From xen-devel-bounces@lists.xensource.com Wed Feb 01 00:38:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 00:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsOD0-0003tg-2I; Wed, 01 Feb 2012 00:37: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 1RsOCz-0003tb-BG
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 00:37:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328056654!51040376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 440 invoked from network); 1 Feb 2012 00:37:34 -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;
	1 Feb 2012 00:37:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,599,1320624000"; d="scan'208";a="10404237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 00:37:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 00:37:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsOCx-0002qc-3x;
	Wed, 01 Feb 2012 00:37:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsOCx-0007d7-1w;
	Wed, 01 Feb 2012 00:37:55 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11746-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 00:37:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11746: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11746 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11746/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 10877

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10877
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10859

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   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-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-rhel6hvm-amd  7 redhat-install               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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  1b7e074ee1d6
baseline version:
 xen                  271e30252c16

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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:   21562:1b7e074ee1d6
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Jan 31 11:49:30 2012 +0000
    
    vesa: flush lfb after zeroing
    
    If Xen is going to relinquish the VGA console, flush the linear frame
    buffer after zeroing it in vesa_endboot().
    
    Failing to do so in some circumstances leads to the actual linear
    framebuffer on the graphics card still containing the output of the
    Xen boot console can lead to ugly graphics output when dom0 is setting
    up the graphics card for its own use.
    
    While the patch is quite large, it is mostly just code motion to
    prevent having to forward declare lfb_flush().  The only functional
    change to vesa_endboot() is to insert a call to lbf_flush().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24615:ac9f32525376
    xen-unstable date:        Sat Jan 28 13:42:25 2012 +0000
    
    
changeset:   21561:0ea6664f8eee
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Jan 31 11:49:15 2012 +0000
    
    Console: introduce console=none command line parameter
    
    Currenty, not specifying 'console=<foo>' on the command line causes
    Xen to default to 'vga'.  Alternativly, the user can explicitly
    specifiy 'console=vga|com1|com2'.
    
    However, there is no way to specify that neither vga nor serial should
    be used.  Specifying 'console=' does have the effect that neither vga
    nor serial is set up, but at the cost of an "Bad console= option ''"
    warning.
    
    Therefore, expliticly support a 'console=none' option which does not
    set up vga and does not set up serial, but does not trigger the bad
    console warning.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24614:f8c2cf24a26c
    xen-unstable date:        Sat Jan 28 13:41:42 2012 +0000
    
    
changeset:   21560:271e30252c16
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 00:38:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 00:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsOD0-0003tg-2I; Wed, 01 Feb 2012 00:37: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 1RsOCz-0003tb-BG
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 00:37:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328056654!51040376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 440 invoked from network); 1 Feb 2012 00:37:34 -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;
	1 Feb 2012 00:37:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,599,1320624000"; d="scan'208";a="10404237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 00:37:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 00:37:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsOCx-0002qc-3x;
	Wed, 01 Feb 2012 00:37:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsOCx-0007d7-1w;
	Wed, 01 Feb 2012 00:37:55 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11746-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 00:37:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11746: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11746 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11746/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 10877

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10877
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10859

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   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-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-rhel6hvm-amd  7 redhat-install               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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  1b7e074ee1d6
baseline version:
 xen                  271e30252c16

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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:   21562:1b7e074ee1d6
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Jan 31 11:49:30 2012 +0000
    
    vesa: flush lfb after zeroing
    
    If Xen is going to relinquish the VGA console, flush the linear frame
    buffer after zeroing it in vesa_endboot().
    
    Failing to do so in some circumstances leads to the actual linear
    framebuffer on the graphics card still containing the output of the
    Xen boot console can lead to ugly graphics output when dom0 is setting
    up the graphics card for its own use.
    
    While the patch is quite large, it is mostly just code motion to
    prevent having to forward declare lfb_flush().  The only functional
    change to vesa_endboot() is to insert a call to lbf_flush().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24615:ac9f32525376
    xen-unstable date:        Sat Jan 28 13:42:25 2012 +0000
    
    
changeset:   21561:0ea6664f8eee
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Jan 31 11:49:15 2012 +0000
    
    Console: introduce console=none command line parameter
    
    Currenty, not specifying 'console=<foo>' on the command line causes
    Xen to default to 'vga'.  Alternativly, the user can explicitly
    specifiy 'console=vga|com1|com2'.
    
    However, there is no way to specify that neither vga nor serial should
    be used.  Specifying 'console=' does have the effect that neither vga
    nor serial is set up, but at the cost of an "Bad console= option ''"
    warning.
    
    Therefore, expliticly support a 'console=none' option which does not
    set up vga and does not set up serial, but does not trigger the bad
    console warning.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24614:f8c2cf24a26c
    xen-unstable date:        Sat Jan 28 13:41:42 2012 +0000
    
    
changeset:   21560:271e30252c16
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:05:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01: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.xensource.com>)
	id 1RsOdQ-0008FV-5m; Wed, 01 Feb 2012 01:05:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsOdO-0008FC-Jk
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:05:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328058305!8707266!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19633 invoked from network); 1 Feb 2012 01:05:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:05:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11150fA011868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:05:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q111502S011865;
	Tue, 31 Jan 2012 20:05:00 -0500
Date: Tue, 31 Jan 2012 21:05:00 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "W. Michael Petullo" <mike@flyn.org>
Message-ID: <20120201010500.GC32295@andromeda.dapyr.net>
References: <20120128235449.GA22022@imp.flyn.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120128235449.GA22022@imp.flyn.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 28, 2012 at 05:54:49PM -0600, W. Michael Petullo wrote:
> I have ported Anil's passive profile-capable OProfile patch to Linux
> 3.2. I have be able to hobble this patch along to new kernel versions, but
> it is in need of additional work if it is to be submitted upstream. Please
> see:
> 
> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz
> 
> With this patch applied to Linux 3.2, I can perform passive
> profiling of an unprivileged Xen domain.

What version of oprofile did you use?
> 
> -- 
> Mike
> 
> :wq
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:05:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01: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.xensource.com>)
	id 1RsOdQ-0008FV-5m; Wed, 01 Feb 2012 01:05:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsOdO-0008FC-Jk
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:05:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328058305!8707266!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19633 invoked from network); 1 Feb 2012 01:05:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:05:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11150fA011868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:05:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q111502S011865;
	Tue, 31 Jan 2012 20:05:00 -0500
Date: Tue, 31 Jan 2012 21:05:00 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "W. Michael Petullo" <mike@flyn.org>
Message-ID: <20120201010500.GC32295@andromeda.dapyr.net>
References: <20120128235449.GA22022@imp.flyn.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120128235449.GA22022@imp.flyn.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 28, 2012 at 05:54:49PM -0600, W. Michael Petullo wrote:
> I have ported Anil's passive profile-capable OProfile patch to Linux
> 3.2. I have be able to hobble this patch along to new kernel versions, but
> it is in need of additional work if it is to be submitted upstream. Please
> see:
> 
> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz
> 
> With this patch applied to Linux 3.2, I can perform passive
> profiling of an unprivileged Xen domain.

What version of oprofile did you use?
> 
> -- 
> Mike
> 
> :wq
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:08:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsOgE-0008Me-Ov; Wed, 01 Feb 2012 01:08:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsOgD-0008MV-Hi
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:08:09 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328058438!52378758!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6875 invoked from network); 1 Feb 2012 01:07:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:07:20 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11183ag011967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:08:03 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q11183R9011965;
	Tue, 31 Jan 2012 20:08:03 -0500
Date: Tue, 31 Jan 2012 21:08:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120201010803.GD32295@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
	<20120131162759.GA18248@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns
	if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 04:40:26PM +0000, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > So the xen_have_vector_callback looks to be only set by
> > 
> > 1398         if (xen_feature(XENFEAT_hvm_callback_vector))
> > 1399                 xen_have_vector_callback = 1;
> > 
> > So could this be just done via a check for that instead?
> > 
> 
> Sure, but I don't think it would be better: using
> xen_have_vector_callback is more consistent and give us the flexibility
> of allowing users to manually override it in the future.

ok. applied. Hm, I was thinking to put on stable@kernel.org - but how
far back should it go? 2.6.37?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:08:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsOgE-0008Me-Ov; Wed, 01 Feb 2012 01:08:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsOgD-0008MV-Hi
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:08:09 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328058438!52378758!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6875 invoked from network); 1 Feb 2012 01:07:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:07:20 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11183ag011967
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:08:03 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q11183R9011965;
	Tue, 31 Jan 2012 20:08:03 -0500
Date: Tue, 31 Jan 2012 21:08:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120201010803.GD32295@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
	<20120131162759.GA18248@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns
	if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 04:40:26PM +0000, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > So the xen_have_vector_callback looks to be only set by
> > 
> > 1398         if (xen_feature(XENFEAT_hvm_callback_vector))
> > 1399                 xen_have_vector_callback = 1;
> > 
> > So could this be just done via a check for that instead?
> > 
> 
> Sure, but I don't think it would be better: using
> xen_have_vector_callback is more consistent and give us the flexibility
> of allowing users to manually override it in the future.

ok. applied. Hm, I was thinking to put on stable@kernel.org - but how
far back should it go? 2.6.37?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:13:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01: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.xensource.com>)
	id 1RsOlQ-0000EU-Hx; Wed, 01 Feb 2012 01:13:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsOlO-0000E5-MO
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:13:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328058802!12938026!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25453 invoked from network); 1 Feb 2012 01:13:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:13:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q111DIF3012196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:13:18 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q111DIBo012194;
	Tue, 31 Jan 2012 20:13:18 -0500
Date: Tue, 31 Jan 2012 21:13:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120201011318.GE32295@andromeda.dapyr.net>
References: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH v3] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 04:02:31PM +0000, Stefano Stabellini wrote:
> This patch implements support for multiple consoles:
> consoles other than the first one are setup using the traditional xenbus
> and grant-table based mechanism.
> We use a list to keep track of the allocated consoles, we don't
> expect too many of them anyway.
> 

So looks good. applied to #testing. How do I test "multiple" consoles?

> 
> Changes in v3:
> 
> - call hvc_remove before removing the console from xenconsoles;
> - do not lock xencons_lock twice in the destruction path;
> - use the DEFINE_XENBUS_DRIVER macro.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/hvc_xen.c |  435 +++++++++++++++++++++++++++++++++++++++------
>  1 files changed, 377 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index d5000aa..26090c7 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -23,6 +23,7 @@
>  #include <linux/err.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
> +#include <linux/list.h>
>  
>  #include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
> @@ -30,47 +31,67 @@
>  #include <xen/xen.h>
>  #include <xen/interface/xen.h>
>  #include <xen/hvm.h>
> +#include <xen/grant_table.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
>  #include <xen/hvc-console.h>
> +#include <xen/xenbus.h>
>  
>  #include "hvc_console.h"
>  
>  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
>  
> -static struct hvc_struct *hvc;
> -static int xencons_irq;
> +struct xencons_info {
> +	struct list_head list;
> +	struct xenbus_device *xbdev;
> +	struct xencons_interface *intf;
> +	unsigned int evtchn;
> +	struct hvc_struct *hvc;
> +	int irq;
> +	int vtermno;
> +	grant_ref_t gntref;
> +};
> +
> +static LIST_HEAD(xenconsoles);
> +static DEFINE_SPINLOCK(xencons_lock);
> +static struct xenbus_driver xencons_driver;
>  
>  /* ------------------------------------------------------------------ */
>  
> -static unsigned long console_pfn = ~0ul;
> -static unsigned int console_evtchn = ~0ul;
> -static struct xencons_interface *xencons_if = NULL;
> +static struct xencons_info *vtermno_to_xencons(int vtermno)
> +{
> +	struct xencons_info *entry, *n, *ret = NULL;
> +
> +	if (list_empty(&xenconsoles))
> +			return NULL;
>  
> -static inline struct xencons_interface *xencons_interface(void)
> +	list_for_each_entry_safe(entry, n, &xenconsoles, list) {
> +		if (entry->vtermno == vtermno) {
> +			ret  = entry;
> +			break;
> +		}
> +	}
> +
> +	return ret;
> +}
> +
> +static inline int xenbus_devid_to_vtermno(int devid)
>  {
> -	if (xencons_if != NULL)
> -		return xencons_if;
> -	if (console_pfn == ~0ul)
> -		return mfn_to_virt(xen_start_info->console.domU.mfn);
> -	else
> -		return __va(console_pfn << PAGE_SHIFT);
> +	return devid + HVC_COOKIE;
>  }
>  
> -static inline void notify_daemon(void)
> +static inline void notify_daemon(struct xencons_info *cons)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	if (console_evtchn == ~0ul)
> -		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> -	else
> -		notify_remote_via_evtchn(console_evtchn);
> +	notify_remote_via_evtchn(cons->evtchn);
>  }
>  
> -static int __write_console(const char *data, int len)
> +static int __write_console(struct xencons_info *xencons,
> +		const char *data, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
>  	XENCONS_RING_IDX cons, prod;
> +	struct xencons_interface *intf = xencons->intf;
>  	int sent = 0;
>  
>  	cons = intf->out_cons;
> @@ -85,13 +106,16 @@ static int __write_console(const char *data, int len)
>  	intf->out_prod = prod;
>  
>  	if (sent)
> -		notify_daemon();
> +		notify_daemon(xencons);
>  	return sent;
>  }
>  
>  static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  {
>  	int ret = len;
> +	struct xencons_info *cons = vtermno_to_xencons(vtermno);
> +	if (cons == NULL)
> +		return -EINVAL;
>  
>  	/*
>  	 * Make sure the whole buffer is emitted, polling if
> @@ -100,7 +124,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  	 * kernel is crippled.
>  	 */
>  	while (len) {
> -		int sent = __write_console(data, len);
> +		int sent = __write_console(cons, data, len);
>  		
>  		data += sent;
>  		len -= sent;
> @@ -114,9 +138,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  
>  static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
> +	struct xencons_interface *intf;
>  	XENCONS_RING_IDX cons, prod;
>  	int recv = 0;
> +	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> +	if (xencons == NULL)
> +		return -EINVAL;
> +	intf = xencons->intf;
>  
>  	cons = intf->in_cons;
>  	prod = intf->in_prod;
> @@ -129,7 +157,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  	mb();			/* read ring before consuming */
>  	intf->in_cons = cons;
>  
> -	notify_daemon();
> +	notify_daemon(xencons);
>  	return recv;
>  }
>  
> @@ -172,78 +200,359 @@ static int xen_hvm_console_init(void)
>  	int r;
>  	uint64_t v = 0;
>  	unsigned long mfn;
> +	struct xencons_info *info;
>  
>  	if (!xen_hvm_domain())
>  		return -ENODEV;
>  
> -	if (xencons_if != NULL)
> -		return -EBUSY;
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
>  
>  	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> -	console_evtchn = v;
> +	}
> +	info->evtchn = v;
>  	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> +	}
>  	mfn = v;
> -	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> -	if (xencons_if == NULL)
> +	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (info->intf == NULL) {
> +		kfree(info);
> +		return -ENODEV;
> +	}
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_pv_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_pv_domain())
> +		return -ENODEV;
> +
> +	if (!xen_start_info->console.domU.evtchn)
> +		return -ENODEV;
> +
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
> +
> +	info->evtchn = xen_start_info->console.domU.evtchn;
> +	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_initial_domain_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_initial_domain())
>  		return -ENODEV;
>  
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
>  	return 0;
>  }
>  
>  static int __init xen_hvc_init(void)
>  {
> -	struct hvc_struct *hp;
> -	struct hv_ops *ops;
>  	int r;
> +	struct xencons_info *info;
> +	const struct hv_ops *ops;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
> -		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +		r = xen_initial_domain_console_init();
> +		if (r < 0)
> +			return r;
> +		info = vtermno_to_xencons(HVC_COOKIE);
>  	} else {
>  		ops = &domU_hvc_ops;
> -		if (xen_pv_domain()) {
> -			if (!xen_start_info->console.domU.evtchn)
> -				return -ENODEV;
> -			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> -		} else {
> +		if (xen_hvm_domain())
>  			r = xen_hvm_console_init();
> -			if (r < 0)
> -				return r;
> -		}
> -		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> -		if (xencons_irq < 0)
> -			xencons_irq = 0; /* NO_IRQ */
>  		else
> -			irq_set_noprobe(xencons_irq);
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
> +
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +		info->irq = bind_evtchn_to_irq(info->evtchn);
> +	}
> +	if (info->irq < 0)
> +		info->irq = 0; /* NO_IRQ */
> +	else
> +		irq_set_noprobe(info->irq);
> +
> +	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> +	if (IS_ERR(info->hvc)) {
> +		r = PTR_ERR(info->hvc);
> +		spin_lock(&xencons_lock);
> +		list_del(&info->list);
> +		spin_unlock(&xencons_lock);
> +		if (info->irq)
> +			unbind_from_irqhandler(info->irq, NULL);
> +		kfree(info);
> +		return r;
>  	}
>  
> -	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
> -	if (IS_ERR(hp))
> -		return PTR_ERR(hp);
> +	return xenbus_register_frontend(&xencons_driver);
> +}
>  
> -	hvc = hp;
> +void xen_console_resume(void)
> +{
> +	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
> +	if (info != NULL && info->irq)
> +		rebind_evtchn_irq(info->evtchn, info->irq);
> +}
> +
> +static void xencons_disconnect_backend(struct xencons_info *info)
> +{
> +	if (info->irq > 0)
> +		unbind_from_irqhandler(info->irq, NULL);
> +	info->irq = 0;
> +	if (info->evtchn > 0)
> +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> +	info->evtchn = 0;
> +	if (info->gntref > 0)
> +		gnttab_free_grant_references(info->gntref);
> +	info->gntref = 0;
> +	if (info->hvc != NULL)
> +		hvc_remove(info->hvc);
> +	info->hvc = NULL;
> +}
>  
> +static void xencons_free(struct xencons_info *info)
> +{
> +	free_page((unsigned long)info->intf);
> +	info->intf = NULL;
> +	info->vtermno = 0;
> +	kfree(info);
> +}
> +
> +static int xen_console_remove(struct xencons_info *info)
> +{
> +	xencons_disconnect_backend(info);
> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	if (info->xbdev != NULL)
> +		xencons_free(info);
> +	else {
> +		if (xen_hvm_domain())
> +			iounmap(info->intf);
> +		kfree(info);
> +	}
>  	return 0;
>  }
>  
> -void xen_console_resume(void)
> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	return xen_console_remove(dev_get_drvdata(&dev->dev));
> +}
> +
> +static int xencons_connect_backend(struct xenbus_device *dev,
> +				  struct xencons_info *info)
> +{
> +	int ret, evtchn, devid, ref, irq;
> +	struct xenbus_transaction xbt;
> +	grant_ref_t gref_head;
> +	unsigned long mfn;
> +
> +	ret = xenbus_alloc_evtchn(dev, &evtchn);
> +	if (ret)
> +		return ret;
> +	info->evtchn = evtchn;
> +	irq = bind_evtchn_to_irq(evtchn);
> +	if (irq < 0)
> +		return irq;
> +	info->irq = irq;
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
> +			irq, &domU_hvc_ops, 256);
> +	if (IS_ERR(info->hvc))
> +		return PTR_ERR(info->hvc);
> +	if (xen_pv_domain())
> +		mfn = virt_to_mfn(info->intf);
> +	else
> +		mfn = __pa(info->intf) >> PAGE_SHIFT;
> +	ret = gnttab_alloc_grant_references(1, &gref_head);
> +	if (ret < 0)
> +		return ret;
> +	info->gntref = gref_head;
> +	ref = gnttab_claim_grant_reference(&gref_head);
> +	if (ref < 0)
> +		return ref;
> +	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
> +			mfn, 0);
> +
> + again:
> +	ret = xenbus_transaction_start(&xbt);
> +	if (ret) {
> +		xenbus_dev_fatal(dev, ret, "starting transaction");
> +		return ret;
> +	}
> +	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
> +			    evtchn);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_transaction_end(xbt, 0);
> +	if (ret) {
> +		if (ret == -EAGAIN)
> +			goto again;
> +		xenbus_dev_fatal(dev, ret, "completing transaction");
> +		return ret;
> +	}
> +
> +	xenbus_switch_state(dev, XenbusStateInitialised);
> +	return 0;
> +
> + error_xenbus:
> +	xenbus_transaction_end(xbt, 1);
> +	xenbus_dev_fatal(dev, ret, "writing xenstore");
> +	return ret;
> +}
> +
> +static int __devinit xencons_probe(struct xenbus_device *dev,
> +				  const struct xenbus_device_id *id)
> +{
> +	int ret, devid;
> +	struct xencons_info *info;
> +
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	if (devid == 0)
> +		return -ENODEV;
> +
> +	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +	if (!info)
> +		goto error_nomem;
> +	dev_set_drvdata(&dev->dev, info);
> +	info->xbdev = dev;
> +	info->vtermno = xenbus_devid_to_vtermno(devid);
> +	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> +	if (!info->intf)
> +		goto error_nomem;
> +
> +	ret = xencons_connect_backend(dev, info);
> +	if (ret < 0)
> +		goto error;
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +
> + error_nomem:
> +	ret = -ENOMEM;
> +	xenbus_dev_fatal(dev, ret, "allocating device memory");
> + error:
> +	xencons_disconnect_backend(info);
> +	xencons_free(info);
> +	return ret;
> +}
> +
> +static int xencons_resume(struct xenbus_device *dev)
>  {
> -	if (xencons_irq)
> -		rebind_evtchn_irq(console_evtchn, xencons_irq);
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	xencons_disconnect_backend(info);
> +	memset(info->intf, 0, PAGE_SIZE);
> +	return xencons_connect_backend(dev, info);
>  }
>  
> +static void xencons_backend_changed(struct xenbus_device *dev,
> +				   enum xenbus_state backend_state)
> +{
> +	switch (backend_state) {
> +	case XenbusStateReconfiguring:
> +	case XenbusStateReconfigured:
> +	case XenbusStateInitialising:
> +	case XenbusStateInitialised:
> +	case XenbusStateUnknown:
> +	case XenbusStateClosed:
> +		break;
> +
> +	case XenbusStateInitWait:
> +		break;
> +
> +	case XenbusStateConnected:
> +		xenbus_switch_state(dev, XenbusStateConnected);
> +		break;
> +
> +	case XenbusStateClosing:
> +		xenbus_frontend_closed(dev);
> +		break;
> +	}
> +}
> +
> +static const struct xenbus_device_id xencons_ids[] = {
> +	{ "console" },
> +	{ "" }
> +};
> +
> +
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		xen_console_remove(entry);
> +	}
>  }
>  
>  static int xen_cons_init(void)
> @@ -256,18 +565,28 @@ static int xen_cons_init(void)
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
>  	else {
> +		int r;
>  		ops = &domU_hvc_ops;
>  
> -		if (xen_pv_domain())
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
>  		else
> -			xen_hvm_console_init();
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
>  	}
>  
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
>  
> +static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +);
> +
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
>  console_initcall(xen_cons_init);
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:13:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01: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.xensource.com>)
	id 1RsOlQ-0000EU-Hx; Wed, 01 Feb 2012 01:13:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsOlO-0000E5-MO
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:13:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328058802!12938026!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25453 invoked from network); 1 Feb 2012 01:13:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:13:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q111DIF3012196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:13:18 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q111DIBo012194;
	Tue, 31 Jan 2012 20:13:18 -0500
Date: Tue, 31 Jan 2012 21:13:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120201011318.GE32295@andromeda.dapyr.net>
References: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH v3] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 04:02:31PM +0000, Stefano Stabellini wrote:
> This patch implements support for multiple consoles:
> consoles other than the first one are setup using the traditional xenbus
> and grant-table based mechanism.
> We use a list to keep track of the allocated consoles, we don't
> expect too many of them anyway.
> 

So looks good. applied to #testing. How do I test "multiple" consoles?

> 
> Changes in v3:
> 
> - call hvc_remove before removing the console from xenconsoles;
> - do not lock xencons_lock twice in the destruction path;
> - use the DEFINE_XENBUS_DRIVER macro.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/hvc_xen.c |  435 +++++++++++++++++++++++++++++++++++++++------
>  1 files changed, 377 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index d5000aa..26090c7 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -23,6 +23,7 @@
>  #include <linux/err.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
> +#include <linux/list.h>
>  
>  #include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
> @@ -30,47 +31,67 @@
>  #include <xen/xen.h>
>  #include <xen/interface/xen.h>
>  #include <xen/hvm.h>
> +#include <xen/grant_table.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
>  #include <xen/hvc-console.h>
> +#include <xen/xenbus.h>
>  
>  #include "hvc_console.h"
>  
>  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
>  
> -static struct hvc_struct *hvc;
> -static int xencons_irq;
> +struct xencons_info {
> +	struct list_head list;
> +	struct xenbus_device *xbdev;
> +	struct xencons_interface *intf;
> +	unsigned int evtchn;
> +	struct hvc_struct *hvc;
> +	int irq;
> +	int vtermno;
> +	grant_ref_t gntref;
> +};
> +
> +static LIST_HEAD(xenconsoles);
> +static DEFINE_SPINLOCK(xencons_lock);
> +static struct xenbus_driver xencons_driver;
>  
>  /* ------------------------------------------------------------------ */
>  
> -static unsigned long console_pfn = ~0ul;
> -static unsigned int console_evtchn = ~0ul;
> -static struct xencons_interface *xencons_if = NULL;
> +static struct xencons_info *vtermno_to_xencons(int vtermno)
> +{
> +	struct xencons_info *entry, *n, *ret = NULL;
> +
> +	if (list_empty(&xenconsoles))
> +			return NULL;
>  
> -static inline struct xencons_interface *xencons_interface(void)
> +	list_for_each_entry_safe(entry, n, &xenconsoles, list) {
> +		if (entry->vtermno == vtermno) {
> +			ret  = entry;
> +			break;
> +		}
> +	}
> +
> +	return ret;
> +}
> +
> +static inline int xenbus_devid_to_vtermno(int devid)
>  {
> -	if (xencons_if != NULL)
> -		return xencons_if;
> -	if (console_pfn == ~0ul)
> -		return mfn_to_virt(xen_start_info->console.domU.mfn);
> -	else
> -		return __va(console_pfn << PAGE_SHIFT);
> +	return devid + HVC_COOKIE;
>  }
>  
> -static inline void notify_daemon(void)
> +static inline void notify_daemon(struct xencons_info *cons)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	if (console_evtchn == ~0ul)
> -		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> -	else
> -		notify_remote_via_evtchn(console_evtchn);
> +	notify_remote_via_evtchn(cons->evtchn);
>  }
>  
> -static int __write_console(const char *data, int len)
> +static int __write_console(struct xencons_info *xencons,
> +		const char *data, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
>  	XENCONS_RING_IDX cons, prod;
> +	struct xencons_interface *intf = xencons->intf;
>  	int sent = 0;
>  
>  	cons = intf->out_cons;
> @@ -85,13 +106,16 @@ static int __write_console(const char *data, int len)
>  	intf->out_prod = prod;
>  
>  	if (sent)
> -		notify_daemon();
> +		notify_daemon(xencons);
>  	return sent;
>  }
>  
>  static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  {
>  	int ret = len;
> +	struct xencons_info *cons = vtermno_to_xencons(vtermno);
> +	if (cons == NULL)
> +		return -EINVAL;
>  
>  	/*
>  	 * Make sure the whole buffer is emitted, polling if
> @@ -100,7 +124,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  	 * kernel is crippled.
>  	 */
>  	while (len) {
> -		int sent = __write_console(data, len);
> +		int sent = __write_console(cons, data, len);
>  		
>  		data += sent;
>  		len -= sent;
> @@ -114,9 +138,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  
>  static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
> +	struct xencons_interface *intf;
>  	XENCONS_RING_IDX cons, prod;
>  	int recv = 0;
> +	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> +	if (xencons == NULL)
> +		return -EINVAL;
> +	intf = xencons->intf;
>  
>  	cons = intf->in_cons;
>  	prod = intf->in_prod;
> @@ -129,7 +157,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  	mb();			/* read ring before consuming */
>  	intf->in_cons = cons;
>  
> -	notify_daemon();
> +	notify_daemon(xencons);
>  	return recv;
>  }
>  
> @@ -172,78 +200,359 @@ static int xen_hvm_console_init(void)
>  	int r;
>  	uint64_t v = 0;
>  	unsigned long mfn;
> +	struct xencons_info *info;
>  
>  	if (!xen_hvm_domain())
>  		return -ENODEV;
>  
> -	if (xencons_if != NULL)
> -		return -EBUSY;
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
>  
>  	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> -	console_evtchn = v;
> +	}
> +	info->evtchn = v;
>  	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> +	}
>  	mfn = v;
> -	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> -	if (xencons_if == NULL)
> +	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (info->intf == NULL) {
> +		kfree(info);
> +		return -ENODEV;
> +	}
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_pv_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_pv_domain())
> +		return -ENODEV;
> +
> +	if (!xen_start_info->console.domU.evtchn)
> +		return -ENODEV;
> +
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
> +
> +	info->evtchn = xen_start_info->console.domU.evtchn;
> +	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_initial_domain_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_initial_domain())
>  		return -ENODEV;
>  
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
>  	return 0;
>  }
>  
>  static int __init xen_hvc_init(void)
>  {
> -	struct hvc_struct *hp;
> -	struct hv_ops *ops;
>  	int r;
> +	struct xencons_info *info;
> +	const struct hv_ops *ops;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
> -		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +		r = xen_initial_domain_console_init();
> +		if (r < 0)
> +			return r;
> +		info = vtermno_to_xencons(HVC_COOKIE);
>  	} else {
>  		ops = &domU_hvc_ops;
> -		if (xen_pv_domain()) {
> -			if (!xen_start_info->console.domU.evtchn)
> -				return -ENODEV;
> -			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> -		} else {
> +		if (xen_hvm_domain())
>  			r = xen_hvm_console_init();
> -			if (r < 0)
> -				return r;
> -		}
> -		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> -		if (xencons_irq < 0)
> -			xencons_irq = 0; /* NO_IRQ */
>  		else
> -			irq_set_noprobe(xencons_irq);
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
> +
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +		info->irq = bind_evtchn_to_irq(info->evtchn);
> +	}
> +	if (info->irq < 0)
> +		info->irq = 0; /* NO_IRQ */
> +	else
> +		irq_set_noprobe(info->irq);
> +
> +	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> +	if (IS_ERR(info->hvc)) {
> +		r = PTR_ERR(info->hvc);
> +		spin_lock(&xencons_lock);
> +		list_del(&info->list);
> +		spin_unlock(&xencons_lock);
> +		if (info->irq)
> +			unbind_from_irqhandler(info->irq, NULL);
> +		kfree(info);
> +		return r;
>  	}
>  
> -	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
> -	if (IS_ERR(hp))
> -		return PTR_ERR(hp);
> +	return xenbus_register_frontend(&xencons_driver);
> +}
>  
> -	hvc = hp;
> +void xen_console_resume(void)
> +{
> +	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
> +	if (info != NULL && info->irq)
> +		rebind_evtchn_irq(info->evtchn, info->irq);
> +}
> +
> +static void xencons_disconnect_backend(struct xencons_info *info)
> +{
> +	if (info->irq > 0)
> +		unbind_from_irqhandler(info->irq, NULL);
> +	info->irq = 0;
> +	if (info->evtchn > 0)
> +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> +	info->evtchn = 0;
> +	if (info->gntref > 0)
> +		gnttab_free_grant_references(info->gntref);
> +	info->gntref = 0;
> +	if (info->hvc != NULL)
> +		hvc_remove(info->hvc);
> +	info->hvc = NULL;
> +}
>  
> +static void xencons_free(struct xencons_info *info)
> +{
> +	free_page((unsigned long)info->intf);
> +	info->intf = NULL;
> +	info->vtermno = 0;
> +	kfree(info);
> +}
> +
> +static int xen_console_remove(struct xencons_info *info)
> +{
> +	xencons_disconnect_backend(info);
> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	if (info->xbdev != NULL)
> +		xencons_free(info);
> +	else {
> +		if (xen_hvm_domain())
> +			iounmap(info->intf);
> +		kfree(info);
> +	}
>  	return 0;
>  }
>  
> -void xen_console_resume(void)
> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	return xen_console_remove(dev_get_drvdata(&dev->dev));
> +}
> +
> +static int xencons_connect_backend(struct xenbus_device *dev,
> +				  struct xencons_info *info)
> +{
> +	int ret, evtchn, devid, ref, irq;
> +	struct xenbus_transaction xbt;
> +	grant_ref_t gref_head;
> +	unsigned long mfn;
> +
> +	ret = xenbus_alloc_evtchn(dev, &evtchn);
> +	if (ret)
> +		return ret;
> +	info->evtchn = evtchn;
> +	irq = bind_evtchn_to_irq(evtchn);
> +	if (irq < 0)
> +		return irq;
> +	info->irq = irq;
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
> +			irq, &domU_hvc_ops, 256);
> +	if (IS_ERR(info->hvc))
> +		return PTR_ERR(info->hvc);
> +	if (xen_pv_domain())
> +		mfn = virt_to_mfn(info->intf);
> +	else
> +		mfn = __pa(info->intf) >> PAGE_SHIFT;
> +	ret = gnttab_alloc_grant_references(1, &gref_head);
> +	if (ret < 0)
> +		return ret;
> +	info->gntref = gref_head;
> +	ref = gnttab_claim_grant_reference(&gref_head);
> +	if (ref < 0)
> +		return ref;
> +	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
> +			mfn, 0);
> +
> + again:
> +	ret = xenbus_transaction_start(&xbt);
> +	if (ret) {
> +		xenbus_dev_fatal(dev, ret, "starting transaction");
> +		return ret;
> +	}
> +	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
> +			    evtchn);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_transaction_end(xbt, 0);
> +	if (ret) {
> +		if (ret == -EAGAIN)
> +			goto again;
> +		xenbus_dev_fatal(dev, ret, "completing transaction");
> +		return ret;
> +	}
> +
> +	xenbus_switch_state(dev, XenbusStateInitialised);
> +	return 0;
> +
> + error_xenbus:
> +	xenbus_transaction_end(xbt, 1);
> +	xenbus_dev_fatal(dev, ret, "writing xenstore");
> +	return ret;
> +}
> +
> +static int __devinit xencons_probe(struct xenbus_device *dev,
> +				  const struct xenbus_device_id *id)
> +{
> +	int ret, devid;
> +	struct xencons_info *info;
> +
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	if (devid == 0)
> +		return -ENODEV;
> +
> +	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +	if (!info)
> +		goto error_nomem;
> +	dev_set_drvdata(&dev->dev, info);
> +	info->xbdev = dev;
> +	info->vtermno = xenbus_devid_to_vtermno(devid);
> +	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> +	if (!info->intf)
> +		goto error_nomem;
> +
> +	ret = xencons_connect_backend(dev, info);
> +	if (ret < 0)
> +		goto error;
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +
> + error_nomem:
> +	ret = -ENOMEM;
> +	xenbus_dev_fatal(dev, ret, "allocating device memory");
> + error:
> +	xencons_disconnect_backend(info);
> +	xencons_free(info);
> +	return ret;
> +}
> +
> +static int xencons_resume(struct xenbus_device *dev)
>  {
> -	if (xencons_irq)
> -		rebind_evtchn_irq(console_evtchn, xencons_irq);
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	xencons_disconnect_backend(info);
> +	memset(info->intf, 0, PAGE_SIZE);
> +	return xencons_connect_backend(dev, info);
>  }
>  
> +static void xencons_backend_changed(struct xenbus_device *dev,
> +				   enum xenbus_state backend_state)
> +{
> +	switch (backend_state) {
> +	case XenbusStateReconfiguring:
> +	case XenbusStateReconfigured:
> +	case XenbusStateInitialising:
> +	case XenbusStateInitialised:
> +	case XenbusStateUnknown:
> +	case XenbusStateClosed:
> +		break;
> +
> +	case XenbusStateInitWait:
> +		break;
> +
> +	case XenbusStateConnected:
> +		xenbus_switch_state(dev, XenbusStateConnected);
> +		break;
> +
> +	case XenbusStateClosing:
> +		xenbus_frontend_closed(dev);
> +		break;
> +	}
> +}
> +
> +static const struct xenbus_device_id xencons_ids[] = {
> +	{ "console" },
> +	{ "" }
> +};
> +
> +
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		xen_console_remove(entry);
> +	}
>  }
>  
>  static int xen_cons_init(void)
> @@ -256,18 +565,28 @@ static int xen_cons_init(void)
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
>  	else {
> +		int r;
>  		ops = &domU_hvc_ops;
>  
> -		if (xen_pv_domain())
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
>  		else
> -			xen_hvm_console_init();
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
>  	}
>  
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
>  
> +static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +);
> +
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
>  console_initcall(xen_cons_init);
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:28:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsOzl-0000mq-7Z; Wed, 01 Feb 2012 01:28:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1RsOzj-0000ml-PS
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:28:20 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328059693!13190974!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13791 invoked from network); 1 Feb 2012 01:28:13 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-2.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 01:28:13 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 539BB1F880B5
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 20:28:13 -0500 (EST)
Received: (qmail 3407 invoked by uid 108); 31 Jan 2012 20:28:13 -0500
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.25.186.85)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 31 Jan 2012 20:28:13 -0500
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 4F95B812133; Tue, 31 Jan 2012 19:28:12 -0600 (CST)
Date: Tue, 31 Jan 2012 19:28:12 -0600
From: "W. Michael Petullo" <mike@flyn.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120201012811.GA1994@imp.flyn.org>
References: <20120128235449.GA22022@imp.flyn.org>
	<20120201010500.GC32295@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120201010500.GC32295@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> I have ported Anil's passive profile-capable OProfile patch to Linux
>> 3.2. I have be able to hobble this patch along to new kernel versions, but
>> it is in need of additional work if it is to be submitted upstream. Please
>> see:
>> 
>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz
>> 
>> With this patch applied to Linux 3.2, I can perform passive
>> profiling of an unprivileged Xen domain.

> What version of oprofile did you use?

Fedora's oprofile-0.9.6-21.fc16.x86_64.

-- 
Mike

:wq

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:28:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsOzl-0000mq-7Z; Wed, 01 Feb 2012 01:28:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1RsOzj-0000ml-PS
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:28:20 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328059693!13190974!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13791 invoked from network); 1 Feb 2012 01:28:13 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-2.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 01:28:13 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 539BB1F880B5
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 20:28:13 -0500 (EST)
Received: (qmail 3407 invoked by uid 108); 31 Jan 2012 20:28:13 -0500
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.25.186.85)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 31 Jan 2012 20:28:13 -0500
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 4F95B812133; Tue, 31 Jan 2012 19:28:12 -0600 (CST)
Date: Tue, 31 Jan 2012 19:28:12 -0600
From: "W. Michael Petullo" <mike@flyn.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120201012811.GA1994@imp.flyn.org>
References: <20120128235449.GA22022@imp.flyn.org>
	<20120201010500.GC32295@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120201010500.GC32295@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> I have ported Anil's passive profile-capable OProfile patch to Linux
>> 3.2. I have be able to hobble this patch along to new kernel versions, but
>> it is in need of additional work if it is to be submitted upstream. Please
>> see:
>> 
>> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz
>> 
>> With this patch applied to Linux 3.2, I can perform passive
>> profiling of an unprivileged Xen domain.

> What version of oprofile did you use?

Fedora's oprofile-0.9.6-21.fc16.x86_64.

-- 
Mike

:wq

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01: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.xensource.com>)
	id 1RsP21-0000ry-Pm; Wed, 01 Feb 2012 01:30:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsP20-0000rs-QX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:30:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328059801!50560203!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6873 invoked from network); 1 Feb 2012 01:30:02 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:30:02 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q111UaYt012813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:30:36 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q111Ua5l012811;
	Tue, 31 Jan 2012 20:30:36 -0500
Date: Tue, 31 Jan 2012 21:30:36 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Nathan March <nathan@gt.net>
Message-ID: <20120201013036.GA12637@andromeda.dapyr.net>
References: <4F28603F.8010900@gt.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F28603F.8010900@gt.net>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
	of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 01:42:23PM -0800, Nathan March wrote:
> Hi All,
> 
> We've got a xen setup based around a dell iscsi device with each xen 
> host having 2 lun's, we then run multipath on top of that. After adding 
> a couple new virtual disks the other day, a couple of our online stable 
> VM's suddenly hard locked up. Attaching to the console gave me nothing, 
> looked like they lost their disk devices.
> 
> Attempting to restart them on the same dom0 failed with hot plug errors, 
> as did attempting to start them on a few different dom0's. After doing a 
> "multipath -F" to remove unused devices and manually bringing in just 
> the selected LUN's via "multipath diskname", I was able to successfully 
> start them. This initially made me think perhaps I was hitting some sort 
> of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun 
> = 1088 iscsi connections). Just to be clear, the problem occurred on 
> multiple dom0's at the same time so it definitely seems iscsi related.
> 
> Now, a day later, I'm debugging this further and I'm again unable to 
> start VM's, even with all extra multipath devices removed. I rebooted 
> one of the dom0's and was able to successfully migrate our production 
> VM's off a broken server, so I've now got an empty dom0 that's unable to 
> start any vm's.
> 
> Starting a VM results in the following in xend.log:
> 
> [2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
> [2012-01-31 13:06:16 12353] DEBUG (DevController:628) 
> hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
> [2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices 
> failed.
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line 
> 85, in perform
>     return op_method(op, req)
>   File 
> "/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line 
> 85, in op_wait_for_devices
>     return self.dom.waitForDevices()
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", 
> line 1237, in waitForDevices
>     self.getDeviceController(devclass).waitForDevices()
>   File 
> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
> line 140, in waitForDevices
>     return map(self.waitForDevice, self.deviceIDs())
>   File 
> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
> line 155, in waitForDevice
>     (devid, self.deviceClass))
> VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.


Was there anything in the kernel (dmesg) about vifs? What does your 
/proc/interrupts look like? Can you provide the dmesg that you get
during startup. I am mainly looking for:

NR_IRQS:16640 nr_irqs:1536 16

How many guests are your running when this happens?

One theory is that your are running out dom0 interrupts. Thought
I *think* that was made dynamic in 3.0..


Thought that does explain your iSCSI network wonky in the guest -
was there anything in the dmesg when the guest started going bad?

> [2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071) 
> XendDomainInfo.destroy: domid=35
> [2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying 
> device model
> 
> I tried turning up udev's log level but that didn't reveal anything. 
> Reading the xenstore for the vif doesn't show anything unusual either:
> 
> ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
> 0 = ""
>  bridge = "vlan91"
>  domain = "nathanxenuk1"
>  handle = "0"
>  uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
>  script = "/etc/xen/scripts/vif-bridge"
>  state = "1"
>  frontend = "/local/domain/35/device/vif/0"
>  mac = "00:16:3d:03:00:44"
>  online = "1"
>  frontend-id = "35"
> 
> The bridge device (vlan91) exists, trying a different bridge doesn't 
> matter. Removing the VIF completely results in the same error for the 
> VBD. Adding debugging to the hotplug/network scripts didn't reveal 
> anything, it looks like they aren't even being executed yet. Nothing is 
> logged to xen-hotplug.log.

OK, so that would imply the kernel hasn't been able to do the right
thing. Hmm.

What do you see when this happens with udev --monitor --kernel --udev
--property ?

> 
> The only thing I can think of that this may be related to, is gentoo 
> defaulted to a 10mb /dev which we filled up a few months back. We upped 
> the size to 50mb in the mount options and everything's been completely 
> stable since (~33 days). None of the /dev on the dom0's is higher than 
> 25% usage. Asides from adding the new luns, no changes have been made in 
> the past month.
> 
> To try and test if removing some devices would solve anything, I tried 
> doing an "iscsiadm -m node --logout" and it promptly hard locked the 
> entire box. After a reboot, I was unable to reproduce the problem on 
> that particular dom0.
> 
> I've still got 1 dom0 that's exhibiting the problem, if anyone is able 
> to suggest any further debugging steps?
> 
> - Nathan
> 
> 
> (XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, 
> pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011
> 
> ukxen1 xen # xm info
> host                   : ukxen1
> release                : 3.0.3
> version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
> machine                : x86_64
> nr_cpus                : 24
> nr_nodes               : 2
> cores_per_socket       : 6
> threads_per_core       : 2
> cpu_mhz                : 2261
> hw_caps                : 
> bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
> virt_caps              : hvm hvm_directio
> total_memory           : 98291
> free_memory            : 91908
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : .1
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1 
> dom0_vcpus_pin=true
> cc_compiler            : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
> cc_compile_by          : root
> cc_compile_domain      :
> cc_compile_date        : Mon Aug 29 16:24:12 PDT 2011
> xend_config_format     : 4
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 01:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 01: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.xensource.com>)
	id 1RsP21-0000ry-Pm; Wed, 01 Feb 2012 01:30:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RsP20-0000rs-QX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 01:30:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328059801!50560203!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6873 invoked from network); 1 Feb 2012 01:30:02 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 01:30:02 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q111UaYt012813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 20:30:36 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q111Ua5l012811;
	Tue, 31 Jan 2012 20:30:36 -0500
Date: Tue, 31 Jan 2012 21:30:36 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Nathan March <nathan@gt.net>
Message-ID: <20120201013036.GA12637@andromeda.dapyr.net>
References: <4F28603F.8010900@gt.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F28603F.8010900@gt.net>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
	of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 01:42:23PM -0800, Nathan March wrote:
> Hi All,
> 
> We've got a xen setup based around a dell iscsi device with each xen 
> host having 2 lun's, we then run multipath on top of that. After adding 
> a couple new virtual disks the other day, a couple of our online stable 
> VM's suddenly hard locked up. Attaching to the console gave me nothing, 
> looked like they lost their disk devices.
> 
> Attempting to restart them on the same dom0 failed with hot plug errors, 
> as did attempting to start them on a few different dom0's. After doing a 
> "multipath -F" to remove unused devices and manually bringing in just 
> the selected LUN's via "multipath diskname", I was able to successfully 
> start them. This initially made me think perhaps I was hitting some sort 
> of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun 
> = 1088 iscsi connections). Just to be clear, the problem occurred on 
> multiple dom0's at the same time so it definitely seems iscsi related.
> 
> Now, a day later, I'm debugging this further and I'm again unable to 
> start VM's, even with all extra multipath devices removed. I rebooted 
> one of the dom0's and was able to successfully migrate our production 
> VM's off a broken server, so I've now got an empty dom0 that's unable to 
> start any vm's.
> 
> Starting a VM results in the following in xend.log:
> 
> [2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
> [2012-01-31 13:06:16 12353] DEBUG (DevController:628) 
> hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
> [2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices 
> failed.
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line 
> 85, in perform
>     return op_method(op, req)
>   File 
> "/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line 
> 85, in op_wait_for_devices
>     return self.dom.waitForDevices()
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", 
> line 1237, in waitForDevices
>     self.getDeviceController(devclass).waitForDevices()
>   File 
> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
> line 140, in waitForDevices
>     return map(self.waitForDevice, self.deviceIDs())
>   File 
> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
> line 155, in waitForDevice
>     (devid, self.deviceClass))
> VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.


Was there anything in the kernel (dmesg) about vifs? What does your 
/proc/interrupts look like? Can you provide the dmesg that you get
during startup. I am mainly looking for:

NR_IRQS:16640 nr_irqs:1536 16

How many guests are your running when this happens?

One theory is that your are running out dom0 interrupts. Thought
I *think* that was made dynamic in 3.0..


Thought that does explain your iSCSI network wonky in the guest -
was there anything in the dmesg when the guest started going bad?

> [2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071) 
> XendDomainInfo.destroy: domid=35
> [2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying 
> device model
> 
> I tried turning up udev's log level but that didn't reveal anything. 
> Reading the xenstore for the vif doesn't show anything unusual either:
> 
> ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
> 0 = ""
>  bridge = "vlan91"
>  domain = "nathanxenuk1"
>  handle = "0"
>  uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
>  script = "/etc/xen/scripts/vif-bridge"
>  state = "1"
>  frontend = "/local/domain/35/device/vif/0"
>  mac = "00:16:3d:03:00:44"
>  online = "1"
>  frontend-id = "35"
> 
> The bridge device (vlan91) exists, trying a different bridge doesn't 
> matter. Removing the VIF completely results in the same error for the 
> VBD. Adding debugging to the hotplug/network scripts didn't reveal 
> anything, it looks like they aren't even being executed yet. Nothing is 
> logged to xen-hotplug.log.

OK, so that would imply the kernel hasn't been able to do the right
thing. Hmm.

What do you see when this happens with udev --monitor --kernel --udev
--property ?

> 
> The only thing I can think of that this may be related to, is gentoo 
> defaulted to a 10mb /dev which we filled up a few months back. We upped 
> the size to 50mb in the mount options and everything's been completely 
> stable since (~33 days). None of the /dev on the dom0's is higher than 
> 25% usage. Asides from adding the new luns, no changes have been made in 
> the past month.
> 
> To try and test if removing some devices would solve anything, I tried 
> doing an "iscsiadm -m node --logout" and it promptly hard locked the 
> entire box. After a reboot, I was unable to reproduce the problem on 
> that particular dom0.
> 
> I've still got 1 dom0 that's exhibiting the problem, if anyone is able 
> to suggest any further debugging steps?
> 
> - Nathan
> 
> 
> (XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, 
> pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011
> 
> ukxen1 xen # xm info
> host                   : ukxen1
> release                : 3.0.3
> version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
> machine                : x86_64
> nr_cpus                : 24
> nr_nodes               : 2
> cores_per_socket       : 6
> threads_per_core       : 2
> cpu_mhz                : 2261
> hw_caps                : 
> bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
> virt_caps              : hvm hvm_directio
> total_memory           : 98291
> free_memory            : 91908
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : .1
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1 
> dom0_vcpus_pin=true
> cc_compiler            : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
> cc_compile_by          : root
> cc_compile_domain      :
> cc_compile_date        : Mon Aug 29 16:24:12 PDT 2011
> xend_config_format     : 4
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 03:50:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 03:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsRD2-0000te-4q; Wed, 01 Feb 2012 03:50:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RsRD0-0000tZ-Px
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 03:50:11 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328068171!50567060!1
X-Originating-IP: [220.181.15.8]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gNjY3OA==\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gNjY3OA==\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26102 invoked from network); 1 Feb 2012 03:49:32 -0000
Received: from m15-8.126.com (HELO m15-8.126.com) (220.181.15.8)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 03:49:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=sEfW22IsYzR0FavC1m7shKURXovQUuSati
	nO15JIaX8=; b=U/Iq+JyZgU9frXTNWCsqzr3JyPr7O1F0ZAflbvjq+xjdg3VQEL
	DyCMH+UF7uNzFP5LCUcoJZgJiJuRVXT1yOb2IAZSYvdFQZw4vBrqv72IPf5oPzYa
	fV5UemKRXt5RecpbAfA1LoDXB31IyCPS7RfiAE2AoS9cjRnLbj1KNuXSM=
Received: from hxkhust ( [211.69.198.241] ) by ajax-webmail-wmsvr8
	(Coremail) ; Wed, 1 Feb 2012 11:50:06 +0800 (CST)
Date: Wed, 1 Feb 2012 11:50:06 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [211.69.198.241]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: 36S2qGZvb3Rlcl9odG09NDMyOjgx
X-CM-TRANSID: CMqowGBJ8EFutihPgdEIAA--.3939W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbikglHBU3kncO72wABsP
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] about page cache architecture of the dom0 and domUs in
 xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0867497771787897062=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0867497771787897062==
Content-Type: multipart/alternative; 
	boundary="----=_Part_67060_1092601857.1328068206356"

------=_Part_67060_1092601857.1328068206356
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
I encounter a problem that has puzzled me for a long time.On a Xen virtualization platform, some VMs ,whose virtual disks are image files ,are running in DomUs.Under this situation ,does the Dom0 cache the pages from the VMs?Does the filesystem in Dom0 see the VMs as general processes?
 
HXK
------=_Part_67060_1092601857.1328068206356
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV>I encounter a problem that has puzzled me for a long time.On a Xen virtualization platform, some VMs ,whose virtual disks&nbsp;are image files ,are running in DomUs.Under this situation ,does the Dom0 cache the pages from the VMs?Does the filesystem in Dom0 see the VMs as general processes?</DIV>
<DIV>&nbsp;</DIV>
<DIV>HXK</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_67060_1092601857.1328068206356--



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

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

--===============0867497771787897062==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 03:50:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 03:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsRD2-0000te-4q; Wed, 01 Feb 2012 03:50:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RsRD0-0000tZ-Px
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 03:50:11 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328068171!50567060!1
X-Originating-IP: [220.181.15.8]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gNjY3OA==\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjggPT4gNjY3OA==\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26102 invoked from network); 1 Feb 2012 03:49:32 -0000
Received: from m15-8.126.com (HELO m15-8.126.com) (220.181.15.8)
	by server-12.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 03:49:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=sEfW22IsYzR0FavC1m7shKURXovQUuSati
	nO15JIaX8=; b=U/Iq+JyZgU9frXTNWCsqzr3JyPr7O1F0ZAflbvjq+xjdg3VQEL
	DyCMH+UF7uNzFP5LCUcoJZgJiJuRVXT1yOb2IAZSYvdFQZw4vBrqv72IPf5oPzYa
	fV5UemKRXt5RecpbAfA1LoDXB31IyCPS7RfiAE2AoS9cjRnLbj1KNuXSM=
Received: from hxkhust ( [211.69.198.241] ) by ajax-webmail-wmsvr8
	(Coremail) ; Wed, 1 Feb 2012 11:50:06 +0800 (CST)
Date: Wed, 1 Feb 2012 11:50:06 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [211.69.198.241]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: 36S2qGZvb3Rlcl9odG09NDMyOjgx
X-CM-TRANSID: CMqowGBJ8EFutihPgdEIAA--.3939W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbikglHBU3kncO72wABsP
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] about page cache architecture of the dom0 and domUs in
 xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0867497771787897062=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0867497771787897062==
Content-Type: multipart/alternative; 
	boundary="----=_Part_67060_1092601857.1328068206356"

------=_Part_67060_1092601857.1328068206356
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
I encounter a problem that has puzzled me for a long time.On a Xen virtualization platform, some VMs ,whose virtual disks are image files ,are running in DomUs.Under this situation ,does the Dom0 cache the pages from the VMs?Does the filesystem in Dom0 see the VMs as general processes?
 
HXK
------=_Part_67060_1092601857.1328068206356
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV>I encounter a problem that has puzzled me for a long time.On a Xen virtualization platform, some VMs ,whose virtual disks&nbsp;are image files ,are running in DomUs.Under this situation ,does the Dom0 cache the pages from the VMs?Does the filesystem in Dom0 see the VMs as general processes?</DIV>
<DIV>&nbsp;</DIV>
<DIV>HXK</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_67060_1092601857.1328068206356--



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

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

--===============0867497771787897062==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 03:58:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 03: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.xensource.com>)
	id 1RsRKD-00012O-2t; Wed, 01 Feb 2012 03:57:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsRKB-00012I-Jc
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 03:57:35 +0000
Received: from [85.158.138.51:25751] by server-2.bemta-3.messagelabs.com id
	46/F1-24515-E28B82F4; Wed, 01 Feb 2012 03:57:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328068653!11494272!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22888 invoked from network); 1 Feb 2012 03:57:33 -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;
	1 Feb 2012 03:57:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,600,1320624000"; d="scan'208";a="10405087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 03:57:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 03:57:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsRK8-00040Y-Fx;
	Wed, 01 Feb 2012 03:57:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsRK8-0008P3-99;
	Wed, 01 Feb 2012 03:57:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11748-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 03:57:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11748: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      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-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          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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  6c9a73817770
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 715 lines long.)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 03:58:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 03: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.xensource.com>)
	id 1RsRKD-00012O-2t; Wed, 01 Feb 2012 03:57:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsRKB-00012I-Jc
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 03:57:35 +0000
Received: from [85.158.138.51:25751] by server-2.bemta-3.messagelabs.com id
	46/F1-24515-E28B82F4; Wed, 01 Feb 2012 03:57:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328068653!11494272!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22888 invoked from network); 1 Feb 2012 03:57:33 -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;
	1 Feb 2012 03:57:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,600,1320624000"; d="scan'208";a="10405087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 03:57:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 03:57:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsRK8-00040Y-Fx;
	Wed, 01 Feb 2012 03:57:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsRK8-0008P3-99;
	Wed, 01 Feb 2012 03:57:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11748-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 03:57:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11748: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      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-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          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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  6c9a73817770
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 715 lines long.)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2O-0001UR-1i; Wed, 01 Feb 2012 04:43:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2J-0001T9-2F
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328071382!13127940!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20785 invoked from network); 1 Feb 2012 04:43:04 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:43:04 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gtLt013489; Tue, 31 Jan 2012 20:42:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114gtGe013486;
	Tue, 31 Jan 2012 20:42:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 79ebe623f3bef4803ce20670642ea513c69712ea
Message-Id: <79ebe623f3bef4803ce2.1328071100@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:20 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 6 V2] libxl: helper function to send
	commands to	traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070813 28800
# Node ID 79ebe623f3bef4803ce20670642ea513c69712ea
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: helper function to send commands to traditional qemu

Introduce a helper function to send commands to traditional
qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
libxl__domain_save_device_model and libxl_domain_unpause have
been refactored to use this function.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Jan 31 20:33:33 2012 -0800
@@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__qemu_traditional_cmd(gc, domid, "continue");
             libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
@@ -349,6 +349,15 @@ out:
     return rc;
 }
 
+int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                const char *cmd)
+{
+    char *path = NULL;
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                          domid);
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -631,12 +640,9 @@ int libxl__domain_save_device_model(libx
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                    "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
     }
diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:33 2012 -0800
@@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
               libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
+_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Tue Jan 31 20:33:33 2012 -0800
@@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
         libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                         pcidev->bus, pcidev->dev, pcidev->func);
     }
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
-    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
+
+    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
     rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
                                       pci_ins_check, state);
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
@@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
     libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                     pcidev->bus, pcidev->dev, pcidev->func);
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
 
     /* Remove all functions at once atomically by only signalling
      * device-model for function 0 */
     if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
-        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
+        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
         if (libxl__wait_for_device_model(gc, domid, "pci-removed",
                                          NULL, NULL, NULL) < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2O-0001UR-1i; Wed, 01 Feb 2012 04:43:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2J-0001T9-2F
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328071382!13127940!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20785 invoked from network); 1 Feb 2012 04:43:04 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:43:04 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gtLt013489; Tue, 31 Jan 2012 20:42:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114gtGe013486;
	Tue, 31 Jan 2012 20:42:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 79ebe623f3bef4803ce20670642ea513c69712ea
Message-Id: <79ebe623f3bef4803ce2.1328071100@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:20 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 6 V2] libxl: helper function to send
	commands to	traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070813 28800
# Node ID 79ebe623f3bef4803ce20670642ea513c69712ea
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: helper function to send commands to traditional qemu

Introduce a helper function to send commands to traditional
qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
libxl__domain_save_device_model and libxl_domain_unpause have
been refactored to use this function.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Jan 31 20:33:33 2012 -0800
@@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__qemu_traditional_cmd(gc, domid, "continue");
             libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
@@ -349,6 +349,15 @@ out:
     return rc;
 }
 
+int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                const char *cmd)
+{
+    char *path = NULL;
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                          domid);
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -631,12 +640,9 @@ int libxl__domain_save_device_model(libx
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                    "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
     }
diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:33 2012 -0800
@@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
               libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
+_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
diff -r e2722b24dc09 -r 79ebe623f3be tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Tue Jan 31 20:33:33 2012 -0800
@@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
         libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                         pcidev->bus, pcidev->dev, pcidev->func);
     }
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
-    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
+
+    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
     rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
                                       pci_ins_check, state);
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
@@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
     libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                     pcidev->bus, pcidev->dev, pcidev->func);
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
 
     /* Remove all functions at once atomically by only signalling
      * device-model for function 0 */
     if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
-        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
+        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
         if (libxl__wait_for_device_model(gc, domid, "pci-removed",
                                          NULL, NULL, NULL) < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2Q-0001Uu-Fa; Wed, 01 Feb 2012 04:43:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2I-0001TA-Vx
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328071382!12028539!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 1 Feb 2012 04:43:04 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 04:43:04 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gusD013510; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guRG013507;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 77041ffdf5c73d91b12e8367d0199e8431dec813
Message-Id: <77041ffdf5c73d91b12e.1328071103@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:23 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6 V2] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 77041ffdf5c73d91b12e8367d0199e8431dec813
# Parent  3ca830009da79443bb445d983a34f5f78664cdf4
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 3ca830009da7 -r 77041ffdf5c7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -229,24 +229,38 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+/* From xc_resume.c ..
+ * Resuming execution of a domain after suspend can
+ * happen in one of two ways:
+ *  1. Resume with special return code.
+ *  2. Reset guest environment so it believes it is resumed in a new
+ *     domain context.
+ * (2) should be used only for guests which cannot handle the special
+ * new return code. (1) is always safe (but slower).
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r 3ca830009da7 -r 77041ffdf5c7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl.h	Tue Jan 31 20:33:34 2012 -0800
@@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r 3ca830009da7 -r 77041ffdf5c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 1);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 1);
     exit(-ERROR_FAIL);
 
  failed_badly:

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2Q-0001Uu-Fa; Wed, 01 Feb 2012 04:43:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2I-0001TA-Vx
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328071382!12028539!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 1 Feb 2012 04:43:04 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 04:43:04 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gusD013510; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guRG013507;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 77041ffdf5c73d91b12e8367d0199e8431dec813
Message-Id: <77041ffdf5c73d91b12e.1328071103@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:23 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6 V2] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 77041ffdf5c73d91b12e8367d0199e8431dec813
# Parent  3ca830009da79443bb445d983a34f5f78664cdf4
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 3ca830009da7 -r 77041ffdf5c7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -229,24 +229,38 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+/* From xc_resume.c ..
+ * Resuming execution of a domain after suspend can
+ * happen in one of two ways:
+ *  1. Resume with special return code.
+ *  2. Reset guest environment so it believes it is resumed in a new
+ *     domain context.
+ * (2) should be used only for guests which cannot handle the special
+ * new return code. (1) is always safe (but slower).
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r 3ca830009da7 -r 77041ffdf5c7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl.h	Tue Jan 31 20:33:34 2012 -0800
@@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r 3ca830009da7 -r 77041ffdf5c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 1);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 1);
     exit(-ERROR_FAIL);
 
  failed_badly:

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2H-0001TQ-NB; Wed, 01 Feb 2012 04:43:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2D-0001T7-In
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:06 +0000
Received: from [85.158.138.51:6939] by server-10.bemta-3.messagelabs.com id
	03/C3-20948-8D2C82F4; Wed, 01 Feb 2012 04:43:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328071382!9634641!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6435 invoked from network); 1 Feb 2012 04:43:03 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 04:43:03 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gu3u013503; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guZF013500;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3ca830009da79443bb445d983a34f5f78664cdf4
Message-Id: <3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:22 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
	QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070813 28800
# Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
# Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
@@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0, fd2 = -1;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
+        if (fd2 < 0) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "Unable to create a QEMU save file\n");
+            return ERROR_FAIL;
+        }
+        /* Save DM state into fd2 */
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        if (ret)
+            unlink(filename);
+        close(fd2);
+        fd2 = -1;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto suspend_dm;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto suspend_dm;
             }
         }
 
@@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ suspend_dm:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
@@ -638,32 +704,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
-        if (ret)
-            goto out;
-        close(fd2);
-        fd2 = -1;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:33 2012 -0800
@@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Tue Jan 31 20:33:33 2012 -0800
@@ -878,6 +878,38 @@ out:
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2H-0001TQ-NB; Wed, 01 Feb 2012 04:43:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2D-0001T7-In
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:06 +0000
Received: from [85.158.138.51:6939] by server-10.bemta-3.messagelabs.com id
	03/C3-20948-8D2C82F4; Wed, 01 Feb 2012 04:43:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328071382!9634641!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6435 invoked from network); 1 Feb 2012 04:43:03 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 04:43:03 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gu3u013503; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guZF013500;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3ca830009da79443bb445d983a34f5f78664cdf4
Message-Id: <3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:22 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
	QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070813 28800
# Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
# Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
@@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0, fd2 = -1;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
+        if (fd2 < 0) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "Unable to create a QEMU save file\n");
+            return ERROR_FAIL;
+        }
+        /* Save DM state into fd2 */
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        if (ret)
+            unlink(filename);
+        close(fd2);
+        fd2 = -1;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto suspend_dm;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto suspend_dm;
             }
         }
 
@@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ suspend_dm:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
@@ -638,32 +704,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
-        if (ret)
-            goto out;
-        close(fd2);
-        fd2 = -1;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:33 2012 -0800
@@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Tue Jan 31 20:33:33 2012 -0800
@@ -878,6 +878,38 @@ out:
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04: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.xensource.com>)
	id 1RsS2G-0001TJ-08; Wed, 01 Feb 2012 04:43:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2D-0001T6-IM
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:05 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328071332!52535102!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19497 invoked from network); 1 Feb 2012 04:42:14 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:42:14 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gtWU013482; Tue, 31 Jan 2012 20:42:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114gtG3013479;
	Tue, 31 Jan 2012 20:42:55 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:19 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 6 V2] libxl: refactor suspend/resume code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series refactors the suspend/resume code to minimize
Remus specific code in libxl. There are a couple of trivial bug
fixes too.

Changes since the previous version:

1. migrate code is refactored as save_config , create child,
   do_preamble instead of coaelscing them all into one single
   function.
2. More documentation for suspend_cancel parameter in domain_resume
3. Minor nits


Shriram

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04: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.xensource.com>)
	id 1RsS2G-0001TJ-08; Wed, 01 Feb 2012 04:43:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2D-0001T6-IM
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:05 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328071332!52535102!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19497 invoked from network); 1 Feb 2012 04:42:14 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:42:14 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gtWU013482; Tue, 31 Jan 2012 20:42:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114gtG3013479;
	Tue, 31 Jan 2012 20:42:55 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:19 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 6 V2] libxl: refactor suspend/resume code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series refactors the suspend/resume code to minimize
Remus specific code in libxl. There are a couple of trivial bug
fixes too.

Changes since the previous version:

1. migrate code is refactored as save_config , create child,
   do_preamble instead of coaelscing them all into one single
   function.
2. More documentation for suspend_cancel parameter in domain_resume
3. Minor nits


Shriram

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2L-0001U5-Ru; Wed, 01 Feb 2012 04:43:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2I-0001T8-Q2
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328071382!1946154!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7935 invoked from network); 1 Feb 2012 04:43:04 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:43:04 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gtYs013496; Tue, 31 Jan 2012 20:42:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114gtfV013493;
	Tue, 31 Jan 2012 20:42:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9f0a67bd54db89a23078913db578df72c5dba2e3
Message-Id: <9f0a67bd54db89a23078.1328071101@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:21 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 6 V2] libxl: bugfix: create_domain() return
	to caller if	!daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070813 28800
# Node ID 9f0a67bd54db89a23078913db578df72c5dba2e3
# Parent  79ebe623f3bef4803ce20670642ea513c69712ea
libxl: bugfix: create_domain() return to caller if !daemonize

Currently the create_domain function does not honor
the daemonize flag properly. It exits irrespective of
the value of the flag. This patch fixes the issue.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 79ebe623f3be -r 9f0a67bd54db tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:33 2012 -0800
@@ -1814,7 +1814,7 @@ waitpid_out:
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:43:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:43:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS2L-0001U5-Ru; Wed, 01 Feb 2012 04:43:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS2I-0001T8-Q2
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:43:11 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328071382!1946154!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7935 invoked from network); 1 Feb 2012 04:43:04 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:43:04 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gtYs013496; Tue, 31 Jan 2012 20:42:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114gtfV013493;
	Tue, 31 Jan 2012 20:42:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9f0a67bd54db89a23078913db578df72c5dba2e3
Message-Id: <9f0a67bd54db89a23078.1328071101@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:21 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 6 V2] libxl: bugfix: create_domain() return
	to caller if	!daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070813 28800
# Node ID 9f0a67bd54db89a23078913db578df72c5dba2e3
# Parent  79ebe623f3bef4803ce20670642ea513c69712ea
libxl: bugfix: create_domain() return to caller if !daemonize

Currently the create_domain function does not honor
the daemonize flag properly. It exits irrespective of
the value of the flag. This patch fixes the issue.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 79ebe623f3be -r 9f0a67bd54db tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:33 2012 -0800
@@ -1814,7 +1814,7 @@ waitpid_out:
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:45:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04: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.xensource.com>)
	id 1RsS4N-0001sB-JF; Wed, 01 Feb 2012 04:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS4K-0001rc-1g
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:45:16 +0000
Received: from [85.158.138.51:5496] by server-1.bemta-3.messagelabs.com id
	E0/5E-09565-B53C82F4; Wed, 01 Feb 2012 04:45:15 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328071510!11467718!2
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25921 invoked from network); 1 Feb 2012 04:45:13 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:45:13 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gut6013517; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guE9013514;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 68ca0e9ea59c4c67d3a10ce968cca7aff50184fe
Message-Id: <68ca0e9ea59c4c67d3a1.1328071104@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:24 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 5 of 6 V2] libxl: refactor migrate_domain and
	generalize	migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 68ca0e9ea59c4c67d3a10ce968cca7aff50184fe
# Parent  77041ffdf5c73d91b12e8367d0199e8431dec813
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 77041ffdf5c7 -r 68ca0e9ea59c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2616,53 +2653,17 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
+                                uint8_t *config_data, int config_len,
+                                const char *rune)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
-    uint8_t *config_data;
-    int config_len;
-
-    save_domain_core_begin(domain_spec, override_config_file,
-                           &config_data, &config_len);
-
-    if (!config_len) {
-        fprintf(stderr, "No config file stored for running domain and "
-                "none supplied - cannot migrate.\n");
+    int rc = 0;
+
+    if (send_fd < 0 || recv_fd < 0) {
+        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
     rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
@@ -2675,6 +2676,34 @@ static void migrate_domain(const char *d
     save_domain_core_writeconfig(send_fd, "migration stream",
                                  config_data, config_len);
 
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    pid_t child = -1;
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    uint8_t *config_data;
+    int config_len;
+
+    save_domain_core_begin(domain_spec, override_config_file,
+                           &config_data, &config_len);
+
+    if (!config_len) {
+        fprintf(stderr, "No config file stored for running domain and "
+                "none supplied - cannot migrate.\n");
+        exit(1);
+    }
+
+    child = create_migration_child(rune, &send_fd, &recv_fd);
+
+    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                        rune);
+
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2798,7 +2827,8 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2810,7 +2840,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2822,7 +2852,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2836,13 +2866,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2861,7 +2891,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2869,7 +2899,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2887,7 +2917,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -2983,7 +3013,9 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    STDOUT_FILENO, STDIN_FILENO);
+
     return 0;
 }
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:45:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04: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.xensource.com>)
	id 1RsS4N-0001sB-JF; Wed, 01 Feb 2012 04:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS4K-0001rc-1g
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:45:16 +0000
Received: from [85.158.138.51:5496] by server-1.bemta-3.messagelabs.com id
	E0/5E-09565-B53C82F4; Wed, 01 Feb 2012 04:45:15 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328071510!11467718!2
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25921 invoked from network); 1 Feb 2012 04:45:13 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:45:13 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114gut6013517; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guE9013514;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 68ca0e9ea59c4c67d3a10ce968cca7aff50184fe
Message-Id: <68ca0e9ea59c4c67d3a1.1328071104@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:24 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 5 of 6 V2] libxl: refactor migrate_domain and
	generalize	migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 68ca0e9ea59c4c67d3a10ce968cca7aff50184fe
# Parent  77041ffdf5c73d91b12e8367d0199e8431dec813
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 77041ffdf5c7 -r 68ca0e9ea59c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2616,53 +2653,17 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
+                                uint8_t *config_data, int config_len,
+                                const char *rune)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
-    uint8_t *config_data;
-    int config_len;
-
-    save_domain_core_begin(domain_spec, override_config_file,
-                           &config_data, &config_len);
-
-    if (!config_len) {
-        fprintf(stderr, "No config file stored for running domain and "
-                "none supplied - cannot migrate.\n");
+    int rc = 0;
+
+    if (send_fd < 0 || recv_fd < 0) {
+        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
     rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
@@ -2675,6 +2676,34 @@ static void migrate_domain(const char *d
     save_domain_core_writeconfig(send_fd, "migration stream",
                                  config_data, config_len);
 
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    pid_t child = -1;
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    uint8_t *config_data;
+    int config_len;
+
+    save_domain_core_begin(domain_spec, override_config_file,
+                           &config_data, &config_len);
+
+    if (!config_len) {
+        fprintf(stderr, "No config file stored for running domain and "
+                "none supplied - cannot migrate.\n");
+        exit(1);
+    }
+
+    child = create_migration_child(rune, &send_fd, &recv_fd);
+
+    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                        rune);
+
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2798,7 +2827,8 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2810,7 +2840,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2822,7 +2852,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2836,13 +2866,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2861,7 +2891,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2869,7 +2899,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2887,7 +2917,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -2983,7 +3013,9 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    STDOUT_FILENO, STDIN_FILENO);
+
     return 0;
 }
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:45:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS4K-0001rg-JE; Wed, 01 Feb 2012 04:45:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS4I-0001rT-JF
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:45:14 +0000
Received: from [85.158.138.51:11825] by server-8.bemta-3.messagelabs.com id
	E5/A3-31878-953C82F4; Wed, 01 Feb 2012 04:45:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328071510!11467718!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25911 invoked from network); 1 Feb 2012 04:45:12 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:45:12 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114guil013524; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guqE013521;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 545f88c2bc73b063a5d0e7adbd95baed4d93790f
Message-Id: <545f88c2bc73b063a5d0.1328071105@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:25 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 6 of 6 V2] libxl: resume instead of unpause on
	xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 545f88c2bc73b063a5d0e7adbd95baed4d93790f
# Parent  68ca0e9ea59c4c67d3a10ce968cca7aff50184fe
libxl: resume instead of unpause on xl save -c

The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
So call libxl_domain_resume instead of libxl_domain_unpause, when taking
a checkpoint of the domain (using xl save -c).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 68ca0e9ea59c -r 545f88c2bc73 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
     close(fd);
 
     if (checkpoint)
-        libxl_domain_unpause(ctx, domid);
+        libxl_domain_resume(ctx, domid, 1);
     else
         libxl_domain_destroy(ctx, domid);
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:45:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS4K-0001rg-JE; Wed, 01 Feb 2012 04:45:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS4I-0001rT-JF
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:45:14 +0000
Received: from [85.158.138.51:11825] by server-8.bemta-3.messagelabs.com id
	E5/A3-31878-953C82F4; Wed, 01 Feb 2012 04:45:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328071510!11467718!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25911 invoked from network); 1 Feb 2012 04:45:12 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:45:12 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114guil013524; Tue, 31 Jan 2012 20:42:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114guqE013521;
	Tue, 31 Jan 2012 20:42:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 545f88c2bc73b063a5d0e7adbd95baed4d93790f
Message-Id: <545f88c2bc73b063a5d0.1328071105@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:38:25 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 6 of 6 V2] libxl: resume instead of unpause on
	xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 545f88c2bc73b063a5d0e7adbd95baed4d93790f
# Parent  68ca0e9ea59c4c67d3a10ce968cca7aff50184fe
libxl: resume instead of unpause on xl save -c

The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
So call libxl_domain_resume instead of libxl_domain_unpause, when taking
a checkpoint of the domain (using xl save -c).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 68ca0e9ea59c -r 545f88c2bc73 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
     close(fd);
 
     if (checkpoint)
-        libxl_domain_unpause(ctx, domid);
+        libxl_domain_resume(ctx, domid, 1);
     else
         libxl_domain_destroy(ctx, domid);
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS6D-0002Ew-4e; Wed, 01 Feb 2012 04:47:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS68-0002Ch-9Y
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:47:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328071620!10860226!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2641 invoked from network); 1 Feb 2012 04:47:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:47:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114kt3J013709; Tue, 31 Jan 2012 20:46:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114ktA1013706;
	Tue, 31 Jan 2012 20:46:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2aa138177f5ef6aa44e6136dd1913441c99aa4b5
Message-Id: <2aa138177f5ef6aa44e6.1328071452@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:44:12 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V2] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 2aa138177f5ef6aa44e6136dd1913441c99aa4b5
# Parent  545f88c2bc73b063a5d0e7adbd95baed4d93790f
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.
 * Introduce a new public API, libxl_domain_remus_start (currently a stub)
   that sets up the network and disk buffer and initiates continuous
   checkpointing.

 * Future patches will augument these callbacks/functions with more functionalities
   like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -480,6 +480,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = ERROR_INVAL;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
@@ -489,7 +524,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl.h	Tue Jan 31 20:33:34 2012 -0800
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:34 2012 -0800
@@ -404,6 +404,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_
     return 1;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        /* save_callbacks:
+         * suspend - called after expiration of checkpoint interval,
+         *           to *suspend* the domain.
+         *
+         * postcopy - called after the domain's dirty pages have been
+         *            copied into an output buffer. We *resume* the domain
+         *            & the device model, return to the caller. Caller then
+         *            flushes the output buffer, while the domain continues to run.
+         *
+         * checkpoint - called after the memory checkpoint has been flushed out
+         *              into the network. Send the saved device state, *wait*
+         *              for checkpoint ack and *release* the network buffer (TBD).
+         *              Then *sleep* for the checkpoint interval.
+         */
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:34 2012 -0800
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Tue Jan 31 20:33:34 2012 -0800
@@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS6A-0002E5-63; Wed, 01 Feb 2012 04:47:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS67-0002CU-Hl
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:47:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328071619!5775345!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23353 invoked from network); 1 Feb 2012 04:47:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:47:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114ktRs013702; Tue, 31 Jan 2012 20:46:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114ktFk013699;
	Tue, 31 Jan 2012 20:46:55 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:44:11 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V2] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series introduces a basic framework to
incorporate Remus into the libxl toolstack. The only functionality
currently implemented is memory checkpointing.

These patches depend on Version 2 of 
"libxl: refactor suspend/resume code" patch series.

Changes since previous version:
 * Move libxl_domain_remus_start into the save_callbacks implementation patch
 * return proper error codes instead of -1.
 * Add documentation to docs/man/xl.pod.1

Shriram


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS6D-0002Ew-4e; Wed, 01 Feb 2012 04:47:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS68-0002Ch-9Y
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:47:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328071620!10860226!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2641 invoked from network); 1 Feb 2012 04:47:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:47:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114kt3J013709; Tue, 31 Jan 2012 20:46:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114ktA1013706;
	Tue, 31 Jan 2012 20:46:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2aa138177f5ef6aa44e6136dd1913441c99aa4b5
Message-Id: <2aa138177f5ef6aa44e6.1328071452@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:44:12 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V2] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID 2aa138177f5ef6aa44e6136dd1913441c99aa4b5
# Parent  545f88c2bc73b063a5d0e7adbd95baed4d93790f
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.
 * Introduce a new public API, libxl_domain_remus_start (currently a stub)
   that sets up the network and disk buffer and initiates continuous
   checkpointing.

 * Future patches will augument these callbacks/functions with more functionalities
   like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -480,6 +480,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = ERROR_INVAL;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
@@ -489,7 +524,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl.h	Tue Jan 31 20:33:34 2012 -0800
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:34 2012 -0800
@@ -404,6 +404,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_
     return 1;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        /* save_callbacks:
+         * suspend - called after expiration of checkpoint interval,
+         *           to *suspend* the domain.
+         *
+         * postcopy - called after the domain's dirty pages have been
+         *            copied into an output buffer. We *resume* the domain
+         *            & the device model, return to the caller. Caller then
+         *            flushes the output buffer, while the domain continues to run.
+         *
+         * checkpoint - called after the memory checkpoint has been flushed out
+         *              into the network. Send the saved device state, *wait*
+         *              for checkpoint ack and *release* the network buffer (TBD).
+         *              Then *sleep* for the checkpoint interval.
+         */
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Tue Jan 31 20:33:34 2012 -0800
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Tue Jan 31 20:33:34 2012 -0800
@@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 04:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 04:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsS6A-0002E5-63; Wed, 01 Feb 2012 04:47:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsS67-0002CU-Hl
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:47:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328071619!5775345!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23353 invoked from network); 1 Feb 2012 04:47:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 04:47:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114ktRs013702; Tue, 31 Jan 2012 20:46:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114ktFk013699;
	Tue, 31 Jan 2012 20:46:55 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:44:11 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V2] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series introduces a basic framework to
incorporate Remus into the libxl toolstack. The only functionality
currently implemented is memory checkpointing.

These patches depend on Version 2 of 
"libxl: refactor suspend/resume code" patch series.

Changes since previous version:
 * Move libxl_domain_remus_start into the save_callbacks implementation patch
 * return proper error codes instead of -1.
 * Add documentation to docs/man/xl.pod.1

Shriram


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 05:09:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 05: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.xensource.com>)
	id 1RsSRK-0003E6-MK; Wed, 01 Feb 2012 05:09:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsSRH-0003E1-Vh
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 05:09:00 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328071620!12574998!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22110 invoked from network); 1 Feb 2012 04:47:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 04:47:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114kt5O013716; Tue, 31 Jan 2012 20:46:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114kt37013713;
	Tue, 31 Jan 2012 20:46:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba
Message-Id: <cf47997255f4a895ce6a.1328071453@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:44:13 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V2] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba
# Parent  2aa138177f5ef6aa44e6136dd1913441c99aa4b5
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 2aa138177f5e -r cf47997255f4 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Jan 31 20:33:34 2012 -0800
+++ b/docs/man/xl.pod.1	Tue Jan 31 20:33:34 2012 -0800
@@ -348,6 +348,39 @@ Send <config> instead of config file fro
 
 =back
 
+=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
+
+Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
+between the two hosts.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-i> I<MS>
+
+Checkpoint domain memory every MS milliseconds (default 200ms).
+
+=item B<-b>
+
+Replicate memory checkpoints to /dev/null (blackhole).
+
+=item B<-u>
+
+Disable memory checkpoint compression.
+
+=item B<-s> I<sshcommand>
+
+Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
+<host> instead of ssh <host> xl migrate-receive -r [-e].
+
+=item B<-e>
+
+On the new host, do not wait in the background (on <host>) for the death of the
+domain. See the corresponding option of the I<create> subcommand.
+
+=back
+
 =item B<pause> I<domain-id>
 
 Pause a domain.  When in a paused state the domain will still consume
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl.h	Tue Jan 31 20:33:34 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2828,7 +2828,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 send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    STDOUT_FILENO, STDIN_FILENO);
+                    STDOUT_FILENO, STDIN_FILENO,
+                    remus);
 
     return 0;
 }
@@ -5951,6 +5990,106 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+    uint8_t *config_data;
+    int config_len;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    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");
+            exit(-1);
+        }
+    } else {
+
+        /*
+         * TODO: change this to plain TCP socket based channel
+         * instead of SSH. For both live-migration and Remus.
+         */
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        child = create_migration_child(rune, &send_fd, &recv_fd);
+
+        migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                            rune);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Tue Jan 31 20:33:34 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r [-e]\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 05:09:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 05: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.xensource.com>)
	id 1RsSRK-0003E6-MK; Wed, 01 Feb 2012 05:09:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsSRH-0003E1-Vh
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 05:09:00 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328071620!12574998!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22110 invoked from network); 1 Feb 2012 04:47:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 04:47:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q114kt5O013716; Tue, 31 Jan 2012 20:46:55 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q114kt37013713;
	Tue, 31 Jan 2012 20:46:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba
Message-Id: <cf47997255f4a895ce6a.1328071453@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
References: <patchbomb.1328071451@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 31 Jan 2012 20:44:13 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V2] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328070814 28800
# Node ID cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba
# Parent  2aa138177f5ef6aa44e6136dd1913441c99aa4b5
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 2aa138177f5e -r cf47997255f4 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Jan 31 20:33:34 2012 -0800
+++ b/docs/man/xl.pod.1	Tue Jan 31 20:33:34 2012 -0800
@@ -348,6 +348,39 @@ Send <config> instead of config file fro
 
 =back
 
+=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
+
+Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
+between the two hosts.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-i> I<MS>
+
+Checkpoint domain memory every MS milliseconds (default 200ms).
+
+=item B<-b>
+
+Replicate memory checkpoints to /dev/null (blackhole).
+
+=item B<-u>
+
+Disable memory checkpoint compression.
+
+=item B<-s> I<sshcommand>
+
+Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
+<host> instead of ssh <host> xl migrate-receive -r [-e].
+
+=item B<-e>
+
+On the new host, do not wait in the background (on <host>) for the death of the
+domain. See the corresponding option of the I<create> subcommand.
+
+=back
+
 =item B<pause> I<domain-id>
 
 Pause a domain.  When in a paused state the domain will still consume
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl.h	Tue Jan 31 20:33:34 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 20:33:34 2012 -0800
@@ -2828,7 +2828,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 send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    STDOUT_FILENO, STDIN_FILENO);
+                    STDOUT_FILENO, STDIN_FILENO,
+                    remus);
 
     return 0;
 }
@@ -5951,6 +5990,106 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+    uint8_t *config_data;
+    int config_len;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    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");
+            exit(-1);
+        }
+    } else {
+
+        /*
+         * TODO: change this to plain TCP socket based channel
+         * instead of SSH. For both live-migration and Remus.
+         */
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        child = create_migration_child(rune, &send_fd, &recv_fd);
+
+        migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                            rune);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Tue Jan 31 20:33:34 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Tue Jan 31 20:33:34 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r [-e]\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 05:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 05: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.xensource.com>)
	id 1RsT7X-0003lp-EA; Wed, 01 Feb 2012 05:52:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsT7W-0003lk-7H
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 05:52:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328075552!12657805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24324 invoked from network); 1 Feb 2012 05:52:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 05:52:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,600,1320624000"; d="scan'208";a="10405938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 05:52:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 05:52:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsT7O-0004mv-NK;
	Wed, 01 Feb 2012 05:52:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsT7O-0002Am-La;
	Wed, 01 Feb 2012 05:52:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11749-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 05:52:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11749: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11749 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 05:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 05: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.xensource.com>)
	id 1RsT7X-0003lp-EA; Wed, 01 Feb 2012 05:52:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsT7W-0003lk-7H
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 05:52:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328075552!12657805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24324 invoked from network); 1 Feb 2012 05:52:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 05:52:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,600,1320624000"; d="scan'208";a="10405938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 05:52:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 05:52:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsT7O-0004mv-NK;
	Wed, 01 Feb 2012 05:52:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsT7O-0002Am-La;
	Wed, 01 Feb 2012 05:52:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11749-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 05:52:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11749: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11749 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 06:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 06: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.xensource.com>)
	id 1RsTgR-0004Dl-PE; Wed, 01 Feb 2012 06:28:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1RsTgP-0004Dg-OL
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 06:28:42 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328077710!13220028!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10465 invoked from network); 1 Feb 2012 06:28:32 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 06:28:32 -0000
Received: by qcsp15 with SMTP id p15so3473091qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 22:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=8CTOwH0dkjgYtIdUEYzCpxP+IAFnckfVwJjQM4ku4f8=;
	b=E4ueHTjGdOpjcupWRv9dc9qz6YpzZUki07vepOdR/Exl8v4+AX3392BoqoFespA0IK
	qa5nC5BtYa40PK7zl7aOw5LsVBqevD9GMBcfLBqUyePHO5BtCcT9XF9arwOblVKVvx+K
	GCSiYbi6mpWKeIbHEh2CiRD4llXMUoCIAz6E8=
MIME-Version: 1.0
Received: by 10.224.179.137 with SMTP id bq9mr30929997qab.53.1328077709692;
	Tue, 31 Jan 2012 22:28:29 -0800 (PST)
Received: by 10.229.239.149 with HTTP; Tue, 31 Jan 2012 22:28:29 -0800 (PST)
In-Reply-To: <mailman.2163.1328075559.1471.xen-devel@lists.xensource.com>
References: <mailman.2163.1328075559.1471.xen-devel@lists.xensource.com>
Date: Wed, 1 Feb 2012 14:28:29 +0800
Message-ID: <CA+ePHTCggCq4tQbCtt6LUgFU-7NSVDHk+JQMRwO=ykbxGuLK6A@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3167636507460871122=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3167636507460871122==
Content-Type: multipart/alternative; boundary=20cf30363f4b1ecd2e04b7e1308d

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

On Wed, Feb 1, 2012 at 1:52 PM, <xen-devel-request@lists.xensource.com>wrote:

> Send Xen-devel mailing list submissions to
>        xen-devel@lists.xensource.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.xensource.com/mailman/listinfo/xen-devel
> or, via email, send a message with subject or body 'help' to
>        xen-devel-request@lists.xensource.com
>
> You can reach the person managing the list at
>        xen-devel-owner@lists.xensource.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xen-devel digest..."
>
> Today's Topics:
>
>   1. [PATCH 0 of 2 V2] libxl - Remus support (rshriram@cs.ubc.ca)
>   2. [PATCH 1 of 2 V2] libxl: Remus -  suspend/postflush/commit
>      callbacks (rshriram@cs.ubc.ca)
>   3. [PATCH 2 of 2 V2] libxl: Remus - xl remus command
>      (rshriram@cs.ubc.ca)
>   4. [linux test] 11749: regressions - FAIL (xen.org)
>
>
> ---------- Forwarded message ----------
> From: rshriram@cs.ubc.ca
> To: xen-devel@lists.xensource.com
> Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
> Date: Tue, 31 Jan 2012 20:44:11 -0800
> Subject: [Xen-devel] [PATCH 0 of 2 V2] libxl - Remus support
> This patch series introduces a basic framework to
> incorporate Remus into the libxl toolstack. The only functionality
> currently implemented is memory checkpointing.
>
> These patches depend on Version 2 of
> "libxl: refactor suspend/resume code" patch series.
>
> Changes since previous version:
>  * Move libxl_domain_remus_start into the save_callbacks implementation
> patch
>  * return proper error codes instead of -1.
>  * Add documentation to docs/man/xl.pod.1
>
> Shriram
>
> test for replying to the sender. Sorry for any trouble with you.
>
>
>
> ---------- Forwarded message ----------
> From: rshriram@cs.ubc.ca
> To: xen-devel@lists.xensource.com
> Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
> Date: Tue, 31 Jan 2012 20:44:12 -0800
> Subject: [Xen-devel] [PATCH 1 of 2 V2] libxl: Remus -
> suspend/postflush/commit callbacks
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328070814 28800
> # Node ID 2aa138177f5ef6aa44e6136dd1913441c99aa4b5
> # Parent  545f88c2bc73b063a5d0e7adbd95baed4d93790f
> libxl: Remus - suspend/postflush/commit callbacks
>
>  * Add libxl callback functions for Remus checkpoint suspend, postflush
>   (aka resume) and checkpoint commit callbacks.
>  * suspend callback is a stub that just bounces off
>   libxl__domain_suspend_common_callback - which suspends the domain and
>   saves the devices model state to a file.
>  * resume callback currently just resumes the domain (and the device
> model).
>  * commit callback just writes out the saved device model state to the
>   network and sleeps for the checkpoint interval.
>  * Introduce a new public API, libxl_domain_remus_start (currently a stub)
>   that sets up the network and disk buffer and initiates continuous
>   checkpointing.
>
>  * Future patches will augument these callbacks/functions with more
> functionalities
>   like issuing network buffer plug/unplug commands, disk checkpoint
> commands, etc.
>
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c       Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl.c       Tue Jan 31 20:33:34 2012 -0800
> @@ -480,6 +480,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
>     return ptr;
>  }
>
> +/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info
> *info,
> +                             uint32_t domid, int send_fd, int recv_fd)
> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d",
> domid);
> +        rc = ERROR_INVAL;
> +        goto remus_fail;
> +    }
> +
> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> +
> +    /* Point of no return */
> +    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live
> */ 1,
> +                                      /* debug */ 0, info);
> +
> +    /*
> +     * With Remus, if we reach this point, it means either
> +     * backup died or some network error occurred preventing us
> +     * from sending checkpoints.
> +     */
> +
> +    /* TBD: Remus cleanup - i.e. detach qdisc, release other
> +     * resources.
> +     */
> + remus_fail:
> +    GC_FREE;
> +    return rc;
> +}
> +
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                          uint32_t domid, int fd)
>  {
> @@ -489,7 +524,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
>     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
>     int rc = 0;
>
> -    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
> +    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
> +                                      /* No Remus */ NULL);
> +
>     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
>         rc = libxl__domain_save_device_model(gc, domid, fd);
>     GC_FREE;
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h       Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl.h       Tue Jan 31 20:33:34 2012 -0800
> @@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config
> *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config
> *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int
> restore_fd);
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info
> *info,
> +                             uint32_t domid, int send_fd, int recv_fd);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                           uint32_t domid, int fd);
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int
> suspend_cancel);
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl_dom.c   Tue Jan 31 20:33:34 2012 -0800
> @@ -404,6 +404,8 @@ struct suspendinfo {
>     int hvm;
>     unsigned int flags;
>     int guest_responded;
> +    int save_fd; /* Migration stream fd (for Remus) */
> +    int interval; /* checkpoint interval (for Remus) */
>  };
>
>  static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid,
> unsigned int enable, void *data)
> @@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_
>     return 1;
>  }
>
> +static int libxl__remus_domain_suspend_callback(void *data)
> +{
> +    /* TODO: Issue disk and network checkpoint reqs. */
> +    return libxl__domain_suspend_common_callback(data);
> +}
> +
> +static int libxl__remus_domain_resume_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
> +
> +    /* Resumes the domain and the device model */
> +    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
> +        return 0;
> +
> +    /* TODO: Deal with disk. Start a new network output buffer */
> +    return 1;
> +}
> +
> +static int libxl__remus_domain_checkpoint_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +
> +    /* This would go into tailbuf. */
> +    if (si->hvm &&
> +        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
> +        return 0;
> +
> +    /* TODO: Wait for disk and memory ack, release network buffer */
> +    usleep(si->interval * 1000);
> +    return 1;
> +}
> +
>  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                  libxl_domain_type type,
> -                                 int live, int debug)
> +                                 int live, int debug,
> +                                 const libxl_domain_remus_info *r_info)
>  {
>     libxl_ctx *ctx = libxl__gc_owner(gc);
>     int flags;
> @@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__
>         return ERROR_INVAL;
>     }
>
> +    memset(&si, 0, sizeof(si));
>     flags = (live) ? XCFLAGS_LIVE : 0
>           | (debug) ? XCFLAGS_DEBUG : 0
>           | (hvm) ? XCFLAGS_HVM : 0;
>
> +    if (r_info != NULL) {
> +        si.interval = r_info->interval;
> +        if (r_info->compression)
> +            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
> +        si.save_fd = fd;
> +    }
> +    else
> +        si.save_fd = -1;
> +
>     si.domid = domid;
>     si.flags = flags;
>     si.hvm = hvm;
> @@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
>     }
>
>     memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        /* save_callbacks:
> +         * suspend - called after expiration of checkpoint interval,
> +         *           to *suspend* the domain.
> +         *
> +         * postcopy - called after the domain's dirty pages have been
> +         *            copied into an output buffer. We *resume* the domain
> +         *            & the device model, return to the caller. Caller
> then
> +         *            flushes the output buffer, while the domain
> continues to run.
> +         *
> +         * checkpoint - called after the memory checkpoint has been
> flushed out
> +         *              into the network. Send the saved device state,
> *wait*
> +         *              for checkpoint ack and *release* the network
> buffer (TBD).
> +         *              Then *sleep* for the checkpoint interval.
> +         */
> +        callbacks.suspend = libxl__remus_domain_suspend_callback;
> +        callbacks.postcopy = libxl__remus_domain_resume_callback;
> +        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
> +    } else
> +        callbacks.suspend = libxl__domain_suspend_common_callback;
> +
>     callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
>     callbacks.data = &si;
>
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl_internal.h      Tue Jan 31 20:33:34 2012 -0800
> @@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
>                                          int fd);
>  _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid,
> int fd,
>                                          libxl_domain_type type,
> -                                         int live, int debug);
> +                                         int live, int debug,
> +                                         const libxl_domain_remus_info
> *r_info);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t
> domid);
>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t
> domid);
>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t
> domid);
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl       Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl_types.idl       Tue Jan 31 20:33:34 2012 -0800
> @@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf",
>     ("extratime", integer),
>     ("weight", integer),
>     ], dispose_fn=None)
> +
> +libxl_domain_remus_info = Struct("domain_remus_info",[
> +    ("interval",     integer),
> +    ("blackhole",    bool),
> +    ("compression",  bool),
> +    ])
>
>
>
>
> ---------- Forwarded message ----------
> From: rshriram@cs.ubc.ca
> To: xen-devel@lists.xensource.com
> Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
> Date: Tue, 31 Jan 2012 20:44:13 -0800
> Subject: [Xen-devel] [PATCH 2 of 2 V2] libxl: Remus - xl remus command
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328070814 28800
> # Node ID cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba
> # Parent  2aa138177f5ef6aa44e6136dd1913441c99aa4b5
> libxl: Remus - xl remus command
>
> xl remus acts as a frontend to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication is
>   supported. Support for disk checkpointing and network buffering will
>   be added in future.
>  * Replication is done over ssh connection currently (like live migration
>   with xl). Future versions will have an option to use simple tcp socket
>   based replication channel (for both Remus & live migration).
>
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> diff -r 2aa138177f5e -r cf47997255f4 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800
> +++ b/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800
> @@ -348,6 +348,39 @@ Send <config> instead of config file fro
>
>  =back
>
> +=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> +
> +Enable Remus HA for domain. By default B<xl> relies on ssh as a transport
> mechanism
> +between the two hosts.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-i> I<MS>
> +
> +Checkpoint domain memory every MS milliseconds (default 200ms).
> +
> +=item B<-b>
> +
> +Replicate memory checkpoints to /dev/null (blackhole).
> +
> +=item B<-u>
> +
> +Disable memory checkpoint compression.
> +
> +=item B<-s> I<sshcommand>
> +
> +Use <sshcommand> instead of ssh.  String will be passed to sh. If empty,
> run
> +<host> instead of ssh <host> xl migrate-receive -r [-e].
> +
> +=item B<-e>
> +
> +On the new host, do not wait in the background (on <host>) for the death
> of the
> +domain. See the corresponding option of the I<create> subcommand.
> +
> +=back
> +
>  =item B<pause> I<domain-id>
>
>  Pause a domain.  When in a paused state the domain will still consume
> diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl.h
> --- a/tools/libxl/xl.h  Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/xl.h  Tue Jan 31 20:33:34 2012 -0800
> @@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
>  int main_getenforce(int argc, char **argv);
>  int main_setenforce(int argc, char **argv);
>  int main_loadpolicy(int argc, char **argv);
> +int main_remus(int argc, char **argv);
>
>  void help(const char *command);
>
> diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Tue Jan 31 20:33:34 2012 -0800
> @@ -2828,7 +2828,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 send_fd, int recv_fd, int remus)
>  {
>     int rc, rc2;
>     char rc_buf;
> @@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i
>         exit(-rc);
>     }
>
> +    if (remus) {
> +        /* If we are here, it means that the sender (primary) has crashed.
> +         * TODO: Split-Brain Check.
> +         */
> +        fprintf(stderr, "migration target: Remus Failover for domain
> %u\n",
> +                domid);
> +
> +        /*
> +         * If domain renaming fails, lets just continue (as we need the
> domain
> +         * to be up & dom names may not matter much, as long as its
> reachable
> +         * over network).
> +         *
> +         * If domain unpausing fails, destroy domain ? Or is it better to
> have
> +         * a consistent copy of the domain (memory, cpu state, disk)
> +         * on atleast one physical host ? Right now, lets just leave the
> domain
> +         * as is and let the Administrator decide (or troubleshoot).
> +         */
> +        if (migration_domname) {
> +            rc = libxl_domain_rename(ctx, domid, migration_domname,
> +                                     common_domname);
> +            if (rc)
> +                fprintf(stderr, "migration target (Remus): "
> +                        "Failed to rename domain from %s to %s:%d\n",
> +                        migration_domname, common_domname, rc);
> +        }
> +
> +        rc = libxl_domain_unpause(ctx, domid);
> +        if (rc)
> +            fprintf(stderr, "migration target (Remus): "
> +                    "Failed to unpause domain %s (id: %u):%d\n",
> +                    common_domname, domid, rc);
> +
> +        exit(rc ? -ERROR_FAIL: 0);
> +    }
> +
>     fprintf(stderr, "migration target: Transfer complete,"
>             " requesting permission to start domain.\n");
>
> @@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)
>
>  int main_migrate_receive(int argc, char **argv)
>  {
> -    int debug = 0, daemonize = 1, monitor = 1;
> +    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
>     int opt;
>
> -    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) !=
> -1) {
> +    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0))
> != -1) {
>         switch (opt) {
>         case 0: case 2:
>             return opt;
> @@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char
>         case 'd':
>             debug = 1;
>             break;
> +        case 'r':
> +            remus = 1;
> +            break;
>         }
>     }
>
> @@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char
>         return 2;
>     }
>     migrate_receive(debug, daemonize, monitor,
> -                    STDOUT_FILENO, STDIN_FILENO);
> +                    STDOUT_FILENO, STDIN_FILENO,
> +                    remus);
>
>     return 0;
>  }
> @@ -5951,6 +5990,106 @@ done:
>     return ret;
>  }
>
> +int main_remus(int argc, char **argv)
> +{
> +    int opt, rc, daemonize = 1;
> +    const char *ssh_command = "ssh";
> +    char *host = NULL, *rune = NULL, *domain = NULL;
> +    libxl_domain_remus_info r_info;
> +    int send_fd = -1, recv_fd = -1;
> +    pid_t child = -1;
> +    uint8_t *config_data;
> +    int config_len;
> +
> +    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
> +    /* Defaults */
> +    r_info.interval = 200;
> +    r_info.blackhole = 0;
> +    r_info.compression = 1;
> +
> +    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
> +        switch (opt) {
> +        case 0: case 2:
> +            return opt;
> +
> +        case 'i':
> +           r_info.interval = atoi(optarg);
> +            break;
> +        case 'b':
> +            r_info.blackhole = 1;
> +            break;
> +        case 'u':
> +           r_info.compression = 0;
> +            break;
> +        case 's':
> +            ssh_command = optarg;
> +            break;
> +        case 'e':
> +            daemonize = 0;
> +            break;
> +        }
> +    }
> +
> +    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");
> +            exit(-1);
> +        }
> +    } else {
> +
> +        /*
> +         * TODO: change this to plain TCP socket based channel
> +         * instead of SSH. For both live-migration and Remus.
> +         */
> +        if (!ssh_command[0]) {
> +            rune = host;
> +        } else {
> +            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
> +                         ssh_command, host,
> +                         daemonize ? "" : " -e") < 0)
> +                return 1;
> +        }
> +
> +        save_domain_core_begin(domain, NULL, &config_data, &config_len);
> +
> +        if (!config_len) {
> +            fprintf(stderr, "No config file stored for running domain and
> "
> +                    "none supplied - cannot start remus.\n");
> +            exit(1);
> +        }
> +
> +        child = create_migration_child(rune, &send_fd, &recv_fd);
> +
> +        migrate_do_preamble(send_fd, recv_fd, child, config_data,
> config_len,
> +                            rune);
> +    }
> +
> +    /* Point of no return */
> +    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
> +
> +    /* If we are here, it means backup has failed/domain suspend failed.
> +     * Try to resume the domain and exit gracefully.
> +     * TODO: Split-Brain check.
> +     */
> +    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
> +            " (rc=%d)\n", rc);
> +
> +    if (rc == ERROR_GUEST_TIMEDOUT)
> +        fprintf(stderr, "Failed to suspend domain at primary.\n");
> +    else {
> +        fprintf(stderr, "Remus: Backup failed? resuming domain at
> primary.\n");
> +        libxl_domain_resume(ctx, domid, 1);
> +    }
> +
> +    close(send_fd);
> +    return -ERROR_FAIL;
> +}
> +
>  /*
>  * Local variables:
>  * mode: C
> diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800
> @@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
>       "Loads a new policy int the Flask Xen security module",
>       "<policy file>",
>     },
> +    { "remus",
> +      &main_remus, 0,
> +      "Enable Remus HA for domain",
> +      "[options] <Domain> [<host>]",
> +      "-i MS                   Checkpoint domain memory every MS
> milliseconds (def. 200ms).\n"
> +      "-b                      Replicate memory checkpoints to /dev/null
> (blackhole)\n"
> +      "-u                      Disable memory checkpoint compression.\n"
> +      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String
> will be passed\n"
> +      "                        to sh. If empty, run <host> instead of \n"
> +      "                        ssh <host> xl migrate-receive -r [-e]\n"
> +      "-e                      Do not wait in the background (on <host>)
> for the death\n"
> +      "                        of the domain."
> +
> +    },
>  };
>
>  int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);
>
>
>
>
> ---------- Forwarded message ----------
> From: xen.org <ian.jackson@eu.citrix.com>
> To: xen-devel@lists.xensource.com
> Cc: ian.jackson@eu.citrix.com
> Date: Wed, 1 Feb 2012 05:52:30 +0000
> Subject: [Xen-devel] [linux test] 11749: regressions - FAIL
> flight 11749 linux real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs.
> 10764
>
> Regressions which are regarded as allowable (not blocking):
>  test-i386-i386-win           14 guest-start.2            fail blocked in
> 10764
>
> 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-xl-win-vcpus1 13 guest-stop                   fail  never
> pass
>  test-amd64-i386-win          16 leak-check/check             fail   never
> pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
> pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never
> pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never
> pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
> pass
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never
> pass
>
> version targeted for testing:
>  linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> baseline version:
>  linux                8664c694e49d4d095706524a27b1fc734b9881ce
>
> ------------------------------------------------------------
> 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-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail
>  test-amd64-amd64-xl-winxpsp3                                 fail
>  test-i386-i386-xl-winxpsp3                                   fail
>
>
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
>    http://www.chiark.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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> Merge: 8664c69... b16a92f...
> Author: Jeremy Fitzhardinge <jeremy@goop.org>
> Date:   Thu Jan 26 13:19:51 2012 -0800
>
>    Merge commit 'v2.6.32.55' into xen/next-2.6.32
>
>    * commit 'v2.6.32.55': (28 commits)
>      Linux 2.6.32.55
>      kprobes: initialize before using a hlist
>      score: fix off-by-one index into syscall table
>      sym53c8xx: Fix NULL pointer dereference in slave_destroy
>      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
>      kernel.h: add printk_ratelimited and pr_<level>_rl
>      block: add and use scsi_blk_cmd_ioctl
>      USB: Fix 'bad dma' problem on WDM device disconnect
>      fix cputime overflow in uptime_proc_show
>      USB: cdc-wdm: fix misuse of logical operation in place of bitop
>      nfsd: Fix oops when parsing a 0 length export
>      svcrpc: destroy server sockets all at once
>      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
>      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
>      i2c: Fix error value returned by several bus drivers
>      UBI: fix nameless volumes handling
>      x86: Fix mmap random address range
>      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
>      ima: free duplicate measurement memory
>      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
>      ...
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

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

<br><br><div class=3D"gmail_quote">On Wed, Feb 1, 2012 at 1:52 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:xen-devel-request@lists.xensource.com">xen=
-devel-request@lists.xensource.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
Send Xen-devel mailing list submissions to<br>
 =A0 =A0 =A0 =A0<a href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@=
lists.xensource.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
 =A0 =A0 =A0 =A0<a href=3D"http://lists.xensource.com/mailman/listinfo/xen-=
devel" target=3D"_blank">http://lists.xensource.com/mailman/listinfo/xen-de=
vel</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
 =A0 =A0 =A0 =A0<a href=3D"mailto:xen-devel-request@lists.xensource.com">xe=
n-devel-request@lists.xensource.com</a><br>
<br>
You can reach the person managing the list at<br>
 =A0 =A0 =A0 =A0<a href=3D"mailto:xen-devel-owner@lists.xensource.com">xen-=
devel-owner@lists.xensource.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of Xen-devel digest...&quot;<br>
<br>Today&#39;s Topics:<br>
<br>
 =A0 1. [PATCH 0 of 2 V2] libxl - Remus support (<a href=3D"mailto:rshriram=
@cs.ubc.ca">rshriram@cs.ubc.ca</a>)<br>
 =A0 2. [PATCH 1 of 2 V2] libxl: Remus - =A0suspend/postflush/commit<br>
 =A0 =A0 =A0callbacks (<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ub=
c.ca</a>)<br>
 =A0 3. [PATCH 2 of 2 V2] libxl: Remus - xl remus command<br>
 =A0 =A0 =A0(<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a>)<=
br>
 =A0 4. [linux test] 11749: regressions - FAIL (<a href=3D"http://xen.org" =
target=3D"_blank">xen.org</a>)<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"mailt=
o:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a><br>To:=A0<a href=3D"mailto:xen=
-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>Cc:=A0<a h=
ref=3D"mailto:brendan@cs.ubc.ca">brendan@cs.ubc.ca</a>, <a href=3D"mailto:i=
an.jackson@eu.citrix.com">ian.jackson@eu.citrix.com</a>, <a href=3D"mailto:=
ian.campbell@citrix.com">ian.campbell@citrix.com</a><br>
Date:=A0Tue, 31 Jan 2012 20:44:11 -0800<br>Subject:=A0[Xen-devel] [PATCH 0 =
of 2 V2] libxl - Remus support<br>This patch series introduces a basic fram=
ework to<br>
incorporate Remus into the libxl toolstack. The only functionality<br>
currently implemented is memory checkpointing.<br>
<br>
These patches depend on Version 2 of<br>
&quot;libxl: refactor suspend/resume code&quot; patch series.<br>
<br>
Changes since previous version:<br>
=A0* Move libxl_domain_remus_start into the save_callbacks implementation p=
atch<br>
=A0* return proper error codes instead of -1.<br>
=A0* Add documentation to docs/man/xl.pod.1<br>
<br>
Shriram<br>
<br>
test for replying to the sender. Sorry for any trouble with you.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"mailt=
o:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a><br>To:=A0<a href=3D"mailto:xen=
-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>Cc:=A0<a h=
ref=3D"mailto:brendan@cs.ubc.ca">brendan@cs.ubc.ca</a>, <a href=3D"mailto:i=
an.jackson@eu.citrix.com">ian.jackson@eu.citrix.com</a>, <a href=3D"mailto:=
ian.campbell@citrix.com">ian.campbell@citrix.com</a><br>
Date:=A0Tue, 31 Jan 2012 20:44:12 -0800<br>Subject:=A0[Xen-devel] [PATCH 1 =
of 2 V2] libxl: Remus - suspend/postflush/commit callbacks<br># HG changese=
t patch<br>
# User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshrir=
am@cs.ubc.ca</a>&gt;<br>
# Date 1328070814 28800<br>
# Node ID 2aa138177f5ef6aa44e6136dd1913441c99aa4b5<br>
# Parent =A0545f88c2bc73b063a5d0e7adbd95baed4d93790f<br>
libxl: Remus - suspend/postflush/commit callbacks<br>
<br>
=A0* Add libxl callback functions for Remus checkpoint suspend, postflush<b=
r>
 =A0 (aka resume) and checkpoint commit callbacks.<br>
=A0* suspend callback is a stub that just bounces off<br>
 =A0 libxl__domain_suspend_common_callback - which suspends the domain and<=
br>
 =A0 saves the devices model state to a file.<br>
=A0* resume callback currently just resumes the domain (and the device mode=
l).<br>
=A0* commit callback just writes out the saved device model state to the<br=
>
 =A0 network and sleeps for the checkpoint interval.<br>
=A0* Introduce a new public API, libxl_domain_remus_start (currently a stub=
)<br>
 =A0 that sets up the network and disk buffer and initiates continuous<br>
 =A0 checkpointing.<br>
<br>
=A0* Future patches will augument these callbacks/functions with more funct=
ionalities<br>
 =A0 like issuing network buffer plug/unplug commands, disk checkpoint comm=
ands, etc.<br>
<br>
Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca=
">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.c<br>
--- a/tools/libxl/libxl.c =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/libxl.c =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -480,6 +480,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *<br>
 =A0 =A0 return ptr;<br>
=A0}<br>
<br>
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */<br>
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info=
,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid, i=
nt send_fd, int recv_fd)<br>
+{<br>
+ =A0 =A0GC_INIT(ctx);<br>
+ =A0 =A0libxl_domain_type type =3D libxl__domain_type(gc, domid);<br>
+ =A0 =A0int rc =3D 0;<br>
+<br>
+ =A0 =A0if (info =3D=3D NULL) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;No remus_info structure supplie=
d for domain %d&quot;, domid);<br>
+ =A0 =A0 =A0 =A0rc =3D ERROR_INVAL;<br>
+ =A0 =A0 =A0 =A0goto remus_fail;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0/* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, et=
c */<br>
+<br>
+ =A0 =A0/* Point of no return */<br>
+ =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, send_fd, type, /* l=
ive */ 1,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0/* debug */ 0, info);<br>
+<br>
+ =A0 =A0/*<br>
+ =A0 =A0 * With Remus, if we reach this point, it means either<br>
+ =A0 =A0 * backup died or some network error occurred preventing us<br>
+ =A0 =A0 * from sending checkpoints.<br>
+ =A0 =A0 */<br>
+<br>
+ =A0 =A0/* TBD: Remus cleanup - i.e. detach qdisc, release other<br>
+ =A0 =A0 * resources.<br>
+ =A0 =A0 */<br>
+ remus_fail:<br>
+ =A0 =A0GC_FREE;<br>
+ =A0 =A0return rc;<br>
+}<br>
+<br>
=A0int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info=
,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t domid, int fd)=
<br>
=A0{<br>
@@ -489,7 +524,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,<br>
 =A0 =A0 int debug =3D info !=3D NULL &amp;&amp; info-&gt;flags &amp; XL_SU=
SPEND_DEBUG;<br>
 =A0 =A0 int rc =3D 0;<br>
<br>
- =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, fd, type, live, deb=
ug);<br>
+ =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, fd, type, live, deb=
ug,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0/* No Remus */ NULL);<br>
+<br>
 =A0 =A0 if (!rc &amp;&amp; type =3D=3D LIBXL_DOMAIN_TYPE_HVM)<br>
 =A0 =A0 =A0 =A0 rc =3D libxl__domain_save_device_model(gc, domid, fd);<br>
 =A0 =A0 GC_FREE;<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.h<br>
--- a/tools/libxl/libxl.h =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/libxl.h =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl<br>
=A0int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_confi=
g, libxl_console_ready cb, void *priv, uint32_t *domid);<br>
=A0int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_c=
onfig, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)=
;<br>
=A0void libxl_domain_config_dispose(libxl_domain_config *d_config);<br>
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info=
,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid, i=
nt send_fd, int recv_fd);<br>
=A0int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info=
,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid, int fd=
);<br>
=A0int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_canc=
el);<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_dom.c<br>
--- a/tools/libxl/libxl_dom.c =A0 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/libxl_dom.c =A0 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -404,6 +404,8 @@ struct suspendinfo {<br>
 =A0 =A0 int hvm;<br>
 =A0 =A0 unsigned int flags;<br>
 =A0 =A0 int guest_responded;<br>
+ =A0 =A0int save_fd; /* Migration stream fd (for Remus) */<br>
+ =A0 =A0int interval; /* checkpoint interval (for Remus) */<br>
=A0};<br>
<br>
=A0static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, =
unsigned int enable, void *data)<br>
@@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_<br>
 =A0 =A0 return 1;<br>
=A0}<br>
<br>
+static int libxl__remus_domain_suspend_callback(void *data)<br>
+{<br>
+ =A0 =A0/* TODO: Issue disk and network checkpoint reqs. */<br>
+ =A0 =A0return libxl__domain_suspend_common_callback(data);<br>
+}<br>
+<br>
+static int libxl__remus_domain_resume_callback(void *data)<br>
+{<br>
+ =A0 =A0struct suspendinfo *si =3D data;<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(si-&gt;gc);<br>
+<br>
+ =A0 =A0/* Resumes the domain and the device model */<br>
+ =A0 =A0if (libxl_domain_resume(ctx, si-&gt;domid, /* Fast Suspend */1))<b=
r>
+ =A0 =A0 =A0 =A0return 0;<br>
+<br>
+ =A0 =A0/* TODO: Deal with disk. Start a new network output buffer */<br>
+ =A0 =A0return 1;<br>
+}<br>
+<br>
+static int libxl__remus_domain_checkpoint_callback(void *data)<br>
+{<br>
+ =A0 =A0struct suspendinfo *si =3D data;<br>
+<br>
+ =A0 =A0/* This would go into tailbuf. */<br>
+ =A0 =A0if (si-&gt;hvm &amp;&amp;<br>
+ =A0 =A0 =A0 =A0libxl__domain_save_device_model(si-&gt;gc, si-&gt;domid, s=
i-&gt;save_fd))<br>
+ =A0 =A0 =A0 =A0return 0;<br>
+<br>
+ =A0 =A0/* TODO: Wait for disk and memory ack, release network buffer */<b=
r>
+ =A0 =A0usleep(si-&gt;interval * 1000);<br>
+ =A0 =A0return 1;<br>
+}<br>
+<br>
=A0int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,<=
br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_d=
omain_type type,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int live,=
 int debug)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int live,=
 int debug,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const lib=
xl_domain_remus_info *r_info)<br>
=A0{<br>
 =A0 =A0 libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
 =A0 =A0 int flags;<br>
@@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 =A0 =A0 return ERROR_INVAL;<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0memset(&amp;si, 0, sizeof(si));<br>
 =A0 =A0 flags =3D (live) ? XCFLAGS_LIVE : 0<br>
 =A0 =A0 =A0 =A0 =A0 | (debug) ? XCFLAGS_DEBUG : 0<br>
 =A0 =A0 =A0 =A0 =A0 | (hvm) ? XCFLAGS_HVM : 0;<br>
<br>
+ =A0 =A0if (r_info !=3D NULL) {<br>
+ =A0 =A0 =A0 =A0si.interval =3D r_info-&gt;interval;<br>
+ =A0 =A0 =A0 =A0if (r_info-&gt;compression)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0flags |=3D XCFLAGS_CHECKPOINT_COMPRESS;<br>
+ =A0 =A0 =A0 =A0si.save_fd =3D fd;<br>
+ =A0 =A0}<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0si.save_fd =3D -1;<br>
+<br>
 =A0 =A0 si.domid =3D domid;<br>
 =A0 =A0 si.flags =3D flags;<br>
 =A0 =A0 si.hvm =3D hvm;<br>
@@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 memset(&amp;callbacks, 0, sizeof(callbacks));<br>
- =A0 =A0callbacks.suspend =3D libxl__domain_suspend_common_callback;<br>
+ =A0 =A0if (r_info !=3D NULL) {<br>
+ =A0 =A0 =A0 =A0/* save_callbacks:<br>
+ =A0 =A0 =A0 =A0 * suspend - called after expiration of checkpoint interva=
l,<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 to *suspend* the domain.<br>
+ =A0 =A0 =A0 =A0 *<br>
+ =A0 =A0 =A0 =A0 * postcopy - called after the domain&#39;s dirty pages ha=
ve been<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0copied into an output buffer. We=
 *resume* the domain<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0&amp; the device model, return t=
o the caller. Caller then<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0flushes the output buffer, while=
 the domain continues to run.<br>
+ =A0 =A0 =A0 =A0 *<br>
+ =A0 =A0 =A0 =A0 * checkpoint - called after the memory checkpoint has bee=
n flushed out<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0into the network. Send the s=
aved device state, *wait*<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0for checkpoint ack and *rele=
ase* the network buffer (TBD).<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0Then *sleep* for the checkpo=
int interval.<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0callbacks.suspend =3D libxl__remus_domain_suspend_callback=
;<br>
+ =A0 =A0 =A0 =A0callbacks.postcopy =3D libxl__remus_domain_resume_callback=
;<br>
+ =A0 =A0 =A0 =A0callbacks.checkpoint =3D libxl__remus_domain_checkpoint_ca=
llback;<br>
+ =A0 =A0} else<br>
+ =A0 =A0 =A0 =A0callbacks.suspend =3D libxl__domain_suspend_common_callbac=
k;<br>
+<br>
 =A0 =A0 callbacks.switch_qemu_logdirty =3D libxl__domain_suspend_common_sw=
itch_qemu_logdirty;<br>
 =A0 =A0 callbacks.data =3D &amp;si;<br>
<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_internal.h<br>
--- a/tools/libxl/libxl_internal.h =A0 =A0 =A0Tue Jan 31 20:33:34 2012 -080=
0<br>
+++ b/tools/libxl/libxl_internal.h =A0 =A0 =A0Tue Jan 31 20:33:34 2012 -080=
0<br>
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0int fd);<br>
=A0_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, =
int fd,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0libxl_domain_type type,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 int live, int debug);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 int live, int debug,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 const libxl_domain_remus_info *r_info);<br>
=A0_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t=
 domid);<br>
=A0_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t d=
omid);<br>
=A0_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t do=
mid);<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_types.idl<br>
--- a/tools/libxl/libxl_types.idl =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -080=
0<br>
+++ b/tools/libxl/libxl_types.idl =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -080=
0<br>
@@ -397,3 +397,9 @@ libxl_sched_sedf =3D Struct(&quot;sched_sedf&quot;,<br>
 =A0 =A0 (&quot;extratime&quot;, integer),<br>
 =A0 =A0 (&quot;weight&quot;, integer),<br>
 =A0 =A0 ], dispose_fn=3DNone)<br>
+<br>
+libxl_domain_remus_info =3D Struct(&quot;domain_remus_info&quot;,[<br>
+ =A0 =A0(&quot;interval&quot;, =A0 =A0 integer),<br>
+ =A0 =A0(&quot;blackhole&quot;, =A0 =A0bool),<br>
+ =A0 =A0(&quot;compression&quot;, =A0bool),<br>
+ =A0 =A0])<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"mailt=
o:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a><br>To:=A0<a href=3D"mailto:xen=
-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>Cc:=A0<a h=
ref=3D"mailto:brendan@cs.ubc.ca">brendan@cs.ubc.ca</a>, <a href=3D"mailto:i=
an.jackson@eu.citrix.com">ian.jackson@eu.citrix.com</a>, <a href=3D"mailto:=
ian.campbell@citrix.com">ian.campbell@citrix.com</a><br>
Date:=A0Tue, 31 Jan 2012 20:44:13 -0800<br>Subject:=A0[Xen-devel] [PATCH 2 =
of 2 V2] libxl: Remus - xl remus command<br># HG changeset patch<br>
# User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshrir=
am@cs.ubc.ca</a>&gt;<br>
# Date 1328070814 28800<br>
# Node ID cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba<br>
# Parent =A02aa138177f5ef6aa44e6136dd1913441c99aa4b5<br>
libxl: Remus - xl remus command<br>
<br>
xl remus acts as a frontend to enable remus for a given domain.<br>
=A0* At the moment, only memory checkpointing and blackhole replication is<=
br>
 =A0 supported. Support for disk checkpointing and network buffering will<b=
r>
 =A0 be added in future.<br>
=A0* Replication is done over ssh connection currently (like live migration=
<br>
 =A0 with xl). Future versions will have an option to use simple tcp socket=
<br>
 =A0 based replication channel (for both Remus &amp; live migration).<br>
<br>
Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca=
">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
diff -r 2aa138177f5e -r cf47997255f4 docs/man/xl.pod.1<br>
--- a/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -348,6 +348,39 @@ Send &lt;config&gt; instead of config file fro<br>
<br>
=A0=3Dback<br>
<br>
+=3Ditem B&lt;remus&gt; [I&lt;OPTIONS&gt;] I&lt;domain-id&gt; I&lt;host&gt;=
<br>
+<br>
+Enable Remus HA for domain. By default B&lt;xl&gt; relies on ssh as a tran=
sport mechanism<br>
+between the two hosts.<br>
+<br>
+B&lt;OPTIONS&gt;<br>
+<br>
+=3Dover 4<br>
+<br>
+=3Ditem B&lt;-i&gt; I&lt;MS&gt;<br>
+<br>
+Checkpoint domain memory every MS milliseconds (default 200ms).<br>
+<br>
+=3Ditem B&lt;-b&gt;<br>
+<br>
+Replicate memory checkpoints to /dev/null (blackhole).<br>
+<br>
+=3Ditem B&lt;-u&gt;<br>
+<br>
+Disable memory checkpoint compression.<br>
+<br>
+=3Ditem B&lt;-s&gt; I&lt;sshcommand&gt;<br>
+<br>
+Use &lt;sshcommand&gt; instead of ssh. =A0String will be passed to sh. If =
empty, run<br>
+&lt;host&gt; instead of ssh &lt;host&gt; xl migrate-receive -r [-e].<br>
+<br>
+=3Ditem B&lt;-e&gt;<br>
+<br>
+On the new host, do not wait in the background (on &lt;host&gt;) for the d=
eath of the<br>
+domain. See the corresponding option of the I&lt;create&gt; subcommand.<br=
>
+<br>
+=3Dback<br>
+<br>
=A0=3Ditem B&lt;pause&gt; I&lt;domain-id&gt;<br>
<br>
=A0Pause a domain. =A0When in a paused state the domain will still consume<=
br>
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl.h<br>
--- a/tools/libxl/xl.h =A0Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/xl.h =A0Tue Jan 31 20:33:34 2012 -0800<br>
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char<br>
=A0int main_getenforce(int argc, char **argv);<br>
=A0int main_setenforce(int argc, char **argv);<br>
=A0int main_loadpolicy(int argc, char **argv);<br>
+int main_remus(int argc, char **argv);<br>
<br>
=A0void help(const char *command);<br>
<br>
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdimpl.c<br>
--- a/tools/libxl/xl_cmdimpl.c =A0Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/xl_cmdimpl.c =A0Tue Jan 31 20:33:34 2012 -0800<br>
@@ -2828,7 +2828,7 @@ static void core_dump_domain(const char<br>
=A0}<br>
<br>
=A0static void migrate_receive(int debug, int daemonize, int monitor,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int send_fd, int r=
ecv_fd)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int send_fd, int r=
ecv_fd, int remus)<br>
=A0{<br>
 =A0 =A0 int rc, rc2;<br>
 =A0 =A0 char rc_buf;<br>
@@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i<br>
 =A0 =A0 =A0 =A0 exit(-rc);<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0if (remus) {<br>
+ =A0 =A0 =A0 =A0/* If we are here, it means that the sender (primary) has =
crashed.<br>
+ =A0 =A0 =A0 =A0 * TODO: Split-Brain Check.<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target: Remus Failover for=
 domain %u\n&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<br>
+<br>
+ =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 * If domain renaming fails, lets just continue (as we nee=
d the domain<br>
+ =A0 =A0 =A0 =A0 * to be up &amp; dom names may not matter much, as long a=
s its reachable<br>
+ =A0 =A0 =A0 =A0 * over network).<br>
+ =A0 =A0 =A0 =A0 *<br>
+ =A0 =A0 =A0 =A0 * If domain unpausing fails, destroy domain ? Or is it be=
tter to have<br>
+ =A0 =A0 =A0 =A0 * a consistent copy of the domain (memory, cpu state, dis=
k)<br>
+ =A0 =A0 =A0 =A0 * on atleast one physical host ? Right now, lets just lea=
ve the domain<br>
+ =A0 =A0 =A0 =A0 * as is and let the Administrator decide (or troubleshoot=
).<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0if (migration_domname) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0rc =3D libxl_domain_rename(ctx, domid, migration_d=
omname,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 c=
ommon_domname);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if (rc)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Re=
mus): &quot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to rename dom=
ain from %s to %s:%d\n&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0migration_domname, common_=
domname, rc);<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0rc =3D libxl_domain_unpause(ctx, domid);<br>
+ =A0 =A0 =A0 =A0if (rc)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus): &q=
uot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to unpause domain %s =
(id: %u):%d\n&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0common_domname, domid, rc);<br>
+<br>
+ =A0 =A0 =A0 =A0exit(rc ? -ERROR_FAIL: 0);<br>
+ =A0 =A0}<br>
+<br>
 =A0 =A0 fprintf(stderr, &quot;migration target: Transfer complete,&quot;<b=
r>
 =A0 =A0 =A0 =A0 =A0 =A0 &quot; requesting permission to start domain.\n&qu=
ot;);<br>
<br>
@@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)<br>
<br>
=A0int main_migrate_receive(int argc, char **argv)<br>
=A0{<br>
- =A0 =A0int debug =3D 0, daemonize =3D 1, monitor =3D 1;<br>
+ =A0 =A0int debug =3D 0, daemonize =3D 1, monitor =3D 1, remus =3D 0;<br>
 =A0 =A0 int opt;<br>
<br>
- =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;Fed&quot;, &quot;migr=
ate-receive&quot;, 0)) !=3D -1) {<br>
+ =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;Fedr&quot;, &quot;mig=
rate-receive&quot;, 0)) !=3D -1) {<br>
 =A0 =A0 =A0 =A0 switch (opt) {<br>
 =A0 =A0 =A0 =A0 case 0: case 2:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return opt;<br>
@@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char<br>
 =A0 =A0 =A0 =A0 case &#39;d&#39;:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 debug =3D 1;<br>
 =A0 =A0 =A0 =A0 =A0 =A0 break;<br>
+ =A0 =A0 =A0 =A0case &#39;r&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0remus =3D 1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 }<br>
<br>
@@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char<br>
 =A0 =A0 =A0 =A0 return 2;<br>
 =A0 =A0 }<br>
 =A0 =A0 migrate_receive(debug, daemonize, monitor,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0STDOUT_FILENO, STDIN_FILENO);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0STDOUT_FILENO, STDIN_FILENO,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remus);<br>
<br>
 =A0 =A0 return 0;<br>
=A0}<br>
@@ -5951,6 +5990,106 @@ done:<br>
 =A0 =A0 return ret;<br>
=A0}<br>
<br>
+int main_remus(int argc, char **argv)<br>
+{<br>
+ =A0 =A0int opt, rc, daemonize =3D 1;<br>
+ =A0 =A0const char *ssh_command =3D &quot;ssh&quot;;<br>
+ =A0 =A0char *host =3D NULL, *rune =3D NULL, *domain =3D NULL;<br>
+ =A0 =A0libxl_domain_remus_info r_info;<br>
+ =A0 =A0int send_fd =3D -1, recv_fd =3D -1;<br>
+ =A0 =A0pid_t child =3D -1;<br>
+ =A0 =A0uint8_t *config_data;<br>
+ =A0 =A0int config_len;<br>
+<br>
+ =A0 =A0memset(&amp;r_info, 0, sizeof(libxl_domain_remus_info));<br>
+ =A0 =A0/* Defaults */<br>
+ =A0 =A0r_info.interval =3D 200;<br>
+ =A0 =A0r_info.blackhole =3D 0;<br>
+ =A0 =A0r_info.compression =3D 1;<br>
+<br>
+ =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;bui:s:e&quot;, &quot;=
remus&quot;, 2)) !=3D -1) {<br>
+ =A0 =A0 =A0 =A0switch (opt) {<br>
+ =A0 =A0 =A0 =A0case 0: case 2:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return opt;<br>
+<br>
+ =A0 =A0 =A0 =A0case &#39;i&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 r_info.interval =3D atoi(optarg);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;b&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0r_info.blackhole =3D 1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;u&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 r_info.compression =3D 0;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;s&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0ssh_command =3D optarg;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;e&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0daemonize =3D 0;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0domain =3D argv[optind];<br>
+ =A0 =A0host =3D argv[optind + 1];<br>
+<br>
+ =A0 =A0if (r_info.blackhole) {<br>
+ =A0 =A0 =A0 =A0find_domain(domain);<br>
+ =A0 =A0 =A0 =A0send_fd =3D open(&quot;/dev/null&quot;, O_RDWR, 0644);<br>
+ =A0 =A0 =A0 =A0if (send_fd &lt; 0) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0perror(&quot;failed to open /dev/null&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0exit(-1);<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0} else {<br>
+<br>
+ =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 * TODO: change this to plain TCP socket based channel<br>
+ =A0 =A0 =A0 =A0 * instead of SSH. For both live-migration and Remus.<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0if (!ssh_command[0]) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0rune =3D host;<br>
+ =A0 =A0 =A0 =A0} else {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if (asprintf(&amp;rune, &quot;exec %s %s xl migrat=
e-receive -r %s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssh_command, host,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 daemonize ? &quot;&quot; =
: &quot; -e&quot;) &lt; 0)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0save_domain_core_begin(domain, NULL, &amp;config_data, &am=
p;config_len);<br>
+<br>
+ =A0 =A0 =A0 =A0if (!config_len) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;No config file stored for ru=
nning domain and &quot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;none supplied - cannot start=
 remus.\n&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0exit(1);<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0child =3D create_migration_child(rune, &amp;send_fd, &amp;=
recv_fd);<br>
+<br>
+ =A0 =A0 =A0 =A0migrate_do_preamble(send_fd, recv_fd, child, config_data, =
config_len,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rune);<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0/* Point of no return */<br>
+ =A0 =A0rc =3D libxl_domain_remus_start(ctx, &amp;r_info, domid, send_fd, =
recv_fd);<br>
+<br>
+ =A0 =A0/* If we are here, it means backup has failed/domain suspend faile=
d.<br>
+ =A0 =A0 * Try to resume the domain and exit gracefully.<br>
+ =A0 =A0 * TODO: Split-Brain check.<br>
+ =A0 =A0 */<br>
+ =A0 =A0fprintf(stderr, &quot;remus sender: libxl_domain_suspend failed&qu=
ot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0&quot; (rc=3D%d)\n&quot;, rc);<br>
+<br>
+ =A0 =A0if (rc =3D=3D ERROR_GUEST_TIMEDOUT)<br>
+ =A0 =A0 =A0 =A0fprintf(stderr, &quot;Failed to suspend domain at primary.=
\n&quot;);<br>
+ =A0 =A0else {<br>
+ =A0 =A0 =A0 =A0fprintf(stderr, &quot;Remus: Backup failed? resuming domai=
n at primary.\n&quot;);<br>
+ =A0 =A0 =A0 =A0libxl_domain_resume(ctx, domid, 1);<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0close(send_fd);<br>
+ =A0 =A0return -ERROR_FAIL;<br>
+}<br>
+<br>
=A0/*<br>
 =A0* Local variables:<br>
 =A0* mode: C<br>
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdtable.c<br>
--- a/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800<br>
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] =3D {<br>
 =A0 =A0 =A0 &quot;Loads a new policy int the Flask Xen security module&quo=
t;,<br>
 =A0 =A0 =A0 &quot;&lt;policy file&gt;&quot;,<br>
 =A0 =A0 },<br>
+ =A0 =A0{ &quot;remus&quot;,<br>
+ =A0 =A0 =A0&amp;main_remus, 0,<br>
+ =A0 =A0 =A0&quot;Enable Remus HA for domain&quot;,<br>
+ =A0 =A0 =A0&quot;[options] &lt;Domain&gt; [&lt;host&gt;]&quot;,<br>
+ =A0 =A0 =A0&quot;-i MS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Checkpoint dom=
ain memory every MS milliseconds (def. 200ms).\n&quot;<br>
+ =A0 =A0 =A0&quot;-b =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Replicate =
memory checkpoints to /dev/null (blackhole)\n&quot;<br>
+ =A0 =A0 =A0&quot;-u =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Disable me=
mory checkpoint compression.\n&quot;<br>
+ =A0 =A0 =A0&quot;-s &lt;sshcommand&gt; =A0 =A0 =A0 =A0 Use &lt;sshcommand=
&gt; instead of ssh. =A0String will be passed\n&quot;<br>
+ =A0 =A0 =A0&quot; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to sh. I=
f empty, run &lt;host&gt; instead of \n&quot;<br>
+ =A0 =A0 =A0&quot; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ssh &lt;=
host&gt; xl migrate-receive -r [-e]\n&quot;<br>
+ =A0 =A0 =A0&quot;-e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Do not wai=
t in the background (on &lt;host&gt;) for the death\n&quot;<br>
+ =A0 =A0 =A0&quot; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of the d=
omain.&quot;<br>
+<br>
+ =A0 =A0},<br>
=A0};<br>
<br>
=A0int cmdtable_len =3D sizeof(cmd_table)/sizeof(struct cmd_spec);<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"http:=
//xen.org">xen.org</a> &lt;<a href=3D"mailto:ian.jackson@eu.citrix.com">ian=
.jackson@eu.citrix.com</a>&gt;<br>To:=A0<a href=3D"mailto:xen-devel@lists.x=
ensource.com">xen-devel@lists.xensource.com</a><br>
Cc:=A0<a href=3D"mailto:ian.jackson@eu.citrix.com">ian.jackson@eu.citrix.co=
m</a><br>Date:=A0Wed, 1 Feb 2012 05:52:30 +0000<br>Subject:=A0[Xen-devel] [=
linux test] 11749: regressions - FAIL<br>flight 11749 linux real [real]<br>
<a href=3D"http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/" target=
=3D"_blank">http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/</a><br>
<br>
Regressions :-(<br>
<br>
Tests which did not succeed and are blocking,<br>
including tests which could not be run:<br>
=A0test-amd64-i386-xl-credit2 =A0 =A07 debian-install =A0 =A0 =A0 =A0 =A0 =
=A0fail REGR. vs. 10764<br>
<br>
Regressions which are regarded as allowable (not blocking):<br>
=A0test-i386-i386-win =A0 =A0 =A0 =A0 =A0 14 guest-start.2 =A0 =A0 =A0 =A0 =
=A0 =A0fail blocked in 10764<br>
<br>
Tests which did not succeed, but are not blocking:<br>
=A0test-amd64-i386-rhel6hvm-amd 11 leak-check/check =A0 =A0 =A0 =A0 =A0 =A0=
 fail =A0 never pass<br>
=A0test-amd64-i386-rhel6hvm-intel 11 leak-check/check =A0 =A0 =A0 =A0 =A0 =
=A0 fail never pass<br>
=A0test-amd64-i386-xl-win-vcpus1 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 fail =A0never pass<br>
=A0test-amd64-i386-win =A0 =A0 =A0 =A0 =A016 leak-check/check =A0 =A0 =A0 =
=A0 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-i386-xl-win7-amd64 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 fail =A0never pass<br>
=A0test-amd64-i386-win-vcpus1 =A0 16 leak-check/check =A0 =A0 =A0 =A0 =A0 =
=A0 fail =A0 never pass<br>
=A0test-i386-i386-xl-winxpsp3 =A0 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 fail never pass<br>
=A0test-amd64-amd64-xl-winxpsp3 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 fail =A0 never pass<br>
=A0test-amd64-amd64-xl-win =A0 =A0 =A013 guest-stop =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-i386-xend-winxpsp3 16 leak-check/check =A0 =A0 =A0 =A0 =A0 =
=A0 fail =A0never pass<br>
=A0test-amd64-amd64-win =A0 =A0 =A0 =A0 16 leak-check/check =A0 =A0 =A0 =A0=
 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-amd64-xl-pcipt-intel =A09 guest-start =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 fail never pass<br>
=A0test-amd64-amd64-xl-win7-amd64 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 fail never pass<br>
=A0test-i386-i386-xl-win =A0 =A0 =A0 =A013 guest-stop =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 fail =A0 never pass<br>
<br>
version targeted for testing:<br>
=A0linux =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01aaf53ee291d9e71d6ec05c0ebdb2854fea=
175ad<br>
baseline version:<br>
=A0linux =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A08664c694e49d4d095706524a27b1fc734b9=
881ce<br>
<br>
------------------------------------------------------------<br>
People who touched revisions under test:<br>
------------------------------------------------------------<br>
<br>
jobs:<br>
=A0build-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0build-i386 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0build-amd64-pvops =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0build-i386-pvops =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-amd64-xl =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-xl =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-i386-i386-xl =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-rhel6hvm-amd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-xl-win7-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-xl-win7-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-xl-credit2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-xl-pcipt-intel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-rhel6hvm-intel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-xl-multivcpu =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-amd64-pair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-pair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-i386-i386-pair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-amd64-xl-sedf-pin =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-amd64-pv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-pv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-i386-i386-pv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-amd64-xl-sedf =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-i386-win-vcpus1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-xl-win-vcpus1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-xl-winxpsp3-vcpus1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-i386-i386-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-xl-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-i386-i386-xl-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-xend-winxpsp3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-amd64-xl-winxpsp3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-i386-i386-xl-winxpsp3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 fail<br>
<br>
<br>
------------------------------------------------------------<br>
sg-report-flight on <a href=3D"http://woking.cam.xci-test.com" target=3D"_b=
lank">woking.cam.xci-test.com</a><br>
logs: /home/xc_osstest/logs<br>
images: /home/xc_osstest/images<br>
<br>
Logs, config files, etc. are available at<br>
 =A0 =A0<a href=3D"http://www.chiark.greenend.org.uk/~xensrcts/logs" target=
=3D"_blank">http://www.chiark.greenend.org.uk/~xensrcts/logs</a><br>
<br>
Test harness code can be found at<br>
 =A0 =A0<a href=3D"http://xenbits.xensource.com/gitweb?p=3Dosstest.git;a=3D=
summary" target=3D"_blank">http://xenbits.xensource.com/gitweb?p=3Dosstest.=
git;a=3Dsummary</a><br>
<br>
<br>
Not pushing.<br>
<br>
------------------------------------------------------------<br>
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad<br>
Merge: 8664c69... b16a92f...<br>
Author: Jeremy Fitzhardinge &lt;<a href=3D"mailto:jeremy@goop.org">jeremy@g=
oop.org</a>&gt;<br>
Date: =A0 Thu Jan 26 13:19:51 2012 -0800<br>
<br>
 =A0 =A0Merge commit &#39;v2.6.32.55&#39; into xen/next-2.6.32<br>
<br>
 =A0 =A0* commit &#39;v2.6.32.55&#39;: (28 commits)<br>
 =A0 =A0 =A0Linux 2.6.32.55<br>
 =A0 =A0 =A0kprobes: initialize before using a hlist<br>
 =A0 =A0 =A0score: fix off-by-one index into syscall table<br>
 =A0 =A0 =A0sym53c8xx: Fix NULL pointer dereference in slave_destroy<br>
 =A0 =A0 =A0ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645<b=
r>
 =A0 =A0 =A0kernel.h: add printk_ratelimited and pr_&lt;level&gt;_rl<br>
 =A0 =A0 =A0block: add and use scsi_blk_cmd_ioctl<br>
 =A0 =A0 =A0USB: Fix &#39;bad dma&#39; problem on WDM device disconnect<br>
 =A0 =A0 =A0fix cputime overflow in uptime_proc_show<br>
 =A0 =A0 =A0USB: cdc-wdm: fix misuse of logical operation in place of bitop=
<br>
 =A0 =A0 =A0nfsd: Fix oops when parsing a 0 length export<br>
 =A0 =A0 =A0svcrpc: destroy server sockets all at once<br>
 =A0 =A0 =A0svcrpc: fix double-free on shutdown of nfsd after changing pool=
 mode<br>
 =A0 =A0 =A0V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()<br>
 =A0 =A0 =A0i2c: Fix error value returned by several bus drivers<br>
 =A0 =A0 =A0UBI: fix nameless volumes handling<br>
 =A0 =A0 =A0x86: Fix mmap random address range<br>
 =A0 =A0 =A0PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks U=
SB<br>
 =A0 =A0 =A0ima: free duplicate measurement memory<br>
 =A0 =A0 =A0xen/xenbus: Reject replies with payload &gt; XENSTORE_PAYLOAD_M=
AX.<br>
 =A0 =A0 =A0...<br>
<br>
<br>
<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br>

--20cf30363f4b1ecd2e04b7e1308d--


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

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

--===============3167636507460871122==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 06:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 06: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.xensource.com>)
	id 1RsTgR-0004Dl-PE; Wed, 01 Feb 2012 06:28:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1RsTgP-0004Dg-OL
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 06:28:42 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328077710!13220028!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10465 invoked from network); 1 Feb 2012 06:28:32 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 06:28:32 -0000
Received: by qcsp15 with SMTP id p15so3473091qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 22:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=8CTOwH0dkjgYtIdUEYzCpxP+IAFnckfVwJjQM4ku4f8=;
	b=E4ueHTjGdOpjcupWRv9dc9qz6YpzZUki07vepOdR/Exl8v4+AX3392BoqoFespA0IK
	qa5nC5BtYa40PK7zl7aOw5LsVBqevD9GMBcfLBqUyePHO5BtCcT9XF9arwOblVKVvx+K
	GCSiYbi6mpWKeIbHEh2CiRD4llXMUoCIAz6E8=
MIME-Version: 1.0
Received: by 10.224.179.137 with SMTP id bq9mr30929997qab.53.1328077709692;
	Tue, 31 Jan 2012 22:28:29 -0800 (PST)
Received: by 10.229.239.149 with HTTP; Tue, 31 Jan 2012 22:28:29 -0800 (PST)
In-Reply-To: <mailman.2163.1328075559.1471.xen-devel@lists.xensource.com>
References: <mailman.2163.1328075559.1471.xen-devel@lists.xensource.com>
Date: Wed, 1 Feb 2012 14:28:29 +0800
Message-ID: <CA+ePHTCggCq4tQbCtt6LUgFU-7NSVDHk+JQMRwO=ykbxGuLK6A@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3167636507460871122=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3167636507460871122==
Content-Type: multipart/alternative; boundary=20cf30363f4b1ecd2e04b7e1308d

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

On Wed, Feb 1, 2012 at 1:52 PM, <xen-devel-request@lists.xensource.com>wrote:

> Send Xen-devel mailing list submissions to
>        xen-devel@lists.xensource.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.xensource.com/mailman/listinfo/xen-devel
> or, via email, send a message with subject or body 'help' to
>        xen-devel-request@lists.xensource.com
>
> You can reach the person managing the list at
>        xen-devel-owner@lists.xensource.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xen-devel digest..."
>
> Today's Topics:
>
>   1. [PATCH 0 of 2 V2] libxl - Remus support (rshriram@cs.ubc.ca)
>   2. [PATCH 1 of 2 V2] libxl: Remus -  suspend/postflush/commit
>      callbacks (rshriram@cs.ubc.ca)
>   3. [PATCH 2 of 2 V2] libxl: Remus - xl remus command
>      (rshriram@cs.ubc.ca)
>   4. [linux test] 11749: regressions - FAIL (xen.org)
>
>
> ---------- Forwarded message ----------
> From: rshriram@cs.ubc.ca
> To: xen-devel@lists.xensource.com
> Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
> Date: Tue, 31 Jan 2012 20:44:11 -0800
> Subject: [Xen-devel] [PATCH 0 of 2 V2] libxl - Remus support
> This patch series introduces a basic framework to
> incorporate Remus into the libxl toolstack. The only functionality
> currently implemented is memory checkpointing.
>
> These patches depend on Version 2 of
> "libxl: refactor suspend/resume code" patch series.
>
> Changes since previous version:
>  * Move libxl_domain_remus_start into the save_callbacks implementation
> patch
>  * return proper error codes instead of -1.
>  * Add documentation to docs/man/xl.pod.1
>
> Shriram
>
> test for replying to the sender. Sorry for any trouble with you.
>
>
>
> ---------- Forwarded message ----------
> From: rshriram@cs.ubc.ca
> To: xen-devel@lists.xensource.com
> Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
> Date: Tue, 31 Jan 2012 20:44:12 -0800
> Subject: [Xen-devel] [PATCH 1 of 2 V2] libxl: Remus -
> suspend/postflush/commit callbacks
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328070814 28800
> # Node ID 2aa138177f5ef6aa44e6136dd1913441c99aa4b5
> # Parent  545f88c2bc73b063a5d0e7adbd95baed4d93790f
> libxl: Remus - suspend/postflush/commit callbacks
>
>  * Add libxl callback functions for Remus checkpoint suspend, postflush
>   (aka resume) and checkpoint commit callbacks.
>  * suspend callback is a stub that just bounces off
>   libxl__domain_suspend_common_callback - which suspends the domain and
>   saves the devices model state to a file.
>  * resume callback currently just resumes the domain (and the device
> model).
>  * commit callback just writes out the saved device model state to the
>   network and sleeps for the checkpoint interval.
>  * Introduce a new public API, libxl_domain_remus_start (currently a stub)
>   that sets up the network and disk buffer and initiates continuous
>   checkpointing.
>
>  * Future patches will augument these callbacks/functions with more
> functionalities
>   like issuing network buffer plug/unplug commands, disk checkpoint
> commands, etc.
>
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c       Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl.c       Tue Jan 31 20:33:34 2012 -0800
> @@ -480,6 +480,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
>     return ptr;
>  }
>
> +/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info
> *info,
> +                             uint32_t domid, int send_fd, int recv_fd)
> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d",
> domid);
> +        rc = ERROR_INVAL;
> +        goto remus_fail;
> +    }
> +
> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> +
> +    /* Point of no return */
> +    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live
> */ 1,
> +                                      /* debug */ 0, info);
> +
> +    /*
> +     * With Remus, if we reach this point, it means either
> +     * backup died or some network error occurred preventing us
> +     * from sending checkpoints.
> +     */
> +
> +    /* TBD: Remus cleanup - i.e. detach qdisc, release other
> +     * resources.
> +     */
> + remus_fail:
> +    GC_FREE;
> +    return rc;
> +}
> +
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                          uint32_t domid, int fd)
>  {
> @@ -489,7 +524,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
>     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
>     int rc = 0;
>
> -    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
> +    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
> +                                      /* No Remus */ NULL);
> +
>     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
>         rc = libxl__domain_save_device_model(gc, domid, fd);
>     GC_FREE;
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h       Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl.h       Tue Jan 31 20:33:34 2012 -0800
> @@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
>  int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config
> *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
>  int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config
> *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int
> restore_fd);
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info
> *info,
> +                             uint32_t domid, int send_fd, int recv_fd);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                           uint32_t domid, int fd);
>  int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int
> suspend_cancel);
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl_dom.c   Tue Jan 31 20:33:34 2012 -0800
> @@ -404,6 +404,8 @@ struct suspendinfo {
>     int hvm;
>     unsigned int flags;
>     int guest_responded;
> +    int save_fd; /* Migration stream fd (for Remus) */
> +    int interval; /* checkpoint interval (for Remus) */
>  };
>
>  static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid,
> unsigned int enable, void *data)
> @@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_
>     return 1;
>  }
>
> +static int libxl__remus_domain_suspend_callback(void *data)
> +{
> +    /* TODO: Issue disk and network checkpoint reqs. */
> +    return libxl__domain_suspend_common_callback(data);
> +}
> +
> +static int libxl__remus_domain_resume_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
> +
> +    /* Resumes the domain and the device model */
> +    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
> +        return 0;
> +
> +    /* TODO: Deal with disk. Start a new network output buffer */
> +    return 1;
> +}
> +
> +static int libxl__remus_domain_checkpoint_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +
> +    /* This would go into tailbuf. */
> +    if (si->hvm &&
> +        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
> +        return 0;
> +
> +    /* TODO: Wait for disk and memory ack, release network buffer */
> +    usleep(si->interval * 1000);
> +    return 1;
> +}
> +
>  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                  libxl_domain_type type,
> -                                 int live, int debug)
> +                                 int live, int debug,
> +                                 const libxl_domain_remus_info *r_info)
>  {
>     libxl_ctx *ctx = libxl__gc_owner(gc);
>     int flags;
> @@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__
>         return ERROR_INVAL;
>     }
>
> +    memset(&si, 0, sizeof(si));
>     flags = (live) ? XCFLAGS_LIVE : 0
>           | (debug) ? XCFLAGS_DEBUG : 0
>           | (hvm) ? XCFLAGS_HVM : 0;
>
> +    if (r_info != NULL) {
> +        si.interval = r_info->interval;
> +        if (r_info->compression)
> +            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
> +        si.save_fd = fd;
> +    }
> +    else
> +        si.save_fd = -1;
> +
>     si.domid = domid;
>     si.flags = flags;
>     si.hvm = hvm;
> @@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
>     }
>
>     memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        /* save_callbacks:
> +         * suspend - called after expiration of checkpoint interval,
> +         *           to *suspend* the domain.
> +         *
> +         * postcopy - called after the domain's dirty pages have been
> +         *            copied into an output buffer. We *resume* the domain
> +         *            & the device model, return to the caller. Caller
> then
> +         *            flushes the output buffer, while the domain
> continues to run.
> +         *
> +         * checkpoint - called after the memory checkpoint has been
> flushed out
> +         *              into the network. Send the saved device state,
> *wait*
> +         *              for checkpoint ack and *release* the network
> buffer (TBD).
> +         *              Then *sleep* for the checkpoint interval.
> +         */
> +        callbacks.suspend = libxl__remus_domain_suspend_callback;
> +        callbacks.postcopy = libxl__remus_domain_resume_callback;
> +        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
> +    } else
> +        callbacks.suspend = libxl__domain_suspend_common_callback;
> +
>     callbacks.switch_qemu_logdirty =
> libxl__domain_suspend_common_switch_qemu_logdirty;
>     callbacks.data = &si;
>
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl_internal.h      Tue Jan 31 20:33:34 2012 -0800
> @@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
>                                          int fd);
>  _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid,
> int fd,
>                                          libxl_domain_type type,
> -                                         int live, int debug);
> +                                         int live, int debug,
> +                                         const libxl_domain_remus_info
> *r_info);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t
> domid);
>  _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t
> domid);
>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t
> domid);
> diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl       Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/libxl_types.idl       Tue Jan 31 20:33:34 2012 -0800
> @@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf",
>     ("extratime", integer),
>     ("weight", integer),
>     ], dispose_fn=None)
> +
> +libxl_domain_remus_info = Struct("domain_remus_info",[
> +    ("interval",     integer),
> +    ("blackhole",    bool),
> +    ("compression",  bool),
> +    ])
>
>
>
>
> ---------- Forwarded message ----------
> From: rshriram@cs.ubc.ca
> To: xen-devel@lists.xensource.com
> Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
> Date: Tue, 31 Jan 2012 20:44:13 -0800
> Subject: [Xen-devel] [PATCH 2 of 2 V2] libxl: Remus - xl remus command
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328070814 28800
> # Node ID cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba
> # Parent  2aa138177f5ef6aa44e6136dd1913441c99aa4b5
> libxl: Remus - xl remus command
>
> xl remus acts as a frontend to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication is
>   supported. Support for disk checkpointing and network buffering will
>   be added in future.
>  * Replication is done over ssh connection currently (like live migration
>   with xl). Future versions will have an option to use simple tcp socket
>   based replication channel (for both Remus & live migration).
>
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> diff -r 2aa138177f5e -r cf47997255f4 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800
> +++ b/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800
> @@ -348,6 +348,39 @@ Send <config> instead of config file fro
>
>  =back
>
> +=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> +
> +Enable Remus HA for domain. By default B<xl> relies on ssh as a transport
> mechanism
> +between the two hosts.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-i> I<MS>
> +
> +Checkpoint domain memory every MS milliseconds (default 200ms).
> +
> +=item B<-b>
> +
> +Replicate memory checkpoints to /dev/null (blackhole).
> +
> +=item B<-u>
> +
> +Disable memory checkpoint compression.
> +
> +=item B<-s> I<sshcommand>
> +
> +Use <sshcommand> instead of ssh.  String will be passed to sh. If empty,
> run
> +<host> instead of ssh <host> xl migrate-receive -r [-e].
> +
> +=item B<-e>
> +
> +On the new host, do not wait in the background (on <host>) for the death
> of the
> +domain. See the corresponding option of the I<create> subcommand.
> +
> +=back
> +
>  =item B<pause> I<domain-id>
>
>  Pause a domain.  When in a paused state the domain will still consume
> diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl.h
> --- a/tools/libxl/xl.h  Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/xl.h  Tue Jan 31 20:33:34 2012 -0800
> @@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
>  int main_getenforce(int argc, char **argv);
>  int main_setenforce(int argc, char **argv);
>  int main_loadpolicy(int argc, char **argv);
> +int main_remus(int argc, char **argv);
>
>  void help(const char *command);
>
> diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Tue Jan 31 20:33:34 2012 -0800
> @@ -2828,7 +2828,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 send_fd, int recv_fd, int remus)
>  {
>     int rc, rc2;
>     char rc_buf;
> @@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i
>         exit(-rc);
>     }
>
> +    if (remus) {
> +        /* If we are here, it means that the sender (primary) has crashed.
> +         * TODO: Split-Brain Check.
> +         */
> +        fprintf(stderr, "migration target: Remus Failover for domain
> %u\n",
> +                domid);
> +
> +        /*
> +         * If domain renaming fails, lets just continue (as we need the
> domain
> +         * to be up & dom names may not matter much, as long as its
> reachable
> +         * over network).
> +         *
> +         * If domain unpausing fails, destroy domain ? Or is it better to
> have
> +         * a consistent copy of the domain (memory, cpu state, disk)
> +         * on atleast one physical host ? Right now, lets just leave the
> domain
> +         * as is and let the Administrator decide (or troubleshoot).
> +         */
> +        if (migration_domname) {
> +            rc = libxl_domain_rename(ctx, domid, migration_domname,
> +                                     common_domname);
> +            if (rc)
> +                fprintf(stderr, "migration target (Remus): "
> +                        "Failed to rename domain from %s to %s:%d\n",
> +                        migration_domname, common_domname, rc);
> +        }
> +
> +        rc = libxl_domain_unpause(ctx, domid);
> +        if (rc)
> +            fprintf(stderr, "migration target (Remus): "
> +                    "Failed to unpause domain %s (id: %u):%d\n",
> +                    common_domname, domid, rc);
> +
> +        exit(rc ? -ERROR_FAIL: 0);
> +    }
> +
>     fprintf(stderr, "migration target: Transfer complete,"
>             " requesting permission to start domain.\n");
>
> @@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)
>
>  int main_migrate_receive(int argc, char **argv)
>  {
> -    int debug = 0, daemonize = 1, monitor = 1;
> +    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
>     int opt;
>
> -    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) !=
> -1) {
> +    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0))
> != -1) {
>         switch (opt) {
>         case 0: case 2:
>             return opt;
> @@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char
>         case 'd':
>             debug = 1;
>             break;
> +        case 'r':
> +            remus = 1;
> +            break;
>         }
>     }
>
> @@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char
>         return 2;
>     }
>     migrate_receive(debug, daemonize, monitor,
> -                    STDOUT_FILENO, STDIN_FILENO);
> +                    STDOUT_FILENO, STDIN_FILENO,
> +                    remus);
>
>     return 0;
>  }
> @@ -5951,6 +5990,106 @@ done:
>     return ret;
>  }
>
> +int main_remus(int argc, char **argv)
> +{
> +    int opt, rc, daemonize = 1;
> +    const char *ssh_command = "ssh";
> +    char *host = NULL, *rune = NULL, *domain = NULL;
> +    libxl_domain_remus_info r_info;
> +    int send_fd = -1, recv_fd = -1;
> +    pid_t child = -1;
> +    uint8_t *config_data;
> +    int config_len;
> +
> +    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
> +    /* Defaults */
> +    r_info.interval = 200;
> +    r_info.blackhole = 0;
> +    r_info.compression = 1;
> +
> +    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
> +        switch (opt) {
> +        case 0: case 2:
> +            return opt;
> +
> +        case 'i':
> +           r_info.interval = atoi(optarg);
> +            break;
> +        case 'b':
> +            r_info.blackhole = 1;
> +            break;
> +        case 'u':
> +           r_info.compression = 0;
> +            break;
> +        case 's':
> +            ssh_command = optarg;
> +            break;
> +        case 'e':
> +            daemonize = 0;
> +            break;
> +        }
> +    }
> +
> +    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");
> +            exit(-1);
> +        }
> +    } else {
> +
> +        /*
> +         * TODO: change this to plain TCP socket based channel
> +         * instead of SSH. For both live-migration and Remus.
> +         */
> +        if (!ssh_command[0]) {
> +            rune = host;
> +        } else {
> +            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
> +                         ssh_command, host,
> +                         daemonize ? "" : " -e") < 0)
> +                return 1;
> +        }
> +
> +        save_domain_core_begin(domain, NULL, &config_data, &config_len);
> +
> +        if (!config_len) {
> +            fprintf(stderr, "No config file stored for running domain and
> "
> +                    "none supplied - cannot start remus.\n");
> +            exit(1);
> +        }
> +
> +        child = create_migration_child(rune, &send_fd, &recv_fd);
> +
> +        migrate_do_preamble(send_fd, recv_fd, child, config_data,
> config_len,
> +                            rune);
> +    }
> +
> +    /* Point of no return */
> +    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
> +
> +    /* If we are here, it means backup has failed/domain suspend failed.
> +     * Try to resume the domain and exit gracefully.
> +     * TODO: Split-Brain check.
> +     */
> +    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
> +            " (rc=%d)\n", rc);
> +
> +    if (rc == ERROR_GUEST_TIMEDOUT)
> +        fprintf(stderr, "Failed to suspend domain at primary.\n");
> +    else {
> +        fprintf(stderr, "Remus: Backup failed? resuming domain at
> primary.\n");
> +        libxl_domain_resume(ctx, domid, 1);
> +    }
> +
> +    close(send_fd);
> +    return -ERROR_FAIL;
> +}
> +
>  /*
>  * Local variables:
>  * mode: C
> diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800
> +++ b/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800
> @@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
>       "Loads a new policy int the Flask Xen security module",
>       "<policy file>",
>     },
> +    { "remus",
> +      &main_remus, 0,
> +      "Enable Remus HA for domain",
> +      "[options] <Domain> [<host>]",
> +      "-i MS                   Checkpoint domain memory every MS
> milliseconds (def. 200ms).\n"
> +      "-b                      Replicate memory checkpoints to /dev/null
> (blackhole)\n"
> +      "-u                      Disable memory checkpoint compression.\n"
> +      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String
> will be passed\n"
> +      "                        to sh. If empty, run <host> instead of \n"
> +      "                        ssh <host> xl migrate-receive -r [-e]\n"
> +      "-e                      Do not wait in the background (on <host>)
> for the death\n"
> +      "                        of the domain."
> +
> +    },
>  };
>
>  int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);
>
>
>
>
> ---------- Forwarded message ----------
> From: xen.org <ian.jackson@eu.citrix.com>
> To: xen-devel@lists.xensource.com
> Cc: ian.jackson@eu.citrix.com
> Date: Wed, 1 Feb 2012 05:52:30 +0000
> Subject: [Xen-devel] [linux test] 11749: regressions - FAIL
> flight 11749 linux real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs.
> 10764
>
> Regressions which are regarded as allowable (not blocking):
>  test-i386-i386-win           14 guest-start.2            fail blocked in
> 10764
>
> 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-xl-win-vcpus1 13 guest-stop                   fail  never
> pass
>  test-amd64-i386-win          16 leak-check/check             fail   never
> pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
> pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never
> pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never
> pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
> pass
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never
> pass
>
> version targeted for testing:
>  linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> baseline version:
>  linux                8664c694e49d4d095706524a27b1fc734b9881ce
>
> ------------------------------------------------------------
> 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-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail
>  test-amd64-amd64-xl-winxpsp3                                 fail
>  test-i386-i386-xl-winxpsp3                                   fail
>
>
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
>    http://www.chiark.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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> Merge: 8664c69... b16a92f...
> Author: Jeremy Fitzhardinge <jeremy@goop.org>
> Date:   Thu Jan 26 13:19:51 2012 -0800
>
>    Merge commit 'v2.6.32.55' into xen/next-2.6.32
>
>    * commit 'v2.6.32.55': (28 commits)
>      Linux 2.6.32.55
>      kprobes: initialize before using a hlist
>      score: fix off-by-one index into syscall table
>      sym53c8xx: Fix NULL pointer dereference in slave_destroy
>      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
>      kernel.h: add printk_ratelimited and pr_<level>_rl
>      block: add and use scsi_blk_cmd_ioctl
>      USB: Fix 'bad dma' problem on WDM device disconnect
>      fix cputime overflow in uptime_proc_show
>      USB: cdc-wdm: fix misuse of logical operation in place of bitop
>      nfsd: Fix oops when parsing a 0 length export
>      svcrpc: destroy server sockets all at once
>      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
>      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
>      i2c: Fix error value returned by several bus drivers
>      UBI: fix nameless volumes handling
>      x86: Fix mmap random address range
>      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
>      ima: free duplicate measurement memory
>      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
>      ...
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

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

<br><br><div class=3D"gmail_quote">On Wed, Feb 1, 2012 at 1:52 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:xen-devel-request@lists.xensource.com">xen=
-devel-request@lists.xensource.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
Send Xen-devel mailing list submissions to<br>
 =A0 =A0 =A0 =A0<a href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@=
lists.xensource.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
 =A0 =A0 =A0 =A0<a href=3D"http://lists.xensource.com/mailman/listinfo/xen-=
devel" target=3D"_blank">http://lists.xensource.com/mailman/listinfo/xen-de=
vel</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
 =A0 =A0 =A0 =A0<a href=3D"mailto:xen-devel-request@lists.xensource.com">xe=
n-devel-request@lists.xensource.com</a><br>
<br>
You can reach the person managing the list at<br>
 =A0 =A0 =A0 =A0<a href=3D"mailto:xen-devel-owner@lists.xensource.com">xen-=
devel-owner@lists.xensource.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of Xen-devel digest...&quot;<br>
<br>Today&#39;s Topics:<br>
<br>
 =A0 1. [PATCH 0 of 2 V2] libxl - Remus support (<a href=3D"mailto:rshriram=
@cs.ubc.ca">rshriram@cs.ubc.ca</a>)<br>
 =A0 2. [PATCH 1 of 2 V2] libxl: Remus - =A0suspend/postflush/commit<br>
 =A0 =A0 =A0callbacks (<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ub=
c.ca</a>)<br>
 =A0 3. [PATCH 2 of 2 V2] libxl: Remus - xl remus command<br>
 =A0 =A0 =A0(<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a>)<=
br>
 =A0 4. [linux test] 11749: regressions - FAIL (<a href=3D"http://xen.org" =
target=3D"_blank">xen.org</a>)<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"mailt=
o:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a><br>To:=A0<a href=3D"mailto:xen=
-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>Cc:=A0<a h=
ref=3D"mailto:brendan@cs.ubc.ca">brendan@cs.ubc.ca</a>, <a href=3D"mailto:i=
an.jackson@eu.citrix.com">ian.jackson@eu.citrix.com</a>, <a href=3D"mailto:=
ian.campbell@citrix.com">ian.campbell@citrix.com</a><br>
Date:=A0Tue, 31 Jan 2012 20:44:11 -0800<br>Subject:=A0[Xen-devel] [PATCH 0 =
of 2 V2] libxl - Remus support<br>This patch series introduces a basic fram=
ework to<br>
incorporate Remus into the libxl toolstack. The only functionality<br>
currently implemented is memory checkpointing.<br>
<br>
These patches depend on Version 2 of<br>
&quot;libxl: refactor suspend/resume code&quot; patch series.<br>
<br>
Changes since previous version:<br>
=A0* Move libxl_domain_remus_start into the save_callbacks implementation p=
atch<br>
=A0* return proper error codes instead of -1.<br>
=A0* Add documentation to docs/man/xl.pod.1<br>
<br>
Shriram<br>
<br>
test for replying to the sender. Sorry for any trouble with you.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"mailt=
o:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a><br>To:=A0<a href=3D"mailto:xen=
-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>Cc:=A0<a h=
ref=3D"mailto:brendan@cs.ubc.ca">brendan@cs.ubc.ca</a>, <a href=3D"mailto:i=
an.jackson@eu.citrix.com">ian.jackson@eu.citrix.com</a>, <a href=3D"mailto:=
ian.campbell@citrix.com">ian.campbell@citrix.com</a><br>
Date:=A0Tue, 31 Jan 2012 20:44:12 -0800<br>Subject:=A0[Xen-devel] [PATCH 1 =
of 2 V2] libxl: Remus - suspend/postflush/commit callbacks<br># HG changese=
t patch<br>
# User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshrir=
am@cs.ubc.ca</a>&gt;<br>
# Date 1328070814 28800<br>
# Node ID 2aa138177f5ef6aa44e6136dd1913441c99aa4b5<br>
# Parent =A0545f88c2bc73b063a5d0e7adbd95baed4d93790f<br>
libxl: Remus - suspend/postflush/commit callbacks<br>
<br>
=A0* Add libxl callback functions for Remus checkpoint suspend, postflush<b=
r>
 =A0 (aka resume) and checkpoint commit callbacks.<br>
=A0* suspend callback is a stub that just bounces off<br>
 =A0 libxl__domain_suspend_common_callback - which suspends the domain and<=
br>
 =A0 saves the devices model state to a file.<br>
=A0* resume callback currently just resumes the domain (and the device mode=
l).<br>
=A0* commit callback just writes out the saved device model state to the<br=
>
 =A0 network and sleeps for the checkpoint interval.<br>
=A0* Introduce a new public API, libxl_domain_remus_start (currently a stub=
)<br>
 =A0 that sets up the network and disk buffer and initiates continuous<br>
 =A0 checkpointing.<br>
<br>
=A0* Future patches will augument these callbacks/functions with more funct=
ionalities<br>
 =A0 like issuing network buffer plug/unplug commands, disk checkpoint comm=
ands, etc.<br>
<br>
Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca=
">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.c<br>
--- a/tools/libxl/libxl.c =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/libxl.c =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -480,6 +480,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *<br>
 =A0 =A0 return ptr;<br>
=A0}<br>
<br>
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */<br>
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info=
,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid, i=
nt send_fd, int recv_fd)<br>
+{<br>
+ =A0 =A0GC_INIT(ctx);<br>
+ =A0 =A0libxl_domain_type type =3D libxl__domain_type(gc, domid);<br>
+ =A0 =A0int rc =3D 0;<br>
+<br>
+ =A0 =A0if (info =3D=3D NULL) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;No remus_info structure supplie=
d for domain %d&quot;, domid);<br>
+ =A0 =A0 =A0 =A0rc =3D ERROR_INVAL;<br>
+ =A0 =A0 =A0 =A0goto remus_fail;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0/* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, et=
c */<br>
+<br>
+ =A0 =A0/* Point of no return */<br>
+ =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, send_fd, type, /* l=
ive */ 1,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0/* debug */ 0, info);<br>
+<br>
+ =A0 =A0/*<br>
+ =A0 =A0 * With Remus, if we reach this point, it means either<br>
+ =A0 =A0 * backup died or some network error occurred preventing us<br>
+ =A0 =A0 * from sending checkpoints.<br>
+ =A0 =A0 */<br>
+<br>
+ =A0 =A0/* TBD: Remus cleanup - i.e. detach qdisc, release other<br>
+ =A0 =A0 * resources.<br>
+ =A0 =A0 */<br>
+ remus_fail:<br>
+ =A0 =A0GC_FREE;<br>
+ =A0 =A0return rc;<br>
+}<br>
+<br>
=A0int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info=
,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t domid, int fd)=
<br>
=A0{<br>
@@ -489,7 +524,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,<br>
 =A0 =A0 int debug =3D info !=3D NULL &amp;&amp; info-&gt;flags &amp; XL_SU=
SPEND_DEBUG;<br>
 =A0 =A0 int rc =3D 0;<br>
<br>
- =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, fd, type, live, deb=
ug);<br>
+ =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, fd, type, live, deb=
ug,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0/* No Remus */ NULL);<br>
+<br>
 =A0 =A0 if (!rc &amp;&amp; type =3D=3D LIBXL_DOMAIN_TYPE_HVM)<br>
 =A0 =A0 =A0 =A0 rc =3D libxl__domain_save_device_model(gc, domid, fd);<br>
 =A0 =A0 GC_FREE;<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl.h<br>
--- a/tools/libxl/libxl.h =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/libxl.h =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl<br>
=A0int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_confi=
g, libxl_console_ready cb, void *priv, uint32_t *domid);<br>
=A0int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_c=
onfig, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd)=
;<br>
=A0void libxl_domain_config_dispose(libxl_domain_config *d_config);<br>
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info=
,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid, i=
nt send_fd, int recv_fd);<br>
=A0int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info=
,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid, int fd=
);<br>
=A0int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_canc=
el);<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_dom.c<br>
--- a/tools/libxl/libxl_dom.c =A0 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/libxl_dom.c =A0 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -404,6 +404,8 @@ struct suspendinfo {<br>
 =A0 =A0 int hvm;<br>
 =A0 =A0 unsigned int flags;<br>
 =A0 =A0 int guest_responded;<br>
+ =A0 =A0int save_fd; /* Migration stream fd (for Remus) */<br>
+ =A0 =A0int interval; /* checkpoint interval (for Remus) */<br>
=A0};<br>
<br>
=A0static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, =
unsigned int enable, void *data)<br>
@@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_<br>
 =A0 =A0 return 1;<br>
=A0}<br>
<br>
+static int libxl__remus_domain_suspend_callback(void *data)<br>
+{<br>
+ =A0 =A0/* TODO: Issue disk and network checkpoint reqs. */<br>
+ =A0 =A0return libxl__domain_suspend_common_callback(data);<br>
+}<br>
+<br>
+static int libxl__remus_domain_resume_callback(void *data)<br>
+{<br>
+ =A0 =A0struct suspendinfo *si =3D data;<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(si-&gt;gc);<br>
+<br>
+ =A0 =A0/* Resumes the domain and the device model */<br>
+ =A0 =A0if (libxl_domain_resume(ctx, si-&gt;domid, /* Fast Suspend */1))<b=
r>
+ =A0 =A0 =A0 =A0return 0;<br>
+<br>
+ =A0 =A0/* TODO: Deal with disk. Start a new network output buffer */<br>
+ =A0 =A0return 1;<br>
+}<br>
+<br>
+static int libxl__remus_domain_checkpoint_callback(void *data)<br>
+{<br>
+ =A0 =A0struct suspendinfo *si =3D data;<br>
+<br>
+ =A0 =A0/* This would go into tailbuf. */<br>
+ =A0 =A0if (si-&gt;hvm &amp;&amp;<br>
+ =A0 =A0 =A0 =A0libxl__domain_save_device_model(si-&gt;gc, si-&gt;domid, s=
i-&gt;save_fd))<br>
+ =A0 =A0 =A0 =A0return 0;<br>
+<br>
+ =A0 =A0/* TODO: Wait for disk and memory ack, release network buffer */<b=
r>
+ =A0 =A0usleep(si-&gt;interval * 1000);<br>
+ =A0 =A0return 1;<br>
+}<br>
+<br>
=A0int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,<=
br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_d=
omain_type type,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int live,=
 int debug)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int live,=
 int debug,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const lib=
xl_domain_remus_info *r_info)<br>
=A0{<br>
 =A0 =A0 libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
 =A0 =A0 int flags;<br>
@@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 =A0 =A0 return ERROR_INVAL;<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0memset(&amp;si, 0, sizeof(si));<br>
 =A0 =A0 flags =3D (live) ? XCFLAGS_LIVE : 0<br>
 =A0 =A0 =A0 =A0 =A0 | (debug) ? XCFLAGS_DEBUG : 0<br>
 =A0 =A0 =A0 =A0 =A0 | (hvm) ? XCFLAGS_HVM : 0;<br>
<br>
+ =A0 =A0if (r_info !=3D NULL) {<br>
+ =A0 =A0 =A0 =A0si.interval =3D r_info-&gt;interval;<br>
+ =A0 =A0 =A0 =A0if (r_info-&gt;compression)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0flags |=3D XCFLAGS_CHECKPOINT_COMPRESS;<br>
+ =A0 =A0 =A0 =A0si.save_fd =3D fd;<br>
+ =A0 =A0}<br>
+ =A0 =A0else<br>
+ =A0 =A0 =A0 =A0si.save_fd =3D -1;<br>
+<br>
 =A0 =A0 si.domid =3D domid;<br>
 =A0 =A0 si.flags =3D flags;<br>
 =A0 =A0 si.hvm =3D hvm;<br>
@@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 memset(&amp;callbacks, 0, sizeof(callbacks));<br>
- =A0 =A0callbacks.suspend =3D libxl__domain_suspend_common_callback;<br>
+ =A0 =A0if (r_info !=3D NULL) {<br>
+ =A0 =A0 =A0 =A0/* save_callbacks:<br>
+ =A0 =A0 =A0 =A0 * suspend - called after expiration of checkpoint interva=
l,<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 to *suspend* the domain.<br>
+ =A0 =A0 =A0 =A0 *<br>
+ =A0 =A0 =A0 =A0 * postcopy - called after the domain&#39;s dirty pages ha=
ve been<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0copied into an output buffer. We=
 *resume* the domain<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0&amp; the device model, return t=
o the caller. Caller then<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0flushes the output buffer, while=
 the domain continues to run.<br>
+ =A0 =A0 =A0 =A0 *<br>
+ =A0 =A0 =A0 =A0 * checkpoint - called after the memory checkpoint has bee=
n flushed out<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0into the network. Send the s=
aved device state, *wait*<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0for checkpoint ack and *rele=
ase* the network buffer (TBD).<br>
+ =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0Then *sleep* for the checkpo=
int interval.<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0callbacks.suspend =3D libxl__remus_domain_suspend_callback=
;<br>
+ =A0 =A0 =A0 =A0callbacks.postcopy =3D libxl__remus_domain_resume_callback=
;<br>
+ =A0 =A0 =A0 =A0callbacks.checkpoint =3D libxl__remus_domain_checkpoint_ca=
llback;<br>
+ =A0 =A0} else<br>
+ =A0 =A0 =A0 =A0callbacks.suspend =3D libxl__domain_suspend_common_callbac=
k;<br>
+<br>
 =A0 =A0 callbacks.switch_qemu_logdirty =3D libxl__domain_suspend_common_sw=
itch_qemu_logdirty;<br>
 =A0 =A0 callbacks.data =3D &amp;si;<br>
<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_internal.h<br>
--- a/tools/libxl/libxl_internal.h =A0 =A0 =A0Tue Jan 31 20:33:34 2012 -080=
0<br>
+++ b/tools/libxl/libxl_internal.h =A0 =A0 =A0Tue Jan 31 20:33:34 2012 -080=
0<br>
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0int fd);<br>
=A0_hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, =
int fd,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0libxl_domain_type type,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 int live, int debug);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 int live, int debug,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 const libxl_domain_remus_info *r_info);<br>
=A0_hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t=
 domid);<br>
=A0_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t d=
omid);<br>
=A0_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t do=
mid);<br>
diff -r 545f88c2bc73 -r 2aa138177f5e tools/libxl/libxl_types.idl<br>
--- a/tools/libxl/libxl_types.idl =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -080=
0<br>
+++ b/tools/libxl/libxl_types.idl =A0 =A0 =A0 Tue Jan 31 20:33:34 2012 -080=
0<br>
@@ -397,3 +397,9 @@ libxl_sched_sedf =3D Struct(&quot;sched_sedf&quot;,<br>
 =A0 =A0 (&quot;extratime&quot;, integer),<br>
 =A0 =A0 (&quot;weight&quot;, integer),<br>
 =A0 =A0 ], dispose_fn=3DNone)<br>
+<br>
+libxl_domain_remus_info =3D Struct(&quot;domain_remus_info&quot;,[<br>
+ =A0 =A0(&quot;interval&quot;, =A0 =A0 integer),<br>
+ =A0 =A0(&quot;blackhole&quot;, =A0 =A0bool),<br>
+ =A0 =A0(&quot;compression&quot;, =A0bool),<br>
+ =A0 =A0])<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"mailt=
o:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a><br>To:=A0<a href=3D"mailto:xen=
-devel@lists.xensource.com">xen-devel@lists.xensource.com</a><br>Cc:=A0<a h=
ref=3D"mailto:brendan@cs.ubc.ca">brendan@cs.ubc.ca</a>, <a href=3D"mailto:i=
an.jackson@eu.citrix.com">ian.jackson@eu.citrix.com</a>, <a href=3D"mailto:=
ian.campbell@citrix.com">ian.campbell@citrix.com</a><br>
Date:=A0Tue, 31 Jan 2012 20:44:13 -0800<br>Subject:=A0[Xen-devel] [PATCH 2 =
of 2 V2] libxl: Remus - xl remus command<br># HG changeset patch<br>
# User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshrir=
am@cs.ubc.ca</a>&gt;<br>
# Date 1328070814 28800<br>
# Node ID cf47997255f4a895ce6a9f0f3cd7fc3eaa0b42ba<br>
# Parent =A02aa138177f5ef6aa44e6136dd1913441c99aa4b5<br>
libxl: Remus - xl remus command<br>
<br>
xl remus acts as a frontend to enable remus for a given domain.<br>
=A0* At the moment, only memory checkpointing and blackhole replication is<=
br>
 =A0 supported. Support for disk checkpointing and network buffering will<b=
r>
 =A0 be added in future.<br>
=A0* Replication is done over ssh connection currently (like live migration=
<br>
 =A0 with xl). Future versions will have an option to use simple tcp socket=
<br>
 =A0 based replication channel (for both Remus &amp; live migration).<br>
<br>
Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca=
">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
diff -r 2aa138177f5e -r cf47997255f4 docs/man/xl.pod.1<br>
--- a/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/docs/man/xl.pod.1 Tue Jan 31 20:33:34 2012 -0800<br>
@@ -348,6 +348,39 @@ Send &lt;config&gt; instead of config file fro<br>
<br>
=A0=3Dback<br>
<br>
+=3Ditem B&lt;remus&gt; [I&lt;OPTIONS&gt;] I&lt;domain-id&gt; I&lt;host&gt;=
<br>
+<br>
+Enable Remus HA for domain. By default B&lt;xl&gt; relies on ssh as a tran=
sport mechanism<br>
+between the two hosts.<br>
+<br>
+B&lt;OPTIONS&gt;<br>
+<br>
+=3Dover 4<br>
+<br>
+=3Ditem B&lt;-i&gt; I&lt;MS&gt;<br>
+<br>
+Checkpoint domain memory every MS milliseconds (default 200ms).<br>
+<br>
+=3Ditem B&lt;-b&gt;<br>
+<br>
+Replicate memory checkpoints to /dev/null (blackhole).<br>
+<br>
+=3Ditem B&lt;-u&gt;<br>
+<br>
+Disable memory checkpoint compression.<br>
+<br>
+=3Ditem B&lt;-s&gt; I&lt;sshcommand&gt;<br>
+<br>
+Use &lt;sshcommand&gt; instead of ssh. =A0String will be passed to sh. If =
empty, run<br>
+&lt;host&gt; instead of ssh &lt;host&gt; xl migrate-receive -r [-e].<br>
+<br>
+=3Ditem B&lt;-e&gt;<br>
+<br>
+On the new host, do not wait in the background (on &lt;host&gt;) for the d=
eath of the<br>
+domain. See the corresponding option of the I&lt;create&gt; subcommand.<br=
>
+<br>
+=3Dback<br>
+<br>
=A0=3Ditem B&lt;pause&gt; I&lt;domain-id&gt;<br>
<br>
=A0Pause a domain. =A0When in a paused state the domain will still consume<=
br>
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl.h<br>
--- a/tools/libxl/xl.h =A0Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/xl.h =A0Tue Jan 31 20:33:34 2012 -0800<br>
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char<br>
=A0int main_getenforce(int argc, char **argv);<br>
=A0int main_setenforce(int argc, char **argv);<br>
=A0int main_loadpolicy(int argc, char **argv);<br>
+int main_remus(int argc, char **argv);<br>
<br>
=A0void help(const char *command);<br>
<br>
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdimpl.c<br>
--- a/tools/libxl/xl_cmdimpl.c =A0Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/xl_cmdimpl.c =A0Tue Jan 31 20:33:34 2012 -0800<br>
@@ -2828,7 +2828,7 @@ static void core_dump_domain(const char<br>
=A0}<br>
<br>
=A0static void migrate_receive(int debug, int daemonize, int monitor,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int send_fd, int r=
ecv_fd)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int send_fd, int r=
ecv_fd, int remus)<br>
=A0{<br>
 =A0 =A0 int rc, rc2;<br>
 =A0 =A0 char rc_buf;<br>
@@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i<br>
 =A0 =A0 =A0 =A0 exit(-rc);<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0if (remus) {<br>
+ =A0 =A0 =A0 =A0/* If we are here, it means that the sender (primary) has =
crashed.<br>
+ =A0 =A0 =A0 =A0 * TODO: Split-Brain Check.<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target: Remus Failover for=
 domain %u\n&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<br>
+<br>
+ =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 * If domain renaming fails, lets just continue (as we nee=
d the domain<br>
+ =A0 =A0 =A0 =A0 * to be up &amp; dom names may not matter much, as long a=
s its reachable<br>
+ =A0 =A0 =A0 =A0 * over network).<br>
+ =A0 =A0 =A0 =A0 *<br>
+ =A0 =A0 =A0 =A0 * If domain unpausing fails, destroy domain ? Or is it be=
tter to have<br>
+ =A0 =A0 =A0 =A0 * a consistent copy of the domain (memory, cpu state, dis=
k)<br>
+ =A0 =A0 =A0 =A0 * on atleast one physical host ? Right now, lets just lea=
ve the domain<br>
+ =A0 =A0 =A0 =A0 * as is and let the Administrator decide (or troubleshoot=
).<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0if (migration_domname) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0rc =3D libxl_domain_rename(ctx, domid, migration_d=
omname,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 c=
ommon_domname);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if (rc)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Re=
mus): &quot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to rename dom=
ain from %s to %s:%d\n&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0migration_domname, common_=
domname, rc);<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0rc =3D libxl_domain_unpause(ctx, domid);<br>
+ =A0 =A0 =A0 =A0if (rc)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus): &q=
uot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to unpause domain %s =
(id: %u):%d\n&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0common_domname, domid, rc);<br>
+<br>
+ =A0 =A0 =A0 =A0exit(rc ? -ERROR_FAIL: 0);<br>
+ =A0 =A0}<br>
+<br>
 =A0 =A0 fprintf(stderr, &quot;migration target: Transfer complete,&quot;<b=
r>
 =A0 =A0 =A0 =A0 =A0 =A0 &quot; requesting permission to start domain.\n&qu=
ot;);<br>
<br>
@@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)<br>
<br>
=A0int main_migrate_receive(int argc, char **argv)<br>
=A0{<br>
- =A0 =A0int debug =3D 0, daemonize =3D 1, monitor =3D 1;<br>
+ =A0 =A0int debug =3D 0, daemonize =3D 1, monitor =3D 1, remus =3D 0;<br>
 =A0 =A0 int opt;<br>
<br>
- =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;Fed&quot;, &quot;migr=
ate-receive&quot;, 0)) !=3D -1) {<br>
+ =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;Fedr&quot;, &quot;mig=
rate-receive&quot;, 0)) !=3D -1) {<br>
 =A0 =A0 =A0 =A0 switch (opt) {<br>
 =A0 =A0 =A0 =A0 case 0: case 2:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return opt;<br>
@@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char<br>
 =A0 =A0 =A0 =A0 case &#39;d&#39;:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 debug =3D 1;<br>
 =A0 =A0 =A0 =A0 =A0 =A0 break;<br>
+ =A0 =A0 =A0 =A0case &#39;r&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0remus =3D 1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 }<br>
<br>
@@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char<br>
 =A0 =A0 =A0 =A0 return 2;<br>
 =A0 =A0 }<br>
 =A0 =A0 migrate_receive(debug, daemonize, monitor,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0STDOUT_FILENO, STDIN_FILENO);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0STDOUT_FILENO, STDIN_FILENO,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remus);<br>
<br>
 =A0 =A0 return 0;<br>
=A0}<br>
@@ -5951,6 +5990,106 @@ done:<br>
 =A0 =A0 return ret;<br>
=A0}<br>
<br>
+int main_remus(int argc, char **argv)<br>
+{<br>
+ =A0 =A0int opt, rc, daemonize =3D 1;<br>
+ =A0 =A0const char *ssh_command =3D &quot;ssh&quot;;<br>
+ =A0 =A0char *host =3D NULL, *rune =3D NULL, *domain =3D NULL;<br>
+ =A0 =A0libxl_domain_remus_info r_info;<br>
+ =A0 =A0int send_fd =3D -1, recv_fd =3D -1;<br>
+ =A0 =A0pid_t child =3D -1;<br>
+ =A0 =A0uint8_t *config_data;<br>
+ =A0 =A0int config_len;<br>
+<br>
+ =A0 =A0memset(&amp;r_info, 0, sizeof(libxl_domain_remus_info));<br>
+ =A0 =A0/* Defaults */<br>
+ =A0 =A0r_info.interval =3D 200;<br>
+ =A0 =A0r_info.blackhole =3D 0;<br>
+ =A0 =A0r_info.compression =3D 1;<br>
+<br>
+ =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;bui:s:e&quot;, &quot;=
remus&quot;, 2)) !=3D -1) {<br>
+ =A0 =A0 =A0 =A0switch (opt) {<br>
+ =A0 =A0 =A0 =A0case 0: case 2:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return opt;<br>
+<br>
+ =A0 =A0 =A0 =A0case &#39;i&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 r_info.interval =3D atoi(optarg);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;b&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0r_info.blackhole =3D 1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;u&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 r_info.compression =3D 0;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;s&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0ssh_command =3D optarg;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0case &#39;e&#39;:<br>
+ =A0 =A0 =A0 =A0 =A0 =A0daemonize =3D 0;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0domain =3D argv[optind];<br>
+ =A0 =A0host =3D argv[optind + 1];<br>
+<br>
+ =A0 =A0if (r_info.blackhole) {<br>
+ =A0 =A0 =A0 =A0find_domain(domain);<br>
+ =A0 =A0 =A0 =A0send_fd =3D open(&quot;/dev/null&quot;, O_RDWR, 0644);<br>
+ =A0 =A0 =A0 =A0if (send_fd &lt; 0) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0perror(&quot;failed to open /dev/null&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0exit(-1);<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0} else {<br>
+<br>
+ =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 * TODO: change this to plain TCP socket based channel<br>
+ =A0 =A0 =A0 =A0 * instead of SSH. For both live-migration and Remus.<br>
+ =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0if (!ssh_command[0]) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0rune =3D host;<br>
+ =A0 =A0 =A0 =A0} else {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if (asprintf(&amp;rune, &quot;exec %s %s xl migrat=
e-receive -r %s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssh_command, host,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 daemonize ? &quot;&quot; =
: &quot; -e&quot;) &lt; 0)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0save_domain_core_begin(domain, NULL, &amp;config_data, &am=
p;config_len);<br>
+<br>
+ =A0 =A0 =A0 =A0if (!config_len) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;No config file stored for ru=
nning domain and &quot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;none supplied - cannot start=
 remus.\n&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0exit(1);<br>
+ =A0 =A0 =A0 =A0}<br>
+<br>
+ =A0 =A0 =A0 =A0child =3D create_migration_child(rune, &amp;send_fd, &amp;=
recv_fd);<br>
+<br>
+ =A0 =A0 =A0 =A0migrate_do_preamble(send_fd, recv_fd, child, config_data, =
config_len,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rune);<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0/* Point of no return */<br>
+ =A0 =A0rc =3D libxl_domain_remus_start(ctx, &amp;r_info, domid, send_fd, =
recv_fd);<br>
+<br>
+ =A0 =A0/* If we are here, it means backup has failed/domain suspend faile=
d.<br>
+ =A0 =A0 * Try to resume the domain and exit gracefully.<br>
+ =A0 =A0 * TODO: Split-Brain check.<br>
+ =A0 =A0 */<br>
+ =A0 =A0fprintf(stderr, &quot;remus sender: libxl_domain_suspend failed&qu=
ot;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0&quot; (rc=3D%d)\n&quot;, rc);<br>
+<br>
+ =A0 =A0if (rc =3D=3D ERROR_GUEST_TIMEDOUT)<br>
+ =A0 =A0 =A0 =A0fprintf(stderr, &quot;Failed to suspend domain at primary.=
\n&quot;);<br>
+ =A0 =A0else {<br>
+ =A0 =A0 =A0 =A0fprintf(stderr, &quot;Remus: Backup failed? resuming domai=
n at primary.\n&quot;);<br>
+ =A0 =A0 =A0 =A0libxl_domain_resume(ctx, domid, 1);<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0close(send_fd);<br>
+ =A0 =A0return -ERROR_FAIL;<br>
+}<br>
+<br>
=A0/*<br>
 =A0* Local variables:<br>
 =A0* mode: C<br>
diff -r 2aa138177f5e -r cf47997255f4 tools/libxl/xl_cmdtable.c<br>
--- a/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800<br>
+++ b/tools/libxl/xl_cmdtable.c Tue Jan 31 20:33:34 2012 -0800<br>
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] =3D {<br>
 =A0 =A0 =A0 &quot;Loads a new policy int the Flask Xen security module&quo=
t;,<br>
 =A0 =A0 =A0 &quot;&lt;policy file&gt;&quot;,<br>
 =A0 =A0 },<br>
+ =A0 =A0{ &quot;remus&quot;,<br>
+ =A0 =A0 =A0&amp;main_remus, 0,<br>
+ =A0 =A0 =A0&quot;Enable Remus HA for domain&quot;,<br>
+ =A0 =A0 =A0&quot;[options] &lt;Domain&gt; [&lt;host&gt;]&quot;,<br>
+ =A0 =A0 =A0&quot;-i MS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Checkpoint dom=
ain memory every MS milliseconds (def. 200ms).\n&quot;<br>
+ =A0 =A0 =A0&quot;-b =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Replicate =
memory checkpoints to /dev/null (blackhole)\n&quot;<br>
+ =A0 =A0 =A0&quot;-u =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Disable me=
mory checkpoint compression.\n&quot;<br>
+ =A0 =A0 =A0&quot;-s &lt;sshcommand&gt; =A0 =A0 =A0 =A0 Use &lt;sshcommand=
&gt; instead of ssh. =A0String will be passed\n&quot;<br>
+ =A0 =A0 =A0&quot; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to sh. I=
f empty, run &lt;host&gt; instead of \n&quot;<br>
+ =A0 =A0 =A0&quot; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ssh &lt;=
host&gt; xl migrate-receive -r [-e]\n&quot;<br>
+ =A0 =A0 =A0&quot;-e =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Do not wai=
t in the background (on &lt;host&gt;) for the death\n&quot;<br>
+ =A0 =A0 =A0&quot; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of the d=
omain.&quot;<br>
+<br>
+ =A0 =A0},<br>
=A0};<br>
<br>
=A0int cmdtable_len =3D sizeof(cmd_table)/sizeof(struct cmd_spec);<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=A0<a href=3D"http:=
//xen.org">xen.org</a> &lt;<a href=3D"mailto:ian.jackson@eu.citrix.com">ian=
.jackson@eu.citrix.com</a>&gt;<br>To:=A0<a href=3D"mailto:xen-devel@lists.x=
ensource.com">xen-devel@lists.xensource.com</a><br>
Cc:=A0<a href=3D"mailto:ian.jackson@eu.citrix.com">ian.jackson@eu.citrix.co=
m</a><br>Date:=A0Wed, 1 Feb 2012 05:52:30 +0000<br>Subject:=A0[Xen-devel] [=
linux test] 11749: regressions - FAIL<br>flight 11749 linux real [real]<br>
<a href=3D"http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/" target=
=3D"_blank">http://www.chiark.greenend.org.uk/~xensrcts/logs/11749/</a><br>
<br>
Regressions :-(<br>
<br>
Tests which did not succeed and are blocking,<br>
including tests which could not be run:<br>
=A0test-amd64-i386-xl-credit2 =A0 =A07 debian-install =A0 =A0 =A0 =A0 =A0 =
=A0fail REGR. vs. 10764<br>
<br>
Regressions which are regarded as allowable (not blocking):<br>
=A0test-i386-i386-win =A0 =A0 =A0 =A0 =A0 14 guest-start.2 =A0 =A0 =A0 =A0 =
=A0 =A0fail blocked in 10764<br>
<br>
Tests which did not succeed, but are not blocking:<br>
=A0test-amd64-i386-rhel6hvm-amd 11 leak-check/check =A0 =A0 =A0 =A0 =A0 =A0=
 fail =A0 never pass<br>
=A0test-amd64-i386-rhel6hvm-intel 11 leak-check/check =A0 =A0 =A0 =A0 =A0 =
=A0 fail never pass<br>
=A0test-amd64-i386-xl-win-vcpus1 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 fail =A0never pass<br>
=A0test-amd64-i386-win =A0 =A0 =A0 =A0 =A016 leak-check/check =A0 =A0 =A0 =
=A0 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-i386-xl-win7-amd64 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 fail =A0never pass<br>
=A0test-amd64-i386-win-vcpus1 =A0 16 leak-check/check =A0 =A0 =A0 =A0 =A0 =
=A0 fail =A0 never pass<br>
=A0test-i386-i386-xl-winxpsp3 =A0 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 fail never pass<br>
=A0test-amd64-amd64-xl-winxpsp3 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 fail =A0 never pass<br>
=A0test-amd64-amd64-xl-win =A0 =A0 =A013 guest-stop =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-i386-xend-winxpsp3 16 leak-check/check =A0 =A0 =A0 =A0 =A0 =
=A0 fail =A0never pass<br>
=A0test-amd64-amd64-win =A0 =A0 =A0 =A0 16 leak-check/check =A0 =A0 =A0 =A0=
 =A0 =A0 fail =A0 never pass<br>
=A0test-amd64-amd64-xl-pcipt-intel =A09 guest-start =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 fail never pass<br>
=A0test-amd64-amd64-xl-win7-amd64 13 guest-stop =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 fail never pass<br>
=A0test-i386-i386-xl-win =A0 =A0 =A0 =A013 guest-stop =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 fail =A0 never pass<br>
<br>
version targeted for testing:<br>
=A0linux =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01aaf53ee291d9e71d6ec05c0ebdb2854fea=
175ad<br>
baseline version:<br>
=A0linux =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A08664c694e49d4d095706524a27b1fc734b9=
881ce<br>
<br>
------------------------------------------------------------<br>
People who touched revisions under test:<br>
------------------------------------------------------------<br>
<br>
jobs:<br>
=A0build-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0build-i386 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0build-amd64-pvops =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0build-i386-pvops =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-amd64-xl =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-xl =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-i386-i386-xl =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-rhel6hvm-amd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-xl-win7-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-xl-win7-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-xl-credit2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-xl-pcipt-intel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-rhel6hvm-intel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-xl-multivcpu =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-amd64-pair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-pair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-i386-i386-pair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-amd64-xl-sedf-pin =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-amd64-pv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-i386-pv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-i386-i386-pv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pass<br>
=A0test-amd64-amd64-xl-sedf =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 pass<br>
=A0test-amd64-i386-win-vcpus1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-xl-win-vcpus1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-xl-winxpsp3-vcpus1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-i386-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-i386-i386-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-amd64-amd64-xl-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-i386-i386-xl-win =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-i386-xend-winxpsp3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0fail<br>
=A0test-amd64-amd64-xl-winxpsp3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 fail<br>
=A0test-i386-i386-xl-winxpsp3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 fail<br>
<br>
<br>
------------------------------------------------------------<br>
sg-report-flight on <a href=3D"http://woking.cam.xci-test.com" target=3D"_b=
lank">woking.cam.xci-test.com</a><br>
logs: /home/xc_osstest/logs<br>
images: /home/xc_osstest/images<br>
<br>
Logs, config files, etc. are available at<br>
 =A0 =A0<a href=3D"http://www.chiark.greenend.org.uk/~xensrcts/logs" target=
=3D"_blank">http://www.chiark.greenend.org.uk/~xensrcts/logs</a><br>
<br>
Test harness code can be found at<br>
 =A0 =A0<a href=3D"http://xenbits.xensource.com/gitweb?p=3Dosstest.git;a=3D=
summary" target=3D"_blank">http://xenbits.xensource.com/gitweb?p=3Dosstest.=
git;a=3Dsummary</a><br>
<br>
<br>
Not pushing.<br>
<br>
------------------------------------------------------------<br>
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad<br>
Merge: 8664c69... b16a92f...<br>
Author: Jeremy Fitzhardinge &lt;<a href=3D"mailto:jeremy@goop.org">jeremy@g=
oop.org</a>&gt;<br>
Date: =A0 Thu Jan 26 13:19:51 2012 -0800<br>
<br>
 =A0 =A0Merge commit &#39;v2.6.32.55&#39; into xen/next-2.6.32<br>
<br>
 =A0 =A0* commit &#39;v2.6.32.55&#39;: (28 commits)<br>
 =A0 =A0 =A0Linux 2.6.32.55<br>
 =A0 =A0 =A0kprobes: initialize before using a hlist<br>
 =A0 =A0 =A0score: fix off-by-one index into syscall table<br>
 =A0 =A0 =A0sym53c8xx: Fix NULL pointer dereference in slave_destroy<br>
 =A0 =A0 =A0ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645<b=
r>
 =A0 =A0 =A0kernel.h: add printk_ratelimited and pr_&lt;level&gt;_rl<br>
 =A0 =A0 =A0block: add and use scsi_blk_cmd_ioctl<br>
 =A0 =A0 =A0USB: Fix &#39;bad dma&#39; problem on WDM device disconnect<br>
 =A0 =A0 =A0fix cputime overflow in uptime_proc_show<br>
 =A0 =A0 =A0USB: cdc-wdm: fix misuse of logical operation in place of bitop=
<br>
 =A0 =A0 =A0nfsd: Fix oops when parsing a 0 length export<br>
 =A0 =A0 =A0svcrpc: destroy server sockets all at once<br>
 =A0 =A0 =A0svcrpc: fix double-free on shutdown of nfsd after changing pool=
 mode<br>
 =A0 =A0 =A0V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()<br>
 =A0 =A0 =A0i2c: Fix error value returned by several bus drivers<br>
 =A0 =A0 =A0UBI: fix nameless volumes handling<br>
 =A0 =A0 =A0x86: Fix mmap random address range<br>
 =A0 =A0 =A0PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks U=
SB<br>
 =A0 =A0 =A0ima: free duplicate measurement memory<br>
 =A0 =A0 =A0xen/xenbus: Reject replies with payload &gt; XENSTORE_PAYLOAD_M=
AX.<br>
 =A0 =A0 =A0...<br>
<br>
<br>
<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br>

--20cf30363f4b1ecd2e04b7e1308d--


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

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

--===============3167636507460871122==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 07:51:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 07: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.xensource.com>)
	id 1RsUyC-00057a-QY; Wed, 01 Feb 2012 07:51:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RsUyB-00057V-CI
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 07:51:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328082661!12045851!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTgyMTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14680 invoked from network); 1 Feb 2012 07:51:01 -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; 1 Feb 2012 07:51:01 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id B5636110D;
	Wed,  1 Feb 2012 09:51:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 93B9820058; Wed,  1 Feb 2012 09:51:00 +0200 (EET)
Date: Wed, 1 Feb 2012 09:51:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120201075100.GK12984@reaktio.net>
References: <4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] about page cache architecture of the dom0 and	domUs
	in xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 11:50:06AM +0800, hxkhust wrote:
>    Hi,
>    I encounter a problem that has puzzled me for a long time.On a Xen
>    virtualization platform, some VMs ,whose virtual disks are image files
>    ,are running in DomUs.Under this situation ,does the Dom0 cache the pages
>    from the VMs?Does the filesystem in Dom0 see the VMs as general processes?
> 

It depends which disk backend driver you're using for the domU disks..
(file: or tap:aio:)

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 07:51:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 07: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.xensource.com>)
	id 1RsUyC-00057a-QY; Wed, 01 Feb 2012 07:51:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RsUyB-00057V-CI
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 07:51:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328082661!12045851!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTgyMTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14680 invoked from network); 1 Feb 2012 07:51:01 -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; 1 Feb 2012 07:51:01 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id B5636110D;
	Wed,  1 Feb 2012 09:51:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 93B9820058; Wed,  1 Feb 2012 09:51:00 +0200 (EET)
Date: Wed, 1 Feb 2012 09:51:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120201075100.GK12984@reaktio.net>
References: <4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] about page cache architecture of the dom0 and	domUs
	in xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 11:50:06AM +0800, hxkhust wrote:
>    Hi,
>    I encounter a problem that has puzzled me for a long time.On a Xen
>    virtualization platform, some VMs ,whose virtual disks are image files
>    ,are running in DomUs.Under this situation ,does the Dom0 cache the pages
>    from the VMs?Does the filesystem in Dom0 see the VMs as general processes?
> 

It depends which disk backend driver you're using for the domU disks..
(file: or tap:aio:)

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsVPj-0005uz-R5; Wed, 01 Feb 2012 08:19:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RsVPi-0005uu-HG
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 08:19:34 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328084321!52409166!1
X-Originating-IP: [98.139.213.140]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27975 invoked from network); 1 Feb 2012 08:18:42 -0000
Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm12-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.140)
	by server-6.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 08:18:42 -0000
Received: from [98.139.212.147] by nm12.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 08:19:29 -0000
Received: from [98.139.212.198] by tm4.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 08:19:29 -0000
Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 08:19:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 432306.89201.bm@omp1007.mail.bf1.yahoo.com
Received: (qmail 48226 invoked by uid 60001); 1 Feb 2012 08:19:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1328084369; bh=5IbWja3YUqvHOr+dZzSIWM3SXO5cOLKEJGCnMOcQCl4=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=nEiwcgXllX8PSyLzRRJjx88eHoF8CvvNQNnuTPSBEbZpyLZYEMLoUjC2IccjzAvEK2DvAR8WFfBvc9biYfrOncj5+NV/Evzaut40WquymAGnrt4QOmvNJzBLKJ+SeGmZPTASpusn6PGPtIu+K9hEC46igWt6QBgXr0PKebcNDFM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=HwUXQkgO9UekveZvzlzRI2sTncbfUi3tklgV6yzqdGeLNCrGK+0rb2eZu0DnmHVx2knT5x9ASNnyWveHOXUiT7iVAJVsE4Hw/XbP3ZJa+7I3Nfi0e/J+PyujTaIML9MdiaKd15e4d2m7armIws/iWC/SCSNLQiGo3YtGLhUgV1k=;
X-YMail-OSG: SE70mqQVM1lKHPyjYVrruAKoZ4_fQ7ldM0ixl6S7y2z6FKm
	WnnmzRUg1y013.CuFgww1Qe0ImSVTmvgeni_EUwPGP7bteXc3tppVJXqDRGC
	viAoXDegE1EkeJXXZdAwtz0P9WwEIrU5Ebjbj.Ty2Tfo1riFD9.hMu3bDoUP
	pmI2xOFHoJU.AKEyMvPzThNxz4NgsK8syz.HOGQ_9GUvjk3.W1S2hoStFd.Q
	NTS4qh.5cUkDZV0ov8.WaJbm_waTgvPwcrL67LXw3gBMAMmtbGKTkqxZ9zaJ
	xpAc9cBDYzx4ttBGm8LkDZew2ucGzwCgCK7nysfnniw3bgZPGX9A5OeUYcEY
	ELhg3if3E6ZRbu3A0CBWC79Si_akEU65gRTwlDRQHlqpJpL8mbVf87phKM4p
	z6ZzMeIithEtXmTMkZL6QTQSRT4ngpt5FBU4yBB_a1vf_TPWQvGiB_KPm8Mv
	Q9HJX.z9l1MV7JvZFUh61wP_X7dQw
Received: from [76.73.45.34] by web160904.mail.bf1.yahoo.com via HTTP;
	Wed, 01 Feb 2012 00:19:29 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1328084369.41126.YahooMailClassic@web160904.mail.bf1.yahoo.com>
Date: Wed, 1 Feb 2012 00:19:29 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1071325783780014432=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1071325783780014432==
Content-Type: multipart/alternative; boundary="-517069186-536313248-1328084369=:41126"

---517069186-536313248-1328084369=:41126
Content-Type: text/plain; charset=us-ascii

Dear Developers,
I appreciate if you could help me with the following question; How we can send initialization parameters from xen to the Linux kernel in boot time, for example this parameter noexec=off.

Thanks in advance,


---517069186-536313248-1328084369=:41126
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Dear Developers,<br>I appreciate if you could help me with the following question; How we can send initialization parameters from xen to the Linux kernel in boot time, for example this parameter noexec=off.<br><br>Thanks in advance,<br><br></td></tr></table>
---517069186-536313248-1328084369=:41126--


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

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

--===============1071325783780014432==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 08:20:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 08:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsVPj-0005uz-R5; Wed, 01 Feb 2012 08:19:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RsVPi-0005uu-HG
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 08:19:34 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328084321!52409166!1
X-Originating-IP: [98.139.213.140]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27975 invoked from network); 1 Feb 2012 08:18:42 -0000
Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm12-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.140)
	by server-6.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 08:18:42 -0000
Received: from [98.139.212.147] by nm12.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 08:19:29 -0000
Received: from [98.139.212.198] by tm4.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 08:19:29 -0000
Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 08:19:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 432306.89201.bm@omp1007.mail.bf1.yahoo.com
Received: (qmail 48226 invoked by uid 60001); 1 Feb 2012 08:19:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1328084369; bh=5IbWja3YUqvHOr+dZzSIWM3SXO5cOLKEJGCnMOcQCl4=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=nEiwcgXllX8PSyLzRRJjx88eHoF8CvvNQNnuTPSBEbZpyLZYEMLoUjC2IccjzAvEK2DvAR8WFfBvc9biYfrOncj5+NV/Evzaut40WquymAGnrt4QOmvNJzBLKJ+SeGmZPTASpusn6PGPtIu+K9hEC46igWt6QBgXr0PKebcNDFM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=HwUXQkgO9UekveZvzlzRI2sTncbfUi3tklgV6yzqdGeLNCrGK+0rb2eZu0DnmHVx2knT5x9ASNnyWveHOXUiT7iVAJVsE4Hw/XbP3ZJa+7I3Nfi0e/J+PyujTaIML9MdiaKd15e4d2m7armIws/iWC/SCSNLQiGo3YtGLhUgV1k=;
X-YMail-OSG: SE70mqQVM1lKHPyjYVrruAKoZ4_fQ7ldM0ixl6S7y2z6FKm
	WnnmzRUg1y013.CuFgww1Qe0ImSVTmvgeni_EUwPGP7bteXc3tppVJXqDRGC
	viAoXDegE1EkeJXXZdAwtz0P9WwEIrU5Ebjbj.Ty2Tfo1riFD9.hMu3bDoUP
	pmI2xOFHoJU.AKEyMvPzThNxz4NgsK8syz.HOGQ_9GUvjk3.W1S2hoStFd.Q
	NTS4qh.5cUkDZV0ov8.WaJbm_waTgvPwcrL67LXw3gBMAMmtbGKTkqxZ9zaJ
	xpAc9cBDYzx4ttBGm8LkDZew2ucGzwCgCK7nysfnniw3bgZPGX9A5OeUYcEY
	ELhg3if3E6ZRbu3A0CBWC79Si_akEU65gRTwlDRQHlqpJpL8mbVf87phKM4p
	z6ZzMeIithEtXmTMkZL6QTQSRT4ngpt5FBU4yBB_a1vf_TPWQvGiB_KPm8Mv
	Q9HJX.z9l1MV7JvZFUh61wP_X7dQw
Received: from [76.73.45.34] by web160904.mail.bf1.yahoo.com via HTTP;
	Wed, 01 Feb 2012 00:19:29 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1328084369.41126.YahooMailClassic@web160904.mail.bf1.yahoo.com>
Date: Wed, 1 Feb 2012 00:19:29 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1071325783780014432=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1071325783780014432==
Content-Type: multipart/alternative; boundary="-517069186-536313248-1328084369=:41126"

---517069186-536313248-1328084369=:41126
Content-Type: text/plain; charset=us-ascii

Dear Developers,
I appreciate if you could help me with the following question; How we can send initialization parameters from xen to the Linux kernel in boot time, for example this parameter noexec=off.

Thanks in advance,


---517069186-536313248-1328084369=:41126
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Dear Developers,<br>I appreciate if you could help me with the following question; How we can send initialization parameters from xen to the Linux kernel in boot time, for example this parameter noexec=off.<br><br>Thanks in advance,<br><br></td></tr></table>
---517069186-536313248-1328084369=:41126--


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

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

--===============1071325783780014432==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 08:24:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 08:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsVTk-00061l-Gl; Wed, 01 Feb 2012 08:23:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RsVTj-00061f-PY
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 08:23:44 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328084574!52409836!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8252 invoked from network); 1 Feb 2012 08:22:54 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-6.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 08:22:54 -0000
Received: (qmail 14875 invoked from network); 1 Feb 2012 09:23:40 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	1 Feb 2012 09:23:40 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 09:23:40 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<20120131215427.GA32295@andromeda.dapyr.net>
In-Reply-To: <20120131215427.GA32295@andromeda.dapyr.net>
MIME-Version: 1.0
Message-Id: <201202010923.40281.pavel@netsafe.cz>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Jan 25, 2012 at 08:52:17PM +0100, Pavel Mat??ja wrote:
> How does one "extract" the bios from the ATI cards? With NVidia I
> noticed could do it via /sys/kernel/debug/dri/0/vbios.rom.
> 
> But that is not present on ATI cards. Did you instrument the radeon
> driver to dump it somewhere?

Hi,
I don't know, I got it from http://www.techpowerup.com/vgabios/
But copy from c000 should be just fine, should it not?
-- 
Pavel Mateja

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 08:24:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 08:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsVTk-00061l-Gl; Wed, 01 Feb 2012 08:23:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RsVTj-00061f-PY
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 08:23:44 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328084574!52409836!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8252 invoked from network); 1 Feb 2012 08:22:54 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-6.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 08:22:54 -0000
Received: (qmail 14875 invoked from network); 1 Feb 2012 09:23:40 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	1 Feb 2012 09:23:40 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 09:23:40 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<20120131215427.GA32295@andromeda.dapyr.net>
In-Reply-To: <20120131215427.GA32295@andromeda.dapyr.net>
MIME-Version: 1.0
Message-Id: <201202010923.40281.pavel@netsafe.cz>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Jan 25, 2012 at 08:52:17PM +0100, Pavel Mat??ja wrote:
> How does one "extract" the bios from the ATI cards? With NVidia I
> noticed could do it via /sys/kernel/debug/dri/0/vbios.rom.
> 
> But that is not present on ATI cards. Did you instrument the radeon
> driver to dump it somewhere?

Hi,
I don't know, I got it from http://www.techpowerup.com/vgabios/
But copy from c000 should be just fine, should it not?
-- 
Pavel Mateja

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 09:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 09:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsWnW-0006lo-Bc; Wed, 01 Feb 2012 09:48:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsWnV-0006lW-7D
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 09:48:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328089686!13229022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18834 invoked from network); 1 Feb 2012 09:48:06 -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;
	1 Feb 2012 09:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10409496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 09:48:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	09:48:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Wed, 1 Feb 2012 09:48:05 +0000
In-Reply-To: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328089685.17444.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
> Config.mk            |   1 +
>  tools/Makefile       |   1 +
>  tools/tests/Makefile |  20 ++++++++++++++++++++
>  3 files changed, 22 insertions(+), 0 deletions(-)
> 
> 
> Build tests as part of the tools build.
> 
> It is enabled with CONFIG_TESTS in Config.mk
> 
> Currently disabled build of tests/regressions and tests/xen-access (in 32 bit
> mode) as they fail.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Ack on the idea but the actual implementation fails for me:

make[1]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools'
make -C tests install
make[2]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
make[3]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
make -C mce-test install
make[4]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
make[4]: *** No rule to make target `install'.  Stop.

Grep seems to suggest that most of the tools/tests dirs are missing an
install target, mce-test just happens to be first.

I'm not sure if it makes sense to install any of these test things?
Depending on the answer we could either hobble the install target in
tools/tests/Makefile or add an install target to tools/tests/*/Makefile
which is a nop or an actual install target as appropriate.

Ian.



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 09:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 09:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsWnW-0006lo-Bc; Wed, 01 Feb 2012 09:48:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsWnV-0006lW-7D
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 09:48:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328089686!13229022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18834 invoked from network); 1 Feb 2012 09:48:06 -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;
	1 Feb 2012 09:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10409496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 09:48:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	09:48:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Wed, 1 Feb 2012 09:48:05 +0000
In-Reply-To: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328089685.17444.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
> Config.mk            |   1 +
>  tools/Makefile       |   1 +
>  tools/tests/Makefile |  20 ++++++++++++++++++++
>  3 files changed, 22 insertions(+), 0 deletions(-)
> 
> 
> Build tests as part of the tools build.
> 
> It is enabled with CONFIG_TESTS in Config.mk
> 
> Currently disabled build of tests/regressions and tests/xen-access (in 32 bit
> mode) as they fail.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Ack on the idea but the actual implementation fails for me:

make[1]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools'
make -C tests install
make[2]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
make[3]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
make -C mce-test install
make[4]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
make[4]: *** No rule to make target `install'.  Stop.

Grep seems to suggest that most of the tools/tests dirs are missing an
install target, mce-test just happens to be first.

I'm not sure if it makes sense to install any of these test things?
Depending on the answer we could either hobble the install target in
tools/tests/Makefile or add an install target to tools/tests/*/Makefile
which is a nop or an actual install target as appropriate.

Ian.



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:01:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:01:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsWzL-000766-OC; Wed, 01 Feb 2012 10:00:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsWzJ-000761-Ig
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:00:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328090374!50923319!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14404 invoked from network); 1 Feb 2012 09:59:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 09:59:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 01 Feb 2012 10:00:23 +0000
Message-Id: <4F291B450200007800070450@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 01 Feb 2012 10:00:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part26084D25.0__="
Subject: [Xen-devel] [PATCH] qemu-dm: fix unregister_iomem()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

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

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). It's unclear how the function can ever have
fulfilled its purpose: the value returned by iomem_index() is *not* an
index into mmio[].

Additionally, fix two problems:
- unregister_iomem() must not clear mmio[].start, otherwise
  cpu_register_physical_memory() won't be able to re-use the previous
  slot, thus causing a leak
- cpu_unregister_io_memory() must not check mmio[].size, otherwise it
  won't properly clean up entries (temporarily) squashed through
  unregister_iomem()

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>

--- a/i386-dm/exec-dm.c
+++ b/i386-dm/exec-dm.c
@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab
     int io_index =3D io_table_address >> IO_MEM_SHIFT;
=20
     for (i =3D 0; i < mmio_cnt; i++) {
-	if (mmio[i].size && mmio[i].io_index =3D=3D io_index) {
+	if (mmio[i].io_index =3D=3D io_index) {
 	   mmio[i].start =3D mmio[i].size =3D 0;
 	   break;
 	}
@@ -466,12 +466,16 @@ static int iomem_index(target_phys_addr_
=20
 void unregister_iomem(target_phys_addr_t start)
 {
-    int index =3D iomem_index(start);
-    if (index) {
+    unsigned int index;
+
+    for (index =3D 0; index < mmio_cnt; index++)
+        if (start =3D=3D mmio[index].start)
+            break;
+    if (index < mmio_cnt) {
         fprintf(logfile, "squash iomem [%lx, %lx).\n",
 		(unsigned long)(mmio[index].start),
                 (unsigned long)(mmio[index].start + mmio[index].size));
-        mmio[index].start =3D mmio[index].size =3D 0;
+        mmio[index].size =3D 0;
     }
 }
=20




--=__Part26084D25.0__=
Content-Type: text/plain; name="qemu-MSI-X-fix-unregister_iomem.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-fix-unregister_iomem.patch"

qemu-dm: fix unregister_iomem()=0A=0AThis function (introduced quite a =
long time ago in=0Ae7911109f4321e9ba0cc56a253b653600aa46bea - "disable =
qemu PCI=0Adevices in HVM domains") appears to be completely broken, =
causing=0Athe regression reported in=0Ahttp://bugzilla.xensource.com/bugzil=
la/show_bug.cgi?id=3D1805 (due to=0Athe newly added caller of it in=0A56d77=
47a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up=0AMSI-X table =
handling"). It's unclear how the function can ever have=0Afulfilled its =
purpose: the value returned by iomem_index() is *not* an=0Aindex into =
mmio[].=0A=0AAdditionally, fix two problems:=0A- unregister_iomem() must =
not clear mmio[].start, otherwise=0A  cpu_register_physical_memory() won't =
be able to re-use the previous=0A  slot, thus causing a leak=0A- cpu_unregi=
ster_io_memory() must not check mmio[].size, otherwise it=0A  won't =
properly clean up entries (temporarily) squashed through=0A  unregister_iom=
em()=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: =
Stefano Stabellini <stefano.stabellini@eu.citrix.com>=0ATested-by: Yongjie =
Ren <yongjie.ren@intel.com>=0A=0A--- a/i386-dm/exec-dm.c=0A+++ b/i386-dm/ex=
ec-dm.c=0A@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab=0A  =
   int io_index =3D io_table_address >> IO_MEM_SHIFT;=0A =0A     for (i =
=3D 0; i < mmio_cnt; i++) {=0A-	if (mmio[i].size && mmio[i].io_index =
=3D=3D io_index) {=0A+	if (mmio[i].io_index =3D=3D io_index) {=0A 	   =
mmio[i].start =3D mmio[i].size =3D 0;=0A 	   break;=0A 	}=0A@@ =
-466,12 +466,16 @@ static int iomem_index(target_phys_addr_=0A =0A void =
unregister_iomem(target_phys_addr_t start)=0A {=0A-    int index =3D =
iomem_index(start);=0A-    if (index) {=0A+    unsigned int index;=0A+=0A+ =
   for (index =3D 0; index < mmio_cnt; index++)=0A+        if (start =
=3D=3D mmio[index].start)=0A+            break;=0A+    if (index < =
mmio_cnt) {=0A         fprintf(logfile, "squash iomem [%lx, %lx).\n",=0A 	=
	(unsigned long)(mmio[index].start),=0A                 (unsigned =
long)(mmio[index].start + mmio[index].size));=0A-        mmio[index].start =
=3D mmio[index].size =3D 0;=0A+        mmio[index].size =3D 0;=0A     }=0A =
}=0A =0A
--=__Part26084D25.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part26084D25.0__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:01:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:01:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsWzL-000766-OC; Wed, 01 Feb 2012 10:00:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsWzJ-000761-Ig
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:00:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328090374!50923319!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14404 invoked from network); 1 Feb 2012 09:59:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 09:59:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 01 Feb 2012 10:00:23 +0000
Message-Id: <4F291B450200007800070450@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 01 Feb 2012 10:00:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part26084D25.0__="
Subject: [Xen-devel] [PATCH] qemu-dm: fix unregister_iomem()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

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

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). It's unclear how the function can ever have
fulfilled its purpose: the value returned by iomem_index() is *not* an
index into mmio[].

Additionally, fix two problems:
- unregister_iomem() must not clear mmio[].start, otherwise
  cpu_register_physical_memory() won't be able to re-use the previous
  slot, thus causing a leak
- cpu_unregister_io_memory() must not check mmio[].size, otherwise it
  won't properly clean up entries (temporarily) squashed through
  unregister_iomem()

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>

--- a/i386-dm/exec-dm.c
+++ b/i386-dm/exec-dm.c
@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab
     int io_index =3D io_table_address >> IO_MEM_SHIFT;
=20
     for (i =3D 0; i < mmio_cnt; i++) {
-	if (mmio[i].size && mmio[i].io_index =3D=3D io_index) {
+	if (mmio[i].io_index =3D=3D io_index) {
 	   mmio[i].start =3D mmio[i].size =3D 0;
 	   break;
 	}
@@ -466,12 +466,16 @@ static int iomem_index(target_phys_addr_
=20
 void unregister_iomem(target_phys_addr_t start)
 {
-    int index =3D iomem_index(start);
-    if (index) {
+    unsigned int index;
+
+    for (index =3D 0; index < mmio_cnt; index++)
+        if (start =3D=3D mmio[index].start)
+            break;
+    if (index < mmio_cnt) {
         fprintf(logfile, "squash iomem [%lx, %lx).\n",
 		(unsigned long)(mmio[index].start),
                 (unsigned long)(mmio[index].start + mmio[index].size));
-        mmio[index].start =3D mmio[index].size =3D 0;
+        mmio[index].size =3D 0;
     }
 }
=20




--=__Part26084D25.0__=
Content-Type: text/plain; name="qemu-MSI-X-fix-unregister_iomem.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-fix-unregister_iomem.patch"

qemu-dm: fix unregister_iomem()=0A=0AThis function (introduced quite a =
long time ago in=0Ae7911109f4321e9ba0cc56a253b653600aa46bea - "disable =
qemu PCI=0Adevices in HVM domains") appears to be completely broken, =
causing=0Athe regression reported in=0Ahttp://bugzilla.xensource.com/bugzil=
la/show_bug.cgi?id=3D1805 (due to=0Athe newly added caller of it in=0A56d77=
47a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up=0AMSI-X table =
handling"). It's unclear how the function can ever have=0Afulfilled its =
purpose: the value returned by iomem_index() is *not* an=0Aindex into =
mmio[].=0A=0AAdditionally, fix two problems:=0A- unregister_iomem() must =
not clear mmio[].start, otherwise=0A  cpu_register_physical_memory() won't =
be able to re-use the previous=0A  slot, thus causing a leak=0A- cpu_unregi=
ster_io_memory() must not check mmio[].size, otherwise it=0A  won't =
properly clean up entries (temporarily) squashed through=0A  unregister_iom=
em()=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: =
Stefano Stabellini <stefano.stabellini@eu.citrix.com>=0ATested-by: Yongjie =
Ren <yongjie.ren@intel.com>=0A=0A--- a/i386-dm/exec-dm.c=0A+++ b/i386-dm/ex=
ec-dm.c=0A@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab=0A  =
   int io_index =3D io_table_address >> IO_MEM_SHIFT;=0A =0A     for (i =
=3D 0; i < mmio_cnt; i++) {=0A-	if (mmio[i].size && mmio[i].io_index =
=3D=3D io_index) {=0A+	if (mmio[i].io_index =3D=3D io_index) {=0A 	   =
mmio[i].start =3D mmio[i].size =3D 0;=0A 	   break;=0A 	}=0A@@ =
-466,12 +466,16 @@ static int iomem_index(target_phys_addr_=0A =0A void =
unregister_iomem(target_phys_addr_t start)=0A {=0A-    int index =3D =
iomem_index(start);=0A-    if (index) {=0A+    unsigned int index;=0A+=0A+ =
   for (index =3D 0; index < mmio_cnt; index++)=0A+        if (start =
=3D=3D mmio[index].start)=0A+            break;=0A+    if (index < =
mmio_cnt) {=0A         fprintf(logfile, "squash iomem [%lx, %lx).\n",=0A 	=
	(unsigned long)(mmio[index].start),=0A                 (unsigned =
long)(mmio[index].start + mmio[index].size));=0A-        mmio[index].start =
=3D mmio[index].size =3D 0;=0A+        mmio[index].size =3D 0;=0A     }=0A =
}=0A =0A
--=__Part26084D25.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part26084D25.0__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsX3h-0007DT-Dt; Wed, 01 Feb 2012 10:04:57 +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 1RsX3g-0007DH-Fm
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:04:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328090650!58298334!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30363 invoked from network); 1 Feb 2012 10:04:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 10:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10409911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:04:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:04:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jack nemati <hn_nemati1985@yahoo.com>
Date: Wed, 1 Feb 2012 10:04:52 +0000
In-Reply-To: <1328084369.41126.YahooMailClassic@web160904.mail.bf1.yahoo.com>
References: <1328084369.41126.YahooMailClassic@web160904.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328090692.17444.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 08:19 +0000, jack nemati wrote:
> I appreciate if you could help me with the following question; How we
> can send initialization parameters from xen to the Linux kernel in
> boot time, for example this parameter noexec=off.

Configuration questions such as this are best addressed to the xen-users
mailing list.

If I've misunderstood and you are actually proposing a some development
related change then please take a look at
http://wiki.xen.org/wiki/AskingXenDevelQuestions to help you frame your
suggestion.

Thanks,

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsX3h-0007DT-Dt; Wed, 01 Feb 2012 10:04:57 +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 1RsX3g-0007DH-Fm
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:04:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328090650!58298334!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30363 invoked from network); 1 Feb 2012 10:04:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 10:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10409911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:04:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:04:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jack nemati <hn_nemati1985@yahoo.com>
Date: Wed, 1 Feb 2012 10:04:52 +0000
In-Reply-To: <1328084369.41126.YahooMailClassic@web160904.mail.bf1.yahoo.com>
References: <1328084369.41126.YahooMailClassic@web160904.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328090692.17444.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 08:19 +0000, jack nemati wrote:
> I appreciate if you could help me with the following question; How we
> can send initialization parameters from xen to the Linux kernel in
> boot time, for example this parameter noexec=off.

Configuration questions such as this are best addressed to the xen-users
mailing list.

If I've misunderstood and you are actually proposing a some development
related change then please take a look at
http://wiki.xen.org/wiki/AskingXenDevelQuestions to help you frame your
suggestion.

Thanks,

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:07:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsX5Y-0007JW-4H; Wed, 01 Feb 2012 10:06:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsX5W-0007JJ-Px
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:06:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328090804!11047085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24569 invoked from network); 1 Feb 2012 10:06:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 10:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10409971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:06:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:06:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=E9=A9=AC=E7=A3=8A?= <aware.why@gmail.com>
Date: Wed, 1 Feb 2012 10:06:43 +0000
In-Reply-To: <CA+ePHTCggCq4tQbCtt6LUgFU-7NSVDHk+JQMRwO=ykbxGuLK6A@mail.gmail.com>
References: <mailman.2163.1328075559.1471.xen-devel@lists.xensource.com>
	<CA+ePHTCggCq4tQbCtt6LUgFU-7NSVDHk+JQMRwO=ykbxGuLK6A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328090803.17444.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTAxIGF0IDA2OjI4ICswMDAwLCDpqazno4ogd3JvdGU6Cj4gCj4gCj4g
T24gV2VkLCBGZWIgMSwgMjAxMiBhdCAxOjUyIFBNLAo+IDx4ZW4tZGV2ZWwtcmVxdWVzdEBsaXN0
cy54ZW5zb3VyY2UuY29tPiB3cm90ZToKPiAgICAgICAgIFNlbmQgWGVuLWRldmVsIG1haWxpbmcg
bGlzdCBzdWJtaXNzaW9ucyB0bwo+ICAgICAgICAgICAgICAgIHhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCj4gICAgICAgICAKPiAgICAgICAgIFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmli
ZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdAo+ICAgICAgICAgICAgICAgIGh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL21haWxtYW4vbGlzdGluZm8veGVuLWRldmVsCj4gICAgICAgICBv
ciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcg
dG8KPiAgICAgICAgICAgICAgICB4ZW4tZGV2ZWwtcmVxdWVzdEBsaXN0cy54ZW5zb3VyY2UuY29t
Cj4gICAgICAgICAKPiAgICAgICAgIFlvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0
aGUgbGlzdCBhdAo+ICAgICAgICAgICAgICAgIHhlbi1kZXZlbC1vd25lckBsaXN0cy54ZW5zb3Vy
Y2UuY29tCj4gICAgICAgICAKPiAgICAgICAgIFdoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlv
dXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUKPiAgICAgICAgIHNwZWNpZmljIHRoYW4gIlJl
OiBDb250ZW50cyBvZiBYZW4tZGV2ZWwgZGlnZXN0Li4uIgoKSSB3YXMgdW5hYmxlIHRvIGZpbmQg
YW55IGNvbnRlbnQgZnJvbSB5b3UgaW4gdGhpcyBtYWlsLiBQbGVhc2UgcmVtZW1iZXIKdG8gdHJp
bSB5b3VyIHF1b3RlZCBtYXRlcmlhbCwgdGhpcyBpcyBlc3BlY2lhbGx5IGNyaXRpY2FsIHdoZW4g
cmVwbHlpbmcKdG8gYSBkaWdlc3QgcG9zdC4gQXMgaXMgYWRqdXN0aW5nIHRoZSBzdWJqZWN0IGxp
bmUgYXMgc3RhdGVkIGFib3ZlLgoKSSBoYXZlIGFsc28gYWRkZWQgc29tZSB3b3JkcyB0byB0aGlz
IGVmZmVjdCB0bwpodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQXNraW5nWGVuRGV2ZWxRdWVzdGlv
bnMKCklhbi4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20K
aHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:07:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsX5Y-0007JW-4H; Wed, 01 Feb 2012 10:06:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsX5W-0007JJ-Px
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:06:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328090804!11047085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24569 invoked from network); 1 Feb 2012 10:06:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 10:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10409971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:06:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:06:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=E9=A9=AC=E7=A3=8A?= <aware.why@gmail.com>
Date: Wed, 1 Feb 2012 10:06:43 +0000
In-Reply-To: <CA+ePHTCggCq4tQbCtt6LUgFU-7NSVDHk+JQMRwO=ykbxGuLK6A@mail.gmail.com>
References: <mailman.2163.1328075559.1471.xen-devel@lists.xensource.com>
	<CA+ePHTCggCq4tQbCtt6LUgFU-7NSVDHk+JQMRwO=ykbxGuLK6A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328090803.17444.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTAxIGF0IDA2OjI4ICswMDAwLCDpqazno4ogd3JvdGU6Cj4gCj4gCj4g
T24gV2VkLCBGZWIgMSwgMjAxMiBhdCAxOjUyIFBNLAo+IDx4ZW4tZGV2ZWwtcmVxdWVzdEBsaXN0
cy54ZW5zb3VyY2UuY29tPiB3cm90ZToKPiAgICAgICAgIFNlbmQgWGVuLWRldmVsIG1haWxpbmcg
bGlzdCBzdWJtaXNzaW9ucyB0bwo+ICAgICAgICAgICAgICAgIHhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCj4gICAgICAgICAKPiAgICAgICAgIFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmli
ZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdAo+ICAgICAgICAgICAgICAgIGh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL21haWxtYW4vbGlzdGluZm8veGVuLWRldmVsCj4gICAgICAgICBv
ciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcg
dG8KPiAgICAgICAgICAgICAgICB4ZW4tZGV2ZWwtcmVxdWVzdEBsaXN0cy54ZW5zb3VyY2UuY29t
Cj4gICAgICAgICAKPiAgICAgICAgIFlvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0
aGUgbGlzdCBhdAo+ICAgICAgICAgICAgICAgIHhlbi1kZXZlbC1vd25lckBsaXN0cy54ZW5zb3Vy
Y2UuY29tCj4gICAgICAgICAKPiAgICAgICAgIFdoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlv
dXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUKPiAgICAgICAgIHNwZWNpZmljIHRoYW4gIlJl
OiBDb250ZW50cyBvZiBYZW4tZGV2ZWwgZGlnZXN0Li4uIgoKSSB3YXMgdW5hYmxlIHRvIGZpbmQg
YW55IGNvbnRlbnQgZnJvbSB5b3UgaW4gdGhpcyBtYWlsLiBQbGVhc2UgcmVtZW1iZXIKdG8gdHJp
bSB5b3VyIHF1b3RlZCBtYXRlcmlhbCwgdGhpcyBpcyBlc3BlY2lhbGx5IGNyaXRpY2FsIHdoZW4g
cmVwbHlpbmcKdG8gYSBkaWdlc3QgcG9zdC4gQXMgaXMgYWRqdXN0aW5nIHRoZSBzdWJqZWN0IGxp
bmUgYXMgc3RhdGVkIGFib3ZlLgoKSSBoYXZlIGFsc28gYWRkZWQgc29tZSB3b3JkcyB0byB0aGlz
IGVmZmVjdCB0bwpodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQXNraW5nWGVuRGV2ZWxRdWVzdGlv
bnMKCklhbi4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20K
aHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBI-00025a-7a; Wed, 01 Feb 2012 10:12:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rq6v6-0008WR-Lv
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:46:04 +0000
Received: from [85.158.139.83:52434] by server-6.bemta-5.messagelabs.com id
	87/95-21889-BDF302F4; Wed, 25 Jan 2012 17:46:03 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327513559!12358754!1
X-Originating-IP: [202.81.31.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MiA9PiAxMjgxOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8831 invoked from network); 25 Jan 2012 17:46:03 -0000
Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 17:46:03 -0000
Received: from /spool/local
	by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 25 Jan 2012 18:37:51 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 25 Jan 2012 18:37:49 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0PHjjWF884966
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 04:45:47 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0PHjhEH012862
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 04:45:45 +1100
Received: from oc5400248562.ibm.com ([9.79.216.118])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0PHjY3t012820; Thu, 26 Jan 2012 04:45:35 +1100
Message-ID: <4F203FC0.70907@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 23:15:36 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F1FC370.5020506@linux.vnet.ibm.com>
	<20120125163552.GB23999@phenom.dumpdata.com>
In-Reply-To: <20120125163552.GB23999@phenom.dumpdata.com>
x-cbid: 12012508-3568-0000-0000-0000011E8D6F
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/25/2012 10:05 PM, Konrad Rzeszutek Wilk wrote:
>> So it seems we have worst case overhead of around 8%. But we see
>> improvement of at-least 15% once when little more time is spent in
>> critical section.
>
> Is this with collecting the histogram information about spinlocks? We found
> that if you enable that for production runs it makes them quite slower.
>

Ok. Are you referring to CONFIG_KVM_DEBUG_FS/CONFIG_XEN_DEBUG_FS?. Not
it was not enabled. But then may be I was not precise. This test was 
only on native. So it should have not affected IMO.

It is nice to know that histogram affects, since I was always under the
impression that it does not affect much on guest too. My experiments
had almost always enabled that.

Let me know if you referred to something else..


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBI-00025a-7a; Wed, 01 Feb 2012 10:12:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rq6v6-0008WR-Lv
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:46:04 +0000
Received: from [85.158.139.83:52434] by server-6.bemta-5.messagelabs.com id
	87/95-21889-BDF302F4; Wed, 25 Jan 2012 17:46:03 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327513559!12358754!1
X-Originating-IP: [202.81.31.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MiA9PiAxMjgxOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8831 invoked from network); 25 Jan 2012 17:46:03 -0000
Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 17:46:03 -0000
Received: from /spool/local
	by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 25 Jan 2012 18:37:51 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 25 Jan 2012 18:37:49 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0PHjjWF884966
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 04:45:47 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0PHjhEH012862
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 04:45:45 +1100
Received: from oc5400248562.ibm.com ([9.79.216.118])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0PHjY3t012820; Thu, 26 Jan 2012 04:45:35 +1100
Message-ID: <4F203FC0.70907@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 23:15:36 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F1FC370.5020506@linux.vnet.ibm.com>
	<20120125163552.GB23999@phenom.dumpdata.com>
In-Reply-To: <20120125163552.GB23999@phenom.dumpdata.com>
x-cbid: 12012508-3568-0000-0000-0000011E8D6F
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/25/2012 10:05 PM, Konrad Rzeszutek Wilk wrote:
>> So it seems we have worst case overhead of around 8%. But we see
>> improvement of at-least 15% once when little more time is spent in
>> critical section.
>
> Is this with collecting the histogram information about spinlocks? We found
> that if you enable that for production runs it makes them quite slower.
>

Ok. Are you referring to CONFIG_KVM_DEBUG_FS/CONFIG_XEN_DEBUG_FS?. Not
it was not enabled. But then may be I was not precise. This test was 
only on native. So it should have not affected IMO.

It is nice to know that histogram affects, since I was always under the
impression that it does not affect much on guest too. My experiments
had almost always enabled that.

Let me know if you referred to something else..


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBL-0002Ar-6G; Wed, 01 Feb 2012 10:12:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpINA-0003L9-BM; Mon, 23 Jan 2012 11:47:40 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327319253!11468892!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1760 invoked from network); 23 Jan 2012 11:47:34 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 11:47:34 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBkhOI021934;
	Mon, 23 Jan 2012 13:46:44 +0200
Message-ID: <F3D825D5E790424C83821FFA6251ECF2@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 13:47:15 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, chris <tknchris@gmail.com>,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 IC> Xen is focused on whatever people submit patches to do. Many of the
 IC> core developers are not currently looking at VGA passthrough, we have
 IC> plenty of stuff on our plates, but we are more than happy to review and
 IC> accept patches to implement/improve/fix this feature if only those
 IC> people who are interested in it would take the time to submit them per
 IC> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
 IC> going to go out hunting for patches on the Internet.

 IC> David Techer recently offered to do this but perhaps he would be
 IC> interested in some help from you?

As far as I understand it, the current set of fluders in this thread is 
ready to provide any assistance.
If we are compiling the kernel team will be in series with the new patch, we 
can make available a service to the masses


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBK-000295-6Q; Wed, 01 Feb 2012 10:12:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIAD-0001ae-Rn; Mon, 23 Jan 2012 11:34:18 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327318450!9466490!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3873 invoked from network); 23 Jan 2012 11:34:11 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 11:34:11 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBXNeu021507;
	Mon, 23 Jan 2012 13:33:24 +0200
Message-ID: <39D4FFFA5C7C44E3A630B5A83AC3139C@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAFoWEVN2F3v_mXUs2wvnjxP1Qu9mSiVYAwgPOUoAjYDXf6iXaA@mail.gmail.com>
Date: Mon, 23 Jan 2012 13:33:55 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBwcm9wb3NlIHRvIGJlZ2luIGRyYWZ0aW5nIGEgam9pbnQgbWFudWFsLiBUcmFpbmluZyBzeXN0
ZW0gZm9yIGZvcndhcmRpbmcgCnRvIGJlIGRpdmlkZWQgaW50byB0d28gc3RhZ2VzOgotIFNldCB0
aGUgc3lzdGVtIHVwIHRvIHRoZSBtb21lbnQgd2hlbiB0aGUgZGV2aWNlIGNhbiBub3QgYmUgZm9y
d2FyZGluZyAoeG0gCnBjaS1saXN0LWFzc2lnbmFibGUtZGV2aWNlcyBpcyBlbXB0eSkKLSBTZXQg
dXAgRG9tVSB2Z2FfcGFzc3RocnUgPSAxIGFmdGVyIHhtIHBjaS1saXN0LWFzc2lnbmFibGUtZGV2
aWNlcyBnaXZlcyBhIApsaXN0IG9mIGRldmljZXMKRXhhbXBsZToKIyBYbSBwY2ktbGlzdC1hc3Np
Z25hYmxlLWRldmljZXMKMDAwMDowMzowMC4wCjAwMDA6MDA6MTQuMAowMDAwOjAwOjE0LjUKCiBT
Uj4gSSBhZ3JlZSwgYSBtYW51YWwgd291bGQgYmUgZ3JlYXQuCgogU1I+IEl0IHdvdWxkIG1ha2Ug
bmV3Y29tZXJzLCBsaWtlIG15c2VsZiwgYSBsaXR0bGUgYml0IG1vcmUgY29tZm9ydGFibGUKIFNS
PiB3aXRoIFhlbi4KCiBTUj4gSSB0aGluayB0aGF0IHRoZSBmaXJzdCBzdGVwIHdvdWxkIGJlIHRo
YXQgZXZlcnlvbmUgd2hvIGhhcyBoYWQgc3VjY2VzcwogU1I+IHdpdGggVkdBIHBhc3N0aHJ1IHNo
b3VsZCBhZGQgdGhlaXIgaGFyZHdhcmUgc2V0dXAgYW5kIHhlbi9rZXJuZWwKIFNSPiB2ZXJzaW9u
cyB0byB0aGUgCmh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9YZW5fVkdBX1Bhc3N0aHJvdWdoX1Rl
c3RlZF9BZGFwdGVycyB3aWtpCiBTUj4gcGFnZSwgb3IgcGVyaGFwcyB3ZSBzdGFydCBhIG5ldyBw
YWdlIGluIHRoZSB3aWtpIHdpdGggaW5mb3JtYXRpb24gb24KIFNSPiBob3cgdG8gdXNlIHBhcnRp
Y3VsYXIgZ3JhcGhpY3MgY2FyZHMgKGkuZS4gaG93IHRvIHBhdGNoIHhlbiB0byBnZXQgdGhlbQog
U1I+IHdvcmtpbmcpLCBhbmQgdGhpcyBwYWdlIGNhbiBsaXN0IHN1Y2Nlc3Mgc3Rvcmllcy4KCiBT
Uj4gUmVnYXJkcwoKIFNSPiBTYW5kaQoKIFNSPiBPbiBGcmksIEphbiAyMCwgMjAxMiBhdCA3OjUz
IFBNLCBMaWthcnBlbmtvdiBBbGV4YW5kZXIKIFNSPiA8YWxAb2hvc3Rpbmcub3JnLnVhPndyb3Rl
OgoKID8/Pj4gUGxlYXNlIG1ha2UgYSBtYW51YWwKID8/Pj4gb3IgbGV0J3MgdG9nZXRoZXIgbWFr
ZQogPz8+PgogPz8+PiDQkiDQv9GP0YLQvdC40YbRgywg0LTQstCw0LTRhtCw0YLQvtCz0L4g0Y/Q
vdCy0LDRgNGPIDIwMTIg0LPQvtC00LAsINCyIDE4OjQ5OjIwINCS0Ysg0L/QuNGB0LDQu9C4Ogog
Pz8+PgogU1I+Pj4gUGFzaSwKID8/Pj4KIFNSPj4+IEkgaGF2ZSB0aGF0IGVuYWJsZWQgaW4gbXkg
QklPUywgVlQtZCBmb3IgdGhlIGNoaXBzZXQgYW5kIFZULXggZm9yIHRoZQogU1I+Pj4gQ1BVLgog
Pz8+PgogU1I+Pj4gSGF2ZSB5b3UgbWFuYWdlZCB0byBwYXNzIHlvdXIgZ3B1IHRocm91Z2ggdG8g
dGhlIGRvbVU/CiA/Pz4+CiBTUj4+PiBSZWdhcmRzCiA/Pz4+CiBTUj4+PiBTYW5kaQogU1I+Pj4g
T24gSmFuIDIwLCAyMDEyIDQ6NDcgUE0sICJQYXNpIEvDpHJra8OkaW5lbiIgPHBhc2lrQGlraS5m
aT4gd3JvdGU6CiA/Pz4+CiA/Pz4+Pj4gT24gRnJpLCBKYW4gMjAsIDIwMTIgYXQgMDI6MDU6NDNQ
TSArMDEwMCwgU2FuZGkgUm9taWggd3JvdGU6CiA/Pz4+Pj4+ICAgIEhlbGxvLAogPz8+Pj4+PiAg
ICBJIGhhdmUgc3BlbnQgYSBsb3Qgb2YgdGltZSB0cnlpbmcgdG8gZ2V0IGdmeCBwYXNzdGhydSB3
b3JraW5nIG9uCiA/Pz4+Pj4+IG15CiA/Pz4+Pj4gc3lzdGVtCiA/Pz4+Pj4+ICAgIHdpdGhvdXQg
c3VjY2Vzcy4KID8/Pj4+Pj4gICAgSSBsb29rZWQgb250byBteSBoYXJkd2FyZSBjYXBhYmlsaXRp
ZXMgYWdhaW4gdG8gbWFrZSBzdXJlIHRoYXQKID8/Pj4+Pj4gaXQgZG9lcyAgIHN1cHBvcnQgVlQt
ZCBhbmQgSSBhbSBub3QgdG9vIHN1cmUgdGhhdCBpdCBkb2VzIGZ1bGx5LgogPz8+Pj4+PiBNeSBo
YXJkd2FyZSBpcyBhcyBmb2xsb3dzOiAgIC0gU3VwZXJtaWNybyBYOERUSC02RiBtb3RoZXJib2Fy
ZCAKKDU1MjAKID8/Pj4gY2hpcHNldAogPz8+Pj4+PiB3aGljaCBzdXBwb3J0cyBWVC1kKSAgIC0g
c2luZ2xlIFhlb24gWDU2NTAgQ1BVICh3aGljaCBpcyBsaXN0ZWQgYXMKID8/Pj4+Pj4gc3VwcG9y
dGluZyBWVC14LCBubwogPz8+Pj4+IG1lbnRpb24gb2YKID8/Pj4+Pj4gICAgVlQtZCBhdCBbMV1h
cmsuaW50ZWwuY29tKQogPz8+Pj4+PiAgICBOb3csIGFjY29yZGluZyB0byB0aGUgWzJdVlRkSG93
VG8sIHRoZSBtb3RoZXJib2FyZCBCSU9TLCBjaGlwc2V0CiA/Pz4+Pj4+IEFORAogPz8+Pj4+IENQ
VQogPz8+Pj4+PiAgICBuZWVkIHRvIHN1cHBvcnQgVlQtZC4KID8/Pj4+Pj4gICAgV2hhdCBjb25m
dXNlcyBtZSBpcywgd2h5IGlzIHRoZSA1NXgwIGNoaXBzZXQgbGlzdGVkIHRoZXJlIGlmCiA/Pz4+
Pj4+IG5vbmUgb2YKID8/Pj4+PiB0aGUKID8/Pj4+Pj4gICAgQ1BVJ3Mgc3VwcG9ydGVkLCB0aGF0
IEkga25vdyBvZiwgZG9udCBoYXZlIHRoZSBWVC1kIGZlYXR1cmUKID8/Pj4+Pj4gb3B0aW9uLAog
Pz8+Pj4+IG9ubHkKID8/Pj4+Pj4gICAgVlQteC4KID8/Pj4+Pj4gCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBK-000295-6Q; Wed, 01 Feb 2012 10:12:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIAD-0001ae-Rn; Mon, 23 Jan 2012 11:34:18 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327318450!9466490!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3873 invoked from network); 23 Jan 2012 11:34:11 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 11:34:11 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBXNeu021507;
	Mon, 23 Jan 2012 13:33:24 +0200
Message-ID: <39D4FFFA5C7C44E3A630B5A83AC3139C@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAFoWEVN2F3v_mXUs2wvnjxP1Qu9mSiVYAwgPOUoAjYDXf6iXaA@mail.gmail.com>
Date: Mon, 23 Jan 2012 13:33:55 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBwcm9wb3NlIHRvIGJlZ2luIGRyYWZ0aW5nIGEgam9pbnQgbWFudWFsLiBUcmFpbmluZyBzeXN0
ZW0gZm9yIGZvcndhcmRpbmcgCnRvIGJlIGRpdmlkZWQgaW50byB0d28gc3RhZ2VzOgotIFNldCB0
aGUgc3lzdGVtIHVwIHRvIHRoZSBtb21lbnQgd2hlbiB0aGUgZGV2aWNlIGNhbiBub3QgYmUgZm9y
d2FyZGluZyAoeG0gCnBjaS1saXN0LWFzc2lnbmFibGUtZGV2aWNlcyBpcyBlbXB0eSkKLSBTZXQg
dXAgRG9tVSB2Z2FfcGFzc3RocnUgPSAxIGFmdGVyIHhtIHBjaS1saXN0LWFzc2lnbmFibGUtZGV2
aWNlcyBnaXZlcyBhIApsaXN0IG9mIGRldmljZXMKRXhhbXBsZToKIyBYbSBwY2ktbGlzdC1hc3Np
Z25hYmxlLWRldmljZXMKMDAwMDowMzowMC4wCjAwMDA6MDA6MTQuMAowMDAwOjAwOjE0LjUKCiBT
Uj4gSSBhZ3JlZSwgYSBtYW51YWwgd291bGQgYmUgZ3JlYXQuCgogU1I+IEl0IHdvdWxkIG1ha2Ug
bmV3Y29tZXJzLCBsaWtlIG15c2VsZiwgYSBsaXR0bGUgYml0IG1vcmUgY29tZm9ydGFibGUKIFNS
PiB3aXRoIFhlbi4KCiBTUj4gSSB0aGluayB0aGF0IHRoZSBmaXJzdCBzdGVwIHdvdWxkIGJlIHRo
YXQgZXZlcnlvbmUgd2hvIGhhcyBoYWQgc3VjY2VzcwogU1I+IHdpdGggVkdBIHBhc3N0aHJ1IHNo
b3VsZCBhZGQgdGhlaXIgaGFyZHdhcmUgc2V0dXAgYW5kIHhlbi9rZXJuZWwKIFNSPiB2ZXJzaW9u
cyB0byB0aGUgCmh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9YZW5fVkdBX1Bhc3N0aHJvdWdoX1Rl
c3RlZF9BZGFwdGVycyB3aWtpCiBTUj4gcGFnZSwgb3IgcGVyaGFwcyB3ZSBzdGFydCBhIG5ldyBw
YWdlIGluIHRoZSB3aWtpIHdpdGggaW5mb3JtYXRpb24gb24KIFNSPiBob3cgdG8gdXNlIHBhcnRp
Y3VsYXIgZ3JhcGhpY3MgY2FyZHMgKGkuZS4gaG93IHRvIHBhdGNoIHhlbiB0byBnZXQgdGhlbQog
U1I+IHdvcmtpbmcpLCBhbmQgdGhpcyBwYWdlIGNhbiBsaXN0IHN1Y2Nlc3Mgc3Rvcmllcy4KCiBT
Uj4gUmVnYXJkcwoKIFNSPiBTYW5kaQoKIFNSPiBPbiBGcmksIEphbiAyMCwgMjAxMiBhdCA3OjUz
IFBNLCBMaWthcnBlbmtvdiBBbGV4YW5kZXIKIFNSPiA8YWxAb2hvc3Rpbmcub3JnLnVhPndyb3Rl
OgoKID8/Pj4gUGxlYXNlIG1ha2UgYSBtYW51YWwKID8/Pj4gb3IgbGV0J3MgdG9nZXRoZXIgbWFr
ZQogPz8+PgogPz8+PiDQkiDQv9GP0YLQvdC40YbRgywg0LTQstCw0LTRhtCw0YLQvtCz0L4g0Y/Q
vdCy0LDRgNGPIDIwMTIg0LPQvtC00LAsINCyIDE4OjQ5OjIwINCS0Ysg0L/QuNGB0LDQu9C4Ogog
Pz8+PgogU1I+Pj4gUGFzaSwKID8/Pj4KIFNSPj4+IEkgaGF2ZSB0aGF0IGVuYWJsZWQgaW4gbXkg
QklPUywgVlQtZCBmb3IgdGhlIGNoaXBzZXQgYW5kIFZULXggZm9yIHRoZQogU1I+Pj4gQ1BVLgog
Pz8+PgogU1I+Pj4gSGF2ZSB5b3UgbWFuYWdlZCB0byBwYXNzIHlvdXIgZ3B1IHRocm91Z2ggdG8g
dGhlIGRvbVU/CiA/Pz4+CiBTUj4+PiBSZWdhcmRzCiA/Pz4+CiBTUj4+PiBTYW5kaQogU1I+Pj4g
T24gSmFuIDIwLCAyMDEyIDQ6NDcgUE0sICJQYXNpIEvDpHJra8OkaW5lbiIgPHBhc2lrQGlraS5m
aT4gd3JvdGU6CiA/Pz4+CiA/Pz4+Pj4gT24gRnJpLCBKYW4gMjAsIDIwMTIgYXQgMDI6MDU6NDNQ
TSArMDEwMCwgU2FuZGkgUm9taWggd3JvdGU6CiA/Pz4+Pj4+ICAgIEhlbGxvLAogPz8+Pj4+PiAg
ICBJIGhhdmUgc3BlbnQgYSBsb3Qgb2YgdGltZSB0cnlpbmcgdG8gZ2V0IGdmeCBwYXNzdGhydSB3
b3JraW5nIG9uCiA/Pz4+Pj4+IG15CiA/Pz4+Pj4gc3lzdGVtCiA/Pz4+Pj4+ICAgIHdpdGhvdXQg
c3VjY2Vzcy4KID8/Pj4+Pj4gICAgSSBsb29rZWQgb250byBteSBoYXJkd2FyZSBjYXBhYmlsaXRp
ZXMgYWdhaW4gdG8gbWFrZSBzdXJlIHRoYXQKID8/Pj4+Pj4gaXQgZG9lcyAgIHN1cHBvcnQgVlQt
ZCBhbmQgSSBhbSBub3QgdG9vIHN1cmUgdGhhdCBpdCBkb2VzIGZ1bGx5LgogPz8+Pj4+PiBNeSBo
YXJkd2FyZSBpcyBhcyBmb2xsb3dzOiAgIC0gU3VwZXJtaWNybyBYOERUSC02RiBtb3RoZXJib2Fy
ZCAKKDU1MjAKID8/Pj4gY2hpcHNldAogPz8+Pj4+PiB3aGljaCBzdXBwb3J0cyBWVC1kKSAgIC0g
c2luZ2xlIFhlb24gWDU2NTAgQ1BVICh3aGljaCBpcyBsaXN0ZWQgYXMKID8/Pj4+Pj4gc3VwcG9y
dGluZyBWVC14LCBubwogPz8+Pj4+IG1lbnRpb24gb2YKID8/Pj4+Pj4gICAgVlQtZCBhdCBbMV1h
cmsuaW50ZWwuY29tKQogPz8+Pj4+PiAgICBOb3csIGFjY29yZGluZyB0byB0aGUgWzJdVlRkSG93
VG8sIHRoZSBtb3RoZXJib2FyZCBCSU9TLCBjaGlwc2V0CiA/Pz4+Pj4+IEFORAogPz8+Pj4+IENQ
VQogPz8+Pj4+PiAgICBuZWVkIHRvIHN1cHBvcnQgVlQtZC4KID8/Pj4+Pj4gICAgV2hhdCBjb25m
dXNlcyBtZSBpcywgd2h5IGlzIHRoZSA1NXgwIGNoaXBzZXQgbGlzdGVkIHRoZXJlIGlmCiA/Pz4+
Pj4+IG5vbmUgb2YKID8/Pj4+PiB0aGUKID8/Pj4+Pj4gICAgQ1BVJ3Mgc3VwcG9ydGVkLCB0aGF0
IEkga25vdyBvZiwgZG9udCBoYXZlIHRoZSBWVC1kIGZlYXR1cmUKID8/Pj4+Pj4gb3B0aW9uLAog
Pz8+Pj4+IG9ubHkKID8/Pj4+Pj4gICAgVlQteC4KID8/Pj4+Pj4gCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBL-0002Ar-6G; Wed, 01 Feb 2012 10:12:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpINA-0003L9-BM; Mon, 23 Jan 2012 11:47:40 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327319253!11468892!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1760 invoked from network); 23 Jan 2012 11:47:34 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 11:47:34 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBkhOI021934;
	Mon, 23 Jan 2012 13:46:44 +0200
Message-ID: <F3D825D5E790424C83821FFA6251ECF2@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 13:47:15 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, chris <tknchris@gmail.com>,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 IC> Xen is focused on whatever people submit patches to do. Many of the
 IC> core developers are not currently looking at VGA passthrough, we have
 IC> plenty of stuff on our plates, but we are more than happy to review and
 IC> accept patches to implement/improve/fix this feature if only those
 IC> people who are interested in it would take the time to submit them per
 IC> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
 IC> going to go out hunting for patches on the Internet.

 IC> David Techer recently offered to do this but perhaps he would be
 IC> interested in some help from you?

As far as I understand it, the current set of fluders in this thread is 
ready to provide any assistance.
If we are compiling the kernel team will be in series with the new patch, we 
can make available a service to the masses


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBE-00021H-Bt; Wed, 01 Feb 2012 10:12:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RoG7q-0004dx-PF
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:11:34 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327072172!60571834!1
X-Originating-IP: [32.97.110.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MiA9PiAzNjg4NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1032 invoked from network); 20 Jan 2012 15:09:34 -0000
Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 15:09:34 -0000
Received: from /spool/local
	by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Fri, 20 Jan 2012 08:11:25 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179)
	by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Jan 2012 08:11:22 -0700
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235])
	by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id CEA2019D8091
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 08:11:15 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0KFBGtu243404
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 10:11:16 -0500
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 q0KFAsbR020063
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 08:10:55 -0700
Received: from linux.vnet.ibm.com ([9.79.193.32])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0KFAaeJ016939; Fri, 20 Jan 2012 08:10:39 -0700
Date: Fri, 20 Jan 2012 20:39:55 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20120120150955.GA8019@linux.vnet.ibm.com>
References: <4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
	<20120117142818.GE30398@linux.vnet.ibm.com>
	<20120117153233.GA7911@redhat.com>
	<20120117155303.GA28904@amt.cnet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117155303.GA28904@amt.cnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12012015-1780-0000-0000-0000027DEA84
X-IBM-ISS-SpamDetectors: 
X-IBM-ISS-DetailInfo: BY=3.00000245; HX=3.00000181; KW=3.00000007;
	PH=3.00000001; SC=3.00000001; SDB=6.00106595; UDB=6.00026806;
	UTC=2012-01-20 15:11:23
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Anthony Liguori <aliguori@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Anthony Liguori <aliguori@us.ibm.com>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 13:53:03]:

> on tue, jan 17, 2012 at 05:32:33pm +0200, gleb natapov wrote:
> > on tue, jan 17, 2012 at 07:58:18pm +0530, srivatsa vaddagiri wrote:
> > > * gleb natapov <gleb@redhat.com> [2012-01-17 15:20:51]:
> > > 
> > > > > having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > > > > hypervisor vs assuming that because of a trapped hlt instruction (which
> > > > > will anyway won't work when yield_on_hlt=0).
> > > > > 
> > > > the purpose of yield_on_hlt=0 is to allow vcpu to occupy cpu for the
> > > > entire time slice no mater what. i do not think disabling yield on hlt
> > > > is even make sense in cpu oversubscribe scenario.
> > > 
> > > Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
> > > initially added it as a way to implement CPU bandwidth capping for VMs,
> > > which would ensure that busy VMs don't eat into cycles meant for a idle
> > > VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
> > > there any real world use for yield_on_hlt=0? If not, deprecate it?
> > > 
> > I was against adding it in the first place, so if IBM no longer needs it
> > I am for removing it ASAP.
> 
> +1. 
> 
> Anthony?

CCing Anthony.

Anthony, could you ACK removal of yield_on_hlt (as keeping it around will
require unnecessary complications in pv-spinlock patches)?

- vatsa


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBE-00021H-Bt; Wed, 01 Feb 2012 10:12:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RoG7q-0004dx-PF
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:11:34 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327072172!60571834!1
X-Originating-IP: [32.97.110.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MiA9PiAzNjg4NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1032 invoked from network); 20 Jan 2012 15:09:34 -0000
Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 15:09:34 -0000
Received: from /spool/local
	by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Fri, 20 Jan 2012 08:11:25 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179)
	by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 20 Jan 2012 08:11:22 -0700
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235])
	by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id CEA2019D8091
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 08:11:15 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0KFBGtu243404
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 10:11:16 -0500
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 q0KFAsbR020063
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 08:10:55 -0700
Received: from linux.vnet.ibm.com ([9.79.193.32])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0KFAaeJ016939; Fri, 20 Jan 2012 08:10:39 -0700
Date: Fri, 20 Jan 2012 20:39:55 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20120120150955.GA8019@linux.vnet.ibm.com>
References: <4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
	<20120117142818.GE30398@linux.vnet.ibm.com>
	<20120117153233.GA7911@redhat.com>
	<20120117155303.GA28904@amt.cnet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117155303.GA28904@amt.cnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12012015-1780-0000-0000-0000027DEA84
X-IBM-ISS-SpamDetectors: 
X-IBM-ISS-DetailInfo: BY=3.00000245; HX=3.00000181; KW=3.00000007;
	PH=3.00000001; SC=3.00000001; SDB=6.00106595; UDB=6.00026806;
	UTC=2012-01-20 15:11:23
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Anthony Liguori <aliguori@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Gleb Natapov <gleb@redhat.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Anthony Liguori <aliguori@us.ibm.com>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 13:53:03]:

> on tue, jan 17, 2012 at 05:32:33pm +0200, gleb natapov wrote:
> > on tue, jan 17, 2012 at 07:58:18pm +0530, srivatsa vaddagiri wrote:
> > > * gleb natapov <gleb@redhat.com> [2012-01-17 15:20:51]:
> > > 
> > > > > having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > > > > hypervisor vs assuming that because of a trapped hlt instruction (which
> > > > > will anyway won't work when yield_on_hlt=0).
> > > > > 
> > > > the purpose of yield_on_hlt=0 is to allow vcpu to occupy cpu for the
> > > > entire time slice no mater what. i do not think disabling yield on hlt
> > > > is even make sense in cpu oversubscribe scenario.
> > > 
> > > Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
> > > initially added it as a way to implement CPU bandwidth capping for VMs,
> > > which would ensure that busy VMs don't eat into cycles meant for a idle
> > > VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
> > > there any real world use for yield_on_hlt=0? If not, deprecate it?
> > > 
> > I was against adding it in the first place, so if IBM no longer needs it
> > I am for removing it ASAP.
> 
> +1. 
> 
> Anthony?

CCing Anthony.

Anthony, could you ACK removal of yield_on_hlt (as keeping it around will
require unnecessary complications in pv-spinlock patches)?

- vatsa


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBH-00024O-CS; Wed, 01 Feb 2012 10:12:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1RpqOD-0000eG-St
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 00:07:02 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327449977!61591029!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDE0MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25064 invoked from network); 25 Jan 2012 00:06:18 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 00:06:18 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0188721004
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 19:07:00 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Tue, 24 Jan 2012 19:07:00 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=uzG1zSZJuJmah/HX/EpHnTCUgAU=; b=qaD/iCK2oLTV62J83T+7WY3Bdvjb
	ks5MGVpJ6x8aqxefD0TafxjGM/8oqivCPjQraOn6MEDXnR2J+19NdI0xiWiqRaT5
	kd0QxAGQVy+IVv5diPLAnhGyN/AdmjTcA9XUSgBLwPfwdwkdIc6DsnoTZwzK9Qy0
	bQu9pS1mDpemtDQ=
X-Sasl-enc: fk7BAiORy0VVdF+gJcw9Tg7VfXBrnLP2Y5lXx+tXC2kV 1327450019
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 3E8A9482507;
	Tue, 24 Jan 2012 19:06:59 -0500 (EST)
Date: Tue, 24 Jan 2012 16:06:34 -0800
From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Message-ID: <20120125000634.GA1178@kroah.com>
References: <Pine.LNX.4.44L0.1201241158540.1200-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44L0.1201241158540.1200-100000@iolanthe.rowland.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, linux-input@vger.kernel.org,
	linux-s390@vger.kernel.org, Andy Walls <awalls@md.metrocast.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jiri Kosina <jkosina@suse.cz>, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, netdev@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Michael Buesch <m@bues.ch>, Joerg Roedel <joerg.roedel@amd.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	USB list <linux-usb@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-pcmcia@lists.infradead.org, linux-media@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 0/5] Get rid of get_driver() and put_driver()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 01:33:37PM -0500, Alan Stern wrote:
> Greg:
> 
> This patch series removes the get_driver() and put_driver() routines
> from the kernel.
> 
> Those routines don't do anything useful.  Their comments say that they
> increment and decrement the driver's reference count, just like
> get_device()/put_device() and a lot of other utility routines.  But a
> struct driver is _not_ like a struct device!  It resembles a piece of
> code more than a piece of data -- it acts as an encapsulation of a
> driver.  Incrementing its refcount doesn't have much meaning because a
> driver's lifetime isn't determined by the structure's refcount; it's
> determined by when the driver's module gets unloaded.
> 
> What really matters for a driver is whether or not it is registered.  
> Drivers expect, for example, that none of their methods will be called
> after driver_unregister() returns.  It doesn't matter if some other
> thread still holds a reference to the driver structure; that reference
> mustn't be used for accessing the driver code after unregistration.  
> get_driver() does not do any checking for this.
> 
> People may have been misled by the kerneldoc into thinking that the
> references obtained by get_driver() do somehow pin the driver structure
> in memory.  This simply isn't true; all it pins is the associated
> private structure.  Code that needs to pin a driver must do it some
> other way (probably by calling try_module_get()).
> 
> In short, these routines don't do anything useful and they can actively 
> mislead people.  Removing them won't introduce any bugs that aren't 
> already present.  There is no reason to keep them.

Very nice work, all now applied, thanks for doing this.

greg k-h

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBK-0002A5-Lv; Wed, 01 Feb 2012 10:12:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIJd-0002f8-Sy; Mon, 23 Jan 2012 11:44:02 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327319034!4682504!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1212 invoked from network); 23 Jan 2012 11:43:55 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 11:43:55 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBh8jN021831;
	Mon, 23 Jan 2012 13:43:08 +0200
Message-ID: <29F02B176A6142308507B31EE4097256@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>, "chris" <tknchris@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
Date: Mon, 23 Jan 2012 13:43:39 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 SR> Yeah, I guess xen has generally been focused on the server end.

I do not agree. If you think so then, too, Unix only for server.

 SR> But I see some good uses for desktop virtualization too. I personally
 SR> want this so that I can have a file server (zfs based) and a Windows
 SR> desktop (as all the tools I use in my job are mostly only supported in
 SR> MS OS) in one machine. Saves me money and space.

I also combined the two workstations in one system unit: 2 keyboards, 2 
mice, 2 graphics cards, 4 monitors + 15-20 DomU guest for other tasks. This 
is a working office or server room in a box.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBH-00024O-CS; Wed, 01 Feb 2012 10:12:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1RpqOD-0000eG-St
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 00:07:02 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327449977!61591029!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDE0MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25064 invoked from network); 25 Jan 2012 00:06:18 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 00:06:18 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0188721004
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 19:07:00 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Tue, 24 Jan 2012 19:07:00 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=uzG1zSZJuJmah/HX/EpHnTCUgAU=; b=qaD/iCK2oLTV62J83T+7WY3Bdvjb
	ks5MGVpJ6x8aqxefD0TafxjGM/8oqivCPjQraOn6MEDXnR2J+19NdI0xiWiqRaT5
	kd0QxAGQVy+IVv5diPLAnhGyN/AdmjTcA9XUSgBLwPfwdwkdIc6DsnoTZwzK9Qy0
	bQu9pS1mDpemtDQ=
X-Sasl-enc: fk7BAiORy0VVdF+gJcw9Tg7VfXBrnLP2Y5lXx+tXC2kV 1327450019
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 3E8A9482507;
	Tue, 24 Jan 2012 19:06:59 -0500 (EST)
Date: Tue, 24 Jan 2012 16:06:34 -0800
From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Message-ID: <20120125000634.GA1178@kroah.com>
References: <Pine.LNX.4.44L0.1201241158540.1200-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44L0.1201241158540.1200-100000@iolanthe.rowland.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, linux-input@vger.kernel.org,
	linux-s390@vger.kernel.org, Andy Walls <awalls@md.metrocast.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jiri Kosina <jkosina@suse.cz>, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, netdev@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Michael Buesch <m@bues.ch>, Joerg Roedel <joerg.roedel@amd.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	USB list <linux-usb@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-pcmcia@lists.infradead.org, linux-media@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 0/5] Get rid of get_driver() and put_driver()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 01:33:37PM -0500, Alan Stern wrote:
> Greg:
> 
> This patch series removes the get_driver() and put_driver() routines
> from the kernel.
> 
> Those routines don't do anything useful.  Their comments say that they
> increment and decrement the driver's reference count, just like
> get_device()/put_device() and a lot of other utility routines.  But a
> struct driver is _not_ like a struct device!  It resembles a piece of
> code more than a piece of data -- it acts as an encapsulation of a
> driver.  Incrementing its refcount doesn't have much meaning because a
> driver's lifetime isn't determined by the structure's refcount; it's
> determined by when the driver's module gets unloaded.
> 
> What really matters for a driver is whether or not it is registered.  
> Drivers expect, for example, that none of their methods will be called
> after driver_unregister() returns.  It doesn't matter if some other
> thread still holds a reference to the driver structure; that reference
> mustn't be used for accessing the driver code after unregistration.  
> get_driver() does not do any checking for this.
> 
> People may have been misled by the kerneldoc into thinking that the
> references obtained by get_driver() do somehow pin the driver structure
> in memory.  This simply isn't true; all it pins is the associated
> private structure.  Code that needs to pin a driver must do it some
> other way (probably by calling try_module_get()).
> 
> In short, these routines don't do anything useful and they can actively 
> mislead people.  Removing them won't introduce any bugs that aren't 
> already present.  There is no reason to keep them.

Very nice work, all now applied, thanks for doing this.

greg k-h

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBK-0002A5-Lv; Wed, 01 Feb 2012 10:12:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIJd-0002f8-Sy; Mon, 23 Jan 2012 11:44:02 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327319034!4682504!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1212 invoked from network); 23 Jan 2012 11:43:55 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 11:43:55 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBh8jN021831;
	Mon, 23 Jan 2012 13:43:08 +0200
Message-ID: <29F02B176A6142308507B31EE4097256@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>, "chris" <tknchris@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
Date: Mon, 23 Jan 2012 13:43:39 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 SR> Yeah, I guess xen has generally been focused on the server end.

I do not agree. If you think so then, too, Unix only for server.

 SR> But I see some good uses for desktop virtualization too. I personally
 SR> want this so that I can have a file server (zfs based) and a Windows
 SR> desktop (as all the tools I use in my job are mostly only supported in
 SR> MS OS) in one machine. Saves me money and space.

I also combined the two workstations in one system unit: 2 keyboards, 2 
mice, 2 graphics cards, 4 monitors + 15-20 DomU guest for other tasks. This 
is a working office or server room in a box.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBN-0002FO-JE; Wed, 01 Feb 2012 10:12:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rpecq-0003wV-Rg; Tue, 24 Jan 2012 11:33:21 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327404794!12349598!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6578 invoked from network); 24 Jan 2012 11:33:14 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 11:33:14 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OBW8PO020196;
	Tue, 24 Jan 2012 13:32:09 +0200
Message-ID: <C8BD07BB8269428FB535E6C30604A963@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <xen-devel@lists.xensource.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 13:32:40 +0200
MIME-Version: 1.0
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	ray@aarden.us, xen-users@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 TG> That said - i gladly can forward-port these old patches, if you think
 TG> they are helping in any way.

I propose to begin the creation of the manual.
Specifically for this purpose I created a blog and an article on this topic.
According to the information came to the mailing list or in blog comments 
will summarize and publish
See link:
http://lixen.ua-ohosting.com/archives/31 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBG-00023G-Fn; Wed, 01 Feb 2012 10:12:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RplU1-0002t3-BP
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:52:41 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327431151!12224991!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDAwMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13346 invoked from network); 24 Jan 2012 18:52:34 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 18:52:34 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 25 Jan 2012 00:22:28 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 25 Jan 2012 00:22:01 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0OIq0pK4243704
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 00:22:01 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0OIpwj2021654
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 05:52:00 +1100
Received: from oc5400248562.ibm.com ([9.77.201.56])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0OIprCo021468; Wed, 25 Jan 2012 05:51:54 +1100
Message-ID: <4F1EFDCB.5040808@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 00:21:55 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
	<20120118135445.GB25711@linux.vnet.ibm.com>
	<4F173F0F.5020604@goop.org> <4F1EBB73.3000705@redhat.com>
In-Reply-To: <4F1EBB73.3000705@redhat.com>
x-cbid: 12012418-4790-0000-0000-00000104268E
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 07:38 PM, Avi Kivity wrote:
> On 01/18/2012 11:52 PM, Jeremy Fitzhardinge wrote:
>> On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
>>>
>>>> That logic relies on the "kick" being level triggered, so that "kick"
>>>> before "block" will cause the block to fall out immediately.  If you're
>>>> using "hlt" as the block and it has the usual edge-triggered behaviour,
>>>> what stops a "kick-before-hlt" from losing the kick?
>>> Hmm ..'hlt' should result in a check for kick request (in hypervisor
>>> context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
>>> will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check
>>> before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
>>>
>>> Won't that trap the 'kick-before-hlt' case? What am I missing here?
>>
>> Nothing, that sounds fine.  It wasn't clear to me that your kick
>> operation left persistent state, and so has a level-triggered effect on hlt.
>>
>
> btw, this persistent state needs to be saved/restored for live
> migration.  Best to put it into some MSR.
>

I did not quite get it. Did you mean, add a new MSR to msrs_to_save[],
and may be retain only the kicked/pv_unhalt flag (persistent state) and 
get rid of PVLOCK_KICK vcpu->request?


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBG-00022i-1I; Wed, 01 Feb 2012 10:12:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RoJbQ-0005sS-Nl; Fri, 20 Jan 2012 18:54:20 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327085653!9409260!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14318 invoked from network); 20 Jan 2012 18:54:13 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 18:54:13 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0KIrMxH007273;
	Fri, 20 Jan 2012 20:53:22 +0200
Message-ID: <3B7B9131A63345CCB34B508E3E4F3507@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>,
	=?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
Date: Fri, 20 Jan 2012 20:53:53 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

UGxlYXNlIG1ha2UgYSBtYW51YWwKb3IgbGV0J3MgdG9nZXRoZXIgbWFrZQoK0JIg0L/Rj9GC0L3Q
uNGG0YMsINC00LLQsNC00YbQsNGC0L7Qs9C+INGP0L3QstCw0YDRjyAyMDEyINCz0L7QtNCwLCDQ
siAxODo0OToyMCDQktGLINC/0LjRgdCw0LvQuDoKCiBTUj4gUGFzaSwKCiBTUj4gSSBoYXZlIHRo
YXQgZW5hYmxlZCBpbiBteSBCSU9TLCBWVC1kIGZvciB0aGUgY2hpcHNldCBhbmQgVlQteCBmb3Ig
dGhlCiBTUj4gQ1BVLgoKIFNSPiBIYXZlIHlvdSBtYW5hZ2VkIHRvIHBhc3MgeW91ciBncHUgdGhy
b3VnaCB0byB0aGUgZG9tVT8KCiBTUj4gUmVnYXJkcwoKIFNSPiBTYW5kaQogU1I+IE9uIEphbiAy
MCwgMjAxMiA0OjQ3IFBNLCAiUGFzaSBLw6Rya2vDpGluZW4iIDxwYXNpa0Bpa2kuZmk+IHdyb3Rl
OgoKID8/Pj4gT24gRnJpLCBKYW4gMjAsIDIwMTIgYXQgMDI6MDU6NDNQTSArMDEwMCwgU2FuZGkg
Um9taWggd3JvdGU6CiA/Pz4+PiAgICBIZWxsbywKID8/Pj4+ICAgIEkgaGF2ZSBzcGVudCBhIGxv
dCBvZiB0aW1lIHRyeWluZyB0byBnZXQgZ2Z4IHBhc3N0aHJ1IHdvcmtpbmcgb24KID8/Pj4+IG15
CiA/Pz4+IHN5c3RlbQogPz8+Pj4gICAgd2l0aG91dCBzdWNjZXNzLgogPz8+Pj4gICAgSSBsb29r
ZWQgb250byBteSBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYWdhaW4gdG8gbWFrZSBzdXJlIHRoYXQg
aXQKID8/Pj4+IGRvZXMgICBzdXBwb3J0IFZULWQgYW5kIEkgYW0gbm90IHRvbyBzdXJlIHRoYXQg
aXQgZG9lcyBmdWxseS4gICBNeQogPz8+Pj4gaGFyZHdhcmUgaXMgYXMgZm9sbG93czogICAtIFN1
cGVybWljcm8gWDhEVEgtNkYgbW90aGVyYm9hcmQgKDU1MjAgCmNoaXBzZXQKID8/Pj4+IHdoaWNo
IHN1cHBvcnRzIFZULWQpICAgLSBzaW5nbGUgWGVvbiBYNTY1MCBDUFUgKHdoaWNoIGlzIGxpc3Rl
ZCBhcwogPz8+Pj4gc3VwcG9ydGluZyBWVC14LCBubwogPz8+PiBtZW50aW9uIG9mCiA/Pz4+PiAg
ICBWVC1kIGF0IFsxXWFyay5pbnRlbC5jb20pCiA/Pz4+PiAgICBOb3csIGFjY29yZGluZyB0byB0
aGUgWzJdVlRkSG93VG8sIHRoZSBtb3RoZXJib2FyZCBCSU9TLCBjaGlwc2V0CiA/Pz4+PiBBTkQK
ID8/Pj4gQ1BVCiA/Pz4+PiAgICBuZWVkIHRvIHN1cHBvcnQgVlQtZC4KID8/Pj4+ICAgIFdoYXQg
Y29uZnVzZXMgbWUgaXMsIHdoeSBpcyB0aGUgNTV4MCBjaGlwc2V0IGxpc3RlZCB0aGVyZSBpZiBu
b25lCiA/Pz4+PiBvZgogPz8+PiB0aGUKID8/Pj4+ICAgIENQVSdzIHN1cHBvcnRlZCwgdGhhdCBJ
IGtub3cgb2YsIGRvbnQgaGF2ZSB0aGUgVlQtZCBmZWF0dXJlCiA/Pz4+PiBvcHRpb24sCiA/Pz4+
IG9ubHkKID8/Pj4+ICAgIFZULXguCiA/Pz4+PgogCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBM-0002DG-DS; Wed, 01 Feb 2012 10:12:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIan-0005gy-LN; Mon, 23 Jan 2012 12:01:45 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327320098!12123872!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30503 invoked from network); 23 Jan 2012 12:01:39 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 12:01:39 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NC0q60022487;
	Mon, 23 Jan 2012 14:00:52 +0200
Message-ID: <48D10F9F57354C4D989F3F280ABE9538@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>, "John Sherwood" <jrs@vt.edu>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com><CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com><CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
	<027167128F834966B223737A4B5F6DFA@nobody>
Date: Mon, 23 Jan 2012 14:01:24 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 SR>> I am trying to pass my secondary graphics card through to the VM. My
 SR>> dom0 runs with the primary card (an onboard GPU).

 SR>> What happens with me is that the secondary card (GTX480) is
 SR>> relinquished to pciback and according to the logs, it looks like the
 SR>> card is passed through successfully to the domU.
 SR>> What happens though is a bit puzzling (with gfx_passthru=1):
 SR>> 1) When I start the domU, my dom0 screen goes blank (which is using a
 SR>> different graphics card than is assigned to the domU)
 SR>> 2) The domain does not boot; i.e. the CDROM does not spin up.
 SR>> 3) If I connect to the domain via vnc, I see only the qemu console.

 LA> The same nonsense. But my video is ATI
I mean I have a similar result


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBG-00023G-Fn; Wed, 01 Feb 2012 10:12:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RplU1-0002t3-BP
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:52:41 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327431151!12224991!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDAwMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13346 invoked from network); 24 Jan 2012 18:52:34 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 18:52:34 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 25 Jan 2012 00:22:28 +0530
Received: from d28relay01.in.ibm.com (9.184.220.58)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 25 Jan 2012 00:22:01 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0OIq0pK4243704
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 00:22:01 +0530
Received: from d28av02.in.ibm.com (loopback [127.0.0.1])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0OIpwj2021654
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 05:52:00 +1100
Received: from oc5400248562.ibm.com ([9.77.201.56])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0OIprCo021468; Wed, 25 Jan 2012 05:51:54 +1100
Message-ID: <4F1EFDCB.5040808@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 00:21:55 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
	<20120118135445.GB25711@linux.vnet.ibm.com>
	<4F173F0F.5020604@goop.org> <4F1EBB73.3000705@redhat.com>
In-Reply-To: <4F1EBB73.3000705@redhat.com>
x-cbid: 12012418-4790-0000-0000-00000104268E
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 07:38 PM, Avi Kivity wrote:
> On 01/18/2012 11:52 PM, Jeremy Fitzhardinge wrote:
>> On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
>>>
>>>> That logic relies on the "kick" being level triggered, so that "kick"
>>>> before "block" will cause the block to fall out immediately.  If you're
>>>> using "hlt" as the block and it has the usual edge-triggered behaviour,
>>>> what stops a "kick-before-hlt" from losing the kick?
>>> Hmm ..'hlt' should result in a check for kick request (in hypervisor
>>> context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
>>> will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check
>>> before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
>>>
>>> Won't that trap the 'kick-before-hlt' case? What am I missing here?
>>
>> Nothing, that sounds fine.  It wasn't clear to me that your kick
>> operation left persistent state, and so has a level-triggered effect on hlt.
>>
>
> btw, this persistent state needs to be saved/restored for live
> migration.  Best to put it into some MSR.
>

I did not quite get it. Did you mean, add a new MSR to msrs_to_save[],
and may be retain only the kicked/pv_unhalt flag (persistent state) and 
get rid of PVLOCK_KICK vcpu->request?


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBN-0002FO-JE; Wed, 01 Feb 2012 10:12:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rpecq-0003wV-Rg; Tue, 24 Jan 2012 11:33:21 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327404794!12349598!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6578 invoked from network); 24 Jan 2012 11:33:14 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 11:33:14 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OBW8PO020196;
	Tue, 24 Jan 2012 13:32:09 +0200
Message-ID: <C8BD07BB8269428FB535E6C30604A963@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <xen-devel@lists.xensource.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 13:32:40 +0200
MIME-Version: 1.0
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	ray@aarden.us, xen-users@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 TG> That said - i gladly can forward-port these old patches, if you think
 TG> they are helping in any way.

I propose to begin the creation of the manual.
Specifically for this purpose I created a blog and an article on this topic.
According to the information came to the mailing list or in blog comments 
will summarize and publish
See link:
http://lixen.ua-ohosting.com/archives/31 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBJ-00027d-Jg; Wed, 01 Feb 2012 10:12:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RoKZu-0007yO-7Z; Fri, 20 Jan 2012 19:56:51 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327089402!5826427!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4534 invoked from network); 20 Jan 2012 19:56:43 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 19:56:43 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0KJtob5008865;
	Fri, 20 Jan 2012 21:55:51 +0200
Message-ID: <3B8433EAEDA04EADB4361C946BA29688@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "John Sherwood" <jrs@vt.edu>, "chris" <tknchris@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
Date: Fri, 20 Jan 2012 21:56:22 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_05D4_01CCD7BE.591C80A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

------=_NextPart_000_05D4_01CCD7BE.591C80A0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
Content-Transfer-Encoding: 8bit

This whole garbage works for me. I have 9 months of sitting in windows mode 
pci passthru (see attach). Also on the past 15 virtual machines that are 
involved in hosting this system, two PCIe graphics card, 2 mice and 2 
keyboards, which are divided between two different autonomous operating mode 
HVM. I'd like to see the login screen from the start, but you can not run on 
gfx_passthru different operating systems and versions of xen

 JS> Most people run Xen for headless virtual machines, and VGA passthrough
 JS> requires VT-d support in both the CPU and motherboard.  VGA passthrough
 JS> is also somewhat dependent on the card you're using it with, so it's a
 JS> hard thing to test.  If you want it to get more love, then you're the
 JS> best situated person to do it :)

 JS> However, on the topic of Sandi's issue:
 JS> If your monitor goes black, that's a GOOD sign - it's indicative that
 JS> the dom0 is relinquishing control of the graphics card, so at least
 JS> that's working.  In my experience using graphics passthrough, this
 JS> problem is related to your card not being fully supported; essentially,
 JS> Xen can't pass your card through to the VM during boot.  If you leave
 JS> the `gfx_passthru` option *disabled*, you'll have the emulated cirrus
 JS> card (by default) and it will at least boot successfully.  Here's some
 JS> step by step suggestions/instructions:

 JS>    - disable gfx_passthru in config (delete the option or set it to 0)
 JS>    - enable VNC, listening on all interfaces
 JS>    - start the VM - your screen should still go black
 JS>    - From another machine (what with your screen being black), connect
 JS> in
 JS>    via VNC and fire up the device manager in XP.  I don't have any XP
 JS> boxes
 JS>    left, but in Windows 7, you should see a device in an error state
 JS> under
 JS>    'Display adapters'.
 JS>    - Check its PCI slot under 'details' - "Location Paths" should help.
 JS>    Compare that to `xm pci-list [domain name]` to see if it matches up
 JS> with
 JS>    the graphics card.
 JS>    - Install the driver for that device
 JS>    - Reboot.  You won't see the BIOS on the monitor, but it should use
 JS> it
 JS>    once Windows takes over.

 JS> If something in there doesn't work, hopefully I can help you debug - I
 JS> went through a lot of this a while back.

 JS> On Fri, Jan 20, 2012 at 2:24 PM, chris <tknchris@gmail.com> wrote:

 ??>> I'm really surprised this doesnt get more attention. For as long as
 ??>> I've been on this list, this feature has been mentioned so many times
 ??>> I would think that getting this working would be a huge feature that
 ??>> would make the product even better. I have only seen the occasional
 ??>> success with experimental patches etc, despite this being talked about
 ??>> for years.
 ??>>
 ??>> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander
 ??>> <al@ohosting.org.ua
 ??>>> wrote:
 ??>>
 ??>>> Please make a manual
 ??>>> or let's together make
 ??>>>
 ??>>> В п�тницу, двадцатого �нвар� 2012 года, в 18:49:20 Вы пи�али:
 ??>>>
 SR>>>> Pasi,
 ??>>>
 SR>>>> I have that enabled in my BIOS, VT-d for the chipset and VT-x for
 SR>>>> the CPU.
 ??>>>
 SR>>>> Have you managed to pass your gpu through to the domU?
 ??>>>
 SR>>>> Regards
 ??>>>
 SR>>>> Sandi
 SR>>>> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
 ??>>>
 ??>>>>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
 ??>>>>>>    Hello,
 ??>>>>>>    I have spent a lot of time trying to get gfx passthru working
 ??>>>>>> on my
 ??>>>>> system
 ??>>>>>>    without success.
 ??>>>>>>    I looked onto my hardware capabilities again to make sure that
 ??>>>>>> it does   support VT-d and I am not too sure that it does fully.
 ??>>>>>> My hardware is as follows:   - Supermicro X8DTH-6F motherboard 
(5520
 ??>>> chipset
 ??>>>>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
 ??>>>>>> supporting VT-x, no
 ??>>>>> mention of
 ??>>>>>>    VT-d at [1]ark.intel.com)
 ??>>>>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS,
 ??>>>>>> chipset AND
 ??>>>>> CPU
 ??>>>>>>    need to support VT-d.
 ??>>>>>>    What confuses me is, why is the 55x0 chipset listed there if
 ??>>>>>> none of
 ??>>>>> the
 ??>>>>>>    CPU's supported, that I know of, dont have the VT-d feature
 ??>>>>>> option,
 ??>>>>> only
 ??>>>>>>    VT-x.
 ??>>>>>>

------=_NextPart_000_05D4_01CCD7BE.591C80A0
Content-Type: image/jpeg;
	name="01.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="01.jpg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wgARCAJPAzADASIA
AhEBAxEB/8QAHgABAAICAwEBAQAAAAAAAAAAAAcIBgkDBAUBAgr/xAAcAQEAAwEBAQEBAAAAAAAA
AAAAAQIDBgQFBwj/2gAMAwEAAhADEAAAAZ7wD9R9+k8ln8iZ5E3z95K/eL4z57ydx4J7x7vHFHFG
UucUZeHpvMX5iT1rYZ50404tc5E6sZ+IxlbFMfjb6fmzvyINjnpvgWx/NSuH1Y2246jmVteOpJNt
lSf2W0VM+6Z2z+1L/aLY/am/pFslT/qbYfanfpW16qH0teqiRa/7U/6m16qH0tcqmRa5VIm1qqn2
FqlVPqLV/aqC1X6qp9hapVX6Wq+1UStWqp+oWpVU+otUqqiLVKq/S1KqwtX+qp/U2v8A3U/khbHn
qXz46W07tRO5ne3XbqX6OW1s+5Vf1cdLR9utHq+Xa40r0S7PL9Rejnh2t3g9d3+3RPPMNLXYvW2J
vmdTdPj15e7+a/0BsO8SM6p/V5S/Hk0Cnr7PP+36flyd+nfhfifv2O/F8Y5Mv4vJ6It9TO+OWB+1
73DtjzxhnvBvEYd/MehXKs01ZH0fS8XE8/4dfPhUazr4vs8dSsNut+eh+PSRdrj9GVKeO7HKikX7
u2TST7doUl/V2k1pN+rr/qIpP9uwKULsfYilS6qFKl1vqKU/brfZilS6pNK/1dP9FK11EKWLpilv
26P0pcukKW/bokUtXSIpcuj9hS77dAUwXQ+wpf8AbnimC6Apeuh9RS77dAUvXQFL/tzxTHmuN9op
zy3B+JqX3LXqzWD0rLdjz7V39yde/jvF+UZt3fkfUwb0817vk2j/AL2ddnP0R/5ss8nn9kP92Vv1
8foIq+Sv+qXhr05Tj37Hw/f2g6r7/Y+vB8mq14/wvt7EO/XfM9vLwZjVPwsNrCZvTvEFtg2T1ImL
15e54WLQj5tLbZFrXlO2N7MLxvAp2kzGq/xPlTYpmWsO821JV+RStaV/kUiV0UISuigSuij7aJXR
WVlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlR
FYlRFYlRFYlRFYlNFisyoisiVUVCVEVpmU0WFZTRYmZT+xWJTRYiJURWmZURWJURWJU1qXXox7vm
eJf6g12Po+TIf1Asw+Xf2OOPo7+P9ixfH+sY1pkvHh+NfC0k7AMTwT7FZnzSqvpWi2H48bpwyLlw
L1TJmFU46XwX/wATiHD/AJPtm/ng/o+C1vv3DEkXj3ftC7k/RplbneS/A5xwOcjgc44HOOBzjgc4
4HOOBzjgc44HOOBzjgc44HOOBzjgc44HOOBzjgc44HOOBzjgc44HOOBz/DhcxPC5hwuYcLmHC5hw
uYcLmHC5hwuYcLmHC5hwuYcNGb2UX9vzPOtrUzZJ6Pna+bQzF+pyqbFGwzp8l2WJ9GRel684k5pI
8z8a+/E/RmiMf1/4Mj1ykPPfG/HpZbiHpnFfXyP1YpFutzbzHPWfOqdKdhMW+Z6vUif2uxze3j5H
KHse69OZIn376I8t6hHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHl
vUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvU+y8p6q0eU9UeU9UeU9UeU9UeU9UeU9UeU9UeU9UeU9
UeU9UeU9UeVQTYhrx+l8nDNnWse+Hl28OVtRu2230Mk7VfeXlvdP32onRvW4/wCa/Q/Gl6/xEEF0
XT/VA8uvNzVeMApW4yqnp3pZhSnu3vcn8YhC9Jsz8r91lZQxeO7QZ7YOjq0NsINx/wASPLZ2S4/Y
rfn6Zx54FyLTCVvsEX8IBWKVvXVYoV1WKFdlihXVYoV1WKFdVihXVYoV1WKFdVihXVYoV1WKFdVi
hXVYoV1WKFdVihXVYoV1WKFdVihXX7YlEV28KzFbTF0a+jE5yrzI01kBgEvJ8BYwVzWMFc1jBXNY
wVzWMFc1jBXNYwVzWMFc6v7LNbv3/iR/fCjG4vauvq/sXSrzX24v9GsE8eXWSIe8LMPZTM/zXDux
Nnu/WXNFpK7cOdWaTDC+OXAI6yjIyYx9nNUMQxeV0I96kmrRW+RMJzdP3JMm/Kutj1b4fjTFhVca
/wD12yv8d+v3wvRJswVn5lbKfus/QrNqflRMPvN7FYsyhNaklxbR6wiQAAAAAAAAAAAAAAOjWOzl
TdKc0MTM+z8mOfCmNNYizvIiZXRQTK6KBK6KBK6KBK6KBK6KBK6KBK6KBK9CrPVs9ngwTcBqO26+
b2VCth6H55z7tMZWmDvfA9MVxx14x+x5ZN92Uol03zPNfI8vfH8Yd7/HV5s+YNiqZyYdHNqTuxXK
qgSBX3N8IzeYkv59ROLdP2e7FapxVOFMum5XaVXuaY45nq/H9TL+lM+Xjkpc0xgX46kr3Rr6k1fv
Ka7ytmq0BEgAAAAAAAAAAAAAAdGn9wKa+nz11jiY/A7Xlse48m5Iri/mZhl0TAfsZt+7xhOQc8f5
b+nYmKJM9HiytjDWmTsYTGTsYGTsYGT64r7MNvbwHI/IzjENsurfaRz33v38+vh/ajz0Mw4aqW+J
KOPaY2MgSwvlZeipcg24+aUq/gtqkWqTjuwlF6OY3sHWpAk9lqBSwFfc3wjN5iSxE4Z5Wb9iFKqM
7wuL7HnwKJrIwT8b01zzm1HFetC5Etf24vQS0M4/LZ+j94eatgAAAAAAAAAAAAAAAAOhWiy9epiR
EoPR54t60tVkm0hfqls9zEt/aozD57SR+62eZrFpOeFOvKc2LTyiL/sniMEniMEniMEn6oDYhSzZ
Fr2+h87GtlWu/YhTXkHyfqRn7uUfhGtaNb7xrh6Jer/eHk2w1s5VsJJpvHGw9rGsKTr3sZ1I7XfR
awFAAFfc3wjN5iSxE4Bx5h+qoa8GNfH9uNtaTXo9n5++vPI74/Nqa4vxsm5Y21vepsJ46Z8nb4uG
7tgAAAAAAAAAAAAAAAA6Ne7CV8LIgY1kojPz5cEKZ1mKJirzJoSh31pMSwDPyIAAAYfmAUPvhSn6
Hz4P2g/zvf0QfX+dzDmOhwvudn0oik/77vqfn/vnnX7srx/v/HSnJ7UZBa1UIhu5mlq1Uia+3YrO
uiarF9uXjyxj2QziFbgV9zfCM3mJLETgkIzv+YnURl213X31fyb96271feT+pWiMb2YdsheYJC+Z
Wqdj95fCWqriVnJlmaeTjnPr6YZoM7gAAAAAAAAAAAAAAdGvlg6+FkQAAAAAAAAAANfewTRl0vOx
V/RB/O//AERe7yhxnWY17HhepDXtClt409nls9kmURb4vb+OT8/utIzyOSvF9GmGdzt+rSmYwzLm
HJwuRPIklEOdjNMdjT1fCjmTLZ9/PY5ka2UljPTGMkx3JYfnF8qwiJg7TP8A0JVU7f5Mu+BC1k+H
90X5llHszvTeYsh497QlN/W9mtet4+eZrTSkVnMezyJpj7c889sY3wS02bXvSHMZ58Giw4ioAAAA
AAAAAAHRr5YOvhZEAAAAAAAAAADRlvN0b9dyEUf0P/zxf0O+iQ4nrvH7+A+smrnR9uKvm/VuNgvq
Rb7/AJU0xxjnm3pZTx635DG1k+pW7wVbL5/UOyNYk98+y+i0AV9zbCc1JNBh+YYbmQw/MMNhFuvj
ZNSbrPHeXFozyDlPZ7Wf1p8K1rHZRV/FqxY/Ma4TnEY1kWBYSrbfBsahy2tqfRrDhVc7CSpTaaNd
powXwYwywmDKqlR1fW6eV1/iRXYp6JFQiQAAAAAAAOjXywdfCyIAAAAAAAAAAGjjePo87HjIp/oY
/nn/AKGNbfRxPY/jz/T8gxyvcf1l1820/BMFhbP2X58XXLllsdheCUPluiyub654yabavmt2NInb
n+Nbli9c7gDKwSr7muFZqSaDwfcwLrkjVk/MBMr1QlIVP8trS9unEgaxYzxY16dVnI+w+C5i0OYV
BxqbXhy6o9f9G0f1KIx1WNmapFt6gAAAAAAAAAAAAAOjXywdfCyIAAAAAAAAAAGj7eDpB7HjIp/o
U/nr/oU1l1qhT7xHY8WS68sl+zz00eTzQ18z790/YqvjmO1zfxS21+uWR/czZzhTNScNjWfBhXey
dMBEgV9zbCc3mJLET53cx3qGBQ3OlGZyvnJteqGxtt3U9iummxX7SuVb4z81pSza11PtDLBVib+e
mvh0teZr1xnXXZg1ly9PmusieWKgiwAAAAAAAAAAAHRr5YOvhZEAAAAAAAAAADSHu80j9jxkUf0G
fz7/ANA+sR9+ZH+cT2lVcWulxRWOvxUmOKW2K+dH8RTpIU8Vvme+EqNfOQaaXmVxx3JbBUfglb9V
zxoi3iq1qdICk19zfCM3mJLETjnb6/GVZiDmky/ksBmGO0jy9V5YHzqNJ0kKZq1e5OUm5FV7q56W
V79YeG1rOevXJrjPfSiqLMtradXDMX0xnrIac2YicuESAAAAAAAAAAAB0a+WDr4WRAAAAAAAAAAA
0j7uNJnY8VFP9Av8/v8AQBrPNx+X3uJ7Tk4aUXRtlrTx68uY019KJJB69NMFkn9+tpjG2Ezd+rXw
+Jpq6dLQJNmZYpdxev6HYzrh09QVleqSkWSbSsB5vhGbyksROL9X1vRKnwbfXxrYYR6EoU+y9Ep+
7g8qaIekXFu5FefkkTBaz4uTY35s6+v7UUWl0wwnH5G87LTpYZ6/Pd1stxXMJpIrGcmgESAAAAAA
AAAAB0a+WDr4WRAAAAAAAAAAA0m7stKHY8VFO/zQF/QDrnDctdv5xPca5JKs1lXs8Vfobvk8fuo/
7FyfpR+XbDJjXnIFzEXrnGl12ddQliL5vTel3Jc1hGv/AN68TVS24ffUrX3N8IzeYksROGeZmvNE
VRqhtJxHLyxxB9646v6ayTZP+NXtWr3bNfUVkwy2HsJrrFl6ewtUCR56Wzpv3LeKaU1wbYGtpQrI
7pJwiyUyICLAAAAAAAAAAAdGvlg6+FkQAAAAAAAAAANKO67Sj2PFRZv80Db+dcuX59cT3Xx9AAAA
AAAAAFfc3wjN5iSxE4Bx5hyQphEOxqDd8c3ops66/m31pedsazK7XrHe1D8mr6cLl/azy83m91Tn
FpAAAAAAAAAAAAAAAA6NfLB18LIgAAAAAAAAAAaVd1WlXruRi7f1oJ37+jzhxPbAAAAAAAAAAV9z
TC8zJPBh3T9L1SoNYNg0O75251W7WPMw21pTvabGLVwiu94f1CjdgZS9CGtmVrnenOlWuWxOFKw7
j1wfQq1uy7ab3N1UPGk6Z/NtUta/1/R4q2YRbzCPP6Ja9P8AP61xCtwAAAAAAAAOjXywdfCyIAAA
AAAAAAAGlHddpYy+xGG/bQXv07v8wDie3AAAAAAAAAAr7meGZmSeDF+XrcRphy66dW/1v42x6o11
Yq/J/txHJHm5dOMXZHkmO5a5VYGDpwmeb6KgAAAAAAAAAAABAJAAAdGvlg6+FkQAAAAAAAAAANNm
5PT75frwbv00Ib7/ANA/MQ4ntwAAAAAAAAAK+5nhmZkng8D2MO6hHlUJFjbo+W2B1jtnSHm+tnvM
KdZzelkMRh7y6Lc4/h1aLzZWRamxPK8WSVj96sWXzGA58mgVsAAAAAAAAA+ffyffv5+xH0TJ8+gH
Rr5YOvhZEAAAAAAAAB+f1AJNRm3PUlesBb6tC++js+HDie6AAAAAAAAAAr7meGZmSeDy+1FULEue
D+IDt5L6QplNS8vdcLMtYXBedoePV/gatdjfnazZcmL69nWrkN89hIrcAAAAAAAAAAAfD6AAADo1
8sHXwsiAAAAAAAADi5et2YqE2ai9umn37/NQ1vn0Ob4/r/IDie8AAAAAAAAAAr7meGZmSeDwvSx3
JyDo/tVhUx7OPdOr3iXt4YNhGm14/tMOL35XZ6lMuWF0O1X2l06bU1VMHtleNTyAs7bQGubYzrAU
AAAAAAAAPx+P3D9iQAAHRr5YOvhZEAAAAAAAAH4/ZAJfnTluL03ddxcY749D2+H0ecOJ7wAAAAAA
AAACvuZ4ZmZJ4MRyHw+c7HhV7rHfPZHTK21EPh+2zU9V4wusWV9mP8D+x5ctzmEI0trdjH4NjuIu
/jkY4HdZPPKG2QvnnOUmdgAAAAAAAAPx8/XFnHM4eW8/oSAA6NfLB18LIgAAAAAAAA/P38Mp5BrD
TVuU019jxEcb3NEu9rbAOI74AAAAAAAAACvuZ4ZmZJ4MT63reieJAtQIf0z3XxT6UI4b5b7GQeva
kfcmTdm0YnwZjxxbvRXZ7llD3JLpXCvFk9EgAAAAAAAAAHz6AAAAdGvlg6+FkQAAAAAAAAcHP1uz
AJNNW5XTd2HERzvX0V71N/OHEd+AAAAAAAAABX3M8MzMk8GD9HMu2aR4I/oXjPJxQXdCObWgrLrH
fL114S1Zv14UJmifuhLLe3wc4AY5kYAAPNPSI5JGAAAAAB+f1+fxFeV1P0t2X4/SPr8pfp+UT06+
WBr8WREgAAAAAAAOLl6/YiAmWm7cjp07HiI43paMN5+3mDiP0AAAAAAAAAACvuZ4ZmZJ4I9ZR6BQ
f3LpwfthNeuXY/8AMPTQDp7EOeGpjYxKPnWzoVi+yz5DVDdax37tOpeW9hpek0D7RcEiaO8ey0mn
0UbGFstd/ibK1Lay+ts9bX1VzbednQIgAAA+fQfD6+fQAA+DpV8sHXwsiAAAAAAAAA+EfXwfdQe3
zVF1vGwhvL0b7yPV4X3594f9BCQAAAAAAAAFfczwzMyTwYh0fS9goT69s6ywsrrV2yxkvX7yLUck
0pXm2WzMjB41sv8AYa7pltr8bUdxW+/28VwszwZfOHoilwAAAAAAAAAAAAAOjXywdfCyIAAAAAAA
AOr2uDnigTdrR2XUD6blqa7xtHm8P6Hxvn3594j9CCQAAAAAAAAFfczwzMyTwYvzdXgKq6u9w8Fd
v8m3VebTVp4r6WcRPJv2l8RlzxM8tnBHRzj9Nefp+9w0v1bIQNPOuIUuAAAAAAAAAAfEPr4l9APh
9fPp0a+WDr4WRAAAAAAAABwc/HyRB8+pUouvT37/AMOgO8DSDu++xzIcT+hAAAAAAAAAAV9zPDMz
JPB0OGOIanPuRTklGPv/ACNtVfbAVHvE0ZZTuW5vJfLTWY4rIP4hKSbZyt5VTpO1mW46x7H9IuB0
6uSnSuf9evXoTaTvahXza2kaTqrY/NrfTRUi1+Wcgfrj5OZ+8CQAAAAAAAAOjXywdfCyIAAAAAAA
AAAFRbdUm+98Oj27nSVu1+tzD78+8V+hhIAAAAAAAACvuZ4ZmZJ4Px85CMFwyZsC3x5a+2W0KbRv
OwbKaj+fS23TpNiekXO/EBetrWdueu8j0j3OWOf3eJp8bE4arayPoRblkTmki05xCL3VwrrwkpKE
/ayrqzM4+jQXj8vp2JNcHZimxbG9Yd0KxJci6vs/20vhj+s+6lKTTktKYli+x70tY2YXyuHI2sfr
RttBfn9VxBIHRr5YOvhZEAAAAAAAAAADVHtc09dlw+I7stKG6+3jffn3iv0QJAAAAAAAAAV9zPDM
zJPABwYzkeDmcVPsXpv0btuDCIizvYzj1ffmabN+zrSnVa6n7pRidNdgag+J3pskVnsxfzBnqAAA
AAAAAAAAAAB0a+WDr4WRAAAAAAAAAPh9A09bhdSfZ8LHu63Srt7v5cwYd4/E/okko5EjI5EjI5Ej
I5/BJKM+YkZHIkZHIkZHIkZG3dM8Yp+yJc1j6QSTQAfj5yDjoxetLqYnm6GB8EhjxcSkdE4TyZkt
HlYNJyGH5gIBIAAAAAAAAAAAAAHRr5YOvhZEAAAAAAAAAACil66i/f8AhUR2T6z9hn1+X5/S8eOe
J/RZlQCun5ALRPyARP2BR99zehNsEcBPyAWifkAifkAiefTrlImafIK9rmo55FgeSyekc/SRUdCR
UdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCR
UdCRUdCRUdCRUdDN6+SHFRaNHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkWo06QB9v4
1VdmWtHZN9Lnuw67jv0HsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647Drjs
OuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOx1vvUPT
dcdh1x2HXHYdcdh1x2HXHYdcdh1x87Pmds7DrjsOuOw647Drj8wjMkM/b+JTy7Wmnu9p+Qbifmn9
837+4X5qA5Tb181Ffc9NvDUZyw228mpXmbbY2p79m17k1R82Wm1X5qt/UNp/Lqt5ZbTWrHknfaV8
1bc+UbQmr0naN81i/iNNnrWLyS2bfNaHPG2yjk1pk7LGtTkRsl/Wtj8Gyr861/2bJ/1rj48ttjn5
1u9PXLZe1l/Zy2Z/dY/AjZ191h8MRtC+6tvm07SmrH9MtpDVn+axtP8AuqvhnHas1Tjav91R/NG1
35qj+m1v7qj4zbA1OfZbYvxqb6xtf87RtH+n0v6DeHQP3tct+f60UdmPLvU/ekD1GW6nk0rd6fJu
f/OmznjLch+tNvfpG4b96hvSx9+2r86ouy22tfNV/Yy22idjV1xRptG4NW2DbZbevmm78e3x7mfW
0/2D+J97YGoj9+b9e82D1Qxz0eX/xAA3EAAABQMCBQQBBAEEAgMBAQAAAwQFBgECBxUWERITFzYQ
FDRAICEwNVAxCCMlMiJBJjNgJEL/2gAIAQEAAQUCUzeW3C0pYZToqLaNblI2yzcU4G4ZyNwzkbin
I3FORuScjck5G5Z2N0TsVlM8FZXPxWXz6grMshUFZtkMGTvI1lD8m5GJBmYciliuacjCua8j0Hez
I4725JHe7JQ735KHfHJQ745KHfHJQ745KHfDJQ74ZKHfDJI74ZJHe/JI735JHe/JI735JHe7JI73
ZIHe7JA73ZJHe7JI725IHe3JA725IHe3JA725IHe3JA725IHe3JA725IHe3JA725IHe3JA72ZIHe
zJA72ZIHezJA72ZHHezJA715IHevI4715HHevI4715HHevI4715HHevI4715HHevI4715HHevI47
1ZHHerI4705GHejIopmbIlRTMeRBTMWQhTL0/qLctT+otyvPKi3KU5qLcnTmopkmbVFMizUMkula
8/VXcam7gtwd770ru8nIUZ88cUdXGSkLF8if0ii2VyCoUS99TlXus/LVEy59PIulcgoN4SjnbUvv
1kke3VjnCmSoX9MvvcFDya8KWaqnIrASDJu3lBtlTa6Kyp4TcrQ5Njrinnjq/tTctlKxTMSMlx5Q
WqmzYkbT560Ublk9jSV8JnCBVeqyTE0918rRHqm1eoemdxpSlbrhxHGn5cKfW4flw/Y4evD14Dh+
PEcBbUW3C0wWmAswFnAs2gLOBZg92sTJGZ8UHO3vMahsfX+9Rrb2SQrujbylfH2vunt2fLiynWRC
1xfjA4SdnWxWrrIeUx1kQYjVJzUgVmIFix6LvoW+LFpSxvSuhp0fLMvpF2AlDI2K9c6mRZs5aRJk
tSWNVnRcqIXE0iKxpKnIijYTVaytqhW+x60ltLSp0bglSNKIIWZA0XGo2ku23oNiZappfXm/a4fV
4fv8BwHD8+H423C24WmC0wFmAs4FnBKsKoXQ5HWlDUwKPJsvLvT2E86YcU4NTlnGWoybRQgodAsV
TF1FUBNa8CiikKA5edSByygpBZfQWQuYW02hMxtCaDZ0zGzpoNmTMbKmw2RNxdApzUVx9ORdjmdV
rdjOd1F2L57Udq8gDtTPxfiWfXC/DE6MHY+bVHYuaDsXNB2Mmg7FTUdi5oOxc0HYuaDsXNB2Lmg7
FzUdi5qOxc1HYyajsZNR2Mmo7GTQdjJoOxk0HYyaDsbNB2Nmg7GzQdjpoOxs0HY6aDsdNB2Omg7H
zQdj5oOx80HY+aDsfNB2Pmg7HzQdkJoOyE0HZCaDshNB2Qmg7ITQdkJoOyEzHZCZjshMx2Rmg7Iz
QdkZoOyMzHZGZjsjMx2RmY7IzMdkZoOyM0HZGZjsjNB2Rmg7JzIdlJkOykyHZWZjsvMh2XmQ7NzG
gtw7MbRbiGZ0FuJpjQWYsmVgtxhL7RbjeYUFuO5dQW4+ltBsKWDYcsGxJYNiysbGlY2PKxsiVjZE
rCxGaiOhF1LJNqJfK2T2QOdqfIbXQ1M9o1hHv7KiWT0iL2uctYGa9kydH5MCZzFlNzdLGF4GoliQ
ysqPpi5t13hNNowsPLkTWdXUSxI5QWwR5ymNG8x1yYwJEJMzjahx1CwaiWNQLGoljUCxqJY1Esai
WNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1Esai
WNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1Esai
WNRLGoFjUCxqJY1EsalYNSsGoljUSxqBY1AsagWNQLGoljUSxqBQ1AsaiWNRLGoljUSxqJY1Esai
WJjf1JLEv5+lOItxmltYHnHLwtNjbbc0sX/p8hjjIn5ojsvY1qWGP1p1mPJIewNEcNa5CHxsKemZ
HC3j2DLjR8ameNQdQxPIlTWe+Rg3GbCQracYPaJoiLI5uaqteP8A+Qk/85E+fXemoqKWqx0zx01F
R01I6amo5FN1lS1A5D6hQdclK3dGeO7o1QI1VjkT01A5VN1a2qKC2xTQcp9LeRTy8qq4L3dua67t
jILlMdOM6aodJSOmpHTUjpqB01A6agdNQORQORQORQORQORQORQORQORQORQORQORQORQORQORQO
RQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQOR
QORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQ
ORQORQORQORQJLz61D/591c0rQjapmRytziidk7hLGFtVp5nXVreBljB+rC9OhreQ3SM04T0n3Ce
qBPzGJLS72hMQnWvF5hDQcja09aEpU6xdbwXSi81PGYPdrbfDDK3P61NYokenkAtuSrFELvMOQuT
mkbKQebyt6fWpXarrwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAc
BwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwEo/nIbTjIpLG6u
IKhi6RJYjHj2BseoM4L3nbi492a2qxqQR4r/AOPvJDmsqp6SFimhf+5cnt5G5tLNeG2ytyt/L/4J
YoMbEyg33Lk4l/8A980s5YdCnf2ccw5/vLk5Nt8lTNnUdm0i32UFK/42SEHc1rEsj6eEIU6Vu6Y6
Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6
Y6Y6Y6Y6Y6Y6Y6Y6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6IlVOEgh1L7
pF7NYLUKmy6qNXUe0WC1sNsM9osCdsOSJzWIs++6KN14do7V6S3Y4Ovv7bGBuiPsS7kSq63aLWE8
cTIzDGw40w5tOUk9vYxQN0XQs4c4OavV9tjQXjk8u9KyeyHs1Y9kroPZrR7NaPZrR7NaPZrR7NaP
ZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7Na
PZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPaLB7R
YPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7
RYPaLB7RYJRbdbIGMw8p7XtxrekbZUzvBTYmMdU9GNZcNvrOO31Y2+rFWBXSlrEquu0BWNvKRt5S
Nvqht9SNvqRt9SNvqRt9SNvqRt9SNuH0G3lI26oCy5c1mszXNnZn23NhtqahYyzNGSmTS5UftubC
6OTegsj83uG3JuLo9NbaWx2bVrtqajbU1G2pqNtTUbamo21NhtmbjbM3G2ZuNszcbZm42zNxtmbj
bM3G2ZuNszcbZm42zNxtmbjbM3G2ZuNszcbZm42zNxtmbjbM3G2ZuNszcbZm42zNxtmbjbM3G2Zu
NszcbZm42zNxtmbjbM3G2ZuNszcbdmRQmKx+KdNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJ
yeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeJVbWkgZqf85kFcpQqsZN0m
iCmCXKTWWMs8WkKlumskVOTHNclvhdcny5wb12Q3dOnQTCesMejckm7pJ9ashWRI8ukEOF+T5wuZ
lWRnm2cW5Wk6FGlmuUKo2edTS5W15QyOvirnIcgqn2Q0otmccf1cawgZNZYmPlk6lMadI9/GQ/js
3KWXEmPUi1zJb7JdMHlYIRI7iXOYys2IlrJ27uTQvyfIG9AVKMoHrbTGrI9hVOH9Sp+NJfMc4TZy
iUfZcutrgwSLK0gJeiMyx4ixJm+MKV8EnKDIDP8ARlXkTRTg9zWKvz+6osYyst0/XgtYYg5PaBhj
NXUllZ0dO20ZOkqyIRRxcjodElRbYwsTLbVrbK3OEXjLuXbH2G0na0Zo6xrHFGeUNcLhzILWdosB
MKhqZUujUdc7HJmTOalBA4O12WxKK2smyob1HhMmSKYZ4c4wyHu613SXLWxRi5+KMQYwkSZ7VI0S
8i/aR1bY3G7iGuJxdipdjyBXqKU4D9f6hT8aVnkppYta4k4S5DjWDtFXyDwx+XX4zx7caTjiBJqw
yMw2EqtbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRKKcZE228Hu
okEzj8ZV148qAxTevgqrrsuQnd4bVVk2bugblRzVkXZxhpbopy8gSWZJMdiYVSRKIsjU5UZrCbcj
3t71ZdW+z9iQ/NhfhwqHFVpyRKqKXEZiyHfA2uioxvcWe0wprj0tdlclvyUnoy3ZIT2LUOS29wdo
zkRK7mPJkqdpxbnNgb0LvkJuKjqSZFLHZBnyEOidCoNVo/6BT8acmmESLVl41ZeNWXjVl41ZeNWX
jVl41ZeNWXjVl41ZeNWXjVl41ZeNWXjVl41ZeNWXjVl41ZeNWXjVl41ZeJJTjIkFvB7qF2HGFxmF
936IiHgp4gVqqxokkaUSEtniv/zEjFyIsVxwmvJcYK0OYdmJI8R57hpLsYqxezGWu2Nm5zSpUxSN
N+xIfmwvw70eEh6xClakZCWdNDcrR41q5MxphfvUbfiKBtAJxuhKalkBQKnqyDtRFEmM25JV4hFr
y9nQJJY4qMesikJIdYjfG/HxrS0x1iRRhj/oFPxsh/o9TxQdtxQ+3QZYiyCbcnLmCohU6zxxa3Ka
uzm3SW+SKzJ0jyQ4rE7pks9uZHCdLkx12Tza3ti1YpRdUdUdUdUdUdUdUdUdUOv+pGNt81TrU6si
QU4yJPbyvQ4CtKVCk9Kl9FKp0lbsSud2m2rgpWMsWmzmvRXzSHFJo/MW96COVOrnKH3Icea01sxi
F7NKMgxqNR4p+aLkyPILBRqKfWQ9z/GQ/Nhfh3o43IqIqcLqTyaWR1nh2c3iUNTUvNVNTHKXyRGF
S6KqTKzuE2WnSeNpXRTJY8kSNGTYS6RpI+M6lz5LeNKUp/RqfjZKrwdnZub3tBSNMOnbcZakK46x
rgdGWU809GhUraxaN1RpIyxIr1UPjK215iBrk93xNgMususLs6tB1aDqjqjqjqjqjqjqjqjqh8t5
pBycjzT1kBBx1jSkNQIvdmRp7V6I3pmRBVrZNoydLE2zHkxZUcLgr5EpE+Rd/e5fbA5OfBJNjF5c
1rrjSUGNDtApeapc8VP5h0Lih8bWfjIfmwvw70frDTEDagVJkL8xEyZ6QYQjiJxaEBjc1RtpmEcJ
LxrKDY0844NVlERx6epSTCJWQ81xhK6s0Ki50eXf0ir40nSJ3CX7NjY2bGxWGxzhtCODaEdGzo8K
Q6ODZ0cFIfHKjZsbtFIhHKjZscGzY4NmxsbNjY2bGxs2NjZsbGzY2NmxsbNjY2bGxs2NhzL535UX
yO1PWoraJDJkl77Y/EMFrm4JWVsj0jbpIR6KZAzJWZY/NqFb+1Ifmwvw70V23GJ6UpcOArbQX/pa
w5FiciUJFRa9IzuSB9bV7uibTLlpBaoUrwFta1/pFXxnvzj1yx7y2FymXvjwzIMguKtwMzI+WMc6
lpDVDY3kIq+NvMwmaJ5Mn7mQpQ5JeD3SCy1VLEP7GRMpTKFf6hQps5310s5XT1k1xVhbcc4XIZsr
tQ5BvUGKychp1CzH6ZyeEDFIWudIH9Ixya5fjKNpDsSok8zPjCdBP1siaD585PTKlyCawJExaJL+
Uh+bC/DvSTXWWs7ae7XN5klcDXF2lahhSMjxY+tMKsXOzBGrpGWvwskfWxpoldVU0YmGYGs8lMmz
1HGijqmkdleNf6NT8Z7849XRob3pKfDo0pCaCxhG8qMeRJQ3XsDUYc5QqNO9yjH8XV1OgMUUO1If
HbbWOMtMdt/YtYGa1/FbOZ4fbeVy/wDfpeWWYL6UoH+BMb85lY4hxlla/oVWl378h+bC/DvRXz+3
py2iZLYOyPxrTFXItnaErE2cLbhZwuBlLLbKcOPJbwrbSgt5a38KUFl3Nd/RKfjPfnH101vM8K5M
xvzrT1eVK1OG5eW6ont6SJHlhW3O6KUt9XWOm0qicHrKksQRZ7yRKW4oiWZDMqoK95/pvLOfo+cV
N3C51pLpVGnImWZNVLYa8KXpn/GQ/Nhfh3pJH5pjLRjjIBk6Z/8AUZEpDM3WNu0yTtyReQ4JIOys
LQzxSYP9yZxnEte8enTuQkyaIzJdKz1WVX5C81kL+ySlryDOnyrbPJX75JNMoXpIs/yBa/f0Cn4z
35x9dRIWhkfMZ+SU/wA+jg3JXKzhaXR3hLiqdmaJaOUcnSuKVui0ZaE62HxJztvZWcwm2BwexBRn
aaIHqPMEkTKWNlW20hkPo1lROLJ0TW0tTGh/GQ/Nhfh3o/N7Q5NzO0NDKlXJPdEyjEbrIXaIsW0o
syMUKjtyWLQ+1XDMcRiKR9XFWD30YYdDRJYpF0K4uCQpIgcMaxVycdCY71zXC4cyBrjcdY1H9Ap+
M9+cfXyz5PjTyTh6uTja22knEKic6OV1zJF5QlZA/OSxpxe6ygphbKZHQnJ1uR2dvmBUskF2In+d
3xeVyDMMZiziblRBSsqlaSIsKjMbCWkmuRD0dkqcnQ16Yp+gtKJyyz3oHzI7IwXG5QREWPt1b1ML
8O9HoqhzPwoOAQkWWKsy/wC1jrC+SEiUvH65KvZp8/PjWbMr3o9yhyl3uf8AFMykj6GnMEefmpPm
dqYGSuT2WqpvyW2uD05TrQsgs0llEydIk4vj7GTphMqX2Tt4W2waTyJc6Ok1d08/jEwkbhMUjzLr
I59hT8Z784+vlnyfGnknq6IVK0IkSZvTSeByVyXR6LaY6O7CheI9fADFDfdjpFYTTHSHcNkIaLIW
RA+gnRYxQM9XDHaJdH3qHpHdKRjBhTtbjjFscFcgjCd+MZ4A0s6pvxcyo00ixYr0hVjROtZXZMUj
vhfh3o82dRo9CG9GctqwstbZrH5YmbsPo8hlO7njiGPz0lgzSjb2WMFMrobi2PmsVMZpqEk4uQIi
jcdIT3ImCtBALYkhUhNxmkoqPhrdWJ9t+KYjGEfSqY/BWyPOLaxJGtxIgzWmtTY4bU6j7Cn4z35x
9fK3lGNPJPVSrJSjjUTOZKEtLXlxYFD9JbGiJMk3WnKDp7CyG+NZTYniLLJbG25RWfQqlKyZhtem
uWR18U2zuIXoELimck35P/zIX4f6PXG9p9EXGxRk15dGKGYly0/zgqKLFKtAtlbxulpyrBnZsVzO
Kt9ZXPWmMC2XxgxVIclxdkYFkmqiUmT5aoud5Y8sEYMkLSVHWmQyQ0WzaGXnlSmMqHKPZHZpJGDZ
LH0rgzyFgkNjNMyXeT1yFHzJOVNYaobL8kwq18smcPMCRWlXpfpqfjPfnH18reUY28k9X0k0+1qS
KECG8pCzv9IwmaA8RlSqx894wSHQ6NQZxQPiCESZhbu17omaXjHF62h8IlqubJsVOFsdfonMZMyR
dsuaGP8AJ/8Alwvw/wBHqnO0+lG++xQ+Ri1/a6w1Nj2N42cHk5NN42/yZSdDZxa3JMTupMee4DKV
ahzxvM3ldL4FI3IiTsTg6Re+HOrUmZMWPyMtogqsiBu+O5XJT5ZAJU+OEKjrw7Le0ruVFGqOSNif
YSyytgZ2jGMiZr0GPJ6ltWQ2QRw5pgskbHRow89omD6in4z35x9fKvlGN/I/XhQH1oUQpQlLC0a9
O12ujgnZ21hmTJI1FLL63dehi2tDa1e5A0x+rjImtoca0vpXkqP94f7w6hxdfwf/AJcL8P8ARamo
tR+h01U3kNLkQ8NqTIEFkxZsjhzC2sUzYZGpWTCOoUqjIkZS2tbmgfECHIEZcXciexVa6M8iZ5BS
OSRmlTbY7N5jsQrKUG/fU/Ge/OPr5U8oxv5H+Cv4kvld6gJlRzEJWrPf8YuKl+kYjqqSMjU4p5w1
CW1cj0s2aD5M2eylbo8tZs7WInjcLUmfXKTJ4YXdLTci4ySrUkK/B/8Alwvw/wBJDyUbG1S73tzn
Pi0DgW6NDU3Q8wk+NwktW7sVY2+Wx4x3NWr1TWdDVzzIU+7oq0SpG3sEfem91SagbEG9hk7bWONT
2y47050OVKKSqOOMha50gf4HcvslH3VPxnvzj6+U/J8c+R+hxpZBRUsa77CnNncKuWKm9zcTMQID
DG+O2tyDSrq00u+go01oNJqKNV1BRprQaTUaXfSj3j1nkZuk1BbfW0z8JB8yF+H+imytyfktDtBG
91cVUPa3A6G2Nlke5LRyWjktHJbx5bRyWc3JaOS0clooXZT+iU/Ge/OPr5S8nx15GJflxAwyuX0p
WN6I5OREUZ5WXOMnMRK69umEnbwpmc3Tq1GVn1C9O2SphG6Q1dKF7P8AuSH5sL8O9Hc9SnRIHexW
jPlhNVcnXTJNIcXJ16aBxpio34hbpxJVboiylM7YtbO5a3n7wVlwtXI5YwyciYLI89qJ/kkx7kz2
+FPrjNpQmdU83nCldBJLOaszxNZK9wG+VvUYXkyzJqpbDXhS9M/21Pxnvzj6+UvJsdeQ0Gz4lqss
aVL4w0Z53xjMAeG2WP7DFHmlWuHuSxDG482JaRVgSqIfjJBHgzsTHHUn7kh+bC/DvR2JTnoCLLSC
5TEWpze5DhN6cVULYDIvGdIarW+2Ox9O7NmLWVpgiiEpkkeRIyEqNDC4e1kKGRmVFvEXjMiMeWBi
kiW+Lxo10tZ2iwN8ajrReniUUSXLI1HHBKVE4snRNbS1MaH7an4z35x9fKXk2O/IaevCgupaHmaq
2NYbkg92vfnl4bsYK3uQQ+sgyGZcyRiSlSVDDchSVdjZkyymaYw35LbXB6R5hjay5wzJHWdvvzRH
apVGWWFuRIsyMjqnjeRVEnl/rIfmwvw70c1fsUiRWSsInqV4PF77JSjY6pcVLKly2qU48snbUda2
5cSOhS3LUbRWoMkty16epkqi80XZScvemZvh9jm2TWRvM9Z8wRx+apBmGMxZxlhj4smN2Y0MTY0k
+ZnJKx5ASuCMzOUHLdmN0NeW37Sn4z35x9fKHkuPPIqelw4i66tBIt3nOrO1yGr0/M6eQMdmOEB6
J2xk2PiyPRdFGCmnHMdZzS8Qsiey2As1pZmLm9lYYzjtzcUh8ARLSXfHjK9XoYh0HGP4+boys9ZD
82F+HejwkPWIUjSjJSv2JWh4kl7BI3JZjchxTw8uDttsRsx0go9s8FaWahOJWhPYRB2okO2PW96e
1+P25e4G45T1IXQRmda24zR9A+DGXuMjiGvOajHTXQsmHNxcjb8boWYJIPe1qYpF0URa/tKfjPfn
H18oeS498iBask0+vG61yskN11P0tkcndG51MkrGncmyWRh5qnlbTRLfMYiVRDIo+6L7ZbFL1SWW
RVcmi8wQSxUzzMl2kyWZRBaHafMSVqvlrK2th8yiKVZF58yTFIimcPckNZzCaM9l9htkh+bC/DvR
xuRURWVpwcHlrQ37naRco6yNmyZK5EShnznIHaXSMyNNMomjw0sr/NlUWROrxc3nt0z1N9jMplbw
9pslFnsK3J0jbE7w/MkdRmymMEOl01h1iuP5KhMjZ3WfxxK0Ip61XC6XxOyrS9M7+i+yp+M9+cfX
yf5Jj3yKv6UvbFih541FhSBQRFFxp0sn7I6yJvTY3eW6Vk42eEsUXQJ7tdpHAJC+ySIsMiZnhyxj
NHhxe8cuipREo/I2g1nxnImO9qjzwdhuyAyN5RJ4PKWRethMuc56TiySLI44Y/kslTvkFklViWw8
tNIfmwvw70frDTEDYgVpkKpFKGuRT/JLo0LoCvUOWP4zEciRmluMlDVIpJF3eRvhUGfE8IfII7yO
QxVhkjeWz43kTIafGpATYuxQ+ko3jG96WLSdkfjX5wg8kVuqLHjgkvicCf2y4vGMpOjT7i5+XmIM
cqSKQ9FI0DN9lT8Z784+vk7yXH3kVP8APLQVstuFkXjRYLSpirq2W1HJaOWlBSlKfvyH5sL8O9Fd
txif/wBKVaNHS9VGFl1Cyyw2y5gdvQl3bzHWn6C+2lbXJ0Rs7cnMtNKpS2o/T+jU/Ge/OPr5O8lx
/wCQU/z9aQ/Nhfh3pJrrLWdtPdat8yfnNqdt3GUpGKrD4/BmyaQ+CMip+jTJImd5bndxtk1ZKvPn
Sh4njS4ktUetXkz639f6RT8Z784+vk3ySA+QU/z9aQ/Nhfh3or5/b2UsoHFcQ3EsWTGB8Wf4HH9F
rI3O6mhdtByU4dOwX8LaU/7dTlFt3Gv9Ep+M9+cfXyX5NAfIPryD5sK8N9Hs5SSjRPHukmX3FVt9
9h6CEygz9aQBUrT4/hktvjcTlksyBHlMskz+2sl2TpyuZpxI3t6JlT/IE706SCUSRGuyBLYk3Ncp
yMe8TOaSlpfVU+k1VyCVShS4WzCUPJSmeS9MuJnsmNfcuP71c1JZpPnCTuM9WPDLWbSG1lJmGVaR
5EosVo/qqfjPfnH18neSwL+f+vIPmwnw30eCU56MggkkuTtvulsgaZBLii7ij7E7U2JKWx5htJMg
UHOaV8ajrog25HuiqiMUWrXiOx+Qp1UZjbgeeys6qjVFoww0XQFjdpafG46qeCWdoTnXxGKGi5lZ
r7aY5605dovGn85TFIstc9EZejbGo5Y8dtMc0S0pSlPqqfjPfnH18mW8ZJAv5/68g+bCfDfR0V3I
SEq0lWT/AKonB0b3fHkyY3GEx02+rDD8hSVdjqNZSPKiZ+UWol0SZDc91k5Ya6oG2eWuzzb+tP6R
T8Z784+vkazmkUD/AJ/68g+bCfDfR4SnrEiRpREpMgYoiMtNZ8PRyxU1t+mtrPjyPs99uKmklEog
TQpsT4+bUzgVi5qtbnCEpHN3L/x/SKfjPfnH18gU/wCfgfkH15B82E+G+jjehsS2VtupPJ02Q1Pf
KH5pdGo849rZssFO8Kf8iw+NEoZZGXBud5VGWNNJpsxR1tb3hCvuSTKLL0zbkuMqbVkwiTeG/IkP
cXMuZQ84hnkLBIbPvqfjPfnH155bxfYJ/P8A15B82E+G+j+WYagbW5WkbstRFolLZjlOzL7S7Sei
oxe87Xrip6rV2x49SI0mHSxpOLxc5J2iFR5xjLQjxjM7i9jT0y1LCZEldHvGsgXpWGAOCN3gDJI2
FB9av+Kf4/NT8Z784+vPf5uDU/5/68g+bCfDfRUXeaXbbbyyi1usvjTfHlJlLbSrU0/jCtyukTIV
fWvMONKUXOza3Gf+PGqsuh5X+P6NT8Z784+l/wC/wyDXg8wb+f8AryD5sJ8N9JtI1kXYsSuM5cI5
JzDqqSbXgxRHXA93Yk1rgZEmyHm0D0knmlwpE8Xvt6N4VzKKJp3YgV25Bqa86ibDmbWE0i/olPxn
vzj6X+K/hkW7/nIP5B9eQfNhPhvo4HXJ0dtltRMoKimVrNjdAiu6KRobtbTdalKVpXhzW8tR07OX
koDf9u0r/r9q3/H7Cn4z35x9aoyNX/5BB/5768g+bCfDfR6pzNln/Uz/AClVFJ1jo6EHMy9UYkUx
WVHO92TFJSJ3KmUtMnEFnUuelTjO5Wne3KSvrrFX59dW9CyzWYNjekmT+pcoTK3+QpohNZpJpTKD
ZM7ZPxonJSPX0/1qKcOH7Cn4z35x9aoyP5DB/wCe+vIPmwnw30fLeo023foqVJkpRb4ymnPBKpQ3
N0Cm9S4jFHFjXaW21vNh0SPXFsjQlvQwBhKkxsRih7g4sbK8t6uGQ9e3ENDSlPVQ+JLS7YtGC3sI
WNla1X0+H7Sn4z35x9fI3kUJ/nfryD5sJ8N9HVVVEmSrSFhMia+eVK0tym6PEWoWHHuSDzEpmTkS
NEmyq4EGyKROCCKEmSKRunPKpI8suRZAul8Mlb4/z8+dPReQJHJ3WyBZOk1zI/L1M4WpGRe4EyP6
vLUcK/sKfjPfnH07fwyN5FCv5768g+bCfDfR4SnrEiVpRkpTkRNyOMsy8uR05eRJDmlPDu3CJQQo
hXUWnQpKnhauG3rVzjBiFi9RjmOHktMUamdyccUtLmndYhrUXQxL27k7MSR5UtTOsJkH3lPxnvzj
6VP+34ZG8ihf899eQfNhPhvo43obEv8A4GWyy+RO2VJKbM4mhijurfI1FMlqniw6cQ0ixTIWNA40
mkPuLtl0WNUJpfFFVxE0h56m2vGn9Gp+M9+cfSp/2/DIvkMM/nvryD5sJ8N9H8sw1A2t6pIgnkjs
ieXZHLkksb8fUv2M04mIaccvcIfjVTTHpAwyBixa9sjKijM6Ld7MbSU2NmxiQJ5MVzcP6NT8Z784
+lT/AD+GRPI4b/O/XkHzYT4b6KrDDS7bacD06K29rWN7i4mX9IMUtZpEZZdWotttoHNxRM6Au8s0
tYrKTFrHVubDLP8AHq2Oze8k/lesSFqg5S2PtCv93jUc145rhx/JT8Z784+lbT9fwyDTjJId/O/X
kHzYT4b6Sa4uxrbT3e5BlNDKlK/GT8c8uJ/AWGyMlmKUPbcW1oJFJnF/slTpDWxQieWi7fq5lqje
FUwYS8g2x+A+7LTNncBahXI31orEUkjQ4wKdVpZ0aZpc9Ub0WR0bNiYt0Ka01Xy6Fltz64hpYnIm
XIkD0ijq9lmCm1SXkD31iJczzP6in4z35x9ed2c8lh/879eQfNhPhvotpdUqyywH3WE2R4mMmv11
3MOezmLpStnLaOS2oIQIkhfLbQVpZUU/BQTYpIYImyRmv3lPxnvzj68sK6spiH879eQfNhPhvo9H
qU6RG82qUeRJU8Vk0qZ0rTIkipcpa3FO4QxqWTWWpnA2eTC5sUZTlamLop7NnWbLnuQLZignEjUu
jjP8hLoOsmswYKyp7kZzYll8rZbayvI642NOdHlh+8p+M9+cfSp/3/B4I60qiP8AOfXkHzYT4b6P
BKc9GnIKJKkMdaZO2QnEugOvLS6iWCwtAk2lFbV62LRlyRznG5crKMicVWr3SNR19NKjUcIeLGBi
LKbo+ws9iCIxNqROERijujUROLK0CRIlQJfvKfjPfnH0v/8AX4KCeeSxH+c+vIPmwnw30dFdyEhK
uIVk5RlK4pkguUXRUzx8w7QYlMFia0/IyOjwlzIWgjt+Y2CqePTMh+XOuQlJ0iYs5RKRnKJ8zpnZ
4yk3RxhYcmtEncP6FT8Z784+lSn/AJfhUvi+RP8AnPryD5sJ8N9HhKesSJWpGSjURaxwfbcSsFzu
ibSG9A9wpUmbVWPELgxm45RXWHQRGuJRR9CkerMdNxbwhx6lRM3bmOHJzcf3KW02C+9cv6FT8Z78
4+lSn40t/wCVif8AOfXkHzYT4b6KCSVBRR6c8PFzOjh0fdYWtkdWtkpajkrOsZqvsDVpizIpcmtd
8dG22PGOlak6SQs+i9xK3RVzx8WuseYRcC3mKq3pbKLEj/bWIXBpUwh/stdce3mUescXNd8vxpa9
GSTF5KF+lLEzONznj8tcS944UKWPhYKfWU/Ge/OPr2/yUU/m/ryD5sJ8N9JqnlixhxXBXyERuRNi
92x9iVmeV02vUXcrJE5IlrXGrtSMpomvKkrTix1QMS9gmVXhggj6hXTJif5IpNxo83WvMTkl6mIQ
h3YV7hAHZXMrYfKLXOEtUgZ24qJSnZdsOeV7o1Q9+Z3huhskjzf22dSU5uMnnhcwv6aTMFeNbfrK
fjPfnH1zVthLzFf5v68g+bCfDfStKVHLQGsLZdczxRlTGXR9spV3M9ofobZwJNjJz+obmRNV0QsT
Q3OztDmSxvdYY6B6dIXGjzXKFkPZcngpxTfKMcOZly+HWvkbfoJLDjn+Bp39W6wpE6tKyGvTZawt
d9q9LHWw5wdoO2XLZZjtvMvWMzCETq3rld6sqxX6pHdvXK6SyP3MAPWJEt72/tMdTNLsjekQJWJF
BoRS2PuC781Pxnvzj68vX3o5JF/5v68g+bCfDfwurwCWqwtYQocbr8gLLG+Vw8lSih0311RLXiMK
yXVxQzNYY/tzksbz29U3IMqNziqeDZCW6zVtcXtFa+kERElaapbp3h5A8EKC4e/PkxjLrdEziWpW
/YkdC19CpsU4FJb0qVYHuyYOiqbFLCktzY+Pjmja5yrElNnb3HUbVIVQkaqWqYZC0riU9ooTKycV
ttsjrKCmhSuSyyqholEuc7nlU4s8+XNypjd0q5xRvqWTaPM0yhgbJGuSU/Sn4qfjPfnH18geRRj+
b+vIPmwnw38Lq8A22cD604CUN8XWSS3/ABfS3m5rbRWlgvRI71NyBCpPpSlP6RT8Z784+vkHyKM/
zX15B82E+G/hfWtKpVRSdYS5kq75lOXpM/RJYqcYqYpTJMns7QQ0ReKoSUMwyk0kOc1WziRp3Qia
y9aqQKHxZ/pwclczNcpLPXN7x7Cn1/PdPvqfjPfnH154lvMfI1/M/Xf/AJkL8P8AwrSlRy0HLQTD
CbXJ5kSQUnJeIzHJEFcWjLg5o4jFW50vbkBhtsOiVi0mNR1M8JY7H0LeahRHgmEwxMa0R9gj9v31
Pxnvzj67m3WLXCOfzOr2DVraV3DW4zXVI11SNdUjXVI11SNdUjXVI1xYNeWDXVI11SNdUjXVI11S
NdUjXVI15UEr4UqK1WwUcONXkzrKIX4f/ZKfjPfnH16fyMd/mHo15KaIhY52RoldVGfro10a6NdG
ujXRrokq89aytZjmS+66NdGujXRro10a6Kvv6Md3Ogp/nF25tmO3/wB8L8P/ALJT8Z784+vT+RZz
yUi/e8QG+IgFz3F1J+pR0alHRqUdGpR0alHRqUdGpR0Uc49aNXYhqUdGpR0alHRqUdGpR0alHRqU
dGox0NsviaJFvyIjfkRBkhY3Y6PvbQ1MO62Abrj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG6
4+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8b
rj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj4OlDA
YU5r2pVJ91x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64
+N1x8brj43XHxuuPjdcfCc8hStgP6SXrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGj
rGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjr
GjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrG
jrGjrGjrGjrGjrGjrGi847n6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xosOO5+
saOsaOsaOsaOsaOsaOsaOsaOsaDzzqE3fq7QPyL/APEGf9/oF/8Af9lR/wDRd/KxBTYgdt8Rwb4j
g3vHhveOje0eG9o8N6x8b1j43rHxvSPjekeG9GAb0YBvJhG8mAbwYRvJiG8mIbwYhvBjG8GMbwYx
u9jG72MbvYxu9kG7mQbuZBu5kG7mQbtZBu1kG7WQbtZBu5lG7GUbuZRu5lG7GUbsZRutlG7WUbtZ
Bu5jG7mMbuYxu9iG8GMbvYxu9jG8GMbwYxvBjG8mIbyYhvBhG8mAbyYRvJhG8mEb0YBvRgG8mEby
YRvRgG9GAbyj43lHxWaMFBfPoyUO5ESFMjROovyHFb7qZEitRTIUXqKZAjFRv2NDfkbqN9xob6jY
31GxviOVG9o9Ub0YKjeTCN4sI3kxDd7EN3MYtljLS7d7GN4MQrNI9aN8xsb6jYtm0duFspZ7xuVq
G5WoGyJrvLLM9wrTZCab7O40KHcSFDuRCx3IhI7kwkdy4SO5cJHcyFDuZCx3PhQ7nQodz4WKZRhY
7pQsd04YO6cMHdeFjutCx3Xhg7rwwd14aO7MMHdiGDuxDB3Yhg7rQ8d2ocO7MRHdiIjuvER3YiA7
sRAd2YiO7EQHdqJDu1Eh3ZiI7sxEUy1Eh3didB3eiQrlyJDuzEB3ZiA7sQ8d2IgO7UNHdmGjuxDB
3Zho7swwd14YO6sOHdWGjutDR3Thg7pw0d0oWO6ULHdKGDujCx3RhY7pQwd0oYO6MKqO6ULHdCFD
uhCwbk6FXUdp1Bld+5YHxskkFpS2WQSgJlcJvpbNIKC5xBxbNoZeKTqFUG+4by0n8LFMgwyotyPC
eNuTITQW5QhdBTKUNFMqwwUytDBTK8NFMsQ0d24aO7MOF2WIaD8mws6vcKFDuFCg15HhdDk2YYmR
Z3qig71RMd6ooHPMpRyf/8QAXREAAgECAwIGCgoOBwUHBQAAAQIDBBEAEiEFExQiMUFRYQYWMlJV
cYGRodIQFSNAQpOisdHwByQwMzU2U1RidIKzweFDcnOSlKOyIDS0wvElREVQY4PiF2R1ldT/2gAI
AQMBAT8BhqNpTQ74SuFv9ebAnqz/AE7+cfRjNtH8q/1t1YzbR/Kv6OrEr7Ti5ZX9HV1YDVpg3/CH
t4/5Yz7U/Kv6Pr9evG82p+Wk9H0fXzY321vy8nnH1+tsVdTtin/7xKPKPoxLt7bC8lVL6Pox2ybX
/OpfR1dWO2bbH51L8n6MdsO2vzub0dX6OO2HbX55N6Or9HHt/tnwhUedfVx2wbZ8IVHnX1cdsO2P
CFR51+jHbDtjwjUecerjth2z4QqPOPVx2wba8I1HnX1cdsG2vCNR519XHbDtrwhUedfVx2w7a8I1
HnX1cdsG2vCNR519XHbDtnwhUecerjtg214RqPOvq47YNteEajzr6uO2DbXhGo86+rjtg214RqPO
vq47YdteEajzr6uO2HbPhGo86+rjth214QqfOv0Y7Yts+Eajzr6uO2LbXhCo/vL6uO2LbXhGo84+
jHbFtvwjUedfVx2xba8I1HnHq47Yts+Eajzr6uO2fbP53N8nq6sds22PzqX0fRjtk2v+cy+jq6sd
se1vzmT0fRjth2p+cSejq6sUu1Zn4JE0jF37pjbXx6YmqqiHlrUPm6sUW0Wn4XvWK5O5tbTxY7EY
Y9rdkw2XI6vDuc95XBi5af4SXvbeMOTpx/8ATzZC0FXUE7NQw0s82e1TUMm7iZ8wp4ozJOVtfcpx
5e4TjMMdhnYtFt72w9s6KjoXpkpWghno6yk3scqk8JWZ1aN95Ye5CzC+ZQE0x9k7sdp+xzYnDKA0
yS8LhjDU7MzWLre4ZQMpGh8dsUktctORAmYX6L4y1/eejxY/7R7043+1vyXo8WD7YnlUnx6/Xlxf
a9su64vRbTm5sZtr/kz5vFiZtsc0XmHTz/Xq58W29+R+TioTb84tub/s/Ng7D2qf+4zH+91Y9otq
/mEvp6se0O1PB8vp6vr9Tj2i2r+YTfK6se0W1fzCb5XVjtf234Pm/wAv18dr22vB8/yPXx2vba8H
zf5fr47XtteD5/kevjte214Pn+R6+O17bXg6f/L9fHa9tzwdP8j18dr22/B0/wAj18dr+2/B0/yP
Wx2vbb8HT/I9fHa7tvwfN8j1sDsd234Pn+R1fp47Xtt+Dp/kevjte254On+R6+O13bfg6f5Hr47X
dt+Dp/kevjtd234On+R6+O13bfg6f5Hr47Xdt+Dp/kevjtd234On/wAv18dru2/Bs/8Al+vjtd25
4Nn/AMv18dru3PBs/wDl+vjtd254Nn+R6+O13av5hN8rHtFtT8wl8zdWPaPan5jN8rqx7RbV/MJv
ldWPafbP5E+bxYp6Tb0NvtfUchy6jxdGDFtw8tPfxoPowItrD+itfl4vL4+nFBVdkmzJ+E0NOaaf
Lk3iU0JbKSjW4wYcqqeTmwvZn9kRe5rqseKCn9THbr9kU8tfW/FQ+pjbW3OynadNu9s1E8lMrq3H
SNBm0yg5AC2tjl11AbmBGxWUU3H5OEx35e54l+Ty4EkOaa6jLlO76zbTxeXAkNxdPm6sbxe9xnjM
qaALvFJa17De1TXtz2V49PEPg4eWbeyWdGjscvFtfqGmmI5FyNdQsmU5b68bm9ODJOfhx2/qfyxD
I+9j3sq7vOufinub8bm6MLKpaFQLMaSjDG3JUmsAqFP9Wn49xcMNAxOmGmqBUyIJhkHJofoxvJ/y
y/3T9GN5P+WX+6foxvJ/yy/3T9GN5P8All/un6MZ5fyqHqy8voxvWxvWxvWxvWxvWxvWxvWxvWxv
WxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxv36T58b5+n043z9Ppxv36T58b043zY3r
Y3rY3rY3rY3rY2q5enjB5OEJ/olxRVMFLs+aeolSGKOVGd3NgosuvSeTmBxRbc2RtFstDX09S3Ja
NjceO4FvLgqRyjDEIAzaAsqD+s3IPLgI7Vo2eqk1jR70QgXO7tfNm+9jTmLX6sWOvUxU9TLyjyez
0A6XxNXtTyrEiB2a9v2bXPkviOYzRrII9WNmPRbQ8vLbqv7HXhZUckK1yozEa8mYLf8AvMBi4xcf
W+LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62Lj
vF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V
62LjvF+V62LjvF+V62L/AKC/K9bH7C+dvWx+wvnb1sfsL529bH7C+dvWx+wvnb1sfsL529bH7C+d
vWx+wvnb1sfsL529bH7C+dvWx+wvnb1sfsL529bG1D7jELAfbC8l+8k6SenCbOptr7IqNnVUZMVS
9mlUaxgIvPzXvjsf7A9k9jrB6EZrkF5HAu9tV157XOCkjOxIsumXrw8T3S6q8QbNICLm4tlK9BGv
JilrtmwGSeCmkNc0axvUVIzSBRyLDI/GC9IBt3OJIpZZJLDJvWzLbTX4R8eowsDLxG1I6T04eKcI
xh3fWX/hfG7nKIZsl9cu7AvzXvit2c9RlaK6yLfjLo2tucWOKamkhgSJmYsL6k63OODyJqxJzajq
+t8LETe/pxwcLfLGuZhYsMoNrg2udbEgEjpAPNjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3
vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+
99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv
3vpX6cbpui3it/DG6PXjdHrxuj143R68bo9eN0evG6PXjdHrxuj143R68bo9eN0evG2FK08XL/vK
/upcbENqKa7FV3nG1/QXFLUyz545Y92qfeiBbNrzdOmvJjK5sMz8oA1POQOnADd3mNgM3L+iz/8A
Ifm6Ri7OGLvxYY5ZWZ2OVI4VzStz2yoCTlve1gL6YUMxk1YSQxU0zB2MeRKmngrGzu5Ai3FFMtRO
WsihWQvnVrCN3IyBpN4qSRalZHSfaEOz6NZFcru56iaogujExQkyh5ykTSGOPhDRRpxzOKdornRk
qZuDI3GtlyVg4JMj5ZYpw2aPdq8gUAxRyoM0UkJnQrcAwj2wIezZdHg2TtCpTphpuaWemimylVqW
W7Cmiq5WKXyutJQSV+aNjZXjlSIwrIpISc7uUI2mN3cg3sMtyzE8UjOXNhmOVYwrXHHYl13fFVpJ
Myq2fNeOBqjIWu26FU9GhXjZbzTwzLGubN7kTIEzxbyoh4NUVFPmzbieWHPbLm3UjJmtdrXte1zb
kucE21ON6MKhzIPytwv909OIwxEBvfLSSM1/hWI4zd83LZjc9eBIDp72kG6aBWt9sU81UraBVjhq
FpjvGawV3lcLGouX0HdMitIRETn0tvcxIsBuqOjr2AzWMhNJWLMBEHIjhqHfKiBnayNkawbeSRAH
4TwtKkoXvhFJDLFKy3WOVDE5Ell+47e/3WH9aT9zPjYahqSRSLgy8n7CY3drcthydXixknC5st4x
a79HRri9h1fw1HzEjynpwMxePIeM8kUKWNi0k8qRRID0ySuiKOdioxTpv5YIIigao3aQ8yPxIRCF
IBGXcy0jJbiimqKSXSnngd4XeZIpo1k90ijkj0JfdtPFwdbIWIeSomp2p4fvrzTRGOMyOuDayqGU
iRIJ0aMg3jgYinZZU4yILMqLmUSRZ1yvEWGOkcxzXHTm3ua/9bfz5unfS3++Pc65ydTLm3l/6TOu
R8/fZl4rZr3XQ6YudNTpkI10zRM7xvbkzozsVk7saDNZVtYWy/B43F5uOyO2nJxnjjdulkRjqotc
kkkkkkkk6kknUk85OGGYEcl8CnS/dk9Xmw1TkdVJ5O5vyjxfX58Duc45AAlukOwAS3QWPJ6MZVAB
AXW3Ja4BkyfvbrggqLm+mGGTKT8Pkx5CeoAsT1BRck9AAJPIMEhZHiJG8j7tOUropBNuRXDXjfuZ
bPuy27fL7wkfdxvIRcIjPbpygm3owdtRtmzQuwdonYMVKs0MPB4WKkWvFE2VNOKbOLSAMG2vC4s8
Mjgqy8Z7nj0sFExudQzUkEVMzg5zCGQtaSXO22IWN2hcku0hN14zvPUVJLd99sVlTMM1wskzstic
e3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMbTrF
q6VcqMu7qob3IN88NT0f1cbB/wB1f+1/5Exfp1HXiGrePZ7ULIru0ocztrKEGay5zrls3Je3VrpC
N/nI5I9W6DhcysjRZldHjePd3DCRGVktl17tRpyN3JBDEYRjEKaoQ5RFJAlLIpHFd6VVg3f6LU2x
URX7i1EqZs9gyho7RR3QRCOnGQ2VCsymGPeLxeERT0sZi43CIJIIshQpHZIjK9PEijMm8hp0GVFQ
M8UcwHcogDxwJKxsE3cSOwWNQEO8hSdLmKRo0RrHVpYJ6pOKRmAMFNPISwAUR2YhioP8j5GUOp/a
RlYdKsGGhHs/z9hhcebny845xqPqMbSo/wDt+l2mNv7ShpY7KdjxUFPLs6paxBWadoy8d73zqwcE
d1gHiIR3L2IHNzEG3UeQ82Orm09DmQeZyXHQ5LcuuDduL3xA6eUgYzaBW1sMy5tbe6mDTo1XyY8p
HWCVI6wwsQegggjlGDq2bnGewGirvMmfKgsig7tNFA7kAe8avWkqFHLu28duQjy4imgaKlz2tGJM
ykDKzk2zn9PLxc1r5dL20wJaSN5MyvIrsCuXkAHVydf/AFwJ6feq8cdkCkOrjQknoN+bTAlpM0jT
q12K5MnIFAy2+YDoAAGmI2oZG4gIAGofn6LXPRiTd523fJ/L2b4viJ4ULb2Iy3WygSGPKT8LuGuR
8HmHODpbQ00n6zT/ALqsxsb73KObeH5k9jn+vJiNtZWjbKqayBbgN05rcvlwhPdjksb6kaEZdGUq
yNrxXRlkjazxsrhSGGcSqeSeqjrJLALmqYuFZZDlA1+234vcBI4IlVYYUjDNdmmJsyLCpfkEUe9y
KmvECyzzBA0gLgtFTQPHDHTwx71xJHKLbyKNI0bKNBHXrtOM25MwrAZWP9LmKziRVjCRsYoo4UJE
cRgaMXIKmnp6imjOZSrE5aqZ2JJLuVVvcUSJVUIqoLBUVUUBVUAKAosqBUUWHIqqo5gBp7P8/Zlp
4XXjRRtY3F1Bsb8o68aLGmg4vIPJp9GFO7N7Zr8l9egfMSfJfBZjZ8gAWzmwHwLMfmwRmIPVl8m8
4R87395kAgggEEWIPOOjHA6S1uDQW6N0n0Yjo6fOQsEQGQ6CNeXzYNLT+4xGGItIrMLxreynL0fp
D0Y4HArshgi4qE/e15jl6P0TiKjgeNW3EV9dd2t+XxYFFTB8gp4QzC/3tObyY4NTXK7iK66H3NPo
xwWl/N4D44kPzrjglL+bU/xMfq44JS/m1P8AEx+rjglL+bU/xMfq42nDFHTru4o47zpfIire0ctr
5QL2ubeM42WBu5f6/wDBfYvbmJ6hynxYp9zDQ18XB231VGVikcZijEqbhjqul+TGu6WNo1Itxr5h
rbitdGRro1nWzd0Be40wWJD6nMyUwD9yySU2zqyhjlQRhEVt9VrtTioD7YxCcN96WHSyCwtHNPIg
tpu6izSxsvcsXkho5nlsG3tKCgRZZFMhztUtbLwmeedrX0E4jTcrzLDDCJ6eBECZI5kkOarpaapj
bjPI51LyNJrqbskSNfkTMwhQuYo4ldhnZDJmdvZ/n7MrRAEGS0h7lc3KfFfFwEW4BGnNcc38sNdr
MvNqBzdA9GDKWgeHLYuMt+Q69f8ADDA2jy6ZbZsumbiheNbl0sNeYW5veo01Gh6sc4bnUEKedQbX
APMDYXt0DFze9zc899ddT5zgEgWBIHQNBi5uGucw5DfUeI8uOk855T0+P/Z2j95X+1H+h8djVc9f
RzyyKFYTHkFuLlUfOD7B8v7PL5MUu3o5556OejePdw2idvhPbuv+mDLeCUJpvoK2nBsCL1NJNTKW
BuGVGlDFSCCARbXF0EwKLaEPUWV/dGEJqUlokfM3ur0yiVZJc8bVUciU8+8EJmmjcxuja8R5XtnJ
7qQtGgICMBEM2V7mYrKIXkcUsUsl1EUkQFt4kQzZVsjx7Toa/MYwAk/+6yEGWzFpRExMYLEsDawy
e4olvvuV/bSKpdyz2ae+zVOz1LGJlsZtZKh2hUEAgm/HkK3OZshkYxh2soZwhUOVSNC4JjiiTLGv
sfz9gaHFXQzSyiaO/FYNy4BXJHnsGUqWXmNrXBH/AFxnsthobKNOpWHzkHyDDHRDhDZlvqMwuOY6
8hwJIhLCWi3iLLA0kedo88atmdM6cbjKDpazcjGxwQ26jXPeREiDPYIJJRXVc08zBeMqSUksEEdO
rZYnhjvLJEkiVXvzsnrJKLZm9iF2eohi8QbMxPybeXHYb+B1POZWBPORkj0J5+U+f2auqglVAaev
pq5TT00U8WaankDVEzTySoroONEsI3jZjFmIXiZsxyZKcKFDIu1swIIQzTU9EdmtNkszwR1NPMJc
l5Y0mfdD3RiGtllK5r5ZzTBsufR2al4X/RtO2WGKpWnyU+4kqZYpBURQRyEpupEsuaXKFksfcTFV
U1UHYDIzpNHDLSskcsbusrRtJFE7SqMpsNUB4CLsN4yLwCqNexCtEsk3tjwYRRjdwtTBfdUeSVoI
sjLCJi0ZMFOJihDlZX2hTiqZSUUNJDs0VLQkRiF5mjzRGxQxsbccIrbhc1hdd8ReRUJEhAeO0QkY
M0NS8s0d4o4AYtxnTebzdcLXOB9+4Iasvc3eRBLwVitQqSFFkWMUfFDs0fJHvSATu1cqC5DDZ0S1
EmTPHmQ7R30lNHmjZ13ayvBHmOI827TOLPlGcXDWa3GGYKgaxvqEUHlCryezc9JxtKmqJd3PSyT7
+LiJTwq8nCGlYRgMiOM2XNccRytrjoxRlngBqoJYZbbt4nV4pbb1UmvvY45YXkp96YZN3nhmaGUB
smvKKYyWLJSUscwjG7U1aVFe00oW9snB2pEN2ZmOXRyrvh8pkd00ztUSAG4jBWhjjpYmRe4RqtS8
ppxHm40mWMylElyl5mjBCs+0JIxZc4EtY8lGFAyxQyRQsEESrJS8H0zRSxqkkuT7dWO5STJwU9y8
eTbocKGsSA2xoITKTxpJp6qHMsbqkblWmuCqg7RqZlkWP3JKF6iuZIGpySCfdaOWMWk3MNOaYSKr
shPGW5SzNT1qPEkrAZpp95Cqy2DLIrSSBapQjQUixCJFaNaPDFTwwBbGZckbXOUNuY4zKijK8KZ1
YqsD08rffs1PLK6LUZXmrGjHuUtRVvDGvEIjknreCKGBXdCGN4t4IwqCGWACCeo2eTU++OzfTYMh
/wDvKH/iUHzaY7C/wMP7d/8ARH7A5+jKSe+/Z5/Nijl2DVbPXPWtsysplq7JUUpqBtE8FqJEVWKS
MjRTxUyLcAMKl2MqCMKwKMKYhsxbeZjyZhuKVwSnNaR5VGmliObEYDDjNbjtz8o0+vlOHVAyZWve
9/JY+TKLydeXJ8LC9045hbyaX+ULSfo5938DEmhS2OYf7dRDPLNTmKSREXPvAjsoa+W2YAgG2tr4
vYSC2ZkS4HOWFivjzMAh6QxHPhrZiF7nPU2/qpWVEcethyxIh0voRz6ABT3TZRnhF+TR5o0f+6jM
3kvy4AF6TW+eLNINe6MFO7XB7yR5EH9XTCWyZiSxEjrkuQSrRSIkmbduGWGoNPniDRyNG7OrbuKc
iBVbgsc0mT7ZeCrqAvIqVFHCksaXYCCdDXT5wsvESHeNSZg8gzcG37Lla9FGIjr9sVGzdoVzQZx3
Xu1JFQ7wBRTtLLVTAxQMhdU4hRuKzVObkLQxquz9y7oWTfMzy1gSKNoiypmZ7I2W94Se5k3rtxc0
loKYlpY0Vki3j1KlEpZG3JkIZtyl8sZAs7KL7qHaU7LmAutDs56tYzIeKmaoU03CCDFKkbzxKFKj
DZQCVOYCaNF4rJvIOEPE1QRZ5ImqYU4RFA0TNRcWKsfLKswF7C+p57Cwv1C5t4rnxn3t2d/gBv16
g/4hcdhH4EH9u/8Aoj9jk16MPV3sgJW2lxzXOvnthoEjekZWzGRJyer72RfxknzcmmqAZP23/wCX
Bveb/wBOhrZo/wBKeGLNDH5W1tzlRbUXxJxZUC8j0scsn6E7z1G8i/YyrpzXxyg9WByt/tOSpRuY
XzDp5MCxXPmy35LG2JAFNPlYktmzdeUxspPTrrr0Y/pAOb+d/n+c4kVd1MSbFWiy+W9/mHnxa6rf
i+6xRFhpkhlinMsg/qlENx5cHdqtVYm6VssUGgsYF2rRUudhmGeRqaqmkjRSt9w8jPu4Sjye5xyu
bEx0/CAiHPm93jp93nsFRkaVZXaXdDgqTVIGSKQKdJJo/wAlJk8YKJIpNrqCVcZkDMY2vFLknSWK
P312d/gA/r1B/wAQuOwb8BR/2z/6I8eL6/P8xxtDaW16fadBSUuyWqqKoNOKusB4lMJJ2jnOYul9
xCBMAYjnBtxeTDU0QZeKnHBbXQkIKdpnUC90plqI2mDFJrPE0EM6TI53b5oEy+6OYliW4zKKmrqa
JNb5QGlop2YBswijzsuoGCQuS2odo8uQX4s9IlbDMw5UilgdbO4W0topAkhRW+vnFj6CR4jbHXzm
5PWSbk+Ukk9Z+4SyQxLmnkjjS9ryuqLe17XcgXsCbdAOAqtEGUgguiqAAVyuNWFrmwFuRCnfvGLE
rTu1QKUAGYTLAq82Zq2bZzFW7lUjrKaohckqfcS6B43heWL3Z4Vj4zz8F3fMbVkBqadjfuVanMEr
c8PC6VJQkrtGmXeGQRgyoqQShgp48cmz6XaGfIeNotSVRbFysTO4hZliNwzPGWVgsMErNfPEUq4U
mgUMuZWMsM0L5RcKs8e8K3bLuyql2GVFIDnlye4V1XPmC3J4NBs+skmK3zGPLBv3kjV4IGmmgiPE
388MN7Biu9qFgL5cwBEeeOQrnBKSoFu4lWNDmhhlayCajpq217iOKqrItnw5mAsC9XIY1vbixSys
FRb4BvfQgq7oysLMrxu0bq68qOrqVdGs6MCkiq4ZR757O/wAf16g/wCIXHYH+Al/tfnC+wUUlSVU
lDmQkAlSVKkqfgnKzLcfBJHITi55bm4CAHnAjk3sY8SS+6p3snHFm1xGhzQlTYmenjhFiw38k+SA
ZArf01Q1uKbGWRvhPcZStPJ3QqZqnISc2WemgollDNcgSCGpihAQsUFPNA+73GTDgoHJ5IhM8lvg
RRSCJJrcskdQ284O0QkzCCUuI/c94ylWdW4pil3MmawVH3ssHHc8VUFRBNTmQndrURPTlxMpTGVt
BlbMybxUyneFeFJRC0f3zM1ZIlKseXePUHcqpkDKBru7EHevu4tRaR9zwhAhvx97T+7QFbioiIeA
yKQcXGZl51WBjy2tU0sFZFa9uWCpiJ6Gup1U+x/P2Z0pNOEspObNHn42R7FQyXvlbKzLdbHKSOQn
CRBFRI2JDKQmvJZNLdGg0wN4qpIGYGOpSVmBIYywxIYnJ5S8ehRjqhUFbaYtbdullWHO0eXiiPem
MyFLWybwxRF7WzmKMtfItiuTKT/SkeU2A16dBbxDHGuCoJkbJCMvdlWbIEvccQb1r3OVVZydL4uB
G7nSNIC7kiwWnhd6EMwPJFnaWkhuMsp30MOe0ijJJxCt2Ekwa6c1UVqKqPMNGMzJBUzJIoYZlKmQ
TSIjqwyCRGG7jizq69wkXCRChRuS0lZTrHCqEmSojiCAu0GYgRs0ZsrpLLC6C10mjCPKrqO5Kb1M
5awEjZCd5dffXZ7+AD+v0H78Y7BPwGP7b+C+xHKGZx5vYjeVXQxFg6ujx5dTvEYMhA74MAV6wMWU
JHyCOMq8PeR79IYEMfMoljo4oo8tgyQ5E0zAnMxkQ3LTOkEg+G8kKwskR+HvI444LJ3SxKi23emH
ckb+W0iGWNWZuMkj1VY9esRK90tTWM9Q0YOWWRQ7A7pMimVHDZ33gkyqWPGDJVrtaOG5sXMFRlqo
hJnkW7SlmaaV5MpVlQAqyFIlA0J4Putmxx6ffI4zHFTRrxo95lye6Nc6u5fu3ldIyw42eSKFIEjF
rgtHDAkeRdRuyCMyti4017oMV/SCNkcjpCvxGtyNxTrj+fszxRSLeSNHI5Cyg28V+TA0RLaWta31
+vJi5sRzHUjm5LfNpi4A6ucc2CSxVr3VNR0Dm/jiBZjPEsVzLLLGsIJX74zAJ3fFHGt3Vl6dMLaS
MRqGZGplAFmvwYstdECTxgqsUr6bMQYt6KyDKJ9692bKBxtIlVbAq3CM24OXuWeS7cHkIL/kWxEj
Se4R8bhLQU+Vm4ruXSCnBZzlD7+mXduWDCqgMwbhCM4vvwsuriaQ14NiM8kq7tqi2nGbhLBmIuJK
mUm0tRIXBB5DflGnSDYjyEWPQffPZ7+AD+v0H78Y7AfwGP7b+C4OuODOJlcOQoNyASAfGOfy+xpZ
1YBlkjkikU3s8U0bRSoSpDAPG7LdWVxe6srAEON4XZzd5Fo1eTTOeAokUOUge53ijSKTd5A8e9Sw
FTVb93MgcOAwked2H6zUbOqZUBFmC59l0irxsyxqyhuNcHjAhjctwhncWV2kqBxpcygZJEYtJCUC
rG7sQtsoWVzIEXuQslS7DlDLO+yZo4x8JVhn2TBMWJaSVrKziMSJNIxk4SToaw1bVGX4bVrSmY63
sMs8iIn3pfc5chqYYZ0d2kQRtqqtIwFvgyT0lQY+tBNQUTrf3T7XVS5WScStx2VzoVEo00zmVxIz
Sc7kMCUubRmSZkAeonaT+fsG9tOXFZSiqRQKqWmtbMYZWjv48jD04iLJEIpRyABJG1ZyOQ5jqT09
Ps8ni6ObzYWUrJDIjZXgmhnjI5ngkSVB/VJQK4+EhZTocRqsUaRKPc0jEeU34xBzCV20cy3CG+bK
2QZla752ZmRo2N1cNm0F8z0dfRSSDTR3i2lVE24qyMpjVFQLhJ5I3SRSA8U6Txm18pSVZRHbkMd4
41415MsY4+YuzDRIo+VYaWno1ve+4pa+LaUK5hZlK1UQZmQozqxVy2SHdKuW9udna2gAzuz5UVQF
SNc2WONAqRxhY0VUUAe+Oz38AH9foP34x2A/gMf238F+6fz9llBBuMSEkR31sRbqsPr5MDQ4kbNG
wAsSLXGh5ujkxcCNVIFzpiw6Pf3ZvTzVOwJVgGZkqqGRv6gqY1J87DHYD+AE/WJPQkVvN93KpzuR
1XwSpjCjXk43P474bWNVHKBYtzk9N+XGlotO5Az8nG+ny4lOY6HKANBbk+2Ea/kQGHps18MyF2ZV
yDfGWMd2q5k2JGQyXUSRqtFtUrAWERfaAl4sl3WMosU5dN4/uO6jzkZ09tqeaaEShVMN9ntVQ7+z
TxRWCSTzxwllNkjVrSMslK7yFQokWKmroZl3K8RC71MJEiESEQlro5GJMrHQMFKNGSWvJb2t2NRq
6tbiSLNs6pqCyWzmoGfNx1KTLDWtOi8SMwtDbi3aLaktS2UcsebZxhoRLYSZ0NRk3nGaNN2kMfwY
6ampyE4gtGFMrgcYl2MMUBJbLLTy1JMcUrkuxUyAgFY+E1kjKuXOaeeFUpKdWdZEU0PHjWTdtwh2
SvmBmjNPJGGCIHILhFDFc1iwAzEZ2Z7E8mZmbpYnX3vsOkhrqxqScK0c0EgIYAjiMkl7HnGTTH2P
/wAX0/WZP3cP3efZ+0JKrfRVCrDmvkv8HTlGEGTgmbKTDUtJMABaSPd/e2typmNwLee2iAqcr68d
9eozSW16ky4PJHyDMouOvInzPm8lsOBna3JmNvFyD0ae/wDYsiRVUpc5b0lSqnobJm+ZTj7H/wCL
6frMn7uH7vtHb9FS7YpNiy7W2fQ1NWN7HT1QqGqKhRyrA0PES/wd6yg68uFSLne2qi19Cu4Y83WA
fHbHRrfRdTqTxRqcMB7n6fQD6APNg9zIb6721+e2FTiyvK+RYxnd8mYRrPtyDZ0LBY7FxFRz8J4O
vu1QViRHDS3wONubjdmV7SISJODq9NvFXeAqk7xSlc8jcGp5VZ4llinhZWUkg3FjmcWFyNHYCzMq
F1sOK5jjMgs+6jzZF99tUcGSSTpRk8/8hbxY+x5+LqfrMn7uH7u8MK1KVAijE9su+yLvMptxc9s1
uq+Aq6afW1v4kYREzd1bq6OTCavKraKrWVuqw5MJa0gvmF7i/k1wzZUzkhzwOerJVrqogqWpzEzG
xMwVGlkjjSR1zU8KLLNVQI3vteT2Oy2c0+xJ3BKkzUa3BseNVRX1HVceLH2OvxdX9ak/dQfd7A8o
BwFllkWOG5PIRh4HSQq4yuO69H8sciSSfAjfdNrpmyg+fXn/AIjGXJI0POpAPoOGiyLHqoLyxJZi
FVUli2kyOXOl3l2bJCic5bO7xqF3gN4nmswSNEdyylSN7VCjgTKeOJJZmisrquSOop5pCsTs8bjI
K0cslHLJAYx/SzwsVmjjPwsjJJFnUMpqFWIaPvAdHddLKUy68bLJDFKN4o0jb3TRQzho8kqtlkAH
vrs8/AB/XqD/AIhcfY6/F1f1qT91B93MgBtikkqKZuERGLWxGZRcadY6sVFRNVytNJZWJGcpoCb5
Ob+r/HrwLHKBcpPke3MSxyg26eLy8uArNLKdcyWJJ5e5B8ePdHaQZXzwNFEq3UtI1VRisRYCGIJk
pZncoSjZBPmWyvinQTohhK7ueG6lQ2V4dyqAWRWJQwBYwMpAiAU2QaE6Ry2uKimpq1nUq4WOpmko
oTLIrFS3CKfgwKNIpYw7t3jdWxzk87Esx52ZjdmJ5yTqSdSfuXdaHTx+8fsgfi+f/wAhQfvxj7G5
v2MxMeVqqpv+ywjHyUHl+7lRvF0GvV4sFcp5Bbo5hoObowQW5Ccp+D8HlvycnLr49cAABR3gAX9E
A3AHRY6i3IcAkXsSL8tjy2FtenQW8WLm7HnYxM2g1MMApoz5Kcbg99CWja6O4I0VEGix3yi55xax
PKy25FYlQeMADrhiWtc8ipH44o5Zp0iI5Ci1EzVA0zCYKwYWIPvm2XTMW6Sfm8g9js/YLsKMnwns
/wAvupx9jX8V4P1qs/en7upjzcY6jmvhjc8tx/tHQsp0ZHeNweVZI2KSIw5VdHVkdTqrAqQCD/sW
Nma2i5cx5lzukSZjzZpZEjW/K7og4zAH/azYGovzexfqONej5vuYBAGbU8/sdn4/7A3nNDtCglPi
E2T/AJ8fY0/Fan/Wqz98fu5iuxbTU3whEYGZQfHr9OFYe6HKCH7nQcXxdHkwoIAB1t04vzeTy5hJ
/pUjxE82Ba4bKpG/3+U5shG5EVgocbtmUWkeLJnUJxRKHmkzazE3O8MjIQQrwyy0fBHnjKgIk7sX
qpWjjjR6p2kEaWQIz3R8vFklrKmqZlsgiNRtCl2hmhBEgMkJgkgg3gZEjnl3izJJJE0TiNoyY43W
KczRwkHcIOFLUpCqFjaGIokUa5iVhXd3ys4aIbqNY8zvll3mdmu73csZHPPUrfNFOMqwyl3WHKwj
VzmULlQWTd8UWRl3u05mR0vZo5Za+BqhLjfe11Lcgohjd8yuth7okaseUgpX0deSp5hJJRjeKb5p
JZZs1zbEx32/+DvpNoS2Hco1cKLIMncslDwO1HFYRiN91OsyGcVHvbs8XPsBxzcKpr+Rm/jj7Gf4
rU/63V/vveAYc4uMwNiAdNy8dv77BvGL8tsIwUMCL8VQvjAAJt/W4vlz8oxayLfl5/ovz25L8+B9
fNb5tMBovcbxlhGzlxnIzLJU7DaRE5Smel2bWw5r3ieuLxZNbI9oRFJaQrVU9Rdl4pMOzayjmOUM
hU1VRVPVBVbLR70ww5kp4cwB9w1JywZJcxBzSjdqJLqiBmZU90bLGhYBo4IpHqZKj3ypuX6mt8hf
Y7L4t9sjL0VVO3pYfxx9jP8AFWD9bq/333eqpqyWZXiq90gPcB2UW/SAIwHRIlDuC6qMzDnPT5cC
SAvHqNYiTz3PffXmwk0JRbtf/rgyw5BxhgGIrGy8a6VWbMSAZeDD2v1QG1PwjecOIBntwcwX+2bj
Ndb6jg9PmNgvu+VhOMoZ+cI5YPkzSNFGmSETz++gqrfLrc3Pj9jsgXNs4j/14T5mx9jH8VKf9brP
3x+7Sdw5B1xFJAVfeG789+W+BLT5e6HIejvU+vpxvafMdRxSEU6fe5Sd+f8A2Ba3e3xvKfmIAHJa
3JzHy6E+PXCzwtIUYgIDofNgmjs33t23hsMqByiT7JAVWcbveTxVVeyySNukFIRIUJaWLPR7uqGW
AskNQsMm7tnkSZo4p0jbjDeoFmERSZgr5ChILrM1IkuSMRPHvJFMmSM8QVVZHEwVRrvKSKlqXYlN
08+5yyOzcGJowJTliui1bLGBExd4aSSaCASKhX3aZY4+EhTEd7u1TeRm/wBpbx09xIRnVWyxqJVi
kqYt+Cy2QT7qOojhN3SJt0WkaaKYD2vd11iVWqNlREiNQEgmoaQ7QqbPdzuavfruhmZXmvpT07Za
KRWqKfLGkZeCOVwmUlGkhm3kEjqFBaN0U5QCApiZmEpeGAaj3v2QOsezmLmw30I16S2mPsYfipT/
AK5V/v8A7ty44NT6+4Q68vuSa+Pi644LTfm8HxMfq4Slpif93g+GPvUfw7Zx3Pw/hd9z4ekpHGXc
wx2kVbrFGDbTnCjS2lubE1HSJIVWGFgEqNd1HrlsQe5N7X5fNh6OljsBSQsDDTFCIY2vLJR085Ep
CWjR5JZUWU3UClnVDUVkclHG1HSZKgrT0x3NNtGVXEETRmSjpI54Ve2UgVc8yUsKgmRpIp43WGdR
DiWjo1E2Wmp7o1Jk9xjK5Z6h0YO+RFEpgTerEDmVTFNHwulqIpsT0dGgZo6aAqODrmMERSIvFWST
TSEBWMcbQU0RUxxRI1Qn25I7pFh9n0YkdVio8q1u16cM8cSgQ0W09n0FLM7BCBGYq5qqrntljp6W
eeOMqhjwlJROIDwSNeEUCyqJKdAY61n2leOYJFIyRU0NNRy1YVXeFZu6zVFKpFPBG77iGMN7VyVM
O6jj3klT7S0ddDF7lclZ6+d6aONC2+3TQwTyzxTmMxrmiEboyS7tc+YBEeWbaUQ17logNlzs8wIj
C1FG8ZmSYsotZTxuNCk1gpzXfakOy90F0Mjo8hqpN1nVaTdTAsKiIEcqK3K++HFYMFanmSOQFhxJ
EYSxmKeB5YJJEqo1cmmYs0dkZwb5ZMmlzn9yqphkVQZbvwUQRLu7zVlVRUy2M5aPQsAAzXo+EZAV
Mgl4dtCkeLibyMtFFRpOVjeTeZmjgeTNC7pEXyhZI2ZxFkuciO09fSUMeU3e8EZqw9ROL5FgqCkb
5RcENE0y9yI96Fk4jqjRRTRb9QW3JdXIbWQKxpwpkE9450WJ57NmRKjbiJaxbc7IWeWO5uqtNWRx
olOq23z7+RQsUTWF7a8vPbUX8dhfzDxfd/shSNF2NzOhswq6Sx/93H2L/wAVKf8AXKv997xXlwwH
OL638vTjdk2PSD6eXz8+IacyVNLSk5DUyQKDYNkgmlenSe2YApvYZ4hHmEuaK7IkTxytRR8LkoI7
7vhtPQzs3dLCa2tqaMIDxVmCNApEisqyNLuhlZLmGTeorEZWMcEhW97CppoauIhrDMHp6iKQaKwD
hZEjlDxr77+yKrP2MVAUXPCaQ+QS4+xf+KdP+t1n733nmPSfPgaHMNDnElxy7xVKLJfv1QlQ3dBS
QDY4GmS2m7y7u2mTJnyZO9y7yTLa1t49u6a9gOQW1J8pNyfGSST0nX352RRJNsySNxdWkiv/AHsf
Yv8AxVh/Wqv983/mW3fwe/8AaRf6sfYvA7WiLaB3IHQS2p8v/mW3/wAHv/aRf6sdj22ts9j9AdmU
ez9ny0ZJYSmqu2vXmv8ANjt37I/BWzvj/F147d+yPwTs7489XXjty7JPBVB8eerrx249kngqg+OP
V147ceyPwTs/489XXjtx7I/BOz/j/F9fqcdtfZH4K2f8eerHbX2R+Ctn/Hnqx219kfgqg+PPVjtq
7I/BOzvjz1deO2Xsl8FbP+P8XXjtl7JfBWz/AI89XXjtk7JPBWz/AI89XXjtk7JPBWz/AI89XXj2
+7JPBWz/AI89XXj297IPBdB/iD1dePb7sk8FbP8Ajz1dePb7sk8FbP8Ajz1dePb7sk8FbP8Ajz1d
ePbzb3gug/xB+nHt7t/wXQf4g9XXjti274MoPjz1deO2Lbvgyg/xB6uvHbJ2SeCtn/Hnq68dsvZJ
4J2f8eerrx219kfgnZ3x/i6+rHbX2R+Cdn/HHqx219kfgrZ/x56sdtfZH4KoPjz1Y7a+yPwVQfHn
qx219kfgqg+PPVjtr7I/BVB8eerHbX2R+Ctn/Hnq68dtfZH4K2f8eerrxD2RbdP/AIXs/wCPP047
YtveDKD/ABB6uvEvZRt4f+GbP/xP/wAsdt/ZH4J2b/iR1fpY7deyTwVsz/FDq/Tx279lfgnZv+JX
q/Tx279kngnZ/wDif/liHsx7Ij/4Ts/48/Tjtp294MoP8QerHbRt3wXQfHnq68dsW3fBlB8eerEv
ZTt2Dl2XQfHn6cduXZT4A2Z/+6of/wCnGzNt9kVahkl2NTRpe2aGuhnXMLXGaOVluL8l8cN2x4NX
45PWxV+2tfFweShWJWZTvN6py2N7kXJI8WuP/8QAWxEAAgECAgQGCwkKCwYHAQAAAQIDBBEAEgUT
ITEGFCJBUWEVFiMyUlNVcZGS0hBAQlSBobLR0yQwMzVic3SUo/AHNkOCk6Kxs7TB4SA0Y3KDwiVE
RVCE4vGV/9oACAECAQE/AafQeiqzSNNo29NSTMpYiYgGQ2uFu2wZjsvuGJdHU0E5gmo4lsd9ub04
y6I+LxfP9eIodFNvgjPp6uvGXQ/xaL5/KPY/p8Pb58cX0d8Vi9B6uvGr0NqNfxaK3y/XiOm0Oe5t
TxF+nbf+3EUWhZd1LF6D9eNH0GgqmbKaOEjo5VubrxFwZ0Cd+igfW6vysdq/B7yQP6/V+VjtX4Pe
SB/X6vysdq/B7yQP6/V+VjtX4PeSB/X6vysdq+gPJVN6re1jtX0B5KpfVb2sdq+gPJVN6re1jtY0
B5KpfVb2sdrGgPJVL6re1jtY0B5KpfVb2sdrGgPJVL6re1jtY0B5KpfVb2sdrGgPJdL6re1jtY0B
5KpfVb2sdrGgPJdL6re1jtX0B5LpvQ3tY7V9AeS6b1W9rHavoDyXTeg+1jtY0D5KpflDe1jtX0D5
LpfVb2sdq+gPJdN6re1jtY0B5Kp/Qfax2saA8l03oPtY7WNAeS6X0N7WO1nQHkul9D+1jtZ0B5Lp
fVf2sdrOgPJdL6re1jtY0D5MpvQ3tY7WNA+SR/W9rHa1oHyV9Pq/Kx2raF+Jw+g/XjtY0N8Uh/rd
X5WO1zRHxWL5+rrxV6Hp043KsKBE71RfZu3bcQ0EE26ikHp+vFRo1oeK6qFXz99mBN/Pt2/NjTUJ
otDJX6rVyNKFIVWVxsl+A+6+QGxN92O2CfjMMVp2zyxplzRxhs7qLax2yx3vbO3JTvjsxpnSfEOL
8WlkmEryqzpNFLlZCO5lAcy26ebvXJbHA6rGltKR09UjvE0UxKyCw2QuRtBvcGxHWMaSWgNUrzyh
JQAQ2az26jfNg1OiWg1RqLv4Ze7c3wib4/8ABvHJ6wwDofxy+sOrGs0L4xPSPD1n95y/+flb9uNf
oXnmX1h1deLcH8mp4wtt984t9WIDoOHadIwH5V6sBuC43VKDzOB/YcUNZwdpz/vKDrzr1deIeEmh
Bv0nEP546uvHbVoPynD6w+vHbVoPynD6w+vHbVoPynD6w+vHbVoPynD6w+vHbVwf8qU/7T2MdtPB
/wAqU37T2MdtPB/ypT/LrPYx20cH/KtP+09jHbRwf8qU37T7PHbRwf8AKtP+09jHbRwe8qU/7T2M
dtHB7ypT/tPYx20cH/KtP+09jHbRwf8AKlP/AF/Yx20cH/KlP+09jHbRwf8AKlP+09jHbRwf8qU/
7T2MdtPB/wAqU/7T2MdtPB/ypT/tPYx20cH/ACpT+iT7PHbRwf8AKkH7T2MdtHB/ynT/ALT2MdtG
gPKlN6JPYx2z8H/KlN6H9jHbPwf8qU/ok9jHbPwf8qU/ok9jHbPoDyrT/tPYx2z8H/KtP6JPYx2y
aE8qx+uPrx2yaE8qReuPrx2xaC8pQ+lcdsmiPj8HpXHZ7RPlCD0p1YnruD81/updu8awWPz7cCo0
EN1XbzS//bGv0Cf/ADW7d3Td8+KpeD1bFqaqt18WYNkepltcC19luZiPlw3B7gM20pTnzzzH/PHa
7wF5oqb+ml6uvGidHcHKOpzaLEXGCjAZZHkIW3KIzEhdmzN0G1+VY6WplnrUZnKrHEmsA5wzsF9J
uMR0Q1YzxMH4jS37ovJquNLr077blgu+bvT3oJOzBo6ex5D32/DH14NLFb8HJ64+vC0sWUjVPexH
fDfzbb7McRpxAtkYyfCGcbN19t9uOJx79VJ663xxKA7Gibbv2r9fy4bR9MFYqshIBsM288w344sp
EY1Mu8ZuVbZs9OBQ0u7VPt5/RvI8/VjsVSeA3rf647FUngN63+uOxdJ4Let/rjsXSeC3rf647HUw
2gPs29//AK44lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144lF14
4lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144hD0fMOr6scQh6PmHV9WOIQ9Hz
Dq+rHEYf3AxxGH9wOr6scSj6T+9vqxxKLrxxKL9x5vqxxKLrxxKLrxxKLrxo6BYZ3Zb31Di/8+HG
kY3mrngjDmSWCAIiLfMRNIT8E2sNu9cVOhq+lQvUw1EKW750sDsG7Zyvkvi8S2+6N+7rt/N/twBe
1mO0Ejveb5Nny4l4SaDirOx8mlIlrCcups5a/nWIr/WwDsVhKSDtXfyv6uA7NuJ+b6sNIU75iL3t
u/yHN+98CQnaHta12NrDrItc/Jij0Maiimrpa/LDDqwxVPhSk5ABa/wTcndb019K1HLqUrtZsR7a
t1ujjMDtRbX3bbHqwdn8qdvn9nGQ7GMuVS6pckDlOeSNu399uKrRtTRZeM5ow7xxqQUkGeSJ50W8
ecAtFFI4DW2L5hjVf8ZvR5vycar/AIzegdXStvTjI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fR
D9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3
j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9
ljI3j5fRD9ljI3j5fRD9ljI3jpfVh+xxkbx0vqxfY4yN46X1YvscZG8dL6sX2OMjeOl9WL7HGRvH
S+rF9jjI3jpfVi+xxkbx0vqxfY4yN46X1YvscZG8dL6sX2OMjeOl9WL7HGRvHS+rF9jjI3jpfVi+
xxo9SJ2u7v3BtjBB/KQ+CinFdpGfRumYqiF1QrTxHldUsvUflxpbhlXaUCx1TK0SZsgUCwzAA/8A
6b7NgthzTM6vcDfs5he3NjjcAACWtlZWPRe1saQ/g7k0hpuXSsFXqnNRFMpLEMFUksFPMD8Ic+zA
njjSNGaJ1SnWIZANkoXLm2fCJIN9u7Gj1FHAUmqZJZWkdyZHLkKTdRcm9ugbhiSSF7cvd1+bEcsU
fOHUnaDtHoxorhdT6MhnpZYmlp6gwkooBUNCSVzKysp77ZdTsv03xpPTcGkqqaoXNZ42QB/gZlVU
ynqy7OcbhsxQRtRwZJ6iSolMryXlcuVRjdFu19nQOjZhpYZgBJaykMoPhDcfOOY4euLlNdWTSKpB
CSSSyLmVGjRsoJXNGkkiIWByrI4W2Y447B4Y9WT2ccdg8MerJ7OOOweGPVk9nHHYPDHqyezjjsHh
j1ZPZxx2Dwx6sns447B4Y9WT2ccdg8MerJ7OOOweGPVk9nHHYPDHqyezjjsHhj1ZPZxx2Dwx6sns
447B4Y9WT2ccdg8MerJ7OOOweGPVk9nHHYPDHqyezjjsHhj1ZPZxx2Dwx6sns447B4Y9WT2ccdg8
MerJ7OOOweGPVk9nHHYPDHqyezjjsHhj1ZPZwKuBv5T6S/SAxxmHxnz44zD4z58cZh8Z8+OMw+M+
fHGYfGfPjjMPjPnxxmHxnz44zD4z58cZh8Z8+OMw+M+fHGYfGfPjjMPjPnxouRJJpMjZrQm/9JFb
HCVUbSMAe1jCgJPMDKwOOEmhdGaH4rJo6tFXxmOJnjExfVho1Zy8WULEVe6jKWzKL8ndgFSbWXae
gYyBQbAC+/Zb/wDcBXYqqKXYkKqra/KIGwMQLc56huOwYCojFAserMNXOGhi1mskpa2PR8caQxpr
ZXqquQQ02RHd3eI5NXKZEtuZtWG1VE8rHIyLxnRj6TdklXMJqenjgqU1y2MrRDJFnmSMnYGJQDIs
rMMi3GqpamuUADvuMUNHNWUzrmilg1Z1gaaJHcaoyh8i6kkSGykKypSM67ASWSSupKdgASZpiEzR
wVUkKJIXWOwjYyiGQNlDROKmgpZllQXYPBLpGlzLbuivrYNbB3XCFnjYgXJno4YIwE7s9XUVtHGO
VlETiroZIhrLIUdJjKsZOFJleELZuMT09MkpUZdZPDFOmckZkRFnp1dmAXPOoTOBIUVtYkclrZ44
3t0Z0Vrbh077C+AOgbcFJbbVsOkDEbZlc+LF2wRly/l7vlwUt72itKtQyj/d6mGkZbEvJJNSyVma
JVDF444YZWmfZq9XIzDVo7rFabLq7EuYgi3BLa2urNGre19XatompyZTGDLPTRJnkkKIg1ql47Mq
xQzMR8GOpVJKct4JmikjmiRrO8LpMqmJg5+8cHv97mHNxVjbmvroMcJT92x3+Ljf/wA7YkfONp22
AvtvYW2ebZhqikirOIa77qnUV0K5v5FbAgdV942jfsvvuenBF1a4zKiPK2y4VIVMzyHoWNEaRm+C
FLc2JmeJXmdZDkLB/DFpM8t8xB5E0cmsG8VNPPFY1NPJGjgRF0LLlV2RmvlivHFNFIczhV1cMVJU
QSzfgYhTSxNIBEQArLlksVOpy5XBGQaSo455ojG+zWNBUqtTlDZXbKXuQTc77nZa383Jl9XVRW6N
Wlu8Ww2BFGwR2yAbAmVkdcg+DZ4o3FrWaNGG1VtYcrYOVmDdJV0CMhO/VlRbV95ynOW8jlrnNmuc
2YNm+FmCNGGvvzCNmQHeEZl3EjB2WA3ZV+iMA2IPRiSd8jd11ezvyuYDrynf0b8UXB2rn0cdKVeW
ipZ2aKJ0YSLVsuQ5bX7kWDZhcXNj0HEltYY1bNqzfbc5Qu3pNtmLOouzsRYjbfbbuh5/B2fJgKVO
0nbu382z+0j3LgbSVUDaWdlRVHOWdiFVRvLMQoG0kDGVsufKchOUMQQC1rsm3+Ui2CePv4GKpMsb
MoPvCJNbLHEDYySIgPRnYLf5L4GgZVyZZ41MaTRoVV1ZUqJzUTqGFiBNKzmTby1eSNrxyOhTQUsb
B0miRgyuMsZUXSsm0gmwbCqV08tWqEZBUZJQuaKIomgpowVSeNQY0htlawjjio4FRb96NTQUUZy2
LrSwh75BbsFL4+P1Wx2Cl8fH6rY7BS+Pj9VsdgpfHx+q2OwUvj4/VbHYKXx8fqtjsFL4+P1Wx2Cl
8fH6rY0dQvRVRzSK+spZrZQRbJNS9PTn+bHCj/fIfzK/TfFh4IN9lvPs+a98TcH0m4Q6L0/xmYdj
NFzaMWDO2rqhKQ2vnGbLLLGdiu92HMRbFTOlEUSdrcZIRWO9S9gLHmtf5MHKzO+dWh1DNJe2ryMm
pbMG5IGxmzbMrXcENtw2aTWxtdiRKZlPPq5WeYN+Ukle7unfATs5GQEi+cwk2bjTrLEr5TrON7mM
b7qWfsg7vnUUr8bmmkvrZXJcqrkk2PFlc2LM2pp2FJGx2u+SnMjU8e3ZJNJGt5pWcowdoyOWu8bP
GQRAKRsYs9TThVUkvrUZQVN8cynmYXU8zC5W6nnGYEXHOCN491t/yL9Ee56OYbdo2m2NG6D4RaX0
VWV+ippajRmjqpKOppEmfUwyvZ78XVtWHG/OOULWI24ZRFNLHYa5SVm6UsbH59mCSdh2jbsO3eLH
0jYerZgbSAdu3n9OCNmLA7CFYHYVdVdWHOGRgVZTuKsCpGwgjGZuVcli5VndznkcprMpeVryOe6y
ElmOZnLNc7feNFsrKYnaNauzmvcEHzjmxxdkqal7numS2097lBy/8twDbdcA7xhoZSQVZhsINidx
IJG/ddQbdQ6MGCXVMuZs+a6tc5hssbHeN53dOFgqLw5HRVRWDq/OzNnzWPOSWJPOxJO04MdXG75m
Dhzdcm5QPrxFnsdYNt9nuZb82MvVjL1YmhmcLqZVhswLEx63MB8H8IlgfhW5RG4rzyC1TD+jVX97
RdZxwg/Dwfml+m/uWWwuNiiwtzDoW275MSKJIaSOuWkJlmtSicQmaQ71VM51hbZcFQd2zAVVzIoV
RdDsVSDkkEoVkZWjkjLjukMqPFKpZJUdHZTnyZG8TFPEhYsQkM4j1icpiAO5l83fmSWomkd5p5ZG
iGpeGJBy+NRTrEdrzVlJ3eN8vf54lgeVoYckT2qKiaJ5Xmla3c1i3oojXLuukejV0UEYixINGqpc
nOjDNE0eZwzHNvsTebaVVuTPBS0jplcMmQUlHBTIMt0QGQHjB12HdpCC20hIo7ksxyxRrEmZnLO7
ZUGZ2YszXZiST7rb/kX6I9wi4tjRentJaFhqKTR1RPSU1XJrqqKmkaGKea1tdMiELJINwZwThTrK
mWof8LMxLX3ud5v07em+/G4Oejb5rEYJy6s9FumxtyTc+cj+3Ge/Rt95gkEEEgjaCNhB6sccq/jV
R/TSe1jjlX8ZqP6aTq/KwKyr38Zn/ppPaxLWVQTOaia2tVfwr89vyr441ViWwqZwGUMAJpBsBVen
8sYFTWMzfdNRsPPNJs2keF1YNVVj/wAzP/TSe1jjlWN1VUjzTye1jjtZ8bqf6eX2scdrPjdT/Ty+
1jjtZ8bqf6eX2saNnmlqG1s0smWB8uskd7XkhvbMTa9he2+w6MaZN5ofzS/Sb3N2KqPRFdVaNqZ5
lNRoyRZYg2VijhSt477UPWtsIbO7xyEhthPJe6NskjBkVsokjLR50yyxhs8LxyqjqwVo2iZRkbjg
ZV3ZK2qgqJQM+sIbVRGizZiOKuYwoBk1plZqlqlrFpHopZIxcRGSiqVqU1YJLRxWNTTCHO68Xqcs
uueCCRAtkiTMw1NLDTIyHKV1LSSiVDtOserFHVsZDLy6V4gRTVdTC2fuWryqvdWkOQZUAKIkcKA5
n1FOFcU6yyzNCkrRI4iCovutv+Rfoj3GAIIOb+aSG2bdltuDRVxoFrzQ1EUEnc4JjGwjZunPaxPm
Powq52RiSHjO0DZfz9IxJ3kgta6kekYY3K7Nlybb97o24/8AKbDm3YTe/V83vcgEZSARe9iLi/Tb
p68XPTuFh5tht5rgegdGLkbif3JP9pJ85OLk7zf/AGdHfh2/Nn6aY4XUUdDpMU8TXAGc+naB1bvT
7hFwRuuCL9GzfifgzpTNx+KaZoxUZvwjbUzbt/zHFMBBNSs5YakRs8cbFM9rZhcEEX3FgQw3qVax
C96xcZnZUzBTkQyGSn4xq+SeLpPSxSQIAkxpKiSSup8rSLBAMtjmsS1VoiokZUUZ+x1RVTyHI2eN
GljqI4BEqimzU7VIijNXJBGpN42fllJLuM7jXw6qshMYkuz0usp6iGkOouIxT8cQa+TVp/JCPaxW
GnhDbI8wg0KujlyZQeLDjq8dyoJBcoN0OSRyCRa3eRg2XIpZUVXZUzOURnDMiNJM6KQsk87hpn9x
t/yL9Ee5tG6wPMTuvjt60hBwYi4OT0FJWRROStQaCrlngVueGpWYQQtstdkItzdCZ5bTx08qgbdo
NubvuY/Lg2YcrY3Rzfv1YYEjZsNth6PN0YGyNl+Ewtm577Nt+nFjqJUvkkeGVEkyqxV2jKo3K3WY
jl7WTv1BZQMFkMpYLZO7WXeQr0lJDDGLnLminhlneodXaQSyqscUlQk1H784KUUVdpbVSmypSVkv
nZYGAH9a/wAl8cO/x635hPnZvqHu8GNIaTjXSNLW0dHNoYVGkKyWnrp6eCtlfifFdHR0NWaWqkhp
aaQNWGkpzFDWySAVF54o5kG+TNfa9AQwyl9Uk04rEjLXCyNFIjDNZH1Yu2ZFXDqzIUvlcxsJWjLC
PXMhjPFCbTR0wVzPHJPrKoVcMMLxmlmlmhmdTPUNEvc+PVFTGOSmemqIYqVaSO6yLCafI9WjvE8U
TyZ0gmlUxyN3rBbM+eqym7RK33dTcVFys5jp+ICfPJkmqVkcsYXaKJJuSGqCOWvGC1OGGrvCtJU2
jYB5cqS1nE8xMjTKnGUDgaqbFlEaDlOwqp5H8Iq2j6WKHaGTuEWk45alYAw1lCBHMOM1FQC5bIxX
K02pmYbliaf7sVUFkjIS40e9K2rTkvX8b5XFo1YArMYztFRMsQc6u8YmoJacXCSsg4tLUxVNRq51
V0bi0dRLGRiXLrGyd5fkXXKcvwbrnky7Pg6x7bs7bz7mVb5sozeFYX9O/HB7hlo3g/obTWjdLcHK
XTcGkTBLxyethop9Gx0zJLJqKmXRtY8EcmrPGCs0KNEXEikZjh50qmWqpNVqZZJZ4gsoqI1FpmpQ
JEsk8UdQKczIQEqadZYGCCW6yAauvSHP3WGvWkaRs0iNJJopqTl/ybqItIcpLCMOUXKjquJGjMjZ
QdUtljyKgfl6YkneRXO2S2jZHjVJwGpwKanR6owvUyR27kJbXUU4cpmEZZNWso5WaWWnemR2MhMN
WNJNtE1G5eFf/LEnlIriouLhy2jiMwAIAtXyusY2hIoYXOeS8jbqVVClnFJqpIy/dZKrXu6Tip2F
FSmY075cmukkEzIDSwF15OrUuGKPo8a0xjl8XKrUzvFtBWegiWBqQsyzaVnqKp5VjEdViMostLJk
OSGGZmhY6zOx0xFV00ErnZKyaMHE6ieSOS9pkQyZ0qWhsopA/fxLQJK55SlYDFJXkx8ozPVAiKLW
uZNbS1BNTTU9egg98cCPx9H+iV3+HfHD78fN+jp9OT3B3wHTfFQKmN+QzkNImy5NhcbtoFjtvboA
ym+xuRriSSTqLDmUnNnt0XOMgzzEsdiRlEubFgsjZbflusaHpDWxHfugtsW4VjtLAMVVtvhoqv8A
z8Dn/wCp8mWnmlX1pY44/O9+rEZJ1t+YxAc/fQQux/pHdfktzYG9v9o7iOfGidM8HqDQmlqTSmi4
qzSNXxfsfUmnhklptWX1tpnjdkD5kzZd9um2F5TIRYI2YgdA2WB/sw4Xlcojvhs6oJ5FO/xqRoek
NghVRSrZjkc7eVcigjqAPlqS8I+q+J+THPlPeyWVvyRPKikW3Z41Rv52Dc3VSFJEZV2GZQUzSvGw
1qMoniSSNZQkgWXVJyWkTM5GslMS3RoWlgRybJ9x1tQsbuFRmn14oqR1fVZJJTIkVSqTpFKDlnWJ
iXXsgY3CjbBDUUVPTz5WvZstTUTmNxlqGpEggP3ZDIJ8geUxZbXlMSXfI5Str4Y4lktI8KS0kVNV
6+VJsgcQ5XkkQs11lOUGRFgQBHKRGWeqjbi7GRGnWEU0qXrY+7JCkqqah8utKhe5JrL5hGmtEb5m
kn07JSxyGnuGsdFNHVpTIdfEUWCpbXSZ2iGcwJJ3JnIWc3ziFpamQsAeRDMlDTcXEkyyxit15elT
W0dTTObXOUEC5sCbkDmBIC3PScov0Dd724C/j+P9Drv8O2OH34+b9Hj+nL7nOOnHFXzIbm3Pt839
mFAMkobbbLe/Ve3ow43Hn+ogj0EXGBs2bhbd5hYfMLYHfr17+u1t+DsdsIBZjb/aGx1Y96t7/LbF
r8Ye5AzxZQD8Gzltn5Ng/wCVlynvsKDrJhbvURk6zlZ1X/qkR/0wh78LZgM1gbrmI284Viqk335l
UP1ElW5YYnc6WHexyOo3Z3GQBD03DM1j4PVhACqrfMusdBm26yNcpWQ9PKZlF/BwI88yICOXLHB0
ZTLHII5GNjkgSUKJpLNbMqKuaQMqASPTKCQs5pVZnGVkaegFcbRXzSFVIjKRmQCodaYSySKxwNsc
Mm7WxCS3gnMykbbMVut0kKKsyFZ4dZTyQzSe+uAn8YI/0Ou/w7Y4ffj5vzCfTkwc1jlALWOUEkAt
zAkBiATvIViOg7sUdFo+ahqqior1p6qITcXprcqZkiDxgcj+Ue6XDDLa5G/EM0s2ZFd9YiryBY2a
auWgo4mZioDV0rDUuueBSJUqJoXgqBFmG1wdjRzy57FQ3FqGHSLrdspzmmnXV3FndZEDXXGRiJDf
ZEzo2Y2GthkWKeFC1g8sLSRF1QnMj6yLWRxzNFjr5/cuRuJ90/5L9Ee6eSt2sF67W+fESiWbUkBV
4xo2Ata/Kr6iaFGscqdxMGcKZA8l7RrdTgSDVvPchI40kkJ3rnopNJRpYXZmNJGZgUDRrcIzrIJF
RxqUlZxlEHGQw2XzUbxQTKo57SGSGJvwc3EqswO8UIdstgWYhTGahesTwVdPRPEh+E2atpl5O15Z
1igWdRJKgQqsdkys0tVCkWxXXihk4w1iVCxrqagg3vJqZAis2RXdrRtKOX3A1C82siyUb05Ba22q
FfRiFD3Rdd3dIdXNq51MOv3NqOMX3rtgNcmU7D+Fk0bXxqVzgNSsXKpJTvO6Zb2u1glhlszudFjS
sixi5zCKAhMxK5pWjQDM9gRbLtVgyRyKym6OkqLJG6NudHRlZJEvHIpDxs6MrH3zwE/jBH+h13+H
bHD/APH3/QH029xgHMZcBzExaItyjGxRoy0ZN8jGN3jJWxKOy7mIxIcsZsoIGsYLbZeVTHKbdMkZ
KSH4aEq1wcKeMRyltp1E5lGazGIRZp+VcG2qhGblC+rXwVxLIUWoka/cKSKVwBlaSkvIYiinJmjL
RiRM+UPr4p1zLLrMaptbJCCGeOppKPk3IeqrIp5kpxs5E0UcI18U2qeJp4Eyl2dUG3V5QW1sYliC
gs0iHU5dWgBZ3kFRA8cagySxypLGrRsGxzZrrlvGM+ZclpaTj6Pnvl1fEvuppb6uODusjKm3B2Z7
3GqVnlBBBiVEzymUHbHxdf8Aec9jSlkFRq2dAWR0tnGUkyjKe+VoZ5aeRXXerLLC4ynbYA8/uNv+
Rfoj3WgapACEjJ0XG4YQ5M9/5LK7HnvFdkN9+ZDcqfgkki1zjLlDJYgOhhAO7VAldXbwO7y8jve6
ybOW17Z88R5TTrGkl9pkWASiJX3lxEs04iU3yCWULbWNdXMghe5yytq05R3gCQ282ojvbwY/BGBF
yJAzhY6cSTvmvkzRjjLuFAN5GVVAsMzuEHRizmSOPbnlkQRC/fy1Ma14yt3pZo8lVIwPIDRyylS6
EqVyR7VjvDMsKMQpNLDVvRVBW10SnimiTWq7IFidJiuqjmaHIxzoVIu1NG6MCCxqKN5os6HaoFDd
maUKqU5YE5EmEYJkAluWEkUdQHJ7+OdpFje7bzIYpCF78qpky5OV764Cfxgj/Q67/Dtjh/8Aj4/m
P+8+4UK4IzC3ThhGqlZAtipBLWGw7Dc9BFxhhnDxsL61JYZRblSrFJJNOsh75zHLUvJMWJZGlu5F
xjWN+Gz7Dasz35BtNUyLUeAVFTWVMqyd6KiVpAdYFIsQVjRnikkpo6uPKcsiw09JGYqlQfwclLRy
Lq5CBPSo8mUxlpb9/qoggAcUtPEirybNDFoWLLfZGsqaulkcFYy1s9sgyu65JHdgUKzvJfao41TS
zVL5dySzUbStM4AlamBDHVRgLJnudaTmBlkbMeUNbVyl3bntJVPJlY8liwEfIKYsduzvSob8kuus
QHoLIQ6375TmGzbht/yL9Ee6sjRm6sV2i9ja/nwbtPO3wdVmZdljff1Ye65CxJzd7frsefrA9GL2
Ib4Q3HnxYKoAAGrJZAB3jEZSV6CVJBtzHBfLFKzFgurZpWUtmtksxunLuEFhl5e7LzYbNH3RrKI6
oxA3XIKiKmgp2iVRyLCnmhpZEUapiOLODJA0cZIiQ3JRIjUPmuQY9VrnqwGHLVUE9QaiIHJaecSr
aWQM94WZmGQoZJWsviBUPLyVFnSJK+cMlmRYajV5dUUXGUxDmXJTQwlrglaZo0rIomk2lUaJIpij
NcrTw6wWpYtUQRvBGwHbs2EXB8xBBHSDf3zwE/jBH+h13+HbHD/8f/8Ax/8AvOL22442DC0ZiTMw
tmyLcdd7X9BHuAlWV1OV0ZXVrKSGVgwPKDDeOcYU5MoUWVDV5F25Bx1y8oK3tJlYs0etDlX1cxLT
01JJAhMawhDl4vqDERbkvTPWSwyZSDGSk1dUTBCmpzsAI9WMmJEzxmMWUcWpaWMEGRI4aOFqeNAj
k3EkJWOou2eZUS7qRmwZfuhqlVs/GIaqK5zFJYajSE+djZRIzdkqiI8lIxEzAR31RhCjLEh5SQxr
DGrbkjBVyoIswZpFztKDrsrzU4kFJPNTuJHEsUxOaWKVJ1cgD7oWorKppyFyrmlkr6wSIAIck5WO
JMkRjXkoIx3oSljF9uVKOmSkhVeZe5INaygPOVjEzOlPTLC2/wCRfoj3Du6MVRkMQjRBZ7AyAWYb
Rtzb/lvhVIkdbk5oADfn3b+nDHWZRv1fukAo6MoZJI5ImVhcZZUaM7OkBrqeZgDzYZ3Zi2Y5jUS1
N9nJaeliopEUEECM00IiC2ugZjGVbIUsuUJlGURLBblfgIzRauEm+YoiaOpIr3zukd5Xkld5C5Mg
fOc2sSRZTsBkeR66RpmyhQJM+k68gRhIhxgjVWigETMWzXtt57DZ/wCHdiibWytek5PdA9jfLZXk
V2bMb9Cqu9mNkUICzuWkkcgXklld5ZXzSSu8jM598cBP4wR/odd/h2xw/wDx9/8AH/7/AL42/wCR
foj3DhSStrXA6ebAJJkN9oFr89r7sLYDrI24G8HoZT57G9j1HccDZtNza2/8lGT582c9JW+NrWIO
zf7+4EPDHp6MzHKppK4D/m4s9h6AccPvx835hPpv9/GcJyoJcvhrcXB5x1Y2cwtfeCNvy4Yg6vKt
snfflefGZSX2bzyer9/l/wA8bGjACi9tp2D/AF3bMX5CKUtZII5VVspdIZa55AswXNHJViWkV6jI
8sCwlIy6KNY3K4soITKKkzyiNdsrw1Wom1V2VtVKaNuL8illkiYGKCnnlVW2g5O59wq0ABLWnkp4
UglztynRauI1hge8ces4sgeJAWEkeuz6u0IkVkg3gRjTMtYyMTtkz6OleivJcozXVuQsmMmampkb
v8r68HlFc1CKcBjuqCtWGrCrNqyJNRmyKMCQa6OVhmK1cNTIW5TPqpQZEFsiKtSJqqotkL0tQlFH
FNJBAuRQRGVuM5p6KMM2aRUnhnMlVLlDwu4qeSzATRnVhqFGiiZZ43Ks7lAVUsxVTlJCk7ASiopI
Gw5URehVGwe9pppIIy0TFZGKojKSpBLAmxG3aqkHpBIxw+/HzfmE+nJ9/wBE8MeB6cDaTQGmtGVz
aZpa6aemraGkorvTlbJFUTGsimlhDHYsigX25bgYzF3djm2yyNywitlZwVusbugIXmV2A6cMFutr
Dp6/32YbKCbbBl838sv/AG8/Rjpt4TfSPv8Aqu9iPgzKf6rj/PHD78fN+YT6cn3+hm4O02iKid4j
NpuV2pqyGdEdEoNmpqqLNtinBLCRlF3GWxGQ3QEMQbHb8EWFtmX5rX68b3sbnbs3/uNoPyWuMp1g
BJkKsLJ085Gw7ev/AD6d+GABIG0X39OHsXZUUEloRCgbIJMuiZ6uoVne+rJq4Y4OMWNPCtS0jBuL
Spjk235slPctZ49bLDSZ5CUKu0K1NYJaSNY+NSxGEVIgnpKyB43AU2UkjKhucoblIrHMqPIqNc8q
MSyiJrx62XLrG+9+ff7wjh1zovQwb0bP88cPvx835hPpyff4KSonqc4kjyCJgAe+AAJN+oBSfmGE
DBrMRcGxy7t/Nhhyht/15RH9gtgcqogVicrRKW87MQT0bBY3t8nPgbh5gT5zv+fCrmYLylvVw0u1
eVaWlFRrrAkLGCyoryNHHqxNVSyQU9PM6e+wb7f32e5wZh1+mKZCARaRiDtGxDzfLjh9+Pm/MJ9O
T7+rMhJQlSRYlSVJHQbbxitqqbR9O1XUvqYYgWYg5RYbTfFFpGm0jSw1tMc9POueNukAlfSCD5jf
AXukbbNsV16hs/0woNkPjTs9OBtd4+VdNaBZWcu1OtNLPZUDHJDTVGvdu+IjKQxyubBVJLLycwen
SwZWtr6Woq2cspKlYY6adZNWZDr6eogA1sarJm/3RmBEVTEtQ7Wu8MDC63j2BpnDI6wl0vEzPnBT
IzJlSJiVJfjAOQ50D01bVUMmSTdIhkpXZHst1YXVWBA+8noNtv3/AKvc4Efj5P0St/uGxw+/Hzfm
E+nJ9/EZO3Gn9BUvCKhfRNZPNFHJyzxWRo5DGNhBKkGx6LjGgdBUmgdHx6OpZpZaakDSQ69y7LBK
bAEtzByxA6ThEezLmJ1N+fmO3+yw6LYU5jDbdq8y23C3R0Ya0SprnXLPAax3sxQLC4XNNycxkR1R
Usr8oIEa+TEueF2EgYSxVtXTsLgutVRUp0lMykNymIqJNWULSSVMkgVbyZ3MbIZIjYcWmqKRVvdS
1Nq5HEIW/IMc3GFuEGQSFwkgyHmA5lVVUcwVQFVR0KqgKoGwAADZ96ey90yF2A2BdpwDsB3dR5ur
78vfckcgd8xve55hfm9zgL+P0/Q67/Dtj+EDZwgkHRTwf1lzn52P38SWjfq/fZiP4M3w7fhPh2vu
zb7dV8bLsbC7KEY85UG4U9Kg7QDuxc7Tc3bvtvfefp+XG61tlhYdQ6B1YJJKG5vHHq0sbZEzrKMt
rWZJUSWNxy4pUSSNldVYBiGZxsLNI5sBYPNCKeV0XvUaSACFmQKTGAh5OzA2XtuOc5ebO+pUydOf
JAse/LkLAqTYr75uD3puN1+vn9zgQ2r00ZPF0VQx8xMan6Vsfwgfxhl/R6b+6X7/ACGWQGMR5V3Z
1Fi3WTiNciKt75Rv9wjNu+Dv+bF77fd6OtVYdauoZWHSrKQyncVII2H3ernN7DzAsfQoLHoAJ3DA
2sqDa0jBEUbWdzuRRvZjzKLk/wC2bDafNgEFcwPJ3X/034BB3Y68XH7g/exu2DL1e5wFGbTojP8A
KUNcv7Ev/wBuP4QP4wy/o9N/dL9/EnJCnmwVJN7nbgkLsJ2j67/2HBN0yrsO4kbCSNlz17MIpCgd
WCW1boGZWaN4xLyDKudomAzMh1kUGpU0sUucQNLU2JhkjhgBCqFWOMAW5JDMmRajRk8UNnZpGigT
R3FoNbJJIkFRKryyMXaTe7l+UnFqWnCuS5mEEM1M8VSwMbGGeKXNNqmjlMqI0TwOiSBtqsvwnhki
eQ2zuZYdKxPK5UIDI/ZNZHIC5pKGkbYY0ySNnm12VN0HIK3QCn3QW2fcVQO5VtMbtU0yRRNMrIZG
I6C17SAOxzSgyUMOjtYJOSRNDTrUNTOLLDUVUkuRgXSQSWqI5woBirUq0QbFtG9S8cTdOqWp4tE4
y6ujp6SnVLQ5njOrFKN/Flo1HWKMVY5JOZo+NcbbjLhjMdrQSwSinlpve3At9Xpq/PxSpA+UL/lc
fLj+ED+MM36PTf3S+8Ceu2MoO2w+XC/D89sAmw245WqZNmdkcZ/Ce2mRCTsuggFbo+2T8IaPNICd
sl8twlwGlrJDbKtxUDRvF0JKSKeJcQjBJQ8fWBOMBTU1BF1swCgf7vksD8GnC1G13dlRqnPLEhaW
UCV1mqZY46WKm98i1hbo/wAz7nBN8mlgemlqB8wP+WP4QP4wy/o9N/dLgffuDHCHg5orQumNHcI9
Aw6Tq6+oWfRVbDSQyVVHDAozRmcxNIiyE8tA6A84bEmraolaOKYRtIzRi5sFY5lW19mUGxHNbEZK
NMDFKwLcm5PJ5rC+7b0YCC21Jr8/KO/04KrYARzXAN9reNW3y5b/AM2+NuUDlKwZb7FJ1baVqWmt
mNzMNHGl1OdtUt50PKWBVOWzWsDxioygFm7gXGo2sEtYZkVcrMY1jmll1sz01L76ufhWHm6Pc4Nm
2k1/MzD+rjh//GGb8xTf3S/fl2sBhYKlWGpLIhUryTl5EgAcbOZ+cfCwKafWbcwGdQbFu9u9yOoB
Rt3b9vNgU1Ry9rA7DvP5N/617dPmvhaaoyglmvbaSejZf5iB5vlwaSZRcMSbbRc8xDfNYEjZc7d4
FhHWBBZ5Y+SoBzSvGryJpG8jxxnXamB4aIukQeeQTsYkk7nHKsVVrKAtJUZGzPUxmUkj/wAUhYQO
6HKCNGmWHWJJEptr1LzZI5I1rXjZ80+fi8UiRGR0JkaGmaWN3dgEKVMk1OiqJNYsbzs0UUcZq1jr
GKgTS2LxJrDrkGreopo2q9U75gBHJUniTMJk4oJZJRFVRWVa0xZi84fnBaQlGlNTNFEQG7rq41o6
WWePLEstZrnyCiqYWKVqxvypncNpZlvLJmcQmDsdDmTuYEgaVtYVUyLGVF5HjGK+KRaSqMkjyBJ5
Y4i5azxx1EAhnRGZyM8bOhZijM6y5I+Laioqve/BxS2k0A29xmPoXH8IH4/n/R6f+5XA3DzD78Kq
qAAFTOANwE0gA83K2YWrq9/Gqj+nk9rHG6vWOONVNtv8vJY8lTuzfLhqysG6pn3E210my1SkY+F4
smQeb0CpqRe1TPsdgDrpNoViqnfzrbHHq3JGTXTiRmrdYBUvlWOKVlgZe7HO4BiE8IYzGWVDKtFT
nXhK2tMsSPV1iiSbR0aqamUSMKvWCoC7Ty6VY1nclQhhniMRmjzVApa6tm2yVlWoEQLfdEqlpOIV
czPCC756VauOmhWc2R1eaGU01enFcRV1ayUuetqhNLTpUNEJ5gX1kGjHWKMlyiy62pre5Z5pzDTq
+oUJVND2Qrcq/dVaWMGjpMkdRK7u1Vo6qrJVjQut5WlpTDSQZuW0qI02blYNfWqaq9dUvxZpQTHU
yWkyT6HSIRGWWJXepjrNIGmBeMTvSnKQKWrxJUSyIgqKqZo+yIp5dbNKY0i7Iz0ms7qFUGGnjEs0
j5TCJVlqYKWJ4hKvexGS6NxbXToVYujxaHp6+qXIFMiOlTULSxU5V52kjngkCSRhmsQspOUNE7Jb
OhXkaOfSBMkikpECVFKt75pi/wAGFzh8whrJV/kKKWoiVlZXeUSUaRpJEbSxN3SrEtJOkFYipTTs
iJOFxKFR51W51dXWRIuZM+ogXRgR3JKwmzV00tTOsupipaaWUAmFwxW2S7quaqaFpCr6sJxKlqoG
s4ilHGnqEp0aWOLUa2OaojVUmQc2Yq0a3bMDypIxFFWSyCVLIUnYUeaGmIzGOrojK8WtbIiZtSCQ
HfVo+U5l1ojoTVpCeTrGp5a3LqyEIWi0mZCjUVpoRrY6Yk5Xlp6J5OcLJWaRmou876OKCONZ5Xct
3yILtKg94cBEWThBErC4NNVf3eOH/wCP5v0en/uVwNw8339cEC5/fmwg1k2/YsZJ8+/04zWjiN/w
g2enDHLDWzd8KIRB++5Uskc02pHJLZhFGsmcKYismVXMyPEJhqhVEHMaaWpjseSXWmoZ68vblMhM
NJU5kKlkyxnaJltLHq3Zb3AeVL7jmgnlppQRc2KTQyIbEq2XPG8kTJI/vvgEwXhFAT8Xqh6Y8cPf
x7J+ah/uY/eAJHuDZtGwnfbZiw2C2xe9Hg+bo+TBJbeSeQY9u3ubMHZP+RnUOV3FgGIuL45yec5w
TzkSBRICefOFUP4QVb3sMf5AAdQUBVHmAAAHMAAPfnBp2j0rG6mxEcv0ccPfx5J+bh/uY/cS23Fh
0D0YsOgejD22fv0YS23Fh0D0YsOgejFh0D0Ye2z/ANo4P/jJPzUv0ccNvx9/04/8/wD3LQBtpBPz
cv0RjSlDobTFTxms0jpCM5VXZTeDzXy9eO17QXlTSH6uPqx2vaC8qaQ/Vx1dWOwegPKlf/QDq6sd
g9A+VK/9XHV1Y7B6B8q1/wCrjq6sdg9A+Va/9WGOwmgvKld+r47CaC8qV/6v5urHYjQPlOu/Vx1Y
7B6G+Mzer5v+HjsJob4xN6PN+RjsJob4xN6D7GOwmhvjE3qn2MdhND/GJfQfZx2E0P8AGJvVPsY7
CaH+MTeqfZx2E0P8Ym9U+zjsJof4xL6p9nHYTQ/xiX1W9nHYTQ/xmb0Hq/Ix2E0P8Ym9U+xjsJof
4xN6D7OOwmhvHzeqfYx2E0N8Ym9U9X5H7/JjsHof4zN6vm/4eOwehvjM3q+b/h47CaC8qV36v5ur
HYTQXlSv/V8dhNBeVK79Xx2D0D5Vrv1YdWOwegvKtd+rDqx2D0D5Vrv1YdWOwegfKtf+rjHYPQPl
Wv8A1cfViLg7oI/+qaQ/Vx/mMdrGgvKukP1cdX5OO1nQXlXSP6t5vycdr2gPKmkv1XzfkY7XtAeV
NJfqv/0x2v8AB/ynpL9UPsY7XtBeU9Ifq/8A9cdr2gvKtf8Aq+OwmgfKlf8Aqw6urHYTQXlSu/V/
NjsJoPyrXfq3mxFoLQU3/qlf8lOOrqx2r8G/Lld//KqvsMaQ0Zwfo31aaYmZrA5ZqWSBrHnyyIps
em3T0Y4vofyn/V/0xTSaKoJOMJX6wqjDJl2tmHNs34//xAB4EAABBAEBBAIIDQwMBwoJCgcEAQID
BQYRABITFBUhByIxMjM1ldUWIzQ2QVF2kpSW0dTWECRAQmFxc3WytbbXICVFUFKBkaGms7TTJjB3
k6Sx8BcnQ0diZXK3weE3RlNVYGNmhsJEVFaChaXExtLxCFdkdIOE4v/aAAgBAQAGPwKWJMiKlHei
w+nVOPazNcmjuINJTtRN5F0UZjydU6ll24iVtU9q/wDCNwnEno//AKK+hfr21kDpI0/hPw3CWt/n
oNnxVJ8FZFI5HSR19JjATJHJ3HPYPjsbXORF6lVFXb1ylfAMa817euMn4DQeYdvXGT8BoPMO3rlI
8n0PmLb1ykeT6HzFt65CPJ9D5i29chHk+h8xbeuMjyfQ+YtvXGR5PofMW3rhK8nUPmTb1wEeTqLz
Jt64Z/JlH5l29cEnkyk8zbeuB/kyl8z7eP18mUvmjbx7/wDdNP5r28eJ5JqPNm3jyPyTU+bdvH0P
kiq837ePI/I9V8w28dx+Rqr5ht47i8jVXzHbx3F5HqvmO3juLyNV/MdvHcXkar+Y7eO4vI1X8x28
eQeSKj5lt47h8kVHzLbx5B5IqPmW3jyDyRUfMtvHkPkio+ZbePIfJFR8y28eQ+SKj5lt48h8kVHz
Lbx5D5IqPmW3jyHyRUfMtvHkPkio+ZbePIfJFR8y28eQ+SKj5lt48h8kVHzLbx5D5IqPmW3jyHyR
UfMtvHkPkio+ZbePIfJFR8y28eQ+SKj5lt48h8kVHzLbx5D5IqPmW3jyLyRUfMdvHkXkio+Y7ePI
vJFR8x28eReSKj5jt48i8kVHzHbx5F5IqPmO3jyHyTUfMdvHkPkmo+Y7ePIvJFR8x28eReSaj5jt
48i8kVHzHbx5F5IqPmO3j2LyRT/MdvHsXkmn+Y7ePYvJNP8AMdvHsXkmn+Y7ePYvJNP8x28exeSa
f5jt49i8k0/zHbx7F5Jp/mO3j2LyTT/MdvHsXkmn+Y7ePYvJNP8AMdvHsXkmn+Y7ePY/JNP8x28e
x+Saf5jt49j8k0/zDbx6zyTUebdvHzPJVR5t28ep5Kp/Nm3j/wD+6qfzXt49d5LpfNW3rg/+7aXz
Rt64X+TaXzPt64JPJ1H5m29cM3k6i8y7euKfydReZdhmG5SbFFKHfTySR1+Nx6S1ZeIQDo3fqJdG
PZfmLMioqudGNuOjRkqTevC1+C4r5g29eFr8ExX6P7Rs9GNt27o09SYp9v3f/F/YAqTL7Vjyq+uK
kageK6JIWJDPIjE6AVUYj5FRiKrlRum85y9ai2ALszKCOFhLCna3sWxIRAVAhA0yMmlZIyORip3z
VVfY2lr7O6yWoNiGGM5c0fBZnPFLlLhgmZJWVthBo6UEpisdK2ZvD3nR7j43OkiZllm6NotbOiuC
xnXfMIu4pEXSgRN1G1kO51aorpd5XatRnrrsfgWNeYduK7KrJ3bxR6ctiMKb00rIWK+cunHFHiR0
iLKQVPCPBGjpZ5Y4mOchwUs2Uwl1YfSNkwgbAhRQa5W70Z01sSNDSKPLuzoxYbKV+8FYtcxq1xvA
hnZlVqjZoo5Wo8DGmvRsjUeiPb0D2rkRe2b7C9W3rrsfgWNeYdpv8KD+DHaOB30rsce5sPQOO2aS
q3oVqSPYRcEatRY0kgjhiRY5N+dw4nX6c2aNEZ33UPqnc9pev7/XtgvJ3cgsI1VWJc4jDkDVYjp7
G2kIcTXwEbhZLYNI1LlBd6W0RnD3Y40QuER3bCzBxkbhClN7bpLe6nksSHe5ObXgd3WDXvW7VmOV
xnRHO15tsXaQwhFHtiriq8JgtdHYxy1sbrEsjrOIZZCDRM5Xh87YiSshqZRbLL7eMSSwn6FErAXp
WrJJDXklMsrYIZ8xqtV/CAPjmN4MpYNbCBrDs6WCvuzwY6+ktC7ECvhkHDrL6aYcEmYaU3pJGxug
VZ4Rgz7pevUPu7NiWjyHpGW3jpIKjla3pCUmarnvYCns6W5OKvKBHfC6aQ+vlqpkf0nyvpvIDAMB
sRDZ23nGFNhFYRXz0JQNecIUgxRzOPJIaMUPy3SAaQyapZdezSpak4fF3YgLlclxMwBeUjJQlUkI
Y235rc4bUj5cUCwTpNEh3eSTpDad4YNkUXCXUAJXAS0VoZPJboWMErCae5sqjUiUIkefiGV7hnRR
GS9HNISyXHSaGHhnF3wnOV0rRCCiaqCpsbY6sc1jD4xSpxRdyKaHtOOm90krk2w4OlIglxyw4r7W
drI39Ivs6K1taYYeV6do8RlWhRqBLB6QfV73URLtaq0Sw4tRLVREBiz49dTyS3lr0UIkD6C6sx5p
ub7YmvfYAFDwdQge5sUeVWGiOrbVtQeDYHYzWlikvGHMZI4w3JRqGaJwk40oiC2ljzHO6kp6T1Ja
h1d5aBspBcgMlAGrl5CuJinnRS2m2wHGI3R3elVnNdWu0dDI93MOLBCkk49Szlyz4x5g4lCnuBrw
uEhs8HHOCqiqwVpS6mpyR3LwRj0GRyqb0h0Y6MARUskrpuXMbFvXH1m0B3fWFpylcUqdZq7AtWRd
04OuPc/j1AzgxrSRHBvmFsLiE6eSIVeKRDTCXXV3evTXlIqi63ekbangNcOAgpFnV89zUIy83zE0
T+j3oObKB0ax28iGJNrXbD2BQDwp5k4e67gbj3f+WFSAs7iR/hU2dp1f4nufv2FOAqtn5bK07VjZ
OpbLsfap2/sLon8ie1sFDkNocFTyPn5wiuDGlsGcIUuaHdiiAOcnEnihiXQDr39PZ29e2beR4voV
tX8Qpd5xAW+nCF6te79p7Ps7VbYid1qUWO92EV3dpatV+09lXKq/dVV9nbHJCcgYAVX4nR0ZIJWD
2t7uS1rSmv4cyjruruk7q6Knajxp3GN0qIqCwmLFq8Sx+gkLlriA+PLUSWbdUHsIUkYnDIZJoxZI
04u5xXuYujpGz+m8rQIq8GHvedzX2OHp9q32NvVC/wCYg/utmxyFNZHI5sckkorZIo2SORjpJWQC
zzPiY1VfI2GCaVWIqRxSO0YseDRXt4weoGCIr780I6QC3OGklm6JOqohZzoaYZZoG1scg8jA1Ch3
UmSqE6U14zk1TXRYINU+54Lb1Qv+Yg/uti3lu3pvRAu8u61v/iTgK9xqIndVfY2iLie1ssWqo57C
JNFVNFVFDezTVOpfudW07WOhgiZYV9sJHDXWSMbat5LnrMtrLJGx2D/226MMjTmJtKjjydvJpChp
c8y70zuGTqM9zoCjYR3RQkLIVMroEZKizSa6zvX7ddQykLOqbSv4zhLGrWKMtkBPC5kN8R4dmJKO
SkEKTw2VbKyVIo99F4bNIiYcmyIO0jBlrz7ceenUyxGcXNYOGshzKB4bZRZiSI62cGrq+X40yQ7q
SyI46sheUIIZVVNOsMZEKODCpXvkrnQOKR+ssskkjy1sOKsj3vc/VXLrVm1p9gI+bIg7SwNFnrmy
gwB47cVgUooxjHR7m+4fmhyulWu3+2RdhXQXV2IeK+05u3hJrY7KxjvkgSwjsear3gsZOgoqRtBb
WIEgw6UXLcFmgQHO2PJCY+7GSIOOH+21ZCMscMR68h0gKZFMrpIya+WpeyRVe1yOXXYaE/Iby4YJ
ZAWIa2SUUb4nh961HVmP1bjOL9tzCu3vZ12qpZ55EfT2bbQfhyQI15zAzq5jX6N64mwnSyNRepNz
q7mww0PMxiiWltcOijmHja59hTF0hERE7GpKyuDBM5GudH6ZAKOEPFuxQxtbJITeXZ3FgxqAfmuh
RYYQcVO6YqQA4A6ysby+96TMS5El3e17mxFjBa2dZYE2bj+eESvcsEjq0KjUaNlnX2wLIlhFGesj
Y0tV3iNZlR70V1Bjzso4Z1MLRzlw2NE2oPQFr2jE3zln6aWQTfeSbJj4g7zgZHAycSJzmbPsQby1
CjOkiKLr41qJKk4oeOIVXohta8kaQrgwtmfW2ULpEij3tdxmlXwiSV6J6TaLvPG7Z1u/iOV/a9ax
Sdu1ftX9snXsO6rvbiuZALXhFxxuqJWGwgs4cZB7Ta2RIi5YvSllASresfa66bD/AFwSvJ5BY5JD
243bWB/SXFjf2vXFH0qT1L1JpB/Bbs8KEmcmFrpo4YplieocSdwKN4wTNRfu2HFsv/W7O/8AQSNh
L5IGjOlmgnSAcmJrCHDjmDFAElBPPDtVEFLhhZZVtkNMMPKkiPhjc3Tjgae16D7PTq6+5/ukewvX
t4cH4oWf6ydmysLA3o1RevFTepW96v8A4Ru632Pa9jYeJTApOVEFD1lxY6PeYAI0CJyq3sjfbxsZ
N99jXd1qbacyBoqqvrUN7q66r/4Ru6uq6r91fb29U1/xUsP1ibSP6RBRskIcPCXETFY1AZbOWNzF
TshNk3nutSeLvveio2Lcazddv+rq/wCKB/6xdvV1f8UTv1h7erq/4pHfrC29XV3xRO/WHt1nV3xQ
O/7eyIqfyoqfcXbl4FfIzmJS5Z5Y4oZSSp4RRnyuhhVYoIoxQQwxR2Ok4IosLZJySOMVNAMPCUSU
YXyIYAfLOmKM5M+w76yMoRoouRp7Sw06Q03R2DdyfRerFMm9nuPwT2d7X/jC9nedr7e87212XTFM
nTXu6SYImunUmv8Avhe11bI30JZLoncTfwTRPvJ/uhbJ/grk/UiInpmC9SNXVqJ/vh9Wi9ae0vXt
61sn6v8A1uC+z3f+ML2dvWrk/dV3hMF7ru+X/wAIXdX2V9nZP8Fcn7XXd9NwXtde7p/vhdWvs+3t
61cn/wA5gvs9a/8AGF7K7etjJvY+3wX7Xvf+ML7X2Pa9jb1s5N7/AAX2lT/+YXtKqfeVU9nZFTHM
m1TrReJgvV3q9X++F/yW+9b7SbKqY3k2qqqqqPwXrV3fKv8Avhd13s+37O2vodyTVU0VdcF609r/
AMIXc29b+R9fd68E9juf8YXsexsv7QZJq5dXLrgvbKi7yKv++F1rvdtr7fX3dvEOR+33cF7vt/8A
hB2T9pcj6tNPWL1bve6f74Xsex7XsbeJMj9n/wCgv22m9/xg+zut19vdb7SbdtSZD3N3uYJ3q91P
/CD3F9lO5t10WQr/ABYH+sHbxFkP8mB/rA28RZD73A/1gbeI8h/kwT9YO3iTIv5ME/WDt4gyL+TB
P1g7eIsh97gf6wNvEWQ+9wT9YG3iLIfe4J+sDbxFkPvcE/WBt4hyD+g36w9vEOQf0G/WFt4hyD+g
36wtvEOQf0G/WFt4hyD+TBv1hbeIcg/kwb9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC28Q5B/Qb
9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC
28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3i
DIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B
/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iDIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6D
frB28QZB/Qf9YO3iDIP6D/rB28QZB/Qb9YO3iDIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28QZB/Qb9Y
O3iHIP6DfrB28Q5B/Qb9YO3iC/8A6D/rA28Q5B/Qf9YG3iO//kwf9YG3rfv/AOg/6wNvW/kP8uD/
AKwdvW/kP8uD/rB29b+Q/wAuD/rB28QZD/Lg/wCsHb1vZH/QT9YO3rdyT+gn6wdvW3kif/WwX9YO
3rayT32CfrB29bGSfy4J+sHbrxfJf5cE/WDt61cm9rv8F7iJon/GD7CdX3urb1q5R/nMF/WFt61M
m/zmB/rA29aeTf5zA/p/t608m/zmB/T/AG9aWT/53A/p/t608m/zuB/T/b1pZP8A53A/1gbetLJ/
87gX0/2nGIgKDKEKUI0I1AkKFKQKvsmtc6tsLUCVkoFqARHIOfN4Z0UrYpopI0xVy6IjclevX3Or
COyE78pjF++1q/aptrvs7m97Krond007q+13Ovuqide1+d0PiwNLTnZNXRH2GaHQTvmx2xMrEKtB
kxCQSoqypRFnlPSzsOTEkjm4BSuRi5N0uVVUoGN2FaA+2Ot4Yq4jpOlp7aCdSCoxGDR71u0TRyyP
V0PE0TicJkBQZYxQpMUc8BI5Ec0M0MrN+OaKSORySxSNVixyx70Tkcvbtc3dXRHsVfYTr619hOrX
ur1dzq2rnIK6xQsp/OcKV0fRtKGyOS3up9yInejr0nH0gXhcw6VE5iHTrFjtrymq3nyoOCy0sw69
5pD0YsUAjSp41Jldvojkg4jWP0Zvue7dRjqC1oymx5CdQGRE3g0JrXC9KNHJAGDSxYd0qtY8yril
IB5ulWWxbKkw7gHWjR8nx8haNk8l20e7ryJKVg6uSZ9u0UkhK5sbop2v5hUVr4XMc1JNWtJ6Iuau
1UIjlTUrrME7kyEau/AW0aeR8EzXJu8F7Ufpo5yM7ieEb3F2ELdGwmCS7qKo1WzrC4KC3OGAYfpw
ZOMyGYqNZItYU3Ec5Zm6bF1sDK5gwNqFTylnW7xZyjCKJ96RFUgMriekZA4ZQGSM5qDVJbCRzo1r
FiKLGDyOhMKBLQAoYW4rSZxjncdGBlxwFPUcl7hSd0d2s/pXDWJCN+BjWwWVfMriigWpEWPIrywu
KhQzGslcqkDrAQhEHVNCo06vjRkav279m17epE0xaWms7ZBOYQbmujgpi+X5hzJWj8bg8PjujkSL
e4iscjd1cTjQZJfRRbw1mqkvh5Bk1JZW3Nu3hXJPpIA0TgKo7nsnUuNzmxcKQwmrsqi+Irbikp7I
AG7Aknr57jIQcf8ArxBuceLLC8kklg5McLpkDWBzh5nyIOlRBkVLPbKsv7Vw21dJYqg0soxbmgtI
5t7RShyhSHJBuxEDTxOcjon6a8RPtk7qd1F06+rq28In8qfJt4RP5U+Tbwifyp8m3hG/zfJt4RP5
U+Tbwifyp8m3hE/lT5NvCJ/KnybeET+VPk28I3+VNvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM
9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35
dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM
9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35
dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM
9+35dvCM9+35dvCM9+35dvCM9+35dvCM9835dvCM9835dvCM9+35dvCM9+35dvCs9+ny7eFZ79Pl
28Iz37fl28Iz37fl28Iz3zfl28Iz3zfl28Iz3zfl28Iz3zfl28Iz3zfl28Kz37fl28JH75vy7eEj
9835dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dsqei672SsXVPcDg
W2N+6J6/yYP2RF2RP+imqd1NeveTX2W91PZ1TqVF69s3ibWY2zKco9HiQXaiDc0g+Um2jgxbG25J
5zIWilCMJjRZdBnvTuRLxDyxyRJZUyunyEIVt7e0PPCh4UNixURN9QRNs6c4h0RFoNMMOZFJFAkB
A3Cmk2Br3CxBcBHyPGgt7bIRmySyPe58d1chiGGTPfK9ZpJoY5XdScTcbwnr1Jruu06u6qIqoia6
9sq9TV7qO0VNF69jjiMjsautZRxY+CLURY6ZMoZLpJ7eaw9EVDcPG5lWgQoosu/HySOY/WZEhqT/
ANor4p+PU+J3LrG4OBKiSpMOkZZATRUlmwyS4EOSaxrWRAMkOCGV57ht8fYCCR1byVb2Qr7LYJxS
TOenr70XJmvi5LoceCvNCKu4xl3iD+MyPmupjIwUZQFehuNaLBL/AA+gNEIsnS2slyCGENZW8JNW
GmPhK0QUgiqgKu2yEFxo0uKIDdIIs41CbXS4njlBAPAsiSpPRGXcj3rCkMMfKQQWUIoUj17T65hb
Cipv7fJ1Lp7Pt93azqZ10ZYBEirL9tCssbkiI1RN5HCv3Zmub26LGjmJvIibYYywMrZ7auys7J8m
KHWdIJjLUPIYDlqm8ss/1uRcipEyVImRBMfC3itYiLyKQgOt6gEGCgyGfMsutGkm09sBZi81jt2E
4HFxz5wI3ldEGzoyJ8kEbeDuMZETIUMTWjAykCsR06kSZDZQ14d5aOhem7HHK2sSVpT3vJnMubZi
qibyzdxNsjpRXDxkW9FbVkMhLnxjNkPAnFapD2Ne9kGsvpzmscqR7yoi7YiZRUWMUxdTcRz2ZwFO
FWllgzUFvXEMhlBrY3Ezc0aLOyOVN2cHiGucwmFjViqJIQeaBfjkI187M81tOaGocpqbaVkmNWwM
4mPRlCgOmQavMLgUlGQ7w4qtcPK9BKUOlq+ydnd9MbEST09Ob0nfU8IC1vINEDjdDOksdsy0nkdW
QR1fJpG9srV7ndXTTq6l9hf4X3+rbuJt3E27ibdxNu4m3cTbuJt3E27ibex/6DZJ7oo/0BwLbHNz
cV65G5E4rpGs68J7IaLq6KEiTqTVU3Ynaroi7qauTdXkOvc/4ew/6HUvRPUqa7yO+1VNdF2Vd8Lr
Vq68wfvMkXiauRUpk60aqs31aqORyIrU06+pQE77uEWn26o537leyqIqa67vWidqqt27tfvewvFP
RV9pFXof+dNPu69zbvq/q6/D2P2r3N1b+1HbaK1vV7Tu71daddev8HflPXd69er9p0+20Xt99NOr
7u3azBq17O6pNi/WOZqu116IRi7ybu7pG1WNdojtdHbd2u03lXddKfupruoxiftNqjGoi9S7znPV
HbyaabKmtcujdNFnstGP3Wo7c1qFezq3tztlRurOpyM0dLOWVVDDx6LNMQadBEki67ivmmq2Rqr0
c72WNdK5XNbvORqaeizC0+4uSxNdr7KKx4jXpp9xHfxd3bVMswvX2P8ACaL+f6zVdP4Wia6a6aL1
7NICNpjhnLweYEsDCYHSpvIkUZDKuZJFcjm7yzL22/6WiPY12yN/a/t10RiTWPf68NNN+qc5i6Kq
byS6Ivbbj07RV1eDvPVNfrqxTVNU3Vdv1LHO7+RXLGxWbyOmc1m8vCTV9cmvV6qN0cqoxW7n7Vb7
0Xef1ozq3Pa13UdvV6Kjl3V49h3ze2bu/tR23Uiv7ip2vWiprsm9ICjdNHKpNj3ujNdeJTvb/wAG
1eprXapo1zEXbr6OT+HoSboxydrqqTVu8zdbr1pL1r9oveLqvI99IurCLSRm8qosujZKldZNxGSP
lFjj31dJv9pvKsbbO5xqtWZquiafdco+RE6l3Y5gmyp173fsZ1N19nTb12YX8ZYvmmzIosoxCV73
IiRw5Ak0q+3uRRhOe9yN1XRE9jtnNbq5Ota/q77Qox25r4NFRtWq+mIkioqIrO06nLr1d8B7P/DW
Psdf/mjZnWDo/uLxz+v2+ror2O7227tpvV/wg7XvWL3Eql9lyp/9XX73fAf56x80bd8B/nrHzRt3
wH+esfNG3fAf5+wT/XU7d9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV
/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/
AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8A
CTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJ
O81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7
zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvN
W3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81b
d9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt3
1f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV
/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bZJv8
Pe9EjfBPe9mnoDwPdVHSRQPXVuirrE3RdW9em8uOfcyKRfe4N2RV/wCzZSC+tV9KhgYms5Uzt90c
UTPa3I3qTN4IPhkSTO5QQoqExcgfyszCpFFjHrTpGMDdHA9m9OyHhyQxv5mPmu13uBvcJvE3WtLr
5UIGc7d4m6rNF1/gO7fvFbJ3vevbtIAWRO0qNGb7Iqq3L3VfFxdNQQCutrXMX7u83ubWLpd51Ahc
cIbpgCq8oMVgISkHqKdDAcQMhamxFJGLxRuVcRuSic0QG16bjo5OGsckb2vZLFJ1ceJ7dd6Jr+1V
2ie3p7G1Gq9arTVSqq91X9GBI5yr7O8qOd9ze+51uUcOadXStHYQke9DBK/iaPnb37UYrGLpu9fE
b1p7LYSohZSYZXRGTQzaacNdXokCwJxzURHxcmBKb9ct4PH+22xsVyawlZHFBPF9rM2GhuCG76ez
6cPHIiew5qd3TaZjauTSCWeNU5PI5eocjg6s5KiJr9Xx+nI10z1+0Rd7R6Ro2hJm1VFdu1uQ6M0K
FH697GU19VMk/wCi13/lBVJPaNEkA5f+5kcsTdUTiFZPYQlP9pvHjHHR24jfBaLvI7RLSaFyxyxV
pskbm9W69sJb43J7KKx26vU5F7XqVPYfxUuIYN6xiSV11aRRSrXEcsWsbJsmgi6nr6UiQtR/EXd0
4XXXEV9mdNxLGKtLCks5joWQwUtwa1zInGGKm9JG1Efuu1cO/wBlNUx3q7lmS1f+UjMcvVXe9hd5
zGu7nUqeztkU8Ej4JoaG5ljmhfJDLFIyvJVj2SRPjka5qoi9q5PaXq1TYF1naZuadYkSRjMqr+zZ
JFE+clHGTyIbGr4IkTR8LPTFTq6tsvBSxMsRq/o+OGcs8uxZxEPyAOWeGQ0gl0fFQMZ/pb9FbHpq
5F2zIoiNSXjH04YzN2eRdyWmqHqzhQDmTv4hhayfWQc2iu07bbXouTyZkn0X25EqilhgIfNAjiw7
KBJmt5/VU5mnHhbvMEhkYriWKiHjORfrew5KvlldvyPwjBZHSORu85Zh7t0iKu73qviY7+Hqiavc
ndg5pzmKWRAHBw41kXmSZIoo+99hskzNV2zUS+jlgpaCSblLasqZJGOY0nhxNMIV+hDnjfXG7FEi
wroxd/TXadYiuch0a+OZWRN3kcQZH3GI7TRYN3qf16fxbdxNu4m3cTbuf+g2Se6Nn6A4Htjif+0E
36CdkbZDht55o4zoGwLI/dkhc6PiRMTe0innkaOpLIkY0qRgsBCSMePcCEKPOg8Q03LSI88gDfL5
cQvWMZ9BI6N2pHD4sqK/Vju27Z2vJTyoRM+ff1j9PVqcsNV9+nCXu1vE7v2+vdVdrCygcE+EyeAl
I1McLMiclXA7npVdYaemgOm//wAmnerptJSwRsQsJyNIY2eaUeCNww8sRz53B1kjBB5CHRcNj0Je
VAsILoyo5zgRwI3ukZC1zOK5EbK+Rz+IrmxpoyKLf60hjayBO4kaJ1bUP4iql/j6NF2eAKVAEM4t
HmTujlnNVGwhPTlWaRp3zGr9co/2fYc7UwCHiJFDXlRpxV65JJIHvd1728ur5HP7uiSLvpo7RdsP
RP8A6VfxL/g5kqt19riq1kKfdemnXsE54kfC6eG4siibsPFTsh8rPvFuoOshw/1qoq5Ai8Dt0q0d
2+11FYY/URV8EYa1bmVle6OVn11zLlk3OI4p2sCrE9+4zqc2NIJYzjl1Tu0/YmVf+XvZTeTSLD/6
qOONdVXt+1Z19uut11Kv7VHL1dap9bFdoiez/r2kaS0gONxxKsn46RQdtYWhMW7DBk9dIzVpDVkV
u7xuWISbfbyHBrGqrnuiPEGVJJY5n8WCqziaRXbttdT6KhLId58rnemN0XtGpHjn3bghP4nY3kGu
2WKqIm7jN9J1u3dGRVpWrpZHeltdL7DWomnsImxbOkR6qR9HbxDkToVxmTOMe9GVzh4WOHs5InuR
pLu0TXVmipqmUo1q8KEPHo2aNe/VXOyd0nE4aSbisdorlm3l1kTX2Nsua5iSQvyzEmSsdE2WN7Wi
4ak2897o4lYqPb2yp1bz9F7XqyCIqhqEpxkg6PndUgsXi8gK6ZkG61rphlI471km33tV2416Ma1E
x2dBWo/gULknQJGq90mH2056uMbV16dUywtl3r+54b2N4/R6p11i9XXgmDK3TXVd0bINGLr3NP5d
q+SGGaXgkNk0Hhnn03D66drk5QUztkZA7tu793Y6GopOZGv532RwfEvhy6+xOj49jGKWOLYOMZKZ
27IipK2EZvpIrIYfS9ljg4kbo0bFOHLFNHKHPxzCp4p+PLM5J1JLnc+NvDgZHwnAxrXSBzTfvf3P
59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5
/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Ptkif8AtGz9AcC2xlsbmse7JHNRz0VzU1wjshou
qJ19aap99dvVY3c09QS69xU116T139HPbv8Af7r5G66PeivcwkRj5Hb8j2Vz2Pkf/Ckc2yR0jvuv
VV0RE7ibLvFiu1/hASOX2V7q2ar3VVfvrt1lir1ouq18irq1EanWtlr3Gp1dzXr7qqu0krJQGSzL
C6aRlYrHyqOiNg4jm2KK/gsa2KPe13IWMhb6UxrU9VjdzT1BL3PKfV9/u7QCjkDRwDQRDQM5Kd25
BDG2KJm8+0c927Gxrd57nOXTVzlXVdnSTR08sj+t75KRj3O7Vre2Vxy69qxqdfte3rt24GPv7vfY
9A7vm7i66mdfa9XXsgs50UToCYDBZxxdCRDBt5IZW8Q5Rn7qPeixyMfG9HKkjHJssr8pIfKrlesr
8dwx0u86TjK7iux9XovG9N6neE7fvuvb1zzfe9DmF6d3XXT0P6a7yq7Xu7znO7rnKr2vsksZ5ZQJ
pSChGKRvVcqTgtY2sMBDhhglTeQeGJkD9XpJG9sj0VzXFCOa5Ho5q18mjkka5j0X9s+tFa9yfc16
tNE28W453Ud62xu61ERF9V9Xep/J17cYQelFm0VOMPRxwS9sjmqvEjOa/f3XuTf3t/Ry9fXsNLIQ
M54kykDryU6cOZwxAiv0S0RHfW5U8e69HN7fe032sc2UYiYGceaOSKaCasdJDLFLG6KRkkT7JWPa
+N7mqjkVOvXu9e2iY5hyJ1dSYhXI3RqaIitQjTTTup3F9nXabokKhq+Z05jo7H4QuY3d7Tj8sbHx
tN9+nE3tN5diDY7maumMZAw1g1UDNEW4ZsbYXcC6isoIXsbFEm/BHE93DZvKqtTb10Tqm6rdFx3D
FTdcmitRFx/RE09rZHtyg5vselUeLhvWPhOh0hNrqkcsXdie5jFGniWNF9LVuycrIJDuiggtRoRG
iC1rSGBRIjrVURIWlTpvd/Jv+muerWbvqsX4BJ7Wn/nP2ttOaE01VdOj5NNXLqq6dJe3t6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+ASe
c9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASe
c9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASe
c9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASe
c9vVYvwCTzntkzZHNe9uTK1XNTdaumC4KiaIvX1Jom2I8tPILLLnVKLx4WwPkZEZR5mJPuITFNDv
PgmkjRXxO3d7ebo5EVJSpclyBWxbjFa2PFt9XkSMHi7+iZE1ySysVu+9keunEVWdSyT1OV3dpDE9
sck1aT2PS42Pdq9rHrCyTdlkiTiNaui8FzXbm9rs4gfIchiRJlg3CWYsjt/hxztTSCimRUVsjUXR
+qMVzu6muztMmvPa8FjerVRzk+1x6Zq9aPY/Xd3Fj03NXKu3rmvfZ/4HHOrTT/2dd3ete6n3G93T
1zXv+axv6O7eua9/zWN/Rzb1zXvteCxvX+L/AAeam9/B11TXuppsv+Et93NU9JxtE01XTT9oHb29
3VXXRE3E0a7e19dF/wB3XTh45pr970P6beue/wD83jn0f29c9/8A5vHPo/sv+E9/ovdThY5u+99D
2n823rmvv81jf0e29c19/msb+j23rmvv81jf0e29c19/msb+j23rmvv81jf0e29c19/msb+j23rm
vv8ANY39Htl0yS8TVd7qgxpOv4vdX8W3rnv/APN459H9vXJeJ1buiQY0iafeTHdNshH6TLN5PHhL
MWUyKtSWAmZ18x+nJABxPZ+14zkbNFJo5Hde65W7VNt6NQh+lK0Gw4HoUHl4HOixE8Hi9LxcTh8T
c3+HHv6b243XRPX2F8UB/PW3r6B+KA/nrbjOzgR6cYeLcZiIKPe6aeOJjGrPkMEaLI97Y9XP6kcq
p19aRjtzUdjpJXDb/oapCGsJbDKS6NyCZKS9HJGzRu8xGaRu3nbyt3vX0Bpqv/igP1oqN3f3a06u
2+/rsmmcBL16dWIjdWvVvaLcdsje6rUcxdOtFdpw3+vkHRU1RPQdC1zfY7beukVUcqKrF4bOpF1T
ubJpnIWvsJ6EB+v7i/tz/wDFH16dv7CtVc6B0XXrTEhtVTcc527+27tHN3e03UI101dG5uqpp6OA
07vdxCHuo9yaddsxN3TTcf8A8NormtYjV19fQPxQH89bevoH4oD+etvX0D8UB/PW3r6B+KA/nrb1
9A/FAfz1t6+gfigP5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J4/nrb19hfE8fz1t6+wvie
P5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J4/nrb19hfE8fz1t6+wvieP5629fYXxPH89be
vsL4nj+etvX2F8Tx/PW3r7C+J4/nrb19hfE8fz1t6+wvieP5629fYXxPH89bevsL4nj+etvX2F8T
x/PW3r7C+J4/nrb19hfE8fz1t6+wvieP5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J4/nrb
19hfE8fz1t6+wvieP5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J8Hnrbiz5uNLDF6ZLFFig
0EskTO2kjjmfaENhe9qK1kroJ2xuVHLDIibi49VY8cLXz25drA+U0fmYEYEC85uqbj5UXSB7G7ns
ydui6IrfXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXk
kj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkf
N9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt
67Ma8kkfN9vXZjXkkj5vtkm890jun4VfI/d35Hu7H2AOfI7caxiOe5VcqMYxiKujGNbo1ML/AMoe
Nfc/czLthClPNZWAMDJOrBBVKlslfMbHE2OLVruIwpgc7ZIl9LWD03QVSdsiDArpx+LJWzLWEWdB
FrM6MudOWLhuH1hSPHe5jeVLJlgjjGinZHIum00hm9GSpcL5277XvbM2tquPE58Tp43MYSyUd7ol
VjmRr1aqrtsgucoEqrbKajK78Uie3aIVZYsKHblRY9BX8SQuTHQiKCKrOgUSQTpJCX25TnkGubEG
a70P9AWma5DhY9NGGb6JA/Q/JcjJcF2zraUQ/jOopjZaqCjHcPW2A7+lZnDPlIxFOLhAJGaYrYZI
IqUt6YynWn6J4ohUS34r7VbXpoF6cKaokpN0sTS9fGhjUsa30IVkIfYpo+yVYttBrc95EhMl70nW
CcocBywPCqWJBaKywIDk3m9F2rCY5hcmmQUCFajK8Aog4yYykc4bLvQfz3NKyeNHkQPyGwGBlgdF
FBOLBzkcyRFybO+uAMou7/sp5VitQrKhWJXuFtcnJNRo95n1UGfA9aVQ6apkyXG5AIpWQo62kFig
KFpLkGopGhYjU3t+HKG4i1mPsbPJqpIQ5q/JbGqrB5OiA7Lc5nIXCskmrVKLkkbYC9krLTHyrSF3
NZQ20Uab6pYQ4FjVjjMsTdUajyyVsqJjV1eVYXFQPHurrvZ6KLI0rNr/AD2sm5R9ay/YXbWGBUuR
3ggsZuW4SEMFWQNN5Oc3Iw4B68GIaKMsqQceWS6qx8UEiq+xTSdkezHPEs7B5pJLsg5+mAnCuhIA
4J4qZHB2T+k+Sf2rxLWMlJhKisAFgOxcyzjobGZ1XCMQBdSYsVk3JwW0mYc5ZFMHYDK8cXBejWwF
vjdkCGDSwbA3VizFLSut+xzl/ZEEqqZh49mBFRxU84FQVYT2Z0BzVbYzQG3MdZXtkJgkSKrGQZ6T
Y/EdTUlcdk2Ug1FbZ2QAsVe+rOxm9t5i4azHOyHmTiZK4iqglikmv69lyOTybR6lf20Zj81y3GZa
2wzHJcCNEqq21hsFssdhyVyXwZhVyTBEHYTY65nQEoBE4UZLXdPmuYrFkyx+M1Y1fauxZ2NzmRgx
gRrf5VVUslcSRUZzkVnavjBs3ydJT0WJPFLCehNI98ygjUNGt7j4R9L2UYsfsTAKC7irb0E7seE5
OFx6v0YpNDDAwggcqvns7CIg+GstIpx0CeCThlUS1HgRhZNknDcmsUtrSLRBVfEavaPUZL0ywHRd
XRGBjlR6SDNezCLECMR5stRhdQJJYcTo8Qi/Pq6SI89sMkMsoYDz0LnHjnGeU2HlmliLLzMT8anl
xmbIX5kFicGTRVtlDjcHPY0/KEmNoH3s5rbGOCLouOpZlCc4UXXl86Kwnk20lcMtXdvFkxaPM3QY
/wBHhjsye/ZShFDH2Gfxk1ql7prgq4KmzclJREQ+UOAqCZc3/wClnP8A1l9lbbEt1ev0OUPV1au/
aoZdEVV0b3NXKqO7RHI1N5UVHDiDsuMklHcXBV8SVsA4rEV7ybCaKDejicrUHEiiR5JDpOKrWjxT
Tx783NSNSJ0ruWBNLXdZNBE5y8kOSxqrzLJIo3rG5YIyCl1DENIEaHj09AGKx4TyD7KUO2m50c1h
MgTAQMmqYt+OKMdXK6za9z51idCP6VJJUCW8VbEa+WrD49MsMgxjuQswmmSQsMIkhnJJsoIlTins
ewd0/GRXNibVWMzIJKiaY4SwXVyTsnbT2B9U0Wdzki3jzgIqmOKWJ7pS7EZkbt9Wo5ILWlxsk2oP
xEDJRTBJzawfIbHsiiY21QoJid+FBwhTbwXmpZCRXmUM+9Mxk3NZdKwSmnMxYuootY41ggt7fIsn
6Cr7sVtjegjQ0tYzfAsBzLiLn8tCu8dW+poMffaWGO4/KDj9Dd24eXmTFXlTIVFyuPkY40Mgejxr
OL2NiEdMThlDz5a57JEgsGP6lp5sAtoaYOPMCBsTy20vRmRqZh1Zxh7VBILeReYY3IJh1poqqKRH
2lSSeXMLHBE5Hd7ommnaorU6kRNN1V1amu9utRN3Tr7q9f70EfgJfyHbYL+Mcj/MBu1UHQX1ZjWQ
ZHbIEDc2zq5Aq8UIaaxsSZulmSArvxwRV7OMx2s58KRJxlj2wCcevtsiyLNqZx49JRtqkKTo0ZOn
SiCLeypKgQYI5rhfTTopZp3sjFHl0k4fZMoeibLHAcTwaC9gv4A8eubWrMIFNIU6evIydK6whdwo
oa2viY5ziopnWc4ossb2sjnHyCxCrH43V5Hl0YFWPS1dzkEA6jQWUPSzD0lc8gdx609dZ19a8yKK
Utu6/cYLLUZMAFJkV/isd2WLUurZLvHByCjhWQhXRly5skAyuEmSo4UzpI4VdHPvxsS+qa6wDq5F
YghB5OPT83q1VkRsdFe3Ugcw3atJEtW15sL3tY4bVH7n2Dkv4/g/6vcA2wr/ACg4593r6Ky/TZCa
g0QZiVD65d+3sgSIpJlsGyERNAHm3pYYyYpYklRUWSLRerXeqi5SqhsIJVY+bl7y6lmcOLbdIEPa
wirdE+Qtn1twXqg/LwQd67eXZF013k7jtW9atTqVFbqmq66+ldSKq6IurXCnn0mOH5EHAwgOwsKq
tLuRR4Z5uFIMTNDzsTBpOM1ixPR0Msi66OfJvEZOHTUPTRzHwE5CGCAtobCxY4eFPbwwtMnYxo0Y
6wyzSNjaNHD1NiRFA5arrxuihZAK1YBB4ejgZ+X4wYO5EnKiz8oIko8HDjk5eDeavBj3W3RlLQli
A0VBT0tUTRAyj0ctDYXR45lXxo3xAyMS4SKLk44Vj4Ldx7dxGpDc2GNUB9wM2Jg9qbUV5VkOweVZ
x2QHTjvJiZBM5ZYWxytSJ67zERdrWEnFsdIhvZoSbyKekrZo7kgdyPHntWSDObYTQPaj4ZS0lfG5
EcxUXZjKalqalsQsYEbayuDAbGDDOQTCGxBYYkaLESYWRGO3SJk5RErWI+eRzinrXAq44oU41yiD
7xZoKDNCLKXh6kFBoGGgs8u9KOgoyRObwIt0iK2x2is4izILEuOwqQDYyrAUdggpxDCR5GzGDCxx
jQEyI6aEeNkMb2xta1Jh20lQ0cisZSzwNrQ0hnp4+Y4dTNEkO5JWM5srcBeiit5kjSJONJvJfJjt
El41kUbbroiv6VayCLgQMSx5fnEZDB6TE1JtI4vS26M6tjMpOkxbmJg7ESAPFMNjxMWR9yYMXbWd
26S6viLu3L6PAgQx0wbI4oyt4eV5auiToXE8aqN0th6dF0VWBodFAQLGanKixaFximFjMJ8M2Aoi
Fr0jmka6Hcq65vL2BFuPuhDJwLUzmebs4dI/S7ArnTOYNZoTNzZPEkdx5d404fEsZgOs5mEWJkND
VRFWBERsVnFOaQwVJSpo7GGGwZLO972GxRFNVJ2NehMdlQUthGYYNYlsOqgS2FWAcMQ4ZxLZ4JEn
MFgghgGJkR00EMMUcT2sjaiVJj5SByqU7nQ5xnRI5UkglFLDnSeGeOUI4WZ8JMe4kielzjTDlQQT
x2EVZhmKV0VuM8K1jAx2oEZZhya8QSwYOHG00Z+87fgJSSJ28uretdnYy3Gcfbjb+t+Ptpq5KRyq
QherqpBuQX66RCeuD1QiTeETe2rJfQljPFpR4xKeToGr4lSLDJxoRqx/K7wA8U3pscIqxRsk7drU
d17ZZEIPANE7FICXRjxMhjcQYdmJhk6sja1qzFlzzlEy6b85E0s8qukkc5cT9zVF+axduk7bFcbt
LH0n9sLCkrDTV5b1PqUSNJOvA/4HV/pX2mm1gEzdV5gRIjeKruH9cwvi7dUbI5G9v22jf+zaU4sb
EZoYAIR442DFyTwBV8ppjo4GR1czlWVxb9IoIZHO3mx7jo2NjQC0khxCKMIyilc0Hm4yYoqq3Lty
NxzaXcIKKlOKayV/Ly8CRGy9suqJDYhjmjxTCkpGXDEVGk4UsBgk6xkMcnHFLijIHlVqPgmhYQx7
Jo2OQtkrcdm58wc45jujpecsK6QeQIwpiorpzg+UBdDPNE6UZwgiRztcLBpy7aKm5Na0qqbA2sC5
ZaizVsh9a2NIuF0ce5jHGh7nLlq2NZ2SbjdoUo8coqdBub5ZKqpBr0H59R3HcBBIIeDzqhh85w93
meUGSffSCLdGMfhGIvLAjGhAKdjdO4gGEFrWhRBzKGsgsQiNag0cDmMhaiJGjUTb/b7nybfx/vQR
+Al/Idtg8xE0UELLHIt+WaRsUbd6iLa3ee9UamrlRqar1uVE7q7U2ZFX0MlhQVljW1ga2lb0ZB0q
6PnT+Dw+ZU+SGNovE5tIUH1by++vE2CnpM1tKWxrLTILCsswrfGZCABMml5i0oIxbCmNqZ6NSd0o
aA2tKLFIYkkJzVV+9fHk5eWPLlOKsxLImB2eNMitQ4YiooD5ePVESDWcHNvcx9fIGE5WRNmBkias
bpGNycqGoNLorK6xyO4oeh76yx6MeME6zWSufaskkQQRxo9ZaVwBkgzHzBq58yygPHysyGWtzW6z
0SZLige9l3eRSREMVstbJC8Afib4kDollR7W8wQSzeY7IbAHIYT7LKDYDrg40nGg3TzDROjj3Asd
raKph1dJORPMyvQosoiacsid7kVvjer+Hi/3u3jer+Hi/wB7t43q/h4v97t43q/h4v8Ae7eN6v4e
L/e7eN6v4eL/AHu3jer+Hi/3u3jer+Hi/wB7t43q/h4v97t43q/h4v8Ae7eN6v4eL/e7eN6v4eL/
AHu3jer+Hi/3u3jer+Hi/wB7t43q/h4v97t43q/h4v8Ae7eN6v4eL/e7ZN+P4P8Aq8wDbCf8oeN/
mvLtvZ7umvX1J/Ki/cRU71V1VN3e2oq+3M4Z+RWQdVVhMaspMhBpMYscz2RqvCgZNIyJxC+l772M
h9lNtOvXq1737ZN1etWq3X+C3Ttno1OpirtHAVOkh9e+Yo6ye6b6yrccuI6+6nFVd8pz74mt3liR
+5HHMXBE2M5LM2zIZvxuJHushjnSNGaROLty7IdGK1kUEnEEOFmXg7sTeJwF9NieiVTumL3GMU5W
1luclx+qprUitPHeJ0f0vDcVN/yeNKJ0pPY20dK0cGeECQ+7ra+SWSRzuEWQVHkUOMvjEGEkfKXI
BBdushmx2JUUtMuPzsyJdw2Q1lQkyNhfYsQFMHPpMPuiKzLshStYTKXhUriq59DaWrCKxR834UBE
kgbZWNse3hECshyxGWkgA0mRVW/MTNjYWRFkvEMx2aUyXFh5iLcIOnS/9EcU0bRDUhKtqerqSHD/
AFvZTxEBzlWUk2H5wxKisHyKwa4CkjePihSErBk7mS5CxyhO5IxH1KIuWQKNNx8di3ddr2+oMltK
AujoLm8GkrBseLisJA6ucsWE5l/R3SKJxImuXkeRIc1zk5jvd2iqp/Rb2Q8iuRDLSGAeDEB7Xo8N
gSnkyvT0FY7CCFMeELCxXdIkSmRtijM3J5IYCa2myW+G9D42U2s1UECxcfoi5Co4S7Ua2s6s2SZV
r7PWrphra3b0cTqBvOFQjJhiIT8gZPl9LQ4jV1fQAZEjT8EqMkfEwu8ssfAfxJHnksQ2zcbK6Vow
ccqNZCxjnMdE5zWuWKTcV8aqmqsesT5I1czvXcOR7NU7V7m6Kv8AiMq9xtf/AFuWbYn7mqL81i/V
UhsMk7uMJCyCJUSSR5JMAjGsV6oxF1kb1vcyPq1leyPfciEDSJKziK1NGyQSR8OXdlifHKiSRPYs
e6+KVjHbzHIvD39yOMlRSSwyZ6+vKiHnjEm4Nuy645O9LU2azOjZVcOMUbk5mKWsskzdyONJCaa1
uMwByaSxlN6RthbSCgnjnCmSOlYg9dICNy9tJ9bayNVjBl3FciObWtlYrZ214bJN/XeSRsMaOY9d
xdPTle1dFfonbNTRdUL6QJidjl8t3HikboI4HCvxE3o05JSGRcSZ19oXbwcwq8IICVR2saj02KyN
MdyVaLmKmGnsmj0jm5Ey6txKcAioDZfvsuWkmLhJ4tuFS8cGWOYXfVetRZMdyWIcSemAvrLgUs4O
N299EBMFWWii305REkEdnWyWJtCJdUgUVhFLPcxNGO5aCsbUZGGMVkN/iwuQli1cdLLfUK2yFAb7
bOaw0lipzC68zozo4hjIRpD2WDpgW49VAB5JcTWGNU+QE2Vh6EQSwq+zjJYMZeAxWtXI6cl4kjiE
x6lJBgmciJwYpR4VtKenzE/HRa7C6K3BgHrccNry7iwt8oEdLaLZUdhYTgblUC0gastKmV0blYOW
ITLx9sRbkCcvc39DU3FhDEZRV41dHYTOD5qMO8vgriyGlJHOliDxwXJbccQdqkBrLMKw2WxbHfiv
lq8yKlZXj0kt3Sx4a0ka8IfDYlzVLi68+JgcCblkCtiSFzMctcs8my1FfU3FtEEwVt1fDrSRVFMQ
WEljDCbIVbBkFyuBlEKkSgCuGjxnCcwsKyLpZk16FloD0e4WKCzw+Wa1jtLWCmEkjjZlK9AbxhQi
PizZcVJjYSzfgSSMmOAcmcAqrmmibJJXnPBkMDc7uwEPrTLAB0rO45RDiof4Ezk/eEj8BL+Q7bDJ
Ynvje2xv9HxuVjk1piWro5qoqaoqovX3F029XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1c
Z8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vNvVxnwmb+829
XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vN
vVxnwmb+829XGfCZv7zb1cZ8Jm/vNsm90An/AFfYJrthX+UXHPzVl+3c1XXq7qJr3etzUdup/Mve
r3dNoc2PusmKsIbGus4AZDq3oyGSrIjMChj/AGpYcwGEyEefl4zUjfw0Y9j4nPa5um6qq/d0+1VV
RV0RdO27XXVWtVdNddG7ypeEDVxzCg6rNkinlDIZASZZZM+0peTKIjQM9SAuG97Rp5mQJGyCVIOH
HEkrJg5gI22JHIwEwTCyctKkBE7+DPLPO1HnTH7rpZF0TdbFuQcJjWQtybIKIVw5Qp0FN0PuWQxG
76UV0tT2xEMjWo+NpNTJW2GkjnRnRyNh0KvUqy6QSoohMapIiCxCFPkhfPxL2GGEixSKKGvlgqwZ
rNo9zLHIelmFEnLSSqT6JchdcyZMLlL8hbDiYh0tmNVk07tQq7FxaCWIurNOHLkIqJTyGkb0hquh
gWLJK5mS5ONj+UR5Ch2NxyUMtbDLk8RDbMoEo3Hyb8aVxBU9hDB0w6vHLfusCUTeGW+45Fi30RYd
BhBvClGbwqofpjcIF3xH7lgvTRW9LLxhvSx9BE3ZOLY40TIQwGzpy6SeWB0bS2CmBPBkkhfJFLC0
hIpFcxz4JI0k0V0Tm9rtUGCXd5jtrSCF1wdxSOqXGOrT2iIaARDd1FzWTQkSV4BHE6PQuCcSNwhI
7XzsmgirrXIaEXoEXF7UWpMCVuQUITyXwA2xNpXWdhHKnP2SOtacypupOkSnPsnSIM8fIwYbi4qR
MqLGIuRghsXNGIHFogceZWNGyHG7seIBwleNM7di5xC2q+IyOHSBBw4EckAsEI0KOe+RyRQRtijR
0kiue9yMamr3uc9y9blVV/xOVe42v/rcs2xP3NUX5rF+qsI0kcM7Sq8mKSWN80bXBWAxiK6GOYd8
qekdcTZouL4PiM3t5CBXt5uM10jz3Fqwnn3EMSOZxG8xkL2SRtji3GxMZuM4TYkjjaiEMmxXplkE
rCOSjq2GDEzykzyOIbFPRWEHNNmsTSZZBtwiWQgmR8iq+RykwHYue1XRkPgM6Flq4B41Sqa4CIGv
xwODSZ0DZOM7XqEaxu61NNlarphXkjq3iRbjSh1lYrdYeaic1srfteJBuovWrVXq2oJqbH6yossd
mDmHu66rq4LwxBhpQjILWxiCQk6O1CImHP4kqyTOmWffSZqO29D3T+QkY/CVREVFMQ6jUehjx+4E
ua0KrIioI7SURsteMIrbiws5BhIEYPJErUk2JsktbsUKysK65uMbgnBWiubOqaI0KwNZNVvuopkZ
W1zSRKq6DBMStDZYhlwzFsIrlQmyc6qzC3zIdzphuI6yu+nWPDmkaNv9HRpflxCQwqhTNwJ0pEjW
zsmw6JtvcT1mERAx09PNBjnJqXWjkCQWMx0ePRXcJLopt6eCvsw62RYWxcpwJJ4yJr6LJcnpX2FK
JRWAlNJUDjn1gZNiVFHISfSGXVYS51uW3nKKxqj4lVksZMc8EEkQlhQ3FziLxqgGilGoOg5AbKnq
pZH14RwOQUd1CjK3mSoRyQmimNiOIbzHpmiZm+SWwb6Oa+avs2tljdEAOSDyNg+p3hFQaWxjSGaw
dO2fn5xRuMj2wxo2S3AvbwCAyMPpqihdTEU94SCElXCeeljRlWY5MoEIgsr6WxqYSIq0R00cj+I6
Sahrc4zAWm5ZoNZXvhwqwiowGTI9oIEtrhp5ZYzRUWsa2/IunIA7cR/MNjJZV4/XcRQqoSMQd03A
SRzWd17mCwCiRb7lc7gBiihQIvBDFGGZFCz94CPwEv5DtsQX/nK7/Msq/wCvZzRyDBpCLrGA3SgF
mAl8A3JKgUiKEqvlgNhWeCaSFyjTRzKyRzWu69shGjluL2shr8ZNrQjj7K4OFsr60JpIw+fliuL6
cI6dsJToXxWRwCxTdGwncZKiB81xSz1GlbZmw8VLKHnZKudrOWEjuqmjseIXDJG6KV9UvMzxnijC
RuC4s9gHHSuW+Iva2ojryL8yWvfYS4oNkhr0LmEIiqa8CuZLGQ0MTd4kKGcrMXYvRA6f0OzWRqBg
mW7ah19ZMFacZOIkVaWBiRoZxEXJlyPdcuxYZ3pAzH8eM9wuKlgGToEBWZHa2oMcszRbGtFIx4Uo
kiBruFOoIJRpw0b2rOwxixQq1H6bJaMtd3GYMdyqEMac9RqU2ahIpHF25U8MJDGbs5xIMc6ilSQQ
1k8o8L0NRksHDxr9sp8kbjqCzm2tcGrZ8eIvR7NstzjFVbtHRkP13xaNrohd4oOKx7WN8dolJC85
heQDWFNzlsURGmNGThWc1atRj1jIaBHPExjbayhoa+NSRGmSjSudG8qYSgYVSgW1FSGHEXDK8tDb
uelj40AKgFMcAClyPC98xkZk5ruDEHwdSI8gfDjh81dSwZIsZyMuh+cMxuIvmoXkOxsrHwhSi68o
eslivbcp26kZYzCnyQgjEWIwwJMyOfIIMY81ImudI6BEnlEC337iMSZEYunXupr/AIqCkgh57Foe
KJa5KO50u4e58aRlVsESO56nB3ZYzJo96Y/jKVVNlgBgbeQFCzwkikwxkDEjyMmgIgmYkkM8E0au
jlhljc18cjHOY9jkc1VRUXbJ/dAH/wBX2C7YR/lGxz81Zfsu3/ev+rufUh48kcPHm5aHf7XekdG+
RImP7kfawuemujV4eidsrdupNdfufd3W6ovXu69eqdWiK9PunAh2BVfVVps1e3kSXV5hxYToobGe
c1GPKjGGJmVgMQc46kLFJPvajs0ks6uysylgmMGkr7OwMPFsUryyBi2aHOJKDmeosswswpMLeNK2
DcWMhW7Q2lDAIfOcIMZXQWRk1UOSwmCKaJphY1faziK6B/EesdYbu7u5wUT02O7ucsrsZxKjpD7i
qns/RfOazm6S2lqDJy1sMYx0IOvfMO5wpanyvejmNeNEru1qTZMsxqMO+lWGiLfe1bRrqZJEhWKp
ncUkVjKkrmxKwN0zuI5Gabyomz4SHh1lg+/yykr62axgeZaNxK3KrDDAoHtHmmThwRmExQRTIAyd
jJZnppK+3pq2lr5anHrAarvDyb94t5AUXVDWsJIWOpTTjlVTojhY0MKv64iZzLBwoBDRIedsXV1l
TXllT2+P1VvUBXYSm1TrzIK+h4tjDBzc4SiuNfPwiR4lmcO4ffiVyyxy5GzKsbdj0MvAmvm3lYtN
FNxWQcGW0QrkWS8aRkPDdOjuK9kem85E2mvHXNGU+eis7zHQFvABn5RHX1zrFI6WXemU1k8fC0IB
gNRjJ45dyRrmo5xEtlXD8B9cOc2Q8ZOQOtWBvABKc57OCUZz4SCQSpHKVzYvBjdzEW8Xb5FY0+KC
D5RkOMRTXV0EGOURRW9hWNdGSdyMfGNZXyFoG3iPhbvsSSZIllWWkguKqa5HiWeepisBJLOGBGCS
LNKAyVSo4kjPBesj4kYjDBHa6EQ7/wCxyr3G1/8AW5ZtifuaovzWL9WdLHgKFKzlyGFMbINIwpeW
4M8T0cyWKZZUjfG9rmPR2jk21aqrr27Xp1tcj9d3T2F0aiewuv3d5db2SpmFKyGor+knVW8vE5fr
dErtIJOGwnWKN0r0cyLiN3U3la/Yu0fCDVyDmTiqK+fml4XLwlRS8VRR49dZZYN3dVy8vr/CVYiy
HsV6yGpIrWt3eHAWVEmnXG3tI4f+UqoiqrV612EsQaCvbh56NkDtiL+Rl4QDPHrX2sWO9BuDhrLH
egLBUrIIrV1bPHOVTimcSuhuYIMmx0l9EkvTcUF3XyLSIJxWm9KxNl1rIxWjvcbzbkQbcnSeNGxO
4jv8McWajbJKVV6fqUjjttV/apdDEj6ST/hK/faajFY1I990ayRU5GQUkFoTNygtVNbhQ2UpKxwz
IMIFJI0madRJoCUgga6bhFDybiwzjybPOIvqUYFhRgbjyLIKMNpNah0lgE4uSeMfmgWV1ipYqSrO
A0Od5UTWQzbtblyZDTVdPaLDEk1xb1APKHSjoR0UbJz7horaKFzVkr2kkTM1b1JFpIs9NDbVstwP
ChJNOw4Z1oOPww5OYIrkl5yCPSwDc58w0SfXYqrok0Ky9xNfb9n2kXXu6oiqiL3U9jb+X2V9n/bq
9pOpNE/eMj8BL+Q7bE19qwuvzY5n5Kqn/ftLW2Uckwc0g8r2RElBycUQiIseSMkKYcqF8REEUrXR
TMXeYnXpqim1jw3kjWL+KdKaaedYlzokTYiJ7gwqe2kJGbBAgRKm8cFB4EDkg4MW6CNPGaayttI7
oF1ncXNqQPZRRLBGQ0uyPKLVqRLucu+Zwyo2PehXhR7p3MCO4ljYCWxJMBZwhqWQIw4gxwh4hMJl
eSwcWKN0lfOM6XWd03EeUU6YUh3S0ZYgkYLDxciyEKxnDilWaIewsQ7SA61jimc+SNLMgvhvkkVm
iyP3h7CeBJChRzRYHOV/DaPYuFeZGo29y0iTPCGd6bC9WKxeGrOJLvi161kfJBVJlGONxSUiZWHo
OhkLkSb02UjlBt8ybiG6xNchCO1XaOWEcl88Vo26Qoy0tbAx9pHWSU0Zc5h5pJRL4qyV4cTSZZY4
4lTcY1zWuRWTgkbr5LZ8rRrO4FcU28IaVaClckeM80AmdjXNrCXSAD6IwQeBnVsNKPX14QTT8fNs
LFL29UsmPH3DTjrLjIwKUSGTKGPRNuCbSWxir3rDqsCLC6zV0BrYrmI6GyBgursaqJZZRujOVace
xiqo5CN5ZXzRBxzIVoY16FtbMjY2drGzTdYirupoit6k7ncVdfb9n9h3du7t3du7t3du7t3du7tl
H3MgD/6vsF2wP/KTj35my39hW8ENp+7ZLxB5PBKyWtsh2yS69SRwzTRSvXu6M9L9N3NhhpilLfFC
xqzvXVV3nvVI2SKu9JBGjmxicVZJuG1UnlfI/Xa3rzXSxRWZpxo8zHPYhoViYQejhH7zHcyCQaSG
WDvIRo2Agb62ika5RqBpx1wfMr4oJbCzmcQUQUydGwBkToJCnNNjkJPeDHCMOk8aLxp43bVFa6VJ
XV9ZVhSTRq5GyqENBAsrVXVeE/hKqq/tpI9dV3W7X1PUnhwWtjl19eMWGysKdhFPb5iRbkVTrqvD
KsaIommlfWpa1YspYE73zhIyeNk0dIlT0SDcj3WQlF3qZlkR8tdTZDksV0ZVuEvMat0zdSBmbhRV
6TTWPOQtJr7MCYl5EF7avnrLETKLnIjTkmKJ5ykEJvra3p4qVejN2aAplknTVVPKLCPYpJYhnmb7
4JKe0QHG6walOjliy4GzsUy8ml5aVSsZmq0pIROjzTJ1bOs+SmiI2OOyiqWWTR1Fh7HtgHijqypK
xWMGzbZ2BDr+tosnrbM2W7pJscjHrjrGtBe8iGG1u4C7QmZJZ4oHrPtcWIEwWsufVWY19azIMixb
nIB8IFxE8cq/xqBLajPdJzJw5ldHZNmbDAMZGsRZDYLmspqvD4GZRgkuJ2EN1k2S30lCVGbkJ0BY
V1YY/PZ5NAdPfOIKSybTEAmwMKiksURsCXAdb6G31GQX+A5EcedaWcFkDNiT8ZjNAFq4KIkYuMsb
G45BTZbcRzJyXwyhbjEnUA+BwNjKJe9kkiWqZmmY4PHPV5zkDboWVMhxQOWyYYGwUcc6qnry6wxC
Jl5hHhjTS5OVLCAPFdk4/IGMGWXYPEFp8So6HkyDjRBSCuAVXFctPIjnzjyMJmSEmeaCP9jlXuNr
/wCtyzbE/c1RfmsX6qNiHUt3P1UijNSNXTRQWYk86JxvSU3YYpHrxVa1UarOJCrkmYUPKQ+Kaeed
8fLenNqlmjRY4gnFjzrMkHazI81j4pJXKqwQwP5CHJ8bU93MmVZSTkOlFiIgFNirnDMgfGG7RofN
PZA6UaZeDEMsqykKRLJ0RXZJkDHGqkjCiLerUcmd6Kx0KImFNnYusU+icGKHce766SRIWvbXzq2S
RimPekblk0jJLIJZHqvBdI5Wz8PfY2LV+iaaJsBjLo8dMxmmjiArshda2UF/0UPFuAjFUPQigONg
a2KvNPhylkdjHA6zSvr5yejI2Y8SzGhkx/seZHguPWIRZ0ht70yAPXQnXgk1MK2ggVAITD6oSwyN
s5hLnpZK2vjmNy+IKKkgiuexTX9j+tY6OWPljAvRJEx5DogH8KpYy0rWQuiilfEwOV6wPZG1q9kO
qHGx1wsuXYHJd5AZOQl5GzHsawm0ihrwei54LN8srJoBySLqubWFFFEJAQ5WitqIkTHFxyp7IOQZ
q2wWysn3hsOQD5NM8HotKdgUU4Z2SS/XKW5HPDAjyvjFfGkcmCQTx05JWGVFrjkgQmeZrig9rVWE
FP8Atv6IMcphLQCw36eNplETX2lYZGTNK81JxmPdkxEsAY8dyTRTBQDlFHSih1eK0lJyRJhgsM0/
LHV5qjO407XCzRTuYOQQQ1/7yEfgJf6t22DCFx8UeY/JOJHvPZvcOmMezto3Memjo2L1OTXTr1RV
18X/AOmHfOdvF/8Aph3znbxd/ph3znbXo9V7n/yo9UX/AKKNJV3s93rT2dNk/a3ur1qhh66denVo
R1/f0RGp1u28Xf6Wd8528Xf6Wd8528Xex/8APD/nK/6l28X6/wD+4avV7C6cynffxt6va26q3qai
f/Kjl7xqtb1ISuumuvcVd/R/hER23i/X7xhy++9PajFT2u7/AB7eL/8ATDvnO3i7/TDvnO3i/wD0
w75zt4u/0w75zt4u/wBMP+dbeLv9MP8AnW3i7/TD/nW3i7/TD/nW3i7/AEw/51t4u/0w/wCdbeLv
9MP+dbeLv9MP+dbZX7og/wDq9wTbAP8AKRQfmTJPlX+Vfb/Yfxovd07nWn+r5erbuJ95fY+9p7Wi
afdTXZMPfj1ddKo8hknSxTEGjWKCObrHdWWiucrZ4/TXNanbLq7eXt7QwDEMZDlDCmLMWrsOXnfB
BDxtHLFi8Cybyxuiaxz9N6NdO51HWx8vLAVYRVgfLuTzJAGBApRcm5Cx0j44xopN1kQ7nq7tYmbz
kary6yO4aO1URHW+PX+OOlSSOKVkkEGQVlXOXE9HbyEjRSwd1vERy6L9R2RPsIJaRB4y+kw96wFe
JKrUYVE8BpPGG7dr1niR8TItZnubExz0ZXTPKkOePCVyoVbZWUrRpz4a2MiVteIVwIVLnajpJtxk
cERZkitDBMng/wAVlXuNr/63LNsT9zVF+axfqyxslfA+ViwtnjZFI+F03pTZWxzskhfw3PR+7NHJ
GqIu8xydW3WnVppuu7b20X29e65rtdfY+p3E9r+L2vvbez3fac5e77Sda/c/g/a9xE2DEqzjEksh
ZDapLHH7+ijuBGbj5JaWS6qq6K5bBDJE561ryOHCqzu34o5HsGPjaS2EmJk7GFBEhGIyRN50cgBs
UJor03UV0E0fEVquZua7mwNxWT83W2QY5YRKREDrPBMzeZNwiEjmYxzHNdGj2NezVy+ztXwly8OW
4P6LrmtjIck5ygG2EcCSsifHGiiV5cyzybkEfC3HO4j2I6EBzSONMPMQ1zQDXDcIVw7XNkNZDykc
68dqxiSTJPK3irHFJGPOqKunVprq3rVFRFVe5pvJpuo1GtcuquTTd1TZ+iNarlVXK1NOtO1Rz3Ij
014TYut6d79xNG/J1p/E7RN7X737yEfgJf6t22A//wB/k/5jsP2BbayyMpjSLnDgIbMCaWAoNp2X
0gEkkb4XNeqJCTIjo+9ka5zXIqO2xMesOJqrSovsRIzuOuJcyaM30ZV+JOxeZ0fpzhrqzW5Nfq76
5q6JyT74ti1kgj/Q/CzFj8ktMTAukuuLbyWdTMePISZjrq2GMOqJKqLAYQht8XYrqDPPVsaS/g4s
c3CuNbZbXF3ddUhGZPfNhpAIKnjlHzYzgdvYjFEHWjRAY2UpFTLAjDSLsOSSOvkhOJs24s7InVVQ
NYW8zKienlu3tjmIleSkSC2FcCphzIpkH3HgSb0jJUazarEpCgcyvPRKXgwJTbyJKizmqRzbWGzO
yIcW0SOB+NDsPJmDDtiVOnbW8GUp/GZmsF7V07aCk7F8GSzgVOW2cBsZemVOMlr7eLEqqxY8h1Wl
ck3GFkqowx7cZshZZIoJaCY0wrHcfsMdpL2ynv5+l4bC4FpDEWuq+hzIrYStgyCqcaYXeAHTPU5I
hp5gfrgMcrGR4ac7LcowoWzjvY5bMi3xnpz65bj76+BsFZZ9BzRwulvHHjkyMa8SSudFcTTlGiVd
YXBOyOanFtiz7Wq40LSIxsjCsaLHTqO23H6rVzAzaQJESwwiMhFZ/iMRxqkrbDKqTKsQpoT8TDVi
kcwt/lLX3tO4iWEQGwBEh4thKXOLVmVYrmXJQcYYVvUbZb9zIQ/+rzBNux9/lLovzFkn7CrWcgkW
LpN+9KJvKQjkqLV0KQsRkqSzcw2LgDuhnQmfhDtHnlljifC+zjjiM3d2aOLrZvJIqI5qo6RNZIuE
58THSthndLFHMYjWLsURKx8g8VcQTM2NV3nMhqKt71iY8cyLiJFG/hqgz2qqK1Zt3mUgyiSUYaEq
OjjdOwZnMjpC9t7MNvFD1EsTTOI4jpEYhlesT0hZuD7sgsOahhwEEEk4jkYwo4kT5yZZ5qcqCCMe
OJszpJ3SPa2NjWue9epI3dzauyCqM7I2XE48bG20p73FLDGz7OuswErng19azFcVGsW1thyVuw9a
61IGhGLgYfHATJrjwhmT5QJXj0NaXFa1WO9kXMhyctluTS8jYZHheRVjRxmtlrI6wTM6u6xptU1w
gIo7RrGAmusSTM8fJa9kvPaO2Fkusmhrh8GJbmfRT4QISYBqsWKWGonpsjHYPYwOnDgCtkCUIWML
ErEO+H41LNR34WQtyFCYTJQGh2MQSZF6Z0aze+sVqVWi751Yqt312trwsC8AyeXIex7jSMHjMjsp
qPE8kpw7c6JB1Uhaa1JKym1SVdYyKEzmCnKNI5rMwaTkWUV92+fLmVFc3G+yE2imDifKViDxMpZk
RXY0GhQeCqc/kqCsvSHoZU2zySCbLngJ54r+vrMtMgypwxsZsHoYBo22ELMeK10bWSXKR4jMZUv4
bipJ8mXhybpS7WTLC+zt2TGkYlFe1kWM9kiqkBLTOKWO9MqcltL+8xScaOuktGyMwEempiaeRTZA
GACRxCjhwuIfELBEPG4sso8pzIWIxriDjpiTTJ1RNZSSyJyZ36yTSySOc5f2WVe42v8A63LNsT9z
VF+axfqyrLM8eDm6rmJ45XQPhG6VC5mVJmPYsW5BxHb+9omnWj07RSXSRJKTE4hlaprlCkOZGxED
ksmsgmdWuJdurI1g80zIk5mUSEiR1bBZ1kMQIslSSg5EkpBUnE40MZgr43NrF0dICSM98fLSRsJ5
qFpL4xoZzefONC4DVd1P51+/w4JiZG7o9BG5u6PBPKx8ksce/G2N7+3RFisomK1srzoOHo1fTATC
ApPtu46QZXw+mIqtkaqommqdiikipb+vNwrkz78i3o7jH4q8gPG7Cq6MFMuKsB1nIefZMgl6EGsA
21ENgtiYCrwYLPsbOtfRra2M+NUQ1oAWnZBqoKIxo1lJYXd0cPLJh94TPJwIzccyslt6E2OMkU8m
aYSvdVhZUFdh20GN1kNYPwruLHBsdigjSGF0EoAoI+VsLdOlqy6ggv3uc5AF6G9KTHpDBc6ntwOy
TdlW0pkF47DhMbipswHxgyqklauKiwqATXw71M9T3GzTj3svNTMgfhQnSmaiWdjgWSmX1jbWWSTq
BlsfoQdROtIyZ5FHdDIGa2MFWRRWI0dpvQEPPNdMPkLGZNjsN5k1XDdVMFdlNpa45jNVWmiovQ2K
21BksricuSA8ybF7ESzdUkjykqZVA2IcmFJKdmOUb9eME7j1XZWwuuqWwvt5Ol7B1k4mjuJHtWGt
Ip87PJyH0kQ2I84ktoRWvd1RdF7qd3tk3u63R3UrV7umqaaK1v7xkfgJfyHbYF+Mcm/R89f9f7Dk
rMfmBuarzeHxp4PrmrPGswJeIPLFJ6QcIPPu7+5Jw+HK2SJz2OteLUwft5aVV1aujfPA82ypH10t
YRLJBLG/QaSqCfy7HNGmVk3MQy84Zx5L0cCdh8hRdgka2txJVwWVhEsB9qFQyHvowLY2OSdpdqDX
D2JHOWDpSXOsTlIoqtK8oIfGIOVoZqi7vqSzrBVHaJKKNdU9mDccsTBHC00d5z4TnDjSmMnmGgfH
TEywSTkUHG6KmIMNIlHfOG4CYiR8xD3FlyCPkicYapBXp0z+NxJpXPsJDQJePZlVxxJQlna1xjD6
mHlgDwDa40UqqPhF+tVNq5gyphNRSJZYFWPbUoe0Ic7H5cWIfNkuTSPsKOWM6Lk7Z7rhXXD4ksz3
im2imHhzkyEiFQk7sqR3UtdMpjHgzPjba3EdYaVVoxK0+0o4z2UtvZAcIflLO0rzLAdQwFiJaoAS
wDNbXq1A76yyYbdNPa6G7t22rbA1r0KR/p6XlpoMqqJBzSqPBEsUHDJbXNsHvMlbMSTb3d3kJ8qx
xsiij6RyCxsz2jQsZ6QGwhokD3zSRQsknmdJ/iJspSvH9EE9ONQPtXIrykphDS7GKvhc9ytHHcab
MSSg7YlNkYJzjp0ABQfbMV9rJAv+rvBNux5/lLovzHkeyfe+q3iMY/cVXM32o7dcrHxKrde4qxyS
Rqqd1j3t7jlTbe9tdFdr99URdV7mvUidfW7qTRXbR3JMxgRsTJmzTQqJLARFJDDAvNCXFfZVzkjh
HYzRBmaom+96uai7TV4t4jUKZJFIOELgo7pmyMSJ/UHjjCNXtRI1WN8b+23mq2TtttG9enerrpr1
dW45qL3ETr0Y72u9121TudevWirvO0cqO0c7Tu9SL16e0mm9/jsq9xtf/W5ZtifuaovzWL9WRYYY
p52tV48UzuHG4hib8COlRr1i9NRvpiNVW91E2buNRE3dEa1ftE004bO46JN7q7m43RI29vtPLdZf
Z43Z2kAiyQCHAQwGclFwGvihODK0kZE6OKRYtzXtN5N5Ndo2lZBlZo+iEsUxuOkDuZJDJpKxZqVz
euFZY95mj9yR6a9arsHVBLNywbHRxOIk407uJI6Rz5JV757pHudq5PZ0T2tnb3XvNVN3Xe345d/T
Vr9xHtb6aqMc1/ad4vW5ru+3m9bk69U79etF6l0Xuads3dTTXd79VX7XVdXP71F3lcqOkcm6jUVX
dTm6NYiN0RrUTT+CvsdWi9TuvTT+F7SovXqvXptpupp7Xse33Pvpr9/r210610TrXvtPYVfZ0T2/
u/wnbOZ1ap2+idT0SRXbr+p28m9uyM10RXbjuvq21Tu9Wq91V+/7f3110277XRvsdze0arvtE03U
Vqt7ddd96K3tE/eMj8BL+Q7bAvxjk36On/ZGZe6as/nwHAUX+bq+9tgMVSdEW4fskUTpeHvdWtVl
rOve+81P4k9rb+L5Pq1zQViSUmw4CpP1RSMSvPJ4KyIx6wOmkHjihn3XcKd0bnQks3hJ4DYmyRsn
Te4MyN3o3t6pGbzd5kiNei7kkT3xTInFhklhdG7bkJMdYYTYGWDA7EmYMcdxA5crnc2esMhtaNy/
pUZrUc1kw0cSM3iHKtHdzJaRFvODEZFZSCzzoOy+hGkdCSwAKWYYhsUM8M7GsY6IlUci6s0uq1lr
JRy2NYUBDcQvWOesmNidBGXG9pAjt6KR0b2xsKHWVzUjSViu3tsXxqixrFMPyen7JFUtgPURukxG
ea27H2WSC30QgUNSXPIgUbuPUEMqz0eJDWyWa10lbfSKUFBUF5TUTZ466CHpVlqi6vBLeeoMuI57
TOsb6ABmmQHiNUzKbSJxytCqbRgc8u2dWQwlLNX49Y4pQ1AHKyrYS2WWh4lNEfYWJmQVNVydZNfk
ahv6KZYog8Ut3RthmMnpaWzDx/GLwwfJ7YsvIAo+WMp8ffUIyMOoos4vYa0kvplOYLly24StgrZj
n1pCHRih4dByYFlzQfYvi5A+T9rDuNlWMt5QyXlDfrEne4M8nIFekPc7lJvBOxvCcboux52PjbYP
J76dgQpl/jUENLNUQqOEGBD2OpZ7GxW4hLLKe2FoMAUycCw4rZoC8sHGrBrO77HfYsGg5yeaajCK
yLN8nqI7GWZnKkGVI7zkOha14clgOkMDShFI5mLNIAoai+yi97J9HjSE1ocKVjSI+xvUnvljprnM
KKPmpIqtQ0qSc2GdCVM5YzzpYIwSyqyOkoxberwIPISqQsdHH2N8cblFYIEOULls1LVikS04Fhw5
bS2QeOSerktHumS2B455o5tiMaYBYcvjtni3KGCybsgMtPbWt2THMMita4mOzKCORWlgyvEmhe79
jlXuNr/63LNsT9zVF+axfqlXN2UgYArdXydfGertUSESNipNOXKm82CAfeIkd4Fjn6JtkN2VVvqx
6jIDa8cVnGONcDDUVFrFPLHBFxHHyRWrmSCgMnRHNbAM6d/pk9LJj1S6xkEYWLLLKXXU7x5GzBMk
4UFyaFO6Ml6SuZLG7hrFDDPC9w5MJBFRS5EMODwKtBynkZHjUm5uVZbBX8sLclTyPmkc1kLY91zp
HN3tWbzV5sR7ZoJHTthlY5s8UqRSywNmY+FZWSQzLHxY+Gq+lOY5Wp16dhM7Hga6uyG9Ga26bXQj
DyZFQuxmwmtTMigDfH0rGOfHVFMsjWEKFZOGhSRkpnBnwGeQajx3GL7G8fkiQTHLAwQq5OBImfSC
GA3zIMRhDghFQAi2qbCvOg3RxzWEcARDp7pcbkFzHsSZzejjU4loCdTSVNQJEkpRFicVEZEbNaMb
M3l61acyUUCEi7ajrCalo6NlbPSETsxWU4ynjZFVZG/EScggG6R9G0R9u6BsdXOTWgYlEHKITIPH
lHSsHAdrHEDALW0wMd/HHxCZxcxJe9p1NHNFK6NsFK0d3NtdC+WdxosjCYYxZ2EZGqgD2OMg47nF
1SFdHQ085ZOFEiCFjcy3Lrw6wBQyUkQmyIxXGI0WBpley0BWRyZafY2mPWF4uFdj8Krkx+oImAJs
L7J8lGqAW0RuVQTvLsTC4xIS5ckCBJG5W3IkqwWE8PGKqP0LUdtar2RIbQu2ryi4xJsHva6ug4VR
V5PMO2cyMiVh9czLT2A78Zg9wXy7gyr/ADcmcGenD7DdJmC4tELYpxp9cqm+srMi3ZHHzJYbp1t3
4wjSKWWvBaPGTXkFk4/CfVUlUbkuUg1Nba2NUK4CSrMxm9uZSIajHOyVlTiJAyKmBYiZsjAZZDl8
FoITo+cW9qMlUIAoZZyqylgoDxpUpW2RAgVt6JlvrWnvYzoGQSSDCBVFhVTS8GyBi34Fk/eAj8BL
+Q7bAvxjk36On/ZGWssjGDPnyQCWJrtV4nB7HuC6p9zVXN/kRdsb932LL/GtXl+v8vs+3t/F8n1Y
Yy2ufHDPx9xHPa2TWCcZ8UqNVOLBLCRLFNC/eimje6ORjmOVNmo1qJp1RxtRreprdN1repvUxuie
0xNE6tprR8lMxZpy4ITypLCROhjyZip64yjcOwUnVZ1Ys7bESRurXpNHLEO6IMeHJqRA4ThbFocV
XyzEHDmGdGOGq5BIrY/rWVrpyXGvbLI//g2tjbKKXFCaEYO6GeCaNk4xY0rVZLHMxUdDNARFI6OW
B6Oinhe9jmujc9qih1OO0VYIEY6yCFr6kAIYSxfDKM+wFgGgjiHOeNPMO8uJrJ3QSyQrIsb3NWFl
li2O2DBizDx2m0laU2A6xkWawNhbOM9Iiz5nOlMJZpMVIqvne9y67WI0lTWPHuG7lsO8AV0NozlI
wNyxiWLcNbyMMIW6S2ROUijH8CxrEGq2YZijKwI/pUOubjtQ0ASz3dzpEYRA+XgP3E3ecijaRu9X
E02gqkq65KsXlOVrUCG5AbkJoiAeAHw+Xh5IiCGcThxt5eaGKWHcfG1UjDyKjp78SKZCYhbqsCtB
oiGsfG2eOA6GeJkzWSSMSVrUejHvai6OXUthlPVlsPr2VJzSa8SdptVEs7oqwtssTkIr43EkqwOb
fHYpE6tjTiv3iKNMUxpKQtw7i6dKKrSrKcI2FgriK/leUmcMwYZg6yROWFo8LY91ImbstbBjWPw1
09clRPXxU1dGFNUpKTOlXKKwdIJK5JjTJkCexRklLJk4e9PKroaylrK+nrR+Jy9fVhj14MHFkfNL
wRBI4oIuJNJJLJuRpvyPe92rnKv7LKvcbX/1uWbYn7mqL81i/VlhvKwS3ro/rmUMysbcRuWFrnNd
HXrAS8khO5BHAPMTI9yRwM4j2qiBUlVW0wGqzMBqghQA2yyO1lk5cKGIdJZH98/V6vVu+i99twUn
IHRzu3cO5m8rVa9qtVJoSI1b2+9puJ1sZ2263dU0miyKOtGZLUMRpIdtFPCXUjb0LxZwTAQTB3uJ
HfMWOO9rZeaAmekwpUW1TQklxkNpwmV6lO9KjnYOqtile2RXaSSM0fMu+/WV7062tZukvx+mxeie
Zw+ddThVtcpPCVz4nEyCQDune1XOcizbz9VV29tX2tfjuNsPpxEraqxGqK9C6kBIJVjCriooGziB
NiNla0ISSGFrCpkaxqSvRYKRtNQlTyUotLeWTaAASfJIBxVDk6XbwnvPilhkfG+MqSeJzJ5Y1Tde
5u0l6LRY9Fk6w8ETISKEMw+CVkHAEdKS3lT5Rx2tiZwGWIqugjaNHPD2itngnJiMsLA461tjRx+Q
iMs7CXiFzDDNJKkFEiTgiBQSllFQCDDtKNLmak6mWgWOUQdnY8XpCxFqQRzj+Pos/OlxQNIKSbRO
Ik8j0eiIjtU2KrQ8PxYauNhQYyvgx+qiCLHZJJPGOSMwRIJYYyZHEMZLHJGyVz3tZvPVdqB81Lj7
6GirbwaLG5MerpamSa7MpS+cbA+LkI5RXUy7iRh8ZXFum4zFT0wOzkpqt9nXCSAV9g8AV5wIMrdy
UQQt0SzjDSscrZYIXsjkau69qpsnQuJ41UbpbD06LoqsDQ6KAgWM1OVFi0LjFMLGYT4ZsBRELXpH
NI11gXS0NLUF20vMWpNXVggEWc6PmkSawmEgikNlSQieTiEukfvzzO13pHqv7wEfgJfyHbYF+Mcm
/R0/7IuPxzH+gfY92xr3f4n+bMu/YCucPOQhBKwK0du/KxrRSi5Jki76ZI4hXqsUesz08EySTdjf
GQPKyeCZrZIpYn70cjHdbXNc1dFav8m1vVxEpVEgRVL6uXmja8ycqwMhhiNrihpYO0Fl9JfEjpEm
WIgd8b0k0aHhl6kBNwDNW18NzzUjumZCSGxwkM3p1dITDxOERv8AGV6rxnPc+eXa3uq6bl7GtwM6
yBJVkcywmC0EhQ83DIZLDLuTRserJo5I36aSMe3VNqOeYGxubO8mEr6ypqWA9IWdhKDNYTMhdYm1
dWMyAIM06ec6wCGZCO9jZFnfBBLXpX0GSWV5YTW8HoUGhph7wF+PkRiXjj5rO7r8fhhrSpxR1IZe
ywHPMFdVSHxSpJtVYQaMULb3cKSAudY4vN27gTD+HNUjZFPk0UbWgFQLYuoOhlKjSFtk7iRufiOU
Kf8At7Zr2PeeO5UL0/pzJaGvtPrbl+Tj5oQ0mL0kePg8TfH4UjI3tv47FSCqUHF8MIDrBUqoJpLr
IsnyGk1adaE1gkPMqPXQq6ztha+BIt9HxSSP4tRUXw5lZa2QQdgXXmWeIClUohxbwoHlsIyiJLeX
jQE8QTD3ZMaxg6uUf64CQp7R8Zyct78pPw6sa12KhJd3dXNbxWENZLb5RWwcMboeaRrj5QXGcwPD
XxlltNGDdkFkJK4aJ4zJ4VtMYqXDqU5I28Y7JcgoqNu5K5sKt6WV8srmtFaRrtDYB0eU24K4hV52
YXWh1aw1eNWbrBvOm87chOkmB6NncUDXNPOljVJa0ewjiKcOQFjoN054WRYTVH5NCHWTUQc17fY/
zFTJzhS2Es5NFaN3jBKcmvDU6CN1mLYpw4qbFaqzIoVsKy7v7G6BEBsLaCuoZaodQqcKxDsxHnHF
W42/ORVWbIw4CYIROdLFJFxuqhKyjNTLojJmMtiaIDHTRIcbuBQbZ2RgWMeJoBLS9IxQEcvTQSl8
iQo4DjJRxSSbaeiycGq9DlvldLYFi1XAyilpYGllkU7BrkgkWWQSUcoQTJIKAsiAhj2Q+lF8ua0s
O5nUGsxW1laCHEXJIPl99Nj1bEPAwrmCCojYHSFwRxK7l1ZynOEO5fZkM2M5PDfSX8WNsxed2LC2
zz56p92M6M0rKIcYmgJrmLKOsGQyTTSo4NkCmxTDx5O5zHROdhda5YpNxXxqsmVqrHrE+SNXM713
DkezVO1e5uirifuaovzWL9W2iWLjJJWns4XB5ji74srOHwOj7fj76LucHoqz4mu50ebry0nc9v8A
n01/l0TX2/qXTuFucazikV3C4fHVKapg4qv6PC5lUbGkHGUm30SJB+kI+XSpq8ikaRKIsIBErSop
XxyjcAWeXjskRyOa+Lc397Xr0VHdqrtb0DJzuk14ocwpNnYkES7qceCeNhExHE3FRWSab/V7HVpp
xoHM4ZckRIse/qqiuqKaVHMRXK98caEwtc/r0WRm8ur01AFxlzUKCEsctuouXYSpeP0KwcxURNkR
3AKu5zEhGnj3Z0QUjhPRW6pgxuP59f1dVl18LVuGqwsJLBbXy4zfXLDq+e4xK3N5gmSuFVZJjSRe
BLKkQ0e+xzOyIBY3h9uNSXdSBVRmi0g/JjzYtT28yI6oqKx07pCrOVu8Us+7DCOyPcVJXTAGFZBe
ZNB6CumspCvKKlxx9TdEyDupG4zIlFinSVTbxQZBFz881tT71bA5t6O7itIcfT1lxaGrftxkejqy
sVtTTbN1W26XlbaqyczEVGiquMYQVLk0MQ3LTiTrGfwhJWn5YpMljZ5VnodaBPPiuPmD1GOZEUE2
EibIrrG6fi1w614ajssSLQ+VeMPDYJEWTF9Z1d9Y00M1ILY5SEPXrR1RWRDgF1Y5kZFoPezcQa1q
ZiSKyksAgWWEKnEj8EzlR6lKPJBRy8hvcUFvixqxlKRkGPraKZXxrHby2vp0FQYQGa6rbXTI1BXG
R2LZgorGlsunialMPx+zDFo8QyHJnQ2BVzkoppBEmM0dqWMkw4QMcbDpIx3cB6is4nMqtACPll9j
wdlYdl6V0wVFQBWrw8XyuqrMfDKByvFrCUHkwDZIp4Zq4SzfIic+9Z2O2MhsTYoL6vs7/HCLkEFk
cM89PZlVsdyHXlPKhjlIgiiKUeZSBIT1lj4U4saRvix+rtskyUc+8ySapymjrMKXK7PG8WDoorOI
OO2FqMHWZmS2hYMdtNWtHKp6yaIIUm2KALmkymoyM0nG6C57HdB0WUBSRvySDLIcfWztbpW1MNiB
bwNykVwotXLSgDnVc8JIE8UskEeKEW1s+yB7IWKXWUjVzxaqGHGZK46meIBWzABDFkCy1mQRwmrb
l2hfPAMlhmGjmmg2vasTNVfZ1+ZYfUU/Y2SHGZOl6C1p8eJvj+ElT6LUSvisLi4W2ZbNrg0reGTE
4ZkkSyipkl3ZcDLeyAPcY5ZY/V1tCHh+P2FtXhWGO3bcdqi7exBPTHgC4x7/ACDc6Rn6SGEdukj0
XZHJyWYoW8Mx0qfDUrqXoIOhyexBBHHAMFrHZHJdVotiMU80i9LrzzoS421oohIzAfsgj8BL+Q7b
Avxjk36On/ZFx+OY/wBA+x7tjP8AlBxb83Zb+wB5UlBJBjFndNw0ke2N4Job+C13pfH0L3onSo6N
jk33xyonCewUVm5DHvr1uc975JHukmmlkeqvlnmle+WaaRzpJZXue9VcqrtZmDy0x0M0iziOIcRB
cQNaXEa2EOXgPhiJjjjfWjTvLYzl3sXeDRjeEGMDUZQ4U06JbNp7LkINrZIomGS8wsYkcbA9JHh7
s/EmZFFC9SXPRjrLGZuMNW2dOXRyKI5jJ4AjA3gu5Z80c8bZYoJPSXSxTMRyNV8ciatUMQ3NMtNO
qbEezob2WPD4LWiIgCJrXNCYBiIdOXAUAYWITFdVNqj4yHOZw5mQyRVbq6/yOpu6yW2mXKA5KSe7
sXX8zSrxtnHa0dlRTw2ZsIpjoI6WCIGUIOOpZXiwNH2TIFvMhd+3MORSVHFp21U97FQJja2U3Dpm
Wj3y1jWtcJ0olbFM1swoQ6ppsNgvGsVqg6wStGMQpsNvD0esTwT4jBoYGR2AhEEBcMzB2xIRE1XQ
Oj3o1utctyYi6v2ADH5OVDiJFt0dW8blamEF+KeheOvRCj+IxcddPM6wLllndM6OSKpfjmR5Ljc1
ZSh4+RLV+huRl1W15JBgcdkDa45Z1kDxiDbB0D6MGm5eI+cSBIgoxBxrLGoru6r624t762tUhHxe
wcf6IjjbE+tmiyDG7kNK9CTXqPwhIzomxQIpz1SR0lAPBZ29JNjJLCaewq5AJTB1bWF0z439OV1y
HO2auNIgfLMI8pqv40BEM3pm1hUtMuXD2WDC9j+eSQoV5DaYTpjhlMlcD40d02VxCJWyjvVkC8oi
tl4s03T2ThgFn49bnUYZdW2qNt8ZlrH19jNx6gixjkkip68Y0UWxHrSo4EncCh313tXmMsbSjual
SOjLylkCbYCRGtjYeKsNoDaVJoZ0cMKTiWdYbAksAxkDITxBCoKo5hdoaZWR5UjyDZAVW0JzKyCt
bw6wiEAEGQiUwFj4I66GvBgZLNGwPc4SRSVxVnfXNQyjscZqKi1Ir1Cx6htY2QGV9Y8CsAOI3hIR
gojb0y5shxR0igNjSc1SrBQL7J8kvLF/Y/rHFWpeOiziUuL5mLc8ULo2nogYiAhSLEhZHxSzlLFE
m6QSqJLb1BGU5JNJkZak5JbECYWYffRchFWR15op2Hk0MAA4Y47IIqulr5Wvh46zuImKknyEOBHJ
ALg1SNCjnvkckUC5VFGjpJFc97kY1NXvc57l63KqrrtifuaovzWL9W1j4fF4laczhcLmOJvCypw+
B0fb8bf13eF0VZ8TXc6PN15aT6lpMQCNJI2yhfDNMFFv9qBQTpJHM+sEdJul1wUiStKtd0ivFTpC
OQGKsqWsbVhQpG3cjUaBgr42cEQbhskGSKRkfL14A6sa5GrACHEqcMaFrOax6Ah8qWdWsoNLYkSk
OCSWZhfamkVb5WbsrOJGyzhVU9MRR+Hx4rQjNRLQcPotIatbGRr3PJU/jlvextgesUzgn1Qzn/Ws
RXIrwh0lHL0Mvsjx+pyY0oQACFuRVVXcD1YgClPZBVRmBSOEaROYQQYvEe+eZzNXJHFFGzEKyIix
UXCbFLClR8oyu0jr7WqFBJVBGpICGBbSDjMibBOjRg+IRKrJuPk9qy0tDpcqsB7Isc7ovlgZhgIK
yKOu5GsBIbCgIgkCocQfIvLMk4vGkIkmq8f5y6jCrMXsMPdJEUIwizo7ESMZ8FovIrDO8eWGA8SS
KAfgFxuTRwZRwhUz1yvLVu5LwTIY8n4uPNtxbESnTH0QcWPHGY7yc1PvhEAz0Mwr0lknSNhfDIjr
3VWS5XVW1adkpsWQDE0hVrOzLbDpS8BNjt6GypywiD2DERcapUoZ4Y6jlR+ncaU6S+yJRTyqiyvq
VJaZlTkdxSwBQB2tojKVtjBO9tZWKYHSWFRTncjEwmskglLiJrdwixXovMbnNx96Ubt7W86c5seb
QRN6vj9EBnLxM4ZLeGNxC5dyXjG5K2QjnjqetpJYldHyjRas20OHkjYkSTIQ+W2IbM50743RshRk
UbmvdIGdU5PlFAeEdmBzC6z0MkSSeja2HubgWWO8xq5F5aMsWFAVjgjKhhbuSkzucr9isPrjLWkB
LGJHfYVhbHXSOOmeRYGdIWcFks1hYzTESGnFREETykzzq/juSRtcz0a5cywpUIHproaDCAT6urLE
gDLpBha/DBaJ9WQwUSXhl0xJIxAgswRQzoI92tUUq4Hqq9KF8mPIUPNUWh2MNYlDaWbywyLiWwAW
ER7pB7YWGweCE60gO4DdlsYDrU7gCl11KJYyhSCY3VHmx2BlXT8qAISokxMAnXak2hUEAQggxMIk
XBXILMeQh8+SWAtkc2Z0boopw6ivpo2iNZFG9kSi1sD3pNJO9Z3Sua9sasiYJy5dpBMDldvlsBcc
wqEc3emnmW1bIqhrFLTGNsiRJBHxLMkCQStKQ8Yc2MRq3OQEY9XWTbirw6cit9DtdYxEqaLLC6Gq
hyAkYE5zzK+qs746nBm5fla+KKuq4wvsgj8BL+Q7bAvxjk36On/ZFx+Oxv58FwHXbGvd/if5ty79
hFzEzIePJwYVeqNSSfhyTcNHr2rO0hk7/u6d3Xu6a9emvc0X+faebiHR1IdjNXyQVE6wWZCBQcW5
tSCBIjDoKmi13TI6wWYrT66V7mog2zN446KececyvAsL9cjq8jCF1mJbVnnthLisUCHks2RDzEIL
Wy80ZG5JGjDWuVjxc7FW4+XkEQqysHUuAYCU9IuM5sjI+JExNHaLovd6trgLKgKjGp6epq8imMGy
B1tSrQWnSTGmyWR9Pjbwphpqg6MuIwKMeKHly4iyWPfCwO3nzLF4ak9Z1Bspr+njANaPKyAnkzVK
5UtBiZIhZnDSyJHNK0eT64VNg8vubjFsbqbMyWGscXldY9HR+EGFtJ5owxQL/l3cQ6lDIs0Fc1qN
Oejl2aJYZJQglPF6RjHLtq4aeSu5UsznmRykpIoPArrOdTOHw0Frj5vBBzkMV3ozxRGNseiHPXIK
fcbaexWOVDe1sndWgnWR/wD06bNxx97TtyB8XMMonWQDLngcHjcXoxSeclj3WvfxYoeDuNeu/oxV
2nEpciorYoWIckkOrtq6xIHGKa10BE8QZMs0QxDHxyQSyxxo9j2ytc9q8PY62jy7F5KmsnYNY2Tb
+ocACRJI2No5ZrDXjikb0sTOGU6FVlc1qdrKjohzgioCgjIISAyxZYSRiRio+IMRBPA+aGaKRNOE
RFLIKQiosMj95P2eWe40H+0ZWm2J+5qj/Ngv1bOLd4nErzmcJYUnSXUaZOFwXA2STcTveCtbZLK3
ea0A3Xhu+pcP3N3iWEUmvA4fFRKesTiLLyITZndqkCTqXaMRsLR+fY+B9bX3NrTythshBZZhFl1S
JZmQTPaydzO9ZvNRVXX2NF1RV2uI763mEOryYEhbXDv4SjkNni9OgkMnIfPGWxEVsTmpuJqvUq7E
PInmncwrRrp2vSVIuTFkRVif6dFvPe5yQyKsiby+xomy4zT1NafKABXW95IddyVRDKyzLNEgfQhd
DHttTI+j5nkxGm1AcM04AaHzKSTOAfcMyqgEr6u1IqDiT7ukhghngLLDHmdNHYzQwjXHIyl0zyJo
3lhOQlGaaxND6QynHAEPjDmCQy6rB1MisuP0Y8Xikx8y2y5UrkHQb7DeXn5aSTl5N+IZ5dZPdTk0
EcVDJaiC2zwbq9ApZbRgTlkJnCr+ccQ+QaGSMh0EgvGGVFIZahMyegUyjhILuw23Fa8ulEF3UmJt
hUn44AsOvEJlL5dB95Elc32DbuK+x+xe2tvD6YKK+rI1yKagHmlOAqpI5ClInimi5KZsLZpYSt5j
4maJriUMgqLDlRcwDSuM7dDLSmNuRY9OV0mQmKvIgYqrCvG4aIjnLuKwWjph7GysbW/Eo4Cbbo8G
epxcuCuu8htbCOtsZawCCymQEeIeutCCHyATo3gGTrXx2lljcUmRzm9HC41V3XPRHEqRPucnbzVg
L3wurBprZXT1Q08cMb4ZR2SNVdnZVKUjKNlR068xUVUbW8pz3H3Wbzl+t+23G7zlXtWoq7SWGSY5
U4xjnRpNo2ymypCrCvhh4MrI8jrpaSvr6qTknzEFSA312GFILNDIU5nDIfWisy7GHk3MksNQO2+q
nT2ssBMgU8VbEhXEOkhMilElYM2V0ZMckD0SVjmp0KNkVETdbhb+iILcCWzVoE8whruQjIcVuiFD
kDFLwtByIJoZd2SN7U6YDPxyC6ixsfIrHHzMmFj6DiKCQ2Lp0yIWcurr9xzXSWc9RutgXmGjPTRi
11Obe0Yl1bQpNXVEtsEywsGaOVZK4SWWIs6FOHLpLAOqKkbl0TdciEy0F5T3kYc6ilyU9mFZsFKR
N5RiXhTTNgnRqoqwyK2REXXd2u8eQGQeOtSTo6zdOx8V06vlhEv0ghRjXQdC2JIoMqukl40sjlRI
+Ho4XHQLKmsW8hkxd0cJdhTJj0+MyUzJwrSCHi8tM9trI+bm5xHiIG/fik31WFLqDLcZmp1nnFS2
ivqqSsUkUWU4kdD2FKKs44UExk8XF4kQsMpEjWxRucmN0EeQ1BJeWV5djSTjW1TMIZAMQMLC2GRD
uIRLZzzysqkEhIaa6usmtejxHNW14eV43J0ERCJd7l7Vu6HKIJcGONa6FL0eROYxwsMJfCklJa6B
jVlRW7DnAkjmhGQREiGCTRkilDTsSSEgciFz4p4Jo3NfFLG5zJGKjmuVF1+xCPwEv5DtsC/GOTfo
6f8AZFx+Oxv0FwLbF/8AKBi/5uy39hXJEClgsdivEgk3eW0dV2MaSEcTeTgpLNH2yJv726mvsbQC
zkSFyRs65XLvJq7TSGCR+szoI+42Ql8s7k76Re41YLudwQinZCUG6ZHJVWomSvQssQhW6DIQNY+E
aU13MovFk310dtXA1mU9LD19vk1lQ4zynMGsdktdY1qAE2STTltCrSbexIUg2KWaRJt2eZ7YoEZa
YiHPEhZOHFY6JLLvpA2d9G+qhllRvbcDiKkjvZ02s6Wkkljtz56CwnsbfIMosiT5sdPAsBq6W+Kt
p8iBq5nBSDwOrzxm1zipzQB4yppJJKG4IAArkrQ8tjNhTM8pzk6YnIvQtCCZDf5TVAmSekUJURcM
mjBI+UaEkyFEJt2PJa6PG7i0w7F7DFzq6zsT62nnW06GWW0Csoqe1mjKFIo+VSB9PxDR7GVJZq7d
3XX1UOTUSqd2JR8DrpFQgRkNg1cjcQ9QoRzlBpHuuRGpEPPYEMjGbC1vCY1Fy1oMNLA2/wCxSFgN
Y1zFjaMcL6ItWyowFEjrP2zru0j9MXlJdQPS2bVN0caIVWU9vDYiSuyfImKMEmKl1E1TFiMIDMeI
MfeGlWiZSWXLb7siDcs2BkI7MUonl19c6t7G+V4TcGVizvlQ/I4cf+vK57xK/nYebrCyCHErXSES
zQOl4j3v2oYTK7G6qzxe9BsRa2jzfKa+vshoaezpiYmXtRQUN5jBDYbOaauUCGzbw4Whn8cWWeJQ
a94EIEsDZHTDQXtpkjUlnmeRK/py5HFuLV0sq70k9jDBJJvbju1amv7LLPcYD/aMq2xP3NUf5sF+
rZxbu/xADm8PhcXiq4abtOCoVikvE18CtbZOkTVGAGd4v1CCITCYOanaTNDEys3JZWQ1o6RySPr3
EPXgVqxcR875EYcW3f8ASKtQZ6azszjQTh5BCoSGCRsKY8QaDe41XFXExOVwxRirCRH6YeYxEZEy
rhCzKHsd4sS+0tavhxLzltX2y7wBYZBtHLYT3Ex9jWvkGK6LHKAJJ1lihm6T5UYzHx74bo22jxVj
LMV1k48wjknVQAFvfNcKMlfc2CNNd0e+QswdixNLIUlpIwYMIddjUcYc4JQOXE2dgNlWLkxnxT2E
1OAPRFwE8QeJkSQeiOrhPiV4h7SRFc2QuoGkrOSkzi+yHcFy/JMdLuaW8sLy1YGTaU1GtpQT1NhY
1kkgtUUTFdsCfDPaVoxBMEtpVzLQyFHdh2t7HQpC81IyC2FTI0kn3yhnl9D62wCpq9bD6yk+ttYx
9rQcWPFSK64yjAspLtzyLCG+GKxWbF4zK+CFlVYQHJOPRSzVdmTZAOGfZT18tUsK9JuygmzOqyH2
WMdkSgCNIyXJi45WZWo7KL/BkivWhxIStCEirrTodLAs1sfNlylFOkkdkAlENic8GSYBFhhLrog8
aWllr+m1BlCYJUHRnV8q3SqoyrVyVzxYbAZbJ2grX19YQHBfBJW2FMYY2Va+O9pJ4jwFL3U4zwZy
w1EsWRq+fo2eVEbq7tsTIoVqrGwxyjOx06rviiQAcgBtlqFspp7QYG3eDYdIU4Zr5W1FpETC8+ok
jRDh7IGgFbeQ4dX0xmX30AOFRU5LQbjKLYiUauDTJMSLrXVFJSmG1w5MdRXEkSFvVoYUMaMfc4Db
W0pgZMd/U1lu10XSbKS147gXFRwA1wMJ9bzbxo4AR2AIOILwWxMco8NqdbA4RX3D+x5lmEx3dSXY
TE5LPfDAjgmXMU+PCkUYADgpSI65lplai9JEQQEScFSDKWEUoD0P1kWHugFdkmRUsFWXj15FZWj/
AEPU4K1WUpZiigwALflRw0kwjZQwt6aeR80yB48HRVPZc7IeSPtISCFyI6xjt8lpWBSV61CCQxq0
mPjXCXkpEteMyq6MYx3Msx+iEkoBi6zsWZxhB0kTiYR57jKR6XgFMdHWpJKBz4BhZ80sTCuLM2do
hE0ku5dPHDx+2pMn6NJsyjbiwrrmtnBoBaN9cKJFj9kNbVbuj4ShnTWdRII+wsU5ebRjprMI9a6K
OFI4cTomXx2Rh0wQwDIoQ5ckNxuiuShXlp1MPCtDAR27sdkXE6EQPEDkzi2tTqYox9uDYRY6JUTx
ZHEQuUur5qjFArySWSyIba18VpZExPIEHQtySI0mGmaPNh1KTimBZPhlFcVc1hOYWTYdCdD3BYpN
HDBWtR1VJOZXMnuWiFzvnhKskldEzGpJgaUyzuey5WXVfWWeXZRlAyS13Y5ug2NscsyOqJu3z8xV
8yIa2pIbXfWqDhOQVGuxu5/aF07Sc+kyIIewNEGrY86t6y1c7H5m0b1tJKro7gq04Wk6VImlsHzA
Oeo2zcfJGqZng+hgMa9IzzN7yOyq6HLqO7IjXD7yvJpsWU8Cp4jhKU8wVp+4GxYwHcWH7EI/AS/k
O2wL8Y5N+jp/2Rb/AI6G/QXAtsX/AMoGMfm7Lf2Hc9jT76e0vtp9/aaRU1SNkz91VVdepV7i+x9z
ue1so5rkIjV28sM0AkkT3bu7rFDMMQq9X8LXrVXd1ddl6MhEr1kBUl3J42KKI+fkUs+jHlQywIpq
iytJ31i5bWNerusU62sbAgeuqgyDrCfhMekIgUcks8qxtr+JLpHFJvNj9jVUTXTUkOvsrSI8YeKw
fW3FIfj1i6vnc1sFkPW39RXGE1vGjcKtrFE8FpSStWZmkbXa8zNq1EdqqCtVrH6K1U3gWdc26qzN
7jd2T2Ws0lE4thxhhxyXTOAkQJ45MksDGw2a1/JFP4kCqSG0hXxRcM0hg0M8C7eqp+91d2gitTvO
rwCvYnfemPZw0Ri6p3Natbi3eEl3aDUFassKOaTZlxzyQBLu1rkhbNGPJK4mfSCNI39bdXb1JTWF
04ayySckSmBWDfebKIJx52RcOuckKQjs5giYjSBivaxPDwMampcrepVTeQRqdr2z27ij7zkiYm+2
SJUic7RHatTTbqNmT/hdEaIi7uu8rtxIddxXKu87g8R2q6uVF029WTLp6W7qG0113V1VoL96Vkna
6elM3F31Tq129VkfxMF1av8AB9ScNkvXH1SSKnW7q7XXZjuPJI3fYitmjjaqpI9IW7jWQxP1135N
NVXRE9hyfscs9xgP9oyrbE/c1R/mwX6pQTlRjSx5xnqscEzUaRFJEsnAIjlHIRVkTWEiOWF/ckjc
mu91fUtTQholhq5GsSKaKZ6lLK7hCcQqGZsVfxn99xB59ztf4KaDWcDVbETGrkY/RdzhvfE9ujer
VHxuTX7mnsaIyKOUmWMwGW0Dbd4tkVbDdABxtmllpYsgqAG5By8M7CJIaZLCZkE6TNajiYnvDtUk
EArSas23CnDrpN2SoBqork0yGAMRz2CLVwRSyP3E3noEF1nyCC7TiV5BsZ448Jzq24o7rH7N9fPM
6GGxGrr8CtPJreJviLZwQyANJYrVma5r2vmKJOcscNrNS8EUGxsSz7hrUdNXVQAQpdhekjxukUke
mEskEcIZFK9nRR/BrJJen3TXDbFwYMGGZgfd8KqlHYe4yjBo5rmtjG5wLrsq8fXnB3dfEVXCW9Ud
DY1x0aTDFCv4o8jXOka9EmdonayMWB8CsSeCdvLktRusTeggzLDnnn2dZBIRj2RCVZllSumbbCV9
6XUjUdlMK4QtZYgrCaWbgEvh1bCqolRFYSSEvPkrISnVF0ygJthuM51WJlMlf6GirOCYaRnJBWRJ
kBgpgyRSFClIyz6FMYUtJbHUtnvRFQKHaV8jojo90qGDf4MvFiUiDeGn7dIS13HNRLnH7COyrnkG
jMMijmYySUEiQOdG8Xd4sbJ4pNZo/SZl9Mh77XYiiYRraCV4dqQLwpk4YB5Bogk/GWPl3cUiuMj4
TJXTM4O9JGxkkTnlwxtKa8KZsEyzgmixPe+CIhFEnJgigsIdyZrXEgSEjsnSUV8rSYJ4o/s8j8BL
+Q7bAvxjk36On/ZFx+Oxv0FwLbF/8oGMfm7Lf2Jf3B5/6lV/17E1rS8gr4mW6hyE0lUbrPIwewkY
CllAcOQxhMVfOS+YBIZY3NZG2RrXbqq4AnKyBCn8mwe7FvDoOc6EKg47Sra2sbRJuQFLk5dCkG9L
mZwtI4t3I5gxpyCbjCLaUcQNsxE0j7OjnnjgGXlo1cruaSFqe2qbvbabR2+IV1uDY43gmS1lcXcV
h9CQTk1uHVvrK0SnyKvBOOQd1ah7CnwR0XNrW8Gc14dhyXoiGscyyV9XYgqZjB2O9kWkPnjsx31x
w47M8yHKCbkmOz5CxK6ILkDAbUlRBsghuCmFXQ0ZeRn8HEsQnszB5bAl7piMoyOTsgvxpZ2ycO7i
x6eSOlEH3LEYdtKOECPFDWsIxaDGbHPa7E9b3pQsyq7Lt/kLLb606MfZACZFQ9ktlUiJe8B8xRVK
xV0NrZta1Yex5Wl8/YRS3Tel7CEEqvmYNPg+WhraTjrC59E9508XLtsUgYFYSRwypwkazbDsnvKU
ltvUZWlBwoYmqyKto8Wy2E+8jejkUUTKb1zUi53k2zV8WOqqdTdskdE/OAm2k3Y+miFYPn45VGe7
OETIq+vPy4+8sLSWuqpkZcG1IVZis8MTuUqWbztckx2D0YyU/o1D6MupjOyNkdnVVK4kGeUTA7Hr
6pzG/rX38JNVozIUCqrI7Us0qvhihYhWRF9kIexF7Esc9MVSdOBwR5SMBZsvyMr6Je+Fpj4EqC2T
ZQ/o14iv6DJltFlIVpNhcZCEFCRjzqMUfGM6vaQ+nkrUjshzLKgvWYcE99v02OdPlmNTXAq7pApU
IKVjB8f6Ynu57k2CmOuVv7A4+ybaPdXwyRvQ2edBWMjgjTgipBDvb7+Hvyyuf+wyz3GA/wBoyrbE
/c1R/mwX6q8WR0EXOVKTSRufGrYOlA1nRskatkZvQordWK1U7qaLtPJLGyQhssnR/N6AzGDqqcm+
zibG9K2SVHJxGsifO1mhCgRTOWrbYVxhVNUPALQdZDrJU5prxh7CPlGtBlIZM0M0PnGzhuYwiTlI
l1cKWXeTiXNEWHPM2RJ4jbiWWudHDPZR86GBRos6tYGUY3jPFaisSLqjc1iguHR7WtcfA7fbE10h
EFiWMURuQNZGxJyoyCWxxtbExJt2NjWNa1vYnpGUmRAk4dytjkhd5jt5jnIOhx6xqXVocl7VgrdF
WpVm4cp9XzIMdbGfLZmDTT1iGdkeqWps0jxPBcnwnDUaPPJNdC2rTrdr6Xdi3ymurosWpUQfjqlh
WEQt0dGqLV5XX0l1CLiuLWVRG66qLTG5bjI8hJx8Wox4QG7BBtCYlLBHetigQ9TGUYByhhhXSEFb
hd3OJZZADTU13SX5VXXlWtpFbZEbQkyZMlVXwzGHoadWmwW/RYJViP0kNMwSOpjs5R8Fyl1PljqZ
tJnNe6aHCssMPiJLKxFwqz0QVKZfVrZujjd3pKuDR/BavbaMXYOWCasoILDJckvLOlt6aa4NhBub
0i2grgDKvJQAaQ2IOafnnuGvIEs5nIxNwdEJGtbOO8samXsk568ekfWMcuMWlzd3bKLMBWgVolpL
XE15ZgRr7k60BFjvQ7wYkauFkmbjXY4bj97BkFPYYsJakS0liPQCi43fVlgXkY2STjTUZ8ZsVfEd
WiAWJ1wws4bpIQeUW0cFa9F1pwqZxleZ0dyVwVEkpAn5jfXdbmMSTSCaftBYXUcVizt3ny43FwXp
FIi5kBj4ZFfaD23ZI9DQnKRxPj3sgvZaRtdAakIXBdvjzVu/Gte+J0aOifGrtsjJxWHsqDiG03Yo
r4bK+jzKDIN5nZBOfk0IhuQM6fbGLWFzTWTHuUIcaeeUVraeSNVyS4Agy+5rsayaoGrqF5l7avvc
bNwegrCWgKfOW+xkByBzbWeyfzk6EiXXGm5gw+VceEMyfKBK8ehrS4rWqx3si5kOTlstyaXkbDI8
LyKsaOM1stZHWCZnV3WNNqmuEBFHaNYwE5cOQmTWUXHnJ9EN16PaoBXkWp6w0dfjmVsbj7W1gyNj
jvMKe6usxWQyFCgOeNzn2aR+Al/IdtgX4xyb9HT/ALIuPx0N+guBbYv/AJQMX/N+WfVknme2OKFj
pJZHLo1jGJvOc5faRE12ZPJxhQ5ZUhjOKUWMdznLpGrkQp5MLZOrtpx4uGnXPwkRdHCDWdeVJKx6
LCMaPNKrN3R6oyORzupvdXTq7uzrOa7t2T8yQVE2PleGPKTxUkdEj4XKi7s0rWOcrnRtkc2NWtXT
aGX0R37Xjv4kSscC1Gybjo+Ju8puOk3HyM33NV27LM3XSaTeBroSGyQ14o4cMk0DnTLGPDHA1ZHM
IjbvPZG3iIxkcarruxtau7sqLNEqOTR2o8q7yK5HqjtTOtFVqbyL1Oam4urO126p4va8BLppoiKm
nOaLvbrd/wDhqxjn6uY1UbpLA3c03N0Z7dxU7j26F9q9O5xE0form72jnIvhofZ0+t5ere3N/T68
6uJw2cXTwu6nE3ttUmhRddd5BpEd3NF7ZC97R/fSt13ZX6ySI56q5eqWHuaep5e4mmieq+43dajE
7jGtY1mjWtRF1lgVV6nOUaRXPTRybsj1L3pGdsvaPVzd7R2m8iKiJzDNGuRzU4U+61yK5UVqc7o3
v17nsaN71rUSKW5cWYyLc3gelcjHqDEjJ5xrbSkEvoKe3Zx+tY7QExj2aQvasKJHt4WHutd1jyL2
zdE3k1L6nuaiNkenbSsa1kiuaiJs18kyP3Xb3VG9HOXVru3kknmVU3mNX2000aqIq6/sMq9xoH9d
li7Yn7mqL81i/VmbHBCRJw3LDATIsQ8szE3oWTSpCSsUayNZvStGndGmr2wyKm47udzufcT2v+in
sN7iL1omxVn0ndATHcHmoQpwlElfCMgbZeXOrzWslcIiDTPi3ONB6TLvx9rtY1cheaW8dSVCKS17
sOkDaRNVCktSKI8GLVEAsY43O4DW6vlYmvWqiwVEZkQIhNtXoywfG8xCa+4PBPWaSCSWJ6uPHJcx
7JFR0atdo3XdTueyq/xr3V27mn3upV0XXrX2evXu+2vtrt3P519tF/j7nV7X8a7a6deipr166O3d
evu9e43+RNv+9fb1/wBfd9vrRepdkfu9siK1HeyiKqOciL7COVrVeid/ut3td1Nu5/Ov+33fv9fd
27mmiaJp1aJ3OrTufxbf96/7fKuq+yu3UmnsaaroiaNTRqa6NTRqaI1EROte6q6/vCR+Al/IdtgX
4xyb9HT/ALIuPx0N+guBbYv/AJQMX/N+WfUx7D6qCK2tLHIKKqun8VWjUo1vYiA7rnRovGtVYW0i
MPqbBAiTFuZxhYiLVOZYI5YY2wyyO3WOJUiJBB3ORkqohhPCE6opF9O6mPXtVqiIALoazrDYDIgi
qvKYAJN2QRybx4sb6ncH4csivjAt+bdO+SKJ0sAJAVQXfWo0EEEp8jK9ZrVXHySU9jC2ISA2lrWN
dE2Zxbnuk30hFlRInI/faFfmVWP5dV41VXJVrhmSOGaMQJKgs7sgq3GwlgQ31VEASKA6wGhGnhsS
xumqRr5p5uyHdQWtfYVUmR4NU4uFaV1xC2jbl1VhUFaWfNPkZa8hWjXbCbeugHAmtbVhhiWFZz/B
FHxts+JT3i52Jic97HT2yUyiHYbYZUk3QKZFIWNaALAPBOC/IyYyYHxz8YLnmIHkTlBDtMYDx3Ob
elM5CKieUZg5AQZ4qFLluQWBobDZSwzLErEsaiicOwqvS1Fla5ckDP8AQnkJ9ZRYMdXkUIhFcPz2
bZIbQx88NbZRIPyoLIxSoGzX1VHZs7eayp4TEkB4uX1XRNuwsiLhpDXiIUI1WvGM5GtyfMhwd5r1
gcP6I7B7njuJVYGkMGh/xmVe42v/AK3LNsT9zVF+axfq74j44yHmVg8b5Y+LG3m7IQVyvjRzFc3c
mdqiPY7+C5rtFQsmSGWN9fISObGPHKcizBprPyCixyPsWr3I2DROJ4uokg8ZscozDgQhpJJKyflj
pi+FXRjzbsb0RrLKavUlkjJonwzRyNgIjkbMPJNCrXPtzai85ESyLENIFAyHBhFRjMdGrmuUa0ns
TENUoQKdFZNIJJXd61J5XcOqbaE85YTz5AeUTvwyLNLZZDbWKve8aOIZ0qoUnGUVjRVl3+W9J3F2
orL0GYZROsZ+xS5L6hI41/fo7OcakdLkEfoVplglcu7O5vTN3rO9/pvapNIEZIuO+h+0zfIsIHo4
xD2ZKHJQvux1tZrZbWUI1ZH0MxpFQzHwXBVpjJelZ1CcpguS2DcQJW67GuVZnWgVYlu11UdjAQc2
lmTNbTtsa06ctsZEcMVQRUkqytaXau1P2J6WXFjxA6zE8rsJqUS0jbWYzf2BwFlDLMTaEMLIqYRl
uRrljBWWteDYRJjwcywP2ybNnjhlBAw39pQDwrMLzlLUxTIFOaVIpOnSjhJbBpUIzGQVpYycrJLD
JJNlNlKbiNxkHoV7EwME9eDZC0yQ5Hnt1XfXNe66sDWPhHtJZYJ2WqtLYgxfLQse4XbIH3MGND1F
dk9ZT5Xe1tORVzTlHYHR2QV6WjrWwduOtntomQzOPIiCLqIebVoE85NVR1eLClnJj9VlV2JGNXpI
gF5b2I41Xv3WeY1PVT1gFfwLC4Fr8tZJZzOd0IDFGOMdQYvj81RXH3Yd1Zrb3teXbAxQUi1rJK8a
rCtqGYyxLW0ZO1eloGChhFzLCV1NZfyDvxrofE8ixbGLCqJBsenL0nIB6GZ51ZYMuUFqU3shhjq6
yemupLCUCaJbGBS2uEFcr8VgqrfOs0wGvibUW89iGRRsyl9TelkeiAcYuFX0DILGlhGDfM1zjBro
ZZkBF7E9YTa01nJkWK2mQWtmbU3E9k6vpfQxwwmOkyaRSrguO2LiItyJeCszhy0q9BpQzbSe2fjk
9bnPYozfJK0KnFPHs8diEpopGiWZZNrYQXrOHaxBlWMAGPNHsoUjQKRDGtGyiLHa5lhcZHnuJUIf
FiCJjHc7sVUVm6Tk7DI8QENmljrHCjiy5LUb0k/FjlJlhZXmFVkdJRi29XgQeQlUhY6OPsb443KK
wQIcoXLZqWrFIlpwLDhy2lsg8ck9XJaPdMlsDxzzRzbEY0wCw5fHbPFuUMFk3ZAZae2tbsmOYZFa
1xMdmUEcitLBleJNC932WR+Al/IdtgX4xyb9HT/si4/HQ36C4Hti/u/xj83Zb9Tp30L4703x+a6Y
6EreleZ/+cdIctzfH/8AXcXif8rYytDligLmcJKNKRxOA2cI0c+PjLE170ZvDJ1ond0Tr10VU5fE
uprtHdJ3e52yIjF3OhU7zrd2pC+xvIrdo8jOmrY4eMWTMOKYQdI8omK0ZGjHOq62KCFvThCq2RJy
HqkXpzo2JsFNlNNjlstfI51fLf1tYfyc0m46RwTrCKTlpJlHY5ywKxzuAxV14bd2xJdXY0efbV3R
ttO4OqKMsqjqYoFhLuSTm12qtaopLpButG7nc2ABraGmrwaomQ2sDCqgRBa42Vs8chYA48EcQhUk
ZZbHzjsjlewohrnKk0m9Z2dTQ45X31nGVzFwlCEpBRBTe3ls3jckZYxySIxxUTzonlNbuLPGukjc
gdZQYsY3IQw6menx/DxcYxSGmD56Tk24++xvePKcVaWM9oQSfKwxJYIeViYP6b0fj9NVUQHFfPyV
PXiVgnHkRqSTcsFDDDxZEYxHybm+5Gt1VdE/xuVe42v/AK3LNsT9zVF+axfqzsKQlYG8Kd6BpO4l
VFmjJj4KCteSr+LEzwDVl/gaL1pDAPE2GFkSNjhYzhxxMYjdxrW8NnD6ndbXaPbu9rEvbKhRc+RY
+HJaIG/o+9qQbF7SGBxjMnDWezryoHTjhxceFqKj0HRURESVXcWpyOtrokjp1RIK6zCcOZUtIbBI
PGBcrHGxyywyK5+9JG107GOSKWZslNjshLS+hw2gJO2PhpMyFVbHIrF3la58e6+RN9zUlfI1vao1
Egqkq65KsXleVreSG5AbkJYyAeAHwuXh5IiCGcThxt5eaGKSHcfG1UJyIehpYchMgUcy+iqwY7gi
Dhxt4RFkyBpxEWg47OC+dW7sUSdyJmlligI9SLa2+Iuxa0ygWjGEsrPerJK2M2w4CIUfwOM2RrJi
3NbqqNcxOrYugxWGhxdtw7hZAUDjYrZLSCcZBrOdkYhdbFFdFwucg9hYJapE/rmEIb1shrYoI4wR
hIgoRUYnBhHgiaO0dGv63QcJEjia5ju0jVXyO327PFrMTxquGeoqvHBoqsSB6gmrYhK6KAWONyh2
DnHi6t+tzFUqLcnXf2PiKqKsmK1lgItIyABJo7KcZg8Y0x7JInNMlHjEFjgkISR8TBh2xq1IY0aH
LkGO0V7LXue8CS5qK+zkBdIsbnuEeaPO4Zz3RRK9YVYrlijVe8bo0HIqSovgY5mksDuq0O0FYSxr
42ENHOhnibMyOWVjZUbvtZI9qLo92oV5Jj1HJdVsDRa64fUgOtABWNlY0YKwcOpYsDWTzMbDBKyN
GzStRukjtYdyrrm8vYEW4+6EMnAtTOZ5uzh0j9LsCudM5g1mhM3Nk8SR3Hl3mSVVBS1kkbzpY319
UCE9klm4d9lIxw0EatfYPEEec9O2LcKO6dZFhj3bh4mM48K/IklbkDh6Wthdetn43GbcLGM1bNJu
YI4qG8ZJOPNva8V+pwJ9BSHBWkg8tmGZVAki2MocY8Ikpw80D4i5BYRBYh3kNkdDGMOyNWthjRst
bBjWPw109clRPXxU1dGFNUpKTOlXKKwdIJK5JjTJkCexRklLJk4e9PKroaylrK+nrR+Jy9fVhj14
MHFkfNLwRBI4oIuJNJJLJuRpvyPe92rnKv2YR+Al/IdtgX4xyb9HT/si4/HQ36C4HtjPu/xj83Zb
sv1e5smvt69f3O2069erte51dz29rKaYG2tjFsrcAaERkoTIRArWWKDeOnt8eqNzhFiK9SDWzPiG
e5nEl11E4IctPILKktlDZF8Y4eBVmZCoL25KVVWsk/KkEOFAkPNGRwrCIY0k7e3vEneNfh4IdaNm
UeHiwXA1BKYsyCEwPHc6ItvE4Ew7h+03ZmpFvbPbd5Td31NYYNk+QuskqsUjyWkscbGriyXVSg1g
GOlBECHScjBa1p6ssh4+PYlAkoyPsgxY+FbNNxHFbMyTI5VxpwIVw3G23VfDLWyWz7hxDoyIJmPk
xtaYh0czGEyxsVFkLEHMcHC2GKC6laI2uu5kh+vJ6jhEvJlFFKbIM8ogIMUmVqvrHmiaEbcSzIhL
zwiCogpyJBR4o7KfMB2TY9aPBEjHiUICSY2Gz4A8ScPHLWVGuSNZHdjB2XvnMts0qaNH2sZWJhJN
Z2MoYL5OgpLqtuym82bBIT6HMeshwoJeJNwY2P3R6lKPJBRy8hvcUFvixqxlKRkGPraKZXxrHby2
vp0FQYQGa6rbXTI1BXGR2LZgosngYHZdIYvPXCkVgpWMXZh5lvZkUtaCE7HMjuQhzybQflHA3ZdO
UDxYiLKIMPfIZZGXVbc0pVZfhYzNU3E2M1hMlubTQXzYY7M3JIcYZBFWTOlecXfjAzPhdAEQVNMG
wppwdPklqHHjQ2XWRdUPTmiVFFIbbV5pRRcd3ypb6ommM5kekmtpzoU5mhjuR4yZYMgNu627x9KA
OmseDcNph32lfkRhFdRm188V1OAPDYHDSDO6cMp5Kt3pt3HWDo+ZlW+joshyA22TIODWUU+JWkkL
safVdIsnthcqfjK/W9wGWPILfEwTNVwfFZbLFXSpV19Ee7GC8LxzKq+9elXEqdOPtnamQuvVsGQP
QOKvhHjpucgtBrFxm7XPBLl+rlXuNr/63LNsT9zVF+axfqqQkMhDuOJCyGJUbJI8kuEZjWK5Ws13
pUX0xzYur01zYt9ycwO9Jo1c9qNRksb2uhWRro5YpWpJHI1zeG9s7GPR6Kq7rlZEzsmnMe5JKLog
rGH8WZrBprPGgq21LlEGdumyDROfwHbk88DppGAwxyEq9/Cnu6oKVXS6xFW1I6aFZkThJPGlHEhH
LsKGkXl3LzEFcby6q02vdsFNZOYp6xPZPJHuvhdIyeRnEjkY2KCeJ0aRvinhRIputze6ibYmW2XJ
fRPYzYPCfbFYBkQlPO6xv6US3etoRjo2NwwnhklQRkizuHikmZyi8fgIoCJCenSWXXOFQOfGHutt
KPp5pk07kM3EBdLjpkUEkSuKWeYKOQKLjLu1bq7DM4JdfVklxj8KBUA63YAnLJbSiuLyWEeJ1U42
HipYyV3SjZopaFLUeQchcOnkiJUHOYKuelMebi4r0S7nEHGGlqj8jDyE2SCaxEQ51LR3A9ek2pb/
AK2IeyOpZSZIOOTkN5io16WLXspiL3HnWzjK+HctXWTkmgqDngHNqujZmwcrIf0jAQAPkc1nY3J2
OA47hs49EFX0xCx2mUZPYY42YVWCC2xDd8UV/DmtJmq6cuIaCchBBVogAMSvGmk5muK39Wf6F47O
t/wVIyKJo8jcySrmILHcFZiljmWAPRrDRZmttlDHmyOqR8xE2MhZEYVIIZjsry5MVHmJtwRahL1+
RwSNQQyOIy2payqIdCnK2UzCApyZg3U2U02P1GHwZByczMIY24mtCLiIeayIfcWBgor4qxnQgwxN
IfAXzTsqhgCURz5LCqCszzOnm40JRV5eL2x9lbvrWXKQgWdPklhiksTKtZjCCZMkhHCYIVEbIOTG
kLqiovhzKy1sgg7AuvMs8QFKpRDi3hQPLYRlESW8vGgJ4gmHuyY1jB1co/1wEhWI47V5PbYyHZUu
XWR01MJjZJRM9RPjEQLHOyOhv4Y4WJaFq9B4IZJFczek0YibAszWSIvIOl8ppHKCRj+PD2jMTsng
E3MLssyKlq4OPE8B8lbFazGvNJnjrRCRRZpIIpgYbKZxV8Ljw8EcInNPlOrYbseyY2QrhJWrj5DL
/iyPQhK9HI4PnU5LbGh6ityrKy7OiqbsuXhYuIdWVVo98AVpkbpLKgp45i5BzHclQMLIXkinj1yQ
tj38gqeNM9+OwX0hM8R2NyuImxqOSS2EhqGX65KK6DgFJGdcUdXTT8q+WG0ePMJMSPYy1R1PzKK+
MOxIpSiFhXrhISfH7e8q5ISY1bNA6CxlVY3NV7WO7X7LI/AS/kO2wL8Y5N+jp/2Rc/jof9BcD2xj
3f4x+bct2X6ntf7feXbq/l9r+bTb2Pfez7GvU1dHL7Wvtaaa7XA7KrNCQ+nbhzXBrYclKMh8Dq1w
kTaskWNkccUus8Gk00UzopZpYXva7HePRZmyAe7riHvsOkJAh0hsRXvle11MxsLVHbKyR7XRJI1d
JHKnct6Et00Ql3WH1Rko72NnjGsBZAyHwPmimZxWRSuWN00D2I7RdOpE2uA7m7v8gKtcdsMUbcWa
0kVhV0NnEkZYNVFT0lXTCvlekZMxa1chhroQI7GYwasAgGNKtbq8LjIxq2xUMThY1AynrbsGECw6
POGx2G5mkkjiWZsNxaWtc0qRSOR34heXKEqyTWVU7mSC00iidHVD1R3NrVNiDiJHjPnepRAshU4U
RCudXjBMkljfihEHPTEYfRyUFXMQS3WYV0SQREWEcEMA5RwkDzogp+DG0VlraJFEnNu3auAW9ycU
SurMWqiA4iKbh3A+HWUtrROsppaOQ1j4C5pVnZVFVYpbJHNJHk7uwMXMWTmV+XXmZxazwIr7O/S9
aaPK5grHcgxMhN5ZkSxFR8MZXmSqyTjWEI52b5FNHUY9U1A4huKCW9ULi1k6xx5tA+cLHaRpNUXL
zHHvJieejgSGydYIqwzXNlkZuUUd6dmkWUUljLYY0TllU6vx8PGIyLHowGywxZ7QKGwQiqECPpYa
2wigZDGXDrBestLq9tCsjxBuGWliStLAXLWtlu5WlRx1tKBXw2KdPFR8RgKCbkAuoXEbPIQfMSTa
wzm02PU7JxCYYJq92LWpl3SWoD+VcsdoJZl8zvT8wDLy8EUoLoeYjnqreyyK+yCzpxLwEYu1Zj47
ni3z6iQmOeGhoKUV3Luph+UeyCOROMTzDidYeBTl1drdMbU4yBijxJn1Uw1tW1TzZa2SyV1TzbDA
5rAuVslUVWRTLIjSoJ42MY36uVe42v8A63LNsT9zVF+axfqrCNJHDO0qvJikljfNGx4VgMYiuhjm
HfKnpHXE2aLi+D4jN7eQkSRnNsOWV5ymK0rn3kMSOdSdY2wyRzQo2B0fCZE6Jqw8LhMRu0WQMI5R
OM0gytaFFOKXMiuVz3Rq+NsSv4k75XsT015BbnskmMme82zbWyrDj81HCPz9KLIcZFCep910POwi
d1vwJnvkhO4b4ZYuDGJ0nZrO4WuitoJhSEfZPaMZ2s41bPanTUo0sb99w/BqJAUaLLwZxU9KJFhl
RWbVOGcyf0bTehvlZ3PG5yR2NWVdaCNn+tFH3JZ66Bk6LF6bHNNFut9LXYe2ZeZFygGRHZUFjnGq
UpB721CsBLCVdKTp10cy2xh3BJt5YhiSuIHGPBGyFMT5ac+dcOx83G6tSJB1UgI/ofmZDuCBEryk
ZSBsZJBwIlV5DJ4ZXrErK0Ya9yUcauq8XqJhRyKZzLYXEDyDcfWwlnpJjhkGKIJ3x6gkAIofitOg
J312r92exclXmdzm4+8+JUW1t+m2Fiv3g+utgTIC+Vij4ZKvjhchDmRvSU67Kt7pHHiYuKtdEtTE
DBHiWRJktU6BOiOkWufYPLiIWewljkGNngdGrUG5cmzhtLmrsiMmrcpjNCfVrKMfXY63GFGgiPrL
AeQOen5iAqEqCdWyFzvHkgcvVkVfFkmTD0GTpfIbjrH0U1WPNlMZDLMoIkuhmyIaSQgucyKBLlQR
yplawRA9+Da9QqSw4d/iIuGGMZLDG2KrEmtyI5RU5RHRnPW8nQh8nFHlbAIx4zuHPxCHSZLlE13L
dh5DBlD5KBtzX2gVVHRskBghx+LH2Dy07JK4kKeiIDngJJc6DjvbMwS5GzHK666jqxKe1sw24o6T
IwgSZyw+mATcWMqI5xpizuGTS11PMjDSIlesfBbDT3I2R3+N2dKLahDlUbMelWYW5dWvMhJiyKgv
x17eqFWJ8EUErPTPTFR+iUfQdre4sdj7LSEO3pyK8uwIgvJYyrqK09EtZkAVo60sIB7Mss4OY9bC
FCYy43ST8WLKpSrAu1ZSRUz1IcGgs741VFuZBRgh42XUsLpBJCRuAOgcjxohIo10ShWhyDI6SSlp
q7Hp5Q3UJDsgqKmZ04Al5Ha0FiOrhnzG8MuphqTWssC2ISjVhSG0fTZflVRX2hNqf0IM3FS62vs7
l8hBthXPt8XsrSKRbGaa0jDnsiKphk0idHqG7lNnVYRBJaTHn2ZRZcVYPMSbYkOJJmcLS11RUj7z
3d4BWCRvVFnlZIVKQRN9lEfgJfyHbYF+Mcm/R0/7Iufx0P8AoLge2Me7/Gfzdlu38e0w0czHTjqj
SIU7+FXRxTN1Z3yo6OaNeImrOtE6nLpt2q932fY09n2Uci6aomi932u7tJYCm506FBJZOWQ/GG0X
HQV7WydUXTbYmF7s+jyNO03ZPSN6N3dc7RPZ69VYqqnc4jk10060fIvV3ZEftTY/RVNdZ21sFa2U
TLy7noAOTpnAxEMjMgpL8t9irrCCaER9XCNKNAbO+xicO2EoSjKuKcPIDR3GDUBlpXw3M8PCknkl
jr+YQieEdkBCzywRSs4Y00yP0i7YqOlyGht1BibOUyttq8/lYJ4mkQykcnO9g0T4n6xPmVkU8b2K
0jv0S1tLC5xoakrlDk6XZkIsosYZwIJo5FoRNEGLXc0h8LgE45MZQMghfMIpbIW0rpMpxyNuSK1M
dV95WNS+V74o2JSq4lOlFfJPAxqA8fefNE1OuRuthVVl5T2NnUO3LWuBswiz6x6uczcsA4JpCAnb
7HM3SY413mub3UXa2BZk2PuNoYJir0NtzXOKpRR+ucm2HQni10ECKizTGMhjj+3cm1oaFkuPmB0b
pW3ZYtzXEDU7oGufO20niJdFXuhYx7pULdEsbWOc/RGrtkbKt4ZVfR2IIItsBYw2IdvEbRVd1zY8
o7OC2Ni2SiaRzlNeo6y8Vu/wo7vHkBkHirUk6Os3TsfDdLXywiX6QQoxroOhbAkUGZXSS8aWRyok
XD0cdyWVY2X0YAy1suVvKyfo+skhQmOxO4RTuUAeOqTsMn4Y7oVSVJFYuuxllSn1OSurr6goLEar
uQ5nAF3d9XUisNeLzqikCc8pKiTxskm4Cw6w7/FZNa5FeYvShRWp1Vzr8jEWsScUwkaMWawOiq4o
bXQd6HVe694JkZIaTlcus75K4nKccgsYq99tJXzXlZEayriGcbJZPFeU2doDA2OKeY5iDtGa6dZE
iRXbUdpQnU89Zc1xxqsmuhOnBJwuj3TBuqQ2nDyOCYezpp3SsT6mWQGN0JCHI+Ei0rsrxo+tDJhD
LsQr2rKBFMJkiiHFILgKfBASRLPBHDBJI2WWSaJjGudIxFbkK5jiyUDyeSZeLkFSlO4zr+tG2fN8
kpPau9ISbi9qva9S7Mlie2SORrXxyMcj2PY9N5r2Obq1zXNVFa5FVFRdU2yr3G1/9blm2J+5qi/N
Yv1Z0seAoUrOXIYUxsg0jCl5bgzxPRzJYpllSN8b2uY9HaOTbVF3kXRyOTra5r17XRfZ0aia/wAu
vWuqQmFQpKj2LwXSRN0du78eqyyRMR6drKzfdqmrXonU1zdFJii9niSFgkNYiN033pAdJLu6d1W9
tqu87q3l2eRXcE2SSKZwjHlbgxE2km7DIZEwtkUXEXdkcwcp8MTHK0ad0TY9gJafCqcxxGG1GYlj
pms8ZKQ3B12IPXUquxRQrOycNSKu6ZYUY8Zs8gjzox2MtJ60PGaOsPrS8XxvKSbC4vi6owYTITLI
TlI6wTHLrmihOi1dOpRVUM6Z6jsmdKGS6PnRK2S6sZyh6+tp4SGjEWRT3PdJGwmRsu40UOIo+Zdy
VeAJN2uq67VeR47T0d/SWPQG4QdlJlERv5LYAVlU8cYbFL2GQOSSxGkmnkMDkT0xjBZNdH0s1xUD
PsDZZH3AtTYvMHpakJiSXN82wMrKqYsOognFnIjkqRZZOaVkXtOpg4YGlk29hyzY1l4MQ4UI8xtl
YzP1kRYBxodIk3F+uCQ4HK1SGrtfUENe5rq1hCVBxBf1vfy1j4wrtjWwDEEBMqLYkauKWSIx8jZe
ajjXccjr+rtsZx6pHxsqMKwNAyw65e8wunr7cZogxOH0EM0DRbCNhc05g80Du0ZDMjnSNze+SmkY
uJ1dhdhCTGNRb+ihgsSKe1iKaK7lBrp1XYRw6RHpC2Hi70mu442I/EaZl4I/CyGBD5eYRVk02bXL
sfBOjtnYdAUw0K1jkYbWzUrGcs3mRj51ckOyWGQ3NTRArKyDnbixErA+PIjlZChJssEKyvRj1ZHv
b7ka5Ub1LsDSTZHQw3VnCwitqJbevjtLAeVJFjnBAcQhRcMiQyqyWCKRjkikVqruO0KAdlmNIeEM
eYYCt7VoYKJVvnisySBlK40A9fKKTGdNKxsYkg87CHRuikRtHdB5FTjw5BuR1wptvUxHONc8OJ9W
6CI6dq2kE9iAMQFBLNLEQYLCvbkQo/Lzqi3pMhscMqbWytKWtuwZTR5KwYqZQ7BozjJ6x8swsgyu
IFV0UiP9Ke6NWbZTNdzV+OVuLn1AM9paWwwwMnS9DS3MUkpBbBIA9JbhgDGPmk48kbZGua6dIGCN
flGOsceA21BR13WtU2rcMUY2yERSfrgBwgJpTTId8dRgyp0k4Q8rmMsqK2rbqukdIyM+pOFsQpHx
O3JWMKDlmgc6N6KyRqPVWOTddov2UR+Al/IdtgX4xyb9HT/si5/HQ/6C4HtjHu/xn83Zbsq+11r/
ACex/HsVJHG4GOOygK6URzebIhbUAwqGInbJLA+WN/GQxJoUcxXJGsrIlZ2yKmvtb3a69xF3Ud1/
wnd6i/xbGOjFGQgh0kM07YGNke2UcpGRkFsFmdEIQW+GEhycBY2ScRJt6NsUnDFPKNHnr1nsldDE
xqTv48zIHpA0wdBoiZiXjq2WvnIc2VsxxzoWRWiVVfR4ldQzRTvbNkVlY1ZGPnqxsdZdU0lfS2kz
zx5HzzDyDF48bARHGodqx+/LBLay8LJBSTcdspbIzOMyx0uK0pKGrqJjZsTq687FsjLc6qjtYzLB
6TyzzygyMQcCBW4TRBm1gR9LTLiWSkQKUkNhi9nGL6IY65XDI/pBxII5QEs0MTB98lInRcy7esLu
p6ElmHzanyqlpTyDAqwkcDCw8TnrrEoasPdXPEe4uypSBq09o8sAacro98sI+Sk11Wb0hjlXS3dD
H2Sc6xcMCarsrA5JBTsdpmR5WCQ20mY8K+o65IpBY5IXI00qJt6pPI12LkSzz1NGJfGZF+2BtmYc
fbcWyx2nMpOd47Xy0UNleVUM8snRygMifz2UF2J9YRJZYz2RcerziMnyYxkseWOGbRN9DU1c2gxQ
apDEHBsUo2nk2iwssCpySlkR9gTVdARt9DnY6BAryuYjAJssDyWwvmiWLBwnpDUkwTDADFQxlzh+
mSpWyMHjgIzq1sR8dHs8puIbkICqMOIrxpocbqapIjjp6mvnnfIbXvkINirmumik4/KxyuUduH2S
ZtaW51GUXNb11lDjotMTFkMRDsp5GWoxQK8kfLZTttQIrSzJiknEHQtySI0mGG5MDx6tqKPsLZkP
VLVTkT2VvJklLCUTPajS1AMFU2FwT5Z4BbG36VPnQ+WUN0HBkcUSPi1LKoXY3rKsGnLMnCfUYdlI
+STFmTPoq6QUmcXfFrKWEcwStcxWdLTsMfKODfVTMdt7IK+7I5CVVraWNXXrWZxkHTQ5sFoPQ3M4
l0BGMMHNF0ROPPAZYQsOY1rJJ6zIjygZamrvILYJPRRkn1iD6GCqianHxGOvHxmYplqcYc3KC55b
ckQhwXDDgZDDHRY7Zl0oDafsf5tgTja4w+ydOy/Gx4WstkGIqqpGLu1ZUljWqQ5IN6CEewNSWSWA
+a8DxGsNJhwOqbW1Zx9pWE1WKZYPkR0xxheP1UrpCYOZDrahKyUYPRyS2c7D38llFnQR1PSlnlQ2
Q48cuSWOPTUEzcLrsaJsZGwYrkgFoVLOKQ2Wosq8uqOCmZKVJzEbIYx4ypmklMghYSQ2NIWzztja
k0zYUVyRNlk3npGiqjEXd1XTbKvcbX/1uWbYn7mqL81i/VRsQ6lu5+qkUZqRq6aKCzEnnRON6Sm7
DFI9eKrWqjVZxIVckzCx5CnwzTykuj5VzJEq1IjThxAOPhnSdYNWzNcdHLC+ZyuUaKBeQgvTgqwy
6FtJhjIix7SoCIFVQoB5at8JE1WiwjtDH4UiTayRrA+bjkoVO6eismzAcBad0g8NssVukNmFMhb2
yxX4kBnLtfI/SCFa9Ho1sxjZOC19RYDiitKsaqawgCkJkiGeSapRjRpCYxzCGR78zI5iI4jJWxrx
WxzStWJ1S4YbDZi2YDQYcaWXfXUvRxlBYXs7bEQCDFopchF4NmMTPUuuKDiERT1kRkESJZTUJweN
4Zl9fSYrjOOin5YdyV3VmUlncGF3VdFFiF6PxzIbEaZ7xj6viTwbvCiijjdJRGQ5GZjtZQjWBLZK
dKMqynvT0jGhfJHkWPXlawUerkOY10cMBSvsur0tibJiHSsNk6syioOq7OwnRs0lDU5hX5DFGfyl
aMNEaGLCTWsGAggChYICjGMbJKjj7EjKbKkrPQ8mOAA0cGPEuIFOdITfutPRFit2yNTZ4QYYuj+B
G6EKLiIrvSnMnuFFPtcfxgbGKEp8yyRWUjIIZyrqeVkLSY33Kx0Qdkit9KJqTZB9BpBpCMRsPRpb
W5tOYTLcVljDjcFMXDkEcy5VyclVi9fcTq6xIZZhx2lgQyacGJxLHvZBJH2S56swEU7LyRZaEt8j
9K7h4rS0HMEbwJEPHHIDInDjWCeAhEHYUyRjpUU4Gny8+3FsOx7fYEouUdCCQhizV6x49MM/FsVr
HzpXmb0MqnoRPCEcbLA+Sb0iZavEhhp7ky4w+wtT8oyjJDZiIMYtq61SBLmygyi1dA3o9w1dW6Q1
4anElRMhe6aMnHcox6CmsjqUS6rJKi+sjKgJ4930dI+wEswqa/mGshJKuIZrVqpGFAnGxqQMqN4t
/C2PHHUeW5DjGTWdkQaet7SkUA1FC+urK9KZwlq1zsehfW2pFvUPrX2E8y1ZShtiMpZUdUMmA7Km
XZyZNEsySzVmQw5WNBEx/JNdJZIPc1sBccqsg4IskTC5mQwJLgHTHQjW4RjOTYzxq4802YttkmOR
V1oOhVNX8nPJBVHc8LxJuT4sMcBtgyWZ0TcbM9Cwrcf7HuT4NjtkCZYykXj72vGr4bC7hlpRvQ+O
jQYCzq4EjJFIOIWZpjUBa0440ckKSduZUGTggsyLJMZ50avwMTDjRCMix2BtxRlJLzZwRVfFYskj
ihGLh4RhLILp5FLSugs8AExZtE/MMlsN4xl3k9qfERmRlMmQoGf0yJIts0SSyiKbMrRPrUaWVsGU
mxGWXNmPj4JnSaB17pl5AB1stNj0ts8YdGo48mnELl13SnGzxyWBX2SR+Al/IdtgX4xyb9HT/si5
/HQ/6C4FtjH+UDF/zflm3+3tJt8mqKncXRFTrROpNUTqX2dutEXXVOvr6nd1Ov7VfZb3PubO3Mfp
Gb7VY/dqgUV7HJuua9eBq9HNVUdva7yL167PfHBDG+REbI6ONjHSNSWadGvc1EVzeMQRLuu1TiET
v7ssiuXVO73fu/f9tPY07m72ve9Wy9Xd17mqd91rp7Sr7Kp19SfwU0X7qImmq6dWv2ve+zprpqqI
iL1Nbp1f7f7f6tE9hP8AH5V7ja/+tyzbE/c1RfmsX6ssbJXwPlYsLZ42RSPhdN6U2Vsc7JIX8Nz0
fuzRyRqiLvMcnVtr1om71oq6r1fy6qiqrV1160TZriihxUXqa4ieOFXe320rm+wiqunbLp7OmmzX
TE0RMqaMar5gJ5URzeDub2/KrWPR7oH/AGrmyOj7Zr9X8OGNkTd9z91jN1m86RZZnbrW7qLJI5z1
cvW98j5OtdVWkSvN570Q1fS9YsQNj6bWdW4cWjhX9GjvaugslosCGztkig1fC9EVd5NVRrdVVN3e
01Tq010dvd7vJ7G4ib6qs9Ckzltha0O5JEc1/EaDYkHiCzq/RIVSUmrOh3d/qWHqRsax7dTk/gp1
9S993U3lar1eq72jmK/RVc5dxNNH6Kru17b21TTdarnOTttOtnbo/rR6Kiu2sbWxnUWuqxCrA8rc
e7lxAoJSSpVhZxSHcGCFZd2OJ7pGvTSJ+rtop2arFJE2WNUY9naydsxNx7GSJusVvfMjd3dWds5E
/wD06onV3F/6TfY6+rq9pNP3jI/AS/kO2wL8Y5N+jp/2Rc/jof8AQXAtsX/yg4v+b8s2X/b2vsfK
vcbX/wBblm2J+5qi/NYv1ZVlmePBzdVzE8croHwjdKhczKkzHsWLcg4jt/e0TTrR6dopD5YUmnhc
S0BxivFmMiiZ9aTHxRQTSAyEu3OJEyCSZsX1zILATItbDOwnBMwyRr0e4MrGQQLYCAZO1Y2RCrSn
MiJVY4SHOYxOBMQUMMdHywVlJ19iDsoK1FdpxsQo0iRnpjN93DyGHqSDcYrY428JmqhwiMGrAacB
54RYJLoZdQbJqOOGG5gno8Y1EJl4hEIvAgnXmZOPIkvWrJUehNUNWWMuS5DgjC8duyQnOsq7IK3H
uXHxLIWlMhjCbUkcObGJy4QKol5RlVbIPeLJYZA7KulsrvmU59c4/H7eg7IWPlFjXYfRBIoknZHy
e8ltDWW8tPYI6rsJawTo54NZFHPcTSTn81J2RC7aXscUrKw/Fm5JLAVnzrzL7GNk51SySCEQMs+J
8AV9P6DYQpmx2QzWCi8I9pT84bk3TGHrij6aTJPQX6HYwaGXIelHDpFhMu8ezLozIsk4+QyQuFbS
s5iaja/Pyq2PMguLiXZLESqjDz9wwd2FyQ+LmVdpaWx9PYF2qRS2lND2P6WpeDAdMHIRbTDslW4p
nN7JdhGT2OCIsVjqScpuWWGVHtvPRFBlChvKjILmZLURwh5W+WihBWaCiiGngmjbJG+LJrKEitik
UomPOKSlxmGCuqYoauIExHYFfzkytmIdYV0kV0E6UgR45I6zSjfxa+13y9XUvs9X7yEfgJfyHbYF
+Mcm/R0/7Iufx0P+guBbYx/lAxf835Zsv+3sJ9j5V7ja/wDrcs2xP3NUX5rF+rIsMMU87Wq8eKZ3
DjcQxN+BHSo16xemo30xGqre6ibNRqNRNzRqI7TtU004aJ3Y03tGr1biaIxqI9dmPlcu/PMgwsKP
jSYouVsj4hh+O9kSzP3Huaj13Eaxyu7RvVAFFHZhSEhUR4rrAceCIsfJGlup3w8MwmRriWhT6iyJ
CSK9iMKY18jdV07q+3/C6kTf+6vUiaex/NvJ1dbfaXRm+q/avVNOGq7nbObr18PX0t1cQewidamd
pYcSWFhCHzTNFilNBHJiBtJRXoycXpKExAC2NKC4BKcVOrte71IqonX3epF0T/sXVU63LroiaJ7S
dSbdxPZT7yO75E9pF0TVE01Xr7uyaaJ1oia977TW6K5qdbtGsT2HuTROvb2P+3Rd3Tq9je3Xa/eT
q9pXb3U1uq9smmujXSarI1qI2JqpInpvXq9NE3NlT2urudxepev+J3sIvt73sfvGR+Al/IdtgX4x
yb9HT/si6/HQ/wCguBbYv/lBxb835Z9kZT7j63+uyzbE/czQ/moT6uormRzSE147JJfBs5o8cWV3
auY/qinfvaPY/d7aFyParkLIfBNEoEhERscMU5npw7Ekl5JYI5HnNVjkWNg8CkpM1QpxIbJs4A+P
9GxzPsJM1qWQw8MgQjhhEEofNDxI4ZeEozJIuNHvDzwE70MxEErJX4oRTBvBBteyHQ22QSyzyy7j
UlngEb6ZJIzgJMc6V0nU9VjdxHK3REVurutq9bep+vX1NfvN1f1brVXuaLvqu9tj/Y7hJmaVmtNU
G0Jg73snHorwGQnNpITYV9LLp5Q7qYAlr2pzV5jUPVvv2pGV1VSOIi7GHYnhFt5ItZUlyPJLXGh1
uTYZI5Z8dpZpOlIQ2Oge79uUaWM8jjx4zjVdFU5Dk93Bf2UplfQCDBqFTLWsQYSgv+ydQP4yrawS
EmNy058EQ08raaWGdZa2ldWDMGyq6JGGGpH1omQPkKSvLtLEFu/luG1icoGEUQ8+XI4x+EJOweMw
mUePaW5q4MXGjquxVR9kayGLr7ezccWYuRqbSAEV9uPEHFPFSfWZz0tJA5UlaolzG504p40BVELS
1Gd9jGkkryI5lyM0067wy+Q6CxjtBQRY1isox2VT6khToICyks2QSIIlBjuOk0VaTa1N9cPtL8Ey
0BbBSLTRNEgAAtaOR807rZs8pnSCRV4okrnBE8w10HZCtJrAAekM7A0Vx0FENYlJHMaLmcaTV9u6
2HCe5Sxnz9KMotD6tQBY4BJBXkz3YtiFQWViDQ4GfQ9FwTijiNzK9JxlArN1xeCwWXRBAcRPP9IY
qJcNXhTsx5FUmLEaG4raiiMtW5SdayWFYx05FXj5eNcs+urqTOchCq5zoLooJ3M5Hc8CceOzWFY/
2qlyMClmxQUHGcDEzcl98NZklG/X2QQFVsXJWYLBIJoqqDdtlYYtbO7R9XaoaxArk4SOgFpMcvcS
oDqGxDsH5JaT5MLj5Tpw7SK0HErJIlyOEcCuloLR9kRXEM5wTnG8kHj+LCYZROsbnsuOnIJpLAgW
NcQywMAcro6uuapSjrjn5ZLid5sHEMndZM8C6vMyjJy5aEmik7BNPlkuG2NRY2FW8wkXLHzDPdJk
DA5Yp7AKRthO6pbLZU3I1jmjTBLYEXBA8WMMxvG8nwPHiAVr7Nbc4bLhMT48gpzLeICtkqiMhdKO
19bYRnjsaI9te8dTC6BVlxXoLIM/yHDI6po9guRAQ44NkaTmSn9K8mUSWXRxTyitphW1IpcQ75rK
SRpTOyFQ15OPAV1R2NTri26YiLmsLWO8gv66IerlgsAoKpBOjH6mki3TTTCxwWiB7ikymY9jVAJL
TY/0NUHnFDVk6RkWWOBWkdsUTJnlLbDBiPsR/wBrQ8OuOlIQiGD3YpBLkq4zm1FGUHXEYIFfA24M
x6BZna5nT1p1bAvMxjsKxWPjFpJukPbYE0xkMyRjyRk5vmipTOoMUTMR4cYYAb6IZi8TkLH4x+QL
b8kGyxeC8toLcZlkHryxJefnXXfW0sKIKtjQwYqa+XHBbiAbHJKossg6HEcX7KmQWNu0cyESLmQM
iQ2YY9Jx8blQSVzxCo5oyIyRoCGERRviinZNE2Rs0cUjpJI45Ecj2Rve97GqjXOcqa/YxH4CX8h2
2BfjHJv0dP8Asi5/HQ/6C4Fti3+UDFv7Bln2RlHuQrf67LNsS9zND+ahPqyxloQo3pc0nKtJfOii
yISzhIFHIUjlfEiOdEnE3e0j9Mc3ZkUcLIoomsSOJjGtijbo1UbExGt3ERya94x3ETe073apsxTa
6Cxo1LdDDa68hO09kMcnHVO2bInLM4crUfIzr00Ry7zq+3nw+or1Zw5C6+4MtzWMciIkrB5qqkjD
kVUfwZX2BbYpODw01V+82Rjo5o3dbHsVr2L91rmqrV7qpqn3l69dhGi1wIzQBnBgtHFghaEI9YVc
KI2NjUGHc4Ydyww7kauhiVW6sbpIM2kqWjzVrKWaBK4ThTU8fM7lVNHwd2WtbzhmgL0cMnNk+len
y70FBLh2LyUQpDjBqR9DVupxzHpIjjIatRVBiLVJp05lkCTohBKI/wCuJt8eqtKKosqsRYnCVthX
CGgjLA1Yx+XEJikHh5eNyxjpHG1II9GRbjUREkGSip2jzVsdLNA2tDbDLTw8bhVMkSQox9bFzE6x
guRRmLNKrYkWR2sVmbjNAbYwDwBwHlU9eQZAGLNzIwkJUw75ohRyE48A8b2wxT+msYj+22YLf0VR
eCxTsKjGuK0OzgjJYxY2kMiNhmY2dsarGkqN3+Gqs3t1dNmFn4/SGlRgkVcZJlUASRHWmQqOXXMm
mgfI0EqBzoCRGuQeeFVjkjcxVTYpCqmsJQ+vZUnJOALMhlVHx1jrCkkidzFexSidwKXfGbzE+kfp
0m9A2jxyhpmi83yzaqor65B+kOW5/gIIPCkXO8kHzfD3eZ5Qbjb/AAIt2XKboGputKikr68K0pwz
uizaWxurBlsGUXxuCVJ0vwmcEeGWDlt9CH8XciFyEmhpSL8GPghXk9WDLcBw6SpwhbKSBxo8ehE6
bkUzW6TS9Xpj9WEj1VdARG6xfGRCCNFMx9uQwu2eyVkSPa60KiiJsXI5FNIjZMTxJGNcgvExjHpO
SrZ6YLfpa13KU5UToCqkXeGXgVpML3wzgxbos0T3RyROa5U2IY6prHMMJCMLa4AVWlF1qCpXFEIs
WkxICAhIFPJvSCoGLwHM5eLcgzE2XF2NCNJsR4qPDWVF9YGPrp6gF+T5NLd2ct7HWVxhjB4oa6qR
SZICNWsGaO4Yi9x2iupw4yIRJ7apAsZhYjGcMuIaQweZ8EZUfaEMiVrZ2drIjk6tgrszGqAu6rWw
srrcmnrp7OvYO5zx2BHyjuKFbA973wtglYkTnuczRXLsQP0RV8uZYNti4OQF4JVq2eEptmRHwtye
waUMOS0yRHEJPBDMknEiY5J8ibQUjcgKg5Ym9bVApcEDcOOHl57NIOdlg4UMMXCkmczhxRs3d1jU
R4KYBhKBSExmyB+hWi5V5kUcsURbx+Q4TiY4p5oo51bxWRzSsa5GyORdE6kTqRE7iJ9jEfgJfyHb
YF+Mcm/R0/7Iufx0P+guB7Yr/lAxb+wZZ9kZR7kK3+uyzbEvczQ/moT6vNNgcTpMFAkEe7xXyGHj
CM3FkcyNNx06Sbjnx8dzGtWaBrVcrJhXNfF3i7iP3o5Y95kg8sLo4pB5YZdGSRTpFJE5ksc7IHxu
btTF1dqbWyJBO2WME0oXmGObAuqyDyx8aNnEc9nsIknW1j95raqe0R0tnBCUOYU8o5pEkkE0rWTS
SsIasj+CsWjn7ztWNfrvojtonMcquSey7ZeveVLIxn8SNVE6vtWojU6k02SSzLGKzkiCogqiZRoW
DWRGWxRy0FryoMUEXRwbpTmGNhha6QfHrOVNXQTu2xie2r73J7ZcJp8ry2wpxaKKKoAOimRtodCR
Y0rZlNkAs5YK7Hg7E3hV5G5XtdKBGSSAlRkJAgNxQUthfjC1vQYheTDVBFK7fJtR7MoU110GOsgF
WW8SZHqYg40oZJFJjwlXe3FXYE5/FZXRzMXFJBKxjJhKhWjtht65qUlY6eVu/PVkWhtaVQyQTWVl
0srSbaemyMaq9D1rlNLZTi1XL5TTU8DSiJ6OEW6LOheSLNAaGPfi0pMoUzJeDpAa+AWigxzIojJa
0e3NUiTF4201bYEnQVhllAmRvsHJYNr5ZRm1oVg8ZkjGWcYxbJxoP+3ua9Xd/wBkTXu9zT95SPwE
v5DtsC/GOTfo6f8AZF3+OYP0FwPbFf8AKBi39gyz7Iyj3IVv9dlm2Je5mh/NQn1eCLNHBOhAJEcs
0TpomuDPGLbvRNlgV/bQppHxo+N1xq9nVIwoV8TS2mOn6QUlI5+kFnbwiOa9LZFK2SJEHdBwmwRx
MaMyJI42ptGbc1ql8vziijBx28ekx7uMfI9lHYAcR5cqcWaaeKaVZXSS7+/I/WMBMTtKwRZUZDMy
XNiRfTFckkhLJ7Sv4KJ2iq5eMxP/ACzutjGBrLxla6eRXqzl0e4sqctUSJXPWPt51YiK/VdEa9ds
Wnh5uUjEKKSir55J42ceF8SDxFmxDMjhmKCglPSvkWNrAYbqzSBkfNy7V4AF3ktUINjYOIWkAZNW
1choAOOgYFtNLVEvEdHGbYQJYY2+kt0jsX6HMfCI4e6YspsMd/e47kRbYXDRRQFYu2haBEIzlPSw
/wDB4B00UyyzKrp3wTxelNhrrIQ+4DKAtMtsXta6pliLhzW3hucgqi+PUEo2vnLHGcM4FQbeKGJj
FsdZJ1ebVT3WSHVkuNW2KVAZs9duY7TXcUQ5QlU6KtGKKlaMIFBEXks9yZBEMyEYmOIo6IjH7Ymz
sHQY26OarpOXoErojYopBmmMPWhfkg0zmTMZIwO6HDnjHhZKI5vE39f4S73X1Lovc1TcZpup2qap
rutTeVV1/eUj8BL+Q7bAvxjk36On/ZF7+OYP0GwPbFf8oGL/ANgyz7Iyj3IVv9dlm2Je5mh/NQn1
ZukuCoMrEGJaUxsoskRb0FWGZjtWuZOs6ROSVro1a9Wqmjn7bzetFXXeRdWu169Wu+2TRdP4tPY2
a+yLjr2EuHEhOJaa4eMywZYcr6grrORNyOtNnkdPCPBrGPAhCvI3UlEyuyCjGuJylxJKW2yGRSRY
CRY2j3TLCXhNnew4JVlrk4Tl5tsQ8aQptWkzycSaUASad+jWRvfKKyaSVN1sW5Er3ORN+FrtNNIm
dsrhsq6DeIathjQRdDLZtdIHDk9rVD15zTYQ3oWK4C3GOiUcZWzTo+rk4KxTkQXr7DIqNC8Yqp7a
2pYrarW9jgj5dY4kq5Th5WEGSkhhVzZ1hiLOsA42uaso7SGWol9TkAO5NEKisgZB2uOkjiCjdJHO
6ON5MskcUDVeq8WThIu/vJs8m6yKjpx2F9HPntbaur4efQfm+Q4xpUEDTnCfXLBnycVIFSd0fCaq
7WZS2NSXaC4/ZX9fQdLixWdvCDXn2kLRRkWcqeAweuMfGRCHNw4ByZUZM6F+5LAIaJOaJGCtiBCV
FMVXLYDMMFYbE300ZZhVWeBk8ET541SSLdY5NLM2uybHTg6VXLdki3dZNFUtjbIqrZzRkviCdpC/
e56URYmxvV/g3MXJTTrrH66goreurBckIvgY6i1Szoqy6gmiMnWANi62LhYmxFltLQbmo5GJNy8I
vP5RjoPPMAkB5y7rRucjtOP0ZILxiWcwyx5UnkHRb6F8vPy6ycKTdy2qivayInCpVZfKRZ1bIxoY
gxSizl3TXyQgV8hK19gUZGK0WyFLEk0WHedWFQ5Xjco13K+CmIjvKx8FvNGXDXyRVkrSljPlYeQO
E+MV0rmlzwjKiTSMYpMtBeU95GHOopclPZhWbBSkTeUYl4U0zYJ0aqKsMitkRF13f3gI/AS/kO2w
L8Y5N+jp/wBkXv44h/QbBNsW93+Mfm/I/lX+Vfb+yMo9yFb/AF2WbYl7maH81CfV0iHUtzS6yXlU
3frhIbMWZYu39L3VZG/ffN6VGzefIsbN+aIqBxjoZSpDJYuVRkrKnmGqkcVe0yGXi8tIiTNYWyWN
5Ms/pDRuELEsF/ZntCFMHJknH1HKHlhKs1ChbOLQWkLY41toR4eINx3QjQEzSSzOUhzhrx1jM8WG
eQYMog6xkeLJDQIpkhgVZVxsjg4I8LBpIWzo6cmaVu65itiSBsaQ8JOWa3tGbqtThcNiJ6WxrFRG
q1EWJvat3U2wKvCOrYrigjxGsyaRyTuDu6PH76svJIopWQrPHZhGASTUsr9IYeftht8NpyGi5iEr
Aihb1M7lqb+fOMzRAZsyHs3owrsfSxEYjxIZbaUQi2AOZKRwulFAYZJJCgi20tVWCn48yuyUCvPM
suJb08NsPjZgBk9XWcwwbpmW3IkLEgljOqaqFjZIUmIXH8kFjxu5yYWLKunwrE+0r66cnKDq20nN
q7UWivDuLTPph6cIQmmc4ypk9KNAkF5cm/rhSKiSSw7Eg2AATK0kWMa4hXKJCfS4RyeToeYuwmjM
GcWWNGC+N8cz4t+QigfOCUIO5ZKq5a+WW0sJSlWc6W9HaMNBORAau446EuR1sO5in8oXFM8i3NtS
KYy6LCwzRTsoyfIRLi1xPJCL8iY5LasjixqqvXyrDFUY5Xy1+PLIQ8AWwY9rGZCU1cfBlyPMhb6z
paPKclxqIqshxQSnUZ2WU1HDejFx3AkFrI8EMbpiGHlTJxIiih1IwsEPEzjmdhLFsQtLGzKsGxVw
ptrl4hJlUjqeyIto2rCyV1QdJVNsHQiqRaQuh1dnFSKTW8hfHYhfVJ0txchWLrHFBcYH6Js21YEB
AAlh6HN70Q1Ny+yCeWko9WsorXSUdsXV1YSVweaxGhvzXKc4JLMyRuMRDFpkGUVAtmu+NSlDGMe1
EEidAgvNJPO2IsG7cIOBFKNBjlKHeF5PHSVQwcUPKpkFlj+O2psbpkesMNkPYEhxtRiWpEL4hgvs
Zfvff/mTrX+LZPY6u4vdT+Tq/wAQR+Al/IdtgX4xyb9HT/si7/HQv6EYRti/u/xj835F9kZR7kK3
+uyzbEvczQ/moT6r445njvkjkjYRHwnSQvfG9rZI4545IZHRKvG3Z2SRKsTd6KRN5NtO72yff3m6
dar7KordOrqRERqaImm0TCa2vL5mF8r0mqY7OeaQUuugEhZDzAyv35S2ozVzt1WN03dpZh8fpIJG
DiP4kFAPWmM5icwacYmNeYf6VMCrlRJ93uJu9okj44o2pHG3ca1GppG1G9q2NG9SNRUTRnX1O3EV
FRUY5KuE6WSZbCSsiKdU3EVHNYsV0fRoWTuC9DBFhHIyWGcYO5KL5saYNg3PI4WCvj6QglfZ2xNC
GoyuK37cWI2Q0GZwzZOTnFbWGsnjIdHyssD4ZuG+LcY1V/5GjevRXLuKrvZ3kZqnU3tPtnP3kRY+
1RVbortGIzuaOVvWr93r7TgKnU1WbuqJ1JVjmzbkt1Y9E1rN18jZT0CNsHDb0LZOEzl64zfWTtPS
1iVd3dbtp/Cbqu8i6qztEkV28re417d9Xa/aJuqsem0AToyOKTCRNG5gpDxIuWfBA9k1lFAoQpO+
TE2AeUhpRCoS8OKeIIlYV7Xd7ZerTT+PqVWrr32rfZXrRH7yfvIR+Al/IdtgX4xyb9HT/sP+P/s/
1ex9/wDY3n45g/QfBfl2xf3f4x+b8h+yMo9yFb/XZZtiXuZofzUJ9Uu0rqWzyI9vCgEqaoIs+eQg
hzmxTSwgQzlMDicm8XKkTvS03YUdO5sUl/YZZAe23IyKzmqhLwQijagHRdVyo0Qz67mQq5LFh8bJ
OWIl3FlKRpqyNV1LzbIon786o2ORSE3GZNjPLyORYod1ywLHMS1iS8rL6RCWVFvEkYccE0xzcrep
dhydpdhSU8JLpy5ZGMhlgx6OOkeTFHJHcw2xl2YW8EeIJA2TTRTzvTm3Osq+UgZEYk0tXYF1amQN
c9N1CVGeVCm9Ixm8ib66IjsW7HLcfuochp7DFB7IroWyHx8SHHLytszcoHyY0aSis22A9a44EIC4
ssgfNZxwWI8JcNy6srKaGDOR3DdmrIrC2ImNzLeZQHBZ84M+tvT57KBsdhX2AkJ9zQmMPlfZs5u2
DyKVDB6KsnsswCowrvsi1xNjHU9kTI7zdgv3twaWy9B2Q49mtkBJRtNhjuVfZVZD2hPs4CJChDos
tt7szIil3qGCo5+O+q6mYWXDsZJsjAcXJk5GCae6aW6WNOYOrSYya1OXJQ9TaCUkbP57gDsj3pds
p0F9Jhg2PsqMtHxScN+7NiscCgkU0XOUTZLGIqYlcnZ0jMkER9mfd5YRlVZCNdWmMz472Qq8Yyzq
bbi2YolpdZDb4lcC2YT7GsgrsGrwKsmY4Cwhr4ejxGihWVT0vFaXeJ9ku5jDPlLdXU12euLphNOY
IW5ABzK0ONYGjzjRxNN6eIiZI+wN41b6EJ+yUENJk4Hoznvqvss2eRDAOqStVArXW+O5ZPXtuejO
cb2PTwR4ouI5IJgI7EWbCONYZpliSVwoLknpuyzhNfUwwy3b5Ly0SykMobidw/KgkU+eGPyF3Ki2
cNmaUbAIV+8RH4CX8h22BfjHJv0dP+w1XuInfa9Se3rr/N/+37G6T/nmH9B8E2xb3f4x+bsi+yMo
9yFb/XZZtiXuZofzUJ9UydsXHWAMmVIdJ3JKrIZHpHuDCmkPWRWIzdGCNI7bSISZ6tik1VO2Ry9f
UvcXROvVdd1O1Rzu201Rd3VzdhobC2vgBhPTIoKUgIFeM1s/pvNpWz2a6pIm+K0zkXcAeTknTxJK
iDMuci4VM9wAPMy1c5PLE19dIVwLIjHR7IRxL9GkOp7WaF8kO+8xp3NCicOGHhggiP0HiTX0qJmq
tbvPajpZNFVXvf271c57t573rwHjTb8Uw0cicxUTOhlJJZBDxYILKWdiKS9v/B9q5iORNWouyov3
W+yiL7C/93d6vZ02REbr33Wiqu77Kqqo3tV3lZoiORyo5ztNItlVE0XXr7qds1V9tGrprqqLppIj
t9NWv62t3U0bpomnU1E0VN32t1UardNN1Wt000Tb+VOpVTTXq6tF6l9pU609ju7dqnsata1HInad
s7V6elsRUREbv7jEXXeVzXK3Zf8ApOXuK3rcu8vauVXJ1rr1r91O1VE+y0+8n3P5l60/j/xJH4CX
8h22BfjHJv0dP+w+5+wT7+11+OYP0GwPbF/d/jH5vyH7Iyj3IVv9dlm2Je5mh/NQn1bFjY1kc8Ap
EYkSy76tglcjOG0GydNvabvBirrGZ+ujACdeGqeymiadz2vudXve19hvVt3qKu45E16+vRdNe1VU
RdNOrVV7m4umqWaOYT9c2MUjJIQSpo5E5OhCRVmgqIYX+mzoySZxdpwoYiHy2UMIJIVNaugiMa9K
WwnR0tcaKqKyuiJa1UJDjejlQqPVqt3mSxyQOYk0UsbVWu5QU0N1oYaYYNPNHwn5NKgHNrA8cidj
uhz55Ufw1grQrEqE2Nw6s2YKY8CacgJ9kGbWRyw19iNG4Rk8wyEyESbiKdXkCS8V8ZtdZBkIrZOI
yOFB5ioILGqaL2QpBB96EDAefWLpcibjsWvnGnsDoWktbPI2pmyGyUORKmJWn41j+OiuxXGLCqpL
FYxqhrxhzKYKxSxaS7NwbAAQOCyF5WuFwS3gOgCkZBbjKW7onD1yFmPIHm2Im5CBFShnRT1hNZNS
MmgnMMtjIbQU8e1UmCYQMXo9zWCzPPjePYmZQgrsZ6FxbKcNoXgTCWUt7aw5WPjSPfGZDYoLVzDk
XU0tXI6qtYrncStWOvmglNk7IWRzQ4vNjtIBngMeK2VEYeeUTiiWImt3YyXUASiWUwMhDqZMeSRt
cXE3pORyrK7EgaRaUCxye1GphzLUUgmoq0bTWFvJu1Yh9XMdLJFVvBBr47UDdlnSVxMiDLASDR4t
WV9xe5Bl3Zes5iRoK+yAe2kzGVk8NcJb5tgjJGFS2jZ+O2+LJBFHX9q7BskpQceMG19cFksloISQ
C+OUqAbDJ6uOzKPk5c18cpA5fM4lzbSUElumRnNEUKVgz8TqaOHFMXiiwfGsosoFojSQyBbcgwTo
nF6wS9p21Q9c2tkSU6ci1jHebXw9HuTedJaMdj0cWGCXOS0KHNjqWzBlY+bMAycg9ubFWpUh04j9
6rfgVPybTYJEtTBxkJseRFd2ToRIrGrDjbXf7jrqsZgTJ78ggJLbmbbk+YFxq21PSSxdHzg8sPF6
IAXBTQ44222U4Fk9r2QJ4mRNIs70W7x7hl3UkSqs54FrYX9aK8iR8w0KlAxtiihdFF9h91U+9p7H
3VRU6/5dk06k9hPa/i9j/EkfgJfyHbYF+Mcm/R0/7HTT2F/hK3209jXXu9xer2e6ibXX46g/QbA9
sX93+Mfm/IfsjKPchW/12WbYl7maH81CfVs4kajnSVxjGMVnE4jnjytSLhchaOl33bqcOOtsZHdx
AiVVsMvdT7Zf82u6/e9hPY7m4uvfNaurduMWQOOPq1vGKkjhgRX97q6WRjV39d1re7vbIPFb1khK
u3OAywCknc/uNbw0ndLvK12qN3VerdEXXvHGCjRQkSEjvH4BRkwLHxz6Mn3jIArJ0PDGkn3N0Erj
SNhjV8OqzbHzXZGK2JxYxYTHDvOGFbCYwuSVJYeQIke9C7E9u9AQPI4eTtXxJI4dohBrKyNBcejp
2cgSS/VY21rd9GFixzbixgNYiTzESaQR7z9N1sZ8i1wKvtI2Q2T1Eg3rGGNkkccRy7n13GxksrGM
n32tbLK1qIkj9a+znxfHZbKoiHHqbCSlrXnVY4mvKQ1xbhlnCiF1Xl4xnxsg1Xho3avcPW1461Qj
6+rdCGNC6sAnSBswYD0i+tRp+TASQUfhRycmLxGuSCJrbvKzq+rs7ewtYbCsMJpxukKLgUVRRuir
7CdJi4uIlVzDpxZBmu5hWtZozfebbzYzj8ttZCSV9jaSU1c6xPBmgYNKEYco/MlCyDMYO8eeV8To
GthVqxojdn1NxUVltVSLFv1lmAKfXv4Dmvg3gyopR3cF7GOh1j9Lcxqs0VqbR052KY0bUQlSHQ1Z
dFVkV0RsqyrKZGDMK8ZhUizzrIQ2JJXrNKrnrxH6xEjVleOSPXx1EBEAQ0U8NVC5HxVkUscbXx18
T2o+MJjkGY5Ec2NFTapiNxfHS4qDRaKMqkrZ46RWrCrVqWSjObW7qjjqnJpDosEOng2aPyVmOULM
jkarZMgbUV7bt7VhQZWvtUH55zVGa0dUWfTgokXeJu/UsTaynq6424mQm2LBrxBCrQhu/ukWM48U
cpszeJJpKS6R6cR+i9suv2aR+Al/IdtgX4xyb9HT/si7/HI/6DYHti3+UDFv7BlXyJ/IntfZGUe5
Ct/rss2xL3M0P5qE+qpCD80iyBiqOzc4kymmwBNT0xWRqjOZV/Ce9iTL2izQN33OScdySxu3muVq
SK+OVF3Jh5o5I45R5ope0lhnSKSFWSMnZA6JWotjIXaDgPoW8zwTZnCR2rrBjK0iBJFmZDvixFM1
GZDGiKk7omk7zkPgAvchMvCI5uhI3X9gaU6whakwb2OI1eyEE9opKpv8JGxsl034YlZUDRuJe2Ou
FckhL5yJ3q6BsjnuWZ0suqK7XhapFBqkEKMijjYwS3ts79FtczATMkzl7h8bkZg9rXvDkhD4uKVF
ZwukYpbncqLOY+yk6JY8VGMllV581rjeW05YPQT21BgdVLaFi5Lbx0NWaN0Xc2Vc5JbOdYZwyChb
AF8T+aAjjbG92ZSX+I3NQDj9zUVgLXz4ewuWa3BoXQ1xZHo1KqksJDrlJGGKWLTRhvDgnL6UdOGx
1pEHNVWxy11aEHZ8nLKBaXtmHS1vO9HGWIUvBLsYJpmjGFRPjie1H67yJdV4uWWlEDiRgFHzNfX4
2Ta31o6nrLQywt1sqWzBhCVLMYeIKqrKeRSI7ElpnKvEgFyaGuysjFw8UKFpoGAVVCWlvbOqK24L
PvFuQbORtarbEQUICqJqDUjQkmewl5kTkcYkMdHBjd5hOLzWVdHBE2OryTJDciiCsYi54GWDxDSq
cWjEHJkRs01rWSMHbI+VzsxGnLifi0VPSG4uIwaFj2xdKZDSn2MpPDQmfpU2mlJEa6Z47K3knRsb
NIQ582ttZQYkPcn17CZaqqjwE0Wqx3fsa1MicE+/TNIMjdMyNyGw4zLBWHVMPHuwDxm0+SBMdTWF
mZgDpRnpCW8OHIckx8SxAepIyMe7k7AkN0yjRSsVeLE2CZrFZi1eT2Qf9zuosaXMDCbPTFfrqxqn
Y6lYLrlNTaxy9qec/ka9sBpmm6yTtE07F1jNluSYmbmRtVV39EDV4co9fLJid3cFyCMv8St7QU15
1ZCkkJppUY8b5h+WZIiPZf43YGy2SBg0t3WmkwhwEqHbOsgZg5UAFDFmUQ2mmmbOyCOThHxQzN9J
ZNP9i+wnd09lfv6r3PvaKn+rZN7TX2dPb+/1a/yJ/wBn+II/AS/kO2wL8Y5N+jp/2J/Gvsaf7ff9
nu/sLv8AHI/6DYHti3u/xf8AsGSf/wDX8v3fsjKPchW/12WbYl7maH81CfV4Is0cE6EAkRyzROmi
a4M8Ytu9E2WBX9tCmkfGj43XGr2dUjCBHxtKYY4jpBSUinWwUhvCJUxViZFLG6JGQOgbEyBkbEFb
Fwo2t2JEGbEHzbTE4kQ6MRCC1nnlJ4bOGr5ZJ5pynybyLLO98rnLI9yqRYGxyRRi0ggY29DYxske
dJDMRuvLKK9NBZXMhcsT2cTmfTUVVVz+rdVuiIjd5ER6O71NN1Ea5+9rp3FXRO5tDg7+ObTx0D8b
kWeZIyiQJROTIWUgOKPhyEQLvq+Lhq5ZOtNdpmW17kN+YSRjcnSlo+nabAFit4PfV1bDHX09cCgj
jotTp5Q5bawjle0uwn4AaD5GZX5Lf00mUuBmsIQo8ZMgjIEGCr+eFHvMbt3pIZWAD1pkJjyAUh4j
4A4Z9CNh8Op5+XStFFWlLJRjVisaomK1rjp4ggxgo2RWgwpU7Aw4RI274AYwjJI9G3wN9eYbZnhi
xXcGOz0xYFjPBHA0d5EWQ0FqMswTWuAita0SusCglHjnm4QwcY0xwGQ5Ljb7EUcK8jpCgUddxCxc
vBxybWqsj68toaSivtseKprmeGMN8h75a6skEsBOGWMGfi9JiMAYc7YWV1Zjk1sVTTVkjouYGsq6
S1Wcc2SaRRig68gdYyonSOW0A5iNyY9UYvEKsrZBIayiJsiQuHvRcypG9aTxTTSkypNHFC7cSbjS
zWdSTkGVNxW2NLsiMRGNrBKiM8wtbOUgWwHp48rHYlw5bdgTMj6OaWqw8mtb9YbJjVlkN8S9CK4v
0Q7tBFec1U24tyDPuQ0MdCroiQx41atFwpYGaSxvlc+Zae4scgvL+0pQ7wEYy0bQwOmGvpamYhhM
NFRUwjlGWnGaG6EeByNkn5lSXOjdFQlEyEMkx246bCSB0bWSldGWdVwykkilV4/L2pD92J0MnGZC
7i7jXxyZHf2CipLZtrKuuiFllmSKjpkNmEcU+YcdWnkn21nMRDEkg0EKixRzTSNmmk+ziPwEv5Dt
sC/GOTfo6f8AYemnt/e9ju+zquv7G7/HI/6DYHtivu+xf+wZL9kZR7kK3+uyzbEvczQ/moT6s3SX
BUGViDEtKY2UWSIt6CrDMx2rXMnWdInJK10aterVTRz9lXqc1zX9aLq16PRq9S/bJpomv3NE2yuk
DzK8x0EIAGxjYJYH8vrHWUKSQRiD2Iu4s0h7nq5iJvdsm93U2muWdkjIT5KyQadg5EhywSStKih1
liKuCoZB+I9ZnxKMSsiR8Dg7r2wz092Sg/MWFeOXMwXRsG/LFvPij1Im4fDk7TWaeSVqtek0Ik3E
GhqJ8gpqvGwMixQ3LaWwEyXpiLo6qcB0nHb81S0fRcocVsGQ10SWtfweZWYwdwzYiK18uXYsxLgi
YSp38hqWttixC4gixa1ziG88QIY7k5oYHPdES5sBCMkfowGmOvKcW6sW8YCqLswBrQyPV6I8YKYz
mSdyNkjJphmTI9zHOY3htdAlxMuV4xw8deg+QSre1axUkkk6iNZbOcYjaxZZ2SQLEa6F7iG8NOKr
WqtSLBk9C4u/G5ulHZcVryboWZU4ZtYxJHONjekb0gmH3xnPasWjtxOHawi5LjpRFGk77+AW5q53
VCDNl5pbiKMzWv4bRSGyc/I3gOhn33OjHkelcDDlOOSm26kpVCQ3dYpNnypJQs/R4zS1IObGUMVC
5A2zrERDNG/cfEqN/j+7/wBv+ydzup+8hH4CX8h22BfjHJv0dP8AsP8Al/1p+xu/xzB+g2B7Yr7v
sX/sGSfZGUe5Ct/rss2xL3M0P5qE+rpEOpbml1kvKpu/XCQ2Ysyxdv6XuqyN+++b0qNm8+RY2b80
RI7zHQyFuNli5XhvZUKR2sUFewyGVZeCqPIRC45onFcVOAwZWDR5cYWlkdGQCExrhYRpJmq+tpzG
RNSN4TOCOOzgxb7XPfHCyUmaV6yyoZjwQFlXmHObwzLYMYSta+MxhDEPJU97WMmjjngh4jZHvJdA
n1nC0yV+J7/bOXHqtWrI+R75GuCHdC57pZSJHtdEsbuI9Y3bit0FDboLFYY+x/NZVZYCdiU9pY3d
7cAxPIqihFjr47gw2OmrpSpUnLBqIQhZ+EiyQP5UbhWDaiHGiw8iweqwi1juijB2UUVbJbNQ2qrx
qs2G8HlZfTukp5isfbzVaFG2z3CHrX2sgUVXZ0WRS1ZRdrY3R1dk9ZIBShUiiDgMorAa0iVldBYi
pPbVCxlWFnFOOibjp21c1NVWhdSHWBUtw/srdkOBJErLQQoI4WqJo7sDC5IuSEOlgoefAknjfVvF
hpCn8GgPmMrkLSurhs1vIL1ZS7hg0Nk/otMYdiAtMk0ZNj9Z5LWl4ufO1VmOA5SCOmITGTPQsPHS
4BlWDY7Z1xNi6fIOm61oMZ15BLWMShHRAoSzKsObK5J7B7iojOFXuYdQ2NOytp64evrQMjNbekvW
yra6A/dpW4rNjc1VwYZJ4lguwryisWx7zZIZBBIwJXbyaKr1X7unVu7y7rdVRm63raipojFV+7xH
/vGR+Al/IdtgX4xyb9HT/sNf2N1+OYP0GwPbFfd9i/8AYMl+yMo9yFb/AF2WbYl7maH81CfVljjm
cM58ErGERtjfNBLIm5HLEyZko8ixarJw54pY3PbFvxPbqm3c01XX7vW3Tu+2neJ7TUREXZZZRxu6
k75XxR+EiUdzXq9Wqr5GIINJH9sxQhlRW8GJWNgErxIgogyHQScokb3OFlqGRSQekxLDE1sQ6Ma1
EVFEGVF+t4EjequRrGM33K5yIjU3ZO2c5Xrw49WJq90SsajXq7farljniqJTSWwxxypORTXlaCcL
NIrGG0x9nWB115Wru/W59NPYBkRSjyqSkMzJ5W6rqrm66J3u9uMeqpor0Y3e9lXzN7Zu5Iu85Faj
UTTttF7ZrlV70d36dsiSOa97na+mKjHOc5znbx1tYS8uBUhkHmFbjpUiGGjkmlduRte6RI40erGR
enM00Ru7J2zHM645GNciq1zOuZEVF4Lk4jFlbI5XpJuyN+2RN5XbJLOwh7JJhR90QA+wn4xE8cUb
nDgQSzjwwvXeeXI1IhGI4siYeCGWRasc2XhTXVktVWNSOVeMdyhlmkOsUXpSPHrSZeI6NjHcNvW5
VR7v+5U06kVE69P9SadzTq/YEEVpHMRC2FjVTu4U0W4fUmzV9hBpPHE53LmDzQ8ViOhl3OJDJJE5
r1/ZQAyFDsNKiInGDfPG0omARYGlTQDq5JZohnEjIRJG1zIVIgSRW8Vm9sQDYH8uULDRzzxcqbLu
RZJcSUNK7fgGkjdzltFILoxznD7vHKSAZUmX/G9z/b/t2626+2qNVE7mqroq66O7iI3f0Xuqu3e9
XV19trqrtO93e5/ytfu9zr27n7H/ALtiPwMv5C7YF+Mcm/R0/wCw16lTvva0Xtvvqv8Aq7q9Xtfs
Lr8cwfoNge2K+77F/wCwZJ9kZR7kK3+uyzbEvczQ/moT6r1nmcNBzdWwghkj4HQjyWgaTv5liscN
uxovp2+jGd2Tdb27Z3zxcQlriEr+b3gXmtYxijSWDIhJ1A4r0fG9Yx3S8ujSlAiImWvGo7ATFmW4
1dzRRc4JznEwRww3kTGtgc2FJJpRSg52jIyZsRMk0DSTWwRFSM1RGsjqj9GtTdam4VSMRqtVN5sk
bXLFMj+24zJPY3dnaxPm7RyK1mm8rXdTmNRVa3tvtmyOa2TdajeI9qIlvR4izOPQXXBY1HDHY0F1
Q5JRV3TwQuQY9ihlmDXX900bEWmzVpsI1rdCGRsZU3M5stYJEBbAJn8mGhdkAMuIayCy20yqSgdi
tkDYpJV2POZvYU/oqNELHgtRiiUkGLngAioYqkiSlZazZ9WVBJ3ZfNnbGVk+PkKIuXVJGJwlEjS1
9mAjq+TmaEdSg2qKOQE5hA7iA9mC5GP2S57UvsQCjUg1ILkKsIy+YO1iyWHKY6uCIOc4mNKhOXy2
JlbwFJ6EGnsHELsUBDMTuCsWiPWKOwrpxiUDgaVCPOkIznTD8wjObAciDktlG4kZYRLWPKJ9Eotp
QWGG4gkY0lkL05MFmePrluV8sM3Q2rtq2GLlj3N9Ipo8hicQCIcURtj0hA2ez3Ff2Rbom3cYLfJg
41FFTZWNjMtc1UnxccJo5FWLEVSNlso5nkOyXiGzxol3IdcZrNfTRVPoqp4cX7IYJQ8MeUB+iorF
7+4vbjGibDoJ9uwAXsaDU6lNliKqQWli1sIuRSDplMuP9JNdi0OYPvOnnQNrROkGquW/4TsBkt+a
aD6IHcynpzhkbULXK7J1hkzwBtq/scExCoF2QhisfOJzjTKK6tsM0trs2y6NpXtjtbKlHqcVMAiQ
mGnYLzG1xUTydkYjCg+yFXcWeuNzC5yd2MF4UIU6OuuRJjM1Pp4czkjYZJSmE2A0fNBumbWQmwx5
ayqFvBMgktOyQZQR3I7YbyWUu8uiaUmWOxYkMhRTJBp4JTEWCd8jJCFex71XMgseTsmHVqYjgiNE
yaXskSXVSVb5Jfh3N6NW84DnxChjQoYQJUEgk2jK94VOZBW8GaHD6u9tM+hqmQ9lBLAuAjLsWJMg
jyCm9CHSJJdmZkwS8k6YimSzvpruQWGUUs4od1oLPSWFcTl5OU5B2KcqmuGXhVgQENmwg+Puxxei
7RW0eN2ayz2MMQo4tWOcjJnnwEPglnbbIXdZBaPkcFNENkuLdkbHZq4p4r2kRtI7I1/ktjZNleyL
mG1FmtOHLE5w0EbjHSTWat/3SfR1vUKZ5x25s1vLNvh25f6AUKRMX3uikteiF7H3184PknAqtioi
rUhVhXZIGw8zsiwMhfYnZfX5I3G/QVcdLsPPuHR5kDRT5IjIRJ7wgc+Ep0ctVOLB0GQmD2N7HnhL
Kg/so44Ee8zNjFaNHloT8NdeKFO9kwBtTDPxLq9jWvuRRQHXJxqj17m9jt2VzdlSerOoLE3LVqD+
yCZk8eZSC0kdPEfHjk0mU19bGHFdt5ISMajSySIi6iceRFPMktrW3BtnJi/YSjMIUNSJZTKzsnnW
NnGRNXxOClsK2ufEZdcoroRmq8pVQVzJV7I8xF1mEN4tf2RIaemAxXsjSAlBqEe/EJKTJR8gM7HY
xcYzaqYJ1Rj9Vk77BktcZNLYzGvMxIeOXN76KUAGKcQs7slxV9LLL0ubZ31jeteRhWQOIllaPJje
RyDE1bIQ2Uj2x8jTu+xCPwEv5DtsC/GOTfo6f9kXf46E/nwfB9f5dsV932L/ANgyT7Iyj3IVv9dl
m2Je5mh/NQn1XcOKGaZGq8eOeThxunZ28S67kmj2zJCrH7m9GvbMd3U21RqJ3NN3vdE73d007XRe
rRETtndXbO1RzlZHGzr3nOaxrEZ2yrq5NNEYju4rdETutZq+OxsajiiHyMlaQHIkcMBCESxOmNHg
0WVElkDj3/BLxIXb0Eb3zb2mqbqo72ftOtNUXtUbovbOXV+6iaabz26d1qu1emiP1Xqc9dxN7d7Z
247VnUjVika5ypDptp1aaIiKzeYitVjetrepY+vqa1HO3Wonb72qJ/3qn3PY7nUvV7XVp3E27nc9
nuL3UXTVOvRVam8ncd9tqmywiCDiwrKQQ6IWJg8TiC5XkFTujhRjHTkTySTzTORZJJpJJXOWR7nK
miaaaImnVoidaImncTqTq7iomi9W3W1F60X+Pvv4u2RHf9JEd3UT9jMPIsrY54pIXuHInEnRkrFY
5YShZISRpURfS5x5Yp4n6SRSMe1rkOkqoTVJs5IZbA+1uLnILUvlouALHPbZBYWdk8YWPeQUTmuV
GWWd8ELHkTuk+ziPwEv5DtsC/GOTfo6f9kXX3LofX4iYOu2K+77GP7Bkn2RlHuQrf67LNsS9zND+
ahPq7wj2RzSE147ZJU1jYhVgMNKq6K13VHK5XaPa/dTWFUe1VQwqSGWB9fJOw1kUU5ib4rGPn5Pl
4JJDvSnt4UY8fNrPqHOIPYQlAwY/QEFTYniFjPJCTkjxpElLNgIdGoEc0rGsDTiQOZHKrN2dqsNH
InFmFndj9hSUxLiBRGpAcHm1Nj7LB8k0icqUDZMkfavdCsb1KZH3k7IuL6T2rDLUHoI58M3MivMF
LfXsR7mucpkK8pKiRNjIfK1UYjd3iRvWNGr6G6htBj+WMk7HxJeb1UJMnozpCs1qqTpO/aLZUtiL
fFGPiIuOkDr0S1rCbAEa5fNYHNqrl7JcYWrxXIMTxi0ryK6xgt743IBMfJJsKszpp49JEi5FE2rr
Ca2/U+QCaB1tC4jfDsShn0jrAzNcgxbEakLHJrUkyPGrTIITpz5rDOsVrnK+qqOfkIfYUwoMYhKs
6TIsQwRXZBWehEGSo7GNZnlsHZNIN6XNtGWccdbUTgXccdaJCXTys5ybpvm5DhAWNHcnPyFVFZQj
k49SGUtfeFxRVSyItpTA201vzZ+bVNkBXjR2bVgFgxC96QgBWUe045rwq5cZpSaWsgrqauv7Ai3r
ibYq2HsrOxr0Dpxw7ulaJySVU6lWJLj0bKdXM6P3Uc4gUyV2PdAWOaZFhg9JDAW3IQnY667Hmtyr
d9nIGZ29DIYbTR0IPRYBzpZrqZKzfsJyiS8drJsp7FGV5ZVT09XeDHUBmPh00hcSlSZGnNyHC28s
laaHyS0J8cG/0+yB8hFo0yTH7UXEuxiLm1ssNVaBG3Zk/oojjCDfLf2MdRAnQ4UhBhLbqXtTN2D6
7idXl0ORF47azRmdifIYLHGwDquCGG17ItUKgJYR1xfOeu8A+cGyYfC0+Hjt6OHURZJ2Y7h1RHZW
17m3Zjsd+YWtPRIKPNJ2OFhCs81wKGSSd9oyWQiO7nnDgGerag1ksk4OYJV1dJG/HSsbrmVDq+a2
tR57amxi6uCyJWZTTV9o2ihs7RsdYBKJNcKwZBT4pIOFaVlnz0FkpYyPeaNU2FFDPK1zo5lbTWpB
dlVq2Vj43gnEzFDva6OZ++i/Z5H4CX8h22BfjHJv0dP+w/fJ/wDEmmnVp233/wCPX9jd9Wul4Hr8
ScFRf5urbFfd9i/9hyT7Iyj3IVv9dlm2Je5mh/NQn1ZYy0IUb0uaTlWkvnRRZEJZwkCjkKRyviRH
OiTibvaR+mObs2KKJsMbGtbHFGiMjjbup1RMajNxOtde0Y5Xarp3uxNPbioUGUxGvRV7eJ2jkYRD
IvWydv8A5Rq8Tudaps65yG4nykyvjdWY3zyySMpqjVNxm5I/hqWmr2uk3XKkaRqx/EV+38qa9zq+
5ovUnya7H14OI4yEDbK1bUISirBhLNW7+6tgNCKyExWcSThqQyRY+I/c3d92tfbJjVClrUjRg1Vm
lPXpYVoUbZmxhgG8vzIgrGzzo0eCRkScaXRvpj9Vr7HHqU8B5rrF4JlWCSG+wkfJM49400D4XGOm
lllUpzFm4sj5N/ecqqAAM3FK6rGAmrkdNhcFrkgIZXaHj4xdy3YImOtMAVQE3ag3gPe2ZNWo2OMK
5Lx2iNtqxsEdXbE1QJFnXRDayCsCsJYXlipA+WSSHgSQ8N8jnonEc6R4RF3Q09xPWTKRWzWlaHYS
186rGqzAyFwyuEk3oYX78Cxu34o5Nd+NqpPkUFBTQ5AVGkJN7DWBRXBELWRRpDPZshQ2WFI4II+E
+dzOHFGzd3WNRBoI6WqZAECRVhwtrxEiErCmQRE1ozOFuwV5EQosUwUSNGkiGHidGrIImtbHUUlR
VxsDjr2R11aGExoEUxJMQLWjQxtQOMgwyeMZE4LJiiZWsR88qulravGMera6cyCwnAApa0MKY8aS
CYY6UUcaOCQweYUaWAl7FmikHgex7XRRq3o62xjHrOv56e05Gwpa00PpMp80hNjyxI0kPPESEkST
l7nMSvnmdJI50r1UmrKxrHyawxQ3F1xFNXTAFOr4BxgHEiSDuHnUEYMQcNZY3KNAKPFDuMgja0cE
EYcIIOCIYQMSGMYUUaBiRwjjjwtZFBBDG1rIoo2tZGxEa1qImn2eR+Al/IdtgX4xyb9HT/sNE+//
AD//ALfsb52n7th/oXgu2K+77GP7Dkf2RlHuQrf67LNsS9zND+ahPq802BxOkwUCQR7vFfIYeMIz
cWRzI03HTpJuOfHx3Ma1ZoGtVyxzCyMdFrwnNaj96OVqObJDLC6KOUeUeWPhyxTpE+FUljIjhkj3
UyitChLri62kkshr3iCuDaXGOs/CiY6VksskMb4yEe+B4z2rHG9vE40TTn5JfHTWIxs6cZ3JxokD
AWObE1vAbFJulQmu1SJyrqjN5U7VI3M8M2SzZEj99zNRzjIoUkVIlldFo2FjnQsdI7vm6rvKsaZX
c5ARfkkY/XXuOWdVQ18GK210YoMBFMQJW1ElpiBttJ0ODbtsMt5p/R0MNlzTLGYgWkCpbmzMMsLo
AdBpceFjkZj84I1sfEtxe1cpIgJBcg5MYcRVhFKEa9wXLQsmkNvsupjKTczK6xWrgmMxYGO1kBtb
ceKBtjYZW2mGMrwKmfpgq1t6etmPHIZTOsGzAxkc2NUZDaDMxkfKrAusFqTQK2ilNtACyii2XfKm
urpqY16i1E9kRZjyRy4/FcRrI9h1a6pu6YwEMCz4VzBXxtMqbZTGV1qJKBZ2UTByZK4pnKGSD2Yz
+0LCgVrkbildVBXQNUZnB2PF3pgdZHTXfRdDkstlWB8yQ+5FeJcVbI0MKrqqKwUAp1QXYAvbNJwa
zjzteVXQDkxm44TFJDcWcNNWnkiVt9ZXVKLLZnVQjochqKi31s4ZuikYLZsA1OJu60AEHNZp5ZRK
3oIyDD5KWO7s3Sbk167o8o2avr0FQaIuUe1WYQhjaoiSK+yShvMdiMsh6ypCuzcNrybaUgaU1ksZ
M2WJTVULRYCJZPRJa0hDXQqLwFMlGHnqwKGttLLn6ca7KMgLxhRKYMok8Fima5GhVi1p1aUI8vGR
b+u4qRqw18U0crv3hI/AS/kO2wL8Y5N+jp/2H/L/AK19n9jkLv8AnoP9CsM+T+bbFfd9jH9hyT7I
yj3IVv8AXZZtiXuZofzUJ9XgizRwToQCRHLNE6aJrgzxi270TZYFf20KaR8aPjdcavZ1SMKDdGwp
pik8+pTYyefeSzhTqYzcjjnY+NiQOHbGyFsLOVbGkMabXAh1PGzHixp3rK1lco5xli8B9g14KuIk
esr4ipSJSA1SWQqVyzOkXq3fQDSw1L1VjpB6nDGFwPc5V5uRXhv32bqNXgsg4ybzkVN125s0CB0q
QMQhiLvcN2sznyTTb0MEbYHbz5XM4TWxI5/adxm7dT8bJs+yC6qVxcKe3IxgBtGC98pDCt6vFxmF
gI9igxxpiJaZJIogigpO+FETGqGS4tmU9FyKkBQD49LFelV5Ap0R1gXZ01lZiEPMEfO8ihOqT2zl
yztmimbHLERwb/IgJUycvL6goSSnYRjlvZyWC2aVLyKWZhQlu20PjPByJLsXdIVjI4omwMjvI7C4
urKfIsRbhdlYzdDwFSV8b72aMqFlZUAAQHt9EBrVk5NoXpIe4G2VJpJpr+N5Li56Ksx57HOhcPyd
QZaGQSNRozJ+ZWe1LbK9ZeXfEkHDgY9HueNZNvskUMDILPKQsf5mt6HDtbiG3ZYvY1lU23mHKlub
EiIU2zKgCIerK+IWBVhWwxr0RZCVjhNdPV11EW6hkFx0Jz15ZlOdHRQ3crKmPcFr+nLO24cY8O8j
3RRvSrFJYUUHV49fYxy0ssSMsq7JG1aWs1nJFDHPPYELVxyc4PKI7iEEyPY+VzHxghG5nmBptPZj
2tDkEzsXZdUhA4c1dwx3C4uPWWEBIJRgpjb+suHkxlzOkkWVIZIscsrjKMgu3YzNzgQ54eHRRz2S
RlxJZTk1mJ11oOQsJfBkhqrCtryIR4oiQpo5C2lfvCR+Al/IdtgX4xyb9HT/ALIyJf8AnoP9DMP2
xT3fYx/Ycj+yMo9yFb/XZZtiXuZofzUJ9WWAiGMgeeKSEiGWNJYpoZWqySKWF7XMljkYrmPY5qor
HOaqaOVNpuBPDOsEzopuDKyXgENY1zopN1V4cyRyscsb+3ayRn2qt2ntTxR+NLTRaF8jzZb7Gxgh
HgcixDTkNVxpEGnDVETiKjWoiJsDWhjzPU0Sxihhs6rIHDETwNYTBo64DfExzKwU+fixK3f4aNc5
2myu6KqO45PUoC76MZIjW6tF0b/C9O1RFbpp2y69j63XFquH0eFihywvYGqVSk0dpeo5XxiyvORE
rXCvFRjEchCS85DLBFAXbvpTMEty6urfZmcW0o4xx4XjslEIvDxYrB1YAUx6P6SUIjhxpxmjksYv
HbOi4zuuNStZNG6qcP0pMSgMdaKSiqiHvsJIw2N4CSPK9JYGx08LEtFSxwl3Q5EA97I2ak4dOVNP
IGOyxk4snITkmM4MLC3QEvKicImhy8tE4Qeww0kt9ay3eJATRTFLUPGiLit5B0c8ro1BZIC0M3JY
ZBCGTRSLAjHrjMtGNimRB5Fki42lhWE1EwY5kdJbWzkQoRpjZCNayNrYNYpmRFQSq9qq3STG6XEa
CzeCBWXNtIeYNVEdH2J5gLJaWviobFLGeBoM0hfPG0AOq18S2jEmIWCyrHm4YlnUDS2NuCpNBz1a
DE2OWQ6zGaqTBiwwzQOeSVFFHHE+FXyOa5kkhxiz4D0ECBCbJbMtKeTg6nHV5DzouVaGEBEUE8WE
91nLxzojg3jjSAqs2OV1VWY9bV+R1OQWo13XrWlB7lERTDKyBRx5oS2kPtXIs0ZTEgcK5m5Ksi8K
2CbguOz0VLkmOYyXZNPZ05IZkgtLMPOFjyYu8UkcWW8HaUi5DERy0BRUcL1jaPJFusxp3MHkVUG6
yqXjWgnM81WxaJ6YeNyZfMBs1Ih5UniRt4Eu6RLRPxS6jEnUYqSpWnsWDEom8o5Dg+M2GdGqirFI
rXoi67u1vCw3DHy4+x8l9E0ijdJSRx7/ABH27EdvVrI+HJvuMSFG7j95U3V0ju22WEOpZpJ4YrdC
6FauWYaKecmKM9H8q+QeAUmadjZVdFEPPI9GsikVuPUTCMVIKygAuxppx5MflELhGIGGibFIk/En
lspp5WViCwkNMWvsWtejhXNXpSa5wGKs5poPSMlhjrAedeM0xgfNulQfmnhvYU0ficVwz2zozhOR
2xgMeLVB8YoWEGxlM5KNhDMzyufGW7iNrp0RoLYUsGyJI9DUfy6INpzC2FY8zDWWVQHJYW1e6eja
dWARMjllOsBFdxwg44poZJCSWRwsZLG9z0a9qqAFBZYROZa8fowSEugkJseWmnHJ5CBj1lM5cgUm
Cfl2ycKYeeJ+6+KRG2kEfawDWLYx4k7yGN9XWEujjT7VnHnmejE7Vu+qNRE6tu5p1/7L/t7GncXq
T7FI/AS/kO2wL8Y5N+jp/wBkZF+OQ/0NxDbFfd9jH9hyP7Iyj3IVv9dlm2Je5mh/NQn1TBMLIqw7
2dGxRmW0hEMAw82rCZh5RgbN0Z0bOsVZQJ4Ff3zV07W6qrmyGks7i+Ot3GVhE5ywKZWVQDZVKtq6
JTC98J5bnzBcrxXRDNh4LVi2mqwnSlmrXVxY8MiRcZ81eYJZDApwIYh3R8OHlOO3SVzmCue9Xve5
0NjKESMFjU1vCbLOzdRlpwZKzo5d1HohgzbFHzNarUVFVm7udWy9apvI7Vkjt1HKr95GOVXxMiau
67f425G9XQwwSRq+few+mslo0x7BCDCKwyuLtHW12g1edTVTDqwupgDqXxg2Tzp+DeXCqXExsLEj
lVq0VPDNSxH1vY1zTCzpBXEMgIsskGrEYUydR2zvAkJrpyyXSok7iSnywwzu03ENeSKlFujXnKRK
+Qj0cQViUancPg8FavoeNHw7so0rDoIyFkYXNLuw0codc94TsaHHuJs0zG8Sxp6HJ6i4Ka7Gbavk
qsf52vruI4WnfYCqd9Z6QjK9q5JPjZdbj4lyBYycZl0RbJZ5M6ugCrrWenOxxqUTo+FI2eSruThj
ESGwsACzt5+wViRIDAqZ2Lls0PooyTJiFBjwsvF1g6byAdlpZTKZPHMjn7kMLImDQsRsb1fXDhg4
+yIUitLrsqIOsYMlxmdhUM1nLU18VNM2VJw4OXWFl5VxWaTyA2MUldE+AzLhEiDMju4c3fT3R2dZ
qihy5eLYcNhOESAF4vHwn2TxJLKvKWSQBGGNglNWVsliXRGAhqTi+HUEcLLGwp5ZYqK6tTLgJtpX
AEFUkFhWWHJB2tbHNYhyLJLBCNJHDPtj5hcoG5WJ2QXEwxWlvbz7+X3tVbBNbZXEHPWbx4wp4zzr
CWMmedWTIyTiv4V1ewV2KjraX2P2omZoWWmZ0oNTW0wZ1SENHRM3oLXo0sKZEyiARQbQhSQi28UI
gAbh49Jj1bneQ5k0l9pY9LHR5AJke/Wy1qUnJhqMXfuj5htsZzAsPF4UEq8FTa+4kHGBa6Eegqg7
onIkpKyEOOHl2X1hRUNmW3io50EdjAcQIxrWpZzwujHEiwyWHG2x49Lj89FYx2VhK3IHY5diW0Lc
irHUUSU62zQIkspg7DIFYWUSU2IhI2xTV97aw0Apno6DyuxrASSjwh4KzEzsdDUY4iqAksrZxMgh
zyp66rZCxjIIt94Ec5lNYj9DTjh23ZHUodTjBOXqc2yQW7FnCRlUSyc0KMRIyK6TkhnzTvWOy3Y9
6XAZKqHG7O0xTF7LGjq6wPOrKqbpbomYmyBsR6S0ISZhFSjHwzVEfPDmzK8gV8e7PCIMbWPigo+x
tVtc7mBU42H5mTkdmsY0cBLRhJBJ0gqoUnmc17WjkOijZzLswDSIEyO7ZnUlRdF5zmTOTIzAeyVs
ZGDOCNxeJYJrKQIizCJbPMKzn0C52SSF1KfTNr6yviBrAMgMjuinyWgFZAckFUmLTY/PWMbDOQjh
bkO8qrKJkkjJmEiQoCRcL7dpH+ZadNnf9L2/+9dPvdXXqunX9jEfgJfyHbYF+Mcm/R0/7IyCJy92
6D/QvDV/+LbFPd9jH9hyP7Iyj3IVv9dlm2Je5mh/NQn1etNf+z7qe0vtL3U9jb/vX/b2P+32V23u
GU1O7w4bK0hiTraujIIC2xMTtW6MijTTdTRi7qbtyg4xQ8c1xzipBYWg8UxE1dXyTFaRKJHPLLO+
VZSePaySPTclsd+Ho+vRPr9NU08dXKa9ruaer+tVav31VrXa7zGql42CRjY6tVZHBMbkE0s7ErBL
B6yyx5MOxnpsqjsVIkXjRvdpquq662EmrHd7c3Cte1GtXRV6QWNsUrdO0kejJGbjXbzU3WnYxFNd
pcVwEVmTA+fLhYUrSJ+HARFYz8CrJY8kaQeNg582iDSJpuwzRtHaQVMNObOo4jZLu2jUo7hSF8tB
F0m1xBSwDzE8rCrp5YR5ZERY4HuSwtj5rGKurASjTpUtL6XgiV46ykSLCMbI+TgRRSP3I497XwLU
kVyvnlPsLdnLQVx5SCTZdYztbb2EdXVOeNWzGTc3YWL2QhByRONJZG9IoHxhEOhHQUm6jnnNJrEG
PdmFTYDWMAsFrJXHB2zQT6s0oCQSxDHPigWzF5cgFZoeXlUYS6NuYJyInFLy0uY2MIYbZYoZLK3I
rObGo6zjzoj7S5lBA30IcpS8uS6NuPzFXkVlIk3AWR2aMrS5hg3WBAYN47SkPsYQo5SZawOwnsGR
QEOcMnLzbhckSZy+YCUOIytbjvZW6dHaewmQIqTHui+nUrSeSLjitejujHTjyjc3zDeFtSQCXVjz
eRFmhVNeSTmAFnNPXvsYzOPVnqNYV8EM1TYjqXYjCCvJFeNHM6dWRuXHUnv5bFkjIJ3j+jYqpDKk
G5uIGwyAZJaCusJRnRTRV59mObIwoLcgXng+NHBSl5C+ScFbMPpGHPaFllXNkhikOqZb6KtitxYn
kDNnnrHlRwc0KszmITAsj8anNv47OI8Kqme5md9Dw2diJAcBXzZHw/Q7CaYMSM4YWS0bNNJPCOxi
kSsiVaV5N+QdHLBCYtamb24NVMSjHwxXttVNMqqCR8MkRO7dGgK0SWIx2gsjJXWF0Gbaw1dSVZB2
RlsXllBGHNTucy046Xslc9sID45YySt3lY5IZ2LNvQSoxr2OPcxyI5rm3ly5rmuTVHNVLDRUVOtF
TqVNqsc0ixhlurDoqtb0rkMnMn8kZYcDWIt7YfrOvLm4s6xQ+lcPicV8bHnxEm3Tya2zGpiAQJMz
tbKSzLrIbqEMCsq+csLWTomdtjN0WMYwYRhExLomClLDBEWZk7FmqhbyV7AOyNPBWVRk5Q0Rt+SO
JKPjkbJwTIy0v5a2QBRCOeYOkMitqgny8st3Y9HVqaFFONsXhGWKsfOjZ3bzg68qXmC5WxqkKR8X
fdCx1sAGRxSqQuEO0i4c7eWKKBFtIYuJLG2ObfCOGmRw75YmcThK5skb42QBK0rjEQzzxvYCbII1
gzoWyJPYRwOAFmcs7OAMSTEQU1JnixTMGIWL6tsCKRxSqMqEK0i4U7OVJIAFtIY9+SNkc2+CaLPv
juljbxOG5yTMkjaBlCH/ALRWfRPIncqb6f04YLX1f1ty/OR80WaNF6cPHweJvkcKNkj27CxklDjy
HEcoEyeeOJ5hXBmJ5YVsjmqQRy45E/Bi3pODBNLu7kT1SMq2JdC2edoog44pdjY2BTmvkQSsqq2A
uztC+FHLOoteISQg8M5CxpDDK9jDwebSF7ns4Z9dY1B0L43broyqy3FBsg5O49IyxIXvifHMxqxS
xvdsWOOUPPOBKyA6GGeOSUOeWCIqOEuNjlePLILPASyOZGPdBNFM1FjkY5doK0M/jGkzZFBDDyps
e/LilhBV37eJKMyJvIHkwQauejSt/ihKRC18jf2ZH4CX8h22BfjHJv0dP+yLvdXTW6G/QfBfl2xT
3fYx/Yci+yMo9yFb/XZZtiXuZofzUJ+x1+57Wq+xqncVev2k6/uO9iz5ccZ8MtiO+SWWZ4r3ahUU
CuYkVKrS0Qbm1bM46wVZxBwHnwMfNHSsQsYOLeiVzuWOlK3ZOAM5Gt4oQb3NUhbCJH8HiOiFglWF
HTyxC5UGUMEkvTtpLJvhCzSuEsT3mDS+njOkn4opAUbHavSPfdwZHMY2V2KCmsfGYLjNJCXEvfsK
GqhmERSOd2qLxGub6Y5iap3faydtLFlQck1J2MAGW9VWXAqJGJ2QzSMgQG5lAjqXvDprTiFMScuH
kZZpJuJDAcIocZ6Z+dj2NdlQIqvngt85srEehsOx4nMksKDPnvrYCDKyVHQtZDyavmrMRCoquSyg
n7JsFqflExxdT2SK4HG4MP7IBVTY1koJ6Yr0TeOuzuxxDIgTapwnRlBXX0x/HBsJJC5DFJzapgbY
9ME5P2KDgpAA1LshqNpWFxMPHiKHJjbDX2Nblhs3OBEDCuiKnPa6JZI3m0x0JxeRz9kjCzIskIH4
SZTF0zSlhWA/JhMr4iaTF6SapuR68MAUNtWVZMDFGt2caflxcpiR+KQwU7cZo7K3q8vtkuJDn4nm
/R8JMQFA149V9cGE4wkol3kcDchjBltB1hjuqnKQgcOlJkqoIsCzQ4S2v1qpoS7yO8EoJ6jo2vBK
sKulgjLWe0NIJI3e1qWE9kHJaoLK8mc6iqBaOwyTF7GhyewvIpbrg0cdJJSY6nobqX2VeSyyhxsT
tz7eQyxt3CyOB7EOPRA5LZJjN4GdZGVOJ5RfwtGZi+S1RNiYZS1FgM0kq2PifMO+bnF5tS3Qctvz
NamKD5Swm5uhfRjVF45aLhpgXRTYpcnEyYivbVg3AoY1eO0arvXpYyQcidj7rNz7APDWEw5aYlPh
JdZbejDFSMcixAuWSndDUYuRNQ430xDYvDlbYTvTKJ4oasBVugWzrFa500w2OuxGfM8SunhOoC+k
72WhxzFSxX12Qy20YUNWy4rR4TmQ0RhD3BGCMsRZJVUezxi2o8lceTlF9Z19lW45dW9RdCZHdm2g
ZMl5XjG1dTMIwttafFkR9U4VwXHaiVcghD+yhVMrchgMsbTspTVwUwV/jdka6wt7e1plGjIiqz5x
bFhAfaN3hDo5Za4tsrHFi7CxCJ2WGV6YMEzAG1f+6HGWzNENtksUyzmdC2ObL6H0E/3S9MYSu5nh
fWnPbYNdThnWTsZyivtbyGkAntDeBNRXVGWUHWiNccbGMXbxEywADEmcpHK+ASVzNzbJMtsw86pG
W+cD2mIWlJit6ZlFS+tw+uxvpQnGWUdrZQB2nJ24vJ5BjkwcgcsEhw0EpIEiEl3QuYiW9/2LaWs6
Jo8NKOoMqtG3WXKyjyoptPa+hcc4UuvfbDNyvF56uC2KimuokHQmDBrpaw0lmM5RX2twBRAzWpcA
k1FdUc7wq4NJDTogCLeGaSGvgLMUOGV44sys3dnWgsWX0tLl/ZVEnJQRt5jVxJitZ2N56SUi1Yxo
NzRgWF1WMZDzjK46Lery4HiGygzMr6RlhlwTBYOzAAFamk3aq19fllOuAF3JssrJLTUCJyAz2E8k
txVc8nGJiJMkkGyOJuU45De5LWw3FPCDlllaY/i9dWWAjXNoMVtscylXm5SsZ1hPjJwtrPUSgOJ5
urDJEee8rJ88QOv7GIUdVdxUnZArm9NT2WZBkmPwwg2XIbi7AqnVrOSsij70pG19q6Z1k6tsYqwO
lqs8pSWx5cRXW0U3ZoyOzNsa90EFRBIFNb4/kdWl6+aY4BeyG43H6dK9wSA3IpcJknZEKPEKg6Su
6EkeUgaSBhiMwTFxiJRlcxjJmRmwEDSLDqyMiGWBd2SJzEwtsmQ5wRMMR2OZScKnp8WaMJGNlOPz
FDTRD4aPlMUFTDHIVI6a55iFgiyHkSwsnR+ssufw5K3LskddSTNySXBG4L+23Qa10M7X4PPPyHod
5WKijflbrXmOlE3OmlTEyLMTskni412QBFOyBpfZnFsbkYrFLWEi6ZiFrK3I6GKK1krhJ46qM+lF
YSbyR8IBd0HDjGWvrLO2qK6tv6WxZTV5dxY1Ul3PSTiW8dOAk9geOnRUteX0WAdYDtOjn4PIMOli
xg8gfsjjYNKLkSGtxqszqmyJ98x1WyhksK3G4BM4ErFGS/SJpQgtc8tostnGrH1UslvPYHZ3DbU/
YgqLCojqbS0BaRnI8+VzIhENC+Kuur1sUdVBaVLUMrjlniQkEtnRskXZJWvjz0O7yDJux5YwlAk5
s8OSlLIwaHIpa4lZZ6OAgWRlyMQPA5tjWUg8gnBHx+COJp4UEnZE6WFucUgwOUY3LjsSXE4BaZty
7IznTE4uaUszcmW3nzOYjKCW8o6qfKQ+nVxRVDV2MFzFB/8AxFyU5EwLo4Y7K3yurLxp6ymxsCb0
okXM1bintGNijdM1ZBmSOTHQFyDsgmAmZpWvvY3UnZawo+trnYlk3OwkXGYZLe3U4BNjFVsIkqLu
GmAsGDOBQYwyKeTT2vbVVX+Vetfvr1/siPwEv5DtsC/GOTfo6f8AZF1+OYP0GwPbFPd9jH9hyL7I
yj3IVv8AXZZtiXuZofzUJ+x1+57Wq+xqncVev2k6/uO9i3fu6cSwjdv7m4kqdEVLN/eQQZJ9OHw0
mUm1c1GcHpBixurgNU7uns9z/ZEb3O57Ps67BZDZU5xJOFrYrNNDFSKES0qphmd0pEZIliXEANOw
kPlmbrCO2V0iorE6/wCfrXr69F9jq1VOrVumibe0qJoip36b2q9XV/yE6mqu/wDbNVGpt17qdS9S
Lp9u3iIrdxHyLvSel6M1esiJ2rpGuXRzGL17+icNNXtekjVax2qK9pCtVHK7eZMrHIqb67IZIKM4
to0gkZLoWvJaK97JJxuLosqwSzMidMOx/DmljbxHPVWtaKXOGPMVXum5EqaFkhIayx8AhRSHs4sH
Hi1inWF6ceNXRyK9jnN26v3kI/AS/kO2wL8Y5N+jp/2RdfjmD9BsD2xT3fYx/Ysi+yMo9yFb/XZZ
tiXuZofzUJ+x7XTXddp9/RVTXtVVE7X2NVX+AumqWbVjJ+ubGGRksIJUzJPrKgBRXEQVEMUnpszY
3zOMtOFDDO+SyhhBJCpo2RMLRVj4/wBc1x4vaJEG96LzI0LuKrLCHdiViP4rSIXNSUeZkWVCuuDo
29O3IjmtZTsiYNAQRWjNZHNVcdyNABFgkl4vp/DXiOker3uxqxOe6Q6woak4x72RxveUYDASQ50c
LY4o1WWR/aRxsjZ3rGNaiJtkUhpIw0K9jWgnXmJoI9Ra/IMtfYk7ksrU5UBhg3PTujWGDnBeM/SR
GrgeZ3dVU5JWVuH4OBODaOamRYQXzMb4sjxiV8JcbrM7pISU4QR1FYmOrRH11lZmLW1S1tvJQUVW
2x7LfZIBFyOoni9Ft2VJJmzIqnIAJqWu4dCPChZD+DdXhI5gNM7o4IdCDAsjdNQUZ0EPY8xdCMjL
czp/AhiMky6IjLMdiZXkTTS0kcr7o6Ma3pJ3RhDuiU2REY2/kBmx19HiuRYvjh9cYKU+/vJcgFx6
dbMW2Ht4wapq+iODowGWjtOkWV0yMKDjJiUaIiCfF4Ky2zDJsGrquWrs5r2sOo+nB4ro0tmQQD20
PHopLAyhgrKeWGqKRzb3fEdKTZm5BaR3B5nYyuSudQcuCd0MuNkOjafKbaW0x56LvqTYcUdpKuRW
hQaLvdiRt9Q4xW17cugdCTUZba3hkk6YPlfCjlAMwrHoYonx8R8krbKZ8b2sjbDK2RZYxoS4quOX
L+wt2RMjtooGEMkFNq6ipijjDbIZK6ATiWxkc7SUJl34YmtmYscqSTUF3LQGNixfHsiBIoID4WhD
W0lgKysPkMMNZYyN6P4olxA2qbZRoQ/oUBImo/7PI/AS/kO2wL8Y5N+jp/2RdyIn7sj/AKEYMn/w
7Yp7vsZ/sORfZGV/cw0Bf5CMr02xP3NUf5sF/Y9aa/cXufybdz5f5f5vvdW3s/yr7H8f3f8AV7Sa
Vl813L1RchkuXhMMlHkOkjBhhqpK2Jgcscb5Z416Xc4gZZIvToF5x8kjooIGJHDBGyGKNvesjjaj
GMT7jWoiJ97YXp+gprzkZFmC6XrArLkpnbu9MJzkM3LSu3GayQ7j13Gar2rdArs/HaM26rUibXW5
dSATZgNgkklgaEfNA8oVIZZpZIkglYkckj3s0c5V2LvK/GqEC6P46nXANQAJaGKTIkpDirAeCMsh
00qJLK+WVznydu5Vd17EEPCFfOWNGEXO6CN0xQULyZIQyJVbvzCRPNMdGNIroY1LJ3WJx5d6ssWY
vjzLCkFiApTm01chlODA2VsIVWSg/GrxImzzNjGEfDCxJpd1icR+pGRD0NLBkBcXALvYqsKO5Jg3
YmcEizbAhs0W6PA3hyTuZuwxJppGzQypCoqYSqsXFvsKwWsCHrznnt3DnmBxQNHJcaztC3TRvUhv
azb6bBrMGLMtfMhNeso8UnIkNglFbOHvMXlpkGInHSWHcekE8sWvDke1TyBsRxgee1YdHaTQ0NVF
LZR2enSUZ8jBWvMZYbreeaQsiF6Jx0k02JjoaSopGGkKWYyorQ61pZTk0cSS0OGFJyHJ1LNLvSKn
Urv3gI/AS/kO2wL8Y5N+jp/2RkG8mulyJ/PhmHfJtivu9xn+w5Ft4Cb+bbTgEdxHd6ido/cfEvX7
L4nq5yfavjczq2njGqbIxRpGRTcJ9TBuOcNGT/8AL7QT7SZm3ret/hWOefdvW9b/AArHPPu3ret/
hWOefdvW9b/Csc8+7et63+FY55929b1v8Kxzz7t63rf4Vjnn3ZP8HblFX25seT/o9o29kenEd6Un
3fu7et6401TuzUDepVk1k3lutzhdo3hu7s/ETh67et63+FY55929b1v8Kxzz7t63rf4Vjnn3b1vW
/wAKxzz7t63rf4Vjnn3b1vW/wrHPPu3ret/hWOefdvW9cfCsb8+7JMwclqLJPE9HI30p0EksT/v9
vC/bwE3822nBn61062I3RftGOavbxyyew2Tq9pdsqenVrh4Kafc5nK9sT9zVH+bBf3zI/AS/kO2w
L8Y5N+jp/wBkZF+OQ/0NxHbFPd9jP9hyLaxkx4QA68YJJ0YLYlLAJKeiokbCZI2Mc3r10gR6QEuT
lZbapiXphKpLkkku0dGTNYklsZHPKWXYGkzO4ETI4I2rK93DhiiZDBHpDBHHC1saXSey61g00crf
3DqU9jT2Nu4vvl+XbuL75fl27i++X5du4vvl+XbuL75fl27i++X5du4vvl+XYwYKQ4ad5FLuS15M
4hDWRXAs0m6QLJFO3WNSEcrZEVWvVNdETSMqYy4eMlr2QCViItzZB+DKVX9GM4D5HQ8EceF7a+Lc
4QOquDZC5VXbuL75fl27i++X5du4vvl+XbuL75fl27i++X5du4vvl+XbuL75fl2d1L1f8tfl2c7+
HY3a9fX+7Ryf6pHfy/cTRv3dqL0UyoVYOAA+un7yHTQImkL7Hf7+eH7aV6LNJ3ZXvVV2yn3Ig/2j
Mv8A9Df5Pv7Yn7mqP82C/vmR+Al/IdtgX4xyb9HT/sjIvxyH+huI7Y6WRJwoBM1oS55dySTchFrM
lnlduRMfI7SON3Uxqr97u7L+3WuqOautfeL1P6n92sXvk7V38Jvar1dW3jn7vi67/hOf/wCa/wCE
9y/x+1psQQPkkULCJUnkZLRX5W5K2CIdHfW3L/8AAwRM013e13tN5XKvrqE+LWTf3u3rqE+LWTf3
u3rqE+LWTf3u3rqE+LWTf3u3rqE+LWTf3u3rqE+LWTf3u3rqE+LWTf3u3VlYqd6vrbyf7VdW/wDC
+wu2noug7mnreyj2tP8Ay3sp3f4Xs67euoT4tZN/e7euoT4tZN/e7euoT4tZN/e7euoT4tZN/e7e
uoT4tZN/e7euoT4tZN/e7euoT4tZN/e7eukTr/8AZrJv73ZgzryOZWSTyukStvI96QmZxEy6dGad
vM9z9E6m67rURqIm3jdOr/m67817eN06/wDm660+9p0X3vtN71PYTbIuRtQXcxjYgMCkyvA4pjyM
i3Iv2wiE8F0iNqqd3mF3td1ulLVkXFQ4isqasAl0VrW8J0g4McLnQK4vVycSNO7/ABbeN6vyrV/O
9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n+3jar8r0/wA/28bVflen+f7e
NqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n+3jar8r0/wA/28bV
flen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n+3jar8r0
/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n
+3jar8r0/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBv
G1X5Xp/n+3jar8r0/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/
K9P8/wBvG1X5Xp/n+3jar8r0/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+0rEt6rV8b2Jrb1Gmr
mqia/X/c2xi0huqNRaYm7ILVbiuY9UNrJgB2QNeQnEe6UjiL1tjbDFIqv31ijl8bVflen+f7eNqv
yvT/AD/bxtV+V6f5/t42q/K9P8/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/AG8bVfle
n+f7eNqvyvT/AD/bxtV+V6f5/t42q/K9P8/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/
AG8bVflen+f7eNqvyvT/AD/bxtV+V6f5/t42q/K9P8/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+2Q
yjTwkwrdjNbMPNHPC5Y8RxOOTclic+N+5IxzHbrl0c1U7qbUCp1aX0vc9xWa7eFk9+75dvCye/d8
u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28
LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZP
fu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793
y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xb
wsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk
9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3
fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75d
vCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7Qemy9b+vt3dfpBK9fX7aIv30RfY28LJ793y
7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbw
snv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xaf02Xqf1du7q9IGXq6/bVV++qr7O3
hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl2mVJ
ZUVIpFRUkdqi7q/d2ybX2bwbX4n4jtQ/j+X9C81/9CR/wn/4cr7BI/Cf/hxf8VN+Ck/IXbJfx4L+
h2I7V1hM0p4gFzxSnDAmWE8MXoUzANXoDWwkHy6llixKvJ/b6beEvPiZm3mHbwl58TM28w7d/efE
zN/MO3fXfxMzbzDt3958TM28w7d/efEzNvMO3f3nxMzbzFt3138TM28w7d9d/EzNvMO3fXvxMzfz
Dt3b34l5t5h2/dz4mZt5h2/dz4mZt5h2/d74mZv5h2768+KGY/R7bvr34oZh9Htu7efE/Mfo9t3b
z4n5j9Htu7efFDMPo9t+7vxQzD6P7fu78UMw+j+37u/FDMPo/t3b34oZh9H9u7e/FDMPo/t3b34o
Zh9H9v3c+J+YfR/b93vihmH0e2/d74oZh9Htv3e+KGYfR7b93vihmH0e2/d74oZh9H9v3e+KGYfR
/b93vihmP0f2/d74oZj9H9u5ffE/MPo/t3L74oZh9H9u5ffE/MPo/t3L74n5h9H9u5ffFDMPo/t+
7nxPzL6P7dy8+KOZfR/buXfxRzL6P7fu98UMw+j+37vfFDMfo9t+73xQzH6Pbfu98UMx+j237vfE
/MPo9t+73xQzH6Pbd29+KGYfR/bu3vxQzD6P7fu78UMw+j+37u/FDMPo/t+7vxQzD6P7d28+J+Y/
R7bu3nxPzH6Pbd9e/FDMPo9t3158UMx+j237vfEzN/MO37vfEzN/MO37u/EzN/MO37ufEzNvMO37
ufEzNvMO37u/EzN/MO37u/EzN/MO37ufEzNvMO37ufEzNvMO3fXvxMzbzFt3178TM28xbd9efEzN
vMO3pkl6z7+GZt9F9vVF58SM9+jO3h7z4k559GtmOQi87STf9Y2edzRU09bPtKqe1oq+3t6ovfiX
m/0W28Pe/EvNvovt4W/+JWbfRfbwl/8AErNvovt4TIPiVm30X28LdfEzNvMW3hbv4mZr5i28JefE
zNvMW3f3nxMzbzFt1OvPiZm3mLbvrz4mZt5h27t78TM38w7d9e/FDMPo9t3bz4n5j9Htu7efFDMP
o9t3b34n5j9Htpnft520u/6z8w7miJp63vaaifeRPaTb93PifmH0e27t58UMw+j23bPvE/8AczNv
MO3hLz4mZv8ARzbwt58TM3+jm3avvF/9zM2+ju3apeL/AO5+Zf8Abj+3e3nxQzHzBt3t58UMx8wb
SMRt3q5jmpriOY6auaqf+YNroxsZMY5tvHMLzYZYE0sMON43Xvl5Q+AYuNnNhFRNWWCPicJXs3o3
Nc7iZABbiG8ThPfjw1ZY1phHd4sY9nbUZVQ7Xr6PY+xC16+d27uZeQMe+mG3e5j5DoPpht3uY+Q6
D6Ybd7mXkOh+mG3e5l5DoPpht4PMfIVB9MNvB5j5DoPpht3mY+Q6D6YbeAzHyJj/ANMdvAZj5Ex/
6YbeAzHyJj/0x28DmXkWg+mO3qfMPImP/THb1PmHkTH/AKY7eAzHyLQfTDbwGY+RaD6Ybep8x8i0
H0x29S5l5HoPpjt6lzLyPQfTHb1LmPkeg+mO3qTMPI9B9MNvUeYeR8f+mG3qPMfI+P8A0x29R5j5
Hx/6Y7eo8x8j4/8ATHb1FmfknG/pdt6kzLyRQfTHb1FmfknG/pdt6izPyTjf0t28X5n5Lxr6XbeL
8y8lY19LtvF2ZeSsb+lu3i/MvJeN/S3bxfmfkrG/pdt4uzLyXjX0u28XZl5Lxr6XbeL8z8l439Lt
vF+Z+S8b+l23i7MvJeNfS7bxfmfkvG/pdt4uzLyXjf0t28XZl5Lxv6W7eocy8k439LdvUOZ+Sca+
lu3qLM/JON/S3b1FmnknG/pbt6kzHyPQfTHb1HmPkeg+mO3qTMfI+P8A0x29R5j5HoPpjt6jzDyP
j/0w29S5j5HoPpjt6lzHyPQfTDb1LmPkag+mO3qfMfIuP/TDbwGY+RaD6YbeAzHyLQfTHb1PmHkT
H/pjt6nzDyJj/wBMdvAZj5EoPpjt6nzDyJj/ANMdvU+YeRMf+mO3gMx8iUH0x28BmPkSg+mO3gMy
8i0H0x28BmHkSg+mG3gMx8iY/wDTHbwOZeRaD6Y7dUeYp/8AYdB9MdpI3F5nG5jtx2mLUK6L9z/D
3bVT8z+96FKHT9PdvVuY/FWh+nu3qzMdPcpQfTzZdwjMl3f/AGYx9P8A8+7eqcy+LFF9PNl9OzFd
3/2Yofp5t2i5o7/3dx1P/wA9bd9mOnucoPpztvb2afF7Hvpzt1+jNV9z2O/TnZd30adr7ePY99Od
u+zPyBj/ANL9v/HHyDQ/TDbTczHX8RUH0w28FmPkSg+mO3gcy8i0P0x28BmPkWg+mO3qfMfImP8A
0x29S5j5GoPpjt6lzHyNQfTHb1LmXkeg+mW3UPmPkSg+mO3e5in/ANh0H0w27mZ/F/Hvptt/45/F
/HvpttuxwZnM/vt3oPHWdSd3rdmmmyN6IzNdP+bcaT/84Lt4nzPydjX0v28T5n5Oxr6XbeJ8y8nY
19L9uFitDaLZS7zGFZElWICA5U9LK5autbeayWNy73JucBG/TtitPS3f/8QAKxABAAICAQIDCAMB
AQAAAAAAAQARITFBEFFhcYEgMEBQkdHw8aGxweFg/9oACAEBAAE/IWaLld1VkU9MpGWogqm3KhkX
Kq3PwbBH/WEZUtUiGQBgUGl90lXLpctSpkwASoNet1jQTAY60fV+1mzfrHsJoXzaSNf6Ye1WrVhL
kBAo0SVKmnz5wQPPnz58+bM0aNGjTps2NPiVpQkSJEiRIkSJEkU6DX5y9LJlUKrcrw2be+l95N+/
T7yb30pt36UGrkE7g2Ofhgl3wgZdQL/67NDbK8xk47cjL9IMCvQlrQAMnlL1VkxFQJvG4ut2ydv7
b9AYljAzraxpQQJRTNj6MyAFSg3m5ufaPbkBuMXzO6EVhAjn/dNxImTeE0/qTZVGdwukSXozemOR
BqV0awu2DMJhFCuHVRptJbdgsp7jPYVfJYE1W+rk+VMFqg6JJHgJxy1dvJCy2Tcwc7rdkohYOm4M
Y8ZjAp1BMM7AoiUECiiG1j1lXi7HSKOA0qg1qaCMjVq/wGMMj0yBEB1Fp44m/GqWVs2ufjgbioHB
Wy4BGkjYpiEph9B8MLnhculb2RGFObGIVCEFGcDEFUsdrqtw4ipBqWtuT58tkqEN3nixH26KVoMV
LZAD/s4ig2qGqxXlXQr2ngH8exR2PpKOx9J4D6HsV0CUdKlSpR1plMplSpUp6K6V4SvCU9FEo9tU
p6KZT1K6j4wihwfSDF7v16FHLPFgfj0QS3l+scxJguxPEZpz6UQqslQBmHAq3johCgRExNGdeDnm
KquBKFEcXuttFFhRfO/MFEs8KbICqo0tbTg7mEN25O7T6ryxvLaKuFQQ1gcL8ph4ZXOWV4CX3OjA
qBeBQrC7HI09OfCg9NluLZ/m7VHMNk6iBWUEXJiLOWx2mw17bijG75U1GLxaC5YVTNIkL58FxhJX
ezKLXNiF6gG9TR2UTwLCFh31dTk7Ou2i8yzCUGNmveBEY6NPeyYlLEaQVlyDhLMdjwUzZlLZ6JIQ
LuCm0hcF5ZetvJ15n2Azq2JNY73pwgpiUibyYKm7XaLNtvUt6F0lWd5HWZtQCXF0E95bguQTOgzh
QFCLC8hbOu6gK17U1Q28EBiCwAHi/MgpscUvE1uyn5+/dqlSvcUyutSutMr2lMplMplSpR1r2BUq
VKJUo6NcfxLe79ZrqeJKNMoniv1YHeB36c9rRFFoeRVyn88dwqjpsAPDkzPvuY+cnn6Y5nJ32pTG
PaW1m5873RMDlBMDmJg9zHNtCCrwC5fLzEqWrVnXP6H+oDB0QlCr8HywE0+c7/adstsMTJE21IQX
C965acO2woGrreLwqamGFKuLWP8APDm4NrgBoZVgvRgxKOHGv0QehPxVcIDHmMCmAVR2UrG7Di8n
nmbzEqN9VvhTmoWtT7XA/wCeq7ortqurx2/sD3cuYtlZVt5XZ4v+JKiip4w+D/HsKIAlpAq7FmNv
Zm23U5DC5IqUXQw3I2Y8AbAbLs5NlacW3uXblpbM9zl4muI4wgVJtTyLErTz0t22fwHPjuVeK883
oHh+hLPJed3v8X+ReImq4wK1oc/rDkjyi3aX9fdBon23IGRYsX+ll+on+on+o68uX+sh+kl+kh+k
h+ul+ml+nl+rj+jj+ql+oh+ij+uj+uj+uj+uj+q940g0880082/+/pPdtttvOeaCBBH6zqEEfuZf
vumTqj0SXZgjf/D7xup7f9IkWrFXdgt+Z01ve+v/ALzaKV3bX585filguWheHDOMGMdGQUgB7TX4
P3iI06zZyVpU8huEJ7HSk7VYzxv6L8ZmgdwA4A0waFkQAryfUcXWLQEkq4x82dsGpYSRonCtUuwu
lhZnI2XavfDFa2VuCMUytRcFCxhuKjLd7TinT04cAwwFaVSaLxBp7tqqZsmdx7lBW7wCWSSbol35
kkLoTfYXg/njcxlHaCP7calNwK525bS4NiMoYMDQcwOLJUAjQjcmqgPrqymf85r/AGVLZSEGih2B
aXINhlyJmhecDB5mWXa9khzV/IFutEBRxsCJoJx6d4LjDnk3znHj7BjwY/ee0GDFixY/7Rn1o/v5
qYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDHz4YMIkVm3+BBj58+fDkCN
kMGDBgwYMCCAZLHtpvJN9Lqs8/ZIFMDJAW49K84UGOC8yWpmFFtNCrxoucD0o6h4Ky9a+TS1occF
6LbSlgUulOAYpWEABCTUWcs9IcklLdX/AEB97LWBCYslPhcpWkfSSVJ68S8sjBGmdLlC+1bHpyhi
NOsc7C0FwpZdO4u/XuGRyAkrAhdNSO5XksT6kRgpix/aml6sZKp6NJbfc3M+T8K/7Ayu4Eb07G4R
UL500pno+8bDDwvzgEXDU+kJ1VFQDBOWn0VRJNmjYsy5HqOaJ+Ff9n4V/wBn4V/2fhX/AGfhX/Z+
Ff8AZ+Ff9n4V/wBn4V/2G9eg/wC/+HdXCaizX4otBTLDHfGpn200mjVsnAQFRHIIaqd0KhGkEmnV
6ZBSeCUy28mJNpKd15PFopZ2bRbg1Id3mRIhMjpZtEeIEZpvuYrag1LoWGD+rYViJVKQjU7Z3cmt
gBYBXurZACyITug2XCRgIu5ufhsMC1tKTKxSd09Ft62QWMSiJoF3ixlfUJQKTQ4SghLTbCYLMvff
oNiwWMqRnaLMpAQjYFyKuNFKYQG3EJROAga5KEy5gFzCyx1QRLZIVcf0IAXwwHWVa8wsQ9uQFwVF
D2VzALGCa4KJeZXZE3YlPKszAvBLxAed6vGiEhsFOXINaF9UdEqeHGbKRBV2ivoPtcEtptyrwNNb
S71RmpU2Joavyo2WP6OtPYcOHCvP1/5Qn/hnbt27du3bt27du3bt27du3bt27du3bt27du3bt27d
u3bt27du3bt27du3bt27du3bt27du3bt27du3bt3VVBBuYLBoo1wqIi/VMv7j9G4w+oip3IoZEqv
DP8ADKWhxIRSsBHBWh4gwgfUwcypDFqcFraaPFIyu/LvW+MmOWJ/zJsBITMIg837CHUcGYtW3KAq
ibE3xoi2NBBKmoHjMnnhIK0KP4dqQpbFjN7BWJsXzaWH21DFjDIdQlK216xphY1Wpp/ZWNj3Uwqd
/Ppoqjei5luM9ccoXCFymjemRS5mdhyKh6aggTDZloj6mDLVU2Bh+IGi84GNvkaJcgVtf0TMzVLm
+MWb+ZOWXKziU+4uNRu4tu9lwWA8Zsa1kedIQ8wgpLqHeBS0KY3YEYkFbXawD3rhPxzMyfdyanm3
SVY0wjYPlIWllPDuPyE/IT8hPI+ktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0
tLS0tLS0tLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbt0C
0FzITZbBps744IO7sRfG4QAx2cotkFm6kcueM9w4WWgeEv0ITDgBU2VOeNRj1MhCoFcGupBylcyZ
7n8P0iOiQ4a10tGuDYIKeRo3A3b1NxDEbBLb1eKLXjsc75uHGLl3Euos+70CoivrC+opsTWzAHo1
UrBvQVubJNVSNCr83fFHxTGbm45W36WQiM7Sh+kA+xE5simAG33wH1/jioAJsU7txwRIjPXYQgN8
wYxAgx60K1hi1Hbqa41lMmJlJ0tcMrDKgb4v677h1ImCxe5Iqdz8zQIyK4Mdqh1l6FyxY/1YmyjS
RrdxfhLIfPtTEcO1N51AqiKkhfyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyz
yzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyyn7vvKfu+8p+77yn7vvKfu+8p+77yn7vv
Kfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p
+77yn7vvKfu+8AMwYN/Uggcihu7WhWgeJo46EIcOHJmM5z5tq0OvwG5DQA4oFPLMAjgEyO2K5W7s
A00NlYLFhJyw4/oQqgAEMu2uuVs8jkvBXinnzbrb2iwYKLfWxLlou9nLZOJCxo5MCctwGtlOY+s1
QphdKy5Kpi7nkdiE2BWCocWLjCtqsbUu1TGw/k1pekrpMVcxsJaLSiz3LEO2fGGiR2jCUNELmVRI
XKKP2jgQinPhvNBm6JOMzGok7T1caLQAADKOFcqFB6lOcrM0WxvY2zfRgNxCPjHj5c0wHguKcAyG
MBCqgBxVESaAlVYd40IsATCjKCpA5BgZLVGvgKOPL+Z/uwYAoHJpYmFXk3WijH/i1y5cuXLly5cu
XLly5cuXLly5cuXLly5cuXLly5cuXLly5cuXLly5cuXLq1atWrVq1atWrVq1atWrVq1atWrVq1ZJ
OR+BQqUvaLzMRas0/nN5utHsEPcNJlgit2BgiJOPpbbH713DZBHFmoDNmCFKWQ0LVcs923oh0QPA
KLTkB3GyK+DqBmwozKI5z4/4Bd9qOWqlFSBO1lq7UhizCptN4y7/ACRPDrly6V21Veqn09w6dOnT
p06HKMrDxCF8lDw6ZewbU92Bh5hfjB0dSwkPdsNNEfvmnxD1Oi1LZl62FMM8Ji1QAnSCh2a/3WhF
TLtVKXIhGlOYzTwEzzXQcTYm4lYy1OzaQEis3OlPCcFuQcm1KDgqpVtGJgLnw0BQTwcvPAA5ESeZ
6SAYpSq1Hj7RmzZs2d2vrf8AXyPMmTJkyZMmTJkyZMmTJkyZMmTJkyZMmTJkyZMmTBQnvOZIMVRg
axDLUd7B2mWCCT4ggoUKFChQoUKFChQoUKFChQoUKFCg1D7qULJumA4A0b0Zef4QP5QhUABMK6mo
7j2Manq6G5yar0r8I6ERWAUO1dBlgy2AnkHr0qJH5Mb2DKnkPVqtSFZRJypph2dGR47pBVHy6oNH
6gcpEbiJrcpE+TA2RuejhjCDuVXTcRe22OEuEmCCVSwJ35QPPqKeW/27OMD80l3Y7P2+tGBT6OwY
ULSxc69GvVCCRtwVOdZ14f8AXszXCyz2Mr2uYFQE9R6dr8YBVlpRpxsS1ep0NMwiPIrShkXL4nz0
JwVZiJ8HRmRd1iWuPa1K+7f3z0cIsTCKEuYRAb3ZSVjWMwgPbRJrRYJqMQu9MCTXug/ZcJRiJdNA
ebjLeAmWSdmCw8lfSz0HSnMk29JLQULOO+aEqKyhYyNRFjkZVw6kmYSOylZl7CktC2kCqKGFEQNY
rWEZrz+r95Xn9X7yvP6v3lef1fvK8/q/eV+W/JYwyiKbr0oQy+ygjRwFncJMc5MqrNr4LbfoZDbt
kZnJomYXeaFg6kqhhklZG6GYPeVeY9ed+CE0Eewm+29xAl003eHLdVFgG9AFv8Ba+OAyWFta3a57
Dl8RCwlIigheN2WAXLNEgAr22mDnSpjlwRTHpUVZLsZte6Eld8mtFaSlokc3uJEXuH1BAdLFVthT
tDF55xDZcYKhtoLcOWjeVVHQUoFsGsycOmGKnhTFP5EkYc4CMwM3W0wDNABqWCBKNTaUJZOQ/S5f
QWIpNOq7yuCqjQb6IfjqnrmV97+PyI33q2rxm0ZKFk02FncV2W9OkTGDPxPWTPpAxK+Re+KXwBFX
1V0NCyVRawpIEHk6RIuaaFApQ7kbM/as98MsZIUZaRbxqRizuWYPKyFMoBZVDsQMU0bYoVS05M2X
fXmRAPCOa3L8lzZiuI0J0yqRHXeUdFE02PFaZYI5uVhkEJDUpZXQU0lyOqgxE+TqV8E3jGKxgqjr
WKV2zW27/ohfTn5NG7VZJrM/9KLYE5DzvPCitObhooFCupKJ5t7gjMTgMofulU82yqoThhh6xmt4
K90v5JliJVsI3wD7PgrW3lK9evXr169evXr169evXr2nyY1h50qPDkphxVmygq4LcEXksmZQ+1IJ
6KURlQGV2QOjvioqrOViLCPNfOFUFpBxn+JKhwU/fsxYIMwPT693utGtjKK+iUbS2jg0jRYAIU3S
0eOpNx064bpF7SwlFOJd3MxWGM4pHrvYIoNSVqw01iTTWV4JsZuAJTKffwmGfRehxjTdWvGUdqsy
F9IaVE2feUg40Weo/TJ/M2Frnbc5QNwRGsylE2cTh1WEI2d05EKB1ZUSgBIjFMnabKAmiipnw1tL
sQiwRXhELSrRFYHrjCo4ZgUcpx4Vi12t/l55kKF4AKYO3hislMjNN38JQwwp2M8I+t1G2OQj0hIj
PWgu/wAKVx1Mt4onFrbHq5fuTEJlwM3BwUHqumPPKkPDOtYFaXzLF7l8ijdsi9NwhNC0WFPiO3bt
27du3bt27du3bt27du3bt27eCv7z+qi+9HaJd7fpo/5NcYGl1BtKkbU7gXUFbg/QyIkE9cFAsQZR
qG4Npgyh8Co/SHlA6TMS/Of5bIN0IUletaiVOKtg8Ad9IATqee8BkrsnsCaR464VPGiR86MZoMg/
9T++QNfoGD++7k5Q1qCy0tFRr3m9U3YS+euD3jGflLJFyNbHPdevQuIvSzngCx3RNS+8DjdKOy+z
IOqC0JLE5FNoVCKcYAEh1aAM89CckTSMayVwG3gGyYtg/nDjhVuCRSuTMeAX6lH96M76Z/x1zwd/
Op4aEmrus1zGEGmfzGfaFoZyEKYwDywmefKrxEJCkyjk+M2d1w08haaa18M3/wCMk30FLQsTAvKj
oLZZvba8sI4Ea/J5Fvqcxo6/IoXGV9sy+Cv+S/8AMQL0OQCz49gM9PgF4Gj73auGq7U/J70K5eIA
V+RSapEqj6bnC0kb6dauDIE5qmzIE1m3xvGdZ0Gbgm0AwHVj9AESuaAB0rcfBSqOESnAnVFs4s6K
SlhZAjLz85iFQ7mVB+U3ZabVVuU7yneU7yneU7yneU7yneU7ztyo1vyTdMqxC6oW2GUeJ6Ij9b7s
QGjk7d8G+54OJS7zx2MFcqFOqq6dgwTJ3LzdOy900WXWIHWiZ0xGDN4QKXhLqpHA2L2ojFVBYJb6
Mp0gJ/iukya0SYZ2Zx8JaODXTaBZshMj20hOa+SlOYzp2T72pIVbtGPHXrQx9NiP0y11gCI6FCZF
cxwrTUj4xbBSUcj6EAuaSm3idT3S4/wcyH3VdrYrbS8UGd0wjpRc01YG6eQumjn4hFvvdA40taJh
c7QxWDRgokGBJBtVW20wckjdoFuNnxfOAGF7ZEqCvEutashJjejSxqUOQtpYnrk7jtK8RMjDtlKS
Ig8AM5nHJ2XmFwYaFMYCqUw01Wg7qgtMN5npwTtB51LkrDs5YDC46euqdabLPN5rIdluYZrTQxPM
AoURbFFLtU5LVbdrdav6W/JIzntKr82fkZvgwc4NCClHXYFODJNPHMSW5mQlL8fylo2vu/lZKeXx
TnB2FvQjOs5v13+Xo0shT2oz8H0UWktOiWIK9zBy3yHT28w0HdoFiVyMFpt5b2GqyBnLThcz8jSq
lk02mLBBLrvXIChiZcqyq73ZzPG/qeN/Ur3n4XPwufhc/C5+Fz8Ln4XPwvpMbcasGuS4HuW2eOdz
l5/4dQG2BhUhZp3Lb3H76av7M0d+dzSOjiOsCzmRA7hA+utzWa7sNrxgb1+xygsEhDEYp7jyw9TN
Rx0xeF2GaabF9zxZfoBK8jLrh5NJp2ZAkaSS7aJA4sDDYo/7d9ILKCf78GzPj1gHPfA7k3A4Pt69
05Q+rHXs4HxITZSSS2cLd33XeuQONM+8bQCyRI+Qb4sdHbogwZQzHPDW5tVolwRqkd8OGAETXNPl
7vN8QJjUqsN0rPB0Atd5kb/Ngms06cOuQ34rHnHiaz/oEo6DhKpJozUGxuCG9cZatUVvhTJYtDdU
14hquZ31v+Tcp+/EWlcaX9HMz9Ggx42PxsYUiUGja9pqOARQXu33QVRVEXCq9gADtRbfd0RYVPFG
xHx6cb6qsOYra16+JQGrtksbasMJvs3YXE1AtVYdnuDdt7S4SWFnXjtxWgWKNjOl0Wgp42V0BfLW
iTx5H46PxsfjPcsgggggggixVdfR1eUy4LePtXf5+YnLz/w6mzV4BsWZschTSFWSQKO4J2lVTByt
KAIlyv1W1fR3Itl0JGO9CInuiQnAbxVTVScZXDXhANIDrag8NGqoB0dZcBtlhKy3BxASUOqhVI2b
3WQr38D3DjRvqpatg3RGrhEFlrktYAVRTMLVwbab/m2/VvNW1euJu2WDx48vU40ynrGBrS0+LKBN
HKY+UOFgW1eYZhqb53yaQCoGmCVolomX0x7G2zKczLnfLXfIjexU53HzQxccoaFWGgqbxFRQEWoX
kKQbEcCyJVTAwyCiIdi14A2swqsfKGgp0x3xYv3jYfKzwbowLyGIsTHhMlJTVkGmm45VICMnutR3
8il7AUJ7b9wWgFCBONEv2KeS0J6njMP8pPMyMG6xpbs9zpOKCW4NPykqDUXkP2mvlD+D3M2O9CwX
e4OKdO/zu81GX6uF/o/MQ2eJb50dVIGhrThaidxou/nofe5bZu6r4A/YjWK3K1w3A0rJBkaI3YUz
gXJaIT0xn1PKTuyZvxfcj0ZyxDWOUFsJIUPBUaJqqwAYrIvSSaQiFClR0yvQD8RCEKBBFqnn6lbS
t8CZ5hUf2X6VdOmBLH0Kxe6rCGQQ3Z1p0we78IONLMLsiSZrjArKdGYU3CCu17DQCEM0GnUp4NhQ
Jh7dlr9gZSy32ZlSW0xpJW7FEJ/2NbirXNOYCDH++nxcJpmX+p2hLs57twoIaLcscoTuzq1Zmo+g
W7Z9U+WASGqpYCsctPIq4GC235lqlJiFmtAgA5Yj8lfGP0T0f7q/41j2D7DKVB0FpaWbxQsC/wDS
HvAawNo6YTsm+lMvlQbLx/Dc0ESDAzm2Tsez5kRTlORh555OCQReqMm7Rzhd6RJSf5olunQU4Zdp
4om2KyncS/rcuUQTfciB3lQme2BCsah0Be7wb5rT5eEPABdJVzPweB18EqhrNceArc1R6IOIVaE7
vr4UhMVHZJeiONgk2Chyag6n5KtUY4NDstTdN1+KlcFVURoYUWrF6BsIVUL+Dhxpbhza8KQjt9EM
I1LUe2sDS1hUMIdlLFH22icCInL7OGJnBiVxQDdeqoN0MltoLUKwTVW8qIIAXRXmJMJLA0pizkms
ob0RrC0zYHFvn5o4UxVUYNPAkHGICWyop7DShmIK0KAUGFM5mCFNbMNFW5iFt+My/XHRxAtQG4dr
XqlKtCAoL3arBcF+MWjAF8lUdRMsZLF87jWBxRq7GwY+aUcqnDOIWz0DkweSPQmdX1BX7X9N3Boi
XqATgaGxce1jARtBjQ4rAHT70HU2+ZTQM72JSQSK1kdCNB9aD0ZH2KO1K8sJR2cp+owLLB93cffI
B3rQ1JVN+DTI4wgoPLskAvDtoEkyoI83+nECjWZiGIxGIgt3B+lXDPSHjOJSBsQCl72nDCVQmrUk
UD3SnCYLsw43LZmmMu/GhoEiXkPUJjfoKx436PvU93nSCITHbBkENMMHMRgrKt/6UgLN6z0ZW4BZ
LzmjDkZ6KMQg7SekPlQvdYK6HaISabmGSb/6x8QoMIIuwK7KH+1NjAY+S0WF9kVLjacZBRqmMWuz
Ab+1e9GKcWkiZymLYuVgtY69NSuSon1ZFWJZwz51eNuh2NYH/gtLDcgtTSuyEJdRfC5R+bBW1lua
PN1UuXHgAHDnRFOtXpQoI2KoFLFAw75g2Go0Vuv9uLr0ucmRuzqqs564vGwKD4Wh299lyZvoArEN
v/XAazzIKDTDRojmC6eMxZKGipagYiGJUwXDLxDphBAOOc9iQRFspE8BQFYRAarlQngf6kCvQUxx
QeDruSZUsKGFO70xl5dcjoq0r3IcbleQ4XSQWGEUymx7Ss1IJ14Gzb4AF84kaNwEyHMm35EJw9Ec
5AYb947TFq0qXwXd7DaNae4p0SIrfOwEYAQopeUUyVjEMllJvmJENggAv5CyQDNAbnEOYmhgXcVB
hocUABAqJJmI6mcIPDzEo/lMzl2fNRGPZabNswqIpNOq7yuCqjQaB1Y16uaokT86pjWPoGPBqs8a
x5T6wfRB/hlBus1XWsItK9PELcRKROCvkCpydlWk2S9IpqCuJq3InIABfjKVkZHBvFPKI+iRHbe+
FmSo2bwK6Gl6i1hAA2hd2DsHsNklpLm8RUtNjUVMEmKx+IE4V0wJGkNYUWh0bS4uzEvKq0Smua4i
J57ixRTKpeIIWVGXk7kxcgh6Yl24Or4bTeHLdRb0I5Le40s7cJNpUb28rJyaAWlhbOEaJTpKAY6d
DoBpZToZnSjBxy/xi4Eqzo3pDSomz7FIaXZtdIe5ZVh3Nc40sAPIJAd0k7gLmIdwjlWP7xERJr/A
dvXhoLDkQLYEUYH/ADELlU2KsuAhVR8zt6qBTHMpQGNObIRkkN4H63Aje18OTkdrLmJ7KkDp3Dt0
vuYteo0BFhNwm505F5xHi8fe9HGLu7gWbC0p2qACFfUSwir5hKIUWJ3U5g6gqJ5VTQnf1gAndzah
fektZ6mw2JnNqzDv/K3H9yw2fa4+VzXxMSKQpiF/dkvRcbjwj7/MUC0Rit2GaNELOdS+aabYBv7N
fFyKmNYIfhOKPpx29gnkq03/AKKi/h5cvlKOkzowDaUEALiZ3r+KiNS4fKw2u6MrREeR1We34ozk
wMJkwoNgd2N0G2r5lXtQLY2QoZbKE+ls4R/o34dqcSMIMDZeDgYjR0FJJdtQGqFzZUEw5VhNkZRt
MolyfBuXUlBWvj7BOP1yGgbm/jAnhVXEol7SsVZp88Fc/kmjX2ST9Eu28P1UAWX24nlygrwiz27S
ZsdS12Q6x8eJWCxl+YstSznsCx3RNS9oacgstHlWfsCcXKBWonw3AC/c50c6FjQiqx+Fcg4A1Tkl
FqXEpLA1mdegNJIjQaVVDaZW7tsya257CKbuxCTbVXL8XyDqCIm3JwXLThGtWDQLMLuQU2ciKqmV
JZF4Yct4EpnGZLXc7bzjhpx6X6Xv4RFJyo0felS5LHDjomVTjD5loQymUUqOIauPNIMjalOEXEqi
dhklFGP4cdE30y3n/LS0HEo4PaadyMj5nwEAnKuGpO2pHJoWo41gDYDgz2/lKL70doPrnqsvq778
+wPRsB2DczBrRASQXbdAwNYyHOM+stgmK+y9ABZwLICJ4IGE8cRQbN5iq42tsA5UVQ2gWgbfqxyM
uR1wsavBQUUozJH1QkWF2K0BIme+zjsbghHXmOW3r2ZSoriatwPPNajM6BTocx954ultXkAo2l05
wYqydTqEpZ+sT0Uk5W8e1mjxX6A/hSfiOOvcZ7dGY2KKqrH1OThSNYRaqyyQdzIbJjisoCmrEnJs
Q3KFTG11hSqWzL99E2I4Bhy4PYU9fusG0UXboV3ZTwR3sjf7OdBwBRaRZvbIeiWwnYCX/NIp9DCK
NML6OSSaDbmGU5vi1eBKraCghg6kgZYI5XjlAVCxqtUnHoSyZcGQLbqSdY07MEK2uONYHcot87Ii
nh0eFrLSJ3SBJ1LIXWgZzlGyXzcwHKUeWHk7W66l2e4iPNrBsQzEpKiM0D6Kdv4pAxcByJ3XXRxV
JynHD9WsMYlwgLiUB0Z95btj7bEF2APKlNZKo6yMwOhAvnsvlsawnwpxZviAF+Rrtx7C48NbuyF6
ekTMgAruquwGugytqWm/KDkpCzuLmRtzP0QVv7zV6ezGassGgtjlDp56CkW9fTKPQ5wsFRlC7FhN
u2oigyQ9qTYhURz5PucvBpI5LzU93xYTELUghoXTefAibBeQfaLwhtE8yzU+XvaTZlhzMqWLFOF3
XactLDxD3LMDuGp4ImujfJKL1WVohzqZYtJ7JiKrqIFr4FZ8hQob0zS3+uVRiuQ5bSpzHlqEluaI
GcmFqJVBYaPj5dshsUJ3DTvlwHVs6ht4n9cIgu70h9wrMGvCty1xBcyfeG4RoGlcGa1JoHiqDLi2
E63sdx1M8KvYFBfQyR98bJ22XZwTNrs9thy2H+TPwCG4OjG9O6JKJvl6Vook4c3MYmiDXIBDsU5V
Ho8Rbym0IajezQSVjebF/W164QFM9zhU1xcvqR+T6dPeHv4IV/UjcxFFBnrUWpaAPk/pEkG5aQ8U
9kWX/wD8v41g0T2PFykI2DqhKOwuLEXoygSIFEalXKDQCZ0CMsWv7P1AorZcla5F5xU7SFl/fpt3
/LPBOyLaxW5ay2qe8e2jYZoY8JhFBoSYAabt17n0srNEG0snxdtVz6AMJVFdXYLUqjtyWSJNv3dg
xD7ODjtGhhAg4Qq4kHNFYsA6A7MKGEcEEqsN5b8vOCyDrIusbUV3nUILtxgQ3zpN2BnqV8i+5jMD
3oZBdNwIt1MNvRu+Eyz3JLNJfKxccvCsvkKlLa4UkAlWq/7UntqNWyb3RmxSidt77S7mjSJU3FIJ
eMJN8X0uitTGRZ6X02OpMctrV79ScvwMBSpiiOPfG+ZllFb/AD2R3nsI66EktH8dwFFJAfZ12xEV
aLTsURwmNBHNnYlgT+j2KP8APzupaAUawC6HsZtyI8uBp5Zl4OmzZIEQ3Bw9VgQbYbTOFEmbr1Tm
WhGQgAoZjsWedDH2pfqN3uxIjMBfRyvEfKFWM+BgoQ09FrltDFPoIZrV+XDIExxDqhiqCf7raRov
kLqAmeKVTHDf3rNtikVj9sRpD1OgodxMFQVzb2t613F3sddJte+ydC+5QZgcpSRRkSysIbcsFcqQ
I0SD6DQRv6+Mj1RhqWTx/wDFLOzHudiDjeOa8EtDgFBFiQsP5YQdFlUdztEirmTLpOuQRc3HH0xG
qOjU1GgoylxzHB88FIF0a+gugXAdrivFmSmtCZnxC1qutBHmMMCLlVuebtZNGUm3wtLgjmgBS6rS
jsE7hgBM81SpI0iq1jxiIT5K6emM5YhrHKC2EkQblL5xpbGXsyvGsOgFIHW7dbcnVmlk9iU6VQb3
GEgR80wghcdnVvaxruiKAkiiDZXx12ERu3y1K7DlYMr5GW+NVkmhoxU3BF2sqvbARxGkisC8kWAK
lGaWorNFGVYSMoUsxDTwA4HA4uCqcAivdcVoNW2bByvKSnQoVcTxTXYVShbAVRdazqOBaJngyHtF
gYpGiGtGt7qvVmxPHSiYCvPeg5jd4jgpvnp7OE/oCCs1TPssTObfVH8gz8Vz1T4ei1Bn/SPXANIR
FU4NHtsDEAIMXxhNztV9QzpgbsVZm9SYAaRw+7spwMDJMqmDdEttYtrStrzfGNYgOQrFtrAKKciy
bbOSxvb0HAUukJs2iwQB8Nx3pwJamzSZbZN2KHYAPfBBtOWrYQVkD15fmo8DSKb8Ni7pQvyvv+Ow
MAOwHCwuNcGFAVorBVYu/EwrvlLe4lqOxhVAZA4KWwFAL+fI1i1bfdezvmkbLIHGxI5Dtsivd4uE
KDBX9Qbily3FtUBqF2cYUXPRIQpSl7+XPjh7BNbJ7J+3dyACmSGoWICBujaEjxIh9+ZN76gK5lS/
ENlUqpo8AIa2x8CwMAcbcURTC2AvRGRIqy5xOtvVY5/G81RYRvAiwPFVwf8A3Ib3LMtSbDYmtTjx
og3n2MC2YigEAVTIWJaTHC0nwGJrYGJc8CCKECLARr1fnXFpcQ6D8QJ7Cp/UenbsoWgdhGEVVM3v
QlyY+M4j2BbNBkOXEROe3Njwwzu3oThhlpy+kUrU6X7YbL4q55qQ5XF3GA9J2/kyORtzAGQzZO5b
B0SrLcQhz6MQCl72nDCVQmrUkUD5spwmC7ONYMksrI9+SRLfn9p/gfrXh/HCxBHZ4tosuZXtAUqZ
XA0Tf68WFdoxUE2mwK7dYuPUHhENebbs23EiNThHa2g5fKhPpDKnasHgGUY3y5Jcu8/7LKtedXVK
kutrtYcorX9S6XAFGq+ADjaWCo0FhYRWXBUcDMIhisFe5DTutKJJ+VzFVEpc8JWeVgxBxyFQxqdq
wA5Yut50yNp+QiiHrB6BP9KcSYAJbYjPr3UWhWTrRciXFp5DZByKrFGx2pagKIRoEk8D8GLNuhzf
OFTrKiY6uOnwbk6y+hiqQOxJtOpUtkySCl3b0tByGwBn0Q/HVMzK+tCyNP5NoRKjh1IVkE3CZDGP
S1WbDKFsaTt4ddyTKlhQwp3emMvLrkdFWlfNY1gySZb+b7dEHDr8/juaeYEVSuDg1o40NGLzAW8A
q/AUoqqKbGBHxJrdhuNkJHzGhlKLktKHnqybZlq7ig1nKp+rYvwbKfYQDthWm3pFXcXHVXvC6i3/
ANAi+GGOCx5fnJ6XIGK4TK8JUVo1YRV8wlEKLE7bBV+HNqzlJfp2D4fYmGFZRYFbq3cdNBiYkW1y
Ma7z6+9F9k+gRUYtcgT7mAxR1IGZZoyUONcggnv25n1Mpwv+VCwUgYQZgNuFAjE+sePtQY6/8Mc4
8t0j9rCHkZAFzC1Lg6mIhgykds/hoH0ys1qhM+HZRR/Hs6KUtC0dLISgaUEZ+MYiCaImLGSwhgK/
1zh5OrxmpYV/m468BaRjqZ68wl0A/StD9qbg1Ht33GmfDVM5CRhE8A67Q6NpcXZiXlb7gPSOO31M
4zQwVPqvZReX9uWVCF5ZpOFU7K5p/pp4XjTo2jUhh9bt4pbY0xjI8YEeUj5nGsAbjpsjfzfbokCm
y9w+l5PCopwsP0Ky2tZ7+fFRLKOQSYDUYANktWuLIZWEFdQ4EE1Q++K7VPlZ62wDe6L+jLiKdWZd
chfRIEN9DVwDxjUH2EPOMgwIFrhnz4+WnWmGZmvVGPzQ5QgTGjqLuRQrEisuuTMInB9UA0VpDDlN
aWQR5ysOeZ5nLwAqjnhBDUgM9GZ8tbJZ7mhyaY8hS1wqkecMQXAOp7gEzRfBxuhHbdFkHVBaklmn
DQlgQbnqoDtul2Oznjj+udP33nLq/hj7j2UyyO0pIIJtu9OBzdtNWBerFA+3F/Knco2/MyxkOciy
YO5uFQmaul6DQQw1vurEYlBEBkNalW8orsyym7qBac6JgtbLvzB6YL1qTf8AZhYUzBV05AzP96Tv
mES2BbJVBlLCLmjMhAqrKy2z3gjCvTWB/wBqhLu+TYGpFDDtBm1KlW5kSgYoaOYOensGurrDbCNh
jA/+yf8Am21XEawtnF5zXovWi8WtGeL5pnKxsABEvMIgnYCvJIc3QGhZXSgsbzpQKvICDTVM0Mjh
OwyiDqRqtk6YsLhlqBYqlti7Bon3W0rXDvuZB5xCu+MsRqIYPXph7AOiVOGz4xMGKwyyQmp4aqxK
R1lYMr9OgUBwAUQpBPm0r50X20ZBrNq91S0L5Fcneqjjjk1wBw4egli/ip8nJTvQEEVsx8dbk9U7
91gauShYRdVUXQYpi0yjhCbJJYzXojc07Z0yeMLUDBXN0DO6irLGjwYdD6V1SDiTkRH2Q40taJhc
7QxWDRmW1tWCmTWZqvvLRaU3+qFTwFfz9NBn99CcmDWIuMrSjNoWx2A7H5R+Tjt3dmCnwYTUNXR6
YjPQ9XSOG9EwXSW3BESNmr5jVPRlO4SE4zD4WtTRBLuoAKrI5fhtLq5+AZAiXPL9CzcvzjDkJIly
OvbzxA99SoNrHmDVJj4c3QGblZ3iFVIqEMPUR7au2SeCzaBlzsF0yJFNG5vWi+E2GIDcl3cbidh2
V3QQuFEjSuzMJ8hvVuNN4WxDNi2unYhwNQAnzWNY2jXzBYKVQvgc4ORKHzCeDbwYRGzcCSmXTVQU
z5EaipWq2wImnk8SYXqOhDzIqj9Q+v6GxsuJ2aVWgHY1/wCKiodHDtb8Ws0LUj956roDdfWFC3h2
6ZGtZWOEZoZ4cR8p3TQ6wKCzo9Bp+9Do2EIIjMWS2vDy+3iAl08m0VkOJJDpz/QXcX1Yp5Kxolzu
MIp/xO3omXLQKJc5VPAJlcA15xPjcOuZN+uIJA5BRUvU44VKXgGrMgU7DyLJRDNcX/8AmiVOZjIF
bGO+U2B2pKz7AcaZ942gFkiR8g3LNo01lEPUWoQZ7QcuZaL0yyFbJ5+aREr93mGF81qa+U4LOmmt
hwFA5drqqtd5DZX0aYdfmiArHm6kpRezeLXFJXu44NUON54m4DBFbSsldK3RQf4g4mS3BofJgIKk
DuFKlj4iwEqKD1bgjU3OHMapA1kcelEwpsI946w+Ij6bulN/1XWqq3zygfJlhpHmnhJw/TaAhwDC
kU5GexGJIuIVHDnC3yJwmHAcmqW6yys8aFjAx6qnDLjvFeE/NOjGsfMPJvqbNng/4f6xfiq0oC2Q
EN6KKCXCkNDGNIK7GE5NDkEyKFyAzdDGrAqWDbWKiC+thUCYAFhaiu2zLRsvJSzFaiiSqTK1CLaa
CysQ5BVhoajajVgCEQRpVa5XWtrxi900AfBBxo31UtWwbojVwimzQUG2s7IVZnVKX7RVWwWS2k2X
KAFBuYXsDUXasAKISxMtg1VF4VkpbpXJkqQ60MYlSUWQUWwsLMuBV7GA8uVSe7gxHTlGDbRsTUJu
oYF9EkjCAtgYNRWps9RlqwZaYre5u9pja4rJ3E1amRQsLaVTkypQ2VgBFqInC1m38+3oBoK+eRrD
wllRfyeXXRK+HDjSzC7Ikma4wKykTVBVy8m3DqIEbaj37+rHUwCKxlBpgsHNDqXnJzONUpHRZiN6
QknQlRmbzBHClVsXvVP9Bzmp4l/aRn4UgLfJKad2EsXK4eIXSNfKED11FjZroaf4pms9WQ8UCwd1
9eGzjpFM2saXHtnGaAz88jWAa5WMt/m/FgcaW4c2vCkI7fRDMpTUIPWMosKZQA92kUsyiImBWb/L
DrgulDAjzohXcUtGM0gbZGKgQ0yyVTKNIrKoAnJ4uy86LYYUlE2QUYUtjgZLLEBRgmAaTBg0Viii
sAmksSlto8IKKwPM2qgvyhUFAyMl8Uc6qAswF07FUvdClWWCtiqIQM2wo5AwBqqrq0l8I1cqDFYa
KAIWs/PUaxHMAALrn9f58P8AXB6Nkaq/sTrQmgTTegCpTYWJJigkCpPNXnbKt9spi0nEgcr5vaPW
JLKMqUaQImIq0baDSRFxhRHHBkPV47aU5garM5fnInS0+mVv1m9y1VMqFwQ+3KzvwUrulNCeYbNO
lZCkwgZBasEgYABnCrhQmxTY5ePsJ7AumR2SjVV8xysJFx11K426IYyXBCyNYIVQNlmuyqviWsJG
JndV4n3Hlq0mTk2n0biOETrVEEfdJBk3bnEUskIkIrcBzmEidBq/nEgxIM8Uqkalr0p0CAe6OjlX
Al0bAG6Re6FDaW568Bj0FK5l4S7k8H6FF1IOksGEU/l0awkrx8bjr8mFirNFJ5EDV1tBklCYowH1
UWDVTZ0WoKWxUxIVGKVlYYLeQsoXyGro3Rykx9rcKzal3YaE+VB1OrgLFz5gEpJFISLTKfc26hfo
iR0rJg34sAAA44FlYwZlTne0pihyf93obVAJsW/BYG1x7bukzX8pclLiB6LbCrDEQe7Jc2DfRDZn
kRpVYsKncYd0NSKVdPHhA0zQqCX3hKrS6F6g9JNkg9aV6agN3hC1FoUyTgjExH0VvnjBXaZFD8oD
69gkEDuBuDPTbb5v+HVdQhkBtY+4E/5hdJNGPYMUVtwEEIEOQtdPAEUAAAAABQAYAMAYD5fGseR/
jdVfk2bgGWQUARIgcpsrocTUt+NlOq/8ieNrQ0NRQxGnRycLeGkMGYJKBS0q74QFBSFLUWc4stxa
qShRgIwMQmCYZm5J7W0ZO52t4VV2MqMTz3aMmXiF/f8AOLho6CgVKubOslm/VDcpilkDCmP0AKKr
57GsWw4v+NZX5NbA7BxE80EAMWe8pexw3WgnIMdD0xwqGJ3GSfOQI5BAYEIbxEXuYmiwYS1PxAV3
FChE/riShAbgTWjm4Enyqp8BBb9uBRxQHjPtIIE30QQ4TfE+jUbGt9MpXvIqeAetPbLV5AhWhDq6
CW5VXz6NYvb40h35NQMvzIX55eGiXsKjhUAGKQutGBEteR1Cl3mxMlt5L+A0W1REszLFnqEWrFzE
AxTrqWMK7h4kM2JXsASiVjy49l1luTLliTbVcQbjFxCaaZkBdzj1+yreyQJoHEIB1HxkY2k6ttDs
5oKS+NWWiJ6z8GE+5+0fObuNtzEXJ/FI8ZKXqvobjh/ceCpeMkebWDYhmJSVEfh3ArgrcPkMawSa
PLiTUfj/AJ/WfGfk14payrcFKKkYFi4KOMiZM21LMBgj1KIHwpyN4sWZ/UFNN5glKc2tkn0DgKeD
hjwIQZg5YRecFFdBrnkSkVKGu2YyyVeS16a8H0KuLJjIPQ5HANCEJQPGMYSKQUBGRL+iDjS8iKF/
/YkhfWXHTI4udQfToESczy0tPLGVCJ413clHAfZazjamtxg7ofEBxm8giz3eH6TpuycCsH/AydGY
7Smw0aNOVjmlOzXxkawOyy+1+zh4x+iD9QL70dpX8Zl+TBATQ7LnClRlr1Sgi5FpiinEhrhW/DFe
XIUBBMliAJFVG7VqUmM0NG4ZgWv4pI1ofPIl4HH+gxzfuNgKTDLYNMI1A5bwWgW+Ao5kqgVArDQE
HVg2APY6zxmNWzFpjjq9plIAjKHWj2zFqpJhsbrwicNUDFvve0vImzAoEF83jWBMKcM13vfovyK4
9nCMJmN4Uz4Wrtb3+NL/AJMCy7sYdkg0GaUu+fdCWyUNMs9OQPTHQS0YrzOUZYlH1k1EsB0WKAwm
dEJs+ZqWovn8I8ajC2jWmg6xLbNS2GlaWWYuFCRmZTGcCDo3NJ5fZCFeYtE0YhWzgYGNCeGn0pnm
z+eFeeYXUEY17Jdy9aOR2amGamYokG/5v+iNYG0bCeAVK4LVxn2VIcb/AB+N4n5M6ZRzuMfpZEAn
EdoHZbLRH4AUiUeWwF4EI1BZ4bRhwSwHDCvJHWy8wAVXyoFQI+3a68O0ZB4wBACscCFUYHFYS1qY
StxR15FbUDUDcV5AOUBUcsguWq02FuMDOsYEQDRCKkLqxBG9BhA4TFwcli12S7AEdsDLUgHU5igx
uVzhWCtEu8YXxXkr4GmNUHkATSX8bGsOmrW0jjGn85PYwyx9wh9VA7qErCQD4zf8mbbjiMenKkjc
lrjdg7EPN3WsAUFS86C9IoJ6chbPJhNA01yAvSWIopUIwV8Jta5xT4ulw/8AcFdJ8RdYAhc5hfYV
ZhTf8CceLyl3JFaLwozYBVCSQhgV4hLVp0TgI1pNYVAKSqBHAfyk9C7hUmJxMzQpWBgxzBu32jxH
bEYwS7JrAQbJNO/YslMmYfXFVkaUVq4vGrhHSgDE9tIJCIrCl8Lk1pWESuNXgJyBmCU5smBeWhpO
KAGAoKpWDAwMVRWq+QxrBWwtspFpLrp021YIPjezf8mROYwa4GxDFJQl2JoOe5DANsASDwe3srzg
G5v1hbZVBcaVVQTzDRRFEUYlwN/czQUnrKW/vN2PTohyEPADIBgClsURLFcSvk20+3xabGK1wSg5
2Yl5lw/ahjGxzXIkyKs1CSu1qK6QT3whi1lxHTI/fBrN+7VGZ5F/jUfLD9JAIRH5IWvrqC4pEW62
YEmJLEKMphiJjcZwHTxUI2SNyTRXOzlH4TbSiWVd4r4yNY75h7Nr8z+H5w+M/Jn0BCo/7XAiQS0O
o4L7EZMe32I6hbnyocCjJqdRISo03kgnH4NDVZOZkaCyTcn0GyrGI6c/Af50GKwP7ac9c4f7NiDK
uEKJsJSOxdE9ihA91WtnAxfgpHpQl6jXSp6UugXUXNzenJqONaJJ6J5MNhcQMFb29P8AJjZoBW/X
MQBsBuTPwSMLd1/Pi3OdClGpBKGvo1sN30OXCfl9fhSzcVXPIWmuaClLarKM1gZIVAVlO7Gg/wB6
ILAttotrby4x8XGsYzXlAA0Vvys3und+jRh6r55xpfr93HS2awbQ/Lv/AC93xn5NbA7BxE80EAMW
ejWqAyaBAF5ZNZcsbaSsNclAdiBl16VDjKoFxkFqFGMUVHJyBNq8m/ScWRk41mxTIUF4YGmlXiZQ
WNdQ5mlrJVCpe+w83ZVBG98lAa+HMGtml+SC9/wVQDWCkNzG6syazNYjC0wGiBwC1QA61QAvYVKA
nt5rHQvManpCASX4kkIR8lGFkvn5pQpG40sRNmSjl2pQ8awnsEalNhr2AsBZQ51fyG2K/JqBl+ZC
/PLw0QoFB5ukm1hPG1QQB4XjYCeUfyK1GdwmSzmvLbAsJNUF41RUk6MjW5frkmrzAogK1cyKkL70
xaYVtHT3gP8AdxGPOrCMlO2IM5a5vS5KeKKE7SbHtcYCFU2y0nUiwh2jL1cpofcNVkVlVbLBzegO
AQ+cRrBp52fx9lJ8b+J/JrxS1lW4KUVIwLFcXOVdYMx9By2spi+9wAZTqPpODItvCpislvCxj7Cl
xYUzYAGCEgGBeNZAIJUmsPRN9CFTY8CuLzxZ5Q3EAbPiYGJLJJ21zAJOlSyJJUlSWT8JXSctnYQL
pL9gWmbkIXDamYVc4E2P4pV8dGsPlvODkH/L0+G2vZ1uNch8ZR+TWhI7A/8A5x8UlM7zAy1oVikF
VG6cEswq9G2spRmKTKzRNanNStW1iODQHNuEBIMAYLescyr5J4UO/SVU5gyDYuKMRXERAPFEk4bI
hXqKTrqs/TECI1NXPbyKjW6qeAVHRjzyKItWEEg+PZUxW3UTtEtcTRVC0LAGgmA+Er3eA2XW9kIK
VNGmMJWlRMY/fiGTfNFrSYmYh3GdDgDtyvg4fDIeLBRYE8BcFeLOouzTHgshMCDDagNgNhO0eDs8
GlL8lOzLmZn8uX5/Rl+f1R8D5fwnYQxDlRssdyZTIbKNHsu+vjS0/k1MSpUI3xTnt4QB5osDtHwj
D+wWnC/f4ZXl/dCTVmDlLv8AjMrTCqW5Ayg0ANQAhaDiK4yLf7i7e1m7WX7E2M7DW/LCsmgVgct6
Sp/vrtXK0ffW44V8ren9CVQn9+y2cNMmagu5Iwb1jIRy1fKo7K+tOr6CGoPrcTPFkJSOVmUcocfJ
bIrmmhE6dyYm1vADcTJA/K4r71mJXzMWFYaUOBzl8s3qOP1se8a01WKrx7G+IIDNDz4im4Ip3I4l
xknmT6pokl06w/ZqMRkmar2GC0yE2Nw0Y8+Q4lhT0RZHKJdM7YopMGqNFUfsQftIhCc5B2v8u8aw
vKDHxX9IL70Q/Gcfk3gZXGCrRwuStlAo+/gW2iiUwDFq3UxvNxHHcVMsICvaPLEGnMWqc4BkcrAq
b+VIeqIMKqQGvLFa4I0cxEHcutoETzvZPiSms6UNNhQoQQnaYsB20Cjl2i4bKShYMoC5Ec6TxGwC
MCCWxYYIYJOABAQw0As0kudwIlUBmFawUYxxo0cFcFHO19hTs2LGyrRylIN5PPp2QxX4aAYX5/R+
NjWLOn5p66xZTJY0SzmnJ4wxxh8V+TLQc+0qJmaIlDciBCkDA2WZkWKpWjj+lCmrwvf+vT7LG1g4
yM+t2bZGWtZSlbYItm+9GNH/AC9C0kmsuqpdBtJus7q4hwqFxhwybHUq9CB1ju71aghjWUqAWVy6
AbvbslUUbaCkJO/vilK0tEESg8iC6FfoB7JsjMx72S+E7joYHQMmYoGMyH/TvDJ65VNHTJycjWg6
IF9IEdBHzKNYwtW7FKcLYyGxmrd6PZ1sKJBEbw8UruKOOnp1DXxX5MLFWaKTyIGrraD8mRfVUE5F
lSYOWpMHTS5aBUA0CESqtqMb7ZbYAT6ICuTN70Eb5KZdaohOcD1NBYCAmlhEwaGl8xOlnlM1rY5R
S+W5nGa9cyBnpuR3MviIAsFeCf1lOZgaxEcPlMb5ve/MS0QP5FkPXOaU7RLoxL+D10Otgnv/AC5d
OAK/Zi4UxPT6b4Kud7irnESU8VHWRmB0IF89h8yjWLO8LJyFqXzUF7p7Ps4zPIhwX+QdH/8AvxX5
Nm4BlkFAESIHKYJoHxoWLbgIYtaHtMQXwG9pmBkroMG3qIQdkb4jQMmXMUTy9Bmieq+NV10suLhj
fmNrQRDCSJ4VL/AMawoNLrEdAm9ZcyvvU2hUXqxkrGZ78V0NHB11HqOr/iRLgyJjpKFdk9OBaewj
6AZj+uRuWiQlU1ecF6/m1qkaxR9T6oei3HF49kKnJQ+f+p+jwhr4x78mtgdg4ieaCAGLPTSO5xAM
Pup7isttu/NZovASYFnrQ6ogbAoGKFgqBSA+XrqAiql2L7eGxCrWBSrND8UnjMZ9u8b7ICVlo2Cd
6oam3cwwFzYzf2IXwLkJQXzshxAFygBBq5ZBtRaALSubBHQriL3GyDKqdP8AOSItCUZMx2ZahriP
iF07ayWdyWdz6/GRrFCvSzv1/Ln5kHxh/wCTLjAtn8LvlAevWy7UZyqHxCVOlqwBRCNegApeRDtk
beixvFCyVhU8CMxB1kqJ1gyWdSlyW/iEhh4MQW2pJJQIODZTq8TlGmJOpEnXzC1oKbJONh/xtws4
RmVwEzHtdIaDgxAaO3NbkxIyEbZm/OsFuhalP3KFgf6a+D8Iax7FWL/YTiCRiUbCAYQFTvT1PgRq
suLQnTY27pIgspURmZETqVtAu8M8wL8NcnE7yKC8MOoyxC5U8+s6/wB7cTyKTpdEmpwq0PZAmcoC
w+Kkiu4MStQdckrIAqShUrXjwcPGtSgIS3eBBm1DFqwW2hbsbH5hRrB8fGe/kzp1ujE8uMgyHAFb
YBVeSMLbOZ/LswOoYBIB7p/RwWCPAFm8tdcBnPgOwruoXnu9DPVx05zMps6wIKB/pusn8XiIxJiU
WSKAnvG6yGLMhRnJtCRJvuQwzsWIpMNjeMshBm6jhU5N02SimoLm/wAhj4WVSei8LWMdTm8owNOB
cVEZOjJUrssZNFtL90UHTQvAQ7or9AGI/o287pe8W+L6ROJMOtWrYcHwQq+PBhFrHEJASSaBVHYo
dEGAZveol9zdEA/F2DTdgp0LC8whgz+bpDQB0V5zG15Qb8PIj6InmJPEvK8kwBQOBVIpyCX5dGsA
oGhb2/xIIYw+K/Jq/UyeLjsPDXIJZu3wUOOFp0fO9kXCWsZTl59BGGCxI4un1llxGGIIqff7Nsa9
TIT7I0UQ/YF0gieFpWVLcictY0Xig3pv8ytM7tXAb1ww222FMEuAsJpbR4XinSBVSUwHdDD3smri
wn3kgVTRxh3YFw7zwlGBAGPqV4mizdyo34pEYXOaxgm30OiU/wBsaxq32piVI5mGZMFh0uLeiwLv
BwEKtjhT33LS99nUTEx5YuJlGXZTEAD/AB9BitY4G3pClXCCgRRgwm5dBz8TIyk6wzrENbAzUOxa
DFQT0gMOM7QvJZMn+aP2uB9sPcUHkTNsvcvApoyfs12BrEVV5ZY58N4tRRWyieisfj2oWLZlU36e
LpGREc9XjKT1mjh/T5K9MzEYnCmnnloknkEwg+bQieTBGsXij+Av+oahrD4z8mulNKqWxYEVK5ZZ
VLyqv4jcitnFIhvZaKrkRQhJMRG7iXcY/BhIS4nIdgjVkNIO0EPhYigCu2SJsV6pWQyLR3AS1n+a
+5smdV1smG9DXGc8YZiJ4UMWBW9KsmgiuuV0dLc715UipU3DnMB4s0vUZ+pI67fx5dmpwXFQk2R7
Lo81SgdFQUgWZUF+palpqpm9H4nFqlqt7hOk8hCYItmsyZmmojn41qI87U+wxRYjNvyXAoONf5XB
mYTxRsWELQNLCQ6QtRt8rd5/Dxnnws0Wa24BXQ/WlvHWrO/vYQsDPqzqt9t/YJkCx80zaru1Qxh7
Ez9MRYoWGfwYKYQGC6HPR+/Fdd0+TCWw4FAwjRxoHwlihI6Qu9tPJSOALPThTTLN7NoF+hWHtbGL
hNRKwKfihQjHoamnY/68Nj1/2Ultstiq60kWJ+BYDwLPcAdNNMZriPHprz1WZAAugBgAVlFO6Kcq
vyGNY+WWHxn5NdKaVUtiwIqVyyyqQtFEFqRm2tiLgC66Rq7firy5TTZuWoJnp5fc1wCoKxkBy3Te
TTaxBAA1RQLQL5QkCt2+oJeDZdlXJsqEFBZYiF4UllYs+yZTtsvGdo301WKDg/2s1WP5eYYyAbQ2
27VaC1VXAB2ADAf+cjWDmr8mMUVe+aeApWttFhE1ChtuhzEK+5zEYeDKbiLzhK7AmNzHkSImzEVq
UP8AOSozrQRwJ6bOFQto0wuh9ljIqGcOpcsv7R4Rei7AcxybQ5fev/kcHahWIwqkdLEJM63BVmTr
8wYAL2VfPFTeWUmlBeTsbMGuo61UtILaIz5uIjEGnX1TVKPmsCNYsdZ2eo0/Rw+PsKqQ1Hf/AFIK
b4hM15A8EC9Bf9mJGv6zP49keiHmLCZWHC7P6JT4sZbVRWVatZK25LMTXdqrb8kcq0bW5sV3NRhw
oon5jbszrtuaFvKrk0rQtZ/2FP1Tt/TIdXORpFeO1jZIXAH5Nnh6SJbR8og06Foz8thx0CSLRAAh
qsjlIRby9YeJtmJRl7vFHdmCLJTglZNr3VZifKcGfd3lHXFCbpzWLfIcYID5zGsU6r+Ev8w1HP08
twdF8UZxKK0WtsxbRHI7tFyTNeO328OHDhw4cLhUZoMvd+Qh8pGGy6I40rBhFG5SPc4cOHDhw4YA
sWFUZX9Y0/SfovvlbScHvSihrzjJKhJQW38Gv/HAY1jaKklbiHfJkb0r0OkE4Wg2hkgQmAuLAWB2
L2w0852rKS1JaktSWpLUlqS1TA5W3uLMENLCg8niC5C4qNJaktSWpLUlqS1JYhCzSJ77HdhOTfBr
ULIEK2wSxnEuKy9EIWUtAP4I+n+fit/40DGsbSIvUDnWEAvHBjCgYLSoQ3O7yDLbd7bWrektjTFG
lUA3PkyRzY1YbM3uGpkyZMmTJmYzHAWzU1yX/d0SwUw7Has8t7TO72aB9xMmTJkyZMXEa9oHyGVr
n6ODGoshIlmkIV1SlTWeOAPCHEzwV5dX3DUHcVD2dJfoJhQ6Ja/Mkt27du3bt27du3bt27du3bt2
7du3bt27du3bt27du3bt27du3bt27du3bt0S18GEpCcnNC1oZQjeePxcFQS/iKXbt27du3bt27du
3bt27du3bt27dGpIb/rcDEVthEtFKFUiU0mqt+r/AOJQIECBAgQIECBAgQIECBAgQIECBAgQIECB
AgQIECBAgQIECBAgQIECBAgQIECBAgQIECBAgQIECBAgQIECBAgOARWAwYvIY580FfAIECBAgQIE
CBAgQIECBA8FisLgxeAxx5or9ygQIECBAgQIA4gAgcRLiORMjGqSq0tqrqrlXlhNZ/6Zk03vm6mM
wVkqxBaWuveIkWS4AAK5kxYS8Sd4k7xPaTZ2cMD3ixfFi+L7Cjx4/wAOb4c7w53hzvD68ef4MXwf
dKxvsWNfAmLP8KZ4UzwpnhexQg8f4sXxYvi+yrhx22eJE8SJ4szxJ3iTvFmeLM8Sd4nXp8/Yw38Z
d6YGnXy+3giJr+RelY7gtK9E/l/sJofR/wBjNGnl9n0mup6HsCiDBut6UL/UcroB5e1FjZhe4Pxr
U4fSzFapah43Ri35wXl1XEitLeR/ZgAhOsH9HVw4GhXqQBdNq3NC1wwE/e49RAEoODUEmx1LUANS
rDd96sWtedFFP84AIAN3z8WBAevaHpTH97EiRB2R1z2eJb+l8+bt3YbTer0W+P8ADrv17ON1i6Yn
piGDS11wgQzGjWbN0i9P2JsQW+g0P+owGI0eIx9SG43Z/Ew6PYfnx+ae+51/zrhdR5PPlF9bzn8+
n+FM2L3tsdgJzPpgROQu9Z/vpU/NOYy7d2X6zzpB8V3zN35A/rIFGboeQ/1H8d5f1K0Ll1FN0Rye
m13kc32JhWdX/SP7PYwQdDogEnEa16EmZaX/2gAMAwEAAgADAAAAEC4Pc94gHJdlDSGdWiv0GeAa
RDVevZa2wMu/+8qAerabT6fPQUBEikeDLMLyzVW6HFLJDsHTz2xCLnGBLfe7GwhvbSXHvVuoZgLM
VSd3PHyXXxqnBjnDDvvAAAAAAAAAAAAAAAAAAAAAAAMgwwMcMAwAAFm93I0ls3zZRBaRcMMMMMMM
MMMMMMMMMMMMMMMNfPPPPPPPPPPPP11fti3oMnAcMmJTzzzzzzzzzzzzzzzzzzzzzz2scccccccc
cccZHqYIzN+tttqvoLZcl0AAFMMMMMMMMMMMMMMMMI48uus88888889FcX5SO1zwIIYQVc6ihZlT
hwAAAAAAAAAAAAAAABDTXDDDDDDDDCh7wCxva4xgwAA0PsGLh6tkwAAAAAAAAAAAAAAAANR3j06T
iQAEtXkM0UxykYYAAAwAMKj1dqAAAAAAAAAAAAAAAAALMMH7hk8McstoUgLXG0U4UwAAAwOlb/wX
iAAAAAAAAAAAAAAAAAEAEYoAkAgAAAETgIM1eFHqKwAAwLgr+vIOggAAAAAAAAAAAAAAAAAAAAAA
AAAAAAcwNjxuuWeoPKIQGpvz10fTuZhHgAAAAAAAAAAAAAAAAAAAAAAABwAOFpJ8R0nAABAKBsOo
F5GNFAt1/YQAAAAAAAAAAAAAAAAAAAAE3QFLqZA7WoAgFALNR4LNW5iSAAAAAAAAAAAAAAAAAAAA
AAAAAAAy3WMPEMcMYQAEwJACl0b/AKEEssAAAAAAAAAAAAAAAAAAAAAAAABMJBB8VcIc8cAAMBYv
yCLb+k0m8AAAAAAAAAAAAAAAAAAAAAAAABcoYawVKnoYY4cMBg5mhuEBCNvQkAAAAAAAAAAAAAAA
AAAAAAAAANrGToeANILLOMMBTtySEhjOIDGMAAAAAAAAAAAAAAAAAAAAAAAANVAAAAAAAAAAAMDy
K6jqfMAAAAAAAAAAAAAAAAAAAAAAAAAAAABSoAAAAAAAAAADwAxHewLKFtabEMcoAAAAAAAAAAAA
AAAAAAAAABUoAAAAAAAAAADwBDVRNaCAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAUoAAAAAAAAAADwC
gQLjfxDiIAAAAAAAAAACcAgAAAAAAAAAAAoBEoAAAAAAAAAADwCy6vF6g8AAAAAAAAAAAAQAAAAA
AAAAAAAACkBAIAAAAAAAAAADwBxoA/BuU4AgAAAAAAAAAwAAAAAAAAAAAAAAABuoAAAAAAAAAADw
DR1hhPrWqAAAAAAAAAABNwAAAAAAAAAAAACoBakAAAAAAAAAADwAzVYJjwjPMAAAAAAAAAAgAAAA
AAAAAAAAAAoBSkAAAAAAAAAADwDRQRWTCgAEAAQMAAAAAA0UkwAMAAAAAAAAAEAeEAAAAAAAAAAD
wDBSKH0EPJzIJOCAAAAAgAgAAwAAAAAAAAAA00BWIAAAAAAAAADwBzuIfJYUycAAAAAAAAAAAAAA
AAAAAAAAAAAsAcuoAAAAAAAAADwACk2PEBqAAAAAAAAAAAAoQAQgAAAAAAAAACgoMgAAAAAAAAAA
DwBfveFvYE4nockUIAAAAAAAAAAAAAAAAAAAAAAH+gAAAAAAAAADwBP9UryzflkQGikEs8mi6sQk
AAAAAAAAAAAAAATWgAAAAAAAAADwADh6rdEUAIAAAAAAAAAAAAAAAAAAAAAAAAAQAdEAwwwwwwww
AwwADBAFIPEOMAAAAAAAAAAAAAAAAAAAAAAAAAAAS4DLDCLLDDDIDAgAAAAAAAAAAAAAAAAAAAAA
AAAwAAAAAAAAAAAVjPHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXHHHHHHHHnHHHHx26gk/zQiq
U0kCs1bbLrDfsgE8wkO03PPP3XZYOLUj2h4oPtC8l/8A/8QAKhEBAQACAQMDBAIDAQEBAAAAAREA
ITFBUWFxkfCBobHxEEAwwdEg4VD/2gAIAQMBAT8QiLIZIRBZ0d55lsxYJqcsOB8u4AVVDYYLJ7h8
GnqqFXPdA5XqNbPPHO95DV1KdFQa2+uivpdALOolgobbZDSVmtps49hF6pOTZrbxt3pdb0BXdAS2
6JeHe9G8Cuu9rSQe3mbitG4YIqSH1eINOxFLOFFLwpj36Uq/6/8AcYbHXf5f++ubfP38P9/v4cv5
p1+Tb7P0+2dfk2+z9M6Jc+lkF6fr/FRcurt65+Fz5F8a+Vz5N8a/PdwDre9hToemT5N8a/Pdzs/W
ft4fPv8AIvjXyufJvjX57ufJvjX57ufJvjX57uQ+Vx8f/XP312/4+/nBuPl9/H5do90/1f6fnu4f
/OO3fw+bvzPt/r8rfgV47+H574dgfLjx9HHZ+7TT+W+PpffDR4uvw7+/jDT4+r7d/Pr3Ozho8fX5
f++uGjw9X27+fXudnDTejd/Lv7+Mnm8ZT1Hqc9j3xGhcybThxw8e72urbNobw9C7nO+jlsbVgl9S
StOQOTaQ+psQH7yd8bgDZR46fjOqJB1Qn4vQzKZR0Xg3jQLtUOS6iXxda7zBIqXV8l8E5/HrL/xi
dunQ1x033a8J2b/3Tx+e2QyzHV7JFFDqCD1OZOS4S/gdE+z/AM39iHTxBqeOJuN5ciDgE27VtU5j
CQIiU4HsX1rt3PPujyZsyJGpZqFCi19S5QqOXlvlzeq/OEnz/Lp89cNM6HB/q+dcGnwfH2+3nDT4
Pj7fbzinB/Vdv9j3y/8A28f+PfL+/wA+Hb0e/nP33y5PfPneP+xnZ9/w8u584p0PT0913PfCG1en
t6917fkz938+T3yvHS/H7r9/rjE6v/PUfV+/bgDV+hvr8vIzs/WX28O575/8D0+Xc98Vbt+fyPfz
nyfH/j7Z8n5cnvnyfH/j7Z8n5cnvnl/0/wBzOyv1Hby7nud8/Y+H+x7nfP2Ph/t+O+ftPH49T6y7
X/x/8+3jOk31fg7/ADUNfj6fDn5qGnwbfd/H284FJok/R6/ftiLa5AoalS7dnu76QZi8o7d1wPzc
HZqmsdHQHuvJ9QFYi4cEi3gIwMuFgHqQTjp9N45cTRXAlx43rqp7uHYMDW6IyDUaS5DetdsWxJ2Y
8g5r3yCFs5Y6Q61hoB1dOaAhS7Xlx6vthco5Le3fmT7+MHTfBA2MChZlUeoA8s6NGgAIakF0W9Kd
XUIQI3YOtLZoeMWjVCoUGeYQ6dOOTKBepLMoJda4322ZqF0FOVBVhbEIL3gNdzUCETogxCN6vyz5
3+eznyz53+eznyz53+eznyz53+eziYqAKhiOoMxTQ0j6OfO587nzufO587nzufO587nzufO587nz
ufO587nzufO587nzufO587nzufO587n7Znke7PI92ftmeE+fTFeVfVc+dz0Pn6PbPnc+dz53Nw9a
OxjRHTuO+oOQ5F0FGC6FpGuKlFMKViLAFFRmt3zNLyDBlER42M9nHZHA1FJqqKJXR3Mdb18oCRoU
MLuug3GbL0qAbfKQvD0XETkwFsLJfHnnr/v0xCqqw7wl8avHL5wp0NqCFbMKBDq6DsNCpkHRyDku
ldF4xE5MUBWg5e2FediCFewU4JWt4FPS9n5+3xGXR8Oj4YjvrE5Ymp+4z/cZ/uM/3Gf7jP8AcZ/u
M/3Gf7jP9xn+4z/cZ/uM/wBxn+4z/cZ/uM/3Gf7jP9xn+4zA8e5ncncncncncncncncncncncncm
W5VSmoG8Lkdnt1z0Z0KY47KbCjpxWVSBnBexpc84yIgOoRRSJYBx3xR6AE1VFeBYRm+jNV4WrILl
QpSjRFlKD0Cacdpqu3S3WBKq1VF+q9IdtTVuQ4JIBksNjxbE6YOB8gEPJAe055d4EyL3ETQfZO/M
3m6MJCkFdrF1ZXvvm5DNGqC1AdAQE6B0AwQUjKcHnpd/XCnqoAhr2DASrWDPBweDg8HB4ODwcHg4
PBweDg8HB4ODwcHg4PBweDg8HB4ODwcHg4PBweDg8HB4ODwcCfK7aV9aePPfPL8/XPL8/XPL8/XP
L8/XPL8/XPL8/XPL8/XPL8/XPL8/XPL8/XPL8/XPL8/XHd2QrzKz0oPrHpkWgDCBBygxjxe+N7SA
JZAoTcC0bZcd6hCsHEHC04514wQbAXMAfx1AHzVsB2Fz/t1aAUFJEIYAsYc1HFQ3gZWmtxXvYRZs
xCY7IilxbFgszLNrXA8wH0WdLvGAtBS3KNKRAKbXSQUNbQlU3sFjJCJaXcpCnLXAjngC5kKTV3Xu
9wKxKKH1/OsT3Na6BzDt0uLjrE53XVAJKREYjxiggiXJDWzAQpoETEQHKFgfg+UvP9RB5B9ch2PY
wYXUkPdTmsxGZ0ICdysggQNKLPplUDFito3FXLsOx7GQ7HsZDsexkOx7GQ7HsZDsexkOx7GQ7HsY
AcCysLOD7HtgOAhQIlOGj6ZY2EXWA0HhyGpPfCZfkAdT0KyOl1u8w1gCJ0UIJ1GM8hcKldSsgccn
PQdWJh1NKqReOUkIm5khSLSkYUFxBIBV+debBCA8saU7E3sHHR3D1S9ew7OsDs8gu/fxWmbEBRBA
ChTSw2BAz0M8A/1XQc8PwpM+ygKCqFVVVVW4KqgRTSHfW8MEgdJWpwQmu3pwwwLWs2O0TrZ1NTnQ
YbuIWtkAFETUi9WIUpQ7EFB2eGJoxkUAt45D/f7xRxGc3qXqTXUF9ZMbGI6LLsq3CwgKhhFjISDg
6YxWpj/0UTQlBBDoXQpAurhYQJmdlNJXGynbAEpAzJfIpRsIpQRMA4XAwXtT4P28eTPg/bx5M+D9
vHkz4P28eTPg/bx5M+D9vHkz4P28eTPg/bx5M8vykATogre55zRzT19dSwlF8gipshzTSia5DAYM
YtREbwGRJRkEkjB4BLTQ7SnH2x3hpT3dhJsRBUYAmsgteFWXbZUykKJ1yZlKUXgxD54bw5mqF5Ml
KAYeZpMQOZrMV4jwjrU32dIfF0U/wcfX8n+NIBahrQR4wg2JTbS42mZFVAiYRKQWYLooSIERuAgI
FRR1nTwCdIRnEEOAEaiI1YY3YyG6115xPOxoHqEvRzAehdNjEdFl3UblYRBBwBMDoJkh0oUgIAn9
G9ATU1Q2NMCiWIxIxJ9/OA6J0zLrd1iKYGKZAhl2wa5CFY9SUmiI0CFKh5W3Lo0pIHEEAAFOFAZu
O5CNKMLQqxazXKtGtEEtBjgrBawhugWGKHP4X8euR59n/nk98jz7P/PJ744DoQARoUyIY26cFhjN
Y71YrAWTYHeGaE1XDReafV98QeS+uC7dUi9XqF7eusdguw0EgADfqY71jxZRNXtEFSjsye+bIPxW
YqECcDjGh1C8uAnBFMyUSVow2ahjwAzC0qtZO86gGgBzRGgQk5FAAMNGA/g4+v5P8c84lFC38jkN
eVHzlQkEZCKCAk2gCHQmsRXB66h0EXhar6ztoK9AIJiBNbVgJ9MSxxInIbOA4NdjXfJ/SREAAROU
Okeo6zQ0CpoC7da7d+uIaaYJvpnVNDKSErkNuCKCiqVoa1IlXC8lQRNCnG7NS2nOLK4tHpwXZmvT
jpgiyVKOhvds+22LknXTuEuVufpG9KTzOf8Aw2bNv/p5S+oBZolaSIG/AfwoCoTmu7UjdwKkOyO5
TACoY9sEgX6JNECwhGQV1IsZW8DIQzgwqgmFhKZYbEci0wVZC+WZEXzGJbUGLRXoRFI6s/8AAOPr
+T/G9TmmaY8NIoMiEg8jXxlIALEIlDEjsQt6cJAJxGBUoIBwRIEoKcKY/CqiQNE0sRTaPbmsKi1T
vAdXd5AIR/VSqMJUjO1NzHbtsHmFySECBUdhF00BFJQkFWoiosVV24CEuEQu2BAr2zpwJVJalILu
CFyFhsvUXdcr5f8AyBNBOqX3cmjYgmMMDqHv/ChVMRtcUTTdXWuSmDi224BKqosqgKHSYrakwEf+
uPTgQ30E3IXAb9n/AIkU9KGg3s0zyLAtIR5KnxluTAad1jFpg76Jvoe4Q6gWFC7AOeZD/JOPr+T/
AAoPZMQtIIIGJyXjdu735ccC5FAt9QE0jCG94AACE8qs3pXkm9iQCBaVB7tKDOle766wFAWtwIoO
o6HATzXpc0hOehkdFoRlE/jP7odqr5OFipbgezTWtI64DRNc9BDkAUBUFJtf444wDsARrXypdTYZ
K4gMHQQBkrVz4WYNLB+RLQBzGFQSJ5V6XmBcJWbggISYkty2RIERXzTgZLHXZTTcyAMLNQOM8wIS
TRC2IWaTldkBrDNXK4KRBXOZtLbgWKGuFqWEh/gDQB2FPw4VylHX6R2yEz1Sk2RoFeT54PLWVTz2
uIm0wgQEscWV/i6oRaxbBAXqtVBICLgJxIuujaUzK0YcRZN50ApgBRWuB12V4ESXDJtY3WAYnbsZ
eUBkzdSECt5qjsP7LOtJoCiRRiVETZUruKOlxrdXufxhRqQIRUk7DtLDU3Ljg3gAADtli+uCKIYj
rg0CUO65AlAiBNtGgvYhLoIHOEsHGNMbvVVaW2MQWN0aDsDwTdBqC+AEEiK0GdBiBsLBfuJj+T8/
+0I6hg7Fy5AV1lGJRHJj5scNYzBPGAdtRVAxdAGoHCKIiQqG/W2rm4xoGEa29IhlANQbtcExAueF
boL1zGdmeX2aLCMQpYMLEQVzZOlO054SZBuJZE5QISTUZGFaG75BUDeO154u3g4YFhVhjbvqm2KA
lw2CSLGGgDACkSNqKFqJg0wr/VaQU7WDWrf4/q4pd2IMoTvD2yq+GiJLSRKC90LxiD6FboO5XUNK
oarCAoMMpxPL0MVhyKsQAKzmMKkSA9ABBAuRqBc7CamAJdsJdp3nsfvGpKoJPFvH/q5G+5AOglKa
cDy9XaFrJ6gdOI6xoYS7dwJtABSi0TU5K0jroWmpNpXW2m3GvBhEiPt+DWtrzRLBM8p3hEWjCMfA
CBVqNxKDneGtDZt1MsYAgoIuK4o3feSRJN6fD+4FY3Z2t15fPjYwLGCoL0FBBeUQNg8Zb8/lmGwA
BqFjkWvFxdVGc+uTIkX3BRlZqEFUMOFSQfMDWwbEIQZQZZTikvVDui0pjtVtEPKDHlUB2ou1crEr
Hk6M4vpkCoAvLOfXv/J/t/L/ACcRIstgUCEDaJBx1ndExE3ChkI5opjvxTRCgBGHcRvcPcZ8NBdW
X45qKBD0yISxf1kQWyiQ1sxI4ccHJP7LQSAwbXHHWQLKoCPH2OJtraKkRrUjm2yZPzYw6MZLP+36
KbCWysab4a07WF7zf8JnalGaCqwgq7ApJzADoUbRaAxkcEYeLikKqvUFADYjyVm32g9LrSCNWpOy
DinF5MRyDeAqVrEBD6VQd/NGCsZSi2os9AlBXB1TKBJ5ZhGFarQJuQTAZX/jA4+v5P8AFiMHZp43
rxkgYR80RkaVgrwOwiwELPDoAQASaDTp+pAFUYEizELAECJCIOsE6nZBl1wBoTmm02kuXRwBiEnu
nEbmBqZyo7dgO6PMg1eDcYJg7iFSYjg0Og9W4AY2CRMoEX8kVQiWblmCBTQf2Wkn9x+Qf4xobZBr
eHx9ckmzVdNnHn9fwamIoIfmj6KMC4PQgggm+8y1MJzJDSCN4KUKJkQQnWmy1G8aU5FnwLggsIiK
hQVkjQjSOTgRha8kZI58qUoKbiuDSZKHsXUBse0kpQagUw4+v5P8qgCLWxIoPhTprIl6tKJSaDjT
KQeiGchbbDTFpwum3TWUqEynIOidbiYWhNdEIPCRxH03kEmOBLRRZ0rqMrN5RsUPplAEcTjwgkEH
hHJrFAABcoYhY1XMaYHFEISzp1LKIEhvBQKAFFCCri7QHIIxE/taE8jx6uAhLL1wHao0ToCA5sbQ
7/xshJooIDhmOcEiJMgg4EohMQP4QZWRNKCVggVuBq4kBKR6pkV3YoOBfiSNKSDuDuuwZQi5ZGEJ
oxgsKRbAK1lSxOJ/uMFxIm6mmy2VsBx9fyf4CR2J7n+sfvbgwBypr3bOy5bQauIBKMBVdgvf+EEi
CPIlH6OCGamWNjs8J9MdMrdFMTqecJ0uEAaRSSAQmIM+bRcUqpmAavxk6NnQAMXytVQxZxpJ0Qob
SwErMImAA4Rwuw06v7TWkNo+w/wV4uu3+I4+v5P8emno9shA2Wl6n4ny4CJACt7gLBDR14b1UAoI
Ox2PvhAxgIBsIi8EeebTFwQUoKum2XcOWQQ6YBwD0A/vR2qJZGEeB3zgKQqSwqKC8xKnZVOX/OpW
g7DA2Qlh9ueNXD0oIQOnQt1/B3rkAp0oqIq2N7W+uaCbEbsjmoDZypau5rBvYeaKMHXl2zWA5DuO
alPgVKGB5mVNstQV4IrHUTyweFxkV2Qnlk8oUkUepqFvvyOKdWArmoLwroJlFIOQrFgqd85IR2ae
x2DUcXOYuj5oyrRKrpybpf1gWjBSHCmyqUQREv8AQCDmqbYbaW37dJ4yAve2lhyHFqCCQnNoOwpV
54rIycugJMUQopiRpF60rUFy1gBEoEiAQdGx19eecCAHAAHYNB9D+85WM1GIIkRlomqdf6ATQjcu
JgC7wAlaFWm0C4Ci4QhOS5KMNJ2tsVR2ra65sy1INmxzXkFRB6A4CS8YIVaJYzje4x3jcptHctur
AmFc7DWggCKfyQTR0MrAhZTgK0ov+RDZ5L/m+/HHn+CW0iPUTWPJUUmycL/QqXH1HZA9UWOi/VyB
RtHgq1VjYaEIvFxDEghswBAAbkJ1nGbZrCk3LtZVR9YqkEGFIlqCNrXXL06msQ0IPTG0h0f9zIIg
HkN+7/AHwrgjhBKE3tI6X+h0UCgcKCnopr6YEi0DZWTR16dGPNuGsVAURjLJKKPoc4tHh1hIYmxQ
6qnWUb4ExFKoFgN2c7ZjoTRamWhKe4dcaAqFMJg/xKCRrA8ZoAYhsgVZNU2igrSqkFWf3/Et1zr1
1/n63wH0OP4aTUpMUpSM5KDPH9DoiRsex29PnXBamrbSjaVOWmM9csgbz4h0Tk9Da8BAChNhXnLC
1ABGwqovFSNG9Le0xOXp0ZgkkbRAGKbkgn40vZGBNOxsnz4G6oFqS3QqxgN2vac5ByJZWUKqv+IZ
aAQdjibPPX95IAcGjtDWnr/mT8FNU0H+9de/8NJKdnJvbhuKnoXvT1n+dorMLRtXlrfPLhssKBo9
ANA0vHnni1GhBoSIXEeoBTBXBSEAwCEvB1kGwjvFkgQaCQAhoAA2ADQYsiKwpW7WpyIE+Ri7dJAg
bvmAhXiQJZ395Z6ldYWn9o21JY8gUE9EA8fxxNTB2KwJ1Gcf0PRea3KI6db1L069tuO0S7BVInEe
3GChBQ7Ch7cZzz/4CMQBRztoYQfSH8ReDjb4O+UIk1Nko4CzI3x/7ZDdMGcehfTgwKmQzaD7O3KS
9PR/HOf/AETXTrZ1Mnc9/Dz5Miciev8AiCEKVGx7b9J56PH8EXKOS0OxEdjnX9DRNCgTwujlxiBA
YYYl52GvL068ZNYPNIQI0OdSDW4XTEKEVVdrt5fhjypoeuqDW0Bu5KpDZVgiMCNAikc4I23JaISn
FQW7OQAAUg6kB91sobl+7ytShxCOdXBSt6GQEUjcX99uUULt2fFUC5LKrD0XWuNloDLb+OKw3YJZ
jn/6uP6+rwfX/wAU7/Hj/HSyl7XeUspe1L7ZtfZx0RUThkMeEHkymTXVO9H539/89e774TRXpCGB
SgplSJAIB9TjuD3QKF8rcxlXHV2amyLR2LW4rtwaFi8rOWr9bfQpgpctiX4RGzyns9DgNmgLzOsr
kBm2J1i6Bdn/ALUHGaHwI93z1X+GU9WO4ME6nY61vPn+7/O0M10gQQMtOo6U9SjYbEZRBdt2rx1r
lwgOUU0IkUE3uJBelAdHl5keWASTicacKgDDZKnTfnwdyGM5SSUDHBMJs61jnNERRyCKi4Wb/JHv
458eudU6nJ1Ou+2v80AkUFXYBl6AB/BJAhteV+HXjPgfJ7/5kjABqdCCxxRG7e65bXa6OvGI2SaX
skR5RV0Kb7kTAADdoh3cNQ9Y3vA9aA1BKBIxnumkDYNogkKPdqqtPtCmaqEqDZjgyHOQEoCZQdfw
l+2wREuCshdKk8IBI4duwEKTMGIjs+OIisZlWHL5zBA7K9S6U4HbOeSg+qSMOdhxrR9Qe5+/v/XO
44VAaIr5xCp8V/mQCII8iCPqOn65tW/m2+pt9VyJCe9aNgP1AD4A4DBgvrY2pQeHI8Rzxs9bYuME
IEVBA1rFWAiXRsgWjamzoiyDT9imWg4qVwIjT4zMJEjJKM0ql4EIgrR5xcY4Ff7uZGDkB8NRuqmE
SXgMxzcNG5DIblbe0ViSULNcnMEkWAcopdcVXBCIQlFwgYcwTROXZGoLQAjA5GQR4wCzLo2gqAmm
xiAl9BV0zzgOY1lFgQKkkiya8I3CeoQQUiRIEZRmNMt/mZ30zfYdY0ICCEhGwSAdCom0cf536NQU
T1Gfd/3/AL/oh0GEHruyp/3gxKgAFINE4Orq37pJLEXkKMZHPDfV1xnxjDYusGwFzKpOFxNwFhjw
wIx5Xb8d4Us7/cuI1QBMArBX6Z8H3/0Hf2+zf34ypwp05eO38aZrklSWyXi79cSKIn1EgCJZeAiC
mzXRLbtRPt6rIAQAoAAVODqQ5RVVf7hPpol4sY9kx6elPe/4P/0xNDNCCAQOB6k29ch2PYyHY9jI
dj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2
PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9
jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYwkCH/Tfxj8
TiMISqF0g10C5wSBN3vu9v284aPB8nj9vOEB7fxeD8DDV4/k8H4FCni+D1fLn2jq/wBvX/eDT4Pk
fBfRw0+D5HwX0cNHh+R8fntnT7XFvR9L9sNXh6/jr7euGjw/J4fb1w1eP4PI93DV4/g8i+rnd6f5
n2v2+nU269T6Pb5q/HvjH7dtfZ/k8X7dtGnx/J4v27a0cWu50O3z734px6Pb5q/b/m8T2c+3fF4n
s4ap0/g8j3chvsvze59++/sXX0/6s0+H5L4c2+TpL7uNHs4aPD8j4PZzi8PP+7439e2HtPyPj89s
4vDz/u+N/Xth7Vz8ji+jgkNTDrfCezgQrUOtyD3P16TfXGy9f4nx/PjOI19LBddpTjZeS4eMJ0Pj
H39c0a6Xs/6Oe55mPQMvm+58nQ0BKrqyu3Zd+3R1kK7DvdrdvX3z7V8T8j4g860/S8H384PPF0/y
k19uvUDZ3y+MNbPBqe1/gAfOIq1CkgC7ASy7wyqAuB44EhaDwvGf/8QAKhEBAAEDBAEDBAMBAQEA
AAAAAREAITFBUWHwkXGBoRDB0fFAseEwIFD/2gAIAQIBAT8QI5fMtoZgAqEZUBp/YhBihCbMZL2Y
vM5pGS+MYyt+fxzT0BMZP2L4nVviv9AGj19wmVe80nMxmdj/AF5z4uPQ4hZJx5GYmrRRFw7ohtfr
880pAYb7MhM+hnzrNaZmkSOqcbNt7oNJ2S2bfR7tb/NfF6dF343v8Xp0Xfje/wAXp0Xfje/xenRd
+N7iYpaETI6Xe/Nalnf/ANPHjx48fee+v0x9575+K69t9ny713Tblt288t/nv1fe+37j22j987xW
qj/hw76tG642dOr78tdn237vzUfs5Ecc31/2/wAFoaG+7nf3/wBttDaPU3p/E3Ijd/bWu07fb/e9
OiXbX76t/wCfT7nyU37Tno363dk4w4+/54abtr2Ufs+eKSnR0jt/PrQ77kSF8iS+bXjNSOhXmDJk
hNkvPFrpThSnaLtEAMMQMt70ZNELpygi6BT7rKFr5gwGJLY4TRlwsLwwFJN4zvGaM7hhFgLBUGJJ
0VpoEHZeEBRFGLJNT1kQWZAQTZjMZLaHMxN3bn19Y5oKIeMF5Dt/XNFubUa+jQ7HxdZtF3vxnRvx
pxMuWu41JhllmLqScQpLXVdtgMzfOb3nMVclMt4ZHG4/bViTThsiSXUF+2dahiESJHXgHET6e8Vs
UHi699ivivi+6/vsV8V8X3X99ivivi+6/vsV+HDhqnfjOJrbKeG6GddzM6NS+uJLhofFjPNba40G
3q1NJmu1x25Ff5o9o+Z3BvnMA0vi6nmlog/XfH3muXYp0V9htvyKNfR1489zG9dnh9x52rs8PvK7
PD7yv0PH7zzX6Hj9560tH95t1ynFa0v6aANeyTtaML6DR6R8NcdwIacc2+K7X3c812zb8fPNfB/D
956zzW3oacY/rHtvXQdvw+K7Lt+HxxUvZx+HxxXL+/tzfT4ruu3PZ5ZbuHiaPc3u/PsWAjEBJLpm
vYVDMTXBbY22Fr/J7qDL1GjDh7R8NT5IiasCvqASwii8NNy0iGUxe9q23ZbRZQkQJEWfY46euLaC
FgEJ2tjNYhnIFQ+AsXo2unckIFgZZ60ISMEzIcsbKAFBvEEQO0fB8xekIJoc3ZjYMhjllEEqwCiD
fQZ4gcrl1gilBbhDwAK6IRm+4DFw2UxeZITKEN7WM41ckWDgLAJCwNtCIvBF0mmIlE5AEJZdtjT0
oSyDDK6TMmGQ9ctKSPhYADlYblkbxeP0HvXrb9B7162+G0ax9/bx8No1j7+3jWBASkkhJJySkkM4
i7HJo0OPw+WuTRocfh8tcmjQ4/D5a5NGhx+Hy1yaNDj8Plrk0aHH4fLXJo0OPw+WuTRocfh8tcmj
Q4/D5a5NGhx+Hy1yaNDj8Plrk0aHH4fLXJo0OPw+WuTRocfh8tcmjQ4/D5a5NGhx+Hy1yaNDj8Pl
rk0aHH4fLXJo0OPw+WuTRocfh8tcmjQ4/D5a5NGhx+Hy1yaNDj8Plrhae10964WntdPeuFp7XT3r
iNPi/D5a4NvY6e9A+xofd01yaNDj8PlrmdNGnT3rk0aHH4fLXJo0OPw+WuTRocfh8tL2HpCDMiMi
wjwpqzKCX1k6wTrkG92EA6JaLIrXCG7EKFmwqbemLN0JIYmS4C9uERVMBZEJVthJkTfapdeBkWkX
qKeUYsEUeQICBkbNR0zjBUlMiJuIw66i3osQwkFpCVzATF3ITdbwtRLBwIkrbaRULYYCn/SbGTY7
fIoi2+KoYWYnnhmIKgnGM0GAg4WWxuNTNruhYMLAh7AAIlbTg9lGOeBSs3X+LgYaA24NHb8m1oFy
UhIknGJZbQTEkEHwHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A
+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3w
HxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX25L3NnTqX2671+XiOu9fl4jrvX5eI671+XiO
u9fl4jrvX5eI671+XiOu9fl4jrvX5eI671+XiOu9fl4jrvX5eIWRIYULcJ5gS6kLbEKjk23kQTYQ
SEMRcYavHWIMewkyaiJQLVZQlJAkK2Gl8Smml1WEQwDZGHHHNJtMlT/oiQBgEsU5U7jTdqAEFJbz
EGH2rfGoEUCwWMzneJZuvAi9oDmfDSGoBSwGVIzvpzNMSE4bwiuLBCAoRpZyVcoAZaVYYgAUGeqB
5AjIyYAIwQysGAQQREtDIEl4aRs2nKpMYq47rvXeetu9d562713nrbvXeetu9d562713nrbvXeet
u9d562713nrbvXeetu9d562713nrbvXeetu9d562713nrbvXeetu9d562713nrbvXeetu9d56271
3nrbvXeetu9d562mIhEYMl9zc0mNYmuX2c8Fcvs54K5fZzwVy+zngrl9nPBXL7OeCuX2c8Fcvs54
K5fZzwVy+zngrl9nPBXL7OeCpaNXTEhdfZ7NC1GeGVEuwvHmona6QmCXbADFKPB0OZgjQNL8LTA0
BYAxcmI1WmYGS8wR/wC5JZIAXFSVuSQ8BvaOTAokFYMyKDyIggYSGzoyj0n5ifC14wnCRABmDMN5
PcVDGVO0RmKcrXrJSdYGRb9RjUkxRaIDhFwcDHE1HnGbfwjUkAwwbheCYpFAlWCCF0GzPiloFC8R
CzIgPzvxQxQzbkEDLDN3e16MTG8FLAiTLayYl0GlMrc0l0fXXQi5p/EQcg+tQbHgpKpYxgJcOC3U
EApDgIo8ZKkj2nCGQy6TMYToKGhkGx4Kg2PBUGx4Kg2PBUGx4Kg2PBUGx4Kg2PBSQSiUGEAFMKCg
5BQy0QoEHYSXjmc3vFt7tS0M0TUpMpmxCbMc03bTChQKyJabrMAJpPZSWsrGmbxoTQNOQca6wyUC
HqCakNBWyrBnlGZgooZXLYTzZzj1fLIvfZaI+GhDPTVLhcXUskDBmSARwOFD4Z3NxBZrsUdQAGCx
BUMillO8dKXF5TJk5pykdgFHAQAAQAAAwAsAWAsFRZqG9IADYRJMSrIzBumZm1RFNNtRBxhZCCBB
JK4ikVcSiQyCQKescAoFFZkokZF0hMBUucRi2YMJYmAmZiu/1+f7pAjZGEJGuiJJEKCGLACmDQTI
JP8AB8mlCGlFEAguikhdCnU6DhnWEfk1UqtucIGCQ0gKAqLsyxUKRICuUoa3f/v69bd/+/r1t3/7
+vW3f/v69bd/+/r1t3/7+vW3f/v69bd/+/r1tK8b4ETqsRG6c15YvJgdzhtSAw0NoMVpi4gvkqQH
vkrDwAEYgqPoKkboGSaEJDK0NKPQI3fuQBMxQtRCmBKhRCQYl7aNDAkaz4hLKDF/EFJECiwMCCQP
WN1WgwywKFlCTkrVK4bFnR2C7EJdEv0gfTB9IbRA1bHBOSGSHQna9KQfoLQIEMBFAsBsRoEyGsCC
FC3GHNAythIiAKGSybgFIRUmkCwUgySJxcGSLgyIIYmCxaxxiI86qsGVAjZWEIGuqpJUIyE0dGHm
4oEiPD+Ao8BcXgiDaQFZEte4iBDMCgwkJunCMgR0INCWRl0kpQrpIaSlkLe5xbcAZXENlKnTnbI+
lIKaEyQjSoWRUlQgAhK4ADn0LskFxpHpv41nLBseCtgf1+K7T/tdp/2i10k0wSKEZFJARlo0+yzJ
IKTQSBOivq5pK6q5G76zf6IAk4Sy2QQyYtqujR2oF/wuoAIQIuzZ9SC+q+MB7UTJBYHQSJ2JCvwh
ERgW3IrGhRlDuCIkSSiaQtyYNVCXGZwnZCQyD71c5DEtcyoUuFH6YPpAIsMfCJ8lHROMnASMoGJJ
ZtIyVLIKjlZKYSWTOrEgMILYCHa0CaW+VV01YCiZM3kFpiUt0hIsRm/b49f4apnEEDCiEeS9Lsqt
iV2CIJZWgigRjW9I6b2zosFKiE3CYxoMTHtaIl95F2yAErpzvzUIOoBKkAkrDeNVG9DiDBEqD4iE
S0BgCS0UjD7bYj0be3FGuTMGY9D/AOFq1b+rxAM05kTCGlqxmZvPN/b6SXMAIssFneh1DuBlrRLE
2IjWEZBUDLvo3yQ1AhYFMxHnkk9hazQB0ZLxamcSZqZvMoOeyBMJxqAtaCNGnAhD/wCBORImD6Qj
AIlbwZEBUi10k1pefwLSArjhURJvCys3LUhGNEk3n1bVcGR5LXgLkblszDdKUqAiChCY0AACA4BU
GUGTEk3JEbXDj+LLvUsRLG0sb/3UvTDIpxIJDSEmjVwZTISySgOSTgtLRIgQoFVUUVUKjdUORlWn
IPUr/fof+WkCm3S+aZllAgqcLoxKtf6AgwQ5EeEz7U8rAwQIkggkN0iJtdowk7CbyqScCBKSypQc
06JteBdfuAIKJ7JyksrA0RSvlkGyaYuNNCkhhQPbwpwXSaBQrAQmYaf9RRdeM4PpCgrAMgBCyyJE
8M4oK8uz4LwDAUyUKSbgdAy6IWAQ5WZoJdFBslDNoQTD1JzTkTgzDKxLMJ0jX3JwNPaJDCLt5mkB
WgxdAES4BN1QArhEkwEn+bUvryALN4i5ENkmARhAhBCEIGwcnzc3gnB9EERBHIkj6jUa2NpgoeEE
dDXsXsD1Kg9ZINRcpKKjMc6xL8SGMefAERXKRYhgzADvaWClQQEsmCjW3bikBOaFD1DEh94Oe9pq
kxAEYSWREEOVpTQmrN3DppuOoTNztcxGiSVExVK7ofpIJCCORJPDQUYohBR2iWcTFYsFWd5iyfaG
ItnGDg9BFMisyZAiR0lUcJ8yiAozgDbZEoIx+lO5y01mEMAyWo6IFXAX9SY1EExUkxDURLcCJPQM
qcg1FjtWyJUHFYBODG015MEE0CCJCeXCVL/+T9eGNokmiTQ73vQCMi7bfP8AB4+l2wDxEaZ5tFTs
SEB0hAJgV0CtopgBKsJAcKAYCY4FAm+FgFgIDCLkrTKSsmSXGiS+oVLKy3s2G65JLocRBIygUSjC
RYkByLEHGQnhZTUlUEgnGcbfVVyzgvsEB7Fjj6hTMIISyQiw6W1/S/SJgUPm+oJZIEIAJQd5bDmB
gaR6tHLQIQhA5SwZYCnJZQFCRXdRJqUyICNiEgFSWZWEQTkCybXEuc5W/S1OhUQKYPHfiCEJdapX
OTpYIdQp9gUaKEsDhRhjKRtQVWntITLisxLUaFyal07ICs66HSCQhbFkLN8/rum2QoVOsCiIAFCh
MP4pGYn6/wAhtEyWEyYnnWlVvciUKEJJidG0yUDQ7ICThSbvQWRlsQxGF4D7WWwgmKiERAAEDAEE
WAF7AaSU7U2mhsYLuhxOT3oACxBYI5m1rqvrelQCkLa7Z1+/4rV9D+3/AM8xAuEgBNcWqBGIowuY
ukLgQIZQIQGUAF0ADn0SwmUCGNOauWcCqHJFei2rB2KSRAV2FLop4R2cJYu/0kIjA08JWlUXysnD
B5SylkUc26LthuubxJi+4NjNP81XqyPt8XMZja2gACo4JK5yKA7Ut/TE4EH1DlofxFWol8rEsyMg
XBFBCabmWBIyMClDYy2+lxZBYYTJOYcmDG1ZVbrl1fVzRIgTmFJ9Y+pBIIve6i+7d5+rZB0XJRCi
ohtLdmL4vRlihED4GcaRhzqS4Jcs5E5/CVFqM1tjE2rdZy9FovXsiyTyjKbqUQDWAYjvhzrZJNAT
MA8ZoTkIUqqO1LSbJiRxJRCSmd4966xlV8DFCKQ134i96VMnlH8ufpj8kc3MQesSxtLQoyMJcTI7
0SYiyTuJIJBq0EkVEMemALgKAoq4FUkNjtTSCAYzE3aCiRNhKEArsDBauJCrguZXbTGRSTu2iZID
VzEBYY6hQC5iTMtG4ZVyiRkRIkEFVMaVxtsMLo4kwAH0wfSAlPWrP2LMBAm121pbsxMMUlwrcDKQ
VkJ+XlIzYKSIYdsIskIMFENAWsFZLEDkykDUyHDkJFwskGgtevCaKpHEWYHNcAVIglPFwgZpFXIo
d6N9LDik8YgtGu7jPKkpB8HxTJOG7WVmGdEtllfyh/wPwtBKGJYnETRgsudV2z5c8GlKhmbCMzMl
B4RnEd3QEpfCmtLcmbYc4v8ARbyuZilIogfUuZAkBUwfAJyNy2YWMHozY01FB6WQ1dzazlEqJ8Ym
lQMsFk7BCUaiwzerUruWlGw7DYwRCspg+kClxh3KjUsgEkIggjhnSjB2N6hIJCCkYRJSS8lIJg5l
SToSSUOFQ4ChCKJItjiRzi3ophaSfRoBIYLwUFQbWoo/YKjB3WYNgUgoPJGEVzSTN4tfRiVMF0pQ
EViocJwCwkVtKEYC0D1aQLmtxxhMWoKiMMIAKRRkGWWABRH+UPULvAf3QlAlLxiagqJEBpLGwkOR
e6lCjIomEYT3KS+O4VIO2JFEnWEiEJZdKJtIqmC23tHmzhQHwCEXNUa0NkJwYnUtggORmYgAIGVN
cIMyZucLGC1H1nD00RwaE4jxrE3RLZQpVni0+LnwfSISlha9yL8Q8UMoBHkABdwES7RTTBMEoGcm
YSTecwwykJG6JLMQc4gtbbj6ZtmdN6kWZoWksB2+ttsXWR4iVKLdaEWpLRCJ0S3bI2mnUTCJrAYX
+jFFKVGCCxBf5ilMceWKoQERByiGpupP/lP6Pz+j+/0lxNtv+WD6QBIbin9lS0jOTEAbTayCWbsC
NINLQlQBAW8WNy1NKECkBKoXX2vv8KiENhbgNBrBBhFGZpRECe5hspCMWhWFoIRFI3AsIxHGoRG3
85TaLGJa2ImbHjivEi4mePWCd4Nj/oq5ZwX2CA9ixx9YqWxQRiRAkwmG8selJBlvWDRaYKyOZp6I
QEYCGzDbRz4oShBAFy0xKwDMXRYVZpi+gCRRMpF2pgbUHHuKkNI3xGx0bM1LCfBAlDS8gNgWyBb2
cl5K0SgGIOFUtlljPbZMrxGJJmmmPYZMQhXFRG1LhlHdSiyg42lq3op1N05U7UyvOAjiLGfx4xXs
SeUCwySiRR/72pTm5b3IERgQkKuMI69E9Y4MsyWkbQiGQB6KklXLKTlg2EkHJNbFlSAdQWyQOIAI
2sY4/wC0m55/g2f6R8+SnMReP4FqXD2RrZJQhRXtOCEkEuQAtIxBuFi9QSCQdIAkG8KSrEI0E0gm
CeQBDKQUlAWbEhMKhmolZvlVzLMqt6kSYkktuD9pSoWINx4j1BnN90g1LOLGER6hwf8AOpC2IlsT
iXExeJ2okCzAYZJ1hlknDLP075x/0GdIvEfSTQRsSRlkfwNoAbDRBMpkQgSxAqCyYamqHAYixY15
q8QAgSdWgJRFWuRa1ahYGFF3kgyULCpRNdIUjYBHskjSpsICGZPTDQT/ADNXIDCJY8A+30EkBgIA
uhEEOMg5P4FpAulAMohTUVGr4NBC4QgYBb/Otx+bNVoiwVM6C9KoAMkEhgMSEIgIwTA1I2pr1hEJ
gswKczMRUsiLw8gq4jEdcrJKHhUvfpUmnxEDAoLdriv+aqW0O/EyUDbsb/y5kF0bFCYi5eUunNBB
Bgsf9iCxvKwt9NPGn2+hGUGHJBhHG+ogjkSS/wDAtCgbJOU4xNSgoaEhOECKBbMstSSLKorjsQCJ
yVjkJm3oizgQBgAsFIZAGFkgSEElVXe83sXxt8ZoBoABNjDHTrVwQgDbRAUPfCBIwIhOoFQALCsB
LDy4ACBgAD/iwIEACK1gY+IbyVIguBbCkmXJr/2uROCwQxQiVdtY0+v0bPE13R9tsQaf94rN4cJC
N1okYbmqM0hSAcQWyvVi9ibxSJDoAmXflBSRKgLV+9MqUqIlzLi2VqPABb0DHAg4pESB0aES2SZR
JwjJD4FESeizBAGxJvmiZcRYtknh/wCe73yf99UFCksgLFVQbTLcTT6bZpNvJxJuKa/wOREC0AWY
ASu65+HfSgkqt27Ou/4+kgVBoSDscCrGbbS1CwAOhjvpba31hhxZno43AeZUSC/QugvYF1tky2My
yEQJVFNcMXMGwYTAw/8AtQRChIFYtAwYvrFACKYQS8xCiF+OcIrqSYYuJ4krR0Ez7QNvftq9b9HH
JQjj/lCCISYxbfAErfGt7/QDAka3FCSawlNkHJ/AZCTCACQSBHnk5C9R4JCAdLGid11qEZCCt1RT
fZFm4A4KKFtlmIJBFVyssq6spcVATlWd7ys3dS+SnWRc1V5GBZ5Tc3IAtbwghWncFWMTGCcVbWrd
pavzd7O+ogyQFKisrphyNkLYDFEUOxBhA+mICVgSrvPIBKmedK4hLRqiWRekTMAkEaB/63DWNdtf
H/cvcubl9Y/u3r9Iy8TBZGWjkXAyIwv0RmCMQR/2g2PFQ2FAi04g22bmukxQESKaJbxeUZks8RRM
wWxiypfSDONXF6zBbWXf/Km/ShAL54MBmXA6IiAHtxhFVHslX67xmS5vD+UamBINdzApTm935+hK
RYZ3azD2/s/vWB6H9f8AaAN+xNPwoZiRZKo6oQ0WYIoChgCnD0JxsAEiSmFabXECmFMtiwSXWg2i
YGG1whEkmRWSCzBhCwFpkJVB4tI8UAA6MbiCVCBgs0Zn/p2v1CJQlgliVwG67f8AcUIOWBWRh0vf
+qEcI+jNS/fzj9jmlc+b33+3/sNmZzc0zb7WpnVfKIEENIa0IhghTiFR8WAhnIV7uEqlmIckIEJA
QK0CJofAiSbEiScsTJKpFmiQXkkYojCXUggSJFDVDNJBFJiacaxYmUgNATpS6D1IJS60nWG6CKKV
zrEwAucnjXqJQwRZ35c9qjo0IAfwgIKbdyHWQM5yBdAzRkVUkhjP+3/jnyohF2JW30Udxsf9RREU
TCWT0ahRTaAxABDSIpjKVJm6toVJiRbXDZoeDIUAoGmQsrhlb5afE+EGRsLRLItNyDRcWIoLIIVQ
WNdKJNw2Nh8zlwqa0Irl3Is1AsgMAES1VliAfim0pRqJhaC4QeOpBIM2INXlikjfJEgDrLJMNrhl
AoWmpjCmbVRJIEyeKCo9aGOkM3kIHWysWwqIVmrbKWAfaCCrt/3YjRqyZaqwOKdPkGKu9K65yIgc
M7c8i9xQqCSZCgd8KcpC5tYhBjURay95AmQ7EsY0khjklj0l9f8AuR6VCTMWZ5/FOX37Hdq+I/o/
7mYnbS21nfV4ncEBYJcoZsPkA9ANKdAUGyogZJJgRLLewiFXesynmGHe2DS15qMLMcjwZD+HtUgj
CYoQcDIAhck0S0K0CZA5rG/mUsxIDeWlgD1miTReNdW+E5gljZXf+Aoo5EvcuRMNpDDkQTH0S1Ui
JSRERSFEURsi1YiYYCBscZuioi0jmwDszuV3BBVSqaV8oABYqFREKsSrcysKM4GawgAH8xVS8Rh9
9XJvei0k4ehHMIufoFcDiJJzP+dmus/HP97NdZ+Of72aAsAzgj+hvQVwOIknM/52a6z8c/3s11n4
5/vZrrPxz/ezQFgGZgjaND/P/kOEpNRKsgzeQgDuBY2LFS7vnux4qXd7+jxUu739Hipd3v6PFS7v
f0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v
6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739
Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+j
xUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4
qQT6+NHx/lEwtCZcKAXAssxPN620LQ5C32399yk/yXw4vz7wWxR3d+xXw3V1DsRg4MffP2cE/AfB
xx8MaUa+jgGI4du3nuelj55rDDYsxOzFsc49YWLJayu++2q2OOa/cutuxXxPxfb2Couhg0GpP+Fd
22/HxxXcdvw8cVth+Q+2P0UeM0duO3sxtX+TvnPjxOld220v/FtqvWzd0Pjg1aI5kx0hseCu592P
Ff5W6cuPE6Vis4x/aqLfBq7Y+OatYMXGpx/p7c1/kiOgfPseM2bbnB7+5XxPhH47eTwPRO3YK+F6
Dj8YKOifDj+4wVwX+XD+x2KJgknT0+UaeHas/eLjw6KkR62aZp1ej0dvEd9ndjYT07eieNrRHut0
Nd/aH/RiNuB2agt/mRqcTX0r9PNuG3Gu5TPIMRodseOf7mM2o1PyY/2xT6XE/wCRxpvR6bGvT/Hz
xTYFrQWC6ZHradoo/p/Z7xn0o6tp0IrzghAKQbo1IR68W/N9/So5DqYAREAuBJY9Mn//xAArEAEA
AgEBBgUFAQEBAAAAAAABABEhMRBBUWFx8IGRobHRIEBQwfEw4WD/2gAIAQEAAT8Qyh8bR7B6yMoW
qIIxq0VFBTarle9YK3bTdCLibrPdDJsAf8ddq1IkefMCBpqdU9j3e+dyj0HB9Jpjbs6vgPL/ALWl
P1X2HYzTX6/p7+1au8P1PcmtbsaC+hNcGayH694ml+L8btPHSvGXwwe3l/j1JUY8uXLoX7Mpjf8A
hbLfH3Z3VsthNJbsnt0nE8m/b6NOkuP+85N/4fufH6oMGDBglGSep9V06dOnQ256/wDVsq8q6/rW
2n3s0eMXUutvl/zOP5B+/wDnNmzZs2bNmzZo+/4V6w4RTSfT239oJvOnse24ncuS/tNePpocc/1N
fHp8/GvN4Yntb/cuJ6zWvAsrxedfKaLzkPfW3TQb0Xv43CaGtdH7uaHei8cs9Z7IfmetXNLPTU83
E+eO1eeWqgtG2/VruVYNOgGsL4g0TYLCsMvQTIv7oYQu+KXZ1ktRGzW3khaEMO8dbIJlLVWb7Dem
oXXB2XvV8nzrXY9rueACpfdcU1sJhFr/ACpA2QaGwiTUhQlY1Q/w6Hl55qFi4lOiBeBq8pMpGYtp
wQjutMyjI4JHjrLJnMiqVC4CNBwInDKN0tDlSPrDIIpTma3XAtWiBQ+xgP2SQqBlPLSmD1v6ASUM
F0S5bd0I2/zwEWegzyeVSDBsi3lfr5M5KWihlDo7c94NGXZGLXQIIlvEBSiQxUbrErJQE4pGFmHE
ZhoB3Ed6qtaigFkLueAfuHBM7Kl8T2jNlXJbl2U6xHWgAEPlGGr4o8NMM+mtiWqpcW2pDnFciZII
pjHJQPCc1fHpz5d5pbVPWn3n8n5S3i+bso4HkT+Y+J/MfE7E/UANDx37AtqAObx+OEo4HlLMunvO
V6vzsE6ebHErXnv+IHfn2lG79++0TQnK9T5gm6uuIE1z1+P7Bbj9EtenfWdLzlt6e/xAHXjKHUuV
fhf6g91PInhePxctvT3+J1nvlU5Xq/MANCvoBdJzP9/fpFCmtcCcr2lt6e/xOlOkd8rnV6f9nV6Q
O9vl3/yAGhXe/j47HN44em/9OIlnHiV/HvfDRH0B7E4I3bit3LnxrOuJxV4vnX/niHfjw8PPnN2B
5KZ8Kr+cWZNW7N6ePt4TIy+b/vjx57+IOmN/jfXhyhNFOi+fzxrfvVUsYMp87vHDwiogl3sYFQz6
OZFerBkQbZsNpQ2enWua7/iVRkoehgYy87rrEEAWVpVw9RkNOqsgojHXCIrEO9KMy1GfUFWo2S8A
DhTLWNgb2qKCyOd502dpNaC1Wxc3BPPvx1qQad6ynkmaA2WFyDojpShnBVfsGcStdbXwpeqLUac7
lgG4YAMH8H3UsssaOECPydxeh3dq6CvohUmVilKAY1cU+wAgc9pgATk6Rk9cAaTgHgy8wG1oHDly
hKMVer9oxcKst++YCAOZAmToTiaNOYq4GZG4axg1mSCiwgUJVFH0ls3vLVhDYBuHtoGj+OlgGHiI
WoR7vZTxdA/vheqBmgghxWZLUOCITJUEmJawwHvpCI5AXKRW2VzLJSBOqyrolCjEAiMOWBNcz0Vk
AzAlNc0e+HVym7m9+zqeueHH/kU1p60+8W8XzdtvF83ZRwPIlHA8jYC6TmfSANL8YJ5HF7/5zleL
ADBsBfnhNPoG3V17uBNcu0brjrr5fyB4W+fpKdKb4Vss3Qe9DvvfOr0/7ADTaC6E5XqTkPlNxT3z
0nSl+JA78+ko3fv32U8HyYJ5dSW3P6+Z1ekpvf18yvF9PiV4vp8SvPvwnK9X5leHvOV6vzKa0141
AdFO3L2n9x8wDQB0x7QU0U6Ke0DvTvLvrOuIvF5vy/vfzoLWHRThw66Q9Cmdz09cvZErrdlz+ljz
78N3qG//AJ3y2SVPsTBbgeWFsQ1gSr8pAixGAMbqud691x9sM38Y0MPWXTTfKQXEVtuBVYy3pg1n
Ml2zutZwOdOXcQN1/LqNSCTuPRcFMTtaEVWk8bj9h4jUGmA9Dm/e4Onq5/LHl+42QY3vx4czR39J
QVEpaGLpAGrIo3iDpUxrQCIJzCCHiz+dUlIViREIGtQh0gOBw3rAaBMcqrUPGMqkqAQoaK+gsPpk
NMQrJSCqxscjFhuWAEQOI0zCbhU7xiojpBBTA0XdM7sFUaGpwNx7nuauLFhWBSkVguJgzGuZRBRA
IdSKl3hzvoECmtJJzUVXPJyirGdID1ENF6tYMZnicrW5t9pgYg7KEO7rxlTNjUYuVQQQXZZYrOQe
guA+nlbMtRtwJMjUwxFvQ0F4nccOMLAO1Ad9Vy76rIQEyYoJ3ou3ON67CINkmdDkDcPBSMqtqO9S
q+P+jdzmNS6jp06rLTerIcP6fE+uHBtrV68Le9UivQYDeJ2cHvtpEgZ07f8AdAdOrl+qLFixas3q
+B7+MA08mf8APn/Ln/Ln/Pn/AD5/y5l+auRef58eb+H6mA6Rf8qf8qf8qZv38BsTfyZfzY/zY/w4
/wAPYgf4cf4f0Ju4ONEPSvtJpC6B7QBo92Ch6vEDryHsKm9k8fYx3Yd3pN0i7yPwnW13ZXp4uGL8
8kt3ys8ilQtpi7uuU1A9dW4Z5/W+U1ab8j5d7w84rvOZbua3xL53AA4IuItMXJQlIDjsPj+ndk17
w63w0eEc3Pf0+26BOt19LdmPQeJQvTR4f8hvvDgCxebu17QP1RoZKBP4r+2c4m8b7oA5h1XYIERQ
yi0hDeLXS1umUM2HtE44nD8s77FJVysFMJ2XksukVXYJcVg/kKJp5tZFpXjhrJk39yAElzxQgRAE
V3wsLxE7aCgSIVWO7b86cozUxIdq4M5Z+Da5rmNDJ258yXtMMiCgNGjYQqEF8KE3Sq0w+I2YH/CU
9xXWhrqjCpdvElXi1FWGzJ1sqgKzDTzV4Nq8tMRPzEOfdETPwgECjo8KtSfBgLPyuAGyRWbvgV0Q
UoglOWWonPcBtJOJo3pVzT/HpJ6N+nU2bN9mLmjOWFuM3T+U4cOHDhw4cOHDhw4cOHDhw4cOHDhw
4cOHDhw4cOHDhw4cOHDhw4cOHCdO4cC5d9Yie8Xat9AnTp12sdbqs1mqwWap/iGXDhw4cOHAoxsQ
XipAAiKCCZIwEF7SwZ4W0vNOaaptJU4STPQEQssOoLdJ66XJGERyALy10lSObwZK30fUSRr8xhgI
UDq5CWLJe9aybod1cknLhIjIk5eGtZCngscp7B8B0w1CpCzSt5BO345SuMcUIIk4hVbMFBauGClL
qqoWFiFH4yBsPP0VZqv+6O23abc6Je9UcmwyM29J60zvbzFCaqz/AK5MitMfSwbFyQtjXKb9/Xh8
7tgq15tmOgDI23svbFgHiZIYt6kOA4IimXu/Gps/65s/65s/65s/65s/65s/65s/65s/65s/65WG
LXKDo6NvbT/w4ilNAFs5jSD7na7SlgihwVLQfpRinalF9qF9aSLWFYBCFOJadZZutOFgBL3v9UsB
DUqpvHozFUOpQIBYy/GnRppMAIZtj6HSrd3H98bgKkYIN0KKTrXRKezHwy+rMXkangMgvICVpS5P
INw1nKP0HPMSRoFdOH6lzoW2w5HjEdXQFFZhWOBQFDIv2a1oOK4ungxQTOPE5x1lOvQnjCVUPigq
jBWq0kmxvJ5iSYDQXf8ABHUjQQu9yJKzYUAhRSEgvFYMAS3YQ688rUBeDPhMLUSGwIkYGg5atk7I
oMMokOPi4xZdKlcYaVanggjgXGCoVqISgJy4tWgBioLrK3LK4c2RB1I+hd+/f5B8CzjJXXFpbgtQ
/wDDDx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx
48ePHjx48lYuN9nmV4onTKKsIALT043A7zg1TkFh1HAV9yc82ydbvEUYjzFIHIagCVXuZcosoa/K
OGVFq4GizKGiuW0Jbwo7SkIfc09z/rqBgb1o+exBW/kxGnGftMnlwKTWsxWon4sF+PUE8skLhRBS
Fhs5A0YSYLeKitmoxWZIJKxdTwZhlBYGRQxOvDLqVz0mK8kSovOEgeCHm0X9HdqHDDiQgx7wPYej
zRE9ustCAZwGwAZKqpfTY56bP6LSnIr+ITPY0dBQtqPJ+kBoFBQA8/L5YFhacEkNekfItccvrL36
uAqYfTRwscr1XS4OtR1dJ95VwkAZmW+jRFXHbpG0YouG+rkWGJjBqvC0E7X/ADO1/wAztf8AMvuF
4lU6NTl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8T
l+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl
+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8TmpzU5qc
1OanNTmpzU5qc1OanNTmpzU5qc1OanNTmpzU5qc1OanNTmpzUNBwKbbpOt299L0zC1AMTzSTjPKk
oZh+bN9XSCK1LlFMXQdqlZXcPrbOxPNfmEsUNG1OEasVvw2j7Z/qxMUM0B5cheCy0IO/FdESaeUe
AoxSDobagczEdxB9WBlq27G72aMXXNgKUpwKs3qOQHCBN1sIwMAKjUlHoN/KlHNQML5SpFac60Aw
0bFVFi7iift2UKU76nZjlWxdAZGFJEC2r1SWs9TO9gEUJWFTOKoUsALHR7FptqeaALBHpfIZ1soy
g8bBFZPYCS4xnctk6YCDrONUZSl1zCDBALpJVbZLUEeKreBj1swpiQKthRYLIu/UcJJfzU7K28ar
o7H4oATsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdl
TsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqcxBzEHMQcxBzEHMQcxBzEHMQcxBz
EHMQcxBzEHMQcxBzEHMQcxBzEHMQcxBzEHMQcxBzEFLAoSjmZXrvzDJ6/Nwmd/O4mUUBS2GbC7Mp
S8k/G5BgcULG07l4YmrFnZOxU9A82uhTY5CjZ7aWUdf0EiNVklUeB3gGXYQjacWPoqzvUiJVPru4
CaQgdMUJou0gIU067cq9MQSJBbLlXpVKGD6vBKaVQBUMgIJFmpHM1NB8X89+NUgW0NpQAph4iBeQ
KACNCIVtJhgmCgZR84AinODFHT8Qe8E8Jus3AagZHBwKbwvLwWisdYxrwh4dPWZLeTLQFKpL/URI
E2dwHhc4JTBIaqkAQvvJ8OVwuEymGcF7AtDvRAQlFSuDAB4gvW6tUZj6CXEqnAUc/wD4tXbt27du
3bt27du3bt27du3bt27du3bt27du3bt27du3bt27du3bt27du5s2bNmzZs2bNmzZs2bNmzZs2bNm
zZswXlVxneBKa31oxcxsqbv25EAURY28voiSTCBQ8/cVm2hRUNcAkxHHIAufx6DXHIOUIjNVgOFY
jADQqpFoHANT8u8bv05wXyeM+C8vWNoICwAg1ku8eltwJVeDqFqUFiKSEwH59+Io7ehInEnugEHg
H+G/fv379+8QZaeQKxzNmEvKQfoNBzJwazBXV43IEsPi6vjDg27qoa3v2HZ71OChCzlSSVQ88/uQ
s0iG0kKs8cwFUWCNEamt2YKP3QIdqY4D+qKZFkMQFIWsrbCa21sAskYZhDu1R1KmpwhFOOTOdaUm
/ViKCN27du3F0J14Tojv1r8HIkSJEiRIkSJEiRIkSJEiRIkSJEiRIkSJEiRIkSOwZODrX7mL/VC2
Zuwa8j/fuCClSpUqVKlSpUqVKlSpUqVKlSpUqULYwIklxj5axAFESugQUNIi3DbVGWP6wWn8K7Nb
nLY4IGsc8G3hGSqXxX3Y5ex5fYlCug1xjsVFIollGNHZOINBjeJuYHqI2W0FqNsT+iCiU9xL4wPj
lm/0yEcPSZqHYrIo6ggnhfkyprgZJMMerxWCbOv5P7l41ZqeRz2c7jRuUAgWolsNnrjN0pAqD46M
ocS0KM4clB1zdKBUYngIsZjtvFCAsdlf4PQFJgPAZhcZAdxqIVgJtkMdUsLymQHhNdWWZIZapyFh
aOlcxyIYNs2KabLpyMijKEKbhL8qVAYhGDMYEG3QaOCIxe9mrxjsJM2VbJ6KOkH31kW0soNZ37gx
WjaJhoB2EBWTE0qMvYrzPnhJWPOYhNSR1I80WORtiQ9faEbXuVEGxL/DQgAVFFdqPK4YQbTjGpxj
U4xqcY1OMYBpfinuv4Xl2ADFrf6jTaZuDmDa+XFvMIh2DXTY0mVauiergUlxjYdZ8cfAYvpzJru9
8jTS6UMyh/a+y+y5OID58cQWqsjlFipFQAgk0MdWIqK7BUozrb2FZGpvKUgC+dJoNMGiKK+QYxW9
5LhAqyXr7mzMT2fzYwRARyY84FL17CwhxyVJ2ysXC10BSWlpbnA8JA8875q0IvnmICsA73/sMjRK
HKXdptjMnPGhXXiYPpWG6GnvauBX94pWOyWQB4MDGw7GwvNjoxZKXeVjJdFgfobLk1BuXyNo15nh
uG+yJqfc23MkNccxFkTkyohqPz9jrvUCLNCOCfE9X1s9h4+coaZ3GymLZLfFNs8F00PU4vHlwGAK
UciLAaBQREb00ju2TsO+Fqp1UNVpbQX4krPBXF9EZc8nXFQAC6FMYA+hNMgg2BofaE3AtmmSwLL8
E33JVuww/wAmkmBgpZRKJYKYAiJXyFmPZVoMRDTV3foEIjRxlWtCVXiqTOHpWAxw9M11id9dd5pu
5Z/uzPRXLX3/AA3LrEBQt2W7yi0RpfcxE23DmldYR/QRnNTmbC17+KuQl6QiAXcrHKl2UvCF9pFW
DgnK/wCzCalAc0OvfvvGbNmzZs2bNmzZs2bNmzZkSyGVkK07KM5cmZnsCdwlooI02I6ZY6hat8rX
SAuOFpOdM+WuQyiZCMsVhwzHR+7eMSy5aPlY1eTlcWLhoI5Yh2ipOWOE1WNNtz1ZM4xThI/c9o60
o+6L+NqvS+KoLFOUztmfSQak0w29aSakTGSzhtC+gIypDSL89X+R40YihLMJPLo3C9B0BmSoH0yO
D4VzueaXyqPxZ/oiBIakuqHNegB4YziEKCuE2u3iM0JLPfQFI6YOWCJH9qZiHzq42BE+2p4bhEAy
PQFRpVImOmJRaR9wJ4FiEqLKLoyZxnl594eu6V/Rr2xgRMjyWjI+RTTtyVKxknQXXQloOB0OTcrP
K2TTb9LeVTW5z43Uhbx3Ag0lUTKAsHVnqSHUGLWizrmLMXGvjYplBW8wv/BV5dVohn7aATRz7ccO
HDhw4cOHDhw4cOHDhw4cOHDh1wQUNOSjCLVEzWF90qyVpv2LIHgNJo3y9iwV3hjEos7CriUeQoUa
upNTjw10Q1lQEFdEj2FhUuBK/wBRqtqoFuXRbgDBQRCKXIBQwLRHbSaAoATWgC5RLGR0t4sk+sSX
N3r3SM7Z25vpmxZiX2FIx/dutSjDjQu+dRWKFd/KODBZslRpU9NoKOKVIRrMmxWLlyYI84KB/o0x
Akg6y5UX49J9kHyEwVw9+siEmOnHxB2YyvviBXl9PJMsCKLGLwMrlpKmPIGpBtKYA4U4MqU7CV6D
UGrAEGVm5ivSgyFbheJLegAmjeeoJPASxwewWik0odHXRNOhEPsAcJC91D5Ei1oiTnXRC2qLHw1k
xXAHBMEjhlmC8JNkH0jkxOmBnD5+B+vy1JbKmaoHXFDumhOjRjOjYusAgGmtmdCEsveJlBHZfVTZ
9bk1qPdI88VNbKLmvT6fHxNBuSOQc/tdlB7tIj9ZpbMvuzyKsBS6foCoxikr4S217Y4pA9VlvZTy
5lUzotsYDashps5BLn/NRkh1NuwB2eDYuy1hS2Tu3O7c7tzu3O7c7tzu3O7c7txbYHr2aEojL4/u
DI7AY/3TxeEsKLyHBvR133y3xsALYKL0r4p4/tZBY0q6CaDRBRsRhGAUVyqwbCGoCwEFEgwE4BOR
ES1TUAAiAQ/HHCsc2pEiVsQaq0rCypcsksIeMkgX4hZopLqVZfb/AKfvTLZq9rTv1uWg0xVoV5uZ
genFZAdpVBMJ9eTFNwalCFf8EZavSW5cSFhuUGVgoY/im3zFWjlRJ3qNShbEZDp8EGx07Cq0QDKK
ScNTd9ORFQ/4X+6KSwhLJtzaAtCX+UiBJv32K7FUrLRqu1Y0qb3pUA7CmeAU9X+VbtI5bjd92/VN
saz5H0AQDnLgHIQ4gIASYa7O+fEfRNTzVbbCjNlToGarhZq2NhOkifm+JG0ORGq6i5ALr7txJIX7
jjQxkbhYV53QeQhCQxESiaklZdFWijnCwQQgKSm3cBWDDA/B2jmEQeYxKnhIBq10iZzpjDQGCVAJ
k4ivpCQgYAkV0ZPhW8iY6srBCiJib7ZpLWSRhcsk+9t6W4LoS6ECF3cHJvoDxuoryqtZkKQtDYjS
gm/OPktKItOsM4UjtYMmNsxqGeMnTpgjY3vMLDcGfwZNuCZuC2qyIG5g5ny+E5ny+E4LvdgM9ax1
nd/U7v6nd/U7v6nd/U7v6nd/U7v6iUKzLrm68v3W+KEWb4JLIFDE2DQWVJnvoXyPXdXnsQasumzq
b5eOKfLoKnatQBJcKYb7y/4AHC14NbyUyvpLED6AY61yXK1VoNnB9JlkDmW2VXZUIEcSEzr6uKHo
KW/GJAJTT9kpL9Krb4BvYiF1jtz27o8D8DoMvlaWEyk4jsfEcf5HhQHTGTVQGHYCYPn+Vwe4JAwU
sydnGHUYxp+3+TnWGgGIEkdSQz3Vgk/p/A6asPBq9+cEk5P2ZAKZU5QrFjDDCoKHVpHRxXWQCzAE
keEwlCOzwEAwwY/hQcAz73XlR6YFlSp7CgWdim4zdNxRdFllAP8Ab6P52TCjQBX2bwUreaWrPGt6
5srPJkou99VfLX9fhRlYxiaKVt8L3CsWHX4UVBiyQtxa0XbiKJLnLdNf1PmobYiXQlwkClcjIQht
RKDYxGpqiKyKsjhwgPTONT1rpRwJXCRWWdg4aFhitMswKrqepUUAIMjKVHU4hbrogLIeKY3rM4o5
JuyDLllSdXSZyzSajeWmjj07LHOe3dPPR89Hz0fPR89Hz0fPR89HUhRVQXLcjVqmjTzl4FYIBVCW
qipbhcyrt+ZiqgUzQFVDA3hIG5Rv6hl4ZUXZm/H4EYbf1OQNgM3LRCfg6ZEFnBdbbynky3wVtnLl
OihT96PYFAoAVEAAtVcAGVcBAwjks7lKOZa555NTLN/uEq2TECTwIFLVdoRG/EyaIrEDBZ40wURr
cEapyxSBkbwG6tFmoJsQbwBNirHWZRchDQyoLkNVF6GAA01Mg1qwYoC0EV2VasWpz7nxiNkyyvyz
HF0Kbrw39OQhhuxoSD6UYKQj4O0AL3pqDJ0DWg0ydSqYqEUOYTqiOr0Rz0xaAdgqH8OM2Cw5PtA7
OmIkSOZwoiQkdxXqvsIopWXPbbloyuWHqBVE36ulGWaoK5NdRA6zLB8bLxT6wGgIxZ9XNOxvnrZk
IIO/p85ttU4ImVNYC93+hCE9Nke2xgGgWK3sLwUpm033VxkbGTxNPDjdR0QKoBaCCQGhBBwdC40I
0QONG+XQo5bTsxMq668nIAptmqwSsMKa8WO/0iMXRB6a6MqzlnZJxksmod4W/QCvVXrj6Mphj7Zn
pKhXgw5IMeOdUv8AjOnGaZ1uq58vjuvIvs0TDKDNdqKcJGee2y+ry7jVr1/pNsjb1i/1BXmAUcAo
IV3rn273enurcTgEDJAkRhFlbU00tI5Ch7W9AMWToQYJhh19ewIOYyTBbziJK3OJ/TQQe/de23CH
G68WUVzkHIqGgTE8fptdyOJTuE+q2sxYGj5twvSi4vj0epbelW3Zfyhr7GdKH8qWrKOfXONgSdxm
To2skWiVazJSR/CT6ZnCArNBa6nPFr65yw2tYVRxRTAxqEMzdPvaqZ+0l2XttsLgernUEi2ZmFqZ
JxObS0BrUYYgb5McteCio+Q5xQs9JA+Zj4Cc5T0bB2U8z98nkok6zaPlUERrRDe110hnAP8AnJCm
rxhpgRwCU1KmAgKCEyHUS3lSq1ljqXAQVDygXWdeM9Q2qaUbI62djIgsyiwExBoo34q2aqbBVsUM
HdDj1ewty1qvwUtOyjugDADuOOTaQqhjoRNRbCA+zqiBI5KfW8R+SzJIUoW1Q8zFS20QgpsCv/vD
tOIi7V/tg1OUVr3OsmBM8sr8BG8XcbtEdWNF8IwgYGKjwn2vUUthFm6lGwtkz4J07z4eh8RsUsZc
VnREgWXDexXdwCovDzncXxqTNWCiwSUysOjvWp8LpCM2KTdWDppAMqIaYc4IANg4a1W2ZT855YhJ
IAIclAyadkkoN5Jy0TuCg3GNBYlMZFw74712gIvoWcxUZ3FrjwxQTLixeOG/hnKEI/kK/wDSwHtC
/wAirREwDyPW4e1aojbI3TsXRSC1Sud6ZxDqs9NheJFQFo5fYVKRNBO+t4HU1s/iqFqTzfs17jGQ
6oE8PWkN/wCAiJpDauEoin3oXD/0w7P12aWJaz2+xFb+oIQkJ3CZAECVZm2PeXrJZYngTBNLoUpV
McIbZCadBEmmAgyn0AH1nv2UiFlJ+D3kdhx9YTy8YK+GjXfRZnzW/ZvU8hRNwsSZgwyxGIgRaKmn
taiYRbnaB2mvWfCUTfLQq6998e11ecWD5iQilsEEXkH6gc+Rdx8oVBJOyvC/y5lwPC7Fx1imsI3Q
KUBjVlfmp5YnASGRmOi4BbJwMVS2Actws0gwKgY8Ro/wbXCClVJeAk5yC+XnCps2EmJzti+/gEBP
gnO9ZA6dW2ifqAPoZzbI/ph6CDxMimYUegz0E9pO/wCcw2E7U4fpULd/u0lmJ8GeFIfyzL+Kf5TD
ODURn/RgtyLTYr+ldXRsdTZUEsfUop95L0ddoDapimsjkpbd1YyqXtTeZZnBP+WdZAkv+bP+jnzo
skKVhOEP8GySkjJCUWG2H0WcXDZG9GPGOqbAyq2Hy6wzl4I93tUEW/yYHcEFINT+cHtSXUBRuVQS
QEO5MztoV3ACd7qw5lN6Zo3m0CCHgbxYDK4GhGZduzCjns/DqdEZzYDTfU/IA+vQiIGe9rN7wrvK
xkuiwMbLhg1zYFETShPzTeWIl9FpN6ITUSbFNkusQmiZPBkcvXKFmS7EcwMFBQ26YxS1uM67dU9V
vmjpNCdkV2LQYKqhoReNC5iYQG2aTgtOXBRYPkFArU6DRD9uXq4DdkdaGdr6fgVc4iWdwpkVs7nc
c+n7fFcY4OI0mVMjurIEZrYl8U8zG2gfKFz1+Xu66WbZbZxlvgSrgRjm6vEpsVhIZ5dVXq0Wcq0S
DDMh4BTC/mnfSBidbFxA3FaaYYj199wQlMvbtRioAuKzlaqeRw8TUt8moVrYCUYdAG9f/QNwuWaX
yqPxZ9CJESiug26GlioScKmPhJgOxq2xcDoWaVbwTc8FHiKOGEh3TTzLpjokkLWBFoL3aEUrUiGx
edwYw4wQoQlZothEiUCFmT0VR99sKZ9nclLbe4+8py5O4tTR7keg2bmrqvU+Qd56ZtarSrkHMQMX
fomwAqp9dVWWYXj2raJ8gUBkc1Gf8hGiAQzJJw4rawqBkTDM6hcx/bhOA5YD8nfM4r9JIqAIgYOG
maFIJm5z0X542vhy8Z71ptL5uPUIwDcn6GFeUzpz97VVdKd2xH8m+6ZOW5rliq+eJ5hC8ioNAoUf
QgYdy9OFeqzxmq8hihr/AGCAZDZ0n9JAE7NIw0d6xWfVbeb0gFTZ3oAdm7BVEbdqkloz9VLdxPDt
2EGX7VlJA8zQEugI6K0SyYH5PNzTaqMaKSxFDtEIWGyuH4yxshu7EWFLVDJ0XgBra4ySwRDZcvYj
KJfqT83cwvFOuovqCQYwvGjyERjUuLjSeiWi23I2LN0ZWffintwDJVmGpgEZWuLzF+Zm8ZUWSc2L
swR5wUD62kJajoIRCAg+3lIotWUKykRgba1pAdiS+0BX8eotg2OZ9q3bePE33hvrOGjKNlWEmm7g
ZFrw7A6B4CM9LeuAmMs0nhCbz+VRfefSAoD1CcATKqDHYoxZ1DT1v0EpRoVSlF1HAYBmvcQmuive
b0aJmHT1yxMpcPIjc43QOuRnMYppE/JKpTX5Yw0o4gBU72aRyZEf6OTJgFD4x7+agGF9jjWqXBkf
piSwMgUsrozysf1Lhnn8li8sRGBgASjFI4JnQE3SicZg3IdcyF7wNvoT8E4XzpLA0ZSRas5Joh0M
1gFqjMGHRBB3lDC/imcUR6AUZUNrpled4qBSL3Ik8BS93W3oRgKUv0SyMm/LE+MUEGSCmfMVOY0f
Lw71EErFwr1UrCrWTfIUEKHgEArnQsEbQiWvRuazf4zc+m07X4AvAJA62yAdXRIFWCEjTe59IZDo
fTvgXrSlhihrOXd22giaN3tg8jHvtC6m0zQDpb02qqhwIkz3Uek7u3BBBcHU66xHMAqLuadJubLA
zFWwp84VTuHLICpjny6t9j21BNeEqQaQpwNzQlq0zDGF/NJFoKiYbt2bFUa8Z7BB7yffpMhv66GS
fL9GqA7SyW3CgZ9iNsk99ZMgXV0/aaWgULuMsfssGzUj4n5nLaDyOJ1wN3EZL3NFXnRWtUdVi2xP
1YTGeTJcHpUXY7jpT9KCxA1WJCCBlvCOhaalgwGgc5QlVVwMtLaVs6gotEv0gSxLxxn3gdyvn2NA
3dMyS2yPuqiJTjyV3G/Ho7JbL/oIyNw01k5yxG8wBKACjPEMhdC4fRUoptlld8xixGyGqsUFtltM
8Npa3gRhyLwY1LtXEobwtWg1YzobnokQA0Sa9nUdbTJv0M4zATQ5LocVBH4mWYL0MOV7OPYuC4pD
LRQiLNr28hptLvQNOzXAcq2Pwy8/WX/NBBi5h15dnnyboEjjea9DkTeodrt/zftXX+yaDoe3+ObU
tMIlwdl0GJNoND7WP5UEklcIL8ToZgI9zHSLgzTCNwP5Yfsg8SO9txH4uizCzyQDWxxhta12hOEm
GdDZPTxD8ExorldjLHCMiHjcIZURqX5JU15b2QKd/wAs6SM2m1VoDqOPk8pHkUo2GrdjjZyTdJB3
iJah6bpMqzzccwS42DYwodkhtt3vx0h4vfedny7TdG8cf2XKYWoPwvGKOaBnjcazYO/TgEMgBttn
CJ5McZVvGwBKaXp/mEP0WyzMmJ5s8LK0VmdQQv3QaDoMRpOqQB8SlIbImk+t2eOdvx0ucsRG0HlE
NAmppWRT2IZB4htdOYVaWqwwEsi1eY+LbALYqgysIQp4ip6RvPfE5M7QaLkW1ISKZrRZ/wDKu9Kg
DXZvOuXednwD7EMkYcaB1qCmhION2yNqlH6Ot8sEhGqhthLSZYrnWtsjGqICLpK1mq1kiV9+WYLH
XHidDKs6bGhECWH1kmKJSKli4UglLoppNcGzSCvzFY4pBuJkKxX141KhET/HNqGnNg4JYZ/SRIMv
Gjw1OukdHowqc5DqntNnJkI529XTPUGVUQNgZ69dijYbYLsCG+gt6Q3YQeITJ9CUh3x8cBMd512Y
VC8ZbVoc2UG6JwrEqVH9XjkSt6f9L5BdOWrq3sCqLYktB5ddqwCy4kdrdQUHEtrop0Df6VLVj81S
G3IW4HzWVImFM/3ilbPLERtL4udkb0HQ9voVjSltIJgrUAEKaDSiVCMg2oYyArBvR+AVmi6k7Q49
kJrH2dMITYuRgIbuw6G6YtKZGN+UxVGM5NUaQPUVzCVzVK+oc8NIpe9gZHPEvTo/iDwM1SRFxsrD
LODf8yARib+C7CEznPRrdd9mppB92K629dg/Zxminiv8lPglgAQ6ula8D/jPNqI1IAJzmNpF5l58
2BwEEh/AOAC3x1xb+F8AT9PgHA3NT54gBHuvBzJhbwZB1jKUr675W2SFUc7v2JayAwRbXuOU0kFZ
koFUz8JH7MLf7jKR8bjucSrjJXKYiQXjto9IKaDhehqp2yVzm6FsklNSzACxCAN1GVumRzEXbEoR
yHq9DmjPRqF1bMekQUk02YSbDMYckGPHOqX/ACrW8ox+TD3B/L+WIjYDyyOkYWAMIO7gs02DwYti
fhn1IlC0Q9VJkQABKmU2zdEnIRsIipTWBS+yFtMZILcjn2SiKNroV/mahcoJiMohFneW+wa/vxNY
AnWMCyGZD+TNqEIYwotUQVGVVNm+2nTy7Wo4eWCwbhJGguLJr1RgQQMCwqMZjlfarQ9vsCPIoxhR
xvulhhUuAr6PI7KWWT2Z/GNF6/RGtD2UPl42ixPk++wn6TBusDjWwxm0vGVVUUKILt/uB83PttHV
lSaysX1BeSpcGCO5VyAqAIYWoCq8xhwGou2lClc3XTm1Ko+6NTWWOJEfFHj66MW8K1xlFVXaCxUY
qAozIgNUAaGgZFOjic6uWMVYYn1bjY2tDFgXo4pU82NqYTIrDmBRIEWAKEkSm3kUSmqmN5BEcoxC
UJnszCKEZslBMAixJhqnfET11AXXVVEFdVo4/NpLPcsRNE2z8Stkc2iWE3jhMF2HzQfEwGrWJi8K
IcIan7w2byuGHPQ+i7r5UL7Us63KkvrQ7rpsjdUYJaU4FKKky0LSnsd60tFsg11l7PCnEQRHAj+x
X/mIYxx1kiBLfbqaW6UBlHFTy3FdrsEUUjIhQNnw299aNRKj8rW9nlN1DrUOg8aUXBjnWR2/Plsn
JM9BGmTHTKpzOFKBKqxef9/IJ7FUjM9LfKG2GcQovn9GhluQBHyZ5ZhBC/rllKfvozIU/POqxynX
PYWBBSfUh1g3iBHnc5bKA1KdANUS7QaK6iQBw+I7FdY8y8aVagWv56W4t7bnY07JGzRBFmliWs9v
sRW/qCEJCdwmQHLESyi9ai+8PKYAUShYjN9Qxo1TZHCt0gwGK4Dmz2XHaf5DQxMo6vCcLYtOJ3hl
gh+JItm1yBWLg0h+AJMIqGX9eutkngLoQfWw07ads0SDso31a+SPGjHrlE/rWQcKWB6Adm0/E+UJ
OLTduCchSSb1Hj+xkCTP+TgxWm9xiuRTU4gTmsewJ7UntInXDIJENfhR9lRg5DYcnJJFu0tgdJP2
QHH48wi9CksBUCVRZTdPjYScIwyUpKMgKIGljEJ1I+cQ7BOUk9YH0UsrRknYNRgJPj6zDa003v34
YYjobShRwCnLvWtnDWmeJc/EF9gOCAUHwlpqDcvkbRkccAYxfl0JteoZG3L7vhRNm/p/MdEz1thl
NZHJS27qxlUvam8yzOCfy2dfLFLodAFYFBwK0nqHtsAoWtTNJvENVolhYEUgQ0UVLQUDWEQAAUBz
DVAlwoQNSspko5bsc6iPN3rvizYmeqJ3ESz6k7VwbYl8vu19K9Vd4lhTmn/QEt+2M/o4OB5OFHZ+
efQmeyvaq8nUMsGwGhwNq0/FlGZ9Mjmoz/kI0QCW4TSXgd9q8usNRrOPlAeztG+KR+J/880yS3NI
xLJZPkqVKvPSF5xHFjsgGwNHi5VH+AZAkpwt1zCogEg+Vxscc3c4SyhlN6YWvgbAzb92sWmnksBY
CSaihMnFj0peySNUscwh0QScmCzYY7Z828fi2h1AWkZ6v18g6ZczNcfM1NhoxyP1SGcqwLaU+CKd
Z9fHKkyPW/oKucTfVqIv++3I/dS+6Oq6mOo4CxfLuGMpkLY6o9fl7uulm2WnPF6CyVDwkwpg5gP3
OoEi9HvCA5O9HniN/wCjDCkCzAy2AIILDv6Q8jfiSuF3FzPyiX8RIa+WKoRqmwa68AVlcDEfUPbY
IjoBW3V0gtBctgtlXFrJTgFAqESgAkRQ6igTBSqtWC6qAlDCBZQfpALU6w7qmDKGqgIVxAdbrHHE
16E0+n+FBlKmkCbsIjhEd1uCqAI0YhvRSCcWh04fs14nUsShdaanySLVzlypqg/P4q9n8oQgdG6i
FwpUYyJfTqJsj+VMyQEeNEFFoZ3B5i9n5kFoxyH9J8KVHMYV0vn/AIq1/vq6w3TrEQJXYiv0LLsg
+AmQIoyVJcdVhMWVWAY5m3BDsA2Kb1OIr9zGfAb3xS1wBAPT+0UyxKiV7UyVlJFZX7g9ZlMIV1vp
ziUz2jqoLhkAh2OEmE4aoCfjGwCydt4XztuXbMSqTESCVJen/bR/MvXVqLYKK6JYUpda5/laZJpt
6KRS3HyVIEBOqEqyzdaygtfw+F5qupWIrkonb1siqM31OCE01BHGuJhsI1uwkh+//s5MsWQLEpmG
jw0YPun1PyqaEjliLgKQOCBufaINMiveFE3ONwsBEDzL0EIdMQrUUF/AEqp7dLIAFhQNROPLioWG
IguWSvaRSxqiYJ4bI1Dq16rZRVdEGaCWRSOwfbZPUm/gl2TAMEdLjuALyiQQkINOmLFWkdk+AiXX
j5rPRTjkV6Fh12AC9QyY0jNWnNuMN1akXIujenDsFmjJSdnDrqCaZRGIi/Tb+q8YvJKJFMj9yqtA
SvDIx/QoYb/H7k4plOACNZ9WRuBcWGrbofgI/wDU8XmjVSXFLpVh5Ukj+a/nL0Q8T0fQQJN++xXY
qlZaNTKTE+8ILZ1MSFSw1KU2UcUFOnlMJZHV1CUGgAoG2Av0psjm0zJc5X+T+zmNZBfXjG1+Gxpw
6tegdpSqV9STQolxsx9AOlchnfQccZ+cmIBT4UtEFSEUKiVsZ2yAMGx4Oz2ePQoW8q/MT3dAr0ue
ER2BfKFbmUeDCocoQgHyF59B+HYIGIqOngOKOBYswiMnF8IEKpnAls6b1VOR83ARF6rzRcMcFCq/
XZUWssFgQp30ApgHKs9LvcOS+/kuWIF1F61GzrWmGVNyDATaoG0IQVHTBL6BCg7EMhKewVQfroQW
ZXXFXWNCSabHfy97tHyIjJ/D3SFe/IEevWwQ46gZZu6e4yucEpFXSLTBtZD4beLll71c0bGGlC12
RupPYRz1P4ZiGpNM47RcIrpXIgWWL+v7kCmGwaueoS2MRrtYLtHRR2qjWyV2QnDEFQXSnKfXCibp
7eYELd0D9y+n+tLbEsYpOe3G/TpPKdnUGgy5LVcdvACuAyb5X6MIi2iRRXIHoQYxMBj1I/TECSOp
IZ7qwSf0/sf8n2Up0+wfZPkuIDJnn1adqm/JuZ0AlGkc/WppLqKf8IXPUMxjPKE0bqgZOFHZ8G1D
i7yMlW1MEhti2tqcRB9FVt68JWr6Oycss9Ffu3KOQHO+i6ZZ2xoDtBcJO6FzSelv1piTOl053ogP
MbGF2ibce/RRzi9dX5wfwj4YYhOj10JuM2CsVUbKFPMKZ8IMDCTneu7LGImKnuTjvDHhoA7vGJty
YoutAZSJ2lAQ+2SXthAC/kxfi+BR5Ysgcmi5ksLF+ACeIpxzZmAbM2JyfMYDOM8iqu2sL1EBniGV
wRFILcBqgYy5yQAiuMjmzm/1ObcikWxgaaQDIBlamJcNnIF84ylAPNdItpgTvvYmr0uslR1VxZut
PRggStRTDIKc4n2eCBJ4EClqu0IjfidMIE1RCtQcBALQ3YzBcCDIOqi0zPEMyjHyItAGx+Mj2mRb
I+b6qVO5SdjD6AhgnVQFhCtPHijRhNs8LFAfJgahcI5Y9DbMBsJdbpTUaergNbPihTGQ1L5cKC/F
K1dpCIopFpVJEgoC41SCAoaVgAg1FW1bRct8mOhP865Yo2BF69F9bWeodkg6zle8AN5+3IEiMIsr
ammlpHIaWZGi5+yGn9rM0ExAgfnyMnUpEI1GMSakpBRVIBwbbakZR0yWyO8C0Q8wRvD1Ece3ArCx
rE33/wDpKsBCSwwiUAMG4OkUgm3yBCZ3X2dLeMJsivrpXOUZ2TMJtRfcAriZaAFOE7RC5ASoLhWP
T85yxMVC6qC9SEoAU5QAcieQqdFff7sgSOSn1vEfksySMVv7B4tOJerDxxW7AQgD0fInSYhpkjFf
zwiqAvCDFamqJCAswSAtqJmRElV+Ti3qjOM+Pn+EQwEkhs0mMGff0nRwqAIHBhEzEFAkBWpYBcDb
0gWLeU8VJAAV+zlEtFRB0Y1giAxHu1ZpVxaBFF+1orfRgKUZUXUtyuxEDH83yxZi5CschyHEBxGS
eKO81iiFKtyttG84wDHDjf2+Y7leY45WYsybkiKWqrQZU0Ayq/8ANqm6WBfaA7VGwIzf1pdJdYru
UhKSLdTMpy/PMbWEiqyXzFlQraIhh+oS3ATaobts09ugtbHFdcNGYeSv23rNWfI8Jk4vA86Bl++O
Y1eHoNghv72pts+vLG1G4lZcAqpn/wD6KnW0kH0IsE7rD/bNEKvW7+36LJ0GQXS9kcLlFT4wVPuW
NWVLvszY+Uc9BUsdiFYSZfyn/WB9gp758Jy1M67Rlir924mG1hkdhUQ1yRgo4ofN0NWPOxQK7JWQ
ozSbQZVtKl3i1pXlKHKIe7SJMsfEhBsqwrmBwvI/kMUnLWAg/Ol2bvLyxIaU2opfGqEFAFZQBXWe
L1+88y6DMYWHX5GyeYPtkwEzUOop8o0mb2+pKapLD1H8QlygI+q8eOcBNqweoPUSbC8ra+WO4b1G
w/aAYEhCWACMjPN9K0Vi6Pobw6EiIN5lkn27KuEYWEJ5QJ0KQUBT31IHgV/AM7F5k1Fsd2yUpqvV
yFmhukQtjKDKMoi09xGkW/ysAaQtcvqgw2vYNRhYufxK3o7pu87HY71antpwPyWTrZV/CpN0rxG/
A14nto2ocI5ZZWOyIG1Lw5iU51bLyM0I8V+k/Py1LYxEDFjcxsv3XjdfJPh82lQM4NkobhFA/PsC
/wCAiHgcAAAAD8fyxX0DMWrXP7adK+9BeZd7CHiQac0Mv3pyy7WjuYd4JssRrUaVBqu2XKwwOcAL
LQ4BAtW6QogpTQmnkYR/ETssGpLEBwkJWbZsoZoqU48yAZV9d4mTWLsjZBlC/wCSJ7OyfoogfDtf
m6pkFwXQXDSIhAlWWKNghGkAKLrGregHsef53liqMC9AW1qNW0UFteVICgOh96eZciNDWVmpXQlX
5Fa/ayxt7/cio6l+2QMJnJGe90jT39wbOolywwYf0n7CJFMst/b5MArqSj9snJxWbCVfQuvt4pUM
lbSATGSgPlytRswfh5Q8MAs7e6HelQGs7NzoUKaU/vDNJZARp+C5Yk6Z40w95PnQbtHd94+ZeLWD
5OdOKauzjBs8j2aYHi1SkDIGTjvs1j+6UpRJIgC2xpmkIXV4kkrlkW1vrvn3B6VqeCzCFyjfWy6X
AuNPMATsFqEpAOdumYfWBhI5MjoAzYCUKhsXHnR370okEq8PdBvHmmRJ2A/OWvnMwYUi/BPSYgkM
2kltYYtToXPA8tjTcnwGtQhJPnQtNSwYDQOc+2YgASpoAFVdwGV3EwDp+B5YmIl1KFMeFF3d7uAB
jBhGE4IuO5Xi/d+ZaImis32StnhhLiOvROiwjZ7A0zRnCIsxva0RjoB7ufklegqInBe2+YgMslXa
bEO0vCc80dPWUVlPqOMdB5RR2EZbT7xG5dqJlma+h2raa7wwDDP5aBQ+5L2+IfERMtAWz76oneFa
wGbUsn3vqXXXYUhqCcnp7ZHcIaHphdluvItQfoZrEeDyo5hKHj7elhMwvIWKlCxRABRSglsCgiLP
S5Ii724spGyi318n4l7/ANPtrL6+TL6+T8S74+Inv9vSxAtgHIChRVg2Yznr9ObMKiYURa1Cw4BN
gpnVRu+ZaGN/T0v7vzLQ+5On1SWowlrCUHAXD9qdQUIDLWUFMqpe0VPsq27tIQ0k0qQNjbS4G3Fn
LVdnvCh0ZmhRzbrjrmWptvpkFINwhLrCJWhAif00sJdYVZKK7AVdPwXC7i00HI+M84F6etoZgSYo
6EqVGAlaigKgFKUyn+YKTtHLEpIURtSqb7xQcmoun02lKoRAvaZFrpsxVlbVbWhb95+ZaE3FCd6H
NvwJJ4obxARp0HoWdU1juzaCNjoKufBBS3OI3hnNFcSQsGsWw23Ry+Vs0zUyVlqOP4y+ylBZNfEx
b+a9/wBlO3tX7eb/ADqnK2KaLw2z4PbJGLpGzSXFr25LlVRe0YrNfLMxGCjg8H+8j7oRYfHTlB2t
8IliJrYiVx+95YrBMJIDgSKUDRZjVtsxnXBzaWjwF6DAXKsqpkgoOaEC9JhRjgfeHmW+X5pxQ+C3
g9qLu4wNuFWAqSjMSoX4mXtD0UKBYEOl5bbFOQWk68HSHi/DBFiAWart0bZbcsjKuAsd8tWUTMak
oFdw2sipOeSMcpw6iRHkdNZgCoMYZgDQgDSmiyIFGKVVDWV29YdNS09IVfzpU4jVJhRaq1xTZ+6K
TAHCAtDIVrwTCC63RIIfecsQcAX1YlTOK1dES9/0ISQKFqBZO3FiWoC1CFdcbxbjz4SxUXr0X1/v
PMtfP03IRfJ5VsQAzhY1sSvigBslcA0Ro0eNfU5pDC1Xfpr070edD0GeXN8cNAlaTekM8Xiyfkcx
Luk4/mn0AftynUdlnQldX7BawC5g5YSVoY+FBcWbTrCefKyX4QChtDtAXahLMqCnvYyyfjq7Nuc3
dwVjgCYFlHX2d4X3NHb8aBPkQvk6623Gc9UQHFLNPThZBQLJeqAhw4xYPzOM7+0qaBc+lpksLAKN
RoLKOVLKIAHQxAOAoDoGCqNfveWKx0b210HlLHEURESn76KLr/MtsPohNDQTzfeWLAgobQbIe5TK
JCyc0RMAFA5BijTAla00TRDEM/b2OFUgDRgJQ0InPqBQHsBdQYbGaDNK1W/JxqUSZYjalZJontl8
7M23UC0f8vsnSJEriNb6fzbf0jYN8gpyxOngxsIUpiAtGNjzal7fn/8A0lhP12xLeT7elB0Lpk0P
txFWpyqTli6kv5jgCumzjzk7Dm0WfwT/AGgouDrpwa8d/vG1pFMJh3XS7mm+YhCjRgbsqq1vSuek
EQREQRGxHIiYRNH7vliKtZcTvWpvZHLoVw739dqgWoBquA8ZkTkKhzMg4ApKFKJpfBCTeC4p+78y
02dDNAGFv9BxrrdGGiGqY+bhnTUJHCQ0aAwactKeLSvGv0fziOIlNLYUM7JBgpzONiRtrc4DIIkT
3o187sWZQsWroyBymbcT/R6x0dEc+VLeLVh/Rskc7rh8p/BkjWv4oo/+LDlKhxGoMIpExwlX3qiT
vz7Ezj8pI16o45w9sPTTbThuTH2YPW1f3knGBt0mInDj8fI+1wlKLDS8Gsuv/YygNCpaOugoASkh
jbSCmGAvVlt11ripsYYFAFApbbQAXgrZfXyZfXyd/fhvl907Frj5L7R8fQ0f5c9PtMQpDHKkbqmk
xdUlN2403TUNpqo7qWtSLW0o21UalRKrS3QaMVgsgtoMXBiDFAxRjyRMTS8+9/MuRGhrKzUroTj5
9LB6IZgaobhVLj4cPJQ/cTXWyTxct6J1RLT5MCeIF59kL3jPVyqtAhIAhFTOcPO8stknDq8A8T+J
2MqOvomi27fJZ2WcRdISLOSdKzUIVr6o3Pe1gxDwtJQF1QLTEb3Gp7yOrYn0GUNV0Yzd5D9Cgg5a
bf5kJmMYxfLGJnYR/PMZtLvUjH5QadOOJFTGGHp5YjOwSEAwSgWQqUIvqrhm5f3j5l4tYPk504pq
7PHus0g90MYs0mw/VMWBNmlocIE9jnl0sqQhW297II/Un2NBU/r0pEZPHPOxJbgQUqLFq4oGo8MN
Kp1nEvLcmeLL7XC/wg5yQhUH9IG5Bsz3L794zHY6qGUy5/CcLeNGYw5wkgBVCimAsC+5s4nmTXT7
3liZWV9LukNVuQa8yvpQiC6iG6uFLN+H7z8y0RNFZvslbPDCiy8AEr2I4JLhopRZk1lZehZsUQbN
cDzGmIgQvZCjjTBoTDZKOItwKZ/8aXQUeBDy9PrRZ450DnUvhVXYLnN/+z3srYUIFb/58RNgTujd
AoDM35YugaJ/zZlxeFV1wnImkJD5fui8rrVcUrvr9MMAcPveWK4EUSlDmR0thxZsWWPoydlWLR45
oypN975X7+88yxZ2XNSmaA8gZhTBVPpB/rmAgJbTkYfjSS7ZEEZStjB3koJv2U5F9BjLiIJsyJTj
nATTri0g96HYCAmEUM0C10QBDvQgXIRl+KfGpAaYcdh5tU+tSBpBRJBAoaHtmnIya4DVM4hiUkEO
iw2is2SxvrTx/wDdFDn6NAAMw8n2qk5DfQpoC2oQMUfm9ULQpd5F7I/qZS2tdoqhwAoULAwQcfzr
AdiZbUOU2sEAqxSA7QNPMCBtwaDIaiIWnQFQpjhgddK9e9dOZeujXBTde2/lvxLe4Op29SX3lt9V
e8vw7HOKhqleJx9cGvZn7PETZhuM51FBkWQZ9KtKAvBBCjwJ3xIUsxfo/eHmWtXGJHkVDnEOken2
2blqbT4UStCAUANt144qFGx7TPrDqwZw8KR2s3hrNg43iRvz09GY/W9Oe6jk7bpXYLmYkeIqr8OK
9DpdW8d8YHI5Uq0djgDGq5JyIRVOfpo0Nsx+QV+cK0unMtLQxfrP9Zhb8rbbU45jxCZML1ec7T8T
NQq9kdPPL/dt+59QqqBEEGkiBmv3XQgaJ5uxPbDHvuM6e+EZz1y+x9hAejsLfmYy5dtji8olp/aN
3qkKWrtehxMUg10pgpFxcrOgvg4dptguq+NlkudrHnwIg5eA/F+PlEVj9VaErXm6wYAb/eMjeWKw
imWzQxWcAzVA26CVWav3g+ZZzkYVq3Gc5CSMT2CShp0TEsFRYWjKXqNBlcMksj7+CXOmanFpqQQi
KME8Hvh3MZhHCFpRVsvCFGbm2xl4/fmEQtoSTa8DlsBoC2GqejCXF+YPjUX2wZRYtkyz0qE+obpo
aLua0F7qsUZOoJ3NgxfCSJxkwC0AwZqoYLLpYfoU2oBBNl54OZTFGrJR/wCzL7Ir6+T8bLv+J7yn
DsHDvXSWc/J+PovunvvmS+ul6Pd8tZZrnho+1X46S92fJ96r7XliyVYvARfLXcy+vk/EUOPgnsQb
0vxE9wl9ccnt8I5KOjAmWsGoCGRTKV8ftxdV/ZoekFB3rn7rzLCkasnhEiUhU6ZYvD+8QaUVVeKs
D/d4HjFjS07k+5zNDGk5K8mutdnuTFUBqgx/s/bSpRW4BI+O7AYY6DH26rEEHEmZXzIdU7W4+CXY
rhy05PnM65pS+qWE5ZUPcvcpbmpf1IMe2HPWMdSJPMSnR06q/phtlApstsSskCczu6UPm5flfLKr
N0Fw2JSaafWxUHMKlQfhEZBad5YjRgWlqMAJiXG5UD6FfgQaLIIhijWSkTXDAlqYvHb4axWO9/3X
mXQZjCw6/I2TzCzvGSttkEElZlB30vlJSm64jrHKPLMawqeI9iIU202wVYjgUwRSLeH51yqIbYgB
OLCWlKYY2UNAcjI+m8MeCcdLLwwIN9LFPaWE7Moe544ZBJN3y3iNXGosSDvJUpgrlUihaQAlvv5h
HHs8o3QKisqrR8rQwG18PbEXlQn6WX8ERAaO0+dy7UQxpf8AQRkbhprJzlixBEbCw6QyCaMjFaPo
LBJLJ4snq4JwlGOrp9/xvYaePufuvMu9hDxINOaGX7qhcBpM+QxoKm3pZYN40Oygyo89wpsM5cK9
1lQPoLBIoZK4T6xiGfAYmfosOr3NFOQuZHnVtqLDZkgA0ne+1CfU1h0tMhmCn8imHhvXFQSVGUxw
lYUUqH/i35El6bZsNOw+BOKp6pAA3HHxIsi8+w3yCv5ZilbnnliZFby2FWp23EtZRgfSpg4QLHQu
oq8I2u6nEbs4/b7v3fmXIjQ1lZqV0JBWuDpNEZxuqzUGBPoyb5iHMOApegUJE2MJeKNe+yC75myP
9kpxDngcCblC1YW5O2W4eLUkLm2nrBdTXpyPi9aHuIQdFC/cv918NGyvlm35E3P+vAzrN/5qShJP
URDv95KlIVn3WdZ1ITyr4S4R8VEpO2W4dP4vMOGprwn9A+YPomawNeGuvKWcTz2WGrUs4ks4nnLO
J5n23LFlxyuvO9O/OKGqHWZKpfCy4I5GzibCUGbR8O+PB+9zRZrf6Fer975l7brnzIdjBjUK2/hD
HfycYiehG90argselQrlAQVQeqBbJrgYM6EIzZtEI7AZEuKPWc6cjB2nHWaKVJ4ULF3y0FATnwqz
osUSDAp4A2+htyNtMDvsbqwbN7D6IyZUcdv8eIiOOxVmoZ1a0eRL+NVOBiuVHljtHJCJKWF7bmJT
ghNuFfkSAn/CsFcBmLE2Kcpw2VyS4qGMcbz8dsrPhRe3C01ytEKtUh5HwEyk+kZG6sajCRdnFkVi
MhcOEGypyJRYTzTvJrViiDIwQ5kIdw2TPFY0SbdjNeK8QFwpLfQDoR0C1MEt/wAeROWIF2L8bQ/R
5yp9/o6Xf9+78y7iCe0lBFTms7G5HT8d84MQkDp5V/7JuUYzKn8+SRgL038NQc95kbhF7BadwRUz
f0t0yBVtDEyj5S2xXSslq/1Ruzg6+s5ZIhU4n8BzRmbpxijJ5+0lSa+wMMSpSrnq3wCacz9f9iag
MBcx6MCB4uyaochdB1EwHJST+rXGIKWdhBXsv2pDmQBaoLvZ/ofYc92bbxhCvRjSQY4SfttiSBlQ
NoEidkDWqy9uRsVG1uHMCSMyU+iLoC+xLvuUtKMrgx9mHxQtYk4PwbAi95DAEHkkOV2N7Hc4xubb
V0hkZS0JNptqNMgCuaf48fLFRL8AXY67q86UNXf2+ndTQ9H2mg6Ht915ligA8t2OqEdSlSqltrAI
vJihtSmAooySQtmvAYZbTGiljKrWq+TRkFJSA/MvGWhdx1QpmXediJPgwBImfCgL59KY+kESLO1X
cROcjwy2AucOh747XUnHTYO4XFb55FQeLsJ6e5H5ioBUmXCqUKyYXWki5tHvSXo9i69H4Kkvg4EF
coDrObSgjCVAIzx53zSSX7wSf2Ntn1Iy+wfYpJcXyVlh+awtkz6aO89aWZKzG429u5/O/wCZHDdk
Ezo912lGbXaBgu8t8eJnlMvNtvme9hgudHSel9qFBwMOrctUszKA3FGilzbXMDxSfUjW81RT7NGL
6nZuIbrugVRkMynSZUyK6sgBmtiQr8rMicKOmDkbzGD/AFBiaktaoDj+uCXD8LUJNsjk7yZbBDA0
PSAT8tdw65YmxgEFDfNJbet4azqHJxqOh6PtNB0Pb7zzLTIslhBzHCBVqMkw6Lr32XPUYcmr5JY6
c1yHbq6nQB6SDpRwCnbCAZGp9YBBeGhhVPtJB72DI21+cKq79uMseEwHgQjAXO+CkOWjAIMkzcmP
Hmbf2GRbJpYoRJa+xkY4t1PXV4YWtLc3Z/a97MqlS8T4SlKUdFH4HBELv8Jf9FnJS462j9aF+4D0
LCftDReJ5ni0o5+P9n6IN2aZVcg3gJUlflNAqrXKLBZ9jt/lP4Yk0oVFLSERgksSXI0AedB7Yfzx
qhFfxTIyQqpwDltidpUvbdmJYz3rp+NqNSNJ4QSroLtlTW1H/insme0wlKPFMsZlavTikqyRc1bQ
hoqCjbY5KD++c/thcL9nK6BBY2CQkch7Yof9HQI9iNST3OmPpDcUZuAM7wK13uzOO3sQoN30XdIV
e2k7lnvhw4LHIPSRLxS6pYnCEbg2BLCa40lxIZ6qNKRCC94ajShX77liaU4iDJ/E+Spoej7TQdD2
+88y0yLJYQcxwgVajJUVJZA7nLI0WiOpSKaBQ2ywQMqoGNu2fpVbOyWo5WEEAy5NQwjIo8O5BXIW
JIKrNIkaCm20SX4IM4NwKmCgGxNUR01neCFzuhQheRcQnY6eciEKqhkloBQAvzQsAPzvLE0NLW5P
Xjo9GGh0PvPMsKVo2wlynAHWFFMAYAQ6xAkPbjJihPmmyd4ThefUBcokHbhi3BSWS4YsKRqrxcrr
4c49ge1TCKsIMAgw5B7Gu2a28r4yO8qltP8AT/bKZ0XmEWrIyxCPQ78ngIRdTCfo2menBC/mCs9I
7bKGqvmF8uWpyUPvVtj8eiFN6Am0VweWIBaBdgiWAs3ghqBHI/RZ/dUaprrBngN8iIZhF3YSnr7f
syHQ+3zXK7ydDDQUiN2FBhD1AQ1wettwA1zq25+l0x6hUtFgkSIOLtoHWB1GUYqVmoMpiUABwh9p
ouIF2uihYAGhIC0rFiIHL4oExoG6YguFEu89k0m1vS6m2ixM0p37uqFDFXGMfNZDUTRTekikLXu6
UkOiQk7lNC9KADsD7Y4UBiGIQi4g4hOQTErKXxA2t4NqU8V7E560lrRjtJjc/m+/gmu8oPynLEFc
dVyrq3vvGcGgYKAPodaDFBcnjXTym51Dm4uSBAaRUapTtz9Ukbo2WyFOI7Zq/Z7RZpCf4VixYsWL
FjTiBKAE6luNSpSiPU8ATrtHgUGv8LFixYsWLBGkQEPNq7BqOBEQDHa3ClImqLuhmQhOLN4IAq0s
utaNuGv/ABurliAglkPnKjpMOidGoYmChAEEWKMlsD0HJA9htgxwOH0GQyrcfWuXLly5cuGoS1Fv
UuQTT6UcHMzgKTxIs/WuXLly5cuFi1GA6XROtukwBBnAIKEIFqwGi2iqw0NF+IWeFTBaT7yYzzQz
g8xQCigBr6U/8cbq5YkKFuNFQN0c3cSNwvdyvDAgBRDcKG+s1tyg5Bhk3mfRwnzzhVl/g8CBAgQI
EC/bsQZNBKVGylooAb0Ycog3CoGGoCPrAgQIECBArJaHW8S54VA2nPI7aUCyqMBLU314NXxuU8QB
4og4xrqeZUKUebgZG2SogXGh9UFEjWw/Jgfx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePH
jx48ePHjx48ePHjxE4AstB4NYwVFCDX4W3Z/cIJg6/Hjx48ePHjx48ePHjx48ePHjx48aH/clu8l
D/BnptsviYKwERMGrf8A4gePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx
48ePHjx48ePHjx48ePHjx48ePHjx49W4cZnoJicTBWfsQ8ePHjx48ePHjx48ePHi/DjM9LMTgYKz
/kHjx48ePHjx4B3AYzwcIABESPNbsuDFBVFVVVZY8mpRfX1/8T6v9j+j/wCeaaUNRMA/l3dvBAh2
ExX4Ob9fX7qbEeokRfJk0SXLlMknAPCBu3bhAgQT2/x7detdv8e3XrXb/Ht1612/x7detcrv9+vW
tv7w52xx79etdx8e/XrXbHHv1612xx79etdz9/nrW0qZu5f0+FChS/L/ALu3XrX2gQI3btwACckT
JrTlzatOXOvWFouK3sjw95lOgd6+7Yq7zlwav1LLnQEdBUHbqyNDA/jAuf8AREs+2qw/DxXnOwgc
/M2V9Hm/B5bh76/RdQRdH5rh403HfNDV8BrwocTp4xUHOT53j9NL+qN08R6OLYyqYQqgaNuHUNgF
3+pVL5p5xHXFso00kUAa7TJoUebTbOifM2gQIv7Q0DYRFQlkTCt4dmVrfbYSKzUELp1VxQ1QoENd
r9/jpewQv7G4fs+XP/C3mejTIwK3XrG48e1ef3J4hpCAHYj3JAAAFrFa/cDiJ/ibSgIF+ruNU8cr
yr2Jq/c+avNOHHY7FVPpz+B5+mzl3J217cdh99e3HcXbXtx9lQ3Hd0kR0DNdOs8eJ8OBMnhemey4
B3+uu0+YAIFris5dUH3xEStAwatSzRS53ppMRH8WeodMQUrta8Mvm6518GWBLKbSODd0vc45Rwfw
bXS7tvI6wIovAKqvGK54/wDJycXKZod5cXm5pSY6/TrzOeNC7gXNZb+NtP3pNzHF0929ryxpKZ5q
TvunHf6aUa5x/wBNdTW9+7PAVCrgGelc78e0Vzg5tkzuvi5mvHTnciweq/PXpGauuK9891nWlcGd
d3c/prHVfXcziu75R2vWJx48no8c64nV+P6+uksKaEpMCcOTTGnLGe0O2nZnUVrT2I89ZSAF0Brn
eBuzwKqLWZvEyt+eORpU1wmvXLZCnMvAfThUryU0P0bxpjOBquLSp85rRxvKP32eAiL9lrYojNel
/9k=

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

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

------=_NextPart_000_05D4_01CCD7BE.591C80A0--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBG-00022i-1I; Wed, 01 Feb 2012 10:12:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RoJbQ-0005sS-Nl; Fri, 20 Jan 2012 18:54:20 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327085653!9409260!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14318 invoked from network); 20 Jan 2012 18:54:13 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 18:54:13 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0KIrMxH007273;
	Fri, 20 Jan 2012 20:53:22 +0200
Message-ID: <3B7B9131A63345CCB34B508E3E4F3507@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>,
	=?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
Date: Fri, 20 Jan 2012 20:53:53 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

UGxlYXNlIG1ha2UgYSBtYW51YWwKb3IgbGV0J3MgdG9nZXRoZXIgbWFrZQoK0JIg0L/Rj9GC0L3Q
uNGG0YMsINC00LLQsNC00YbQsNGC0L7Qs9C+INGP0L3QstCw0YDRjyAyMDEyINCz0L7QtNCwLCDQ
siAxODo0OToyMCDQktGLINC/0LjRgdCw0LvQuDoKCiBTUj4gUGFzaSwKCiBTUj4gSSBoYXZlIHRo
YXQgZW5hYmxlZCBpbiBteSBCSU9TLCBWVC1kIGZvciB0aGUgY2hpcHNldCBhbmQgVlQteCBmb3Ig
dGhlCiBTUj4gQ1BVLgoKIFNSPiBIYXZlIHlvdSBtYW5hZ2VkIHRvIHBhc3MgeW91ciBncHUgdGhy
b3VnaCB0byB0aGUgZG9tVT8KCiBTUj4gUmVnYXJkcwoKIFNSPiBTYW5kaQogU1I+IE9uIEphbiAy
MCwgMjAxMiA0OjQ3IFBNLCAiUGFzaSBLw6Rya2vDpGluZW4iIDxwYXNpa0Bpa2kuZmk+IHdyb3Rl
OgoKID8/Pj4gT24gRnJpLCBKYW4gMjAsIDIwMTIgYXQgMDI6MDU6NDNQTSArMDEwMCwgU2FuZGkg
Um9taWggd3JvdGU6CiA/Pz4+PiAgICBIZWxsbywKID8/Pj4+ICAgIEkgaGF2ZSBzcGVudCBhIGxv
dCBvZiB0aW1lIHRyeWluZyB0byBnZXQgZ2Z4IHBhc3N0aHJ1IHdvcmtpbmcgb24KID8/Pj4+IG15
CiA/Pz4+IHN5c3RlbQogPz8+Pj4gICAgd2l0aG91dCBzdWNjZXNzLgogPz8+Pj4gICAgSSBsb29r
ZWQgb250byBteSBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYWdhaW4gdG8gbWFrZSBzdXJlIHRoYXQg
aXQKID8/Pj4+IGRvZXMgICBzdXBwb3J0IFZULWQgYW5kIEkgYW0gbm90IHRvbyBzdXJlIHRoYXQg
aXQgZG9lcyBmdWxseS4gICBNeQogPz8+Pj4gaGFyZHdhcmUgaXMgYXMgZm9sbG93czogICAtIFN1
cGVybWljcm8gWDhEVEgtNkYgbW90aGVyYm9hcmQgKDU1MjAgCmNoaXBzZXQKID8/Pj4+IHdoaWNo
IHN1cHBvcnRzIFZULWQpICAgLSBzaW5nbGUgWGVvbiBYNTY1MCBDUFUgKHdoaWNoIGlzIGxpc3Rl
ZCBhcwogPz8+Pj4gc3VwcG9ydGluZyBWVC14LCBubwogPz8+PiBtZW50aW9uIG9mCiA/Pz4+PiAg
ICBWVC1kIGF0IFsxXWFyay5pbnRlbC5jb20pCiA/Pz4+PiAgICBOb3csIGFjY29yZGluZyB0byB0
aGUgWzJdVlRkSG93VG8sIHRoZSBtb3RoZXJib2FyZCBCSU9TLCBjaGlwc2V0CiA/Pz4+PiBBTkQK
ID8/Pj4gQ1BVCiA/Pz4+PiAgICBuZWVkIHRvIHN1cHBvcnQgVlQtZC4KID8/Pj4+ICAgIFdoYXQg
Y29uZnVzZXMgbWUgaXMsIHdoeSBpcyB0aGUgNTV4MCBjaGlwc2V0IGxpc3RlZCB0aGVyZSBpZiBu
b25lCiA/Pz4+PiBvZgogPz8+PiB0aGUKID8/Pj4+ICAgIENQVSdzIHN1cHBvcnRlZCwgdGhhdCBJ
IGtub3cgb2YsIGRvbnQgaGF2ZSB0aGUgVlQtZCBmZWF0dXJlCiA/Pz4+PiBvcHRpb24sCiA/Pz4+
IG9ubHkKID8/Pj4+ICAgIFZULXguCiA/Pz4+PgogCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBM-0002DG-DS; Wed, 01 Feb 2012 10:12:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIan-0005gy-LN; Mon, 23 Jan 2012 12:01:45 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327320098!12123872!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30503 invoked from network); 23 Jan 2012 12:01:39 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 12:01:39 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NC0q60022487;
	Mon, 23 Jan 2012 14:00:52 +0200
Message-ID: <48D10F9F57354C4D989F3F280ABE9538@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>, "John Sherwood" <jrs@vt.edu>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com><CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com><CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
	<027167128F834966B223737A4B5F6DFA@nobody>
Date: Mon, 23 Jan 2012 14:01:24 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 SR>> I am trying to pass my secondary graphics card through to the VM. My
 SR>> dom0 runs with the primary card (an onboard GPU).

 SR>> What happens with me is that the secondary card (GTX480) is
 SR>> relinquished to pciback and according to the logs, it looks like the
 SR>> card is passed through successfully to the domU.
 SR>> What happens though is a bit puzzling (with gfx_passthru=1):
 SR>> 1) When I start the domU, my dom0 screen goes blank (which is using a
 SR>> different graphics card than is assigned to the domU)
 SR>> 2) The domain does not boot; i.e. the CDROM does not spin up.
 SR>> 3) If I connect to the domain via vnc, I see only the qemu console.

 LA> The same nonsense. But my video is ATI
I mean I have a similar result


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBG-00023j-TT; Wed, 01 Feb 2012 10:12:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RpldN-00030W-5k
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:02:21 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327431730!12173418!1
X-Originating-IP: [202.81.31.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NyA9PiA1OTQxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27674 invoked from network); 24 Jan 2012 19:02:14 -0000
Received: from e23smtp05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.31.147)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 19:02:14 -0000
Received: from /spool/local
	by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 24 Jan 2012 18:58:54 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp05.au.ibm.com (202.81.31.211) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 24 Jan 2012 18:58:50 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0OJ1uN3606382
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 06:01:56 +1100
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0OJ1s8E013536
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 06:01:56 +1100
Received: from oc5400248562.ibm.com ([9.77.201.56])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0OJ1ibO012392; Wed, 25 Jan 2012 06:01:44 +1100
Message-ID: <4F1F0019.2010601@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 00:31:45 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<4F15C48F.1000000@linux.vnet.ibm.com>
In-Reply-To: <4F15C48F.1000000@linux.vnet.ibm.com>
x-cbid: 12012408-1396-0000-0000-000000947761
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 12:27 AM, Raghavendra K T wrote:
> On 01/17/2012 04:32 PM, Marcelo Tosatti wrote:
>> On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
[...]
>>> + || (vcpu->requests& ~(1UL<<KVM_REQ_PVLOCK_KICK))
>>> + || need_resched() || signal_pending(current)) {
>>> vcpu->mode = OUTSIDE_GUEST_MODE;
>>> smp_wmb();
>>> local_irq_enable();
>>> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>>> !vcpu->arch.apf.halted)
>>> || !list_empty_careful(&vcpu->async_pf.done)
>>> || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
>>> + || kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
>>
>> The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
>> on vcpu entry (along with the other kvm_check_request processing).
>>
[...]
>
> I had tried alternative approach earlier, I think that is closer
> to your expectation.
>
> where
> - flag is read in kvm_arch_vcpu_runnable
> - flag cleared in vcpu entry along with others.
>
> But it needs per vcpu flag to remember that pv_unhalted while clearing
> the flag in vcpu enter [ patch below ]. Could not find third alternative
> though.
[...]
> do you think having pv_unhalt flag in below patch cause problem to
> live migration still? (vcpu->request bit is retained as is) OR do we
> have to have KVM_GET_MP_STATE changes also with below patch you
> mentioned earlier.
>

Avi, Marcello, Please let me know, any comments you have on how should
it look like in next version?
Should I get rid of KVM_REQ_PVLOCK_KICK bit in vcpu->request and have
only pv_unahlt flag as below and also add MSR as suggested?

> ---8<---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..1bf8fa8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5684,6 +5717,11 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> r = 1;
> goto out;
> }
> + if (kvm_check_request(KVM_REQ_PVKICK, vcpu)) {
> + vcpu->pv_unhalted = 1;
> + r = 1;
> + goto out;
> + }
> if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
> record_steal_time(vcpu);
> if (kvm_check_request(KVM_REQ_NMI, vcpu))
> @@ -6683,6 +6720,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> !vcpu->arch.apf.halted)
> || !list_empty_careful(&vcpu->async_pf.done)
> || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> + || (kvm_test_request(KVM_REQ_PVKICK, vcpu) || vcpu->pv_unhalted)
> || atomic_read(&vcpu->arch.nmi_queued) ||
> (kvm_arch_interrupt_allowed(vcpu) &&
> kvm_cpu_has_interrupt(vcpu));
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d526231..a48e0f2 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -154,6 +155,8 @@ struct kvm_vcpu {
> #endif
>
> struct kvm_vcpu_arch arch;
> +
> + int pv_unhalted;
> };
>
> static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> @@ -770,5 +773,12 @@ static inline bool kvm_check_request(int req,
> struct kvm_vcpu *vcpu)
> }
> }
>
> +static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
> +{
> + if (test_bit(req, &vcpu->requests))
> + return true;
> + else
> + return false;
> +}
> #endif
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d9cfb78..55c44a2 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm
> *kvm, unsigned id)
> vcpu->kvm = kvm;
> vcpu->vcpu_id = id;
> vcpu->pid = NULL;
> + vcpu->pv_unhalted = 0;
> init_waitqueue_head(&vcpu->wq);
> kvm_async_pf_vcpu_init(vcpu);
>
> @@ -1509,11 +1510,12 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
> void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> {
> DEFINE_WAIT(wait);
> for (;;) {
> prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>
> if (kvm_arch_vcpu_runnable(vcpu)) {
> + vcpu->pv_unhalted = 0;
> kvm_make_request(KVM_REQ_UNHALT, vcpu);
> break;
> }
>


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBO-0002Gn-6n; Wed, 01 Feb 2012 10:12:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rph42-0000H5-VC
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:09:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327414166!3132995!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10669 invoked from network); 24 Jan 2012 14:09:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 14:09:27 -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 q0OE90dt028293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 09:09:00 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OE8pd8003446; Tue, 24 Jan 2012 09:08:52 -0500
Message-ID: <4F1EBB73.3000705@redhat.com>
Date: Tue, 24 Jan 2012 16:08:51 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
	<20120118135445.GB25711@linux.vnet.ibm.com>
	<4F173F0F.5020604@goop.org>
In-Reply-To: <4F173F0F.5020604@goop.org>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 11:52 PM, Jeremy Fitzhardinge wrote:
> On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
> >
> >> That logic relies on the "kick" being level triggered, so that "kick"
> >> before "block" will cause the block to fall out immediately.  If you're
> >> using "hlt" as the block and it has the usual edge-triggered behaviour,
> >> what stops a "kick-before-hlt" from losing the kick?
> > Hmm ..'hlt' should result in a check for kick request (in hypervisor
> > context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
> > will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
> > before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
> >
> > Won't that trap the 'kick-before-hlt' case? What am I missing here?
>
> Nothing, that sounds fine.  It wasn't clear to me that your kick
> operation left persistent state, and so has a level-triggered effect on hlt.
>

btw, this persistent state needs to be saved/restored for live
migration.  Best to put it into some MSR.

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


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBN-0002ER-00; Wed, 01 Feb 2012 10:12:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpK59-00026f-OQ; Mon, 23 Jan 2012 13:37:11 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327325824!10324399!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26105 invoked from network); 23 Jan 2012 13:37:04 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 13:37:04 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NDaA7x025783;
	Mon, 23 Jan 2012 15:36:11 +0200
Message-ID: <51A65EA9980F41C9A98C83820FEC3E87@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <xen-devel@lists.xensource.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Date: Mon, 23 Jan 2012 15:36:42 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	xen-users@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

As has already been written before - does not work. This water in the 
internet a lot. If you work - help with a manual. I am from April 2011, each 
month make a new entry. In January, compiled nine different versions of the 
kernel for Xena. 3 different versions of Xena: 4.0.2rc3, 4.1.2,4.2 unstable 
/ test them on debian and Ubuntu - not worked

 TG> The thing is, you either dont need patches at all to get it to work
 TG> (ATI), or you need to customize patches reflecting your individual
 TG> setup (NVIDIA);

 TG> To be more specific:
 TG> I can confirm that passing through a ATI Card works "out of the box" -
 TG> either to Windows 7 or Windows XP;
 TG> In the past i had a setup running with a NVIDIA card, it only worked
 TG> with special patches (the ones David packed together and offers as
 TG> tarball) and - as far as i can tell - are not generaly working for all
 TG> NVIDIA Cards, i.e. you have to adjust Memory-Adresses in the acpi.dst
 TG> (iirc). - and even then the passed through Card worked only with
 TG> Windows XP - NOT with Windows 7;

 TG> Both setup have the "flaw" that they only work once - meaning you can't
 TG> reboot your DomU , cause after the reboot the passed-through Card
 TG> doesnt have correct 3D-Accelleration any more (was/is the case with
 TG> NVIDIA and ATI, Windows XP and Windows7 )

 TG> So - to summarize: It works easiest and most featureful with a ATI 
Card;
 TG>                        It may work with patches and only with WindowsXP
 TG> with an NVIDIA card

 TG> To me it seems that unless someone finds an general approach to
 TG> runtime-detect the NVIDIA-Secific stuff , submitting any patches may be
 TG> to early, as it arouses expectations which only in some cases will be
 TG> met.

 TG> That said - i gladly can forward-port these old patches, if you think
 TG> they are helping in any way.

 TG> Greetings!
 TG> Tobias

 TG> Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
 ??>> Please do not a) top-post or b) cross-post. The latter being aimed at
 ??>> whoever started this thread.
 ??>>
 ??>> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
 ??>>> Yeah, I guess xen has generally been focused on the server end.
 ??>>
 ??>> Xen is focused on whatever people submit patches to do. Many of the
 ??>> core developers are not currently looking at VGA passthrough, we have
 ??>> plenty of stuff on our plates, but we are more than happy to review
 ??>> and accept patches to implement/improve/fix this feature if only those
 ??>> people who are interested in it would take the time to submit them per
 ??>> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
 ??>> going to go out hunting for patches on the Internet.
 ??>>
 ??>> David Techer recently offered to do this but perhaps he would be
 ??>> interested in some help from you?
 ??>>


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBI-000263-KY; Wed, 01 Feb 2012 10:12:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>)
	id 1RoKPm-0007IS-E5; Fri, 20 Jan 2012 19:46:22 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327088727!49468347!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25552 invoked from network); 20 Jan 2012 19:45:28 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 19:45:28 -0000
Received: by iahk25 with SMTP id k25so7753790iah.30
	for <multiple recipients>; Fri, 20 Jan 2012 11:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=FBIjqnSPs4q/rDIuQPA1sbKZwbXJRDNb1Ic9dByyrV8=;
	b=hkUuazHYti49silci2sxBUCSf7I9Pz2Hew4xiqh46PZlVxZYMUaeD45yZnUapQ4KW4
	VdOIS7yPwLznySdYAUs96N3rq4lJpNsV/I5VG65qo/I2LJ54J5F4ktz5oIV6TFBf+0WU
	XeH/NhgB8oFMHo3Ug430iy4d063d9qVytv4Qo=
MIME-Version: 1.0
Received: by 10.42.168.138 with SMTP id w10mr27404410icy.47.1327088773406;
	Fri, 20 Jan 2012 11:46:13 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Fri, 20 Jan 2012 11:46:13 -0800 (PST)
In-Reply-To: <CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
Date: Fri, 20 Jan 2012 14:46:13 -0500
X-Google-Sender-Auth: 3xIkvKyocinNv3wAEk-a0DkhRWw
Message-ID: <CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: chris <tknchris@gmail.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	Likarpenkov Alexander <al@ohosting.org.ua>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2326141285686832260=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2326141285686832260==
Content-Type: multipart/alternative; boundary=90e6ba6e8e12ec9f6404b6faeeb1

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

Most people run Xen for headless virtual machines, and VGA passthrough
requires VT-d support in both the CPU and motherboard.  VGA passthrough is
also somewhat dependent on the card you're using it with, so it's a hard
thing to test.  If you want it to get more love, then you're the best
situated person to do it :)

However, on the topic of Sandi's issue:
If your monitor goes black, that's a GOOD sign - it's indicative that the
dom0 is relinquishing control of the graphics card, so at least that's
working.  In my experience using graphics passthrough, this problem is
related to your card not being fully supported; essentially, Xen can't pass
your card through to the VM during boot.  If you leave the `gfx_passthru`
option *disabled*, you'll have the emulated cirrus card (by default) and it
will at least boot successfully.  Here's some step by step
suggestions/instructions:


   - disable gfx_passthru in config (delete the option or set it to 0)
   - enable VNC, listening on all interfaces
   - start the VM - your screen should still go black
   - From another machine (what with your screen being black), connect in
   via VNC and fire up the device manager in XP.  I don't have any XP boxes
   left, but in Windows 7, you should see a device in an error state under
   'Display adapters'.
   - Check its PCI slot under 'details' - "Location Paths" should help.
   Compare that to `xm pci-list [domain name]` to see if it matches up with
   the graphics card.
   - Install the driver for that device
   - Reboot.  You won't see the BIOS on the monitor, but it should use it
   once Windows takes over.

If something in there doesn't work, hopefully I can help you debug - I went
through a lot of this a while back.

On Fri, Jan 20, 2012 at 2:24 PM, chris <tknchris@gmail.com> wrote:

> I'm really surprised this doesnt get more attention. For as long as I've
> been on this list, this feature has been mentioned so many times I would
> think that getting this working would be a huge feature that would make t=
he
> product even better. I have only seen the occasional success with
> experimental patches etc, despite this being talked about for years.
>
>
> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander <al@ohosting.org.u=
a
> > wrote:
>
>> Please make a manual
>> or let's together make
>>
>> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>>
>> SR> Pasi,
>>
>> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e
>> SR> CPU.
>>
>> SR> Have you managed to pass your gpu through to the domU?
>>
>> SR> Regards
>>
>> SR> Sandi
>> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> =
wrote:
>>
>> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>> ??>>>    Hello,
>> ??>>>    I have spent a lot of time trying to get gfx passthru working o=
n
>> ??>>> my
>> ??>> system
>> ??>>>    without success.
>> ??>>>    I looked onto my hardware capabilities again to make sure that =
it
>> ??>>> does   support VT-d and I am not too sure that it does fully.   My
>> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
>> chipset
>> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
>> ??>>> supporting VT-x, no
>> ??>> mention of
>> ??>>>    VT-d at [1]ark.intel.com)
>> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipse=
t
>> ??>>> AND
>> ??>> CPU
>> ??>>>    need to support VT-d.
>> ??>>>    What confuses me is, why is the 55x0 chipset listed there if no=
ne
>> ??>>> of
>> ??>> the
>> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
>> ??>>> option,
>> ??>> only
>> ??>>>    VT-x.
>> ??>>>
>>
>>
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-us=
ers>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
>

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

Most people run Xen for headless virtual machines, and VGA passthrough requ=
ires VT-d support in both the CPU and motherboard.=C2=A0 VGA passthrough is=
 also somewhat dependent on the card you&#39;re using it with, so it&#39;s =
a hard thing to test.=C2=A0 If you want it to get more love, then you&#39;r=
e the best situated person to do it :)<br>
<br>However, on the topic of Sandi&#39;s issue:<br>If your monitor goes bla=
ck, that&#39;s a GOOD sign - it&#39;s indicative that the dom0 is relinquis=
hing control of the graphics card, so at least that&#39;s working.=C2=A0 In=
 my experience using graphics passthrough, this problem is related to your =
card not being fully supported; essentially, Xen can&#39;t pass your card t=
hrough to the VM during boot.=C2=A0 If you leave the `gfx_passthru` option =
*disabled*, you&#39;ll have the emulated cirrus card (by default) and it wi=
ll at least boot successfully.=C2=A0 Here&#39;s some step by step suggestio=
ns/instructions:<br>
<br><ul><li>disable gfx_passthru in config (delete the option or set it to =
0)<br></li><li>enable VNC, listening on all interfaces</li><li>start the VM=
 - your screen should still go black</li><li>From another machine (what wit=
h your screen being black), connect in via VNC and fire up the device manag=
er in XP.=C2=A0 I don&#39;t have any XP boxes left, but in Windows 7, you s=
hould see a device in an error state under &#39;Display adapters&#39;.</li>
<li>Check its PCI slot under &#39;details&#39; - &quot;Location Paths&quot;=
 should help.=C2=A0 Compare that to `xm pci-list [domain name]` to see if i=
t matches up with the graphics card.</li><li>Install the driver for that de=
vice</li>
<li>Reboot.=C2=A0 You won&#39;t see the BIOS on the monitor, but it should =
use it once Windows takes over.</li></ul><p>If something in there doesn&#39=
;t work, hopefully I can help you debug - I went through a lot of this a wh=
ile back.<br>
</p><br><div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 2:24 PM, chris <=
span dir=3D"ltr">&lt;<a href=3D"mailto:tknchris@gmail.com">tknchris@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m really surprised this doesnt get more attention. For as long as I&#=
39;ve been on this list, this feature has been mentioned so many times I wo=
uld think that getting this working would be a huge feature that would make=
 the product even better. I have only seen the occasional success with expe=
rimental patches etc, despite this being talked about for years.<div class=
=3D"HOEnZb">
<div class=3D"h5"><br>
<br><div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov=
 Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:al@ohosting.org.ua" targ=
et=3D"_blank">al@ohosting.org.ua</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com" target=3D"_blank">Xen-user=
s@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-users</a></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com">Xen-users@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/xen-users</a><br>
<br></blockquote></div><br>

--90e6ba6e8e12ec9f6404b6faeeb1--


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

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

--===============2326141285686832260==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBJ-00027d-Jg; Wed, 01 Feb 2012 10:12:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RoKZu-0007yO-7Z; Fri, 20 Jan 2012 19:56:51 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327089402!5826427!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4534 invoked from network); 20 Jan 2012 19:56:43 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 19:56:43 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0KJtob5008865;
	Fri, 20 Jan 2012 21:55:51 +0200
Message-ID: <3B8433EAEDA04EADB4361C946BA29688@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "John Sherwood" <jrs@vt.edu>, "chris" <tknchris@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
Date: Fri, 20 Jan 2012 21:56:22 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_05D4_01CCD7BE.591C80A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

------=_NextPart_000_05D4_01CCD7BE.591C80A0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
Content-Transfer-Encoding: 8bit

This whole garbage works for me. I have 9 months of sitting in windows mode 
pci passthru (see attach). Also on the past 15 virtual machines that are 
involved in hosting this system, two PCIe graphics card, 2 mice and 2 
keyboards, which are divided between two different autonomous operating mode 
HVM. I'd like to see the login screen from the start, but you can not run on 
gfx_passthru different operating systems and versions of xen

 JS> Most people run Xen for headless virtual machines, and VGA passthrough
 JS> requires VT-d support in both the CPU and motherboard.  VGA passthrough
 JS> is also somewhat dependent on the card you're using it with, so it's a
 JS> hard thing to test.  If you want it to get more love, then you're the
 JS> best situated person to do it :)

 JS> However, on the topic of Sandi's issue:
 JS> If your monitor goes black, that's a GOOD sign - it's indicative that
 JS> the dom0 is relinquishing control of the graphics card, so at least
 JS> that's working.  In my experience using graphics passthrough, this
 JS> problem is related to your card not being fully supported; essentially,
 JS> Xen can't pass your card through to the VM during boot.  If you leave
 JS> the `gfx_passthru` option *disabled*, you'll have the emulated cirrus
 JS> card (by default) and it will at least boot successfully.  Here's some
 JS> step by step suggestions/instructions:

 JS>    - disable gfx_passthru in config (delete the option or set it to 0)
 JS>    - enable VNC, listening on all interfaces
 JS>    - start the VM - your screen should still go black
 JS>    - From another machine (what with your screen being black), connect
 JS> in
 JS>    via VNC and fire up the device manager in XP.  I don't have any XP
 JS> boxes
 JS>    left, but in Windows 7, you should see a device in an error state
 JS> under
 JS>    'Display adapters'.
 JS>    - Check its PCI slot under 'details' - "Location Paths" should help.
 JS>    Compare that to `xm pci-list [domain name]` to see if it matches up
 JS> with
 JS>    the graphics card.
 JS>    - Install the driver for that device
 JS>    - Reboot.  You won't see the BIOS on the monitor, but it should use
 JS> it
 JS>    once Windows takes over.

 JS> If something in there doesn't work, hopefully I can help you debug - I
 JS> went through a lot of this a while back.

 JS> On Fri, Jan 20, 2012 at 2:24 PM, chris <tknchris@gmail.com> wrote:

 ??>> I'm really surprised this doesnt get more attention. For as long as
 ??>> I've been on this list, this feature has been mentioned so many times
 ??>> I would think that getting this working would be a huge feature that
 ??>> would make the product even better. I have only seen the occasional
 ??>> success with experimental patches etc, despite this being talked about
 ??>> for years.
 ??>>
 ??>> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander
 ??>> <al@ohosting.org.ua
 ??>>> wrote:
 ??>>
 ??>>> Please make a manual
 ??>>> or let's together make
 ??>>>
 ??>>> В п�тницу, двадцатого �нвар� 2012 года, в 18:49:20 Вы пи�али:
 ??>>>
 SR>>>> Pasi,
 ??>>>
 SR>>>> I have that enabled in my BIOS, VT-d for the chipset and VT-x for
 SR>>>> the CPU.
 ??>>>
 SR>>>> Have you managed to pass your gpu through to the domU?
 ??>>>
 SR>>>> Regards
 ??>>>
 SR>>>> Sandi
 SR>>>> On Jan 20, 2012 4:47 PM, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
 ??>>>
 ??>>>>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
 ??>>>>>>    Hello,
 ??>>>>>>    I have spent a lot of time trying to get gfx passthru working
 ??>>>>>> on my
 ??>>>>> system
 ??>>>>>>    without success.
 ??>>>>>>    I looked onto my hardware capabilities again to make sure that
 ??>>>>>> it does   support VT-d and I am not too sure that it does fully.
 ??>>>>>> My hardware is as follows:   - Supermicro X8DTH-6F motherboard 
(5520
 ??>>> chipset
 ??>>>>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
 ??>>>>>> supporting VT-x, no
 ??>>>>> mention of
 ??>>>>>>    VT-d at [1]ark.intel.com)
 ??>>>>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS,
 ??>>>>>> chipset AND
 ??>>>>> CPU
 ??>>>>>>    need to support VT-d.
 ??>>>>>>    What confuses me is, why is the 55x0 chipset listed there if
 ??>>>>>> none of
 ??>>>>> the
 ??>>>>>>    CPU's supported, that I know of, dont have the VT-d feature
 ??>>>>>> option,
 ??>>>>> only
 ??>>>>>>    VT-x.
 ??>>>>>>

------=_NextPart_000_05D4_01CCD7BE.591C80A0
Content-Type: image/jpeg;
	name="01.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="01.jpg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wgARCAJPAzADASIA
AhEBAxEB/8QAHgABAAICAwEBAQAAAAAAAAAAAAcIBgkDBAUBAgr/xAAcAQEAAwEBAQEBAAAAAAAA
AAAAAQIDBgQFBwj/2gAMAwEAAhADEAAAAZ7wD9R9+k8ln8iZ5E3z95K/eL4z57ydx4J7x7vHFHFG
UucUZeHpvMX5iT1rYZ50404tc5E6sZ+IxlbFMfjb6fmzvyINjnpvgWx/NSuH1Y2246jmVteOpJNt
lSf2W0VM+6Z2z+1L/aLY/am/pFslT/qbYfanfpW16qH0teqiRa/7U/6m16qH0tcqmRa5VIm1qqn2
FqlVPqLV/aqC1X6qp9hapVX6Wq+1UStWqp+oWpVU+otUqqiLVKq/S1KqwtX+qp/U2v8A3U/khbHn
qXz46W07tRO5ne3XbqX6OW1s+5Vf1cdLR9utHq+Xa40r0S7PL9Rejnh2t3g9d3+3RPPMNLXYvW2J
vmdTdPj15e7+a/0BsO8SM6p/V5S/Hk0Cnr7PP+36flyd+nfhfifv2O/F8Y5Mv4vJ6It9TO+OWB+1
73DtjzxhnvBvEYd/MehXKs01ZH0fS8XE8/4dfPhUazr4vs8dSsNut+eh+PSRdrj9GVKeO7HKikX7
u2TST7doUl/V2k1pN+rr/qIpP9uwKULsfYilS6qFKl1vqKU/brfZilS6pNK/1dP9FK11EKWLpilv
26P0pcukKW/bokUtXSIpcuj9hS77dAUwXQ+wpf8AbnimC6Apeuh9RS77dAUvXQFL/tzxTHmuN9op
zy3B+JqX3LXqzWD0rLdjz7V39yde/jvF+UZt3fkfUwb0817vk2j/AL2ddnP0R/5ss8nn9kP92Vv1
8foIq+Sv+qXhr05Tj37Hw/f2g6r7/Y+vB8mq14/wvt7EO/XfM9vLwZjVPwsNrCZvTvEFtg2T1ImL
15e54WLQj5tLbZFrXlO2N7MLxvAp2kzGq/xPlTYpmWsO821JV+RStaV/kUiV0UISuigSuij7aJXR
WVlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlRFYlR
FYlRFYlRFYlRFYlNFisyoisiVUVCVEVpmU0WFZTRYmZT+xWJTRYiJURWmZURWJURWJU1qXXox7vm
eJf6g12Po+TIf1Asw+Xf2OOPo7+P9ixfH+sY1pkvHh+NfC0k7AMTwT7FZnzSqvpWi2H48bpwyLlw
L1TJmFU46XwX/wATiHD/AJPtm/ng/o+C1vv3DEkXj3ftC7k/RplbneS/A5xwOcjgc44HOOBzjgc4
4HOOBzjgc44HOOBzjgc44HOOBzjgc44HOOBzjgc44HOOBzjgc44HOOBz/DhcxPC5hwuYcLmHC5hw
uYcLmHC5hwuYcLmHC5hwuYcNGb2UX9vzPOtrUzZJ6Pna+bQzF+pyqbFGwzp8l2WJ9GRel684k5pI
8z8a+/E/RmiMf1/4Mj1ykPPfG/HpZbiHpnFfXyP1YpFutzbzHPWfOqdKdhMW+Z6vUif2uxze3j5H
KHse69OZIn376I8t6hHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHl
vUHlvUHlvUHlvUHlvUHlvUHlvUHlvUHlvU+y8p6q0eU9UeU9UeU9UeU9UeU9UeU9UeU9UeU9UeU9
UeU9UeU9UeVQTYhrx+l8nDNnWse+Hl28OVtRu2230Mk7VfeXlvdP32onRvW4/wCa/Q/Gl6/xEEF0
XT/VA8uvNzVeMApW4yqnp3pZhSnu3vcn8YhC9Jsz8r91lZQxeO7QZ7YOjq0NsINx/wASPLZ2S4/Y
rfn6Zx54FyLTCVvsEX8IBWKVvXVYoV1WKFdlihXVYoV1WKFdVihXVYoV1WKFdVihXVYoV1WKFdVi
hXVYoV1WKFdVihXVYoV1WKFdVihXX7YlEV28KzFbTF0a+jE5yrzI01kBgEvJ8BYwVzWMFc1jBXNY
wVzWMFc1jBXNYwVzWMFc6v7LNbv3/iR/fCjG4vauvq/sXSrzX24v9GsE8eXWSIe8LMPZTM/zXDux
Nnu/WXNFpK7cOdWaTDC+OXAI6yjIyYx9nNUMQxeV0I96kmrRW+RMJzdP3JMm/Kutj1b4fjTFhVca
/wD12yv8d+v3wvRJswVn5lbKfus/QrNqflRMPvN7FYsyhNaklxbR6wiQAAAAAAAAAAAAAAOjWOzl
TdKc0MTM+z8mOfCmNNYizvIiZXRQTK6KBK6KBK6KBK6KBK6KBK6KBK6KBK9CrPVs9ngwTcBqO26+
b2VCth6H55z7tMZWmDvfA9MVxx14x+x5ZN92Uol03zPNfI8vfH8Yd7/HV5s+YNiqZyYdHNqTuxXK
qgSBX3N8IzeYkv59ROLdP2e7FapxVOFMum5XaVXuaY45nq/H9TL+lM+Xjkpc0xgX46kr3Rr6k1fv
Ka7ytmq0BEgAAAAAAAAAAAAAAdGn9wKa+nz11jiY/A7Xlse48m5Iri/mZhl0TAfsZt+7xhOQc8f5
b+nYmKJM9HiytjDWmTsYTGTsYGTsYGT64r7MNvbwHI/IzjENsurfaRz33v38+vh/ajz0Mw4aqW+J
KOPaY2MgSwvlZeipcg24+aUq/gtqkWqTjuwlF6OY3sHWpAk9lqBSwFfc3wjN5iSxE4Z5Wb9iFKqM
7wuL7HnwKJrIwT8b01zzm1HFetC5Etf24vQS0M4/LZ+j94eatgAAAAAAAAAAAAAAAAOhWiy9epiR
EoPR54t60tVkm0hfqls9zEt/aozD57SR+62eZrFpOeFOvKc2LTyiL/sniMEniMEniMEn6oDYhSzZ
Fr2+h87GtlWu/YhTXkHyfqRn7uUfhGtaNb7xrh6Jer/eHk2w1s5VsJJpvHGw9rGsKTr3sZ1I7XfR
awFAAFfc3wjN5iSxE4Bx5h+qoa8GNfH9uNtaTXo9n5++vPI74/Nqa4vxsm5Y21vepsJ46Z8nb4uG
7tgAAAAAAAAAAAAAAAA6Ne7CV8LIgY1kojPz5cEKZ1mKJirzJoSh31pMSwDPyIAAAYfmAUPvhSn6
Hz4P2g/zvf0QfX+dzDmOhwvudn0oik/77vqfn/vnnX7srx/v/HSnJ7UZBa1UIhu5mlq1Uia+3YrO
uiarF9uXjyxj2QziFbgV9zfCM3mJLETgkIzv+YnURl213X31fyb96271feT+pWiMb2YdsheYJC+Z
Wqdj95fCWqriVnJlmaeTjnPr6YZoM7gAAAAAAAAAAAAAAdGvlg6+FkQAAAAAAAAAANfewTRl0vOx
V/RB/O//AERe7yhxnWY17HhepDXtClt409nls9kmURb4vb+OT8/utIzyOSvF9GmGdzt+rSmYwzLm
HJwuRPIklEOdjNMdjT1fCjmTLZ9/PY5ka2UljPTGMkx3JYfnF8qwiJg7TP8A0JVU7f5Mu+BC1k+H
90X5llHszvTeYsh497QlN/W9mtet4+eZrTSkVnMezyJpj7c889sY3wS02bXvSHMZ58Giw4ioAAAA
AAAAAAHRr5YOvhZEAAAAAAAAAADRlvN0b9dyEUf0P/zxf0O+iQ4nrvH7+A+smrnR9uKvm/VuNgvq
Rb7/AJU0xxjnm3pZTx635DG1k+pW7wVbL5/UOyNYk98+y+i0AV9zbCc1JNBh+YYbmQw/MMNhFuvj
ZNSbrPHeXFozyDlPZ7Wf1p8K1rHZRV/FqxY/Ma4TnEY1kWBYSrbfBsahy2tqfRrDhVc7CSpTaaNd
powXwYwywmDKqlR1fW6eV1/iRXYp6JFQiQAAAAAAAOjXywdfCyIAAAAAAAAAAGjjePo87HjIp/oY
/nn/AKGNbfRxPY/jz/T8gxyvcf1l1820/BMFhbP2X58XXLllsdheCUPluiyub654yabavmt2NInb
n+Nbli9c7gDKwSr7muFZqSaDwfcwLrkjVk/MBMr1QlIVP8trS9unEgaxYzxY16dVnI+w+C5i0OYV
BxqbXhy6o9f9G0f1KIx1WNmapFt6gAAAAAAAAAAAAAOjXywdfCyIAAAAAAAAAAGj7eDpB7HjIp/o
U/nr/oU1l1qhT7xHY8WS68sl+zz00eTzQ18z790/YqvjmO1zfxS21+uWR/czZzhTNScNjWfBhXey
dMBEgV9zbCc3mJLET53cx3qGBQ3OlGZyvnJteqGxtt3U9iummxX7SuVb4z81pSza11PtDLBVib+e
mvh0teZr1xnXXZg1ly9PmusieWKgiwAAAAAAAAAAAHRr5YOvhZEAAAAAAAAAADSHu80j9jxkUf0G
fz7/ANA+sR9+ZH+cT2lVcWulxRWOvxUmOKW2K+dH8RTpIU8Vvme+EqNfOQaaXmVxx3JbBUfglb9V
zxoi3iq1qdICk19zfCM3mJLETjnb6/GVZiDmky/ksBmGO0jy9V5YHzqNJ0kKZq1e5OUm5FV7q56W
V79YeG1rOevXJrjPfSiqLMtradXDMX0xnrIac2YicuESAAAAAAAAAAAB0a+WDr4WRAAAAAAAAAAA
0j7uNJnY8VFP9Av8/v8AQBrPNx+X3uJ7Tk4aUXRtlrTx68uY019KJJB69NMFkn9+tpjG2Ezd+rXw
+Jpq6dLQJNmZYpdxev6HYzrh09QVleqSkWSbSsB5vhGbyksROL9X1vRKnwbfXxrYYR6EoU+y9Ep+
7g8qaIekXFu5FefkkTBaz4uTY35s6+v7UUWl0wwnH5G87LTpYZ6/Pd1stxXMJpIrGcmgESAAAAAA
AAAAB0a+WDr4WRAAAAAAAAAAA0m7stKHY8VFO/zQF/QDrnDctdv5xPca5JKs1lXs8Vfobvk8fuo/
7FyfpR+XbDJjXnIFzEXrnGl12ddQliL5vTel3Jc1hGv/AN68TVS24ffUrX3N8IzeYksROGeZmvNE
VRqhtJxHLyxxB9646v6ayTZP+NXtWr3bNfUVkwy2HsJrrFl6ewtUCR56Wzpv3LeKaU1wbYGtpQrI
7pJwiyUyICLAAAAAAAAAAAdGvlg6+FkQAAAAAAAAAANKO67Sj2PFRZv80Db+dcuX59cT3Xx9AAAA
AAAAAFfc3wjN5iSxE4Bx5hyQphEOxqDd8c3ops66/m31pedsazK7XrHe1D8mr6cLl/azy83m91Tn
FpAAAAAAAAAAAAAAAA6NfLB18LIgAAAAAAAAAAaVd1WlXruRi7f1oJ37+jzhxPbAAAAAAAAAAV9z
TC8zJPBh3T9L1SoNYNg0O75251W7WPMw21pTvabGLVwiu94f1CjdgZS9CGtmVrnenOlWuWxOFKw7
j1wfQq1uy7ab3N1UPGk6Z/NtUta/1/R4q2YRbzCPP6Ja9P8AP61xCtwAAAAAAAAOjXywdfCyIAAA
AAAAAAAGlHddpYy+xGG/bQXv07v8wDie3AAAAAAAAAAr7meGZmSeDF+XrcRphy66dW/1v42x6o11
Yq/J/txHJHm5dOMXZHkmO5a5VYGDpwmeb6KgAAAAAAAAAAABAJAAAdGvlg6+FkQAAAAAAAAAANNm
5PT75frwbv00Ib7/ANA/MQ4ntwAAAAAAAAAK+5nhmZkng8D2MO6hHlUJFjbo+W2B1jtnSHm+tnvM
KdZzelkMRh7y6Lc4/h1aLzZWRamxPK8WSVj96sWXzGA58mgVsAAAAAAAAA+ffyffv5+xH0TJ8+gH
Rr5YOvhZEAAAAAAAAB+f1AJNRm3PUlesBb6tC++js+HDie6AAAAAAAAAAr7meGZmSeDy+1FULEue
D+IDt5L6QplNS8vdcLMtYXBedoePV/gatdjfnazZcmL69nWrkN89hIrcAAAAAAAAAAAfD6AAADo1
8sHXwsiAAAAAAAADi5et2YqE2ai9umn37/NQ1vn0Ob4/r/IDie8AAAAAAAAAAr7meGZmSeDwvSx3
JyDo/tVhUx7OPdOr3iXt4YNhGm14/tMOL35XZ6lMuWF0O1X2l06bU1VMHtleNTyAs7bQGubYzrAU
AAAAAAAAPx+P3D9iQAAHRr5YOvhZEAAAAAAAAH4/ZAJfnTluL03ddxcY749D2+H0ecOJ7wAAAAAA
AAACvuZ4ZmZJ4MRyHw+c7HhV7rHfPZHTK21EPh+2zU9V4wusWV9mP8D+x5ctzmEI0trdjH4NjuIu
/jkY4HdZPPKG2QvnnOUmdgAAAAAAAAPx8/XFnHM4eW8/oSAA6NfLB18LIgAAAAAAAA/P38Mp5BrD
TVuU019jxEcb3NEu9rbAOI74AAAAAAAAACvuZ4ZmZJ4MT63reieJAtQIf0z3XxT6UI4b5b7GQeva
kfcmTdm0YnwZjxxbvRXZ7llD3JLpXCvFk9EgAAAAAAAAAHz6AAAAdGvlg6+FkQAAAAAAAAcHP1uz
AJNNW5XTd2HERzvX0V71N/OHEd+AAAAAAAAABX3M8MzMk8GD9HMu2aR4I/oXjPJxQXdCObWgrLrH
fL114S1Zv14UJmifuhLLe3wc4AY5kYAAPNPSI5JGAAAAAB+f1+fxFeV1P0t2X4/SPr8pfp+UT06+
WBr8WREgAAAAAAAOLl6/YiAmWm7cjp07HiI43paMN5+3mDiP0AAAAAAAAAACvuZ4ZmZJ4I9ZR6BQ
f3LpwfthNeuXY/8AMPTQDp7EOeGpjYxKPnWzoVi+yz5DVDdax37tOpeW9hpek0D7RcEiaO8ey0mn
0UbGFstd/ibK1Lay+ts9bX1VzbednQIgAAA+fQfD6+fQAA+DpV8sHXwsiAAAAAAAAA+EfXwfdQe3
zVF1vGwhvL0b7yPV4X3594f9BCQAAAAAAAAFfczwzMyTwYh0fS9goT69s6ywsrrV2yxkvX7yLUck
0pXm2WzMjB41sv8AYa7pltr8bUdxW+/28VwszwZfOHoilwAAAAAAAAAAAAAOjXywdfCyIAAAAAAA
AOr2uDnigTdrR2XUD6blqa7xtHm8P6Hxvn3594j9CCQAAAAAAAAFfczwzMyTwYvzdXgKq6u9w8Fd
v8m3VebTVp4r6WcRPJv2l8RlzxM8tnBHRzj9Nefp+9w0v1bIQNPOuIUuAAAAAAAAAAfEPr4l9APh
9fPp0a+WDr4WRAAAAAAAABwc/HyRB8+pUouvT37/AMOgO8DSDu++xzIcT+hAAAAAAAAAAV9zPDMz
JPB0OGOIanPuRTklGPv/ACNtVfbAVHvE0ZZTuW5vJfLTWY4rIP4hKSbZyt5VTpO1mW46x7H9IuB0
6uSnSuf9evXoTaTvahXza2kaTqrY/NrfTRUi1+Wcgfrj5OZ+8CQAAAAAAAAOjXywdfCyIAAAAAAA
AAAFRbdUm+98Oj27nSVu1+tzD78+8V+hhIAAAAAAAACvuZ4ZmZJ4Px85CMFwyZsC3x5a+2W0KbRv
OwbKaj+fS23TpNiekXO/EBetrWdueu8j0j3OWOf3eJp8bE4arayPoRblkTmki05xCL3VwrrwkpKE
/ayrqzM4+jQXj8vp2JNcHZimxbG9Yd0KxJci6vs/20vhj+s+6lKTTktKYli+x70tY2YXyuHI2sfr
RttBfn9VxBIHRr5YOvhZEAAAAAAAAAADVHtc09dlw+I7stKG6+3jffn3iv0QJAAAAAAAAAV9zPDM
zJPABwYzkeDmcVPsXpv0btuDCIizvYzj1ffmabN+zrSnVa6n7pRidNdgag+J3pskVnsxfzBnqAAA
AAAAAAAAAAB0a+WDr4WRAAAAAAAAAPh9A09bhdSfZ8LHu63Srt7v5cwYd4/E/okko5EjI5EjI5Ej
I5/BJKM+YkZHIkZHIkZHIkZG3dM8Yp+yJc1j6QSTQAfj5yDjoxetLqYnm6GB8EhjxcSkdE4TyZkt
HlYNJyGH5gIBIAAAAAAAAAAAAAHRr5YOvhZEAAAAAAAAAACil66i/f8AhUR2T6z9hn1+X5/S8eOe
J/RZlQCun5ALRPyARP2BR99zehNsEcBPyAWifkAifkAiefTrlImafIK9rmo55FgeSyekc/SRUdCR
UdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCRUdCR
UdCRUdCRUdCRUdDN6+SHFRaNHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkVHQkWo06QB9v4
1VdmWtHZN9Lnuw67jv0HsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647Drjs
OuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOw647DrjsOuOx1vvUPT
dcdh1x2HXHYdcdh1x2HXHYdcdh1x87Pmds7DrjsOuOw647Drj8wjMkM/b+JTy7Wmnu9p+Qbifmn9
837+4X5qA5Tb181Ffc9NvDUZyw228mpXmbbY2p79m17k1R82Wm1X5qt/UNp/Lqt5ZbTWrHknfaV8
1bc+UbQmr0naN81i/iNNnrWLyS2bfNaHPG2yjk1pk7LGtTkRsl/Wtj8Gyr861/2bJ/1rj48ttjn5
1u9PXLZe1l/Zy2Z/dY/AjZ191h8MRtC+6tvm07SmrH9MtpDVn+axtP8AuqvhnHas1Tjav91R/NG1
35qj+m1v7qj4zbA1OfZbYvxqb6xtf87RtH+n0v6DeHQP3tct+f60UdmPLvU/ekD1GW6nk0rd6fJu
f/OmznjLch+tNvfpG4b96hvSx9+2r86ouy22tfNV/Yy22idjV1xRptG4NW2DbZbevmm78e3x7mfW
0/2D+J97YGoj9+b9e82D1Qxz0eX/xAA3EAAABQMCBQQBBAEEAgMBAQAAAwQFBgECBxUWERITFzYQ
FDRAICEwNVAxCCMlMiJBJjNgJEL/2gAIAQEAAQUCUzeW3C0pYZToqLaNblI2yzcU4G4ZyNwzkbin
I3FORuScjck5G5Z2N0TsVlM8FZXPxWXz6grMshUFZtkMGTvI1lD8m5GJBmYciliuacjCua8j0Hez
I4725JHe7JQ735KHfHJQ745KHfHJQ745KHfDJQ74ZKHfDJI74ZJHe/JI735JHe/JI735JHe7JI73
ZIHe7JA73ZJHe7JI725IHe3JA725IHe3JA725IHe3JA725IHe3JA725IHe3JA725IHe3JA72ZIHe
zJA72ZIHezJA72ZHHezJA715IHevI4715HHevI4715HHevI4715HHevI4715HHevI4715HHevI47
1ZHHerI4705GHejIopmbIlRTMeRBTMWQhTL0/qLctT+otyvPKi3KU5qLcnTmopkmbVFMizUMkula
8/VXcam7gtwd770ru8nIUZ88cUdXGSkLF8if0ii2VyCoUS99TlXus/LVEy59PIulcgoN4SjnbUvv
1kke3VjnCmSoX9MvvcFDya8KWaqnIrASDJu3lBtlTa6Kyp4TcrQ5Njrinnjq/tTctlKxTMSMlx5Q
WqmzYkbT560Ublk9jSV8JnCBVeqyTE0918rRHqm1eoemdxpSlbrhxHGn5cKfW4flw/Y4evD14Dh+
PEcBbUW3C0wWmAswFnAs2gLOBZg92sTJGZ8UHO3vMahsfX+9Rrb2SQrujbylfH2vunt2fLiynWRC
1xfjA4SdnWxWrrIeUx1kQYjVJzUgVmIFix6LvoW+LFpSxvSuhp0fLMvpF2AlDI2K9c6mRZs5aRJk
tSWNVnRcqIXE0iKxpKnIijYTVaytqhW+x60ltLSp0bglSNKIIWZA0XGo2ku23oNiZappfXm/a4fV
4fv8BwHD8+H423C24WmC0wFmAs4FnBKsKoXQ5HWlDUwKPJsvLvT2E86YcU4NTlnGWoybRQgodAsV
TF1FUBNa8CiikKA5edSByygpBZfQWQuYW02hMxtCaDZ0zGzpoNmTMbKmw2RNxdApzUVx9ORdjmdV
rdjOd1F2L57Udq8gDtTPxfiWfXC/DE6MHY+bVHYuaDsXNB2Mmg7FTUdi5oOxc0HYuaDsXNB2Lmg7
FzUdi5qOxc1HYyajsZNR2Mmo7GTQdjJoOxk0HYyaDsbNB2Nmg7GzQdjpoOxs0HY6aDsdNB2Omg7H
zQdj5oOx80HY+aDsfNB2Pmg7HzQdkJoOyE0HZCaDshNB2Qmg7ITQdkJoOyEzHZCZjshMx2Rmg7Iz
QdkZoOyMzHZGZjsjMx2RmY7IzMdkZoOyM0HZGZjsjNB2Rmg7JzIdlJkOykyHZWZjsvMh2XmQ7NzG
gtw7MbRbiGZ0FuJpjQWYsmVgtxhL7RbjeYUFuO5dQW4+ltBsKWDYcsGxJYNiysbGlY2PKxsiVjZE
rCxGaiOhF1LJNqJfK2T2QOdqfIbXQ1M9o1hHv7KiWT0iL2uctYGa9kydH5MCZzFlNzdLGF4GoliQ
ysqPpi5t13hNNowsPLkTWdXUSxI5QWwR5ymNG8x1yYwJEJMzjahx1CwaiWNQLGoljUCxqJY1Esai
WNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1Esai
WNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1EsaiWNRLGoljUSxqJY1Esai
WNRLGoFjUCxqJY1EsalYNSsGoljUSxqBY1AsagWNQLGoljUSxqBQ1AsaiWNRLGoljUSxqJY1Esai
WJjf1JLEv5+lOItxmltYHnHLwtNjbbc0sX/p8hjjIn5ojsvY1qWGP1p1mPJIewNEcNa5CHxsKemZ
HC3j2DLjR8ameNQdQxPIlTWe+Rg3GbCQracYPaJoiLI5uaqteP8A+Qk/85E+fXemoqKWqx0zx01F
R01I6amo5FN1lS1A5D6hQdclK3dGeO7o1QI1VjkT01A5VN1a2qKC2xTQcp9LeRTy8qq4L3dua67t
jILlMdOM6aodJSOmpHTUjpqB01A6agdNQORQORQORQORQORQORQORQORQORQORQORQORQORQORQO
RQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQOR
QORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQORQ
ORQORQORQORQJLz61D/591c0rQjapmRytziidk7hLGFtVp5nXVreBljB+rC9OhreQ3SM04T0n3Ce
qBPzGJLS72hMQnWvF5hDQcja09aEpU6xdbwXSi81PGYPdrbfDDK3P61NYokenkAtuSrFELvMOQuT
mkbKQebyt6fWpXarrwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAc
BwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwHAcBwEo/nIbTjIpLG6u
IKhi6RJYjHj2BseoM4L3nbi492a2qxqQR4r/AOPvJDmsqp6SFimhf+5cnt5G5tLNeG2ytyt/L/4J
YoMbEyg33Lk4l/8A980s5YdCnf2ccw5/vLk5Nt8lTNnUdm0i32UFK/42SEHc1rEsj6eEIU6Vu6Y6
Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6Y6
Y6Y6Y6Y6Y6Y6Y6Y6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6I6IlVOEgh1L7
pF7NYLUKmy6qNXUe0WC1sNsM9osCdsOSJzWIs++6KN14do7V6S3Y4Ovv7bGBuiPsS7kSq63aLWE8
cTIzDGw40w5tOUk9vYxQN0XQs4c4OavV9tjQXjk8u9KyeyHs1Y9kroPZrR7NaPZrR7NaPZrR7NaP
ZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7Na
PZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPZrR7NaPaLB7R
YPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7RYPaLB7
RYPaLB7RYJRbdbIGMw8p7XtxrekbZUzvBTYmMdU9GNZcNvrOO31Y2+rFWBXSlrEquu0BWNvKRt5S
Nvqht9SNvqRt9SNvqRt9SNvqRt9SNuH0G3lI26oCy5c1mszXNnZn23NhtqahYyzNGSmTS5UftubC
6OTegsj83uG3JuLo9NbaWx2bVrtqajbU1G2pqNtTUbamo21NhtmbjbM3G2ZuNszcbZm42zNxtmbj
bM3G2ZuNszcbZm42zNxtmbjbM3G2ZuNszcbZm42zNxtmbjbM3G2ZuNszcbZm42zNxtmbjbM3G2Zu
NszcbZm42zNxtmbjbM3G2ZuNszcbdmRQmKx+KdNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJ
yeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeNJyeJVbWkgZqf85kFcpQqsZN0m
iCmCXKTWWMs8WkKlumskVOTHNclvhdcny5wb12Q3dOnQTCesMejckm7pJ9ashWRI8ukEOF+T5wuZ
lWRnm2cW5Wk6FGlmuUKo2edTS5W15QyOvirnIcgqn2Q0otmccf1cawgZNZYmPlk6lMadI9/GQ/js
3KWXEmPUi1zJb7JdMHlYIRI7iXOYys2IlrJ27uTQvyfIG9AVKMoHrbTGrI9hVOH9Sp+NJfMc4TZy
iUfZcutrgwSLK0gJeiMyx4ixJm+MKV8EnKDIDP8ARlXkTRTg9zWKvz+6osYyst0/XgtYYg5PaBhj
NXUllZ0dO20ZOkqyIRRxcjodElRbYwsTLbVrbK3OEXjLuXbH2G0na0Zo6xrHFGeUNcLhzILWdosB
MKhqZUujUdc7HJmTOalBA4O12WxKK2smyob1HhMmSKYZ4c4wyHu613SXLWxRi5+KMQYwkSZ7VI0S
8i/aR1bY3G7iGuJxdipdjyBXqKU4D9f6hT8aVnkppYta4k4S5DjWDtFXyDwx+XX4zx7caTjiBJqw
yMw2EqtbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRrbKNbZRKKcZE228Hu
okEzj8ZV148qAxTevgqrrsuQnd4bVVk2bugblRzVkXZxhpbopy8gSWZJMdiYVSRKIsjU5UZrCbcj
3t71ZdW+z9iQ/NhfhwqHFVpyRKqKXEZiyHfA2uioxvcWe0wprj0tdlclvyUnoy3ZIT2LUOS29wdo
zkRK7mPJkqdpxbnNgb0LvkJuKjqSZFLHZBnyEOidCoNVo/6BT8acmmESLVl41ZeNWXjVl41ZeNWX
jVl41ZeNWXjVl41ZeNWXjVl41ZeNWXjVl41ZeNWXjVl41ZeNWXjVl41ZeJJTjIkFvB7qF2HGFxmF
936IiHgp4gVqqxokkaUSEtniv/zEjFyIsVxwmvJcYK0OYdmJI8R57hpLsYqxezGWu2Nm5zSpUxSN
N+xIfmwvw70eEh6xClakZCWdNDcrR41q5MxphfvUbfiKBtAJxuhKalkBQKnqyDtRFEmM25JV4hFr
y9nQJJY4qMesikJIdYjfG/HxrS0x1iRRhj/oFPxsh/o9TxQdtxQ+3QZYiyCbcnLmCohU6zxxa3Ka
uzm3SW+SKzJ0jyQ4rE7pks9uZHCdLkx12Tza3ti1YpRdUdUdUdUdUdUdUdUdUOv+pGNt81TrU6si
QU4yJPbyvQ4CtKVCk9Kl9FKp0lbsSud2m2rgpWMsWmzmvRXzSHFJo/MW96COVOrnKH3Icea01sxi
F7NKMgxqNR4p+aLkyPILBRqKfWQ9z/GQ/Nhfh3o43IqIqcLqTyaWR1nh2c3iUNTUvNVNTHKXyRGF
S6KqTKzuE2WnSeNpXRTJY8kSNGTYS6RpI+M6lz5LeNKUp/RqfjZKrwdnZub3tBSNMOnbcZakK46x
rgdGWU809GhUraxaN1RpIyxIr1UPjK215iBrk93xNgMususLs6tB1aDqjqjqjqjqjqjqjqjqh8t5
pBycjzT1kBBx1jSkNQIvdmRp7V6I3pmRBVrZNoydLE2zHkxZUcLgr5EpE+Rd/e5fbA5OfBJNjF5c
1rrjSUGNDtApeapc8VP5h0Lih8bWfjIfmwvw70frDTEDagVJkL8xEyZ6QYQjiJxaEBjc1RtpmEcJ
LxrKDY0844NVlERx6epSTCJWQ81xhK6s0Ki50eXf0ir40nSJ3CX7NjY2bGxWGxzhtCODaEdGzo8K
Q6ODZ0cFIfHKjZsbtFIhHKjZscGzY4NmxsbNjY2bGxs2NjZsbGzY2NmxsbNjY2bGxs2NhzL535UX
yO1PWoraJDJkl77Y/EMFrm4JWVsj0jbpIR6KZAzJWZY/NqFb+1Ifmwvw70V23GJ6UpcOArbQX/pa
w5FiciUJFRa9IzuSB9bV7uibTLlpBaoUrwFta1/pFXxnvzj1yx7y2FymXvjwzIMguKtwMzI+WMc6
lpDVDY3kIq+NvMwmaJ5Mn7mQpQ5JeD3SCy1VLEP7GRMpTKFf6hQps5310s5XT1k1xVhbcc4XIZsr
tQ5BvUGKychp1CzH6ZyeEDFIWudIH9Ixya5fjKNpDsSok8zPjCdBP1siaD585PTKlyCawJExaJL+
Uh+bC/DvSTXWWs7ae7XN5klcDXF2lahhSMjxY+tMKsXOzBGrpGWvwskfWxpoldVU0YmGYGs8lMmz
1HGijqmkdleNf6NT8Z7849XRob3pKfDo0pCaCxhG8qMeRJQ3XsDUYc5QqNO9yjH8XV1OgMUUO1If
HbbWOMtMdt/YtYGa1/FbOZ4fbeVy/wDfpeWWYL6UoH+BMb85lY4hxlla/oVWl378h+bC/DvRXz+3
py2iZLYOyPxrTFXItnaErE2cLbhZwuBlLLbKcOPJbwrbSgt5a38KUFl3Nd/RKfjPfnH101vM8K5M
xvzrT1eVK1OG5eW6ont6SJHlhW3O6KUt9XWOm0qicHrKksQRZ7yRKW4oiWZDMqoK95/pvLOfo+cV
N3C51pLpVGnImWZNVLYa8KXpn/GQ/Nhfh3pJH5pjLRjjIBk6Z/8AUZEpDM3WNu0yTtyReQ4JIOys
LQzxSYP9yZxnEte8enTuQkyaIzJdKz1WVX5C81kL+ySlryDOnyrbPJX75JNMoXpIs/yBa/f0Cn4z
35x9dRIWhkfMZ+SU/wA+jg3JXKzhaXR3hLiqdmaJaOUcnSuKVui0ZaE62HxJztvZWcwm2BwexBRn
aaIHqPMEkTKWNlW20hkPo1lROLJ0TW0tTGh/GQ/Nhfh3o/N7Q5NzO0NDKlXJPdEyjEbrIXaIsW0o
syMUKjtyWLQ+1XDMcRiKR9XFWD30YYdDRJYpF0K4uCQpIgcMaxVycdCY71zXC4cyBrjcdY1H9Ap+
M9+cfXyz5PjTyTh6uTja22knEKic6OV1zJF5QlZA/OSxpxe6ygphbKZHQnJ1uR2dvmBUskF2In+d
3xeVyDMMZiziblRBSsqlaSIsKjMbCWkmuRD0dkqcnQ16Yp+gtKJyyz3oHzI7IwXG5QREWPt1b1ML
8O9HoqhzPwoOAQkWWKsy/wC1jrC+SEiUvH65KvZp8/PjWbMr3o9yhyl3uf8AFMykj6GnMEefmpPm
dqYGSuT2WqpvyW2uD05TrQsgs0llEydIk4vj7GTphMqX2Tt4W2waTyJc6Ok1d08/jEwkbhMUjzLr
I59hT8Z784+vlnyfGnknq6IVK0IkSZvTSeByVyXR6LaY6O7CheI9fADFDfdjpFYTTHSHcNkIaLIW
RA+gnRYxQM9XDHaJdH3qHpHdKRjBhTtbjjFscFcgjCd+MZ4A0s6pvxcyo00ixYr0hVjROtZXZMUj
vhfh3o82dRo9CG9GctqwstbZrH5YmbsPo8hlO7njiGPz0lgzSjb2WMFMrobi2PmsVMZpqEk4uQIi
jcdIT3ImCtBALYkhUhNxmkoqPhrdWJ9t+KYjGEfSqY/BWyPOLaxJGtxIgzWmtTY4bU6j7Cn4z35x
9fK3lGNPJPVSrJSjjUTOZKEtLXlxYFD9JbGiJMk3WnKDp7CyG+NZTYniLLJbG25RWfQqlKyZhtem
uWR18U2zuIXoELimck35P/zIX4f6PXG9p9EXGxRk15dGKGYly0/zgqKLFKtAtlbxulpyrBnZsVzO
Kt9ZXPWmMC2XxgxVIclxdkYFkmqiUmT5aoud5Y8sEYMkLSVHWmQyQ0WzaGXnlSmMqHKPZHZpJGDZ
LH0rgzyFgkNjNMyXeT1yFHzJOVNYaobL8kwq18smcPMCRWlXpfpqfjPfnH18reUY28k9X0k0+1qS
KECG8pCzv9IwmaA8RlSqx894wSHQ6NQZxQPiCESZhbu17omaXjHF62h8IlqubJsVOFsdfonMZMyR
dsuaGP8AJ/8Alwvw/wBHqnO0+lG++xQ+Ri1/a6w1Nj2N42cHk5NN42/yZSdDZxa3JMTupMee4DKV
ahzxvM3ldL4FI3IiTsTg6Re+HOrUmZMWPyMtogqsiBu+O5XJT5ZAJU+OEKjrw7Le0ruVFGqOSNif
YSyytgZ2jGMiZr0GPJ6ltWQ2QRw5pgskbHRow89omD6in4z35x9fKvlGN/I/XhQH1oUQpQlLC0a9
O12ujgnZ21hmTJI1FLL63dehi2tDa1e5A0x+rjImtoca0vpXkqP94f7w6hxdfwf/AJcL8P8ARamo
tR+h01U3kNLkQ8NqTIEFkxZsjhzC2sUzYZGpWTCOoUqjIkZS2tbmgfECHIEZcXciexVa6M8iZ5BS
OSRmlTbY7N5jsQrKUG/fU/Ge/OPr5U8oxv5H+Cv4kvld6gJlRzEJWrPf8YuKl+kYjqqSMjU4p5w1
CW1cj0s2aD5M2eylbo8tZs7WInjcLUmfXKTJ4YXdLTci4ySrUkK/B/8Alwvw/wBJDyUbG1S73tzn
Pi0DgW6NDU3Q8wk+NwktW7sVY2+Wx4x3NWr1TWdDVzzIU+7oq0SpG3sEfem91SagbEG9hk7bWONT
2y47050OVKKSqOOMha50gf4HcvslH3VPxnvzj6+U/J8c+R+hxpZBRUsa77CnNncKuWKm9zcTMQID
DG+O2tyDSrq00u+go01oNJqKNV1BRprQaTUaXfSj3j1nkZuk1BbfW0z8JB8yF+H+imytyfktDtBG
91cVUPa3A6G2Nlke5LRyWjktHJbx5bRyWc3JaOS0clooXZT+iU/Ge/OPr5S8nx15GJflxAwyuX0p
WN6I5OREUZ5WXOMnMRK69umEnbwpmc3Tq1GVn1C9O2SphG6Q1dKF7P8AuSH5sL8O9Hc9SnRIHexW
jPlhNVcnXTJNIcXJ16aBxpio34hbpxJVboiylM7YtbO5a3n7wVlwtXI5YwyciYLI89qJ/kkx7kz2
+FPrjNpQmdU83nCldBJLOaszxNZK9wG+VvUYXkyzJqpbDXhS9M/21Pxnvzj6+UvJsdeQ0Gz4lqss
aVL4w0Z53xjMAeG2WP7DFHmlWuHuSxDG482JaRVgSqIfjJBHgzsTHHUn7kh+bC/DvR2JTnoCLLSC
5TEWpze5DhN6cVULYDIvGdIarW+2Ox9O7NmLWVpgiiEpkkeRIyEqNDC4e1kKGRmVFvEXjMiMeWBi
kiW+Lxo10tZ2iwN8ajrReniUUSXLI1HHBKVE4snRNbS1MaH7an4z35x9fKXk2O/IaevCgupaHmaq
2NYbkg92vfnl4bsYK3uQQ+sgyGZcyRiSlSVDDchSVdjZkyymaYw35LbXB6R5hjay5wzJHWdvvzRH
apVGWWFuRIsyMjqnjeRVEnl/rIfmwvw70c1fsUiRWSsInqV4PF77JSjY6pcVLKly2qU48snbUda2
5cSOhS3LUbRWoMkty16epkqi80XZScvemZvh9jm2TWRvM9Z8wRx+apBmGMxZxlhj4smN2Y0MTY0k
+ZnJKx5ASuCMzOUHLdmN0NeW37Sn4z35x9fKHkuPPIqelw4i66tBIt3nOrO1yGr0/M6eQMdmOEB6
J2xk2PiyPRdFGCmnHMdZzS8Qsiey2As1pZmLm9lYYzjtzcUh8ARLSXfHjK9XoYh0HGP4+boys9ZD
82F+HejwkPWIUjSjJSv2JWh4kl7BI3JZjchxTw8uDttsRsx0go9s8FaWahOJWhPYRB2okO2PW96e
1+P25e4G45T1IXQRmda24zR9A+DGXuMjiGvOajHTXQsmHNxcjb8boWYJIPe1qYpF0URa/tKfjPfn
H18oeS498iBask0+vG61yskN11P0tkcndG51MkrGncmyWRh5qnlbTRLfMYiVRDIo+6L7ZbFL1SWW
RVcmi8wQSxUzzMl2kyWZRBaHafMSVqvlrK2th8yiKVZF58yTFIimcPckNZzCaM9l9htkh+bC/DvR
xuRURWVpwcHlrQ37naRco6yNmyZK5EShnznIHaXSMyNNMomjw0sr/NlUWROrxc3nt0z1N9jMplbw
9pslFnsK3J0jbE7w/MkdRmymMEOl01h1iuP5KhMjZ3WfxxK0Ip61XC6XxOyrS9M7+i+yp+M9+cfX
yf5Jj3yKv6UvbFih541FhSBQRFFxp0sn7I6yJvTY3eW6Vk42eEsUXQJ7tdpHAJC+ySIsMiZnhyxj
NHhxe8cuipREo/I2g1nxnImO9qjzwdhuyAyN5RJ4PKWRethMuc56TiySLI44Y/kslTvkFklViWw8
tNIfmwvw70frDTEDYgVpkKpFKGuRT/JLo0LoCvUOWP4zEciRmluMlDVIpJF3eRvhUGfE8IfII7yO
QxVhkjeWz43kTIafGpATYuxQ+ko3jG96WLSdkfjX5wg8kVuqLHjgkvicCf2y4vGMpOjT7i5+XmIM
cqSKQ9FI0DN9lT8Z784+vk7yXH3kVP8APLQVstuFkXjRYLSpirq2W1HJaOWlBSlKfvyH5sL8O9Fd
txif/wBKVaNHS9VGFl1Cyyw2y5gdvQl3bzHWn6C+2lbXJ0Rs7cnMtNKpS2o/T+jU/Ge/OPr5O8lx
/wCQU/z9aQ/Nhfh3pJrrLWdtPdat8yfnNqdt3GUpGKrD4/BmyaQ+CMip+jTJImd5bndxtk1ZKvPn
Sh4njS4ktUetXkz639f6RT8Z784+vk3ySA+QU/z9aQ/Nhfh3or5/b2UsoHFcQ3EsWTGB8Wf4HH9F
rI3O6mhdtByU4dOwX8LaU/7dTlFt3Gv9Ep+M9+cfXyX5NAfIPryD5sK8N9Hs5SSjRPHukmX3FVt9
9h6CEygz9aQBUrT4/hktvjcTlksyBHlMskz+2sl2TpyuZpxI3t6JlT/IE706SCUSRGuyBLYk3Ncp
yMe8TOaSlpfVU+k1VyCVShS4WzCUPJSmeS9MuJnsmNfcuP71c1JZpPnCTuM9WPDLWbSG1lJmGVaR
5EosVo/qqfjPfnH18neSwL+f+vIPmwnw30eCU56MggkkuTtvulsgaZBLii7ij7E7U2JKWx5htJMg
UHOaV8ajrog25HuiqiMUWrXiOx+Qp1UZjbgeeys6qjVFoww0XQFjdpafG46qeCWdoTnXxGKGi5lZ
r7aY5605dovGn85TFIstc9EZejbGo5Y8dtMc0S0pSlPqqfjPfnH18mW8ZJAv5/68g+bCfDfR0V3I
SEq0lWT/AKonB0b3fHkyY3GEx02+rDD8hSVdjqNZSPKiZ+UWol0SZDc91k5Ya6oG2eWuzzb+tP6R
T8Z784+vkazmkUD/AJ/68g+bCfDfR4SnrEiRpREpMgYoiMtNZ8PRyxU1t+mtrPjyPs99uKmklEog
TQpsT4+bUzgVi5qtbnCEpHN3L/x/SKfjPfnH18gU/wCfgfkH15B82E+G+jjehsS2VtupPJ02Q1Pf
KH5pdGo849rZssFO8Kf8iw+NEoZZGXBud5VGWNNJpsxR1tb3hCvuSTKLL0zbkuMqbVkwiTeG/IkP
cXMuZQ84hnkLBIbPvqfjPfnH155bxfYJ/P8A15B82E+G+j+WYagbW5WkbstRFolLZjlOzL7S7Sei
oxe87Xrip6rV2x49SI0mHSxpOLxc5J2iFR5xjLQjxjM7i9jT0y1LCZEldHvGsgXpWGAOCN3gDJI2
FB9av+Kf4/NT8Z784+vPf5uDU/5/68g+bCfDfRUXeaXbbbyyi1usvjTfHlJlLbSrU0/jCtyukTIV
fWvMONKUXOza3Gf+PGqsuh5X+P6NT8Z784+l/wC/wyDXg8wb+f8AryD5sJ8N9JtI1kXYsSuM5cI5
JzDqqSbXgxRHXA93Yk1rgZEmyHm0D0knmlwpE8Xvt6N4VzKKJp3YgV25Bqa86ibDmbWE0i/olPxn
vzj6X+K/hkW7/nIP5B9eQfNhPhvo4HXJ0dtltRMoKimVrNjdAiu6KRobtbTdalKVpXhzW8tR07OX
koDf9u0r/r9q3/H7Cn4z35x9aoyNX/5BB/5768g+bCfDfR6pzNln/Uz/AClVFJ1jo6EHMy9UYkUx
WVHO92TFJSJ3KmUtMnEFnUuelTjO5Wne3KSvrrFX59dW9CyzWYNjekmT+pcoTK3+QpohNZpJpTKD
ZM7ZPxonJSPX0/1qKcOH7Cn4z35x9aoyP5DB/wCe+vIPmwnw30fLeo023foqVJkpRb4ymnPBKpQ3
N0Cm9S4jFHFjXaW21vNh0SPXFsjQlvQwBhKkxsRih7g4sbK8t6uGQ9e3ENDSlPVQ+JLS7YtGC3sI
WNla1X0+H7Sn4z35x9fI3kUJ/nfryD5sJ8N9HVVVEmSrSFhMia+eVK0tym6PEWoWHHuSDzEpmTkS
NEmyq4EGyKROCCKEmSKRunPKpI8suRZAul8Mlb4/z8+dPReQJHJ3WyBZOk1zI/L1M4WpGRe4EyP6
vLUcK/sKfjPfnH07fwyN5FCv5768g+bCfDfR4SnrEiVpRkpTkRNyOMsy8uR05eRJDmlPDu3CJQQo
hXUWnQpKnhauG3rVzjBiFi9RjmOHktMUamdyccUtLmndYhrUXQxL27k7MSR5UtTOsJkH3lPxnvzj
6VP+34ZG8ihf899eQfNhPhvo43obEv8A4GWyy+RO2VJKbM4mhijurfI1FMlqniw6cQ0ixTIWNA40
mkPuLtl0WNUJpfFFVxE0h56m2vGn9Gp+M9+cfSp/2/DIvkMM/nvryD5sJ8N9H8sw1A2t6pIgnkjs
ieXZHLkksb8fUv2M04mIaccvcIfjVTTHpAwyBixa9sjKijM6Ld7MbSU2NmxiQJ5MVzcP6NT8Z784
+lT/AD+GRPI4b/O/XkHzYT4b6KrDDS7bacD06K29rWN7i4mX9IMUtZpEZZdWotttoHNxRM6Au8s0
tYrKTFrHVubDLP8AHq2Oze8k/lesSFqg5S2PtCv93jUc145rhx/JT8Z784+lbT9fwyDTjJId/O/X
kHzYT4b6Sa4uxrbT3e5BlNDKlK/GT8c8uJ/AWGyMlmKUPbcW1oJFJnF/slTpDWxQieWi7fq5lqje
FUwYS8g2x+A+7LTNncBahXI31orEUkjQ4wKdVpZ0aZpc9Ub0WR0bNiYt0Ka01Xy6Fltz64hpYnIm
XIkD0ijq9lmCm1SXkD31iJczzP6in4z35x9ed2c8lh/879eQfNhPhvotpdUqyywH3WE2R4mMmv11
3MOezmLpStnLaOS2oIQIkhfLbQVpZUU/BQTYpIYImyRmv3lPxnvzj68sK6spiH879eQfNhPhvo9H
qU6RG82qUeRJU8Vk0qZ0rTIkipcpa3FO4QxqWTWWpnA2eTC5sUZTlamLop7NnWbLnuQLZignEjUu
jjP8hLoOsmswYKyp7kZzYll8rZbayvI642NOdHlh+8p+M9+cfSp/3/B4I60qiP8AOfXkHzYT4b6P
BKc9GnIKJKkMdaZO2QnEugOvLS6iWCwtAk2lFbV62LRlyRznG5crKMicVWr3SNR19NKjUcIeLGBi
LKbo+ws9iCIxNqROERijujUROLK0CRIlQJfvKfjPfnH0v/8AX4KCeeSxH+c+vIPmwnw30dFdyEhK
uIVk5RlK4pkguUXRUzx8w7QYlMFia0/IyOjwlzIWgjt+Y2CqePTMh+XOuQlJ0iYs5RKRnKJ8zpnZ
4yk3RxhYcmtEncP6FT8Z784+lSn/AJfhUvi+RP8AnPryD5sJ8N9HhKesSJWpGSjURaxwfbcSsFzu
ibSG9A9wpUmbVWPELgxm45RXWHQRGuJRR9CkerMdNxbwhx6lRM3bmOHJzcf3KW02C+9cv6FT8Z78
4+lSn40t/wCVif8AOfXkHzYT4b6KCSVBRR6c8PFzOjh0fdYWtkdWtkpajkrOsZqvsDVpizIpcmtd
8dG22PGOlak6SQs+i9xK3RVzx8WuseYRcC3mKq3pbKLEj/bWIXBpUwh/stdce3mUescXNd8vxpa9
GSTF5KF+lLEzONznj8tcS944UKWPhYKfWU/Ge/OPr2/yUU/m/ryD5sJ8N9JqnlixhxXBXyERuRNi
92x9iVmeV02vUXcrJE5IlrXGrtSMpomvKkrTix1QMS9gmVXhggj6hXTJif5IpNxo83WvMTkl6mIQ
h3YV7hAHZXMrYfKLXOEtUgZ24qJSnZdsOeV7o1Q9+Z3huhskjzf22dSU5uMnnhcwv6aTMFeNbfrK
fjPfnH1zVthLzFf5v68g+bCfDfStKVHLQGsLZdczxRlTGXR9spV3M9ofobZwJNjJz+obmRNV0QsT
Q3OztDmSxvdYY6B6dIXGjzXKFkPZcngpxTfKMcOZly+HWvkbfoJLDjn+Bp39W6wpE6tKyGvTZawt
d9q9LHWw5wdoO2XLZZjtvMvWMzCETq3rld6sqxX6pHdvXK6SyP3MAPWJEt72/tMdTNLsjekQJWJF
BoRS2PuC781Pxnvzj68vX3o5JF/5v68g+bCfDfwurwCWqwtYQocbr8gLLG+Vw8lSih0311RLXiMK
yXVxQzNYY/tzksbz29U3IMqNziqeDZCW6zVtcXtFa+kERElaapbp3h5A8EKC4e/PkxjLrdEziWpW
/YkdC19CpsU4FJb0qVYHuyYOiqbFLCktzY+Pjmja5yrElNnb3HUbVIVQkaqWqYZC0riU9ooTKycV
ttsjrKCmhSuSyyqholEuc7nlU4s8+XNypjd0q5xRvqWTaPM0yhgbJGuSU/Sn4qfjPfnH18geRRj+
b+vIPmwnw38Lq8A22cD604CUN8XWSS3/ABfS3m5rbRWlgvRI71NyBCpPpSlP6RT8Z784+vkHyKM/
zX15B82E+G/hfWtKpVRSdYS5kq75lOXpM/RJYqcYqYpTJMns7QQ0ReKoSUMwyk0kOc1WziRp3Qia
y9aqQKHxZ/pwclczNcpLPXN7x7Cn1/PdPvqfjPfnH154lvMfI1/M/Xf/AJkL8P8AwrSlRy0HLQTD
CbXJ5kSQUnJeIzHJEFcWjLg5o4jFW50vbkBhtsOiVi0mNR1M8JY7H0LeahRHgmEwxMa0R9gj9v31
Pxnvzj67m3WLXCOfzOr2DVraV3DW4zXVI11SNdUjXVI11SNdUjXVI1xYNeWDXVI11SNdUjXVI11S
NdUjXVI15UEr4UqK1WwUcONXkzrKIX4f/ZKfjPfnH16fyMd/mHo15KaIhY52RoldVGfro10a6NdG
ujXRrokq89aytZjmS+66NdGujXRro10a6Kvv6Md3Ogp/nF25tmO3/wB8L8P/ALJT8Z784+vT+RZz
yUi/e8QG+IgFz3F1J+pR0alHRqUdGpR0alHRqUdGpR0Uc49aNXYhqUdGpR0alHRqUdGpR0alHRqU
dGox0NsviaJFvyIjfkRBkhY3Y6PvbQ1MO62Abrj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG6
4+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8b
rj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj4OlDA
YU5r2pVJ91x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64+N1x8brj43XHxuuPjdcfG64
+N1x8brj43XHxuuPjdcfCc8hStgP6SXrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGj
rGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjr
GjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrGjrG
jrGjrGjrGjrGjrGjrGi847n6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xo6xosOO5+
saOsaOsaOsaOsaOsaOsaOsaOsaDzzqE3fq7QPyL/APEGf9/oF/8Af9lR/wDRd/KxBTYgdt8Rwb4j
g3vHhveOje0eG9o8N6x8b1j43rHxvSPjekeG9GAb0YBvJhG8mAbwYRvJiG8mIbwYhvBjG8GMbwYx
u9jG72MbvYxu9kG7mQbuZBu5kG7mQbtZBu1kG7WQbtZBu5lG7GUbuZRu5lG7GUbsZRutlG7WUbtZ
Bu5jG7mMbuYxu9iG8GMbvYxu9jG8GMbwYxvBjG8mIbyYhvBhG8mAbyYRvJhG8mEb0YBvRgG8mEby
YRvRgG9GAbyj43lHxWaMFBfPoyUO5ESFMjROovyHFb7qZEitRTIUXqKZAjFRv2NDfkbqN9xob6jY
31GxviOVG9o9Ub0YKjeTCN4sI3kxDd7EN3MYtljLS7d7GN4MQrNI9aN8xsb6jYtm0duFspZ7xuVq
G5WoGyJrvLLM9wrTZCab7O40KHcSFDuRCx3IhI7kwkdy4SO5cJHcyFDuZCx3PhQ7nQodz4WKZRhY
7pQsd04YO6cMHdeFjutCx3Xhg7rwwd14aO7MMHdiGDuxDB3Yhg7rQ8d2ocO7MRHdiIjuvER3YiA7
sRAd2YiO7EQHdqJDu1Eh3ZiI7sxEUy1Eh3didB3eiQrlyJDuzEB3ZiA7sQ8d2IgO7UNHdmGjuxDB
3Zho7swwd14YO6sOHdWGjutDR3Thg7pw0d0oWO6ULHdKGDujCx3RhY7pQwd0oYO6MKqO6ULHdCFD
uhCwbk6FXUdp1Bld+5YHxskkFpS2WQSgJlcJvpbNIKC5xBxbNoZeKTqFUG+4by0n8LFMgwyotyPC
eNuTITQW5QhdBTKUNFMqwwUytDBTK8NFMsQ0d24aO7MOF2WIaD8mws6vcKFDuFCg15HhdDk2YYmR
Z3qig71RMd6ooHPMpRyf/8QAXREAAgECAwIGCgoOBwUHBQAAAQIDBBEAEiEFExQiMUFRYQYWMlJV
cYGRodIQFSNAQpOisdHwByQwMzU2U1RidIKzweFDcnOSlKOyIDS0wvElREVQY4PiF2R1ldT/2gAI
AQMBAT8BhqNpTQ74SuFv9ebAnqz/AE7+cfRjNtH8q/1t1YzbR/Kv6OrEr7Ti5ZX9HV1YDVpg3/CH
t4/5Yz7U/Kv6Pr9evG82p+Wk9H0fXzY321vy8nnH1+tsVdTtin/7xKPKPoxLt7bC8lVL6Pox2ybX
/OpfR1dWO2bbH51L8n6MdsO2vzub0dX6OO2HbX55N6Or9HHt/tnwhUedfVx2wbZ8IVHnX1cdsO2P
CFR51+jHbDtjwjUecerjth2z4QqPOPVx2wba8I1HnX1cdsG2vCNR519XHbDtrwhUedfVx2w7a8I1
HnX1cdsG2vCNR519XHbDtnwhUecerjtg214RqPOvq47YNteEajzr6uO2DbXhGo86+rjtg214RqPO
vq47YdteEajzr6uO2HbPhGo86+rjth214QqfOv0Y7Yts+Eajzr6uO2LbXhCo/vL6uO2LbXhGo84+
jHbFtvwjUedfVx2xba8I1HnHq47Yts+Eajzr6uO2fbP53N8nq6sds22PzqX0fRjtk2v+cy+jq6sd
se1vzmT0fRjth2p+cSejq6sUu1Zn4JE0jF37pjbXx6YmqqiHlrUPm6sUW0Wn4XvWK5O5tbTxY7EY
Y9rdkw2XI6vDuc95XBi5af4SXvbeMOTpx/8ATzZC0FXUE7NQw0s82e1TUMm7iZ8wp4ozJOVtfcpx
5e4TjMMdhnYtFt72w9s6KjoXpkpWghno6yk3scqk8JWZ1aN95Ye5CzC+ZQE0x9k7sdp+xzYnDKA0
yS8LhjDU7MzWLre4ZQMpGh8dsUktctORAmYX6L4y1/eejxY/7R7043+1vyXo8WD7YnlUnx6/Xlxf
a9su64vRbTm5sZtr/kz5vFiZtsc0XmHTz/Xq58W29+R+TioTb84tub/s/Ng7D2qf+4zH+91Y9otq
/mEvp6se0O1PB8vp6vr9Tj2i2r+YTfK6se0W1fzCb5XVjtf234Pm/wAv18dr22vB8/yPXx2vba8H
zf5fr47XtteD5/kevjte214Pn+R6+O17bXg6f/L9fHa9tzwdP8j18dr22/B0/wAj18dr+2/B0/yP
Wx2vbb8HT/I9fHa7tvwfN8j1sDsd234Pn+R1fp47Xtt+Dp/kevjte254On+R6+O13bfg6f5Hr47X
dt+Dp/kevjtd234On+R6+O13bfg6f5Hr47Xdt+Dp/kevjtd234On/wAv18dru2/Bs/8Al+vjtd25
4Nn/AMv18dru3PBs/wDl+vjtd254Nn+R6+O13av5hN8rHtFtT8wl8zdWPaPan5jN8rqx7RbV/MJv
ldWPafbP5E+bxYp6Tb0NvtfUchy6jxdGDFtw8tPfxoPowItrD+itfl4vL4+nFBVdkmzJ+E0NOaaf
Lk3iU0JbKSjW4wYcqqeTmwvZn9kRe5rqseKCn9THbr9kU8tfW/FQ+pjbW3OynadNu9s1E8lMrq3H
SNBm0yg5AC2tjl11AbmBGxWUU3H5OEx35e54l+Ty4EkOaa6jLlO76zbTxeXAkNxdPm6sbxe9xnjM
qaALvFJa17De1TXtz2V49PEPg4eWbeyWdGjscvFtfqGmmI5FyNdQsmU5b68bm9ODJOfhx2/qfyxD
I+9j3sq7vOufinub8bm6MLKpaFQLMaSjDG3JUmsAqFP9Wn49xcMNAxOmGmqBUyIJhkHJofoxvJ/y
y/3T9GN5P+WX+6foxvJ/yy/3T9GN5P8All/un6MZ5fyqHqy8voxvWxvWxvWxvWxvWxvWxvWxvWxv
WxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxvWxv36T58b5+n043z9Ppxv36T58b043zY3r
Y3rY3rY3rY3rY2q5enjB5OEJ/olxRVMFLs+aeolSGKOVGd3NgosuvSeTmBxRbc2RtFstDX09S3Ja
NjceO4FvLgqRyjDEIAzaAsqD+s3IPLgI7Vo2eqk1jR70QgXO7tfNm+9jTmLX6sWOvUxU9TLyjyez
0A6XxNXtTyrEiB2a9v2bXPkviOYzRrII9WNmPRbQ8vLbqv7HXhZUckK1yozEa8mYLf8AvMBi4xcf
W+LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62Lj
vF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V62LjvF+V
62LjvF+V62LjvF+V62L/AKC/K9bH7C+dvWx+wvnb1sfsL529bH7C+dvWx+wvnb1sfsL529bH7C+d
vWx+wvnb1sfsL529bH7C+dvWx+wvnb1sfsL529bG1D7jELAfbC8l+8k6SenCbOptr7IqNnVUZMVS
9mlUaxgIvPzXvjsf7A9k9jrB6EZrkF5HAu9tV157XOCkjOxIsumXrw8T3S6q8QbNICLm4tlK9BGv
JilrtmwGSeCmkNc0axvUVIzSBRyLDI/GC9IBt3OJIpZZJLDJvWzLbTX4R8eowsDLxG1I6T04eKcI
xh3fWX/hfG7nKIZsl9cu7AvzXvit2c9RlaK6yLfjLo2tucWOKamkhgSJmYsL6k63OODyJqxJzajq
+t8LETe/pxwcLfLGuZhYsMoNrg2udbEgEjpAPNjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3
vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+
99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv3vpX6cbl+99K/Tjcv
3vpX6cbpui3it/DG6PXjdHrxuj143R68bo9eN0evG6PXjdHrxuj143R68bo9eN0evG2FK08XL/vK
/upcbENqKa7FV3nG1/QXFLUyz545Y92qfeiBbNrzdOmvJjK5sMz8oA1POQOnADd3mNgM3L+iz/8A
Ifm6Ri7OGLvxYY5ZWZ2OVI4VzStz2yoCTlve1gL6YUMxk1YSQxU0zB2MeRKmngrGzu5Ai3FFMtRO
WsihWQvnVrCN3IyBpN4qSRalZHSfaEOz6NZFcru56iaogujExQkyh5ykTSGOPhDRRpxzOKdornRk
qZuDI3GtlyVg4JMj5ZYpw2aPdq8gUAxRyoM0UkJnQrcAwj2wIezZdHg2TtCpTphpuaWemimylVqW
W7Cmiq5WKXyutJQSV+aNjZXjlSIwrIpISc7uUI2mN3cg3sMtyzE8UjOXNhmOVYwrXHHYl13fFVpJ
Myq2fNeOBqjIWu26FU9GhXjZbzTwzLGubN7kTIEzxbyoh4NUVFPmzbieWHPbLm3UjJmtdrXte1zb
kucE21ON6MKhzIPytwv909OIwxEBvfLSSM1/hWI4zd83LZjc9eBIDp72kG6aBWt9sU81UraBVjhq
FpjvGawV3lcLGouX0HdMitIRETn0tvcxIsBuqOjr2AzWMhNJWLMBEHIjhqHfKiBnayNkawbeSRAH
4TwtKkoXvhFJDLFKy3WOVDE5Ell+47e/3WH9aT9zPjYahqSRSLgy8n7CY3drcthydXixknC5st4x
a79HRri9h1fw1HzEjynpwMxePIeM8kUKWNi0k8qRRID0ySuiKOdioxTpv5YIIigao3aQ8yPxIRCF
IBGXcy0jJbiimqKSXSnngd4XeZIpo1k90ijkj0JfdtPFwdbIWIeSomp2p4fvrzTRGOMyOuDayqGU
iRIJ0aMg3jgYinZZU4yILMqLmUSRZ1yvEWGOkcxzXHTm3ua/9bfz5unfS3++Pc65ydTLm3l/6TOu
R8/fZl4rZr3XQ6YudNTpkI10zRM7xvbkzozsVk7saDNZVtYWy/B43F5uOyO2nJxnjjdulkRjqotc
kkkkkkkk6kknUk85OGGYEcl8CnS/dk9Xmw1TkdVJ5O5vyjxfX58Duc45AAlukOwAS3QWPJ6MZVAB
AXW3Ja4BkyfvbrggqLm+mGGTKT8Pkx5CeoAsT1BRck9AAJPIMEhZHiJG8j7tOUropBNuRXDXjfuZ
bPuy27fL7wkfdxvIRcIjPbpygm3owdtRtmzQuwdonYMVKs0MPB4WKkWvFE2VNOKbOLSAMG2vC4s8
Mjgqy8Z7nj0sFExudQzUkEVMzg5zCGQtaSXO22IWN2hcku0hN14zvPUVJLd99sVlTMM1wskzstic
e3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMe3MX5F/OMbTrF
q6VcqMu7qob3IN88NT0f1cbB/wB1f+1/5Exfp1HXiGrePZ7ULIru0ocztrKEGay5zrls3Je3VrpC
N/nI5I9W6DhcysjRZldHjePd3DCRGVktl17tRpyN3JBDEYRjEKaoQ5RFJAlLIpHFd6VVg3f6LU2x
URX7i1EqZs9gyho7RR3QRCOnGQ2VCsymGPeLxeERT0sZi43CIJIIshQpHZIjK9PEijMm8hp0GVFQ
M8UcwHcogDxwJKxsE3cSOwWNQEO8hSdLmKRo0RrHVpYJ6pOKRmAMFNPISwAUR2YhioP8j5GUOp/a
RlYdKsGGhHs/z9hhcebny845xqPqMbSo/wDt+l2mNv7ShpY7KdjxUFPLs6paxBWadoy8d73zqwcE
d1gHiIR3L2IHNzEG3UeQ82Orm09DmQeZyXHQ5LcuuDduL3xA6eUgYzaBW1sMy5tbe6mDTo1XyY8p
HWCVI6wwsQegggjlGDq2bnGewGirvMmfKgsig7tNFA7kAe8avWkqFHLu28duQjy4imgaKlz2tGJM
ykDKzk2zn9PLxc1r5dL20wJaSN5MyvIrsCuXkAHVydf/AFwJ6feq8cdkCkOrjQknoN+bTAlpM0jT
q12K5MnIFAy2+YDoAAGmI2oZG4gIAGofn6LXPRiTd523fJ/L2b4viJ4ULb2Iy3WygSGPKT8LuGuR
8HmHODpbQ00n6zT/ALqsxsb73KObeH5k9jn+vJiNtZWjbKqayBbgN05rcvlwhPdjksb6kaEZdGUq
yNrxXRlkjazxsrhSGGcSqeSeqjrJLALmqYuFZZDlA1+234vcBI4IlVYYUjDNdmmJsyLCpfkEUe9y
KmvECyzzBA0gLgtFTQPHDHTwx71xJHKLbyKNI0bKNBHXrtOM25MwrAZWP9LmKziRVjCRsYoo4UJE
cRgaMXIKmnp6imjOZSrE5aqZ2JJLuVVvcUSJVUIqoLBUVUUBVUAKAosqBUUWHIqqo5gBp7P8/Zlp
4XXjRRtY3F1Bsb8o68aLGmg4vIPJp9GFO7N7Zr8l9egfMSfJfBZjZ8gAWzmwHwLMfmwRmIPVl8m8
4R87395kAgggEEWIPOOjHA6S1uDQW6N0n0Yjo6fOQsEQGQ6CNeXzYNLT+4xGGItIrMLxreynL0fp
D0Y4HArshgi4qE/e15jl6P0TiKjgeNW3EV9dd2t+XxYFFTB8gp4QzC/3tObyY4NTXK7iK66H3NPo
xwWl/N4D44kPzrjglL+bU/xMfq44JS/m1P8AEx+rjglL+bU/xMfq42nDFHTru4o47zpfIire0ctr
5QL2ubeM42WBu5f6/wDBfYvbmJ6hynxYp9zDQ18XB231VGVikcZijEqbhjqul+TGu6WNo1Itxr5h
rbitdGRro1nWzd0Be40wWJD6nMyUwD9yySU2zqyhjlQRhEVt9VrtTioD7YxCcN96WHSyCwtHNPIg
tpu6izSxsvcsXkho5nlsG3tKCgRZZFMhztUtbLwmeedrX0E4jTcrzLDDCJ6eBECZI5kkOarpaapj
bjPI51LyNJrqbskSNfkTMwhQuYo4ldhnZDJmdvZ/n7MrRAEGS0h7lc3KfFfFwEW4BGnNcc38sNdr
MvNqBzdA9GDKWgeHLYuMt+Q69f8ADDA2jy6ZbZsumbiheNbl0sNeYW5veo01Gh6sc4bnUEKedQbX
APMDYXt0DFze9zc899ddT5zgEgWBIHQNBi5uGucw5DfUeI8uOk855T0+P/Z2j95X+1H+h8djVc9f
RzyyKFYTHkFuLlUfOD7B8v7PL5MUu3o5556OejePdw2idvhPbuv+mDLeCUJpvoK2nBsCL1NJNTKW
BuGVGlDFSCCARbXF0EwKLaEPUWV/dGEJqUlokfM3ur0yiVZJc8bVUciU8+8EJmmjcxuja8R5XtnJ
7qQtGgICMBEM2V7mYrKIXkcUsUsl1EUkQFt4kQzZVsjx7Toa/MYwAk/+6yEGWzFpRExMYLEsDawy
e4olvvuV/bSKpdyz2ae+zVOz1LGJlsZtZKh2hUEAgm/HkK3OZshkYxh2soZwhUOVSNC4JjiiTLGv
sfz9gaHFXQzSyiaO/FYNy4BXJHnsGUqWXmNrXBH/AFxnsthobKNOpWHzkHyDDHRDhDZlvqMwuOY6
8hwJIhLCWi3iLLA0kedo88atmdM6cbjKDpazcjGxwQ26jXPeREiDPYIJJRXVc08zBeMqSUksEEdO
rZYnhjvLJEkiVXvzsnrJKLZm9iF2eohi8QbMxPybeXHYb+B1POZWBPORkj0J5+U+f2auqglVAaev
pq5TT00U8WaankDVEzTySoroONEsI3jZjFmIXiZsxyZKcKFDIu1swIIQzTU9EdmtNkszwR1NPMJc
l5Y0mfdD3RiGtllK5r5ZzTBsufR2al4X/RtO2WGKpWnyU+4kqZYpBURQRyEpupEsuaXKFksfcTFV
U1UHYDIzpNHDLSskcsbusrRtJFE7SqMpsNUB4CLsN4yLwCqNexCtEsk3tjwYRRjdwtTBfdUeSVoI
sjLCJi0ZMFOJihDlZX2hTiqZSUUNJDs0VLQkRiF5mjzRGxQxsbccIrbhc1hdd8ReRUJEhAeO0QkY
M0NS8s0d4o4AYtxnTebzdcLXOB9+4Iasvc3eRBLwVitQqSFFkWMUfFDs0fJHvSATu1cqC5DDZ0S1
EmTPHmQ7R30lNHmjZ13ayvBHmOI827TOLPlGcXDWa3GGYKgaxvqEUHlCryezc9JxtKmqJd3PSyT7
+LiJTwq8nCGlYRgMiOM2XNccRytrjoxRlngBqoJYZbbt4nV4pbb1UmvvY45YXkp96YZN3nhmaGUB
smvKKYyWLJSUscwjG7U1aVFe00oW9snB2pEN2ZmOXRyrvh8pkd00ztUSAG4jBWhjjpYmRe4RqtS8
ppxHm40mWMylElyl5mjBCs+0JIxZc4EtY8lGFAyxQyRQsEESrJS8H0zRSxqkkuT7dWO5STJwU9y8
eTbocKGsSA2xoITKTxpJp6qHMsbqkblWmuCqg7RqZlkWP3JKF6iuZIGpySCfdaOWMWk3MNOaYSKr
shPGW5SzNT1qPEkrAZpp95Cqy2DLIrSSBapQjQUixCJFaNaPDFTwwBbGZckbXOUNuY4zKijK8KZ1
YqsD08rffs1PLK6LUZXmrGjHuUtRVvDGvEIjknreCKGBXdCGN4t4IwqCGWACCeo2eTU++OzfTYMh
/wDvKH/iUHzaY7C/wMP7d/8ARH7A5+jKSe+/Z5/Nijl2DVbPXPWtsysplq7JUUpqBtE8FqJEVWKS
MjRTxUyLcAMKl2MqCMKwKMKYhsxbeZjyZhuKVwSnNaR5VGmliObEYDDjNbjtz8o0+vlOHVAyZWve
9/JY+TKLydeXJ8LC9045hbyaX+ULSfo5938DEmhS2OYf7dRDPLNTmKSREXPvAjsoa+W2YAgG2tr4
vYSC2ZkS4HOWFivjzMAh6QxHPhrZiF7nPU2/qpWVEcethyxIh0voRz6ABT3TZRnhF+TR5o0f+6jM
3kvy4AF6TW+eLNINe6MFO7XB7yR5EH9XTCWyZiSxEjrkuQSrRSIkmbduGWGoNPniDRyNG7OrbuKc
iBVbgsc0mT7ZeCrqAvIqVFHCksaXYCCdDXT5wsvESHeNSZg8gzcG37Lla9FGIjr9sVGzdoVzQZx3
Xu1JFQ7wBRTtLLVTAxQMhdU4hRuKzVObkLQxquz9y7oWTfMzy1gSKNoiypmZ7I2W94Se5k3rtxc0
loKYlpY0Vki3j1KlEpZG3JkIZtyl8sZAs7KL7qHaU7LmAutDs56tYzIeKmaoU03CCDFKkbzxKFKj
DZQCVOYCaNF4rJvIOEPE1QRZ5ImqYU4RFA0TNRcWKsfLKswF7C+p57Cwv1C5t4rnxn3t2d/gBv16
g/4hcdhH4EH9u/8Aoj9jk16MPV3sgJW2lxzXOvnthoEjekZWzGRJyer72RfxknzcmmqAZP23/wCX
Bveb/wBOhrZo/wBKeGLNDH5W1tzlRbUXxJxZUC8j0scsn6E7z1G8i/YyrpzXxyg9WByt/tOSpRuY
XzDp5MCxXPmy35LG2JAFNPlYktmzdeUxspPTrrr0Y/pAOb+d/n+c4kVd1MSbFWiy+W9/mHnxa6rf
i+6xRFhpkhlinMsg/qlENx5cHdqtVYm6VssUGgsYF2rRUudhmGeRqaqmkjRSt9w8jPu4Sjye5xyu
bEx0/CAiHPm93jp93nsFRkaVZXaXdDgqTVIGSKQKdJJo/wAlJk8YKJIpNrqCVcZkDMY2vFLknSWK
P312d/gA/r1B/wAQuOwb8BR/2z/6I8eL6/P8xxtDaW16fadBSUuyWqqKoNOKusB4lMJJ2jnOYul9
xCBMAYjnBtxeTDU0QZeKnHBbXQkIKdpnUC90plqI2mDFJrPE0EM6TI53b5oEy+6OYliW4zKKmrqa
JNb5QGlop2YBswijzsuoGCQuS2odo8uQX4s9IlbDMw5UilgdbO4W0topAkhRW+vnFj6CR4jbHXzm
5PWSbk+Ukk9Z+4SyQxLmnkjjS9ryuqLe17XcgXsCbdAOAqtEGUgguiqAAVyuNWFrmwFuRCnfvGLE
rTu1QKUAGYTLAq82Zq2bZzFW7lUjrKaohckqfcS6B43heWL3Z4Vj4zz8F3fMbVkBqadjfuVanMEr
c8PC6VJQkrtGmXeGQRgyoqQShgp48cmz6XaGfIeNotSVRbFysTO4hZliNwzPGWVgsMErNfPEUq4U
mgUMuZWMsM0L5RcKs8e8K3bLuyql2GVFIDnlye4V1XPmC3J4NBs+skmK3zGPLBv3kjV4IGmmgiPE
388MN7Biu9qFgL5cwBEeeOQrnBKSoFu4lWNDmhhlayCajpq217iOKqrItnw5mAsC9XIY1vbixSys
FRb4BvfQgq7oysLMrxu0bq68qOrqVdGs6MCkiq4ZR757O/wAf16g/wCIXHYH+Al/tfnC+wUUlSVU
lDmQkAlSVKkqfgnKzLcfBJHITi55bm4CAHnAjk3sY8SS+6p3snHFm1xGhzQlTYmenjhFiw38k+SA
ZArf01Q1uKbGWRvhPcZStPJ3QqZqnISc2WemgollDNcgSCGpihAQsUFPNA+73GTDgoHJ5IhM8lvg
RRSCJJrcskdQ284O0QkzCCUuI/c94ylWdW4pil3MmawVH3ssHHc8VUFRBNTmQndrURPTlxMpTGVt
BlbMybxUyneFeFJRC0f3zM1ZIlKseXePUHcqpkDKBru7EHevu4tRaR9zwhAhvx97T+7QFbioiIeA
yKQcXGZl51WBjy2tU0sFZFa9uWCpiJ6Gup1U+x/P2Z0pNOEspObNHn42R7FQyXvlbKzLdbHKSOQn
CRBFRI2JDKQmvJZNLdGg0wN4qpIGYGOpSVmBIYywxIYnJ5S8ehRjqhUFbaYtbdullWHO0eXiiPem
MyFLWybwxRF7WzmKMtfItiuTKT/SkeU2A16dBbxDHGuCoJkbJCMvdlWbIEvccQb1r3OVVZydL4uB
G7nSNIC7kiwWnhd6EMwPJFnaWkhuMsp30MOe0ijJJxCt2Ekwa6c1UVqKqPMNGMzJBUzJIoYZlKmQ
TSIjqwyCRGG7jizq69wkXCRChRuS0lZTrHCqEmSojiCAu0GYgRs0ZsrpLLC6C10mjCPKrqO5Kb1M
5awEjZCd5dffXZ7+AD+v0H78Y7BPwGP7b+C+xHKGZx5vYjeVXQxFg6ujx5dTvEYMhA74MAV6wMWU
JHyCOMq8PeR79IYEMfMoljo4oo8tgyQ5E0zAnMxkQ3LTOkEg+G8kKwskR+HvI444LJ3SxKi23emH
ckb+W0iGWNWZuMkj1VY9esRK90tTWM9Q0YOWWRQ7A7pMimVHDZ33gkyqWPGDJVrtaOG5sXMFRlqo
hJnkW7SlmaaV5MpVlQAqyFIlA0J4Putmxx6ffI4zHFTRrxo95lye6Nc6u5fu3ldIyw42eSKFIEjF
rgtHDAkeRdRuyCMyti4017oMV/SCNkcjpCvxGtyNxTrj+fszxRSLeSNHI5Cyg28V+TA0RLaWta31
+vJi5sRzHUjm5LfNpi4A6ucc2CSxVr3VNR0Dm/jiBZjPEsVzLLLGsIJX74zAJ3fFHGt3Vl6dMLaS
MRqGZGplAFmvwYstdECTxgqsUr6bMQYt6KyDKJ9692bKBxtIlVbAq3CM24OXuWeS7cHkIL/kWxEj
Se4R8bhLQU+Vm4ruXSCnBZzlD7+mXduWDCqgMwbhCM4vvwsuriaQ14NiM8kq7tqi2nGbhLBmIuJK
mUm0tRIXBB5DflGnSDYjyEWPQffPZ7+AD+v0H78Y7AfwGP7b+C4OuODOJlcOQoNyASAfGOfy+xpZ
1YBlkjkikU3s8U0bRSoSpDAPG7LdWVxe6srAEON4XZzd5Fo1eTTOeAokUOUge53ijSKTd5A8e9Sw
FTVb93MgcOAwked2H6zUbOqZUBFmC59l0irxsyxqyhuNcHjAhjctwhncWV2kqBxpcygZJEYtJCUC
rG7sQtsoWVzIEXuQslS7DlDLO+yZo4x8JVhn2TBMWJaSVrKziMSJNIxk4SToaw1bVGX4bVrSmY63
sMs8iIn3pfc5chqYYZ0d2kQRtqqtIwFvgyT0lQY+tBNQUTrf3T7XVS5WScStx2VzoVEo00zmVxIz
Sc7kMCUubRmSZkAeonaT+fsG9tOXFZSiqRQKqWmtbMYZWjv48jD04iLJEIpRyABJG1ZyOQ5jqT09
Ps8ni6ObzYWUrJDIjZXgmhnjI5ngkSVB/VJQK4+EhZTocRqsUaRKPc0jEeU34xBzCV20cy3CG+bK
2QZla752ZmRo2N1cNm0F8z0dfRSSDTR3i2lVE24qyMpjVFQLhJ5I3SRSA8U6Txm18pSVZRHbkMd4
41415MsY4+YuzDRIo+VYaWno1ve+4pa+LaUK5hZlK1UQZmQozqxVy2SHdKuW9udna2gAzuz5UVQF
SNc2WONAqRxhY0VUUAe+Oz38AH9foP34x2A/gMf238F+6fz9llBBuMSEkR31sRbqsPr5MDQ4kbNG
wAsSLXGh5ujkxcCNVIFzpiw6Pf3ZvTzVOwJVgGZkqqGRv6gqY1J87DHYD+AE/WJPQkVvN93KpzuR
1XwSpjCjXk43P474bWNVHKBYtzk9N+XGlotO5Az8nG+ny4lOY6HKANBbk+2Ea/kQGHps18MyF2ZV
yDfGWMd2q5k2JGQyXUSRqtFtUrAWERfaAl4sl3WMosU5dN4/uO6jzkZ09tqeaaEShVMN9ntVQ7+z
TxRWCSTzxwllNkjVrSMslK7yFQokWKmroZl3K8RC71MJEiESEQlro5GJMrHQMFKNGSWvJb2t2NRq
6tbiSLNs6pqCyWzmoGfNx1KTLDWtOi8SMwtDbi3aLaktS2UcsebZxhoRLYSZ0NRk3nGaNN2kMfwY
6ampyE4gtGFMrgcYl2MMUBJbLLTy1JMcUrkuxUyAgFY+E1kjKuXOaeeFUpKdWdZEU0PHjWTdtwh2
SvmBmjNPJGGCIHILhFDFc1iwAzEZ2Z7E8mZmbpYnX3vsOkhrqxqScK0c0EgIYAjiMkl7HnGTTH2P
/wAX0/WZP3cP3efZ+0JKrfRVCrDmvkv8HTlGEGTgmbKTDUtJMABaSPd/e2typmNwLee2iAqcr68d
9eozSW16ky4PJHyDMouOvInzPm8lsOBna3JmNvFyD0ae/wDYsiRVUpc5b0lSqnobJm+ZTj7H/wCL
6frMn7uH7vtHb9FS7YpNiy7W2fQ1NWN7HT1QqGqKhRyrA0PES/wd6yg68uFSLne2qi19Cu4Y83WA
fHbHRrfRdTqTxRqcMB7n6fQD6APNg9zIb6721+e2FTiyvK+RYxnd8mYRrPtyDZ0LBY7FxFRz8J4O
vu1QViRHDS3wONubjdmV7SISJODq9NvFXeAqk7xSlc8jcGp5VZ4llinhZWUkg3FjmcWFyNHYCzMq
F1sOK5jjMgs+6jzZF99tUcGSSTpRk8/8hbxY+x5+LqfrMn7uH7u8MK1KVAijE9su+yLvMptxc9s1
uq+Aq6afW1v4kYREzd1bq6OTCavKraKrWVuqw5MJa0gvmF7i/k1wzZUzkhzwOerJVrqogqWpzEzG
xMwVGlkjjSR1zU8KLLNVQI3vteT2Oy2c0+xJ3BKkzUa3BseNVRX1HVceLH2OvxdX9ak/dQfd7A8o
BwFllkWOG5PIRh4HSQq4yuO69H8sciSSfAjfdNrpmyg+fXn/AIjGXJI0POpAPoOGiyLHqoLyxJZi
FVUli2kyOXOl3l2bJCic5bO7xqF3gN4nmswSNEdyylSN7VCjgTKeOJJZmisrquSOop5pCsTs8bjI
K0cslHLJAYx/SzwsVmjjPwsjJJFnUMpqFWIaPvAdHddLKUy68bLJDFKN4o0jb3TRQzho8kqtlkAH
vrs8/AB/XqD/AIhcfY6/F1f1qT91B93MgBtikkqKZuERGLWxGZRcadY6sVFRNVytNJZWJGcpoCb5
Ob+r/HrwLHKBcpPke3MSxyg26eLy8uArNLKdcyWJJ5e5B8ePdHaQZXzwNFEq3UtI1VRisRYCGIJk
pZncoSjZBPmWyvinQTohhK7ueG6lQ2V4dyqAWRWJQwBYwMpAiAU2QaE6Ry2uKimpq1nUq4WOpmko
oTLIrFS3CKfgwKNIpYw7t3jdWxzk87Esx52ZjdmJ5yTqSdSfuXdaHTx+8fsgfi+f/wAhQfvxj7G5
v2MxMeVqqpv+ywjHyUHl+7lRvF0GvV4sFcp5Bbo5hoObowQW5Ccp+D8HlvycnLr49cAABR3gAX9E
A3AHRY6i3IcAkXsSL8tjy2FtenQW8WLm7HnYxM2g1MMApoz5Kcbg99CWja6O4I0VEGix3yi55xax
PKy25FYlQeMADrhiWtc8ipH44o5Zp0iI5Ci1EzVA0zCYKwYWIPvm2XTMW6Sfm8g9js/YLsKMnwns
/wAvupx9jX8V4P1qs/en7upjzcY6jmvhjc8tx/tHQsp0ZHeNweVZI2KSIw5VdHVkdTqrAqQCD/sW
Nma2i5cx5lzukSZjzZpZEjW/K7og4zAH/azYGovzexfqONej5vuYBAGbU8/sdn4/7A3nNDtCglPi
E2T/AJ8fY0/Fan/Wqz98fu5iuxbTU3whEYGZQfHr9OFYe6HKCH7nQcXxdHkwoIAB1t04vzeTy5hJ
/pUjxE82Ba4bKpG/3+U5shG5EVgocbtmUWkeLJnUJxRKHmkzazE3O8MjIQQrwyy0fBHnjKgIk7sX
qpWjjjR6p2kEaWQIz3R8vFklrKmqZlsgiNRtCl2hmhBEgMkJgkgg3gZEjnl3izJJJE0TiNoyY43W
KczRwkHcIOFLUpCqFjaGIokUa5iVhXd3ys4aIbqNY8zvll3mdmu73csZHPPUrfNFOMqwyl3WHKwj
VzmULlQWTd8UWRl3u05mR0vZo5Za+BqhLjfe11Lcgohjd8yuth7okaseUgpX0deSp5hJJRjeKb5p
JZZs1zbEx32/+DvpNoS2Hco1cKLIMncslDwO1HFYRiN91OsyGcVHvbs8XPsBxzcKpr+Rm/jj7Gf4
rU/63V/vveAYc4uMwNiAdNy8dv77BvGL8tsIwUMCL8VQvjAAJt/W4vlz8oxayLfl5/ovz25L8+B9
fNb5tMBovcbxlhGzlxnIzLJU7DaRE5Smel2bWw5r3ieuLxZNbI9oRFJaQrVU9Rdl4pMOzayjmOUM
hU1VRVPVBVbLR70ww5kp4cwB9w1JywZJcxBzSjdqJLqiBmZU90bLGhYBo4IpHqZKj3ypuX6mt8hf
Y7L4t9sjL0VVO3pYfxx9jP8AFWD9bq/333eqpqyWZXiq90gPcB2UW/SAIwHRIlDuC6qMzDnPT5cC
SAvHqNYiTz3PffXmwk0JRbtf/rgyw5BxhgGIrGy8a6VWbMSAZeDD2v1QG1PwjecOIBntwcwX+2bj
Ndb6jg9PmNgvu+VhOMoZ+cI5YPkzSNFGmSETz++gqrfLrc3Pj9jsgXNs4j/14T5mx9jH8VKf9brP
3x+7Sdw5B1xFJAVfeG789+W+BLT5e6HIejvU+vpxvafMdRxSEU6fe5Sd+f8A2Ba3e3xvKfmIAHJa
3JzHy6E+PXCzwtIUYgIDofNgmjs33t23hsMqByiT7JAVWcbveTxVVeyySNukFIRIUJaWLPR7uqGW
AskNQsMm7tnkSZo4p0jbjDeoFmERSZgr5ChILrM1IkuSMRPHvJFMmSM8QVVZHEwVRrvKSKlqXYlN
08+5yyOzcGJowJTliui1bLGBExd4aSSaCASKhX3aZY4+EhTEd7u1TeRm/wBpbx09xIRnVWyxqJVi
kqYt+Cy2QT7qOojhN3SJt0WkaaKYD2vd11iVWqNlREiNQEgmoaQ7QqbPdzuavfruhmZXmvpT07Za
KRWqKfLGkZeCOVwmUlGkhm3kEjqFBaN0U5QCApiZmEpeGAaj3v2QOsezmLmw30I16S2mPsYfipT/
AK5V/v8A7ty44NT6+4Q68vuSa+Pi644LTfm8HxMfq4Slpif93g+GPvUfw7Zx3Pw/hd9z4ekpHGXc
wx2kVbrFGDbTnCjS2lubE1HSJIVWGFgEqNd1HrlsQe5N7X5fNh6OljsBSQsDDTFCIY2vLJR085Ep
CWjR5JZUWU3UClnVDUVkclHG1HSZKgrT0x3NNtGVXEETRmSjpI54Ve2UgVc8yUsKgmRpIp43WGdR
DiWjo1E2Wmp7o1Jk9xjK5Z6h0YO+RFEpgTerEDmVTFNHwulqIpsT0dGgZo6aAqODrmMERSIvFWST
TSEBWMcbQU0RUxxRI1Qn25I7pFh9n0YkdVio8q1u16cM8cSgQ0W09n0FLM7BCBGYq5qqrntljp6W
eeOMqhjwlJROIDwSNeEUCyqJKdAY61n2leOYJFIyRU0NNRy1YVXeFZu6zVFKpFPBG77iGMN7VyVM
O6jj3klT7S0ddDF7lclZ6+d6aONC2+3TQwTyzxTmMxrmiEboyS7tc+YBEeWbaUQ17logNlzs8wIj
C1FG8ZmSYsotZTxuNCk1gpzXfakOy90F0Mjo8hqpN1nVaTdTAsKiIEcqK3K++HFYMFanmSOQFhxJ
EYSxmKeB5YJJEqo1cmmYs0dkZwb5ZMmlzn9yqphkVQZbvwUQRLu7zVlVRUy2M5aPQsAAzXo+EZAV
Mgl4dtCkeLibyMtFFRpOVjeTeZmjgeTNC7pEXyhZI2ZxFkuciO09fSUMeU3e8EZqw9ROL5FgqCkb
5RcENE0y9yI96Fk4jqjRRTRb9QW3JdXIbWQKxpwpkE9450WJ57NmRKjbiJaxbc7IWeWO5uqtNWRx
olOq23z7+RQsUTWF7a8vPbUX8dhfzDxfd/shSNF2NzOhswq6Sx/93H2L/wAVKf8AXKv997xXlwwH
OL638vTjdk2PSD6eXz8+IacyVNLSk5DUyQKDYNkgmlenSe2YApvYZ4hHmEuaK7IkTxytRR8LkoI7
7vhtPQzs3dLCa2tqaMIDxVmCNApEisqyNLuhlZLmGTeorEZWMcEhW97CppoauIhrDMHp6iKQaKwD
hZEjlDxr77+yKrP2MVAUXPCaQ+QS4+xf+KdP+t1n733nmPSfPgaHMNDnElxy7xVKLJfv1QlQ3dBS
QDY4GmS2m7y7u2mTJnyZO9y7yTLa1t49u6a9gOQW1J8pNyfGSST0nX352RRJNsySNxdWkiv/AHsf
Yv8AxVh/Wqv983/mW3fwe/8AaRf6sfYvA7WiLaB3IHQS2p8v/mW3/wAHv/aRf6sdj22ts9j9AdmU
ez9ny0ZJYSmqu2vXmv8ANjt37I/BWzvj/F147d+yPwTs7489XXjty7JPBVB8eerrx249kngqg+OP
V147ceyPwTs/489XXjtx7I/BOz/j/F9fqcdtfZH4K2f8eerHbX2R+Ctn/Hnqx219kfgqg+PPVjtq
7I/BOzvjz1deO2Xsl8FbP+P8XXjtl7JfBWz/AI89XXjtk7JPBWz/AI89XXjtk7JPBWz/AI89XXj2
+7JPBWz/AI89XXj297IPBdB/iD1dePb7sk8FbP8Ajz1dePb7sk8FbP8Ajz1dePb7sk8FbP8Ajz1d
ePbzb3gug/xB+nHt7t/wXQf4g9XXjti274MoPjz1deO2Lbvgyg/xB6uvHbJ2SeCtn/Hnq68dsvZJ
4J2f8eerrx219kfgnZ3x/i6+rHbX2R+Cdn/HHqx219kfgrZ/x56sdtfZH4KoPjz1Y7a+yPwVQfHn
qx219kfgqg+PPVjtr7I/BVB8eerHbX2R+Ctn/Hnq68dtfZH4K2f8eerrxD2RbdP/AIXs/wCPP047
YtveDKD/ABB6uvEvZRt4f+GbP/xP/wAsdt/ZH4J2b/iR1fpY7deyTwVsz/FDq/Tx279lfgnZv+JX
q/Tx279kngnZ/wDif/liHsx7Ij/4Ts/48/Tjtp294MoP8QerHbRt3wXQfHnq68dsW3fBlB8eerEv
ZTt2Dl2XQfHn6cduXZT4A2Z/+6of/wCnGzNt9kVahkl2NTRpe2aGuhnXMLXGaOVluL8l8cN2x4NX
45PWxV+2tfFweShWJWZTvN6py2N7kXJI8WuP/8QAWxEAAgECAgQGCwkKCwYHAQAAAQIDBBEAEgUT
ITEGFCJBUWEVFiMyUlNVcZGS0hBAQlSBobLR0yQwMzVic3SUo/AHNkOCk6Kxs7TB4SA0Y3KDwiVE
RVCE4vGV/9oACAECAQE/AafQeiqzSNNo29NSTMpYiYgGQ2uFu2wZjsvuGJdHU0E5gmo4lsd9ub04
y6I+LxfP9eIodFNvgjPp6uvGXQ/xaL5/KPY/p8Pb58cX0d8Vi9B6uvGr0NqNfxaK3y/XiOm0Oe5t
TxF+nbf+3EUWhZd1LF6D9eNH0GgqmbKaOEjo5VubrxFwZ0Cd+igfW6vysdq/B7yQP6/V+VjtX4Pe
SB/X6vysdq/B7yQP6/V+VjtX4PeSB/X6vysdq+gPJVN6re1jtX0B5KpfVb2sdq+gPJVN6re1jtY0
B5KpfVb2sdrGgPJVL6re1jtY0B5KpfVb2sdrGgPJVL6re1jtY0B5KpfVb2sdrGgPJdL6re1jtY0B
5KpfVb2sdrGgPJdL6re1jtX0B5LpvQ3tY7V9AeS6b1W9rHavoDyXTeg+1jtY0D5KpflDe1jtX0D5
LpfVb2sdq+gPJdN6re1jtY0B5Kp/Qfax2saA8l03oPtY7WNAeS6X0N7WO1nQHkul9D+1jtZ0B5Lp
fVf2sdrOgPJdL6re1jtY0D5MpvQ3tY7WNA+SR/W9rHa1oHyV9Pq/Kx2raF+Jw+g/XjtY0N8Uh/rd
X5WO1zRHxWL5+rrxV6Hp043KsKBE71RfZu3bcQ0EE26ikHp+vFRo1oeK6qFXz99mBN/Pt2/NjTUJ
otDJX6rVyNKFIVWVxsl+A+6+QGxN92O2CfjMMVp2zyxplzRxhs7qLax2yx3vbO3JTvjsxpnSfEOL
8WlkmEryqzpNFLlZCO5lAcy26ebvXJbHA6rGltKR09UjvE0UxKyCw2QuRtBvcGxHWMaSWgNUrzyh
JQAQ2az26jfNg1OiWg1RqLv4Ze7c3wib4/8ABvHJ6wwDofxy+sOrGs0L4xPSPD1n95y/+flb9uNf
oXnmX1h1deLcH8mp4wtt984t9WIDoOHadIwH5V6sBuC43VKDzOB/YcUNZwdpz/vKDrzr1deIeEmh
Bv0nEP546uvHbVoPynD6w+vHbVoPynD6w+vHbVoPynD6w+vHbVoPynD6w+vHbVwf8qU/7T2MdtPB
/wAqU37T2MdtPB/ypT/LrPYx20cH/KtP+09jHbRwf8qU37T7PHbRwf8AKtP+09jHbRwe8qU/7T2M
dtHB7ypT/tPYx20cH/KtP+09jHbRwf8AKlP/AF/Yx20cH/KlP+09jHbRwf8AKlP+09jHbRwf8qU/
7T2MdtPB/wAqU/7T2MdtPB/ypT/tPYx20cH/ACpT+iT7PHbRwf8AKkH7T2MdtHB/ynT/ALT2MdtG
gPKlN6JPYx2z8H/KlN6H9jHbPwf8qU/ok9jHbPwf8qU/ok9jHbPoDyrT/tPYx2z8H/KtP6JPYx2y
aE8qx+uPrx2yaE8qReuPrx2xaC8pQ+lcdsmiPj8HpXHZ7RPlCD0p1YnruD81/updu8awWPz7cCo0
EN1XbzS//bGv0Cf/ADW7d3Td8+KpeD1bFqaqt18WYNkepltcC19luZiPlw3B7gM20pTnzzzH/PHa
7wF5oqb+ml6uvGidHcHKOpzaLEXGCjAZZHkIW3KIzEhdmzN0G1+VY6WplnrUZnKrHEmsA5wzsF9J
uMR0Q1YzxMH4jS37ovJquNLr077blgu+bvT3oJOzBo6ex5D32/DH14NLFb8HJ64+vC0sWUjVPexH
fDfzbb7McRpxAtkYyfCGcbN19t9uOJx79VJ663xxKA7Gibbv2r9fy4bR9MFYqshIBsM288w344sp
EY1Mu8ZuVbZs9OBQ0u7VPt5/RvI8/VjsVSeA3rf647FUngN63+uOxdJ4Let/rjsXSeC3rf647HUw
2gPs29//AK44lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144lF14
4lF144lF144lF144lF144lF144lF144lF144lF144lF144lF144hD0fMOr6scQh6PmHV9WOIQ9Hz
Dq+rHEYf3AxxGH9wOr6scSj6T+9vqxxKLrxxKL9x5vqxxKLrxxKLrxxKLrxo6BYZ3Zb31Di/8+HG
kY3mrngjDmSWCAIiLfMRNIT8E2sNu9cVOhq+lQvUw1EKW750sDsG7Zyvkvi8S2+6N+7rt/N/twBe
1mO0Ejveb5Nny4l4SaDirOx8mlIlrCcups5a/nWIr/WwDsVhKSDtXfyv6uA7NuJ+b6sNIU75iL3t
u/yHN+98CQnaHta12NrDrItc/Jij0Maiimrpa/LDDqwxVPhSk5ABa/wTcndb019K1HLqUrtZsR7a
t1ujjMDtRbX3bbHqwdn8qdvn9nGQ7GMuVS6pckDlOeSNu399uKrRtTRZeM5ow7xxqQUkGeSJ50W8
ecAtFFI4DW2L5hjVf8ZvR5vycar/AIzegdXStvTjI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fR
D9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3
j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9ljI3j5fRD9
ljI3j5fRD9ljI3j5fRD9ljI3jpfVh+xxkbx0vqxfY4yN46X1YvscZG8dL6sX2OMjeOl9WL7HGRvH
S+rF9jjI3jpfVi+xxkbx0vqxfY4yN46X1YvscZG8dL6sX2OMjeOl9WL7HGRvHS+rF9jjI3jpfVi+
xxo9SJ2u7v3BtjBB/KQ+CinFdpGfRumYqiF1QrTxHldUsvUflxpbhlXaUCx1TK0SZsgUCwzAA/8A
6b7NgthzTM6vcDfs5he3NjjcAACWtlZWPRe1saQ/g7k0hpuXSsFXqnNRFMpLEMFUksFPMD8Ic+zA
njjSNGaJ1SnWIZANkoXLm2fCJIN9u7Gj1FHAUmqZJZWkdyZHLkKTdRcm9ugbhiSSF7cvd1+bEcsU
fOHUnaDtHoxorhdT6MhnpZYmlp6gwkooBUNCSVzKysp77ZdTsv03xpPTcGkqqaoXNZ42QB/gZlVU
ynqy7OcbhsxQRtRwZJ6iSolMryXlcuVRjdFu19nQOjZhpYZgBJaykMoPhDcfOOY4euLlNdWTSKpB
CSSSyLmVGjRsoJXNGkkiIWByrI4W2Y447B4Y9WT2ccdg8MerJ7OOOweGPVk9nHHYPDHqyezjjsHh
j1ZPZxx2Dwx6sns447B4Y9WT2ccdg8MerJ7OOOweGPVk9nHHYPDHqyezjjsHhj1ZPZxx2Dwx6sns
447B4Y9WT2ccdg8MerJ7OOOweGPVk9nHHYPDHqyezjjsHhj1ZPZxx2Dwx6sns447B4Y9WT2ccdg8
MerJ7OOOweGPVk9nHHYPDHqyezjjsHhj1ZPZwKuBv5T6S/SAxxmHxnz44zD4z58cZh8Z8+OMw+M+
fHGYfGfPjjMPjPnxxmHxnz44zD4z58cZh8Z8+OMw+M+fHGYfGfPjjMPjPnxouRJJpMjZrQm/9JFb
HCVUbSMAe1jCgJPMDKwOOEmhdGaH4rJo6tFXxmOJnjExfVho1Zy8WULEVe6jKWzKL8ndgFSbWXae
gYyBQbAC+/Zb/wDcBXYqqKXYkKqra/KIGwMQLc56huOwYCojFAserMNXOGhi1mskpa2PR8caQxpr
ZXqquQQ02RHd3eI5NXKZEtuZtWG1VE8rHIyLxnRj6TdklXMJqenjgqU1y2MrRDJFnmSMnYGJQDIs
rMMi3GqpamuUADvuMUNHNWUzrmilg1Z1gaaJHcaoyh8i6kkSGykKypSM67ASWSSupKdgASZpiEzR
wVUkKJIXWOwjYyiGQNlDROKmgpZllQXYPBLpGlzLbuivrYNbB3XCFnjYgXJno4YIwE7s9XUVtHGO
VlETiroZIhrLIUdJjKsZOFJleELZuMT09MkpUZdZPDFOmckZkRFnp1dmAXPOoTOBIUVtYkclrZ44
3t0Z0Vrbh077C+AOgbcFJbbVsOkDEbZlc+LF2wRly/l7vlwUt72itKtQyj/d6mGkZbEvJJNSyVma
JVDF444YZWmfZq9XIzDVo7rFabLq7EuYgi3BLa2urNGre19XatompyZTGDLPTRJnkkKIg1ql47Mq
xQzMR8GOpVJKct4JmikjmiRrO8LpMqmJg5+8cHv97mHNxVjbmvroMcJT92x3+Ljf/wA7YkfONp22
AvtvYW2ebZhqikirOIa77qnUV0K5v5FbAgdV942jfsvvuenBF1a4zKiPK2y4VIVMzyHoWNEaRm+C
FLc2JmeJXmdZDkLB/DFpM8t8xB5E0cmsG8VNPPFY1NPJGjgRF0LLlV2RmvlivHFNFIczhV1cMVJU
QSzfgYhTSxNIBEQArLlksVOpy5XBGQaSo455ojG+zWNBUqtTlDZXbKXuQTc77nZa383Jl9XVRW6N
Wlu8Ww2BFGwR2yAbAmVkdcg+DZ4o3FrWaNGG1VtYcrYOVmDdJV0CMhO/VlRbV95ynOW8jlrnNmuc
2YNm+FmCNGGvvzCNmQHeEZl3EjB2WA3ZV+iMA2IPRiSd8jd11ezvyuYDrynf0b8UXB2rn0cdKVeW
ipZ2aKJ0YSLVsuQ5bX7kWDZhcXNj0HEltYY1bNqzfbc5Qu3pNtmLOouzsRYjbfbbuh5/B2fJgKVO
0nbu382z+0j3LgbSVUDaWdlRVHOWdiFVRvLMQoG0kDGVsufKchOUMQQC1rsm3+Ui2CePv4GKpMsb
MoPvCJNbLHEDYySIgPRnYLf5L4GgZVyZZ41MaTRoVV1ZUqJzUTqGFiBNKzmTby1eSNrxyOhTQUsb
B0miRgyuMsZUXSsm0gmwbCqV08tWqEZBUZJQuaKIomgpowVSeNQY0htlawjjio4FRb96NTQUUZy2
LrSwh75BbsFL4+P1Wx2Cl8fH6rY7BS+Pj9VsdgpfHx+q2OwUvj4/VbHYKXx8fqtjsFL4+P1Wx2Cl
8fH6rY0dQvRVRzSK+spZrZQRbJNS9PTn+bHCj/fIfzK/TfFh4IN9lvPs+a98TcH0m4Q6L0/xmYdj
NFzaMWDO2rqhKQ2vnGbLLLGdiu92HMRbFTOlEUSdrcZIRWO9S9gLHmtf5MHKzO+dWh1DNJe2ryMm
pbMG5IGxmzbMrXcENtw2aTWxtdiRKZlPPq5WeYN+Ukle7unfATs5GQEi+cwk2bjTrLEr5TrON7mM
b7qWfsg7vnUUr8bmmkvrZXJcqrkk2PFlc2LM2pp2FJGx2u+SnMjU8e3ZJNJGt5pWcowdoyOWu8bP
GQRAKRsYs9TThVUkvrUZQVN8cynmYXU8zC5W6nnGYEXHOCN491t/yL9Ee56OYbdo2m2NG6D4RaX0
VWV+ippajRmjqpKOppEmfUwyvZ78XVtWHG/OOULWI24ZRFNLHYa5SVm6UsbH59mCSdh2jbsO3eLH
0jYerZgbSAdu3n9OCNmLA7CFYHYVdVdWHOGRgVZTuKsCpGwgjGZuVcli5VndznkcprMpeVryOe6y
ElmOZnLNc7feNFsrKYnaNauzmvcEHzjmxxdkqal7numS2097lBy/8twDbdcA7xhoZSQVZhsINidx
IJG/ddQbdQ6MGCXVMuZs+a6tc5hssbHeN53dOFgqLw5HRVRWDq/OzNnzWPOSWJPOxJO04MdXG75m
Dhzdcm5QPrxFnsdYNt9nuZb82MvVjL1YmhmcLqZVhswLEx63MB8H8IlgfhW5RG4rzyC1TD+jVX97
RdZxwg/Dwfml+m/uWWwuNiiwtzDoW275MSKJIaSOuWkJlmtSicQmaQ71VM51hbZcFQd2zAVVzIoV
RdDsVSDkkEoVkZWjkjLjukMqPFKpZJUdHZTnyZG8TFPEhYsQkM4j1icpiAO5l83fmSWomkd5p5ZG
iGpeGJBy+NRTrEdrzVlJ3eN8vf54lgeVoYckT2qKiaJ5Xmla3c1i3oojXLuukejV0UEYixINGqpc
nOjDNE0eZwzHNvsTebaVVuTPBS0jplcMmQUlHBTIMt0QGQHjB12HdpCC20hIo7ksxyxRrEmZnLO7
ZUGZ2YszXZiST7rb/kX6I9wi4tjRentJaFhqKTR1RPSU1XJrqqKmkaGKea1tdMiELJINwZwThTrK
mWof8LMxLX3ud5v07em+/G4Oejb5rEYJy6s9FumxtyTc+cj+3Ge/Rt95gkEEEgjaCNhB6sccq/jV
R/TSe1jjlX8ZqP6aTq/KwKyr38Zn/ppPaxLWVQTOaia2tVfwr89vyr441ViWwqZwGUMAJpBsBVen
8sYFTWMzfdNRsPPNJs2keF1YNVVj/wAzP/TSe1jjlWN1VUjzTye1jjtZ8bqf6eX2scdrPjdT/Ty+
1jjtZ8bqf6eX2saNnmlqG1s0smWB8uskd7XkhvbMTa9he2+w6MaZN5ofzS/Sb3N2KqPRFdVaNqZ5
lNRoyRZYg2VijhSt477UPWtsIbO7xyEhthPJe6NskjBkVsokjLR50yyxhs8LxyqjqwVo2iZRkbjg
ZV3ZK2qgqJQM+sIbVRGizZiOKuYwoBk1plZqlqlrFpHopZIxcRGSiqVqU1YJLRxWNTTCHO68Xqcs
uueCCRAtkiTMw1NLDTIyHKV1LSSiVDtOserFHVsZDLy6V4gRTVdTC2fuWryqvdWkOQZUAKIkcKA5
n1FOFcU6yyzNCkrRI4iCovutv+Rfoj3GAIIOb+aSG2bdltuDRVxoFrzQ1EUEnc4JjGwjZunPaxPm
Powq52RiSHjO0DZfz9IxJ3kgta6kekYY3K7Nlybb97o24/8AKbDm3YTe/V83vcgEZSARe9iLi/Tb
p68XPTuFh5tht5rgegdGLkbif3JP9pJ85OLk7zf/AGdHfh2/Nn6aY4XUUdDpMU8TXAGc+naB1bvT
7hFwRuuCL9GzfifgzpTNx+KaZoxUZvwjbUzbt/zHFMBBNSs5YakRs8cbFM9rZhcEEX3FgQw3qVax
C96xcZnZUzBTkQyGSn4xq+SeLpPSxSQIAkxpKiSSup8rSLBAMtjmsS1VoiokZUUZ+x1RVTyHI2eN
GljqI4BEqimzU7VIijNXJBGpN42fllJLuM7jXw6qshMYkuz0usp6iGkOouIxT8cQa+TVp/JCPaxW
GnhDbI8wg0KujlyZQeLDjq8dyoJBcoN0OSRyCRa3eRg2XIpZUVXZUzOURnDMiNJM6KQsk87hpn9x
t/yL9Ee5tG6wPMTuvjt60hBwYi4OT0FJWRROStQaCrlngVueGpWYQQtstdkItzdCZ5bTx08qgbdo
NubvuY/Lg2YcrY3Rzfv1YYEjZsNth6PN0YGyNl+Ewtm577Nt+nFjqJUvkkeGVEkyqxV2jKo3K3WY
jl7WTv1BZQMFkMpYLZO7WXeQr0lJDDGLnLminhlneodXaQSyqscUlQk1H784KUUVdpbVSmypSVkv
nZYGAH9a/wAl8cO/x635hPnZvqHu8GNIaTjXSNLW0dHNoYVGkKyWnrp6eCtlfifFdHR0NWaWqkhp
aaQNWGkpzFDWySAVF54o5kG+TNfa9AQwyl9Uk04rEjLXCyNFIjDNZH1Yu2ZFXDqzIUvlcxsJWjLC
PXMhjPFCbTR0wVzPHJPrKoVcMMLxmlmlmhmdTPUNEvc+PVFTGOSmemqIYqVaSO6yLCafI9WjvE8U
TyZ0gmlUxyN3rBbM+eqym7RK33dTcVFys5jp+ICfPJkmqVkcsYXaKJJuSGqCOWvGC1OGGrvCtJU2
jYB5cqS1nE8xMjTKnGUDgaqbFlEaDlOwqp5H8Iq2j6WKHaGTuEWk45alYAw1lCBHMOM1FQC5bIxX
K02pmYbliaf7sVUFkjIS40e9K2rTkvX8b5XFo1YArMYztFRMsQc6u8YmoJacXCSsg4tLUxVNRq51
V0bi0dRLGRiXLrGyd5fkXXKcvwbrnky7Pg6x7bs7bz7mVb5sozeFYX9O/HB7hlo3g/obTWjdLcHK
XTcGkTBLxyethop9Gx0zJLJqKmXRtY8EcmrPGCs0KNEXEikZjh50qmWqpNVqZZJZ4gsoqI1FpmpQ
JEsk8UdQKczIQEqadZYGCCW6yAauvSHP3WGvWkaRs0iNJJopqTl/ybqItIcpLCMOUXKjquJGjMjZ
QdUtljyKgfl6YkneRXO2S2jZHjVJwGpwKanR6owvUyR27kJbXUU4cpmEZZNWso5WaWWnemR2MhMN
WNJNtE1G5eFf/LEnlIriouLhy2jiMwAIAtXyusY2hIoYXOeS8jbqVVClnFJqpIy/dZKrXu6Tip2F
FSmY075cmukkEzIDSwF15OrUuGKPo8a0xjl8XKrUzvFtBWegiWBqQsyzaVnqKp5VjEdViMostLJk
OSGGZmhY6zOx0xFV00ErnZKyaMHE6ieSOS9pkQyZ0qWhsopA/fxLQJK55SlYDFJXkx8ozPVAiKLW
uZNbS1BNTTU9egg98cCPx9H+iV3+HfHD78fN+jp9OT3B3wHTfFQKmN+QzkNImy5NhcbtoFjtvboA
ym+xuRriSSTqLDmUnNnt0XOMgzzEsdiRlEubFgsjZbflusaHpDWxHfugtsW4VjtLAMVVtvhoqv8A
z8Dn/wCp8mWnmlX1pY44/O9+rEZJ1t+YxAc/fQQux/pHdfktzYG9v9o7iOfGidM8HqDQmlqTSmi4
qzSNXxfsfUmnhklptWX1tpnjdkD5kzZd9um2F5TIRYI2YgdA2WB/sw4Xlcojvhs6oJ5FO/xqRoek
NghVRSrZjkc7eVcigjqAPlqS8I+q+J+THPlPeyWVvyRPKikW3Z41Rv52Dc3VSFJEZV2GZQUzSvGw
1qMoniSSNZQkgWXVJyWkTM5GslMS3RoWlgRybJ9x1tQsbuFRmn14oqR1fVZJJTIkVSqTpFKDlnWJ
iXXsgY3CjbBDUUVPTz5WvZstTUTmNxlqGpEggP3ZDIJ8geUxZbXlMSXfI5Str4Y4lktI8KS0kVNV
6+VJsgcQ5XkkQs11lOUGRFgQBHKRGWeqjbi7GRGnWEU0qXrY+7JCkqqah8utKhe5JrL5hGmtEb5m
kn07JSxyGnuGsdFNHVpTIdfEUWCpbXSZ2iGcwJJ3JnIWc3ziFpamQsAeRDMlDTcXEkyyxit15elT
W0dTTObXOUEC5sCbkDmBIC3PScov0Dd724C/j+P9Drv8O2OH34+b9Hj+nL7nOOnHFXzIbm3Pt839
mFAMkobbbLe/Ve3ow43Hn+ogj0EXGBs2bhbd5hYfMLYHfr17+u1t+DsdsIBZjb/aGx1Y96t7/LbF
r8Ye5AzxZQD8Gzltn5Ng/wCVlynvsKDrJhbvURk6zlZ1X/qkR/0wh78LZgM1gbrmI284Viqk335l
UP1ElW5YYnc6WHexyOo3Z3GQBD03DM1j4PVhACqrfMusdBm26yNcpWQ9PKZlF/BwI88yICOXLHB0
ZTLHII5GNjkgSUKJpLNbMqKuaQMqASPTKCQs5pVZnGVkaegFcbRXzSFVIjKRmQCodaYSySKxwNsc
Mm7WxCS3gnMykbbMVut0kKKsyFZ4dZTyQzSe+uAn8YI/0Ou/w7Y4ffj5vzCfTkwc1jlALWOUEkAt
zAkBiATvIViOg7sUdFo+ahqqior1p6qITcXprcqZkiDxgcj+Ue6XDDLa5G/EM0s2ZFd9YiryBY2a
auWgo4mZioDV0rDUuueBSJUqJoXgqBFmG1wdjRzy57FQ3FqGHSLrdspzmmnXV3FndZEDXXGRiJDf
ZEzo2Y2GthkWKeFC1g8sLSRF1QnMj6yLWRxzNFjr5/cuRuJ90/5L9Ee6eSt2sF67W+fESiWbUkBV
4xo2Ata/Kr6iaFGscqdxMGcKZA8l7RrdTgSDVvPchI40kkJ3rnopNJRpYXZmNJGZgUDRrcIzrIJF
RxqUlZxlEHGQw2XzUbxQTKo57SGSGJvwc3EqswO8UIdstgWYhTGahesTwVdPRPEh+E2atpl5O15Z
1igWdRJKgQqsdkys0tVCkWxXXihk4w1iVCxrqagg3vJqZAis2RXdrRtKOX3A1C82siyUb05Ba22q
FfRiFD3Rdd3dIdXNq51MOv3NqOMX3rtgNcmU7D+Fk0bXxqVzgNSsXKpJTvO6Zb2u1glhlszudFjS
sixi5zCKAhMxK5pWjQDM9gRbLtVgyRyKym6OkqLJG6NudHRlZJEvHIpDxs6MrH3zwE/jBH+h13+H
bHD/APH3/QH029xgHMZcBzExaItyjGxRoy0ZN8jGN3jJWxKOy7mIxIcsZsoIGsYLbZeVTHKbdMkZ
KSH4aEq1wcKeMRyltp1E5lGazGIRZp+VcG2qhGblC+rXwVxLIUWoka/cKSKVwBlaSkvIYiinJmjL
RiRM+UPr4p1zLLrMaptbJCCGeOppKPk3IeqrIp5kpxs5E0UcI18U2qeJp4Eyl2dUG3V5QW1sYliC
gs0iHU5dWgBZ3kFRA8cagySxypLGrRsGxzZrrlvGM+ZclpaTj6Pnvl1fEvuppb6uODusjKm3B2Z7
3GqVnlBBBiVEzymUHbHxdf8Aec9jSlkFRq2dAWR0tnGUkyjKe+VoZ5aeRXXerLLC4ynbYA8/uNv+
Rfoj3WgapACEjJ0XG4YQ5M9/5LK7HnvFdkN9+ZDcqfgkki1zjLlDJYgOhhAO7VAldXbwO7y8jve6
ybOW17Z88R5TTrGkl9pkWASiJX3lxEs04iU3yCWULbWNdXMghe5yytq05R3gCQ282ojvbwY/BGBF
yJAzhY6cSTvmvkzRjjLuFAN5GVVAsMzuEHRizmSOPbnlkQRC/fy1Ma14yt3pZo8lVIwPIDRyylS6
EqVyR7VjvDMsKMQpNLDVvRVBW10SnimiTWq7IFidJiuqjmaHIxzoVIu1NG6MCCxqKN5os6HaoFDd
maUKqU5YE5EmEYJkAluWEkUdQHJ7+OdpFje7bzIYpCF78qpky5OV764Cfxgj/Q67/Dtjh/8Aj4/m
P+8+4UK4IzC3ThhGqlZAtipBLWGw7Dc9BFxhhnDxsL61JYZRblSrFJJNOsh75zHLUvJMWJZGlu5F
xjWN+Gz7Dasz35BtNUyLUeAVFTWVMqyd6KiVpAdYFIsQVjRnikkpo6uPKcsiw09JGYqlQfwclLRy
Lq5CBPSo8mUxlpb9/qoggAcUtPEirybNDFoWLLfZGsqaulkcFYy1s9sgyu65JHdgUKzvJfao41TS
zVL5dySzUbStM4AlamBDHVRgLJnudaTmBlkbMeUNbVyl3bntJVPJlY8liwEfIKYsduzvSob8kuus
QHoLIQ6375TmGzbht/yL9Ee6sjRm6sV2i9ja/nwbtPO3wdVmZdljff1Ye65CxJzd7frsefrA9GL2
Ib4Q3HnxYKoAAGrJZAB3jEZSV6CVJBtzHBfLFKzFgurZpWUtmtksxunLuEFhl5e7LzYbNH3RrKI6
oxA3XIKiKmgp2iVRyLCnmhpZEUapiOLODJA0cZIiQ3JRIjUPmuQY9VrnqwGHLVUE9QaiIHJaecSr
aWQM94WZmGQoZJWsviBUPLyVFnSJK+cMlmRYajV5dUUXGUxDmXJTQwlrglaZo0rIomk2lUaJIpij
NcrTw6wWpYtUQRvBGwHbs2EXB8xBBHSDf3zwE/jBH+h13+HbHD/8f/8Ax/8AvOL22442DC0ZiTMw
tmyLcdd7X9BHuAlWV1OV0ZXVrKSGVgwPKDDeOcYU5MoUWVDV5F25Bx1y8oK3tJlYs0etDlX1cxLT
01JJAhMawhDl4vqDERbkvTPWSwyZSDGSk1dUTBCmpzsAI9WMmJEzxmMWUcWpaWMEGRI4aOFqeNAj
k3EkJWOou2eZUS7qRmwZfuhqlVs/GIaqK5zFJYajSE+djZRIzdkqiI8lIxEzAR31RhCjLEh5SQxr
DGrbkjBVyoIswZpFztKDrsrzU4kFJPNTuJHEsUxOaWKVJ1cgD7oWorKppyFyrmlkr6wSIAIck5WO
JMkRjXkoIx3oSljF9uVKOmSkhVeZe5INaygPOVjEzOlPTLC2/wCRfoj3Du6MVRkMQjRBZ7AyAWYb
Rtzb/lvhVIkdbk5oADfn3b+nDHWZRv1fukAo6MoZJI5ImVhcZZUaM7OkBrqeZgDzYZ3Zi2Y5jUS1
N9nJaeliopEUEECM00IiC2ugZjGVbIUsuUJlGURLBblfgIzRauEm+YoiaOpIr3zukd5Xkld5C5Mg
fOc2sSRZTsBkeR66RpmyhQJM+k68gRhIhxgjVWigETMWzXtt57DZ/wCHdiibWytek5PdA9jfLZXk
V2bMb9Cqu9mNkUICzuWkkcgXklld5ZXzSSu8jM598cBP4wR/odd/h2xw/wDx9/8AH/7/AL42/wCR
foj3DhSStrXA6ebAJJkN9oFr89r7sLYDrI24G8HoZT57G9j1HccDZtNza2/8lGT582c9JW+NrWIO
zf7+4EPDHp6MzHKppK4D/m4s9h6AccPvx835hPpv9/GcJyoJcvhrcXB5x1Y2cwtfeCNvy4Yg6vKt
snfflefGZSX2bzyer9/l/wA8bGjACi9tp2D/AF3bMX5CKUtZII5VVspdIZa55AswXNHJViWkV6jI
8sCwlIy6KNY3K4soITKKkzyiNdsrw1Wom1V2VtVKaNuL8illkiYGKCnnlVW2g5O59wq0ABLWnkp4
UglztynRauI1hge8ces4sgeJAWEkeuz6u0IkVkg3gRjTMtYyMTtkz6OleivJcozXVuQsmMmampkb
v8r68HlFc1CKcBjuqCtWGrCrNqyJNRmyKMCQa6OVhmK1cNTIW5TPqpQZEFsiKtSJqqotkL0tQlFH
FNJBAuRQRGVuM5p6KMM2aRUnhnMlVLlDwu4qeSzATRnVhqFGiiZZ43Ks7lAVUsxVTlJCk7ASiopI
Gw5URehVGwe9pppIIy0TFZGKojKSpBLAmxG3aqkHpBIxw+/HzfmE+nJ9/wBE8MeB6cDaTQGmtGVz
aZpa6aemraGkorvTlbJFUTGsimlhDHYsigX25bgYzF3djm2yyNywitlZwVusbugIXmV2A6cMFutr
Dp6/32YbKCbbBl838sv/AG8/Rjpt4TfSPv8Aqu9iPgzKf6rj/PHD78fN+YT6cn3+hm4O02iKid4j
NpuV2pqyGdEdEoNmpqqLNtinBLCRlF3GWxGQ3QEMQbHb8EWFtmX5rX68b3sbnbs3/uNoPyWuMp1g
BJkKsLJ085Gw7ev/AD6d+GABIG0X39OHsXZUUEloRCgbIJMuiZ6uoVne+rJq4Y4OMWNPCtS0jBuL
Spjk235slPctZ49bLDSZ5CUKu0K1NYJaSNY+NSxGEVIgnpKyB43AU2UkjKhucoblIrHMqPIqNc8q
MSyiJrx62XLrG+9+ff7wjh1zovQwb0bP88cPvx835hPpyff4KSonqc4kjyCJgAe+AAJN+oBSfmGE
DBrMRcGxy7t/Nhhyht/15RH9gtgcqogVicrRKW87MQT0bBY3t8nPgbh5gT5zv+fCrmYLylvVw0u1
eVaWlFRrrAkLGCyoryNHHqxNVSyQU9PM6e+wb7f32e5wZh1+mKZCARaRiDtGxDzfLjh9+Pm/MJ9O
T7+rMhJQlSRYlSVJHQbbxitqqbR9O1XUvqYYgWYg5RYbTfFFpGm0jSw1tMc9POueNukAlfSCD5jf
AXukbbNsV16hs/0woNkPjTs9OBtd4+VdNaBZWcu1OtNLPZUDHJDTVGvdu+IjKQxyubBVJLLycwen
SwZWtr6Woq2cspKlYY6adZNWZDr6eogA1sarJm/3RmBEVTEtQ7Wu8MDC63j2BpnDI6wl0vEzPnBT
IzJlSJiVJfjAOQ50D01bVUMmSTdIhkpXZHst1YXVWBA+8noNtv3/AKvc4Efj5P0St/uGxw+/Hzfm
E+nJ9/EZO3Gn9BUvCKhfRNZPNFHJyzxWRo5DGNhBKkGx6LjGgdBUmgdHx6OpZpZaakDSQ69y7LBK
bAEtzByxA6ThEezLmJ1N+fmO3+yw6LYU5jDbdq8y23C3R0Ya0SprnXLPAax3sxQLC4XNNycxkR1R
Usr8oIEa+TEueF2EgYSxVtXTsLgutVRUp0lMykNymIqJNWULSSVMkgVbyZ3MbIZIjYcWmqKRVvdS
1Nq5HEIW/IMc3GFuEGQSFwkgyHmA5lVVUcwVQFVR0KqgKoGwAADZ96ey90yF2A2BdpwDsB3dR5ur
78vfckcgd8xve55hfm9zgL+P0/Q67/Dtj+EDZwgkHRTwf1lzn52P38SWjfq/fZiP4M3w7fhPh2vu
zb7dV8bLsbC7KEY85UG4U9Kg7QDuxc7Tc3bvtvfefp+XG61tlhYdQ6B1YJJKG5vHHq0sbZEzrKMt
rWZJUSWNxy4pUSSNldVYBiGZxsLNI5sBYPNCKeV0XvUaSACFmQKTGAh5OzA2XtuOc5ebO+pUydOf
JAse/LkLAqTYr75uD3puN1+vn9zgQ2r00ZPF0VQx8xMan6Vsfwgfxhl/R6b+6X7/ACGWQGMR5V3Z
1Fi3WTiNciKt75Rv9wjNu+Dv+bF77fd6OtVYdauoZWHSrKQyncVII2H3ernN7DzAsfQoLHoAJ3DA
2sqDa0jBEUbWdzuRRvZjzKLk/wC2bDafNgEFcwPJ3X/034BB3Y68XH7g/exu2DL1e5wFGbTojP8A
KUNcv7Ev/wBuP4QP4wy/o9N/dL9/EnJCnmwVJN7nbgkLsJ2j67/2HBN0yrsO4kbCSNlz17MIpCgd
WCW1boGZWaN4xLyDKudomAzMh1kUGpU0sUucQNLU2JhkjhgBCqFWOMAW5JDMmRajRk8UNnZpGigT
R3FoNbJJIkFRKryyMXaTe7l+UnFqWnCuS5mEEM1M8VSwMbGGeKXNNqmjlMqI0TwOiSBtqsvwnhki
eQ2zuZYdKxPK5UIDI/ZNZHIC5pKGkbYY0ySNnm12VN0HIK3QCn3QW2fcVQO5VtMbtU0yRRNMrIZG
I6C17SAOxzSgyUMOjtYJOSRNDTrUNTOLLDUVUkuRgXSQSWqI5woBirUq0QbFtG9S8cTdOqWp4tE4
y6ujp6SnVLQ5njOrFKN/Flo1HWKMVY5JOZo+NcbbjLhjMdrQSwSinlpve3At9Xpq/PxSpA+UL/lc
fLj+ED+MM36PTf3S+8Ceu2MoO2w+XC/D89sAmw245WqZNmdkcZ/Ce2mRCTsuggFbo+2T8IaPNICd
sl8twlwGlrJDbKtxUDRvF0JKSKeJcQjBJQ8fWBOMBTU1BF1swCgf7vksD8GnC1G13dlRqnPLEhaW
UCV1mqZY46WKm98i1hbo/wAz7nBN8mlgemlqB8wP+WP4QP4wy/o9N/dLgffuDHCHg5orQumNHcI9
Aw6Tq6+oWfRVbDSQyVVHDAozRmcxNIiyE8tA6A84bEmraolaOKYRtIzRi5sFY5lW19mUGxHNbEZK
NMDFKwLcm5PJ5rC+7b0YCC21Jr8/KO/04KrYARzXAN9reNW3y5b/AM2+NuUDlKwZb7FJ1baVqWmt
mNzMNHGl1OdtUt50PKWBVOWzWsDxioygFm7gXGo2sEtYZkVcrMY1jmll1sz01L76ufhWHm6Pc4Nm
2k1/MzD+rjh//GGb8xTf3S/fl2sBhYKlWGpLIhUryTl5EgAcbOZ+cfCwKafWbcwGdQbFu9u9yOoB
Rt3b9vNgU1Ry9rA7DvP5N/617dPmvhaaoyglmvbaSejZf5iB5vlwaSZRcMSbbRc8xDfNYEjZc7d4
FhHWBBZ5Y+SoBzSvGryJpG8jxxnXamB4aIukQeeQTsYkk7nHKsVVrKAtJUZGzPUxmUkj/wAUhYQO
6HKCNGmWHWJJEptr1LzZI5I1rXjZ80+fi8UiRGR0JkaGmaWN3dgEKVMk1OiqJNYsbzs0UUcZq1jr
GKgTS2LxJrDrkGreopo2q9U75gBHJUniTMJk4oJZJRFVRWVa0xZi84fnBaQlGlNTNFEQG7rq41o6
WWePLEstZrnyCiqYWKVqxvypncNpZlvLJmcQmDsdDmTuYEgaVtYVUyLGVF5HjGK+KRaSqMkjyBJ5
Y4i5azxx1EAhnRGZyM8bOhZijM6y5I+Laioqve/BxS2k0A29xmPoXH8IH4/n/R6f+5XA3DzD78Kq
qAAFTOANwE0gA83K2YWrq9/Gqj+nk9rHG6vWOONVNtv8vJY8lTuzfLhqysG6pn3E210my1SkY+F4
smQeb0CpqRe1TPsdgDrpNoViqnfzrbHHq3JGTXTiRmrdYBUvlWOKVlgZe7HO4BiE8IYzGWVDKtFT
nXhK2tMsSPV1iiSbR0aqamUSMKvWCoC7Ty6VY1nclQhhniMRmjzVApa6tm2yVlWoEQLfdEqlpOIV
czPCC756VauOmhWc2R1eaGU01enFcRV1ayUuetqhNLTpUNEJ5gX1kGjHWKMlyiy62pre5Z5pzDTq
+oUJVND2Qrcq/dVaWMGjpMkdRK7u1Vo6qrJVjQut5WlpTDSQZuW0qI02blYNfWqaq9dUvxZpQTHU
yWkyT6HSIRGWWJXepjrNIGmBeMTvSnKQKWrxJUSyIgqKqZo+yIp5dbNKY0i7Iz0ms7qFUGGnjEs0
j5TCJVlqYKWJ4hKvexGS6NxbXToVYujxaHp6+qXIFMiOlTULSxU5V52kjngkCSRhmsQspOUNE7Jb
OhXkaOfSBMkikpECVFKt75pi/wAGFzh8whrJV/kKKWoiVlZXeUSUaRpJEbSxN3SrEtJOkFYipTTs
iJOFxKFR51W51dXWRIuZM+ogXRgR3JKwmzV00tTOsupipaaWUAmFwxW2S7quaqaFpCr6sJxKlqoG
s4ilHGnqEp0aWOLUa2OaojVUmQc2Yq0a3bMDypIxFFWSyCVLIUnYUeaGmIzGOrojK8WtbIiZtSCQ
HfVo+U5l1ojoTVpCeTrGp5a3LqyEIWi0mZCjUVpoRrY6Yk5Xlp6J5OcLJWaRmou876OKCONZ5Xct
3yILtKg94cBEWThBErC4NNVf3eOH/wCP5v0en/uVwNw8339cEC5/fmwg1k2/YsZJ8+/04zWjiN/w
g2enDHLDWzd8KIRB++5Uskc02pHJLZhFGsmcKYismVXMyPEJhqhVEHMaaWpjseSXWmoZ68vblMhM
NJU5kKlkyxnaJltLHq3Zb3AeVL7jmgnlppQRc2KTQyIbEq2XPG8kTJI/vvgEwXhFAT8Xqh6Y8cPf
x7J+ah/uY/eAJHuDZtGwnfbZiw2C2xe9Hg+bo+TBJbeSeQY9u3ubMHZP+RnUOV3FgGIuL45yec5w
TzkSBRICefOFUP4QVb3sMf5AAdQUBVHmAAAHMAAPfnBp2j0rG6mxEcv0ccPfx5J+bh/uY/cS23Fh
0D0YsOgejD22fv0YS23Fh0D0YsOgejFh0D0Ye2z/ANo4P/jJPzUv0ccNvx9/04/8/wD3LQBtpBPz
cv0RjSlDobTFTxms0jpCM5VXZTeDzXy9eO17QXlTSH6uPqx2vaC8qaQ/Vx1dWOwegPKlf/QDq6sd
g9A+VK/9XHV1Y7B6B8q1/wCrjq6sdg9A+Va/9WGOwmgvKld+r47CaC8qV/6v5urHYjQPlOu/Vx1Y
7B6G+Mzer5v+HjsJob4xN6PN+RjsJob4xN6D7GOwmhvjE3qn2MdhND/GJfQfZx2E0P8AGJvVPsY7
CaH+MTeqfZx2E0P8Ym9U+zjsJof4xL6p9nHYTQ/xiX1W9nHYTQ/xmb0Hq/Ix2E0P8Ym9U+xjsJof
4xN6D7OOwmhvHzeqfYx2E0N8Ym9U9X5H7/JjsHof4zN6vm/4eOwehvjM3q+b/h47CaC8qV36v5ur
HYTQXlSv/V8dhNBeVK79Xx2D0D5Vrv1YdWOwegvKtd+rDqx2D0D5Vrv1YdWOwegfKtf+rjHYPQPl
Wv8A1cfViLg7oI/+qaQ/Vx/mMdrGgvKukP1cdX5OO1nQXlXSP6t5vycdr2gPKmkv1XzfkY7XtAeV
NJfqv/0x2v8AB/ynpL9UPsY7XtBeU9Ifq/8A9cdr2gvKtf8Aq+OwmgfKlf8Aqw6urHYTQXlSu/V/
NjsJoPyrXfq3mxFoLQU3/qlf8lOOrqx2r8G/Lld//KqvsMaQ0Zwfo31aaYmZrA5ZqWSBrHnyyIps
em3T0Y4vofyn/V/0xTSaKoJOMJX6wqjDJl2tmHNs34//xAB4EAABBAEBBAIIDQwMBwoJCgcEAQID
BQYRABITFBUhByIxMjM1ldUWIzQ2QVF2kpSW0dTWECRAQmFxc3WytbbXICVFUFKBkaGms7TTJjB3
k6Sx8BcnQ0diZXK3weE3RlNVYGNmhsJEVFaChaXExtLxCFdkdIOE4v/aAAgBAQAGPwKWJMiKlHei
w+nVOPazNcmjuINJTtRN5F0UZjydU6ll24iVtU9q/wDCNwnEno//AKK+hfr21kDpI0/hPw3CWt/n
oNnxVJ8FZFI5HSR19JjATJHJ3HPYPjsbXORF6lVFXb1ylfAMa817euMn4DQeYdvXGT8BoPMO3rlI
8n0PmLb1ykeT6HzFt65CPJ9D5i29chHk+h8xbeuMjyfQ+YtvXGR5PofMW3rhK8nUPmTb1wEeTqLz
Jt64Z/JlH5l29cEnkyk8zbeuB/kyl8z7eP18mUvmjbx7/wDdNP5r28eJ5JqPNm3jyPyTU+bdvH0P
kiq837ePI/I9V8w28dx+Rqr5ht47i8jVXzHbx3F5HqvmO3juLyNV/MdvHcXkar+Y7eO4vI1X8x28
eQeSKj5lt47h8kVHzLbx5B5IqPmW3jyDyRUfMtvHkPkio+ZbePIfJFR8y28eQ+SKj5lt48h8kVHz
Lbx5D5IqPmW3jyHyRUfMtvHkPkio+ZbePIfJFR8y28eQ+SKj5lt48h8kVHzLbx5D5IqPmW3jyHyR
UfMtvHkPkio+ZbePIfJFR8y28eQ+SKj5lt48h8kVHzLbx5D5IqPmW3jyLyRUfMdvHkXkio+Y7ePI
vJFR8x28eReSKj5jt48i8kVHzHbx5F5IqPmO3jyHyTUfMdvHkPkmo+Y7ePIvJFR8x28eReSaj5jt
48i8kVHzHbx5F5IqPmO3j2LyRT/MdvHsXkmn+Y7ePYvJNP8AMdvHsXkmn+Y7ePYvJNP8x28exeSa
f5jt49i8k0/zHbx7F5Jp/mO3j2LyTT/MdvHsXkmn+Y7ePYvJNP8AMdvHsXkmn+Y7ePY/JNP8x28e
x+Saf5jt49j8k0/zDbx6zyTUebdvHzPJVR5t28ep5Kp/Nm3j/wD+6qfzXt49d5LpfNW3rg/+7aXz
Rt64X+TaXzPt64JPJ1H5m29cM3k6i8y7euKfydReZdhmG5SbFFKHfTySR1+Nx6S1ZeIQDo3fqJdG
PZfmLMioqudGNuOjRkqTevC1+C4r5g29eFr8ExX6P7Rs9GNt27o09SYp9v3f/F/YAqTL7Vjyq+uK
kageK6JIWJDPIjE6AVUYj5FRiKrlRum85y9ai2ALszKCOFhLCna3sWxIRAVAhA0yMmlZIyORip3z
VVfY2lr7O6yWoNiGGM5c0fBZnPFLlLhgmZJWVthBo6UEpisdK2ZvD3nR7j43OkiZllm6NotbOiuC
xnXfMIu4pEXSgRN1G1kO51aorpd5XatRnrrsfgWNeYduK7KrJ3bxR6ctiMKb00rIWK+cunHFHiR0
iLKQVPCPBGjpZ5Y4mOchwUs2Uwl1YfSNkwgbAhRQa5W70Z01sSNDSKPLuzoxYbKV+8FYtcxq1xvA
hnZlVqjZoo5Wo8DGmvRsjUeiPb0D2rkRe2b7C9W3rrsfgWNeYdpv8KD+DHaOB30rsce5sPQOO2aS
q3oVqSPYRcEatRY0kgjhiRY5N+dw4nX6c2aNEZ33UPqnc9pev7/XtgvJ3cgsI1VWJc4jDkDVYjp7
G2kIcTXwEbhZLYNI1LlBd6W0RnD3Y40QuER3bCzBxkbhClN7bpLe6nksSHe5ObXgd3WDXvW7VmOV
xnRHO15tsXaQwhFHtiriq8JgtdHYxy1sbrEsjrOIZZCDRM5Xh87YiSshqZRbLL7eMSSwn6FErAXp
WrJJDXklMsrYIZ8xqtV/CAPjmN4MpYNbCBrDs6WCvuzwY6+ktC7ECvhkHDrL6aYcEmYaU3pJGxug
VZ4Rgz7pevUPu7NiWjyHpGW3jpIKjla3pCUmarnvYCns6W5OKvKBHfC6aQ+vlqpkf0nyvpvIDAMB
sRDZ23nGFNhFYRXz0JQNecIUgxRzOPJIaMUPy3SAaQyapZdezSpak4fF3YgLlclxMwBeUjJQlUkI
Y235rc4bUj5cUCwTpNEh3eSTpDad4YNkUXCXUAJXAS0VoZPJboWMErCae5sqjUiUIkefiGV7hnRR
GS9HNISyXHSaGHhnF3wnOV0rRCCiaqCpsbY6sc1jD4xSpxRdyKaHtOOm90krk2w4OlIglxyw4r7W
drI39Ivs6K1taYYeV6do8RlWhRqBLB6QfV73URLtaq0Sw4tRLVREBiz49dTyS3lr0UIkD6C6sx5p
ub7YmvfYAFDwdQge5sUeVWGiOrbVtQeDYHYzWlikvGHMZI4w3JRqGaJwk40oiC2ljzHO6kp6T1Ja
h1d5aBspBcgMlAGrl5CuJinnRS2m2wHGI3R3elVnNdWu0dDI93MOLBCkk49Szlyz4x5g4lCnuBrw
uEhs8HHOCqiqwVpS6mpyR3LwRj0GRyqb0h0Y6MARUskrpuXMbFvXH1m0B3fWFpylcUqdZq7AtWRd
04OuPc/j1AzgxrSRHBvmFsLiE6eSIVeKRDTCXXV3evTXlIqi63ekbangNcOAgpFnV89zUIy83zE0
T+j3oObKB0ax28iGJNrXbD2BQDwp5k4e67gbj3f+WFSAs7iR/hU2dp1f4nufv2FOAqtn5bK07VjZ
OpbLsfap2/sLon8ie1sFDkNocFTyPn5wiuDGlsGcIUuaHdiiAOcnEnihiXQDr39PZ29e2beR4voV
tX8Qpd5xAW+nCF6te79p7Ps7VbYid1qUWO92EV3dpatV+09lXKq/dVV9nbHJCcgYAVX4nR0ZIJWD
2t7uS1rSmv4cyjruruk7q6Knajxp3GN0qIqCwmLFq8Sx+gkLlriA+PLUSWbdUHsIUkYnDIZJoxZI
04u5xXuYujpGz+m8rQIq8GHvedzX2OHp9q32NvVC/wCYg/utmxyFNZHI5sckkorZIo2SORjpJWQC
zzPiY1VfI2GCaVWIqRxSO0YseDRXt4weoGCIr780I6QC3OGklm6JOqohZzoaYZZoG1scg8jA1Ch3
UmSqE6U14zk1TXRYINU+54Lb1Qv+Yg/uti3lu3pvRAu8u61v/iTgK9xqIndVfY2iLie1ssWqo57C
JNFVNFVFDezTVOpfudW07WOhgiZYV9sJHDXWSMbat5LnrMtrLJGx2D/226MMjTmJtKjjydvJpChp
c8y70zuGTqM9zoCjYR3RQkLIVMroEZKizSa6zvX7ddQykLOqbSv4zhLGrWKMtkBPC5kN8R4dmJKO
SkEKTw2VbKyVIo99F4bNIiYcmyIO0jBlrz7ceenUyxGcXNYOGshzKB4bZRZiSI62cGrq+X40yQ7q
SyI46sheUIIZVVNOsMZEKODCpXvkrnQOKR+ssskkjy1sOKsj3vc/VXLrVm1p9gI+bIg7SwNFnrmy
gwB47cVgUooxjHR7m+4fmhyulWu3+2RdhXQXV2IeK+05u3hJrY7KxjvkgSwjsear3gsZOgoqRtBb
WIEgw6UXLcFmgQHO2PJCY+7GSIOOH+21ZCMscMR68h0gKZFMrpIya+WpeyRVe1yOXXYaE/Iby4YJ
ZAWIa2SUUb4nh961HVmP1bjOL9tzCu3vZ12qpZ55EfT2bbQfhyQI15zAzq5jX6N64mwnSyNRepNz
q7mww0PMxiiWltcOijmHja59hTF0hERE7GpKyuDBM5GudH6ZAKOEPFuxQxtbJITeXZ3FgxqAfmuh
RYYQcVO6YqQA4A6ysby+96TMS5El3e17mxFjBa2dZYE2bj+eESvcsEjq0KjUaNlnX2wLIlhFGesj
Y0tV3iNZlR70V1Bjzso4Z1MLRzlw2NE2oPQFr2jE3zln6aWQTfeSbJj4g7zgZHAycSJzmbPsQby1
CjOkiKLr41qJKk4oeOIVXohta8kaQrgwtmfW2ULpEij3tdxmlXwiSV6J6TaLvPG7Z1u/iOV/a9ax
Sdu1ftX9snXsO6rvbiuZALXhFxxuqJWGwgs4cZB7Ta2RIi5YvSllASresfa66bD/AFwSvJ5BY5JD
243bWB/SXFjf2vXFH0qT1L1JpB/Bbs8KEmcmFrpo4YplieocSdwKN4wTNRfu2HFsv/W7O/8AQSNh
L5IGjOlmgnSAcmJrCHDjmDFAElBPPDtVEFLhhZZVtkNMMPKkiPhjc3Tjgae16D7PTq6+5/ukewvX
t4cH4oWf6ydmysLA3o1RevFTepW96v8A4Ru632Pa9jYeJTApOVEFD1lxY6PeYAI0CJyq3sjfbxsZ
N99jXd1qbacyBoqqvrUN7q66r/4Ru6uq6r91fb29U1/xUsP1ibSP6RBRskIcPCXETFY1AZbOWNzF
TshNk3nutSeLvveio2Lcazddv+rq/wCKB/6xdvV1f8UTv1h7erq/4pHfrC29XV3xRO/WHt1nV3xQ
O/7eyIqfyoqfcXbl4FfIzmJS5Z5Y4oZSSp4RRnyuhhVYoIoxQQwxR2Ok4IosLZJySOMVNAMPCUSU
YXyIYAfLOmKM5M+w76yMoRoouRp7Sw06Q03R2DdyfRerFMm9nuPwT2d7X/jC9nedr7e87212XTFM
nTXu6SYImunUmv8Avhe11bI30JZLoncTfwTRPvJ/uhbJ/grk/UiInpmC9SNXVqJ/vh9Wi9ae0vXt
61sn6v8A1uC+z3f+ML2dvWrk/dV3hMF7ru+X/wAIXdX2V9nZP8Fcn7XXd9NwXtde7p/vhdWvs+3t
61cn/wA5gvs9a/8AGF7K7etjJvY+3wX7Xvf+ML7X2Pa9jb1s5N7/AAX2lT/+YXtKqfeVU9nZFTHM
m1TrReJgvV3q9X++F/yW+9b7SbKqY3k2qqqqqPwXrV3fKv8Avhd13s+37O2vodyTVU0VdcF609r/
AMIXc29b+R9fd68E9juf8YXsexsv7QZJq5dXLrgvbKi7yKv++F1rvdtr7fX3dvEOR+33cF7vt/8A
hB2T9pcj6tNPWL1bve6f74Xsex7XsbeJMj9n/wCgv22m9/xg+zut19vdb7SbdtSZD3N3uYJ3q91P
/CD3F9lO5t10WQr/ABYH+sHbxFkP8mB/rA28RZD73A/1gbeI8h/kwT9YO3iTIv5ME/WDt4gyL+TB
P1g7eIsh97gf6wNvEWQ+9wT9YG3iLIfe4J+sDbxFkPvcE/WBt4hyD+g36w9vEOQf0G/WFt4hyD+g
36wtvEOQf0G/WFt4hyD+TBv1hbeIcg/kwb9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC28Q5B/Qb
9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC28Q5B/Qb9YW3iHIP6DfrC
28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3i
DIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B
/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iDIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28Q5B/Qb9YO3iHIP6D
frB28QZB/Qf9YO3iDIP6D/rB28QZB/Qb9YO3iDIP6DfrB28Q5B/Qb9YO3iHIP6DfrB28QZB/Qb9Y
O3iHIP6DfrB28Q5B/Qb9YO3iC/8A6D/rA28Q5B/Qf9YG3iO//kwf9YG3rfv/AOg/6wNvW/kP8uD/
AKwdvW/kP8uD/rB29b+Q/wAuD/rB28QZD/Lg/wCsHb1vZH/QT9YO3rdyT+gn6wdvW3kif/WwX9YO
3rayT32CfrB29bGSfy4J+sHbrxfJf5cE/WDt61cm9rv8F7iJon/GD7CdX3urb1q5R/nMF/WFt61M
m/zmB/rA29aeTf5zA/p/t608m/zmB/T/AG9aWT/53A/p/t608m/zuB/T/b1pZP8A53A/1gbetLJ/
87gX0/2nGIgKDKEKUI0I1AkKFKQKvsmtc6tsLUCVkoFqARHIOfN4Z0UrYpopI0xVy6IjclevX3Or
COyE78pjF++1q/aptrvs7m97Krond007q+13Ovuqide1+d0PiwNLTnZNXRH2GaHQTvmx2xMrEKtB
kxCQSoqypRFnlPSzsOTEkjm4BSuRi5N0uVVUoGN2FaA+2Ot4Yq4jpOlp7aCdSCoxGDR71u0TRyyP
V0PE0TicJkBQZYxQpMUc8BI5Ec0M0MrN+OaKSORySxSNVixyx70Tkcvbtc3dXRHsVfYTr619hOrX
ur1dzq2rnIK6xQsp/OcKV0fRtKGyOS3up9yInejr0nH0gXhcw6VE5iHTrFjtrymq3nyoOCy0sw69
5pD0YsUAjSp41Jldvojkg4jWP0Zvue7dRjqC1oymx5CdQGRE3g0JrXC9KNHJAGDSxYd0qtY8yril
IB5ulWWxbKkw7gHWjR8nx8haNk8l20e7ryJKVg6uSZ9u0UkhK5sbop2v5hUVr4XMc1JNWtJ6Iuau
1UIjlTUrrME7kyEau/AW0aeR8EzXJu8F7Ufpo5yM7ieEb3F2ELdGwmCS7qKo1WzrC4KC3OGAYfpw
ZOMyGYqNZItYU3Ec5Zm6bF1sDK5gwNqFTylnW7xZyjCKJ96RFUgMriekZA4ZQGSM5qDVJbCRzo1r
FiKLGDyOhMKBLQAoYW4rSZxjncdGBlxwFPUcl7hSd0d2s/pXDWJCN+BjWwWVfMriigWpEWPIrywu
KhQzGslcqkDrAQhEHVNCo06vjRkav279m17epE0xaWms7ZBOYQbmujgpi+X5hzJWj8bg8PjujkSL
e4iscjd1cTjQZJfRRbw1mqkvh5Bk1JZW3Nu3hXJPpIA0TgKo7nsnUuNzmxcKQwmrsqi+Irbikp7I
AG7Aknr57jIQcf8ArxBuceLLC8kklg5McLpkDWBzh5nyIOlRBkVLPbKsv7Vw21dJYqg0soxbmgtI
5t7RShyhSHJBuxEDTxOcjon6a8RPtk7qd1F06+rq28In8qfJt4RP5U+Tbwifyp8m3hG/zfJt4RP5
U+Tbwifyp8m3hE/lT5NvCJ/KnybeET+VPk28I3+VNvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM
9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35
dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM
9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35
dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM
9+35dvCM9+35dvCM9+35dvCM9+35dvCM9835dvCM9835dvCM9+35dvCM9+35dvCs9+ny7eFZ79Pl
28Iz37fl28Iz37fl28Iz3zfl28Iz3zfl28Iz3zfl28Iz3zfl28Iz3zfl28Kz37fl28JH75vy7eEj
9835dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dvCM9+35dsqei672SsXVPcDg
W2N+6J6/yYP2RF2RP+imqd1NeveTX2W91PZ1TqVF69s3ibWY2zKco9HiQXaiDc0g+Um2jgxbG25J
5zIWilCMJjRZdBnvTuRLxDyxyRJZUyunyEIVt7e0PPCh4UNixURN9QRNs6c4h0RFoNMMOZFJFAkB
A3Cmk2Br3CxBcBHyPGgt7bIRmySyPe58d1chiGGTPfK9ZpJoY5XdScTcbwnr1Jruu06u6qIqoia6
9sq9TV7qO0VNF69jjiMjsautZRxY+CLURY6ZMoZLpJ7eaw9EVDcPG5lWgQoosu/HySOY/WZEhqT/
ANor4p+PU+J3LrG4OBKiSpMOkZZATRUlmwyS4EOSaxrWRAMkOCGV57ht8fYCCR1byVb2Qr7LYJxS
TOenr70XJmvi5LoceCvNCKu4xl3iD+MyPmupjIwUZQFehuNaLBL/AA+gNEIsnS2slyCGENZW8JNW
GmPhK0QUgiqgKu2yEFxo0uKIDdIIs41CbXS4njlBAPAsiSpPRGXcj3rCkMMfKQQWUIoUj17T65hb
Cipv7fJ1Lp7Pt93azqZ10ZYBEirL9tCssbkiI1RN5HCv3Zmub26LGjmJvIibYYywMrZ7auys7J8m
KHWdIJjLUPIYDlqm8ss/1uRcipEyVImRBMfC3itYiLyKQgOt6gEGCgyGfMsutGkm09sBZi81jt2E
4HFxz5wI3ldEGzoyJ8kEbeDuMZETIUMTWjAykCsR06kSZDZQ14d5aOhem7HHK2sSVpT3vJnMubZi
qibyzdxNsjpRXDxkW9FbVkMhLnxjNkPAnFapD2Ne9kGsvpzmscqR7yoi7YiZRUWMUxdTcRz2ZwFO
FWllgzUFvXEMhlBrY3Ezc0aLOyOVN2cHiGucwmFjViqJIQeaBfjkI187M81tOaGocpqbaVkmNWwM
4mPRlCgOmQavMLgUlGQ7w4qtcPK9BKUOlq+ydnd9MbEST09Ob0nfU8IC1vINEDjdDOksdsy0nkdW
QR1fJpG9srV7ndXTTq6l9hf4X3+rbuJt3E27ibdxNu4m3cTbuJt3E27ibex/6DZJ7oo/0BwLbHNz
cV65G5E4rpGs68J7IaLq6KEiTqTVU3Ynaroi7qauTdXkOvc/4ew/6HUvRPUqa7yO+1VNdF2Vd8Lr
Vq68wfvMkXiauRUpk60aqs31aqORyIrU06+pQE77uEWn26o537leyqIqa67vWidqqt27tfvewvFP
RV9pFXof+dNPu69zbvq/q6/D2P2r3N1b+1HbaK1vV7Tu71daddev8HflPXd69er9p0+20Xt99NOr
7u3azBq17O6pNi/WOZqu116IRi7ybu7pG1WNdojtdHbd2u03lXddKfupruoxiftNqjGoi9S7znPV
HbyaabKmtcujdNFnstGP3Wo7c1qFezq3tztlRurOpyM0dLOWVVDDx6LNMQadBEki67ivmmq2Rqr0
c72WNdK5XNbvORqaeizC0+4uSxNdr7KKx4jXpp9xHfxd3bVMswvX2P8ACaL+f6zVdP4Wia6a6aL1
7NICNpjhnLweYEsDCYHSpvIkUZDKuZJFcjm7yzL22/6WiPY12yN/a/t10RiTWPf68NNN+qc5i6Kq
byS6Ivbbj07RV1eDvPVNfrqxTVNU3Vdv1LHO7+RXLGxWbyOmc1m8vCTV9cmvV6qN0cqoxW7n7Vb7
0Xef1ozq3Pa13UdvV6Kjl3V49h3ze2bu/tR23Uiv7ip2vWiprsm9ICjdNHKpNj3ujNdeJTvb/wAG
1eprXapo1zEXbr6OT+HoSboxydrqqTVu8zdbr1pL1r9oveLqvI99IurCLSRm8qosujZKldZNxGSP
lFjj31dJv9pvKsbbO5xqtWZquiafdco+RE6l3Y5gmyp173fsZ1N19nTb12YX8ZYvmmzIosoxCV73
IiRw5Ak0q+3uRRhOe9yN1XRE9jtnNbq5Ota/q77Qox25r4NFRtWq+mIkioqIrO06nLr1d8B7P/DW
Psdf/mjZnWDo/uLxz+v2+ror2O7227tpvV/wg7XvWL3Eql9lyp/9XX73fAf56x80bd8B/nrHzRt3
wH+esfNG3fAf5+wT/XU7d9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV
/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/
AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8A
CTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJ
O81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7
zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvN
W3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81b
d9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt3
1f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV
/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bd9X/AAk7zVt31f8ACTvNW3fV/wAJO81bZJv8
Pe9EjfBPe9mnoDwPdVHSRQPXVuirrE3RdW9em8uOfcyKRfe4N2RV/wCzZSC+tV9KhgYms5Uzt90c
UTPa3I3qTN4IPhkSTO5QQoqExcgfyszCpFFjHrTpGMDdHA9m9OyHhyQxv5mPmu13uBvcJvE3WtLr
5UIGc7d4m6rNF1/gO7fvFbJ3vevbtIAWRO0qNGb7Iqq3L3VfFxdNQQCutrXMX7u83ubWLpd51Ahc
cIbpgCq8oMVgISkHqKdDAcQMhamxFJGLxRuVcRuSic0QG16bjo5OGsckb2vZLFJ1ceJ7dd6Jr+1V
2ie3p7G1Gq9arTVSqq91X9GBI5yr7O8qOd9ze+51uUcOadXStHYQke9DBK/iaPnb37UYrGLpu9fE
b1p7LYSohZSYZXRGTQzaacNdXokCwJxzURHxcmBKb9ct4PH+22xsVyawlZHFBPF9rM2GhuCG76ez
6cPHIiew5qd3TaZjauTSCWeNU5PI5eocjg6s5KiJr9Xx+nI10z1+0Rd7R6Ro2hJm1VFdu1uQ6M0K
FH697GU19VMk/wCi13/lBVJPaNEkA5f+5kcsTdUTiFZPYQlP9pvHjHHR24jfBaLvI7RLSaFyxyxV
pskbm9W69sJb43J7KKx26vU5F7XqVPYfxUuIYN6xiSV11aRRSrXEcsWsbJsmgi6nr6UiQtR/EXd0
4XXXEV9mdNxLGKtLCks5joWQwUtwa1zInGGKm9JG1Efuu1cO/wBlNUx3q7lmS1f+UjMcvVXe9hd5
zGu7nUqeztkU8Ej4JoaG5ljmhfJDLFIyvJVj2SRPjka5qoi9q5PaXq1TYF1naZuadYkSRjMqr+zZ
JFE+clHGTyIbGr4IkTR8LPTFTq6tsvBSxMsRq/o+OGcs8uxZxEPyAOWeGQ0gl0fFQMZ/pb9FbHpq
5F2zIoiNSXjH04YzN2eRdyWmqHqzhQDmTv4hhayfWQc2iu07bbXouTyZkn0X25EqilhgIfNAjiw7
KBJmt5/VU5mnHhbvMEhkYriWKiHjORfrew5KvlldvyPwjBZHSORu85Zh7t0iKu73qviY7+Hqiavc
ndg5pzmKWRAHBw41kXmSZIoo+99hskzNV2zUS+jlgpaCSblLasqZJGOY0nhxNMIV+hDnjfXG7FEi
wroxd/TXadYiuch0a+OZWRN3kcQZH3GI7TRYN3qf16fxbdxNu4m3cTbuf+g2Se6Nn6A4Htjif+0E
36CdkbZDht55o4zoGwLI/dkhc6PiRMTe0innkaOpLIkY0qRgsBCSMePcCEKPOg8Q03LSI88gDfL5
cQvWMZ9BI6N2pHD4sqK/Vju27Z2vJTyoRM+ff1j9PVqcsNV9+nCXu1vE7v2+vdVdrCygcE+EyeAl
I1McLMiclXA7npVdYaemgOm//wAmnerptJSwRsQsJyNIY2eaUeCNww8sRz53B1kjBB5CHRcNj0Je
VAsILoyo5zgRwI3ukZC1zOK5EbK+Rz+IrmxpoyKLf60hjayBO4kaJ1bUP4iql/j6NF2eAKVAEM4t
HmTujlnNVGwhPTlWaRp3zGr9co/2fYc7UwCHiJFDXlRpxV65JJIHvd1728ur5HP7uiSLvpo7RdsP
RP8A6VfxL/g5kqt19riq1kKfdemnXsE54kfC6eG4siibsPFTsh8rPvFuoOshw/1qoq5Ai8Dt0q0d
2+11FYY/URV8EYa1bmVle6OVn11zLlk3OI4p2sCrE9+4zqc2NIJYzjl1Tu0/YmVf+XvZTeTSLD/6
qOONdVXt+1Z19uut11Kv7VHL1dap9bFdoiez/r2kaS0gONxxKsn46RQdtYWhMW7DBk9dIzVpDVkV
u7xuWISbfbyHBrGqrnuiPEGVJJY5n8WCqziaRXbttdT6KhLId58rnemN0XtGpHjn3bghP4nY3kGu
2WKqIm7jN9J1u3dGRVpWrpZHeltdL7DWomnsImxbOkR6qR9HbxDkToVxmTOMe9GVzh4WOHs5InuR
pLu0TXVmipqmUo1q8KEPHo2aNe/VXOyd0nE4aSbisdorlm3l1kTX2Nsua5iSQvyzEmSsdE2WN7Wi
4ak2897o4lYqPb2yp1bz9F7XqyCIqhqEpxkg6PndUgsXi8gK6ZkG61rphlI471km33tV2416Ma1E
x2dBWo/gULknQJGq90mH2056uMbV16dUywtl3r+54b2N4/R6p11i9XXgmDK3TXVd0bINGLr3NP5d
q+SGGaXgkNk0Hhnn03D66drk5QUztkZA7tu793Y6GopOZGv532RwfEvhy6+xOj49jGKWOLYOMZKZ
27IipK2EZvpIrIYfS9ljg4kbo0bFOHLFNHKHPxzCp4p+PLM5J1JLnc+NvDgZHwnAxrXSBzTfvf3P
59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5
/Pt3P59u5/Pt3P59u5/Pt3P59u5/Pt3P59u5/Ptkif8AtGz9AcC2xlsbmse7JHNRz0VzU1wjshou
qJ19aap99dvVY3c09QS69xU116T139HPbv8Af7r5G66PeivcwkRj5Hb8j2Vz2Pkf/Ckc2yR0jvuv
VV0RE7ibLvFiu1/hASOX2V7q2ar3VVfvrt1lir1ouq18irq1EanWtlr3Gp1dzXr7qqu0krJQGSzL
C6aRlYrHyqOiNg4jm2KK/gsa2KPe13IWMhb6UxrU9VjdzT1BL3PKfV9/u7QCjkDRwDQRDQM5Kd25
BDG2KJm8+0c927Gxrd57nOXTVzlXVdnSTR08sj+t75KRj3O7Vre2Vxy69qxqdfte3rt24GPv7vfY
9A7vm7i66mdfa9XXsgs50UToCYDBZxxdCRDBt5IZW8Q5Rn7qPeixyMfG9HKkjHJssr8pIfKrlesr
8dwx0u86TjK7iux9XovG9N6neE7fvuvb1zzfe9DmF6d3XXT0P6a7yq7Xu7znO7rnKr2vsksZ5ZQJ
pSChGKRvVcqTgtY2sMBDhhglTeQeGJkD9XpJG9sj0VzXFCOa5Ho5q18mjkka5j0X9s+tFa9yfc16
tNE28W453Ud62xu61ERF9V9Xep/J17cYQelFm0VOMPRxwS9sjmqvEjOa/f3XuTf3t/Ry9fXsNLIQ
M54kykDryU6cOZwxAiv0S0RHfW5U8e69HN7fe032sc2UYiYGceaOSKaCasdJDLFLG6KRkkT7JWPa
+N7mqjkVOvXu9e2iY5hyJ1dSYhXI3RqaIitQjTTTup3F9nXabokKhq+Z05jo7H4QuY3d7Tj8sbHx
tN9+nE3tN5diDY7maumMZAw1g1UDNEW4ZsbYXcC6isoIXsbFEm/BHE93DZvKqtTb10Tqm6rdFx3D
FTdcmitRFx/RE09rZHtyg5vselUeLhvWPhOh0hNrqkcsXdie5jFGniWNF9LVuycrIJDuiggtRoRG
iC1rSGBRIjrVURIWlTpvd/Jv+muerWbvqsX4BJ7Wn/nP2ttOaE01VdOj5NNXLqq6dJe3t6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+
cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+Ay+cNvVYvwGXzht6rF+ASe
c9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASe
c9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASe
c9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASec9vVYvwCTznt6rF+ASe
c9vVYvwCTzntkzZHNe9uTK1XNTdaumC4KiaIvX1Jom2I8tPILLLnVKLx4WwPkZEZR5mJPuITFNDv
PgmkjRXxO3d7ebo5EVJSpclyBWxbjFa2PFt9XkSMHi7+iZE1ySysVu+9keunEVWdSyT1OV3dpDE9
sck1aT2PS42Pdq9rHrCyTdlkiTiNaui8FzXbm9rs4gfIchiRJlg3CWYsjt/hxztTSCimRUVsjUXR
+qMVzu6muztMmvPa8FjerVRzk+1x6Zq9aPY/Xd3Fj03NXKu3rmvfZ/4HHOrTT/2dd3ete6n3G93T
1zXv+axv6O7eua9/zWN/Rzb1zXvteCxvX+L/AAeam9/B11TXuppsv+Et93NU9JxtE01XTT9oHb29
3VXXRE3E0a7e19dF/wB3XTh45pr970P6beue/wD83jn0f29c9/8A5vHPo/sv+E9/ovdThY5u+99D
2n823rmvv81jf0e29c19/msb+j23rmvv81jf0e29c19/msb+j23rmvv81jf0e29c19/msb+j23rm
vv8ANY39Htl0yS8TVd7qgxpOv4vdX8W3rnv/APN459H9vXJeJ1buiQY0iafeTHdNshH6TLN5PHhL
MWUyKtSWAmZ18x+nJABxPZ+14zkbNFJo5Hde65W7VNt6NQh+lK0Gw4HoUHl4HOixE8Hi9LxcTh8T
c3+HHv6b243XRPX2F8UB/PW3r6B+KA/nrbjOzgR6cYeLcZiIKPe6aeOJjGrPkMEaLI97Y9XP6kcq
p19aRjtzUdjpJXDb/oapCGsJbDKS6NyCZKS9HJGzRu8xGaRu3nbyt3vX0Bpqv/igP1oqN3f3a06u
2+/rsmmcBL16dWIjdWvVvaLcdsje6rUcxdOtFdpw3+vkHRU1RPQdC1zfY7beukVUcqKrF4bOpF1T
ubJpnIWvsJ6EB+v7i/tz/wDFH16dv7CtVc6B0XXrTEhtVTcc527+27tHN3e03UI101dG5uqpp6OA
07vdxCHuo9yaddsxN3TTcf8A8NormtYjV19fQPxQH89bevoH4oD+etvX0D8UB/PW3r6B+KA/nrb1
9A/FAfz1t6+gfigP5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J4/nrb19hfE8fz1t6+wvie
P5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J4/nrb19hfE8fz1t6+wvieP5629fYXxPH89be
vsL4nj+etvX2F8Tx/PW3r7C+J4/nrb19hfE8fz1t6+wvieP5629fYXxPH89bevsL4nj+etvX2F8T
x/PW3r7C+J4/nrb19hfE8fz1t6+wvieP5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J4/nrb
19hfE8fz1t6+wvieP5629fYXxPH89bevsL4nj+etvX2F8Tx/PW3r7C+J8Hnrbiz5uNLDF6ZLFFig
0EskTO2kjjmfaENhe9qK1kroJ2xuVHLDIibi49VY8cLXz25drA+U0fmYEYEC85uqbj5UXSB7G7ns
ydui6IrfXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXk
kj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkf
N9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt67Ma8kkfN9vXZjXkkj5vt
67Ma8kkfN9vXZjXkkj5vtkm890jun4VfI/d35Hu7H2AOfI7caxiOe5VcqMYxiKujGNbo1ML/AMoe
Nfc/czLthClPNZWAMDJOrBBVKlslfMbHE2OLVruIwpgc7ZIl9LWD03QVSdsiDArpx+LJWzLWEWdB
FrM6MudOWLhuH1hSPHe5jeVLJlgjjGinZHIum00hm9GSpcL5277XvbM2tquPE58Tp43MYSyUd7ol
VjmRr1aqrtsgucoEqrbKajK78Uie3aIVZYsKHblRY9BX8SQuTHQiKCKrOgUSQTpJCX25TnkGubEG
a70P9AWma5DhY9NGGb6JA/Q/JcjJcF2zraUQ/jOopjZaqCjHcPW2A7+lZnDPlIxFOLhAJGaYrYZI
IqUt6YynWn6J4ohUS34r7VbXpoF6cKaokpN0sTS9fGhjUsa30IVkIfYpo+yVYttBrc95EhMl70nW
CcocBywPCqWJBaKywIDk3m9F2rCY5hcmmQUCFajK8Aog4yYykc4bLvQfz3NKyeNHkQPyGwGBlgdF
FBOLBzkcyRFybO+uAMou7/sp5VitQrKhWJXuFtcnJNRo95n1UGfA9aVQ6apkyXG5AIpWQo62kFig
KFpLkGopGhYjU3t+HKG4i1mPsbPJqpIQ5q/JbGqrB5OiA7Lc5nIXCskmrVKLkkbYC9krLTHyrSF3
NZQ20Uab6pYQ4FjVjjMsTdUajyyVsqJjV1eVYXFQPHurrvZ6KLI0rNr/AD2sm5R9ay/YXbWGBUuR
3ggsZuW4SEMFWQNN5Oc3Iw4B68GIaKMsqQceWS6qx8UEiq+xTSdkezHPEs7B5pJLsg5+mAnCuhIA
4J4qZHB2T+k+Sf2rxLWMlJhKisAFgOxcyzjobGZ1XCMQBdSYsVk3JwW0mYc5ZFMHYDK8cXBejWwF
vjdkCGDSwbA3VizFLSut+xzl/ZEEqqZh49mBFRxU84FQVYT2Z0BzVbYzQG3MdZXtkJgkSKrGQZ6T
Y/EdTUlcdk2Ug1FbZ2QAsVe+rOxm9t5i4azHOyHmTiZK4iqglikmv69lyOTybR6lf20Zj81y3GZa
2wzHJcCNEqq21hsFssdhyVyXwZhVyTBEHYTY65nQEoBE4UZLXdPmuYrFkyx+M1Y1fauxZ2NzmRgx
gRrf5VVUslcSRUZzkVnavjBs3ydJT0WJPFLCehNI98ygjUNGt7j4R9L2UYsfsTAKC7irb0E7seE5
OFx6v0YpNDDAwggcqvns7CIg+GstIpx0CeCThlUS1HgRhZNknDcmsUtrSLRBVfEavaPUZL0ywHRd
XRGBjlR6SDNezCLECMR5stRhdQJJYcTo8Qi/Pq6SI89sMkMsoYDz0LnHjnGeU2HlmliLLzMT8anl
xmbIX5kFicGTRVtlDjcHPY0/KEmNoH3s5rbGOCLouOpZlCc4UXXl86Kwnk20lcMtXdvFkxaPM3QY
/wBHhjsye/ZShFDH2Gfxk1ql7prgq4KmzclJREQ+UOAqCZc3/wClnP8A1l9lbbEt1ev0OUPV1au/
aoZdEVV0b3NXKqO7RHI1N5UVHDiDsuMklHcXBV8SVsA4rEV7ybCaKDejicrUHEiiR5JDpOKrWjxT
Tx783NSNSJ0ruWBNLXdZNBE5y8kOSxqrzLJIo3rG5YIyCl1DENIEaHj09AGKx4TyD7KUO2m50c1h
MgTAQMmqYt+OKMdXK6za9z51idCP6VJJUCW8VbEa+WrD49MsMgxjuQswmmSQsMIkhnJJsoIlTins
ewd0/GRXNibVWMzIJKiaY4SwXVyTsnbT2B9U0Wdzki3jzgIqmOKWJ7pS7EZkbt9Wo5ILWlxsk2oP
xEDJRTBJzawfIbHsiiY21QoJid+FBwhTbwXmpZCRXmUM+9Mxk3NZdKwSmnMxYuootY41ggt7fIsn
6Cr7sVtjegjQ0tYzfAsBzLiLn8tCu8dW+poMffaWGO4/KDj9Dd24eXmTFXlTIVFyuPkY40Mgejxr
OL2NiEdMThlDz5a57JEgsGP6lp5sAtoaYOPMCBsTy20vRmRqZh1Zxh7VBILeReYY3IJh1poqqKRH
2lSSeXMLHBE5Hd7ommnaorU6kRNN1V1amu9utRN3Tr7q9f70EfgJfyHbYL+Mcj/MBu1UHQX1ZjWQ
ZHbIEDc2zq5Aq8UIaaxsSZulmSArvxwRV7OMx2s58KRJxlj2wCcevtsiyLNqZx49JRtqkKTo0ZOn
SiCLeypKgQYI5rhfTTopZp3sjFHl0k4fZMoeibLHAcTwaC9gv4A8eubWrMIFNIU6evIydK6whdwo
oa2viY5ziopnWc4ossb2sjnHyCxCrH43V5Hl0YFWPS1dzkEA6jQWUPSzD0lc8gdx609dZ19a8yKK
Utu6/cYLLUZMAFJkV/isd2WLUurZLvHByCjhWQhXRly5skAyuEmSo4UzpI4VdHPvxsS+qa6wDq5F
YghB5OPT83q1VkRsdFe3Ugcw3atJEtW15sL3tY4bVH7n2Dkv4/g/6vcA2wr/ACg4593r6Ky/TZCa
g0QZiVD65d+3sgSIpJlsGyERNAHm3pYYyYpYklRUWSLRerXeqi5SqhsIJVY+bl7y6lmcOLbdIEPa
wirdE+Qtn1twXqg/LwQd67eXZF013k7jtW9atTqVFbqmq66+ldSKq6IurXCnn0mOH5EHAwgOwsKq
tLuRR4Z5uFIMTNDzsTBpOM1ixPR0Msi66OfJvEZOHTUPTRzHwE5CGCAtobCxY4eFPbwwtMnYxo0Y
6wyzSNjaNHD1NiRFA5arrxuihZAK1YBB4ejgZ+X4wYO5EnKiz8oIko8HDjk5eDeavBj3W3RlLQli
A0VBT0tUTRAyj0ctDYXR45lXxo3xAyMS4SKLk44Vj4Ldx7dxGpDc2GNUB9wM2Jg9qbUV5VkOweVZ
x2QHTjvJiZBM5ZYWxytSJ67zERdrWEnFsdIhvZoSbyKekrZo7kgdyPHntWSDObYTQPaj4ZS0lfG5
EcxUXZjKalqalsQsYEbayuDAbGDDOQTCGxBYYkaLESYWRGO3SJk5RErWI+eRzinrXAq44oU41yiD
7xZoKDNCLKXh6kFBoGGgs8u9KOgoyRObwIt0iK2x2is4izILEuOwqQDYyrAUdggpxDCR5GzGDCxx
jQEyI6aEeNkMb2xta1Jh20lQ0cisZSzwNrQ0hnp4+Y4dTNEkO5JWM5srcBeiit5kjSJONJvJfJjt
El41kUbbroiv6VayCLgQMSx5fnEZDB6TE1JtI4vS26M6tjMpOkxbmJg7ESAPFMNjxMWR9yYMXbWd
26S6viLu3L6PAgQx0wbI4oyt4eV5auiToXE8aqN0th6dF0VWBodFAQLGanKixaFximFjMJ8M2Aoi
Fr0jmka6Hcq65vL2BFuPuhDJwLUzmebs4dI/S7ArnTOYNZoTNzZPEkdx5d404fEsZgOs5mEWJkND
VRFWBERsVnFOaQwVJSpo7GGGwZLO972GxRFNVJ2NehMdlQUthGYYNYlsOqgS2FWAcMQ4ZxLZ4JEn
MFgghgGJkR00EMMUcT2sjaiVJj5SByqU7nQ5xnRI5UkglFLDnSeGeOUI4WZ8JMe4kielzjTDlQQT
x2EVZhmKV0VuM8K1jAx2oEZZhya8QSwYOHG00Z+87fgJSSJ28uretdnYy3Gcfbjb+t+Ptpq5KRyq
QherqpBuQX66RCeuD1QiTeETe2rJfQljPFpR4xKeToGr4lSLDJxoRqx/K7wA8U3pscIqxRsk7drU
d17ZZEIPANE7FICXRjxMhjcQYdmJhk6sja1qzFlzzlEy6b85E0s8qukkc5cT9zVF+axduk7bFcbt
LH0n9sLCkrDTV5b1PqUSNJOvA/4HV/pX2mm1gEzdV5gRIjeKruH9cwvi7dUbI5G9v22jf+zaU4sb
EZoYAIR442DFyTwBV8ppjo4GR1czlWVxb9IoIZHO3mx7jo2NjQC0khxCKMIyilc0Hm4yYoqq3Lty
NxzaXcIKKlOKayV/Ly8CRGy9suqJDYhjmjxTCkpGXDEVGk4UsBgk6xkMcnHFLijIHlVqPgmhYQx7
Jo2OQtkrcdm58wc45jujpecsK6QeQIwpiorpzg+UBdDPNE6UZwgiRztcLBpy7aKm5Na0qqbA2sC5
ZaizVsh9a2NIuF0ce5jHGh7nLlq2NZ2SbjdoUo8coqdBub5ZKqpBr0H59R3HcBBIIeDzqhh85w93
meUGSffSCLdGMfhGIvLAjGhAKdjdO4gGEFrWhRBzKGsgsQiNag0cDmMhaiJGjUTb/b7nybfx/vQR
+Al/Idtg8xE0UELLHIt+WaRsUbd6iLa3ee9UamrlRqar1uVE7q7U2ZFX0MlhQVljW1ga2lb0ZB0q
6PnT+Dw+ZU+SGNovE5tIUH1by++vE2CnpM1tKWxrLTILCsswrfGZCABMml5i0oIxbCmNqZ6NSd0o
aA2tKLFIYkkJzVV+9fHk5eWPLlOKsxLImB2eNMitQ4YiooD5ePVESDWcHNvcx9fIGE5WRNmBkias
bpGNycqGoNLorK6xyO4oeh76yx6MeME6zWSufaskkQQRxo9ZaVwBkgzHzBq58yygPHysyGWtzW6z
0SZLige9l3eRSREMVstbJC8Afib4kDollR7W8wQSzeY7IbAHIYT7LKDYDrg40nGg3TzDROjj3Asd
raKph1dJORPMyvQosoiacsid7kVvjer+Hi/3u3jer+Hi/wB7t43q/h4v97t43q/h4v8Ae7eN6v4e
L/e7eN6v4eL/AHu3jer+Hi/3u3jer+Hi/wB7t43q/h4v97t43q/h4v8Ae7eN6v4eL/e7eN6v4eL/
AHu3jer+Hi/3u3jer+Hi/wB7t43q/h4v97t43q/h4v8Ae7eN6v4eL/e7ZN+P4P8Aq8wDbCf8oeN/
mvLtvZ7umvX1J/Ki/cRU71V1VN3e2oq+3M4Z+RWQdVVhMaspMhBpMYscz2RqvCgZNIyJxC+l772M
h9lNtOvXq1737ZN1etWq3X+C3Ttno1OpirtHAVOkh9e+Yo6ye6b6yrccuI6+6nFVd8pz74mt3liR
+5HHMXBE2M5LM2zIZvxuJHushjnSNGaROLty7IdGK1kUEnEEOFmXg7sTeJwF9NieiVTumL3GMU5W
1luclx+qprUitPHeJ0f0vDcVN/yeNKJ0pPY20dK0cGeECQ+7ra+SWSRzuEWQVHkUOMvjEGEkfKXI
BBdushmx2JUUtMuPzsyJdw2Q1lQkyNhfYsQFMHPpMPuiKzLshStYTKXhUriq59DaWrCKxR834UBE
kgbZWNse3hECshyxGWkgA0mRVW/MTNjYWRFkvEMx2aUyXFh5iLcIOnS/9EcU0bRDUhKtqerqSHD/
AFvZTxEBzlWUk2H5wxKisHyKwa4CkjePihSErBk7mS5CxyhO5IxH1KIuWQKNNx8di3ddr2+oMltK
AujoLm8GkrBseLisJA6ucsWE5l/R3SKJxImuXkeRIc1zk5jvd2iqp/Rb2Q8iuRDLSGAeDEB7Xo8N
gSnkyvT0FY7CCFMeELCxXdIkSmRtijM3J5IYCa2myW+G9D42U2s1UECxcfoi5Co4S7Ua2s6s2SZV
r7PWrphra3b0cTqBvOFQjJhiIT8gZPl9LQ4jV1fQAZEjT8EqMkfEwu8ssfAfxJHnksQ2zcbK6Vow
ccqNZCxjnMdE5zWuWKTcV8aqmqsesT5I1czvXcOR7NU7V7m6Kv8AiMq9xtf/AFuWbYn7mqL81i/V
UhsMk7uMJCyCJUSSR5JMAjGsV6oxF1kb1vcyPq1leyPfciEDSJKziK1NGyQSR8OXdlifHKiSRPYs
e6+KVjHbzHIvD39yOMlRSSwyZ6+vKiHnjEm4Nuy645O9LU2azOjZVcOMUbk5mKWsskzdyONJCaa1
uMwByaSxlN6RthbSCgnjnCmSOlYg9dICNy9tJ9bayNVjBl3FciObWtlYrZ214bJN/XeSRsMaOY9d
xdPTle1dFfonbNTRdUL6QJidjl8t3HikboI4HCvxE3o05JSGRcSZ19oXbwcwq8IICVR2saj02KyN
MdyVaLmKmGnsmj0jm5Ey6txKcAioDZfvsuWkmLhJ4tuFS8cGWOYXfVetRZMdyWIcSemAvrLgUs4O
N299EBMFWWii305REkEdnWyWJtCJdUgUVhFLPcxNGO5aCsbUZGGMVkN/iwuQli1cdLLfUK2yFAb7
bOaw0lipzC68zozo4hjIRpD2WDpgW49VAB5JcTWGNU+QE2Vh6EQSwq+zjJYMZeAxWtXI6cl4kjiE
x6lJBgmciJwYpR4VtKenzE/HRa7C6K3BgHrccNry7iwt8oEdLaLZUdhYTgblUC0gastKmV0blYOW
ITLx9sRbkCcvc39DU3FhDEZRV41dHYTOD5qMO8vgriyGlJHOliDxwXJbccQdqkBrLMKw2WxbHfiv
lq8yKlZXj0kt3Sx4a0ka8IfDYlzVLi68+JgcCblkCtiSFzMctcs8my1FfU3FtEEwVt1fDrSRVFMQ
WEljDCbIVbBkFyuBlEKkSgCuGjxnCcwsKyLpZk16FloD0e4WKCzw+Wa1jtLWCmEkjjZlK9AbxhQi
PizZcVJjYSzfgSSMmOAcmcAqrmmibJJXnPBkMDc7uwEPrTLAB0rO45RDiof4Ezk/eEj8BL+Q7bDJ
Ynvje2xv9HxuVjk1piWro5qoqaoqovX3F029XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1c
Z8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vNvVxnwmb+829
XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vNvVxnwmb+829XGfCZv7zb1cZ8Jm/vN
vVxnwmb+829XGfCZv7zb1cZ8Jm/vNsm90An/AFfYJrthX+UXHPzVl+3c1XXq7qJr3etzUdup/Mve
r3dNoc2PusmKsIbGus4AZDq3oyGSrIjMChj/AGpYcwGEyEefl4zUjfw0Y9j4nPa5um6qq/d0+1VV
RV0RdO27XXVWtVdNddG7ypeEDVxzCg6rNkinlDIZASZZZM+0peTKIjQM9SAuG97Rp5mQJGyCVIOH
HEkrJg5gI22JHIwEwTCyctKkBE7+DPLPO1HnTH7rpZF0TdbFuQcJjWQtybIKIVw5Qp0FN0PuWQxG
76UV0tT2xEMjWo+NpNTJW2GkjnRnRyNh0KvUqy6QSoohMapIiCxCFPkhfPxL2GGEixSKKGvlgqwZ
rNo9zLHIelmFEnLSSqT6JchdcyZMLlL8hbDiYh0tmNVk07tQq7FxaCWIurNOHLkIqJTyGkb0hquh
gWLJK5mS5ONj+UR5Ch2NxyUMtbDLk8RDbMoEo3Hyb8aVxBU9hDB0w6vHLfusCUTeGW+45Fi30RYd
BhBvClGbwqofpjcIF3xH7lgvTRW9LLxhvSx9BE3ZOLY40TIQwGzpy6SeWB0bS2CmBPBkkhfJFLC0
hIpFcxz4JI0k0V0Tm9rtUGCXd5jtrSCF1wdxSOqXGOrT2iIaARDd1FzWTQkSV4BHE6PQuCcSNwhI
7XzsmgirrXIaEXoEXF7UWpMCVuQUITyXwA2xNpXWdhHKnP2SOtacypupOkSnPsnSIM8fIwYbi4qR
MqLGIuRghsXNGIHFogceZWNGyHG7seIBwleNM7di5xC2q+IyOHSBBw4EckAsEI0KOe+RyRQRtijR
0kiue9yMamr3uc9y9blVV/xOVe42v/rcs2xP3NUX5rF+qsI0kcM7Sq8mKSWN80bXBWAxiK6GOYd8
qekdcTZouL4PiM3t5CBXt5uM10jz3Fqwnn3EMSOZxG8xkL2SRtji3GxMZuM4TYkjjaiEMmxXplkE
rCOSjq2GDEzykzyOIbFPRWEHNNmsTSZZBtwiWQgmR8iq+RykwHYue1XRkPgM6Flq4B41Sqa4CIGv
xwODSZ0DZOM7XqEaxu61NNlarphXkjq3iRbjSh1lYrdYeaic1srfteJBuovWrVXq2oJqbH6yossd
mDmHu66rq4LwxBhpQjILWxiCQk6O1CImHP4kqyTOmWffSZqO29D3T+QkY/CVREVFMQ6jUehjx+4E
ua0KrIioI7SURsteMIrbiws5BhIEYPJErUk2JsktbsUKysK65uMbgnBWiubOqaI0KwNZNVvuopkZ
W1zSRKq6DBMStDZYhlwzFsIrlQmyc6qzC3zIdzphuI6yu+nWPDmkaNv9HRpflxCQwqhTNwJ0pEjW
zsmw6JtvcT1mERAx09PNBjnJqXWjkCQWMx0ePRXcJLopt6eCvsw62RYWxcpwJJ4yJr6LJcnpX2FK
JRWAlNJUDjn1gZNiVFHISfSGXVYS51uW3nKKxqj4lVksZMc8EEkQlhQ3FziLxqgGilGoOg5AbKnq
pZH14RwOQUd1CjK3mSoRyQmimNiOIbzHpmiZm+SWwb6Oa+avs2tljdEAOSDyNg+p3hFQaWxjSGaw
dO2fn5xRuMj2wxo2S3AvbwCAyMPpqihdTEU94SCElXCeeljRlWY5MoEIgsr6WxqYSIq0R00cj+I6
Sahrc4zAWm5ZoNZXvhwqwiowGTI9oIEtrhp5ZYzRUWsa2/IunIA7cR/MNjJZV4/XcRQqoSMQd03A
SRzWd17mCwCiRb7lc7gBiihQIvBDFGGZFCz94CPwEv5DtsQX/nK7/Msq/wCvZzRyDBpCLrGA3SgF
mAl8A3JKgUiKEqvlgNhWeCaSFyjTRzKyRzWu69shGjluL2shr8ZNrQjj7K4OFsr60JpIw+fliuL6
cI6dsJToXxWRwCxTdGwncZKiB81xSz1GlbZmw8VLKHnZKudrOWEjuqmjseIXDJG6KV9UvMzxnijC
RuC4s9gHHSuW+Iva2ojryL8yWvfYS4oNkhr0LmEIiqa8CuZLGQ0MTd4kKGcrMXYvRA6f0OzWRqBg
mW7ah19ZMFacZOIkVaWBiRoZxEXJlyPdcuxYZ3pAzH8eM9wuKlgGToEBWZHa2oMcszRbGtFIx4Uo
kiBruFOoIJRpw0b2rOwxixQq1H6bJaMtd3GYMdyqEMac9RqU2ahIpHF25U8MJDGbs5xIMc6ilSQQ
1k8o8L0NRksHDxr9sp8kbjqCzm2tcGrZ8eIvR7NstzjFVbtHRkP13xaNrohd4oOKx7WN8dolJC85
heQDWFNzlsURGmNGThWc1atRj1jIaBHPExjbayhoa+NSRGmSjSudG8qYSgYVSgW1FSGHEXDK8tDb
uelj40AKgFMcAClyPC98xkZk5ruDEHwdSI8gfDjh81dSwZIsZyMuh+cMxuIvmoXkOxsrHwhSi68o
eslivbcp26kZYzCnyQgjEWIwwJMyOfIIMY81ImudI6BEnlEC337iMSZEYunXupr/AIqCkgh57Foe
KJa5KO50u4e58aRlVsESO56nB3ZYzJo96Y/jKVVNlgBgbeQFCzwkikwxkDEjyMmgIgmYkkM8E0au
jlhljc18cjHOY9jkc1VRUXbJ/dAH/wBX2C7YR/lGxz81Zfsu3/ev+rufUh48kcPHm5aHf7XekdG+
RImP7kfawuemujV4eidsrdupNdfufd3W6ovXu69eqdWiK9PunAh2BVfVVps1e3kSXV5hxYToobGe
c1GPKjGGJmVgMQc46kLFJPvajs0ks6uysylgmMGkr7OwMPFsUryyBi2aHOJKDmeosswswpMLeNK2
DcWMhW7Q2lDAIfOcIMZXQWRk1UOSwmCKaJphY1faziK6B/EesdYbu7u5wUT02O7ucsrsZxKjpD7i
qns/RfOazm6S2lqDJy1sMYx0IOvfMO5wpanyvejmNeNEru1qTZMsxqMO+lWGiLfe1bRrqZJEhWKp
ncUkVjKkrmxKwN0zuI5Gabyomz4SHh1lg+/yykr62axgeZaNxK3KrDDAoHtHmmThwRmExQRTIAyd
jJZnppK+3pq2lr5anHrAarvDyb94t5AUXVDWsJIWOpTTjlVTojhY0MKv64iZzLBwoBDRIedsXV1l
TXllT2+P1VvUBXYSm1TrzIK+h4tjDBzc4SiuNfPwiR4lmcO4ffiVyyxy5GzKsbdj0MvAmvm3lYtN
FNxWQcGW0QrkWS8aRkPDdOjuK9kem85E2mvHXNGU+eis7zHQFvABn5RHX1zrFI6WXemU1k8fC0IB
gNRjJ45dyRrmo5xEtlXD8B9cOc2Q8ZOQOtWBvABKc57OCUZz4SCQSpHKVzYvBjdzEW8Xb5FY0+KC
D5RkOMRTXV0EGOURRW9hWNdGSdyMfGNZXyFoG3iPhbvsSSZIllWWkguKqa5HiWeepisBJLOGBGCS
LNKAyVSo4kjPBesj4kYjDBHa6EQ7/wCxyr3G1/8AW5ZtifuaovzWL9WdLHgKFKzlyGFMbINIwpeW
4M8T0cyWKZZUjfG9rmPR2jk21aqrr27Xp1tcj9d3T2F0aiewuv3d5db2SpmFKyGor+knVW8vE5fr
dErtIJOGwnWKN0r0cyLiN3U3la/Yu0fCDVyDmTiqK+fml4XLwlRS8VRR49dZZYN3dVy8vr/CVYiy
HsV6yGpIrWt3eHAWVEmnXG3tI4f+UqoiqrV612EsQaCvbh56NkDtiL+Rl4QDPHrX2sWO9BuDhrLH
egLBUrIIrV1bPHOVTimcSuhuYIMmx0l9EkvTcUF3XyLSIJxWm9KxNl1rIxWjvcbzbkQbcnSeNGxO
4jv8McWajbJKVV6fqUjjttV/apdDEj6ST/hK/faajFY1I990ayRU5GQUkFoTNygtVNbhQ2UpKxwz
IMIFJI0madRJoCUgga6bhFDybiwzjybPOIvqUYFhRgbjyLIKMNpNah0lgE4uSeMfmgWV1ipYqSrO
A0Od5UTWQzbtblyZDTVdPaLDEk1xb1APKHSjoR0UbJz7horaKFzVkr2kkTM1b1JFpIs9NDbVstwP
ChJNOw4Z1oOPww5OYIrkl5yCPSwDc58w0SfXYqrok0Ky9xNfb9n2kXXu6oiqiL3U9jb+X2V9n/bq
9pOpNE/eMj8BL+Q7bE19qwuvzY5n5Kqn/ftLW2Uckwc0g8r2RElBycUQiIseSMkKYcqF8REEUrXR
TMXeYnXpqim1jw3kjWL+KdKaaedYlzokTYiJ7gwqe2kJGbBAgRKm8cFB4EDkg4MW6CNPGaayttI7
oF1ncXNqQPZRRLBGQ0uyPKLVqRLucu+Zwyo2PehXhR7p3MCO4ljYCWxJMBZwhqWQIw4gxwh4hMJl
eSwcWKN0lfOM6XWd03EeUU6YUh3S0ZYgkYLDxciyEKxnDilWaIewsQ7SA61jimc+SNLMgvhvkkVm
iyP3h7CeBJChRzRYHOV/DaPYuFeZGo29y0iTPCGd6bC9WKxeGrOJLvi161kfJBVJlGONxSUiZWHo
OhkLkSb02UjlBt8ybiG6xNchCO1XaOWEcl88Vo26Qoy0tbAx9pHWSU0Zc5h5pJRL4qyV4cTSZZY4
4lTcY1zWuRWTgkbr5LZ8rRrO4FcU28IaVaClckeM80AmdjXNrCXSAD6IwQeBnVsNKPX14QTT8fNs
LFL29UsmPH3DTjrLjIwKUSGTKGPRNuCbSWxir3rDqsCLC6zV0BrYrmI6GyBgursaqJZZRujOVace
xiqo5CN5ZXzRBxzIVoY16FtbMjY2drGzTdYirupoit6k7ncVdfb9n9h3du7t3du7t3du7t3du7tl
H3MgD/6vsF2wP/KTj35my39hW8ENp+7ZLxB5PBKyWtsh2yS69SRwzTRSvXu6M9L9N3NhhpilLfFC
xqzvXVV3nvVI2SKu9JBGjmxicVZJuG1UnlfI/Xa3rzXSxRWZpxo8zHPYhoViYQejhH7zHcyCQaSG
WDvIRo2Agb62ika5RqBpx1wfMr4oJbCzmcQUQUydGwBkToJCnNNjkJPeDHCMOk8aLxp43bVFa6VJ
XV9ZVhSTRq5GyqENBAsrVXVeE/hKqq/tpI9dV3W7X1PUnhwWtjl19eMWGysKdhFPb5iRbkVTrqvD
KsaIommlfWpa1YspYE73zhIyeNk0dIlT0SDcj3WQlF3qZlkR8tdTZDksV0ZVuEvMat0zdSBmbhRV
6TTWPOQtJr7MCYl5EF7avnrLETKLnIjTkmKJ5ykEJvra3p4qVejN2aAplknTVVPKLCPYpJYhnmb7
4JKe0QHG6walOjliy4GzsUy8ml5aVSsZmq0pIROjzTJ1bOs+SmiI2OOyiqWWTR1Fh7HtgHijqypK
xWMGzbZ2BDr+tosnrbM2W7pJscjHrjrGtBe8iGG1u4C7QmZJZ4oHrPtcWIEwWsufVWY19azIMixb
nIB8IFxE8cq/xqBLajPdJzJw5ldHZNmbDAMZGsRZDYLmspqvD4GZRgkuJ2EN1k2S30lCVGbkJ0BY
V1YY/PZ5NAdPfOIKSybTEAmwMKiksURsCXAdb6G31GQX+A5EcedaWcFkDNiT8ZjNAFq4KIkYuMsb
G45BTZbcRzJyXwyhbjEnUA+BwNjKJe9kkiWqZmmY4PHPV5zkDboWVMhxQOWyYYGwUcc6qnry6wxC
Jl5hHhjTS5OVLCAPFdk4/IGMGWXYPEFp8So6HkyDjRBSCuAVXFctPIjnzjyMJmSEmeaCP9jlXuNr
/wCtyzbE/c1RfmsX6qNiHUt3P1UijNSNXTRQWYk86JxvSU3YYpHrxVa1UarOJCrkmYUPKQ+Kaeed
8fLenNqlmjRY4gnFjzrMkHazI81j4pJXKqwQwP5CHJ8bU93MmVZSTkOlFiIgFNirnDMgfGG7RofN
PZA6UaZeDEMsqykKRLJ0RXZJkDHGqkjCiLerUcmd6Kx0KImFNnYusU+icGKHce766SRIWvbXzq2S
RimPekblk0jJLIJZHqvBdI5Wz8PfY2LV+iaaJsBjLo8dMxmmjiArshda2UF/0UPFuAjFUPQigONg
a2KvNPhylkdjHA6zSvr5yejI2Y8SzGhkx/seZHguPWIRZ0ht70yAPXQnXgk1MK2ggVAITD6oSwyN
s5hLnpZK2vjmNy+IKKkgiuexTX9j+tY6OWPljAvRJEx5DogH8KpYy0rWQuiilfEwOV6wPZG1q9kO
qHGx1wsuXYHJd5AZOQl5GzHsawm0ihrwei54LN8srJoBySLqubWFFFEJAQ5WitqIkTHFxyp7IOQZ
q2wWysn3hsOQD5NM8HotKdgUU4Z2SS/XKW5HPDAjyvjFfGkcmCQTx05JWGVFrjkgQmeZrig9rVWE
FP8Atv6IMcphLQCw36eNplETX2lYZGTNK81JxmPdkxEsAY8dyTRTBQDlFHSih1eK0lJyRJhgsM0/
LHV5qjO407XCzRTuYOQQQ1/7yEfgJf6t22DCFx8UeY/JOJHvPZvcOmMezto3Memjo2L1OTXTr1RV
18X/AOmHfOdvF/8Aph3znbxd/ph3znbXo9V7n/yo9UX/AKKNJV3s93rT2dNk/a3ur1qhh66denVo
R1/f0RGp1u28Xf6Wd8528Xf6Wd8528Xex/8APD/nK/6l28X6/wD+4avV7C6cynffxt6va26q3qai
f/Kjl7xqtb1ISuumuvcVd/R/hER23i/X7xhy++9PajFT2u7/AB7eL/8ATDvnO3i7/TDvnO3i/wD0
w75zt4u/0w75zt4u/wBMP+dbeLv9MP8AnW3i7/TD/nW3i7/TD/nW3i7/AEw/51t4u/0w/wCdbeLv
9MP+dbeLv9MP+dbZX7og/wDq9wTbAP8AKRQfmTJPlX+Vfb/Yfxovd07nWn+r5erbuJ95fY+9p7Wi
afdTXZMPfj1ddKo8hknSxTEGjWKCObrHdWWiucrZ4/TXNanbLq7eXt7QwDEMZDlDCmLMWrsOXnfB
BDxtHLFi8Cybyxuiaxz9N6NdO51HWx8vLAVYRVgfLuTzJAGBApRcm5Cx0j44xopN1kQ7nq7tYmbz
kary6yO4aO1URHW+PX+OOlSSOKVkkEGQVlXOXE9HbyEjRSwd1vERy6L9R2RPsIJaRB4y+kw96wFe
JKrUYVE8BpPGG7dr1niR8TItZnubExz0ZXTPKkOePCVyoVbZWUrRpz4a2MiVteIVwIVLnajpJtxk
cERZkitDBMng/wAVlXuNr/63LNsT9zVF+axfqyxslfA+ViwtnjZFI+F03pTZWxzskhfw3PR+7NHJ
GqIu8xydW3WnVppuu7b20X29e65rtdfY+p3E9r+L2vvbez3fac5e77Sda/c/g/a9xE2DEqzjEksh
ZDapLHH7+ijuBGbj5JaWS6qq6K5bBDJE561ryOHCqzu34o5HsGPjaS2EmJk7GFBEhGIyRN50cgBs
UJor03UV0E0fEVquZua7mwNxWT83W2QY5YRKREDrPBMzeZNwiEjmYxzHNdGj2NezVy+ztXwly8OW
4P6LrmtjIck5ygG2EcCSsifHGiiV5cyzybkEfC3HO4j2I6EBzSONMPMQ1zQDXDcIVw7XNkNZDykc
68dqxiSTJPK3irHFJGPOqKunVprq3rVFRFVe5pvJpuo1GtcuquTTd1TZ+iNarlVXK1NOtO1Rz3Ij
014TYut6d79xNG/J1p/E7RN7X737yEfgJf6t22A//wB/k/5jsP2BbayyMpjSLnDgIbMCaWAoNp2X
0gEkkb4XNeqJCTIjo+9ka5zXIqO2xMesOJqrSovsRIzuOuJcyaM30ZV+JOxeZ0fpzhrqzW5Nfq76
5q6JyT74ti1kgj/Q/CzFj8ktMTAukuuLbyWdTMePISZjrq2GMOqJKqLAYQht8XYrqDPPVsaS/g4s
c3CuNbZbXF3ddUhGZPfNhpAIKnjlHzYzgdvYjFEHWjRAY2UpFTLAjDSLsOSSOvkhOJs24s7InVVQ
NYW8zKienlu3tjmIleSkSC2FcCphzIpkH3HgSb0jJUazarEpCgcyvPRKXgwJTbyJKizmqRzbWGzO
yIcW0SOB+NDsPJmDDtiVOnbW8GUp/GZmsF7V07aCk7F8GSzgVOW2cBsZemVOMlr7eLEqqxY8h1Wl
ck3GFkqowx7cZshZZIoJaCY0wrHcfsMdpL2ynv5+l4bC4FpDEWuq+hzIrYStgyCqcaYXeAHTPU5I
hp5gfrgMcrGR4ac7LcowoWzjvY5bMi3xnpz65bj76+BsFZZ9BzRwulvHHjkyMa8SSudFcTTlGiVd
YXBOyOanFtiz7Wq40LSIxsjCsaLHTqO23H6rVzAzaQJESwwiMhFZ/iMRxqkrbDKqTKsQpoT8TDVi
kcwt/lLX3tO4iWEQGwBEh4thKXOLVmVYrmXJQcYYVvUbZb9zIQ/+rzBNux9/lLovzFkn7CrWcgkW
LpN+9KJvKQjkqLV0KQsRkqSzcw2LgDuhnQmfhDtHnlljifC+zjjiM3d2aOLrZvJIqI5qo6RNZIuE
58THSthndLFHMYjWLsURKx8g8VcQTM2NV3nMhqKt71iY8cyLiJFG/hqgz2qqK1Zt3mUgyiSUYaEq
OjjdOwZnMjpC9t7MNvFD1EsTTOI4jpEYhlesT0hZuD7sgsOahhwEEEk4jkYwo4kT5yZZ5qcqCCMe
OJszpJ3SPa2NjWue9epI3dzauyCqM7I2XE48bG20p73FLDGz7OuswErng19azFcVGsW1thyVuw9a
61IGhGLgYfHATJrjwhmT5QJXj0NaXFa1WO9kXMhyctluTS8jYZHheRVjRxmtlrI6wTM6u6xptU1w
gIo7RrGAmusSTM8fJa9kvPaO2Fkusmhrh8GJbmfRT4QISYBqsWKWGonpsjHYPYwOnDgCtkCUIWML
ErEO+H41LNR34WQtyFCYTJQGh2MQSZF6Z0aze+sVqVWi751Yqt312trwsC8AyeXIex7jSMHjMjsp
qPE8kpw7c6JB1Uhaa1JKym1SVdYyKEzmCnKNI5rMwaTkWUV92+fLmVFc3G+yE2imDifKViDxMpZk
RXY0GhQeCqc/kqCsvSHoZU2zySCbLngJ54r+vrMtMgypwxsZsHoYBo22ELMeK10bWSXKR4jMZUv4
bipJ8mXhybpS7WTLC+zt2TGkYlFe1kWM9kiqkBLTOKWO9MqcltL+8xScaOuktGyMwEempiaeRTZA
GACRxCjhwuIfELBEPG4sso8pzIWIxriDjpiTTJ1RNZSSyJyZ36yTSySOc5f2WVe42v8A63LNsT9z
VF+axfqyrLM8eDm6rmJ45XQPhG6VC5mVJmPYsW5BxHb+9omnWj07RSXSRJKTE4hlaprlCkOZGxED
ksmsgmdWuJdurI1g80zIk5mUSEiR1bBZ1kMQIslSSg5EkpBUnE40MZgr43NrF0dICSM98fLSRsJ5
qFpL4xoZzefONC4DVd1P51+/w4JiZG7o9BG5u6PBPKx8ksce/G2N7+3RFisomK1srzoOHo1fTATC
ApPtu46QZXw+mIqtkaqommqdiikipb+vNwrkz78i3o7jH4q8gPG7Cq6MFMuKsB1nIefZMgl6EGsA
21ENgtiYCrwYLPsbOtfRra2M+NUQ1oAWnZBqoKIxo1lJYXd0cPLJh94TPJwIzccyslt6E2OMkU8m
aYSvdVhZUFdh20GN1kNYPwruLHBsdigjSGF0EoAoI+VsLdOlqy6ggv3uc5AF6G9KTHpDBc6ntwOy
TdlW0pkF47DhMbipswHxgyqklauKiwqATXw71M9T3GzTj3svNTMgfhQnSmaiWdjgWSmX1jbWWSTq
BlsfoQdROtIyZ5FHdDIGa2MFWRRWI0dpvQEPPNdMPkLGZNjsN5k1XDdVMFdlNpa45jNVWmiovQ2K
21BksricuSA8ybF7ESzdUkjykqZVA2IcmFJKdmOUb9eME7j1XZWwuuqWwvt5Ol7B1k4mjuJHtWGt
Ip87PJyH0kQ2I84ktoRWvd1RdF7qd3tk3u63R3UrV7umqaaK1v7xkfgJfyHbYF+Mcm/R89f9f7Dk
rMfmBuarzeHxp4PrmrPGswJeIPLFJ6QcIPPu7+5Jw+HK2SJz2OteLUwft5aVV1aujfPA82ypH10t
YRLJBLG/QaSqCfy7HNGmVk3MQy84Zx5L0cCdh8hRdgka2txJVwWVhEsB9qFQyHvowLY2OSdpdqDX
D2JHOWDpSXOsTlIoqtK8oIfGIOVoZqi7vqSzrBVHaJKKNdU9mDccsTBHC00d5z4TnDjSmMnmGgfH
TEywSTkUHG6KmIMNIlHfOG4CYiR8xD3FlyCPkicYapBXp0z+NxJpXPsJDQJePZlVxxJQlna1xjD6
mHlgDwDa40UqqPhF+tVNq5gyphNRSJZYFWPbUoe0Ic7H5cWIfNkuTSPsKOWM6Lk7Z7rhXXD4ksz3
im2imHhzkyEiFQk7sqR3UtdMpjHgzPjba3EdYaVVoxK0+0o4z2UtvZAcIflLO0rzLAdQwFiJaoAS
wDNbXq1A76yyYbdNPa6G7t22rbA1r0KR/p6XlpoMqqJBzSqPBEsUHDJbXNsHvMlbMSTb3d3kJ8qx
xsiij6RyCxsz2jQsZ6QGwhokD3zSRQsknmdJ/iJspSvH9EE9ONQPtXIrykphDS7GKvhc9ytHHcab
MSSg7YlNkYJzjp0ABQfbMV9rJAv+rvBNux5/lLovzHkeyfe+q3iMY/cVXM32o7dcrHxKrde4qxyS
Rqqd1j3t7jlTbe9tdFdr99URdV7mvUidfW7qTRXbR3JMxgRsTJmzTQqJLARFJDDAvNCXFfZVzkjh
HYzRBmaom+96uai7TV4t4jUKZJFIOELgo7pmyMSJ/UHjjCNXtRI1WN8b+23mq2TtttG9enerrpr1
dW45qL3ETr0Y72u9121TudevWirvO0cqO0c7Tu9SL16e0mm9/jsq9xtf/W5ZtifuaovzWL9WRYYY
p52tV48UzuHG4hib8COlRr1i9NRvpiNVW91E2buNRE3dEa1ftE004bO46JN7q7m43RI29vtPLdZf
Z43Z2kAiyQCHAQwGclFwGvihODK0kZE6OKRYtzXtN5N5Ndo2lZBlZo+iEsUxuOkDuZJDJpKxZqVz
euFZY95mj9yR6a9arsHVBLNywbHRxOIk407uJI6Rz5JV757pHudq5PZ0T2tnb3XvNVN3Xe345d/T
Vr9xHtb6aqMc1/ad4vW5ru+3m9bk69U79etF6l0Xuads3dTTXd79VX7XVdXP71F3lcqOkcm6jUVX
dTm6NYiN0RrUTT+CvsdWi9TuvTT+F7SovXqvXptpupp7Xse33Pvpr9/r210610TrXvtPYVfZ0T2/
u/wnbOZ1ap2+idT0SRXbr+p28m9uyM10RXbjuvq21Tu9Wq91V+/7f3110277XRvsdze0arvtE03U
Vqt7ddd96K3tE/eMj8BL+Q7bAvxjk36On/ZGZe6as/nwHAUX+bq+9tgMVSdEW4fskUTpeHvdWtVl
rOve+81P4k9rb+L5Pq1zQViSUmw4CpP1RSMSvPJ4KyIx6wOmkHjihn3XcKd0bnQks3hJ4DYmyRsn
Te4MyN3o3t6pGbzd5kiNei7kkT3xTInFhklhdG7bkJMdYYTYGWDA7EmYMcdxA5crnc2esMhtaNy/
pUZrUc1kw0cSM3iHKtHdzJaRFvODEZFZSCzzoOy+hGkdCSwAKWYYhsUM8M7GsY6IlUci6s0uq1lr
JRy2NYUBDcQvWOesmNidBGXG9pAjt6KR0b2xsKHWVzUjSViu3tsXxqixrFMPyen7JFUtgPURukxG
ea27H2WSC30QgUNSXPIgUbuPUEMqz0eJDWyWa10lbfSKUFBUF5TUTZ466CHpVlqi6vBLeeoMuI57
TOsb6ABmmQHiNUzKbSJxytCqbRgc8u2dWQwlLNX49Y4pQ1AHKyrYS2WWh4lNEfYWJmQVNVydZNfk
ahv6KZYog8Ut3RthmMnpaWzDx/GLwwfJ7YsvIAo+WMp8ffUIyMOoos4vYa0kvplOYLly24StgrZj
n1pCHRih4dByYFlzQfYvi5A+T9rDuNlWMt5QyXlDfrEne4M8nIFekPc7lJvBOxvCcboux52PjbYP
J76dgQpl/jUENLNUQqOEGBD2OpZ7GxW4hLLKe2FoMAUycCw4rZoC8sHGrBrO77HfYsGg5yeaajCK
yLN8nqI7GWZnKkGVI7zkOha14clgOkMDShFI5mLNIAoai+yi97J9HjSE1ocKVjSI+xvUnvljprnM
KKPmpIqtQ0qSc2GdCVM5YzzpYIwSyqyOkoxberwIPISqQsdHH2N8cblFYIEOULls1LVikS04Fhw5
bS2QeOSerktHumS2B455o5tiMaYBYcvjtni3KGCybsgMtPbWt2THMMita4mOzKCORWlgyvEmhe79
jlXuNr/63LNsT9zVF+axfqlXN2UgYArdXydfGertUSESNipNOXKm82CAfeIkd4Fjn6JtkN2VVvqx
6jIDa8cVnGONcDDUVFrFPLHBFxHHyRWrmSCgMnRHNbAM6d/pk9LJj1S6xkEYWLLLKXXU7x5GzBMk
4UFyaFO6Ml6SuZLG7hrFDDPC9w5MJBFRS5EMODwKtBynkZHjUm5uVZbBX8sLclTyPmkc1kLY91zp
HN3tWbzV5sR7ZoJHTthlY5s8UqRSywNmY+FZWSQzLHxY+Gq+lOY5Wp16dhM7Hga6uyG9Ga26bXQj
DyZFQuxmwmtTMigDfH0rGOfHVFMsjWEKFZOGhSRkpnBnwGeQajx3GL7G8fkiQTHLAwQq5OBImfSC
GA3zIMRhDghFQAi2qbCvOg3RxzWEcARDp7pcbkFzHsSZzejjU4loCdTSVNQJEkpRFicVEZEbNaMb
M3l61acyUUCEi7ajrCalo6NlbPSETsxWU4ynjZFVZG/EScggG6R9G0R9u6BsdXOTWgYlEHKITIPH
lHSsHAdrHEDALW0wMd/HHxCZxcxJe9p1NHNFK6NsFK0d3NtdC+WdxosjCYYxZ2EZGqgD2OMg47nF
1SFdHQ085ZOFEiCFjcy3Lrw6wBQyUkQmyIxXGI0WBpley0BWRyZafY2mPWF4uFdj8Krkx+oImAJs
L7J8lGqAW0RuVQTvLsTC4xIS5ckCBJG5W3IkqwWE8PGKqP0LUdtar2RIbQu2ryi4xJsHva6ug4VR
V5PMO2cyMiVh9czLT2A78Zg9wXy7gyr/ADcmcGenD7DdJmC4tELYpxp9cqm+srMi3ZHHzJYbp1t3
4wjSKWWvBaPGTXkFk4/CfVUlUbkuUg1Nba2NUK4CSrMxm9uZSIajHOyVlTiJAyKmBYiZsjAZZDl8
FoITo+cW9qMlUIAoZZyqylgoDxpUpW2RAgVt6JlvrWnvYzoGQSSDCBVFhVTS8GyBi34Fk/eAj8BL
+Q7bAvxjk36On/ZGWssjGDPnyQCWJrtV4nB7HuC6p9zVXN/kRdsb932LL/GtXl+v8vs+3t/F8n1Y
Yy2ufHDPx9xHPa2TWCcZ8UqNVOLBLCRLFNC/eimje6ORjmOVNmo1qJp1RxtRreprdN1repvUxuie
0xNE6tprR8lMxZpy4ITypLCROhjyZip64yjcOwUnVZ1Ys7bESRurXpNHLEO6IMeHJqRA4ThbFocV
XyzEHDmGdGOGq5BIrY/rWVrpyXGvbLI//g2tjbKKXFCaEYO6GeCaNk4xY0rVZLHMxUdDNARFI6OW
B6Oinhe9jmujc9qih1OO0VYIEY6yCFr6kAIYSxfDKM+wFgGgjiHOeNPMO8uJrJ3QSyQrIsb3NWFl
li2O2DBizDx2m0laU2A6xkWawNhbOM9Iiz5nOlMJZpMVIqvne9y67WI0lTWPHuG7lsO8AV0NozlI
wNyxiWLcNbyMMIW6S2ROUijH8CxrEGq2YZijKwI/pUOubjtQ0ASz3dzpEYRA+XgP3E3ecijaRu9X
E02gqkq65KsXlOVrUCG5AbkJoiAeAHw+Xh5IiCGcThxt5eaGKWHcfG1UjDyKjp78SKZCYhbqsCtB
oiGsfG2eOA6GeJkzWSSMSVrUejHvai6OXUthlPVlsPr2VJzSa8SdptVEs7oqwtssTkIr43EkqwOb
fHYpE6tjTiv3iKNMUxpKQtw7i6dKKrSrKcI2FgriK/leUmcMwYZg6yROWFo8LY91ImbstbBjWPw1
09clRPXxU1dGFNUpKTOlXKKwdIJK5JjTJkCexRklLJk4e9PKroaylrK+nrR+Jy9fVhj14MHFkfNL
wRBI4oIuJNJJLJuRpvyPe92rnKv7LKvcbX/1uWbYn7mqL81i/VlhvKwS3ro/rmUMysbcRuWFrnNd
HXrAS8khO5BHAPMTI9yRwM4j2qiBUlVW0wGqzMBqghQA2yyO1lk5cKGIdJZH98/V6vVu+i99twUn
IHRzu3cO5m8rVa9qtVJoSI1b2+9puJ1sZ2263dU0miyKOtGZLUMRpIdtFPCXUjb0LxZwTAQTB3uJ
HfMWOO9rZeaAmekwpUW1TQklxkNpwmV6lO9KjnYOqtile2RXaSSM0fMu+/WV7062tZukvx+mxeie
Zw+ddThVtcpPCVz4nEyCQDune1XOcizbz9VV29tX2tfjuNsPpxEraqxGqK9C6kBIJVjCriooGziB
NiNla0ISSGFrCpkaxqSvRYKRtNQlTyUotLeWTaAASfJIBxVDk6XbwnvPilhkfG+MqSeJzJ5Y1Tde
5u0l6LRY9Fk6w8ETISKEMw+CVkHAEdKS3lT5Rx2tiZwGWIqugjaNHPD2itngnJiMsLA461tjRx+Q
iMs7CXiFzDDNJKkFEiTgiBQSllFQCDDtKNLmak6mWgWOUQdnY8XpCxFqQRzj+Pos/OlxQNIKSbRO
Ik8j0eiIjtU2KrQ8PxYauNhQYyvgx+qiCLHZJJPGOSMwRIJYYyZHEMZLHJGyVz3tZvPVdqB81Lj7
6GirbwaLG5MerpamSa7MpS+cbA+LkI5RXUy7iRh8ZXFum4zFT0wOzkpqt9nXCSAV9g8AV5wIMrdy
UQQt0SzjDSscrZYIXsjkau69qpsnQuJ41UbpbD06LoqsDQ6KAgWM1OVFi0LjFMLGYT4ZsBRELXpH
NI11gXS0NLUF20vMWpNXVggEWc6PmkSawmEgikNlSQieTiEukfvzzO13pHqv7wEfgJfyHbYF+Mcm
/R0/7IuPxzH+gfY92xr3f4n+bMu/YCucPOQhBKwK0du/KxrRSi5Jki76ZI4hXqsUesz08EySTdjf
GQPKyeCZrZIpYn70cjHdbXNc1dFav8m1vVxEpVEgRVL6uXmja8ycqwMhhiNrihpYO0Fl9JfEjpEm
WIgd8b0k0aHhl6kBNwDNW18NzzUjumZCSGxwkM3p1dITDxOERv8AGV6rxnPc+eXa3uq6bl7GtwM6
yBJVkcywmC0EhQ83DIZLDLuTRserJo5I36aSMe3VNqOeYGxubO8mEr6ypqWA9IWdhKDNYTMhdYm1
dWMyAIM06ec6wCGZCO9jZFnfBBLXpX0GSWV5YTW8HoUGhph7wF+PkRiXjj5rO7r8fhhrSpxR1IZe
ywHPMFdVSHxSpJtVYQaMULb3cKSAudY4vN27gTD+HNUjZFPk0UbWgFQLYuoOhlKjSFtk7iRufiOU
Kf8At7Zr2PeeO5UL0/pzJaGvtPrbl+Tj5oQ0mL0kePg8TfH4UjI3tv47FSCqUHF8MIDrBUqoJpLr
IsnyGk1adaE1gkPMqPXQq6ztha+BIt9HxSSP4tRUXw5lZa2QQdgXXmWeIClUohxbwoHlsIyiJLeX
jQE8QTD3ZMaxg6uUf64CQp7R8Zyct78pPw6sa12KhJd3dXNbxWENZLb5RWwcMboeaRrj5QXGcwPD
XxlltNGDdkFkJK4aJ4zJ4VtMYqXDqU5I28Y7JcgoqNu5K5sKt6WV8srmtFaRrtDYB0eU24K4hV52
YXWh1aw1eNWbrBvOm87chOkmB6NncUDXNPOljVJa0ewjiKcOQFjoN054WRYTVH5NCHWTUQc17fY/
zFTJzhS2Es5NFaN3jBKcmvDU6CN1mLYpw4qbFaqzIoVsKy7v7G6BEBsLaCuoZaodQqcKxDsxHnHF
W42/ORVWbIw4CYIROdLFJFxuqhKyjNTLojJmMtiaIDHTRIcbuBQbZ2RgWMeJoBLS9IxQEcvTQSl8
iQo4DjJRxSSbaeiycGq9DlvldLYFi1XAyilpYGllkU7BrkgkWWQSUcoQTJIKAsiAhj2Q+lF8ua0s
O5nUGsxW1laCHEXJIPl99Nj1bEPAwrmCCojYHSFwRxK7l1ZynOEO5fZkM2M5PDfSX8WNsxed2LC2
zz56p92M6M0rKIcYmgJrmLKOsGQyTTSo4NkCmxTDx5O5zHROdhda5YpNxXxqsmVqrHrE+SNXM713
DkezVO1e5uirifuaovzWL9W2iWLjJJWns4XB5ji74srOHwOj7fj76LucHoqz4mu50ebry0nc9v8A
n01/l0TX2/qXTuFucazikV3C4fHVKapg4qv6PC5lUbGkHGUm30SJB+kI+XSpq8ikaRKIsIBErSop
XxyjcAWeXjskRyOa+Lc397Xr0VHdqrtb0DJzuk14ocwpNnYkES7qceCeNhExHE3FRWSab/V7HVpp
xoHM4ZckRIse/qqiuqKaVHMRXK98caEwtc/r0WRm8ur01AFxlzUKCEsctuouXYSpeP0KwcxURNkR
3AKu5zEhGnj3Z0QUjhPRW6pgxuP59f1dVl18LVuGqwsJLBbXy4zfXLDq+e4xK3N5gmSuFVZJjSRe
BLKkQ0e+xzOyIBY3h9uNSXdSBVRmi0g/JjzYtT28yI6oqKx07pCrOVu8Us+7DCOyPcVJXTAGFZBe
ZNB6CumspCvKKlxx9TdEyDupG4zIlFinSVTbxQZBFz881tT71bA5t6O7itIcfT1lxaGrftxkejqy
sVtTTbN1W26XlbaqyczEVGiquMYQVLk0MQ3LTiTrGfwhJWn5YpMljZ5VnodaBPPiuPmD1GOZEUE2
EibIrrG6fi1w614ajssSLQ+VeMPDYJEWTF9Z1d9Y00M1ILY5SEPXrR1RWRDgF1Y5kZFoPezcQa1q
ZiSKyksAgWWEKnEj8EzlR6lKPJBRy8hvcUFvixqxlKRkGPraKZXxrHby2vp0FQYQGa6rbXTI1BXG
R2LZgorGlsunialMPx+zDFo8QyHJnQ2BVzkoppBEmM0dqWMkw4QMcbDpIx3cB6is4nMqtACPll9j
wdlYdl6V0wVFQBWrw8XyuqrMfDKByvFrCUHkwDZIp4Zq4SzfIic+9Z2O2MhsTYoL6vs7/HCLkEFk
cM89PZlVsdyHXlPKhjlIgiiKUeZSBIT1lj4U4saRvix+rtskyUc+8ySapymjrMKXK7PG8WDoorOI
OO2FqMHWZmS2hYMdtNWtHKp6yaIIUm2KALmkymoyM0nG6C57HdB0WUBSRvySDLIcfWztbpW1MNiB
bwNykVwotXLSgDnVc8JIE8UskEeKEW1s+yB7IWKXWUjVzxaqGHGZK46meIBWzABDFkCy1mQRwmrb
l2hfPAMlhmGjmmg2vasTNVfZ1+ZYfUU/Y2SHGZOl6C1p8eJvj+ElT6LUSvisLi4W2ZbNrg0reGTE
4ZkkSyipkl3ZcDLeyAPcY5ZY/V1tCHh+P2FtXhWGO3bcdqi7exBPTHgC4x7/ACDc6Rn6SGEdukj0
XZHJyWYoW8Mx0qfDUrqXoIOhyexBBHHAMFrHZHJdVotiMU80i9LrzzoS421oohIzAfsgj8BL+Q7b
Avxjk36On/ZFx+OY/wBA+x7tjP8AlBxb83Zb+wB5UlBJBjFndNw0ke2N4Job+C13pfH0L3onSo6N
jk33xyonCewUVm5DHvr1uc975JHukmmlkeqvlnmle+WaaRzpJZXue9VcqrtZmDy0x0M0iziOIcRB
cQNaXEa2EOXgPhiJjjjfWjTvLYzl3sXeDRjeEGMDUZQ4U06JbNp7LkINrZIomGS8wsYkcbA9JHh7
s/EmZFFC9SXPRjrLGZuMNW2dOXRyKI5jJ4AjA3gu5Z80c8bZYoJPSXSxTMRyNV8ciatUMQ3NMtNO
qbEezob2WPD4LWiIgCJrXNCYBiIdOXAUAYWITFdVNqj4yHOZw5mQyRVbq6/yOpu6yW2mXKA5KSe7
sXX8zSrxtnHa0dlRTw2ZsIpjoI6WCIGUIOOpZXiwNH2TIFvMhd+3MORSVHFp21U97FQJja2U3Dpm
Wj3y1jWtcJ0olbFM1swoQ6ppsNgvGsVqg6wStGMQpsNvD0esTwT4jBoYGR2AhEEBcMzB2xIRE1XQ
Oj3o1utctyYi6v2ADH5OVDiJFt0dW8blamEF+KeheOvRCj+IxcddPM6wLllndM6OSKpfjmR5Ljc1
ZSh4+RLV+huRl1W15JBgcdkDa45Z1kDxiDbB0D6MGm5eI+cSBIgoxBxrLGoru6r624t762tUhHxe
wcf6IjjbE+tmiyDG7kNK9CTXqPwhIzomxQIpz1SR0lAPBZ29JNjJLCaewq5AJTB1bWF0z439OV1y
HO2auNIgfLMI8pqv40BEM3pm1hUtMuXD2WDC9j+eSQoV5DaYTpjhlMlcD40d02VxCJWyjvVkC8oi
tl4s03T2ThgFn49bnUYZdW2qNt8ZlrH19jNx6gixjkkip68Y0UWxHrSo4EncCh313tXmMsbSjual
SOjLylkCbYCRGtjYeKsNoDaVJoZ0cMKTiWdYbAksAxkDITxBCoKo5hdoaZWR5UjyDZAVW0JzKyCt
bw6wiEAEGQiUwFj4I66GvBgZLNGwPc4SRSVxVnfXNQyjscZqKi1Ir1Cx6htY2QGV9Y8CsAOI3hIR
gojb0y5shxR0igNjSc1SrBQL7J8kvLF/Y/rHFWpeOiziUuL5mLc8ULo2nogYiAhSLEhZHxSzlLFE
m6QSqJLb1BGU5JNJkZak5JbECYWYffRchFWR15op2Hk0MAA4Y47IIqulr5Wvh46zuImKknyEOBHJ
ALg1SNCjnvkckUC5VFGjpJFc97kY1NXvc57l63KqrrtifuaovzWL9W1j4fF4laczhcLmOJvCypw+
B0fb8bf13eF0VZ8TXc6PN15aT6lpMQCNJI2yhfDNMFFv9qBQTpJHM+sEdJul1wUiStKtd0ivFTpC
OQGKsqWsbVhQpG3cjUaBgr42cEQbhskGSKRkfL14A6sa5GrACHEqcMaFrOax6Ah8qWdWsoNLYkSk
OCSWZhfamkVb5WbsrOJGyzhVU9MRR+Hx4rQjNRLQcPotIatbGRr3PJU/jlvextgesUzgn1Qzn/Ws
RXIrwh0lHL0Mvsjx+pyY0oQACFuRVVXcD1YgClPZBVRmBSOEaROYQQYvEe+eZzNXJHFFGzEKyIix
UXCbFLClR8oyu0jr7WqFBJVBGpICGBbSDjMibBOjRg+IRKrJuPk9qy0tDpcqsB7Isc7ovlgZhgIK
yKOu5GsBIbCgIgkCocQfIvLMk4vGkIkmq8f5y6jCrMXsMPdJEUIwizo7ESMZ8FovIrDO8eWGA8SS
KAfgFxuTRwZRwhUz1yvLVu5LwTIY8n4uPNtxbESnTH0QcWPHGY7yc1PvhEAz0Mwr0lknSNhfDIjr
3VWS5XVW1adkpsWQDE0hVrOzLbDpS8BNjt6GypywiD2DERcapUoZ4Y6jlR+ncaU6S+yJRTyqiyvq
VJaZlTkdxSwBQB2tojKVtjBO9tZWKYHSWFRTncjEwmskglLiJrdwixXovMbnNx96Ubt7W86c5seb
QRN6vj9EBnLxM4ZLeGNxC5dyXjG5K2QjnjqetpJYldHyjRas20OHkjYkSTIQ+W2IbM50743RshRk
UbmvdIGdU5PlFAeEdmBzC6z0MkSSeja2HubgWWO8xq5F5aMsWFAVjgjKhhbuSkzucr9isPrjLWkB
LGJHfYVhbHXSOOmeRYGdIWcFks1hYzTESGnFREETykzzq/juSRtcz0a5cywpUIHproaDCAT6urLE
gDLpBha/DBaJ9WQwUSXhl0xJIxAgswRQzoI92tUUq4Hqq9KF8mPIUPNUWh2MNYlDaWbywyLiWwAW
ER7pB7YWGweCE60gO4DdlsYDrU7gCl11KJYyhSCY3VHmx2BlXT8qAISokxMAnXak2hUEAQggxMIk
XBXILMeQh8+SWAtkc2Z0boopw6ivpo2iNZFG9kSi1sD3pNJO9Z3Sua9sasiYJy5dpBMDldvlsBcc
wqEc3emnmW1bIqhrFLTGNsiRJBHxLMkCQStKQ8Yc2MRq3OQEY9XWTbirw6cit9DtdYxEqaLLC6Gq
hyAkYE5zzK+qs746nBm5fla+KKuq4wvsgj8BL+Q7bAvxjk36On/ZFx+Oxv58FwHXbGvd/if5ty79
hFzEzIePJwYVeqNSSfhyTcNHr2rO0hk7/u6d3Xu6a9emvc0X+faebiHR1IdjNXyQVE6wWZCBQcW5
tSCBIjDoKmi13TI6wWYrT66V7mog2zN446KececyvAsL9cjq8jCF1mJbVnnthLisUCHks2RDzEIL
Wy80ZG5JGjDWuVjxc7FW4+XkEQqysHUuAYCU9IuM5sjI+JExNHaLovd6trgLKgKjGp6epq8imMGy
B1tSrQWnSTGmyWR9Pjbwphpqg6MuIwKMeKHly4iyWPfCwO3nzLF4ak9Z1Bspr+njANaPKyAnkzVK
5UtBiZIhZnDSyJHNK0eT64VNg8vubjFsbqbMyWGscXldY9HR+EGFtJ5owxQL/l3cQ6lDIs0Fc1qN
Oejl2aJYZJQglPF6RjHLtq4aeSu5UsznmRykpIoPArrOdTOHw0Frj5vBBzkMV3ozxRGNseiHPXIK
fcbaexWOVDe1sndWgnWR/wD06bNxx97TtyB8XMMonWQDLngcHjcXoxSeclj3WvfxYoeDuNeu/oxV
2nEpciorYoWIckkOrtq6xIHGKa10BE8QZMs0QxDHxyQSyxxo9j2ytc9q8PY62jy7F5KmsnYNY2Tb
+ocACRJI2No5ZrDXjikb0sTOGU6FVlc1qdrKjohzgioCgjIISAyxZYSRiRio+IMRBPA+aGaKRNOE
RFLIKQiosMj95P2eWe40H+0ZWm2J+5qj/Ngv1bOLd4nErzmcJYUnSXUaZOFwXA2STcTveCtbZLK3
ea0A3Xhu+pcP3N3iWEUmvA4fFRKesTiLLyITZndqkCTqXaMRsLR+fY+B9bX3NrTythshBZZhFl1S
JZmQTPaydzO9ZvNRVXX2NF1RV2uI763mEOryYEhbXDv4SjkNni9OgkMnIfPGWxEVsTmpuJqvUq7E
PInmncwrRrp2vSVIuTFkRVif6dFvPe5yQyKsiby+xomy4zT1NafKABXW95IddyVRDKyzLNEgfQhd
DHttTI+j5nkxGm1AcM04AaHzKSTOAfcMyqgEr6u1IqDiT7ukhghngLLDHmdNHYzQwjXHIyl0zyJo
3lhOQlGaaxND6QynHAEPjDmCQy6rB1MisuP0Y8Xikx8y2y5UrkHQb7DeXn5aSTl5N+IZ5dZPdTk0
EcVDJaiC2zwbq9ApZbRgTlkJnCr+ccQ+QaGSMh0EgvGGVFIZahMyegUyjhILuw23Fa8ulEF3UmJt
hUn44AsOvEJlL5dB95Elc32DbuK+x+xe2tvD6YKK+rI1yKagHmlOAqpI5ClInimi5KZsLZpYSt5j
4maJriUMgqLDlRcwDSuM7dDLSmNuRY9OV0mQmKvIgYqrCvG4aIjnLuKwWjph7GysbW/Eo4Cbbo8G
epxcuCuu8htbCOtsZawCCymQEeIeutCCHyATo3gGTrXx2lljcUmRzm9HC41V3XPRHEqRPucnbzVg
L3wurBprZXT1Q08cMb4ZR2SNVdnZVKUjKNlR068xUVUbW8pz3H3Wbzl+t+23G7zlXtWoq7SWGSY5
U4xjnRpNo2ymypCrCvhh4MrI8jrpaSvr6qTknzEFSA312GFILNDIU5nDIfWisy7GHk3MksNQO2+q
nT2ssBMgU8VbEhXEOkhMilElYM2V0ZMckD0SVjmp0KNkVETdbhb+iILcCWzVoE8whruQjIcVuiFD
kDFLwtByIJoZd2SN7U6YDPxyC6ixsfIrHHzMmFj6DiKCQ2Lp0yIWcurr9xzXSWc9RutgXmGjPTRi
11Obe0Yl1bQpNXVEtsEywsGaOVZK4SWWIs6FOHLpLAOqKkbl0TdciEy0F5T3kYc6ilyU9mFZsFKR
N5RiXhTTNgnRqoqwyK2REXXd2u8eQGQeOtSTo6zdOx8V06vlhEv0ghRjXQdC2JIoMqukl40sjlRI
+Ho4XHQLKmsW8hkxd0cJdhTJj0+MyUzJwrSCHi8tM9trI+bm5xHiIG/fik31WFLqDLcZmp1nnFS2
ivqqSsUkUWU4kdD2FKKs44UExk8XF4kQsMpEjWxRucmN0EeQ1BJeWV5djSTjW1TMIZAMQMLC2GRD
uIRLZzzysqkEhIaa6usmtejxHNW14eV43J0ERCJd7l7Vu6HKIJcGONa6FL0eROYxwsMJfCklJa6B
jVlRW7DnAkjmhGQREiGCTRkilDTsSSEgciFz4p4Jo3NfFLG5zJGKjmuVF1+xCPwEv5DtsC/GOTfo
6f8AZFx+Oxv0FwLbF/8AKBi/5uy39hXJEClgsdivEgk3eW0dV2MaSEcTeTgpLNH2yJv726mvsbQC
zkSFyRs65XLvJq7TSGCR+szoI+42Ql8s7k76Re41YLudwQinZCUG6ZHJVWomSvQssQhW6DIQNY+E
aU13MovFk310dtXA1mU9LD19vk1lQ4zynMGsdktdY1qAE2STTltCrSbexIUg2KWaRJt2eZ7YoEZa
YiHPEhZOHFY6JLLvpA2d9G+qhllRvbcDiKkjvZ02s6Wkkljtz56CwnsbfIMosiT5sdPAsBq6W+Kt
p8iBq5nBSDwOrzxm1zipzQB4yppJJKG4IAArkrQ8tjNhTM8pzk6YnIvQtCCZDf5TVAmSekUJURcM
mjBI+UaEkyFEJt2PJa6PG7i0w7F7DFzq6zsT62nnW06GWW0Csoqe1mjKFIo+VSB9PxDR7GVJZq7d
3XX1UOTUSqd2JR8DrpFQgRkNg1cjcQ9QoRzlBpHuuRGpEPPYEMjGbC1vCY1Fy1oMNLA2/wCxSFgN
Y1zFjaMcL6ItWyowFEjrP2zru0j9MXlJdQPS2bVN0caIVWU9vDYiSuyfImKMEmKl1E1TFiMIDMeI
MfeGlWiZSWXLb7siDcs2BkI7MUonl19c6t7G+V4TcGVizvlQ/I4cf+vK57xK/nYebrCyCHErXSES
zQOl4j3v2oYTK7G6qzxe9BsRa2jzfKa+vshoaezpiYmXtRQUN5jBDYbOaauUCGzbw4Whn8cWWeJQ
a94EIEsDZHTDQXtpkjUlnmeRK/py5HFuLV0sq70k9jDBJJvbju1amv7LLPcYD/aMq2xP3NUf5sF+
rZxbu/xADm8PhcXiq4abtOCoVikvE18CtbZOkTVGAGd4v1CCITCYOanaTNDEys3JZWQ1o6RySPr3
EPXgVqxcR875EYcW3f8ASKtQZ6azszjQTh5BCoSGCRsKY8QaDe41XFXExOVwxRirCRH6YeYxEZEy
rhCzKHsd4sS+0tavhxLzltX2y7wBYZBtHLYT3Ex9jWvkGK6LHKAJJ1lihm6T5UYzHx74bo22jxVj
LMV1k48wjknVQAFvfNcKMlfc2CNNd0e+QswdixNLIUlpIwYMIddjUcYc4JQOXE2dgNlWLkxnxT2E
1OAPRFwE8QeJkSQeiOrhPiV4h7SRFc2QuoGkrOSkzi+yHcFy/JMdLuaW8sLy1YGTaU1GtpQT1NhY
1kkgtUUTFdsCfDPaVoxBMEtpVzLQyFHdh2t7HQpC81IyC2FTI0kn3yhnl9D62wCpq9bD6yk+ttYx
9rQcWPFSK64yjAspLtzyLCG+GKxWbF4zK+CFlVYQHJOPRSzVdmTZAOGfZT18tUsK9JuygmzOqyH2
WMdkSgCNIyXJi45WZWo7KL/BkivWhxIStCEirrTodLAs1sfNlylFOkkdkAlENic8GSYBFhhLrog8
aWllr+m1BlCYJUHRnV8q3SqoyrVyVzxYbAZbJ2grX19YQHBfBJW2FMYY2Va+O9pJ4jwFL3U4zwZy
w1EsWRq+fo2eVEbq7tsTIoVqrGwxyjOx06rviiQAcgBtlqFspp7QYG3eDYdIU4Zr5W1FpETC8+ok
jRDh7IGgFbeQ4dX0xmX30AOFRU5LQbjKLYiUauDTJMSLrXVFJSmG1w5MdRXEkSFvVoYUMaMfc4Db
W0pgZMd/U1lu10XSbKS147gXFRwA1wMJ9bzbxo4AR2AIOILwWxMco8NqdbA4RX3D+x5lmEx3dSXY
TE5LPfDAjgmXMU+PCkUYADgpSI65lplai9JEQQEScFSDKWEUoD0P1kWHugFdkmRUsFWXj15FZWj/
AEPU4K1WUpZiigwALflRw0kwjZQwt6aeR80yB48HRVPZc7IeSPtISCFyI6xjt8lpWBSV61CCQxq0
mPjXCXkpEteMyq6MYx3Msx+iEkoBi6zsWZxhB0kTiYR57jKR6XgFMdHWpJKBz4BhZ80sTCuLM2do
hE0ku5dPHDx+2pMn6NJsyjbiwrrmtnBoBaN9cKJFj9kNbVbuj4ShnTWdRII+wsU5ebRjprMI9a6K
OFI4cTomXx2Rh0wQwDIoQ5ckNxuiuShXlp1MPCtDAR27sdkXE6EQPEDkzi2tTqYox9uDYRY6JUTx
ZHEQuUur5qjFArySWSyIba18VpZExPIEHQtySI0mGmaPNh1KTimBZPhlFcVc1hOYWTYdCdD3BYpN
HDBWtR1VJOZXMnuWiFzvnhKskldEzGpJgaUyzuey5WXVfWWeXZRlAyS13Y5ug2NscsyOqJu3z8xV
8yIa2pIbXfWqDhOQVGuxu5/aF07Sc+kyIIewNEGrY86t6y1c7H5m0b1tJKro7gq04Wk6VImlsHzA
Oeo2zcfJGqZng+hgMa9IzzN7yOyq6HLqO7IjXD7yvJpsWU8Cp4jhKU8wVp+4GxYwHcWH7EI/AS/k
O2wL8Y5N+jp/2Rb/AI6G/QXAtsX/AMoGMfm7Lf2Hc9jT76e0vtp9/aaRU1SNkz91VVdepV7i+x9z
ue1so5rkIjV28sM0AkkT3bu7rFDMMQq9X8LXrVXd1ddl6MhEr1kBUl3J42KKI+fkUs+jHlQywIpq
iytJ31i5bWNerusU62sbAgeuqgyDrCfhMekIgUcks8qxtr+JLpHFJvNj9jVUTXTUkOvsrSI8YeKw
fW3FIfj1i6vnc1sFkPW39RXGE1vGjcKtrFE8FpSStWZmkbXa8zNq1EdqqCtVrH6K1U3gWdc26qzN
7jd2T2Ws0lE4thxhhxyXTOAkQJ45MksDGw2a1/JFP4kCqSG0hXxRcM0hg0M8C7eqp+91d2gitTvO
rwCvYnfemPZw0Ri6p3Natbi3eEl3aDUFassKOaTZlxzyQBLu1rkhbNGPJK4mfSCNI39bdXb1JTWF
04ayySckSmBWDfebKIJx52RcOuckKQjs5giYjSBivaxPDwMampcrepVTeQRqdr2z27ij7zkiYm+2
SJUic7RHatTTbqNmT/hdEaIi7uu8rtxIddxXKu87g8R2q6uVF029WTLp6W7qG0113V1VoL96Vkna
6elM3F31Tq129VkfxMF1av8AB9ScNkvXH1SSKnW7q7XXZjuPJI3fYitmjjaqpI9IW7jWQxP1135N
NVXRE9hyfscs9xgP9oyrbE/c1R/mwX6pQTlRjSx5xnqscEzUaRFJEsnAIjlHIRVkTWEiOWF/ckjc
mu91fUtTQholhq5GsSKaKZ6lLK7hCcQqGZsVfxn99xB59ztf4KaDWcDVbETGrkY/RdzhvfE9ujer
VHxuTX7mnsaIyKOUmWMwGW0Dbd4tkVbDdABxtmllpYsgqAG5By8M7CJIaZLCZkE6TNajiYnvDtUk
EArSas23CnDrpN2SoBqork0yGAMRz2CLVwRSyP3E3noEF1nyCC7TiV5BsZ448Jzq24o7rH7N9fPM
6GGxGrr8CtPJreJviLZwQyANJYrVma5r2vmKJOcscNrNS8EUGxsSz7hrUdNXVQAQpdhekjxukUke
mEskEcIZFK9nRR/BrJJen3TXDbFwYMGGZgfd8KqlHYe4yjBo5rmtjG5wLrsq8fXnB3dfEVXCW9Ud
DY1x0aTDFCv4o8jXOka9EmdonayMWB8CsSeCdvLktRusTeggzLDnnn2dZBIRj2RCVZllSumbbCV9
6XUjUdlMK4QtZYgrCaWbgEvh1bCqolRFYSSEvPkrISnVF0ygJthuM51WJlMlf6GirOCYaRnJBWRJ
kBgpgyRSFClIyz6FMYUtJbHUtnvRFQKHaV8jojo90qGDf4MvFiUiDeGn7dIS13HNRLnH7COyrnkG
jMMijmYySUEiQOdG8Xd4sbJ4pNZo/SZl9Mh77XYiiYRraCV4dqQLwpk4YB5Bogk/GWPl3cUiuMj4
TJXTM4O9JGxkkTnlwxtKa8KZsEyzgmixPe+CIhFEnJgigsIdyZrXEgSEjsnSUV8rSYJ4o/s8j8BL
+Q7bAvxjk36On/ZFx+Oxv0FwLbF/8oGMfm7Lf2Jf3B5/6lV/17E1rS8gr4mW6hyE0lUbrPIwewkY
CllAcOQxhMVfOS+YBIZY3NZG2RrXbqq4AnKyBCn8mwe7FvDoOc6EKg47Sra2sbRJuQFLk5dCkG9L
mZwtI4t3I5gxpyCbjCLaUcQNsxE0j7OjnnjgGXlo1cruaSFqe2qbvbabR2+IV1uDY43gmS1lcXcV
h9CQTk1uHVvrK0SnyKvBOOQd1ah7CnwR0XNrW8Gc14dhyXoiGscyyV9XYgqZjB2O9kWkPnjsx31x
w47M8yHKCbkmOz5CxK6ILkDAbUlRBsghuCmFXQ0ZeRn8HEsQnszB5bAl7piMoyOTsgvxpZ2ycO7i
x6eSOlEH3LEYdtKOECPFDWsIxaDGbHPa7E9b3pQsyq7Lt/kLLb606MfZACZFQ9ktlUiJe8B8xRVK
xV0NrZta1Yex5Wl8/YRS3Tel7CEEqvmYNPg+WhraTjrC59E9508XLtsUgYFYSRwypwkazbDsnvKU
ltvUZWlBwoYmqyKto8Wy2E+8jejkUUTKb1zUi53k2zV8WOqqdTdskdE/OAm2k3Y+miFYPn45VGe7
OETIq+vPy4+8sLSWuqpkZcG1IVZis8MTuUqWbztckx2D0YyU/o1D6MupjOyNkdnVVK4kGeUTA7Hr
6pzG/rX38JNVozIUCqrI7Us0qvhihYhWRF9kIexF7Esc9MVSdOBwR5SMBZsvyMr6Je+Fpj4EqC2T
ZQ/o14iv6DJltFlIVpNhcZCEFCRjzqMUfGM6vaQ+nkrUjshzLKgvWYcE99v02OdPlmNTXAq7pApU
IKVjB8f6Ynu57k2CmOuVv7A4+ybaPdXwyRvQ2edBWMjgjTgipBDvb7+Hvyyuf+wyz3GA/wBoyrbE
/c1R/mwX6q8WR0EXOVKTSRufGrYOlA1nRskatkZvQordWK1U7qaLtPJLGyQhssnR/N6AzGDqqcm+
zibG9K2SVHJxGsifO1mhCgRTOWrbYVxhVNUPALQdZDrJU5prxh7CPlGtBlIZM0M0PnGzhuYwiTlI
l1cKWXeTiXNEWHPM2RJ4jbiWWudHDPZR86GBRos6tYGUY3jPFaisSLqjc1iguHR7WtcfA7fbE10h
EFiWMURuQNZGxJyoyCWxxtbExJt2NjWNa1vYnpGUmRAk4dytjkhd5jt5jnIOhx6xqXVocl7VgrdF
WpVm4cp9XzIMdbGfLZmDTT1iGdkeqWps0jxPBcnwnDUaPPJNdC2rTrdr6Xdi3ymurosWpUQfjqlh
WEQt0dGqLV5XX0l1CLiuLWVRG66qLTG5bjI8hJx8Wox4QG7BBtCYlLBHetigQ9TGUYByhhhXSEFb
hd3OJZZADTU13SX5VXXlWtpFbZEbQkyZMlVXwzGHoadWmwW/RYJViP0kNMwSOpjs5R8Fyl1PljqZ
tJnNe6aHCssMPiJLKxFwqz0QVKZfVrZujjd3pKuDR/BavbaMXYOWCasoILDJckvLOlt6aa4NhBub
0i2grgDKvJQAaQ2IOafnnuGvIEs5nIxNwdEJGtbOO8samXsk568ekfWMcuMWlzd3bKLMBWgVolpL
XE15ZgRr7k60BFjvQ7wYkauFkmbjXY4bj97BkFPYYsJakS0liPQCi43fVlgXkY2STjTUZ8ZsVfEd
WiAWJ1wws4bpIQeUW0cFa9F1pwqZxleZ0dyVwVEkpAn5jfXdbmMSTSCaftBYXUcVizt3ny43FwXp
FIi5kBj4ZFfaD23ZI9DQnKRxPj3sgvZaRtdAakIXBdvjzVu/Gte+J0aOifGrtsjJxWHsqDiG03Yo
r4bK+jzKDIN5nZBOfk0IhuQM6fbGLWFzTWTHuUIcaeeUVraeSNVyS4Agy+5rsayaoGrqF5l7avvc
bNwegrCWgKfOW+xkByBzbWeyfzk6EiXXGm5gw+VceEMyfKBK8ehrS4rWqx3si5kOTlstyaXkbDI8
LyKsaOM1stZHWCZnV3WNNqmuEBFHaNYwE5cOQmTWUXHnJ9EN16PaoBXkWp6w0dfjmVsbj7W1gyNj
jvMKe6usxWQyFCgOeNzn2aR+Al/IdtgX4xyb9HT/ALIuPx0N+guBbYv/AJQMX/N+WfVknme2OKFj
pJZHLo1jGJvOc5faRE12ZPJxhQ5ZUhjOKUWMdznLpGrkQp5MLZOrtpx4uGnXPwkRdHCDWdeVJKx6
LCMaPNKrN3R6oyORzupvdXTq7uzrOa7t2T8yQVE2PleGPKTxUkdEj4XKi7s0rWOcrnRtkc2NWtXT
aGX0R37Xjv4kSscC1Gybjo+Ju8puOk3HyM33NV27LM3XSaTeBroSGyQ14o4cMk0DnTLGPDHA1ZHM
IjbvPZG3iIxkcarruxtau7sqLNEqOTR2o8q7yK5HqjtTOtFVqbyL1Oam4urO126p4va8BLppoiKm
nOaLvbrd/wDhqxjn6uY1UbpLA3c03N0Z7dxU7j26F9q9O5xE0form72jnIvhofZ0+t5ere3N/T68
6uJw2cXTwu6nE3ttUmhRddd5BpEd3NF7ZC97R/fSt13ZX6ySI56q5eqWHuaep5e4mmieq+43dajE
7jGtY1mjWtRF1lgVV6nOUaRXPTRybsj1L3pGdsvaPVzd7R2m8iKiJzDNGuRzU4U+61yK5UVqc7o3
v17nsaN71rUSKW5cWYyLc3gelcjHqDEjJ5xrbSkEvoKe3Zx+tY7QExj2aQvasKJHt4WHutd1jyL2
zdE3k1L6nuaiNkenbSsa1kiuaiJs18kyP3Xb3VG9HOXVru3kknmVU3mNX2000aqIq6/sMq9xoH9d
li7Yn7mqL81i/VmbHBCRJw3LDATIsQ8szE3oWTSpCSsUayNZvStGndGmr2wyKm47udzufcT2v+in
sN7iL1omxVn0ndATHcHmoQpwlElfCMgbZeXOrzWslcIiDTPi3ONB6TLvx9rtY1cheaW8dSVCKS17
sOkDaRNVCktSKI8GLVEAsY43O4DW6vlYmvWqiwVEZkQIhNtXoywfG8xCa+4PBPWaSCSWJ6uPHJcx
7JFR0atdo3XdTueyq/xr3V27mn3upV0XXrX2evXu+2vtrt3P519tF/j7nV7X8a7a6deipr166O3d
evu9e43+RNv+9fb1/wBfd9vrRepdkfu9siK1HeyiKqOciL7COVrVeid/ut3td1Nu5/Ov+33fv9fd
27mmiaJp1aJ3OrTufxbf96/7fKuq+yu3UmnsaaroiaNTRqa6NTRqaI1EROte6q6/vCR+Al/IdtgX
4xyb9HT/ALIuPx0N+guBbYv/AJQMX/N+WfUx7D6qCK2tLHIKKqun8VWjUo1vYiA7rnRovGtVYW0i
MPqbBAiTFuZxhYiLVOZYI5YY2wyyO3WOJUiJBB3ORkqohhPCE6opF9O6mPXtVqiIALoazrDYDIgi
qvKYAJN2QRybx4sb6ncH4csivjAt+bdO+SKJ0sAJAVQXfWo0EEEp8jK9ZrVXHySU9jC2ISA2lrWN
dE2Zxbnuk30hFlRInI/faFfmVWP5dV41VXJVrhmSOGaMQJKgs7sgq3GwlgQ31VEASKA6wGhGnhsS
xumqRr5p5uyHdQWtfYVUmR4NU4uFaV1xC2jbl1VhUFaWfNPkZa8hWjXbCbeugHAmtbVhhiWFZz/B
FHxts+JT3i52Jic97HT2yUyiHYbYZUk3QKZFIWNaALAPBOC/IyYyYHxz8YLnmIHkTlBDtMYDx3Ob
elM5CKieUZg5AQZ4qFLluQWBobDZSwzLErEsaiicOwqvS1Fla5ckDP8AQnkJ9ZRYMdXkUIhFcPz2
bZIbQx88NbZRIPyoLIxSoGzX1VHZs7eayp4TEkB4uX1XRNuwsiLhpDXiIUI1WvGM5GtyfMhwd5r1
gcP6I7B7njuJVYGkMGh/xmVe42v/AK3LNsT9zVF+axfq74j44yHmVg8b5Y+LG3m7IQVyvjRzFc3c
mdqiPY7+C5rtFQsmSGWN9fISObGPHKcizBprPyCixyPsWr3I2DROJ4uokg8ZscozDgQhpJJKyflj
pi+FXRjzbsb0RrLKavUlkjJonwzRyNgIjkbMPJNCrXPtzai85ESyLENIFAyHBhFRjMdGrmuUa0ns
TENUoQKdFZNIJJXd61J5XcOqbaE85YTz5AeUTvwyLNLZZDbWKve8aOIZ0qoUnGUVjRVl3+W9J3F2
orL0GYZROsZ+xS5L6hI41/fo7OcakdLkEfoVplglcu7O5vTN3rO9/pvapNIEZIuO+h+0zfIsIHo4
xD2ZKHJQvux1tZrZbWUI1ZH0MxpFQzHwXBVpjJelZ1CcpguS2DcQJW67GuVZnWgVYlu11UdjAQc2
lmTNbTtsa06ctsZEcMVQRUkqytaXau1P2J6WXFjxA6zE8rsJqUS0jbWYzf2BwFlDLMTaEMLIqYRl
uRrljBWWteDYRJjwcywP2ybNnjhlBAw39pQDwrMLzlLUxTIFOaVIpOnSjhJbBpUIzGQVpYycrJLD
JJNlNlKbiNxkHoV7EwME9eDZC0yQ5Hnt1XfXNe66sDWPhHtJZYJ2WqtLYgxfLQse4XbIH3MGND1F
dk9ZT5Xe1tORVzTlHYHR2QV6WjrWwduOtntomQzOPIiCLqIebVoE85NVR1eLClnJj9VlV2JGNXpI
gF5b2I41Xv3WeY1PVT1gFfwLC4Fr8tZJZzOd0IDFGOMdQYvj81RXH3Yd1Zrb3teXbAxQUi1rJK8a
rCtqGYyxLW0ZO1eloGChhFzLCV1NZfyDvxrofE8ixbGLCqJBsenL0nIB6GZ51ZYMuUFqU3shhjq6
yemupLCUCaJbGBS2uEFcr8VgqrfOs0wGvibUW89iGRRsyl9TelkeiAcYuFX0DILGlhGDfM1zjBro
ZZkBF7E9YTa01nJkWK2mQWtmbU3E9k6vpfQxwwmOkyaRSrguO2LiItyJeCszhy0q9BpQzbSe2fjk
9bnPYozfJK0KnFPHs8diEpopGiWZZNrYQXrOHaxBlWMAGPNHsoUjQKRDGtGyiLHa5lhcZHnuJUIf
FiCJjHc7sVUVm6Tk7DI8QENmljrHCjiy5LUb0k/FjlJlhZXmFVkdJRi29XgQeQlUhY6OPsb443KK
wQIcoXLZqWrFIlpwLDhy2lsg8ck9XJaPdMlsDxzzRzbEY0wCw5fHbPFuUMFk3ZAZae2tbsmOYZFa
1xMdmUEcitLBleJNC932WR+Al/IdtgX4xyb9HT/si4/HQ36C4Hti/u/xj83Zb9Tp30L4703x+a6Y
6EreleZ/+cdIctzfH/8AXcXif8rYytDligLmcJKNKRxOA2cI0c+PjLE170ZvDJ1ond0Tr10VU5fE
uprtHdJ3e52yIjF3OhU7zrd2pC+xvIrdo8jOmrY4eMWTMOKYQdI8omK0ZGjHOq62KCFvThCq2RJy
HqkXpzo2JsFNlNNjlstfI51fLf1tYfyc0m46RwTrCKTlpJlHY5ywKxzuAxV14bd2xJdXY0efbV3R
ttO4OqKMsqjqYoFhLuSTm12qtaopLpButG7nc2ABraGmrwaomQ2sDCqgRBa42Vs8chYA48EcQhUk
ZZbHzjsjlewohrnKk0m9Z2dTQ45X31nGVzFwlCEpBRBTe3ls3jckZYxySIxxUTzonlNbuLPGukjc
gdZQYsY3IQw6menx/DxcYxSGmD56Tk24++xvePKcVaWM9oQSfKwxJYIeViYP6b0fj9NVUQHFfPyV
PXiVgnHkRqSTcsFDDDxZEYxHybm+5Gt1VdE/xuVe42v/AK3LNsT9zVF+axfqzsKQlYG8Kd6BpO4l
VFmjJj4KCteSr+LEzwDVl/gaL1pDAPE2GFkSNjhYzhxxMYjdxrW8NnD6ndbXaPbu9rEvbKhRc+RY
+HJaIG/o+9qQbF7SGBxjMnDWezryoHTjhxceFqKj0HRURESVXcWpyOtrokjp1RIK6zCcOZUtIbBI
PGBcrHGxyywyK5+9JG107GOSKWZslNjshLS+hw2gJO2PhpMyFVbHIrF3la58e6+RN9zUlfI1vao1
Egqkq65KsXleVreSG5AbkJYyAeAHwuXh5IiCGcThxt5eaGKSHcfG1UJyIehpYchMgUcy+iqwY7gi
Dhxt4RFkyBpxEWg47OC+dW7sUSdyJmlligI9SLa2+Iuxa0ygWjGEsrPerJK2M2w4CIUfwOM2RrJi
3NbqqNcxOrYugxWGhxdtw7hZAUDjYrZLSCcZBrOdkYhdbFFdFwucg9hYJapE/rmEIb1shrYoI4wR
hIgoRUYnBhHgiaO0dGv63QcJEjia5ju0jVXyO327PFrMTxquGeoqvHBoqsSB6gmrYhK6KAWONyh2
DnHi6t+tzFUqLcnXf2PiKqKsmK1lgItIyABJo7KcZg8Y0x7JInNMlHjEFjgkISR8TBh2xq1IY0aH
LkGO0V7LXue8CS5qK+zkBdIsbnuEeaPO4Zz3RRK9YVYrlijVe8bo0HIqSovgY5mksDuq0O0FYSxr
42ENHOhnibMyOWVjZUbvtZI9qLo92oV5Jj1HJdVsDRa64fUgOtABWNlY0YKwcOpYsDWTzMbDBKyN
GzStRukjtYdyrrm8vYEW4+6EMnAtTOZ5uzh0j9LsCudM5g1mhM3Nk8SR3Hl3mSVVBS1kkbzpY319
UCE9klm4d9lIxw0EatfYPEEec9O2LcKO6dZFhj3bh4mM48K/IklbkDh6Wthdetn43GbcLGM1bNJu
YI4qG8ZJOPNva8V+pwJ9BSHBWkg8tmGZVAki2MocY8Ikpw80D4i5BYRBYh3kNkdDGMOyNWthjRst
bBjWPw109clRPXxU1dGFNUpKTOlXKKwdIJK5JjTJkCexRklLJk4e9PKroaylrK+nrR+Jy9fVhj14
MHFkfNLwRBI4oIuJNJJLJuRpvyPe92rnKv2YR+Al/IdtgX4xyb9HT/si4/HQ36C4HtjPu/xj83Zb
sv1e5smvt69f3O2069erte51dz29rKaYG2tjFsrcAaERkoTIRArWWKDeOnt8eqNzhFiK9SDWzPiG
e5nEl11E4IctPILKktlDZF8Y4eBVmZCoL25KVVWsk/KkEOFAkPNGRwrCIY0k7e3vEneNfh4IdaNm
UeHiwXA1BKYsyCEwPHc6ItvE4Ew7h+03ZmpFvbPbd5Td31NYYNk+QuskqsUjyWkscbGriyXVSg1g
GOlBECHScjBa1p6ssh4+PYlAkoyPsgxY+FbNNxHFbMyTI5VxpwIVw3G23VfDLWyWz7hxDoyIJmPk
xtaYh0czGEyxsVFkLEHMcHC2GKC6laI2uu5kh+vJ6jhEvJlFFKbIM8ogIMUmVqvrHmiaEbcSzIhL
zwiCogpyJBR4o7KfMB2TY9aPBEjHiUICSY2Gz4A8ScPHLWVGuSNZHdjB2XvnMts0qaNH2sZWJhJN
Z2MoYL5OgpLqtuym82bBIT6HMeshwoJeJNwY2P3R6lKPJBRy8hvcUFvixqxlKRkGPraKZXxrHby2
vp0FQYQGa6rbXTI1BXGR2LZgosngYHZdIYvPXCkVgpWMXZh5lvZkUtaCE7HMjuQhzybQflHA3ZdO
UDxYiLKIMPfIZZGXVbc0pVZfhYzNU3E2M1hMlubTQXzYY7M3JIcYZBFWTOlecXfjAzPhdAEQVNMG
wppwdPklqHHjQ2XWRdUPTmiVFFIbbV5pRRcd3ypb6ommM5kekmtpzoU5mhjuR4yZYMgNu627x9KA
OmseDcNph32lfkRhFdRm188V1OAPDYHDSDO6cMp5Kt3pt3HWDo+ZlW+joshyA22TIODWUU+JWkkL
safVdIsnthcqfjK/W9wGWPILfEwTNVwfFZbLFXSpV19Ee7GC8LxzKq+9elXEqdOPtnamQuvVsGQP
QOKvhHjpucgtBrFxm7XPBLl+rlXuNr/63LNsT9zVF+axfqqQkMhDuOJCyGJUbJI8kuEZjWK5Ws13
pUX0xzYur01zYt9ycwO9Jo1c9qNRksb2uhWRro5YpWpJHI1zeG9s7GPR6Kq7rlZEzsmnMe5JKLog
rGH8WZrBprPGgq21LlEGdumyDROfwHbk88DppGAwxyEq9/Cnu6oKVXS6xFW1I6aFZkThJPGlHEhH
LsKGkXl3LzEFcby6q02vdsFNZOYp6xPZPJHuvhdIyeRnEjkY2KCeJ0aRvinhRIputze6ibYmW2XJ
fRPYzYPCfbFYBkQlPO6xv6US3etoRjo2NwwnhklQRkizuHikmZyi8fgIoCJCenSWXXOFQOfGHutt
KPp5pk07kM3EBdLjpkUEkSuKWeYKOQKLjLu1bq7DM4JdfVklxj8KBUA63YAnLJbSiuLyWEeJ1U42
HipYyV3SjZopaFLUeQchcOnkiJUHOYKuelMebi4r0S7nEHGGlqj8jDyE2SCaxEQ51LR3A9ek2pb/
AK2IeyOpZSZIOOTkN5io16WLXspiL3HnWzjK+HctXWTkmgqDngHNqujZmwcrIf0jAQAPkc1nY3J2
OA47hs49EFX0xCx2mUZPYY42YVWCC2xDd8UV/DmtJmq6cuIaCchBBVogAMSvGmk5muK39Wf6F47O
t/wVIyKJo8jcySrmILHcFZiljmWAPRrDRZmttlDHmyOqR8xE2MhZEYVIIZjsry5MVHmJtwRahL1+
RwSNQQyOIy2payqIdCnK2UzCApyZg3U2U02P1GHwZByczMIY24mtCLiIeayIfcWBgor4qxnQgwxN
IfAXzTsqhgCURz5LCqCszzOnm40JRV5eL2x9lbvrWXKQgWdPklhiksTKtZjCCZMkhHCYIVEbIOTG
kLqiovhzKy1sgg7AuvMs8QFKpRDi3hQPLYRlESW8vGgJ4gmHuyY1jB1co/1wEhWI47V5PbYyHZUu
XWR01MJjZJRM9RPjEQLHOyOhv4Y4WJaFq9B4IZJFczek0YibAszWSIvIOl8ppHKCRj+PD2jMTsng
E3MLssyKlq4OPE8B8lbFazGvNJnjrRCRRZpIIpgYbKZxV8Ljw8EcInNPlOrYbseyY2QrhJWrj5DL
/iyPQhK9HI4PnU5LbGh6ityrKy7OiqbsuXhYuIdWVVo98AVpkbpLKgp45i5BzHclQMLIXkinj1yQ
tj38gqeNM9+OwX0hM8R2NyuImxqOSS2EhqGX65KK6DgFJGdcUdXTT8q+WG0ePMJMSPYy1R1PzKK+
MOxIpSiFhXrhISfH7e8q5ISY1bNA6CxlVY3NV7WO7X7LI/AS/kO2wL8Y5N+jp/2Rc/jof9BcD2xj
3f4x+bct2X6ntf7feXbq/l9r+bTb2Pfez7GvU1dHL7Wvtaaa7XA7KrNCQ+nbhzXBrYclKMh8Dq1w
kTaskWNkccUus8Gk00UzopZpYXva7HePRZmyAe7riHvsOkJAh0hsRXvle11MxsLVHbKyR7XRJI1d
JHKnct6Et00Ql3WH1Rko72NnjGsBZAyHwPmimZxWRSuWN00D2I7RdOpE2uA7m7v8gKtcdsMUbcWa
0kVhV0NnEkZYNVFT0lXTCvlekZMxa1chhroQI7GYwasAgGNKtbq8LjIxq2xUMThY1AynrbsGECw6
POGx2G5mkkjiWZsNxaWtc0qRSOR34heXKEqyTWVU7mSC00iidHVD1R3NrVNiDiJHjPnepRAshU4U
RCudXjBMkljfihEHPTEYfRyUFXMQS3WYV0SQREWEcEMA5RwkDzogp+DG0VlraJFEnNu3auAW9ycU
SurMWqiA4iKbh3A+HWUtrROsppaOQ1j4C5pVnZVFVYpbJHNJHk7uwMXMWTmV+XXmZxazwIr7O/S9
aaPK5grHcgxMhN5ZkSxFR8MZXmSqyTjWEI52b5FNHUY9U1A4huKCW9ULi1k6xx5tA+cLHaRpNUXL
zHHvJieejgSGydYIqwzXNlkZuUUd6dmkWUUljLYY0TllU6vx8PGIyLHowGywxZ7QKGwQiqECPpYa
2wigZDGXDrBestLq9tCsjxBuGWliStLAXLWtlu5WlRx1tKBXw2KdPFR8RgKCbkAuoXEbPIQfMSTa
wzm02PU7JxCYYJq92LWpl3SWoD+VcsdoJZl8zvT8wDLy8EUoLoeYjnqreyyK+yCzpxLwEYu1Zj47
ni3z6iQmOeGhoKUV3Luph+UeyCOROMTzDidYeBTl1drdMbU4yBijxJn1Uw1tW1TzZa2SyV1TzbDA
5rAuVslUVWRTLIjSoJ42MY36uVe42v8A63LNsT9zVF+axfqrCNJHDO0qvJikljfNGx4VgMYiuhjm
HfKnpHXE2aLi+D4jN7eQkSRnNsOWV5ymK0rn3kMSOdSdY2wyRzQo2B0fCZE6Jqw8LhMRu0WQMI5R
OM0gytaFFOKXMiuVz3Rq+NsSv4k75XsT015BbnskmMme82zbWyrDj81HCPz9KLIcZFCep910POwi
d1vwJnvkhO4b4ZYuDGJ0nZrO4WuitoJhSEfZPaMZ2s41bPanTUo0sb99w/BqJAUaLLwZxU9KJFhl
RWbVOGcyf0bTehvlZ3PG5yR2NWVdaCNn+tFH3JZ66Bk6LF6bHNNFut9LXYe2ZeZFygGRHZUFjnGq
UpB721CsBLCVdKTp10cy2xh3BJt5YhiSuIHGPBGyFMT5ac+dcOx83G6tSJB1UgI/ofmZDuCBEryk
ZSBsZJBwIlV5DJ4ZXrErK0Ya9yUcauq8XqJhRyKZzLYXEDyDcfWwlnpJjhkGKIJ3x6gkAIofitOg
J312r92exclXmdzm4+8+JUW1t+m2Fiv3g+utgTIC+Vij4ZKvjhchDmRvSU67Kt7pHHiYuKtdEtTE
DBHiWRJktU6BOiOkWufYPLiIWewljkGNngdGrUG5cmzhtLmrsiMmrcpjNCfVrKMfXY63GFGgiPrL
AeQOen5iAqEqCdWyFzvHkgcvVkVfFkmTD0GTpfIbjrH0U1WPNlMZDLMoIkuhmyIaSQgucyKBLlQR
yplawRA9+Da9QqSw4d/iIuGGMZLDG2KrEmtyI5RU5RHRnPW8nQh8nFHlbAIx4zuHPxCHSZLlE13L
dh5DBlD5KBtzX2gVVHRskBghx+LH2Dy07JK4kKeiIDngJJc6DjvbMwS5GzHK666jqxKe1sw24o6T
IwgSZyw+mATcWMqI5xpizuGTS11PMjDSIlesfBbDT3I2R3+N2dKLahDlUbMelWYW5dWvMhJiyKgv
x17eqFWJ8EUErPTPTFR+iUfQdre4sdj7LSEO3pyK8uwIgvJYyrqK09EtZkAVo60sIB7Mss4OY9bC
FCYy43ST8WLKpSrAu1ZSRUz1IcGgs741VFuZBRgh42XUsLpBJCRuAOgcjxohIo10ShWhyDI6SSlp
q7Hp5Q3UJDsgqKmZ04Al5Ha0FiOrhnzG8MuphqTWssC2ISjVhSG0fTZflVRX2hNqf0IM3FS62vs7
l8hBthXPt8XsrSKRbGaa0jDnsiKphk0idHqG7lNnVYRBJaTHn2ZRZcVYPMSbYkOJJmcLS11RUj7z
3d4BWCRvVFnlZIVKQRN9lEfgJfyHbYF+Mcm/R0/7Iufx0P8AoLge2Me7/Gfzdlu38e0w0czHTjqj
SIU7+FXRxTN1Z3yo6OaNeImrOtE6nLpt2q932fY09n2Uci6aomi932u7tJYCm506FBJZOWQ/GG0X
HQV7WydUXTbYmF7s+jyNO03ZPSN6N3dc7RPZ69VYqqnc4jk10060fIvV3ZEftTY/RVNdZ21sFa2U
TLy7noAOTpnAxEMjMgpL8t9irrCCaER9XCNKNAbO+xicO2EoSjKuKcPIDR3GDUBlpXw3M8PCknkl
jr+YQieEdkBCzywRSs4Y00yP0i7YqOlyGht1BibOUyttq8/lYJ4mkQykcnO9g0T4n6xPmVkU8b2K
0jv0S1tLC5xoakrlDk6XZkIsosYZwIJo5FoRNEGLXc0h8LgE45MZQMghfMIpbIW0rpMpxyNuSK1M
dV95WNS+V74o2JSq4lOlFfJPAxqA8fefNE1OuRuthVVl5T2NnUO3LWuBswiz6x6uczcsA4JpCAnb
7HM3SY413mub3UXa2BZk2PuNoYJir0NtzXOKpRR+ucm2HQni10ECKizTGMhjj+3cm1oaFkuPmB0b
pW3ZYtzXEDU7oGufO20niJdFXuhYx7pULdEsbWOc/RGrtkbKt4ZVfR2IIItsBYw2IdvEbRVd1zY8
o7OC2Ni2SiaRzlNeo6y8Vu/wo7vHkBkHirUk6Os3TsfDdLXywiX6QQoxroOhbAkUGZXSS8aWRyok
XD0cdyWVY2X0YAy1suVvKyfo+skhQmOxO4RTuUAeOqTsMn4Y7oVSVJFYuuxllSn1OSurr6goLEar
uQ5nAF3d9XUisNeLzqikCc8pKiTxskm4Cw6w7/FZNa5FeYvShRWp1Vzr8jEWsScUwkaMWawOiq4o
bXQd6HVe694JkZIaTlcus75K4nKccgsYq99tJXzXlZEayriGcbJZPFeU2doDA2OKeY5iDtGa6dZE
iRXbUdpQnU89Zc1xxqsmuhOnBJwuj3TBuqQ2nDyOCYezpp3SsT6mWQGN0JCHI+Ei0rsrxo+tDJhD
LsQr2rKBFMJkiiHFILgKfBASRLPBHDBJI2WWSaJjGudIxFbkK5jiyUDyeSZeLkFSlO4zr+tG2fN8
kpPau9ISbi9qva9S7Mlie2SORrXxyMcj2PY9N5r2Obq1zXNVFa5FVFRdU2yr3G1/9blm2J+5qi/N
Yv1Z0seAoUrOXIYUxsg0jCl5bgzxPRzJYpllSN8b2uY9HaOTbVF3kXRyOTra5r17XRfZ0aia/wAu
vWuqQmFQpKj2LwXSRN0du78eqyyRMR6drKzfdqmrXonU1zdFJii9niSFgkNYiN033pAdJLu6d1W9
tqu87q3l2eRXcE2SSKZwjHlbgxE2km7DIZEwtkUXEXdkcwcp8MTHK0ad0TY9gJafCqcxxGG1GYlj
pms8ZKQ3B12IPXUquxRQrOycNSKu6ZYUY8Zs8gjzox2MtJ60PGaOsPrS8XxvKSbC4vi6owYTITLI
TlI6wTHLrmihOi1dOpRVUM6Z6jsmdKGS6PnRK2S6sZyh6+tp4SGjEWRT3PdJGwmRsu40UOIo+Zdy
VeAJN2uq67VeR47T0d/SWPQG4QdlJlERv5LYAVlU8cYbFL2GQOSSxGkmnkMDkT0xjBZNdH0s1xUD
PsDZZH3AtTYvMHpakJiSXN82wMrKqYsOognFnIjkqRZZOaVkXtOpg4YGlk29hyzY1l4MQ4UI8xtl
YzP1kRYBxodIk3F+uCQ4HK1SGrtfUENe5rq1hCVBxBf1vfy1j4wrtjWwDEEBMqLYkauKWSIx8jZe
ajjXccjr+rtsZx6pHxsqMKwNAyw65e8wunr7cZogxOH0EM0DRbCNhc05g80Du0ZDMjnSNze+SmkY
uJ1dhdhCTGNRb+ihgsSKe1iKaK7lBrp1XYRw6RHpC2Hi70mu442I/EaZl4I/CyGBD5eYRVk02bXL
sfBOjtnYdAUw0K1jkYbWzUrGcs3mRj51ckOyWGQ3NTRArKyDnbixErA+PIjlZChJssEKyvRj1ZHv
b7ka5Ub1LsDSTZHQw3VnCwitqJbevjtLAeVJFjnBAcQhRcMiQyqyWCKRjkikVqruO0KAdlmNIeEM
eYYCt7VoYKJVvnisySBlK40A9fKKTGdNKxsYkg87CHRuikRtHdB5FTjw5BuR1wptvUxHONc8OJ9W
6CI6dq2kE9iAMQFBLNLEQYLCvbkQo/Lzqi3pMhscMqbWytKWtuwZTR5KwYqZQ7BozjJ6x8swsgyu
IFV0UiP9Ke6NWbZTNdzV+OVuLn1AM9paWwwwMnS9DS3MUkpBbBIA9JbhgDGPmk48kbZGua6dIGCN
flGOsceA21BR13WtU2rcMUY2yERSfrgBwgJpTTId8dRgyp0k4Q8rmMsqK2rbqukdIyM+pOFsQpHx
O3JWMKDlmgc6N6KyRqPVWOTddov2UR+Al/IdtgX4xyb9HT/si5/HQ/6C4HtjHu/xn83Zbsq+11r/
ACex/HsVJHG4GOOygK6URzebIhbUAwqGInbJLA+WN/GQxJoUcxXJGsrIlZ2yKmvtb3a69xF3Ud1/
wnd6i/xbGOjFGQgh0kM07YGNke2UcpGRkFsFmdEIQW+GEhycBY2ScRJt6NsUnDFPKNHnr1nsldDE
xqTv48zIHpA0wdBoiZiXjq2WvnIc2VsxxzoWRWiVVfR4ldQzRTvbNkVlY1ZGPnqxsdZdU0lfS2kz
zx5HzzDyDF48bARHGodqx+/LBLay8LJBSTcdspbIzOMyx0uK0pKGrqJjZsTq687FsjLc6qjtYzLB
6TyzzygyMQcCBW4TRBm1gR9LTLiWSkQKUkNhi9nGL6IY65XDI/pBxII5QEs0MTB98lInRcy7esLu
p6ElmHzanyqlpTyDAqwkcDCw8TnrrEoasPdXPEe4uypSBq09o8sAacro98sI+Sk11Wb0hjlXS3dD
H2Sc6xcMCarsrA5JBTsdpmR5WCQ20mY8K+o65IpBY5IXI00qJt6pPI12LkSzz1NGJfGZF+2BtmYc
fbcWyx2nMpOd47Xy0UNleVUM8snRygMifz2UF2J9YRJZYz2RcerziMnyYxkseWOGbRN9DU1c2gxQ
apDEHBsUo2nk2iwssCpySlkR9gTVdARt9DnY6BAryuYjAJssDyWwvmiWLBwnpDUkwTDADFQxlzh+
mSpWyMHjgIzq1sR8dHs8puIbkICqMOIrxpocbqapIjjp6mvnnfIbXvkINirmumik4/KxyuUduH2S
ZtaW51GUXNb11lDjotMTFkMRDsp5GWoxQK8kfLZTttQIrSzJiknEHQtySI0mGG5MDx6tqKPsLZkP
VLVTkT2VvJklLCUTPajS1AMFU2FwT5Z4BbG36VPnQ+WUN0HBkcUSPi1LKoXY3rKsGnLMnCfUYdlI
+STFmTPoq6QUmcXfFrKWEcwStcxWdLTsMfKODfVTMdt7IK+7I5CVVraWNXXrWZxkHTQ5sFoPQ3M4
l0BGMMHNF0ROPPAZYQsOY1rJJ6zIjygZamrvILYJPRRkn1iD6GCqianHxGOvHxmYplqcYc3KC55b
ckQhwXDDgZDDHRY7Zl0oDafsf5tgTja4w+ydOy/Gx4WstkGIqqpGLu1ZUljWqQ5IN6CEewNSWSWA
+a8DxGsNJhwOqbW1Zx9pWE1WKZYPkR0xxheP1UrpCYOZDrahKyUYPRyS2c7D38llFnQR1PSlnlQ2
Q48cuSWOPTUEzcLrsaJsZGwYrkgFoVLOKQ2Wosq8uqOCmZKVJzEbIYx4ypmklMghYSQ2NIWzztja
k0zYUVyRNlk3npGiqjEXd1XTbKvcbX/1uWbYn7mqL81i/VRsQ6lu5+qkUZqRq6aKCzEnnRON6Sm7
DFI9eKrWqjVZxIVckzCx5CnwzTykuj5VzJEq1IjThxAOPhnSdYNWzNcdHLC+ZyuUaKBeQgvTgqwy
6FtJhjIix7SoCIFVQoB5at8JE1WiwjtDH4UiTayRrA+bjkoVO6eismzAcBad0g8NssVukNmFMhb2
yxX4kBnLtfI/SCFa9Ho1sxjZOC19RYDiitKsaqawgCkJkiGeSapRjRpCYxzCGR78zI5iI4jJWxrx
WxzStWJ1S4YbDZi2YDQYcaWXfXUvRxlBYXs7bEQCDFopchF4NmMTPUuuKDiERT1kRkESJZTUJweN
4Zl9fSYrjOOin5YdyV3VmUlncGF3VdFFiF6PxzIbEaZ7xj6viTwbvCiijjdJRGQ5GZjtZQjWBLZK
dKMqynvT0jGhfJHkWPXlawUerkOY10cMBSvsur0tibJiHSsNk6syioOq7OwnRs0lDU5hX5DFGfyl
aMNEaGLCTWsGAggChYICjGMbJKjj7EjKbKkrPQ8mOAA0cGPEuIFOdITfutPRFit2yNTZ4QYYuj+B
G6EKLiIrvSnMnuFFPtcfxgbGKEp8yyRWUjIIZyrqeVkLSY33Kx0Qdkit9KJqTZB9BpBpCMRsPRpb
W5tOYTLcVljDjcFMXDkEcy5VyclVi9fcTq6xIZZhx2lgQyacGJxLHvZBJH2S56swEU7LyRZaEt8j
9K7h4rS0HMEbwJEPHHIDInDjWCeAhEHYUyRjpUU4Gny8+3FsOx7fYEouUdCCQhizV6x49MM/FsVr
HzpXmb0MqnoRPCEcbLA+Sb0iZavEhhp7ky4w+wtT8oyjJDZiIMYtq61SBLmygyi1dA3o9w1dW6Q1
4anElRMhe6aMnHcox6CmsjqUS6rJKi+sjKgJ4930dI+wEswqa/mGshJKuIZrVqpGFAnGxqQMqN4t
/C2PHHUeW5DjGTWdkQaet7SkUA1FC+urK9KZwlq1zsehfW2pFvUPrX2E8y1ZShtiMpZUdUMmA7Km
XZyZNEsySzVmQw5WNBEx/JNdJZIPc1sBccqsg4IskTC5mQwJLgHTHQjW4RjOTYzxq4802YttkmOR
V1oOhVNX8nPJBVHc8LxJuT4sMcBtgyWZ0TcbM9Cwrcf7HuT4NjtkCZYykXj72vGr4bC7hlpRvQ+O
jQYCzq4EjJFIOIWZpjUBa0440ckKSduZUGTggsyLJMZ50avwMTDjRCMix2BtxRlJLzZwRVfFYskj
ihGLh4RhLILp5FLSugs8AExZtE/MMlsN4xl3k9qfERmRlMmQoGf0yJIts0SSyiKbMrRPrUaWVsGU
mxGWXNmPj4JnSaB17pl5AB1stNj0ts8YdGo48mnELl13SnGzxyWBX2SR+Al/IdtgX4xyb9HT/si5
/HQ/6C4FtjH+UDF/zflm3+3tJt8mqKncXRFTrROpNUTqX2dutEXXVOvr6nd1Ov7VfZb3PubO3Mfp
Gb7VY/dqgUV7HJuua9eBq9HNVUdva7yL167PfHBDG+REbI6ONjHSNSWadGvc1EVzeMQRLuu1TiET
v7ssiuXVO73fu/f9tPY07m72ve9Wy9Xd17mqd91rp7Sr7Kp19SfwU0X7qImmq6dWv2ve+zprpqqI
iL1Nbp1f7f7f6tE9hP8AH5V7ja/+tyzbE/c1RfmsX6ssbJXwPlYsLZ42RSPhdN6U2Vsc7JIX8Nz0
fuzRyRqiLvMcnVtr1om71oq6r1fy6qiqrV1160TZriihxUXqa4ieOFXe320rm+wiqunbLp7OmmzX
TE0RMqaMar5gJ5URzeDub2/KrWPR7oH/AGrmyOj7Zr9X8OGNkTd9z91jN1m86RZZnbrW7qLJI5z1
cvW98j5OtdVWkSvN570Q1fS9YsQNj6bWdW4cWjhX9GjvaugslosCGztkig1fC9EVd5NVRrdVVN3e
01Tq010dvd7vJ7G4ib6qs9Ckzltha0O5JEc1/EaDYkHiCzq/RIVSUmrOh3d/qWHqRsax7dTk/gp1
9S993U3lar1eq72jmK/RVc5dxNNH6Kru17b21TTdarnOTttOtnbo/rR6Kiu2sbWxnUWuqxCrA8rc
e7lxAoJSSpVhZxSHcGCFZd2OJ7pGvTSJ+rtop2arFJE2WNUY9naydsxNx7GSJusVvfMjd3dWds5E
/wD06onV3F/6TfY6+rq9pNP3jI/AS/kO2wL8Y5N+jp/2Rc/jof8AQXAtsX/yg4v+b8s2X/b2vsfK
vcbX/wBblm2J+5qi/NYv1ZVlmePBzdVzE8croHwjdKhczKkzHsWLcg4jt/e0TTrR6dopD5YUmnhc
S0BxivFmMiiZ9aTHxRQTSAyEu3OJEyCSZsX1zILATItbDOwnBMwyRr0e4MrGQQLYCAZO1Y2RCrSn
MiJVY4SHOYxOBMQUMMdHywVlJ19iDsoK1FdpxsQo0iRnpjN93DyGHqSDcYrY428JmqhwiMGrAacB
54RYJLoZdQbJqOOGG5gno8Y1EJl4hEIvAgnXmZOPIkvWrJUehNUNWWMuS5DgjC8duyQnOsq7IK3H
uXHxLIWlMhjCbUkcObGJy4QKol5RlVbIPeLJYZA7KulsrvmU59c4/H7eg7IWPlFjXYfRBIoknZHy
e8ltDWW8tPYI6rsJawTo54NZFHPcTSTn81J2RC7aXscUrKw/Fm5JLAVnzrzL7GNk51SySCEQMs+J
8AV9P6DYQpmx2QzWCi8I9pT84bk3TGHrij6aTJPQX6HYwaGXIelHDpFhMu8ezLozIsk4+QyQuFbS
s5iaja/Pyq2PMguLiXZLESqjDz9wwd2FyQ+LmVdpaWx9PYF2qRS2lND2P6WpeDAdMHIRbTDslW4p
nN7JdhGT2OCIsVjqScpuWWGVHtvPRFBlChvKjILmZLURwh5W+WihBWaCiiGngmjbJG+LJrKEitik
UomPOKSlxmGCuqYoauIExHYFfzkytmIdYV0kV0E6UgR45I6zSjfxa+13y9XUvs9X7yEfgJfyHbYF
+Mcm/R0/7Iufx0P+guBbYx/lAxf835Zsv+3sJ9j5V7ja/wDrcs2xP3NUX5rF+rIsMMU87Wq8eKZ3
DjcQxN+BHSo16xemo30xGqre6ibNRqNRNzRqI7TtU004aJ3Y03tGr1biaIxqI9dmPlcu/PMgwsKP
jSYouVsj4hh+O9kSzP3Huaj13Eaxyu7RvVAFFHZhSEhUR4rrAceCIsfJGlup3w8MwmRriWhT6iyJ
CSK9iMKY18jdV07q+3/C6kTf+6vUiaex/NvJ1dbfaXRm+q/avVNOGq7nbObr18PX0t1cQewidamd
pYcSWFhCHzTNFilNBHJiBtJRXoycXpKExAC2NKC4BKcVOrte71IqonX3epF0T/sXVU63LroiaJ7S
dSbdxPZT7yO75E9pF0TVE01Xr7uyaaJ1oia977TW6K5qdbtGsT2HuTROvb2P+3Rd3Tq9je3Xa/eT
q9pXb3U1uq9smmujXSarI1qI2JqpInpvXq9NE3NlT2urudxepev+J3sIvt73sfvGR+Al/IdtgX4x
yb9HT/si6/HQ/wCguBbYv/lBxb835Z9kZT7j63+uyzbE/czQ/moT6uormRzSE147JJfBs5o8cWV3
auY/qinfvaPY/d7aFyParkLIfBNEoEhERscMU5npw7Ekl5JYI5HnNVjkWNg8CkpM1QpxIbJs4A+P
9GxzPsJM1qWQw8MgQjhhEEofNDxI4ZeEozJIuNHvDzwE70MxEErJX4oRTBvBBteyHQ22QSyzyy7j
UlngEb6ZJIzgJMc6V0nU9VjdxHK3REVurutq9bep+vX1NfvN1f1brVXuaLvqu9tj/Y7hJmaVmtNU
G0Jg73snHorwGQnNpITYV9LLp5Q7qYAlr2pzV5jUPVvv2pGV1VSOIi7GHYnhFt5ItZUlyPJLXGh1
uTYZI5Z8dpZpOlIQ2Oge79uUaWM8jjx4zjVdFU5Dk93Bf2UplfQCDBqFTLWsQYSgv+ydQP4yrawS
EmNy058EQ08raaWGdZa2ldWDMGyq6JGGGpH1omQPkKSvLtLEFu/luG1icoGEUQ8+XI4x+EJOweMw
mUePaW5q4MXGjquxVR9kayGLr7ezccWYuRqbSAEV9uPEHFPFSfWZz0tJA5UlaolzG504p40BVELS
1Gd9jGkkryI5lyM0067wy+Q6CxjtBQRY1isox2VT6khToICyks2QSIIlBjuOk0VaTa1N9cPtL8Ey
0BbBSLTRNEgAAtaOR807rZs8pnSCRV4okrnBE8w10HZCtJrAAekM7A0Vx0FENYlJHMaLmcaTV9u6
2HCe5Sxnz9KMotD6tQBY4BJBXkz3YtiFQWViDQ4GfQ9FwTijiNzK9JxlArN1xeCwWXRBAcRPP9IY
qJcNXhTsx5FUmLEaG4raiiMtW5SdayWFYx05FXj5eNcs+urqTOchCq5zoLooJ3M5Hc8CceOzWFY/
2qlyMClmxQUHGcDEzcl98NZklG/X2QQFVsXJWYLBIJoqqDdtlYYtbO7R9XaoaxArk4SOgFpMcvcS
oDqGxDsH5JaT5MLj5Tpw7SK0HErJIlyOEcCuloLR9kRXEM5wTnG8kHj+LCYZROsbnsuOnIJpLAgW
NcQywMAcro6uuapSjrjn5ZLid5sHEMndZM8C6vMyjJy5aEmik7BNPlkuG2NRY2FW8wkXLHzDPdJk
DA5Yp7AKRthO6pbLZU3I1jmjTBLYEXBA8WMMxvG8nwPHiAVr7Nbc4bLhMT48gpzLeICtkqiMhdKO
19bYRnjsaI9te8dTC6BVlxXoLIM/yHDI6po9guRAQ44NkaTmSn9K8mUSWXRxTyitphW1IpcQ75rK
SRpTOyFQ15OPAV1R2NTri26YiLmsLWO8gv66IerlgsAoKpBOjH6mki3TTTCxwWiB7ikymY9jVAJL
TY/0NUHnFDVk6RkWWOBWkdsUTJnlLbDBiPsR/wBrQ8OuOlIQiGD3YpBLkq4zm1FGUHXEYIFfA24M
x6BZna5nT1p1bAvMxjsKxWPjFpJukPbYE0xkMyRjyRk5vmipTOoMUTMR4cYYAb6IZi8TkLH4x+QL
b8kGyxeC8toLcZlkHryxJefnXXfW0sKIKtjQwYqa+XHBbiAbHJKossg6HEcX7KmQWNu0cyESLmQM
iQ2YY9Jx8blQSVzxCo5oyIyRoCGERRviinZNE2Rs0cUjpJI45Ecj2Rve97GqjXOcqa/YxH4CX8h2
2BfjHJv0dP8Asi5/HQ/6C4Fti3+UDFv7Bln2RlHuQrf67LNsS9zND+ahPqyxloQo3pc0nKtJfOii
yISzhIFHIUjlfEiOdEnE3e0j9Mc3ZkUcLIoomsSOJjGtijbo1UbExGt3ERya94x3ETe073apsxTa
6Cxo1LdDDa68hO09kMcnHVO2bInLM4crUfIzr00Ry7zq+3nw+or1Zw5C6+4MtzWMciIkrB5qqkjD
kVUfwZX2BbYpODw01V+82Rjo5o3dbHsVr2L91rmqrV7qpqn3l69dhGi1wIzQBnBgtHFghaEI9YVc
KI2NjUGHc4Ydyww7kauhiVW6sbpIM2kqWjzVrKWaBK4ThTU8fM7lVNHwd2WtbzhmgL0cMnNk+len
y70FBLh2LyUQpDjBqR9DVupxzHpIjjIatRVBiLVJp05lkCTohBKI/wCuJt8eqtKKosqsRYnCVthX
CGgjLA1Yx+XEJikHh5eNyxjpHG1II9GRbjUREkGSip2jzVsdLNA2tDbDLTw8bhVMkSQox9bFzE6x
guRRmLNKrYkWR2sVmbjNAbYwDwBwHlU9eQZAGLNzIwkJUw75ohRyE48A8b2wxT+msYj+22YLf0VR
eCxTsKjGuK0OzgjJYxY2kMiNhmY2dsarGkqN3+Gqs3t1dNmFn4/SGlRgkVcZJlUASRHWmQqOXXMm
mgfI0EqBzoCRGuQeeFVjkjcxVTYpCqmsJQ+vZUnJOALMhlVHx1jrCkkidzFexSidwKXfGbzE+kfp
0m9A2jxyhpmi83yzaqor65B+kOW5/gIIPCkXO8kHzfD3eZ5Qbjb/AAIt2XKboGputKikr68K0pwz
uizaWxurBlsGUXxuCVJ0vwmcEeGWDlt9CH8XciFyEmhpSL8GPghXk9WDLcBw6SpwhbKSBxo8ehE6
bkUzW6TS9Xpj9WEj1VdARG6xfGRCCNFMx9uQwu2eyVkSPa60KiiJsXI5FNIjZMTxJGNcgvExjHpO
SrZ6YLfpa13KU5UToCqkXeGXgVpML3wzgxbos0T3RyROa5U2IY6prHMMJCMLa4AVWlF1qCpXFEIs
WkxICAhIFPJvSCoGLwHM5eLcgzE2XF2NCNJsR4qPDWVF9YGPrp6gF+T5NLd2ct7HWVxhjB4oa6qR
SZICNWsGaO4Yi9x2iupw4yIRJ7apAsZhYjGcMuIaQweZ8EZUfaEMiVrZ2drIjk6tgrszGqAu6rWw
srrcmnrp7OvYO5zx2BHyjuKFbA973wtglYkTnuczRXLsQP0RV8uZYNti4OQF4JVq2eEptmRHwtye
waUMOS0yRHEJPBDMknEiY5J8ibQUjcgKg5Ym9bVApcEDcOOHl57NIOdlg4UMMXCkmczhxRs3d1jU
R4KYBhKBSExmyB+hWi5V5kUcsURbx+Q4TiY4p5oo51bxWRzSsa5GyORdE6kTqRE7iJ9jEfgJfyHb
YF+Mcm/R0/7Iufx0P+guB7Yr/lAxb+wZZ9kZR7kK3+uyzbEvczQ/moT6vNNgcTpMFAkEe7xXyGHj
CM3FkcyNNx06Sbjnx8dzGtWaBrVcrJhXNfF3i7iP3o5Y95kg8sLo4pB5YZdGSRTpFJE5ksc7IHxu
btTF1dqbWyJBO2WME0oXmGObAuqyDyx8aNnEc9nsIknW1j95raqe0R0tnBCUOYU8o5pEkkE0rWTS
SsIasj+CsWjn7ztWNfrvojtonMcquSey7ZeveVLIxn8SNVE6vtWojU6k02SSzLGKzkiCogqiZRoW
DWRGWxRy0FryoMUEXRwbpTmGNhha6QfHrOVNXQTu2xie2r73J7ZcJp8ry2wpxaKKKoAOimRtodCR
Y0rZlNkAs5YK7Hg7E3hV5G5XtdKBGSSAlRkJAgNxQUthfjC1vQYheTDVBFK7fJtR7MoU110GOsgF
WW8SZHqYg40oZJFJjwlXe3FXYE5/FZXRzMXFJBKxjJhKhWjtht65qUlY6eVu/PVkWhtaVQyQTWVl
0srSbaemyMaq9D1rlNLZTi1XL5TTU8DSiJ6OEW6LOheSLNAaGPfi0pMoUzJeDpAa+AWigxzIojJa
0e3NUiTF4201bYEnQVhllAmRvsHJYNr5ZRm1oVg8ZkjGWcYxbJxoP+3ua9Xd/wBkTXu9zT95SPwE
v5DtsC/GOTfo6f8AZF3+OYP0FwPbFf8AKBi39gyz7Iyj3IVv9dlm2Je5mh/NQn1eCLNHBOhAJEcs
0TpomuDPGLbvRNlgV/bQppHxo+N1xq9nVIwoV8TS2mOn6QUlI5+kFnbwiOa9LZFK2SJEHdBwmwRx
MaMyJI42ptGbc1ql8vziijBx28ekx7uMfI9lHYAcR5cqcWaaeKaVZXSS7+/I/WMBMTtKwRZUZDMy
XNiRfTFckkhLJ7Sv4KJ2iq5eMxP/ACzutjGBrLxla6eRXqzl0e4sqctUSJXPWPt51YiK/VdEa9ds
Wnh5uUjEKKSir55J42ceF8SDxFmxDMjhmKCglPSvkWNrAYbqzSBkfNy7V4AF3ktUINjYOIWkAZNW
1choAOOgYFtNLVEvEdHGbYQJYY2+kt0jsX6HMfCI4e6YspsMd/e47kRbYXDRRQFYu2haBEIzlPSw
/wDB4B00UyyzKrp3wTxelNhrrIQ+4DKAtMtsXta6pliLhzW3hucgqi+PUEo2vnLHGcM4FQbeKGJj
FsdZJ1ebVT3WSHVkuNW2KVAZs9duY7TXcUQ5QlU6KtGKKlaMIFBEXks9yZBEMyEYmOIo6IjH7Ymz
sHQY26OarpOXoErojYopBmmMPWhfkg0zmTMZIwO6HDnjHhZKI5vE39f4S73X1Lovc1TcZpup2qap
rutTeVV1/eUj8BL+Q7bAvxjk36On/ZF7+OYP0GwPbFf8oGL/ANgyz7Iyj3IVv9dlm2Je5mh/NQn1
ZukuCoMrEGJaUxsoskRb0FWGZjtWuZOs6ROSVro1a9Wqmjn7bzetFXXeRdWu169Wu+2TRdP4tPY2
a+yLjr2EuHEhOJaa4eMywZYcr6grrORNyOtNnkdPCPBrGPAhCvI3UlEyuyCjGuJylxJKW2yGRSRY
CRY2j3TLCXhNnew4JVlrk4Tl5tsQ8aQptWkzycSaUASad+jWRvfKKyaSVN1sW5Er3ORN+FrtNNIm
dsrhsq6DeIathjQRdDLZtdIHDk9rVD15zTYQ3oWK4C3GOiUcZWzTo+rk4KxTkQXr7DIqNC8Yqp7a
2pYrarW9jgj5dY4kq5Th5WEGSkhhVzZ1hiLOsA42uaso7SGWol9TkAO5NEKisgZB2uOkjiCjdJHO
6ON5MskcUDVeq8WThIu/vJs8m6yKjpx2F9HPntbaur4efQfm+Q4xpUEDTnCfXLBnycVIFSd0fCaq
7WZS2NSXaC4/ZX9fQdLixWdvCDXn2kLRRkWcqeAweuMfGRCHNw4ByZUZM6F+5LAIaJOaJGCtiBCV
FMVXLYDMMFYbE300ZZhVWeBk8ET541SSLdY5NLM2uybHTg6VXLdki3dZNFUtjbIqrZzRkviCdpC/
e56URYmxvV/g3MXJTTrrH66goreurBckIvgY6i1Szoqy6gmiMnWANi62LhYmxFltLQbmo5GJNy8I
vP5RjoPPMAkB5y7rRucjtOP0ZILxiWcwyx5UnkHRb6F8vPy6ycKTdy2qivayInCpVZfKRZ1bIxoY
gxSizl3TXyQgV8hK19gUZGK0WyFLEk0WHedWFQ5Xjco13K+CmIjvKx8FvNGXDXyRVkrSljPlYeQO
E+MV0rmlzwjKiTSMYpMtBeU95GHOopclPZhWbBSkTeUYl4U0zYJ0aqKsMitkRF13f3gI/AS/kO2w
L8Y5N+jp/wBkXv44h/QbBNsW93+Mfm/I/lX+Vfb+yMo9yFb/AF2WbYl7maH81CfV0iHUtzS6yXlU
3frhIbMWZYu39L3VZG/ffN6VGzefIsbN+aIqBxjoZSpDJYuVRkrKnmGqkcVe0yGXi8tIiTNYWyWN
5Ms/pDRuELEsF/ZntCFMHJknH1HKHlhKs1ChbOLQWkLY41toR4eINx3QjQEzSSzOUhzhrx1jM8WG
eQYMog6xkeLJDQIpkhgVZVxsjg4I8LBpIWzo6cmaVu65itiSBsaQ8JOWa3tGbqtThcNiJ6WxrFRG
q1EWJvat3U2wKvCOrYrigjxGsyaRyTuDu6PH76svJIopWQrPHZhGASTUsr9IYeftht8NpyGi5iEr
Aihb1M7lqb+fOMzRAZsyHs3owrsfSxEYjxIZbaUQi2AOZKRwulFAYZJJCgi20tVWCn48yuyUCvPM
suJb08NsPjZgBk9XWcwwbpmW3IkLEgljOqaqFjZIUmIXH8kFjxu5yYWLKunwrE+0r66cnKDq20nN
q7UWivDuLTPph6cIQmmc4ypk9KNAkF5cm/rhSKiSSw7Eg2AATK0kWMa4hXKJCfS4RyeToeYuwmjM
GcWWNGC+N8cz4t+QigfOCUIO5ZKq5a+WW0sJSlWc6W9HaMNBORAau446EuR1sO5in8oXFM8i3NtS
KYy6LCwzRTsoyfIRLi1xPJCL8iY5LasjixqqvXyrDFUY5Xy1+PLIQ8AWwY9rGZCU1cfBlyPMhb6z
paPKclxqIqshxQSnUZ2WU1HDejFx3AkFrI8EMbpiGHlTJxIiih1IwsEPEzjmdhLFsQtLGzKsGxVw
ptrl4hJlUjqeyIto2rCyV1QdJVNsHQiqRaQuh1dnFSKTW8hfHYhfVJ0txchWLrHFBcYH6Js21YEB
AAlh6HN70Q1Ny+yCeWko9WsorXSUdsXV1YSVweaxGhvzXKc4JLMyRuMRDFpkGUVAtmu+NSlDGMe1
EEidAgvNJPO2IsG7cIOBFKNBjlKHeF5PHSVQwcUPKpkFlj+O2psbpkesMNkPYEhxtRiWpEL4hgvs
Zfvff/mTrX+LZPY6u4vdT+Tq/wAQR+Al/IdtgX4xyb9HT/si7/HQv6EYRti/u/xj835F9kZR7kK3
+uyzbEvczQ/moT6r445njvkjkjYRHwnSQvfG9rZI4545IZHRKvG3Z2SRKsTd6KRN5NtO72yff3m6
dar7KordOrqRERqaImm0TCa2vL5mF8r0mqY7OeaQUuugEhZDzAyv35S2ozVzt1WN03dpZh8fpIJG
DiP4kFAPWmM5icwacYmNeYf6VMCrlRJ93uJu9okj44o2pHG3ca1GppG1G9q2NG9SNRUTRnX1O3EV
FRUY5KuE6WSZbCSsiKdU3EVHNYsV0fRoWTuC9DBFhHIyWGcYO5KL5saYNg3PI4WCvj6QglfZ2xNC
GoyuK37cWI2Q0GZwzZOTnFbWGsnjIdHyssD4ZuG+LcY1V/5GjevRXLuKrvZ3kZqnU3tPtnP3kRY+
1RVbortGIzuaOVvWr93r7TgKnU1WbuqJ1JVjmzbkt1Y9E1rN18jZT0CNsHDb0LZOEzl64zfWTtPS
1iVd3dbtp/Cbqu8i6qztEkV28re417d9Xa/aJuqsem0AToyOKTCRNG5gpDxIuWfBA9k1lFAoQpO+
TE2AeUhpRCoS8OKeIIlYV7Xd7ZerTT+PqVWrr32rfZXrRH7yfvIR+Al/IdtgX4xyb9HT/sP+P/s/
1ex9/wDY3n45g/QfBfl2xf3f4x+b8h+yMo9yFb/XZZtiXuZofzUJ9Uu0rqWzyI9vCgEqaoIs+eQg
hzmxTSwgQzlMDicm8XKkTvS03YUdO5sUl/YZZAe23IyKzmqhLwQijagHRdVyo0Qz67mQq5LFh8bJ
OWIl3FlKRpqyNV1LzbIon786o2ORSE3GZNjPLyORYod1ywLHMS1iS8rL6RCWVFvEkYccE0xzcrep
dhydpdhSU8JLpy5ZGMhlgx6OOkeTFHJHcw2xl2YW8EeIJA2TTRTzvTm3Osq+UgZEYk0tXYF1amQN
c9N1CVGeVCm9Ixm8ib66IjsW7HLcfuochp7DFB7IroWyHx8SHHLytszcoHyY0aSis22A9a44EIC4
ssgfNZxwWI8JcNy6srKaGDOR3DdmrIrC2ImNzLeZQHBZ84M+tvT57KBsdhX2AkJ9zQmMPlfZs5u2
DyKVDB6KsnsswCowrvsi1xNjHU9kTI7zdgv3twaWy9B2Q49mtkBJRtNhjuVfZVZD2hPs4CJChDos
tt7szIil3qGCo5+O+q6mYWXDsZJsjAcXJk5GCae6aW6WNOYOrSYya1OXJQ9TaCUkbP57gDsj3pds
p0F9Jhg2PsqMtHxScN+7NiscCgkU0XOUTZLGIqYlcnZ0jMkER9mfd5YRlVZCNdWmMz472Qq8Yyzq
bbi2YolpdZDb4lcC2YT7GsgrsGrwKsmY4Cwhr4ejxGihWVT0vFaXeJ9ku5jDPlLdXU12euLphNOY
IW5ABzK0ONYGjzjRxNN6eIiZI+wN41b6EJ+yUENJk4Hoznvqvss2eRDAOqStVArXW+O5ZPXtuejO
cb2PTwR4ouI5IJgI7EWbCONYZpliSVwoLknpuyzhNfUwwy3b5Ly0SykMobidw/KgkU+eGPyF3Ki2
cNmaUbAIV+8RH4CX8h22BfjHJv0dP+w1XuInfa9Se3rr/N/+37G6T/nmH9B8E2xb3f4x+bsi+yMo
9yFb/XZZtiXuZofzUJ9UydsXHWAMmVIdJ3JKrIZHpHuDCmkPWRWIzdGCNI7bSISZ6tik1VO2Ry9f
UvcXROvVdd1O1Rzu201Rd3VzdhobC2vgBhPTIoKUgIFeM1s/pvNpWz2a6pIm+K0zkXcAeTknTxJK
iDMuci4VM9wAPMy1c5PLE19dIVwLIjHR7IRxL9GkOp7WaF8kO+8xp3NCicOGHhggiP0HiTX0qJmq
tbvPajpZNFVXvf271c57t573rwHjTb8Uw0cicxUTOhlJJZBDxYILKWdiKS9v/B9q5iORNWouyov3
W+yiL7C/93d6vZ02REbr33Wiqu77Kqqo3tV3lZoiORyo5ztNItlVE0XXr7qds1V9tGrprqqLppIj
t9NWv62t3U0bpomnU1E0VN32t1UardNN1Wt000Tb+VOpVTTXq6tF6l9pU609ju7dqnsata1HInad
s7V6elsRUREbv7jEXXeVzXK3Zf8ApOXuK3rcu8vauVXJ1rr1r91O1VE+y0+8n3P5l60/j/xJH4CX
8h22BfjHJv0dP+w+5+wT7+11+OYP0GwPbF/d/jH5vyH7Iyj3IVv9dlm2Je5mh/NQn1bFjY1kc8Ap
EYkSy76tglcjOG0GydNvabvBirrGZ+ujACdeGqeymiadz2vudXve19hvVt3qKu45E16+vRdNe1VU
RdNOrVV7m4umqWaOYT9c2MUjJIQSpo5E5OhCRVmgqIYX+mzoySZxdpwoYiHy2UMIJIVNaugiMa9K
WwnR0tcaKqKyuiJa1UJDjejlQqPVqt3mSxyQOYk0UsbVWu5QU0N1oYaYYNPNHwn5NKgHNrA8cidj
uhz55Ufw1grQrEqE2Nw6s2YKY8CacgJ9kGbWRyw19iNG4Rk8wyEyESbiKdXkCS8V8ZtdZBkIrZOI
yOFB5ioILGqaL2QpBB96EDAefWLpcibjsWvnGnsDoWktbPI2pmyGyUORKmJWn41j+OiuxXGLCqpL
FYxqhrxhzKYKxSxaS7NwbAAQOCyF5WuFwS3gOgCkZBbjKW7onD1yFmPIHm2Im5CBFShnRT1hNZNS
MmgnMMtjIbQU8e1UmCYQMXo9zWCzPPjePYmZQgrsZ6FxbKcNoXgTCWUt7aw5WPjSPfGZDYoLVzDk
XU0tXI6qtYrncStWOvmglNk7IWRzQ4vNjtIBngMeK2VEYeeUTiiWImt3YyXUASiWUwMhDqZMeSRt
cXE3pORyrK7EgaRaUCxye1GphzLUUgmoq0bTWFvJu1Yh9XMdLJFVvBBr47UDdlnSVxMiDLASDR4t
WV9xe5Bl3Zes5iRoK+yAe2kzGVk8NcJb5tgjJGFS2jZ+O2+LJBFHX9q7BskpQceMG19cFksloISQ
C+OUqAbDJ6uOzKPk5c18cpA5fM4lzbSUElumRnNEUKVgz8TqaOHFMXiiwfGsosoFojSQyBbcgwTo
nF6wS9p21Q9c2tkSU6ci1jHebXw9HuTedJaMdj0cWGCXOS0KHNjqWzBlY+bMAycg9ubFWpUh04j9
6rfgVPybTYJEtTBxkJseRFd2ToRIrGrDjbXf7jrqsZgTJ78ggJLbmbbk+YFxq21PSSxdHzg8sPF6
IAXBTQ44222U4Fk9r2QJ4mRNIs70W7x7hl3UkSqs54FrYX9aK8iR8w0KlAxtiihdFF9h91U+9p7H
3VRU6/5dk06k9hPa/i9j/EkfgJfyHbYF+Mcm/R0/7HTT2F/hK3209jXXu9xer2e6ibXX46g/QbA9
sX93+Mfm/IfsjKPchW/12WbYl7maH81CfVs4kajnSVxjGMVnE4jnjytSLhchaOl33bqcOOtsZHdx
AiVVsMvdT7Zf82u6/e9hPY7m4uvfNaurduMWQOOPq1vGKkjhgRX97q6WRjV39d1re7vbIPFb1khK
u3OAywCknc/uNbw0ndLvK12qN3VerdEXXvHGCjRQkSEjvH4BRkwLHxz6Mn3jIArJ0PDGkn3N0Erj
SNhjV8OqzbHzXZGK2JxYxYTHDvOGFbCYwuSVJYeQIke9C7E9u9AQPI4eTtXxJI4dohBrKyNBcejp
2cgSS/VY21rd9GFixzbixgNYiTzESaQR7z9N1sZ8i1wKvtI2Q2T1Eg3rGGNkkccRy7n13GxksrGM
n32tbLK1qIkj9a+znxfHZbKoiHHqbCSlrXnVY4mvKQ1xbhlnCiF1Xl4xnxsg1Xho3avcPW1461Qj
6+rdCGNC6sAnSBswYD0i+tRp+TASQUfhRycmLxGuSCJrbvKzq+rs7ewtYbCsMJpxukKLgUVRRuir
7CdJi4uIlVzDpxZBmu5hWtZozfebbzYzj8ttZCSV9jaSU1c6xPBmgYNKEYco/MlCyDMYO8eeV8To
GthVqxojdn1NxUVltVSLFv1lmAKfXv4Dmvg3gyopR3cF7GOh1j9Lcxqs0VqbR052KY0bUQlSHQ1Z
dFVkV0RsqyrKZGDMK8ZhUizzrIQ2JJXrNKrnrxH6xEjVleOSPXx1EBEAQ0U8NVC5HxVkUscbXx18
T2o+MJjkGY5Ec2NFTapiNxfHS4qDRaKMqkrZ46RWrCrVqWSjObW7qjjqnJpDosEOng2aPyVmOULM
jkarZMgbUV7bt7VhQZWvtUH55zVGa0dUWfTgokXeJu/UsTaynq6424mQm2LBrxBCrQhu/ukWM48U
cpszeJJpKS6R6cR+i9suv2aR+Al/IdtgX4xyb9HT/si7/HI/6DYHti3+UDFv7BlXyJ/IntfZGUe5
Ct/rss2xL3M0P5qE+qpCD80iyBiqOzc4kymmwBNT0xWRqjOZV/Ce9iTL2izQN33OScdySxu3muVq
SK+OVF3Jh5o5I45R5ope0lhnSKSFWSMnZA6JWotjIXaDgPoW8zwTZnCR2rrBjK0iBJFmZDvixFM1
GZDGiKk7omk7zkPgAvchMvCI5uhI3X9gaU6whakwb2OI1eyEE9opKpv8JGxsl034YlZUDRuJe2Ou
FckhL5yJ3q6BsjnuWZ0suqK7XhapFBqkEKMijjYwS3ts79FtczATMkzl7h8bkZg9rXvDkhD4uKVF
ZwukYpbncqLOY+yk6JY8VGMllV581rjeW05YPQT21BgdVLaFi5Lbx0NWaN0Xc2Vc5JbOdYZwyChb
AF8T+aAjjbG92ZSX+I3NQDj9zUVgLXz4ewuWa3BoXQ1xZHo1KqksJDrlJGGKWLTRhvDgnL6UdOGx
1pEHNVWxy11aEHZ8nLKBaXtmHS1vO9HGWIUvBLsYJpmjGFRPjie1H67yJdV4uWWlEDiRgFHzNfX4
2Ta31o6nrLQywt1sqWzBhCVLMYeIKqrKeRSI7ElpnKvEgFyaGuysjFw8UKFpoGAVVCWlvbOqK24L
PvFuQbORtarbEQUICqJqDUjQkmewl5kTkcYkMdHBjd5hOLzWVdHBE2OryTJDciiCsYi54GWDxDSq
cWjEHJkRs01rWSMHbI+VzsxGnLifi0VPSG4uIwaFj2xdKZDSn2MpPDQmfpU2mlJEa6Z47K3knRsb
NIQ582ttZQYkPcn17CZaqqjwE0Wqx3fsa1MicE+/TNIMjdMyNyGw4zLBWHVMPHuwDxm0+SBMdTWF
mZgDpRnpCW8OHIckx8SxAepIyMe7k7AkN0yjRSsVeLE2CZrFZi1eT2Qf9zuosaXMDCbPTFfrqxqn
Y6lYLrlNTaxy9qec/ka9sBpmm6yTtE07F1jNluSYmbmRtVV39EDV4co9fLJid3cFyCMv8St7QU15
1ZCkkJppUY8b5h+WZIiPZf43YGy2SBg0t3WmkwhwEqHbOsgZg5UAFDFmUQ2mmmbOyCOThHxQzN9J
ZNP9i+wnd09lfv6r3PvaKn+rZN7TX2dPb+/1a/yJ/wBn+II/AS/kO2wL8Y5N+jp/2J/Gvsaf7ff9
nu/sLv8AHI/6DYHti3u/xf8AsGSf/wDX8v3fsjKPchW/12WbYl7maH81CfV4Is0cE6EAkRyzROmi
a4M8Ytu9E2WBX9tCmkfGj43XGr2dUjCBHxtKYY4jpBSUinWwUhvCJUxViZFLG6JGQOgbEyBkbEFb
Fwo2t2JEGbEHzbTE4kQ6MRCC1nnlJ4bOGr5ZJ5pynybyLLO98rnLI9yqRYGxyRRi0ggY29DYxske
dJDMRuvLKK9NBZXMhcsT2cTmfTUVVVz+rdVuiIjd5ER6O71NN1Ea5+9rp3FXRO5tDg7+ObTx0D8b
kWeZIyiQJROTIWUgOKPhyEQLvq+Lhq5ZOtNdpmW17kN+YSRjcnSlo+nabAFit4PfV1bDHX09cCgj
jotTp5Q5bawjle0uwn4AaD5GZX5Lf00mUuBmsIQo8ZMgjIEGCr+eFHvMbt3pIZWAD1pkJjyAUh4j
4A4Z9CNh8Op5+XStFFWlLJRjVisaomK1rjp4ggxgo2RWgwpU7Aw4RI274AYwjJI9G3wN9eYbZnhi
xXcGOz0xYFjPBHA0d5EWQ0FqMswTWuAita0SusCglHjnm4QwcY0xwGQ5Ljb7EUcK8jpCgUddxCxc
vBxybWqsj68toaSivtseKprmeGMN8h75a6skEsBOGWMGfi9JiMAYc7YWV1Zjk1sVTTVkjouYGsq6
S1Wcc2SaRRig68gdYyonSOW0A5iNyY9UYvEKsrZBIayiJsiQuHvRcypG9aTxTTSkypNHFC7cSbjS
zWdSTkGVNxW2NLsiMRGNrBKiM8wtbOUgWwHp48rHYlw5bdgTMj6OaWqw8mtb9YbJjVlkN8S9CK4v
0Q7tBFec1U24tyDPuQ0MdCroiQx41atFwpYGaSxvlc+Zae4scgvL+0pQ7wEYy0bQwOmGvpamYhhM
NFRUwjlGWnGaG6EeByNkn5lSXOjdFQlEyEMkx246bCSB0bWSldGWdVwykkilV4/L2pD92J0MnGZC
7i7jXxyZHf2CipLZtrKuuiFllmSKjpkNmEcU+YcdWnkn21nMRDEkg0EKixRzTSNmmk+ziPwEv5Dt
sC/GOTfo6f8AYemnt/e9ju+zquv7G7/HI/6DYHtivu+xf+wZL9kZR7kK3+uyzbEvczQ/moT6s3SX
BUGViDEtKY2UWSIt6CrDMx2rXMnWdInJK10aterVTRz9lXqc1zX9aLq16PRq9S/bJpomv3NE2yuk
DzK8x0EIAGxjYJYH8vrHWUKSQRiD2Iu4s0h7nq5iJvdsm93U2muWdkjIT5KyQadg5EhywSStKih1
liKuCoZB+I9ZnxKMSsiR8Dg7r2wz092Sg/MWFeOXMwXRsG/LFvPij1Im4fDk7TWaeSVqtek0Ik3E
GhqJ8gpqvGwMixQ3LaWwEyXpiLo6qcB0nHb81S0fRcocVsGQ10SWtfweZWYwdwzYiK18uXYsxLgi
YSp38hqWttixC4gixa1ziG88QIY7k5oYHPdES5sBCMkfowGmOvKcW6sW8YCqLswBrQyPV6I8YKYz
mSdyNkjJphmTI9zHOY3htdAlxMuV4xw8deg+QSre1axUkkk6iNZbOcYjaxZZ2SQLEa6F7iG8NOKr
WqtSLBk9C4u/G5ulHZcVryboWZU4ZtYxJHONjekb0gmH3xnPasWjtxOHawi5LjpRFGk77+AW5q53
VCDNl5pbiKMzWv4bRSGyc/I3gOhn33OjHkelcDDlOOSm26kpVCQ3dYpNnypJQs/R4zS1IObGUMVC
5A2zrERDNG/cfEqN/j+7/wBv+ydzup+8hH4CX8h22BfjHJv0dP8AsP8Al/1p+xu/xzB+g2B7Yr7v
sX/sGSfZGUe5Ct/rss2xL3M0P5qE+rpEOpbml1kvKpu/XCQ2Ysyxdv6XuqyN+++b0qNm8+RY2b80
RI7zHQyFuNli5XhvZUKR2sUFewyGVZeCqPIRC45onFcVOAwZWDR5cYWlkdGQCExrhYRpJmq+tpzG
RNSN4TOCOOzgxb7XPfHCyUmaV6yyoZjwQFlXmHObwzLYMYSta+MxhDEPJU97WMmjjngh4jZHvJdA
n1nC0yV+J7/bOXHqtWrI+R75GuCHdC57pZSJHtdEsbuI9Y3bit0FDboLFYY+x/NZVZYCdiU9pY3d
7cAxPIqihFjr47gw2OmrpSpUnLBqIQhZ+EiyQP5UbhWDaiHGiw8iweqwi1juijB2UUVbJbNQ2qrx
qs2G8HlZfTukp5isfbzVaFG2z3CHrX2sgUVXZ0WRS1ZRdrY3R1dk9ZIBShUiiDgMorAa0iVldBYi
pPbVCxlWFnFOOibjp21c1NVWhdSHWBUtw/srdkOBJErLQQoI4WqJo7sDC5IuSEOlgoefAknjfVvF
hpCn8GgPmMrkLSurhs1vIL1ZS7hg0Nk/otMYdiAtMk0ZNj9Z5LWl4ufO1VmOA5SCOmITGTPQsPHS
4BlWDY7Z1xNi6fIOm61oMZ15BLWMShHRAoSzKsObK5J7B7iojOFXuYdQ2NOytp64evrQMjNbekvW
yra6A/dpW4rNjc1VwYZJ4lguwryisWx7zZIZBBIwJXbyaKr1X7unVu7y7rdVRm63raipojFV+7xH
/vGR+Al/IdtgX4xyb9HT/sNf2N1+OYP0GwPbFfd9i/8AYMl+yMo9yFb/AF2WbYl7maH81CfVljjm
cM58ErGERtjfNBLIm5HLEyZko8ixarJw54pY3PbFvxPbqm3c01XX7vW3Tu+2neJ7TUREXZZZRxu6
k75XxR+EiUdzXq9Wqr5GIINJH9sxQhlRW8GJWNgErxIgogyHQScokb3OFlqGRSQekxLDE1sQ6Ma1
EVFEGVF+t4EjequRrGM33K5yIjU3ZO2c5Xrw49WJq90SsajXq7farljniqJTSWwxxypORTXlaCcL
NIrGG0x9nWB115Wru/W59NPYBkRSjyqSkMzJ5W6rqrm66J3u9uMeqpor0Y3e9lXzN7Zu5Iu85Faj
UTTttF7ZrlV70d36dsiSOa97na+mKjHOc5znbx1tYS8uBUhkHmFbjpUiGGjkmlduRte6RI40erGR
enM00Ru7J2zHM645GNciq1zOuZEVF4Lk4jFlbI5XpJuyN+2RN5XbJLOwh7JJhR90QA+wn4xE8cUb
nDgQSzjwwvXeeXI1IhGI4siYeCGWRasc2XhTXVktVWNSOVeMdyhlmkOsUXpSPHrSZeI6NjHcNvW5
VR7v+5U06kVE69P9SadzTq/YEEVpHMRC2FjVTu4U0W4fUmzV9hBpPHE53LmDzQ8ViOhl3OJDJJE5
r1/ZQAyFDsNKiInGDfPG0omARYGlTQDq5JZohnEjIRJG1zIVIgSRW8Vm9sQDYH8uULDRzzxcqbLu
RZJcSUNK7fgGkjdzltFILoxznD7vHKSAZUmX/G9z/b/t2626+2qNVE7mqroq66O7iI3f0Xuqu3e9
XV19trqrtO93e5/ytfu9zr27n7H/ALtiPwMv5C7YF+Mcm/R0/wCw16lTvva0Xtvvqv8Aq7q9Xtfs
Lr8cwfoNge2K+77F/wCwZJ9kZR7kK3+uyzbEvczQ/moT6r1nmcNBzdWwghkj4HQjyWgaTv5liscN
uxovp2+jGd2Tdb27Z3zxcQlriEr+b3gXmtYxijSWDIhJ1A4r0fG9Yx3S8ujSlAiImWvGo7ATFmW4
1dzRRc4JznEwRww3kTGtgc2FJJpRSg52jIyZsRMk0DSTWwRFSM1RGsjqj9GtTdam4VSMRqtVN5sk
bXLFMj+24zJPY3dnaxPm7RyK1mm8rXdTmNRVa3tvtmyOa2TdajeI9qIlvR4izOPQXXBY1HDHY0F1
Q5JRV3TwQuQY9ihlmDXX900bEWmzVpsI1rdCGRsZU3M5stYJEBbAJn8mGhdkAMuIayCy20yqSgdi
tkDYpJV2POZvYU/oqNELHgtRiiUkGLngAioYqkiSlZazZ9WVBJ3ZfNnbGVk+PkKIuXVJGJwlEjS1
9mAjq+TmaEdSg2qKOQE5hA7iA9mC5GP2S57UvsQCjUg1ILkKsIy+YO1iyWHKY6uCIOc4mNKhOXy2
JlbwFJ6EGnsHELsUBDMTuCsWiPWKOwrpxiUDgaVCPOkIznTD8wjObAciDktlG4kZYRLWPKJ9Eotp
QWGG4gkY0lkL05MFmePrluV8sM3Q2rtq2GLlj3N9Ipo8hicQCIcURtj0hA2ez3Ff2Rbom3cYLfJg
41FFTZWNjMtc1UnxccJo5FWLEVSNlso5nkOyXiGzxol3IdcZrNfTRVPoqp4cX7IYJQ8MeUB+iorF
7+4vbjGibDoJ9uwAXsaDU6lNliKqQWli1sIuRSDplMuP9JNdi0OYPvOnnQNrROkGquW/4TsBkt+a
aD6IHcynpzhkbULXK7J1hkzwBtq/scExCoF2QhisfOJzjTKK6tsM0trs2y6NpXtjtbKlHqcVMAiQ
mGnYLzG1xUTydkYjCg+yFXcWeuNzC5yd2MF4UIU6OuuRJjM1Pp4czkjYZJSmE2A0fNBumbWQmwx5
ayqFvBMgktOyQZQR3I7YbyWUu8uiaUmWOxYkMhRTJBp4JTEWCd8jJCFex71XMgseTsmHVqYjgiNE
yaXskSXVSVb5Jfh3N6NW84DnxChjQoYQJUEgk2jK94VOZBW8GaHD6u9tM+hqmQ9lBLAuAjLsWJMg
jyCm9CHSJJdmZkwS8k6YimSzvpruQWGUUs4od1oLPSWFcTl5OU5B2KcqmuGXhVgQENmwg+Puxxei
7RW0eN2ayz2MMQo4tWOcjJnnwEPglnbbIXdZBaPkcFNENkuLdkbHZq4p4r2kRtI7I1/ktjZNleyL
mG1FmtOHLE5w0EbjHSTWat/3SfR1vUKZ5x25s1vLNvh25f6AUKRMX3uikteiF7H3184PknAqtioi
rUhVhXZIGw8zsiwMhfYnZfX5I3G/QVcdLsPPuHR5kDRT5IjIRJ7wgc+Ep0ctVOLB0GQmD2N7HnhL
Kg/so44Ee8zNjFaNHloT8NdeKFO9kwBtTDPxLq9jWvuRRQHXJxqj17m9jt2VzdlSerOoLE3LVqD+
yCZk8eZSC0kdPEfHjk0mU19bGHFdt5ISMajSySIi6iceRFPMktrW3BtnJi/YSjMIUNSJZTKzsnnW
NnGRNXxOClsK2ufEZdcoroRmq8pVQVzJV7I8xF1mEN4tf2RIaemAxXsjSAlBqEe/EJKTJR8gM7HY
xcYzaqYJ1Rj9Vk77BktcZNLYzGvMxIeOXN76KUAGKcQs7slxV9LLL0ubZ31jeteRhWQOIllaPJje
RyDE1bIQ2Uj2x8jTu+xCPwEv5DtsC/GOTfo6f9kXf46E/nwfB9f5dsV932L/ANgyT7Iyj3IVv9dl
m2Je5mh/NQn1XcOKGaZGq8eOeThxunZ28S67kmj2zJCrH7m9GvbMd3U21RqJ3NN3vdE73d007XRe
rRETtndXbO1RzlZHGzr3nOaxrEZ2yrq5NNEYju4rdETutZq+OxsajiiHyMlaQHIkcMBCESxOmNHg
0WVElkDj3/BLxIXb0Eb3zb2mqbqo72ftOtNUXtUbovbOXV+6iaabz26d1qu1emiP1Xqc9dxN7d7Z
247VnUjVika5ypDptp1aaIiKzeYitVjetrepY+vqa1HO3Wonb72qJ/3qn3PY7nUvV7XVp3E27nc9
nuL3UXTVOvRVam8ncd9tqmywiCDiwrKQQ6IWJg8TiC5XkFTujhRjHTkTySTzTORZJJpJJXOWR7nK
miaaaImnVoidaImncTqTq7iomi9W3W1F60X+Pvv4u2RHf9JEd3UT9jMPIsrY54pIXuHInEnRkrFY
5YShZISRpURfS5x5Yp4n6SRSMe1rkOkqoTVJs5IZbA+1uLnILUvlouALHPbZBYWdk8YWPeQUTmuV
GWWd8ELHkTuk+ziPwEv5DtsC/GOTfo6f9kXX3LofX4iYOu2K+77GP7Bkn2RlHuQrf67LNsS9zND+
ahPq7wj2RzSE147ZJU1jYhVgMNKq6K13VHK5XaPa/dTWFUe1VQwqSGWB9fJOw1kUU5ib4rGPn5Pl
4JJDvSnt4UY8fNrPqHOIPYQlAwY/QEFTYniFjPJCTkjxpElLNgIdGoEc0rGsDTiQOZHKrN2dqsNH
InFmFndj9hSUxLiBRGpAcHm1Nj7LB8k0icqUDZMkfavdCsb1KZH3k7IuL6T2rDLUHoI58M3MivMF
LfXsR7mucpkK8pKiRNjIfK1UYjd3iRvWNGr6G6htBj+WMk7HxJeb1UJMnozpCs1qqTpO/aLZUtiL
fFGPiIuOkDr0S1rCbAEa5fNYHNqrl7JcYWrxXIMTxi0ryK6xgt743IBMfJJsKszpp49JEi5FE2rr
Ca2/U+QCaB1tC4jfDsShn0jrAzNcgxbEakLHJrUkyPGrTIITpz5rDOsVrnK+qqOfkIfYUwoMYhKs
6TIsQwRXZBWehEGSo7GNZnlsHZNIN6XNtGWccdbUTgXccdaJCXTys5ybpvm5DhAWNHcnPyFVFZQj
k49SGUtfeFxRVSyItpTA201vzZ+bVNkBXjR2bVgFgxC96QgBWUe045rwq5cZpSaWsgrqauv7Ai3r
ibYq2HsrOxr0Dpxw7ulaJySVU6lWJLj0bKdXM6P3Uc4gUyV2PdAWOaZFhg9JDAW3IQnY667Hmtyr
d9nIGZ29DIYbTR0IPRYBzpZrqZKzfsJyiS8drJsp7FGV5ZVT09XeDHUBmPh00hcSlSZGnNyHC28s
laaHyS0J8cG/0+yB8hFo0yTH7UXEuxiLm1ssNVaBG3Zk/oojjCDfLf2MdRAnQ4UhBhLbqXtTN2D6
7idXl0ORF47azRmdifIYLHGwDquCGG17ItUKgJYR1xfOeu8A+cGyYfC0+Hjt6OHURZJ2Y7h1RHZW
17m3Zjsd+YWtPRIKPNJ2OFhCs81wKGSSd9oyWQiO7nnDgGerag1ksk4OYJV1dJG/HSsbrmVDq+a2
tR57amxi6uCyJWZTTV9o2ihs7RsdYBKJNcKwZBT4pIOFaVlnz0FkpYyPeaNU2FFDPK1zo5lbTWpB
dlVq2Vj43gnEzFDva6OZ++i/Z5H4CX8h22BfjHJv0dP+w/fJ/wDEmmnVp233/wCPX9jd9Wul4Hr8
ScFRf5urbFfd9i/9hyT7Iyj3IVv9dlm2Je5mh/NQn1ZYy0IUb0uaTlWkvnRRZEJZwkCjkKRyviRH
OiTibvaR+mObs2KKJsMbGtbHFGiMjjbup1RMajNxOtde0Y5Xarp3uxNPbioUGUxGvRV7eJ2jkYRD
IvWydv8A5Rq8Tudaps65yG4nykyvjdWY3zyySMpqjVNxm5I/hqWmr2uk3XKkaRqx/EV+38qa9zq+
5ovUnya7H14OI4yEDbK1bUISirBhLNW7+6tgNCKyExWcSThqQyRY+I/c3d92tfbJjVClrUjRg1Vm
lPXpYVoUbZmxhgG8vzIgrGzzo0eCRkScaXRvpj9Vr7HHqU8B5rrF4JlWCSG+wkfJM49400D4XGOm
lllUpzFm4sj5N/ecqqAAM3FK6rGAmrkdNhcFrkgIZXaHj4xdy3YImOtMAVQE3ag3gPe2ZNWo2OMK
5Lx2iNtqxsEdXbE1QJFnXRDayCsCsJYXlipA+WSSHgSQ8N8jnonEc6R4RF3Q09xPWTKRWzWlaHYS
186rGqzAyFwyuEk3oYX78Cxu34o5Nd+NqpPkUFBTQ5AVGkJN7DWBRXBELWRRpDPZshQ2WFI4II+E
+dzOHFGzd3WNRBoI6WqZAECRVhwtrxEiErCmQRE1ozOFuwV5EQosUwUSNGkiGHidGrIImtbHUUlR
VxsDjr2R11aGExoEUxJMQLWjQxtQOMgwyeMZE4LJiiZWsR88qulravGMera6cyCwnAApa0MKY8aS
CYY6UUcaOCQweYUaWAl7FmikHgex7XRRq3o62xjHrOv56e05Gwpa00PpMp80hNjyxI0kPPESEkST
l7nMSvnmdJI50r1UmrKxrHyawxQ3F1xFNXTAFOr4BxgHEiSDuHnUEYMQcNZY3KNAKPFDuMgja0cE
EYcIIOCIYQMSGMYUUaBiRwjjjwtZFBBDG1rIoo2tZGxEa1qImn2eR+Al/IdtgX4xyb9HT/sNE+//
AD//ALfsb52n7th/oXgu2K+77GP7Dkf2RlHuQrf67LNsS9zND+ahPq802BxOkwUCQR7vFfIYeMIz
cWRzI03HTpJuOfHx3Ma1ZoGtVyxzCyMdFrwnNaj96OVqObJDLC6KOUeUeWPhyxTpE+FUljIjhkj3
UyitChLri62kkshr3iCuDaXGOs/CiY6VksskMb4yEe+B4z2rHG9vE40TTn5JfHTWIxs6cZ3JxokD
AWObE1vAbFJulQmu1SJyrqjN5U7VI3M8M2SzZEj99zNRzjIoUkVIlldFo2FjnQsdI7vm6rvKsaZX
c5ARfkkY/XXuOWdVQ18GK210YoMBFMQJW1ElpiBttJ0ODbtsMt5p/R0MNlzTLGYgWkCpbmzMMsLo
AdBpceFjkZj84I1sfEtxe1cpIgJBcg5MYcRVhFKEa9wXLQsmkNvsupjKTczK6xWrgmMxYGO1kBtb
ceKBtjYZW2mGMrwKmfpgq1t6etmPHIZTOsGzAxkc2NUZDaDMxkfKrAusFqTQK2ilNtACyii2XfKm
urpqY16i1E9kRZjyRy4/FcRrI9h1a6pu6YwEMCz4VzBXxtMqbZTGV1qJKBZ2UTByZK4pnKGSD2Yz
+0LCgVrkbildVBXQNUZnB2PF3pgdZHTXfRdDkstlWB8yQ+5FeJcVbI0MKrqqKwUAp1QXYAvbNJwa
zjzteVXQDkxm44TFJDcWcNNWnkiVt9ZXVKLLZnVQjochqKi31s4ZuikYLZsA1OJu60AEHNZp5ZRK
3oIyDD5KWO7s3Sbk167o8o2avr0FQaIuUe1WYQhjaoiSK+yShvMdiMsh6ypCuzcNrybaUgaU1ksZ
M2WJTVULRYCJZPRJa0hDXQqLwFMlGHnqwKGttLLn6ca7KMgLxhRKYMok8Fima5GhVi1p1aUI8vGR
b+u4qRqw18U0crv3hI/AS/kO2wL8Y5N+jp/2H/L/AK19n9jkLv8AnoP9CsM+T+bbFfd9jH9hyT7I
yj3IVv8AXZZtiXuZofzUJ9XgizRwToQCRHLNE6aJrgzxi270TZYFf20KaR8aPjdcavZ1SMKDdGwp
pik8+pTYyefeSzhTqYzcjjnY+NiQOHbGyFsLOVbGkMabXAh1PGzHixp3rK1lco5xli8B9g14KuIk
esr4ipSJSA1SWQqVyzOkXq3fQDSw1L1VjpB6nDGFwPc5V5uRXhv32bqNXgsg4ybzkVN125s0CB0q
QMQhiLvcN2sznyTTb0MEbYHbz5XM4TWxI5/adxm7dT8bJs+yC6qVxcKe3IxgBtGC98pDCt6vFxmF
gI9igxxpiJaZJIogigpO+FETGqGS4tmU9FyKkBQD49LFelV5Ap0R1gXZ01lZiEPMEfO8ihOqT2zl
yztmimbHLERwb/IgJUycvL6goSSnYRjlvZyWC2aVLyKWZhQlu20PjPByJLsXdIVjI4omwMjvI7C4
urKfIsRbhdlYzdDwFSV8b72aMqFlZUAAQHt9EBrVk5NoXpIe4G2VJpJpr+N5Li56Ksx57HOhcPyd
QZaGQSNRozJ+ZWe1LbK9ZeXfEkHDgY9HueNZNvskUMDILPKQsf5mt6HDtbiG3ZYvY1lU23mHKlub
EiIU2zKgCIerK+IWBVhWwxr0RZCVjhNdPV11EW6hkFx0Jz15ZlOdHRQ3crKmPcFr+nLO24cY8O8j
3RRvSrFJYUUHV49fYxy0ssSMsq7JG1aWs1nJFDHPPYELVxyc4PKI7iEEyPY+VzHxghG5nmBptPZj
2tDkEzsXZdUhA4c1dwx3C4uPWWEBIJRgpjb+suHkxlzOkkWVIZIscsrjKMgu3YzNzgQ54eHRRz2S
RlxJZTk1mJ11oOQsJfBkhqrCtryIR4oiQpo5C2lfvCR+Al/IdtgX4xyb9HT/ALIyJf8AnoP9DMP2
xT3fYx/Ycj+yMo9yFb/XZZtiXuZofzUJ9WWAiGMgeeKSEiGWNJYpoZWqySKWF7XMljkYrmPY5qor
HOaqaOVNpuBPDOsEzopuDKyXgENY1zopN1V4cyRyscsb+3ayRn2qt2ntTxR+NLTRaF8jzZb7Gxgh
HgcixDTkNVxpEGnDVETiKjWoiJsDWhjzPU0Sxihhs6rIHDETwNYTBo64DfExzKwU+fixK3f4aNc5
2myu6KqO45PUoC76MZIjW6tF0b/C9O1RFbpp2y69j63XFquH0eFihywvYGqVSk0dpeo5XxiyvORE
rXCvFRjEchCS85DLBFAXbvpTMEty6urfZmcW0o4xx4XjslEIvDxYrB1YAUx6P6SUIjhxpxmjksYv
HbOi4zuuNStZNG6qcP0pMSgMdaKSiqiHvsJIw2N4CSPK9JYGx08LEtFSxwl3Q5EA97I2ak4dOVNP
IGOyxk4snITkmM4MLC3QEvKicImhy8tE4Qeww0kt9ay3eJATRTFLUPGiLit5B0c8ro1BZIC0M3JY
ZBCGTRSLAjHrjMtGNimRB5Fki42lhWE1EwY5kdJbWzkQoRpjZCNayNrYNYpmRFQSq9qq3STG6XEa
CzeCBWXNtIeYNVEdH2J5gLJaWviobFLGeBoM0hfPG0AOq18S2jEmIWCyrHm4YlnUDS2NuCpNBz1a
DE2OWQ6zGaqTBiwwzQOeSVFFHHE+FXyOa5kkhxiz4D0ECBCbJbMtKeTg6nHV5DzouVaGEBEUE8WE
91nLxzojg3jjSAqs2OV1VWY9bV+R1OQWo13XrWlB7lERTDKyBRx5oS2kPtXIs0ZTEgcK5m5Ksi8K
2CbguOz0VLkmOYyXZNPZ05IZkgtLMPOFjyYu8UkcWW8HaUi5DERy0BRUcL1jaPJFusxp3MHkVUG6
yqXjWgnM81WxaJ6YeNyZfMBs1Ih5UniRt4Eu6RLRPxS6jEnUYqSpWnsWDEom8o5Dg+M2GdGqirFI
rXoi67u1vCw3DHy4+x8l9E0ijdJSRx7/ABH27EdvVrI+HJvuMSFG7j95U3V0ju22WEOpZpJ4YrdC
6FauWYaKecmKM9H8q+QeAUmadjZVdFEPPI9GsikVuPUTCMVIKygAuxppx5MflELhGIGGibFIk/En
lspp5WViCwkNMWvsWtejhXNXpSa5wGKs5poPSMlhjrAedeM0xgfNulQfmnhvYU0ficVwz2zozhOR
2xgMeLVB8YoWEGxlM5KNhDMzyufGW7iNrp0RoLYUsGyJI9DUfy6INpzC2FY8zDWWVQHJYW1e6eja
dWARMjllOsBFdxwg44poZJCSWRwsZLG9z0a9qqAFBZYROZa8fowSEugkJseWmnHJ5CBj1lM5cgUm
Cfl2ycKYeeJ+6+KRG2kEfawDWLYx4k7yGN9XWEujjT7VnHnmejE7Vu+qNRE6tu5p1/7L/t7GncXq
T7FI/AS/kO2wL8Y5N+jp/wBkZF+OQ/0NxDbFfd9jH9hyP7Iyj3IVv9dlm2Je5mh/NQn1TBMLIqw7
2dGxRmW0hEMAw82rCZh5RgbN0Z0bOsVZQJ4Ff3zV07W6qrmyGks7i+Ot3GVhE5ywKZWVQDZVKtq6
JTC98J5bnzBcrxXRDNh4LVi2mqwnSlmrXVxY8MiRcZ81eYJZDApwIYh3R8OHlOO3SVzmCue9Xve5
0NjKESMFjU1vCbLOzdRlpwZKzo5d1HohgzbFHzNarUVFVm7udWy9apvI7Vkjt1HKr95GOVXxMiau
67f425G9XQwwSRq+few+mslo0x7BCDCKwyuLtHW12g1edTVTDqwupgDqXxg2Tzp+DeXCqXExsLEj
lVq0VPDNSxH1vY1zTCzpBXEMgIsskGrEYUydR2zvAkJrpyyXSok7iSnywwzu03ENeSKlFujXnKRK
+Qj0cQViUancPg8FavoeNHw7so0rDoIyFkYXNLuw0codc94TsaHHuJs0zG8Sxp6HJ6i4Ka7Gbavk
qsf52vruI4WnfYCqd9Z6QjK9q5JPjZdbj4lyBYycZl0RbJZ5M6ugCrrWenOxxqUTo+FI2eSruThj
ESGwsACzt5+wViRIDAqZ2Lls0PooyTJiFBjwsvF1g6byAdlpZTKZPHMjn7kMLImDQsRsb1fXDhg4
+yIUitLrsqIOsYMlxmdhUM1nLU18VNM2VJw4OXWFl5VxWaTyA2MUldE+AzLhEiDMju4c3fT3R2dZ
qihy5eLYcNhOESAF4vHwn2TxJLKvKWSQBGGNglNWVsliXRGAhqTi+HUEcLLGwp5ZYqK6tTLgJtpX
AEFUkFhWWHJB2tbHNYhyLJLBCNJHDPtj5hcoG5WJ2QXEwxWlvbz7+X3tVbBNbZXEHPWbx4wp4zzr
CWMmedWTIyTiv4V1ewV2KjraX2P2omZoWWmZ0oNTW0wZ1SENHRM3oLXo0sKZEyiARQbQhSQi28UI
gAbh49Jj1bneQ5k0l9pY9LHR5AJke/Wy1qUnJhqMXfuj5htsZzAsPF4UEq8FTa+4kHGBa6Eegqg7
onIkpKyEOOHl2X1hRUNmW3io50EdjAcQIxrWpZzwujHEiwyWHG2x49Lj89FYx2VhK3IHY5diW0Lc
irHUUSU62zQIkspg7DIFYWUSU2IhI2xTV97aw0Apno6DyuxrASSjwh4KzEzsdDUY4iqAksrZxMgh
zyp66rZCxjIIt94Ec5lNYj9DTjh23ZHUodTjBOXqc2yQW7FnCRlUSyc0KMRIyK6TkhnzTvWOy3Y9
6XAZKqHG7O0xTF7LGjq6wPOrKqbpbomYmyBsR6S0ISZhFSjHwzVEfPDmzK8gV8e7PCIMbWPigo+x
tVtc7mBU42H5mTkdmsY0cBLRhJBJ0gqoUnmc17WjkOijZzLswDSIEyO7ZnUlRdF5zmTOTIzAeyVs
ZGDOCNxeJYJrKQIizCJbPMKzn0C52SSF1KfTNr6yviBrAMgMjuinyWgFZAckFUmLTY/PWMbDOQjh
bkO8qrKJkkjJmEiQoCRcL7dpH+ZadNnf9L2/+9dPvdXXqunX9jEfgJfyHbYF+Mcm/R0/7IyCJy92
6D/QvDV/+LbFPd9jH9hyP7Iyj3IVv9dlm2Je5mh/NQn1etNf+z7qe0vtL3U9jb/vX/b2P+32V23u
GU1O7w4bK0hiTraujIIC2xMTtW6MijTTdTRi7qbtyg4xQ8c1xzipBYWg8UxE1dXyTFaRKJHPLLO+
VZSePaySPTclsd+Ho+vRPr9NU08dXKa9ruaer+tVav31VrXa7zGql42CRjY6tVZHBMbkE0s7ErBL
B6yyx5MOxnpsqjsVIkXjRvdpquq662EmrHd7c3Cte1GtXRV6QWNsUrdO0kejJGbjXbzU3WnYxFNd
pcVwEVmTA+fLhYUrSJ+HARFYz8CrJY8kaQeNg582iDSJpuwzRtHaQVMNObOo4jZLu2jUo7hSF8tB
F0m1xBSwDzE8rCrp5YR5ZERY4HuSwtj5rGKurASjTpUtL6XgiV46ykSLCMbI+TgRRSP3I497XwLU
kVyvnlPsLdnLQVx5SCTZdYztbb2EdXVOeNWzGTc3YWL2QhByRONJZG9IoHxhEOhHQUm6jnnNJrEG
PdmFTYDWMAsFrJXHB2zQT6s0oCQSxDHPigWzF5cgFZoeXlUYS6NuYJyInFLy0uY2MIYbZYoZLK3I
rObGo6zjzoj7S5lBA30IcpS8uS6NuPzFXkVlIk3AWR2aMrS5hg3WBAYN47SkPsYQo5SZawOwnsGR
QEOcMnLzbhckSZy+YCUOIytbjvZW6dHaewmQIqTHui+nUrSeSLjitejujHTjyjc3zDeFtSQCXVjz
eRFmhVNeSTmAFnNPXvsYzOPVnqNYV8EM1TYjqXYjCCvJFeNHM6dWRuXHUnv5bFkjIJ3j+jYqpDKk
G5uIGwyAZJaCusJRnRTRV59mObIwoLcgXng+NHBSl5C+ScFbMPpGHPaFllXNkhikOqZb6KtitxYn
kDNnnrHlRwc0KszmITAsj8anNv47OI8Kqme5md9Dw2diJAcBXzZHw/Q7CaYMSM4YWS0bNNJPCOxi
kSsiVaV5N+QdHLBCYtamb24NVMSjHwxXttVNMqqCR8MkRO7dGgK0SWIx2gsjJXWF0Gbaw1dSVZB2
RlsXllBGHNTucy046Xslc9sID45YySt3lY5IZ2LNvQSoxr2OPcxyI5rm3ly5rmuTVHNVLDRUVOtF
TqVNqsc0ixhlurDoqtb0rkMnMn8kZYcDWIt7YfrOvLm4s6xQ+lcPicV8bHnxEm3Tya2zGpiAQJMz
tbKSzLrIbqEMCsq+csLWTomdtjN0WMYwYRhExLomClLDBEWZk7FmqhbyV7AOyNPBWVRk5Q0Rt+SO
JKPjkbJwTIy0v5a2QBRCOeYOkMitqgny8st3Y9HVqaFFONsXhGWKsfOjZ3bzg68qXmC5WxqkKR8X
fdCx1sAGRxSqQuEO0i4c7eWKKBFtIYuJLG2ObfCOGmRw75YmcThK5skb42QBK0rjEQzzxvYCbII1
gzoWyJPYRwOAFmcs7OAMSTEQU1JnixTMGIWL6tsCKRxSqMqEK0i4U7OVJIAFtIY9+SNkc2+CaLPv
juljbxOG5yTMkjaBlCH/ALRWfRPIncqb6f04YLX1f1ty/OR80WaNF6cPHweJvkcKNkj27CxklDjy
HEcoEyeeOJ5hXBmJ5YVsjmqQRy45E/Bi3pODBNLu7kT1SMq2JdC2edoog44pdjY2BTmvkQSsqq2A
uztC+FHLOoteISQg8M5CxpDDK9jDwebSF7ns4Z9dY1B0L43broyqy3FBsg5O49IyxIXvifHMxqxS
xvdsWOOUPPOBKyA6GGeOSUOeWCIqOEuNjlePLILPASyOZGPdBNFM1FjkY5doK0M/jGkzZFBDDyps
e/LilhBV37eJKMyJvIHkwQauejSt/ihKRC18jf2ZH4CX8h22BfjHJv0dP+yLvdXTW6G/QfBfl2xT
3fYx/Yci+yMo9yFb/XZZtiXuZofzUJ+x1+57Wq+xqncVev2k6/uO9iz5ccZ8MtiO+SWWZ4r3ahUU
CuYkVKrS0Qbm1bM46wVZxBwHnwMfNHSsQsYOLeiVzuWOlK3ZOAM5Gt4oQb3NUhbCJH8HiOiFglWF
HTyxC5UGUMEkvTtpLJvhCzSuEsT3mDS+njOkn4opAUbHavSPfdwZHMY2V2KCmsfGYLjNJCXEvfsK
GqhmERSOd2qLxGub6Y5iap3faydtLFlQck1J2MAGW9VWXAqJGJ2QzSMgQG5lAjqXvDprTiFMScuH
kZZpJuJDAcIocZ6Z+dj2NdlQIqvngt85srEehsOx4nMksKDPnvrYCDKyVHQtZDyavmrMRCoquSyg
n7JsFqflExxdT2SK4HG4MP7IBVTY1koJ6Yr0TeOuzuxxDIgTapwnRlBXX0x/HBsJJC5DFJzapgbY
9ME5P2KDgpAA1LshqNpWFxMPHiKHJjbDX2Nblhs3OBEDCuiKnPa6JZI3m0x0JxeRz9kjCzIskIH4
SZTF0zSlhWA/JhMr4iaTF6SapuR68MAUNtWVZMDFGt2caflxcpiR+KQwU7cZo7K3q8vtkuJDn4nm
/R8JMQFA149V9cGE4wkol3kcDchjBltB1hjuqnKQgcOlJkqoIsCzQ4S2v1qpoS7yO8EoJ6jo2vBK
sKulgjLWe0NIJI3e1qWE9kHJaoLK8mc6iqBaOwyTF7GhyewvIpbrg0cdJJSY6nobqX2VeSyyhxsT
tz7eQyxt3CyOB7EOPRA5LZJjN4GdZGVOJ5RfwtGZi+S1RNiYZS1FgM0kq2PifMO+bnF5tS3Qctvz
NamKD5Swm5uhfRjVF45aLhpgXRTYpcnEyYivbVg3AoY1eO0arvXpYyQcidj7rNz7APDWEw5aYlPh
JdZbejDFSMcixAuWSndDUYuRNQ430xDYvDlbYTvTKJ4oasBVugWzrFa500w2OuxGfM8SunhOoC+k
72WhxzFSxX12Qy20YUNWy4rR4TmQ0RhD3BGCMsRZJVUezxi2o8lceTlF9Z19lW45dW9RdCZHdm2g
ZMl5XjG1dTMIwttafFkR9U4VwXHaiVcghD+yhVMrchgMsbTspTVwUwV/jdka6wt7e1plGjIiqz5x
bFhAfaN3hDo5Za4tsrHFi7CxCJ2WGV6YMEzAG1f+6HGWzNENtksUyzmdC2ObL6H0E/3S9MYSu5nh
fWnPbYNdThnWTsZyivtbyGkAntDeBNRXVGWUHWiNccbGMXbxEywADEmcpHK+ASVzNzbJMtsw86pG
W+cD2mIWlJit6ZlFS+tw+uxvpQnGWUdrZQB2nJ24vJ5BjkwcgcsEhw0EpIEiEl3QuYiW9/2LaWs6
Jo8NKOoMqtG3WXKyjyoptPa+hcc4UuvfbDNyvF56uC2KimuokHQmDBrpaw0lmM5RX2twBRAzWpcA
k1FdUc7wq4NJDTogCLeGaSGvgLMUOGV44sys3dnWgsWX0tLl/ZVEnJQRt5jVxJitZ2N56SUi1Yxo
NzRgWF1WMZDzjK46Lery4HiGygzMr6RlhlwTBYOzAAFamk3aq19fllOuAF3JssrJLTUCJyAz2E8k
txVc8nGJiJMkkGyOJuU45De5LWw3FPCDlllaY/i9dWWAjXNoMVtscylXm5SsZ1hPjJwtrPUSgOJ5
urDJEee8rJ88QOv7GIUdVdxUnZArm9NT2WZBkmPwwg2XIbi7AqnVrOSsij70pG19q6Z1k6tsYqwO
lqs8pSWx5cRXW0U3ZoyOzNsa90EFRBIFNb4/kdWl6+aY4BeyG43H6dK9wSA3IpcJknZEKPEKg6Su
6EkeUgaSBhiMwTFxiJRlcxjJmRmwEDSLDqyMiGWBd2SJzEwtsmQ5wRMMR2OZScKnp8WaMJGNlOPz
FDTRD4aPlMUFTDHIVI6a55iFgiyHkSwsnR+ssufw5K3LskddSTNySXBG4L+23Qa10M7X4PPPyHod
5WKijflbrXmOlE3OmlTEyLMTskni412QBFOyBpfZnFsbkYrFLWEi6ZiFrK3I6GKK1krhJ46qM+lF
YSbyR8IBd0HDjGWvrLO2qK6tv6WxZTV5dxY1Ul3PSTiW8dOAk9geOnRUteX0WAdYDtOjn4PIMOli
xg8gfsjjYNKLkSGtxqszqmyJ98x1WyhksK3G4BM4ErFGS/SJpQgtc8tostnGrH1UslvPYHZ3DbU/
YgqLCojqbS0BaRnI8+VzIhENC+Kuur1sUdVBaVLUMrjlniQkEtnRskXZJWvjz0O7yDJux5YwlAk5
s8OSlLIwaHIpa4lZZ6OAgWRlyMQPA5tjWUg8gnBHx+COJp4UEnZE6WFucUgwOUY3LjsSXE4BaZty
7IznTE4uaUszcmW3nzOYjKCW8o6qfKQ+nVxRVDV2MFzFB/8AxFyU5EwLo4Y7K3yurLxp6ymxsCb0
okXM1bintGNijdM1ZBmSOTHQFyDsgmAmZpWvvY3UnZawo+trnYlk3OwkXGYZLe3U4BNjFVsIkqLu
GmAsGDOBQYwyKeTT2vbVVX+Vetfvr1/siPwEv5DtsC/GOTfo6f8AZF1+OYP0GwPbFPd9jH9hyL7I
yj3IVv8AXZZtiXuZofzUJ+x1+57Wq+xqncVev2k6/uO9i3fu6cSwjdv7m4kqdEVLN/eQQZJ9OHw0
mUm1c1GcHpBixurgNU7uns9z/ZEb3O57Ps67BZDZU5xJOFrYrNNDFSKES0qphmd0pEZIliXEANOw
kPlmbrCO2V0iorE6/wCfrXr69F9jq1VOrVumibe0qJoip36b2q9XV/yE6mqu/wDbNVGpt17qdS9S
Lp9u3iIrdxHyLvSel6M1esiJ2rpGuXRzGL17+icNNXtekjVax2qK9pCtVHK7eZMrHIqb67IZIKM4
to0gkZLoWvJaK97JJxuLosqwSzMidMOx/DmljbxHPVWtaKXOGPMVXum5EqaFkhIayx8AhRSHs4sH
Hi1inWF6ceNXRyK9jnN26v3kI/AS/kO2wL8Y5N+jp/2RdfjmD9BsD2xT3fYx/Ysi+yMo9yFb/XZZ
tiXuZofzUJ+x7XTXddp9/RVTXtVVE7X2NVX+AumqWbVjJ+ubGGRksIJUzJPrKgBRXEQVEMUnpszY
3zOMtOFDDO+SyhhBJCpo2RMLRVj4/wBc1x4vaJEG96LzI0LuKrLCHdiViP4rSIXNSUeZkWVCuuDo
29O3IjmtZTsiYNAQRWjNZHNVcdyNABFgkl4vp/DXiOker3uxqxOe6Q6woak4x72RxveUYDASQ50c
LY4o1WWR/aRxsjZ3rGNaiJtkUhpIw0K9jWgnXmJoI9Ra/IMtfYk7ksrU5UBhg3PTujWGDnBeM/SR
GrgeZ3dVU5JWVuH4OBODaOamRYQXzMb4sjxiV8JcbrM7pISU4QR1FYmOrRH11lZmLW1S1tvJQUVW
2x7LfZIBFyOoni9Ft2VJJmzIqnIAJqWu4dCPChZD+DdXhI5gNM7o4IdCDAsjdNQUZ0EPY8xdCMjL
czp/AhiMky6IjLMdiZXkTTS0kcr7o6Ma3pJ3RhDuiU2REY2/kBmx19HiuRYvjh9cYKU+/vJcgFx6
dbMW2Ht4wapq+iODowGWjtOkWV0yMKDjJiUaIiCfF4Ky2zDJsGrquWrs5r2sOo+nB4ro0tmQQD20
PHopLAyhgrKeWGqKRzb3fEdKTZm5BaR3B5nYyuSudQcuCd0MuNkOjafKbaW0x56LvqTYcUdpKuRW
hQaLvdiRt9Q4xW17cugdCTUZba3hkk6YPlfCjlAMwrHoYonx8R8krbKZ8b2sjbDK2RZYxoS4quOX
L+wt2RMjtooGEMkFNq6ipijjDbIZK6ATiWxkc7SUJl34YmtmYscqSTUF3LQGNixfHsiBIoID4WhD
W0lgKysPkMMNZYyN6P4olxA2qbZRoQ/oUBImo/7PI/AS/kO2wL8Y5N+jp/2RdyIn7sj/AKEYMn/w
7Yp7vsZ/sORfZGV/cw0Bf5CMr02xP3NUf5sF/Y9aa/cXufybdz5f5f5vvdW3s/yr7H8f3f8AV7Sa
Vl813L1RchkuXhMMlHkOkjBhhqpK2Jgcscb5Z416Xc4gZZIvToF5x8kjooIGJHDBGyGKNvesjjaj
GMT7jWoiJ97YXp+gprzkZFmC6XrArLkpnbu9MJzkM3LSu3GayQ7j13Gar2rdArs/HaM26rUibXW5
dSATZgNgkklgaEfNA8oVIZZpZIkglYkckj3s0c5V2LvK/GqEC6P46nXANQAJaGKTIkpDirAeCMsh
00qJLK+WVznydu5Vd17EEPCFfOWNGEXO6CN0xQULyZIQyJVbvzCRPNMdGNIroY1LJ3WJx5d6ssWY
vjzLCkFiApTm01chlODA2VsIVWSg/GrxImzzNjGEfDCxJpd1icR+pGRD0NLBkBcXALvYqsKO5Jg3
YmcEizbAhs0W6PA3hyTuZuwxJppGzQypCoqYSqsXFvsKwWsCHrznnt3DnmBxQNHJcaztC3TRvUhv
azb6bBrMGLMtfMhNeso8UnIkNglFbOHvMXlpkGInHSWHcekE8sWvDke1TyBsRxgee1YdHaTQ0NVF
LZR2enSUZ8jBWvMZYbreeaQsiF6Jx0k02JjoaSopGGkKWYyorQ61pZTk0cSS0OGFJyHJ1LNLvSKn
Urv3gI/AS/kO2wL8Y5N+jp/2RkG8mulyJ/PhmHfJtivu9xn+w5Ft4Cb+bbTgEdxHd6ido/cfEvX7
L4nq5yfavjczq2njGqbIxRpGRTcJ9TBuOcNGT/8AL7QT7SZm3ret/hWOefdvW9b/AArHPPu3ret/
hWOefdvW9b/Csc8+7et63+FY55929b1v8Kxzz7t63rf4Vjnn3ZP8HblFX25seT/o9o29kenEd6Un
3fu7et6401TuzUDepVk1k3lutzhdo3hu7s/ETh67et63+FY55929b1v8Kxzz7t63rf4Vjnn3b1vW
/wAKxzz7t63rf4Vjnn3b1vW/wrHPPu3ret/hWOefdvW9cfCsb8+7JMwclqLJPE9HI30p0EksT/v9
vC/bwE3822nBn61062I3RftGOavbxyyew2Tq9pdsqenVrh4Kafc5nK9sT9zVH+bBf3zI/AS/kO2w
L8Y5N+jp/wBkZF+OQ/0NxHbFPd9jP9hyLaxkx4QA68YJJ0YLYlLAJKeiokbCZI2Mc3r10gR6QEuT
lZbapiXphKpLkkku0dGTNYklsZHPKWXYGkzO4ETI4I2rK93DhiiZDBHpDBHHC1saXSey61g00crf
3DqU9jT2Nu4vvl+XbuL75fl27i++X5du4vvl+XbuL75fl27i++X5du4vvl+XYwYKQ4ad5FLuS15M
4hDWRXAs0m6QLJFO3WNSEcrZEVWvVNdETSMqYy4eMlr2QCViItzZB+DKVX9GM4D5HQ8EceF7a+Lc
4QOquDZC5VXbuL75fl27i++X5du4vvl+XbuL75fl27i++X5du4vvl+XbuL75fl2d1L1f8tfl2c7+
HY3a9fX+7Ryf6pHfy/cTRv3dqL0UyoVYOAA+un7yHTQImkL7Hf7+eH7aV6LNJ3ZXvVV2yn3Ig/2j
Mv8A9Df5Pv7Yn7mqP82C/vmR+Al/IdtgX4xyb9HT/sjIvxyH+huI7Y6WRJwoBM1oS55dySTchFrM
lnlduRMfI7SON3Uxqr97u7L+3WuqOautfeL1P6n92sXvk7V38Jvar1dW3jn7vi67/hOf/wCa/wCE
9y/x+1psQQPkkULCJUnkZLRX5W5K2CIdHfW3L/8AAwRM013e13tN5XKvrqE+LWTf3u3rqE+LWTf3
u3rqE+LWTf3u3rqE+LWTf3u3rqE+LWTf3u3rqE+LWTf3u3rqE+LWTf3u3VlYqd6vrbyf7VdW/wDC
+wu2noug7mnreyj2tP8Ay3sp3f4Xs67euoT4tZN/e7euoT4tZN/e7euoT4tZN/e7euoT4tZN/e7e
uoT4tZN/e7euoT4tZN/e7euoT4tZN/e7eukTr/8AZrJv73ZgzryOZWSTyukStvI96QmZxEy6dGad
vM9z9E6m67rURqIm3jdOr/m67817eN06/wDm660+9p0X3vtN71PYTbIuRtQXcxjYgMCkyvA4pjyM
i3Iv2wiE8F0iNqqd3mF3td1ulLVkXFQ4isqasAl0VrW8J0g4McLnQK4vVycSNO7/ABbeN6vyrV/O
9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n+3jar8r0/wA/28bVflen+f7e
NqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n+3jar8r0/wA/28bV
flen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n+3jar8r0
/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBvG1X5Xp/n
+3jar8r0/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/K9P8/wBv
G1X5Xp/n+3jar8r0/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/bxtV+V6f5/t42q/
K9P8/wBvG1X5Xp/n+3jar8r0/wA/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+0rEt6rV8b2Jrb1Gmr
mqia/X/c2xi0huqNRaYm7ILVbiuY9UNrJgB2QNeQnEe6UjiL1tjbDFIqv31ijl8bVflen+f7eNqv
yvT/AD/bxtV+V6f5/t42q/K9P8/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/AG8bVfle
n+f7eNqvyvT/AD/bxtV+V6f5/t42q/K9P8/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+3jar8r0/z/
AG8bVflen+f7eNqvyvT/AD/bxtV+V6f5/t42q/K9P8/28bVflen+f7eNqvyvT/P9vG1X5Xp/n+2Q
yjTwkwrdjNbMPNHPC5Y8RxOOTclic+N+5IxzHbrl0c1U7qbUCp1aX0vc9xWa7eFk9+75dvCye/d8
u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28
LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZP
fu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793
y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xb
wsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk
9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3
fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75d
vCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7Qemy9b+vt3dfpBK9fX7aIv30RfY28LJ793y
7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbw
snv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xaf02Xqf1du7q9IGXq6/bVV++qr7O3
hZPfu+Xbwsnv3fLt4WT37vl28LJ793y7eFk9+75dvCye/d8u3hZPfu+Xbwsnv3fLt4WT37vl2mVJ
ZUVIpFRUkdqi7q/d2ybX2bwbX4n4jtQ/j+X9C81/9CR/wn/4cr7BI/Cf/hxf8VN+Ck/IXbJfx4L+
h2I7V1hM0p4gFzxSnDAmWE8MXoUzANXoDWwkHy6llixKvJ/b6beEvPiZm3mHbwl58TM28w7d/efE
zN/MO3fXfxMzbzDt3958TM28w7d/efEzNvMO3f3nxMzbzFt3138TM28w7d9d/EzNvMO3fXvxMzfz
Dt3b34l5t5h2/dz4mZt5h2/dz4mZt5h2/d74mZv5h2768+KGY/R7bvr34oZh9Htu7efE/Mfo9t3b
z4n5j9Htu7efFDMPo9t+7vxQzD6P7fu78UMw+j+37u/FDMPo/t3b34oZh9H9u7e/FDMPo/t3b34o
Zh9H9v3c+J+YfR/b93vihmH0e2/d74oZh9Htv3e+KGYfR7b93vihmH0e2/d74oZh9H9v3e+KGYfR
/b93vihmP0f2/d74oZj9H9u5ffE/MPo/t3L74oZh9H9u5ffE/MPo/t3L74n5h9H9u5ffFDMPo/t+
7nxPzL6P7dy8+KOZfR/buXfxRzL6P7fu98UMw+j+37vfFDMfo9t+73xQzH6Pbfu98UMx+j237vfE
/MPo9t+73xQzH6Pbd29+KGYfR/bu3vxQzD6P7fu78UMw+j+37u/FDMPo/t+7vxQzD6P7d28+J+Y/
R7bu3nxPzH6Pbd9e/FDMPo9t3158UMx+j237vfEzN/MO37vfEzN/MO37u/EzN/MO37ufEzNvMO37
ufEzNvMO37u/EzN/MO37u/EzN/MO37ufEzNvMO37ufEzNvMO3fXvxMzbzFt3178TM28xbd9efEzN
vMO3pkl6z7+GZt9F9vVF58SM9+jO3h7z4k559GtmOQi87STf9Y2edzRU09bPtKqe1oq+3t6ovfiX
m/0W28Pe/EvNvovt4W/+JWbfRfbwl/8AErNvovt4TIPiVm30X28LdfEzNvMW3hbv4mZr5i28JefE
zNvMW3f3nxMzbzFt1OvPiZm3mLbvrz4mZt5h27t78TM38w7d9e/FDMPo9t3bz4n5j9Htu7efFDMP
o9t3b34n5j9Htpnft520u/6z8w7miJp63vaaifeRPaTb93PifmH0e27t58UMw+j23bPvE/8AczNv
MO3hLz4mZv8ARzbwt58TM3+jm3avvF/9zM2+ju3apeL/AO5+Zf8Abj+3e3nxQzHzBt3t58UMx8wb
SMRt3q5jmpriOY6auaqf+YNroxsZMY5tvHMLzYZYE0sMON43Xvl5Q+AYuNnNhFRNWWCPicJXs3o3
Nc7iZABbiG8ThPfjw1ZY1phHd4sY9nbUZVQ7Xr6PY+xC16+d27uZeQMe+mG3e5j5DoPpht3uY+Q6
D6Ybd7mXkOh+mG3e5l5DoPpht4PMfIVB9MNvB5j5DoPpht3mY+Q6D6YbeAzHyJj/ANMdvAZj5Ex/
6YbeAzHyJj/0x28DmXkWg+mO3qfMPImP/THb1PmHkTH/AKY7eAzHyLQfTDbwGY+RaD6Ybep8x8i0
H0x29S5l5HoPpjt6lzLyPQfTHb1LmPkeg+mO3qTMPI9B9MNvUeYeR8f+mG3qPMfI+P8A0x29R5j5
Hx/6Y7eo8x8j4/8ATHb1FmfknG/pdt6kzLyRQfTHb1FmfknG/pdt6izPyTjf0t28X5n5Lxr6XbeL
8y8lY19LtvF2ZeSsb+lu3i/MvJeN/S3bxfmfkrG/pdt4uzLyXjX0u28XZl5Lxr6XbeL8z8l439Lt
vF+Z+S8b+l23i7MvJeNfS7bxfmfkvG/pdt4uzLyXjf0t28XZl5Lxv6W7eocy8k439LdvUOZ+Sca+
lu3qLM/JON/S3b1FmnknG/pbt6kzHyPQfTHb1HmPkeg+mO3qTMfI+P8A0x29R5j5HoPpjt6jzDyP
j/0w29S5j5HoPpjt6lzHyPQfTDb1LmPkag+mO3qfMfIuP/TDbwGY+RaD6YbeAzHyLQfTHb1PmHkT
H/pjt6nzDyJj/wBMdvAZj5EoPpjt6nzDyJj/ANMdvU+YeRMf+mO3gMx8iUH0x28BmPkSg+mO3gMy
8i0H0x28BmHkSg+mG3gMx8iY/wDTHbwOZeRaD6Y7dUeYp/8AYdB9MdpI3F5nG5jtx2mLUK6L9z/D
3bVT8z+96FKHT9PdvVuY/FWh+nu3qzMdPcpQfTzZdwjMl3f/AGYx9P8A8+7eqcy+LFF9PNl9OzFd
3/2Yofp5t2i5o7/3dx1P/wA9bd9mOnucoPpztvb2afF7Hvpzt1+jNV9z2O/TnZd30adr7ePY99Od
u+zPyBj/ANL9v/HHyDQ/TDbTczHX8RUH0w28FmPkSg+mO3gcy8i0P0x28BmPkWg+mO3qfMfImP8A
0x29S5j5GoPpjt6lzHyNQfTHb1LmXkeg+mW3UPmPkSg+mO3e5in/ANh0H0w27mZ/F/Hvptt/45/F
/HvpttuxwZnM/vt3oPHWdSd3rdmmmyN6IzNdP+bcaT/84Lt4nzPydjX0v28T5n5Oxr6XbeJ8y8nY
19L9uFitDaLZS7zGFZElWICA5U9LK5autbeayWNy73JucBG/TtitPS3f/8QAKxABAAICAQIDCAMB
AQAAAAAAAQARITFBEFFhcYEgMEBQkdHw8aGxweFg/9oACAEBAAE/IWaLld1VkU9MpGWogqm3KhkX
Kq3PwbBH/WEZUtUiGQBgUGl90lXLpctSpkwASoNet1jQTAY60fV+1mzfrHsJoXzaSNf6Ye1WrVhL
kBAo0SVKmnz5wQPPnz58+bM0aNGjTps2NPiVpQkSJEiRIkSJEkU6DX5y9LJlUKrcrw2be+l95N+/
T7yb30pt36UGrkE7g2Ofhgl3wgZdQL/67NDbK8xk47cjL9IMCvQlrQAMnlL1VkxFQJvG4ut2ydv7
b9AYljAzraxpQQJRTNj6MyAFSg3m5ufaPbkBuMXzO6EVhAjn/dNxImTeE0/qTZVGdwukSXozemOR
BqV0awu2DMJhFCuHVRptJbdgsp7jPYVfJYE1W+rk+VMFqg6JJHgJxy1dvJCy2Tcwc7rdkohYOm4M
Y8ZjAp1BMM7AoiUECiiG1j1lXi7HSKOA0qg1qaCMjVq/wGMMj0yBEB1Fp44m/GqWVs2ufjgbioHB
Wy4BGkjYpiEph9B8MLnhculb2RGFObGIVCEFGcDEFUsdrqtw4ipBqWtuT58tkqEN3nixH26KVoMV
LZAD/s4ig2qGqxXlXQr2ngH8exR2PpKOx9J4D6HsV0CUdKlSpR1plMplSpUp6K6V4SvCU9FEo9tU
p6KZT1K6j4wihwfSDF7v16FHLPFgfj0QS3l+scxJguxPEZpz6UQqslQBmHAq3johCgRExNGdeDnm
KquBKFEcXuttFFhRfO/MFEs8KbICqo0tbTg7mEN25O7T6ryxvLaKuFQQ1gcL8ph4ZXOWV4CX3OjA
qBeBQrC7HI09OfCg9NluLZ/m7VHMNk6iBWUEXJiLOWx2mw17bijG75U1GLxaC5YVTNIkL58FxhJX
ezKLXNiF6gG9TR2UTwLCFh31dTk7Ou2i8yzCUGNmveBEY6NPeyYlLEaQVlyDhLMdjwUzZlLZ6JIQ
LuCm0hcF5ZetvJ15n2Azq2JNY73pwgpiUibyYKm7XaLNtvUt6F0lWd5HWZtQCXF0E95bguQTOgzh
QFCLC8hbOu6gK17U1Q28EBiCwAHi/MgpscUvE1uyn5+/dqlSvcUyutSutMr2lMplMplSpR1r2BUq
VKJUo6NcfxLe79ZrqeJKNMoniv1YHeB36c9rRFFoeRVyn88dwqjpsAPDkzPvuY+cnn6Y5nJ32pTG
PaW1m5873RMDlBMDmJg9zHNtCCrwC5fLzEqWrVnXP6H+oDB0QlCr8HywE0+c7/adstsMTJE21IQX
C965acO2woGrreLwqamGFKuLWP8APDm4NrgBoZVgvRgxKOHGv0QehPxVcIDHmMCmAVR2UrG7Di8n
nmbzEqN9VvhTmoWtT7XA/wCeq7ortqurx2/sD3cuYtlZVt5XZ4v+JKiip4w+D/HsKIAlpAq7FmNv
Zm23U5DC5IqUXQw3I2Y8AbAbLs5NlacW3uXblpbM9zl4muI4wgVJtTyLErTz0t22fwHPjuVeK883
oHh+hLPJed3v8X+ReImq4wK1oc/rDkjyi3aX9fdBon23IGRYsX+ll+on+on+o68uX+sh+kl+kh+k
h+ul+ml+nl+rj+jj+ql+oh+ij+uj+uj+uj+uj+q940g0880082/+/pPdtttvOeaCBBH6zqEEfuZf
vumTqj0SXZgjf/D7xup7f9IkWrFXdgt+Z01ve+v/ALzaKV3bX585filguWheHDOMGMdGQUgB7TX4
P3iI06zZyVpU8huEJ7HSk7VYzxv6L8ZmgdwA4A0waFkQAryfUcXWLQEkq4x82dsGpYSRonCtUuwu
lhZnI2XavfDFa2VuCMUytRcFCxhuKjLd7TinT04cAwwFaVSaLxBp7tqqZsmdx7lBW7wCWSSbol35
kkLoTfYXg/njcxlHaCP7calNwK525bS4NiMoYMDQcwOLJUAjQjcmqgPrqymf85r/AGVLZSEGih2B
aXINhlyJmhecDB5mWXa9khzV/IFutEBRxsCJoJx6d4LjDnk3znHj7BjwY/ee0GDFixY/7Rn1o/v5
qYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDBgwYMGDHz4YMIkVm3+BBj58+fDkCN
kMGDBgwYMCCAZLHtpvJN9Lqs8/ZIFMDJAW49K84UGOC8yWpmFFtNCrxoucD0o6h4Ky9a+TS1occF
6LbSlgUulOAYpWEABCTUWcs9IcklLdX/AEB97LWBCYslPhcpWkfSSVJ68S8sjBGmdLlC+1bHpyhi
NOsc7C0FwpZdO4u/XuGRyAkrAhdNSO5XksT6kRgpix/aml6sZKp6NJbfc3M+T8K/7Ayu4Eb07G4R
UL500pno+8bDDwvzgEXDU+kJ1VFQDBOWn0VRJNmjYsy5HqOaJ+Ff9n4V/wBn4V/2fhX/AGfhX/Z+
Ff8AZ+Ff9n4V/wBn4V/2G9eg/wC/+HdXCaizX4otBTLDHfGpn200mjVsnAQFRHIIaqd0KhGkEmnV
6ZBSeCUy28mJNpKd15PFopZ2bRbg1Id3mRIhMjpZtEeIEZpvuYrag1LoWGD+rYViJVKQjU7Z3cmt
gBYBXurZACyITug2XCRgIu5ufhsMC1tKTKxSd09Ft62QWMSiJoF3ixlfUJQKTQ4SghLTbCYLMvff
oNiwWMqRnaLMpAQjYFyKuNFKYQG3EJROAga5KEy5gFzCyx1QRLZIVcf0IAXwwHWVa8wsQ9uQFwVF
D2VzALGCa4KJeZXZE3YlPKszAvBLxAed6vGiEhsFOXINaF9UdEqeHGbKRBV2ivoPtcEtptyrwNNb
S71RmpU2Joavyo2WP6OtPYcOHCvP1/5Qn/hnbt27du3bt27du3bt27du3bt27du3bt27du3bt27d
u3bt27du3bt27du3bt27du3bt27du3bt27du3bt3VVBBuYLBoo1wqIi/VMv7j9G4w+oip3IoZEqv
DP8ADKWhxIRSsBHBWh4gwgfUwcypDFqcFraaPFIyu/LvW+MmOWJ/zJsBITMIg837CHUcGYtW3KAq
ibE3xoi2NBBKmoHjMnnhIK0KP4dqQpbFjN7BWJsXzaWH21DFjDIdQlK216xphY1Wpp/ZWNj3Uwqd
/Ppoqjei5luM9ccoXCFymjemRS5mdhyKh6aggTDZloj6mDLVU2Bh+IGi84GNvkaJcgVtf0TMzVLm
+MWb+ZOWXKziU+4uNRu4tu9lwWA8Zsa1kedIQ8wgpLqHeBS0KY3YEYkFbXawD3rhPxzMyfdyanm3
SVY0wjYPlIWllPDuPyE/IT8hPI+ktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0
tLS0tLS0tLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbtLdpbt0C
0FzITZbBps744IO7sRfG4QAx2cotkFm6kcueM9w4WWgeEv0ITDgBU2VOeNRj1MhCoFcGupBylcyZ
7n8P0iOiQ4a10tGuDYIKeRo3A3b1NxDEbBLb1eKLXjsc75uHGLl3Euos+70CoivrC+opsTWzAHo1
UrBvQVubJNVSNCr83fFHxTGbm45W36WQiM7Sh+kA+xE5simAG33wH1/jioAJsU7txwRIjPXYQgN8
wYxAgx60K1hi1Hbqa41lMmJlJ0tcMrDKgb4v677h1ImCxe5Iqdz8zQIyK4Mdqh1l6FyxY/1YmyjS
RrdxfhLIfPtTEcO1N51AqiKkhfyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyz
yzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyzyyn7vvKfu+8p+77yn7vvKfu+8p+77yn7vv
Kfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p+77yn7vvKfu+8p
+77yn7vvKfu+8AMwYN/Uggcihu7WhWgeJo46EIcOHJmM5z5tq0OvwG5DQA4oFPLMAjgEyO2K5W7s
A00NlYLFhJyw4/oQqgAEMu2uuVs8jkvBXinnzbrb2iwYKLfWxLlou9nLZOJCxo5MCctwGtlOY+s1
QphdKy5Kpi7nkdiE2BWCocWLjCtqsbUu1TGw/k1pekrpMVcxsJaLSiz3LEO2fGGiR2jCUNELmVRI
XKKP2jgQinPhvNBm6JOMzGok7T1caLQAADKOFcqFB6lOcrM0WxvY2zfRgNxCPjHj5c0wHguKcAyG
MBCqgBxVESaAlVYd40IsATCjKCpA5BgZLVGvgKOPL+Z/uwYAoHJpYmFXk3WijH/i1y5cuXLly5cu
XLly5cuXLly5cuXLly5cuXLly5cuXLly5cuXLly5cuXLq1atWrVq1atWrVq1atWrVq1atWrVq1ZJ
OR+BQqUvaLzMRas0/nN5utHsEPcNJlgit2BgiJOPpbbH713DZBHFmoDNmCFKWQ0LVcs923oh0QPA
KLTkB3GyK+DqBmwozKI5z4/4Bd9qOWqlFSBO1lq7UhizCptN4y7/ACRPDrly6V21Veqn09w6dOnT
p06HKMrDxCF8lDw6ZewbU92Bh5hfjB0dSwkPdsNNEfvmnxD1Oi1LZl62FMM8Ji1QAnSCh2a/3WhF
TLtVKXIhGlOYzTwEzzXQcTYm4lYy1OzaQEis3OlPCcFuQcm1KDgqpVtGJgLnw0BQTwcvPAA5ESeZ
6SAYpSq1Hj7RmzZs2d2vrf8AXyPMmTJkyZMmTJkyZMmTJkyZMmTJkyZMmTJkyZMmTBQnvOZIMVRg
axDLUd7B2mWCCT4ggoUKFChQoUKFChQoUKFChQoUKFCg1D7qULJumA4A0b0Zef4QP5QhUABMK6mo
7j2Manq6G5yar0r8I6ERWAUO1dBlgy2AnkHr0qJH5Mb2DKnkPVqtSFZRJypph2dGR47pBVHy6oNH
6gcpEbiJrcpE+TA2RuejhjCDuVXTcRe22OEuEmCCVSwJ35QPPqKeW/27OMD80l3Y7P2+tGBT6OwY
ULSxc69GvVCCRtwVOdZ14f8AXszXCyz2Mr2uYFQE9R6dr8YBVlpRpxsS1ep0NMwiPIrShkXL4nz0
JwVZiJ8HRmRd1iWuPa1K+7f3z0cIsTCKEuYRAb3ZSVjWMwgPbRJrRYJqMQu9MCTXug/ZcJRiJdNA
ebjLeAmWSdmCw8lfSz0HSnMk29JLQULOO+aEqKyhYyNRFjkZVw6kmYSOylZl7CktC2kCqKGFEQNY
rWEZrz+r95Xn9X7yvP6v3lef1fvK8/q/eV+W/JYwyiKbr0oQy+ygjRwFncJMc5MqrNr4LbfoZDbt
kZnJomYXeaFg6kqhhklZG6GYPeVeY9ed+CE0Eewm+29xAl003eHLdVFgG9AFv8Ba+OAyWFta3a57
Dl8RCwlIigheN2WAXLNEgAr22mDnSpjlwRTHpUVZLsZte6Eld8mtFaSlokc3uJEXuH1BAdLFVthT
tDF55xDZcYKhtoLcOWjeVVHQUoFsGsycOmGKnhTFP5EkYc4CMwM3W0wDNABqWCBKNTaUJZOQ/S5f
QWIpNOq7yuCqjQb6IfjqnrmV97+PyI33q2rxm0ZKFk02FncV2W9OkTGDPxPWTPpAxK+Re+KXwBFX
1V0NCyVRawpIEHk6RIuaaFApQ7kbM/as98MsZIUZaRbxqRizuWYPKyFMoBZVDsQMU0bYoVS05M2X
fXmRAPCOa3L8lzZiuI0J0yqRHXeUdFE02PFaZYI5uVhkEJDUpZXQU0lyOqgxE+TqV8E3jGKxgqjr
WKV2zW27/ohfTn5NG7VZJrM/9KLYE5DzvPCitObhooFCupKJ5t7gjMTgMofulU82yqoThhh6xmt4
K90v5JliJVsI3wD7PgrW3lK9evXr169evXr169evXr2nyY1h50qPDkphxVmygq4LcEXksmZQ+1IJ
6KURlQGV2QOjvioqrOViLCPNfOFUFpBxn+JKhwU/fsxYIMwPT693utGtjKK+iUbS2jg0jRYAIU3S
0eOpNx064bpF7SwlFOJd3MxWGM4pHrvYIoNSVqw01iTTWV4JsZuAJTKffwmGfRehxjTdWvGUdqsy
F9IaVE2feUg40Weo/TJ/M2Frnbc5QNwRGsylE2cTh1WEI2d05EKB1ZUSgBIjFMnabKAmiipnw1tL
sQiwRXhELSrRFYHrjCo4ZgUcpx4Vi12t/l55kKF4AKYO3hislMjNN38JQwwp2M8I+t1G2OQj0hIj
PWgu/wAKVx1Mt4onFrbHq5fuTEJlwM3BwUHqumPPKkPDOtYFaXzLF7l8ijdsi9NwhNC0WFPiO3bt
27du3bt27du3bt27du3bt27eCv7z+qi+9HaJd7fpo/5NcYGl1BtKkbU7gXUFbg/QyIkE9cFAsQZR
qG4Npgyh8Co/SHlA6TMS/Of5bIN0IUletaiVOKtg8Ad9IATqee8BkrsnsCaR464VPGiR86MZoMg/
9T++QNfoGD++7k5Q1qCy0tFRr3m9U3YS+euD3jGflLJFyNbHPdevQuIvSzngCx3RNS+8DjdKOy+z
IOqC0JLE5FNoVCKcYAEh1aAM89CckTSMayVwG3gGyYtg/nDjhVuCRSuTMeAX6lH96M76Z/x1zwd/
Op4aEmrus1zGEGmfzGfaFoZyEKYwDywmefKrxEJCkyjk+M2d1w08haaa18M3/wCMk30FLQsTAvKj
oLZZvba8sI4Ea/J5Fvqcxo6/IoXGV9sy+Cv+S/8AMQL0OQCz49gM9PgF4Gj73auGq7U/J70K5eIA
V+RSapEqj6bnC0kb6dauDIE5qmzIE1m3xvGdZ0Gbgm0AwHVj9AESuaAB0rcfBSqOESnAnVFs4s6K
SlhZAjLz85iFQ7mVB+U3ZabVVuU7yneU7yneU7yneU7yneU7ztyo1vyTdMqxC6oW2GUeJ6Ij9b7s
QGjk7d8G+54OJS7zx2MFcqFOqq6dgwTJ3LzdOy900WXWIHWiZ0xGDN4QKXhLqpHA2L2ojFVBYJb6
Mp0gJ/iukya0SYZ2Zx8JaODXTaBZshMj20hOa+SlOYzp2T72pIVbtGPHXrQx9NiP0y11gCI6FCZF
cxwrTUj4xbBSUcj6EAuaSm3idT3S4/wcyH3VdrYrbS8UGd0wjpRc01YG6eQumjn4hFvvdA40taJh
c7QxWDRgokGBJBtVW20wckjdoFuNnxfOAGF7ZEqCvEutashJjejSxqUOQtpYnrk7jtK8RMjDtlKS
Ig8AM5nHJ2XmFwYaFMYCqUw01Wg7qgtMN5npwTtB51LkrDs5YDC46euqdabLPN5rIdluYZrTQxPM
AoURbFFLtU5LVbdrdav6W/JIzntKr82fkZvgwc4NCClHXYFODJNPHMSW5mQlL8fylo2vu/lZKeXx
TnB2FvQjOs5v13+Xo0shT2oz8H0UWktOiWIK9zBy3yHT28w0HdoFiVyMFpt5b2GqyBnLThcz8jSq
lk02mLBBLrvXIChiZcqyq73ZzPG/qeN/Ur3n4XPwufhc/C5+Fz8Ln4XPwvpMbcasGuS4HuW2eOdz
l5/4dQG2BhUhZp3Lb3H76av7M0d+dzSOjiOsCzmRA7hA+utzWa7sNrxgb1+xygsEhDEYp7jyw9TN
Rx0xeF2GaabF9zxZfoBK8jLrh5NJp2ZAkaSS7aJA4sDDYo/7d9ILKCf78GzPj1gHPfA7k3A4Pt69
05Q+rHXs4HxITZSSS2cLd33XeuQONM+8bQCyRI+Qb4sdHbogwZQzHPDW5tVolwRqkd8OGAETXNPl
7vN8QJjUqsN0rPB0Atd5kb/Ngms06cOuQ34rHnHiaz/oEo6DhKpJozUGxuCG9cZatUVvhTJYtDdU
14hquZ31v+Tcp+/EWlcaX9HMz9Ggx42PxsYUiUGja9pqOARQXu33QVRVEXCq9gADtRbfd0RYVPFG
xHx6cb6qsOYra16+JQGrtksbasMJvs3YXE1AtVYdnuDdt7S4SWFnXjtxWgWKNjOl0Wgp42V0BfLW
iTx5H46PxsfjPcsgggggggixVdfR1eUy4LePtXf5+YnLz/w6mzV4BsWZschTSFWSQKO4J2lVTByt
KAIlyv1W1fR3Itl0JGO9CInuiQnAbxVTVScZXDXhANIDrag8NGqoB0dZcBtlhKy3BxASUOqhVI2b
3WQr38D3DjRvqpatg3RGrhEFlrktYAVRTMLVwbab/m2/VvNW1euJu2WDx48vU40ynrGBrS0+LKBN
HKY+UOFgW1eYZhqb53yaQCoGmCVolomX0x7G2zKczLnfLXfIjexU53HzQxccoaFWGgqbxFRQEWoX
kKQbEcCyJVTAwyCiIdi14A2swqsfKGgp0x3xYv3jYfKzwbowLyGIsTHhMlJTVkGmm45VICMnutR3
8il7AUJ7b9wWgFCBONEv2KeS0J6njMP8pPMyMG6xpbs9zpOKCW4NPykqDUXkP2mvlD+D3M2O9CwX
e4OKdO/zu81GX6uF/o/MQ2eJb50dVIGhrThaidxou/nofe5bZu6r4A/YjWK3K1w3A0rJBkaI3YUz
gXJaIT0xn1PKTuyZvxfcj0ZyxDWOUFsJIUPBUaJqqwAYrIvSSaQiFClR0yvQD8RCEKBBFqnn6lbS
t8CZ5hUf2X6VdOmBLH0Kxe6rCGQQ3Z1p0we78IONLMLsiSZrjArKdGYU3CCu17DQCEM0GnUp4NhQ
Jh7dlr9gZSy32ZlSW0xpJW7FEJ/2NbirXNOYCDH++nxcJpmX+p2hLs57twoIaLcscoTuzq1Zmo+g
W7Z9U+WASGqpYCsctPIq4GC235lqlJiFmtAgA5Yj8lfGP0T0f7q/41j2D7DKVB0FpaWbxQsC/wDS
HvAawNo6YTsm+lMvlQbLx/Dc0ESDAzm2Tsez5kRTlORh555OCQReqMm7Rzhd6RJSf5olunQU4Zdp
4om2KyncS/rcuUQTfciB3lQme2BCsah0Be7wb5rT5eEPABdJVzPweB18EqhrNceArc1R6IOIVaE7
vr4UhMVHZJeiONgk2Chyag6n5KtUY4NDstTdN1+KlcFVURoYUWrF6BsIVUL+Dhxpbhza8KQjt9EM
I1LUe2sDS1hUMIdlLFH22icCInL7OGJnBiVxQDdeqoN0MltoLUKwTVW8qIIAXRXmJMJLA0pizkms
ob0RrC0zYHFvn5o4UxVUYNPAkHGICWyop7DShmIK0KAUGFM5mCFNbMNFW5iFt+My/XHRxAtQG4dr
XqlKtCAoL3arBcF+MWjAF8lUdRMsZLF87jWBxRq7GwY+aUcqnDOIWz0DkweSPQmdX1BX7X9N3Boi
XqATgaGxce1jARtBjQ4rAHT70HU2+ZTQM72JSQSK1kdCNB9aD0ZH2KO1K8sJR2cp+owLLB93cffI
B3rQ1JVN+DTI4wgoPLskAvDtoEkyoI83+nECjWZiGIxGIgt3B+lXDPSHjOJSBsQCl72nDCVQmrUk
UD3SnCYLsw43LZmmMu/GhoEiXkPUJjfoKx436PvU93nSCITHbBkENMMHMRgrKt/6UgLN6z0ZW4BZ
LzmjDkZ6KMQg7SekPlQvdYK6HaISabmGSb/6x8QoMIIuwK7KH+1NjAY+S0WF9kVLjacZBRqmMWuz
Ab+1e9GKcWkiZymLYuVgtY69NSuSon1ZFWJZwz51eNuh2NYH/gtLDcgtTSuyEJdRfC5R+bBW1lua
PN1UuXHgAHDnRFOtXpQoI2KoFLFAw75g2Go0Vuv9uLr0ucmRuzqqs564vGwKD4Wh299lyZvoArEN
v/XAazzIKDTDRojmC6eMxZKGipagYiGJUwXDLxDphBAOOc9iQRFspE8BQFYRAarlQngf6kCvQUxx
QeDruSZUsKGFO70xl5dcjoq0r3IcbleQ4XSQWGEUymx7Ss1IJ14Gzb4AF84kaNwEyHMm35EJw9Ec
5AYb947TFq0qXwXd7DaNae4p0SIrfOwEYAQopeUUyVjEMllJvmJENggAv5CyQDNAbnEOYmhgXcVB
hocUABAqJJmI6mcIPDzEo/lMzl2fNRGPZabNswqIpNOq7yuCqjQaB1Y16uaokT86pjWPoGPBqs8a
x5T6wfRB/hlBus1XWsItK9PELcRKROCvkCpydlWk2S9IpqCuJq3InIABfjKVkZHBvFPKI+iRHbe+
FmSo2bwK6Gl6i1hAA2hd2DsHsNklpLm8RUtNjUVMEmKx+IE4V0wJGkNYUWh0bS4uzEvKq0Smua4i
J57ixRTKpeIIWVGXk7kxcgh6Yl24Or4bTeHLdRb0I5Le40s7cJNpUb28rJyaAWlhbOEaJTpKAY6d
DoBpZToZnSjBxy/xi4Eqzo3pDSomz7FIaXZtdIe5ZVh3Nc40sAPIJAd0k7gLmIdwjlWP7xERJr/A
dvXhoLDkQLYEUYH/ADELlU2KsuAhVR8zt6qBTHMpQGNObIRkkN4H63Aje18OTkdrLmJ7KkDp3Dt0
vuYteo0BFhNwm505F5xHi8fe9HGLu7gWbC0p2qACFfUSwir5hKIUWJ3U5g6gqJ5VTQnf1gAndzah
fektZ6mw2JnNqzDv/K3H9yw2fa4+VzXxMSKQpiF/dkvRcbjwj7/MUC0Rit2GaNELOdS+aabYBv7N
fFyKmNYIfhOKPpx29gnkq03/AKKi/h5cvlKOkzowDaUEALiZ3r+KiNS4fKw2u6MrREeR1We34ozk
wMJkwoNgd2N0G2r5lXtQLY2QoZbKE+ls4R/o34dqcSMIMDZeDgYjR0FJJdtQGqFzZUEw5VhNkZRt
MolyfBuXUlBWvj7BOP1yGgbm/jAnhVXEol7SsVZp88Fc/kmjX2ST9Eu28P1UAWX24nlygrwiz27S
ZsdS12Q6x8eJWCxl+YstSznsCx3RNS9oacgstHlWfsCcXKBWonw3AC/c50c6FjQiqx+Fcg4A1Tkl
FqXEpLA1mdegNJIjQaVVDaZW7tsya257CKbuxCTbVXL8XyDqCIm3JwXLThGtWDQLMLuQU2ciKqmV
JZF4Yct4EpnGZLXc7bzjhpx6X6Xv4RFJyo0felS5LHDjomVTjD5loQymUUqOIauPNIMjalOEXEqi
dhklFGP4cdE30y3n/LS0HEo4PaadyMj5nwEAnKuGpO2pHJoWo41gDYDgz2/lKL70doPrnqsvq778
+wPRsB2DczBrRASQXbdAwNYyHOM+stgmK+y9ABZwLICJ4IGE8cRQbN5iq42tsA5UVQ2gWgbfqxyM
uR1wsavBQUUozJH1QkWF2K0BIme+zjsbghHXmOW3r2ZSoriatwPPNajM6BTocx954ultXkAo2l05
wYqydTqEpZ+sT0Uk5W8e1mjxX6A/hSfiOOvcZ7dGY2KKqrH1OThSNYRaqyyQdzIbJjisoCmrEnJs
Q3KFTG11hSqWzL99E2I4Bhy4PYU9fusG0UXboV3ZTwR3sjf7OdBwBRaRZvbIeiWwnYCX/NIp9DCK
NML6OSSaDbmGU5vi1eBKraCghg6kgZYI5XjlAVCxqtUnHoSyZcGQLbqSdY07MEK2uONYHcot87Ii
nh0eFrLSJ3SBJ1LIXWgZzlGyXzcwHKUeWHk7W66l2e4iPNrBsQzEpKiM0D6Kdv4pAxcByJ3XXRxV
JynHD9WsMYlwgLiUB0Z95btj7bEF2APKlNZKo6yMwOhAvnsvlsawnwpxZviAF+Rrtx7C48NbuyF6
ekTMgAruquwGugytqWm/KDkpCzuLmRtzP0QVv7zV6ezGassGgtjlDp56CkW9fTKPQ5wsFRlC7FhN
u2oigyQ9qTYhURz5PucvBpI5LzU93xYTELUghoXTefAibBeQfaLwhtE8yzU+XvaTZlhzMqWLFOF3
XactLDxD3LMDuGp4ImujfJKL1WVohzqZYtJ7JiKrqIFr4FZ8hQob0zS3+uVRiuQ5bSpzHlqEluaI
GcmFqJVBYaPj5dshsUJ3DTvlwHVs6ht4n9cIgu70h9wrMGvCty1xBcyfeG4RoGlcGa1JoHiqDLi2
E63sdx1M8KvYFBfQyR98bJ22XZwTNrs9thy2H+TPwCG4OjG9O6JKJvl6Vook4c3MYmiDXIBDsU5V
Ho8Rbym0IajezQSVjebF/W164QFM9zhU1xcvqR+T6dPeHv4IV/UjcxFFBnrUWpaAPk/pEkG5aQ8U
9kWX/wD8v41g0T2PFykI2DqhKOwuLEXoygSIFEalXKDQCZ0CMsWv7P1AorZcla5F5xU7SFl/fpt3
/LPBOyLaxW5ay2qe8e2jYZoY8JhFBoSYAabt17n0srNEG0snxdtVz6AMJVFdXYLUqjtyWSJNv3dg
xD7ODjtGhhAg4Qq4kHNFYsA6A7MKGEcEEqsN5b8vOCyDrIusbUV3nUILtxgQ3zpN2BnqV8i+5jMD
3oZBdNwIt1MNvRu+Eyz3JLNJfKxccvCsvkKlLa4UkAlWq/7UntqNWyb3RmxSidt77S7mjSJU3FIJ
eMJN8X0uitTGRZ6X02OpMctrV79ScvwMBSpiiOPfG+ZllFb/AD2R3nsI66EktH8dwFFJAfZ12xEV
aLTsURwmNBHNnYlgT+j2KP8APzupaAUawC6HsZtyI8uBp5Zl4OmzZIEQ3Bw9VgQbYbTOFEmbr1Tm
WhGQgAoZjsWedDH2pfqN3uxIjMBfRyvEfKFWM+BgoQ09FrltDFPoIZrV+XDIExxDqhiqCf7raRov
kLqAmeKVTHDf3rNtikVj9sRpD1OgodxMFQVzb2t613F3sddJte+ydC+5QZgcpSRRkSysIbcsFcqQ
I0SD6DQRv6+Mj1RhqWTx/wDFLOzHudiDjeOa8EtDgFBFiQsP5YQdFlUdztEirmTLpOuQRc3HH0xG
qOjU1GgoylxzHB88FIF0a+gugXAdrivFmSmtCZnxC1qutBHmMMCLlVuebtZNGUm3wtLgjmgBS6rS
jsE7hgBM81SpI0iq1jxiIT5K6emM5YhrHKC2EkQblL5xpbGXsyvGsOgFIHW7dbcnVmlk9iU6VQb3
GEgR80wghcdnVvaxruiKAkiiDZXx12ERu3y1K7DlYMr5GW+NVkmhoxU3BF2sqvbARxGkisC8kWAK
lGaWorNFGVYSMoUsxDTwA4HA4uCqcAivdcVoNW2bByvKSnQoVcTxTXYVShbAVRdazqOBaJngyHtF
gYpGiGtGt7qvVmxPHSiYCvPeg5jd4jgpvnp7OE/oCCs1TPssTObfVH8gz8Vz1T4ei1Bn/SPXANIR
FU4NHtsDEAIMXxhNztV9QzpgbsVZm9SYAaRw+7spwMDJMqmDdEttYtrStrzfGNYgOQrFtrAKKciy
bbOSxvb0HAUukJs2iwQB8Nx3pwJamzSZbZN2KHYAPfBBtOWrYQVkD15fmo8DSKb8Ni7pQvyvv+Ow
MAOwHCwuNcGFAVorBVYu/EwrvlLe4lqOxhVAZA4KWwFAL+fI1i1bfdezvmkbLIHGxI5Dtsivd4uE
KDBX9Qbily3FtUBqF2cYUXPRIQpSl7+XPjh7BNbJ7J+3dyACmSGoWICBujaEjxIh9+ZN76gK5lS/
ENlUqpo8AIa2x8CwMAcbcURTC2AvRGRIqy5xOtvVY5/G81RYRvAiwPFVwf8A3Ib3LMtSbDYmtTjx
og3n2MC2YigEAVTIWJaTHC0nwGJrYGJc8CCKECLARr1fnXFpcQ6D8QJ7Cp/UenbsoWgdhGEVVM3v
QlyY+M4j2BbNBkOXEROe3Njwwzu3oThhlpy+kUrU6X7YbL4q55qQ5XF3GA9J2/kyORtzAGQzZO5b
B0SrLcQhz6MQCl72nDCVQmrUkUD5spwmC7ONYMksrI9+SRLfn9p/gfrXh/HCxBHZ4tosuZXtAUqZ
XA0Tf68WFdoxUE2mwK7dYuPUHhENebbs23EiNThHa2g5fKhPpDKnasHgGUY3y5Jcu8/7LKtedXVK
kutrtYcorX9S6XAFGq+ADjaWCo0FhYRWXBUcDMIhisFe5DTutKJJ+VzFVEpc8JWeVgxBxyFQxqdq
wA5Yut50yNp+QiiHrB6BP9KcSYAJbYjPr3UWhWTrRciXFp5DZByKrFGx2pagKIRoEk8D8GLNuhzf
OFTrKiY6uOnwbk6y+hiqQOxJtOpUtkySCl3b0tByGwBn0Q/HVMzK+tCyNP5NoRKjh1IVkE3CZDGP
S1WbDKFsaTt4ddyTKlhQwp3emMvLrkdFWlfNY1gySZb+b7dEHDr8/juaeYEVSuDg1o40NGLzAW8A
q/AUoqqKbGBHxJrdhuNkJHzGhlKLktKHnqybZlq7ig1nKp+rYvwbKfYQDthWm3pFXcXHVXvC6i3/
ANAi+GGOCx5fnJ6XIGK4TK8JUVo1YRV8wlEKLE7bBV+HNqzlJfp2D4fYmGFZRYFbq3cdNBiYkW1y
Ma7z6+9F9k+gRUYtcgT7mAxR1IGZZoyUONcggnv25n1Mpwv+VCwUgYQZgNuFAjE+sePtQY6/8Mc4
8t0j9rCHkZAFzC1Lg6mIhgykds/hoH0ys1qhM+HZRR/Hs6KUtC0dLISgaUEZ+MYiCaImLGSwhgK/
1zh5OrxmpYV/m468BaRjqZ68wl0A/StD9qbg1Ht33GmfDVM5CRhE8A67Q6NpcXZiXlb7gPSOO31M
4zQwVPqvZReX9uWVCF5ZpOFU7K5p/pp4XjTo2jUhh9bt4pbY0xjI8YEeUj5nGsAbjpsjfzfbokCm
y9w+l5PCopwsP0Ky2tZ7+fFRLKOQSYDUYANktWuLIZWEFdQ4EE1Q++K7VPlZ62wDe6L+jLiKdWZd
chfRIEN9DVwDxjUH2EPOMgwIFrhnz4+WnWmGZmvVGPzQ5QgTGjqLuRQrEisuuTMInB9UA0VpDDlN
aWQR5ysOeZ5nLwAqjnhBDUgM9GZ8tbJZ7mhyaY8hS1wqkecMQXAOp7gEzRfBxuhHbdFkHVBaklmn
DQlgQbnqoDtul2Oznjj+udP33nLq/hj7j2UyyO0pIIJtu9OBzdtNWBerFA+3F/Knco2/MyxkOciy
YO5uFQmaul6DQQw1vurEYlBEBkNalW8orsyym7qBac6JgtbLvzB6YL1qTf8AZhYUzBV05AzP96Tv
mES2BbJVBlLCLmjMhAqrKy2z3gjCvTWB/wBqhLu+TYGpFDDtBm1KlW5kSgYoaOYOensGurrDbCNh
jA/+yf8Am21XEawtnF5zXovWi8WtGeL5pnKxsABEvMIgnYCvJIc3QGhZXSgsbzpQKvICDTVM0Mjh
OwyiDqRqtk6YsLhlqBYqlti7Bon3W0rXDvuZB5xCu+MsRqIYPXph7AOiVOGz4xMGKwyyQmp4aqxK
R1lYMr9OgUBwAUQpBPm0r50X20ZBrNq91S0L5Fcneqjjjk1wBw4egli/ip8nJTvQEEVsx8dbk9U7
91gauShYRdVUXQYpi0yjhCbJJYzXojc07Z0yeMLUDBXN0DO6irLGjwYdD6V1SDiTkRH2Q40taJhc
7QxWDRmW1tWCmTWZqvvLRaU3+qFTwFfz9NBn99CcmDWIuMrSjNoWx2A7H5R+Tjt3dmCnwYTUNXR6
YjPQ9XSOG9EwXSW3BESNmr5jVPRlO4SE4zD4WtTRBLuoAKrI5fhtLq5+AZAiXPL9CzcvzjDkJIly
OvbzxA99SoNrHmDVJj4c3QGblZ3iFVIqEMPUR7au2SeCzaBlzsF0yJFNG5vWi+E2GIDcl3cbidh2
V3QQuFEjSuzMJ8hvVuNN4WxDNi2unYhwNQAnzWNY2jXzBYKVQvgc4ORKHzCeDbwYRGzcCSmXTVQU
z5EaipWq2wImnk8SYXqOhDzIqj9Q+v6GxsuJ2aVWgHY1/wCKiodHDtb8Ws0LUj956roDdfWFC3h2
6ZGtZWOEZoZ4cR8p3TQ6wKCzo9Bp+9Do2EIIjMWS2vDy+3iAl08m0VkOJJDpz/QXcX1Yp5Kxolzu
MIp/xO3omXLQKJc5VPAJlcA15xPjcOuZN+uIJA5BRUvU44VKXgGrMgU7DyLJRDNcX/8AmiVOZjIF
bGO+U2B2pKz7AcaZ942gFkiR8g3LNo01lEPUWoQZ7QcuZaL0yyFbJ5+aREr93mGF81qa+U4LOmmt
hwFA5drqqtd5DZX0aYdfmiArHm6kpRezeLXFJXu44NUON54m4DBFbSsldK3RQf4g4mS3BofJgIKk
DuFKlj4iwEqKD1bgjU3OHMapA1kcelEwpsI946w+Ij6bulN/1XWqq3zygfJlhpHmnhJw/TaAhwDC
kU5GexGJIuIVHDnC3yJwmHAcmqW6yys8aFjAx6qnDLjvFeE/NOjGsfMPJvqbNng/4f6xfiq0oC2Q
EN6KKCXCkNDGNIK7GE5NDkEyKFyAzdDGrAqWDbWKiC+thUCYAFhaiu2zLRsvJSzFaiiSqTK1CLaa
CysQ5BVhoajajVgCEQRpVa5XWtrxi900AfBBxo31UtWwbojVwimzQUG2s7IVZnVKX7RVWwWS2k2X
KAFBuYXsDUXasAKISxMtg1VF4VkpbpXJkqQ60MYlSUWQUWwsLMuBV7GA8uVSe7gxHTlGDbRsTUJu
oYF9EkjCAtgYNRWps9RlqwZaYre5u9pja4rJ3E1amRQsLaVTkypQ2VgBFqInC1m38+3oBoK+eRrD
wllRfyeXXRK+HDjSzC7Ikma4wKykTVBVy8m3DqIEbaj37+rHUwCKxlBpgsHNDqXnJzONUpHRZiN6
QknQlRmbzBHClVsXvVP9Bzmp4l/aRn4UgLfJKad2EsXK4eIXSNfKED11FjZroaf4pms9WQ8UCwd1
9eGzjpFM2saXHtnGaAz88jWAa5WMt/m/FgcaW4c2vCkI7fRDMpTUIPWMosKZQA92kUsyiImBWb/L
DrgulDAjzohXcUtGM0gbZGKgQ0yyVTKNIrKoAnJ4uy86LYYUlE2QUYUtjgZLLEBRgmAaTBg0Viii
sAmksSlto8IKKwPM2qgvyhUFAyMl8Uc6qAswF07FUvdClWWCtiqIQM2wo5AwBqqrq0l8I1cqDFYa
KAIWs/PUaxHMAALrn9f58P8AXB6Nkaq/sTrQmgTTegCpTYWJJigkCpPNXnbKt9spi0nEgcr5vaPW
JLKMqUaQImIq0baDSRFxhRHHBkPV47aU5garM5fnInS0+mVv1m9y1VMqFwQ+3KzvwUrulNCeYbNO
lZCkwgZBasEgYABnCrhQmxTY5ePsJ7AumR2SjVV8xysJFx11K426IYyXBCyNYIVQNlmuyqviWsJG
JndV4n3Hlq0mTk2n0biOETrVEEfdJBk3bnEUskIkIrcBzmEidBq/nEgxIM8Uqkalr0p0CAe6OjlX
Al0bAG6Re6FDaW568Bj0FK5l4S7k8H6FF1IOksGEU/l0awkrx8bjr8mFirNFJ5EDV1tBklCYowH1
UWDVTZ0WoKWxUxIVGKVlYYLeQsoXyGro3Rykx9rcKzal3YaE+VB1OrgLFz5gEpJFISLTKfc26hfo
iR0rJg34sAAA44FlYwZlTne0pihyf93obVAJsW/BYG1x7bukzX8pclLiB6LbCrDEQe7Jc2DfRDZn
kRpVYsKncYd0NSKVdPHhA0zQqCX3hKrS6F6g9JNkg9aV6agN3hC1FoUyTgjExH0VvnjBXaZFD8oD
69gkEDuBuDPTbb5v+HVdQhkBtY+4E/5hdJNGPYMUVtwEEIEOQtdPAEUAAAAABQAYAMAYD5fGseR/
jdVfk2bgGWQUARIgcpsrocTUt+NlOq/8ieNrQ0NRQxGnRycLeGkMGYJKBS0q74QFBSFLUWc4stxa
qShRgIwMQmCYZm5J7W0ZO52t4VV2MqMTz3aMmXiF/f8AOLho6CgVKubOslm/VDcpilkDCmP0AKKr
57GsWw4v+NZX5NbA7BxE80EAMWe8pexw3WgnIMdD0xwqGJ3GSfOQI5BAYEIbxEXuYmiwYS1PxAV3
FChE/riShAbgTWjm4Enyqp8BBb9uBRxQHjPtIIE30QQ4TfE+jUbGt9MpXvIqeAetPbLV5AhWhDq6
CW5VXz6NYvb40h35NQMvzIX55eGiXsKjhUAGKQutGBEteR1Cl3mxMlt5L+A0W1REszLFnqEWrFzE
AxTrqWMK7h4kM2JXsASiVjy49l1luTLliTbVcQbjFxCaaZkBdzj1+yreyQJoHEIB1HxkY2k6ttDs
5oKS+NWWiJ6z8GE+5+0fObuNtzEXJ/FI8ZKXqvobjh/ceCpeMkebWDYhmJSVEfh3ArgrcPkMawSa
PLiTUfj/AJ/WfGfk14payrcFKKkYFi4KOMiZM21LMBgj1KIHwpyN4sWZ/UFNN5glKc2tkn0DgKeD
hjwIQZg5YRecFFdBrnkSkVKGu2YyyVeS16a8H0KuLJjIPQ5HANCEJQPGMYSKQUBGRL+iDjS8iKF/
/YkhfWXHTI4udQfToESczy0tPLGVCJ413clHAfZazjamtxg7ofEBxm8giz3eH6TpuycCsH/AydGY
7Smw0aNOVjmlOzXxkawOyy+1+zh4x+iD9QL70dpX8Zl+TBATQ7LnClRlr1Sgi5FpiinEhrhW/DFe
XIUBBMliAJFVG7VqUmM0NG4ZgWv4pI1ofPIl4HH+gxzfuNgKTDLYNMI1A5bwWgW+Ao5kqgVArDQE
HVg2APY6zxmNWzFpjjq9plIAjKHWj2zFqpJhsbrwicNUDFvve0vImzAoEF83jWBMKcM13vfovyK4
9nCMJmN4Uz4Wrtb3+NL/AJMCy7sYdkg0GaUu+fdCWyUNMs9OQPTHQS0YrzOUZYlH1k1EsB0WKAwm
dEJs+ZqWovn8I8ajC2jWmg6xLbNS2GlaWWYuFCRmZTGcCDo3NJ5fZCFeYtE0YhWzgYGNCeGn0pnm
z+eFeeYXUEY17Jdy9aOR2amGamYokG/5v+iNYG0bCeAVK4LVxn2VIcb/AB+N4n5M6ZRzuMfpZEAn
EdoHZbLRH4AUiUeWwF4EI1BZ4bRhwSwHDCvJHWy8wAVXyoFQI+3a68O0ZB4wBACscCFUYHFYS1qY
StxR15FbUDUDcV5AOUBUcsguWq02FuMDOsYEQDRCKkLqxBG9BhA4TFwcli12S7AEdsDLUgHU5igx
uVzhWCtEu8YXxXkr4GmNUHkATSX8bGsOmrW0jjGn85PYwyx9wh9VA7qErCQD4zf8mbbjiMenKkjc
lrjdg7EPN3WsAUFS86C9IoJ6chbPJhNA01yAvSWIopUIwV8Jta5xT4ulw/8AcFdJ8RdYAhc5hfYV
ZhTf8CceLyl3JFaLwozYBVCSQhgV4hLVp0TgI1pNYVAKSqBHAfyk9C7hUmJxMzQpWBgxzBu32jxH
bEYwS7JrAQbJNO/YslMmYfXFVkaUVq4vGrhHSgDE9tIJCIrCl8Lk1pWESuNXgJyBmCU5smBeWhpO
KAGAoKpWDAwMVRWq+QxrBWwtspFpLrp021YIPjezf8mROYwa4GxDFJQl2JoOe5DANsASDwe3srzg
G5v1hbZVBcaVVQTzDRRFEUYlwN/czQUnrKW/vN2PTohyEPADIBgClsURLFcSvk20+3xabGK1wSg5
2Yl5lw/ahjGxzXIkyKs1CSu1qK6QT3whi1lxHTI/fBrN+7VGZ5F/jUfLD9JAIRH5IWvrqC4pEW62
YEmJLEKMphiJjcZwHTxUI2SNyTRXOzlH4TbSiWVd4r4yNY75h7Nr8z+H5w+M/Jn0BCo/7XAiQS0O
o4L7EZMe32I6hbnyocCjJqdRISo03kgnH4NDVZOZkaCyTcn0GyrGI6c/Af50GKwP7ac9c4f7NiDK
uEKJsJSOxdE9ihA91WtnAxfgpHpQl6jXSp6UugXUXNzenJqONaJJ6J5MNhcQMFb29P8AJjZoBW/X
MQBsBuTPwSMLd1/Pi3OdClGpBKGvo1sN30OXCfl9fhSzcVXPIWmuaClLarKM1gZIVAVlO7Gg/wB6
ILAttotrby4x8XGsYzXlAA0Vvys3und+jRh6r55xpfr93HS2awbQ/Lv/AC93xn5NbA7BxE80EAMW
ejWqAyaBAF5ZNZcsbaSsNclAdiBl16VDjKoFxkFqFGMUVHJyBNq8m/ScWRk41mxTIUF4YGmlXiZQ
WNdQ5mlrJVCpe+w83ZVBG98lAa+HMGtml+SC9/wVQDWCkNzG6syazNYjC0wGiBwC1QA61QAvYVKA
nt5rHQvManpCASX4kkIR8lGFkvn5pQpG40sRNmSjl2pQ8awnsEalNhr2AsBZQ51fyG2K/JqBl+ZC
/PLw0QoFB5ukm1hPG1QQB4XjYCeUfyK1GdwmSzmvLbAsJNUF41RUk6MjW5frkmrzAogK1cyKkL70
xaYVtHT3gP8AdxGPOrCMlO2IM5a5vS5KeKKE7SbHtcYCFU2y0nUiwh2jL1cpofcNVkVlVbLBzegO
AQ+cRrBp52fx9lJ8b+J/JrxS1lW4KUVIwLFcXOVdYMx9By2spi+9wAZTqPpODItvCpislvCxj7Cl
xYUzYAGCEgGBeNZAIJUmsPRN9CFTY8CuLzxZ5Q3EAbPiYGJLJJ21zAJOlSyJJUlSWT8JXSctnYQL
pL9gWmbkIXDamYVc4E2P4pV8dGsPlvODkH/L0+G2vZ1uNch8ZR+TWhI7A/8A5x8UlM7zAy1oVikF
VG6cEswq9G2spRmKTKzRNanNStW1iODQHNuEBIMAYLescyr5J4UO/SVU5gyDYuKMRXERAPFEk4bI
hXqKTrqs/TECI1NXPbyKjW6qeAVHRjzyKItWEEg+PZUxW3UTtEtcTRVC0LAGgmA+Er3eA2XW9kIK
VNGmMJWlRMY/fiGTfNFrSYmYh3GdDgDtyvg4fDIeLBRYE8BcFeLOouzTHgshMCDDagNgNhO0eDs8
GlL8lOzLmZn8uX5/Rl+f1R8D5fwnYQxDlRssdyZTIbKNHsu+vjS0/k1MSpUI3xTnt4QB5osDtHwj
D+wWnC/f4ZXl/dCTVmDlLv8AjMrTCqW5Ayg0ANQAhaDiK4yLf7i7e1m7WX7E2M7DW/LCsmgVgct6
Sp/vrtXK0ffW44V8ren9CVQn9+y2cNMmagu5Iwb1jIRy1fKo7K+tOr6CGoPrcTPFkJSOVmUcocfJ
bIrmmhE6dyYm1vADcTJA/K4r71mJXzMWFYaUOBzl8s3qOP1se8a01WKrx7G+IIDNDz4im4Ip3I4l
xknmT6pokl06w/ZqMRkmar2GC0yE2Nw0Y8+Q4lhT0RZHKJdM7YopMGqNFUfsQftIhCc5B2v8u8aw
vKDHxX9IL70Q/Gcfk3gZXGCrRwuStlAo+/gW2iiUwDFq3UxvNxHHcVMsICvaPLEGnMWqc4BkcrAq
b+VIeqIMKqQGvLFa4I0cxEHcutoETzvZPiSms6UNNhQoQQnaYsB20Cjl2i4bKShYMoC5Ec6TxGwC
MCCWxYYIYJOABAQw0As0kudwIlUBmFawUYxxo0cFcFHO19hTs2LGyrRylIN5PPp2QxX4aAYX5/R+
NjWLOn5p66xZTJY0SzmnJ4wxxh8V+TLQc+0qJmaIlDciBCkDA2WZkWKpWjj+lCmrwvf+vT7LG1g4
yM+t2bZGWtZSlbYItm+9GNH/AC9C0kmsuqpdBtJus7q4hwqFxhwybHUq9CB1ju71aghjWUqAWVy6
AbvbslUUbaCkJO/vilK0tEESg8iC6FfoB7JsjMx72S+E7joYHQMmYoGMyH/TvDJ65VNHTJycjWg6
IF9IEdBHzKNYwtW7FKcLYyGxmrd6PZ1sKJBEbw8UruKOOnp1DXxX5MLFWaKTyIGrraD8mRfVUE5F
lSYOWpMHTS5aBUA0CESqtqMb7ZbYAT6ICuTN70Eb5KZdaohOcD1NBYCAmlhEwaGl8xOlnlM1rY5R
S+W5nGa9cyBnpuR3MviIAsFeCf1lOZgaxEcPlMb5ve/MS0QP5FkPXOaU7RLoxL+D10Otgnv/AC5d
OAK/Zi4UxPT6b4Kud7irnESU8VHWRmB0IF89h8yjWLO8LJyFqXzUF7p7Ps4zPIhwX+QdH/8AvxX5
Nm4BlkFAESIHKYJoHxoWLbgIYtaHtMQXwG9pmBkroMG3qIQdkb4jQMmXMUTy9Bmieq+NV10suLhj
fmNrQRDCSJ4VL/AMawoNLrEdAm9ZcyvvU2hUXqxkrGZ78V0NHB11HqOr/iRLgyJjpKFdk9OBaewj
6AZj+uRuWiQlU1ecF6/m1qkaxR9T6oei3HF49kKnJQ+f+p+jwhr4x78mtgdg4ieaCAGLPTSO5xAM
Pup7isttu/NZovASYFnrQ6ogbAoGKFgqBSA+XrqAiql2L7eGxCrWBSrND8UnjMZ9u8b7ICVlo2Cd
6oam3cwwFzYzf2IXwLkJQXzshxAFygBBq5ZBtRaALSubBHQriL3GyDKqdP8AOSItCUZMx2ZahriP
iF07ayWdyWdz6/GRrFCvSzv1/Ln5kHxh/wCTLjAtn8LvlAevWy7UZyqHxCVOlqwBRCNegApeRDtk
beixvFCyVhU8CMxB1kqJ1gyWdSlyW/iEhh4MQW2pJJQIODZTq8TlGmJOpEnXzC1oKbJONh/xtws4
RmVwEzHtdIaDgxAaO3NbkxIyEbZm/OsFuhalP3KFgf6a+D8Iax7FWL/YTiCRiUbCAYQFTvT1PgRq
suLQnTY27pIgspURmZETqVtAu8M8wL8NcnE7yKC8MOoyxC5U8+s6/wB7cTyKTpdEmpwq0PZAmcoC
w+Kkiu4MStQdckrIAqShUrXjwcPGtSgIS3eBBm1DFqwW2hbsbH5hRrB8fGe/kzp1ujE8uMgyHAFb
YBVeSMLbOZ/LswOoYBIB7p/RwWCPAFm8tdcBnPgOwruoXnu9DPVx05zMps6wIKB/pusn8XiIxJiU
WSKAnvG6yGLMhRnJtCRJvuQwzsWIpMNjeMshBm6jhU5N02SimoLm/wAhj4WVSei8LWMdTm8owNOB
cVEZOjJUrssZNFtL90UHTQvAQ7or9AGI/o287pe8W+L6ROJMOtWrYcHwQq+PBhFrHEJASSaBVHYo
dEGAZveol9zdEA/F2DTdgp0LC8whgz+bpDQB0V5zG15Qb8PIj6InmJPEvK8kwBQOBVIpyCX5dGsA
oGhb2/xIIYw+K/Jq/UyeLjsPDXIJZu3wUOOFp0fO9kXCWsZTl59BGGCxI4un1llxGGIIqff7Nsa9
TIT7I0UQ/YF0gieFpWVLcictY0Xig3pv8ytM7tXAb1ww222FMEuAsJpbR4XinSBVSUwHdDD3smri
wn3kgVTRxh3YFw7zwlGBAGPqV4mizdyo34pEYXOaxgm30OiU/wBsaxq32piVI5mGZMFh0uLeiwLv
BwEKtjhT33LS99nUTEx5YuJlGXZTEAD/AB9BitY4G3pClXCCgRRgwm5dBz8TIyk6wzrENbAzUOxa
DFQT0gMOM7QvJZMn+aP2uB9sPcUHkTNsvcvApoyfs12BrEVV5ZY58N4tRRWyieisfj2oWLZlU36e
LpGREc9XjKT1mjh/T5K9MzEYnCmnnloknkEwg+bQieTBGsXij+Av+oahrD4z8mulNKqWxYEVK5ZZ
VLyqv4jcitnFIhvZaKrkRQhJMRG7iXcY/BhIS4nIdgjVkNIO0EPhYigCu2SJsV6pWQyLR3AS1n+a
+5smdV1smG9DXGc8YZiJ4UMWBW9KsmgiuuV0dLc715UipU3DnMB4s0vUZ+pI67fx5dmpwXFQk2R7
Lo81SgdFQUgWZUF+palpqpm9H4nFqlqt7hOk8hCYItmsyZmmojn41qI87U+wxRYjNvyXAoONf5XB
mYTxRsWELQNLCQ6QtRt8rd5/Dxnnws0Wa24BXQ/WlvHWrO/vYQsDPqzqt9t/YJkCx80zaru1Qxh7
Ez9MRYoWGfwYKYQGC6HPR+/Fdd0+TCWw4FAwjRxoHwlihI6Qu9tPJSOALPThTTLN7NoF+hWHtbGL
hNRKwKfihQjHoamnY/68Nj1/2Ultstiq60kWJ+BYDwLPcAdNNMZriPHprz1WZAAugBgAVlFO6Kcq
vyGNY+WWHxn5NdKaVUtiwIqVyyyqQtFEFqRm2tiLgC66Rq7firy5TTZuWoJnp5fc1wCoKxkBy3Te
TTaxBAA1RQLQL5QkCt2+oJeDZdlXJsqEFBZYiF4UllYs+yZTtsvGdo301WKDg/2s1WP5eYYyAbQ2
27VaC1VXAB2ADAf+cjWDmr8mMUVe+aeApWttFhE1ChtuhzEK+5zEYeDKbiLzhK7AmNzHkSImzEVq
UP8AOSozrQRwJ6bOFQto0wuh9ljIqGcOpcsv7R4Rei7AcxybQ5fev/kcHahWIwqkdLEJM63BVmTr
8wYAL2VfPFTeWUmlBeTsbMGuo61UtILaIz5uIjEGnX1TVKPmsCNYsdZ2eo0/Rw+PsKqQ1Hf/AFIK
b4hM15A8EC9Bf9mJGv6zP49keiHmLCZWHC7P6JT4sZbVRWVatZK25LMTXdqrb8kcq0bW5sV3NRhw
oon5jbszrtuaFvKrk0rQtZ/2FP1Tt/TIdXORpFeO1jZIXAH5Nnh6SJbR8og06Foz8thx0CSLRAAh
qsjlIRby9YeJtmJRl7vFHdmCLJTglZNr3VZifKcGfd3lHXFCbpzWLfIcYID5zGsU6r+Ev8w1HP08
twdF8UZxKK0WtsxbRHI7tFyTNeO328OHDhw4cLhUZoMvd+Qh8pGGy6I40rBhFG5SPc4cOHDhw4YA
sWFUZX9Y0/SfovvlbScHvSihrzjJKhJQW38Gv/HAY1jaKklbiHfJkb0r0OkE4Wg2hkgQmAuLAWB2
L2w0852rKS1JaktSWpLUlqS1TA5W3uLMENLCg8niC5C4qNJaktSWpLUlqS1JYhCzSJ77HdhOTfBr
ULIEK2wSxnEuKy9EIWUtAP4I+n+fit/40DGsbSIvUDnWEAvHBjCgYLSoQ3O7yDLbd7bWrektjTFG
lUA3PkyRzY1YbM3uGpkyZMmTJmYzHAWzU1yX/d0SwUw7Has8t7TO72aB9xMmTJkyZMXEa9oHyGVr
n6ODGoshIlmkIV1SlTWeOAPCHEzwV5dX3DUHcVD2dJfoJhQ6Ja/Mkt27du3bt27du3bt27du3bt2
7du3bt27du3bt27du3bt27du3bt27du3bt0S18GEpCcnNC1oZQjeePxcFQS/iKXbt27du3bt27du
3bt27du3bt27dGpIb/rcDEVthEtFKFUiU0mqt+r/AOJQIECBAgQIECBAgQIECBAgQIECBAgQIECB
AgQIECBAgQIECBAgQIECBAgQIECBAgQIECBAgQIECBAgQIECBAgOARWAwYvIY580FfAIECBAgQIE
CBAgQIECBA8FisLgxeAxx5or9ygQIECBAgQIA4gAgcRLiORMjGqSq0tqrqrlXlhNZ/6Zk03vm6mM
wVkqxBaWuveIkWS4AAK5kxYS8Sd4k7xPaTZ2cMD3ixfFi+L7Cjx4/wAOb4c7w53hzvD68ef4MXwf
dKxvsWNfAmLP8KZ4UzwpnhexQg8f4sXxYvi+yrhx22eJE8SJ4szxJ3iTvFmeLM8Sd4nXp8/Yw38Z
d6YGnXy+3giJr+RelY7gtK9E/l/sJofR/wBjNGnl9n0mup6HsCiDBut6UL/UcroB5e1FjZhe4Pxr
U4fSzFapah43Ri35wXl1XEitLeR/ZgAhOsH9HVw4GhXqQBdNq3NC1wwE/e49RAEoODUEmx1LUANS
rDd96sWtedFFP84AIAN3z8WBAevaHpTH97EiRB2R1z2eJb+l8+bt3YbTer0W+P8ADrv17ON1i6Yn
piGDS11wgQzGjWbN0i9P2JsQW+g0P+owGI0eIx9SG43Z/Ew6PYfnx+ae+51/zrhdR5PPlF9bzn8+
n+FM2L3tsdgJzPpgROQu9Z/vpU/NOYy7d2X6zzpB8V3zN35A/rIFGboeQ/1H8d5f1K0Ll1FN0Rye
m13kc32JhWdX/SP7PYwQdDogEnEa16EmZaX/2gAMAwEAAgADAAAAEC4Pc94gHJdlDSGdWiv0GeAa
RDVevZa2wMu/+8qAerabT6fPQUBEikeDLMLyzVW6HFLJDsHTz2xCLnGBLfe7GwhvbSXHvVuoZgLM
VSd3PHyXXxqnBjnDDvvAAAAAAAAAAAAAAAAAAAAAAAMgwwMcMAwAAFm93I0ls3zZRBaRcMMMMMMM
MMMMMMMMMMMMMMMNfPPPPPPPPPPPP11fti3oMnAcMmJTzzzzzzzzzzzzzzzzzzzzzz2scccccccc
cccZHqYIzN+tttqvoLZcl0AAFMMMMMMMMMMMMMMMMI48uus88888889FcX5SO1zwIIYQVc6ihZlT
hwAAAAAAAAAAAAAAABDTXDDDDDDDDCh7wCxva4xgwAA0PsGLh6tkwAAAAAAAAAAAAAAAANR3j06T
iQAEtXkM0UxykYYAAAwAMKj1dqAAAAAAAAAAAAAAAAALMMH7hk8McstoUgLXG0U4UwAAAwOlb/wX
iAAAAAAAAAAAAAAAAAEAEYoAkAgAAAETgIM1eFHqKwAAwLgr+vIOggAAAAAAAAAAAAAAAAAAAAAA
AAAAAAcwNjxuuWeoPKIQGpvz10fTuZhHgAAAAAAAAAAAAAAAAAAAAAAABwAOFpJ8R0nAABAKBsOo
F5GNFAt1/YQAAAAAAAAAAAAAAAAAAAAE3QFLqZA7WoAgFALNR4LNW5iSAAAAAAAAAAAAAAAAAAAA
AAAAAAAy3WMPEMcMYQAEwJACl0b/AKEEssAAAAAAAAAAAAAAAAAAAAAAAABMJBB8VcIc8cAAMBYv
yCLb+k0m8AAAAAAAAAAAAAAAAAAAAAAAABcoYawVKnoYY4cMBg5mhuEBCNvQkAAAAAAAAAAAAAAA
AAAAAAAAANrGToeANILLOMMBTtySEhjOIDGMAAAAAAAAAAAAAAAAAAAAAAAANVAAAAAAAAAAAMDy
K6jqfMAAAAAAAAAAAAAAAAAAAAAAAAAAAABSoAAAAAAAAAADwAxHewLKFtabEMcoAAAAAAAAAAAA
AAAAAAAAABUoAAAAAAAAAADwBDVRNaCAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAUoAAAAAAAAAADwC
gQLjfxDiIAAAAAAAAAACcAgAAAAAAAAAAAoBEoAAAAAAAAAADwCy6vF6g8AAAAAAAAAAAAQAAAAA
AAAAAAAACkBAIAAAAAAAAAADwBxoA/BuU4AgAAAAAAAAAwAAAAAAAAAAAAAAABuoAAAAAAAAAADw
DR1hhPrWqAAAAAAAAAABNwAAAAAAAAAAAACoBakAAAAAAAAAADwAzVYJjwjPMAAAAAAAAAAgAAAA
AAAAAAAAAAoBSkAAAAAAAAAADwDRQRWTCgAEAAQMAAAAAA0UkwAMAAAAAAAAAEAeEAAAAAAAAAAD
wDBSKH0EPJzIJOCAAAAAgAgAAwAAAAAAAAAA00BWIAAAAAAAAADwBzuIfJYUycAAAAAAAAAAAAAA
AAAAAAAAAAAsAcuoAAAAAAAAADwACk2PEBqAAAAAAAAAAAAoQAQgAAAAAAAAACgoMgAAAAAAAAAA
DwBfveFvYE4nockUIAAAAAAAAAAAAAAAAAAAAAAH+gAAAAAAAAADwBP9UryzflkQGikEs8mi6sQk
AAAAAAAAAAAAAATWgAAAAAAAAADwADh6rdEUAIAAAAAAAAAAAAAAAAAAAAAAAAAQAdEAwwwwwwww
AwwADBAFIPEOMAAAAAAAAAAAAAAAAAAAAAAAAAAAS4DLDCLLDDDIDAgAAAAAAAAAAAAAAAAAAAAA
AAAwAAAAAAAAAAAVjPHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHXHHHHHHHHnHHHHx26gk/zQiq
U0kCs1bbLrDfsgE8wkO03PPP3XZYOLUj2h4oPtC8l/8A/8QAKhEBAQACAQMDBAIDAQEBAAAAAREA
ITFBUWFxkfCBobHxEEAwwdEg4VD/2gAIAQMBAT8QiLIZIRBZ0d55lsxYJqcsOB8u4AVVDYYLJ7h8
GnqqFXPdA5XqNbPPHO95DV1KdFQa2+uivpdALOolgobbZDSVmtps49hF6pOTZrbxt3pdb0BXdAS2
6JeHe9G8Cuu9rSQe3mbitG4YIqSH1eINOxFLOFFLwpj36Uq/6/8AcYbHXf5f++ubfP38P9/v4cv5
p1+Tb7P0+2dfk2+z9M6Jc+lkF6fr/FRcurt65+Fz5F8a+Vz5N8a/PdwDre9hToemT5N8a/Pdzs/W
ft4fPv8AIvjXyufJvjX57ufJvjX57ufJvjX57uQ+Vx8f/XP312/4+/nBuPl9/H5do90/1f6fnu4f
/OO3fw+bvzPt/r8rfgV47+H574dgfLjx9HHZ+7TT+W+PpffDR4uvw7+/jDT4+r7d/Pr3Ozho8fX5
f++uGjw9X27+fXudnDTejd/Lv7+Mnm8ZT1Hqc9j3xGhcybThxw8e72urbNobw9C7nO+jlsbVgl9S
StOQOTaQ+psQH7yd8bgDZR46fjOqJB1Qn4vQzKZR0Xg3jQLtUOS6iXxda7zBIqXV8l8E5/HrL/xi
dunQ1x033a8J2b/3Tx+e2QyzHV7JFFDqCD1OZOS4S/gdE+z/AM39iHTxBqeOJuN5ciDgE27VtU5j
CQIiU4HsX1rt3PPujyZsyJGpZqFCi19S5QqOXlvlzeq/OEnz/Lp89cNM6HB/q+dcGnwfH2+3nDT4
Pj7fbzinB/Vdv9j3y/8A28f+PfL+/wA+Hb0e/nP33y5PfPneP+xnZ9/w8u584p0PT0913PfCG1en
t6917fkz938+T3yvHS/H7r9/rjE6v/PUfV+/bgDV+hvr8vIzs/WX28O575/8D0+Xc98Vbt+fyPfz
nyfH/j7Z8n5cnvnyfH/j7Z8n5cnvnl/0/wBzOyv1Hby7nud8/Y+H+x7nfP2Ph/t+O+ftPH49T6y7
X/x/8+3jOk31fg7/ADUNfj6fDn5qGnwbfd/H284FJok/R6/ftiLa5AoalS7dnu76QZi8o7d1wPzc
HZqmsdHQHuvJ9QFYi4cEi3gIwMuFgHqQTjp9N45cTRXAlx43rqp7uHYMDW6IyDUaS5DetdsWxJ2Y
8g5r3yCFs5Y6Q61hoB1dOaAhS7Xlx6vthco5Le3fmT7+MHTfBA2MChZlUeoA8s6NGgAIakF0W9Kd
XUIQI3YOtLZoeMWjVCoUGeYQ6dOOTKBepLMoJda4322ZqF0FOVBVhbEIL3gNdzUCETogxCN6vyz5
3+eznyz53+eznyz53+eznyz53+eziYqAKhiOoMxTQ0j6OfO587nzufO587nzufO587nzufO587nz
ufO587nzufO587nzufO587nzufO587n7Znke7PI92ftmeE+fTFeVfVc+dz0Pn6PbPnc+dz53Nw9a
OxjRHTuO+oOQ5F0FGC6FpGuKlFMKViLAFFRmt3zNLyDBlER42M9nHZHA1FJqqKJXR3Mdb18oCRoU
MLuug3GbL0qAbfKQvD0XETkwFsLJfHnnr/v0xCqqw7wl8avHL5wp0NqCFbMKBDq6DsNCpkHRyDku
ldF4xE5MUBWg5e2FediCFewU4JWt4FPS9n5+3xGXR8Oj4YjvrE5Ymp+4z/cZ/uM/3Gf7jP8AcZ/u
M/3Gf7jP9xn+4z/cZ/uM/wBxn+4z/cZ/uM/3Gf7jP9xn+4zA8e5ncncncncncncncncncncncncm
W5VSmoG8Lkdnt1z0Z0KY47KbCjpxWVSBnBexpc84yIgOoRRSJYBx3xR6AE1VFeBYRm+jNV4WrILl
QpSjRFlKD0Cacdpqu3S3WBKq1VF+q9IdtTVuQ4JIBksNjxbE6YOB8gEPJAe055d4EyL3ETQfZO/M
3m6MJCkFdrF1ZXvvm5DNGqC1AdAQE6B0AwQUjKcHnpd/XCnqoAhr2DASrWDPBweDg8HB4ODwcHg4
PBweDg8HB4ODwcHg4PBweDg8HB4ODwcHg4PBweDg8HB4ODwcCfK7aV9aePPfPL8/XPL8/XPL8/XP
L8/XPL8/XPL8/XPL8/XPL8/XPL8/XPL8/XPL8/XPL8/XHd2QrzKz0oPrHpkWgDCBBygxjxe+N7SA
JZAoTcC0bZcd6hCsHEHC04514wQbAXMAfx1AHzVsB2Fz/t1aAUFJEIYAsYc1HFQ3gZWmtxXvYRZs
xCY7IilxbFgszLNrXA8wH0WdLvGAtBS3KNKRAKbXSQUNbQlU3sFjJCJaXcpCnLXAjngC5kKTV3Xu
9wKxKKH1/OsT3Na6BzDt0uLjrE53XVAJKREYjxiggiXJDWzAQpoETEQHKFgfg+UvP9RB5B9ch2PY
wYXUkPdTmsxGZ0ICdysggQNKLPplUDFito3FXLsOx7GQ7HsZDsexkOx7GQ7HsZDsexkOx7GQ7HsY
AcCysLOD7HtgOAhQIlOGj6ZY2EXWA0HhyGpPfCZfkAdT0KyOl1u8w1gCJ0UIJ1GM8hcKldSsgccn
PQdWJh1NKqReOUkIm5khSLSkYUFxBIBV+debBCA8saU7E3sHHR3D1S9ew7OsDs8gu/fxWmbEBRBA
ChTSw2BAz0M8A/1XQc8PwpM+ygKCqFVVVVW4KqgRTSHfW8MEgdJWpwQmu3pwwwLWs2O0TrZ1NTnQ
YbuIWtkAFETUi9WIUpQ7EFB2eGJoxkUAt45D/f7xRxGc3qXqTXUF9ZMbGI6LLsq3CwgKhhFjISDg
6YxWpj/0UTQlBBDoXQpAurhYQJmdlNJXGynbAEpAzJfIpRsIpQRMA4XAwXtT4P28eTPg/bx5M+D9
vHkz4P28eTPg/bx5M+D9vHkz4P28eTPg/bx5M8vykATogre55zRzT19dSwlF8gipshzTSia5DAYM
YtREbwGRJRkEkjB4BLTQ7SnH2x3hpT3dhJsRBUYAmsgteFWXbZUykKJ1yZlKUXgxD54bw5mqF5Ml
KAYeZpMQOZrMV4jwjrU32dIfF0U/wcfX8n+NIBahrQR4wg2JTbS42mZFVAiYRKQWYLooSIERuAgI
FRR1nTwCdIRnEEOAEaiI1YY3YyG6115xPOxoHqEvRzAehdNjEdFl3UblYRBBwBMDoJkh0oUgIAn9
G9ATU1Q2NMCiWIxIxJ9/OA6J0zLrd1iKYGKZAhl2wa5CFY9SUmiI0CFKh5W3Lo0pIHEEAAFOFAZu
O5CNKMLQqxazXKtGtEEtBjgrBawhugWGKHP4X8euR59n/nk98jz7P/PJ744DoQARoUyIY26cFhjN
Y71YrAWTYHeGaE1XDReafV98QeS+uC7dUi9XqF7eusdguw0EgADfqY71jxZRNXtEFSjsye+bIPxW
YqECcDjGh1C8uAnBFMyUSVow2ahjwAzC0qtZO86gGgBzRGgQk5FAAMNGA/g4+v5P8c84lFC38jkN
eVHzlQkEZCKCAk2gCHQmsRXB66h0EXhar6ztoK9AIJiBNbVgJ9MSxxInIbOA4NdjXfJ/SREAAROU
Okeo6zQ0CpoC7da7d+uIaaYJvpnVNDKSErkNuCKCiqVoa1IlXC8lQRNCnG7NS2nOLK4tHpwXZmvT
jpgiyVKOhvds+22LknXTuEuVufpG9KTzOf8Aw2bNv/p5S+oBZolaSIG/AfwoCoTmu7UjdwKkOyO5
TACoY9sEgX6JNECwhGQV1IsZW8DIQzgwqgmFhKZYbEci0wVZC+WZEXzGJbUGLRXoRFI6s/8AAOPr
+T/G9TmmaY8NIoMiEg8jXxlIALEIlDEjsQt6cJAJxGBUoIBwRIEoKcKY/CqiQNE0sRTaPbmsKi1T
vAdXd5AIR/VSqMJUjO1NzHbtsHmFySECBUdhF00BFJQkFWoiosVV24CEuEQu2BAr2zpwJVJalILu
CFyFhsvUXdcr5f8AyBNBOqX3cmjYgmMMDqHv/ChVMRtcUTTdXWuSmDi224BKqosqgKHSYrakwEf+
uPTgQ30E3IXAb9n/AIkU9KGg3s0zyLAtIR5KnxluTAad1jFpg76Jvoe4Q6gWFC7AOeZD/JOPr+T/
AAoPZMQtIIIGJyXjdu735ccC5FAt9QE0jCG94AACE8qs3pXkm9iQCBaVB7tKDOle766wFAWtwIoO
o6HATzXpc0hOehkdFoRlE/jP7odqr5OFipbgezTWtI64DRNc9BDkAUBUFJtf444wDsARrXypdTYZ
K4gMHQQBkrVz4WYNLB+RLQBzGFQSJ5V6XmBcJWbggISYkty2RIERXzTgZLHXZTTcyAMLNQOM8wIS
TRC2IWaTldkBrDNXK4KRBXOZtLbgWKGuFqWEh/gDQB2FPw4VylHX6R2yEz1Sk2RoFeT54PLWVTz2
uIm0wgQEscWV/i6oRaxbBAXqtVBICLgJxIuujaUzK0YcRZN50ApgBRWuB12V4ESXDJtY3WAYnbsZ
eUBkzdSECt5qjsP7LOtJoCiRRiVETZUruKOlxrdXufxhRqQIRUk7DtLDU3Ljg3gAADtli+uCKIYj
rg0CUO65AlAiBNtGgvYhLoIHOEsHGNMbvVVaW2MQWN0aDsDwTdBqC+AEEiK0GdBiBsLBfuJj+T8/
+0I6hg7Fy5AV1lGJRHJj5scNYzBPGAdtRVAxdAGoHCKIiQqG/W2rm4xoGEa29IhlANQbtcExAueF
boL1zGdmeX2aLCMQpYMLEQVzZOlO054SZBuJZE5QISTUZGFaG75BUDeO154u3g4YFhVhjbvqm2KA
lw2CSLGGgDACkSNqKFqJg0wr/VaQU7WDWrf4/q4pd2IMoTvD2yq+GiJLSRKC90LxiD6FboO5XUNK
oarCAoMMpxPL0MVhyKsQAKzmMKkSA9ABBAuRqBc7CamAJdsJdp3nsfvGpKoJPFvH/q5G+5AOglKa
cDy9XaFrJ6gdOI6xoYS7dwJtABSi0TU5K0jroWmpNpXW2m3GvBhEiPt+DWtrzRLBM8p3hEWjCMfA
CBVqNxKDneGtDZt1MsYAgoIuK4o3feSRJN6fD+4FY3Z2t15fPjYwLGCoL0FBBeUQNg8Zb8/lmGwA
BqFjkWvFxdVGc+uTIkX3BRlZqEFUMOFSQfMDWwbEIQZQZZTikvVDui0pjtVtEPKDHlUB2ou1crEr
Hk6M4vpkCoAvLOfXv/J/t/L/ACcRIstgUCEDaJBx1ndExE3ChkI5opjvxTRCgBGHcRvcPcZ8NBdW
X45qKBD0yISxf1kQWyiQ1sxI4ccHJP7LQSAwbXHHWQLKoCPH2OJtraKkRrUjm2yZPzYw6MZLP+36
KbCWysab4a07WF7zf8JnalGaCqwgq7ApJzADoUbRaAxkcEYeLikKqvUFADYjyVm32g9LrSCNWpOy
DinF5MRyDeAqVrEBD6VQd/NGCsZSi2os9AlBXB1TKBJ5ZhGFarQJuQTAZX/jA4+v5P8AFiMHZp43
rxkgYR80RkaVgrwOwiwELPDoAQASaDTp+pAFUYEizELAECJCIOsE6nZBl1wBoTmm02kuXRwBiEnu
nEbmBqZyo7dgO6PMg1eDcYJg7iFSYjg0Og9W4AY2CRMoEX8kVQiWblmCBTQf2Wkn9x+Qf4xobZBr
eHx9ckmzVdNnHn9fwamIoIfmj6KMC4PQgggm+8y1MJzJDSCN4KUKJkQQnWmy1G8aU5FnwLggsIiK
hQVkjQjSOTgRha8kZI58qUoKbiuDSZKHsXUBse0kpQagUw4+v5P8qgCLWxIoPhTprIl6tKJSaDjT
KQeiGchbbDTFpwum3TWUqEynIOidbiYWhNdEIPCRxH03kEmOBLRRZ0rqMrN5RsUPplAEcTjwgkEH
hHJrFAABcoYhY1XMaYHFEISzp1LKIEhvBQKAFFCCri7QHIIxE/taE8jx6uAhLL1wHao0ToCA5sbQ
7/xshJooIDhmOcEiJMgg4EohMQP4QZWRNKCVggVuBq4kBKR6pkV3YoOBfiSNKSDuDuuwZQi5ZGEJ
oxgsKRbAK1lSxOJ/uMFxIm6mmy2VsBx9fyf4CR2J7n+sfvbgwBypr3bOy5bQauIBKMBVdgvf+EEi
CPIlH6OCGamWNjs8J9MdMrdFMTqecJ0uEAaRSSAQmIM+bRcUqpmAavxk6NnQAMXytVQxZxpJ0Qob
SwErMImAA4Rwuw06v7TWkNo+w/wV4uu3+I4+v5P8emno9shA2Wl6n4ny4CJACt7gLBDR14b1UAoI
Ox2PvhAxgIBsIi8EeebTFwQUoKum2XcOWQQ6YBwD0A/vR2qJZGEeB3zgKQqSwqKC8xKnZVOX/OpW
g7DA2Qlh9ueNXD0oIQOnQt1/B3rkAp0oqIq2N7W+uaCbEbsjmoDZypau5rBvYeaKMHXl2zWA5DuO
alPgVKGB5mVNstQV4IrHUTyweFxkV2Qnlk8oUkUepqFvvyOKdWArmoLwroJlFIOQrFgqd85IR2ae
x2DUcXOYuj5oyrRKrpybpf1gWjBSHCmyqUQREv8AQCDmqbYbaW37dJ4yAve2lhyHFqCCQnNoOwpV
54rIycugJMUQopiRpF60rUFy1gBEoEiAQdGx19eecCAHAAHYNB9D+85WM1GIIkRlomqdf6ATQjcu
JgC7wAlaFWm0C4Ci4QhOS5KMNJ2tsVR2ra65sy1INmxzXkFRB6A4CS8YIVaJYzje4x3jcptHctur
AmFc7DWggCKfyQTR0MrAhZTgK0ov+RDZ5L/m+/HHn+CW0iPUTWPJUUmycL/QqXH1HZA9UWOi/VyB
RtHgq1VjYaEIvFxDEghswBAAbkJ1nGbZrCk3LtZVR9YqkEGFIlqCNrXXL06msQ0IPTG0h0f9zIIg
HkN+7/AHwrgjhBKE3tI6X+h0UCgcKCnopr6YEi0DZWTR16dGPNuGsVAURjLJKKPoc4tHh1hIYmxQ
6qnWUb4ExFKoFgN2c7ZjoTRamWhKe4dcaAqFMJg/xKCRrA8ZoAYhsgVZNU2igrSqkFWf3/Et1zr1
1/n63wH0OP4aTUpMUpSM5KDPH9DoiRsex29PnXBamrbSjaVOWmM9csgbz4h0Tk9Da8BAChNhXnLC
1ABGwqovFSNG9Le0xOXp0ZgkkbRAGKbkgn40vZGBNOxsnz4G6oFqS3QqxgN2vac5ByJZWUKqv+IZ
aAQdjibPPX95IAcGjtDWnr/mT8FNU0H+9de/8NJKdnJvbhuKnoXvT1n+dorMLRtXlrfPLhssKBo9
ANA0vHnni1GhBoSIXEeoBTBXBSEAwCEvB1kGwjvFkgQaCQAhoAA2ADQYsiKwpW7WpyIE+Ri7dJAg
bvmAhXiQJZ395Z6ldYWn9o21JY8gUE9EA8fxxNTB2KwJ1Gcf0PRea3KI6db1L069tuO0S7BVInEe
3GChBQ7Ch7cZzz/4CMQBRztoYQfSH8ReDjb4O+UIk1Nko4CzI3x/7ZDdMGcehfTgwKmQzaD7O3KS
9PR/HOf/AETXTrZ1Mnc9/Dz5Miciev8AiCEKVGx7b9J56PH8EXKOS0OxEdjnX9DRNCgTwujlxiBA
YYYl52GvL068ZNYPNIQI0OdSDW4XTEKEVVdrt5fhjypoeuqDW0Bu5KpDZVgiMCNAikc4I23JaISn
FQW7OQAAUg6kB91sobl+7ytShxCOdXBSt6GQEUjcX99uUULt2fFUC5LKrD0XWuNloDLb+OKw3YJZ
jn/6uP6+rwfX/wAU7/Hj/HSyl7XeUspe1L7ZtfZx0RUThkMeEHkymTXVO9H539/89e774TRXpCGB
SgplSJAIB9TjuD3QKF8rcxlXHV2amyLR2LW4rtwaFi8rOWr9bfQpgpctiX4RGzyns9DgNmgLzOsr
kBm2J1i6Bdn/ALUHGaHwI93z1X+GU9WO4ME6nY61vPn+7/O0M10gQQMtOo6U9SjYbEZRBdt2rx1r
lwgOUU0IkUE3uJBelAdHl5keWASTicacKgDDZKnTfnwdyGM5SSUDHBMJs61jnNERRyCKi4Wb/JHv
458eudU6nJ1Ou+2v80AkUFXYBl6AB/BJAhteV+HXjPgfJ7/5kjABqdCCxxRG7e65bXa6OvGI2SaX
skR5RV0Kb7kTAADdoh3cNQ9Y3vA9aA1BKBIxnumkDYNogkKPdqqtPtCmaqEqDZjgyHOQEoCZQdfw
l+2wREuCshdKk8IBI4duwEKTMGIjs+OIisZlWHL5zBA7K9S6U4HbOeSg+qSMOdhxrR9Qe5+/v/XO
44VAaIr5xCp8V/mQCII8iCPqOn65tW/m2+pt9VyJCe9aNgP1AD4A4DBgvrY2pQeHI8Rzxs9bYuME
IEVBA1rFWAiXRsgWjamzoiyDT9imWg4qVwIjT4zMJEjJKM0ql4EIgrR5xcY4Ff7uZGDkB8NRuqmE
SXgMxzcNG5DIblbe0ViSULNcnMEkWAcopdcVXBCIQlFwgYcwTROXZGoLQAjA5GQR4wCzLo2gqAmm
xiAl9BV0zzgOY1lFgQKkkiya8I3CeoQQUiRIEZRmNMt/mZ30zfYdY0ICCEhGwSAdCom0cf536NQU
T1Gfd/3/AL/oh0GEHruyp/3gxKgAFINE4Orq37pJLEXkKMZHPDfV1xnxjDYusGwFzKpOFxNwFhjw
wIx5Xb8d4Us7/cuI1QBMArBX6Z8H3/0Hf2+zf34ypwp05eO38aZrklSWyXi79cSKIn1EgCJZeAiC
mzXRLbtRPt6rIAQAoAAVODqQ5RVVf7hPpol4sY9kx6elPe/4P/0xNDNCCAQOB6k29ch2PYyHY9jI
dj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2
PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9
jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYyHY9jIdj2Mh2PYwkCH/Tfxj8
TiMISqF0g10C5wSBN3vu9v284aPB8nj9vOEB7fxeD8DDV4/k8H4FCni+D1fLn2jq/wBvX/eDT4Pk
fBfRw0+D5HwX0cNHh+R8fntnT7XFvR9L9sNXh6/jr7euGjw/J4fb1w1eP4PI93DV4/g8i+rnd6f5
n2v2+nU269T6Pb5q/HvjH7dtfZ/k8X7dtGnx/J4v27a0cWu50O3z734px6Pb5q/b/m8T2c+3fF4n
s4ap0/g8j3chvsvze59++/sXX0/6s0+H5L4c2+TpL7uNHs4aPD8j4PZzi8PP+7439e2HtPyPj89s
4vDz/u+N/Xth7Vz8ji+jgkNTDrfCezgQrUOtyD3P16TfXGy9f4nx/PjOI19LBddpTjZeS4eMJ0Pj
H39c0a6Xs/6Oe55mPQMvm+58nQ0BKrqyu3Zd+3R1kK7DvdrdvX3z7V8T8j4g860/S8H384PPF0/y
k19uvUDZ3y+MNbPBqe1/gAfOIq1CkgC7ASy7wyqAuB44EhaDwvGf/8QAKhEBAAEDBAEDBAMBAQEA
AAAAAREAITFBUWHwkXGBoRDB0fFAseEwIFD/2gAIAQIBAT8QI5fMtoZgAqEZUBp/YhBihCbMZL2Y
vM5pGS+MYyt+fxzT0BMZP2L4nVviv9AGj19wmVe80nMxmdj/AF5z4uPQ4hZJx5GYmrRRFw7ohtfr
880pAYb7MhM+hnzrNaZmkSOqcbNt7oNJ2S2bfR7tb/NfF6dF343v8Xp0Xfje/wAXp0Xfje/xenRd
+N7iYpaETI6Xe/Nalnf/ANPHjx48fee+v0x9575+K69t9ny713Tblt288t/nv1fe+37j22j987xW
qj/hw76tG642dOr78tdn237vzUfs5Ecc31/2/wAFoaG+7nf3/wBttDaPU3p/E3Ijd/bWu07fb/e9
OiXbX76t/wCfT7nyU37Tno363dk4w4+/54abtr2Ufs+eKSnR0jt/PrQ77kSF8iS+bXjNSOhXmDJk
hNkvPFrpThSnaLtEAMMQMt70ZNELpygi6BT7rKFr5gwGJLY4TRlwsLwwFJN4zvGaM7hhFgLBUGJJ
0VpoEHZeEBRFGLJNT1kQWZAQTZjMZLaHMxN3bn19Y5oKIeMF5Dt/XNFubUa+jQ7HxdZtF3vxnRvx
pxMuWu41JhllmLqScQpLXVdtgMzfOb3nMVclMt4ZHG4/bViTThsiSXUF+2dahiESJHXgHET6e8Vs
UHi699ivivi+6/vsV8V8X3X99ivivi+6/vsV+HDhqnfjOJrbKeG6GddzM6NS+uJLhofFjPNba40G
3q1NJmu1x25Ff5o9o+Z3BvnMA0vi6nmlog/XfH3muXYp0V9htvyKNfR1489zG9dnh9x52rs8PvK7
PD7yv0PH7zzX6Hj9560tH95t1ynFa0v6aANeyTtaML6DR6R8NcdwIacc2+K7X3c812zb8fPNfB/D
956zzW3oacY/rHtvXQdvw+K7Lt+HxxUvZx+HxxXL+/tzfT4ruu3PZ5ZbuHiaPc3u/PsWAjEBJLpm
vYVDMTXBbY22Fr/J7qDL1GjDh7R8NT5IiasCvqASwii8NNy0iGUxe9q23ZbRZQkQJEWfY46euLaC
FgEJ2tjNYhnIFQ+AsXo2unckIFgZZ60ISMEzIcsbKAFBvEEQO0fB8xekIJoc3ZjYMhjllEEqwCiD
fQZ4gcrl1gilBbhDwAK6IRm+4DFw2UxeZITKEN7WM41ckWDgLAJCwNtCIvBF0mmIlE5AEJZdtjT0
oSyDDK6TMmGQ9ctKSPhYADlYblkbxeP0HvXrb9B7162+G0ax9/bx8No1j7+3jWBASkkhJJySkkM4
i7HJo0OPw+WuTRocfh8tcmjQ4/D5a5NGhx+Hy1yaNDj8Plrk0aHH4fLXJo0OPw+WuTRocfh8tcmj
Q4/D5a5NGhx+Hy1yaNDj8Plrk0aHH4fLXJo0OPw+WuTRocfh8tcmjQ4/D5a5NGhx+Hy1yaNDj8Pl
rk0aHH4fLXJo0OPw+WuTRocfh8tcmjQ4/D5a5NGhx+Hy1yaNDj8Plrhae10964WntdPeuFp7XT3r
iNPi/D5a4NvY6e9A+xofd01yaNDj8PlrmdNGnT3rk0aHH4fLXJo0OPw+WuTRocfh8tL2HpCDMiMi
wjwpqzKCX1k6wTrkG92EA6JaLIrXCG7EKFmwqbemLN0JIYmS4C9uERVMBZEJVthJkTfapdeBkWkX
qKeUYsEUeQICBkbNR0zjBUlMiJuIw66i3osQwkFpCVzATF3ITdbwtRLBwIkrbaRULYYCn/SbGTY7
fIoi2+KoYWYnnhmIKgnGM0GAg4WWxuNTNruhYMLAh7AAIlbTg9lGOeBSs3X+LgYaA24NHb8m1oFy
UhIknGJZbQTEkEHwHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A
+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3w
HxfeeX2+A+L7zy+3wHxfeeX2+A+L7zy+3wHxfeeX25L3NnTqX2671+XiOu9fl4jrvX5eI671+XiO
u9fl4jrvX5eI671+XiOu9fl4jrvX5eI671+XiOu9fl4jrvX5eIWRIYULcJ5gS6kLbEKjk23kQTYQ
SEMRcYavHWIMewkyaiJQLVZQlJAkK2Gl8Smml1WEQwDZGHHHNJtMlT/oiQBgEsU5U7jTdqAEFJbz
EGH2rfGoEUCwWMzneJZuvAi9oDmfDSGoBSwGVIzvpzNMSE4bwiuLBCAoRpZyVcoAZaVYYgAUGeqB
5AjIyYAIwQysGAQQREtDIEl4aRs2nKpMYq47rvXeetu9d562713nrbvXeetu9d562713nrbvXeet
u9d562713nrbvXeetu9d562713nrbvXeetu9d562713nrbvXeetu9d562713nrbvXeetu9d56271
3nrbvXeetu9d562mIhEYMl9zc0mNYmuX2c8Fcvs54K5fZzwVy+zngrl9nPBXL7OeCuX2c8Fcvs54
K5fZzwVy+zngrl9nPBXL7OeCpaNXTEhdfZ7NC1GeGVEuwvHmona6QmCXbADFKPB0OZgjQNL8LTA0
BYAxcmI1WmYGS8wR/wC5JZIAXFSVuSQ8BvaOTAokFYMyKDyIggYSGzoyj0n5ifC14wnCRABmDMN5
PcVDGVO0RmKcrXrJSdYGRb9RjUkxRaIDhFwcDHE1HnGbfwjUkAwwbheCYpFAlWCCF0GzPiloFC8R
CzIgPzvxQxQzbkEDLDN3e16MTG8FLAiTLayYl0GlMrc0l0fXXQi5p/EQcg+tQbHgpKpYxgJcOC3U
EApDgIo8ZKkj2nCGQy6TMYToKGhkGx4Kg2PBUGx4Kg2PBUGx4Kg2PBUGx4Kg2PBSQSiUGEAFMKCg
5BQy0QoEHYSXjmc3vFt7tS0M0TUpMpmxCbMc03bTChQKyJabrMAJpPZSWsrGmbxoTQNOQca6wyUC
HqCakNBWyrBnlGZgooZXLYTzZzj1fLIvfZaI+GhDPTVLhcXUskDBmSARwOFD4Z3NxBZrsUdQAGCx
BUMillO8dKXF5TJk5pykdgFHAQAAQAAAwAsAWAsFRZqG9IADYRJMSrIzBumZm1RFNNtRBxhZCCBB
JK4ikVcSiQyCQKescAoFFZkokZF0hMBUucRi2YMJYmAmZiu/1+f7pAjZGEJGuiJJEKCGLACmDQTI
JP8AB8mlCGlFEAguikhdCnU6DhnWEfk1UqtucIGCQ0gKAqLsyxUKRICuUoa3f/v69bd/+/r1t3/7
+vW3f/v69bd/+/r1t3/7+vW3f/v69bd/+/r1tK8b4ETqsRG6c15YvJgdzhtSAw0NoMVpi4gvkqQH
vkrDwAEYgqPoKkboGSaEJDK0NKPQI3fuQBMxQtRCmBKhRCQYl7aNDAkaz4hLKDF/EFJECiwMCCQP
WN1WgwywKFlCTkrVK4bFnR2C7EJdEv0gfTB9IbRA1bHBOSGSHQna9KQfoLQIEMBFAsBsRoEyGsCC
FC3GHNAythIiAKGSybgFIRUmkCwUgySJxcGSLgyIIYmCxaxxiI86qsGVAjZWEIGuqpJUIyE0dGHm
4oEiPD+Ao8BcXgiDaQFZEte4iBDMCgwkJunCMgR0INCWRl0kpQrpIaSlkLe5xbcAZXENlKnTnbI+
lIKaEyQjSoWRUlQgAhK4ADn0LskFxpHpv41nLBseCtgf1+K7T/tdp/2i10k0wSKEZFJARlo0+yzJ
IKTQSBOivq5pK6q5G76zf6IAk4Sy2QQyYtqujR2oF/wuoAIQIuzZ9SC+q+MB7UTJBYHQSJ2JCvwh
ERgW3IrGhRlDuCIkSSiaQtyYNVCXGZwnZCQyD71c5DEtcyoUuFH6YPpAIsMfCJ8lHROMnASMoGJJ
ZtIyVLIKjlZKYSWTOrEgMILYCHa0CaW+VV01YCiZM3kFpiUt0hIsRm/b49f4apnEEDCiEeS9Lsqt
iV2CIJZWgigRjW9I6b2zosFKiE3CYxoMTHtaIl95F2yAErpzvzUIOoBKkAkrDeNVG9DiDBEqD4iE
S0BgCS0UjD7bYj0be3FGuTMGY9D/AOFq1b+rxAM05kTCGlqxmZvPN/b6SXMAIssFneh1DuBlrRLE
2IjWEZBUDLvo3yQ1AhYFMxHnkk9hazQB0ZLxamcSZqZvMoOeyBMJxqAtaCNGnAhD/wCBORImD6Qj
AIlbwZEBUi10k1pefwLSArjhURJvCys3LUhGNEk3n1bVcGR5LXgLkblszDdKUqAiChCY0AACA4BU
GUGTEk3JEbXDj+LLvUsRLG0sb/3UvTDIpxIJDSEmjVwZTISySgOSTgtLRIgQoFVUUVUKjdUORlWn
IPUr/fof+WkCm3S+aZllAgqcLoxKtf6AgwQ5EeEz7U8rAwQIkggkN0iJtdowk7CbyqScCBKSypQc
06JteBdfuAIKJ7JyksrA0RSvlkGyaYuNNCkhhQPbwpwXSaBQrAQmYaf9RRdeM4PpCgrAMgBCyyJE
8M4oK8uz4LwDAUyUKSbgdAy6IWAQ5WZoJdFBslDNoQTD1JzTkTgzDKxLMJ0jX3JwNPaJDCLt5mkB
WgxdAES4BN1QArhEkwEn+bUvryALN4i5ENkmARhAhBCEIGwcnzc3gnB9EERBHIkj6jUa2NpgoeEE
dDXsXsD1Kg9ZINRcpKKjMc6xL8SGMefAERXKRYhgzADvaWClQQEsmCjW3bikBOaFD1DEh94Oe9pq
kxAEYSWREEOVpTQmrN3DppuOoTNztcxGiSVExVK7ofpIJCCORJPDQUYohBR2iWcTFYsFWd5iyfaG
ItnGDg9BFMisyZAiR0lUcJ8yiAozgDbZEoIx+lO5y01mEMAyWo6IFXAX9SY1EExUkxDURLcCJPQM
qcg1FjtWyJUHFYBODG015MEE0CCJCeXCVL/+T9eGNokmiTQ73vQCMi7bfP8AB4+l2wDxEaZ5tFTs
SEB0hAJgV0CtopgBKsJAcKAYCY4FAm+FgFgIDCLkrTKSsmSXGiS+oVLKy3s2G65JLocRBIygUSjC
RYkByLEHGQnhZTUlUEgnGcbfVVyzgvsEB7Fjj6hTMIISyQiw6W1/S/SJgUPm+oJZIEIAJQd5bDmB
gaR6tHLQIQhA5SwZYCnJZQFCRXdRJqUyICNiEgFSWZWEQTkCybXEuc5W/S1OhUQKYPHfiCEJdapX
OTpYIdQp9gUaKEsDhRhjKRtQVWntITLisxLUaFyal07ICs66HSCQhbFkLN8/rum2QoVOsCiIAFCh
MP4pGYn6/wAhtEyWEyYnnWlVvciUKEJJidG0yUDQ7ICThSbvQWRlsQxGF4D7WWwgmKiERAAEDAEE
WAF7AaSU7U2mhsYLuhxOT3oACxBYI5m1rqvrelQCkLa7Z1+/4rV9D+3/AM8xAuEgBNcWqBGIowuY
ukLgQIZQIQGUAF0ADn0SwmUCGNOauWcCqHJFei2rB2KSRAV2FLop4R2cJYu/0kIjA08JWlUXysnD
B5SylkUc26LthuubxJi+4NjNP81XqyPt8XMZja2gACo4JK5yKA7Ut/TE4EH1DlofxFWol8rEsyMg
XBFBCabmWBIyMClDYy2+lxZBYYTJOYcmDG1ZVbrl1fVzRIgTmFJ9Y+pBIIve6i+7d5+rZB0XJRCi
ohtLdmL4vRlihED4GcaRhzqS4Jcs5E5/CVFqM1tjE2rdZy9FovXsiyTyjKbqUQDWAYjvhzrZJNAT
MA8ZoTkIUqqO1LSbJiRxJRCSmd4966xlV8DFCKQ134i96VMnlH8ufpj8kc3MQesSxtLQoyMJcTI7
0SYiyTuJIJBq0EkVEMemALgKAoq4FUkNjtTSCAYzE3aCiRNhKEArsDBauJCrguZXbTGRSTu2iZID
VzEBYY6hQC5iTMtG4ZVyiRkRIkEFVMaVxtsMLo4kwAH0wfSAlPWrP2LMBAm121pbsxMMUlwrcDKQ
VkJ+XlIzYKSIYdsIskIMFENAWsFZLEDkykDUyHDkJFwskGgtevCaKpHEWYHNcAVIglPFwgZpFXIo
d6N9LDik8YgtGu7jPKkpB8HxTJOG7WVmGdEtllfyh/wPwtBKGJYnETRgsudV2z5c8GlKhmbCMzMl
B4RnEd3QEpfCmtLcmbYc4v8ARbyuZilIogfUuZAkBUwfAJyNy2YWMHozY01FB6WQ1dzazlEqJ8Ym
lQMsFk7BCUaiwzerUruWlGw7DYwRCspg+kClxh3KjUsgEkIggjhnSjB2N6hIJCCkYRJSS8lIJg5l
SToSSUOFQ4ChCKJItjiRzi3ophaSfRoBIYLwUFQbWoo/YKjB3WYNgUgoPJGEVzSTN4tfRiVMF0pQ
EViocJwCwkVtKEYC0D1aQLmtxxhMWoKiMMIAKRRkGWWABRH+UPULvAf3QlAlLxiagqJEBpLGwkOR
e6lCjIomEYT3KS+O4VIO2JFEnWEiEJZdKJtIqmC23tHmzhQHwCEXNUa0NkJwYnUtggORmYgAIGVN
cIMyZucLGC1H1nD00RwaE4jxrE3RLZQpVni0+LnwfSISlha9yL8Q8UMoBHkABdwES7RTTBMEoGcm
YSTecwwykJG6JLMQc4gtbbj6ZtmdN6kWZoWksB2+ttsXWR4iVKLdaEWpLRCJ0S3bI2mnUTCJrAYX
+jFFKVGCCxBf5ilMceWKoQERByiGpupP/lP6Pz+j+/0lxNtv+WD6QBIbin9lS0jOTEAbTayCWbsC
NINLQlQBAW8WNy1NKECkBKoXX2vv8KiENhbgNBrBBhFGZpRECe5hspCMWhWFoIRFI3AsIxHGoRG3
85TaLGJa2ImbHjivEi4mePWCd4Nj/oq5ZwX2CA9ixx9YqWxQRiRAkwmG8selJBlvWDRaYKyOZp6I
QEYCGzDbRz4oShBAFy0xKwDMXRYVZpi+gCRRMpF2pgbUHHuKkNI3xGx0bM1LCfBAlDS8gNgWyBb2
cl5K0SgGIOFUtlljPbZMrxGJJmmmPYZMQhXFRG1LhlHdSiyg42lq3op1N05U7UyvOAjiLGfx4xXs
SeUCwySiRR/72pTm5b3IERgQkKuMI69E9Y4MsyWkbQiGQB6KklXLKTlg2EkHJNbFlSAdQWyQOIAI
2sY4/wC0m55/g2f6R8+SnMReP4FqXD2RrZJQhRXtOCEkEuQAtIxBuFi9QSCQdIAkG8KSrEI0E0gm
CeQBDKQUlAWbEhMKhmolZvlVzLMqt6kSYkktuD9pSoWINx4j1BnN90g1LOLGER6hwf8AOpC2IlsT
iXExeJ2okCzAYZJ1hlknDLP075x/0GdIvEfSTQRsSRlkfwNoAbDRBMpkQgSxAqCyYamqHAYixY15
q8QAgSdWgJRFWuRa1ahYGFF3kgyULCpRNdIUjYBHskjSpsICGZPTDQT/ADNXIDCJY8A+30EkBgIA
uhEEOMg5P4FpAulAMohTUVGr4NBC4QgYBb/Otx+bNVoiwVM6C9KoAMkEhgMSEIgIwTA1I2pr1hEJ
gswKczMRUsiLw8gq4jEdcrJKHhUvfpUmnxEDAoLdriv+aqW0O/EyUDbsb/y5kF0bFCYi5eUunNBB
Bgsf9iCxvKwt9NPGn2+hGUGHJBhHG+ogjkSS/wDAtCgbJOU4xNSgoaEhOECKBbMstSSLKorjsQCJ
yVjkJm3oizgQBgAsFIZAGFkgSEElVXe83sXxt8ZoBoABNjDHTrVwQgDbRAUPfCBIwIhOoFQALCsB
LDy4ACBgAD/iwIEACK1gY+IbyVIguBbCkmXJr/2uROCwQxQiVdtY0+v0bPE13R9tsQaf94rN4cJC
N1okYbmqM0hSAcQWyvVi9ibxSJDoAmXflBSRKgLV+9MqUqIlzLi2VqPABb0DHAg4pESB0aES2SZR
JwjJD4FESeizBAGxJvmiZcRYtknh/wCe73yf99UFCksgLFVQbTLcTT6bZpNvJxJuKa/wOREC0AWY
ASu65+HfSgkqt27Ou/4+kgVBoSDscCrGbbS1CwAOhjvpba31hhxZno43AeZUSC/QugvYF1tky2My
yEQJVFNcMXMGwYTAw/8AtQRChIFYtAwYvrFACKYQS8xCiF+OcIrqSYYuJ4krR0Ez7QNvftq9b9HH
JQjj/lCCISYxbfAErfGt7/QDAka3FCSawlNkHJ/AZCTCACQSBHnk5C9R4JCAdLGid11qEZCCt1RT
fZFm4A4KKFtlmIJBFVyssq6spcVATlWd7ys3dS+SnWRc1V5GBZ5Tc3IAtbwghWncFWMTGCcVbWrd
pavzd7O+ogyQFKisrphyNkLYDFEUOxBhA+mICVgSrvPIBKmedK4hLRqiWRekTMAkEaB/63DWNdtf
H/cvcubl9Y/u3r9Iy8TBZGWjkXAyIwv0RmCMQR/2g2PFQ2FAi04g22bmukxQESKaJbxeUZks8RRM
wWxiypfSDONXF6zBbWXf/Km/ShAL54MBmXA6IiAHtxhFVHslX67xmS5vD+UamBINdzApTm935+hK
RYZ3azD2/s/vWB6H9f8AaAN+xNPwoZiRZKo6oQ0WYIoChgCnD0JxsAEiSmFabXECmFMtiwSXWg2i
YGG1whEkmRWSCzBhCwFpkJVB4tI8UAA6MbiCVCBgs0Zn/p2v1CJQlgliVwG67f8AcUIOWBWRh0vf
+qEcI+jNS/fzj9jmlc+b33+3/sNmZzc0zb7WpnVfKIEENIa0IhghTiFR8WAhnIV7uEqlmIckIEJA
QK0CJofAiSbEiScsTJKpFmiQXkkYojCXUggSJFDVDNJBFJiacaxYmUgNATpS6D1IJS60nWG6CKKV
zrEwAucnjXqJQwRZ35c9qjo0IAfwgIKbdyHWQM5yBdAzRkVUkhjP+3/jnyohF2JW30Udxsf9RREU
TCWT0ahRTaAxABDSIpjKVJm6toVJiRbXDZoeDIUAoGmQsrhlb5afE+EGRsLRLItNyDRcWIoLIIVQ
WNdKJNw2Nh8zlwqa0Irl3Is1AsgMAES1VliAfim0pRqJhaC4QeOpBIM2INXlikjfJEgDrLJMNrhl
AoWmpjCmbVRJIEyeKCo9aGOkM3kIHWysWwqIVmrbKWAfaCCrt/3YjRqyZaqwOKdPkGKu9K65yIgc
M7c8i9xQqCSZCgd8KcpC5tYhBjURay95AmQ7EsY0khjklj0l9f8AuR6VCTMWZ5/FOX37Hdq+I/o/
7mYnbS21nfV4ncEBYJcoZsPkA9ANKdAUGyogZJJgRLLewiFXesynmGHe2DS15qMLMcjwZD+HtUgj
CYoQcDIAhck0S0K0CZA5rG/mUsxIDeWlgD1miTReNdW+E5gljZXf+Aoo5EvcuRMNpDDkQTH0S1Ui
JSRERSFEURsi1YiYYCBscZuioi0jmwDszuV3BBVSqaV8oABYqFREKsSrcysKM4GawgAH8xVS8Rh9
9XJvei0k4ehHMIufoFcDiJJzP+dmus/HP97NdZ+Of72aAsAzgj+hvQVwOIknM/52a6z8c/3s11n4
5/vZrrPxz/ezQFgGZgjaND/P/kOEpNRKsgzeQgDuBY2LFS7vnux4qXd7+jxUu739Hipd3v6PFS7v
f0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v
6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739
Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+j
xUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4qXd7+jxUu739Hipd3v6PFS7vf0eKl3e/o8VLu9/R4
qQT6+NHx/lEwtCZcKAXAssxPN620LQ5C32399yk/yXw4vz7wWxR3d+xXw3V1DsRg4MffP2cE/AfB
xx8MaUa+jgGI4du3nuelj55rDDYsxOzFsc49YWLJayu++2q2OOa/cutuxXxPxfb2Couhg0GpP+Fd
22/HxxXcdvw8cVth+Q+2P0UeM0duO3sxtX+TvnPjxOld220v/FtqvWzd0Pjg1aI5kx0hseCu592P
Ff5W6cuPE6Vis4x/aqLfBq7Y+OatYMXGpx/p7c1/kiOgfPseM2bbnB7+5XxPhH47eTwPRO3YK+F6
Dj8YKOifDj+4wVwX+XD+x2KJgknT0+UaeHas/eLjw6KkR62aZp1ej0dvEd9ndjYT07eieNrRHut0
Nd/aH/RiNuB2agt/mRqcTX0r9PNuG3Gu5TPIMRodseOf7mM2o1PyY/2xT6XE/wCRxpvR6bGvT/Hz
xTYFrQWC6ZHradoo/p/Z7xn0o6tp0IrzghAKQbo1IR68W/N9/So5DqYAREAuBJY9Mn//xAArEAEA
AgEBBgUFAQEBAAAAAAABABEhMRBBUWFx8IGRobHRIEBQwfEw4WD/2gAIAQEAAT8Qyh8bR7B6yMoW
qIIxq0VFBTarle9YK3bTdCLibrPdDJsAf8ddq1IkefMCBpqdU9j3e+dyj0HB9Jpjbs6vgPL/ALWl
P1X2HYzTX6/p7+1au8P1PcmtbsaC+hNcGayH694ml+L8btPHSvGXwwe3l/j1JUY8uXLoX7Mpjf8A
hbLfH3Z3VsthNJbsnt0nE8m/b6NOkuP+85N/4fufH6oMGDBglGSep9V06dOnQ256/wDVsq8q6/rW
2n3s0eMXUutvl/zOP5B+/wDnNmzZs2bNmzZo+/4V6w4RTSfT239oJvOnse24ncuS/tNePpocc/1N
fHp8/GvN4Yntb/cuJ6zWvAsrxedfKaLzkPfW3TQb0Xv43CaGtdH7uaHei8cs9Z7IfmetXNLPTU83
E+eO1eeWqgtG2/VruVYNOgGsL4g0TYLCsMvQTIv7oYQu+KXZ1ktRGzW3khaEMO8dbIJlLVWb7Dem
oXXB2XvV8nzrXY9rueACpfdcU1sJhFr/ACpA2QaGwiTUhQlY1Q/w6Hl55qFi4lOiBeBq8pMpGYtp
wQjutMyjI4JHjrLJnMiqVC4CNBwInDKN0tDlSPrDIIpTma3XAtWiBQ+xgP2SQqBlPLSmD1v6ASUM
F0S5bd0I2/zwEWegzyeVSDBsi3lfr5M5KWihlDo7c94NGXZGLXQIIlvEBSiQxUbrErJQE4pGFmHE
ZhoB3Ed6qtaigFkLueAfuHBM7Kl8T2jNlXJbl2U6xHWgAEPlGGr4o8NMM+mtiWqpcW2pDnFciZII
pjHJQPCc1fHpz5d5pbVPWn3n8n5S3i+bso4HkT+Y+J/MfE7E/UANDx37AtqAObx+OEo4HlLMunvO
V6vzsE6ebHErXnv+IHfn2lG79++0TQnK9T5gm6uuIE1z1+P7Bbj9EtenfWdLzlt6e/xAHXjKHUuV
fhf6g91PInhePxctvT3+J1nvlU5Xq/MANCvoBdJzP9/fpFCmtcCcr2lt6e/xOlOkd8rnV6f9nV6Q
O9vl3/yAGhXe/j47HN44em/9OIlnHiV/HvfDRH0B7E4I3bit3LnxrOuJxV4vnX/niHfjw8PPnN2B
5KZ8Kr+cWZNW7N6ePt4TIy+b/vjx57+IOmN/jfXhyhNFOi+fzxrfvVUsYMp87vHDwiogl3sYFQz6
OZFerBkQbZsNpQ2enWua7/iVRkoehgYy87rrEEAWVpVw9RkNOqsgojHXCIrEO9KMy1GfUFWo2S8A
DhTLWNgb2qKCyOd502dpNaC1Wxc3BPPvx1qQad6ynkmaA2WFyDojpShnBVfsGcStdbXwpeqLUac7
lgG4YAMH8H3UsssaOECPydxeh3dq6CvohUmVilKAY1cU+wAgc9pgATk6Rk9cAaTgHgy8wG1oHDly
hKMVer9oxcKst++YCAOZAmToTiaNOYq4GZG4axg1mSCiwgUJVFH0ls3vLVhDYBuHtoGj+OlgGHiI
WoR7vZTxdA/vheqBmgghxWZLUOCITJUEmJawwHvpCI5AXKRW2VzLJSBOqyrolCjEAiMOWBNcz0Vk
AzAlNc0e+HVym7m9+zqeueHH/kU1p60+8W8XzdtvF83ZRwPIlHA8jYC6TmfSANL8YJ5HF7/5zleL
ADBsBfnhNPoG3V17uBNcu0brjrr5fyB4W+fpKdKb4Vss3Qe9DvvfOr0/7ADTaC6E5XqTkPlNxT3z
0nSl+JA78+ko3fv32U8HyYJ5dSW3P6+Z1ekpvf18yvF9PiV4vp8SvPvwnK9X5leHvOV6vzKa0141
AdFO3L2n9x8wDQB0x7QU0U6Ke0DvTvLvrOuIvF5vy/vfzoLWHRThw66Q9Cmdz09cvZErrdlz+ljz
78N3qG//AJ3y2SVPsTBbgeWFsQ1gSr8pAixGAMbqud691x9sM38Y0MPWXTTfKQXEVtuBVYy3pg1n
Ml2zutZwOdOXcQN1/LqNSCTuPRcFMTtaEVWk8bj9h4jUGmA9Dm/e4Onq5/LHl+42QY3vx4czR39J
QVEpaGLpAGrIo3iDpUxrQCIJzCCHiz+dUlIViREIGtQh0gOBw3rAaBMcqrUPGMqkqAQoaK+gsPpk
NMQrJSCqxscjFhuWAEQOI0zCbhU7xiojpBBTA0XdM7sFUaGpwNx7nuauLFhWBSkVguJgzGuZRBRA
IdSKl3hzvoECmtJJzUVXPJyirGdID1ENF6tYMZnicrW5t9pgYg7KEO7rxlTNjUYuVQQQXZZYrOQe
guA+nlbMtRtwJMjUwxFvQ0F4nccOMLAO1Ad9Vy76rIQEyYoJ3ou3ON67CINkmdDkDcPBSMqtqO9S
q+P+jdzmNS6jp06rLTerIcP6fE+uHBtrV68Le9UivQYDeJ2cHvtpEgZ07f8AdAdOrl+qLFixas3q
+B7+MA08mf8APn/Ln/Ln/Pn/AD5/y5l+auRef58eb+H6mA6Rf8qf8qf8qZv38BsTfyZfzY/zY/w4
/wAPYgf4cf4f0Ju4ONEPSvtJpC6B7QBo92Ch6vEDryHsKm9k8fYx3Yd3pN0i7yPwnW13ZXp4uGL8
8kt3ys8ilQtpi7uuU1A9dW4Z5/W+U1ab8j5d7w84rvOZbua3xL53AA4IuItMXJQlIDjsPj+ndk17
w63w0eEc3Pf0+26BOt19LdmPQeJQvTR4f8hvvDgCxebu17QP1RoZKBP4r+2c4m8b7oA5h1XYIERQ
yi0hDeLXS1umUM2HtE44nD8s77FJVysFMJ2XksukVXYJcVg/kKJp5tZFpXjhrJk39yAElzxQgRAE
V3wsLxE7aCgSIVWO7b86cozUxIdq4M5Z+Da5rmNDJ258yXtMMiCgNGjYQqEF8KE3Sq0w+I2YH/CU
9xXWhrqjCpdvElXi1FWGzJ1sqgKzDTzV4Nq8tMRPzEOfdETPwgECjo8KtSfBgLPyuAGyRWbvgV0Q
UoglOWWonPcBtJOJo3pVzT/HpJ6N+nU2bN9mLmjOWFuM3T+U4cOHDhw4cOHDhw4cOHDhw4cOHDhw
4cOHDhw4cOHDhw4cOHDhw4cOHCdO4cC5d9Yie8Xat9AnTp12sdbqs1mqwWap/iGXDhw4cOHAoxsQ
XipAAiKCCZIwEF7SwZ4W0vNOaaptJU4STPQEQssOoLdJ66XJGERyALy10lSObwZK30fUSRr8xhgI
UDq5CWLJe9aybod1cknLhIjIk5eGtZCngscp7B8B0w1CpCzSt5BO345SuMcUIIk4hVbMFBauGClL
qqoWFiFH4yBsPP0VZqv+6O23abc6Je9UcmwyM29J60zvbzFCaqz/AK5MitMfSwbFyQtjXKb9/Xh8
7tgq15tmOgDI23svbFgHiZIYt6kOA4IimXu/Gps/65s/65s/65s/65s/65s/65s/65s/65s/65WG
LXKDo6NvbT/w4ilNAFs5jSD7na7SlgihwVLQfpRinalF9qF9aSLWFYBCFOJadZZutOFgBL3v9UsB
DUqpvHozFUOpQIBYy/GnRppMAIZtj6HSrd3H98bgKkYIN0KKTrXRKezHwy+rMXkangMgvICVpS5P
INw1nKP0HPMSRoFdOH6lzoW2w5HjEdXQFFZhWOBQFDIv2a1oOK4ungxQTOPE5x1lOvQnjCVUPigq
jBWq0kmxvJ5iSYDQXf8ABHUjQQu9yJKzYUAhRSEgvFYMAS3YQ688rUBeDPhMLUSGwIkYGg5atk7I
oMMokOPi4xZdKlcYaVanggjgXGCoVqISgJy4tWgBioLrK3LK4c2RB1I+hd+/f5B8CzjJXXFpbgtQ
/wDDDx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx
48ePHjx48lYuN9nmV4onTKKsIALT043A7zg1TkFh1HAV9yc82ydbvEUYjzFIHIagCVXuZcosoa/K
OGVFq4GizKGiuW0Jbwo7SkIfc09z/rqBgb1o+exBW/kxGnGftMnlwKTWsxWon4sF+PUE8skLhRBS
Fhs5A0YSYLeKitmoxWZIJKxdTwZhlBYGRQxOvDLqVz0mK8kSovOEgeCHm0X9HdqHDDiQgx7wPYej
zRE9ustCAZwGwAZKqpfTY56bP6LSnIr+ITPY0dBQtqPJ+kBoFBQA8/L5YFhacEkNekfItccvrL36
uAqYfTRwscr1XS4OtR1dJ95VwkAZmW+jRFXHbpG0YouG+rkWGJjBqvC0E7X/ADO1/wAztf8AMvuF
4lU6NTl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8T
l+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl
+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8Tl+j8TmpzU5qc
1OanNTmpzU5qc1OanNTmpzU5qc1OanNTmpzU5qc1OanNTmpzUNBwKbbpOt299L0zC1AMTzSTjPKk
oZh+bN9XSCK1LlFMXQdqlZXcPrbOxPNfmEsUNG1OEasVvw2j7Z/qxMUM0B5cheCy0IO/FdESaeUe
AoxSDobagczEdxB9WBlq27G72aMXXNgKUpwKs3qOQHCBN1sIwMAKjUlHoN/KlHNQML5SpFac60Aw
0bFVFi7iift2UKU76nZjlWxdAZGFJEC2r1SWs9TO9gEUJWFTOKoUsALHR7FptqeaALBHpfIZ1soy
g8bBFZPYCS4xnctk6YCDrONUZSl1zCDBALpJVbZLUEeKreBj1swpiQKthRYLIu/UcJJfzU7K28ar
o7H4oATsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdl
TsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqdlTsqcxBzEHMQcxBzEHMQcxBzEHMQcxBz
EHMQcxBzEHMQcxBzEHMQcxBzEHMQcxBzEHMQcxBzEFLAoSjmZXrvzDJ6/Nwmd/O4mUUBS2GbC7Mp
S8k/G5BgcULG07l4YmrFnZOxU9A82uhTY5CjZ7aWUdf0EiNVklUeB3gGXYQjacWPoqzvUiJVPru4
CaQgdMUJou0gIU067cq9MQSJBbLlXpVKGD6vBKaVQBUMgIJFmpHM1NB8X89+NUgW0NpQAph4iBeQ
KACNCIVtJhgmCgZR84AinODFHT8Qe8E8Jus3AagZHBwKbwvLwWisdYxrwh4dPWZLeTLQFKpL/URI
E2dwHhc4JTBIaqkAQvvJ8OVwuEymGcF7AtDvRAQlFSuDAB4gvW6tUZj6CXEqnAUc/wD4tXbt27du
3bt27du3bt27du3bt27du3bt27du3bt27du3bt27du3bt27du5s2bNmzZs2bNmzZs2bNmzZs2bNm
zZswXlVxneBKa31oxcxsqbv25EAURY28voiSTCBQ8/cVm2hRUNcAkxHHIAufx6DXHIOUIjNVgOFY
jADQqpFoHANT8u8bv05wXyeM+C8vWNoICwAg1ku8eltwJVeDqFqUFiKSEwH59+Io7ehInEnugEHg
H+G/fv379+8QZaeQKxzNmEvKQfoNBzJwazBXV43IEsPi6vjDg27qoa3v2HZ71OChCzlSSVQ88/uQ
s0iG0kKs8cwFUWCNEamt2YKP3QIdqY4D+qKZFkMQFIWsrbCa21sAskYZhDu1R1KmpwhFOOTOdaUm
/ViKCN27du3F0J14Tojv1r8HIkSJEiRIkSJEiRIkSJEiRIkSJEiRIkSJEiRIkSOwZODrX7mL/VC2
Zuwa8j/fuCClSpUqVKlSpUqVKlSpUqVKlSpUqULYwIklxj5axAFESugQUNIi3DbVGWP6wWn8K7Nb
nLY4IGsc8G3hGSqXxX3Y5ex5fYlCug1xjsVFIollGNHZOINBjeJuYHqI2W0FqNsT+iCiU9xL4wPj
lm/0yEcPSZqHYrIo6ggnhfkyprgZJMMerxWCbOv5P7l41ZqeRz2c7jRuUAgWolsNnrjN0pAqD46M
ocS0KM4clB1zdKBUYngIsZjtvFCAsdlf4PQFJgPAZhcZAdxqIVgJtkMdUsLymQHhNdWWZIZapyFh
aOlcxyIYNs2KabLpyMijKEKbhL8qVAYhGDMYEG3QaOCIxe9mrxjsJM2VbJ6KOkH31kW0soNZ37gx
WjaJhoB2EBWTE0qMvYrzPnhJWPOYhNSR1I80WORtiQ9faEbXuVEGxL/DQgAVFFdqPK4YQbTjGpxj
U4xqcY1OMYBpfinuv4Xl2ADFrf6jTaZuDmDa+XFvMIh2DXTY0mVauiergUlxjYdZ8cfAYvpzJru9
8jTS6UMyh/a+y+y5OID58cQWqsjlFipFQAgk0MdWIqK7BUozrb2FZGpvKUgC+dJoNMGiKK+QYxW9
5LhAqyXr7mzMT2fzYwRARyY84FL17CwhxyVJ2ysXC10BSWlpbnA8JA8875q0IvnmICsA73/sMjRK
HKXdptjMnPGhXXiYPpWG6GnvauBX94pWOyWQB4MDGw7GwvNjoxZKXeVjJdFgfobLk1BuXyNo15nh
uG+yJqfc23MkNccxFkTkyohqPz9jrvUCLNCOCfE9X1s9h4+coaZ3GymLZLfFNs8F00PU4vHlwGAK
UciLAaBQREb00ju2TsO+Fqp1UNVpbQX4krPBXF9EZc8nXFQAC6FMYA+hNMgg2BofaE3AtmmSwLL8
E33JVuww/wAmkmBgpZRKJYKYAiJXyFmPZVoMRDTV3foEIjRxlWtCVXiqTOHpWAxw9M11id9dd5pu
5Z/uzPRXLX3/AA3LrEBQt2W7yi0RpfcxE23DmldYR/QRnNTmbC17+KuQl6QiAXcrHKl2UvCF9pFW
DgnK/wCzCalAc0OvfvvGbNmzZs2bNmzZs2bNmzZkSyGVkK07KM5cmZnsCdwlooI02I6ZY6hat8rX
SAuOFpOdM+WuQyiZCMsVhwzHR+7eMSy5aPlY1eTlcWLhoI5Yh2ipOWOE1WNNtz1ZM4xThI/c9o60
o+6L+NqvS+KoLFOUztmfSQak0w29aSakTGSzhtC+gIypDSL89X+R40YihLMJPLo3C9B0BmSoH0yO
D4VzueaXyqPxZ/oiBIakuqHNegB4YziEKCuE2u3iM0JLPfQFI6YOWCJH9qZiHzq42BE+2p4bhEAy
PQFRpVImOmJRaR9wJ4FiEqLKLoyZxnl594eu6V/Rr2xgRMjyWjI+RTTtyVKxknQXXQloOB0OTcrP
K2TTb9LeVTW5z43Uhbx3Ag0lUTKAsHVnqSHUGLWizrmLMXGvjYplBW8wv/BV5dVohn7aATRz7ccO
HDhw4cOHDhw4cOHDhw4cOHDh1wQUNOSjCLVEzWF90qyVpv2LIHgNJo3y9iwV3hjEos7CriUeQoUa
upNTjw10Q1lQEFdEj2FhUuBK/wBRqtqoFuXRbgDBQRCKXIBQwLRHbSaAoATWgC5RLGR0t4sk+sSX
N3r3SM7Z25vpmxZiX2FIx/dutSjDjQu+dRWKFd/KODBZslRpU9NoKOKVIRrMmxWLlyYI84KB/o0x
Akg6y5UX49J9kHyEwVw9+siEmOnHxB2YyvviBXl9PJMsCKLGLwMrlpKmPIGpBtKYA4U4MqU7CV6D
UGrAEGVm5ivSgyFbheJLegAmjeeoJPASxwewWik0odHXRNOhEPsAcJC91D5Ei1oiTnXRC2qLHw1k
xXAHBMEjhlmC8JNkH0jkxOmBnD5+B+vy1JbKmaoHXFDumhOjRjOjYusAgGmtmdCEsveJlBHZfVTZ
9bk1qPdI88VNbKLmvT6fHxNBuSOQc/tdlB7tIj9ZpbMvuzyKsBS6foCoxikr4S217Y4pA9VlvZTy
5lUzotsYDashps5BLn/NRkh1NuwB2eDYuy1hS2Tu3O7c7tzu3O7c7tzu3O7c7txbYHr2aEojL4/u
DI7AY/3TxeEsKLyHBvR133y3xsALYKL0r4p4/tZBY0q6CaDRBRsRhGAUVyqwbCGoCwEFEgwE4BOR
ES1TUAAiAQ/HHCsc2pEiVsQaq0rCypcsksIeMkgX4hZopLqVZfb/AKfvTLZq9rTv1uWg0xVoV5uZ
genFZAdpVBMJ9eTFNwalCFf8EZavSW5cSFhuUGVgoY/im3zFWjlRJ3qNShbEZDp8EGx07Cq0QDKK
ScNTd9ORFQ/4X+6KSwhLJtzaAtCX+UiBJv32K7FUrLRqu1Y0qb3pUA7CmeAU9X+VbtI5bjd92/VN
saz5H0AQDnLgHIQ4gIASYa7O+fEfRNTzVbbCjNlToGarhZq2NhOkifm+JG0ORGq6i5ALr7txJIX7
jjQxkbhYV53QeQhCQxESiaklZdFWijnCwQQgKSm3cBWDDA/B2jmEQeYxKnhIBq10iZzpjDQGCVAJ
k4ivpCQgYAkV0ZPhW8iY6srBCiJib7ZpLWSRhcsk+9t6W4LoS6ECF3cHJvoDxuoryqtZkKQtDYjS
gm/OPktKItOsM4UjtYMmNsxqGeMnTpgjY3vMLDcGfwZNuCZuC2qyIG5g5ny+E5ny+E4LvdgM9ax1
nd/U7v6nd/U7v6nd/U7v6nd/U7v6iUKzLrm68v3W+KEWb4JLIFDE2DQWVJnvoXyPXdXnsQasumzq
b5eOKfLoKnatQBJcKYb7y/4AHC14NbyUyvpLED6AY61yXK1VoNnB9JlkDmW2VXZUIEcSEzr6uKHo
KW/GJAJTT9kpL9Krb4BvYiF1jtz27o8D8DoMvlaWEyk4jsfEcf5HhQHTGTVQGHYCYPn+Vwe4JAwU
sydnGHUYxp+3+TnWGgGIEkdSQz3Vgk/p/A6asPBq9+cEk5P2ZAKZU5QrFjDDCoKHVpHRxXWQCzAE
keEwlCOzwEAwwY/hQcAz73XlR6YFlSp7CgWdim4zdNxRdFllAP8Ab6P52TCjQBX2bwUreaWrPGt6
5srPJkou99VfLX9fhRlYxiaKVt8L3CsWHX4UVBiyQtxa0XbiKJLnLdNf1PmobYiXQlwkClcjIQht
RKDYxGpqiKyKsjhwgPTONT1rpRwJXCRWWdg4aFhitMswKrqepUUAIMjKVHU4hbrogLIeKY3rM4o5
JuyDLllSdXSZyzSajeWmjj07LHOe3dPPR89Hz0fPR89Hz0fPR89HUhRVQXLcjVqmjTzl4FYIBVCW
qipbhcyrt+ZiqgUzQFVDA3hIG5Rv6hl4ZUXZm/H4EYbf1OQNgM3LRCfg6ZEFnBdbbynky3wVtnLl
OihT96PYFAoAVEAAtVcAGVcBAwjks7lKOZa555NTLN/uEq2TECTwIFLVdoRG/EyaIrEDBZ40wURr
cEapyxSBkbwG6tFmoJsQbwBNirHWZRchDQyoLkNVF6GAA01Mg1qwYoC0EV2VasWpz7nxiNkyyvyz
HF0Kbrw39OQhhuxoSD6UYKQj4O0AL3pqDJ0DWg0ydSqYqEUOYTqiOr0Rz0xaAdgqH8OM2Cw5PtA7
OmIkSOZwoiQkdxXqvsIopWXPbbloyuWHqBVE36ulGWaoK5NdRA6zLB8bLxT6wGgIxZ9XNOxvnrZk
IIO/p85ttU4ImVNYC93+hCE9Nke2xgGgWK3sLwUpm033VxkbGTxNPDjdR0QKoBaCCQGhBBwdC40I
0QONG+XQo5bTsxMq668nIAptmqwSsMKa8WO/0iMXRB6a6MqzlnZJxksmod4W/QCvVXrj6Mphj7Zn
pKhXgw5IMeOdUv8AjOnGaZ1uq58vjuvIvs0TDKDNdqKcJGee2y+ry7jVr1/pNsjb1i/1BXmAUcAo
IV3rn273enurcTgEDJAkRhFlbU00tI5Ch7W9AMWToQYJhh19ewIOYyTBbziJK3OJ/TQQe/de23CH
G68WUVzkHIqGgTE8fptdyOJTuE+q2sxYGj5twvSi4vj0epbelW3Zfyhr7GdKH8qWrKOfXONgSdxm
To2skWiVazJSR/CT6ZnCArNBa6nPFr65yw2tYVRxRTAxqEMzdPvaqZ+0l2XttsLgernUEi2ZmFqZ
JxObS0BrUYYgb5McteCio+Q5xQs9JA+Zj4Cc5T0bB2U8z98nkok6zaPlUERrRDe110hnAP8AnJCm
rxhpgRwCU1KmAgKCEyHUS3lSq1ljqXAQVDygXWdeM9Q2qaUbI62djIgsyiwExBoo34q2aqbBVsUM
HdDj1ewty1qvwUtOyjugDADuOOTaQqhjoRNRbCA+zqiBI5KfW8R+SzJIUoW1Q8zFS20QgpsCv/vD
tOIi7V/tg1OUVr3OsmBM8sr8BG8XcbtEdWNF8IwgYGKjwn2vUUthFm6lGwtkz4J07z4eh8RsUsZc
VnREgWXDexXdwCovDzncXxqTNWCiwSUysOjvWp8LpCM2KTdWDppAMqIaYc4IANg4a1W2ZT855YhJ
IAIclAyadkkoN5Jy0TuCg3GNBYlMZFw74712gIvoWcxUZ3FrjwxQTLixeOG/hnKEI/kK/wDSwHtC
/wAirREwDyPW4e1aojbI3TsXRSC1Sud6ZxDqs9NheJFQFo5fYVKRNBO+t4HU1s/iqFqTzfs17jGQ
6oE8PWkN/wCAiJpDauEoin3oXD/0w7P12aWJaz2+xFb+oIQkJ3CZAECVZm2PeXrJZYngTBNLoUpV
McIbZCadBEmmAgyn0AH1nv2UiFlJ+D3kdhx9YTy8YK+GjXfRZnzW/ZvU8hRNwsSZgwyxGIgRaKmn
taiYRbnaB2mvWfCUTfLQq6998e11ecWD5iQilsEEXkH6gc+Rdx8oVBJOyvC/y5lwPC7Fx1imsI3Q
KUBjVlfmp5YnASGRmOi4BbJwMVS2Actws0gwKgY8Ro/wbXCClVJeAk5yC+XnCps2EmJzti+/gEBP
gnO9ZA6dW2ifqAPoZzbI/ph6CDxMimYUegz0E9pO/wCcw2E7U4fpULd/u0lmJ8GeFIfyzL+Kf5TD
ODURn/RgtyLTYr+ldXRsdTZUEsfUop95L0ddoDapimsjkpbd1YyqXtTeZZnBP+WdZAkv+bP+jnzo
skKVhOEP8GySkjJCUWG2H0WcXDZG9GPGOqbAyq2Hy6wzl4I93tUEW/yYHcEFINT+cHtSXUBRuVQS
QEO5MztoV3ACd7qw5lN6Zo3m0CCHgbxYDK4GhGZduzCjns/DqdEZzYDTfU/IA+vQiIGe9rN7wrvK
xkuiwMbLhg1zYFETShPzTeWIl9FpN6ITUSbFNkusQmiZPBkcvXKFmS7EcwMFBQ26YxS1uM67dU9V
vmjpNCdkV2LQYKqhoReNC5iYQG2aTgtOXBRYPkFArU6DRD9uXq4DdkdaGdr6fgVc4iWdwpkVs7nc
c+n7fFcY4OI0mVMjurIEZrYl8U8zG2gfKFz1+Xu66WbZbZxlvgSrgRjm6vEpsVhIZ5dVXq0Wcq0S
DDMh4BTC/mnfSBidbFxA3FaaYYj199wQlMvbtRioAuKzlaqeRw8TUt8moVrYCUYdAG9f/QNwuWaX
yqPxZ9CJESiug26GlioScKmPhJgOxq2xcDoWaVbwTc8FHiKOGEh3TTzLpjokkLWBFoL3aEUrUiGx
edwYw4wQoQlZothEiUCFmT0VR99sKZ9nclLbe4+8py5O4tTR7keg2bmrqvU+Qd56ZtarSrkHMQMX
fomwAqp9dVWWYXj2raJ8gUBkc1Gf8hGiAQzJJw4rawqBkTDM6hcx/bhOA5YD8nfM4r9JIqAIgYOG
maFIJm5z0X542vhy8Z71ptL5uPUIwDcn6GFeUzpz97VVdKd2xH8m+6ZOW5rliq+eJ5hC8ioNAoUf
QgYdy9OFeqzxmq8hihr/AGCAZDZ0n9JAE7NIw0d6xWfVbeb0gFTZ3oAdm7BVEbdqkloz9VLdxPDt
2EGX7VlJA8zQEugI6K0SyYH5PNzTaqMaKSxFDtEIWGyuH4yxshu7EWFLVDJ0XgBra4ySwRDZcvYj
KJfqT83cwvFOuovqCQYwvGjyERjUuLjSeiWi23I2LN0ZWffintwDJVmGpgEZWuLzF+Zm8ZUWSc2L
swR5wUD62kJajoIRCAg+3lIotWUKykRgba1pAdiS+0BX8eotg2OZ9q3bePE33hvrOGjKNlWEmm7g
ZFrw7A6B4CM9LeuAmMs0nhCbz+VRfefSAoD1CcATKqDHYoxZ1DT1v0EpRoVSlF1HAYBmvcQmuive
b0aJmHT1yxMpcPIjc43QOuRnMYppE/JKpTX5Yw0o4gBU72aRyZEf6OTJgFD4x7+agGF9jjWqXBkf
piSwMgUsrozysf1Lhnn8li8sRGBgASjFI4JnQE3SicZg3IdcyF7wNvoT8E4XzpLA0ZSRas5Joh0M
1gFqjMGHRBB3lDC/imcUR6AUZUNrpled4qBSL3Ik8BS93W3oRgKUv0SyMm/LE+MUEGSCmfMVOY0f
Lw71EErFwr1UrCrWTfIUEKHgEArnQsEbQiWvRuazf4zc+m07X4AvAJA62yAdXRIFWCEjTe59IZDo
fTvgXrSlhihrOXd22giaN3tg8jHvtC6m0zQDpb02qqhwIkz3Uek7u3BBBcHU66xHMAqLuadJubLA
zFWwp84VTuHLICpjny6t9j21BNeEqQaQpwNzQlq0zDGF/NJFoKiYbt2bFUa8Z7BB7yffpMhv66GS
fL9GqA7SyW3CgZ9iNsk99ZMgXV0/aaWgULuMsfssGzUj4n5nLaDyOJ1wN3EZL3NFXnRWtUdVi2xP
1YTGeTJcHpUXY7jpT9KCxA1WJCCBlvCOhaalgwGgc5QlVVwMtLaVs6gotEv0gSxLxxn3gdyvn2NA
3dMyS2yPuqiJTjyV3G/Ho7JbL/oIyNw01k5yxG8wBKACjPEMhdC4fRUoptlld8xixGyGqsUFtltM
8Npa3gRhyLwY1LtXEobwtWg1YzobnokQA0Sa9nUdbTJv0M4zATQ5LocVBH4mWYL0MOV7OPYuC4pD
LRQiLNr28hptLvQNOzXAcq2Pwy8/WX/NBBi5h15dnnyboEjjea9DkTeodrt/zftXX+yaDoe3+ObU
tMIlwdl0GJNoND7WP5UEklcIL8ToZgI9zHSLgzTCNwP5Yfsg8SO9txH4uizCzyQDWxxhta12hOEm
GdDZPTxD8ExorldjLHCMiHjcIZURqX5JU15b2QKd/wAs6SM2m1VoDqOPk8pHkUo2GrdjjZyTdJB3
iJah6bpMqzzccwS42DYwodkhtt3vx0h4vfedny7TdG8cf2XKYWoPwvGKOaBnjcazYO/TgEMgBttn
CJ5McZVvGwBKaXp/mEP0WyzMmJ5s8LK0VmdQQv3QaDoMRpOqQB8SlIbImk+t2eOdvx0ucsRG0HlE
NAmppWRT2IZB4htdOYVaWqwwEsi1eY+LbALYqgysIQp4ip6RvPfE5M7QaLkW1ISKZrRZ/wDKu9Kg
DXZvOuXednwD7EMkYcaB1qCmhION2yNqlH6Ot8sEhGqhthLSZYrnWtsjGqICLpK1mq1kiV9+WYLH
XHidDKs6bGhECWH1kmKJSKli4UglLoppNcGzSCvzFY4pBuJkKxX141KhET/HNqGnNg4JYZ/SRIMv
Gjw1OukdHowqc5DqntNnJkI529XTPUGVUQNgZ69dijYbYLsCG+gt6Q3YQeITJ9CUh3x8cBMd512Y
VC8ZbVoc2UG6JwrEqVH9XjkSt6f9L5BdOWrq3sCqLYktB5ddqwCy4kdrdQUHEtrop0Df6VLVj81S
G3IW4HzWVImFM/3ilbPLERtL4udkb0HQ9voVjSltIJgrUAEKaDSiVCMg2oYyArBvR+AVmi6k7Q49
kJrH2dMITYuRgIbuw6G6YtKZGN+UxVGM5NUaQPUVzCVzVK+oc8NIpe9gZHPEvTo/iDwM1SRFxsrD
LODf8yARib+C7CEznPRrdd9mppB92K629dg/Zxminiv8lPglgAQ6ula8D/jPNqI1IAJzmNpF5l58
2BwEEh/AOAC3x1xb+F8AT9PgHA3NT54gBHuvBzJhbwZB1jKUr675W2SFUc7v2JayAwRbXuOU0kFZ
koFUz8JH7MLf7jKR8bjucSrjJXKYiQXjto9IKaDhehqp2yVzm6FsklNSzACxCAN1GVumRzEXbEoR
yHq9DmjPRqF1bMekQUk02YSbDMYckGPHOqX/ACrW8ox+TD3B/L+WIjYDyyOkYWAMIO7gs02DwYti
fhn1IlC0Q9VJkQABKmU2zdEnIRsIipTWBS+yFtMZILcjn2SiKNroV/mahcoJiMohFneW+wa/vxNY
AnWMCyGZD+TNqEIYwotUQVGVVNm+2nTy7Wo4eWCwbhJGguLJr1RgQQMCwqMZjlfarQ9vsCPIoxhR
xvulhhUuAr6PI7KWWT2Z/GNF6/RGtD2UPl42ixPk++wn6TBusDjWwxm0vGVVUUKILt/uB83PttHV
lSaysX1BeSpcGCO5VyAqAIYWoCq8xhwGou2lClc3XTm1Ko+6NTWWOJEfFHj66MW8K1xlFVXaCxUY
qAozIgNUAaGgZFOjic6uWMVYYn1bjY2tDFgXo4pU82NqYTIrDmBRIEWAKEkSm3kUSmqmN5BEcoxC
UJnszCKEZslBMAixJhqnfET11AXXVVEFdVo4/NpLPcsRNE2z8Stkc2iWE3jhMF2HzQfEwGrWJi8K
IcIan7w2byuGHPQ+i7r5UL7Us63KkvrQ7rpsjdUYJaU4FKKky0LSnsd60tFsg11l7PCnEQRHAj+x
X/mIYxx1kiBLfbqaW6UBlHFTy3FdrsEUUjIhQNnw299aNRKj8rW9nlN1DrUOg8aUXBjnWR2/Plsn
JM9BGmTHTKpzOFKBKqxef9/IJ7FUjM9LfKG2GcQovn9GhluQBHyZ5ZhBC/rllKfvozIU/POqxynX
PYWBBSfUh1g3iBHnc5bKA1KdANUS7QaK6iQBw+I7FdY8y8aVagWv56W4t7bnY07JGzRBFmliWs9v
sRW/qCEJCdwmQHLESyi9ai+8PKYAUShYjN9Qxo1TZHCt0gwGK4Dmz2XHaf5DQxMo6vCcLYtOJ3hl
gh+JItm1yBWLg0h+AJMIqGX9eutkngLoQfWw07ads0SDso31a+SPGjHrlE/rWQcKWB6Adm0/E+UJ
OLTduCchSSb1Hj+xkCTP+TgxWm9xiuRTU4gTmsewJ7UntInXDIJENfhR9lRg5DYcnJJFu0tgdJP2
QHH48wi9CksBUCVRZTdPjYScIwyUpKMgKIGljEJ1I+cQ7BOUk9YH0UsrRknYNRgJPj6zDa003v34
YYjobShRwCnLvWtnDWmeJc/EF9gOCAUHwlpqDcvkbRkccAYxfl0JteoZG3L7vhRNm/p/MdEz1thl
NZHJS27qxlUvam8yzOCfy2dfLFLodAFYFBwK0nqHtsAoWtTNJvENVolhYEUgQ0UVLQUDWEQAAUBz
DVAlwoQNSspko5bsc6iPN3rvizYmeqJ3ESz6k7VwbYl8vu19K9Vd4lhTmn/QEt+2M/o4OB5OFHZ+
efQmeyvaq8nUMsGwGhwNq0/FlGZ9Mjmoz/kI0QCW4TSXgd9q8usNRrOPlAeztG+KR+J/880yS3NI
xLJZPkqVKvPSF5xHFjsgGwNHi5VH+AZAkpwt1zCogEg+Vxscc3c4SyhlN6YWvgbAzb92sWmnksBY
CSaihMnFj0peySNUscwh0QScmCzYY7Z828fi2h1AWkZ6v18g6ZczNcfM1NhoxyP1SGcqwLaU+CKd
Z9fHKkyPW/oKucTfVqIv++3I/dS+6Oq6mOo4CxfLuGMpkLY6o9fl7uulm2WnPF6CyVDwkwpg5gP3
OoEi9HvCA5O9HniN/wCjDCkCzAy2AIILDv6Q8jfiSuF3FzPyiX8RIa+WKoRqmwa68AVlcDEfUPbY
IjoBW3V0gtBctgtlXFrJTgFAqESgAkRQ6igTBSqtWC6qAlDCBZQfpALU6w7qmDKGqgIVxAdbrHHE
16E0+n+FBlKmkCbsIjhEd1uCqAI0YhvRSCcWh04fs14nUsShdaanySLVzlypqg/P4q9n8oQgdG6i
FwpUYyJfTqJsj+VMyQEeNEFFoZ3B5i9n5kFoxyH9J8KVHMYV0vn/AIq1/vq6w3TrEQJXYiv0LLsg
+AmQIoyVJcdVhMWVWAY5m3BDsA2Kb1OIr9zGfAb3xS1wBAPT+0UyxKiV7UyVlJFZX7g9ZlMIV1vp
ziUz2jqoLhkAh2OEmE4aoCfjGwCydt4XztuXbMSqTESCVJen/bR/MvXVqLYKK6JYUpda5/laZJpt
6KRS3HyVIEBOqEqyzdaygtfw+F5qupWIrkonb1siqM31OCE01BHGuJhsI1uwkh+//s5MsWQLEpmG
jw0YPun1PyqaEjliLgKQOCBufaINMiveFE3ONwsBEDzL0EIdMQrUUF/AEqp7dLIAFhQNROPLioWG
IguWSvaRSxqiYJ4bI1Dq16rZRVdEGaCWRSOwfbZPUm/gl2TAMEdLjuALyiQQkINOmLFWkdk+AiXX
j5rPRTjkV6Fh12AC9QyY0jNWnNuMN1akXIujenDsFmjJSdnDrqCaZRGIi/Tb+q8YvJKJFMj9yqtA
SvDIx/QoYb/H7k4plOACNZ9WRuBcWGrbofgI/wDU8XmjVSXFLpVh5Ukj+a/nL0Q8T0fQQJN++xXY
qlZaNTKTE+8ILZ1MSFSw1KU2UcUFOnlMJZHV1CUGgAoG2Av0psjm0zJc5X+T+zmNZBfXjG1+Gxpw
6tegdpSqV9STQolxsx9AOlchnfQccZ+cmIBT4UtEFSEUKiVsZ2yAMGx4Oz2ePQoW8q/MT3dAr0ue
ER2BfKFbmUeDCocoQgHyF59B+HYIGIqOngOKOBYswiMnF8IEKpnAls6b1VOR83ARF6rzRcMcFCq/
XZUWssFgQp30ApgHKs9LvcOS+/kuWIF1F61GzrWmGVNyDATaoG0IQVHTBL6BCg7EMhKewVQfroQW
ZXXFXWNCSabHfy97tHyIjJ/D3SFe/IEevWwQ46gZZu6e4yucEpFXSLTBtZD4beLll71c0bGGlC12
RupPYRz1P4ZiGpNM47RcIrpXIgWWL+v7kCmGwaueoS2MRrtYLtHRR2qjWyV2QnDEFQXSnKfXCibp
7eYELd0D9y+n+tLbEsYpOe3G/TpPKdnUGgy5LVcdvACuAyb5X6MIi2iRRXIHoQYxMBj1I/TECSOp
IZ7qwSf0/sf8n2Up0+wfZPkuIDJnn1adqm/JuZ0AlGkc/WppLqKf8IXPUMxjPKE0bqgZOFHZ8G1D
i7yMlW1MEhti2tqcRB9FVt68JWr6Oycss9Ffu3KOQHO+i6ZZ2xoDtBcJO6FzSelv1piTOl053ogP
MbGF2ibce/RRzi9dX5wfwj4YYhOj10JuM2CsVUbKFPMKZ8IMDCTneu7LGImKnuTjvDHhoA7vGJty
YoutAZSJ2lAQ+2SXthAC/kxfi+BR5Ysgcmi5ksLF+ACeIpxzZmAbM2JyfMYDOM8iqu2sL1EBniGV
wRFILcBqgYy5yQAiuMjmzm/1ObcikWxgaaQDIBlamJcNnIF84ylAPNdItpgTvvYmr0uslR1VxZut
PRggStRTDIKc4n2eCBJ4EClqu0IjfidMIE1RCtQcBALQ3YzBcCDIOqi0zPEMyjHyItAGx+Mj2mRb
I+b6qVO5SdjD6AhgnVQFhCtPHijRhNs8LFAfJgahcI5Y9DbMBsJdbpTUaergNbPihTGQ1L5cKC/F
K1dpCIopFpVJEgoC41SCAoaVgAg1FW1bRct8mOhP865Yo2BF69F9bWeodkg6zle8AN5+3IEiMIsr
ammlpHIaWZGi5+yGn9rM0ExAgfnyMnUpEI1GMSakpBRVIBwbbakZR0yWyO8C0Q8wRvD1Ece3ArCx
rE33/wDpKsBCSwwiUAMG4OkUgm3yBCZ3X2dLeMJsivrpXOUZ2TMJtRfcAriZaAFOE7RC5ASoLhWP
T85yxMVC6qC9SEoAU5QAcieQqdFff7sgSOSn1vEfksySMVv7B4tOJerDxxW7AQgD0fInSYhpkjFf
zwiqAvCDFamqJCAswSAtqJmRElV+Ti3qjOM+Pn+EQwEkhs0mMGff0nRwqAIHBhEzEFAkBWpYBcDb
0gWLeU8VJAAV+zlEtFRB0Y1giAxHu1ZpVxaBFF+1orfRgKUZUXUtyuxEDH83yxZi5CschyHEBxGS
eKO81iiFKtyttG84wDHDjf2+Y7leY45WYsybkiKWqrQZU0Ayq/8ANqm6WBfaA7VGwIzf1pdJdYru
UhKSLdTMpy/PMbWEiqyXzFlQraIhh+oS3ATaobts09ugtbHFdcNGYeSv23rNWfI8Jk4vA86Bl++O
Y1eHoNghv72pts+vLG1G4lZcAqpn/wD6KnW0kH0IsE7rD/bNEKvW7+36LJ0GQXS9kcLlFT4wVPuW
NWVLvszY+Uc9BUsdiFYSZfyn/WB9gp758Jy1M67Rlir924mG1hkdhUQ1yRgo4ofN0NWPOxQK7JWQ
ozSbQZVtKl3i1pXlKHKIe7SJMsfEhBsqwrmBwvI/kMUnLWAg/Ol2bvLyxIaU2opfGqEFAFZQBXWe
L1+88y6DMYWHX5GyeYPtkwEzUOop8o0mb2+pKapLD1H8QlygI+q8eOcBNqweoPUSbC8ra+WO4b1G
w/aAYEhCWACMjPN9K0Vi6Pobw6EiIN5lkn27KuEYWEJ5QJ0KQUBT31IHgV/AM7F5k1Fsd2yUpqvV
yFmhukQtjKDKMoi09xGkW/ysAaQtcvqgw2vYNRhYufxK3o7pu87HY71antpwPyWTrZV/CpN0rxG/
A14nto2ocI5ZZWOyIG1Lw5iU51bLyM0I8V+k/Py1LYxEDFjcxsv3XjdfJPh82lQM4NkobhFA/PsC
/wCAiHgcAAAAD8fyxX0DMWrXP7adK+9BeZd7CHiQac0Mv3pyy7WjuYd4JssRrUaVBqu2XKwwOcAL
LQ4BAtW6QogpTQmnkYR/ETssGpLEBwkJWbZsoZoqU48yAZV9d4mTWLsjZBlC/wCSJ7OyfoogfDtf
m6pkFwXQXDSIhAlWWKNghGkAKLrGregHsef53liqMC9AW1qNW0UFteVICgOh96eZciNDWVmpXQlX
5Fa/ayxt7/cio6l+2QMJnJGe90jT39wbOolywwYf0n7CJFMst/b5MArqSj9snJxWbCVfQuvt4pUM
lbSATGSgPlytRswfh5Q8MAs7e6HelQGs7NzoUKaU/vDNJZARp+C5Yk6Z40w95PnQbtHd94+ZeLWD
5OdOKauzjBs8j2aYHi1SkDIGTjvs1j+6UpRJIgC2xpmkIXV4kkrlkW1vrvn3B6VqeCzCFyjfWy6X
AuNPMATsFqEpAOdumYfWBhI5MjoAzYCUKhsXHnR370okEq8PdBvHmmRJ2A/OWvnMwYUi/BPSYgkM
2kltYYtToXPA8tjTcnwGtQhJPnQtNSwYDQOc+2YgASpoAFVdwGV3EwDp+B5YmIl1KFMeFF3d7uAB
jBhGE4IuO5Xi/d+ZaImis32StnhhLiOvROiwjZ7A0zRnCIsxva0RjoB7ufklegqInBe2+YgMslXa
bEO0vCc80dPWUVlPqOMdB5RR2EZbT7xG5dqJlma+h2raa7wwDDP5aBQ+5L2+IfERMtAWz76oneFa
wGbUsn3vqXXXYUhqCcnp7ZHcIaHphdluvItQfoZrEeDyo5hKHj7elhMwvIWKlCxRABRSglsCgiLP
S5Ii724spGyi318n4l7/ANPtrL6+TL6+T8S74+Inv9vSxAtgHIChRVg2Yznr9ObMKiYURa1Cw4BN
gpnVRu+ZaGN/T0v7vzLQ+5On1SWowlrCUHAXD9qdQUIDLWUFMqpe0VPsq27tIQ0k0qQNjbS4G3Fn
LVdnvCh0ZmhRzbrjrmWptvpkFINwhLrCJWhAif00sJdYVZKK7AVdPwXC7i00HI+M84F6etoZgSYo
6EqVGAlaigKgFKUyn+YKTtHLEpIURtSqb7xQcmoun02lKoRAvaZFrpsxVlbVbWhb95+ZaE3FCd6H
NvwJJ4obxARp0HoWdU1juzaCNjoKufBBS3OI3hnNFcSQsGsWw23Ry+Vs0zUyVlqOP4y+ylBZNfEx
b+a9/wBlO3tX7eb/ADqnK2KaLw2z4PbJGLpGzSXFr25LlVRe0YrNfLMxGCjg8H+8j7oRYfHTlB2t
8IliJrYiVx+95YrBMJIDgSKUDRZjVtsxnXBzaWjwF6DAXKsqpkgoOaEC9JhRjgfeHmW+X5pxQ+C3
g9qLu4wNuFWAqSjMSoX4mXtD0UKBYEOl5bbFOQWk68HSHi/DBFiAWart0bZbcsjKuAsd8tWUTMak
oFdw2sipOeSMcpw6iRHkdNZgCoMYZgDQgDSmiyIFGKVVDWV29YdNS09IVfzpU4jVJhRaq1xTZ+6K
TAHCAtDIVrwTCC63RIIfecsQcAX1YlTOK1dES9/0ISQKFqBZO3FiWoC1CFdcbxbjz4SxUXr0X1/v
PMtfP03IRfJ5VsQAzhY1sSvigBslcA0Ro0eNfU5pDC1Xfpr070edD0GeXN8cNAlaTekM8Xiyfkcx
Luk4/mn0AftynUdlnQldX7BawC5g5YSVoY+FBcWbTrCefKyX4QChtDtAXahLMqCnvYyyfjq7Nuc3
dwVjgCYFlHX2d4X3NHb8aBPkQvk6623Gc9UQHFLNPThZBQLJeqAhw4xYPzOM7+0qaBc+lpksLAKN
RoLKOVLKIAHQxAOAoDoGCqNfveWKx0b210HlLHEURESn76KLr/MtsPohNDQTzfeWLAgobQbIe5TK
JCyc0RMAFA5BijTAla00TRDEM/b2OFUgDRgJQ0InPqBQHsBdQYbGaDNK1W/JxqUSZYjalZJontl8
7M23UC0f8vsnSJEriNb6fzbf0jYN8gpyxOngxsIUpiAtGNjzal7fn/8A0lhP12xLeT7elB0Lpk0P
txFWpyqTli6kv5jgCumzjzk7Dm0WfwT/AGgouDrpwa8d/vG1pFMJh3XS7mm+YhCjRgbsqq1vSuek
EQREQRGxHIiYRNH7vliKtZcTvWpvZHLoVw739dqgWoBquA8ZkTkKhzMg4ApKFKJpfBCTeC4p+78y
02dDNAGFv9BxrrdGGiGqY+bhnTUJHCQ0aAwactKeLSvGv0fziOIlNLYUM7JBgpzONiRtrc4DIIkT
3o187sWZQsWroyBymbcT/R6x0dEc+VLeLVh/Rskc7rh8p/BkjWv4oo/+LDlKhxGoMIpExwlX3qiT
vz7Ezj8pI16o45w9sPTTbThuTH2YPW1f3knGBt0mInDj8fI+1wlKLDS8Gsuv/YygNCpaOugoASkh
jbSCmGAvVlt11ripsYYFAFApbbQAXgrZfXyZfXyd/fhvl907Frj5L7R8fQ0f5c9PtMQpDHKkbqmk
xdUlN2403TUNpqo7qWtSLW0o21UalRKrS3QaMVgsgtoMXBiDFAxRjyRMTS8+9/MuRGhrKzUroTj5
9LB6IZgaobhVLj4cPJQ/cTXWyTxct6J1RLT5MCeIF59kL3jPVyqtAhIAhFTOcPO8stknDq8A8T+J
2MqOvomi27fJZ2WcRdISLOSdKzUIVr6o3Pe1gxDwtJQF1QLTEb3Gp7yOrYn0GUNV0Yzd5D9Cgg5a
bf5kJmMYxfLGJnYR/PMZtLvUjH5QadOOJFTGGHp5YjOwSEAwSgWQqUIvqrhm5f3j5l4tYPk504pq
7PHus0g90MYs0mw/VMWBNmlocIE9jnl0sqQhW297II/Un2NBU/r0pEZPHPOxJbgQUqLFq4oGo8MN
Kp1nEvLcmeLL7XC/wg5yQhUH9IG5Bsz3L794zHY6qGUy5/CcLeNGYw5wkgBVCimAsC+5s4nmTXT7
3liZWV9LukNVuQa8yvpQiC6iG6uFLN+H7z8y0RNFZvslbPDCiy8AEr2I4JLhopRZk1lZehZsUQbN
cDzGmIgQvZCjjTBoTDZKOItwKZ/8aXQUeBDy9PrRZ450DnUvhVXYLnN/+z3srYUIFb/58RNgTujd
AoDM35YugaJ/zZlxeFV1wnImkJD5fui8rrVcUrvr9MMAcPveWK4EUSlDmR0thxZsWWPoydlWLR45
oypN975X7+88yxZ2XNSmaA8gZhTBVPpB/rmAgJbTkYfjSS7ZEEZStjB3koJv2U5F9BjLiIJsyJTj
nATTri0g96HYCAmEUM0C10QBDvQgXIRl+KfGpAaYcdh5tU+tSBpBRJBAoaHtmnIya4DVM4hiUkEO
iw2is2SxvrTx/wDdFDn6NAAMw8n2qk5DfQpoC2oQMUfm9ULQpd5F7I/qZS2tdoqhwAoULAwQcfzr
AdiZbUOU2sEAqxSA7QNPMCBtwaDIaiIWnQFQpjhgddK9e9dOZeujXBTde2/lvxLe4Op29SX3lt9V
e8vw7HOKhqleJx9cGvZn7PETZhuM51FBkWQZ9KtKAvBBCjwJ3xIUsxfo/eHmWtXGJHkVDnEOken2
2blqbT4UStCAUANt144qFGx7TPrDqwZw8KR2s3hrNg43iRvz09GY/W9Oe6jk7bpXYLmYkeIqr8OK
9DpdW8d8YHI5Uq0djgDGq5JyIRVOfpo0Nsx+QV+cK0unMtLQxfrP9Zhb8rbbU45jxCZML1ec7T8T
NQq9kdPPL/dt+59QqqBEEGkiBmv3XQgaJ5uxPbDHvuM6e+EZz1y+x9hAejsLfmYy5dtji8olp/aN
3qkKWrtehxMUg10pgpFxcrOgvg4dptguq+NlkudrHnwIg5eA/F+PlEVj9VaErXm6wYAb/eMjeWKw
imWzQxWcAzVA26CVWav3g+ZZzkYVq3Gc5CSMT2CShp0TEsFRYWjKXqNBlcMksj7+CXOmanFpqQQi
KME8Hvh3MZhHCFpRVsvCFGbm2xl4/fmEQtoSTa8DlsBoC2GqejCXF+YPjUX2wZRYtkyz0qE+obpo
aLua0F7qsUZOoJ3NgxfCSJxkwC0AwZqoYLLpYfoU2oBBNl54OZTFGrJR/wCzL7Ir6+T8bLv+J7yn
DsHDvXSWc/J+PovunvvmS+ul6Pd8tZZrnho+1X46S92fJ96r7XliyVYvARfLXcy+vk/EUOPgnsQb
0vxE9wl9ccnt8I5KOjAmWsGoCGRTKV8ftxdV/ZoekFB3rn7rzLCkasnhEiUhU6ZYvD+8QaUVVeKs
D/d4HjFjS07k+5zNDGk5K8mutdnuTFUBqgx/s/bSpRW4BI+O7AYY6DH26rEEHEmZXzIdU7W4+CXY
rhy05PnM65pS+qWE5ZUPcvcpbmpf1IMe2HPWMdSJPMSnR06q/phtlApstsSskCczu6UPm5flfLKr
N0Fw2JSaafWxUHMKlQfhEZBad5YjRgWlqMAJiXG5UD6FfgQaLIIhijWSkTXDAlqYvHb4axWO9/3X
mXQZjCw6/I2TzCzvGSttkEElZlB30vlJSm64jrHKPLMawqeI9iIU202wVYjgUwRSLeH51yqIbYgB
OLCWlKYY2UNAcjI+m8MeCcdLLwwIN9LFPaWE7Moe544ZBJN3y3iNXGosSDvJUpgrlUihaQAlvv5h
HHs8o3QKisqrR8rQwG18PbEXlQn6WX8ERAaO0+dy7UQxpf8AQRkbhprJzlixBEbCw6QyCaMjFaPo
LBJLJ4snq4JwlGOrp9/xvYaePufuvMu9hDxINOaGX7qhcBpM+QxoKm3pZYN40Oygyo89wpsM5cK9
1lQPoLBIoZK4T6xiGfAYmfosOr3NFOQuZHnVtqLDZkgA0ne+1CfU1h0tMhmCn8imHhvXFQSVGUxw
lYUUqH/i35El6bZsNOw+BOKp6pAA3HHxIsi8+w3yCv5ZilbnnliZFby2FWp23EtZRgfSpg4QLHQu
oq8I2u6nEbs4/b7v3fmXIjQ1lZqV0JBWuDpNEZxuqzUGBPoyb5iHMOApegUJE2MJeKNe+yC75myP
9kpxDngcCblC1YW5O2W4eLUkLm2nrBdTXpyPi9aHuIQdFC/cv918NGyvlm35E3P+vAzrN/5qShJP
URDv95KlIVn3WdZ1ITyr4S4R8VEpO2W4dP4vMOGprwn9A+YPomawNeGuvKWcTz2WGrUs4ks4nnLO
J5n23LFlxyuvO9O/OKGqHWZKpfCy4I5GzibCUGbR8O+PB+9zRZrf6Fer975l7brnzIdjBjUK2/hD
HfycYiehG90argselQrlAQVQeqBbJrgYM6EIzZtEI7AZEuKPWc6cjB2nHWaKVJ4ULF3y0FATnwqz
osUSDAp4A2+htyNtMDvsbqwbN7D6IyZUcdv8eIiOOxVmoZ1a0eRL+NVOBiuVHljtHJCJKWF7bmJT
ghNuFfkSAn/CsFcBmLE2Kcpw2VyS4qGMcbz8dsrPhRe3C01ytEKtUh5HwEyk+kZG6sajCRdnFkVi
MhcOEGypyJRYTzTvJrViiDIwQ5kIdw2TPFY0SbdjNeK8QFwpLfQDoR0C1MEt/wAeROWIF2L8bQ/R
5yp9/o6Xf9+78y7iCe0lBFTms7G5HT8d84MQkDp5V/7JuUYzKn8+SRgL038NQc95kbhF7BadwRUz
f0t0yBVtDEyj5S2xXSslq/1Ruzg6+s5ZIhU4n8BzRmbpxijJ5+0lSa+wMMSpSrnq3wCacz9f9iag
MBcx6MCB4uyaochdB1EwHJST+rXGIKWdhBXsv2pDmQBaoLvZ/ofYc92bbxhCvRjSQY4SfttiSBlQ
NoEidkDWqy9uRsVG1uHMCSMyU+iLoC+xLvuUtKMrgx9mHxQtYk4PwbAi95DAEHkkOV2N7Hc4xubb
V0hkZS0JNptqNMgCuaf48fLFRL8AXY67q86UNXf2+ndTQ9H2mg6Ht915ligA8t2OqEdSlSqltrAI
vJihtSmAooySQtmvAYZbTGiljKrWq+TRkFJSA/MvGWhdx1QpmXediJPgwBImfCgL59KY+kESLO1X
cROcjwy2AucOh747XUnHTYO4XFb55FQeLsJ6e5H5ioBUmXCqUKyYXWki5tHvSXo9i69H4Kkvg4EF
coDrObSgjCVAIzx53zSSX7wSf2Ntn1Iy+wfYpJcXyVlh+awtkz6aO89aWZKzG429u5/O/wCZHDdk
Ezo912lGbXaBgu8t8eJnlMvNtvme9hgudHSel9qFBwMOrctUszKA3FGilzbXMDxSfUjW81RT7NGL
6nZuIbrugVRkMynSZUyK6sgBmtiQr8rMicKOmDkbzGD/AFBiaktaoDj+uCXD8LUJNsjk7yZbBDA0
PSAT8tdw65YmxgEFDfNJbet4azqHJxqOh6PtNB0Pb7zzLTIslhBzHCBVqMkw6Lr32XPUYcmr5JY6
c1yHbq6nQB6SDpRwCnbCAZGp9YBBeGhhVPtJB72DI21+cKq79uMseEwHgQjAXO+CkOWjAIMkzcmP
Hmbf2GRbJpYoRJa+xkY4t1PXV4YWtLc3Z/a97MqlS8T4SlKUdFH4HBELv8Jf9FnJS462j9aF+4D0
LCftDReJ5ni0o5+P9n6IN2aZVcg3gJUlflNAqrXKLBZ9jt/lP4Yk0oVFLSERgksSXI0AedB7Yfzx
qhFfxTIyQqpwDltidpUvbdmJYz3rp+NqNSNJ4QSroLtlTW1H/insme0wlKPFMsZlavTikqyRc1bQ
hoqCjbY5KD++c/thcL9nK6BBY2CQkch7Yof9HQI9iNST3OmPpDcUZuAM7wK13uzOO3sQoN30XdIV
e2k7lnvhw4LHIPSRLxS6pYnCEbg2BLCa40lxIZ6qNKRCC94ajShX77liaU4iDJ/E+Spoej7TQdD2
+88y0yLJYQcxwgVajJUVJZA7nLI0WiOpSKaBQ2ywQMqoGNu2fpVbOyWo5WEEAy5NQwjIo8O5BXIW
JIKrNIkaCm20SX4IM4NwKmCgGxNUR01neCFzuhQheRcQnY6eciEKqhkloBQAvzQsAPzvLE0NLW5P
Xjo9GGh0PvPMsKVo2wlynAHWFFMAYAQ6xAkPbjJihPmmyd4ThefUBcokHbhi3BSWS4YsKRqrxcrr
4c49ge1TCKsIMAgw5B7Gu2a28r4yO8qltP8AT/bKZ0XmEWrIyxCPQ78ngIRdTCfo2menBC/mCs9I
7bKGqvmF8uWpyUPvVtj8eiFN6Am0VweWIBaBdgiWAs3ghqBHI/RZ/dUaprrBngN8iIZhF3YSnr7f
syHQ+3zXK7ydDDQUiN2FBhD1AQ1wettwA1zq25+l0x6hUtFgkSIOLtoHWB1GUYqVmoMpiUABwh9p
ouIF2uihYAGhIC0rFiIHL4oExoG6YguFEu89k0m1vS6m2ixM0p37uqFDFXGMfNZDUTRTekikLXu6
UkOiQk7lNC9KADsD7Y4UBiGIQi4g4hOQTErKXxA2t4NqU8V7E560lrRjtJjc/m+/gmu8oPynLEFc
dVyrq3vvGcGgYKAPodaDFBcnjXTym51Dm4uSBAaRUapTtz9Ukbo2WyFOI7Zq/Z7RZpCf4VixYsWL
FjTiBKAE6luNSpSiPU8ATrtHgUGv8LFixYsWLBGkQEPNq7BqOBEQDHa3ClImqLuhmQhOLN4IAq0s
utaNuGv/ABurliAglkPnKjpMOidGoYmChAEEWKMlsD0HJA9htgxwOH0GQyrcfWuXLly5cuGoS1Fv
UuQTT6UcHMzgKTxIs/WuXLly5cuFi1GA6XROtukwBBnAIKEIFqwGi2iqw0NF+IWeFTBaT7yYzzQz
g8xQCigBr6U/8cbq5YkKFuNFQN0c3cSNwvdyvDAgBRDcKG+s1tyg5Bhk3mfRwnzzhVl/g8CBAgQI
EC/bsQZNBKVGylooAb0Ycog3CoGGoCPrAgQIECBArJaHW8S54VA2nPI7aUCyqMBLU314NXxuU8QB
4og4xrqeZUKUebgZG2SogXGh9UFEjWw/Jgfx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePH
jx48ePHjx48ePHjxE4AstB4NYwVFCDX4W3Z/cIJg6/Hjx48ePHjx48ePHjx48ePHjx48aH/clu8l
D/BnptsviYKwERMGrf8A4gePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx48ePHjx
48ePHjx48ePHjx48ePHjx48ePHjx49W4cZnoJicTBWfsQ8ePHjx48ePHjx48ePHi/DjM9LMTgYKz
/kHjx48ePHjx4B3AYzwcIABESPNbsuDFBVFVVVZY8mpRfX1/8T6v9j+j/wCeaaUNRMA/l3dvBAh2
ExX4Ob9fX7qbEeokRfJk0SXLlMknAPCBu3bhAgQT2/x7detdv8e3XrXb/Ht1612/x7detcrv9+vW
tv7w52xx79etdx8e/XrXbHHv1612xx79etdz9/nrW0qZu5f0+FChS/L/ALu3XrX2gQI3btwACckT
JrTlzatOXOvWFouK3sjw95lOgd6+7Yq7zlwav1LLnQEdBUHbqyNDA/jAuf8AREs+2qw/DxXnOwgc
/M2V9Hm/B5bh76/RdQRdH5rh403HfNDV8BrwocTp4xUHOT53j9NL+qN08R6OLYyqYQqgaNuHUNgF
3+pVL5p5xHXFso00kUAa7TJoUebTbOifM2gQIv7Q0DYRFQlkTCt4dmVrfbYSKzUELp1VxQ1QoENd
r9/jpewQv7G4fs+XP/C3mejTIwK3XrG48e1ef3J4hpCAHYj3JAAAFrFa/cDiJ/ibSgIF+ruNU8cr
yr2Jq/c+avNOHHY7FVPpz+B5+mzl3J217cdh99e3HcXbXtx9lQ3Hd0kR0DNdOs8eJ8OBMnhemey4
B3+uu0+YAIFris5dUH3xEStAwatSzRS53ppMRH8WeodMQUrta8Mvm6518GWBLKbSODd0vc45Rwfw
bXS7tvI6wIovAKqvGK54/wDJycXKZod5cXm5pSY6/TrzOeNC7gXNZb+NtP3pNzHF0929ryxpKZ5q
TvunHf6aUa5x/wBNdTW9+7PAVCrgGelc78e0Vzg5tkzuvi5mvHTnciweq/PXpGauuK9891nWlcGd
d3c/prHVfXcziu75R2vWJx48no8c64nV+P6+uksKaEpMCcOTTGnLGe0O2nZnUVrT2I89ZSAF0Brn
eBuzwKqLWZvEyt+eORpU1wmvXLZCnMvAfThUryU0P0bxpjOBquLSp85rRxvKP32eAiL9lrYojNel
/9k=

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

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

------=_NextPart_000_05D4_01CCD7BE.591C80A0--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBP-0002Iy-7N; Wed, 01 Feb 2012 10:12:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rphmi-0003UU-Q1; Tue, 24 Jan 2012 14:55:44 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327416870!62296871!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 24 Jan 2012 14:54:31 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:54:31 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OErorW025676;
	Tue, 24 Jan 2012 16:53:51 +0200
Message-ID: <509629CB53414C2CB871E799AAB78E90@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<201201241537.24507.tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 16:54:36 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 TG> I was a bit un-percice regarding the "reboot" issue:

 TG> The passing-through itself works even after a reboot of DomU - the
 TG> rebooted System spits out its Graphics normaly through the
 TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
 TG> After a reboot it doesn't work properly. Meaning: Slow 3d Performance, 
i.e.
 TG> unsable for real 3d apps, even a 3d Desktop;
 TG> For example, when the Card gives you 70fps in a Benchmark after a fresh
 TG> Cold Boot, it only gives you 5-10fps after a reboot, this will be that
 TG> low until you reboot Dom0 also, not only DomU;

 TG> hopefully i described the scenario better now...

 That is, situations as follows:
- There is a certain group who are trying to make a vga pass, but success
- In the second group turned out, the performance on the second restart the 
deplorable

I belong to the first group, but I use a pci pass and after 10-20 reboots 
the system does not lose the 3D performance.

Question for Tobias Geiger:
You do not deign to describe the process step by step is the setup and 
configuration xen-linux-syste to a successful vga pass? 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBO-0002Gn-6n; Wed, 01 Feb 2012 10:12:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rph42-0000H5-VC
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:09:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327414166!3132995!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10669 invoked from network); 24 Jan 2012 14:09:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 14:09:27 -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 q0OE90dt028293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 09:09:00 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OE8pd8003446; Tue, 24 Jan 2012 09:08:52 -0500
Message-ID: <4F1EBB73.3000705@redhat.com>
Date: Tue, 24 Jan 2012 16:08:51 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
	<20120118135445.GB25711@linux.vnet.ibm.com>
	<4F173F0F.5020604@goop.org>
In-Reply-To: <4F173F0F.5020604@goop.org>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 11:52 PM, Jeremy Fitzhardinge wrote:
> On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
> >
> >> That logic relies on the "kick" being level triggered, so that "kick"
> >> before "block" will cause the block to fall out immediately.  If you're
> >> using "hlt" as the block and it has the usual edge-triggered behaviour,
> >> what stops a "kick-before-hlt" from losing the kick?
> > Hmm ..'hlt' should result in a check for kick request (in hypervisor
> > context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
> > will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
> > before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
> >
> > Won't that trap the 'kick-before-hlt' case? What am I missing here?
>
> Nothing, that sounds fine.  It wasn't clear to me that your kick
> operation left persistent state, and so has a level-triggered effect on hlt.
>

btw, this persistent state needs to be saved/restored for live
migration.  Best to put it into some MSR.

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


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBG-00023j-TT; Wed, 01 Feb 2012 10:12:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RpldN-00030W-5k
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:02:21 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327431730!12173418!1
X-Originating-IP: [202.81.31.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NyA9PiA1OTQxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27674 invoked from network); 24 Jan 2012 19:02:14 -0000
Received: from e23smtp05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.31.147)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 19:02:14 -0000
Received: from /spool/local
	by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 24 Jan 2012 18:58:54 +1000
Received: from d23relay03.au.ibm.com (202.81.31.245)
	by e23smtp05.au.ibm.com (202.81.31.211) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 24 Jan 2012 18:58:50 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0OJ1uN3606382
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 06:01:56 +1100
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0OJ1s8E013536
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 06:01:56 +1100
Received: from oc5400248562.ibm.com ([9.77.201.56])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0OJ1ibO012392; Wed, 25 Jan 2012 06:01:44 +1100
Message-ID: <4F1F0019.2010601@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 00:31:45 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<4F15C48F.1000000@linux.vnet.ibm.com>
In-Reply-To: <4F15C48F.1000000@linux.vnet.ibm.com>
x-cbid: 12012408-1396-0000-0000-000000947761
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 12:27 AM, Raghavendra K T wrote:
> On 01/17/2012 04:32 PM, Marcelo Tosatti wrote:
>> On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
[...]
>>> + || (vcpu->requests& ~(1UL<<KVM_REQ_PVLOCK_KICK))
>>> + || need_resched() || signal_pending(current)) {
>>> vcpu->mode = OUTSIDE_GUEST_MODE;
>>> smp_wmb();
>>> local_irq_enable();
>>> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>>> !vcpu->arch.apf.halted)
>>> || !list_empty_careful(&vcpu->async_pf.done)
>>> || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
>>> + || kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
>>
>> The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
>> on vcpu entry (along with the other kvm_check_request processing).
>>
[...]
>
> I had tried alternative approach earlier, I think that is closer
> to your expectation.
>
> where
> - flag is read in kvm_arch_vcpu_runnable
> - flag cleared in vcpu entry along with others.
>
> But it needs per vcpu flag to remember that pv_unhalted while clearing
> the flag in vcpu enter [ patch below ]. Could not find third alternative
> though.
[...]
> do you think having pv_unhalt flag in below patch cause problem to
> live migration still? (vcpu->request bit is retained as is) OR do we
> have to have KVM_GET_MP_STATE changes also with below patch you
> mentioned earlier.
>

Avi, Marcello, Please let me know, any comments you have on how should
it look like in next version?
Should I get rid of KVM_REQ_PVLOCK_KICK bit in vcpu->request and have
only pv_unahlt flag as below and also add MSR as suggested?

> ---8<---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..1bf8fa8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5684,6 +5717,11 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> r = 1;
> goto out;
> }
> + if (kvm_check_request(KVM_REQ_PVKICK, vcpu)) {
> + vcpu->pv_unhalted = 1;
> + r = 1;
> + goto out;
> + }
> if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
> record_steal_time(vcpu);
> if (kvm_check_request(KVM_REQ_NMI, vcpu))
> @@ -6683,6 +6720,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> !vcpu->arch.apf.halted)
> || !list_empty_careful(&vcpu->async_pf.done)
> || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> + || (kvm_test_request(KVM_REQ_PVKICK, vcpu) || vcpu->pv_unhalted)
> || atomic_read(&vcpu->arch.nmi_queued) ||
> (kvm_arch_interrupt_allowed(vcpu) &&
> kvm_cpu_has_interrupt(vcpu));
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d526231..a48e0f2 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -154,6 +155,8 @@ struct kvm_vcpu {
> #endif
>
> struct kvm_vcpu_arch arch;
> +
> + int pv_unhalted;
> };
>
> static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> @@ -770,5 +773,12 @@ static inline bool kvm_check_request(int req,
> struct kvm_vcpu *vcpu)
> }
> }
>
> +static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
> +{
> + if (test_bit(req, &vcpu->requests))
> + return true;
> + else
> + return false;
> +}
> #endif
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d9cfb78..55c44a2 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm
> *kvm, unsigned id)
> vcpu->kvm = kvm;
> vcpu->vcpu_id = id;
> vcpu->pid = NULL;
> + vcpu->pv_unhalted = 0;
> init_waitqueue_head(&vcpu->wq);
> kvm_async_pf_vcpu_init(vcpu);
>
> @@ -1509,11 +1510,12 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
> void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> {
> DEFINE_WAIT(wait);
> for (;;) {
> prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>
> if (kvm_arch_vcpu_runnable(vcpu)) {
> + vcpu->pv_unhalted = 0;
> kvm_make_request(KVM_REQ_UNHALT, vcpu);
> break;
> }
>


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBJ-00026r-6A; Wed, 01 Feb 2012 10:12:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RoKSM-0007UO-PN; Fri, 20 Jan 2012 19:49:03 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327088934!10054314!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22491 invoked from network); 20 Jan 2012 19:48:55 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 19:48:55 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0KJlwcn008649;
	Fri, 20 Jan 2012 21:47:59 +0200
Message-ID: <D8ECC4609A434D96BB8F8FEBC2301EA4@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "chris" <tknchris@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
Date: Fri, 20 Jan 2012 21:48:30 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I will start it only pci video card (not PCIe) and hangs. Although I do 
periodically attempts throughout the year. I also have 2 more cards in the 
same system (ati hd 2600), but can not run any vga pass under fedora, under 
any debain or ubuntu.

I have a motherboard ASUS M4A89TD, which can IOMMU

 c> I'm really surprised this doesnt get more attention. For as long as I've
 c> been on this list, this feature has been mentioned so many times I would
 c> think that getting this working would be a huge feature that would make
 c> the product even better. I have only seen the occasional success with
 c> experimental patches etc, despite this being talked about for years.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBI-000263-KY; Wed, 01 Feb 2012 10:12:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>)
	id 1RoKPm-0007IS-E5; Fri, 20 Jan 2012 19:46:22 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327088727!49468347!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25552 invoked from network); 20 Jan 2012 19:45:28 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 19:45:28 -0000
Received: by iahk25 with SMTP id k25so7753790iah.30
	for <multiple recipients>; Fri, 20 Jan 2012 11:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=FBIjqnSPs4q/rDIuQPA1sbKZwbXJRDNb1Ic9dByyrV8=;
	b=hkUuazHYti49silci2sxBUCSf7I9Pz2Hew4xiqh46PZlVxZYMUaeD45yZnUapQ4KW4
	VdOIS7yPwLznySdYAUs96N3rq4lJpNsV/I5VG65qo/I2LJ54J5F4ktz5oIV6TFBf+0WU
	XeH/NhgB8oFMHo3Ug430iy4d063d9qVytv4Qo=
MIME-Version: 1.0
Received: by 10.42.168.138 with SMTP id w10mr27404410icy.47.1327088773406;
	Fri, 20 Jan 2012 11:46:13 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Fri, 20 Jan 2012 11:46:13 -0800 (PST)
In-Reply-To: <CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
Date: Fri, 20 Jan 2012 14:46:13 -0500
X-Google-Sender-Auth: 3xIkvKyocinNv3wAEk-a0DkhRWw
Message-ID: <CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: chris <tknchris@gmail.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	Likarpenkov Alexander <al@ohosting.org.ua>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2326141285686832260=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2326141285686832260==
Content-Type: multipart/alternative; boundary=90e6ba6e8e12ec9f6404b6faeeb1

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

Most people run Xen for headless virtual machines, and VGA passthrough
requires VT-d support in both the CPU and motherboard.  VGA passthrough is
also somewhat dependent on the card you're using it with, so it's a hard
thing to test.  If you want it to get more love, then you're the best
situated person to do it :)

However, on the topic of Sandi's issue:
If your monitor goes black, that's a GOOD sign - it's indicative that the
dom0 is relinquishing control of the graphics card, so at least that's
working.  In my experience using graphics passthrough, this problem is
related to your card not being fully supported; essentially, Xen can't pass
your card through to the VM during boot.  If you leave the `gfx_passthru`
option *disabled*, you'll have the emulated cirrus card (by default) and it
will at least boot successfully.  Here's some step by step
suggestions/instructions:


   - disable gfx_passthru in config (delete the option or set it to 0)
   - enable VNC, listening on all interfaces
   - start the VM - your screen should still go black
   - From another machine (what with your screen being black), connect in
   via VNC and fire up the device manager in XP.  I don't have any XP boxes
   left, but in Windows 7, you should see a device in an error state under
   'Display adapters'.
   - Check its PCI slot under 'details' - "Location Paths" should help.
   Compare that to `xm pci-list [domain name]` to see if it matches up with
   the graphics card.
   - Install the driver for that device
   - Reboot.  You won't see the BIOS on the monitor, but it should use it
   once Windows takes over.

If something in there doesn't work, hopefully I can help you debug - I went
through a lot of this a while back.

On Fri, Jan 20, 2012 at 2:24 PM, chris <tknchris@gmail.com> wrote:

> I'm really surprised this doesnt get more attention. For as long as I've
> been on this list, this feature has been mentioned so many times I would
> think that getting this working would be a huge feature that would make t=
he
> product even better. I have only seen the occasional success with
> experimental patches etc, despite this being talked about for years.
>
>
> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander <al@ohosting.org.u=
a
> > wrote:
>
>> Please make a manual
>> or let's together make
>>
>> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>>
>> SR> Pasi,
>>
>> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e
>> SR> CPU.
>>
>> SR> Have you managed to pass your gpu through to the domU?
>>
>> SR> Regards
>>
>> SR> Sandi
>> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> =
wrote:
>>
>> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>> ??>>>    Hello,
>> ??>>>    I have spent a lot of time trying to get gfx passthru working o=
n
>> ??>>> my
>> ??>> system
>> ??>>>    without success.
>> ??>>>    I looked onto my hardware capabilities again to make sure that =
it
>> ??>>> does   support VT-d and I am not too sure that it does fully.   My
>> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
>> chipset
>> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
>> ??>>> supporting VT-x, no
>> ??>> mention of
>> ??>>>    VT-d at [1]ark.intel.com)
>> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipse=
t
>> ??>>> AND
>> ??>> CPU
>> ??>>>    need to support VT-d.
>> ??>>>    What confuses me is, why is the 55x0 chipset listed there if no=
ne
>> ??>>> of
>> ??>> the
>> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
>> ??>>> option,
>> ??>> only
>> ??>>>    VT-x.
>> ??>>>
>>
>>
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-us=
ers>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
>

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

Most people run Xen for headless virtual machines, and VGA passthrough requ=
ires VT-d support in both the CPU and motherboard.=C2=A0 VGA passthrough is=
 also somewhat dependent on the card you&#39;re using it with, so it&#39;s =
a hard thing to test.=C2=A0 If you want it to get more love, then you&#39;r=
e the best situated person to do it :)<br>
<br>However, on the topic of Sandi&#39;s issue:<br>If your monitor goes bla=
ck, that&#39;s a GOOD sign - it&#39;s indicative that the dom0 is relinquis=
hing control of the graphics card, so at least that&#39;s working.=C2=A0 In=
 my experience using graphics passthrough, this problem is related to your =
card not being fully supported; essentially, Xen can&#39;t pass your card t=
hrough to the VM during boot.=C2=A0 If you leave the `gfx_passthru` option =
*disabled*, you&#39;ll have the emulated cirrus card (by default) and it wi=
ll at least boot successfully.=C2=A0 Here&#39;s some step by step suggestio=
ns/instructions:<br>
<br><ul><li>disable gfx_passthru in config (delete the option or set it to =
0)<br></li><li>enable VNC, listening on all interfaces</li><li>start the VM=
 - your screen should still go black</li><li>From another machine (what wit=
h your screen being black), connect in via VNC and fire up the device manag=
er in XP.=C2=A0 I don&#39;t have any XP boxes left, but in Windows 7, you s=
hould see a device in an error state under &#39;Display adapters&#39;.</li>
<li>Check its PCI slot under &#39;details&#39; - &quot;Location Paths&quot;=
 should help.=C2=A0 Compare that to `xm pci-list [domain name]` to see if i=
t matches up with the graphics card.</li><li>Install the driver for that de=
vice</li>
<li>Reboot.=C2=A0 You won&#39;t see the BIOS on the monitor, but it should =
use it once Windows takes over.</li></ul><p>If something in there doesn&#39=
;t work, hopefully I can help you debug - I went through a lot of this a wh=
ile back.<br>
</p><br><div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 2:24 PM, chris <=
span dir=3D"ltr">&lt;<a href=3D"mailto:tknchris@gmail.com">tknchris@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m really surprised this doesnt get more attention. For as long as I&#=
39;ve been on this list, this feature has been mentioned so many times I wo=
uld think that getting this working would be a huge feature that would make=
 the product even better. I have only seen the occasional success with expe=
rimental patches etc, despite this being talked about for years.<div class=
=3D"HOEnZb">
<div class=3D"h5"><br>
<br><div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov=
 Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:al@ohosting.org.ua" targ=
et=3D"_blank">al@ohosting.org.ua</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com" target=3D"_blank">Xen-user=
s@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-users</a></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com">Xen-users@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/xen-users</a><br>
<br></blockquote></div><br>

--90e6ba6e8e12ec9f6404b6faeeb1--


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

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

--===============2326141285686832260==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBP-0002Iy-7N; Wed, 01 Feb 2012 10:12:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rphmi-0003UU-Q1; Tue, 24 Jan 2012 14:55:44 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327416870!62296871!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 24 Jan 2012 14:54:31 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:54:31 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OErorW025676;
	Tue, 24 Jan 2012 16:53:51 +0200
Message-ID: <509629CB53414C2CB871E799AAB78E90@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<201201241537.24507.tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 16:54:36 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 TG> I was a bit un-percice regarding the "reboot" issue:

 TG> The passing-through itself works even after a reboot of DomU - the
 TG> rebooted System spits out its Graphics normaly through the
 TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
 TG> After a reboot it doesn't work properly. Meaning: Slow 3d Performance, 
i.e.
 TG> unsable for real 3d apps, even a 3d Desktop;
 TG> For example, when the Card gives you 70fps in a Benchmark after a fresh
 TG> Cold Boot, it only gives you 5-10fps after a reboot, this will be that
 TG> low until you reboot Dom0 also, not only DomU;

 TG> hopefully i described the scenario better now...

 That is, situations as follows:
- There is a certain group who are trying to make a vga pass, but success
- In the second group turned out, the performance on the second restart the 
deplorable

I belong to the first group, but I use a pci pass and after 10-20 reboots 
the system does not lose the 3D performance.

Question for Tobias Geiger:
You do not deign to describe the process step by step is the setup and 
configuration xen-linux-syste to a successful vga pass? 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBN-0002ER-00; Wed, 01 Feb 2012 10:12:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpK59-00026f-OQ; Mon, 23 Jan 2012 13:37:11 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327325824!10324399!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26105 invoked from network); 23 Jan 2012 13:37:04 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 13:37:04 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NDaA7x025783;
	Mon, 23 Jan 2012 15:36:11 +0200
Message-ID: <51A65EA9980F41C9A98C83820FEC3E87@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <xen-devel@lists.xensource.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Date: Mon, 23 Jan 2012 15:36:42 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	xen-users@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

As has already been written before - does not work. This water in the 
internet a lot. If you work - help with a manual. I am from April 2011, each 
month make a new entry. In January, compiled nine different versions of the 
kernel for Xena. 3 different versions of Xena: 4.0.2rc3, 4.1.2,4.2 unstable 
/ test them on debian and Ubuntu - not worked

 TG> The thing is, you either dont need patches at all to get it to work
 TG> (ATI), or you need to customize patches reflecting your individual
 TG> setup (NVIDIA);

 TG> To be more specific:
 TG> I can confirm that passing through a ATI Card works "out of the box" -
 TG> either to Windows 7 or Windows XP;
 TG> In the past i had a setup running with a NVIDIA card, it only worked
 TG> with special patches (the ones David packed together and offers as
 TG> tarball) and - as far as i can tell - are not generaly working for all
 TG> NVIDIA Cards, i.e. you have to adjust Memory-Adresses in the acpi.dst
 TG> (iirc). - and even then the passed through Card worked only with
 TG> Windows XP - NOT with Windows 7;

 TG> Both setup have the "flaw" that they only work once - meaning you can't
 TG> reboot your DomU , cause after the reboot the passed-through Card
 TG> doesnt have correct 3D-Accelleration any more (was/is the case with
 TG> NVIDIA and ATI, Windows XP and Windows7 )

 TG> So - to summarize: It works easiest and most featureful with a ATI 
Card;
 TG>                        It may work with patches and only with WindowsXP
 TG> with an NVIDIA card

 TG> To me it seems that unless someone finds an general approach to
 TG> runtime-detect the NVIDIA-Secific stuff , submitting any patches may be
 TG> to early, as it arouses expectations which only in some cases will be
 TG> met.

 TG> That said - i gladly can forward-port these old patches, if you think
 TG> they are helping in any way.

 TG> Greetings!
 TG> Tobias

 TG> Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
 ??>> Please do not a) top-post or b) cross-post. The latter being aimed at
 ??>> whoever started this thread.
 ??>>
 ??>> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
 ??>>> Yeah, I guess xen has generally been focused on the server end.
 ??>>
 ??>> Xen is focused on whatever people submit patches to do. Many of the
 ??>> core developers are not currently looking at VGA passthrough, we have
 ??>> plenty of stuff on our plates, but we are more than happy to review
 ??>> and accept patches to implement/improve/fix this feature if only those
 ??>> people who are interested in it would take the time to submit them per
 ??>> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
 ??>> going to go out hunting for patches on the Internet.
 ??>>
 ??>> David Techer recently offered to do this but perhaps he would be
 ??>> interested in some help from you?
 ??>>


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBJ-00026r-6A; Wed, 01 Feb 2012 10:12:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RoKSM-0007UO-PN; Fri, 20 Jan 2012 19:49:03 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327088934!10054314!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22491 invoked from network); 20 Jan 2012 19:48:55 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 19:48:55 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0KJlwcn008649;
	Fri, 20 Jan 2012 21:47:59 +0200
Message-ID: <D8ECC4609A434D96BB8F8FEBC2301EA4@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "chris" <tknchris@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
Date: Fri, 20 Jan 2012 21:48:30 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I will start it only pci video card (not PCIe) and hangs. Although I do 
periodically attempts throughout the year. I also have 2 more cards in the 
same system (ati hd 2600), but can not run any vga pass under fedora, under 
any debain or ubuntu.

I have a motherboard ASUS M4A89TD, which can IOMMU

 c> I'm really surprised this doesnt get more attention. For as long as I've
 c> been on this list, this feature has been mentioned so many times I would
 c> think that getting this working would be a huge feature that would make
 c> the product even better. I have only seen the occasional success with
 c> experimental patches etc, despite this being talked about for years.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBE-00021d-OF; Wed, 01 Feb 2012 10:12:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akinobu.mita@gmail.com>) id 1RoGBm-0004g0-P0
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:15:39 +0000
X-Env-Sender: akinobu.mita@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327072529!10022299!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20998 invoked from network); 20 Jan 2012 15:15:31 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:15:31 -0000
Received: by iahk25 with SMTP id k25so6378417iah.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 07:15:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=4/g2/3g0lcanB/xNM1OBXtLy79eVoMilPafdDO2V8K4=;
	b=bXulivCZ7qW8OTtg5W+fgX9ol404inJgnklOPnIAi7C1iuejFzoS6bPUgw6fqIxVOd
	/gkBzvGBxZUwarKIq+7/NxgF4rDeqeIG+ofXA+n1Hp+1IL5McN+HMEaJCsksal733FgC
	+NtFF9p8Oi1HwJDyrhQYElGDU8G7+XJ3fMzqc=
Received: by 10.50.207.72 with SMTP id lu8mr33285174igc.0.1327072529493;
	Fri, 20 Jan 2012 07:15:29 -0800 (PST)
Received: from localhost.localdomain
	(p2046-adsao01yokonib2-acca.kanagawa.ocn.ne.jp. [61.214.148.46])
	by mx.google.com with ESMTPS id f8sm10882978ibl.6.2012.01.20.07.15.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Jan 2012 07:15:28 -0800 (PST)
From: Akinobu Mita <akinobu.mita@gmail.com>
To: linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org
Date: Sat, 21 Jan 2012 00:15:26 +0900
Message-Id: <1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
X-Mailer: git-send-email 1.7.4.4
In-Reply-To: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use bitmap_set and bitmap_clear rather than modifying individual bits
in a memory region.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
---
 drivers/block/xen-blkfront.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..619868d 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/scatterlist.h>
+#include <linux/bitmap.h>
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
@@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 
 	spin_lock(&minor_lock);
 	if (find_next_bit(minors, end, minor) >= end) {
-		for (; minor < end; ++minor)
-			__set_bit(minor, minors);
+		bitmap_set(minors, minor, nr);
 		rc = 0;
 	} else
 		rc = -EBUSY;
@@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, unsigned int nr)
 
 	BUG_ON(end > nr_minors);
 	spin_lock(&minor_lock);
-	for (; minor < end; ++minor)
-		__clear_bit(minor, minors);
+	bitmap_clear(minors,  minor, nr);
 	spin_unlock(&minor_lock);
 }
 
-- 
1.7.4.4


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBE-00021d-OF; Wed, 01 Feb 2012 10:12:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akinobu.mita@gmail.com>) id 1RoGBm-0004g0-P0
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:15:39 +0000
X-Env-Sender: akinobu.mita@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327072529!10022299!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20998 invoked from network); 20 Jan 2012 15:15:31 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:15:31 -0000
Received: by iahk25 with SMTP id k25so6378417iah.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 07:15:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=4/g2/3g0lcanB/xNM1OBXtLy79eVoMilPafdDO2V8K4=;
	b=bXulivCZ7qW8OTtg5W+fgX9ol404inJgnklOPnIAi7C1iuejFzoS6bPUgw6fqIxVOd
	/gkBzvGBxZUwarKIq+7/NxgF4rDeqeIG+ofXA+n1Hp+1IL5McN+HMEaJCsksal733FgC
	+NtFF9p8Oi1HwJDyrhQYElGDU8G7+XJ3fMzqc=
Received: by 10.50.207.72 with SMTP id lu8mr33285174igc.0.1327072529493;
	Fri, 20 Jan 2012 07:15:29 -0800 (PST)
Received: from localhost.localdomain
	(p2046-adsao01yokonib2-acca.kanagawa.ocn.ne.jp. [61.214.148.46])
	by mx.google.com with ESMTPS id f8sm10882978ibl.6.2012.01.20.07.15.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 20 Jan 2012 07:15:28 -0800 (PST)
From: Akinobu Mita <akinobu.mita@gmail.com>
To: linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org
Date: Sat, 21 Jan 2012 00:15:26 +0900
Message-Id: <1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
X-Mailer: git-send-email 1.7.4.4
In-Reply-To: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use bitmap_set and bitmap_clear rather than modifying individual bits
in a memory region.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
---
 drivers/block/xen-blkfront.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..619868d 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/scatterlist.h>
+#include <linux/bitmap.h>
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
@@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
 
 	spin_lock(&minor_lock);
 	if (find_next_bit(minors, end, minor) >= end) {
-		for (; minor < end; ++minor)
-			__set_bit(minor, minors);
+		bitmap_set(minors, minor, nr);
 		rc = 0;
 	} else
 		rc = -EBUSY;
@@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, unsigned int nr)
 
 	BUG_ON(end > nr_minors);
 	spin_lock(&minor_lock);
-	for (; minor < end; ++minor)
-		__clear_bit(minor, minors);
+	bitmap_clear(minors,  minor, nr);
 	spin_unlock(&minor_lock);
 }
 
-- 
1.7.4.4


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBO-0002Hm-MQ; Wed, 01 Feb 2012 10:12:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RphSw-0002Ax-GK; Tue, 24 Jan 2012 14:35:18 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327415711!12171674!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17068 invoked from network); 24 Jan 2012 14:35:12 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:35:12 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OEXEUU025167;
	Tue, 24 Jan 2012 16:33:14 +0200
Message-ID: <3758972BBA474BCBB9CA5D1D316892E7@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: <djmagee@mageenet.net>, "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Tobias Geiger" <tobias.geiger@vido.info>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
Date: Tue, 24 Jan 2012 16:33:59 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 ??>>> Hello!
 ??>>>
 ??>>> The thing is, you either dont need patches at all to get it to work
 ??>> (ATI), or
 ??>>> you need to customize patches reflecting your individual setup
 ??>> (NVIDIA);
 ??>>>
 ??>>> To be more specific:
 ??>>> I can confirm that passing through a ATI Card works "out of the box"
 ??>> - either
 ??>>> to Windows 7 or Windows XP;
 ??>>> In the past i had a setup running with a NVIDIA card, it only worked
 ??>> with
 ??>>> special patches (the ones David packed together and offers as
 ??>> tarball) and - as
 ??>>> far as i can tell - are not generaly working for all NVIDIA Cards,
 ??>> i.e. you
 ??>>> have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
 ??>> then the
 ??>>> passed through Card worked only with Windows XP - NOT with Windows
 d> 7;
 ??>>>
 ??>>> Both setup have the "flaw" that they only work once - meaning you
 ??>> can't reboot
 ??>>> your DomU , cause after the reboot the passed-through Card doesnt
 ??>> have correct
 ??>>> 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
 ??>> Windows XP and
 ??>>> Windows7 )
 ??>>
 ??>> For me it was with ATI with Windows7. Hadn't tried other OSes.
 ??>>
 ??>> Anybody had luck with passing the card more than once to a guest? With
 ??>> any random set of patches?
^^^^^^^^^^^^^^^^^^^^^^^^
Better not to quote, than to do wrong quoting!!!
Also see the question below/

 d> Yes, I've had a machine running for a couple of weeks, hosting a Windows
 d> 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
 d> machine multiple times, as well as gone through a couple of xl
 d> destroy/create cycles.

 d> I only pass it through as a secondary card, as I have the IGD as the
 d> primary on the host.  The machine is a DQ67SW with a Core i5.  This is
 d> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.

 d> I haven't, however, had any luck passing through the IGD to anything
 d> other than a Windows XP, and that includes running the latest qemu-xen
 d> with Jean's patches (opregion, host bridge config space mapping).  I've
 d> been intending to start a separate thread for that...

Can you put a youtube video start DomU after
# Xm create
??? 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBO-0002Hm-MQ; Wed, 01 Feb 2012 10:12:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RphSw-0002Ax-GK; Tue, 24 Jan 2012 14:35:18 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327415711!12171674!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17068 invoked from network); 24 Jan 2012 14:35:12 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:35:12 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OEXEUU025167;
	Tue, 24 Jan 2012 16:33:14 +0200
Message-ID: <3758972BBA474BCBB9CA5D1D316892E7@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: <djmagee@mageenet.net>, "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Tobias Geiger" <tobias.geiger@vido.info>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
Date: Tue, 24 Jan 2012 16:33:59 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 ??>>> Hello!
 ??>>>
 ??>>> The thing is, you either dont need patches at all to get it to work
 ??>> (ATI), or
 ??>>> you need to customize patches reflecting your individual setup
 ??>> (NVIDIA);
 ??>>>
 ??>>> To be more specific:
 ??>>> I can confirm that passing through a ATI Card works "out of the box"
 ??>> - either
 ??>>> to Windows 7 or Windows XP;
 ??>>> In the past i had a setup running with a NVIDIA card, it only worked
 ??>> with
 ??>>> special patches (the ones David packed together and offers as
 ??>> tarball) and - as
 ??>>> far as i can tell - are not generaly working for all NVIDIA Cards,
 ??>> i.e. you
 ??>>> have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
 ??>> then the
 ??>>> passed through Card worked only with Windows XP - NOT with Windows
 d> 7;
 ??>>>
 ??>>> Both setup have the "flaw" that they only work once - meaning you
 ??>> can't reboot
 ??>>> your DomU , cause after the reboot the passed-through Card doesnt
 ??>> have correct
 ??>>> 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
 ??>> Windows XP and
 ??>>> Windows7 )
 ??>>
 ??>> For me it was with ATI with Windows7. Hadn't tried other OSes.
 ??>>
 ??>> Anybody had luck with passing the card more than once to a guest? With
 ??>> any random set of patches?
^^^^^^^^^^^^^^^^^^^^^^^^
Better not to quote, than to do wrong quoting!!!
Also see the question below/

 d> Yes, I've had a machine running for a couple of weeks, hosting a Windows
 d> 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
 d> machine multiple times, as well as gone through a couple of xl
 d> destroy/create cycles.

 d> I only pass it through as a secondary card, as I have the IGD as the
 d> primary on the host.  The machine is a DQ67SW with a Core i5.  This is
 d> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.

 d> I haven't, however, had any luck passing through the IGD to anything
 d> other than a Windows XP, and that includes running the latest qemu-xen
 d> with Jean's patches (opregion, host bridge config space mapping).  I've
 d> been intending to start a separate thread for that...

Can you put a youtube video start DomU after
# Xm create
??? 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBH-00024z-PF; Wed, 01 Feb 2012 10:12:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rpydi-0006IR-4J
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 08:55:34 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327481722!12263142!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxNDkzNzk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15879 invoked from network); 25 Jan 2012 08:55:27 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 08:55:27 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 25 Jan 2012 14:25:21 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 25 Jan 2012 14:25:12 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0P8tCOu4034724
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:25:12 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0P8tAlI004415
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 19:55:11 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.124.26])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0P8tACx004410; Wed, 25 Jan 2012 19:55:10 +1100
Message-ID: <4F1FC370.5020506@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 14:25:12 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
In-Reply-To: <4F15BFAE.7060500@linux.vnet.ibm.com>
Content-Type: multipart/mixed; boundary="------------030109060407080508000302"
x-cbid: 12012508-5564-0000-0000-0000011990AE
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

On 01/18/2012 12:06 AM, Raghavendra K T wrote:
> On 01/17/2012 11:09 PM, Alexander Graf wrote:
[...]
>>>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> B. pre-3.2.0 + Jeremy's above patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> C. pre-3.2.0 + Jeremy's above patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = y
>>>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = y
[...]
>> Maybe it'd be a good idea to create a small in-kernel microbenchmark
>> with a couple threads that take spinlocks, then do work for a
>> specified number of cycles, then release them again and start anew. At
>> the end of it, we can check how long the whole thing took for n runs.
>> That would enable us to measure the worst case scenario.
>>
>
> It was a quick test. two iteration of kernbench (=6runs) and had ensured
> cache is cleared.
>
> echo "1" > /proc/sys/vm/drop_caches
> ccache -C. Yes may be I can run test as you mentioned..
>

Sorry for late reply. Was trying to do more performance analysis.
Measured the worst case scenario with a spinlock stress driver
[ attached below ]. I think S1 (below) is what you were
looking for:

2 types of scenarios:
S1.
lock()
increment counter.
unlock()

S2:
do_somework()
lock()
do_conditional_work() /* this is to give variable spinlock hold time */
unlock()

Setup:
Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
core , 64GB RAM, 16 online cpus.
The below results are taken across total 18 Runs of
insmod spinlock_thread.ko nr_spinlock_threads=4 loop_count=4000000

Results:
scenario S1: plain counter
==========================
     total Mega cycles taken for completion (std)
A.  12343.833333      (1254.664021)
B.  12817.111111      (917.791606)
C.  13426.555556      (844.882978)

%improvement w.r.t BASE     -8.77

scenario S2: counter with variable work inside lock + do_work_outside_lock
=========================================================================
A.   25077.888889      (1349.471703)
B.   24906.777778      (1447.853874)
C.   21287.000000      (2731.643644)

%improvement w.r.t BASE      15.12

So it seems we have worst case overhead of around 8%. But we see 
improvement of at-least 15% once when little more time is spent in
critical section.

>>>
>>> Guest Run
>>> ============
>>> case A case B %improvement case C %improvement
>>> 166.999 (15.7613) 161.876 (14.4874) 3.06768 161.24 (12.6497) 3.44852
>>
>> Is this the same machine? Why is the guest 3x slower?
> Yes non - ple machine but with all 16 cpus online. 3x slower you meant
> case A is slower (pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n) ?

Got your point, There were multiple reasons. guest was 32 bit, and had
only 8vcpu  and the current RAM was only 1GB (max 4GB) when I increased
it to 4GB it came around just 127 second.

There is a happy news:
I created a new 64 bit guest and ran with 16GB RAM and 16VCPU.
Kernbench in The pv spinlock (case E)  took just around 42sec (against
57 sec of host), an improvement of around 26% against host.
So its much faster rather than 3x slower.

--------------030109060407080508000302
Content-Type: text/x-csrc;
 name="spinlock_thread.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="spinlock_thread.c"

/*
 * spinlock_thread.c 
 *
 * Author: Raghavendra K T
 *
 * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/sched.h>
#include <linux/kthread.h>
#include <asm/msr.h>

unsigned int start, end, diff;

static struct task_struct **spintask_pid;
static DECLARE_COMPLETION(spintask_exited);

static int total_thread_exit = 0;
static DEFINE_SPINLOCK(counter_spinlock);

#define DEFAULT_NR_THREADS 4
#define DEFAULT_LOOP_COUNT 4000000L

static int nr_spinlock_threads = DEFAULT_NR_THREADS;
static long loop_count = DEFAULT_LOOP_COUNT;

module_param(nr_spinlock_threads, int, S_IRUGO);
module_param(loop_count, long, S_IRUGO);

static long count = 0;
static int a[2][2] = {{2, 5}, {3, 7}};
static int b[2][2] = {{1, 19}, {11, 13}};
static int m[2][2];
static int n[2][2];
static int res[2][2];

static inline void matrix_initialize(int id)
{
	int i, j;
	for (i=0; i<2; i++)
		for(j=0; j<2; j++) {
			m[i][j] = (id + 1) * a[i][j];
			n[i][j] = (id + 1) * b[i][j];
		}
}

static inline void matrix_mult(void)
{
	int i, j, k;
	for (i=0; i<2; i++)
		for (j=0; j<2; j++) {
			res[i][j] = 0;
			for(k=0; k<2; k++) 
				res[i][j] += m[i][k] * n[k][j];
		} 
}

static int input_check_thread(void* arg)
{
	int id = (int)arg;
	long i = loop_count;
	allow_signal(SIGKILL);
#if 0
	matrix_initialize(id);
	matrix_mult();	
#endif
	do {

		spin_lock(&counter_spinlock);
		count++;
#if 0
		if (id%3) 
			matrix_initialize(id);
		else if (id%3 + 1)
			matrix_mult();	
#endif
		spin_unlock(&counter_spinlock);
	} while(i--); 

	spin_lock(&counter_spinlock);
	total_thread_exit++;
	spin_unlock(&counter_spinlock);
	if(total_thread_exit == nr_spinlock_threads) {
		rdtscl(end);
		diff = end - start;
		complete_and_exit(&spintask_exited, 0);
	}

	return 0;
}

static int spinlock_init_module(void)
{
	int i;
	char name[20];
	printk(KERN_INFO "insmod nr_spinlock_threads = %d\n", nr_spinlock_threads);
	spintask_pid = kzalloc(sizeof(struct task_struct *)* nr_spinlock_threads, GFP_KERNEL);
	rdtscl(start);
	for (i=0; i<nr_spinlock_threads; i++)
	{
		sprintf(name, "spintask%d", i);
		spintask_pid[i] = kthread_run(input_check_thread,(void *)i, name);
	}

	return 0;
}

static void spinlock_cleanup_module(void)
{
	wait_for_completion(&spintask_exited);
	kfree(spintask_pid);
	printk(KERN_INFO "rmmod count = %ld time elaspsed=%u\n", count, diff);
}

module_init(spinlock_init_module);
module_exit(spinlock_cleanup_module);

MODULE_PARM_DESC(loopcount, "How many iterations counter should be incremented");
MODULE_PARM_DESC(nr_spinlock_threads, "How many kernel threads to be spawned");
MODULE_AUTHOR("Raghavendra K T");
MODULE_DESCRIPTION("spinlock stress driver");
MODULE_LICENSE("GPL");

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

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

--------------030109060407080508000302--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBF-000220-7S; Wed, 01 Feb 2012 10:12:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akinobu.mita@gmail.com>) id 1RoGN1-0005I0-9R
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:27:15 +0000
X-Env-Sender: akinobu.mita@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327073226!11907360!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31881 invoked from network); 20 Jan 2012 15:27:07 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:27:07 -0000
Received: by qcsd15 with SMTP id d15so8488128qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 07:27:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=/cZlp91nYC7YI7j9qMGGPautcVgVIttF0qVjON42dDs=;
	b=NdNhsUEshZPK0VwkjLmfPAM/DnnpTvnKkMN4ShImPPSBPqmp6AU2gHSjO6p0kACsI4
	TYsKIl68GIUoU48r43hkhJM8NdpKfRJUqZ+TZl9RQC5ohJNUXBs89mlpFzGT8LxHPmFN
	YWLzwV9A0qxGA2N5GevwA2QRP1sGyZj6tTJzQ=
MIME-Version: 1.0
Received: by 10.224.10.19 with SMTP id n19mr33575657qan.68.1327073226279; Fri,
	20 Jan 2012 07:27:06 -0800 (PST)
Received: by 10.229.74.83 with HTTP; Fri, 20 Jan 2012 07:27:06 -0800 (PST)
In-Reply-To: <1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
Date: Sat, 21 Jan 2012 00:27:06 +0900
Message-ID: <CAC5umygu32iS=OaioHYaYtemt7uBOiW51ef7L5UhNPezf3JBsQ@mail.gmail.com>
From: Akinobu Mita <akinobu.mita@gmail.com>
To: linux-kernel@vger.kernel.org, akpm@linux-foundation.org
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I used Jeremy Fitzhardinge's old email address...

2012/1/21 Akinobu Mita <akinobu.mita@gmail.com>:
> Use bitmap_set and bitmap_clear rather than modifying individual bits
> in a memory region.
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Cc: Jeremy Fitzhardinge <jeremy@goop.org>

> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> ---
> =A0drivers/block/xen-blkfront.c | =A0 =A07 +++----
> =A01 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..619868d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -43,6 +43,7 @@
> =A0#include <linux/slab.h>
> =A0#include <linux/mutex.h>
> =A0#include <linux/scatterlist.h>
> +#include <linux/bitmap.h>
>
> =A0#include <xen/xen.h>
> =A0#include <xen/xenbus.h>
> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, un=
signed int nr)
>
> =A0 =A0 =A0 =A0spin_lock(&minor_lock);
> =A0 =A0 =A0 =A0if (find_next_bit(minors, end, minor) >=3D end) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (; minor < end; ++minor)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __set_bit(minor, minors);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bitmap_set(minors, minor, nr);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D 0;
> =A0 =A0 =A0 =A0} else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EBUSY;
> @@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, u=
nsigned int nr)
>
> =A0 =A0 =A0 =A0BUG_ON(end > nr_minors);
> =A0 =A0 =A0 =A0spin_lock(&minor_lock);
> - =A0 =A0 =A0 for (; minor < end; ++minor)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 __clear_bit(minor, minors);
> + =A0 =A0 =A0 bitmap_clear(minors, =A0minor, nr);
> =A0 =A0 =A0 =A0spin_unlock(&minor_lock);
> =A0}
>
> --
> 1.7.4.4
>

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBL-0002Bt-Oe; Wed, 01 Feb 2012 10:12:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIOp-0003ed-I9; Mon, 23 Jan 2012 11:49:23 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327319356!12005474!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8179 invoked from network); 23 Jan 2012 11:49:17 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 11:49:17 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBmVOo022010;
	Mon, 23 Jan 2012 13:48:31 +0200
Message-ID: <027167128F834966B223737A4B5F6DFA@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>, "John Sherwood" <jrs@vt.edu>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com><CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
	<CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
Date: Mon, 23 Jan 2012 13:49:02 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 SR> I am trying to pass my secondary graphics card through to the VM. My
 SR> dom0 runs with the primary card (an onboard GPU).

 SR> What happens with me is that the secondary card (GTX480) is
 SR> relinquished to pciback and according to the logs, it looks like the
 SR> card is passed through successfully to the domU.
 SR> What happens though is a bit puzzling (with gfx_passthru=1):
 SR> 1) When I start the domU, my dom0 screen goes blank (which is using a
 SR> different graphics card than is assigned to the domU)
 SR> 2) The domain does not boot; i.e. the CDROM does not spin up.
 SR> 3) If I connect to the domain via vnc, I see only the qemu console.

The same nonsense. But my video is ATI


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBF-00022K-LR; Wed, 01 Feb 2012 10:12:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akinobu.mita@gmail.com>) id 1RoGbN-0005n4-MZ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:42:05 +0000
X-Env-Sender: akinobu.mita@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327074116!10011969!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29187 invoked from network); 20 Jan 2012 15:41:58 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:41:58 -0000
Received: by qabg27 with SMTP id g27so5136697qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 07:41:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=oi+2PY/ivcl3p9h+GdoVFs7k8ZkZ7TOwT358YpvPdrQ=;
	b=JgcRzIQG68YGSCB7L/PG1zfzll4ygMmTe3pRX8drC4ojhnWP8ov2p9N+/0zBS/dOOJ
	sr7kDe5wRSuAkMclodYjE5NrrBfZnwqzSdLrF5TrDwyye/vwzwfE4M6H53yq9Ozq5kEG
	teO6HY9V9FSZDPQvXSpzQKbLnRcaSkl4Nli5c=
MIME-Version: 1.0
Received: by 10.224.186.209 with SMTP id ct17mr5269224qab.55.1327074116245;
	Fri, 20 Jan 2012 07:41:56 -0800 (PST)
Received: by 10.229.74.83 with HTTP; Fri, 20 Jan 2012 07:41:56 -0800 (PST)
In-Reply-To: <20120120152819.GA3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
Date: Sat, 21 Jan 2012 00:41:56 +0900
Message-ID: <CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: akpm@linux-foundation.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/21 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> On Sat, Jan 21, 2012 at 12:15:26AM +0900, Akinobu Mita wrote:
>> Use bitmap_set and bitmap_clear rather than modifying individual bits
>> in a memory region.
>>
>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: xen-devel@lists.xensource.com
>> Cc: virtualization@lists.linux-foundation.org
>> ---
>> =A0drivers/block/xen-blkfront.c | =A0 =A07 +++----
>> =A01 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 2f22874..619868d 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -43,6 +43,7 @@
>> =A0#include <linux/slab.h>
>> =A0#include <linux/mutex.h>
>> =A0#include <linux/scatterlist.h>
>> +#include <linux/bitmap.h>
>>
>> =A0#include <xen/xen.h>
>> =A0#include <xen/xenbus.h>
>> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, u=
nsigned int nr)
>>
>> =A0 =A0 =A0 spin_lock(&minor_lock);
>> =A0 =A0 =A0 if (find_next_bit(minors, end, minor) >=3D end) {
>> - =A0 =A0 =A0 =A0 =A0 =A0 for (; minor < end; ++minor)
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __set_bit(minor, minors);
>> + =A0 =A0 =A0 =A0 =A0 =A0 bitmap_set(minors, minor, nr);
>
> Hm, I would have thought the last argument should have been 'end'?

'end' is the index of the last bit to clear.  But the last argument of
bitmap_clear() is the number of bits to clear.  So I think 'nr' is correct.

> Did you test this patch with a large amount of minors?

Sorry I didn't do runtime test.

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D 0;
>> =A0 =A0 =A0 } else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY;
>> @@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, =
unsigned int nr)
>>
>> =A0 =A0 =A0 BUG_ON(end > nr_minors);
>> =A0 =A0 =A0 spin_lock(&minor_lock);
>> - =A0 =A0 for (; minor < end; ++minor)
>> - =A0 =A0 =A0 =A0 =A0 =A0 __clear_bit(minor, minors);
>> + =A0 =A0 bitmap_clear(minors, =A0minor, nr);
>
> Ditto.
>> =A0 =A0 =A0 spin_unlock(&minor_lock);
>> =A0}
>>
>> --
>> 1.7.4.4
>>
>> --
>> 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 =A0http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at =A0http://www.tux.org/lkml/

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBH-00024z-PF; Wed, 01 Feb 2012 10:12:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rpydi-0006IR-4J
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 08:55:34 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327481722!12263142!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxNDkzNzk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15879 invoked from network); 25 Jan 2012 08:55:27 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 08:55:27 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 25 Jan 2012 14:25:21 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 25 Jan 2012 14:25:12 +0530
Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0P8tCOu4034724
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:25:12 +0530
Received: from d28av05.in.ibm.com (loopback [127.0.0.1])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0P8tAlI004415
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 19:55:11 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.124.26])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0P8tACx004410; Wed, 25 Jan 2012 19:55:10 +1100
Message-ID: <4F1FC370.5020506@linux.vnet.ibm.com>
Date: Wed, 25 Jan 2012 14:25:12 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
In-Reply-To: <4F15BFAE.7060500@linux.vnet.ibm.com>
Content-Type: multipart/mixed; boundary="------------030109060407080508000302"
x-cbid: 12012508-5564-0000-0000-0000011990AE
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

On 01/18/2012 12:06 AM, Raghavendra K T wrote:
> On 01/17/2012 11:09 PM, Alexander Graf wrote:
[...]
>>>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> B. pre-3.2.0 + Jeremy's above patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> C. pre-3.2.0 + Jeremy's above patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = y
>>>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = y
[...]
>> Maybe it'd be a good idea to create a small in-kernel microbenchmark
>> with a couple threads that take spinlocks, then do work for a
>> specified number of cycles, then release them again and start anew. At
>> the end of it, we can check how long the whole thing took for n runs.
>> That would enable us to measure the worst case scenario.
>>
>
> It was a quick test. two iteration of kernbench (=6runs) and had ensured
> cache is cleared.
>
> echo "1" > /proc/sys/vm/drop_caches
> ccache -C. Yes may be I can run test as you mentioned..
>

Sorry for late reply. Was trying to do more performance analysis.
Measured the worst case scenario with a spinlock stress driver
[ attached below ]. I think S1 (below) is what you were
looking for:

2 types of scenarios:
S1.
lock()
increment counter.
unlock()

S2:
do_somework()
lock()
do_conditional_work() /* this is to give variable spinlock hold time */
unlock()

Setup:
Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
core , 64GB RAM, 16 online cpus.
The below results are taken across total 18 Runs of
insmod spinlock_thread.ko nr_spinlock_threads=4 loop_count=4000000

Results:
scenario S1: plain counter
==========================
     total Mega cycles taken for completion (std)
A.  12343.833333      (1254.664021)
B.  12817.111111      (917.791606)
C.  13426.555556      (844.882978)

%improvement w.r.t BASE     -8.77

scenario S2: counter with variable work inside lock + do_work_outside_lock
=========================================================================
A.   25077.888889      (1349.471703)
B.   24906.777778      (1447.853874)
C.   21287.000000      (2731.643644)

%improvement w.r.t BASE      15.12

So it seems we have worst case overhead of around 8%. But we see 
improvement of at-least 15% once when little more time is spent in
critical section.

>>>
>>> Guest Run
>>> ============
>>> case A case B %improvement case C %improvement
>>> 166.999 (15.7613) 161.876 (14.4874) 3.06768 161.24 (12.6497) 3.44852
>>
>> Is this the same machine? Why is the guest 3x slower?
> Yes non - ple machine but with all 16 cpus online. 3x slower you meant
> case A is slower (pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n) ?

Got your point, There were multiple reasons. guest was 32 bit, and had
only 8vcpu  and the current RAM was only 1GB (max 4GB) when I increased
it to 4GB it came around just 127 second.

There is a happy news:
I created a new 64 bit guest and ran with 16GB RAM and 16VCPU.
Kernbench in The pv spinlock (case E)  took just around 42sec (against
57 sec of host), an improvement of around 26% against host.
So its much faster rather than 3x slower.

--------------030109060407080508000302
Content-Type: text/x-csrc;
 name="spinlock_thread.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="spinlock_thread.c"

/*
 * spinlock_thread.c 
 *
 * Author: Raghavendra K T
 *
 * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/sched.h>
#include <linux/kthread.h>
#include <asm/msr.h>

unsigned int start, end, diff;

static struct task_struct **spintask_pid;
static DECLARE_COMPLETION(spintask_exited);

static int total_thread_exit = 0;
static DEFINE_SPINLOCK(counter_spinlock);

#define DEFAULT_NR_THREADS 4
#define DEFAULT_LOOP_COUNT 4000000L

static int nr_spinlock_threads = DEFAULT_NR_THREADS;
static long loop_count = DEFAULT_LOOP_COUNT;

module_param(nr_spinlock_threads, int, S_IRUGO);
module_param(loop_count, long, S_IRUGO);

static long count = 0;
static int a[2][2] = {{2, 5}, {3, 7}};
static int b[2][2] = {{1, 19}, {11, 13}};
static int m[2][2];
static int n[2][2];
static int res[2][2];

static inline void matrix_initialize(int id)
{
	int i, j;
	for (i=0; i<2; i++)
		for(j=0; j<2; j++) {
			m[i][j] = (id + 1) * a[i][j];
			n[i][j] = (id + 1) * b[i][j];
		}
}

static inline void matrix_mult(void)
{
	int i, j, k;
	for (i=0; i<2; i++)
		for (j=0; j<2; j++) {
			res[i][j] = 0;
			for(k=0; k<2; k++) 
				res[i][j] += m[i][k] * n[k][j];
		} 
}

static int input_check_thread(void* arg)
{
	int id = (int)arg;
	long i = loop_count;
	allow_signal(SIGKILL);
#if 0
	matrix_initialize(id);
	matrix_mult();	
#endif
	do {

		spin_lock(&counter_spinlock);
		count++;
#if 0
		if (id%3) 
			matrix_initialize(id);
		else if (id%3 + 1)
			matrix_mult();	
#endif
		spin_unlock(&counter_spinlock);
	} while(i--); 

	spin_lock(&counter_spinlock);
	total_thread_exit++;
	spin_unlock(&counter_spinlock);
	if(total_thread_exit == nr_spinlock_threads) {
		rdtscl(end);
		diff = end - start;
		complete_and_exit(&spintask_exited, 0);
	}

	return 0;
}

static int spinlock_init_module(void)
{
	int i;
	char name[20];
	printk(KERN_INFO "insmod nr_spinlock_threads = %d\n", nr_spinlock_threads);
	spintask_pid = kzalloc(sizeof(struct task_struct *)* nr_spinlock_threads, GFP_KERNEL);
	rdtscl(start);
	for (i=0; i<nr_spinlock_threads; i++)
	{
		sprintf(name, "spintask%d", i);
		spintask_pid[i] = kthread_run(input_check_thread,(void *)i, name);
	}

	return 0;
}

static void spinlock_cleanup_module(void)
{
	wait_for_completion(&spintask_exited);
	kfree(spintask_pid);
	printk(KERN_INFO "rmmod count = %ld time elaspsed=%u\n", count, diff);
}

module_init(spinlock_init_module);
module_exit(spinlock_cleanup_module);

MODULE_PARM_DESC(loopcount, "How many iterations counter should be incremented");
MODULE_PARM_DESC(nr_spinlock_threads, "How many kernel threads to be spawned");
MODULE_AUTHOR("Raghavendra K T");
MODULE_DESCRIPTION("spinlock stress driver");
MODULE_LICENSE("GPL");

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

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

--------------030109060407080508000302--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBF-000220-7S; Wed, 01 Feb 2012 10:12:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akinobu.mita@gmail.com>) id 1RoGN1-0005I0-9R
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:27:15 +0000
X-Env-Sender: akinobu.mita@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327073226!11907360!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31881 invoked from network); 20 Jan 2012 15:27:07 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:27:07 -0000
Received: by qcsd15 with SMTP id d15so8488128qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 07:27:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=/cZlp91nYC7YI7j9qMGGPautcVgVIttF0qVjON42dDs=;
	b=NdNhsUEshZPK0VwkjLmfPAM/DnnpTvnKkMN4ShImPPSBPqmp6AU2gHSjO6p0kACsI4
	TYsKIl68GIUoU48r43hkhJM8NdpKfRJUqZ+TZl9RQC5ohJNUXBs89mlpFzGT8LxHPmFN
	YWLzwV9A0qxGA2N5GevwA2QRP1sGyZj6tTJzQ=
MIME-Version: 1.0
Received: by 10.224.10.19 with SMTP id n19mr33575657qan.68.1327073226279; Fri,
	20 Jan 2012 07:27:06 -0800 (PST)
Received: by 10.229.74.83 with HTTP; Fri, 20 Jan 2012 07:27:06 -0800 (PST)
In-Reply-To: <1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
Date: Sat, 21 Jan 2012 00:27:06 +0900
Message-ID: <CAC5umygu32iS=OaioHYaYtemt7uBOiW51ef7L5UhNPezf3JBsQ@mail.gmail.com>
From: Akinobu Mita <akinobu.mita@gmail.com>
To: linux-kernel@vger.kernel.org, akpm@linux-foundation.org
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I used Jeremy Fitzhardinge's old email address...

2012/1/21 Akinobu Mita <akinobu.mita@gmail.com>:
> Use bitmap_set and bitmap_clear rather than modifying individual bits
> in a memory region.
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Cc: Jeremy Fitzhardinge <jeremy@goop.org>

> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> ---
> =A0drivers/block/xen-blkfront.c | =A0 =A07 +++----
> =A01 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..619868d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -43,6 +43,7 @@
> =A0#include <linux/slab.h>
> =A0#include <linux/mutex.h>
> =A0#include <linux/scatterlist.h>
> +#include <linux/bitmap.h>
>
> =A0#include <xen/xen.h>
> =A0#include <xen/xenbus.h>
> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, un=
signed int nr)
>
> =A0 =A0 =A0 =A0spin_lock(&minor_lock);
> =A0 =A0 =A0 =A0if (find_next_bit(minors, end, minor) >=3D end) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (; minor < end; ++minor)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __set_bit(minor, minors);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bitmap_set(minors, minor, nr);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D 0;
> =A0 =A0 =A0 =A0} else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rc =3D -EBUSY;
> @@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, u=
nsigned int nr)
>
> =A0 =A0 =A0 =A0BUG_ON(end > nr_minors);
> =A0 =A0 =A0 =A0spin_lock(&minor_lock);
> - =A0 =A0 =A0 for (; minor < end; ++minor)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 __clear_bit(minor, minors);
> + =A0 =A0 =A0 bitmap_clear(minors, =A0minor, nr);
> =A0 =A0 =A0 =A0spin_unlock(&minor_lock);
> =A0}
>
> --
> 1.7.4.4
>

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBF-00022K-LR; Wed, 01 Feb 2012 10:12:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <akinobu.mita@gmail.com>) id 1RoGbN-0005n4-MZ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:42:05 +0000
X-Env-Sender: akinobu.mita@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327074116!10011969!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29187 invoked from network); 20 Jan 2012 15:41:58 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:41:58 -0000
Received: by qabg27 with SMTP id g27so5136697qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 07:41:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=oi+2PY/ivcl3p9h+GdoVFs7k8ZkZ7TOwT358YpvPdrQ=;
	b=JgcRzIQG68YGSCB7L/PG1zfzll4ygMmTe3pRX8drC4ojhnWP8ov2p9N+/0zBS/dOOJ
	sr7kDe5wRSuAkMclodYjE5NrrBfZnwqzSdLrF5TrDwyye/vwzwfE4M6H53yq9Ozq5kEG
	teO6HY9V9FSZDPQvXSpzQKbLnRcaSkl4Nli5c=
MIME-Version: 1.0
Received: by 10.224.186.209 with SMTP id ct17mr5269224qab.55.1327074116245;
	Fri, 20 Jan 2012 07:41:56 -0800 (PST)
Received: by 10.229.74.83 with HTTP; Fri, 20 Jan 2012 07:41:56 -0800 (PST)
In-Reply-To: <20120120152819.GA3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
Date: Sat, 21 Jan 2012 00:41:56 +0900
Message-ID: <CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: akpm@linux-foundation.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/21 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> On Sat, Jan 21, 2012 at 12:15:26AM +0900, Akinobu Mita wrote:
>> Use bitmap_set and bitmap_clear rather than modifying individual bits
>> in a memory region.
>>
>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: xen-devel@lists.xensource.com
>> Cc: virtualization@lists.linux-foundation.org
>> ---
>> =A0drivers/block/xen-blkfront.c | =A0 =A07 +++----
>> =A01 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 2f22874..619868d 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -43,6 +43,7 @@
>> =A0#include <linux/slab.h>
>> =A0#include <linux/mutex.h>
>> =A0#include <linux/scatterlist.h>
>> +#include <linux/bitmap.h>
>>
>> =A0#include <xen/xen.h>
>> =A0#include <xen/xenbus.h>
>> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, u=
nsigned int nr)
>>
>> =A0 =A0 =A0 spin_lock(&minor_lock);
>> =A0 =A0 =A0 if (find_next_bit(minors, end, minor) >=3D end) {
>> - =A0 =A0 =A0 =A0 =A0 =A0 for (; minor < end; ++minor)
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __set_bit(minor, minors);
>> + =A0 =A0 =A0 =A0 =A0 =A0 bitmap_set(minors, minor, nr);
>
> Hm, I would have thought the last argument should have been 'end'?

'end' is the index of the last bit to clear.  But the last argument of
bitmap_clear() is the number of bits to clear.  So I think 'nr' is correct.

> Did you test this patch with a large amount of minors?

Sorry I didn't do runtime test.

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D 0;
>> =A0 =A0 =A0 } else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY;
>> @@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, =
unsigned int nr)
>>
>> =A0 =A0 =A0 BUG_ON(end > nr_minors);
>> =A0 =A0 =A0 spin_lock(&minor_lock);
>> - =A0 =A0 for (; minor < end; ++minor)
>> - =A0 =A0 =A0 =A0 =A0 =A0 __clear_bit(minor, minors);
>> + =A0 =A0 bitmap_clear(minors, =A0minor, nr);
>
> Ditto.
>> =A0 =A0 =A0 spin_unlock(&minor_lock);
>> =A0}
>>
>> --
>> 1.7.4.4
>>
>> --
>> 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 =A0http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at =A0http://www.tux.org/lkml/

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBP-0002KZ-V0; Wed, 01 Feb 2012 10:12:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rpi6z-0004Iu-5s; Tue, 24 Jan 2012 15:16:41 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327418193!12352894!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.6 required=7.0 tests=FORGED_MUA_OUTLOOK,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31294 invoked from network); 24 Jan 2012 15:16:34 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 15:16:34 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OFEhwu026336;
	Tue, 24 Jan 2012 17:14:44 +0200
Message-ID: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<201201241537.24507.tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 17:15:29 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0326410729034144685=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0326410729034144685==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01CCDABB.C57B6680"

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01CCDABB.C57B6680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

TG> I was a bit un-percice regarding the "reboot" issue:

 TG> The passing-through itself works even after a reboot of DomU - the
 TG> rebooted System spits out its Graphics normaly through the
 TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
 TG> After a reboot it doesn't work properly. Meaning:=20
 TG> Slow 3d Performance, i.e.
 TG> unsable for real 3d apps, even a 3d Desktop;
 TG> For example, when the Card gives you 70fps in a Benchmark after a =
fresh
 TG> Cold Boot, it only gives you 5-10fps after a reboot, this will be =
that
 TG> low until you reboot Dom0 also, not only DomU;
 TG> hopefully i described the scenario better now...

I'm sorry. Errors are highlighted in red.

 That is, situations as follows:
- There is a certain group who are trying to make a vga pass, but not =
successed (unsuccessfully)
- In the second group turned out, the performance on the second restart =
the=20
deplorable

I belong to the first group, but I use a pci pass and after 10-20 =
reboots=20
the system does not lose the 3D performance.

Question for Tobias Geiger:
You do not deign to describe the process step by step is the setup and=20
configuration xen-linux-systeM to a successful vga pass?=20


------=_NextPart_000_0031_01CCDABB.C57B6680
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY><FONT size=3D2 face=3DArial>TG&gt; I was a bit un-percice =
regarding the=20
"reboot" issue:<BR><BR>&nbsp;TG&gt; The passing-through itself works =
even after=20
a reboot of DomU - the<BR>&nbsp;TG&gt; rebooted System spits out its =
Graphics=20
normaly through the<BR>&nbsp;TG&gt; passed-through Card (NVIDA or ATI =
doesnt=20
matter here) ; BUT:<BR>&nbsp;TG&gt; After a reboot it doesn't work =
properly.=20
Meaning:=20
<DIV>&nbsp;TG&gt; Slow 3d Performance, i.e.<BR>&nbsp;TG&gt; unsable for =
real 3d=20
apps, even a 3d Desktop;<BR>&nbsp;TG&gt; For example, when the Card =
gives you=20
70fps in a Benchmark after a fresh<BR>&nbsp;TG&gt; Cold Boot, it only =
gives you=20
5-10fps after a reboot, this will be that<BR>&nbsp;TG&gt; low until you =
reboot=20
Dom0 also, not only DomU;<BR>&nbsp;TG&gt; hopefully i described the =
scenario=20
better now...<BR></DIV>
<DIV>I'm sorry. <SPAN id=3Dresult_box lang=3Den class=3Dshort_text=20
closure_uid_bkpfes=3D"182" a=3D"undefined" c=3D"4"><SPAN class=3Dhps=20
closure_uid_bkpfes=3D"6934">Errors</SPAN> <SPAN class=3Dhps=20
closure_uid_bkpfes=3D"6935">are highlighted in red.</SPAN></SPAN></DIV>
<DIV><SPAN lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
a=3D"undefined"=20
c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"6935"></SPAN></SPAN><BR>&nbsp;That is,=20
situations as follows:<BR>- There is a certain group who are trying to =
make a=20
vga pass, but<FONT color=3D#ff0000 size=3D4><STRONG> not</STRONG></FONT> =
successed=20
<STRONG><FONT color=3D#ff0000>(unsuccessfully)</FONT></STRONG><BR>- In =
the second=20
group turned out, the performance on the second restart the=20
<BR>deplorable<BR><BR>I belong to the first group, but I use a pci pass =
and=20
after 10-20 reboots <BR>the system does not lose the 3D=20
performance.<BR><BR>Question for Tobias Geiger:<BR>You do not deign to =
describe=20
the process step by step is the setup and <BR>configuration=20
xen-linux-syste<STRONG><FONT color=3D#ff0000>M</FONT></STRONG> to a =
successful vga=20
pass? <BR><BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0031_01CCDABB.C57B6680--



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

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

--===============0326410729034144685==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBL-0002Bt-Oe; Wed, 01 Feb 2012 10:12:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpIOp-0003ed-I9; Mon, 23 Jan 2012 11:49:23 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327319356!12005474!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8179 invoked from network); 23 Jan 2012 11:49:17 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 11:49:17 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0NBmVOo022010;
	Mon, 23 Jan 2012 13:48:31 +0200
Message-ID: <027167128F834966B223737A4B5F6DFA@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Sandi Romih" <romihs.forums@gmail.com>, "John Sherwood" <jrs@vt.edu>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><3B7B9131A63345CCB34B508E3E4F3507@nobody><CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com><CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
	<CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
Date: Mon, 23 Jan 2012 13:49:02 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 SR> I am trying to pass my secondary graphics card through to the VM. My
 SR> dom0 runs with the primary card (an onboard GPU).

 SR> What happens with me is that the secondary card (GTX480) is
 SR> relinquished to pciback and according to the logs, it looks like the
 SR> card is passed through successfully to the domU.
 SR> What happens though is a bit puzzling (with gfx_passthru=1):
 SR> 1) When I start the domU, my dom0 screen goes blank (which is using a
 SR> different graphics card than is assigned to the domU)
 SR> 2) The domain does not boot; i.e. the CDROM does not spin up.
 SR> 3) If I connect to the domain via vnc, I see only the qemu console.

The same nonsense. But my video is ATI


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:12:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBP-0002KZ-V0; Wed, 01 Feb 2012 10:12:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rpi6z-0004Iu-5s; Tue, 24 Jan 2012 15:16:41 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327418193!12352894!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.6 required=7.0 tests=FORGED_MUA_OUTLOOK,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31294 invoked from network); 24 Jan 2012 15:16:34 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 15:16:34 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0OFEhwu026336;
	Tue, 24 Jan 2012 17:14:44 +0200
Message-ID: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Tobias Geiger" <tobias.geiger@vido.info>, <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<201201241537.24507.tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 17:15:29 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0326410729034144685=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0326410729034144685==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01CCDABB.C57B6680"

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01CCDABB.C57B6680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

TG> I was a bit un-percice regarding the "reboot" issue:

 TG> The passing-through itself works even after a reboot of DomU - the
 TG> rebooted System spits out its Graphics normaly through the
 TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
 TG> After a reboot it doesn't work properly. Meaning:=20
 TG> Slow 3d Performance, i.e.
 TG> unsable for real 3d apps, even a 3d Desktop;
 TG> For example, when the Card gives you 70fps in a Benchmark after a =
fresh
 TG> Cold Boot, it only gives you 5-10fps after a reboot, this will be =
that
 TG> low until you reboot Dom0 also, not only DomU;
 TG> hopefully i described the scenario better now...

I'm sorry. Errors are highlighted in red.

 That is, situations as follows:
- There is a certain group who are trying to make a vga pass, but not =
successed (unsuccessfully)
- In the second group turned out, the performance on the second restart =
the=20
deplorable

I belong to the first group, but I use a pci pass and after 10-20 =
reboots=20
the system does not lose the 3D performance.

Question for Tobias Geiger:
You do not deign to describe the process step by step is the setup and=20
configuration xen-linux-systeM to a successful vga pass?=20


------=_NextPart_000_0031_01CCDABB.C57B6680
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY><FONT size=3D2 face=3DArial>TG&gt; I was a bit un-percice =
regarding the=20
"reboot" issue:<BR><BR>&nbsp;TG&gt; The passing-through itself works =
even after=20
a reboot of DomU - the<BR>&nbsp;TG&gt; rebooted System spits out its =
Graphics=20
normaly through the<BR>&nbsp;TG&gt; passed-through Card (NVIDA or ATI =
doesnt=20
matter here) ; BUT:<BR>&nbsp;TG&gt; After a reboot it doesn't work =
properly.=20
Meaning:=20
<DIV>&nbsp;TG&gt; Slow 3d Performance, i.e.<BR>&nbsp;TG&gt; unsable for =
real 3d=20
apps, even a 3d Desktop;<BR>&nbsp;TG&gt; For example, when the Card =
gives you=20
70fps in a Benchmark after a fresh<BR>&nbsp;TG&gt; Cold Boot, it only =
gives you=20
5-10fps after a reboot, this will be that<BR>&nbsp;TG&gt; low until you =
reboot=20
Dom0 also, not only DomU;<BR>&nbsp;TG&gt; hopefully i described the =
scenario=20
better now...<BR></DIV>
<DIV>I'm sorry. <SPAN id=3Dresult_box lang=3Den class=3Dshort_text=20
closure_uid_bkpfes=3D"182" a=3D"undefined" c=3D"4"><SPAN class=3Dhps=20
closure_uid_bkpfes=3D"6934">Errors</SPAN> <SPAN class=3Dhps=20
closure_uid_bkpfes=3D"6935">are highlighted in red.</SPAN></SPAN></DIV>
<DIV><SPAN lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
a=3D"undefined"=20
c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"6935"></SPAN></SPAN><BR>&nbsp;That is,=20
situations as follows:<BR>- There is a certain group who are trying to =
make a=20
vga pass, but<FONT color=3D#ff0000 size=3D4><STRONG> not</STRONG></FONT> =
successed=20
<STRONG><FONT color=3D#ff0000>(unsuccessfully)</FONT></STRONG><BR>- In =
the second=20
group turned out, the performance on the second restart the=20
<BR>deplorable<BR><BR>I belong to the first group, but I use a pci pass =
and=20
after 10-20 reboots <BR>the system does not lose the 3D=20
performance.<BR><BR>Question for Tobias Geiger:<BR>You do not deign to =
describe=20
the process step by step is the setup and <BR>configuration=20
xen-linux-syste<STRONG><FONT color=3D#ff0000>M</FONT></STRONG> to a =
successful vga=20
pass? <BR><BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0031_01CCDABB.C57B6680--



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

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

--===============0326410729034144685==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBS-0002Ri-Gn; Wed, 01 Feb 2012 10:12:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stern+4f088378@rowland.harvard.edu>)
	id 1RplBf-000152-3C
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:33:43 +0000
Received: from [85.158.138.51:27509] by server-8.bemta-3.messagelabs.com id
	69/0E-31878-689FE1F4; Tue, 24 Jan 2012 18:33:42 +0000
X-Env-Sender: stern+4f088378@rowland.harvard.edu
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327430020!10442366!1
X-Originating-IP: [192.131.102.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12453 invoked from network); 24 Jan 2012 18:33:41 -0000
Received: from iolanthe.rowland.org (HELO iolanthe.rowland.org)
	(192.131.102.54) by server-3.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 18:33:41 -0000
Received: (qmail 1468 invoked by uid 2102); 24 Jan 2012 13:33:37 -0500
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 24 Jan 2012 13:33:37 -0500
Date: Tue, 24 Jan 2012 13:33:37 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Greg KH <greg@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1201241158540.1200-100000@iolanthe.rowland.org>
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, linux-input@vger.kernel.org,
	linux-s390@vger.kernel.org, Andy Walls <awalls@md.metrocast.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jiri Kosina <jkosina@suse.cz>, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, netdev@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Michael Buesch <m@bues.ch>, Joerg Roedel <joerg.roedel@amd.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	USB list <linux-usb@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-pcmcia@lists.infradead.org, linux-media@vger.kernel.org
Subject: [Xen-devel] [PATCH 0/5] Get rid of get_driver() and put_driver()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Greg:

This patch series removes the get_driver() and put_driver() routines
from the kernel.

Those routines don't do anything useful.  Their comments say that they
increment and decrement the driver's reference count, just like
get_device()/put_device() and a lot of other utility routines.  But a
struct driver is _not_ like a struct device!  It resembles a piece of
code more than a piece of data -- it acts as an encapsulation of a
driver.  Incrementing its refcount doesn't have much meaning because a
driver's lifetime isn't determined by the structure's refcount; it's
determined by when the driver's module gets unloaded.

What really matters for a driver is whether or not it is registered.  
Drivers expect, for example, that none of their methods will be called
after driver_unregister() returns.  It doesn't matter if some other
thread still holds a reference to the driver structure; that reference
mustn't be used for accessing the driver code after unregistration.  
get_driver() does not do any checking for this.

People may have been misled by the kerneldoc into thinking that the
references obtained by get_driver() do somehow pin the driver structure
in memory.  This simply isn't true; all it pins is the associated
private structure.  Code that needs to pin a driver must do it some
other way (probably by calling try_module_get()).

In short, these routines don't do anything useful and they can actively 
mislead people.  Removing them won't introduce any bugs that aren't 
already present.  There is no reason to keep them.

Alan Stern


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBS-0002Ri-Gn; Wed, 01 Feb 2012 10:12:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stern+4f088378@rowland.harvard.edu>)
	id 1RplBf-000152-3C
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:33:43 +0000
Received: from [85.158.138.51:27509] by server-8.bemta-3.messagelabs.com id
	69/0E-31878-689FE1F4; Tue, 24 Jan 2012 18:33:42 +0000
X-Env-Sender: stern+4f088378@rowland.harvard.edu
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327430020!10442366!1
X-Originating-IP: [192.131.102.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12453 invoked from network); 24 Jan 2012 18:33:41 -0000
Received: from iolanthe.rowland.org (HELO iolanthe.rowland.org)
	(192.131.102.54) by server-3.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 18:33:41 -0000
Received: (qmail 1468 invoked by uid 2102); 24 Jan 2012 13:33:37 -0500
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 24 Jan 2012 13:33:37 -0500
Date: Tue, 24 Jan 2012 13:33:37 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Greg KH <greg@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1201241158540.1200-100000@iolanthe.rowland.org>
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, linux-input@vger.kernel.org,
	linux-s390@vger.kernel.org, Andy Walls <awalls@md.metrocast.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jiri Kosina <jkosina@suse.cz>, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, netdev@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Michael Buesch <m@bues.ch>, Joerg Roedel <joerg.roedel@amd.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	USB list <linux-usb@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-pcmcia@lists.infradead.org, linux-media@vger.kernel.org
Subject: [Xen-devel] [PATCH 0/5] Get rid of get_driver() and put_driver()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Greg:

This patch series removes the get_driver() and put_driver() routines
from the kernel.

Those routines don't do anything useful.  Their comments say that they
increment and decrement the driver's reference count, just like
get_device()/put_device() and a lot of other utility routines.  But a
struct driver is _not_ like a struct device!  It resembles a piece of
code more than a piece of data -- it acts as an encapsulation of a
driver.  Incrementing its refcount doesn't have much meaning because a
driver's lifetime isn't determined by the structure's refcount; it's
determined by when the driver's module gets unloaded.

What really matters for a driver is whether or not it is registered.  
Drivers expect, for example, that none of their methods will be called
after driver_unregister() returns.  It doesn't matter if some other
thread still holds a reference to the driver structure; that reference
mustn't be used for accessing the driver code after unregistration.  
get_driver() does not do any checking for this.

People may have been misled by the kerneldoc into thinking that the
references obtained by get_driver() do somehow pin the driver structure
in memory.  This simply isn't true; all it pins is the associated
private structure.  Code that needs to pin a driver must do it some
other way (probably by calling try_module_get()).

In short, these routines don't do anything useful and they can actively 
mislead people.  Removing them won't introduce any bugs that aren't 
already present.  There is no reason to keep them.

Alan Stern


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBc-0002by-Fn; Wed, 01 Feb 2012 10:13:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpyD3-0005fb-4W; Wed, 25 Jan 2012 08:28:01 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327480074!11856134!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6363 invoked from network); 25 Jan 2012 08:27:54 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 08:27:54 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0P8Q6ux025024;
	Wed, 25 Jan 2012 10:26:07 +0200
Message-ID: <EE3AE950D047481283FF742510029D1E@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Doug Magee" <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
Date: Wed, 25 Jan 2012 10:26:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

0JfQtNGA0LDQstGB0YLQstGD0LnRgtC1IQoK0JLQviDQstGC0L7RgNC90LjQuiwg0LTQstCw0LTR
htCw0YLRjCDRh9C10YLQstC10YDRgtC+0LPQviDRj9C90LLQsNGA0Y8gMjAxMiDQs9C+0LTQsCwg
0LIgMjA6NDE6Mzgg0JLRiyDQv9C40YHQsNC70Lg6CiBETT4gSSB1c2UgdGhlIHhsIHRvb2xzdGFj
aywgbm90IHhtLiAgSSBkb24ndCB0aGluayB4bSBpcyBiZWluZyBhY3RpdmVseQogRE0+IG1haW50
YWluZWQsIGF0IGxlYXN0IG5vdCBmb3IgY3VycmVudCByZWxlYXNlcy4KCllvdSBjYW4gaW4gYSBu
dXRzaGVsbCB3aGF0IGJldHRlciB4bCB4bT8KCiBETT4gSSBkb24ndCBrbm93IHdoYXQgYSB2aWRl
byBjb3VsZCBzaG93IHlvdS4gIEluIHRoZSBBVEkgY2FzZSwgdGhlcmUncyBubwogRE0+IHNpZ25h
bCB1bnRpbCBXaW5kb3dzIGxvYWRzIHRoZSBkcml2ZXJzLiAgSXQgYXV0b21hdGljYWxseSBkaXNh
YmxlcyB0aGUKIERNPiBlbXVsYXRlZCBhZGFwdGVyLCBzbyBpIGNhbiB3YXRjaCB0aGUgQklPUyBh
bmQgV2luZG93cyBsb2FkaW5nIHNjcmVlbnMKIERNPiB2aWEgVk5DLCB0aGVuIG15IGRlc2t0b3Ag
YXBwZWFycyBvbiB0aGUgbW9uaXRvciBhbmQgdGhlIFZOQyBjb25zb2xlCiBETT4gZ29lcyBibGFj
ay4KCkkgc2F5IHRoYXQgQVRJIHByb2R1Y2VzIHRoZSBzYW1lIGVmZmVjdC4gSSBkbyBub3Qgc2Vl
IGFueXRoaW5nIHVudGlsIHRoZSAKd2VsY29tZSBzY3JlZW4gYW5kIG9ubHkgd2hlbiBnZnhfcGFz
c3RocnUgPSAwLiBJZiBnZnhfcGFzc3RocnUgPSAxIC0gcWVtdSAKc2hlbGwgb24gdm5jIGNvbnNv
bGUgYW5kIGZyZWV6ZWQgZG9tVSA6KAoKIERNPiBJbiB0aGUgSUdEIGNhc2UsIGkgY2FuIHNlZSB0
aGUgb3V0cHV0IGZyb20gUk9NQklPUyBhbmQgdGhlIHdpbmRvd3MKIERNPiBsb2FkZXIgKG9yIGdy
dWIyKSBvbiB0aGUgbW9uaXRvci4gIElmIGknbSBib290aW5nIGEgWFAgZG9tVSwgdGhlCiBETT4g
d2luZG93cyBsb2dpbiBzY3JlZW4gdGhlbiBhcHBlYXJzLiAgSWYgaSdtIGJvb3RpbmcgYSBXaW43
IGRvbVUsIHRoZQogRE0+IHNjcmVlbiBnb2VzIGJsYWNrLiAgSWYgaSdtIGJvb3RpbmcgYSBmZWRv
cmExNiBkb211LCB0aGUgc2lnbmFsIHZhbmlzaGVzCiBETT4gZW50aXJlbHkuIEluIHRoZSBXaW43
IGNhc2UsIHRoZSBkb21VIHNlZW1zIHRvIGJlIHN0dWNrIGluIGEgbG9vcC4gIEluCiBETT4gdGhl
IEZlZG9yYSBjYXNlLCBpIGNhbiBzc2ggdG8gdGhlIG1hY2hpbmUgYW5kIHNlZSB2YXJpb3VzIFdB
Uk5fT04gZHVtcHMKIERNPiBpbiBkbWVzZyByZWxhdGVkIHRvIHRoZSBpOTE1IGRyaXZlciwgYW5k
IGV2ZW50dWFsbHksIGEgbWVzc2FnZSBzYXlpbmcKIERNPiBpdCBmYWlsZWQgdG8gcmVzZXQgdGhl
IGFkYXB0ZXIuCgogRE0+IEkgdGhpbmsgdGhhdCBnaXZlcyB5b3UgbW9yZSBkZXRhaWwgdGhhbiBh
bnkgdmlkZW8gaSBjb3VsZCBwb3N0LgoKWWVzLCB5b3VyIHBvc3QgaXMgcmVhbGx5IGJldHRlciB2
aWRlbwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDov
L2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBc-0002by-Fn; Wed, 01 Feb 2012 10:13:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RpyD3-0005fb-4W; Wed, 25 Jan 2012 08:28:01 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327480074!11856134!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6363 invoked from network); 25 Jan 2012 08:27:54 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 08:27:54 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0P8Q6ux025024;
	Wed, 25 Jan 2012 10:26:07 +0200
Message-ID: <EE3AE950D047481283FF742510029D1E@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Doug Magee" <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
Date: Wed, 25 Jan 2012 10:26:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

0JfQtNGA0LDQstGB0YLQstGD0LnRgtC1IQoK0JLQviDQstGC0L7RgNC90LjQuiwg0LTQstCw0LTR
htCw0YLRjCDRh9C10YLQstC10YDRgtC+0LPQviDRj9C90LLQsNGA0Y8gMjAxMiDQs9C+0LTQsCwg
0LIgMjA6NDE6Mzgg0JLRiyDQv9C40YHQsNC70Lg6CiBETT4gSSB1c2UgdGhlIHhsIHRvb2xzdGFj
aywgbm90IHhtLiAgSSBkb24ndCB0aGluayB4bSBpcyBiZWluZyBhY3RpdmVseQogRE0+IG1haW50
YWluZWQsIGF0IGxlYXN0IG5vdCBmb3IgY3VycmVudCByZWxlYXNlcy4KCllvdSBjYW4gaW4gYSBu
dXRzaGVsbCB3aGF0IGJldHRlciB4bCB4bT8KCiBETT4gSSBkb24ndCBrbm93IHdoYXQgYSB2aWRl
byBjb3VsZCBzaG93IHlvdS4gIEluIHRoZSBBVEkgY2FzZSwgdGhlcmUncyBubwogRE0+IHNpZ25h
bCB1bnRpbCBXaW5kb3dzIGxvYWRzIHRoZSBkcml2ZXJzLiAgSXQgYXV0b21hdGljYWxseSBkaXNh
YmxlcyB0aGUKIERNPiBlbXVsYXRlZCBhZGFwdGVyLCBzbyBpIGNhbiB3YXRjaCB0aGUgQklPUyBh
bmQgV2luZG93cyBsb2FkaW5nIHNjcmVlbnMKIERNPiB2aWEgVk5DLCB0aGVuIG15IGRlc2t0b3Ag
YXBwZWFycyBvbiB0aGUgbW9uaXRvciBhbmQgdGhlIFZOQyBjb25zb2xlCiBETT4gZ29lcyBibGFj
ay4KCkkgc2F5IHRoYXQgQVRJIHByb2R1Y2VzIHRoZSBzYW1lIGVmZmVjdC4gSSBkbyBub3Qgc2Vl
IGFueXRoaW5nIHVudGlsIHRoZSAKd2VsY29tZSBzY3JlZW4gYW5kIG9ubHkgd2hlbiBnZnhfcGFz
c3RocnUgPSAwLiBJZiBnZnhfcGFzc3RocnUgPSAxIC0gcWVtdSAKc2hlbGwgb24gdm5jIGNvbnNv
bGUgYW5kIGZyZWV6ZWQgZG9tVSA6KAoKIERNPiBJbiB0aGUgSUdEIGNhc2UsIGkgY2FuIHNlZSB0
aGUgb3V0cHV0IGZyb20gUk9NQklPUyBhbmQgdGhlIHdpbmRvd3MKIERNPiBsb2FkZXIgKG9yIGdy
dWIyKSBvbiB0aGUgbW9uaXRvci4gIElmIGknbSBib290aW5nIGEgWFAgZG9tVSwgdGhlCiBETT4g
d2luZG93cyBsb2dpbiBzY3JlZW4gdGhlbiBhcHBlYXJzLiAgSWYgaSdtIGJvb3RpbmcgYSBXaW43
IGRvbVUsIHRoZQogRE0+IHNjcmVlbiBnb2VzIGJsYWNrLiAgSWYgaSdtIGJvb3RpbmcgYSBmZWRv
cmExNiBkb211LCB0aGUgc2lnbmFsIHZhbmlzaGVzCiBETT4gZW50aXJlbHkuIEluIHRoZSBXaW43
IGNhc2UsIHRoZSBkb21VIHNlZW1zIHRvIGJlIHN0dWNrIGluIGEgbG9vcC4gIEluCiBETT4gdGhl
IEZlZG9yYSBjYXNlLCBpIGNhbiBzc2ggdG8gdGhlIG1hY2hpbmUgYW5kIHNlZSB2YXJpb3VzIFdB
Uk5fT04gZHVtcHMKIERNPiBpbiBkbWVzZyByZWxhdGVkIHRvIHRoZSBpOTE1IGRyaXZlciwgYW5k
IGV2ZW50dWFsbHksIGEgbWVzc2FnZSBzYXlpbmcKIERNPiBpdCBmYWlsZWQgdG8gcmVzZXQgdGhl
IGFkYXB0ZXIuCgogRE0+IEkgdGhpbmsgdGhhdCBnaXZlcyB5b3UgbW9yZSBkZXRhaWwgdGhhbiBh
bnkgdmlkZW8gaSBjb3VsZCBwb3N0LgoKWWVzLCB5b3VyIHBvc3QgaXMgcmVhbGx5IGJldHRlciB2
aWRlbwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDov
L2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBj-0002ft-LQ; Wed, 01 Feb 2012 10:13:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RpzUe-0007wi-1h
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:50:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327484989!50156705!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22977 invoked from network); 25 Jan 2012 09:49:49 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 09:49:49 -0000
Received: by wibhm2 with SMTP id hm2so4744738wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 01:50:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=51A2ebY6gr7L9rWQgJMuwZUXP9WRAxeMHeavbb4doaE=;
	b=SxPMmZqPOyO54bYXFKJTsyQkS5sIIofzAt7v9v4iOIue8Px8GSNXI4M9H3uFqJn7W1
	0dczbYU+iFxbBdnkqUhDL8rcswWfVXy0nNBqWZoIxjPDEw89X2BkuQnBAB6I3jggsdCe
	ZOVbqtrXPh0cQlOCYDpG9XEBz/fuXXY4/7ntM=
Received: by 10.180.83.104 with SMTP id p8mr9929061wiy.4.1327485010923;
	Wed, 25 Jan 2012 01:50:10 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id di5sm61824275wib.3.2012.01.25.01.50.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Jan 2012 01:50:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6fde017c419e70925f15eb00e8266107011e21cb
Message-Id: <6fde017c419e70925f15.1326761318@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 17 Jan 2012 01:48:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] [PATCH v4] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MjE5MTgxIC0zNjAwCiMgTm9kZSBJRCA2ZmRlMDE3YzQx
OWU3MDkyNWYxNWViMDBlODI2NjEwNzAxMWUyMWNiCiMgUGFyZW50ICA1YjI2NzZhYzEzMjE4OTUx
Njk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL1Rvb2xzLm1rIGFuZCB0b29scy9jb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMg
aW5jbHVkZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRp
b25zIHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBh
c3NpbmcKcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBl
eGVjdXRpbmcgY29uZmlndXJlCnNjcmlwdC4KCnRvb2xzL2NvbmZpZy5oIGlzIHN0aWxsIG5vdCB1
c2VkIGFueXdoZXJlLCBhbmQgaXMgYXV0b21hdGljYWxseQpjcmVhdGVkIGJ5IGF1dG9oZWFkZXIs
IGFsdG91Z2ggdGhpcyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvCmluY2x1ZGUgdGhpcyBm
aWxlLgoKSnVzdCBhIGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9j
b25mIHNjcmlwdCBJIGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhl
cmUuLi4gUGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjM6CgogKiBD
b3BpZWQgY29uZmlnLnN1YiBhbmQgY29uZmlnLmd1ZXNzIGZyb20gYXV0b21ha2UgdmVyc2lvbiAx
LjExLjEKICAgcHJlc2VudCBpbiBEZWJpYW4gc3RhYmxlICg2LjAuMykuCgpDaGFuZ2VzIHNpbmNl
IHYyOgoKICogQ2hhbmdlZCBvcmRlciBvZiBjb25maWcvVG9vbHMubWsgaW5jbHVkZS4KCiAqIEFk
ZGVkICItZSIgdG8gYXV0b2dlbi5zaCBzaGViYW5nLgoKICogQWRkZWQgbmVjZXNzYXJ5IGZpbGVz
IChjb25maWcuKikgYW5kIG91dHB1dCBmcm9tIEF1dG9oZWFkZXIgYW5kCiAgIEF1dG9jb25mLgoK
ICogUmVtb3ZlZCBBdXRvY29uZiBmcm9tIGJ1aWxkIGRlcGVuZGVuY2llcyBhbmQgdXBkYXRlZCBS
RUFETUUuCgpDaGFuZ2VzIHNpbmNlIHYxOgoKICogTW92ZWQgYXV0b2NvbmYgc3R1ZmYgaW5zaWRl
IHRvb2xzIGZvbGRlci4KCiAqIEFkZCBNYWtlZmlsZSBydWxlcyBmb3IgY2xlYW5pbmcuCgogKiBS
ZW1vdmVkIEF1dG9tYWtlIGRlcGVuZGVuY3kuCgogKiBDcmVhdGUgYXV0b2dlbi5zaCB0byBhdXRv
bWF0aWNhbGx5IGNyZWF0ZSBjb25maWd1cmUgc2NyaXB0IHdoZW4KICAgYnVpbGRpbmcgZnJvbSBz
b3VyY2UgcmVwb3NpdG9yeS4KCiAqIENhY2hlZCB2YWx1ZXMgb2Ygb3B0aW9ucyBwYXNzZWQgZnJv
bSBjb21tYW5kIGxpbmUuCgogKiBBZGQgbmVjZXNzYXJ5IGlnbm9yZXMgdG8gLmhnaWdub3JlLgoK
ICogQWRkZWQgQXV0b2NvbmYgdG8gdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVzLgoKICogQ2hhbmdl
ZCBoeXBlbiB0byB1bmRlcnNjb3JlIGluIFhNTDIgYW5kIENVUkwgdmFyaWFibGUgbmFtZXMuCgog
KiBBZGRlZCBzY3JpcHQgdG8gZ2V0IHZlcnNpb24gZnJvbSB4ZW4vTWFrZWZpbGUuCgogKiBTZXQg
T2NhbWwgdG9vbHMgdG8gb3B0aW9uYWwuCgogKiBBZGRlZCBwcm9jZWRlbmNlIG9mIG00L29jYW1s
Lm00LgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBj
LmVkdT4KCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSAuaGdpZ25vcmUKLS0t
IGEvLmhnaWdub3JlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi8uaGdpZ25v
cmUJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0zMDgsNiArMzA4LDEyIEBACiBe
dG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2NhbWwvbGlicy94bC94
ZW5saWdodFwubWxpJAogXnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3RvcmVkJAorXnRvb2xz
L2F1dG9tNHRlXC5jYWNoZSQKK150b29scy9jb25maWdcLmgkCitedG9vbHMvY29uZmlnXC5sb2ck
CitedG9vbHMvY29uZmlnXC5zdGF0dXMkCitedG9vbHMvY29uZmlnXC5jYWNoZSQKK15jb25maWcv
VG9vbHNcLm1rJAogXnhlbi9cLmJhbm5lci4qJAogXnhlbi9CTE9HJAogXnhlbi9TeXN0ZW0ubWFw
JApkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgQ29uZmlnLm1rCi0tLSBhL0Nv
bmZpZy5tawlNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIGIvQ29uZmlnLm1rCVR1
ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtNzAsOSArNzAsNiBAQCBFWFRSQV9JTkNM
VURFUyArPSAkKEVYVFJBX1BSRUZJWCkvaW5jbHVkCiBFWFRSQV9MSUIgKz0gJChFWFRSQV9QUkVG
SVgpLyQoTElCTEVBRkRJUikKIGVuZGlmCiAKLUJJU09OCT89IGJpc29uCi1GTEVYCT89IGZsZXgK
LQogUFlUSE9OICAgICAgPz0gcHl0aG9uCiBQWVRIT05fUFJFRklYX0FSRyA/PSAtLXByZWZpeD0i
JChQUkVGSVgpIgogIyBUaGUgYWJvdmUgcmVxdWlyZXMgdGhhdCBQUkVGSVggY29udGFpbnMgKm5v
IHNwYWNlcyouIFRoaXMgdmFyaWFibGUgaXMgaGVyZQpAQCAtMTc1LDIyICsxNzIsOSBAQCBDRkxB
R1MgKz0gJChmb3JlYWNoIGksICQoUFJFUEVORF9JTkNMVURFCiBBUFBFTkRfTERGTEFHUyArPSAk
KGZvcmVhY2ggaSwgJChBUFBFTkRfTElCKSwgLUwkKGkpKQogQVBQRU5EX0NGTEFHUyArPSAkKGZv
cmVhY2ggaSwgJChBUFBFTkRfSU5DTFVERVMpLCAtSSQoaSkpCiAKLUNIRUNLX0xJQiA9ICQoRVhU
UkFfTElCKSAkKFBSRVBFTkRfTElCKSAkKEFQUEVORF9MSUIpCi1DSEVDS19JTkNMVURFUyA9ICQo
RVhUUkFfSU5DTFVERVMpICQoUFJFUEVORF9JTkNMVURFUykgJChBUFBFTkRfSU5DTFVERVMpCi0K
IEVNQkVEREVEX0VYVFJBX0NGTEFHUyA6PSAtbm9waWUgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1zdGFjay1wcm90ZWN0b3ItYWxsCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgKz0gLWZuby1leGNl
cHRpb25zCiAKLSMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNr
KS4KLVhTTV9FTkFCTEUgPz0gbgotRkxBU0tfRU5BQkxFID89ICQoWFNNX0VOQUJMRSkKLQotIyBE
b3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8K
LSMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3Jr
cyBhdCBhbGwgKGZpcmV3YWxscwotIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZh
dWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKLSMgZmFpbCBvciBoYW5n
LCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCi1HSVRfSFRU
UCA/PSBuCi0KIFhFTl9FWFRGSUxFU19VUkw9aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS94
ZW4tZXh0ZmlsZXMKICMgQWxsIHRoZSBmaWxlcyBhdCB0aGF0IGxvY2F0aW9uIHdlcmUgZG93bmxv
YWRlZCBmcm9tIGVsc2V3aGVyZSBvbgogIyB0aGUgaW50ZXJuZXQuICBUaGUgb3JpZ2luYWwgZG93
bmxvYWQgVVJMIGlzIHByZXNlcnZlZCBhcyBhIGNvbW1lbnQKQEAgLTIyMiwxNyArMjA2LDMgQEAg
UUVNVV9UQUcgPz0gYmIzNmQ2MzJlNGNhYmY0Nzg4MmFkZmYwN2E0NQogIyBOb3RlIHRoYXQgdXNp
bmcgU2VhQklPUyByZXF1aXJlcyB0aGUgdXNlIHRoZSB1cHN0cmVhbSBxZW11IGFzIHRoZQogIyBk
ZXZpY2UgbW9kZWwuCiBTRUFCSU9TX0RJUiA/PSAKLQotIyBPcHRpb25hbCBjb21wb25lbnRzCi1Y
RU5TVEFUX1hFTlRPUCAgICAgPz0geQotVlRQTV9UT09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQ
SV9CSU5ESU5HUyA/PSBuCi1QWVRIT05fVE9PTFMgICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAg
ICAgID89IHkKLUNPTkZJR19NSU5JVEVSTSAgICA/PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0g
bgotQ09ORklHX1NZU1RFTV9MSUJBSU8gPz0geQotCi1pZmVxICgkKE9DQU1MX1RPT0xTKSx5KQot
T0NBTUxfVE9PTFMgOj0gJChzaGVsbCBvY2FtbG9wdCAtdiA+IC9kZXYvbnVsbCAyPiYxICYmIGVj
aG8gInkiIHx8IGVjaG8gIm4iKQotZW5kaWYKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAx
N2M0MTllIE1ha2VmaWxlCi0tLSBhL01ha2VmaWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiAr
MDEwMAorKysgYi9NYWtlZmlsZQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTQw
LDExICs0MCw5IEBAIGRpc3Q6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0OiBkaXN0
LXhlbiBkaXN0LWtlcm5lbHMgZGlzdC10b29scyBkaXN0LXN0dWJkb20gZGlzdC1kb2NzIGRpc3Qt
bWlzYwogCiBkaXN0LW1pc2M6Ci0JJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawogCSQo
SU5TVEFMTF9EQVRBKSAuL0NPUFlJTkcgJChESVNURElSKQogCSQoSU5TVEFMTF9EQVRBKSAuL1JF
QURNRSAkKERJU1RESVIpCiAJJChJTlNUQUxMX1BST0cpIC4vaW5zdGFsbC5zaCAkKERJU1RESVIp
Ci0JJChJTlNUQUxMX1BST0cpIHRvb2xzL2NoZWNrL2NoayB0b29scy9jaGVjay9jaGVja18qIHRv
b2xzL2NoZWNrL2Z1bmNzLnNoICQoRElTVERJUikvY2hlY2sKIGRpc3QtJTogREVTVERJUj0kKERJ
U1RESVIpL2luc3RhbGwKIGRpc3QtJTogaW5zdGFsbC0lCiAJQDogIyBkbyBub3RoaW5nCmRpZmYg
LXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSBSRUFETUUKLS0tIGEvUkVBRE1FCU1vbiBK
YW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi9SRUFETUUJVHVlIEphbiAxMCAxOToxMzow
MSAyMDEyICswMTAwCkBAIC04Nyw5ICs4NywxMyBAQCAyLiBjZCB0byB4ZW4tdW5zdGFibGUgKG9y
IHdoYXRldmVyIHlvdSBzCiAzLiBGb3IgdGhlIHZlcnkgZmlyc3QgYnVpbGQsIG9yIGlmIHlvdSB3
YW50IHRvIGRlc3Ryb3kgYnVpbGQgdHJlZXMsCiAgICBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgc3Rl
cHM6CiAKKyAgICAjIC4vY29uZmlndXJlCiAgICAgIyBtYWtlIHdvcmxkCiAgICAgIyBtYWtlIGlu
c3RhbGwKIAorICAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29uZmlndXJlIC0taGVscCB0
byBzZWUgdGhlIGxpc3Qgb2YKKyAgIG9wdGlvbnMgYXZhaWxhYmxlIG9wdGlvbnMgd2hlbiBidWls
ZGluZyBhbmQgaW5zdGFsbGluZyBYZW4uCisKICAgIFRoaXMgd2lsbCBjcmVhdGUgYW5kIGluc3Rh
bGwgb250byB0aGUgbG9jYWwgbWFjaGluZS4gSXQgd2lsbCBidWlsZAogICAgdGhlIHhlbiBiaW5h
cnkgKHhlbi5neiksIHRoZSB0b29scyBhbmQgdGhlIGRvY3VtZW50YXRpb24uCiAKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIGF1dG9nZW4uc2gKLS0tIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvYXV0b2dlbi5zaAlUdWUgSmFuIDEwIDE5
OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSw5IEBACisjIS9iaW4vc2ggLWUKK3JtIC1yZiBj
b25maWd1cmUKK2NkIHRvb2xzCithdXRvaGVhZGVyCithdXRvY29uZgorY2QgLi4KK2VjaG8gIiMh
L2Jpbi9zaCAtZSIgPj4gY29uZmlndXJlCitlY2hvICJjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSBc
JEAiID4+IGNvbmZpZ3VyZQorY2htb2QgK3ggY29uZmlndXJlCmRpZmYgLXIgNWIyNjc2YWMxMzIx
IC1yIDZmZGUwMTdjNDE5ZSBjb25maWcvVG9vbHMubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvY29uZmlnL1Rvb2xzLm1rLmluCVR1ZSBKYW4g
MTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDUwIEBACisjIFByZWZpeCBhbmQgaW5z
dGFsbCBmb2xkZXIKK1BSRUZJWCAgICAgICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJf
eDg2XzY0ICAgOj0gQExJQl9QQVRIQAorCisjIEEgZGVidWcgYnVpbGQgb2YgdG9vbHM/CitkZWJ1
ZyAgICAgICAgICAgICAgIDo9IEBkZWJ1Z0AKKworIyBUb29scyBwYXRoCitCSVNPTiAgICAgICAg
ICAgICAgIDo9IEBCSVNPTkAKK0ZMRVggICAgICAgICAgICAgICAgOj0gQEZMRVhACitQWVRIT04g
ICAgICAgICAgICAgIDo9IEBQWVRIT05ACitQWVRIT05fUEFUSCAgICAgICAgIDo9IEBQWVRIT05Q
QVRIQAorUEVSTCAgICAgICAgICAgICAgICA6PSBAUEVSTEAKK0JSQ1RMICAgICAgICAgICAgICAg
Oj0gQEJSQ1RMQAorSVAgICAgICAgICAgICAgICAgICA6PSBASVBACitDVVJMX0NPTkZJRyAgICAg
ICAgIDo9IEBDVVJMQAorWE1MMl9DT05GSUcgICAgICAgICA6PSBAWE1MQAorQkFTSCAgICAgICAg
ICAgICAgICA6PSBAQkFTSEAKK1hHRVRUVEVYVCAgICAgICAgICAgOj0gQFhHRVRURVhUQAorCisj
IEV4dHJhIGZvbGRlciBmb3IgbGlicy9pbmNsdWRlcworUFJFUEVORF9JTkNMVURFUyAgICA6PSBA
UFJFUEVORF9JTkNMVURFU0AKK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElCQAor
QVBQRU5EX0lOQ0xVREVTICAgICA6PSBAQVBQRU5EX0lOQ0xVREVTQAorQVBQRU5EX0xJQiAgICAg
ICAgICA6PSBAQVBQRU5EX0xJQkAKKworIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkg
ZGVmYXVsdCwgRmxhc2spLgorWFNNX0VOQUJMRSAgICAgICAgICA6PSBAeHNtQAorRkxBU0tfRU5B
QkxFICAgICAgICA6PSBAeHNtQAorCisjIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhU
VFAgb3IgR0lUJ3Mgb3duIHByb3RvY29sPworIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5k
IG1vcmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCisjIG1heSBibG9j
ayBpdCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5
IGRvd25sb2FkcworIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4g
eW91ciBlbnZpcm9ubWVudC4KK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBACisKKyMg
T3B0aW9uYWwgY29tcG9uZW50cworWEVOU1RBVF9YRU5UT1AgICAgICA6PSBAbW9uaXRvcnNACitW
VFBNX1RPT0xTICAgICAgICAgIDo9IEB2dHBtQAorTElCWEVOQVBJX0JJTkRJTkdTICA6PSBAeGFw
aUAKK1BZVEhPTl9UT09MUyAgICAgICAgOj0gQHB5dGhvbnRvb2xzQAorT0NBTUxfVE9PTFMgICAg
ICAgICA6PSBAb2NhbWx0b29sc0AKK0NPTkZJR19NSU5JVEVSTSAgICAgOj0gQG1pbml0ZXJtQAor
Q09ORklHX0xPTU9VTlQgICAgICA6PSBAbG9tb3VudEAKKworI1N5c3RlbSBvcHRpb25zCitDT05G
SUdfU1lTVEVNX0xJQkFJTzo9IEBzeXN0ZW1fYWlvQAorQ09ORklHX0xJQklDT05WICAgICA6PSBA
bGliaWNvbnZACitDT05GSUdfR0NSWVBUICAgICAgIDo9IEBsaWJnY3J5cHRACitDT05GSUdfRVhU
MkZTICAgICAgIDo9IEBsaWJleHQyZnNACmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdj
NDE5ZSBjb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIvY29uZmlndXJlCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCww
ICsxLDIgQEAKKyMhL2Jpbi9zaCAtZQorY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgJEAKZGlmZiAt
ciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL01ha2VmaWxlCi0tLSBhL3Rvb2xz
L01ha2VmaWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9NYWtl
ZmlsZQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTYsNyArNiw2IEBAIFNVQkRJ
UlMtbGliYWlvIDo9IGxpYmFpbwogZW5kaWYKIAogU1VCRElSUy15IDo9Ci1TVUJESVJTLXkgKz0g
Y2hlY2sKIFNVQkRJUlMteSArPSBpbmNsdWRlCiBTVUJESVJTLXkgKz0gbGlieGMKIFNVQkRJUlMt
eSArPSBmbGFzawpAQCAtNzYsNiArNzUsOCBAQCBjbGVhbjogc3ViZGlycy1jbGVhbgogLlBIT05Z
OiBkaXN0Y2xlYW4KIGRpc3RjbGVhbjogc3ViZGlycy1kaXN0Y2xlYW4KIAlybSAtcmYgaW9lbXUt
ZGlyIGlvZW11LXJlbW90ZQorCXJtIC1yZiAuLi9jb25maWcvVG9vbHMubWsgY29uZmlnLmggY29u
ZmlnLmxvZyBjb25maWcuc3RhdHVzIFwKKyAgICAgICAgICAgICAgIGNvbmZpZy5jYWNoZSBhdXRv
bTR0ZS5jYWNoZQogCiBpZm5lcSAoJChYRU5fQ09NUElMRV9BUkNIKSwkKFhFTl9UQVJHRVRfQVJD
SCkpCiBJT0VNVV9DT05GSUdVUkVfQ1JPU1MgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gpIFwK
ZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL1J1bGVzLm1rCi0tLSBh
L3Rvb2xzL1J1bGVzLm1rCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29s
cy9SdWxlcy5tawlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTQsNiArNCw3IEBA
CiBhbGw6CiAKIGluY2x1ZGUgJChYRU5fUk9PVCkvQ29uZmlnLm1rCitpbmNsdWRlICQoWEVOX1JP
T1QpL2NvbmZpZy9Ub29scy5tawogCiBleHBvcnQgX0lOU1RBTEwgOj0gJChJTlNUQUxMKQogSU5T
VEFMTCA9ICQoWEVOX1JPT1QpL3Rvb2xzL2Nyb3NzLWluc3RhbGwKQEAgLTgwLDggKzgxLDYgQEAg
Y2hlY2stJChDT05GSUdfWDg2KSA9ICQoY2FsbCBjYy12ZXItY2hlYwogICAgICAgICAgICAgICAg
ICAgICAgICAgIlhlbiByZXF1aXJlcyBhdCBsZWFzdCBnY2MtMy40IikKICQoZXZhbCAkKGNoZWNr
LXkpKQogCi1fUFlUSE9OX1BBVEggOj0gJChzaGVsbCB3aGljaCAkKFBZVEhPTikpCi1QWVRIT05f
UEFUSCA/PSAkKF9QWVRIT05fUEFUSCkKIElOU1RBTExfUFlUSE9OX1BST0cgPSBcCiAJJChYRU5f
Uk9PVCkvdG9vbHMvcHl0aG9uL2luc3RhbGwtd3JhcCAiJChQWVRIT05fUEFUSCkiICQoSU5TVEFM
TF9QUk9HKQogCkBAIC0xMDksMyArMTA4LDcgQEAgc3ViZGlyLWFsbC0lIHN1YmRpci1jbGVhbi0l
IHN1YmRpci1pbnN0YQogCiBzdWJkaXItZGlzdGNsZWFuLSU6IC5waG9ueQogCSQoTUFLRSkgLUMg
JCogY2xlYW4KKworJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1rOgorCUBlY2hvICJZb3UgaGF2
ZSB0byBydW4gLi9jb25maWd1cmUgYmVmb3JlIGJ1aWxkaW5nIG9yIGluc3RhbGxpbmcgdGhlIHRv
b2xzIgorCUBleGl0IDEKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xz
L2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2Vm
aWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9ibGt0YXAvZHJp
dmVycy9NYWtlZmlsZQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTEzLDcgKzEz
LDcgQEAgQ0ZMQUdTICAgKz0gJChDRkxBR1NfbGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAk
KE1FTVNIUl9ESVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCiAKLWlmZXEgKCQoc2hlbGwg
LiAuL2NoZWNrX2djcnlwdCAkKENDKSkseWVzKQoraWZlcSAoJENPTkZJR19HQ1JZUFQseSkKIENG
TEFHUyArPSAtRFVTRV9HQ1JZUFQKIENSWVBUX0xJQiA6PSAtbGdjcnlwdAogZWxzZQpkaWZmIC1y
IDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tf
Z2NyeXB0Ci0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAlNb24gSmFuIDA5
IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+IC5nY3J5cHQuYyA8
PCBFT0YKLSNpbmNsdWRlIDxnY3J5cHQuaD4KLWludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0K
LUVPRgotCi1pZiAkMSAtbyAuZ2NyeXB0IC5nY3J5cHQuYyAtbGdjcnlwdCAyPi9kZXYvbnVsbCA7
IHRoZW4KLSAgZWNobyAieWVzIgotZWxzZQotICBlY2hvICJubyIKLWZpCi0KLXJtIC1mIC5nY3J5
cHQqCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9NYWtl
ZmlsZQotLS0gYS90b29scy9jaGVjay9NYWtlZmlsZQlNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIg
KzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MjYgKzAsMCBAQAotWEVOX1JPT1QgPSAkKENVUkRJUikvLi4vLi4KLWluY2x1ZGUgJChYRU5fUk9P
VCkvdG9vbHMvUnVsZXMubWsKLQotIyBFeHBvcnQgdGhlIG5lY2Vzc2FyeSBlbnZpcm9ubWVudCB2
YXJpYWJsZXMgZm9yIHRoZSB0ZXN0cwotZXhwb3J0IFBZVEhPTgotZXhwb3J0IExJQlhFTkFQSV9C
SU5ESU5HUwotZXhwb3J0IENIRUNLX0lOQ0xVREVTCi1leHBvcnQgQ0hFQ0tfTElCCi1leHBvcnQg
Q09ORklHX1NZU1RFTV9MSUJBSU8KLQotLlBIT05ZOiBhbGwgaW5zdGFsbAotYWxsIGluc3RhbGw6
IGNoZWNrLWJ1aWxkCi0KLSMgQ2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBidWlsZGluZyBv
bi4KLS5QSE9OWTogY2hlY2stYnVpbGQKLWNoZWNrLWJ1aWxkOgotCS4vY2hrIGJ1aWxkCi0KLSMg
Q2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBpbnN0YWxsaW5nIG9uLgotLlBIT05ZOiBjaGVj
ay1pbnN0YWxsCi1jaGVjay1pbnN0YWxsOgotCS4vY2hrIGluc3RhbGwKLQotLlBIT05ZOiBjbGVh
bgotY2xlYW46Ci0JLi9jaGsgY2xlYW4KZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0
MTllIHRvb2xzL2NoZWNrL1JFQURNRQotLS0gYS90b29scy9jaGVjay9SRUFETUUJTW9uIEphbiAw
OSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDIwICswLDAgQEAKLUNoZWNrcyBmb3IgdGhlIHN1aXRhYmlsaXR5IG9m
IGEgbWFjaGluZSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuCi1UbyBjaGVjayBmb3IgYnVpbGQg
c3VpdGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgYnVpbGQKLQotVG8gY2hlY2sgZm9yIGlu
c3RhbGwgc3VpdGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgaW5zdGFsbAotCi1UaGUgY2hr
IHNjcmlwdCB3aWxsIHJ1biBjaGVja3MgaW4gdGhpcyBkaXJlY3RvcnkgYW5kIHByaW50Ci10aGUg
b25lcyB0aGF0IGZhaWxlZC4gSXQgcHJpbnRzIG5vdGhpbmcgaWYgY2hlY2tzIHN1Y2NlZWQuCi1U
aGUgY2hrIHNjcmlwdCBleGl0cyB3aXRoIDAgb24gc3VjY2VzcyBhbmQgMSBvbiBmYWlsdXJlLgot
Ci1UaGUgY2hrIHNjcmlwdCBydW5zIGV4ZWN1dGFibGUgZmlsZXMgaW4gdGhpcyBkaXJlY3Rvcnkg
d2hvc2UKLW5hbWVzIGJlZ2luIHdpdGggJ2NoZWNrXycuIEZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0st
QlVJTEQKLWFyZSBydW4gZm9yIHRoZSBidWlsZCBjaGVjaywgYW5kIGZpbGVzIGNvbnRhaW5pbmcg
Q0hFQ0stSU5TVEFMTAotYXJlIHJ1biBmb3IgdGhlIGluc3RhbGwgY2hlY2suCi0KLURldGFpbGVk
IG91dHB1dCBmcm9tIHRoZSBjaGVjayBzY3JpcHRzIGlzIGluIC5jaGtidWlsZCBmb3IgYnVpbGQK
LWFuZCAuY2hraW5zdGFsbCBmb3IgaW5zdGFsbC4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxl
CmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9jaGVja19i
cmN0bAotLS0gYS90b29scy9jaGVjay9jaGVja19icmN0bAlNb24gSmFuIDA5IDE2OjAxOjQ0IDIw
MTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNo
Ci0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9mYWlsIGJy
Y29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBicmN0bCA7OwotKikKLQlmYWlsICJ1bmtu
b3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9v
bHMvY2hlY2svY2hlY2tfY3J5cHRvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19jcnlwdG9f
bGliCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZy
ZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwIDs7Ci1lc2FjCi0KLWhhc19saWIgbGliY3J5
cHRvLnNvIHx8IGZhaWwgIm1pc3NpbmcgbGliY3J5cHRvLnNvIgpkaWZmIC1yIDViMjY3NmFjMTMy
MSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfY3VybAotLS0gYS90b29scy9jaGVj
ay9jaGVja19jdXJsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyAi
JExJQlhFTkFQSV9CSU5ESU5HUyIgIT0gInkiIF07IHRoZW4KLQllY2hvIC1uICJ1bnVzZWQsICIK
LQlleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIGN1cmwtY29uZmlnCi1jdXJsX2xpYnM9YGN1cmwt
Y29uZmlnIC0tbGlic2AgfHwgZmFpbCAiY3VybC1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3Rf
bGluayAkY3VybF9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciBjdXJsIGFy
ZSBtaXNzaW5nIgpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hl
Y2svY2hlY2tfaXByb3V0ZQotLS0gYS90b29scy9jaGVjay9jaGVja19pcHJvdXRlCU1vbiBKYW4g
MDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAot
Ci0uIC4vZnVuY3Muc2gKLQotUEFUSD0vc2JpbjokUEFUSAotCi1jYXNlICRPUyBpbgotT3BlbkJT
RHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBpZmNvbmZpZyA7OwotTGludXgpCi0JaGFz
X29yX2ZhaWwgaXAgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19kZXZl
bAotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwJTW9uIEphbiAwOSAxNjowMTo0
NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Mu
c2gKLQotaWYgWyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAg
IGV4aXQgMAotZmkKLWlmICEgaGFzX2hlYWRlciBsaWJhaW8uaCA7IHRoZW4KLSAgICBmYWlsICJj
YW4ndCBmaW5kIGxpYmFpbyBoZWFkZXJzLCBpbnN0YWxsIGxpYmFpbyBkZXZlbCBwYWNrYWdlIG9y
IHNldCBDT05GSUdfU1lTVEVNX0xJQkFJTz1uIgotZmkKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIg
NmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfbGliYWlvX2xpYglNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQot
aWYgWyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQg
MAotZmkKLWhhc19saWIgbGliYWlvLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGliYWlvIgpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNz
bF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCU1vbiBKYW4gMDkg
MTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMApAQCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4v
ZnVuY3Muc2gKLQotaGFzX2hlYWRlciBvcGVuc3NsL21kNS5oIHx8IGZhaWwgIm1pc3Npbmcgb3Bl
bnNzbCBoZWFkZXJzIgpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMv
Y2hlY2svY2hlY2tfcHl0aG9uCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbglNb24gSmFu
IDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENI
RUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVu
Ci0gIFBZVEhPTj1weXRob24KLWZpCi0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgc3lzCi1zeXMu
ZXhpdChzeXMudmVyc2lvbl9pbmZvWzBdIDwgMiBvciBzeXMudmVyc2lvbl9pbmZvWzFdIDwgMykK
LScgfHwgZmFpbCAibmVlZCBweXRob24gdmVyc2lvbiA+PSAyLjMiCmRpZmYgLXIgNWIyNjc2YWMx
MzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9jaGVja19weXRob25fZGV2ZWwKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX2RldmVsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiAr
MDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwx
NyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlm
IHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3JfZmFp
bCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBvcy5wYXRoLCBzeXMKLWZvciBw
IGluIHN5cy5wYXRoOgotCWlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIp
OgotCQlzeXMuZXhpdCgwKQotc3lzLmV4aXQoMSkKLScgfHwgZmFpbCAiY2FuJ3QgZmluZCBweXRo
b24gZGV2ZWwgZmlsZXMiCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29s
cy9jaGVjay9jaGVja19weXRob25feG1sCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94
bWwJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgot
ICBQWVRIT049cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAt
YyAnaW1wb3J0IHhtbC5kb20ubWluaWRvbScgMj4vZGV2L251bGwgfHwgXAotZmFpbCAiY2FuJ3Qg
aW1wb3J0IHhtbC5kb20ubWluaWRvbSIKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0
MTllIHRvb2xzL2NoZWNrL2NoZWNrX3VkZXYKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdWRldglN
b24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlO
U1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVl
QlNEKQotCWhhc19vcl9mYWlsIHZuY29uZmlnCi0JOzsKLUxpbnV4KQotCWhhcyAvc2Jpbi91ZGV2
YWRtICYmIFwKLQkJdWRldnZlcj1gL3NiaW4vdWRldmFkbSBpbmZvIC1WIHwgYXdrICd7cHJpbnQg
JE5GfSdgCi0JWyAteiAiJHVkZXZ2ZXIiIF0gJiYgaGFzX29yX2ZhaWwgdWRldmluZm8gJiYgXAot
CQl1ZGV2dmVyPWB1ZGV2aW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgIiR1ZGV2dmVy
IiAtZ2UgNTkgXSAyPi9kZXYvbnVsbCB8fCBcCi0JCWhhcyBob3RwbHVnIHx8IFwKLQkJZmFpbCAi
dWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3IgbGF0ZXIiCi0JOzsKLSop
Ci0JZmFpbCAidW5rbm93biBPUyIKLQk7OwotZXNhYwpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2
ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAotLS0gYS90b29scy9jaGVj
ay9jaGVja191dWlkX2RldmVsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw3ICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB1dWlk
LmggfHwgXAotaGFzX2hlYWRlciB1dWlkL3V1aWQuaCB8fCBmYWlsICJtaXNzaW5nIHV1aWQgaGVh
ZGVycyAocGFja2FnZSB1dWlkLWRldikiCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdj
NDE5ZSB0b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
eDExX2RldmVsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciBYMTEva2V5c3ltZGVm
LmggfHwgXAotaGFzX2hlYWRlciAvdXNyL1gxMVI2L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8
IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNy9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi13
YXJuaW5nICJjYW4ndCBmaW5kIFgxMSBoZWFkZXJzIgpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2
ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfeGdldHRleHQKLS0tIGEvdG9vbHMvY2hlY2sv
Y2hlY2tfeGdldHRleHQJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmlu
L3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfb3JfZmFpbCB4Z2V0dGV4
dApkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tf
eG1sMgotLS0gYS90b29scy9jaGVjay9jaGVja194bWwyCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAx
MiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSwxNCArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0u
IC4vZnVuY3Muc2gKLQotaWYgWyAhICIkTElCWEVOQVBJX0JJTkRJTkdTIiA9ICJ5IiBdCi10aGVu
Ci0gICAgZWNobyAtbiAidW51c2VkLCAiCi0gICAgZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCB4
bWwyLWNvbmZpZwoteG1sMl9saWJzPWB4bWwyLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgInhtbDIt
Y29uZmlnIC0tbGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJHhtbDJfbGlicyB8fCBmYWlsICJkZXBl
bmRlbmN5IGxpYnJhcmllcyBmb3IgeG1sMiBhcmUgbWlzc2luZyIKZGlmZiAtciA1YjI2NzZhYzEz
MjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwKLS0tIGEvdG9v
bHMvY2hlY2svY2hlY2tfeWFqbF9kZXZlbAlNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOCArMCww
IEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFk
ZXIgeWFqbC95YWpsX3BhcnNlLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfcGFyc2Uu
aCIKLWhhc19oZWFkZXIgeWFqbC95YWpsX2dlbi5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95
YWpsX2dlbi5oIgotaGFzX2xpYiBsaWJ5YWpsLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFq
bC5zbyIKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2No
ZWNrX3lhamxfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfbGliCU1vbiBKYW4gMDkg
MTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMApAQCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1J
TlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfbGliIGxpYnlhamwuc28uMSB8fCBmYWlsICJj
YW4ndCBmaW5kIGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1y
IDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3psaWJfZGV2ZWwJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAot
IyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHps
aWIuaCB8fCBmYWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA1YjI2NzZhYzEz
MjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX3psaWJfbGliCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gK
LQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVz
YWMKLQotaGFzX2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9j
aGVjay9jaGsJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAot
Ci1mdW5jX3VzYWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVp
bGR8aW5zdGFsbHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5
IGZvciBYZW4gYnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ss
IDEgaWYgbm90LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVt
b3ZlcyBnZW5lcmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmlu
Oi91c3Ivc2JpbgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9
ICJTdW5PUyIgXTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQot
ICAgICAgICBjaGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAg
ICAgICAgY2hlY2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAg
ICAgIGV4aXQgMAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAg
ICAgOzsKLWVzYWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1m
b3IgZiBpbiBjaGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAg
ICAgICAgY29udGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7
OwotICAgIGVzYWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUK
LSAgICBmaQotICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNv
bnRpbnVlCi0gICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYg
Mj4mMSA7IHRoZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEK
LSAgICBmaQotZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2
ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Mu
c2gJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2Ft
ZSBhcyB3aGljaCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7
Ci0JaWYgWyAteiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAi
Ci0JCXJldHVybiAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBz
dWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToK
LQlmb3IgcCBpbiAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBd
OyB0aGVuCi0JCQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlm
aQotCWRvbmUKLQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIg
Pi9kZXYvbnVsbCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewot
CWNoZWNrX3N5c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkq
KQotCQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJ
CXJldHVybiAwCi0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJ
aWYgWyAtciAiJENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAw
Ci0JCQlmaQotCQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigp
IHsKLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50
IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRI
ICAgICAgICAjIGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIK
LQotCSMgVGhpcyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0
YWxsZWQgYnV0Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3
b24ndCB3b3JrLgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1Qv
ZXRjL2xkLnNvLmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcg
LXIgXCIkQ1JPU1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBm
YWxsIHRocm91Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsg
IiR7T1N9IiA9ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09U
Ky1yICIkQ1JPU1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkK
LQlpZiBbICIke09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8
IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVz
dF9saW5rKCkgewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0J
dW5zZXQgdG1wZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0J
dG1wZmlsZT1gbWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rl
di9udWxsIDI+JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2Vk
IGNvbW1vbmx5IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElM
RSIgXSAmJiByZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQll
Y2hvICJwbGVhc2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0
dXJuIDEKLQlmaQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8g
Im5vIHN5cy1yb290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQot
fQotCi13YXJuaW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlM
RUQkeyorOiAkKn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1l
ICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA1YjI2NzZhYzEzMjEg
LXIgNmZkZTAxN2M0MTllIHRvb2xzL2NvbmZpZy5ndWVzcwotLS0gL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuZ3Vlc3MJVHVlIEphbiAx
MCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTUwMiBAQAorIyEgL2Jpbi9zaAorIyBB
dHRlbXB0IHRvIGd1ZXNzIGEgY2Fub25pY2FsIHN5c3RlbSBuYW1lLgorIyAgIENvcHlyaWdodCAo
QykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwKKyMgICAy
MDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5
LCAyMDEwCisjICAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3RpbWVzdGFtcD0n
MjAwOS0xMi0zMCcKKworIyBUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAorIyB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAo
YXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMg
ZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJ
VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YK
KyMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg
U2VlIHRoZSBHTlUKKyMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgor
IworIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQ
dWJsaWMgTGljZW5zZQorIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0
byB0aGUgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJl
ZXQgLSBGaWZ0aCBGbG9vciwgQm9zdG9uLCBNQQorIyAwMjExMC0xMzAxLCBVU0EuCisjCisjIEFz
IGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBp
ZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBj
b250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwg
eW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0
aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KKworCisjIE9yaWdpbmFs
bHkgd3JpdHRlbiBieSBQZXIgQm90aG5lci4gIFBsZWFzZSBzZW5kIHBhdGNoZXMgKGNvbnRleHQK
KyMgZGlmZiBmb3JtYXQpIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPiBhbmQgaW5jbHVkZSBh
IENoYW5nZUxvZworIyBlbnRyeS4KKyMKKyMgVGhpcyBzY3JpcHQgYXR0ZW1wdHMgdG8gZ3Vlc3Mg
YSBjYW5vbmljYWwgc3lzdGVtIG5hbWUgc2ltaWxhciB0bworIyBjb25maWcuc3ViLiAgSWYgaXQg
c3VjY2VlZHMsIGl0IHByaW50cyB0aGUgc3lzdGVtIG5hbWUgb24gc3Rkb3V0LCBhbmQKKyMgZXhp
dHMgd2l0aCAwLiAgT3RoZXJ3aXNlLCBpdCBleGl0cyB3aXRoIDEuCisjCisjIFlvdSBjYW4gZ2V0
IHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGlzIHNjcmlwdCBmcm9tOgorIyBodHRwOi8vZ2l0LnNh
dmFubmFoLmdudS5vcmcvZ2l0d2ViLz9wPWNvbmZpZy5naXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmln
Lmd1ZXNzO2hiPUhFQUQKKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3Vz
YWdlPSJcCitVc2FnZTogJDAgW09QVElPTl0KKworT3V0cHV0IHRoZSBjb25maWd1cmF0aW9uIG5h
bWUgb2YgdGhlIHN5c3RlbSBcYCRtZScgaXMgcnVuIG9uLgorCitPcGVyYXRpb24gbW9kZXM6Cisg
IC1oLCAtLWhlbHAgICAgICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtdCwgLS10
aW1lLXN0YW1wICAgcHJpbnQgZGF0ZSBvZiBsYXN0IG1vZGlmaWNhdGlvbiwgdGhlbiBleGl0Cisg
IC12LCAtLXZlcnNpb24gICAgICBwcmludCB2ZXJzaW9uIG51bWJlciwgdGhlbiBleGl0CisKK1Jl
cG9ydCBidWdzIGFuZCBwYXRjaGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4iCisKK3Zl
cnNpb249IlwKK0dOVSBjb25maWcuZ3Vlc3MgKCR0aW1lc3RhbXApCisKK09yaWdpbmFsbHkgd3Jp
dHRlbiBieSBQZXIgQm90aG5lci4KK0NvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5
NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwgMjAwMCwKKzIwMDEsIDIwMDIsIDIwMDMsIDIwMDQs
IDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDksIDIwMTAgRnJlZQorU29mdHdhcmUgRm91bmRh
dGlvbiwgSW5jLgorCitUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUgc291cmNlIGZvciBj
b3B5aW5nIGNvbmRpdGlvbnMuICBUaGVyZSBpcyBOTword2FycmFudHk7IG5vdCBldmVuIGZvciBN
RVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIgorCito
ZWxwPSIKK1RyeSBcYCRtZSAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uLiIKKworIyBQYXJz
ZSBjb21tYW5kIGxpbmUKK3doaWxlIHRlc3QgJCMgLWd0IDAgOyBkbworICBjYXNlICQxIGluCisg
ICAgLS10aW1lLXN0YW1wIHwgLS10aW1lKiB8IC10ICkKKyAgICAgICBlY2hvICIkdGltZXN0YW1w
IiA7IGV4aXQgOzsKKyAgICAtLXZlcnNpb24gfCAtdiApCisgICAgICAgZWNobyAiJHZlcnNpb24i
IDsgZXhpdCA7OworICAgIC0taGVscCB8IC0taCogfCAtaCApCisgICAgICAgZWNobyAiJHVzYWdl
IjsgZXhpdCA7OworICAgIC0tICkgICAgICMgU3RvcCBvcHRpb24gcHJvY2Vzc2luZworICAgICAg
IHNoaWZ0OyBicmVhayA7OworICAgIC0gKQkjIFVzZSBzdGRpbiBhcyBpbnB1dC4KKyAgICAgICBi
cmVhayA7OworICAgIC0qICkKKyAgICAgICBlY2hvICIkbWU6IGludmFsaWQgb3B0aW9uICQxJGhl
bHAiID4mMgorICAgICAgIGV4aXQgMSA7OworICAgICogKQorICAgICAgIGJyZWFrIDs7CisgIGVz
YWMKK2RvbmUKKworaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgIGVjaG8gIiRtZTogdG9vIG1hbnkg
YXJndW1lbnRzJGhlbHAiID4mMgorICBleGl0IDEKK2ZpCisKK3RyYXAgJ2V4aXQgMScgMSAyIDE1
CisKKyMgQ0NfRk9SX0JVSUxEIC0tIGNvbXBpbGVyIHVzZWQgYnkgdGhpcyBzY3JpcHQuIE5vdGUg
dGhhdCB0aGUgdXNlIG9mIGEKKyMgY29tcGlsZXIgdG8gYWlkIGluIHN5c3RlbSBkZXRlY3Rpb24g
aXMgZGlzY291cmFnZWQgYXMgaXQgcmVxdWlyZXMKKyMgdGVtcG9yYXJ5IGZpbGVzIHRvIGJlIGNy
ZWF0ZWQgYW5kLCBhcyB5b3UgY2FuIHNlZSBiZWxvdywgaXQgaXMgYQorIyBoZWFkYWNoZSB0byBk
ZWFsIHdpdGggaW4gYSBwb3J0YWJsZSBmYXNoaW9uLgorCisjIEhpc3RvcmljYWxseSwgYENDX0ZP
Ul9CVUlMRCcgdXNlZCB0byBiZSBuYW1lZCBgSE9TVF9DQycuIFdlIHN0aWxsCisjIHVzZSBgSE9T
VF9DQycgaWYgZGVmaW5lZCwgYnV0IGl0IGlzIGRlcHJlY2F0ZWQuCisKKyMgUG9ydGFibGUgdG1w
IGRpcmVjdG9yeSBjcmVhdGlvbiBpbnNwaXJlZCBieSB0aGUgQXV0b2NvbmYgdGVhbS4KKworc2V0
X2NjX2Zvcl9idWlsZD0nCit0cmFwICJleGl0Y29kZT1cJD87IChybSAtZiBcJHRtcGZpbGVzIDI+
L2Rldi9udWxsOyBybWRpciBcJHRtcCAyPi9kZXYvbnVsbCkgJiYgZXhpdCBcJGV4aXRjb2RlIiAw
IDsKK3RyYXAgInJtIC1mIFwkdG1wZmlsZXMgMj4vZGV2L251bGw7IHJtZGlyIFwkdG1wIDI+L2Rl
di9udWxsOyBleGl0IDEiIDEgMiAxMyAxNSA7Cis6ICR7VE1QRElSPS90bXB9IDsKKyB7IHRtcD1g
KHVtYXNrIDA3NyAmJiBta3RlbXAgLWQgIiRUTVBESVIvY2dYWFhYWFgiKSAyPi9kZXYvbnVsbGAg
JiYgdGVzdCAtbiAiJHRtcCIgJiYgdGVzdCAtZCAiJHRtcCIgOyB9IHx8CisgeyB0ZXN0IC1uICIk
UkFORE9NIiAmJiB0bXA9JFRNUERJUi9jZyQkLSRSQU5ET00gJiYgKHVtYXNrIDA3NyAmJiBta2Rp
ciAkdG1wKSA7IH0gfHwKKyB7IHRtcD0kVE1QRElSL2NnLSQkICYmICh1bWFzayAwNzcgJiYgbWtk
aXIgJHRtcCkgJiYgZWNobyAiV2FybmluZzogY3JlYXRpbmcgaW5zZWN1cmUgdGVtcCBkaXJlY3Rv
cnkiID4mMiA7IH0gfHwKKyB7IGVjaG8gIiRtZTogY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFyeSBk
aXJlY3RvcnkgaW4gJFRNUERJUiIgPiYyIDsgZXhpdCAxIDsgfSA7CitkdW1teT0kdG1wL2R1bW15
IDsKK3RtcGZpbGVzPSIkZHVtbXkuYyAkZHVtbXkubyAkZHVtbXkucmVsICRkdW1teSIgOworY2Fz
ZSAkQ0NfRk9SX0JVSUxELCRIT1NUX0NDLCRDQyBpbgorICwsKSAgICBlY2hvICJpbnQgeDsiID4g
JGR1bW15LmMgOworCWZvciBjIGluIGNjIGdjYyBjODkgYzk5IDsgZG8KKwkgIGlmICgkYyAtYyAt
byAkZHVtbXkubyAkZHVtbXkuYykgPi9kZXYvbnVsbCAyPiYxIDsgdGhlbgorCSAgICAgQ0NfRk9S
X0JVSUxEPSIkYyI7IGJyZWFrIDsKKwkgIGZpIDsKKwlkb25lIDsKKwlpZiB0ZXN0IHgiJENDX0ZP
Ul9CVUlMRCIgPSB4IDsgdGhlbgorCSAgQ0NfRk9SX0JVSUxEPW5vX2NvbXBpbGVyX2ZvdW5kIDsK
KwlmaQorCTs7CisgLCwqKSAgIENDX0ZPUl9CVUlMRD0kQ0MgOzsKKyAsKiwqKSAgQ0NfRk9SX0JV
SUxEPSRIT1NUX0NDIDs7Citlc2FjIDsgc2V0X2NjX2Zvcl9idWlsZD0gOycKKworIyBUaGlzIGlz
IG5lZWRlZCB0byBmaW5kIHVuYW1lIG9uIGEgUHlyYW1pZCBPU3ggd2hlbiBydW4gaW4gdGhlIEJT
RCB1bml2ZXJzZS4KKyMgKGdoYXppQG5vYy5ydXRnZXJzLmVkdSAxOTk0LTA4LTI0KQoraWYgKHRl
c3QgLWYgLy5hdHRiaW4vdW5hbWUpID4vZGV2L251bGwgMj4mMSA7IHRoZW4KKwlQQVRIPSRQQVRI
Oi8uYXR0YmluIDsgZXhwb3J0IFBBVEgKK2ZpCisKK1VOQU1FX01BQ0hJTkU9YCh1bmFtZSAtbSkg
Mj4vZGV2L251bGxgIHx8IFVOQU1FX01BQ0hJTkU9dW5rbm93bgorVU5BTUVfUkVMRUFTRT1gKHVu
YW1lIC1yKSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfUkVMRUFTRT11bmtub3duCitVTkFNRV9TWVNU
RU09YCh1bmFtZSAtcykgMj4vZGV2L251bGxgICB8fCBVTkFNRV9TWVNURU09dW5rbm93bgorVU5B
TUVfVkVSU0lPTj1gKHVuYW1lIC12KSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfVkVSU0lPTj11bmtu
b3duCisKKyMgTm90ZTogb3JkZXIgaXMgc2lnbmlmaWNhbnQgLSB0aGUgY2FzZSBicmFuY2hlcyBh
cmUgbm90IGV4Y2x1c2l2ZS4KKworY2FzZSAiJHtVTkFNRV9NQUNISU5FfToke1VOQU1FX1NZU1RF
TX06JHtVTkFNRV9SRUxFQVNFfToke1VOQU1FX1ZFUlNJT059IiBpbgorICAgICo6TmV0QlNEOio6
KikKKwkjIE5ldEJTRCAobmJzZCkgdGFyZ2V0cyBzaG91bGQgKHdoZXJlIGFwcGxpY2FibGUpIG1h
dGNoIG9uZSBvcgorCSMgbW9yZSBvZiB0aGUgdHVwcGxlczogKi0qLW5ldGJzZGVsZiosICotKi1u
ZXRic2Rhb3V0KiwKKwkjICotKi1uZXRic2RlY29mZiogYW5kICotKi1uZXRic2QqLiAgRm9yIHRh
cmdldHMgdGhhdCByZWNlbnRseQorCSMgc3dpdGNoZWQgdG8gRUxGLCAqLSotbmV0YnNkKiB3b3Vs
ZCBzZWxlY3QgdGhlIG9sZAorCSMgb2JqZWN0IGZpbGUgZm9ybWF0LiAgVGhpcyBwcm92aWRlcyBi
b3RoIGZvcndhcmQKKwkjIGNvbXBhdGliaWxpdHkgYW5kIGEgY29uc2lzdGVudCBtZWNoYW5pc20g
Zm9yIHNlbGVjdGluZyB0aGUKKwkjIG9iamVjdCBmaWxlIGZvcm1hdC4KKwkjCisJIyBOb3RlOiBO
ZXRCU0QgZG9lc24ndCBwYXJ0aWN1bGFybHkgY2FyZSBhYm91dCB0aGUgdmVuZG9yCisJIyBwb3J0
aW9uIG9mIHRoZSBuYW1lLiAgV2UgYWx3YXlzIHNldCBpdCB0byAidW5rbm93biIuCisJc3lzY3Rs
PSJzeXNjdGwgLW4gaHcubWFjaGluZV9hcmNoIgorCVVOQU1FX01BQ0hJTkVfQVJDSD1gKC9zYmlu
LyRzeXNjdGwgMj4vZGV2L251bGwgfHwgXAorCSAgICAvdXNyL3NiaW4vJHN5c2N0bCAyPi9kZXYv
bnVsbCB8fCBlY2hvIHVua25vd24pYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORV9BUkNIfSIgaW4K
KwkgICAgYXJtZWIpIG1hY2hpbmU9YXJtZWItdW5rbm93biA7OworCSAgICBhcm0qKSBtYWNoaW5l
PWFybS11bmtub3duIDs7CisJICAgIHNoM2VsKSBtYWNoaW5lPXNobC11bmtub3duIDs7CisJICAg
IHNoM2ViKSBtYWNoaW5lPXNoLXVua25vd24gOzsKKwkgICAgc2g1ZWwpIG1hY2hpbmU9c2g1bGUt
dW5rbm93biA7OworCSAgICAqKSBtYWNoaW5lPSR7VU5BTUVfTUFDSElORV9BUkNIfS11bmtub3du
IDs7CisJZXNhYworCSMgVGhlIE9wZXJhdGluZyBTeXN0ZW0gaW5jbHVkaW5nIG9iamVjdCBmb3Jt
YXQsIGlmIGl0IGhhcyBzd2l0Y2hlZAorCSMgdG8gRUxGIHJlY2VudGx5LCBvciB3aWxsIGluIHRo
ZSBmdXR1cmUuCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FX0FSQ0h9IiBpbgorCSAgICBhcm0qfGkz
ODZ8bTY4a3xuczMya3xzaDMqfHNwYXJjfHZheCkKKwkJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAor
CQlpZiBlY2hvIF9fRUxGX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwgXAorCQkJ
fCBncmVwIC1xIF9fRUxGX18KKwkJdGhlbgorCQkgICAgIyBPbmNlIGFsbCB1dGlsaXRpZXMgY2Fu
IGJlIEVDT0ZGIChuZXRic2RlY29mZikgb3IgYS5vdXQgKG5ldGJzZGFvdXQpLgorCQkgICAgIyBS
ZXR1cm4gbmV0YnNkIGZvciBlaXRoZXIuICBGSVg/CisJCSAgICBvcz1uZXRic2QKKwkJZWxzZQor
CQkgICAgb3M9bmV0YnNkZWxmCisJCWZpCisJCTs7CisJICAgICopCisJICAgICAgICBvcz1uZXRi
c2QKKwkJOzsKKwllc2FjCisJIyBUaGUgT1MgcmVsZWFzZQorCSMgRGViaWFuIEdOVS9OZXRCU0Qg
bWFjaGluZXMgaGF2ZSBhIGRpZmZlcmVudCB1c2VybGFuZCwgYW5kCisJIyB0aHVzLCBuZWVkIGEg
ZGlzdGluY3QgdHJpcGxldC4gSG93ZXZlciwgdGhleSBkbyBub3QgbmVlZAorCSMga2VybmVsIHZl
cnNpb24gaW5mb3JtYXRpb24sIHNvIGl0IGNhbiBiZSByZXBsYWNlZCB3aXRoIGEKKwkjIHN1aXRh
YmxlIHRhZywgaW4gdGhlIHN0eWxlIG9mIGxpbnV4LWdudS4KKwljYXNlICIke1VOQU1FX1ZFUlNJ
T059IiBpbgorCSAgICBEZWJpYW4qKQorCQlyZWxlYXNlPSctZ251JworCQk7OworCSAgICAqKQor
CQlyZWxlYXNlPWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1stX10uKi9cLi8nYAor
CQk7OworCWVzYWMKKwkjIFNpbmNlIENQVV9UWVBFLU1BTlVGQUNUVVJFUi1LRVJORUwtT1BFUkFU
SU5HX1NZU1RFTToKKwkjIGNvbnRhaW5zIHJlZHVuZGFudCBpbmZvcm1hdGlvbiwgdGhlIHNob3J0
ZXIgZm9ybToKKwkjIENQVV9UWVBFLU1BTlVGQUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNIGlzIHVz
ZWQuCisJZWNobyAiJHttYWNoaW5lfS0ke29zfSR7cmVsZWFzZX0iCisJZXhpdCA7OworICAgICo6
T3BlbkJTRDoqOiopCisJVU5BTUVfTUFDSElORV9BUkNIPWBhcmNoIHwgc2VkICdzL09wZW5CU0Qu
Ly8nYAorCWVjaG8gJHtVTkFNRV9NQUNISU5FX0FSQ0h9LXVua25vd24tb3BlbmJzZCR7VU5BTUVf
UkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpla2tvQlNEOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1la2tvYnNkJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlNv
bGlkQlNEOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zb2xpZGJzZCR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgbWFjcHBjOk1pckJTRDoqOiopCisJZWNobyBwb3dl
cnBjLXVua25vd24tbWlyYnNkJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOk1pckJT
RDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbWlyYnNkJHtVTkFNRV9SRUxF
QVNFfQorCWV4aXQgOzsKKyAgICBhbHBoYTpPU0YxOio6KikKKwljYXNlICRVTkFNRV9SRUxFQVNF
IGluCisJKjQuMCkKKwkJVU5BTUVfUkVMRUFTRT1gL3Vzci9zYmluL3NpemVyIC12IHwgYXdrICd7
cHJpbnQgJDN9J2AKKwkJOzsKKwkqNS4qKQorCSAgICAgICAgVU5BTUVfUkVMRUFTRT1gL3Vzci9z
YmluL3NpemVyIC12IHwgYXdrICd7cHJpbnQgJDR9J2AKKwkJOzsKKwllc2FjCisJIyBBY2NvcmRp
bmcgdG8gQ29tcGFxLCAvdXNyL3NiaW4vcHNyaW5mbyBoYXMgYmVlbiBhdmFpbGFibGUgb24KKwkj
IE9TRi8xIGFuZCBUcnU2NCBzeXN0ZW1zIHByb2R1Y2VkIHNpbmNlIDE5OTUuICBJIGhvcGUgdGhh
dAorCSMgY292ZXJzIG1vc3Qgc3lzdGVtcyBydW5uaW5nIHRvZGF5LiAgVGhpcyBjb2RlIHBpcGVz
IHRoZSBDUFUKKwkjIHR5cGVzIHRocm91Z2ggaGVhZCAtbiAxLCBzbyB3ZSBvbmx5IGRldGVjdCB0
aGUgdHlwZSBvZiBDUFUgMC4KKwlBTFBIQV9DUFVfVFlQRT1gL3Vzci9zYmluL3BzcmluZm8gLXYg
fCBzZWQgLW4gLWUgJ3MvXiAgVGhlIGFscGhhIFwoLipcKSBwcm9jZXNzb3IuKiQvXDEvcCcgfCBo
ZWFkIC1uIDFgCisJY2FzZSAiJEFMUEhBX0NQVV9UWVBFIiBpbgorCSAgICAiRVY0ICgyMTA2NCki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAgIkVWNC41ICgyMTA2NCkiKQorCQlV
TkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAgIkxDQTQgKDIxMDY2LzIxMDY4KSIpCisJCVVO
QU1FX01BQ0hJTkU9ImFscGhhIiA7OworCSAgICAiRVY1ICgyMTE2NCkiKQorCQlVTkFNRV9NQUNI
SU5FPSJhbHBoYWV2NSIgOzsKKwkgICAgIkVWNS42ICgyMTE2NEEpIikKKwkJVU5BTUVfTUFDSElO
RT0iYWxwaGFldjU2IiA7OworCSAgICAiRVY1LjYgKDIxMTY0UEMpIikKKwkJVU5BTUVfTUFDSElO
RT0iYWxwaGFwY2E1NiIgOzsKKwkgICAgIkVWNS43ICgyMTE2NFBDKSIpCisJCVVOQU1FX01BQ0hJ
TkU9ImFscGhhcGNhNTciIDs7CisJICAgICJFVjYgKDIxMjY0KSIpCisJCVVOQU1FX01BQ0hJTkU9
ImFscGhhZXY2IiA7OworCSAgICAiRVY2LjcgKDIxMjY0QSkiKQorCQlVTkFNRV9NQUNISU5FPSJh
bHBoYWV2NjciIDs7CisJICAgICJFVjYuOENCICgyMTI2NEMpIikKKwkJVU5BTUVfTUFDSElORT0i
YWxwaGFldjY4IiA7OworCSAgICAiRVY2LjhBTCAoMjEyNjRCKSIpCisJCVVOQU1FX01BQ0hJTkU9
ImFscGhhZXY2OCIgOzsKKwkgICAgIkVWNi44Q1ggKDIxMjY0RCkiKQorCQlVTkFNRV9NQUNISU5F
PSJhbHBoYWV2NjgiIDs7CisJICAgICJFVjYuOUEgKDIxMjY0L0VWNjlBKSIpCisJCVVOQU1FX01B
Q0hJTkU9ImFscGhhZXY2OSIgOzsKKwkgICAgIkVWNyAoMjEzNjQpIikKKwkJVU5BTUVfTUFDSElO
RT0iYWxwaGFldjciIDs7CisJICAgICJFVjcuOSAoMjEzNjRBKSIpCisJCVVOQU1FX01BQ0hJTkU9
ImFscGhhZXY3OSIgOzsKKwllc2FjCisJIyBBIFBuLm4gdmVyc2lvbiBpcyBhIHBhdGNoZWQgdmVy
c2lvbi4KKwkjIEEgVm4ubiB2ZXJzaW9uIGlzIGEgcmVsZWFzZWQgdmVyc2lvbi4KKwkjIEEgVG4u
biB2ZXJzaW9uIGlzIGEgcmVsZWFzZWQgZmllbGQgdGVzdCB2ZXJzaW9uLgorCSMgQSBYbi5uIHZl
cnNpb24gaXMgYW4gdW5yZWxlYXNlZCBleHBlcmltZW50YWwgYmFzZWxldmVsLgorCSMgMS4yIHVz
ZXMgIjEuMiIgZm9yIHVuYW1lIC1yLgorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1kZWMtb3NmYGVj
aG8gJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9eW1BWVFhdLy8nIHwgdHIgJ0FCQ0RFRkdI
SUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonYAorCWV4aXQg
OzsKKyAgICBBbHBoYVwgKjpXaW5kb3dzX05UKjoqKQorCSMgSG93IGRvIHdlIGtub3cgaXQncyBJ
bnRlcml4IHJhdGhlciB0aGFuIHRoZSBnZW5lcmljIFBPU0lYIHN1YnN5c3RlbT8KKwkjIFNob3Vs
ZCB3ZSBjaGFuZ2UgVU5BTUVfTUFDSElORSBiYXNlZCBvbiB0aGUgb3V0cHV0IG9mIHVuYW1lIGlu
c3RlYWQKKwkjIG9mIHRoZSBzcGVjaWZpYyBBbHBoYSBtb2RlbD8KKwllY2hvIGFscGhhLXBjLWlu
dGVyaXgKKwlleGl0IDs7CisgICAgMjEwNjQ6V2luZG93c19OVDo1MDozKQorCWVjaG8gYWxwaGEt
ZGVjLXdpbm50My41CisJZXhpdCA7OworICAgIEFtaWdhKjpVTklYX1N5c3RlbV9WOjQuMDoqKQor
CWVjaG8gbTY4ay11bmtub3duLXN5c3Y0CisJZXhpdCA7OworICAgICo6W0FhXW1pZ2FbT29dW1Nz
XToqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tYW1pZ2FvcworCWV4aXQgOzsK
KyAgICAqOltNbV1vcnBoW09vXVtTc106KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtu
b3duLW1vcnBob3MKKwlleGl0IDs7CisgICAgKjpPUy8zOTA6KjoqKQorCWVjaG8gaTM3MC1pYm0t
b3BlbmVkaXRpb24KKwlleGl0IDs7CisgICAgKjp6L1ZNOio6KikKKwllY2hvIHMzOTAtaWJtLXp2
bW9lCisJZXhpdCA7OworICAgICo6T1M0MDA6KjoqKQorICAgICAgICBlY2hvIHBvd2VycGMtaWJt
LW9zNDAwCisJZXhpdCA7OworICAgIGFybTpSSVNDKjoxLlswMTJdKjoqfGFybTpyaXNjaXg6MS5b
MDEyXSo6KikKKwllY2hvIGFybS1hY29ybi1yaXNjaXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGFybTpyaXNjb3M6KjoqfGFybTpSSVNDT1M6KjoqKQorCWVjaG8gYXJtLXVua25vd24t
cmlzY29zCisJZXhpdCA7OworICAgIFNSMj8wMTpISS1VWC9NUFA6KjoqIHwgU1I4MDAwOkhJLVVY
L01QUDoqOiopCisJZWNobyBocHBhMS4xLWhpdGFjaGktaGl1eG1wcAorCWV4aXQgOzsKKyAgICBQ
eXJhbWlkKjpPU3gqOio6KiB8IE1JUyo6T1N4KjoqOiogfCBNSVMqOlNNUF9EQy1PU3gqOio6KikK
KwkjIGFrZWVAd3BkaXMwMy53cGFmYi5hZi5taWwgKEVhcmxlIEYuIEFrZSkgY29udHJpYnV0ZWQg
TUlTIGFuZCBOSUxFLgorCWlmIHRlc3QgImAoL2Jpbi91bml2ZXJzZSkgMj4vZGV2L251bGxgIiA9
IGF0dCA7IHRoZW4KKwkJZWNobyBweXJhbWlkLXB5cmFtaWQtc3lzdjMKKwllbHNlCisJCWVjaG8g
cHlyYW1pZC1weXJhbWlkLWJzZAorCWZpCisJZXhpdCA7OworICAgIE5JTEUqOio6KjpkY29zeCkK
KwllY2hvIHB5cmFtaWQtcHlyYW1pZC1zdnI0CisJZXhpdCA7OworICAgIERSUz82MDAwOnVuaXg6
NC4wOjYqKQorCWVjaG8gc3BhcmMtaWNsLW54NgorCWV4aXQgOzsKKyAgICBEUlM/NjAwMDpVTklY
X1NWOjQuMio6NyogfCBEUlM/NjAwMDppc2lzOjQuMio6NyopCisJY2FzZSBgL3Vzci9iaW4vdW5h
bWUgLXBgIGluCisJICAgIHNwYXJjKSBlY2hvIHNwYXJjLWljbC1ueDc7IGV4aXQgOzsKKwllc2Fj
IDs7CisgICAgczM5MHg6U3VuT1M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1pYm0tc29s
YXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7
CisgICAgc3VuNEg6U3VuT1M6NS4qOiopCisJZWNobyBzcGFyYy1oYWwtc29sYXJpczJgZWNobyAk
e1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgc3VuNCo6
U3VuT1M6NS4qOiogfCB0YWRwb2xlKjpTdW5PUzo1Lio6KikKKwllY2hvIHNwYXJjLXN1bi1zb2xh
cmlzMmBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsK
KyAgICBpODZwYzpBdXJvcmFVWDo1Lio6KiB8IGk4NnhlbjpBdXJvcmFVWDo1Lio6KikKKwllY2hv
IGkzODYtcGMtYXVyb3JhdXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIGk4NnBjOlN1
bk9TOjUuKjoqIHwgaTg2eGVuOlN1bk9TOjUuKjoqKQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQK
KwlTVU5fQVJDSD0iaTM4NiIKKwkjIElmIHRoZXJlIGlzIGEgY29tcGlsZXIsIHNlZSBpZiBpdCBp
cyBjb25maWd1cmVkIGZvciA2NC1iaXQgb2JqZWN0cy4KKwkjIE5vdGUgdGhhdCB0aGUgU3VuIGNj
IGRvZXMgbm90IHR1cm4gX19MUDY0X18gaW50byAxIGxpa2UgZ2NjIGRvZXMuCisJIyBUaGlzIHRl
c3Qgd29ya3MgZm9yIGJvdGggY29tcGlsZXJzLgorCWlmIFsgIiRDQ19GT1JfQlVJTEQiICE9ICdu
b19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCSAgICBpZiAoZWNobyAnI2lmZGVmIF9fYW1kNjQn
OyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicpIHwgXAorCQkoQ0NPUFRTPSAkQ0Nf
Rk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwgXAorCQlncmVwIElTXzY0QklUX0FSQ0ggPi9k
ZXYvbnVsbAorCSAgICB0aGVuCisJCVNVTl9BUkNIPSJ4ODZfNjQiCisJICAgIGZpCisJZmkKKwll
Y2hvICR7U1VOX0FSQ0h9LXBjLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjYqOiopCisJIyBBY2NvcmRp
bmcgdG8gY29uZmlnLnN1YiwgdGhpcyBpcyB0aGUgcHJvcGVyIHdheSB0byBjYW5vbmljYWxpemUK
KwkjIFN1bk9TNi4gIEhhcmQgdG8gZ3Vlc3MgZXhhY3RseSB3aGF0IFN1bk9TNiB3aWxsIGJlIGxp
a2UsIGJ1dAorCSMgaXQncyBsaWtlbHkgdG8gYmUgbW9yZSBsaWtlIFNvbGFyaXMgdGhhbiBTdW5P
UzQuCisJZWNobyBzcGFyYy1zdW4tc29sYXJpczNgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgc3VuNCo6U3VuT1M6KjoqKQorCWNhc2UgImAv
dXNyL2Jpbi9hcmNoIC1rYCIgaW4KKwkgICAgU2VyaWVzKnxTNCopCisJCVVOQU1FX1JFTEVBU0U9
YHVuYW1lIC12YAorCQk7OworCWVzYWMKKwkjIEphcGFuZXNlIExhbmd1YWdlIHZlcnNpb25zIGhh
dmUgYSB2ZXJzaW9uIG51bWJlciBsaWtlIGA0LjEuMy1KTCcuCisJZWNobyBzcGFyYy1zdW4tc3Vu
b3NgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vJ2AKKwlleGl0IDs7CisgICAg
c3VuMyo6U3VuT1M6KjoqKQorCWVjaG8gbTY4ay1zdW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgIHN1bio6Kjo0LjJCU0Q6KikKKwlVTkFNRV9SRUxFQVNFPWAoc2VkIDFxIC9l
dGMvbW90ZCB8IGF3ayAne3ByaW50IHN1YnN0cigkNSwxLDMpfScpIDI+L2Rldi9udWxsYAorCXRl
c3QgIngke1VOQU1FX1JFTEVBU0V9IiA9ICJ4IiAmJiBVTkFNRV9SRUxFQVNFPTMKKwljYXNlICJg
L2Jpbi9hcmNoYCIgaW4KKwkgICAgc3VuMykKKwkJZWNobyBtNjhrLXN1bi1zdW5vcyR7VU5BTUVf
UkVMRUFTRX0KKwkJOzsKKwkgICAgc3VuNCkKKwkJZWNobyBzcGFyYy1zdW4tc3Vub3Mke1VOQU1F
X1JFTEVBU0V9CisJCTs7CisJZXNhYworCWV4aXQgOzsKKyAgICBhdXNocDpTdW5PUzoqOiopCisJ
ZWNobyBzcGFyYy1hdXNwZXgtc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICMg
VGhlIHNpdHVhdGlvbiBmb3IgTWlOVCBpcyBhIGxpdHRsZSBjb25mdXNpbmcuICBUaGUgbWFjaGlu
ZSBuYW1lCisgICAgIyBjYW4gYmUgdmlydHVhbGx5IGV2ZXJ5dGhpbmcgKGV2ZXJ5dGhpbmcgd2hp
Y2ggaXMgbm90CisgICAgIyAiYXRhcmlzdCIgb3IgImF0YXJpc3RlIiBhdCBsZWFzdCBzaG91bGQg
aGF2ZSBhIHByb2Nlc3NvcgorICAgICMgPiBtNjgwMDApLiAgVGhlIHN5c3RlbSBuYW1lIHJhbmdl
cyBmcm9tICJNaU5UIiBvdmVyICJGcmVlTWlOVCIKKyAgICAjIHRvIHRoZSBsb3dlcmNhc2UgdmVy
c2lvbiAibWludCIgKG9yICJmcmVlbWludCIpLiAgRmluYWxseQorICAgICMgdGhlIHN5c3RlbSBu
YW1lICJUT1MiIGRlbm90ZXMgYSBzeXN0ZW0gd2hpY2ggaXMgYWN0dWFsbHkgbm90CisgICAgIyBN
aU5ULiAgQnV0IE1pTlQgaXMgZG93bndhcmQgY29tcGF0aWJsZSB0byBUT1MsIHNvIHRoaXMgc2hv
dWxkCisgICAgIyBiZSBubyBwcm9ibGVtLgorICAgIGF0YXJpc3RbZV06Kk1pTlQ6KjoqIHwgYXRh
cmlzdFtlXToqbWludDoqOiogfCBhdGFyaXN0W2VdOipUT1M6KjoqKQorICAgICAgICBlY2hvIG02
OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgYXRhcmkqOipNaU5U
Oio6KiB8IGF0YXJpKjoqbWludDoqOiogfCBhdGFyaXN0W2VdOipUT1M6KjoqKQorCWVjaG8gbTY4
ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorICAgICAgICBleGl0IDs7CisgICAgKmZhbGNv
bio6Kk1pTlQ6KjoqIHwgKmZhbGNvbio6Km1pbnQ6KjoqIHwgKmZhbGNvbio6KlRPUzoqOiopCisg
ICAgICAgIGVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAg
ICBtaWxhbio6Kk1pTlQ6KjoqIHwgbWlsYW4qOiptaW50Oio6KiB8ICptaWxhbio6KlRPUzoqOiop
CisgICAgICAgIGVjaG8gbTY4ay1taWxhbi1taW50JHtVTkFNRV9SRUxFQVNFfQorICAgICAgICBl
eGl0IDs7CisgICAgaGFkZXMqOipNaU5UOio6KiB8IGhhZGVzKjoqbWludDoqOiogfCAqaGFkZXMq
OipUT1M6KjoqKQorICAgICAgICBlY2hvIG02OGstaGFkZXMtbWludCR7VU5BTUVfUkVMRUFTRX0K
KyAgICAgICAgZXhpdCA7OworICAgICo6Kk1pTlQ6KjoqIHwgKjoqbWludDoqOiogfCAqOipUT1M6
KjoqKQorICAgICAgICBlY2hvIG02OGstdW5rbm93bi1taW50JHtVTkFNRV9SRUxFQVNFfQorICAg
ICAgICBleGl0IDs7CisgICAgbTY4azptYWNodGVuOio6KikKKwllY2hvIG02OGstYXBwbGUtbWFj
aHRlbiR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgcG93ZXJwYzptYWNodGVuOio6KikK
KwllY2hvIHBvd2VycGMtYXBwbGUtbWFjaHRlbiR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7Cisg
ICAgUklTQyo6TWFjaDoqOiopCisJZWNobyBtaXBzLWRlYy1tYWNoX2JzZDQuMworCWV4aXQgOzsK
KyAgICBSSVNDKjpVTFRSSVg6KjoqKQorCWVjaG8gbWlwcy1kZWMtdWx0cml4JHtVTkFNRV9SRUxF
QVNFfQorCWV4aXQgOzsKKyAgICBWQVgqOlVMVFJJWCo6KjoqKQorCWVjaG8gdmF4LWRlYy11bHRy
aXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIDIwMjA6Q0xJWDoqOiogfCAyNDMwOkNM
SVg6KjoqKQorCWVjaG8gY2xpcHBlci1pbnRlcmdyYXBoLWNsaXgke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgIG1pcHM6KjoqOlVNSVBTIHwgbWlwczoqOio6UklTQ29zKQorCWV2YWwgJHNl
dF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworI2lmZGVmIF9f
Y3BsdXNwbHVzCisjaW5jbHVkZSA8c3RkaW8uaD4gIC8qIGZvciBwcmludGYoKSBwcm90b3R5cGUg
Ki8KKwlpbnQgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkgeworI2Vsc2UKKwlpbnQgbWFp
biAoYXJnYywgYXJndikgaW50IGFyZ2M7IGNoYXIgKmFyZ3ZbXTsgeworI2VuZGlmCisJI2lmIGRl
ZmluZWQgKGhvc3RfbWlwcykgJiYgZGVmaW5lZCAoTUlQU0VCKQorCSNpZiBkZWZpbmVkIChTWVNU
WVBFX1NZU1YpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzeXN2XG4iLCBhcmd2WzFd
KTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfU1ZSNCkKKwkgIHBy
aW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc3N2cjRcbiIsIGFyZ3ZbMV0pOyBleGl0ICgwKTsKKwkj
ZW5kaWYKKwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9CU0Q0MykgfHwgZGVmaW5lZChTWVNUWVBFX0JT
RCkKKwkgIHByaW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc2JzZFxuIiwgYXJndlsxXSk7IGV4aXQg
KDApOworCSNlbmRpZgorCSNlbmRpZgorCSAgZXhpdCAoLTEpOworCX0KK0VPRgorCSRDQ19GT1Jf
QlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmCisJICBkdW1teWFyZz1gZWNobyAiJHtVTkFNRV9S
RUxFQVNFfSIgfCBzZWQgLW4gJ3MvXChbMC05XSpcKS4qL1wxL3AnYCAmJgorCSAgU1lTVEVNX05B
TUU9YCRkdW1teSAkZHVtbXlhcmdgICYmCisJICAgIHsgZWNobyAiJFNZU1RFTV9OQU1FIjsgZXhp
dDsgfQorCWVjaG8gbWlwcy1taXBzLXJpc2NvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7Cisg
ICAgTW90b3JvbGE6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93ZXJwYy1tb3Rvcm9sYS1wb3dl
cm1heAorCWV4aXQgOzsKKyAgICBNb3Rvcm9sYToqOjQuMzpQTDgtKikKKwllY2hvIHBvd2VycGMt
aGFycmlzLXBvd2VybWF4CisJZXhpdCA7OworICAgIE5pZ2h0X0hhd2s6KjoqOlBvd2VyTUFYX09T
IHwgU3luZXJneTpQb3dlck1BWF9PUzoqOiopCisJZWNobyBwb3dlcnBjLWhhcnJpcy1wb3dlcm1h
eAorCWV4aXQgOzsKKyAgICBOaWdodF9IYXdrOlBvd2VyX1VOSVg6KjoqKQorCWVjaG8gcG93ZXJw
Yy1oYXJyaXMtcG93ZXJ1bml4CisJZXhpdCA7OworICAgIG04OGs6Q1gvVVg6Nyo6KikKKwllY2hv
IG04OGstaGFycmlzLWN4dXg3CisJZXhpdCA7OworICAgIG04OGs6Kjo0KjpSNCopCisJZWNobyBt
ODhrLW1vdG9yb2xhLXN5c3Y0CisJZXhpdCA7OworICAgIG04OGs6KjozKjpSMyopCisJZWNobyBt
ODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIEFWaWlPTjpkZ3V4Oio6KikKKyAgICAg
ICAgIyBERy9VWCByZXR1cm5zIEFWaWlPTiBmb3IgYWxsIGFyY2hpdGVjdHVyZXMKKyAgICAgICAg
VU5BTUVfUFJPQ0VTU09SPWAvdXNyL2Jpbi91bmFtZSAtcGAKKwlpZiBbICRVTkFNRV9QUk9DRVNT
T1IgPSBtYzg4MTAwIF0gfHwgWyAkVU5BTUVfUFJPQ0VTU09SID0gbWM4ODExMCBdCisJdGhlbgor
CSAgICBpZiBbICR7VEFSR0VUX0JJTkFSWV9JTlRFUkZBQ0V9eCA9IG04OGtkZ3V4ZWxmeCBdIHx8
IFwKKwkgICAgICAgWyAke1RBUkdFVF9CSU5BUllfSU5URVJGQUNFfXggPSB4IF0KKwkgICAgdGhl
bgorCQllY2hvIG04OGstZGctZGd1eCR7VU5BTUVfUkVMRUFTRX0KKwkgICAgZWxzZQorCQllY2hv
IG04OGstZGctZGd1eGJjcyR7VU5BTUVfUkVMRUFTRX0KKwkgICAgZmkKKwllbHNlCisJICAgIGVj
aG8gaTU4Ni1kZy1kZ3V4JHtVTkFNRV9SRUxFQVNFfQorCWZpCisgCWV4aXQgOzsKKyAgICBNODgq
OkRvbHBoaW5PUzoqOiopCSMgRG9scGhpbk9TIChTVlIzKQorCWVjaG8gbTg4ay1kb2xwaGluLXN5
c3YzCisJZXhpdCA7OworICAgIE04OCo6KjpSMyo6KikKKwkjIERlbHRhIDg4ayBzeXN0ZW0gcnVu
bmluZyBTVlIzCisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIFhEODgq
Oio6KjoqKSAjIFRla3Ryb25peCBYRDg4IHN5c3RlbSBydW5uaW5nIFVUZWtWIChTVlIzKQorCWVj
aG8gbTg4ay10ZWt0cm9uaXgtc3lzdjMKKwlleGl0IDs7CisgICAgVGVrNDNbMC05XVswLTldOlVU
ZWs6KjoqKSAjIFRla3Ryb25peCA0MzAwIHN5c3RlbSBydW5uaW5nIFVUZWsgKEJTRCkKKwllY2hv
IG02OGstdGVrdHJvbml4LWJzZAorCWV4aXQgOzsKKyAgICAqOklSSVgqOio6KikKKwllY2hvIG1p
cHMtc2dpLWlyaXhgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vZydgCisJZXhp
dCA7OworICAgID8/Pz8/Pz8/OkFJWD86WzEyXS4xOjIpICAgIyBBSVggMi4yLjEgb3IgQUlYIDIu
MS4xIGlzIFJUL1BDIEFJWC4KKwllY2hvIHJvbXAtaWJtLWFpeCAgICAgIyB1bmFtZSAtbSBnaXZl
cyBhbiA4IGhleC1jb2RlIENQVSBpZAorCWV4aXQgOzsgICAgICAgICAgICAgICAjIE5vdGUgdGhh
dDogZWNobyAiJ2B1bmFtZSAtc2AnIiBnaXZlcyAnQUlYICcKKyAgICBpKjg2OkFJWDoqOiopCisJ
ZWNobyBpMzg2LWlibS1haXgKKwlleGl0IDs7CisgICAgaWE2NDpBSVg6KjoqKQorCWlmIFsgLXgg
L3Vzci9iaW4vb3NsZXZlbCBdIDsgdGhlbgorCQlJQk1fUkVWPWAvdXNyL2Jpbi9vc2xldmVsYAor
CWVsc2UKKwkJSUJNX1JFVj0ke1VOQU1FX1ZFUlNJT059LiR7VU5BTUVfUkVMRUFTRX0KKwlmaQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1pYm0tYWl4JHtJQk1fUkVWfQorCWV4aXQgOzsKKyAgICAq
OkFJWDoyOjMpCisJaWYgZ3JlcCBib3MzMjUgL3Vzci9pbmNsdWRlL3N0ZGlvLmggPi9kZXYvbnVs
bCAyPiYxOyB0aGVuCisJCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJc2VkICdzL14JCS8vJyA8
PCBFT0YgPiRkdW1teS5jCisJCSNpbmNsdWRlIDxzeXMvc3lzdGVtY2ZnLmg+CisKKwkJbWFpbigp
CisJCQl7CisJCQlpZiAoIV9fcG93ZXJfcGMoKSkKKwkJCQlleGl0KDEpOworCQkJcHV0cygicG93
ZXJwYy1pYm0tYWl4My4yLjUiKTsKKwkJCWV4aXQoMCk7CisJCQl9CitFT0YKKwkJaWYgJENDX0ZP
Ul9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRkdW1teWAKKwkJdGhl
bgorCQkJZWNobyAiJFNZU1RFTV9OQU1FIgorCQllbHNlCisJCQllY2hvIHJzNjAwMC1pYm0tYWl4
My4yLjUKKwkJZmkKKwllbGlmIGdyZXAgYm9zMzI0IC91c3IvaW5jbHVkZS9zdGRpby5oID4vZGV2
L251bGwgMj4mMTsgdGhlbgorCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yLjQKKwllbHNlCisJCWVj
aG8gcnM2MDAwLWlibS1haXgzLjIKKwlmaQorCWV4aXQgOzsKKyAgICAqOkFJWDoqOls0NTZdKQor
CUlCTV9DUFVfSUQ9YC91c3Ivc2Jpbi9sc2RldiAtQyAtYyBwcm9jZXNzb3IgLVMgYXZhaWxhYmxl
IHwgc2VkIDFxIHwgYXdrICd7IHByaW50ICQxIH0nYAorCWlmIC91c3Ivc2Jpbi9sc2F0dHIgLUVs
ICR7SUJNX0NQVV9JRH0gfCBncmVwICcgUE9XRVInID4vZGV2L251bGwgMj4mMTsgdGhlbgorCQlJ
Qk1fQVJDSD1yczYwMDAKKwllbHNlCisJCUlCTV9BUkNIPXBvd2VycGMKKwlmaQorCWlmIFsgLXgg
L3Vzci9iaW4vb3NsZXZlbCBdIDsgdGhlbgorCQlJQk1fUkVWPWAvdXNyL2Jpbi9vc2xldmVsYAor
CWVsc2UKKwkJSUJNX1JFVj0ke1VOQU1FX1ZFUlNJT059LiR7VU5BTUVfUkVMRUFTRX0KKwlmaQor
CWVjaG8gJHtJQk1fQVJDSH0taWJtLWFpeCR7SUJNX1JFVn0KKwlleGl0IDs7CisgICAgKjpBSVg6
KjoqKQorCWVjaG8gcnM2MDAwLWlibS1haXgKKwlleGl0IDs7CisgICAgaWJtcnQ6NC40QlNEOip8
cm9tcC1pYm06QlNEOiopCisJZWNobyByb21wLWlibS1ic2Q0LjQKKwlleGl0IDs7CisgICAgaWJt
cnQ6KkJTRDoqfHJvbXAtaWJtOkJTRDoqKSAgICAgICAgICAgICMgY292ZXJzIFJUL1BDIEJTRCBh
bmQKKwllY2hvIHJvbXAtaWJtLWJzZCR7VU5BTUVfUkVMRUFTRX0gICAjIDQuMyB3aXRoIHVuYW1l
IGFkZGVkIHRvCisJZXhpdCA7OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyByZXBvcnQ6
IHJvbXAtaWJtIEJTRCA0LjMKKyAgICAqOkJPU1g6KjoqKQorCWVjaG8gcnM2MDAwLWJ1bGwtYm9z
eAorCWV4aXQgOzsKKyAgICBEUFgvMj8wMDpCLk8uUy46KjoqKQorCWVjaG8gbTY4ay1idWxsLXN5
c3YzCisJZXhpdCA7OworICAgIDkwMDAvWzM0XT8/OjQuM2JzZDoxLio6KikKKwllY2hvIG02OGst
aHAtYnNkCisJZXhpdCA7OworICAgIGhwMzAwOjQuNEJTRDoqOiogfCA5MDAwL1szNF0/Pzo0LjNi
c2Q6Mi4qOiopCisJZWNobyBtNjhrLWhwLWJzZDQuNAorCWV4aXQgOzsKKyAgICA5MDAwL1szNDY3
OF0/PzpIUC1VWDoqOiopCisJSFBVWF9SRVY9YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvW14uXSouWzBCXSovLydgCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FfSIgaW4KKwkgICAgOTAw
MC8zMT8gKSAgICAgICAgICAgIEhQX0FSQ0g9bTY4MDAwIDs7CisJICAgIDkwMDAvWzM0XT8/ICkg
ICAgICAgICBIUF9BUkNIPW02OGsgOzsKKwkgICAgOTAwMC9bNjc4XVswLTldWzAtOV0pCisJCWlm
IFsgLXggL3Vzci9iaW4vZ2V0Y29uZiBdOyB0aGVuCisJCSAgICBzY19jcHVfdmVyc2lvbj1gL3Vz
ci9iaW4vZ2V0Y29uZiBTQ19DUFVfVkVSU0lPTiAyPi9kZXYvbnVsbGAKKyAgICAgICAgICAgICAg
ICAgICAgc2Nfa2VybmVsX2JpdHM9YC91c3IvYmluL2dldGNvbmYgU0NfS0VSTkVMX0JJVFMgMj4v
ZGV2L251bGxgCisgICAgICAgICAgICAgICAgICAgIGNhc2UgIiR7c2NfY3B1X3ZlcnNpb259IiBp
bgorICAgICAgICAgICAgICAgICAgICAgIDUyMykgSFBfQVJDSD0iaHBwYTEuMCIgOzsgIyBDUFVf
UEFfUklTQzFfMAorICAgICAgICAgICAgICAgICAgICAgIDUyOCkgSFBfQVJDSD0iaHBwYTEuMSIg
OzsgIyBDUFVfUEFfUklTQzFfMQorICAgICAgICAgICAgICAgICAgICAgIDUzMikgICAgICAgICAg
ICAgICAgICAgICAgIyBDUFVfUEFfUklTQzJfMAorICAgICAgICAgICAgICAgICAgICAgICAgY2Fz
ZSAiJHtzY19rZXJuZWxfYml0c30iIGluCisgICAgICAgICAgICAgICAgICAgICAgICAgIDMyKSBI
UF9BUkNIPSJocHBhMi4wbiIgOzsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgNjQpIEhQX0FS
Q0g9ImhwcGEyLjB3IiA7OworCQkJICAnJykgSFBfQVJDSD0iaHBwYTIuMCIgOzsgICAjIEhQLVVY
IDEwLjIwCisgICAgICAgICAgICAgICAgICAgICAgICBlc2FjIDs7CisgICAgICAgICAgICAgICAg
ICAgIGVzYWMKKwkJZmkKKwkJaWYgWyAiJHtIUF9BUkNIfSIgPSAiIiBdOyB0aGVuCisJCSAgICBl
dmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCSAgICBzZWQgJ3MvXiAgICAgICAgICAgICAgLy8nIDw8
IEVPRiA+JGR1bW15LmMKKworICAgICAgICAgICAgICAjZGVmaW5lIF9IUFVYX1NPVVJDRQorICAg
ICAgICAgICAgICAjaW5jbHVkZSA8c3RkbGliLmg+CisgICAgICAgICAgICAgICNpbmNsdWRlIDx1
bmlzdGQuaD4KKworICAgICAgICAgICAgICBpbnQgbWFpbiAoKQorICAgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgICNpZiBkZWZpbmVkKF9TQ19LRVJORUxfQklUUykKKyAgICAgICAgICAgICAg
ICAgIGxvbmcgYml0cyA9IHN5c2NvbmYoX1NDX0tFUk5FTF9CSVRTKTsKKyAgICAgICAgICAgICAg
I2VuZGlmCisgICAgICAgICAgICAgICAgICBsb25nIGNwdSAgPSBzeXNjb25mIChfU0NfQ1BVX1ZF
UlNJT04pOworCisgICAgICAgICAgICAgICAgICBzd2l0Y2ggKGNwdSkKKyAgICAgICAgICAgICAg
CXsKKyAgICAgICAgICAgICAgCWNhc2UgQ1BVX1BBX1JJU0MxXzA6IHB1dHMgKCJocHBhMS4wIik7
IGJyZWFrOworICAgICAgICAgICAgICAJY2FzZSBDUFVfUEFfUklTQzFfMTogcHV0cyAoImhwcGEx
LjEiKTsgYnJlYWs7CisgICAgICAgICAgICAgIAljYXNlIENQVV9QQV9SSVNDMl8wOgorICAgICAg
ICAgICAgICAjaWYgZGVmaW5lZChfU0NfS0VSTkVMX0JJVFMpCisgICAgICAgICAgICAgIAkgICAg
c3dpdGNoIChiaXRzKQorICAgICAgICAgICAgICAJCXsKKyAgICAgICAgICAgICAgCQljYXNlIDY0
OiBwdXRzICgiaHBwYTIuMHciKTsgYnJlYWs7CisgICAgICAgICAgICAgIAkJY2FzZSAzMjogcHV0
cyAoImhwcGEyLjBuIik7IGJyZWFrOworICAgICAgICAgICAgICAJCWRlZmF1bHQ6IHB1dHMgKCJo
cHBhMi4wIik7IGJyZWFrOworICAgICAgICAgICAgICAJCX0gYnJlYWs7CisgICAgICAgICAgICAg
ICNlbHNlICAvKiAhZGVmaW5lZChfU0NfS0VSTkVMX0JJVFMpICovCisgICAgICAgICAgICAgIAkg
ICAgcHV0cyAoImhwcGEyLjAiKTsgYnJlYWs7CisgICAgICAgICAgICAgICNlbmRpZgorICAgICAg
ICAgICAgICAJZGVmYXVsdDogcHV0cyAoImhwcGExLjAiKTsgYnJlYWs7CisgICAgICAgICAgICAg
IAl9CisgICAgICAgICAgICAgICAgICBleGl0ICgwKTsKKyAgICAgICAgICAgICAgfQorRU9GCisJ
CSAgICAoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAyPi9kZXYvbnVs
bCkgJiYgSFBfQVJDSD1gJGR1bW15YAorCQkgICAgdGVzdCAteiAiJEhQX0FSQ0giICYmIEhQX0FS
Q0g9aHBwYQorCQlmaSA7OworCWVzYWMKKwlpZiBbICR7SFBfQVJDSH0gPSAiaHBwYTIuMHciIF0K
Kwl0aGVuCisJICAgIGV2YWwgJHNldF9jY19mb3JfYnVpbGQKKworCSAgICAjIGhwcGEyLjB3LWhw
LWhwdXgqIGhhcyBhIDY0LWJpdCBrZXJuZWwgYW5kIGEgY29tcGlsZXIgZ2VuZXJhdGluZworCSAg
ICAjIDMyLWJpdCBjb2RlLiAgaHBwYTY0LWhwLWhwdXgqIGhhcyB0aGUgc2FtZSBrZXJuZWwgYW5k
IGEgY29tcGlsZXIKKwkgICAgIyBnZW5lcmF0aW5nIDY0LWJpdCBjb2RlLiAgR05VIGFuZCBIUCB1
c2UgZGlmZmVyZW50IG5vbWVuY2xhdHVyZToKKwkgICAgIworCSAgICAjICQgQ0NfRk9SX0JVSUxE
PWNjIC4vY29uZmlnLmd1ZXNzCisJICAgICMgPT4gaHBwYTIuMHctaHAtaHB1eDExLjIzCisJICAg
ICMgJCBDQ19GT1JfQlVJTEQ9ImNjICtEQTIuMHciIC4vY29uZmlnLmd1ZXNzCisJICAgICMgPT4g
aHBwYTY0LWhwLWhwdXgxMS4yMworCisJICAgIGlmIGVjaG8gX19MUDY0X18gfCAoQ0NPUFRTPSAk
Q0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwKKwkJZ3JlcCAtcSBfX0xQNjRfXworCSAg
ICB0aGVuCisJCUhQX0FSQ0g9ImhwcGEyLjB3IgorCSAgICBlbHNlCisJCUhQX0FSQ0g9ImhwcGE2
NCIKKwkgICAgZmkKKwlmaQorCWVjaG8gJHtIUF9BUkNIfS1ocC1ocHV4JHtIUFVYX1JFVn0KKwll
eGl0IDs7CisgICAgaWE2NDpIUC1VWDoqOiopCisJSFBVWF9SRVY9YGVjaG8gJHtVTkFNRV9SRUxF
QVNFfXxzZWQgLWUgJ3MvW14uXSouWzBCXSovLydgCisJZWNobyBpYTY0LWhwLWhwdXgke0hQVVhf
UkVWfQorCWV4aXQgOzsKKyAgICAzMDUwKjpISS1VWDoqOiopCisJZXZhbCAkc2V0X2NjX2Zvcl9i
dWlsZAorCXNlZCAncy9eCS8vJyA8PCBFT0YgPiRkdW1teS5jCisJI2luY2x1ZGUgPHVuaXN0ZC5o
PgorCWludAorCW1haW4gKCkKKwl7CisJICBsb25nIGNwdSA9IHN5c2NvbmYgKF9TQ19DUFVfVkVS
U0lPTik7CisJICAvKiBUaGUgb3JkZXIgbWF0dGVycywgYmVjYXVzZSBDUFVfSVNfSFBfTUM2OEsg
ZXJyb25lb3VzbHkgcmV0dXJucworCSAgICAgdHJ1ZSBmb3IgQ1BVX1BBX1JJU0MxXzAuICBDUFVf
SVNfUEFfUklTQyByZXR1cm5zIGNvcnJlY3QKKwkgICAgIHJlc3VsdHMsIGhvd2V2ZXIuICAqLwor
CSAgaWYgKENQVV9JU19QQV9SSVNDIChjcHUpKQorCSAgICB7CisJICAgICAgc3dpdGNoIChjcHUp
CisJCXsKKwkJICBjYXNlIENQVV9QQV9SSVNDMV8wOiBwdXRzICgiaHBwYTEuMC1oaXRhY2hpLWhp
dXh3ZTIiKTsgYnJlYWs7CisJCSAgY2FzZSBDUFVfUEFfUklTQzFfMTogcHV0cyAoImhwcGExLjEt
aGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQkgIGNhc2UgQ1BVX1BBX1JJU0MyXzA6IHB1dHMg
KCJocHBhMi4wLWhpdGFjaGktaGl1eHdlMiIpOyBicmVhazsKKwkJICBkZWZhdWx0OiBwdXRzICgi
aHBwYS1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJCX0KKwkgICAgfQorCSAgZWxzZSBpZiAo
Q1BVX0lTX0hQX01DNjhLIChjcHUpKQorCSAgICBwdXRzICgibTY4ay1oaXRhY2hpLWhpdXh3ZTIi
KTsKKwkgIGVsc2UgcHV0cyAoInVua25vd24taGl0YWNoaS1oaXV4d2UyIik7CisJICBleGl0ICgw
KTsKKwl9CitFT0YKKwkkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAmJiBTWVNURU1f
TkFNRT1gJGR1bW15YCAmJgorCQl7IGVjaG8gIiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKwllY2hv
IHVua25vd24taGl0YWNoaS1oaXV4d2UyCisJZXhpdCA7OworICAgIDkwMDAvNz8/OjQuM2JzZDoq
OiogfCA5MDAwLzg/Wzc5XTo0LjNic2Q6KjoqICkKKwllY2hvIGhwcGExLjEtaHAtYnNkCisJZXhp
dCA7OworICAgIDkwMDAvOD8/OjQuM2JzZDoqOiopCisJZWNobyBocHBhMS4wLWhwLWJzZAorCWV4
aXQgOzsKKyAgICAqOT8/KjpNUEUvaVg6KjoqIHwgKjMwMDAqOk1QRS9pWDoqOiopCisJZWNobyBo
cHBhMS4wLWhwLW1wZWl4CisJZXhpdCA7OworICAgIGhwNz8/Ok9TRjE6KjoqIHwgaHA4P1s3OV06
T1NGMToqOiogKQorCWVjaG8gaHBwYTEuMS1ocC1vc2YKKwlleGl0IDs7CisgICAgaHA4Pz86T1NG
MToqOiopCisJZWNobyBocHBhMS4wLWhwLW9zZgorCWV4aXQgOzsKKyAgICBpKjg2Ok9TRjE6Kjoq
KQorCWlmIFsgLXggL3Vzci9zYmluL3N5c3ZlcnNpb24gXSA7IHRoZW4KKwkgICAgZWNobyAke1VO
QU1FX01BQ0hJTkV9LXVua25vd24tb3NmMW1rCisJZWxzZQorCSAgICBlY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1vc2YxCisJZmkKKwlleGl0IDs7CisgICAgcGFyaXNjKjpMaXRlcyo6Kjoq
KQorCWVjaG8gaHBwYTEuMS1ocC1saXRlcworCWV4aXQgOzsKKyAgICBDMSo6Q29udmV4T1M6Kjoq
IHwgY29udmV4OkNvbnZleE9TOkMxKjoqKQorCWVjaG8gYzEtY29udmV4LWJzZAorICAgICAgICBl
eGl0IDs7CisgICAgQzIqOkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMio6KikKKwlp
ZiBnZXRzeXNpbmZvIC1mIHNjYWxhcl9hY2MKKwl0aGVuIGVjaG8gYzMyLWNvbnZleC1ic2QKKwll
bHNlIGVjaG8gYzItY29udmV4LWJzZAorCWZpCisgICAgICAgIGV4aXQgOzsKKyAgICBDMzQqOkNv
bnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMzQqOiopCisJZWNobyBjMzQtY29udmV4LWJz
ZAorICAgICAgICBleGl0IDs7CisgICAgQzM4KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4
T1M6QzM4KjoqKQorCWVjaG8gYzM4LWNvbnZleC1ic2QKKyAgICAgICAgZXhpdCA7OworICAgIEM0
KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzQqOiopCisJZWNobyBjNC1jb252ZXgt
YnNkCisgICAgICAgIGV4aXQgOzsKKyAgICBDUkFZKlktTVA6KjoqOiopCisJZWNobyB5bXAtY3Jh
eS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwlleGl0
IDs7CisgICAgQ1JBWSpbQS1aXTkwOio6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1jcmF5
LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gXAorCXwgc2VkIC1lICdzL0NSQVkuKlwoW0EtWl05MFwp
L1wxLycgXAorCSAgICAgIC1lIHkvQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVovYWJjZGVmZ2hp
amtsbW5vcHFyc3R1dnd4eXovIFwKKwkgICAgICAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7
OworICAgIENSQVkqVFM6KjoqOiopCisJZWNobyB0OTAtY3JheS11bmljb3Mke1VOQU1FX1JFTEVB
U0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpUM0U6Kjoq
OiopCisJZWNobyBhbHBoYWV2NS1jcmF5LXVuaWNvc21rJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAt
ZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIENSQVkqU1YxOio6KjoqKQorCWVjaG8g
c3YxLWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8n
CisJZXhpdCA7OworICAgICo6VU5JQ09TL21wOio6KikKKwllY2hvIGNyYXludi1jcmF5LXVuaWNv
c21wJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7Owor
ICAgIEYzMFswMV06VU5JWF9TeXN0ZW1fVjoqOiogfCBGNzAwOlVOSVhfU3lzdGVtX1Y6KjoqKQor
CUZVSklUU1VfUFJPQz1gdW5hbWUgLW0gfCB0ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVon
ICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eidgCisgICAgICAgIEZVSklUU1VfU1lTPWB1bmFt
ZSAtcCB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3Bx
cnN0dXZ3eHl6JyB8IHNlZCAtZSAncy9cLy8vJ2AKKyAgICAgICAgRlVKSVRTVV9SRUw9YGVjaG8g
JHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy8gL18vJ2AKKyAgICAgICAgZWNobyAiJHtGVUpJ
VFNVX1BST0N9LWZ1aml0c3UtJHtGVUpJVFNVX1NZU30ke0ZVSklUU1VfUkVMfSIKKyAgICAgICAg
ZXhpdCA7OworICAgIDUwMDA6VU5JWF9TeXN0ZW1fVjo0Lio6KikKKyAgICAgICAgRlVKSVRTVV9T
WVM9YHVuYW1lIC1wIHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hp
amtsbW5vcHFyc3R1dnd4eXonIHwgc2VkIC1lICdzL1wvLy8nYAorICAgICAgICBGVUpJVFNVX1JF
TD1gZWNobyAke1VOQU1FX1JFTEVBU0V9IHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFla
JyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHwgc2VkIC1lICdzLyAvXy8nYAorICAgICAg
ICBlY2hvICJzcGFyYy1mdWppdHN1LSR7RlVKSVRTVV9TWVN9JHtGVUpJVFNVX1JFTH0iCisJZXhp
dCA7OworICAgIGkqODY6QlNELzM4NjoqOiogfCBpKjg2OkJTRC9PUzoqOiogfCAqOkFzY2VuZFwg
RW1iZWRkZWQvT1M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1ic2RpJHtVTkFNRV9S
RUxFQVNFfQorCWV4aXQgOzsKKyAgICBzcGFyYyo6QlNEL09TOio6KikKKwllY2hvIHNwYXJjLXVu
a25vd24tYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpCU0QvT1M6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhp
dCA7OworICAgICo6RnJlZUJTRDoqOiopCisJY2FzZSAke1VOQU1FX01BQ0hJTkV9IGluCisJICAg
IHBjOTgpCisJCWVjaG8gaTM4Ni11bmtub3duLWZyZWVic2RgZWNobyAke1VOQU1FX1JFTEVBU0V9
fHNlZCAtZSAncy9bLShdLiovLydgIDs7CisJICAgIGFtZDY0KQorCQllY2hvIHg4Nl82NC11bmtu
b3duLWZyZWVic2RgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgIDs7
CisJICAgICopCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWZyZWVic2RgZWNobyAk
e1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgIDs7CisJZXNhYworCWV4aXQgOzsK
KyAgICBpKjpDWUdXSU4qOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLWN5Z3dpbgorCWV4
aXQgOzsKKyAgICAqOk1JTkdXKjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1taW5ndzMy
CisJZXhpdCA7OworICAgIGkqOndpbmRvd3MzMio6KikKKyAgICAJIyB1bmFtZSAtbSBpbmNsdWRl
cyAiLXBjIiBvbiB0aGlzIHN5c3RlbS4KKyAgICAJZWNobyAke1VOQU1FX01BQ0hJTkV9LW1pbmd3
MzIKKwlleGl0IDs7CisgICAgaSo6UFcqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXB3
MzIKKwlleGl0IDs7CisgICAgKjpJbnRlcml4KjoqKQorICAgIAljYXNlICR7VU5BTUVfTUFDSElO
RX0gaW4KKwkgICAgeDg2KQorCQllY2hvIGk1ODYtcGMtaW50ZXJpeCR7VU5BTUVfUkVMRUFTRX0K
KwkJZXhpdCA7OworCSAgICBhdXRoZW50aWNhbWQgfCBnZW51aW5laW50ZWwgfCBFTTY0VCkKKwkJ
ZWNobyB4ODZfNjQtdW5rbm93bi1pbnRlcml4JHtVTkFNRV9SRUxFQVNFfQorCQlleGl0IDs7CisJ
ICAgIElBNjQpCisJCWVjaG8gaWE2NC11bmtub3duLWludGVyaXgke1VOQU1FX1JFTEVBU0V9CisJ
CWV4aXQgOzsKKwllc2FjIDs7CisgICAgWzM0NV04NjpXaW5kb3dzXzk1OiogfCBbMzQ1XTg2Oldp
bmRvd3NfOTg6KiB8IFszNDVdODY6V2luZG93c19OVDoqKQorCWVjaG8gaSR7VU5BTUVfTUFDSElO
RX0tcGMtbWtzCisJZXhpdCA7OworICAgIDg2NjQ6V2luZG93c19OVDoqKQorCWVjaG8geDg2XzY0
LXBjLW1rcworCWV4aXQgOzsKKyAgICBpKjpXaW5kb3dzX05UKjoqIHwgUGVudGl1bSo6V2luZG93
c19OVCo6KikKKwkjIEhvdyBkbyB3ZSBrbm93IGl0J3MgSW50ZXJpeCByYXRoZXIgdGhhbiB0aGUg
Z2VuZXJpYyBQT1NJWCBzdWJzeXN0ZW0/CisJIyBJdCBhbHNvIGNvbmZsaWN0cyB3aXRoIHByZS0y
LjAgdmVyc2lvbnMgb2YgQVQmVCBVV0lOLiBTaG91bGQgd2UKKwkjIFVOQU1FX01BQ0hJTkUgYmFz
ZWQgb24gdGhlIG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFkIG9mIGkzODY/CisJZWNobyBpNTg2LXBj
LWludGVyaXgKKwlleGl0IDs7CisgICAgaSo6VVdJTio6KikKKwllY2hvICR7VU5BTUVfTUFDSElO
RX0tcGMtdXdpbgorCWV4aXQgOzsKKyAgICBhbWQ2NDpDWUdXSU4qOio6KiB8IHg4Nl82NDpDWUdX
SU4qOio6KikKKwllY2hvIHg4Nl82NC11bmtub3duLWN5Z3dpbgorCWV4aXQgOzsKKyAgICBwKjpD
WUdXSU4qOiopCisJZWNobyBwb3dlcnBjbGUtdW5rbm93bi1jeWd3aW4KKwlleGl0IDs7CisgICAg
cHJlcCo6U3VuT1M6NS4qOiopCisJZWNobyBwb3dlcnBjbGUtdW5rbm93bi1zb2xhcmlzMmBlY2hv
ICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsKKyAgICAqOkdO
VToqOiopCisJIyB0aGUgR05VIHN5c3RlbQorCWVjaG8gYGVjaG8gJHtVTkFNRV9NQUNISU5FfXxz
ZWQgLWUgJ3MsWy0vXS4qJCwsJ2AtdW5rbm93bi1nbnVgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNl
ZCAtZSAncywvLiokLCwnYAorCWV4aXQgOzsKKyAgICAqOkdOVS8qOio6KikKKwkjIG90aGVyIHN5
c3RlbXMgd2l0aCBHTlUgbGliYyBhbmQgdXNlcmxhbmQKKwllY2hvICR7VU5BTUVfTUFDSElORX0t
dW5rbm93bi1gZWNobyAke1VOQU1FX1NZU1RFTX0gfCBzZWQgJ3MsXlteL10qLywsJyB8IHRyICdb
QS1aXScgJ1thLXpdJ2BgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydg
LWdudQorCWV4aXQgOzsKKyAgICBpKjg2Ok1pbml4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElO
RX0tcGMtbWluaXgKKwlleGl0IDs7CisgICAgYWxwaGE6TGludXg6KjoqKQorCWNhc2UgYHNlZCAt
biAnL15jcHUgbW9kZWwvcy9eLio6IFwoLipcKS9cMS9wJyA8IC9wcm9jL2NwdWluZm9gIGluCisJ
ICBFVjUpICAgVU5BTUVfTUFDSElORT1hbHBoYWV2NSA7OworCSAgRVY1NikgIFVOQU1FX01BQ0hJ
TkU9YWxwaGFldjU2IDs7CisJICBQQ0E1NikgVU5BTUVfTUFDSElORT1hbHBoYXBjYTU2IDs7CisJ
ICBQQ0E1NykgVU5BTUVfTUFDSElORT1hbHBoYXBjYTU2IDs7CisJICBFVjYpICAgVU5BTUVfTUFD
SElORT1hbHBoYWV2NiA7OworCSAgRVY2NykgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjY3IDs7CisJ
ICBFVjY4KikgVU5BTUVfTUFDSElORT1hbHBoYWV2NjggOzsKKyAgICAgICAgZXNhYworCW9iamR1
bXAgLS1wcml2YXRlLWhlYWRlcnMgL2Jpbi9zaCB8IGdyZXAgLXEgbGQuc28uMQorCWlmIHRlc3Qg
IiQ/IiA9IDAgOyB0aGVuIExJQkM9ImxpYmMxIiA7IGVsc2UgTElCQz0iIiA7IGZpCisJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251JHtMSUJDfQorCWV4aXQgOzsKKyAgICBh
cm0qOkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJaWYgZWNobyBfX0FSTV9F
QUJJX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwgXAorCSAgICB8IGdyZXAgLXEg
X19BUk1fRUFCSV9fCisJdGhlbgorCSAgICBlY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1s
aW51eC1nbnUKKwllbHNlCisJICAgIGVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4
LWdudWVhYmkKKwlmaQorCWV4aXQgOzsKKyAgICBhdnIzMio6TGludXg6KjoqKQorCWVjaG8gJHtV
TkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBjcmlzOkxpbnV4
Oio6KikKKwllY2hvIGNyaXMtYXhpcy1saW51eC1nbnUKKwlleGl0IDs7CisgICAgY3Jpc3YzMjpM
aW51eDoqOiopCisJZWNobyBjcmlzdjMyLWF4aXMtbGludXgtZ251CisJZXhpdCA7OworICAgIGZy
djpMaW51eDoqOiopCisgICAgCWVjaG8gZnJ2LXVua25vd24tbGludXgtZ251CisJZXhpdCA7Owor
ICAgIGkqODY6TGludXg6KjoqKQorCUxJQkM9Z251CisJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAor
CXNlZCAncy9eCS8vJyA8PCBFT0YgPiRkdW1teS5jCisJI2lmZGVmIF9fZGlldGxpYmNfXworCUxJ
QkM9ZGlldGxpYmMKKwkjZW5kaWYKK0VPRgorCWV2YWwgYCRDQ19GT1JfQlVJTEQgLUUgJGR1bW15
LmMgMj4vZGV2L251bGwgfCBncmVwICdeTElCQydgCisJZWNobyAiJHtVTkFNRV9NQUNISU5FfS1w
Yy1saW51eC0ke0xJQkN9IgorCWV4aXQgOzsKKyAgICBpYTY0OkxpbnV4Oio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgbTMycio6TGlu
dXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQg
OzsKKyAgICBtNjgqOkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1s
aW51eC1nbnUKKwlleGl0IDs7CisgICAgbWlwczpMaW51eDoqOiogfCBtaXBzNjQ6TGludXg6Kjoq
KQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXku
YworCSN1bmRlZiBDUFUKKwkjdW5kZWYgJHtVTkFNRV9NQUNISU5FfQorCSN1bmRlZiAke1VOQU1F
X01BQ0hJTkV9ZWwKKwkjaWYgZGVmaW5lZChfX01JUFNFTF9fKSB8fCBkZWZpbmVkKF9fTUlQU0VM
KSB8fCBkZWZpbmVkKF9NSVBTRUwpIHx8IGRlZmluZWQoTUlQU0VMKQorCUNQVT0ke1VOQU1FX01B
Q0hJTkV9ZWwKKwkjZWxzZQorCSNpZiBkZWZpbmVkKF9fTUlQU0VCX18pIHx8IGRlZmluZWQoX19N
SVBTRUIpIHx8IGRlZmluZWQoX01JUFNFQikgfHwgZGVmaW5lZChNSVBTRUIpCisJQ1BVPSR7VU5B
TUVfTUFDSElORX0KKwkjZWxzZQorCUNQVT0KKwkjZW5kaWYKKwkjZW5kaWYKK0VPRgorCWV2YWwg
YCRDQ19GT1JfQlVJTEQgLUUgJGR1bW15LmMgMj4vZGV2L251bGwgfCBncmVwICdeQ1BVJ2AKKwl0
ZXN0IHgiJHtDUFV9IiAhPSB4ICYmIHsgZWNobyAiJHtDUFV9LXVua25vd24tbGludXgtZ251Ijsg
ZXhpdDsgfQorCTs7CisgICAgb3IzMjpMaW51eDoqOiopCisJZWNobyBvcjMyLXVua25vd24tbGlu
dXgtZ251CisJZXhpdCA7OworICAgIHBhZHJlOkxpbnV4Oio6KikKKwllY2hvIHNwYXJjLXVua25v
d24tbGludXgtZ251CisJZXhpdCA7OworICAgIHBhcmlzYzY0OkxpbnV4Oio6KiB8IGhwcGE2NDpM
aW51eDoqOiopCisJZWNobyBocHBhNjQtdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAg
cGFyaXNjOkxpbnV4Oio6KiB8IGhwcGE6TGludXg6KjoqKQorCSMgTG9vayBmb3IgQ1BVIGxldmVs
CisJY2FzZSBgZ3JlcCAnXmNwdVteYS16XSo6JyAvcHJvYy9jcHVpbmZvIDI+L2Rldi9udWxsIHwg
Y3V0IC1kJyAnIC1mMmAgaW4KKwkgIFBBNyopIGVjaG8gaHBwYTEuMS11bmtub3duLWxpbnV4LWdu
dSA7OworCSAgUEE4KikgZWNobyBocHBhMi4wLXVua25vd24tbGludXgtZ251IDs7CisJICAqKSAg
ICBlY2hvIGhwcGEtdW5rbm93bi1saW51eC1nbnUgOzsKKwllc2FjCisJZXhpdCA7OworICAgIHBw
YzY0OkxpbnV4Oio6KikKKwllY2hvIHBvd2VycGM2NC11bmtub3duLWxpbnV4LWdudQorCWV4aXQg
OzsKKyAgICBwcGM6TGludXg6KjoqKQorCWVjaG8gcG93ZXJwYy11bmtub3duLWxpbnV4LWdudQor
CWV4aXQgOzsKKyAgICBzMzkwOkxpbnV4Oio6KiB8IHMzOTB4OkxpbnV4Oio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0taWJtLWxpbnV4CisJZXhpdCA7OworICAgIHNoNjQqOkxpbnV4Oio6KikK
KyAgICAJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7Owor
ICAgIHNoKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHNwYXJjOkxpbnV4Oio6KiB8IHNwYXJjNjQ6TGludXg6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB2
YXg6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1kZWMtbGludXgtZ251CisJZXhp
dCA7OworICAgIHg4Nl82NDpMaW51eDoqOiopCisJZWNobyB4ODZfNjQtdW5rbm93bi1saW51eC1n
bnUKKwlleGl0IDs7CisgICAgeHRlbnNhKjpMaW51eDoqOiopCisgICAgCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBpKjg2OkRZTklYL3B0eDo0
KjoqKQorCSMgcHR4IDQuMCBkb2VzIHVuYW1lIC1zIGNvcnJlY3RseSwgd2l0aCBEWU5JWC9wdHgg
aW4gdGhlcmUuCisJIyBlYXJsaWVyIHZlcnNpb25zIGFyZSBtZXNzZWQgdXAgYW5kIHB1dCB0aGUg
bm9kZW5hbWUgaW4gYm90aAorCSMgc3lzbmFtZSBhbmQgbm9kZW5hbWUuCisJZWNobyBpMzg2LXNl
cXVlbnQtc3lzdjQKKwlleGl0IDs7CisgICAgaSo4NjpVTklYX1NWOjQuMk1QOjIuKikKKyAgICAg
ICAgIyBVbml4d2FyZSBpcyBhbiBvZmZzaG9vdCBvZiBTVlI0LCBidXQgaXQgaGFzIGl0cyBvd24g
dmVyc2lvbgorICAgICAgICAjIG51bWJlciBzZXJpZXMgc3RhcnRpbmcgd2l0aCAyLi4uCisgICAg
ICAgICMgSSBhbSBub3QgcG9zaXRpdmUgdGhhdCBvdGhlciBTVlI0IHN5c3RlbXMgd29uJ3QgbWF0
Y2ggdGhpcywKKwkjIEkganVzdCBoYXZlIHRvIGhvcGUuICAtLSBybXMuCisgICAgICAgICMgVXNl
IHN5c3Y0LjJ1dy4uLiBzbyB0aGF0IHN5c3Y0KiBtYXRjaGVzIGl0LgorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1wYy1zeXN2NC4ydXcke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6
T1MvMjoqOiopCisJIyBJZiB3ZSB3ZXJlIGFibGUgdG8gZmluZCBgdW5hbWUnLCB0aGVuIEVNWCBV
bml4IGNvbXBhdGliaWxpdHkKKwkjIGlzIHByb2JhYmx5IGluc3RhbGxlZC4KKwllY2hvICR7VU5B
TUVfTUFDSElORX0tcGMtb3MyLWVteAorCWV4aXQgOzsKKyAgICBpKjg2OlhUUy0zMDA6KjpTVE9Q
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXN0b3AKKwlleGl0IDs7CisgICAgaSo4
NjphdGhlb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWF0aGVvcworCWV4
aXQgOzsKKyAgICBpKjg2OnN5bGxhYmxlOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMt
c3lsbGFibGUKKwlleGl0IDs7CisgICAgaSo4NjpMeW54T1M6Mi4qOiogfCBpKjg2Okx5bnhPUzoz
LlswMV0qOiogfCBpKjg2Okx5bnhPUzo0LlswMl0qOiopCisJZWNobyBpMzg2LXVua25vd24tbHlu
eG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBpKjg2OipET1M6KjoqKQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1wYy1tc2Rvc2RqZ3BwCisJZXhpdCA7OworICAgIGkqODY6Kjo0Lio6
KiB8IGkqODY6U1lTVEVNX1Y6NC4qOiopCisJVU5BTUVfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFT
RX0gfCBzZWQgJ3MvXC9NUCQvLydgCisJaWYgZ3JlcCBOb3ZlbGwgL3Vzci9pbmNsdWRlL2xpbmsu
aCA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11
bml2ZWwtc3lzdiR7VU5BTUVfUkVMfQorCWVsc2UKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBj
LXN5c3Yke1VOQU1FX1JFTH0KKwlmaQorCWV4aXQgOzsKKyAgICBpKjg2Oio6NTpbNjc4XSopCisg
ICAgCSMgVW5peFdhcmUgNy54LCBPcGVuVU5JWCBhbmQgT3BlblNlcnZlciA2LgorCWNhc2UgYC9i
aW4vdW5hbWUgLVggfCBncmVwICJeTWFjaGluZSJgIGluCisJICAgICo0ODYqKQkgICAgIFVOQU1F
X01BQ0hJTkU9aTQ4NiA7OworCSAgICAqUGVudGl1bSkJICAgICBVTkFNRV9NQUNISU5FPWk1ODYg
OzsKKwkgICAgKlBlbnQqfCpDZWxlcm9uKSBVTkFNRV9NQUNISU5FPWk2ODYgOzsKKwllc2FjCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFTRX0ke1VOQU1F
X1NZU1RFTX0ke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6KjozLjI6KikKKwlp
ZiB0ZXN0IC1mIC91c3Ivb3B0aW9ucy9jYi5uYW1lOyB0aGVuCisJCVVOQU1FX1JFTD1gc2VkIC1u
ICdzLy4qVmVyc2lvbiAvL3AnIDwvdXNyL29wdGlvbnMvY2IubmFtZWAKKwkJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXBjLWlzYyRVTkFNRV9SRUwKKwllbGlmIC9iaW4vdW5hbWUgLVggMj4vZGV2L251
bGwgPi9kZXYvbnVsbCA7IHRoZW4KKwkJVU5BTUVfUkVMPWAoL2Jpbi91bmFtZSAtWHxncmVwIFJl
bGVhc2V8c2VkIC1lICdzLy4qPSAvLycpYAorCQkoL2Jpbi91bmFtZSAtWHxncmVwIGk4MDQ4NiA+
L2Rldi9udWxsKSAmJiBVTkFNRV9NQUNISU5FPWk0ODYKKwkJKC9iaW4vdW5hbWUgLVh8Z3JlcCAn
Xk1hY2hpbmUuKlBlbnRpdW0nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTU4
NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFjaGluZS4qUGVudCAqSUknID4vZGV2L251bGwp
IFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTY4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFj
aGluZS4qUGVudGl1bSBQcm8nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTY4
NgorCQllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc2NvJFVOQU1FX1JFTAorCWVsc2UKKwkJZWNo
byAke1VOQU1FX01BQ0hJTkV9LXBjLXN5c3YzMgorCWZpCisJZXhpdCA7OworICAgIHBjOio6Kjoq
KQorCSMgTGVmdCBoZXJlIGZvciBjb21wYXRpYmlsaXR5OgorICAgICAgICAjIHVuYW1lIC1tIHBy
aW50cyBmb3IgREpHUFAgYWx3YXlzICdwYycsIGJ1dCBpdCBwcmludHMgbm90aGluZyBhYm91dAor
ICAgICAgICAjIHRoZSBwcm9jZXNzb3IsIHNvIHdlIHBsYXkgc2FmZSBieSBhc3N1bWluZyBpNTg2
LgorCSMgTm90ZTogd2hhdGV2ZXIgdGhpcyBpcywgaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB3aGF0
IGNvbmZpZy5zdWIKKwkjIHByaW50cyBmb3IgdGhlICJkamdwcCIgaG9zdCwgb3IgZWxzZSBHREIg
Y29uZmlndXJ5IHdpbGwgZGVjaWRlIHRoYXQKKwkjIHRoaXMgaXMgYSBjcm9zcy1idWlsZC4KKwll
Y2hvIGk1ODYtcGMtbXNkb3NkamdwcAorICAgICAgICBleGl0IDs7CisgICAgSW50ZWw6TWFjaDoz
KjoqKQorCWVjaG8gaTM4Ni1wYy1tYWNoMworCWV4aXQgOzsKKyAgICBwYXJhZ29uOio6KjoqKQor
CWVjaG8gaTg2MC1pbnRlbC1vc2YxCisJZXhpdCA7OworICAgIGk4NjA6Kjo0Lio6KikgIyBpODYw
LVNWUjQKKwlpZiBncmVwIFN0YXJkZW50IC91c3IvaW5jbHVkZS9zeXMvdWFkbWluLmggPi9kZXYv
bnVsbCAyPiYxIDsgdGhlbgorCSAgZWNobyBpODYwLXN0YXJkZW50LXN5c3Yke1VOQU1FX1JFTEVB
U0V9ICMgU3RhcmRlbnQgVmlzdHJhIGk4NjAtU1ZSNAorCWVsc2UgIyBBZGQgb3RoZXIgaTg2MC1T
VlI0IHZlbmRvcnMgYmVsb3cgYXMgdGhleSBhcmUgZGlzY292ZXJlZC4KKwkgIGVjaG8gaTg2MC11
bmtub3duLXN5c3Yke1VOQU1FX1JFTEVBU0V9ICAjIFVua25vd24gaTg2MC1TVlI0CisJZmkKKwll
eGl0IDs7CisgICAgbWluaSo6Q1RJWDpTWVMqNToqKQorCSMgIm1pbmlmcmFtZSIKKwllY2hvIG02
ODAxMC1jb252ZXJnZW50LXN5c3YKKwlleGl0IDs7CisgICAgbWM2OGs6VU5JWDpTWVNURU01OjMu
NTFtKQorCWVjaG8gbTY4ay1jb252ZXJnZW50LXN5c3YKKwlleGl0IDs7CisgICAgTTY4MD8wOkQt
TklYOjUuMzoqKQorCWVjaG8gbTY4ay1kaWFiLWRuaXgKKwlleGl0IDs7CisgICAgTTY4KjoqOlIz
Vls1Njc4XSo6KikKKwl0ZXN0IC1yIC9zeXNWNjggJiYgeyBlY2hvICdtNjhrLW1vdG9yb2xhLXN5
c3YnOyBleGl0OyB9IDs7CisgICAgM1szNDVdPz86Kjo0LjA6My4wIHwgM1szNF0/P0E6Kjo0LjA6
My4wIHwgM1szNF0/PywqOio6NC4wOjMuMCB8IDNbMzRdPz8vKjoqOjQuMDozLjAgfCA0NDAwOio6
NC4wOjMuMCB8IDQ4NTA6Kjo0LjA6My4wIHwgU0tBNDA6Kjo0LjA6My4wIHwgU0RTMjoqOjQuMDoz
LjAgfCBTSEcyOio6NC4wOjMuMCB8IFM3NTAxKjoqOjQuMDozLjApCisJT1NfUkVMPScnCisJdGVz
dCAtciAvZXRjLy5yZWxpZCBcCisJJiYgT1NfUkVMPS5gc2VkIC1uICdzL1teIF0qIFteIF0qIFwo
WzAtOV1bMC05XVwpLiovXDEvcCcgPCAvZXRjLy5yZWxpZGAKKwkvYmluL3VuYW1lIC1wIDI+L2Rl
di9udWxsIHwgZ3JlcCA4NiA+L2Rldi9udWxsIFwKKwkgICYmIHsgZWNobyBpNDg2LW5jci1zeXN2
NC4zJHtPU19SRUx9OyBleGl0OyB9CisJL2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVsbCB8IC9iaW4v
Z3JlcCBlbnRpdW0gPi9kZXYvbnVsbCBcCisJICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQuMyR7
T1NfUkVMfTsgZXhpdDsgfSA7OworICAgIDNbMzRdPz86Kjo0LjA6KiB8IDNbMzRdPz8sKjoqOjQu
MDoqKQorICAgICAgICAvYmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4NiA+L2Rldi9u
dWxsIFwKKyAgICAgICAgICAmJiB7IGVjaG8gaTQ4Ni1uY3Itc3lzdjQ7IGV4aXQ7IH0gOzsKKyAg
ICBOQ1IqOio6NC4yOiogfCBNUFJBUyo6Kjo0LjI6KikKKwlPU19SRUw9Jy4zJworCXRlc3QgLXIg
L2V0Yy8ucmVsaWQgXAorCSAgICAmJiBPU19SRUw9LmBzZWQgLW4gJ3MvW14gXSogW14gXSogXChb
MC05XVswLTldXCkuKi9cMS9wJyA8IC9ldGMvLnJlbGlkYAorCS9iaW4vdW5hbWUgLXAgMj4vZGV2
L251bGwgfCBncmVwIDg2ID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8gaTQ4Ni1uY3Itc3lz
djQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCAvYmlu
L2dyZXAgZW50aXVtID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQu
MyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCAvYmluL2dy
ZXAgcHRlcm9uID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQuMyR7
T1NfUkVMfTsgZXhpdDsgfSA7OworICAgIG02OCo6THlueE9TOjIuKjoqIHwgbTY4KjpMeW54T1M6
My4wKjoqKQorCWVjaG8gbTY4ay11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0
IDs7CisgICAgbWM2ODAzMDpVTklYX1N5c3RlbV9WOjQuKjoqKQorCWVjaG8gbTY4ay1hdGFyaS1z
eXN2NAorCWV4aXQgOzsKKyAgICBUU1VOQU1JOkx5bnhPUzoyLio6KikKKwllY2hvIHNwYXJjLXVu
a25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICByczYwMDA6THlueE9T
OjIuKjoqKQorCWVjaG8gcnM2MDAwLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICBQb3dlclBDOkx5bnhPUzoyLio6KiB8IFBvd2VyUEM6THlueE9TOjMuWzAxXSo6
KiB8IFBvd2VyUEM6THlueE9TOjQuWzAyXSo6KikKKwllY2hvIHBvd2VycGMtdW5rbm93bi1seW54
b3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFNNW0JFXVM6VU5JWF9TVjoqOiopCisJ
ZWNobyBtaXBzLWRkZS1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBSTSo6UmVs
aWFudFVOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAorCWV4aXQgOzsKKyAgICBSTSo6
U0lOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAorCWV4aXQgOzsKKyAgICAqOlNJTklY
LSo6KjoqKQorCWlmIHVuYW1lIC1wIDI+L2Rldi9udWxsID4vZGV2L251bGwgOyB0aGVuCisJCVVO
QU1FX01BQ0hJTkU9YCh1bmFtZSAtcCkgMj4vZGV2L251bGxgCisJCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS1zbmktc3lzdjQKKwllbHNlCisJCWVjaG8gbnMzMmstc25pLXN5c3YKKwlmaQorCWV4aXQg
OzsKKyAgICBQRU5USVVNOio6NC4wKjoqKSAjIFVuaXN5cyBgQ2xlYXJQYXRoIEhNUCBJWCA0MDAw
JyBTVlI0L01QIGVmZm9ydAorICAgICAgICAgICAgICAgICAgICAgICMgc2F5cyA8UmljaGFyZC5N
LkJhcnRlbEBjY01haWwuQ2Vuc3VzLkdPVj4KKyAgICAgICAgZWNobyBpNTg2LXVuaXN5cy1zeXN2
NAorICAgICAgICBleGl0IDs7CisgICAgKjpVTklYX1N5c3RlbV9WOjQqOkZUWCopCisJIyBGcm9t
IEdlcmFsZCBIZXdlcyA8aGV3ZXNAb3Blbm1hcmtldC5jb20+LgorCSMgSG93IGFib3V0IGRpZmZl
cmVudGlhdGluZyBiZXR3ZWVuIHN0cmF0dXMgYXJjaGl0ZWN0dXJlcz8gLWRqbQorCWVjaG8gaHBw
YTEuMS1zdHJhdHVzLXN5c3Y0CisJZXhpdCA7OworICAgICo6KjoqOkZUWCopCisJIyBGcm9tIHNl
YW5mQHN3ZGMuc3RyYXR1cy5jb20uCisJZWNobyBpODYwLXN0cmF0dXMtc3lzdjQKKwlleGl0IDs7
CisgICAgaSo4NjpWT1M6KjoqKQorCSMgRnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS1zdHJhdHVzLXZvcworCWV4aXQgOzsKKyAgICAqOlZPUzoqOiop
CisJIyBGcm9tIFBhdWwuR3JlZW5Ac3RyYXR1cy5jb20uCisJZWNobyBocHBhMS4xLXN0cmF0dXMt
dm9zCisJZXhpdCA7OworICAgIG1jNjgqOkEvVVg6KjoqKQorCWVjaG8gbTY4ay1hcHBsZS1hdXgk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG5ld3MqOk5FV1MtT1M6Nio6KikKKwllY2hv
IG1pcHMtc29ueS1uZXdzb3M2CisJZXhpdCA7OworICAgIFJbMzRdMDAwOipTeXN0ZW1fVio6Kjoq
IHwgUjQwMDA6VU5JWF9TWVNWOio6KiB8IFIqMDAwOlVOSVhfU1Y6KjoqKQorCWlmIFsgLWQgL3Vz
ci9uZWMgXTsgdGhlbgorCSAgICAgICAgZWNobyBtaXBzLW5lYy1zeXN2JHtVTkFNRV9SRUxFQVNF
fQorCWVsc2UKKwkgICAgICAgIGVjaG8gbWlwcy11bmtub3duLXN5c3Yke1VOQU1FX1JFTEVBU0V9
CisJZmkKKyAgICAgICAgZXhpdCA7OworICAgIEJlQm94OkJlT1M6KjoqKQkjIEJlT1MgcnVubmlu
ZyBvbiBoYXJkd2FyZSBtYWRlIGJ5IEJlLCBQUEMgb25seS4KKwllY2hvIHBvd2VycGMtYmUtYmVv
cworCWV4aXQgOzsKKyAgICBCZU1hYzpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcgb24gTWFjIG9y
IE1hYyBjbG9uZSwgUFBDIG9ubHkuCisJZWNobyBwb3dlcnBjLWFwcGxlLWJlb3MKKwlleGl0IDs7
CisgICAgQmVQQzpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcgb24gSW50ZWwgUEMgY29tcGF0aWJs
ZS4KKwllY2hvIGk1ODYtcGMtYmVvcworCWV4aXQgOzsKKyAgICBCZVBDOkhhaWt1Oio6KikJIyBI
YWlrdSBydW5uaW5nIG9uIEludGVsIFBDIGNvbXBhdGlibGUuCisJZWNobyBpNTg2LXBjLWhhaWt1
CisJZXhpdCA7OworICAgIFNYLTQ6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g0LW5lYy1zdXBlcnV4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC01OlNVUEVSLVVYOio6KikKKwllY2hv
IHN4NS1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtNjpTVVBF
Ui1VWDoqOiopCisJZWNobyBzeDYtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIFNYLTc6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g3LW5lYy1zdXBlcnV4JHtVTkFNRV9S
RUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC04OlNVUEVSLVVYOio6KikKKwllY2hvIHN4OC1uZWMt
c3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtOFI6U1VQRVItVVg6Kjoq
KQorCWVjaG8gc3g4ci1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAg
UG93ZXIqOlJoYXBzb2R5Oio6KikKKwllY2hvIHBvd2VycGMtYXBwbGUtcmhhcHNvZHkke1VOQU1F
X1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6UmhhcHNvZHk6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1hcHBsZS1yaGFwc29keSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpE
YXJ3aW46KjoqKQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUgLXBgIHx8IFVOQU1FX1BST0NFU1NP
Uj11bmtub3duCisJY2FzZSAkVU5BTUVfUFJPQ0VTU09SIGluCisJICAgIGkzODYpCisJCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwkJaWYgWyAiJENDX0ZPUl9CVUlMRCIgIT0gJ25vX2NvbXBpbGVy
X2ZvdW5kJyBdOyB0aGVuCisJCSAgaWYgKGVjaG8gJyNpZmRlZiBfX0xQNjRfXyc7IGVjaG8gSVNf
NjRCSVRfQVJDSDsgZWNobyAnI2VuZGlmJykgfCBcCisJCSAgICAgIChDQ09QVFM9ICRDQ19GT1Jf
QlVJTEQgLUUgLSAyPi9kZXYvbnVsbCkgfCBcCisJCSAgICAgIGdyZXAgSVNfNjRCSVRfQVJDSCA+
L2Rldi9udWxsCisJCSAgdGhlbgorCQkgICAgICBVTkFNRV9QUk9DRVNTT1I9Ing4Nl82NCIKKwkJ
ICBmaQorCQlmaSA7OworCSAgICB1bmtub3duKSBVTkFNRV9QUk9DRVNTT1I9cG93ZXJwYyA7Owor
CWVzYWMKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS1hcHBsZS1kYXJ3aW4ke1VOQU1FX1JFTEVB
U0V9CisJZXhpdCA7OworICAgICo6cHJvY250byo6KjoqIHwgKjpRTlg6WzAxMjM0NTY3ODldKjoq
KQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUgLXBgCisJaWYgdGVzdCAiJFVOQU1FX1BST0NFU1NP
UiIgPSAieDg2IjsgdGhlbgorCQlVTkFNRV9QUk9DRVNTT1I9aTM4NgorCQlVTkFNRV9NQUNISU5F
PXBjCisJZmkKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS0ke1VOQU1FX01BQ0hJTkV9LW50by1x
bngke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6UU5YOio6NCopCisJZWNobyBpMzg2
LXBjLXFueAorCWV4aXQgOzsKKyAgICBOU0UtPzpOT05TVE9QX0tFUk5FTDoqOiopCisJZWNobyBu
c2UtdGFuZGVtLW5zayR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgTlNSLT86Tk9OU1RP
UF9LRVJORUw6KjoqKQorCWVjaG8gbnNyLXRhbmRlbS1uc2ske1VOQU1FX1JFTEVBU0V9CisJZXhp
dCA7OworICAgICo6Tm9uU3RvcC1VWDoqOiopCisJZWNobyBtaXBzLWNvbXBhcS1ub25zdG9wdXgK
KwlleGl0IDs7CisgICAgQlMyMDAwOlBPU0lYKjoqOiopCisJZWNobyBiczIwMDAtc2llbWVucy1z
eXN2CisJZXhpdCA7OworICAgIERTLyo6VU5JWF9TeXN0ZW1fVjoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LSR7VU5BTUVfU1lTVEVNfS0ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAg
ICo6UGxhbjk6KjoqKQorCSMgInVuYW1lIC1tIiBpcyBub3QgY29uc2lzdGVudCwgc28gdXNlICRj
cHV0eXBlIGluc3RlYWQuIDM4NgorCSMgaXMgY29udmVydGVkIHRvIGkzODYgZm9yIGNvbnNpc3Rl
bmN5IHdpdGggb3RoZXIgeDg2CisJIyBvcGVyYXRpbmcgc3lzdGVtcy4KKwlpZiB0ZXN0ICIkY3B1
dHlwZSIgPSAiMzg2IjsgdGhlbgorCSAgICBVTkFNRV9NQUNISU5FPWkzODYKKwllbHNlCisJICAg
IFVOQU1FX01BQ0hJTkU9IiRjcHV0eXBlIgorCWZpCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tcGxhbjkKKwlleGl0IDs7CisgICAgKjpUT1BTLTEwOio6KikKKwllY2hvIHBkcDEwLXVu
a25vd24tdG9wczEwCisJZXhpdCA7OworICAgICo6VEVORVg6KjoqKQorCWVjaG8gcGRwMTAtdW5r
bm93bi10ZW5leAorCWV4aXQgOzsKKyAgICBLUzEwOlRPUFMtMjA6KjoqIHwgS0wxMDpUT1BTLTIw
Oio6KiB8IFRZUEU0OlRPUFMtMjA6KjoqKQorCWVjaG8gcGRwMTAtZGVjLXRvcHMyMAorCWV4aXQg
OzsKKyAgICBYS0wtMTpUT1BTLTIwOio6KiB8IFRZUEU1OlRPUFMtMjA6KjoqKQorCWVjaG8gcGRw
MTAteGtsLXRvcHMyMAorCWV4aXQgOzsKKyAgICAqOlRPUFMtMjA6KjoqKQorCWVjaG8gcGRwMTAt
dW5rbm93bi10b3BzMjAKKwlleGl0IDs7CisgICAgKjpJVFM6KjoqKQorCWVjaG8gcGRwMTAtdW5r
bm93bi1pdHMKKwlleGl0IDs7CisgICAgU0VJOio6KjpTRUlVWCkKKyAgICAgICAgZWNobyBtaXBz
LXNlaS1zZWl1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpEcmFnb25GbHk6Kjoq
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWRyYWdvbmZseWBlY2hvICR7VU5BTUVf
UkVMRUFTRX18c2VkIC1lICdzL1stKF0uKi8vJ2AKKwlleGl0IDs7CisgICAgKjoqVk1TOio6KikK
KyAgICAJVU5BTUVfTUFDSElORT1gKHVuYW1lIC1wKSAyPi9kZXYvbnVsbGAKKwljYXNlICIke1VO
QU1FX01BQ0hJTkV9IiBpbgorCSAgICBBKikgZWNobyBhbHBoYS1kZWMtdm1zIDsgZXhpdCA7Owor
CSAgICBJKikgZWNobyBpYTY0LWRlYy12bXMgOyBleGl0IDs7CisJICAgIFYqKSBlY2hvIHZheC1k
ZWMtdm1zIDsgZXhpdCA7OworCWVzYWMgOzsKKyAgICAqOlhFTklYOio6U3lzVikKKwllY2hvIGkz
ODYtcGMteGVuaXgKKwlleGl0IDs7CisgICAgaSo4Njpza3lvczoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXBjLXNreW9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfWAgfCBzZWQgLWUgJ3MvIC4q
JC8vJworCWV4aXQgOzsKKyAgICBpKjg2OnJkb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5F
fS1wYy1yZG9zCisJZXhpdCA7OworICAgIGkqODY6QVJPUzoqOiopCisJZWNobyAke1VOQU1FX01B
Q0hJTkV9LXBjLWFyb3MKKwlleGl0IDs7Citlc2FjCisKKyNlY2hvICcoTm8gdW5hbWUgY29tbWFu
ZCBvciB1bmFtZSBvdXRwdXQgbm90IHJlY29nbml6ZWQuKScgMT4mMgorI2VjaG8gIiR7VU5BTUVf
TUFDSElORX06JHtVTkFNRV9TWVNURU19OiR7VU5BTUVfUkVMRUFTRX06JHtVTkFNRV9WRVJTSU9O
fSIgMT4mMgorCitldmFsICRzZXRfY2NfZm9yX2J1aWxkCitjYXQgPiRkdW1teS5jIDw8RU9GCisj
aWZkZWYgX1NFUVVFTlRfCisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorIyBpbmNsdWRlIDxzeXMv
dXRzbmFtZS5oPgorI2VuZGlmCittYWluICgpCit7CisjaWYgZGVmaW5lZCAoc29ueSkKKyNpZiBk
ZWZpbmVkIChNSVBTRUIpCisgIC8qIEJGRCB3YW50cyAiYnNkIiBpbnN0ZWFkIG9mICJuZXdzb3Mi
LiAgUGVyaGFwcyBCRkQgc2hvdWxkIGJlIGNoYW5nZWQsCisgICAgIEkgZG9uJ3Qga25vdy4uLi4g
ICovCisgIHByaW50ZiAoIm1pcHMtc29ueS1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbHNlCisjaW5j
bHVkZSA8c3lzL3BhcmFtLmg+CisgIHByaW50ZiAoIm02OGstc29ueS1uZXdzb3Mlc1xuIiwKKyNp
ZmRlZiBORVdTT1M0CisgICAgICAgICAgIjQiCisjZWxzZQorCSAgIiIKKyNlbmRpZgorICAgICAg
ICAgKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoX19hcm0pICYm
IGRlZmluZWQgKF9fYWNvcm4pICYmIGRlZmluZWQgKF9fdW5peCkKKyAgcHJpbnRmICgiYXJtLWFj
b3JuLXJpc2NpeFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBkZWZpbmVkIChocDMwMCkg
JiYgIWRlZmluZWQgKGhwdXgpCisgIHByaW50ZiAoIm02OGstaHAtYnNkXG4iKTsgZXhpdCAoMCk7
CisjZW5kaWYKKworI2lmIGRlZmluZWQgKE5lWFQpCisjaWYgIWRlZmluZWQgKF9fQVJDSElURUNU
VVJFX18pCisjZGVmaW5lIF9fQVJDSElURUNUVVJFX18gIm02OGsiCisjZW5kaWYKKyAgaW50IHZl
cnNpb247CisgIHZlcnNpb249YChob3N0aW5mbyB8IHNlZCAtbiAncy8uKk5lWFQgTWFjaCBcKFsw
LTldKlwpLiovXDEvcCcpIDI+L2Rldi9udWxsYDsKKyAgaWYgKHZlcnNpb24gPCA0KQorICAgIHBy
aW50ZiAoIiVzLW5leHQtbmV4dHN0ZXAlZFxuIiwgX19BUkNISVRFQ1RVUkVfXywgdmVyc2lvbik7
CisgIGVsc2UKKyAgICBwcmludGYgKCIlcy1uZXh0LW9wZW5zdGVwJWRcbiIsIF9fQVJDSElURUNU
VVJFX18sIHZlcnNpb24pOworICBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoTVVM
VElNQVgpIHx8IGRlZmluZWQgKG4xNikKKyNpZiBkZWZpbmVkIChVTUFYVikKKyAgcHJpbnRmICgi
bnMzMmstZW5jb3JlLXN5c3ZcbiIpOyBleGl0ICgwKTsKKyNlbHNlCisjaWYgZGVmaW5lZCAoQ01V
KQorICBwcmludGYgKCJuczMyay1lbmNvcmUtbWFjaFxuIik7IGV4aXQgKDApOworI2Vsc2UKKyAg
cHJpbnRmICgibnMzMmstZW5jb3JlLWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisjZW5kaWYK
KyNlbmRpZgorCisjaWYgZGVmaW5lZCAoX18zODZCU0RfXykKKyAgcHJpbnRmICgiaTM4Ni1wYy1i
c2RcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoc2VxdWVudCkKKyNpZiBk
ZWZpbmVkIChpMzg2KQorICBwcmludGYgKCJpMzg2LXNlcXVlbnQtZHluaXhcbiIpOyBleGl0ICgw
KTsKKyNlbmRpZgorI2lmIGRlZmluZWQgKG5zMzIwMDApCisgIHByaW50ZiAoIm5zMzJrLXNlcXVl
bnQtZHluaXhcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorI2VuZGlmCisKKyNpZiBkZWZpbmVkIChf
U0VRVUVOVF8pCisgICAgc3RydWN0IHV0c25hbWUgdW47CisKKyAgICB1bmFtZSgmdW4pOworCisg
ICAgaWYgKHN0cm5jbXAodW4udmVyc2lvbiwgIlYyIiwgMikgPT0gMCkgeworCXByaW50ZiAoImkz
ODYtc2VxdWVudC1wdHgyXG4iKTsgZXhpdCAoMCk7CisgICAgfQorICAgIGlmIChzdHJuY21wKHVu
LnZlcnNpb24sICJWMSIsIDIpID09IDApIHsgLyogWFhYIGlzIFYxIGNvcnJlY3Q/ICovCisJcHJp
bnRmICgiaTM4Ni1zZXF1ZW50LXB0eDFcbiIpOyBleGl0ICgwKTsKKyAgICB9CisgICAgcHJpbnRm
ICgiaTM4Ni1zZXF1ZW50LXB0eFxuIik7IGV4aXQgKDApOworCisjZW5kaWYKKworI2lmIGRlZmlu
ZWQgKHZheCkKKyMgaWYgIWRlZmluZWQgKHVsdHJpeCkKKyMgIGluY2x1ZGUgPHN5cy9wYXJhbS5o
PgorIyAgaWYgZGVmaW5lZCAoQlNEKQorIyAgIGlmIEJTRCA9PSA0MworICAgICAgcHJpbnRmICgi
dmF4LWRlYy1ic2Q0LjNcbiIpOyBleGl0ICgwKTsKKyMgICBlbHNlCisjICAgIGlmIEJTRCA9PSAx
OTkwMDYKKyAgICAgIHByaW50ZiAoInZheC1kZWMtYnNkNC4zcmVub1xuIik7IGV4aXQgKDApOwor
IyAgICBlbHNlCisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZFxuIik7IGV4aXQgKDApOworIyAg
ICBlbmRpZgorIyAgIGVuZGlmCisjICBlbHNlCisgICAgcHJpbnRmICgidmF4LWRlYy1ic2RcbiIp
OyBleGl0ICgwKTsKKyMgIGVuZGlmCisjIGVsc2UKKyAgICBwcmludGYgKCJ2YXgtZGVjLXVsdHJp
eFxuIik7IGV4aXQgKDApOworIyBlbmRpZgorI2VuZGlmCisKKyNpZiBkZWZpbmVkIChhbGxpYW50
KSAmJiBkZWZpbmVkIChpODYwKQorICBwcmludGYgKCJpODYwLWFsbGlhbnQtYnNkXG4iKTsgZXhp
dCAoMCk7CisjZW5kaWYKKworICBleGl0ICgxKTsKK30KK0VPRgorCiskQ0NfRk9SX0JVSUxEIC1v
ICRkdW1teSAkZHVtbXkuYyAyPi9kZXYvbnVsbCAmJiBTWVNURU1fTkFNRT1gJGR1bW15YCAmJgor
CXsgZWNobyAiJFNZU1RFTV9OQU1FIjsgZXhpdDsgfQorCisjIEFwb2xsb3MgcHV0IHRoZSBzeXN0
ZW0gdHlwZSBpbiB0aGUgZW52aXJvbm1lbnQuCisKK3Rlc3QgLWQgL3Vzci9hcG9sbG8gJiYgeyBl
Y2hvICR7SVNQfS1hcG9sbG8tJHtTWVNUWVBFfTsgZXhpdDsgfQorCisjIENvbnZleCB2ZXJzaW9u
cyB0aGF0IHByZWRhdGUgdW5hbWUgY2FuIHVzZSBnZXRzeXNpbmZvKDEpCisKK2lmIFsgLXggL3Vz
ci9jb252ZXgvZ2V0c3lzaW5mbyBdCit0aGVuCisgICAgY2FzZSBgZ2V0c3lzaW5mbyAtZiBjcHVf
dHlwZWAgaW4KKyAgICBjMSopCisJZWNobyBjMS1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGMy
KikKKwlpZiBnZXRzeXNpbmZvIC1mIHNjYWxhcl9hY2MKKwl0aGVuIGVjaG8gYzMyLWNvbnZleC1i
c2QKKwllbHNlIGVjaG8gYzItY29udmV4LWJzZAorCWZpCisJZXhpdCA7OworICAgIGMzNCopCisJ
ZWNobyBjMzQtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBjMzgqKQorCWVjaG8gYzM4LWNvbnZl
eC1ic2QKKwlleGl0IDs7CisgICAgYzQqKQorCWVjaG8gYzQtY29udmV4LWJzZAorCWV4aXQgOzsK
KyAgICBlc2FjCitmaQorCitjYXQgPiYyIDw8RU9GCiskMDogdW5hYmxlIHRvIGd1ZXNzIHN5c3Rl
bSB0eXBlCisKK1RoaXMgc2NyaXB0LCBsYXN0IG1vZGlmaWVkICR0aW1lc3RhbXAsIGhhcyBmYWls
ZWQgdG8gcmVjb2duaXplCit0aGUgb3BlcmF0aW5nIHN5c3RlbSB5b3UgYXJlIHVzaW5nLiBJdCBp
cyBhZHZpc2VkIHRoYXQgeW91Citkb3dubG9hZCB0aGUgbW9zdCB1cCB0byBkYXRlIHZlcnNpb24g
b2YgdGhlIGNvbmZpZyBzY3JpcHRzIGZyb20KKworICBodHRwOi8vZ2l0LnNhdmFubmFoLmdudS5v
cmcvZ2l0d2ViLz9wPWNvbmZpZy5naXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmlnLmd1ZXNzO2hiPUhF
QUQKK2FuZAorICBodHRwOi8vZ2l0LnNhdmFubmFoLmdudS5vcmcvZ2l0d2ViLz9wPWNvbmZpZy5n
aXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmlnLnN1YjtoYj1IRUFECisKK0lmIHRoZSB2ZXJzaW9uIHlv
dSBydW4gKCQwKSBpcyBhbHJlYWR5IHVwIHRvIGRhdGUsIHBsZWFzZQorc2VuZCB0aGUgZm9sbG93
aW5nIGRhdGEgYW5kIGFueSBpbmZvcm1hdGlvbiB5b3UgdGhpbmsgbWlnaHQgYmUKK3BlcnRpbmVu
dCB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9yZz4gaW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgbmVl
ZGVkCitpbmZvcm1hdGlvbiB0byBoYW5kbGUgeW91ciBzeXN0ZW0uCisKK2NvbmZpZy5ndWVzcyB0
aW1lc3RhbXAgPSAkdGltZXN0YW1wCisKK3VuYW1lIC1tID0gYCh1bmFtZSAtbSkgMj4vZGV2L251
bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXIgPSBgKHVuYW1lIC1yKSAyPi9kZXYvbnVsbCB8
fCBlY2hvIHVua25vd25gCit1bmFtZSAtcyA9IGAodW5hbWUgLXMpIDI+L2Rldi9udWxsIHx8IGVj
aG8gdW5rbm93bmAKK3VuYW1lIC12ID0gYCh1bmFtZSAtdikgMj4vZGV2L251bGwgfHwgZWNobyB1
bmtub3duYAorCisvdXNyL2Jpbi91bmFtZSAtcCA9IGAoL3Vzci9iaW4vdW5hbWUgLXApIDI+L2Rl
di9udWxsYAorL2Jpbi91bmFtZSAtWCAgICAgPSBgKC9iaW4vdW5hbWUgLVgpIDI+L2Rldi9udWxs
YAorCitob3N0aW5mbyAgICAgICAgICAgICAgID0gYChob3N0aW5mbykgMj4vZGV2L251bGxgCisv
YmluL3VuaXZlcnNlICAgICAgICAgID0gYCgvYmluL3VuaXZlcnNlKSAyPi9kZXYvbnVsbGAKKy91
c3IvYmluL2FyY2ggLWsgICAgICAgPSBgKC91c3IvYmluL2FyY2ggLWspIDI+L2Rldi9udWxsYAor
L2Jpbi9hcmNoICAgICAgICAgICAgICA9IGAoL2Jpbi9hcmNoKSAyPi9kZXYvbnVsbGAKKy91c3Iv
YmluL29zbGV2ZWwgICAgICAgPSBgKC91c3IvYmluL29zbGV2ZWwpIDI+L2Rldi9udWxsYAorL3Vz
ci9jb252ZXgvZ2V0c3lzaW5mbyA9IGAoL3Vzci9jb252ZXgvZ2V0c3lzaW5mbykgMj4vZGV2L251
bGxgCisKK1VOQU1FX01BQ0hJTkUgPSAke1VOQU1FX01BQ0hJTkV9CitVTkFNRV9SRUxFQVNFID0g
JHtVTkFNRV9SRUxFQVNFfQorVU5BTUVfU1lTVEVNICA9ICR7VU5BTUVfU1lTVEVNfQorVU5BTUVf
VkVSU0lPTiA9ICR7VU5BTUVfVkVSU0lPTn0KK0VPRgorCitleGl0IDEKKworIyBMb2NhbCB2YXJp
YWJsZXM6CisjIGV2YWw6IChhZGQtaG9vayAnd3JpdGUtZmlsZS1ob29rcyAndGltZS1zdGFtcCkK
KyMgdGltZS1zdGFtcC1zdGFydDogInRpbWVzdGFtcD0nIgorIyB0aW1lLXN0YW1wLWZvcm1hdDog
IiU6eS0lMDJtLSUwMmQiCisjIHRpbWUtc3RhbXAtZW5kOiAiJyIKKyMgRW5kOgpkaWZmIC1yIDVi
MjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY29uZmlnLmguaW4KLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlnLmguaW4J
VHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNDY4IEBACisvKiBjb25m
aWcuaC5pbi4gIEdlbmVyYXRlZCBmcm9tIGNvbmZpZ3VyZS5hYyBieSBhdXRvaGVhZGVyLiAgKi8K
KworLyogRGVmaW5lIHRvIG9uZSBvZiBgX2dldGI2NycsIGBHRVRCNjcnLCBgZ2V0YjY3JyBmb3Ig
Q3JheS0yIGFuZCBDcmF5LVlNUAorICAgc3lzdGVtcy4gVGhpcyBmdW5jdGlvbiBpcyByZXF1aXJl
ZCBmb3IgYGFsbG9jYS5jJyBzdXBwb3J0IG9uIHRob3NlIHN5c3RlbXMuCisgICAqLworI3VuZGVm
IENSQVlfU1RBQ0tTRUdfRU5ECisKKy8qIERlZmluZSB0byAxIGlmIHVzaW5nIGBhbGxvY2EuYycu
ICovCisjdW5kZWYgQ19BTExPQ0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBh
bGFybScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9BTEFSTQorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSBgYWxsb2NhJywgYXMgYSBmdW5jdGlvbiBvciBtYWNyby4gKi8KKyN1bmRlZiBI
QVZFX0FMTE9DQQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSA8YWxsb2NhLmg+IGFuZCBp
dCBzaG91bGQgYmUgdXNlZCAobm90IG9uIFVsdHJpeCkuCisgICAqLworI3VuZGVmIEhBVkVfQUxM
T0NBX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxhcnBhL2luZXQuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9BUlBBX0lORVRfSAorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYGF0ZXhpdCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9BVEVYSVQK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBiemVybycgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9CWkVSTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGNsb2Nr
X2dldHRpbWUnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQ0xPQ0tfR0VUVElNRQorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGR1cDInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfRFVQMgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGZjbnRsLmg+IGhlYWRl
ciBmaWxlLiAqLworI3VuZGVmIEhBVkVfRkNOVExfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug
aGF2ZSB0aGUgYGZkYXRhc3luYycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9GREFUQVNZTkMK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmb3JrJyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX0ZPUksKKworLyogRGVmaW5lIHRvIDEgaWYgZnNlZWtvIChhbmQgcHJlc3VtYWJs
eSBmdGVsbG8pIGV4aXN0cyBhbmQgaXMgZGVjbGFyZWQuICovCisjdW5kZWYgSEFWRV9GU0VFS08K
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmdHJ1bmNhdGUnIGZ1bmN0aW9uLiAq
LworI3VuZGVmIEhBVkVfRlRSVU5DQVRFCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgZ2V0Y3dkJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVENXRAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldGhvc3RieW5hbWUnIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfR0VUSE9TVEJZTkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdl
dGhvc3RuYW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVEhPU1ROQU1FCisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZ2V0cGFnZXNpemUnIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfR0VUUEFHRVNJWkUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBn
ZXR0aW1lb2ZkYXknIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfR0VUVElNRU9GREFZCisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgaW5ldF9udG9hJyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX0lORVRfTlRPQQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGlu
dHR5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfSU5UVFlQRVNfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGlzYXNjaWknIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfSVNBU0NJSQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGNyeXB0bycg
bGlicmFyeSAoLWxjcnlwdG8pLiAqLworI3VuZGVmIEhBVkVfTElCQ1JZUFRPCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bGliaW50bC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRl
ZiBIQVZFX0xJQklOVExfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJ0JyBs
aWJyYXJ5ICgtbHJ0KS4gKi8KKyN1bmRlZiBIQVZFX0xJQlJUCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgdXVpZCcgbGlicmFyeSAoLWx1dWlkKS4gKi8KKyN1bmRlZiBIQVZFX0xJ
QlVVSUQKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB5YWpsJyBsaWJyYXJ5ICgt
bHlhamwpLiAqLworI3VuZGVmIEhBVkVfTElCWUFKTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug
aGF2ZSB0aGUgYHonIGxpYnJhcnkgKC1seikuICovCisjdW5kZWYgSEFWRV9MSUJaCisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bGltaXRzLmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfTElNSVRTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBsb2Nh
bHRpbWVfcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9MT0NBTFRJTUVfUgorCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3VyIHN5c3RlbSBoYXMgYSBHTlUgbGliYyBjb21wYXRpYmxlIGBtYWxsb2Mn
IGZ1bmN0aW9uLCBhbmQKKyAgIHRvIDAgb3RoZXJ3aXNlLiAqLworI3VuZGVmIEhBVkVfTUFMTE9D
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bWFsbG9jLmg+IGhlYWRlciBmaWxl
LiAqLworI3VuZGVmIEhBVkVfTUFMTE9DX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBtZW1jaHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTUVNQ0hSCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtbW92ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFW
RV9NRU1NT1ZFCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bWVtb3J5Lmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTUVNT1JZX0gKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIGBtZW1zZXQnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTUVNU0VUCisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWtkaXInIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfTUtESVIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBta2ZpZm8n
IGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTUtGSUZPCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIGEgd29ya2luZyBgbW1hcCcgc3lzdGVtIGNhbGwuICovCisjdW5kZWYgSEFWRV9NTUFQ
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbXVubWFwJyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX01VTk1BUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG5l
dGRiLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTkVUREJfSAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG5ldGluZXQvaW4uaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9ORVRJTkVUX0lOX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBw
YXRoY29uZicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9QQVRIQ09ORgorCisvKiBEZWZpbmUg
dG8gMSBpZiB0aGUgc3lzdGVtIGhhcyB0aGUgdHlwZSBgcHRyZGlmZl90Jy4gKi8KKyN1bmRlZiBI
QVZFX1BUUkRJRkZfVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3VyIHN5c3RlbSBoYXMgYSBHTlUg
bGliYyBjb21wYXRpYmxlIGByZWFsbG9jJyBmdW5jdGlvbiwKKyAgIGFuZCB0byAwIG90aGVyd2lz
ZS4gKi8KKyN1bmRlZiBIQVZFX1JFQUxMT0MKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGByZWFscGF0aCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9SRUFMUEFUSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJlZ2NvbXAnIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfUkVHQ09NUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJtZGlyJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1JNRElSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc2VsZWN0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NFTEVDVAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHNldGVudicgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9TRVRFTlYKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzb2NrZXQnIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU09DS0VUCisKKy8qIERlZmluZSB0byAxIGlmIHN0ZGJv
b2wuaCBjb25mb3JtcyB0byBDOTkuICovCisjdW5kZWYgSEFWRV9TVERCT09MX0gKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdGRkZWYuaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9TVERERUZfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGlu
dC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURElOVF9ICisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkbGliLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhB
VkVfU1RETElCX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJjYXNlY21w
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUkNBU0VDTVAKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIGBzdHJjaHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ0hS
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyY3NwbicgZnVuY3Rpb24uICov
CisjdW5kZWYgSEFWRV9TVFJDU1BOCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBg
c3RyZHVwJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUkRVUAorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmVycm9yJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NU
UkVSUk9SCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5ncy5oPiBoZWFk
ZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NUUklOR1NfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPHN0cmluZy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NUUklO
R19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RybmR1cCcgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9TVFJORFVQCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgc3RycGJyaycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJQQlJLCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RycmNocicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFW
RV9TVFJSQ0hSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3Ryc3BuJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlNQTgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHN0cnN0cicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJTVFIKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJ0b2wnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfU1RSVE9MCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RydG91bCcgZnVu
Y3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJUT1VMCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc3RydG91bGwnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSVE9VTEwKKwor
LyogRGVmaW5lIHRvIDEgaWYgYHN0X2Jsa3NpemUnIGlzIGEgbWVtYmVyIG9mIGBzdHJ1Y3Qgc3Rh
dCcuICovCisjdW5kZWYgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFCisKKy8qIERlZmluZSB0
byAxIGlmIGBzdF9ibG9ja3MnIGlzIGEgbWVtYmVyIG9mIGBzdHJ1Y3Qgc3RhdCcuICovCisjdW5k
ZWYgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MKKworLyogRGVmaW5lIHRvIDEgaWYgYHN0X3Jk
ZXYnIGlzIGEgbWVtYmVyIG9mIGBzdHJ1Y3Qgc3RhdCcuICovCisjdW5kZWYgSEFWRV9TVFJVQ1Rf
U1RBVF9TVF9SREVWCisKKy8qIERlZmluZSB0byAxIGlmIHlvdXIgYHN0cnVjdCBzdGF0JyBoYXMg
YHN0X2Jsb2NrcycuIERlcHJlY2F0ZWQsIHVzZQorICAgYEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxP
Q0tTJyBpbnN0ZWFkLiAqLworI3VuZGVmIEhBVkVfU1RfQkxPQ0tTCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8c3lzbG9nLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1lTTE9HX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvZmlsZS5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19GSUxFX0gKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxzeXMvaW9jdGwuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFW
RV9TWVNfSU9DVExfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9tb3Vu
dC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19NT1VOVF9ICisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3BhcmFtLmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfU1lTX1BBUkFNX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxz
eXMvc29ja2V0Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1NPQ0tFVF9ICisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3N0YXR2ZnMuaD4gaGVhZGVyIGZp
bGUuICovCisjdW5kZWYgSEFWRV9TWVNfU1RBVFZGU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSA8c3lzL3N0YXQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNf
U1RBVF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3RpbWUuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfVElNRV9ICisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSA8c3lzL3R5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1lTX1RZUEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx0ZXJtaW9zLmg+
IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfVEVSTUlPU19ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgdHpzZXQnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVFpTRVQK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB1bmFtZScgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9VTkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHVuaXN0
ZC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1VOSVNURF9ICisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSBgdmZvcmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVkZP
UksKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx2Zm9yay5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1ZGT1JLX0gKKworLyogRGVmaW5lIHRvIDEgaWYgYGZvcmsnIHdv
cmtzLiAqLworI3VuZGVmIEhBVkVfV09SS0lOR19GT1JLCisKKy8qIERlZmluZSB0byAxIGlmIGB2
Zm9yaycgd29ya3MuICovCisjdW5kZWYgSEFWRV9XT1JLSU5HX1ZGT1JLCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4gaGVhZGVyIGZpbGUuICov
CisjdW5kZWYgSEFWRV9ZQUpMX1lBSkxfVkVSU0lPTl9ICisKKy8qIERlZmluZSB0byAxIGlmIHRo
ZSBzeXN0ZW0gaGFzIHRoZSB0eXBlIGBfQm9vbCcuICovCisjdW5kZWYgSEFWRV9fQk9PTAorCisv
KiBEZWZpbmUgdG8gMSBpZiBgbHN0YXQnIGRlcmVmZXJlbmNlcyBhIHN5bWxpbmsgc3BlY2lmaWVk
IHdpdGggYSB0cmFpbGluZworICAgc2xhc2guICovCisjdW5kZWYgTFNUQVRfRk9MTE9XU19TTEFT
SEVEX1NZTUxJTksKKworLyogRGVmaW5lIHRvIDEgaWYgYG1ham9yJywgYG1pbm9yJywgYW5kIGBt
YWtlZGV2JyBhcmUgZGVjbGFyZWQgaW4gPG1rZGV2Lmg+LgorICAgKi8KKyN1bmRlZiBNQUpPUl9J
Tl9NS0RFVgorCisvKiBEZWZpbmUgdG8gMSBpZiBgbWFqb3InLCBgbWlub3InLCBhbmQgYG1ha2Vk
ZXYnIGFyZSBkZWNsYXJlZCBpbgorICAgPHN5c21hY3Jvcy5oPi4gKi8KKyN1bmRlZiBNQUpPUl9J
Tl9TWVNNQUNST1MKKworLyogRGVmaW5lIHRvIHRoZSBhZGRyZXNzIHdoZXJlIGJ1ZyByZXBvcnRz
IGZvciB0aGlzIHBhY2thZ2Ugc2hvdWxkIGJlIHNlbnQuICovCisjdW5kZWYgUEFDS0FHRV9CVUdS
RVBPUlQKKworLyogRGVmaW5lIHRvIHRoZSBmdWxsIG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLwor
I3VuZGVmIFBBQ0tBR0VfTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFtZSBhbmQgdmVy
c2lvbiBvZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9TVFJJTkcKKworLyogRGVm
aW5lIHRvIHRoZSBvbmUgc3ltYm9sIHNob3J0IG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLworI3Vu
ZGVmIFBBQ0tBR0VfVEFSTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGhvbWUgcGFnZSBmb3IgdGhp
cyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfVVJMCisKKy8qIERlZmluZSB0byB0aGUgdmVy
c2lvbiBvZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9WRVJTSU9OCisKKy8qIElm
IHVzaW5nIHRoZSBDIGltcGxlbWVudGF0aW9uIG9mIGFsbG9jYSwgZGVmaW5lIGlmIHlvdSBrbm93
IHRoZQorICAgZGlyZWN0aW9uIG9mIHN0YWNrIGdyb3d0aCBmb3IgeW91ciBzeXN0ZW07IG90aGVy
d2lzZSBpdCB3aWxsIGJlCisgICBhdXRvbWF0aWNhbGx5IGRlZHVjZWQgYXQgcnVudGltZS4KKwlT
VEFDS19ESVJFQ1RJT04gPiAwID0+IGdyb3dzIHRvd2FyZCBoaWdoZXIgYWRkcmVzc2VzCisJU1RB
Q0tfRElSRUNUSU9OIDwgMCA9PiBncm93cyB0b3dhcmQgbG93ZXIgYWRkcmVzc2VzCisJU1RBQ0tf
RElSRUNUSU9OID0gMCA9PiBkaXJlY3Rpb24gb2YgZ3Jvd3RoIHVua25vd24gKi8KKyN1bmRlZiBT
VEFDS19ESVJFQ1RJT04KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIEFOU0kgQyBo
ZWFkZXIgZmlsZXMuICovCisjdW5kZWYgU1REQ19IRUFERVJTCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBjYW4gc2FmZWx5IGluY2x1ZGUgYm90aCA8c3lzL3RpbWUuaD4gYW5kIDx0aW1lLmg+LiAq
LworI3VuZGVmIFRJTUVfV0lUSF9TWVNfVElNRQorCisvKiBFbmFibGUgZXh0ZW5zaW9ucyBvbiBB
SVggMywgSW50ZXJpeC4gICovCisjaWZuZGVmIF9BTExfU09VUkNFCisjIHVuZGVmIF9BTExfU09V
UkNFCisjZW5kaWYKKy8qIEVuYWJsZSBHTlUgZXh0ZW5zaW9ucyBvbiBzeXN0ZW1zIHRoYXQgaGF2
ZSB0aGVtLiAgKi8KKyNpZm5kZWYgX0dOVV9TT1VSQ0UKKyMgdW5kZWYgX0dOVV9TT1VSQ0UKKyNl
bmRpZgorLyogRW5hYmxlIHRocmVhZGluZyBleHRlbnNpb25zIG9uIFNvbGFyaXMuICAqLworI2lm
bmRlZiBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MKKyMgdW5kZWYgX1BPU0lYX1BUSFJFQURfU0VN
QU5USUNTCisjZW5kaWYKKy8qIEVuYWJsZSBleHRlbnNpb25zIG9uIEhQIE5vblN0b3AuICAqLwor
I2lmbmRlZiBfVEFOREVNX1NPVVJDRQorIyB1bmRlZiBfVEFOREVNX1NPVVJDRQorI2VuZGlmCisv
KiBFbmFibGUgZ2VuZXJhbCBleHRlbnNpb25zIG9uIFNvbGFyaXMuICAqLworI2lmbmRlZiBfX0VY
VEVOU0lPTlNfXworIyB1bmRlZiBfX0VYVEVOU0lPTlNfXworI2VuZGlmCisKKworLyogRGVmaW5l
IHRvIDEgdG8gbWFrZSBmc2Vla28gdmlzaWJsZSBvbiBzb21lIGhvc3RzIChlLmcuIGdsaWJjIDIu
MikuICovCisjdW5kZWYgX0xBUkdFRklMRV9TT1VSQ0UKKworLyogRGVmaW5lIHRvIDEgaWYgb24g
TUlOSVguICovCisjdW5kZWYgX01JTklYCisKKy8qIERlZmluZSB0byAyIGlmIHRoZSBzeXN0ZW0g
ZG9lcyBub3QgcHJvdmlkZSBQT1NJWC4xIGZlYXR1cmVzIGV4Y2VwdCB3aXRoCisgICB0aGlzIGRl
ZmluZWQuICovCisjdW5kZWYgX1BPU0lYXzFfU09VUkNFCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBuZWVkIHRvIGluIG9yZGVyIGZvciBgc3RhdCcgYW5kIG90aGVyIHRoaW5ncyB0byB3b3JrLiAq
LworI3VuZGVmIF9QT1NJWF9TT1VSQ0UKKworLyogRGVmaW5lIGZvciBTb2xhcmlzIDIuNS4xIHNv
IHRoZSB1aW50MzJfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+
LCBvciA8c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93
ZWQsIHRoZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8K
KyN1bmRlZiBfVUlOVDMyX1QKKworLyogRGVmaW5lIGZvciBTb2xhcmlzIDIuNS4xIHNvIHRoZSB1
aW50NjRfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+LCBvciA8
c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93ZWQsIHRo
ZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8KKyN1bmRl
ZiBfVUlOVDY0X1QKKworLyogRGVmaW5lIGZvciBTb2xhcmlzIDIuNS4xIHNvIHRoZSB1aW50OF90
IHR5cGVkZWYgZnJvbSA8c3lzL3N5bmNoLmg+LAorICAgPHB0aHJlYWQuaD4sIG9yIDxzZW1hcGhv
cmUuaD4gaXMgbm90IHVzZWQuIElmIHRoZSB0eXBlZGVmIHdlcmUgYWxsb3dlZCwgdGhlCisgICAj
ZGVmaW5lIGJlbG93IHdvdWxkIGNhdXNlIGEgc3ludGF4IGVycm9yLiAqLworI3VuZGVmIF9VSU5U
OF9UCisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5l
LiAqLworI3VuZGVmIGdpZF90CisKKy8qIERlZmluZSB0byBgX19pbmxpbmVfXycgb3IgYF9faW5s
aW5lJyBpZiB0aGF0J3Mgd2hhdCB0aGUgQyBjb21waWxlcgorICAgY2FsbHMgaXQsIG9yIHRvIG5v
dGhpbmcgaWYgJ2lubGluZScgaXMgbm90IHN1cHBvcnRlZCB1bmRlciBhbnkgbmFtZS4gICovCisj
aWZuZGVmIF9fY3BsdXNwbHVzCisjdW5kZWYgaW5saW5lCisjZW5kaWYKKworLyogRGVmaW5lIHRv
IHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDE2IGJp
dHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRv
IG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MTZfdAorCisvKiBEZWZpbmUgdG8gdGhlIHR5
cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkgMzIgYml0cyBpZgor
ICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRl
ZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQzMl90CisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBh
IHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA2NCBiaXRzIGlmCisgICBzdWNo
IGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0
LiAqLworI3VuZGVmIGludDY0X3QKKworLyogRGVmaW5lIHRvIHRoZSB0eXBlIG9mIGEgc2lnbmVk
IGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDggYml0cyBpZiBzdWNoCisgICBhIHR5cGUg
ZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRlZmluZSBpdC4gKi8KKyN1
bmRlZiBpbnQ4X3QKKworLyogRGVmaW5lIHRvIHJwbF9tYWxsb2MgaWYgdGhlIHJlcGxhY2VtZW50
IGZ1bmN0aW9uIHNob3VsZCBiZSB1c2VkLiAqLworI3VuZGVmIG1hbGxvYworCisvKiBEZWZpbmUg
dG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgbW9k
ZV90CisKKy8qIERlZmluZSB0byBgbG9uZyBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3Qg
ZGVmaW5lLiAqLworI3VuZGVmIG9mZl90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5
cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBwaWRfdAorCisvKiBEZWZpbmUgdG8g
cnBsX3JlYWxsb2MgaWYgdGhlIHJlcGxhY2VtZW50IGZ1bmN0aW9uIHNob3VsZCBiZSB1c2VkLiAq
LworI3VuZGVmIHJlYWxsb2MKKworLyogRGVmaW5lIHRvIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBD
OTkgJ3Jlc3RyaWN0JyBrZXl3b3JkLCBvciB0bworICAgbm90aGluZyBpZiB0aGlzIGlzIG5vdCBz
dXBwb3J0ZWQuICBEbyBub3QgZGVmaW5lIGlmIHJlc3RyaWN0IGlzCisgICBzdXBwb3J0ZWQgZGly
ZWN0bHkuICAqLworI3VuZGVmIHJlc3RyaWN0CisvKiBXb3JrIGFyb3VuZCBhIGJ1ZyBpbiBTdW4g
QysrOiBpdCBkb2VzIG5vdCBzdXBwb3J0IF9SZXN0cmljdCBvcgorICAgX19yZXN0cmljdF9fLCBl
dmVuIHRob3VnaCB0aGUgY29ycmVzcG9uZGluZyBTdW4gQyBjb21waWxlciBlbmRzIHVwIHdpdGgK
KyAgICIjZGVmaW5lIHJlc3RyaWN0IF9SZXN0cmljdCIgb3IgIiNkZWZpbmUgcmVzdHJpY3QgX19y
ZXN0cmljdF9fIiBpbiB0aGUKKyAgIHByZXZpb3VzIGxpbmUuICBQZXJoYXBzIHNvbWUgZnV0dXJl
IHZlcnNpb24gb2YgU3VuIEMrKyB3aWxsIHdvcmsgd2l0aAorICAgcmVzdHJpY3Q7IGlmIHNvLCBo
b3BlZnVsbHkgaXQgZGVmaW5lcyBfX1JFU1RSSUNUIGxpa2UgU3VuIEMgZG9lcy4gICovCisjaWYg
ZGVmaW5lZCBfX1NVTlBST19DQyAmJiAhZGVmaW5lZCBfX1JFU1RSSUNUCisjIGRlZmluZSBfUmVz
dHJpY3QKKyMgZGVmaW5lIF9fcmVzdHJpY3RfXworI2VuZGlmCisKKy8qIERlZmluZSB0byBgdW5z
aWduZWQgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBz
aXplX3QKKworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVm
aW5lLiAqLworI3VuZGVmIHNzaXplX3QKKworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlw
ZXMuaD4gZG9lc24ndCBkZWZpbmUuICovCisjdW5kZWYgdWlkX3QKKworLyogRGVmaW5lIHRvIHRo
ZSB0eXBlIG9mIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDE2IGJp
dHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRv
IG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDE2X3QKKworLyogRGVmaW5lIHRvIHRoZSB0
eXBlIG9mIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDMyIGJpdHMg
aWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5v
dCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDMyX3QKKworLyogRGVmaW5lIHRvIHRoZSB0eXBl
IG9mIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDY0IGJpdHMgaWYK
KyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5vdCBk
ZWZpbmUgaXQuICovCisjdW5kZWYgdWludDY0X3QKKworLyogRGVmaW5lIHRvIHRoZSB0eXBlIG9m
IGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDggYml0cyBpZgorICAg
c3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRlZmlu
ZSBpdC4gKi8KKyN1bmRlZiB1aW50OF90CisKKy8qIERlZmluZSBhcyBgZm9yaycgaWYgYHZmb3Jr
JyBkb2VzIG5vdCB3b3JrLiAqLworI3VuZGVmIHZmb3JrCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1y
IDZmZGUwMTdjNDE5ZSB0b29scy9jb25maWcuc3ViCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5zdWIJVHVlIEphbiAxMCAxOTox
MzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTcxNCBAQAorIyEgL2Jpbi9zaAorIyBDb25maWd1
cmF0aW9uIHZhbGlkYXRpb24gc3Vicm91dGluZSBzY3JpcHQuCisjICAgQ29weXJpZ2h0IChDKSAx
OTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LAorIyAgIDIwMDAs
IDIwMDEsIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDksIDIw
MTAKKyMgICBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKwordGltZXN0YW1wPScyMDEw
LTAxLTIyJworCisjIFRoaXMgZmlsZSBpcyAoaW4gcHJpbmNpcGxlKSBjb21tb24gdG8gQUxMIEdO
VSBzb2Z0d2FyZS4KKyMgVGhlIHByZXNlbmNlIG9mIGEgbWFjaGluZSBpbiB0aGlzIGZpbGUgc3Vn
Z2VzdHMgdGhhdCBTT01FIEdOVSBzb2Z0d2FyZQorIyBjYW4gaGFuZGxlIHRoYXQgbWFjaGluZS4g
IEl0IGRvZXMgbm90IGltcGx5IEFMTCBHTlUgc29mdHdhcmUgY2FuLgorIworIyBUaGlzIGZpbGUg
aXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQor
IyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFz
IHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVy
c2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2
ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh
dCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyMgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0
IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5F
U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorIyBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2
ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorIyBhbG9uZyB3aXRo
IHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorIyBGb3Vu
ZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQgLSBGaWZ0aCBGbG9vciwgQm9zdG9uLCBN
QQorIyAwMjExMC0xMzAxLCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZp
bGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24g
c2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisj
IHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9m
IHRoYXQgcHJvZ3JhbS4KKworCisjIFBsZWFzZSBzZW5kIHBhdGNoZXMgdG8gPGNvbmZpZy1wYXRj
aGVzQGdudS5vcmc+LiAgU3VibWl0IGEgY29udGV4dAorIyBkaWZmIGFuZCBhIHByb3Blcmx5IGZv
cm1hdHRlZCBHTlUgQ2hhbmdlTG9nIGVudHJ5LgorIworIyBDb25maWd1cmF0aW9uIHN1YnJvdXRp
bmUgdG8gdmFsaWRhdGUgYW5kIGNhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gdHlwZS4KKyMg
U3VwcGx5IHRoZSBzcGVjaWZpZWQgY29uZmlndXJhdGlvbiB0eXBlIGFzIGFuIGFyZ3VtZW50Lgor
IyBJZiBpdCBpcyBpbnZhbGlkLCB3ZSBwcmludCBhbiBlcnJvciBtZXNzYWdlIG9uIHN0ZGVyciBh
bmQgZXhpdCB3aXRoIGNvZGUgMS4KKyMgT3RoZXJ3aXNlLCB3ZSBwcmludCB0aGUgY2Fub25pY2Fs
IGNvbmZpZyB0eXBlIG9uIHN0ZG91dCBhbmQgc3VjY2VlZC4KKworIyBZb3UgY2FuIGdldCB0aGUg
bGF0ZXN0IHZlcnNpb24gb2YgdGhpcyBzY3JpcHQgZnJvbToKKyMgaHR0cDovL2dpdC5zYXZhbm5h
aC5nbnUub3JnL2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZpZy5zdWI7
aGI9SEVBRAorCisjIFRoaXMgZmlsZSBpcyBzdXBwb3NlZCB0byBiZSB0aGUgc2FtZSBmb3IgYWxs
IEdOVSBwYWNrYWdlcworIyBhbmQgcmVjb2duaXplIGFsbCB0aGUgQ1BVIHR5cGVzLCBzeXN0ZW0g
dHlwZXMgYW5kIGFsaWFzZXMKKyMgdGhhdCBhcmUgbWVhbmluZ2Z1bCB3aXRoICphbnkqIEdOVSBz
b2Z0d2FyZS4KKyMgRWFjaCBwYWNrYWdlIGlzIHJlc3BvbnNpYmxlIGZvciByZXBvcnRpbmcgd2hp
Y2ggdmFsaWQgY29uZmlndXJhdGlvbnMKKyMgaXQgZG9lcyBub3Qgc3VwcG9ydC4gIFRoZSB1c2Vy
IHNob3VsZCBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoCisjIGEgZmFpbHVyZSB0byBzdXBwb3J0IGEg
dmFsaWQgY29uZmlndXJhdGlvbiBmcm9tIGEgbWVhbmluZ2xlc3MKKyMgY29uZmlndXJhdGlvbi4K
KworIyBUaGUgZ29hbCBvZiB0aGlzIGZpbGUgaXMgdG8gbWFwIGFsbCB0aGUgdmFyaW91cyB2YXJp
YXRpb25zIG9mIGEgZ2l2ZW4KKyMgbWFjaGluZSBzcGVjaWZpY2F0aW9uIGludG8gYSBzaW5nbGUg
c3BlY2lmaWNhdGlvbiBpbiB0aGUgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLU9QRVJB
VElOR19TWVNURU0KKyMgb3IgaW4gc29tZSBjYXNlcywgdGhlIG5ld2VyIGZvdXItcGFydCBmb3Jt
OgorIwlDUFVfVFlQRS1NQU5VRkFDVFVSRVItS0VSTkVMLU9QRVJBVElOR19TWVNURU0KKyMgSXQg
aXMgd3JvbmcgdG8gZWNobyBhbnkgb3RoZXIgdHlwZSBvZiBzcGVjaWZpY2F0aW9uLgorCittZT1g
ZWNobyAiJDAiIHwgc2VkIC1lICdzLC4qLywsJ2AKKwordXNhZ2U9IlwKK1VzYWdlOiAkMCBbT1BU
SU9OXSBDUFUtTUZSLU9QU1lTCisgICAgICAgJDAgW09QVElPTl0gQUxJQVMKKworQ2Fub25pY2Fs
aXplIGEgY29uZmlndXJhdGlvbiBuYW1lLgorCitPcGVyYXRpb24gbW9kZXM6CisgIC1oLCAtLWhl
bHAgICAgICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtdCwgLS10aW1lLXN0YW1w
ICAgcHJpbnQgZGF0ZSBvZiBsYXN0IG1vZGlmaWNhdGlvbiwgdGhlbiBleGl0CisgIC12LCAtLXZl
cnNpb24gICAgICBwcmludCB2ZXJzaW9uIG51bWJlciwgdGhlbiBleGl0CisKK1JlcG9ydCBidWdz
IGFuZCBwYXRjaGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4iCisKK3ZlcnNpb249IlwK
K0dOVSBjb25maWcuc3ViICgkdGltZXN0YW1wKQorCitDb3B5cmlnaHQgKEMpIDE5OTIsIDE5OTMs
IDE5OTQsIDE5OTUsIDE5OTYsIDE5OTcsIDE5OTgsIDE5OTksIDIwMDAsCisyMDAxLCAyMDAyLCAy
MDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEwIEZyZWUKK1NvZnR3
YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBzZWUgdGhlIHNv
dXJjZSBmb3IgY29weWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8KK3dhcnJhbnR5OyBub3Qg
ZXZlbiBmb3IgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiIKKworaGVscD0iCitUcnkgXGAkbWUgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4i
CisKKyMgUGFyc2UgY29tbWFuZCBsaW5lCit3aGlsZSB0ZXN0ICQjIC1ndCAwIDsgZG8KKyAgY2Fz
ZSAkMSBpbgorICAgIC0tdGltZS1zdGFtcCB8IC0tdGltZSogfCAtdCApCisgICAgICAgZWNobyAi
JHRpbWVzdGFtcCIgOyBleGl0IDs7CisgICAgLS12ZXJzaW9uIHwgLXYgKQorICAgICAgIGVjaG8g
IiR2ZXJzaW9uIiA7IGV4aXQgOzsKKyAgICAtLWhlbHAgfCAtLWgqIHwgLWggKQorICAgICAgIGVj
aG8gIiR1c2FnZSI7IGV4aXQgOzsKKyAgICAtLSApICAgICAjIFN0b3Agb3B0aW9uIHByb2Nlc3Np
bmcKKyAgICAgICBzaGlmdDsgYnJlYWsgOzsKKyAgICAtICkJIyBVc2Ugc3RkaW4gYXMgaW5wdXQu
CisgICAgICAgYnJlYWsgOzsKKyAgICAtKiApCisgICAgICAgZWNobyAiJG1lOiBpbnZhbGlkIG9w
dGlvbiAkMSRoZWxwIgorICAgICAgIGV4aXQgMSA7OworCisgICAgKmxvY2FsKikKKyAgICAgICAj
IEZpcnN0IHBhc3MgdGhyb3VnaCBhbnkgbG9jYWwgbWFjaGluZSB0eXBlcy4KKyAgICAgICBlY2hv
ICQxCisgICAgICAgZXhpdCA7OworCisgICAgKiApCisgICAgICAgYnJlYWsgOzsKKyAgZXNhYwor
ZG9uZQorCitjYXNlICQjIGluCisgMCkgZWNobyAiJG1lOiBtaXNzaW5nIGFyZ3VtZW50JGhlbHAi
ID4mMgorICAgIGV4aXQgMTs7CisgMSkgOzsKKyAqKSBlY2hvICIkbWU6IHRvbyBtYW55IGFyZ3Vt
ZW50cyRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworZXNhYworCisjIFNlcGFyYXRlIHdoYXQgdGhl
IHVzZXIgZ2F2ZSBpbnRvIENQVS1DT01QQU5ZIGFuZCBPUyBvciBLRVJORUwtT1MgKGlmIGFueSku
CisjIEhlcmUgd2UgbXVzdCByZWNvZ25pemUgYWxsIHRoZSB2YWxpZCBLRVJORUwtT1MgY29tYmlu
YXRpb25zLgorbWF5YmVfb3M9YGVjaG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0q
XCkkL1wyLydgCitjYXNlICRtYXliZV9vcyBpbgorICBudG8tcW54KiB8IGxpbnV4LWdudSogfCBs
aW51eC1kaWV0bGliYyB8IGxpbnV4LW5ld2xpYiogfCBsaW51eC11Y2xpYmMqIHwgXAorICB1Y2xp
bnV4LXVjbGliYyogfCB1Y2xpbnV4LWdudSogfCBrZnJlZWJzZCotZ251KiB8IGtuZXRic2QqLWdu
dSogfCBuZXRic2QqLWdudSogfCBcCisgIGtvcGVuc29sYXJpcyotZ251KiB8IFwKKyAgc3Rvcm0t
Y2hhb3MqIHwgb3MyLWVteCogfCBydG1rLW5vdmEqKQorICAgIG9zPS0kbWF5YmVfb3MKKyAgICBi
YXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzL15cKC4qXCktXChbXi1dKi1bXi1dKlwpJC9c
MS8nYAorICAgIDs7CisgICopCisgICAgYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAncy8t
W14tXSokLy8nYAorICAgIGlmIFsgJGJhc2ljX21hY2hpbmUgIT0gJDEgXQorICAgIHRoZW4gb3M9
YGVjaG8gJDEgfCBzZWQgJ3MvLiotLy0vJ2AKKyAgICBlbHNlIG9zPTsgZmkKKyAgICA7OworZXNh
YworCisjIyMgTGV0J3MgcmVjb2duaXplIGNvbW1vbiBtYWNoaW5lcyBhcyBub3QgYmVpbmcgb3Bl
cmF0aW5nIHN5c3RlbXMgc28KKyMjIyB0aGF0IHRoaW5ncyBsaWtlIGNvbmZpZy5zdWIgZGVjc3Rh
dGlvbi0zMTAwIHdvcmsuICBXZSBhbHNvCisjIyMgcmVjb2duaXplIHNvbWUgbWFudWZhY3R1cmVy
cyBhcyBub3QgYmVpbmcgb3BlcmF0aW5nIHN5c3RlbXMsIHNvIHdlCisjIyMgY2FuIHByb3ZpZGUg
ZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVtcyBiZWxvdy4KK2Nhc2UgJG9zIGluCisJLXN1bipvcyop
CisJCSMgUHJldmVudCBmb2xsb3dpbmcgY2xhdXNlIGZyb20gaGFuZGxpbmcgdGhpcyBpbnZhbGlk
IGlucHV0LgorCQk7OworCS1kZWMqIHwgLW1pcHMqIHwgLXNlcXVlbnQqIHwgLWVuY29yZSogfCAt
cGM1MzIqIHwgLXNnaSogfCAtc29ueSogfCBcCisJLWF0dCogfCAtNzMwMCogfCAtMzMwMCogfCAt
ZGVsdGEqIHwgLW1vdG9yb2xhKiB8IC1zdW5bMjM0XSogfCBcCisJLXVuaWNvbSogfCAtaWJtKiB8
IC1uZXh0IHwgLWhwIHwgLWlzaSogfCAtYXBvbGxvIHwgLWFsdG9zKiB8IFwKKwktY29udmVyZ2Vu
dCogfCAtbmNyKiB8IC1uZXdzIHwgLTMyKiB8IC0zNjAwKiB8IC0zMTAwKiB8IC1oaXRhY2hpKiB8
XAorCS1jWzEyM10qIHwgLWNvbnZleCogfCAtc3VuIHwgLWNyZHMgfCAtb21yb24qIHwgLWRnIHwg
LXVsdHJhIHwgLXR0aSogfCBcCisJLWhhcnJpcyB8IC1kb2xwaGluIHwgLWhpZ2hsZXZlbCB8IC1n
b3VsZCB8IC1jYm0gfCAtbnMgfCAtbWFzc2NvbXAgfCBcCisJLWFwcGxlIHwgLWF4aXMgfCAta251
dGggfCAtY3JheSB8IC1taWNyb2JsYXplKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7
OworICAgICAgICAtYmx1ZWdlbmUqKQorCSAgICAgICAgb3M9LWNuaworCQk7OworCS1zaW0gfCAt
Y2lzY28gfCAtb2tpIHwgLXdlYyB8IC13aW5ib25kKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0k
MQorCQk7OworCS1zY291dCkKKwkJOzsKKwktd3JzKQorCQlvcz0tdnh3b3JrcworCQliYXNpY19t
YWNoaW5lPSQxCisJCTs7CisJLWNob3J1c29zKikKKwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21h
Y2hpbmU9JDEKKwkJOzsKKyAJLWNob3J1c3JkYikKKyAJCW9zPS1jaG9ydXNyZGIKKwkJYmFzaWNf
bWFjaGluZT0kMQorIAkJOzsKKwktaGl1eCopCisJCW9zPS1oaXV4d2UyCisJCTs7CisJLXNjbzYp
CisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0u
Ki84Ni1wYy8nYAorCQk7OworCS1zY281KQorCQlvcz0tc2NvMy4ydjUKKwkJYmFzaWNfbWFjaGlu
ZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY280KQorCQlv
cz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84
Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQtOV0qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUg
J3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktc2NvMy4ydls0LTldKikKKwkJIyBEb24ndCBmb3Jn
ZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBvciBuZXdlci4KKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281djYqKQorCQkjIERv
bid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlzIDMuMnY0IG9yIG5ld2VyLgorCQliYXNpY19tYWNo
aW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXNjbyopCisJ
CW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4q
Lzg2LXBjLydgCisJCTs7CisJLXVkayopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQg
LWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktaXNjKQorCQlvcz0taXNjMi4yCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktY2xp
eCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBlci1pbnRlcmdyYXBoCisJCTs7CisJLWlzYyopCisJ
CWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsK
KwktbHlueCopCisJCW9zPS1seW54b3MKKwkJOzsKKwktcHR4KikKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1zZXF1ZW50LydgCisJCTs7CisJLXdpbmRvd3Nu
dCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAncy93aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsK
KwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7CisJLW1pbnQgfCAtbWludFswLTldKikKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9zPS1taW50CisJCTs7Citlc2FjCisKKyMgRGVjb2Rl
IGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNPTVBBTlkgY29tYmluYXRpb25zLgorY2FzZSAkYmFz
aWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aG91dCBj
b21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBvbWl0dGVkIGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUg
c3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkxNzUwYSB8IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFs
cGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFldjU2IHwgYWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1
WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2NGV2WzQtOF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhh
NjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjddIFwKKwl8IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFy
bSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBhcm12WzIzNDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2
ciB8IGF2cjMyIFwKKwl8IGJmaW4gXAorCXwgYzR4IHwgY2xpcHBlciBcCisJfCBkMTB2IHwgZDMw
diB8IGRseCB8IGRzcDE2eHggXAorCXwgZmlkbyB8IGZyMzAgfCBmcnYgXAorCXwgaDgzMDAgfCBo
ODUwMCB8IGhwcGEgfCBocHBhMS5bMDFdIHwgaHBwYTIuMCB8IGhwcGEyLjBbbnddIHwgaHBwYTY0
IFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlhNjQgXAorCXwgaXAyayB8IGlxMjAwMCBcCisJ
fCBsbTMyIFwKKwl8IG0zMmMgfCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsg
XAorCXwgbWF4cSB8IG1iIHwgbWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwg
bWlwcyB8IG1pcHNiZSB8IG1pcHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAor
CXwgbWlwczY0IHwgbWlwczY0ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwg
XAorCXwgbWlwczY0b3Jpb24gfCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlw
czY0cjU5MDBlbCBcCisJfCBtaXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAw
IHwgbWlwczY0dnI0MTAwZWwgXAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAor
CXwgbWlwczY0dnI1MDAwIHwgbWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlw
czY0dnI1OTAwZWwgXAorCXwgbWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMy
cjIgfCBtaXBzaXNhMzJyMmVsIFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1p
cHNpc2E2NHIyIHwgbWlwc2lzYTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRz
YjFlbCBcCisJfCBtaXBzaXNhNjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4
MzkgfCBtaXBzdHgzOWVsIFwKKwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8
IG10IFwKKwl8IG1zcDQzMCBcCisJfCBuaW9zIHwgbmlvczIgXAorCXwgbnMxNmsgfCBuczMyayBc
CisJfCBvcjMyIFwKKwl8IHBkcDEwIHwgcGRwMTEgfCBwaiB8IHBqbCBcCisJfCBwb3dlcnBjIHwg
cG93ZXJwYzY0IHwgcG93ZXJwYzY0bGUgfCBwb3dlcnBjbGUgfCBwcGNiZSBcCisJfCBweXJhbWlk
IFwKKwl8IHJ4IFwKKwl8IHNjb3JlIFwKKwl8IHNoIHwgc2hbMTIzNF0gfCBzaFsyNF1hIHwgc2hb
MjRdYWViIHwgc2hbMjNdZSB8IHNoWzM0XWViIHwgc2hlYiB8IHNoYmUgfCBzaGxlIHwgc2hbMTIz
NF1sZSB8IHNoM2VsZSBcCisJfCBzaDY0IHwgc2g2NGxlIFwKKwl8IHNwYXJjIHwgc3BhcmM2NCB8
IHNwYXJjNjRiIHwgc3BhcmM2NHYgfCBzcGFyYzg2eCB8IHNwYXJjbGV0IHwgc3BhcmNsaXRlIFwK
Kwl8IHNwYXJjdjggfCBzcGFyY3Y5IHwgc3BhcmN2OWIgfCBzcGFyY3Y5diBcCisJfCBzcHUgfCBz
dHJvbmdhcm0gXAorCXwgdGFob2UgfCB0aHVtYiB8IHRpYzR4IHwgdGljODAgfCB0cm9uIFwKKwl8
IHViaWNvbTMyIFwKKwl8IHY4NTAgfCB2ODUwZSBcCisJfCB3ZTMyayBcCisJfCB4ODYgfCB4YzE2
eCB8IHhzY2FsZSB8IHhzY2FsZWVbYmxdIHwgeHN0b3JteTE2IHwgeHRlbnNhIFwKKwl8IHo4ayB8
IHo4MCkKKwkJYmFzaWNfbWFjaGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJbTY4
MTEgfCBtNjhoYzExIHwgbTY4MTIgfCBtNjhoYzEyIHwgcGljb2NoaXApCisJCSMgTW90b3JvbGEg
NjhIQzExLzEyLgorCQliYXNpY19tYWNoaW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9
LW5vbmUKKwkJOzsKKwltODgxMTAgfCBtNjgwWzEyMzQ2XTAgfCBtNjgzPzIgfCBtNjgzNjAgfCBt
NTIwMCB8IHY3MCB8IHc2NSB8IHo4aykKKwkJOzsKKwltczEpCisJCWJhc2ljX21hY2hpbmU9bXQt
dW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhhbiBgdW5rbm93bicKKwkj
IGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJlLCBhbmQKKwkjICgyKSB0
aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5pbmcgdXNlcnMuCisJaSo4
NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtcGMKKwkgIDs7CisJ
IyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29yZC4KKwkqLSotKikKKwkJ
ZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5lIFxgJGJhc2ljX21hY2hp
bmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworCSMgUmVjb2duaXplIHRo
ZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgwLSogXAorCXwgYTI5ay0q
IFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1Ni0qIHwgYWxwaGFldjZb
NzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8IGFscGhhNjRldjU2LSog
fCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8IGFscGhhNjRwY2E1WzY3
XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxlLSogfCBhcm1lYi0qIHwg
YXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmZpbi0qIHwgYnMyMDAwLSogXAor
CXwgY1sxMjNdKiB8IGMzMC0qIHwgW2NqdF05MC0qIHwgYzR4LSogfCBjNTR4LSogfCBjNTV4LSog
fCBjNngtKiBcCisJfCBjbGlwcGVyLSogfCBjcmF5bnYtKiB8IGN5ZHJhLSogXAorCXwgZDEwdi0q
IHwgZDMwdi0qIHwgZGx4LSogXAorCXwgZWx4c2ktKiBcCisJfCBmMzBbMDFdLSogfCBmNzAwLSog
fCBmaWRvLSogfCBmcjMwLSogfCBmcnYtKiB8IGZ4ODAtKiBcCisJfCBoODMwMC0qIHwgaDg1MDAt
KiBcCisJfCBocHBhLSogfCBocHBhMS5bMDFdLSogfCBocHBhMi4wLSogfCBocHBhMi4wW253XS0q
IHwgaHBwYTY0LSogXAorCXwgaSo4Ni0qIHwgaTg2MC0qIHwgaTk2MC0qIHwgaWE2NC0qIFwKKwl8
IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxtMzItKiBcCisJfCBtMzJjLSogfCBtMzJyLSogfCBt
MzJybGUtKiBcCisJfCBtNjgwMDAtKiB8IG02ODBbMDEyMzQ2XTAtKiB8IG02ODM2MC0qIHwgbTY4
Mz8yLSogfCBtNjhrLSogXAorCXwgbTg4MTEwLSogfCBtODhrLSogfCBtYXhxLSogfCBtY29yZS0q
IHwgbWV0YWctKiB8IG1pY3JvYmxhemUtKiBcCisJfCBtaXBzLSogfCBtaXBzYmUtKiB8IG1pcHNl
Yi0qIHwgbWlwc2VsLSogfCBtaXBzbGUtKiBcCisJfCBtaXBzMTYtKiBcCisJfCBtaXBzNjQtKiB8
IG1pcHM2NGVsLSogXAorCXwgbWlwczY0b2N0ZW9uLSogfCBtaXBzNjRvY3Rlb25lbC0qIFwKKwl8
IG1pcHM2NG9yaW9uLSogfCBtaXBzNjRvcmlvbmVsLSogXAorCXwgbWlwczY0cjU5MDAtKiB8IG1p
cHM2NHI1OTAwZWwtKiBcCisJfCBtaXBzNjR2ci0qIHwgbWlwczY0dnJlbC0qIFwKKwl8IG1pcHM2
NHZyNDEwMC0qIHwgbWlwczY0dnI0MTAwZWwtKiBcCisJfCBtaXBzNjR2cjQzMDAtKiB8IG1pcHM2
NHZyNDMwMGVsLSogXAorCXwgbWlwczY0dnI1MDAwLSogfCBtaXBzNjR2cjUwMDBlbC0qIFwKKwl8
IG1pcHM2NHZyNTkwMC0qIHwgbWlwczY0dnI1OTAwZWwtKiBcCisJfCBtaXBzaXNhMzItKiB8IG1p
cHNpc2EzMmVsLSogXAorCXwgbWlwc2lzYTMycjItKiB8IG1pcHNpc2EzMnIyZWwtKiBcCisJfCBt
aXBzaXNhNjQtKiB8IG1pcHNpc2E2NGVsLSogXAorCXwgbWlwc2lzYTY0cjItKiB8IG1pcHNpc2E2
NHIyZWwtKiBcCisJfCBtaXBzaXNhNjRzYjEtKiB8IG1pcHNpc2E2NHNiMWVsLSogXAorCXwgbWlw
c2lzYTY0c3I3MWstKiB8IG1pcHNpc2E2NHNyNzFrZWwtKiBcCisJfCBtaXBzdHgzOS0qIHwgbWlw
c3R4MzllbC0qIFwKKwl8IG1taXgtKiBcCisJfCBtdC0qIFwKKwl8IG1zcDQzMC0qIFwKKwl8IG5p
b3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0qIHwgbnAxLSogfCBuczE2ay0qIHwgbnMzMmstKiBc
CisJfCBvcmlvbi0qIFwKKwl8IHBkcDEwLSogfCBwZHAxMS0qIHwgcGotKiB8IHBqbC0qIHwgcG4t
KiB8IHBvd2VyLSogXAorCXwgcG93ZXJwYy0qIHwgcG93ZXJwYzY0LSogfCBwb3dlcnBjNjRsZS0q
IHwgcG93ZXJwY2xlLSogfCBwcGNiZS0qIFwKKwl8IHB5cmFtaWQtKiBcCisJfCByb21wLSogfCBy
czYwMDAtKiB8IHJ4LSogXAorCXwgc2gtKiB8IHNoWzEyMzRdLSogfCBzaFsyNF1hLSogfCBzaFsy
NF1hZWItKiB8IHNoWzIzXWUtKiB8IHNoWzM0XWViLSogfCBzaGViLSogfCBzaGJlLSogXAorCXwg
c2hsZS0qIHwgc2hbMTIzNF1sZS0qIHwgc2gzZWxlLSogfCBzaDY0LSogfCBzaDY0bGUtKiBcCisJ
fCBzcGFyYy0qIHwgc3BhcmM2NC0qIHwgc3BhcmM2NGItKiB8IHNwYXJjNjR2LSogfCBzcGFyYzg2
eC0qIHwgc3BhcmNsZXQtKiBcCisJfCBzcGFyY2xpdGUtKiBcCisJfCBzcGFyY3Y4LSogfCBzcGFy
Y3Y5LSogfCBzcGFyY3Y5Yi0qIHwgc3BhcmN2OXYtKiB8IHN0cm9uZ2FybS0qIHwgc3YxLSogfCBz
eD8tKiBcCisJfCB0YWhvZS0qIHwgdGh1bWItKiBcCisJfCB0aWMzMC0qIHwgdGljNHgtKiB8IHRp
YzU0eC0qIHwgdGljNTV4LSogfCB0aWM2eC0qIHwgdGljODAtKiBcCisJfCB0aWxlLSogfCB0aWxl
Z3gtKiBcCisJfCB0cm9uLSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSogfCB2ODUwZS0q
IHwgdmF4LSogXAorCXwgd2UzMmstKiBcCisJfCB4ODYtKiB8IHg4Nl82NC0qIHwgeGMxNngtKiB8
IHhwczEwMC0qIHwgeHNjYWxlLSogfCB4c2NhbGVlW2JsXS0qIFwKKwl8IHhzdG9ybXkxNi0qIHwg
eHRlbnNhKi0qIFwKKwl8IHltcC0qIFwKKwl8IHo4ay0qIHwgejgwLSopCisJCTs7CisJIyBSZWNv
Z25pemUgdGhlIGJhc2ljIENQVSB0eXBlcyB3aXRob3V0IGNvbXBhbnkgbmFtZSwgd2l0aCBnbG9i
IG1hdGNoLgorCXh0ZW5zYSopCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93
bgorCQk7OworCSMgUmVjb2duaXplIHRoZSB2YXJpb3VzIG1hY2hpbmUgbmFtZXMgYW5kIGFsaWFz
ZXMgd2hpY2ggc3RhbmQKKwkjIGZvciBhIENQVSB0eXBlIGFuZCBhIGNvbXBhbnkgYW5kIHNvbWV0
aW1lcyBldmVuIGFuIE9TLgorCTM4NmJzZCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24K
KwkJb3M9LWJzZAorCQk7OworCTNiMSB8IDczMDAgfCA3MzAwLWF0dCB8IGF0dC03MzAwIHwgcGM3
MzAwIHwgc2FmYXJpIHwgdW5peHBjKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1hdHQKKwkJOzsK
KwkzYiopCisJCWJhc2ljX21hY2hpbmU9d2UzMmstYXR0CisJCTs7CisJYTI5a2hpZikKKwkJYmFz
aWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tdWRpCisJCTs7CisgICAgCWFiYWN1cykKKwkJYmFz
aWNfbWFjaGluZT1hYmFjdXMtdW5rbm93bgorCQk7OworCWFkb2JlNjhrKQorCQliYXNpY19tYWNo
aW5lPW02ODAxMC1hZG9iZQorCQlvcz0tc2NvdXQKKwkJOzsKKwlhbGxpYW50IHwgZng4MCkKKwkJ
YmFzaWNfbWFjaGluZT1meDgwLWFsbGlhbnQKKwkJOzsKKwlhbHRvcyB8IGFsdG9zMzA2OCkKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLWFsdG9zCisJCTs7CisJYW0yOWspCisJCWJhc2ljX21hY2hpbmU9
YTI5ay1ub25lCisJCW9zPS1ic2QKKwkJOzsKKwlhbWQ2NCkKKwkJYmFzaWNfbWFjaGluZT14ODZf
NjQtcGMKKwkJOzsKKwlhbWQ2NC0qKQorCQliYXNpY19tYWNoaW5lPXg4Nl82NC1gZWNobyAkYmFz
aWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWFtZGFobCkKKwkJYmFzaWNf
bWFjaGluZT01ODAtYW1kYWhsCisJCW9zPS1zeXN2CisJCTs7CisJYW1pZ2EgfCBhbWlnYS0qKQor
CQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93bgorCQk7OworCWFtaWdhb3MgfCBhbWlnYWRvcykK
KwkJYmFzaWNfbWFjaGluZT1tNjhrLXVua25vd24KKwkJb3M9LWFtaWdhb3MKKwkJOzsKKwlhbWln
YXVuaXggfCBhbWl4KQorCQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93bgorCQlvcz0tc3lzdjQK
KwkJOzsKKwlhcG9sbG82OCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWFwb2xsbworCQlvcz0tc3lz
dgorCQk7OworCWFwb2xsbzY4YnNkKQorCQliYXNpY19tYWNoaW5lPW02OGstYXBvbGxvCisJCW9z
PS1ic2QKKwkJOzsKKwlhcm9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWFyb3MK
KwkJOzsKKwlhdXgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQlvcz0tYXV4CisJCTs7
CisJYmFsYW5jZSkKKwkJYmFzaWNfbWFjaGluZT1uczMyay1zZXF1ZW50CisJCW9zPS1keW5peAor
CQk7OworCWJsYWNrZmluKQorCQliYXNpY19tYWNoaW5lPWJmaW4tdW5rbm93bgorCQlvcz0tbGlu
dXgKKwkJOzsKKwlibGFja2Zpbi0qKQorCQliYXNpY19tYWNoaW5lPWJmaW4tYGVjaG8gJGJhc2lj
X21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4CisJCTs7CisJYmx1ZWdl
bmUqKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGMtaWJtCisJCW9zPS1jbmsKKwkJOzsKKwljOTAp
CisJCWJhc2ljX21hY2hpbmU9YzkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworICAgICAgICBj
ZWdjYykKKwkJYmFzaWNfbWFjaGluZT1hcm0tdW5rbm93bgorCQlvcz0tY2VnY2MKKwkJOzsKKwlj
b252ZXgtYzEpCisJCWJhc2ljX21hY2hpbmU9YzEtY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwlj
b252ZXgtYzIpCisJCWJhc2ljX21hY2hpbmU9YzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwlj
b252ZXgtYzMyKQorCQliYXNpY19tYWNoaW5lPWMzMi1jb252ZXgKKwkJb3M9LWJzZAorCQk7Owor
CWNvbnZleC1jMzQpCisJCWJhc2ljX21hY2hpbmU9YzM0LWNvbnZleAorCQlvcz0tYnNkCisJCTs7
CisJY29udmV4LWMzOCkKKwkJYmFzaWNfbWFjaGluZT1jMzgtY29udmV4CisJCW9zPS1ic2QKKwkJ
OzsKKwljcmF5IHwgajkwKQorCQliYXNpY19tYWNoaW5lPWo5MC1jcmF5CisJCW9zPS11bmljb3MK
KwkJOzsKKwljcmF5bnYpCisJCWJhc2ljX21hY2hpbmU9Y3JheW52LWNyYXkKKwkJb3M9LXVuaWNv
c21wCisJCTs7CisJY3IxNikKKwkJYmFzaWNfbWFjaGluZT1jcjE2LXVua25vd24KKwkJb3M9LWVs
ZgorCQk7OworCWNyZHMgfCB1bm9zKQorCQliYXNpY19tYWNoaW5lPW02OGstY3JkcworCQk7Owor
CWNyaXN2MzIgfCBjcmlzdjMyLSogfCBldHJheGZzKikKKwkJYmFzaWNfbWFjaGluZT1jcmlzdjMy
LWF4aXMKKwkJOzsKKwljcmlzIHwgY3Jpcy0qIHwgZXRyYXgqKQorCQliYXNpY19tYWNoaW5lPWNy
aXMtYXhpcworCQk7OworCWNyeCkKKwkJYmFzaWNfbWFjaGluZT1jcngtdW5rbm93bgorCQlvcz0t
ZWxmCisJCTs7CisJZGEzMCB8IGRhMzAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWRhMzAKKwkJ
OzsKKwlkZWNzdGF0aW9uIHwgZGVjc3RhdGlvbi0zMTAwIHwgcG1heCB8IHBtYXgtKiB8IHBtaW4g
fCBkZWMzMTAwIHwgZGVjc3RhdG4pCisJCWJhc2ljX21hY2hpbmU9bWlwcy1kZWMKKwkJOzsKKwlk
ZWNzeXN0ZW0xMCogfCBkZWMxMCopCisJCWJhc2ljX21hY2hpbmU9cGRwMTAtZGVjCisJCW9zPS10
b3BzMTAKKwkJOzsKKwlkZWNzeXN0ZW0yMCogfCBkZWMyMCopCisJCWJhc2ljX21hY2hpbmU9cGRw
MTAtZGVjCisJCW9zPS10b3BzMjAKKwkJOzsKKwlkZWx0YSB8IDMzMDAgfCBtb3Rvcm9sYS0zMzAw
IHwgbW90b3JvbGEtZGVsdGEgXAorCSAgICAgIHwgMzMwMC1tb3Rvcm9sYSB8IGRlbHRhLW1vdG9y
b2xhKQorCQliYXNpY19tYWNoaW5lPW02OGstbW90b3JvbGEKKwkJOzsKKwlkZWx0YTg4KQorCQli
YXNpY19tYWNoaW5lPW04OGstbW90b3JvbGEKKwkJb3M9LXN5c3YzCisJCTs7CisJZGljb3MpCisJ
CWJhc2ljX21hY2hpbmU9aTY4Ni1wYworCQlvcz0tZGljb3MKKwkJOzsKKwlkamdwcCkKKwkJYmFz
aWNfbWFjaGluZT1pNTg2LXBjCisJCW9zPS1tc2Rvc2RqZ3BwCisJCTs7CisJZHB4MjAgfCBkcHgy
MC0qKQorCQliYXNpY19tYWNoaW5lPXJzNjAwMC1idWxsCisJCW9zPS1ib3N4CisJCTs7CisJZHB4
MiogfCBkcHgyKi1idWxsKQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlvcz0tc3lzdjMK
KwkJOzsKKwllYm1vbjI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tZWJtb24K
KwkJOzsKKwllbHhzaSkKKwkJYmFzaWNfbWFjaGluZT1lbHhzaS1lbHhzaQorCQlvcz0tYnNkCisJ
CTs7CisJZW5jb3JlIHwgdW1heCB8IG1tYXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstZW5jb3Jl
CisJCTs7CisJZXMxODAwIHwgT1NFNjhrIHwgb3NlNjhrIHwgb3NlIHwgT1NFKQorCQliYXNpY19t
YWNoaW5lPW02OGstZXJpY3Nzb24KKwkJb3M9LW9zZQorCQk7OworCWZ4MjgwMCkKKwkJYmFzaWNf
bWFjaGluZT1pODYwLWFsbGlhbnQKKwkJOzsKKwlnZW5peCkKKwkJYmFzaWNfbWFjaGluZT1uczMy
ay1ucworCQk7OworCWdtaWNybykKKwkJYmFzaWNfbWFjaGluZT10cm9uLWdtaWNybworCQlvcz0t
c3lzdgorCQk7OworCWdvMzIpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1wYworCQlvcz0tZ28zMgor
CQk7OworCWgzMDUwciogfCBoaXV4KikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhpdGFjaGkK
KwkJb3M9LWhpdXh3ZTIKKwkJOzsKKwloODMwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODMwMC1o
aXRhY2hpCisJCW9zPS1obXMKKwkJOzsKKwloODMwMHhyYXkpCisJCWJhc2ljX21hY2hpbmU9aDgz
MDAtaGl0YWNoaQorCQlvcz0teHJheQorCQk7OworCWg4NTAwaG1zKQorCQliYXNpY19tYWNoaW5l
PWg4NTAwLWhpdGFjaGkKKwkJb3M9LWhtcworCQk7OworCWhhcnJpcykKKwkJYmFzaWNfbWFjaGlu
ZT1tODhrLWhhcnJpcworCQlvcz0tc3lzdjMKKwkJOzsKKwlocDMwMC0qKQorCQliYXNpY19tYWNo
aW5lPW02OGstaHAKKwkJOzsKKwlocDMwMGJzZCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhwCisJ
CW9zPS1ic2QKKwkJOzsKKwlocDMwMGhwdXgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlv
cz0taHB1eAorCQk7OworCWhwM2s5WzAtOV1bMC05XSB8IGhwOVswLTldWzAtOV0pCisJCWJhc2lj
X21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwOWsyWzAtOV1bMC05XSB8IGhwOWszMVswLTld
KQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1ocAorCQk7OworCWhwOWszWzItOV1bMC05XSkKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLWhwCisJCTs7CisJaHA5azZbMC05XVswLTldIHwgaHA2WzAtOV1b
MC05XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHA5azdbMC03OV1bMC05
XSB8IGhwN1swLTc5XVswLTldKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaHAKKwkJOzsKKwlo
cDlrNzhbMC05XSB8IGhwNzhbMC05XSkKKwkJIyBGSVhNRTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJ
YmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azhbNjddMSB8IGhwOFs2N10xIHwg
aHA5azgwWzI0XSB8IGhwODBbMjRdIHwgaHA5azhbNzhdOSB8IGhwOFs3OF05IHwgaHA5azg5MyB8
IGhwODkzKQorCQkjIEZJWE1FOiByZWFsbHkgaHBwYTIuMC1ocAorCQliYXNpY19tYWNoaW5lPWhw
cGExLjEtaHAKKwkJOzsKKwlocDlrOFswLTldWzEzNjc5XSB8IGhwOFswLTldWzEzNjc5XSkKKwkJ
YmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azhbMC05XVswLTldIHwgaHA4WzAt
OV1bMC05XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHBwYS1uZXh0KQor
CQlvcz0tbmV4dHN0ZXAzCisJCTs7CisJaHBwYW9zZikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4x
LWhwCisJCW9zPS1vc2YKKwkJOzsKKwlocHBybykKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhw
CisJCW9zPS1wcm9lbGYKKwkJOzsKKwlpMzcwLWlibSogfCBpYm0qKQorCQliYXNpY19tYWNoaW5l
PWkzNzAtaWJtCisJCTs7CisjIEknbSBub3Qgc3VyZSB3aGF0ICJTeXN2MzIiIG1lYW5zLiAgU2hv
dWxkIHRoaXMgYmUgc3lzdjMuMj8KKwlpKjg2djMyKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICQx
IHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXN5c3YzMgorCQk7OworCWkqODZ2NCop
CisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlv
cz0tc3lzdjQKKwkJOzsKKwlpKjg2dikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAt
ZSAncy84Ni4qLzg2LXBjLydgCisJCW9zPS1zeXN2CisJCTs7CisJaSo4NnNvbDIpCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlvcz0tc29sYXJp
czIKKwkJOzsKKwlpMzg2bWFjaCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LW1hY2gKKwkJb3M9LW1h
Y2gKKwkJOzsKKwlpMzg2LXZzdGEgfCB2c3RhKQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93
bgorCQlvcz0tdnN0YQorCQk7OworCWlyaXMgfCBpcmlzNGQpCisJCWJhc2ljX21hY2hpbmU9bWlw
cy1zZ2kKKwkJY2FzZSAkb3MgaW4KKwkJICAgIC1pcml4KikKKwkJCTs7CisJCSAgICAqKQorCQkJ
b3M9LWlyaXg0CisJCQk7OworCQllc2FjCisJCTs7CisJaXNpNjggfCBpc2kpCisJCWJhc2ljX21h
Y2hpbmU9bTY4ay1pc2kKKwkJb3M9LXN5c3YKKwkJOzsKKwltNjhrbm9tbXUpCisJCWJhc2ljX21h
Y2hpbmU9bTY4ay11bmtub3duCisJCW9zPS1saW51eAorCQk7OworCW02OGtub21tdS0qKQorCQli
YXNpY19tYWNoaW5lPW02OGstYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJb3M9LWxpbnV4CisJCTs7CisJbTg4ay1vbXJvbiopCisJCWJhc2ljX21hY2hpbmU9bTg4
ay1vbXJvbgorCQk7OworCW1hZ251bSB8IG0zMjMwKQorCQliYXNpY19tYWNoaW5lPW1pcHMtbWlw
cworCQlvcz0tc3lzdgorCQk7OworCW1lcmxpbikKKwkJYmFzaWNfbWFjaGluZT1uczMyay11dGVr
CisJCW9zPS1zeXN2CisJCTs7CisgICAgICAgIG1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9
bWljcm9ibGF6ZS14aWxpbngKKwkJOzsKKwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYt
cGMKKwkJb3M9LW1pbmd3MzIKKwkJOzsKKwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJt
LXVua25vd24KKwkJb3M9LW1pbmd3MzJjZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFj
aGluZT1tNjgwMDAtY29udmVyZ2VudAorCQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlO
VCB8ICpNaU5UWzAtOV0qKQorCQliYXNpY19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQK
KwkJOzsKKwltaXBzMyotKikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8
IHNlZCAtZSAncy9taXBzMy9taXBzNjQvJ2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hp
bmU9YGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25v
d24KKwkJOzsKKwltb25pdG9yKQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1j
b2ZmCisJCTs7CisJbW9ycGhvcykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJ
b3M9LW1vcnBob3MKKwkJOzsKKwltc2RvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9z
PS1tc2RvcworCQk7OworCW1zMS0qKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNo
aW5lIHwgc2VkIC1lICdzL21zMS0vbXQtLydgCisJCTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5l
PWkzNzAtaWJtCisJCW9zPS1tdnMKKwkJOzsKKwluY3IzMDAwKQorCQliYXNpY19tYWNoaW5lPWk0
ODYtbmNyCisJCW9zPS1zeXN2NAorCQk7OworCW5ldGJzZDM4NikKKwkJYmFzaWNfbWFjaGluZT1p
Mzg2LXVua25vd24KKwkJb3M9LW5ldGJzZAorCQk7OworCW5ldHdpbmRlcikKKwkJYmFzaWNfbWFj
aGluZT1hcm12NGwtcmViZWwKKwkJb3M9LWxpbnV4CisJCTs7CisJbmV3cyB8IG5ld3M3MDAgfCBu
ZXdzODAwIHwgbmV3czkwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXNvbnkKKwkJb3M9LW5ld3Nv
cworCQk7OworCW5ld3MxMDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAzMC1zb255CisJCW9zPS1u
ZXdzb3MKKwkJOzsKKwluZXdzLTM2MDAgfCByaXNjLW5ld3MpCisJCWJhc2ljX21hY2hpbmU9bWlw
cy1zb255CisJCW9zPS1uZXdzb3MKKwkJOzsKKwluZWN2NzApCisJCWJhc2ljX21hY2hpbmU9djcw
LW5lYworCQlvcz0tc3lzdgorCQk7OworCW5leHQgfCBtKi1uZXh0ICkKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLW5leHQKKwkJY2FzZSAkb3MgaW4KKwkJICAgIC1uZXh0c3RlcCogKQorCQkJOzsKKwkJ
ICAgIC1uczIqKQorCQkgICAgICBvcz0tbmV4dHN0ZXAyCisJCQk7OworCQkgICAgKikKKwkJICAg
ICAgb3M9LW5leHRzdGVwMworCQkJOzsKKwkJZXNhYworCQk7OworCW5oMzAwMCkKKwkJYmFzaWNf
bWFjaGluZT1tNjhrLWhhcnJpcworCQlvcz0tY3h1eAorCQk7OworCW5oWzQ1XTAwMCkKKwkJYmFz
aWNfbWFjaGluZT1tODhrLWhhcnJpcworCQlvcz0tY3h1eAorCQk7OworCW5pbmR5OTYwKQorCQli
YXNpY19tYWNoaW5lPWk5NjAtaW50ZWwKKwkJb3M9LW5pbmR5CisJCTs7CisJbW9uOTYwKQorCQli
YXNpY19tYWNoaW5lPWk5NjAtaW50ZWwKKwkJb3M9LW1vbjk2MAorCQk7OworCW5vbnN0b3B1eCkK
KwkJYmFzaWNfbWFjaGluZT1taXBzLWNvbXBhcQorCQlvcz0tbm9uc3RvcHV4CisJCTs7CisJbnAx
KQorCQliYXNpY19tYWNoaW5lPW5wMS1nb3VsZAorCQk7OworCW5zci10YW5kZW0pCisJCWJhc2lj
X21hY2hpbmU9bnNyLXRhbmRlbQorCQk7OworCW9wNTBuLSogfCBvcDYwYy0qKQorCQliYXNpY19t
YWNoaW5lPWhwcGExLjEtb2tpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwlvcGVucmlzYyB8IG9wZW5y
aXNjLSopCisJCWJhc2ljX21hY2hpbmU9b3IzMi11bmtub3duCisJCTs7CisJb3M0MDApCisJCWJh
c2ljX21hY2hpbmU9cG93ZXJwYy1pYm0KKwkJb3M9LW9zNDAwCisJCTs7CisJT1NFNjgwMDAgfCBv
c2U2ODAwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtZXJpY3Nzb24KKwkJb3M9LW9zZQorCQk7
OworCW9zNjhrKQorCQliYXNpY19tYWNoaW5lPW02OGstbm9uZQorCQlvcz0tb3M2OGsKKwkJOzsK
KwlwYS1oaXRhY2hpKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaGl0YWNoaQorCQlvcz0taGl1
eHdlMgorCQk7OworCXBhcmFnb24pCisJCWJhc2ljX21hY2hpbmU9aTg2MC1pbnRlbAorCQlvcz0t
b3NmCisJCTs7CisJcGFyaXNjKQorCQliYXNpY19tYWNoaW5lPWhwcGEtdW5rbm93bgorCQlvcz0t
bGludXgKKwkJOzsKKwlwYXJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhLWBlY2hvICRiYXNp
Y19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9zPS1saW51eAorCQk7OworCXBiZCkK
KwkJYmFzaWNfbWFjaGluZT1zcGFyYy10dGkKKwkJOzsKKwlwYmIpCisJCWJhc2ljX21hY2hpbmU9
bTY4ay10dGkKKwkJOzsKKwlwYzUzMiB8IHBjNTMyLSopCisJCWJhc2ljX21hY2hpbmU9bnMzMmst
cGM1MzIKKwkJOzsKKwlwYzk4KQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJOzsKKwlwYzk4
LSopCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9e
W14tXSotLy8nYAorCQk7OworCXBlbnRpdW0gfCBwNSB8IGs1IHwgazYgfCBuZXhnZW4gfCB2aWFj
MykKKwkJYmFzaWNfbWFjaGluZT1pNTg2LXBjCisJCTs7CisJcGVudGl1bXBybyB8IHA2IHwgNng4
NiB8IGF0aGxvbiB8IGF0aGxvbl8qKQorCQliYXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlw
ZW50aXVtaWkgfCBwZW50aXVtMiB8IHBlbnRpdW1paWkgfCBwZW50aXVtMykKKwkJYmFzaWNfbWFj
aGluZT1pNjg2LXBjCisJCTs7CisJcGVudGl1bTQpCisJCWJhc2ljX21hY2hpbmU9aTc4Ni1wYwor
CQk7OworCXBlbnRpdW0tKiB8IHA1LSogfCBrNS0qIHwgazYtKiB8IG5leGdlbi0qIHwgdmlhYzMt
KikKKwkJYmFzaWNfbWFjaGluZT1pNTg2LWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15b
Xi1dKi0vLydgCisJCTs7CisJcGVudGl1bXByby0qIHwgcDYtKiB8IDZ4ODYtKiB8IGF0aGxvbi0q
KQorCQliYXNpY19tYWNoaW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlte
LV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtaWktKiB8IHBlbnRpdW0yLSogfCBwZW50aXVtaWlpLSog
fCBwZW50aXVtMy0qKQorCQliYXNpY19tYWNoaW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUg
fCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtNC0qKQorCQliYXNpY19tYWNoaW5l
PWk3ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlw
bikKKwkJYmFzaWNfbWFjaGluZT1wbi1nb3VsZAorCQk7OworCXBvd2VyKQliYXNpY19tYWNoaW5l
PXBvd2VyLWlibQorCQk7OworCXBwYykJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJ
OzsKKwlwcGMtKikJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWBlY2hvICRiYXNpY19tYWNoaW5lIHwg
c2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcHBjbGUgfCBwb3dlcnBjbGl0dGxlIHwgcHBjLWxl
IHwgcG93ZXJwYy1saXR0bGUpCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLXVua25vd24KKwkJ
OzsKKwlwcGNsZS0qIHwgcG93ZXJwY2xpdHRsZS0qKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGNs
ZS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0
KQliYXNpY19tYWNoaW5lPXBvd2VycGM2NC11bmtub3duCisJCTs7CisJcHBjNjQtKikgYmFzaWNf
bWFjaGluZT1wb3dlcnBjNjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJOzsKKwlwcGM2NGxlIHwgcG93ZXJwYzY0bGl0dGxlIHwgcHBjNjQtbGUgfCBwb3dlcnBj
NjQtbGl0dGxlKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLXVua25vd24KKwkJOzsKKwlw
cGM2NGxlLSogfCBwb3dlcnBjNjRsaXR0bGUtKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjNjRs
ZS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBzMikK
KwkJYmFzaWNfbWFjaGluZT1pMzg2LWlibQorCQk7OworCXB3MzIpCisJCWJhc2ljX21hY2hpbmU9
aTU4Ni11bmtub3duCisJCW9zPS1wdzMyCisJCTs7CisJcmRvcykKKwkJYmFzaWNfbWFjaGluZT1p
Mzg2LXBjCisJCW9zPS1yZG9zCisJCTs7CisJcm9tNjhrKQorCQliYXNpY19tYWNoaW5lPW02OGst
cm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJcm1bNDZdMDApCisJCWJhc2ljX21hY2hpbmU9bWlw
cy1zaWVtZW5zCisJCTs7CisJcnRwYyB8IHJ0cGMtKikKKwkJYmFzaWNfbWFjaGluZT1yb21wLWli
bQorCQk7OworCXMzOTAgfCBzMzkwLSopCisJCWJhc2ljX21hY2hpbmU9czM5MC1pYm0KKwkJOzsK
KwlzMzkweCB8IHMzOTB4LSopCisJCWJhc2ljX21hY2hpbmU9czM5MHgtaWJtCisJCTs7CisJc2Ey
OTIwMCkKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tdWRpCisJCTs7CisJc2IxKQor
CQliYXNpY19tYWNoaW5lPW1pcHNpc2E2NHNiMS11bmtub3duCisJCTs7CisJc2IxZWwpCisJCWJh
c2ljX21hY2hpbmU9bWlwc2lzYTY0c2IxZWwtdW5rbm93bgorCQk7OworCXNkZSkKKwkJYmFzaWNf
bWFjaGluZT1taXBzaXNhMzItc2RlCisJCW9zPS1lbGYKKwkJOzsKKwlzZWkpCisJCWJhc2ljX21h
Y2hpbmU9bWlwcy1zZWkKKwkJb3M9LXNlaXV4CisJCTs7CisJc2VxdWVudCkKKwkJYmFzaWNfbWFj
aGluZT1pMzg2LXNlcXVlbnQKKwkJOzsKKwlzaCkKKwkJYmFzaWNfbWFjaGluZT1zaC1oaXRhY2hp
CisJCW9zPS1obXMKKwkJOzsKKwlzaDVlbCkKKwkJYmFzaWNfbWFjaGluZT1zaDVsZS11bmtub3du
CisJCTs7CisJc2g2NCkKKwkJYmFzaWNfbWFjaGluZT1zaDY0LXVua25vd24KKwkJOzsKKwlzcGFy
Y2xpdGUtd3JzIHwgc2ltc28td3JzKQorCQliYXNpY19tYWNoaW5lPXNwYXJjbGl0ZS13cnMKKwkJ
b3M9LXZ4d29ya3MKKwkJOzsKKwlzcHM3KQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlv
cz0tc3lzdjIKKwkJOzsKKwlzcHVyKQorCQliYXNpY19tYWNoaW5lPXNwdXItdW5rbm93bgorCQk7
OworCXN0MjAwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXRhbmRlbQorCQk7OworCXN0cmF0dXMp
CisJCWJhc2ljX21hY2hpbmU9aTg2MC1zdHJhdHVzCisJCW9zPS1zeXN2NAorCQk7OworCXN1bjIp
CisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJvczMpCisJCWJhc2ljX21h
Y2hpbmU9bTY4MDAwLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuMm9zNCkKKwkJYmFzaWNf
bWFjaGluZT1tNjgwMDAtc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW4zb3MzKQorCQliYXNp
Y19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlzdW4zb3M0KQorCQliYXNp
Y19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW40b3MzKQorCQliYXNp
Y19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuNG9zNCkKKwkJYmFz
aWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7OworCXN1bjRzb2wyKQorCQli
YXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlzdW4zIHwgc3Vu
My0qKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCTs7CisJc3VuNCkKKwkJYmFzaWNfbWFj
aGluZT1zcGFyYy1zdW4KKwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwgcm9hZHJ1bm5lcikKKwkJ
YmFzaWNfbWFjaGluZT1pMzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFzaWNfbWFjaGluZT1zdjEt
Y3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJhc2ljX21hY2hpbmU9aTM4
Ni1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCXQzZSkKKwkJYmFzaWNfbWFjaGluZT1hbHBo
YWV2NS1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJhc2ljX21hY2hpbmU9dDkw
LWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworCXRpYzU0eCB8IGM1NHgqKQorCQliYXNpY19tYWNo
aW5lPXRpYzU0eC11bmtub3duCisJCW9zPS1jb2ZmCisJCTs7CisJdGljNTV4IHwgYzU1eCopCisJ
CWJhc2ljX21hY2hpbmU9dGljNTV4LXVua25vd24KKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM2eCB8
IGM2eCopCisJCWJhc2ljX21hY2hpbmU9dGljNngtdW5rbm93bgorCQlvcz0tY29mZgorCQk7Owor
ICAgICAgICAjIFRoaXMgbXVzdCBiZSBtYXRjaGVkIGJlZm9yZSB0aWxlKi4KKyAgICAgICAgdGls
ZWd4KikKKwkJYmFzaWNfbWFjaGluZT10aWxlZ3gtdW5rbm93bgorCQlvcz0tbGludXgtZ251CisJ
CTs7CisJdGlsZSopCisJCWJhc2ljX21hY2hpbmU9dGlsZS11bmtub3duCisJCW9zPS1saW51eC1n
bnUKKwkJOzsKKwl0eDM5KQorCQliYXNpY19tYWNoaW5lPW1pcHN0eDM5LXVua25vd24KKwkJOzsK
Kwl0eDM5ZWwpCisJCWJhc2ljX21hY2hpbmU9bWlwc3R4MzllbC11bmtub3duCisJCTs7CisJdG9h
ZDEpCisJCWJhc2ljX21hY2hpbmU9cGRwMTAteGtsCisJCW9zPS10b3BzMjAKKwkJOzsKKwl0b3dl
ciB8IHRvd2VyLTMyKQorCQliYXNpY19tYWNoaW5lPW02OGstbmNyCisJCTs7CisJdHBmKQorCQli
YXNpY19tYWNoaW5lPXMzOTB4LWlibQorCQlvcz0tdHBmCisJCTs7CisJdWRpMjlrKQorCQliYXNp
Y19tYWNoaW5lPWEyOWstYW1kCisJCW9zPS11ZGkKKwkJOzsKKwl1bHRyYTMpCisJCWJhc2ljX21h
Y2hpbmU9YTI5ay1ueXUKKwkJb3M9LXN5bTEKKwkJOzsKKwl2ODEwIHwgbmVjdjgxMCkKKwkJYmFz
aWNfbWFjaGluZT12ODEwLW5lYworCQlvcz0tbm9uZQorCQk7OworCXZheHYpCisJCWJhc2ljX21h
Y2hpbmU9dmF4LWRlYworCQlvcz0tc3lzdgorCQk7OworCXZtcykKKwkJYmFzaWNfbWFjaGluZT12
YXgtZGVjCisJCW9zPS12bXMKKwkJOzsKKwl2cHAqfHZ4fHZ4LSopCisJCWJhc2ljX21hY2hpbmU9
ZjMwMS1mdWppdHN1CisJCTs7CisJdnh3b3Jrczk2MCkKKwkJYmFzaWNfbWFjaGluZT1pOTYwLXdy
cworCQlvcz0tdnh3b3JrcworCQk7OworCXZ4d29ya3M2OCkKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LXdycworCQlvcz0tdnh3b3JrcworCQk7OworCXZ4d29ya3MyOWspCisJCWJhc2ljX21hY2hpbmU9
YTI5ay13cnMKKwkJb3M9LXZ4d29ya3MKKwkJOzsKKwl3NjUqKQorCQliYXNpY19tYWNoaW5lPXc2
NS13ZGMKKwkJb3M9LW5vbmUKKwkJOzsKKwl3ODlrLSopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEu
MS13aW5ib25kCisJCW9zPS1wcm9lbGYKKwkJOzsKKwl4Ym94KQorCQliYXNpY19tYWNoaW5lPWk2
ODYtcGMKKwkJb3M9LW1pbmd3MzIKKwkJOzsKKwl4cHMgfCB4cHMxMDApCisJCWJhc2ljX21hY2hp
bmU9eHBzMTAwLWhvbmV5d2VsbAorCQk7OworCXltcCkKKwkJYmFzaWNfbWFjaGluZT15bXAtY3Jh
eQorCQlvcz0tdW5pY29zCisJCTs7CisJejhrLSotY29mZikKKwkJYmFzaWNfbWFjaGluZT16OGst
dW5rbm93bgorCQlvcz0tc2ltCisJCTs7CisJejgwLSotY29mZikKKwkJYmFzaWNfbWFjaGluZT16
ODAtdW5rbm93bgorCQlvcz0tc2ltCisJCTs7CisJbm9uZSkKKwkJYmFzaWNfbWFjaGluZT1ub25l
LW5vbmUKKwkJb3M9LW5vbmUKKwkJOzsKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBt
YW51ZmFjdHVyZXIgb2YgY2VydGFpbiBDUFUgdHlwZXMuICBJdCBpcyBpbgorIyBzb21lIGNhc2Vz
IHRoZSBvbmx5IG1hbnVmYWN0dXJlciwgaW4gb3RoZXJzLCBpdCBpcyB0aGUgbW9zdCBwb3B1bGFy
LgorCXc4OWspCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS13aW5ib25kCisJCTs7CisJb3A1MG4p
CisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJOzsKKwlvcDYwYykKKwkJYmFzaWNfbWFj
aGluZT1ocHBhMS4xLW9raQorCQk7OworCXJvbXApCisJCWJhc2ljX21hY2hpbmU9cm9tcC1pYm0K
KwkJOzsKKwltbWl4KQorCQliYXNpY19tYWNoaW5lPW1taXgta251dGgKKwkJOzsKKwlyczYwMDAp
CisJCWJhc2ljX21hY2hpbmU9cnM2MDAwLWlibQorCQk7OworCXZheCkKKwkJYmFzaWNfbWFjaGlu
ZT12YXgtZGVjCisJCTs7CisJcGRwMTApCisJCSMgdGhlcmUgYXJlIG1hbnkgY2xvbmVzLCBzbyBE
RUMgaXMgbm90IGEgc2FmZSBiZXQKKwkJYmFzaWNfbWFjaGluZT1wZHAxMC11bmtub3duCisJCTs7
CisJcGRwMTEpCisJCWJhc2ljX21hY2hpbmU9cGRwMTEtZGVjCisJCTs7CisJd2UzMmspCisJCWJh
c2ljX21hY2hpbmU9d2UzMmstYXR0CisJCTs7CisJc2hbMTIzNF0gfCBzaFsyNF1hIHwgc2hbMjRd
YWViIHwgc2hbMzRdZWIgfCBzaFsxMjM0XWxlIHwgc2hbMjNdZWxlKQorCQliYXNpY19tYWNoaW5l
PXNoLXVua25vd24KKwkJOzsKKwlzcGFyYyB8IHNwYXJjdjggfCBzcGFyY3Y5IHwgc3BhcmN2OWIg
fCBzcGFyY3Y5dikKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJOzsKKwljeWRyYSkKKwkJ
YmFzaWNfbWFjaGluZT1jeWRyYS1jeWRyb21lCisJCTs7CisJb3Jpb24pCisJCWJhc2ljX21hY2hp
bmU9b3Jpb24taGlnaGxldmVsCisJCTs7CisJb3Jpb24xMDUpCisJCWJhc2ljX21hY2hpbmU9Y2xp
cHBlci1oaWdobGV2ZWwKKwkJOzsKKwltYWMgfCBtcHcgfCBtYWMtbXB3KQorCQliYXNpY19tYWNo
aW5lPW02OGstYXBwbGUKKwkJOzsKKwlwbWFjIHwgcG1hYy1tcHcpCisJCWJhc2ljX21hY2hpbmU9
cG93ZXJwYy1hcHBsZQorCQk7OworCSotdW5rbm93bikKKwkJIyBNYWtlIHN1cmUgdG8gbWF0Y2gg
YW4gYWxyZWFkeS1jYW5vbmljYWxpemVkIG1hY2hpbmUgbmFtZS4KKwkJOzsKKwkqKQorCQllY2hv
IEludmFsaWQgY29uZmlndXJhdGlvbiBcYCQxXCc6IG1hY2hpbmUgXGAkYmFzaWNfbWFjaGluZVwn
IG5vdCByZWNvZ25pemVkIDE+JjIKKwkJZXhpdCAxCisJCTs7Citlc2FjCisKKyMgSGVyZSB3ZSBj
YW5vbmljYWxpemUgY2VydGFpbiBhbGlhc2VzIGZvciBtYW51ZmFjdHVyZXJzLgorY2FzZSAkYmFz
aWNfbWFjaGluZSBpbgorCSotZGlnaXRhbCopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2lj
X21hY2hpbmUgfCBzZWQgJ3MvZGlnaXRhbC4qL2RlYy8nYAorCQk7OworCSotY29tbW9kb3JlKikK
KwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9jb21tb2RvcmUu
Ki9jYm0vJ2AKKwkJOzsKKwkqKQorCQk7OworZXNhYworCisjIERlY29kZSBtYW51ZmFjdHVyZXIt
c3BlY2lmaWMgYWxpYXNlcyBmb3IgY2VydGFpbiBvcGVyYXRpbmcgc3lzdGVtcy4KKworaWYgWyB4
IiRvcyIgIT0geCIiIF0KK3RoZW4KK2Nhc2UgJG9zIGluCisgICAgICAgICMgRmlyc3QgbWF0Y2gg
c29tZSBzeXN0ZW0gdHlwZSBhbGlhc2VzCisgICAgICAgICMgdGhhdCBtaWdodCBnZXQgY29uZnVz
ZWQgd2l0aCB2YWxpZCBzeXN0ZW0gdHlwZXMuCisJIyAtc29sYXJpcyogaXMgYSBiYXNpYyBzeXN0
ZW0gdHlwZSwgd2l0aCB0aGlzIG9uZSBleGNlcHRpb24uCisgICAgICAgIC1hdXJvcmF1eCkKKwkg
ICAgICAgIG9zPS1hdXJvcmF1eAorCQk7OworCS1zb2xhcmlzMSB8IC1zb2xhcmlzMS4qKQorCQlv
cz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8c29sYXJpczF8c3Vub3M0fCdgCisJCTs7CisJLXNvbGFy
aXMpCisJCW9zPS1zb2xhcmlzMgorCQk7OworCS1zdnI0KikKKwkJb3M9LXN5c3Y0CisJCTs7CisJ
LXVuaXh3YXJlKikKKwkJb3M9LXN5c3Y0LjJ1dworCQk7OworCS1nbnUvbGludXgqKQorCQlvcz1g
ZWNobyAkb3MgfCBzZWQgLWUgJ3N8Z251L2xpbnV4fGxpbnV4LWdudXwnYAorCQk7OworCSMgRmly
c3QgYWNjZXB0IHRoZSBiYXNpYyBzeXN0ZW0gdHlwZXMuCisJIyBUaGUgcG9ydGFibGUgc3lzdGVt
cyBjb21lcyBmaXJzdC4KKwkjIEVhY2ggYWx0ZXJuYXRpdmUgTVVTVCBFTkQgSU4gQSAqLCB0byBt
YXRjaCBhIHZlcnNpb24gbnVtYmVyLgorCSMgLXN5c3YqIGlzIG5vdCBoZXJlIGJlY2F1c2UgaXQg
Y29tZXMgbGF0ZXIsIGFmdGVyIHN5c3ZyNC4KKwktZ251KiB8IC1ic2QqIHwgLW1hY2gqIHwgLW1p
bml4KiB8IC1nZW5peCogfCAtdWx0cml4KiB8IC1pcml4KiBcCisJICAgICAgfCAtKnZtcyogfCAt
c2NvKiB8IC1lc2l4KiB8IC1pc2MqIHwgLWFpeCogfCAtY25rKiB8IC1zdW5vcyB8IC1zdW5vc1sz
NF0qXAorCSAgICAgIHwgLWhwdXgqIHwgLXVub3MqIHwgLW9zZiogfCAtbHVuYSogfCAtZGd1eCog
fCAtYXVyb3JhdXgqIHwgLXNvbGFyaXMqIFwKKwkgICAgICB8IC1zeW0qIHwgLWtvcGVuc29sYXJp
cyogXAorCSAgICAgIHwgLWFtaWdhb3MqIHwgLWFtaWdhZG9zKiB8IC1tc2RvcyogfCAtbmV3c29z
KiB8IC11bmljb3MqIHwgLWFvZiogXAorCSAgICAgIHwgLWFvcyogfCAtYXJvcyogXAorCSAgICAg
IHwgLW5pbmR5KiB8IC12eHNpbSogfCAtdnh3b3JrcyogfCAtZWJtb24qIHwgLWhtcyogfCAtbXZz
KiBcCisJICAgICAgfCAtY2xpeCogfCAtcmlzY29zKiB8IC11bmlwbHVzKiB8IC1pcmlzKiB8IC1y
dHUqIHwgLXhlbml4KiBcCisJICAgICAgfCAtaGl1eCogfCAtMzg2YnNkKiB8IC1rbmV0YnNkKiB8
IC1taXJic2QqIHwgLW5ldGJzZCogXAorCSAgICAgIHwgLW9wZW5ic2QqIHwgLXNvbGlkYnNkKiBc
CisJICAgICAgfCAtZWtrb2JzZCogfCAta2ZyZWVic2QqIHwgLWZyZWVic2QqIHwgLXJpc2NpeCog
fCAtbHlueG9zKiBcCisJICAgICAgfCAtYm9zeCogfCAtbmV4dHN0ZXAqIHwgLWN4dXgqIHwgLWFv
dXQqIHwgLWVsZiogfCAtb2FiaSogXAorCSAgICAgIHwgLXB0eCogfCAtY29mZiogfCAtZWNvZmYq
IHwgLXdpbm50KiB8IC1kb21haW4qIHwgLXZzdGEqIFwKKwkgICAgICB8IC11ZGkqIHwgLWVhYmkq
IHwgLWxpdGVzKiB8IC1pZWVlKiB8IC1nbzMyKiB8IC1hdXgqIFwKKwkgICAgICB8IC1jaG9ydXNv
cyogfCAtY2hvcnVzcmRiKiB8IC1jZWdjYyogXAorCSAgICAgIHwgLWN5Z3dpbiogfCAtcGUqIHwg
LXBzb3MqIHwgLW1vc3MqIHwgLXByb2VsZiogfCAtcnRlbXMqIFwKKwkgICAgICB8IC1taW5ndzMy
KiB8IC1saW51eC1nbnUqIHwgLWxpbnV4LW5ld2xpYiogfCAtbGludXgtdWNsaWJjKiBcCisJICAg
ICAgfCAtdXhwdiogfCAtYmVvcyogfCAtbXBlaXgqIHwgLXVkayogXAorCSAgICAgIHwgLWludGVy
aXgqIHwgLXV3aW4qIHwgLW1rcyogfCAtcmhhcHNvZHkqIHwgLWRhcndpbiogfCAtb3BlbmVkKiBc
CisJICAgICAgfCAtb3BlbnN0ZXAqIHwgLW9za2l0KiB8IC1jb25peCogfCAtcHczMiogfCAtbm9u
c3RvcHV4KiBcCisJICAgICAgfCAtc3Rvcm0tY2hhb3MqIHwgLXRvcHMxMCogfCAtdGVuZXgqIHwg
LXRvcHMyMCogfCAtaXRzKiBcCisJICAgICAgfCAtb3MyKiB8IC12b3MqIHwgLXBhbG1vcyogfCAt
dWNsaW51eCogfCAtbnVjbGV1cyogXAorCSAgICAgIHwgLW1vcnBob3MqIHwgLXN1cGVydXgqIHwg
LXJ0bWsqIHwgLXJ0bWstbm92YSogfCAtd2luZGlzcyogXAorCSAgICAgIHwgLXBvd2VybWF4KiB8
IC1kbml4KiB8IC1ueDYgfCAtbng3IHwgLXNlaSogfCAtZHJhZ29uZmx5KiBcCisJICAgICAgfCAt
c2t5b3MqIHwgLWhhaWt1KiB8IC1yZG9zKiB8IC10b3BwZXJzKiB8IC1kcm9wcyogfCAtZXMqKQor
CSMgUmVtZW1iZXIsIGVhY2ggYWx0ZXJuYXRpdmUgTVVTVCBFTkQgSU4gKiwgdG8gbWF0Y2ggYSB2
ZXJzaW9uIG51bWJlci4KKwkJOzsKKwktcW54KikKKwkJY2FzZSAkYmFzaWNfbWFjaGluZSBpbgor
CQkgICAgeDg2LSogfCBpKjg2LSopCisJCQk7OworCQkgICAgKikKKwkJCW9zPS1udG8kb3MKKwkJ
CTs7CisJCWVzYWMKKwkJOzsKKwktbnRvLXFueCopCisJCTs7CisJLW50byopCisJCW9zPWBlY2hv
ICRvcyB8IHNlZCAtZSAnc3xudG98bnRvLXFueHwnYAorCQk7OworCS1zaW0gfCAtZXMxODAwKiB8
IC1obXMqIHwgLXhyYXkgfCAtb3M2OGsqIHwgLW5vbmUqIHwgLXY4OHIqIFwKKwkgICAgICB8IC13
aW5kb3dzKiB8IC1vc3ggfCAtYWJ1ZyB8IC1uZXR3YXJlKiB8IC1vczkqIHwgLWJlb3MqIHwgLWhh
aWt1KiBcCisJICAgICAgfCAtbWFjb3MqIHwgLW1wdyogfCAtbWFnaWMqIHwgLW1taXh3YXJlKiB8
IC1tb245NjAqIHwgLWxuZXdzKikKKwkJOzsKKwktbWFjKikKKwkJb3M9YGVjaG8gJG9zIHwgc2Vk
IC1lICdzfG1hY3xtYWNvc3wnYAorCQk7OworCS1saW51eC1kaWV0bGliYykKKwkJb3M9LWxpbnV4
LWRpZXRsaWJjCisJCTs7CisJLWxpbnV4KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfGxp
bnV4fGxpbnV4LWdudXwnYAorCQk7OworCS1zdW5vczUqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQg
LWUgJ3N8c3Vub3M1fHNvbGFyaXMyfCdgCisJCTs7CisJLXN1bm9zNiopCisJCW9zPWBlY2hvICRv
cyB8IHNlZCAtZSAnc3xzdW5vczZ8c29sYXJpczN8J2AKKwkJOzsKKwktb3BlbmVkKikKKwkJb3M9
LW9wZW5lZGl0aW9uCisJCTs7CisgICAgICAgIC1vczQwMCopCisJCW9zPS1vczQwMAorCQk7Owor
CS13aW5jZSopCisJCW9zPS13aW5jZQorCQk7OworCS1vc2Zyb3NlKikKKwkJb3M9LW9zZnJvc2UK
KwkJOzsKKwktb3NmKikKKwkJb3M9LW9zZgorCQk7OworCS11dGVrKikKKwkJb3M9LWJzZAorCQk7
OworCS1keW5peCopCisJCW9zPS1ic2QKKwkJOzsKKwktYWNpcyopCisJCW9zPS1hb3MKKwkJOzsK
KwktYXRoZW9zKikKKwkJb3M9LWF0aGVvcworCQk7OworCS1zeWxsYWJsZSopCisJCW9zPS1zeWxs
YWJsZQorCQk7OworCS0zODZic2QpCisJCW9zPS1ic2QKKwkJOzsKKwktY3RpeCogfCAtdXRzKikK
KwkJb3M9LXN5c3YKKwkJOzsKKwktbm92YSopCisJCW9zPS1ydG1rLW5vdmEKKwkJOzsKKwktbnMy
ICkKKwkJb3M9LW5leHRzdGVwMgorCQk7OworCS1uc2sqKQorCQlvcz0tbnNrCisJCTs7CisJIyBQ
cmVzZXJ2ZSB0aGUgdmVyc2lvbiBudW1iZXIgb2Ygc2luaXg1LgorCS1zaW5peDUuKikKKwkJb3M9
YGVjaG8gJG9zIHwgc2VkIC1lICdzfHNpbml4fHN5c3Z8J2AKKwkJOzsKKwktc2luaXgqKQorCQlv
cz0tc3lzdjQKKwkJOzsKKyAgICAgICAgLXRwZiopCisJCW9zPS10cGYKKwkJOzsKKwktdHJpdG9u
KikKKwkJb3M9LXN5c3YzCisJCTs7CisJLW9zcyopCisJCW9zPS1zeXN2MworCQk7OworCS1zdnI0
KQorCQlvcz0tc3lzdjQKKwkJOzsKKwktc3ZyMykKKwkJb3M9LXN5c3YzCisJCTs7CisJLXN5c3Zy
NCkKKwkJb3M9LXN5c3Y0CisJCTs7CisJIyBUaGlzIG11c3QgY29tZSBhZnRlciAtc3lzdnI0Lgor
CS1zeXN2KikKKwkJOzsKKwktb3NlKikKKwkJb3M9LW9zZQorCQk7OworCS1lczE4MDAqKQorCQlv
cz0tb3NlCisJCTs7CisJLXhlbml4KQorCQlvcz0teGVuaXgKKwkJOzsKKwktKm1pbnQgfCAtbWlu
dFswLTldKiB8IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQorCQlvcz0tbWludAorCQk7OworCS1hcm9z
KikKKwkJb3M9LWFyb3MKKwkJOzsKKwkta2FvcyopCisJCW9zPS1rYW9zCisJCTs7CisJLXp2bW9l
KQorCQlvcz0tenZtb2UKKwkJOzsKKwktZGljb3MqKQorCQlvcz0tZGljb3MKKwkJOzsKKyAgICAg
ICAgLW5hY2wqKQorCSAgICAgICAgOzsKKwktbm9uZSkKKwkJOzsKKwkqKQorCQkjIEdldCByaWQg
b2YgdGhlIGAtJyBhdCB0aGUgYmVnaW5uaW5nIG9mICRvcy4KKwkJb3M9YGVjaG8gJG9zIHwgc2Vk
ICdzL1teLV0qLS8vJ2AKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBzeXN0
ZW0gXGAkb3NcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworZXNhYworZWxz
ZQorCisjIEhlcmUgd2UgaGFuZGxlIHRoZSBkZWZhdWx0IG9wZXJhdGluZyBzeXN0ZW1zIHRoYXQg
Y29tZSB3aXRoIHZhcmlvdXMgbWFjaGluZXMuCisjIFRoZSB2YWx1ZSBzaG91bGQgYmUgd2hhdCB0
aGUgdmVuZG9yIGN1cnJlbnRseSBzaGlwcyBvdXQgdGhlIGRvb3Igd2l0aCB0aGVpcgorIyBtYWNo
aW5lIG9yIHB1dCBhbm90aGVyIHdheSwgdGhlIG1vc3QgcG9wdWxhciBvcyBwcm92aWRlZCB3aXRo
IHRoZSBtYWNoaW5lLgorCisjIE5vdGUgdGhhdCBpZiB5b3UncmUgZ29pbmcgdG8gdHJ5IHRvIG1h
dGNoICItTUFOVUZBQ1RVUkVSIiBoZXJlIChzYXksCisjICItc3VuIiksIHRoZW4geW91IGhhdmUg
dG8gdGVsbCB0aGUgY2FzZSBzdGF0ZW1lbnQgdXAgdG93YXJkcyB0aGUgdG9wCisjIHRoYXQgTUFO
VUZBQ1RVUkVSIGlzbid0IGFuIG9wZXJhdGluZyBzeXN0ZW0uICBPdGhlcndpc2UsIGNvZGUgYWJv
dmUKKyMgd2lsbCBzaWduYWwgYW4gZXJyb3Igc2F5aW5nIHRoYXQgTUFOVUZBQ1RVUkVSIGlzbid0
IGFuIG9wZXJhdGluZworIyBzeXN0ZW0sIGFuZCB3ZSdsbCBuZXZlciBnZXQgdG8gdGhpcyBwb2lu
dC4KKworY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorICAgICAgICBzY29yZS0qKQorCQlvcz0tZWxm
CisJCTs7CisgICAgICAgIHNwdS0qKQorCQlvcz0tZWxmCisJCTs7CisJKi1hY29ybikKKwkJb3M9
LXJpc2NpeDEuMgorCQk7OworCWFybSotcmViZWwpCisJCW9zPS1saW51eAorCQk7OworCWFybSot
c2VtaSkKKwkJb3M9LWFvdXQKKwkJOzsKKyAgICAgICAgYzR4LSogfCB0aWM0eC0qKQorICAgICAg
ICAJb3M9LWNvZmYKKwkJOzsKKwkjIFRoaXMgbXVzdCBjb21lIGJlZm9yZSB0aGUgKi1kZWMgZW50
cnkuCisJcGRwMTAtKikKKwkJb3M9LXRvcHMyMAorCQk7OworCXBkcDExLSopCisJCW9zPS1ub25l
CisJCTs7CisJKi1kZWMgfCB2YXgtKikKKwkJb3M9LXVsdHJpeDQuMgorCQk7OworCW02OCotYXBv
bGxvKQorCQlvcz0tZG9tYWluCisJCTs7CisJaTM4Ni1zdW4pCisJCW9zPS1zdW5vczQuMC4yCisJ
CTs7CisJbTY4MDAwLXN1bikKKwkJb3M9LXN1bm9zMworCQkjIFRoaXMgYWxzbyBleGlzdHMgaW4g
dGhlIGNvbmZpZ3VyZSBwcm9ncmFtLCBidXQgd2FzIG5vdCB0aGUKKwkJIyBkZWZhdWx0LgorCQkj
IG9zPS1zdW5vczQKKwkJOzsKKwltNjgqLWNpc2NvKQorCQlvcz0tYW91dAorCQk7OworICAgICAg
ICBtZXAtKikKKwkJb3M9LWVsZgorCQk7OworCW1pcHMqLWNpc2NvKQorCQlvcz0tZWxmCisJCTs7
CisJbWlwcyotKikKKwkJb3M9LWVsZgorCQk7OworCW9yMzItKikKKwkJb3M9LWNvZmYKKwkJOzsK
KwkqLXR0aSkJIyBtdXN0IGJlIGJlZm9yZSBzcGFyYyBlbnRyeSBvciB3ZSBnZXQgdGhlIHdyb25n
IG9zLgorCQlvcz0tc3lzdjMKKwkJOzsKKwlzcGFyYy0qIHwgKi1zdW4pCisJCW9zPS1zdW5vczQu
MS4xCisJCTs7CisJKi1iZSkKKwkJb3M9LWJlb3MKKwkJOzsKKwkqLWhhaWt1KQorCQlvcz0taGFp
a3UKKwkJOzsKKwkqLWlibSkKKwkJb3M9LWFpeAorCQk7OworICAgIAkqLWtudXRoKQorCQlvcz0t
bW1peHdhcmUKKwkJOzsKKwkqLXdlYykKKwkJb3M9LXByb2VsZgorCQk7OworCSotd2luYm9uZCkK
KwkJb3M9LXByb2VsZgorCQk7OworCSotb2tpKQorCQlvcz0tcHJvZWxmCisJCTs7CisJKi1ocCkK
KwkJb3M9LWhwdXgKKwkJOzsKKwkqLWhpdGFjaGkpCisJCW9zPS1oaXV4CisJCTs7CisJaTg2MC0q
IHwgKi1hdHQgfCAqLW5jciB8ICotYWx0b3MgfCAqLW1vdG9yb2xhIHwgKi1jb252ZXJnZW50KQor
CQlvcz0tc3lzdgorCQk7OworCSotY2JtKQorCQlvcz0tYW1pZ2FvcworCQk7OworCSotZGcpCisJ
CW9zPS1kZ3V4CisJCTs7CisJKi1kb2xwaGluKQorCQlvcz0tc3lzdjMKKwkJOzsKKwltNjhrLWNj
dXIpCisJCW9zPS1ydHUKKwkJOzsKKwltODhrLW9tcm9uKikKKwkJb3M9LWx1bmEKKwkJOzsKKwkq
LW5leHQgKQorCQlvcz0tbmV4dHN0ZXAKKwkJOzsKKwkqLXNlcXVlbnQpCisJCW9zPS1wdHgKKwkJ
OzsKKwkqLWNyZHMpCisJCW9zPS11bm9zCisJCTs7CisJKi1ucykKKwkJb3M9LWdlbml4CisJCTs7
CisJaTM3MC0qKQorCQlvcz0tbXZzCisJCTs7CisJKi1uZXh0KQorCQlvcz0tbmV4dHN0ZXAzCisJ
CTs7CisJKi1nb3VsZCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWhpZ2hsZXZlbCkKKwkJb3M9LWJz
ZAorCQk7OworCSotZW5jb3JlKQorCQlvcz0tYnNkCisJCTs7CisJKi1zZ2kpCisJCW9zPS1pcml4
CisJCTs7CisJKi1zaWVtZW5zKQorCQlvcz0tc3lzdjQKKwkJOzsKKwkqLW1hc3Njb21wKQorCQlv
cz0tcnR1CisJCTs7CisJZjMwWzAxXS1mdWppdHN1IHwgZjcwMC1mdWppdHN1KQorCQlvcz0tdXhw
dgorCQk7OworCSotcm9tNjhrKQorCQlvcz0tY29mZgorCQk7OworCSotKmJ1ZykKKwkJb3M9LWNv
ZmYKKwkJOzsKKwkqLWFwcGxlKQorCQlvcz0tbWFjb3MKKwkJOzsKKwkqLWF0YXJpKikKKwkJb3M9
LW1pbnQKKwkJOzsKKwkqKQorCQlvcz0tbm9uZQorCQk7OworZXNhYworZmkKKworIyBIZXJlIHdl
IGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB3ZSBrbm93IHRoZSBvcywgYW5kIHRoZSBDUFUgdHlwZSwg
YnV0IG5vdCB0aGUKKyMgbWFudWZhY3R1cmVyLiAgV2UgcGljayB0aGUgbG9naWNhbCBtYW51ZmFj
dHVyZXIuCit2ZW5kb3I9dW5rbm93bgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSotdW5rbm93
bikKKwkJY2FzZSAkb3MgaW4KKwkJCS1yaXNjaXgqKQorCQkJCXZlbmRvcj1hY29ybgorCQkJCTs7
CisJCQktc3Vub3MqKQorCQkJCXZlbmRvcj1zdW4KKwkJCQk7OworCQkJLWNuayp8LWFpeCopCisJ
CQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktYmVvcyopCisJCQkJdmVuZG9yPWJlCisJCQkJOzsK
KwkJCS1ocHV4KikKKwkJCQl2ZW5kb3I9aHAKKwkJCQk7OworCQkJLW1wZWl4KikKKwkJCQl2ZW5k
b3I9aHAKKwkJCQk7OworCQkJLWhpdXgqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsKKwkJ
CS11bm9zKikKKwkJCQl2ZW5kb3I9Y3JkcworCQkJCTs7CisJCQktZGd1eCopCisJCQkJdmVuZG9y
PWRnCisJCQkJOzsKKwkJCS1sdW5hKikKKwkJCQl2ZW5kb3I9b21yb24KKwkJCQk7OworCQkJLWdl
bml4KikKKwkJCQl2ZW5kb3I9bnMKKwkJCQk7OworCQkJLW12cyogfCAtb3BlbmVkKikKKwkJCQl2
ZW5kb3I9aWJtCisJCQkJOzsKKwkJCS1vczQwMCopCisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJ
CQktcHR4KikKKwkJCQl2ZW5kb3I9c2VxdWVudAorCQkJCTs7CisJCQktdHBmKikKKwkJCQl2ZW5k
b3I9aWJtCisJCQkJOzsKKwkJCS12eHNpbSogfCAtdnh3b3JrcyogfCAtd2luZGlzcyopCisJCQkJ
dmVuZG9yPXdycworCQkJCTs7CisJCQktYXV4KikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7Owor
CQkJLWhtcyopCisJCQkJdmVuZG9yPWhpdGFjaGkKKwkJCQk7OworCQkJLW1wdyogfCAtbWFjb3Mq
KQorCQkJCXZlbmRvcj1hcHBsZQorCQkJCTs7CisJCQktKm1pbnQgfCAtbWludFswLTldKiB8IC0q
TWlOVCB8IC1NaU5UWzAtOV0qKQorCQkJCXZlbmRvcj1hdGFyaQorCQkJCTs7CisJCQktdm9zKikK
KwkJCQl2ZW5kb3I9c3RyYXR1cworCQkJCTs7CisJCWVzYWMKKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkYmFzaWNfbWFjaGluZSB8IHNlZCAicy91bmtub3duLyR2ZW5kb3IvImAKKwkJOzsKK2VzYWMK
KworZWNobyAkYmFzaWNfbWFjaGluZSRvcworZXhpdAorCisjIExvY2FsIHZhcmlhYmxlczoKKyMg
ZXZhbDogKGFkZC1ob29rICd3cml0ZS1maWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1lLXN0
YW1wLXN0YXJ0OiAidGltZXN0YW1wPSciCisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0t
JTAyZCIKKyMgdGltZS1zdGFtcC1lbmQ6ICInIgorIyBFbmQ6CmRpZmYgLXIgNWIyNjc2YWMxMzIx
IC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlndXJlCVR1ZSBKYW4gMTAgMTk6
MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwMTUzIEBACisjISAvYmluL3NoCisjIEd1ZXNz
IHZhbHVlcyBmb3Igc3lzdGVtLWRlcGVuZGVudCB2YXJpYWJsZXMgYW5kIGNyZWF0ZSBNYWtlZmls
ZXMuCisjIEdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42Ny4KKyMKKyMKKyMgQ29weXJpZ2h0
IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk4LCAxOTk5LCAyMDAwLCAyMDAx
LAorIyAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEw
IEZyZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLgorIworIworIyBUaGlzIGNvbmZpZ3Vy
ZSBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbgor
IyBnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBjb3B5LCBkaXN0cmlidXRlIGFuZCBtb2Rp
ZnkgaXQuCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTTRzaCBJbml0aWFsaXphdGlv
bi4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMgQmUgbW9yZSBCb3VybmUgY29t
cGF0aWJsZQorRFVBTENBU0U9MTsgZXhwb3J0IERVQUxDQVNFICMgZm9yIE1LUyBzaAoraWYgdGVz
dCAtbiAiJHtaU0hfVkVSU0lPTitzZXR9IiAmJiAoZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYx
OyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25z
IG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiAkezErIiRAIn0sIHdoaWNoCisgICMgaXMgY29u
dHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1nICck
ezErIiRAIn0nPSciJEAiJworICBzZXRvcHQgTk9fR0xPQl9TVUJTVAorZWxzZQorICBjYXNlIGAo
c2V0IC1vKSAyPi9kZXYvbnVsbGAgaW4gIygKKyAgKnBvc2l4KikgOgorICAgIHNldCAtbyBwb3Np
eCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorCisKK2FzX25sPScKKycKK2V4cG9y
dCBhc19ubAorIyBQcmludGluZyBhIGxvbmcgc3RyaW5nIGNyYXNoZXMgU29sYXJpcyA3IC91c3Iv
YmluL3ByaW50Zi4KK2FzX2VjaG89J1xcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFwnCithc19lY2hvPSRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFz
X2VjaG8KK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRh
c19lY2hvCisjIFByZWZlciBhIGtzaCBzaGVsbCBidWlsdGluIG92ZXIgYW4gZXh0ZXJuYWwgcHJp
bnRmIHByb2dyYW0gb24gU29sYXJpcywKKyMgYnV0IHdpdGhvdXQgd2FzdGluZyBmb3JrcyBmb3Ig
YmFzaCBvciB6c2guCitpZiB0ZXN0IC16ICIkQkFTSF9WRVJTSU9OJFpTSF9WRVJTSU9OIiBcCisg
ICAgJiYgKHRlc3QgIlhgcHJpbnQgLXIgLS0gJGFzX2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9k
ZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmludCAtciAtLScKKyAgYXNfZWNob19uPSdwcmlu
dCAtcm4gLS0nCitlbGlmICh0ZXN0ICJYYHByaW50ZiAlcyAkYXNfZWNob2AiID0gIlgkYXNfZWNo
byIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50ZiAlc1xuJworICBhc19lY2hv
X249J3ByaW50ZiAlcycKK2Vsc2UKKyAgaWYgdGVzdCAiWGAoL3Vzci91Y2IvZWNobyAtbiAtbiAk
YXNfZWNobykgMj4vZGV2L251bGxgIiA9ICJYLW4gJGFzX2VjaG8iOyB0aGVuCisgICAgYXNfZWNo
b19ib2R5PSdldmFsIC91c3IvdWNiL2VjaG8gLW4gIiQxJGFzX25sIicKKyAgICBhc19lY2hvX249
Jy91c3IvdWNiL2VjaG8gLW4nCisgIGVsc2UKKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgZXhwciAi
WCQxIiA6ICJYXFwoLipcXCkiJworICAgIGFzX2VjaG9fbl9ib2R5PSdldmFsCisgICAgICBhcmc9
JDE7CisgICAgICBjYXNlICRhcmcgaW4gIygKKyAgICAgICoiJGFzX25sIiopCisJZXhwciAiWCRh
cmciIDogIlhcXCguKlxcKSRhc19ubCI7CisJYXJnPWBleHByICJYJGFyZyIgOiAiLiokYXNfbmxc
XCguKlxcKSJgOzsKKyAgICAgIGVzYWM7CisgICAgICBleHByICJYJGFyZyIgOiAiWFxcKC4qXFwp
IiB8IHRyIC1kICIkYXNfbmwiCisgICAgJworICAgIGV4cG9ydCBhc19lY2hvX25fYm9keQorICAg
IGFzX2VjaG9fbj0nc2ggLWMgJGFzX2VjaG9fbl9ib2R5IGFzX2VjaG8nCisgIGZpCisgIGV4cG9y
dCBhc19lY2hvX2JvZHkKKyAgYXNfZWNobz0nc2ggLWMgJGFzX2VjaG9fYm9keSBhc19lY2hvJwor
ZmkKKworIyBUaGUgdXNlciBpcyBhbHdheXMgcmlnaHQuCitpZiB0ZXN0ICIke1BBVEhfU0VQQVJB
VE9SK3NldH0iICE9IHNldDsgdGhlbgorICBQQVRIX1NFUEFSQVRPUj06CisgIChQQVRIPScvYmlu
Oy9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVsbCAyPiYxICYmIHsKKyAgICAo
UEFUSD0nL2JpbjovYmluJzsgRlBBVEg9JFBBVEg7IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSB8
fAorICAgICAgUEFUSF9TRVBBUkFUT1I9JzsnCisgIH0KK2ZpCisKKworIyBJRlMKKyMgV2UgbmVl
ZCBzcGFjZSwgdGFiIGFuZCBuZXcgbGluZSwgaW4gcHJlY2lzZWx5IHRoYXQgb3JkZXIuICBRdW90
aW5nIGlzCisjIHRoZXJlIHRvIHByZXZlbnQgZWRpdG9ycyBmcm9tIGNvbXBsYWluaW5nIGFib3V0
IHNwYWNlLXRhYi4KKyMgKElmIF9BU19QQVRIX1dBTEsgd2VyZSBjYWxsZWQgd2l0aCBJRlMgdW5z
ZXQsIGl0IHdvdWxkIGRpc2FibGUgd29yZAorIyBzcGxpdHRpbmcgYnkgc2V0dGluZyBJRlMgdG8g
ZW1wdHkgdmFsdWUuKQorSUZTPSIgIiIJJGFzX25sIgorCisjIEZpbmQgd2hvIHdlIGFyZS4gIExv
b2sgaW4gdGhlIHBhdGggaWYgd2UgY29udGFpbiBubyBkaXJlY3Rvcnkgc2VwYXJhdG9yLgorY2Fz
ZSAkMCBpbiAjKCgKKyAgKltcXC9dKiApIGFzX215c2VsZj0kMCA7OworICAqKSBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgdGVz
dCAtciAiJGFzX2Rpci8kMCIgJiYgYXNfbXlzZWxmPSRhc19kaXIvJDAgJiYgYnJlYWsKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgICAgIDs7Citlc2FjCisjIFdlIGRpZCBub3QgZmluZCBv
dXJzZWx2ZXMsIG1vc3QgcHJvYmFibHkgd2Ugd2VyZSBydW4gYXMgYHNoIENPTU1BTkQnCisjIGlu
IHdoaWNoIGNhc2Ugd2UgYXJlIG5vdCB0byBiZSBmb3VuZCBpbiB0aGUgcGF0aC4KK2lmIHRlc3Qg
IngkYXNfbXlzZWxmIiA9IHg7IHRoZW4KKyAgYXNfbXlzZWxmPSQwCitmaQoraWYgdGVzdCAhIC1m
ICIkYXNfbXlzZWxmIjsgdGhlbgorICAkYXNfZWNobyAiJGFzX215c2VsZjogZXJyb3I6IGNhbm5v
dCBmaW5kIG15c2VsZjsgcmVydW4gd2l0aCBhbiBhYnNvbHV0ZSBmaWxlIG5hbWUiID4mMgorICBl
eGl0IDEKK2ZpCisKKyMgVW5zZXQgdmFyaWFibGVzIHRoYXQgd2UgZG8gbm90IG5lZWQgYW5kIHdo
aWNoIGNhdXNlIGJ1Z3MgKGUuZy4gaW4KKyMgcHJlLTMuMCBVV0lOIGtzaCkuICBCdXQgZG8gbm90
IGNhdXNlIGJ1Z3MgaW4gYmFzaCAyLjAxOyB0aGUgInx8IGV4aXQgMSIKKyMgc3VwcHJlc3NlcyBh
bnkgIlNlZ21lbnRhdGlvbiBmYXVsdCIgbWVzc2FnZSB0aGVyZS4gICcoKCcgY291bGQKKyMgdHJp
Z2dlciBhIGJ1ZyBpbiBwZGtzaCA1LjIuMTQuCitmb3IgYXNfdmFyIGluIEJBU0hfRU5WIEVOViBN
QUlMIE1BSUxQQVRICitkbyBldmFsIHRlc3QgeFwkeyRhc192YXIrc2V0fSA9IHhzZXQgXAorICAm
JiAoICh1bnNldCAkYXNfdmFyKSB8fCBleGl0IDEpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCAk
YXNfdmFyIHx8IDoKK2RvbmUKK1BTMT0nJCAnCitQUzI9Jz4gJworUFM0PScrICcKKworIyBOTFMg
bnVpc2FuY2VzLgorTENfQUxMPUMKK2V4cG9ydCBMQ19BTEwKK0xBTkdVQUdFPUMKK2V4cG9ydCBM
QU5HVUFHRQorCisjIENEUEFUSC4KKyh1bnNldCBDRFBBVEgpID4vZGV2L251bGwgMj4mMSAmJiB1
bnNldCBDRFBBVEgKKworaWYgdGVzdCAieCRDT05GSUdfU0hFTEwiID0geDsgdGhlbgorICBhc19i
b3VybmVfY29tcGF0aWJsZT0iaWYgdGVzdCAtbiBcIlwke1pTSF9WRVJTSU9OK3NldH1cIiAmJiAo
ZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxM
Q01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiBc
JHsxK1wiXCRAXCJ9LCB3aGljaAorICAjIGlzIGNvbnRyYXJ5IHRvIG91ciB1c2FnZS4gIERpc2Fi
bGUgdGhpcyBmZWF0dXJlLgorICBhbGlhcyAtZyAnXCR7MStcIlwkQFwifSc9J1wiXCRAXCInCisg
IHNldG9wdCBOT19HTE9CX1NVQlNUCitlbHNlCisgIGNhc2UgXGAoc2V0IC1vKSAyPi9kZXYvbnVs
bFxgIGluICMoCisgICpwb3NpeCopIDoKKyAgICBzZXQgLW8gcG9zaXggOzsgIygKKyAgKikgOgor
ICAgICA7OworZXNhYworZmkKKyIKKyAgYXNfcmVxdWlyZWQ9ImFzX2ZuX3JldHVybiAoKSB7IChl
eGl0IFwkMSk7IH0KK2FzX2ZuX3N1Y2Nlc3MgKCkgeyBhc19mbl9yZXR1cm4gMDsgfQorYXNfZm5f
ZmFpbHVyZSAoKSB7IGFzX2ZuX3JldHVybiAxOyB9Cithc19mbl9yZXRfc3VjY2VzcyAoKSB7IHJl
dHVybiAwOyB9Cithc19mbl9yZXRfZmFpbHVyZSAoKSB7IHJldHVybiAxOyB9CisKK2V4aXRjb2Rl
PTAKK2FzX2ZuX3N1Y2Nlc3MgfHwgeyBleGl0Y29kZT0xOyBlY2hvIGFzX2ZuX3N1Y2Nlc3MgZmFp
bGVkLjsgfQorYXNfZm5fZmFpbHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fZmFpbHVy
ZSBzdWNjZWVkZWQuOyB9Cithc19mbl9yZXRfc3VjY2VzcyB8fCB7IGV4aXRjb2RlPTE7IGVjaG8g
YXNfZm5fcmV0X3N1Y2Nlc3MgZmFpbGVkLjsgfQorYXNfZm5fcmV0X2ZhaWx1cmUgJiYgeyBleGl0
Y29kZT0xOyBlY2hvIGFzX2ZuX3JldF9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2lmICggc2V0IHg7
IGFzX2ZuX3JldF9zdWNjZXNzIHkgJiYgdGVzdCB4ID0gXCJcJDFcIiApOyB0aGVuIDoKKworZWxz
ZQorICBleGl0Y29kZT0xOyBlY2hvIHBvc2l0aW9uYWwgcGFyYW1ldGVycyB3ZXJlIG5vdCBzYXZl
ZC4KK2ZpCit0ZXN0IHhcJGV4aXRjb2RlID0geDAgfHwgZXhpdCAxIgorICBhc19zdWdnZXN0ZWQ9
IiAgYXNfbGluZW5vXzE9Ijthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCRMSU5FTk87YXNfc3Vn
Z2VzdGVkPSRhc19zdWdnZXN0ZWQiIGFzX2xpbmVub18xYT1cJExJTkVOTworICBhc19saW5lbm9f
Mj0iO2FzX3N1Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1
Z2dlc3RlZCIgYXNfbGluZW5vXzJhPVwkTElORU5PCisgIGV2YWwgJ3Rlc3QgXCJ4XCRhc19saW5l
bm9fMSdcJGFzX3J1bidcIiAhPSBcInhcJGFzX2xpbmVub18yJ1wkYXNfcnVuJ1wiICYmCisgIHRl
c3QgXCJ4XGBleHByIFwkYXNfbGluZW5vXzEnXCRhc19ydW4nICsgMVxgXCIgPSBcInhcJGFzX2xp
bmVub18yJ1wkYXNfcnVuJ1wiJyB8fCBleGl0IDEKK3Rlc3QgXCQoKCAxICsgMSApKSA9IDIgfHwg
ZXhpdCAxIgorICBpZiAoZXZhbCAiJGFzX3JlcXVpcmVkIikgMj4vZGV2L251bGw7IHRoZW4gOgor
ICBhc19oYXZlX3JlcXVpcmVkPXllcworZWxzZQorICBhc19oYXZlX3JlcXVpcmVkPW5vCitmaQor
ICBpZiB0ZXN0IHgkYXNfaGF2ZV9yZXF1aXJlZCA9IHh5ZXMgJiYgKGV2YWwgIiRhc19zdWdnZXN0
ZWQiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisKK2Vsc2UKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorYXNfZm91bmQ9ZmFsc2UKK2ZvciBhc19kaXIgaW4gL2JpbiRQQVRI
X1NFUEFSQVRPUi91c3IvYmluJFBBVEhfU0VQQVJBVE9SJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgYXNfZm91bmQ9OgorICBj
YXNlICRhc19kaXIgaW4gIygKKwkgLyopCisJICAgZm9yIGFzX2Jhc2UgaW4gc2ggYmFzaCBrc2gg
c2g1OyBkbworCSAgICAgIyBUcnkgb25seSBzaGVsbHMgdGhhdCBleGlzdCwgdG8gc2F2ZSBzZXZl
cmFsIGZvcmtzLgorCSAgICAgYXNfc2hlbGw9JGFzX2Rpci8kYXNfYmFzZQorCSAgICAgaWYgeyB0
ZXN0IC1mICIkYXNfc2hlbGwiIHx8IHRlc3QgLWYgIiRhc19zaGVsbC5leGUiOyB9ICYmCisJCSAg
ICB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUiIiRhc19yZXF1aXJlZCIgfCBhc19y
dW49YSAiJGFzX3NoZWxsIjsgfSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIENPTkZJR19TSEVMTD0k
YXNfc2hlbGwgYXNfaGF2ZV9yZXF1aXJlZD15ZXMKKwkJICAgaWYgeyAkYXNfZWNobyAiJGFzX2Jv
dXJuZV9jb21wYXRpYmxlIiIkYXNfc3VnZ2VzdGVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9
IDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgYnJlYWsgMgorZmkKK2ZpCisJICAgZG9uZTs7CisgICAg
ICAgZXNhYworICBhc19mb3VuZD1mYWxzZQorZG9uZQorJGFzX2ZvdW5kIHx8IHsgaWYgeyB0ZXN0
IC1mICIkU0hFTEwiIHx8IHRlc3QgLWYgIiRTSEVMTC5leGUiOyB9ICYmCisJICAgICAgeyAkYXNf
ZWNobyAiJGFzX2JvdXJuZV9jb21wYXRpYmxlIiIkYXNfcmVxdWlyZWQiIHwgYXNfcnVuPWEgIiRT
SEVMTCI7IH0gMj4vZGV2L251bGw7IHRoZW4gOgorICBDT05GSUdfU0hFTEw9JFNIRUxMIGFzX2hh
dmVfcmVxdWlyZWQ9eWVzCitmaTsgfQorSUZTPSRhc19zYXZlX0lGUworCisKKyAgICAgIGlmIHRl
c3QgIngkQ09ORklHX1NIRUxMIiAhPSB4OyB0aGVuIDoKKyAgIyBXZSBjYW5ub3QgeWV0IGFzc3Vt
ZSBhIGRlY2VudCBzaGVsbCwgc28gd2UgaGF2ZSB0byBwcm92aWRlIGEKKwkjIG5ldXRyYWxpemF0
aW9uIHZhbHVlIGZvciBzaGVsbHMgd2l0aG91dCB1bnNldDsgYW5kIHRoaXMgYWxzbworCSMgd29y
a3MgYXJvdW5kIHNoZWxscyB0aGF0IGNhbm5vdCB1bnNldCBub25leGlzdGVudCB2YXJpYWJsZXMu
CisJQkFTSF9FTlY9L2Rldi9udWxsCisJRU5WPS9kZXYvbnVsbAorCSh1bnNldCBCQVNIX0VOVikg
Pi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IEJBU0hfRU5WIEVOVgorCWV4cG9ydCBDT05GSUdfU0hF
TEwKKwlleGVjICIkQ09ORklHX1NIRUxMIiAiJGFzX215c2VsZiIgJHsxKyIkQCJ9CitmaQorCisg
ICAgaWYgdGVzdCB4JGFzX2hhdmVfcmVxdWlyZWQgPSB4bm87IHRoZW4gOgorICAkYXNfZWNobyAi
JDA6IFRoaXMgc2NyaXB0IHJlcXVpcmVzIGEgc2hlbGwgbW9yZSBtb2Rlcm4gdGhhbiBhbGwiCisg
ICRhc19lY2hvICIkMDogdGhlIHNoZWxscyB0aGF0IEkgZm91bmQgb24geW91ciBzeXN0ZW0uIgor
ICBpZiB0ZXN0IHgke1pTSF9WRVJTSU9OK3NldH0gPSB4c2V0IDsgdGhlbgorICAgICRhc19lY2hv
ICIkMDogSW4gcGFydGljdWxhciwgenNoICRaU0hfVkVSU0lPTiBoYXMgYnVncyBhbmQgc2hvdWxk
IgorICAgICRhc19lY2hvICIkMDogYmUgdXBncmFkZWQgdG8genNoIDQuMy40IG9yIGxhdGVyLiIK
KyAgZWxzZQorICAgICRhc19lY2hvICIkMDogUGxlYXNlIHRlbGwgYnVnLWF1dG9jb25mQGdudS5v
cmcgYWJvdXQgeW91ciBzeXN0ZW0sCiskMDogaW5jbHVkaW5nIGFueSBlcnJvciBwb3NzaWJseSBv
dXRwdXQgYmVmb3JlIHRoaXMKKyQwOiBtZXNzYWdlLiBUaGVuIGluc3RhbGwgYSBtb2Rlcm4gc2hl
bGwsIG9yIG1hbnVhbGx5IHJ1bgorJDA6IHRoZSBzY3JpcHQgdW5kZXIgc3VjaCBhIHNoZWxsIGlm
IHlvdSBkbyBoYXZlIG9uZS4iCisgIGZpCisgIGV4aXQgMQorZmkKK2ZpCitmaQorU0hFTEw9JHtD
T05GSUdfU0hFTEwtL2Jpbi9zaH0KK2V4cG9ydCBTSEVMTAorIyBVbnNldCBtb3JlIHZhcmlhYmxl
cyBrbm93biB0byBpbnRlcmZlcmUgd2l0aCBiZWhhdmlvciBvZiBjb21tb24gdG9vbHMuCitDTElD
T0xPUl9GT1JDRT0gR1JFUF9PUFRJT05TPQordW5zZXQgQ0xJQ09MT1JfRk9SQ0UgR1JFUF9PUFRJ
T05TCisKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTTRzaCBTaGVsbCBGdW5jdGlv
bnMuICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMgYXNfZm5fdW5zZXQgVkFSCisj
IC0tLS0tLS0tLS0tLS0tLQorIyBQb3J0YWJseSB1bnNldCBWQVIuCithc19mbl91bnNldCAoKQor
eworICB7IGV2YWwgJDE9OyB1bnNldCAkMTt9Cit9Cithc191bnNldD1hc19mbl91bnNldAorCisj
IGFzX2ZuX3NldF9zdGF0dXMgU1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFNl
dCAkPyB0byBTVEFUVVMsIHdpdGhvdXQgZm9ya2luZy4KK2FzX2ZuX3NldF9zdGF0dXMgKCkKK3sK
KyAgcmV0dXJuICQxCit9ICMgYXNfZm5fc2V0X3N0YXR1cworCisjIGFzX2ZuX2V4aXQgU1RBVFVT
CisjIC0tLS0tLS0tLS0tLS0tLS0tCisjIEV4aXQgdGhlIHNoZWxsIHdpdGggU1RBVFVTLCBldmVu
IGluIGEgInRyYXAgMCIgb3IgInNldCAtZSIgY29udGV4dC4KK2FzX2ZuX2V4aXQgKCkKK3sKKyAg
c2V0ICtlCisgIGFzX2ZuX3NldF9zdGF0dXMgJDEKKyAgZXhpdCAkMQorfSAjIGFzX2ZuX2V4aXQK
KworIyBhc19mbl9ta2Rpcl9wCisjIC0tLS0tLS0tLS0tLS0KKyMgQ3JlYXRlICIkYXNfZGlyIiBh
cyBhIGRpcmVjdG9yeSwgaW5jbHVkaW5nIHBhcmVudHMgaWYgbmVjZXNzYXJ5LgorYXNfZm5fbWtk
aXJfcCAoKQoreworCisgIGNhc2UgJGFzX2RpciBpbiAjKAorICAtKikgYXNfZGlyPS4vJGFzX2Rp
cjs7CisgIGVzYWMKKyAgdGVzdCAtZCAiJGFzX2RpciIgfHwgZXZhbCAkYXNfbWtkaXJfcCB8fCB7
CisgICAgYXNfZGlycz0KKyAgICB3aGlsZSA6OyBkbworICAgICAgY2FzZSAkYXNfZGlyIGluICMo
CisgICAgICAqXCcqKSBhc19xZGlyPWAkYXNfZWNobyAiJGFzX2RpciIgfCBzZWQgInMvJy8nXFxc
XFxcXFwnJy9nImA7OyAjJygKKyAgICAgICopIGFzX3FkaXI9JGFzX2Rpcjs7CisgICAgICBlc2Fj
CisgICAgICBhc19kaXJzPSInJGFzX3FkaXInICRhc19kaXJzIgorICAgICAgYXNfZGlyPWAkYXNf
ZGlybmFtZSAtLSAiJGFzX2RpciIgfHwKKyRhc19leHByIFgiJGFzX2RpciIgOiAnWFwoLipbXi9d
XCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpW14vXScgXHwg
XAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFzX2RpciIgOiAnWFwoL1wp
JyBcfCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhc19kaXIiIHwKKyAgICBzZWQgJy9e
WFwoLipbXi9dXClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAg
fQorCSAgL15YXChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAg
L15YXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cKS4q
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICAgICAgdGVz
dCAtZCAiJGFzX2RpciIgJiYgYnJlYWsKKyAgICBkb25lCisgICAgdGVzdCAteiAiJGFzX2RpcnMi
IHx8IGV2YWwgIm1rZGlyICRhc19kaXJzIgorICB9IHx8IHRlc3QgLWQgIiRhc19kaXIiIHx8IGFz
X2ZuX2Vycm9yICQ/ICJjYW5ub3QgY3JlYXRlIGRpcmVjdG9yeSAkYXNfZGlyIgorCisKK30gIyBh
c19mbl9ta2Rpcl9wCisjIGFzX2ZuX2FwcGVuZCBWQVIgVkFMVUUKKyMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorIyBBcHBlbmQgdGhlIHRleHQgaW4gVkFMVUUgdG8gdGhlIGVuZCBvZiB0aGUgZGVm
aW5pdGlvbiBjb250YWluZWQgaW4gVkFSLiBUYWtlCisjIGFkdmFudGFnZSBvZiBhbnkgc2hlbGwg
b3B0aW1pemF0aW9ucyB0aGF0IGFsbG93IGFtb3J0aXplZCBsaW5lYXIgZ3Jvd3RoIG92ZXIKKyMg
cmVwZWF0ZWQgYXBwZW5kcywgaW5zdGVhZCBvZiB0aGUgdHlwaWNhbCBxdWFkcmF0aWMgZ3Jvd3Ro
IHByZXNlbnQgaW4gbmFpdmUKKyMgaW1wbGVtZW50YXRpb25zLgoraWYgKGV2YWwgImFzX3Zhcj0x
OyBhc192YXIrPTI7IHRlc3QgeFwkYXNfdmFyID0geDEyIikgMj4vZGV2L251bGw7IHRoZW4gOgor
ICBldmFsICdhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDErPVwkMgorICB9JworZWxz
ZQorICBhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDE9XCQkMVwkMgorICB9CitmaSAj
IGFzX2ZuX2FwcGVuZAorCisjIGFzX2ZuX2FyaXRoIEFSRy4uLgorIyAtLS0tLS0tLS0tLS0tLS0t
LS0KKyMgUGVyZm9ybSBhcml0aG1ldGljIGV2YWx1YXRpb24gb24gdGhlIEFSR3MsIGFuZCBzdG9y
ZSB0aGUgcmVzdWx0IGluIHRoZQorIyBnbG9iYWwgJGFzX3ZhbC4gVGFrZSBhZHZhbnRhZ2Ugb2Yg
c2hlbGxzIHRoYXQgY2FuIGF2b2lkIGZvcmtzLiBUaGUgYXJndW1lbnRzCisjIG11c3QgYmUgcG9y
dGFibGUgYWNyb3NzICQoKCkpIGFuZCBleHByLgoraWYgKGV2YWwgInRlc3QgXCQoKCAxICsgMSAp
KSA9IDIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2FyaXRoICgpCisgIHsK
KyAgICBhc192YWw9JCgoICQqICkpCisgIH0nCitlbHNlCisgIGFzX2ZuX2FyaXRoICgpCisgIHsK
KyAgICBhc192YWw9YGV4cHIgIiRAIiB8fCB0ZXN0ICQ/IC1lcSAxYAorICB9CitmaSAjIGFzX2Zu
X2FyaXRoCisKKworIyBhc19mbl9lcnJvciBTVEFUVVMgRVJST1IgW0xJTkVOTyBMT0dfRkRdCisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgT3V0cHV0ICJgYmFz
ZW5hbWUgJDBgOiBlcnJvcjogRVJST1IiIHRvIHN0ZGVyci4gSWYgTElORU5PIGFuZCBMT0dfRkQg
YXJlCisjIHByb3ZpZGVkLCBhbHNvIG91dHB1dCB0aGUgZXJyb3IgdG8gTE9HX0ZELCByZWZlcmVu
Y2luZyBMSU5FTk8uIFRoZW4gZXhpdCB0aGUKKyMgc2NyaXB0IHdpdGggU1RBVFVTLCB1c2luZyAx
IGlmIHRoYXQgd2FzIDAuCithc19mbl9lcnJvciAoKQoreworICBhc19zdGF0dXM9JDE7IHRlc3Qg
JGFzX3N0YXR1cyAtZXEgMCAmJiBhc19zdGF0dXM9MQorICBpZiB0ZXN0ICIkNCI7IHRoZW4KKyAg
ICBhc19saW5lbm89JHthc19saW5lbm8tIiQzIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19z
dGFjaz0kYXNfbGluZW5vX3N0YWNrCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6ICQyIiA+JiQ0CisgIGZpCisgICRhc19lY2hvICIkYXNfbWU6IGVycm9y
OiAkMiIgPiYyCisgIGFzX2ZuX2V4aXQgJGFzX3N0YXR1cworfSAjIGFzX2ZuX2Vycm9yCisKK2lm
IGV4cHIgYSA6ICdcKGFcKScgPi9kZXYvbnVsbCAyPiYxICYmCisgICB0ZXN0ICJYYGV4cHIgMDAw
MDEgOiAnLipcKC4uLlwpJ2AiID0gWDAwMTsgdGhlbgorICBhc19leHByPWV4cHIKK2Vsc2UKKyAg
YXNfZXhwcj1mYWxzZQorZmkKKworaWYgKGJhc2VuYW1lIC0tIC8pID4vZGV2L251bGwgMj4mMSAm
JiB0ZXN0ICJYYGJhc2VuYW1lIC0tIC8gMj4mMWAiID0gIlgvIjsgdGhlbgorICBhc19iYXNlbmFt
ZT1iYXNlbmFtZQorZWxzZQorICBhc19iYXNlbmFtZT1mYWxzZQorZmkKKworaWYgKGFzX2Rpcj1g
ZGlybmFtZSAtLSAvYCAmJiB0ZXN0ICJYJGFzX2RpciIgPSBYLykgPi9kZXYvbnVsbCAyPiYxOyB0
aGVuCisgIGFzX2Rpcm5hbWU9ZGlybmFtZQorZWxzZQorICBhc19kaXJuYW1lPWZhbHNlCitmaQor
Cithc19tZT1gJGFzX2Jhc2VuYW1lIC0tICIkMCIgfHwKKyRhc19leHByIFgvIiQwIiA6ICcuKi9c
KFteL11bXi9dKlwpLyokJyBcfCBcCisJIFgiJDAiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJDAi
IDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWC8iJDAiIHwKKyAgICBz
ZWQgJy9eLipcL1woW14vXVteL10qXClcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0K
KwkgIC9eWFwvXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwv
XChcL1wpLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisK
KyMgQXZvaWQgZGVwZW5kaW5nIHVwb24gQ2hhcmFjdGVyIFJhbmdlcy4KK2FzX2NyX2xldHRlcnM9
J2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6JworYXNfY3JfTEVUVEVSUz0nQUJDREVGR0hJSktM
TU5PUFFSU1RVVldYWVonCithc19jcl9MZXR0ZXJzPSRhc19jcl9sZXR0ZXJzJGFzX2NyX0xFVFRF
UlMKK2FzX2NyX2RpZ2l0cz0nMDEyMzQ1Njc4OScKK2FzX2NyX2FsbnVtPSRhc19jcl9MZXR0ZXJz
JGFzX2NyX2RpZ2l0cworCisKKyAgYXNfbGluZW5vXzE9JExJTkVOTyBhc19saW5lbm9fMWE9JExJ
TkVOTworICBhc19saW5lbm9fMj0kTElORU5PIGFzX2xpbmVub18yYT0kTElORU5PCisgIGV2YWwg
J3Rlc3QgIngkYXNfbGluZW5vXzEnJGFzX3J1biciICE9ICJ4JGFzX2xpbmVub18yJyRhc19ydW4n
IiAmJgorICB0ZXN0ICJ4YGV4cHIgJGFzX2xpbmVub18xJyRhc19ydW4nICsgMWAiID0gIngkYXNf
bGluZW5vXzInJGFzX3J1biciJyB8fCB7CisgICMgQmxhbWUgTGVlIEUuIE1jTWFob24gKDE5MzEt
MTk4OSkgZm9yIHNlZCdzIHN5bnRheC4gIDotKQorICBzZWQgLW4gJworICAgIHAKKyAgICAvWyRd
TElORU5PLz0KKyAgJyA8JGFzX215c2VsZiB8CisgICAgc2VkICcKKyAgICAgIHMvWyRdTElORU5P
LiovJi0vCisgICAgICB0IGxpbmVubworICAgICAgYgorICAgICAgOmxpbmVubworICAgICAgTgor
ICAgICAgOmxvb3AKKyAgICAgIHMvWyRdTElORU5PXChbXickYXNfY3JfYWxudW0nX10uKlxuXClc
KC4qXCkvXDJcMVwyLworICAgICAgdCBsb29wCisgICAgICBzLy1cbi4qLy8KKyAgICAnID4kYXNf
bWUubGluZW5vICYmCisgIGNobW9kICt4ICIkYXNfbWUubGluZW5vIiB8fAorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZTogZXJyb3I6IGNhbm5vdCBjcmVhdGUgJGFzX21lLmxpbmVubzsgcmVydW4gd2l0
aCBhIFBPU0lYIHNoZWxsIiA+JjI7IGFzX2ZuX2V4aXQgMTsgfQorCisgICMgRG9uJ3QgdHJ5IHRv
IGV4ZWMgYXMgaXQgY2hhbmdlcyAkWzBdLCBjYXVzaW5nIGFsbCBzb3J0IG9mIHByb2JsZW1zCisg
ICMgKHRoZSBkaXJuYW1lIG9mICRbMF0gaXMgbm90IHRoZSBwbGFjZSB3aGVyZSB3ZSBtaWdodCBm
aW5kIHRoZQorICAjIG9yaWdpbmFsIGFuZCBzbyBvbi4gIEF1dG9jb25mIGlzIGVzcGVjaWFsbHkg
c2Vuc2l0aXZlIHRvIHRoaXMpLgorICAuICIuLyRhc19tZS5saW5lbm8iCisgICMgRXhpdCBzdGF0
dXMgaXMgdGhhdCBvZiB0aGUgbGFzdCBjb21tYW5kLgorICBleGl0Cit9CisKK0VDSE9fQz0gRUNI
T19OPSBFQ0hPX1Q9CitjYXNlIGBlY2hvIC1uIHhgIGluICMoKCgoKAorLW4qKQorICBjYXNlIGBl
Y2hvICd4eVxjJ2AgaW4KKyAgKmMqKSBFQ0hPX1Q9JwknOzsJIyBFQ0hPX1QgaXMgc2luZ2xlIHRh
YiBjaGFyYWN0ZXIuCisgIHh5KSAgRUNIT19DPSdcYyc7OworICAqKSAgIGVjaG8gYGVjaG8ga3No
ODggYnVnIG9uIEFJWCA2LjFgID4gL2Rldi9udWxsCisgICAgICAgRUNIT19UPScJJzs7CisgIGVz
YWM7OworKikKKyAgRUNIT19OPSctbic7OworZXNhYworCitybSAtZiBjb25mJCQgY29uZiQkLmV4
ZSBjb25mJCQuZmlsZQoraWYgdGVzdCAtZCBjb25mJCQuZGlyOyB0aGVuCisgIHJtIC1mIGNvbmYk
JC5kaXIvY29uZiQkLmZpbGUKK2Vsc2UKKyAgcm0gLWYgY29uZiQkLmRpcgorICBta2RpciBjb25m
JCQuZGlyIDI+L2Rldi9udWxsCitmaQoraWYgKGVjaG8gPmNvbmYkJC5maWxlKSAyPi9kZXYvbnVs
bDsgdGhlbgorICBpZiBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4K
KyAgICBhc19sbl9zPSdsbiAtcycKKyAgICAjIC4uLiBidXQgdGhlcmUgYXJlIHR3byBnb3RjaGFz
OgorICAgICMgMSkgT24gTVNZUywgYm90aCBgbG4gLXMgZmlsZSBkaXInIGFuZCBgbG4gZmlsZSBk
aXInIGZhaWwuCisgICAgIyAyKSBESkdQUCA8IDIuMDQgaGFzIG5vIHN5bWxpbmtzOyBgbG4gLXMn
IGNyZWF0ZXMgYSB3cmFwcGVyIGV4ZWN1dGFibGUuCisgICAgIyBJbiBib3RoIGNhc2VzLCB3ZSBo
YXZlIHRvIGRlZmF1bHQgdG8gYGNwIC1wJy4KKyAgICBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQu
ZGlyIDI+L2Rldi9udWxsICYmIHRlc3QgISAtZiBjb25mJCQuZXhlIHx8CisgICAgICBhc19sbl9z
PSdjcCAtcCcKKyAgZWxpZiBsbiBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4K
KyAgICBhc19sbl9zPWxuCisgIGVsc2UKKyAgICBhc19sbl9zPSdjcCAtcCcKKyAgZmkKK2Vsc2UK
KyAgYXNfbG5fcz0nY3AgLXAnCitmaQorcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmRp
ci9jb25mJCQuZmlsZSBjb25mJCQuZmlsZQorcm1kaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAor
CitpZiBta2RpciAtcCAuIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX21rZGlyX3A9J21rZGlyIC1w
ICIkYXNfZGlyIicKK2Vsc2UKKyAgdGVzdCAtZCAuLy1wICYmIHJtZGlyIC4vLXAKKyAgYXNfbWtk
aXJfcD1mYWxzZQorZmkKKworaWYgdGVzdCAteCAvID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBh
c190ZXN0X3g9J3Rlc3QgLXgnCitlbHNlCisgIGlmIGxzIC1kTCAvID4vZGV2L251bGwgMj4mMTsg
dGhlbgorICAgIGFzX2xzX0xfb3B0aW9uPUwKKyAgZWxzZQorICAgIGFzX2xzX0xfb3B0aW9uPQor
ICBmaQorICBhc190ZXN0X3g9JworICAgIGV2YWwgc2ggLWMgJ1wnJworICAgICAgaWYgdGVzdCAt
ZCAiJDEiOyB0aGVuCisJdGVzdCAtZCAiJDEvLiI7CisgICAgICBlbHNlCisJY2FzZSAkMSBpbiAj
KAorCS0qKXNldCAiLi8kMSI7OworCWVzYWM7CisJY2FzZSBgbHMgLWxkJyRhc19sc19MX29wdGlv
bicgIiQxIiAyPi9kZXYvbnVsbGAgaW4gIygoCisJPz8/W3N4XSopOjs7KilmYWxzZTs7ZXNhYztm
aQorICAgICdcJycgc2gKKyAgJworZmkKK2FzX2V4ZWN1dGFibGVfcD0kYXNfdGVzdF94CisKKyMg
U2VkIGV4cHJlc3Npb24gdG8gbWFwIGEgc3RyaW5nIG9udG8gYSB2YWxpZCBDUFAgbmFtZS4KK2Fz
X3RyX2NwcD0iZXZhbCBzZWQgJ3klKiRhc19jcl9sZXR0ZXJzJVAkYXNfY3JfTEVUVEVSUyU7cyVb
Xl8kYXNfY3JfYWxudW1dJV8lZyciCisKKyMgU2VkIGV4cHJlc3Npb24gdG8gbWFwIGEgc3RyaW5n
IG9udG8gYSB2YWxpZCB2YXJpYWJsZSBuYW1lLgorYXNfdHJfc2g9ImV2YWwgc2VkICd5JSorJXBw
JTtzJVteXyRhc19jcl9hbG51bV0lXyVnJyIKKworCit0ZXN0IC1uICIkREpESVIiIHx8IGV4ZWMg
NzwmMCA8L2Rldi9udWxsCitleGVjIDY+JjEKKworIyBOYW1lIG9mIHRoZSBob3N0LgorIyBob3N0
bmFtZSBvbiBzb21lIHN5c3RlbXMgKFNWUjMuMiwgb2xkIEdOVS9MaW51eCkgcmV0dXJucyBhIGJv
Z3VzIGV4aXQgc3RhdHVzLAorIyBzbyB1bmFtZSBnZXRzIHJ1biB0b28uCithY19ob3N0bmFtZT1g
KGhvc3RuYW1lIHx8IHVuYW1lIC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKKworIworIyBJbml0
aWFsaXphdGlvbnMuCisjCithY19kZWZhdWx0X3ByZWZpeD0vdXNyL2xvY2FsCithY19jbGVhbl9m
aWxlcz0KK2FjX2NvbmZpZ19saWJvYmpfZGlyPS4KK0xJQk9CSlM9Citjcm9zc19jb21waWxpbmc9
bm8KK3N1YmRpcnM9CitNRkxBR1M9CitNQUtFRkxBR1M9CisKKyMgSWRlbnRpdHkgb2YgdGhpcyBw
YWNrYWdlLgorUEFDS0FHRV9OQU1FPQorUEFDS0FHRV9UQVJOQU1FPQorUEFDS0FHRV9WRVJTSU9O
PQorUEFDS0FHRV9TVFJJTkc9CitQQUNLQUdFX0JVR1JFUE9SVD0KK1BBQ0tBR0VfVVJMPQorCith
Y191bmlxdWVfZmlsZT0iWGVuIEh5cGVydmlzb3IiCithY191bmlxdWVfZmlsZT0ibGlieGwvbGli
eGwuYyIKK2FjX2RlZmF1bHRfcHJlZml4PS91c3IKKyMgRmFjdG9yaW5nIGRlZmF1bHQgaGVhZGVy
cyBmb3IgbW9zdCB0ZXN0cy4KK2FjX2luY2x1ZGVzX2RlZmF1bHQ9IlwKKyNpbmNsdWRlIDxzdGRp
by5oPgorI2lmZGVmIEhBVkVfU1lTX1RZUEVTX0gKKyMgaW5jbHVkZSA8c3lzL3R5cGVzLmg+Cisj
ZW5kaWYKKyNpZmRlZiBIQVZFX1NZU19TVEFUX0gKKyMgaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNl
bmRpZgorI2lmZGVmIFNURENfSEVBREVSUworIyBpbmNsdWRlIDxzdGRsaWIuaD4KKyMgaW5jbHVk
ZSA8c3RkZGVmLmg+CisjZWxzZQorIyBpZmRlZiBIQVZFX1NURExJQl9ICisjICBpbmNsdWRlIDxz
dGRsaWIuaD4KKyMgZW5kaWYKKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RSSU5HX0gKKyMgaWYgIWRl
ZmluZWQgU1REQ19IRUFERVJTICYmIGRlZmluZWQgSEFWRV9NRU1PUllfSAorIyAgaW5jbHVkZSA8
bWVtb3J5Lmg+CisjIGVuZGlmCisjIGluY2x1ZGUgPHN0cmluZy5oPgorI2VuZGlmCisjaWZkZWYg
SEFWRV9TVFJJTkdTX0gKKyMgaW5jbHVkZSA8c3RyaW5ncy5oPgorI2VuZGlmCisjaWZkZWYgSEFW
RV9JTlRUWVBFU19ICisjIGluY2x1ZGUgPGludHR5cGVzLmg+CisjZW5kaWYKKyNpZmRlZiBIQVZF
X1NURElOVF9ICisjIGluY2x1ZGUgPHN0ZGludC5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9VTklT
VERfSAorIyBpbmNsdWRlIDx1bmlzdGQuaD4KKyNlbmRpZiIKKworYWNfaGVhZGVyX2xpc3Q9Cith
Y19mdW5jX2xpc3Q9CithY19zdWJzdF92YXJzPSdMVExJQk9CSlMKK1BPV19MSUIKK0xJQk9CSlMK
K0FMTE9DQQorbGliaWNvbnYKK2xpYmdjcnlwdAorbGliZXh0MmZzCitzeXN0ZW1fYWlvCitMSUJf
UEFUSAorVk5DT05GSUcKK0hPVFBMVUcKK1VERVZJTkZPCitVREVWQURNCitQWVRIT05QQVRICitP
Q0FNTEJVSUxECitPQ0FNTERPQworT0NBTUxNS0xJQgorT0NBTUxNS1RPUAorT0NBTUxERVAKK09D
QU1MCitPQ0FNTE9QVERPVE9QVAorT0NBTUxDRE9UT1BUCitPQ0FNTEJFU1QKK09DQU1MT1BUCitP
Q0FNTExJQgorT0NBTUxWRVJTSU9OCitPQ0FNTEMKK0lOU1RBTExfREFUQQorSU5TVEFMTF9TQ1JJ
UFQKK0lOU1RBTExfUFJPR1JBTQorU0VUX01BS0UKK0xOX1MKK1NFRAorWEdFVFRFWFQKK0JBU0gK
K1hNTAorQ1VSTAorRkxFWAorQklTT04KK0lQCitCUkNUTAorUEVSTAorUFlUSE9OCitBUFBFTkRf
TElCCitBUFBFTkRfSU5DTFVERVMKK1BSRVBFTkRfTElCCitQUkVQRU5EX0lOQ0xVREVTCitkZWJ1
ZworbG9tb3VudAorbWluaXRlcm0KK29jYW1sdG9vbHMKK3B5dGhvbnRvb2xzCit4YXBpCit2dHBt
Cittb25pdG9ycworZ2l0aHR0cAoreHNtCitob3N0X29zCitob3N0X3ZlbmRvcgoraG9zdF9jcHUK
K2hvc3QKK2J1aWxkX29zCitidWlsZF92ZW5kb3IKK2J1aWxkX2NwdQorYnVpbGQKK0VHUkVQCitH
UkVQCitDUFAKK09CSkVYVAorRVhFRVhUCithY19jdF9DQworQ1BQRkxBR1MKK0xERkxBR1MKK0NG
TEFHUworQ0MKK3RhcmdldF9hbGlhcworaG9zdF9hbGlhcworYnVpbGRfYWxpYXMKK0xJQlMKK0VD
SE9fVAorRUNIT19OCitFQ0hPX0MKK0RFRlMKK21hbmRpcgorbG9jYWxlZGlyCitsaWJkaXIKK3Bz
ZGlyCitwZGZkaXIKK2R2aWRpcgoraHRtbGRpcgoraW5mb2RpcgorZG9jZGlyCitvbGRpbmNsdWRl
ZGlyCitpbmNsdWRlZGlyCitsb2NhbHN0YXRlZGlyCitzaGFyZWRzdGF0ZWRpcgorc3lzY29uZmRp
cgorZGF0YWRpcgorZGF0YXJvb3RkaXIKK2xpYmV4ZWNkaXIKK3NiaW5kaXIKK2JpbmRpcgorcHJv
Z3JhbV90cmFuc2Zvcm1fbmFtZQorcHJlZml4CitleGVjX3ByZWZpeAorUEFDS0FHRV9VUkwKK1BB
Q0tBR0VfQlVHUkVQT1JUCitQQUNLQUdFX1NUUklORworUEFDS0FHRV9WRVJTSU9OCitQQUNLQUdF
X1RBUk5BTUUKK1BBQ0tBR0VfTkFNRQorUEFUSF9TRVBBUkFUT1IKK1NIRUxMJworYWNfc3Vic3Rf
ZmlsZXM9JycKK2FjX3VzZXJfb3B0cz0nCitlbmFibGVfb3B0aW9uX2NoZWNraW5nCitlbmFibGVf
eHNtCitlbmFibGVfZ2l0aHR0cAorZW5hYmxlX21vbml0b3JzCitlbmFibGVfdnRwbQorZW5hYmxl
X3hhcGkKK2VuYWJsZV9weXRob250b29scworZW5hYmxlX29jYW1sdG9vbHMKK2VuYWJsZV9taW5p
dGVybQorZW5hYmxlX2xvbW91bnQKK2VuYWJsZV9kZWJ1ZworJworICAgICAgYWNfcHJlY2lvdXNf
dmFycz0nYnVpbGRfYWxpYXMKK2hvc3RfYWxpYXMKK3RhcmdldF9hbGlhcworQ0MKK0NGTEFHUwor
TERGTEFHUworTElCUworQ1BQRkxBR1MKK0NQUAorUFJFUEVORF9JTkNMVURFUworUFJFUEVORF9M
SUIKK0FQUEVORF9JTkNMVURFUworQVBQRU5EX0xJQgorUFlUSE9OCitQRVJMCitCUkNUTAorSVAK
K0JJU09OCitGTEVYCitDVVJMCitYTUwKK0JBU0gKK1hHRVRURVhUJworCisKKyMgSW5pdGlhbGl6
ZSBzb21lIHZhcmlhYmxlcyBzZXQgYnkgb3B0aW9ucy4KK2FjX2luaXRfaGVscD0KK2FjX2luaXRf
dmVyc2lvbj1mYWxzZQorYWNfdW5yZWNvZ25pemVkX29wdHM9CithY191bnJlY29nbml6ZWRfc2Vw
PQorIyBUaGUgdmFyaWFibGVzIGhhdmUgdGhlIHNhbWUgbmFtZXMgYXMgdGhlIG9wdGlvbnMsIHdp
dGgKKyMgZGFzaGVzIGNoYW5nZWQgdG8gdW5kZXJsaW5lcy4KK2NhY2hlX2ZpbGU9L2Rldi9udWxs
CitleGVjX3ByZWZpeD1OT05FCitub19jcmVhdGU9Citub19yZWN1cnNpb249CitwcmVmaXg9Tk9O
RQorcHJvZ3JhbV9wcmVmaXg9Tk9ORQorcHJvZ3JhbV9zdWZmaXg9Tk9ORQorcHJvZ3JhbV90cmFu
c2Zvcm1fbmFtZT1zLHgseCwKK3NpbGVudD0KK3NpdGU9CitzcmNkaXI9Cit2ZXJib3NlPQoreF9p
bmNsdWRlcz1OT05FCit4X2xpYnJhcmllcz1OT05FCisKKyMgSW5zdGFsbGF0aW9uIGRpcmVjdG9y
eSBvcHRpb25zLgorIyBUaGVzZSBhcmUgbGVmdCB1bmV4cGFuZGVkIHNvIHVzZXJzIGNhbiAibWFr
ZSBpbnN0YWxsIGV4ZWNfcHJlZml4PS9mb28iCisjIGFuZCBhbGwgdGhlIHZhcmlhYmxlcyB0aGF0
IGFyZSBzdXBwb3NlZCB0byBiZSBiYXNlZCBvbiBleGVjX3ByZWZpeAorIyBieSBkZWZhdWx0IHdp
bGwgYWN0dWFsbHkgY2hhbmdlLgorIyBVc2UgYnJhY2VzIGluc3RlYWQgb2YgcGFyZW5zIGJlY2F1
c2Ugc2gsIHBlcmwsIGV0Yy4gYWxzbyBhY2NlcHQgdGhlbS4KKyMgKFRoZSBsaXN0IGZvbGxvd3Mg
dGhlIHNhbWUgb3JkZXIgYXMgdGhlIEdOVSBDb2RpbmcgU3RhbmRhcmRzLikKK2JpbmRpcj0nJHtl
eGVjX3ByZWZpeH0vYmluJworc2JpbmRpcj0nJHtleGVjX3ByZWZpeH0vc2JpbicKK2xpYmV4ZWNk
aXI9JyR7ZXhlY19wcmVmaXh9L2xpYmV4ZWMnCitkYXRhcm9vdGRpcj0nJHtwcmVmaXh9L3NoYXJl
JworZGF0YWRpcj0nJHtkYXRhcm9vdGRpcn0nCitzeXNjb25mZGlyPScke3ByZWZpeH0vZXRjJwor
c2hhcmVkc3RhdGVkaXI9JyR7cHJlZml4fS9jb20nCitsb2NhbHN0YXRlZGlyPScke3ByZWZpeH0v
dmFyJworaW5jbHVkZWRpcj0nJHtwcmVmaXh9L2luY2x1ZGUnCitvbGRpbmNsdWRlZGlyPScvdXNy
L2luY2x1ZGUnCitkb2NkaXI9JyR7ZGF0YXJvb3RkaXJ9L2RvYy8ke1BBQ0tBR0V9JworaW5mb2Rp
cj0nJHtkYXRhcm9vdGRpcn0vaW5mbycKK2h0bWxkaXI9JyR7ZG9jZGlyfScKK2R2aWRpcj0nJHtk
b2NkaXJ9JworcGRmZGlyPScke2RvY2Rpcn0nCitwc2Rpcj0nJHtkb2NkaXJ9JworbGliZGlyPSck
e2V4ZWNfcHJlZml4fS9saWInCitsb2NhbGVkaXI9JyR7ZGF0YXJvb3RkaXJ9L2xvY2FsZScKK21h
bmRpcj0nJHtkYXRhcm9vdGRpcn0vbWFuJworCithY19wcmV2PQorYWNfZGFzaGRhc2g9Citmb3Ig
YWNfb3B0aW9uCitkbworICAjIElmIHRoZSBwcmV2aW91cyBvcHRpb24gbmVlZHMgYW4gYXJndW1l
bnQsIGFzc2lnbiBpdC4KKyAgaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgICAgZXZhbCAk
YWNfcHJldj1cJGFjX29wdGlvbgorICAgIGFjX3ByZXY9CisgICAgY29udGludWUKKyAgZmkKKwor
ICBjYXNlICRhY19vcHRpb24gaW4KKyAgKj0/KikgYWNfb3B0YXJnPWBleHByICJYJGFjX29wdGlv
biIgOiAnW149XSo9XCguKlwpJ2AgOzsKKyAgKj0pICAgYWNfb3B0YXJnPSA7OworICAqKSAgICBh
Y19vcHRhcmc9eWVzIDs7CisgIGVzYWMKKworICAjIEFjY2VwdCB0aGUgaW1wb3J0YW50IEN5Z251
cyBjb25maWd1cmUgb3B0aW9ucywgc28gd2UgY2FuIGRpYWdub3NlIHR5cG9zLgorCisgIGNhc2Ug
JGFjX2Rhc2hkYXNoJGFjX29wdGlvbiBpbgorICAtLSkKKyAgICBhY19kYXNoZGFzaD15ZXMgOzsK
KworICAtYmluZGlyIHwgLS1iaW5kaXIgfCAtLWJpbmRpIHwgLS1iaW5kIHwgLS1iaW4gfCAtLWJp
KQorICAgIGFjX3ByZXY9YmluZGlyIDs7CisgIC1iaW5kaXI9KiB8IC0tYmluZGlyPSogfCAtLWJp
bmRpPSogfCAtLWJpbmQ9KiB8IC0tYmluPSogfCAtLWJpPSopCisgICAgYmluZGlyPSRhY19vcHRh
cmcgOzsKKworICAtYnVpbGQgfCAtLWJ1aWxkIHwgLS1idWlsIHwgLS1idWkgfCAtLWJ1KQorICAg
IGFjX3ByZXY9YnVpbGRfYWxpYXMgOzsKKyAgLWJ1aWxkPSogfCAtLWJ1aWxkPSogfCAtLWJ1aWw9
KiB8IC0tYnVpPSogfCAtLWJ1PSopCisgICAgYnVpbGRfYWxpYXM9JGFjX29wdGFyZyA7OworCisg
IC1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWwgfCAtLWNhY2hlLWZpIFwK
KyAgfCAtLWNhY2hlLWYgfCAtLWNhY2hlLSB8IC0tY2FjaGUgfCAtLWNhY2ggfCAtLWNhYyB8IC0t
Y2EgfCAtLWMpCisgICAgYWNfcHJldj1jYWNoZV9maWxlIDs7CisgIC1jYWNoZS1maWxlPSogfCAt
LWNhY2hlLWZpbGU9KiB8IC0tY2FjaGUtZmlsPSogfCAtLWNhY2hlLWZpPSogXAorICB8IC0tY2Fj
aGUtZj0qIHwgLS1jYWNoZS09KiB8IC0tY2FjaGU9KiB8IC0tY2FjaD0qIHwgLS1jYWM9KiB8IC0t
Y2E9KiB8IC0tYz0qKQorICAgIGNhY2hlX2ZpbGU9JGFjX29wdGFyZyA7OworCisgIC0tY29uZmln
LWNhY2hlIHwgLUMpCisgICAgY2FjaGVfZmlsZT1jb25maWcuY2FjaGUgOzsKKworICAtZGF0YWRp
ciB8IC0tZGF0YWRpciB8IC0tZGF0YWRpIHwgLS1kYXRhZCkKKyAgICBhY19wcmV2PWRhdGFkaXIg
OzsKKyAgLWRhdGFkaXI9KiB8IC0tZGF0YWRpcj0qIHwgLS1kYXRhZGk9KiB8IC0tZGF0YWQ9KikK
KyAgICBkYXRhZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGF0YXJvb3RkaXIgfCAtLWRhdGFyb290
ZGlyIHwgLS1kYXRhcm9vdGRpIHwgLS1kYXRhcm9vdGQgfCAtLWRhdGFyb290IFwKKyAgfCAtLWRh
dGFyb28gfCAtLWRhdGFybyB8IC0tZGF0YXIpCisgICAgYWNfcHJldj1kYXRhcm9vdGRpciA7Owor
ICAtZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaT0qIHwgLS1k
YXRhcm9vdGQ9KiBcCisgIHwgLS1kYXRhcm9vdD0qIHwgLS1kYXRhcm9vPSogfCAtLWRhdGFybz0q
IHwgLS1kYXRhcj0qKQorICAgIGRhdGFyb290ZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGlzYWJs
ZS0qIHwgLS1kaXNhYmxlLSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19vcHRpb24iIDog
J3gtKmRpc2FibGUtXCguKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFs
aWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlte
LSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJp
bnZhbGlkIGZlYXR1cmUgbmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRh
Y191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAn
cy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFi
bGVfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIk
YWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZGlzYWJsZS0kYWNfdXNl
cm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVzYWMKKyAgICBl
dmFsIGVuYWJsZV8kYWNfdXNlcm9wdD1ubyA7OworCisgIC1kb2NkaXIgfCAtLWRvY2RpciB8IC0t
ZG9jZGkgfCAtLWRvYyB8IC0tZG8pCisgICAgYWNfcHJldj1kb2NkaXIgOzsKKyAgLWRvY2Rpcj0q
IHwgLS1kb2NkaXI9KiB8IC0tZG9jZGk9KiB8IC0tZG9jPSogfCAtLWRvPSopCisgICAgZG9jZGly
PSRhY19vcHRhcmcgOzsKKworICAtZHZpZGlyIHwgLS1kdmlkaXIgfCAtLWR2aWRpIHwgLS1kdmlk
IHwgLS1kdmkgfCAtLWR2KQorICAgIGFjX3ByZXY9ZHZpZGlyIDs7CisgIC1kdmlkaXI9KiB8IC0t
ZHZpZGlyPSogfCAtLWR2aWRpPSogfCAtLWR2aWQ9KiB8IC0tZHZpPSogfCAtLWR2PSopCisgICAg
ZHZpZGlyPSRhY19vcHRhcmcgOzsKKworICAtZW5hYmxlLSogfCAtLWVuYWJsZS0qKQorICAgIGFj
X3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSplbmFibGUtXChbXj1dKlwpJ2AKKyAg
ICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMu
CisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2
L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUgbmFtZTogJGFj
X3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9w
dD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2Ug
JGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQiCisiKikgOzsK
KyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVkX29wdHMkYWNf
dW5yZWNvZ25pemVkX3NlcC0tZW5hYmxlLSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2du
aXplZF9zZXA9JywgJzs7CisgICAgZXNhYworICAgIGV2YWwgZW5hYmxlXyRhY191c2Vyb3B0PVwk
YWNfb3B0YXJnIDs7CisKKyAgLWV4ZWMtcHJlZml4IHwgLS1leGVjX3ByZWZpeCB8IC0tZXhlYy1w
cmVmaXggfCAtLWV4ZWMtcHJlZmkgXAorICB8IC0tZXhlYy1wcmVmIHwgLS1leGVjLXByZSB8IC0t
ZXhlYy1wciB8IC0tZXhlYy1wIHwgLS1leGVjLSBcCisgIHwgLS1leGVjIHwgLS1leGUgfCAtLWV4
KQorICAgIGFjX3ByZXY9ZXhlY19wcmVmaXggOzsKKyAgLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWNf
cHJlZml4PSogfCAtLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWMtcHJlZmk9KiBcCisgIHwgLS1leGVj
LXByZWY9KiB8IC0tZXhlYy1wcmU9KiB8IC0tZXhlYy1wcj0qIHwgLS1leGVjLXA9KiB8IC0tZXhl
Yy09KiBcCisgIHwgLS1leGVjPSogfCAtLWV4ZT0qIHwgLS1leD0qKQorICAgIGV4ZWNfcHJlZml4
PSRhY19vcHRhcmcgOzsKKworICAtZ2FzIHwgLS1nYXMgfCAtLWdhIHwgLS1nKQorICAgICMgT2Jz
b2xldGU7IHVzZSAtLXdpdGgtZ2FzLgorICAgIHdpdGhfZ2FzPXllcyA7OworCisgIC1oZWxwIHwg
LS1oZWxwIHwgLS1oZWwgfCAtLWhlIHwgLWgpCisgICAgYWNfaW5pdF9oZWxwPWxvbmcgOzsKKyAg
LWhlbHA9ciogfCAtLWhlbHA9ciogfCAtLWhlbD1yKiB8IC0taGU9ciogfCAtaHIqKQorICAgIGFj
X2luaXRfaGVscD1yZWN1cnNpdmUgOzsKKyAgLWhlbHA9cyogfCAtLWhlbHA9cyogfCAtLWhlbD1z
KiB8IC0taGU9cyogfCAtaHMqKQorICAgIGFjX2luaXRfaGVscD1zaG9ydCA7OworCisgIC1ob3N0
IHwgLS1ob3N0IHwgLS1ob3MgfCAtLWhvKQorICAgIGFjX3ByZXY9aG9zdF9hbGlhcyA7OworICAt
aG9zdD0qIHwgLS1ob3N0PSogfCAtLWhvcz0qIHwgLS1obz0qKQorICAgIGhvc3RfYWxpYXM9JGFj
X29wdGFyZyA7OworCisgIC1odG1sZGlyIHwgLS1odG1sZGlyIHwgLS1odG1sZGkgfCAtLWh0bWxk
IHwgLS1odG1sIHwgLS1odG0gfCAtLWh0KQorICAgIGFjX3ByZXY9aHRtbGRpciA7OworICAtaHRt
bGRpcj0qIHwgLS1odG1sZGlyPSogfCAtLWh0bWxkaT0qIHwgLS1odG1sZD0qIHwgLS1odG1sPSog
fCAtLWh0bT0qIFwKKyAgfCAtLWh0PSopCisgICAgaHRtbGRpcj0kYWNfb3B0YXJnIDs7CisKKyAg
LWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaSB8IC0taW5jbHVkZWQgfCAt
LWluY2x1ZGUgXAorICB8IC0taW5jbHVkIHwgLS1pbmNsdSB8IC0taW5jbCB8IC0taW5jKQorICAg
IGFjX3ByZXY9aW5jbHVkZWRpciA7OworICAtaW5jbHVkZWRpcj0qIHwgLS1pbmNsdWRlZGlyPSog
fCAtLWluY2x1ZGVkaT0qIHwgLS1pbmNsdWRlZD0qIHwgLS1pbmNsdWRlPSogXAorICB8IC0taW5j
bHVkPSogfCAtLWluY2x1PSogfCAtLWluY2w9KiB8IC0taW5jPSopCisgICAgaW5jbHVkZWRpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLWluZm9kaXIgfCAtLWluZm9kaXIgfCAtLWluZm9kaSB8IC0taW5m
b2QgfCAtLWluZm8gfCAtLWluZikKKyAgICBhY19wcmV2PWluZm9kaXIgOzsKKyAgLWluZm9kaXI9
KiB8IC0taW5mb2Rpcj0qIHwgLS1pbmZvZGk9KiB8IC0taW5mb2Q9KiB8IC0taW5mbz0qIHwgLS1p
bmY9KikKKyAgICBpbmZvZGlyPSRhY19vcHRhcmcgOzsKKworICAtbGliZGlyIHwgLS1saWJkaXIg
fCAtLWxpYmRpIHwgLS1saWJkKQorICAgIGFjX3ByZXY9bGliZGlyIDs7CisgIC1saWJkaXI9KiB8
IC0tbGliZGlyPSogfCAtLWxpYmRpPSogfCAtLWxpYmQ9KikKKyAgICBsaWJkaXI9JGFjX29wdGFy
ZyA7OworCisgIC1saWJleGVjZGlyIHwgLS1saWJleGVjZGlyIHwgLS1saWJleGVjZGkgfCAtLWxp
YmV4ZWNkIHwgLS1saWJleGVjIFwKKyAgfCAtLWxpYmV4ZSB8IC0tbGliZXggfCAtLWxpYmUpCisg
ICAgYWNfcHJldj1saWJleGVjZGlyIDs7CisgIC1saWJleGVjZGlyPSogfCAtLWxpYmV4ZWNkaXI9
KiB8IC0tbGliZXhlY2RpPSogfCAtLWxpYmV4ZWNkPSogfCAtLWxpYmV4ZWM9KiBcCisgIHwgLS1s
aWJleGU9KiB8IC0tbGliZXg9KiB8IC0tbGliZT0qKQorICAgIGxpYmV4ZWNkaXI9JGFjX29wdGFy
ZyA7OworCisgIC1sb2NhbGVkaXIgfCAtLWxvY2FsZWRpciB8IC0tbG9jYWxlZGkgfCAtLWxvY2Fs
ZWQgfCAtLWxvY2FsZSkKKyAgICBhY19wcmV2PWxvY2FsZWRpciA7OworICAtbG9jYWxlZGlyPSog
fCAtLWxvY2FsZWRpcj0qIHwgLS1sb2NhbGVkaT0qIHwgLS1sb2NhbGVkPSogfCAtLWxvY2FsZT0q
KQorICAgIGxvY2FsZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWxvY2Fsc3RhdGVkaXIgfCAtLWxv
Y2Fsc3RhdGVkaXIgfCAtLWxvY2Fsc3RhdGVkaSB8IC0tbG9jYWxzdGF0ZWQgXAorICB8IC0tbG9j
YWxzdGF0ZSB8IC0tbG9jYWxzdGF0IHwgLS1sb2NhbHN0YSB8IC0tbG9jYWxzdCB8IC0tbG9jYWxz
KQorICAgIGFjX3ByZXY9bG9jYWxzdGF0ZWRpciA7OworICAtbG9jYWxzdGF0ZWRpcj0qIHwgLS1s
b2NhbHN0YXRlZGlyPSogfCAtLWxvY2Fsc3RhdGVkaT0qIHwgLS1sb2NhbHN0YXRlZD0qIFwKKyAg
fCAtLWxvY2Fsc3RhdGU9KiB8IC0tbG9jYWxzdGF0PSogfCAtLWxvY2Fsc3RhPSogfCAtLWxvY2Fs
c3Q9KiB8IC0tbG9jYWxzPSopCisgICAgbG9jYWxzdGF0ZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAg
LW1hbmRpciB8IC0tbWFuZGlyIHwgLS1tYW5kaSB8IC0tbWFuZCB8IC0tbWFuIHwgLS1tYSB8IC0t
bSkKKyAgICBhY19wcmV2PW1hbmRpciA7OworICAtbWFuZGlyPSogfCAtLW1hbmRpcj0qIHwgLS1t
YW5kaT0qIHwgLS1tYW5kPSogfCAtLW1hbj0qIHwgLS1tYT0qIHwgLS1tPSopCisgICAgbWFuZGly
PSRhY19vcHRhcmcgOzsKKworICAtbmZwIHwgLS1uZnAgfCAtLW5mKQorICAgICMgT2Jzb2xldGU7
IHVzZSAtLXdpdGhvdXQtZnAuCisgICAgd2l0aF9mcD1ubyA7OworCisgIC1uby1jcmVhdGUgfCAt
LW5vLWNyZWF0ZSB8IC0tbm8tY3JlYXQgfCAtLW5vLWNyZWEgfCAtLW5vLWNyZSBcCisgIHwgLS1u
by1jciB8IC0tbm8tYyB8IC1uKQorICAgIG5vX2NyZWF0ZT15ZXMgOzsKKworICAtbm8tcmVjdXJz
aW9uIHwgLS1uby1yZWN1cnNpb24gfCAtLW5vLXJlY3Vyc2lvIHwgLS1uby1yZWN1cnNpIFwKKyAg
fCAtLW5vLXJlY3VycyB8IC0tbm8tcmVjdXIgfCAtLW5vLXJlY3UgfCAtLW5vLXJlYyB8IC0tbm8t
cmUgfCAtLW5vLXIpCisgICAgbm9fcmVjdXJzaW9uPXllcyA7OworCisgIC1vbGRpbmNsdWRlZGly
IHwgLS1vbGRpbmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRlZGkgfCAtLW9sZGluY2x1ZGVkIFwKKyAg
fCAtLW9sZGluY2x1ZGUgfCAtLW9sZGluY2x1ZCB8IC0tb2xkaW5jbHUgfCAtLW9sZGluY2wgfCAt
LW9sZGluYyBcCisgIHwgLS1vbGRpbiB8IC0tb2xkaSB8IC0tb2xkIHwgLS1vbCB8IC0tbykKKyAg
ICBhY19wcmV2PW9sZGluY2x1ZGVkaXIgOzsKKyAgLW9sZGluY2x1ZGVkaXI9KiB8IC0tb2xkaW5j
bHVkZWRpcj0qIHwgLS1vbGRpbmNsdWRlZGk9KiB8IC0tb2xkaW5jbHVkZWQ9KiBcCisgIHwgLS1v
bGRpbmNsdWRlPSogfCAtLW9sZGluY2x1ZD0qIHwgLS1vbGRpbmNsdT0qIHwgLS1vbGRpbmNsPSog
fCAtLW9sZGluYz0qIFwKKyAgfCAtLW9sZGluPSogfCAtLW9sZGk9KiB8IC0tb2xkPSogfCAtLW9s
PSogfCAtLW89KikKKyAgICBvbGRpbmNsdWRlZGlyPSRhY19vcHRhcmcgOzsKKworICAtcHJlZml4
IHwgLS1wcmVmaXggfCAtLXByZWZpIHwgLS1wcmVmIHwgLS1wcmUgfCAtLXByIHwgLS1wKQorICAg
IGFjX3ByZXY9cHJlZml4IDs7CisgIC1wcmVmaXg9KiB8IC0tcHJlZml4PSogfCAtLXByZWZpPSog
fCAtLXByZWY9KiB8IC0tcHJlPSogfCAtLXByPSogfCAtLXA9KikKKyAgICBwcmVmaXg9JGFjX29w
dGFyZyA7OworCisgIC1wcm9ncmFtLXByZWZpeCB8IC0tcHJvZ3JhbS1wcmVmaXggfCAtLXByb2dy
YW0tcHJlZmkgfCAtLXByb2dyYW0tcHJlZiBcCisgIHwgLS1wcm9ncmFtLXByZSB8IC0tcHJvZ3Jh
bS1wciB8IC0tcHJvZ3JhbS1wKQorICAgIGFjX3ByZXY9cHJvZ3JhbV9wcmVmaXggOzsKKyAgLXBy
b2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZmk9KiBc
CisgIHwgLS1wcm9ncmFtLXByZWY9KiB8IC0tcHJvZ3JhbS1wcmU9KiB8IC0tcHJvZ3JhbS1wcj0q
IHwgLS1wcm9ncmFtLXA9KikKKyAgICBwcm9ncmFtX3ByZWZpeD0kYWNfb3B0YXJnIDs7CisKKyAg
LXByb2dyYW0tc3VmZml4IHwgLS1wcm9ncmFtLXN1ZmZpeCB8IC0tcHJvZ3JhbS1zdWZmaSB8IC0t
cHJvZ3JhbS1zdWZmIFwKKyAgfCAtLXByb2dyYW0tc3VmIHwgLS1wcm9ncmFtLXN1IHwgLS1wcm9n
cmFtLXMpCisgICAgYWNfcHJldj1wcm9ncmFtX3N1ZmZpeCA7OworICAtcHJvZ3JhbS1zdWZmaXg9
KiB8IC0tcHJvZ3JhbS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaT0qIFwKKyAgfCAtLXByb2dy
YW0tc3VmZj0qIHwgLS1wcm9ncmFtLXN1Zj0qIHwgLS1wcm9ncmFtLXN1PSogfCAtLXByb2dyYW0t
cz0qKQorICAgIHByb2dyYW1fc3VmZml4PSRhY19vcHRhcmcgOzsKKworICAtcHJvZ3JhbS10cmFu
c2Zvcm0tbmFtZSB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSBcCisgIHwgLS1wcm9ncmFtLXRy
YW5zZm9ybS1uYW0gfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hIFwKKyAgfCAtLXByb2dyYW0tdHJh
bnNmb3JtLW4gfCAtLXByb2dyYW0tdHJhbnNmb3JtLSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9y
bSB8IC0tcHJvZ3JhbS10cmFuc2ZvciBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm8gfCAtLXByb2dy
YW0tdHJhbnNmIFwKKyAgfCAtLXByb2dyYW0tdHJhbnMgfCAtLXByb2dyYW0tdHJhbiBcCisgIHwg
LS1wcm9nci10cmEgfCAtLXByb2dyYW0tdHIgfCAtLXByb2dyYW0tdCkKKyAgICBhY19wcmV2PXBy
b2dyYW1fdHJhbnNmb3JtX25hbWUgOzsKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5hbWU9KiB8IC0t
cHJvZ3JhbS10cmFuc2Zvcm0tbmFtZT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hbT0q
IHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW49
KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tPSogXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm09KiB8
IC0tcHJvZ3JhbS10cmFuc2Zvcj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmbz0qIHwgLS1wcm9n
cmFtLXRyYW5zZj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnM9KiB8IC0tcHJvZ3JhbS10cmFuPSog
XAorICB8IC0tcHJvZ3ItdHJhPSogfCAtLXByb2dyYW0tdHI9KiB8IC0tcHJvZ3JhbS10PSopCisg
ICAgcHJvZ3JhbV90cmFuc2Zvcm1fbmFtZT0kYWNfb3B0YXJnIDs7CisKKyAgLXBkZmRpciB8IC0t
cGRmZGlyIHwgLS1wZGZkaSB8IC0tcGRmZCB8IC0tcGRmIHwgLS1wZCkKKyAgICBhY19wcmV2PXBk
ZmRpciA7OworICAtcGRmZGlyPSogfCAtLXBkZmRpcj0qIHwgLS1wZGZkaT0qIHwgLS1wZGZkPSog
fCAtLXBkZj0qIHwgLS1wZD0qKQorICAgIHBkZmRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXBzZGly
IHwgLS1wc2RpciB8IC0tcHNkaSB8IC0tcHNkIHwgLS1wcykKKyAgICBhY19wcmV2PXBzZGlyIDs7
CisgIC1wc2Rpcj0qIHwgLS1wc2Rpcj0qIHwgLS1wc2RpPSogfCAtLXBzZD0qIHwgLS1wcz0qKQor
ICAgIHBzZGlyPSRhY19vcHRhcmcgOzsKKworICAtcSB8IC1xdWlldCB8IC0tcXVpZXQgfCAtLXF1
aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2ls
ZW4gfCAtLXNpbGUgfCAtLXNpbCkKKyAgICBzaWxlbnQ9eWVzIDs7CisKKyAgLXNiaW5kaXIgfCAt
LXNiaW5kaXIgfCAtLXNiaW5kaSB8IC0tc2JpbmQgfCAtLXNiaW4gfCAtLXNiaSB8IC0tc2IpCisg
ICAgYWNfcHJldj1zYmluZGlyIDs7CisgIC1zYmluZGlyPSogfCAtLXNiaW5kaXI9KiB8IC0tc2Jp
bmRpPSogfCAtLXNiaW5kPSogfCAtLXNiaW49KiBcCisgIHwgLS1zYmk9KiB8IC0tc2I9KikKKyAg
ICBzYmluZGlyPSRhY19vcHRhcmcgOzsKKworICAtc2hhcmVkc3RhdGVkaXIgfCAtLXNoYXJlZHN0
YXRlZGlyIHwgLS1zaGFyZWRzdGF0ZWRpIFwKKyAgfCAtLXNoYXJlZHN0YXRlZCB8IC0tc2hhcmVk
c3RhdGUgfCAtLXNoYXJlZHN0YXQgfCAtLXNoYXJlZHN0YSBcCisgIHwgLS1zaGFyZWRzdCB8IC0t
c2hhcmVkcyB8IC0tc2hhcmVkIHwgLS1zaGFyZSB8IC0tc2hhciBcCisgIHwgLS1zaGEgfCAtLXNo
KQorICAgIGFjX3ByZXY9c2hhcmVkc3RhdGVkaXIgOzsKKyAgLXNoYXJlZHN0YXRlZGlyPSogfCAt
LXNoYXJlZHN0YXRlZGlyPSogfCAtLXNoYXJlZHN0YXRlZGk9KiBcCisgIHwgLS1zaGFyZWRzdGF0
ZWQ9KiB8IC0tc2hhcmVkc3RhdGU9KiB8IC0tc2hhcmVkc3RhdD0qIHwgLS1zaGFyZWRzdGE9KiBc
CisgIHwgLS1zaGFyZWRzdD0qIHwgLS1zaGFyZWRzPSogfCAtLXNoYXJlZD0qIHwgLS1zaGFyZT0q
IHwgLS1zaGFyPSogXAorICB8IC0tc2hhPSogfCAtLXNoPSopCisgICAgc2hhcmVkc3RhdGVkaXI9
JGFjX29wdGFyZyA7OworCisgIC1zaXRlIHwgLS1zaXRlIHwgLS1zaXQpCisgICAgYWNfcHJldj1z
aXRlIDs7CisgIC1zaXRlPSogfCAtLXNpdGU9KiB8IC0tc2l0PSopCisgICAgc2l0ZT0kYWNfb3B0
YXJnIDs7CisKKyAgLXNyY2RpciB8IC0tc3JjZGlyIHwgLS1zcmNkaSB8IC0tc3JjZCB8IC0tc3Jj
IHwgLS1zcikKKyAgICBhY19wcmV2PXNyY2RpciA7OworICAtc3JjZGlyPSogfCAtLXNyY2Rpcj0q
IHwgLS1zcmNkaT0qIHwgLS1zcmNkPSogfCAtLXNyYz0qIHwgLS1zcj0qKQorICAgIHNyY2Rpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZk
aSB8IC0tc3lzY29uZmQgfCAtLXN5c2NvbmYgXAorICB8IC0tc3lzY29uIHwgLS1zeXNjbyB8IC0t
c3lzYyB8IC0tc3lzIHwgLS1zeSkKKyAgICBhY19wcmV2PXN5c2NvbmZkaXIgOzsKKyAgLXN5c2Nv
bmZkaXI9KiB8IC0tc3lzY29uZmRpcj0qIHwgLS1zeXNjb25mZGk9KiB8IC0tc3lzY29uZmQ9KiB8
IC0tc3lzY29uZj0qIFwKKyAgfCAtLXN5c2Nvbj0qIHwgLS1zeXNjbz0qIHwgLS1zeXNjPSogfCAt
LXN5cz0qIHwgLS1zeT0qKQorICAgIHN5c2NvbmZkaXI9JGFjX29wdGFyZyA7OworCisgIC10YXJn
ZXQgfCAtLXRhcmdldCB8IC0tdGFyZ2UgfCAtLXRhcmcgfCAtLXRhciB8IC0tdGEgfCAtLXQpCisg
ICAgYWNfcHJldj10YXJnZXRfYWxpYXMgOzsKKyAgLXRhcmdldD0qIHwgLS10YXJnZXQ9KiB8IC0t
dGFyZ2U9KiB8IC0tdGFyZz0qIHwgLS10YXI9KiB8IC0tdGE9KiB8IC0tdD0qKQorICAgIHRhcmdl
dF9hbGlhcz0kYWNfb3B0YXJnIDs7CisKKyAgLXYgfCAtdmVyYm9zZSB8IC0tdmVyYm9zZSB8IC0t
dmVyYm9zIHwgLS12ZXJibyB8IC0tdmVyYikKKyAgICB2ZXJib3NlPXllcyA7OworCisgIC12ZXJz
aW9uIHwgLS12ZXJzaW9uIHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwgLVYpCisgICAg
YWNfaW5pdF92ZXJzaW9uPTogOzsKKworICAtd2l0aC0qIHwgLS13aXRoLSopCisgICAgYWNfdXNl
cm9wdD1gZXhwciAieCRhY19vcHRpb24iIDogJ3gtKndpdGgtXChbXj1dKlwpJ2AKKyAgICAjIFJl
amVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAg
ZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwg
JiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHBhY2thZ2UgbmFtZTogJGFjX3VzZXJv
cHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFz
X2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3Vz
ZXJfb3B0cyBpbgorICAgICAgKiIKKyJ3aXRoXyRhY191c2Vyb3B0IgorIiopIDs7CisgICAgICAq
KSBhY191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFjX3VucmVjb2du
aXplZF9zZXAtLXdpdGgtJGFjX3VzZXJvcHRfb3JpZyIKKwkgYWNfdW5yZWNvZ25pemVkX3NlcD0n
LCAnOzsKKyAgICBlc2FjCisgICAgZXZhbCB3aXRoXyRhY191c2Vyb3B0PVwkYWNfb3B0YXJnIDs7
CisKKyAgLXdpdGhvdXQtKiB8IC0td2l0aG91dC0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngk
YWNfb3B0aW9uIiA6ICd4LSp3aXRob3V0LVwoLipcKSdgCisgICAgIyBSZWplY3QgbmFtZXMgdGhh
dCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNfdXNl
cm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBhc19m
bl9lcnJvciAkPyAiaW52YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFjX3Vz
ZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNfdXNl
cm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4KKyAg
ICAgICoiCisid2l0aF8kYWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNfdW5yZWNvZ25p
emVkX29wdHM9IiRhY191bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRfc2VwLS13aXRo
b3V0LSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAg
ZXNhYworICAgIGV2YWwgd2l0aF8kYWNfdXNlcm9wdD1ubyA7OworCisgIC0teCkKKyAgICAjIE9i
c29sZXRlOyB1c2UgLS13aXRoLXguCisgICAgd2l0aF94PXllcyA7OworCisgIC14LWluY2x1ZGVz
IHwgLS14LWluY2x1ZGVzIHwgLS14LWluY2x1ZGUgfCAtLXgtaW5jbHVkIHwgLS14LWluY2x1IFwK
KyAgfCAtLXgtaW5jbCB8IC0teC1pbmMgfCAtLXgtaW4gfCAtLXgtaSkKKyAgICBhY19wcmV2PXhf
aW5jbHVkZXMgOzsKKyAgLXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlcz0qIHwgLS14LWluY2x1
ZGU9KiB8IC0teC1pbmNsdWQ9KiB8IC0teC1pbmNsdT0qIFwKKyAgfCAtLXgtaW5jbD0qIHwgLS14
LWluYz0qIHwgLS14LWluPSogfCAtLXgtaT0qKQorICAgIHhfaW5jbHVkZXM9JGFjX29wdGFyZyA7
OworCisgIC14LWxpYnJhcmllcyB8IC0teC1saWJyYXJpZXMgfCAtLXgtbGlicmFyaWUgfCAtLXgt
bGlicmFyaSBcCisgIHwgLS14LWxpYnJhciB8IC0teC1saWJyYSB8IC0teC1saWJyIHwgLS14LWxp
YiB8IC0teC1saSB8IC0teC1sKQorICAgIGFjX3ByZXY9eF9saWJyYXJpZXMgOzsKKyAgLXgtbGli
cmFyaWVzPSogfCAtLXgtbGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWU9KiB8IC0teC1saWJyYXJp
PSogXAorICB8IC0teC1saWJyYXI9KiB8IC0teC1saWJyYT0qIHwgLS14LWxpYnI9KiB8IC0teC1s
aWI9KiB8IC0teC1saT0qIHwgLS14LWw9KikKKyAgICB4X2xpYnJhcmllcz0kYWNfb3B0YXJnIDs7
CisKKyAgLSopIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uOiBcYCRhY19vcHRp
b24nCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uIgorICAgIDs7CisKKyAg
Kj0qKQorICAgIGFjX2VudnZhcj1gZXhwciAieCRhY19vcHRpb24iIDogJ3hcKFtePV0qXCk9J2AK
KyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFt
ZXMuCisgICAgY2FzZSAkYWNfZW52dmFyIGluICMoCisgICAgICAnJyB8IFswLTldKiB8ICpbIV8k
YXNfY3JfYWxudW1dKiApCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YXJpYWJsZSBu
YW1lOiBcYCRhY19lbnZ2YXInIiA7OworICAgIGVzYWMKKyAgICBldmFsICRhY19lbnZ2YXI9XCRh
Y19vcHRhcmcKKyAgICBleHBvcnQgJGFjX2VudnZhciA7OworCisgICopCisgICAgIyBGSVhNRTog
c2hvdWxkIGJlIHJlbW92ZWQgaW4gYXV0b2NvbmYgMy4wLgorICAgICRhc19lY2hvICIkYXNfbWU6
IFdBUk5JTkc6IHlvdSBzaG91bGQgdXNlIC0tYnVpbGQsIC0taG9zdCwgLS10YXJnZXQiID4mMgor
ICAgIGV4cHIgIngkYWNfb3B0aW9uIiA6ICIuKlteLS5fJGFzX2NyX2FsbnVtXSIgPi9kZXYvbnVs
bCAmJgorICAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaW52YWxpZCBob3N0IHR5cGU6
ICRhY19vcHRpb24iID4mMgorICAgIDogJHtidWlsZF9hbGlhcz0kYWNfb3B0aW9ufSAke2hvc3Rf
YWxpYXM9JGFjX29wdGlvbn0gJHt0YXJnZXRfYWxpYXM9JGFjX29wdGlvbn0KKyAgICA7OworCisg
IGVzYWMKK2RvbmUKKworaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgIGFjX29wdGlvbj0t
LWBlY2hvICRhY19wcmV2IHwgc2VkICdzL18vLS9nJ2AKKyAgYXNfZm5fZXJyb3IgJD8gIm1pc3Np
bmcgYXJndW1lbnQgdG8gJGFjX29wdGlvbiIKK2ZpCisKK2lmIHRlc3QgLW4gIiRhY191bnJlY29n
bml6ZWRfb3B0cyI7IHRoZW4KKyAgY2FzZSAkZW5hYmxlX29wdGlvbl9jaGVja2luZyBpbgorICAg
IG5vKSA7OworICAgIGZhdGFsKSBhc19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbnM6
ICRhY191bnJlY29nbml6ZWRfb3B0cyIgOzsKKyAgICAqKSAgICAgJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogdW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYy
IDs7CisgIGVzYWMKK2ZpCisKKyMgQ2hlY2sgYWxsIGRpcmVjdG9yeSBhcmd1bWVudHMgZm9yIGNv
bnNpc3RlbmN5LgorZm9yIGFjX3ZhciBpbglleGVjX3ByZWZpeCBwcmVmaXggYmluZGlyIHNiaW5k
aXIgbGliZXhlY2RpciBkYXRhcm9vdGRpciBcCisJCWRhdGFkaXIgc3lzY29uZmRpciBzaGFyZWRz
dGF0ZWRpciBsb2NhbHN0YXRlZGlyIGluY2x1ZGVkaXIgXAorCQlvbGRpbmNsdWRlZGlyIGRvY2Rp
ciBpbmZvZGlyIGh0bWxkaXIgZHZpZGlyIHBkZmRpciBwc2RpciBcCisJCWxpYmRpciBsb2NhbGVk
aXIgbWFuZGlyCitkbworICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgIyBSZW1vdmUgdHJhaWxp
bmcgc2xhc2hlcy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgKi8gKQorICAgICAgYWNfdmFsPWBl
eHByICJYJGFjX3ZhbCIgOiAnWFwoLipbXi9dXCknIFx8ICJYJGFjX3ZhbCIgOiAnWFwoLipcKSdg
CisgICAgICBldmFsICRhY192YXI9XCRhY192YWw7OworICBlc2FjCisgICMgQmUgc3VyZSB0byBo
YXZlIGFic29sdXRlIGRpcmVjdG9yeSBuYW1lcy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgW1xc
LyRdKiB8ID86W1xcL10qICkgIGNvbnRpbnVlOzsKKyAgICBOT05FIHwgJycgKSBjYXNlICRhY192
YXIgaW4gKnByZWZpeCApIGNvbnRpbnVlOzsgZXNhYzs7CisgIGVzYWMKKyAgYXNfZm5fZXJyb3Ig
JD8gImV4cGVjdGVkIGFuIGFic29sdXRlIGRpcmVjdG9yeSBuYW1lIGZvciAtLSRhY192YXI6ICRh
Y192YWwiCitkb25lCisKKyMgVGhlcmUgbWlnaHQgYmUgcGVvcGxlIHdobyBkZXBlbmQgb24gdGhl
IG9sZCBicm9rZW4gYmVoYXZpb3I6IGAkaG9zdCcKKyMgdXNlZCB0byBob2xkIHRoZSBhcmd1bWVu
dCBvZiAtLWhvc3QgZXRjLgorIyBGSVhNRTogVG8gcmVtb3ZlIHNvbWUgZGF5LgorYnVpbGQ9JGJ1
aWxkX2FsaWFzCitob3N0PSRob3N0X2FsaWFzCit0YXJnZXQ9JHRhcmdldF9hbGlhcworCisjIEZJ
WE1FOiBUbyByZW1vdmUgc29tZSBkYXkuCitpZiB0ZXN0ICJ4JGhvc3RfYWxpYXMiICE9IHg7IHRo
ZW4KKyAgaWYgdGVzdCAieCRidWlsZF9hbGlhcyIgPSB4OyB0aGVuCisgICAgY3Jvc3NfY29tcGls
aW5nPW1heWJlCisgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaWYgeW91IHdhbnRlZCB0
byBzZXQgdGhlIC0tYnVpbGQgdHlwZSwgZG9uJ3QgdXNlIC0taG9zdC4KKyAgICBJZiBhIGNyb3Nz
IGNvbXBpbGVyIGlzIGRldGVjdGVkIHRoZW4gY3Jvc3MgY29tcGlsZSBtb2RlIHdpbGwgYmUgdXNl
ZCIgPiYyCisgIGVsaWYgdGVzdCAieCRidWlsZF9hbGlhcyIgIT0gIngkaG9zdF9hbGlhcyI7IHRo
ZW4KKyAgICBjcm9zc19jb21waWxpbmc9eWVzCisgIGZpCitmaQorCithY190b29sX3ByZWZpeD0K
K3Rlc3QgLW4gIiRob3N0X2FsaWFzIiAmJiBhY190b29sX3ByZWZpeD0kaG9zdF9hbGlhcy0KKwor
dGVzdCAiJHNpbGVudCIgPSB5ZXMgJiYgZXhlYyA2Pi9kZXYvbnVsbAorCisKK2FjX3B3ZD1gcHdk
YCAmJiB0ZXN0IC1uICIkYWNfcHdkIiAmJgorYWNfbHNfZGk9YGxzIC1kaSAuYCAmJgorYWNfcHdk
X2xzX2RpPWBjZCAiJGFjX3B3ZCIgJiYgbHMgLWRpIC5gIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJ3
b3JraW5nIGRpcmVjdG9yeSBjYW5ub3QgYmUgZGV0ZXJtaW5lZCIKK3Rlc3QgIlgkYWNfbHNfZGki
ID0gIlgkYWNfcHdkX2xzX2RpIiB8fAorICBhc19mbl9lcnJvciAkPyAicHdkIGRvZXMgbm90IHJl
cG9ydCBuYW1lIG9mIHdvcmtpbmcgZGlyZWN0b3J5IgorCisKKyMgRmluZCB0aGUgc291cmNlIGZp
bGVzLCBpZiBsb2NhdGlvbiB3YXMgbm90IHNwZWNpZmllZC4KK2lmIHRlc3QgLXogIiRzcmNkaXIi
OyB0aGVuCisgIGFjX3NyY2Rpcl9kZWZhdWx0ZWQ9eWVzCisgICMgVHJ5IHRoZSBkaXJlY3Rvcnkg
Y29udGFpbmluZyB0aGlzIHNjcmlwdCwgdGhlbiB0aGUgcGFyZW50IGRpcmVjdG9yeS4KKyAgYWNf
Y29uZmRpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19teXNlbGYiIHx8CiskYXNfZXhwciBYIiRhc19t
eXNlbGYiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX215c2Vs
ZiIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wpJCcgXHwg
XAorCSBYIiRhc19teXNlbGYiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2Vj
aG8gWCIkYXNfbXlzZWxmIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpc
LyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sK
KwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wx
LworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJ
ICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgc3JjZGlyPSRhY19jb25mZGlyCisgIGlmIHRlc3QgISAt
ciAiJHNyY2Rpci8kYWNfdW5pcXVlX2ZpbGUiOyB0aGVuCisgICAgc3JjZGlyPS4uCisgIGZpCitl
bHNlCisgIGFjX3NyY2Rpcl9kZWZhdWx0ZWQ9bm8KK2ZpCitpZiB0ZXN0ICEgLXIgIiRzcmNkaXIv
JGFjX3VuaXF1ZV9maWxlIjsgdGhlbgorICB0ZXN0ICIkYWNfc3JjZGlyX2RlZmF1bHRlZCIgPSB5
ZXMgJiYgc3JjZGlyPSIkYWNfY29uZmRpciBvciAuLiIKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBmaW5kIHNvdXJjZXMgKCRhY191bmlxdWVfZmlsZSkgaW4gJHNyY2RpciIKK2ZpCithY19tc2c9
InNvdXJjZXMgYXJlIGluICRzcmNkaXIsIGJ1dCBcYGNkICRzcmNkaXInIGRvZXMgbm90IHdvcmsi
CithY19hYnNfY29uZmRpcj1gKAorCWNkICIkc3JjZGlyIiAmJiB0ZXN0IC1yICIuLyRhY191bmlx
dWVfZmlsZSIgfHwgYXNfZm5fZXJyb3IgJD8gIiRhY19tc2ciCisJcHdkKWAKKyMgV2hlbiBidWls
ZGluZyBpbiBwbGFjZSwgc2V0IHNyY2Rpcj0uCitpZiB0ZXN0ICIkYWNfYWJzX2NvbmZkaXIiID0g
IiRhY19wd2QiOyB0aGVuCisgIHNyY2Rpcj0uCitmaQorIyBSZW1vdmUgdW5uZWNlc3NhcnkgdHJh
aWxpbmcgc2xhc2hlcyBmcm9tIHNyY2Rpci4KKyMgRG91YmxlIHNsYXNoZXMgaW4gZmlsZSBuYW1l
cyBpbiBvYmplY3QgZmlsZSBkZWJ1Z2dpbmcgaW5mbworIyBtZXNzIHVwIE0teCBnZGIgaW4gRW1h
Y3MuCitjYXNlICRzcmNkaXIgaW4KKyovKSBzcmNkaXI9YGV4cHIgIlgkc3JjZGlyIiA6ICdYXCgu
KlteL11cKScgXHwgIlgkc3JjZGlyIiA6ICdYXCguKlwpJ2A7OworZXNhYworZm9yIGFjX3ZhciBp
biAkYWNfcHJlY2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19lbnZfJHthY192YXJ9X3NldD1cJHsk
e2FjX3Zhcn0rc2V0fQorICBldmFsIGFjX2Vudl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0K
KyAgZXZhbCBhY19jdl9lbnZfJHthY192YXJ9X3NldD1cJHske2FjX3Zhcn0rc2V0fQorICBldmFs
IGFjX2N2X2Vudl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0KK2RvbmUKKworIworIyBSZXBv
cnQgdGhlIC0taGVscCBtZXNzYWdlLgorIworaWYgdGVzdCAiJGFjX2luaXRfaGVscCIgPSAibG9u
ZyI7IHRoZW4KKyAgIyBPbWl0IHNvbWUgaW50ZXJuYWwgb3Igb2Jzb2xldGUgb3B0aW9ucyB0byBt
YWtlIHRoZSBsaXN0IGxlc3MgaW1wb3NpbmcuCisgICMgVGhpcyBtZXNzYWdlIGlzIHRvbyBsb25n
IHRvIGJlIGEgc3RyaW5nIGluIHRoZSBBL1VYIDMuMSBzaC4KKyAgY2F0IDw8X0FDRU9GCitcYGNv
bmZpZ3VyZScgY29uZmlndXJlcyB0aGlzIHBhY2thZ2UgdG8gYWRhcHQgdG8gbWFueSBraW5kcyBv
ZiBzeXN0ZW1zLgorCitVc2FnZTogJDAgW09QVElPTl0uLi4gW1ZBUj1WQUxVRV0uLi4KKworVG8g
YXNzaWduIGVudmlyb25tZW50IHZhcmlhYmxlcyAoZS5nLiwgQ0MsIENGTEFHUy4uLiksIHNwZWNp
ZnkgdGhlbSBhcworVkFSPVZBTFVFLiAgU2VlIGJlbG93IGZvciBkZXNjcmlwdGlvbnMgb2Ygc29t
ZSBvZiB0aGUgdXNlZnVsIHZhcmlhYmxlcy4KKworRGVmYXVsdHMgZm9yIHRoZSBvcHRpb25zIGFy
ZSBzcGVjaWZpZWQgaW4gYnJhY2tldHMuCisKK0NvbmZpZ3VyYXRpb246CisgIC1oLCAtLWhlbHAg
ICAgICAgICAgICAgIGRpc3BsYXkgdGhpcyBoZWxwIGFuZCBleGl0CisgICAgICAtLWhlbHA9c2hv
cnQgICAgICAgIGRpc3BsYXkgb3B0aW9ucyBzcGVjaWZpYyB0byB0aGlzIHBhY2thZ2UKKyAgICAg
IC0taGVscD1yZWN1cnNpdmUgICAgZGlzcGxheSB0aGUgc2hvcnQgaGVscCBvZiBhbGwgdGhlIGlu
Y2x1ZGVkIHBhY2thZ2VzCisgIC1WLCAtLXZlcnNpb24gICAgICAgICAgIGRpc3BsYXkgdmVyc2lv
biBpbmZvcm1hdGlvbiBhbmQgZXhpdAorICAtcSwgLS1xdWlldCwgLS1zaWxlbnQgICBkbyBub3Qg
cHJpbnQgXGBjaGVja2luZyAuLi4nIG1lc3NhZ2VzCisgICAgICAtLWNhY2hlLWZpbGU9RklMRSAg
IGNhY2hlIHRlc3QgcmVzdWx0cyBpbiBGSUxFIFtkaXNhYmxlZF0KKyAgLUMsIC0tY29uZmlnLWNh
Y2hlICAgICAgYWxpYXMgZm9yIFxgLS1jYWNoZS1maWxlPWNvbmZpZy5jYWNoZScKKyAgLW4sIC0t
bm8tY3JlYXRlICAgICAgICAgZG8gbm90IGNyZWF0ZSBvdXRwdXQgZmlsZXMKKyAgICAgIC0tc3Jj
ZGlyPURJUiAgICAgICAgZmluZCB0aGUgc291cmNlcyBpbiBESVIgW2NvbmZpZ3VyZSBkaXIgb3Ig
XGAuLiddCisKK0luc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1wcmVmaXg9UFJFRklYICAg
ICAgICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtaW5kZXBlbmRlbnQgZmlsZXMgaW4gUFJFRklYCisg
ICAgICAgICAgICAgICAgICAgICAgICAgIFskYWNfZGVmYXVsdF9wcmVmaXhdCisgIC0tZXhlYy1w
cmVmaXg9RVBSRUZJWCAgIGluc3RhbGwgYXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBmaWxlcyBpbiBF
UFJFRklYCisgICAgICAgICAgICAgICAgICAgICAgICAgIFtQUkVGSVhdCisKK0J5IGRlZmF1bHQs
IFxgbWFrZSBpbnN0YWxsJyB3aWxsIGluc3RhbGwgYWxsIHRoZSBmaWxlcyBpbgorXGAkYWNfZGVm
YXVsdF9wcmVmaXgvYmluJywgXGAkYWNfZGVmYXVsdF9wcmVmaXgvbGliJyBldGMuICBZb3UgY2Fu
IHNwZWNpZnkKK2FuIGluc3RhbGxhdGlvbiBwcmVmaXggb3RoZXIgdGhhbiBcYCRhY19kZWZhdWx0
X3ByZWZpeCcgdXNpbmcgXGAtLXByZWZpeCcsCitmb3IgaW5zdGFuY2UgXGAtLXByZWZpeD1cJEhP
TUUnLgorCitGb3IgYmV0dGVyIGNvbnRyb2wsIHVzZSB0aGUgb3B0aW9ucyBiZWxvdy4KKworRmlu
ZSB0dW5pbmcgb2YgdGhlIGluc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1iaW5kaXI9RElS
ICAgICAgICAgICAgdXNlciBleGVjdXRhYmxlcyBbRVBSRUZJWC9iaW5dCisgIC0tc2JpbmRpcj1E
SVIgICAgICAgICAgIHN5c3RlbSBhZG1pbiBleGVjdXRhYmxlcyBbRVBSRUZJWC9zYmluXQorICAt
LWxpYmV4ZWNkaXI9RElSICAgICAgICBwcm9ncmFtIGV4ZWN1dGFibGVzIFtFUFJFRklYL2xpYmV4
ZWNdCisgIC0tc3lzY29uZmRpcj1ESVIgICAgICAgIHJlYWQtb25seSBzaW5nbGUtbWFjaGluZSBk
YXRhIFtQUkVGSVgvZXRjXQorICAtLXNoYXJlZHN0YXRlZGlyPURJUiAgICBtb2RpZmlhYmxlIGFy
Y2hpdGVjdHVyZS1pbmRlcGVuZGVudCBkYXRhIFtQUkVGSVgvY29tXQorICAtLWxvY2Fsc3RhdGVk
aXI9RElSICAgICBtb2RpZmlhYmxlIHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BSRUZJWC92YXJdCisg
IC0tbGliZGlyPURJUiAgICAgICAgICAgIG9iamVjdCBjb2RlIGxpYnJhcmllcyBbRVBSRUZJWC9s
aWJdCisgIC0taW5jbHVkZWRpcj1ESVIgICAgICAgIEMgaGVhZGVyIGZpbGVzIFtQUkVGSVgvaW5j
bHVkZV0KKyAgLS1vbGRpbmNsdWRlZGlyPURJUiAgICAgQyBoZWFkZXIgZmlsZXMgZm9yIG5vbi1n
Y2MgWy91c3IvaW5jbHVkZV0KKyAgLS1kYXRhcm9vdGRpcj1ESVIgICAgICAgcmVhZC1vbmx5IGFy
Y2guLWluZGVwZW5kZW50IGRhdGEgcm9vdCBbUFJFRklYL3NoYXJlXQorICAtLWRhdGFkaXI9RElS
ICAgICAgICAgICByZWFkLW9ubHkgYXJjaGl0ZWN0dXJlLWluZGVwZW5kZW50IGRhdGEgW0RBVEFS
T09URElSXQorICAtLWluZm9kaXI9RElSICAgICAgICAgICBpbmZvIGRvY3VtZW50YXRpb24gW0RB
VEFST09URElSL2luZm9dCisgIC0tbG9jYWxlZGlyPURJUiAgICAgICAgIGxvY2FsZS1kZXBlbmRl
bnQgZGF0YSBbREFUQVJPT1RESVIvbG9jYWxlXQorICAtLW1hbmRpcj1ESVIgICAgICAgICAgICBt
YW4gZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RESVIvbWFuXQorICAtLWRvY2Rpcj1ESVIgICAgICAg
ICAgICBkb2N1bWVudGF0aW9uIHJvb3QgW0RBVEFST09URElSL2RvYy9QQUNLQUdFXQorICAtLWh0
bWxkaXI9RElSICAgICAgICAgICBodG1sIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1kdmlk
aXI9RElSICAgICAgICAgICAgZHZpIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wZGZkaXI9
RElSICAgICAgICAgICAgcGRmIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wc2Rpcj1ESVIg
ICAgICAgICAgICAgcHMgZG9jdW1lbnRhdGlvbiBbRE9DRElSXQorX0FDRU9GCisKKyAgY2F0IDw8
XF9BQ0VPRgorCitTeXN0ZW0gdHlwZXM6CisgIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBm
b3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCisgIC0taG9zdD1IT1NUICAgICAgIGNyb3Nz
LWNvbXBpbGUgdG8gYnVpbGQgcHJvZ3JhbXMgdG8gcnVuIG9uIEhPU1QgW0JVSUxEXQorX0FDRU9G
CitmaQorCitpZiB0ZXN0IC1uICIkYWNfaW5pdF9oZWxwIjsgdGhlbgorCisgIGNhdCA8PFxfQUNF
T0YKKworT3B0aW9uYWwgRmVhdHVyZXM6CisgIC0tZGlzYWJsZS1vcHRpb24tY2hlY2tpbmcgIGln
bm9yZSB1bnJlY29nbml6ZWQgLS1lbmFibGUvLS13aXRoIG9wdGlvbnMKKyAgLS1kaXNhYmxlLUZF
QVRVUkUgICAgICAgZG8gbm90IGluY2x1ZGUgRkVBVFVSRSAoc2FtZSBhcyAtLWVuYWJsZS1GRUFU
VVJFPW5vKQorICAtLWVuYWJsZS1GRUFUVVJFWz1BUkddICBpbmNsdWRlIEZFQVRVUkUgW0FSRz15
ZXNdCisgIC0tZW5hYmxlLXhzbSAgICAgICAgICAgIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxl
IChieSBkZWZhdWx0LCBGbGFzaykKKyAgLS1lbmFibGUtZ2l0aHR0cCAgICAgICAgRG93bmxvYWQg
R0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUAorICAtLWRpc2FibGUtbW9uaXRvcnMgICAgICBEaXNh
YmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzCisgIC0tZW5hYmxlLXZ0cG0g
ICAgICAgICAgIEVuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlCisgIC0tZW5h
YmxlLXhhcGkgICAgICAgICAgIEVuYWJsZSBYZW4gQVBJIEJpbmRpbmdzCisgIC0tZGlzYWJsZS1w
eXRob250b29scyAgIERpc2FibGUgUHl0aG9uIHRvb2xzCisgIC0tZGlzYWJsZS1vY2FtbHRvb2xz
ICAgIERpc2FibGUgT2NhbWwgdG9vbHMKKyAgLS1lbmFibGUtbWluaXRlcm0gICAgICAgRW5hYmxl
IG1pbml0ZXJtCisgIC0tZW5hYmxlLWxvbW91bnQgICAgICAgIEVuYWJsZSBsb21vdW50CisgIC0t
ZGlzYWJsZS1kZWJ1ZyAgICAgICAgIERpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29s
cworCitTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoKKyAgQ0MgICAgICAg
ICAgQyBjb21waWxlciBjb21tYW5kCisgIENGTEFHUyAgICAgIEMgY29tcGlsZXIgZmxhZ3MKKyAg
TERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxp
YnJhcmllcyBpbiBhCisgICAgICAgICAgICAgIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8bGliIGRp
cj4KKyAgTElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8gdGhlIGxpbmtlciwgZS5nLiAt
bDxsaWJyYXJ5PgorICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3Ig
ZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCisgICAgICAgICAgICAgIHlvdSBoYXZlIGhl
YWRlcnMgaW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1ZGUgZGlyPgorICBDUFAgICAg
ICAgICBDIHByZXByb2Nlc3NvcgorICBQUkVQRU5EX0lOQ0xVREVTCisgICAgICAgICAgICAgIExp
c3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQor
ICBQUkVQRU5EX0xJQiBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxB
R1MgKHdpdGhvdXQgLUwpCisgIEFQUEVORF9JTkNMVURFUworICAgICAgICAgICAgICBMaXN0IG9m
IGluY2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQorICBBUFBF
TkRfTElCICBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAod2l0
aG91dCAtTCkKKyAgUFlUSE9OICAgICAgUGF0aCB0byB0aGUgUHl0aG9uIHBhcnNlcgorICBQRVJM
ICAgICAgICBQYXRoIHRvIFBlcmwgcGFyc2VyCisgIEJSQ1RMICAgICAgIFBhdGggdG8gYnJjdGwg
dG9vbAorICBJUCAgICAgICAgICBQYXRoIHRvIGlwIHRvb2wKKyAgQklTT04gICAgICAgUGF0aCB0
byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yCisgIEZMRVggICAgICAgIFBhdGggdG8gRmxleCBsZXhp
Y2FsIGFuYWx5c2VyIGdlbmVyYXRvcgorICBDVVJMICAgICAgICBQYXRoIHRvIGN1cmwtY29uZmln
IHRvb2wKKyAgWE1MICAgICAgICAgUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sCisgIEJBU0ggICAg
ICAgIFBhdGggdG8gYmFzaCBzaGVsbAorICBYR0VUVEVYVCAgICBQYXRoIHRvIHhnZXR0dGV4dCB0
b29sCisKK1VzZSB0aGVzZSB2YXJpYWJsZXMgdG8gb3ZlcnJpZGUgdGhlIGNob2ljZXMgbWFkZSBi
eSBgY29uZmlndXJlJyBvciB0byBoZWxwCitpdCB0byBmaW5kIGxpYnJhcmllcyBhbmQgcHJvZ3Jh
bXMgd2l0aCBub25zdGFuZGFyZCBuYW1lcy9sb2NhdGlvbnMuCisKK1JlcG9ydCBidWdzIHRvIHRo
ZSBwYWNrYWdlIHByb3ZpZGVyLgorX0FDRU9GCithY19zdGF0dXM9JD8KK2ZpCisKK2lmIHRlc3Qg
IiRhY19pbml0X2hlbHAiID0gInJlY3Vyc2l2ZSI7IHRoZW4KKyAgIyBJZiB0aGVyZSBhcmUgc3Vi
ZGlycywgcmVwb3J0IHRoZWlyIHNwZWNpZmljIC0taGVscC4KKyAgZm9yIGFjX2RpciBpbiA6ICRh
Y19zdWJkaXJzX2FsbDsgZG8gdGVzdCAieCRhY19kaXIiID0geDogJiYgY29udGludWUKKyAgICB0
ZXN0IC1kICIkYWNfZGlyIiB8fAorICAgICAgeyBjZCAiJHNyY2RpciIgJiYgYWNfcHdkPWBwd2Rg
ICYmIHNyY2Rpcj0uICYmIHRlc3QgLWQgIiRhY19kaXIiOyB9IHx8CisgICAgICBjb250aW51ZQor
ICAgIGFjX2J1aWxkZGlyPS4KKworY2FzZSAiJGFjX2RpciIgaW4KKy4pIGFjX2Rpcl9zdWZmaXg9
IGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4PSA7OworKikKKyAgYWNf
ZGlyX3N1ZmZpeD0vYCRhc19lY2hvICIkYWNfZGlyIiB8IHNlZCAnc3xeXC5bXFwvXXx8J2AKKyAg
IyBBICIuLiIgZm9yIGVhY2ggZGlyZWN0b3J5IGluICRhY19kaXJfc3VmZml4LgorICBhY190b3Bf
YnVpbGRkaXJfc3ViPWAkYXNfZWNobyAiJGFjX2Rpcl9zdWZmaXgiIHwgc2VkICdzfC9bXlxcL10q
fC8uLnxnO3N8L3x8J2AKKyAgY2FzZSAkYWNfdG9wX2J1aWxkZGlyX3N1YiBpbgorICAiIikgYWNf
dG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7CisgICopICBhY190b3Bf
YnVpbGRfcHJlZml4PSRhY190b3BfYnVpbGRkaXJfc3ViLyA7OworICBlc2FjIDs7Citlc2FjCith
Y19hYnNfdG9wX2J1aWxkZGlyPSRhY19wd2QKK2FjX2Fic19idWlsZGRpcj0kYWNfcHdkJGFjX2Rp
cl9zdWZmaXgKKyMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk6CithY190b3BfYnVpbGRkaXI9
JGFjX3RvcF9idWlsZF9wcmVmaXgKKworY2FzZSAkc3JjZGlyIGluCisgIC4pICAjIFdlIGFyZSBi
dWlsZGluZyBpbiBwbGFjZS4KKyAgICBhY19zcmNkaXI9LgorICAgIGFjX3RvcF9zcmNkaXI9JGFj
X3RvcF9idWlsZGRpcl9zdWIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0kYWNfcHdkIDs7CisgIFtc
XC9dKiB8ID86W1xcL10qICkgICMgQWJzb2x1dGUgbmFtZS4KKyAgICBhY19zcmNkaXI9JHNyY2Rp
ciRhY19kaXJfc3VmZml4OworICAgIGFjX3RvcF9zcmNkaXI9JHNyY2RpcgorICAgIGFjX2Fic190
b3Bfc3JjZGlyPSRzcmNkaXIgOzsKKyAgKikgIyBSZWxhdGl2ZSBuYW1lLgorICAgIGFjX3NyY2Rp
cj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIkYWNfZGlyX3N1ZmZpeAorICAgIGFjX3RvcF9z
cmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9
JGFjX3B3ZC8kc3JjZGlyIDs7Citlc2FjCithY19hYnNfc3JjZGlyPSRhY19hYnNfdG9wX3NyY2Rp
ciRhY19kaXJfc3VmZml4CisKKyAgICBjZCAiJGFjX2RpciIgfHwgeyBhY19zdGF0dXM9JD87IGNv
bnRpbnVlOyB9CisgICAgIyBDaGVjayBmb3IgZ3Vlc3RlZCBjb25maWd1cmUuCisgICAgaWYgdGVz
dCAtZiAiJGFjX3NyY2Rpci9jb25maWd1cmUuZ251IjsgdGhlbgorICAgICAgZWNobyAmJgorICAg
ICAgJFNIRUxMICIkYWNfc3JjZGlyL2NvbmZpZ3VyZS5nbnUiIC0taGVscD1yZWN1cnNpdmUKKyAg
ICBlbGlmIHRlc3QgLWYgIiRhY19zcmNkaXIvY29uZmlndXJlIjsgdGhlbgorICAgICAgZWNobyAm
JgorICAgICAgJFNIRUxMICIkYWNfc3JjZGlyL2NvbmZpZ3VyZSIgLS1oZWxwPXJlY3Vyc2l2ZQor
ICAgIGVsc2UKKyAgICAgICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IG5vIGNvbmZpZ3VyYXRp
b24gaW5mb3JtYXRpb24gaXMgaW4gJGFjX2RpciIgPiYyCisgICAgZmkgfHwgYWNfc3RhdHVzPSQ/
CisgICAgY2QgIiRhY19wd2QiIHx8IHsgYWNfc3RhdHVzPSQ/OyBicmVhazsgfQorICBkb25lCitm
aQorCit0ZXN0IC1uICIkYWNfaW5pdF9oZWxwIiAmJiBleGl0ICRhY19zdGF0dXMKK2lmICRhY19p
bml0X3ZlcnNpb247IHRoZW4KKyAgY2F0IDw8XF9BQ0VPRgorY29uZmlndXJlCitnZW5lcmF0ZWQg
YnkgR05VIEF1dG9jb25mIDIuNjcKKworQ29weXJpZ2h0IChDKSAyMDEwIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbiwgSW5jLgorVGhpcyBjb25maWd1cmUgc2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7
IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KK2dpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9u
IHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4KK19BQ0VPRgorICBleGl0CitmaQor
CisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIEF1dG9jb25mIGluaXRpYWxpemF0
aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMgYWNfZm5fY190cnlf
Y29tcGlsZSBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGNv
bXBpbGUgY29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVk
LgorYWNfZm5fY190cnlfY29tcGlsZSAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQx
In0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHJt
IC1mIGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGUiCitj
YXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2Vj
aG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNf
ZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jb21waWxlIikgMj5jb25m
dGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVu
CisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQg
Y29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAg
ZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0
YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeworCSB0ZXN0IC16ICIkYWNf
Y193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAgIH0gJiYg
dGVzdCAtcyBjb25mdGVzdC4kYWNfb2JqZXh0OyB0aGVuIDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UK
KyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98
IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKKwlhY19yZXR2YWw9MQorZmkKKyAgZXZhbCAkYXNf
bGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5v
PTsgdW5zZXQgYXNfbGluZW5vO30KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCisKK30g
IyBhY19mbl9jX3RyeV9jb21waWxlCisKKyMgYWNfZm5fY190cnlfY3BwIExJTkVOTworIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyeSB0byBwcmVwcm9jZXNzIGNvbmZ0ZXN0LiRhY19leHQs
IGFuZCByZXR1cm4gd2hldGhlciB0aGlzIHN1Y2NlZWRlZC4KK2FjX2ZuX2NfdHJ5X2NwcCAoKQor
eworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVu
b19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIHsgeyBhY190cnk9IiRhY19jcHAgY29uZnRl
c3QuJGFjX2V4dCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBh
Y190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYwor
ZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5
X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2Nw
cCBjb25mdGVzdC4kYWNfZXh0IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlm
IHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3Qu
ZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNv
bmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH0gPiBjb25mdGVzdC5pICYmIHsKKwkgdGVzdCAteiAiJGFjX2NfcHJlcHJvY193YXJuX2Zs
YWckYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAg
IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWls
ZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUK
KworICAgIGFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngk
YXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQor
ICBhc19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5X2NwcAorCisj
IGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgTElORU5PIEhFQURFUiBWQVIgSU5DTFVERVMK
KyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorIyBUZXN0cyB3aGV0aGVyIEhFQURFUiBleGlzdHMsIGdpdmluZyBhIHdhcm5pbmcgaWYgaXQg
Y2Fubm90IGJlIGNvbXBpbGVkIHVzaW5nCisjIHRoZSBpbmNsdWRlIGZpbGVzIGluIElOQ0xVREVT
IGFuZCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIKKyMgYWNjb3JkaW5nbHkuCithY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0i
JDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAg
aWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KK2lmIGV2YWwgInRlc3QgXCJcJHsk
MytzZXR9XCIiID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Zp
CitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7
IH0KK2Vsc2UKKyAgIyBJcyB0aGUgaGVhZGVyIGNvbXBpbGFibGU/Cit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHVzYWJpbGl0eSIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyAkMiB1c2FiaWxpdHkuLi4gIiA+JjY7IH0KK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0
CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfaGVhZGVyX2NvbXBpbGVyPXllcworZWxzZQorICBhY19oZWFkZXJfY29t
cGlsZXI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfaGVhZGVyX2NvbXBpbGVyIiA+JjUKKyRhc19lY2hvICIkYWNfaGVhZGVy
X2NvbXBpbGVyIiA+JjY7IH0KKworIyBJcyB0aGUgaGVhZGVyIHByZXNlbnQ/Cit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHByZXNlbmNlIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nICQyIHByZXNlbmNlLi4uICIgPiY2OyB9CitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRo
ZW4gOgorICBhY19oZWFkZXJfcHJlcHJvYz15ZXMKK2Vsc2UKKyAgYWNfaGVhZGVyX3ByZXByb2M9
bm8KK2ZpCitybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Cit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2hlYWRl
cl9wcmVwcm9jIiA+JjUKKyRhc19lY2hvICIkYWNfaGVhZGVyX3ByZXByb2MiID4mNjsgfQorCisj
IFNvPyAgV2hhdCBhYm91dCB0aGlzIGhlYWRlcj8KK2Nhc2UgJGFjX2hlYWRlcl9jb21waWxlcjok
YWNfaGVhZGVyX3ByZXByb2M6JGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gIygoCisgIHllczpu
bzogKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogJDI6IGFjY2VwdGVkIGJ5IHRoZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXByb2Nl
c3NvciEiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IGFjY2VwdGVkIGJ5IHRo
ZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXByb2Nlc3NvciEiID4mMjt9CisgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJvY2Vl
ZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBX
QVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiYyO30K
KyAgICA7OworICBubzp5ZXM6KiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJlc2VudCBidXQgY2Fubm90IGJlIGNvbXBpbGVkIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3QgYmUg
Y29tcGlsZWQiID4mMjt9CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZvciBtaXNzaW5nIHByZXJlcXVpc2l0ZSBoZWFk
ZXJzPyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZvciBt
aXNzaW5nIHByZXJlcXVpc2l0ZSBoZWFkZXJzPyIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBzZWUgdGhlIEF1dG9jb25mIGRv
Y3VtZW50YXRpb24iID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHNlZSB0aGUg
QXV0b2NvbmYgZG9jdW1lbnRhdGlvbiIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiAgICAgc2VjdGlvbiBcIlByZXNlbnQgQnV0
IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQy
OiAgICAgc2VjdGlvbiBcIlByZXNlbnQgQnV0IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjI7fQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6
IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1bHQiID4mNQorJGFzX2VjaG8gIiRh
c19tZTogV0FSTklORzogJDI6IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1bHQi
ID4mMjt9CisgICAgOzsKK2VzYWMKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQy
Li4uICIgPiY2OyB9CitpZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9IHNldDsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGV2YWwgIiQzPVwkYWNfaGVh
ZGVyX2NvbXBpbGVyIgorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2Vj
aG8gIiRhY19yZXMiID4mNjsgfQorZmkKKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4
JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30K
KworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwKKworIyBhY19mbl9jX3RyeV9ydW4g
TElORU5PCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGxpbmsgY29uZnRlc3Qu
JGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLiBBc3N1bWVzCisjIHRo
YXQgZXhlY3V0YWJsZXMgKmNhbiogYmUgcnVuLgorYWNfZm5fY190cnlfcnVuICgpCit7CisgIGFz
X2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNr
PSRhc19saW5lbm9fc3RhY2sKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRh
Y190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owor
ICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFj
X3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0dXM9
JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0
YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeyBhY190cnk9Jy4vY29uZnRl
c3QkYWNfZXhlZXh0JworICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8
ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7
Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFs
ICIkYWNfdHJ5IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1
cyA9IDA7IH07IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFz
X21lOiBwcm9ncmFtIGV4aXRlZCB3aXRoIHN0YXR1cyAkYWNfc3RhdHVzIiA+JjUKKyAgICAgICAk
YXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycg
Y29uZnRlc3QuJGFjX2V4dCA+JjUKKworICAgICAgIGFjX3JldHZhbD0kYWNfc3RhdHVzCitmaQor
ICBybSAtcmYgY29uZnRlc3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwg
JGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xp
bmVubz07IHVuc2V0IGFzX2xpbmVubzt9CisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAor
Cit9ICMgYWNfZm5fY190cnlfcnVuCisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSBM
SU5FTk8gSEVBREVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4aXN0
cyBhbmQgY2FuIGJlIGNvbXBpbGVkIHVzaW5nIHRoZSBpbmNsdWRlIGZpbGVzIGluCisjIElOQ0xV
REVTLCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCithY19mbl9j
X2NoZWNrX2hlYWRlcl9jb21waWxlICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEi
fSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFsICJ0ZXN0
IFwiXCR7JDMrc2V0fVwiIiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDM9eWVzIgorZWxz
ZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVz
IiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNr
OyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNf
bGluZW5vO30KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUKKworIyBhY19mbl9j
X3RyeV9saW5rIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gbGlu
ayBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCith
Y19mbl9jX3RyeV9saW5rICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19s
aW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdCRhY19leGVleHQKKyAgaWYgeyB7IGFjX3RyeT0iJGFj
X2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5
X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwg
YWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hv
XCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikg
Mj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJy
OyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAg
ICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5l
cnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0g
JGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeworCSB0ZXN0IC16
ICIkYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAg
IH0gJiYgdGVzdCAtcyBjb25mdGVzdCRhY19leGVleHQgJiYgeworCSB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllcyB8fAorCSAkYXNfdGVzdF94IGNvbmZ0ZXN0JGFjX2V4ZWV4dAorICAgICAg
IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWls
ZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUK
KworCWFjX3JldHZhbD0xCitmaQorICAjIERlbGV0ZSB0aGUgSVBBL0lQTyAoSW50ZXIgUHJvY2Vk
dXJhbCBBbmFseXNpcy9PcHRpbWl6YXRpb24pIGluZm9ybWF0aW9uCisgICMgY3JlYXRlZCBieSB0
aGUgUEdJIGNvbXBpbGVyIChjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vKSwgYXMgaXQgd291bGQK
KyAgIyBpbnRlcmZlcmUgd2l0aCB0aGUgbmV4dCBsaW5rIGNvbW1hbmQ7IGFsc28gZGVsZXRlIGEg
ZGlyZWN0b3J5IHRoYXQgaXMKKyAgIyBsZWZ0IGJlaGluZCBieSBBcHBsZSdzIGNvbXBpbGVyLiAg
V2UgZG8gdGhpcyBiZWZvcmUgZXhlY3V0aW5nIHRoZSBhY3Rpb25zLgorICBybSAtcmYgY29uZnRl
c3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwgJGFzX2xpbmVub19zdGFj
azsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFz
X2xpbmVubzt9CisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMgYWNfZm5fY190
cnlfbGluaworCisjIGFjX2ZuX2NfY2hlY2tfZnVuYyBMSU5FTk8gRlVOQyBWQVIKKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3Rz
LCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkKK2FjX2ZuX2NfY2hl
Y2tfZnVuYyAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0
YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1c
IiIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCisvKiBEZWZpbmUgJDIgdG8gYW4gaW5ub2N1b3VzIHZhcmlhbnQsIGluIGNhc2Ug
PGxpbWl0cy5oPiBkZWNsYXJlcyAkMi4KKyAgIEZvciBleGFtcGxlLCBIUC1VWCAxMWkgPGxpbWl0
cy5oPiBkZWNsYXJlcyBnZXR0aW1lb2ZkYXkuICAqLworI2RlZmluZSAkMiBpbm5vY3VvdXNfJDIK
KworLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5
IGZldyBwcm90b3R5cGVzLAorICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgJDIgKCk7
IGJlbG93LgorICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18g
aXMgZGVmaW5lZCwgc2luY2UKKyAgICA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFu
ZGluZyBjb21waWxlcnMuICAqLworCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRz
Lmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRpZgorCisjdW5kZWYgJDIKKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciAkMiAoKTsKKy8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rp
b25zIHdoaWNoIGl0IGltcGxlbWVudHMKKyAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4g
IFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZAorICAgIHNvbWV0aGluZyBzdGFydGlu
ZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLworI2lmIGRlZmlu
ZWQgX19zdHViXyQyIHx8IGRlZmluZWQgX19zdHViX19fJDIKK2Nob2tlIG1lCisjZW5kaWYKKwor
aW50CittYWluICgpCit7CityZXR1cm4gJDIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDM9eWVz
IgorZWxzZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMi
ID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNr
IiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQorCit9ICMgYWNfZm5fY19j
aGVja19mdW5jCisKKyMgYWNfZm5fY19jaGVja190eXBlIExJTkVOTyBUWVBFIFZBUiBJTkNMVURF
UworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3Rz
IHdoZXRoZXIgVFlQRSBleGlzdHMgYWZ0ZXIgaGF2aW5nIGluY2x1ZGVkIElOQ0xVREVTLCBzZXR0
aW5nIGNhY2hlCisjIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfdHlw
ZSAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFz
X2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIk
Mz1ubyIKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworJDQKK2ludAorbWFpbiAoKQoreworaWYgKHNpemVvZiAoJDIp
KQorCSByZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNAoraW50CittYWlu
ICgpCit7CitpZiAoc2l6ZW9mICgoJDIpKSkKKwkgICAgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KworZWxzZQorICBldmFsICIkMz15ZXMiCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19y
ZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwg
JGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xp
bmVubz07IHVuc2V0IGFzX2xpbmVubzt9CisKK30gIyBhY19mbl9jX2NoZWNrX3R5cGUKKworIyBh
Y19mbl9jX2ZpbmRfaW50WF90IExJTkVOTyBCSVRTIFZBUgorIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorIyBGaW5kcyBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0
aCBCSVRTLCBzZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUgorIyBhY2NvcmRpbmdseS4KK2FjX2Zu
X2NfZmluZF9pbnRYX3QgKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xp
bmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpbnQkMl90IiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciBpbnQkMl90Li4uICIgPiY2OyB9CitpZiBldmFsICJ0
ZXN0IFwiXCR7JDMrc2V0fVwiIiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAt
IG5ldmVyIGNoZWNrIGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKKyAgICAgIyB0
aGFuIGhhbGYgb2YgdGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KKyAgICAgZm9yIGFjX3R5cGUg
aW4gaW50JDJfdCAnaW50JyAnbG9uZyBpbnQnIFwKKwkgJ2xvbmcgbG9uZyBpbnQnICdzaG9ydCBp
bnQnICdzaWduZWQgY2hhcic7IGRvCisgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQKKwkgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7Citz
dGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAoKCgoKCRhY190
eXBlKSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAor
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRM
SU5FTk8iOyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKwkgICAg
ICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7CitzdGF0aWMgaW50
IHRlc3RfYXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikg
PDwgTikgLSAxKSAqIDIgKyAxKQorCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwg
TikgPDwgTikgLSAxKSAqIDIgKyAyKSldOwordGVzdF9hcnJheSBbMF0gPSAwCisKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRo
ZW4gOgorCitlbHNlCisgIGNhc2UgJGFjX3R5cGUgaW4gIygKKyAgaW50JDJfdCkgOgorICAgIGV2
YWwgIiQzPXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2Vz
YWMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4
Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFj
X3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZh
bCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNf
bGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KKworfSAjIGFjX2ZuX2NfZmluZF9pbnRYX3QKKwor
IyBhY19mbl9jX2NoZWNrX21lbWJlciBMSU5FTk8gQUdHUiBNRU1CRVIgVkFSIElOQ0xVREVTCisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMg
VHJpZXMgdG8gZmluZCBpZiB0aGUgZmllbGQgTUVNQkVSIGV4aXN0cyBpbiB0eXBlIEFHR1IsIGFm
dGVyIGluY2x1ZGluZworIyBJTkNMVURFUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIgYWNj
b3JkaW5nbHkuCithY19mbl9jX2NoZWNrX21lbWJlciAoKQoreworICBhc19saW5lbm89JHthc19s
aW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0
YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICQyLiQzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4kMy4uLiAiID4mNjsg
fQoraWYgZXZhbCAidGVzdCBcIlwkeyQ0K3NldH1cIiIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNQoraW50CittYWluICgp
Cit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChhY19hZ2dyLiQzKQorcmV0dXJuIDA7CisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgZXZhbCAiJDQ9eWVzIgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNQoraW50Citt
YWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChzaXplb2YgYWNfYWdnci4kMykKK3Jl
dHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwgIiQ0PXllcyIKK2Vsc2UKKyAgZXZhbCAiJDQ9
bm8iCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25m
dGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkNAorCSAgICAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1
CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVz
dCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVu
bzt9CisKK30gIyBhY19mbl9jX2NoZWNrX21lbWJlcgorCisjIGFjX2ZuX2NfZmluZF91aW50WF90
IExJTkVOTyBCSVRTIFZBUgorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
KyMgRmluZHMgYW4gdW5zaWduZWQgaW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGlu
ZyBjYWNoZSB2YXJpYWJsZSBWQVIKKyMgYWNjb3JkaW5nbHkuCithY19mbl9jX2ZpbmRfdWludFhf
dCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFz
X2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHVpbnQkMl90IiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciB1aW50JDJfdC4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyQz
K3NldH1cIiIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBldmFsICIkMz1ubyIKKyAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVj
ayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCisgICAgICMgdGhhbiBoYWxmIG9m
IHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCisgICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90
ICd1bnNpZ25lZCBpbnQnICd1bnNpZ25lZCBsb25nIGludCcgXAorCSAndW5zaWduZWQgbG9uZyBs
b25nIGludCcgJ3Vuc2lnbmVkIHNob3J0IGludCcgJ3Vuc2lnbmVkIGNoYXInOyBkbworICAgICAg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK21haW4gKCkKK3sKK3N0YXRp
YyBpbnQgdGVzdF9hcnJheSBbMSAtIDIgKiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAx
KSkgPj4gKCQyIC8gMiAtIDEpID09IDMpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAg
cmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgY2FzZSAkYWNfdHlwZSBpbiAjKAorICB1aW50JDJfdCkgOgorICAgIGV2YWwgIiQz
PXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6CisK
K2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAg
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
cmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0
YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQg
YXNfbGluZW5vO30KKworfSAjIGFjX2ZuX2NfZmluZF91aW50WF90CitjYXQgPmNvbmZpZy5sb2cg
PDxfQUNFT0YKK1RoaXMgZmlsZSBjb250YWlucyBhbnkgbWVzc2FnZXMgcHJvZHVjZWQgYnkgY29t
cGlsZXJzIHdoaWxlCitydW5uaW5nIGNvbmZpZ3VyZSwgdG8gYWlkIGRlYnVnZ2luZyBpZiBjb25m
aWd1cmUgbWFrZXMgYSBtaXN0YWtlLgorCitJdCB3YXMgY3JlYXRlZCBieSAkYXNfbWUsIHdoaWNo
IHdhcworZ2VuZXJhdGVkIGJ5IEdOVSBBdXRvY29uZiAyLjY3LiAgSW52b2NhdGlvbiBjb21tYW5k
IGxpbmUgd2FzCisKKyAgJCAkMCAkQAorCitfQUNFT0YKK2V4ZWMgNT4+Y29uZmlnLmxvZworewor
Y2F0IDw8X0FTVU5BTUUKKyMjIC0tLS0tLS0tLSAjIworIyMgUGxhdGZvcm0uICMjCisjIyAtLS0t
LS0tLS0gIyMKKworaG9zdG5hbWUgPSBgKGhvc3RuYW1lIHx8IHVuYW1lIC1uKSAyPi9kZXYvbnVs
bCB8IHNlZCAxcWAKK3VuYW1lIC1tID0gYCh1bmFtZSAtbSkgMj4vZGV2L251bGwgfHwgZWNobyB1
bmtub3duYAordW5hbWUgLXIgPSBgKHVuYW1lIC1yKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25v
d25gCit1bmFtZSAtcyA9IGAodW5hbWUgLXMpIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAK
K3VuYW1lIC12ID0gYCh1bmFtZSAtdikgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAorCisv
dXNyL2Jpbi91bmFtZSAtcCA9IGAoL3Vzci9iaW4vdW5hbWUgLXApIDI+L2Rldi9udWxsIHx8IGVj
aG8gdW5rbm93bmAKKy9iaW4vdW5hbWUgLVggICAgID0gYCgvYmluL3VuYW1lIC1YKSAyPi9kZXYv
bnVsbCAgICAgfHwgZWNobyB1bmtub3duYAorCisvYmluL2FyY2ggICAgICAgICAgICAgID0gYCgv
YmluL2FyY2gpIDI+L2Rldi9udWxsICAgICAgICAgICAgICB8fCBlY2hvIHVua25vd25gCisvdXNy
L2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jpbi9hcmNoIC1rKSAyPi9kZXYvbnVsbCAgICAg
ICB8fCBlY2hvIHVua25vd25gCisvdXNyL2NvbnZleC9nZXRzeXNpbmZvID0gYCgvdXNyL2NvbnZl
eC9nZXRzeXNpbmZvKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCisvdXNyL2Jpbi9ob3N0
aW5mbyAgICAgID0gYCgvdXNyL2Jpbi9ob3N0aW5mbykgMj4vZGV2L251bGwgICAgICB8fCBlY2hv
IHVua25vd25gCisvYmluL21hY2hpbmUgICAgICAgICAgID0gYCgvYmluL21hY2hpbmUpIDI+L2Rl
di9udWxsICAgICAgICAgICB8fCBlY2hvIHVua25vd25gCisvdXNyL2Jpbi9vc2xldmVsICAgICAg
ID0gYCgvdXNyL2Jpbi9vc2xldmVsKSAyPi9kZXYvbnVsbCAgICAgICB8fCBlY2hvIHVua25vd25g
CisvYmluL3VuaXZlcnNlICAgICAgICAgID0gYCgvYmluL3VuaXZlcnNlKSAyPi9kZXYvbnVsbCAg
ICAgICAgICB8fCBlY2hvIHVua25vd25gCisKK19BU1VOQU1FCisKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAkYXNfZWNobyAi
UEFUSDogJGFzX2RpciIKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCit9ID4mNQorCitjYXQg
PiY1IDw8X0FDRU9GCisKKworIyMgLS0tLS0tLS0tLS0gIyMKKyMjIENvcmUgdGVzdHMuICMjCisj
IyAtLS0tLS0tLS0tLSAjIworCitfQUNFT0YKKworCisjIEtlZXAgYSB0cmFjZSBvZiB0aGUgY29t
bWFuZCBsaW5lLgorIyBTdHJpcCBvdXQgLS1uby1jcmVhdGUgYW5kIC0tbm8tcmVjdXJzaW9uIHNv
IHRoZXkgZG8gbm90IHBpbGUgdXAuCisjIFN0cmlwIG91dCAtLXNpbGVudCBiZWNhdXNlIHdlIGRv
bid0IHdhbnQgdG8gcmVjb3JkIGl0IGZvciBmdXR1cmUgcnVucy4KKyMgQWxzbyBxdW90ZSBhbnkg
YXJncyBjb250YWluaW5nIHNoZWxsIG1ldGEtY2hhcmFjdGVycy4KKyMgTWFrZSB0d28gcGFzc2Vz
IHRvIGFsbG93IGZvciBwcm9wZXIgZHVwbGljYXRlLWFyZ3VtZW50IHN1cHByZXNzaW9uLgorYWNf
Y29uZmlndXJlX2FyZ3M9CithY19jb25maWd1cmVfYXJnczA9CithY19jb25maWd1cmVfYXJnczE9
CithY19tdXN0X2tlZXBfbmV4dD1mYWxzZQorZm9yIGFjX3Bhc3MgaW4gMSAyCitkbworICBmb3Ig
YWNfYXJnCisgIGRvCisgICAgY2FzZSAkYWNfYXJnIGluCisgICAgLW5vLWNyZWF0ZSB8IC0tbm8t
YyogfCAtbiB8IC1uby1yZWN1cnNpb24gfCAtLW5vLXIqKSBjb250aW51ZSA7OworICAgIC1xIHwg
LXF1aWV0IHwgLS1xdWlldCB8IC0tcXVpZSB8IC0tcXVpIHwgLS1xdSB8IC0tcSBcCisgICAgfCAt
c2lsZW50IHwgLS1zaWxlbnQgfCAtLXNpbGVuIHwgLS1zaWxlIHwgLS1zaWwpCisgICAgICBjb250
aW51ZSA7OworICAgICpcJyopCisgICAgICBhY19hcmc9YCRhc19lY2hvICIkYWNfYXJnIiB8IHNl
ZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAgIGVzYWMKKyAgICBjYXNlICRhY19wYXNzIGlu
CisgICAgMSkgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ3VyZV9hcmdzMCAiICckYWNfYXJnJyIgOzsK
KyAgICAyKQorICAgICAgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ3VyZV9hcmdzMSAiICckYWNfYXJn
JyIKKyAgICAgIGlmIHRlc3QgJGFjX211c3Rfa2VlcF9uZXh0ID0gdHJ1ZTsgdGhlbgorCWFjX211
c3Rfa2VlcF9uZXh0PWZhbHNlICMgR290IHZhbHVlLCBiYWNrIHRvIG5vcm1hbC4KKyAgICAgIGVs
c2UKKwljYXNlICRhY19hcmcgaW4KKwkgICo9KiB8IC0tY29uZmlnLWNhY2hlIHwgLUMgfCAtZGlz
YWJsZS0qIHwgLS1kaXNhYmxlLSogXAorCSAgfCAtZW5hYmxlLSogfCAtLWVuYWJsZS0qIHwgLWdh
cyB8IC0tZyogfCAtbmZwIHwgLS1uZiogXAorCSAgfCAtcSB8IC1xdWlldCB8IC0tcSogfCAtc2ls
ZW50IHwgLS1zaWwqIHwgLXYgfCAtdmVyYiogXAorCSAgfCAtd2l0aC0qIHwgLS13aXRoLSogfCAt
d2l0aG91dC0qIHwgLS13aXRob3V0LSogfCAtLXgpCisJICAgIGNhc2UgIiRhY19jb25maWd1cmVf
YXJnczAgIiBpbgorCSAgICAgICIkYWNfY29uZmlndXJlX2FyZ3MxIioiICckYWNfYXJnJyAiKiAp
IGNvbnRpbnVlIDs7CisJICAgIGVzYWMKKwkgICAgOzsKKwkgIC0qICkgYWNfbXVzdF9rZWVwX25l
eHQ9dHJ1ZSA7OworCWVzYWMKKyAgICAgIGZpCisgICAgICBhc19mbl9hcHBlbmQgYWNfY29uZmln
dXJlX2FyZ3MgIiAnJGFjX2FyZyciCisgICAgICA7OworICAgIGVzYWMKKyAgZG9uZQorZG9uZQor
eyBhY19jb25maWd1cmVfYXJnczA9OyB1bnNldCBhY19jb25maWd1cmVfYXJnczA7fQoreyBhY19j
b25maWd1cmVfYXJnczE9OyB1bnNldCBhY19jb25maWd1cmVfYXJnczE7fQorCisjIFdoZW4gaW50
ZXJydXB0ZWQgb3IgZXhpdCdkLCBjbGVhbnVwIHRlbXBvcmFyeSBmaWxlcywgYW5kIGNvbXBsZXRl
CisjIGNvbmZpZy5sb2cuICBXZSByZW1vdmUgY29tbWVudHMgYmVjYXVzZSBhbnl3YXkgdGhlIHF1
b3RlcyBpbiB0aGVyZQorIyB3b3VsZCBjYXVzZSBwcm9ibGVtcyBvciBsb29rIHVnbHkuCisjIFdB
Uk5JTkc6IFVzZSAnXCcnIHRvIHJlcHJlc2VudCBhbiBhcG9zdHJvcGhlIHdpdGhpbiB0aGUgdHJh
cC4KKyMgV0FSTklORzogRG8gbm90IHN0YXJ0IHRoZSB0cmFwIGNvZGUgd2l0aCBhIG5ld2xpbmUs
IGR1ZSB0byBhIEZyZWVCU0QgNC4wIGJ1Zy4KK3RyYXAgJ2V4aXRfc3RhdHVzPSQ/CisgICMgU2F2
ZSBpbnRvIGNvbmZpZy5sb2cgc29tZSBpbmZvcm1hdGlvbiB0aGF0IG1pZ2h0IGhlbHAgaW4gZGVi
dWdnaW5nLgorICB7CisgICAgZWNobworCisgICAgJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0t
LS0gIyMKKyMjIENhY2hlIHZhcmlhYmxlcy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0gIyMiCisg
ICAgZWNobworICAgICMgVGhlIGZvbGxvd2luZyB3YXkgb2Ygd3JpdGluZyB0aGUgY2FjaGUgbWlz
aGFuZGxlcyBuZXdsaW5lcyBpbiB2YWx1ZXMsCisoCisgIGZvciBhY192YXIgaW4gYChzZXQpIDI+
JjEgfCBzZWQgLW4gJ1wnJ3MvXlwoW2EtekEtWl9dW2EtekEtWjAtOV9dKlwpPS4qL1wxL3AnXCcn
YDsgZG8KKyAgICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgICBjYXNlICRhY192YWwgaW4gIygK
KyAgICAqJHthc19ubH0qKQorICAgICAgY2FzZSAkYWNfdmFyIGluICMoCisgICAgICAqX2N2Xyop
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogY2FjaGUg
dmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4m
Mjt9IDs7CisgICAgICBlc2FjCisgICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgIF8gfCBJ
RlMgfCBhc19ubCkgOzsgIygKKyAgICAgIEJBU0hfQVJHViB8IEJBU0hfU09VUkNFKSBldmFsICRh
Y192YXI9IDs7ICMoCisgICAgICAqKSB7IGV2YWwgJGFjX3Zhcj07IHVuc2V0ICRhY192YXI7fSA7
OworICAgICAgZXNhYyA7OworICAgIGVzYWMKKyAgZG9uZQorICAoc2V0KSAyPiYxIHwKKyAgICBj
YXNlICRhc19ubGAoYWNfc3BhY2U9J1wnJyAnXCcnOyBzZXQpIDI+JjFgIGluICMoCisgICAgKiR7
YXNfbmx9YWNfc3BhY2U9XCAqKQorICAgICAgc2VkIC1uIFwKKwkicy8nXCcnLydcJydcXFxcJ1wn
JydcJycvZzsKKwkgIHMvXlxcKFtfJGFzX2NyX2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKlxc
KT1cXCguKlxcKS9cXDE9J1wnJ1xcMidcJycvcCIKKyAgICAgIDs7ICMoCisgICAgKikKKyAgICAg
IHNlZCAtbiAiL15bXyRhc19jcl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisgICAg
ICA7OworICAgIGVzYWMgfAorICAgIHNvcnQKKykKKyAgICBlY2hvCisKKyAgICAkYXNfZWNobyAi
IyMgLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE91dHB1dCB2YXJpYWJsZXMuICMjCisjIyAtLS0t
LS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisgICAgZm9yIGFjX3ZhciBpbiAkYWNfc3Vic3Rf
dmFycworICAgIGRvCisgICAgICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgICAgIGNhc2UgJGFj
X3ZhbCBpbgorICAgICAgKlwnXCcnKikgYWNfdmFsPWAkYXNfZWNobyAiJGFjX3ZhbCIgfCBzZWQg
InMvJ1wnJy8nXCcnXFxcXFxcXFwnXCcnJ1wnJy9nImA7OworICAgICAgZXNhYworICAgICAgJGFz
X2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwnXCcnIgorICAgIGRvbmUgfCBzb3J0CisgICAgZWNo
bworCisgICAgaWYgdGVzdCAtbiAiJGFjX3N1YnN0X2ZpbGVzIjsgdGhlbgorICAgICAgJGFzX2Vj
aG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIEZpbGUgc3Vic3RpdHV0aW9ucy4gIyMK
KyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMiCisgICAgICBlY2hvCisgICAgICBmb3IgYWNfdmFy
IGluICRhY19zdWJzdF9maWxlcworICAgICAgZG8KKwlldmFsIGFjX3ZhbD1cJCRhY192YXIKKwlj
YXNlICRhY192YWwgaW4KKwkqXCdcJycqKSBhY192YWw9YCRhc19lY2hvICIkYWNfdmFsIiB8IHNl
ZCAicy8nXCcnLydcJydcXFxcXFxcXCdcJycnXCcnL2ciYDs7CisJZXNhYworCSRhc19lY2hvICIk
YWNfdmFyPSdcJyckYWNfdmFsJ1wnJyIKKyAgICAgIGRvbmUgfCBzb3J0CisgICAgICBlY2hvCisg
ICAgZmkKKworICAgIGlmIHRlc3QgLXMgY29uZmRlZnMuaDsgdGhlbgorICAgICAgJGFzX2VjaG8g
IiMjIC0tLS0tLS0tLS0tICMjCisjIyBjb25mZGVmcy5oLiAjIworIyMgLS0tLS0tLS0tLS0gIyMi
CisgICAgICBlY2hvCisgICAgICBjYXQgY29uZmRlZnMuaAorICAgICAgZWNobworICAgIGZpCisg
ICAgdGVzdCAiJGFjX3NpZ25hbCIgIT0gMCAmJgorICAgICAgJGFzX2VjaG8gIiRhc19tZTogY2F1
Z2h0IHNpZ25hbCAkYWNfc2lnbmFsIgorICAgICRhc19lY2hvICIkYXNfbWU6IGV4aXQgJGV4aXRf
c3RhdHVzIgorICB9ID4mNQorICBybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogJiYK
KyAgICBybSAtZiAtciBjb25mdGVzdCogY29uZmRlZnMqIGNvbmYkJCogJGFjX2NsZWFuX2ZpbGVz
ICYmCisgICAgZXhpdCAkZXhpdF9zdGF0dXMKKycgMAorZm9yIGFjX3NpZ25hbCBpbiAxIDIgMTMg
MTU7IGRvCisgIHRyYXAgJ2FjX3NpZ25hbD0nJGFjX3NpZ25hbCc7IGFzX2ZuX2V4aXQgMScgJGFj
X3NpZ25hbAorZG9uZQorYWNfc2lnbmFsPTAKKworIyBjb25mZGVmcy5oIGF2b2lkcyBPUyBjb21t
YW5kIGxpbmUgbGVuZ3RoIGxpbWl0cyB0aGF0IERFRlMgY2FuIGV4Y2VlZC4KK3JtIC1mIC1yIGNv
bmZ0ZXN0KiBjb25mZGVmcy5oCisKKyRhc19lY2hvICIvKiBjb25mZGVmcy5oICovIiA+IGNvbmZk
ZWZzLmgKKworIyBQcmVkZWZpbmVkIHByZXByb2Nlc3NvciB2YXJpYWJsZXMuCisKK2NhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9OQU1FICIkUEFDS0FHRV9OQU1FIgor
X0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9UQVJO
QU1FICIkUEFDS0FHRV9UQVJOQU1FIgorX0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKKyNkZWZpbmUgUEFDS0FHRV9WRVJTSU9OICIkUEFDS0FHRV9WRVJTSU9OIgorX0FDRU9GCisK
K2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9TVFJJTkcgIiRQQUNL
QUdFX1NUUklORyIKK19BQ0VPRgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IFBBQ0tBR0VfQlVHUkVQT1JUICIkUEFDS0FHRV9CVUdSRVBPUlQiCitfQUNFT0YKKworY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1VSTCAiJFBBQ0tBR0VfVVJMIgor
X0FDRU9GCisKKworIyBMZXQgdGhlIHNpdGUgZmlsZSBzZWxlY3QgYW4gYWx0ZXJuYXRlIGNhY2hl
IGZpbGUgaWYgaXQgd2FudHMgdG8uCisjIFByZWZlciBhbiBleHBsaWNpdGx5IHNlbGVjdGVkIGZp
bGUgdG8gYXV0b21hdGljYWxseSBzZWxlY3RlZCBvbmVzLgorYWNfc2l0ZV9maWxlMT1OT05FCith
Y19zaXRlX2ZpbGUyPU5PTkUKK2lmIHRlc3QgLW4gIiRDT05GSUdfU0lURSI7IHRoZW4KKyAgIyBX
ZSBkbyBub3Qgd2FudCBhIFBBVEggc2VhcmNoIGZvciBjb25maWcuc2l0ZS4KKyAgY2FzZSAkQ09O
RklHX1NJVEUgaW4gIygoCisgICAgLSopICBhY19zaXRlX2ZpbGUxPS4vJENPTkZJR19TSVRFOzsK
KyAgICAqLyopIGFjX3NpdGVfZmlsZTE9JENPTkZJR19TSVRFOzsKKyAgICAqKSAgIGFjX3NpdGVf
ZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICBlc2FjCitlbGlmIHRlc3QgIngkcHJlZml4IiAhPSB4
Tk9ORTsgdGhlbgorICBhY19zaXRlX2ZpbGUxPSRwcmVmaXgvc2hhcmUvY29uZmlnLnNpdGUKKyAg
YWNfc2l0ZV9maWxlMj0kcHJlZml4L2V0Yy9jb25maWcuc2l0ZQorZWxzZQorICBhY19zaXRlX2Zp
bGUxPSRhY19kZWZhdWx0X3ByZWZpeC9zaGFyZS9jb25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUy
PSRhY19kZWZhdWx0X3ByZWZpeC9ldGMvY29uZmlnLnNpdGUKK2ZpCitmb3IgYWNfc2l0ZV9maWxl
IGluICIkYWNfc2l0ZV9maWxlMSIgIiRhY19zaXRlX2ZpbGUyIgorZG8KKyAgdGVzdCAieCRhY19z
aXRlX2ZpbGUiID0geE5PTkUgJiYgY29udGludWUKKyAgaWYgdGVzdCAvZGV2L251bGwgIT0gIiRh
Y19zaXRlX2ZpbGUiICYmIHRlc3QgLXIgIiRhY19zaXRlX2ZpbGUiOyB0aGVuCisgICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRh
Y19zaXRlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogbG9hZGluZyBzaXRlIHNjcmlwdCAk
YWNfc2l0ZV9maWxlIiA+JjY7fQorICAgIHNlZCAncy9eL3wgLycgIiRhY19zaXRlX2ZpbGUiID4m
NQorICAgIC4gIiRhY19zaXRlX2ZpbGUiIFwKKyAgICAgIHx8IHsgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8g
ImZhaWxlZCB0byBsb2FkIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUKK1NlZSBcYGNvbmZpZy5s
b2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICBmaQorZG9uZQorCitpZiB0
ZXN0IC1yICIkY2FjaGVfZmlsZSI7IHRoZW4KKyAgIyBTb21lIHZlcnNpb25zIG9mIGJhc2ggd2ls
bCBmYWlsIHRvIHNvdXJjZSAvZGV2L251bGwgKHNwZWNpYWwgZmlsZXMKKyAgIyBhY3R1YWxseSks
IHNvIHdlIGF2b2lkIGRvaW5nIHRoYXQuICBESkdQUCBlbXVsYXRlcyBpdCBhcyBhIHJlZ3VsYXIg
ZmlsZS4KKyAgaWYgdGVzdCAvZGV2L251bGwgIT0gIiRjYWNoZV9maWxlIiAmJiB0ZXN0IC1mICIk
Y2FjaGVfZmlsZSI7IHRoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGxvYWRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTog
bG9hZGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAgICBjYXNlICRjYWNoZV9maWxlIGlu
CisgICAgICBbXFwvXSogfCA/OltcXC9dKiApIC4gIiRjYWNoZV9maWxlIjs7CisgICAgICAqKSAg
ICAgICAgICAgICAgICAgICAgICAuICIuLyRjYWNoZV9maWxlIjs7CisgICAgZXNhYworICBmaQor
ZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNyZWF0aW5n
IGNhY2hlICRjYWNoZV9maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGNyZWF0aW5nIGNhY2hl
ICRjYWNoZV9maWxlIiA+JjY7fQorICA+JGNhY2hlX2ZpbGUKK2ZpCisKK2FzX2ZuX2FwcGVuZCBh
Y19oZWFkZXJfbGlzdCAiIHN5cy90aW1lLmgiCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3Qg
IiB1bmlzdGQuaCIKK2FzX2ZuX2FwcGVuZCBhY19mdW5jX2xpc3QgIiBhbGFybSIKK2FzX2ZuX2Fw
cGVuZCBhY19oZWFkZXJfbGlzdCAiIHN0ZGxpYi5oIgorYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9s
aXN0ICIgc3lzL3BhcmFtLmgiCisjIENoZWNrIHRoYXQgdGhlIHByZWNpb3VzIHZhcmlhYmxlcyBz
YXZlZCBpbiB0aGUgY2FjaGUgaGF2ZSBrZXB0IHRoZSBzYW1lCisjIHZhbHVlLgorYWNfY2FjaGVf
Y29ycnVwdGVkPWZhbHNlCitmb3IgYWNfdmFyIGluICRhY19wcmVjaW91c192YXJzOyBkbworICBl
dmFsIGFjX29sZF9zZXQ9XCRhY19jdl9lbnZfJHthY192YXJ9X3NldAorICBldmFsIGFjX25ld19z
ZXQ9XCRhY19lbnZfJHthY192YXJ9X3NldAorICBldmFsIGFjX29sZF92YWw9XCRhY19jdl9lbnZf
JHthY192YXJ9X3ZhbHVlCisgIGV2YWwgYWNfbmV3X3ZhbD1cJGFjX2Vudl8ke2FjX3Zhcn1fdmFs
dWUKKyAgY2FzZSAkYWNfb2xkX3NldCwkYWNfbmV3X3NldCBpbgorICAgIHNldCwpCisgICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBcYCRhY192YXIn
IHdhcyBzZXQgdG8gXGAkYWNfb2xkX3ZhbCcgaW4gdGhlIHByZXZpb3VzIHJ1biIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgc2V0IHRvIFxgJGFjX29sZF92YWwn
IGluIHRoZSBwcmV2aW91cyBydW4iID4mMjt9CisgICAgICBhY19jYWNoZV9jb3JydXB0ZWQ9OiA7
OworICAgICxzZXQpCisgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBcYCRhY192YXInIHdhcyBub3Qgc2V0IGluIHRoZSBwcmV2aW91cyBydW4iID4m
NQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IFxgJGFjX3Zhcicgd2FzIG5vdCBzZXQgaW4gdGhl
IHByZXZpb3VzIHJ1biIgPiYyO30KKyAgICAgIGFjX2NhY2hlX2NvcnJ1cHRlZD06IDs7CisgICAg
LCk7OworICAgICopCisgICAgICBpZiB0ZXN0ICJ4JGFjX29sZF92YWwiICE9ICJ4JGFjX25ld192
YWwiOyB0aGVuCisJIyBkaWZmZXJlbmNlcyBpbiB3aGl0ZXNwYWNlIGRvIG5vdCBsZWFkIHRvIGZh
aWx1cmUuCisJYWNfb2xkX3ZhbF93PWBlY2hvIHggJGFjX29sZF92YWxgCisJYWNfbmV3X3ZhbF93
PWBlY2hvIHggJGFjX25ld192YWxgCisJaWYgdGVzdCAiJGFjX29sZF92YWxfdyIgIT0gIiRhY19u
ZXdfdmFsX3ciOyB0aGVuCisJICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBcYCRhY192YXInIGhhcyBjaGFuZ2VkIHNpbmNlIHRoZSBwcmV2aW91cyBydW46
IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBcYCRhY192YXInIGhhcyBjaGFuZ2VkIHNp
bmNlIHRoZSBwcmV2aW91cyBydW46IiA+JjI7fQorCSAgYWNfY2FjaGVfY29ycnVwdGVkPToKKwll
bHNlCisJICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHdhcm5pbmc6
IGlnbm9yaW5nIHdoaXRlc3BhY2UgY2hhbmdlcyBpbiBcYCRhY192YXInIHNpbmNlIHRoZSBwcmV2
aW91cyBydW46IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IHdhcm5pbmc6IGlnbm9yaW5nIHdoaXRl
c3BhY2UgY2hhbmdlcyBpbiBcYCRhY192YXInIHNpbmNlIHRoZSBwcmV2aW91cyBydW46IiA+JjI7
fQorCSAgZXZhbCAkYWNfdmFyPVwkYWNfb2xkX3ZhbAorCWZpCisJeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiAgIGZvcm1lciB2YWx1ZTogIFxgJGFjX29sZF92YWwnIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6ICAgZm9ybWVyIHZhbHVlOiAgXGAkYWNfb2xkX3ZhbCciID4m
Mjt9CisJeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAgIGN1cnJlbnQg
dmFsdWU6IFxgJGFjX25ld192YWwnIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6ICAgY3VycmVudCB2
YWx1ZTogXGAkYWNfbmV3X3ZhbCciID4mMjt9CisgICAgICBmaTs7CisgIGVzYWMKKyAgIyBQYXNz
IHByZWNpb3VzIHZhcmlhYmxlcyB0byBjb25maWcuc3RhdHVzLgorICBpZiB0ZXN0ICIkYWNfbmV3
X3NldCIgPSBzZXQ7IHRoZW4KKyAgICBjYXNlICRhY19uZXdfdmFsIGluCisgICAgKlwnKikgYWNf
YXJnPSRhY192YXI9YCRhc19lY2hvICIkYWNfbmV3X3ZhbCIgfCBzZWQgInMvJy8nXFxcXFxcXFwn
Jy9nImAgOzsKKyAgICAqKSBhY19hcmc9JGFjX3Zhcj0kYWNfbmV3X3ZhbCA7OworICAgIGVzYWMK
KyAgICBjYXNlICIgJGFjX2NvbmZpZ3VyZV9hcmdzICIgaW4KKyAgICAgICoiICckYWNfYXJnJyAi
KikgOzsgIyBBdm9pZCBkdXBzLiAgVXNlIG9mIHF1b3RlcyBlbnN1cmVzIGFjY3VyYWN5LgorICAg
ICAgKikgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ3VyZV9hcmdzICIgJyRhY19hcmcnIiA7OworICAg
IGVzYWMKKyAgZmkKK2RvbmUKK2lmICRhY19jYWNoZV9jb3JydXB0ZWQ7IHRoZW4KKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBjaGFuZ2VzIGlu
IHRoZSBlbnZpcm9ubWVudCBjYW4gY29tcHJvbWlzZSB0aGUgYnVpbGQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogZXJyb3I6IGNoYW5nZXMgaW4gdGhlIGVudmlyb25tZW50IGNhbiBjb21wcm9taXNl
IHRoZSBidWlsZCIgPiYyO30KKyAgYXNfZm5fZXJyb3IgJD8gInJ1biBcYG1ha2UgZGlzdGNsZWFu
JyBhbmQvb3IgXGBybSAkY2FjaGVfZmlsZScgYW5kIHN0YXJ0IG92ZXIiICIkTElORU5PIiA1Citm
aQorIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE1haW4gYm9keSBvZiBzY3JpcHQuICMj
CisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworCithY19leHQ9YworYWNfY3BwPSckQ1BQICRD
UFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4k
YWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAk
Q1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19jb21waWxl
cl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKworCithY19jb25maWdfZmlsZXM9IiRhY19j
b25maWdfZmlsZXMgLi4vY29uZmlnL1Rvb2xzLm1rIgorCithY19jb25maWdfaGVhZGVycz0iJGFj
X2NvbmZpZ19oZWFkZXJzIGNvbmZpZy5oIgorCisKK2FjX2F1eF9kaXI9Citmb3IgYWNfZGlyIGlu
IC4gIiRzcmNkaXIiLy47IGRvCisgIGlmIHRlc3QgLWYgIiRhY19kaXIvaW5zdGFsbC1zaCI7IHRo
ZW4KKyAgICBhY19hdXhfZGlyPSRhY19kaXIKKyAgICBhY19pbnN0YWxsX3NoPSIkYWNfYXV4X2Rp
ci9pbnN0YWxsLXNoIC1jIgorICAgIGJyZWFrCisgIGVsaWYgdGVzdCAtZiAiJGFjX2Rpci9pbnN0
YWxsLnNoIjsgdGhlbgorICAgIGFjX2F1eF9kaXI9JGFjX2RpcgorICAgIGFjX2luc3RhbGxfc2g9
IiRhY19hdXhfZGlyL2luc3RhbGwuc2ggLWMiCisgICAgYnJlYWsKKyAgZWxpZiB0ZXN0IC1mICIk
YWNfZGlyL3NodG9vbCI7IHRoZW4KKyAgICBhY19hdXhfZGlyPSRhY19kaXIKKyAgICBhY19pbnN0
YWxsX3NoPSIkYWNfYXV4X2Rpci9zaHRvb2wgaW5zdGFsbCAtYyIKKyAgICBicmVhaworICBmaQor
ZG9uZQoraWYgdGVzdCAteiAiJGFjX2F1eF9kaXIiOyB0aGVuCisgIGFzX2ZuX2Vycm9yICQ/ICJj
YW5ub3QgZmluZCBpbnN0YWxsLXNoLCBpbnN0YWxsLnNoLCBvciBzaHRvb2wgaW4gLiBcIiRzcmNk
aXJcIi8uIiAiJExJTkVOTyIgNQorZmkKKworIyBUaGVzZSB0aHJlZSB2YXJpYWJsZXMgYXJlIHVu
ZG9jdW1lbnRlZCBhbmQgdW5zdXBwb3J0ZWQsCisjIGFuZCBhcmUgaW50ZW5kZWQgdG8gYmUgd2l0
aGRyYXduIGluIGEgZnV0dXJlIEF1dG9jb25mIHJlbGVhc2UuCisjIFRoZXkgY2FuIGNhdXNlIHNl
cmlvdXMgcHJvYmxlbXMgaWYgYSBidWlsZGVyJ3Mgc291cmNlIHRyZWUgaXMgaW4gYSBkaXJlY3Rv
cnkKKyMgd2hvc2UgZnVsbCBuYW1lIGNvbnRhaW5zIHVudXN1YWwgY2hhcmFjdGVycy4KK2FjX2Nv
bmZpZ19ndWVzcz0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5ndWVzcyIgICMgUGxlYXNlIGRv
bid0IHVzZSB0aGlzIHZhci4KK2FjX2NvbmZpZ19zdWI9IiRTSEVMTCAkYWNfYXV4X2Rpci9jb25m
aWcuc3ViIiAgIyBQbGVhc2UgZG9uJ3QgdXNlIHRoaXMgdmFyLgorYWNfY29uZmlndXJlPSIkU0hF
TEwgJGFjX2F1eF9kaXIvY29uZmlndXJlIiAgIyBQbGVhc2UgZG9uJ3QgdXNlIHRoaXMgdmFyLgor
CisKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBp
cyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitpZiB0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxB
R1MkTElCUyRDUFBGTEFHUyRDUFAiOyB0aGVuIDoKKworICAgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdT
LCBMSUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVO
RF9JTkNMVURFUywgUFJFUEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJ
QiBpbnN0ZWFkIHdoZW4gcG9zc2libGUuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IFNldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5v
dCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitB
UFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLiIgPiYy
O30KKworZmkKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxl
PSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5r
PSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNv
bmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBp
bGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsg
YWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0Mi
OyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KKyAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgorICBh
Y19jdF9DQz0kQ0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3Rf
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9
JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lm
IHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0ND
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3Qg
IngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9z
c19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQor
YWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNl
CisgIENDPSIkYWNfY3ZfcHJvZ19DQyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAg
ICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBh
Y193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRD
QyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKKyAgZmkKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgorc2V0IGR1bW15IGNjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKKyAgYWNfcHJvZ19yZWplY3RlZD1u
bworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAk
UEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgaWYg
dGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVu
CisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAgICAgICBjb250aW51ZQorICAgICBmaQor
ICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitpZiB0ZXN0ICRh
Y19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91bmQgYSBib2dvbiBpbiB0aGUg
cGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAgc2V0IGR1bW15ICRhY19jdl9w
cm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgorICAgICMgV2UgY2hvc2Ug
YSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgorICAgICMgSG93ZXZlciwg
aXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KKyAg
ICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRoZSBmdWxs
IGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dv
cmQkezErJyAnfSRAIgorICBmaQorZmkKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisg
IGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgZm9yIGFjX3Byb2cgaW4gY2wu
ZXhlCisgIGRvCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9vbF9wcmVm
aXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth
Y19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIk
Q0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZT
PSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJGFj
X3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9
JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJEND
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICB0ZXN0
IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisg
IGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKK2RvCisgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRlc3QgLW4gIiRhY19jdF9D
QyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAg
ICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0ZXN0IC16ICIkQ0MiICYm
IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsg
fQorCisjIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCiskYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxl
ciB2ZXJzaW9uIiA+JjUKK3NldCBYICRhY19jb21waWxlCithY19jb21waWxlcj0kMgorZm9yIGFj
X29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbworICB7IHsgYWNfdHJ5PSIk
YWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiog
fCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0k
YWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUK
KyAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3QuZXJyCisg
IGFjX3N0YXR1cz0kPworICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgorICAgIHNlZCAn
MTBhXAorLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgorICAgICAgICAgMTBx
JyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1Cisg
IGZpCisgIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFj
X3N0YXR1cyA9IDA7IH0KK2RvbmUKKworY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCithY19jbGVhbl9maWxlc19zYXZlPSRhY19jbGVh
bl9maWxlcworYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9maWxlcyBhLm91dCBhLm91dC5kU1lN
IGEuZXhlIGIub3V0IgorIyBUcnkgdG8gY3JlYXRlIGFuIGV4ZWN1dGFibGUgd2l0aG91dCAtbyBm
aXJzdCwgZGlzcmVnYXJkIGEub3V0LgorIyBJdCB3aWxsIGhlbHAgdXMgZGlhZ25vc2UgYnJva2Vu
IGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGludHVpdGlvbgorIyBvZiBleGVleHQuCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIg
dGhlIEMgY29tcGlsZXIgd29ya3MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0
aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsgfQorYWNfbGlua19kZWZhdWx0PWAkYXNfZWNo
byAiJGFjX2xpbmsiIHwgc2VkICdzLyAtbyAqY29uZnRlc3RbXiBdKi8vJ2AKKworIyBUaGUgcG9z
c2libGUgb3V0cHV0IGZpbGVzOgorYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVz
dCBhLmV4ZSBhX291dC5leGUgYi5vdXQgY29uZnRlc3QuKiIKKworYWNfcm1maWxlcz0KK2ZvciBh
Y19maWxlIGluICRhY19maWxlcworZG8KKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4
dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJn
IHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKKyAgICAqICkgYWNf
cm1maWxlcz0iJGFjX3JtZmlsZXMgJGFjX2ZpbGUiOzsKKyAgZXNhYworZG9uZQorcm0gLWYgJGFj
X3JtZmlsZXMKKworaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKK2Nhc2UgIigoJGFj
X3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cisg
ICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNf
dHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmtfZGVmYXVsdCIpIDI+JjUKKyAgYWNf
c3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBB
dXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3ZfZXhlZXh0IHZhcmlhYmxlIHRvIGBubycu
CisjIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBubycsIG90aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQg
dG8gYEVYRUVYVCA9IG5vJworIyBpbiBhIE1ha2VmaWxlLiAgV2Ugc2hvdWxkIG5vdCBvdmVycmlk
ZSBhY19jdl9leGVleHQgaWYgaXQgd2FzIGNhY2hlZCwKKyMgc28gdGhhdCB0aGUgdXNlciBjYW4g
c2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9yIGNvbXBpbGVycyB1bmtub3duIHRvCisjIEF1dG9j
b25mLgorZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzICcnCitkbworICB0ZXN0IC1mICIkYWNfZmls
ZSIgfHwgY29udGludWUKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNv
ZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAg
fCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkKKwk7OworICAgIFthYl0ub3V0ICkKKwkj
IFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMgbW9zdAor
CSMgY2VydGFpbmx5IHJpZ2h0LgorCWJyZWFrOzsKKyAgICAqLiogKQorCWlmIHRlc3QgIiR7YWNf
Y3ZfZXhlZXh0K3NldH0iID0gc2V0ICYmIHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5vOworCXRo
ZW4gOjsgZWxzZQorCSAgIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChc
Li4qXCknYAorCWZpCisJIyBXZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUgYmVjYXVzZSB0aGUgbGF0
ZXIgdGVzdCBmb3IgaXQgaXMgbm90CisJIyBzYWZlOiBjcm9zcyBjb21waWxlcnMgbWF5IG5vdCBh
ZGQgdGhlIHN1ZmZpeCBpZiBnaXZlbiBhbiBgLW8nCisJIyBhcmd1bWVudCwgc28gd2UgbWF5IG5l
ZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVhZHkuCisJIyBFdmVuIGlmIHRoaXMgc2Vj
dGlvbiBsb29rcyBjcnVmdHk6IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCisJIyBhY3R1YWxseSB3
b3JraW5nLgorCWJyZWFrOzsKKyAgICAqICkKKwlicmVhazs7CisgIGVzYWMKK2RvbmUKK3Rlc3Qg
IiRhY19jdl9leGVleHQiID0gbm8gJiYgYWNfY3ZfZXhlZXh0PQorCitlbHNlCisgIGFjX2ZpbGU9
JycKK2ZpCitpZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRoZW4gOgorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KKyRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQorc2VkICdz
L14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCit7IHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIk
YXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yIDc3ICJDIGNv
bXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJsZXMKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBt
b3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4m
NjsgfQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZS4uLiAi
ID4mNjsgfQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYWNfZmlsZSIgPiY2OyB9CithY19leGVleHQ9JGFj
X2N2X2V4ZWV4dAorCitybSAtZiAtciBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGNvbmZ0ZXN0JGFj
X2N2X2V4ZWV4dCBiLm91dAorYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZp
eCBvZiBleGVjdXRhYmxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igc3VmZml4IG9m
IGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9CitpZiB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2Ug
IigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry
eTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0i
XCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hv
ICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0
YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6CisgICMgSWYg
Ym90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNvbmZ0ZXN0JyBhcmUgYHByZXNlbnQnICh3ZWxsLCBv
YnNlcnZhYmxlKQorIyBjYXRjaCBgY29uZnRlc3QuZXhlJy4gIEZvciBpbnN0YW5jZSB3aXRoIEN5
Z3dpbiwgYGxzIGNvbmZ0ZXN0JyB3aWxsCisjIHdvcmsgcHJvcGVybHkgKGkuZS4sIHJlZmVyIHRv
IGBjb25mdGVzdC5leGUnKSwgd2hpbGUgaXQgd29uJ3Qgd2l0aAorIyBgcm0nLgorZm9yIGFjX2Zp
bGUgaW4gY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGNvbmZ0ZXN0Lio7IGRvCisgIHRlc3QgLWYgIiRh
Y19maWxlIiB8fCBjb250aW51ZQorICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwg
Ki54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAq
Lm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7OworICAgICouKiApIGFjX2N2
X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAorCSAgYnJlYWs7Owor
ICAgICogKSBicmVhazs7CisgIGVzYWMKK2RvbmUKK2Vsc2UKKyAgeyB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAk
PyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVzOiBjYW5ub3QgY29tcGlsZSBh
bmQgbGluaworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUg
OyB9CitmaQorcm0gLWYgY29uZnRlc3QgY29uZnRlc3QkYWNfY3ZfZXhlZXh0Cit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2V4ZWV4dCIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9CisKK3JtIC1mIGNvbmZ0ZXN0LiRhY19l
eHQKK0VYRUVYVD0kYWNfY3ZfZXhlZXh0CithY19leGVleHQ9JEVYRUVYVAorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
I2luY2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK0ZJTEUgKmYgPSBmb3BlbiAoImNv
bmZ0ZXN0Lm91dCIsICJ3Iik7CisgcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAw
OworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xl
YW5fZmlsZXMgY29uZnRlc3Qub3V0IgorIyBDaGVjayB0aGF0IHRoZSBjb21waWxlciBwcm9kdWNl
cyBleGVjdXRhYmxlcyB3ZSBjYW4gcnVuLiAgSWYgbm90LCBlaXRoZXIKKyMgdGhlIGNvbXBpbGVy
IGlzIGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5n
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGlu
Zy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgIT0geWVzOyB0aGVuCisg
IHsgeyBhY190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxg
KiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3Ry
eTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChl
dmFsICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9CisgIGlmIHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCcKKyAg
eyB7IGNhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNo
bz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190
cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIK
KyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX3RyeSIpIDI+JjUK
KyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9OyB0aGVu
CisgICAgY3Jvc3NfY29tcGlsaW5nPW5vCisgIGVsc2UKKyAgICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IG1heWJlOyB0aGVuCisJY3Jvc3NfY29tcGlsaW5nPXllcworICAgIGVsc2UKKwl7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFj
X3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMuCitJZiB5
b3UgbWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNlIFxgLS1ob3N0Jy4KK1NlZSBcYGNvbmZpZy5s
b2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAgIGZpCisgIGZpCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRjcm9zc19j
b21waWxpbmciID4mNQorJGFzX2VjaG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQorCitybSAt
ZiBjb25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5vdXQKK2Fj
X2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWlu
ICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorcm0gLWYgY29uZnRlc3QubyBj
b25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgorY2FzZSAiKCgkYWNfdHJ5
IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikg
YWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlf
ZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/
CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0
dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgZm9yIGFjX2ZpbGUg
aW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFj
X2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwg
Ki54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAq
Lm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAgICAqKSBhY19jdl9vYmpleHQ9YGV4cHIgIiRh
Y19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAgICBicmVhazs7CisgIGVzYWMKK2RvbmUKK2Vs
c2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3Mv
Xi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKK3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRh
c19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBjb21waWxlCitTZWUgXGBj
b25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KK2ZpCitybSAtZiBj
b25mdGVzdC4kYWNfY3Zfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X29iamV4dCIgPiY2OyB9CitPQkpFWFQ9JGFjX2N2X29iamV4dAorYWNf
b2JqZXh0PSRPQkpFWFQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxl
ci4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNl
dDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg
Ki8KKworaW50CittYWluICgpCit7CisjaWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hva2UgbWUK
KyNlbmRpZgorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2Nv
bXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY29tcGlsZXJfZ251PXllcworZWxzZQorICBh
Y19jb21waWxlcl9nbnU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2FjX2N2X2NfY29tcGlsZXJfZ251PSRhY19jb21w
aWxlcl9nbnUKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX2Nv
bXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7IHRoZW4K
KyAgR0NDPXllcworZWxzZQorICBHQ0M9CitmaQorYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0
fQorYWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9m
bGFnCisgICBhY19jX3dlcnJvcl9mbGFnPXllcworICAgYWNfY3ZfcHJvZ19jY19nPW5vCisgICBD
RkxBR1M9Ii1nIgorICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKK2Vsc2UKKyAgQ0ZMQUdTPSIiCisgICAgICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICBhY19j
X3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKKwkgQ0ZMQUdTPSItZyIKKwkgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2df
Y2NfZz15ZXMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9
JGFjX3NhdmVfY193ZXJyb3JfZmxhZworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfcHJvZ19jY19nIiA+JjY7IH0KK2lmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRo
ZW4KKyAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cg
PSB5ZXM7IHRoZW4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1n
IC1PMiIKKyAgZWxzZQorICAgIENGTEFHUz0iLWciCisgIGZpCitlbHNlCisgIGlmIHRlc3QgIiRH
Q0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItTzIiCisgIGVsc2UKKyAgICBDRkxBR1M9Cisg
IGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2N2X3Byb2dfY2NfYzg5PW5vCithY19zYXZlX0ND
PSRDQworY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+
CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKy8qIE1vc3Qg
b2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20gUkNTIDUuNydzIHNyYy9jb25m
LnNoLiAgKi8KK3N0cnVjdCBidWYgeyBpbnQgeDsgfTsKK0ZJTEUgKiAoKnJjc29wZW4pIChzdHJ1
Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7CitzdGF0aWMgY2hhciAqZSAocCwgaSkKKyAg
ICAgY2hhciAqKnA7CisgICAgIGludCBpOworeworICByZXR1cm4gcFtpXTsKK30KK3N0YXRpYyBj
aGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikKK3sKKyAg
Y2hhciAqczsKKyAgdmFfbGlzdCB2OworICB2YV9zdGFydCAodixwKTsKKyAgcyA9IGcgKHAsIHZh
X2FyZyAodixpbnQpKTsKKyAgdmFfZW5kICh2KTsKKyAgcmV0dXJuIHM7Cit9CisKKy8qIE9TRiA0
LjAgQ29tcGFxIGNjIGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQg
aGFzCisgICBmdW5jdGlvbiBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhISCcgaGV4
IGNoYXJhY3RlciBjb25zdGFudHMuCisgICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVu
Zm9ydHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKKyAgIGFzICd4Jy4gIFRo
ZSBmb2xsb3dpbmcgaW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQK
KyAgIHByb3BlciBBTlNJIG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlzIGNvbWVz
IG91dCB0cnVlLCBmb3IgYW4KKyAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vzc2Fy
eSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZworICAgdGhhdCdzIHRydWUgb25s
eSB3aXRoIC1zdGQuICAqLworaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8gMSA6IC0x
XTsKKworLyogSUJNIEMgNiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQsIGJ1dCBp
dCByZXBsYWNlcyBtYWNybyBwYXJhbWV0ZXJzCisgICBpbnNpZGUgc3RyaW5ncyBhbmQgY2hhcmFj
dGVyIGNvbnN0YW50cy4gICovCisjZGVmaW5lIEZPTyh4KSAneCcKK2ludCB4bGM2X2NjX2FycmF5
W0ZPTyhhKSA9PSAneCcgPyAxIDogLTFdOworCitpbnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsK
K3N0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Oworc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91
YmxlIGEpO307CitpbnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3Qg
YnVmICosIHN0cnVjdCBzdGF0ICosIGludCksIGludCwgaW50KTsKK2ludCBhcmdjOworY2hhciAq
KmFyZ3Y7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBd
ICB8fCAgZiAoZSwgYXJndiwgMSkgIT0gYXJndlsxXTsKKyAgOworICByZXR1cm4gMDsKK30KK19B
Q0VPRgorZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1hbnNpIC1z
dGQgXAorCS1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05TX18iCitk
bworICBDQz0iJGFjX3NhdmVfQ0MgJGFjX2FyZyIKKyAgaWYgYWNfZm5fY190cnlfY29tcGlsZSAi
JExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCitmaQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAorICB0ZXN0ICJ4JGFjX2N2X3By
b2dfY2NfYzg5IiAhPSAieG5vIiAmJiBicmVhaworZG9uZQorcm0gLWYgY29uZnRlc3QuJGFjX2V4
dAorQ0M9JGFjX3NhdmVfQ0MKKworZmkKKyMgQUNfQ0FDSEVfVkFMCitjYXNlICJ4JGFjX2N2X3By
b2dfY2NfYzg5IiBpbgorICB4KQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1CiskYXNfZWNobyAibm9uZSBuZWVkZWQi
ID4mNjsgfSA7OworICB4bm8pCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUKKyRhc19lY2hvICJ1bnN1cHBvcnRlZCIg
PiY2OyB9IDs7CisgICopCisgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCisgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9n
X2NjX2M4OSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0gOzsKK2Vz
YWMKK2lmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6CisKK2ZpCisK
K2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRD
RkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKKwor
CithY19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAk
Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBj
b25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFj
X2V4dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBy
dW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvdyB0byBy
dW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0aW1lcyAk
Q1BQIG5hbWVzIGEgZGlyZWN0b3J5LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQ
UCI7IHRoZW4KKyAgQ1BQPQorZmkKK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19DUFArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICAgICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQIG5lZWRz
IHRvIGJlIGV4cGFuZGVkCisgICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRp
b25hbC1jcHAiICIvbGliL2NwcCIKKyAgICBkbworICAgICAgYWNfcHJlcHJvY19vaz1mYWxzZQor
Zm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRl
ciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0
aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRv
IDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+
IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQs
IGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMg
bm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhp
cyBjYXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRz
Lmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRpZgorCQkgICAgIFN5bnRheCBl
cnJvcgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxz
ZQorICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCitjb250aW51ZQorZmkKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3Jr
cyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwor
ICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNf
bm9uZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxz
ZQorICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3Jt
IC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworZG9uZQorIyBC
ZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2Fz
IHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0
CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisgIGJyZWFrCitmaQorCisgICAgZG9uZQorICAg
IGFjX2N2X3Byb2dfQ1BQPSRDUFAKKworZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAorZWxzZQor
ICBhY19jdl9wcm9nX0NQUD0kQ1BQCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRDUFAiID4mNQorJGFzX2VjaG8gIiRDUFAiID4mNjsgfQorYWNf
cHJlcHJvY19vaz1mYWxzZQorZm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitk
bworICAjIFVzZSBhIGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3Vy
aW5nIGdsaWJjCisgICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFBy
ZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2lu
Y2UKKyAgIyA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMu
CisgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGls
ZXIncyBwYXJzZXIsCisgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlz
IGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19TVERDX18K
KyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRp
ZgorCQkgICAgIFN5bnRheCBlcnJvcgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5F
Tk8iOyB0aGVuIDoKKworZWxzZQorICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCitj
b250aW51ZQorZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19l
eHQKKworICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9u
ZXhpc3RlbnQgaGVhZGVycworICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlf
Y3BwICIkTElORU5PIjsgdGhlbiA6CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5w
dXQuCitjb250aW51ZQorZWxzZQorICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19v
az06CiticmVhaworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRh
Y19leHQKKworZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdz
IGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisKK2Vsc2UKKyAg
eyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRh
Y19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
Mjt9Cithc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMgc2FuaXR5
IGNoZWNrCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7
IH0KK2ZpCisKK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0n
JENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0n
JENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxl
cl9nbnUKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZSIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUuLi4g
IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9HUkVQK3NldH0iID0gc2V0OyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAteiAiJEdSRVAi
OyB0aGVuCisgIGFjX3BhdGhfR1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhyb3VnaCB0aGUg
dXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAorICBhc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhf
U0VQQVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dyZXA7IGRv
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgICAgICBhY19wYXRoX0dSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAg
ICB7IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0dSRVAi
OyB9IHx8IGNvbnRpbnVlCisjIENoZWNrIGZvciBHTlUgYWNfcGF0aF9HUkVQIGFuZCBzZWxlY3Qg
aXQgaWYgaXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9HUkVQCitjYXNl
IGAiJGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0
aF9HUkVQPSIkYWNfcGF0aF9HUkVQIiBhY19wYXRoX0dSRVBfZm91bmQ9Ojs7CisqKQorICBhY19j
b3VudD0wCisgICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6
CisgIGRvCisgICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRt
cCIKKyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0
LmluIiAiY29uZnRlc3QubmwiCisgICAgJGFzX2VjaG8gJ0dSRVAnID4+ICJjb25mdGVzdC5ubCIK
KyAgICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gpLScgPCAi
Y29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAgIGRp
ZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsK
KyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAgICBp
ZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCisgICAgICAj
IEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBv
bmUKKyAgICAgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIKKyAgICAgIGFjX3BhdGhf
R1JFUF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1
dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJy
ZWFrCisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5s
IGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX0dSRVBfZm91bmQgJiYgYnJl
YWsgMworICAgIGRvbmUKKyAgZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisgIGlmIHRl
c3QgLXogIiRhY19jdl9wYXRoX0dSRVAiOyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFj
Y2VwdGFibGUgZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3Iv
eHBnNC9iaW4iICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2X3BhdGhfR1JFUD0kR1JF
UAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfcGF0aF9HUkVQIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcGF0aF9HUkVQIiA+
JjY7IH0KKyBHUkVQPSIkYWNfY3ZfcGF0aF9HUkVQIgorCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGVncmVwIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX0VH
UkVQK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgaWYgZWNobyBhIHwgJEdSRVAgLUUgJyhhfGIpJyA+L2Rldi9udWxsIDI+JjEKKyAgIHRo
ZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCisgICBlbHNlCisgICAgIGlmIHRlc3QgLXog
IiRFR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9FR1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhy
b3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAor
ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUwor
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIGVncmVw
OyBkbworICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICAgICAgYWNfcGF0aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIK
KyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfRUdSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRo
X0VHUkVQIjsgfSB8fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfRUdSRVAgYW5k
IHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBDaGVjayBmb3IgR05VICRhY19wYXRoX0VH
UkVQCitjYXNlIGAiJGFjX3BhdGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisg
IGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VHUkVQX2ZvdW5kPTo7
OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5p
biIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIg
PiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAg
IGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgorICAgICRhc19lY2hvICdFR1JFUCcgPj4g
ImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29uZnRlc3Qu
bmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAgIGRpZmYgImNvbmZ0
ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKKyAgICBhc19m
bl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAgICBpZiB0ZXN0ICRh
Y19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9u
ZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAg
ICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIKKyAgICAgIGFjX3BhdGhfRUdSRVBf
bWF4PSRhY19jb3VudAorICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2Vl
bXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawor
ICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25m
dGVzdC5vdXQ7OworZXNhYworCisgICAgICAkYWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBicmVhayAz
CisgICAgZG9uZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAt
eiAiJGFjX2N2X3BhdGhfRUdSRVAiOyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2Vw
dGFibGUgZWdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hw
ZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQorZWxzZQorICBhY19jdl9wYXRoX0VHUkVQPSRFR1JF
UAorZmkKKworICAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wYXRo
X0VHUkVQIiA+JjY7IH0KKyBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCisKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRl
ciBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxl
cy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYytzZXR9IiA9IHNldDsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdHJp
bmcuaD4KKyNpbmNsdWRlIDxmbG9hdC5oPgorCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2N2X2hlYWRlcl9zdGRjPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1u
bworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl
c3QuJGFjX2V4dAorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAj
IFN1bk9TIDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFO
U0kuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKworX0FDRU9GCitpZiAoZXZh
bCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAibWVtY2hyIiA+
L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitm
aQorcm0gLWYgY29uZnRlc3QqCisKK2ZpCisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0g
eWVzOyB0aGVuCisgICMgSVNDIDIuMC4yIHN0ZGxpYi5oIGRvZXMgbm90IGRlY2xhcmUgZnJlZSwg
Y29udHJhcnkgdG8gQU5TSS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0ZGxpYi5oPgorCitf
QUNFT0YKK2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVH
UkVQICJmcmVlIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRl
cl9zdGRjPW5vCitmaQorcm0gLWYgY29uZnRlc3QqCisKK2ZpCisKK2lmIHRlc3QgJGFjX2N2X2hl
YWRlcl9zdGRjID0geWVzOyB0aGVuCisgICMgL2Jpbi9jYyBpbiBJcml4LTQuMC41IGdldHMgbm9u
LUFOU0kgY3R5cGUgbWFjcm9zIHVubGVzcyB1c2luZyAtYW5zaS4KKyAgaWYgdGVzdCAiJGNyb3Nz
X2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICA6CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxjdHlwZS5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2lmICgoJyAnICYgMHgwRkYpID09
IDB4MDIwKQorIyBkZWZpbmUgSVNMT1dFUihjKSAoJ2EnIDw9IChjKSAmJiAoYykgPD0gJ3onKQor
IyBkZWZpbmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMp
KQorI2Vsc2UKKyMgZGVmaW5lIElTTE9XRVIoYykgXAorCQkgICAoKCdhJyA8PSAoYykgJiYgKGMp
IDw9ICdpJykgXAorCQkgICAgIHx8ICgnaicgPD0gKGMpICYmIChjKSA8PSAncicpIFwKKwkJICAg
ICB8fCAoJ3MnIDw9IChjKSAmJiAoYykgPD0gJ3onKSkKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElT
TE9XRVIoYykgPyAoKGMpIHwgMHg0MCkgOiAoYykpCisjZW5kaWYKKworI2RlZmluZSBYT1IoZSwg
ZikgKCgoZSkgJiYgIShmKSkgfHwgKCEoZSkgJiYgKGYpKSkKK2ludAorbWFpbiAoKQoreworICBp
bnQgaTsKKyAgZm9yIChpID0gMDsgaSA8IDI1NjsgaSsrKQorICAgIGlmIChYT1IgKGlzbG93ZXIg
KGkpLCBJU0xPV0VSIChpKSkKKwl8fCB0b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkKKyAgICAg
IHJldHVybiAyOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIk
TElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KK2ZpCitybSAt
ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4k
YWNfZXh0CitmaQorCitmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNQorJGFzX2VjaG8gIiRhY19jdl9o
ZWFkZXJfc3RkYyIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhl
bgorCiskYXNfZWNobyAiI2RlZmluZSBTVERDX0hFQURFUlMgMSIgPj5jb25mZGVmcy5oCisKK2Zp
CisKKyMgT24gSVJJWCA1LjMsIHN5cy90eXBlcyBhbmQgaW50dHlwZXMuaCBhcmUgY29uZmxpY3Rp
bmcuCitmb3IgYWNfaGVhZGVyIGluIHN5cy90eXBlcy5oIHN5cy9zdGF0Lmggc3RkbGliLmggc3Ry
aW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKKwkJICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0
ZC5oCitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVh
ZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8i
ICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0CisiCitp
ZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNh
dCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFk
ZXIiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKworCisKKyAgYWNfZm5f
Y19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIm1pbml4L2NvbmZpZy5oIiAiYWNfY3Zf
aGVhZGVyX21pbml4X2NvbmZpZ19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4
JGFjX2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBNSU5JWD15
ZXMKK2Vsc2UKKyAgTUlOSVg9CitmaQorCisKKyAgaWYgdGVzdCAiJE1JTklYIiA9IHllczsgdGhl
bgorCiskYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfU09VUkNFIDEiID4+Y29uZmRlZnMuaAorCisK
KyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF8xX1NPVVJDRSAyIiA+PmNvbmZkZWZzLmgKKworCisk
YXNfZWNobyAiI2RlZmluZSBfTUlOSVggMSIgPj5jb25mZGVmcy5oCisKKyAgZmkKKworCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBp
dCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXyIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fLi4uICIgPiY2
OyB9CitpZiB0ZXN0ICIke2FjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fK3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworCisjCSAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKKwkgICRhY19pbmNsdWRlc19k
ZWZhdWx0CitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3NhZmVfdG9f
ZGVmaW5lX19fZXh0ZW5zaW9uc19fPXllcworZWxzZQorICBhY19jdl9zYWZlX3RvX2RlZmluZV9f
X2V4dGVuc2lvbnNfXz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25z
X18iID4mNQorJGFzX2VjaG8gIiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIg
PiY2OyB9CisgIHRlc3QgJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fID0geWVz
ICYmCisgICAgJGFzX2VjaG8gIiNkZWZpbmUgX19FWFRFTlNJT05TX18gMSIgPj5jb25mZGVmcy5o
CisKKyAgJGFzX2VjaG8gIiNkZWZpbmUgX0FMTF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAg
JGFzX2VjaG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFzX2Vj
aG8gIiNkZWZpbmUgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTIDEiID4+Y29uZmRlZnMuaAorCisg
ICRhc19lY2hvICIjZGVmaW5lIF9UQU5ERU1fU09VUkNFIDEiID4+Y29uZmRlZnMuaAorCisKKyMg
TWFrZSBzdXJlIHdlIGNhbiBydW4gY29uZmlnLnN1Yi4KKyRTSEVMTCAiJGFjX2F1eF9kaXIvY29u
ZmlnLnN1YiIgc3VuNCA+L2Rldi9udWxsIDI+JjEgfHwKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBydW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5PIiA1CisKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgYnVpbGQgc3lzdGVt
IHR5cGUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfYnVpbGQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19idWlsZF9hbGlhcz0kYnVpbGRfYWxp
YXMKK3Rlc3QgIngkYWNfYnVpbGRfYWxpYXMiID0geCAmJgorICBhY19idWlsZF9hbGlhcz1gJFNI
RUxMICIkYWNfYXV4X2Rpci9jb25maWcuZ3Vlc3MiYAordGVzdCAieCRhY19idWlsZF9hbGlhcyIg
PSB4ICYmCisgIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgZ3Vlc3MgYnVpbGQgdHlwZTsgeW91IG11
c3Qgc3BlY2lmeSBvbmUiICIkTElORU5PIiA1CithY19jdl9idWlsZD1gJFNIRUxMICIkYWNfYXV4
X2Rpci9jb25maWcuc3ViIiAkYWNfYnVpbGRfYWxpYXNgIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICIk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkYWNfYnVpbGRfYWxpYXMgZmFpbGVkIiAiJExJ
TkVOTyIgNQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9idWlsZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2J1aWxkIiA+JjY7IH0K
K2Nhc2UgJGFjX2N2X2J1aWxkIGluCisqLSotKikgOzsKKyopIGFzX2ZuX2Vycm9yICQ/ICJpbnZh
bGlkIHZhbHVlIG9mIGNhbm9uaWNhbCBidWlsZCIgIiRMSU5FTk8iIDUgOzsKK2VzYWMKK2J1aWxk
PSRhY19jdl9idWlsZAorYWNfc2F2ZV9JRlM9JElGUzsgSUZTPSctJworc2V0IHggJGFjX2N2X2J1
aWxkCitzaGlmdAorYnVpbGRfY3B1PSQxCitidWlsZF92ZW5kb3I9JDIKK3NoaWZ0OyBzaGlmdAor
IyBSZW1lbWJlciwgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBJRlMgaXMgdXNlZCB0byBjcmVhdGUg
JCosCisjIGV4Y2VwdCB3aXRoIG9sZCBzaGVsbHM6CitidWlsZF9vcz0kKgorSUZTPSRhY19zYXZl
X0lGUworY2FzZSAkYnVpbGRfb3MgaW4gKlwgKikgYnVpbGRfb3M9YGVjaG8gIiRidWlsZF9vcyIg
fCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9o
b3N0K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgaWYgdGVzdCAieCRob3N0X2FsaWFzIiA9IHg7IHRoZW4KKyAgYWNfY3ZfaG9zdD0kYWNf
Y3ZfYnVpbGQKK2Vsc2UKKyAgYWNfY3ZfaG9zdD1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcu
c3ViIiAkaG9zdF9hbGlhc2AgfHwKKyAgICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRhY19hdXhf
ZGlyL2NvbmZpZy5zdWIgJGhvc3RfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQorZmkKKworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
aG9zdCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hvc3QiID4mNjsgfQorY2FzZSAkYWNfY3ZfaG9z
dCBpbgorKi0qLSopIDs7CisqKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YWx1ZSBvZiBjYW5v
bmljYWwgaG9zdCIgIiRMSU5FTk8iIDUgOzsKK2VzYWMKK2hvc3Q9JGFjX2N2X2hvc3QKK2FjX3Nh
dmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4ICRhY19jdl9ob3N0CitzaGlmdAoraG9zdF9jcHU9
JDEKK2hvc3RfdmVuZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBmaXJzdCBj
aGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAorIyBleGNlcHQgd2l0aCBvbGQg
c2hlbGxzOgoraG9zdF9vcz0kKgorSUZTPSRhY19zYXZlX0lGUworY2FzZSAkaG9zdF9vcyBpbiAq
XCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKwor
CisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKKworCisKKworCisKKworCisKKworCisKKworCisKKwor
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisK
KworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUteHNt
IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3hzbStzZXR9IiA9IHNldDsgdGhlbiA6Cisg
IGVuYWJsZXZhbD0kZW5hYmxlX3hzbTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfeHNtIiA9
ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl94c209InkiCisKK2VsaWYgdGVzdCAieCRlbmFi
bGVfeHNtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3hzbT0ibiIKKworZWxpZiB0ZXN0
IC16ICRheF9jdl94c207IHRoZW4gOgorCisgICAgYXhfY3ZfeHNtPSJuIgorCitmaQoreHNtPSRh
eF9jdl94c20KKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWdpdGh0dHAgd2FzIGdpdmVuLgor
aWYgdGVzdCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZh
bD0kZW5hYmxlX2dpdGh0dHA7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0g
Inh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9InkiCisKK2VsaWYgdGVzdCAieCRl
bmFibGVfZ2l0aHR0cCIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9naXRodHRwPSJuIgor
CitlbGlmIHRlc3QgLXogJGF4X2N2X2dpdGh0dHA7IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0
cD0ibiIKKworZmkKK2dpdGh0dHA9JGF4X2N2X2dpdGh0dHAKKworIyBDaGVjayB3aGV0aGVyIC0t
ZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3Nl
dH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfbW9uaXRvcnM7CitmaQorCisK
K2lmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2
X21vbml0b3JzPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsg
dGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9t
b25pdG9yczsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKKworZmkKK21vbml0b3Jz
PSRheF9jdl9tb25pdG9ycworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtdnRwbSB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV92dHBtK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxl
dmFsPSRlbmFibGVfdnRwbTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieHll
cyI7IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ieSIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV92
dHBtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3Z0cG09Im4iCisKK2VsaWYgdGVzdCAt
eiAkYXhfY3ZfdnRwbTsgdGhlbiA6CisKKyAgICBheF9jdl92dHBtPSJuIgorCitmaQordnRwbT0k
YXhfY3ZfdnRwbQorCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUteGFwaSB3YXMgZ2l2ZW4uCitp
ZiB0ZXN0ICIke2VuYWJsZV94YXBpK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRl
bmFibGVfeGFwaTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieHllcyI7IHRo
ZW4gOgorCisgICAgYXhfY3ZfeGFwaT0ieSIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV94YXBpIiA9
ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3hhcGk9Im4iCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfeGFwaTsgdGhlbiA6CisKKyAgICBheF9jdl94YXBpPSJuIgorCitmaQoreGFwaT0kYXhfY3Zf
eGFwaQorCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtcHl0aG9udG9vbHMgd2FzIGdpdmVuLgor
aWYgdGVzdCAiJHtlbmFibGVfcHl0aG9udG9vbHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFi
bGV2YWw9JGVuYWJsZV9weXRob250b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfcHl0
aG9udG9vbHMiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4iCisK
K2VsaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAg
IGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRvb2xz
OyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCitmaQorcHl0aG9udG9vbHM9
JGF4X2N2X3B5dGhvbnRvb2xzCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xz
IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX29jYW1sdG9vbHMrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xzOworZmkKKworCitpZiB0ZXN0ICJ4
JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9v
bHM9Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4g
OgorCisgICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9vY2Ft
bHRvb2xzOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCisKK2ZpCitvY2FtbHRv
b2xzPSRheF9jdl9vY2FtbHRvb2xzCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1taW5pdGVy
bSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9taW5pdGVybStzZXR9IiA9IHNldDsgdGhl
biA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOworZmkKKworCitpZiB0ZXN0ICJ4JGVu
YWJsZV9taW5pdGVybSIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbWluaXRlcm09Inki
CisKK2VsaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInhubyI7IHRoZW4gOgorCisgICAg
YXhfY3ZfbWluaXRlcm09Im4iCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbWluaXRlcm07IHRoZW4g
OgorCisgICAgYXhfY3ZfbWluaXRlcm09Im4iCisKK2ZpCittaW5pdGVybT0kYXhfY3ZfbWluaXRl
cm0KKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWxvbW91bnQgd2FzIGdpdmVuLgoraWYgdGVz
dCAiJHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX2xvbW91bnQ7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInh5ZXMi
OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVf
bG9tb3VudCIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9sb21vdW50PSJuIgorCitlbGlm
IHRlc3QgLXogJGF4X2N2X2xvbW91bnQ7IHRoZW4gOgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIK
KworZmkKK2xvbW91bnQ9JGF4X2N2X2xvbW91bnQKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxl
LWRlYnVnIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2RlYnVnK3NldH0iID0gc2V0OyB0
aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfZGVidWc7CitmaQorCisKK2lmIHRlc3QgIngkZW5h
YmxlX2RlYnVnIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X2RlYnVnPSJuIgorCitlbGlm
IHRlc3QgIngkZW5hYmxlX2RlYnVnIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9kZWJ1
Zz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9kZWJ1ZzsgdGhlbiA6CisKKyAgICBheF9jdl9k
ZWJ1Zz0ieSIKKworZmkKK2RlYnVnPSRheF9jdl9kZWJ1ZworCisKKworCisKKworCitmb3IgY2Zs
YWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKK2RvCisgICAgUFJFUEVORF9DRkxBR1MrPSIgLUkkY2Zs
YWciCitkb25lCitmb3IgbGRmbGFnIGluICRQUkVQRU5EX0xJQgorZG8KKyAgICBQUkVQRU5EX0xE
RkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorZm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMK
K2RvCisgICAgQVBQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4g
JEFQUEVORF9MSUIKK2RvCisgICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQor
Q0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENGTEFHUyAkQVBQRU5EX0NGTEFHUyIKK0xERkxBR1M9
IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdTIgorCisKKworCisKKwor
CisKKworCisKKworIyBDaGVja3MgZm9yIHByb2dyYW1zLgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVu
Y2F0ZSBvdXRwdXQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9l
cyBub3QgdHJ1bmNhdGUgb3V0cHV0Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhf
U0VEK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgICAgICAgICAgIGFjX3NjcmlwdD1zL2FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhL2JiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYi8KKyAgICAgZm9yIGFjX2kg
aW4gMSAyIDMgNCA1IDYgNzsgZG8KKyAgICAgICBhY19zY3JpcHQ9IiRhY19zY3JpcHQkYXNfbmwk
YWNfc2NyaXB0IgorICAgICBkb25lCisgICAgIGVjaG8gIiRhY19zY3JpcHQiIDI+L2Rldi9udWxs
IHwgc2VkIDk5cSA+Y29uZnRlc3Quc2VkCisgICAgIHsgYWNfc2NyaXB0PTsgdW5zZXQgYWNfc2Ny
aXB0O30KKyAgICAgaWYgdGVzdCAteiAiJFNFRCI7IHRoZW4KKyAgYWNfcGF0aF9TRURfZm91bmQ9
ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNo
IG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIHNlZCBnc2VkOyBkbwor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICAgICAgYWNfcGF0aF9TRUQ9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAgICB7
IHRlc3QgLWYgIiRhY19wYXRoX1NFRCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfU0VEIjsgfSB8
fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfU0VEIGFuZCBzZWxlY3QgaXQgaWYg
aXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9TRUQKK2Nhc2UgYCIkYWNf
cGF0aF9TRUQiIC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfU0VEPSIk
YWNfcGF0aF9TRUQiIGFjX3BhdGhfU0VEX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAk
YXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAg
IGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYg
ImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0
ZXN0Lm5sIgorICAgICRhc19lY2hvICcnID4+ICJjb25mdGVzdC5ubCIKKyAgICAiJGFjX3BhdGhf
U0VEIiAtZiBjb25mdGVzdC5zZWQgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9k
ZXYvbnVsbCB8fCBicmVhaworICAgIGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+
L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYm
IGFjX2NvdW50PSRhc192YWwKKyAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX1NF
RF9tYXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVw
IGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9TRUQ9IiRhY19wYXRo
X1NFRCIKKyAgICAgIGFjX3BhdGhfU0VEX21heD0kYWNfY291bnQKKyAgICBmaQorICAgICMgMTAq
KDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0ZXN0ICRh
Y19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5pbiBjb25m
dGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAgJGFjX3Bh
dGhfU0VEX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRh
c19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9TRUQiOyB0aGVuCisgICAgYXNf
Zm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgc2VkIGNvdWxkIGJlIGZvdW5kIGluIFwkUEFUSCIg
IiRMSU5FTk8iIDUKKyAgZmkKK2Vsc2UKKyAgYWNfY3ZfcGF0aF9TRUQ9JFNFRAorZmkKKworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
cGF0aF9TRUQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wYXRoX1NFRCIgPiY2OyB9CisgU0VEPSIk
YWNfY3ZfcGF0aF9TRUQiCisgIHJtIC1mIGNvbmZ0ZXN0LnNlZAorCithY19leHQ9YworYWNfY3Bw
PSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBj
b25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQg
JENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCith
Y19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CitpZiB0ZXN0IC1uICIkYWNfdG9v
bF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1nY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9Z2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJEND
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNf
dG9vbF9wcmVmaXh9Z2NjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19j
dl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2
OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgZ2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19h
Y19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfYWNfY3RfQ0M9ImdjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh
ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19j
dF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0
X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAg
Q0M9IiIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQg
aW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5J
Tkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1
CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMK
KyAgICBDQz0kYWNfY3RfQ0MKKyAgZmkKK2Vsc2UKKyAgQ0M9IiRhY19jdl9wcm9nX0NDIgorZmkK
KworaWYgdGVzdCAteiAiJENDIjsgdGhlbgorICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9v
bF9wcmVmaXh9Y2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9Y2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1jYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisg
IGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3Zf
cHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICBmaQorZmkKK2lmIHRl
c3QgLXogIiRDQyI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgY2M7IGFjX3dv
cmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi
ID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhl
bgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
LgorZWxzZQorICBhY19wcm9nX3JlamVjdGVkPW5vCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBpZiB0ZXN0ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA9ICIvdXNyL3VjYi9jYyI7IHRoZW4KKyAgICAgICBhY19wcm9nX3JlamVjdGVkPXll
cworICAgICAgIGNvbnRpbnVlCisgICAgIGZpCisgICAgYWNfY3ZfcHJvZ19DQz0iY2MiCisgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJ
RlM9JGFzX3NhdmVfSUZTCisKK2lmIHRlc3QgJGFjX3Byb2dfcmVqZWN0ZWQgPSB5ZXM7IHRoZW4K
KyAgIyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIg
dXNlIGl0LgorICBzZXQgZHVtbXkgJGFjX2N2X3Byb2dfQ0MKKyAgc2hpZnQKKyAgaWYgdGVzdCAk
IyAhPSAwOyB0aGVuCisgICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVudCBjb21waWxlciBmcm9tIHRo
ZSBib2d1cyBvbmUuCisgICAgIyBIb3dldmVyLCBpdCBoYXMgdGhlIHNhbWUgYmFzZW5hbWUsIHNv
IHRoZSBib2dvbiB3aWxsIGJlIGNob3NlbgorICAgICMgZmlyc3QgaWYgd2Ugc2V0IENDIHRvIGp1
c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgorICAgIHNoaWZ0CisgICAg
YWNfY3ZfcHJvZ19DQz0iJGFzX2Rpci8kYWNfd29yZCR7MSsnICd9JEAiCisgIGZpCitmaQorZmkK
K2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19l
Y2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKwor
ZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKKyAgZG8KKyAgICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkYWNfdG9vbF9wcmVmaXgkYWNfcHJv
ZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm
b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAi
JENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKworICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKKyAgZG9uZQor
ZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZvciBhY19wcm9n
IGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfcHJvZyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3By
b2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0i
JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91
bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQor
ZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2
X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Cisk
YXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CitmaQorCisKKyAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRl
c3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitm
aQorCitmaQorCisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAibm8gYWNj
ZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2VlIFxgY29uZmlnLmxvZycgZm9y
IG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0
aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQorc2V0IFggJGFjX2Nv
bXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAt
cXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIK
K2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c
JGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRh
c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19v
cHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMg
Y29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcxMGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0
cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIx
CisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNv
bmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8g
PSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2Ug
YXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3
aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQor
eworI2lmbmRlZiBfX0dOVUNfXworICAgICAgIGNob2tlIG1lCisjZW5kaWYKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2NvbXBpbGVyX2dudT15ZXMKK2Vsc2UKKyAgYWNfY29tcGlsZXJfZ251PW5vCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CithY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251CisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29t
cGlsZXJfZ251IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQor
aWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCisgIEdDQz15ZXMKK2Vsc2UKKyAg
R0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KK2FjX3NhdmVfQ0ZMQUdTPSRD
RkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
d2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVy
ICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfZytz
ZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNfY193ZXJyb3Jf
ZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIKKyAgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2Nj
X2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4g
KCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY193ZXJyb3JfZmxhZz0kYWNfc2F2
ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWlu
ICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitmaQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Citm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2Zs
YWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfZyIgPiY2OyB9
CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCisgIENGTEFHUz0kYWNfc2F2
ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVuCisgIGlmIHRl
c3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItZyAtTzIiCisgIGVsc2UKKyAgICBD
RkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAg
IENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPQorICBmaQorZmkKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8g
YWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRDQyBvcHRpb24g
dG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19j
ODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
bmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBl
cy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVz
dHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVm
IHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3Rh
dCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBp
bnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykg
KGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3Qg
djsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZh
X2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21l
IHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJv
dG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRz
LgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFk
IGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMg
YW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2Rl
LiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisg
ICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0w
IHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2lu
dCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisKKy8qIElCTSBDIDYgZm9y
IEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFy
YW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwor
I2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6
IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYp
IChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJu
YW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAq
LCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2OworaW50CittYWluICgp
Cit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4g
JycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9I
UFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAgQ0M9IiRhY19zYXZlX0ND
ICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIg
JiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0NDPSRhY19zYXZlX0NDCisK
K2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KKyAgeCkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9u
ZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKKyAgeG5vKQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1
cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OworICAqKQorICAg
IENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitpZiB0ZXN0ICJ4JGFjX2N2
X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9CitMTl9T
PSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8g
InllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2VjaG8gIm5vLCB1c2luZyAk
TE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAi
ID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2Vk
ICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgInRlc3QgXCJcJHthY19j
dl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQrc2V0fVwiIiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCA+Y29uZnRlc3QubWFrZSA8PFxfQUNF
T0YKK1NIRUxMID0gL2Jpbi9zaAorYWxsOgorCUBlY2hvICdAQEAlJSU9JChNQUtFKT1AQEAlJSUn
CitfQUNFT0YKKyMgR05VIG1ha2Ugc29tZXRpbWVzIHByaW50cyAibWFrZVsxXTogRW50ZXJpbmcg
Li4uIiwgd2hpY2ggd291bGQgY29uZnVzZSB1cy4KK2Nhc2UgYCR7TUFLRS1tYWtlfSAtZiBjb25m
dGVzdC5tYWtlIDI+L2Rldi9udWxsYCBpbgorICAqQEBAJSUlPT8qPUBAQCUlJSopCisgICAgZXZh
bCBhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQ9eWVzOzsKKyAgKikKKyAgICBldmFsIGFj
X2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD1ubzs7Citlc2FjCitybSAtZiBjb25mdGVzdC5t
YWtlCitmaQoraWYgZXZhbCB0ZXN0IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0g
eWVzOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisgIFNFVF9NQUtFPQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgU0VUX01BS0U9Ik1BS0U9JHtNQUtFLW1ha2V9Igor
ZmkKKworIyBGaW5kIGEgZ29vZCBpbnN0YWxsIHByb2dyYW0uICBXZSBwcmVmZXIgYSBDIHByb2dy
YW0gKGZhc3RlciksCisjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBhbm90aGVyLiAgQnV0
IGF2b2lkIHRoZSBicm9rZW4gb3IKKyMgaW5jb21wYXRpYmxlIHZlcnNpb25zOgorIyBTeXNWIC9l
dGMvaW5zdGFsbCwgL3Vzci9zYmluL2luc3RhbGwKKyMgU3VuT1MgL3Vzci9ldGMvaW5zdGFsbAor
IyBJUklYIC9zYmluL2luc3RhbGwKKyMgQUlYIC9iaW4vaW5zdGFsbAorIyBBbWlnYU9TIC9DL2lu
c3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxvcHB5IGRpc2NzCisjIEFJWCA0
IC91c3IvYmluL2luc3RhbGxic2QsIHdoaWNoIGRvZXNuJ3Qgd29yayB3aXRob3V0IGEgLWcgZmxh
ZworIyBBRlMgL3Vzci9hZnN3cy9iaW4vaW5zdGFsbCwgd2hpY2ggbWlzaGFuZGxlcyBub25leGlz
dGVudCBhcmdzCisjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRo
ZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCisjIE9TLzIncyBzeXN0ZW0gaW5zdGFsbCwgd2hp
Y2ggaGFzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2VtYW50aWMKKyMgLi9pbnN0YWxsLCB3aGlj
aCBjYW4gYmUgZXJyb25lb3VzbHkgY3JlYXRlZCBieSBtYWtlIGZyb20gLi9pbnN0YWxsLnNoLgor
IyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZp
bGVzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwuLi4gIiA+JjY7IH0KK2lmIHRlc3QgLXogIiRJTlNU
QUxMIjsgdGhlbgoraWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgIyBBY2Nv
dW50IGZvciBwZW9wbGUgd2hvIHB1dCB0cmFpbGluZyBzbGFzaGVzIGluIFBBVEggZWxlbWVudHMu
CitjYXNlICRhc19kaXIvIGluICMoKAorICAuLyB8IC4vLyB8IC9bY0NdLyogfCBcCisgIC9ldGMv
KiB8IC91c3Ivc2Jpbi8qIHwgL3Vzci9ldGMvKiB8IC9zYmluLyogfCAvdXNyL2Fmc3dzL2Jpbi8q
IHwgXAorICA/OltcXC9db3MyW1xcL11pbnN0YWxsW1xcL10qIHwgPzpbXFwvXU9TMltcXC9dSU5T
VEFMTFtcXC9dKiB8IFwKKyAgL3Vzci91Y2IvKiApIDs7CisgICopCisgICAgIyBPU0YxIGFuZCBT
Q08gT0RUIDMuMCBoYXZlIHRoZWlyIG93biBuYW1lcyBmb3IgaW5zdGFsbC4KKyAgICAjIERvbid0
IHVzZSBpbnN0YWxsYnNkIGZyb20gT1NGIHNpbmNlIGl0IGluc3RhbGxzIHN0dWZmIGFzIHJvb3QK
KyAgICAjIGJ5IGRlZmF1bHQuCisgICAgZm9yIGFjX3Byb2cgaW4gZ2luc3RhbGwgc2NvaW5zdCBp
bnN0YWxsOyBkbworICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisJaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
CSAgaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBkc3Btc2cgIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgorCSAgICAjIEFJ
WCBpbnN0YWxsLiAgSXQgaGFzIGFuIGluY29tcGF0aWJsZSBjYWxsaW5nIGNvbnZlbnRpb24uCisJ
ICAgIDoKKwkgIGVsaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBwd3Bs
dXMgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgor
CSAgICAjIHByb2dyYW0tc3BlY2lmaWMgaW5zdGFsbCBzY3JpcHQgdXNlZCBieSBIUCBwd3BsdXMt
LWRvbid0IHVzZS4KKwkgICAgOgorCSAgZWxzZQorCSAgICBybSAtcmYgY29uZnRlc3Qub25lIGNv
bmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwkgICAgZWNobyBvbmUgPiBjb25mdGVzdC5vbmUKKwkg
ICAgZWNobyB0d28gPiBjb25mdGVzdC50d28KKwkgICAgbWtkaXIgY29uZnRlc3QuZGlyCisJICAg
IGlmICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAtYyBjb25mdGVzdC5vbmUgY29uZnRl
c3QudHdvICJgcHdkYC9jb25mdGVzdC5kaXIiICYmCisJICAgICAgdGVzdCAtcyBjb25mdGVzdC5v
bmUgJiYgdGVzdCAtcyBjb25mdGVzdC50d28gJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRp
ci9jb25mdGVzdC5vbmUgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRpci9jb25mdGVzdC50
d28KKwkgICAgdGhlbgorCSAgICAgIGFjX2N2X3BhdGhfaW5zdGFsbD0iJGFzX2Rpci8kYWNfcHJv
ZyRhY19leGVjX2V4dCAtYyIKKwkgICAgICBicmVhayAzCisJICAgIGZpCisJICBmaQorCWZpCisg
ICAgICBkb25lCisgICAgZG9uZQorICAgIDs7Citlc2FjCisKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitybSAtcmYgY29uZnRlc3Qub25lIGNvbmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwor
ZmkKKyAgaWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KKyAg
ICBJTlNUQUxMPSRhY19jdl9wYXRoX2luc3RhbGwKKyAgZWxzZQorICAgICMgQXMgYSBsYXN0IHJl
c29ydCwgdXNlIHRoZSBzbG93IHNoZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKKyAgICAjIHZh
bHVlIGZvciBJTlNUQUxMIHdpdGhpbiBhIHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2UgdGhhdCB3
aWxsCisgICAgIyBicmVhayBvdGhlciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBk
aXJlY3RvcnkgaXMKKyAgICAjIHJlbW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZl
IG5hbWUuCisgICAgSU5TVEFMTD0kYWNfaW5zdGFsbF9zaAorICBmaQorZmkKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSU5TVEFMTCIgPiY1CiskYXNf
ZWNobyAiJElOU1RBTEwiID4mNjsgfQorCisjIFVzZSB0ZXN0IC16IGJlY2F1c2UgU3VuT1M0IHNo
IG1pc2hhbmRsZXMgYnJhY2VzIGluICR7dmFyLXZhbH0uCisjIEl0IHRoaW5rcyB0aGUgZmlyc3Qg
Y2xvc2UgYnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgordGVzdCAteiAiJElO
U1RBTExfUFJPR1JBTSIgJiYgSU5TVEFMTF9QUk9HUkFNPScke0lOU1RBTEx9JworCit0ZXN0IC16
ICIkSU5TVEFMTF9TQ1JJUFQiICYmIElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworCit0ZXN0
IC16ICIkSU5TVEFMTF9EQVRBIiAmJiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0Jwor
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBlcmwiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHBlcmw7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX1BFUkwrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRQRVJMIGluCisgIFtcXC9dKiB8ID86W1xcL10q
KQorICBhY19jdl9wYXRoX1BFUkw9IiRQRVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9QRVJMPSIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19j
dl9wYXRoX1BFUkwiICYmIGFjX2N2X3BhdGhfUEVSTD0ibm8iCisgIDs7Citlc2FjCitmaQorUEVS
TD0kYWNfY3ZfcGF0aF9QRVJMCitpZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQRVJMIiA+JjUKKyRhc19l
Y2hvICIkUEVSTCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKwor
CitpZiB0ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAi
VW5hYmxlIHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3RhbGwgcGVybCIgIiRMSU5FTk8iIDUKK2Zp
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJyY3RsIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBicmN0bDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3BhdGhfQlJDVEwrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCUkNUTCBpbgorICBbXFwvXSogfCA/Oltc
XC9dKikKKyAgYWNfY3ZfcGF0aF9CUkNUTD0iJEJSQ1RMIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CUkNUTD0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9CUkNUTCIgJiYgYWNfY3ZfcGF0aF9CUkNUTD0ibm8iCisgIDs7Citlc2Fj
CitmaQorQlJDVEw9JGFjX2N2X3BhdGhfQlJDVEwKK2lmIHRlc3QgLW4gIiRCUkNUTCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCUkNU
TCIgPiY1CiskYXNfZWNobyAiJEJSQ1RMIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIg
PiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JSQ1RMfSIgPT0geCJubyIKK3RoZW4KKyAgICBh
c19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYnJjdGwsIHBsZWFzZSBpbnN0YWxsIGJyY3Rs
IiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiaXAiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGlwOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9JUCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJElQIGluCisgIFtcXC9dKiB8
ID86W1xcL10qKQorICBhY19jdl9wYXRoX0lQPSIkSVAiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0lQPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRh
Y19jdl9wYXRoX0lQIiAmJiBhY19jdl9wYXRoX0lQPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitJUD0k
YWNfY3ZfcGF0aF9JUAoraWYgdGVzdCAtbiAiJElQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElQIiA+JjUKKyRhc19lY2hvICIkSVAi
ID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4
IiR7SVB9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCBpcCwgcGxlYXNlIGluc3RhbGwgaXAiICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJiaXNvbiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgYmlzb247IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRo
X0JJU09OK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgY2FzZSAkQklTT04gaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3Bh
dGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQklTT049IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQklT
T04iICYmIGFjX2N2X3BhdGhfQklTT049Im5vIgorICA7OworZXNhYworZmkKK0JJU09OPSRhY19j
dl9wYXRoX0JJU09OCitpZiB0ZXN0IC1uICIkQklTT04iOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQklTT04iID4mNQorJGFzX2VjaG8g
IiRCSVNPTiIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitp
ZiB0ZXN0IHgiJHtCSVNPTn0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kIGJpc29uLCBwbGVhc2UgaW5zdGFsbCBiaXNvbiIgIiRMSU5FTk8iIDUKK2Zp
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImZsZXgiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGZsZXg7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX0ZMRVgrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRGTEVYIGluCisgIFtcXC9dKiB8ID86W1xcL10q
KQorICBhY19jdl9wYXRoX0ZMRVg9IiRGTEVYIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9GTEVYPSIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19j
dl9wYXRoX0ZMRVgiICYmIGFjX2N2X3BhdGhfRkxFWD0ibm8iCisgIDs7Citlc2FjCitmaQorRkxF
WD0kYWNfY3ZfcGF0aF9GTEVYCitpZiB0ZXN0IC1uICIkRkxFWCI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRGTEVYIiA+JjUKKyRhc19l
Y2hvICIkRkxFWCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKwor
CitpZiB0ZXN0IHgiJHtGTEVYfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAi
VW5hYmxlIHRvIGZpbmQgZmxleCwgcGxlYXNlIGluc3RhbGwgZmxleCIgIiRMSU5FTk8iIDUKK2Zp
CitpZiB0ZXN0ICJ4JHhhcGkiID0gInh5IjsgdGhlbiA6CisKKyAgICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImN1cmwtY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfQ1VSTCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJENVUkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisg
IGFjX2N2X3BhdGhfQ1VSTD0iJENVUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0NVUkw9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfQ1VSTCIgJiYgYWNfY3ZfcGF0aF9DVVJMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitDVVJMPSRh
Y19jdl9wYXRoX0NVUkwKK2lmIHRlc3QgLW4gIiRDVVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENVUkwiID4mNQorJGFzX2VjaG8g
IiRDVVJMIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lm
IHRlc3QgeCIke0NVUkx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCBjdXJsLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgY3VybC1jb25maWciICIkTElO
RU5PIiA1CitmaQorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieG1sMi1jb25maWci
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHhtbDIt
Y29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YTUwrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRY
TUwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfWE1MPSIkWE1MIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAg
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU
SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf
cGF0aF9YTUw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVf
SUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWE1MIiAmJiBhY19jdl9wYXRoX1hNTD0ibm8i
CisgIDs7Citlc2FjCitmaQorWE1MPSRhY19jdl9wYXRoX1hNTAoraWYgdGVzdCAtbiAiJFhNTCI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRYTUwiID4mNQorJGFzX2VjaG8gIiRYTUwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7WE1MfSIgPT0geCJubyIKK3RoZW4KKyAgICBh
c19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sMi1jb25maWcsIHBsZWFzZSBpbnN0YWxs
IHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQorZmkKKworZmkKK2lmIHRlc3QgIngkb2NhbWx0b29s
cyIgPSAieHkiOyB0aGVuIDoKKworICAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIGlmIHRl
c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGM7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEMi
OyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
YyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitPQ0FNTEM9JGFjX2N2X3Byb2dfT0NB
TUxDCitpZiB0ZXN0IC1uICIkT0NBTUxDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQyIgPiY1CiskYXNfZWNobyAiJE9DQU1M
QyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgorICBhY19jdF9PQ0FNTEM9JE9DQU1M
QworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxjOyBhY193b3JkPSQyCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNf
d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0K
K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0iJGFjX2N0X09DQU1MQyIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFz
X3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
Qz0ib2NhbWxjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MQz0k
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
KyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDIiA9
IHg7IHRoZW4KKyAgICBPQ0FNTEM9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xf
d2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MQz0kYWNfY3RfT0NBTUxDCisgIGZpCitlbHNl
CisgIE9DQU1MQz0iJGFjX2N2X3Byb2dfT0NBTUxDIgorZmkKKworCisgIGlmIHRlc3QgIiRPQ0FN
TEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1u
IC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZF
UlNJT04iID4mNQorJGFzX2VjaG8gIk9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY2
OyB9CisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAgaWYgdGVzdCAiJE9D
QU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9k
ZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAorICAgICBlbHNl
CisgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQorJGFzX2VjaG8g
Ik9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9CisgICAgIGZp
CisgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBP
Q2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjUKKyRhc19lY2hvICJPQ2FtbCBsaWJy
YXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjY7IH0KKworCisKKworICAgICAjIGNoZWNraW5nIGZv
ciBvY2FtbG9wdAorICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29s
X3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NB
TUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxP
UFQ9IiRPQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCith
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRI
CitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9w
cm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitmaQorZmkKK09DQU1MT1BUPSRhY19jdl9wcm9nX09DQU1MT1BUCitpZiB0ZXN0IC1u
ICIkT0NBTUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVCIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAi
JGFjX2N2X3Byb2dfT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BUPSRPQ0FNTE9QVAor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbG9wdDsgYWNfd29yZD0kMgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQ9IiRhY19jdF9P
Q0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MT1BUPSJvY2FtbG9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCith
Y19jdF9PQ0FNTE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVAoraWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BUIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NB
TUxPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxPUFQ9Im5vIgorICBl
bHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1M
T1BUPSRhY19jdF9PQ0FNTE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVD0iJGFjX2N2X3Byb2df
T0NBTUxPUFQiCitmaQorCisgICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FN
TE9QVCIgPSAibm8iOyB0aGVuCisJeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24g
b25seS4iID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxv
cHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuIiA+JjI7fQorICAgICBlbHNlCisJVE1QVkVS
U0lPTj1gJE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8
cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJ
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJz
aW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19l
Y2hvICJ2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+
JjY7IH0KKwkgICAgT0NBTUxPUFQ9bm8KKwllbHNlCisJICAgIE9DQU1MQkVTVD1vcHQKKwlmaQor
ICAgICBmaQorCisKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0CisgICAgIGlmIHRl
c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdDsg
YWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxDRE9UT1BUK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAtbiAiJE9DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiRP
Q0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19PQ0FNTENET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKKworZmkKK2ZpCitPQ0FNTENET1RPUFQ9JGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BU
CitpZiB0ZXN0IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQ0RPVE9QVCIgPiY1CiskYXNfZWNo
byAiJE9DQU1MQ0RPVE9QVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQor
ZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUIjsgdGhlbgor
ICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIm9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTENET1RP
UFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSIkYWNfY3RfT0NBTUxD
RE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDRE9UT1BUPSJvY2FtbGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK2FjX2N0X09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQKK2lm
IHRlc3QgLW4gIiRhY19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjUK
KyRhc19lY2hvICIkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDRE9UT1BUIiA9IHg7
IHRoZW4KKyAgICBPQ0FNTENET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29t
cGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rv
b2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MQ0RPVE9QVD0kYWNfY3RfT0NBTUxDRE9U
T1BUCisgIGZpCitlbHNlCisgIE9DQU1MQ0RPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BU
IgorZmkKKworICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1Q
VkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4q
XCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsg
dGhlbgorCSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+
JjUKKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRp
c2NhcmRlZC4iID4mNjsgfQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQor
ICAgICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0
ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxPUFRE
T1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiRPQ0FNTE9QVERPVE9Q
VCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MT1BU
RE9UT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKKworZmkKK2ZpCitPQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAor
aWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19l
Y2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIjsg
dGhlbgorICBhY19jdF9PQ0FNTE9QVERPVE9QVD0kT0NBTUxPUFRET1RPUFQKKyAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Citp
ZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
YWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE
T1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUPSJvY2FtbG9wdC5vcHQiCisg
ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25l
CitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERP
VE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1M
T1BURE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisg
IGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFRET1RPUFQiID0geDsgdGhlbgorICAgIE9DQU1MT1BU
RE9UT1BUPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93
YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxl
dCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsK
K2VzYWMKKyAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NBTUxPUFRET1RPUFQKKyAgZmkKK2Vs
c2UKKyAgT0NBTUxPUFRET1RPUFQ9IiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIgorZmkKKwor
CWlmIHRlc3QgIiRPQ0FNTE9QVERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCSAgIFRNUFZFUlNJT049
YCRPQ0FNTE9QVERPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwx
fHAnIGAKKwkgICBpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhl
bgorCSAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuIiA+
JjUKKyRhc19lY2hvICJ2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBk
aXNjYXJkZWQuIiA+JjY7IH0KKwkgICBlbHNlCisJICAgICAgT0NBTUxPUFQ9JE9DQU1MT1BURE9U
T1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAgZmkKKworCisgIGZpCisKKworCisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19PQ0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTD0i
JE9DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NB
TUw9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorT0NBTUw9JGFjX2N2X3Byb2dfT0NBTUwKK2lmIHRlc3QgLW4gIiRPQ0FNTCI7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTCIg
PiY1CiskYXNfZWNobyAiJE9DQU1MIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTCI7IHRoZW4KKyAg
YWNfY3RfT0NBTUw9JE9DQU1MCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWwi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1s
OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTCtzZXR9IiA9
IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0iJGFj
X2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUw9Im9jYW1sIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0
X09DQU1MPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUwi
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3RfT0NBTUwiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1M
IiA9IHg7IHRoZW4KKyAgICBPQ0FNTD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUw9JGFjX2N0X09DQU1MCisgIGZpCitlbHNl
CisgIE9DQU1MPSIkYWNfY3ZfcHJvZ19PQ0FNTCIKK2ZpCisKKworICAjIGNoZWNraW5nIGZvciBv
Y2FtbGRlcAorICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZp
eH1vY2FtbGRlcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxERVAr
c2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQor
ICBpZiB0ZXN0IC1uICIkT0NBTUxERVAiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiRP
Q0FNTERFUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09D
QU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgorICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwor
CitmaQorZmkKK09DQU1MREVQPSRhY19jdl9wcm9nX09DQU1MREVQCitpZiB0ZXN0IC1uICIkT0NB
TUxERVAiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxERVAiID4mNQorJGFzX2VjaG8gIiRPQ0FNTERFUCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxERVAiOyB0aGVuCisgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAorICAjIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRlcDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxERVAiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9IiRhY19jdF9PQ0FNTERF
UCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09D
QU1MREVQPSJvY2FtbGRlcCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAy
CisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9P
Q0FNTERFUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MREVQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X09DQU1MREVQIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxERVAi
ID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAi
eCRhY19jdF9PQ0FNTERFUCIgPSB4OyB0aGVuCisgICAgT0NBTUxERVA9Im5vIgorICBlbHNlCisg
ICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3Mg
dG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp
cGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MREVQPSRh
Y19jdF9PQ0FNTERFUAorICBmaQorZWxzZQorICBPQ0FNTERFUD0iJGFjX2N2X3Byb2dfT0NBTUxE
RVAiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHth
Y190b29sX3ByZWZpeH1vY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MTUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NB
TUxNS1RPUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QPSIkT0NBTUxNS1RPUCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2Zp
CitPQ0FNTE1LVE9QPSRhY19jdl9wcm9nX09DQU1MTUtUT1AKK2lmIHRlc3QgLW4gIiRPQ0FNTE1L
VE9QIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJE9DQU1MTUtUT1AiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LVE9QIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNf
Y3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LVE9QPSRPQ0FNTE1LVE9Q
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta3RvcCIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxta3RvcDsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUCtzZXR9IiA9IHNl
dDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtU
T1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0ib2NhbWxta3RvcCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE1LVE9QPSRhY19jdl9wcm9nX2FjX2N0X09DQU1M
TUtUT1AKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtUT1Ai
ID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19l
Y2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4
OyB0aGVuCisgICAgT0NBTUxNS1RPUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAor
ICBmaQorZWxzZQorICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgorZmkKKwor
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl
Zml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0
aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxNS0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NBTUxNS0xJ
Qj0kYWNfY3ZfcHJvZ19PQ0FNTE1LTElCCitpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TE1LTElCIiA+JjUKKyRhc19lY2hvICIkT0NBTUxNS0xJQiIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NB
TUxNS0xJQiI7IHRoZW4KKyAgYWNfY3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgorICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3Jk
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSIkYWNfY3Rf
T0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MTUtMSUI9Im9jYW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorYWNfY3RfT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCCitpZiB0
ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LTElCIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3RfT0NBTUxNS0xJQiIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgorICAg
IE9DQU1MTUtMSUI9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190
b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0
cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz
IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXll
cyA7OworZXNhYworICAgIE9DQU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKKyAgZmkKK2Vsc2UK
KyAgT0NBTUxNS0xJQj0iJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiIKK2ZpCisKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbGRvYworICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRvYyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190
b29sX3ByZWZpeH1vY2FtbGRvYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2df
T0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NB
TUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNl
Cithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wcm9nX09DQU1MRE9DPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgorICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19z
YXZlX0lGUworCitmaQorZmkKK09DQU1MRE9DPSRhY19jdl9wcm9nX09DQU1MRE9DCitpZiB0ZXN0
IC1uICIkT0NBTUxET0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRPQ0FNTERPQyIgPiY2
OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfT0NBTUxET0MiOyB0aGVuCisgIGFjX2N0X09DQU1MRE9DPSRPQ0FNTERP
QworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRvYzsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
YWNfY3RfT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9IiRhY19j
dF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MRE9DPSJvY2FtbGRvYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2Zp
CithY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQworaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKKyRhc19lY2hvICIkYWNfY3Rf
T0NBTUxET0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9PQ0FNTERPQyIgPSB4OyB0aGVuCisgICAgT0NBTUxET0M9Im5vIgor
ICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVz
OikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNp
bmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19l
Y2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9D
QU1MRE9DPSRhY19jdF9PQ0FNTERPQworICBmaQorZWxzZQorICBPQ0FNTERPQz0iJGFjX2N2X3By
b2dfT0NBTUxET0MiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAorICBpZiB0
ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQ7
IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQlVJTEQrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIkT0NBTUxC
VUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1M
QlVJTEQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZCIKKyAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK
KworZmkKK2ZpCitPQ0FNTEJVSUxEPSRhY19jdl9wcm9nX09DQU1MQlVJTEQKK2lmIHRlc3QgLW4g
IiRPQ0FNTEJVSUxEIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJE9DQU1MQlVJTEQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTEJVSUxEIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdF9PQ0FNTEJVSUxEPSRP
Q0FNTEJVSUxECisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxidWls
ZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRCtz
ZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MQlVJTEQ9IiRhY19jdF9PQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0ib2NhbWxidWlsZCIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTEJVSUxEPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MQlVJTEQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09D
QU1MQlVJTEQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEJVSUxEIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxC
VUlMRCIgPSB4OyB0aGVuCisgICAgT0NBTUxCVUlMRD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxCVUlMRD0kYWNfY3RfT0NB
TUxCVUlMRAorICBmaQorZWxzZQorICBPQ0FNTEJVSUxEPSIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxE
IgorZmkKKworCisgICAgaWYgdGVzdCAieCRPQ0FNTEMiID0gInhubyI7IHRoZW4gOgorCisgICAg
ICAgIGlmIHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAg
ICAgICAgICAgYXNfZm5fZXJyb3IgJD8gIk9jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUg
dG8gZmluZCBPY2FtbCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgICAgIG9jYW1sdG9vbHM9Im4iCisK
K2ZpCisKK2ZpCisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJhc2giLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGJhc2g7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgdGVzdCAiJHthY19jdl9wYXRoX0JBU0grc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCQVNIIGluCisgIFtcXC9dKiB8
ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CQVNIPSIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAg
IGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3Qg
LXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3BhdGhfQkFTSD0ibm8iCisgIDs7Citlc2Fj
CitmaQorQkFTSD0kYWNfY3ZfcGF0aF9CQVNICitpZiB0ZXN0IC1uICIkQkFTSCI7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCQVNIIiA+
JjUKKyRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorZmkKKworCitpZiB0ZXN0IHgiJHtCQVNIfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmFzaCwgcGxlYXNlIGluc3RhbGwgYmFzaCIgIiRMSU5F
Tk8iIDUKK2ZpCitpZiB0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSI7IHRoZW4gOgorCisgICAg
aWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyI7IHRoZW4gOgorCisgICAgICAgIFBZVEhP
TlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorCitl
bGlmIHRlc3QgLXogIiRQWVRIT04iOyB0aGVuIDoKKyAgUFlUSE9OPSJweXRob24iCitlbHNlCisg
IGFzX2ZuX2Vycm9yICQ/ICJQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRl
IHBhdGgiICIkTElORU5PIiA1CitmaQorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
JFBZVEhPTiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgJFBZVEhPTjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfUFlUSE9OUEFU
SCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhc2UgJFBZVEhPTlBBVEggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3Bh
dGhfUFlUSE9OUEFUSD0iJFBZVEhPTlBBVEgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9IiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAi
JGFjX2N2X3BhdGhfUFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKKyAg
OzsKK2VzYWMKK2ZpCitQWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZVEhPTlBBVEgKK2lmIHRlc3Qg
LW4gIiRQWVRIT05QQVRIIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJFBZVEhPTlBBVEgiID4mNQorJGFzX2VjaG8gIiRQWVRIT05QQVRI
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3Qg
eCIke1BZVEhPTlBBVEh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCAkUFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQor
ZmkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBweXRob24gdmVyc2lvbiA+PSAyLjMgIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBweXRob24gdmVyc2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0
IHN5czsgZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKK2lmIHRlc3Qg
IiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYAor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICAgIGFzX2ZuX2Vycm9yICQ/ICIkcHl0aG9uX3Zl
cnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMyIgIiRMSU5F
Tk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKKyAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRob24geG1s
LmRvbS5taW5pZG9tIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24geG1sLmRv
bS5taW5pZG9tLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20ubWluaWRv
bSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIHhtbC5kb20ubWluaWRvbSBtb2R1
bGUiICIkTElORU5PIiA1CitlbHNlCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KK2ZpCisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
cHl0aG9uIGRldmVsIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24gZGV2ZWwu
Li4gIiA+JjY7IH0KKworYCRQWVRIT04gLWMgJworaW1wb3J0IG9zLnBhdGgsIHN5cworZm9yIHAg
aW4gc3lzLnBhdGg6CisgICAgaWYgb3MucGF0aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxl
Iik6CisgICAgICAgIHN5cy5leGl0KDApCitzeXMuZXhpdCgxKQorJyA+IC9kZXYvbnVsbCAyPiYx
YAorCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CisgICAgYXNfZm5fZXJyb3IgJD8gIlB5dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZCIgIiRM
SU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKKworZmkKKyMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
IHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhHRVRURVhUIGluCisgIFtcXC9d
KiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1hHRVRURVhUPSIkWEdFVFRFWFQiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRo
X1hHRVRURVhUPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hHRVRURVhUIiAmJiBhY19jdl9wYXRoX1hH
RVRURVhUPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitYR0VUVEVYVD0kYWNfY3ZfcGF0aF9YR0VUVEVY
VAoraWYgdGVzdCAtbiAiJFhHRVRURVhUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhHRVRURVhUIiA+JjUKKyRhc19lY2hvICIkWEdF
VFRFWFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYg
dGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJV
bmFibGUgdG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5P
IiA1CitmaQoraWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4KKyAgICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInVkZXZhZG0iLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHVkZXZhZG07IGFjX3dvcmQ9JDIKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3Jk
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9wYXRoX1VERVZBRE0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRVREVWQURNIGluCisgIFtcXC9dKiB8
ID86W1xcL10qKQorICBhY19jdl9wYXRoX1VERVZBRE09IiRVREVWQURNIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9VREVW
QURNPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwor
CisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1VERVZBRE0iICYmIGFjX2N2X3BhdGhfVURFVkFETT0i
bm8iCisgIDs7Citlc2FjCitmaQorVURFVkFETT0kYWNfY3ZfcGF0aF9VREVWQURNCitpZiB0ZXN0
IC1uICIkVURFVkFETSI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRVREVWQURNIiA+JjUKKyRhc19lY2hvICIkVURFVkFETSIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgaWYgdGVzdCB4IiR7
VURFVkFETX0iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgInVkZXZpbmZvIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSB1ZGV2aW5mbzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Bh
dGhfVURFVklORk8rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXNlICRVREVWSU5GTyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAg
YWNfY3ZfcGF0aF9VREVWSU5GTz0iJFVERVZJTkZPIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9VREVWSU5GTz0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9VREVWSU5GTyIgJiYgYWNfY3ZfcGF0aF9VREVWSU5GTz0ibm8iCisgIDs7
Citlc2FjCitmaQorVURFVklORk89JGFjX2N2X3BhdGhfVURFVklORk8KK2lmIHRlc3QgLW4gIiRV
REVWSU5GTyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRVREVWSU5GTyIgPiY1CiskYXNfZWNobyAiJFVERVZJTkZPIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICAgICAgaWYgdGVzdCB4IiR7
VURFVklORk99IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBhc19mbl9lcnJv
ciAkPyAiVW5hYmxlIHRvIGZpbmQgdWRldmFkbSBvciB1ZGV2aW5mbywgcGxlYXNlIGluc3RhbGwg
dWRldiIgIiRMSU5FTk8iIDUKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5G
T30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7
VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVz
dCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICJob3RwbHVnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBob3RwbHVnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0
aF9IT1RQTFVHK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgY2FzZSAkSE9UUExVRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNf
Y3ZfcGF0aF9IT1RQTFVHPSIkSE9UUExVRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl
c3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMK
KyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfSE9UUExVRz0iJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAy
CisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9IT1RQTFVHIiAmJiBhY19jdl9wYXRoX0hPVFBMVUc9Im5vIgorICA7OworZXNhYwor
ZmkKK0hPVFBMVUc9JGFjX2N2X3BhdGhfSE9UUExVRworaWYgdGVzdCAtbiAiJEhPVFBMVUciOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
SE9UUExVRyIgPiY1CiskYXNfZWNobyAiJEhPVFBMVUciID4mNjsgfQorZWxzZQorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0g
eCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgYXNfZm5fZXJyb3IgJD8gInVkZXYgaXMg
dG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVyIiAiJExJTkVOTyIgNQorICAg
ICAgICBmaQorICAgIGZpCitlbHNlCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ2
bmNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgdm5jb25maWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX1ZOQ09ORklH
K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgY2FzZSAkVk5DT05GSUcgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhf
Vk5DT05GSUc9IiRWTkNPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0
aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfVk5DT05GSUc9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfVk5DT05GSUciICYmIGFjX2N2X3BhdGhfVk5DT05GSUc9Im5vIgorICA7OworZXNhYworZmkK
K1ZOQ09ORklHPSRhY19jdl9wYXRoX1ZOQ09ORklHCitpZiB0ZXN0IC1uICIkVk5DT05GSUciOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
Vk5DT05GSUciID4mNQorJGFzX2VjaG8gIiRWTkNPTkZJRyIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgaWYgdGVzdCB4IiR7Vk5DT05GSUd9IiA9PSB4
Im5vIgorICAgIHRoZW4KKyAgICAgICAgYXNfZm5fZXJyb3IgJD8gIk5vdCBhIExpbnV4IHN5c3Rl
bSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kIiAiJExJTkVOTyIgNQorICAgIGZpCitmaQorCisKKyMg
Q2hlY2sgbGlicmFyeSBwYXRoCitpZiB0ZXN0IC1kICIkcHJlZml4L2xpYjY0IjsgdGhlbiA6CisK
KyAgICBMSUJfUEFUSD0ibGliNjQiCisKK2Vsc2UKKworICAgIExJQl9QQVRIPSJsaWIiCisKK2Zp
CisKKworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9saWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UworTElCUz0iLWxhaW8gICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0ND
IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1
c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNp
ZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGlvX3NldHVwICgpOwor
aW50CittYWluICgpCit7CityZXR1cm4gaW9fc2V0dXAgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zf
bGliX2Fpb19pb19zZXR1cD15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD1ubwor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2
ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2Fp
b19pb19zZXR1cCIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0g
eCIieWVzOyB0aGVuIDoKKyAgc3lzdGVtX2Fpbz0ieSIKK2Vsc2UKKyAgc3lzdGVtX2Fpbz0ibiIK
K2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgTUQ1IGluIC1sY3J5cHRvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBNRDUg
aW4gLWxjcnlwdG8uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUr
c2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQor
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGNyeXB0byAgJExJQlMiCitj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2
b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJl
dHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90
b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4g
IkMiCisjZW5kaWYKK2NoYXIgTUQ1ICgpOworaW50CittYWluICgpCit7CityZXR1cm4gTUQ1ICgp
OworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PXllcworZWxzZQorICBhY19jdl9s
aWJfY3J5cHRvX01ENT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJT
PSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2Ny
eXB0b19NRDUiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBIQVZFX0xJQkNSWVBUTyAxCitfQUNFT0YKKworICBMSUJTPSItbGNyeXB0byAkTElC
UyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAi
JExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCitMSUJTPSItbGV4dDJmcyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJy
aWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNl
IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisg
ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw
bHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0
MmZzX29wZW4yICgpOworaW50CittYWluICgpCit7CityZXR1cm4gZXh0MmZzX29wZW4yICgpOwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5P
IjsgdGhlbiA6CisgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcworZWxzZQorICBh
Y19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4y
IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID0geCIi
eWVzOyB0aGVuIDoKKyAgbGliZXh0MmZzPSJ5IgorZWxzZQorICBsaWJleHQyZnM9Im4iCitmaQor
CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyK3NldH0iID0gc2V0OyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGli
X3NhdmVfTElCUz0kTElCUworTElCUz0iLWxnY3J5cHQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisv
KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K
KyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh
IEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0
aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitj
aGFyIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBnY3J5
X21kX2hhc2hfYnVmZmVyICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9t
ZF9oYXNoX2J1ZmZlcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hf
YnVmZmVyPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9
CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPSB4IiJ5
ZXM7IHRoZW4gOgorICBsaWJnY3J5cHQ9InkiCitlbHNlCisgIGxpYmdjcnlwdD0ibiIKK2ZpCisK
KworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
cHRocmVhZF9jcmVhdGUgaW4gLWxwdGhyZWFkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBwdGhyZWFkX2NyZWF0ZSBpbiAtbHB0aHJlYWQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRM
SUJTCitMSUJTPSItbHB0aHJlYWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIHB0aHJlYWRf
Y3JlYXRlICgpOworaW50CittYWluICgpCit7CityZXR1cm4gcHRocmVhZF9jcmVhdGUgKCk7Cisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGU9eWVzCitlbHNlCisg
IGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlPW5vCitmaQorcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv
bmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9wdGhy
ZWFkX3B0aHJlYWRfY3JlYXRlIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3B0aHJlYWRfcHRo
cmVhZF9jcmVhdGUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfcHRocmVhZF9wdGhyZWFk
X2NyZWF0ZSIgPSB4IiJ5ZXM7IHRoZW4gOgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3Vs
ZCBub3QgZmluZCBsaWJwdGhyZWFkIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgY2xvY2tfZ2V0dGltZSBpbiAt
bHJ0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbG9ja19nZXR0aW1lIGluIC1scnQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUrc2V0fSIg
PSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19j
aGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHJ0ICAkTElCUyIKK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJy
b3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg
b2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs
ZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRp
ZgorY2hhciBjbG9ja19nZXR0aW1lICgpOworaW50CittYWluICgpCit7CityZXR1cm4gY2xvY2tf
Z2V0dGltZSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlf
bGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZT15ZXMK
K2Vsc2UKKyAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9bm8KK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3J0
X2Nsb2NrX2dldHRpbWUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGlt
ZSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA9IHgiInll
czsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJS
VCAxCitfQUNFT0YKKworICBMSUJTPSItbHJ0ICRMSUJTIgorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1s
dXVpZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcitzZXR9IiA9
IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sdXVpZCAgJExJQlMiCitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy
cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl
IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k
aWYKK2NoYXIgdXVpZF9jbGVhciAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHV1aWRfY2xl
YXIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsg
IiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj15ZXMKK2Vsc2UK
KyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlk
X2NsZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY2OyB9
CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID0geCIieWVzOyB0aGVuIDoK
KyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX0xJQlVVSUQgMQorX0FD
RU9GCisKKyAgTElCUz0iLWx1dWlkICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJD
b3VsZCBub3QgZmluZCBsaWJ1dWlkIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlh
amwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4u
ICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHlhamwgICRMSUJTIgorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv
ci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlm
CitjaGFyIHlhamxfYWxsb2MgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiB5YWpsX2FsbG9j
ICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCitlbHNlCisg
IGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3Qu
JGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9h
bGxvYyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQor
aWYgdGVzdCAieCRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHgiInllczsgdGhlbiA6Cisg
IGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKK19BQ0VP
RgorCisgIExJQlM9Ii1seWFqbCAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291
bGQgbm90IGZpbmQgeWFqbCIgIiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1seiIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6Li4uICIgPiY2OyB9
CitpZiB0ZXN0ICIke2FjX2N2X2xpYl96X2RlZmxhdGVDb3B5K3NldH0iID0gc2V0OyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVf
TElCUz0kTElCUworTElCUz0iLWx6ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUg
YW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hh
ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1
aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g
ICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBkZWZsYXRl
Q29weSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGRlZmxhdGVDb3B5ICgpOworICA7Cisg
IHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PXllcworZWxzZQorICBhY19jdl9saWJfel9k
ZWZsYXRlQ29weT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2RlZmluZSBIQVZFX0xJQlogMQorX0FDRU9GCisKKyAgTElCUz0iLWx6ICRMSUJTIgor
CitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB6bGliIiAiJExJTkVOTyIg
NQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfbGliX2ljb252X2xpYmljb252X29wZW4rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJT
CitMSUJTPSItbGljb252ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdD
QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNh
dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4g
YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisj
aWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBsaWJpY29udl9vcGVu
ICgpOworaW50CittYWluICgpCit7CityZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGli
X2ljb252X2xpYmljb252X29wZW49bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29w
ZW4iID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY2OyB9
CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA9IHgiInllczsgdGhl
biA6CisgIGxpYmljb252PSJ5IgorZWxzZQorICBsaWJpY29udj0ibiIKK2ZpCisKKworCisjIEF1
dG9zY2FuIHN0dWZmIChleGNlcHQgZm9yIHlhamwveWFqbF92ZXJzaW9uLmggY2hlY2spCisjIENo
ZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgorIyBUaGUgVWx0cml4IDQuMiBtaXBzIGJ1aWx0aW4gYWxs
b2NhIGRlY2xhcmVkIGJ5IGFsbG9jYS5oIG9ubHkgd29ya3MKKyMgZm9yIGNvbnN0YW50IGFyZ3Vt
ZW50cy4gIFVzZWxlc3MhCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciB3b3JraW5nIGFsbG9jYS5oLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3dvcmtp
bmdfYWxsb2NhX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWxsb2NhLmg+CitpbnQKK21haW4g
KCkKK3sKK2NoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDIgKiBzaXplb2YgKGludCkpOworCQkJ
ICBpZiAocCkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD15
ZXMKK2Vsc2UKKyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD1ubworZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3Zfd29ya2luZ19hbGxvY2FfaCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl93b3JraW5nX2FsbG9j
YV9oID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIgPj5j
b25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIGFsbG9jYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgYWxs
b2NhLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzK3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworI2lmZGVmIF9fR05VQ19fCisjIGRlZmluZSBhbGxvY2EgX19idWlsdGluX2FsbG9j
YQorI2Vsc2UKKyMgaWZkZWYgX01TQ19WRVIKKyMgIGluY2x1ZGUgPG1hbGxvYy5oPgorIyAgZGVm
aW5lIGFsbG9jYSBfYWxsb2NhCisjIGVsc2UKKyMgIGlmZGVmIEhBVkVfQUxMT0NBX0gKKyMgICBp
bmNsdWRlIDxhbGxvY2EuaD4KKyMgIGVsc2UKKyMgICBpZmRlZiBfQUlYCisgI3ByYWdtYSBhbGxv
Y2EKKyMgICBlbHNlCisjICAgIGlmbmRlZiBhbGxvY2EgLyogcHJlZGVmaW5lZCBieSBIUCBjYyAr
T2xpYmNhbGxzICovCitjaGFyICphbGxvY2EgKCk7CisjICAgIGVuZGlmCisjICAgZW5kaWYKKyMg
IGVuZGlmCisjIGVuZGlmCisjZW5kaWYKKworaW50CittYWluICgpCit7CitjaGFyICpwID0gKGNo
YXIgKikgYWxsb2NhICgxKTsKKwkJCQkgICAgaWYgKHApIHJldHVybiAwOworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPXllcworZWxzZQorICBhY19jdl9mdW5jX2FsbG9jYV93
b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
XAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2FsbG9j
YV93b3JrcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjY7IH0K
KworaWYgdGVzdCAkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MgPSB5ZXM7IHRoZW4KKworJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9BTExPQ0EgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgIyBUaGUg
U1ZSMyBsaWJQVyBhbmQgU1ZSNCBsaWJ1Y2IgYm90aCBjb250YWluIGluY29tcGF0aWJsZSBmdW5j
dGlvbnMKKyMgdGhhdCBjYXVzZSB0cm91YmxlLiAgU29tZSB2ZXJzaW9ucyBkbyBub3QgZXZlbiBj
b250YWluIGFsbG9jYSBvcgorIyBjb250YWluIGEgYnVnZ3kgdmVyc2lvbi4gIElmIHlvdSBzdGls
bCB3YW50IHRvIHVzZSB0aGVpciBhbGxvY2EsCisjIHVzZSBhciB0byBleHRyYWN0IGFsbG9jYS5v
IGZyb20gdGhlbSBpbnN0ZWFkIG9mIGNvbXBpbGluZyBhbGxvY2EuYy4KKworQUxMT0NBPVwke0xJ
Qk9CSkRJUn1hbGxvY2EuJGFjX29iamV4dAorCiskYXNfZWNobyAiI2RlZmluZSBDX0FMTE9DQSAx
IiA+PmNvbmZkZWZzLmgKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3Mu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zfb3NfY3JheStzZXR9IiA9IHNldDsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBk
ZWZpbmVkIENSQVkgJiYgISBkZWZpbmVkIENSQVkyCit3ZWJlY3JheQorI2Vsc2UKK3dlbm90YmVj
cmF5CisjZW5kaWYKKworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0
IikgMj4mNSB8CisgICRFR1JFUCAid2ViZWNyYXkiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Cisg
IGFjX2N2X29zX2NyYXk9eWVzCitlbHNlCisgIGFjX2N2X29zX2NyYXk9bm8KK2ZpCitybSAtZiBj
b25mdGVzdCoKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3Zfb3NfY3JheSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4m
NjsgfQoraWYgdGVzdCAkYWNfY3Zfb3NfY3JheSA9IHllczsgdGhlbgorICBmb3IgYWNfZnVuYyBp
biBfZ2V0YjY3IEdFVEI2NyBnZXRiNjc7IGRvCisgICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNf
Y3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5F
Tk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3Zh
ciJcIiA9IHgieWVzIjsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZp
bmUgQ1JBWV9TVEFDS1NFR19FTkQgJGFjX2Z1bmMKK19BQ0VPRgorCisgICAgYnJlYWsKK2ZpCisK
KyAgZG9uZQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBzdGFjayBkaXJlY3Rpb24gZm9yIEMgYWxsb2NhIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIHN0YWNrIGRpcmVjdGlvbiBmb3IgQyBhbGxvY2EuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfY19zdGFja19kaXJlY3Rpb24rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9
IHllczsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPTAKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2ludAorZmluZF9zdGFja19kaXJlY3Rpb24gKCkK
K3sKKyAgc3RhdGljIGNoYXIgKmFkZHIgPSAwOworICBhdXRvIGNoYXIgZHVtbXk7CisgIGlmIChh
ZGRyID09IDApCisgICAgeworICAgICAgYWRkciA9ICZkdW1teTsKKyAgICAgIHJldHVybiBmaW5k
X3N0YWNrX2RpcmVjdGlvbiAoKTsKKyAgICB9CisgIGVsc2UKKyAgICByZXR1cm4gKCZkdW1teSA+
IGFkZHIpID8gMSA6IC0xOworfQorCitpbnQKK21haW4gKCkKK3sKKyAgcmV0dXJuIGZpbmRfc3Rh
Y2tfZGlyZWN0aW9uICgpIDwgMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPTEKK2Vsc2UKKyAgYWNfY3Zf
Y19zdGFja19kaXJlY3Rpb249LTEKK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0
LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3N0YWNrX2Rp
cmVjdGlvbiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjY7IH0K
K2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgU1RBQ0tfRElSRUNUSU9OICRhY19j
dl9jX3N0YWNrX2RpcmVjdGlvbgorX0FDRU9GCisKKworZmkKKworZm9yIGFjX2hlYWRlciBpbiAg
XAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRs
LmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9p
bi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAgICAgICAgICAg
ICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0u
aCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUu
aCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFq
bF92ZXJzaW9uLmggXAorCitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hl
YWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdy
ZWwgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRo
ZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFW
RV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKKwor
IyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVy
aXN0aWNzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMgdG8gQzk5IiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0byBDOTkuLi4gIiA+JjY7IH0KK2lm
IHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworI2luY2x1ZGUg
PHN0ZGJvb2wuaD4KKyNpZm5kZWYgYm9vbAorICJlcnJvcjogYm9vbCBpcyBub3QgZGVmaW5lZCIK
KyNlbmRpZgorI2lmbmRlZiBmYWxzZQorICJlcnJvcjogZmFsc2UgaXMgbm90IGRlZmluZWQiCisj
ZW5kaWYKKyNpZiBmYWxzZQorICJlcnJvcjogZmFsc2UgaXMgbm90IDAiCisjZW5kaWYKKyNpZm5k
ZWYgdHJ1ZQorICJlcnJvcjogdHJ1ZSBpcyBub3QgZGVmaW5lZCIKKyNlbmRpZgorI2lmIHRydWUg
IT0gMQorICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIKKyNlbmRpZgorI2lmbmRlZiBfX2Jvb2xfdHJ1
ZV9mYWxzZV9hcmVfZGVmaW5lZAorICJlcnJvcjogX19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmlu
ZWQgaXMgbm90IGRlZmluZWQiCisjZW5kaWYKKworCXN0cnVjdCBzIHsgX0Jvb2wgczogMTsgX0Jv
b2wgdDsgfSBzOworCisJY2hhciBhW3RydWUgPT0gMSA/IDEgOiAtMV07CisJY2hhciBiW2ZhbHNl
ID09IDAgPyAxIDogLTFdOworCWNoYXIgY1tfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCA9
PSAxID8gMSA6IC0xXTsKKwljaGFyIGRbKGJvb2wpIDAuNSA9PSB0cnVlID8gMSA6IC0xXTsKKwli
b29sIGUgPSAmczsKKwljaGFyIGZbKF9Cb29sKSAwLjAgPT0gZmFsc2UgPyAxIDogLTFdOworCWNo
YXIgZ1t0cnVlXTsKKwljaGFyIGhbc2l6ZW9mIChfQm9vbCldOworCWNoYXIgaVtzaXplb2Ygcy50
XTsKKwllbnVtIHsgaiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRy
dWUgKiAyNTYgfTsKKwkvKiBUaGUgZm9sbG93aW5nIGZhaWxzIGZvcgorCSAgIEhQIGFDKysvQU5T
SSBDIEIzOTEwQiBBLjA1LjU1IFtEZWMgMDQgMjAwM10uICovCisJX0Jvb2wgblttXTsKKwljaGFy
IG9bc2l6ZW9mIG4gPT0gbSAqIHNpemVvZiBuWzBdID8gMSA6IC0xXTsKKwljaGFyIHBbLTEgLSAo
X0Jvb2wpIDAgPCAwICYmIC0xIC0gKGJvb2wpIDAgPCAwID8gMSA6IC0xXTsKKyMJaWYgZGVmaW5l
ZCBfX3hsY19fIHx8IGRlZmluZWQgX19HTlVDX18KKwkgLyogQ2F0Y2ggYSBidWcgaW4gSUJNIEFJ
WCB4bGMgY29tcGlsZXIgdmVyc2lvbiA2LjAuMC4wCisJICAgIHJlcG9ydGVkIGJ5IEphbWVzIExl
bWxleSBvbiAyMDA1LTEwLTA1OyBzZWUKKwkgICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2
ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMC9tc2cwMDA4Ni5odG1sCisJICAgIFRoaXMgdGVz
dCBpcyBub3QgcXVpdGUgcmlnaHQsIHNpbmNlIHhsYyBpcyBhbGxvd2VkIHRvCisJICAgIHJlamVj
dCB0aGlzIHByb2dyYW0sIGFzIHRoZSBpbml0aWFsaXplciBmb3IgeGxjYnVnIGlzCisJICAgIG5v
dCBvbmUgb2YgdGhlIGZvcm1zIHRoYXQgQyByZXF1aXJlcyBzdXBwb3J0IGZvci4KKwkgICAgSG93
ZXZlciwgZG9pbmcgdGhlIHRlc3QgcmlnaHQgd291bGQgcmVxdWlyZSBhIHJ1bnRpbWUKKwkgICAg
dGVzdCwgYW5kIHRoYXQgd291bGQgbWFrZSBjcm9zcy1jb21waWxhdGlvbiBoYXJkZXIuCisJICAg
IExldCB1cyBob3BlIHRoYXQgSUJNIGZpeGVzIHRoZSB4bGMgYnVnLCBhbmQgYWxzbyBhZGRzCisJ
ICAgIHN1cHBvcnQgZm9yIHRoaXMga2luZCBvZiBjb25zdGFudCBleHByZXNzaW9uLiAgSW4gdGhl
CisJICAgIG1lYW50aW1lLCB0aGlzIHRlc3Qgd2lsbCByZWplY3QgeGxjLCB3aGljaCBpcyBPSywg
c2luY2UKKwkgICAgb3VyIHN0ZGJvb2wuaCBzdWJzdGl0dXRlIHNob3VsZCBzdWZmaWNlLiAgV2Ug
YWxzbyB0ZXN0CisJICAgIHRoaXMgd2l0aCBHQ0MsIHdoZXJlIGl0IHNob3VsZCB3b3JrLCB0byBk
ZXRlY3QgbW9yZQorCSAgICBxdWlja2x5IHdoZXRoZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRl
c3QgaW4gdGhlCisJICAgIGZ1dHVyZS4gICovCisJIGNoYXIgZGlnc1tdID0gIjAxMjM0NTY3ODki
OworCSBpbnQgeGxjYnVnID0gMSAvICgmKGRpZ3MgKyA1KVstMiArIChib29sKSAxXSA9PSAmZGln
c1s0XSA/IDEgOiAtMSk7CisjCWVuZGlmCisJLyogQ2F0Y2ggYSBidWcgaW4gYW4gSFAtVVggQyBj
b21waWxlci4gIFNlZQorCSAgIGh0dHA6Ly9nY2MuZ251Lm9yZy9tbC9nY2MtcGF0Y2hlcy8yMDAz
LTEyL21zZzAyMzAzLmh0bWwKKwkgICBodHRwOi8vbGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwv
YnVnLWNvcmV1dGlscy8yMDA1LTExL21zZzAwMTYxLmh0bWwKKwkgKi8KKwlfQm9vbCBxID0gdHJ1
ZTsKKwlfQm9vbCAqcHEgPSAmcTsKKworaW50CittYWluICgpCit7CisKKwkqcHEgfD0gcTsKKwkq
cHEgfD0gISBxOworCS8qIFJlZmVyIHRvIGV2ZXJ5IGRlY2xhcmVkIHZhbHVlLCB0byBhdm9pZCBj
b21waWxlciBvcHRpbWl6YXRpb25zLiAgKi8KKwlyZXR1cm4gKCFhICsgIWIgKyAhYyArICFkICsg
IWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCisJCSsgIW0gKyAhbiArICFv
ICsgIXAgKyAhcSArICFwcSk7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3RkYm9v
bF9oPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYm9vbF9oPW5vCitmaQorcm0gLWYgY29y
ZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9o
ZWFkZXJfc3RkYm9vbF9oIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCIg
PiY2OyB9CithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJfQm9vbCIgImFjX2N2X3R5cGVf
X0Jvb2wiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9fQm9v
bCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IEhBVkVfX0JPT0wgMQorX0FDRU9GCisKKworZmkKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0
ZGJvb2xfaCA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX1NUREJPT0xfSCAx
IiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5oLi4uICIgPiY2OyB9CitpZiB0ZXN0
ICIke2FjX2N2X3R5cGVfdWlkX3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+
CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAor
ICAkRUdSRVAgInVpZF90IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBhY19jdl90eXBlX3Vp
ZF90PXllcworZWxzZQorICBhY19jdl90eXBlX3VpZF90PW5vCitmaQorcm0gLWYgY29uZnRlc3Qq
CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X3R5cGVfdWlkX3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl90eXBlX3VpZF90IiA+JjY7
IH0KK2lmIHRlc3QgJGFjX2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgorCiskYXNfZWNobyAiI2Rl
ZmluZSB1aWRfdCBpbnQiID4+Y29uZmRlZnMuaAorCisKKyRhc19lY2hvICIjZGVmaW5lIGdpZF90
IGludCIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgaW5saW5lLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2NfaW5saW5lK3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNf
Y3ZfY19pbmxpbmU9bm8KK2ZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxpbmVfXyBfX2lubGluZTsg
ZG8KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cwordHlwZWRlZiBpbnQgZm9vX3Q7
CitzdGF0aWMgJGFjX2t3IGZvb190IHN0YXRpY19mb28gKCkge3JldHVybiAwOyB9CiskYWNfa3cg
Zm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQorI2VuZGlmCisKK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9jX2lubGluZT0kYWNfa3cKK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKKyAgdGVzdCAiJGFjX2N2X2NfaW5saW5lIiAhPSBubyAmJiBicmVhaworZG9uZQorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9jX2lubGluZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2NfaW5saW5lIiA+JjY7IH0KKworY2Fz
ZSAkYWNfY3ZfY19pbmxpbmUgaW4KKyAgaW5saW5lIHwgeWVzKSA7OworICAqKQorICAgIGNhc2Ug
JGFjX2N2X2NfaW5saW5lIGluCisgICAgICBubykgYWNfdmFsPTs7CisgICAgICAqKSBhY192YWw9
JGFjX2N2X2NfaW5saW5lOzsKKyAgICBlc2FjCisgICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
RgorI2lmbmRlZiBfX2NwbHVzcGx1cworI2RlZmluZSBpbmxpbmUgJGFjX3ZhbAorI2VuZGlmCitf
QUNFT0YKKyAgICA7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiMTYi
ICJhY19jdl9jX2ludDE2X3QiCitjYXNlICRhY19jdl9jX2ludDE2X3QgaW4gIygKKyAgbm98eWVz
KSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDE2
X3QgJGFjX2N2X2NfaW50MTZfdAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50
WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX2ludDMyX3QiCitjYXNlICRhY19jdl9jX2ludDMy
X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCisjZGVmaW5lIGludDMyX3QgJGFjX2N2X2NfaW50MzJfdAorX0FDRU9GCis7OworZXNhYwor
CithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0X3QiCitj
YXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitjYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDY0X3QgJGFjX2N2X2NfaW50NjRfdAor
X0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIgImFj
X2N2X2NfaW50OF90IgorY2FzZSAkYWNfY3ZfY19pbnQ4X3QgaW4gIygKKyAgbm98eWVzKSA7OyAj
KAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDhfdCAkYWNf
Y3ZfY19pbnQ4X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19jaGVja190eXBlICIkTElO
RU5PIiAibW9kZV90IiAiYWNfY3ZfdHlwZV9tb2RlX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIK
K2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9tb2RlX3QiID0geCIieWVzOyB0aGVuIDoKKworZWxzZQor
CitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIG1vZGVfdCBpbnQKK19BQ0VPRgor
CitmaQorCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2X3R5cGVf
b2ZmX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZf
dCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
KyNkZWZpbmUgb2ZmX3QgbG9uZyBpbnQKK19BQ0VPRgorCitmaQorCithY19mbl9jX2NoZWNrX3R5
cGUgIiRMSU5FTk8iICJwaWRfdCIgImFjX2N2X3R5cGVfcGlkX3QiICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9waWRfdCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitl
bHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgcGlkX3QgaW50CitfQUNF
T0YKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9jX3Jlc3RyaWN0K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgYWNfY3ZfY19yZXN0cmljdD1ubworICAgIyBUaGUgb3JkZXIgaGVyZSBj
YXRlcnMgdG8gdGhlIGZhY3QgdGhhdCBDKysgZG9lcyBub3QgcmVxdWlyZSByZXN0cmljdC4KKyAg
IGZvciBhY19rdyBpbiBfX3Jlc3RyaWN0IF9fcmVzdHJpY3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7
IGRvCisgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KK3R5cGVkZWYgaW50ICogaW50X3B0cjsKKwlpbnQgZm9vIChp
bnRfcHRyICRhY19rdyBpcCkgeworCXJldHVybiBpcFswXTsKKyAgICAgICB9CitpbnQKK21haW4g
KCkKK3sKK2ludCBzWzFdOworCWludCAqICRhY19rdyB0ID0gczsKKwl0WzBdID0gMDsKKwlyZXR1
cm4gZm9vKHQpCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2Nv
bXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19yZXN0cmljdD0kYWNfa3cKK2ZpCity
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKKyAgICAgdGVzdCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJyZWFrCisgICBkb25l
CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2NfcmVzdHJpY3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX3Jlc3RyaWN0IiA+JjY7
IH0KKworIGNhc2UgJGFjX2N2X2NfcmVzdHJpY3QgaW4KKyAgIHJlc3RyaWN0KSA7OworICAgbm8p
ICRhc19lY2hvICIjZGVmaW5lIHJlc3RyaWN0IC8qKi8iID4+Y29uZmRlZnMuaAorIDs7CisgICAq
KSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSByZXN0cmljdCAkYWNfY3ZfY19y
ZXN0cmljdAorX0FDRU9GCisgOzsKKyBlc2FjCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVO
TyIgInNpemVfdCIgImFjX2N2X3R5cGVfc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitp
ZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc2l6ZV90IiA9IHgiInllczsgdGhlbiA6CisKK2Vsc2UKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBzaXplX3QgdW5zaWduZWQgaW50Citf
QUNFT0YKKworZmkKKworYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic3NpemVfdCIgImFj
X2N2X3R5cGVfc3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl90eXBlX3NzaXplX3QiID0geCIieWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIHNzaXplX3QgaW50CitfQUNFT0YKKworZmkKKworYWNfZm5f
Y19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X2Jsa3NpemUiICJhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igor
aWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4IiJ5ZXM7
IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfU1RSVUNU
X1NUQVRfU1RfQkxLU0laRSAxCitfQUNFT0YKKworCitmaQorCithY19mbl9jX2NoZWNrX21lbWJl
ciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVj
dF9zdGF0X3N0X2Jsb2NrcyIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tzIiA9IHgiInllczsgdGhlbiA6CisKK2NhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1Mg
MQorX0FDRU9GCisKKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9TVF9CTE9DS1MgMSIgPj5jb25m
ZGVmcy5oCisKK2Vsc2UKKyAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgZmlsZWJsb2Nrcy4k
YWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgZmlsZWJsb2Nrcy4kYWNf
b2JqZXh0IgorIDs7Citlc2FjCisKK2ZpCisKKworYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5F
Tk8iICJzdHJ1Y3Qgc3RhdCIgInN0X3JkZXYiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3Rf
cmRldiIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3Ry
dWN0X3N0YXRfc3RfcmRldiIgPSB4IiJ5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfUkRFViAxCitfQUNFT0YKKworCitm
aQorCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY191aW50MTZf
dCIKK2Nhc2UgJGFjX2N2X2NfdWludDE2X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQor
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgdWludDE2X3QgJGFjX2N2X2Nf
dWludDE2X3QKK19BQ0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJ
TkVOTyIgIjMyIiAiYWNfY3ZfY191aW50MzJfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDMyX3QgaW4g
IygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBfVUlOVDMyX1Qg
MSIgPj5jb25mZGVmcy5oCisKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1
aW50MzJfdCAkYWNfY3ZfY191aW50MzJfdAorX0FDRU9GCis7OworICBlc2FjCisKK2FjX2ZuX2Nf
ZmluZF91aW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX3VpbnQ2NF90IgorY2FzZSAkYWNf
Y3ZfY191aW50NjRfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKKyRhc19lY2hvICIj
ZGVmaW5lIF9VSU5UNjRfVCAxIiA+PmNvbmZkZWZzLmgKKworCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIHVpbnQ2NF90ICRhY19jdl9jX3VpbnQ2NF90CitfQUNFT0YKKzs7Cisg
IGVzYWMKKworYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8iICI4IiAiYWNfY3ZfY191aW50
OF90IgorY2FzZSAkYWNfY3ZfY191aW50OF90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikK
KworJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ4X1QgMSIgPj5jb25mZGVmcy5oCisKKworY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1aW50OF90ICRhY19jdl9jX3VpbnQ4X3QKK19B
Q0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJwdHJkaWZm
X3QiICJhY19jdl90eXBlX3B0cmRpZmZfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl90eXBlX3B0cmRpZmZfdCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfUFRSRElGRl9UIDEKK19BQ0VPRgorCisKK2Zp
CisKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9saWJfZXJyb3JfYXRfbGluZStzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxlcnJv
ci5oPgoraW50CittYWluICgpCit7CitlcnJvcl9hdF9saW5lICgwLCAwLCAiIiwgMCwgImFuIGVy
cm9yIG9jY3VycmVkIik7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVz
CitlbHNlCisgIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPW5vCitmaQorcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfbGliX2Vycm9yX2F0X2xpbmUiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfbGliX2Vycm9yX2F0
X2xpbmUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBlcnJvci4kYWNf
b2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgZXJyb3IuJGFjX29iamV4dCIK
KyA7OworZXNhYworCitmaQorCitmb3IgYWNfaGVhZGVyIGluIHZmb3JrLmgKK2RvIDoKKyAgYWNf
Zm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInZmb3JrLmgiICJhY19jdl9oZWFk
ZXJfdmZvcmtfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFk
ZXJfdmZvcmtfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjZGVmaW5lIEhBVkVfVkZPUktfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCitmb3IgYWNf
ZnVuYyBpbiBmb3JrIHZmb3JrCitkbyA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1
bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAi
JGFjX2Z1bmMiICIkYXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIg
PSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAk
YXNfZWNobyAiSEFWRV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKK2Rv
bmUKKworaWYgdGVzdCAieCRhY19jdl9mdW5jX2ZvcmsiID0geHllczsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIGZv
cmsiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yay4uLiAiID4mNjsg
fQoraWYgdGVzdCAiJHthY19jdl9mdW5jX2Zvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1jcm9zcworZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50CittYWluICgpCit7CisK
KwkgIC8qIEJ5IFJ1ZWRpZ2VyIEt1aGxtYW5uLiAqLworCSAgcmV0dXJuIGZvcmsgKCkgPCAwOwor
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVO
TyI7IHRoZW4gOgorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCitlbHNlCisgIGFjX2N2X2Z1
bmNfZm9ya193b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBn
bW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfZm9ya193b3Jr
cyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9CisKK2Vsc2UK
KyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPSRhY19jdl9mdW5jX2ZvcmsKK2ZpCitpZiB0ZXN0ICJ4
JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KKyAgY2FzZSAkaG9zdCBpbgor
ICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3BwKikKKyAgICAgICMgT3ZlcnJpZGUsIGFz
IHRoZXNlIHN5c3RlbXMgaGF2ZSBvbmx5IGEgZHVtbXkgZm9yaygpIHN0dWIKKyAgICAgIGFjX2N2
X2Z1bmNfZm9ya193b3Jrcz1ubworICAgICAgOzsKKyAgICAqKQorICAgICAgYWNfY3ZfZnVuY19m
b3JrX3dvcmtzPXllcworICAgICAgOzsKKyAgZXNhYworICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19mb3JrX3dvcmtz
IGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1
c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorYWNfY3ZfZnVuY192Zm9ya193b3Jr
cz0kYWNfY3ZfZnVuY192Zm9yaworaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrIiA9IHh5ZXM7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3Igd29ya2luZyB2Zm9yayIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2lu
ZyB2Zm9yay4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX3Zmb3JrX3dvcmtzK3Nl
dH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzPWNyb3NzCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIFRoYW5rcyB0byBQYXVsIEVn
Z2VydCBmb3IgdGhpcyB0ZXN0LiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisjaW5jbHVkZSA8
c3lzL3dhaXQuaD4KKyNpZmRlZiBIQVZFX1ZGT1JLX0gKKyMgaW5jbHVkZSA8dmZvcmsuaD4KKyNl
bmRpZgorLyogT24gc29tZSBzcGFyYyBzeXN0ZW1zLCBjaGFuZ2VzIGJ5IHRoZSBjaGlsZCB0byBs
b2NhbCBhbmQgaW5jb21pbmcKKyAgIGFyZ3VtZW50IHJlZ2lzdGVycyBhcmUgcHJvcGFnYXRlZCBi
YWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGlsZXIKKyAgIGlzIHRvbGQgYWJvdXQgdGhpcyB3
aXRoICNpbmNsdWRlIDx2Zm9yay5oPiwgYnV0IHNvbWUgY29tcGlsZXJzCisgICAoZS5nLiBnY2Mg
LU8pIGRvbid0IGdyb2sgPHZmb3JrLmg+LiAgVGVzdCBmb3IgdGhpcyBieSB1c2luZyBhCisgICBz
dGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVzcyBpcyBwdXQgaW50byBhIHJlZ2lzdGVyIHRoYXQg
aXMKKyAgIGNsb2JiZXJlZCBieSB0aGUgdmZvcmsuICAqLworc3RhdGljIHZvaWQKKyNpZmRlZiBf
X2NwbHVzcGx1cworc3BhcmNfYWRkcmVzc190ZXN0IChpbnQgYXJnKQorIyBlbHNlCitzcGFyY19h
ZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsKKyNlbmRpZgoreworICBzdGF0aWMgcGlkX3QgY2hp
bGQ7CisgIGlmICghY2hpbGQpIHsKKyAgICBjaGlsZCA9IHZmb3JrICgpOworICAgIGlmIChjaGls
ZCA8IDApIHsKKyAgICAgIHBlcnJvciAoInZmb3JrIik7CisgICAgICBfZXhpdCgyKTsKKyAgICB9
CisgICAgaWYgKCFjaGlsZCkgeworICAgICAgYXJnID0gZ2V0cGlkKCk7CisgICAgICB3cml0ZSgt
MSwgIiIsIDApOworICAgICAgX2V4aXQgKGFyZyk7CisgICAgfQorICB9Cit9CisKK2ludAorbWFp
biAoKQoreworICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7CisgIHBpZF90IGNoaWxkOworCisg
IHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7CisKKyAgY2hpbGQgPSB2Zm9yayAoKTsKKworICBpZiAo
Y2hpbGQgPT0gMCkgeworICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0ZXN0IGZvciBzcGFyYyB2Zm9y
ayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKKyAgICAgICB0ZXN0IHVzZXMgbG90cyBvZiBsb2Nh
bCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1hbnkgbG9jYWwKKyAgICAgICB2YXJpYWJsZXMgYXMg
bWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBpbmNsdWRpbmcgY29tcGlsZXIKKyAgICAgICB0ZW1w
b3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9yIGdjYyAxLjQwLjMgb24gYSBTb2xhcmlz
CisgICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3ZSB1c2UgOCB0byBiZSBzYWZlLiAgQSBidWdneSBj
b21waWxlciBzaG91bGQKKyAgICAgICByZXVzZSB0aGUgcmVnaXN0ZXIgb2YgcGFyZW50IGZvciBv
bmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywKKyAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRo
YXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJlIHVzZWQgYW55IG1vcmUKKyAgICAgICBpbiB0aGlz
IHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhlIGxvY2FsIHZhcmlhYmxlIHdpbGwgdGh1cworICAg
ICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFyZW50IHByb2Nlc3MuICAqLworICAgIHBpZF90Cisg
ICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0cGlkKCksIHAyID0gZ2V0cGlkKCksIHAzID0gZ2V0
cGlkKCksCisgICAgICBwNCA9IGdldHBpZCgpLCBwNSA9IGdldHBpZCgpLCBwNiA9IGdldHBpZCgp
LCBwNyA9IGdldHBpZCgpOworICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3
IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1pZ2h0CisgICAgICAgdXNlIHRoZSBzYW1lIGhhcmR3
YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2NhbCB2YXJpYWJsZXMuICAqLworICAgIGlmIChwICE9
IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8fCBwICE9IHA0CisJfHwgcCAhPSBwNSB8fCBwICE9
IHA2IHx8IHAgIT0gcDcpCisgICAgICBfZXhpdCgxKTsKKworICAgIC8qIE9uIHNvbWUgc3lzdGVt
cyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50CisgICAgICAg
ZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3JzLiAgSWYgdGhlIGNoaWxkIGNsb3NlcyBhIGRlc2Ny
aXB0b3IKKyAgICAgICBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMsIHRoaXMgbXVuZ2VzIHRoZSBw
YXJlbnQncyBkZXNjcmlwdG9yCisgICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRoaXMgYnkgY2xv
c2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KKyAgICBfZXhpdChjbG9zZShmaWxlbm8oc3Rk
b3V0KSkgIT0gMCk7CisgIH0gZWxzZSB7CisgICAgaW50IHN0YXR1czsKKyAgICBzdHJ1Y3Qgc3Rh
dCBzdDsKKworICAgIHdoaWxlICh3YWl0KCZzdGF0dXMpICE9IGNoaWxkKQorICAgICAgOworICAg
IHJldHVybiAoCisJIC8qIFdhcyB0aGVyZSBzb21lIHByb2JsZW0gd2l0aCB2Zm9ya2luZz8gICov
CisJIGNoaWxkIDwgMAorCisJIC8qIERpZCB0aGUgY2hpbGQgZmFpbD8gIChUaGlzIHNob3VsZG4n
dCBoYXBwZW4uKSAgKi8KKwkgfHwgc3RhdHVzCisKKwkgLyogRGlkIHRoZSB2Zm9yay9jb21waWxl
ciBidWcgb2NjdXI/ICAqLworCSB8fCBwYXJlbnQgIT0gZ2V0cGlkKCkKKworCSAvKiBEaWQgdGhl
IGZpbGUgZGVzY3JpcHRvciBidWcgb2NjdXI/ICAqLworCSB8fCBmc3RhdChmaWxlbm8oc3Rkb3V0
KSwgJnN0KSAhPSAwCisJICk7CisgIH0KK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9eWVzCitlbHNlCisgIGFj
X2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0
ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY2OyB9
CisKK2ZpOworaWYgdGVzdCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geGNyb3NzOyB0aGVu
CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1bmNfdmZvcmsKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY192Zm9ya193b3Jr
cyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorCitpZiB0
ZXN0ICJ4JGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID0geHllczsgdGhlbgorCiskYXNfZWNobyAi
I2RlZmluZSBIQVZFX1dPUktJTkdfVkZPUksgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKworJGFz
X2VjaG8gIiNkZWZpbmUgdmZvcmsgZm9yayIgPj5jb25mZGVmcy5oCisKK2ZpCitpZiB0ZXN0ICJ4
JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5l
IEhBVkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBfTEFSR0VGSUxFX1NPVVJD
RSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBfTEFSR0VGSUxFX1NPVVJDRSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlK3NldH0iID0gc2V0
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgd2hpbGUgOjsg
ZG8KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8K
KyAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK2ludCAoKmZwKSAoRklM
RSAqLCBvZmZfdCwgaW50KSA9IGZzZWVrbzsKKyAgICAgcmV0dXJuIGZzZWVrbyAoc3RkaW4sIDAs
IDApICYmIGZwIChzdGRpbiwgMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfc3lzX2xhcmdlZmls
ZV9zb3VyY2U9bm87IGJyZWFrCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAxCisjaW5jbHVkZSA8c3lzL3R5
cGVzLmg+IC8qIGZvciBvZmZfdCAqLworICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFp
biAoKQoreworaW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOworICAgICBy
ZXR1cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT0xOyBicmVhaworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPXVua25vd24K
KyAgYnJlYWsKK2RvbmUKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjUKKyRhc19lY2hvICIk
YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNjsgfQorY2FzZSAkYWNfY3Zfc3lzX2xhcmdl
ZmlsZV9zb3VyY2UgaW4gIygKKyAgbm8gfCB1bmtub3duKSA7OworICAqKQorY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdl
ZmlsZV9zb3VyY2UKK19BQ0VPRgorOzsKK2VzYWMKK3JtIC1yZiBjb25mdGVzdCoKKworIyBXZSB1
c2VkIHRvIHRyeSBkZWZpbmluZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5k
IGEgYnVnCisjIGluIGdsaWJjIDIuMS4zLCBidXQgdGhhdCBicmVha3MgdG9vIG1hbnkgb3RoZXIg
dGhpbmdzLgorIyBJZiB5b3Ugd2FudCBmc2Vla28gYW5kIGZ0ZWxsbyB3aXRoIGdsaWJjLCB1cGdy
YWRlIHRvIGEgZml4ZWQgZ2xpYmMuCitpZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJj
ZSAhPSB1bmtub3duOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+
Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMgdHJhaWxpbmcgc2xh
c2giID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFu
ZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX2xz
dGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBybSAtZiBjb25mdGVzdC5zeW0gY29u
ZnRlc3QuZmlsZQorZWNobyA+Y29uZnRlc3QuZmlsZQoraWYgdGVzdCAiJGFzX2xuX3MiID0gImxu
IC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0ZXN0LnN5bTsgdGhlbgorICBpZiB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbHN0YXRfZGVy
ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5j
bHVkZXNfZGVmYXVsdAoraW50CittYWluICgpCit7CitzdHJ1Y3Qgc3RhdCBzYnVmOworICAgICAv
KiBMaW51eCB3aWxsIGRlcmVmZXJlbmNlIHRoZSBzeW1saW5rIGFuZCBmYWlsLCBhcyByZXF1aXJl
ZCBieSBQT1NJWC4KKwlUaGF0IGlzIGJldHRlciBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBtZWFucyB3
ZSB3aWxsIG5vdAorCWhhdmUgdG8gY29tcGlsZSBhbmQgdXNlIHRoZSBsc3RhdCB3cmFwcGVyLiAg
Ki8KKyAgICAgcmV0dXJuIGxzdGF0ICgiY29uZnRlc3Quc3ltLyIsICZzYnVmKSA9PSAwOworICA7
CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0
aGVuIDoKKyAgYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXll
cworZWxzZQorICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9
bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0
IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVh
bSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitlbHNlCisgICMgSWYgdGhlIGBsbiAtcycgY29tbWFu
ZCBmYWlsZWQsIHRoZW4gd2UgcHJvYmFibHkgZG9uJ3QgZXZlbgorICAjIGhhdmUgYW4gbHN0YXQg
ZnVuY3Rpb24uCisgIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGlu
az1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCisKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0
YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1
bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9CisKK3Rlc3QgJGFj
X2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9T
WU1MSU5LIDEKK19BQ0VPRgorCisKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVy
ZW5jZXNfc2xhc2hlZF9zeW1saW5rIiA9IHhubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBp
bgorICAqIiBsc3RhdC4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMg
bHN0YXQuJGFjX29iamV4dCIKKyA7OworZXNhYworCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmggZGVmaW5l
cyBtYWtlZGV2IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmgg
ZGVmaW5lcyBtYWtlZGV2Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zeXNf
dHlwZXNfaF9tYWtlZGV2K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgoraW50
CittYWluICgpCit7CityZXR1cm4gbWFrZWRldigwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9o
ZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N5c190
eXBlc19oX21ha2VkZXY9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRl
cl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjY7IH0KKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5
c190eXBlc19oX21ha2VkZXYgPSBubzsgdGhlbgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgInN5cy9ta2Rldi5oIiAiYWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIg
PSB4IiJ5ZXM7IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBNQUpPUl9JTl9NS0RFViAxIiA+
PmNvbmZkZWZzLmgKKworZmkKKworCisKKyAgaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5c19ta2Rl
dl9oID0gbm87IHRoZW4KKyAgICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5P
IiAic3lzL3N5c21hY3Jvcy5oIiAiYWNfY3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgIiRhY19p
bmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jvc19o
IiA9IHgiInllczsgdGhlbiA6CisKKyRhc19lY2hvICIjZGVmaW5lIE1BSk9SX0lOX1NZU01BQ1JP
UyAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisgIGZpCitmaQorCitmb3IgYWNfaGVhZGVyIGlu
IHN0ZGxpYi5oCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8i
ICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0
IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3RkbGliX2giID0geCIieWVzOyB0aGVuIDoKKyAg
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NURExJQl9IIDEKK19BQ0VP
RgorCitmaQorCitkb25lCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgbWFsbG9jIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxvYy4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwrc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1u
bworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5l
ZCBIQVZFX1NURExJQl9ICisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorI2Vsc2UKK2NoYXIgKm1hbGxv
YyAoKTsKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAhIG1hbGxvYyAoMCk7Cisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9eWVzCitlbHNlCisgIGFjX2N2
X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29u
ZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNf
bWFsbG9jXzBfbm9ubnVsbCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9u
bnVsbCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwgPSB5ZXM7
IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAxIiA+PmNvbmZkZWZzLmgK
KworZWxzZQorICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAwIiA+PmNvbmZkZWZzLmgK
KworICAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbWFsbG9jLiRhY19vYmpleHQgIiogKSA7
OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBtYWxsb2MuJGFjX29iamV4dCIKKyA7OworZXNhYwor
CisKKyRhc19lY2hvICIjZGVmaW5lIG1hbGxvYyBycGxfbWFsbG9jIiA+PmNvbmZkZWZzLmgKKwor
ZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVkIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBi
b3RoIGJlIGluY2x1ZGVkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl90aW1l
K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNv
bmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy90aW1l
Lmg+CisjaW5jbHVkZSA8dGltZS5oPgorCitpbnQKK21haW4gKCkKK3sKK2lmICgoc3RydWN0IHRt
ICopIDApCityZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfdGltZT15ZXMK
K2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3RpbWU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl90aW1lIiA+
JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQoraWYgdGVzdCAkYWNfY3Zf
aGVhZGVyX3RpbWUgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgVElNRV9XSVRIX1NZ
U19USU1FIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKworCisgIGZvciBhY19oZWFkZXIgaW4g
JGFjX2hlYWRlcl9saXN0CitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hl
YWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBp
bGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsg
dGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJI
QVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKwor
CisKKworCisKKworCisgIGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKK2RvIDoKKyAgYXNf
YWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19m
bl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFs
IHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190
cl9jcHBgIDEKK19BQ0VPRgorCitmaQorZG9uZQorCisKKworCisKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1lIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIG1rdGltZS4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBp
bGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKy8qIFRlc3QgcHJvZ3JhbSBmcm9tIFBhdWwgRWdnZXJ0IGFuZCBUb255
IExlbmVpcy4gICovCisjaWZkZWYgVElNRV9XSVRIX1NZU19USU1FCisjIGluY2x1ZGUgPHN5cy90
aW1lLmg+CisjIGluY2x1ZGUgPHRpbWUuaD4KKyNlbHNlCisjIGlmZGVmIEhBVkVfU1lTX1RJTUVf
SAorIyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4KKyMgZWxzZQorIyAgaW5jbHVkZSA8dGltZS5oPgor
IyBlbmRpZgorI2VuZGlmCisKKyNpbmNsdWRlIDxsaW1pdHMuaD4KKyNpbmNsdWRlIDxzdGRsaWIu
aD4KKworI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3RkLmg+CisjZW5kaWYK
KworI2lmbmRlZiBIQVZFX0FMQVJNCisjIGRlZmluZSBhbGFybShYKSAvKiBlbXB0eSAqLworI2Vu
ZGlmCisKKy8qIFdvcmsgYXJvdW5kIHJlZGVmaW5pdGlvbiB0byBycGxfcHV0ZW52IGJ5IG90aGVy
IGNvbmZpZyB0ZXN0cy4gICovCisjdW5kZWYgcHV0ZW52CisKK3N0YXRpYyB0aW1lX3QgdGltZV90
X21heDsKK3N0YXRpYyB0aW1lX3QgdGltZV90X21pbjsKKworLyogVmFsdWVzIHdlJ2xsIHVzZSB0
byBzZXQgdGhlIFRaIGVudmlyb25tZW50IHZhcmlhYmxlLiAgKi8KK3N0YXRpYyBjb25zdCBjaGFy
ICp0el9zdHJpbmdzW10gPSB7CisgIChjb25zdCBjaGFyICopIDAsICJUWj1HTVQwIiwgIlRaPUpT
VC05IiwKKyAgIlRaPUVTVCszRURUKzIsTTEwLjEuMC8wMDowMDowMCxNMi4zLjAvMDA6MDA6MDAi
Cit9OworI2RlZmluZSBOX1NUUklOR1MgKHNpemVvZiAodHpfc3RyaW5ncykgLyBzaXplb2YgKHR6
X3N0cmluZ3NbMF0pKQorCisvKiBSZXR1cm4gMCBpZiBta3RpbWUgZmFpbHMgdG8gY29udmVydCBh
IGRhdGUgaW4gdGhlIHNwcmluZy1mb3J3YXJkIGdhcC4KKyAgIEJhc2VkIG9uIGEgcHJvYmxlbSBy
ZXBvcnQgZnJvbSBBbmRyZWFzIEphZWdlci4gICovCitzdGF0aWMgaW50CitzcHJpbmdfZm9yd2Fy
ZF9nYXAgKCkKK3sKKyAgLyogZ2xpYmMgKHVwIHRvIGFib3V0IDE5OTgtMTAtMDcpIGZhaWxlZCB0
aGlzIHRlc3QuICovCisgIHN0cnVjdCB0bSB0bTsKKworICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBP
U0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIKKyAgICAgaW5z
dGVhZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVn
IGV2ZW4KKyAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhlIE9sc29uIGV4dGVu
c2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUKKyAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFs
bGVkLiAgKi8KKyAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7
CisKKyAgdG0udG1feWVhciA9IDk4OworICB0bS50bV9tb24gPSAzOworICB0bS50bV9tZGF5ID0g
NTsKKyAgdG0udG1faG91ciA9IDI7CisgIHRtLnRtX21pbiA9IDA7CisgIHRtLnRtX3NlYyA9IDA7
CisgIHRtLnRtX2lzZHN0ID0gLTE7CisgIHJldHVybiBta3RpbWUgKCZ0bSkgIT0gKHRpbWVfdCkg
LTE7Cit9CisKK3N0YXRpYyBpbnQKK21rdGltZV90ZXN0MSAodGltZV90IG5vdykKK3sKKyAgc3Ry
dWN0IHRtICpsdDsKKyAgcmV0dXJuICEgKGx0ID0gbG9jYWx0aW1lICgmbm93KSkgfHwgbWt0aW1l
IChsdCkgPT0gbm93OworfQorCitzdGF0aWMgaW50Citta3RpbWVfdGVzdCAodGltZV90IG5vdykK
K3sKKyAgcmV0dXJuIChta3RpbWVfdGVzdDEgKG5vdykKKwkgICYmIG1rdGltZV90ZXN0MSAoKHRp
bWVfdCkgKHRpbWVfdF9tYXggLSBub3cpKQorCSAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAo
dGltZV90X21pbiArIG5vdykpKTsKK30KKworc3RhdGljIGludAoraXJpeF82XzRfYnVnICgpCit7
CisgIC8qIEJhc2VkIG9uIGNvZGUgZnJvbSBBcmllbCBGYWlnb24uICAqLworICBzdHJ1Y3QgdG0g
dG07CisgIHRtLnRtX3llYXIgPSA5NjsKKyAgdG0udG1fbW9uID0gMzsKKyAgdG0udG1fbWRheSA9
IDA7CisgIHRtLnRtX2hvdXIgPSAwOworICB0bS50bV9taW4gPSAwOworICB0bS50bV9zZWMgPSAw
OworICB0bS50bV9pc2RzdCA9IC0xOworICBta3RpbWUgKCZ0bSk7CisgIHJldHVybiB0bS50bV9t
b24gPT0gMiAmJiB0bS50bV9tZGF5ID09IDMxOworfQorCitzdGF0aWMgaW50CitiaWd0aW1lX3Rl
c3QgKGludCBqKQoreworICBzdHJ1Y3QgdG0gdG07CisgIHRpbWVfdCBub3c7CisgIHRtLnRtX3ll
YXIgPSB0bS50bV9tb24gPSB0bS50bV9tZGF5ID0gdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRt
LnRtX3NlYyA9IGo7CisgIG5vdyA9IG1rdGltZSAoJnRtKTsKKyAgaWYgKG5vdyAhPSAodGltZV90
KSAtMSkKKyAgICB7CisgICAgICBzdHJ1Y3QgdG0gKmx0ID0gbG9jYWx0aW1lICgmbm93KTsKKyAg
ICAgIGlmICghIChsdAorCSAgICAgJiYgbHQtPnRtX3llYXIgPT0gdG0udG1feWVhcgorCSAgICAg
JiYgbHQtPnRtX21vbiA9PSB0bS50bV9tb24KKwkgICAgICYmIGx0LT50bV9tZGF5ID09IHRtLnRt
X21kYXkKKwkgICAgICYmIGx0LT50bV9ob3VyID09IHRtLnRtX2hvdXIKKwkgICAgICYmIGx0LT50
bV9taW4gPT0gdG0udG1fbWluCisJICAgICAmJiBsdC0+dG1fc2VjID09IHRtLnRtX3NlYworCSAg
ICAgJiYgbHQtPnRtX3lkYXkgPT0gdG0udG1feWRheQorCSAgICAgJiYgbHQtPnRtX3dkYXkgPT0g
dG0udG1fd2RheQorCSAgICAgJiYgKChsdC0+dG1faXNkc3QgPCAwID8gLTEgOiAwIDwgbHQtPnRt
X2lzZHN0KQorCQkgID09ICh0bS50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCB0bS50bV9pc2RzdCkp
KSkKKwlyZXR1cm4gMDsKKyAgICB9CisgIHJldHVybiAxOworfQorCitzdGF0aWMgaW50Cit5ZWFy
XzIwNTBfdGVzdCAoKQoreworICAvKiBUaGUgY29ycmVjdCBhbnN3ZXIgZm9yIDIwNTAtMDItMDEg
MDA6MDA6MDAgaW4gUGFjaWZpYyB0aW1lLAorICAgICBpZ25vcmluZyBsZWFwIHNlY29uZHMuICAq
LworICB1bnNpZ25lZCBsb25nIGludCBhbnN3ZXIgPSAyNTI3MzE1MjAwVUw7CisKKyAgc3RydWN0
IHRtIHRtOworICB0aW1lX3QgdDsKKyAgdG0udG1feWVhciA9IDIwNTAgLSAxOTAwOworICB0bS50
bV9tb24gPSAyIC0gMTsKKyAgdG0udG1fbWRheSA9IDE7CisgIHRtLnRtX2hvdXIgPSB0bS50bV9t
aW4gPSB0bS50bV9zZWMgPSAwOworICB0bS50bV9pc2RzdCA9IC0xOworCisgIC8qIFVzZSB0aGUg
cG9ydGFibGUgUE9TSVguMSBzcGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4w
IgorICAgICBpbnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0
ZWN0IHRoZSBidWcgZXZlbgorICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUg
T2xzb24gZXh0ZW5zaW9uLCBvciBkb24ndCBoYXZlIHRoZQorICAgICBmdWxsIHpvbmVpbmZvIHRh
YmxlcyBpbnN0YWxsZWQuICAqLworICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4w
LE0xMC41LjAiKTsKKworICB0ID0gbWt0aW1lICgmdG0pOworCisgIC8qIENoZWNrIHRoYXQgdGhl
IHJlc3VsdCBpcyBlaXRoZXIgYSBmYWlsdXJlLCBvciBjbG9zZSBlbm91Z2gKKyAgICAgdG8gdGhl
IGNvcnJlY3QgYW5zd2VyIHRoYXQgd2UgY2FuIGFzc3VtZSB0aGUgZGlzY3JlcGFuY3kgaXMKKyAg
ICAgZHVlIHRvIGxlYXAgc2Vjb25kcy4gICovCisgIHJldHVybiAodCA9PSAodGltZV90KSAtMQor
CSAgfHwgKDAgPCB0ICYmIGFuc3dlciAtIDEyMCA8PSB0ICYmIHQgPD0gYW5zd2VyICsgMTIwKSk7
Cit9CisKK2ludAorbWFpbiAoKQoreworICB0aW1lX3QgdCwgZGVsdGE7CisgIGludCBpLCBqOwor
CisgIC8qIFRoaXMgdGVzdCBtYWtlcyBzb21lIGJ1Z2d5IG1rdGltZSBpbXBsZW1lbnRhdGlvbnMg
bG9vcC4KKyAgICAgR2l2ZSB1cCBhZnRlciA2MCBzZWNvbmRzOyBhIG1rdGltZSBzbG93ZXIgdGhh
biB0aGF0CisgICAgIGlzbid0IHdvcnRoIHVzaW5nIGFueXdheS4gICovCisgIGFsYXJtICg2MCk7
CisKKyAgZm9yICg7OykKKyAgICB7CisgICAgICB0ID0gKHRpbWVfdF9tYXggPDwgMSkgKyAxOwor
ICAgICAgaWYgKHQgPD0gdGltZV90X21heCkKKwlicmVhazsKKyAgICAgIHRpbWVfdF9tYXggPSB0
OworICAgIH0KKyAgdGltZV90X21pbiA9IC0gKCh0aW1lX3QpIH4gKHRpbWVfdCkgMCA9PSAodGlt
ZV90KSAtMSkgLSB0aW1lX3RfbWF4OworCisgIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyog
YSBzdWl0YWJsZSBwcmltZSBudW1iZXIgKi8KKyAgZm9yIChpID0gMDsgaSA8IE5fU1RSSU5HUzsg
aSsrKQorICAgIHsKKyAgICAgIGlmICh0el9zdHJpbmdzW2ldKQorCXB1dGVudiAoKGNoYXIqKSB0
el9zdHJpbmdzW2ldKTsKKworICAgICAgZm9yICh0ID0gMDsgdCA8PSB0aW1lX3RfbWF4IC0gZGVs
dGE7IHQgKz0gZGVsdGEpCisJaWYgKCEgbWt0aW1lX3Rlc3QgKHQpKQorCSAgcmV0dXJuIDE7Cisg
ICAgICBpZiAoISAobWt0aW1lX3Rlc3QgKCh0aW1lX3QpIDEpCisJICAgICAmJiBta3RpbWVfdGVz
dCAoKHRpbWVfdCkgKDYwICogNjApKQorCSAgICAgJiYgbWt0aW1lX3Rlc3QgKCh0aW1lX3QpICg2
MCAqIDYwICogMjQpKSkpCisJcmV0dXJuIDE7CisKKyAgICAgIGZvciAoaiA9IDE7IDsgaiA8PD0g
MSkKKwlpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQorCSAgcmV0dXJuIDE7CisJZWxzZSBpZiAoSU5U
X01BWCAvIDIgPCBqKQorCSAgYnJlYWs7CisgICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKElOVF9N
QVgpKQorCXJldHVybiAxOworICAgIH0KKyAgcmV0dXJuICEgKGlyaXhfNl80X2J1ZyAoKSAmJiBz
cHJpbmdfZm9yd2FyZF9nYXAgKCkgJiYgeWVhcl8yMDUwX3Rlc3QgKCkpOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY193b3JraW5n
X21rdGltZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubworZmkKK3Jt
IC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3Qk
YWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0
LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNQorJGFzX2VjaG8gIiRh
Y19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfd29y
a2luZ19ta3RpbWUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBta3Rp
bWUuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIG1rdGltZS4kYWNf
b2JqZXh0IgorIDs7Citlc2FjCisKK2ZpCisKKworCisKKworCitmb3IgYWNfZnVuYyBpbiBnZXRw
YWdlc2l6ZQorZG8gOgorICBhY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6
ZSIgImFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFn
ZXNpemUiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2Rl
ZmluZSBIQVZFX0dFVFBBR0VTSVpFIDEKK19BQ0VPRgorCitmaQorZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3Nz
X2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVk
PW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisvKiBtYWxsb2Mg
bWlnaHQgaGF2ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8KKyN1bmRlZiBtYWxsb2MK
KworLyogVGhhbmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmltIEF2ZXJhIGZvciB0aGlzIHRlc3Qu
CisgICBIZXJlIGlzIGEgbWF0cml4IG9mIG1tYXAgcG9zc2liaWxpdGllczoKKwltbWFwIHByaXZh
dGUgbm90IGZpeGVkCisJbW1hcCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkg
dW5tYXBwZWQKKwltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVk
CisJbW1hcCBzaGFyZWQgbm90IGZpeGVkCisJbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJl
IGN1cnJlbnRseSB1bm1hcHBlZAorCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJl
YWR5IG1hcHBlZAorICAgRm9yIHByaXZhdGUgbWFwcGluZ3MsIHdlIHNob3VsZCB2ZXJpZnkgdGhh
dCBjaGFuZ2VzIGNhbm5vdCBiZSByZWFkKCkKKyAgIGJhY2sgZnJvbSB0aGUgZmlsZSwgbm9yIG1t
YXAncyBiYWNrIGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQKKyAgIGFkZHJlc3MuICAoVGhl
cmUgaGF2ZSBiZWVuIHN5c3RlbXMgd2hlcmUgcHJpdmF0ZSB3YXMgbm90IGNvcnJlY3RseQorICAg
aW1wbGVtZW50ZWQgbGlrZSB0aGUgaW5mYW1vdXMgaTM4NiBzdnI0LjAsIGFuZCBzeXN0ZW1zIHdo
ZXJlIHRoZQorICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90IGNvaGVyZW50IHdpdGggdGhlIGZpbGUg
c3lzdGVtIGJ1ZmZlciBjYWNoZQorICAgbGlrZSBlYXJseSB2ZXJzaW9ucyBvZiBGcmVlQlNEIGFu
ZCBwb3NzaWJseSBjb250ZW1wb3JhcnkgTmV0QlNELikKKyAgIEZvciBzaGFyZWQgbWFwcGluZ3Ms
IHdlIHNob3VsZCBjb252ZXJzZWx5IHZlcmlmeSB0aGF0IGNoYW5nZXMgZ2V0CisgICBwcm9wYWdh
dGVkIGJhY2sgdG8gYWxsIHRoZSBwbGFjZXMgdGhleSdyZSBzdXBwb3NlZCB0byBiZS4KKworICAg
R3JlcCB3YW50cyBwcml2YXRlIGZpeGVkIGFscmVhZHkgbWFwcGVkLgorICAgVGhlIG1haW4gdGhp
bmdzIGdyZXAgbmVlZHMgdG8ga25vdyBhYm91dCBtbWFwIGFyZToKKyAgICogZG9lcyBpdCBleGlz
dCBhbmQgaXMgaXQgc2FmZSB0byB3cml0ZSBpbnRvIHRoZSBtbWFwJ2QgYXJlYQorICAgKiBob3cg
dG8gdXNlIGl0IChCU0QgdmFyaWFudHMpICAqLworCisjaW5jbHVkZSA8ZmNudGwuaD4KKyNpbmNs
dWRlIDxzeXMvbW1hbi5oPgorCisjaWYgIWRlZmluZWQgU1REQ19IRUFERVJTICYmICFkZWZpbmVk
IEhBVkVfU1RETElCX0gKK2NoYXIgKm1hbGxvYyAoKTsKKyNlbmRpZgorCisvKiBUaGlzIG1lc3Mg
d2FzIGNvcGllZCBmcm9tIHRoZSBHTlUgZ2V0cGFnZXNpemUuaC4gICovCisjaWZuZGVmIEhBVkVf
R0VUUEFHRVNJWkUKKyMgaWZkZWYgX1NDX1BBR0VTSVpFCisjICBkZWZpbmUgZ2V0cGFnZXNpemUo
KSBzeXNjb25mKF9TQ19QQUdFU0laRSkKKyMgZWxzZSAvKiBubyBfU0NfUEFHRVNJWkUgKi8KKyMg
IGlmZGVmIEhBVkVfU1lTX1BBUkFNX0gKKyMgICBpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyMgICBp
ZmRlZiBFWEVDX1BBR0VTSVpFCisjICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIEVYRUNfUEFHRVNJ
WkUKKyMgICBlbHNlIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgICAgaWZkZWYgTkJQRworIyAg
ICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgTkJQRyAqIENMU0laRQorIyAgICAgaWZuZGVmIENMU0la
RQorIyAgICAgIGRlZmluZSBDTFNJWkUgMQorIyAgICAgZW5kaWYgLyogbm8gQ0xTSVpFICovCisj
ICAgIGVsc2UgLyogbm8gTkJQRyAqLworIyAgICAgaWZkZWYgTkJQQworIyAgICAgIGRlZmluZSBn
ZXRwYWdlc2l6ZSgpIE5CUEMKKyMgICAgIGVsc2UgLyogbm8gTkJQQyAqLworIyAgICAgIGlmZGVm
IFBBR0VTSVpFCisjICAgICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIFBBR0VTSVpFCisjICAgICAg
ZW5kaWYgLyogUEFHRVNJWkUgKi8KKyMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KKyMgICAgZW5k
aWYgLyogbm8gTkJQRyAqLworIyAgIGVuZGlmIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgIGVs
c2UgLyogbm8gSEFWRV9TWVNfUEFSQU1fSCAqLworIyAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIDgx
OTIJLyogcHVudCB0b3RhbGx5ICovCisjICBlbmRpZiAvKiBubyBIQVZFX1NZU19QQVJBTV9IICov
CisjIGVuZGlmIC8qIG5vIF9TQ19QQUdFU0laRSAqLworCisjZW5kaWYgLyogbm8gSEFWRV9HRVRQ
QUdFU0laRSAqLworCitpbnQKK21haW4gKCkKK3sKKyAgY2hhciAqZGF0YSwgKmRhdGEyLCAqZGF0
YTM7CisgIGNvbnN0IGNoYXIgKmNkYXRhMjsKKyAgaW50IGksIHBhZ2VzaXplOworICBpbnQgZmQs
IGZkMjsKKworICBwYWdlc2l6ZSA9IGdldHBhZ2VzaXplICgpOworCisgIC8qIEZpcnN0LCBtYWtl
IGEgZmlsZSB3aXRoIHNvbWUga25vd24gZ2FyYmFnZSBpbiBpdC4gKi8KKyAgZGF0YSA9IChjaGFy
ICopIG1hbGxvYyAocGFnZXNpemUpOworICBpZiAoIWRhdGEpCisgICAgcmV0dXJuIDE7CisgIGZv
ciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgICooZGF0YSArIGkpID0gcmFuZCAoKTsK
KyAgdW1hc2sgKDApOworICBmZCA9IGNyZWF0ICgiY29uZnRlc3QubW1hcCIsIDA2MDApOworICBp
ZiAoZmQgPCAwKQorICAgIHJldHVybiAyOworICBpZiAod3JpdGUgKGZkLCBkYXRhLCBwYWdlc2l6
ZSkgIT0gcGFnZXNpemUpCisgICAgcmV0dXJuIDM7CisgIGNsb3NlIChmZCk7CisKKyAgLyogTmV4
dCwgY2hlY2sgdGhhdCB0aGUgdGFpbCBvZiBhIHBhZ2UgaXMgemVyby1maWxsZWQuICBGaWxlIG11
c3QgaGF2ZQorICAgICBub24temVybyBsZW5ndGgsIG90aGVyd2lzZSB3ZSByaXNrIFNJR0JVUyBm
b3IgZW50aXJlIHBhZ2UuICAqLworICBmZDIgPSBvcGVuICgiY29uZnRlc3QudHh0IiwgT19SRFdS
IHwgT19DUkVBVCB8IE9fVFJVTkMsIDA2MDApOworICBpZiAoZmQyIDwgMCkKKyAgICByZXR1cm4g
NDsKKyAgY2RhdGEyID0gIiI7CisgIGlmICh3cml0ZSAoZmQyLCBjZGF0YTIsIDEpICE9IDEpCisg
ICAgcmV0dXJuIDU7CisgIGRhdGEyID0gKGNoYXIgKikgbW1hcCAoMCwgcGFnZXNpemUsIFBST1Rf
UkVBRCB8IFBST1RfV1JJVEUsIE1BUF9TSEFSRUQsIGZkMiwgMEwpOworICBpZiAoZGF0YTIgPT0g
TUFQX0ZBSUxFRCkKKyAgICByZXR1cm4gNjsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyAr
K2kpCisgICAgaWYgKCooZGF0YTIgKyBpKSkKKyAgICAgIHJldHVybiA3OworICBjbG9zZSAoZmQy
KTsKKyAgaWYgKG11bm1hcCAoZGF0YTIsIHBhZ2VzaXplKSkKKyAgICByZXR1cm4gODsKKworICAv
KiBOZXh0LCB0cnkgdG8gbW1hcCB0aGUgZmlsZSBhdCBhIGZpeGVkIGFkZHJlc3Mgd2hpY2ggYWxy
ZWFkeSBoYXMKKyAgICAgc29tZXRoaW5nIGVsc2UgYWxsb2NhdGVkIGF0IGl0LiAgSWYgd2UgY2Fu
LCBhbHNvIG1ha2Ugc3VyZSB0aGF0CisgICAgIHdlIHNlZSB0aGUgc2FtZSBnYXJiYWdlLiAgKi8K
KyAgZmQgPSBvcGVuICgiY29uZnRlc3QubW1hcCIsIE9fUkRXUik7CisgIGlmIChmZCA8IDApCisg
ICAgcmV0dXJuIDk7CisgIGlmIChkYXRhMiAhPSBtbWFwIChkYXRhMiwgcGFnZXNpemUsIFBST1Rf
UkVBRCB8IFBST1RfV1JJVEUsCisJCSAgICAgTUFQX1BSSVZBVEUgfCBNQVBfRklYRUQsIGZkLCAw
TCkpCisgICAgcmV0dXJuIDEwOworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAg
ICBpZiAoKihkYXRhICsgaSkgIT0gKihkYXRhMiArIGkpKQorICAgICAgcmV0dXJuIDExOworCisg
IC8qIEZpbmFsbHksIG1ha2Ugc3VyZSB0aGF0IGNoYW5nZXMgdG8gdGhlIG1hcHBlZCBhcmVhIGRv
IG5vdAorICAgICBwZXJjb2xhdGUgYmFjayB0byB0aGUgZmlsZSBhcyBzZWVuIGJ5IHJlYWQoKS4g
IChUaGlzIGlzIGEgYnVnIG9uCisgICAgIHNvbWUgdmFyaWFudHMgb2YgaTM4NiBzdnI0LjAuKSAg
Ki8KKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAgKihkYXRhMiArIGkpID0g
KihkYXRhMiArIGkpICsgMTsKKyAgZGF0YTMgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsK
KyAgaWYgKCFkYXRhMykKKyAgICByZXR1cm4gMTI7CisgIGlmIChyZWFkIChmZCwgZGF0YTMsIHBh
Z2VzaXplKSAhPSBwYWdlc2l6ZSkKKyAgICByZXR1cm4gMTM7CisgIGZvciAoaSA9IDA7IGkgPCBw
YWdlc2l6ZTsgKytpKQorICAgIGlmICgqKGRhdGEgKyBpKSAhPSAqKGRhdGEzICsgaSkpCisgICAg
ICByZXR1cm4gMTQ7CisgIGNsb3NlIChmZCk7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVk
X21hcHBlZD15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD1ubworZmkK
K3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRl
c3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0
ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2
X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUg
SEFWRV9NTUFQIDEiID4+Y29uZmRlZnMuaAorCitmaQorcm0gLWYgY29uZnRlc3QubW1hcCBjb25m
dGVzdC50eHQKKworZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAorZG8gOgorICBhY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3Rk
bGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0
ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgSEFWRV9TVERMSUJfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21w
YXRpYmxlIHJlYWxsb2MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNv
bXBhdGlibGUgcmVhbGxvYy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX3JlYWxs
b2NfMF9ub25udWxsK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgor
ICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
ZiBkZWZpbmVkIFNURENfSEVBREVSUyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKKyMgaW5jbHVk
ZSA8c3RkbGliLmg+CisjZWxzZQorY2hhciAqcmVhbGxvYyAoKTsKKyNlbmRpZgorCitpbnQKK21h
aW4gKCkKK3sKK3JldHVybiAhIHJlYWxsb2MgKDAsIDApOworICA7CisgIHJldHVybiAwOworfQor
X0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9u
bnVsbD1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBi
Yi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KK2lm
IHRlc3QgJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwgPSB5ZXM7IHRoZW4gOgorCiskYXNf
ZWNobyAiI2RlZmluZSBIQVZFX1JFQUxMT0MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgJGFz
X2VjaG8gIiNkZWZpbmUgSEFWRV9SRUFMTE9DIDAiID4+Y29uZmRlZnMuaAorCisgICBjYXNlICIg
JExJQk9CSlMgIiBpbgorICAqIiByZWFsbG9jLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJP
QkpTPSIkTElCT0JKUyByZWFsbG9jLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworCiskYXNfZWNo
byAiI2RlZmluZSByZWFsbG9jIHJwbF9yZWFsbG9jIiA+PmNvbmZkZWZzLmgKKworZmkKKworCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3Jr
aW5nIHN0cm5sZW4iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3Rybmxl
bi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZytzZXR9
IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlm
IHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19zdHJu
bGVuX3dvcmtpbmc9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQK
K2ludAorbWFpbiAoKQoreworCisjZGVmaW5lIFMgImZvb2JhciIKKyNkZWZpbmUgU19MRU4gKHNp
emVvZiBTIC0gMSkKKworICAvKiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYnVnZ3k6
IHRoYXQgb2YgQUlYIDQuMyB3b3VsZAorICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMuICAq
LworCisgIGludCBpOworICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCisgICAgewor
ICAgICAgaW50IGV4cGVjdGVkID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsKKyAgICAgIGlmIChz
dHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKKwlyZXR1cm4gMTsKKyAgICB9CisgIHJldHVybiAw
OworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKK2Vsc2UKKyAg
YWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3Jl
LmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9m
dW5jX3N0cm5sZW5fd29ya2luZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93
b3JraW5nIiA+JjY7IH0KK3Rlc3QgJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nID0gbm8gJiYg
Y2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgc3Rybmxlbi4kYWNfb2JqZXh0ICIqICkgOzsKKyAg
KikgTElCT0JKUz0iJExJQk9CSlMgc3Rybmxlbi4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKKwor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29y
a2luZyBzdHJ0b2QiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9k
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2Z1bmNfc3RydG9kK3NldH0iID0gc2V0OyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNy
b3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3N0cnRvZD1ubworZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKKyRhY19pbmNsdWRlc19kZWZhdWx0CisjaWZuZGVmIHN0cnRvZAor
ZG91YmxlIHN0cnRvZCAoKTsKKyNlbmRpZgoraW50CittYWluKCkKK3sKKyAgeworICAgIC8qIFNv
bWUgdmVyc2lvbnMgb2YgTGludXggc3RydG9kIG1pcy1wYXJzZSBzdHJpbmdzIHdpdGggbGVhZGlu
ZyAnKycuICAqLworICAgIGNoYXIgKnN0cmluZyA9ICIgKzY5IjsKKyAgICBjaGFyICp0ZXJtOwor
ICAgIGRvdWJsZSB2YWx1ZTsKKyAgICB2YWx1ZSA9IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Cisg
ICAgaWYgKHZhbHVlICE9IDY5IHx8IHRlcm0gIT0gKHN0cmluZyArIDQpKQorICAgICAgcmV0dXJu
IDE7CisgIH0KKworICB7CisgICAgLyogVW5kZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5z
IHRoZSB3cm9uZyB2YWx1ZSBmb3IgdGhlCisgICAgICAgdGVybWluYXRpbmcgY2hhcmFjdGVyIHVu
ZGVyIHNvbWUgY29uZGl0aW9ucy4gICovCisgICAgY2hhciAqc3RyaW5nID0gIk5hTiI7CisgICAg
Y2hhciAqdGVybTsKKyAgICBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOworICAgIGlmICh0ZXJtICE9
IHN0cmluZyAmJiAqKHRlcm0gLSAxKSA9PSAwKQorICAgICAgcmV0dXJuIDE7CisgIH0KKyAgcmV0
dXJuIDA7Cit9CisKK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2Z1bmNfc3RydG9kPXllcworZWxzZQorICBhY19jdl9mdW5jX3N0cnRvZD1ubwor
ZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29u
ZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfc3RydG9kIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfZnVuY19zdHJ0b2QiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19zdHJ0b2QgPSBubzsg
dGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBzdHJ0b2QuJGFjX29iamV4dCAiKiAp
IDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIHN0cnRvZC4kYWNfb2JqZXh0IgorIDs7Citlc2Fj
CisKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgInBvdyIgImFjX2N2X2Z1bmNfcG93Igor
aWYgdGVzdCAieCRhY19jdl9mdW5jX3BvdyIgPSB4IiJ5ZXM7IHRoZW4gOgorCitmaQorCitpZiB0
ZXN0ICRhY19jdl9mdW5jX3BvdyA9IG5vOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHBvdyBpbiAtbG0iID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHBvdyBpbiAtbG0uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zf
bGliX21fcG93K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxtICAkTElC
UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg
dG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0
aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50
IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4
dGVybiAiQyIKKyNlbmRpZgorY2hhciBwb3cgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBw
b3cgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsg
IiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX21fcG93PXllcworZWxzZQorICBhY19jdl9s
aWJfbV9wb3c9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNf
Y2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX21fcG93IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
bGliX21fcG93IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX21fcG93IiA9IHgiInllczsg
dGhlbiA6CisgIFBPV19MSUI9LWxtCitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRl
ZmluaXRpb24gb2YgcG93IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IGNhbm5vdCBm
aW5kIGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9mIHBvdyIgPiYyO30KK2ZpCisKK2Zp
CisKK2ZpCisKK2ZvciBhY19mdW5jIGluICBcCisgICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0
IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKKyAgICAgICAg
ICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0
aW1lb2ZkYXkgXAorICAgICAgICAgICAgICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9y
IG1lbWNociBtZW1tb3ZlIG1lbXNldCBta2RpciBcCisgICAgICAgICAgICAgICAgbWtmaWZvIG11
bm1hcCBwYXRoY29uZiByZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAorICAg
ICAgICAgICAgICAgIHNvY2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJl
cnJvciBzdHJuZHVwIFwKKyAgICAgICAgICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0
cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNldCBcCisgICAgICAgICAgICAgICAgdW5h
bWUgXAorCitkbyA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMi
IHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIk
YXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRo
ZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFW
RV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKK2RvbmUKKworCitjYXQg
PmNvbmZjYWNoZSA8PFxfQUNFT0YKKyMgVGhpcyBmaWxlIGlzIGEgc2hlbGwgc2NyaXB0IHRoYXQg
Y2FjaGVzIHRoZSByZXN1bHRzIG9mIGNvbmZpZ3VyZQorIyB0ZXN0cyBydW4gb24gdGhpcyBzeXN0
ZW0gc28gdGhleSBjYW4gYmUgc2hhcmVkIGJldHdlZW4gY29uZmlndXJlCisjIHNjcmlwdHMgYW5k
IGNvbmZpZ3VyZSBydW5zLCBzZWUgY29uZmlndXJlJ3Mgb3B0aW9uIC0tY29uZmlnLWNhY2hlLgor
IyBJdCBpcyBub3QgdXNlZnVsIG9uIG90aGVyIHN5c3RlbXMuICBJZiBpdCBjb250YWlucyByZXN1
bHRzIHlvdSBkb24ndAorIyB3YW50IHRvIGtlZXAsIHlvdSBtYXkgcmVtb3ZlIG9yIGVkaXQgaXQu
CisjCisjIGNvbmZpZy5zdGF0dXMgb25seSBwYXlzIGF0dGVudGlvbiB0byB0aGUgY2FjaGUgZmls
ZSBpZiB5b3UgZ2l2ZSBpdAorIyB0aGUgLS1yZWNoZWNrIG9wdGlvbiB0byByZXJ1biBjb25maWd1
cmUuCisjCisjIGBhY19jdl9lbnZfZm9vJyB2YXJpYWJsZXMgKHNldCBvciB1bnNldCkgd2lsbCBi
ZSBvdmVycmlkZGVuIHdoZW4KKyMgbG9hZGluZyB0aGlzIGZpbGUsIG90aGVyICp1bnNldCogYGFj
X2N2X2Zvbycgd2lsbCBiZSBhc3NpZ25lZCB0aGUKKyMgZm9sbG93aW5nIHZhbHVlcy4KKworX0FD
RU9GCisKKyMgVGhlIGZvbGxvd2luZyB3YXkgb2Ygd3JpdGluZyB0aGUgY2FjaGUgbWlzaGFuZGxl
cyBuZXdsaW5lcyBpbiB2YWx1ZXMsCisjIGJ1dCB3ZSBrbm93IG9mIG5vIHdvcmthcm91bmQgdGhh
dCBpcyBzaW1wbGUsIHBvcnRhYmxlLCBhbmQgZWZmaWNpZW50LgorIyBTbywgd2Uga2lsbCB2YXJp
YWJsZXMgY29udGFpbmluZyBuZXdsaW5lcy4KKyMgVWx0cml4IHNoIHNldCB3cml0ZXMgdG8gc3Rk
ZXJyIGFuZCBjYW4ndCBiZSByZWRpcmVjdGVkIGRpcmVjdGx5LAorIyBhbmQgc2V0cyB0aGUgaGln
aCBiaXQgaW4gdGhlIGNhY2hlIGZpbGUgdW5sZXNzIHdlIGFzc2lnbiB0byB0aGUgdmFycy4KKygK
KyAgZm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAtbiAncy9eXChbYS16QS1aX11bYS16
QS1aMC05X10qXCk9LiovXDEvcCdgOyBkbworICAgIGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAg
IGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSopCisgICAgICBjYXNlICRhY192YXIg
aW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGluZSIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNv
bnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVzYWMKKyAgICAgIGNhc2UgJGFjX3Zh
ciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAjKAorICAgICAgQkFTSF9BUkdWIHwg
QkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAgICAgICopIHsgZXZhbCAkYWNfdmFy
PTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7CisgICAgZXNhYworICBkb25lCisK
KyAgKHNldCkgMj4mMSB8CisgICAgY2FzZSAkYXNfbmxgKGFjX3NwYWNlPScgJzsgc2V0KSAyPiYx
YCBpbiAjKAorICAgICoke2FzX25sfWFjX3NwYWNlPVwgKikKKyAgICAgICMgYHNldCcgZG9lcyBu
b3QgcXVvdGUgY29ycmVjdGx5LCBzbyBhZGQgcXVvdGVzOiBkb3VibGUtcXVvdGUKKyAgICAgICMg
c3Vic3RpdHV0aW9uIHR1cm5zIFxcXFwgaW50byBcXCwgYW5kIHNlZCB0dXJucyBcXCBpbnRvIFwu
CisgICAgICBzZWQgLW4gXAorCSJzLycvJ1xcXFwnJy9nOworCSAgcy9eXFwoW18kYXNfY3JfYWxu
dW1dKl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwpL1xcMT0nXFwyJy9wIgorICAgICAg
OzsgIygKKyAgICAqKQorICAgICAgIyBgc2V0JyBxdW90ZXMgY29ycmVjdGx5IGFzIHJlcXVpcmVk
IGJ5IFBPU0lYLCBzbyBkbyBub3QgYWRkIHF1b3Rlcy4KKyAgICAgIHNlZCAtbiAiL15bXyRhc19j
cl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisgICAgICA7OworICAgIGVzYWMgfAor
ICAgIHNvcnQKKykgfAorICBzZWQgJworICAgICAvXmFjX2N2X2Vudl8vYiBlbmQKKyAgICAgdCBj
bGVhcgorICAgICA6Y2xlYXIKKyAgICAgcy9eXChbXj1dKlwpPVwoLipbe31dLipcKSQvdGVzdCAi
JHtcMStzZXR9IiA9IHNldCB8fCAmLworICAgICB0IGVuZAorICAgICBzL15cKFtePV0qXCk9XCgu
KlwpJC9cMT0ke1wxPVwyfS8KKyAgICAgOmVuZCcgPj5jb25mY2FjaGUKK2lmIGRpZmYgIiRjYWNo
ZV9maWxlIiBjb25mY2FjaGUgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDo7IGVsc2UKKyAgaWYgdGVz
dCAtdyAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICAgdGVzdCAieCRjYWNoZV9maWxlIiAhPSAieC9k
ZXYvbnVsbCIgJiYKKyAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogdXBkYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogdXBk
YXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CisgICAgY2F0IGNvbmZjYWNoZSA+JGNhY2hl
X2ZpbGUKKyAgZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogbm90IHVwZGF0aW5nIHVud3JpdGFibGUgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogbm90IHVwZGF0aW5nIHVud3JpdGFibGUgY2FjaGUgJGNhY2hlX2ZpbGUiID4m
Njt9CisgIGZpCitmaQorcm0gLWYgY29uZmNhY2hlCisKK3Rlc3QgIngkcHJlZml4IiA9IHhOT05F
ICYmIHByZWZpeD0kYWNfZGVmYXVsdF9wcmVmaXgKKyMgTGV0IG1ha2UgZXhwYW5kIGV4ZWNfcHJl
Zml4LgordGVzdCAieCRleGVjX3ByZWZpeCIgPSB4Tk9ORSAmJiBleGVjX3ByZWZpeD0nJHtwcmVm
aXh9JworCitERUZTPS1ESEFWRV9DT05GSUdfSAorCithY19saWJvYmpzPQorYWNfbHRsaWJvYmpz
PQorVT0KK2ZvciBhY19pIGluIDogJExJQk9CSlM7IGRvIHRlc3QgIngkYWNfaSIgPSB4OiAmJiBj
b250aW51ZQorICAjIDEuIFJlbW92ZSB0aGUgZXh0ZW5zaW9uLCBhbmQgJFUgaWYgYWxyZWFkeSBp
bnN0YWxsZWQuCisgIGFjX3NjcmlwdD0ncy9cJFVcLi8uLztzL1wubyQvLztzL1wub2JqJC8vJwor
ICBhY19pPWAkYXNfZWNobyAiJGFjX2kiIHwgc2VkICIkYWNfc2NyaXB0ImAKKyAgIyAyLiBQcmVw
ZW5kIExJQk9CSkRJUi4gIFdoZW4gdXNlZCB3aXRoIGF1dG9tYWtlPj0xLjEwIExJQk9CSkRJUgor
ICAjICAgIHdpbGwgYmUgc2V0IHRvIHRoZSBkaXJlY3Rvcnkgd2hlcmUgTElCT0JKUyBvYmplY3Rz
IGFyZSBidWlsdC4KKyAgYXNfZm5fYXBwZW5kIGFjX2xpYm9ianMgIiBcJHtMSUJPQkpESVJ9JGFj
X2lcJFUuJGFjX29iamV4dCIKKyAgYXNfZm5fYXBwZW5kIGFjX2x0bGlib2JqcyAiIFwke0xJQk9C
SkRJUn0kYWNfaSInJFUubG8nCitkb25lCitMSUJPQkpTPSRhY19saWJvYmpzCisKK0xUTElCT0JK
Uz0kYWNfbHRsaWJvYmpzCisKKworCis6ICR7Q09ORklHX1NUQVRVUz0uL2NvbmZpZy5zdGF0dXN9
CithY193cml0ZV9mYWlsPTAKK2FjX2NsZWFuX2ZpbGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCith
Y19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzICRDT05GSUdfU1RBVFVTIgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIgPiY2O30KK2Fz
X3dyaXRlX2ZhaWw9MAorY2F0ID4kQ09ORklHX1NUQVRVUyA8PF9BU0VPRiB8fCBhc193cml0ZV9m
YWlsPTEKKyMhICRTSEVMTAorIyBHZW5lcmF0ZWQgYnkgJGFzX21lLgorIyBSdW4gdGhpcyBmaWxl
IHRvIHJlY3JlYXRlIHRoZSBjdXJyZW50IGNvbmZpZ3VyYXRpb24uCisjIENvbXBpbGVyIG91dHB1
dCBwcm9kdWNlZCBieSBjb25maWd1cmUsIHVzZWZ1bCBmb3IgZGVidWdnaW5nCisjIGNvbmZpZ3Vy
ZSwgaXMgaW4gY29uZmlnLmxvZyBpZiBpdCBleGlzdHMuCisKK2RlYnVnPWZhbHNlCithY19jc19y
ZWNoZWNrPWZhbHNlCithY19jc19zaWxlbnQ9ZmFsc2UKKworU0hFTEw9XCR7Q09ORklHX1NIRUxM
LSRTSEVMTH0KK2V4cG9ydCBTSEVMTAorX0FTRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxf
QVNFT0YgfHwgYXNfd3JpdGVfZmFpbD0xCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMg
TTRzaCBJbml0aWFsaXphdGlvbi4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMg
QmUgbW9yZSBCb3VybmUgY29tcGF0aWJsZQorRFVBTENBU0U9MTsgZXhwb3J0IERVQUxDQVNFICMg
Zm9yIE1LUyBzaAoraWYgdGVzdCAtbiAiJHtaU0hfVkVSU0lPTitzZXR9IiAmJiAoZW11bGF0ZSBz
aCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAg
IyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiAkezErIiRAIn0s
IHdoaWNoCisgICMgaXMgY29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1
cmUuCisgIGFsaWFzIC1nICckezErIiRAIn0nPSciJEAiJworICBzZXRvcHQgTk9fR0xPQl9TVUJT
VAorZWxzZQorICBjYXNlIGAoc2V0IC1vKSAyPi9kZXYvbnVsbGAgaW4gIygKKyAgKnBvc2l4Kikg
OgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorCisK
K2FzX25sPScKKycKK2V4cG9ydCBhc19ubAorIyBQcmludGluZyBhIGxvbmcgc3RyaW5nIGNyYXNo
ZXMgU29sYXJpcyA3IC91c3IvYmluL3ByaW50Zi4KK2FzX2VjaG89J1xcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFwnCithc19lY2hvPSRhc19lY2hvJGFzX2VjaG8k
YXNfZWNobyRhc19lY2hvJGFzX2VjaG8KK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hv
JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCisjIFByZWZlciBhIGtzaCBzaGVsbCBidWlsdGluIG92
ZXIgYW4gZXh0ZXJuYWwgcHJpbnRmIHByb2dyYW0gb24gU29sYXJpcywKKyMgYnV0IHdpdGhvdXQg
d2FzdGluZyBmb3JrcyBmb3IgYmFzaCBvciB6c2guCitpZiB0ZXN0IC16ICIkQkFTSF9WRVJTSU9O
JFpTSF9WRVJTSU9OIiBcCisgICAgJiYgKHRlc3QgIlhgcHJpbnQgLXIgLS0gJGFzX2VjaG9gIiA9
ICJYJGFzX2VjaG8iKSAyPi9kZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmludCAtciAtLScK
KyAgYXNfZWNob19uPSdwcmludCAtcm4gLS0nCitlbGlmICh0ZXN0ICJYYHByaW50ZiAlcyAkYXNf
ZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50
ZiAlc1xuJworICBhc19lY2hvX249J3ByaW50ZiAlcycKK2Vsc2UKKyAgaWYgdGVzdCAiWGAoL3Vz
ci91Y2IvZWNobyAtbiAtbiAkYXNfZWNobykgMj4vZGV2L251bGxgIiA9ICJYLW4gJGFzX2VjaG8i
OyB0aGVuCisgICAgYXNfZWNob19ib2R5PSdldmFsIC91c3IvdWNiL2VjaG8gLW4gIiQxJGFzX25s
IicKKyAgICBhc19lY2hvX249Jy91c3IvdWNiL2VjaG8gLW4nCisgIGVsc2UKKyAgICBhc19lY2hv
X2JvZHk9J2V2YWwgZXhwciAiWCQxIiA6ICJYXFwoLipcXCkiJworICAgIGFzX2VjaG9fbl9ib2R5
PSdldmFsCisgICAgICBhcmc9JDE7CisgICAgICBjYXNlICRhcmcgaW4gIygKKyAgICAgICoiJGFz
X25sIiopCisJZXhwciAiWCRhcmciIDogIlhcXCguKlxcKSRhc19ubCI7CisJYXJnPWBleHByICJY
JGFyZyIgOiAiLiokYXNfbmxcXCguKlxcKSJgOzsKKyAgICAgIGVzYWM7CisgICAgICBleHByICJY
JGFyZyIgOiAiWFxcKC4qXFwpIiB8IHRyIC1kICIkYXNfbmwiCisgICAgJworICAgIGV4cG9ydCBh
c19lY2hvX25fYm9keQorICAgIGFzX2VjaG9fbj0nc2ggLWMgJGFzX2VjaG9fbl9ib2R5IGFzX2Vj
aG8nCisgIGZpCisgIGV4cG9ydCBhc19lY2hvX2JvZHkKKyAgYXNfZWNobz0nc2ggLWMgJGFzX2Vj
aG9fYm9keSBhc19lY2hvJworZmkKKworIyBUaGUgdXNlciBpcyBhbHdheXMgcmlnaHQuCitpZiB0
ZXN0ICIke1BBVEhfU0VQQVJBVE9SK3NldH0iICE9IHNldDsgdGhlbgorICBQQVRIX1NFUEFSQVRP
Uj06CisgIChQQVRIPScvYmluOy9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVs
bCAyPiYxICYmIHsKKyAgICAoUEFUSD0nL2JpbjovYmluJzsgRlBBVEg9JFBBVEg7IHNoIC1jIDop
ID4vZGV2L251bGwgMj4mMSB8fAorICAgICAgUEFUSF9TRVBBUkFUT1I9JzsnCisgIH0KK2ZpCisK
KworIyBJRlMKKyMgV2UgbmVlZCBzcGFjZSwgdGFiIGFuZCBuZXcgbGluZSwgaW4gcHJlY2lzZWx5
IHRoYXQgb3JkZXIuICBRdW90aW5nIGlzCisjIHRoZXJlIHRvIHByZXZlbnQgZWRpdG9ycyBmcm9t
IGNvbXBsYWluaW5nIGFib3V0IHNwYWNlLXRhYi4KKyMgKElmIF9BU19QQVRIX1dBTEsgd2VyZSBj
YWxsZWQgd2l0aCBJRlMgdW5zZXQsIGl0IHdvdWxkIGRpc2FibGUgd29yZAorIyBzcGxpdHRpbmcg
Ynkgc2V0dGluZyBJRlMgdG8gZW1wdHkgdmFsdWUuKQorSUZTPSIgIiIJJGFzX25sIgorCisjIEZp
bmQgd2hvIHdlIGFyZS4gIExvb2sgaW4gdGhlIHBhdGggaWYgd2UgY29udGFpbiBubyBkaXJlY3Rv
cnkgc2VwYXJhdG9yLgorY2FzZSAkMCBpbiAjKCgKKyAgKltcXC9dKiApIGFzX215c2VsZj0kMCA7
OworICAqKSBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgdGVzdCAtciAiJGFzX2Rpci8kMCIgJiYgYXNfbXlzZWxmPSRhc19kaXIv
JDAgJiYgYnJlYWsKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgICAgIDs7Citlc2FjCisj
IFdlIGRpZCBub3QgZmluZCBvdXJzZWx2ZXMsIG1vc3QgcHJvYmFibHkgd2Ugd2VyZSBydW4gYXMg
YHNoIENPTU1BTkQnCisjIGluIHdoaWNoIGNhc2Ugd2UgYXJlIG5vdCB0byBiZSBmb3VuZCBpbiB0
aGUgcGF0aC4KK2lmIHRlc3QgIngkYXNfbXlzZWxmIiA9IHg7IHRoZW4KKyAgYXNfbXlzZWxmPSQw
CitmaQoraWYgdGVzdCAhIC1mICIkYXNfbXlzZWxmIjsgdGhlbgorICAkYXNfZWNobyAiJGFzX215
c2VsZjogZXJyb3I6IGNhbm5vdCBmaW5kIG15c2VsZjsgcmVydW4gd2l0aCBhbiBhYnNvbHV0ZSBm
aWxlIG5hbWUiID4mMgorICBleGl0IDEKK2ZpCisKKyMgVW5zZXQgdmFyaWFibGVzIHRoYXQgd2Ug
ZG8gbm90IG5lZWQgYW5kIHdoaWNoIGNhdXNlIGJ1Z3MgKGUuZy4gaW4KKyMgcHJlLTMuMCBVV0lO
IGtzaCkuICBCdXQgZG8gbm90IGNhdXNlIGJ1Z3MgaW4gYmFzaCAyLjAxOyB0aGUgInx8IGV4aXQg
MSIKKyMgc3VwcHJlc3NlcyBhbnkgIlNlZ21lbnRhdGlvbiBmYXVsdCIgbWVzc2FnZSB0aGVyZS4g
ICcoKCcgY291bGQKKyMgdHJpZ2dlciBhIGJ1ZyBpbiBwZGtzaCA1LjIuMTQuCitmb3IgYXNfdmFy
IGluIEJBU0hfRU5WIEVOViBNQUlMIE1BSUxQQVRICitkbyBldmFsIHRlc3QgeFwkeyRhc192YXIr
c2V0fSA9IHhzZXQgXAorICAmJiAoICh1bnNldCAkYXNfdmFyKSB8fCBleGl0IDEpID4vZGV2L251
bGwgMj4mMSAmJiB1bnNldCAkYXNfdmFyIHx8IDoKK2RvbmUKK1BTMT0nJCAnCitQUzI9Jz4gJwor
UFM0PScrICcKKworIyBOTFMgbnVpc2FuY2VzLgorTENfQUxMPUMKK2V4cG9ydCBMQ19BTEwKK0xB
TkdVQUdFPUMKK2V4cG9ydCBMQU5HVUFHRQorCisjIENEUEFUSC4KKyh1bnNldCBDRFBBVEgpID4v
ZGV2L251bGwgMj4mMSAmJiB1bnNldCBDRFBBVEgKKworCisjIGFzX2ZuX2Vycm9yIFNUQVRVUyBF
UlJPUiBbTElORU5PIExPR19GRF0KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorIyBPdXRwdXQgImBiYXNlbmFtZSAkMGA6IGVycm9yOiBFUlJPUiIgdG8gc3RkZXJy
LiBJZiBMSU5FTk8gYW5kIExPR19GRCBhcmUKKyMgcHJvdmlkZWQsIGFsc28gb3V0cHV0IHRoZSBl
cnJvciB0byBMT0dfRkQsIHJlZmVyZW5jaW5nIExJTkVOTy4gVGhlbiBleGl0IHRoZQorIyBzY3Jp
cHQgd2l0aCBTVEFUVVMsIHVzaW5nIDEgaWYgdGhhdCB3YXMgMC4KK2FzX2ZuX2Vycm9yICgpCit7
CisgIGFzX3N0YXR1cz0kMTsgdGVzdCAkYXNfc3RhdHVzIC1lcSAwICYmIGFzX3N0YXR1cz0xCisg
IGlmIHRlc3QgIiQ0IjsgdGhlbgorICAgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDMifSBhc19s
aW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogJDIiID4mJDQKKyAgZmkKKyAg
JGFzX2VjaG8gIiRhc19tZTogZXJyb3I6ICQyIiA+JjIKKyAgYXNfZm5fZXhpdCAkYXNfc3RhdHVz
Cit9ICMgYXNfZm5fZXJyb3IKKworCisjIGFzX2ZuX3NldF9zdGF0dXMgU1RBVFVTCisjIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCisjIFNldCAkPyB0byBTVEFUVVMsIHdpdGhvdXQgZm9ya2luZy4K
K2FzX2ZuX3NldF9zdGF0dXMgKCkKK3sKKyAgcmV0dXJuICQxCit9ICMgYXNfZm5fc2V0X3N0YXR1
cworCisjIGFzX2ZuX2V4aXQgU1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tCisjIEV4aXQgdGhl
IHNoZWxsIHdpdGggU1RBVFVTLCBldmVuIGluIGEgInRyYXAgMCIgb3IgInNldCAtZSIgY29udGV4
dC4KK2FzX2ZuX2V4aXQgKCkKK3sKKyAgc2V0ICtlCisgIGFzX2ZuX3NldF9zdGF0dXMgJDEKKyAg
ZXhpdCAkMQorfSAjIGFzX2ZuX2V4aXQKKworIyBhc19mbl91bnNldCBWQVIKKyMgLS0tLS0tLS0t
LS0tLS0tCisjIFBvcnRhYmx5IHVuc2V0IFZBUi4KK2FzX2ZuX3Vuc2V0ICgpCit7CisgIHsgZXZh
bCAkMT07IHVuc2V0ICQxO30KK30KK2FzX3Vuc2V0PWFzX2ZuX3Vuc2V0CisjIGFzX2ZuX2FwcGVu
ZCBWQVIgVkFMVUUKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBBcHBlbmQgdGhlIHRleHQg
aW4gVkFMVUUgdG8gdGhlIGVuZCBvZiB0aGUgZGVmaW5pdGlvbiBjb250YWluZWQgaW4gVkFSLiBU
YWtlCisjIGFkdmFudGFnZSBvZiBhbnkgc2hlbGwgb3B0aW1pemF0aW9ucyB0aGF0IGFsbG93IGFt
b3J0aXplZCBsaW5lYXIgZ3Jvd3RoIG92ZXIKKyMgcmVwZWF0ZWQgYXBwZW5kcywgaW5zdGVhZCBv
ZiB0aGUgdHlwaWNhbCBxdWFkcmF0aWMgZ3Jvd3RoIHByZXNlbnQgaW4gbmFpdmUKKyMgaW1wbGVt
ZW50YXRpb25zLgoraWYgKGV2YWwgImFzX3Zhcj0xOyBhc192YXIrPTI7IHRlc3QgeFwkYXNfdmFy
ID0geDEyIikgMj4vZGV2L251bGw7IHRoZW4gOgorICBldmFsICdhc19mbl9hcHBlbmQgKCkKKyAg
eworICAgIGV2YWwgJDErPVwkMgorICB9JworZWxzZQorICBhc19mbl9hcHBlbmQgKCkKKyAgewor
ICAgIGV2YWwgJDE9XCQkMVwkMgorICB9CitmaSAjIGFzX2ZuX2FwcGVuZAorCisjIGFzX2ZuX2Fy
aXRoIEFSRy4uLgorIyAtLS0tLS0tLS0tLS0tLS0tLS0KKyMgUGVyZm9ybSBhcml0aG1ldGljIGV2
YWx1YXRpb24gb24gdGhlIEFSR3MsIGFuZCBzdG9yZSB0aGUgcmVzdWx0IGluIHRoZQorIyBnbG9i
YWwgJGFzX3ZhbC4gVGFrZSBhZHZhbnRhZ2Ugb2Ygc2hlbGxzIHRoYXQgY2FuIGF2b2lkIGZvcmtz
LiBUaGUgYXJndW1lbnRzCisjIG11c3QgYmUgcG9ydGFibGUgYWNyb3NzICQoKCkpIGFuZCBleHBy
LgoraWYgKGV2YWwgInRlc3QgXCQoKCAxICsgMSApKSA9IDIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6
CisgIGV2YWwgJ2FzX2ZuX2FyaXRoICgpCisgIHsKKyAgICBhc192YWw9JCgoICQqICkpCisgIH0n
CitlbHNlCisgIGFzX2ZuX2FyaXRoICgpCisgIHsKKyAgICBhc192YWw9YGV4cHIgIiRAIiB8fCB0
ZXN0ICQ/IC1lcSAxYAorICB9CitmaSAjIGFzX2ZuX2FyaXRoCisKKworaWYgZXhwciBhIDogJ1wo
YVwpJyA+L2Rldi9udWxsIDI+JjEgJiYKKyAgIHRlc3QgIlhgZXhwciAwMDAwMSA6ICcuKlwoLi4u
XCknYCIgPSBYMDAxOyB0aGVuCisgIGFzX2V4cHI9ZXhwcgorZWxzZQorICBhc19leHByPWZhbHNl
CitmaQorCitpZiAoYmFzZW5hbWUgLS0gLykgPi9kZXYvbnVsbCAyPiYxICYmIHRlc3QgIlhgYmFz
ZW5hbWUgLS0gLyAyPiYxYCIgPSAiWC8iOyB0aGVuCisgIGFzX2Jhc2VuYW1lPWJhc2VuYW1lCitl
bHNlCisgIGFzX2Jhc2VuYW1lPWZhbHNlCitmaQorCitpZiAoYXNfZGlyPWBkaXJuYW1lIC0tIC9g
ICYmIHRlc3QgIlgkYXNfZGlyIiA9IFgvKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfZGly
bmFtZT1kaXJuYW1lCitlbHNlCisgIGFzX2Rpcm5hbWU9ZmFsc2UKK2ZpCisKK2FzX21lPWAkYXNf
YmFzZW5hbWUgLS0gIiQwIiB8fAorJGFzX2V4cHIgWC8iJDAiIDogJy4qL1woW14vXVteL10qXCkv
KiQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoL1wpJyBc
fCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYLyIkMCIgfAorICAgIHNlZCAnL14uKlwvXChb
Xi9dW14vXSpcKVwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwv
XC9cKSQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXCkuKi97CisJ
ICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKworIyBBdm9pZCBkZXBl
bmRpbmcgdXBvbiBDaGFyYWN0ZXIgUmFuZ2VzLgorYXNfY3JfbGV0dGVycz0nYWJjZGVmZ2hpamts
bW5vcHFyc3R1dnd4eXonCithc19jcl9MRVRURVJTPSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZ
WicKK2FzX2NyX0xldHRlcnM9JGFzX2NyX2xldHRlcnMkYXNfY3JfTEVUVEVSUworYXNfY3JfZGln
aXRzPScwMTIzNDU2Nzg5JworYXNfY3JfYWxudW09JGFzX2NyX0xldHRlcnMkYXNfY3JfZGlnaXRz
CisKK0VDSE9fQz0gRUNIT19OPSBFQ0hPX1Q9CitjYXNlIGBlY2hvIC1uIHhgIGluICMoKCgoKAor
LW4qKQorICBjYXNlIGBlY2hvICd4eVxjJ2AgaW4KKyAgKmMqKSBFQ0hPX1Q9JwknOzsJIyBFQ0hP
X1QgaXMgc2luZ2xlIHRhYiBjaGFyYWN0ZXIuCisgIHh5KSAgRUNIT19DPSdcYyc7OworICAqKSAg
IGVjaG8gYGVjaG8ga3NoODggYnVnIG9uIEFJWCA2LjFgID4gL2Rldi9udWxsCisgICAgICAgRUNI
T19UPScJJzs7CisgIGVzYWM7OworKikKKyAgRUNIT19OPSctbic7OworZXNhYworCitybSAtZiBj
b25mJCQgY29uZiQkLmV4ZSBjb25mJCQuZmlsZQoraWYgdGVzdCAtZCBjb25mJCQuZGlyOyB0aGVu
CisgIHJtIC1mIGNvbmYkJC5kaXIvY29uZiQkLmZpbGUKK2Vsc2UKKyAgcm0gLWYgY29uZiQkLmRp
cgorICBta2RpciBjb25mJCQuZGlyIDI+L2Rldi9udWxsCitmaQoraWYgKGVjaG8gPmNvbmYkJC5m
aWxlKSAyPi9kZXYvbnVsbDsgdGhlbgorICBpZiBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQgMj4v
ZGV2L251bGw7IHRoZW4KKyAgICBhc19sbl9zPSdsbiAtcycKKyAgICAjIC4uLiBidXQgdGhlcmUg
YXJlIHR3byBnb3RjaGFzOgorICAgICMgMSkgT24gTVNZUywgYm90aCBgbG4gLXMgZmlsZSBkaXIn
IGFuZCBgbG4gZmlsZSBkaXInIGZhaWwuCisgICAgIyAyKSBESkdQUCA8IDIuMDQgaGFzIG5vIHN5
bWxpbmtzOyBgbG4gLXMnIGNyZWF0ZXMgYSB3cmFwcGVyIGV4ZWN1dGFibGUuCisgICAgIyBJbiBi
b3RoIGNhc2VzLCB3ZSBoYXZlIHRvIGRlZmF1bHQgdG8gYGNwIC1wJy4KKyAgICBsbiAtcyBjb25m
JCQuZmlsZSBjb25mJCQuZGlyIDI+L2Rldi9udWxsICYmIHRlc3QgISAtZiBjb25mJCQuZXhlIHx8
CisgICAgICBhc19sbl9zPSdjcCAtcCcKKyAgZWxpZiBsbiBjb25mJCQuZmlsZSBjb25mJCQgMj4v
ZGV2L251bGw7IHRoZW4KKyAgICBhc19sbl9zPWxuCisgIGVsc2UKKyAgICBhc19sbl9zPSdjcCAt
cCcKKyAgZmkKK2Vsc2UKKyAgYXNfbG5fcz0nY3AgLXAnCitmaQorcm0gLWYgY29uZiQkIGNvbmYk
JC5leGUgY29uZiQkLmRpci9jb25mJCQuZmlsZSBjb25mJCQuZmlsZQorcm1kaXIgY29uZiQkLmRp
ciAyPi9kZXYvbnVsbAorCisKKyMgYXNfZm5fbWtkaXJfcAorIyAtLS0tLS0tLS0tLS0tCisjIENy
ZWF0ZSAiJGFzX2RpciIgYXMgYSBkaXJlY3RvcnksIGluY2x1ZGluZyBwYXJlbnRzIGlmIG5lY2Vz
c2FyeS4KK2FzX2ZuX21rZGlyX3AgKCkKK3sKKworICBjYXNlICRhc19kaXIgaW4gIygKKyAgLSop
IGFzX2Rpcj0uLyRhc19kaXI7OworICBlc2FjCisgIHRlc3QgLWQgIiRhc19kaXIiIHx8IGV2YWwg
JGFzX21rZGlyX3AgfHwgeworICAgIGFzX2RpcnM9CisgICAgd2hpbGUgOjsgZG8KKyAgICAgIGNh
c2UgJGFzX2RpciBpbiAjKAorICAgICAgKlwnKikgYXNfcWRpcj1gJGFzX2VjaG8gIiRhc19kaXIi
IHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgIycoCisgICAgICAqKSBhc19xZGlyPSRhc19k
aXI7OworICAgICAgZXNhYworICAgICAgYXNfZGlycz0iJyRhc19xZGlyJyAkYXNfZGlycyIKKyAg
ICAgIGFzX2Rpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19kaXIiIHx8CiskYXNfZXhwciBYIiRhc19k
aXIiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX2RpciIgOiAn
WFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRh
c19kaXIiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYXNfZGly
IiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkgICAgcy8v
XDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8vXDEvCisJ
ICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9
CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4v
OyBxJ2AKKyAgICAgIHRlc3QgLWQgIiRhc19kaXIiICYmIGJyZWFrCisgICAgZG9uZQorICAgIHRl
c3QgLXogIiRhc19kaXJzIiB8fCBldmFsICJta2RpciAkYXNfZGlycyIKKyAgfSB8fCB0ZXN0IC1k
ICIkYXNfZGlyIiB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBkaXJlY3RvcnkgJGFz
X2RpciIKKworCit9ICMgYXNfZm5fbWtkaXJfcAoraWYgbWtkaXIgLXAgLiAyPi9kZXYvbnVsbDsg
dGhlbgorICBhc19ta2Rpcl9wPSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRlc3QgLWQg
Li8tcCAmJiBybWRpciAuLy1wCisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRlc3QgLXgg
LyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxzZQorICBp
ZiBscyAtZEwgLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlvbj1MCisg
IGVsc2UKKyAgICBhc19sc19MX29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAgICBldmFs
IHNoIC1jICdcJycKKyAgICAgIGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQgIiQxLy4i
OworICAgICAgZWxzZQorCWNhc2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwllc2FjOwor
CWNhc2UgYGxzIC1sZCckYXNfbHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGluICMoKAor
CT8/P1tzeF0qKTo7OyopZmFsc2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2ZpCithc19l
eGVjdXRhYmxlX3A9JGFzX3Rlc3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmlu
ZyBvbnRvIGEgdmFsaWQgQ1BQIG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSokYXNfY3Jf
bGV0dGVycyVQJGFzX2NyX0xFVFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisjIFNl
ZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUgbmFtZS4K
K2FzX3RyX3NoPSJldmFsIHNlZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisK
KworZXhlYyA2PiYxCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIwor
IyMgTWFpbiBib2R5IG9mICRDT05GSUdfU1RBVFVTIHNjcmlwdC4gIyMKKyMjIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCitfQVNFT0YKK3Rlc3QgJGFzX3dyaXRlX2ZhaWwg
PSAwICYmIGNobW9kICt4ICRDT05GSUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorCitjYXQg
Pj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIFNhdmUgdGhl
IGxvZyBtZXNzYWdlLCB0byBrZWVwICQwIGFuZCBzbyBvbiBtZWFuaW5nZnVsLCBhbmQgdG8KKyMg
cmVwb3J0IGFjdHVhbCBpbnB1dCB2YWx1ZXMgb2YgQ09ORklHX0ZJTEVTIGV0Yy4gaW5zdGVhZCBv
ZiB0aGVpcgorIyB2YWx1ZXMgYWZ0ZXIgb3B0aW9ucyBoYW5kbGluZy4KK2FjX2xvZz0iCitUaGlz
IGZpbGUgd2FzIGV4dGVuZGVkIGJ5ICRhc19tZSwgd2hpY2ggd2FzCitnZW5lcmF0ZWQgYnkgR05V
IEF1dG9jb25mIDIuNjcuICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICBDT05GSUdf
RklMRVMgICAgPSAkQ09ORklHX0ZJTEVTCisgIENPTkZJR19IRUFERVJTICA9ICRDT05GSUdfSEVB
REVSUworICBDT05GSUdfTElOS1MgICAgPSAkQ09ORklHX0xJTktTCisgIENPTkZJR19DT01NQU5E
UyA9ICRDT05GSUdfQ09NTUFORFMKKyAgJCAkMCAkQAorCitvbiBgKGhvc3RuYW1lIHx8IHVuYW1l
IC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKKyIKKworX0FDRU9GCisKK2Nhc2UgJGFjX2NvbmZp
Z19maWxlcyBpbiAqIgorIiopIHNldCB4ICRhY19jb25maWdfZmlsZXM7IHNoaWZ0OyBhY19jb25m
aWdfZmlsZXM9JCo7OworZXNhYworCitjYXNlICRhY19jb25maWdfaGVhZGVycyBpbiAqIgorIiop
IHNldCB4ICRhY19jb25maWdfaGVhZGVyczsgc2hpZnQ7IGFjX2NvbmZpZ19oZWFkZXJzPSQqOzsK
K2VzYWMKKworCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWls
PTEKKyMgRmlsZXMgdGhhdCBjb25maWcuc3RhdHVzIHdhcyBtYWRlIGZvci4KK2NvbmZpZ19maWxl
cz0iJGFjX2NvbmZpZ19maWxlcyIKK2NvbmZpZ19oZWFkZXJzPSIkYWNfY29uZmlnX2hlYWRlcnMi
CisKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVf
ZmFpbD0xCithY19jc191c2FnZT0iXAorXGAkYXNfbWUnIGluc3RhbnRpYXRlcyBmaWxlcyBhbmQg
b3RoZXIgY29uZmlndXJhdGlvbiBhY3Rpb25zCitmcm9tIHRlbXBsYXRlcyBhY2NvcmRpbmcgdG8g
dGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4gIFVubGVzcyB0aGUgZmlsZXMKK2FuZCBhY3Rpb25z
IGFyZSBzcGVjaWZpZWQgYXMgVEFHcywgYWxsIGFyZSBpbnN0YW50aWF0ZWQgYnkgZGVmYXVsdC4K
KworVXNhZ2U6ICQwIFtPUFRJT05dLi4uIFtUQUddLi4uCisKKyAgLWgsIC0taGVscCAgICAgICBw
cmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtViwgLS12ZXJzaW9uICAgIHByaW50IHZlcnNp
b24gbnVtYmVyIGFuZCBjb25maWd1cmF0aW9uIHNldHRpbmdzLCB0aGVuIGV4aXQKKyAgICAgIC0t
Y29uZmlnICAgICBwcmludCBjb25maWd1cmF0aW9uLCB0aGVuIGV4aXQKKyAgLXEsIC0tcXVpZXQs
IC0tc2lsZW50CisgICAgICAgICAgICAgICAgICAgZG8gbm90IHByaW50IHByb2dyZXNzIG1lc3Nh
Z2VzCisgIC1kLCAtLWRlYnVnICAgICAgZG9uJ3QgcmVtb3ZlIHRlbXBvcmFyeSBmaWxlcworICAg
ICAgLS1yZWNoZWNrICAgIHVwZGF0ZSAkYXNfbWUgYnkgcmVjb25maWd1cmluZyBpbiB0aGUgc2Ft
ZSBjb25kaXRpb25zCisgICAgICAtLWZpbGU9RklMRVs6VEVNUExBVEVdCisgICAgICAgICAgICAg
ICAgICAgaW5zdGFudGlhdGUgdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSBGSUxFCisgICAgICAtLWhl
YWRlcj1GSUxFWzpURU1QTEFURV0KKyAgICAgICAgICAgICAgICAgICBpbnN0YW50aWF0ZSB0aGUg
Y29uZmlndXJhdGlvbiBoZWFkZXIgRklMRQorCitDb25maWd1cmF0aW9uIGZpbGVzOgorJGNvbmZp
Z19maWxlcworCitDb25maWd1cmF0aW9uIGhlYWRlcnM6CiskY29uZmlnX2hlYWRlcnMKKworUmVw
b3J0IGJ1Z3MgdG8gdGhlIHBhY2thZ2UgcHJvdmlkZXIuIgorCitfQUNFT0YKK2NhdCA+PiRDT05G
SUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorYWNfY3NfY29uZmlnPSJgJGFz
X2VjaG8gIiRhY19jb25maWd1cmVfYXJncyIgfCBzZWQgJ3MvXiAvLzsgcy9bXFwiIlxgXCRdL1xc
XFwmL2cnYCIKK2FjX2NzX3ZlcnNpb249IlxcCitjb25maWcuc3RhdHVzCitjb25maWd1cmVkIGJ5
ICQwLCBnZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIuNjcsCisgIHdpdGggb3B0aW9ucyBcXCJc
JGFjX2NzX2NvbmZpZ1xcIgorCitDb3B5cmlnaHQgKEMpIDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uLCBJbmMuCitUaGlzIGNvbmZpZy5zdGF0dXMgc2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7
IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KK2dpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9u
IHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4iCisKK2FjX3B3ZD0nJGFjX3B3ZCcK
K3NyY2Rpcj0nJHNyY2RpcicKK0lOU1RBTEw9JyRJTlNUQUxMJwordGVzdCAtbiAiXCRBV0siIHx8
IEFXSz1hd2sKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNf
d3JpdGVfZmFpbD0xCisjIFRoZSBkZWZhdWx0IGxpc3RzIGFwcGx5IGlmIHRoZSB1c2VyIGRvZXMg
bm90IHNwZWNpZnkgYW55IGZpbGUuCithY19uZWVkX2RlZmF1bHRzPToKK3doaWxlIHRlc3QgJCMg
IT0gMAorZG8KKyAgY2FzZSAkMSBpbgorICAtLSo9PyopCisgICAgYWNfb3B0aW9uPWBleHByICJY
JDEiIDogJ1hcKFtePV0qXCk9J2AKKyAgICBhY19vcHRhcmc9YGV4cHIgIlgkMSIgOiAnWFtePV0q
PVwoLipcKSdgCisgICAgYWNfc2hpZnQ9OgorICAgIDs7CisgIC0tKj0pCisgICAgYWNfb3B0aW9u
PWBleHByICJYJDEiIDogJ1hcKFtePV0qXCk9J2AKKyAgICBhY19vcHRhcmc9CisgICAgYWNfc2hp
ZnQ9OgorICAgIDs7CisgICopCisgICAgYWNfb3B0aW9uPSQxCisgICAgYWNfb3B0YXJnPSQyCisg
ICAgYWNfc2hpZnQ9c2hpZnQKKyAgICA7OworICBlc2FjCisKKyAgY2FzZSAkYWNfb3B0aW9uIGlu
CisgICMgSGFuZGxpbmcgb2YgdGhlIG9wdGlvbnMuCisgIC1yZWNoZWNrIHwgLS1yZWNoZWNrIHwg
LS1yZWNoZWMgfCAtLXJlY2hlIHwgLS1yZWNoIHwgLS1yZWMgfCAtLXJlIHwgLS1yKQorICAgIGFj
X2NzX3JlY2hlY2s9OiA7OworICAtLXZlcnNpb24gfCAtLXZlcnNpbyB8IC0tdmVyc2kgfCAtLXZl
cnMgfCAtLXZlciB8IC0tdmUgfCAtLXYgfCAtViApCisgICAgJGFzX2VjaG8gIiRhY19jc192ZXJz
aW9uIjsgZXhpdCA7OworICAtLWNvbmZpZyB8IC0tY29uZmkgfCAtLWNvbmYgfCAtLWNvbiB8IC0t
Y28gfCAtLWMgKQorICAgICRhc19lY2hvICIkYWNfY3NfY29uZmlnIjsgZXhpdCA7OworICAtLWRl
YnVnIHwgLS1kZWJ1IHwgLS1kZWIgfCAtLWRlIHwgLS1kIHwgLWQgKQorICAgIGRlYnVnPTogOzsK
KyAgLS1maWxlIHwgLS1maWwgfCAtLWZpIHwgLS1mICkKKyAgICAkYWNfc2hpZnQKKyAgICBjYXNl
ICRhY19vcHRhcmcgaW4KKyAgICAqXCcqKSBhY19vcHRhcmc9YCRhc19lY2hvICIkYWNfb3B0YXJn
IiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAgICcnKSBhc19mbl9lcnJvciAkPyAi
bWlzc2luZyBmaWxlIGFyZ3VtZW50IiA7OworICAgIGVzYWMKKyAgICBhc19mbl9hcHBlbmQgQ09O
RklHX0ZJTEVTICIgJyRhY19vcHRhcmcnIgorICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2U7Owor
ICAtLWhlYWRlciB8IC0taGVhZGUgfCAtLWhlYWQgfCAtLWhlYSApCisgICAgJGFjX3NoaWZ0Cisg
ICAgY2FzZSAkYWNfb3B0YXJnIGluCisgICAgKlwnKikgYWNfb3B0YXJnPWAkYXNfZWNobyAiJGFj
X29wdGFyZyIgfCBzZWQgInMvJy8nXFxcXFxcXFwnJy9nImAgOzsKKyAgICBlc2FjCisgICAgYXNf
Zm5fYXBwZW5kIENPTkZJR19IRUFERVJTICIgJyRhY19vcHRhcmcnIgorICAgIGFjX25lZWRfZGVm
YXVsdHM9ZmFsc2U7OworICAtLWhlIHwgLS1oKQorICAgICMgQ29uZmxpY3QgYmV0d2VlbiAtLWhl
bHAgYW5kIC0taGVhZGVyCisgICAgYXNfZm5fZXJyb3IgJD8gImFtYmlndW91cyBvcHRpb246IFxg
JDEnCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uLiI7OworICAtLWhlbHAg
fCAtLWhlbCB8IC1oICkKKyAgICAkYXNfZWNobyAiJGFjX2NzX3VzYWdlIjsgZXhpdCA7OworICAt
cSB8IC1xdWlldCB8IC0tcXVpZXQgfCAtLXF1aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8
IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCB8IC0tc2kgfCAt
LXMpCisgICAgYWNfY3Nfc2lsZW50PTogOzsKKworICAjIFRoaXMgaXMgYW4gZXJyb3IuCisgIC0q
KSBhc19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbjogXGAkMScKK1RyeSBcYCQwIC0t
aGVscCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIiA7OworCisgICopIGFzX2ZuX2FwcGVuZCBhY19j
b25maWdfdGFyZ2V0cyAiICQxIgorICAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlIDs7CisKKyAg
ZXNhYworICBzaGlmdAorZG9uZQorCithY19jb25maWd1cmVfZXh0cmFfYXJncz0KKworaWYgJGFj
X2NzX3NpbGVudDsgdGhlbgorICBleGVjIDY+L2Rldi9udWxsCisgIGFjX2NvbmZpZ3VyZV9leHRy
YV9hcmdzPSIkYWNfY29uZmlndXJlX2V4dHJhX2FyZ3MgLS1zaWxlbnQiCitmaQorCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQoraWYgXCRh
Y19jc19yZWNoZWNrOyB0aGVuCisgIHNldCBYICckU0hFTEwnICckMCcgJGFjX2NvbmZpZ3VyZV9h
cmdzIFwkYWNfY29uZmlndXJlX2V4dHJhX2FyZ3MgLS1uby1jcmVhdGUgLS1uby1yZWN1cnNpb24K
KyAgc2hpZnQKKyAgXCRhc19lY2hvICJydW5uaW5nIENPTkZJR19TSEVMTD0kU0hFTEwgXCQqIiA+
JjYKKyAgQ09ORklHX1NIRUxMPSckU0hFTEwnCisgIGV4cG9ydCBDT05GSUdfU0hFTEwKKyAgZXhl
YyAiXCRAIgorZmkKKworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwg
YWNfd3JpdGVfZmFpbD0xCitleGVjIDU+PmNvbmZpZy5sb2cKK3sKKyAgZWNobworICBzZWQgJ2g7
cy8uLy0vZztzL14uLi4vIyMgLztzLy4uLiQvICMjLztwO3g7cDt4JyA8PF9BU0JPWAorIyMgUnVu
bmluZyAkYXNfbWUuICMjCitfQVNCT1gKKyAgJGFzX2VjaG8gIiRhY19sb2ciCit9ID4mNQorCitf
QUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQor
X0FDRU9GCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWls
PTEKKworIyBIYW5kbGluZyBvZiBhcmd1bWVudHMuCitmb3IgYWNfY29uZmlnX3RhcmdldCBpbiAk
YWNfY29uZmlnX3RhcmdldHMKK2RvCisgIGNhc2UgJGFjX2NvbmZpZ190YXJnZXQgaW4KKyAgICAi
Li4vY29uZmlnL1Rvb2xzLm1rIikgQ09ORklHX0ZJTEVTPSIkQ09ORklHX0ZJTEVTIC4uL2NvbmZp
Zy9Ub29scy5tayIgOzsKKyAgICAiY29uZmlnLmgiKSBDT05GSUdfSEVBREVSUz0iJENPTkZJR19I
RUFERVJTIGNvbmZpZy5oIiA7OworCisgICopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGFyZ3Vt
ZW50OiBcYCRhY19jb25maWdfdGFyZ2V0JyIgIiRMSU5FTk8iIDUgOzsKKyAgZXNhYworZG9uZQor
CisKKyMgSWYgdGhlIHVzZXIgZGlkIG5vdCB1c2UgdGhlIGFyZ3VtZW50cyB0byBzcGVjaWZ5IHRo
ZSBpdGVtcyB0byBpbnN0YW50aWF0ZSwKKyMgdGhlbiB0aGUgZW52dmFyIGludGVyZmFjZSBpcyB1
c2VkLiAgU2V0IG9ubHkgdGhvc2UgdGhhdCBhcmUgbm90LgorIyBXZSB1c2UgdGhlIGxvbmcgZm9y
bSBmb3IgdGhlIGRlZmF1bHQgYXNzaWdubWVudCBiZWNhdXNlIG9mIGFuIGV4dHJlbWVseQorIyBi
aXphcnJlIGJ1ZyBvbiBTdW5PUyA0LjEuMy4KK2lmICRhY19uZWVkX2RlZmF1bHRzOyB0aGVuCisg
IHRlc3QgIiR7Q09ORklHX0ZJTEVTK3NldH0iID0gc2V0IHx8IENPTkZJR19GSUxFUz0kY29uZmln
X2ZpbGVzCisgIHRlc3QgIiR7Q09ORklHX0hFQURFUlMrc2V0fSIgPSBzZXQgfHwgQ09ORklHX0hF
QURFUlM9JGNvbmZpZ19oZWFkZXJzCitmaQorCisjIEhhdmUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5
IGZvciBjb252ZW5pZW5jZS4gIE1ha2UgaXQgaW4gdGhlIGJ1aWxkIHRyZWUKKyMgc2ltcGx5IGJl
Y2F1c2UgdGhlcmUgaXMgbm8gcmVhc29uIGFnYWluc3QgaGF2aW5nIGl0IGhlcmUsIGFuZCBpbiBh
ZGRpdGlvbiwKKyMgY3JlYXRpbmcgYW5kIG1vdmluZyBmaWxlcyBmcm9tIC90bXAgY2FuIHNvbWV0
aW1lcyBjYXVzZSBwcm9ibGVtcy4KKyMgSG9vayBmb3IgaXRzIHJlbW92YWwgdW5sZXNzIGRlYnVn
Z2luZy4KKyMgTm90ZSB0aGF0IHRoZXJlIGlzIGEgc21hbGwgd2luZG93IGluIHdoaWNoIHRoZSBk
aXJlY3Rvcnkgd2lsbCBub3QgYmUgY2xlYW5lZDoKKyMgYWZ0ZXIgaXRzIGNyZWF0aW9uIGJ1dCBi
ZWZvcmUgaXRzIG5hbWUgaGFzIGJlZW4gYXNzaWduZWQgdG8gYCR0bXAnLgorJGRlYnVnIHx8Cit7
CisgIHRtcD0KKyAgdHJhcCAnZXhpdF9zdGF0dXM9JD8KKyAgeyB0ZXN0IC16ICIkdG1wIiB8fCB0
ZXN0ICEgLWQgIiR0bXAiIHx8IHJtIC1mciAiJHRtcCI7IH0gJiYgZXhpdCAkZXhpdF9zdGF0dXMK
KycgMAorICB0cmFwICdhc19mbl9leGl0IDEnIDEgMiAxMyAxNQorfQorIyBDcmVhdGUgYSAoc2Vj
dXJlKSB0bXAgZGlyZWN0b3J5IGZvciB0bXAgZmlsZXMuCisKK3sKKyAgdG1wPWAodW1hc2sgMDc3
ICYmIG1rdGVtcCAtZCAiLi9jb25mWFhYWFhYIikgMj4vZGV2L251bGxgICYmCisgIHRlc3QgLW4g
IiR0bXAiICYmIHRlc3QgLWQgIiR0bXAiCit9ICB8fAoreworICB0bXA9Li9jb25mJCQtJFJBTkRP
TQorICAodW1hc2sgMDc3ICYmIG1rZGlyICIkdG1wIikKK30gfHwgYXNfZm5fZXJyb3IgJD8gImNh
bm5vdCBjcmVhdGUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGluIC4iICIkTElORU5PIiA1CisKKyMg
U2V0IHVwIHRoZSBzY3JpcHRzIGZvciBDT05GSUdfRklMRVMgc2VjdGlvbi4KKyMgTm8gbmVlZCB0
byBnZW5lcmF0ZSB0aGVtIGlmIHRoZXJlIGFyZSBubyBDT05GSUdfRklMRVMuCisjIFRoaXMgaGFw
cGVucyBmb3IgaW5zdGFuY2Ugd2l0aCBgLi9jb25maWcuc3RhdHVzIGNvbmZpZy5oJy4KK2lmIHRl
c3QgLW4gIiRDT05GSUdfRklMRVMiOyB0aGVuCisKKworYWNfY3I9YGVjaG8gWCB8IHRyIFggJ1ww
MTUnYAorIyBPbiBjeWd3aW4sIGJhc2ggY2FuIGVhdCBcciBpbnNpZGUgYGAgaWYgdGhlIHVzZXIg
cmVxdWVzdGVkIGlnbmNyLgorIyBCdXQgd2Uga25vdyBvZiBubyBvdGhlciBzaGVsbCB3aGVyZSBh
Y19jciB3b3VsZCBiZSBlbXB0eSBhdCB0aGlzCisjIHBvaW50LCBzbyB3ZSBjYW4gdXNlIGEgYmFz
aGlzbSBhcyBhIGZhbGxiYWNrLgoraWYgdGVzdCAieCRhY19jciIgPSB4OyB0aGVuCisgIGV2YWwg
YWNfY3I9XCRcJ1xcclwnCitmaQorYWNfY3NfYXdrX2NyPWAkQVdLICdCRUdJTiB7IHByaW50ICJh
XHJiIiB9JyA8L2Rldi9udWxsIDI+L2Rldi9udWxsYAoraWYgdGVzdCAiJGFjX2NzX2F3a19jciIg
PSAiYSR7YWNfY3J9YiI7IHRoZW4KKyAgYWNfY3NfYXdrX2NyPSdcXHInCitlbHNlCisgIGFjX2Nz
X2F3a19jcj0kYWNfY3IKK2ZpCisKK2VjaG8gJ0JFR0lOIHsnID4iJHRtcC9zdWJzMS5hd2siICYm
CitfQUNFT0YKKworCit7CisgIGVjaG8gImNhdCA+Y29uZiQkc3Vicy5hd2sgPDxfQUNFT0YiICYm
CisgIGVjaG8gIiRhY19zdWJzdF92YXJzIiB8IHNlZCAncy8uKi8mISQmJGFjX2RlbGltLycgJiYK
KyAgZWNobyAiX0FDRU9GIgorfSA+Y29uZiQkc3Vicy5zaCB8fAorICBhc19mbl9lcnJvciAkPyAi
Y291bGQgbm90IG1ha2UgJENPTkZJR19TVEFUVVMiICIkTElORU5PIiA1CithY19kZWxpbV9udW09
YGVjaG8gIiRhY19zdWJzdF92YXJzIiB8IGdyZXAgLWMgJ14nYAorYWNfZGVsaW09JyUhXyEjICcK
K2ZvciBhY19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSA6OyBkbwor
ICAuIC4vY29uZiQkc3Vicy5zaCB8fAorICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFr
ZSAkQ09ORklHX1NUQVRVUyIgIiRMSU5FTk8iIDUKKworICBhY19kZWxpbV9uPWBzZWQgLW4gInMv
LiokYWNfZGVsaW1cJC9YL3AiIGNvbmYkJHN1YnMuYXdrIHwgZ3JlcCAtYyBYYAorICBpZiB0ZXN0
ICRhY19kZWxpbV9uID0gJGFjX2RlbGltX251bTsgdGhlbgorICAgIGJyZWFrCisgIGVsaWYgJGFj
X2xhc3RfdHJ5OyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05G
SUdfU1RBVFVTIiAiJExJTkVOTyIgNQorICBlbHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEk
YWNfZGVsaW0gXyRhY19kZWxpbSEhICIKKyAgZmkKK2RvbmUKK3JtIC1mIGNvbmYkJHN1YnMuc2gK
KworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitjYXQg
Pj4iXCR0bXAvc3ViczEuYXdrIiA8PFxcX0FDQVdLICYmCitfQUNFT0YKK3NlZCAtbiAnCitoCitz
L14vU1siLzsgcy8hLiovIl09LworcAorZworcy9eW14hXSohLy8KKzpyZXBsCit0IHJlcGwKK3Mv
JyIkYWNfZGVsaW0iJyQvLwordCBkZWxpbQorOm5sCitoCitzL1woLlx7MTQ4XH1cKS4uKi9cMS8K
K3QgbW9yZTEKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kL1xcbiJcXC8KK3AKK24KK2IgcmVw
bAorOm1vcmUxCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0
OFx9Ly8KK3QgbmwKKzpkZWxpbQoraAorcy9cKC5cezE0OFx9XCkuLiovXDEvCit0IG1vcmUyCitz
L1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iLworcAorYgorOm1vcmUyCitzL1siXFxdL1xcJi9n
OyBzL14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0OFx9Ly8KK3QgZGVsaW0KKycgPGNvbmYk
JHN1YnMuYXdrIHwgc2VkICcKKy9eW14iIl0veworICBOCisgIHMvXG4vLworfQorJyA+PiRDT05G
SUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorcm0gLWYgY29uZiQkc3Vicy5hd2sKK2NhdCA+
PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorX0FDQVdLCitjYXQg
Pj4iXCR0bXAvc3ViczEuYXdrIiA8PF9BQ0FXSyAmJgorICBmb3IgKGtleSBpbiBTKSBTX2lzX3Nl
dFtrZXldID0gMQorICBGUyA9ICIHIgorCit9Cit7CisgIGxpbmUgPSAkIDAKKyAgbmZpZWxkcyA9
IHNwbGl0KGxpbmUsIGZpZWxkLCAiQCIpCisgIHN1YnN0ZWQgPSAwCisgIGxlbiA9IGxlbmd0aChm
aWVsZFsxXSkKKyAgZm9yIChpID0gMjsgaSA8IG5maWVsZHM7IGkrKykgeworICAgIGtleSA9IGZp
ZWxkW2ldCisgICAga2V5bGVuID0gbGVuZ3RoKGtleSkKKyAgICBpZiAoU19pc19zZXRba2V5XSkg
eworICAgICAgdmFsdWUgPSBTW2tleV0KKyAgICAgIGxpbmUgPSBzdWJzdHIobGluZSwgMSwgbGVu
KSAiIiB2YWx1ZSAiIiBzdWJzdHIobGluZSwgbGVuICsga2V5bGVuICsgMykKKyAgICAgIGxlbiAr
PSBsZW5ndGgodmFsdWUpICsgbGVuZ3RoKGZpZWxkWysraV0pCisgICAgICBzdWJzdGVkID0gMQor
ICAgIH0gZWxzZQorICAgICAgbGVuICs9IDEgKyBrZXlsZW4KKyAgfQorCisgIHByaW50IGxpbmUK
K30KKworX0FDQVdLCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBh
Y193cml0ZV9mYWlsPTEKK2lmIHNlZCAicy8kYWNfY3IvLyIgPCAvZGV2L251bGwgPiAvZGV2L251
bGwgMj4mMTsgdGhlbgorICBzZWQgInMvJGFjX2NyXCQvLzsgcy8kYWNfY3IvJGFjX2NzX2F3a19j
ci9nIgorZWxzZQorICBjYXQKK2ZpIDwgIiR0bXAvc3ViczEuYXdrIiA+ICIkdG1wL3N1YnMuYXdr
IiBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGZpbGVzIG1h
Y2hpbmVyeSIgIiRMSU5FTk8iIDUKK19BQ0VPRgorCisjIFZQQVRIIG1heSBjYXVzZSB0cm91Ymxl
IHdpdGggc29tZSBtYWtlcywgc28gd2UgcmVtb3ZlIHNvbGUgJChzcmNkaXIpLAorIyAke3NyY2Rp
cn0gYW5kIEBzcmNkaXJAIGVudHJpZXMgZnJvbSBWUEFUSCBpZiBzcmNkaXIgaXMgIi4iLCBzdHJp
cCBsZWFkaW5nIGFuZAorIyB0cmFpbGluZyBjb2xvbnMgYW5kIHRoZW4gcmVtb3ZlIHRoZSB3aG9s
ZSBsaW5lIGlmIFZQQVRIIGJlY29tZXMgZW1wdHkKKyMgKGFjdHVhbGx5IHdlIGxlYXZlIGFuIGVt
cHR5IGxpbmUgdG8gcHJlc2VydmUgbGluZSBudW1iZXJzKS4KK2lmIHRlc3QgIngkc3JjZGlyIiA9
IHguOyB0aGVuCisgIGFjX3Zwc3ViPScvXlsJIF0qVlBBVEhbCSBdKj1bCSBdKi97CitoCitzLy8v
CitzL14vOi8KK3MvWwkgXSokLzovCitzLzpcJChzcmNkaXIpOi86L2cKK3MvOlwke3NyY2Rpcn06
LzovZworcy86QHNyY2RpckA6LzovZworcy9eOiovLworcy86KiQvLworeAorcy9cKD1bCSBdKlwp
LiovXDEvCitHCitzL1xuLy8KK3MvXltePV0qPVsJIF0qJC8vCit9JworZmkKKworY2F0ID4+JENP
TkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorZmkgIyB0ZXN0IC1uICIk
Q09ORklHX0ZJTEVTIgorCisjIFNldCB1cCB0aGUgc2NyaXB0cyBmb3IgQ09ORklHX0hFQURFUlMg
c2VjdGlvbi4KKyMgTm8gbmVlZCB0byBnZW5lcmF0ZSB0aGVtIGlmIHRoZXJlIGFyZSBubyBDT05G
SUdfSEVBREVSUy4KKyMgVGhpcyBoYXBwZW5zIGZvciBpbnN0YW5jZSB3aXRoIGAuL2NvbmZpZy5z
dGF0dXMgTWFrZWZpbGUnLgoraWYgdGVzdCAtbiAiJENPTkZJR19IRUFERVJTIjsgdGhlbgorY2F0
ID4iJHRtcC9kZWZpbmVzLmF3ayIgPDxcX0FDQVdLIHx8CitCRUdJTiB7CitfQUNFT0YKKworIyBU
cmFuc2Zvcm0gY29uZmRlZnMuaCBpbnRvIGFuIGF3ayBzY3JpcHQgYGRlZmluZXMuYXdrJywgZW1i
ZWRkZWQgYXMKKyMgaGVyZS1kb2N1bWVudCBpbiBjb25maWcuc3RhdHVzLCB0aGF0IHN1YnN0aXR1
dGVzIHRoZSBwcm9wZXIgdmFsdWVzIGludG8KKyMgY29uZmlnLmguaW4gdG8gcHJvZHVjZSBjb25m
aWcuaC4KKworIyBDcmVhdGUgYSBkZWxpbWl0ZXIgc3RyaW5nIHRoYXQgZG9lcyBub3QgZXhpc3Qg
aW4gY29uZmRlZnMuaCwgdG8gZWFzZQorIyBoYW5kbGluZyBvZiBsb25nIGxpbmVzLgorYWNfZGVs
aW09JyUhXyEjICcKK2ZvciBhY19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSA6OyBkbworICBhY190
PWBzZWQgLW4gIi8kYWNfZGVsaW0vcCIgY29uZmRlZnMuaGAKKyAgaWYgdGVzdCAteiAiJGFjX3Qi
OyB0aGVuCisgICAgYnJlYWsKKyAgZWxpZiAkYWNfbGFzdF90cnk7IHRoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAiY291bGQgbm90IG1ha2UgJENPTkZJR19IRUFERVJTIiAiJExJTkVOTyIgNQorICBl
bHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEkYWNfZGVsaW0gXyRhY19kZWxpbSEhICIKKyAg
ZmkKK2RvbmUKKworIyBGb3IgdGhlIGF3ayBzY3JpcHQsIEQgaXMgYW4gYXJyYXkgb2YgbWFjcm8g
dmFsdWVzIGtleWVkIGJ5IG5hbWUsCisjIGxpa2V3aXNlIFAgY29udGFpbnMgbWFjcm8gcGFyYW1l
dGVycyBpZiBhbnkuICBQcmVzZXJ2ZSBiYWNrc2xhc2gKKyMgbmV3bGluZSBzZXF1ZW5jZXMuCisK
K2FjX3dvcmRfcmU9W18kYXNfY3JfTGV0dGVyc11bXyRhc19jcl9hbG51bV0qCitzZWQgLW4gJwor
cy8uXHsxNDhcfS8mJyIkYWNfZGVsaW0iJy9nCit0IHJzZXQKKzpyc2V0CitzL15bCSBdKiNbCSBd
KmRlZmluZVsJIF1bCSBdKi8gLwordCBkZWYKK2QKKzpkZWYKK3MvXFwkLy8KK3QgYnNubAorcy9b
IlxcXS9cXCYvZworcy9eIFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSopXClbCSBdKlwoLipc
KS9QWyJcMSJdPSJcMiJcCitEWyJcMSJdPSIgXDMiL3AKK3MvXiBcKCciJGFjX3dvcmRfcmUiJ1wp
WwkgXSpcKC4qXCkvRFsiXDEiXT0iIFwyIi9wCitkCis6YnNubAorcy9bIlxcXS9cXCYvZworcy9e
IFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSopXClbCSBdKlwoLipcKS9QWyJcMSJdPSJcMiJc
CitEWyJcMSJdPSIgXDNcXFxcXFxuIlxcL3AKK3QgY29udAorcy9eIFwoJyIkYWNfd29yZF9yZSIn
XClbCSBdKlwoLipcKS9EWyJcMSJdPSIgXDJcXFxcXFxuIlxcL3AKK3QgY29udAorZAorOmNvbnQK
K24KK3MvLlx7MTQ4XH0vJiciJGFjX2RlbGltIicvZwordCBjbGVhcgorOmNsZWFyCitzL1xcJC8v
Cit0IGJzbmxjCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iL3AKK2QKKzpic25sYworcy9b
IlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvXFxcXFxcbiJcXC9wCitiIGNvbnQKKycgPGNvbmZkZWZz
LmggfCBzZWQgJworcy8nIiRhY19kZWxpbSInLyJcXFwKKyIvZycgPj4kQ09ORklHX1NUQVRVUyB8
fCBhY193cml0ZV9mYWlsPTEKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNf
d3JpdGVfZmFpbD0xCisgIGZvciAoa2V5IGluIEQpIERfaXNfc2V0W2tleV0gPSAxCisgIEZTID0g
IgciCit9CisvXltcdCBdKiNbXHQgXSooZGVmaW5lfHVuZGVmKVtcdCBdKyRhY193b3JkX3JlKFtc
dCAoXXxcJCkvIHsKKyAgbGluZSA9IFwkIDAKKyAgc3BsaXQobGluZSwgYXJnLCAiICIpCisgIGlm
IChhcmdbMV0gPT0gIiMiKSB7CisgICAgZGVmdW5kZWYgPSBhcmdbMl0KKyAgICBtYWMxID0gYXJn
WzNdCisgIH0gZWxzZSB7CisgICAgZGVmdW5kZWYgPSBzdWJzdHIoYXJnWzFdLCAyKQorICAgIG1h
YzEgPSBhcmdbMl0KKyAgfQorICBzcGxpdChtYWMxLCBtYWMyLCAiKCIpICMpCisgIG1hY3JvID0g
bWFjMlsxXQorICBwcmVmaXggPSBzdWJzdHIobGluZSwgMSwgaW5kZXgobGluZSwgZGVmdW5kZWYp
IC0gMSkKKyAgaWYgKERfaXNfc2V0W21hY3JvXSkgeworICAgICMgUHJlc2VydmUgdGhlIHdoaXRl
IHNwYWNlIHN1cnJvdW5kaW5nIHRoZSAiIyIuCisgICAgcHJpbnQgcHJlZml4ICJkZWZpbmUiLCBt
YWNybyBQW21hY3JvXSBEW21hY3JvXQorICAgIG5leHQKKyAgfSBlbHNlIHsKKyAgICAjIFJlcGxh
Y2UgI3VuZGVmIHdpdGggY29tbWVudHMuICBUaGlzIGlzIG5lY2Vzc2FyeSwgZm9yIGV4YW1wbGUs
CisgICAgIyBpbiB0aGUgY2FzZSBvZiBfUE9TSVhfU09VUkNFLCB3aGljaCBpcyBwcmVkZWZpbmVk
IGFuZCByZXF1aXJlZAorICAgICMgb24gc29tZSBzeXN0ZW1zIHdoZXJlIGNvbmZpZ3VyZSB3aWxs
IG5vdCBkZWNpZGUgdG8gZGVmaW5lIGl0LgorICAgIGlmIChkZWZ1bmRlZiA9PSAidW5kZWYiKSB7
CisgICAgICBwcmludCAiLyoiLCBwcmVmaXggZGVmdW5kZWYsIG1hY3JvLCAiKi8iCisgICAgICBu
ZXh0CisgICAgfQorICB9Cit9Cit7IHByaW50IH0KK19BQ0FXSworX0FDRU9GCitjYXQgPj4kQ09O
RklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGFzX2ZuX2Vycm9yICQ/
ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGhlYWRlcnMgbWFjaGluZXJ5IiAiJExJTkVOTyIgNQor
ZmkgIyB0ZXN0IC1uICIkQ09ORklHX0hFQURFUlMiCisKKworZXZhbCBzZXQgWCAiICA6RiAkQ09O
RklHX0ZJTEVTICA6SCAkQ09ORklHX0hFQURFUlMgICAgIgorc2hpZnQKK2ZvciBhY190YWcKK2Rv
CisgIGNhc2UgJGFjX3RhZyBpbgorICA6W0ZITENdKSBhY19tb2RlPSRhY190YWc7IGNvbnRpbnVl
OzsKKyAgZXNhYworICBjYXNlICRhY19tb2RlJGFjX3RhZyBpbgorICA6W0ZITF0qOiopOzsKKyAg
OkwqIHwgOkMqOiopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHRhZyBcYCRhY190YWcnIiAiJExJ
TkVOTyIgNSA7OworICA6W0ZIXS0pIGFjX3RhZz0tOi07OworICA6W0ZIXSopIGFjX3RhZz0kYWNf
dGFnOiRhY190YWcuaW47OworICBlc2FjCisgIGFjX3NhdmVfSUZTPSRJRlMKKyAgSUZTPToKKyAg
c2V0IHggJGFjX3RhZworICBJRlM9JGFjX3NhdmVfSUZTCisgIHNoaWZ0CisgIGFjX2ZpbGU9JDEK
KyAgc2hpZnQKKworICBjYXNlICRhY19tb2RlIGluCisgIDpMKSBhY19zb3VyY2U9JDE7OworICA6
W0ZIXSkKKyAgICBhY19maWxlX2lucHV0cz0KKyAgICBmb3IgYWNfZgorICAgIGRvCisgICAgICBj
YXNlICRhY19mIGluCisgICAgICAtKSBhY19mPSIkdG1wL3N0ZGluIjs7CisgICAgICAqKSAjIExv
b2sgZm9yIHRoZSBmaWxlIGZpcnN0IGluIHRoZSBidWlsZCB0cmVlLCB0aGVuIGluIHRoZSBzb3Vy
Y2UgdHJlZQorCSAjIChpZiB0aGUgcGF0aCBpcyBub3QgYWJzb2x1dGUpLiAgVGhlIGFic29sdXRl
IHBhdGggY2Fubm90IGJlIERPUy1zdHlsZSwKKwkgIyBiZWNhdXNlICRhY19mIGNhbm5vdCBjb250
YWluIGA6Jy4KKwkgdGVzdCAtZiAiJGFjX2YiIHx8CisJICAgY2FzZSAkYWNfZiBpbgorCSAgIFtc
XC8kXSopIGZhbHNlOzsKKwkgICAqKSB0ZXN0IC1mICIkc3JjZGlyLyRhY19mIiAmJiBhY19mPSIk
c3JjZGlyLyRhY19mIjs7CisJICAgZXNhYyB8fAorCSAgIGFzX2ZuX2Vycm9yIDEgImNhbm5vdCBm
aW5kIGlucHV0IGZpbGU6IFxgJGFjX2YnIiAiJExJTkVOTyIgNSA7OworICAgICAgZXNhYworICAg
ICAgY2FzZSAkYWNfZiBpbiAqXCcqKSBhY19mPWAkYXNfZWNobyAiJGFjX2YiIHwgc2VkICJzLycv
J1xcXFxcXFxcJycvZyJgOzsgZXNhYworICAgICAgYXNfZm5fYXBwZW5kIGFjX2ZpbGVfaW5wdXRz
ICIgJyRhY19mJyIKKyAgICBkb25lCisKKyAgICAjIExldCdzIHN0aWxsIHByZXRlbmQgaXQgaXMg
YGNvbmZpZ3VyZScgd2hpY2ggaW5zdGFudGlhdGVzIChpLmUuLCBkb24ndAorICAgICMgdXNlICRh
c19tZSksIHBlb3BsZSB3b3VsZCBiZSBzdXJwcmlzZWQgdG8gcmVhZDoKKyAgICAjICAgIC8qIGNv
bmZpZy5oLiAgR2VuZXJhdGVkIGJ5IGNvbmZpZy5zdGF0dXMuICAqLworICAgIGNvbmZpZ3VyZV9p
bnB1dD0nR2VuZXJhdGVkIGZyb20gJ2AKKwkgICRhc19lY2hvICIkKiIgfCBzZWQgJ3N8XlteOl0q
L3x8O3N8OlteOl0qL3wsIHxnJworCWAnIGJ5IGNvbmZpZ3VyZS4nCisgICAgaWYgdGVzdCB4IiRh
Y19maWxlIiAhPSB4LTsgdGhlbgorICAgICAgY29uZmlndXJlX2lucHV0PSIkYWNfZmlsZS4gICRj
b25maWd1cmVfaW5wdXQiCisgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNyZWF0aW5nICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGNyZWF0aW5n
ICRhY19maWxlIiA+JjY7fQorICAgIGZpCisgICAgIyBOZXV0cmFsaXplIHNwZWNpYWwgY2hhcmFj
dGVycyBpbnRlcnByZXRlZCBieSBzZWQgaW4gcmVwbGFjZW1lbnQgc3RyaW5ncy4KKyAgICBjYXNl
ICRjb25maWd1cmVfaW5wdXQgaW4gIygKKyAgICAqXCYqIHwgKlx8KiB8ICpcXCogKQorICAgICAg
IGFjX3NlZF9jb25mX2lucHV0PWAkYXNfZWNobyAiJGNvbmZpZ3VyZV9pbnB1dCIgfAorICAgICAg
IHNlZCAncy9bXFxcXCZ8XS9cXFxcJi9nJ2A7OyAjKAorICAgICopIGFjX3NlZF9jb25mX2lucHV0
PSRjb25maWd1cmVfaW5wdXQ7OworICAgIGVzYWMKKworICAgIGNhc2UgJGFjX3RhZyBpbgorICAg
ICo6LToqIHwgKjotKSBjYXQgPiIkdG1wL3N0ZGluIiBcCisgICAgICB8fCBhc19mbl9lcnJvciAk
PyAiY291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUgIDs7CisgICAgZXNhYwor
ICAgIDs7CisgIGVzYWMKKworICBhY19kaXI9YCRhc19kaXJuYW1lIC0tICIkYWNfZmlsZSIgfHwK
KyRhc19leHByIFgiJGFjX2ZpbGUiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBc
CisJIFgiJGFjX2ZpbGUiIDogJ1hcKC8vXClbXi9dJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hc
KC8vXCkkJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8
fAorJGFzX2VjaG8gWCIkYWNfZmlsZSIgfAorICAgIHNlZCAnL15YXCguKlteL11cKVwvXC8qW14v
XVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKVte
L10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKSQveworCSAg
ICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wpLioveworCSAgICBzLy9cMS8KKwkg
ICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgIGFzX2Rpcj0iJGFjX2RpciI7IGFzX2ZuX21r
ZGlyX3AKKyAgYWNfYnVpbGRkaXI9LgorCitjYXNlICIkYWNfZGlyIiBpbgorLikgYWNfZGlyX3N1
ZmZpeD0gYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7CisqKQor
ICBhY19kaXJfc3VmZml4PS9gJGFzX2VjaG8gIiRhY19kaXIiIHwgc2VkICdzfF5cLltcXC9dfHwn
YAorICAjIEEgIi4uIiBmb3IgZWFjaCBkaXJlY3RvcnkgaW4gJGFjX2Rpcl9zdWZmaXguCisgIGFj
X3RvcF9idWlsZGRpcl9zdWI9YCRhc19lY2hvICIkYWNfZGlyX3N1ZmZpeCIgfCBzZWQgJ3N8L1te
XFwvXSp8Ly4ufGc7c3wvfHwnYAorICBjYXNlICRhY190b3BfYnVpbGRkaXJfc3ViIGluCisgICIi
KSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZpeD0gOzsKKyAgKikgIGFj
X3RvcF9idWlsZF9wcmVmaXg9JGFjX3RvcF9idWlsZGRpcl9zdWIvIDs7CisgIGVzYWMgOzsKK2Vz
YWMKK2FjX2Fic190b3BfYnVpbGRkaXI9JGFjX3B3ZAorYWNfYWJzX2J1aWxkZGlyPSRhY19wd2Qk
YWNfZGlyX3N1ZmZpeAorIyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eToKK2FjX3RvcF9idWls
ZGRpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeAorCitjYXNlICRzcmNkaXIgaW4KKyAgLikgICMgV2Ug
YXJlIGJ1aWxkaW5nIGluIHBsYWNlLgorICAgIGFjX3NyY2Rpcj0uCisgICAgYWNfdG9wX3NyY2Rp
cj0kYWNfdG9wX2J1aWxkZGlyX3N1YgorICAgIGFjX2Fic190b3Bfc3JjZGlyPSRhY19wd2QgOzsK
KyAgW1xcL10qIHwgPzpbXFwvXSogKSAgIyBBYnNvbHV0ZSBuYW1lLgorICAgIGFjX3NyY2Rpcj0k
c3JjZGlyJGFjX2Rpcl9zdWZmaXg7CisgICAgYWNfdG9wX3NyY2Rpcj0kc3JjZGlyCisgICAgYWNf
YWJzX3RvcF9zcmNkaXI9JHNyY2RpciA7OworICAqKSAjIFJlbGF0aXZlIG5hbWUuCisgICAgYWNf
c3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpciRhY19kaXJfc3VmZml4CisgICAgYWNf
dG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIKKyAgICBhY19hYnNfdG9wX3Ny
Y2Rpcj0kYWNfcHdkLyRzcmNkaXIgOzsKK2VzYWMKK2FjX2Fic19zcmNkaXI9JGFjX2Fic190b3Bf
c3JjZGlyJGFjX2Rpcl9zdWZmaXgKKworCisgIGNhc2UgJGFjX21vZGUgaW4KKyAgOkYpCisgICMK
KyAgIyBDT05GSUdfRklMRQorICAjCisKKyAgY2FzZSAkSU5TVEFMTCBpbgorICBbXFwvJF0qIHwg
PzpbXFwvXSogKSBhY19JTlNUQUxMPSRJTlNUQUxMIDs7CisgICopIGFjX0lOU1RBTEw9JGFjX3Rv
cF9idWlsZF9wcmVmaXgkSU5TVEFMTCA7OworICBlc2FjCitfQUNFT0YKKworY2F0ID4+JENPTkZJ
R19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBJZiB0aGUgdGVtcGxhdGUg
ZG9lcyBub3Qga25vdyBhYm91dCBkYXRhcm9vdGRpciwgZXhwYW5kIGl0LgorIyBGSVhNRTogVGhp
cyBoYWNrIHNob3VsZCBiZSByZW1vdmVkIGEgZmV3IHllYXJzIGFmdGVyIDIuNjAuCithY19kYXRh
cm9vdGRpcl9oYWNrPTsgYWNfZGF0YXJvb3RkaXJfc2Vlbj0KK2FjX3NlZF9kYXRhcm9vdD0nCisv
ZGF0YXJvb3RkaXIvIHsKKyAgcAorICBxCit9CisvQGRhdGFkaXJAL3AKKy9AZG9jZGlyQC9wCisv
QGluZm9kaXJAL3AKKy9AbG9jYWxlZGlyQC9wCisvQG1hbmRpckAvcCcKK2Nhc2UgYGV2YWwgInNl
ZCAtbiBcIlwkYWNfc2VkX2RhdGFyb290XCIgJGFjX2ZpbGVfaW5wdXRzImAgaW4KKypkYXRhcm9v
dGRpciopIGFjX2RhdGFyb290ZGlyX3NlZW49eWVzOzsKKypAZGF0YWRpckAqfCpAZG9jZGlyQCp8
KkBpbmZvZGlyQCp8KkBsb2NhbGVkaXJAKnwqQG1hbmRpckAqKQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICRhY19maWxlX2lucHV0cyBzZWVtcyB0
byBpZ25vcmUgdGhlIC0tZGF0YXJvb3RkaXIgc2V0dGluZyIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiAkYWNfZmlsZV9pbnB1dHMgc2VlbXMgdG8gaWdub3JlIHRoZSAtLWRhdGFyb290
ZGlyIHNldHRpbmciID4mMjt9CitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9G
IHx8IGFjX3dyaXRlX2ZhaWw9MQorICBhY19kYXRhcm9vdGRpcl9oYWNrPScKKyAgcyZAZGF0YWRp
ckAmJGRhdGFkaXImZworICBzJkBkb2NkaXJAJiRkb2NkaXImZworICBzJkBpbmZvZGlyQCYkaW5m
b2RpciZnCisgIHMmQGxvY2FsZWRpckAmJGxvY2FsZWRpciZnCisgIHMmQG1hbmRpckAmJG1hbmRp
ciZnCisgIHMmXFxcJHtkYXRhcm9vdGRpcn0mJGRhdGFyb290ZGlyJmcnIDs7Citlc2FjCitfQUNF
T0YKKworIyBOZXV0cmFsaXplIFZQQVRIIHdoZW4gYCRzcmNkaXInID0gYC4nLgorIyBTaGVsbCBj
b2RlIGluIGNvbmZpZ3VyZS5hYyBtaWdodCBzZXQgZXh0cmFzdWIuCisjIEZJWE1FOiBkbyB3ZSBy
ZWFsbHkgd2FudCB0byBtYWludGFpbiB0aGlzIGZlYXR1cmU/CitjYXQgPj4kQ09ORklHX1NUQVRV
UyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2FjX3NlZF9leHRyYT0iJGFjX3Zwc3ViCisk
ZXh0cmFzdWIKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dy
aXRlX2ZhaWw9MQorOnQKKy9AW2EtekEtWl9dW2EtekEtWl8wLTldKkAvIWIKK3N8QGNvbmZpZ3Vy
ZV9pbnB1dEB8JGFjX3NlZF9jb25mX2lucHV0fDt0IHQKK3MmQHRvcF9idWlsZGRpckAmJGFjX3Rv
cF9idWlsZGRpcl9zdWImO3QgdAorcyZAdG9wX2J1aWxkX3ByZWZpeEAmJGFjX3RvcF9idWlsZF9w
cmVmaXgmO3QgdAorcyZAc3JjZGlyQCYkYWNfc3JjZGlyJjt0IHQKK3MmQGFic19zcmNkaXJAJiRh
Y19hYnNfc3JjZGlyJjt0IHQKK3MmQHRvcF9zcmNkaXJAJiRhY190b3Bfc3JjZGlyJjt0IHQKK3Mm
QGFic190b3Bfc3JjZGlyQCYkYWNfYWJzX3RvcF9zcmNkaXImO3QgdAorcyZAYnVpbGRkaXJAJiRh
Y19idWlsZGRpciY7dCB0CitzJkBhYnNfYnVpbGRkaXJAJiRhY19hYnNfYnVpbGRkaXImO3QgdAor
cyZAYWJzX3RvcF9idWlsZGRpckAmJGFjX2Fic190b3BfYnVpbGRkaXImO3QgdAorcyZASU5TVEFM
TEAmJGFjX0lOU1RBTEwmO3QgdAorJGFjX2RhdGFyb290ZGlyX2hhY2sKKyIKK2V2YWwgc2VkIFwi
XCRhY19zZWRfZXh0cmFcIiAiJGFjX2ZpbGVfaW5wdXRzIiB8ICRBV0sgLWYgIiR0bXAvc3Vicy5h
d2siID4kdG1wL291dCBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3JlYXRlICRh
Y19maWxlIiAiJExJTkVOTyIgNQorCit0ZXN0IC16ICIkYWNfZGF0YXJvb3RkaXJfaGFjayRhY19k
YXRhcm9vdGRpcl9zZWVuIiAmJgorICB7IGFjX291dD1gc2VkIC1uICcvXCR7ZGF0YXJvb3RkaXJ9
L3AnICIkdG1wL291dCJgOyB0ZXN0IC1uICIkYWNfb3V0IjsgfSAmJgorICB7IGFjX291dD1gc2Vk
IC1uICcvXlsJIF0qZGF0YXJvb3RkaXJbCSBdKjoqPS9wJyAiJHRtcC9vdXQiYDsgdGVzdCAteiAi
JGFjX291dCI7IH0gJiYKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiAkYWNfZmlsZSBjb250YWlucyBhIHJlZmVyZW5jZSB0byB0aGUgdmFyaWFibGUg
XGBkYXRhcm9vdGRpcicKK3doaWNoIHNlZW1zIHRvIGJlIHVuZGVmaW5lZC4gIFBsZWFzZSBtYWtl
IHN1cmUgaXQgaXMgZGVmaW5lZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkYWNf
ZmlsZSBjb250YWlucyBhIHJlZmVyZW5jZSB0byB0aGUgdmFyaWFibGUgXGBkYXRhcm9vdGRpcicK
K3doaWNoIHNlZW1zIHRvIGJlIHVuZGVmaW5lZC4gIFBsZWFzZSBtYWtlIHN1cmUgaXQgaXMgZGVm
aW5lZCIgPiYyO30KKworICBybSAtZiAiJHRtcC9zdGRpbiIKKyAgY2FzZSAkYWNfZmlsZSBpbgor
ICAtKSBjYXQgIiR0bXAvb3V0IiAmJiBybSAtZiAiJHRtcC9vdXQiOzsKKyAgKikgcm0gLWYgIiRh
Y19maWxlIiAmJiBtdiAiJHRtcC9vdXQiICIkYWNfZmlsZSI7OworICBlc2FjIFwKKyAgfHwgYXNf
Zm5fZXJyb3IgJD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgOzsK
KyAgOkgpCisgICMKKyAgIyBDT05GSUdfSEVBREVSCisgICMKKyAgaWYgdGVzdCB4IiRhY19maWxl
IiAhPSB4LTsgdGhlbgorICAgIHsKKyAgICAgICRhc19lY2hvICIvKiAkY29uZmlndXJlX2lucHV0
ICAqLyIgXAorICAgICAgJiYgZXZhbCAnJEFXSyAtZiAiJHRtcC9kZWZpbmVzLmF3ayInICIkYWNf
ZmlsZV9pbnB1dHMiCisgICAgfSA+IiR0bXAvY29uZmlnLmgiIFwKKyAgICAgIHx8IGFzX2ZuX2Vy
cm9yICQ/ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGlmIGRp
ZmYgIiRhY19maWxlIiAiJHRtcC9jb25maWcuaCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgICAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY19maWxlIGlzIHVu
Y2hhbmdlZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAkYWNfZmlsZSBpcyB1bmNoYW5nZWQiID4m
Njt9CisgICAgZWxzZQorICAgICAgcm0gLWYgIiRhY19maWxlIgorICAgICAgbXYgIiR0bXAvY29u
ZmlnLmgiICIkYWNfZmlsZSIgXAorCXx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3JlYXRl
ICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGZpCisgIGVsc2UKKyAgICAkYXNfZWNobyAiLyog
JGNvbmZpZ3VyZV9pbnB1dCAgKi8iIFwKKyAgICAgICYmIGV2YWwgJyRBV0sgLWYgIiR0bXAvZGVm
aW5lcy5hd2siJyAiJGFjX2ZpbGVfaW5wdXRzIiBcCisgICAgICB8fCBhc19mbl9lcnJvciAkPyAi
Y291bGQgbm90IGNyZWF0ZSAtIiAiJExJTkVOTyIgNQorICBmaQorIDs7CisKKworICBlc2FjCisK
K2RvbmUgIyBmb3IgYWNfdGFnCisKKworYXNfZm5fZXhpdCAwCitfQUNFT0YKK2FjX2NsZWFuX2Zp
bGVzPSRhY19jbGVhbl9maWxlc19zYXZlCisKK3Rlc3QgJGFjX3dyaXRlX2ZhaWwgPSAwIHx8Cisg
IGFzX2ZuX2Vycm9yICQ/ICJ3cml0ZSBmYWlsdXJlIGNyZWF0aW5nICRDT05GSUdfU1RBVFVTIiAi
JExJTkVOTyIgNQorCisKKyMgY29uZmlndXJlIGlzIHdyaXRpbmcgdG8gY29uZmlnLmxvZywgYW5k
IHRoZW4gY2FsbHMgY29uZmlnLnN0YXR1cy4KKyMgY29uZmlnLnN0YXR1cyBkb2VzIGl0cyBvd24g
cmVkaXJlY3Rpb24sIGFwcGVuZGluZyB0byBjb25maWcubG9nLgorIyBVbmZvcnR1bmF0ZWx5LCBv
biBET1MgdGhpcyBmYWlscywgYXMgY29uZmlnLmxvZyBpcyBzdGlsbCBrZXB0IG9wZW4KKyMgYnkg
Y29uZmlndXJlLCBzbyBjb25maWcuc3RhdHVzIHdvbid0IGJlIGFibGUgdG8gd3JpdGUgdG8gaXQ7
IGl0cworIyBvdXRwdXQgaXMgc2ltcGx5IGRpc2NhcmRlZC4gIFNvIHdlIGV4ZWMgdGhlIEZEIHRv
IC9kZXYvbnVsbCwKKyMgZWZmZWN0aXZlbHkgY2xvc2luZyBjb25maWcubG9nLCBzbyBpdCBjYW4g
YmUgcHJvcGVybHkgKHJlKW9wZW5lZCBhbmQKKyMgYXBwZW5kZWQgdG8gYnkgY29uZmlnLnN0YXR1
cy4gIFdoZW4gY29taW5nIGJhY2sgdG8gY29uZmlndXJlLCB3ZQorIyBuZWVkIHRvIG1ha2UgdGhl
IEZEIGF2YWlsYWJsZSBhZ2Fpbi4KK2lmIHRlc3QgIiRub19jcmVhdGUiICE9IHllczsgdGhlbgor
ICBhY19jc19zdWNjZXNzPToKKyAgYWNfY29uZmlnX3N0YXR1c19hcmdzPQorICB0ZXN0ICIkc2ls
ZW50IiA9IHllcyAmJgorICAgIGFjX2NvbmZpZ19zdGF0dXNfYXJncz0iJGFjX2NvbmZpZ19zdGF0
dXNfYXJncyAtLXF1aWV0IgorICBleGVjIDU+L2Rldi9udWxsCisgICRTSEVMTCAkQ09ORklHX1NU
QVRVUyAkYWNfY29uZmlnX3N0YXR1c19hcmdzIHx8IGFjX2NzX3N1Y2Nlc3M9ZmFsc2UKKyAgZXhl
YyA1Pj5jb25maWcubG9nCisgICMgVXNlIHx8LCBub3QgJiYsIHRvIGF2b2lkIGV4aXRpbmcgZnJv
bSB0aGUgaWYgd2l0aCAkPyA9IDEsIHdoaWNoCisgICMgd291bGQgbWFrZSBjb25maWd1cmUgZmFp
bCBpZiB0aGlzIGlzIHRoZSBsYXN0IGluc3RydWN0aW9uLgorICAkYWNfY3Nfc3VjY2VzcyB8fCBh
c19mbl9leGl0IDEKK2ZpCitpZiB0ZXN0IC1uICIkYWNfdW5yZWNvZ25pemVkX29wdHMiICYmIHRl
c3QgIiRlbmFibGVfb3B0aW9uX2NoZWNraW5nIiAhPSBubzsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVucmVjb2duaXplZCBvcHRpb25z
OiAkYWNfdW5yZWNvZ25pemVkX29wdHMiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYyO30KK2ZpCisK
ZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NvbmZpZ3VyZS5hYwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9j
b25maWd1cmUuYWMJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTg5
IEBACisjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtKi0g
QXV0b2NvbmYgLSotCisjIFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0b2NvbmYgdG8gcHJvZHVj
ZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCisKK0FDX1BSRVJFUShbMi42N10pCitBQ19JTklUKFtYZW4g
SHlwZXJ2aXNvcl0sIG00X2VzeXNjbWQoWy4uL3ZlcnNpb24uc2ggLi4veGVuL01ha2VmaWxlXSks
CisgICAgW3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKK0FDX0NPTkZJR19TUkNESVIo
W2xpYnhsL2xpYnhsLmNdKQorQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMubWtdKQor
QUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKK0FDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkK
K0FDX0NPTkZJR19BVVhfRElSKFsuXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJ
QlMsIENQUEZMQUdTIG9yIENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitBU19JRihb
dGVzdCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsKKyAgICBB
Q19NU0dfV0FSTigKK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdT
IG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQ
RU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBw
b3NzaWJsZS5dKQorXSkKKworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCitBQ19DQU5PTklDQUxf
SE9TVAorCisjIE00IE1hY3JvIGluY2x1ZGVzCittNF9pbmNsdWRlKFttNC9lbmFibGVfZmVhdHVy
ZS5tNF0pCittNF9pbmNsdWRlKFttNC9kaXNhYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5jbHVkZShb
bTQvcGF0aF9vcl9mYWlsLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRdKQorbTRf
aW5jbHVkZShbbTQvcHl0aG9uX3ZlcnNpb24ubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX2Rl
dmVsLm00XSkKK200X2luY2x1ZGUoW200L3VkZXYubTRdKQorbTRfaW5jbHVkZShbbTQvb2NhbWwu
bTRdKQorbTRfaW5jbHVkZShbbTQvZGVmYXVsdF9saWIubTRdKQorbTRfaW5jbHVkZShbbTQvc2V0
X2NmbGFnc19sZGZsYWdzLm00XSkKKworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCitBWF9BUkdf
RU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCisgICAgW0VuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxl
IChieSBkZWZhdWx0LCBGbGFzayldKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtnaXRodHRw
XSwgW0Rvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFBdKQorQVhfQVJHX0RJU0FCTEVf
QU5EX0VYUE9SVChbbW9uaXRvcnNdLAorICAgIFtEaXNhYmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBt
b25pdG9yaW5nIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbdnRwbV0sIFtFbmFi
bGUgVmlydHVhbCBUcnVzdGVkIFBsYXRmb3JtIE1vZHVsZV0pCitBWF9BUkdfRU5BQkxFX0FORF9F
WFBPUlQoW3hhcGldLCBbRW5hYmxlIFhlbiBBUEkgQmluZGluZ3NdKQorQVhfQVJHX0RJU0FCTEVf
QU5EX0VYUE9SVChbcHl0aG9udG9vbHNdLCBbRGlzYWJsZSBQeXRob24gdG9vbHNdKQorQVhfQVJH
X0RJU0FCTEVfQU5EX0VYUE9SVChbb2NhbWx0b29sc10sIFtEaXNhYmxlIE9jYW1sIHRvb2xzXSkK
K0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbWluaXRlcm1dLCBbRW5hYmxlIG1pbml0ZXJtXSkK
K0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbG9tb3VudF0sIFtFbmFibGUgbG9tb3VudF0pCitB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtkZWJ1Z10sIFtEaXNhYmxlIGRlYnVnIGJ1aWxkIG9m
IFhlbiBhbmQgdG9vbHNdKQorCitBQ19BUkdfVkFSKFtQUkVQRU5EX0lOQ0xVREVTXSwKKyAgICBb
TGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkp
XSkKK0FDX0FSR19WQVIoW1BSRVBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRl
cnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKV0pCitBQ19BUkdfVkFSKFtBUFBF
TkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8g
Q0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfTElCXSwKKyAgICBbTGlz
dCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gYXBwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkK
KworQVhfU0VUX0ZMQUdTCisKK0FDX0FSR19WQVIoW1BZVEhPTl0sIFtQYXRoIHRvIHRoZSBQeXRo
b24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBhcnNlcl0pCitB
Q19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJHX1ZBUihbSVBd
LCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGggdG8gQmlzb24g
cGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8gRmxleCBsZXhp
Y2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1BhdGggdG8gY3Vy
bC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwyLWNvbmZpZyB0
b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkKK0FDX0FSR19W
QVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENoZWNrcyBmb3Ig
cHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJPR19DQworQUNfUFJPR19MTl9TCitBQ19QUk9H
X01BS0VfU0VUCitBQ19QUk9HX0lOU1RBTEwKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtQRVJMXSwg
W3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkKK0FYX1BBVEhf
UFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQklTT05dLCBb
Ymlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitBU19JRihbdGVz
dCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0NVUkxdLCBb
Y3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBbeG1sMi1jb25m
aWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsKKyAgICBBQ19Q
Uk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWworICAgICAg
ICBBU19JRihbdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyJdLCBbCisgICAgICAg
ICAgICBBQ19NU0dfRVJST1IoW09jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmlu
ZCBPY2FtbF0pXSkKKyAgICAgICAgb2NhbWx0b29scz0ibiIKKyAgICBdKQorXSkKK0FYX1BBVEhf
UFJPR19PUl9GQUlMKFtCQVNIXSwgW2Jhc2hdKQorQVNfSUYoW3Rlc3QgIngkcHl0aG9udG9vbHMi
ID0gInh5Il0sIFsKKyAgICBBU19JRihbZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyJdLCBb
CisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQ
WVRIT05QQVRIYAorICAgIF0sW3Rlc3QgLXogIiRQWVRIT04iXSwgW1BZVEhPTj0icHl0aG9uIl0s
CisgICAgW0FDX01TR19FUlJPUihbUFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNv
bHV0ZSBwYXRoXSldKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtQWVRIT05QQVRIXSwgWyRQ
WVRIT05dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9WRVJTSU9OKFsyXSwgWzNdKQorICAgIEFYX0NI
RUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNLX1BZVEhPTl9ERVZFTCgpCitdKQorQVhfUEFU
SF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hnZXR0ZXh0XSkKK0FYX0NIRUNLX1VERVYoWzU5
XSkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRfTElCCisKKyMgQ2hlY2tzIGZv
ciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10sIFtpb19zZXR1cF0sIFtzeXN0ZW1fYWlv
PSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJTVChzeXN0ZW1fYWlvKQorQUNfQ0hFQ0tf
TElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxp
YmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4dDJmc19vcGVuMl0sIFtsaWJl
eHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNfU1VCU1QobGliZXh0MmZzKQorQUNfQ0hF
Q0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwg
W2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2NyeXB0KQorQUNfQ0hFQ0tfTElCKFtwdGhy
ZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5v
dCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2NrX2dldHRpbWVd
KQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBbXSwKKyAgICBbQUNfTVNHX0VS
Uk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lh
amxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5YWpsXSld
KQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJST1IoW0Nv
dWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmljb252X29w
ZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCitBQ19TVUJTVChsaWJpY29udikK
KworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNr
KQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNfQUxMT0NBCitBQ19DSEVDS19I
RUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMu
aCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5ldGRiLmgg
bmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAg
ICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBz
eXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmgg
c3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVuaXN0ZC5o
IHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAgICAgICAgIF0pCisKKyMgQ2hlY2tzIGZv
ciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KK0FD
X0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitBQ19DX0lOTElORQorQUNfVFlQRV9JTlQx
Nl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5UNjRfVAorQUNfVFlQRV9JTlQ4X1QKK0FD
X1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19UWVBFX1BJRF9UCitBQ19DX1JFU1RSSUNU
CitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9UCitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1
Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9TVF9CTE9DS1MKK0FDX0NIRUNLX01FTUJF
UlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5UMTZfVAorQUNfVFlQRV9VSU5U
MzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9VSU5UOF9UCitBQ19DSEVDS19UWVBFUyhb
cHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgorQUNfRlVOQ19F
UlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNFRUtPCitBQ19GVU5DX0xTVEFU
X0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFERVJfTUFKT1IKK0FDX0ZVTkNfTUFMTE9D
CitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitBQ19GVU5DX1JFQUxMT0MKK0FDX0ZVTkNf
U1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAgICAgICAg
ICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVu
Y2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUg
Z2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNh
c2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAgICAgICAg
ICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxl
Y3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3Ry
Y3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3RycGJyayBz
dHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAorICAg
ICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQVVQoKQpk
aWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvZGVidWdnZXIvZ2Ric3gv
eGcvTWFrZWZpbGUKLS0tIGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJTW9uIEph
biAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01h
a2VmaWxlCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMjEsNyArMjEsNiBAQCB4
Z19hbGwuYTogJChYR19PQkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMg
LW8gJEAgJF4KIAogeGVuLWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVjayAKIAkk
KE1BS0UpIC1DIC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4uYyBNYWtl
ZmlsZSAkKFhHX0hEUlMpCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29s
cy9pbnN0YWxsLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3Rvb2xzL2luc3RhbGwuc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsMSBAQAorLi4vaW5zdGFsbC5zaApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUK
ZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2xpYmZzaW1hZ2UvTWFr
ZWZpbGUKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlNb24gSmFuIDA5IDE2OjAxOjQ0
IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUdWUgSmFuIDEwIDE5
OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTIsNyArMiwxMSBAQCBYRU5fUk9PVCA9ICQoQ1VSRElSKS8u
Li8uLgogaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBj
b21tb24gdWZzIHJlaXNlcmZzIGlzbzk2NjAgZmF0IHpmcyB4ZnMKLVNVQkRJUlMteSArPSAkKHNo
ZWxsIGVudiBDQz0iJChDQykiIC4vY2hlY2stbGliZXh0MmZzKQoraWZlcSAoJChDT05GSUdfRVhU
MkZTKSwgeSkKKyAgICBTVUJESVJTLXkgKz0gZXh0MmZzLWxpYgorZWxzZQorICAgIFNVQkRJUlMt
eSArPSBleHQyZnMKK2VuZGlmCiAKIC5QSE9OWTogYWxsIGNsZWFuIGluc3RhbGwKIGFsbCBjbGVh
biBpbnN0YWxsOiAlOiBzdWJkaXJzLSUKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0
MTllIHRvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCi0tLSBhL3Rvb2xzL2xpYmZzaW1h
Z2UvY2hlY2stbGliZXh0MmZzCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMSArMCwwIEBACi0j
IS9iaW4vc2gKLQotY2F0ID5leHQyLXRlc3QuYyA8PEVPRgotI2luY2x1ZGUgPGV4dDJmcy9leHQy
ZnMuaD4KLQotaW50IG1haW4oKQotewotCWV4dDJmc19vcGVuMjsKLX0KLUVPRgotCi0ke0NDLWdj
Y30gLW8gZXh0Mi10ZXN0IGV4dDItdGVzdC5jIC1sZXh0MmZzID4vZGV2L251bGwgMj4mMQotaWYg
WyAkPyA9IDAgXTsgdGhlbgotCWVjaG8gZXh0MmZzLWxpYgotZWxzZQotCWVjaG8gZXh0MmZzCi1m
aQotCi1ybSAtZiBleHQyLXRlc3QgZXh0Mi10ZXN0LmMKLQotZXhpdCAwCmRpZmYgLXIgNWIyNjc2
YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9saWJ4ZW4vTWFrZWZpbGUKLS0tIGEvdG9vbHMv
bGlieGVuL01ha2VmaWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29s
cy9saWJ4ZW4vTWFrZWZpbGUJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0yMiwx
MiArMjIsMTIgQEAgTUFKT1IgPSAxLjAKIE1JTk9SID0gMAogCiBDRkxBR1MgKz0gLUlpbmNsdWRl
ICAgICAgICAgICAgICAgICAgICAgXAotICAgICAgICAgICQoc2hlbGwgeG1sMi1jb25maWcgLS1j
ZmxhZ3MpIFwKLSAgICAgICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tY2ZsYWdzKSBcCisgICAg
ICAgICAgJChzaGVsbCAkKFhNTDJfQ09ORklHKSAtLWNmbGFncykgXAorICAgICAgICAgICQoc2hl
bGwgJChDVVJMX0NPTkZJRykgLS1jZmxhZ3MpIFwKICAgICAgICAgICAtZlBJQwogCi1MREZMQUdT
ICs9ICQoc2hlbGwgeG1sMi1jb25maWcgLS1saWJzKSBcCi0gICAgICAgICAgICQoc2hlbGwgY3Vy
bC1jb25maWcgLS1saWJzKQorTERGTEFHUyArPSAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tbGli
cykgXAorICAgICAgICAgICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tbGlicykKIAogTElCWEVO
QVBJX0hEUlMgPSAkKHdpbGRjYXJkIGluY2x1ZGUveGVuL2FwaS8qLmgpIGluY2x1ZGUveGVuL2Fw
aS94ZW5fYWxsLmgKIExJQlhFTkFQSV9PQkpTID0gJChwYXRzdWJzdCAlLmMsICUubywgJCh3aWxk
Y2FyZCBzcmMvKi5jKSkKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xz
L200L2RlZmF1bHRfbGliLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL200L2RlZmF1bHRfbGliLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEg
MjAxMiArMDEwMApAQCAtMCwwICsxLDggQEAKK0FDX0RFRlVOKFtBWF9ERUZBVUxUX0xJQl0sCitb
QVNfSUYoW3Rlc3QgLWQgIiRwcmVmaXgvbGliNjQiXSwgWworICAgIExJQl9QQVRIPSJsaWI2NCIK
K10sWworICAgIExJQl9QQVRIPSJsaWIiCitdKQorQUNfU1VCU1QoTElCX1BBVEgpXSkKKwpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvZGlzYWJsZV9mZWF0dXJl
Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAK
QEAgLTAsMCArMSwxMyBAQAorQUNfREVGVU4oW0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlRdLAor
W0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhbLS1kaXNhYmxlLSQxXSwg
WyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9j
dl8kMT0ibiIKK10sIFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3Zf
JDE9InkiCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdKQor
JDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRl
MDE3YzQxOWUgdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQJ
VHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVO
KFtBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBB
U19IRUxQX1NUUklORyhbLS1lbmFibGUtJDFdLCBbJDJdKSkKKworQVNfSUYoW3Rlc3QgIngkZW5h
YmxlXyQxIiA9ICJ4eWVzIl0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0ZXN0ICJ4JGVuYWJs
ZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0IC16ICRheF9jdl8k
MV0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10pCiskMT0kYXhfY3ZfJDEKK0FDX1NVQlNUKCQxKV0p
CmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9tNC9vY2FtbC5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC9vY2FtbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyNDEg
QEAKK2RubCBhdXRvY29uZiBtYWNyb3MgZm9yIE9DYW1sCitkbmwgZnJvbSBodHRwOi8vZm9yZ2Uu
b2NhbWxjb3JlLm9yZy8KK2RubAorZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgUmljaGFyZCBX
Lk0uIEpvbmVzCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAgICBTdGVmYW5vIFphY2NoaXJvbGkK
K2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IE9saXZpZXIgQW5kcmlldQorZG5sIENvcHlyaWdo
dCDCqSAyMDAwLTIwMDUgSmVhbi1DaHJpc3RvcGhlIEZpbGxpw6J0cmUKK2RubCBDb3B5cmlnaHQg
wqkgMjAwMC0yMDA1IEdlb3JnZXMgTWFyaWFubworZG5sCitkbmwgRm9yIGRvY3VtZW50YXRpb24s
IHBsZWFzZSByZWFkIHRoZSBvY2FtbC5tNCBtYW4gcGFnZS4KKworQUNfREVGVU4oW0FDX1BST0df
T0NBTUxdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgQUNfQ0hFQ0tfVE9PTChb
T0NBTUxDXSxbb2NhbWxjXSxbbm9dKQorCisgIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRo
ZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCdgCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIHZlcnNpb24gaXMg
JE9DQU1MVkVSU0lPTl0pCisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAg
aWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxD
IC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0
YAorICAgICBlbHNlCisgICAgICAgIEFDX01TR19SRVNVTFQoW09DQU1MTElCIHByZXZpb3VzbHkg
c2V0OyBwcmVzZXJ2aW5nIGl0Ll0pCisgICAgIGZpCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1s
IGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUJdKQorCisgICAgIEFDX1NVQlNUKFtPQ0FNTFZFUlNJ
T05dKQorICAgICBBQ19TVUJTVChbT0NBTUxMSUJdKQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9j
YW1sb3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MT1BUXSxbb2NhbWxvcHRdLFtub10pCisg
ICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVu
CisJQUNfTVNHX1dBUk4oW0Nhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlv
biBvbmx5Ll0pCisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4g
LWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZFUlNJT04i
ICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMg
ZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLl0pCisJICAgIE9DQU1MT1BU
PW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9b3B0CisJZmkKKyAgICAgZmkKKworICAgICBBQ19T
VUJTVChbT0NBTUxCRVNUXSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0CisgICAg
IEFDX0NIRUNLX1RPT0woW09DQU1MQ0RPVE9QVF0sW29jYW1sYy5vcHRdLFtub10pCisgICAgIGlm
IHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxD
RE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlm
IHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01T
R19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2Fy
ZGVkLl0pCisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisK
KyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9Q
VCIgIT0gIm5vIiA7IHRoZW4KKwlBQ19DSEVDS19UT09MKFtPQ0FNTE9QVERPVE9QVF0sW29jYW1s
b3B0Lm9wdF0sW25vXSkKKwlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4K
KwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJz
aW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NB
TUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9uIGRpZmZlcnMg
ZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuXSkKKwkgICBlbHNlCisJICAgICAg
T0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAgZmkKKwor
ICAgICBBQ19TVUJTVChbT0NBTUxPUFRdKQorICBmaQorCisgIEFDX1NVQlNUKFtPQ0FNTENdKQor
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisgIEFDX0NIRUNLX1RPT0woW09DQU1M
XSxbb2NhbWxdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKKyAgQUNfQ0hFQ0tf
VE9PTChbT0NBTUxERVBdLFtvY2FtbGRlcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2Ft
bG1rdG9wCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtUT1BdLFtvY2FtbG1rdG9wXSxbbm9dKQor
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxNS0xJ
Ql0sW29jYW1sbWtsaWJdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxET0NdLFtvY2FtbGRvY10sW25vXSkKKworICAjIGNoZWNraW5nIGZv
ciBvY2FtbGJ1aWxkCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQlVJTERdLFtvY2FtbGJ1aWxkXSxb
bm9dKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTExFWF0sCitbZG5sCisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sbGV4CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYXSxbb2NhbWxsZXhd
LFtub10pCisgIGlmIHRlc3QgIiRPQ0FNTExFWCIgIT0gIm5vIjsgdGhlbgorICAgIEFDX0NIRUNL
X1RPT0woW09DQU1MTEVYRE9UT1BUXSxbb2NhbWxsZXgub3B0XSxbbm9dKQorICAgIGlmIHRlc3Qg
IiRPQ0FNTExFWERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCU9DQU1MTEVYPSRPQ0FNTExFWERPVE9Q
VAorICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtPQ0FNTExFWF0pCitdKQorCitBQ19ERUZVTihb
QUNfUFJPR19PQ0FNTFlBQ0NdLAorW2RubAorICBBQ19DSEVDS19UT09MKFtPQ0FNTFlBQ0NdLFtv
Y2FtbHlhY2NdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTFlBQ0NdKQorXSkKKworCitBQ19ERUZV
TihbQUNfUFJPR19DQU1MUDRdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlk
bmwKKworICAjIGNoZWNraW5nIGZvciBjYW1scDQKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0XSxb
Y2FtbHA0XSxbbm9dKQorICBpZiB0ZXN0ICIkQ0FNTFA0IiAhPSAibm8iOyB0aGVuCisgICAgIFRN
UFZFUlNJT049YCRDQU1MUDQgLXYgMj4mMXwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiAqXCguKlwp
JHxcMXxwJ2AKKyAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7
IHRoZW4KKwlBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjXSkKKyAg
ICAgICAgQ0FNTFA0PW5vCisgICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtDQU1MUDRdKQorCisg
ICMgY2hlY2tpbmcgZm9yIGNvbXBhbmlvbiB0b29scworICBBQ19DSEVDS19UT09MKFtDQU1MUDRC
T09UXSxbY2FtbHA0Ym9vdF0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T10sW2NhbWxw
NG9dLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9GXSxbY2FtbHA0b2ZdLFtub10pCisg
IEFDX0NIRUNLX1RPT0woW0NBTUxQNE9PRl0sW2NhbWxwNG9vZl0sW25vXSkKKyAgQUNfQ0hFQ0tf
VE9PTChbQ0FNTFA0T1JGXSxbY2FtbHA0b3JmXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1M
UDRQUk9GXSxbY2FtbHA0cHJvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Ul0sW2Nh
bWxwNHJdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJGXSxbY2FtbHA0cmZdLFtub10p
CisgIEFDX1NVQlNUKFtDQU1MUDRCT09UXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9dKQorICBBQ19T
VUJTVChbQ0FNTFA0T0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0T09GXSkKKyAgQUNfU1VCU1QoW0NB
TUxQNE9SRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRQUk9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJd
KQorICBBQ19TVUJTVChbQ0FNTFA0UkZdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19GSU5E
TElCXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVj
a2luZyBmb3Igb2NhbWxmaW5kCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRklORF0sW29jYW1sZmlu
ZF0sW25vXSkKKyAgQUNfU1VCU1QoW09DQU1MRklORF0pCitdKQorCisKK2RubCBUaGFua3MgdG8g
SmltIE1leWVyaW5nIGZvciB3b3JraW5nIHRoaXMgbmV4dCBiaXQgb3V0IGZvciB1cy4KK2RubCBY
WFggV2Ugc2hvdWxkIGRlZmluZSBBU19UUl9TSCBpZiBpdCdzIG5vdCBkZWZpbmVkIGFscmVhZHkK
K2RubCAoZWcuIGZvciBvbGQgYXV0b2NvbmYpLgorQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1BL
R10sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfRklORExJQl0pZG5sCisKKyAgQUNfTVNH
X0NIRUNLSU5HKFtmb3IgT0NhbWwgZmluZGxpYiBwYWNrYWdlICQxXSkKKworICB1bnNldCBmb3Vu
ZAorICB1bnNldCBwa2cKKyAgZm91bmQ9bm8KKyAgZm9yIHBrZyBpbiAkMSAkMiA7IGRvCisgICAg
aWYgJE9DQU1MRklORCBxdWVyeSAkcGtnID4vZGV2L251bGwgMj4vZGV2L251bGw7IHRoZW4KKyAg
ICAgIEFDX01TR19SRVNVTFQoW2ZvdW5kXSkKKyAgICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFd
KT0kcGtnCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAgZG9uZQorICBp
ZiB0ZXN0ICIkZm91bmQiID0gIm5vIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91
bmRdKQorICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT1ubworICBmaQorCisgIEFDX1NVQlNU
KEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKSkKK10pCisKKworQUNfREVGVU4oW0FDX0NIRUNLX09D
QU1MX01PRFVMRV0sCitbZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIG1vZHVsZSAk
Ml0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKK29wZW4gJDMKK0VPRgorICB1bnNldCBm
b3VuZAorICBmb3IgJDEgaW4gJCQxICQ0IDsgZG8KKyAgICBpZiAkT0NBTUxDIC1jIC1JICIkJDEi
IGNvbmZ0ZXN0Lm1sID4mNSAyPiY1IDsgdGhlbgorICAgICAgZm91bmQ9eWVzCisgICAgICBicmVh
aworICAgIGZpCisgIGRvbmUKKworICBpZiB0ZXN0ICIkZm91bmQiIDsgdGhlbgorICAgIEFDX01T
R19SRVNVTFQoWyQkMV0pCisgIGVsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQor
ICAgICQxPW5vCisgIGZpCisgIEFDX1NVQlNUKFskMV0pCitdKQorCisKK2RubCBYWFggQ3Jvc3Mt
Y29tcGlsaW5nCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfV09SRF9TSVpFXSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9D
YW1sIGNvbXBpbGVyIHdvcmQgc2l6ZV0pCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCisgIHBy
aW50X2VuZGxpbmUgKHN0cmluZ19vZl9pbnQgU3lzLndvcmRfc2l6ZSkKKyAgRU9GCisgIE9DQU1M
X1dPUkRfU0laRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFskT0NBTUxf
V09SRF9TSVpFXSkKKyAgQUNfU1VCU1QoW09DQU1MX1dPUkRfU0laRV0pCitdKQorCitBQ19ERUZV
TihbQUNfQ0hFQ0tfT0NBTUxfT1NfVFlQRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0df
T0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW09DYW1sIFN5cy5vc190eXBlXSkKKworICBj
YXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9zdHJpbmcoU3lzLm9zX3R5cGUpOzsKK0VP
RgorCisgIE9DQU1MX09TX1RZUEU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VM
VChbJE9DQU1MX09TX1RZUEVdKQorICBBQ19TVUJTVChbT0NBTUxfT1NfVFlQRV0pCitdKQpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvcGF0aF9vcl9mYWlsLm00
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L200L3BhdGhfb3JfZmFpbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAs
MCArMSw2IEBACitBQ19ERUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FDX1BBVEhfUFJP
RyhbJDFdLCBbJDJdLCBbbm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAKK3RoZW4KKyAg
ICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFsbCAkMl0pCitm
aV0pCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9tNC9weXRob25f
ZGV2ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIvdG9vbHMvbTQvcHl0aG9uX2RldmVsLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEw
MApAQCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBv
cnQgb3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0
cyhwICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0
KDEpCisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAg
ICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFj
a2FnZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRp
ZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9tNC9weXRob25fdmVyc2lv
bi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9weXRob25fdmVyc2lvbi5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAK
QEAgLTAsMCArMSwxMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04g
LWMgJ2ltcG9ydCBzeXM7IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikp
J2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhP
TiAtViAyPiYxYAorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisg
ICAgICAgIFskcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJz
aW9uIGlzICQxLiQyXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvcHl0aG9uX3htbC5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC9weXRob25feG1sLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsx
LDEwIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5H
KFtmb3IgcHl0aG9uIHhtbC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5k
b20ubWluaWRvbSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VM
VChbbm9dKQorICAgIEFDX01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9t
IG1vZHVsZV0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5t
NAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29s
cy9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMjAgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBjZmxhZyBp
biAkUFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIK
K2RvbmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRfTERGTEFH
Uys9IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURFUworZG8K
KyAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkQVBQ
RU5EX0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitDRkxB
R1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFHUz0iJFBS
RVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1yIDViMjY3
NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00CVR1ZSBK
YW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZVTihbQVhf
Q0hFQ0tfVURFVl0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4K
KyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVz
dCB4IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9H
KFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJ
TkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAor
ICAgICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVh
c2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5G
T30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7
VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVz
dCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQ
TFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0g
eCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRv
byBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAg
ZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkK
KyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBB
Q19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkK
KyAgICBmaQorZmkKK10pCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB2ZXJz
aW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3ZlcnNpb24uc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNCBA
QAorIyEvYmluL3NoCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9OIiAkMSB8IHNlZCAn
cy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBYRU5fU1VCVkVSU0lP
TiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAiJWQuJWQiICRNQUpP
UiAkTUlOT1IKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBj-0002ft-LQ; Wed, 01 Feb 2012 10:13:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RpzUe-0007wi-1h
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:50:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327484989!50156705!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22977 invoked from network); 25 Jan 2012 09:49:49 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 09:49:49 -0000
Received: by wibhm2 with SMTP id hm2so4744738wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 01:50:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=51A2ebY6gr7L9rWQgJMuwZUXP9WRAxeMHeavbb4doaE=;
	b=SxPMmZqPOyO54bYXFKJTsyQkS5sIIofzAt7v9v4iOIue8Px8GSNXI4M9H3uFqJn7W1
	0dczbYU+iFxbBdnkqUhDL8rcswWfVXy0nNBqWZoIxjPDEw89X2BkuQnBAB6I3jggsdCe
	ZOVbqtrXPh0cQlOCYDpG9XEBz/fuXXY4/7ntM=
Received: by 10.180.83.104 with SMTP id p8mr9929061wiy.4.1327485010923;
	Wed, 25 Jan 2012 01:50:10 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id di5sm61824275wib.3.2012.01.25.01.50.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Jan 2012 01:50:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6fde017c419e70925f15eb00e8266107011e21cb
Message-Id: <6fde017c419e70925f15.1326761318@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 17 Jan 2012 01:48:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] [PATCH v4] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MjE5MTgxIC0zNjAwCiMgTm9kZSBJRCA2ZmRlMDE3YzQx
OWU3MDkyNWYxNWViMDBlODI2NjEwNzAxMWUyMWNiCiMgUGFyZW50ICA1YjI2NzZhYzEzMjE4OTUx
Njk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL1Rvb2xzLm1rIGFuZCB0b29scy9jb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMg
aW5jbHVkZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRp
b25zIHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBh
c3NpbmcKcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBl
eGVjdXRpbmcgY29uZmlndXJlCnNjcmlwdC4KCnRvb2xzL2NvbmZpZy5oIGlzIHN0aWxsIG5vdCB1
c2VkIGFueXdoZXJlLCBhbmQgaXMgYXV0b21hdGljYWxseQpjcmVhdGVkIGJ5IGF1dG9oZWFkZXIs
IGFsdG91Z2ggdGhpcyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvCmluY2x1ZGUgdGhpcyBm
aWxlLgoKSnVzdCBhIGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9j
b25mIHNjcmlwdCBJIGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhl
cmUuLi4gUGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjM6CgogKiBD
b3BpZWQgY29uZmlnLnN1YiBhbmQgY29uZmlnLmd1ZXNzIGZyb20gYXV0b21ha2UgdmVyc2lvbiAx
LjExLjEKICAgcHJlc2VudCBpbiBEZWJpYW4gc3RhYmxlICg2LjAuMykuCgpDaGFuZ2VzIHNpbmNl
IHYyOgoKICogQ2hhbmdlZCBvcmRlciBvZiBjb25maWcvVG9vbHMubWsgaW5jbHVkZS4KCiAqIEFk
ZGVkICItZSIgdG8gYXV0b2dlbi5zaCBzaGViYW5nLgoKICogQWRkZWQgbmVjZXNzYXJ5IGZpbGVz
IChjb25maWcuKikgYW5kIG91dHB1dCBmcm9tIEF1dG9oZWFkZXIgYW5kCiAgIEF1dG9jb25mLgoK
ICogUmVtb3ZlZCBBdXRvY29uZiBmcm9tIGJ1aWxkIGRlcGVuZGVuY2llcyBhbmQgdXBkYXRlZCBS
RUFETUUuCgpDaGFuZ2VzIHNpbmNlIHYxOgoKICogTW92ZWQgYXV0b2NvbmYgc3R1ZmYgaW5zaWRl
IHRvb2xzIGZvbGRlci4KCiAqIEFkZCBNYWtlZmlsZSBydWxlcyBmb3IgY2xlYW5pbmcuCgogKiBS
ZW1vdmVkIEF1dG9tYWtlIGRlcGVuZGVuY3kuCgogKiBDcmVhdGUgYXV0b2dlbi5zaCB0byBhdXRv
bWF0aWNhbGx5IGNyZWF0ZSBjb25maWd1cmUgc2NyaXB0IHdoZW4KICAgYnVpbGRpbmcgZnJvbSBz
b3VyY2UgcmVwb3NpdG9yeS4KCiAqIENhY2hlZCB2YWx1ZXMgb2Ygb3B0aW9ucyBwYXNzZWQgZnJv
bSBjb21tYW5kIGxpbmUuCgogKiBBZGQgbmVjZXNzYXJ5IGlnbm9yZXMgdG8gLmhnaWdub3JlLgoK
ICogQWRkZWQgQXV0b2NvbmYgdG8gdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVzLgoKICogQ2hhbmdl
ZCBoeXBlbiB0byB1bmRlcnNjb3JlIGluIFhNTDIgYW5kIENVUkwgdmFyaWFibGUgbmFtZXMuCgog
KiBBZGRlZCBzY3JpcHQgdG8gZ2V0IHZlcnNpb24gZnJvbSB4ZW4vTWFrZWZpbGUuCgogKiBTZXQg
T2NhbWwgdG9vbHMgdG8gb3B0aW9uYWwuCgogKiBBZGRlZCBwcm9jZWRlbmNlIG9mIG00L29jYW1s
Lm00LgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBj
LmVkdT4KCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSAuaGdpZ25vcmUKLS0t
IGEvLmhnaWdub3JlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi8uaGdpZ25v
cmUJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0zMDgsNiArMzA4LDEyIEBACiBe
dG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2NhbWwvbGlicy94bC94
ZW5saWdodFwubWxpJAogXnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3RvcmVkJAorXnRvb2xz
L2F1dG9tNHRlXC5jYWNoZSQKK150b29scy9jb25maWdcLmgkCitedG9vbHMvY29uZmlnXC5sb2ck
CitedG9vbHMvY29uZmlnXC5zdGF0dXMkCitedG9vbHMvY29uZmlnXC5jYWNoZSQKK15jb25maWcv
VG9vbHNcLm1rJAogXnhlbi9cLmJhbm5lci4qJAogXnhlbi9CTE9HJAogXnhlbi9TeXN0ZW0ubWFw
JApkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgQ29uZmlnLm1rCi0tLSBhL0Nv
bmZpZy5tawlNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIGIvQ29uZmlnLm1rCVR1
ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtNzAsOSArNzAsNiBAQCBFWFRSQV9JTkNM
VURFUyArPSAkKEVYVFJBX1BSRUZJWCkvaW5jbHVkCiBFWFRSQV9MSUIgKz0gJChFWFRSQV9QUkVG
SVgpLyQoTElCTEVBRkRJUikKIGVuZGlmCiAKLUJJU09OCT89IGJpc29uCi1GTEVYCT89IGZsZXgK
LQogUFlUSE9OICAgICAgPz0gcHl0aG9uCiBQWVRIT05fUFJFRklYX0FSRyA/PSAtLXByZWZpeD0i
JChQUkVGSVgpIgogIyBUaGUgYWJvdmUgcmVxdWlyZXMgdGhhdCBQUkVGSVggY29udGFpbnMgKm5v
IHNwYWNlcyouIFRoaXMgdmFyaWFibGUgaXMgaGVyZQpAQCAtMTc1LDIyICsxNzIsOSBAQCBDRkxB
R1MgKz0gJChmb3JlYWNoIGksICQoUFJFUEVORF9JTkNMVURFCiBBUFBFTkRfTERGTEFHUyArPSAk
KGZvcmVhY2ggaSwgJChBUFBFTkRfTElCKSwgLUwkKGkpKQogQVBQRU5EX0NGTEFHUyArPSAkKGZv
cmVhY2ggaSwgJChBUFBFTkRfSU5DTFVERVMpLCAtSSQoaSkpCiAKLUNIRUNLX0xJQiA9ICQoRVhU
UkFfTElCKSAkKFBSRVBFTkRfTElCKSAkKEFQUEVORF9MSUIpCi1DSEVDS19JTkNMVURFUyA9ICQo
RVhUUkFfSU5DTFVERVMpICQoUFJFUEVORF9JTkNMVURFUykgJChBUFBFTkRfSU5DTFVERVMpCi0K
IEVNQkVEREVEX0VYVFJBX0NGTEFHUyA6PSAtbm9waWUgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZu
by1zdGFjay1wcm90ZWN0b3ItYWxsCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgKz0gLWZuby1leGNl
cHRpb25zCiAKLSMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNr
KS4KLVhTTV9FTkFCTEUgPz0gbgotRkxBU0tfRU5BQkxFID89ICQoWFNNX0VOQUJMRSkKLQotIyBE
b3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8K
LSMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3Jr
cyBhdCBhbGwgKGZpcmV3YWxscwotIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZh
dWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKLSMgZmFpbCBvciBoYW5n
LCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCi1HSVRfSFRU
UCA/PSBuCi0KIFhFTl9FWFRGSUxFU19VUkw9aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS94
ZW4tZXh0ZmlsZXMKICMgQWxsIHRoZSBmaWxlcyBhdCB0aGF0IGxvY2F0aW9uIHdlcmUgZG93bmxv
YWRlZCBmcm9tIGVsc2V3aGVyZSBvbgogIyB0aGUgaW50ZXJuZXQuICBUaGUgb3JpZ2luYWwgZG93
bmxvYWQgVVJMIGlzIHByZXNlcnZlZCBhcyBhIGNvbW1lbnQKQEAgLTIyMiwxNyArMjA2LDMgQEAg
UUVNVV9UQUcgPz0gYmIzNmQ2MzJlNGNhYmY0Nzg4MmFkZmYwN2E0NQogIyBOb3RlIHRoYXQgdXNp
bmcgU2VhQklPUyByZXF1aXJlcyB0aGUgdXNlIHRoZSB1cHN0cmVhbSBxZW11IGFzIHRoZQogIyBk
ZXZpY2UgbW9kZWwuCiBTRUFCSU9TX0RJUiA/PSAKLQotIyBPcHRpb25hbCBjb21wb25lbnRzCi1Y
RU5TVEFUX1hFTlRPUCAgICAgPz0geQotVlRQTV9UT09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQ
SV9CSU5ESU5HUyA/PSBuCi1QWVRIT05fVE9PTFMgICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAg
ICAgID89IHkKLUNPTkZJR19NSU5JVEVSTSAgICA/PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0g
bgotQ09ORklHX1NZU1RFTV9MSUJBSU8gPz0geQotCi1pZmVxICgkKE9DQU1MX1RPT0xTKSx5KQot
T0NBTUxfVE9PTFMgOj0gJChzaGVsbCBvY2FtbG9wdCAtdiA+IC9kZXYvbnVsbCAyPiYxICYmIGVj
aG8gInkiIHx8IGVjaG8gIm4iKQotZW5kaWYKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAx
N2M0MTllIE1ha2VmaWxlCi0tLSBhL01ha2VmaWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiAr
MDEwMAorKysgYi9NYWtlZmlsZQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTQw
LDExICs0MCw5IEBAIGRpc3Q6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0OiBkaXN0
LXhlbiBkaXN0LWtlcm5lbHMgZGlzdC10b29scyBkaXN0LXN0dWJkb20gZGlzdC1kb2NzIGRpc3Qt
bWlzYwogCiBkaXN0LW1pc2M6Ci0JJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawogCSQo
SU5TVEFMTF9EQVRBKSAuL0NPUFlJTkcgJChESVNURElSKQogCSQoSU5TVEFMTF9EQVRBKSAuL1JF
QURNRSAkKERJU1RESVIpCiAJJChJTlNUQUxMX1BST0cpIC4vaW5zdGFsbC5zaCAkKERJU1RESVIp
Ci0JJChJTlNUQUxMX1BST0cpIHRvb2xzL2NoZWNrL2NoayB0b29scy9jaGVjay9jaGVja18qIHRv
b2xzL2NoZWNrL2Z1bmNzLnNoICQoRElTVERJUikvY2hlY2sKIGRpc3QtJTogREVTVERJUj0kKERJ
U1RESVIpL2luc3RhbGwKIGRpc3QtJTogaW5zdGFsbC0lCiAJQDogIyBkbyBub3RoaW5nCmRpZmYg
LXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSBSRUFETUUKLS0tIGEvUkVBRE1FCU1vbiBK
YW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi9SRUFETUUJVHVlIEphbiAxMCAxOToxMzow
MSAyMDEyICswMTAwCkBAIC04Nyw5ICs4NywxMyBAQCAyLiBjZCB0byB4ZW4tdW5zdGFibGUgKG9y
IHdoYXRldmVyIHlvdSBzCiAzLiBGb3IgdGhlIHZlcnkgZmlyc3QgYnVpbGQsIG9yIGlmIHlvdSB3
YW50IHRvIGRlc3Ryb3kgYnVpbGQgdHJlZXMsCiAgICBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgc3Rl
cHM6CiAKKyAgICAjIC4vY29uZmlndXJlCiAgICAgIyBtYWtlIHdvcmxkCiAgICAgIyBtYWtlIGlu
c3RhbGwKIAorICAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29uZmlndXJlIC0taGVscCB0
byBzZWUgdGhlIGxpc3Qgb2YKKyAgIG9wdGlvbnMgYXZhaWxhYmxlIG9wdGlvbnMgd2hlbiBidWls
ZGluZyBhbmQgaW5zdGFsbGluZyBYZW4uCisKICAgIFRoaXMgd2lsbCBjcmVhdGUgYW5kIGluc3Rh
bGwgb250byB0aGUgbG9jYWwgbWFjaGluZS4gSXQgd2lsbCBidWlsZAogICAgdGhlIHhlbiBiaW5h
cnkgKHhlbi5neiksIHRoZSB0b29scyBhbmQgdGhlIGRvY3VtZW50YXRpb24uCiAKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIGF1dG9nZW4uc2gKLS0tIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvYXV0b2dlbi5zaAlUdWUgSmFuIDEwIDE5
OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSw5IEBACisjIS9iaW4vc2ggLWUKK3JtIC1yZiBj
b25maWd1cmUKK2NkIHRvb2xzCithdXRvaGVhZGVyCithdXRvY29uZgorY2QgLi4KK2VjaG8gIiMh
L2Jpbi9zaCAtZSIgPj4gY29uZmlndXJlCitlY2hvICJjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSBc
JEAiID4+IGNvbmZpZ3VyZQorY2htb2QgK3ggY29uZmlndXJlCmRpZmYgLXIgNWIyNjc2YWMxMzIx
IC1yIDZmZGUwMTdjNDE5ZSBjb25maWcvVG9vbHMubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvY29uZmlnL1Rvb2xzLm1rLmluCVR1ZSBKYW4g
MTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDUwIEBACisjIFByZWZpeCBhbmQgaW5z
dGFsbCBmb2xkZXIKK1BSRUZJWCAgICAgICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJf
eDg2XzY0ICAgOj0gQExJQl9QQVRIQAorCisjIEEgZGVidWcgYnVpbGQgb2YgdG9vbHM/CitkZWJ1
ZyAgICAgICAgICAgICAgIDo9IEBkZWJ1Z0AKKworIyBUb29scyBwYXRoCitCSVNPTiAgICAgICAg
ICAgICAgIDo9IEBCSVNPTkAKK0ZMRVggICAgICAgICAgICAgICAgOj0gQEZMRVhACitQWVRIT04g
ICAgICAgICAgICAgIDo9IEBQWVRIT05ACitQWVRIT05fUEFUSCAgICAgICAgIDo9IEBQWVRIT05Q
QVRIQAorUEVSTCAgICAgICAgICAgICAgICA6PSBAUEVSTEAKK0JSQ1RMICAgICAgICAgICAgICAg
Oj0gQEJSQ1RMQAorSVAgICAgICAgICAgICAgICAgICA6PSBASVBACitDVVJMX0NPTkZJRyAgICAg
ICAgIDo9IEBDVVJMQAorWE1MMl9DT05GSUcgICAgICAgICA6PSBAWE1MQAorQkFTSCAgICAgICAg
ICAgICAgICA6PSBAQkFTSEAKK1hHRVRUVEVYVCAgICAgICAgICAgOj0gQFhHRVRURVhUQAorCisj
IEV4dHJhIGZvbGRlciBmb3IgbGlicy9pbmNsdWRlcworUFJFUEVORF9JTkNMVURFUyAgICA6PSBA
UFJFUEVORF9JTkNMVURFU0AKK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElCQAor
QVBQRU5EX0lOQ0xVREVTICAgICA6PSBAQVBQRU5EX0lOQ0xVREVTQAorQVBQRU5EX0xJQiAgICAg
ICAgICA6PSBAQVBQRU5EX0xJQkAKKworIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkg
ZGVmYXVsdCwgRmxhc2spLgorWFNNX0VOQUJMRSAgICAgICAgICA6PSBAeHNtQAorRkxBU0tfRU5B
QkxFICAgICAgICA6PSBAeHNtQAorCisjIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhU
VFAgb3IgR0lUJ3Mgb3duIHByb3RvY29sPworIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5k
IG1vcmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCisjIG1heSBibG9j
ayBpdCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5
IGRvd25sb2FkcworIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4g
eW91ciBlbnZpcm9ubWVudC4KK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBACisKKyMg
T3B0aW9uYWwgY29tcG9uZW50cworWEVOU1RBVF9YRU5UT1AgICAgICA6PSBAbW9uaXRvcnNACitW
VFBNX1RPT0xTICAgICAgICAgIDo9IEB2dHBtQAorTElCWEVOQVBJX0JJTkRJTkdTICA6PSBAeGFw
aUAKK1BZVEhPTl9UT09MUyAgICAgICAgOj0gQHB5dGhvbnRvb2xzQAorT0NBTUxfVE9PTFMgICAg
ICAgICA6PSBAb2NhbWx0b29sc0AKK0NPTkZJR19NSU5JVEVSTSAgICAgOj0gQG1pbml0ZXJtQAor
Q09ORklHX0xPTU9VTlQgICAgICA6PSBAbG9tb3VudEAKKworI1N5c3RlbSBvcHRpb25zCitDT05G
SUdfU1lTVEVNX0xJQkFJTzo9IEBzeXN0ZW1fYWlvQAorQ09ORklHX0xJQklDT05WICAgICA6PSBA
bGliaWNvbnZACitDT05GSUdfR0NSWVBUICAgICAgIDo9IEBsaWJnY3J5cHRACitDT05GSUdfRVhU
MkZTICAgICAgIDo9IEBsaWJleHQyZnNACmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdj
NDE5ZSBjb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIvY29uZmlndXJlCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCww
ICsxLDIgQEAKKyMhL2Jpbi9zaCAtZQorY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgJEAKZGlmZiAt
ciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL01ha2VmaWxlCi0tLSBhL3Rvb2xz
L01ha2VmaWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9NYWtl
ZmlsZQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTYsNyArNiw2IEBAIFNVQkRJ
UlMtbGliYWlvIDo9IGxpYmFpbwogZW5kaWYKIAogU1VCRElSUy15IDo9Ci1TVUJESVJTLXkgKz0g
Y2hlY2sKIFNVQkRJUlMteSArPSBpbmNsdWRlCiBTVUJESVJTLXkgKz0gbGlieGMKIFNVQkRJUlMt
eSArPSBmbGFzawpAQCAtNzYsNiArNzUsOCBAQCBjbGVhbjogc3ViZGlycy1jbGVhbgogLlBIT05Z
OiBkaXN0Y2xlYW4KIGRpc3RjbGVhbjogc3ViZGlycy1kaXN0Y2xlYW4KIAlybSAtcmYgaW9lbXUt
ZGlyIGlvZW11LXJlbW90ZQorCXJtIC1yZiAuLi9jb25maWcvVG9vbHMubWsgY29uZmlnLmggY29u
ZmlnLmxvZyBjb25maWcuc3RhdHVzIFwKKyAgICAgICAgICAgICAgIGNvbmZpZy5jYWNoZSBhdXRv
bTR0ZS5jYWNoZQogCiBpZm5lcSAoJChYRU5fQ09NUElMRV9BUkNIKSwkKFhFTl9UQVJHRVRfQVJD
SCkpCiBJT0VNVV9DT05GSUdVUkVfQ1JPU1MgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gpIFwK
ZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL1J1bGVzLm1rCi0tLSBh
L3Rvb2xzL1J1bGVzLm1rCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29s
cy9SdWxlcy5tawlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTQsNiArNCw3IEBA
CiBhbGw6CiAKIGluY2x1ZGUgJChYRU5fUk9PVCkvQ29uZmlnLm1rCitpbmNsdWRlICQoWEVOX1JP
T1QpL2NvbmZpZy9Ub29scy5tawogCiBleHBvcnQgX0lOU1RBTEwgOj0gJChJTlNUQUxMKQogSU5T
VEFMTCA9ICQoWEVOX1JPT1QpL3Rvb2xzL2Nyb3NzLWluc3RhbGwKQEAgLTgwLDggKzgxLDYgQEAg
Y2hlY2stJChDT05GSUdfWDg2KSA9ICQoY2FsbCBjYy12ZXItY2hlYwogICAgICAgICAgICAgICAg
ICAgICAgICAgIlhlbiByZXF1aXJlcyBhdCBsZWFzdCBnY2MtMy40IikKICQoZXZhbCAkKGNoZWNr
LXkpKQogCi1fUFlUSE9OX1BBVEggOj0gJChzaGVsbCB3aGljaCAkKFBZVEhPTikpCi1QWVRIT05f
UEFUSCA/PSAkKF9QWVRIT05fUEFUSCkKIElOU1RBTExfUFlUSE9OX1BST0cgPSBcCiAJJChYRU5f
Uk9PVCkvdG9vbHMvcHl0aG9uL2luc3RhbGwtd3JhcCAiJChQWVRIT05fUEFUSCkiICQoSU5TVEFM
TF9QUk9HKQogCkBAIC0xMDksMyArMTA4LDcgQEAgc3ViZGlyLWFsbC0lIHN1YmRpci1jbGVhbi0l
IHN1YmRpci1pbnN0YQogCiBzdWJkaXItZGlzdGNsZWFuLSU6IC5waG9ueQogCSQoTUFLRSkgLUMg
JCogY2xlYW4KKworJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1rOgorCUBlY2hvICJZb3UgaGF2
ZSB0byBydW4gLi9jb25maWd1cmUgYmVmb3JlIGJ1aWxkaW5nIG9yIGluc3RhbGxpbmcgdGhlIHRv
b2xzIgorCUBleGl0IDEKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xz
L2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2Vm
aWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9ibGt0YXAvZHJp
dmVycy9NYWtlZmlsZQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTEzLDcgKzEz
LDcgQEAgQ0ZMQUdTICAgKz0gJChDRkxBR1NfbGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAk
KE1FTVNIUl9ESVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCiAKLWlmZXEgKCQoc2hlbGwg
LiAuL2NoZWNrX2djcnlwdCAkKENDKSkseWVzKQoraWZlcSAoJENPTkZJR19HQ1JZUFQseSkKIENG
TEFHUyArPSAtRFVTRV9HQ1JZUFQKIENSWVBUX0xJQiA6PSAtbGdjcnlwdAogZWxzZQpkaWZmIC1y
IDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tf
Z2NyeXB0Ci0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAlNb24gSmFuIDA5
IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+IC5nY3J5cHQuYyA8
PCBFT0YKLSNpbmNsdWRlIDxnY3J5cHQuaD4KLWludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0K
LUVPRgotCi1pZiAkMSAtbyAuZ2NyeXB0IC5nY3J5cHQuYyAtbGdjcnlwdCAyPi9kZXYvbnVsbCA7
IHRoZW4KLSAgZWNobyAieWVzIgotZWxzZQotICBlY2hvICJubyIKLWZpCi0KLXJtIC1mIC5nY3J5
cHQqCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9NYWtl
ZmlsZQotLS0gYS90b29scy9jaGVjay9NYWtlZmlsZQlNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIg
KzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MjYgKzAsMCBAQAotWEVOX1JPT1QgPSAkKENVUkRJUikvLi4vLi4KLWluY2x1ZGUgJChYRU5fUk9P
VCkvdG9vbHMvUnVsZXMubWsKLQotIyBFeHBvcnQgdGhlIG5lY2Vzc2FyeSBlbnZpcm9ubWVudCB2
YXJpYWJsZXMgZm9yIHRoZSB0ZXN0cwotZXhwb3J0IFBZVEhPTgotZXhwb3J0IExJQlhFTkFQSV9C
SU5ESU5HUwotZXhwb3J0IENIRUNLX0lOQ0xVREVTCi1leHBvcnQgQ0hFQ0tfTElCCi1leHBvcnQg
Q09ORklHX1NZU1RFTV9MSUJBSU8KLQotLlBIT05ZOiBhbGwgaW5zdGFsbAotYWxsIGluc3RhbGw6
IGNoZWNrLWJ1aWxkCi0KLSMgQ2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBidWlsZGluZyBv
bi4KLS5QSE9OWTogY2hlY2stYnVpbGQKLWNoZWNrLWJ1aWxkOgotCS4vY2hrIGJ1aWxkCi0KLSMg
Q2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBpbnN0YWxsaW5nIG9uLgotLlBIT05ZOiBjaGVj
ay1pbnN0YWxsCi1jaGVjay1pbnN0YWxsOgotCS4vY2hrIGluc3RhbGwKLQotLlBIT05ZOiBjbGVh
bgotY2xlYW46Ci0JLi9jaGsgY2xlYW4KZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0
MTllIHRvb2xzL2NoZWNrL1JFQURNRQotLS0gYS90b29scy9jaGVjay9SRUFETUUJTW9uIEphbiAw
OSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDIwICswLDAgQEAKLUNoZWNrcyBmb3IgdGhlIHN1aXRhYmlsaXR5IG9m
IGEgbWFjaGluZSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuCi1UbyBjaGVjayBmb3IgYnVpbGQg
c3VpdGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgYnVpbGQKLQotVG8gY2hlY2sgZm9yIGlu
c3RhbGwgc3VpdGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgaW5zdGFsbAotCi1UaGUgY2hr
IHNjcmlwdCB3aWxsIHJ1biBjaGVja3MgaW4gdGhpcyBkaXJlY3RvcnkgYW5kIHByaW50Ci10aGUg
b25lcyB0aGF0IGZhaWxlZC4gSXQgcHJpbnRzIG5vdGhpbmcgaWYgY2hlY2tzIHN1Y2NlZWQuCi1U
aGUgY2hrIHNjcmlwdCBleGl0cyB3aXRoIDAgb24gc3VjY2VzcyBhbmQgMSBvbiBmYWlsdXJlLgot
Ci1UaGUgY2hrIHNjcmlwdCBydW5zIGV4ZWN1dGFibGUgZmlsZXMgaW4gdGhpcyBkaXJlY3Rvcnkg
d2hvc2UKLW5hbWVzIGJlZ2luIHdpdGggJ2NoZWNrXycuIEZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0st
QlVJTEQKLWFyZSBydW4gZm9yIHRoZSBidWlsZCBjaGVjaywgYW5kIGZpbGVzIGNvbnRhaW5pbmcg
Q0hFQ0stSU5TVEFMTAotYXJlIHJ1biBmb3IgdGhlIGluc3RhbGwgY2hlY2suCi0KLURldGFpbGVk
IG91dHB1dCBmcm9tIHRoZSBjaGVjayBzY3JpcHRzIGlzIGluIC5jaGtidWlsZCBmb3IgYnVpbGQK
LWFuZCAuY2hraW5zdGFsbCBmb3IgaW5zdGFsbC4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxl
CmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9jaGVja19i
cmN0bAotLS0gYS90b29scy9jaGVjay9jaGVja19icmN0bAlNb24gSmFuIDA5IDE2OjAxOjQ0IDIw
MTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNo
Ci0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9mYWlsIGJy
Y29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBicmN0bCA7OwotKikKLQlmYWlsICJ1bmtu
b3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9v
bHMvY2hlY2svY2hlY2tfY3J5cHRvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19jcnlwdG9f
bGliCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZy
ZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwIDs7Ci1lc2FjCi0KLWhhc19saWIgbGliY3J5
cHRvLnNvIHx8IGZhaWwgIm1pc3NpbmcgbGliY3J5cHRvLnNvIgpkaWZmIC1yIDViMjY3NmFjMTMy
MSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfY3VybAotLS0gYS90b29scy9jaGVj
ay9jaGVja19jdXJsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyAi
JExJQlhFTkFQSV9CSU5ESU5HUyIgIT0gInkiIF07IHRoZW4KLQllY2hvIC1uICJ1bnVzZWQsICIK
LQlleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIGN1cmwtY29uZmlnCi1jdXJsX2xpYnM9YGN1cmwt
Y29uZmlnIC0tbGlic2AgfHwgZmFpbCAiY3VybC1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3Rf
bGluayAkY3VybF9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciBjdXJsIGFy
ZSBtaXNzaW5nIgpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hl
Y2svY2hlY2tfaXByb3V0ZQotLS0gYS90b29scy9jaGVjay9jaGVja19pcHJvdXRlCU1vbiBKYW4g
MDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAot
Ci0uIC4vZnVuY3Muc2gKLQotUEFUSD0vc2JpbjokUEFUSAotCi1jYXNlICRPUyBpbgotT3BlbkJT
RHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBpZmNvbmZpZyA7OwotTGludXgpCi0JaGFz
X29yX2ZhaWwgaXAgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19kZXZl
bAotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwJTW9uIEphbiAwOSAxNjowMTo0
NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Mu
c2gKLQotaWYgWyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAg
IGV4aXQgMAotZmkKLWlmICEgaGFzX2hlYWRlciBsaWJhaW8uaCA7IHRoZW4KLSAgICBmYWlsICJj
YW4ndCBmaW5kIGxpYmFpbyBoZWFkZXJzLCBpbnN0YWxsIGxpYmFpbyBkZXZlbCBwYWNrYWdlIG9y
IHNldCBDT05GSUdfU1lTVEVNX0xJQkFJTz1uIgotZmkKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIg
NmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfbGliYWlvX2xpYglNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQot
aWYgWyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQg
MAotZmkKLWhhc19saWIgbGliYWlvLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGliYWlvIgpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNz
bF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCU1vbiBKYW4gMDkg
MTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMApAQCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4v
ZnVuY3Muc2gKLQotaGFzX2hlYWRlciBvcGVuc3NsL21kNS5oIHx8IGZhaWwgIm1pc3Npbmcgb3Bl
bnNzbCBoZWFkZXJzIgpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMv
Y2hlY2svY2hlY2tfcHl0aG9uCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbglNb24gSmFu
IDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENI
RUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVu
Ci0gIFBZVEhPTj1weXRob24KLWZpCi0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgc3lzCi1zeXMu
ZXhpdChzeXMudmVyc2lvbl9pbmZvWzBdIDwgMiBvciBzeXMudmVyc2lvbl9pbmZvWzFdIDwgMykK
LScgfHwgZmFpbCAibmVlZCBweXRob24gdmVyc2lvbiA+PSAyLjMiCmRpZmYgLXIgNWIyNjc2YWMx
MzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9jaGVja19weXRob25fZGV2ZWwKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX2RldmVsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiAr
MDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwx
NyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlm
IHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3JfZmFp
bCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBvcy5wYXRoLCBzeXMKLWZvciBw
IGluIHN5cy5wYXRoOgotCWlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIp
OgotCQlzeXMuZXhpdCgwKQotc3lzLmV4aXQoMSkKLScgfHwgZmFpbCAiY2FuJ3QgZmluZCBweXRo
b24gZGV2ZWwgZmlsZXMiCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29s
cy9jaGVjay9jaGVja19weXRob25feG1sCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94
bWwJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgot
ICBQWVRIT049cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAt
YyAnaW1wb3J0IHhtbC5kb20ubWluaWRvbScgMj4vZGV2L251bGwgfHwgXAotZmFpbCAiY2FuJ3Qg
aW1wb3J0IHhtbC5kb20ubWluaWRvbSIKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0
MTllIHRvb2xzL2NoZWNrL2NoZWNrX3VkZXYKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdWRldglN
b24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlO
U1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVl
QlNEKQotCWhhc19vcl9mYWlsIHZuY29uZmlnCi0JOzsKLUxpbnV4KQotCWhhcyAvc2Jpbi91ZGV2
YWRtICYmIFwKLQkJdWRldnZlcj1gL3NiaW4vdWRldmFkbSBpbmZvIC1WIHwgYXdrICd7cHJpbnQg
JE5GfSdgCi0JWyAteiAiJHVkZXZ2ZXIiIF0gJiYgaGFzX29yX2ZhaWwgdWRldmluZm8gJiYgXAot
CQl1ZGV2dmVyPWB1ZGV2aW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgIiR1ZGV2dmVy
IiAtZ2UgNTkgXSAyPi9kZXYvbnVsbCB8fCBcCi0JCWhhcyBob3RwbHVnIHx8IFwKLQkJZmFpbCAi
dWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3IgbGF0ZXIiCi0JOzsKLSop
Ci0JZmFpbCAidW5rbm93biBPUyIKLQk7OwotZXNhYwpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2
ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAotLS0gYS90b29scy9jaGVj
ay9jaGVja191dWlkX2RldmVsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw3ICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB1dWlk
LmggfHwgXAotaGFzX2hlYWRlciB1dWlkL3V1aWQuaCB8fCBmYWlsICJtaXNzaW5nIHV1aWQgaGVh
ZGVycyAocGFja2FnZSB1dWlkLWRldikiCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdj
NDE5ZSB0b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
eDExX2RldmVsCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciBYMTEva2V5c3ltZGVm
LmggfHwgXAotaGFzX2hlYWRlciAvdXNyL1gxMVI2L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8
IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNy9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi13
YXJuaW5nICJjYW4ndCBmaW5kIFgxMSBoZWFkZXJzIgpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2
ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tfeGdldHRleHQKLS0tIGEvdG9vbHMvY2hlY2sv
Y2hlY2tfeGdldHRleHQJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmlu
L3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfb3JfZmFpbCB4Z2V0dGV4
dApkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svY2hlY2tf
eG1sMgotLS0gYS90b29scy9jaGVjay9jaGVja194bWwyCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAx
MiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSwxNCArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0u
IC4vZnVuY3Muc2gKLQotaWYgWyAhICIkTElCWEVOQVBJX0JJTkRJTkdTIiA9ICJ5IiBdCi10aGVu
Ci0gICAgZWNobyAtbiAidW51c2VkLCAiCi0gICAgZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCB4
bWwyLWNvbmZpZwoteG1sMl9saWJzPWB4bWwyLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgInhtbDIt
Y29uZmlnIC0tbGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJHhtbDJfbGlicyB8fCBmYWlsICJkZXBl
bmRlbmN5IGxpYnJhcmllcyBmb3IgeG1sMiBhcmUgbWlzc2luZyIKZGlmZiAtciA1YjI2NzZhYzEz
MjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwKLS0tIGEvdG9v
bHMvY2hlY2svY2hlY2tfeWFqbF9kZXZlbAlNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAxMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOCArMCww
IEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFk
ZXIgeWFqbC95YWpsX3BhcnNlLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfcGFyc2Uu
aCIKLWhhc19oZWFkZXIgeWFqbC95YWpsX2dlbi5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95
YWpsX2dlbi5oIgotaGFzX2xpYiBsaWJ5YWpsLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFq
bC5zbyIKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2No
ZWNrX3lhamxfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfbGliCU1vbiBKYW4gMDkg
MTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMApAQCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1J
TlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfbGliIGxpYnlhamwuc28uMSB8fCBmYWlsICJj
YW4ndCBmaW5kIGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1y
IDZmZGUwMTdjNDE5ZSB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3psaWJfZGV2ZWwJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAot
IyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHps
aWIuaCB8fCBmYWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA1YjI2NzZhYzEz
MjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX3psaWJfbGliCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gK
LQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVz
YWMKLQotaGFzX2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9j
aGVjay9jaGsJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAot
Ci1mdW5jX3VzYWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVp
bGR8aW5zdGFsbHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5
IGZvciBYZW4gYnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ss
IDEgaWYgbm90LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVt
b3ZlcyBnZW5lcmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmlu
Oi91c3Ivc2JpbgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9
ICJTdW5PUyIgXTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQot
ICAgICAgICBjaGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAg
ICAgICAgY2hlY2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAg
ICAgIGV4aXQgMAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAg
ICAgOzsKLWVzYWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1m
b3IgZiBpbiBjaGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAg
ICAgICAgY29udGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7
OwotICAgIGVzYWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUK
LSAgICBmaQotICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNv
bnRpbnVlCi0gICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYg
Mj4mMSA7IHRoZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEK
LSAgICBmaQotZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2
ZmRlMDE3YzQxOWUgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Mu
c2gJTW9uIEphbiAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2Ft
ZSBhcyB3aGljaCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7
Ci0JaWYgWyAteiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAi
Ci0JCXJldHVybiAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBz
dWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToK
LQlmb3IgcCBpbiAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBd
OyB0aGVuCi0JCQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlm
aQotCWRvbmUKLQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIg
Pi9kZXYvbnVsbCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewot
CWNoZWNrX3N5c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkq
KQotCQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJ
CXJldHVybiAwCi0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJ
aWYgWyAtciAiJENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAw
Ci0JCQlmaQotCQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigp
IHsKLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50
IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRI
ICAgICAgICAjIGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIK
LQotCSMgVGhpcyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0
YWxsZWQgYnV0Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3
b24ndCB3b3JrLgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1Qv
ZXRjL2xkLnNvLmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcg
LXIgXCIkQ1JPU1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBm
YWxsIHRocm91Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsg
IiR7T1N9IiA9ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09U
Ky1yICIkQ1JPU1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkK
LQlpZiBbICIke09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8
IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVz
dF9saW5rKCkgewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0J
dW5zZXQgdG1wZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0J
dG1wZmlsZT1gbWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rl
di9udWxsIDI+JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2Vk
IGNvbW1vbmx5IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElM
RSIgXSAmJiByZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQll
Y2hvICJwbGVhc2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0
dXJuIDEKLQlmaQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8g
Im5vIHN5cy1yb290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQot
fQotCi13YXJuaW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlM
RUQkeyorOiAkKn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1l
ICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA1YjI2NzZhYzEzMjEg
LXIgNmZkZTAxN2M0MTllIHRvb2xzL2NvbmZpZy5ndWVzcwotLS0gL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuZ3Vlc3MJVHVlIEphbiAx
MCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTUwMiBAQAorIyEgL2Jpbi9zaAorIyBB
dHRlbXB0IHRvIGd1ZXNzIGEgY2Fub25pY2FsIHN5c3RlbSBuYW1lLgorIyAgIENvcHlyaWdodCAo
QykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwKKyMgICAy
MDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5
LCAyMDEwCisjICAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3RpbWVzdGFtcD0n
MjAwOS0xMi0zMCcKKworIyBUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAorIyB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAo
YXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMg
ZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJ
VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YK
KyMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg
U2VlIHRoZSBHTlUKKyMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgor
IworIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQ
dWJsaWMgTGljZW5zZQorIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0
byB0aGUgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJl
ZXQgLSBGaWZ0aCBGbG9vciwgQm9zdG9uLCBNQQorIyAwMjExMC0xMzAxLCBVU0EuCisjCisjIEFz
IGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBp
ZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBj
b250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwg
eW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0
aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KKworCisjIE9yaWdpbmFs
bHkgd3JpdHRlbiBieSBQZXIgQm90aG5lci4gIFBsZWFzZSBzZW5kIHBhdGNoZXMgKGNvbnRleHQK
KyMgZGlmZiBmb3JtYXQpIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPiBhbmQgaW5jbHVkZSBh
IENoYW5nZUxvZworIyBlbnRyeS4KKyMKKyMgVGhpcyBzY3JpcHQgYXR0ZW1wdHMgdG8gZ3Vlc3Mg
YSBjYW5vbmljYWwgc3lzdGVtIG5hbWUgc2ltaWxhciB0bworIyBjb25maWcuc3ViLiAgSWYgaXQg
c3VjY2VlZHMsIGl0IHByaW50cyB0aGUgc3lzdGVtIG5hbWUgb24gc3Rkb3V0LCBhbmQKKyMgZXhp
dHMgd2l0aCAwLiAgT3RoZXJ3aXNlLCBpdCBleGl0cyB3aXRoIDEuCisjCisjIFlvdSBjYW4gZ2V0
IHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGlzIHNjcmlwdCBmcm9tOgorIyBodHRwOi8vZ2l0LnNh
dmFubmFoLmdudS5vcmcvZ2l0d2ViLz9wPWNvbmZpZy5naXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmln
Lmd1ZXNzO2hiPUhFQUQKKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3Vz
YWdlPSJcCitVc2FnZTogJDAgW09QVElPTl0KKworT3V0cHV0IHRoZSBjb25maWd1cmF0aW9uIG5h
bWUgb2YgdGhlIHN5c3RlbSBcYCRtZScgaXMgcnVuIG9uLgorCitPcGVyYXRpb24gbW9kZXM6Cisg
IC1oLCAtLWhlbHAgICAgICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtdCwgLS10
aW1lLXN0YW1wICAgcHJpbnQgZGF0ZSBvZiBsYXN0IG1vZGlmaWNhdGlvbiwgdGhlbiBleGl0Cisg
IC12LCAtLXZlcnNpb24gICAgICBwcmludCB2ZXJzaW9uIG51bWJlciwgdGhlbiBleGl0CisKK1Jl
cG9ydCBidWdzIGFuZCBwYXRjaGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4iCisKK3Zl
cnNpb249IlwKK0dOVSBjb25maWcuZ3Vlc3MgKCR0aW1lc3RhbXApCisKK09yaWdpbmFsbHkgd3Jp
dHRlbiBieSBQZXIgQm90aG5lci4KK0NvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5
NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwgMjAwMCwKKzIwMDEsIDIwMDIsIDIwMDMsIDIwMDQs
IDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDksIDIwMTAgRnJlZQorU29mdHdhcmUgRm91bmRh
dGlvbiwgSW5jLgorCitUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUgc291cmNlIGZvciBj
b3B5aW5nIGNvbmRpdGlvbnMuICBUaGVyZSBpcyBOTword2FycmFudHk7IG5vdCBldmVuIGZvciBN
RVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIgorCito
ZWxwPSIKK1RyeSBcYCRtZSAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uLiIKKworIyBQYXJz
ZSBjb21tYW5kIGxpbmUKK3doaWxlIHRlc3QgJCMgLWd0IDAgOyBkbworICBjYXNlICQxIGluCisg
ICAgLS10aW1lLXN0YW1wIHwgLS10aW1lKiB8IC10ICkKKyAgICAgICBlY2hvICIkdGltZXN0YW1w
IiA7IGV4aXQgOzsKKyAgICAtLXZlcnNpb24gfCAtdiApCisgICAgICAgZWNobyAiJHZlcnNpb24i
IDsgZXhpdCA7OworICAgIC0taGVscCB8IC0taCogfCAtaCApCisgICAgICAgZWNobyAiJHVzYWdl
IjsgZXhpdCA7OworICAgIC0tICkgICAgICMgU3RvcCBvcHRpb24gcHJvY2Vzc2luZworICAgICAg
IHNoaWZ0OyBicmVhayA7OworICAgIC0gKQkjIFVzZSBzdGRpbiBhcyBpbnB1dC4KKyAgICAgICBi
cmVhayA7OworICAgIC0qICkKKyAgICAgICBlY2hvICIkbWU6IGludmFsaWQgb3B0aW9uICQxJGhl
bHAiID4mMgorICAgICAgIGV4aXQgMSA7OworICAgICogKQorICAgICAgIGJyZWFrIDs7CisgIGVz
YWMKK2RvbmUKKworaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgIGVjaG8gIiRtZTogdG9vIG1hbnkg
YXJndW1lbnRzJGhlbHAiID4mMgorICBleGl0IDEKK2ZpCisKK3RyYXAgJ2V4aXQgMScgMSAyIDE1
CisKKyMgQ0NfRk9SX0JVSUxEIC0tIGNvbXBpbGVyIHVzZWQgYnkgdGhpcyBzY3JpcHQuIE5vdGUg
dGhhdCB0aGUgdXNlIG9mIGEKKyMgY29tcGlsZXIgdG8gYWlkIGluIHN5c3RlbSBkZXRlY3Rpb24g
aXMgZGlzY291cmFnZWQgYXMgaXQgcmVxdWlyZXMKKyMgdGVtcG9yYXJ5IGZpbGVzIHRvIGJlIGNy
ZWF0ZWQgYW5kLCBhcyB5b3UgY2FuIHNlZSBiZWxvdywgaXQgaXMgYQorIyBoZWFkYWNoZSB0byBk
ZWFsIHdpdGggaW4gYSBwb3J0YWJsZSBmYXNoaW9uLgorCisjIEhpc3RvcmljYWxseSwgYENDX0ZP
Ul9CVUlMRCcgdXNlZCB0byBiZSBuYW1lZCBgSE9TVF9DQycuIFdlIHN0aWxsCisjIHVzZSBgSE9T
VF9DQycgaWYgZGVmaW5lZCwgYnV0IGl0IGlzIGRlcHJlY2F0ZWQuCisKKyMgUG9ydGFibGUgdG1w
IGRpcmVjdG9yeSBjcmVhdGlvbiBpbnNwaXJlZCBieSB0aGUgQXV0b2NvbmYgdGVhbS4KKworc2V0
X2NjX2Zvcl9idWlsZD0nCit0cmFwICJleGl0Y29kZT1cJD87IChybSAtZiBcJHRtcGZpbGVzIDI+
L2Rldi9udWxsOyBybWRpciBcJHRtcCAyPi9kZXYvbnVsbCkgJiYgZXhpdCBcJGV4aXRjb2RlIiAw
IDsKK3RyYXAgInJtIC1mIFwkdG1wZmlsZXMgMj4vZGV2L251bGw7IHJtZGlyIFwkdG1wIDI+L2Rl
di9udWxsOyBleGl0IDEiIDEgMiAxMyAxNSA7Cis6ICR7VE1QRElSPS90bXB9IDsKKyB7IHRtcD1g
KHVtYXNrIDA3NyAmJiBta3RlbXAgLWQgIiRUTVBESVIvY2dYWFhYWFgiKSAyPi9kZXYvbnVsbGAg
JiYgdGVzdCAtbiAiJHRtcCIgJiYgdGVzdCAtZCAiJHRtcCIgOyB9IHx8CisgeyB0ZXN0IC1uICIk
UkFORE9NIiAmJiB0bXA9JFRNUERJUi9jZyQkLSRSQU5ET00gJiYgKHVtYXNrIDA3NyAmJiBta2Rp
ciAkdG1wKSA7IH0gfHwKKyB7IHRtcD0kVE1QRElSL2NnLSQkICYmICh1bWFzayAwNzcgJiYgbWtk
aXIgJHRtcCkgJiYgZWNobyAiV2FybmluZzogY3JlYXRpbmcgaW5zZWN1cmUgdGVtcCBkaXJlY3Rv
cnkiID4mMiA7IH0gfHwKKyB7IGVjaG8gIiRtZTogY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFyeSBk
aXJlY3RvcnkgaW4gJFRNUERJUiIgPiYyIDsgZXhpdCAxIDsgfSA7CitkdW1teT0kdG1wL2R1bW15
IDsKK3RtcGZpbGVzPSIkZHVtbXkuYyAkZHVtbXkubyAkZHVtbXkucmVsICRkdW1teSIgOworY2Fz
ZSAkQ0NfRk9SX0JVSUxELCRIT1NUX0NDLCRDQyBpbgorICwsKSAgICBlY2hvICJpbnQgeDsiID4g
JGR1bW15LmMgOworCWZvciBjIGluIGNjIGdjYyBjODkgYzk5IDsgZG8KKwkgIGlmICgkYyAtYyAt
byAkZHVtbXkubyAkZHVtbXkuYykgPi9kZXYvbnVsbCAyPiYxIDsgdGhlbgorCSAgICAgQ0NfRk9S
X0JVSUxEPSIkYyI7IGJyZWFrIDsKKwkgIGZpIDsKKwlkb25lIDsKKwlpZiB0ZXN0IHgiJENDX0ZP
Ul9CVUlMRCIgPSB4IDsgdGhlbgorCSAgQ0NfRk9SX0JVSUxEPW5vX2NvbXBpbGVyX2ZvdW5kIDsK
KwlmaQorCTs7CisgLCwqKSAgIENDX0ZPUl9CVUlMRD0kQ0MgOzsKKyAsKiwqKSAgQ0NfRk9SX0JV
SUxEPSRIT1NUX0NDIDs7Citlc2FjIDsgc2V0X2NjX2Zvcl9idWlsZD0gOycKKworIyBUaGlzIGlz
IG5lZWRlZCB0byBmaW5kIHVuYW1lIG9uIGEgUHlyYW1pZCBPU3ggd2hlbiBydW4gaW4gdGhlIEJT
RCB1bml2ZXJzZS4KKyMgKGdoYXppQG5vYy5ydXRnZXJzLmVkdSAxOTk0LTA4LTI0KQoraWYgKHRl
c3QgLWYgLy5hdHRiaW4vdW5hbWUpID4vZGV2L251bGwgMj4mMSA7IHRoZW4KKwlQQVRIPSRQQVRI
Oi8uYXR0YmluIDsgZXhwb3J0IFBBVEgKK2ZpCisKK1VOQU1FX01BQ0hJTkU9YCh1bmFtZSAtbSkg
Mj4vZGV2L251bGxgIHx8IFVOQU1FX01BQ0hJTkU9dW5rbm93bgorVU5BTUVfUkVMRUFTRT1gKHVu
YW1lIC1yKSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfUkVMRUFTRT11bmtub3duCitVTkFNRV9TWVNU
RU09YCh1bmFtZSAtcykgMj4vZGV2L251bGxgICB8fCBVTkFNRV9TWVNURU09dW5rbm93bgorVU5B
TUVfVkVSU0lPTj1gKHVuYW1lIC12KSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfVkVSU0lPTj11bmtu
b3duCisKKyMgTm90ZTogb3JkZXIgaXMgc2lnbmlmaWNhbnQgLSB0aGUgY2FzZSBicmFuY2hlcyBh
cmUgbm90IGV4Y2x1c2l2ZS4KKworY2FzZSAiJHtVTkFNRV9NQUNISU5FfToke1VOQU1FX1NZU1RF
TX06JHtVTkFNRV9SRUxFQVNFfToke1VOQU1FX1ZFUlNJT059IiBpbgorICAgICo6TmV0QlNEOio6
KikKKwkjIE5ldEJTRCAobmJzZCkgdGFyZ2V0cyBzaG91bGQgKHdoZXJlIGFwcGxpY2FibGUpIG1h
dGNoIG9uZSBvcgorCSMgbW9yZSBvZiB0aGUgdHVwcGxlczogKi0qLW5ldGJzZGVsZiosICotKi1u
ZXRic2Rhb3V0KiwKKwkjICotKi1uZXRic2RlY29mZiogYW5kICotKi1uZXRic2QqLiAgRm9yIHRh
cmdldHMgdGhhdCByZWNlbnRseQorCSMgc3dpdGNoZWQgdG8gRUxGLCAqLSotbmV0YnNkKiB3b3Vs
ZCBzZWxlY3QgdGhlIG9sZAorCSMgb2JqZWN0IGZpbGUgZm9ybWF0LiAgVGhpcyBwcm92aWRlcyBi
b3RoIGZvcndhcmQKKwkjIGNvbXBhdGliaWxpdHkgYW5kIGEgY29uc2lzdGVudCBtZWNoYW5pc20g
Zm9yIHNlbGVjdGluZyB0aGUKKwkjIG9iamVjdCBmaWxlIGZvcm1hdC4KKwkjCisJIyBOb3RlOiBO
ZXRCU0QgZG9lc24ndCBwYXJ0aWN1bGFybHkgY2FyZSBhYm91dCB0aGUgdmVuZG9yCisJIyBwb3J0
aW9uIG9mIHRoZSBuYW1lLiAgV2UgYWx3YXlzIHNldCBpdCB0byAidW5rbm93biIuCisJc3lzY3Rs
PSJzeXNjdGwgLW4gaHcubWFjaGluZV9hcmNoIgorCVVOQU1FX01BQ0hJTkVfQVJDSD1gKC9zYmlu
LyRzeXNjdGwgMj4vZGV2L251bGwgfHwgXAorCSAgICAvdXNyL3NiaW4vJHN5c2N0bCAyPi9kZXYv
bnVsbCB8fCBlY2hvIHVua25vd24pYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORV9BUkNIfSIgaW4K
KwkgICAgYXJtZWIpIG1hY2hpbmU9YXJtZWItdW5rbm93biA7OworCSAgICBhcm0qKSBtYWNoaW5l
PWFybS11bmtub3duIDs7CisJICAgIHNoM2VsKSBtYWNoaW5lPXNobC11bmtub3duIDs7CisJICAg
IHNoM2ViKSBtYWNoaW5lPXNoLXVua25vd24gOzsKKwkgICAgc2g1ZWwpIG1hY2hpbmU9c2g1bGUt
dW5rbm93biA7OworCSAgICAqKSBtYWNoaW5lPSR7VU5BTUVfTUFDSElORV9BUkNIfS11bmtub3du
IDs7CisJZXNhYworCSMgVGhlIE9wZXJhdGluZyBTeXN0ZW0gaW5jbHVkaW5nIG9iamVjdCBmb3Jt
YXQsIGlmIGl0IGhhcyBzd2l0Y2hlZAorCSMgdG8gRUxGIHJlY2VudGx5LCBvciB3aWxsIGluIHRo
ZSBmdXR1cmUuCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FX0FSQ0h9IiBpbgorCSAgICBhcm0qfGkz
ODZ8bTY4a3xuczMya3xzaDMqfHNwYXJjfHZheCkKKwkJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAor
CQlpZiBlY2hvIF9fRUxGX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwgXAorCQkJ
fCBncmVwIC1xIF9fRUxGX18KKwkJdGhlbgorCQkgICAgIyBPbmNlIGFsbCB1dGlsaXRpZXMgY2Fu
IGJlIEVDT0ZGIChuZXRic2RlY29mZikgb3IgYS5vdXQgKG5ldGJzZGFvdXQpLgorCQkgICAgIyBS
ZXR1cm4gbmV0YnNkIGZvciBlaXRoZXIuICBGSVg/CisJCSAgICBvcz1uZXRic2QKKwkJZWxzZQor
CQkgICAgb3M9bmV0YnNkZWxmCisJCWZpCisJCTs7CisJICAgICopCisJICAgICAgICBvcz1uZXRi
c2QKKwkJOzsKKwllc2FjCisJIyBUaGUgT1MgcmVsZWFzZQorCSMgRGViaWFuIEdOVS9OZXRCU0Qg
bWFjaGluZXMgaGF2ZSBhIGRpZmZlcmVudCB1c2VybGFuZCwgYW5kCisJIyB0aHVzLCBuZWVkIGEg
ZGlzdGluY3QgdHJpcGxldC4gSG93ZXZlciwgdGhleSBkbyBub3QgbmVlZAorCSMga2VybmVsIHZl
cnNpb24gaW5mb3JtYXRpb24sIHNvIGl0IGNhbiBiZSByZXBsYWNlZCB3aXRoIGEKKwkjIHN1aXRh
YmxlIHRhZywgaW4gdGhlIHN0eWxlIG9mIGxpbnV4LWdudS4KKwljYXNlICIke1VOQU1FX1ZFUlNJ
T059IiBpbgorCSAgICBEZWJpYW4qKQorCQlyZWxlYXNlPSctZ251JworCQk7OworCSAgICAqKQor
CQlyZWxlYXNlPWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1stX10uKi9cLi8nYAor
CQk7OworCWVzYWMKKwkjIFNpbmNlIENQVV9UWVBFLU1BTlVGQUNUVVJFUi1LRVJORUwtT1BFUkFU
SU5HX1NZU1RFTToKKwkjIGNvbnRhaW5zIHJlZHVuZGFudCBpbmZvcm1hdGlvbiwgdGhlIHNob3J0
ZXIgZm9ybToKKwkjIENQVV9UWVBFLU1BTlVGQUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNIGlzIHVz
ZWQuCisJZWNobyAiJHttYWNoaW5lfS0ke29zfSR7cmVsZWFzZX0iCisJZXhpdCA7OworICAgICo6
T3BlbkJTRDoqOiopCisJVU5BTUVfTUFDSElORV9BUkNIPWBhcmNoIHwgc2VkICdzL09wZW5CU0Qu
Ly8nYAorCWVjaG8gJHtVTkFNRV9NQUNISU5FX0FSQ0h9LXVua25vd24tb3BlbmJzZCR7VU5BTUVf
UkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpla2tvQlNEOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1la2tvYnNkJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlNv
bGlkQlNEOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zb2xpZGJzZCR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgbWFjcHBjOk1pckJTRDoqOiopCisJZWNobyBwb3dl
cnBjLXVua25vd24tbWlyYnNkJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOk1pckJT
RDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbWlyYnNkJHtVTkFNRV9SRUxF
QVNFfQorCWV4aXQgOzsKKyAgICBhbHBoYTpPU0YxOio6KikKKwljYXNlICRVTkFNRV9SRUxFQVNF
IGluCisJKjQuMCkKKwkJVU5BTUVfUkVMRUFTRT1gL3Vzci9zYmluL3NpemVyIC12IHwgYXdrICd7
cHJpbnQgJDN9J2AKKwkJOzsKKwkqNS4qKQorCSAgICAgICAgVU5BTUVfUkVMRUFTRT1gL3Vzci9z
YmluL3NpemVyIC12IHwgYXdrICd7cHJpbnQgJDR9J2AKKwkJOzsKKwllc2FjCisJIyBBY2NvcmRp
bmcgdG8gQ29tcGFxLCAvdXNyL3NiaW4vcHNyaW5mbyBoYXMgYmVlbiBhdmFpbGFibGUgb24KKwkj
IE9TRi8xIGFuZCBUcnU2NCBzeXN0ZW1zIHByb2R1Y2VkIHNpbmNlIDE5OTUuICBJIGhvcGUgdGhh
dAorCSMgY292ZXJzIG1vc3Qgc3lzdGVtcyBydW5uaW5nIHRvZGF5LiAgVGhpcyBjb2RlIHBpcGVz
IHRoZSBDUFUKKwkjIHR5cGVzIHRocm91Z2ggaGVhZCAtbiAxLCBzbyB3ZSBvbmx5IGRldGVjdCB0
aGUgdHlwZSBvZiBDUFUgMC4KKwlBTFBIQV9DUFVfVFlQRT1gL3Vzci9zYmluL3BzcmluZm8gLXYg
fCBzZWQgLW4gLWUgJ3MvXiAgVGhlIGFscGhhIFwoLipcKSBwcm9jZXNzb3IuKiQvXDEvcCcgfCBo
ZWFkIC1uIDFgCisJY2FzZSAiJEFMUEhBX0NQVV9UWVBFIiBpbgorCSAgICAiRVY0ICgyMTA2NCki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAgIkVWNC41ICgyMTA2NCkiKQorCQlV
TkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAgIkxDQTQgKDIxMDY2LzIxMDY4KSIpCisJCVVO
QU1FX01BQ0hJTkU9ImFscGhhIiA7OworCSAgICAiRVY1ICgyMTE2NCkiKQorCQlVTkFNRV9NQUNI
SU5FPSJhbHBoYWV2NSIgOzsKKwkgICAgIkVWNS42ICgyMTE2NEEpIikKKwkJVU5BTUVfTUFDSElO
RT0iYWxwaGFldjU2IiA7OworCSAgICAiRVY1LjYgKDIxMTY0UEMpIikKKwkJVU5BTUVfTUFDSElO
RT0iYWxwaGFwY2E1NiIgOzsKKwkgICAgIkVWNS43ICgyMTE2NFBDKSIpCisJCVVOQU1FX01BQ0hJ
TkU9ImFscGhhcGNhNTciIDs7CisJICAgICJFVjYgKDIxMjY0KSIpCisJCVVOQU1FX01BQ0hJTkU9
ImFscGhhZXY2IiA7OworCSAgICAiRVY2LjcgKDIxMjY0QSkiKQorCQlVTkFNRV9NQUNISU5FPSJh
bHBoYWV2NjciIDs7CisJICAgICJFVjYuOENCICgyMTI2NEMpIikKKwkJVU5BTUVfTUFDSElORT0i
YWxwaGFldjY4IiA7OworCSAgICAiRVY2LjhBTCAoMjEyNjRCKSIpCisJCVVOQU1FX01BQ0hJTkU9
ImFscGhhZXY2OCIgOzsKKwkgICAgIkVWNi44Q1ggKDIxMjY0RCkiKQorCQlVTkFNRV9NQUNISU5F
PSJhbHBoYWV2NjgiIDs7CisJICAgICJFVjYuOUEgKDIxMjY0L0VWNjlBKSIpCisJCVVOQU1FX01B
Q0hJTkU9ImFscGhhZXY2OSIgOzsKKwkgICAgIkVWNyAoMjEzNjQpIikKKwkJVU5BTUVfTUFDSElO
RT0iYWxwaGFldjciIDs7CisJICAgICJFVjcuOSAoMjEzNjRBKSIpCisJCVVOQU1FX01BQ0hJTkU9
ImFscGhhZXY3OSIgOzsKKwllc2FjCisJIyBBIFBuLm4gdmVyc2lvbiBpcyBhIHBhdGNoZWQgdmVy
c2lvbi4KKwkjIEEgVm4ubiB2ZXJzaW9uIGlzIGEgcmVsZWFzZWQgdmVyc2lvbi4KKwkjIEEgVG4u
biB2ZXJzaW9uIGlzIGEgcmVsZWFzZWQgZmllbGQgdGVzdCB2ZXJzaW9uLgorCSMgQSBYbi5uIHZl
cnNpb24gaXMgYW4gdW5yZWxlYXNlZCBleHBlcmltZW50YWwgYmFzZWxldmVsLgorCSMgMS4yIHVz
ZXMgIjEuMiIgZm9yIHVuYW1lIC1yLgorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1kZWMtb3NmYGVj
aG8gJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9eW1BWVFhdLy8nIHwgdHIgJ0FCQ0RFRkdI
SUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonYAorCWV4aXQg
OzsKKyAgICBBbHBoYVwgKjpXaW5kb3dzX05UKjoqKQorCSMgSG93IGRvIHdlIGtub3cgaXQncyBJ
bnRlcml4IHJhdGhlciB0aGFuIHRoZSBnZW5lcmljIFBPU0lYIHN1YnN5c3RlbT8KKwkjIFNob3Vs
ZCB3ZSBjaGFuZ2UgVU5BTUVfTUFDSElORSBiYXNlZCBvbiB0aGUgb3V0cHV0IG9mIHVuYW1lIGlu
c3RlYWQKKwkjIG9mIHRoZSBzcGVjaWZpYyBBbHBoYSBtb2RlbD8KKwllY2hvIGFscGhhLXBjLWlu
dGVyaXgKKwlleGl0IDs7CisgICAgMjEwNjQ6V2luZG93c19OVDo1MDozKQorCWVjaG8gYWxwaGEt
ZGVjLXdpbm50My41CisJZXhpdCA7OworICAgIEFtaWdhKjpVTklYX1N5c3RlbV9WOjQuMDoqKQor
CWVjaG8gbTY4ay11bmtub3duLXN5c3Y0CisJZXhpdCA7OworICAgICo6W0FhXW1pZ2FbT29dW1Nz
XToqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tYW1pZ2FvcworCWV4aXQgOzsK
KyAgICAqOltNbV1vcnBoW09vXVtTc106KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtu
b3duLW1vcnBob3MKKwlleGl0IDs7CisgICAgKjpPUy8zOTA6KjoqKQorCWVjaG8gaTM3MC1pYm0t
b3BlbmVkaXRpb24KKwlleGl0IDs7CisgICAgKjp6L1ZNOio6KikKKwllY2hvIHMzOTAtaWJtLXp2
bW9lCisJZXhpdCA7OworICAgICo6T1M0MDA6KjoqKQorICAgICAgICBlY2hvIHBvd2VycGMtaWJt
LW9zNDAwCisJZXhpdCA7OworICAgIGFybTpSSVNDKjoxLlswMTJdKjoqfGFybTpyaXNjaXg6MS5b
MDEyXSo6KikKKwllY2hvIGFybS1hY29ybi1yaXNjaXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGFybTpyaXNjb3M6KjoqfGFybTpSSVNDT1M6KjoqKQorCWVjaG8gYXJtLXVua25vd24t
cmlzY29zCisJZXhpdCA7OworICAgIFNSMj8wMTpISS1VWC9NUFA6KjoqIHwgU1I4MDAwOkhJLVVY
L01QUDoqOiopCisJZWNobyBocHBhMS4xLWhpdGFjaGktaGl1eG1wcAorCWV4aXQgOzsKKyAgICBQ
eXJhbWlkKjpPU3gqOio6KiB8IE1JUyo6T1N4KjoqOiogfCBNSVMqOlNNUF9EQy1PU3gqOio6KikK
KwkjIGFrZWVAd3BkaXMwMy53cGFmYi5hZi5taWwgKEVhcmxlIEYuIEFrZSkgY29udHJpYnV0ZWQg
TUlTIGFuZCBOSUxFLgorCWlmIHRlc3QgImAoL2Jpbi91bml2ZXJzZSkgMj4vZGV2L251bGxgIiA9
IGF0dCA7IHRoZW4KKwkJZWNobyBweXJhbWlkLXB5cmFtaWQtc3lzdjMKKwllbHNlCisJCWVjaG8g
cHlyYW1pZC1weXJhbWlkLWJzZAorCWZpCisJZXhpdCA7OworICAgIE5JTEUqOio6KjpkY29zeCkK
KwllY2hvIHB5cmFtaWQtcHlyYW1pZC1zdnI0CisJZXhpdCA7OworICAgIERSUz82MDAwOnVuaXg6
NC4wOjYqKQorCWVjaG8gc3BhcmMtaWNsLW54NgorCWV4aXQgOzsKKyAgICBEUlM/NjAwMDpVTklY
X1NWOjQuMio6NyogfCBEUlM/NjAwMDppc2lzOjQuMio6NyopCisJY2FzZSBgL3Vzci9iaW4vdW5h
bWUgLXBgIGluCisJICAgIHNwYXJjKSBlY2hvIHNwYXJjLWljbC1ueDc7IGV4aXQgOzsKKwllc2Fj
IDs7CisgICAgczM5MHg6U3VuT1M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1pYm0tc29s
YXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7
CisgICAgc3VuNEg6U3VuT1M6NS4qOiopCisJZWNobyBzcGFyYy1oYWwtc29sYXJpczJgZWNobyAk
e1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgc3VuNCo6
U3VuT1M6NS4qOiogfCB0YWRwb2xlKjpTdW5PUzo1Lio6KikKKwllY2hvIHNwYXJjLXN1bi1zb2xh
cmlzMmBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsK
KyAgICBpODZwYzpBdXJvcmFVWDo1Lio6KiB8IGk4NnhlbjpBdXJvcmFVWDo1Lio6KikKKwllY2hv
IGkzODYtcGMtYXVyb3JhdXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIGk4NnBjOlN1
bk9TOjUuKjoqIHwgaTg2eGVuOlN1bk9TOjUuKjoqKQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQK
KwlTVU5fQVJDSD0iaTM4NiIKKwkjIElmIHRoZXJlIGlzIGEgY29tcGlsZXIsIHNlZSBpZiBpdCBp
cyBjb25maWd1cmVkIGZvciA2NC1iaXQgb2JqZWN0cy4KKwkjIE5vdGUgdGhhdCB0aGUgU3VuIGNj
IGRvZXMgbm90IHR1cm4gX19MUDY0X18gaW50byAxIGxpa2UgZ2NjIGRvZXMuCisJIyBUaGlzIHRl
c3Qgd29ya3MgZm9yIGJvdGggY29tcGlsZXJzLgorCWlmIFsgIiRDQ19GT1JfQlVJTEQiICE9ICdu
b19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCSAgICBpZiAoZWNobyAnI2lmZGVmIF9fYW1kNjQn
OyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicpIHwgXAorCQkoQ0NPUFRTPSAkQ0Nf
Rk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwgXAorCQlncmVwIElTXzY0QklUX0FSQ0ggPi9k
ZXYvbnVsbAorCSAgICB0aGVuCisJCVNVTl9BUkNIPSJ4ODZfNjQiCisJICAgIGZpCisJZmkKKwll
Y2hvICR7U1VOX0FSQ0h9LXBjLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjYqOiopCisJIyBBY2NvcmRp
bmcgdG8gY29uZmlnLnN1YiwgdGhpcyBpcyB0aGUgcHJvcGVyIHdheSB0byBjYW5vbmljYWxpemUK
KwkjIFN1bk9TNi4gIEhhcmQgdG8gZ3Vlc3MgZXhhY3RseSB3aGF0IFN1bk9TNiB3aWxsIGJlIGxp
a2UsIGJ1dAorCSMgaXQncyBsaWtlbHkgdG8gYmUgbW9yZSBsaWtlIFNvbGFyaXMgdGhhbiBTdW5P
UzQuCisJZWNobyBzcGFyYy1zdW4tc29sYXJpczNgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgc3VuNCo6U3VuT1M6KjoqKQorCWNhc2UgImAv
dXNyL2Jpbi9hcmNoIC1rYCIgaW4KKwkgICAgU2VyaWVzKnxTNCopCisJCVVOQU1FX1JFTEVBU0U9
YHVuYW1lIC12YAorCQk7OworCWVzYWMKKwkjIEphcGFuZXNlIExhbmd1YWdlIHZlcnNpb25zIGhh
dmUgYSB2ZXJzaW9uIG51bWJlciBsaWtlIGA0LjEuMy1KTCcuCisJZWNobyBzcGFyYy1zdW4tc3Vu
b3NgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vJ2AKKwlleGl0IDs7CisgICAg
c3VuMyo6U3VuT1M6KjoqKQorCWVjaG8gbTY4ay1zdW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgIHN1bio6Kjo0LjJCU0Q6KikKKwlVTkFNRV9SRUxFQVNFPWAoc2VkIDFxIC9l
dGMvbW90ZCB8IGF3ayAne3ByaW50IHN1YnN0cigkNSwxLDMpfScpIDI+L2Rldi9udWxsYAorCXRl
c3QgIngke1VOQU1FX1JFTEVBU0V9IiA9ICJ4IiAmJiBVTkFNRV9SRUxFQVNFPTMKKwljYXNlICJg
L2Jpbi9hcmNoYCIgaW4KKwkgICAgc3VuMykKKwkJZWNobyBtNjhrLXN1bi1zdW5vcyR7VU5BTUVf
UkVMRUFTRX0KKwkJOzsKKwkgICAgc3VuNCkKKwkJZWNobyBzcGFyYy1zdW4tc3Vub3Mke1VOQU1F
X1JFTEVBU0V9CisJCTs7CisJZXNhYworCWV4aXQgOzsKKyAgICBhdXNocDpTdW5PUzoqOiopCisJ
ZWNobyBzcGFyYy1hdXNwZXgtc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICMg
VGhlIHNpdHVhdGlvbiBmb3IgTWlOVCBpcyBhIGxpdHRsZSBjb25mdXNpbmcuICBUaGUgbWFjaGlu
ZSBuYW1lCisgICAgIyBjYW4gYmUgdmlydHVhbGx5IGV2ZXJ5dGhpbmcgKGV2ZXJ5dGhpbmcgd2hp
Y2ggaXMgbm90CisgICAgIyAiYXRhcmlzdCIgb3IgImF0YXJpc3RlIiBhdCBsZWFzdCBzaG91bGQg
aGF2ZSBhIHByb2Nlc3NvcgorICAgICMgPiBtNjgwMDApLiAgVGhlIHN5c3RlbSBuYW1lIHJhbmdl
cyBmcm9tICJNaU5UIiBvdmVyICJGcmVlTWlOVCIKKyAgICAjIHRvIHRoZSBsb3dlcmNhc2UgdmVy
c2lvbiAibWludCIgKG9yICJmcmVlbWludCIpLiAgRmluYWxseQorICAgICMgdGhlIHN5c3RlbSBu
YW1lICJUT1MiIGRlbm90ZXMgYSBzeXN0ZW0gd2hpY2ggaXMgYWN0dWFsbHkgbm90CisgICAgIyBN
aU5ULiAgQnV0IE1pTlQgaXMgZG93bndhcmQgY29tcGF0aWJsZSB0byBUT1MsIHNvIHRoaXMgc2hv
dWxkCisgICAgIyBiZSBubyBwcm9ibGVtLgorICAgIGF0YXJpc3RbZV06Kk1pTlQ6KjoqIHwgYXRh
cmlzdFtlXToqbWludDoqOiogfCBhdGFyaXN0W2VdOipUT1M6KjoqKQorICAgICAgICBlY2hvIG02
OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgYXRhcmkqOipNaU5U
Oio6KiB8IGF0YXJpKjoqbWludDoqOiogfCBhdGFyaXN0W2VdOipUT1M6KjoqKQorCWVjaG8gbTY4
ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorICAgICAgICBleGl0IDs7CisgICAgKmZhbGNv
bio6Kk1pTlQ6KjoqIHwgKmZhbGNvbio6Km1pbnQ6KjoqIHwgKmZhbGNvbio6KlRPUzoqOiopCisg
ICAgICAgIGVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAg
ICBtaWxhbio6Kk1pTlQ6KjoqIHwgbWlsYW4qOiptaW50Oio6KiB8ICptaWxhbio6KlRPUzoqOiop
CisgICAgICAgIGVjaG8gbTY4ay1taWxhbi1taW50JHtVTkFNRV9SRUxFQVNFfQorICAgICAgICBl
eGl0IDs7CisgICAgaGFkZXMqOipNaU5UOio6KiB8IGhhZGVzKjoqbWludDoqOiogfCAqaGFkZXMq
OipUT1M6KjoqKQorICAgICAgICBlY2hvIG02OGstaGFkZXMtbWludCR7VU5BTUVfUkVMRUFTRX0K
KyAgICAgICAgZXhpdCA7OworICAgICo6Kk1pTlQ6KjoqIHwgKjoqbWludDoqOiogfCAqOipUT1M6
KjoqKQorICAgICAgICBlY2hvIG02OGstdW5rbm93bi1taW50JHtVTkFNRV9SRUxFQVNFfQorICAg
ICAgICBleGl0IDs7CisgICAgbTY4azptYWNodGVuOio6KikKKwllY2hvIG02OGstYXBwbGUtbWFj
aHRlbiR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgcG93ZXJwYzptYWNodGVuOio6KikK
KwllY2hvIHBvd2VycGMtYXBwbGUtbWFjaHRlbiR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7Cisg
ICAgUklTQyo6TWFjaDoqOiopCisJZWNobyBtaXBzLWRlYy1tYWNoX2JzZDQuMworCWV4aXQgOzsK
KyAgICBSSVNDKjpVTFRSSVg6KjoqKQorCWVjaG8gbWlwcy1kZWMtdWx0cml4JHtVTkFNRV9SRUxF
QVNFfQorCWV4aXQgOzsKKyAgICBWQVgqOlVMVFJJWCo6KjoqKQorCWVjaG8gdmF4LWRlYy11bHRy
aXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIDIwMjA6Q0xJWDoqOiogfCAyNDMwOkNM
SVg6KjoqKQorCWVjaG8gY2xpcHBlci1pbnRlcmdyYXBoLWNsaXgke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgIG1pcHM6KjoqOlVNSVBTIHwgbWlwczoqOio6UklTQ29zKQorCWV2YWwgJHNl
dF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworI2lmZGVmIF9f
Y3BsdXNwbHVzCisjaW5jbHVkZSA8c3RkaW8uaD4gIC8qIGZvciBwcmludGYoKSBwcm90b3R5cGUg
Ki8KKwlpbnQgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkgeworI2Vsc2UKKwlpbnQgbWFp
biAoYXJnYywgYXJndikgaW50IGFyZ2M7IGNoYXIgKmFyZ3ZbXTsgeworI2VuZGlmCisJI2lmIGRl
ZmluZWQgKGhvc3RfbWlwcykgJiYgZGVmaW5lZCAoTUlQU0VCKQorCSNpZiBkZWZpbmVkIChTWVNU
WVBFX1NZU1YpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzeXN2XG4iLCBhcmd2WzFd
KTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfU1ZSNCkKKwkgIHBy
aW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc3N2cjRcbiIsIGFyZ3ZbMV0pOyBleGl0ICgwKTsKKwkj
ZW5kaWYKKwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9CU0Q0MykgfHwgZGVmaW5lZChTWVNUWVBFX0JT
RCkKKwkgIHByaW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc2JzZFxuIiwgYXJndlsxXSk7IGV4aXQg
KDApOworCSNlbmRpZgorCSNlbmRpZgorCSAgZXhpdCAoLTEpOworCX0KK0VPRgorCSRDQ19GT1Jf
QlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmCisJICBkdW1teWFyZz1gZWNobyAiJHtVTkFNRV9S
RUxFQVNFfSIgfCBzZWQgLW4gJ3MvXChbMC05XSpcKS4qL1wxL3AnYCAmJgorCSAgU1lTVEVNX05B
TUU9YCRkdW1teSAkZHVtbXlhcmdgICYmCisJICAgIHsgZWNobyAiJFNZU1RFTV9OQU1FIjsgZXhp
dDsgfQorCWVjaG8gbWlwcy1taXBzLXJpc2NvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7Cisg
ICAgTW90b3JvbGE6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93ZXJwYy1tb3Rvcm9sYS1wb3dl
cm1heAorCWV4aXQgOzsKKyAgICBNb3Rvcm9sYToqOjQuMzpQTDgtKikKKwllY2hvIHBvd2VycGMt
aGFycmlzLXBvd2VybWF4CisJZXhpdCA7OworICAgIE5pZ2h0X0hhd2s6KjoqOlBvd2VyTUFYX09T
IHwgU3luZXJneTpQb3dlck1BWF9PUzoqOiopCisJZWNobyBwb3dlcnBjLWhhcnJpcy1wb3dlcm1h
eAorCWV4aXQgOzsKKyAgICBOaWdodF9IYXdrOlBvd2VyX1VOSVg6KjoqKQorCWVjaG8gcG93ZXJw
Yy1oYXJyaXMtcG93ZXJ1bml4CisJZXhpdCA7OworICAgIG04OGs6Q1gvVVg6Nyo6KikKKwllY2hv
IG04OGstaGFycmlzLWN4dXg3CisJZXhpdCA7OworICAgIG04OGs6Kjo0KjpSNCopCisJZWNobyBt
ODhrLW1vdG9yb2xhLXN5c3Y0CisJZXhpdCA7OworICAgIG04OGs6KjozKjpSMyopCisJZWNobyBt
ODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIEFWaWlPTjpkZ3V4Oio6KikKKyAgICAg
ICAgIyBERy9VWCByZXR1cm5zIEFWaWlPTiBmb3IgYWxsIGFyY2hpdGVjdHVyZXMKKyAgICAgICAg
VU5BTUVfUFJPQ0VTU09SPWAvdXNyL2Jpbi91bmFtZSAtcGAKKwlpZiBbICRVTkFNRV9QUk9DRVNT
T1IgPSBtYzg4MTAwIF0gfHwgWyAkVU5BTUVfUFJPQ0VTU09SID0gbWM4ODExMCBdCisJdGhlbgor
CSAgICBpZiBbICR7VEFSR0VUX0JJTkFSWV9JTlRFUkZBQ0V9eCA9IG04OGtkZ3V4ZWxmeCBdIHx8
IFwKKwkgICAgICAgWyAke1RBUkdFVF9CSU5BUllfSU5URVJGQUNFfXggPSB4IF0KKwkgICAgdGhl
bgorCQllY2hvIG04OGstZGctZGd1eCR7VU5BTUVfUkVMRUFTRX0KKwkgICAgZWxzZQorCQllY2hv
IG04OGstZGctZGd1eGJjcyR7VU5BTUVfUkVMRUFTRX0KKwkgICAgZmkKKwllbHNlCisJICAgIGVj
aG8gaTU4Ni1kZy1kZ3V4JHtVTkFNRV9SRUxFQVNFfQorCWZpCisgCWV4aXQgOzsKKyAgICBNODgq
OkRvbHBoaW5PUzoqOiopCSMgRG9scGhpbk9TIChTVlIzKQorCWVjaG8gbTg4ay1kb2xwaGluLXN5
c3YzCisJZXhpdCA7OworICAgIE04OCo6KjpSMyo6KikKKwkjIERlbHRhIDg4ayBzeXN0ZW0gcnVu
bmluZyBTVlIzCisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIFhEODgq
Oio6KjoqKSAjIFRla3Ryb25peCBYRDg4IHN5c3RlbSBydW5uaW5nIFVUZWtWIChTVlIzKQorCWVj
aG8gbTg4ay10ZWt0cm9uaXgtc3lzdjMKKwlleGl0IDs7CisgICAgVGVrNDNbMC05XVswLTldOlVU
ZWs6KjoqKSAjIFRla3Ryb25peCA0MzAwIHN5c3RlbSBydW5uaW5nIFVUZWsgKEJTRCkKKwllY2hv
IG02OGstdGVrdHJvbml4LWJzZAorCWV4aXQgOzsKKyAgICAqOklSSVgqOio6KikKKwllY2hvIG1p
cHMtc2dpLWlyaXhgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vZydgCisJZXhp
dCA7OworICAgID8/Pz8/Pz8/OkFJWD86WzEyXS4xOjIpICAgIyBBSVggMi4yLjEgb3IgQUlYIDIu
MS4xIGlzIFJUL1BDIEFJWC4KKwllY2hvIHJvbXAtaWJtLWFpeCAgICAgIyB1bmFtZSAtbSBnaXZl
cyBhbiA4IGhleC1jb2RlIENQVSBpZAorCWV4aXQgOzsgICAgICAgICAgICAgICAjIE5vdGUgdGhh
dDogZWNobyAiJ2B1bmFtZSAtc2AnIiBnaXZlcyAnQUlYICcKKyAgICBpKjg2OkFJWDoqOiopCisJ
ZWNobyBpMzg2LWlibS1haXgKKwlleGl0IDs7CisgICAgaWE2NDpBSVg6KjoqKQorCWlmIFsgLXgg
L3Vzci9iaW4vb3NsZXZlbCBdIDsgdGhlbgorCQlJQk1fUkVWPWAvdXNyL2Jpbi9vc2xldmVsYAor
CWVsc2UKKwkJSUJNX1JFVj0ke1VOQU1FX1ZFUlNJT059LiR7VU5BTUVfUkVMRUFTRX0KKwlmaQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1pYm0tYWl4JHtJQk1fUkVWfQorCWV4aXQgOzsKKyAgICAq
OkFJWDoyOjMpCisJaWYgZ3JlcCBib3MzMjUgL3Vzci9pbmNsdWRlL3N0ZGlvLmggPi9kZXYvbnVs
bCAyPiYxOyB0aGVuCisJCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJc2VkICdzL14JCS8vJyA8
PCBFT0YgPiRkdW1teS5jCisJCSNpbmNsdWRlIDxzeXMvc3lzdGVtY2ZnLmg+CisKKwkJbWFpbigp
CisJCQl7CisJCQlpZiAoIV9fcG93ZXJfcGMoKSkKKwkJCQlleGl0KDEpOworCQkJcHV0cygicG93
ZXJwYy1pYm0tYWl4My4yLjUiKTsKKwkJCWV4aXQoMCk7CisJCQl9CitFT0YKKwkJaWYgJENDX0ZP
Ul9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRkdW1teWAKKwkJdGhl
bgorCQkJZWNobyAiJFNZU1RFTV9OQU1FIgorCQllbHNlCisJCQllY2hvIHJzNjAwMC1pYm0tYWl4
My4yLjUKKwkJZmkKKwllbGlmIGdyZXAgYm9zMzI0IC91c3IvaW5jbHVkZS9zdGRpby5oID4vZGV2
L251bGwgMj4mMTsgdGhlbgorCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yLjQKKwllbHNlCisJCWVj
aG8gcnM2MDAwLWlibS1haXgzLjIKKwlmaQorCWV4aXQgOzsKKyAgICAqOkFJWDoqOls0NTZdKQor
CUlCTV9DUFVfSUQ9YC91c3Ivc2Jpbi9sc2RldiAtQyAtYyBwcm9jZXNzb3IgLVMgYXZhaWxhYmxl
IHwgc2VkIDFxIHwgYXdrICd7IHByaW50ICQxIH0nYAorCWlmIC91c3Ivc2Jpbi9sc2F0dHIgLUVs
ICR7SUJNX0NQVV9JRH0gfCBncmVwICcgUE9XRVInID4vZGV2L251bGwgMj4mMTsgdGhlbgorCQlJ
Qk1fQVJDSD1yczYwMDAKKwllbHNlCisJCUlCTV9BUkNIPXBvd2VycGMKKwlmaQorCWlmIFsgLXgg
L3Vzci9iaW4vb3NsZXZlbCBdIDsgdGhlbgorCQlJQk1fUkVWPWAvdXNyL2Jpbi9vc2xldmVsYAor
CWVsc2UKKwkJSUJNX1JFVj0ke1VOQU1FX1ZFUlNJT059LiR7VU5BTUVfUkVMRUFTRX0KKwlmaQor
CWVjaG8gJHtJQk1fQVJDSH0taWJtLWFpeCR7SUJNX1JFVn0KKwlleGl0IDs7CisgICAgKjpBSVg6
KjoqKQorCWVjaG8gcnM2MDAwLWlibS1haXgKKwlleGl0IDs7CisgICAgaWJtcnQ6NC40QlNEOip8
cm9tcC1pYm06QlNEOiopCisJZWNobyByb21wLWlibS1ic2Q0LjQKKwlleGl0IDs7CisgICAgaWJt
cnQ6KkJTRDoqfHJvbXAtaWJtOkJTRDoqKSAgICAgICAgICAgICMgY292ZXJzIFJUL1BDIEJTRCBh
bmQKKwllY2hvIHJvbXAtaWJtLWJzZCR7VU5BTUVfUkVMRUFTRX0gICAjIDQuMyB3aXRoIHVuYW1l
IGFkZGVkIHRvCisJZXhpdCA7OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyByZXBvcnQ6
IHJvbXAtaWJtIEJTRCA0LjMKKyAgICAqOkJPU1g6KjoqKQorCWVjaG8gcnM2MDAwLWJ1bGwtYm9z
eAorCWV4aXQgOzsKKyAgICBEUFgvMj8wMDpCLk8uUy46KjoqKQorCWVjaG8gbTY4ay1idWxsLXN5
c3YzCisJZXhpdCA7OworICAgIDkwMDAvWzM0XT8/OjQuM2JzZDoxLio6KikKKwllY2hvIG02OGst
aHAtYnNkCisJZXhpdCA7OworICAgIGhwMzAwOjQuNEJTRDoqOiogfCA5MDAwL1szNF0/Pzo0LjNi
c2Q6Mi4qOiopCisJZWNobyBtNjhrLWhwLWJzZDQuNAorCWV4aXQgOzsKKyAgICA5MDAwL1szNDY3
OF0/PzpIUC1VWDoqOiopCisJSFBVWF9SRVY9YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvW14uXSouWzBCXSovLydgCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FfSIgaW4KKwkgICAgOTAw
MC8zMT8gKSAgICAgICAgICAgIEhQX0FSQ0g9bTY4MDAwIDs7CisJICAgIDkwMDAvWzM0XT8/ICkg
ICAgICAgICBIUF9BUkNIPW02OGsgOzsKKwkgICAgOTAwMC9bNjc4XVswLTldWzAtOV0pCisJCWlm
IFsgLXggL3Vzci9iaW4vZ2V0Y29uZiBdOyB0aGVuCisJCSAgICBzY19jcHVfdmVyc2lvbj1gL3Vz
ci9iaW4vZ2V0Y29uZiBTQ19DUFVfVkVSU0lPTiAyPi9kZXYvbnVsbGAKKyAgICAgICAgICAgICAg
ICAgICAgc2Nfa2VybmVsX2JpdHM9YC91c3IvYmluL2dldGNvbmYgU0NfS0VSTkVMX0JJVFMgMj4v
ZGV2L251bGxgCisgICAgICAgICAgICAgICAgICAgIGNhc2UgIiR7c2NfY3B1X3ZlcnNpb259IiBp
bgorICAgICAgICAgICAgICAgICAgICAgIDUyMykgSFBfQVJDSD0iaHBwYTEuMCIgOzsgIyBDUFVf
UEFfUklTQzFfMAorICAgICAgICAgICAgICAgICAgICAgIDUyOCkgSFBfQVJDSD0iaHBwYTEuMSIg
OzsgIyBDUFVfUEFfUklTQzFfMQorICAgICAgICAgICAgICAgICAgICAgIDUzMikgICAgICAgICAg
ICAgICAgICAgICAgIyBDUFVfUEFfUklTQzJfMAorICAgICAgICAgICAgICAgICAgICAgICAgY2Fz
ZSAiJHtzY19rZXJuZWxfYml0c30iIGluCisgICAgICAgICAgICAgICAgICAgICAgICAgIDMyKSBI
UF9BUkNIPSJocHBhMi4wbiIgOzsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgNjQpIEhQX0FS
Q0g9ImhwcGEyLjB3IiA7OworCQkJICAnJykgSFBfQVJDSD0iaHBwYTIuMCIgOzsgICAjIEhQLVVY
IDEwLjIwCisgICAgICAgICAgICAgICAgICAgICAgICBlc2FjIDs7CisgICAgICAgICAgICAgICAg
ICAgIGVzYWMKKwkJZmkKKwkJaWYgWyAiJHtIUF9BUkNIfSIgPSAiIiBdOyB0aGVuCisJCSAgICBl
dmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCSAgICBzZWQgJ3MvXiAgICAgICAgICAgICAgLy8nIDw8
IEVPRiA+JGR1bW15LmMKKworICAgICAgICAgICAgICAjZGVmaW5lIF9IUFVYX1NPVVJDRQorICAg
ICAgICAgICAgICAjaW5jbHVkZSA8c3RkbGliLmg+CisgICAgICAgICAgICAgICNpbmNsdWRlIDx1
bmlzdGQuaD4KKworICAgICAgICAgICAgICBpbnQgbWFpbiAoKQorICAgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgICNpZiBkZWZpbmVkKF9TQ19LRVJORUxfQklUUykKKyAgICAgICAgICAgICAg
ICAgIGxvbmcgYml0cyA9IHN5c2NvbmYoX1NDX0tFUk5FTF9CSVRTKTsKKyAgICAgICAgICAgICAg
I2VuZGlmCisgICAgICAgICAgICAgICAgICBsb25nIGNwdSAgPSBzeXNjb25mIChfU0NfQ1BVX1ZF
UlNJT04pOworCisgICAgICAgICAgICAgICAgICBzd2l0Y2ggKGNwdSkKKyAgICAgICAgICAgICAg
CXsKKyAgICAgICAgICAgICAgCWNhc2UgQ1BVX1BBX1JJU0MxXzA6IHB1dHMgKCJocHBhMS4wIik7
IGJyZWFrOworICAgICAgICAgICAgICAJY2FzZSBDUFVfUEFfUklTQzFfMTogcHV0cyAoImhwcGEx
LjEiKTsgYnJlYWs7CisgICAgICAgICAgICAgIAljYXNlIENQVV9QQV9SSVNDMl8wOgorICAgICAg
ICAgICAgICAjaWYgZGVmaW5lZChfU0NfS0VSTkVMX0JJVFMpCisgICAgICAgICAgICAgIAkgICAg
c3dpdGNoIChiaXRzKQorICAgICAgICAgICAgICAJCXsKKyAgICAgICAgICAgICAgCQljYXNlIDY0
OiBwdXRzICgiaHBwYTIuMHciKTsgYnJlYWs7CisgICAgICAgICAgICAgIAkJY2FzZSAzMjogcHV0
cyAoImhwcGEyLjBuIik7IGJyZWFrOworICAgICAgICAgICAgICAJCWRlZmF1bHQ6IHB1dHMgKCJo
cHBhMi4wIik7IGJyZWFrOworICAgICAgICAgICAgICAJCX0gYnJlYWs7CisgICAgICAgICAgICAg
ICNlbHNlICAvKiAhZGVmaW5lZChfU0NfS0VSTkVMX0JJVFMpICovCisgICAgICAgICAgICAgIAkg
ICAgcHV0cyAoImhwcGEyLjAiKTsgYnJlYWs7CisgICAgICAgICAgICAgICNlbmRpZgorICAgICAg
ICAgICAgICAJZGVmYXVsdDogcHV0cyAoImhwcGExLjAiKTsgYnJlYWs7CisgICAgICAgICAgICAg
IAl9CisgICAgICAgICAgICAgICAgICBleGl0ICgwKTsKKyAgICAgICAgICAgICAgfQorRU9GCisJ
CSAgICAoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAyPi9kZXYvbnVs
bCkgJiYgSFBfQVJDSD1gJGR1bW15YAorCQkgICAgdGVzdCAteiAiJEhQX0FSQ0giICYmIEhQX0FS
Q0g9aHBwYQorCQlmaSA7OworCWVzYWMKKwlpZiBbICR7SFBfQVJDSH0gPSAiaHBwYTIuMHciIF0K
Kwl0aGVuCisJICAgIGV2YWwgJHNldF9jY19mb3JfYnVpbGQKKworCSAgICAjIGhwcGEyLjB3LWhw
LWhwdXgqIGhhcyBhIDY0LWJpdCBrZXJuZWwgYW5kIGEgY29tcGlsZXIgZ2VuZXJhdGluZworCSAg
ICAjIDMyLWJpdCBjb2RlLiAgaHBwYTY0LWhwLWhwdXgqIGhhcyB0aGUgc2FtZSBrZXJuZWwgYW5k
IGEgY29tcGlsZXIKKwkgICAgIyBnZW5lcmF0aW5nIDY0LWJpdCBjb2RlLiAgR05VIGFuZCBIUCB1
c2UgZGlmZmVyZW50IG5vbWVuY2xhdHVyZToKKwkgICAgIworCSAgICAjICQgQ0NfRk9SX0JVSUxE
PWNjIC4vY29uZmlnLmd1ZXNzCisJICAgICMgPT4gaHBwYTIuMHctaHAtaHB1eDExLjIzCisJICAg
ICMgJCBDQ19GT1JfQlVJTEQ9ImNjICtEQTIuMHciIC4vY29uZmlnLmd1ZXNzCisJICAgICMgPT4g
aHBwYTY0LWhwLWhwdXgxMS4yMworCisJICAgIGlmIGVjaG8gX19MUDY0X18gfCAoQ0NPUFRTPSAk
Q0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwKKwkJZ3JlcCAtcSBfX0xQNjRfXworCSAg
ICB0aGVuCisJCUhQX0FSQ0g9ImhwcGEyLjB3IgorCSAgICBlbHNlCisJCUhQX0FSQ0g9ImhwcGE2
NCIKKwkgICAgZmkKKwlmaQorCWVjaG8gJHtIUF9BUkNIfS1ocC1ocHV4JHtIUFVYX1JFVn0KKwll
eGl0IDs7CisgICAgaWE2NDpIUC1VWDoqOiopCisJSFBVWF9SRVY9YGVjaG8gJHtVTkFNRV9SRUxF
QVNFfXxzZWQgLWUgJ3MvW14uXSouWzBCXSovLydgCisJZWNobyBpYTY0LWhwLWhwdXgke0hQVVhf
UkVWfQorCWV4aXQgOzsKKyAgICAzMDUwKjpISS1VWDoqOiopCisJZXZhbCAkc2V0X2NjX2Zvcl9i
dWlsZAorCXNlZCAncy9eCS8vJyA8PCBFT0YgPiRkdW1teS5jCisJI2luY2x1ZGUgPHVuaXN0ZC5o
PgorCWludAorCW1haW4gKCkKKwl7CisJICBsb25nIGNwdSA9IHN5c2NvbmYgKF9TQ19DUFVfVkVS
U0lPTik7CisJICAvKiBUaGUgb3JkZXIgbWF0dGVycywgYmVjYXVzZSBDUFVfSVNfSFBfTUM2OEsg
ZXJyb25lb3VzbHkgcmV0dXJucworCSAgICAgdHJ1ZSBmb3IgQ1BVX1BBX1JJU0MxXzAuICBDUFVf
SVNfUEFfUklTQyByZXR1cm5zIGNvcnJlY3QKKwkgICAgIHJlc3VsdHMsIGhvd2V2ZXIuICAqLwor
CSAgaWYgKENQVV9JU19QQV9SSVNDIChjcHUpKQorCSAgICB7CisJICAgICAgc3dpdGNoIChjcHUp
CisJCXsKKwkJICBjYXNlIENQVV9QQV9SSVNDMV8wOiBwdXRzICgiaHBwYTEuMC1oaXRhY2hpLWhp
dXh3ZTIiKTsgYnJlYWs7CisJCSAgY2FzZSBDUFVfUEFfUklTQzFfMTogcHV0cyAoImhwcGExLjEt
aGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQkgIGNhc2UgQ1BVX1BBX1JJU0MyXzA6IHB1dHMg
KCJocHBhMi4wLWhpdGFjaGktaGl1eHdlMiIpOyBicmVhazsKKwkJICBkZWZhdWx0OiBwdXRzICgi
aHBwYS1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJCX0KKwkgICAgfQorCSAgZWxzZSBpZiAo
Q1BVX0lTX0hQX01DNjhLIChjcHUpKQorCSAgICBwdXRzICgibTY4ay1oaXRhY2hpLWhpdXh3ZTIi
KTsKKwkgIGVsc2UgcHV0cyAoInVua25vd24taGl0YWNoaS1oaXV4d2UyIik7CisJICBleGl0ICgw
KTsKKwl9CitFT0YKKwkkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAmJiBTWVNURU1f
TkFNRT1gJGR1bW15YCAmJgorCQl7IGVjaG8gIiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKwllY2hv
IHVua25vd24taGl0YWNoaS1oaXV4d2UyCisJZXhpdCA7OworICAgIDkwMDAvNz8/OjQuM2JzZDoq
OiogfCA5MDAwLzg/Wzc5XTo0LjNic2Q6KjoqICkKKwllY2hvIGhwcGExLjEtaHAtYnNkCisJZXhp
dCA7OworICAgIDkwMDAvOD8/OjQuM2JzZDoqOiopCisJZWNobyBocHBhMS4wLWhwLWJzZAorCWV4
aXQgOzsKKyAgICAqOT8/KjpNUEUvaVg6KjoqIHwgKjMwMDAqOk1QRS9pWDoqOiopCisJZWNobyBo
cHBhMS4wLWhwLW1wZWl4CisJZXhpdCA7OworICAgIGhwNz8/Ok9TRjE6KjoqIHwgaHA4P1s3OV06
T1NGMToqOiogKQorCWVjaG8gaHBwYTEuMS1ocC1vc2YKKwlleGl0IDs7CisgICAgaHA4Pz86T1NG
MToqOiopCisJZWNobyBocHBhMS4wLWhwLW9zZgorCWV4aXQgOzsKKyAgICBpKjg2Ok9TRjE6Kjoq
KQorCWlmIFsgLXggL3Vzci9zYmluL3N5c3ZlcnNpb24gXSA7IHRoZW4KKwkgICAgZWNobyAke1VO
QU1FX01BQ0hJTkV9LXVua25vd24tb3NmMW1rCisJZWxzZQorCSAgICBlY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1vc2YxCisJZmkKKwlleGl0IDs7CisgICAgcGFyaXNjKjpMaXRlcyo6Kjoq
KQorCWVjaG8gaHBwYTEuMS1ocC1saXRlcworCWV4aXQgOzsKKyAgICBDMSo6Q29udmV4T1M6Kjoq
IHwgY29udmV4OkNvbnZleE9TOkMxKjoqKQorCWVjaG8gYzEtY29udmV4LWJzZAorICAgICAgICBl
eGl0IDs7CisgICAgQzIqOkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMio6KikKKwlp
ZiBnZXRzeXNpbmZvIC1mIHNjYWxhcl9hY2MKKwl0aGVuIGVjaG8gYzMyLWNvbnZleC1ic2QKKwll
bHNlIGVjaG8gYzItY29udmV4LWJzZAorCWZpCisgICAgICAgIGV4aXQgOzsKKyAgICBDMzQqOkNv
bnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMzQqOiopCisJZWNobyBjMzQtY29udmV4LWJz
ZAorICAgICAgICBleGl0IDs7CisgICAgQzM4KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4
T1M6QzM4KjoqKQorCWVjaG8gYzM4LWNvbnZleC1ic2QKKyAgICAgICAgZXhpdCA7OworICAgIEM0
KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzQqOiopCisJZWNobyBjNC1jb252ZXgt
YnNkCisgICAgICAgIGV4aXQgOzsKKyAgICBDUkFZKlktTVA6KjoqOiopCisJZWNobyB5bXAtY3Jh
eS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwlleGl0
IDs7CisgICAgQ1JBWSpbQS1aXTkwOio6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1jcmF5
LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gXAorCXwgc2VkIC1lICdzL0NSQVkuKlwoW0EtWl05MFwp
L1wxLycgXAorCSAgICAgIC1lIHkvQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVovYWJjZGVmZ2hp
amtsbW5vcHFyc3R1dnd4eXovIFwKKwkgICAgICAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7
OworICAgIENSQVkqVFM6KjoqOiopCisJZWNobyB0OTAtY3JheS11bmljb3Mke1VOQU1FX1JFTEVB
U0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpUM0U6Kjoq
OiopCisJZWNobyBhbHBoYWV2NS1jcmF5LXVuaWNvc21rJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAt
ZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIENSQVkqU1YxOio6KjoqKQorCWVjaG8g
c3YxLWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8n
CisJZXhpdCA7OworICAgICo6VU5JQ09TL21wOio6KikKKwllY2hvIGNyYXludi1jcmF5LXVuaWNv
c21wJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7Owor
ICAgIEYzMFswMV06VU5JWF9TeXN0ZW1fVjoqOiogfCBGNzAwOlVOSVhfU3lzdGVtX1Y6KjoqKQor
CUZVSklUU1VfUFJPQz1gdW5hbWUgLW0gfCB0ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVon
ICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eidgCisgICAgICAgIEZVSklUU1VfU1lTPWB1bmFt
ZSAtcCB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3Bx
cnN0dXZ3eHl6JyB8IHNlZCAtZSAncy9cLy8vJ2AKKyAgICAgICAgRlVKSVRTVV9SRUw9YGVjaG8g
JHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy8gL18vJ2AKKyAgICAgICAgZWNobyAiJHtGVUpJ
VFNVX1BST0N9LWZ1aml0c3UtJHtGVUpJVFNVX1NZU30ke0ZVSklUU1VfUkVMfSIKKyAgICAgICAg
ZXhpdCA7OworICAgIDUwMDA6VU5JWF9TeXN0ZW1fVjo0Lio6KikKKyAgICAgICAgRlVKSVRTVV9T
WVM9YHVuYW1lIC1wIHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hp
amtsbW5vcHFyc3R1dnd4eXonIHwgc2VkIC1lICdzL1wvLy8nYAorICAgICAgICBGVUpJVFNVX1JF
TD1gZWNobyAke1VOQU1FX1JFTEVBU0V9IHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFla
JyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHwgc2VkIC1lICdzLyAvXy8nYAorICAgICAg
ICBlY2hvICJzcGFyYy1mdWppdHN1LSR7RlVKSVRTVV9TWVN9JHtGVUpJVFNVX1JFTH0iCisJZXhp
dCA7OworICAgIGkqODY6QlNELzM4NjoqOiogfCBpKjg2OkJTRC9PUzoqOiogfCAqOkFzY2VuZFwg
RW1iZWRkZWQvT1M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1ic2RpJHtVTkFNRV9S
RUxFQVNFfQorCWV4aXQgOzsKKyAgICBzcGFyYyo6QlNEL09TOio6KikKKwllY2hvIHNwYXJjLXVu
a25vd24tYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpCU0QvT1M6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhp
dCA7OworICAgICo6RnJlZUJTRDoqOiopCisJY2FzZSAke1VOQU1FX01BQ0hJTkV9IGluCisJICAg
IHBjOTgpCisJCWVjaG8gaTM4Ni11bmtub3duLWZyZWVic2RgZWNobyAke1VOQU1FX1JFTEVBU0V9
fHNlZCAtZSAncy9bLShdLiovLydgIDs7CisJICAgIGFtZDY0KQorCQllY2hvIHg4Nl82NC11bmtu
b3duLWZyZWVic2RgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgIDs7
CisJICAgICopCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWZyZWVic2RgZWNobyAk
e1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgIDs7CisJZXNhYworCWV4aXQgOzsK
KyAgICBpKjpDWUdXSU4qOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLWN5Z3dpbgorCWV4
aXQgOzsKKyAgICAqOk1JTkdXKjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1taW5ndzMy
CisJZXhpdCA7OworICAgIGkqOndpbmRvd3MzMio6KikKKyAgICAJIyB1bmFtZSAtbSBpbmNsdWRl
cyAiLXBjIiBvbiB0aGlzIHN5c3RlbS4KKyAgICAJZWNobyAke1VOQU1FX01BQ0hJTkV9LW1pbmd3
MzIKKwlleGl0IDs7CisgICAgaSo6UFcqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXB3
MzIKKwlleGl0IDs7CisgICAgKjpJbnRlcml4KjoqKQorICAgIAljYXNlICR7VU5BTUVfTUFDSElO
RX0gaW4KKwkgICAgeDg2KQorCQllY2hvIGk1ODYtcGMtaW50ZXJpeCR7VU5BTUVfUkVMRUFTRX0K
KwkJZXhpdCA7OworCSAgICBhdXRoZW50aWNhbWQgfCBnZW51aW5laW50ZWwgfCBFTTY0VCkKKwkJ
ZWNobyB4ODZfNjQtdW5rbm93bi1pbnRlcml4JHtVTkFNRV9SRUxFQVNFfQorCQlleGl0IDs7CisJ
ICAgIElBNjQpCisJCWVjaG8gaWE2NC11bmtub3duLWludGVyaXgke1VOQU1FX1JFTEVBU0V9CisJ
CWV4aXQgOzsKKwllc2FjIDs7CisgICAgWzM0NV04NjpXaW5kb3dzXzk1OiogfCBbMzQ1XTg2Oldp
bmRvd3NfOTg6KiB8IFszNDVdODY6V2luZG93c19OVDoqKQorCWVjaG8gaSR7VU5BTUVfTUFDSElO
RX0tcGMtbWtzCisJZXhpdCA7OworICAgIDg2NjQ6V2luZG93c19OVDoqKQorCWVjaG8geDg2XzY0
LXBjLW1rcworCWV4aXQgOzsKKyAgICBpKjpXaW5kb3dzX05UKjoqIHwgUGVudGl1bSo6V2luZG93
c19OVCo6KikKKwkjIEhvdyBkbyB3ZSBrbm93IGl0J3MgSW50ZXJpeCByYXRoZXIgdGhhbiB0aGUg
Z2VuZXJpYyBQT1NJWCBzdWJzeXN0ZW0/CisJIyBJdCBhbHNvIGNvbmZsaWN0cyB3aXRoIHByZS0y
LjAgdmVyc2lvbnMgb2YgQVQmVCBVV0lOLiBTaG91bGQgd2UKKwkjIFVOQU1FX01BQ0hJTkUgYmFz
ZWQgb24gdGhlIG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFkIG9mIGkzODY/CisJZWNobyBpNTg2LXBj
LWludGVyaXgKKwlleGl0IDs7CisgICAgaSo6VVdJTio6KikKKwllY2hvICR7VU5BTUVfTUFDSElO
RX0tcGMtdXdpbgorCWV4aXQgOzsKKyAgICBhbWQ2NDpDWUdXSU4qOio6KiB8IHg4Nl82NDpDWUdX
SU4qOio6KikKKwllY2hvIHg4Nl82NC11bmtub3duLWN5Z3dpbgorCWV4aXQgOzsKKyAgICBwKjpD
WUdXSU4qOiopCisJZWNobyBwb3dlcnBjbGUtdW5rbm93bi1jeWd3aW4KKwlleGl0IDs7CisgICAg
cHJlcCo6U3VuT1M6NS4qOiopCisJZWNobyBwb3dlcnBjbGUtdW5rbm93bi1zb2xhcmlzMmBlY2hv
ICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsKKyAgICAqOkdO
VToqOiopCisJIyB0aGUgR05VIHN5c3RlbQorCWVjaG8gYGVjaG8gJHtVTkFNRV9NQUNISU5FfXxz
ZWQgLWUgJ3MsWy0vXS4qJCwsJ2AtdW5rbm93bi1nbnVgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNl
ZCAtZSAncywvLiokLCwnYAorCWV4aXQgOzsKKyAgICAqOkdOVS8qOio6KikKKwkjIG90aGVyIHN5
c3RlbXMgd2l0aCBHTlUgbGliYyBhbmQgdXNlcmxhbmQKKwllY2hvICR7VU5BTUVfTUFDSElORX0t
dW5rbm93bi1gZWNobyAke1VOQU1FX1NZU1RFTX0gfCBzZWQgJ3MsXlteL10qLywsJyB8IHRyICdb
QS1aXScgJ1thLXpdJ2BgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydg
LWdudQorCWV4aXQgOzsKKyAgICBpKjg2Ok1pbml4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElO
RX0tcGMtbWluaXgKKwlleGl0IDs7CisgICAgYWxwaGE6TGludXg6KjoqKQorCWNhc2UgYHNlZCAt
biAnL15jcHUgbW9kZWwvcy9eLio6IFwoLipcKS9cMS9wJyA8IC9wcm9jL2NwdWluZm9gIGluCisJ
ICBFVjUpICAgVU5BTUVfTUFDSElORT1hbHBoYWV2NSA7OworCSAgRVY1NikgIFVOQU1FX01BQ0hJ
TkU9YWxwaGFldjU2IDs7CisJICBQQ0E1NikgVU5BTUVfTUFDSElORT1hbHBoYXBjYTU2IDs7CisJ
ICBQQ0E1NykgVU5BTUVfTUFDSElORT1hbHBoYXBjYTU2IDs7CisJICBFVjYpICAgVU5BTUVfTUFD
SElORT1hbHBoYWV2NiA7OworCSAgRVY2NykgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjY3IDs7CisJ
ICBFVjY4KikgVU5BTUVfTUFDSElORT1hbHBoYWV2NjggOzsKKyAgICAgICAgZXNhYworCW9iamR1
bXAgLS1wcml2YXRlLWhlYWRlcnMgL2Jpbi9zaCB8IGdyZXAgLXEgbGQuc28uMQorCWlmIHRlc3Qg
IiQ/IiA9IDAgOyB0aGVuIExJQkM9ImxpYmMxIiA7IGVsc2UgTElCQz0iIiA7IGZpCisJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251JHtMSUJDfQorCWV4aXQgOzsKKyAgICBh
cm0qOkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJaWYgZWNobyBfX0FSTV9F
QUJJX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwgXAorCSAgICB8IGdyZXAgLXEg
X19BUk1fRUFCSV9fCisJdGhlbgorCSAgICBlY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1s
aW51eC1nbnUKKwllbHNlCisJICAgIGVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4
LWdudWVhYmkKKwlmaQorCWV4aXQgOzsKKyAgICBhdnIzMio6TGludXg6KjoqKQorCWVjaG8gJHtV
TkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBjcmlzOkxpbnV4
Oio6KikKKwllY2hvIGNyaXMtYXhpcy1saW51eC1nbnUKKwlleGl0IDs7CisgICAgY3Jpc3YzMjpM
aW51eDoqOiopCisJZWNobyBjcmlzdjMyLWF4aXMtbGludXgtZ251CisJZXhpdCA7OworICAgIGZy
djpMaW51eDoqOiopCisgICAgCWVjaG8gZnJ2LXVua25vd24tbGludXgtZ251CisJZXhpdCA7Owor
ICAgIGkqODY6TGludXg6KjoqKQorCUxJQkM9Z251CisJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAor
CXNlZCAncy9eCS8vJyA8PCBFT0YgPiRkdW1teS5jCisJI2lmZGVmIF9fZGlldGxpYmNfXworCUxJ
QkM9ZGlldGxpYmMKKwkjZW5kaWYKK0VPRgorCWV2YWwgYCRDQ19GT1JfQlVJTEQgLUUgJGR1bW15
LmMgMj4vZGV2L251bGwgfCBncmVwICdeTElCQydgCisJZWNobyAiJHtVTkFNRV9NQUNISU5FfS1w
Yy1saW51eC0ke0xJQkN9IgorCWV4aXQgOzsKKyAgICBpYTY0OkxpbnV4Oio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgbTMycio6TGlu
dXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQg
OzsKKyAgICBtNjgqOkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1s
aW51eC1nbnUKKwlleGl0IDs7CisgICAgbWlwczpMaW51eDoqOiogfCBtaXBzNjQ6TGludXg6Kjoq
KQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXku
YworCSN1bmRlZiBDUFUKKwkjdW5kZWYgJHtVTkFNRV9NQUNISU5FfQorCSN1bmRlZiAke1VOQU1F
X01BQ0hJTkV9ZWwKKwkjaWYgZGVmaW5lZChfX01JUFNFTF9fKSB8fCBkZWZpbmVkKF9fTUlQU0VM
KSB8fCBkZWZpbmVkKF9NSVBTRUwpIHx8IGRlZmluZWQoTUlQU0VMKQorCUNQVT0ke1VOQU1FX01B
Q0hJTkV9ZWwKKwkjZWxzZQorCSNpZiBkZWZpbmVkKF9fTUlQU0VCX18pIHx8IGRlZmluZWQoX19N
SVBTRUIpIHx8IGRlZmluZWQoX01JUFNFQikgfHwgZGVmaW5lZChNSVBTRUIpCisJQ1BVPSR7VU5B
TUVfTUFDSElORX0KKwkjZWxzZQorCUNQVT0KKwkjZW5kaWYKKwkjZW5kaWYKK0VPRgorCWV2YWwg
YCRDQ19GT1JfQlVJTEQgLUUgJGR1bW15LmMgMj4vZGV2L251bGwgfCBncmVwICdeQ1BVJ2AKKwl0
ZXN0IHgiJHtDUFV9IiAhPSB4ICYmIHsgZWNobyAiJHtDUFV9LXVua25vd24tbGludXgtZ251Ijsg
ZXhpdDsgfQorCTs7CisgICAgb3IzMjpMaW51eDoqOiopCisJZWNobyBvcjMyLXVua25vd24tbGlu
dXgtZ251CisJZXhpdCA7OworICAgIHBhZHJlOkxpbnV4Oio6KikKKwllY2hvIHNwYXJjLXVua25v
d24tbGludXgtZ251CisJZXhpdCA7OworICAgIHBhcmlzYzY0OkxpbnV4Oio6KiB8IGhwcGE2NDpM
aW51eDoqOiopCisJZWNobyBocHBhNjQtdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAg
cGFyaXNjOkxpbnV4Oio6KiB8IGhwcGE6TGludXg6KjoqKQorCSMgTG9vayBmb3IgQ1BVIGxldmVs
CisJY2FzZSBgZ3JlcCAnXmNwdVteYS16XSo6JyAvcHJvYy9jcHVpbmZvIDI+L2Rldi9udWxsIHwg
Y3V0IC1kJyAnIC1mMmAgaW4KKwkgIFBBNyopIGVjaG8gaHBwYTEuMS11bmtub3duLWxpbnV4LWdu
dSA7OworCSAgUEE4KikgZWNobyBocHBhMi4wLXVua25vd24tbGludXgtZ251IDs7CisJICAqKSAg
ICBlY2hvIGhwcGEtdW5rbm93bi1saW51eC1nbnUgOzsKKwllc2FjCisJZXhpdCA7OworICAgIHBw
YzY0OkxpbnV4Oio6KikKKwllY2hvIHBvd2VycGM2NC11bmtub3duLWxpbnV4LWdudQorCWV4aXQg
OzsKKyAgICBwcGM6TGludXg6KjoqKQorCWVjaG8gcG93ZXJwYy11bmtub3duLWxpbnV4LWdudQor
CWV4aXQgOzsKKyAgICBzMzkwOkxpbnV4Oio6KiB8IHMzOTB4OkxpbnV4Oio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0taWJtLWxpbnV4CisJZXhpdCA7OworICAgIHNoNjQqOkxpbnV4Oio6KikK
KyAgICAJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7Owor
ICAgIHNoKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHNwYXJjOkxpbnV4Oio6KiB8IHNwYXJjNjQ6TGludXg6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB2
YXg6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1kZWMtbGludXgtZ251CisJZXhp
dCA7OworICAgIHg4Nl82NDpMaW51eDoqOiopCisJZWNobyB4ODZfNjQtdW5rbm93bi1saW51eC1n
bnUKKwlleGl0IDs7CisgICAgeHRlbnNhKjpMaW51eDoqOiopCisgICAgCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBpKjg2OkRZTklYL3B0eDo0
KjoqKQorCSMgcHR4IDQuMCBkb2VzIHVuYW1lIC1zIGNvcnJlY3RseSwgd2l0aCBEWU5JWC9wdHgg
aW4gdGhlcmUuCisJIyBlYXJsaWVyIHZlcnNpb25zIGFyZSBtZXNzZWQgdXAgYW5kIHB1dCB0aGUg
bm9kZW5hbWUgaW4gYm90aAorCSMgc3lzbmFtZSBhbmQgbm9kZW5hbWUuCisJZWNobyBpMzg2LXNl
cXVlbnQtc3lzdjQKKwlleGl0IDs7CisgICAgaSo4NjpVTklYX1NWOjQuMk1QOjIuKikKKyAgICAg
ICAgIyBVbml4d2FyZSBpcyBhbiBvZmZzaG9vdCBvZiBTVlI0LCBidXQgaXQgaGFzIGl0cyBvd24g
dmVyc2lvbgorICAgICAgICAjIG51bWJlciBzZXJpZXMgc3RhcnRpbmcgd2l0aCAyLi4uCisgICAg
ICAgICMgSSBhbSBub3QgcG9zaXRpdmUgdGhhdCBvdGhlciBTVlI0IHN5c3RlbXMgd29uJ3QgbWF0
Y2ggdGhpcywKKwkjIEkganVzdCBoYXZlIHRvIGhvcGUuICAtLSBybXMuCisgICAgICAgICMgVXNl
IHN5c3Y0LjJ1dy4uLiBzbyB0aGF0IHN5c3Y0KiBtYXRjaGVzIGl0LgorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1wYy1zeXN2NC4ydXcke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6
T1MvMjoqOiopCisJIyBJZiB3ZSB3ZXJlIGFibGUgdG8gZmluZCBgdW5hbWUnLCB0aGVuIEVNWCBV
bml4IGNvbXBhdGliaWxpdHkKKwkjIGlzIHByb2JhYmx5IGluc3RhbGxlZC4KKwllY2hvICR7VU5B
TUVfTUFDSElORX0tcGMtb3MyLWVteAorCWV4aXQgOzsKKyAgICBpKjg2OlhUUy0zMDA6KjpTVE9Q
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXN0b3AKKwlleGl0IDs7CisgICAgaSo4
NjphdGhlb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWF0aGVvcworCWV4
aXQgOzsKKyAgICBpKjg2OnN5bGxhYmxlOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMt
c3lsbGFibGUKKwlleGl0IDs7CisgICAgaSo4NjpMeW54T1M6Mi4qOiogfCBpKjg2Okx5bnhPUzoz
LlswMV0qOiogfCBpKjg2Okx5bnhPUzo0LlswMl0qOiopCisJZWNobyBpMzg2LXVua25vd24tbHlu
eG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBpKjg2OipET1M6KjoqKQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1wYy1tc2Rvc2RqZ3BwCisJZXhpdCA7OworICAgIGkqODY6Kjo0Lio6
KiB8IGkqODY6U1lTVEVNX1Y6NC4qOiopCisJVU5BTUVfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFT
RX0gfCBzZWQgJ3MvXC9NUCQvLydgCisJaWYgZ3JlcCBOb3ZlbGwgL3Vzci9pbmNsdWRlL2xpbmsu
aCA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11
bml2ZWwtc3lzdiR7VU5BTUVfUkVMfQorCWVsc2UKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBj
LXN5c3Yke1VOQU1FX1JFTH0KKwlmaQorCWV4aXQgOzsKKyAgICBpKjg2Oio6NTpbNjc4XSopCisg
ICAgCSMgVW5peFdhcmUgNy54LCBPcGVuVU5JWCBhbmQgT3BlblNlcnZlciA2LgorCWNhc2UgYC9i
aW4vdW5hbWUgLVggfCBncmVwICJeTWFjaGluZSJgIGluCisJICAgICo0ODYqKQkgICAgIFVOQU1F
X01BQ0hJTkU9aTQ4NiA7OworCSAgICAqUGVudGl1bSkJICAgICBVTkFNRV9NQUNISU5FPWk1ODYg
OzsKKwkgICAgKlBlbnQqfCpDZWxlcm9uKSBVTkFNRV9NQUNISU5FPWk2ODYgOzsKKwllc2FjCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFTRX0ke1VOQU1F
X1NZU1RFTX0ke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6KjozLjI6KikKKwlp
ZiB0ZXN0IC1mIC91c3Ivb3B0aW9ucy9jYi5uYW1lOyB0aGVuCisJCVVOQU1FX1JFTD1gc2VkIC1u
ICdzLy4qVmVyc2lvbiAvL3AnIDwvdXNyL29wdGlvbnMvY2IubmFtZWAKKwkJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXBjLWlzYyRVTkFNRV9SRUwKKwllbGlmIC9iaW4vdW5hbWUgLVggMj4vZGV2L251
bGwgPi9kZXYvbnVsbCA7IHRoZW4KKwkJVU5BTUVfUkVMPWAoL2Jpbi91bmFtZSAtWHxncmVwIFJl
bGVhc2V8c2VkIC1lICdzLy4qPSAvLycpYAorCQkoL2Jpbi91bmFtZSAtWHxncmVwIGk4MDQ4NiA+
L2Rldi9udWxsKSAmJiBVTkFNRV9NQUNISU5FPWk0ODYKKwkJKC9iaW4vdW5hbWUgLVh8Z3JlcCAn
Xk1hY2hpbmUuKlBlbnRpdW0nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTU4
NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFjaGluZS4qUGVudCAqSUknID4vZGV2L251bGwp
IFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTY4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFj
aGluZS4qUGVudGl1bSBQcm8nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTY4
NgorCQllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc2NvJFVOQU1FX1JFTAorCWVsc2UKKwkJZWNo
byAke1VOQU1FX01BQ0hJTkV9LXBjLXN5c3YzMgorCWZpCisJZXhpdCA7OworICAgIHBjOio6Kjoq
KQorCSMgTGVmdCBoZXJlIGZvciBjb21wYXRpYmlsaXR5OgorICAgICAgICAjIHVuYW1lIC1tIHBy
aW50cyBmb3IgREpHUFAgYWx3YXlzICdwYycsIGJ1dCBpdCBwcmludHMgbm90aGluZyBhYm91dAor
ICAgICAgICAjIHRoZSBwcm9jZXNzb3IsIHNvIHdlIHBsYXkgc2FmZSBieSBhc3N1bWluZyBpNTg2
LgorCSMgTm90ZTogd2hhdGV2ZXIgdGhpcyBpcywgaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB3aGF0
IGNvbmZpZy5zdWIKKwkjIHByaW50cyBmb3IgdGhlICJkamdwcCIgaG9zdCwgb3IgZWxzZSBHREIg
Y29uZmlndXJ5IHdpbGwgZGVjaWRlIHRoYXQKKwkjIHRoaXMgaXMgYSBjcm9zcy1idWlsZC4KKwll
Y2hvIGk1ODYtcGMtbXNkb3NkamdwcAorICAgICAgICBleGl0IDs7CisgICAgSW50ZWw6TWFjaDoz
KjoqKQorCWVjaG8gaTM4Ni1wYy1tYWNoMworCWV4aXQgOzsKKyAgICBwYXJhZ29uOio6KjoqKQor
CWVjaG8gaTg2MC1pbnRlbC1vc2YxCisJZXhpdCA7OworICAgIGk4NjA6Kjo0Lio6KikgIyBpODYw
LVNWUjQKKwlpZiBncmVwIFN0YXJkZW50IC91c3IvaW5jbHVkZS9zeXMvdWFkbWluLmggPi9kZXYv
bnVsbCAyPiYxIDsgdGhlbgorCSAgZWNobyBpODYwLXN0YXJkZW50LXN5c3Yke1VOQU1FX1JFTEVB
U0V9ICMgU3RhcmRlbnQgVmlzdHJhIGk4NjAtU1ZSNAorCWVsc2UgIyBBZGQgb3RoZXIgaTg2MC1T
VlI0IHZlbmRvcnMgYmVsb3cgYXMgdGhleSBhcmUgZGlzY292ZXJlZC4KKwkgIGVjaG8gaTg2MC11
bmtub3duLXN5c3Yke1VOQU1FX1JFTEVBU0V9ICAjIFVua25vd24gaTg2MC1TVlI0CisJZmkKKwll
eGl0IDs7CisgICAgbWluaSo6Q1RJWDpTWVMqNToqKQorCSMgIm1pbmlmcmFtZSIKKwllY2hvIG02
ODAxMC1jb252ZXJnZW50LXN5c3YKKwlleGl0IDs7CisgICAgbWM2OGs6VU5JWDpTWVNURU01OjMu
NTFtKQorCWVjaG8gbTY4ay1jb252ZXJnZW50LXN5c3YKKwlleGl0IDs7CisgICAgTTY4MD8wOkQt
TklYOjUuMzoqKQorCWVjaG8gbTY4ay1kaWFiLWRuaXgKKwlleGl0IDs7CisgICAgTTY4KjoqOlIz
Vls1Njc4XSo6KikKKwl0ZXN0IC1yIC9zeXNWNjggJiYgeyBlY2hvICdtNjhrLW1vdG9yb2xhLXN5
c3YnOyBleGl0OyB9IDs7CisgICAgM1szNDVdPz86Kjo0LjA6My4wIHwgM1szNF0/P0E6Kjo0LjA6
My4wIHwgM1szNF0/PywqOio6NC4wOjMuMCB8IDNbMzRdPz8vKjoqOjQuMDozLjAgfCA0NDAwOio6
NC4wOjMuMCB8IDQ4NTA6Kjo0LjA6My4wIHwgU0tBNDA6Kjo0LjA6My4wIHwgU0RTMjoqOjQuMDoz
LjAgfCBTSEcyOio6NC4wOjMuMCB8IFM3NTAxKjoqOjQuMDozLjApCisJT1NfUkVMPScnCisJdGVz
dCAtciAvZXRjLy5yZWxpZCBcCisJJiYgT1NfUkVMPS5gc2VkIC1uICdzL1teIF0qIFteIF0qIFwo
WzAtOV1bMC05XVwpLiovXDEvcCcgPCAvZXRjLy5yZWxpZGAKKwkvYmluL3VuYW1lIC1wIDI+L2Rl
di9udWxsIHwgZ3JlcCA4NiA+L2Rldi9udWxsIFwKKwkgICYmIHsgZWNobyBpNDg2LW5jci1zeXN2
NC4zJHtPU19SRUx9OyBleGl0OyB9CisJL2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVsbCB8IC9iaW4v
Z3JlcCBlbnRpdW0gPi9kZXYvbnVsbCBcCisJICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQuMyR7
T1NfUkVMfTsgZXhpdDsgfSA7OworICAgIDNbMzRdPz86Kjo0LjA6KiB8IDNbMzRdPz8sKjoqOjQu
MDoqKQorICAgICAgICAvYmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4NiA+L2Rldi9u
dWxsIFwKKyAgICAgICAgICAmJiB7IGVjaG8gaTQ4Ni1uY3Itc3lzdjQ7IGV4aXQ7IH0gOzsKKyAg
ICBOQ1IqOio6NC4yOiogfCBNUFJBUyo6Kjo0LjI6KikKKwlPU19SRUw9Jy4zJworCXRlc3QgLXIg
L2V0Yy8ucmVsaWQgXAorCSAgICAmJiBPU19SRUw9LmBzZWQgLW4gJ3MvW14gXSogW14gXSogXChb
MC05XVswLTldXCkuKi9cMS9wJyA8IC9ldGMvLnJlbGlkYAorCS9iaW4vdW5hbWUgLXAgMj4vZGV2
L251bGwgfCBncmVwIDg2ID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8gaTQ4Ni1uY3Itc3lz
djQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCAvYmlu
L2dyZXAgZW50aXVtID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQu
MyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCAvYmluL2dy
ZXAgcHRlcm9uID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQuMyR7
T1NfUkVMfTsgZXhpdDsgfSA7OworICAgIG02OCo6THlueE9TOjIuKjoqIHwgbTY4KjpMeW54T1M6
My4wKjoqKQorCWVjaG8gbTY4ay11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0
IDs7CisgICAgbWM2ODAzMDpVTklYX1N5c3RlbV9WOjQuKjoqKQorCWVjaG8gbTY4ay1hdGFyaS1z
eXN2NAorCWV4aXQgOzsKKyAgICBUU1VOQU1JOkx5bnhPUzoyLio6KikKKwllY2hvIHNwYXJjLXVu
a25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICByczYwMDA6THlueE9T
OjIuKjoqKQorCWVjaG8gcnM2MDAwLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICBQb3dlclBDOkx5bnhPUzoyLio6KiB8IFBvd2VyUEM6THlueE9TOjMuWzAxXSo6
KiB8IFBvd2VyUEM6THlueE9TOjQuWzAyXSo6KikKKwllY2hvIHBvd2VycGMtdW5rbm93bi1seW54
b3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFNNW0JFXVM6VU5JWF9TVjoqOiopCisJ
ZWNobyBtaXBzLWRkZS1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBSTSo6UmVs
aWFudFVOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAorCWV4aXQgOzsKKyAgICBSTSo6
U0lOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAorCWV4aXQgOzsKKyAgICAqOlNJTklY
LSo6KjoqKQorCWlmIHVuYW1lIC1wIDI+L2Rldi9udWxsID4vZGV2L251bGwgOyB0aGVuCisJCVVO
QU1FX01BQ0hJTkU9YCh1bmFtZSAtcCkgMj4vZGV2L251bGxgCisJCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS1zbmktc3lzdjQKKwllbHNlCisJCWVjaG8gbnMzMmstc25pLXN5c3YKKwlmaQorCWV4aXQg
OzsKKyAgICBQRU5USVVNOio6NC4wKjoqKSAjIFVuaXN5cyBgQ2xlYXJQYXRoIEhNUCBJWCA0MDAw
JyBTVlI0L01QIGVmZm9ydAorICAgICAgICAgICAgICAgICAgICAgICMgc2F5cyA8UmljaGFyZC5N
LkJhcnRlbEBjY01haWwuQ2Vuc3VzLkdPVj4KKyAgICAgICAgZWNobyBpNTg2LXVuaXN5cy1zeXN2
NAorICAgICAgICBleGl0IDs7CisgICAgKjpVTklYX1N5c3RlbV9WOjQqOkZUWCopCisJIyBGcm9t
IEdlcmFsZCBIZXdlcyA8aGV3ZXNAb3Blbm1hcmtldC5jb20+LgorCSMgSG93IGFib3V0IGRpZmZl
cmVudGlhdGluZyBiZXR3ZWVuIHN0cmF0dXMgYXJjaGl0ZWN0dXJlcz8gLWRqbQorCWVjaG8gaHBw
YTEuMS1zdHJhdHVzLXN5c3Y0CisJZXhpdCA7OworICAgICo6KjoqOkZUWCopCisJIyBGcm9tIHNl
YW5mQHN3ZGMuc3RyYXR1cy5jb20uCisJZWNobyBpODYwLXN0cmF0dXMtc3lzdjQKKwlleGl0IDs7
CisgICAgaSo4NjpWT1M6KjoqKQorCSMgRnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS1zdHJhdHVzLXZvcworCWV4aXQgOzsKKyAgICAqOlZPUzoqOiop
CisJIyBGcm9tIFBhdWwuR3JlZW5Ac3RyYXR1cy5jb20uCisJZWNobyBocHBhMS4xLXN0cmF0dXMt
dm9zCisJZXhpdCA7OworICAgIG1jNjgqOkEvVVg6KjoqKQorCWVjaG8gbTY4ay1hcHBsZS1hdXgk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG5ld3MqOk5FV1MtT1M6Nio6KikKKwllY2hv
IG1pcHMtc29ueS1uZXdzb3M2CisJZXhpdCA7OworICAgIFJbMzRdMDAwOipTeXN0ZW1fVio6Kjoq
IHwgUjQwMDA6VU5JWF9TWVNWOio6KiB8IFIqMDAwOlVOSVhfU1Y6KjoqKQorCWlmIFsgLWQgL3Vz
ci9uZWMgXTsgdGhlbgorCSAgICAgICAgZWNobyBtaXBzLW5lYy1zeXN2JHtVTkFNRV9SRUxFQVNF
fQorCWVsc2UKKwkgICAgICAgIGVjaG8gbWlwcy11bmtub3duLXN5c3Yke1VOQU1FX1JFTEVBU0V9
CisJZmkKKyAgICAgICAgZXhpdCA7OworICAgIEJlQm94OkJlT1M6KjoqKQkjIEJlT1MgcnVubmlu
ZyBvbiBoYXJkd2FyZSBtYWRlIGJ5IEJlLCBQUEMgb25seS4KKwllY2hvIHBvd2VycGMtYmUtYmVv
cworCWV4aXQgOzsKKyAgICBCZU1hYzpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcgb24gTWFjIG9y
IE1hYyBjbG9uZSwgUFBDIG9ubHkuCisJZWNobyBwb3dlcnBjLWFwcGxlLWJlb3MKKwlleGl0IDs7
CisgICAgQmVQQzpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcgb24gSW50ZWwgUEMgY29tcGF0aWJs
ZS4KKwllY2hvIGk1ODYtcGMtYmVvcworCWV4aXQgOzsKKyAgICBCZVBDOkhhaWt1Oio6KikJIyBI
YWlrdSBydW5uaW5nIG9uIEludGVsIFBDIGNvbXBhdGlibGUuCisJZWNobyBpNTg2LXBjLWhhaWt1
CisJZXhpdCA7OworICAgIFNYLTQ6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g0LW5lYy1zdXBlcnV4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC01OlNVUEVSLVVYOio6KikKKwllY2hv
IHN4NS1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtNjpTVVBF
Ui1VWDoqOiopCisJZWNobyBzeDYtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIFNYLTc6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g3LW5lYy1zdXBlcnV4JHtVTkFNRV9S
RUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC04OlNVUEVSLVVYOio6KikKKwllY2hvIHN4OC1uZWMt
c3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtOFI6U1VQRVItVVg6Kjoq
KQorCWVjaG8gc3g4ci1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAg
UG93ZXIqOlJoYXBzb2R5Oio6KikKKwllY2hvIHBvd2VycGMtYXBwbGUtcmhhcHNvZHkke1VOQU1F
X1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6UmhhcHNvZHk6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1hcHBsZS1yaGFwc29keSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpE
YXJ3aW46KjoqKQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUgLXBgIHx8IFVOQU1FX1BST0NFU1NP
Uj11bmtub3duCisJY2FzZSAkVU5BTUVfUFJPQ0VTU09SIGluCisJICAgIGkzODYpCisJCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwkJaWYgWyAiJENDX0ZPUl9CVUlMRCIgIT0gJ25vX2NvbXBpbGVy
X2ZvdW5kJyBdOyB0aGVuCisJCSAgaWYgKGVjaG8gJyNpZmRlZiBfX0xQNjRfXyc7IGVjaG8gSVNf
NjRCSVRfQVJDSDsgZWNobyAnI2VuZGlmJykgfCBcCisJCSAgICAgIChDQ09QVFM9ICRDQ19GT1Jf
QlVJTEQgLUUgLSAyPi9kZXYvbnVsbCkgfCBcCisJCSAgICAgIGdyZXAgSVNfNjRCSVRfQVJDSCA+
L2Rldi9udWxsCisJCSAgdGhlbgorCQkgICAgICBVTkFNRV9QUk9DRVNTT1I9Ing4Nl82NCIKKwkJ
ICBmaQorCQlmaSA7OworCSAgICB1bmtub3duKSBVTkFNRV9QUk9DRVNTT1I9cG93ZXJwYyA7Owor
CWVzYWMKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS1hcHBsZS1kYXJ3aW4ke1VOQU1FX1JFTEVB
U0V9CisJZXhpdCA7OworICAgICo6cHJvY250byo6KjoqIHwgKjpRTlg6WzAxMjM0NTY3ODldKjoq
KQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUgLXBgCisJaWYgdGVzdCAiJFVOQU1FX1BST0NFU1NP
UiIgPSAieDg2IjsgdGhlbgorCQlVTkFNRV9QUk9DRVNTT1I9aTM4NgorCQlVTkFNRV9NQUNISU5F
PXBjCisJZmkKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS0ke1VOQU1FX01BQ0hJTkV9LW50by1x
bngke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6UU5YOio6NCopCisJZWNobyBpMzg2
LXBjLXFueAorCWV4aXQgOzsKKyAgICBOU0UtPzpOT05TVE9QX0tFUk5FTDoqOiopCisJZWNobyBu
c2UtdGFuZGVtLW5zayR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgTlNSLT86Tk9OU1RP
UF9LRVJORUw6KjoqKQorCWVjaG8gbnNyLXRhbmRlbS1uc2ske1VOQU1FX1JFTEVBU0V9CisJZXhp
dCA7OworICAgICo6Tm9uU3RvcC1VWDoqOiopCisJZWNobyBtaXBzLWNvbXBhcS1ub25zdG9wdXgK
KwlleGl0IDs7CisgICAgQlMyMDAwOlBPU0lYKjoqOiopCisJZWNobyBiczIwMDAtc2llbWVucy1z
eXN2CisJZXhpdCA7OworICAgIERTLyo6VU5JWF9TeXN0ZW1fVjoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LSR7VU5BTUVfU1lTVEVNfS0ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAg
ICo6UGxhbjk6KjoqKQorCSMgInVuYW1lIC1tIiBpcyBub3QgY29uc2lzdGVudCwgc28gdXNlICRj
cHV0eXBlIGluc3RlYWQuIDM4NgorCSMgaXMgY29udmVydGVkIHRvIGkzODYgZm9yIGNvbnNpc3Rl
bmN5IHdpdGggb3RoZXIgeDg2CisJIyBvcGVyYXRpbmcgc3lzdGVtcy4KKwlpZiB0ZXN0ICIkY3B1
dHlwZSIgPSAiMzg2IjsgdGhlbgorCSAgICBVTkFNRV9NQUNISU5FPWkzODYKKwllbHNlCisJICAg
IFVOQU1FX01BQ0hJTkU9IiRjcHV0eXBlIgorCWZpCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tcGxhbjkKKwlleGl0IDs7CisgICAgKjpUT1BTLTEwOio6KikKKwllY2hvIHBkcDEwLXVu
a25vd24tdG9wczEwCisJZXhpdCA7OworICAgICo6VEVORVg6KjoqKQorCWVjaG8gcGRwMTAtdW5r
bm93bi10ZW5leAorCWV4aXQgOzsKKyAgICBLUzEwOlRPUFMtMjA6KjoqIHwgS0wxMDpUT1BTLTIw
Oio6KiB8IFRZUEU0OlRPUFMtMjA6KjoqKQorCWVjaG8gcGRwMTAtZGVjLXRvcHMyMAorCWV4aXQg
OzsKKyAgICBYS0wtMTpUT1BTLTIwOio6KiB8IFRZUEU1OlRPUFMtMjA6KjoqKQorCWVjaG8gcGRw
MTAteGtsLXRvcHMyMAorCWV4aXQgOzsKKyAgICAqOlRPUFMtMjA6KjoqKQorCWVjaG8gcGRwMTAt
dW5rbm93bi10b3BzMjAKKwlleGl0IDs7CisgICAgKjpJVFM6KjoqKQorCWVjaG8gcGRwMTAtdW5r
bm93bi1pdHMKKwlleGl0IDs7CisgICAgU0VJOio6KjpTRUlVWCkKKyAgICAgICAgZWNobyBtaXBz
LXNlaS1zZWl1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpEcmFnb25GbHk6Kjoq
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWRyYWdvbmZseWBlY2hvICR7VU5BTUVf
UkVMRUFTRX18c2VkIC1lICdzL1stKF0uKi8vJ2AKKwlleGl0IDs7CisgICAgKjoqVk1TOio6KikK
KyAgICAJVU5BTUVfTUFDSElORT1gKHVuYW1lIC1wKSAyPi9kZXYvbnVsbGAKKwljYXNlICIke1VO
QU1FX01BQ0hJTkV9IiBpbgorCSAgICBBKikgZWNobyBhbHBoYS1kZWMtdm1zIDsgZXhpdCA7Owor
CSAgICBJKikgZWNobyBpYTY0LWRlYy12bXMgOyBleGl0IDs7CisJICAgIFYqKSBlY2hvIHZheC1k
ZWMtdm1zIDsgZXhpdCA7OworCWVzYWMgOzsKKyAgICAqOlhFTklYOio6U3lzVikKKwllY2hvIGkz
ODYtcGMteGVuaXgKKwlleGl0IDs7CisgICAgaSo4Njpza3lvczoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXBjLXNreW9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfWAgfCBzZWQgLWUgJ3MvIC4q
JC8vJworCWV4aXQgOzsKKyAgICBpKjg2OnJkb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5F
fS1wYy1yZG9zCisJZXhpdCA7OworICAgIGkqODY6QVJPUzoqOiopCisJZWNobyAke1VOQU1FX01B
Q0hJTkV9LXBjLWFyb3MKKwlleGl0IDs7Citlc2FjCisKKyNlY2hvICcoTm8gdW5hbWUgY29tbWFu
ZCBvciB1bmFtZSBvdXRwdXQgbm90IHJlY29nbml6ZWQuKScgMT4mMgorI2VjaG8gIiR7VU5BTUVf
TUFDSElORX06JHtVTkFNRV9TWVNURU19OiR7VU5BTUVfUkVMRUFTRX06JHtVTkFNRV9WRVJTSU9O
fSIgMT4mMgorCitldmFsICRzZXRfY2NfZm9yX2J1aWxkCitjYXQgPiRkdW1teS5jIDw8RU9GCisj
aWZkZWYgX1NFUVVFTlRfCisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorIyBpbmNsdWRlIDxzeXMv
dXRzbmFtZS5oPgorI2VuZGlmCittYWluICgpCit7CisjaWYgZGVmaW5lZCAoc29ueSkKKyNpZiBk
ZWZpbmVkIChNSVBTRUIpCisgIC8qIEJGRCB3YW50cyAiYnNkIiBpbnN0ZWFkIG9mICJuZXdzb3Mi
LiAgUGVyaGFwcyBCRkQgc2hvdWxkIGJlIGNoYW5nZWQsCisgICAgIEkgZG9uJ3Qga25vdy4uLi4g
ICovCisgIHByaW50ZiAoIm1pcHMtc29ueS1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbHNlCisjaW5j
bHVkZSA8c3lzL3BhcmFtLmg+CisgIHByaW50ZiAoIm02OGstc29ueS1uZXdzb3Mlc1xuIiwKKyNp
ZmRlZiBORVdTT1M0CisgICAgICAgICAgIjQiCisjZWxzZQorCSAgIiIKKyNlbmRpZgorICAgICAg
ICAgKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoX19hcm0pICYm
IGRlZmluZWQgKF9fYWNvcm4pICYmIGRlZmluZWQgKF9fdW5peCkKKyAgcHJpbnRmICgiYXJtLWFj
b3JuLXJpc2NpeFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBkZWZpbmVkIChocDMwMCkg
JiYgIWRlZmluZWQgKGhwdXgpCisgIHByaW50ZiAoIm02OGstaHAtYnNkXG4iKTsgZXhpdCAoMCk7
CisjZW5kaWYKKworI2lmIGRlZmluZWQgKE5lWFQpCisjaWYgIWRlZmluZWQgKF9fQVJDSElURUNU
VVJFX18pCisjZGVmaW5lIF9fQVJDSElURUNUVVJFX18gIm02OGsiCisjZW5kaWYKKyAgaW50IHZl
cnNpb247CisgIHZlcnNpb249YChob3N0aW5mbyB8IHNlZCAtbiAncy8uKk5lWFQgTWFjaCBcKFsw
LTldKlwpLiovXDEvcCcpIDI+L2Rldi9udWxsYDsKKyAgaWYgKHZlcnNpb24gPCA0KQorICAgIHBy
aW50ZiAoIiVzLW5leHQtbmV4dHN0ZXAlZFxuIiwgX19BUkNISVRFQ1RVUkVfXywgdmVyc2lvbik7
CisgIGVsc2UKKyAgICBwcmludGYgKCIlcy1uZXh0LW9wZW5zdGVwJWRcbiIsIF9fQVJDSElURUNU
VVJFX18sIHZlcnNpb24pOworICBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoTVVM
VElNQVgpIHx8IGRlZmluZWQgKG4xNikKKyNpZiBkZWZpbmVkIChVTUFYVikKKyAgcHJpbnRmICgi
bnMzMmstZW5jb3JlLXN5c3ZcbiIpOyBleGl0ICgwKTsKKyNlbHNlCisjaWYgZGVmaW5lZCAoQ01V
KQorICBwcmludGYgKCJuczMyay1lbmNvcmUtbWFjaFxuIik7IGV4aXQgKDApOworI2Vsc2UKKyAg
cHJpbnRmICgibnMzMmstZW5jb3JlLWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisjZW5kaWYK
KyNlbmRpZgorCisjaWYgZGVmaW5lZCAoX18zODZCU0RfXykKKyAgcHJpbnRmICgiaTM4Ni1wYy1i
c2RcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoc2VxdWVudCkKKyNpZiBk
ZWZpbmVkIChpMzg2KQorICBwcmludGYgKCJpMzg2LXNlcXVlbnQtZHluaXhcbiIpOyBleGl0ICgw
KTsKKyNlbmRpZgorI2lmIGRlZmluZWQgKG5zMzIwMDApCisgIHByaW50ZiAoIm5zMzJrLXNlcXVl
bnQtZHluaXhcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorI2VuZGlmCisKKyNpZiBkZWZpbmVkIChf
U0VRVUVOVF8pCisgICAgc3RydWN0IHV0c25hbWUgdW47CisKKyAgICB1bmFtZSgmdW4pOworCisg
ICAgaWYgKHN0cm5jbXAodW4udmVyc2lvbiwgIlYyIiwgMikgPT0gMCkgeworCXByaW50ZiAoImkz
ODYtc2VxdWVudC1wdHgyXG4iKTsgZXhpdCAoMCk7CisgICAgfQorICAgIGlmIChzdHJuY21wKHVu
LnZlcnNpb24sICJWMSIsIDIpID09IDApIHsgLyogWFhYIGlzIFYxIGNvcnJlY3Q/ICovCisJcHJp
bnRmICgiaTM4Ni1zZXF1ZW50LXB0eDFcbiIpOyBleGl0ICgwKTsKKyAgICB9CisgICAgcHJpbnRm
ICgiaTM4Ni1zZXF1ZW50LXB0eFxuIik7IGV4aXQgKDApOworCisjZW5kaWYKKworI2lmIGRlZmlu
ZWQgKHZheCkKKyMgaWYgIWRlZmluZWQgKHVsdHJpeCkKKyMgIGluY2x1ZGUgPHN5cy9wYXJhbS5o
PgorIyAgaWYgZGVmaW5lZCAoQlNEKQorIyAgIGlmIEJTRCA9PSA0MworICAgICAgcHJpbnRmICgi
dmF4LWRlYy1ic2Q0LjNcbiIpOyBleGl0ICgwKTsKKyMgICBlbHNlCisjICAgIGlmIEJTRCA9PSAx
OTkwMDYKKyAgICAgIHByaW50ZiAoInZheC1kZWMtYnNkNC4zcmVub1xuIik7IGV4aXQgKDApOwor
IyAgICBlbHNlCisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZFxuIik7IGV4aXQgKDApOworIyAg
ICBlbmRpZgorIyAgIGVuZGlmCisjICBlbHNlCisgICAgcHJpbnRmICgidmF4LWRlYy1ic2RcbiIp
OyBleGl0ICgwKTsKKyMgIGVuZGlmCisjIGVsc2UKKyAgICBwcmludGYgKCJ2YXgtZGVjLXVsdHJp
eFxuIik7IGV4aXQgKDApOworIyBlbmRpZgorI2VuZGlmCisKKyNpZiBkZWZpbmVkIChhbGxpYW50
KSAmJiBkZWZpbmVkIChpODYwKQorICBwcmludGYgKCJpODYwLWFsbGlhbnQtYnNkXG4iKTsgZXhp
dCAoMCk7CisjZW5kaWYKKworICBleGl0ICgxKTsKK30KK0VPRgorCiskQ0NfRk9SX0JVSUxEIC1v
ICRkdW1teSAkZHVtbXkuYyAyPi9kZXYvbnVsbCAmJiBTWVNURU1fTkFNRT1gJGR1bW15YCAmJgor
CXsgZWNobyAiJFNZU1RFTV9OQU1FIjsgZXhpdDsgfQorCisjIEFwb2xsb3MgcHV0IHRoZSBzeXN0
ZW0gdHlwZSBpbiB0aGUgZW52aXJvbm1lbnQuCisKK3Rlc3QgLWQgL3Vzci9hcG9sbG8gJiYgeyBl
Y2hvICR7SVNQfS1hcG9sbG8tJHtTWVNUWVBFfTsgZXhpdDsgfQorCisjIENvbnZleCB2ZXJzaW9u
cyB0aGF0IHByZWRhdGUgdW5hbWUgY2FuIHVzZSBnZXRzeXNpbmZvKDEpCisKK2lmIFsgLXggL3Vz
ci9jb252ZXgvZ2V0c3lzaW5mbyBdCit0aGVuCisgICAgY2FzZSBgZ2V0c3lzaW5mbyAtZiBjcHVf
dHlwZWAgaW4KKyAgICBjMSopCisJZWNobyBjMS1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGMy
KikKKwlpZiBnZXRzeXNpbmZvIC1mIHNjYWxhcl9hY2MKKwl0aGVuIGVjaG8gYzMyLWNvbnZleC1i
c2QKKwllbHNlIGVjaG8gYzItY29udmV4LWJzZAorCWZpCisJZXhpdCA7OworICAgIGMzNCopCisJ
ZWNobyBjMzQtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBjMzgqKQorCWVjaG8gYzM4LWNvbnZl
eC1ic2QKKwlleGl0IDs7CisgICAgYzQqKQorCWVjaG8gYzQtY29udmV4LWJzZAorCWV4aXQgOzsK
KyAgICBlc2FjCitmaQorCitjYXQgPiYyIDw8RU9GCiskMDogdW5hYmxlIHRvIGd1ZXNzIHN5c3Rl
bSB0eXBlCisKK1RoaXMgc2NyaXB0LCBsYXN0IG1vZGlmaWVkICR0aW1lc3RhbXAsIGhhcyBmYWls
ZWQgdG8gcmVjb2duaXplCit0aGUgb3BlcmF0aW5nIHN5c3RlbSB5b3UgYXJlIHVzaW5nLiBJdCBp
cyBhZHZpc2VkIHRoYXQgeW91Citkb3dubG9hZCB0aGUgbW9zdCB1cCB0byBkYXRlIHZlcnNpb24g
b2YgdGhlIGNvbmZpZyBzY3JpcHRzIGZyb20KKworICBodHRwOi8vZ2l0LnNhdmFubmFoLmdudS5v
cmcvZ2l0d2ViLz9wPWNvbmZpZy5naXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmlnLmd1ZXNzO2hiPUhF
QUQKK2FuZAorICBodHRwOi8vZ2l0LnNhdmFubmFoLmdudS5vcmcvZ2l0d2ViLz9wPWNvbmZpZy5n
aXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmlnLnN1YjtoYj1IRUFECisKK0lmIHRoZSB2ZXJzaW9uIHlv
dSBydW4gKCQwKSBpcyBhbHJlYWR5IHVwIHRvIGRhdGUsIHBsZWFzZQorc2VuZCB0aGUgZm9sbG93
aW5nIGRhdGEgYW5kIGFueSBpbmZvcm1hdGlvbiB5b3UgdGhpbmsgbWlnaHQgYmUKK3BlcnRpbmVu
dCB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9yZz4gaW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgbmVl
ZGVkCitpbmZvcm1hdGlvbiB0byBoYW5kbGUgeW91ciBzeXN0ZW0uCisKK2NvbmZpZy5ndWVzcyB0
aW1lc3RhbXAgPSAkdGltZXN0YW1wCisKK3VuYW1lIC1tID0gYCh1bmFtZSAtbSkgMj4vZGV2L251
bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXIgPSBgKHVuYW1lIC1yKSAyPi9kZXYvbnVsbCB8
fCBlY2hvIHVua25vd25gCit1bmFtZSAtcyA9IGAodW5hbWUgLXMpIDI+L2Rldi9udWxsIHx8IGVj
aG8gdW5rbm93bmAKK3VuYW1lIC12ID0gYCh1bmFtZSAtdikgMj4vZGV2L251bGwgfHwgZWNobyB1
bmtub3duYAorCisvdXNyL2Jpbi91bmFtZSAtcCA9IGAoL3Vzci9iaW4vdW5hbWUgLXApIDI+L2Rl
di9udWxsYAorL2Jpbi91bmFtZSAtWCAgICAgPSBgKC9iaW4vdW5hbWUgLVgpIDI+L2Rldi9udWxs
YAorCitob3N0aW5mbyAgICAgICAgICAgICAgID0gYChob3N0aW5mbykgMj4vZGV2L251bGxgCisv
YmluL3VuaXZlcnNlICAgICAgICAgID0gYCgvYmluL3VuaXZlcnNlKSAyPi9kZXYvbnVsbGAKKy91
c3IvYmluL2FyY2ggLWsgICAgICAgPSBgKC91c3IvYmluL2FyY2ggLWspIDI+L2Rldi9udWxsYAor
L2Jpbi9hcmNoICAgICAgICAgICAgICA9IGAoL2Jpbi9hcmNoKSAyPi9kZXYvbnVsbGAKKy91c3Iv
YmluL29zbGV2ZWwgICAgICAgPSBgKC91c3IvYmluL29zbGV2ZWwpIDI+L2Rldi9udWxsYAorL3Vz
ci9jb252ZXgvZ2V0c3lzaW5mbyA9IGAoL3Vzci9jb252ZXgvZ2V0c3lzaW5mbykgMj4vZGV2L251
bGxgCisKK1VOQU1FX01BQ0hJTkUgPSAke1VOQU1FX01BQ0hJTkV9CitVTkFNRV9SRUxFQVNFID0g
JHtVTkFNRV9SRUxFQVNFfQorVU5BTUVfU1lTVEVNICA9ICR7VU5BTUVfU1lTVEVNfQorVU5BTUVf
VkVSU0lPTiA9ICR7VU5BTUVfVkVSU0lPTn0KK0VPRgorCitleGl0IDEKKworIyBMb2NhbCB2YXJp
YWJsZXM6CisjIGV2YWw6IChhZGQtaG9vayAnd3JpdGUtZmlsZS1ob29rcyAndGltZS1zdGFtcCkK
KyMgdGltZS1zdGFtcC1zdGFydDogInRpbWVzdGFtcD0nIgorIyB0aW1lLXN0YW1wLWZvcm1hdDog
IiU6eS0lMDJtLSUwMmQiCisjIHRpbWUtc3RhbXAtZW5kOiAiJyIKKyMgRW5kOgpkaWZmIC1yIDVi
MjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvY29uZmlnLmguaW4KLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlnLmguaW4J
VHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNDY4IEBACisvKiBjb25m
aWcuaC5pbi4gIEdlbmVyYXRlZCBmcm9tIGNvbmZpZ3VyZS5hYyBieSBhdXRvaGVhZGVyLiAgKi8K
KworLyogRGVmaW5lIHRvIG9uZSBvZiBgX2dldGI2NycsIGBHRVRCNjcnLCBgZ2V0YjY3JyBmb3Ig
Q3JheS0yIGFuZCBDcmF5LVlNUAorICAgc3lzdGVtcy4gVGhpcyBmdW5jdGlvbiBpcyByZXF1aXJl
ZCBmb3IgYGFsbG9jYS5jJyBzdXBwb3J0IG9uIHRob3NlIHN5c3RlbXMuCisgICAqLworI3VuZGVm
IENSQVlfU1RBQ0tTRUdfRU5ECisKKy8qIERlZmluZSB0byAxIGlmIHVzaW5nIGBhbGxvY2EuYycu
ICovCisjdW5kZWYgQ19BTExPQ0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBh
bGFybScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9BTEFSTQorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSBgYWxsb2NhJywgYXMgYSBmdW5jdGlvbiBvciBtYWNyby4gKi8KKyN1bmRlZiBI
QVZFX0FMTE9DQQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSA8YWxsb2NhLmg+IGFuZCBp
dCBzaG91bGQgYmUgdXNlZCAobm90IG9uIFVsdHJpeCkuCisgICAqLworI3VuZGVmIEhBVkVfQUxM
T0NBX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxhcnBhL2luZXQuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9BUlBBX0lORVRfSAorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYGF0ZXhpdCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9BVEVYSVQK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBiemVybycgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9CWkVSTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGNsb2Nr
X2dldHRpbWUnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQ0xPQ0tfR0VUVElNRQorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGR1cDInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfRFVQMgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGZjbnRsLmg+IGhlYWRl
ciBmaWxlLiAqLworI3VuZGVmIEhBVkVfRkNOVExfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug
aGF2ZSB0aGUgYGZkYXRhc3luYycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9GREFUQVNZTkMK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmb3JrJyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX0ZPUksKKworLyogRGVmaW5lIHRvIDEgaWYgZnNlZWtvIChhbmQgcHJlc3VtYWJs
eSBmdGVsbG8pIGV4aXN0cyBhbmQgaXMgZGVjbGFyZWQuICovCisjdW5kZWYgSEFWRV9GU0VFS08K
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmdHJ1bmNhdGUnIGZ1bmN0aW9uLiAq
LworI3VuZGVmIEhBVkVfRlRSVU5DQVRFCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgZ2V0Y3dkJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVENXRAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldGhvc3RieW5hbWUnIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfR0VUSE9TVEJZTkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdl
dGhvc3RuYW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVEhPU1ROQU1FCisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZ2V0cGFnZXNpemUnIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfR0VUUEFHRVNJWkUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBn
ZXR0aW1lb2ZkYXknIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfR0VUVElNRU9GREFZCisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgaW5ldF9udG9hJyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX0lORVRfTlRPQQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGlu
dHR5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfSU5UVFlQRVNfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGlzYXNjaWknIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfSVNBU0NJSQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGNyeXB0bycg
bGlicmFyeSAoLWxjcnlwdG8pLiAqLworI3VuZGVmIEhBVkVfTElCQ1JZUFRPCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bGliaW50bC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRl
ZiBIQVZFX0xJQklOVExfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJ0JyBs
aWJyYXJ5ICgtbHJ0KS4gKi8KKyN1bmRlZiBIQVZFX0xJQlJUCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgdXVpZCcgbGlicmFyeSAoLWx1dWlkKS4gKi8KKyN1bmRlZiBIQVZFX0xJ
QlVVSUQKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB5YWpsJyBsaWJyYXJ5ICgt
bHlhamwpLiAqLworI3VuZGVmIEhBVkVfTElCWUFKTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug
aGF2ZSB0aGUgYHonIGxpYnJhcnkgKC1seikuICovCisjdW5kZWYgSEFWRV9MSUJaCisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bGltaXRzLmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfTElNSVRTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBsb2Nh
bHRpbWVfcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9MT0NBTFRJTUVfUgorCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3VyIHN5c3RlbSBoYXMgYSBHTlUgbGliYyBjb21wYXRpYmxlIGBtYWxsb2Mn
IGZ1bmN0aW9uLCBhbmQKKyAgIHRvIDAgb3RoZXJ3aXNlLiAqLworI3VuZGVmIEhBVkVfTUFMTE9D
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bWFsbG9jLmg+IGhlYWRlciBmaWxl
LiAqLworI3VuZGVmIEhBVkVfTUFMTE9DX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBtZW1jaHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTUVNQ0hSCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtbW92ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFW
RV9NRU1NT1ZFCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bWVtb3J5Lmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTUVNT1JZX0gKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIGBtZW1zZXQnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTUVNU0VUCisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWtkaXInIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfTUtESVIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBta2ZpZm8n
IGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTUtGSUZPCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIGEgd29ya2luZyBgbW1hcCcgc3lzdGVtIGNhbGwuICovCisjdW5kZWYgSEFWRV9NTUFQ
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbXVubWFwJyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX01VTk1BUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG5l
dGRiLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTkVUREJfSAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG5ldGluZXQvaW4uaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9ORVRJTkVUX0lOX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBw
YXRoY29uZicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9QQVRIQ09ORgorCisvKiBEZWZpbmUg
dG8gMSBpZiB0aGUgc3lzdGVtIGhhcyB0aGUgdHlwZSBgcHRyZGlmZl90Jy4gKi8KKyN1bmRlZiBI
QVZFX1BUUkRJRkZfVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3VyIHN5c3RlbSBoYXMgYSBHTlUg
bGliYyBjb21wYXRpYmxlIGByZWFsbG9jJyBmdW5jdGlvbiwKKyAgIGFuZCB0byAwIG90aGVyd2lz
ZS4gKi8KKyN1bmRlZiBIQVZFX1JFQUxMT0MKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGByZWFscGF0aCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9SRUFMUEFUSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJlZ2NvbXAnIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfUkVHQ09NUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJtZGlyJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1JNRElSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc2VsZWN0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NFTEVDVAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHNldGVudicgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9TRVRFTlYKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzb2NrZXQnIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU09DS0VUCisKKy8qIERlZmluZSB0byAxIGlmIHN0ZGJv
b2wuaCBjb25mb3JtcyB0byBDOTkuICovCisjdW5kZWYgSEFWRV9TVERCT09MX0gKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdGRkZWYuaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9TVERERUZfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGlu
dC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURElOVF9ICisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkbGliLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhB
VkVfU1RETElCX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJjYXNlY21w
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUkNBU0VDTVAKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIGBzdHJjaHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ0hS
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyY3NwbicgZnVuY3Rpb24uICov
CisjdW5kZWYgSEFWRV9TVFJDU1BOCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBg
c3RyZHVwJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUkRVUAorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmVycm9yJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NU
UkVSUk9SCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5ncy5oPiBoZWFk
ZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NUUklOR1NfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPHN0cmluZy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NUUklO
R19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RybmR1cCcgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9TVFJORFVQCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgc3RycGJyaycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJQQlJLCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RycmNocicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFW
RV9TVFJSQ0hSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3Ryc3BuJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlNQTgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHN0cnN0cicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJTVFIKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJ0b2wnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfU1RSVE9MCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RydG91bCcgZnVu
Y3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJUT1VMCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc3RydG91bGwnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSVE9VTEwKKwor
LyogRGVmaW5lIHRvIDEgaWYgYHN0X2Jsa3NpemUnIGlzIGEgbWVtYmVyIG9mIGBzdHJ1Y3Qgc3Rh
dCcuICovCisjdW5kZWYgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFCisKKy8qIERlZmluZSB0
byAxIGlmIGBzdF9ibG9ja3MnIGlzIGEgbWVtYmVyIG9mIGBzdHJ1Y3Qgc3RhdCcuICovCisjdW5k
ZWYgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MKKworLyogRGVmaW5lIHRvIDEgaWYgYHN0X3Jk
ZXYnIGlzIGEgbWVtYmVyIG9mIGBzdHJ1Y3Qgc3RhdCcuICovCisjdW5kZWYgSEFWRV9TVFJVQ1Rf
U1RBVF9TVF9SREVWCisKKy8qIERlZmluZSB0byAxIGlmIHlvdXIgYHN0cnVjdCBzdGF0JyBoYXMg
YHN0X2Jsb2NrcycuIERlcHJlY2F0ZWQsIHVzZQorICAgYEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxP
Q0tTJyBpbnN0ZWFkLiAqLworI3VuZGVmIEhBVkVfU1RfQkxPQ0tTCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8c3lzbG9nLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1lTTE9HX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvZmlsZS5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19GSUxFX0gKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxzeXMvaW9jdGwuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFW
RV9TWVNfSU9DVExfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9tb3Vu
dC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19NT1VOVF9ICisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3BhcmFtLmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfU1lTX1BBUkFNX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxz
eXMvc29ja2V0Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1NPQ0tFVF9ICisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3N0YXR2ZnMuaD4gaGVhZGVyIGZp
bGUuICovCisjdW5kZWYgSEFWRV9TWVNfU1RBVFZGU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSA8c3lzL3N0YXQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNf
U1RBVF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3RpbWUuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfVElNRV9ICisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSA8c3lzL3R5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1lTX1RZUEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx0ZXJtaW9zLmg+
IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfVEVSTUlPU19ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgdHpzZXQnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVFpTRVQK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB1bmFtZScgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9VTkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHVuaXN0
ZC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1VOSVNURF9ICisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSBgdmZvcmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVkZP
UksKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx2Zm9yay5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1ZGT1JLX0gKKworLyogRGVmaW5lIHRvIDEgaWYgYGZvcmsnIHdv
cmtzLiAqLworI3VuZGVmIEhBVkVfV09SS0lOR19GT1JLCisKKy8qIERlZmluZSB0byAxIGlmIGB2
Zm9yaycgd29ya3MuICovCisjdW5kZWYgSEFWRV9XT1JLSU5HX1ZGT1JLCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4gaGVhZGVyIGZpbGUuICov
CisjdW5kZWYgSEFWRV9ZQUpMX1lBSkxfVkVSU0lPTl9ICisKKy8qIERlZmluZSB0byAxIGlmIHRo
ZSBzeXN0ZW0gaGFzIHRoZSB0eXBlIGBfQm9vbCcuICovCisjdW5kZWYgSEFWRV9fQk9PTAorCisv
KiBEZWZpbmUgdG8gMSBpZiBgbHN0YXQnIGRlcmVmZXJlbmNlcyBhIHN5bWxpbmsgc3BlY2lmaWVk
IHdpdGggYSB0cmFpbGluZworICAgc2xhc2guICovCisjdW5kZWYgTFNUQVRfRk9MTE9XU19TTEFT
SEVEX1NZTUxJTksKKworLyogRGVmaW5lIHRvIDEgaWYgYG1ham9yJywgYG1pbm9yJywgYW5kIGBt
YWtlZGV2JyBhcmUgZGVjbGFyZWQgaW4gPG1rZGV2Lmg+LgorICAgKi8KKyN1bmRlZiBNQUpPUl9J
Tl9NS0RFVgorCisvKiBEZWZpbmUgdG8gMSBpZiBgbWFqb3InLCBgbWlub3InLCBhbmQgYG1ha2Vk
ZXYnIGFyZSBkZWNsYXJlZCBpbgorICAgPHN5c21hY3Jvcy5oPi4gKi8KKyN1bmRlZiBNQUpPUl9J
Tl9TWVNNQUNST1MKKworLyogRGVmaW5lIHRvIHRoZSBhZGRyZXNzIHdoZXJlIGJ1ZyByZXBvcnRz
IGZvciB0aGlzIHBhY2thZ2Ugc2hvdWxkIGJlIHNlbnQuICovCisjdW5kZWYgUEFDS0FHRV9CVUdS
RVBPUlQKKworLyogRGVmaW5lIHRvIHRoZSBmdWxsIG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLwor
I3VuZGVmIFBBQ0tBR0VfTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFtZSBhbmQgdmVy
c2lvbiBvZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9TVFJJTkcKKworLyogRGVm
aW5lIHRvIHRoZSBvbmUgc3ltYm9sIHNob3J0IG5hbWUgb2YgdGhpcyBwYWNrYWdlLiAqLworI3Vu
ZGVmIFBBQ0tBR0VfVEFSTkFNRQorCisvKiBEZWZpbmUgdG8gdGhlIGhvbWUgcGFnZSBmb3IgdGhp
cyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfVVJMCisKKy8qIERlZmluZSB0byB0aGUgdmVy
c2lvbiBvZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9WRVJTSU9OCisKKy8qIElm
IHVzaW5nIHRoZSBDIGltcGxlbWVudGF0aW9uIG9mIGFsbG9jYSwgZGVmaW5lIGlmIHlvdSBrbm93
IHRoZQorICAgZGlyZWN0aW9uIG9mIHN0YWNrIGdyb3d0aCBmb3IgeW91ciBzeXN0ZW07IG90aGVy
d2lzZSBpdCB3aWxsIGJlCisgICBhdXRvbWF0aWNhbGx5IGRlZHVjZWQgYXQgcnVudGltZS4KKwlT
VEFDS19ESVJFQ1RJT04gPiAwID0+IGdyb3dzIHRvd2FyZCBoaWdoZXIgYWRkcmVzc2VzCisJU1RB
Q0tfRElSRUNUSU9OIDwgMCA9PiBncm93cyB0b3dhcmQgbG93ZXIgYWRkcmVzc2VzCisJU1RBQ0tf
RElSRUNUSU9OID0gMCA9PiBkaXJlY3Rpb24gb2YgZ3Jvd3RoIHVua25vd24gKi8KKyN1bmRlZiBT
VEFDS19ESVJFQ1RJT04KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIEFOU0kgQyBo
ZWFkZXIgZmlsZXMuICovCisjdW5kZWYgU1REQ19IRUFERVJTCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBjYW4gc2FmZWx5IGluY2x1ZGUgYm90aCA8c3lzL3RpbWUuaD4gYW5kIDx0aW1lLmg+LiAq
LworI3VuZGVmIFRJTUVfV0lUSF9TWVNfVElNRQorCisvKiBFbmFibGUgZXh0ZW5zaW9ucyBvbiBB
SVggMywgSW50ZXJpeC4gICovCisjaWZuZGVmIF9BTExfU09VUkNFCisjIHVuZGVmIF9BTExfU09V
UkNFCisjZW5kaWYKKy8qIEVuYWJsZSBHTlUgZXh0ZW5zaW9ucyBvbiBzeXN0ZW1zIHRoYXQgaGF2
ZSB0aGVtLiAgKi8KKyNpZm5kZWYgX0dOVV9TT1VSQ0UKKyMgdW5kZWYgX0dOVV9TT1VSQ0UKKyNl
bmRpZgorLyogRW5hYmxlIHRocmVhZGluZyBleHRlbnNpb25zIG9uIFNvbGFyaXMuICAqLworI2lm
bmRlZiBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MKKyMgdW5kZWYgX1BPU0lYX1BUSFJFQURfU0VN
QU5USUNTCisjZW5kaWYKKy8qIEVuYWJsZSBleHRlbnNpb25zIG9uIEhQIE5vblN0b3AuICAqLwor
I2lmbmRlZiBfVEFOREVNX1NPVVJDRQorIyB1bmRlZiBfVEFOREVNX1NPVVJDRQorI2VuZGlmCisv
KiBFbmFibGUgZ2VuZXJhbCBleHRlbnNpb25zIG9uIFNvbGFyaXMuICAqLworI2lmbmRlZiBfX0VY
VEVOU0lPTlNfXworIyB1bmRlZiBfX0VYVEVOU0lPTlNfXworI2VuZGlmCisKKworLyogRGVmaW5l
IHRvIDEgdG8gbWFrZSBmc2Vla28gdmlzaWJsZSBvbiBzb21lIGhvc3RzIChlLmcuIGdsaWJjIDIu
MikuICovCisjdW5kZWYgX0xBUkdFRklMRV9TT1VSQ0UKKworLyogRGVmaW5lIHRvIDEgaWYgb24g
TUlOSVguICovCisjdW5kZWYgX01JTklYCisKKy8qIERlZmluZSB0byAyIGlmIHRoZSBzeXN0ZW0g
ZG9lcyBub3QgcHJvdmlkZSBQT1NJWC4xIGZlYXR1cmVzIGV4Y2VwdCB3aXRoCisgICB0aGlzIGRl
ZmluZWQuICovCisjdW5kZWYgX1BPU0lYXzFfU09VUkNFCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBuZWVkIHRvIGluIG9yZGVyIGZvciBgc3RhdCcgYW5kIG90aGVyIHRoaW5ncyB0byB3b3JrLiAq
LworI3VuZGVmIF9QT1NJWF9TT1VSQ0UKKworLyogRGVmaW5lIGZvciBTb2xhcmlzIDIuNS4xIHNv
IHRoZSB1aW50MzJfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+
LCBvciA8c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93
ZWQsIHRoZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8K
KyN1bmRlZiBfVUlOVDMyX1QKKworLyogRGVmaW5lIGZvciBTb2xhcmlzIDIuNS4xIHNvIHRoZSB1
aW50NjRfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+LCBvciA8
c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93ZWQsIHRo
ZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8KKyN1bmRl
ZiBfVUlOVDY0X1QKKworLyogRGVmaW5lIGZvciBTb2xhcmlzIDIuNS4xIHNvIHRoZSB1aW50OF90
IHR5cGVkZWYgZnJvbSA8c3lzL3N5bmNoLmg+LAorICAgPHB0aHJlYWQuaD4sIG9yIDxzZW1hcGhv
cmUuaD4gaXMgbm90IHVzZWQuIElmIHRoZSB0eXBlZGVmIHdlcmUgYWxsb3dlZCwgdGhlCisgICAj
ZGVmaW5lIGJlbG93IHdvdWxkIGNhdXNlIGEgc3ludGF4IGVycm9yLiAqLworI3VuZGVmIF9VSU5U
OF9UCisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5l
LiAqLworI3VuZGVmIGdpZF90CisKKy8qIERlZmluZSB0byBgX19pbmxpbmVfXycgb3IgYF9faW5s
aW5lJyBpZiB0aGF0J3Mgd2hhdCB0aGUgQyBjb21waWxlcgorICAgY2FsbHMgaXQsIG9yIHRvIG5v
dGhpbmcgaWYgJ2lubGluZScgaXMgbm90IHN1cHBvcnRlZCB1bmRlciBhbnkgbmFtZS4gICovCisj
aWZuZGVmIF9fY3BsdXNwbHVzCisjdW5kZWYgaW5saW5lCisjZW5kaWYKKworLyogRGVmaW5lIHRv
IHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDE2IGJp
dHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRv
IG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MTZfdAorCisvKiBEZWZpbmUgdG8gdGhlIHR5
cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkgMzIgYml0cyBpZgor
ICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRl
ZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQzMl90CisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBh
IHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA2NCBiaXRzIGlmCisgICBzdWNo
IGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0
LiAqLworI3VuZGVmIGludDY0X3QKKworLyogRGVmaW5lIHRvIHRoZSB0eXBlIG9mIGEgc2lnbmVk
IGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDggYml0cyBpZiBzdWNoCisgICBhIHR5cGUg
ZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRlZmluZSBpdC4gKi8KKyN1
bmRlZiBpbnQ4X3QKKworLyogRGVmaW5lIHRvIHJwbF9tYWxsb2MgaWYgdGhlIHJlcGxhY2VtZW50
IGZ1bmN0aW9uIHNob3VsZCBiZSB1c2VkLiAqLworI3VuZGVmIG1hbGxvYworCisvKiBEZWZpbmUg
dG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgbW9k
ZV90CisKKy8qIERlZmluZSB0byBgbG9uZyBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3Qg
ZGVmaW5lLiAqLworI3VuZGVmIG9mZl90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5
cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBwaWRfdAorCisvKiBEZWZpbmUgdG8g
cnBsX3JlYWxsb2MgaWYgdGhlIHJlcGxhY2VtZW50IGZ1bmN0aW9uIHNob3VsZCBiZSB1c2VkLiAq
LworI3VuZGVmIHJlYWxsb2MKKworLyogRGVmaW5lIHRvIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBD
OTkgJ3Jlc3RyaWN0JyBrZXl3b3JkLCBvciB0bworICAgbm90aGluZyBpZiB0aGlzIGlzIG5vdCBz
dXBwb3J0ZWQuICBEbyBub3QgZGVmaW5lIGlmIHJlc3RyaWN0IGlzCisgICBzdXBwb3J0ZWQgZGly
ZWN0bHkuICAqLworI3VuZGVmIHJlc3RyaWN0CisvKiBXb3JrIGFyb3VuZCBhIGJ1ZyBpbiBTdW4g
QysrOiBpdCBkb2VzIG5vdCBzdXBwb3J0IF9SZXN0cmljdCBvcgorICAgX19yZXN0cmljdF9fLCBl
dmVuIHRob3VnaCB0aGUgY29ycmVzcG9uZGluZyBTdW4gQyBjb21waWxlciBlbmRzIHVwIHdpdGgK
KyAgICIjZGVmaW5lIHJlc3RyaWN0IF9SZXN0cmljdCIgb3IgIiNkZWZpbmUgcmVzdHJpY3QgX19y
ZXN0cmljdF9fIiBpbiB0aGUKKyAgIHByZXZpb3VzIGxpbmUuICBQZXJoYXBzIHNvbWUgZnV0dXJl
IHZlcnNpb24gb2YgU3VuIEMrKyB3aWxsIHdvcmsgd2l0aAorICAgcmVzdHJpY3Q7IGlmIHNvLCBo
b3BlZnVsbHkgaXQgZGVmaW5lcyBfX1JFU1RSSUNUIGxpa2UgU3VuIEMgZG9lcy4gICovCisjaWYg
ZGVmaW5lZCBfX1NVTlBST19DQyAmJiAhZGVmaW5lZCBfX1JFU1RSSUNUCisjIGRlZmluZSBfUmVz
dHJpY3QKKyMgZGVmaW5lIF9fcmVzdHJpY3RfXworI2VuZGlmCisKKy8qIERlZmluZSB0byBgdW5z
aWduZWQgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBz
aXplX3QKKworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVm
aW5lLiAqLworI3VuZGVmIHNzaXplX3QKKworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlw
ZXMuaD4gZG9lc24ndCBkZWZpbmUuICovCisjdW5kZWYgdWlkX3QKKworLyogRGVmaW5lIHRvIHRo
ZSB0eXBlIG9mIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDE2IGJp
dHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRv
IG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDE2X3QKKworLyogRGVmaW5lIHRvIHRoZSB0
eXBlIG9mIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDMyIGJpdHMg
aWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5v
dCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDMyX3QKKworLyogRGVmaW5lIHRvIHRoZSB0eXBl
IG9mIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDY0IGJpdHMgaWYK
KyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5vdCBk
ZWZpbmUgaXQuICovCisjdW5kZWYgdWludDY0X3QKKworLyogRGVmaW5lIHRvIHRoZSB0eXBlIG9m
IGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDggYml0cyBpZgorICAg
c3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRlZmlu
ZSBpdC4gKi8KKyN1bmRlZiB1aW50OF90CisKKy8qIERlZmluZSBhcyBgZm9yaycgaWYgYHZmb3Jr
JyBkb2VzIG5vdCB3b3JrLiAqLworI3VuZGVmIHZmb3JrCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1y
IDZmZGUwMTdjNDE5ZSB0b29scy9jb25maWcuc3ViCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5zdWIJVHVlIEphbiAxMCAxOTox
MzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTcxNCBAQAorIyEgL2Jpbi9zaAorIyBDb25maWd1
cmF0aW9uIHZhbGlkYXRpb24gc3Vicm91dGluZSBzY3JpcHQuCisjICAgQ29weXJpZ2h0IChDKSAx
OTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LAorIyAgIDIwMDAs
IDIwMDEsIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDksIDIw
MTAKKyMgICBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKwordGltZXN0YW1wPScyMDEw
LTAxLTIyJworCisjIFRoaXMgZmlsZSBpcyAoaW4gcHJpbmNpcGxlKSBjb21tb24gdG8gQUxMIEdO
VSBzb2Z0d2FyZS4KKyMgVGhlIHByZXNlbmNlIG9mIGEgbWFjaGluZSBpbiB0aGlzIGZpbGUgc3Vn
Z2VzdHMgdGhhdCBTT01FIEdOVSBzb2Z0d2FyZQorIyBjYW4gaGFuZGxlIHRoYXQgbWFjaGluZS4g
IEl0IGRvZXMgbm90IGltcGx5IEFMTCBHTlUgc29mdHdhcmUgY2FuLgorIworIyBUaGlzIGZpbGUg
aXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQor
IyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFz
IHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVy
c2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2
ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh
dCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyMgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0
IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5F
U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorIyBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2
ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorIyBhbG9uZyB3aXRo
IHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorIyBGb3Vu
ZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQgLSBGaWZ0aCBGbG9vciwgQm9zdG9uLCBN
QQorIyAwMjExMC0xMzAxLCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZp
bGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24g
c2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisj
IHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9m
IHRoYXQgcHJvZ3JhbS4KKworCisjIFBsZWFzZSBzZW5kIHBhdGNoZXMgdG8gPGNvbmZpZy1wYXRj
aGVzQGdudS5vcmc+LiAgU3VibWl0IGEgY29udGV4dAorIyBkaWZmIGFuZCBhIHByb3Blcmx5IGZv
cm1hdHRlZCBHTlUgQ2hhbmdlTG9nIGVudHJ5LgorIworIyBDb25maWd1cmF0aW9uIHN1YnJvdXRp
bmUgdG8gdmFsaWRhdGUgYW5kIGNhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gdHlwZS4KKyMg
U3VwcGx5IHRoZSBzcGVjaWZpZWQgY29uZmlndXJhdGlvbiB0eXBlIGFzIGFuIGFyZ3VtZW50Lgor
IyBJZiBpdCBpcyBpbnZhbGlkLCB3ZSBwcmludCBhbiBlcnJvciBtZXNzYWdlIG9uIHN0ZGVyciBh
bmQgZXhpdCB3aXRoIGNvZGUgMS4KKyMgT3RoZXJ3aXNlLCB3ZSBwcmludCB0aGUgY2Fub25pY2Fs
IGNvbmZpZyB0eXBlIG9uIHN0ZG91dCBhbmQgc3VjY2VlZC4KKworIyBZb3UgY2FuIGdldCB0aGUg
bGF0ZXN0IHZlcnNpb24gb2YgdGhpcyBzY3JpcHQgZnJvbToKKyMgaHR0cDovL2dpdC5zYXZhbm5h
aC5nbnUub3JnL2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZpZy5zdWI7
aGI9SEVBRAorCisjIFRoaXMgZmlsZSBpcyBzdXBwb3NlZCB0byBiZSB0aGUgc2FtZSBmb3IgYWxs
IEdOVSBwYWNrYWdlcworIyBhbmQgcmVjb2duaXplIGFsbCB0aGUgQ1BVIHR5cGVzLCBzeXN0ZW0g
dHlwZXMgYW5kIGFsaWFzZXMKKyMgdGhhdCBhcmUgbWVhbmluZ2Z1bCB3aXRoICphbnkqIEdOVSBz
b2Z0d2FyZS4KKyMgRWFjaCBwYWNrYWdlIGlzIHJlc3BvbnNpYmxlIGZvciByZXBvcnRpbmcgd2hp
Y2ggdmFsaWQgY29uZmlndXJhdGlvbnMKKyMgaXQgZG9lcyBub3Qgc3VwcG9ydC4gIFRoZSB1c2Vy
IHNob3VsZCBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoCisjIGEgZmFpbHVyZSB0byBzdXBwb3J0IGEg
dmFsaWQgY29uZmlndXJhdGlvbiBmcm9tIGEgbWVhbmluZ2xlc3MKKyMgY29uZmlndXJhdGlvbi4K
KworIyBUaGUgZ29hbCBvZiB0aGlzIGZpbGUgaXMgdG8gbWFwIGFsbCB0aGUgdmFyaW91cyB2YXJp
YXRpb25zIG9mIGEgZ2l2ZW4KKyMgbWFjaGluZSBzcGVjaWZpY2F0aW9uIGludG8gYSBzaW5nbGUg
c3BlY2lmaWNhdGlvbiBpbiB0aGUgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLU9QRVJB
VElOR19TWVNURU0KKyMgb3IgaW4gc29tZSBjYXNlcywgdGhlIG5ld2VyIGZvdXItcGFydCBmb3Jt
OgorIwlDUFVfVFlQRS1NQU5VRkFDVFVSRVItS0VSTkVMLU9QRVJBVElOR19TWVNURU0KKyMgSXQg
aXMgd3JvbmcgdG8gZWNobyBhbnkgb3RoZXIgdHlwZSBvZiBzcGVjaWZpY2F0aW9uLgorCittZT1g
ZWNobyAiJDAiIHwgc2VkIC1lICdzLC4qLywsJ2AKKwordXNhZ2U9IlwKK1VzYWdlOiAkMCBbT1BU
SU9OXSBDUFUtTUZSLU9QU1lTCisgICAgICAgJDAgW09QVElPTl0gQUxJQVMKKworQ2Fub25pY2Fs
aXplIGEgY29uZmlndXJhdGlvbiBuYW1lLgorCitPcGVyYXRpb24gbW9kZXM6CisgIC1oLCAtLWhl
bHAgICAgICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtdCwgLS10aW1lLXN0YW1w
ICAgcHJpbnQgZGF0ZSBvZiBsYXN0IG1vZGlmaWNhdGlvbiwgdGhlbiBleGl0CisgIC12LCAtLXZl
cnNpb24gICAgICBwcmludCB2ZXJzaW9uIG51bWJlciwgdGhlbiBleGl0CisKK1JlcG9ydCBidWdz
IGFuZCBwYXRjaGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4iCisKK3ZlcnNpb249IlwK
K0dOVSBjb25maWcuc3ViICgkdGltZXN0YW1wKQorCitDb3B5cmlnaHQgKEMpIDE5OTIsIDE5OTMs
IDE5OTQsIDE5OTUsIDE5OTYsIDE5OTcsIDE5OTgsIDE5OTksIDIwMDAsCisyMDAxLCAyMDAyLCAy
MDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEwIEZyZWUKK1NvZnR3
YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBzZWUgdGhlIHNv
dXJjZSBmb3IgY29weWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8KK3dhcnJhbnR5OyBub3Qg
ZXZlbiBmb3IgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiIKKworaGVscD0iCitUcnkgXGAkbWUgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4i
CisKKyMgUGFyc2UgY29tbWFuZCBsaW5lCit3aGlsZSB0ZXN0ICQjIC1ndCAwIDsgZG8KKyAgY2Fz
ZSAkMSBpbgorICAgIC0tdGltZS1zdGFtcCB8IC0tdGltZSogfCAtdCApCisgICAgICAgZWNobyAi
JHRpbWVzdGFtcCIgOyBleGl0IDs7CisgICAgLS12ZXJzaW9uIHwgLXYgKQorICAgICAgIGVjaG8g
IiR2ZXJzaW9uIiA7IGV4aXQgOzsKKyAgICAtLWhlbHAgfCAtLWgqIHwgLWggKQorICAgICAgIGVj
aG8gIiR1c2FnZSI7IGV4aXQgOzsKKyAgICAtLSApICAgICAjIFN0b3Agb3B0aW9uIHByb2Nlc3Np
bmcKKyAgICAgICBzaGlmdDsgYnJlYWsgOzsKKyAgICAtICkJIyBVc2Ugc3RkaW4gYXMgaW5wdXQu
CisgICAgICAgYnJlYWsgOzsKKyAgICAtKiApCisgICAgICAgZWNobyAiJG1lOiBpbnZhbGlkIG9w
dGlvbiAkMSRoZWxwIgorICAgICAgIGV4aXQgMSA7OworCisgICAgKmxvY2FsKikKKyAgICAgICAj
IEZpcnN0IHBhc3MgdGhyb3VnaCBhbnkgbG9jYWwgbWFjaGluZSB0eXBlcy4KKyAgICAgICBlY2hv
ICQxCisgICAgICAgZXhpdCA7OworCisgICAgKiApCisgICAgICAgYnJlYWsgOzsKKyAgZXNhYwor
ZG9uZQorCitjYXNlICQjIGluCisgMCkgZWNobyAiJG1lOiBtaXNzaW5nIGFyZ3VtZW50JGhlbHAi
ID4mMgorICAgIGV4aXQgMTs7CisgMSkgOzsKKyAqKSBlY2hvICIkbWU6IHRvbyBtYW55IGFyZ3Vt
ZW50cyRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworZXNhYworCisjIFNlcGFyYXRlIHdoYXQgdGhl
IHVzZXIgZ2F2ZSBpbnRvIENQVS1DT01QQU5ZIGFuZCBPUyBvciBLRVJORUwtT1MgKGlmIGFueSku
CisjIEhlcmUgd2UgbXVzdCByZWNvZ25pemUgYWxsIHRoZSB2YWxpZCBLRVJORUwtT1MgY29tYmlu
YXRpb25zLgorbWF5YmVfb3M9YGVjaG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0q
XCkkL1wyLydgCitjYXNlICRtYXliZV9vcyBpbgorICBudG8tcW54KiB8IGxpbnV4LWdudSogfCBs
aW51eC1kaWV0bGliYyB8IGxpbnV4LW5ld2xpYiogfCBsaW51eC11Y2xpYmMqIHwgXAorICB1Y2xp
bnV4LXVjbGliYyogfCB1Y2xpbnV4LWdudSogfCBrZnJlZWJzZCotZ251KiB8IGtuZXRic2QqLWdu
dSogfCBuZXRic2QqLWdudSogfCBcCisgIGtvcGVuc29sYXJpcyotZ251KiB8IFwKKyAgc3Rvcm0t
Y2hhb3MqIHwgb3MyLWVteCogfCBydG1rLW5vdmEqKQorICAgIG9zPS0kbWF5YmVfb3MKKyAgICBi
YXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzL15cKC4qXCktXChbXi1dKi1bXi1dKlwpJC9c
MS8nYAorICAgIDs7CisgICopCisgICAgYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAncy8t
W14tXSokLy8nYAorICAgIGlmIFsgJGJhc2ljX21hY2hpbmUgIT0gJDEgXQorICAgIHRoZW4gb3M9
YGVjaG8gJDEgfCBzZWQgJ3MvLiotLy0vJ2AKKyAgICBlbHNlIG9zPTsgZmkKKyAgICA7OworZXNh
YworCisjIyMgTGV0J3MgcmVjb2duaXplIGNvbW1vbiBtYWNoaW5lcyBhcyBub3QgYmVpbmcgb3Bl
cmF0aW5nIHN5c3RlbXMgc28KKyMjIyB0aGF0IHRoaW5ncyBsaWtlIGNvbmZpZy5zdWIgZGVjc3Rh
dGlvbi0zMTAwIHdvcmsuICBXZSBhbHNvCisjIyMgcmVjb2duaXplIHNvbWUgbWFudWZhY3R1cmVy
cyBhcyBub3QgYmVpbmcgb3BlcmF0aW5nIHN5c3RlbXMsIHNvIHdlCisjIyMgY2FuIHByb3ZpZGUg
ZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVtcyBiZWxvdy4KK2Nhc2UgJG9zIGluCisJLXN1bipvcyop
CisJCSMgUHJldmVudCBmb2xsb3dpbmcgY2xhdXNlIGZyb20gaGFuZGxpbmcgdGhpcyBpbnZhbGlk
IGlucHV0LgorCQk7OworCS1kZWMqIHwgLW1pcHMqIHwgLXNlcXVlbnQqIHwgLWVuY29yZSogfCAt
cGM1MzIqIHwgLXNnaSogfCAtc29ueSogfCBcCisJLWF0dCogfCAtNzMwMCogfCAtMzMwMCogfCAt
ZGVsdGEqIHwgLW1vdG9yb2xhKiB8IC1zdW5bMjM0XSogfCBcCisJLXVuaWNvbSogfCAtaWJtKiB8
IC1uZXh0IHwgLWhwIHwgLWlzaSogfCAtYXBvbGxvIHwgLWFsdG9zKiB8IFwKKwktY29udmVyZ2Vu
dCogfCAtbmNyKiB8IC1uZXdzIHwgLTMyKiB8IC0zNjAwKiB8IC0zMTAwKiB8IC1oaXRhY2hpKiB8
XAorCS1jWzEyM10qIHwgLWNvbnZleCogfCAtc3VuIHwgLWNyZHMgfCAtb21yb24qIHwgLWRnIHwg
LXVsdHJhIHwgLXR0aSogfCBcCisJLWhhcnJpcyB8IC1kb2xwaGluIHwgLWhpZ2hsZXZlbCB8IC1n
b3VsZCB8IC1jYm0gfCAtbnMgfCAtbWFzc2NvbXAgfCBcCisJLWFwcGxlIHwgLWF4aXMgfCAta251
dGggfCAtY3JheSB8IC1taWNyb2JsYXplKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7
OworICAgICAgICAtYmx1ZWdlbmUqKQorCSAgICAgICAgb3M9LWNuaworCQk7OworCS1zaW0gfCAt
Y2lzY28gfCAtb2tpIHwgLXdlYyB8IC13aW5ib25kKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0k
MQorCQk7OworCS1zY291dCkKKwkJOzsKKwktd3JzKQorCQlvcz0tdnh3b3JrcworCQliYXNpY19t
YWNoaW5lPSQxCisJCTs7CisJLWNob3J1c29zKikKKwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21h
Y2hpbmU9JDEKKwkJOzsKKyAJLWNob3J1c3JkYikKKyAJCW9zPS1jaG9ydXNyZGIKKwkJYmFzaWNf
bWFjaGluZT0kMQorIAkJOzsKKwktaGl1eCopCisJCW9zPS1oaXV4d2UyCisJCTs7CisJLXNjbzYp
CisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0u
Ki84Ni1wYy8nYAorCQk7OworCS1zY281KQorCQlvcz0tc2NvMy4ydjUKKwkJYmFzaWNfbWFjaGlu
ZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY280KQorCQlv
cz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84
Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQtOV0qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUg
J3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktc2NvMy4ydls0LTldKikKKwkJIyBEb24ndCBmb3Jn
ZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBvciBuZXdlci4KKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281djYqKQorCQkjIERv
bid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlzIDMuMnY0IG9yIG5ld2VyLgorCQliYXNpY19tYWNo
aW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXNjbyopCisJ
CW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4q
Lzg2LXBjLydgCisJCTs7CisJLXVkayopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQg
LWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktaXNjKQorCQlvcz0taXNjMi4yCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktY2xp
eCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBlci1pbnRlcmdyYXBoCisJCTs7CisJLWlzYyopCisJ
CWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsK
KwktbHlueCopCisJCW9zPS1seW54b3MKKwkJOzsKKwktcHR4KikKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1zZXF1ZW50LydgCisJCTs7CisJLXdpbmRvd3Nu
dCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAncy93aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsK
KwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7CisJLW1pbnQgfCAtbWludFswLTldKikKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9zPS1taW50CisJCTs7Citlc2FjCisKKyMgRGVjb2Rl
IGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNPTVBBTlkgY29tYmluYXRpb25zLgorY2FzZSAkYmFz
aWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aG91dCBj
b21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBvbWl0dGVkIGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUg
c3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkxNzUwYSB8IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFs
cGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFldjU2IHwgYWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1
WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2NGV2WzQtOF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhh
NjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjddIFwKKwl8IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFy
bSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBhcm12WzIzNDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2
ciB8IGF2cjMyIFwKKwl8IGJmaW4gXAorCXwgYzR4IHwgY2xpcHBlciBcCisJfCBkMTB2IHwgZDMw
diB8IGRseCB8IGRzcDE2eHggXAorCXwgZmlkbyB8IGZyMzAgfCBmcnYgXAorCXwgaDgzMDAgfCBo
ODUwMCB8IGhwcGEgfCBocHBhMS5bMDFdIHwgaHBwYTIuMCB8IGhwcGEyLjBbbnddIHwgaHBwYTY0
IFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlhNjQgXAorCXwgaXAyayB8IGlxMjAwMCBcCisJ
fCBsbTMyIFwKKwl8IG0zMmMgfCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsg
XAorCXwgbWF4cSB8IG1iIHwgbWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwg
bWlwcyB8IG1pcHNiZSB8IG1pcHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAor
CXwgbWlwczY0IHwgbWlwczY0ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwg
XAorCXwgbWlwczY0b3Jpb24gfCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlw
czY0cjU5MDBlbCBcCisJfCBtaXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAw
IHwgbWlwczY0dnI0MTAwZWwgXAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAor
CXwgbWlwczY0dnI1MDAwIHwgbWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlw
czY0dnI1OTAwZWwgXAorCXwgbWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMy
cjIgfCBtaXBzaXNhMzJyMmVsIFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1p
cHNpc2E2NHIyIHwgbWlwc2lzYTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRz
YjFlbCBcCisJfCBtaXBzaXNhNjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4
MzkgfCBtaXBzdHgzOWVsIFwKKwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8
IG10IFwKKwl8IG1zcDQzMCBcCisJfCBuaW9zIHwgbmlvczIgXAorCXwgbnMxNmsgfCBuczMyayBc
CisJfCBvcjMyIFwKKwl8IHBkcDEwIHwgcGRwMTEgfCBwaiB8IHBqbCBcCisJfCBwb3dlcnBjIHwg
cG93ZXJwYzY0IHwgcG93ZXJwYzY0bGUgfCBwb3dlcnBjbGUgfCBwcGNiZSBcCisJfCBweXJhbWlk
IFwKKwl8IHJ4IFwKKwl8IHNjb3JlIFwKKwl8IHNoIHwgc2hbMTIzNF0gfCBzaFsyNF1hIHwgc2hb
MjRdYWViIHwgc2hbMjNdZSB8IHNoWzM0XWViIHwgc2hlYiB8IHNoYmUgfCBzaGxlIHwgc2hbMTIz
NF1sZSB8IHNoM2VsZSBcCisJfCBzaDY0IHwgc2g2NGxlIFwKKwl8IHNwYXJjIHwgc3BhcmM2NCB8
IHNwYXJjNjRiIHwgc3BhcmM2NHYgfCBzcGFyYzg2eCB8IHNwYXJjbGV0IHwgc3BhcmNsaXRlIFwK
Kwl8IHNwYXJjdjggfCBzcGFyY3Y5IHwgc3BhcmN2OWIgfCBzcGFyY3Y5diBcCisJfCBzcHUgfCBz
dHJvbmdhcm0gXAorCXwgdGFob2UgfCB0aHVtYiB8IHRpYzR4IHwgdGljODAgfCB0cm9uIFwKKwl8
IHViaWNvbTMyIFwKKwl8IHY4NTAgfCB2ODUwZSBcCisJfCB3ZTMyayBcCisJfCB4ODYgfCB4YzE2
eCB8IHhzY2FsZSB8IHhzY2FsZWVbYmxdIHwgeHN0b3JteTE2IHwgeHRlbnNhIFwKKwl8IHo4ayB8
IHo4MCkKKwkJYmFzaWNfbWFjaGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJbTY4
MTEgfCBtNjhoYzExIHwgbTY4MTIgfCBtNjhoYzEyIHwgcGljb2NoaXApCisJCSMgTW90b3JvbGEg
NjhIQzExLzEyLgorCQliYXNpY19tYWNoaW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9
LW5vbmUKKwkJOzsKKwltODgxMTAgfCBtNjgwWzEyMzQ2XTAgfCBtNjgzPzIgfCBtNjgzNjAgfCBt
NTIwMCB8IHY3MCB8IHc2NSB8IHo4aykKKwkJOzsKKwltczEpCisJCWJhc2ljX21hY2hpbmU9bXQt
dW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhhbiBgdW5rbm93bicKKwkj
IGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJlLCBhbmQKKwkjICgyKSB0
aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5pbmcgdXNlcnMuCisJaSo4
NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtcGMKKwkgIDs7CisJ
IyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29yZC4KKwkqLSotKikKKwkJ
ZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5lIFxgJGJhc2ljX21hY2hp
bmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworCSMgUmVjb2duaXplIHRo
ZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgwLSogXAorCXwgYTI5ay0q
IFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1Ni0qIHwgYWxwaGFldjZb
NzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8IGFscGhhNjRldjU2LSog
fCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8IGFscGhhNjRwY2E1WzY3
XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxlLSogfCBhcm1lYi0qIHwg
YXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmZpbi0qIHwgYnMyMDAwLSogXAor
CXwgY1sxMjNdKiB8IGMzMC0qIHwgW2NqdF05MC0qIHwgYzR4LSogfCBjNTR4LSogfCBjNTV4LSog
fCBjNngtKiBcCisJfCBjbGlwcGVyLSogfCBjcmF5bnYtKiB8IGN5ZHJhLSogXAorCXwgZDEwdi0q
IHwgZDMwdi0qIHwgZGx4LSogXAorCXwgZWx4c2ktKiBcCisJfCBmMzBbMDFdLSogfCBmNzAwLSog
fCBmaWRvLSogfCBmcjMwLSogfCBmcnYtKiB8IGZ4ODAtKiBcCisJfCBoODMwMC0qIHwgaDg1MDAt
KiBcCisJfCBocHBhLSogfCBocHBhMS5bMDFdLSogfCBocHBhMi4wLSogfCBocHBhMi4wW253XS0q
IHwgaHBwYTY0LSogXAorCXwgaSo4Ni0qIHwgaTg2MC0qIHwgaTk2MC0qIHwgaWE2NC0qIFwKKwl8
IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxtMzItKiBcCisJfCBtMzJjLSogfCBtMzJyLSogfCBt
MzJybGUtKiBcCisJfCBtNjgwMDAtKiB8IG02ODBbMDEyMzQ2XTAtKiB8IG02ODM2MC0qIHwgbTY4
Mz8yLSogfCBtNjhrLSogXAorCXwgbTg4MTEwLSogfCBtODhrLSogfCBtYXhxLSogfCBtY29yZS0q
IHwgbWV0YWctKiB8IG1pY3JvYmxhemUtKiBcCisJfCBtaXBzLSogfCBtaXBzYmUtKiB8IG1pcHNl
Yi0qIHwgbWlwc2VsLSogfCBtaXBzbGUtKiBcCisJfCBtaXBzMTYtKiBcCisJfCBtaXBzNjQtKiB8
IG1pcHM2NGVsLSogXAorCXwgbWlwczY0b2N0ZW9uLSogfCBtaXBzNjRvY3Rlb25lbC0qIFwKKwl8
IG1pcHM2NG9yaW9uLSogfCBtaXBzNjRvcmlvbmVsLSogXAorCXwgbWlwczY0cjU5MDAtKiB8IG1p
cHM2NHI1OTAwZWwtKiBcCisJfCBtaXBzNjR2ci0qIHwgbWlwczY0dnJlbC0qIFwKKwl8IG1pcHM2
NHZyNDEwMC0qIHwgbWlwczY0dnI0MTAwZWwtKiBcCisJfCBtaXBzNjR2cjQzMDAtKiB8IG1pcHM2
NHZyNDMwMGVsLSogXAorCXwgbWlwczY0dnI1MDAwLSogfCBtaXBzNjR2cjUwMDBlbC0qIFwKKwl8
IG1pcHM2NHZyNTkwMC0qIHwgbWlwczY0dnI1OTAwZWwtKiBcCisJfCBtaXBzaXNhMzItKiB8IG1p
cHNpc2EzMmVsLSogXAorCXwgbWlwc2lzYTMycjItKiB8IG1pcHNpc2EzMnIyZWwtKiBcCisJfCBt
aXBzaXNhNjQtKiB8IG1pcHNpc2E2NGVsLSogXAorCXwgbWlwc2lzYTY0cjItKiB8IG1pcHNpc2E2
NHIyZWwtKiBcCisJfCBtaXBzaXNhNjRzYjEtKiB8IG1pcHNpc2E2NHNiMWVsLSogXAorCXwgbWlw
c2lzYTY0c3I3MWstKiB8IG1pcHNpc2E2NHNyNzFrZWwtKiBcCisJfCBtaXBzdHgzOS0qIHwgbWlw
c3R4MzllbC0qIFwKKwl8IG1taXgtKiBcCisJfCBtdC0qIFwKKwl8IG1zcDQzMC0qIFwKKwl8IG5p
b3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0qIHwgbnAxLSogfCBuczE2ay0qIHwgbnMzMmstKiBc
CisJfCBvcmlvbi0qIFwKKwl8IHBkcDEwLSogfCBwZHAxMS0qIHwgcGotKiB8IHBqbC0qIHwgcG4t
KiB8IHBvd2VyLSogXAorCXwgcG93ZXJwYy0qIHwgcG93ZXJwYzY0LSogfCBwb3dlcnBjNjRsZS0q
IHwgcG93ZXJwY2xlLSogfCBwcGNiZS0qIFwKKwl8IHB5cmFtaWQtKiBcCisJfCByb21wLSogfCBy
czYwMDAtKiB8IHJ4LSogXAorCXwgc2gtKiB8IHNoWzEyMzRdLSogfCBzaFsyNF1hLSogfCBzaFsy
NF1hZWItKiB8IHNoWzIzXWUtKiB8IHNoWzM0XWViLSogfCBzaGViLSogfCBzaGJlLSogXAorCXwg
c2hsZS0qIHwgc2hbMTIzNF1sZS0qIHwgc2gzZWxlLSogfCBzaDY0LSogfCBzaDY0bGUtKiBcCisJ
fCBzcGFyYy0qIHwgc3BhcmM2NC0qIHwgc3BhcmM2NGItKiB8IHNwYXJjNjR2LSogfCBzcGFyYzg2
eC0qIHwgc3BhcmNsZXQtKiBcCisJfCBzcGFyY2xpdGUtKiBcCisJfCBzcGFyY3Y4LSogfCBzcGFy
Y3Y5LSogfCBzcGFyY3Y5Yi0qIHwgc3BhcmN2OXYtKiB8IHN0cm9uZ2FybS0qIHwgc3YxLSogfCBz
eD8tKiBcCisJfCB0YWhvZS0qIHwgdGh1bWItKiBcCisJfCB0aWMzMC0qIHwgdGljNHgtKiB8IHRp
YzU0eC0qIHwgdGljNTV4LSogfCB0aWM2eC0qIHwgdGljODAtKiBcCisJfCB0aWxlLSogfCB0aWxl
Z3gtKiBcCisJfCB0cm9uLSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSogfCB2ODUwZS0q
IHwgdmF4LSogXAorCXwgd2UzMmstKiBcCisJfCB4ODYtKiB8IHg4Nl82NC0qIHwgeGMxNngtKiB8
IHhwczEwMC0qIHwgeHNjYWxlLSogfCB4c2NhbGVlW2JsXS0qIFwKKwl8IHhzdG9ybXkxNi0qIHwg
eHRlbnNhKi0qIFwKKwl8IHltcC0qIFwKKwl8IHo4ay0qIHwgejgwLSopCisJCTs7CisJIyBSZWNv
Z25pemUgdGhlIGJhc2ljIENQVSB0eXBlcyB3aXRob3V0IGNvbXBhbnkgbmFtZSwgd2l0aCBnbG9i
IG1hdGNoLgorCXh0ZW5zYSopCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93
bgorCQk7OworCSMgUmVjb2duaXplIHRoZSB2YXJpb3VzIG1hY2hpbmUgbmFtZXMgYW5kIGFsaWFz
ZXMgd2hpY2ggc3RhbmQKKwkjIGZvciBhIENQVSB0eXBlIGFuZCBhIGNvbXBhbnkgYW5kIHNvbWV0
aW1lcyBldmVuIGFuIE9TLgorCTM4NmJzZCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24K
KwkJb3M9LWJzZAorCQk7OworCTNiMSB8IDczMDAgfCA3MzAwLWF0dCB8IGF0dC03MzAwIHwgcGM3
MzAwIHwgc2FmYXJpIHwgdW5peHBjKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1hdHQKKwkJOzsK
KwkzYiopCisJCWJhc2ljX21hY2hpbmU9d2UzMmstYXR0CisJCTs7CisJYTI5a2hpZikKKwkJYmFz
aWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tdWRpCisJCTs7CisgICAgCWFiYWN1cykKKwkJYmFz
aWNfbWFjaGluZT1hYmFjdXMtdW5rbm93bgorCQk7OworCWFkb2JlNjhrKQorCQliYXNpY19tYWNo
aW5lPW02ODAxMC1hZG9iZQorCQlvcz0tc2NvdXQKKwkJOzsKKwlhbGxpYW50IHwgZng4MCkKKwkJ
YmFzaWNfbWFjaGluZT1meDgwLWFsbGlhbnQKKwkJOzsKKwlhbHRvcyB8IGFsdG9zMzA2OCkKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLWFsdG9zCisJCTs7CisJYW0yOWspCisJCWJhc2ljX21hY2hpbmU9
YTI5ay1ub25lCisJCW9zPS1ic2QKKwkJOzsKKwlhbWQ2NCkKKwkJYmFzaWNfbWFjaGluZT14ODZf
NjQtcGMKKwkJOzsKKwlhbWQ2NC0qKQorCQliYXNpY19tYWNoaW5lPXg4Nl82NC1gZWNobyAkYmFz
aWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWFtZGFobCkKKwkJYmFzaWNf
bWFjaGluZT01ODAtYW1kYWhsCisJCW9zPS1zeXN2CisJCTs7CisJYW1pZ2EgfCBhbWlnYS0qKQor
CQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93bgorCQk7OworCWFtaWdhb3MgfCBhbWlnYWRvcykK
KwkJYmFzaWNfbWFjaGluZT1tNjhrLXVua25vd24KKwkJb3M9LWFtaWdhb3MKKwkJOzsKKwlhbWln
YXVuaXggfCBhbWl4KQorCQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93bgorCQlvcz0tc3lzdjQK
KwkJOzsKKwlhcG9sbG82OCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWFwb2xsbworCQlvcz0tc3lz
dgorCQk7OworCWFwb2xsbzY4YnNkKQorCQliYXNpY19tYWNoaW5lPW02OGstYXBvbGxvCisJCW9z
PS1ic2QKKwkJOzsKKwlhcm9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWFyb3MK
KwkJOzsKKwlhdXgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQlvcz0tYXV4CisJCTs7
CisJYmFsYW5jZSkKKwkJYmFzaWNfbWFjaGluZT1uczMyay1zZXF1ZW50CisJCW9zPS1keW5peAor
CQk7OworCWJsYWNrZmluKQorCQliYXNpY19tYWNoaW5lPWJmaW4tdW5rbm93bgorCQlvcz0tbGlu
dXgKKwkJOzsKKwlibGFja2Zpbi0qKQorCQliYXNpY19tYWNoaW5lPWJmaW4tYGVjaG8gJGJhc2lj
X21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4CisJCTs7CisJYmx1ZWdl
bmUqKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGMtaWJtCisJCW9zPS1jbmsKKwkJOzsKKwljOTAp
CisJCWJhc2ljX21hY2hpbmU9YzkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworICAgICAgICBj
ZWdjYykKKwkJYmFzaWNfbWFjaGluZT1hcm0tdW5rbm93bgorCQlvcz0tY2VnY2MKKwkJOzsKKwlj
b252ZXgtYzEpCisJCWJhc2ljX21hY2hpbmU9YzEtY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwlj
b252ZXgtYzIpCisJCWJhc2ljX21hY2hpbmU9YzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwlj
b252ZXgtYzMyKQorCQliYXNpY19tYWNoaW5lPWMzMi1jb252ZXgKKwkJb3M9LWJzZAorCQk7Owor
CWNvbnZleC1jMzQpCisJCWJhc2ljX21hY2hpbmU9YzM0LWNvbnZleAorCQlvcz0tYnNkCisJCTs7
CisJY29udmV4LWMzOCkKKwkJYmFzaWNfbWFjaGluZT1jMzgtY29udmV4CisJCW9zPS1ic2QKKwkJ
OzsKKwljcmF5IHwgajkwKQorCQliYXNpY19tYWNoaW5lPWo5MC1jcmF5CisJCW9zPS11bmljb3MK
KwkJOzsKKwljcmF5bnYpCisJCWJhc2ljX21hY2hpbmU9Y3JheW52LWNyYXkKKwkJb3M9LXVuaWNv
c21wCisJCTs7CisJY3IxNikKKwkJYmFzaWNfbWFjaGluZT1jcjE2LXVua25vd24KKwkJb3M9LWVs
ZgorCQk7OworCWNyZHMgfCB1bm9zKQorCQliYXNpY19tYWNoaW5lPW02OGstY3JkcworCQk7Owor
CWNyaXN2MzIgfCBjcmlzdjMyLSogfCBldHJheGZzKikKKwkJYmFzaWNfbWFjaGluZT1jcmlzdjMy
LWF4aXMKKwkJOzsKKwljcmlzIHwgY3Jpcy0qIHwgZXRyYXgqKQorCQliYXNpY19tYWNoaW5lPWNy
aXMtYXhpcworCQk7OworCWNyeCkKKwkJYmFzaWNfbWFjaGluZT1jcngtdW5rbm93bgorCQlvcz0t
ZWxmCisJCTs7CisJZGEzMCB8IGRhMzAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWRhMzAKKwkJ
OzsKKwlkZWNzdGF0aW9uIHwgZGVjc3RhdGlvbi0zMTAwIHwgcG1heCB8IHBtYXgtKiB8IHBtaW4g
fCBkZWMzMTAwIHwgZGVjc3RhdG4pCisJCWJhc2ljX21hY2hpbmU9bWlwcy1kZWMKKwkJOzsKKwlk
ZWNzeXN0ZW0xMCogfCBkZWMxMCopCisJCWJhc2ljX21hY2hpbmU9cGRwMTAtZGVjCisJCW9zPS10
b3BzMTAKKwkJOzsKKwlkZWNzeXN0ZW0yMCogfCBkZWMyMCopCisJCWJhc2ljX21hY2hpbmU9cGRw
MTAtZGVjCisJCW9zPS10b3BzMjAKKwkJOzsKKwlkZWx0YSB8IDMzMDAgfCBtb3Rvcm9sYS0zMzAw
IHwgbW90b3JvbGEtZGVsdGEgXAorCSAgICAgIHwgMzMwMC1tb3Rvcm9sYSB8IGRlbHRhLW1vdG9y
b2xhKQorCQliYXNpY19tYWNoaW5lPW02OGstbW90b3JvbGEKKwkJOzsKKwlkZWx0YTg4KQorCQli
YXNpY19tYWNoaW5lPW04OGstbW90b3JvbGEKKwkJb3M9LXN5c3YzCisJCTs7CisJZGljb3MpCisJ
CWJhc2ljX21hY2hpbmU9aTY4Ni1wYworCQlvcz0tZGljb3MKKwkJOzsKKwlkamdwcCkKKwkJYmFz
aWNfbWFjaGluZT1pNTg2LXBjCisJCW9zPS1tc2Rvc2RqZ3BwCisJCTs7CisJZHB4MjAgfCBkcHgy
MC0qKQorCQliYXNpY19tYWNoaW5lPXJzNjAwMC1idWxsCisJCW9zPS1ib3N4CisJCTs7CisJZHB4
MiogfCBkcHgyKi1idWxsKQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlvcz0tc3lzdjMK
KwkJOzsKKwllYm1vbjI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tZWJtb24K
KwkJOzsKKwllbHhzaSkKKwkJYmFzaWNfbWFjaGluZT1lbHhzaS1lbHhzaQorCQlvcz0tYnNkCisJ
CTs7CisJZW5jb3JlIHwgdW1heCB8IG1tYXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstZW5jb3Jl
CisJCTs7CisJZXMxODAwIHwgT1NFNjhrIHwgb3NlNjhrIHwgb3NlIHwgT1NFKQorCQliYXNpY19t
YWNoaW5lPW02OGstZXJpY3Nzb24KKwkJb3M9LW9zZQorCQk7OworCWZ4MjgwMCkKKwkJYmFzaWNf
bWFjaGluZT1pODYwLWFsbGlhbnQKKwkJOzsKKwlnZW5peCkKKwkJYmFzaWNfbWFjaGluZT1uczMy
ay1ucworCQk7OworCWdtaWNybykKKwkJYmFzaWNfbWFjaGluZT10cm9uLWdtaWNybworCQlvcz0t
c3lzdgorCQk7OworCWdvMzIpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1wYworCQlvcz0tZ28zMgor
CQk7OworCWgzMDUwciogfCBoaXV4KikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhpdGFjaGkK
KwkJb3M9LWhpdXh3ZTIKKwkJOzsKKwloODMwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODMwMC1o
aXRhY2hpCisJCW9zPS1obXMKKwkJOzsKKwloODMwMHhyYXkpCisJCWJhc2ljX21hY2hpbmU9aDgz
MDAtaGl0YWNoaQorCQlvcz0teHJheQorCQk7OworCWg4NTAwaG1zKQorCQliYXNpY19tYWNoaW5l
PWg4NTAwLWhpdGFjaGkKKwkJb3M9LWhtcworCQk7OworCWhhcnJpcykKKwkJYmFzaWNfbWFjaGlu
ZT1tODhrLWhhcnJpcworCQlvcz0tc3lzdjMKKwkJOzsKKwlocDMwMC0qKQorCQliYXNpY19tYWNo
aW5lPW02OGstaHAKKwkJOzsKKwlocDMwMGJzZCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhwCisJ
CW9zPS1ic2QKKwkJOzsKKwlocDMwMGhwdXgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlv
cz0taHB1eAorCQk7OworCWhwM2s5WzAtOV1bMC05XSB8IGhwOVswLTldWzAtOV0pCisJCWJhc2lj
X21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwOWsyWzAtOV1bMC05XSB8IGhwOWszMVswLTld
KQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1ocAorCQk7OworCWhwOWszWzItOV1bMC05XSkKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLWhwCisJCTs7CisJaHA5azZbMC05XVswLTldIHwgaHA2WzAtOV1b
MC05XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHA5azdbMC03OV1bMC05
XSB8IGhwN1swLTc5XVswLTldKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaHAKKwkJOzsKKwlo
cDlrNzhbMC05XSB8IGhwNzhbMC05XSkKKwkJIyBGSVhNRTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJ
YmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azhbNjddMSB8IGhwOFs2N10xIHwg
aHA5azgwWzI0XSB8IGhwODBbMjRdIHwgaHA5azhbNzhdOSB8IGhwOFs3OF05IHwgaHA5azg5MyB8
IGhwODkzKQorCQkjIEZJWE1FOiByZWFsbHkgaHBwYTIuMC1ocAorCQliYXNpY19tYWNoaW5lPWhw
cGExLjEtaHAKKwkJOzsKKwlocDlrOFswLTldWzEzNjc5XSB8IGhwOFswLTldWzEzNjc5XSkKKwkJ
YmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azhbMC05XVswLTldIHwgaHA4WzAt
OV1bMC05XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHBwYS1uZXh0KQor
CQlvcz0tbmV4dHN0ZXAzCisJCTs7CisJaHBwYW9zZikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4x
LWhwCisJCW9zPS1vc2YKKwkJOzsKKwlocHBybykKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhw
CisJCW9zPS1wcm9lbGYKKwkJOzsKKwlpMzcwLWlibSogfCBpYm0qKQorCQliYXNpY19tYWNoaW5l
PWkzNzAtaWJtCisJCTs7CisjIEknbSBub3Qgc3VyZSB3aGF0ICJTeXN2MzIiIG1lYW5zLiAgU2hv
dWxkIHRoaXMgYmUgc3lzdjMuMj8KKwlpKjg2djMyKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICQx
IHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXN5c3YzMgorCQk7OworCWkqODZ2NCop
CisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlv
cz0tc3lzdjQKKwkJOzsKKwlpKjg2dikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAt
ZSAncy84Ni4qLzg2LXBjLydgCisJCW9zPS1zeXN2CisJCTs7CisJaSo4NnNvbDIpCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlvcz0tc29sYXJp
czIKKwkJOzsKKwlpMzg2bWFjaCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LW1hY2gKKwkJb3M9LW1h
Y2gKKwkJOzsKKwlpMzg2LXZzdGEgfCB2c3RhKQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93
bgorCQlvcz0tdnN0YQorCQk7OworCWlyaXMgfCBpcmlzNGQpCisJCWJhc2ljX21hY2hpbmU9bWlw
cy1zZ2kKKwkJY2FzZSAkb3MgaW4KKwkJICAgIC1pcml4KikKKwkJCTs7CisJCSAgICAqKQorCQkJ
b3M9LWlyaXg0CisJCQk7OworCQllc2FjCisJCTs7CisJaXNpNjggfCBpc2kpCisJCWJhc2ljX21h
Y2hpbmU9bTY4ay1pc2kKKwkJb3M9LXN5c3YKKwkJOzsKKwltNjhrbm9tbXUpCisJCWJhc2ljX21h
Y2hpbmU9bTY4ay11bmtub3duCisJCW9zPS1saW51eAorCQk7OworCW02OGtub21tdS0qKQorCQli
YXNpY19tYWNoaW5lPW02OGstYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJb3M9LWxpbnV4CisJCTs7CisJbTg4ay1vbXJvbiopCisJCWJhc2ljX21hY2hpbmU9bTg4
ay1vbXJvbgorCQk7OworCW1hZ251bSB8IG0zMjMwKQorCQliYXNpY19tYWNoaW5lPW1pcHMtbWlw
cworCQlvcz0tc3lzdgorCQk7OworCW1lcmxpbikKKwkJYmFzaWNfbWFjaGluZT1uczMyay11dGVr
CisJCW9zPS1zeXN2CisJCTs7CisgICAgICAgIG1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9
bWljcm9ibGF6ZS14aWxpbngKKwkJOzsKKwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYt
cGMKKwkJb3M9LW1pbmd3MzIKKwkJOzsKKwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJt
LXVua25vd24KKwkJb3M9LW1pbmd3MzJjZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFj
aGluZT1tNjgwMDAtY29udmVyZ2VudAorCQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlO
VCB8ICpNaU5UWzAtOV0qKQorCQliYXNpY19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQK
KwkJOzsKKwltaXBzMyotKikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8
IHNlZCAtZSAncy9taXBzMy9taXBzNjQvJ2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hp
bmU9YGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25v
d24KKwkJOzsKKwltb25pdG9yKQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1j
b2ZmCisJCTs7CisJbW9ycGhvcykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJ
b3M9LW1vcnBob3MKKwkJOzsKKwltc2RvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9z
PS1tc2RvcworCQk7OworCW1zMS0qKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNo
aW5lIHwgc2VkIC1lICdzL21zMS0vbXQtLydgCisJCTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5l
PWkzNzAtaWJtCisJCW9zPS1tdnMKKwkJOzsKKwluY3IzMDAwKQorCQliYXNpY19tYWNoaW5lPWk0
ODYtbmNyCisJCW9zPS1zeXN2NAorCQk7OworCW5ldGJzZDM4NikKKwkJYmFzaWNfbWFjaGluZT1p
Mzg2LXVua25vd24KKwkJb3M9LW5ldGJzZAorCQk7OworCW5ldHdpbmRlcikKKwkJYmFzaWNfbWFj
aGluZT1hcm12NGwtcmViZWwKKwkJb3M9LWxpbnV4CisJCTs7CisJbmV3cyB8IG5ld3M3MDAgfCBu
ZXdzODAwIHwgbmV3czkwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXNvbnkKKwkJb3M9LW5ld3Nv
cworCQk7OworCW5ld3MxMDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAzMC1zb255CisJCW9zPS1u
ZXdzb3MKKwkJOzsKKwluZXdzLTM2MDAgfCByaXNjLW5ld3MpCisJCWJhc2ljX21hY2hpbmU9bWlw
cy1zb255CisJCW9zPS1uZXdzb3MKKwkJOzsKKwluZWN2NzApCisJCWJhc2ljX21hY2hpbmU9djcw
LW5lYworCQlvcz0tc3lzdgorCQk7OworCW5leHQgfCBtKi1uZXh0ICkKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLW5leHQKKwkJY2FzZSAkb3MgaW4KKwkJICAgIC1uZXh0c3RlcCogKQorCQkJOzsKKwkJ
ICAgIC1uczIqKQorCQkgICAgICBvcz0tbmV4dHN0ZXAyCisJCQk7OworCQkgICAgKikKKwkJICAg
ICAgb3M9LW5leHRzdGVwMworCQkJOzsKKwkJZXNhYworCQk7OworCW5oMzAwMCkKKwkJYmFzaWNf
bWFjaGluZT1tNjhrLWhhcnJpcworCQlvcz0tY3h1eAorCQk7OworCW5oWzQ1XTAwMCkKKwkJYmFz
aWNfbWFjaGluZT1tODhrLWhhcnJpcworCQlvcz0tY3h1eAorCQk7OworCW5pbmR5OTYwKQorCQli
YXNpY19tYWNoaW5lPWk5NjAtaW50ZWwKKwkJb3M9LW5pbmR5CisJCTs7CisJbW9uOTYwKQorCQli
YXNpY19tYWNoaW5lPWk5NjAtaW50ZWwKKwkJb3M9LW1vbjk2MAorCQk7OworCW5vbnN0b3B1eCkK
KwkJYmFzaWNfbWFjaGluZT1taXBzLWNvbXBhcQorCQlvcz0tbm9uc3RvcHV4CisJCTs7CisJbnAx
KQorCQliYXNpY19tYWNoaW5lPW5wMS1nb3VsZAorCQk7OworCW5zci10YW5kZW0pCisJCWJhc2lj
X21hY2hpbmU9bnNyLXRhbmRlbQorCQk7OworCW9wNTBuLSogfCBvcDYwYy0qKQorCQliYXNpY19t
YWNoaW5lPWhwcGExLjEtb2tpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwlvcGVucmlzYyB8IG9wZW5y
aXNjLSopCisJCWJhc2ljX21hY2hpbmU9b3IzMi11bmtub3duCisJCTs7CisJb3M0MDApCisJCWJh
c2ljX21hY2hpbmU9cG93ZXJwYy1pYm0KKwkJb3M9LW9zNDAwCisJCTs7CisJT1NFNjgwMDAgfCBv
c2U2ODAwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtZXJpY3Nzb24KKwkJb3M9LW9zZQorCQk7
OworCW9zNjhrKQorCQliYXNpY19tYWNoaW5lPW02OGstbm9uZQorCQlvcz0tb3M2OGsKKwkJOzsK
KwlwYS1oaXRhY2hpKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaGl0YWNoaQorCQlvcz0taGl1
eHdlMgorCQk7OworCXBhcmFnb24pCisJCWJhc2ljX21hY2hpbmU9aTg2MC1pbnRlbAorCQlvcz0t
b3NmCisJCTs7CisJcGFyaXNjKQorCQliYXNpY19tYWNoaW5lPWhwcGEtdW5rbm93bgorCQlvcz0t
bGludXgKKwkJOzsKKwlwYXJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhLWBlY2hvICRiYXNp
Y19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9zPS1saW51eAorCQk7OworCXBiZCkK
KwkJYmFzaWNfbWFjaGluZT1zcGFyYy10dGkKKwkJOzsKKwlwYmIpCisJCWJhc2ljX21hY2hpbmU9
bTY4ay10dGkKKwkJOzsKKwlwYzUzMiB8IHBjNTMyLSopCisJCWJhc2ljX21hY2hpbmU9bnMzMmst
cGM1MzIKKwkJOzsKKwlwYzk4KQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJOzsKKwlwYzk4
LSopCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9e
W14tXSotLy8nYAorCQk7OworCXBlbnRpdW0gfCBwNSB8IGs1IHwgazYgfCBuZXhnZW4gfCB2aWFj
MykKKwkJYmFzaWNfbWFjaGluZT1pNTg2LXBjCisJCTs7CisJcGVudGl1bXBybyB8IHA2IHwgNng4
NiB8IGF0aGxvbiB8IGF0aGxvbl8qKQorCQliYXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlw
ZW50aXVtaWkgfCBwZW50aXVtMiB8IHBlbnRpdW1paWkgfCBwZW50aXVtMykKKwkJYmFzaWNfbWFj
aGluZT1pNjg2LXBjCisJCTs7CisJcGVudGl1bTQpCisJCWJhc2ljX21hY2hpbmU9aTc4Ni1wYwor
CQk7OworCXBlbnRpdW0tKiB8IHA1LSogfCBrNS0qIHwgazYtKiB8IG5leGdlbi0qIHwgdmlhYzMt
KikKKwkJYmFzaWNfbWFjaGluZT1pNTg2LWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15b
Xi1dKi0vLydgCisJCTs7CisJcGVudGl1bXByby0qIHwgcDYtKiB8IDZ4ODYtKiB8IGF0aGxvbi0q
KQorCQliYXNpY19tYWNoaW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlte
LV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtaWktKiB8IHBlbnRpdW0yLSogfCBwZW50aXVtaWlpLSog
fCBwZW50aXVtMy0qKQorCQliYXNpY19tYWNoaW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUg
fCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtNC0qKQorCQliYXNpY19tYWNoaW5l
PWk3ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlw
bikKKwkJYmFzaWNfbWFjaGluZT1wbi1nb3VsZAorCQk7OworCXBvd2VyKQliYXNpY19tYWNoaW5l
PXBvd2VyLWlibQorCQk7OworCXBwYykJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJ
OzsKKwlwcGMtKikJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWBlY2hvICRiYXNpY19tYWNoaW5lIHwg
c2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcHBjbGUgfCBwb3dlcnBjbGl0dGxlIHwgcHBjLWxl
IHwgcG93ZXJwYy1saXR0bGUpCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLXVua25vd24KKwkJ
OzsKKwlwcGNsZS0qIHwgcG93ZXJwY2xpdHRsZS0qKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGNs
ZS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0
KQliYXNpY19tYWNoaW5lPXBvd2VycGM2NC11bmtub3duCisJCTs7CisJcHBjNjQtKikgYmFzaWNf
bWFjaGluZT1wb3dlcnBjNjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJOzsKKwlwcGM2NGxlIHwgcG93ZXJwYzY0bGl0dGxlIHwgcHBjNjQtbGUgfCBwb3dlcnBj
NjQtbGl0dGxlKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLXVua25vd24KKwkJOzsKKwlw
cGM2NGxlLSogfCBwb3dlcnBjNjRsaXR0bGUtKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjNjRs
ZS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBzMikK
KwkJYmFzaWNfbWFjaGluZT1pMzg2LWlibQorCQk7OworCXB3MzIpCisJCWJhc2ljX21hY2hpbmU9
aTU4Ni11bmtub3duCisJCW9zPS1wdzMyCisJCTs7CisJcmRvcykKKwkJYmFzaWNfbWFjaGluZT1p
Mzg2LXBjCisJCW9zPS1yZG9zCisJCTs7CisJcm9tNjhrKQorCQliYXNpY19tYWNoaW5lPW02OGst
cm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJcm1bNDZdMDApCisJCWJhc2ljX21hY2hpbmU9bWlw
cy1zaWVtZW5zCisJCTs7CisJcnRwYyB8IHJ0cGMtKikKKwkJYmFzaWNfbWFjaGluZT1yb21wLWli
bQorCQk7OworCXMzOTAgfCBzMzkwLSopCisJCWJhc2ljX21hY2hpbmU9czM5MC1pYm0KKwkJOzsK
KwlzMzkweCB8IHMzOTB4LSopCisJCWJhc2ljX21hY2hpbmU9czM5MHgtaWJtCisJCTs7CisJc2Ey
OTIwMCkKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tdWRpCisJCTs7CisJc2IxKQor
CQliYXNpY19tYWNoaW5lPW1pcHNpc2E2NHNiMS11bmtub3duCisJCTs7CisJc2IxZWwpCisJCWJh
c2ljX21hY2hpbmU9bWlwc2lzYTY0c2IxZWwtdW5rbm93bgorCQk7OworCXNkZSkKKwkJYmFzaWNf
bWFjaGluZT1taXBzaXNhMzItc2RlCisJCW9zPS1lbGYKKwkJOzsKKwlzZWkpCisJCWJhc2ljX21h
Y2hpbmU9bWlwcy1zZWkKKwkJb3M9LXNlaXV4CisJCTs7CisJc2VxdWVudCkKKwkJYmFzaWNfbWFj
aGluZT1pMzg2LXNlcXVlbnQKKwkJOzsKKwlzaCkKKwkJYmFzaWNfbWFjaGluZT1zaC1oaXRhY2hp
CisJCW9zPS1obXMKKwkJOzsKKwlzaDVlbCkKKwkJYmFzaWNfbWFjaGluZT1zaDVsZS11bmtub3du
CisJCTs7CisJc2g2NCkKKwkJYmFzaWNfbWFjaGluZT1zaDY0LXVua25vd24KKwkJOzsKKwlzcGFy
Y2xpdGUtd3JzIHwgc2ltc28td3JzKQorCQliYXNpY19tYWNoaW5lPXNwYXJjbGl0ZS13cnMKKwkJ
b3M9LXZ4d29ya3MKKwkJOzsKKwlzcHM3KQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlv
cz0tc3lzdjIKKwkJOzsKKwlzcHVyKQorCQliYXNpY19tYWNoaW5lPXNwdXItdW5rbm93bgorCQk7
OworCXN0MjAwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXRhbmRlbQorCQk7OworCXN0cmF0dXMp
CisJCWJhc2ljX21hY2hpbmU9aTg2MC1zdHJhdHVzCisJCW9zPS1zeXN2NAorCQk7OworCXN1bjIp
CisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJvczMpCisJCWJhc2ljX21h
Y2hpbmU9bTY4MDAwLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuMm9zNCkKKwkJYmFzaWNf
bWFjaGluZT1tNjgwMDAtc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW4zb3MzKQorCQliYXNp
Y19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlzdW4zb3M0KQorCQliYXNp
Y19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW40b3MzKQorCQliYXNp
Y19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuNG9zNCkKKwkJYmFz
aWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7OworCXN1bjRzb2wyKQorCQli
YXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlzdW4zIHwgc3Vu
My0qKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCTs7CisJc3VuNCkKKwkJYmFzaWNfbWFj
aGluZT1zcGFyYy1zdW4KKwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwgcm9hZHJ1bm5lcikKKwkJ
YmFzaWNfbWFjaGluZT1pMzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFzaWNfbWFjaGluZT1zdjEt
Y3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJhc2ljX21hY2hpbmU9aTM4
Ni1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCXQzZSkKKwkJYmFzaWNfbWFjaGluZT1hbHBo
YWV2NS1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJhc2ljX21hY2hpbmU9dDkw
LWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworCXRpYzU0eCB8IGM1NHgqKQorCQliYXNpY19tYWNo
aW5lPXRpYzU0eC11bmtub3duCisJCW9zPS1jb2ZmCisJCTs7CisJdGljNTV4IHwgYzU1eCopCisJ
CWJhc2ljX21hY2hpbmU9dGljNTV4LXVua25vd24KKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM2eCB8
IGM2eCopCisJCWJhc2ljX21hY2hpbmU9dGljNngtdW5rbm93bgorCQlvcz0tY29mZgorCQk7Owor
ICAgICAgICAjIFRoaXMgbXVzdCBiZSBtYXRjaGVkIGJlZm9yZSB0aWxlKi4KKyAgICAgICAgdGls
ZWd4KikKKwkJYmFzaWNfbWFjaGluZT10aWxlZ3gtdW5rbm93bgorCQlvcz0tbGludXgtZ251CisJ
CTs7CisJdGlsZSopCisJCWJhc2ljX21hY2hpbmU9dGlsZS11bmtub3duCisJCW9zPS1saW51eC1n
bnUKKwkJOzsKKwl0eDM5KQorCQliYXNpY19tYWNoaW5lPW1pcHN0eDM5LXVua25vd24KKwkJOzsK
Kwl0eDM5ZWwpCisJCWJhc2ljX21hY2hpbmU9bWlwc3R4MzllbC11bmtub3duCisJCTs7CisJdG9h
ZDEpCisJCWJhc2ljX21hY2hpbmU9cGRwMTAteGtsCisJCW9zPS10b3BzMjAKKwkJOzsKKwl0b3dl
ciB8IHRvd2VyLTMyKQorCQliYXNpY19tYWNoaW5lPW02OGstbmNyCisJCTs7CisJdHBmKQorCQli
YXNpY19tYWNoaW5lPXMzOTB4LWlibQorCQlvcz0tdHBmCisJCTs7CisJdWRpMjlrKQorCQliYXNp
Y19tYWNoaW5lPWEyOWstYW1kCisJCW9zPS11ZGkKKwkJOzsKKwl1bHRyYTMpCisJCWJhc2ljX21h
Y2hpbmU9YTI5ay1ueXUKKwkJb3M9LXN5bTEKKwkJOzsKKwl2ODEwIHwgbmVjdjgxMCkKKwkJYmFz
aWNfbWFjaGluZT12ODEwLW5lYworCQlvcz0tbm9uZQorCQk7OworCXZheHYpCisJCWJhc2ljX21h
Y2hpbmU9dmF4LWRlYworCQlvcz0tc3lzdgorCQk7OworCXZtcykKKwkJYmFzaWNfbWFjaGluZT12
YXgtZGVjCisJCW9zPS12bXMKKwkJOzsKKwl2cHAqfHZ4fHZ4LSopCisJCWJhc2ljX21hY2hpbmU9
ZjMwMS1mdWppdHN1CisJCTs7CisJdnh3b3Jrczk2MCkKKwkJYmFzaWNfbWFjaGluZT1pOTYwLXdy
cworCQlvcz0tdnh3b3JrcworCQk7OworCXZ4d29ya3M2OCkKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LXdycworCQlvcz0tdnh3b3JrcworCQk7OworCXZ4d29ya3MyOWspCisJCWJhc2ljX21hY2hpbmU9
YTI5ay13cnMKKwkJb3M9LXZ4d29ya3MKKwkJOzsKKwl3NjUqKQorCQliYXNpY19tYWNoaW5lPXc2
NS13ZGMKKwkJb3M9LW5vbmUKKwkJOzsKKwl3ODlrLSopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEu
MS13aW5ib25kCisJCW9zPS1wcm9lbGYKKwkJOzsKKwl4Ym94KQorCQliYXNpY19tYWNoaW5lPWk2
ODYtcGMKKwkJb3M9LW1pbmd3MzIKKwkJOzsKKwl4cHMgfCB4cHMxMDApCisJCWJhc2ljX21hY2hp
bmU9eHBzMTAwLWhvbmV5d2VsbAorCQk7OworCXltcCkKKwkJYmFzaWNfbWFjaGluZT15bXAtY3Jh
eQorCQlvcz0tdW5pY29zCisJCTs7CisJejhrLSotY29mZikKKwkJYmFzaWNfbWFjaGluZT16OGst
dW5rbm93bgorCQlvcz0tc2ltCisJCTs7CisJejgwLSotY29mZikKKwkJYmFzaWNfbWFjaGluZT16
ODAtdW5rbm93bgorCQlvcz0tc2ltCisJCTs7CisJbm9uZSkKKwkJYmFzaWNfbWFjaGluZT1ub25l
LW5vbmUKKwkJb3M9LW5vbmUKKwkJOzsKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBt
YW51ZmFjdHVyZXIgb2YgY2VydGFpbiBDUFUgdHlwZXMuICBJdCBpcyBpbgorIyBzb21lIGNhc2Vz
IHRoZSBvbmx5IG1hbnVmYWN0dXJlciwgaW4gb3RoZXJzLCBpdCBpcyB0aGUgbW9zdCBwb3B1bGFy
LgorCXc4OWspCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS13aW5ib25kCisJCTs7CisJb3A1MG4p
CisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJOzsKKwlvcDYwYykKKwkJYmFzaWNfbWFj
aGluZT1ocHBhMS4xLW9raQorCQk7OworCXJvbXApCisJCWJhc2ljX21hY2hpbmU9cm9tcC1pYm0K
KwkJOzsKKwltbWl4KQorCQliYXNpY19tYWNoaW5lPW1taXgta251dGgKKwkJOzsKKwlyczYwMDAp
CisJCWJhc2ljX21hY2hpbmU9cnM2MDAwLWlibQorCQk7OworCXZheCkKKwkJYmFzaWNfbWFjaGlu
ZT12YXgtZGVjCisJCTs7CisJcGRwMTApCisJCSMgdGhlcmUgYXJlIG1hbnkgY2xvbmVzLCBzbyBE
RUMgaXMgbm90IGEgc2FmZSBiZXQKKwkJYmFzaWNfbWFjaGluZT1wZHAxMC11bmtub3duCisJCTs7
CisJcGRwMTEpCisJCWJhc2ljX21hY2hpbmU9cGRwMTEtZGVjCisJCTs7CisJd2UzMmspCisJCWJh
c2ljX21hY2hpbmU9d2UzMmstYXR0CisJCTs7CisJc2hbMTIzNF0gfCBzaFsyNF1hIHwgc2hbMjRd
YWViIHwgc2hbMzRdZWIgfCBzaFsxMjM0XWxlIHwgc2hbMjNdZWxlKQorCQliYXNpY19tYWNoaW5l
PXNoLXVua25vd24KKwkJOzsKKwlzcGFyYyB8IHNwYXJjdjggfCBzcGFyY3Y5IHwgc3BhcmN2OWIg
fCBzcGFyY3Y5dikKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJOzsKKwljeWRyYSkKKwkJ
YmFzaWNfbWFjaGluZT1jeWRyYS1jeWRyb21lCisJCTs7CisJb3Jpb24pCisJCWJhc2ljX21hY2hp
bmU9b3Jpb24taGlnaGxldmVsCisJCTs7CisJb3Jpb24xMDUpCisJCWJhc2ljX21hY2hpbmU9Y2xp
cHBlci1oaWdobGV2ZWwKKwkJOzsKKwltYWMgfCBtcHcgfCBtYWMtbXB3KQorCQliYXNpY19tYWNo
aW5lPW02OGstYXBwbGUKKwkJOzsKKwlwbWFjIHwgcG1hYy1tcHcpCisJCWJhc2ljX21hY2hpbmU9
cG93ZXJwYy1hcHBsZQorCQk7OworCSotdW5rbm93bikKKwkJIyBNYWtlIHN1cmUgdG8gbWF0Y2gg
YW4gYWxyZWFkeS1jYW5vbmljYWxpemVkIG1hY2hpbmUgbmFtZS4KKwkJOzsKKwkqKQorCQllY2hv
IEludmFsaWQgY29uZmlndXJhdGlvbiBcYCQxXCc6IG1hY2hpbmUgXGAkYmFzaWNfbWFjaGluZVwn
IG5vdCByZWNvZ25pemVkIDE+JjIKKwkJZXhpdCAxCisJCTs7Citlc2FjCisKKyMgSGVyZSB3ZSBj
YW5vbmljYWxpemUgY2VydGFpbiBhbGlhc2VzIGZvciBtYW51ZmFjdHVyZXJzLgorY2FzZSAkYmFz
aWNfbWFjaGluZSBpbgorCSotZGlnaXRhbCopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2lj
X21hY2hpbmUgfCBzZWQgJ3MvZGlnaXRhbC4qL2RlYy8nYAorCQk7OworCSotY29tbW9kb3JlKikK
KwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9jb21tb2RvcmUu
Ki9jYm0vJ2AKKwkJOzsKKwkqKQorCQk7OworZXNhYworCisjIERlY29kZSBtYW51ZmFjdHVyZXIt
c3BlY2lmaWMgYWxpYXNlcyBmb3IgY2VydGFpbiBvcGVyYXRpbmcgc3lzdGVtcy4KKworaWYgWyB4
IiRvcyIgIT0geCIiIF0KK3RoZW4KK2Nhc2UgJG9zIGluCisgICAgICAgICMgRmlyc3QgbWF0Y2gg
c29tZSBzeXN0ZW0gdHlwZSBhbGlhc2VzCisgICAgICAgICMgdGhhdCBtaWdodCBnZXQgY29uZnVz
ZWQgd2l0aCB2YWxpZCBzeXN0ZW0gdHlwZXMuCisJIyAtc29sYXJpcyogaXMgYSBiYXNpYyBzeXN0
ZW0gdHlwZSwgd2l0aCB0aGlzIG9uZSBleGNlcHRpb24uCisgICAgICAgIC1hdXJvcmF1eCkKKwkg
ICAgICAgIG9zPS1hdXJvcmF1eAorCQk7OworCS1zb2xhcmlzMSB8IC1zb2xhcmlzMS4qKQorCQlv
cz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8c29sYXJpczF8c3Vub3M0fCdgCisJCTs7CisJLXNvbGFy
aXMpCisJCW9zPS1zb2xhcmlzMgorCQk7OworCS1zdnI0KikKKwkJb3M9LXN5c3Y0CisJCTs7CisJ
LXVuaXh3YXJlKikKKwkJb3M9LXN5c3Y0LjJ1dworCQk7OworCS1nbnUvbGludXgqKQorCQlvcz1g
ZWNobyAkb3MgfCBzZWQgLWUgJ3N8Z251L2xpbnV4fGxpbnV4LWdudXwnYAorCQk7OworCSMgRmly
c3QgYWNjZXB0IHRoZSBiYXNpYyBzeXN0ZW0gdHlwZXMuCisJIyBUaGUgcG9ydGFibGUgc3lzdGVt
cyBjb21lcyBmaXJzdC4KKwkjIEVhY2ggYWx0ZXJuYXRpdmUgTVVTVCBFTkQgSU4gQSAqLCB0byBt
YXRjaCBhIHZlcnNpb24gbnVtYmVyLgorCSMgLXN5c3YqIGlzIG5vdCBoZXJlIGJlY2F1c2UgaXQg
Y29tZXMgbGF0ZXIsIGFmdGVyIHN5c3ZyNC4KKwktZ251KiB8IC1ic2QqIHwgLW1hY2gqIHwgLW1p
bml4KiB8IC1nZW5peCogfCAtdWx0cml4KiB8IC1pcml4KiBcCisJICAgICAgfCAtKnZtcyogfCAt
c2NvKiB8IC1lc2l4KiB8IC1pc2MqIHwgLWFpeCogfCAtY25rKiB8IC1zdW5vcyB8IC1zdW5vc1sz
NF0qXAorCSAgICAgIHwgLWhwdXgqIHwgLXVub3MqIHwgLW9zZiogfCAtbHVuYSogfCAtZGd1eCog
fCAtYXVyb3JhdXgqIHwgLXNvbGFyaXMqIFwKKwkgICAgICB8IC1zeW0qIHwgLWtvcGVuc29sYXJp
cyogXAorCSAgICAgIHwgLWFtaWdhb3MqIHwgLWFtaWdhZG9zKiB8IC1tc2RvcyogfCAtbmV3c29z
KiB8IC11bmljb3MqIHwgLWFvZiogXAorCSAgICAgIHwgLWFvcyogfCAtYXJvcyogXAorCSAgICAg
IHwgLW5pbmR5KiB8IC12eHNpbSogfCAtdnh3b3JrcyogfCAtZWJtb24qIHwgLWhtcyogfCAtbXZz
KiBcCisJICAgICAgfCAtY2xpeCogfCAtcmlzY29zKiB8IC11bmlwbHVzKiB8IC1pcmlzKiB8IC1y
dHUqIHwgLXhlbml4KiBcCisJICAgICAgfCAtaGl1eCogfCAtMzg2YnNkKiB8IC1rbmV0YnNkKiB8
IC1taXJic2QqIHwgLW5ldGJzZCogXAorCSAgICAgIHwgLW9wZW5ic2QqIHwgLXNvbGlkYnNkKiBc
CisJICAgICAgfCAtZWtrb2JzZCogfCAta2ZyZWVic2QqIHwgLWZyZWVic2QqIHwgLXJpc2NpeCog
fCAtbHlueG9zKiBcCisJICAgICAgfCAtYm9zeCogfCAtbmV4dHN0ZXAqIHwgLWN4dXgqIHwgLWFv
dXQqIHwgLWVsZiogfCAtb2FiaSogXAorCSAgICAgIHwgLXB0eCogfCAtY29mZiogfCAtZWNvZmYq
IHwgLXdpbm50KiB8IC1kb21haW4qIHwgLXZzdGEqIFwKKwkgICAgICB8IC11ZGkqIHwgLWVhYmkq
IHwgLWxpdGVzKiB8IC1pZWVlKiB8IC1nbzMyKiB8IC1hdXgqIFwKKwkgICAgICB8IC1jaG9ydXNv
cyogfCAtY2hvcnVzcmRiKiB8IC1jZWdjYyogXAorCSAgICAgIHwgLWN5Z3dpbiogfCAtcGUqIHwg
LXBzb3MqIHwgLW1vc3MqIHwgLXByb2VsZiogfCAtcnRlbXMqIFwKKwkgICAgICB8IC1taW5ndzMy
KiB8IC1saW51eC1nbnUqIHwgLWxpbnV4LW5ld2xpYiogfCAtbGludXgtdWNsaWJjKiBcCisJICAg
ICAgfCAtdXhwdiogfCAtYmVvcyogfCAtbXBlaXgqIHwgLXVkayogXAorCSAgICAgIHwgLWludGVy
aXgqIHwgLXV3aW4qIHwgLW1rcyogfCAtcmhhcHNvZHkqIHwgLWRhcndpbiogfCAtb3BlbmVkKiBc
CisJICAgICAgfCAtb3BlbnN0ZXAqIHwgLW9za2l0KiB8IC1jb25peCogfCAtcHczMiogfCAtbm9u
c3RvcHV4KiBcCisJICAgICAgfCAtc3Rvcm0tY2hhb3MqIHwgLXRvcHMxMCogfCAtdGVuZXgqIHwg
LXRvcHMyMCogfCAtaXRzKiBcCisJICAgICAgfCAtb3MyKiB8IC12b3MqIHwgLXBhbG1vcyogfCAt
dWNsaW51eCogfCAtbnVjbGV1cyogXAorCSAgICAgIHwgLW1vcnBob3MqIHwgLXN1cGVydXgqIHwg
LXJ0bWsqIHwgLXJ0bWstbm92YSogfCAtd2luZGlzcyogXAorCSAgICAgIHwgLXBvd2VybWF4KiB8
IC1kbml4KiB8IC1ueDYgfCAtbng3IHwgLXNlaSogfCAtZHJhZ29uZmx5KiBcCisJICAgICAgfCAt
c2t5b3MqIHwgLWhhaWt1KiB8IC1yZG9zKiB8IC10b3BwZXJzKiB8IC1kcm9wcyogfCAtZXMqKQor
CSMgUmVtZW1iZXIsIGVhY2ggYWx0ZXJuYXRpdmUgTVVTVCBFTkQgSU4gKiwgdG8gbWF0Y2ggYSB2
ZXJzaW9uIG51bWJlci4KKwkJOzsKKwktcW54KikKKwkJY2FzZSAkYmFzaWNfbWFjaGluZSBpbgor
CQkgICAgeDg2LSogfCBpKjg2LSopCisJCQk7OworCQkgICAgKikKKwkJCW9zPS1udG8kb3MKKwkJ
CTs7CisJCWVzYWMKKwkJOzsKKwktbnRvLXFueCopCisJCTs7CisJLW50byopCisJCW9zPWBlY2hv
ICRvcyB8IHNlZCAtZSAnc3xudG98bnRvLXFueHwnYAorCQk7OworCS1zaW0gfCAtZXMxODAwKiB8
IC1obXMqIHwgLXhyYXkgfCAtb3M2OGsqIHwgLW5vbmUqIHwgLXY4OHIqIFwKKwkgICAgICB8IC13
aW5kb3dzKiB8IC1vc3ggfCAtYWJ1ZyB8IC1uZXR3YXJlKiB8IC1vczkqIHwgLWJlb3MqIHwgLWhh
aWt1KiBcCisJICAgICAgfCAtbWFjb3MqIHwgLW1wdyogfCAtbWFnaWMqIHwgLW1taXh3YXJlKiB8
IC1tb245NjAqIHwgLWxuZXdzKikKKwkJOzsKKwktbWFjKikKKwkJb3M9YGVjaG8gJG9zIHwgc2Vk
IC1lICdzfG1hY3xtYWNvc3wnYAorCQk7OworCS1saW51eC1kaWV0bGliYykKKwkJb3M9LWxpbnV4
LWRpZXRsaWJjCisJCTs7CisJLWxpbnV4KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfGxp
bnV4fGxpbnV4LWdudXwnYAorCQk7OworCS1zdW5vczUqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQg
LWUgJ3N8c3Vub3M1fHNvbGFyaXMyfCdgCisJCTs7CisJLXN1bm9zNiopCisJCW9zPWBlY2hvICRv
cyB8IHNlZCAtZSAnc3xzdW5vczZ8c29sYXJpczN8J2AKKwkJOzsKKwktb3BlbmVkKikKKwkJb3M9
LW9wZW5lZGl0aW9uCisJCTs7CisgICAgICAgIC1vczQwMCopCisJCW9zPS1vczQwMAorCQk7Owor
CS13aW5jZSopCisJCW9zPS13aW5jZQorCQk7OworCS1vc2Zyb3NlKikKKwkJb3M9LW9zZnJvc2UK
KwkJOzsKKwktb3NmKikKKwkJb3M9LW9zZgorCQk7OworCS11dGVrKikKKwkJb3M9LWJzZAorCQk7
OworCS1keW5peCopCisJCW9zPS1ic2QKKwkJOzsKKwktYWNpcyopCisJCW9zPS1hb3MKKwkJOzsK
KwktYXRoZW9zKikKKwkJb3M9LWF0aGVvcworCQk7OworCS1zeWxsYWJsZSopCisJCW9zPS1zeWxs
YWJsZQorCQk7OworCS0zODZic2QpCisJCW9zPS1ic2QKKwkJOzsKKwktY3RpeCogfCAtdXRzKikK
KwkJb3M9LXN5c3YKKwkJOzsKKwktbm92YSopCisJCW9zPS1ydG1rLW5vdmEKKwkJOzsKKwktbnMy
ICkKKwkJb3M9LW5leHRzdGVwMgorCQk7OworCS1uc2sqKQorCQlvcz0tbnNrCisJCTs7CisJIyBQ
cmVzZXJ2ZSB0aGUgdmVyc2lvbiBudW1iZXIgb2Ygc2luaXg1LgorCS1zaW5peDUuKikKKwkJb3M9
YGVjaG8gJG9zIHwgc2VkIC1lICdzfHNpbml4fHN5c3Z8J2AKKwkJOzsKKwktc2luaXgqKQorCQlv
cz0tc3lzdjQKKwkJOzsKKyAgICAgICAgLXRwZiopCisJCW9zPS10cGYKKwkJOzsKKwktdHJpdG9u
KikKKwkJb3M9LXN5c3YzCisJCTs7CisJLW9zcyopCisJCW9zPS1zeXN2MworCQk7OworCS1zdnI0
KQorCQlvcz0tc3lzdjQKKwkJOzsKKwktc3ZyMykKKwkJb3M9LXN5c3YzCisJCTs7CisJLXN5c3Zy
NCkKKwkJb3M9LXN5c3Y0CisJCTs7CisJIyBUaGlzIG11c3QgY29tZSBhZnRlciAtc3lzdnI0Lgor
CS1zeXN2KikKKwkJOzsKKwktb3NlKikKKwkJb3M9LW9zZQorCQk7OworCS1lczE4MDAqKQorCQlv
cz0tb3NlCisJCTs7CisJLXhlbml4KQorCQlvcz0teGVuaXgKKwkJOzsKKwktKm1pbnQgfCAtbWlu
dFswLTldKiB8IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQorCQlvcz0tbWludAorCQk7OworCS1hcm9z
KikKKwkJb3M9LWFyb3MKKwkJOzsKKwkta2FvcyopCisJCW9zPS1rYW9zCisJCTs7CisJLXp2bW9l
KQorCQlvcz0tenZtb2UKKwkJOzsKKwktZGljb3MqKQorCQlvcz0tZGljb3MKKwkJOzsKKyAgICAg
ICAgLW5hY2wqKQorCSAgICAgICAgOzsKKwktbm9uZSkKKwkJOzsKKwkqKQorCQkjIEdldCByaWQg
b2YgdGhlIGAtJyBhdCB0aGUgYmVnaW5uaW5nIG9mICRvcy4KKwkJb3M9YGVjaG8gJG9zIHwgc2Vk
ICdzL1teLV0qLS8vJ2AKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBzeXN0
ZW0gXGAkb3NcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworZXNhYworZWxz
ZQorCisjIEhlcmUgd2UgaGFuZGxlIHRoZSBkZWZhdWx0IG9wZXJhdGluZyBzeXN0ZW1zIHRoYXQg
Y29tZSB3aXRoIHZhcmlvdXMgbWFjaGluZXMuCisjIFRoZSB2YWx1ZSBzaG91bGQgYmUgd2hhdCB0
aGUgdmVuZG9yIGN1cnJlbnRseSBzaGlwcyBvdXQgdGhlIGRvb3Igd2l0aCB0aGVpcgorIyBtYWNo
aW5lIG9yIHB1dCBhbm90aGVyIHdheSwgdGhlIG1vc3QgcG9wdWxhciBvcyBwcm92aWRlZCB3aXRo
IHRoZSBtYWNoaW5lLgorCisjIE5vdGUgdGhhdCBpZiB5b3UncmUgZ29pbmcgdG8gdHJ5IHRvIG1h
dGNoICItTUFOVUZBQ1RVUkVSIiBoZXJlIChzYXksCisjICItc3VuIiksIHRoZW4geW91IGhhdmUg
dG8gdGVsbCB0aGUgY2FzZSBzdGF0ZW1lbnQgdXAgdG93YXJkcyB0aGUgdG9wCisjIHRoYXQgTUFO
VUZBQ1RVUkVSIGlzbid0IGFuIG9wZXJhdGluZyBzeXN0ZW0uICBPdGhlcndpc2UsIGNvZGUgYWJv
dmUKKyMgd2lsbCBzaWduYWwgYW4gZXJyb3Igc2F5aW5nIHRoYXQgTUFOVUZBQ1RVUkVSIGlzbid0
IGFuIG9wZXJhdGluZworIyBzeXN0ZW0sIGFuZCB3ZSdsbCBuZXZlciBnZXQgdG8gdGhpcyBwb2lu
dC4KKworY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorICAgICAgICBzY29yZS0qKQorCQlvcz0tZWxm
CisJCTs7CisgICAgICAgIHNwdS0qKQorCQlvcz0tZWxmCisJCTs7CisJKi1hY29ybikKKwkJb3M9
LXJpc2NpeDEuMgorCQk7OworCWFybSotcmViZWwpCisJCW9zPS1saW51eAorCQk7OworCWFybSot
c2VtaSkKKwkJb3M9LWFvdXQKKwkJOzsKKyAgICAgICAgYzR4LSogfCB0aWM0eC0qKQorICAgICAg
ICAJb3M9LWNvZmYKKwkJOzsKKwkjIFRoaXMgbXVzdCBjb21lIGJlZm9yZSB0aGUgKi1kZWMgZW50
cnkuCisJcGRwMTAtKikKKwkJb3M9LXRvcHMyMAorCQk7OworCXBkcDExLSopCisJCW9zPS1ub25l
CisJCTs7CisJKi1kZWMgfCB2YXgtKikKKwkJb3M9LXVsdHJpeDQuMgorCQk7OworCW02OCotYXBv
bGxvKQorCQlvcz0tZG9tYWluCisJCTs7CisJaTM4Ni1zdW4pCisJCW9zPS1zdW5vczQuMC4yCisJ
CTs7CisJbTY4MDAwLXN1bikKKwkJb3M9LXN1bm9zMworCQkjIFRoaXMgYWxzbyBleGlzdHMgaW4g
dGhlIGNvbmZpZ3VyZSBwcm9ncmFtLCBidXQgd2FzIG5vdCB0aGUKKwkJIyBkZWZhdWx0LgorCQkj
IG9zPS1zdW5vczQKKwkJOzsKKwltNjgqLWNpc2NvKQorCQlvcz0tYW91dAorCQk7OworICAgICAg
ICBtZXAtKikKKwkJb3M9LWVsZgorCQk7OworCW1pcHMqLWNpc2NvKQorCQlvcz0tZWxmCisJCTs7
CisJbWlwcyotKikKKwkJb3M9LWVsZgorCQk7OworCW9yMzItKikKKwkJb3M9LWNvZmYKKwkJOzsK
KwkqLXR0aSkJIyBtdXN0IGJlIGJlZm9yZSBzcGFyYyBlbnRyeSBvciB3ZSBnZXQgdGhlIHdyb25n
IG9zLgorCQlvcz0tc3lzdjMKKwkJOzsKKwlzcGFyYy0qIHwgKi1zdW4pCisJCW9zPS1zdW5vczQu
MS4xCisJCTs7CisJKi1iZSkKKwkJb3M9LWJlb3MKKwkJOzsKKwkqLWhhaWt1KQorCQlvcz0taGFp
a3UKKwkJOzsKKwkqLWlibSkKKwkJb3M9LWFpeAorCQk7OworICAgIAkqLWtudXRoKQorCQlvcz0t
bW1peHdhcmUKKwkJOzsKKwkqLXdlYykKKwkJb3M9LXByb2VsZgorCQk7OworCSotd2luYm9uZCkK
KwkJb3M9LXByb2VsZgorCQk7OworCSotb2tpKQorCQlvcz0tcHJvZWxmCisJCTs7CisJKi1ocCkK
KwkJb3M9LWhwdXgKKwkJOzsKKwkqLWhpdGFjaGkpCisJCW9zPS1oaXV4CisJCTs7CisJaTg2MC0q
IHwgKi1hdHQgfCAqLW5jciB8ICotYWx0b3MgfCAqLW1vdG9yb2xhIHwgKi1jb252ZXJnZW50KQor
CQlvcz0tc3lzdgorCQk7OworCSotY2JtKQorCQlvcz0tYW1pZ2FvcworCQk7OworCSotZGcpCisJ
CW9zPS1kZ3V4CisJCTs7CisJKi1kb2xwaGluKQorCQlvcz0tc3lzdjMKKwkJOzsKKwltNjhrLWNj
dXIpCisJCW9zPS1ydHUKKwkJOzsKKwltODhrLW9tcm9uKikKKwkJb3M9LWx1bmEKKwkJOzsKKwkq
LW5leHQgKQorCQlvcz0tbmV4dHN0ZXAKKwkJOzsKKwkqLXNlcXVlbnQpCisJCW9zPS1wdHgKKwkJ
OzsKKwkqLWNyZHMpCisJCW9zPS11bm9zCisJCTs7CisJKi1ucykKKwkJb3M9LWdlbml4CisJCTs7
CisJaTM3MC0qKQorCQlvcz0tbXZzCisJCTs7CisJKi1uZXh0KQorCQlvcz0tbmV4dHN0ZXAzCisJ
CTs7CisJKi1nb3VsZCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWhpZ2hsZXZlbCkKKwkJb3M9LWJz
ZAorCQk7OworCSotZW5jb3JlKQorCQlvcz0tYnNkCisJCTs7CisJKi1zZ2kpCisJCW9zPS1pcml4
CisJCTs7CisJKi1zaWVtZW5zKQorCQlvcz0tc3lzdjQKKwkJOzsKKwkqLW1hc3Njb21wKQorCQlv
cz0tcnR1CisJCTs7CisJZjMwWzAxXS1mdWppdHN1IHwgZjcwMC1mdWppdHN1KQorCQlvcz0tdXhw
dgorCQk7OworCSotcm9tNjhrKQorCQlvcz0tY29mZgorCQk7OworCSotKmJ1ZykKKwkJb3M9LWNv
ZmYKKwkJOzsKKwkqLWFwcGxlKQorCQlvcz0tbWFjb3MKKwkJOzsKKwkqLWF0YXJpKikKKwkJb3M9
LW1pbnQKKwkJOzsKKwkqKQorCQlvcz0tbm9uZQorCQk7OworZXNhYworZmkKKworIyBIZXJlIHdl
IGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB3ZSBrbm93IHRoZSBvcywgYW5kIHRoZSBDUFUgdHlwZSwg
YnV0IG5vdCB0aGUKKyMgbWFudWZhY3R1cmVyLiAgV2UgcGljayB0aGUgbG9naWNhbCBtYW51ZmFj
dHVyZXIuCit2ZW5kb3I9dW5rbm93bgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSotdW5rbm93
bikKKwkJY2FzZSAkb3MgaW4KKwkJCS1yaXNjaXgqKQorCQkJCXZlbmRvcj1hY29ybgorCQkJCTs7
CisJCQktc3Vub3MqKQorCQkJCXZlbmRvcj1zdW4KKwkJCQk7OworCQkJLWNuayp8LWFpeCopCisJ
CQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktYmVvcyopCisJCQkJdmVuZG9yPWJlCisJCQkJOzsK
KwkJCS1ocHV4KikKKwkJCQl2ZW5kb3I9aHAKKwkJCQk7OworCQkJLW1wZWl4KikKKwkJCQl2ZW5k
b3I9aHAKKwkJCQk7OworCQkJLWhpdXgqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsKKwkJ
CS11bm9zKikKKwkJCQl2ZW5kb3I9Y3JkcworCQkJCTs7CisJCQktZGd1eCopCisJCQkJdmVuZG9y
PWRnCisJCQkJOzsKKwkJCS1sdW5hKikKKwkJCQl2ZW5kb3I9b21yb24KKwkJCQk7OworCQkJLWdl
bml4KikKKwkJCQl2ZW5kb3I9bnMKKwkJCQk7OworCQkJLW12cyogfCAtb3BlbmVkKikKKwkJCQl2
ZW5kb3I9aWJtCisJCQkJOzsKKwkJCS1vczQwMCopCisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJ
CQktcHR4KikKKwkJCQl2ZW5kb3I9c2VxdWVudAorCQkJCTs7CisJCQktdHBmKikKKwkJCQl2ZW5k
b3I9aWJtCisJCQkJOzsKKwkJCS12eHNpbSogfCAtdnh3b3JrcyogfCAtd2luZGlzcyopCisJCQkJ
dmVuZG9yPXdycworCQkJCTs7CisJCQktYXV4KikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7Owor
CQkJLWhtcyopCisJCQkJdmVuZG9yPWhpdGFjaGkKKwkJCQk7OworCQkJLW1wdyogfCAtbWFjb3Mq
KQorCQkJCXZlbmRvcj1hcHBsZQorCQkJCTs7CisJCQktKm1pbnQgfCAtbWludFswLTldKiB8IC0q
TWlOVCB8IC1NaU5UWzAtOV0qKQorCQkJCXZlbmRvcj1hdGFyaQorCQkJCTs7CisJCQktdm9zKikK
KwkJCQl2ZW5kb3I9c3RyYXR1cworCQkJCTs7CisJCWVzYWMKKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkYmFzaWNfbWFjaGluZSB8IHNlZCAicy91bmtub3duLyR2ZW5kb3IvImAKKwkJOzsKK2VzYWMK
KworZWNobyAkYmFzaWNfbWFjaGluZSRvcworZXhpdAorCisjIExvY2FsIHZhcmlhYmxlczoKKyMg
ZXZhbDogKGFkZC1ob29rICd3cml0ZS1maWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1lLXN0
YW1wLXN0YXJ0OiAidGltZXN0YW1wPSciCisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0t
JTAyZCIKKyMgdGltZS1zdGFtcC1lbmQ6ICInIgorIyBFbmQ6CmRpZmYgLXIgNWIyNjc2YWMxMzIx
IC1yIDZmZGUwMTdjNDE5ZSB0b29scy9jb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlndXJlCVR1ZSBKYW4gMTAgMTk6
MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwMTUzIEBACisjISAvYmluL3NoCisjIEd1ZXNz
IHZhbHVlcyBmb3Igc3lzdGVtLWRlcGVuZGVudCB2YXJpYWJsZXMgYW5kIGNyZWF0ZSBNYWtlZmls
ZXMuCisjIEdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42Ny4KKyMKKyMKKyMgQ29weXJpZ2h0
IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk4LCAxOTk5LCAyMDAwLCAyMDAx
LAorIyAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEw
IEZyZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLgorIworIworIyBUaGlzIGNvbmZpZ3Vy
ZSBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbgor
IyBnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBjb3B5LCBkaXN0cmlidXRlIGFuZCBtb2Rp
ZnkgaXQuCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTTRzaCBJbml0aWFsaXphdGlv
bi4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMgQmUgbW9yZSBCb3VybmUgY29t
cGF0aWJsZQorRFVBTENBU0U9MTsgZXhwb3J0IERVQUxDQVNFICMgZm9yIE1LUyBzaAoraWYgdGVz
dCAtbiAiJHtaU0hfVkVSU0lPTitzZXR9IiAmJiAoZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYx
OyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25z
IG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiAkezErIiRAIn0sIHdoaWNoCisgICMgaXMgY29u
dHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1nICck
ezErIiRAIn0nPSciJEAiJworICBzZXRvcHQgTk9fR0xPQl9TVUJTVAorZWxzZQorICBjYXNlIGAo
c2V0IC1vKSAyPi9kZXYvbnVsbGAgaW4gIygKKyAgKnBvc2l4KikgOgorICAgIHNldCAtbyBwb3Np
eCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorCisKK2FzX25sPScKKycKK2V4cG9y
dCBhc19ubAorIyBQcmludGluZyBhIGxvbmcgc3RyaW5nIGNyYXNoZXMgU29sYXJpcyA3IC91c3Iv
YmluL3ByaW50Zi4KK2FzX2VjaG89J1xcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFwnCithc19lY2hvPSRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFz
X2VjaG8KK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRh
c19lY2hvCisjIFByZWZlciBhIGtzaCBzaGVsbCBidWlsdGluIG92ZXIgYW4gZXh0ZXJuYWwgcHJp
bnRmIHByb2dyYW0gb24gU29sYXJpcywKKyMgYnV0IHdpdGhvdXQgd2FzdGluZyBmb3JrcyBmb3Ig
YmFzaCBvciB6c2guCitpZiB0ZXN0IC16ICIkQkFTSF9WRVJTSU9OJFpTSF9WRVJTSU9OIiBcCisg
ICAgJiYgKHRlc3QgIlhgcHJpbnQgLXIgLS0gJGFzX2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9k
ZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmludCAtciAtLScKKyAgYXNfZWNob19uPSdwcmlu
dCAtcm4gLS0nCitlbGlmICh0ZXN0ICJYYHByaW50ZiAlcyAkYXNfZWNob2AiID0gIlgkYXNfZWNo
byIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50ZiAlc1xuJworICBhc19lY2hv
X249J3ByaW50ZiAlcycKK2Vsc2UKKyAgaWYgdGVzdCAiWGAoL3Vzci91Y2IvZWNobyAtbiAtbiAk
YXNfZWNobykgMj4vZGV2L251bGxgIiA9ICJYLW4gJGFzX2VjaG8iOyB0aGVuCisgICAgYXNfZWNo
b19ib2R5PSdldmFsIC91c3IvdWNiL2VjaG8gLW4gIiQxJGFzX25sIicKKyAgICBhc19lY2hvX249
Jy91c3IvdWNiL2VjaG8gLW4nCisgIGVsc2UKKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgZXhwciAi
WCQxIiA6ICJYXFwoLipcXCkiJworICAgIGFzX2VjaG9fbl9ib2R5PSdldmFsCisgICAgICBhcmc9
JDE7CisgICAgICBjYXNlICRhcmcgaW4gIygKKyAgICAgICoiJGFzX25sIiopCisJZXhwciAiWCRh
cmciIDogIlhcXCguKlxcKSRhc19ubCI7CisJYXJnPWBleHByICJYJGFyZyIgOiAiLiokYXNfbmxc
XCguKlxcKSJgOzsKKyAgICAgIGVzYWM7CisgICAgICBleHByICJYJGFyZyIgOiAiWFxcKC4qXFwp
IiB8IHRyIC1kICIkYXNfbmwiCisgICAgJworICAgIGV4cG9ydCBhc19lY2hvX25fYm9keQorICAg
IGFzX2VjaG9fbj0nc2ggLWMgJGFzX2VjaG9fbl9ib2R5IGFzX2VjaG8nCisgIGZpCisgIGV4cG9y
dCBhc19lY2hvX2JvZHkKKyAgYXNfZWNobz0nc2ggLWMgJGFzX2VjaG9fYm9keSBhc19lY2hvJwor
ZmkKKworIyBUaGUgdXNlciBpcyBhbHdheXMgcmlnaHQuCitpZiB0ZXN0ICIke1BBVEhfU0VQQVJB
VE9SK3NldH0iICE9IHNldDsgdGhlbgorICBQQVRIX1NFUEFSQVRPUj06CisgIChQQVRIPScvYmlu
Oy9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVsbCAyPiYxICYmIHsKKyAgICAo
UEFUSD0nL2JpbjovYmluJzsgRlBBVEg9JFBBVEg7IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSB8
fAorICAgICAgUEFUSF9TRVBBUkFUT1I9JzsnCisgIH0KK2ZpCisKKworIyBJRlMKKyMgV2UgbmVl
ZCBzcGFjZSwgdGFiIGFuZCBuZXcgbGluZSwgaW4gcHJlY2lzZWx5IHRoYXQgb3JkZXIuICBRdW90
aW5nIGlzCisjIHRoZXJlIHRvIHByZXZlbnQgZWRpdG9ycyBmcm9tIGNvbXBsYWluaW5nIGFib3V0
IHNwYWNlLXRhYi4KKyMgKElmIF9BU19QQVRIX1dBTEsgd2VyZSBjYWxsZWQgd2l0aCBJRlMgdW5z
ZXQsIGl0IHdvdWxkIGRpc2FibGUgd29yZAorIyBzcGxpdHRpbmcgYnkgc2V0dGluZyBJRlMgdG8g
ZW1wdHkgdmFsdWUuKQorSUZTPSIgIiIJJGFzX25sIgorCisjIEZpbmQgd2hvIHdlIGFyZS4gIExv
b2sgaW4gdGhlIHBhdGggaWYgd2UgY29udGFpbiBubyBkaXJlY3Rvcnkgc2VwYXJhdG9yLgorY2Fz
ZSAkMCBpbiAjKCgKKyAgKltcXC9dKiApIGFzX215c2VsZj0kMCA7OworICAqKSBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgdGVz
dCAtciAiJGFzX2Rpci8kMCIgJiYgYXNfbXlzZWxmPSRhc19kaXIvJDAgJiYgYnJlYWsKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgICAgIDs7Citlc2FjCisjIFdlIGRpZCBub3QgZmluZCBv
dXJzZWx2ZXMsIG1vc3QgcHJvYmFibHkgd2Ugd2VyZSBydW4gYXMgYHNoIENPTU1BTkQnCisjIGlu
IHdoaWNoIGNhc2Ugd2UgYXJlIG5vdCB0byBiZSBmb3VuZCBpbiB0aGUgcGF0aC4KK2lmIHRlc3Qg
IngkYXNfbXlzZWxmIiA9IHg7IHRoZW4KKyAgYXNfbXlzZWxmPSQwCitmaQoraWYgdGVzdCAhIC1m
ICIkYXNfbXlzZWxmIjsgdGhlbgorICAkYXNfZWNobyAiJGFzX215c2VsZjogZXJyb3I6IGNhbm5v
dCBmaW5kIG15c2VsZjsgcmVydW4gd2l0aCBhbiBhYnNvbHV0ZSBmaWxlIG5hbWUiID4mMgorICBl
eGl0IDEKK2ZpCisKKyMgVW5zZXQgdmFyaWFibGVzIHRoYXQgd2UgZG8gbm90IG5lZWQgYW5kIHdo
aWNoIGNhdXNlIGJ1Z3MgKGUuZy4gaW4KKyMgcHJlLTMuMCBVV0lOIGtzaCkuICBCdXQgZG8gbm90
IGNhdXNlIGJ1Z3MgaW4gYmFzaCAyLjAxOyB0aGUgInx8IGV4aXQgMSIKKyMgc3VwcHJlc3NlcyBh
bnkgIlNlZ21lbnRhdGlvbiBmYXVsdCIgbWVzc2FnZSB0aGVyZS4gICcoKCcgY291bGQKKyMgdHJp
Z2dlciBhIGJ1ZyBpbiBwZGtzaCA1LjIuMTQuCitmb3IgYXNfdmFyIGluIEJBU0hfRU5WIEVOViBN
QUlMIE1BSUxQQVRICitkbyBldmFsIHRlc3QgeFwkeyRhc192YXIrc2V0fSA9IHhzZXQgXAorICAm
JiAoICh1bnNldCAkYXNfdmFyKSB8fCBleGl0IDEpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCAk
YXNfdmFyIHx8IDoKK2RvbmUKK1BTMT0nJCAnCitQUzI9Jz4gJworUFM0PScrICcKKworIyBOTFMg
bnVpc2FuY2VzLgorTENfQUxMPUMKK2V4cG9ydCBMQ19BTEwKK0xBTkdVQUdFPUMKK2V4cG9ydCBM
QU5HVUFHRQorCisjIENEUEFUSC4KKyh1bnNldCBDRFBBVEgpID4vZGV2L251bGwgMj4mMSAmJiB1
bnNldCBDRFBBVEgKKworaWYgdGVzdCAieCRDT05GSUdfU0hFTEwiID0geDsgdGhlbgorICBhc19i
b3VybmVfY29tcGF0aWJsZT0iaWYgdGVzdCAtbiBcIlwke1pTSF9WRVJTSU9OK3NldH1cIiAmJiAo
ZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxM
Q01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiBc
JHsxK1wiXCRAXCJ9LCB3aGljaAorICAjIGlzIGNvbnRyYXJ5IHRvIG91ciB1c2FnZS4gIERpc2Fi
bGUgdGhpcyBmZWF0dXJlLgorICBhbGlhcyAtZyAnXCR7MStcIlwkQFwifSc9J1wiXCRAXCInCisg
IHNldG9wdCBOT19HTE9CX1NVQlNUCitlbHNlCisgIGNhc2UgXGAoc2V0IC1vKSAyPi9kZXYvbnVs
bFxgIGluICMoCisgICpwb3NpeCopIDoKKyAgICBzZXQgLW8gcG9zaXggOzsgIygKKyAgKikgOgor
ICAgICA7OworZXNhYworZmkKKyIKKyAgYXNfcmVxdWlyZWQ9ImFzX2ZuX3JldHVybiAoKSB7IChl
eGl0IFwkMSk7IH0KK2FzX2ZuX3N1Y2Nlc3MgKCkgeyBhc19mbl9yZXR1cm4gMDsgfQorYXNfZm5f
ZmFpbHVyZSAoKSB7IGFzX2ZuX3JldHVybiAxOyB9Cithc19mbl9yZXRfc3VjY2VzcyAoKSB7IHJl
dHVybiAwOyB9Cithc19mbl9yZXRfZmFpbHVyZSAoKSB7IHJldHVybiAxOyB9CisKK2V4aXRjb2Rl
PTAKK2FzX2ZuX3N1Y2Nlc3MgfHwgeyBleGl0Y29kZT0xOyBlY2hvIGFzX2ZuX3N1Y2Nlc3MgZmFp
bGVkLjsgfQorYXNfZm5fZmFpbHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fZmFpbHVy
ZSBzdWNjZWVkZWQuOyB9Cithc19mbl9yZXRfc3VjY2VzcyB8fCB7IGV4aXRjb2RlPTE7IGVjaG8g
YXNfZm5fcmV0X3N1Y2Nlc3MgZmFpbGVkLjsgfQorYXNfZm5fcmV0X2ZhaWx1cmUgJiYgeyBleGl0
Y29kZT0xOyBlY2hvIGFzX2ZuX3JldF9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2lmICggc2V0IHg7
IGFzX2ZuX3JldF9zdWNjZXNzIHkgJiYgdGVzdCB4ID0gXCJcJDFcIiApOyB0aGVuIDoKKworZWxz
ZQorICBleGl0Y29kZT0xOyBlY2hvIHBvc2l0aW9uYWwgcGFyYW1ldGVycyB3ZXJlIG5vdCBzYXZl
ZC4KK2ZpCit0ZXN0IHhcJGV4aXRjb2RlID0geDAgfHwgZXhpdCAxIgorICBhc19zdWdnZXN0ZWQ9
IiAgYXNfbGluZW5vXzE9Ijthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCRMSU5FTk87YXNfc3Vn
Z2VzdGVkPSRhc19zdWdnZXN0ZWQiIGFzX2xpbmVub18xYT1cJExJTkVOTworICBhc19saW5lbm9f
Mj0iO2FzX3N1Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1
Z2dlc3RlZCIgYXNfbGluZW5vXzJhPVwkTElORU5PCisgIGV2YWwgJ3Rlc3QgXCJ4XCRhc19saW5l
bm9fMSdcJGFzX3J1bidcIiAhPSBcInhcJGFzX2xpbmVub18yJ1wkYXNfcnVuJ1wiICYmCisgIHRl
c3QgXCJ4XGBleHByIFwkYXNfbGluZW5vXzEnXCRhc19ydW4nICsgMVxgXCIgPSBcInhcJGFzX2xp
bmVub18yJ1wkYXNfcnVuJ1wiJyB8fCBleGl0IDEKK3Rlc3QgXCQoKCAxICsgMSApKSA9IDIgfHwg
ZXhpdCAxIgorICBpZiAoZXZhbCAiJGFzX3JlcXVpcmVkIikgMj4vZGV2L251bGw7IHRoZW4gOgor
ICBhc19oYXZlX3JlcXVpcmVkPXllcworZWxzZQorICBhc19oYXZlX3JlcXVpcmVkPW5vCitmaQor
ICBpZiB0ZXN0IHgkYXNfaGF2ZV9yZXF1aXJlZCA9IHh5ZXMgJiYgKGV2YWwgIiRhc19zdWdnZXN0
ZWQiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisKK2Vsc2UKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorYXNfZm91bmQ9ZmFsc2UKK2ZvciBhc19kaXIgaW4gL2JpbiRQQVRI
X1NFUEFSQVRPUi91c3IvYmluJFBBVEhfU0VQQVJBVE9SJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgYXNfZm91bmQ9OgorICBj
YXNlICRhc19kaXIgaW4gIygKKwkgLyopCisJICAgZm9yIGFzX2Jhc2UgaW4gc2ggYmFzaCBrc2gg
c2g1OyBkbworCSAgICAgIyBUcnkgb25seSBzaGVsbHMgdGhhdCBleGlzdCwgdG8gc2F2ZSBzZXZl
cmFsIGZvcmtzLgorCSAgICAgYXNfc2hlbGw9JGFzX2Rpci8kYXNfYmFzZQorCSAgICAgaWYgeyB0
ZXN0IC1mICIkYXNfc2hlbGwiIHx8IHRlc3QgLWYgIiRhc19zaGVsbC5leGUiOyB9ICYmCisJCSAg
ICB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUiIiRhc19yZXF1aXJlZCIgfCBhc19y
dW49YSAiJGFzX3NoZWxsIjsgfSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIENPTkZJR19TSEVMTD0k
YXNfc2hlbGwgYXNfaGF2ZV9yZXF1aXJlZD15ZXMKKwkJICAgaWYgeyAkYXNfZWNobyAiJGFzX2Jv
dXJuZV9jb21wYXRpYmxlIiIkYXNfc3VnZ2VzdGVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9
IDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgYnJlYWsgMgorZmkKK2ZpCisJICAgZG9uZTs7CisgICAg
ICAgZXNhYworICBhc19mb3VuZD1mYWxzZQorZG9uZQorJGFzX2ZvdW5kIHx8IHsgaWYgeyB0ZXN0
IC1mICIkU0hFTEwiIHx8IHRlc3QgLWYgIiRTSEVMTC5leGUiOyB9ICYmCisJICAgICAgeyAkYXNf
ZWNobyAiJGFzX2JvdXJuZV9jb21wYXRpYmxlIiIkYXNfcmVxdWlyZWQiIHwgYXNfcnVuPWEgIiRT
SEVMTCI7IH0gMj4vZGV2L251bGw7IHRoZW4gOgorICBDT05GSUdfU0hFTEw9JFNIRUxMIGFzX2hh
dmVfcmVxdWlyZWQ9eWVzCitmaTsgfQorSUZTPSRhc19zYXZlX0lGUworCisKKyAgICAgIGlmIHRl
c3QgIngkQ09ORklHX1NIRUxMIiAhPSB4OyB0aGVuIDoKKyAgIyBXZSBjYW5ub3QgeWV0IGFzc3Vt
ZSBhIGRlY2VudCBzaGVsbCwgc28gd2UgaGF2ZSB0byBwcm92aWRlIGEKKwkjIG5ldXRyYWxpemF0
aW9uIHZhbHVlIGZvciBzaGVsbHMgd2l0aG91dCB1bnNldDsgYW5kIHRoaXMgYWxzbworCSMgd29y
a3MgYXJvdW5kIHNoZWxscyB0aGF0IGNhbm5vdCB1bnNldCBub25leGlzdGVudCB2YXJpYWJsZXMu
CisJQkFTSF9FTlY9L2Rldi9udWxsCisJRU5WPS9kZXYvbnVsbAorCSh1bnNldCBCQVNIX0VOVikg
Pi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IEJBU0hfRU5WIEVOVgorCWV4cG9ydCBDT05GSUdfU0hF
TEwKKwlleGVjICIkQ09ORklHX1NIRUxMIiAiJGFzX215c2VsZiIgJHsxKyIkQCJ9CitmaQorCisg
ICAgaWYgdGVzdCB4JGFzX2hhdmVfcmVxdWlyZWQgPSB4bm87IHRoZW4gOgorICAkYXNfZWNobyAi
JDA6IFRoaXMgc2NyaXB0IHJlcXVpcmVzIGEgc2hlbGwgbW9yZSBtb2Rlcm4gdGhhbiBhbGwiCisg
ICRhc19lY2hvICIkMDogdGhlIHNoZWxscyB0aGF0IEkgZm91bmQgb24geW91ciBzeXN0ZW0uIgor
ICBpZiB0ZXN0IHgke1pTSF9WRVJTSU9OK3NldH0gPSB4c2V0IDsgdGhlbgorICAgICRhc19lY2hv
ICIkMDogSW4gcGFydGljdWxhciwgenNoICRaU0hfVkVSU0lPTiBoYXMgYnVncyBhbmQgc2hvdWxk
IgorICAgICRhc19lY2hvICIkMDogYmUgdXBncmFkZWQgdG8genNoIDQuMy40IG9yIGxhdGVyLiIK
KyAgZWxzZQorICAgICRhc19lY2hvICIkMDogUGxlYXNlIHRlbGwgYnVnLWF1dG9jb25mQGdudS5v
cmcgYWJvdXQgeW91ciBzeXN0ZW0sCiskMDogaW5jbHVkaW5nIGFueSBlcnJvciBwb3NzaWJseSBv
dXRwdXQgYmVmb3JlIHRoaXMKKyQwOiBtZXNzYWdlLiBUaGVuIGluc3RhbGwgYSBtb2Rlcm4gc2hl
bGwsIG9yIG1hbnVhbGx5IHJ1bgorJDA6IHRoZSBzY3JpcHQgdW5kZXIgc3VjaCBhIHNoZWxsIGlm
IHlvdSBkbyBoYXZlIG9uZS4iCisgIGZpCisgIGV4aXQgMQorZmkKK2ZpCitmaQorU0hFTEw9JHtD
T05GSUdfU0hFTEwtL2Jpbi9zaH0KK2V4cG9ydCBTSEVMTAorIyBVbnNldCBtb3JlIHZhcmlhYmxl
cyBrbm93biB0byBpbnRlcmZlcmUgd2l0aCBiZWhhdmlvciBvZiBjb21tb24gdG9vbHMuCitDTElD
T0xPUl9GT1JDRT0gR1JFUF9PUFRJT05TPQordW5zZXQgQ0xJQ09MT1JfRk9SQ0UgR1JFUF9PUFRJ
T05TCisKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTTRzaCBTaGVsbCBGdW5jdGlv
bnMuICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMgYXNfZm5fdW5zZXQgVkFSCisj
IC0tLS0tLS0tLS0tLS0tLQorIyBQb3J0YWJseSB1bnNldCBWQVIuCithc19mbl91bnNldCAoKQor
eworICB7IGV2YWwgJDE9OyB1bnNldCAkMTt9Cit9Cithc191bnNldD1hc19mbl91bnNldAorCisj
IGFzX2ZuX3NldF9zdGF0dXMgU1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFNl
dCAkPyB0byBTVEFUVVMsIHdpdGhvdXQgZm9ya2luZy4KK2FzX2ZuX3NldF9zdGF0dXMgKCkKK3sK
KyAgcmV0dXJuICQxCit9ICMgYXNfZm5fc2V0X3N0YXR1cworCisjIGFzX2ZuX2V4aXQgU1RBVFVT
CisjIC0tLS0tLS0tLS0tLS0tLS0tCisjIEV4aXQgdGhlIHNoZWxsIHdpdGggU1RBVFVTLCBldmVu
IGluIGEgInRyYXAgMCIgb3IgInNldCAtZSIgY29udGV4dC4KK2FzX2ZuX2V4aXQgKCkKK3sKKyAg
c2V0ICtlCisgIGFzX2ZuX3NldF9zdGF0dXMgJDEKKyAgZXhpdCAkMQorfSAjIGFzX2ZuX2V4aXQK
KworIyBhc19mbl9ta2Rpcl9wCisjIC0tLS0tLS0tLS0tLS0KKyMgQ3JlYXRlICIkYXNfZGlyIiBh
cyBhIGRpcmVjdG9yeSwgaW5jbHVkaW5nIHBhcmVudHMgaWYgbmVjZXNzYXJ5LgorYXNfZm5fbWtk
aXJfcCAoKQoreworCisgIGNhc2UgJGFzX2RpciBpbiAjKAorICAtKikgYXNfZGlyPS4vJGFzX2Rp
cjs7CisgIGVzYWMKKyAgdGVzdCAtZCAiJGFzX2RpciIgfHwgZXZhbCAkYXNfbWtkaXJfcCB8fCB7
CisgICAgYXNfZGlycz0KKyAgICB3aGlsZSA6OyBkbworICAgICAgY2FzZSAkYXNfZGlyIGluICMo
CisgICAgICAqXCcqKSBhc19xZGlyPWAkYXNfZWNobyAiJGFzX2RpciIgfCBzZWQgInMvJy8nXFxc
XFxcXFwnJy9nImA7OyAjJygKKyAgICAgICopIGFzX3FkaXI9JGFzX2Rpcjs7CisgICAgICBlc2Fj
CisgICAgICBhc19kaXJzPSInJGFzX3FkaXInICRhc19kaXJzIgorICAgICAgYXNfZGlyPWAkYXNf
ZGlybmFtZSAtLSAiJGFzX2RpciIgfHwKKyRhc19leHByIFgiJGFzX2RpciIgOiAnWFwoLipbXi9d
XCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpW14vXScgXHwg
XAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFzX2RpciIgOiAnWFwoL1wp
JyBcfCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhc19kaXIiIHwKKyAgICBzZWQgJy9e
WFwoLipbXi9dXClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAg
fQorCSAgL15YXChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAg
L15YXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cKS4q
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICAgICAgdGVz
dCAtZCAiJGFzX2RpciIgJiYgYnJlYWsKKyAgICBkb25lCisgICAgdGVzdCAteiAiJGFzX2RpcnMi
IHx8IGV2YWwgIm1rZGlyICRhc19kaXJzIgorICB9IHx8IHRlc3QgLWQgIiRhc19kaXIiIHx8IGFz
X2ZuX2Vycm9yICQ/ICJjYW5ub3QgY3JlYXRlIGRpcmVjdG9yeSAkYXNfZGlyIgorCisKK30gIyBh
c19mbl9ta2Rpcl9wCisjIGFzX2ZuX2FwcGVuZCBWQVIgVkFMVUUKKyMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorIyBBcHBlbmQgdGhlIHRleHQgaW4gVkFMVUUgdG8gdGhlIGVuZCBvZiB0aGUgZGVm
aW5pdGlvbiBjb250YWluZWQgaW4gVkFSLiBUYWtlCisjIGFkdmFudGFnZSBvZiBhbnkgc2hlbGwg
b3B0aW1pemF0aW9ucyB0aGF0IGFsbG93IGFtb3J0aXplZCBsaW5lYXIgZ3Jvd3RoIG92ZXIKKyMg
cmVwZWF0ZWQgYXBwZW5kcywgaW5zdGVhZCBvZiB0aGUgdHlwaWNhbCBxdWFkcmF0aWMgZ3Jvd3Ro
IHByZXNlbnQgaW4gbmFpdmUKKyMgaW1wbGVtZW50YXRpb25zLgoraWYgKGV2YWwgImFzX3Zhcj0x
OyBhc192YXIrPTI7IHRlc3QgeFwkYXNfdmFyID0geDEyIikgMj4vZGV2L251bGw7IHRoZW4gOgor
ICBldmFsICdhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDErPVwkMgorICB9JworZWxz
ZQorICBhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDE9XCQkMVwkMgorICB9CitmaSAj
IGFzX2ZuX2FwcGVuZAorCisjIGFzX2ZuX2FyaXRoIEFSRy4uLgorIyAtLS0tLS0tLS0tLS0tLS0t
LS0KKyMgUGVyZm9ybSBhcml0aG1ldGljIGV2YWx1YXRpb24gb24gdGhlIEFSR3MsIGFuZCBzdG9y
ZSB0aGUgcmVzdWx0IGluIHRoZQorIyBnbG9iYWwgJGFzX3ZhbC4gVGFrZSBhZHZhbnRhZ2Ugb2Yg
c2hlbGxzIHRoYXQgY2FuIGF2b2lkIGZvcmtzLiBUaGUgYXJndW1lbnRzCisjIG11c3QgYmUgcG9y
dGFibGUgYWNyb3NzICQoKCkpIGFuZCBleHByLgoraWYgKGV2YWwgInRlc3QgXCQoKCAxICsgMSAp
KSA9IDIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2FyaXRoICgpCisgIHsK
KyAgICBhc192YWw9JCgoICQqICkpCisgIH0nCitlbHNlCisgIGFzX2ZuX2FyaXRoICgpCisgIHsK
KyAgICBhc192YWw9YGV4cHIgIiRAIiB8fCB0ZXN0ICQ/IC1lcSAxYAorICB9CitmaSAjIGFzX2Zu
X2FyaXRoCisKKworIyBhc19mbl9lcnJvciBTVEFUVVMgRVJST1IgW0xJTkVOTyBMT0dfRkRdCisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgT3V0cHV0ICJgYmFz
ZW5hbWUgJDBgOiBlcnJvcjogRVJST1IiIHRvIHN0ZGVyci4gSWYgTElORU5PIGFuZCBMT0dfRkQg
YXJlCisjIHByb3ZpZGVkLCBhbHNvIG91dHB1dCB0aGUgZXJyb3IgdG8gTE9HX0ZELCByZWZlcmVu
Y2luZyBMSU5FTk8uIFRoZW4gZXhpdCB0aGUKKyMgc2NyaXB0IHdpdGggU1RBVFVTLCB1c2luZyAx
IGlmIHRoYXQgd2FzIDAuCithc19mbl9lcnJvciAoKQoreworICBhc19zdGF0dXM9JDE7IHRlc3Qg
JGFzX3N0YXR1cyAtZXEgMCAmJiBhc19zdGF0dXM9MQorICBpZiB0ZXN0ICIkNCI7IHRoZW4KKyAg
ICBhc19saW5lbm89JHthc19saW5lbm8tIiQzIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19z
dGFjaz0kYXNfbGluZW5vX3N0YWNrCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6ICQyIiA+JiQ0CisgIGZpCisgICRhc19lY2hvICIkYXNfbWU6IGVycm9y
OiAkMiIgPiYyCisgIGFzX2ZuX2V4aXQgJGFzX3N0YXR1cworfSAjIGFzX2ZuX2Vycm9yCisKK2lm
IGV4cHIgYSA6ICdcKGFcKScgPi9kZXYvbnVsbCAyPiYxICYmCisgICB0ZXN0ICJYYGV4cHIgMDAw
MDEgOiAnLipcKC4uLlwpJ2AiID0gWDAwMTsgdGhlbgorICBhc19leHByPWV4cHIKK2Vsc2UKKyAg
YXNfZXhwcj1mYWxzZQorZmkKKworaWYgKGJhc2VuYW1lIC0tIC8pID4vZGV2L251bGwgMj4mMSAm
JiB0ZXN0ICJYYGJhc2VuYW1lIC0tIC8gMj4mMWAiID0gIlgvIjsgdGhlbgorICBhc19iYXNlbmFt
ZT1iYXNlbmFtZQorZWxzZQorICBhc19iYXNlbmFtZT1mYWxzZQorZmkKKworaWYgKGFzX2Rpcj1g
ZGlybmFtZSAtLSAvYCAmJiB0ZXN0ICJYJGFzX2RpciIgPSBYLykgPi9kZXYvbnVsbCAyPiYxOyB0
aGVuCisgIGFzX2Rpcm5hbWU9ZGlybmFtZQorZWxzZQorICBhc19kaXJuYW1lPWZhbHNlCitmaQor
Cithc19tZT1gJGFzX2Jhc2VuYW1lIC0tICIkMCIgfHwKKyRhc19leHByIFgvIiQwIiA6ICcuKi9c
KFteL11bXi9dKlwpLyokJyBcfCBcCisJIFgiJDAiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJDAi
IDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWC8iJDAiIHwKKyAgICBz
ZWQgJy9eLipcL1woW14vXVteL10qXClcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0K
KwkgIC9eWFwvXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwv
XChcL1wpLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisK
KyMgQXZvaWQgZGVwZW5kaW5nIHVwb24gQ2hhcmFjdGVyIFJhbmdlcy4KK2FzX2NyX2xldHRlcnM9
J2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6JworYXNfY3JfTEVUVEVSUz0nQUJDREVGR0hJSktM
TU5PUFFSU1RVVldYWVonCithc19jcl9MZXR0ZXJzPSRhc19jcl9sZXR0ZXJzJGFzX2NyX0xFVFRF
UlMKK2FzX2NyX2RpZ2l0cz0nMDEyMzQ1Njc4OScKK2FzX2NyX2FsbnVtPSRhc19jcl9MZXR0ZXJz
JGFzX2NyX2RpZ2l0cworCisKKyAgYXNfbGluZW5vXzE9JExJTkVOTyBhc19saW5lbm9fMWE9JExJ
TkVOTworICBhc19saW5lbm9fMj0kTElORU5PIGFzX2xpbmVub18yYT0kTElORU5PCisgIGV2YWwg
J3Rlc3QgIngkYXNfbGluZW5vXzEnJGFzX3J1biciICE9ICJ4JGFzX2xpbmVub18yJyRhc19ydW4n
IiAmJgorICB0ZXN0ICJ4YGV4cHIgJGFzX2xpbmVub18xJyRhc19ydW4nICsgMWAiID0gIngkYXNf
bGluZW5vXzInJGFzX3J1biciJyB8fCB7CisgICMgQmxhbWUgTGVlIEUuIE1jTWFob24gKDE5MzEt
MTk4OSkgZm9yIHNlZCdzIHN5bnRheC4gIDotKQorICBzZWQgLW4gJworICAgIHAKKyAgICAvWyRd
TElORU5PLz0KKyAgJyA8JGFzX215c2VsZiB8CisgICAgc2VkICcKKyAgICAgIHMvWyRdTElORU5P
LiovJi0vCisgICAgICB0IGxpbmVubworICAgICAgYgorICAgICAgOmxpbmVubworICAgICAgTgor
ICAgICAgOmxvb3AKKyAgICAgIHMvWyRdTElORU5PXChbXickYXNfY3JfYWxudW0nX10uKlxuXClc
KC4qXCkvXDJcMVwyLworICAgICAgdCBsb29wCisgICAgICBzLy1cbi4qLy8KKyAgICAnID4kYXNf
bWUubGluZW5vICYmCisgIGNobW9kICt4ICIkYXNfbWUubGluZW5vIiB8fAorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZTogZXJyb3I6IGNhbm5vdCBjcmVhdGUgJGFzX21lLmxpbmVubzsgcmVydW4gd2l0
aCBhIFBPU0lYIHNoZWxsIiA+JjI7IGFzX2ZuX2V4aXQgMTsgfQorCisgICMgRG9uJ3QgdHJ5IHRv
IGV4ZWMgYXMgaXQgY2hhbmdlcyAkWzBdLCBjYXVzaW5nIGFsbCBzb3J0IG9mIHByb2JsZW1zCisg
ICMgKHRoZSBkaXJuYW1lIG9mICRbMF0gaXMgbm90IHRoZSBwbGFjZSB3aGVyZSB3ZSBtaWdodCBm
aW5kIHRoZQorICAjIG9yaWdpbmFsIGFuZCBzbyBvbi4gIEF1dG9jb25mIGlzIGVzcGVjaWFsbHkg
c2Vuc2l0aXZlIHRvIHRoaXMpLgorICAuICIuLyRhc19tZS5saW5lbm8iCisgICMgRXhpdCBzdGF0
dXMgaXMgdGhhdCBvZiB0aGUgbGFzdCBjb21tYW5kLgorICBleGl0Cit9CisKK0VDSE9fQz0gRUNI
T19OPSBFQ0hPX1Q9CitjYXNlIGBlY2hvIC1uIHhgIGluICMoKCgoKAorLW4qKQorICBjYXNlIGBl
Y2hvICd4eVxjJ2AgaW4KKyAgKmMqKSBFQ0hPX1Q9JwknOzsJIyBFQ0hPX1QgaXMgc2luZ2xlIHRh
YiBjaGFyYWN0ZXIuCisgIHh5KSAgRUNIT19DPSdcYyc7OworICAqKSAgIGVjaG8gYGVjaG8ga3No
ODggYnVnIG9uIEFJWCA2LjFgID4gL2Rldi9udWxsCisgICAgICAgRUNIT19UPScJJzs7CisgIGVz
YWM7OworKikKKyAgRUNIT19OPSctbic7OworZXNhYworCitybSAtZiBjb25mJCQgY29uZiQkLmV4
ZSBjb25mJCQuZmlsZQoraWYgdGVzdCAtZCBjb25mJCQuZGlyOyB0aGVuCisgIHJtIC1mIGNvbmYk
JC5kaXIvY29uZiQkLmZpbGUKK2Vsc2UKKyAgcm0gLWYgY29uZiQkLmRpcgorICBta2RpciBjb25m
JCQuZGlyIDI+L2Rldi9udWxsCitmaQoraWYgKGVjaG8gPmNvbmYkJC5maWxlKSAyPi9kZXYvbnVs
bDsgdGhlbgorICBpZiBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4K
KyAgICBhc19sbl9zPSdsbiAtcycKKyAgICAjIC4uLiBidXQgdGhlcmUgYXJlIHR3byBnb3RjaGFz
OgorICAgICMgMSkgT24gTVNZUywgYm90aCBgbG4gLXMgZmlsZSBkaXInIGFuZCBgbG4gZmlsZSBk
aXInIGZhaWwuCisgICAgIyAyKSBESkdQUCA8IDIuMDQgaGFzIG5vIHN5bWxpbmtzOyBgbG4gLXMn
IGNyZWF0ZXMgYSB3cmFwcGVyIGV4ZWN1dGFibGUuCisgICAgIyBJbiBib3RoIGNhc2VzLCB3ZSBo
YXZlIHRvIGRlZmF1bHQgdG8gYGNwIC1wJy4KKyAgICBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQu
ZGlyIDI+L2Rldi9udWxsICYmIHRlc3QgISAtZiBjb25mJCQuZXhlIHx8CisgICAgICBhc19sbl9z
PSdjcCAtcCcKKyAgZWxpZiBsbiBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4K
KyAgICBhc19sbl9zPWxuCisgIGVsc2UKKyAgICBhc19sbl9zPSdjcCAtcCcKKyAgZmkKK2Vsc2UK
KyAgYXNfbG5fcz0nY3AgLXAnCitmaQorcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmRp
ci9jb25mJCQuZmlsZSBjb25mJCQuZmlsZQorcm1kaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAor
CitpZiBta2RpciAtcCAuIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX21rZGlyX3A9J21rZGlyIC1w
ICIkYXNfZGlyIicKK2Vsc2UKKyAgdGVzdCAtZCAuLy1wICYmIHJtZGlyIC4vLXAKKyAgYXNfbWtk
aXJfcD1mYWxzZQorZmkKKworaWYgdGVzdCAteCAvID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBh
c190ZXN0X3g9J3Rlc3QgLXgnCitlbHNlCisgIGlmIGxzIC1kTCAvID4vZGV2L251bGwgMj4mMTsg
dGhlbgorICAgIGFzX2xzX0xfb3B0aW9uPUwKKyAgZWxzZQorICAgIGFzX2xzX0xfb3B0aW9uPQor
ICBmaQorICBhc190ZXN0X3g9JworICAgIGV2YWwgc2ggLWMgJ1wnJworICAgICAgaWYgdGVzdCAt
ZCAiJDEiOyB0aGVuCisJdGVzdCAtZCAiJDEvLiI7CisgICAgICBlbHNlCisJY2FzZSAkMSBpbiAj
KAorCS0qKXNldCAiLi8kMSI7OworCWVzYWM7CisJY2FzZSBgbHMgLWxkJyRhc19sc19MX29wdGlv
bicgIiQxIiAyPi9kZXYvbnVsbGAgaW4gIygoCisJPz8/W3N4XSopOjs7KilmYWxzZTs7ZXNhYztm
aQorICAgICdcJycgc2gKKyAgJworZmkKK2FzX2V4ZWN1dGFibGVfcD0kYXNfdGVzdF94CisKKyMg
U2VkIGV4cHJlc3Npb24gdG8gbWFwIGEgc3RyaW5nIG9udG8gYSB2YWxpZCBDUFAgbmFtZS4KK2Fz
X3RyX2NwcD0iZXZhbCBzZWQgJ3klKiRhc19jcl9sZXR0ZXJzJVAkYXNfY3JfTEVUVEVSUyU7cyVb
Xl8kYXNfY3JfYWxudW1dJV8lZyciCisKKyMgU2VkIGV4cHJlc3Npb24gdG8gbWFwIGEgc3RyaW5n
IG9udG8gYSB2YWxpZCB2YXJpYWJsZSBuYW1lLgorYXNfdHJfc2g9ImV2YWwgc2VkICd5JSorJXBw
JTtzJVteXyRhc19jcl9hbG51bV0lXyVnJyIKKworCit0ZXN0IC1uICIkREpESVIiIHx8IGV4ZWMg
NzwmMCA8L2Rldi9udWxsCitleGVjIDY+JjEKKworIyBOYW1lIG9mIHRoZSBob3N0LgorIyBob3N0
bmFtZSBvbiBzb21lIHN5c3RlbXMgKFNWUjMuMiwgb2xkIEdOVS9MaW51eCkgcmV0dXJucyBhIGJv
Z3VzIGV4aXQgc3RhdHVzLAorIyBzbyB1bmFtZSBnZXRzIHJ1biB0b28uCithY19ob3N0bmFtZT1g
KGhvc3RuYW1lIHx8IHVuYW1lIC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKKworIworIyBJbml0
aWFsaXphdGlvbnMuCisjCithY19kZWZhdWx0X3ByZWZpeD0vdXNyL2xvY2FsCithY19jbGVhbl9m
aWxlcz0KK2FjX2NvbmZpZ19saWJvYmpfZGlyPS4KK0xJQk9CSlM9Citjcm9zc19jb21waWxpbmc9
bm8KK3N1YmRpcnM9CitNRkxBR1M9CitNQUtFRkxBR1M9CisKKyMgSWRlbnRpdHkgb2YgdGhpcyBw
YWNrYWdlLgorUEFDS0FHRV9OQU1FPQorUEFDS0FHRV9UQVJOQU1FPQorUEFDS0FHRV9WRVJTSU9O
PQorUEFDS0FHRV9TVFJJTkc9CitQQUNLQUdFX0JVR1JFUE9SVD0KK1BBQ0tBR0VfVVJMPQorCith
Y191bmlxdWVfZmlsZT0iWGVuIEh5cGVydmlzb3IiCithY191bmlxdWVfZmlsZT0ibGlieGwvbGli
eGwuYyIKK2FjX2RlZmF1bHRfcHJlZml4PS91c3IKKyMgRmFjdG9yaW5nIGRlZmF1bHQgaGVhZGVy
cyBmb3IgbW9zdCB0ZXN0cy4KK2FjX2luY2x1ZGVzX2RlZmF1bHQ9IlwKKyNpbmNsdWRlIDxzdGRp
by5oPgorI2lmZGVmIEhBVkVfU1lTX1RZUEVTX0gKKyMgaW5jbHVkZSA8c3lzL3R5cGVzLmg+Cisj
ZW5kaWYKKyNpZmRlZiBIQVZFX1NZU19TVEFUX0gKKyMgaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNl
bmRpZgorI2lmZGVmIFNURENfSEVBREVSUworIyBpbmNsdWRlIDxzdGRsaWIuaD4KKyMgaW5jbHVk
ZSA8c3RkZGVmLmg+CisjZWxzZQorIyBpZmRlZiBIQVZFX1NURExJQl9ICisjICBpbmNsdWRlIDxz
dGRsaWIuaD4KKyMgZW5kaWYKKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RSSU5HX0gKKyMgaWYgIWRl
ZmluZWQgU1REQ19IRUFERVJTICYmIGRlZmluZWQgSEFWRV9NRU1PUllfSAorIyAgaW5jbHVkZSA8
bWVtb3J5Lmg+CisjIGVuZGlmCisjIGluY2x1ZGUgPHN0cmluZy5oPgorI2VuZGlmCisjaWZkZWYg
SEFWRV9TVFJJTkdTX0gKKyMgaW5jbHVkZSA8c3RyaW5ncy5oPgorI2VuZGlmCisjaWZkZWYgSEFW
RV9JTlRUWVBFU19ICisjIGluY2x1ZGUgPGludHR5cGVzLmg+CisjZW5kaWYKKyNpZmRlZiBIQVZF
X1NURElOVF9ICisjIGluY2x1ZGUgPHN0ZGludC5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9VTklT
VERfSAorIyBpbmNsdWRlIDx1bmlzdGQuaD4KKyNlbmRpZiIKKworYWNfaGVhZGVyX2xpc3Q9Cith
Y19mdW5jX2xpc3Q9CithY19zdWJzdF92YXJzPSdMVExJQk9CSlMKK1BPV19MSUIKK0xJQk9CSlMK
K0FMTE9DQQorbGliaWNvbnYKK2xpYmdjcnlwdAorbGliZXh0MmZzCitzeXN0ZW1fYWlvCitMSUJf
UEFUSAorVk5DT05GSUcKK0hPVFBMVUcKK1VERVZJTkZPCitVREVWQURNCitQWVRIT05QQVRICitP
Q0FNTEJVSUxECitPQ0FNTERPQworT0NBTUxNS0xJQgorT0NBTUxNS1RPUAorT0NBTUxERVAKK09D
QU1MCitPQ0FNTE9QVERPVE9QVAorT0NBTUxDRE9UT1BUCitPQ0FNTEJFU1QKK09DQU1MT1BUCitP
Q0FNTExJQgorT0NBTUxWRVJTSU9OCitPQ0FNTEMKK0lOU1RBTExfREFUQQorSU5TVEFMTF9TQ1JJ
UFQKK0lOU1RBTExfUFJPR1JBTQorU0VUX01BS0UKK0xOX1MKK1NFRAorWEdFVFRFWFQKK0JBU0gK
K1hNTAorQ1VSTAorRkxFWAorQklTT04KK0lQCitCUkNUTAorUEVSTAorUFlUSE9OCitBUFBFTkRf
TElCCitBUFBFTkRfSU5DTFVERVMKK1BSRVBFTkRfTElCCitQUkVQRU5EX0lOQ0xVREVTCitkZWJ1
ZworbG9tb3VudAorbWluaXRlcm0KK29jYW1sdG9vbHMKK3B5dGhvbnRvb2xzCit4YXBpCit2dHBt
Cittb25pdG9ycworZ2l0aHR0cAoreHNtCitob3N0X29zCitob3N0X3ZlbmRvcgoraG9zdF9jcHUK
K2hvc3QKK2J1aWxkX29zCitidWlsZF92ZW5kb3IKK2J1aWxkX2NwdQorYnVpbGQKK0VHUkVQCitH
UkVQCitDUFAKK09CSkVYVAorRVhFRVhUCithY19jdF9DQworQ1BQRkxBR1MKK0xERkxBR1MKK0NG
TEFHUworQ0MKK3RhcmdldF9hbGlhcworaG9zdF9hbGlhcworYnVpbGRfYWxpYXMKK0xJQlMKK0VD
SE9fVAorRUNIT19OCitFQ0hPX0MKK0RFRlMKK21hbmRpcgorbG9jYWxlZGlyCitsaWJkaXIKK3Bz
ZGlyCitwZGZkaXIKK2R2aWRpcgoraHRtbGRpcgoraW5mb2RpcgorZG9jZGlyCitvbGRpbmNsdWRl
ZGlyCitpbmNsdWRlZGlyCitsb2NhbHN0YXRlZGlyCitzaGFyZWRzdGF0ZWRpcgorc3lzY29uZmRp
cgorZGF0YWRpcgorZGF0YXJvb3RkaXIKK2xpYmV4ZWNkaXIKK3NiaW5kaXIKK2JpbmRpcgorcHJv
Z3JhbV90cmFuc2Zvcm1fbmFtZQorcHJlZml4CitleGVjX3ByZWZpeAorUEFDS0FHRV9VUkwKK1BB
Q0tBR0VfQlVHUkVQT1JUCitQQUNLQUdFX1NUUklORworUEFDS0FHRV9WRVJTSU9OCitQQUNLQUdF
X1RBUk5BTUUKK1BBQ0tBR0VfTkFNRQorUEFUSF9TRVBBUkFUT1IKK1NIRUxMJworYWNfc3Vic3Rf
ZmlsZXM9JycKK2FjX3VzZXJfb3B0cz0nCitlbmFibGVfb3B0aW9uX2NoZWNraW5nCitlbmFibGVf
eHNtCitlbmFibGVfZ2l0aHR0cAorZW5hYmxlX21vbml0b3JzCitlbmFibGVfdnRwbQorZW5hYmxl
X3hhcGkKK2VuYWJsZV9weXRob250b29scworZW5hYmxlX29jYW1sdG9vbHMKK2VuYWJsZV9taW5p
dGVybQorZW5hYmxlX2xvbW91bnQKK2VuYWJsZV9kZWJ1ZworJworICAgICAgYWNfcHJlY2lvdXNf
dmFycz0nYnVpbGRfYWxpYXMKK2hvc3RfYWxpYXMKK3RhcmdldF9hbGlhcworQ0MKK0NGTEFHUwor
TERGTEFHUworTElCUworQ1BQRkxBR1MKK0NQUAorUFJFUEVORF9JTkNMVURFUworUFJFUEVORF9M
SUIKK0FQUEVORF9JTkNMVURFUworQVBQRU5EX0xJQgorUFlUSE9OCitQRVJMCitCUkNUTAorSVAK
K0JJU09OCitGTEVYCitDVVJMCitYTUwKK0JBU0gKK1hHRVRURVhUJworCisKKyMgSW5pdGlhbGl6
ZSBzb21lIHZhcmlhYmxlcyBzZXQgYnkgb3B0aW9ucy4KK2FjX2luaXRfaGVscD0KK2FjX2luaXRf
dmVyc2lvbj1mYWxzZQorYWNfdW5yZWNvZ25pemVkX29wdHM9CithY191bnJlY29nbml6ZWRfc2Vw
PQorIyBUaGUgdmFyaWFibGVzIGhhdmUgdGhlIHNhbWUgbmFtZXMgYXMgdGhlIG9wdGlvbnMsIHdp
dGgKKyMgZGFzaGVzIGNoYW5nZWQgdG8gdW5kZXJsaW5lcy4KK2NhY2hlX2ZpbGU9L2Rldi9udWxs
CitleGVjX3ByZWZpeD1OT05FCitub19jcmVhdGU9Citub19yZWN1cnNpb249CitwcmVmaXg9Tk9O
RQorcHJvZ3JhbV9wcmVmaXg9Tk9ORQorcHJvZ3JhbV9zdWZmaXg9Tk9ORQorcHJvZ3JhbV90cmFu
c2Zvcm1fbmFtZT1zLHgseCwKK3NpbGVudD0KK3NpdGU9CitzcmNkaXI9Cit2ZXJib3NlPQoreF9p
bmNsdWRlcz1OT05FCit4X2xpYnJhcmllcz1OT05FCisKKyMgSW5zdGFsbGF0aW9uIGRpcmVjdG9y
eSBvcHRpb25zLgorIyBUaGVzZSBhcmUgbGVmdCB1bmV4cGFuZGVkIHNvIHVzZXJzIGNhbiAibWFr
ZSBpbnN0YWxsIGV4ZWNfcHJlZml4PS9mb28iCisjIGFuZCBhbGwgdGhlIHZhcmlhYmxlcyB0aGF0
IGFyZSBzdXBwb3NlZCB0byBiZSBiYXNlZCBvbiBleGVjX3ByZWZpeAorIyBieSBkZWZhdWx0IHdp
bGwgYWN0dWFsbHkgY2hhbmdlLgorIyBVc2UgYnJhY2VzIGluc3RlYWQgb2YgcGFyZW5zIGJlY2F1
c2Ugc2gsIHBlcmwsIGV0Yy4gYWxzbyBhY2NlcHQgdGhlbS4KKyMgKFRoZSBsaXN0IGZvbGxvd3Mg
dGhlIHNhbWUgb3JkZXIgYXMgdGhlIEdOVSBDb2RpbmcgU3RhbmRhcmRzLikKK2JpbmRpcj0nJHtl
eGVjX3ByZWZpeH0vYmluJworc2JpbmRpcj0nJHtleGVjX3ByZWZpeH0vc2JpbicKK2xpYmV4ZWNk
aXI9JyR7ZXhlY19wcmVmaXh9L2xpYmV4ZWMnCitkYXRhcm9vdGRpcj0nJHtwcmVmaXh9L3NoYXJl
JworZGF0YWRpcj0nJHtkYXRhcm9vdGRpcn0nCitzeXNjb25mZGlyPScke3ByZWZpeH0vZXRjJwor
c2hhcmVkc3RhdGVkaXI9JyR7cHJlZml4fS9jb20nCitsb2NhbHN0YXRlZGlyPScke3ByZWZpeH0v
dmFyJworaW5jbHVkZWRpcj0nJHtwcmVmaXh9L2luY2x1ZGUnCitvbGRpbmNsdWRlZGlyPScvdXNy
L2luY2x1ZGUnCitkb2NkaXI9JyR7ZGF0YXJvb3RkaXJ9L2RvYy8ke1BBQ0tBR0V9JworaW5mb2Rp
cj0nJHtkYXRhcm9vdGRpcn0vaW5mbycKK2h0bWxkaXI9JyR7ZG9jZGlyfScKK2R2aWRpcj0nJHtk
b2NkaXJ9JworcGRmZGlyPScke2RvY2Rpcn0nCitwc2Rpcj0nJHtkb2NkaXJ9JworbGliZGlyPSck
e2V4ZWNfcHJlZml4fS9saWInCitsb2NhbGVkaXI9JyR7ZGF0YXJvb3RkaXJ9L2xvY2FsZScKK21h
bmRpcj0nJHtkYXRhcm9vdGRpcn0vbWFuJworCithY19wcmV2PQorYWNfZGFzaGRhc2g9Citmb3Ig
YWNfb3B0aW9uCitkbworICAjIElmIHRoZSBwcmV2aW91cyBvcHRpb24gbmVlZHMgYW4gYXJndW1l
bnQsIGFzc2lnbiBpdC4KKyAgaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgICAgZXZhbCAk
YWNfcHJldj1cJGFjX29wdGlvbgorICAgIGFjX3ByZXY9CisgICAgY29udGludWUKKyAgZmkKKwor
ICBjYXNlICRhY19vcHRpb24gaW4KKyAgKj0/KikgYWNfb3B0YXJnPWBleHByICJYJGFjX29wdGlv
biIgOiAnW149XSo9XCguKlwpJ2AgOzsKKyAgKj0pICAgYWNfb3B0YXJnPSA7OworICAqKSAgICBh
Y19vcHRhcmc9eWVzIDs7CisgIGVzYWMKKworICAjIEFjY2VwdCB0aGUgaW1wb3J0YW50IEN5Z251
cyBjb25maWd1cmUgb3B0aW9ucywgc28gd2UgY2FuIGRpYWdub3NlIHR5cG9zLgorCisgIGNhc2Ug
JGFjX2Rhc2hkYXNoJGFjX29wdGlvbiBpbgorICAtLSkKKyAgICBhY19kYXNoZGFzaD15ZXMgOzsK
KworICAtYmluZGlyIHwgLS1iaW5kaXIgfCAtLWJpbmRpIHwgLS1iaW5kIHwgLS1iaW4gfCAtLWJp
KQorICAgIGFjX3ByZXY9YmluZGlyIDs7CisgIC1iaW5kaXI9KiB8IC0tYmluZGlyPSogfCAtLWJp
bmRpPSogfCAtLWJpbmQ9KiB8IC0tYmluPSogfCAtLWJpPSopCisgICAgYmluZGlyPSRhY19vcHRh
cmcgOzsKKworICAtYnVpbGQgfCAtLWJ1aWxkIHwgLS1idWlsIHwgLS1idWkgfCAtLWJ1KQorICAg
IGFjX3ByZXY9YnVpbGRfYWxpYXMgOzsKKyAgLWJ1aWxkPSogfCAtLWJ1aWxkPSogfCAtLWJ1aWw9
KiB8IC0tYnVpPSogfCAtLWJ1PSopCisgICAgYnVpbGRfYWxpYXM9JGFjX29wdGFyZyA7OworCisg
IC1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWwgfCAtLWNhY2hlLWZpIFwK
KyAgfCAtLWNhY2hlLWYgfCAtLWNhY2hlLSB8IC0tY2FjaGUgfCAtLWNhY2ggfCAtLWNhYyB8IC0t
Y2EgfCAtLWMpCisgICAgYWNfcHJldj1jYWNoZV9maWxlIDs7CisgIC1jYWNoZS1maWxlPSogfCAt
LWNhY2hlLWZpbGU9KiB8IC0tY2FjaGUtZmlsPSogfCAtLWNhY2hlLWZpPSogXAorICB8IC0tY2Fj
aGUtZj0qIHwgLS1jYWNoZS09KiB8IC0tY2FjaGU9KiB8IC0tY2FjaD0qIHwgLS1jYWM9KiB8IC0t
Y2E9KiB8IC0tYz0qKQorICAgIGNhY2hlX2ZpbGU9JGFjX29wdGFyZyA7OworCisgIC0tY29uZmln
LWNhY2hlIHwgLUMpCisgICAgY2FjaGVfZmlsZT1jb25maWcuY2FjaGUgOzsKKworICAtZGF0YWRp
ciB8IC0tZGF0YWRpciB8IC0tZGF0YWRpIHwgLS1kYXRhZCkKKyAgICBhY19wcmV2PWRhdGFkaXIg
OzsKKyAgLWRhdGFkaXI9KiB8IC0tZGF0YWRpcj0qIHwgLS1kYXRhZGk9KiB8IC0tZGF0YWQ9KikK
KyAgICBkYXRhZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGF0YXJvb3RkaXIgfCAtLWRhdGFyb290
ZGlyIHwgLS1kYXRhcm9vdGRpIHwgLS1kYXRhcm9vdGQgfCAtLWRhdGFyb290IFwKKyAgfCAtLWRh
dGFyb28gfCAtLWRhdGFybyB8IC0tZGF0YXIpCisgICAgYWNfcHJldj1kYXRhcm9vdGRpciA7Owor
ICAtZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaT0qIHwgLS1k
YXRhcm9vdGQ9KiBcCisgIHwgLS1kYXRhcm9vdD0qIHwgLS1kYXRhcm9vPSogfCAtLWRhdGFybz0q
IHwgLS1kYXRhcj0qKQorICAgIGRhdGFyb290ZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGlzYWJs
ZS0qIHwgLS1kaXNhYmxlLSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19vcHRpb24iIDog
J3gtKmRpc2FibGUtXCguKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFs
aWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlte
LSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJp
bnZhbGlkIGZlYXR1cmUgbmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRh
Y191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAn
cy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFi
bGVfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIk
YWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZGlzYWJsZS0kYWNfdXNl
cm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVzYWMKKyAgICBl
dmFsIGVuYWJsZV8kYWNfdXNlcm9wdD1ubyA7OworCisgIC1kb2NkaXIgfCAtLWRvY2RpciB8IC0t
ZG9jZGkgfCAtLWRvYyB8IC0tZG8pCisgICAgYWNfcHJldj1kb2NkaXIgOzsKKyAgLWRvY2Rpcj0q
IHwgLS1kb2NkaXI9KiB8IC0tZG9jZGk9KiB8IC0tZG9jPSogfCAtLWRvPSopCisgICAgZG9jZGly
PSRhY19vcHRhcmcgOzsKKworICAtZHZpZGlyIHwgLS1kdmlkaXIgfCAtLWR2aWRpIHwgLS1kdmlk
IHwgLS1kdmkgfCAtLWR2KQorICAgIGFjX3ByZXY9ZHZpZGlyIDs7CisgIC1kdmlkaXI9KiB8IC0t
ZHZpZGlyPSogfCAtLWR2aWRpPSogfCAtLWR2aWQ9KiB8IC0tZHZpPSogfCAtLWR2PSopCisgICAg
ZHZpZGlyPSRhY19vcHRhcmcgOzsKKworICAtZW5hYmxlLSogfCAtLWVuYWJsZS0qKQorICAgIGFj
X3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSplbmFibGUtXChbXj1dKlwpJ2AKKyAg
ICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMu
CisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2
L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUgbmFtZTogJGFj
X3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9w
dD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2Ug
JGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQiCisiKikgOzsK
KyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVkX29wdHMkYWNf
dW5yZWNvZ25pemVkX3NlcC0tZW5hYmxlLSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2du
aXplZF9zZXA9JywgJzs7CisgICAgZXNhYworICAgIGV2YWwgZW5hYmxlXyRhY191c2Vyb3B0PVwk
YWNfb3B0YXJnIDs7CisKKyAgLWV4ZWMtcHJlZml4IHwgLS1leGVjX3ByZWZpeCB8IC0tZXhlYy1w
cmVmaXggfCAtLWV4ZWMtcHJlZmkgXAorICB8IC0tZXhlYy1wcmVmIHwgLS1leGVjLXByZSB8IC0t
ZXhlYy1wciB8IC0tZXhlYy1wIHwgLS1leGVjLSBcCisgIHwgLS1leGVjIHwgLS1leGUgfCAtLWV4
KQorICAgIGFjX3ByZXY9ZXhlY19wcmVmaXggOzsKKyAgLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWNf
cHJlZml4PSogfCAtLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWMtcHJlZmk9KiBcCisgIHwgLS1leGVj
LXByZWY9KiB8IC0tZXhlYy1wcmU9KiB8IC0tZXhlYy1wcj0qIHwgLS1leGVjLXA9KiB8IC0tZXhl
Yy09KiBcCisgIHwgLS1leGVjPSogfCAtLWV4ZT0qIHwgLS1leD0qKQorICAgIGV4ZWNfcHJlZml4
PSRhY19vcHRhcmcgOzsKKworICAtZ2FzIHwgLS1nYXMgfCAtLWdhIHwgLS1nKQorICAgICMgT2Jz
b2xldGU7IHVzZSAtLXdpdGgtZ2FzLgorICAgIHdpdGhfZ2FzPXllcyA7OworCisgIC1oZWxwIHwg
LS1oZWxwIHwgLS1oZWwgfCAtLWhlIHwgLWgpCisgICAgYWNfaW5pdF9oZWxwPWxvbmcgOzsKKyAg
LWhlbHA9ciogfCAtLWhlbHA9ciogfCAtLWhlbD1yKiB8IC0taGU9ciogfCAtaHIqKQorICAgIGFj
X2luaXRfaGVscD1yZWN1cnNpdmUgOzsKKyAgLWhlbHA9cyogfCAtLWhlbHA9cyogfCAtLWhlbD1z
KiB8IC0taGU9cyogfCAtaHMqKQorICAgIGFjX2luaXRfaGVscD1zaG9ydCA7OworCisgIC1ob3N0
IHwgLS1ob3N0IHwgLS1ob3MgfCAtLWhvKQorICAgIGFjX3ByZXY9aG9zdF9hbGlhcyA7OworICAt
aG9zdD0qIHwgLS1ob3N0PSogfCAtLWhvcz0qIHwgLS1obz0qKQorICAgIGhvc3RfYWxpYXM9JGFj
X29wdGFyZyA7OworCisgIC1odG1sZGlyIHwgLS1odG1sZGlyIHwgLS1odG1sZGkgfCAtLWh0bWxk
IHwgLS1odG1sIHwgLS1odG0gfCAtLWh0KQorICAgIGFjX3ByZXY9aHRtbGRpciA7OworICAtaHRt
bGRpcj0qIHwgLS1odG1sZGlyPSogfCAtLWh0bWxkaT0qIHwgLS1odG1sZD0qIHwgLS1odG1sPSog
fCAtLWh0bT0qIFwKKyAgfCAtLWh0PSopCisgICAgaHRtbGRpcj0kYWNfb3B0YXJnIDs7CisKKyAg
LWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaSB8IC0taW5jbHVkZWQgfCAt
LWluY2x1ZGUgXAorICB8IC0taW5jbHVkIHwgLS1pbmNsdSB8IC0taW5jbCB8IC0taW5jKQorICAg
IGFjX3ByZXY9aW5jbHVkZWRpciA7OworICAtaW5jbHVkZWRpcj0qIHwgLS1pbmNsdWRlZGlyPSog
fCAtLWluY2x1ZGVkaT0qIHwgLS1pbmNsdWRlZD0qIHwgLS1pbmNsdWRlPSogXAorICB8IC0taW5j
bHVkPSogfCAtLWluY2x1PSogfCAtLWluY2w9KiB8IC0taW5jPSopCisgICAgaW5jbHVkZWRpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLWluZm9kaXIgfCAtLWluZm9kaXIgfCAtLWluZm9kaSB8IC0taW5m
b2QgfCAtLWluZm8gfCAtLWluZikKKyAgICBhY19wcmV2PWluZm9kaXIgOzsKKyAgLWluZm9kaXI9
KiB8IC0taW5mb2Rpcj0qIHwgLS1pbmZvZGk9KiB8IC0taW5mb2Q9KiB8IC0taW5mbz0qIHwgLS1p
bmY9KikKKyAgICBpbmZvZGlyPSRhY19vcHRhcmcgOzsKKworICAtbGliZGlyIHwgLS1saWJkaXIg
fCAtLWxpYmRpIHwgLS1saWJkKQorICAgIGFjX3ByZXY9bGliZGlyIDs7CisgIC1saWJkaXI9KiB8
IC0tbGliZGlyPSogfCAtLWxpYmRpPSogfCAtLWxpYmQ9KikKKyAgICBsaWJkaXI9JGFjX29wdGFy
ZyA7OworCisgIC1saWJleGVjZGlyIHwgLS1saWJleGVjZGlyIHwgLS1saWJleGVjZGkgfCAtLWxp
YmV4ZWNkIHwgLS1saWJleGVjIFwKKyAgfCAtLWxpYmV4ZSB8IC0tbGliZXggfCAtLWxpYmUpCisg
ICAgYWNfcHJldj1saWJleGVjZGlyIDs7CisgIC1saWJleGVjZGlyPSogfCAtLWxpYmV4ZWNkaXI9
KiB8IC0tbGliZXhlY2RpPSogfCAtLWxpYmV4ZWNkPSogfCAtLWxpYmV4ZWM9KiBcCisgIHwgLS1s
aWJleGU9KiB8IC0tbGliZXg9KiB8IC0tbGliZT0qKQorICAgIGxpYmV4ZWNkaXI9JGFjX29wdGFy
ZyA7OworCisgIC1sb2NhbGVkaXIgfCAtLWxvY2FsZWRpciB8IC0tbG9jYWxlZGkgfCAtLWxvY2Fs
ZWQgfCAtLWxvY2FsZSkKKyAgICBhY19wcmV2PWxvY2FsZWRpciA7OworICAtbG9jYWxlZGlyPSog
fCAtLWxvY2FsZWRpcj0qIHwgLS1sb2NhbGVkaT0qIHwgLS1sb2NhbGVkPSogfCAtLWxvY2FsZT0q
KQorICAgIGxvY2FsZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWxvY2Fsc3RhdGVkaXIgfCAtLWxv
Y2Fsc3RhdGVkaXIgfCAtLWxvY2Fsc3RhdGVkaSB8IC0tbG9jYWxzdGF0ZWQgXAorICB8IC0tbG9j
YWxzdGF0ZSB8IC0tbG9jYWxzdGF0IHwgLS1sb2NhbHN0YSB8IC0tbG9jYWxzdCB8IC0tbG9jYWxz
KQorICAgIGFjX3ByZXY9bG9jYWxzdGF0ZWRpciA7OworICAtbG9jYWxzdGF0ZWRpcj0qIHwgLS1s
b2NhbHN0YXRlZGlyPSogfCAtLWxvY2Fsc3RhdGVkaT0qIHwgLS1sb2NhbHN0YXRlZD0qIFwKKyAg
fCAtLWxvY2Fsc3RhdGU9KiB8IC0tbG9jYWxzdGF0PSogfCAtLWxvY2Fsc3RhPSogfCAtLWxvY2Fs
c3Q9KiB8IC0tbG9jYWxzPSopCisgICAgbG9jYWxzdGF0ZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAg
LW1hbmRpciB8IC0tbWFuZGlyIHwgLS1tYW5kaSB8IC0tbWFuZCB8IC0tbWFuIHwgLS1tYSB8IC0t
bSkKKyAgICBhY19wcmV2PW1hbmRpciA7OworICAtbWFuZGlyPSogfCAtLW1hbmRpcj0qIHwgLS1t
YW5kaT0qIHwgLS1tYW5kPSogfCAtLW1hbj0qIHwgLS1tYT0qIHwgLS1tPSopCisgICAgbWFuZGly
PSRhY19vcHRhcmcgOzsKKworICAtbmZwIHwgLS1uZnAgfCAtLW5mKQorICAgICMgT2Jzb2xldGU7
IHVzZSAtLXdpdGhvdXQtZnAuCisgICAgd2l0aF9mcD1ubyA7OworCisgIC1uby1jcmVhdGUgfCAt
LW5vLWNyZWF0ZSB8IC0tbm8tY3JlYXQgfCAtLW5vLWNyZWEgfCAtLW5vLWNyZSBcCisgIHwgLS1u
by1jciB8IC0tbm8tYyB8IC1uKQorICAgIG5vX2NyZWF0ZT15ZXMgOzsKKworICAtbm8tcmVjdXJz
aW9uIHwgLS1uby1yZWN1cnNpb24gfCAtLW5vLXJlY3Vyc2lvIHwgLS1uby1yZWN1cnNpIFwKKyAg
fCAtLW5vLXJlY3VycyB8IC0tbm8tcmVjdXIgfCAtLW5vLXJlY3UgfCAtLW5vLXJlYyB8IC0tbm8t
cmUgfCAtLW5vLXIpCisgICAgbm9fcmVjdXJzaW9uPXllcyA7OworCisgIC1vbGRpbmNsdWRlZGly
IHwgLS1vbGRpbmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRlZGkgfCAtLW9sZGluY2x1ZGVkIFwKKyAg
fCAtLW9sZGluY2x1ZGUgfCAtLW9sZGluY2x1ZCB8IC0tb2xkaW5jbHUgfCAtLW9sZGluY2wgfCAt
LW9sZGluYyBcCisgIHwgLS1vbGRpbiB8IC0tb2xkaSB8IC0tb2xkIHwgLS1vbCB8IC0tbykKKyAg
ICBhY19wcmV2PW9sZGluY2x1ZGVkaXIgOzsKKyAgLW9sZGluY2x1ZGVkaXI9KiB8IC0tb2xkaW5j
bHVkZWRpcj0qIHwgLS1vbGRpbmNsdWRlZGk9KiB8IC0tb2xkaW5jbHVkZWQ9KiBcCisgIHwgLS1v
bGRpbmNsdWRlPSogfCAtLW9sZGluY2x1ZD0qIHwgLS1vbGRpbmNsdT0qIHwgLS1vbGRpbmNsPSog
fCAtLW9sZGluYz0qIFwKKyAgfCAtLW9sZGluPSogfCAtLW9sZGk9KiB8IC0tb2xkPSogfCAtLW9s
PSogfCAtLW89KikKKyAgICBvbGRpbmNsdWRlZGlyPSRhY19vcHRhcmcgOzsKKworICAtcHJlZml4
IHwgLS1wcmVmaXggfCAtLXByZWZpIHwgLS1wcmVmIHwgLS1wcmUgfCAtLXByIHwgLS1wKQorICAg
IGFjX3ByZXY9cHJlZml4IDs7CisgIC1wcmVmaXg9KiB8IC0tcHJlZml4PSogfCAtLXByZWZpPSog
fCAtLXByZWY9KiB8IC0tcHJlPSogfCAtLXByPSogfCAtLXA9KikKKyAgICBwcmVmaXg9JGFjX29w
dGFyZyA7OworCisgIC1wcm9ncmFtLXByZWZpeCB8IC0tcHJvZ3JhbS1wcmVmaXggfCAtLXByb2dy
YW0tcHJlZmkgfCAtLXByb2dyYW0tcHJlZiBcCisgIHwgLS1wcm9ncmFtLXByZSB8IC0tcHJvZ3Jh
bS1wciB8IC0tcHJvZ3JhbS1wKQorICAgIGFjX3ByZXY9cHJvZ3JhbV9wcmVmaXggOzsKKyAgLXBy
b2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZmk9KiBc
CisgIHwgLS1wcm9ncmFtLXByZWY9KiB8IC0tcHJvZ3JhbS1wcmU9KiB8IC0tcHJvZ3JhbS1wcj0q
IHwgLS1wcm9ncmFtLXA9KikKKyAgICBwcm9ncmFtX3ByZWZpeD0kYWNfb3B0YXJnIDs7CisKKyAg
LXByb2dyYW0tc3VmZml4IHwgLS1wcm9ncmFtLXN1ZmZpeCB8IC0tcHJvZ3JhbS1zdWZmaSB8IC0t
cHJvZ3JhbS1zdWZmIFwKKyAgfCAtLXByb2dyYW0tc3VmIHwgLS1wcm9ncmFtLXN1IHwgLS1wcm9n
cmFtLXMpCisgICAgYWNfcHJldj1wcm9ncmFtX3N1ZmZpeCA7OworICAtcHJvZ3JhbS1zdWZmaXg9
KiB8IC0tcHJvZ3JhbS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaT0qIFwKKyAgfCAtLXByb2dy
YW0tc3VmZj0qIHwgLS1wcm9ncmFtLXN1Zj0qIHwgLS1wcm9ncmFtLXN1PSogfCAtLXByb2dyYW0t
cz0qKQorICAgIHByb2dyYW1fc3VmZml4PSRhY19vcHRhcmcgOzsKKworICAtcHJvZ3JhbS10cmFu
c2Zvcm0tbmFtZSB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSBcCisgIHwgLS1wcm9ncmFtLXRy
YW5zZm9ybS1uYW0gfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hIFwKKyAgfCAtLXByb2dyYW0tdHJh
bnNmb3JtLW4gfCAtLXByb2dyYW0tdHJhbnNmb3JtLSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9y
bSB8IC0tcHJvZ3JhbS10cmFuc2ZvciBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm8gfCAtLXByb2dy
YW0tdHJhbnNmIFwKKyAgfCAtLXByb2dyYW0tdHJhbnMgfCAtLXByb2dyYW0tdHJhbiBcCisgIHwg
LS1wcm9nci10cmEgfCAtLXByb2dyYW0tdHIgfCAtLXByb2dyYW0tdCkKKyAgICBhY19wcmV2PXBy
b2dyYW1fdHJhbnNmb3JtX25hbWUgOzsKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5hbWU9KiB8IC0t
cHJvZ3JhbS10cmFuc2Zvcm0tbmFtZT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hbT0q
IHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW49
KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tPSogXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm09KiB8
IC0tcHJvZ3JhbS10cmFuc2Zvcj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmbz0qIHwgLS1wcm9n
cmFtLXRyYW5zZj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnM9KiB8IC0tcHJvZ3JhbS10cmFuPSog
XAorICB8IC0tcHJvZ3ItdHJhPSogfCAtLXByb2dyYW0tdHI9KiB8IC0tcHJvZ3JhbS10PSopCisg
ICAgcHJvZ3JhbV90cmFuc2Zvcm1fbmFtZT0kYWNfb3B0YXJnIDs7CisKKyAgLXBkZmRpciB8IC0t
cGRmZGlyIHwgLS1wZGZkaSB8IC0tcGRmZCB8IC0tcGRmIHwgLS1wZCkKKyAgICBhY19wcmV2PXBk
ZmRpciA7OworICAtcGRmZGlyPSogfCAtLXBkZmRpcj0qIHwgLS1wZGZkaT0qIHwgLS1wZGZkPSog
fCAtLXBkZj0qIHwgLS1wZD0qKQorICAgIHBkZmRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXBzZGly
IHwgLS1wc2RpciB8IC0tcHNkaSB8IC0tcHNkIHwgLS1wcykKKyAgICBhY19wcmV2PXBzZGlyIDs7
CisgIC1wc2Rpcj0qIHwgLS1wc2Rpcj0qIHwgLS1wc2RpPSogfCAtLXBzZD0qIHwgLS1wcz0qKQor
ICAgIHBzZGlyPSRhY19vcHRhcmcgOzsKKworICAtcSB8IC1xdWlldCB8IC0tcXVpZXQgfCAtLXF1
aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2ls
ZW4gfCAtLXNpbGUgfCAtLXNpbCkKKyAgICBzaWxlbnQ9eWVzIDs7CisKKyAgLXNiaW5kaXIgfCAt
LXNiaW5kaXIgfCAtLXNiaW5kaSB8IC0tc2JpbmQgfCAtLXNiaW4gfCAtLXNiaSB8IC0tc2IpCisg
ICAgYWNfcHJldj1zYmluZGlyIDs7CisgIC1zYmluZGlyPSogfCAtLXNiaW5kaXI9KiB8IC0tc2Jp
bmRpPSogfCAtLXNiaW5kPSogfCAtLXNiaW49KiBcCisgIHwgLS1zYmk9KiB8IC0tc2I9KikKKyAg
ICBzYmluZGlyPSRhY19vcHRhcmcgOzsKKworICAtc2hhcmVkc3RhdGVkaXIgfCAtLXNoYXJlZHN0
YXRlZGlyIHwgLS1zaGFyZWRzdGF0ZWRpIFwKKyAgfCAtLXNoYXJlZHN0YXRlZCB8IC0tc2hhcmVk
c3RhdGUgfCAtLXNoYXJlZHN0YXQgfCAtLXNoYXJlZHN0YSBcCisgIHwgLS1zaGFyZWRzdCB8IC0t
c2hhcmVkcyB8IC0tc2hhcmVkIHwgLS1zaGFyZSB8IC0tc2hhciBcCisgIHwgLS1zaGEgfCAtLXNo
KQorICAgIGFjX3ByZXY9c2hhcmVkc3RhdGVkaXIgOzsKKyAgLXNoYXJlZHN0YXRlZGlyPSogfCAt
LXNoYXJlZHN0YXRlZGlyPSogfCAtLXNoYXJlZHN0YXRlZGk9KiBcCisgIHwgLS1zaGFyZWRzdGF0
ZWQ9KiB8IC0tc2hhcmVkc3RhdGU9KiB8IC0tc2hhcmVkc3RhdD0qIHwgLS1zaGFyZWRzdGE9KiBc
CisgIHwgLS1zaGFyZWRzdD0qIHwgLS1zaGFyZWRzPSogfCAtLXNoYXJlZD0qIHwgLS1zaGFyZT0q
IHwgLS1zaGFyPSogXAorICB8IC0tc2hhPSogfCAtLXNoPSopCisgICAgc2hhcmVkc3RhdGVkaXI9
JGFjX29wdGFyZyA7OworCisgIC1zaXRlIHwgLS1zaXRlIHwgLS1zaXQpCisgICAgYWNfcHJldj1z
aXRlIDs7CisgIC1zaXRlPSogfCAtLXNpdGU9KiB8IC0tc2l0PSopCisgICAgc2l0ZT0kYWNfb3B0
YXJnIDs7CisKKyAgLXNyY2RpciB8IC0tc3JjZGlyIHwgLS1zcmNkaSB8IC0tc3JjZCB8IC0tc3Jj
IHwgLS1zcikKKyAgICBhY19wcmV2PXNyY2RpciA7OworICAtc3JjZGlyPSogfCAtLXNyY2Rpcj0q
IHwgLS1zcmNkaT0qIHwgLS1zcmNkPSogfCAtLXNyYz0qIHwgLS1zcj0qKQorICAgIHNyY2Rpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZk
aSB8IC0tc3lzY29uZmQgfCAtLXN5c2NvbmYgXAorICB8IC0tc3lzY29uIHwgLS1zeXNjbyB8IC0t
c3lzYyB8IC0tc3lzIHwgLS1zeSkKKyAgICBhY19wcmV2PXN5c2NvbmZkaXIgOzsKKyAgLXN5c2Nv
bmZkaXI9KiB8IC0tc3lzY29uZmRpcj0qIHwgLS1zeXNjb25mZGk9KiB8IC0tc3lzY29uZmQ9KiB8
IC0tc3lzY29uZj0qIFwKKyAgfCAtLXN5c2Nvbj0qIHwgLS1zeXNjbz0qIHwgLS1zeXNjPSogfCAt
LXN5cz0qIHwgLS1zeT0qKQorICAgIHN5c2NvbmZkaXI9JGFjX29wdGFyZyA7OworCisgIC10YXJn
ZXQgfCAtLXRhcmdldCB8IC0tdGFyZ2UgfCAtLXRhcmcgfCAtLXRhciB8IC0tdGEgfCAtLXQpCisg
ICAgYWNfcHJldj10YXJnZXRfYWxpYXMgOzsKKyAgLXRhcmdldD0qIHwgLS10YXJnZXQ9KiB8IC0t
dGFyZ2U9KiB8IC0tdGFyZz0qIHwgLS10YXI9KiB8IC0tdGE9KiB8IC0tdD0qKQorICAgIHRhcmdl
dF9hbGlhcz0kYWNfb3B0YXJnIDs7CisKKyAgLXYgfCAtdmVyYm9zZSB8IC0tdmVyYm9zZSB8IC0t
dmVyYm9zIHwgLS12ZXJibyB8IC0tdmVyYikKKyAgICB2ZXJib3NlPXllcyA7OworCisgIC12ZXJz
aW9uIHwgLS12ZXJzaW9uIHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwgLVYpCisgICAg
YWNfaW5pdF92ZXJzaW9uPTogOzsKKworICAtd2l0aC0qIHwgLS13aXRoLSopCisgICAgYWNfdXNl
cm9wdD1gZXhwciAieCRhY19vcHRpb24iIDogJ3gtKndpdGgtXChbXj1dKlwpJ2AKKyAgICAjIFJl
amVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAg
ZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwg
JiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHBhY2thZ2UgbmFtZTogJGFjX3VzZXJv
cHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFz
X2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3Vz
ZXJfb3B0cyBpbgorICAgICAgKiIKKyJ3aXRoXyRhY191c2Vyb3B0IgorIiopIDs7CisgICAgICAq
KSBhY191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFjX3VucmVjb2du
aXplZF9zZXAtLXdpdGgtJGFjX3VzZXJvcHRfb3JpZyIKKwkgYWNfdW5yZWNvZ25pemVkX3NlcD0n
LCAnOzsKKyAgICBlc2FjCisgICAgZXZhbCB3aXRoXyRhY191c2Vyb3B0PVwkYWNfb3B0YXJnIDs7
CisKKyAgLXdpdGhvdXQtKiB8IC0td2l0aG91dC0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngk
YWNfb3B0aW9uIiA6ICd4LSp3aXRob3V0LVwoLipcKSdgCisgICAgIyBSZWplY3QgbmFtZXMgdGhh
dCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNfdXNl
cm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBhc19m
bl9lcnJvciAkPyAiaW52YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFjX3Vz
ZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNfdXNl
cm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4KKyAg
ICAgICoiCisid2l0aF8kYWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNfdW5yZWNvZ25p
emVkX29wdHM9IiRhY191bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRfc2VwLS13aXRo
b3V0LSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAg
ZXNhYworICAgIGV2YWwgd2l0aF8kYWNfdXNlcm9wdD1ubyA7OworCisgIC0teCkKKyAgICAjIE9i
c29sZXRlOyB1c2UgLS13aXRoLXguCisgICAgd2l0aF94PXllcyA7OworCisgIC14LWluY2x1ZGVz
IHwgLS14LWluY2x1ZGVzIHwgLS14LWluY2x1ZGUgfCAtLXgtaW5jbHVkIHwgLS14LWluY2x1IFwK
KyAgfCAtLXgtaW5jbCB8IC0teC1pbmMgfCAtLXgtaW4gfCAtLXgtaSkKKyAgICBhY19wcmV2PXhf
aW5jbHVkZXMgOzsKKyAgLXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlcz0qIHwgLS14LWluY2x1
ZGU9KiB8IC0teC1pbmNsdWQ9KiB8IC0teC1pbmNsdT0qIFwKKyAgfCAtLXgtaW5jbD0qIHwgLS14
LWluYz0qIHwgLS14LWluPSogfCAtLXgtaT0qKQorICAgIHhfaW5jbHVkZXM9JGFjX29wdGFyZyA7
OworCisgIC14LWxpYnJhcmllcyB8IC0teC1saWJyYXJpZXMgfCAtLXgtbGlicmFyaWUgfCAtLXgt
bGlicmFyaSBcCisgIHwgLS14LWxpYnJhciB8IC0teC1saWJyYSB8IC0teC1saWJyIHwgLS14LWxp
YiB8IC0teC1saSB8IC0teC1sKQorICAgIGFjX3ByZXY9eF9saWJyYXJpZXMgOzsKKyAgLXgtbGli
cmFyaWVzPSogfCAtLXgtbGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWU9KiB8IC0teC1saWJyYXJp
PSogXAorICB8IC0teC1saWJyYXI9KiB8IC0teC1saWJyYT0qIHwgLS14LWxpYnI9KiB8IC0teC1s
aWI9KiB8IC0teC1saT0qIHwgLS14LWw9KikKKyAgICB4X2xpYnJhcmllcz0kYWNfb3B0YXJnIDs7
CisKKyAgLSopIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uOiBcYCRhY19vcHRp
b24nCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uIgorICAgIDs7CisKKyAg
Kj0qKQorICAgIGFjX2VudnZhcj1gZXhwciAieCRhY19vcHRpb24iIDogJ3hcKFtePV0qXCk9J2AK
KyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFt
ZXMuCisgICAgY2FzZSAkYWNfZW52dmFyIGluICMoCisgICAgICAnJyB8IFswLTldKiB8ICpbIV8k
YXNfY3JfYWxudW1dKiApCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YXJpYWJsZSBu
YW1lOiBcYCRhY19lbnZ2YXInIiA7OworICAgIGVzYWMKKyAgICBldmFsICRhY19lbnZ2YXI9XCRh
Y19vcHRhcmcKKyAgICBleHBvcnQgJGFjX2VudnZhciA7OworCisgICopCisgICAgIyBGSVhNRTog
c2hvdWxkIGJlIHJlbW92ZWQgaW4gYXV0b2NvbmYgMy4wLgorICAgICRhc19lY2hvICIkYXNfbWU6
IFdBUk5JTkc6IHlvdSBzaG91bGQgdXNlIC0tYnVpbGQsIC0taG9zdCwgLS10YXJnZXQiID4mMgor
ICAgIGV4cHIgIngkYWNfb3B0aW9uIiA6ICIuKlteLS5fJGFzX2NyX2FsbnVtXSIgPi9kZXYvbnVs
bCAmJgorICAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaW52YWxpZCBob3N0IHR5cGU6
ICRhY19vcHRpb24iID4mMgorICAgIDogJHtidWlsZF9hbGlhcz0kYWNfb3B0aW9ufSAke2hvc3Rf
YWxpYXM9JGFjX29wdGlvbn0gJHt0YXJnZXRfYWxpYXM9JGFjX29wdGlvbn0KKyAgICA7OworCisg
IGVzYWMKK2RvbmUKKworaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgIGFjX29wdGlvbj0t
LWBlY2hvICRhY19wcmV2IHwgc2VkICdzL18vLS9nJ2AKKyAgYXNfZm5fZXJyb3IgJD8gIm1pc3Np
bmcgYXJndW1lbnQgdG8gJGFjX29wdGlvbiIKK2ZpCisKK2lmIHRlc3QgLW4gIiRhY191bnJlY29n
bml6ZWRfb3B0cyI7IHRoZW4KKyAgY2FzZSAkZW5hYmxlX29wdGlvbl9jaGVja2luZyBpbgorICAg
IG5vKSA7OworICAgIGZhdGFsKSBhc19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbnM6
ICRhY191bnJlY29nbml6ZWRfb3B0cyIgOzsKKyAgICAqKSAgICAgJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogdW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYy
IDs7CisgIGVzYWMKK2ZpCisKKyMgQ2hlY2sgYWxsIGRpcmVjdG9yeSBhcmd1bWVudHMgZm9yIGNv
bnNpc3RlbmN5LgorZm9yIGFjX3ZhciBpbglleGVjX3ByZWZpeCBwcmVmaXggYmluZGlyIHNiaW5k
aXIgbGliZXhlY2RpciBkYXRhcm9vdGRpciBcCisJCWRhdGFkaXIgc3lzY29uZmRpciBzaGFyZWRz
dGF0ZWRpciBsb2NhbHN0YXRlZGlyIGluY2x1ZGVkaXIgXAorCQlvbGRpbmNsdWRlZGlyIGRvY2Rp
ciBpbmZvZGlyIGh0bWxkaXIgZHZpZGlyIHBkZmRpciBwc2RpciBcCisJCWxpYmRpciBsb2NhbGVk
aXIgbWFuZGlyCitkbworICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgIyBSZW1vdmUgdHJhaWxp
bmcgc2xhc2hlcy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgKi8gKQorICAgICAgYWNfdmFsPWBl
eHByICJYJGFjX3ZhbCIgOiAnWFwoLipbXi9dXCknIFx8ICJYJGFjX3ZhbCIgOiAnWFwoLipcKSdg
CisgICAgICBldmFsICRhY192YXI9XCRhY192YWw7OworICBlc2FjCisgICMgQmUgc3VyZSB0byBo
YXZlIGFic29sdXRlIGRpcmVjdG9yeSBuYW1lcy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgW1xc
LyRdKiB8ID86W1xcL10qICkgIGNvbnRpbnVlOzsKKyAgICBOT05FIHwgJycgKSBjYXNlICRhY192
YXIgaW4gKnByZWZpeCApIGNvbnRpbnVlOzsgZXNhYzs7CisgIGVzYWMKKyAgYXNfZm5fZXJyb3Ig
JD8gImV4cGVjdGVkIGFuIGFic29sdXRlIGRpcmVjdG9yeSBuYW1lIGZvciAtLSRhY192YXI6ICRh
Y192YWwiCitkb25lCisKKyMgVGhlcmUgbWlnaHQgYmUgcGVvcGxlIHdobyBkZXBlbmQgb24gdGhl
IG9sZCBicm9rZW4gYmVoYXZpb3I6IGAkaG9zdCcKKyMgdXNlZCB0byBob2xkIHRoZSBhcmd1bWVu
dCBvZiAtLWhvc3QgZXRjLgorIyBGSVhNRTogVG8gcmVtb3ZlIHNvbWUgZGF5LgorYnVpbGQ9JGJ1
aWxkX2FsaWFzCitob3N0PSRob3N0X2FsaWFzCit0YXJnZXQ9JHRhcmdldF9hbGlhcworCisjIEZJ
WE1FOiBUbyByZW1vdmUgc29tZSBkYXkuCitpZiB0ZXN0ICJ4JGhvc3RfYWxpYXMiICE9IHg7IHRo
ZW4KKyAgaWYgdGVzdCAieCRidWlsZF9hbGlhcyIgPSB4OyB0aGVuCisgICAgY3Jvc3NfY29tcGls
aW5nPW1heWJlCisgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaWYgeW91IHdhbnRlZCB0
byBzZXQgdGhlIC0tYnVpbGQgdHlwZSwgZG9uJ3QgdXNlIC0taG9zdC4KKyAgICBJZiBhIGNyb3Nz
IGNvbXBpbGVyIGlzIGRldGVjdGVkIHRoZW4gY3Jvc3MgY29tcGlsZSBtb2RlIHdpbGwgYmUgdXNl
ZCIgPiYyCisgIGVsaWYgdGVzdCAieCRidWlsZF9hbGlhcyIgIT0gIngkaG9zdF9hbGlhcyI7IHRo
ZW4KKyAgICBjcm9zc19jb21waWxpbmc9eWVzCisgIGZpCitmaQorCithY190b29sX3ByZWZpeD0K
K3Rlc3QgLW4gIiRob3N0X2FsaWFzIiAmJiBhY190b29sX3ByZWZpeD0kaG9zdF9hbGlhcy0KKwor
dGVzdCAiJHNpbGVudCIgPSB5ZXMgJiYgZXhlYyA2Pi9kZXYvbnVsbAorCisKK2FjX3B3ZD1gcHdk
YCAmJiB0ZXN0IC1uICIkYWNfcHdkIiAmJgorYWNfbHNfZGk9YGxzIC1kaSAuYCAmJgorYWNfcHdk
X2xzX2RpPWBjZCAiJGFjX3B3ZCIgJiYgbHMgLWRpIC5gIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJ3
b3JraW5nIGRpcmVjdG9yeSBjYW5ub3QgYmUgZGV0ZXJtaW5lZCIKK3Rlc3QgIlgkYWNfbHNfZGki
ID0gIlgkYWNfcHdkX2xzX2RpIiB8fAorICBhc19mbl9lcnJvciAkPyAicHdkIGRvZXMgbm90IHJl
cG9ydCBuYW1lIG9mIHdvcmtpbmcgZGlyZWN0b3J5IgorCisKKyMgRmluZCB0aGUgc291cmNlIGZp
bGVzLCBpZiBsb2NhdGlvbiB3YXMgbm90IHNwZWNpZmllZC4KK2lmIHRlc3QgLXogIiRzcmNkaXIi
OyB0aGVuCisgIGFjX3NyY2Rpcl9kZWZhdWx0ZWQ9eWVzCisgICMgVHJ5IHRoZSBkaXJlY3Rvcnkg
Y29udGFpbmluZyB0aGlzIHNjcmlwdCwgdGhlbiB0aGUgcGFyZW50IGRpcmVjdG9yeS4KKyAgYWNf
Y29uZmRpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19teXNlbGYiIHx8CiskYXNfZXhwciBYIiRhc19t
eXNlbGYiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX215c2Vs
ZiIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wpJCcgXHwg
XAorCSBYIiRhc19teXNlbGYiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2Vj
aG8gWCIkYXNfbXlzZWxmIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpc
LyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sK
KwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wx
LworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJ
ICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgc3JjZGlyPSRhY19jb25mZGlyCisgIGlmIHRlc3QgISAt
ciAiJHNyY2Rpci8kYWNfdW5pcXVlX2ZpbGUiOyB0aGVuCisgICAgc3JjZGlyPS4uCisgIGZpCitl
bHNlCisgIGFjX3NyY2Rpcl9kZWZhdWx0ZWQ9bm8KK2ZpCitpZiB0ZXN0ICEgLXIgIiRzcmNkaXIv
JGFjX3VuaXF1ZV9maWxlIjsgdGhlbgorICB0ZXN0ICIkYWNfc3JjZGlyX2RlZmF1bHRlZCIgPSB5
ZXMgJiYgc3JjZGlyPSIkYWNfY29uZmRpciBvciAuLiIKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBmaW5kIHNvdXJjZXMgKCRhY191bmlxdWVfZmlsZSkgaW4gJHNyY2RpciIKK2ZpCithY19tc2c9
InNvdXJjZXMgYXJlIGluICRzcmNkaXIsIGJ1dCBcYGNkICRzcmNkaXInIGRvZXMgbm90IHdvcmsi
CithY19hYnNfY29uZmRpcj1gKAorCWNkICIkc3JjZGlyIiAmJiB0ZXN0IC1yICIuLyRhY191bmlx
dWVfZmlsZSIgfHwgYXNfZm5fZXJyb3IgJD8gIiRhY19tc2ciCisJcHdkKWAKKyMgV2hlbiBidWls
ZGluZyBpbiBwbGFjZSwgc2V0IHNyY2Rpcj0uCitpZiB0ZXN0ICIkYWNfYWJzX2NvbmZkaXIiID0g
IiRhY19wd2QiOyB0aGVuCisgIHNyY2Rpcj0uCitmaQorIyBSZW1vdmUgdW5uZWNlc3NhcnkgdHJh
aWxpbmcgc2xhc2hlcyBmcm9tIHNyY2Rpci4KKyMgRG91YmxlIHNsYXNoZXMgaW4gZmlsZSBuYW1l
cyBpbiBvYmplY3QgZmlsZSBkZWJ1Z2dpbmcgaW5mbworIyBtZXNzIHVwIE0teCBnZGIgaW4gRW1h
Y3MuCitjYXNlICRzcmNkaXIgaW4KKyovKSBzcmNkaXI9YGV4cHIgIlgkc3JjZGlyIiA6ICdYXCgu
KlteL11cKScgXHwgIlgkc3JjZGlyIiA6ICdYXCguKlwpJ2A7OworZXNhYworZm9yIGFjX3ZhciBp
biAkYWNfcHJlY2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19lbnZfJHthY192YXJ9X3NldD1cJHsk
e2FjX3Zhcn0rc2V0fQorICBldmFsIGFjX2Vudl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0K
KyAgZXZhbCBhY19jdl9lbnZfJHthY192YXJ9X3NldD1cJHske2FjX3Zhcn0rc2V0fQorICBldmFs
IGFjX2N2X2Vudl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0KK2RvbmUKKworIworIyBSZXBv
cnQgdGhlIC0taGVscCBtZXNzYWdlLgorIworaWYgdGVzdCAiJGFjX2luaXRfaGVscCIgPSAibG9u
ZyI7IHRoZW4KKyAgIyBPbWl0IHNvbWUgaW50ZXJuYWwgb3Igb2Jzb2xldGUgb3B0aW9ucyB0byBt
YWtlIHRoZSBsaXN0IGxlc3MgaW1wb3NpbmcuCisgICMgVGhpcyBtZXNzYWdlIGlzIHRvbyBsb25n
IHRvIGJlIGEgc3RyaW5nIGluIHRoZSBBL1VYIDMuMSBzaC4KKyAgY2F0IDw8X0FDRU9GCitcYGNv
bmZpZ3VyZScgY29uZmlndXJlcyB0aGlzIHBhY2thZ2UgdG8gYWRhcHQgdG8gbWFueSBraW5kcyBv
ZiBzeXN0ZW1zLgorCitVc2FnZTogJDAgW09QVElPTl0uLi4gW1ZBUj1WQUxVRV0uLi4KKworVG8g
YXNzaWduIGVudmlyb25tZW50IHZhcmlhYmxlcyAoZS5nLiwgQ0MsIENGTEFHUy4uLiksIHNwZWNp
ZnkgdGhlbSBhcworVkFSPVZBTFVFLiAgU2VlIGJlbG93IGZvciBkZXNjcmlwdGlvbnMgb2Ygc29t
ZSBvZiB0aGUgdXNlZnVsIHZhcmlhYmxlcy4KKworRGVmYXVsdHMgZm9yIHRoZSBvcHRpb25zIGFy
ZSBzcGVjaWZpZWQgaW4gYnJhY2tldHMuCisKK0NvbmZpZ3VyYXRpb246CisgIC1oLCAtLWhlbHAg
ICAgICAgICAgICAgIGRpc3BsYXkgdGhpcyBoZWxwIGFuZCBleGl0CisgICAgICAtLWhlbHA9c2hv
cnQgICAgICAgIGRpc3BsYXkgb3B0aW9ucyBzcGVjaWZpYyB0byB0aGlzIHBhY2thZ2UKKyAgICAg
IC0taGVscD1yZWN1cnNpdmUgICAgZGlzcGxheSB0aGUgc2hvcnQgaGVscCBvZiBhbGwgdGhlIGlu
Y2x1ZGVkIHBhY2thZ2VzCisgIC1WLCAtLXZlcnNpb24gICAgICAgICAgIGRpc3BsYXkgdmVyc2lv
biBpbmZvcm1hdGlvbiBhbmQgZXhpdAorICAtcSwgLS1xdWlldCwgLS1zaWxlbnQgICBkbyBub3Qg
cHJpbnQgXGBjaGVja2luZyAuLi4nIG1lc3NhZ2VzCisgICAgICAtLWNhY2hlLWZpbGU9RklMRSAg
IGNhY2hlIHRlc3QgcmVzdWx0cyBpbiBGSUxFIFtkaXNhYmxlZF0KKyAgLUMsIC0tY29uZmlnLWNh
Y2hlICAgICAgYWxpYXMgZm9yIFxgLS1jYWNoZS1maWxlPWNvbmZpZy5jYWNoZScKKyAgLW4sIC0t
bm8tY3JlYXRlICAgICAgICAgZG8gbm90IGNyZWF0ZSBvdXRwdXQgZmlsZXMKKyAgICAgIC0tc3Jj
ZGlyPURJUiAgICAgICAgZmluZCB0aGUgc291cmNlcyBpbiBESVIgW2NvbmZpZ3VyZSBkaXIgb3Ig
XGAuLiddCisKK0luc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1wcmVmaXg9UFJFRklYICAg
ICAgICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtaW5kZXBlbmRlbnQgZmlsZXMgaW4gUFJFRklYCisg
ICAgICAgICAgICAgICAgICAgICAgICAgIFskYWNfZGVmYXVsdF9wcmVmaXhdCisgIC0tZXhlYy1w
cmVmaXg9RVBSRUZJWCAgIGluc3RhbGwgYXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBmaWxlcyBpbiBF
UFJFRklYCisgICAgICAgICAgICAgICAgICAgICAgICAgIFtQUkVGSVhdCisKK0J5IGRlZmF1bHQs
IFxgbWFrZSBpbnN0YWxsJyB3aWxsIGluc3RhbGwgYWxsIHRoZSBmaWxlcyBpbgorXGAkYWNfZGVm
YXVsdF9wcmVmaXgvYmluJywgXGAkYWNfZGVmYXVsdF9wcmVmaXgvbGliJyBldGMuICBZb3UgY2Fu
IHNwZWNpZnkKK2FuIGluc3RhbGxhdGlvbiBwcmVmaXggb3RoZXIgdGhhbiBcYCRhY19kZWZhdWx0
X3ByZWZpeCcgdXNpbmcgXGAtLXByZWZpeCcsCitmb3IgaW5zdGFuY2UgXGAtLXByZWZpeD1cJEhP
TUUnLgorCitGb3IgYmV0dGVyIGNvbnRyb2wsIHVzZSB0aGUgb3B0aW9ucyBiZWxvdy4KKworRmlu
ZSB0dW5pbmcgb2YgdGhlIGluc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1iaW5kaXI9RElS
ICAgICAgICAgICAgdXNlciBleGVjdXRhYmxlcyBbRVBSRUZJWC9iaW5dCisgIC0tc2JpbmRpcj1E
SVIgICAgICAgICAgIHN5c3RlbSBhZG1pbiBleGVjdXRhYmxlcyBbRVBSRUZJWC9zYmluXQorICAt
LWxpYmV4ZWNkaXI9RElSICAgICAgICBwcm9ncmFtIGV4ZWN1dGFibGVzIFtFUFJFRklYL2xpYmV4
ZWNdCisgIC0tc3lzY29uZmRpcj1ESVIgICAgICAgIHJlYWQtb25seSBzaW5nbGUtbWFjaGluZSBk
YXRhIFtQUkVGSVgvZXRjXQorICAtLXNoYXJlZHN0YXRlZGlyPURJUiAgICBtb2RpZmlhYmxlIGFy
Y2hpdGVjdHVyZS1pbmRlcGVuZGVudCBkYXRhIFtQUkVGSVgvY29tXQorICAtLWxvY2Fsc3RhdGVk
aXI9RElSICAgICBtb2RpZmlhYmxlIHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BSRUZJWC92YXJdCisg
IC0tbGliZGlyPURJUiAgICAgICAgICAgIG9iamVjdCBjb2RlIGxpYnJhcmllcyBbRVBSRUZJWC9s
aWJdCisgIC0taW5jbHVkZWRpcj1ESVIgICAgICAgIEMgaGVhZGVyIGZpbGVzIFtQUkVGSVgvaW5j
bHVkZV0KKyAgLS1vbGRpbmNsdWRlZGlyPURJUiAgICAgQyBoZWFkZXIgZmlsZXMgZm9yIG5vbi1n
Y2MgWy91c3IvaW5jbHVkZV0KKyAgLS1kYXRhcm9vdGRpcj1ESVIgICAgICAgcmVhZC1vbmx5IGFy
Y2guLWluZGVwZW5kZW50IGRhdGEgcm9vdCBbUFJFRklYL3NoYXJlXQorICAtLWRhdGFkaXI9RElS
ICAgICAgICAgICByZWFkLW9ubHkgYXJjaGl0ZWN0dXJlLWluZGVwZW5kZW50IGRhdGEgW0RBVEFS
T09URElSXQorICAtLWluZm9kaXI9RElSICAgICAgICAgICBpbmZvIGRvY3VtZW50YXRpb24gW0RB
VEFST09URElSL2luZm9dCisgIC0tbG9jYWxlZGlyPURJUiAgICAgICAgIGxvY2FsZS1kZXBlbmRl
bnQgZGF0YSBbREFUQVJPT1RESVIvbG9jYWxlXQorICAtLW1hbmRpcj1ESVIgICAgICAgICAgICBt
YW4gZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RESVIvbWFuXQorICAtLWRvY2Rpcj1ESVIgICAgICAg
ICAgICBkb2N1bWVudGF0aW9uIHJvb3QgW0RBVEFST09URElSL2RvYy9QQUNLQUdFXQorICAtLWh0
bWxkaXI9RElSICAgICAgICAgICBodG1sIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1kdmlk
aXI9RElSICAgICAgICAgICAgZHZpIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wZGZkaXI9
RElSICAgICAgICAgICAgcGRmIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wc2Rpcj1ESVIg
ICAgICAgICAgICAgcHMgZG9jdW1lbnRhdGlvbiBbRE9DRElSXQorX0FDRU9GCisKKyAgY2F0IDw8
XF9BQ0VPRgorCitTeXN0ZW0gdHlwZXM6CisgIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBm
b3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCisgIC0taG9zdD1IT1NUICAgICAgIGNyb3Nz
LWNvbXBpbGUgdG8gYnVpbGQgcHJvZ3JhbXMgdG8gcnVuIG9uIEhPU1QgW0JVSUxEXQorX0FDRU9G
CitmaQorCitpZiB0ZXN0IC1uICIkYWNfaW5pdF9oZWxwIjsgdGhlbgorCisgIGNhdCA8PFxfQUNF
T0YKKworT3B0aW9uYWwgRmVhdHVyZXM6CisgIC0tZGlzYWJsZS1vcHRpb24tY2hlY2tpbmcgIGln
bm9yZSB1bnJlY29nbml6ZWQgLS1lbmFibGUvLS13aXRoIG9wdGlvbnMKKyAgLS1kaXNhYmxlLUZF
QVRVUkUgICAgICAgZG8gbm90IGluY2x1ZGUgRkVBVFVSRSAoc2FtZSBhcyAtLWVuYWJsZS1GRUFU
VVJFPW5vKQorICAtLWVuYWJsZS1GRUFUVVJFWz1BUkddICBpbmNsdWRlIEZFQVRVUkUgW0FSRz15
ZXNdCisgIC0tZW5hYmxlLXhzbSAgICAgICAgICAgIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxl
IChieSBkZWZhdWx0LCBGbGFzaykKKyAgLS1lbmFibGUtZ2l0aHR0cCAgICAgICAgRG93bmxvYWQg
R0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUAorICAtLWRpc2FibGUtbW9uaXRvcnMgICAgICBEaXNh
YmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzCisgIC0tZW5hYmxlLXZ0cG0g
ICAgICAgICAgIEVuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlCisgIC0tZW5h
YmxlLXhhcGkgICAgICAgICAgIEVuYWJsZSBYZW4gQVBJIEJpbmRpbmdzCisgIC0tZGlzYWJsZS1w
eXRob250b29scyAgIERpc2FibGUgUHl0aG9uIHRvb2xzCisgIC0tZGlzYWJsZS1vY2FtbHRvb2xz
ICAgIERpc2FibGUgT2NhbWwgdG9vbHMKKyAgLS1lbmFibGUtbWluaXRlcm0gICAgICAgRW5hYmxl
IG1pbml0ZXJtCisgIC0tZW5hYmxlLWxvbW91bnQgICAgICAgIEVuYWJsZSBsb21vdW50CisgIC0t
ZGlzYWJsZS1kZWJ1ZyAgICAgICAgIERpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29s
cworCitTb21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoKKyAgQ0MgICAgICAg
ICAgQyBjb21waWxlciBjb21tYW5kCisgIENGTEFHUyAgICAgIEMgY29tcGlsZXIgZmxhZ3MKKyAg
TERGTEFHUyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxp
YnJhcmllcyBpbiBhCisgICAgICAgICAgICAgIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8bGliIGRp
cj4KKyAgTElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8gdGhlIGxpbmtlciwgZS5nLiAt
bDxsaWJyYXJ5PgorICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3Ig
ZmxhZ3MsIGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCisgICAgICAgICAgICAgIHlvdSBoYXZlIGhl
YWRlcnMgaW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1ZGUgZGlyPgorICBDUFAgICAg
ICAgICBDIHByZXByb2Nlc3NvcgorICBQUkVQRU5EX0lOQ0xVREVTCisgICAgICAgICAgICAgIExp
c3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQor
ICBQUkVQRU5EX0xJQiBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxB
R1MgKHdpdGhvdXQgLUwpCisgIEFQUEVORF9JTkNMVURFUworICAgICAgICAgICAgICBMaXN0IG9m
IGluY2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQorICBBUFBF
TkRfTElCICBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAod2l0
aG91dCAtTCkKKyAgUFlUSE9OICAgICAgUGF0aCB0byB0aGUgUHl0aG9uIHBhcnNlcgorICBQRVJM
ICAgICAgICBQYXRoIHRvIFBlcmwgcGFyc2VyCisgIEJSQ1RMICAgICAgIFBhdGggdG8gYnJjdGwg
dG9vbAorICBJUCAgICAgICAgICBQYXRoIHRvIGlwIHRvb2wKKyAgQklTT04gICAgICAgUGF0aCB0
byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yCisgIEZMRVggICAgICAgIFBhdGggdG8gRmxleCBsZXhp
Y2FsIGFuYWx5c2VyIGdlbmVyYXRvcgorICBDVVJMICAgICAgICBQYXRoIHRvIGN1cmwtY29uZmln
IHRvb2wKKyAgWE1MICAgICAgICAgUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sCisgIEJBU0ggICAg
ICAgIFBhdGggdG8gYmFzaCBzaGVsbAorICBYR0VUVEVYVCAgICBQYXRoIHRvIHhnZXR0dGV4dCB0
b29sCisKK1VzZSB0aGVzZSB2YXJpYWJsZXMgdG8gb3ZlcnJpZGUgdGhlIGNob2ljZXMgbWFkZSBi
eSBgY29uZmlndXJlJyBvciB0byBoZWxwCitpdCB0byBmaW5kIGxpYnJhcmllcyBhbmQgcHJvZ3Jh
bXMgd2l0aCBub25zdGFuZGFyZCBuYW1lcy9sb2NhdGlvbnMuCisKK1JlcG9ydCBidWdzIHRvIHRo
ZSBwYWNrYWdlIHByb3ZpZGVyLgorX0FDRU9GCithY19zdGF0dXM9JD8KK2ZpCisKK2lmIHRlc3Qg
IiRhY19pbml0X2hlbHAiID0gInJlY3Vyc2l2ZSI7IHRoZW4KKyAgIyBJZiB0aGVyZSBhcmUgc3Vi
ZGlycywgcmVwb3J0IHRoZWlyIHNwZWNpZmljIC0taGVscC4KKyAgZm9yIGFjX2RpciBpbiA6ICRh
Y19zdWJkaXJzX2FsbDsgZG8gdGVzdCAieCRhY19kaXIiID0geDogJiYgY29udGludWUKKyAgICB0
ZXN0IC1kICIkYWNfZGlyIiB8fAorICAgICAgeyBjZCAiJHNyY2RpciIgJiYgYWNfcHdkPWBwd2Rg
ICYmIHNyY2Rpcj0uICYmIHRlc3QgLWQgIiRhY19kaXIiOyB9IHx8CisgICAgICBjb250aW51ZQor
ICAgIGFjX2J1aWxkZGlyPS4KKworY2FzZSAiJGFjX2RpciIgaW4KKy4pIGFjX2Rpcl9zdWZmaXg9
IGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4PSA7OworKikKKyAgYWNf
ZGlyX3N1ZmZpeD0vYCRhc19lY2hvICIkYWNfZGlyIiB8IHNlZCAnc3xeXC5bXFwvXXx8J2AKKyAg
IyBBICIuLiIgZm9yIGVhY2ggZGlyZWN0b3J5IGluICRhY19kaXJfc3VmZml4LgorICBhY190b3Bf
YnVpbGRkaXJfc3ViPWAkYXNfZWNobyAiJGFjX2Rpcl9zdWZmaXgiIHwgc2VkICdzfC9bXlxcL10q
fC8uLnxnO3N8L3x8J2AKKyAgY2FzZSAkYWNfdG9wX2J1aWxkZGlyX3N1YiBpbgorICAiIikgYWNf
dG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7CisgICopICBhY190b3Bf
YnVpbGRfcHJlZml4PSRhY190b3BfYnVpbGRkaXJfc3ViLyA7OworICBlc2FjIDs7Citlc2FjCith
Y19hYnNfdG9wX2J1aWxkZGlyPSRhY19wd2QKK2FjX2Fic19idWlsZGRpcj0kYWNfcHdkJGFjX2Rp
cl9zdWZmaXgKKyMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk6CithY190b3BfYnVpbGRkaXI9
JGFjX3RvcF9idWlsZF9wcmVmaXgKKworY2FzZSAkc3JjZGlyIGluCisgIC4pICAjIFdlIGFyZSBi
dWlsZGluZyBpbiBwbGFjZS4KKyAgICBhY19zcmNkaXI9LgorICAgIGFjX3RvcF9zcmNkaXI9JGFj
X3RvcF9idWlsZGRpcl9zdWIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0kYWNfcHdkIDs7CisgIFtc
XC9dKiB8ID86W1xcL10qICkgICMgQWJzb2x1dGUgbmFtZS4KKyAgICBhY19zcmNkaXI9JHNyY2Rp
ciRhY19kaXJfc3VmZml4OworICAgIGFjX3RvcF9zcmNkaXI9JHNyY2RpcgorICAgIGFjX2Fic190
b3Bfc3JjZGlyPSRzcmNkaXIgOzsKKyAgKikgIyBSZWxhdGl2ZSBuYW1lLgorICAgIGFjX3NyY2Rp
cj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIkYWNfZGlyX3N1ZmZpeAorICAgIGFjX3RvcF9z
cmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9
JGFjX3B3ZC8kc3JjZGlyIDs7Citlc2FjCithY19hYnNfc3JjZGlyPSRhY19hYnNfdG9wX3NyY2Rp
ciRhY19kaXJfc3VmZml4CisKKyAgICBjZCAiJGFjX2RpciIgfHwgeyBhY19zdGF0dXM9JD87IGNv
bnRpbnVlOyB9CisgICAgIyBDaGVjayBmb3IgZ3Vlc3RlZCBjb25maWd1cmUuCisgICAgaWYgdGVz
dCAtZiAiJGFjX3NyY2Rpci9jb25maWd1cmUuZ251IjsgdGhlbgorICAgICAgZWNobyAmJgorICAg
ICAgJFNIRUxMICIkYWNfc3JjZGlyL2NvbmZpZ3VyZS5nbnUiIC0taGVscD1yZWN1cnNpdmUKKyAg
ICBlbGlmIHRlc3QgLWYgIiRhY19zcmNkaXIvY29uZmlndXJlIjsgdGhlbgorICAgICAgZWNobyAm
JgorICAgICAgJFNIRUxMICIkYWNfc3JjZGlyL2NvbmZpZ3VyZSIgLS1oZWxwPXJlY3Vyc2l2ZQor
ICAgIGVsc2UKKyAgICAgICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IG5vIGNvbmZpZ3VyYXRp
b24gaW5mb3JtYXRpb24gaXMgaW4gJGFjX2RpciIgPiYyCisgICAgZmkgfHwgYWNfc3RhdHVzPSQ/
CisgICAgY2QgIiRhY19wd2QiIHx8IHsgYWNfc3RhdHVzPSQ/OyBicmVhazsgfQorICBkb25lCitm
aQorCit0ZXN0IC1uICIkYWNfaW5pdF9oZWxwIiAmJiBleGl0ICRhY19zdGF0dXMKK2lmICRhY19p
bml0X3ZlcnNpb247IHRoZW4KKyAgY2F0IDw8XF9BQ0VPRgorY29uZmlndXJlCitnZW5lcmF0ZWQg
YnkgR05VIEF1dG9jb25mIDIuNjcKKworQ29weXJpZ2h0IChDKSAyMDEwIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbiwgSW5jLgorVGhpcyBjb25maWd1cmUgc2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7
IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KK2dpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9u
IHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4KK19BQ0VPRgorICBleGl0CitmaQor
CisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIEF1dG9jb25mIGluaXRpYWxpemF0
aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMgYWNfZm5fY190cnlf
Y29tcGlsZSBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGNv
bXBpbGUgY29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVk
LgorYWNfZm5fY190cnlfY29tcGlsZSAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQx
In0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHJt
IC1mIGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGUiCitj
YXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2Vj
aG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNf
ZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jb21waWxlIikgMj5jb25m
dGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVu
CisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQg
Y29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAg
ZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0
YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeworCSB0ZXN0IC16ICIkYWNf
Y193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAgIH0gJiYg
dGVzdCAtcyBjb25mdGVzdC4kYWNfb2JqZXh0OyB0aGVuIDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UK
KyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98
IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKKwlhY19yZXR2YWw9MQorZmkKKyAgZXZhbCAkYXNf
bGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5v
PTsgdW5zZXQgYXNfbGluZW5vO30KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCisKK30g
IyBhY19mbl9jX3RyeV9jb21waWxlCisKKyMgYWNfZm5fY190cnlfY3BwIExJTkVOTworIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyeSB0byBwcmVwcm9jZXNzIGNvbmZ0ZXN0LiRhY19leHQs
IGFuZCByZXR1cm4gd2hldGhlciB0aGlzIHN1Y2NlZWRlZC4KK2FjX2ZuX2NfdHJ5X2NwcCAoKQor
eworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVu
b19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIHsgeyBhY190cnk9IiRhY19jcHAgY29uZnRl
c3QuJGFjX2V4dCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBh
Y190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYwor
ZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5
X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2Nw
cCBjb25mdGVzdC4kYWNfZXh0IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlm
IHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3Qu
ZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNv
bmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9
IDA7IH0gPiBjb25mdGVzdC5pICYmIHsKKwkgdGVzdCAteiAiJGFjX2NfcHJlcHJvY193YXJuX2Zs
YWckYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAg
IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWls
ZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUK
KworICAgIGFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngk
YXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQor
ICBhc19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5X2NwcAorCisj
IGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgTElORU5PIEhFQURFUiBWQVIgSU5DTFVERVMK
KyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorIyBUZXN0cyB3aGV0aGVyIEhFQURFUiBleGlzdHMsIGdpdmluZyBhIHdhcm5pbmcgaWYgaXQg
Y2Fubm90IGJlIGNvbXBpbGVkIHVzaW5nCisjIHRoZSBpbmNsdWRlIGZpbGVzIGluIElOQ0xVREVT
IGFuZCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIKKyMgYWNjb3JkaW5nbHkuCithY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0i
JDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAg
aWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBzZXQ7IHRoZW4gOgorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KK2lmIGV2YWwgInRlc3QgXCJcJHsk
MytzZXR9XCIiID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Zp
CitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7
IH0KK2Vsc2UKKyAgIyBJcyB0aGUgaGVhZGVyIGNvbXBpbGFibGU/Cit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHVzYWJpbGl0eSIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyAkMiB1c2FiaWxpdHkuLi4gIiA+JjY7IH0KK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0
CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfaGVhZGVyX2NvbXBpbGVyPXllcworZWxzZQorICBhY19oZWFkZXJfY29t
cGlsZXI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfaGVhZGVyX2NvbXBpbGVyIiA+JjUKKyRhc19lY2hvICIkYWNfaGVhZGVy
X2NvbXBpbGVyIiA+JjY7IH0KKworIyBJcyB0aGUgaGVhZGVyIHByZXNlbnQ/Cit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHByZXNlbmNlIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nICQyIHByZXNlbmNlLi4uICIgPiY2OyB9CitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRo
ZW4gOgorICBhY19oZWFkZXJfcHJlcHJvYz15ZXMKK2Vsc2UKKyAgYWNfaGVhZGVyX3ByZXByb2M9
bm8KK2ZpCitybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0Cit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2hlYWRl
cl9wcmVwcm9jIiA+JjUKKyRhc19lY2hvICIkYWNfaGVhZGVyX3ByZXByb2MiID4mNjsgfQorCisj
IFNvPyAgV2hhdCBhYm91dCB0aGlzIGhlYWRlcj8KK2Nhc2UgJGFjX2hlYWRlcl9jb21waWxlcjok
YWNfaGVhZGVyX3ByZXByb2M6JGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gIygoCisgIHllczpu
bzogKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklO
RzogJDI6IGFjY2VwdGVkIGJ5IHRoZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXByb2Nl
c3NvciEiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IGFjY2VwdGVkIGJ5IHRo
ZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXByb2Nlc3NvciEiID4mMjt9CisgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJvY2Vl
ZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBX
QVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiYyO30K
KyAgICA7OworICBubzp5ZXM6KiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJlc2VudCBidXQgY2Fubm90IGJlIGNvbXBpbGVkIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3QgYmUg
Y29tcGlsZWQiID4mMjt9CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZvciBtaXNzaW5nIHByZXJlcXVpc2l0ZSBoZWFk
ZXJzPyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZvciBt
aXNzaW5nIHByZXJlcXVpc2l0ZSBoZWFkZXJzPyIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBzZWUgdGhlIEF1dG9jb25mIGRv
Y3VtZW50YXRpb24iID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHNlZSB0aGUg
QXV0b2NvbmYgZG9jdW1lbnRhdGlvbiIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiAgICAgc2VjdGlvbiBcIlByZXNlbnQgQnV0
IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQy
OiAgICAgc2VjdGlvbiBcIlByZXNlbnQgQnV0IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjI7fQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6
IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1bHQiID4mNQorJGFzX2VjaG8gIiRh
c19tZTogV0FSTklORzogJDI6IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1bHQi
ID4mMjt9CisgICAgOzsKK2VzYWMKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQy
Li4uICIgPiY2OyB9CitpZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9IHNldDsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGV2YWwgIiQzPVwkYWNfaGVh
ZGVyX2NvbXBpbGVyIgorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2Vj
aG8gIiRhY19yZXMiID4mNjsgfQorZmkKKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4
JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30K
KworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwKKworIyBhY19mbl9jX3RyeV9ydW4g
TElORU5PCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGxpbmsgY29uZnRlc3Qu
JGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLiBBc3N1bWVzCisjIHRo
YXQgZXhlY3V0YWJsZXMgKmNhbiogYmUgcnVuLgorYWNfZm5fY190cnlfcnVuICgpCit7CisgIGFz
X2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNr
PSRhc19saW5lbm9fc3RhY2sKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRh
Y190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7Owor
ICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFj
X3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0dXM9
JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0
YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeyBhY190cnk9Jy4vY29uZnRl
c3QkYWNfZXhlZXh0JworICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8
ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7
Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFs
ICIkYWNfdHJ5IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1
cyA9IDA7IH07IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFz
X21lOiBwcm9ncmFtIGV4aXRlZCB3aXRoIHN0YXR1cyAkYWNfc3RhdHVzIiA+JjUKKyAgICAgICAk
YXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycg
Y29uZnRlc3QuJGFjX2V4dCA+JjUKKworICAgICAgIGFjX3JldHZhbD0kYWNfc3RhdHVzCitmaQor
ICBybSAtcmYgY29uZnRlc3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwg
JGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xp
bmVubz07IHVuc2V0IGFzX2xpbmVubzt9CisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAor
Cit9ICMgYWNfZm5fY190cnlfcnVuCisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSBM
SU5FTk8gSEVBREVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4aXN0
cyBhbmQgY2FuIGJlIGNvbXBpbGVkIHVzaW5nIHRoZSBpbmNsdWRlIGZpbGVzIGluCisjIElOQ0xV
REVTLCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCithY19mbl9j
X2NoZWNrX2hlYWRlcl9jb21waWxlICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEi
fSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFsICJ0ZXN0
IFwiXCR7JDMrc2V0fVwiIiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDM9eWVzIgorZWxz
ZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVz
IiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNr
OyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNf
bGluZW5vO30KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUKKworIyBhY19mbl9j
X3RyeV9saW5rIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gbGlu
ayBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCith
Y19mbl9jX3RyeV9saW5rICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19s
aW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdCRhY19leGVleHQKKyAgaWYgeyB7IGFjX3RyeT0iJGFj
X2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5
X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwg
YWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hv
XCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikg
Mj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJy
OyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAg
ICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5l
cnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0g
JGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeworCSB0ZXN0IC16
ICIkYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAg
IH0gJiYgdGVzdCAtcyBjb25mdGVzdCRhY19leGVleHQgJiYgeworCSB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllcyB8fAorCSAkYXNfdGVzdF94IGNvbmZ0ZXN0JGFjX2V4ZWV4dAorICAgICAg
IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWls
ZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUK
KworCWFjX3JldHZhbD0xCitmaQorICAjIERlbGV0ZSB0aGUgSVBBL0lQTyAoSW50ZXIgUHJvY2Vk
dXJhbCBBbmFseXNpcy9PcHRpbWl6YXRpb24pIGluZm9ybWF0aW9uCisgICMgY3JlYXRlZCBieSB0
aGUgUEdJIGNvbXBpbGVyIChjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vKSwgYXMgaXQgd291bGQK
KyAgIyBpbnRlcmZlcmUgd2l0aCB0aGUgbmV4dCBsaW5rIGNvbW1hbmQ7IGFsc28gZGVsZXRlIGEg
ZGlyZWN0b3J5IHRoYXQgaXMKKyAgIyBsZWZ0IGJlaGluZCBieSBBcHBsZSdzIGNvbXBpbGVyLiAg
V2UgZG8gdGhpcyBiZWZvcmUgZXhlY3V0aW5nIHRoZSBhY3Rpb25zLgorICBybSAtcmYgY29uZnRl
c3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwgJGFzX2xpbmVub19zdGFj
azsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFz
X2xpbmVubzt9CisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMgYWNfZm5fY190
cnlfbGluaworCisjIGFjX2ZuX2NfY2hlY2tfZnVuYyBMSU5FTk8gRlVOQyBWQVIKKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3Rz
LCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkKK2FjX2ZuX2NfY2hl
Y2tfZnVuYyAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0
YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1c
IiIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCisvKiBEZWZpbmUgJDIgdG8gYW4gaW5ub2N1b3VzIHZhcmlhbnQsIGluIGNhc2Ug
PGxpbWl0cy5oPiBkZWNsYXJlcyAkMi4KKyAgIEZvciBleGFtcGxlLCBIUC1VWCAxMWkgPGxpbWl0
cy5oPiBkZWNsYXJlcyBnZXR0aW1lb2ZkYXkuICAqLworI2RlZmluZSAkMiBpbm5vY3VvdXNfJDIK
KworLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5
IGZldyBwcm90b3R5cGVzLAorICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgJDIgKCk7
IGJlbG93LgorICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18g
aXMgZGVmaW5lZCwgc2luY2UKKyAgICA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFu
ZGluZyBjb21waWxlcnMuICAqLworCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRz
Lmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRpZgorCisjdW5kZWYgJDIKKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciAkMiAoKTsKKy8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rp
b25zIHdoaWNoIGl0IGltcGxlbWVudHMKKyAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4g
IFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZAorICAgIHNvbWV0aGluZyBzdGFydGlu
ZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLworI2lmIGRlZmlu
ZWQgX19zdHViXyQyIHx8IGRlZmluZWQgX19zdHViX19fJDIKK2Nob2tlIG1lCisjZW5kaWYKKwor
aW50CittYWluICgpCit7CityZXR1cm4gJDIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDM9eWVz
IgorZWxzZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMi
ID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNr
IiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBhc19saW5lbm87fQorCit9ICMgYWNfZm5fY19j
aGVja19mdW5jCisKKyMgYWNfZm5fY19jaGVja190eXBlIExJTkVOTyBUWVBFIFZBUiBJTkNMVURF
UworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3Rz
IHdoZXRoZXIgVFlQRSBleGlzdHMgYWZ0ZXIgaGF2aW5nIGluY2x1ZGVkIElOQ0xVREVTLCBzZXR0
aW5nIGNhY2hlCisjIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfdHlw
ZSAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFz
X2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyQzK3NldH1cIiIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIk
Mz1ubyIKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworJDQKK2ludAorbWFpbiAoKQoreworaWYgKHNpemVvZiAoJDIp
KQorCSByZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNAoraW50CittYWlu
ICgpCit7CitpZiAoc2l6ZW9mICgoJDIpKSkKKwkgICAgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KworZWxzZQorICBldmFsICIkMz15ZXMiCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19y
ZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwg
JGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xp
bmVubz07IHVuc2V0IGFzX2xpbmVubzt9CisKK30gIyBhY19mbl9jX2NoZWNrX3R5cGUKKworIyBh
Y19mbl9jX2ZpbmRfaW50WF90IExJTkVOTyBCSVRTIFZBUgorIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorIyBGaW5kcyBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0
aCBCSVRTLCBzZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUgorIyBhY2NvcmRpbmdseS4KK2FjX2Zu
X2NfZmluZF9pbnRYX3QgKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xp
bmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpbnQkMl90IiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciBpbnQkMl90Li4uICIgPiY2OyB9CitpZiBldmFsICJ0
ZXN0IFwiXCR7JDMrc2V0fVwiIiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAt
IG5ldmVyIGNoZWNrIGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKKyAgICAgIyB0
aGFuIGhhbGYgb2YgdGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KKyAgICAgZm9yIGFjX3R5cGUg
aW4gaW50JDJfdCAnaW50JyAnbG9uZyBpbnQnIFwKKwkgJ2xvbmcgbG9uZyBpbnQnICdzaG9ydCBp
bnQnICdzaWduZWQgY2hhcic7IGRvCisgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2Rl
ZmF1bHQKKwkgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7Citz
dGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAoKCgoKCRhY190
eXBlKSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAor
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRM
SU5FTk8iOyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKwkgICAg
ICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7CitzdGF0aWMgaW50
IHRlc3RfYXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikg
PDwgTikgLSAxKSAqIDIgKyAxKQorCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwg
TikgPDwgTikgLSAxKSAqIDIgKyAyKSldOwordGVzdF9hcnJheSBbMF0gPSAwCisKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRo
ZW4gOgorCitlbHNlCisgIGNhc2UgJGFjX3R5cGUgaW4gIygKKyAgaW50JDJfdCkgOgorICAgIGV2
YWwgIiQzPXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2Vz
YWMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4
Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFj
X3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZh
bCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNf
bGluZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KKworfSAjIGFjX2ZuX2NfZmluZF9pbnRYX3QKKwor
IyBhY19mbl9jX2NoZWNrX21lbWJlciBMSU5FTk8gQUdHUiBNRU1CRVIgVkFSIElOQ0xVREVTCisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMg
VHJpZXMgdG8gZmluZCBpZiB0aGUgZmllbGQgTUVNQkVSIGV4aXN0cyBpbiB0eXBlIEFHR1IsIGFm
dGVyIGluY2x1ZGluZworIyBJTkNMVURFUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIgYWNj
b3JkaW5nbHkuCithY19mbl9jX2NoZWNrX21lbWJlciAoKQoreworICBhc19saW5lbm89JHthc19s
aW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0
YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICQyLiQzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4kMy4uLiAiID4mNjsg
fQoraWYgZXZhbCAidGVzdCBcIlwkeyQ0K3NldH1cIiIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNQoraW50CittYWluICgp
Cit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChhY19hZ2dyLiQzKQorcmV0dXJuIDA7CisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgZXZhbCAiJDQ9eWVzIgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNQoraW50Citt
YWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChzaXplb2YgYWNfYWdnci4kMykKK3Jl
dHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwgIiQ0PXllcyIKK2Vsc2UKKyAgZXZhbCAiJDQ9
bm8iCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25m
dGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkNAorCSAgICAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1
CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVz
dCAieCRhc19saW5lbm9fc3RhY2siID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVu
bzt9CisKK30gIyBhY19mbl9jX2NoZWNrX21lbWJlcgorCisjIGFjX2ZuX2NfZmluZF91aW50WF90
IExJTkVOTyBCSVRTIFZBUgorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
KyMgRmluZHMgYW4gdW5zaWduZWQgaW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGlu
ZyBjYWNoZSB2YXJpYWJsZSBWQVIKKyMgYWNjb3JkaW5nbHkuCithY19mbl9jX2ZpbmRfdWludFhf
dCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFz
X2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHVpbnQkMl90IiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciB1aW50JDJfdC4uLiAiID4mNjsgfQoraWYgZXZhbCAidGVzdCBcIlwkeyQz
K3NldH1cIiIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBldmFsICIkMz1ubyIKKyAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVj
ayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCisgICAgICMgdGhhbiBoYWxmIG9m
IHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCisgICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90
ICd1bnNpZ25lZCBpbnQnICd1bnNpZ25lZCBsb25nIGludCcgXAorCSAndW5zaWduZWQgbG9uZyBs
b25nIGludCcgJ3Vuc2lnbmVkIHNob3J0IGludCcgJ3Vuc2lnbmVkIGNoYXInOyBkbworICAgICAg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK21haW4gKCkKK3sKK3N0YXRp
YyBpbnQgdGVzdF9hcnJheSBbMSAtIDIgKiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAx
KSkgPj4gKCQyIC8gMiAtIDEpID09IDMpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAg
cmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgY2FzZSAkYWNfdHlwZSBpbiAjKAorICB1aW50JDJfdCkgOgorICAgIGV2YWwgIiQz
PXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6CisK
K2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAg
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
cmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0
YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQg
YXNfbGluZW5vO30KKworfSAjIGFjX2ZuX2NfZmluZF91aW50WF90CitjYXQgPmNvbmZpZy5sb2cg
PDxfQUNFT0YKK1RoaXMgZmlsZSBjb250YWlucyBhbnkgbWVzc2FnZXMgcHJvZHVjZWQgYnkgY29t
cGlsZXJzIHdoaWxlCitydW5uaW5nIGNvbmZpZ3VyZSwgdG8gYWlkIGRlYnVnZ2luZyBpZiBjb25m
aWd1cmUgbWFrZXMgYSBtaXN0YWtlLgorCitJdCB3YXMgY3JlYXRlZCBieSAkYXNfbWUsIHdoaWNo
IHdhcworZ2VuZXJhdGVkIGJ5IEdOVSBBdXRvY29uZiAyLjY3LiAgSW52b2NhdGlvbiBjb21tYW5k
IGxpbmUgd2FzCisKKyAgJCAkMCAkQAorCitfQUNFT0YKK2V4ZWMgNT4+Y29uZmlnLmxvZworewor
Y2F0IDw8X0FTVU5BTUUKKyMjIC0tLS0tLS0tLSAjIworIyMgUGxhdGZvcm0uICMjCisjIyAtLS0t
LS0tLS0gIyMKKworaG9zdG5hbWUgPSBgKGhvc3RuYW1lIHx8IHVuYW1lIC1uKSAyPi9kZXYvbnVs
bCB8IHNlZCAxcWAKK3VuYW1lIC1tID0gYCh1bmFtZSAtbSkgMj4vZGV2L251bGwgfHwgZWNobyB1
bmtub3duYAordW5hbWUgLXIgPSBgKHVuYW1lIC1yKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25v
d25gCit1bmFtZSAtcyA9IGAodW5hbWUgLXMpIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAK
K3VuYW1lIC12ID0gYCh1bmFtZSAtdikgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAorCisv
dXNyL2Jpbi91bmFtZSAtcCA9IGAoL3Vzci9iaW4vdW5hbWUgLXApIDI+L2Rldi9udWxsIHx8IGVj
aG8gdW5rbm93bmAKKy9iaW4vdW5hbWUgLVggICAgID0gYCgvYmluL3VuYW1lIC1YKSAyPi9kZXYv
bnVsbCAgICAgfHwgZWNobyB1bmtub3duYAorCisvYmluL2FyY2ggICAgICAgICAgICAgID0gYCgv
YmluL2FyY2gpIDI+L2Rldi9udWxsICAgICAgICAgICAgICB8fCBlY2hvIHVua25vd25gCisvdXNy
L2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jpbi9hcmNoIC1rKSAyPi9kZXYvbnVsbCAgICAg
ICB8fCBlY2hvIHVua25vd25gCisvdXNyL2NvbnZleC9nZXRzeXNpbmZvID0gYCgvdXNyL2NvbnZl
eC9nZXRzeXNpbmZvKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCisvdXNyL2Jpbi9ob3N0
aW5mbyAgICAgID0gYCgvdXNyL2Jpbi9ob3N0aW5mbykgMj4vZGV2L251bGwgICAgICB8fCBlY2hv
IHVua25vd25gCisvYmluL21hY2hpbmUgICAgICAgICAgID0gYCgvYmluL21hY2hpbmUpIDI+L2Rl
di9udWxsICAgICAgICAgICB8fCBlY2hvIHVua25vd25gCisvdXNyL2Jpbi9vc2xldmVsICAgICAg
ID0gYCgvdXNyL2Jpbi9vc2xldmVsKSAyPi9kZXYvbnVsbCAgICAgICB8fCBlY2hvIHVua25vd25g
CisvYmluL3VuaXZlcnNlICAgICAgICAgID0gYCgvYmluL3VuaXZlcnNlKSAyPi9kZXYvbnVsbCAg
ICAgICAgICB8fCBlY2hvIHVua25vd25gCisKK19BU1VOQU1FCisKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAkYXNfZWNobyAi
UEFUSDogJGFzX2RpciIKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCit9ID4mNQorCitjYXQg
PiY1IDw8X0FDRU9GCisKKworIyMgLS0tLS0tLS0tLS0gIyMKKyMjIENvcmUgdGVzdHMuICMjCisj
IyAtLS0tLS0tLS0tLSAjIworCitfQUNFT0YKKworCisjIEtlZXAgYSB0cmFjZSBvZiB0aGUgY29t
bWFuZCBsaW5lLgorIyBTdHJpcCBvdXQgLS1uby1jcmVhdGUgYW5kIC0tbm8tcmVjdXJzaW9uIHNv
IHRoZXkgZG8gbm90IHBpbGUgdXAuCisjIFN0cmlwIG91dCAtLXNpbGVudCBiZWNhdXNlIHdlIGRv
bid0IHdhbnQgdG8gcmVjb3JkIGl0IGZvciBmdXR1cmUgcnVucy4KKyMgQWxzbyBxdW90ZSBhbnkg
YXJncyBjb250YWluaW5nIHNoZWxsIG1ldGEtY2hhcmFjdGVycy4KKyMgTWFrZSB0d28gcGFzc2Vz
IHRvIGFsbG93IGZvciBwcm9wZXIgZHVwbGljYXRlLWFyZ3VtZW50IHN1cHByZXNzaW9uLgorYWNf
Y29uZmlndXJlX2FyZ3M9CithY19jb25maWd1cmVfYXJnczA9CithY19jb25maWd1cmVfYXJnczE9
CithY19tdXN0X2tlZXBfbmV4dD1mYWxzZQorZm9yIGFjX3Bhc3MgaW4gMSAyCitkbworICBmb3Ig
YWNfYXJnCisgIGRvCisgICAgY2FzZSAkYWNfYXJnIGluCisgICAgLW5vLWNyZWF0ZSB8IC0tbm8t
YyogfCAtbiB8IC1uby1yZWN1cnNpb24gfCAtLW5vLXIqKSBjb250aW51ZSA7OworICAgIC1xIHwg
LXF1aWV0IHwgLS1xdWlldCB8IC0tcXVpZSB8IC0tcXVpIHwgLS1xdSB8IC0tcSBcCisgICAgfCAt
c2lsZW50IHwgLS1zaWxlbnQgfCAtLXNpbGVuIHwgLS1zaWxlIHwgLS1zaWwpCisgICAgICBjb250
aW51ZSA7OworICAgICpcJyopCisgICAgICBhY19hcmc9YCRhc19lY2hvICIkYWNfYXJnIiB8IHNl
ZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAgIGVzYWMKKyAgICBjYXNlICRhY19wYXNzIGlu
CisgICAgMSkgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ3VyZV9hcmdzMCAiICckYWNfYXJnJyIgOzsK
KyAgICAyKQorICAgICAgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ3VyZV9hcmdzMSAiICckYWNfYXJn
JyIKKyAgICAgIGlmIHRlc3QgJGFjX211c3Rfa2VlcF9uZXh0ID0gdHJ1ZTsgdGhlbgorCWFjX211
c3Rfa2VlcF9uZXh0PWZhbHNlICMgR290IHZhbHVlLCBiYWNrIHRvIG5vcm1hbC4KKyAgICAgIGVs
c2UKKwljYXNlICRhY19hcmcgaW4KKwkgICo9KiB8IC0tY29uZmlnLWNhY2hlIHwgLUMgfCAtZGlz
YWJsZS0qIHwgLS1kaXNhYmxlLSogXAorCSAgfCAtZW5hYmxlLSogfCAtLWVuYWJsZS0qIHwgLWdh
cyB8IC0tZyogfCAtbmZwIHwgLS1uZiogXAorCSAgfCAtcSB8IC1xdWlldCB8IC0tcSogfCAtc2ls
ZW50IHwgLS1zaWwqIHwgLXYgfCAtdmVyYiogXAorCSAgfCAtd2l0aC0qIHwgLS13aXRoLSogfCAt
d2l0aG91dC0qIHwgLS13aXRob3V0LSogfCAtLXgpCisJICAgIGNhc2UgIiRhY19jb25maWd1cmVf
YXJnczAgIiBpbgorCSAgICAgICIkYWNfY29uZmlndXJlX2FyZ3MxIioiICckYWNfYXJnJyAiKiAp
IGNvbnRpbnVlIDs7CisJICAgIGVzYWMKKwkgICAgOzsKKwkgIC0qICkgYWNfbXVzdF9rZWVwX25l
eHQ9dHJ1ZSA7OworCWVzYWMKKyAgICAgIGZpCisgICAgICBhc19mbl9hcHBlbmQgYWNfY29uZmln
dXJlX2FyZ3MgIiAnJGFjX2FyZyciCisgICAgICA7OworICAgIGVzYWMKKyAgZG9uZQorZG9uZQor
eyBhY19jb25maWd1cmVfYXJnczA9OyB1bnNldCBhY19jb25maWd1cmVfYXJnczA7fQoreyBhY19j
b25maWd1cmVfYXJnczE9OyB1bnNldCBhY19jb25maWd1cmVfYXJnczE7fQorCisjIFdoZW4gaW50
ZXJydXB0ZWQgb3IgZXhpdCdkLCBjbGVhbnVwIHRlbXBvcmFyeSBmaWxlcywgYW5kIGNvbXBsZXRl
CisjIGNvbmZpZy5sb2cuICBXZSByZW1vdmUgY29tbWVudHMgYmVjYXVzZSBhbnl3YXkgdGhlIHF1
b3RlcyBpbiB0aGVyZQorIyB3b3VsZCBjYXVzZSBwcm9ibGVtcyBvciBsb29rIHVnbHkuCisjIFdB
Uk5JTkc6IFVzZSAnXCcnIHRvIHJlcHJlc2VudCBhbiBhcG9zdHJvcGhlIHdpdGhpbiB0aGUgdHJh
cC4KKyMgV0FSTklORzogRG8gbm90IHN0YXJ0IHRoZSB0cmFwIGNvZGUgd2l0aCBhIG5ld2xpbmUs
IGR1ZSB0byBhIEZyZWVCU0QgNC4wIGJ1Zy4KK3RyYXAgJ2V4aXRfc3RhdHVzPSQ/CisgICMgU2F2
ZSBpbnRvIGNvbmZpZy5sb2cgc29tZSBpbmZvcm1hdGlvbiB0aGF0IG1pZ2h0IGhlbHAgaW4gZGVi
dWdnaW5nLgorICB7CisgICAgZWNobworCisgICAgJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0t
LS0gIyMKKyMjIENhY2hlIHZhcmlhYmxlcy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0gIyMiCisg
ICAgZWNobworICAgICMgVGhlIGZvbGxvd2luZyB3YXkgb2Ygd3JpdGluZyB0aGUgY2FjaGUgbWlz
aGFuZGxlcyBuZXdsaW5lcyBpbiB2YWx1ZXMsCisoCisgIGZvciBhY192YXIgaW4gYChzZXQpIDI+
JjEgfCBzZWQgLW4gJ1wnJ3MvXlwoW2EtekEtWl9dW2EtekEtWjAtOV9dKlwpPS4qL1wxL3AnXCcn
YDsgZG8KKyAgICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgICBjYXNlICRhY192YWwgaW4gIygK
KyAgICAqJHthc19ubH0qKQorICAgICAgY2FzZSAkYWNfdmFyIGluICMoCisgICAgICAqX2N2Xyop
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogY2FjaGUg
dmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4m
Mjt9IDs7CisgICAgICBlc2FjCisgICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgIF8gfCBJ
RlMgfCBhc19ubCkgOzsgIygKKyAgICAgIEJBU0hfQVJHViB8IEJBU0hfU09VUkNFKSBldmFsICRh
Y192YXI9IDs7ICMoCisgICAgICAqKSB7IGV2YWwgJGFjX3Zhcj07IHVuc2V0ICRhY192YXI7fSA7
OworICAgICAgZXNhYyA7OworICAgIGVzYWMKKyAgZG9uZQorICAoc2V0KSAyPiYxIHwKKyAgICBj
YXNlICRhc19ubGAoYWNfc3BhY2U9J1wnJyAnXCcnOyBzZXQpIDI+JjFgIGluICMoCisgICAgKiR7
YXNfbmx9YWNfc3BhY2U9XCAqKQorICAgICAgc2VkIC1uIFwKKwkicy8nXCcnLydcJydcXFxcJ1wn
JydcJycvZzsKKwkgIHMvXlxcKFtfJGFzX2NyX2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKlxc
KT1cXCguKlxcKS9cXDE9J1wnJ1xcMidcJycvcCIKKyAgICAgIDs7ICMoCisgICAgKikKKyAgICAg
IHNlZCAtbiAiL15bXyRhc19jcl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisgICAg
ICA7OworICAgIGVzYWMgfAorICAgIHNvcnQKKykKKyAgICBlY2hvCisKKyAgICAkYXNfZWNobyAi
IyMgLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE91dHB1dCB2YXJpYWJsZXMuICMjCisjIyAtLS0t
LS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisgICAgZm9yIGFjX3ZhciBpbiAkYWNfc3Vic3Rf
dmFycworICAgIGRvCisgICAgICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgICAgIGNhc2UgJGFj
X3ZhbCBpbgorICAgICAgKlwnXCcnKikgYWNfdmFsPWAkYXNfZWNobyAiJGFjX3ZhbCIgfCBzZWQg
InMvJ1wnJy8nXCcnXFxcXFxcXFwnXCcnJ1wnJy9nImA7OworICAgICAgZXNhYworICAgICAgJGFz
X2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwnXCcnIgorICAgIGRvbmUgfCBzb3J0CisgICAgZWNo
bworCisgICAgaWYgdGVzdCAtbiAiJGFjX3N1YnN0X2ZpbGVzIjsgdGhlbgorICAgICAgJGFzX2Vj
aG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIEZpbGUgc3Vic3RpdHV0aW9ucy4gIyMK
KyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMiCisgICAgICBlY2hvCisgICAgICBmb3IgYWNfdmFy
IGluICRhY19zdWJzdF9maWxlcworICAgICAgZG8KKwlldmFsIGFjX3ZhbD1cJCRhY192YXIKKwlj
YXNlICRhY192YWwgaW4KKwkqXCdcJycqKSBhY192YWw9YCRhc19lY2hvICIkYWNfdmFsIiB8IHNl
ZCAicy8nXCcnLydcJydcXFxcXFxcXCdcJycnXCcnL2ciYDs7CisJZXNhYworCSRhc19lY2hvICIk
YWNfdmFyPSdcJyckYWNfdmFsJ1wnJyIKKyAgICAgIGRvbmUgfCBzb3J0CisgICAgICBlY2hvCisg
ICAgZmkKKworICAgIGlmIHRlc3QgLXMgY29uZmRlZnMuaDsgdGhlbgorICAgICAgJGFzX2VjaG8g
IiMjIC0tLS0tLS0tLS0tICMjCisjIyBjb25mZGVmcy5oLiAjIworIyMgLS0tLS0tLS0tLS0gIyMi
CisgICAgICBlY2hvCisgICAgICBjYXQgY29uZmRlZnMuaAorICAgICAgZWNobworICAgIGZpCisg
ICAgdGVzdCAiJGFjX3NpZ25hbCIgIT0gMCAmJgorICAgICAgJGFzX2VjaG8gIiRhc19tZTogY2F1
Z2h0IHNpZ25hbCAkYWNfc2lnbmFsIgorICAgICRhc19lY2hvICIkYXNfbWU6IGV4aXQgJGV4aXRf
c3RhdHVzIgorICB9ID4mNQorICBybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogJiYK
KyAgICBybSAtZiAtciBjb25mdGVzdCogY29uZmRlZnMqIGNvbmYkJCogJGFjX2NsZWFuX2ZpbGVz
ICYmCisgICAgZXhpdCAkZXhpdF9zdGF0dXMKKycgMAorZm9yIGFjX3NpZ25hbCBpbiAxIDIgMTMg
MTU7IGRvCisgIHRyYXAgJ2FjX3NpZ25hbD0nJGFjX3NpZ25hbCc7IGFzX2ZuX2V4aXQgMScgJGFj
X3NpZ25hbAorZG9uZQorYWNfc2lnbmFsPTAKKworIyBjb25mZGVmcy5oIGF2b2lkcyBPUyBjb21t
YW5kIGxpbmUgbGVuZ3RoIGxpbWl0cyB0aGF0IERFRlMgY2FuIGV4Y2VlZC4KK3JtIC1mIC1yIGNv
bmZ0ZXN0KiBjb25mZGVmcy5oCisKKyRhc19lY2hvICIvKiBjb25mZGVmcy5oICovIiA+IGNvbmZk
ZWZzLmgKKworIyBQcmVkZWZpbmVkIHByZXByb2Nlc3NvciB2YXJpYWJsZXMuCisKK2NhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9OQU1FICIkUEFDS0FHRV9OQU1FIgor
X0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9UQVJO
QU1FICIkUEFDS0FHRV9UQVJOQU1FIgorX0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKKyNkZWZpbmUgUEFDS0FHRV9WRVJTSU9OICIkUEFDS0FHRV9WRVJTSU9OIgorX0FDRU9GCisK
K2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9TVFJJTkcgIiRQQUNL
QUdFX1NUUklORyIKK19BQ0VPRgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IFBBQ0tBR0VfQlVHUkVQT1JUICIkUEFDS0FHRV9CVUdSRVBPUlQiCitfQUNFT0YKKworY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1VSTCAiJFBBQ0tBR0VfVVJMIgor
X0FDRU9GCisKKworIyBMZXQgdGhlIHNpdGUgZmlsZSBzZWxlY3QgYW4gYWx0ZXJuYXRlIGNhY2hl
IGZpbGUgaWYgaXQgd2FudHMgdG8uCisjIFByZWZlciBhbiBleHBsaWNpdGx5IHNlbGVjdGVkIGZp
bGUgdG8gYXV0b21hdGljYWxseSBzZWxlY3RlZCBvbmVzLgorYWNfc2l0ZV9maWxlMT1OT05FCith
Y19zaXRlX2ZpbGUyPU5PTkUKK2lmIHRlc3QgLW4gIiRDT05GSUdfU0lURSI7IHRoZW4KKyAgIyBX
ZSBkbyBub3Qgd2FudCBhIFBBVEggc2VhcmNoIGZvciBjb25maWcuc2l0ZS4KKyAgY2FzZSAkQ09O
RklHX1NJVEUgaW4gIygoCisgICAgLSopICBhY19zaXRlX2ZpbGUxPS4vJENPTkZJR19TSVRFOzsK
KyAgICAqLyopIGFjX3NpdGVfZmlsZTE9JENPTkZJR19TSVRFOzsKKyAgICAqKSAgIGFjX3NpdGVf
ZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICBlc2FjCitlbGlmIHRlc3QgIngkcHJlZml4IiAhPSB4
Tk9ORTsgdGhlbgorICBhY19zaXRlX2ZpbGUxPSRwcmVmaXgvc2hhcmUvY29uZmlnLnNpdGUKKyAg
YWNfc2l0ZV9maWxlMj0kcHJlZml4L2V0Yy9jb25maWcuc2l0ZQorZWxzZQorICBhY19zaXRlX2Zp
bGUxPSRhY19kZWZhdWx0X3ByZWZpeC9zaGFyZS9jb25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUy
PSRhY19kZWZhdWx0X3ByZWZpeC9ldGMvY29uZmlnLnNpdGUKK2ZpCitmb3IgYWNfc2l0ZV9maWxl
IGluICIkYWNfc2l0ZV9maWxlMSIgIiRhY19zaXRlX2ZpbGUyIgorZG8KKyAgdGVzdCAieCRhY19z
aXRlX2ZpbGUiID0geE5PTkUgJiYgY29udGludWUKKyAgaWYgdGVzdCAvZGV2L251bGwgIT0gIiRh
Y19zaXRlX2ZpbGUiICYmIHRlc3QgLXIgIiRhY19zaXRlX2ZpbGUiOyB0aGVuCisgICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRh
Y19zaXRlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogbG9hZGluZyBzaXRlIHNjcmlwdCAk
YWNfc2l0ZV9maWxlIiA+JjY7fQorICAgIHNlZCAncy9eL3wgLycgIiRhY19zaXRlX2ZpbGUiID4m
NQorICAgIC4gIiRhY19zaXRlX2ZpbGUiIFwKKyAgICAgIHx8IHsgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8g
ImZhaWxlZCB0byBsb2FkIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUKK1NlZSBcYGNvbmZpZy5s
b2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICBmaQorZG9uZQorCitpZiB0
ZXN0IC1yICIkY2FjaGVfZmlsZSI7IHRoZW4KKyAgIyBTb21lIHZlcnNpb25zIG9mIGJhc2ggd2ls
bCBmYWlsIHRvIHNvdXJjZSAvZGV2L251bGwgKHNwZWNpYWwgZmlsZXMKKyAgIyBhY3R1YWxseSks
IHNvIHdlIGF2b2lkIGRvaW5nIHRoYXQuICBESkdQUCBlbXVsYXRlcyBpdCBhcyBhIHJlZ3VsYXIg
ZmlsZS4KKyAgaWYgdGVzdCAvZGV2L251bGwgIT0gIiRjYWNoZV9maWxlIiAmJiB0ZXN0IC1mICIk
Y2FjaGVfZmlsZSI7IHRoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGxvYWRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTog
bG9hZGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAgICBjYXNlICRjYWNoZV9maWxlIGlu
CisgICAgICBbXFwvXSogfCA/OltcXC9dKiApIC4gIiRjYWNoZV9maWxlIjs7CisgICAgICAqKSAg
ICAgICAgICAgICAgICAgICAgICAuICIuLyRjYWNoZV9maWxlIjs7CisgICAgZXNhYworICBmaQor
ZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNyZWF0aW5n
IGNhY2hlICRjYWNoZV9maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGNyZWF0aW5nIGNhY2hl
ICRjYWNoZV9maWxlIiA+JjY7fQorICA+JGNhY2hlX2ZpbGUKK2ZpCisKK2FzX2ZuX2FwcGVuZCBh
Y19oZWFkZXJfbGlzdCAiIHN5cy90aW1lLmgiCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3Qg
IiB1bmlzdGQuaCIKK2FzX2ZuX2FwcGVuZCBhY19mdW5jX2xpc3QgIiBhbGFybSIKK2FzX2ZuX2Fw
cGVuZCBhY19oZWFkZXJfbGlzdCAiIHN0ZGxpYi5oIgorYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9s
aXN0ICIgc3lzL3BhcmFtLmgiCisjIENoZWNrIHRoYXQgdGhlIHByZWNpb3VzIHZhcmlhYmxlcyBz
YXZlZCBpbiB0aGUgY2FjaGUgaGF2ZSBrZXB0IHRoZSBzYW1lCisjIHZhbHVlLgorYWNfY2FjaGVf
Y29ycnVwdGVkPWZhbHNlCitmb3IgYWNfdmFyIGluICRhY19wcmVjaW91c192YXJzOyBkbworICBl
dmFsIGFjX29sZF9zZXQ9XCRhY19jdl9lbnZfJHthY192YXJ9X3NldAorICBldmFsIGFjX25ld19z
ZXQ9XCRhY19lbnZfJHthY192YXJ9X3NldAorICBldmFsIGFjX29sZF92YWw9XCRhY19jdl9lbnZf
JHthY192YXJ9X3ZhbHVlCisgIGV2YWwgYWNfbmV3X3ZhbD1cJGFjX2Vudl8ke2FjX3Zhcn1fdmFs
dWUKKyAgY2FzZSAkYWNfb2xkX3NldCwkYWNfbmV3X3NldCBpbgorICAgIHNldCwpCisgICAgICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBcYCRhY192YXIn
IHdhcyBzZXQgdG8gXGAkYWNfb2xkX3ZhbCcgaW4gdGhlIHByZXZpb3VzIHJ1biIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgc2V0IHRvIFxgJGFjX29sZF92YWwn
IGluIHRoZSBwcmV2aW91cyBydW4iID4mMjt9CisgICAgICBhY19jYWNoZV9jb3JydXB0ZWQ9OiA7
OworICAgICxzZXQpCisgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBcYCRhY192YXInIHdhcyBub3Qgc2V0IGluIHRoZSBwcmV2aW91cyBydW4iID4m
NQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IFxgJGFjX3Zhcicgd2FzIG5vdCBzZXQgaW4gdGhl
IHByZXZpb3VzIHJ1biIgPiYyO30KKyAgICAgIGFjX2NhY2hlX2NvcnJ1cHRlZD06IDs7CisgICAg
LCk7OworICAgICopCisgICAgICBpZiB0ZXN0ICJ4JGFjX29sZF92YWwiICE9ICJ4JGFjX25ld192
YWwiOyB0aGVuCisJIyBkaWZmZXJlbmNlcyBpbiB3aGl0ZXNwYWNlIGRvIG5vdCBsZWFkIHRvIGZh
aWx1cmUuCisJYWNfb2xkX3ZhbF93PWBlY2hvIHggJGFjX29sZF92YWxgCisJYWNfbmV3X3ZhbF93
PWBlY2hvIHggJGFjX25ld192YWxgCisJaWYgdGVzdCAiJGFjX29sZF92YWxfdyIgIT0gIiRhY19u
ZXdfdmFsX3ciOyB0aGVuCisJICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBcYCRhY192YXInIGhhcyBjaGFuZ2VkIHNpbmNlIHRoZSBwcmV2aW91cyBydW46
IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBcYCRhY192YXInIGhhcyBjaGFuZ2VkIHNp
bmNlIHRoZSBwcmV2aW91cyBydW46IiA+JjI7fQorCSAgYWNfY2FjaGVfY29ycnVwdGVkPToKKwll
bHNlCisJICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHdhcm5pbmc6
IGlnbm9yaW5nIHdoaXRlc3BhY2UgY2hhbmdlcyBpbiBcYCRhY192YXInIHNpbmNlIHRoZSBwcmV2
aW91cyBydW46IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IHdhcm5pbmc6IGlnbm9yaW5nIHdoaXRl
c3BhY2UgY2hhbmdlcyBpbiBcYCRhY192YXInIHNpbmNlIHRoZSBwcmV2aW91cyBydW46IiA+JjI7
fQorCSAgZXZhbCAkYWNfdmFyPVwkYWNfb2xkX3ZhbAorCWZpCisJeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiAgIGZvcm1lciB2YWx1ZTogIFxgJGFjX29sZF92YWwnIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6ICAgZm9ybWVyIHZhbHVlOiAgXGAkYWNfb2xkX3ZhbCciID4m
Mjt9CisJeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAgIGN1cnJlbnQg
dmFsdWU6IFxgJGFjX25ld192YWwnIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6ICAgY3VycmVudCB2
YWx1ZTogXGAkYWNfbmV3X3ZhbCciID4mMjt9CisgICAgICBmaTs7CisgIGVzYWMKKyAgIyBQYXNz
IHByZWNpb3VzIHZhcmlhYmxlcyB0byBjb25maWcuc3RhdHVzLgorICBpZiB0ZXN0ICIkYWNfbmV3
X3NldCIgPSBzZXQ7IHRoZW4KKyAgICBjYXNlICRhY19uZXdfdmFsIGluCisgICAgKlwnKikgYWNf
YXJnPSRhY192YXI9YCRhc19lY2hvICIkYWNfbmV3X3ZhbCIgfCBzZWQgInMvJy8nXFxcXFxcXFwn
Jy9nImAgOzsKKyAgICAqKSBhY19hcmc9JGFjX3Zhcj0kYWNfbmV3X3ZhbCA7OworICAgIGVzYWMK
KyAgICBjYXNlICIgJGFjX2NvbmZpZ3VyZV9hcmdzICIgaW4KKyAgICAgICoiICckYWNfYXJnJyAi
KikgOzsgIyBBdm9pZCBkdXBzLiAgVXNlIG9mIHF1b3RlcyBlbnN1cmVzIGFjY3VyYWN5LgorICAg
ICAgKikgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ3VyZV9hcmdzICIgJyRhY19hcmcnIiA7OworICAg
IGVzYWMKKyAgZmkKK2RvbmUKK2lmICRhY19jYWNoZV9jb3JydXB0ZWQ7IHRoZW4KKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBjaGFuZ2VzIGlu
IHRoZSBlbnZpcm9ubWVudCBjYW4gY29tcHJvbWlzZSB0aGUgYnVpbGQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogZXJyb3I6IGNoYW5nZXMgaW4gdGhlIGVudmlyb25tZW50IGNhbiBjb21wcm9taXNl
IHRoZSBidWlsZCIgPiYyO30KKyAgYXNfZm5fZXJyb3IgJD8gInJ1biBcYG1ha2UgZGlzdGNsZWFu
JyBhbmQvb3IgXGBybSAkY2FjaGVfZmlsZScgYW5kIHN0YXJ0IG92ZXIiICIkTElORU5PIiA1Citm
aQorIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE1haW4gYm9keSBvZiBzY3JpcHQuICMj
CisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworCithY19leHQ9YworYWNfY3BwPSckQ1BQICRD
UFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4k
YWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAk
Q1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19jb21waWxl
cl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKworCithY19jb25maWdfZmlsZXM9IiRhY19j
b25maWdfZmlsZXMgLi4vY29uZmlnL1Rvb2xzLm1rIgorCithY19jb25maWdfaGVhZGVycz0iJGFj
X2NvbmZpZ19oZWFkZXJzIGNvbmZpZy5oIgorCisKK2FjX2F1eF9kaXI9Citmb3IgYWNfZGlyIGlu
IC4gIiRzcmNkaXIiLy47IGRvCisgIGlmIHRlc3QgLWYgIiRhY19kaXIvaW5zdGFsbC1zaCI7IHRo
ZW4KKyAgICBhY19hdXhfZGlyPSRhY19kaXIKKyAgICBhY19pbnN0YWxsX3NoPSIkYWNfYXV4X2Rp
ci9pbnN0YWxsLXNoIC1jIgorICAgIGJyZWFrCisgIGVsaWYgdGVzdCAtZiAiJGFjX2Rpci9pbnN0
YWxsLnNoIjsgdGhlbgorICAgIGFjX2F1eF9kaXI9JGFjX2RpcgorICAgIGFjX2luc3RhbGxfc2g9
IiRhY19hdXhfZGlyL2luc3RhbGwuc2ggLWMiCisgICAgYnJlYWsKKyAgZWxpZiB0ZXN0IC1mICIk
YWNfZGlyL3NodG9vbCI7IHRoZW4KKyAgICBhY19hdXhfZGlyPSRhY19kaXIKKyAgICBhY19pbnN0
YWxsX3NoPSIkYWNfYXV4X2Rpci9zaHRvb2wgaW5zdGFsbCAtYyIKKyAgICBicmVhaworICBmaQor
ZG9uZQoraWYgdGVzdCAteiAiJGFjX2F1eF9kaXIiOyB0aGVuCisgIGFzX2ZuX2Vycm9yICQ/ICJj
YW5ub3QgZmluZCBpbnN0YWxsLXNoLCBpbnN0YWxsLnNoLCBvciBzaHRvb2wgaW4gLiBcIiRzcmNk
aXJcIi8uIiAiJExJTkVOTyIgNQorZmkKKworIyBUaGVzZSB0aHJlZSB2YXJpYWJsZXMgYXJlIHVu
ZG9jdW1lbnRlZCBhbmQgdW5zdXBwb3J0ZWQsCisjIGFuZCBhcmUgaW50ZW5kZWQgdG8gYmUgd2l0
aGRyYXduIGluIGEgZnV0dXJlIEF1dG9jb25mIHJlbGVhc2UuCisjIFRoZXkgY2FuIGNhdXNlIHNl
cmlvdXMgcHJvYmxlbXMgaWYgYSBidWlsZGVyJ3Mgc291cmNlIHRyZWUgaXMgaW4gYSBkaXJlY3Rv
cnkKKyMgd2hvc2UgZnVsbCBuYW1lIGNvbnRhaW5zIHVudXN1YWwgY2hhcmFjdGVycy4KK2FjX2Nv
bmZpZ19ndWVzcz0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5ndWVzcyIgICMgUGxlYXNlIGRv
bid0IHVzZSB0aGlzIHZhci4KK2FjX2NvbmZpZ19zdWI9IiRTSEVMTCAkYWNfYXV4X2Rpci9jb25m
aWcuc3ViIiAgIyBQbGVhc2UgZG9uJ3QgdXNlIHRoaXMgdmFyLgorYWNfY29uZmlndXJlPSIkU0hF
TEwgJGFjX2F1eF9kaXIvY29uZmlndXJlIiAgIyBQbGVhc2UgZG9uJ3QgdXNlIHRoaXMgdmFyLgor
CisKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBp
cyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitpZiB0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxB
R1MkTElCUyRDUFBGTEFHUyRDUFAiOyB0aGVuIDoKKworICAgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdT
LCBMSUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVO
RF9JTkNMVURFUywgUFJFUEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJ
QiBpbnN0ZWFkIHdoZW4gcG9zc2libGUuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IFNldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5v
dCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitB
UFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLiIgPiYy
O30KKworZmkKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxl
PSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5r
PSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNv
bmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBp
bGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3Qg
dGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsg
YWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0Mi
OyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KKyAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgorICBh
Y19jdF9DQz0kQ0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3Rf
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9
JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lm
IHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0ND
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3Qg
IngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9z
c19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQor
YWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNl
CisgIENDPSIkYWNfY3ZfcHJvZ19DQyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAg
ICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBh
Y193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRD
QyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKKyAgZmkKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0
aCBhcmdzLgorc2V0IGR1bW15IGNjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKKyAgYWNfcHJvZ19yZWplY3RlZD1u
bworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAk
UEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k
aXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgaWYg
dGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVu
CisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAgICAgICBjb250aW51ZQorICAgICBmaQor
ICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitpZiB0ZXN0ICRh
Y19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91bmQgYSBib2dvbiBpbiB0aGUg
cGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAgc2V0IGR1bW15ICRhY19jdl9w
cm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgorICAgICMgV2UgY2hvc2Ug
YSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgorICAgICMgSG93ZXZlciwg
aXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KKyAg
ICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRoZSBmdWxs
IGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dv
cmQkezErJyAnfSRAIgorICBmaQorZmkKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisg
IGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgZm9yIGFjX3Byb2cgaW4gY2wu
ZXhlCisgIGRvCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9vbF9wcmVm
aXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth
Y19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIk
Q0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9
JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZT
PSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBh
Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJGFj
X3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9
JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJEND
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICB0ZXN0
IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisg
IGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKK2RvCisgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg
d2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7
YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRlc3QgLW4gIiRhY19jdF9D
QyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAg
ICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0ZXN0IC16ICIkQ0MiICYm
IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsg
fQorCisjIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCiskYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxl
ciB2ZXJzaW9uIiA+JjUKK3NldCBYICRhY19jb21waWxlCithY19jb21waWxlcj0kMgorZm9yIGFj
X29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbworICB7IHsgYWNfdHJ5PSIk
YWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiog
fCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0k
YWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUK
KyAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3QuZXJyCisg
IGFjX3N0YXR1cz0kPworICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgorICAgIHNlZCAn
MTBhXAorLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgorICAgICAgICAgMTBx
JyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1Cisg
IGZpCisgIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFj
X3N0YXR1cyA9IDA7IH0KK2RvbmUKKworY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCithY19jbGVhbl9maWxlc19zYXZlPSRhY19jbGVh
bl9maWxlcworYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9maWxlcyBhLm91dCBhLm91dC5kU1lN
IGEuZXhlIGIub3V0IgorIyBUcnkgdG8gY3JlYXRlIGFuIGV4ZWN1dGFibGUgd2l0aG91dCAtbyBm
aXJzdCwgZGlzcmVnYXJkIGEub3V0LgorIyBJdCB3aWxsIGhlbHAgdXMgZGlhZ25vc2UgYnJva2Vu
IGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGludHVpdGlvbgorIyBvZiBleGVleHQuCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIg
dGhlIEMgY29tcGlsZXIgd29ya3MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0
aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsgfQorYWNfbGlua19kZWZhdWx0PWAkYXNfZWNo
byAiJGFjX2xpbmsiIHwgc2VkICdzLyAtbyAqY29uZnRlc3RbXiBdKi8vJ2AKKworIyBUaGUgcG9z
c2libGUgb3V0cHV0IGZpbGVzOgorYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVz
dCBhLmV4ZSBhX291dC5leGUgYi5vdXQgY29uZnRlc3QuKiIKKworYWNfcm1maWxlcz0KK2ZvciBh
Y19maWxlIGluICRhY19maWxlcworZG8KKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4
dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJn
IHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKKyAgICAqICkgYWNf
cm1maWxlcz0iJGFjX3JtZmlsZXMgJGFjX2ZpbGUiOzsKKyAgZXNhYworZG9uZQorcm0gLWYgJGFj
X3JtZmlsZXMKKworaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKK2Nhc2UgIigoJGFj
X3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cisg
ICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNf
dHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmtfZGVmYXVsdCIpIDI+JjUKKyAgYWNf
c3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBB
dXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3ZfZXhlZXh0IHZhcmlhYmxlIHRvIGBubycu
CisjIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBubycsIG90aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQg
dG8gYEVYRUVYVCA9IG5vJworIyBpbiBhIE1ha2VmaWxlLiAgV2Ugc2hvdWxkIG5vdCBvdmVycmlk
ZSBhY19jdl9leGVleHQgaWYgaXQgd2FzIGNhY2hlZCwKKyMgc28gdGhhdCB0aGUgdXNlciBjYW4g
c2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9yIGNvbXBpbGVycyB1bmtub3duIHRvCisjIEF1dG9j
b25mLgorZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzICcnCitkbworICB0ZXN0IC1mICIkYWNfZmls
ZSIgfHwgY29udGludWUKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNv
ZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAg
fCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkKKwk7OworICAgIFthYl0ub3V0ICkKKwkj
IFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMgbW9zdAor
CSMgY2VydGFpbmx5IHJpZ2h0LgorCWJyZWFrOzsKKyAgICAqLiogKQorCWlmIHRlc3QgIiR7YWNf
Y3ZfZXhlZXh0K3NldH0iID0gc2V0ICYmIHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5vOworCXRo
ZW4gOjsgZWxzZQorCSAgIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChc
Li4qXCknYAorCWZpCisJIyBXZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUgYmVjYXVzZSB0aGUgbGF0
ZXIgdGVzdCBmb3IgaXQgaXMgbm90CisJIyBzYWZlOiBjcm9zcyBjb21waWxlcnMgbWF5IG5vdCBh
ZGQgdGhlIHN1ZmZpeCBpZiBnaXZlbiBhbiBgLW8nCisJIyBhcmd1bWVudCwgc28gd2UgbWF5IG5l
ZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVhZHkuCisJIyBFdmVuIGlmIHRoaXMgc2Vj
dGlvbiBsb29rcyBjcnVmdHk6IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCisJIyBhY3R1YWxseSB3
b3JraW5nLgorCWJyZWFrOzsKKyAgICAqICkKKwlicmVhazs7CisgIGVzYWMKK2RvbmUKK3Rlc3Qg
IiRhY19jdl9leGVleHQiID0gbm8gJiYgYWNfY3ZfZXhlZXh0PQorCitlbHNlCisgIGFjX2ZpbGU9
JycKK2ZpCitpZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRoZW4gOgorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KKyRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQorc2VkICdz
L14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCit7IHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIk
YXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yIDc3ICJDIGNv
bXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJsZXMKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBt
b3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4m
NjsgfQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFtZS4uLiAi
ID4mNjsgfQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYWNfZmlsZSIgPiY2OyB9CithY19leGVleHQ9JGFj
X2N2X2V4ZWV4dAorCitybSAtZiAtciBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGNvbmZ0ZXN0JGFj
X2N2X2V4ZWV4dCBiLm91dAorYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZp
eCBvZiBleGVjdXRhYmxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igc3VmZml4IG9m
IGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9CitpZiB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2Ug
IigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry
eTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0i
XCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hv
ICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0
YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6CisgICMgSWYg
Ym90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNvbmZ0ZXN0JyBhcmUgYHByZXNlbnQnICh3ZWxsLCBv
YnNlcnZhYmxlKQorIyBjYXRjaCBgY29uZnRlc3QuZXhlJy4gIEZvciBpbnN0YW5jZSB3aXRoIEN5
Z3dpbiwgYGxzIGNvbmZ0ZXN0JyB3aWxsCisjIHdvcmsgcHJvcGVybHkgKGkuZS4sIHJlZmVyIHRv
IGBjb25mdGVzdC5leGUnKSwgd2hpbGUgaXQgd29uJ3Qgd2l0aAorIyBgcm0nLgorZm9yIGFjX2Zp
bGUgaW4gY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGNvbmZ0ZXN0Lio7IGRvCisgIHRlc3QgLWYgIiRh
Y19maWxlIiB8fCBjb250aW51ZQorICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwg
Ki54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAq
Lm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7OworICAgICouKiApIGFjX2N2
X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAorCSAgYnJlYWs7Owor
ICAgICogKSBicmVhazs7CisgIGVzYWMKK2RvbmUKK2Vsc2UKKyAgeyB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAk
PyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVzOiBjYW5ub3QgY29tcGlsZSBh
bmQgbGluaworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUg
OyB9CitmaQorcm0gLWYgY29uZnRlc3QgY29uZnRlc3QkYWNfY3ZfZXhlZXh0Cit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2V4ZWV4dCIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9CisKK3JtIC1mIGNvbmZ0ZXN0LiRhY19l
eHQKK0VYRUVYVD0kYWNfY3ZfZXhlZXh0CithY19leGVleHQ9JEVYRUVYVAorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
I2luY2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK0ZJTEUgKmYgPSBmb3BlbiAoImNv
bmZ0ZXN0Lm91dCIsICJ3Iik7CisgcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChmKSAhPSAw
OworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xl
YW5fZmlsZXMgY29uZnRlc3Qub3V0IgorIyBDaGVjayB0aGF0IHRoZSBjb21waWxlciBwcm9kdWNl
cyBleGVjdXRhYmxlcyB3ZSBjYW4gcnVuLiAgSWYgbm90LCBlaXRoZXIKKyMgdGhlIGNvbXBpbGVy
IGlzIGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5n
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGlu
Zy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgIT0geWVzOyB0aGVuCisg
IHsgeyBhY190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxg
KiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3Ry
eTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChl
dmFsICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19z
dGF0dXMgPSAwOyB9CisgIGlmIHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCcKKyAg
eyB7IGNhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNo
bz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190
cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIK
KyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX3RyeSIpIDI+JjUK
KyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9OyB0aGVu
CisgICAgY3Jvc3NfY29tcGlsaW5nPW5vCisgIGVsc2UKKyAgICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IG1heWJlOyB0aGVuCisJY3Jvc3NfY29tcGlsaW5nPXllcworICAgIGVsc2UKKwl7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFj
X3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMuCitJZiB5
b3UgbWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNlIFxgLS1ob3N0Jy4KK1NlZSBcYGNvbmZpZy5s
b2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAgIGZpCisgIGZpCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRjcm9zc19j
b21waWxpbmciID4mNQorJGFzX2VjaG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQorCitybSAt
ZiBjb25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5vdXQKK2Fj
X2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWlu
ICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorcm0gLWYgY29uZnRlc3QubyBj
b25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgorY2FzZSAiKCgkYWNfdHJ5
IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikg
YWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlf
ZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/
CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0
dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgZm9yIGFjX2ZpbGUg
aW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFj
X2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwg
Ki54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAq
Lm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAgICAqKSBhY19jdl9vYmpleHQ9YGV4cHIgIiRh
Y19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAgICBicmVhazs7CisgIGVzYWMKK2RvbmUKK2Vs
c2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3Mv
Xi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKK3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRh
c19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBjb21waWxlCitTZWUgXGBj
b25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KK2ZpCitybSAtZiBj
b25mdGVzdC4kYWNfY3Zfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X29iamV4dCIgPiY2OyB9CitPQkpFWFQ9JGFjX2N2X29iamV4dAorYWNf
b2JqZXh0PSRPQkpFWFQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxl
ci4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNl
dDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg
Ki8KKworaW50CittYWluICgpCit7CisjaWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hva2UgbWUK
KyNlbmRpZgorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2Nv
bXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY29tcGlsZXJfZ251PXllcworZWxzZQorICBh
Y19jb21waWxlcl9nbnU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2FjX2N2X2NfY29tcGlsZXJfZ251PSRhY19jb21w
aWxlcl9nbnUKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX2Nv
bXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7IHRoZW4K
KyAgR0NDPXllcworZWxzZQorICBHQ0M9CitmaQorYWNfdGVzdF9DRkxBR1M9JHtDRkxBR1Mrc2V0
fQorYWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9m
bGFnCisgICBhY19jX3dlcnJvcl9mbGFnPXllcworICAgYWNfY3ZfcHJvZ19jY19nPW5vCisgICBD
RkxBR1M9Ii1nIgorICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKK2Vsc2UKKyAgQ0ZMQUdTPSIiCisgICAgICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICBhY19j
X3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKKwkgQ0ZMQUdTPSItZyIKKwkgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2df
Y2NfZz15ZXMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9
JGFjX3NhdmVfY193ZXJyb3JfZmxhZworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfcHJvZ19jY19nIiA+JjY7IH0KK2lmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRo
ZW4KKyAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cg
PSB5ZXM7IHRoZW4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1n
IC1PMiIKKyAgZWxzZQorICAgIENGTEFHUz0iLWciCisgIGZpCitlbHNlCisgIGlmIHRlc3QgIiRH
Q0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItTzIiCisgIGVsc2UKKyAgICBDRkxBR1M9Cisg
IGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2N2X3Byb2dfY2NfYzg5PW5vCithY19zYXZlX0ND
PSRDQworY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+
CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKy8qIE1vc3Qg
b2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20gUkNTIDUuNydzIHNyYy9jb25m
LnNoLiAgKi8KK3N0cnVjdCBidWYgeyBpbnQgeDsgfTsKK0ZJTEUgKiAoKnJjc29wZW4pIChzdHJ1
Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7CitzdGF0aWMgY2hhciAqZSAocCwgaSkKKyAg
ICAgY2hhciAqKnA7CisgICAgIGludCBpOworeworICByZXR1cm4gcFtpXTsKK30KK3N0YXRpYyBj
aGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikKK3sKKyAg
Y2hhciAqczsKKyAgdmFfbGlzdCB2OworICB2YV9zdGFydCAodixwKTsKKyAgcyA9IGcgKHAsIHZh
X2FyZyAodixpbnQpKTsKKyAgdmFfZW5kICh2KTsKKyAgcmV0dXJuIHM7Cit9CisKKy8qIE9TRiA0
LjAgQ29tcGFxIGNjIGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQg
aGFzCisgICBmdW5jdGlvbiBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhISCcgaGV4
IGNoYXJhY3RlciBjb25zdGFudHMuCisgICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVu
Zm9ydHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKKyAgIGFzICd4Jy4gIFRo
ZSBmb2xsb3dpbmcgaW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQK
KyAgIHByb3BlciBBTlNJIG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlzIGNvbWVz
IG91dCB0cnVlLCBmb3IgYW4KKyAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vzc2Fy
eSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZworICAgdGhhdCdzIHRydWUgb25s
eSB3aXRoIC1zdGQuICAqLworaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8gMSA6IC0x
XTsKKworLyogSUJNIEMgNiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQsIGJ1dCBp
dCByZXBsYWNlcyBtYWNybyBwYXJhbWV0ZXJzCisgICBpbnNpZGUgc3RyaW5ncyBhbmQgY2hhcmFj
dGVyIGNvbnN0YW50cy4gICovCisjZGVmaW5lIEZPTyh4KSAneCcKK2ludCB4bGM2X2NjX2FycmF5
W0ZPTyhhKSA9PSAneCcgPyAxIDogLTFdOworCitpbnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsK
K3N0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Oworc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91
YmxlIGEpO307CitpbnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3Qg
YnVmICosIHN0cnVjdCBzdGF0ICosIGludCksIGludCwgaW50KTsKK2ludCBhcmdjOworY2hhciAq
KmFyZ3Y7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBd
ICB8fCAgZiAoZSwgYXJndiwgMSkgIT0gYXJndlsxXTsKKyAgOworICByZXR1cm4gMDsKK30KK19B
Q0VPRgorZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1hbnNpIC1z
dGQgXAorCS1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05TX18iCitk
bworICBDQz0iJGFjX3NhdmVfQ0MgJGFjX2FyZyIKKyAgaWYgYWNfZm5fY190cnlfY29tcGlsZSAi
JExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCitmaQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAorICB0ZXN0ICJ4JGFjX2N2X3By
b2dfY2NfYzg5IiAhPSAieG5vIiAmJiBicmVhaworZG9uZQorcm0gLWYgY29uZnRlc3QuJGFjX2V4
dAorQ0M9JGFjX3NhdmVfQ0MKKworZmkKKyMgQUNfQ0FDSEVfVkFMCitjYXNlICJ4JGFjX2N2X3By
b2dfY2NfYzg5IiBpbgorICB4KQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1CiskYXNfZWNobyAibm9uZSBuZWVkZWQi
ID4mNjsgfSA7OworICB4bm8pCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUKKyRhc19lY2hvICJ1bnN1cHBvcnRlZCIg
PiY2OyB9IDs7CisgICopCisgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCisgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9n
X2NjX2M4OSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0gOzsKK2Vz
YWMKK2lmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6CisKK2ZpCisK
K2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRD
RkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKKwor
CithY19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAk
Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBj
b25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFj
X2V4dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBy
dW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvdyB0byBy
dW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0aW1lcyAk
Q1BQIG5hbWVzIGEgZGlyZWN0b3J5LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQ
UCI7IHRoZW4KKyAgQ1BQPQorZmkKK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlmIHRlc3Qg
IiR7YWNfY3ZfcHJvZ19DUFArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICAgICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQIG5lZWRz
IHRvIGJlIGV4cGFuZGVkCisgICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRp
b25hbC1jcHAiICIvbGliL2NwcCIKKyAgICBkbworICAgICAgYWNfcHJlcHJvY19vaz1mYWxzZQor
Zm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRl
ciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0
aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRv
IDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+
IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQs
IGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMg
bm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhp
cyBjYXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRz
Lmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRpZgorCQkgICAgIFN5bnRheCBl
cnJvcgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxz
ZQorICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCitjb250aW51ZQorZmkKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3Jr
cyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycwor
ICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G
ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNf
bm9uZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxz
ZQorICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3Jt
IC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworZG9uZQorIyBC
ZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2Fz
IHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0
CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisgIGJyZWFrCitmaQorCisgICAgZG9uZQorICAg
IGFjX2N2X3Byb2dfQ1BQPSRDUFAKKworZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAorZWxzZQor
ICBhY19jdl9wcm9nX0NQUD0kQ1BQCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRDUFAiID4mNQorJGFzX2VjaG8gIiRDUFAiID4mNjsgfQorYWNf
cHJlcHJvY19vaz1mYWxzZQorZm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitk
bworICAjIFVzZSBhIGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3Vy
aW5nIGdsaWJjCisgICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFBy
ZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2lu
Y2UKKyAgIyA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMu
CisgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGls
ZXIncyBwYXJzZXIsCisgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlz
IGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19TVERDX18K
KyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRp
ZgorCQkgICAgIFN5bnRheCBlcnJvcgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5F
Tk8iOyB0aGVuIDoKKworZWxzZQorICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCitj
b250aW51ZQorZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19l
eHQKKworICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9u
ZXhpc3RlbnQgaGVhZGVycworICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlf
Y3BwICIkTElORU5PIjsgdGhlbiA6CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5w
dXQuCitjb250aW51ZQorZWxzZQorICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19v
az06CiticmVhaworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRh
Y19leHQKKworZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdz
IGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisKK2Vsc2UKKyAg
eyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRh
Y19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4m
Mjt9Cithc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMgc2FuaXR5
IGNoZWNrCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7
IH0KK2ZpCisKK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0n
JENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0n
JENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxl
cl9nbnUKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZSIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUuLi4g
IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9HUkVQK3NldH0iID0gc2V0OyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAteiAiJEdSRVAi
OyB0aGVuCisgIGFjX3BhdGhfR1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhyb3VnaCB0aGUg
dXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAorICBhc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhf
U0VQQVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dyZXA7IGRv
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgICAgICBhY19wYXRoX0dSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAg
ICB7IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0dSRVAi
OyB9IHx8IGNvbnRpbnVlCisjIENoZWNrIGZvciBHTlUgYWNfcGF0aF9HUkVQIGFuZCBzZWxlY3Qg
aXQgaWYgaXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9HUkVQCitjYXNl
IGAiJGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0
aF9HUkVQPSIkYWNfcGF0aF9HUkVQIiBhY19wYXRoX0dSRVBfZm91bmQ9Ojs7CisqKQorICBhY19j
b3VudD0wCisgICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6
CisgIGRvCisgICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRt
cCIKKyAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0
LmluIiAiY29uZnRlc3QubmwiCisgICAgJGFzX2VjaG8gJ0dSRVAnID4+ICJjb25mdGVzdC5ubCIK
KyAgICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gpLScgPCAi
Y29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAgIGRp
ZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsK
KyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAgICBp
ZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCisgICAgICAj
IEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBv
bmUKKyAgICAgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIKKyAgICAgIGFjX3BhdGhf
R1JFUF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1
dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJy
ZWFrCisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5s
IGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX0dSRVBfZm91bmQgJiYgYnJl
YWsgMworICAgIGRvbmUKKyAgZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisgIGlmIHRl
c3QgLXogIiRhY19jdl9wYXRoX0dSRVAiOyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFj
Y2VwdGFibGUgZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3Iv
eHBnNC9iaW4iICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2X3BhdGhfR1JFUD0kR1JF
UAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfcGF0aF9HUkVQIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcGF0aF9HUkVQIiA+
JjY7IH0KKyBHUkVQPSIkYWNfY3ZfcGF0aF9HUkVQIgorCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGVncmVwIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX0VH
UkVQK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgaWYgZWNobyBhIHwgJEdSRVAgLUUgJyhhfGIpJyA+L2Rldi9udWxsIDI+JjEKKyAgIHRo
ZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCisgICBlbHNlCisgICAgIGlmIHRlc3QgLXog
IiRFR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9FR1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhy
b3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAor
ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUwor
ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIGVncmVw
OyBkbworICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z
OyBkbworICAgICAgYWNfcGF0aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIK
KyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfRUdSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRo
X0VHUkVQIjsgfSB8fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfRUdSRVAgYW5k
IHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBDaGVjayBmb3IgR05VICRhY19wYXRoX0VH
UkVQCitjYXNlIGAiJGFjX3BhdGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisg
IGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VHUkVQX2ZvdW5kPTo7
OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5p
biIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIg
PiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAg
IGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgorICAgICRhc19lY2hvICdFR1JFUCcgPj4g
ImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29uZnRlc3Qu
bmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhaworICAgIGRpZmYgImNvbmZ0
ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKKyAgICBhc19m
bl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKKyAgICBpZiB0ZXN0ICRh
Y19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9u
ZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAg
ICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIKKyAgICAgIGFjX3BhdGhfRUdSRVBf
bWF4PSRhY19jb3VudAorICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2Vl
bXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawor
ICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25m
dGVzdC5vdXQ7OworZXNhYworCisgICAgICAkYWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBicmVhayAz
CisgICAgZG9uZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAt
eiAiJGFjX2N2X3BhdGhfRUdSRVAiOyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2Vw
dGFibGUgZWdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hw
ZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQorZWxzZQorICBhY19jdl9wYXRoX0VHUkVQPSRFR1JF
UAorZmkKKworICAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wYXRo
X0VHUkVQIiA+JjY7IH0KKyBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCisKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRl
ciBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxl
cy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYytzZXR9IiA9IHNldDsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdHJp
bmcuaD4KKyNpbmNsdWRlIDxmbG9hdC5oPgorCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2N2X2hlYWRlcl9zdGRjPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1u
bworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl
c3QuJGFjX2V4dAorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAj
IFN1bk9TIDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFO
U0kuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKworX0FDRU9GCitpZiAoZXZh
bCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAibWVtY2hyIiA+
L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitm
aQorcm0gLWYgY29uZnRlc3QqCisKK2ZpCisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0g
eWVzOyB0aGVuCisgICMgSVNDIDIuMC4yIHN0ZGxpYi5oIGRvZXMgbm90IGRlY2xhcmUgZnJlZSwg
Y29udHJhcnkgdG8gQU5TSS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0ZGxpYi5oPgorCitf
QUNFT0YKK2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVH
UkVQICJmcmVlIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRl
cl9zdGRjPW5vCitmaQorcm0gLWYgY29uZnRlc3QqCisKK2ZpCisKK2lmIHRlc3QgJGFjX2N2X2hl
YWRlcl9zdGRjID0geWVzOyB0aGVuCisgICMgL2Jpbi9jYyBpbiBJcml4LTQuMC41IGdldHMgbm9u
LUFOU0kgY3R5cGUgbWFjcm9zIHVubGVzcyB1c2luZyAtYW5zaS4KKyAgaWYgdGVzdCAiJGNyb3Nz
X2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICA6CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxjdHlwZS5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2lmICgoJyAnICYgMHgwRkYpID09
IDB4MDIwKQorIyBkZWZpbmUgSVNMT1dFUihjKSAoJ2EnIDw9IChjKSAmJiAoYykgPD0gJ3onKQor
IyBkZWZpbmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScpIDogKGMp
KQorI2Vsc2UKKyMgZGVmaW5lIElTTE9XRVIoYykgXAorCQkgICAoKCdhJyA8PSAoYykgJiYgKGMp
IDw9ICdpJykgXAorCQkgICAgIHx8ICgnaicgPD0gKGMpICYmIChjKSA8PSAncicpIFwKKwkJICAg
ICB8fCAoJ3MnIDw9IChjKSAmJiAoYykgPD0gJ3onKSkKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElT
TE9XRVIoYykgPyAoKGMpIHwgMHg0MCkgOiAoYykpCisjZW5kaWYKKworI2RlZmluZSBYT1IoZSwg
ZikgKCgoZSkgJiYgIShmKSkgfHwgKCEoZSkgJiYgKGYpKSkKK2ludAorbWFpbiAoKQoreworICBp
bnQgaTsKKyAgZm9yIChpID0gMDsgaSA8IDI1NjsgaSsrKQorICAgIGlmIChYT1IgKGlzbG93ZXIg
KGkpLCBJU0xPV0VSIChpKSkKKwl8fCB0b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkKKyAgICAg
IHJldHVybiAyOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIk
TElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KK2ZpCitybSAt
ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4k
YWNfZXh0CitmaQorCitmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNQorJGFzX2VjaG8gIiRhY19jdl9o
ZWFkZXJfc3RkYyIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhl
bgorCiskYXNfZWNobyAiI2RlZmluZSBTVERDX0hFQURFUlMgMSIgPj5jb25mZGVmcy5oCisKK2Zp
CisKKyMgT24gSVJJWCA1LjMsIHN5cy90eXBlcyBhbmQgaW50dHlwZXMuaCBhcmUgY29uZmxpY3Rp
bmcuCitmb3IgYWNfaGVhZGVyIGluIHN5cy90eXBlcy5oIHN5cy9zdGF0Lmggc3RkbGliLmggc3Ry
aW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKKwkJICBpbnR0eXBlcy5oIHN0ZGludC5oIHVuaXN0
ZC5oCitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVh
ZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRMSU5FTk8i
ICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0CisiCitp
ZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNh
dCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFk
ZXIiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKworCisKKyAgYWNfZm5f
Y19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIm1pbml4L2NvbmZpZy5oIiAiYWNfY3Zf
aGVhZGVyX21pbml4X2NvbmZpZ19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4
JGFjX2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBNSU5JWD15
ZXMKK2Vsc2UKKyAgTUlOSVg9CitmaQorCisKKyAgaWYgdGVzdCAiJE1JTklYIiA9IHllczsgdGhl
bgorCiskYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfU09VUkNFIDEiID4+Y29uZmRlZnMuaAorCisK
KyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF8xX1NPVVJDRSAyIiA+PmNvbmZkZWZzLmgKKworCisk
YXNfZWNobyAiI2RlZmluZSBfTUlOSVggMSIgPj5jb25mZGVmcy5oCisKKyAgZmkKKworCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBp
dCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXyIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fLi4uICIgPiY2
OyB9CitpZiB0ZXN0ICIke2FjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fK3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworCisjCSAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKKwkgICRhY19pbmNsdWRlc19k
ZWZhdWx0CitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3NhZmVfdG9f
ZGVmaW5lX19fZXh0ZW5zaW9uc19fPXllcworZWxzZQorICBhY19jdl9zYWZlX3RvX2RlZmluZV9f
X2V4dGVuc2lvbnNfXz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25z
X18iID4mNQorJGFzX2VjaG8gIiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIg
PiY2OyB9CisgIHRlc3QgJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fID0geWVz
ICYmCisgICAgJGFzX2VjaG8gIiNkZWZpbmUgX19FWFRFTlNJT05TX18gMSIgPj5jb25mZGVmcy5o
CisKKyAgJGFzX2VjaG8gIiNkZWZpbmUgX0FMTF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAg
JGFzX2VjaG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFzX2Vj
aG8gIiNkZWZpbmUgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTIDEiID4+Y29uZmRlZnMuaAorCisg
ICRhc19lY2hvICIjZGVmaW5lIF9UQU5ERU1fU09VUkNFIDEiID4+Y29uZmRlZnMuaAorCisKKyMg
TWFrZSBzdXJlIHdlIGNhbiBydW4gY29uZmlnLnN1Yi4KKyRTSEVMTCAiJGFjX2F1eF9kaXIvY29u
ZmlnLnN1YiIgc3VuNCA+L2Rldi9udWxsIDI+JjEgfHwKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBydW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5PIiA1CisKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgYnVpbGQgc3lzdGVt
IHR5cGUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfYnVpbGQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19idWlsZF9hbGlhcz0kYnVpbGRfYWxp
YXMKK3Rlc3QgIngkYWNfYnVpbGRfYWxpYXMiID0geCAmJgorICBhY19idWlsZF9hbGlhcz1gJFNI
RUxMICIkYWNfYXV4X2Rpci9jb25maWcuZ3Vlc3MiYAordGVzdCAieCRhY19idWlsZF9hbGlhcyIg
PSB4ICYmCisgIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgZ3Vlc3MgYnVpbGQgdHlwZTsgeW91IG11
c3Qgc3BlY2lmeSBvbmUiICIkTElORU5PIiA1CithY19jdl9idWlsZD1gJFNIRUxMICIkYWNfYXV4
X2Rpci9jb25maWcuc3ViIiAkYWNfYnVpbGRfYWxpYXNgIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICIk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkYWNfYnVpbGRfYWxpYXMgZmFpbGVkIiAiJExJ
TkVOTyIgNQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9idWlsZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2J1aWxkIiA+JjY7IH0K
K2Nhc2UgJGFjX2N2X2J1aWxkIGluCisqLSotKikgOzsKKyopIGFzX2ZuX2Vycm9yICQ/ICJpbnZh
bGlkIHZhbHVlIG9mIGNhbm9uaWNhbCBidWlsZCIgIiRMSU5FTk8iIDUgOzsKK2VzYWMKK2J1aWxk
PSRhY19jdl9idWlsZAorYWNfc2F2ZV9JRlM9JElGUzsgSUZTPSctJworc2V0IHggJGFjX2N2X2J1
aWxkCitzaGlmdAorYnVpbGRfY3B1PSQxCitidWlsZF92ZW5kb3I9JDIKK3NoaWZ0OyBzaGlmdAor
IyBSZW1lbWJlciwgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBJRlMgaXMgdXNlZCB0byBjcmVhdGUg
JCosCisjIGV4Y2VwdCB3aXRoIG9sZCBzaGVsbHM6CitidWlsZF9vcz0kKgorSUZTPSRhY19zYXZl
X0lGUworY2FzZSAkYnVpbGRfb3MgaW4gKlwgKikgYnVpbGRfb3M9YGVjaG8gIiRidWlsZF9vcyIg
fCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9o
b3N0K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgaWYgdGVzdCAieCRob3N0X2FsaWFzIiA9IHg7IHRoZW4KKyAgYWNfY3ZfaG9zdD0kYWNf
Y3ZfYnVpbGQKK2Vsc2UKKyAgYWNfY3ZfaG9zdD1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcu
c3ViIiAkaG9zdF9hbGlhc2AgfHwKKyAgICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRhY19hdXhf
ZGlyL2NvbmZpZy5zdWIgJGhvc3RfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQorZmkKKworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
aG9zdCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hvc3QiID4mNjsgfQorY2FzZSAkYWNfY3ZfaG9z
dCBpbgorKi0qLSopIDs7CisqKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YWx1ZSBvZiBjYW5v
bmljYWwgaG9zdCIgIiRMSU5FTk8iIDUgOzsKK2VzYWMKK2hvc3Q9JGFjX2N2X2hvc3QKK2FjX3Nh
dmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4ICRhY19jdl9ob3N0CitzaGlmdAoraG9zdF9jcHU9
JDEKK2hvc3RfdmVuZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBmaXJzdCBj
aGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAorIyBleGNlcHQgd2l0aCBvbGQg
c2hlbGxzOgoraG9zdF9vcz0kKgorSUZTPSRhY19zYXZlX0lGUworY2FzZSAkaG9zdF9vcyBpbiAq
XCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKwor
CisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKKworCisKKworCisKKworCisKKworCisKKworCisKKwor
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisK
KworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUteHNt
IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3hzbStzZXR9IiA9IHNldDsgdGhlbiA6Cisg
IGVuYWJsZXZhbD0kZW5hYmxlX3hzbTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfeHNtIiA9
ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl94c209InkiCisKK2VsaWYgdGVzdCAieCRlbmFi
bGVfeHNtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3hzbT0ibiIKKworZWxpZiB0ZXN0
IC16ICRheF9jdl94c207IHRoZW4gOgorCisgICAgYXhfY3ZfeHNtPSJuIgorCitmaQoreHNtPSRh
eF9jdl94c20KKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWdpdGh0dHAgd2FzIGdpdmVuLgor
aWYgdGVzdCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZh
bD0kZW5hYmxlX2dpdGh0dHA7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0g
Inh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9InkiCisKK2VsaWYgdGVzdCAieCRl
bmFibGVfZ2l0aHR0cCIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9naXRodHRwPSJuIgor
CitlbGlmIHRlc3QgLXogJGF4X2N2X2dpdGh0dHA7IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0
cD0ibiIKKworZmkKK2dpdGh0dHA9JGF4X2N2X2dpdGh0dHAKKworIyBDaGVjayB3aGV0aGVyIC0t
ZW5hYmxlLW1vbml0b3JzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX21vbml0b3JzK3Nl
dH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfbW9uaXRvcnM7CitmaQorCisK
K2lmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2
X21vbml0b3JzPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX21vbml0b3JzIiA9ICJ4eWVzIjsg
dGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9t
b25pdG9yczsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ieSIKKworZmkKK21vbml0b3Jz
PSRheF9jdl9tb25pdG9ycworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtdnRwbSB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV92dHBtK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxl
dmFsPSRlbmFibGVfdnRwbTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieHll
cyI7IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ieSIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV92
dHBtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3Z0cG09Im4iCisKK2VsaWYgdGVzdCAt
eiAkYXhfY3ZfdnRwbTsgdGhlbiA6CisKKyAgICBheF9jdl92dHBtPSJuIgorCitmaQordnRwbT0k
YXhfY3ZfdnRwbQorCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUteGFwaSB3YXMgZ2l2ZW4uCitp
ZiB0ZXN0ICIke2VuYWJsZV94YXBpK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRl
bmFibGVfeGFwaTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieHllcyI7IHRo
ZW4gOgorCisgICAgYXhfY3ZfeGFwaT0ieSIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV94YXBpIiA9
ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3hhcGk9Im4iCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfeGFwaTsgdGhlbiA6CisKKyAgICBheF9jdl94YXBpPSJuIgorCitmaQoreGFwaT0kYXhfY3Zf
eGFwaQorCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtcHl0aG9udG9vbHMgd2FzIGdpdmVuLgor
aWYgdGVzdCAiJHtlbmFibGVfcHl0aG9udG9vbHMrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFi
bGV2YWw9JGVuYWJsZV9weXRob250b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfcHl0
aG9udG9vbHMiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4iCisK
K2VsaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAg
IGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRvb2xz
OyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCitmaQorcHl0aG9udG9vbHM9
JGF4X2N2X3B5dGhvbnRvb2xzCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xz
IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX29jYW1sdG9vbHMrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xzOworZmkKKworCitpZiB0ZXN0ICJ4
JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9v
bHM9Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4g
OgorCisgICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9vY2Ft
bHRvb2xzOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCisKK2ZpCitvY2FtbHRv
b2xzPSRheF9jdl9vY2FtbHRvb2xzCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1taW5pdGVy
bSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9taW5pdGVybStzZXR9IiA9IHNldDsgdGhl
biA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX21pbml0ZXJtOworZmkKKworCitpZiB0ZXN0ICJ4JGVu
YWJsZV9taW5pdGVybSIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbWluaXRlcm09Inki
CisKK2VsaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInhubyI7IHRoZW4gOgorCisgICAg
YXhfY3ZfbWluaXRlcm09Im4iCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbWluaXRlcm07IHRoZW4g
OgorCisgICAgYXhfY3ZfbWluaXRlcm09Im4iCisKK2ZpCittaW5pdGVybT0kYXhfY3ZfbWluaXRl
cm0KKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWxvbW91bnQgd2FzIGdpdmVuLgoraWYgdGVz
dCAiJHtlbmFibGVfbG9tb3VudCtzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX2xvbW91bnQ7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInh5ZXMi
OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVf
bG9tb3VudCIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9sb21vdW50PSJuIgorCitlbGlm
IHRlc3QgLXogJGF4X2N2X2xvbW91bnQ7IHRoZW4gOgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIK
KworZmkKK2xvbW91bnQ9JGF4X2N2X2xvbW91bnQKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxl
LWRlYnVnIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2RlYnVnK3NldH0iID0gc2V0OyB0
aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfZGVidWc7CitmaQorCisKK2lmIHRlc3QgIngkZW5h
YmxlX2RlYnVnIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X2RlYnVnPSJuIgorCitlbGlm
IHRlc3QgIngkZW5hYmxlX2RlYnVnIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9kZWJ1
Zz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9kZWJ1ZzsgdGhlbiA6CisKKyAgICBheF9jdl9k
ZWJ1Zz0ieSIKKworZmkKK2RlYnVnPSRheF9jdl9kZWJ1ZworCisKKworCisKKworCitmb3IgY2Zs
YWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKK2RvCisgICAgUFJFUEVORF9DRkxBR1MrPSIgLUkkY2Zs
YWciCitkb25lCitmb3IgbGRmbGFnIGluICRQUkVQRU5EX0xJQgorZG8KKyAgICBQUkVQRU5EX0xE
RkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorZm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMK
K2RvCisgICAgQVBQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4g
JEFQUEVORF9MSUIKK2RvCisgICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQor
Q0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENGTEFHUyAkQVBQRU5EX0NGTEFHUyIKK0xERkxBR1M9
IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdTIgorCisKKworCisKKwor
CisKKworCisKKworIyBDaGVja3MgZm9yIHByb2dyYW1zLgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVu
Y2F0ZSBvdXRwdXQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9l
cyBub3QgdHJ1bmNhdGUgb3V0cHV0Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhf
U0VEK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgICAgICAgICAgIGFjX3NjcmlwdD1zL2FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhL2JiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJiYi8KKyAgICAgZm9yIGFjX2kg
aW4gMSAyIDMgNCA1IDYgNzsgZG8KKyAgICAgICBhY19zY3JpcHQ9IiRhY19zY3JpcHQkYXNfbmwk
YWNfc2NyaXB0IgorICAgICBkb25lCisgICAgIGVjaG8gIiRhY19zY3JpcHQiIDI+L2Rldi9udWxs
IHwgc2VkIDk5cSA+Y29uZnRlc3Quc2VkCisgICAgIHsgYWNfc2NyaXB0PTsgdW5zZXQgYWNfc2Ny
aXB0O30KKyAgICAgaWYgdGVzdCAteiAiJFNFRCI7IHRoZW4KKyAgYWNfcGF0aF9TRURfZm91bmQ9
ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNo
IG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19wcm9nIGluIHNlZCBnc2VkOyBkbwor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICAgICAgYWNfcGF0aF9TRUQ9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAgICB7
IHRlc3QgLWYgIiRhY19wYXRoX1NFRCIgJiYgJGFzX3Rlc3RfeCAiJGFjX3BhdGhfU0VEIjsgfSB8
fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfU0VEIGFuZCBzZWxlY3QgaXQgaWYg
aXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9TRUQKK2Nhc2UgYCIkYWNf
cGF0aF9TRUQiIC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfU0VEPSIk
YWNfcGF0aF9TRUQiIGFjX3BhdGhfU0VEX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAk
YXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAg
IGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYg
ImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0
ZXN0Lm5sIgorICAgICRhc19lY2hvICcnID4+ICJjb25mdGVzdC5ubCIKKyAgICAiJGFjX3BhdGhf
U0VEIiAtZiBjb25mdGVzdC5zZWQgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9k
ZXYvbnVsbCB8fCBicmVhaworICAgIGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+
L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYm
IGFjX2NvdW50PSRhc192YWwKKyAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX1NF
RF9tYXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVw
IGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9TRUQ9IiRhY19wYXRo
X1NFRCIKKyAgICAgIGFjX3BhdGhfU0VEX21heD0kYWNfY291bnQKKyAgICBmaQorICAgICMgMTAq
KDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0ZXN0ICRh
Y19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5pbiBjb25m
dGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAgJGFjX3Bh
dGhfU0VEX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRh
c19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9TRUQiOyB0aGVuCisgICAgYXNf
Zm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgc2VkIGNvdWxkIGJlIGZvdW5kIGluIFwkUEFUSCIg
IiRMSU5FTk8iIDUKKyAgZmkKK2Vsc2UKKyAgYWNfY3ZfcGF0aF9TRUQ9JFNFRAorZmkKKworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
cGF0aF9TRUQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wYXRoX1NFRCIgPiY2OyB9CisgU0VEPSIk
YWNfY3ZfcGF0aF9TRUQiCisgIHJtIC1mIGNvbmZ0ZXN0LnNlZAorCithY19leHQ9YworYWNfY3Bw
PSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBj
b25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQg
JENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCith
Y19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CitpZiB0ZXN0IC1uICIkYWNfdG9v
bF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29s
X3ByZWZpeH1nY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9Z2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJEND
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNf
dG9vbF9wcmVmaXh9Z2NjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19j
dl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2
OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgZ2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19h
Y19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfYWNfY3RfQ0M9ImdjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh
ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19j
dF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0
X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAg
Q0M9IiIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQg
aW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5J
Tkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1
CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMK
KyAgICBDQz0kYWNfY3RfQ0MKKyAgZmkKK2Vsc2UKKyAgQ0M9IiRhY19jdl9wcm9nX0NDIgorZmkK
KworaWYgdGVzdCAteiAiJENDIjsgdGhlbgorICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9v
bF9wcmVmaXh9Y2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9Y2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1jYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisg
IGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3Zf
cHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICBmaQorZmkKK2lmIHRl
c3QgLXogIiRDQyI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgY2M7IGFjX3dv
cmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi
ID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhl
bgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
LgorZWxzZQorICBhY19wcm9nX3JlamVjdGVkPW5vCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBpZiB0ZXN0ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA9ICIvdXNyL3VjYi9jYyI7IHRoZW4KKyAgICAgICBhY19wcm9nX3JlamVjdGVkPXll
cworICAgICAgIGNvbnRpbnVlCisgICAgIGZpCisgICAgYWNfY3ZfcHJvZ19DQz0iY2MiCisgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJ
RlM9JGFzX3NhdmVfSUZTCisKK2lmIHRlc3QgJGFjX3Byb2dfcmVqZWN0ZWQgPSB5ZXM7IHRoZW4K
KyAgIyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBtYWtlIHN1cmUgd2UgbmV2ZXIg
dXNlIGl0LgorICBzZXQgZHVtbXkgJGFjX2N2X3Byb2dfQ0MKKyAgc2hpZnQKKyAgaWYgdGVzdCAk
IyAhPSAwOyB0aGVuCisgICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVudCBjb21waWxlciBmcm9tIHRo
ZSBib2d1cyBvbmUuCisgICAgIyBIb3dldmVyLCBpdCBoYXMgdGhlIHNhbWUgYmFzZW5hbWUsIHNv
IHRoZSBib2dvbiB3aWxsIGJlIGNob3NlbgorICAgICMgZmlyc3QgaWYgd2Ugc2V0IENDIHRvIGp1
c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1lLgorICAgIHNoaWZ0CisgICAg
YWNfY3ZfcHJvZ19DQz0iJGFzX2Rpci8kYWNfd29yZCR7MSsnICd9JEAiCisgIGZpCitmaQorZmkK
K2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19l
Y2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKwor
ZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKKyAgZG8KKyAgICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkYWNfdG9vbF9wcmVmaXgkYWNfcHJv
ZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm
b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAi
JENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKworICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsKKyAgZG9uZQor
ZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZvciBhY19wcm9n
IGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfcHJvZyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3By
b2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0i
JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91
bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQor
ZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2
X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Cisk
YXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CitmaQorCisKKyAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRl
c3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitm
aQorCitmaQorCisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAibm8gYWNj
ZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2VlIFxgY29uZmlnLmxvZycgZm9y
IG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0
aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQorc2V0IFggJGFjX2Nv
bXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAt
cXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIK
K2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c
JGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRh
c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19v
cHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMg
Y29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcxMGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0
cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIx
CisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNv
bmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8g
PSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2Ug
YXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3
aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfY19jb21waWxlcl9nbnUrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQor
eworI2lmbmRlZiBfX0dOVUNfXworICAgICAgIGNob2tlIG1lCisjZW5kaWYKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2NvbXBpbGVyX2dudT15ZXMKK2Vsc2UKKyAgYWNfY29tcGlsZXJfZ251PW5vCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CithY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251CisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29t
cGlsZXJfZ251IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQor
aWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCisgIEdDQz15ZXMKK2Vsc2UKKyAg
R0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KK2FjX3NhdmVfQ0ZMQUdTPSRD
RkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
d2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVy
ICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfZytz
ZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNfY193ZXJyb3Jf
ZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIKKyAgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2Nj
X2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP
RiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4g
KCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY193ZXJyb3JfZmxhZz0kYWNfc2F2
ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWlu
ICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitmaQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Citm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2Zs
YWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfZyIgPiY2OyB9
CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCisgIENGTEFHUz0kYWNfc2F2
ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVuCisgIGlmIHRl
c3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItZyAtTzIiCisgIGVsc2UKKyAgICBD
RkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAg
IENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPQorICBmaQorZmkKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8g
YWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRDQyBvcHRpb24g
dG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19j
ODkrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
bmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBl
cy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVz
dHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVm
IHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3Rh
dCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBp
bnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykg
KGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3Qg
djsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZh
X2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21l
IHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJv
dG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRz
LgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFk
IGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMg
YW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2Rl
LiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisg
ICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0w
IHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2lu
dCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisKKy8qIElCTSBDIDYgZm9y
IEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFy
YW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwor
I2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6
IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYp
IChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJu
YW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAq
LCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2OworaW50CittYWluICgp
Cit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4g
JycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9I
UFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAgQ0M9IiRhY19zYXZlX0ND
ICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIg
JiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0NDPSRhY19zYXZlX0NDCisK
K2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KKyAgeCkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9u
ZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKKyAgeG5vKQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1
cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OworICAqKQorICAg
IENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitpZiB0ZXN0ICJ4JGFjX2N2
X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9CitMTl9T
PSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8g
InllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2VjaG8gIm5vLCB1c2luZyAk
TE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAi
ID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2Vk
ICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgInRlc3QgXCJcJHthY19j
dl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQrc2V0fVwiIiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCA+Y29uZnRlc3QubWFrZSA8PFxfQUNF
T0YKK1NIRUxMID0gL2Jpbi9zaAorYWxsOgorCUBlY2hvICdAQEAlJSU9JChNQUtFKT1AQEAlJSUn
CitfQUNFT0YKKyMgR05VIG1ha2Ugc29tZXRpbWVzIHByaW50cyAibWFrZVsxXTogRW50ZXJpbmcg
Li4uIiwgd2hpY2ggd291bGQgY29uZnVzZSB1cy4KK2Nhc2UgYCR7TUFLRS1tYWtlfSAtZiBjb25m
dGVzdC5tYWtlIDI+L2Rldi9udWxsYCBpbgorICAqQEBAJSUlPT8qPUBAQCUlJSopCisgICAgZXZh
bCBhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQ9eWVzOzsKKyAgKikKKyAgICBldmFsIGFj
X2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD1ubzs7Citlc2FjCitybSAtZiBjb25mdGVzdC5t
YWtlCitmaQoraWYgZXZhbCB0ZXN0IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0g
eWVzOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CisgIFNFVF9NQUtFPQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgU0VUX01BS0U9Ik1BS0U9JHtNQUtFLW1ha2V9Igor
ZmkKKworIyBGaW5kIGEgZ29vZCBpbnN0YWxsIHByb2dyYW0uICBXZSBwcmVmZXIgYSBDIHByb2dy
YW0gKGZhc3RlciksCisjIHNvIG9uZSBzY3JpcHQgaXMgYXMgZ29vZCBhcyBhbm90aGVyLiAgQnV0
IGF2b2lkIHRoZSBicm9rZW4gb3IKKyMgaW5jb21wYXRpYmxlIHZlcnNpb25zOgorIyBTeXNWIC9l
dGMvaW5zdGFsbCwgL3Vzci9zYmluL2luc3RhbGwKKyMgU3VuT1MgL3Vzci9ldGMvaW5zdGFsbAor
IyBJUklYIC9zYmluL2luc3RhbGwKKyMgQUlYIC9iaW4vaW5zdGFsbAorIyBBbWlnYU9TIC9DL2lu
c3RhbGwsIHdoaWNoIGluc3RhbGxzIGJvb3RibG9ja3Mgb24gZmxvcHB5IGRpc2NzCisjIEFJWCA0
IC91c3IvYmluL2luc3RhbGxic2QsIHdoaWNoIGRvZXNuJ3Qgd29yayB3aXRob3V0IGEgLWcgZmxh
ZworIyBBRlMgL3Vzci9hZnN3cy9iaW4vaW5zdGFsbCwgd2hpY2ggbWlzaGFuZGxlcyBub25leGlz
dGVudCBhcmdzCisjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hpY2ggdHJpZXMgdG8gdXNlIHRo
ZSBub25leGlzdGVudCBncm91cCAic3RhZmYiCisjIE9TLzIncyBzeXN0ZW0gaW5zdGFsbCwgd2hp
Y2ggaGFzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2VtYW50aWMKKyMgLi9pbnN0YWxsLCB3aGlj
aCBjYW4gYmUgZXJyb25lb3VzbHkgY3JlYXRlZCBieSBtYWtlIGZyb20gLi9pbnN0YWxsLnNoLgor
IyBSZWplY3QgaW5zdGFsbCBwcm9ncmFtcyB0aGF0IGNhbm5vdCBpbnN0YWxsIG11bHRpcGxlIGZp
bGVzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgYSBCU0QtY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwuLi4gIiA+JjY7IH0KK2lmIHRlc3QgLXogIiRJTlNU
QUxMIjsgdGhlbgoraWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgIyBBY2Nv
dW50IGZvciBwZW9wbGUgd2hvIHB1dCB0cmFpbGluZyBzbGFzaGVzIGluIFBBVEggZWxlbWVudHMu
CitjYXNlICRhc19kaXIvIGluICMoKAorICAuLyB8IC4vLyB8IC9bY0NdLyogfCBcCisgIC9ldGMv
KiB8IC91c3Ivc2Jpbi8qIHwgL3Vzci9ldGMvKiB8IC9zYmluLyogfCAvdXNyL2Fmc3dzL2Jpbi8q
IHwgXAorICA/OltcXC9db3MyW1xcL11pbnN0YWxsW1xcL10qIHwgPzpbXFwvXU9TMltcXC9dSU5T
VEFMTFtcXC9dKiB8IFwKKyAgL3Vzci91Y2IvKiApIDs7CisgICopCisgICAgIyBPU0YxIGFuZCBT
Q08gT0RUIDMuMCBoYXZlIHRoZWlyIG93biBuYW1lcyBmb3IgaW5zdGFsbC4KKyAgICAjIERvbid0
IHVzZSBpbnN0YWxsYnNkIGZyb20gT1NGIHNpbmNlIGl0IGluc3RhbGxzIHN0dWZmIGFzIHJvb3QK
KyAgICAjIGJ5IGRlZmF1bHQuCisgICAgZm9yIGFjX3Byb2cgaW4gZ2luc3RhbGwgc2NvaW5zdCBp
bnN0YWxsOyBkbworICAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisJaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
CSAgaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBkc3Btc2cgIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgorCSAgICAjIEFJ
WCBpbnN0YWxsLiAgSXQgaGFzIGFuIGluY29tcGF0aWJsZSBjYWxsaW5nIGNvbnZlbnRpb24uCisJ
ICAgIDoKKwkgIGVsaWYgdGVzdCAkYWNfcHJvZyA9IGluc3RhbGwgJiYKKwkgICAgZ3JlcCBwd3Bs
dXMgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiID4vZGV2L251bGwgMj4mMTsgdGhlbgor
CSAgICAjIHByb2dyYW0tc3BlY2lmaWMgaW5zdGFsbCBzY3JpcHQgdXNlZCBieSBIUCBwd3BsdXMt
LWRvbid0IHVzZS4KKwkgICAgOgorCSAgZWxzZQorCSAgICBybSAtcmYgY29uZnRlc3Qub25lIGNv
bmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwkgICAgZWNobyBvbmUgPiBjb25mdGVzdC5vbmUKKwkg
ICAgZWNobyB0d28gPiBjb25mdGVzdC50d28KKwkgICAgbWtkaXIgY29uZnRlc3QuZGlyCisJICAg
IGlmICIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IiAtYyBjb25mdGVzdC5vbmUgY29uZnRl
c3QudHdvICJgcHdkYC9jb25mdGVzdC5kaXIiICYmCisJICAgICAgdGVzdCAtcyBjb25mdGVzdC5v
bmUgJiYgdGVzdCAtcyBjb25mdGVzdC50d28gJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRp
ci9jb25mdGVzdC5vbmUgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0LmRpci9jb25mdGVzdC50
d28KKwkgICAgdGhlbgorCSAgICAgIGFjX2N2X3BhdGhfaW5zdGFsbD0iJGFzX2Rpci8kYWNfcHJv
ZyRhY19leGVjX2V4dCAtYyIKKwkgICAgICBicmVhayAzCisJICAgIGZpCisJICBmaQorCWZpCisg
ICAgICBkb25lCisgICAgZG9uZQorICAgIDs7Citlc2FjCisKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitybSAtcmYgY29uZnRlc3Qub25lIGNvbmZ0ZXN0LnR3byBjb25mdGVzdC5kaXIKKwor
ZmkKKyAgaWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRoZW4KKyAg
ICBJTlNUQUxMPSRhY19jdl9wYXRoX2luc3RhbGwKKyAgZWxzZQorICAgICMgQXMgYSBsYXN0IHJl
c29ydCwgdXNlIHRoZSBzbG93IHNoZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKKyAgICAjIHZh
bHVlIGZvciBJTlNUQUxMIHdpdGhpbiBhIHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2UgdGhhdCB3
aWxsCisgICAgIyBicmVhayBvdGhlciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYgdGhhdCBk
aXJlY3RvcnkgaXMKKyAgICAjIHJlbW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJlbGF0aXZl
IG5hbWUuCisgICAgSU5TVEFMTD0kYWNfaW5zdGFsbF9zaAorICBmaQorZmkKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSU5TVEFMTCIgPiY1CiskYXNf
ZWNobyAiJElOU1RBTEwiID4mNjsgfQorCisjIFVzZSB0ZXN0IC16IGJlY2F1c2UgU3VuT1M0IHNo
IG1pc2hhbmRsZXMgYnJhY2VzIGluICR7dmFyLXZhbH0uCisjIEl0IHRoaW5rcyB0aGUgZmlyc3Qg
Y2xvc2UgYnJhY2UgZW5kcyB0aGUgdmFyaWFibGUgc3Vic3RpdHV0aW9uLgordGVzdCAteiAiJElO
U1RBTExfUFJPR1JBTSIgJiYgSU5TVEFMTF9QUk9HUkFNPScke0lOU1RBTEx9JworCit0ZXN0IC16
ICIkSU5TVEFMTF9TQ1JJUFQiICYmIElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworCit0ZXN0
IC16ICIkSU5TVEFMTF9EQVRBIiAmJiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0Jwor
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBlcmwiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHBlcmw7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX1BFUkwrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRQRVJMIGluCisgIFtcXC9dKiB8ID86W1xcL10q
KQorICBhY19jdl9wYXRoX1BFUkw9IiRQRVJMIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9QRVJMPSIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19j
dl9wYXRoX1BFUkwiICYmIGFjX2N2X3BhdGhfUEVSTD0ibm8iCisgIDs7Citlc2FjCitmaQorUEVS
TD0kYWNfY3ZfcGF0aF9QRVJMCitpZiB0ZXN0IC1uICIkUEVSTCI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRQRVJMIiA+JjUKKyRhc19l
Y2hvICIkUEVSTCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKwor
CitpZiB0ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAi
VW5hYmxlIHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3RhbGwgcGVybCIgIiRMSU5FTk8iIDUKK2Zp
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJyY3RsIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBicmN0bDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3BhdGhfQlJDVEwrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCUkNUTCBpbgorICBbXFwvXSogfCA/Oltc
XC9dKikKKyAgYWNfY3ZfcGF0aF9CUkNUTD0iJEJSQ1RMIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CUkNUTD0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9CUkNUTCIgJiYgYWNfY3ZfcGF0aF9CUkNUTD0ibm8iCisgIDs7Citlc2Fj
CitmaQorQlJDVEw9JGFjX2N2X3BhdGhfQlJDVEwKK2lmIHRlc3QgLW4gIiRCUkNUTCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCUkNU
TCIgPiY1CiskYXNfZWNobyAiJEJSQ1RMIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIg
PiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JSQ1RMfSIgPT0geCJubyIKK3RoZW4KKyAgICBh
c19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYnJjdGwsIHBsZWFzZSBpbnN0YWxsIGJyY3Rs
IiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiaXAiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGlwOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9JUCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJElQIGluCisgIFtcXC9dKiB8
ID86W1xcL10qKQorICBhY19jdl9wYXRoX0lQPSIkSVAiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0lQPSIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRh
Y19jdl9wYXRoX0lQIiAmJiBhY19jdl9wYXRoX0lQPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitJUD0k
YWNfY3ZfcGF0aF9JUAoraWYgdGVzdCAtbiAiJElQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElQIiA+JjUKKyRhc19lY2hvICIkSVAi
ID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4
IiR7SVB9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCBpcCwgcGxlYXNlIGluc3RhbGwgaXAiICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJiaXNvbiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgYmlzb247IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRo
X0JJU09OK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgY2FzZSAkQklTT04gaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3Bh
dGhfQklTT049IiRCSVNPTiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh
IHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQklTT049IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQklT
T04iICYmIGFjX2N2X3BhdGhfQklTT049Im5vIgorICA7OworZXNhYworZmkKK0JJU09OPSRhY19j
dl9wYXRoX0JJU09OCitpZiB0ZXN0IC1uICIkQklTT04iOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQklTT04iID4mNQorJGFzX2VjaG8g
IiRCSVNPTiIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitp
ZiB0ZXN0IHgiJHtCSVNPTn0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kIGJpc29uLCBwbGVhc2UgaW5zdGFsbCBiaXNvbiIgIiRMSU5FTk8iIDUKK2Zp
CisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImZsZXgiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGZsZXg7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9wYXRoX0ZMRVgrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRGTEVYIGluCisgIFtcXC9dKiB8ID86W1xcL10q
KQorICBhY19jdl9wYXRoX0ZMRVg9IiRGTEVYIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9GTEVYPSIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19j
dl9wYXRoX0ZMRVgiICYmIGFjX2N2X3BhdGhfRkxFWD0ibm8iCisgIDs7Citlc2FjCitmaQorRkxF
WD0kYWNfY3ZfcGF0aF9GTEVYCitpZiB0ZXN0IC1uICIkRkxFWCI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRGTEVYIiA+JjUKKyRhc19l
Y2hvICIkRkxFWCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKwor
CitpZiB0ZXN0IHgiJHtGTEVYfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAi
VW5hYmxlIHRvIGZpbmQgZmxleCwgcGxlYXNlIGluc3RhbGwgZmxleCIgIiRMSU5FTk8iIDUKK2Zp
CitpZiB0ZXN0ICJ4JHhhcGkiID0gInh5IjsgdGhlbiA6CisKKyAgICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgImN1cmwtY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIk
e2FjX2N2X3BhdGhfQ1VSTCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJENVUkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisg
IGFjX2N2X3BhdGhfQ1VSTD0iJENVUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0NVUkw9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfQ1VSTCIgJiYgYWNfY3ZfcGF0aF9DVVJMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitDVVJMPSRh
Y19jdl9wYXRoX0NVUkwKK2lmIHRlc3QgLW4gIiRDVVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENVUkwiID4mNQorJGFzX2VjaG8g
IiRDVVJMIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lm
IHRlc3QgeCIke0NVUkx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCBjdXJsLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgY3VybC1jb25maWciICIkTElO
RU5PIiA1CitmaQorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieG1sMi1jb25maWci
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHhtbDIt
Y29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YTUwrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRY
TUwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfWE1MPSIkWE1MIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAg
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU
SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf
cGF0aF9YTUw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVf
SUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWE1MIiAmJiBhY19jdl9wYXRoX1hNTD0ibm8i
CisgIDs7Citlc2FjCitmaQorWE1MPSRhY19jdl9wYXRoX1hNTAoraWYgdGVzdCAtbiAiJFhNTCI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRYTUwiID4mNQorJGFzX2VjaG8gIiRYTUwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7WE1MfSIgPT0geCJubyIKK3RoZW4KKyAgICBh
c19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sMi1jb25maWcsIHBsZWFzZSBpbnN0YWxs
IHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQorZmkKKworZmkKK2lmIHRlc3QgIngkb2NhbWx0b29s
cyIgPSAieHkiOyB0aGVuIDoKKworICAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIGlmIHRl
c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGM7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQytzZXR9IiA9IHNldDsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEMi
OyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1s
YyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitPQ0FNTEM9JGFjX2N2X3Byb2dfT0NB
TUxDCitpZiB0ZXN0IC1uICIkT0NBTUxDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQyIgPiY1CiskYXNfZWNobyAiJE9DQU1M
QyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgorICBhY19jdF9PQ0FNTEM9JE9DQU1M
QworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxjOyBhY193b3JkPSQyCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNf
d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0K
K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0iJGFjX2N0X09DQU1MQyIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZT
OyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFz
X3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4
ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAt
ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
Qz0ib2NhbWxjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MQz0k
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEMKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3RfT0NBTUxDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
KyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDIiA9
IHg7IHRoZW4KKyAgICBPQ0FNTEM9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xf
d2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MQz0kYWNfY3RfT0NBTUxDCisgIGZpCitlbHNl
CisgIE9DQU1MQz0iJGFjX2N2X3Byb2dfT0NBTUxDIgorZmkKKworCisgIGlmIHRlc3QgIiRPQ0FN
TEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1u
IC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZF
UlNJT04iID4mNQorJGFzX2VjaG8gIk9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY2
OyB9CisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAgaWYgdGVzdCAiJE9D
QU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9k
ZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAorICAgICBlbHNl
CisgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQorJGFzX2VjaG8g
Ik9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9CisgICAgIGZp
CisgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBP
Q2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjUKKyRhc19lY2hvICJPQ2FtbCBsaWJy
YXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjY7IH0KKworCisKKworICAgICAjIGNoZWNraW5nIGZv
ciBvY2FtbG9wdAorICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29s
X3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NB
TUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxP
UFQ9IiRPQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCith
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRI
CitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9w
cm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitmaQorZmkKK09DQU1MT1BUPSRhY19jdl9wcm9nX09DQU1MT1BUCitpZiB0ZXN0IC1u
ICIkT0NBTUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVCIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAi
JGFjX2N2X3Byb2dfT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BUPSRPQ0FNTE9QVAor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbG9wdDsgYWNfd29yZD0kMgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFQ9IiRhY19jdF9P
Q0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2Fj
X2N0X09DQU1MT1BUPSJvY2FtbG9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCith
Y19jdF9PQ0FNTE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVAoraWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BUIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NB
TUxPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxPUFQ9Im5vIgorICBl
bHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1M
T1BUPSRhY19jdF9PQ0FNTE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVD0iJGFjX2N2X3Byb2df
T0NBTUxPUFQiCitmaQorCisgICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FN
TE9QVCIgPSAibm8iOyB0aGVuCisJeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24g
b25seS4iID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxv
cHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuIiA+JjI7fQorICAgICBlbHNlCisJVE1QVkVS
U0lPTj1gJE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8
cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJ
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJz
aW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19l
Y2hvICJ2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+
JjY7IH0KKwkgICAgT0NBTUxPUFQ9bm8KKwllbHNlCisJICAgIE9DQU1MQkVTVD1vcHQKKwlmaQor
ICAgICBmaQorCisKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0CisgICAgIGlmIHRl
c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdDsg
YWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxDRE9UT1BUK3NldH0iID0g
c2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAtbiAiJE9DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQ9IiRP
Q0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19PQ0FNTENET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKKworZmkKK2ZpCitPQ0FNTENET1RPUFQ9JGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BU
CitpZiB0ZXN0IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQ0RPVE9QVCIgPiY1CiskYXNfZWNo
byAiJE9DQU1MQ0RPVE9QVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQor
ZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUIjsgdGhlbgor
ICBhY19jdF9PQ0FNTENET1RPUFQ9JE9DQU1MQ0RPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIm9jYW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTENET1RP
UFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSIkYWNfY3RfT0NBTUxD
RE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDRE9UT1BUPSJvY2FtbGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK2FjX2N0X09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQKK2lm
IHRlc3QgLW4gIiRhY19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjUK
KyRhc19lY2hvICIkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDRE9UT1BUIiA9IHg7
IHRoZW4KKyAgICBPQ0FNTENET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29t
cGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5n
IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rv
b2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MQ0RPVE9QVD0kYWNfY3RfT0NBTUxDRE9U
T1BUCisgIGZpCitlbHNlCisgIE9DQU1MQ0RPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BU
IgorZmkKKworICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1Q
VkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4q
XCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsg
dGhlbgorCSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+
JjUKKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRp
c2NhcmRlZC4iID4mNjsgfQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQor
ICAgICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0
ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxPUFRE
T1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiRPQ0FNTE9QVERPVE9Q
VCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MT1BU
RE9UT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKKworZmkKK2ZpCitPQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAor
aWYgdGVzdCAtbiAiJE9DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19l
Y2hvICIkT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIjsg
dGhlbgorICBhY19jdF9PQ0FNTE9QVERPVE9QVD0kT0NBTUxPUFRET1RPUFQKKyAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Citp
ZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
YWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE
T1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUPSJvY2FtbG9wdC5vcHQiCisg
ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25l
CitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERP
VE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1M
T1BURE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisg
IGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFRET1RPUFQiID0geDsgdGhlbgorICAgIE9DQU1MT1BU
RE9UT1BUPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93
YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxl
dCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsK
K2VzYWMKKyAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NBTUxPUFRET1RPUFQKKyAgZmkKK2Vs
c2UKKyAgT0NBTUxPUFRET1RPUFQ9IiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIgorZmkKKwor
CWlmIHRlc3QgIiRPQ0FNTE9QVERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCSAgIFRNUFZFUlNJT049
YCRPQ0FNTE9QVERPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwx
fHAnIGAKKwkgICBpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhl
bgorCSAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiB2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuIiA+
JjUKKyRhc19lY2hvICJ2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBk
aXNjYXJkZWQuIiA+JjY7IH0KKwkgICBlbHNlCisJICAgICAgT0NBTUxPUFQ9JE9DQU1MT1BURE9U
T1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAgZmkKKworCisgIGZpCisKKworCisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAk
e2FjX3Rvb2xfcHJlZml4fW9jYW1sOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJv
Z19PQ0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTD0i
JE9DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NB
TUw9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorT0NBTUw9JGFjX2N2X3Byb2dfT0NBTUwKK2lmIHRlc3QgLW4gIiRPQ0FNTCI7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTCIg
PiY1CiskYXNfZWNobyAiJE9DQU1MIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTCI7IHRoZW4KKyAg
YWNfY3RfT0NBTUw9JE9DQU1MCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWwi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1s
OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dv
cmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTCtzZXR9IiA9
IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0iJGFj
X2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUw9Im9jYW1sIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0
X09DQU1MPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUwi
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3RfT0NBTUwiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1M
IiA9IHg7IHRoZW4KKyAgICBPQ0FNTD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUw9JGFjX2N0X09DQU1MCisgIGZpCitlbHNl
CisgIE9DQU1MPSIkYWNfY3ZfcHJvZ19PQ0FNTCIKK2ZpCisKKworICAjIGNoZWNraW5nIGZvciBv
Y2FtbGRlcAorICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRlcCIsIHNvIGl0IGNh
biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZp
eH1vY2FtbGRlcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxERVAr
c2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQor
ICBpZiB0ZXN0IC1uICIkT0NBTUxERVAiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiRP
Q0FNTERFUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09D
QU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgorICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwor
CitmaQorZmkKK09DQU1MREVQPSRhY19jdl9wcm9nX09DQU1MREVQCitpZiB0ZXN0IC1uICIkT0NB
TUxERVAiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkT0NBTUxERVAiID4mNQorJGFzX2VjaG8gIiRPQ0FNTERFUCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxERVAiOyB0aGVuCisgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAorICAjIEV4
dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRlcDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0
ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxERVAiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9IiRhY19jdF9PQ0FNTERF
UCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09D
QU1MREVQPSJvY2FtbGRlcCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAy
CisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9P
Q0FNTERFUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MREVQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N0X09DQU1MREVQIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxERVAi
ID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAi
eCRhY19jdF9PQ0FNTERFUCIgPSB4OyB0aGVuCisgICAgT0NBTUxERVA9Im5vIgorICBlbHNlCisg
ICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3Mg
dG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp
cGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MREVQPSRh
Y19jdF9PQ0FNTERFUAorICBmaQorZWxzZQorICBPQ0FNTERFUD0iJGFjX2N2X3Byb2dfT0NBTUxE
RVAiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHth
Y190b29sX3ByZWZpeH1vY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MTUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NB
TUxNS1RPUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QPSIkT0NBTUxNS1RPUCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2Zp
CitPQ0FNTE1LVE9QPSRhY19jdl9wcm9nX09DQU1MTUtUT1AKK2lmIHRlc3QgLW4gIiRPQ0FNTE1L
VE9QIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJE9DQU1MTUtUT1AiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LVE9QIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNf
Y3ZfcHJvZ19PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LVE9QPSRPQ0FNTE1LVE9Q
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta3RvcCIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxta3RvcDsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUCtzZXR9IiA9IHNl
dDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtU
T1A9IiRhY19jdF9PQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0ib2NhbWxta3RvcCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE1LVE9QPSRhY19jdl9wcm9nX2FjX2N0X09DQU1M
TUtUT1AKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtUT1Ai
ID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19l
Y2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS1RPUCIgPSB4
OyB0aGVuCisgICAgT0NBTUxNS1RPUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxNS1RPUD0kYWNfY3RfT0NBTUxNS1RPUAor
ICBmaQorZWxzZQorICBPQ0FNTE1LVE9QPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QIgorZmkKKwor
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl
Zml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm
aXh9b2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LTElCK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0
aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxNS0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NBTUxNS0xJ
Qj0kYWNfY3ZfcHJvZ19PQ0FNTE1LTElCCitpZiB0ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TE1LTElCIiA+JjUKKyRhc19lY2hvICIkT0NBTUxNS0xJQiIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NB
TUxNS0xJQiI7IHRoZW4KKyAgYWNfY3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgorICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3Jk
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3Rf
T0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSIkYWNfY3Rf
T0NBTUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MTUtMSUI9Im9jYW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorYWNfY3RfT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCCitpZiB0
ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LTElCIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3RfT0NBTUxNS0xJQiIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MTUtMSUIiID0geDsgdGhlbgorICAg
IE9DQU1MTUtMSUI9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190
b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0
cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz
IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXll
cyA7OworZXNhYworICAgIE9DQU1MTUtMSUI9JGFjX2N0X09DQU1MTUtMSUIKKyAgZmkKK2Vsc2UK
KyAgT0NBTUxNS0xJQj0iJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiIKK2ZpCisKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbGRvYworICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGRvYyIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190
b29sX3ByZWZpeH1vY2FtbGRvYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2df
T0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4m
NgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NB
TUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNl
Cithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wcm9nX09DQU1MRE9DPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgorICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19z
YXZlX0lGUworCitmaQorZmkKK09DQU1MRE9DPSRhY19jdl9wcm9nX09DQU1MRE9DCitpZiB0ZXN0
IC1uICIkT0NBTUxET0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRPQ0FNTERPQyIgPiY2
OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAt
eiAiJGFjX2N2X3Byb2dfT0NBTUxET0MiOyB0aGVuCisgIGFjX2N0X09DQU1MRE9DPSRPQ0FNTERP
QworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRvYzsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0Mrc2V0fSIgPSBzZXQ7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
YWNfY3RfT0NBTUxET0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9IiRhY19j
dF9PQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X2FjX2N0X09DQU1MRE9DPSJvY2FtbGRvYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2Zp
CithY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQworaWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKKyRhc19lY2hvICIkYWNfY3Rf
T0NBTUxET0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9PQ0FNTERPQyIgPSB4OyB0aGVuCisgICAgT0NBTUxET0M9Im5vIgor
ICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVz
OikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNp
bmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19l
Y2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9D
QU1MRE9DPSRhY19jdF9PQ0FNTERPQworICBmaQorZWxzZQorICBPQ0FNTERPQz0iJGFjX2N2X3By
b2dfT0NBTUxET0MiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAorICBpZiB0
ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQ7
IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MQlVJTEQrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIkT0NBTUxC
VUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1M
QlVJTEQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZCIKKyAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK
KworZmkKK2ZpCitPQ0FNTEJVSUxEPSRhY19jdl9wcm9nX09DQU1MQlVJTEQKK2lmIHRlc3QgLW4g
IiRPQ0FNTEJVSUxEIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJE9DQU1MQlVJTEQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTEJVSUxEIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0
IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdF9PQ0FNTEJVSUxEPSRP
Q0FNTEJVSUxECisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxidWlsZCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxidWls
ZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRCtz
ZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MQlVJTEQ9IiRhY19jdF9PQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0ib2NhbWxidWlsZCIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTEJVSUxEPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MQlVJTEQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09D
QU1MQlVJTEQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEJVSUxEIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxC
VUlMRCIgPSB4OyB0aGVuCisgICAgT0NBTUxCVUlMRD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxCVUlMRD0kYWNfY3RfT0NB
TUxCVUlMRAorICBmaQorZWxzZQorICBPQ0FNTEJVSUxEPSIkYWNfY3ZfcHJvZ19PQ0FNTEJVSUxE
IgorZmkKKworCisgICAgaWYgdGVzdCAieCRPQ0FNTEMiID0gInhubyI7IHRoZW4gOgorCisgICAg
ICAgIGlmIHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAg
ICAgICAgICAgYXNfZm5fZXJyb3IgJD8gIk9jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUg
dG8gZmluZCBPY2FtbCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgICAgIG9jYW1sdG9vbHM9Im4iCisK
K2ZpCisKK2ZpCisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJhc2giLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGJhc2g7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgdGVzdCAiJHthY19jdl9wYXRoX0JBU0grc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCQVNIIGluCisgIFtcXC9dKiB8
ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CQVNIPSIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAg
IGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3Qg
LXogIiRhY19jdl9wYXRoX0JBU0giICYmIGFjX2N2X3BhdGhfQkFTSD0ibm8iCisgIDs7Citlc2Fj
CitmaQorQkFTSD0kYWNfY3ZfcGF0aF9CQVNICitpZiB0ZXN0IC1uICIkQkFTSCI7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCQVNIIiA+
JjUKKyRhc19lY2hvICIkQkFTSCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorZmkKKworCitpZiB0ZXN0IHgiJHtCQVNIfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmFzaCwgcGxlYXNlIGluc3RhbGwgYmFzaCIgIiRMSU5F
Tk8iIDUKK2ZpCitpZiB0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSI7IHRoZW4gOgorCisgICAg
aWYgZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyI7IHRoZW4gOgorCisgICAgICAgIFBZVEhP
TlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorCitl
bGlmIHRlc3QgLXogIiRQWVRIT04iOyB0aGVuIDoKKyAgUFlUSE9OPSJweXRob24iCitlbHNlCisg
IGFzX2ZuX2Vycm9yICQ/ICJQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRl
IHBhdGgiICIkTElORU5PIiA1CitmaQorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
JFBZVEhPTiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgJFBZVEhPTjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfUFlUSE9OUEFU
SCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhc2UgJFBZVEhPTlBBVEggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3Bh
dGhfUFlUSE9OUEFUSD0iJFBZVEhPTlBBVEgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1BZVEhPTlBBVEg9IiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAi
JGFjX2N2X3BhdGhfUFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKKyAg
OzsKK2VzYWMKK2ZpCitQWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZVEhPTlBBVEgKK2lmIHRlc3Qg
LW4gIiRQWVRIT05QQVRIIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJFBZVEhPTlBBVEgiID4mNQorJGFzX2VjaG8gIiRQWVRIT05QQVRI
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3Qg
eCIke1BZVEhPTlBBVEh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCAkUFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQor
ZmkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBweXRob24gdmVyc2lvbiA+PSAyLjMgIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBweXRob24gdmVyc2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0
IHN5czsgZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKK2lmIHRlc3Qg
IiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYAor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICAgIGFzX2ZuX2Vycm9yICQ/ICIkcHl0aG9uX3Zl
cnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMyIgIiRMSU5F
Tk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKKyAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRob24geG1s
LmRvbS5taW5pZG9tIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24geG1sLmRv
bS5taW5pZG9tLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20ubWluaWRv
bSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIHhtbC5kb20ubWluaWRvbSBtb2R1
bGUiICIkTElORU5PIiA1CitlbHNlCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KK2ZpCisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
cHl0aG9uIGRldmVsIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24gZGV2ZWwu
Li4gIiA+JjY7IH0KKworYCRQWVRIT04gLWMgJworaW1wb3J0IG9zLnBhdGgsIHN5cworZm9yIHAg
aW4gc3lzLnBhdGg6CisgICAgaWYgb3MucGF0aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxl
Iik6CisgICAgICAgIHN5cy5leGl0KDApCitzeXMuZXhpdCgxKQorJyA+IC9kZXYvbnVsbCAyPiYx
YAorCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CisgICAgYXNfZm5fZXJyb3IgJD8gIlB5dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZCIgIiRM
SU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKKworZmkKKyMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
IHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhHRVRURVhUIGluCisgIFtcXC9d
KiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1hHRVRURVhUPSIkWEdFVFRFWFQiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRo
X1hHRVRURVhUPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hHRVRURVhUIiAmJiBhY19jdl9wYXRoX1hH
RVRURVhUPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitYR0VUVEVYVD0kYWNfY3ZfcGF0aF9YR0VUVEVY
VAoraWYgdGVzdCAtbiAiJFhHRVRURVhUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhHRVRURVhUIiA+JjUKKyRhc19lY2hvICIkWEdF
VFRFWFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYg
dGVzdCB4IiR7WEdFVFRFWFR9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJV
bmFibGUgdG8gZmluZCB4Z2V0dGV4dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5P
IiA1CitmaQoraWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4KKyAgICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInVkZXZhZG0iLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHVkZXZhZG07IGFjX3dvcmQ9JDIKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3Jk
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9wYXRoX1VERVZBRE0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRVREVWQURNIGluCisgIFtcXC9dKiB8
ID86W1xcL10qKQorICBhY19jdl9wYXRoX1VERVZBRE09IiRVREVWQURNIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9VREVW
QURNPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
ID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwor
CisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1VERVZBRE0iICYmIGFjX2N2X3BhdGhfVURFVkFETT0i
bm8iCisgIDs7Citlc2FjCitmaQorVURFVkFETT0kYWNfY3ZfcGF0aF9VREVWQURNCitpZiB0ZXN0
IC1uICIkVURFVkFETSI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRVREVWQURNIiA+JjUKKyRhc19lY2hvICIkVURFVkFETSIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgaWYgdGVzdCB4IiR7
VURFVkFETX0iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgInVkZXZpbmZvIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSB1ZGV2aW5mbzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Bh
dGhfVURFVklORk8rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXNlICRVREVWSU5GTyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAg
YWNfY3ZfcGF0aF9VREVWSU5GTz0iJFVERVZJTkZPIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9VREVWSU5GTz0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9VREVWSU5GTyIgJiYgYWNfY3ZfcGF0aF9VREVWSU5GTz0ibm8iCisgIDs7
Citlc2FjCitmaQorVURFVklORk89JGFjX2N2X3BhdGhfVURFVklORk8KK2lmIHRlc3QgLW4gIiRV
REVWSU5GTyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRVREVWSU5GTyIgPiY1CiskYXNfZWNobyAiJFVERVZJTkZPIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICAgICAgaWYgdGVzdCB4IiR7
VURFVklORk99IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBhc19mbl9lcnJv
ciAkPyAiVW5hYmxlIHRvIGZpbmQgdWRldmFkbSBvciB1ZGV2aW5mbywgcGxlYXNlIGluc3RhbGwg
dWRldiIgIiRMSU5FTk8iIDUKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5G
T30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7
VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVz
dCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICJob3RwbHVnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBob3RwbHVnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0
aF9IT1RQTFVHK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgY2FzZSAkSE9UUExVRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNf
Y3ZfcGF0aF9IT1RQTFVHPSIkSE9UUExVRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl
c3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMK
KyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfSE9UUExVRz0iJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAy
CisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNf
Y3ZfcGF0aF9IT1RQTFVHIiAmJiBhY19jdl9wYXRoX0hPVFBMVUc9Im5vIgorICA7OworZXNhYwor
ZmkKK0hPVFBMVUc9JGFjX2N2X3BhdGhfSE9UUExVRworaWYgdGVzdCAtbiAiJEhPVFBMVUciOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
SE9UUExVRyIgPiY1CiskYXNfZWNobyAiJEhPVFBMVUciID4mNjsgfQorZWxzZQorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2Vj
aG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0g
eCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgYXNfZm5fZXJyb3IgJD8gInVkZXYgaXMg
dG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVyIiAiJExJTkVOTyIgNQorICAg
ICAgICBmaQorICAgIGZpCitlbHNlCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ2
bmNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgdm5jb25maWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wYXRoX1ZOQ09ORklH
K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgY2FzZSAkVk5DT05GSUcgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhf
Vk5DT05GSUc9IiRWTkNPTkZJRyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0
aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfVk5DT05GSUc9IiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3Bh
dGhfVk5DT05GSUciICYmIGFjX2N2X3BhdGhfVk5DT05GSUc9Im5vIgorICA7OworZXNhYworZmkK
K1ZOQ09ORklHPSRhY19jdl9wYXRoX1ZOQ09ORklHCitpZiB0ZXN0IC1uICIkVk5DT05GSUciOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
Vk5DT05GSUciID4mNQorJGFzX2VjaG8gIiRWTkNPTkZJRyIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgaWYgdGVzdCB4IiR7Vk5DT05GSUd9IiA9PSB4
Im5vIgorICAgIHRoZW4KKyAgICAgICAgYXNfZm5fZXJyb3IgJD8gIk5vdCBhIExpbnV4IHN5c3Rl
bSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kIiAiJExJTkVOTyIgNQorICAgIGZpCitmaQorCisKKyMg
Q2hlY2sgbGlicmFyeSBwYXRoCitpZiB0ZXN0IC1kICIkcHJlZml4L2xpYjY0IjsgdGhlbiA6CisK
KyAgICBMSUJfUEFUSD0ibGliNjQiCisKK2Vsc2UKKworICAgIExJQl9QQVRIPSJsaWIiCisKK2Zp
CisKKworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9saWJfYWlvX2lvX3NldHVwK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UworTElCUz0iLWxhaW8gICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0ND
IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1
c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNp
ZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGlvX3NldHVwICgpOwor
aW50CittYWluICgpCit7CityZXR1cm4gaW9fc2V0dXAgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zf
bGliX2Fpb19pb19zZXR1cD15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD1ubwor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2
ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2Fp
b19pb19zZXR1cCIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0g
eCIieWVzOyB0aGVuIDoKKyAgc3lzdGVtX2Fpbz0ieSIKK2Vsc2UKKyAgc3lzdGVtX2Fpbz0ibiIK
K2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgTUQ1IGluIC1sY3J5cHRvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBNRDUg
aW4gLWxjcnlwdG8uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUr
c2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQor
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGNyeXB0byAgJExJQlMiCitj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2
b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJl
dHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90
b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4g
IkMiCisjZW5kaWYKK2NoYXIgTUQ1ICgpOworaW50CittYWluICgpCit7CityZXR1cm4gTUQ1ICgp
OworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PXllcworZWxzZQorICBhY19jdl9s
aWJfY3J5cHRvX01ENT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJT
PSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2Ny
eXB0b19NRDUiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBIQVZFX0xJQkNSWVBUTyAxCitfQUNFT0YKKworICBMSUJTPSItbGNyeXB0byAkTElC
UyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAi
JExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9M
SUJTPSRMSUJTCitMSUJTPSItbGV4dDJmcyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJy
aWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNl
IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisg
ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw
bHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0
MmZzX29wZW4yICgpOworaW50CittYWluICgpCit7CityZXR1cm4gZXh0MmZzX29wZW4yICgpOwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5P
IjsgdGhlbiA6CisgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcworZWxzZQorICBh
Y19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4y
IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID0geCIi
eWVzOyB0aGVuIDoKKyAgbGliZXh0MmZzPSJ5IgorZWxzZQorICBsaWJleHQyZnM9Im4iCitmaQor
CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiR7YWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyK3NldH0iID0gc2V0OyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGli
X3NhdmVfTElCUz0kTElCUworTElCUz0iLWxnY3J5cHQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisv
KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K
KyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh
IEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0
aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitj
aGFyIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBnY3J5
X21kX2hhc2hfYnVmZmVyICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9t
ZF9oYXNoX2J1ZmZlcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hf
YnVmZmVyPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9
CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlciIgPSB4IiJ5
ZXM7IHRoZW4gOgorICBsaWJnY3J5cHQ9InkiCitlbHNlCisgIGxpYmdjcnlwdD0ibiIKK2ZpCisK
KworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
cHRocmVhZF9jcmVhdGUgaW4gLWxwdGhyZWFkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciBwdGhyZWFkX2NyZWF0ZSBpbiAtbHB0aHJlYWQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRM
SUJTCitMSUJTPSItbHB0aHJlYWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIHB0aHJlYWRf
Y3JlYXRlICgpOworaW50CittYWluICgpCit7CityZXR1cm4gcHRocmVhZF9jcmVhdGUgKCk7Cisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGU9eWVzCitlbHNlCisg
IGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlPW5vCitmaQorcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv
bmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9wdGhy
ZWFkX3B0aHJlYWRfY3JlYXRlIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3B0aHJlYWRfcHRo
cmVhZF9jcmVhdGUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfcHRocmVhZF9wdGhyZWFk
X2NyZWF0ZSIgPSB4IiJ5ZXM7IHRoZW4gOgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3Vs
ZCBub3QgZmluZCBsaWJwdGhyZWFkIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgY2xvY2tfZ2V0dGltZSBpbiAt
bHJ0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbG9ja19nZXR0aW1lIGluIC1scnQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUrc2V0fSIg
PSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19j
aGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHJ0ICAkTElCUyIKK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJy
b3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg
b2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs
ZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRp
ZgorY2hhciBjbG9ja19nZXR0aW1lICgpOworaW50CittYWluICgpCit7CityZXR1cm4gY2xvY2tf
Z2V0dGltZSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlf
bGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZT15ZXMK
K2Vsc2UKKyAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9bm8KK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3J0
X2Nsb2NrX2dldHRpbWUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGlt
ZSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA9IHgiInll
czsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJS
VCAxCitfQUNFT0YKKworICBMSUJTPSItbHJ0ICRMSUJTIgorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1s
dXVpZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcitzZXR9IiA9
IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sdXVpZCAgJExJQlMiCitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy
cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl
IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k
aWYKK2NoYXIgdXVpZF9jbGVhciAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHV1aWRfY2xl
YXIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsg
IiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj15ZXMKK2Vsc2UK
KyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlk
X2NsZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY2OyB9
CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID0geCIieWVzOyB0aGVuIDoK
KyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX0xJQlVVSUQgMQorX0FD
RU9GCisKKyAgTElCUz0iLWx1dWlkICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJD
b3VsZCBub3QgZmluZCBsaWJ1dWlkIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlh
amwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4u
ICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mrc2V0fSIgPSBz
ZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHlhamwgICRMSUJTIgorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv
ci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlm
CitjaGFyIHlhamxfYWxsb2MgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiB5YWpsX2FsbG9j
ICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCitlbHNlCisg
IGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3Qu
JGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9h
bGxvYyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQor
aWYgdGVzdCAieCRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHgiInllczsgdGhlbiA6Cisg
IGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKK19BQ0VP
RgorCisgIExJQlM9Ii1seWFqbCAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291
bGQgbm90IGZpbmQgeWFqbCIgIiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1seiIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6Li4uICIgPiY2OyB9
CitpZiB0ZXN0ICIke2FjX2N2X2xpYl96X2RlZmxhdGVDb3B5K3NldH0iID0gc2V0OyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVf
TElCUz0kTElCUworTElCUz0iLWx6ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUg
YW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hh
ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1
aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g
ICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBkZWZsYXRl
Q29weSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGRlZmxhdGVDb3B5ICgpOworICA7Cisg
IHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PXllcworZWxzZQorICBhY19jdl9saWJfel9k
ZWZsYXRlQ29weT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGli
X3pfZGVmbGF0ZUNvcHkiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2RlZmluZSBIQVZFX0xJQlogMQorX0FDRU9GCisKKyAgTElCUz0iLWx6ICRMSUJTIgor
CitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB6bGliIiAiJExJTkVOTyIg
NQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf
Y3ZfbGliX2ljb252X2xpYmljb252X29wZW4rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJT
CitMSUJTPSItbGljb252ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdD
QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNh
dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4g
YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisj
aWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBsaWJpY29udl9vcGVu
ICgpOworaW50CittYWluICgpCit7CityZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGli
X2ljb252X2xpYmljb252X29wZW49bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29w
ZW4iID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY2OyB9
CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA9IHgiInllczsgdGhl
biA6CisgIGxpYmljb252PSJ5IgorZWxzZQorICBsaWJpY29udj0ibiIKK2ZpCisKKworCisjIEF1
dG9zY2FuIHN0dWZmIChleGNlcHQgZm9yIHlhamwveWFqbF92ZXJzaW9uLmggY2hlY2spCisjIENo
ZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgorIyBUaGUgVWx0cml4IDQuMiBtaXBzIGJ1aWx0aW4gYWxs
b2NhIGRlY2xhcmVkIGJ5IGFsbG9jYS5oIG9ubHkgd29ya3MKKyMgZm9yIGNvbnN0YW50IGFyZ3Vt
ZW50cy4gIFVzZWxlc3MhCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciB3b3JraW5nIGFsbG9jYS5oLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3dvcmtp
bmdfYWxsb2NhX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWxsb2NhLmg+CitpbnQKK21haW4g
KCkKK3sKK2NoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDIgKiBzaXplb2YgKGludCkpOworCQkJ
ICBpZiAocCkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD15
ZXMKK2Vsc2UKKyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD1ubworZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3Zfd29ya2luZ19hbGxvY2FfaCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl93b3JraW5nX2FsbG9j
YV9oID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIgPj5j
b25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIGFsbG9jYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgYWxs
b2NhLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzK3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworI2lmZGVmIF9fR05VQ19fCisjIGRlZmluZSBhbGxvY2EgX19idWlsdGluX2FsbG9j
YQorI2Vsc2UKKyMgaWZkZWYgX01TQ19WRVIKKyMgIGluY2x1ZGUgPG1hbGxvYy5oPgorIyAgZGVm
aW5lIGFsbG9jYSBfYWxsb2NhCisjIGVsc2UKKyMgIGlmZGVmIEhBVkVfQUxMT0NBX0gKKyMgICBp
bmNsdWRlIDxhbGxvY2EuaD4KKyMgIGVsc2UKKyMgICBpZmRlZiBfQUlYCisgI3ByYWdtYSBhbGxv
Y2EKKyMgICBlbHNlCisjICAgIGlmbmRlZiBhbGxvY2EgLyogcHJlZGVmaW5lZCBieSBIUCBjYyAr
T2xpYmNhbGxzICovCitjaGFyICphbGxvY2EgKCk7CisjICAgIGVuZGlmCisjICAgZW5kaWYKKyMg
IGVuZGlmCisjIGVuZGlmCisjZW5kaWYKKworaW50CittYWluICgpCit7CitjaGFyICpwID0gKGNo
YXIgKikgYWxsb2NhICgxKTsKKwkJCQkgICAgaWYgKHApIHJldHVybiAwOworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPXllcworZWxzZQorICBhY19jdl9mdW5jX2FsbG9jYV93
b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
XAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2FsbG9j
YV93b3JrcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjY7IH0K
KworaWYgdGVzdCAkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MgPSB5ZXM7IHRoZW4KKworJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9BTExPQ0EgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgIyBUaGUg
U1ZSMyBsaWJQVyBhbmQgU1ZSNCBsaWJ1Y2IgYm90aCBjb250YWluIGluY29tcGF0aWJsZSBmdW5j
dGlvbnMKKyMgdGhhdCBjYXVzZSB0cm91YmxlLiAgU29tZSB2ZXJzaW9ucyBkbyBub3QgZXZlbiBj
b250YWluIGFsbG9jYSBvcgorIyBjb250YWluIGEgYnVnZ3kgdmVyc2lvbi4gIElmIHlvdSBzdGls
bCB3YW50IHRvIHVzZSB0aGVpciBhbGxvY2EsCisjIHVzZSBhciB0byBleHRyYWN0IGFsbG9jYS5v
IGZyb20gdGhlbSBpbnN0ZWFkIG9mIGNvbXBpbGluZyBhbGxvY2EuYy4KKworQUxMT0NBPVwke0xJ
Qk9CSkRJUn1hbGxvY2EuJGFjX29iamV4dAorCiskYXNfZWNobyAiI2RlZmluZSBDX0FMTE9DQSAx
IiA+PmNvbmZkZWZzLmgKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3Mu
Li4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zfb3NfY3JheStzZXR9IiA9IHNldDsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBk
ZWZpbmVkIENSQVkgJiYgISBkZWZpbmVkIENSQVkyCit3ZWJlY3JheQorI2Vsc2UKK3dlbm90YmVj
cmF5CisjZW5kaWYKKworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0
IikgMj4mNSB8CisgICRFR1JFUCAid2ViZWNyYXkiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Cisg
IGFjX2N2X29zX2NyYXk9eWVzCitlbHNlCisgIGFjX2N2X29zX2NyYXk9bm8KK2ZpCitybSAtZiBj
b25mdGVzdCoKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3Zfb3NfY3JheSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4m
NjsgfQoraWYgdGVzdCAkYWNfY3Zfb3NfY3JheSA9IHllczsgdGhlbgorICBmb3IgYWNfZnVuYyBp
biBfZ2V0YjY3IEdFVEI2NyBnZXRiNjc7IGRvCisgICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNf
Y3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5F
Tk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3Zh
ciJcIiA9IHgieWVzIjsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZp
bmUgQ1JBWV9TVEFDS1NFR19FTkQgJGFjX2Z1bmMKK19BQ0VPRgorCisgICAgYnJlYWsKK2ZpCisK
KyAgZG9uZQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBzdGFjayBkaXJlY3Rpb24gZm9yIEMgYWxsb2NhIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIHN0YWNrIGRpcmVjdGlvbiBmb3IgQyBhbGxvY2EuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg
IiR7YWNfY3ZfY19zdGFja19kaXJlY3Rpb24rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9
IHllczsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPTAKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2ludAorZmluZF9zdGFja19kaXJlY3Rpb24gKCkK
K3sKKyAgc3RhdGljIGNoYXIgKmFkZHIgPSAwOworICBhdXRvIGNoYXIgZHVtbXk7CisgIGlmIChh
ZGRyID09IDApCisgICAgeworICAgICAgYWRkciA9ICZkdW1teTsKKyAgICAgIHJldHVybiBmaW5k
X3N0YWNrX2RpcmVjdGlvbiAoKTsKKyAgICB9CisgIGVsc2UKKyAgICByZXR1cm4gKCZkdW1teSA+
IGFkZHIpID8gMSA6IC0xOworfQorCitpbnQKK21haW4gKCkKK3sKKyAgcmV0dXJuIGZpbmRfc3Rh
Y2tfZGlyZWN0aW9uICgpIDwgMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPTEKK2Vsc2UKKyAgYWNfY3Zf
Y19zdGFja19kaXJlY3Rpb249LTEKK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0
LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3N0YWNrX2Rp
cmVjdGlvbiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjY7IH0K
K2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgU1RBQ0tfRElSRUNUSU9OICRhY19j
dl9jX3N0YWNrX2RpcmVjdGlvbgorX0FDRU9GCisKKworZmkKKworZm9yIGFjX2hlYWRlciBpbiAg
XAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRs
LmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9p
bi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAgICAgICAgICAg
ICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0u
aCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUu
aCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFq
bF92ZXJzaW9uLmggXAorCitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hl
YWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdy
ZWwgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRo
ZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFW
RV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKKwor
IyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVy
aXN0aWNzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMgdG8gQzk5IiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0byBDOTkuLi4gIiA+JjY7IH0KK2lm
IHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF
T0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworI2luY2x1ZGUg
PHN0ZGJvb2wuaD4KKyNpZm5kZWYgYm9vbAorICJlcnJvcjogYm9vbCBpcyBub3QgZGVmaW5lZCIK
KyNlbmRpZgorI2lmbmRlZiBmYWxzZQorICJlcnJvcjogZmFsc2UgaXMgbm90IGRlZmluZWQiCisj
ZW5kaWYKKyNpZiBmYWxzZQorICJlcnJvcjogZmFsc2UgaXMgbm90IDAiCisjZW5kaWYKKyNpZm5k
ZWYgdHJ1ZQorICJlcnJvcjogdHJ1ZSBpcyBub3QgZGVmaW5lZCIKKyNlbmRpZgorI2lmIHRydWUg
IT0gMQorICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIKKyNlbmRpZgorI2lmbmRlZiBfX2Jvb2xfdHJ1
ZV9mYWxzZV9hcmVfZGVmaW5lZAorICJlcnJvcjogX19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmlu
ZWQgaXMgbm90IGRlZmluZWQiCisjZW5kaWYKKworCXN0cnVjdCBzIHsgX0Jvb2wgczogMTsgX0Jv
b2wgdDsgfSBzOworCisJY2hhciBhW3RydWUgPT0gMSA/IDEgOiAtMV07CisJY2hhciBiW2ZhbHNl
ID09IDAgPyAxIDogLTFdOworCWNoYXIgY1tfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZCA9
PSAxID8gMSA6IC0xXTsKKwljaGFyIGRbKGJvb2wpIDAuNSA9PSB0cnVlID8gMSA6IC0xXTsKKwli
b29sIGUgPSAmczsKKwljaGFyIGZbKF9Cb29sKSAwLjAgPT0gZmFsc2UgPyAxIDogLTFdOworCWNo
YXIgZ1t0cnVlXTsKKwljaGFyIGhbc2l6ZW9mIChfQm9vbCldOworCWNoYXIgaVtzaXplb2Ygcy50
XTsKKwllbnVtIHsgaiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRy
dWUgKiAyNTYgfTsKKwkvKiBUaGUgZm9sbG93aW5nIGZhaWxzIGZvcgorCSAgIEhQIGFDKysvQU5T
SSBDIEIzOTEwQiBBLjA1LjU1IFtEZWMgMDQgMjAwM10uICovCisJX0Jvb2wgblttXTsKKwljaGFy
IG9bc2l6ZW9mIG4gPT0gbSAqIHNpemVvZiBuWzBdID8gMSA6IC0xXTsKKwljaGFyIHBbLTEgLSAo
X0Jvb2wpIDAgPCAwICYmIC0xIC0gKGJvb2wpIDAgPCAwID8gMSA6IC0xXTsKKyMJaWYgZGVmaW5l
ZCBfX3hsY19fIHx8IGRlZmluZWQgX19HTlVDX18KKwkgLyogQ2F0Y2ggYSBidWcgaW4gSUJNIEFJ
WCB4bGMgY29tcGlsZXIgdmVyc2lvbiA2LjAuMC4wCisJICAgIHJlcG9ydGVkIGJ5IEphbWVzIExl
bWxleSBvbiAyMDA1LTEwLTA1OyBzZWUKKwkgICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2
ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMC9tc2cwMDA4Ni5odG1sCisJICAgIFRoaXMgdGVz
dCBpcyBub3QgcXVpdGUgcmlnaHQsIHNpbmNlIHhsYyBpcyBhbGxvd2VkIHRvCisJICAgIHJlamVj
dCB0aGlzIHByb2dyYW0sIGFzIHRoZSBpbml0aWFsaXplciBmb3IgeGxjYnVnIGlzCisJICAgIG5v
dCBvbmUgb2YgdGhlIGZvcm1zIHRoYXQgQyByZXF1aXJlcyBzdXBwb3J0IGZvci4KKwkgICAgSG93
ZXZlciwgZG9pbmcgdGhlIHRlc3QgcmlnaHQgd291bGQgcmVxdWlyZSBhIHJ1bnRpbWUKKwkgICAg
dGVzdCwgYW5kIHRoYXQgd291bGQgbWFrZSBjcm9zcy1jb21waWxhdGlvbiBoYXJkZXIuCisJICAg
IExldCB1cyBob3BlIHRoYXQgSUJNIGZpeGVzIHRoZSB4bGMgYnVnLCBhbmQgYWxzbyBhZGRzCisJ
ICAgIHN1cHBvcnQgZm9yIHRoaXMga2luZCBvZiBjb25zdGFudCBleHByZXNzaW9uLiAgSW4gdGhl
CisJICAgIG1lYW50aW1lLCB0aGlzIHRlc3Qgd2lsbCByZWplY3QgeGxjLCB3aGljaCBpcyBPSywg
c2luY2UKKwkgICAgb3VyIHN0ZGJvb2wuaCBzdWJzdGl0dXRlIHNob3VsZCBzdWZmaWNlLiAgV2Ug
YWxzbyB0ZXN0CisJICAgIHRoaXMgd2l0aCBHQ0MsIHdoZXJlIGl0IHNob3VsZCB3b3JrLCB0byBk
ZXRlY3QgbW9yZQorCSAgICBxdWlja2x5IHdoZXRoZXIgc29tZW9uZSBtZXNzZXMgdXAgdGhlIHRl
c3QgaW4gdGhlCisJICAgIGZ1dHVyZS4gICovCisJIGNoYXIgZGlnc1tdID0gIjAxMjM0NTY3ODki
OworCSBpbnQgeGxjYnVnID0gMSAvICgmKGRpZ3MgKyA1KVstMiArIChib29sKSAxXSA9PSAmZGln
c1s0XSA/IDEgOiAtMSk7CisjCWVuZGlmCisJLyogQ2F0Y2ggYSBidWcgaW4gYW4gSFAtVVggQyBj
b21waWxlci4gIFNlZQorCSAgIGh0dHA6Ly9nY2MuZ251Lm9yZy9tbC9nY2MtcGF0Y2hlcy8yMDAz
LTEyL21zZzAyMzAzLmh0bWwKKwkgICBodHRwOi8vbGlzdHMuZ251Lm9yZy9hcmNoaXZlL2h0bWwv
YnVnLWNvcmV1dGlscy8yMDA1LTExL21zZzAwMTYxLmh0bWwKKwkgKi8KKwlfQm9vbCBxID0gdHJ1
ZTsKKwlfQm9vbCAqcHEgPSAmcTsKKworaW50CittYWluICgpCit7CisKKwkqcHEgfD0gcTsKKwkq
cHEgfD0gISBxOworCS8qIFJlZmVyIHRvIGV2ZXJ5IGRlY2xhcmVkIHZhbHVlLCB0byBhdm9pZCBj
b21waWxlciBvcHRpbWl6YXRpb25zLiAgKi8KKwlyZXR1cm4gKCFhICsgIWIgKyAhYyArICFkICsg
IWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFrICsgISFsCisJCSsgIW0gKyAhbiArICFv
ICsgIXAgKyAhcSArICFwcSk7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3RkYm9v
bF9oPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYm9vbF9oPW5vCitmaQorcm0gLWYgY29y
ZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9o
ZWFkZXJfc3RkYm9vbF9oIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCIg
PiY2OyB9CithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJfQm9vbCIgImFjX2N2X3R5cGVf
X0Jvb2wiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9fQm9v
bCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IEhBVkVfX0JPT0wgMQorX0FDRU9GCisKKworZmkKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0
ZGJvb2xfaCA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX1NUREJPT0xfSCAx
IiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5oLi4uICIgPiY2OyB9CitpZiB0ZXN0
ICIke2FjX2N2X3R5cGVfdWlkX3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+
CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAor
ICAkRUdSRVAgInVpZF90IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBhY19jdl90eXBlX3Vp
ZF90PXllcworZWxzZQorICBhY19jdl90eXBlX3VpZF90PW5vCitmaQorcm0gLWYgY29uZnRlc3Qq
CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X3R5cGVfdWlkX3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl90eXBlX3VpZF90IiA+JjY7
IH0KK2lmIHRlc3QgJGFjX2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgorCiskYXNfZWNobyAiI2Rl
ZmluZSB1aWRfdCBpbnQiID4+Y29uZmRlZnMuaAorCisKKyRhc19lY2hvICIjZGVmaW5lIGdpZF90
IGludCIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgaW5saW5lLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2NfaW5saW5lK3NldH0i
ID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNf
Y3ZfY19pbmxpbmU9bm8KK2ZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxpbmVfXyBfX2lubGluZTsg
ZG8KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cwordHlwZWRlZiBpbnQgZm9vX3Q7
CitzdGF0aWMgJGFjX2t3IGZvb190IHN0YXRpY19mb28gKCkge3JldHVybiAwOyB9CiskYWNfa3cg
Zm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQorI2VuZGlmCisKK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9jX2lubGluZT0kYWNfa3cKK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKKyAgdGVzdCAiJGFjX2N2X2NfaW5saW5lIiAhPSBubyAmJiBicmVhaworZG9uZQorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9jX2lubGluZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2NfaW5saW5lIiA+JjY7IH0KKworY2Fz
ZSAkYWNfY3ZfY19pbmxpbmUgaW4KKyAgaW5saW5lIHwgeWVzKSA7OworICAqKQorICAgIGNhc2Ug
JGFjX2N2X2NfaW5saW5lIGluCisgICAgICBubykgYWNfdmFsPTs7CisgICAgICAqKSBhY192YWw9
JGFjX2N2X2NfaW5saW5lOzsKKyAgICBlc2FjCisgICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
RgorI2lmbmRlZiBfX2NwbHVzcGx1cworI2RlZmluZSBpbmxpbmUgJGFjX3ZhbAorI2VuZGlmCitf
QUNFT0YKKyAgICA7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiMTYi
ICJhY19jdl9jX2ludDE2X3QiCitjYXNlICRhY19jdl9jX2ludDE2X3QgaW4gIygKKyAgbm98eWVz
KSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDE2
X3QgJGFjX2N2X2NfaW50MTZfdAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50
WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX2ludDMyX3QiCitjYXNlICRhY19jdl9jX2ludDMy
X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCisjZGVmaW5lIGludDMyX3QgJGFjX2N2X2NfaW50MzJfdAorX0FDRU9GCis7OworZXNhYwor
CithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0X3QiCitj
YXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitjYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDY0X3QgJGFjX2N2X2NfaW50NjRfdAor
X0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIgImFj
X2N2X2NfaW50OF90IgorY2FzZSAkYWNfY3ZfY19pbnQ4X3QgaW4gIygKKyAgbm98eWVzKSA7OyAj
KAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDhfdCAkYWNf
Y3ZfY19pbnQ4X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19jaGVja190eXBlICIkTElO
RU5PIiAibW9kZV90IiAiYWNfY3ZfdHlwZV9tb2RlX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIK
K2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9tb2RlX3QiID0geCIieWVzOyB0aGVuIDoKKworZWxzZQor
CitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIG1vZGVfdCBpbnQKK19BQ0VPRgor
CitmaQorCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2X3R5cGVf
b2ZmX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZf
dCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
KyNkZWZpbmUgb2ZmX3QgbG9uZyBpbnQKK19BQ0VPRgorCitmaQorCithY19mbl9jX2NoZWNrX3R5
cGUgIiRMSU5FTk8iICJwaWRfdCIgImFjX2N2X3R5cGVfcGlkX3QiICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9waWRfdCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitl
bHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgcGlkX3QgaW50CitfQUNF
T0YKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j
dl9jX3Jlc3RyaWN0K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgYWNfY3ZfY19yZXN0cmljdD1ubworICAgIyBUaGUgb3JkZXIgaGVyZSBj
YXRlcnMgdG8gdGhlIGZhY3QgdGhhdCBDKysgZG9lcyBub3QgcmVxdWlyZSByZXN0cmljdC4KKyAg
IGZvciBhY19rdyBpbiBfX3Jlc3RyaWN0IF9fcmVzdHJpY3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7
IGRvCisgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KK3R5cGVkZWYgaW50ICogaW50X3B0cjsKKwlpbnQgZm9vIChp
bnRfcHRyICRhY19rdyBpcCkgeworCXJldHVybiBpcFswXTsKKyAgICAgICB9CitpbnQKK21haW4g
KCkKK3sKK2ludCBzWzFdOworCWludCAqICRhY19rdyB0ID0gczsKKwl0WzBdID0gMDsKKwlyZXR1
cm4gZm9vKHQpCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2Nv
bXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19yZXN0cmljdD0kYWNfa3cKK2ZpCity
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKKyAgICAgdGVzdCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJyZWFrCisgICBkb25l
CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX2N2X2NfcmVzdHJpY3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX3Jlc3RyaWN0IiA+JjY7
IH0KKworIGNhc2UgJGFjX2N2X2NfcmVzdHJpY3QgaW4KKyAgIHJlc3RyaWN0KSA7OworICAgbm8p
ICRhc19lY2hvICIjZGVmaW5lIHJlc3RyaWN0IC8qKi8iID4+Y29uZmRlZnMuaAorIDs7CisgICAq
KSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSByZXN0cmljdCAkYWNfY3ZfY19y
ZXN0cmljdAorX0FDRU9GCisgOzsKKyBlc2FjCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVO
TyIgInNpemVfdCIgImFjX2N2X3R5cGVfc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitp
ZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc2l6ZV90IiA9IHgiInllczsgdGhlbiA6CisKK2Vsc2UKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBzaXplX3QgdW5zaWduZWQgaW50Citf
QUNFT0YKKworZmkKKworYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic3NpemVfdCIgImFj
X2N2X3R5cGVfc3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl90eXBlX3NzaXplX3QiID0geCIieWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIHNzaXplX3QgaW50CitfQUNFT0YKKworZmkKKworYWNfZm5f
Y19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X2Jsa3NpemUiICJhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igor
aWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4IiJ5ZXM7
IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfU1RSVUNU
X1NUQVRfU1RfQkxLU0laRSAxCitfQUNFT0YKKworCitmaQorCithY19mbl9jX2NoZWNrX21lbWJl
ciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVj
dF9zdGF0X3N0X2Jsb2NrcyIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tzIiA9IHgiInllczsgdGhlbiA6CisKK2NhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1Mg
MQorX0FDRU9GCisKKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9TVF9CTE9DS1MgMSIgPj5jb25m
ZGVmcy5oCisKK2Vsc2UKKyAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgZmlsZWJsb2Nrcy4k
YWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgZmlsZWJsb2Nrcy4kYWNf
b2JqZXh0IgorIDs7Citlc2FjCisKK2ZpCisKKworYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5F
Tk8iICJzdHJ1Y3Qgc3RhdCIgInN0X3JkZXYiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3Rf
cmRldiIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3Ry
dWN0X3N0YXRfc3RfcmRldiIgPSB4IiJ5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfUkRFViAxCitfQUNFT0YKKworCitm
aQorCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY191aW50MTZf
dCIKK2Nhc2UgJGFjX2N2X2NfdWludDE2X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQor
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgdWludDE2X3QgJGFjX2N2X2Nf
dWludDE2X3QKK19BQ0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJ
TkVOTyIgIjMyIiAiYWNfY3ZfY191aW50MzJfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDMyX3QgaW4g
IygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBfVUlOVDMyX1Qg
MSIgPj5jb25mZGVmcy5oCisKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1
aW50MzJfdCAkYWNfY3ZfY191aW50MzJfdAorX0FDRU9GCis7OworICBlc2FjCisKK2FjX2ZuX2Nf
ZmluZF91aW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX3VpbnQ2NF90IgorY2FzZSAkYWNf
Y3ZfY191aW50NjRfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKKyRhc19lY2hvICIj
ZGVmaW5lIF9VSU5UNjRfVCAxIiA+PmNvbmZkZWZzLmgKKworCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIHVpbnQ2NF90ICRhY19jdl9jX3VpbnQ2NF90CitfQUNFT0YKKzs7Cisg
IGVzYWMKKworYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8iICI4IiAiYWNfY3ZfY191aW50
OF90IgorY2FzZSAkYWNfY3ZfY191aW50OF90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikK
KworJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ4X1QgMSIgPj5jb25mZGVmcy5oCisKKworY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1aW50OF90ICRhY19jdl9jX3VpbnQ4X3QKK19B
Q0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJwdHJkaWZm
X3QiICJhY19jdl90eXBlX3B0cmRpZmZfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl90eXBlX3B0cmRpZmZfdCIgPSB4IiJ5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25m
ZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfUFRSRElGRl9UIDEKK19BQ0VPRgorCisKK2Zp
CisKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQoraWYgdGVz
dCAiJHthY19jdl9saWJfZXJyb3JfYXRfbGluZStzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxlcnJv
ci5oPgoraW50CittYWluICgpCit7CitlcnJvcl9hdF9saW5lICgwLCAwLCAiIiwgMCwgImFuIGVy
cm9yIG9jY3VycmVkIik7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVz
CitlbHNlCisgIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPW5vCitmaQorcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfbGliX2Vycm9yX2F0X2xpbmUiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfbGliX2Vycm9yX2F0
X2xpbmUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBlcnJvci4kYWNf
b2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgZXJyb3IuJGFjX29iamV4dCIK
KyA7OworZXNhYworCitmaQorCitmb3IgYWNfaGVhZGVyIGluIHZmb3JrLmgKK2RvIDoKKyAgYWNf
Zm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInZmb3JrLmgiICJhY19jdl9oZWFk
ZXJfdmZvcmtfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFk
ZXJfdmZvcmtfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjZGVmaW5lIEhBVkVfVkZPUktfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCitmb3IgYWNf
ZnVuYyBpbiBmb3JrIHZmb3JrCitkbyA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1
bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAi
JGFjX2Z1bmMiICIkYXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIg
PSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAk
YXNfZWNobyAiSEFWRV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKK2Rv
bmUKKworaWYgdGVzdCAieCRhY19jdl9mdW5jX2ZvcmsiID0geHllczsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIGZv
cmsiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yay4uLiAiID4mNjsg
fQoraWYgdGVzdCAiJHthY19jdl9mdW5jX2Zvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1jcm9zcworZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50CittYWluICgpCit7CisK
KwkgIC8qIEJ5IFJ1ZWRpZ2VyIEt1aGxtYW5uLiAqLworCSAgcmV0dXJuIGZvcmsgKCkgPCAwOwor
CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVO
TyI7IHRoZW4gOgorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCitlbHNlCisgIGFjX2N2X2Z1
bmNfZm9ya193b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBn
bW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfZm9ya193b3Jr
cyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9CisKK2Vsc2UK
KyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPSRhY19jdl9mdW5jX2ZvcmsKK2ZpCitpZiB0ZXN0ICJ4
JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KKyAgY2FzZSAkaG9zdCBpbgor
ICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3BwKikKKyAgICAgICMgT3ZlcnJpZGUsIGFz
IHRoZXNlIHN5c3RlbXMgaGF2ZSBvbmx5IGEgZHVtbXkgZm9yaygpIHN0dWIKKyAgICAgIGFjX2N2
X2Z1bmNfZm9ya193b3Jrcz1ubworICAgICAgOzsKKyAgICAqKQorICAgICAgYWNfY3ZfZnVuY19m
b3JrX3dvcmtzPXllcworICAgICAgOzsKKyAgZXNhYworICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19mb3JrX3dvcmtz
IGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1
c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorYWNfY3ZfZnVuY192Zm9ya193b3Jr
cz0kYWNfY3ZfZnVuY192Zm9yaworaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrIiA9IHh5ZXM7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3Igd29ya2luZyB2Zm9yayIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2lu
ZyB2Zm9yay4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX3Zmb3JrX3dvcmtzK3Nl
dH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzPWNyb3NzCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIFRoYW5rcyB0byBQYXVsIEVn
Z2VydCBmb3IgdGhpcyB0ZXN0LiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisjaW5jbHVkZSA8
c3lzL3dhaXQuaD4KKyNpZmRlZiBIQVZFX1ZGT1JLX0gKKyMgaW5jbHVkZSA8dmZvcmsuaD4KKyNl
bmRpZgorLyogT24gc29tZSBzcGFyYyBzeXN0ZW1zLCBjaGFuZ2VzIGJ5IHRoZSBjaGlsZCB0byBs
b2NhbCBhbmQgaW5jb21pbmcKKyAgIGFyZ3VtZW50IHJlZ2lzdGVycyBhcmUgcHJvcGFnYXRlZCBi
YWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGlsZXIKKyAgIGlzIHRvbGQgYWJvdXQgdGhpcyB3
aXRoICNpbmNsdWRlIDx2Zm9yay5oPiwgYnV0IHNvbWUgY29tcGlsZXJzCisgICAoZS5nLiBnY2Mg
LU8pIGRvbid0IGdyb2sgPHZmb3JrLmg+LiAgVGVzdCBmb3IgdGhpcyBieSB1c2luZyBhCisgICBz
dGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVzcyBpcyBwdXQgaW50byBhIHJlZ2lzdGVyIHRoYXQg
aXMKKyAgIGNsb2JiZXJlZCBieSB0aGUgdmZvcmsuICAqLworc3RhdGljIHZvaWQKKyNpZmRlZiBf
X2NwbHVzcGx1cworc3BhcmNfYWRkcmVzc190ZXN0IChpbnQgYXJnKQorIyBlbHNlCitzcGFyY19h
ZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsKKyNlbmRpZgoreworICBzdGF0aWMgcGlkX3QgY2hp
bGQ7CisgIGlmICghY2hpbGQpIHsKKyAgICBjaGlsZCA9IHZmb3JrICgpOworICAgIGlmIChjaGls
ZCA8IDApIHsKKyAgICAgIHBlcnJvciAoInZmb3JrIik7CisgICAgICBfZXhpdCgyKTsKKyAgICB9
CisgICAgaWYgKCFjaGlsZCkgeworICAgICAgYXJnID0gZ2V0cGlkKCk7CisgICAgICB3cml0ZSgt
MSwgIiIsIDApOworICAgICAgX2V4aXQgKGFyZyk7CisgICAgfQorICB9Cit9CisKK2ludAorbWFp
biAoKQoreworICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7CisgIHBpZF90IGNoaWxkOworCisg
IHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7CisKKyAgY2hpbGQgPSB2Zm9yayAoKTsKKworICBpZiAo
Y2hpbGQgPT0gMCkgeworICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0ZXN0IGZvciBzcGFyYyB2Zm9y
ayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKKyAgICAgICB0ZXN0IHVzZXMgbG90cyBvZiBsb2Nh
bCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1hbnkgbG9jYWwKKyAgICAgICB2YXJpYWJsZXMgYXMg
bWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBpbmNsdWRpbmcgY29tcGlsZXIKKyAgICAgICB0ZW1w
b3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9yIGdjYyAxLjQwLjMgb24gYSBTb2xhcmlz
CisgICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3ZSB1c2UgOCB0byBiZSBzYWZlLiAgQSBidWdneSBj
b21waWxlciBzaG91bGQKKyAgICAgICByZXVzZSB0aGUgcmVnaXN0ZXIgb2YgcGFyZW50IGZvciBv
bmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywKKyAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRo
YXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJlIHVzZWQgYW55IG1vcmUKKyAgICAgICBpbiB0aGlz
IHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhlIGxvY2FsIHZhcmlhYmxlIHdpbGwgdGh1cworICAg
ICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFyZW50IHByb2Nlc3MuICAqLworICAgIHBpZF90Cisg
ICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0cGlkKCksIHAyID0gZ2V0cGlkKCksIHAzID0gZ2V0
cGlkKCksCisgICAgICBwNCA9IGdldHBpZCgpLCBwNSA9IGdldHBpZCgpLCBwNiA9IGdldHBpZCgp
LCBwNyA9IGdldHBpZCgpOworICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3
IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1pZ2h0CisgICAgICAgdXNlIHRoZSBzYW1lIGhhcmR3
YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2NhbCB2YXJpYWJsZXMuICAqLworICAgIGlmIChwICE9
IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8fCBwICE9IHA0CisJfHwgcCAhPSBwNSB8fCBwICE9
IHA2IHx8IHAgIT0gcDcpCisgICAgICBfZXhpdCgxKTsKKworICAgIC8qIE9uIHNvbWUgc3lzdGVt
cyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50CisgICAgICAg
ZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3JzLiAgSWYgdGhlIGNoaWxkIGNsb3NlcyBhIGRlc2Ny
aXB0b3IKKyAgICAgICBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMsIHRoaXMgbXVuZ2VzIHRoZSBw
YXJlbnQncyBkZXNjcmlwdG9yCisgICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRoaXMgYnkgY2xv
c2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KKyAgICBfZXhpdChjbG9zZShmaWxlbm8oc3Rk
b3V0KSkgIT0gMCk7CisgIH0gZWxzZSB7CisgICAgaW50IHN0YXR1czsKKyAgICBzdHJ1Y3Qgc3Rh
dCBzdDsKKworICAgIHdoaWxlICh3YWl0KCZzdGF0dXMpICE9IGNoaWxkKQorICAgICAgOworICAg
IHJldHVybiAoCisJIC8qIFdhcyB0aGVyZSBzb21lIHByb2JsZW0gd2l0aCB2Zm9ya2luZz8gICov
CisJIGNoaWxkIDwgMAorCisJIC8qIERpZCB0aGUgY2hpbGQgZmFpbD8gIChUaGlzIHNob3VsZG4n
dCBoYXBwZW4uKSAgKi8KKwkgfHwgc3RhdHVzCisKKwkgLyogRGlkIHRoZSB2Zm9yay9jb21waWxl
ciBidWcgb2NjdXI/ICAqLworCSB8fCBwYXJlbnQgIT0gZ2V0cGlkKCkKKworCSAvKiBEaWQgdGhl
IGZpbGUgZGVzY3JpcHRvciBidWcgb2NjdXI/ICAqLworCSB8fCBmc3RhdChmaWxlbm8oc3Rkb3V0
KSwgJnN0KSAhPSAwCisJICk7CisgIH0KK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9eWVzCitlbHNlCisgIGFj
X2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0
ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY2OyB9
CisKK2ZpOworaWYgdGVzdCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geGNyb3NzOyB0aGVu
CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1bmNfdmZvcmsKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY192Zm9ya193b3Jr
cyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorCitpZiB0
ZXN0ICJ4JGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID0geHllczsgdGhlbgorCiskYXNfZWNobyAi
I2RlZmluZSBIQVZFX1dPUktJTkdfVkZPUksgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKworJGFz
X2VjaG8gIiNkZWZpbmUgdmZvcmsgZm9yayIgPj5jb25mZGVmcy5oCisKK2ZpCitpZiB0ZXN0ICJ4
JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5l
IEhBVkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBfTEFSR0VGSUxFX1NPVVJD
RSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBfTEFSR0VGSUxFX1NPVVJDRSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzLi4uICIg
PiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlK3NldH0iID0gc2V0
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgd2hpbGUgOjsg
ZG8KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8K
KyAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK2ludCAoKmZwKSAoRklM
RSAqLCBvZmZfdCwgaW50KSA9IGZzZWVrbzsKKyAgICAgcmV0dXJuIGZzZWVrbyAoc3RkaW4sIDAs
IDApICYmIGZwIChzdGRpbiwgMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfc3lzX2xhcmdlZmls
ZV9zb3VyY2U9bm87IGJyZWFrCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3Qu
JGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAxCisjaW5jbHVkZSA8c3lzL3R5
cGVzLmg+IC8qIGZvciBvZmZfdCAqLworICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFp
biAoKQoreworaW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOworICAgICBy
ZXR1cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT0xOyBicmVhaworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPXVua25vd24K
KyAgYnJlYWsKK2RvbmUKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjUKKyRhc19lY2hvICIk
YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNjsgfQorY2FzZSAkYWNfY3Zfc3lzX2xhcmdl
ZmlsZV9zb3VyY2UgaW4gIygKKyAgbm8gfCB1bmtub3duKSA7OworICAqKQorY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdl
ZmlsZV9zb3VyY2UKK19BQ0VPRgorOzsKK2VzYWMKK3JtIC1yZiBjb25mdGVzdCoKKworIyBXZSB1
c2VkIHRvIHRyeSBkZWZpbmluZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5k
IGEgYnVnCisjIGluIGdsaWJjIDIuMS4zLCBidXQgdGhhdCBicmVha3MgdG9vIG1hbnkgb3RoZXIg
dGhpbmdzLgorIyBJZiB5b3Ugd2FudCBmc2Vla28gYW5kIGZ0ZWxsbyB3aXRoIGdsaWJjLCB1cGdy
YWRlIHRvIGEgZml4ZWQgZ2xpYmMuCitpZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJj
ZSAhPSB1bmtub3duOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+
Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMgdHJhaWxpbmcgc2xh
c2giID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFu
ZGxlcyB0cmFpbGluZyBzbGFzaC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX2xz
dGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBybSAtZiBjb25mdGVzdC5zeW0gY29u
ZnRlc3QuZmlsZQorZWNobyA+Y29uZnRlc3QuZmlsZQoraWYgdGVzdCAiJGFzX2xuX3MiID0gImxu
IC1zIiAmJiBsbiAtcyBjb25mdGVzdC5maWxlIGNvbmZ0ZXN0LnN5bTsgdGhlbgorICBpZiB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbHN0YXRfZGVy
ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5j
bHVkZXNfZGVmYXVsdAoraW50CittYWluICgpCit7CitzdHJ1Y3Qgc3RhdCBzYnVmOworICAgICAv
KiBMaW51eCB3aWxsIGRlcmVmZXJlbmNlIHRoZSBzeW1saW5rIGFuZCBmYWlsLCBhcyByZXF1aXJl
ZCBieSBQT1NJWC4KKwlUaGF0IGlzIGJldHRlciBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBtZWFucyB3
ZSB3aWxsIG5vdAorCWhhdmUgdG8gY29tcGlsZSBhbmQgdXNlIHRoZSBsc3RhdCB3cmFwcGVyLiAg
Ki8KKyAgICAgcmV0dXJuIGxzdGF0ICgiY29uZnRlc3Quc3ltLyIsICZzYnVmKSA9PSAwOworICA7
CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0
aGVuIDoKKyAgYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXll
cworZWxzZQorICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9
bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0
IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVh
bSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitlbHNlCisgICMgSWYgdGhlIGBsbiAtcycgY29tbWFu
ZCBmYWlsZWQsIHRoZW4gd2UgcHJvYmFibHkgZG9uJ3QgZXZlbgorICAjIGhhdmUgYW4gbHN0YXQg
ZnVuY3Rpb24uCisgIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGlu
az1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCisKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0
YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1
bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9CisKK3Rlc3QgJGFj
X2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9T
WU1MSU5LIDEKK19BQ0VPRgorCisKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVy
ZW5jZXNfc2xhc2hlZF9zeW1saW5rIiA9IHhubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBp
bgorICAqIiBsc3RhdC4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMg
bHN0YXQuJGFjX29iamV4dCIKKyA7OworZXNhYworCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmggZGVmaW5l
cyBtYWtlZGV2IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmgg
ZGVmaW5lcyBtYWtlZGV2Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl9zeXNf
dHlwZXNfaF9tYWtlZGV2K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgoraW50
CittYWluICgpCit7CityZXR1cm4gbWFrZWRldigwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9o
ZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N5c190
eXBlc19oX21ha2VkZXY9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k
YWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRl
cl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjY7IH0KKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5
c190eXBlc19oX21ha2VkZXYgPSBubzsgdGhlbgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCAiJExJTkVOTyIgInN5cy9ta2Rldi5oIiAiYWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIg
PSB4IiJ5ZXM7IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBNQUpPUl9JTl9NS0RFViAxIiA+
PmNvbmZkZWZzLmgKKworZmkKKworCisKKyAgaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5c19ta2Rl
dl9oID0gbm87IHRoZW4KKyAgICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5P
IiAic3lzL3N5c21hY3Jvcy5oIiAiYWNfY3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgIiRhY19p
bmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jvc19o
IiA9IHgiInllczsgdGhlbiA6CisKKyRhc19lY2hvICIjZGVmaW5lIE1BSk9SX0lOX1NZU01BQ1JP
UyAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisgIGZpCitmaQorCitmb3IgYWNfaGVhZGVyIGlu
IHN0ZGxpYi5oCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8i
ICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0
IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3RkbGliX2giID0geCIieWVzOyB0aGVuIDoKKyAg
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NURExJQl9IIDEKK19BQ0VP
RgorCitmaQorCitkb25lCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgbWFsbG9jIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIG1hbGxvYy4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwrc2V0fSIgPSBzZXQ7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1u
bworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBTVERDX0hFQURFUlMgfHwgZGVmaW5l
ZCBIQVZFX1NURExJQl9ICisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorI2Vsc2UKK2NoYXIgKm1hbGxv
YyAoKTsKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAhIG1hbGxvYyAoMCk7Cisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9eWVzCitlbHNlCisgIGFjX2N2
X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29u
ZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNf
bWFsbG9jXzBfbm9ubnVsbCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9u
bnVsbCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwgPSB5ZXM7
IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAxIiA+PmNvbmZkZWZzLmgK
KworZWxzZQorICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAwIiA+PmNvbmZkZWZzLmgK
KworICAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbWFsbG9jLiRhY19vYmpleHQgIiogKSA7
OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBtYWxsb2MuJGFjX29iamV4dCIKKyA7OworZXNhYwor
CisKKyRhc19lY2hvICIjZGVmaW5lIG1hbGxvYyBycGxfbWFsbG9jIiA+PmNvbmZkZWZzLmgKKwor
ZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVkIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBi
b3RoIGJlIGluY2x1ZGVkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2hlYWRlcl90aW1l
K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNv
bmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy90aW1l
Lmg+CisjaW5jbHVkZSA8dGltZS5oPgorCitpbnQKK21haW4gKCkKK3sKK2lmICgoc3RydWN0IHRt
ICopIDApCityZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfdGltZT15ZXMK
K2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3RpbWU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl90aW1lIiA+
JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQoraWYgdGVzdCAkYWNfY3Zf
aGVhZGVyX3RpbWUgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgVElNRV9XSVRIX1NZ
U19USU1FIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKworCisgIGZvciBhY19oZWFkZXIgaW4g
JGFjX2hlYWRlcl9saXN0CitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hl
YWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBp
bGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsg
dGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJI
QVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKwor
CisKKworCisKKworCisgIGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKK2RvIDoKKyAgYXNf
YWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19m
bl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFs
IHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190
cl9jcHBgIDEKK19BQ0VPRgorCitmaQorZG9uZQorCisKKworCisKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1lIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIG1rdGltZS4uLiAiID4mNjsgfQoraWYg
dGVzdCAiJHthY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBp
bGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKy8qIFRlc3QgcHJvZ3JhbSBmcm9tIFBhdWwgRWdnZXJ0IGFuZCBUb255
IExlbmVpcy4gICovCisjaWZkZWYgVElNRV9XSVRIX1NZU19USU1FCisjIGluY2x1ZGUgPHN5cy90
aW1lLmg+CisjIGluY2x1ZGUgPHRpbWUuaD4KKyNlbHNlCisjIGlmZGVmIEhBVkVfU1lTX1RJTUVf
SAorIyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4KKyMgZWxzZQorIyAgaW5jbHVkZSA8dGltZS5oPgor
IyBlbmRpZgorI2VuZGlmCisKKyNpbmNsdWRlIDxsaW1pdHMuaD4KKyNpbmNsdWRlIDxzdGRsaWIu
aD4KKworI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3RkLmg+CisjZW5kaWYK
KworI2lmbmRlZiBIQVZFX0FMQVJNCisjIGRlZmluZSBhbGFybShYKSAvKiBlbXB0eSAqLworI2Vu
ZGlmCisKKy8qIFdvcmsgYXJvdW5kIHJlZGVmaW5pdGlvbiB0byBycGxfcHV0ZW52IGJ5IG90aGVy
IGNvbmZpZyB0ZXN0cy4gICovCisjdW5kZWYgcHV0ZW52CisKK3N0YXRpYyB0aW1lX3QgdGltZV90
X21heDsKK3N0YXRpYyB0aW1lX3QgdGltZV90X21pbjsKKworLyogVmFsdWVzIHdlJ2xsIHVzZSB0
byBzZXQgdGhlIFRaIGVudmlyb25tZW50IHZhcmlhYmxlLiAgKi8KK3N0YXRpYyBjb25zdCBjaGFy
ICp0el9zdHJpbmdzW10gPSB7CisgIChjb25zdCBjaGFyICopIDAsICJUWj1HTVQwIiwgIlRaPUpT
VC05IiwKKyAgIlRaPUVTVCszRURUKzIsTTEwLjEuMC8wMDowMDowMCxNMi4zLjAvMDA6MDA6MDAi
Cit9OworI2RlZmluZSBOX1NUUklOR1MgKHNpemVvZiAodHpfc3RyaW5ncykgLyBzaXplb2YgKHR6
X3N0cmluZ3NbMF0pKQorCisvKiBSZXR1cm4gMCBpZiBta3RpbWUgZmFpbHMgdG8gY29udmVydCBh
IGRhdGUgaW4gdGhlIHNwcmluZy1mb3J3YXJkIGdhcC4KKyAgIEJhc2VkIG9uIGEgcHJvYmxlbSBy
ZXBvcnQgZnJvbSBBbmRyZWFzIEphZWdlci4gICovCitzdGF0aWMgaW50CitzcHJpbmdfZm9yd2Fy
ZF9nYXAgKCkKK3sKKyAgLyogZ2xpYmMgKHVwIHRvIGFib3V0IDE5OTgtMTAtMDcpIGZhaWxlZCB0
aGlzIHRlc3QuICovCisgIHN0cnVjdCB0bSB0bTsKKworICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBP
U0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIKKyAgICAgaW5z
dGVhZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVn
IGV2ZW4KKyAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhlIE9sc29uIGV4dGVu
c2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUKKyAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFs
bGVkLiAgKi8KKyAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7
CisKKyAgdG0udG1feWVhciA9IDk4OworICB0bS50bV9tb24gPSAzOworICB0bS50bV9tZGF5ID0g
NTsKKyAgdG0udG1faG91ciA9IDI7CisgIHRtLnRtX21pbiA9IDA7CisgIHRtLnRtX3NlYyA9IDA7
CisgIHRtLnRtX2lzZHN0ID0gLTE7CisgIHJldHVybiBta3RpbWUgKCZ0bSkgIT0gKHRpbWVfdCkg
LTE7Cit9CisKK3N0YXRpYyBpbnQKK21rdGltZV90ZXN0MSAodGltZV90IG5vdykKK3sKKyAgc3Ry
dWN0IHRtICpsdDsKKyAgcmV0dXJuICEgKGx0ID0gbG9jYWx0aW1lICgmbm93KSkgfHwgbWt0aW1l
IChsdCkgPT0gbm93OworfQorCitzdGF0aWMgaW50Citta3RpbWVfdGVzdCAodGltZV90IG5vdykK
K3sKKyAgcmV0dXJuIChta3RpbWVfdGVzdDEgKG5vdykKKwkgICYmIG1rdGltZV90ZXN0MSAoKHRp
bWVfdCkgKHRpbWVfdF9tYXggLSBub3cpKQorCSAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAo
dGltZV90X21pbiArIG5vdykpKTsKK30KKworc3RhdGljIGludAoraXJpeF82XzRfYnVnICgpCit7
CisgIC8qIEJhc2VkIG9uIGNvZGUgZnJvbSBBcmllbCBGYWlnb24uICAqLworICBzdHJ1Y3QgdG0g
dG07CisgIHRtLnRtX3llYXIgPSA5NjsKKyAgdG0udG1fbW9uID0gMzsKKyAgdG0udG1fbWRheSA9
IDA7CisgIHRtLnRtX2hvdXIgPSAwOworICB0bS50bV9taW4gPSAwOworICB0bS50bV9zZWMgPSAw
OworICB0bS50bV9pc2RzdCA9IC0xOworICBta3RpbWUgKCZ0bSk7CisgIHJldHVybiB0bS50bV9t
b24gPT0gMiAmJiB0bS50bV9tZGF5ID09IDMxOworfQorCitzdGF0aWMgaW50CitiaWd0aW1lX3Rl
c3QgKGludCBqKQoreworICBzdHJ1Y3QgdG0gdG07CisgIHRpbWVfdCBub3c7CisgIHRtLnRtX3ll
YXIgPSB0bS50bV9tb24gPSB0bS50bV9tZGF5ID0gdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRt
LnRtX3NlYyA9IGo7CisgIG5vdyA9IG1rdGltZSAoJnRtKTsKKyAgaWYgKG5vdyAhPSAodGltZV90
KSAtMSkKKyAgICB7CisgICAgICBzdHJ1Y3QgdG0gKmx0ID0gbG9jYWx0aW1lICgmbm93KTsKKyAg
ICAgIGlmICghIChsdAorCSAgICAgJiYgbHQtPnRtX3llYXIgPT0gdG0udG1feWVhcgorCSAgICAg
JiYgbHQtPnRtX21vbiA9PSB0bS50bV9tb24KKwkgICAgICYmIGx0LT50bV9tZGF5ID09IHRtLnRt
X21kYXkKKwkgICAgICYmIGx0LT50bV9ob3VyID09IHRtLnRtX2hvdXIKKwkgICAgICYmIGx0LT50
bV9taW4gPT0gdG0udG1fbWluCisJICAgICAmJiBsdC0+dG1fc2VjID09IHRtLnRtX3NlYworCSAg
ICAgJiYgbHQtPnRtX3lkYXkgPT0gdG0udG1feWRheQorCSAgICAgJiYgbHQtPnRtX3dkYXkgPT0g
dG0udG1fd2RheQorCSAgICAgJiYgKChsdC0+dG1faXNkc3QgPCAwID8gLTEgOiAwIDwgbHQtPnRt
X2lzZHN0KQorCQkgID09ICh0bS50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCB0bS50bV9pc2RzdCkp
KSkKKwlyZXR1cm4gMDsKKyAgICB9CisgIHJldHVybiAxOworfQorCitzdGF0aWMgaW50Cit5ZWFy
XzIwNTBfdGVzdCAoKQoreworICAvKiBUaGUgY29ycmVjdCBhbnN3ZXIgZm9yIDIwNTAtMDItMDEg
MDA6MDA6MDAgaW4gUGFjaWZpYyB0aW1lLAorICAgICBpZ25vcmluZyBsZWFwIHNlY29uZHMuICAq
LworICB1bnNpZ25lZCBsb25nIGludCBhbnN3ZXIgPSAyNTI3MzE1MjAwVUw7CisKKyAgc3RydWN0
IHRtIHRtOworICB0aW1lX3QgdDsKKyAgdG0udG1feWVhciA9IDIwNTAgLSAxOTAwOworICB0bS50
bV9tb24gPSAyIC0gMTsKKyAgdG0udG1fbWRheSA9IDE7CisgIHRtLnRtX2hvdXIgPSB0bS50bV9t
aW4gPSB0bS50bV9zZWMgPSAwOworICB0bS50bV9pc2RzdCA9IC0xOworCisgIC8qIFVzZSB0aGUg
cG9ydGFibGUgUE9TSVguMSBzcGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4w
IgorICAgICBpbnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0
ZWN0IHRoZSBidWcgZXZlbgorICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUg
T2xzb24gZXh0ZW5zaW9uLCBvciBkb24ndCBoYXZlIHRoZQorICAgICBmdWxsIHpvbmVpbmZvIHRh
YmxlcyBpbnN0YWxsZWQuICAqLworICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4w
LE0xMC41LjAiKTsKKworICB0ID0gbWt0aW1lICgmdG0pOworCisgIC8qIENoZWNrIHRoYXQgdGhl
IHJlc3VsdCBpcyBlaXRoZXIgYSBmYWlsdXJlLCBvciBjbG9zZSBlbm91Z2gKKyAgICAgdG8gdGhl
IGNvcnJlY3QgYW5zd2VyIHRoYXQgd2UgY2FuIGFzc3VtZSB0aGUgZGlzY3JlcGFuY3kgaXMKKyAg
ICAgZHVlIHRvIGxlYXAgc2Vjb25kcy4gICovCisgIHJldHVybiAodCA9PSAodGltZV90KSAtMQor
CSAgfHwgKDAgPCB0ICYmIGFuc3dlciAtIDEyMCA8PSB0ICYmIHQgPD0gYW5zd2VyICsgMTIwKSk7
Cit9CisKK2ludAorbWFpbiAoKQoreworICB0aW1lX3QgdCwgZGVsdGE7CisgIGludCBpLCBqOwor
CisgIC8qIFRoaXMgdGVzdCBtYWtlcyBzb21lIGJ1Z2d5IG1rdGltZSBpbXBsZW1lbnRhdGlvbnMg
bG9vcC4KKyAgICAgR2l2ZSB1cCBhZnRlciA2MCBzZWNvbmRzOyBhIG1rdGltZSBzbG93ZXIgdGhh
biB0aGF0CisgICAgIGlzbid0IHdvcnRoIHVzaW5nIGFueXdheS4gICovCisgIGFsYXJtICg2MCk7
CisKKyAgZm9yICg7OykKKyAgICB7CisgICAgICB0ID0gKHRpbWVfdF9tYXggPDwgMSkgKyAxOwor
ICAgICAgaWYgKHQgPD0gdGltZV90X21heCkKKwlicmVhazsKKyAgICAgIHRpbWVfdF9tYXggPSB0
OworICAgIH0KKyAgdGltZV90X21pbiA9IC0gKCh0aW1lX3QpIH4gKHRpbWVfdCkgMCA9PSAodGlt
ZV90KSAtMSkgLSB0aW1lX3RfbWF4OworCisgIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyog
YSBzdWl0YWJsZSBwcmltZSBudW1iZXIgKi8KKyAgZm9yIChpID0gMDsgaSA8IE5fU1RSSU5HUzsg
aSsrKQorICAgIHsKKyAgICAgIGlmICh0el9zdHJpbmdzW2ldKQorCXB1dGVudiAoKGNoYXIqKSB0
el9zdHJpbmdzW2ldKTsKKworICAgICAgZm9yICh0ID0gMDsgdCA8PSB0aW1lX3RfbWF4IC0gZGVs
dGE7IHQgKz0gZGVsdGEpCisJaWYgKCEgbWt0aW1lX3Rlc3QgKHQpKQorCSAgcmV0dXJuIDE7Cisg
ICAgICBpZiAoISAobWt0aW1lX3Rlc3QgKCh0aW1lX3QpIDEpCisJICAgICAmJiBta3RpbWVfdGVz
dCAoKHRpbWVfdCkgKDYwICogNjApKQorCSAgICAgJiYgbWt0aW1lX3Rlc3QgKCh0aW1lX3QpICg2
MCAqIDYwICogMjQpKSkpCisJcmV0dXJuIDE7CisKKyAgICAgIGZvciAoaiA9IDE7IDsgaiA8PD0g
MSkKKwlpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQorCSAgcmV0dXJuIDE7CisJZWxzZSBpZiAoSU5U
X01BWCAvIDIgPCBqKQorCSAgYnJlYWs7CisgICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKElOVF9N
QVgpKQorCXJldHVybiAxOworICAgIH0KKyAgcmV0dXJuICEgKGlyaXhfNl80X2J1ZyAoKSAmJiBz
cHJpbmdfZm9yd2FyZF9nYXAgKCkgJiYgeWVhcl8yMDUwX3Rlc3QgKCkpOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY193b3JraW5n
X21rdGltZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubworZmkKK3Jt
IC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3Qk
YWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0
LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNQorJGFzX2VjaG8gIiRh
Y19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfd29y
a2luZ19ta3RpbWUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBta3Rp
bWUuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIG1rdGltZS4kYWNf
b2JqZXh0IgorIDs7Citlc2FjCisKK2ZpCisKKworCisKKworCitmb3IgYWNfZnVuYyBpbiBnZXRw
YWdlc2l6ZQorZG8gOgorICBhY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6
ZSIgImFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFn
ZXNpemUiID0geCIieWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2Rl
ZmluZSBIQVZFX0dFVFBBR0VTSVpFIDEKK19BQ0VPRgorCitmaQorZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQor
aWYgdGVzdCAiJHthY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkK3NldH0iID0gc2V0OyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3Nz
X2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVk
PW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisvKiBtYWxsb2Mg
bWlnaHQgaGF2ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8KKyN1bmRlZiBtYWxsb2MK
KworLyogVGhhbmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmltIEF2ZXJhIGZvciB0aGlzIHRlc3Qu
CisgICBIZXJlIGlzIGEgbWF0cml4IG9mIG1tYXAgcG9zc2liaWxpdGllczoKKwltbWFwIHByaXZh
dGUgbm90IGZpeGVkCisJbW1hcCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkg
dW5tYXBwZWQKKwltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVk
CisJbW1hcCBzaGFyZWQgbm90IGZpeGVkCisJbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJl
IGN1cnJlbnRseSB1bm1hcHBlZAorCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJl
YWR5IG1hcHBlZAorICAgRm9yIHByaXZhdGUgbWFwcGluZ3MsIHdlIHNob3VsZCB2ZXJpZnkgdGhh
dCBjaGFuZ2VzIGNhbm5vdCBiZSByZWFkKCkKKyAgIGJhY2sgZnJvbSB0aGUgZmlsZSwgbm9yIG1t
YXAncyBiYWNrIGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQKKyAgIGFkZHJlc3MuICAoVGhl
cmUgaGF2ZSBiZWVuIHN5c3RlbXMgd2hlcmUgcHJpdmF0ZSB3YXMgbm90IGNvcnJlY3RseQorICAg
aW1wbGVtZW50ZWQgbGlrZSB0aGUgaW5mYW1vdXMgaTM4NiBzdnI0LjAsIGFuZCBzeXN0ZW1zIHdo
ZXJlIHRoZQorICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90IGNvaGVyZW50IHdpdGggdGhlIGZpbGUg
c3lzdGVtIGJ1ZmZlciBjYWNoZQorICAgbGlrZSBlYXJseSB2ZXJzaW9ucyBvZiBGcmVlQlNEIGFu
ZCBwb3NzaWJseSBjb250ZW1wb3JhcnkgTmV0QlNELikKKyAgIEZvciBzaGFyZWQgbWFwcGluZ3Ms
IHdlIHNob3VsZCBjb252ZXJzZWx5IHZlcmlmeSB0aGF0IGNoYW5nZXMgZ2V0CisgICBwcm9wYWdh
dGVkIGJhY2sgdG8gYWxsIHRoZSBwbGFjZXMgdGhleSdyZSBzdXBwb3NlZCB0byBiZS4KKworICAg
R3JlcCB3YW50cyBwcml2YXRlIGZpeGVkIGFscmVhZHkgbWFwcGVkLgorICAgVGhlIG1haW4gdGhp
bmdzIGdyZXAgbmVlZHMgdG8ga25vdyBhYm91dCBtbWFwIGFyZToKKyAgICogZG9lcyBpdCBleGlz
dCBhbmQgaXMgaXQgc2FmZSB0byB3cml0ZSBpbnRvIHRoZSBtbWFwJ2QgYXJlYQorICAgKiBob3cg
dG8gdXNlIGl0IChCU0QgdmFyaWFudHMpICAqLworCisjaW5jbHVkZSA8ZmNudGwuaD4KKyNpbmNs
dWRlIDxzeXMvbW1hbi5oPgorCisjaWYgIWRlZmluZWQgU1REQ19IRUFERVJTICYmICFkZWZpbmVk
IEhBVkVfU1RETElCX0gKK2NoYXIgKm1hbGxvYyAoKTsKKyNlbmRpZgorCisvKiBUaGlzIG1lc3Mg
d2FzIGNvcGllZCBmcm9tIHRoZSBHTlUgZ2V0cGFnZXNpemUuaC4gICovCisjaWZuZGVmIEhBVkVf
R0VUUEFHRVNJWkUKKyMgaWZkZWYgX1NDX1BBR0VTSVpFCisjICBkZWZpbmUgZ2V0cGFnZXNpemUo
KSBzeXNjb25mKF9TQ19QQUdFU0laRSkKKyMgZWxzZSAvKiBubyBfU0NfUEFHRVNJWkUgKi8KKyMg
IGlmZGVmIEhBVkVfU1lTX1BBUkFNX0gKKyMgICBpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyMgICBp
ZmRlZiBFWEVDX1BBR0VTSVpFCisjICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIEVYRUNfUEFHRVNJ
WkUKKyMgICBlbHNlIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgICAgaWZkZWYgTkJQRworIyAg
ICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgTkJQRyAqIENMU0laRQorIyAgICAgaWZuZGVmIENMU0la
RQorIyAgICAgIGRlZmluZSBDTFNJWkUgMQorIyAgICAgZW5kaWYgLyogbm8gQ0xTSVpFICovCisj
ICAgIGVsc2UgLyogbm8gTkJQRyAqLworIyAgICAgaWZkZWYgTkJQQworIyAgICAgIGRlZmluZSBn
ZXRwYWdlc2l6ZSgpIE5CUEMKKyMgICAgIGVsc2UgLyogbm8gTkJQQyAqLworIyAgICAgIGlmZGVm
IFBBR0VTSVpFCisjICAgICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIFBBR0VTSVpFCisjICAgICAg
ZW5kaWYgLyogUEFHRVNJWkUgKi8KKyMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KKyMgICAgZW5k
aWYgLyogbm8gTkJQRyAqLworIyAgIGVuZGlmIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgIGVs
c2UgLyogbm8gSEFWRV9TWVNfUEFSQU1fSCAqLworIyAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIDgx
OTIJLyogcHVudCB0b3RhbGx5ICovCisjICBlbmRpZiAvKiBubyBIQVZFX1NZU19QQVJBTV9IICov
CisjIGVuZGlmIC8qIG5vIF9TQ19QQUdFU0laRSAqLworCisjZW5kaWYgLyogbm8gSEFWRV9HRVRQ
QUdFU0laRSAqLworCitpbnQKK21haW4gKCkKK3sKKyAgY2hhciAqZGF0YSwgKmRhdGEyLCAqZGF0
YTM7CisgIGNvbnN0IGNoYXIgKmNkYXRhMjsKKyAgaW50IGksIHBhZ2VzaXplOworICBpbnQgZmQs
IGZkMjsKKworICBwYWdlc2l6ZSA9IGdldHBhZ2VzaXplICgpOworCisgIC8qIEZpcnN0LCBtYWtl
IGEgZmlsZSB3aXRoIHNvbWUga25vd24gZ2FyYmFnZSBpbiBpdC4gKi8KKyAgZGF0YSA9IChjaGFy
ICopIG1hbGxvYyAocGFnZXNpemUpOworICBpZiAoIWRhdGEpCisgICAgcmV0dXJuIDE7CisgIGZv
ciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgICooZGF0YSArIGkpID0gcmFuZCAoKTsK
KyAgdW1hc2sgKDApOworICBmZCA9IGNyZWF0ICgiY29uZnRlc3QubW1hcCIsIDA2MDApOworICBp
ZiAoZmQgPCAwKQorICAgIHJldHVybiAyOworICBpZiAod3JpdGUgKGZkLCBkYXRhLCBwYWdlc2l6
ZSkgIT0gcGFnZXNpemUpCisgICAgcmV0dXJuIDM7CisgIGNsb3NlIChmZCk7CisKKyAgLyogTmV4
dCwgY2hlY2sgdGhhdCB0aGUgdGFpbCBvZiBhIHBhZ2UgaXMgemVyby1maWxsZWQuICBGaWxlIG11
c3QgaGF2ZQorICAgICBub24temVybyBsZW5ndGgsIG90aGVyd2lzZSB3ZSByaXNrIFNJR0JVUyBm
b3IgZW50aXJlIHBhZ2UuICAqLworICBmZDIgPSBvcGVuICgiY29uZnRlc3QudHh0IiwgT19SRFdS
IHwgT19DUkVBVCB8IE9fVFJVTkMsIDA2MDApOworICBpZiAoZmQyIDwgMCkKKyAgICByZXR1cm4g
NDsKKyAgY2RhdGEyID0gIiI7CisgIGlmICh3cml0ZSAoZmQyLCBjZGF0YTIsIDEpICE9IDEpCisg
ICAgcmV0dXJuIDU7CisgIGRhdGEyID0gKGNoYXIgKikgbW1hcCAoMCwgcGFnZXNpemUsIFBST1Rf
UkVBRCB8IFBST1RfV1JJVEUsIE1BUF9TSEFSRUQsIGZkMiwgMEwpOworICBpZiAoZGF0YTIgPT0g
TUFQX0ZBSUxFRCkKKyAgICByZXR1cm4gNjsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyAr
K2kpCisgICAgaWYgKCooZGF0YTIgKyBpKSkKKyAgICAgIHJldHVybiA3OworICBjbG9zZSAoZmQy
KTsKKyAgaWYgKG11bm1hcCAoZGF0YTIsIHBhZ2VzaXplKSkKKyAgICByZXR1cm4gODsKKworICAv
KiBOZXh0LCB0cnkgdG8gbW1hcCB0aGUgZmlsZSBhdCBhIGZpeGVkIGFkZHJlc3Mgd2hpY2ggYWxy
ZWFkeSBoYXMKKyAgICAgc29tZXRoaW5nIGVsc2UgYWxsb2NhdGVkIGF0IGl0LiAgSWYgd2UgY2Fu
LCBhbHNvIG1ha2Ugc3VyZSB0aGF0CisgICAgIHdlIHNlZSB0aGUgc2FtZSBnYXJiYWdlLiAgKi8K
KyAgZmQgPSBvcGVuICgiY29uZnRlc3QubW1hcCIsIE9fUkRXUik7CisgIGlmIChmZCA8IDApCisg
ICAgcmV0dXJuIDk7CisgIGlmIChkYXRhMiAhPSBtbWFwIChkYXRhMiwgcGFnZXNpemUsIFBST1Rf
UkVBRCB8IFBST1RfV1JJVEUsCisJCSAgICAgTUFQX1BSSVZBVEUgfCBNQVBfRklYRUQsIGZkLCAw
TCkpCisgICAgcmV0dXJuIDEwOworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAg
ICBpZiAoKihkYXRhICsgaSkgIT0gKihkYXRhMiArIGkpKQorICAgICAgcmV0dXJuIDExOworCisg
IC8qIEZpbmFsbHksIG1ha2Ugc3VyZSB0aGF0IGNoYW5nZXMgdG8gdGhlIG1hcHBlZCBhcmVhIGRv
IG5vdAorICAgICBwZXJjb2xhdGUgYmFjayB0byB0aGUgZmlsZSBhcyBzZWVuIGJ5IHJlYWQoKS4g
IChUaGlzIGlzIGEgYnVnIG9uCisgICAgIHNvbWUgdmFyaWFudHMgb2YgaTM4NiBzdnI0LjAuKSAg
Ki8KKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAgKihkYXRhMiArIGkpID0g
KihkYXRhMiArIGkpICsgMTsKKyAgZGF0YTMgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsK
KyAgaWYgKCFkYXRhMykKKyAgICByZXR1cm4gMTI7CisgIGlmIChyZWFkIChmZCwgZGF0YTMsIHBh
Z2VzaXplKSAhPSBwYWdlc2l6ZSkKKyAgICByZXR1cm4gMTM7CisgIGZvciAoaSA9IDA7IGkgPCBw
YWdlc2l6ZTsgKytpKQorICAgIGlmICgqKGRhdGEgKyBpKSAhPSAqKGRhdGEzICsgaSkpCisgICAg
ICByZXR1cm4gMTQ7CisgIGNsb3NlIChmZCk7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVk
X21hcHBlZD15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD1ubworZmkK
K3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRl
c3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0
ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2
X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUg
SEFWRV9NTUFQIDEiID4+Y29uZmRlZnMuaAorCitmaQorcm0gLWYgY29uZnRlc3QubW1hcCBjb25m
dGVzdC50eHQKKworZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAorZG8gOgorICBhY19mbl9jX2No
ZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3Rk
bGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0
ZGxpYl9oIiA9IHgiInllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgSEFWRV9TVERMSUJfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21w
YXRpYmxlIHJlYWxsb2MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNv
bXBhdGlibGUgcmVhbGxvYy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX3JlYWxs
b2NfMF9ub25udWxsK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgor
ICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
ZiBkZWZpbmVkIFNURENfSEVBREVSUyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKKyMgaW5jbHVk
ZSA8c3RkbGliLmg+CisjZWxzZQorY2hhciAqcmVhbGxvYyAoKTsKKyNlbmRpZgorCitpbnQKK21h
aW4gKCkKK3sKK3JldHVybiAhIHJlYWxsb2MgKDAsIDApOworICA7CisgIHJldHVybiAwOworfQor
X0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y19yZWFsbG9jXzBfbm9ubnVsbD15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9u
bnVsbD1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBi
Yi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KK2lm
IHRlc3QgJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwgPSB5ZXM7IHRoZW4gOgorCiskYXNf
ZWNobyAiI2RlZmluZSBIQVZFX1JFQUxMT0MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgJGFz
X2VjaG8gIiNkZWZpbmUgSEFWRV9SRUFMTE9DIDAiID4+Y29uZmRlZnMuaAorCisgICBjYXNlICIg
JExJQk9CSlMgIiBpbgorICAqIiByZWFsbG9jLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJP
QkpTPSIkTElCT0JKUyByZWFsbG9jLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworCiskYXNfZWNo
byAiI2RlZmluZSByZWFsbG9jIHJwbF9yZWFsbG9jIiA+PmNvbmZkZWZzLmgKKworZmkKKworCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3Jr
aW5nIHN0cm5sZW4iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3Rybmxl
bi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZytzZXR9
IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlm
IHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19zdHJu
bGVuX3dvcmtpbmc9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQK
K2ludAorbWFpbiAoKQoreworCisjZGVmaW5lIFMgImZvb2JhciIKKyNkZWZpbmUgU19MRU4gKHNp
emVvZiBTIC0gMSkKKworICAvKiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYnVnZ3k6
IHRoYXQgb2YgQUlYIDQuMyB3b3VsZAorICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMuICAq
LworCisgIGludCBpOworICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCisgICAgewor
ICAgICAgaW50IGV4cGVjdGVkID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsKKyAgICAgIGlmIChz
dHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKKwlyZXR1cm4gMTsKKyAgICB9CisgIHJldHVybiAw
OworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKK2Vsc2UKKyAg
YWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3Jl
LmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9m
dW5jX3N0cm5sZW5fd29ya2luZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93
b3JraW5nIiA+JjY7IH0KK3Rlc3QgJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nID0gbm8gJiYg
Y2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgc3Rybmxlbi4kYWNfb2JqZXh0ICIqICkgOzsKKyAg
KikgTElCT0JKUz0iJExJQk9CSlMgc3Rybmxlbi4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKKwor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29y
a2luZyBzdHJ0b2QiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9k
Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2Z1bmNfc3RydG9kK3NldH0iID0gc2V0OyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNy
b3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3N0cnRvZD1ubworZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKKyRhY19pbmNsdWRlc19kZWZhdWx0CisjaWZuZGVmIHN0cnRvZAor
ZG91YmxlIHN0cnRvZCAoKTsKKyNlbmRpZgoraW50CittYWluKCkKK3sKKyAgeworICAgIC8qIFNv
bWUgdmVyc2lvbnMgb2YgTGludXggc3RydG9kIG1pcy1wYXJzZSBzdHJpbmdzIHdpdGggbGVhZGlu
ZyAnKycuICAqLworICAgIGNoYXIgKnN0cmluZyA9ICIgKzY5IjsKKyAgICBjaGFyICp0ZXJtOwor
ICAgIGRvdWJsZSB2YWx1ZTsKKyAgICB2YWx1ZSA9IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7Cisg
ICAgaWYgKHZhbHVlICE9IDY5IHx8IHRlcm0gIT0gKHN0cmluZyArIDQpKQorICAgICAgcmV0dXJu
IDE7CisgIH0KKworICB7CisgICAgLyogVW5kZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5z
IHRoZSB3cm9uZyB2YWx1ZSBmb3IgdGhlCisgICAgICAgdGVybWluYXRpbmcgY2hhcmFjdGVyIHVu
ZGVyIHNvbWUgY29uZGl0aW9ucy4gICovCisgICAgY2hhciAqc3RyaW5nID0gIk5hTiI7CisgICAg
Y2hhciAqdGVybTsKKyAgICBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOworICAgIGlmICh0ZXJtICE9
IHN0cmluZyAmJiAqKHRlcm0gLSAxKSA9PSAwKQorICAgICAgcmV0dXJuIDE7CisgIH0KKyAgcmV0
dXJuIDA7Cit9CisKK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2Z1bmNfc3RydG9kPXllcworZWxzZQorICBhY19jdl9mdW5jX3N0cnRvZD1ubwor
ZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29u
ZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfc3RydG9kIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfZnVuY19zdHJ0b2QiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19zdHJ0b2QgPSBubzsg
dGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBzdHJ0b2QuJGFjX29iamV4dCAiKiAp
IDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIHN0cnRvZC4kYWNfb2JqZXh0IgorIDs7Citlc2Fj
CisKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgInBvdyIgImFjX2N2X2Z1bmNfcG93Igor
aWYgdGVzdCAieCRhY19jdl9mdW5jX3BvdyIgPSB4IiJ5ZXM7IHRoZW4gOgorCitmaQorCitpZiB0
ZXN0ICRhY19jdl9mdW5jX3BvdyA9IG5vOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHBvdyBpbiAtbG0iID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yIHBvdyBpbiAtbG0uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3Zf
bGliX21fcG93K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxtICAkTElC
UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg
dG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0
aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50
IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4
dGVybiAiQyIKKyNlbmRpZgorY2hhciBwb3cgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBw
b3cgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsg
IiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX21fcG93PXllcworZWxzZQorICBhY19jdl9s
aWJfbV9wb3c9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNf
Y2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX21fcG93IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
bGliX21fcG93IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX21fcG93IiA9IHgiInllczsg
dGhlbiA6CisgIFBPV19MSUI9LWxtCitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRl
ZmluaXRpb24gb2YgcG93IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IGNhbm5vdCBm
aW5kIGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9mIHBvdyIgPiYyO30KK2ZpCisKK2Zp
CisKK2ZpCisKK2ZvciBhY19mdW5jIGluICBcCisgICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0
IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKKyAgICAgICAg
ICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0
aW1lb2ZkYXkgXAorICAgICAgICAgICAgICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9y
IG1lbWNociBtZW1tb3ZlIG1lbXNldCBta2RpciBcCisgICAgICAgICAgICAgICAgbWtmaWZvIG11
bm1hcCBwYXRoY29uZiByZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAorICAg
ICAgICAgICAgICAgIHNvY2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJl
cnJvciBzdHJuZHVwIFwKKyAgICAgICAgICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0
cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNldCBcCisgICAgICAgICAgICAgICAgdW5h
bWUgXAorCitkbyA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMi
IHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIk
YXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRo
ZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFW
RV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKK2RvbmUKKworCitjYXQg
PmNvbmZjYWNoZSA8PFxfQUNFT0YKKyMgVGhpcyBmaWxlIGlzIGEgc2hlbGwgc2NyaXB0IHRoYXQg
Y2FjaGVzIHRoZSByZXN1bHRzIG9mIGNvbmZpZ3VyZQorIyB0ZXN0cyBydW4gb24gdGhpcyBzeXN0
ZW0gc28gdGhleSBjYW4gYmUgc2hhcmVkIGJldHdlZW4gY29uZmlndXJlCisjIHNjcmlwdHMgYW5k
IGNvbmZpZ3VyZSBydW5zLCBzZWUgY29uZmlndXJlJ3Mgb3B0aW9uIC0tY29uZmlnLWNhY2hlLgor
IyBJdCBpcyBub3QgdXNlZnVsIG9uIG90aGVyIHN5c3RlbXMuICBJZiBpdCBjb250YWlucyByZXN1
bHRzIHlvdSBkb24ndAorIyB3YW50IHRvIGtlZXAsIHlvdSBtYXkgcmVtb3ZlIG9yIGVkaXQgaXQu
CisjCisjIGNvbmZpZy5zdGF0dXMgb25seSBwYXlzIGF0dGVudGlvbiB0byB0aGUgY2FjaGUgZmls
ZSBpZiB5b3UgZ2l2ZSBpdAorIyB0aGUgLS1yZWNoZWNrIG9wdGlvbiB0byByZXJ1biBjb25maWd1
cmUuCisjCisjIGBhY19jdl9lbnZfZm9vJyB2YXJpYWJsZXMgKHNldCBvciB1bnNldCkgd2lsbCBi
ZSBvdmVycmlkZGVuIHdoZW4KKyMgbG9hZGluZyB0aGlzIGZpbGUsIG90aGVyICp1bnNldCogYGFj
X2N2X2Zvbycgd2lsbCBiZSBhc3NpZ25lZCB0aGUKKyMgZm9sbG93aW5nIHZhbHVlcy4KKworX0FD
RU9GCisKKyMgVGhlIGZvbGxvd2luZyB3YXkgb2Ygd3JpdGluZyB0aGUgY2FjaGUgbWlzaGFuZGxl
cyBuZXdsaW5lcyBpbiB2YWx1ZXMsCisjIGJ1dCB3ZSBrbm93IG9mIG5vIHdvcmthcm91bmQgdGhh
dCBpcyBzaW1wbGUsIHBvcnRhYmxlLCBhbmQgZWZmaWNpZW50LgorIyBTbywgd2Uga2lsbCB2YXJp
YWJsZXMgY29udGFpbmluZyBuZXdsaW5lcy4KKyMgVWx0cml4IHNoIHNldCB3cml0ZXMgdG8gc3Rk
ZXJyIGFuZCBjYW4ndCBiZSByZWRpcmVjdGVkIGRpcmVjdGx5LAorIyBhbmQgc2V0cyB0aGUgaGln
aCBiaXQgaW4gdGhlIGNhY2hlIGZpbGUgdW5sZXNzIHdlIGFzc2lnbiB0byB0aGUgdmFycy4KKygK
KyAgZm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAtbiAncy9eXChbYS16QS1aX11bYS16
QS1aMC05X10qXCk9LiovXDEvcCdgOyBkbworICAgIGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAg
IGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSopCisgICAgICBjYXNlICRhY192YXIg
aW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGluZSIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNv
bnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVzYWMKKyAgICAgIGNhc2UgJGFjX3Zh
ciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAjKAorICAgICAgQkFTSF9BUkdWIHwg
QkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAgICAgICopIHsgZXZhbCAkYWNfdmFy
PTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7CisgICAgZXNhYworICBkb25lCisK
KyAgKHNldCkgMj4mMSB8CisgICAgY2FzZSAkYXNfbmxgKGFjX3NwYWNlPScgJzsgc2V0KSAyPiYx
YCBpbiAjKAorICAgICoke2FzX25sfWFjX3NwYWNlPVwgKikKKyAgICAgICMgYHNldCcgZG9lcyBu
b3QgcXVvdGUgY29ycmVjdGx5LCBzbyBhZGQgcXVvdGVzOiBkb3VibGUtcXVvdGUKKyAgICAgICMg
c3Vic3RpdHV0aW9uIHR1cm5zIFxcXFwgaW50byBcXCwgYW5kIHNlZCB0dXJucyBcXCBpbnRvIFwu
CisgICAgICBzZWQgLW4gXAorCSJzLycvJ1xcXFwnJy9nOworCSAgcy9eXFwoW18kYXNfY3JfYWxu
dW1dKl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwpL1xcMT0nXFwyJy9wIgorICAgICAg
OzsgIygKKyAgICAqKQorICAgICAgIyBgc2V0JyBxdW90ZXMgY29ycmVjdGx5IGFzIHJlcXVpcmVk
IGJ5IFBPU0lYLCBzbyBkbyBub3QgYWRkIHF1b3Rlcy4KKyAgICAgIHNlZCAtbiAiL15bXyRhc19j
cl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisgICAgICA7OworICAgIGVzYWMgfAor
ICAgIHNvcnQKKykgfAorICBzZWQgJworICAgICAvXmFjX2N2X2Vudl8vYiBlbmQKKyAgICAgdCBj
bGVhcgorICAgICA6Y2xlYXIKKyAgICAgcy9eXChbXj1dKlwpPVwoLipbe31dLipcKSQvdGVzdCAi
JHtcMStzZXR9IiA9IHNldCB8fCAmLworICAgICB0IGVuZAorICAgICBzL15cKFtePV0qXCk9XCgu
KlwpJC9cMT0ke1wxPVwyfS8KKyAgICAgOmVuZCcgPj5jb25mY2FjaGUKK2lmIGRpZmYgIiRjYWNo
ZV9maWxlIiBjb25mY2FjaGUgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDo7IGVsc2UKKyAgaWYgdGVz
dCAtdyAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICAgdGVzdCAieCRjYWNoZV9maWxlIiAhPSAieC9k
ZXYvbnVsbCIgJiYKKyAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogdXBkYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogdXBk
YXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CisgICAgY2F0IGNvbmZjYWNoZSA+JGNhY2hl
X2ZpbGUKKyAgZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogbm90IHVwZGF0aW5nIHVud3JpdGFibGUgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogbm90IHVwZGF0aW5nIHVud3JpdGFibGUgY2FjaGUgJGNhY2hlX2ZpbGUiID4m
Njt9CisgIGZpCitmaQorcm0gLWYgY29uZmNhY2hlCisKK3Rlc3QgIngkcHJlZml4IiA9IHhOT05F
ICYmIHByZWZpeD0kYWNfZGVmYXVsdF9wcmVmaXgKKyMgTGV0IG1ha2UgZXhwYW5kIGV4ZWNfcHJl
Zml4LgordGVzdCAieCRleGVjX3ByZWZpeCIgPSB4Tk9ORSAmJiBleGVjX3ByZWZpeD0nJHtwcmVm
aXh9JworCitERUZTPS1ESEFWRV9DT05GSUdfSAorCithY19saWJvYmpzPQorYWNfbHRsaWJvYmpz
PQorVT0KK2ZvciBhY19pIGluIDogJExJQk9CSlM7IGRvIHRlc3QgIngkYWNfaSIgPSB4OiAmJiBj
b250aW51ZQorICAjIDEuIFJlbW92ZSB0aGUgZXh0ZW5zaW9uLCBhbmQgJFUgaWYgYWxyZWFkeSBp
bnN0YWxsZWQuCisgIGFjX3NjcmlwdD0ncy9cJFVcLi8uLztzL1wubyQvLztzL1wub2JqJC8vJwor
ICBhY19pPWAkYXNfZWNobyAiJGFjX2kiIHwgc2VkICIkYWNfc2NyaXB0ImAKKyAgIyAyLiBQcmVw
ZW5kIExJQk9CSkRJUi4gIFdoZW4gdXNlZCB3aXRoIGF1dG9tYWtlPj0xLjEwIExJQk9CSkRJUgor
ICAjICAgIHdpbGwgYmUgc2V0IHRvIHRoZSBkaXJlY3Rvcnkgd2hlcmUgTElCT0JKUyBvYmplY3Rz
IGFyZSBidWlsdC4KKyAgYXNfZm5fYXBwZW5kIGFjX2xpYm9ianMgIiBcJHtMSUJPQkpESVJ9JGFj
X2lcJFUuJGFjX29iamV4dCIKKyAgYXNfZm5fYXBwZW5kIGFjX2x0bGlib2JqcyAiIFwke0xJQk9C
SkRJUn0kYWNfaSInJFUubG8nCitkb25lCitMSUJPQkpTPSRhY19saWJvYmpzCisKK0xUTElCT0JK
Uz0kYWNfbHRsaWJvYmpzCisKKworCis6ICR7Q09ORklHX1NUQVRVUz0uL2NvbmZpZy5zdGF0dXN9
CithY193cml0ZV9mYWlsPTAKK2FjX2NsZWFuX2ZpbGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCith
Y19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzICRDT05GSUdfU1RBVFVTIgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIgPiY2O30KK2Fz
X3dyaXRlX2ZhaWw9MAorY2F0ID4kQ09ORklHX1NUQVRVUyA8PF9BU0VPRiB8fCBhc193cml0ZV9m
YWlsPTEKKyMhICRTSEVMTAorIyBHZW5lcmF0ZWQgYnkgJGFzX21lLgorIyBSdW4gdGhpcyBmaWxl
IHRvIHJlY3JlYXRlIHRoZSBjdXJyZW50IGNvbmZpZ3VyYXRpb24uCisjIENvbXBpbGVyIG91dHB1
dCBwcm9kdWNlZCBieSBjb25maWd1cmUsIHVzZWZ1bCBmb3IgZGVidWdnaW5nCisjIGNvbmZpZ3Vy
ZSwgaXMgaW4gY29uZmlnLmxvZyBpZiBpdCBleGlzdHMuCisKK2RlYnVnPWZhbHNlCithY19jc19y
ZWNoZWNrPWZhbHNlCithY19jc19zaWxlbnQ9ZmFsc2UKKworU0hFTEw9XCR7Q09ORklHX1NIRUxM
LSRTSEVMTH0KK2V4cG9ydCBTSEVMTAorX0FTRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxf
QVNFT0YgfHwgYXNfd3JpdGVfZmFpbD0xCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMg
TTRzaCBJbml0aWFsaXphdGlvbi4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMg
QmUgbW9yZSBCb3VybmUgY29tcGF0aWJsZQorRFVBTENBU0U9MTsgZXhwb3J0IERVQUxDQVNFICMg
Zm9yIE1LUyBzaAoraWYgdGVzdCAtbiAiJHtaU0hfVkVSU0lPTitzZXR9IiAmJiAoZW11bGF0ZSBz
aCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAg
IyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiAkezErIiRAIn0s
IHdoaWNoCisgICMgaXMgY29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1
cmUuCisgIGFsaWFzIC1nICckezErIiRAIn0nPSciJEAiJworICBzZXRvcHQgTk9fR0xPQl9TVUJT
VAorZWxzZQorICBjYXNlIGAoc2V0IC1vKSAyPi9kZXYvbnVsbGAgaW4gIygKKyAgKnBvc2l4Kikg
OgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorCisK
K2FzX25sPScKKycKK2V4cG9ydCBhc19ubAorIyBQcmludGluZyBhIGxvbmcgc3RyaW5nIGNyYXNo
ZXMgU29sYXJpcyA3IC91c3IvYmluL3ByaW50Zi4KK2FzX2VjaG89J1xcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFwnCithc19lY2hvPSRhc19lY2hvJGFzX2VjaG8k
YXNfZWNobyRhc19lY2hvJGFzX2VjaG8KK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hv
JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCisjIFByZWZlciBhIGtzaCBzaGVsbCBidWlsdGluIG92
ZXIgYW4gZXh0ZXJuYWwgcHJpbnRmIHByb2dyYW0gb24gU29sYXJpcywKKyMgYnV0IHdpdGhvdXQg
d2FzdGluZyBmb3JrcyBmb3IgYmFzaCBvciB6c2guCitpZiB0ZXN0IC16ICIkQkFTSF9WRVJTSU9O
JFpTSF9WRVJTSU9OIiBcCisgICAgJiYgKHRlc3QgIlhgcHJpbnQgLXIgLS0gJGFzX2VjaG9gIiA9
ICJYJGFzX2VjaG8iKSAyPi9kZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmludCAtciAtLScK
KyAgYXNfZWNob19uPSdwcmludCAtcm4gLS0nCitlbGlmICh0ZXN0ICJYYHByaW50ZiAlcyAkYXNf
ZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50
ZiAlc1xuJworICBhc19lY2hvX249J3ByaW50ZiAlcycKK2Vsc2UKKyAgaWYgdGVzdCAiWGAoL3Vz
ci91Y2IvZWNobyAtbiAtbiAkYXNfZWNobykgMj4vZGV2L251bGxgIiA9ICJYLW4gJGFzX2VjaG8i
OyB0aGVuCisgICAgYXNfZWNob19ib2R5PSdldmFsIC91c3IvdWNiL2VjaG8gLW4gIiQxJGFzX25s
IicKKyAgICBhc19lY2hvX249Jy91c3IvdWNiL2VjaG8gLW4nCisgIGVsc2UKKyAgICBhc19lY2hv
X2JvZHk9J2V2YWwgZXhwciAiWCQxIiA6ICJYXFwoLipcXCkiJworICAgIGFzX2VjaG9fbl9ib2R5
PSdldmFsCisgICAgICBhcmc9JDE7CisgICAgICBjYXNlICRhcmcgaW4gIygKKyAgICAgICoiJGFz
X25sIiopCisJZXhwciAiWCRhcmciIDogIlhcXCguKlxcKSRhc19ubCI7CisJYXJnPWBleHByICJY
JGFyZyIgOiAiLiokYXNfbmxcXCguKlxcKSJgOzsKKyAgICAgIGVzYWM7CisgICAgICBleHByICJY
JGFyZyIgOiAiWFxcKC4qXFwpIiB8IHRyIC1kICIkYXNfbmwiCisgICAgJworICAgIGV4cG9ydCBh
c19lY2hvX25fYm9keQorICAgIGFzX2VjaG9fbj0nc2ggLWMgJGFzX2VjaG9fbl9ib2R5IGFzX2Vj
aG8nCisgIGZpCisgIGV4cG9ydCBhc19lY2hvX2JvZHkKKyAgYXNfZWNobz0nc2ggLWMgJGFzX2Vj
aG9fYm9keSBhc19lY2hvJworZmkKKworIyBUaGUgdXNlciBpcyBhbHdheXMgcmlnaHQuCitpZiB0
ZXN0ICIke1BBVEhfU0VQQVJBVE9SK3NldH0iICE9IHNldDsgdGhlbgorICBQQVRIX1NFUEFSQVRP
Uj06CisgIChQQVRIPScvYmluOy9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVs
bCAyPiYxICYmIHsKKyAgICAoUEFUSD0nL2JpbjovYmluJzsgRlBBVEg9JFBBVEg7IHNoIC1jIDop
ID4vZGV2L251bGwgMj4mMSB8fAorICAgICAgUEFUSF9TRVBBUkFUT1I9JzsnCisgIH0KK2ZpCisK
KworIyBJRlMKKyMgV2UgbmVlZCBzcGFjZSwgdGFiIGFuZCBuZXcgbGluZSwgaW4gcHJlY2lzZWx5
IHRoYXQgb3JkZXIuICBRdW90aW5nIGlzCisjIHRoZXJlIHRvIHByZXZlbnQgZWRpdG9ycyBmcm9t
IGNvbXBsYWluaW5nIGFib3V0IHNwYWNlLXRhYi4KKyMgKElmIF9BU19QQVRIX1dBTEsgd2VyZSBj
YWxsZWQgd2l0aCBJRlMgdW5zZXQsIGl0IHdvdWxkIGRpc2FibGUgd29yZAorIyBzcGxpdHRpbmcg
Ynkgc2V0dGluZyBJRlMgdG8gZW1wdHkgdmFsdWUuKQorSUZTPSIgIiIJJGFzX25sIgorCisjIEZp
bmQgd2hvIHdlIGFyZS4gIExvb2sgaW4gdGhlIHBhdGggaWYgd2UgY29udGFpbiBubyBkaXJlY3Rv
cnkgc2VwYXJhdG9yLgorY2FzZSAkMCBpbiAjKCgKKyAgKltcXC9dKiApIGFzX215c2VsZj0kMCA7
OworICAqKSBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgdGVzdCAtciAiJGFzX2Rpci8kMCIgJiYgYXNfbXlzZWxmPSRhc19kaXIv
JDAgJiYgYnJlYWsKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgICAgIDs7Citlc2FjCisj
IFdlIGRpZCBub3QgZmluZCBvdXJzZWx2ZXMsIG1vc3QgcHJvYmFibHkgd2Ugd2VyZSBydW4gYXMg
YHNoIENPTU1BTkQnCisjIGluIHdoaWNoIGNhc2Ugd2UgYXJlIG5vdCB0byBiZSBmb3VuZCBpbiB0
aGUgcGF0aC4KK2lmIHRlc3QgIngkYXNfbXlzZWxmIiA9IHg7IHRoZW4KKyAgYXNfbXlzZWxmPSQw
CitmaQoraWYgdGVzdCAhIC1mICIkYXNfbXlzZWxmIjsgdGhlbgorICAkYXNfZWNobyAiJGFzX215
c2VsZjogZXJyb3I6IGNhbm5vdCBmaW5kIG15c2VsZjsgcmVydW4gd2l0aCBhbiBhYnNvbHV0ZSBm
aWxlIG5hbWUiID4mMgorICBleGl0IDEKK2ZpCisKKyMgVW5zZXQgdmFyaWFibGVzIHRoYXQgd2Ug
ZG8gbm90IG5lZWQgYW5kIHdoaWNoIGNhdXNlIGJ1Z3MgKGUuZy4gaW4KKyMgcHJlLTMuMCBVV0lO
IGtzaCkuICBCdXQgZG8gbm90IGNhdXNlIGJ1Z3MgaW4gYmFzaCAyLjAxOyB0aGUgInx8IGV4aXQg
MSIKKyMgc3VwcHJlc3NlcyBhbnkgIlNlZ21lbnRhdGlvbiBmYXVsdCIgbWVzc2FnZSB0aGVyZS4g
ICcoKCcgY291bGQKKyMgdHJpZ2dlciBhIGJ1ZyBpbiBwZGtzaCA1LjIuMTQuCitmb3IgYXNfdmFy
IGluIEJBU0hfRU5WIEVOViBNQUlMIE1BSUxQQVRICitkbyBldmFsIHRlc3QgeFwkeyRhc192YXIr
c2V0fSA9IHhzZXQgXAorICAmJiAoICh1bnNldCAkYXNfdmFyKSB8fCBleGl0IDEpID4vZGV2L251
bGwgMj4mMSAmJiB1bnNldCAkYXNfdmFyIHx8IDoKK2RvbmUKK1BTMT0nJCAnCitQUzI9Jz4gJwor
UFM0PScrICcKKworIyBOTFMgbnVpc2FuY2VzLgorTENfQUxMPUMKK2V4cG9ydCBMQ19BTEwKK0xB
TkdVQUdFPUMKK2V4cG9ydCBMQU5HVUFHRQorCisjIENEUEFUSC4KKyh1bnNldCBDRFBBVEgpID4v
ZGV2L251bGwgMj4mMSAmJiB1bnNldCBDRFBBVEgKKworCisjIGFzX2ZuX2Vycm9yIFNUQVRVUyBF
UlJPUiBbTElORU5PIExPR19GRF0KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorIyBPdXRwdXQgImBiYXNlbmFtZSAkMGA6IGVycm9yOiBFUlJPUiIgdG8gc3RkZXJy
LiBJZiBMSU5FTk8gYW5kIExPR19GRCBhcmUKKyMgcHJvdmlkZWQsIGFsc28gb3V0cHV0IHRoZSBl
cnJvciB0byBMT0dfRkQsIHJlZmVyZW5jaW5nIExJTkVOTy4gVGhlbiBleGl0IHRoZQorIyBzY3Jp
cHQgd2l0aCBTVEFUVVMsIHVzaW5nIDEgaWYgdGhhdCB3YXMgMC4KK2FzX2ZuX2Vycm9yICgpCit7
CisgIGFzX3N0YXR1cz0kMTsgdGVzdCAkYXNfc3RhdHVzIC1lcSAwICYmIGFzX3N0YXR1cz0xCisg
IGlmIHRlc3QgIiQ0IjsgdGhlbgorICAgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDMifSBhc19s
aW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogJDIiID4mJDQKKyAgZmkKKyAg
JGFzX2VjaG8gIiRhc19tZTogZXJyb3I6ICQyIiA+JjIKKyAgYXNfZm5fZXhpdCAkYXNfc3RhdHVz
Cit9ICMgYXNfZm5fZXJyb3IKKworCisjIGFzX2ZuX3NldF9zdGF0dXMgU1RBVFVTCisjIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCisjIFNldCAkPyB0byBTVEFUVVMsIHdpdGhvdXQgZm9ya2luZy4K
K2FzX2ZuX3NldF9zdGF0dXMgKCkKK3sKKyAgcmV0dXJuICQxCit9ICMgYXNfZm5fc2V0X3N0YXR1
cworCisjIGFzX2ZuX2V4aXQgU1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tCisjIEV4aXQgdGhl
IHNoZWxsIHdpdGggU1RBVFVTLCBldmVuIGluIGEgInRyYXAgMCIgb3IgInNldCAtZSIgY29udGV4
dC4KK2FzX2ZuX2V4aXQgKCkKK3sKKyAgc2V0ICtlCisgIGFzX2ZuX3NldF9zdGF0dXMgJDEKKyAg
ZXhpdCAkMQorfSAjIGFzX2ZuX2V4aXQKKworIyBhc19mbl91bnNldCBWQVIKKyMgLS0tLS0tLS0t
LS0tLS0tCisjIFBvcnRhYmx5IHVuc2V0IFZBUi4KK2FzX2ZuX3Vuc2V0ICgpCit7CisgIHsgZXZh
bCAkMT07IHVuc2V0ICQxO30KK30KK2FzX3Vuc2V0PWFzX2ZuX3Vuc2V0CisjIGFzX2ZuX2FwcGVu
ZCBWQVIgVkFMVUUKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBBcHBlbmQgdGhlIHRleHQg
aW4gVkFMVUUgdG8gdGhlIGVuZCBvZiB0aGUgZGVmaW5pdGlvbiBjb250YWluZWQgaW4gVkFSLiBU
YWtlCisjIGFkdmFudGFnZSBvZiBhbnkgc2hlbGwgb3B0aW1pemF0aW9ucyB0aGF0IGFsbG93IGFt
b3J0aXplZCBsaW5lYXIgZ3Jvd3RoIG92ZXIKKyMgcmVwZWF0ZWQgYXBwZW5kcywgaW5zdGVhZCBv
ZiB0aGUgdHlwaWNhbCBxdWFkcmF0aWMgZ3Jvd3RoIHByZXNlbnQgaW4gbmFpdmUKKyMgaW1wbGVt
ZW50YXRpb25zLgoraWYgKGV2YWwgImFzX3Zhcj0xOyBhc192YXIrPTI7IHRlc3QgeFwkYXNfdmFy
ID0geDEyIikgMj4vZGV2L251bGw7IHRoZW4gOgorICBldmFsICdhc19mbl9hcHBlbmQgKCkKKyAg
eworICAgIGV2YWwgJDErPVwkMgorICB9JworZWxzZQorICBhc19mbl9hcHBlbmQgKCkKKyAgewor
ICAgIGV2YWwgJDE9XCQkMVwkMgorICB9CitmaSAjIGFzX2ZuX2FwcGVuZAorCisjIGFzX2ZuX2Fy
aXRoIEFSRy4uLgorIyAtLS0tLS0tLS0tLS0tLS0tLS0KKyMgUGVyZm9ybSBhcml0aG1ldGljIGV2
YWx1YXRpb24gb24gdGhlIEFSR3MsIGFuZCBzdG9yZSB0aGUgcmVzdWx0IGluIHRoZQorIyBnbG9i
YWwgJGFzX3ZhbC4gVGFrZSBhZHZhbnRhZ2Ugb2Ygc2hlbGxzIHRoYXQgY2FuIGF2b2lkIGZvcmtz
LiBUaGUgYXJndW1lbnRzCisjIG11c3QgYmUgcG9ydGFibGUgYWNyb3NzICQoKCkpIGFuZCBleHBy
LgoraWYgKGV2YWwgInRlc3QgXCQoKCAxICsgMSApKSA9IDIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6
CisgIGV2YWwgJ2FzX2ZuX2FyaXRoICgpCisgIHsKKyAgICBhc192YWw9JCgoICQqICkpCisgIH0n
CitlbHNlCisgIGFzX2ZuX2FyaXRoICgpCisgIHsKKyAgICBhc192YWw9YGV4cHIgIiRAIiB8fCB0
ZXN0ICQ/IC1lcSAxYAorICB9CitmaSAjIGFzX2ZuX2FyaXRoCisKKworaWYgZXhwciBhIDogJ1wo
YVwpJyA+L2Rldi9udWxsIDI+JjEgJiYKKyAgIHRlc3QgIlhgZXhwciAwMDAwMSA6ICcuKlwoLi4u
XCknYCIgPSBYMDAxOyB0aGVuCisgIGFzX2V4cHI9ZXhwcgorZWxzZQorICBhc19leHByPWZhbHNl
CitmaQorCitpZiAoYmFzZW5hbWUgLS0gLykgPi9kZXYvbnVsbCAyPiYxICYmIHRlc3QgIlhgYmFz
ZW5hbWUgLS0gLyAyPiYxYCIgPSAiWC8iOyB0aGVuCisgIGFzX2Jhc2VuYW1lPWJhc2VuYW1lCitl
bHNlCisgIGFzX2Jhc2VuYW1lPWZhbHNlCitmaQorCitpZiAoYXNfZGlyPWBkaXJuYW1lIC0tIC9g
ICYmIHRlc3QgIlgkYXNfZGlyIiA9IFgvKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfZGly
bmFtZT1kaXJuYW1lCitlbHNlCisgIGFzX2Rpcm5hbWU9ZmFsc2UKK2ZpCisKK2FzX21lPWAkYXNf
YmFzZW5hbWUgLS0gIiQwIiB8fAorJGFzX2V4cHIgWC8iJDAiIDogJy4qL1woW14vXVteL10qXCkv
KiQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoL1wpJyBc
fCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYLyIkMCIgfAorICAgIHNlZCAnL14uKlwvXChb
Xi9dW14vXSpcKVwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwv
XC9cKSQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXCkuKi97CisJ
ICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKworIyBBdm9pZCBkZXBl
bmRpbmcgdXBvbiBDaGFyYWN0ZXIgUmFuZ2VzLgorYXNfY3JfbGV0dGVycz0nYWJjZGVmZ2hpamts
bW5vcHFyc3R1dnd4eXonCithc19jcl9MRVRURVJTPSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZ
WicKK2FzX2NyX0xldHRlcnM9JGFzX2NyX2xldHRlcnMkYXNfY3JfTEVUVEVSUworYXNfY3JfZGln
aXRzPScwMTIzNDU2Nzg5JworYXNfY3JfYWxudW09JGFzX2NyX0xldHRlcnMkYXNfY3JfZGlnaXRz
CisKK0VDSE9fQz0gRUNIT19OPSBFQ0hPX1Q9CitjYXNlIGBlY2hvIC1uIHhgIGluICMoKCgoKAor
LW4qKQorICBjYXNlIGBlY2hvICd4eVxjJ2AgaW4KKyAgKmMqKSBFQ0hPX1Q9JwknOzsJIyBFQ0hP
X1QgaXMgc2luZ2xlIHRhYiBjaGFyYWN0ZXIuCisgIHh5KSAgRUNIT19DPSdcYyc7OworICAqKSAg
IGVjaG8gYGVjaG8ga3NoODggYnVnIG9uIEFJWCA2LjFgID4gL2Rldi9udWxsCisgICAgICAgRUNI
T19UPScJJzs7CisgIGVzYWM7OworKikKKyAgRUNIT19OPSctbic7OworZXNhYworCitybSAtZiBj
b25mJCQgY29uZiQkLmV4ZSBjb25mJCQuZmlsZQoraWYgdGVzdCAtZCBjb25mJCQuZGlyOyB0aGVu
CisgIHJtIC1mIGNvbmYkJC5kaXIvY29uZiQkLmZpbGUKK2Vsc2UKKyAgcm0gLWYgY29uZiQkLmRp
cgorICBta2RpciBjb25mJCQuZGlyIDI+L2Rldi9udWxsCitmaQoraWYgKGVjaG8gPmNvbmYkJC5m
aWxlKSAyPi9kZXYvbnVsbDsgdGhlbgorICBpZiBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQgMj4v
ZGV2L251bGw7IHRoZW4KKyAgICBhc19sbl9zPSdsbiAtcycKKyAgICAjIC4uLiBidXQgdGhlcmUg
YXJlIHR3byBnb3RjaGFzOgorICAgICMgMSkgT24gTVNZUywgYm90aCBgbG4gLXMgZmlsZSBkaXIn
IGFuZCBgbG4gZmlsZSBkaXInIGZhaWwuCisgICAgIyAyKSBESkdQUCA8IDIuMDQgaGFzIG5vIHN5
bWxpbmtzOyBgbG4gLXMnIGNyZWF0ZXMgYSB3cmFwcGVyIGV4ZWN1dGFibGUuCisgICAgIyBJbiBi
b3RoIGNhc2VzLCB3ZSBoYXZlIHRvIGRlZmF1bHQgdG8gYGNwIC1wJy4KKyAgICBsbiAtcyBjb25m
JCQuZmlsZSBjb25mJCQuZGlyIDI+L2Rldi9udWxsICYmIHRlc3QgISAtZiBjb25mJCQuZXhlIHx8
CisgICAgICBhc19sbl9zPSdjcCAtcCcKKyAgZWxpZiBsbiBjb25mJCQuZmlsZSBjb25mJCQgMj4v
ZGV2L251bGw7IHRoZW4KKyAgICBhc19sbl9zPWxuCisgIGVsc2UKKyAgICBhc19sbl9zPSdjcCAt
cCcKKyAgZmkKK2Vsc2UKKyAgYXNfbG5fcz0nY3AgLXAnCitmaQorcm0gLWYgY29uZiQkIGNvbmYk
JC5leGUgY29uZiQkLmRpci9jb25mJCQuZmlsZSBjb25mJCQuZmlsZQorcm1kaXIgY29uZiQkLmRp
ciAyPi9kZXYvbnVsbAorCisKKyMgYXNfZm5fbWtkaXJfcAorIyAtLS0tLS0tLS0tLS0tCisjIENy
ZWF0ZSAiJGFzX2RpciIgYXMgYSBkaXJlY3RvcnksIGluY2x1ZGluZyBwYXJlbnRzIGlmIG5lY2Vz
c2FyeS4KK2FzX2ZuX21rZGlyX3AgKCkKK3sKKworICBjYXNlICRhc19kaXIgaW4gIygKKyAgLSop
IGFzX2Rpcj0uLyRhc19kaXI7OworICBlc2FjCisgIHRlc3QgLWQgIiRhc19kaXIiIHx8IGV2YWwg
JGFzX21rZGlyX3AgfHwgeworICAgIGFzX2RpcnM9CisgICAgd2hpbGUgOjsgZG8KKyAgICAgIGNh
c2UgJGFzX2RpciBpbiAjKAorICAgICAgKlwnKikgYXNfcWRpcj1gJGFzX2VjaG8gIiRhc19kaXIi
IHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgIycoCisgICAgICAqKSBhc19xZGlyPSRhc19k
aXI7OworICAgICAgZXNhYworICAgICAgYXNfZGlycz0iJyRhc19xZGlyJyAkYXNfZGlycyIKKyAg
ICAgIGFzX2Rpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19kaXIiIHx8CiskYXNfZXhwciBYIiRhc19k
aXIiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX2RpciIgOiAn
WFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRh
c19kaXIiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYXNfZGly
IiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkgICAgcy8v
XDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8vXDEvCisJ
ICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9
CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4v
OyBxJ2AKKyAgICAgIHRlc3QgLWQgIiRhc19kaXIiICYmIGJyZWFrCisgICAgZG9uZQorICAgIHRl
c3QgLXogIiRhc19kaXJzIiB8fCBldmFsICJta2RpciAkYXNfZGlycyIKKyAgfSB8fCB0ZXN0IC1k
ICIkYXNfZGlyIiB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBkaXJlY3RvcnkgJGFz
X2RpciIKKworCit9ICMgYXNfZm5fbWtkaXJfcAoraWYgbWtkaXIgLXAgLiAyPi9kZXYvbnVsbDsg
dGhlbgorICBhc19ta2Rpcl9wPSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRlc3QgLWQg
Li8tcCAmJiBybWRpciAuLy1wCisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRlc3QgLXgg
LyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxzZQorICBp
ZiBscyAtZEwgLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlvbj1MCisg
IGVsc2UKKyAgICBhc19sc19MX29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAgICBldmFs
IHNoIC1jICdcJycKKyAgICAgIGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQgIiQxLy4i
OworICAgICAgZWxzZQorCWNhc2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwllc2FjOwor
CWNhc2UgYGxzIC1sZCckYXNfbHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGluICMoKAor
CT8/P1tzeF0qKTo7OyopZmFsc2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2ZpCithc19l
eGVjdXRhYmxlX3A9JGFzX3Rlc3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmlu
ZyBvbnRvIGEgdmFsaWQgQ1BQIG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSokYXNfY3Jf
bGV0dGVycyVQJGFzX2NyX0xFVFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisjIFNl
ZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUgbmFtZS4K
K2FzX3RyX3NoPSJldmFsIHNlZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisK
KworZXhlYyA2PiYxCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIwor
IyMgTWFpbiBib2R5IG9mICRDT05GSUdfU1RBVFVTIHNjcmlwdC4gIyMKKyMjIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCitfQVNFT0YKK3Rlc3QgJGFzX3dyaXRlX2ZhaWwg
PSAwICYmIGNobW9kICt4ICRDT05GSUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorCitjYXQg
Pj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIFNhdmUgdGhl
IGxvZyBtZXNzYWdlLCB0byBrZWVwICQwIGFuZCBzbyBvbiBtZWFuaW5nZnVsLCBhbmQgdG8KKyMg
cmVwb3J0IGFjdHVhbCBpbnB1dCB2YWx1ZXMgb2YgQ09ORklHX0ZJTEVTIGV0Yy4gaW5zdGVhZCBv
ZiB0aGVpcgorIyB2YWx1ZXMgYWZ0ZXIgb3B0aW9ucyBoYW5kbGluZy4KK2FjX2xvZz0iCitUaGlz
IGZpbGUgd2FzIGV4dGVuZGVkIGJ5ICRhc19tZSwgd2hpY2ggd2FzCitnZW5lcmF0ZWQgYnkgR05V
IEF1dG9jb25mIDIuNjcuICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICBDT05GSUdf
RklMRVMgICAgPSAkQ09ORklHX0ZJTEVTCisgIENPTkZJR19IRUFERVJTICA9ICRDT05GSUdfSEVB
REVSUworICBDT05GSUdfTElOS1MgICAgPSAkQ09ORklHX0xJTktTCisgIENPTkZJR19DT01NQU5E
UyA9ICRDT05GSUdfQ09NTUFORFMKKyAgJCAkMCAkQAorCitvbiBgKGhvc3RuYW1lIHx8IHVuYW1l
IC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKKyIKKworX0FDRU9GCisKK2Nhc2UgJGFjX2NvbmZp
Z19maWxlcyBpbiAqIgorIiopIHNldCB4ICRhY19jb25maWdfZmlsZXM7IHNoaWZ0OyBhY19jb25m
aWdfZmlsZXM9JCo7OworZXNhYworCitjYXNlICRhY19jb25maWdfaGVhZGVycyBpbiAqIgorIiop
IHNldCB4ICRhY19jb25maWdfaGVhZGVyczsgc2hpZnQ7IGFjX2NvbmZpZ19oZWFkZXJzPSQqOzsK
K2VzYWMKKworCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWls
PTEKKyMgRmlsZXMgdGhhdCBjb25maWcuc3RhdHVzIHdhcyBtYWRlIGZvci4KK2NvbmZpZ19maWxl
cz0iJGFjX2NvbmZpZ19maWxlcyIKK2NvbmZpZ19oZWFkZXJzPSIkYWNfY29uZmlnX2hlYWRlcnMi
CisKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVf
ZmFpbD0xCithY19jc191c2FnZT0iXAorXGAkYXNfbWUnIGluc3RhbnRpYXRlcyBmaWxlcyBhbmQg
b3RoZXIgY29uZmlndXJhdGlvbiBhY3Rpb25zCitmcm9tIHRlbXBsYXRlcyBhY2NvcmRpbmcgdG8g
dGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4gIFVubGVzcyB0aGUgZmlsZXMKK2FuZCBhY3Rpb25z
IGFyZSBzcGVjaWZpZWQgYXMgVEFHcywgYWxsIGFyZSBpbnN0YW50aWF0ZWQgYnkgZGVmYXVsdC4K
KworVXNhZ2U6ICQwIFtPUFRJT05dLi4uIFtUQUddLi4uCisKKyAgLWgsIC0taGVscCAgICAgICBw
cmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtViwgLS12ZXJzaW9uICAgIHByaW50IHZlcnNp
b24gbnVtYmVyIGFuZCBjb25maWd1cmF0aW9uIHNldHRpbmdzLCB0aGVuIGV4aXQKKyAgICAgIC0t
Y29uZmlnICAgICBwcmludCBjb25maWd1cmF0aW9uLCB0aGVuIGV4aXQKKyAgLXEsIC0tcXVpZXQs
IC0tc2lsZW50CisgICAgICAgICAgICAgICAgICAgZG8gbm90IHByaW50IHByb2dyZXNzIG1lc3Nh
Z2VzCisgIC1kLCAtLWRlYnVnICAgICAgZG9uJ3QgcmVtb3ZlIHRlbXBvcmFyeSBmaWxlcworICAg
ICAgLS1yZWNoZWNrICAgIHVwZGF0ZSAkYXNfbWUgYnkgcmVjb25maWd1cmluZyBpbiB0aGUgc2Ft
ZSBjb25kaXRpb25zCisgICAgICAtLWZpbGU9RklMRVs6VEVNUExBVEVdCisgICAgICAgICAgICAg
ICAgICAgaW5zdGFudGlhdGUgdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSBGSUxFCisgICAgICAtLWhl
YWRlcj1GSUxFWzpURU1QTEFURV0KKyAgICAgICAgICAgICAgICAgICBpbnN0YW50aWF0ZSB0aGUg
Y29uZmlndXJhdGlvbiBoZWFkZXIgRklMRQorCitDb25maWd1cmF0aW9uIGZpbGVzOgorJGNvbmZp
Z19maWxlcworCitDb25maWd1cmF0aW9uIGhlYWRlcnM6CiskY29uZmlnX2hlYWRlcnMKKworUmVw
b3J0IGJ1Z3MgdG8gdGhlIHBhY2thZ2UgcHJvdmlkZXIuIgorCitfQUNFT0YKK2NhdCA+PiRDT05G
SUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorYWNfY3NfY29uZmlnPSJgJGFz
X2VjaG8gIiRhY19jb25maWd1cmVfYXJncyIgfCBzZWQgJ3MvXiAvLzsgcy9bXFwiIlxgXCRdL1xc
XFwmL2cnYCIKK2FjX2NzX3ZlcnNpb249IlxcCitjb25maWcuc3RhdHVzCitjb25maWd1cmVkIGJ5
ICQwLCBnZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIuNjcsCisgIHdpdGggb3B0aW9ucyBcXCJc
JGFjX2NzX2NvbmZpZ1xcIgorCitDb3B5cmlnaHQgKEMpIDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uLCBJbmMuCitUaGlzIGNvbmZpZy5zdGF0dXMgc2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7
IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KK2dpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9u
IHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4iCisKK2FjX3B3ZD0nJGFjX3B3ZCcK
K3NyY2Rpcj0nJHNyY2RpcicKK0lOU1RBTEw9JyRJTlNUQUxMJwordGVzdCAtbiAiXCRBV0siIHx8
IEFXSz1hd2sKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNf
d3JpdGVfZmFpbD0xCisjIFRoZSBkZWZhdWx0IGxpc3RzIGFwcGx5IGlmIHRoZSB1c2VyIGRvZXMg
bm90IHNwZWNpZnkgYW55IGZpbGUuCithY19uZWVkX2RlZmF1bHRzPToKK3doaWxlIHRlc3QgJCMg
IT0gMAorZG8KKyAgY2FzZSAkMSBpbgorICAtLSo9PyopCisgICAgYWNfb3B0aW9uPWBleHByICJY
JDEiIDogJ1hcKFtePV0qXCk9J2AKKyAgICBhY19vcHRhcmc9YGV4cHIgIlgkMSIgOiAnWFtePV0q
PVwoLipcKSdgCisgICAgYWNfc2hpZnQ9OgorICAgIDs7CisgIC0tKj0pCisgICAgYWNfb3B0aW9u
PWBleHByICJYJDEiIDogJ1hcKFtePV0qXCk9J2AKKyAgICBhY19vcHRhcmc9CisgICAgYWNfc2hp
ZnQ9OgorICAgIDs7CisgICopCisgICAgYWNfb3B0aW9uPSQxCisgICAgYWNfb3B0YXJnPSQyCisg
ICAgYWNfc2hpZnQ9c2hpZnQKKyAgICA7OworICBlc2FjCisKKyAgY2FzZSAkYWNfb3B0aW9uIGlu
CisgICMgSGFuZGxpbmcgb2YgdGhlIG9wdGlvbnMuCisgIC1yZWNoZWNrIHwgLS1yZWNoZWNrIHwg
LS1yZWNoZWMgfCAtLXJlY2hlIHwgLS1yZWNoIHwgLS1yZWMgfCAtLXJlIHwgLS1yKQorICAgIGFj
X2NzX3JlY2hlY2s9OiA7OworICAtLXZlcnNpb24gfCAtLXZlcnNpbyB8IC0tdmVyc2kgfCAtLXZl
cnMgfCAtLXZlciB8IC0tdmUgfCAtLXYgfCAtViApCisgICAgJGFzX2VjaG8gIiRhY19jc192ZXJz
aW9uIjsgZXhpdCA7OworICAtLWNvbmZpZyB8IC0tY29uZmkgfCAtLWNvbmYgfCAtLWNvbiB8IC0t
Y28gfCAtLWMgKQorICAgICRhc19lY2hvICIkYWNfY3NfY29uZmlnIjsgZXhpdCA7OworICAtLWRl
YnVnIHwgLS1kZWJ1IHwgLS1kZWIgfCAtLWRlIHwgLS1kIHwgLWQgKQorICAgIGRlYnVnPTogOzsK
KyAgLS1maWxlIHwgLS1maWwgfCAtLWZpIHwgLS1mICkKKyAgICAkYWNfc2hpZnQKKyAgICBjYXNl
ICRhY19vcHRhcmcgaW4KKyAgICAqXCcqKSBhY19vcHRhcmc9YCRhc19lY2hvICIkYWNfb3B0YXJn
IiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAgICcnKSBhc19mbl9lcnJvciAkPyAi
bWlzc2luZyBmaWxlIGFyZ3VtZW50IiA7OworICAgIGVzYWMKKyAgICBhc19mbl9hcHBlbmQgQ09O
RklHX0ZJTEVTICIgJyRhY19vcHRhcmcnIgorICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2U7Owor
ICAtLWhlYWRlciB8IC0taGVhZGUgfCAtLWhlYWQgfCAtLWhlYSApCisgICAgJGFjX3NoaWZ0Cisg
ICAgY2FzZSAkYWNfb3B0YXJnIGluCisgICAgKlwnKikgYWNfb3B0YXJnPWAkYXNfZWNobyAiJGFj
X29wdGFyZyIgfCBzZWQgInMvJy8nXFxcXFxcXFwnJy9nImAgOzsKKyAgICBlc2FjCisgICAgYXNf
Zm5fYXBwZW5kIENPTkZJR19IRUFERVJTICIgJyRhY19vcHRhcmcnIgorICAgIGFjX25lZWRfZGVm
YXVsdHM9ZmFsc2U7OworICAtLWhlIHwgLS1oKQorICAgICMgQ29uZmxpY3QgYmV0d2VlbiAtLWhl
bHAgYW5kIC0taGVhZGVyCisgICAgYXNfZm5fZXJyb3IgJD8gImFtYmlndW91cyBvcHRpb246IFxg
JDEnCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uLiI7OworICAtLWhlbHAg
fCAtLWhlbCB8IC1oICkKKyAgICAkYXNfZWNobyAiJGFjX2NzX3VzYWdlIjsgZXhpdCA7OworICAt
cSB8IC1xdWlldCB8IC0tcXVpZXQgfCAtLXF1aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8
IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCB8IC0tc2kgfCAt
LXMpCisgICAgYWNfY3Nfc2lsZW50PTogOzsKKworICAjIFRoaXMgaXMgYW4gZXJyb3IuCisgIC0q
KSBhc19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbjogXGAkMScKK1RyeSBcYCQwIC0t
aGVscCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIiA7OworCisgICopIGFzX2ZuX2FwcGVuZCBhY19j
b25maWdfdGFyZ2V0cyAiICQxIgorICAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlIDs7CisKKyAg
ZXNhYworICBzaGlmdAorZG9uZQorCithY19jb25maWd1cmVfZXh0cmFfYXJncz0KKworaWYgJGFj
X2NzX3NpbGVudDsgdGhlbgorICBleGVjIDY+L2Rldi9udWxsCisgIGFjX2NvbmZpZ3VyZV9leHRy
YV9hcmdzPSIkYWNfY29uZmlndXJlX2V4dHJhX2FyZ3MgLS1zaWxlbnQiCitmaQorCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQoraWYgXCRh
Y19jc19yZWNoZWNrOyB0aGVuCisgIHNldCBYICckU0hFTEwnICckMCcgJGFjX2NvbmZpZ3VyZV9h
cmdzIFwkYWNfY29uZmlndXJlX2V4dHJhX2FyZ3MgLS1uby1jcmVhdGUgLS1uby1yZWN1cnNpb24K
KyAgc2hpZnQKKyAgXCRhc19lY2hvICJydW5uaW5nIENPTkZJR19TSEVMTD0kU0hFTEwgXCQqIiA+
JjYKKyAgQ09ORklHX1NIRUxMPSckU0hFTEwnCisgIGV4cG9ydCBDT05GSUdfU0hFTEwKKyAgZXhl
YyAiXCRAIgorZmkKKworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwg
YWNfd3JpdGVfZmFpbD0xCitleGVjIDU+PmNvbmZpZy5sb2cKK3sKKyAgZWNobworICBzZWQgJ2g7
cy8uLy0vZztzL14uLi4vIyMgLztzLy4uLiQvICMjLztwO3g7cDt4JyA8PF9BU0JPWAorIyMgUnVu
bmluZyAkYXNfbWUuICMjCitfQVNCT1gKKyAgJGFzX2VjaG8gIiRhY19sb2ciCit9ID4mNQorCitf
QUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQor
X0FDRU9GCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWls
PTEKKworIyBIYW5kbGluZyBvZiBhcmd1bWVudHMuCitmb3IgYWNfY29uZmlnX3RhcmdldCBpbiAk
YWNfY29uZmlnX3RhcmdldHMKK2RvCisgIGNhc2UgJGFjX2NvbmZpZ190YXJnZXQgaW4KKyAgICAi
Li4vY29uZmlnL1Rvb2xzLm1rIikgQ09ORklHX0ZJTEVTPSIkQ09ORklHX0ZJTEVTIC4uL2NvbmZp
Zy9Ub29scy5tayIgOzsKKyAgICAiY29uZmlnLmgiKSBDT05GSUdfSEVBREVSUz0iJENPTkZJR19I
RUFERVJTIGNvbmZpZy5oIiA7OworCisgICopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGFyZ3Vt
ZW50OiBcYCRhY19jb25maWdfdGFyZ2V0JyIgIiRMSU5FTk8iIDUgOzsKKyAgZXNhYworZG9uZQor
CisKKyMgSWYgdGhlIHVzZXIgZGlkIG5vdCB1c2UgdGhlIGFyZ3VtZW50cyB0byBzcGVjaWZ5IHRo
ZSBpdGVtcyB0byBpbnN0YW50aWF0ZSwKKyMgdGhlbiB0aGUgZW52dmFyIGludGVyZmFjZSBpcyB1
c2VkLiAgU2V0IG9ubHkgdGhvc2UgdGhhdCBhcmUgbm90LgorIyBXZSB1c2UgdGhlIGxvbmcgZm9y
bSBmb3IgdGhlIGRlZmF1bHQgYXNzaWdubWVudCBiZWNhdXNlIG9mIGFuIGV4dHJlbWVseQorIyBi
aXphcnJlIGJ1ZyBvbiBTdW5PUyA0LjEuMy4KK2lmICRhY19uZWVkX2RlZmF1bHRzOyB0aGVuCisg
IHRlc3QgIiR7Q09ORklHX0ZJTEVTK3NldH0iID0gc2V0IHx8IENPTkZJR19GSUxFUz0kY29uZmln
X2ZpbGVzCisgIHRlc3QgIiR7Q09ORklHX0hFQURFUlMrc2V0fSIgPSBzZXQgfHwgQ09ORklHX0hF
QURFUlM9JGNvbmZpZ19oZWFkZXJzCitmaQorCisjIEhhdmUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5
IGZvciBjb252ZW5pZW5jZS4gIE1ha2UgaXQgaW4gdGhlIGJ1aWxkIHRyZWUKKyMgc2ltcGx5IGJl
Y2F1c2UgdGhlcmUgaXMgbm8gcmVhc29uIGFnYWluc3QgaGF2aW5nIGl0IGhlcmUsIGFuZCBpbiBh
ZGRpdGlvbiwKKyMgY3JlYXRpbmcgYW5kIG1vdmluZyBmaWxlcyBmcm9tIC90bXAgY2FuIHNvbWV0
aW1lcyBjYXVzZSBwcm9ibGVtcy4KKyMgSG9vayBmb3IgaXRzIHJlbW92YWwgdW5sZXNzIGRlYnVn
Z2luZy4KKyMgTm90ZSB0aGF0IHRoZXJlIGlzIGEgc21hbGwgd2luZG93IGluIHdoaWNoIHRoZSBk
aXJlY3Rvcnkgd2lsbCBub3QgYmUgY2xlYW5lZDoKKyMgYWZ0ZXIgaXRzIGNyZWF0aW9uIGJ1dCBi
ZWZvcmUgaXRzIG5hbWUgaGFzIGJlZW4gYXNzaWduZWQgdG8gYCR0bXAnLgorJGRlYnVnIHx8Cit7
CisgIHRtcD0KKyAgdHJhcCAnZXhpdF9zdGF0dXM9JD8KKyAgeyB0ZXN0IC16ICIkdG1wIiB8fCB0
ZXN0ICEgLWQgIiR0bXAiIHx8IHJtIC1mciAiJHRtcCI7IH0gJiYgZXhpdCAkZXhpdF9zdGF0dXMK
KycgMAorICB0cmFwICdhc19mbl9leGl0IDEnIDEgMiAxMyAxNQorfQorIyBDcmVhdGUgYSAoc2Vj
dXJlKSB0bXAgZGlyZWN0b3J5IGZvciB0bXAgZmlsZXMuCisKK3sKKyAgdG1wPWAodW1hc2sgMDc3
ICYmIG1rdGVtcCAtZCAiLi9jb25mWFhYWFhYIikgMj4vZGV2L251bGxgICYmCisgIHRlc3QgLW4g
IiR0bXAiICYmIHRlc3QgLWQgIiR0bXAiCit9ICB8fAoreworICB0bXA9Li9jb25mJCQtJFJBTkRP
TQorICAodW1hc2sgMDc3ICYmIG1rZGlyICIkdG1wIikKK30gfHwgYXNfZm5fZXJyb3IgJD8gImNh
bm5vdCBjcmVhdGUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGluIC4iICIkTElORU5PIiA1CisKKyMg
U2V0IHVwIHRoZSBzY3JpcHRzIGZvciBDT05GSUdfRklMRVMgc2VjdGlvbi4KKyMgTm8gbmVlZCB0
byBnZW5lcmF0ZSB0aGVtIGlmIHRoZXJlIGFyZSBubyBDT05GSUdfRklMRVMuCisjIFRoaXMgaGFw
cGVucyBmb3IgaW5zdGFuY2Ugd2l0aCBgLi9jb25maWcuc3RhdHVzIGNvbmZpZy5oJy4KK2lmIHRl
c3QgLW4gIiRDT05GSUdfRklMRVMiOyB0aGVuCisKKworYWNfY3I9YGVjaG8gWCB8IHRyIFggJ1ww
MTUnYAorIyBPbiBjeWd3aW4sIGJhc2ggY2FuIGVhdCBcciBpbnNpZGUgYGAgaWYgdGhlIHVzZXIg
cmVxdWVzdGVkIGlnbmNyLgorIyBCdXQgd2Uga25vdyBvZiBubyBvdGhlciBzaGVsbCB3aGVyZSBh
Y19jciB3b3VsZCBiZSBlbXB0eSBhdCB0aGlzCisjIHBvaW50LCBzbyB3ZSBjYW4gdXNlIGEgYmFz
aGlzbSBhcyBhIGZhbGxiYWNrLgoraWYgdGVzdCAieCRhY19jciIgPSB4OyB0aGVuCisgIGV2YWwg
YWNfY3I9XCRcJ1xcclwnCitmaQorYWNfY3NfYXdrX2NyPWAkQVdLICdCRUdJTiB7IHByaW50ICJh
XHJiIiB9JyA8L2Rldi9udWxsIDI+L2Rldi9udWxsYAoraWYgdGVzdCAiJGFjX2NzX2F3a19jciIg
PSAiYSR7YWNfY3J9YiI7IHRoZW4KKyAgYWNfY3NfYXdrX2NyPSdcXHInCitlbHNlCisgIGFjX2Nz
X2F3a19jcj0kYWNfY3IKK2ZpCisKK2VjaG8gJ0JFR0lOIHsnID4iJHRtcC9zdWJzMS5hd2siICYm
CitfQUNFT0YKKworCit7CisgIGVjaG8gImNhdCA+Y29uZiQkc3Vicy5hd2sgPDxfQUNFT0YiICYm
CisgIGVjaG8gIiRhY19zdWJzdF92YXJzIiB8IHNlZCAncy8uKi8mISQmJGFjX2RlbGltLycgJiYK
KyAgZWNobyAiX0FDRU9GIgorfSA+Y29uZiQkc3Vicy5zaCB8fAorICBhc19mbl9lcnJvciAkPyAi
Y291bGQgbm90IG1ha2UgJENPTkZJR19TVEFUVVMiICIkTElORU5PIiA1CithY19kZWxpbV9udW09
YGVjaG8gIiRhY19zdWJzdF92YXJzIiB8IGdyZXAgLWMgJ14nYAorYWNfZGVsaW09JyUhXyEjICcK
K2ZvciBhY19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSA6OyBkbwor
ICAuIC4vY29uZiQkc3Vicy5zaCB8fAorICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFr
ZSAkQ09ORklHX1NUQVRVUyIgIiRMSU5FTk8iIDUKKworICBhY19kZWxpbV9uPWBzZWQgLW4gInMv
LiokYWNfZGVsaW1cJC9YL3AiIGNvbmYkJHN1YnMuYXdrIHwgZ3JlcCAtYyBYYAorICBpZiB0ZXN0
ICRhY19kZWxpbV9uID0gJGFjX2RlbGltX251bTsgdGhlbgorICAgIGJyZWFrCisgIGVsaWYgJGFj
X2xhc3RfdHJ5OyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05G
SUdfU1RBVFVTIiAiJExJTkVOTyIgNQorICBlbHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEk
YWNfZGVsaW0gXyRhY19kZWxpbSEhICIKKyAgZmkKK2RvbmUKK3JtIC1mIGNvbmYkJHN1YnMuc2gK
KworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitjYXQg
Pj4iXCR0bXAvc3ViczEuYXdrIiA8PFxcX0FDQVdLICYmCitfQUNFT0YKK3NlZCAtbiAnCitoCitz
L14vU1siLzsgcy8hLiovIl09LworcAorZworcy9eW14hXSohLy8KKzpyZXBsCit0IHJlcGwKK3Mv
JyIkYWNfZGVsaW0iJyQvLwordCBkZWxpbQorOm5sCitoCitzL1woLlx7MTQ4XH1cKS4uKi9cMS8K
K3QgbW9yZTEKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kL1xcbiJcXC8KK3AKK24KK2IgcmVw
bAorOm1vcmUxCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0
OFx9Ly8KK3QgbmwKKzpkZWxpbQoraAorcy9cKC5cezE0OFx9XCkuLiovXDEvCit0IG1vcmUyCitz
L1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iLworcAorYgorOm1vcmUyCitzL1siXFxdL1xcJi9n
OyBzL14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0OFx9Ly8KK3QgZGVsaW0KKycgPGNvbmYk
JHN1YnMuYXdrIHwgc2VkICcKKy9eW14iIl0veworICBOCisgIHMvXG4vLworfQorJyA+PiRDT05G
SUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorcm0gLWYgY29uZiQkc3Vicy5hd2sKK2NhdCA+
PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorX0FDQVdLCitjYXQg
Pj4iXCR0bXAvc3ViczEuYXdrIiA8PF9BQ0FXSyAmJgorICBmb3IgKGtleSBpbiBTKSBTX2lzX3Nl
dFtrZXldID0gMQorICBGUyA9ICIHIgorCit9Cit7CisgIGxpbmUgPSAkIDAKKyAgbmZpZWxkcyA9
IHNwbGl0KGxpbmUsIGZpZWxkLCAiQCIpCisgIHN1YnN0ZWQgPSAwCisgIGxlbiA9IGxlbmd0aChm
aWVsZFsxXSkKKyAgZm9yIChpID0gMjsgaSA8IG5maWVsZHM7IGkrKykgeworICAgIGtleSA9IGZp
ZWxkW2ldCisgICAga2V5bGVuID0gbGVuZ3RoKGtleSkKKyAgICBpZiAoU19pc19zZXRba2V5XSkg
eworICAgICAgdmFsdWUgPSBTW2tleV0KKyAgICAgIGxpbmUgPSBzdWJzdHIobGluZSwgMSwgbGVu
KSAiIiB2YWx1ZSAiIiBzdWJzdHIobGluZSwgbGVuICsga2V5bGVuICsgMykKKyAgICAgIGxlbiAr
PSBsZW5ndGgodmFsdWUpICsgbGVuZ3RoKGZpZWxkWysraV0pCisgICAgICBzdWJzdGVkID0gMQor
ICAgIH0gZWxzZQorICAgICAgbGVuICs9IDEgKyBrZXlsZW4KKyAgfQorCisgIHByaW50IGxpbmUK
K30KKworX0FDQVdLCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBh
Y193cml0ZV9mYWlsPTEKK2lmIHNlZCAicy8kYWNfY3IvLyIgPCAvZGV2L251bGwgPiAvZGV2L251
bGwgMj4mMTsgdGhlbgorICBzZWQgInMvJGFjX2NyXCQvLzsgcy8kYWNfY3IvJGFjX2NzX2F3a19j
ci9nIgorZWxzZQorICBjYXQKK2ZpIDwgIiR0bXAvc3ViczEuYXdrIiA+ICIkdG1wL3N1YnMuYXdr
IiBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGZpbGVzIG1h
Y2hpbmVyeSIgIiRMSU5FTk8iIDUKK19BQ0VPRgorCisjIFZQQVRIIG1heSBjYXVzZSB0cm91Ymxl
IHdpdGggc29tZSBtYWtlcywgc28gd2UgcmVtb3ZlIHNvbGUgJChzcmNkaXIpLAorIyAke3NyY2Rp
cn0gYW5kIEBzcmNkaXJAIGVudHJpZXMgZnJvbSBWUEFUSCBpZiBzcmNkaXIgaXMgIi4iLCBzdHJp
cCBsZWFkaW5nIGFuZAorIyB0cmFpbGluZyBjb2xvbnMgYW5kIHRoZW4gcmVtb3ZlIHRoZSB3aG9s
ZSBsaW5lIGlmIFZQQVRIIGJlY29tZXMgZW1wdHkKKyMgKGFjdHVhbGx5IHdlIGxlYXZlIGFuIGVt
cHR5IGxpbmUgdG8gcHJlc2VydmUgbGluZSBudW1iZXJzKS4KK2lmIHRlc3QgIngkc3JjZGlyIiA9
IHguOyB0aGVuCisgIGFjX3Zwc3ViPScvXlsJIF0qVlBBVEhbCSBdKj1bCSBdKi97CitoCitzLy8v
CitzL14vOi8KK3MvWwkgXSokLzovCitzLzpcJChzcmNkaXIpOi86L2cKK3MvOlwke3NyY2Rpcn06
LzovZworcy86QHNyY2RpckA6LzovZworcy9eOiovLworcy86KiQvLworeAorcy9cKD1bCSBdKlwp
LiovXDEvCitHCitzL1xuLy8KK3MvXltePV0qPVsJIF0qJC8vCit9JworZmkKKworY2F0ID4+JENP
TkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorZmkgIyB0ZXN0IC1uICIk
Q09ORklHX0ZJTEVTIgorCisjIFNldCB1cCB0aGUgc2NyaXB0cyBmb3IgQ09ORklHX0hFQURFUlMg
c2VjdGlvbi4KKyMgTm8gbmVlZCB0byBnZW5lcmF0ZSB0aGVtIGlmIHRoZXJlIGFyZSBubyBDT05G
SUdfSEVBREVSUy4KKyMgVGhpcyBoYXBwZW5zIGZvciBpbnN0YW5jZSB3aXRoIGAuL2NvbmZpZy5z
dGF0dXMgTWFrZWZpbGUnLgoraWYgdGVzdCAtbiAiJENPTkZJR19IRUFERVJTIjsgdGhlbgorY2F0
ID4iJHRtcC9kZWZpbmVzLmF3ayIgPDxcX0FDQVdLIHx8CitCRUdJTiB7CitfQUNFT0YKKworIyBU
cmFuc2Zvcm0gY29uZmRlZnMuaCBpbnRvIGFuIGF3ayBzY3JpcHQgYGRlZmluZXMuYXdrJywgZW1i
ZWRkZWQgYXMKKyMgaGVyZS1kb2N1bWVudCBpbiBjb25maWcuc3RhdHVzLCB0aGF0IHN1YnN0aXR1
dGVzIHRoZSBwcm9wZXIgdmFsdWVzIGludG8KKyMgY29uZmlnLmguaW4gdG8gcHJvZHVjZSBjb25m
aWcuaC4KKworIyBDcmVhdGUgYSBkZWxpbWl0ZXIgc3RyaW5nIHRoYXQgZG9lcyBub3QgZXhpc3Qg
aW4gY29uZmRlZnMuaCwgdG8gZWFzZQorIyBoYW5kbGluZyBvZiBsb25nIGxpbmVzLgorYWNfZGVs
aW09JyUhXyEjICcKK2ZvciBhY19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSA6OyBkbworICBhY190
PWBzZWQgLW4gIi8kYWNfZGVsaW0vcCIgY29uZmRlZnMuaGAKKyAgaWYgdGVzdCAteiAiJGFjX3Qi
OyB0aGVuCisgICAgYnJlYWsKKyAgZWxpZiAkYWNfbGFzdF90cnk7IHRoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAiY291bGQgbm90IG1ha2UgJENPTkZJR19IRUFERVJTIiAiJExJTkVOTyIgNQorICBl
bHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEkYWNfZGVsaW0gXyRhY19kZWxpbSEhICIKKyAg
ZmkKK2RvbmUKKworIyBGb3IgdGhlIGF3ayBzY3JpcHQsIEQgaXMgYW4gYXJyYXkgb2YgbWFjcm8g
dmFsdWVzIGtleWVkIGJ5IG5hbWUsCisjIGxpa2V3aXNlIFAgY29udGFpbnMgbWFjcm8gcGFyYW1l
dGVycyBpZiBhbnkuICBQcmVzZXJ2ZSBiYWNrc2xhc2gKKyMgbmV3bGluZSBzZXF1ZW5jZXMuCisK
K2FjX3dvcmRfcmU9W18kYXNfY3JfTGV0dGVyc11bXyRhc19jcl9hbG51bV0qCitzZWQgLW4gJwor
cy8uXHsxNDhcfS8mJyIkYWNfZGVsaW0iJy9nCit0IHJzZXQKKzpyc2V0CitzL15bCSBdKiNbCSBd
KmRlZmluZVsJIF1bCSBdKi8gLwordCBkZWYKK2QKKzpkZWYKK3MvXFwkLy8KK3QgYnNubAorcy9b
IlxcXS9cXCYvZworcy9eIFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSopXClbCSBdKlwoLipc
KS9QWyJcMSJdPSJcMiJcCitEWyJcMSJdPSIgXDMiL3AKK3MvXiBcKCciJGFjX3dvcmRfcmUiJ1wp
WwkgXSpcKC4qXCkvRFsiXDEiXT0iIFwyIi9wCitkCis6YnNubAorcy9bIlxcXS9cXCYvZworcy9e
IFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSopXClbCSBdKlwoLipcKS9QWyJcMSJdPSJcMiJc
CitEWyJcMSJdPSIgXDNcXFxcXFxuIlxcL3AKK3QgY29udAorcy9eIFwoJyIkYWNfd29yZF9yZSIn
XClbCSBdKlwoLipcKS9EWyJcMSJdPSIgXDJcXFxcXFxuIlxcL3AKK3QgY29udAorZAorOmNvbnQK
K24KK3MvLlx7MTQ4XH0vJiciJGFjX2RlbGltIicvZwordCBjbGVhcgorOmNsZWFyCitzL1xcJC8v
Cit0IGJzbmxjCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iL3AKK2QKKzpic25sYworcy9b
IlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvXFxcXFxcbiJcXC9wCitiIGNvbnQKKycgPGNvbmZkZWZz
LmggfCBzZWQgJworcy8nIiRhY19kZWxpbSInLyJcXFwKKyIvZycgPj4kQ09ORklHX1NUQVRVUyB8
fCBhY193cml0ZV9mYWlsPTEKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNf
d3JpdGVfZmFpbD0xCisgIGZvciAoa2V5IGluIEQpIERfaXNfc2V0W2tleV0gPSAxCisgIEZTID0g
IgciCit9CisvXltcdCBdKiNbXHQgXSooZGVmaW5lfHVuZGVmKVtcdCBdKyRhY193b3JkX3JlKFtc
dCAoXXxcJCkvIHsKKyAgbGluZSA9IFwkIDAKKyAgc3BsaXQobGluZSwgYXJnLCAiICIpCisgIGlm
IChhcmdbMV0gPT0gIiMiKSB7CisgICAgZGVmdW5kZWYgPSBhcmdbMl0KKyAgICBtYWMxID0gYXJn
WzNdCisgIH0gZWxzZSB7CisgICAgZGVmdW5kZWYgPSBzdWJzdHIoYXJnWzFdLCAyKQorICAgIG1h
YzEgPSBhcmdbMl0KKyAgfQorICBzcGxpdChtYWMxLCBtYWMyLCAiKCIpICMpCisgIG1hY3JvID0g
bWFjMlsxXQorICBwcmVmaXggPSBzdWJzdHIobGluZSwgMSwgaW5kZXgobGluZSwgZGVmdW5kZWYp
IC0gMSkKKyAgaWYgKERfaXNfc2V0W21hY3JvXSkgeworICAgICMgUHJlc2VydmUgdGhlIHdoaXRl
IHNwYWNlIHN1cnJvdW5kaW5nIHRoZSAiIyIuCisgICAgcHJpbnQgcHJlZml4ICJkZWZpbmUiLCBt
YWNybyBQW21hY3JvXSBEW21hY3JvXQorICAgIG5leHQKKyAgfSBlbHNlIHsKKyAgICAjIFJlcGxh
Y2UgI3VuZGVmIHdpdGggY29tbWVudHMuICBUaGlzIGlzIG5lY2Vzc2FyeSwgZm9yIGV4YW1wbGUs
CisgICAgIyBpbiB0aGUgY2FzZSBvZiBfUE9TSVhfU09VUkNFLCB3aGljaCBpcyBwcmVkZWZpbmVk
IGFuZCByZXF1aXJlZAorICAgICMgb24gc29tZSBzeXN0ZW1zIHdoZXJlIGNvbmZpZ3VyZSB3aWxs
IG5vdCBkZWNpZGUgdG8gZGVmaW5lIGl0LgorICAgIGlmIChkZWZ1bmRlZiA9PSAidW5kZWYiKSB7
CisgICAgICBwcmludCAiLyoiLCBwcmVmaXggZGVmdW5kZWYsIG1hY3JvLCAiKi8iCisgICAgICBu
ZXh0CisgICAgfQorICB9Cit9Cit7IHByaW50IH0KK19BQ0FXSworX0FDRU9GCitjYXQgPj4kQ09O
RklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGFzX2ZuX2Vycm9yICQ/
ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGhlYWRlcnMgbWFjaGluZXJ5IiAiJExJTkVOTyIgNQor
ZmkgIyB0ZXN0IC1uICIkQ09ORklHX0hFQURFUlMiCisKKworZXZhbCBzZXQgWCAiICA6RiAkQ09O
RklHX0ZJTEVTICA6SCAkQ09ORklHX0hFQURFUlMgICAgIgorc2hpZnQKK2ZvciBhY190YWcKK2Rv
CisgIGNhc2UgJGFjX3RhZyBpbgorICA6W0ZITENdKSBhY19tb2RlPSRhY190YWc7IGNvbnRpbnVl
OzsKKyAgZXNhYworICBjYXNlICRhY19tb2RlJGFjX3RhZyBpbgorICA6W0ZITF0qOiopOzsKKyAg
OkwqIHwgOkMqOiopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHRhZyBcYCRhY190YWcnIiAiJExJ
TkVOTyIgNSA7OworICA6W0ZIXS0pIGFjX3RhZz0tOi07OworICA6W0ZIXSopIGFjX3RhZz0kYWNf
dGFnOiRhY190YWcuaW47OworICBlc2FjCisgIGFjX3NhdmVfSUZTPSRJRlMKKyAgSUZTPToKKyAg
c2V0IHggJGFjX3RhZworICBJRlM9JGFjX3NhdmVfSUZTCisgIHNoaWZ0CisgIGFjX2ZpbGU9JDEK
KyAgc2hpZnQKKworICBjYXNlICRhY19tb2RlIGluCisgIDpMKSBhY19zb3VyY2U9JDE7OworICA6
W0ZIXSkKKyAgICBhY19maWxlX2lucHV0cz0KKyAgICBmb3IgYWNfZgorICAgIGRvCisgICAgICBj
YXNlICRhY19mIGluCisgICAgICAtKSBhY19mPSIkdG1wL3N0ZGluIjs7CisgICAgICAqKSAjIExv
b2sgZm9yIHRoZSBmaWxlIGZpcnN0IGluIHRoZSBidWlsZCB0cmVlLCB0aGVuIGluIHRoZSBzb3Vy
Y2UgdHJlZQorCSAjIChpZiB0aGUgcGF0aCBpcyBub3QgYWJzb2x1dGUpLiAgVGhlIGFic29sdXRl
IHBhdGggY2Fubm90IGJlIERPUy1zdHlsZSwKKwkgIyBiZWNhdXNlICRhY19mIGNhbm5vdCBjb250
YWluIGA6Jy4KKwkgdGVzdCAtZiAiJGFjX2YiIHx8CisJICAgY2FzZSAkYWNfZiBpbgorCSAgIFtc
XC8kXSopIGZhbHNlOzsKKwkgICAqKSB0ZXN0IC1mICIkc3JjZGlyLyRhY19mIiAmJiBhY19mPSIk
c3JjZGlyLyRhY19mIjs7CisJICAgZXNhYyB8fAorCSAgIGFzX2ZuX2Vycm9yIDEgImNhbm5vdCBm
aW5kIGlucHV0IGZpbGU6IFxgJGFjX2YnIiAiJExJTkVOTyIgNSA7OworICAgICAgZXNhYworICAg
ICAgY2FzZSAkYWNfZiBpbiAqXCcqKSBhY19mPWAkYXNfZWNobyAiJGFjX2YiIHwgc2VkICJzLycv
J1xcXFxcXFxcJycvZyJgOzsgZXNhYworICAgICAgYXNfZm5fYXBwZW5kIGFjX2ZpbGVfaW5wdXRz
ICIgJyRhY19mJyIKKyAgICBkb25lCisKKyAgICAjIExldCdzIHN0aWxsIHByZXRlbmQgaXQgaXMg
YGNvbmZpZ3VyZScgd2hpY2ggaW5zdGFudGlhdGVzIChpLmUuLCBkb24ndAorICAgICMgdXNlICRh
c19tZSksIHBlb3BsZSB3b3VsZCBiZSBzdXJwcmlzZWQgdG8gcmVhZDoKKyAgICAjICAgIC8qIGNv
bmZpZy5oLiAgR2VuZXJhdGVkIGJ5IGNvbmZpZy5zdGF0dXMuICAqLworICAgIGNvbmZpZ3VyZV9p
bnB1dD0nR2VuZXJhdGVkIGZyb20gJ2AKKwkgICRhc19lY2hvICIkKiIgfCBzZWQgJ3N8XlteOl0q
L3x8O3N8OlteOl0qL3wsIHxnJworCWAnIGJ5IGNvbmZpZ3VyZS4nCisgICAgaWYgdGVzdCB4IiRh
Y19maWxlIiAhPSB4LTsgdGhlbgorICAgICAgY29uZmlndXJlX2lucHV0PSIkYWNfZmlsZS4gICRj
b25maWd1cmVfaW5wdXQiCisgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNyZWF0aW5nICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGNyZWF0aW5n
ICRhY19maWxlIiA+JjY7fQorICAgIGZpCisgICAgIyBOZXV0cmFsaXplIHNwZWNpYWwgY2hhcmFj
dGVycyBpbnRlcnByZXRlZCBieSBzZWQgaW4gcmVwbGFjZW1lbnQgc3RyaW5ncy4KKyAgICBjYXNl
ICRjb25maWd1cmVfaW5wdXQgaW4gIygKKyAgICAqXCYqIHwgKlx8KiB8ICpcXCogKQorICAgICAg
IGFjX3NlZF9jb25mX2lucHV0PWAkYXNfZWNobyAiJGNvbmZpZ3VyZV9pbnB1dCIgfAorICAgICAg
IHNlZCAncy9bXFxcXCZ8XS9cXFxcJi9nJ2A7OyAjKAorICAgICopIGFjX3NlZF9jb25mX2lucHV0
PSRjb25maWd1cmVfaW5wdXQ7OworICAgIGVzYWMKKworICAgIGNhc2UgJGFjX3RhZyBpbgorICAg
ICo6LToqIHwgKjotKSBjYXQgPiIkdG1wL3N0ZGluIiBcCisgICAgICB8fCBhc19mbl9lcnJvciAk
PyAiY291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUgIDs7CisgICAgZXNhYwor
ICAgIDs7CisgIGVzYWMKKworICBhY19kaXI9YCRhc19kaXJuYW1lIC0tICIkYWNfZmlsZSIgfHwK
KyRhc19leHByIFgiJGFjX2ZpbGUiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBc
CisJIFgiJGFjX2ZpbGUiIDogJ1hcKC8vXClbXi9dJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hc
KC8vXCkkJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8
fAorJGFzX2VjaG8gWCIkYWNfZmlsZSIgfAorICAgIHNlZCAnL15YXCguKlteL11cKVwvXC8qW14v
XVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKVte
L10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKSQveworCSAg
ICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wpLioveworCSAgICBzLy9cMS8KKwkg
ICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgIGFzX2Rpcj0iJGFjX2RpciI7IGFzX2ZuX21r
ZGlyX3AKKyAgYWNfYnVpbGRkaXI9LgorCitjYXNlICIkYWNfZGlyIiBpbgorLikgYWNfZGlyX3N1
ZmZpeD0gYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7CisqKQor
ICBhY19kaXJfc3VmZml4PS9gJGFzX2VjaG8gIiRhY19kaXIiIHwgc2VkICdzfF5cLltcXC9dfHwn
YAorICAjIEEgIi4uIiBmb3IgZWFjaCBkaXJlY3RvcnkgaW4gJGFjX2Rpcl9zdWZmaXguCisgIGFj
X3RvcF9idWlsZGRpcl9zdWI9YCRhc19lY2hvICIkYWNfZGlyX3N1ZmZpeCIgfCBzZWQgJ3N8L1te
XFwvXSp8Ly4ufGc7c3wvfHwnYAorICBjYXNlICRhY190b3BfYnVpbGRkaXJfc3ViIGluCisgICIi
KSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZpeD0gOzsKKyAgKikgIGFj
X3RvcF9idWlsZF9wcmVmaXg9JGFjX3RvcF9idWlsZGRpcl9zdWIvIDs7CisgIGVzYWMgOzsKK2Vz
YWMKK2FjX2Fic190b3BfYnVpbGRkaXI9JGFjX3B3ZAorYWNfYWJzX2J1aWxkZGlyPSRhY19wd2Qk
YWNfZGlyX3N1ZmZpeAorIyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eToKK2FjX3RvcF9idWls
ZGRpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeAorCitjYXNlICRzcmNkaXIgaW4KKyAgLikgICMgV2Ug
YXJlIGJ1aWxkaW5nIGluIHBsYWNlLgorICAgIGFjX3NyY2Rpcj0uCisgICAgYWNfdG9wX3NyY2Rp
cj0kYWNfdG9wX2J1aWxkZGlyX3N1YgorICAgIGFjX2Fic190b3Bfc3JjZGlyPSRhY19wd2QgOzsK
KyAgW1xcL10qIHwgPzpbXFwvXSogKSAgIyBBYnNvbHV0ZSBuYW1lLgorICAgIGFjX3NyY2Rpcj0k
c3JjZGlyJGFjX2Rpcl9zdWZmaXg7CisgICAgYWNfdG9wX3NyY2Rpcj0kc3JjZGlyCisgICAgYWNf
YWJzX3RvcF9zcmNkaXI9JHNyY2RpciA7OworICAqKSAjIFJlbGF0aXZlIG5hbWUuCisgICAgYWNf
c3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpciRhY19kaXJfc3VmZml4CisgICAgYWNf
dG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIKKyAgICBhY19hYnNfdG9wX3Ny
Y2Rpcj0kYWNfcHdkLyRzcmNkaXIgOzsKK2VzYWMKK2FjX2Fic19zcmNkaXI9JGFjX2Fic190b3Bf
c3JjZGlyJGFjX2Rpcl9zdWZmaXgKKworCisgIGNhc2UgJGFjX21vZGUgaW4KKyAgOkYpCisgICMK
KyAgIyBDT05GSUdfRklMRQorICAjCisKKyAgY2FzZSAkSU5TVEFMTCBpbgorICBbXFwvJF0qIHwg
PzpbXFwvXSogKSBhY19JTlNUQUxMPSRJTlNUQUxMIDs7CisgICopIGFjX0lOU1RBTEw9JGFjX3Rv
cF9idWlsZF9wcmVmaXgkSU5TVEFMTCA7OworICBlc2FjCitfQUNFT0YKKworY2F0ID4+JENPTkZJ
R19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBJZiB0aGUgdGVtcGxhdGUg
ZG9lcyBub3Qga25vdyBhYm91dCBkYXRhcm9vdGRpciwgZXhwYW5kIGl0LgorIyBGSVhNRTogVGhp
cyBoYWNrIHNob3VsZCBiZSByZW1vdmVkIGEgZmV3IHllYXJzIGFmdGVyIDIuNjAuCithY19kYXRh
cm9vdGRpcl9oYWNrPTsgYWNfZGF0YXJvb3RkaXJfc2Vlbj0KK2FjX3NlZF9kYXRhcm9vdD0nCisv
ZGF0YXJvb3RkaXIvIHsKKyAgcAorICBxCit9CisvQGRhdGFkaXJAL3AKKy9AZG9jZGlyQC9wCisv
QGluZm9kaXJAL3AKKy9AbG9jYWxlZGlyQC9wCisvQG1hbmRpckAvcCcKK2Nhc2UgYGV2YWwgInNl
ZCAtbiBcIlwkYWNfc2VkX2RhdGFyb290XCIgJGFjX2ZpbGVfaW5wdXRzImAgaW4KKypkYXRhcm9v
dGRpciopIGFjX2RhdGFyb290ZGlyX3NlZW49eWVzOzsKKypAZGF0YWRpckAqfCpAZG9jZGlyQCp8
KkBpbmZvZGlyQCp8KkBsb2NhbGVkaXJAKnwqQG1hbmRpckAqKQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICRhY19maWxlX2lucHV0cyBzZWVtcyB0
byBpZ25vcmUgdGhlIC0tZGF0YXJvb3RkaXIgc2V0dGluZyIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiAkYWNfZmlsZV9pbnB1dHMgc2VlbXMgdG8gaWdub3JlIHRoZSAtLWRhdGFyb290
ZGlyIHNldHRpbmciID4mMjt9CitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9G
IHx8IGFjX3dyaXRlX2ZhaWw9MQorICBhY19kYXRhcm9vdGRpcl9oYWNrPScKKyAgcyZAZGF0YWRp
ckAmJGRhdGFkaXImZworICBzJkBkb2NkaXJAJiRkb2NkaXImZworICBzJkBpbmZvZGlyQCYkaW5m
b2RpciZnCisgIHMmQGxvY2FsZWRpckAmJGxvY2FsZWRpciZnCisgIHMmQG1hbmRpckAmJG1hbmRp
ciZnCisgIHMmXFxcJHtkYXRhcm9vdGRpcn0mJGRhdGFyb290ZGlyJmcnIDs7Citlc2FjCitfQUNF
T0YKKworIyBOZXV0cmFsaXplIFZQQVRIIHdoZW4gYCRzcmNkaXInID0gYC4nLgorIyBTaGVsbCBj
b2RlIGluIGNvbmZpZ3VyZS5hYyBtaWdodCBzZXQgZXh0cmFzdWIuCisjIEZJWE1FOiBkbyB3ZSBy
ZWFsbHkgd2FudCB0byBtYWludGFpbiB0aGlzIGZlYXR1cmU/CitjYXQgPj4kQ09ORklHX1NUQVRV
UyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2FjX3NlZF9leHRyYT0iJGFjX3Zwc3ViCisk
ZXh0cmFzdWIKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dy
aXRlX2ZhaWw9MQorOnQKKy9AW2EtekEtWl9dW2EtekEtWl8wLTldKkAvIWIKK3N8QGNvbmZpZ3Vy
ZV9pbnB1dEB8JGFjX3NlZF9jb25mX2lucHV0fDt0IHQKK3MmQHRvcF9idWlsZGRpckAmJGFjX3Rv
cF9idWlsZGRpcl9zdWImO3QgdAorcyZAdG9wX2J1aWxkX3ByZWZpeEAmJGFjX3RvcF9idWlsZF9w
cmVmaXgmO3QgdAorcyZAc3JjZGlyQCYkYWNfc3JjZGlyJjt0IHQKK3MmQGFic19zcmNkaXJAJiRh
Y19hYnNfc3JjZGlyJjt0IHQKK3MmQHRvcF9zcmNkaXJAJiRhY190b3Bfc3JjZGlyJjt0IHQKK3Mm
QGFic190b3Bfc3JjZGlyQCYkYWNfYWJzX3RvcF9zcmNkaXImO3QgdAorcyZAYnVpbGRkaXJAJiRh
Y19idWlsZGRpciY7dCB0CitzJkBhYnNfYnVpbGRkaXJAJiRhY19hYnNfYnVpbGRkaXImO3QgdAor
cyZAYWJzX3RvcF9idWlsZGRpckAmJGFjX2Fic190b3BfYnVpbGRkaXImO3QgdAorcyZASU5TVEFM
TEAmJGFjX0lOU1RBTEwmO3QgdAorJGFjX2RhdGFyb290ZGlyX2hhY2sKKyIKK2V2YWwgc2VkIFwi
XCRhY19zZWRfZXh0cmFcIiAiJGFjX2ZpbGVfaW5wdXRzIiB8ICRBV0sgLWYgIiR0bXAvc3Vicy5h
d2siID4kdG1wL291dCBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3JlYXRlICRh
Y19maWxlIiAiJExJTkVOTyIgNQorCit0ZXN0IC16ICIkYWNfZGF0YXJvb3RkaXJfaGFjayRhY19k
YXRhcm9vdGRpcl9zZWVuIiAmJgorICB7IGFjX291dD1gc2VkIC1uICcvXCR7ZGF0YXJvb3RkaXJ9
L3AnICIkdG1wL291dCJgOyB0ZXN0IC1uICIkYWNfb3V0IjsgfSAmJgorICB7IGFjX291dD1gc2Vk
IC1uICcvXlsJIF0qZGF0YXJvb3RkaXJbCSBdKjoqPS9wJyAiJHRtcC9vdXQiYDsgdGVzdCAteiAi
JGFjX291dCI7IH0gJiYKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiAkYWNfZmlsZSBjb250YWlucyBhIHJlZmVyZW5jZSB0byB0aGUgdmFyaWFibGUg
XGBkYXRhcm9vdGRpcicKK3doaWNoIHNlZW1zIHRvIGJlIHVuZGVmaW5lZC4gIFBsZWFzZSBtYWtl
IHN1cmUgaXQgaXMgZGVmaW5lZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkYWNf
ZmlsZSBjb250YWlucyBhIHJlZmVyZW5jZSB0byB0aGUgdmFyaWFibGUgXGBkYXRhcm9vdGRpcicK
K3doaWNoIHNlZW1zIHRvIGJlIHVuZGVmaW5lZC4gIFBsZWFzZSBtYWtlIHN1cmUgaXQgaXMgZGVm
aW5lZCIgPiYyO30KKworICBybSAtZiAiJHRtcC9zdGRpbiIKKyAgY2FzZSAkYWNfZmlsZSBpbgor
ICAtKSBjYXQgIiR0bXAvb3V0IiAmJiBybSAtZiAiJHRtcC9vdXQiOzsKKyAgKikgcm0gLWYgIiRh
Y19maWxlIiAmJiBtdiAiJHRtcC9vdXQiICIkYWNfZmlsZSI7OworICBlc2FjIFwKKyAgfHwgYXNf
Zm5fZXJyb3IgJD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgOzsK
KyAgOkgpCisgICMKKyAgIyBDT05GSUdfSEVBREVSCisgICMKKyAgaWYgdGVzdCB4IiRhY19maWxl
IiAhPSB4LTsgdGhlbgorICAgIHsKKyAgICAgICRhc19lY2hvICIvKiAkY29uZmlndXJlX2lucHV0
ICAqLyIgXAorICAgICAgJiYgZXZhbCAnJEFXSyAtZiAiJHRtcC9kZWZpbmVzLmF3ayInICIkYWNf
ZmlsZV9pbnB1dHMiCisgICAgfSA+IiR0bXAvY29uZmlnLmgiIFwKKyAgICAgIHx8IGFzX2ZuX2Vy
cm9yICQ/ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGlmIGRp
ZmYgIiRhY19maWxlIiAiJHRtcC9jb25maWcuaCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgICAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY19maWxlIGlzIHVu
Y2hhbmdlZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAkYWNfZmlsZSBpcyB1bmNoYW5nZWQiID4m
Njt9CisgICAgZWxzZQorICAgICAgcm0gLWYgIiRhY19maWxlIgorICAgICAgbXYgIiR0bXAvY29u
ZmlnLmgiICIkYWNfZmlsZSIgXAorCXx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3JlYXRl
ICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGZpCisgIGVsc2UKKyAgICAkYXNfZWNobyAiLyog
JGNvbmZpZ3VyZV9pbnB1dCAgKi8iIFwKKyAgICAgICYmIGV2YWwgJyRBV0sgLWYgIiR0bXAvZGVm
aW5lcy5hd2siJyAiJGFjX2ZpbGVfaW5wdXRzIiBcCisgICAgICB8fCBhc19mbl9lcnJvciAkPyAi
Y291bGQgbm90IGNyZWF0ZSAtIiAiJExJTkVOTyIgNQorICBmaQorIDs7CisKKworICBlc2FjCisK
K2RvbmUgIyBmb3IgYWNfdGFnCisKKworYXNfZm5fZXhpdCAwCitfQUNFT0YKK2FjX2NsZWFuX2Zp
bGVzPSRhY19jbGVhbl9maWxlc19zYXZlCisKK3Rlc3QgJGFjX3dyaXRlX2ZhaWwgPSAwIHx8Cisg
IGFzX2ZuX2Vycm9yICQ/ICJ3cml0ZSBmYWlsdXJlIGNyZWF0aW5nICRDT05GSUdfU1RBVFVTIiAi
JExJTkVOTyIgNQorCisKKyMgY29uZmlndXJlIGlzIHdyaXRpbmcgdG8gY29uZmlnLmxvZywgYW5k
IHRoZW4gY2FsbHMgY29uZmlnLnN0YXR1cy4KKyMgY29uZmlnLnN0YXR1cyBkb2VzIGl0cyBvd24g
cmVkaXJlY3Rpb24sIGFwcGVuZGluZyB0byBjb25maWcubG9nLgorIyBVbmZvcnR1bmF0ZWx5LCBv
biBET1MgdGhpcyBmYWlscywgYXMgY29uZmlnLmxvZyBpcyBzdGlsbCBrZXB0IG9wZW4KKyMgYnkg
Y29uZmlndXJlLCBzbyBjb25maWcuc3RhdHVzIHdvbid0IGJlIGFibGUgdG8gd3JpdGUgdG8gaXQ7
IGl0cworIyBvdXRwdXQgaXMgc2ltcGx5IGRpc2NhcmRlZC4gIFNvIHdlIGV4ZWMgdGhlIEZEIHRv
IC9kZXYvbnVsbCwKKyMgZWZmZWN0aXZlbHkgY2xvc2luZyBjb25maWcubG9nLCBzbyBpdCBjYW4g
YmUgcHJvcGVybHkgKHJlKW9wZW5lZCBhbmQKKyMgYXBwZW5kZWQgdG8gYnkgY29uZmlnLnN0YXR1
cy4gIFdoZW4gY29taW5nIGJhY2sgdG8gY29uZmlndXJlLCB3ZQorIyBuZWVkIHRvIG1ha2UgdGhl
IEZEIGF2YWlsYWJsZSBhZ2Fpbi4KK2lmIHRlc3QgIiRub19jcmVhdGUiICE9IHllczsgdGhlbgor
ICBhY19jc19zdWNjZXNzPToKKyAgYWNfY29uZmlnX3N0YXR1c19hcmdzPQorICB0ZXN0ICIkc2ls
ZW50IiA9IHllcyAmJgorICAgIGFjX2NvbmZpZ19zdGF0dXNfYXJncz0iJGFjX2NvbmZpZ19zdGF0
dXNfYXJncyAtLXF1aWV0IgorICBleGVjIDU+L2Rldi9udWxsCisgICRTSEVMTCAkQ09ORklHX1NU
QVRVUyAkYWNfY29uZmlnX3N0YXR1c19hcmdzIHx8IGFjX2NzX3N1Y2Nlc3M9ZmFsc2UKKyAgZXhl
YyA1Pj5jb25maWcubG9nCisgICMgVXNlIHx8LCBub3QgJiYsIHRvIGF2b2lkIGV4aXRpbmcgZnJv
bSB0aGUgaWYgd2l0aCAkPyA9IDEsIHdoaWNoCisgICMgd291bGQgbWFrZSBjb25maWd1cmUgZmFp
bCBpZiB0aGlzIGlzIHRoZSBsYXN0IGluc3RydWN0aW9uLgorICAkYWNfY3Nfc3VjY2VzcyB8fCBh
c19mbl9leGl0IDEKK2ZpCitpZiB0ZXN0IC1uICIkYWNfdW5yZWNvZ25pemVkX29wdHMiICYmIHRl
c3QgIiRlbmFibGVfb3B0aW9uX2NoZWNraW5nIiAhPSBubzsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVucmVjb2duaXplZCBvcHRpb25z
OiAkYWNfdW5yZWNvZ25pemVkX29wdHMiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYyO30KK2ZpCisK
ZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2NvbmZpZ3VyZS5hYwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9j
b25maWd1cmUuYWMJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTg5
IEBACisjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtKi0g
QXV0b2NvbmYgLSotCisjIFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0b2NvbmYgdG8gcHJvZHVj
ZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCisKK0FDX1BSRVJFUShbMi42N10pCitBQ19JTklUKFtYZW4g
SHlwZXJ2aXNvcl0sIG00X2VzeXNjbWQoWy4uL3ZlcnNpb24uc2ggLi4veGVuL01ha2VmaWxlXSks
CisgICAgW3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKK0FDX0NPTkZJR19TUkNESVIo
W2xpYnhsL2xpYnhsLmNdKQorQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMubWtdKQor
QUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKK0FDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkK
K0FDX0NPTkZJR19BVVhfRElSKFsuXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJ
QlMsIENQUEZMQUdTIG9yIENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitBU19JRihb
dGVzdCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsKKyAgICBB
Q19NU0dfV0FSTigKK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdT
IG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQ
RU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBw
b3NzaWJsZS5dKQorXSkKKworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCitBQ19DQU5PTklDQUxf
SE9TVAorCisjIE00IE1hY3JvIGluY2x1ZGVzCittNF9pbmNsdWRlKFttNC9lbmFibGVfZmVhdHVy
ZS5tNF0pCittNF9pbmNsdWRlKFttNC9kaXNhYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5jbHVkZShb
bTQvcGF0aF9vcl9mYWlsLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRdKQorbTRf
aW5jbHVkZShbbTQvcHl0aG9uX3ZlcnNpb24ubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX2Rl
dmVsLm00XSkKK200X2luY2x1ZGUoW200L3VkZXYubTRdKQorbTRfaW5jbHVkZShbbTQvb2NhbWwu
bTRdKQorbTRfaW5jbHVkZShbbTQvZGVmYXVsdF9saWIubTRdKQorbTRfaW5jbHVkZShbbTQvc2V0
X2NmbGFnc19sZGZsYWdzLm00XSkKKworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCitBWF9BUkdf
RU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCisgICAgW0VuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxl
IChieSBkZWZhdWx0LCBGbGFzayldKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtnaXRodHRw
XSwgW0Rvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFBdKQorQVhfQVJHX0RJU0FCTEVf
QU5EX0VYUE9SVChbbW9uaXRvcnNdLAorICAgIFtEaXNhYmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBt
b25pdG9yaW5nIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbdnRwbV0sIFtFbmFi
bGUgVmlydHVhbCBUcnVzdGVkIFBsYXRmb3JtIE1vZHVsZV0pCitBWF9BUkdfRU5BQkxFX0FORF9F
WFBPUlQoW3hhcGldLCBbRW5hYmxlIFhlbiBBUEkgQmluZGluZ3NdKQorQVhfQVJHX0RJU0FCTEVf
QU5EX0VYUE9SVChbcHl0aG9udG9vbHNdLCBbRGlzYWJsZSBQeXRob24gdG9vbHNdKQorQVhfQVJH
X0RJU0FCTEVfQU5EX0VYUE9SVChbb2NhbWx0b29sc10sIFtEaXNhYmxlIE9jYW1sIHRvb2xzXSkK
K0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbWluaXRlcm1dLCBbRW5hYmxlIG1pbml0ZXJtXSkK
K0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbG9tb3VudF0sIFtFbmFibGUgbG9tb3VudF0pCitB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtkZWJ1Z10sIFtEaXNhYmxlIGRlYnVnIGJ1aWxkIG9m
IFhlbiBhbmQgdG9vbHNdKQorCitBQ19BUkdfVkFSKFtQUkVQRU5EX0lOQ0xVREVTXSwKKyAgICBb
TGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkp
XSkKK0FDX0FSR19WQVIoW1BSRVBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRl
cnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKV0pCitBQ19BUkdfVkFSKFtBUFBF
TkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8g
Q0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfTElCXSwKKyAgICBbTGlz
dCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gYXBwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkK
KworQVhfU0VUX0ZMQUdTCisKK0FDX0FSR19WQVIoW1BZVEhPTl0sIFtQYXRoIHRvIHRoZSBQeXRo
b24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBhcnNlcl0pCitB
Q19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJHX1ZBUihbSVBd
LCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGggdG8gQmlzb24g
cGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8gRmxleCBsZXhp
Y2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1BhdGggdG8gY3Vy
bC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwyLWNvbmZpZyB0
b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkKK0FDX0FSR19W
QVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENoZWNrcyBmb3Ig
cHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJPR19DQworQUNfUFJPR19MTl9TCitBQ19QUk9H
X01BS0VfU0VUCitBQ19QUk9HX0lOU1RBTEwKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtQRVJMXSwg
W3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkKK0FYX1BBVEhf
UFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQklTT05dLCBb
Ymlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitBU19JRihbdGVz
dCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0NVUkxdLCBb
Y3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBbeG1sMi1jb25m
aWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsKKyAgICBBQ19Q
Uk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWworICAgICAg
ICBBU19JRihbdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyJdLCBbCisgICAgICAg
ICAgICBBQ19NU0dfRVJST1IoW09jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmlu
ZCBPY2FtbF0pXSkKKyAgICAgICAgb2NhbWx0b29scz0ibiIKKyAgICBdKQorXSkKK0FYX1BBVEhf
UFJPR19PUl9GQUlMKFtCQVNIXSwgW2Jhc2hdKQorQVNfSUYoW3Rlc3QgIngkcHl0aG9udG9vbHMi
ID0gInh5Il0sIFsKKyAgICBBU19JRihbZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyJdLCBb
CisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQ
WVRIT05QQVRIYAorICAgIF0sW3Rlc3QgLXogIiRQWVRIT04iXSwgW1BZVEhPTj0icHl0aG9uIl0s
CisgICAgW0FDX01TR19FUlJPUihbUFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNv
bHV0ZSBwYXRoXSldKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtQWVRIT05QQVRIXSwgWyRQ
WVRIT05dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9WRVJTSU9OKFsyXSwgWzNdKQorICAgIEFYX0NI
RUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNLX1BZVEhPTl9ERVZFTCgpCitdKQorQVhfUEFU
SF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hnZXR0ZXh0XSkKK0FYX0NIRUNLX1VERVYoWzU5
XSkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRfTElCCisKKyMgQ2hlY2tzIGZv
ciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10sIFtpb19zZXR1cF0sIFtzeXN0ZW1fYWlv
PSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJTVChzeXN0ZW1fYWlvKQorQUNfQ0hFQ0tf
TElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxp
YmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4dDJmc19vcGVuMl0sIFtsaWJl
eHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNfU1VCU1QobGliZXh0MmZzKQorQUNfQ0hF
Q0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwg
W2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2NyeXB0KQorQUNfQ0hFQ0tfTElCKFtwdGhy
ZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5v
dCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2NrX2dldHRpbWVd
KQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBbXSwKKyAgICBbQUNfTVNHX0VS
Uk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lh
amxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5YWpsXSld
KQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJST1IoW0Nv
dWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmljb252X29w
ZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCitBQ19TVUJTVChsaWJpY29udikK
KworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNr
KQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNfQUxMT0NBCitBQ19DSEVDS19I
RUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMu
aCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5ldGRiLmgg
bmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAg
ICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBz
eXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmgg
c3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVuaXN0ZC5o
IHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAgICAgICAgIF0pCisKKyMgQ2hlY2tzIGZv
ciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KK0FD
X0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitBQ19DX0lOTElORQorQUNfVFlQRV9JTlQx
Nl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5UNjRfVAorQUNfVFlQRV9JTlQ4X1QKK0FD
X1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19UWVBFX1BJRF9UCitBQ19DX1JFU1RSSUNU
CitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9UCitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1
Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9TVF9CTE9DS1MKK0FDX0NIRUNLX01FTUJF
UlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5UMTZfVAorQUNfVFlQRV9VSU5U
MzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9VSU5UOF9UCitBQ19DSEVDS19UWVBFUyhb
cHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgorQUNfRlVOQ19F
UlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNFRUtPCitBQ19GVU5DX0xTVEFU
X0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFERVJfTUFKT1IKK0FDX0ZVTkNfTUFMTE9D
CitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitBQ19GVU5DX1JFQUxMT0MKK0FDX0ZVTkNf
U1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAgICAgICAg
ICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVu
Y2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUg
Z2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNh
c2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAgICAgICAg
ICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxl
Y3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3Ry
Y3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3RycGJyayBz
dHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAorICAg
ICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQVVQoKQpk
aWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvZGVidWdnZXIvZ2Ric3gv
eGcvTWFrZWZpbGUKLS0tIGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJTW9uIEph
biAwOSAxNjowMTo0NCAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01h
a2VmaWxlCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMjEsNyArMjEsNiBAQCB4
Z19hbGwuYTogJChYR19PQkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMg
LW8gJEAgJF4KIAogeGVuLWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVjayAKIAkk
KE1BS0UpIC1DIC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4uYyBNYWtl
ZmlsZSAkKFhHX0hEUlMpCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29s
cy9pbnN0YWxsLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3Rvb2xzL2luc3RhbGwuc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsMSBAQAorLi4vaW5zdGFsbC5zaApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUK
ZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL2xpYmZzaW1hZ2UvTWFr
ZWZpbGUKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlNb24gSmFuIDA5IDE2OjAxOjQ0
IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUdWUgSmFuIDEwIDE5
OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTIsNyArMiwxMSBAQCBYRU5fUk9PVCA9ICQoQ1VSRElSKS8u
Li8uLgogaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBj
b21tb24gdWZzIHJlaXNlcmZzIGlzbzk2NjAgZmF0IHpmcyB4ZnMKLVNVQkRJUlMteSArPSAkKHNo
ZWxsIGVudiBDQz0iJChDQykiIC4vY2hlY2stbGliZXh0MmZzKQoraWZlcSAoJChDT05GSUdfRVhU
MkZTKSwgeSkKKyAgICBTVUJESVJTLXkgKz0gZXh0MmZzLWxpYgorZWxzZQorICAgIFNVQkRJUlMt
eSArPSBleHQyZnMKK2VuZGlmCiAKIC5QSE9OWTogYWxsIGNsZWFuIGluc3RhbGwKIGFsbCBjbGVh
biBpbnN0YWxsOiAlOiBzdWJkaXJzLSUKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0
MTllIHRvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCi0tLSBhL3Rvb2xzL2xpYmZzaW1h
Z2UvY2hlY2stbGliZXh0MmZzCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMSArMCwwIEBACi0j
IS9iaW4vc2gKLQotY2F0ID5leHQyLXRlc3QuYyA8PEVPRgotI2luY2x1ZGUgPGV4dDJmcy9leHQy
ZnMuaD4KLQotaW50IG1haW4oKQotewotCWV4dDJmc19vcGVuMjsKLX0KLUVPRgotCi0ke0NDLWdj
Y30gLW8gZXh0Mi10ZXN0IGV4dDItdGVzdC5jIC1sZXh0MmZzID4vZGV2L251bGwgMj4mMQotaWYg
WyAkPyA9IDAgXTsgdGhlbgotCWVjaG8gZXh0MmZzLWxpYgotZWxzZQotCWVjaG8gZXh0MmZzCi1m
aQotCi1ybSAtZiBleHQyLXRlc3QgZXh0Mi10ZXN0LmMKLQotZXhpdCAwCmRpZmYgLXIgNWIyNjc2
YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9saWJ4ZW4vTWFrZWZpbGUKLS0tIGEvdG9vbHMv
bGlieGVuL01ha2VmaWxlCU1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAorKysgYi90b29s
cy9saWJ4ZW4vTWFrZWZpbGUJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0yMiwx
MiArMjIsMTIgQEAgTUFKT1IgPSAxLjAKIE1JTk9SID0gMAogCiBDRkxBR1MgKz0gLUlpbmNsdWRl
ICAgICAgICAgICAgICAgICAgICAgXAotICAgICAgICAgICQoc2hlbGwgeG1sMi1jb25maWcgLS1j
ZmxhZ3MpIFwKLSAgICAgICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tY2ZsYWdzKSBcCisgICAg
ICAgICAgJChzaGVsbCAkKFhNTDJfQ09ORklHKSAtLWNmbGFncykgXAorICAgICAgICAgICQoc2hl
bGwgJChDVVJMX0NPTkZJRykgLS1jZmxhZ3MpIFwKICAgICAgICAgICAtZlBJQwogCi1MREZMQUdT
ICs9ICQoc2hlbGwgeG1sMi1jb25maWcgLS1saWJzKSBcCi0gICAgICAgICAgICQoc2hlbGwgY3Vy
bC1jb25maWcgLS1saWJzKQorTERGTEFHUyArPSAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tbGli
cykgXAorICAgICAgICAgICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tbGlicykKIAogTElCWEVO
QVBJX0hEUlMgPSAkKHdpbGRjYXJkIGluY2x1ZGUveGVuL2FwaS8qLmgpIGluY2x1ZGUveGVuL2Fw
aS94ZW5fYWxsLmgKIExJQlhFTkFQSV9PQkpTID0gJChwYXRzdWJzdCAlLmMsICUubywgJCh3aWxk
Y2FyZCBzcmMvKi5jKSkKZGlmZiAtciA1YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xz
L200L2RlZmF1bHRfbGliLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL200L2RlZmF1bHRfbGliLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEg
MjAxMiArMDEwMApAQCAtMCwwICsxLDggQEAKK0FDX0RFRlVOKFtBWF9ERUZBVUxUX0xJQl0sCitb
QVNfSUYoW3Rlc3QgLWQgIiRwcmVmaXgvbGliNjQiXSwgWworICAgIExJQl9QQVRIPSJsaWI2NCIK
K10sWworICAgIExJQl9QQVRIPSJsaWIiCitdKQorQUNfU1VCU1QoTElCX1BBVEgpXSkKKwpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvZGlzYWJsZV9mZWF0dXJl
Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAK
QEAgLTAsMCArMSwxMyBAQAorQUNfREVGVU4oW0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlRdLAor
W0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhbLS1kaXNhYmxlLSQxXSwg
WyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9j
dl8kMT0ibiIKK10sIFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3Zf
JDE9InkiCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdKQor
JDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA2ZmRl
MDE3YzQxOWUgdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQJ
VHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVO
KFtBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBB
U19IRUxQX1NUUklORyhbLS1lbmFibGUtJDFdLCBbJDJdKSkKKworQVNfSUYoW3Rlc3QgIngkZW5h
YmxlXyQxIiA9ICJ4eWVzIl0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0ZXN0ICJ4JGVuYWJs
ZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0IC16ICRheF9jdl8k
MV0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10pCiskMT0kYXhfY3ZfJDEKK0FDX1NVQlNUKCQxKV0p
CmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9tNC9vY2FtbC5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC9vY2FtbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyNDEg
QEAKK2RubCBhdXRvY29uZiBtYWNyb3MgZm9yIE9DYW1sCitkbmwgZnJvbSBodHRwOi8vZm9yZ2Uu
b2NhbWxjb3JlLm9yZy8KK2RubAorZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgUmljaGFyZCBX
Lk0uIEpvbmVzCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAgICBTdGVmYW5vIFphY2NoaXJvbGkK
K2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IE9saXZpZXIgQW5kcmlldQorZG5sIENvcHlyaWdo
dCDCqSAyMDAwLTIwMDUgSmVhbi1DaHJpc3RvcGhlIEZpbGxpw6J0cmUKK2RubCBDb3B5cmlnaHQg
wqkgMjAwMC0yMDA1IEdlb3JnZXMgTWFyaWFubworZG5sCitkbmwgRm9yIGRvY3VtZW50YXRpb24s
IHBsZWFzZSByZWFkIHRoZSBvY2FtbC5tNCBtYW4gcGFnZS4KKworQUNfREVGVU4oW0FDX1BST0df
T0NBTUxdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgQUNfQ0hFQ0tfVE9PTChb
T0NBTUxDXSxbb2NhbWxjXSxbbm9dKQorCisgIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRo
ZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCdgCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIHZlcnNpb24gaXMg
JE9DQU1MVkVSU0lPTl0pCisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAg
aWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxD
IC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0
YAorICAgICBlbHNlCisgICAgICAgIEFDX01TR19SRVNVTFQoW09DQU1MTElCIHByZXZpb3VzbHkg
c2V0OyBwcmVzZXJ2aW5nIGl0Ll0pCisgICAgIGZpCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1s
IGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUJdKQorCisgICAgIEFDX1NVQlNUKFtPQ0FNTFZFUlNJ
T05dKQorICAgICBBQ19TVUJTVChbT0NBTUxMSUJdKQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9j
YW1sb3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MT1BUXSxbb2NhbWxvcHRdLFtub10pCisg
ICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVu
CisJQUNfTVNHX1dBUk4oW0Nhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlv
biBvbmx5Ll0pCisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4g
LWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZFUlNJT04i
ICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMg
ZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLl0pCisJICAgIE9DQU1MT1BU
PW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9b3B0CisJZmkKKyAgICAgZmkKKworICAgICBBQ19T
VUJTVChbT0NBTUxCRVNUXSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0CisgICAg
IEFDX0NIRUNLX1RPT0woW09DQU1MQ0RPVE9QVF0sW29jYW1sYy5vcHRdLFtub10pCisgICAgIGlm
IHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxD
RE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlm
IHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01T
R19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2Fy
ZGVkLl0pCisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisK
KyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9Q
VCIgIT0gIm5vIiA7IHRoZW4KKwlBQ19DSEVDS19UT09MKFtPQ0FNTE9QVERPVE9QVF0sW29jYW1s
b3B0Lm9wdF0sW25vXSkKKwlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4K
KwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJz
aW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NB
TUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9uIGRpZmZlcnMg
ZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuXSkKKwkgICBlbHNlCisJICAgICAg
T0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAgZmkKKwor
ICAgICBBQ19TVUJTVChbT0NBTUxPUFRdKQorICBmaQorCisgIEFDX1NVQlNUKFtPQ0FNTENdKQor
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisgIEFDX0NIRUNLX1RPT0woW09DQU1M
XSxbb2NhbWxdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKKyAgQUNfQ0hFQ0tf
VE9PTChbT0NBTUxERVBdLFtvY2FtbGRlcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2Ft
bG1rdG9wCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtUT1BdLFtvY2FtbG1rdG9wXSxbbm9dKQor
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxNS0xJ
Ql0sW29jYW1sbWtsaWJdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxET0NdLFtvY2FtbGRvY10sW25vXSkKKworICAjIGNoZWNraW5nIGZv
ciBvY2FtbGJ1aWxkCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQlVJTERdLFtvY2FtbGJ1aWxkXSxb
bm9dKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTExFWF0sCitbZG5sCisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sbGV4CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYXSxbb2NhbWxsZXhd
LFtub10pCisgIGlmIHRlc3QgIiRPQ0FNTExFWCIgIT0gIm5vIjsgdGhlbgorICAgIEFDX0NIRUNL
X1RPT0woW09DQU1MTEVYRE9UT1BUXSxbb2NhbWxsZXgub3B0XSxbbm9dKQorICAgIGlmIHRlc3Qg
IiRPQ0FNTExFWERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCU9DQU1MTEVYPSRPQ0FNTExFWERPVE9Q
VAorICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtPQ0FNTExFWF0pCitdKQorCitBQ19ERUZVTihb
QUNfUFJPR19PQ0FNTFlBQ0NdLAorW2RubAorICBBQ19DSEVDS19UT09MKFtPQ0FNTFlBQ0NdLFtv
Y2FtbHlhY2NdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTFlBQ0NdKQorXSkKKworCitBQ19ERUZV
TihbQUNfUFJPR19DQU1MUDRdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlk
bmwKKworICAjIGNoZWNraW5nIGZvciBjYW1scDQKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0XSxb
Y2FtbHA0XSxbbm9dKQorICBpZiB0ZXN0ICIkQ0FNTFA0IiAhPSAibm8iOyB0aGVuCisgICAgIFRN
UFZFUlNJT049YCRDQU1MUDQgLXYgMj4mMXwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiAqXCguKlwp
JHxcMXxwJ2AKKyAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7
IHRoZW4KKwlBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjXSkKKyAg
ICAgICAgQ0FNTFA0PW5vCisgICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtDQU1MUDRdKQorCisg
ICMgY2hlY2tpbmcgZm9yIGNvbXBhbmlvbiB0b29scworICBBQ19DSEVDS19UT09MKFtDQU1MUDRC
T09UXSxbY2FtbHA0Ym9vdF0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T10sW2NhbWxw
NG9dLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9GXSxbY2FtbHA0b2ZdLFtub10pCisg
IEFDX0NIRUNLX1RPT0woW0NBTUxQNE9PRl0sW2NhbWxwNG9vZl0sW25vXSkKKyAgQUNfQ0hFQ0tf
VE9PTChbQ0FNTFA0T1JGXSxbY2FtbHA0b3JmXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1M
UDRQUk9GXSxbY2FtbHA0cHJvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Ul0sW2Nh
bWxwNHJdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJGXSxbY2FtbHA0cmZdLFtub10p
CisgIEFDX1NVQlNUKFtDQU1MUDRCT09UXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9dKQorICBBQ19T
VUJTVChbQ0FNTFA0T0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0T09GXSkKKyAgQUNfU1VCU1QoW0NB
TUxQNE9SRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRQUk9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJd
KQorICBBQ19TVUJTVChbQ0FNTFA0UkZdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19GSU5E
TElCXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVj
a2luZyBmb3Igb2NhbWxmaW5kCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRklORF0sW29jYW1sZmlu
ZF0sW25vXSkKKyAgQUNfU1VCU1QoW09DQU1MRklORF0pCitdKQorCisKK2RubCBUaGFua3MgdG8g
SmltIE1leWVyaW5nIGZvciB3b3JraW5nIHRoaXMgbmV4dCBiaXQgb3V0IGZvciB1cy4KK2RubCBY
WFggV2Ugc2hvdWxkIGRlZmluZSBBU19UUl9TSCBpZiBpdCdzIG5vdCBkZWZpbmVkIGFscmVhZHkK
K2RubCAoZWcuIGZvciBvbGQgYXV0b2NvbmYpLgorQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1BL
R10sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfRklORExJQl0pZG5sCisKKyAgQUNfTVNH
X0NIRUNLSU5HKFtmb3IgT0NhbWwgZmluZGxpYiBwYWNrYWdlICQxXSkKKworICB1bnNldCBmb3Vu
ZAorICB1bnNldCBwa2cKKyAgZm91bmQ9bm8KKyAgZm9yIHBrZyBpbiAkMSAkMiA7IGRvCisgICAg
aWYgJE9DQU1MRklORCBxdWVyeSAkcGtnID4vZGV2L251bGwgMj4vZGV2L251bGw7IHRoZW4KKyAg
ICAgIEFDX01TR19SRVNVTFQoW2ZvdW5kXSkKKyAgICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFd
KT0kcGtnCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAgZG9uZQorICBp
ZiB0ZXN0ICIkZm91bmQiID0gIm5vIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91
bmRdKQorICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT1ubworICBmaQorCisgIEFDX1NVQlNU
KEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKSkKK10pCisKKworQUNfREVGVU4oW0FDX0NIRUNLX09D
QU1MX01PRFVMRV0sCitbZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIG1vZHVsZSAk
Ml0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKK29wZW4gJDMKK0VPRgorICB1bnNldCBm
b3VuZAorICBmb3IgJDEgaW4gJCQxICQ0IDsgZG8KKyAgICBpZiAkT0NBTUxDIC1jIC1JICIkJDEi
IGNvbmZ0ZXN0Lm1sID4mNSAyPiY1IDsgdGhlbgorICAgICAgZm91bmQ9eWVzCisgICAgICBicmVh
aworICAgIGZpCisgIGRvbmUKKworICBpZiB0ZXN0ICIkZm91bmQiIDsgdGhlbgorICAgIEFDX01T
R19SRVNVTFQoWyQkMV0pCisgIGVsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQor
ICAgICQxPW5vCisgIGZpCisgIEFDX1NVQlNUKFskMV0pCitdKQorCisKK2RubCBYWFggQ3Jvc3Mt
Y29tcGlsaW5nCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfV09SRF9TSVpFXSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9D
YW1sIGNvbXBpbGVyIHdvcmQgc2l6ZV0pCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCisgIHBy
aW50X2VuZGxpbmUgKHN0cmluZ19vZl9pbnQgU3lzLndvcmRfc2l6ZSkKKyAgRU9GCisgIE9DQU1M
X1dPUkRfU0laRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFskT0NBTUxf
V09SRF9TSVpFXSkKKyAgQUNfU1VCU1QoW09DQU1MX1dPUkRfU0laRV0pCitdKQorCitBQ19ERUZV
TihbQUNfQ0hFQ0tfT0NBTUxfT1NfVFlQRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0df
T0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW09DYW1sIFN5cy5vc190eXBlXSkKKworICBj
YXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9zdHJpbmcoU3lzLm9zX3R5cGUpOzsKK0VP
RgorCisgIE9DQU1MX09TX1RZUEU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VM
VChbJE9DQU1MX09TX1RZUEVdKQorICBBQ19TVUJTVChbT0NBTUxfT1NfVFlQRV0pCitdKQpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvcGF0aF9vcl9mYWlsLm00
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L200L3BhdGhfb3JfZmFpbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAs
MCArMSw2IEBACitBQ19ERUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FDX1BBVEhfUFJP
RyhbJDFdLCBbJDJdLCBbbm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAKK3RoZW4KKyAg
ICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFsbCAkMl0pCitm
aV0pCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9tNC9weXRob25f
ZGV2ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIvdG9vbHMvbTQvcHl0aG9uX2RldmVsLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEw
MApAQCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBv
cnQgb3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0
cyhwICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0
KDEpCisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAg
ICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFj
a2FnZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRp
ZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB0b29scy9tNC9weXRob25fdmVyc2lv
bi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9weXRob25fdmVyc2lvbi5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAK
QEAgLTAsMCArMSwxMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04g
LWMgJ2ltcG9ydCBzeXM7IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikp
J2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhP
TiAtViAyPiYxYAorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisg
ICAgICAgIFskcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJz
aW9uIGlzICQxLiQyXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZm
IC1yIDViMjY3NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvcHl0aG9uX3htbC5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC9weXRob25feG1sLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsx
LDEwIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5H
KFtmb3IgcHl0aG9uIHhtbC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5k
b20ubWluaWRvbSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VM
VChbbm9dKQorICAgIEFDX01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9t
IG1vZHVsZV0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciA1
YjI2NzZhYzEzMjEgLXIgNmZkZTAxN2M0MTllIHRvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5t
NAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29s
cy9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMjAgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBjZmxhZyBp
biAkUFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIK
K2RvbmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRfTERGTEFH
Uys9IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURFUworZG8K
KyAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkQVBQ
RU5EX0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitDRkxB
R1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFHUz0iJFBS
RVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1yIDViMjY3
NmFjMTMyMSAtciA2ZmRlMDE3YzQxOWUgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00CVR1ZSBK
YW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZVTihbQVhf
Q0hFQ0tfVURFVl0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4K
KyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVz
dCB4IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9H
KFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJ
TkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAor
ICAgICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVh
c2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5G
T30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7
VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVz
dCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQ
TFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0g
eCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRv
byBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAg
ZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkK
KyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBB
Q19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkK
KyAgICBmaQorZmkKK10pCmRpZmYgLXIgNWIyNjc2YWMxMzIxIC1yIDZmZGUwMTdjNDE5ZSB2ZXJz
aW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3ZlcnNpb24uc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNCBA
QAorIyEvYmluL3NoCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9OIiAkMSB8IHNlZCAn
cy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBYRU5fU1VCVkVSU0lP
TiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAiJWQuJWQiICRNQUpP
UiAkTUlOT1IKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBl-0002gx-4n; Wed, 01 Feb 2012 10:13:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <socketpair@gmail.com>) id 1Rpzxy-0000fp-T1
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:20:35 +0000
X-Env-Sender: socketpair@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327486827!3546200!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6466 invoked from network); 25 Jan 2012 10:20:27 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:20:27 -0000
Received: by bkar1 with SMTP id r1so4650163bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 02:20:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=6Yldi9pJCqnA16LRqmqVS95fHF4Y+iCxbDent+mQaAg=;
	b=Fu6WAg69ugMAK3XDHGUQePkWi/e3HQ6HcV6kA/gculXjvWaJwZXKcs5PNpyJYIrcng
	het3sxqvKdw9GJ5H/ZUSQGPc/OClCN/7twUX84/Pt4QwTrD1faMiKwOcrlgwi/yN45cC
	DIZjzAYIbA3UBKQT5HybP3qL2inAnXDw0Pkm0=
MIME-Version: 1.0
Received: by 10.205.26.67 with SMTP id rl3mr6785576bkb.45.1327486826718; Wed,
	25 Jan 2012 02:20:26 -0800 (PST)
Received: by 10.204.61.78 with HTTP; Wed, 25 Jan 2012 02:20:26 -0800 (PST)
In-Reply-To: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
Date: Wed, 25 Jan 2012 16:20:26 +0600
Message-ID: <CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
From: =?UTF-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?= <socketpair@gmail.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] Fwd: BUG in
	linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

First, maintainer's addresses (Ryan Wilson <hap9@epoch.ncsc.mil>,
Chris Bookholt <hap10@epoch.ncsc.mil>) are wrong (users unknown to
remote mailsystem), so posting to you:

PCI bus format strings are wrong.

"%04x:%02x:%02x.%d"

should be used instead of

"%04x:%02x:%02x.%1x"

(in many places of linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c)

-- 
Segmentation fault

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBl-0002gx-4n; Wed, 01 Feb 2012 10:13:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <socketpair@gmail.com>) id 1Rpzxy-0000fp-T1
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:20:35 +0000
X-Env-Sender: socketpair@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327486827!3546200!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6466 invoked from network); 25 Jan 2012 10:20:27 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:20:27 -0000
Received: by bkar1 with SMTP id r1so4650163bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 02:20:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=6Yldi9pJCqnA16LRqmqVS95fHF4Y+iCxbDent+mQaAg=;
	b=Fu6WAg69ugMAK3XDHGUQePkWi/e3HQ6HcV6kA/gculXjvWaJwZXKcs5PNpyJYIrcng
	het3sxqvKdw9GJ5H/ZUSQGPc/OClCN/7twUX84/Pt4QwTrD1faMiKwOcrlgwi/yN45cC
	DIZjzAYIbA3UBKQT5HybP3qL2inAnXDw0Pkm0=
MIME-Version: 1.0
Received: by 10.205.26.67 with SMTP id rl3mr6785576bkb.45.1327486826718; Wed,
	25 Jan 2012 02:20:26 -0800 (PST)
Received: by 10.204.61.78 with HTTP; Wed, 25 Jan 2012 02:20:26 -0800 (PST)
In-Reply-To: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
Date: Wed, 25 Jan 2012 16:20:26 +0600
Message-ID: <CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
From: =?UTF-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?= <socketpair@gmail.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] Fwd: BUG in
	linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

First, maintainer's addresses (Ryan Wilson <hap9@epoch.ncsc.mil>,
Chris Bookholt <hap10@epoch.ncsc.mil>) are wrong (users unknown to
remote mailsystem), so posting to you:

PCI bus format strings are wrong.

"%04x:%02x:%02x.%d"

should be used instead of

"%04x:%02x:%02x.%1x"

(in many places of linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c)

-- 
Segmentation fault

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBm-0002hP-0y; Wed, 01 Feb 2012 10:13:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rq5sc-0002kY-7f
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:39:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327509555!10210531!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20926 invoked from network); 25 Jan 2012 16:39:20 -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; 25 Jan 2012 16:39:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q0PGcI5E004686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 16:38:19 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
	q0PGcDZl000666
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 16:38:14 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PGcAlN020235; Wed, 25 Jan 2012 10:38:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 08:38:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30D9D401A1; Wed, 25 Jan 2012 11:35:52 -0500 (EST)
Date: Wed, 25 Jan 2012 11:35:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120125163552.GB23999@phenom.dumpdata.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F1FC370.5020506@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1FC370.5020506@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F202FFC.0123,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 02:25:12PM +0530, Raghavendra K T wrote:
> On 01/18/2012 12:06 AM, Raghavendra K T wrote:
> >On 01/17/2012 11:09 PM, Alexander Graf wrote:
> [...]
> >>>>>A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>B. pre-3.2.0 + Jeremy's above patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>C. pre-3.2.0 + Jeremy's above patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = y
> >>>>>D. pre-3.2.0 + Jeremy's above patches + V5 patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>E. pre-3.2.0 + Jeremy's above patches + V5 patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = y
> [...]
> >>Maybe it'd be a good idea to create a small in-kernel microbenchmark
> >>with a couple threads that take spinlocks, then do work for a
> >>specified number of cycles, then release them again and start anew. At
> >>the end of it, we can check how long the whole thing took for n runs.
> >>That would enable us to measure the worst case scenario.
> >>
> >
> >It was a quick test. two iteration of kernbench (=6runs) and had ensured
> >cache is cleared.
> >
> >echo "1" > /proc/sys/vm/drop_caches
> >ccache -C. Yes may be I can run test as you mentioned..
> >
> 
> Sorry for late reply. Was trying to do more performance analysis.
> Measured the worst case scenario with a spinlock stress driver
> [ attached below ]. I think S1 (below) is what you were
> looking for:
> 
> 2 types of scenarios:
> S1.
> lock()
> increment counter.
> unlock()
> 
> S2:
> do_somework()
> lock()
> do_conditional_work() /* this is to give variable spinlock hold time */
> unlock()
> 
> Setup:
> Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
> core , 64GB RAM, 16 online cpus.
> The below results are taken across total 18 Runs of
> insmod spinlock_thread.ko nr_spinlock_threads=4 loop_count=4000000
> 
> Results:
> scenario S1: plain counter
> ==========================
>     total Mega cycles taken for completion (std)
> A.  12343.833333      (1254.664021)
> B.  12817.111111      (917.791606)
> C.  13426.555556      (844.882978)
> 
> %improvement w.r.t BASE     -8.77
> 
> scenario S2: counter with variable work inside lock + do_work_outside_lock
> =========================================================================
> A.   25077.888889      (1349.471703)
> B.   24906.777778      (1447.853874)
> C.   21287.000000      (2731.643644)
> 
> %improvement w.r.t BASE      15.12
> 
> So it seems we have worst case overhead of around 8%. But we see
> improvement of at-least 15% once when little more time is spent in
> critical section.

Is this with collecting the histogram information about spinlocks? We found
that if you enable that for production runs it makes them quite slower.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBm-0002hP-0y; Wed, 01 Feb 2012 10:13:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rq5sc-0002kY-7f
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:39:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327509555!10210531!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20926 invoked from network); 25 Jan 2012 16:39:20 -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; 25 Jan 2012 16:39:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q0PGcI5E004686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 16:38:19 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
	q0PGcDZl000666
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 16:38:14 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PGcAlN020235; Wed, 25 Jan 2012 10:38:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 08:38:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30D9D401A1; Wed, 25 Jan 2012 11:35:52 -0500 (EST)
Date: Wed, 25 Jan 2012 11:35:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120125163552.GB23999@phenom.dumpdata.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F1FC370.5020506@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1FC370.5020506@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F202FFC.0123,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 02:25:12PM +0530, Raghavendra K T wrote:
> On 01/18/2012 12:06 AM, Raghavendra K T wrote:
> >On 01/17/2012 11:09 PM, Alexander Graf wrote:
> [...]
> >>>>>A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>B. pre-3.2.0 + Jeremy's above patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>C. pre-3.2.0 + Jeremy's above patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = y
> >>>>>D. pre-3.2.0 + Jeremy's above patches + V5 patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>E. pre-3.2.0 + Jeremy's above patches + V5 patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = y
> [...]
> >>Maybe it'd be a good idea to create a small in-kernel microbenchmark
> >>with a couple threads that take spinlocks, then do work for a
> >>specified number of cycles, then release them again and start anew. At
> >>the end of it, we can check how long the whole thing took for n runs.
> >>That would enable us to measure the worst case scenario.
> >>
> >
> >It was a quick test. two iteration of kernbench (=6runs) and had ensured
> >cache is cleared.
> >
> >echo "1" > /proc/sys/vm/drop_caches
> >ccache -C. Yes may be I can run test as you mentioned..
> >
> 
> Sorry for late reply. Was trying to do more performance analysis.
> Measured the worst case scenario with a spinlock stress driver
> [ attached below ]. I think S1 (below) is what you were
> looking for:
> 
> 2 types of scenarios:
> S1.
> lock()
> increment counter.
> unlock()
> 
> S2:
> do_somework()
> lock()
> do_conditional_work() /* this is to give variable spinlock hold time */
> unlock()
> 
> Setup:
> Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
> core , 64GB RAM, 16 online cpus.
> The below results are taken across total 18 Runs of
> insmod spinlock_thread.ko nr_spinlock_threads=4 loop_count=4000000
> 
> Results:
> scenario S1: plain counter
> ==========================
>     total Mega cycles taken for completion (std)
> A.  12343.833333      (1254.664021)
> B.  12817.111111      (917.791606)
> C.  13426.555556      (844.882978)
> 
> %improvement w.r.t BASE     -8.77
> 
> scenario S2: counter with variable work inside lock + do_work_outside_lock
> =========================================================================
> A.   25077.888889      (1349.471703)
> B.   24906.777778      (1447.853874)
> C.   21287.000000      (2731.643644)
> 
> %improvement w.r.t BASE      15.12
> 
> So it seems we have worst case overhead of around 8%. But we see
> improvement of at-least 15% once when little more time is spent in
> critical section.

Is this with collecting the histogram information about spinlocks? We found
that if you enable that for production runs it makes them quite slower.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBn-0002i7-8P; Wed, 01 Feb 2012 10:13:19 +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 1Rq8CR-0002zf-Hq
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:08:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327518439!57450112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7539 invoked from network); 25 Jan 2012 19:07:21 -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; 25 Jan 2012 19:07:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q0PJ7bNL003548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 19:07:38 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
	q0PJ7ZOi029681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 19:07:35 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
	q0PJ7VJl028545; Wed, 25 Jan 2012 13:07:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 11:07:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 24EB0401A3; Wed, 25 Jan 2012 14:05:13 -0500 (EST)
Date: Wed, 25 Jan 2012 14:05:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120125190513.GD18606@phenom.dumpdata.com>
References: <20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F1FC370.5020506@linux.vnet.ibm.com>
	<20120125163552.GB23999@phenom.dumpdata.com>
	<4F203FC0.70907@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F203FC0.70907@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F2052FC.00AB,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 11:15:36PM +0530, Raghavendra K T wrote:
> On 01/25/2012 10:05 PM, Konrad Rzeszutek Wilk wrote:
> >>So it seems we have worst case overhead of around 8%. But we see
> >>improvement of at-least 15% once when little more time is spent in
> >>critical section.
> >
> >Is this with collecting the histogram information about spinlocks? We found
> >that if you enable that for production runs it makes them quite slower.
> >
> 
> Ok. Are you referring to CONFIG_KVM_DEBUG_FS/CONFIG_XEN_DEBUG_FS?. Not

Those were the ones.

> it was not enabled. But then may be I was not precise. This test was
> only on native. So it should have not affected IMO.

Yup.
> 
> It is nice to know that histogram affects, since I was always under the
> impression that it does not affect much on guest too. My experiments
> had almost always enabled that.
> 
> Let me know if you referred to something else..

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBo-0002ip-0S; Wed, 01 Feb 2012 10:13:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RqMyH-0005wN-6l; Thu, 26 Jan 2012 10:54:25 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327575258!12588006!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31575 invoked from network); 26 Jan 2012 10:54:18 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 10:54:18 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0QAqLCb009661;
	Thu, 26 Jan 2012 12:52:22 +0200
Message-ID: <6AFC4F8E7F6E45EBAB673D8BDCC8328F@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Doug Magee" <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
Date: Thu, 26 Jan 2012 12:53:07 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 ??>> I say that ATI produces the same effect. I do not see anything until
 ??>> the
 ??>> welcome screen and only when gfx_passthru = 0. If gfx_passthru = 1 -
 ??>> qemu
 ??>> shell on vnc console and freezed domU :(

 DM> You won't be able to passthrough an ATI card with the BIOS for multiple
 DM> reasons.  First, the ati bios keeps a copy of the pci config space, so
 DM> certain values need to be modified for it to work properly with the
 DM> guest addresses.  The most recent experimental patch for this was from
 DM> december 2010:
 DM> http://lists.xen.org/archives/html/xen-devel/2010-12/msg00705.html
 DM> I can confirmm i had limited success with this.


 DM> However, this patch was based on xen-unstable before the 4.1-rc's came
 DM> out.  You can try building an older version of xen (in that thread, i
 DM> mentioned the specific C/S i used in testing) and applying the patch or
 DM> forward porting the patch to the current xen/qemu-xen.

In fact of the matter is that it tested an older version of Xen, and I read 
about this in the beginning of its work with Xen (although there was a 
version 4.0.1rc3.) Out of my last comment^ 4.1.2 works more stable than 
4.0.2 4.0.1rc3
And how to roll the old patch to newer versions of xen?

 DM> Also, i believe you said the card you're trying to pass through is not
 DM> the primary card in your host system.  If that's the case, don't use
 DM> gfx_passthru or expect to get the video bios working.  The 'primary'
 DM> video adapter owns certain io ports and memory areas that are consitent
 DM> from machine to machine.  Also, the system will copy the vbios from the
 DM> card to a location in memory (0xc0000) so it can execute at boot time.

 DM> Xen's gfx_passthru code depends on all of these factors.  As the code
 DM> stands, if you use gfx_passthru on a secondary card, it will still copy
 DM> the vbios from the primary card (as it simply reads memory from
 DM> 0xc0000), and directly map io ports and low memory areas to those used
 DM> by the primary card in the host system.  In this case the guest will
 DM> almost certainly never get past executing ROMBIOS, and the host may or
 DM> may not lock up or experience 'issues'.

I use both. When the primary adapter is the one on which you want to run 
gfx_passthru - there remains the possibility to control the system through 
the console, not ssh. There is the following question: if I have a primary 
device that the video card, you want to passing, I need to do it pciback and 
add config DomU pci = ['02: 00.0 '], where '02: 00.0' - is the primary 
graphics card or no???



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBn-0002i7-8P; Wed, 01 Feb 2012 10:13:19 +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 1Rq8CR-0002zf-Hq
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:08:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327518439!57450112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7539 invoked from network); 25 Jan 2012 19:07:21 -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; 25 Jan 2012 19:07:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q0PJ7bNL003548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 19:07:38 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
	q0PJ7ZOi029681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 19:07:35 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
	q0PJ7VJl028545; Wed, 25 Jan 2012 13:07:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 11:07:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 24EB0401A3; Wed, 25 Jan 2012 14:05:13 -0500 (EST)
Date: Wed, 25 Jan 2012 14:05:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120125190513.GD18606@phenom.dumpdata.com>
References: <20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F1FC370.5020506@linux.vnet.ibm.com>
	<20120125163552.GB23999@phenom.dumpdata.com>
	<4F203FC0.70907@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F203FC0.70907@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F2052FC.00AB,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 11:15:36PM +0530, Raghavendra K T wrote:
> On 01/25/2012 10:05 PM, Konrad Rzeszutek Wilk wrote:
> >>So it seems we have worst case overhead of around 8%. But we see
> >>improvement of at-least 15% once when little more time is spent in
> >>critical section.
> >
> >Is this with collecting the histogram information about spinlocks? We found
> >that if you enable that for production runs it makes them quite slower.
> >
> 
> Ok. Are you referring to CONFIG_KVM_DEBUG_FS/CONFIG_XEN_DEBUG_FS?. Not

Those were the ones.

> it was not enabled. But then may be I was not precise. This test was
> only on native. So it should have not affected IMO.

Yup.
> 
> It is nice to know that histogram affects, since I was always under the
> impression that it does not affect much on guest too. My experiments
> had almost always enabled that.
> 
> Let me know if you referred to something else..

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBo-0002ip-0S; Wed, 01 Feb 2012 10:13:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RqMyH-0005wN-6l; Thu, 26 Jan 2012 10:54:25 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327575258!12588006!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31575 invoked from network); 26 Jan 2012 10:54:18 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 10:54:18 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0QAqLCb009661;
	Thu, 26 Jan 2012 12:52:22 +0200
Message-ID: <6AFC4F8E7F6E45EBAB673D8BDCC8328F@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Doug Magee" <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
Date: Thu, 26 Jan 2012 12:53:07 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 ??>> I say that ATI produces the same effect. I do not see anything until
 ??>> the
 ??>> welcome screen and only when gfx_passthru = 0. If gfx_passthru = 1 -
 ??>> qemu
 ??>> shell on vnc console and freezed domU :(

 DM> You won't be able to passthrough an ATI card with the BIOS for multiple
 DM> reasons.  First, the ati bios keeps a copy of the pci config space, so
 DM> certain values need to be modified for it to work properly with the
 DM> guest addresses.  The most recent experimental patch for this was from
 DM> december 2010:
 DM> http://lists.xen.org/archives/html/xen-devel/2010-12/msg00705.html
 DM> I can confirmm i had limited success with this.


 DM> However, this patch was based on xen-unstable before the 4.1-rc's came
 DM> out.  You can try building an older version of xen (in that thread, i
 DM> mentioned the specific C/S i used in testing) and applying the patch or
 DM> forward porting the patch to the current xen/qemu-xen.

In fact of the matter is that it tested an older version of Xen, and I read 
about this in the beginning of its work with Xen (although there was a 
version 4.0.1rc3.) Out of my last comment^ 4.1.2 works more stable than 
4.0.2 4.0.1rc3
And how to roll the old patch to newer versions of xen?

 DM> Also, i believe you said the card you're trying to pass through is not
 DM> the primary card in your host system.  If that's the case, don't use
 DM> gfx_passthru or expect to get the video bios working.  The 'primary'
 DM> video adapter owns certain io ports and memory areas that are consitent
 DM> from machine to machine.  Also, the system will copy the vbios from the
 DM> card to a location in memory (0xc0000) so it can execute at boot time.

 DM> Xen's gfx_passthru code depends on all of these factors.  As the code
 DM> stands, if you use gfx_passthru on a secondary card, it will still copy
 DM> the vbios from the primary card (as it simply reads memory from
 DM> 0xc0000), and directly map io ports and low memory areas to those used
 DM> by the primary card in the host system.  In this case the guest will
 DM> almost certainly never get past executing ROMBIOS, and the host may or
 DM> may not lock up or experience 'issues'.

I use both. When the primary adapter is the one on which you want to run 
gfx_passthru - there remains the possibility to control the system through 
the console, not ssh. There is the following question: if I have a primary 
device that the video card, you want to passing, I need to do it pciback and 
add config DomU pci = ['02: 00.0 '], where '02: 00.0' - is the primary 
graphics card or no???



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBo-0002jO-OY; Wed, 01 Feb 2012 10:13:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RqO4K-0000rB-JB
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:04:44 +0000
Received: from [85.158.139.83:47757] by server-4.bemta-5.messagelabs.com id
	43/59-09697-B51412F4; Thu, 26 Jan 2012 12:04:43 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327579482!5147920!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gOTM5MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6531 invoked from network); 26 Jan 2012 12:04:43 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 12:04:43 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RqO4I-0002es-BJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:04:42 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Thu, 26 Jan 2012
	12:04:02 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 12:04:02 +0000
Thread-Topic: xc_gnttab_get_version question/bug
Thread-Index: AQHM3CKXcTpsM1b+sE2R4c1rcYR6Pg==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everyon,

I am new to Xen Development, so I don't know if it is a bug or my lack of knowledge regarding Xen dev.

I am running Fedora 16 x86-64 XFCE with the latest xen unstable and when I run the following code the machine reboots.

#include <xenctrl.h>


int main(int argc, char **argv)
{
        xc_interface *xch;
        xch = xc_interface_open(NULL, NULL, 0);

        printf("version: %d\n", xc_gnttab_get_version(xch, 1));

        xc_interface_close(xch);

        return 0;
}

Can anyone help? Thank you for your time.

Cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBo-0002jO-OY; Wed, 01 Feb 2012 10:13:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RqO4K-0000rB-JB
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:04:44 +0000
Received: from [85.158.139.83:47757] by server-4.bemta-5.messagelabs.com id
	43/59-09697-B51412F4; Thu, 26 Jan 2012 12:04:43 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327579482!5147920!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gOTM5MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6531 invoked from network); 26 Jan 2012 12:04:43 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 12:04:43 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RqO4I-0002es-BJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:04:42 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Thu, 26 Jan 2012
	12:04:02 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 12:04:02 +0000
Thread-Topic: xc_gnttab_get_version question/bug
Thread-Index: AQHM3CKXcTpsM1b+sE2R4c1rcYR6Pg==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everyon,

I am new to Xen Development, so I don't know if it is a bug or my lack of knowledge regarding Xen dev.

I am running Fedora 16 x86-64 XFCE with the latest xen unstable and when I run the following code the machine reboots.

#include <xenctrl.h>


int main(int argc, char **argv)
{
        xc_interface *xch;
        xch = xc_interface_open(NULL, NULL, 0);

        printf("version: %d\n", xc_gnttab_get_version(xch, 1));

        xc_interface_close(xch);

        return 0;
}

Can anyone help? Thank you for your time.

Cheers,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBq-0002ke-1Y; Wed, 01 Feb 2012 10:13:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <segfaultreloaded@gmail.com>) id 1RqPB2-0004VC-4i
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:15:44 +0000
Received: from [85.158.139.83:2047] by server-4.bemta-5.messagelabs.com id
	04/30-09697-8F1512F4; Thu, 26 Jan 2012 13:15:36 +0000
X-Env-Sender: segfaultreloaded@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327583732!12415804!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2324 invoked from network); 26 Jan 2012 13:15:33 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-7.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 13:15:33 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0QDFT0N004242
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:15:29 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0QDFTql025354
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:15:29 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012608152914716
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 08:15:29 -0500
From: John McDermott <segfaultreloaded@gmail.com>
Date: Thu, 26 Jan 2012 08:15:29 -0500
Message-Id: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen Developers,

FYI, in 4.1-testing, tools/libxl/xl_cmdimpl.c, in function main_cpupoollist, the variable opt_long is set but not used. Tools won't make with this warning.

Sincerely,

John
----
What is the formal meaning of the one-line program
#include "/dev/tty"


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBq-0002ke-1Y; Wed, 01 Feb 2012 10:13:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <segfaultreloaded@gmail.com>) id 1RqPB2-0004VC-4i
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:15:44 +0000
Received: from [85.158.139.83:2047] by server-4.bemta-5.messagelabs.com id
	04/30-09697-8F1512F4; Thu, 26 Jan 2012 13:15:36 +0000
X-Env-Sender: segfaultreloaded@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327583732!12415804!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2324 invoked from network); 26 Jan 2012 13:15:33 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-7.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 13:15:33 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0QDFT0N004242
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:15:29 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0QDFTql025354
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:15:29 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012608152914716
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 08:15:29 -0500
From: John McDermott <segfaultreloaded@gmail.com>
Date: Thu, 26 Jan 2012 08:15:29 -0500
Message-Id: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen Developers,

FYI, in 4.1-testing, tools/libxl/xl_cmdimpl.c, in function main_cpupoollist, the variable opt_long is set but not used. Tools won't make with this warning.

Sincerely,

John
----
What is the formal meaning of the one-line program
#include "/dev/tty"


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBr-0002lK-Gn; Wed, 01 Feb 2012 10:13:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RqQSp-0007Y4-Cc; Thu, 26 Jan 2012 14:38:11 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327588684!8743190!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.1 required=7.0 tests=FORGED_MUA_OUTLOOK,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13549 invoked from network); 26 Jan 2012 14:38:04 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 14:38:04 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0QEa6ex016968;
	Thu, 26 Jan 2012 16:36:06 +0200
Message-ID: <B46B5ECD433A44BEA1850616AAB769BB@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Florian Heigl" <florian.heigl@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
	<alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
Date: Thu, 26 Jan 2012 16:36:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
	passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1297620558873011989=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1297620558873011989==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_018D_01CCDC48.B538B410"

This is a multi-part message in MIME format.

------=_NextPart_000_018D_01CCDC48.B538B410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I propose the following innovations in xl (or xen). Namely domu and dom0 =
to equate the rights of control xen
Example in grub.cfg on debian:
multiboot       /boot/xen-4.1.2.gz placeholder iommu=3D1 msi=3D1 =
dom0_mem=3D512M xl_ip=3D10.0.0.1 xl_port=3D8888 =
xl_access=3D10.0.0.0/8,190.12.12.231(external ip )[any list ip coma =
separated]
------=_NextPart_000_018D_01CCDC48.B538B410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=3D2 face=3DArial>I propose the following innovations in =
xl (or xen).=20
Namely domu and dom0 to equate </FONT><FONT size=3D2 face=3DArial>the =
rights of=20
control xen</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>Example in grub.cfg on =
debian:</FONT></DIV>
<DIV><FONT size=3D2 =
face=3DArial>multiboot&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
/boot/xen-4.1.2.gz placeholder iommu=3D1 msi=3D1 dom0_mem=3D512M =
</FONT><FONT size=3D2=20
face=3DArial>xl_ip=3D10.0.0.1 xl_port=3D8888=20
xl_access=3D10.0.0.0/8,190.12.12.231(external ip )[any list ip coma=20
separated]</FONT></DIV></BODY></HTML>

------=_NextPart_000_018D_01CCDC48.B538B410--



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

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

--===============1297620558873011989==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBr-0002lK-Gn; Wed, 01 Feb 2012 10:13:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RqQSp-0007Y4-Cc; Thu, 26 Jan 2012 14:38:11 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327588684!8743190!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.1 required=7.0 tests=FORGED_MUA_OUTLOOK,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13549 invoked from network); 26 Jan 2012 14:38:04 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 14:38:04 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0QEa6ex016968;
	Thu, 26 Jan 2012 16:36:06 +0200
Message-ID: <B46B5ECD433A44BEA1850616AAB769BB@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Florian Heigl" <florian.heigl@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
	<alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
Date: Thu, 26 Jan 2012 16:36:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
	passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1297620558873011989=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1297620558873011989==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_018D_01CCDC48.B538B410"

This is a multi-part message in MIME format.

------=_NextPart_000_018D_01CCDC48.B538B410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I propose the following innovations in xl (or xen). Namely domu and dom0 =
to equate the rights of control xen
Example in grub.cfg on debian:
multiboot       /boot/xen-4.1.2.gz placeholder iommu=3D1 msi=3D1 =
dom0_mem=3D512M xl_ip=3D10.0.0.1 xl_port=3D8888 =
xl_access=3D10.0.0.0/8,190.12.12.231(external ip )[any list ip coma =
separated]
------=_NextPart_000_018D_01CCDC48.B538B410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=3D2 face=3DArial>I propose the following innovations in =
xl (or xen).=20
Namely domu and dom0 to equate </FONT><FONT size=3D2 face=3DArial>the =
rights of=20
control xen</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>Example in grub.cfg on =
debian:</FONT></DIV>
<DIV><FONT size=3D2 =
face=3DArial>multiboot&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
/boot/xen-4.1.2.gz placeholder iommu=3D1 msi=3D1 dom0_mem=3D512M =
</FONT><FONT size=3D2=20
face=3DArial>xl_ip=3D10.0.0.1 xl_port=3D8888=20
xl_access=3D10.0.0.0/8,190.12.12.231(external ip )[any list ip coma=20
separated]</FONT></DIV></BODY></HTML>

------=_NextPart_000_018D_01CCDC48.B538B410--



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

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

--===============1297620558873011989==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBs-0002lp-AE; Wed, 01 Feb 2012 10:13:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>) id 1RqRCQ-0000yO-0g
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:25:18 +0000
Received: from [85.158.138.51:2443] by server-9.bemta-3.messagelabs.com id
	ED/2C-31168-D50712F4; Thu, 26 Jan 2012 15:25:17 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327591506!10788110!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7294 invoked from network); 26 Jan 2012 15:25:06 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 15:25:06 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0QERQtZ016766;
	Thu, 26 Jan 2012 16:27:26 +0200
Message-ID: <C638113DD94547BF9334FA4A0BE50E9C@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Doug Magee" <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
Date: Thu, 26 Jan 2012 16:28:11 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I propose the following innovations in xl. Namely domu and dom0 to equate 
the rights of control xen
Example in grub.cfg:
multiboot       /boot/xen-4.1.2.gz placeholder iommu=1 msi=1 dom0_mem=512M 
xl_ip=10.0.0.1 xl_port=8888 xl_access=10.0.0.0/8,190.12.12.231 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBs-0002lp-AE; Wed, 01 Feb 2012 10:13:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>) id 1RqRCQ-0000yO-0g
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:25:18 +0000
Received: from [85.158.138.51:2443] by server-9.bemta-3.messagelabs.com id
	ED/2C-31168-D50712F4; Thu, 26 Jan 2012 15:25:17 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327591506!10788110!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7294 invoked from network); 26 Jan 2012 15:25:06 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 15:25:06 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0QERQtZ016766;
	Thu, 26 Jan 2012 16:27:26 +0200
Message-ID: <C638113DD94547BF9334FA4A0BE50E9C@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Doug Magee" <djmagee@mageenet.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
Date: Thu, 26 Jan 2012 16:28:11 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I propose the following innovations in xl. Namely domu and dom0 to equate 
the rights of control xen
Example in grub.cfg:
multiboot       /boot/xen-4.1.2.gz placeholder iommu=1 msi=1 dom0_mem=512M 
xl_ip=10.0.0.1 xl_port=8888 xl_access=10.0.0.0/8,190.12.12.231 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBt-0002ml-NT; Wed, 01 Feb 2012 10:13:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Leonid.Kalev@ca.com>) id 1RqSo9-00005z-Sn
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:08:22 +0000
X-Env-Sender: Leonid.Kalev@ca.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327597690!3791187!1
X-Originating-IP: [74.125.149.149]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27268 invoked from network); 26 Jan 2012 17:08:12 -0000
Received: from na3sys009aog123.obsmtp.com (HELO na3sys009aog123.obsmtp.com)
	(74.125.149.149)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 17:08:12 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob123.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTyGIeZ7PlfGkFgzMmEeWOzhch6wByKnX@postini.com;
	Thu, 26 Jan 2012 09:08:12 PST
Received: from USILMS174.ca.com (141.202.6.24) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Thu, 26 Jan 2012 12:08:08 -0500
Received: from USILMS111A.ca.com ([169.254.3.121]) by usilms174.ca.com
	([141.202.6.24]) with mapi id 14.01.0355.002;
	Thu, 26 Jan 2012 12:08:08 -0500
From: "Kalev, Leonid" <Leonid.Kalev@ca.com>
To: xen-devel <xen-devel@lists.xensource.com>
Thread-Topic: Help needed debugging "EPT Misconfiguration" exception on
	Intel CPU
Thread-Index: AQHM3E0SU3wUxrG6pEq0yWH/vYcRvQ==
Date: Thu, 26 Jan 2012 17:08:07 +0000
Message-ID: <4F218876.8090606@ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24)
	Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
x-originating-ip: [81.218.169.161]
Content-Type: multipart/mixed; boundary="_002_4F2188768090606cacom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] Help needed debugging "EPT Misconfiguration" exception
	on Intel CPU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_4F2188768090606cacom_
Content-Type: text/plain; charset="utf-8"
Content-ID: <677AA049BF78EE438FE88BCBCBB47015@ca.com>
Content-Transfer-Encoding: base64

KG5vdGUsIHBsZWFzZSBzZW5kIGEgY29weSBvZiByZXBsaWVzIHRvIG15IGUtbWFpbCwgSSBhbSBu
b3Qgc3Vic2NyaWJlZCB0byB0aGUgDQp4ZW4tZGV2ZWwgbGlzdCkNCg0KQmVmb3JlIEkgZ2V0IGlu
dG8gZGV0YWlscyBhYm91dCB0aGUgcHJvYmxlbTogSSB0cmllZCB0byBpZGVudGlmeSB0aGUgQ1BV
IGFzIHByZWNpc2VseSANCmFzIHBvc3NpYmxlIChpbiBjYXNlIHRoZXJlIGFyZSBrbm93biBwcm9i
bGVtcyB3aXRoIHRoZSBzcGVjaWZpYyBtb2RlbCksIGJ1dCB3aGF0IEkgDQpmb3VuZCBpbiB0aGUg
Q1BVIGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIChhcyByZXBvcnRlZCBieSB0aGUgJ2NwdWlk
JyBpbnN0cnVjdGlvbikgDQpzZWVtcyBzdHJhbmdlOiB1bmxpa2UgbW9zdCBJbnRlbCBDUFVzIHRo
YXQgcmVwb3J0IGEgc2Vuc2libGUgbW9kZWwgbmFtZSwgd2hpY2ggDQpnZW5lcmFsbHkgbWF0Y2hl
cyB0aGUgY29tbWVyY2lhbCBuYW1lIG9mIHRoZSBDUFUsIChlLmcuICJJbnRlbChSKSBDb3JlKFRN
KSBpNSBDUFUiKSwgDQpvbiB0aGUgc2VydmVyIHdoZXJlIEkgY2F1Z2h0IHRoZSBFUFQgZXhjZXB0
aW9uLCB0aGUgQ1BVIG1vZGVsIHN0cmluZyByZWFkczoNCiJHZW51aW5lIEludGVsKFIpIENQVSAg
ICAgICAgICAgQCAwMDAwIEAgMi40MEdIeiINCg0KVGhpcyBkb2VzIG5vdCBsb29rIGxpa2UgYW55
IENQVSB0aGF0IEludGVsIHNlbGxzLiBUaGUgZmFtaWx5LCBtb2RlbCBhbmQgc3RlcHBpbmcgDQpu
dW1iZXJzIGFyZSA2IDI2IGFuZCAyLCByZXNwZWN0aXZlbHkuIEkgZGlkIG5vdCBmaW5kIGFueSBy
ZWZlcmVuY2UgdG8gdGhpcyBwYXJ0aWN1bGFyIA0KY29tYmluYXRpb24gb2YgbW9kZWwgSUQgbnVt
YmVycywgZXhjZXB0IGluIGp1c3Qgb25lIG9yIHR3byBmb3J1bSBwb3N0cyBvbiB0aGUgV2ViLCAN
CnJlZmVycmluZyB0byB0aGUgc2FtZSBub24tZGVzY3JpcHQgbW9kZWwgc3RyaW5nIHF1b3RlZCBh
Ym92ZS4gT25lIG9mIHRoZSBwb3N0cyBldmVuIA0Kc3VnZ2VzdGVkIHRoYXQgdGhpcyBtaWdodCBi
ZSBhIG5vbi1wcm9kdWN0aW9uIENQVSBjaGlwOiANCmh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlz
dHMva3ZtL21zZzU4MjU4Lmh0bWwNCg0KTm93LCB0byB0aGUgcHJvYmxlbSBpdHNlbGY6DQphdHRl
bXB0aW5nIHRvIHN0YXJ0IGEgaGFyZHdhcmUtYXNzaXN0ZWQgdmlydHVhbCBtYWNoaW5lIChIVk0p
IG9uIFhFTiA0LjEuMSBjYXVzZXMgdGhlIA0KZ3Vlc3QgVk0gdG8gY3Jhc2ggaW5zdGFudGx5IG9u
IHN0YXJ0dXAuIFRoZSBjcmFzaCBpcyBjYXVzZWQgYnkgYSBWTSBleGl0IHRoYXQgaXMgbm90IA0K
aGFuZGxlZCBieSBYRU4gKGFuZCB3aGljaCBjYW5ub3QgYmUgaGFuZGxlZCBpbiBhbnkgd2F5IG90
aGVyIHRoYW4gZGVzdHJveWluZyB0aGUgDQpndWVzdCBWTSk6IHRoZSBWTSBleGl0IHJlYXNvbiBp
cyA0OSAoMHgzMSksIHdoaWNoIGlzICJFUFQgTWlzY29uZmlndXJhdGlvbiIuDQoNCkFjY29yZGlu
ZyB0byB0aGUgSW50ZWwgU29mdHdhcmUgRGV2ZWxvcGVyIE1hbnVhbCAoVm9sIDNCLCBDaGFwdGVy
IDI1IC0gVk1YIFNVUFBPUlQgDQpGT1IgQUREUkVTUyBUUkFOU0xBVElPTiksIHRoaXMgVk0gZXhp
dCBtZWFucyB0aGF0IGFuIGludmFsaWQgdmFsdWUgd2FzIGZvdW5kIGluIHRoZSANCmV4dGVuZGVk
IHBhZ2UgdGFibGVzLiBTdXNwZWN0aW5nIGEgc29mdHdhcmUgcHJvYmxlbSwgSSBtb2RpZmllZCB0
aGUgWEVOIGh5cGVydmlzb3IgdG8gDQpwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYXMg
Zm9sbG93czoNCi0gcmVhZCBhbmQgZGlzcGxheSB0aGUgdmFsdWUgb2YgdGhlIEVQVFAgVk0gY29u
dHJvbCBmaWVsZA0KLSByZWFkIGFuZCBkaXNwbGF5IHRoZSB2YWx1ZSBvZiB0aGUgIkd1ZXN0LXBo
eXNpY2FsIGFkZHJlc3MiIGNvbnRyb2wgZmllbGQgKEdQQSkNCi0gdXNlIHRoZSBndWVzdC1waHlz
aWNhbCBhZGRyZXNzIHZhbHVlIHRvIHRyYXZlcnNlIHRoZSBFUFQgc3RydWN0dXJlcyBhbmQgZGlz
cGxheQ0KICAgIGFsbCA0IGxldmVscyBvZiBwYWdlIHRhYmxlIGVudHJpZXMgdGhhdCBwZXJ0YWlu
IHRvIHRoZSBHUEEgcmVwb3J0ZWQgYnkgdGhlIENQVS4NCg0KSSB3YXMgbm90IGFibGUgdG8gZmlu
ZCBhbnkgZXJyb3IgaW4gdGhlIEVQVFAgdmFsdWUsIG5vciBpbiB0aGUgRVBUIHRhYmxlIGVudHJp
ZXMsIA0KdGhleSBhbGwgc2VlbSB0byBiZSB2YWxpZC4gQmVsb3csIEkgYW0gaW5jbHVkaW5nOg0K
LSB0aGUgZGVidWcgaW5mb3JtYXRpb24gZGlzcGxheWVkIGJ5IFhFTiAod2l0aCB0aGUgYWRkaXRp
b25hbCBpbnN0cnVtZW50YXRpb24NCiAgICB0aGF0IEkgYWRkZWQpLCB3aXRoIHNvbWUgYml0LWZp
ZWxkIGFuYWx5c2lzIHRoYXQgSSBkaWQgbWFudWFsbHkgKHNob3dpbmcgbm8NCiAgICBwcm9ibGVt
cyBpbiB0aGUgRVBUIGVudHJpZXMpDQotIHRoZSBDUFUgaW5mb3JtYXRpb24gKHhtIGluZm8gYW5k
IC9wcm9jL2NwdWluZm8pDQotIG1lbW9yeSBtYXAgZnJvbSBCSU9TDQoNCkFsc28sIHRoZSBkZXRh
aWxlZCBETUkgaW5mbyBmcm9tIEJJT1MgaXMgYXR0YWNoZWQgYXMgYSB0ZXh0IGZpbGUgKGl0IGRv
ZXNuJ3Qgc2hvdyANCmFueXRoaW5nIGRpZmZlcmVudCBhYm91dCB0aGUgQ1BVLCB0aG91Z2gpLg0K
DQo9PT09PT09PT09PT09IFhFTiBjb25zb2xlIGxvZywgd2l0aCBjb21tZW50cyBmcm9tIG1lID09
PT09PT09PT09PT09PT09PT09PT09PT09DQooWEVOKSBFUFQgTWlzY29uZmlndXJhdGlvbiwgZ3Bh
PTAwMDAwMDAwZmVmZmUwMDANCihYRU4pIGRvbWFpbi0+Li4uLT5lcHRwICAgPSAweDQzMWIzZDAx
ZQ0KKFhFTikgdm1yZWFkKEVQVF9QT0lOVEVSKSA9IDB4NDMxYjNkMDFlDQoNCiAgICBFUFRQIGJp
dHM6DQogICAgMC0yICAgPSA2OyBtZW0gdHlwZSAoMCA9IFVDLCA2PVdCLCBhbGwgb3RoZXIgPSBp
bnZhbGlkKQ0KICAgIDUtMyAgID0gMyAoc2hvdWxkIGJlID0gMyAod2FsayBsZW5ndGggLSAxKSkN
CiAgICA2LTExICA9IDAgcmVzZXJ2ZWQNCiAgICAxMi0zOSA9IDB4NDMxYjNkOyBhZGRyIG9mIEVQ
VCBQTUw0DQogICAgNDAtNjQgPSAwIDsgcmVzZXJ2ZWQgKDQwIGlzIHRoZSBhZGRyIHN6IG9mIHRo
ZSBDUFUgaGVyZSwgbWF5IHZhcnkgb24gb3RoZXIgQ1BVcywgDQptYXg9NDgpDQoNCihYRU4pIHAy
bS1lcHQuYzo2NDk6ZDMgV2Fsa2luZyBFUFQgdGFibGVzIGZvciBkb21haW4gMyBnZm4gZmVmZmUN
CihYRU4pIHAybS1lcHQuYzo2Njg6ZDMgIGVwdGUgMWMwMDAwMDQzMWIzYzAwNw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC0yID0gNzogYWNjZXNzIGFs
bG93ZWQ6IHJ3eA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMy03ID0gMDogcmVzZXJ2ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIDgtMTEgPSAw
OiBpZ25vcmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4LTEyID0gNDMxYjNjOiBhZGRyZXNzIG9mIG5leHQgbGV2ZWwgRVBUDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICA1MS14IC0gMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgNTItNjMg
LSBpZ25vcmVkDQooWEVOKSBwMm0tZXB0LmM6NjY4OmQzICBlcHRlIDFjMDAwMDA0Mzc0ZmIwMDcN
CihYRU4pIHAybS1lcHQuYzo2Njg6ZDMgIGVwdGUgMWMwMDAwMDQzNzRmYTAwNw0KKFhFTikgcDJt
LWVwdC5jOjY2ODpkMyAgZXB0ZSAxYzEwMDAwYzIxM2VlMDM3IDAtMiA9IDc6IHJ3eA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTAwMDAwMDAwMDAgKG5iOiBhZGRyIHNpemUg
bGltaXQgLSA0MCBiaXRzIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHRoaXMgQ1BVLCB3ZSdyZSB3YXkgYmVsb3cpDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzLTUgPSA2OiB0eXBlICgwID0gVUM7IDEg
PSBXQzsgNCA9IFdUOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgNSA9IFdQOyA2ID0gV0IpDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICA2ICAgPSAwOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgNy0xMSA9MDogKGlnbm9yZWQp
DQogICAgICAgICAgICAgICAgICAgICAgICAgICBtZm49YzIxM2VlLCAobG9va3MgdmFsaWQsIG1l
bSBleHRlbmRzIGZyb20gMTAwMDAwIHRvIA0KYzQwMDAwLCBzZWUgbWVtIG1hcCBiZWxvdykNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDUyPTE7ICA1Mi02MyBzaG91bGQgYmUgaWdub3JlZA0K
DQooWEVOKSBkb21haW5fY3Jhc2ggY2FsbGVkIGZyb20gdm14LmM6MjY1MA0KKFhFTikgRG9tYWlu
IDMgKHZjcHUjMCkgY3Jhc2hlZCBvbiBjcHUjMTU6DQooWEVOKSAtLS0tWyBYZW4tNC4xLjEgIHg4
Nl82NCAgZGVidWc9biAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIENQVTogICAgMTUNCihYRU4p
IFJJUDogICAgMDAwMDpbPDAwMDAwMDAwMDAwMDAwMDA+XQ0KKFhFTikgUkZMQUdTOiAwMDAwMDAw
MDAwMDEwMDAyICAgQ09OVEVYVDogaHZtIGd1ZXN0DQooWEVOKSByYXg6IDAwMDAwMDAwMDAwMDAw
MDEgICByYng6IDAwMDAwMDAwMDAwMDAwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4p
IHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJzaTogMDAwMDAwMDAwMDAwMDAwMCAgIHJkaTogMDAw
MDAwMDAwMDAwMDAwMA0KKFhFTikgcmJwOiAwMDAwMDAwMDAwMDAwMDAwICAgcnNwOiAwMDAwMDAw
MDAwMDAwMDAwICAgcjg6ICAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSByOTogIDAwMDAwMDAwMDAw
MDAwMDAgICByMTA6IDAwMDAwMDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAwMDAwMDANCihY
RU4pIHIxMjogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDog
MDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAwMDAw
MDAwMDAwMDAwMDExICAgY3I0OiAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBjcjM6IDAwMDAwMDAw
MDAwMDAwMDAgICBjcjI6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIGRzOiAwMDAwICAgZXM6IDAw
MDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAgICBjczogMDAwMA0KDQogICAgICBD
UjAgPSAweDEwID0gUEUrRVQNCiAgICAgIFJGTEFHUyA9IFJGICsgMiAoMiBpcyBhbHdheXMgc2V0
KQ0KDQo9PT09PT09PT09PT09IHN5c3RlbSBpbmZvIGZyb20gWEVOID09PT09PT09PT09PT09PT09
PT09PT09PT09PT0NCiMgeG0gaW5mbw0KaG9zdCAgICAgICAgICAgICAgICAgICA6IDN0ZXJhLXNy
djENCnJlbGVhc2UgICAgICAgICAgICAgICAgOiAzLjAuNC00MC54ZW4wDQp2ZXJzaW9uICAgICAg
ICAgICAgICAgIDogIzEgU01QIFdlZCBEZWMgMTQgMTk6NDg6MDMgRVNUIDIwMTENCm1hY2hpbmUg
ICAgICAgICAgICAgICAgOiBpNjg2DQpucl9jcHVzICAgICAgICAgICAgICAgIDogMTYNCm5yX25v
ZGVzICAgICAgICAgICAgICAgOiAyDQpjb3Jlc19wZXJfc29ja2V0ICAgICAgIDogNA0KdGhyZWFk
c19wZXJfY29yZSAgICAgICA6IDINCmNwdV9taHogICAgICAgICAgICAgICAgOiAyNDAwDQpod19j
YXBzICAgICAgICAgICAgICAgIDogDQpiZmViZmJmZjoyODEwMDgwMDowMDAwMDAwMDowMDAwM2I0
MDowMGJjZTNiZDowMDAwMDAwMDowMDAwMDAwMTowMDAwMDAwMA0KdmlydF9jYXBzICAgICAgICAg
ICAgICA6IGh2bQ0KdG90YWxfbWVtb3J5ICAgICAgICAgICA6IDQ5MTQyDQpmcmVlX21lbW9yeSAg
ICAgICAgICAgIDogNDc0ODcNCmZyZWVfY3B1cyAgICAgICAgICAgICAgOiAwDQp4ZW5fbWFqb3Ig
ICAgICAgICAgICAgIDogNA0KeGVuX21pbm9yICAgICAgICAgICAgICA6IDENCnhlbl9leHRyYSAg
ICAgICAgICAgICAgOiAuMQ0KeGVuX2NhcHMgICAgICAgICAgICAgICA6IHhlbi0zLjAteDg2XzY0
IHhlbi0zLjAteDg2XzMycCBodm0tMy4wLXg4Nl8zMiANCmh2bS0zLjAteDg2XzMycCBodm0tMy4w
LXg4Nl82NA0KeGVuX3NjaGVkdWxlciAgICAgICAgICA6IGNyZWRpdA0KeGVuX3BhZ2VzaXplICAg
ICAgICAgICA6IDQwOTYNCnBsYXRmb3JtX3BhcmFtcyAgICAgICAgOiB2aXJ0X3N0YXJ0PTB4ZmNj
MDAwMDANCnhlbl9jaGFuZ2VzZXQgICAgICAgICAgOiB1bmF2YWlsYWJsZQ0KeGVuX2NvbW1hbmRs
aW5lICAgICAgICA6IG5vaHQgaW9tbXU9b2ZmIGRvbTBfdmNwdXNfcGluIGRvbTBfbWF4X3ZjcHVz
PTEgZG9tMF9tZW09Nzg2NDMyDQpjY19jb21waWxlciAgICAgICAgICAgIDogZ2NjIHZlcnNpb24g
NC4xLjEgMjAwNzAxMDUgKFJlZCBIYXQgNC4xLjEtNTIpDQpjY19jb21waWxlX2J5ICAgICAgICAg
IDogM3RlcmENCmNjX2NvbXBpbGVfZG9tYWluICAgICAgOiAobm9uZSkNCmNjX2NvbXBpbGVfZGF0
ZSAgICAgICAgOiBNb24gSmFuIDIzIDA2OjExOjQ3IFBTVCAyMDEyDQp4ZW5kX2NvbmZpZ19mb3Jt
YXQgICAgIDogNA0KDQo9PT09PT09PT09PT09IENQVSBpbmZvICgvcHJvYy9jcHVpbmZvLCBmcm9t
IERvbTAgLSBmbGFncyBhcmUgZmlsdGVyZWQgYnkgWEVOKQ0KIyBjYXQgL3Byb2MvY3B1aW5mbw0K
cHJvY2Vzc29yICAgIDogMA0KdmVuZG9yX2lkICAgIDogR2VudWluZUludGVsDQpjcHUgZmFtaWx5
ICAgIDogNg0KbW9kZWwgICAgICAgIDogMjYNCm1vZGVsIG5hbWUgICAgOiBHZW51aW5lIEludGVs
KFIpIENQVSAgICAgICAgICAgQCAwMDAwIEAgMi40MEdIeg0Kc3RlcHBpbmcgICAgOiAyDQpjcHUg
TUh6ICAgICAgICA6IDI0MDAuMTEyDQpjYWNoZSBzaXplICAgIDogODE5MiBLQg0KcGh5c2ljYWwg
aWQgICAgOiAwDQpzaWJsaW5ncyAgICA6IDENCmNvcmUgaWQgICAgICAgIDogMA0KY3B1IGNvcmVz
ICAgIDogMQ0KYXBpY2lkICAgICAgICA6IDANCmluaXRpYWwgYXBpY2lkICAgIDogMA0KZmRpdl9i
dWcgICAgOiBubw0KaGx0X2J1ZyAgICAgICAgOiBubw0KZjAwZl9idWcgICAgOiBubw0KY29tYV9i
dWcgICAgOiBubw0KZnB1ICAgICAgICA6IHllcw0KZnB1X2V4Y2VwdGlvbiAgICA6IHllcw0KY3B1
aWQgbGV2ZWwgICAgOiAxMQ0Kd3AgICAgICAgIDogeWVzDQpmbGFncyAgICAgICAgOiBmcHUgZGUg
dHNjIG1zciBwYWUgY3g4IGFwaWMgc2VwIGNtb3YgcGF0IGNsZmx1c2ggYWNwaSBtbXggZnhzciBz
c2UgDQpzc2UyIHNzIGh0IG54IGxtIGNvbnN0YW50X3RzYyB1cCBub25zdG9wX3RzYyBhcGVyZm1w
ZXJmIHBuaSBlc3Qgc3NzZTMgc3NlNF8xIHNzZTRfMiANCngyYXBpYyBwb3BjbnQgaHlwZXJ2aXNv
ciBpZGEgZHRzDQpib2dvbWlwcyAgICA6IDQ4MDAuMjINCmNsZmx1c2ggc2l6ZSAgICA6IDY0DQpj
YWNoZV9hbGlnbm1lbnQgICAgOiA2NA0KYWRkcmVzcyBzaXplcyAgICA6IDQwIGJpdHMgcGh5c2lj
YWwsIDQ4IGJpdHMgdmlydHVhbA0KcG93ZXIgbWFuYWdlbWVudDoNCg0KPT09PT09PT09PT09PSBC
SU9TIG1lbW9yeSBtYXAsIGFzIHNob3duIGJ5IFhFTiBvbiBib290ID09PT09PT09PT09PT09PT09
PT09PT09PT09DQooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAw
MDAgLSAwMDAwMDAwMDAwMDljYzAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5Y2MwMCAt
IDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTYwMDAgLSAw
MDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDBiZjc2MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYmY3NmUwMDAgLSAwMDAwMDAw
MGJmNzcwMDAwIHR5cGUgOQ0KKFhFTikgIDAwMDAwMDAwYmY3NzAwMDAgLSAwMDAwMDAwMGJmNzdl
MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBiZjc3ZTAwMCAtIDAwMDAwMDAwYmY3ZDAw
MDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYmY3ZDAwMDAgLSAwMDAwMDAwMGJmN2UwMDAw
IChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGJmN2VjMDAwIC0gMDAwMDAwMDBjMDAwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgKHJl
c2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNl
cnZlZCkNCihYRU4pICAwMDAwMDAwMGZmYzAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2
ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDBjNDAwMDAwMDAgKHVzYWJsZSkN
Cg0KLS0gDQpMZW9uaWQgS2FsZXYNCkNBIFRlY2hub2xvZ2llcw0KUHJpbmNpcGFsIFNvZnR3YXJl
IEVuZ2luZWVyDQpUZWw6ICAgICArOTcyIDQgODI1IDM5NTINCk1vYmlsZTogICs5NzIgNTQgNDYz
MTUwOA0KTGVvbmlkLkthbGV2QGNhLmNvbQ0KDQoNCmRtaWRlY29kZS1lcHRmYWlsDQoNCiMgZG1p
ZGVjb2RlIDIuMTANClNNQklPUyAyLjYgcHJlc2VudC4NCjQ0IHN0cnVjdHVyZXMgb2NjdXB5aW5n
IDI1NDkgYnl0ZXMuDQpUYWJsZSBhdCAweDAwMDlFQzAwLg0KDQpIYW5kbGUgMHgwMDAwLCBETUkg
dHlwZSAwLCAyNCBieXRlcw0KQklPUyBJbmZvcm1hdGlvbg0KCVZlbmRvcjogQW1lcmljYW4gTWVn
YXRyZW5kcyBJbmMuDQoJVmVyc2lvbjogMDgwMDE2DQoJUmVsZWFzZSBEYXRlOiAwMi8xMS8yMDEx
DQoJQWRkcmVzczogMHhGMDAwMA0KCVJ1bnRpbWUgU2l6ZTogNjQga0INCglST00gU2l6ZTogNDA5
NiBrQg0KCUNoYXJhY3RlcmlzdGljczoNCgkJSVNBIGlzIHN1cHBvcnRlZA0KCQlQQ0kgaXMgc3Vw
cG9ydGVkDQoJCVBOUCBpcyBzdXBwb3J0ZWQNCgkJQklPUyBpcyB1cGdyYWRlYWJsZQ0KCQlCSU9T
IHNoYWRvd2luZyBpcyBhbGxvd2VkDQoJCUVTQ0Qgc3VwcG9ydCBpcyBhdmFpbGFibGUNCgkJQm9v
dCBmcm9tIENEIGlzIHN1cHBvcnRlZA0KCQlTZWxlY3RhYmxlIGJvb3QgaXMgc3VwcG9ydGVkDQoJ
CUJJT1MgUk9NIGlzIHNvY2tldGVkDQoJCUVERCBpcyBzdXBwb3J0ZWQNCgkJNS4yNSIvMS4yIE1C
IGZsb3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQ0KCQkzLjUiLzcyMCBrQiBm
bG9wcHkgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEzaCkNCgkJMy41Ii8yLjg4IE1CIGZs
b3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQ0KCQlQcmludCBzY3JlZW4gc2Vy
dmljZSBpcyBzdXBwb3J0ZWQgKGludCA1aCkNCgkJODA0MiBrZXlib2FyZCBzZXJ2aWNlcyBhcmUg
c3VwcG9ydGVkIChpbnQgOWgpDQoJCVNlcmlhbCBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQg
MTRoKQ0KCQlQcmludGVyIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAxN2gpDQoJCUNHQS9t
b25vIHZpZGVvIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAxMGgpDQoJCUFDUEkgaXMgc3Vw
cG9ydGVkDQoJCVVTQiBsZWdhY3kgaXMgc3VwcG9ydGVkDQoJCUxTLTEyMCBib290IGlzIHN1cHBv
cnRlZA0KCQlBVEFQSSBaaXAgZHJpdmUgYm9vdCBpcyBzdXBwb3J0ZWQNCgkJQklPUyBib290IHNw
ZWNpZmljYXRpb24gaXMgc3VwcG9ydGVkDQoJCVRhcmdldGVkIGNvbnRlbnQgZGlzdHJpYnV0aW9u
IGlzIHN1cHBvcnRlZA0KCUJJT1MgUmV2aXNpb246IDguMTYNCg0KSGFuZGxlIDB4MDAwMSwgRE1J
IHR5cGUgMSwgMjcgYnl0ZXMNClN5c3RlbSBJbmZvcm1hdGlvbg0KCU1hbnVmYWN0dXJlcjogU3Vw
ZXJtaWNybw0KCVByb2R1Y3QgTmFtZTogWDhEVFQtSA0KCVZlcnNpb246IDEyMzQ1Njc4OTANCglT
ZXJpYWwgTnVtYmVyOiAxMjM0NTY3ODkwDQoJVVVJRDogNTQ0NDM4NTgtNEU1NC0zMDAwLTQ4RjQt
MDAzMDQ4RjQxNzcwDQoJV2FrZS11cCBUeXBlOiBQb3dlciBTd2l0Y2gNCglTS1UgTnVtYmVyOiAx
MjM0NTY3ODkwDQoJRmFtaWx5OiBTZXJ2ZXINCg0KSGFuZGxlIDB4MDAwMiwgRE1JIHR5cGUgMiwg
MTUgYnl0ZXMNCkJhc2UgQm9hcmQgSW5mb3JtYXRpb24NCglNYW51ZmFjdHVyZXI6IFN1cGVybWlj
cm8NCglQcm9kdWN0IE5hbWU6IFg4RFRULUgNCglWZXJzaW9uOiAxLjMNCglTZXJpYWwgTnVtYmVy
OiAxMjM0NTY3ODkwDQoJQXNzZXQgVGFnOiAxMjM0NTY3ODkwDQoJRmVhdHVyZXM6DQoJCUJvYXJk
IGlzIGEgaG9zdGluZyBib2FyZA0KCQlCb2FyZCBpcyByZXBsYWNlYWJsZQ0KCUxvY2F0aW9uIElu
IENoYXNzaXM6IDEyMzQ1Njc4OTANCglDaGFzc2lzIEhhbmRsZTogMHgwMDAzDQoJVHlwZTogTW90
aGVyYm9hcmQNCglDb250YWluZWQgT2JqZWN0IEhhbmRsZXM6IDANCg0KSGFuZGxlIDB4MDAwMywg
RE1JIHR5cGUgMywgMjEgYnl0ZXMNCkNoYXNzaXMgSW5mb3JtYXRpb24NCglNYW51ZmFjdHVyZXI6
IFN1cGVybWljcm8NCglUeXBlOiBNYWluIFNlcnZlciBDaGFzc2lzDQoJTG9jazogTm90IFByZXNl
bnQNCglWZXJzaW9uOiAxMjM0NTY3ODkwDQoJU2VyaWFsIE51bWJlcjogMTIzNDU2Nzg5MC4NCglB
c3NldCBUYWc6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglCb290LXVwIFN0YXRlOiBTYWZlDQoJ
UG93ZXIgU3VwcGx5IFN0YXRlOiBTYWZlDQoJVGhlcm1hbCBTdGF0ZTogU2FmZQ0KCVNlY3VyaXR5
IFN0YXR1czogTm9uZQ0KCU9FTSBJbmZvcm1hdGlvbjogMHgwMDAwMDAwMA0KCUhlaWdodDogVW5z
cGVjaWZpZWQNCglOdW1iZXIgT2YgUG93ZXIgQ29yZHM6IDENCglDb250YWluZWQgRWxlbWVudHM6
IDANCg0KSGFuZGxlIDB4MDAwNCwgRE1JIHR5cGUgNCwgNDIgYnl0ZXMNClByb2Nlc3NvciBJbmZv
cm1hdGlvbg0KCVNvY2tldCBEZXNpZ25hdGlvbjogQ1BVIDENCglUeXBlOiBDZW50cmFsIFByb2Nl
c3Nvcg0KCUZhbWlseTogWGVvbg0KCU1hbnVmYWN0dXJlcjogSW50ZWwNCglJRDogQTIgMDYgMDEg
MDAgRkYgRkIgRUIgQkYNCglTaWduYXR1cmU6IFR5cGUgMCwgRmFtaWx5IDYsIE1vZGVsIDI2LCBT
dGVwcGluZyAyDQoJRmxhZ3M6DQoJCUZQVSAoRmxvYXRpbmctcG9pbnQgdW5pdCBvbi1jaGlwKQ0K
CQlWTUUgKFZpcnR1YWwgbW9kZSBleHRlbnNpb24pDQoJCURFIChEZWJ1Z2dpbmcgZXh0ZW5zaW9u
KQ0KCQlQU0UgKFBhZ2Ugc2l6ZSBleHRlbnNpb24pDQoJCVRTQyAoVGltZSBzdGFtcCBjb3VudGVy
KQ0KCQlNU1IgKE1vZGVsIHNwZWNpZmljIHJlZ2lzdGVycykNCgkJUEFFIChQaHlzaWNhbCBhZGRy
ZXNzIGV4dGVuc2lvbikNCgkJTUNFIChNYWNoaW5lIGNoZWNrIGV4Y2VwdGlvbikNCgkJQ1g4IChD
TVBYQ0hHOCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpDQoJCUFQSUMgKE9uLWNoaXAgQVBJQyBoYXJk
d2FyZSBzdXBwb3J0ZWQpDQoJCVNFUCAoRmFzdCBzeXN0ZW0gY2FsbCkNCgkJTVRSUiAoTWVtb3J5
IHR5cGUgcmFuZ2UgcmVnaXN0ZXJzKQ0KCQlQR0UgKFBhZ2UgZ2xvYmFsIGVuYWJsZSkNCgkJTUNB
IChNYWNoaW5lIGNoZWNrIGFyY2hpdGVjdHVyZSkNCgkJQ01PViAoQ29uZGl0aW9uYWwgbW92ZSBp
bnN0cnVjdGlvbiBzdXBwb3J0ZWQpDQoJCVBBVCAoUGFnZSBhdHRyaWJ1dGUgdGFibGUpDQoJCVBT
RS0zNiAoMzYtYml0IHBhZ2Ugc2l6ZSBleHRlbnNpb24pDQoJCUNMRlNIIChDTEZMVVNIIGluc3Ry
dWN0aW9uIHN1cHBvcnRlZCkNCgkJRFMgKERlYnVnIHN0b3JlKQ0KCQlBQ1BJIChBQ1BJIHN1cHBv
cnRlZCkNCgkJTU1YIChNTVggdGVjaG5vbG9neSBzdXBwb3J0ZWQpDQoJCUZYU1IgKEZhc3QgZmxv
YXRpbmctcG9pbnQgc2F2ZSBhbmQgcmVzdG9yZSkNCgkJU1NFIChTdHJlYW1pbmcgU0lNRCBleHRl
bnNpb25zKQ0KCQlTU0UyIChTdHJlYW1pbmcgU0lNRCBleHRlbnNpb25zIDIpDQoJCVNTIChTZWxm
LXNub29wKQ0KCQlIVFQgKEh5cGVyLXRocmVhZGluZyB0ZWNobm9sb2d5KQ0KCQlUTSAoVGhlcm1h
bCBtb25pdG9yIHN1cHBvcnRlZCkNCgkJUEJFIChQZW5kaW5nIGJyZWFrIGVuYWJsZWQpDQoJVmVy
c2lvbjogR2VudWluZSBJbnRlbChSKSBDUFUgICAgICAgICAgIEAgMDAwMCBAIDIuNDBHSHoNCglW
b2x0YWdlOiBVbmtub3duDQoJRXh0ZXJuYWwgQ2xvY2s6IDEzMyBNSHoNCglNYXggU3BlZWQ6IDI0
MDAgTUh6DQoJQ3VycmVudCBTcGVlZDogMjQwMCBNSHoNCglTdGF0dXM6IFBvcHVsYXRlZCwgRW5h
YmxlZA0KCVVwZ3JhZGU6IE90aGVyDQoJTDEgQ2FjaGUgSGFuZGxlOiAweDAwMDUNCglMMiBDYWNo
ZSBIYW5kbGU6IDB4MDAwNg0KCUwzIENhY2hlIEhhbmRsZTogMHgwMDA3DQoJU2VyaWFsIE51bWJl
cjogVG8gQmUgRmlsbGVkIEJ5IE8uRS5NLg0KCUFzc2V0IFRhZzogVG8gQmUgRmlsbGVkIEJ5IE8u
RS5NLg0KCVBhcnQgTnVtYmVyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uDQoJQ29yZSBDb3VudDog
NA0KCUNvcmUgRW5hYmxlZDogNA0KCVRocmVhZCBDb3VudDogOA0KCUNoYXJhY3RlcmlzdGljczoN
CgkJNjQtYml0IGNhcGFibGUNCg0KSGFuZGxlIDB4MDAwNSwgRE1JIHR5cGUgNywgMTkgYnl0ZXMN
CkNhY2hlIEluZm9ybWF0aW9uDQoJU29ja2V0IERlc2lnbmF0aW9uOiBMMS1DYWNoZQ0KCUNvbmZp
Z3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMQ0KCU9wZXJhdGlvbmFsIE1v
ZGU6IFdyaXRlIFRocm91Z2gNCglMb2NhdGlvbjogSW50ZXJuYWwNCglJbnN0YWxsZWQgU2l6ZTog
MjU2IGtCDQoJTWF4aW11bSBTaXplOiAyNTYga0INCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoNCgkJ
T3RoZXINCglJbnN0YWxsZWQgU1JBTSBUeXBlOiBPdGhlcg0KCVNwZWVkOiBVbmtub3duDQoJRXJy
b3IgQ29ycmVjdGlvbiBUeXBlOiBQYXJpdHkNCglTeXN0ZW0gVHlwZTogSW5zdHJ1Y3Rpb24NCglB
c3NvY2lhdGl2aXR5OiA0LXdheSBTZXQtYXNzb2NpYXRpdmUNCg0KSGFuZGxlIDB4MDAwNiwgRE1J
IHR5cGUgNywgMTkgYnl0ZXMNCkNhY2hlIEluZm9ybWF0aW9uDQoJU29ja2V0IERlc2lnbmF0aW9u
OiBMMi1DYWNoZQ0KCUNvbmZpZ3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwg
Mg0KCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIFRocm91Z2gNCglMb2NhdGlvbjogSW50ZXJuYWwN
CglJbnN0YWxsZWQgU2l6ZTogMTAyNCBrQg0KCU1heGltdW0gU2l6ZTogMTAyNCBrQg0KCVN1cHBv
cnRlZCBTUkFNIFR5cGVzOg0KCQlPdGhlcg0KCUluc3RhbGxlZCBTUkFNIFR5cGU6IE90aGVyDQoJ
U3BlZWQ6IFVua25vd24NCglFcnJvciBDb3JyZWN0aW9uIFR5cGU6IFNpbmdsZS1iaXQgRUNDDQoJ
U3lzdGVtIFR5cGU6IFVuaWZpZWQNCglBc3NvY2lhdGl2aXR5OiA4LXdheSBTZXQtYXNzb2NpYXRp
dmUNCg0KSGFuZGxlIDB4MDAwNywgRE1JIHR5cGUgNywgMTkgYnl0ZXMNCkNhY2hlIEluZm9ybWF0
aW9uDQoJU29ja2V0IERlc2lnbmF0aW9uOiBMMy1DYWNoZQ0KCUNvbmZpZ3VyYXRpb246IEVuYWJs
ZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMw0KCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIEJhY2sN
CglMb2NhdGlvbjogSW50ZXJuYWwNCglJbnN0YWxsZWQgU2l6ZTogODE5MiBrQg0KCU1heGltdW0g
U2l6ZTogODE5MiBrQg0KCVN1cHBvcnRlZCBTUkFNIFR5cGVzOg0KCQlPdGhlcg0KCUluc3RhbGxl
ZCBTUkFNIFR5cGU6IE90aGVyDQoJU3BlZWQ6IFVua25vd24NCglFcnJvciBDb3JyZWN0aW9uIFR5
cGU6IFNpbmdsZS1iaXQgRUNDDQoJU3lzdGVtIFR5cGU6IFVuaWZpZWQNCglBc3NvY2lhdGl2aXR5
OiAxNi13YXkgU2V0LWFzc29jaWF0aXZlDQoNCkhhbmRsZSAweDAwMDgsIERNSSB0eXBlIDQsIDQy
IGJ5dGVzDQpQcm9jZXNzb3IgSW5mb3JtYXRpb24NCglTb2NrZXQgRGVzaWduYXRpb246IENQVSAy
DQoJVHlwZTogQ2VudHJhbCBQcm9jZXNzb3INCglGYW1pbHk6IFhlb24NCglNYW51ZmFjdHVyZXI6
IEludGVsDQoJSUQ6IEEyIDA2IDAxIDAwIEZGIEZCIEVCIEJGDQoJU2lnbmF0dXJlOiBUeXBlIDAs
IEZhbWlseSA2LCBNb2RlbCAyNiwgU3RlcHBpbmcgMg0KCUZsYWdzOg0KCQlGUFUgKEZsb2F0aW5n
LXBvaW50IHVuaXQgb24tY2hpcCkNCgkJVk1FIChWaXJ0dWFsIG1vZGUgZXh0ZW5zaW9uKQ0KCQlE
RSAoRGVidWdnaW5nIGV4dGVuc2lvbikNCgkJUFNFIChQYWdlIHNpemUgZXh0ZW5zaW9uKQ0KCQlU
U0MgKFRpbWUgc3RhbXAgY291bnRlcikNCgkJTVNSIChNb2RlbCBzcGVjaWZpYyByZWdpc3RlcnMp
DQoJCVBBRSAoUGh5c2ljYWwgYWRkcmVzcyBleHRlbnNpb24pDQoJCU1DRSAoTWFjaGluZSBjaGVj
ayBleGNlcHRpb24pDQoJCUNYOCAoQ01QWENIRzggaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQ0KCQlB
UElDIChPbi1jaGlwIEFQSUMgaGFyZHdhcmUgc3VwcG9ydGVkKQ0KCQlTRVAgKEZhc3Qgc3lzdGVt
IGNhbGwpDQoJCU1UUlIgKE1lbW9yeSB0eXBlIHJhbmdlIHJlZ2lzdGVycykNCgkJUEdFIChQYWdl
IGdsb2JhbCBlbmFibGUpDQoJCU1DQSAoTWFjaGluZSBjaGVjayBhcmNoaXRlY3R1cmUpDQoJCUNN
T1YgKENvbmRpdGlvbmFsIG1vdmUgaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQ0KCQlQQVQgKFBhZ2Ug
YXR0cmlidXRlIHRhYmxlKQ0KCQlQU0UtMzYgKDM2LWJpdCBwYWdlIHNpemUgZXh0ZW5zaW9uKQ0K
CQlDTEZTSCAoQ0xGTFVTSCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpDQoJCURTIChEZWJ1ZyBzdG9y
ZSkNCgkJQUNQSSAoQUNQSSBzdXBwb3J0ZWQpDQoJCU1NWCAoTU1YIHRlY2hub2xvZ3kgc3VwcG9y
dGVkKQ0KCQlGWFNSIChGYXN0IGZsb2F0aW5nLXBvaW50IHNhdmUgYW5kIHJlc3RvcmUpDQoJCVNT
RSAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9ucykNCgkJU1NFMiAoU3RyZWFtaW5nIFNJTUQgZXh0
ZW5zaW9ucyAyKQ0KCQlTUyAoU2VsZi1zbm9vcCkNCgkJSFRUIChIeXBlci10aHJlYWRpbmcgdGVj
aG5vbG9neSkNCgkJVE0gKFRoZXJtYWwgbW9uaXRvciBzdXBwb3J0ZWQpDQoJCVBCRSAoUGVuZGlu
ZyBicmVhayBlbmFibGVkKQ0KCVZlcnNpb246IEdlbnVpbmUgSW50ZWwoUikgQ1BVICAgICAgICAg
ICBAIDAwMDAgQCAyLjQwR0h6DQoJVm9sdGFnZTogVW5rbm93bg0KCUV4dGVybmFsIENsb2NrOiAx
MzMgTUh6DQoJTWF4IFNwZWVkOiAyNDAwIE1Ieg0KCUN1cnJlbnQgU3BlZWQ6IDI0MDAgTUh6DQoJ
U3RhdHVzOiBQb3B1bGF0ZWQsIEVuYWJsZWQNCglVcGdyYWRlOiBPdGhlcg0KCUwxIENhY2hlIEhh
bmRsZTogMHgwMDA5DQoJTDIgQ2FjaGUgSGFuZGxlOiAweDAwMEENCglMMyBDYWNoZSBIYW5kbGU6
IDB4MDAwQg0KCVNlcmlhbCBOdW1iZXI6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglBc3NldCBU
YWc6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglQYXJ0IE51bWJlcjogVG8gQmUgRmlsbGVkIEJ5
IE8uRS5NLg0KCUNvcmUgQ291bnQ6IDQNCglDb3JlIEVuYWJsZWQ6IDQNCglUaHJlYWQgQ291bnQ6
IDgNCglDaGFyYWN0ZXJpc3RpY3M6DQoJCTY0LWJpdCBjYXBhYmxlDQoNCkhhbmRsZSAweDAwMDks
IERNSSB0eXBlIDcsIDE5IGJ5dGVzDQpDYWNoZSBJbmZvcm1hdGlvbg0KCVNvY2tldCBEZXNpZ25h
dGlvbjogTDEtQ2FjaGUNCglDb25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExl
dmVsIDENCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBUaHJvdWdoDQoJTG9jYXRpb246IEludGVy
bmFsDQoJSW5zdGFsbGVkIFNpemU6IDI1NiBrQg0KCU1heGltdW0gU2l6ZTogMjU2IGtCDQoJU3Vw
cG9ydGVkIFNSQU0gVHlwZXM6DQoJCU90aGVyDQoJSW5zdGFsbGVkIFNSQU0gVHlwZTogT3RoZXIN
CglTcGVlZDogVW5rbm93bg0KCUVycm9yIENvcnJlY3Rpb24gVHlwZTogUGFyaXR5DQoJU3lzdGVt
IFR5cGU6IEluc3RydWN0aW9uDQoJQXNzb2NpYXRpdml0eTogNC13YXkgU2V0LWFzc29jaWF0aXZl
DQoNCkhhbmRsZSAweDAwMEEsIERNSSB0eXBlIDcsIDE5IGJ5dGVzDQpDYWNoZSBJbmZvcm1hdGlv
bg0KCVNvY2tldCBEZXNpZ25hdGlvbjogTDItQ2FjaGUNCglDb25maWd1cmF0aW9uOiBFbmFibGVk
LCBOb3QgU29ja2V0ZWQsIExldmVsIDINCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBUaHJvdWdo
DQoJTG9jYXRpb246IEludGVybmFsDQoJSW5zdGFsbGVkIFNpemU6IDEwMjQga0INCglNYXhpbXVt
IFNpemU6IDEwMjQga0INCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoNCgkJT3RoZXINCglJbnN0YWxs
ZWQgU1JBTSBUeXBlOiBPdGhlcg0KCVNwZWVkOiBVbmtub3duDQoJRXJyb3IgQ29ycmVjdGlvbiBU
eXBlOiBTaW5nbGUtYml0IEVDQw0KCVN5c3RlbSBUeXBlOiBVbmlmaWVkDQoJQXNzb2NpYXRpdml0
eTogOC13YXkgU2V0LWFzc29jaWF0aXZlDQoNCkhhbmRsZSAweDAwMEIsIERNSSB0eXBlIDcsIDE5
IGJ5dGVzDQpDYWNoZSBJbmZvcm1hdGlvbg0KCVNvY2tldCBEZXNpZ25hdGlvbjogTDMtQ2FjaGUN
CglDb25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDMNCglPcGVyYXRp
b25hbCBNb2RlOiBXcml0ZSBCYWNrDQoJTG9jYXRpb246IEludGVybmFsDQoJSW5zdGFsbGVkIFNp
emU6IDgxOTIga0INCglNYXhpbXVtIFNpemU6IDgxOTIga0INCglTdXBwb3J0ZWQgU1JBTSBUeXBl
czoNCgkJT3RoZXINCglJbnN0YWxsZWQgU1JBTSBUeXBlOiBPdGhlcg0KCVNwZWVkOiBVbmtub3du
DQoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQw0KCVN5c3RlbSBUeXBlOiBV
bmlmaWVkDQoJQXNzb2NpYXRpdml0eTogMTYtd2F5IFNldC1hc3NvY2lhdGl2ZQ0KDQpIYW5kbGUg
MHgwMDBDLCBETUkgdHlwZSA5LCAxNyBieXRlcw0KU3lzdGVtIFNsb3QgSW5mb3JtYXRpb24NCglE
ZXNpZ25hdGlvbjogUENJRTENCglUeXBlOiB4MTYgUENJIEV4cHJlc3MNCglDdXJyZW50IFVzYWdl
OiBBdmFpbGFibGUNCglMZW5ndGg6IExvbmcNCglJRDogMQ0KCUNoYXJhY3RlcmlzdGljczoNCgkJ
My4zIFYgaXMgcHJvdmlkZWQNCgkJT3BlbmluZyBpcyBzaGFyZWQNCgkJUE1FIHNpZ25hbCBpcyBz
dXBwb3J0ZWQNCg0KSGFuZGxlIDB4MDAwRCwgRE1JIHR5cGUgMTEsIDUgYnl0ZXMNCk9FTSBTdHJp
bmdzDQoJU3RyaW5nIDE6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglTdHJpbmcgMjogVG8gQmUg
RmlsbGVkIEJ5IE8uRS5NLg0KDQpIYW5kbGUgMHgwMDBFLCBETUkgdHlwZSAxNSwgNTUgYnl0ZXMN
ClN5c3RlbSBFdmVudCBMb2cNCglBcmVhIExlbmd0aDogMTAwOCBieXRlcw0KCUhlYWRlciBTdGFy
dCBPZmZzZXQ6IDB4MDgxMA0KCURhdGEgU3RhcnQgT2Zmc2V0OiAweDA4MTANCglBY2Nlc3MgTWV0
aG9kOiBHZW5lcmFsLXB1cnBvc2Ugbm9uLXZvbGF0aWxlIGRhdGEgZnVuY3Rpb25zDQoJQWNjZXNz
IEFkZHJlc3M6IDB4MDAwMQ0KCVN0YXR1czogVmFsaWQsIE5vdCBGdWxsDQoJQ2hhbmdlIFRva2Vu
OiAweDAwMDAwMDAwDQoJSGVhZGVyIEZvcm1hdDogTm8gSGVhZGVyDQoJU3VwcG9ydGVkIExvZyBU
eXBlIERlc2NyaXB0b3JzOiAxNQ0KCURlc2NyaXB0b3IgMTogU2luZ2xlLWJpdCBFQ0MgbWVtb3J5
IGVycm9yDQoJRGF0YSBGb3JtYXQgMTogTXVsdGlwbGUtZXZlbnQgaGFuZGxlDQoJRGVzY3JpcHRv
ciAyOiBNdWx0aS1iaXQgRUNDIG1lbW9yeSBlcnJvcg0KCURhdGEgRm9ybWF0IDI6IE11bHRpcGxl
LWV2ZW50IGhhbmRsZQ0KCURlc2NyaXB0b3IgMzogUGFyaXR5IG1lbW9yeSBlcnJvcg0KCURhdGEg
Rm9ybWF0IDM6IE11bHRpcGxlLWV2ZW50DQoJRGVzY3JpcHRvciA0OiBJL08gY2hhbm5lbCBibG9j
aw0KCURhdGEgRm9ybWF0IDQ6IE11bHRpcGxlLWV2ZW50DQoJRGVzY3JpcHRvciA1OiBQT1NUIGVy
cm9yDQoJRGF0YSBGb3JtYXQgNTogUE9TVCByZXN1bHRzIGJpdG1hcA0KCURlc2NyaXB0b3IgNjog
UENJIHBhcml0eSBlcnJvcg0KCURhdGEgRm9ybWF0IDY6IE11bHRpcGxlLWV2ZW50IGhhbmRsZQ0K
CURlc2NyaXB0b3IgNzogUENJIHN5c3RlbSBlcnJvcg0KCURhdGEgRm9ybWF0IDc6IE11bHRpcGxl
LWV2ZW50IGhhbmRsZQ0KCURlc2NyaXB0b3IgODogU3lzdGVtIGxpbWl0IGV4Y2VlZGVkDQoJRGF0
YSBGb3JtYXQgODogTXVsdGlwbGUtZXZlbnQgc3lzdGVtIG1hbmFnZW1lbnQNCglEZXNjcmlwdG9y
IDk6IE9FTS1zcGVjaWZpYw0KCURhdGEgRm9ybWF0IDk6IFBPU1QgcmVzdWx0cyBiaXRtYXANCglE
ZXNjcmlwdG9yIDEwOiBPRU0tc3BlY2lmaWMNCglEYXRhIEZvcm1hdCAxMDogTXVsdGlwbGUtZXZl
bnQgaGFuZGxlDQoJRGVzY3JpcHRvciAxMTogT0VNLXNwZWNpZmljDQoJRGF0YSBGb3JtYXQgMTE6
IE11bHRpcGxlLWV2ZW50IGhhbmRsZQ0KCURlc2NyaXB0b3IgMTI6IE9FTS1zcGVjaWZpYw0KCURh
dGEgRm9ybWF0IDEyOiBNdWx0aXBsZS1ldmVudCBoYW5kbGUNCglEZXNjcmlwdG9yIDEzOiBPRU0t
c3BlY2lmaWMNCglEYXRhIEZvcm1hdCAxMzogTXVsdGlwbGUtZXZlbnQgaGFuZGxlDQoJRGVzY3Jp
cHRvciAxNDogT0VNLXNwZWNpZmljDQoJRGF0YSBGb3JtYXQgMTQ6IE11bHRpcGxlLWV2ZW50IGhh
bmRsZQ0KCURlc2NyaXB0b3IgMTU6IE9FTS1zcGVjaWZpYw0KCURhdGEgRm9ybWF0IDE1OiBNdWx0
aXBsZS1ldmVudCBoYW5kbGUNCg0KSGFuZGxlIDB4MDAwRiwgRE1JIHR5cGUgMTYsIDE1IGJ5dGVz
DQpQaHlzaWNhbCBNZW1vcnkgQXJyYXkNCglMb2NhdGlvbjogU3lzdGVtIEJvYXJkIE9yIE1vdGhl
cmJvYXJkDQoJVXNlOiBTeXN0ZW0gTWVtb3J5DQoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBNdWx0
aS1iaXQgRUNDDQoJTWF4aW11bSBDYXBhY2l0eTogMzg0IEdCDQoJRXJyb3IgSW5mb3JtYXRpb24g
SGFuZGxlOiBOb3QgUHJvdmlkZWQNCglOdW1iZXIgT2YgRGV2aWNlczogMTINCg0KSGFuZGxlIDB4
MDAxMCwgRE1JIHR5cGUgMTksIDE1IGJ5dGVzDQpNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MN
CglTdGFydGluZyBBZGRyZXNzOiAweDAwMDAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4MDQ0
NDNGRkZGRkYNCglSYW5nZSBTaXplOiAyNzk2MTYgTUINCglQaHlzaWNhbCBBcnJheSBIYW5kbGU6
IDB4MDAwRg0KCVBhcnRpdGlvbiBXaWR0aDogMA0KDQpIYW5kbGUgMHgwMDExLCBETUkgdHlwZSAx
NywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJheSBIYW5kbGU6IDB4MDAwRg0KCUVycm9y
IEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6IDcyIGJpdHMN
CglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFjdG9yOiBESU1N
DQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDEtRElNTTFBDQoJQmFuayBMb2NhdG9yOiBCQU5LMA0K
CVR5cGU6IEREUjMNCglUeXBlIERldGFpbDogT3RoZXINCglTcGVlZDogMTA2NiBNSHoNCglNYW51
ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJlcjogMDAwMDAwMDANCglBc3NldCBUYWc6DQoJUGFydCBO
dW1iZXI6IFNVUEVSVEFMRU5UMDINCglSYW5rOiBVbmtub3duDQoNCkhhbmRsZSAweDAwMTIsIERN
SSB0eXBlIDIwLCAxOSBieXRlcw0KTWVtb3J5IERldmljZSBNYXBwZWQgQWRkcmVzcw0KCVN0YXJ0
aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDANCglFbmRpbmcgQWRkcmVzczogMHgwMDEwMDAwMDNG
Rg0KCVJhbmdlIFNpemU6IDQxOTQzMDUga0INCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAw
MTENCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMTANCglQYXJ0aXRp
b24gUm93IFBvc2l0aW9uOiAxDQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bg0KCUludGVy
bGVhdmVkIERhdGEgRGVwdGg6IDINCg0KSGFuZGxlIDB4MDAxMywgRE1JIHR5cGUgMTcsIDI4IGJ5
dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJyYXkgSGFuZGxlOiAweDAwMEYNCglFcnJvciBJbmZvcm1h
dGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZA0KCVRvdGFsIFdpZHRoOiA3MiBiaXRzDQoJRGF0YSBX
aWR0aDogNjQgYml0cw0KCVNpemU6IDQwOTYgTUINCglGb3JtIEZhY3RvcjogRElNTQ0KCVNldDog
Tm9uZQ0KCUxvY2F0b3I6IFAxLURJTU0xQg0KCUJhbmsgTG9jYXRvcjogQkFOSzENCglUeXBlOiBE
RFIzDQoJVHlwZSBEZXRhaWw6IE90aGVyDQoJU3BlZWQ6IDEwNjYgTUh6DQoJTWFudWZhY3R1cmVy
Og0KCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwDQoJQXNzZXQgVGFnOg0KCVBhcnQgTnVtYmVyOiBT
VVBFUlRBTEVOVDAyDQoJUmFuazogVW5rbm93bg0KDQpIYW5kbGUgMHgwMDE0LCBETUkgdHlwZSAy
MCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MNCglTdGFydGluZyBBZGRy
ZXNzOiAweDAwMTAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4MDAyMDAwMDAzRkYNCglSYW5n
ZSBTaXplOiA0MTk0MzA1IGtCDQoJUGh5c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDEzDQoJTWVt
b3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEwDQoJUGFydGl0aW9uIFJvdyBQ
b3NpdGlvbjogMQ0KCUludGVybGVhdmUgUG9zaXRpb246IFVua25vd24NCglJbnRlcmxlYXZlZCBE
YXRhIERlcHRoOiAyDQoNCkhhbmRsZSAweDAwMTUsIERNSSB0eXBlIDE3LCAyOCBieXRlcw0KTWVt
b3J5IERldmljZQ0KCUFycmF5IEhhbmRsZTogMHgwMDBGDQoJRXJyb3IgSW5mb3JtYXRpb24gSGFu
ZGxlOiBOb3QgUHJvdmlkZWQNCglUb3RhbCBXaWR0aDogNzIgYml0cw0KCURhdGEgV2lkdGg6IDY0
IGJpdHMNCglTaXplOiA0MDk2IE1CDQoJRm9ybSBGYWN0b3I6IERJTU0NCglTZXQ6IE5vbmUNCglM
b2NhdG9yOiBQMS1ESU1NMkENCglCYW5rIExvY2F0b3I6IEJBTksyDQoJVHlwZTogRERSMw0KCVR5
cGUgRGV0YWlsOiBPdGhlcg0KCVNwZWVkOiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJp
YWwgTnVtYmVyOiAwMDAwMDAwMA0KCUFzc2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxF
TlQwMg0KCVJhbms6IFVua25vd24NCg0KSGFuZGxlIDB4MDAxNiwgRE1JIHR5cGUgMjAsIDE5IGJ5
dGVzDQpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgw
MDIwMDAwMDAwMA0KCUVuZGluZyBBZGRyZXNzOiAweDAwMzAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTog
NDE5NDMwNSBrQg0KCVBoeXNpY2FsIERldmljZSBIYW5kbGU6IDB4MDAxNQ0KCU1lbW9yeSBBcnJh
eSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246
IDENCglJbnRlcmxlYXZlIFBvc2l0aW9uOiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0
aDogMg0KDQpIYW5kbGUgMHgwMDE3LCBETUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZp
Y2UNCglBcnJheSBIYW5kbGU6IDB4MDAwRg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90
IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJ
U2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFjdG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjog
UDEtRElNTTJCDQoJQmFuayBMb2NhdG9yOiBCQU5LMw0KCVR5cGU6IEREUjMNCglUeXBlIERldGFp
bDogT3RoZXINCglTcGVlZDogMTA2NiBNSHoNCglNYW51ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJl
cjogMDAwMDAwMDANCglBc3NldCBUYWc6DQoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDINCglS
YW5rOiBVbmtub3duDQoNCkhhbmRsZSAweDAwMTgsIERNSSB0eXBlIDIwLCAxOSBieXRlcw0KTWVt
b3J5IERldmljZSBNYXBwZWQgQWRkcmVzcw0KCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAzMDAwMDAw
MDANCglFbmRpbmcgQWRkcmVzczogMHgwMDQwMDAwMDNGRg0KCVJhbmdlIFNpemU6IDQxOTQzMDUg
a0INCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTcNCglNZW1vcnkgQXJyYXkgTWFwcGVk
IEFkZHJlc3MgSGFuZGxlOiAweDAwMTANCglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxDQoJSW50
ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bg0KCUludGVybGVhdmVkIERhdGEgRGVwdGg6IDINCg0K
SGFuZGxlIDB4MDAxOSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJy
YXkgSGFuZGxlOiAweDAwMEYNCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRl
ZA0KCVRvdGFsIFdpZHRoOiA3MiBiaXRzDQoJRGF0YSBXaWR0aDogNjQgYml0cw0KCVNpemU6IDQw
OTYgTUINCglGb3JtIEZhY3RvcjogRElNTQ0KCVNldDogTm9uZQ0KCUxvY2F0b3I6IFAxLURJTU0z
QQ0KCUJhbmsgTG9jYXRvcjogQkFOSzQNCglUeXBlOiBERFIzDQoJVHlwZSBEZXRhaWw6IE90aGVy
DQoJU3BlZWQ6IDEwNjYgTUh6DQoJTWFudWZhY3R1cmVyOg0KCVNlcmlhbCBOdW1iZXI6IDAwMDAw
MDAwDQoJQXNzZXQgVGFnOg0KCVBhcnQgTnVtYmVyOiBTVVBFUlRBTEVOVDAyDQoJUmFuazogVW5r
bm93bg0KDQpIYW5kbGUgMHgwMDFBLCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZp
Y2UgTWFwcGVkIEFkZHJlc3MNCglTdGFydGluZyBBZGRyZXNzOiAweDAwNDAwMDAwMDAwDQoJRW5k
aW5nIEFkZHJlc3M6IDB4MDA1MDAwMDAzRkYNCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCDQoJUGh5
c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDE5DQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNz
IEhhbmRsZTogMHgwMDEwDQoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQ0KCUludGVybGVhdmUg
UG9zaXRpb246IFVua25vd24NCglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAyDQoNCkhhbmRsZSAw
eDAwMUIsIERNSSB0eXBlIDE3LCAyOCBieXRlcw0KTWVtb3J5IERldmljZQ0KCUFycmF5IEhhbmRs
ZTogMHgwMDBGDQoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxlOiBOb3QgUHJvdmlkZWQNCglUb3Rh
bCBXaWR0aDogNzIgYml0cw0KCURhdGEgV2lkdGg6IDY0IGJpdHMNCglTaXplOiA0MDk2IE1CDQoJ
Rm9ybSBGYWN0b3I6IERJTU0NCglTZXQ6IE5vbmUNCglMb2NhdG9yOiBQMS1ESU1NM0INCglCYW5r
IExvY2F0b3I6IEJBTks1DQoJVHlwZTogRERSMw0KCVR5cGUgRGV0YWlsOiBPdGhlcg0KCVNwZWVk
OiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJpYWwgTnVtYmVyOiAwMDAwMDAwMA0KCUFz
c2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQwMg0KCVJhbms6IFVua25vd24NCg0K
SGFuZGxlIDB4MDAxQywgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzDQpNZW1vcnkgRGV2aWNlIE1hcHBl
ZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDUwMDAwMDAwMA0KCUVuZGluZyBBZGRy
ZXNzOiAweDAwNjAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTogNDE5NDMwNSBrQg0KCVBoeXNpY2FsIERl
dmljZSBIYW5kbGU6IDB4MDAxQg0KCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6
IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDENCglJbnRlcmxlYXZlIFBvc2l0aW9u
OiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMg0KDQpIYW5kbGUgMHgwMDFELCBE
TUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJheSBIYW5kbGU6IDB4MDAw
Rg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6
IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFj
dG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDItRElNTTFBDQoJQmFuayBMb2NhdG9y
OiBCQU5LNg0KCVR5cGU6IEREUjMNCglUeXBlIERldGFpbDogT3RoZXINCglTcGVlZDogMTA2NiBN
SHoNCglNYW51ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJlcjogMDAwMDAwMDANCglBc3NldCBUYWc6
DQoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDINCglSYW5rOiBVbmtub3duDQoNCkhhbmRsZSAw
eDAwMUUsIERNSSB0eXBlIDIwLCAxOSBieXRlcw0KTWVtb3J5IERldmljZSBNYXBwZWQgQWRkcmVz
cw0KCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDANCglFbmRpbmcgQWRkcmVzczogMHgw
MDAwMDAwMDNGRg0KCVJhbmdlIFNpemU6IDEga0INCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAw
eDAwMUQNCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMTANCglQYXJ0
aXRpb24gUm93IFBvc2l0aW9uOiAxDQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bg0KCUlu
dGVybGVhdmVkIERhdGEgRGVwdGg6IDINCg0KSGFuZGxlIDB4MDAxRiwgRE1JIHR5cGUgMTcsIDI4
IGJ5dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJyYXkgSGFuZGxlOiAweDAwMEYNCglFcnJvciBJbmZv
cm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZA0KCVRvdGFsIFdpZHRoOiA3MiBiaXRzDQoJRGF0
YSBXaWR0aDogNjQgYml0cw0KCVNpemU6IDQwOTYgTUINCglGb3JtIEZhY3RvcjogRElNTQ0KCVNl
dDogTm9uZQ0KCUxvY2F0b3I6IFAyLURJTU0xQg0KCUJhbmsgTG9jYXRvcjogQkFOSzcNCglUeXBl
OiBERFIzDQoJVHlwZSBEZXRhaWw6IE90aGVyDQoJU3BlZWQ6IDEwNjYgTUh6DQoJTWFudWZhY3R1
cmVyOg0KCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwDQoJQXNzZXQgVGFnOg0KCVBhcnQgTnVtYmVy
OiBTVVBFUlRBTEVOVDAyDQoJUmFuazogVW5rbm93bg0KDQpIYW5kbGUgMHgwMDIwLCBETUkgdHlw
ZSAyMCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MNCglTdGFydGluZyBB
ZGRyZXNzOiAweDAwMDAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAzRkYNCglS
YW5nZSBTaXplOiAxIGtCDQoJUGh5c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDFGDQoJTWVtb3J5
IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEwDQoJUGFydGl0aW9uIFJvdyBQb3Np
dGlvbjogMQ0KCUludGVybGVhdmUgUG9zaXRpb246IFVua25vd24NCglJbnRlcmxlYXZlZCBEYXRh
IERlcHRoOiAyDQoNCkhhbmRsZSAweDAwMjEsIERNSSB0eXBlIDE3LCAyOCBieXRlcw0KTWVtb3J5
IERldmljZQ0KCUFycmF5IEhhbmRsZTogMHgwMDBGDQoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxl
OiBOb3QgUHJvdmlkZWQNCglUb3RhbCBXaWR0aDogNzIgYml0cw0KCURhdGEgV2lkdGg6IDY0IGJp
dHMNCglTaXplOiA0MDk2IE1CDQoJRm9ybSBGYWN0b3I6IERJTU0NCglTZXQ6IE5vbmUNCglMb2Nh
dG9yOiBQMi1ESU1NMkENCglCYW5rIExvY2F0b3I6IEJBTks4DQoJVHlwZTogRERSMw0KCVR5cGUg
RGV0YWlsOiBPdGhlcg0KCVNwZWVkOiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJpYWwg
TnVtYmVyOiAwMDAwMDAwMA0KCUFzc2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQw
Mg0KCVJhbms6IFVua25vd24NCg0KSGFuZGxlIDB4MDAyMiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVz
DQpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDAw
MDAwMDAwMA0KCUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTogMSBr
Qg0KCVBoeXNpY2FsIERldmljZSBIYW5kbGU6IDB4MDAyMQ0KCU1lbW9yeSBBcnJheSBNYXBwZWQg
QWRkcmVzcyBIYW5kbGU6IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDENCglJbnRl
cmxlYXZlIFBvc2l0aW9uOiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMg0KDQpI
YW5kbGUgMHgwMDIzLCBETUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJh
eSBIYW5kbGU6IDB4MDAwRg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVk
DQoJVG90YWwgV2lkdGg6IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5
NiBNQg0KCUZvcm0gRmFjdG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDItRElNTTJC
DQoJQmFuayBMb2NhdG9yOiBCQU5LOQ0KCVR5cGU6IEREUjMNCglUeXBlIERldGFpbDogT3RoZXIN
CglTcGVlZDogMTA2NiBNSHoNCglNYW51ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJlcjogMDAwMDAw
MDANCglBc3NldCBUYWc6DQoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDINCglSYW5rOiBVbmtu
b3duDQoNCkhhbmRsZSAweDAwMjQsIERNSSB0eXBlIDIwLCAxOSBieXRlcw0KTWVtb3J5IERldmlj
ZSBNYXBwZWQgQWRkcmVzcw0KCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDA2MDAwMDAwMDANCglFbmRp
bmcgQWRkcmVzczogMHgwMDcwMDAwMDNGRg0KCVJhbmdlIFNpemU6IDQxOTQzMDUga0INCglQaHlz
aWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMjMNCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3Mg
SGFuZGxlOiAweDAwMTANCglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxDQoJSW50ZXJsZWF2ZSBQ
b3NpdGlvbjogVW5rbm93bg0KCUludGVybGVhdmVkIERhdGEgRGVwdGg6IDINCg0KSGFuZGxlIDB4
MDAyNSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJyYXkgSGFuZGxl
OiAweDAwMEYNCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZA0KCVRvdGFs
IFdpZHRoOiA3MiBiaXRzDQoJRGF0YSBXaWR0aDogNjQgYml0cw0KCVNpemU6IDQwOTYgTUINCglG
b3JtIEZhY3RvcjogRElNTQ0KCVNldDogTm9uZQ0KCUxvY2F0b3I6IFAyLURJTU0zQQ0KCUJhbmsg
TG9jYXRvcjogQkFOSzEwDQoJVHlwZTogRERSMw0KCVR5cGUgRGV0YWlsOiBPdGhlcg0KCVNwZWVk
OiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJpYWwgTnVtYmVyOiAwMDAwMDAwMA0KCUFz
c2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQwMg0KCVJhbms6IFVua25vd24NCg0K
SGFuZGxlIDB4MDAyNiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzDQpNZW1vcnkgRGV2aWNlIE1hcHBl
ZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDcwMDAwMDAwMA0KCUVuZGluZyBBZGRy
ZXNzOiAweDAwODAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTogNDE5NDMwNSBrQg0KCVBoeXNpY2FsIERl
dmljZSBIYW5kbGU6IDB4MDAyNQ0KCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6
IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDENCglJbnRlcmxlYXZlIFBvc2l0aW9u
OiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMg0KDQpIYW5kbGUgMHgwMDI3LCBE
TUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJheSBIYW5kbGU6IDB4MDAw
Rg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6
IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFj
dG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDItRElNTTNCDQoJQmFuayBMb2NhdG9y
OiBCQU5LMTENCglUeXBlOiBERFIzDQoJVHlwZSBEZXRhaWw6IE90aGVyDQoJU3BlZWQ6IDEwNjYg
TUh6DQoJTWFudWZhY3R1cmVyOg0KCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwDQoJQXNzZXQgVGFn
Og0KCVBhcnQgTnVtYmVyOiBTVVBFUlRBTEVOVDAyDQoJUmFuazogVW5rbm93bg0KDQpIYW5kbGUg
MHgwMDI4LCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJl
c3MNCglTdGFydGluZyBBZGRyZXNzOiAweDAwODAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4
MDA5MDAwMDAzRkYNCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCDQoJUGh5c2ljYWwgRGV2aWNlIEhh
bmRsZTogMHgwMDI3DQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEw
DQoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQ0KCUludGVybGVhdmUgUG9zaXRpb246IFVua25v
d24NCglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAyDQoNCkhhbmRsZSAweDAwMjksIERNSSB0eXBl
IDMyLCAyMCBieXRlcw0KU3lzdGVtIEJvb3QgSW5mb3JtYXRpb24NCglTdGF0dXM6IE5vIGVycm9y
cyBkZXRlY3RlZA0KDQpIYW5kbGUgMHgwMDJBLCBETUkgdHlwZSAzOCwgMTggYnl0ZXMNCklQTUkg
RGV2aWNlIEluZm9ybWF0aW9uDQoJSW50ZXJmYWNlIFR5cGU6IEtDUyAoS2V5Ym9hcmQgQ29udHJv
bCBTdHlsZSkNCglTcGVjaWZpY2F0aW9uIFZlcnNpb246IDIuMA0KCUkyQyBTbGF2ZSBBZGRyZXNz
OiAweDEwDQoJTlYgU3RvcmFnZSBEZXZpY2U6IE5vdCBQcmVzZW50DQoJQmFzZSBBZGRyZXNzOiAw
eDAwMDAwMDAwMDAwMDBDQTIgKEkvTykNCglSZWdpc3RlciBTcGFjaW5nOiBTdWNjZXNzaXZlIEJ5
dGUgQm91bmRhcmllcw0KDQpIYW5kbGUgMHgwMDJCLCBETUkgdHlwZSAxMjcsIDQgYnl0ZXMNCkVu
ZCBPZiBUYWJsZQ0KDQoNCi0tIA0KTGVvbmlkIEthbGV2DQpDQSBUZWNobm9sb2dpZXMNClByaW5j
aXBhbCBTb2Z0d2FyZSBFbmdpbmVlcg0KVGVsOiAgICAgKzk3MiA0IDgyNSAzOTUyDQpNb2JpbGU6
ICArOTcyIDU0IDQ2MzE1MDgNCkxlb25pZC5LYWxldkBjYS5jb20NCg==

--_002_4F2188768090606cacom_
Content-Type: text/plain; name="dmidecode-eptfail"
Content-Description: dmidecode-eptfail
Content-Disposition: attachment; filename="dmidecode-eptfail"; size=19255;
	creation-date="Thu, 26 Jan 2012 17:08:07 GMT";
	modification-date="Thu, 26 Jan 2012 17:08:07 GMT"
Content-ID: <84EC5538FD1AF2418C2D79167F96121A@ca.com>
Content-Transfer-Encoding: base64

IyBkbWlkZWNvZGUgMi4xMApTTUJJT1MgMi42IHByZXNlbnQuCjQ0IHN0cnVjdHVyZXMgb2NjdXB5
aW5nIDI1NDkgYnl0ZXMuClRhYmxlIGF0IDB4MDAwOUVDMDAuCgpIYW5kbGUgMHgwMDAwLCBETUkg
dHlwZSAwLCAyNCBieXRlcwpCSU9TIEluZm9ybWF0aW9uCglWZW5kb3I6IEFtZXJpY2FuIE1lZ2F0
cmVuZHMgSW5jLgoJVmVyc2lvbjogMDgwMDE2IAoJUmVsZWFzZSBEYXRlOiAwMi8xMS8yMDExCglB
ZGRyZXNzOiAweEYwMDAwCglSdW50aW1lIFNpemU6IDY0IGtCCglST00gU2l6ZTogNDA5NiBrQgoJ
Q2hhcmFjdGVyaXN0aWNzOgoJCUlTQSBpcyBzdXBwb3J0ZWQKCQlQQ0kgaXMgc3VwcG9ydGVkCgkJ
UE5QIGlzIHN1cHBvcnRlZAoJCUJJT1MgaXMgdXBncmFkZWFibGUKCQlCSU9TIHNoYWRvd2luZyBp
cyBhbGxvd2VkCgkJRVNDRCBzdXBwb3J0IGlzIGF2YWlsYWJsZQoJCUJvb3QgZnJvbSBDRCBpcyBz
dXBwb3J0ZWQKCQlTZWxlY3RhYmxlIGJvb3QgaXMgc3VwcG9ydGVkCgkJQklPUyBST00gaXMgc29j
a2V0ZWQKCQlFREQgaXMgc3VwcG9ydGVkCgkJNS4yNSIvMS4yIE1CIGZsb3BweSBzZXJ2aWNlcyBh
cmUgc3VwcG9ydGVkIChpbnQgMTNoKQoJCTMuNSIvNzIwIGtCIGZsb3BweSBzZXJ2aWNlcyBhcmUg
c3VwcG9ydGVkIChpbnQgMTNoKQoJCTMuNSIvMi44OCBNQiBmbG9wcHkgc2VydmljZXMgYXJlIHN1
cHBvcnRlZCAoaW50IDEzaCkKCQlQcmludCBzY3JlZW4gc2VydmljZSBpcyBzdXBwb3J0ZWQgKGlu
dCA1aCkKCQk4MDQyIGtleWJvYXJkIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCA5aCkKCQlT
ZXJpYWwgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDE0aCkKCQlQcmludGVyIHNlcnZpY2Vz
IGFyZSBzdXBwb3J0ZWQgKGludCAxN2gpCgkJQ0dBL21vbm8gdmlkZW8gc2VydmljZXMgYXJlIHN1
cHBvcnRlZCAoaW50IDEwaCkKCQlBQ1BJIGlzIHN1cHBvcnRlZAoJCVVTQiBsZWdhY3kgaXMgc3Vw
cG9ydGVkCgkJTFMtMTIwIGJvb3QgaXMgc3VwcG9ydGVkCgkJQVRBUEkgWmlwIGRyaXZlIGJvb3Qg
aXMgc3VwcG9ydGVkCgkJQklPUyBib290IHNwZWNpZmljYXRpb24gaXMgc3VwcG9ydGVkCgkJVGFy
Z2V0ZWQgY29udGVudCBkaXN0cmlidXRpb24gaXMgc3VwcG9ydGVkCglCSU9TIFJldmlzaW9uOiA4
LjE2CgpIYW5kbGUgMHgwMDAxLCBETUkgdHlwZSAxLCAyNyBieXRlcwpTeXN0ZW0gSW5mb3JtYXRp
b24KCU1hbnVmYWN0dXJlcjogU3VwZXJtaWNybwoJUHJvZHVjdCBOYW1lOiBYOERUVC1ICglWZXJz
aW9uOiAxMjM0NTY3ODkwCglTZXJpYWwgTnVtYmVyOiAxMjM0NTY3ODkwCglVVUlEOiA1NDQ0Mzg1
OC00RTU0LTMwMDAtNDhGNC0wMDMwNDhGNDE3NzAKCVdha2UtdXAgVHlwZTogUG93ZXIgU3dpdGNo
CglTS1UgTnVtYmVyOiAxMjM0NTY3ODkwCglGYW1pbHk6IFNlcnZlcgoKSGFuZGxlIDB4MDAwMiwg
RE1JIHR5cGUgMiwgMTUgYnl0ZXMKQmFzZSBCb2FyZCBJbmZvcm1hdGlvbgoJTWFudWZhY3R1cmVy
OiBTdXBlcm1pY3JvCglQcm9kdWN0IE5hbWU6IFg4RFRULUgKCVZlcnNpb246IDEuMyAgICAgICAK
CVNlcmlhbCBOdW1iZXI6IDEyMzQ1Njc4OTAKCUFzc2V0IFRhZzogMTIzNDU2Nzg5MAoJRmVhdHVy
ZXM6CgkJQm9hcmQgaXMgYSBob3N0aW5nIGJvYXJkCgkJQm9hcmQgaXMgcmVwbGFjZWFibGUKCUxv
Y2F0aW9uIEluIENoYXNzaXM6IDEyMzQ1Njc4OTAKCUNoYXNzaXMgSGFuZGxlOiAweDAwMDMKCVR5
cGU6IE1vdGhlcmJvYXJkCglDb250YWluZWQgT2JqZWN0IEhhbmRsZXM6IDAKCkhhbmRsZSAweDAw
MDMsIERNSSB0eXBlIDMsIDIxIGJ5dGVzCkNoYXNzaXMgSW5mb3JtYXRpb24KCU1hbnVmYWN0dXJl
cjogU3VwZXJtaWNybwoJVHlwZTogTWFpbiBTZXJ2ZXIgQ2hhc3NpcwoJTG9jazogTm90IFByZXNl
bnQKCVZlcnNpb246IDEyMzQ1Njc4OTAKCVNlcmlhbCBOdW1iZXI6IDEyMzQ1Njc4OTAuCglBc3Nl
dCBUYWc6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4KCUJvb3QtdXAgU3RhdGU6IFNhZmUKCVBvd2Vy
IFN1cHBseSBTdGF0ZTogU2FmZQoJVGhlcm1hbCBTdGF0ZTogU2FmZQoJU2VjdXJpdHkgU3RhdHVz
OiBOb25lCglPRU0gSW5mb3JtYXRpb246IDB4MDAwMDAwMDAKCUhlaWdodDogVW5zcGVjaWZpZWQK
CU51bWJlciBPZiBQb3dlciBDb3JkczogMQoJQ29udGFpbmVkIEVsZW1lbnRzOiAwCgpIYW5kbGUg
MHgwMDA0LCBETUkgdHlwZSA0LCA0MiBieXRlcwpQcm9jZXNzb3IgSW5mb3JtYXRpb24KCVNvY2tl
dCBEZXNpZ25hdGlvbjogQ1BVIDEKCVR5cGU6IENlbnRyYWwgUHJvY2Vzc29yCglGYW1pbHk6IFhl
b24KCU1hbnVmYWN0dXJlcjogSW50ZWwgICAgICAgICAgICAKCUlEOiBBMiAwNiAwMSAwMCBGRiBG
QiBFQiBCRgoJU2lnbmF0dXJlOiBUeXBlIDAsIEZhbWlseSA2LCBNb2RlbCAyNiwgU3RlcHBpbmcg
MgoJRmxhZ3M6CgkJRlBVIChGbG9hdGluZy1wb2ludCB1bml0IG9uLWNoaXApCgkJVk1FIChWaXJ0
dWFsIG1vZGUgZXh0ZW5zaW9uKQoJCURFIChEZWJ1Z2dpbmcgZXh0ZW5zaW9uKQoJCVBTRSAoUGFn
ZSBzaXplIGV4dGVuc2lvbikKCQlUU0MgKFRpbWUgc3RhbXAgY291bnRlcikKCQlNU1IgKE1vZGVs
IHNwZWNpZmljIHJlZ2lzdGVycykKCQlQQUUgKFBoeXNpY2FsIGFkZHJlc3MgZXh0ZW5zaW9uKQoJ
CU1DRSAoTWFjaGluZSBjaGVjayBleGNlcHRpb24pCgkJQ1g4IChDTVBYQ0hHOCBpbnN0cnVjdGlv
biBzdXBwb3J0ZWQpCgkJQVBJQyAoT24tY2hpcCBBUElDIGhhcmR3YXJlIHN1cHBvcnRlZCkKCQlT
RVAgKEZhc3Qgc3lzdGVtIGNhbGwpCgkJTVRSUiAoTWVtb3J5IHR5cGUgcmFuZ2UgcmVnaXN0ZXJz
KQoJCVBHRSAoUGFnZSBnbG9iYWwgZW5hYmxlKQoJCU1DQSAoTWFjaGluZSBjaGVjayBhcmNoaXRl
Y3R1cmUpCgkJQ01PViAoQ29uZGl0aW9uYWwgbW92ZSBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJ
UEFUIChQYWdlIGF0dHJpYnV0ZSB0YWJsZSkKCQlQU0UtMzYgKDM2LWJpdCBwYWdlIHNpemUgZXh0
ZW5zaW9uKQoJCUNMRlNIIChDTEZMVVNIIGluc3RydWN0aW9uIHN1cHBvcnRlZCkKCQlEUyAoRGVi
dWcgc3RvcmUpCgkJQUNQSSAoQUNQSSBzdXBwb3J0ZWQpCgkJTU1YIChNTVggdGVjaG5vbG9neSBz
dXBwb3J0ZWQpCgkJRlhTUiAoRmFzdCBmbG9hdGluZy1wb2ludCBzYXZlIGFuZCByZXN0b3JlKQoJ
CVNTRSAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9ucykKCQlTU0UyIChTdHJlYW1pbmcgU0lNRCBl
eHRlbnNpb25zIDIpCgkJU1MgKFNlbGYtc25vb3ApCgkJSFRUIChIeXBlci10aHJlYWRpbmcgdGVj
aG5vbG9neSkKCQlUTSAoVGhlcm1hbCBtb25pdG9yIHN1cHBvcnRlZCkKCQlQQkUgKFBlbmRpbmcg
YnJlYWsgZW5hYmxlZCkKCVZlcnNpb246IEdlbnVpbmUgSW50ZWwoUikgQ1BVICAgICAgICAgICBA
IDAwMDAgQCAyLjQwR0h6ICAgICAKCVZvbHRhZ2U6IFVua25vd24KCUV4dGVybmFsIENsb2NrOiAx
MzMgTUh6CglNYXggU3BlZWQ6IDI0MDAgTUh6CglDdXJyZW50IFNwZWVkOiAyNDAwIE1IegoJU3Rh
dHVzOiBQb3B1bGF0ZWQsIEVuYWJsZWQKCVVwZ3JhZGU6IE90aGVyCglMMSBDYWNoZSBIYW5kbGU6
IDB4MDAwNQoJTDIgQ2FjaGUgSGFuZGxlOiAweDAwMDYKCUwzIENhY2hlIEhhbmRsZTogMHgwMDA3
CglTZXJpYWwgTnVtYmVyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uCglBc3NldCBUYWc6IFRvIEJl
IEZpbGxlZCBCeSBPLkUuTS4KCVBhcnQgTnVtYmVyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uCglD
b3JlIENvdW50OiA0CglDb3JlIEVuYWJsZWQ6IDQKCVRocmVhZCBDb3VudDogOAoJQ2hhcmFjdGVy
aXN0aWNzOgoJCTY0LWJpdCBjYXBhYmxlCgpIYW5kbGUgMHgwMDA1LCBETUkgdHlwZSA3LCAxOSBi
eXRlcwpDYWNoZSBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2lnbmF0aW9uOiBMMS1DYWNoZQoJQ29u
ZmlndXJhdGlvbjogRW5hYmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAxCglPcGVyYXRpb25hbCBN
b2RlOiBXcml0ZSBUaHJvdWdoCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAy
NTYga0IKCU1heGltdW0gU2l6ZTogMjU2IGtCCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoKCQlPdGhl
cgoJSW5zdGFsbGVkIFNSQU0gVHlwZTogT3RoZXIKCVNwZWVkOiBVbmtub3duCglFcnJvciBDb3Jy
ZWN0aW9uIFR5cGU6IFBhcml0eQoJU3lzdGVtIFR5cGU6IEluc3RydWN0aW9uCglBc3NvY2lhdGl2
aXR5OiA0LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMDYsIERNSSB0eXBlIDcsIDE5
IGJ5dGVzCkNhY2hlIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWduYXRpb246IEwyLUNhY2hlCglD
b25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDIKCU9wZXJhdGlvbmFs
IE1vZGU6IFdyaXRlIFRocm91Z2gKCUxvY2F0aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6
IDEwMjQga0IKCU1heGltdW0gU2l6ZTogMTAyNCBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJ
T3RoZXIKCUluc3RhbGxlZCBTUkFNIFR5cGU6IE90aGVyCglTcGVlZDogVW5rbm93bgoJRXJyb3Ig
Q29ycmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJU3lzdGVtIFR5cGU6IFVuaWZpZWQKCUFz
c29jaWF0aXZpdHk6IDgtd2F5IFNldC1hc3NvY2lhdGl2ZQoKSGFuZGxlIDB4MDAwNywgRE1JIHR5
cGUgNywgMTkgYnl0ZXMKQ2FjaGUgSW5mb3JtYXRpb24KCVNvY2tldCBEZXNpZ25hdGlvbjogTDMt
Q2FjaGUKCUNvbmZpZ3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMwoJT3Bl
cmF0aW9uYWwgTW9kZTogV3JpdGUgQmFjawoJTG9jYXRpb246IEludGVybmFsCglJbnN0YWxsZWQg
U2l6ZTogODE5MiBrQgoJTWF4aW11bSBTaXplOiA4MTkyIGtCCglTdXBwb3J0ZWQgU1JBTSBUeXBl
czoKCQlPdGhlcgoJSW5zdGFsbGVkIFNSQU0gVHlwZTogT3RoZXIKCVNwZWVkOiBVbmtub3duCglF
cnJvciBDb3JyZWN0aW9uIFR5cGU6IFNpbmdsZS1iaXQgRUNDCglTeXN0ZW0gVHlwZTogVW5pZmll
ZAoJQXNzb2NpYXRpdml0eTogMTYtd2F5IFNldC1hc3NvY2lhdGl2ZQoKSGFuZGxlIDB4MDAwOCwg
RE1JIHR5cGUgNCwgNDIgYnl0ZXMKUHJvY2Vzc29yIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWdu
YXRpb246IENQVSAyCglUeXBlOiBDZW50cmFsIFByb2Nlc3NvcgoJRmFtaWx5OiBYZW9uCglNYW51
ZmFjdHVyZXI6IEludGVsICAgICAgICAgICAgCglJRDogQTIgMDYgMDEgMDAgRkYgRkIgRUIgQkYK
CVNpZ25hdHVyZTogVHlwZSAwLCBGYW1pbHkgNiwgTW9kZWwgMjYsIFN0ZXBwaW5nIDIKCUZsYWdz
OgoJCUZQVSAoRmxvYXRpbmctcG9pbnQgdW5pdCBvbi1jaGlwKQoJCVZNRSAoVmlydHVhbCBtb2Rl
IGV4dGVuc2lvbikKCQlERSAoRGVidWdnaW5nIGV4dGVuc2lvbikKCQlQU0UgKFBhZ2Ugc2l6ZSBl
eHRlbnNpb24pCgkJVFNDIChUaW1lIHN0YW1wIGNvdW50ZXIpCgkJTVNSIChNb2RlbCBzcGVjaWZp
YyByZWdpc3RlcnMpCgkJUEFFIChQaHlzaWNhbCBhZGRyZXNzIGV4dGVuc2lvbikKCQlNQ0UgKE1h
Y2hpbmUgY2hlY2sgZXhjZXB0aW9uKQoJCUNYOCAoQ01QWENIRzggaW5zdHJ1Y3Rpb24gc3VwcG9y
dGVkKQoJCUFQSUMgKE9uLWNoaXAgQVBJQyBoYXJkd2FyZSBzdXBwb3J0ZWQpCgkJU0VQIChGYXN0
IHN5c3RlbSBjYWxsKQoJCU1UUlIgKE1lbW9yeSB0eXBlIHJhbmdlIHJlZ2lzdGVycykKCQlQR0Ug
KFBhZ2UgZ2xvYmFsIGVuYWJsZSkKCQlNQ0EgKE1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJlKQoJ
CUNNT1YgKENvbmRpdGlvbmFsIG1vdmUgaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQoJCVBBVCAoUGFn
ZSBhdHRyaWJ1dGUgdGFibGUpCgkJUFNFLTM2ICgzNi1iaXQgcGFnZSBzaXplIGV4dGVuc2lvbikK
CQlDTEZTSCAoQ0xGTFVTSCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJRFMgKERlYnVnIHN0b3Jl
KQoJCUFDUEkgKEFDUEkgc3VwcG9ydGVkKQoJCU1NWCAoTU1YIHRlY2hub2xvZ3kgc3VwcG9ydGVk
KQoJCUZYU1IgKEZhc3QgZmxvYXRpbmctcG9pbnQgc2F2ZSBhbmQgcmVzdG9yZSkKCQlTU0UgKFN0
cmVhbWluZyBTSU1EIGV4dGVuc2lvbnMpCgkJU1NFMiAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9u
cyAyKQoJCVNTIChTZWxmLXNub29wKQoJCUhUVCAoSHlwZXItdGhyZWFkaW5nIHRlY2hub2xvZ3kp
CgkJVE0gKFRoZXJtYWwgbW9uaXRvciBzdXBwb3J0ZWQpCgkJUEJFIChQZW5kaW5nIGJyZWFrIGVu
YWJsZWQpCglWZXJzaW9uOiBHZW51aW5lIEludGVsKFIpIENQVSAgICAgICAgICAgQCAwMDAwIEAg
Mi40MEdIeiAgICAgCglWb2x0YWdlOiBVbmtub3duCglFeHRlcm5hbCBDbG9jazogMTMzIE1IegoJ
TWF4IFNwZWVkOiAyNDAwIE1IegoJQ3VycmVudCBTcGVlZDogMjQwMCBNSHoKCVN0YXR1czogUG9w
dWxhdGVkLCBFbmFibGVkCglVcGdyYWRlOiBPdGhlcgoJTDEgQ2FjaGUgSGFuZGxlOiAweDAwMDkK
CUwyIENhY2hlIEhhbmRsZTogMHgwMDBBCglMMyBDYWNoZSBIYW5kbGU6IDB4MDAwQgoJU2VyaWFs
IE51bWJlcjogVG8gQmUgRmlsbGVkIEJ5IE8uRS5NLgoJQXNzZXQgVGFnOiBUbyBCZSBGaWxsZWQg
QnkgTy5FLk0uCglQYXJ0IE51bWJlcjogVG8gQmUgRmlsbGVkIEJ5IE8uRS5NLgoJQ29yZSBDb3Vu
dDogNAoJQ29yZSBFbmFibGVkOiA0CglUaHJlYWQgQ291bnQ6IDgKCUNoYXJhY3RlcmlzdGljczoK
CQk2NC1iaXQgY2FwYWJsZQoKSGFuZGxlIDB4MDAwOSwgRE1JIHR5cGUgNywgMTkgYnl0ZXMKQ2Fj
aGUgSW5mb3JtYXRpb24KCVNvY2tldCBEZXNpZ25hdGlvbjogTDEtQ2FjaGUKCUNvbmZpZ3VyYXRp
b246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMQoJT3BlcmF0aW9uYWwgTW9kZTogV3Jp
dGUgVGhyb3VnaAoJTG9jYXRpb246IEludGVybmFsCglJbnN0YWxsZWQgU2l6ZTogMjU2IGtCCglN
YXhpbXVtIFNpemU6IDI1NiBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJT3RoZXIKCUluc3Rh
bGxlZCBTUkFNIFR5cGU6IE90aGVyCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVjdGlvbiBU
eXBlOiBQYXJpdHkKCVN5c3RlbSBUeXBlOiBJbnN0cnVjdGlvbgoJQXNzb2NpYXRpdml0eTogNC13
YXkgU2V0LWFzc29jaWF0aXZlCgpIYW5kbGUgMHgwMDBBLCBETUkgdHlwZSA3LCAxOSBieXRlcwpD
YWNoZSBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2lnbmF0aW9uOiBMMi1DYWNoZQoJQ29uZmlndXJh
dGlvbjogRW5hYmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAyCglPcGVyYXRpb25hbCBNb2RlOiBX
cml0ZSBUaHJvdWdoCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAxMDI0IGtC
CglNYXhpbXVtIFNpemU6IDEwMjQga0IKCVN1cHBvcnRlZCBTUkFNIFR5cGVzOgoJCU90aGVyCglJ
bnN0YWxsZWQgU1JBTSBUeXBlOiBPdGhlcgoJU3BlZWQ6IFVua25vd24KCUVycm9yIENvcnJlY3Rp
b24gVHlwZTogU2luZ2xlLWJpdCBFQ0MKCVN5c3RlbSBUeXBlOiBVbmlmaWVkCglBc3NvY2lhdGl2
aXR5OiA4LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMEIsIERNSSB0eXBlIDcsIDE5
IGJ5dGVzCkNhY2hlIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWduYXRpb246IEwzLUNhY2hlCglD
b25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDMKCU9wZXJhdGlvbmFs
IE1vZGU6IFdyaXRlIEJhY2sKCUxvY2F0aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6IDgx
OTIga0IKCU1heGltdW0gU2l6ZTogODE5MiBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJT3Ro
ZXIKCUluc3RhbGxlZCBTUkFNIFR5cGU6IE90aGVyCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29y
cmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJU3lzdGVtIFR5cGU6IFVuaWZpZWQKCUFzc29j
aWF0aXZpdHk6IDE2LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMEMsIERNSSB0eXBl
IDksIDE3IGJ5dGVzClN5c3RlbSBTbG90IEluZm9ybWF0aW9uCglEZXNpZ25hdGlvbjogUENJRTEK
CVR5cGU6IHgxNiBQQ0kgRXhwcmVzcwoJQ3VycmVudCBVc2FnZTogQXZhaWxhYmxlCglMZW5ndGg6
IExvbmcKCUlEOiAxCglDaGFyYWN0ZXJpc3RpY3M6CgkJMy4zIFYgaXMgcHJvdmlkZWQKCQlPcGVu
aW5nIGlzIHNoYXJlZAoJCVBNRSBzaWduYWwgaXMgc3VwcG9ydGVkCgpIYW5kbGUgMHgwMDBELCBE
TUkgdHlwZSAxMSwgNSBieXRlcwpPRU0gU3RyaW5ncwoJU3RyaW5nIDE6IFRvIEJlIEZpbGxlZCBC
eSBPLkUuTS4KCVN0cmluZyAyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uCgpIYW5kbGUgMHgwMDBF
LCBETUkgdHlwZSAxNSwgNTUgYnl0ZXMKU3lzdGVtIEV2ZW50IExvZwoJQXJlYSBMZW5ndGg6IDEw
MDggYnl0ZXMKCUhlYWRlciBTdGFydCBPZmZzZXQ6IDB4MDgxMAoJRGF0YSBTdGFydCBPZmZzZXQ6
IDB4MDgxMAoJQWNjZXNzIE1ldGhvZDogR2VuZXJhbC1wdXJwb3NlIG5vbi12b2xhdGlsZSBkYXRh
IGZ1bmN0aW9ucwoJQWNjZXNzIEFkZHJlc3M6IDB4MDAwMQoJU3RhdHVzOiBWYWxpZCwgTm90IEZ1
bGwKCUNoYW5nZSBUb2tlbjogMHgwMDAwMDAwMAoJSGVhZGVyIEZvcm1hdDogTm8gSGVhZGVyCglT
dXBwb3J0ZWQgTG9nIFR5cGUgRGVzY3JpcHRvcnM6IDE1CglEZXNjcmlwdG9yIDE6IFNpbmdsZS1i
aXQgRUNDIG1lbW9yeSBlcnJvcgoJRGF0YSBGb3JtYXQgMTogTXVsdGlwbGUtZXZlbnQgaGFuZGxl
CglEZXNjcmlwdG9yIDI6IE11bHRpLWJpdCBFQ0MgbWVtb3J5IGVycm9yCglEYXRhIEZvcm1hdCAy
OiBNdWx0aXBsZS1ldmVudCBoYW5kbGUKCURlc2NyaXB0b3IgMzogUGFyaXR5IG1lbW9yeSBlcnJv
cgoJRGF0YSBGb3JtYXQgMzogTXVsdGlwbGUtZXZlbnQKCURlc2NyaXB0b3IgNDogSS9PIGNoYW5u
ZWwgYmxvY2sKCURhdGEgRm9ybWF0IDQ6IE11bHRpcGxlLWV2ZW50CglEZXNjcmlwdG9yIDU6IFBP
U1QgZXJyb3IKCURhdGEgRm9ybWF0IDU6IFBPU1QgcmVzdWx0cyBiaXRtYXAKCURlc2NyaXB0b3Ig
NjogUENJIHBhcml0eSBlcnJvcgoJRGF0YSBGb3JtYXQgNjogTXVsdGlwbGUtZXZlbnQgaGFuZGxl
CglEZXNjcmlwdG9yIDc6IFBDSSBzeXN0ZW0gZXJyb3IKCURhdGEgRm9ybWF0IDc6IE11bHRpcGxl
LWV2ZW50IGhhbmRsZQoJRGVzY3JpcHRvciA4OiBTeXN0ZW0gbGltaXQgZXhjZWVkZWQKCURhdGEg
Rm9ybWF0IDg6IE11bHRpcGxlLWV2ZW50IHN5c3RlbSBtYW5hZ2VtZW50CglEZXNjcmlwdG9yIDk6
IE9FTS1zcGVjaWZpYwoJRGF0YSBGb3JtYXQgOTogUE9TVCByZXN1bHRzIGJpdG1hcAoJRGVzY3Jp
cHRvciAxMDogT0VNLXNwZWNpZmljCglEYXRhIEZvcm1hdCAxMDogTXVsdGlwbGUtZXZlbnQgaGFu
ZGxlCglEZXNjcmlwdG9yIDExOiBPRU0tc3BlY2lmaWMKCURhdGEgRm9ybWF0IDExOiBNdWx0aXBs
ZS1ldmVudCBoYW5kbGUKCURlc2NyaXB0b3IgMTI6IE9FTS1zcGVjaWZpYwoJRGF0YSBGb3JtYXQg
MTI6IE11bHRpcGxlLWV2ZW50IGhhbmRsZQoJRGVzY3JpcHRvciAxMzogT0VNLXNwZWNpZmljCglE
YXRhIEZvcm1hdCAxMzogTXVsdGlwbGUtZXZlbnQgaGFuZGxlCglEZXNjcmlwdG9yIDE0OiBPRU0t
c3BlY2lmaWMKCURhdGEgRm9ybWF0IDE0OiBNdWx0aXBsZS1ldmVudCBoYW5kbGUKCURlc2NyaXB0
b3IgMTU6IE9FTS1zcGVjaWZpYwoJRGF0YSBGb3JtYXQgMTU6IE11bHRpcGxlLWV2ZW50IGhhbmRs
ZQoKSGFuZGxlIDB4MDAwRiwgRE1JIHR5cGUgMTYsIDE1IGJ5dGVzClBoeXNpY2FsIE1lbW9yeSBB
cnJheQoJTG9jYXRpb246IFN5c3RlbSBCb2FyZCBPciBNb3RoZXJib2FyZAoJVXNlOiBTeXN0ZW0g
TWVtb3J5CglFcnJvciBDb3JyZWN0aW9uIFR5cGU6IE11bHRpLWJpdCBFQ0MKCU1heGltdW0gQ2Fw
YWNpdHk6IDM4NCBHQgoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxlOiBOb3QgUHJvdmlkZWQKCU51
bWJlciBPZiBEZXZpY2VzOiAxMgoKSGFuZGxlIDB4MDAxMCwgRE1JIHR5cGUgMTksIDE1IGJ5dGVz
Ck1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcwoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDAwMDAw
MDAwMAoJRW5kaW5nIEFkZHJlc3M6IDB4MDQ0NDNGRkZGRkYKCVJhbmdlIFNpemU6IDI3OTYxNiBN
QgoJUGh5c2ljYWwgQXJyYXkgSGFuZGxlOiAweDAwMEYKCVBhcnRpdGlvbiBXaWR0aDogMAoKSGFu
ZGxlIDB4MDAxMSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhh
bmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90
YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZv
cm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0xQQoJQmFuayBMb2Nh
dG9yOiBCQU5LMAoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBN
SHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAw
CglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAg
IAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAxMiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1l
bW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAw
MDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMTAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtC
CglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTEKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRk
cmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2
ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4
MDAxMywgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTog
MHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lk
dGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFj
dG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0xQgoJQmFuayBMb2NhdG9yOiBC
QU5LMQoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1h
bnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3Nl
dCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFu
azogVW5rbm93bgoKSGFuZGxlIDB4MDAxNCwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBE
ZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAxMDAwMDAwMDAKCUVu
ZGluZyBBZGRyZXNzOiAweDAwMjAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlz
aWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTMKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBI
YW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3Np
dGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxNSwg
RE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBG
CglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcy
IGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBE
SU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0yQQoJQmFuayBMb2NhdG9yOiBCQU5LMgoJ
VHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0
dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6
ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5r
bm93bgoKSGFuZGxlIDB4MDAxNiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2Ug
TWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAyMDAwMDAwMDAKCUVuZGluZyBB
ZGRyZXNzOiAweDAwMzAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBE
ZXZpY2UgSGFuZGxlOiAweDAwMTUKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6
IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjog
VW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxNywgRE1JIHR5
cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJv
ciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMK
CURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglT
ZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0yQgoJQmFuayBMb2NhdG9yOiBCQU5LMwoJVHlwZTog
RERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjog
ICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAg
ICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoK
SGFuZGxlIDB4MDAxOCwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVk
IEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAzMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNz
OiAweDAwNDAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZpY2Ug
SGFuZGxlOiAweDAwMTcKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAx
MAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93
bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxOSwgRE1JIHR5cGUgMTcs
IDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZv
cm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEg
V2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5v
bmUKCUxvY2F0b3I6IFAxLURJTU0zQQoJQmFuayBMb2NhdG9yOiBCQU5LNAoJVHlwZTogRERSMwoJ
VHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAg
ICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAg
IAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxl
IDB4MDAxQSwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJl
c3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDA0MDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAw
NTAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxl
OiAweDAwMTkKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFy
dGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50
ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxQiwgRE1JIHR5cGUgMTcsIDI4IGJ5
dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlv
biBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6
IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxv
Y2F0b3I6IFAxLURJTU0zQgoJQmFuayBMb2NhdG9yOiBCQU5LNQoJVHlwZTogRERSMwoJVHlwZSBE
ZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAg
ICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFy
dCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAx
QywgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0
YXJ0aW5nIEFkZHJlc3M6IDB4MDA1MDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwNjAwMDAw
M0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAw
MUIKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9u
IFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2
ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxRCwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1l
bW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5k
bGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJp
dHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6
IFAyLURJTU0xQQoJQmFuayBMb2NhdG9yOiBCQU5LNgoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6
IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNl
cmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1i
ZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAxRSwgRE1J
IHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5n
IEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGCglS
YW5nZSBTaXplOiAxIGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMUQKCU1lbW9yeSBB
cnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlv
bjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0
aDogMgoKSGFuZGxlIDB4MDAxRiwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UK
CUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92
aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQw
OTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0xQgoJ
QmFuayBMb2NhdG9yOiBCQU5LNwoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVl
ZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6
IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFM
RU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAyMCwgRE1JIHR5cGUgMjAsIDE5
IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4
MDAwMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGCglSYW5nZSBTaXplOiAx
IGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMUYKCU1lbW9yeSBBcnJheSBNYXBwZWQg
QWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJs
ZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxl
IDB4MDAyMSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRs
ZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwg
V2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0g
RmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0yQQoJQmFuayBMb2NhdG9y
OiBCQU5LOAoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoK
CU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglB
c3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJ
UmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAyMiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9y
eSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAK
CUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGCglSYW5nZSBTaXplOiAxIGtCCglQaHlzaWNh
bCBEZXZpY2UgSGFuZGxlOiAweDAwMjEKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5k
bGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlv
bjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAyMywgRE1J
IHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglF
cnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJp
dHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1N
CglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0yQgoJQmFuayBMb2NhdG9yOiBCQU5LOQoJVHlw
ZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJl
cjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAg
ICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93
bgoKSGFuZGxlIDB4MDAyNCwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFw
cGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDA2MDAwMDAwMDAKCUVuZGluZyBBZGRy
ZXNzOiAweDAwNzAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZp
Y2UgSGFuZGxlOiAweDAwMjMKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4
MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5r
bm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAyNSwgRE1JIHR5cGUg
MTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJ
bmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURh
dGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6
IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0zQQoJQmFuayBMb2NhdG9yOiBCQU5LMTAKCVR5cGU6IERE
UjMKCVR5cGUgRGV0YWlsOiBPdGhlcgoJU3BlZWQ6IDEwNjYgTUh6CglNYW51ZmFjdHVyZXI6ICAg
ICAgICAgICAgICAgCglTZXJpYWwgTnVtYmVyOiAwMDAwMDAwMAoJQXNzZXQgVGFnOiAgICAgICAg
ICAgICAgCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQwMiAgICAgCglSYW5rOiBVbmtub3duCgpI
YW5kbGUgMHgwMDI2LCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMKTWVtb3J5IERldmljZSBNYXBwZWQg
QWRkcmVzcwoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDcwMDAwMDAwMAoJRW5kaW5nIEFkZHJlc3M6
IDB4MDA4MDAwMDAzRkYKCVJhbmdlIFNpemU6IDQxOTQzMDUga0IKCVBoeXNpY2FsIERldmljZSBI
YW5kbGU6IDB4MDAyNQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEw
CglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxCglJbnRlcmxlYXZlIFBvc2l0aW9uOiBVbmtub3du
CglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAyCgpIYW5kbGUgMHgwMDI3LCBETUkgdHlwZSAxNywg
MjggYnl0ZXMKTWVtb3J5IERldmljZQoJQXJyYXkgSGFuZGxlOiAweDAwMEYKCUVycm9yIEluZm9y
bWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkCglUb3RhbCBXaWR0aDogNzIgYml0cwoJRGF0YSBX
aWR0aDogNjQgYml0cwoJU2l6ZTogNDA5NiBNQgoJRm9ybSBGYWN0b3I6IERJTU0KCVNldDogTm9u
ZQoJTG9jYXRvcjogUDItRElNTTNCCglCYW5rIExvY2F0b3I6IEJBTksxMQoJVHlwZTogRERSMwoJ
VHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAg
ICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAg
ICAKCVBhcnQgTnVtYmVyOiBTVVBFUlRBTEVOVDAyICAgICAKCVJhbms6IFVua25vd24KCkhhbmRs
ZSAweDAwMjgsIERNSSB0eXBlIDIwLCAxOSBieXRlcwpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRy
ZXNzCglTdGFydGluZyBBZGRyZXNzOiAweDAwODAwMDAwMDAwCglFbmRpbmcgQWRkcmVzczogMHgw
MDkwMDAwMDNGRgoJUmFuZ2UgU2l6ZTogNDE5NDMwNSBrQgoJUGh5c2ljYWwgRGV2aWNlIEhhbmRs
ZTogMHgwMDI3CglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMTAKCVBh
cnRpdGlvbiBSb3cgUG9zaXRpb246IDEKCUludGVybGVhdmUgUG9zaXRpb246IFVua25vd24KCUlu
dGVybGVhdmVkIERhdGEgRGVwdGg6IDIKCkhhbmRsZSAweDAwMjksIERNSSB0eXBlIDMyLCAyMCBi
eXRlcwpTeXN0ZW0gQm9vdCBJbmZvcm1hdGlvbgoJU3RhdHVzOiBObyBlcnJvcnMgZGV0ZWN0ZWQK
CkhhbmRsZSAweDAwMkEsIERNSSB0eXBlIDM4LCAxOCBieXRlcwpJUE1JIERldmljZSBJbmZvcm1h
dGlvbgoJSW50ZXJmYWNlIFR5cGU6IEtDUyAoS2V5Ym9hcmQgQ29udHJvbCBTdHlsZSkKCVNwZWNp
ZmljYXRpb24gVmVyc2lvbjogMi4wCglJMkMgU2xhdmUgQWRkcmVzczogMHgxMAoJTlYgU3RvcmFn
ZSBEZXZpY2U6IE5vdCBQcmVzZW50CglCYXNlIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAwMENBMiAo
SS9PKQoJUmVnaXN0ZXIgU3BhY2luZzogU3VjY2Vzc2l2ZSBCeXRlIEJvdW5kYXJpZXMKCkhhbmRs
ZSAweDAwMkIsIERNSSB0eXBlIDEyNywgNCBieXRlcwpFbmQgT2YgVGFibGUKCg==

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

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

--_002_4F2188768090606cacom_--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBt-0002ml-NT; Wed, 01 Feb 2012 10:13:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Leonid.Kalev@ca.com>) id 1RqSo9-00005z-Sn
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:08:22 +0000
X-Env-Sender: Leonid.Kalev@ca.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327597690!3791187!1
X-Originating-IP: [74.125.149.149]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27268 invoked from network); 26 Jan 2012 17:08:12 -0000
Received: from na3sys009aog123.obsmtp.com (HELO na3sys009aog123.obsmtp.com)
	(74.125.149.149)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 17:08:12 -0000
Received: from USILMS190.ca.com ([141.202.246.44]) (using TLSv1) by
	na3sys009aob123.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTyGIeZ7PlfGkFgzMmEeWOzhch6wByKnX@postini.com;
	Thu, 26 Jan 2012 09:08:12 PST
Received: from USILMS174.ca.com (141.202.6.24) by USILMS190.ca.com
	(141.202.246.44) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Thu, 26 Jan 2012 12:08:08 -0500
Received: from USILMS111A.ca.com ([169.254.3.121]) by usilms174.ca.com
	([141.202.6.24]) with mapi id 14.01.0355.002;
	Thu, 26 Jan 2012 12:08:08 -0500
From: "Kalev, Leonid" <Leonid.Kalev@ca.com>
To: xen-devel <xen-devel@lists.xensource.com>
Thread-Topic: Help needed debugging "EPT Misconfiguration" exception on
	Intel CPU
Thread-Index: AQHM3E0SU3wUxrG6pEq0yWH/vYcRvQ==
Date: Thu, 26 Jan 2012 17:08:07 +0000
Message-ID: <4F218876.8090606@ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24)
	Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
x-originating-ip: [81.218.169.161]
Content-Type: multipart/mixed; boundary="_002_4F2188768090606cacom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Subject: [Xen-devel] Help needed debugging "EPT Misconfiguration" exception
	on Intel CPU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_4F2188768090606cacom_
Content-Type: text/plain; charset="utf-8"
Content-ID: <677AA049BF78EE438FE88BCBCBB47015@ca.com>
Content-Transfer-Encoding: base64

KG5vdGUsIHBsZWFzZSBzZW5kIGEgY29weSBvZiByZXBsaWVzIHRvIG15IGUtbWFpbCwgSSBhbSBu
b3Qgc3Vic2NyaWJlZCB0byB0aGUgDQp4ZW4tZGV2ZWwgbGlzdCkNCg0KQmVmb3JlIEkgZ2V0IGlu
dG8gZGV0YWlscyBhYm91dCB0aGUgcHJvYmxlbTogSSB0cmllZCB0byBpZGVudGlmeSB0aGUgQ1BV
IGFzIHByZWNpc2VseSANCmFzIHBvc3NpYmxlIChpbiBjYXNlIHRoZXJlIGFyZSBrbm93biBwcm9i
bGVtcyB3aXRoIHRoZSBzcGVjaWZpYyBtb2RlbCksIGJ1dCB3aGF0IEkgDQpmb3VuZCBpbiB0aGUg
Q1BVIGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIChhcyByZXBvcnRlZCBieSB0aGUgJ2NwdWlk
JyBpbnN0cnVjdGlvbikgDQpzZWVtcyBzdHJhbmdlOiB1bmxpa2UgbW9zdCBJbnRlbCBDUFVzIHRo
YXQgcmVwb3J0IGEgc2Vuc2libGUgbW9kZWwgbmFtZSwgd2hpY2ggDQpnZW5lcmFsbHkgbWF0Y2hl
cyB0aGUgY29tbWVyY2lhbCBuYW1lIG9mIHRoZSBDUFUsIChlLmcuICJJbnRlbChSKSBDb3JlKFRN
KSBpNSBDUFUiKSwgDQpvbiB0aGUgc2VydmVyIHdoZXJlIEkgY2F1Z2h0IHRoZSBFUFQgZXhjZXB0
aW9uLCB0aGUgQ1BVIG1vZGVsIHN0cmluZyByZWFkczoNCiJHZW51aW5lIEludGVsKFIpIENQVSAg
ICAgICAgICAgQCAwMDAwIEAgMi40MEdIeiINCg0KVGhpcyBkb2VzIG5vdCBsb29rIGxpa2UgYW55
IENQVSB0aGF0IEludGVsIHNlbGxzLiBUaGUgZmFtaWx5LCBtb2RlbCBhbmQgc3RlcHBpbmcgDQpu
dW1iZXJzIGFyZSA2IDI2IGFuZCAyLCByZXNwZWN0aXZlbHkuIEkgZGlkIG5vdCBmaW5kIGFueSBy
ZWZlcmVuY2UgdG8gdGhpcyBwYXJ0aWN1bGFyIA0KY29tYmluYXRpb24gb2YgbW9kZWwgSUQgbnVt
YmVycywgZXhjZXB0IGluIGp1c3Qgb25lIG9yIHR3byBmb3J1bSBwb3N0cyBvbiB0aGUgV2ViLCAN
CnJlZmVycmluZyB0byB0aGUgc2FtZSBub24tZGVzY3JpcHQgbW9kZWwgc3RyaW5nIHF1b3RlZCBh
Ym92ZS4gT25lIG9mIHRoZSBwb3N0cyBldmVuIA0Kc3VnZ2VzdGVkIHRoYXQgdGhpcyBtaWdodCBi
ZSBhIG5vbi1wcm9kdWN0aW9uIENQVSBjaGlwOiANCmh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlz
dHMva3ZtL21zZzU4MjU4Lmh0bWwNCg0KTm93LCB0byB0aGUgcHJvYmxlbSBpdHNlbGY6DQphdHRl
bXB0aW5nIHRvIHN0YXJ0IGEgaGFyZHdhcmUtYXNzaXN0ZWQgdmlydHVhbCBtYWNoaW5lIChIVk0p
IG9uIFhFTiA0LjEuMSBjYXVzZXMgdGhlIA0KZ3Vlc3QgVk0gdG8gY3Jhc2ggaW5zdGFudGx5IG9u
IHN0YXJ0dXAuIFRoZSBjcmFzaCBpcyBjYXVzZWQgYnkgYSBWTSBleGl0IHRoYXQgaXMgbm90IA0K
aGFuZGxlZCBieSBYRU4gKGFuZCB3aGljaCBjYW5ub3QgYmUgaGFuZGxlZCBpbiBhbnkgd2F5IG90
aGVyIHRoYW4gZGVzdHJveWluZyB0aGUgDQpndWVzdCBWTSk6IHRoZSBWTSBleGl0IHJlYXNvbiBp
cyA0OSAoMHgzMSksIHdoaWNoIGlzICJFUFQgTWlzY29uZmlndXJhdGlvbiIuDQoNCkFjY29yZGlu
ZyB0byB0aGUgSW50ZWwgU29mdHdhcmUgRGV2ZWxvcGVyIE1hbnVhbCAoVm9sIDNCLCBDaGFwdGVy
IDI1IC0gVk1YIFNVUFBPUlQgDQpGT1IgQUREUkVTUyBUUkFOU0xBVElPTiksIHRoaXMgVk0gZXhp
dCBtZWFucyB0aGF0IGFuIGludmFsaWQgdmFsdWUgd2FzIGZvdW5kIGluIHRoZSANCmV4dGVuZGVk
IHBhZ2UgdGFibGVzLiBTdXNwZWN0aW5nIGEgc29mdHdhcmUgcHJvYmxlbSwgSSBtb2RpZmllZCB0
aGUgWEVOIGh5cGVydmlzb3IgdG8gDQpwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYXMg
Zm9sbG93czoNCi0gcmVhZCBhbmQgZGlzcGxheSB0aGUgdmFsdWUgb2YgdGhlIEVQVFAgVk0gY29u
dHJvbCBmaWVsZA0KLSByZWFkIGFuZCBkaXNwbGF5IHRoZSB2YWx1ZSBvZiB0aGUgIkd1ZXN0LXBo
eXNpY2FsIGFkZHJlc3MiIGNvbnRyb2wgZmllbGQgKEdQQSkNCi0gdXNlIHRoZSBndWVzdC1waHlz
aWNhbCBhZGRyZXNzIHZhbHVlIHRvIHRyYXZlcnNlIHRoZSBFUFQgc3RydWN0dXJlcyBhbmQgZGlz
cGxheQ0KICAgIGFsbCA0IGxldmVscyBvZiBwYWdlIHRhYmxlIGVudHJpZXMgdGhhdCBwZXJ0YWlu
IHRvIHRoZSBHUEEgcmVwb3J0ZWQgYnkgdGhlIENQVS4NCg0KSSB3YXMgbm90IGFibGUgdG8gZmlu
ZCBhbnkgZXJyb3IgaW4gdGhlIEVQVFAgdmFsdWUsIG5vciBpbiB0aGUgRVBUIHRhYmxlIGVudHJp
ZXMsIA0KdGhleSBhbGwgc2VlbSB0byBiZSB2YWxpZC4gQmVsb3csIEkgYW0gaW5jbHVkaW5nOg0K
LSB0aGUgZGVidWcgaW5mb3JtYXRpb24gZGlzcGxheWVkIGJ5IFhFTiAod2l0aCB0aGUgYWRkaXRp
b25hbCBpbnN0cnVtZW50YXRpb24NCiAgICB0aGF0IEkgYWRkZWQpLCB3aXRoIHNvbWUgYml0LWZp
ZWxkIGFuYWx5c2lzIHRoYXQgSSBkaWQgbWFudWFsbHkgKHNob3dpbmcgbm8NCiAgICBwcm9ibGVt
cyBpbiB0aGUgRVBUIGVudHJpZXMpDQotIHRoZSBDUFUgaW5mb3JtYXRpb24gKHhtIGluZm8gYW5k
IC9wcm9jL2NwdWluZm8pDQotIG1lbW9yeSBtYXAgZnJvbSBCSU9TDQoNCkFsc28sIHRoZSBkZXRh
aWxlZCBETUkgaW5mbyBmcm9tIEJJT1MgaXMgYXR0YWNoZWQgYXMgYSB0ZXh0IGZpbGUgKGl0IGRv
ZXNuJ3Qgc2hvdyANCmFueXRoaW5nIGRpZmZlcmVudCBhYm91dCB0aGUgQ1BVLCB0aG91Z2gpLg0K
DQo9PT09PT09PT09PT09IFhFTiBjb25zb2xlIGxvZywgd2l0aCBjb21tZW50cyBmcm9tIG1lID09
PT09PT09PT09PT09PT09PT09PT09PT09DQooWEVOKSBFUFQgTWlzY29uZmlndXJhdGlvbiwgZ3Bh
PTAwMDAwMDAwZmVmZmUwMDANCihYRU4pIGRvbWFpbi0+Li4uLT5lcHRwICAgPSAweDQzMWIzZDAx
ZQ0KKFhFTikgdm1yZWFkKEVQVF9QT0lOVEVSKSA9IDB4NDMxYjNkMDFlDQoNCiAgICBFUFRQIGJp
dHM6DQogICAgMC0yICAgPSA2OyBtZW0gdHlwZSAoMCA9IFVDLCA2PVdCLCBhbGwgb3RoZXIgPSBp
bnZhbGlkKQ0KICAgIDUtMyAgID0gMyAoc2hvdWxkIGJlID0gMyAod2FsayBsZW5ndGggLSAxKSkN
CiAgICA2LTExICA9IDAgcmVzZXJ2ZWQNCiAgICAxMi0zOSA9IDB4NDMxYjNkOyBhZGRyIG9mIEVQ
VCBQTUw0DQogICAgNDAtNjQgPSAwIDsgcmVzZXJ2ZWQgKDQwIGlzIHRoZSBhZGRyIHN6IG9mIHRo
ZSBDUFUgaGVyZSwgbWF5IHZhcnkgb24gb3RoZXIgQ1BVcywgDQptYXg9NDgpDQoNCihYRU4pIHAy
bS1lcHQuYzo2NDk6ZDMgV2Fsa2luZyBFUFQgdGFibGVzIGZvciBkb21haW4gMyBnZm4gZmVmZmUN
CihYRU4pIHAybS1lcHQuYzo2Njg6ZDMgIGVwdGUgMWMwMDAwMDQzMWIzYzAwNw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC0yID0gNzogYWNjZXNzIGFs
bG93ZWQ6IHJ3eA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMy03ID0gMDogcmVzZXJ2ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIDgtMTEgPSAw
OiBpZ25vcmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4LTEyID0gNDMxYjNjOiBhZGRyZXNzIG9mIG5leHQgbGV2ZWwgRVBUDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICA1MS14IC0gMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgNTItNjMg
LSBpZ25vcmVkDQooWEVOKSBwMm0tZXB0LmM6NjY4OmQzICBlcHRlIDFjMDAwMDA0Mzc0ZmIwMDcN
CihYRU4pIHAybS1lcHQuYzo2Njg6ZDMgIGVwdGUgMWMwMDAwMDQzNzRmYTAwNw0KKFhFTikgcDJt
LWVwdC5jOjY2ODpkMyAgZXB0ZSAxYzEwMDAwYzIxM2VlMDM3IDAtMiA9IDc6IHJ3eA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTAwMDAwMDAwMDAgKG5iOiBhZGRyIHNpemUg
bGltaXQgLSA0MCBiaXRzIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHRoaXMgQ1BVLCB3ZSdyZSB3YXkgYmVsb3cpDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzLTUgPSA2OiB0eXBlICgwID0gVUM7IDEg
PSBXQzsgNCA9IFdUOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgNSA9IFdQOyA2ID0gV0IpDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICA2ICAgPSAwOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgNy0xMSA9MDogKGlnbm9yZWQp
DQogICAgICAgICAgICAgICAgICAgICAgICAgICBtZm49YzIxM2VlLCAobG9va3MgdmFsaWQsIG1l
bSBleHRlbmRzIGZyb20gMTAwMDAwIHRvIA0KYzQwMDAwLCBzZWUgbWVtIG1hcCBiZWxvdykNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDUyPTE7ICA1Mi02MyBzaG91bGQgYmUgaWdub3JlZA0K
DQooWEVOKSBkb21haW5fY3Jhc2ggY2FsbGVkIGZyb20gdm14LmM6MjY1MA0KKFhFTikgRG9tYWlu
IDMgKHZjcHUjMCkgY3Jhc2hlZCBvbiBjcHUjMTU6DQooWEVOKSAtLS0tWyBYZW4tNC4xLjEgIHg4
Nl82NCAgZGVidWc9biAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIENQVTogICAgMTUNCihYRU4p
IFJJUDogICAgMDAwMDpbPDAwMDAwMDAwMDAwMDAwMDA+XQ0KKFhFTikgUkZMQUdTOiAwMDAwMDAw
MDAwMDEwMDAyICAgQ09OVEVYVDogaHZtIGd1ZXN0DQooWEVOKSByYXg6IDAwMDAwMDAwMDAwMDAw
MDEgICByYng6IDAwMDAwMDAwMDAwMDAwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4p
IHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJzaTogMDAwMDAwMDAwMDAwMDAwMCAgIHJkaTogMDAw
MDAwMDAwMDAwMDAwMA0KKFhFTikgcmJwOiAwMDAwMDAwMDAwMDAwMDAwICAgcnNwOiAwMDAwMDAw
MDAwMDAwMDAwICAgcjg6ICAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSByOTogIDAwMDAwMDAwMDAw
MDAwMDAgICByMTA6IDAwMDAwMDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAwMDAwMDANCihY
RU4pIHIxMjogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDog
MDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAwMDAw
MDAwMDAwMDAwMDExICAgY3I0OiAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBjcjM6IDAwMDAwMDAw
MDAwMDAwMDAgICBjcjI6IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIGRzOiAwMDAwICAgZXM6IDAw
MDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAgICBjczogMDAwMA0KDQogICAgICBD
UjAgPSAweDEwID0gUEUrRVQNCiAgICAgIFJGTEFHUyA9IFJGICsgMiAoMiBpcyBhbHdheXMgc2V0
KQ0KDQo9PT09PT09PT09PT09IHN5c3RlbSBpbmZvIGZyb20gWEVOID09PT09PT09PT09PT09PT09
PT09PT09PT09PT0NCiMgeG0gaW5mbw0KaG9zdCAgICAgICAgICAgICAgICAgICA6IDN0ZXJhLXNy
djENCnJlbGVhc2UgICAgICAgICAgICAgICAgOiAzLjAuNC00MC54ZW4wDQp2ZXJzaW9uICAgICAg
ICAgICAgICAgIDogIzEgU01QIFdlZCBEZWMgMTQgMTk6NDg6MDMgRVNUIDIwMTENCm1hY2hpbmUg
ICAgICAgICAgICAgICAgOiBpNjg2DQpucl9jcHVzICAgICAgICAgICAgICAgIDogMTYNCm5yX25v
ZGVzICAgICAgICAgICAgICAgOiAyDQpjb3Jlc19wZXJfc29ja2V0ICAgICAgIDogNA0KdGhyZWFk
c19wZXJfY29yZSAgICAgICA6IDINCmNwdV9taHogICAgICAgICAgICAgICAgOiAyNDAwDQpod19j
YXBzICAgICAgICAgICAgICAgIDogDQpiZmViZmJmZjoyODEwMDgwMDowMDAwMDAwMDowMDAwM2I0
MDowMGJjZTNiZDowMDAwMDAwMDowMDAwMDAwMTowMDAwMDAwMA0KdmlydF9jYXBzICAgICAgICAg
ICAgICA6IGh2bQ0KdG90YWxfbWVtb3J5ICAgICAgICAgICA6IDQ5MTQyDQpmcmVlX21lbW9yeSAg
ICAgICAgICAgIDogNDc0ODcNCmZyZWVfY3B1cyAgICAgICAgICAgICAgOiAwDQp4ZW5fbWFqb3Ig
ICAgICAgICAgICAgIDogNA0KeGVuX21pbm9yICAgICAgICAgICAgICA6IDENCnhlbl9leHRyYSAg
ICAgICAgICAgICAgOiAuMQ0KeGVuX2NhcHMgICAgICAgICAgICAgICA6IHhlbi0zLjAteDg2XzY0
IHhlbi0zLjAteDg2XzMycCBodm0tMy4wLXg4Nl8zMiANCmh2bS0zLjAteDg2XzMycCBodm0tMy4w
LXg4Nl82NA0KeGVuX3NjaGVkdWxlciAgICAgICAgICA6IGNyZWRpdA0KeGVuX3BhZ2VzaXplICAg
ICAgICAgICA6IDQwOTYNCnBsYXRmb3JtX3BhcmFtcyAgICAgICAgOiB2aXJ0X3N0YXJ0PTB4ZmNj
MDAwMDANCnhlbl9jaGFuZ2VzZXQgICAgICAgICAgOiB1bmF2YWlsYWJsZQ0KeGVuX2NvbW1hbmRs
aW5lICAgICAgICA6IG5vaHQgaW9tbXU9b2ZmIGRvbTBfdmNwdXNfcGluIGRvbTBfbWF4X3ZjcHVz
PTEgZG9tMF9tZW09Nzg2NDMyDQpjY19jb21waWxlciAgICAgICAgICAgIDogZ2NjIHZlcnNpb24g
NC4xLjEgMjAwNzAxMDUgKFJlZCBIYXQgNC4xLjEtNTIpDQpjY19jb21waWxlX2J5ICAgICAgICAg
IDogM3RlcmENCmNjX2NvbXBpbGVfZG9tYWluICAgICAgOiAobm9uZSkNCmNjX2NvbXBpbGVfZGF0
ZSAgICAgICAgOiBNb24gSmFuIDIzIDA2OjExOjQ3IFBTVCAyMDEyDQp4ZW5kX2NvbmZpZ19mb3Jt
YXQgICAgIDogNA0KDQo9PT09PT09PT09PT09IENQVSBpbmZvICgvcHJvYy9jcHVpbmZvLCBmcm9t
IERvbTAgLSBmbGFncyBhcmUgZmlsdGVyZWQgYnkgWEVOKQ0KIyBjYXQgL3Byb2MvY3B1aW5mbw0K
cHJvY2Vzc29yICAgIDogMA0KdmVuZG9yX2lkICAgIDogR2VudWluZUludGVsDQpjcHUgZmFtaWx5
ICAgIDogNg0KbW9kZWwgICAgICAgIDogMjYNCm1vZGVsIG5hbWUgICAgOiBHZW51aW5lIEludGVs
KFIpIENQVSAgICAgICAgICAgQCAwMDAwIEAgMi40MEdIeg0Kc3RlcHBpbmcgICAgOiAyDQpjcHUg
TUh6ICAgICAgICA6IDI0MDAuMTEyDQpjYWNoZSBzaXplICAgIDogODE5MiBLQg0KcGh5c2ljYWwg
aWQgICAgOiAwDQpzaWJsaW5ncyAgICA6IDENCmNvcmUgaWQgICAgICAgIDogMA0KY3B1IGNvcmVz
ICAgIDogMQ0KYXBpY2lkICAgICAgICA6IDANCmluaXRpYWwgYXBpY2lkICAgIDogMA0KZmRpdl9i
dWcgICAgOiBubw0KaGx0X2J1ZyAgICAgICAgOiBubw0KZjAwZl9idWcgICAgOiBubw0KY29tYV9i
dWcgICAgOiBubw0KZnB1ICAgICAgICA6IHllcw0KZnB1X2V4Y2VwdGlvbiAgICA6IHllcw0KY3B1
aWQgbGV2ZWwgICAgOiAxMQ0Kd3AgICAgICAgIDogeWVzDQpmbGFncyAgICAgICAgOiBmcHUgZGUg
dHNjIG1zciBwYWUgY3g4IGFwaWMgc2VwIGNtb3YgcGF0IGNsZmx1c2ggYWNwaSBtbXggZnhzciBz
c2UgDQpzc2UyIHNzIGh0IG54IGxtIGNvbnN0YW50X3RzYyB1cCBub25zdG9wX3RzYyBhcGVyZm1w
ZXJmIHBuaSBlc3Qgc3NzZTMgc3NlNF8xIHNzZTRfMiANCngyYXBpYyBwb3BjbnQgaHlwZXJ2aXNv
ciBpZGEgZHRzDQpib2dvbWlwcyAgICA6IDQ4MDAuMjINCmNsZmx1c2ggc2l6ZSAgICA6IDY0DQpj
YWNoZV9hbGlnbm1lbnQgICAgOiA2NA0KYWRkcmVzcyBzaXplcyAgICA6IDQwIGJpdHMgcGh5c2lj
YWwsIDQ4IGJpdHMgdmlydHVhbA0KcG93ZXIgbWFuYWdlbWVudDoNCg0KPT09PT09PT09PT09PSBC
SU9TIG1lbW9yeSBtYXAsIGFzIHNob3duIGJ5IFhFTiBvbiBib290ID09PT09PT09PT09PT09PT09
PT09PT09PT09DQooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAw
MDAgLSAwMDAwMDAwMDAwMDljYzAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5Y2MwMCAt
IDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTYwMDAgLSAw
MDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAw
MDAwMDBiZjc2MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYmY3NmUwMDAgLSAwMDAwMDAw
MGJmNzcwMDAwIHR5cGUgOQ0KKFhFTikgIDAwMDAwMDAwYmY3NzAwMDAgLSAwMDAwMDAwMGJmNzdl
MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBiZjc3ZTAwMCAtIDAwMDAwMDAwYmY3ZDAw
MDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYmY3ZDAwMDAgLSAwMDAwMDAwMGJmN2UwMDAw
IChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGJmN2VjMDAwIC0gMDAwMDAwMDBjMDAwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgKHJl
c2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNl
cnZlZCkNCihYRU4pICAwMDAwMDAwMGZmYzAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2
ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDBjNDAwMDAwMDAgKHVzYWJsZSkN
Cg0KLS0gDQpMZW9uaWQgS2FsZXYNCkNBIFRlY2hub2xvZ2llcw0KUHJpbmNpcGFsIFNvZnR3YXJl
IEVuZ2luZWVyDQpUZWw6ICAgICArOTcyIDQgODI1IDM5NTINCk1vYmlsZTogICs5NzIgNTQgNDYz
MTUwOA0KTGVvbmlkLkthbGV2QGNhLmNvbQ0KDQoNCmRtaWRlY29kZS1lcHRmYWlsDQoNCiMgZG1p
ZGVjb2RlIDIuMTANClNNQklPUyAyLjYgcHJlc2VudC4NCjQ0IHN0cnVjdHVyZXMgb2NjdXB5aW5n
IDI1NDkgYnl0ZXMuDQpUYWJsZSBhdCAweDAwMDlFQzAwLg0KDQpIYW5kbGUgMHgwMDAwLCBETUkg
dHlwZSAwLCAyNCBieXRlcw0KQklPUyBJbmZvcm1hdGlvbg0KCVZlbmRvcjogQW1lcmljYW4gTWVn
YXRyZW5kcyBJbmMuDQoJVmVyc2lvbjogMDgwMDE2DQoJUmVsZWFzZSBEYXRlOiAwMi8xMS8yMDEx
DQoJQWRkcmVzczogMHhGMDAwMA0KCVJ1bnRpbWUgU2l6ZTogNjQga0INCglST00gU2l6ZTogNDA5
NiBrQg0KCUNoYXJhY3RlcmlzdGljczoNCgkJSVNBIGlzIHN1cHBvcnRlZA0KCQlQQ0kgaXMgc3Vw
cG9ydGVkDQoJCVBOUCBpcyBzdXBwb3J0ZWQNCgkJQklPUyBpcyB1cGdyYWRlYWJsZQ0KCQlCSU9T
IHNoYWRvd2luZyBpcyBhbGxvd2VkDQoJCUVTQ0Qgc3VwcG9ydCBpcyBhdmFpbGFibGUNCgkJQm9v
dCBmcm9tIENEIGlzIHN1cHBvcnRlZA0KCQlTZWxlY3RhYmxlIGJvb3QgaXMgc3VwcG9ydGVkDQoJ
CUJJT1MgUk9NIGlzIHNvY2tldGVkDQoJCUVERCBpcyBzdXBwb3J0ZWQNCgkJNS4yNSIvMS4yIE1C
IGZsb3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQ0KCQkzLjUiLzcyMCBrQiBm
bG9wcHkgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEzaCkNCgkJMy41Ii8yLjg4IE1CIGZs
b3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQ0KCQlQcmludCBzY3JlZW4gc2Vy
dmljZSBpcyBzdXBwb3J0ZWQgKGludCA1aCkNCgkJODA0MiBrZXlib2FyZCBzZXJ2aWNlcyBhcmUg
c3VwcG9ydGVkIChpbnQgOWgpDQoJCVNlcmlhbCBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQg
MTRoKQ0KCQlQcmludGVyIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAxN2gpDQoJCUNHQS9t
b25vIHZpZGVvIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAxMGgpDQoJCUFDUEkgaXMgc3Vw
cG9ydGVkDQoJCVVTQiBsZWdhY3kgaXMgc3VwcG9ydGVkDQoJCUxTLTEyMCBib290IGlzIHN1cHBv
cnRlZA0KCQlBVEFQSSBaaXAgZHJpdmUgYm9vdCBpcyBzdXBwb3J0ZWQNCgkJQklPUyBib290IHNw
ZWNpZmljYXRpb24gaXMgc3VwcG9ydGVkDQoJCVRhcmdldGVkIGNvbnRlbnQgZGlzdHJpYnV0aW9u
IGlzIHN1cHBvcnRlZA0KCUJJT1MgUmV2aXNpb246IDguMTYNCg0KSGFuZGxlIDB4MDAwMSwgRE1J
IHR5cGUgMSwgMjcgYnl0ZXMNClN5c3RlbSBJbmZvcm1hdGlvbg0KCU1hbnVmYWN0dXJlcjogU3Vw
ZXJtaWNybw0KCVByb2R1Y3QgTmFtZTogWDhEVFQtSA0KCVZlcnNpb246IDEyMzQ1Njc4OTANCglT
ZXJpYWwgTnVtYmVyOiAxMjM0NTY3ODkwDQoJVVVJRDogNTQ0NDM4NTgtNEU1NC0zMDAwLTQ4RjQt
MDAzMDQ4RjQxNzcwDQoJV2FrZS11cCBUeXBlOiBQb3dlciBTd2l0Y2gNCglTS1UgTnVtYmVyOiAx
MjM0NTY3ODkwDQoJRmFtaWx5OiBTZXJ2ZXINCg0KSGFuZGxlIDB4MDAwMiwgRE1JIHR5cGUgMiwg
MTUgYnl0ZXMNCkJhc2UgQm9hcmQgSW5mb3JtYXRpb24NCglNYW51ZmFjdHVyZXI6IFN1cGVybWlj
cm8NCglQcm9kdWN0IE5hbWU6IFg4RFRULUgNCglWZXJzaW9uOiAxLjMNCglTZXJpYWwgTnVtYmVy
OiAxMjM0NTY3ODkwDQoJQXNzZXQgVGFnOiAxMjM0NTY3ODkwDQoJRmVhdHVyZXM6DQoJCUJvYXJk
IGlzIGEgaG9zdGluZyBib2FyZA0KCQlCb2FyZCBpcyByZXBsYWNlYWJsZQ0KCUxvY2F0aW9uIElu
IENoYXNzaXM6IDEyMzQ1Njc4OTANCglDaGFzc2lzIEhhbmRsZTogMHgwMDAzDQoJVHlwZTogTW90
aGVyYm9hcmQNCglDb250YWluZWQgT2JqZWN0IEhhbmRsZXM6IDANCg0KSGFuZGxlIDB4MDAwMywg
RE1JIHR5cGUgMywgMjEgYnl0ZXMNCkNoYXNzaXMgSW5mb3JtYXRpb24NCglNYW51ZmFjdHVyZXI6
IFN1cGVybWljcm8NCglUeXBlOiBNYWluIFNlcnZlciBDaGFzc2lzDQoJTG9jazogTm90IFByZXNl
bnQNCglWZXJzaW9uOiAxMjM0NTY3ODkwDQoJU2VyaWFsIE51bWJlcjogMTIzNDU2Nzg5MC4NCglB
c3NldCBUYWc6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglCb290LXVwIFN0YXRlOiBTYWZlDQoJ
UG93ZXIgU3VwcGx5IFN0YXRlOiBTYWZlDQoJVGhlcm1hbCBTdGF0ZTogU2FmZQ0KCVNlY3VyaXR5
IFN0YXR1czogTm9uZQ0KCU9FTSBJbmZvcm1hdGlvbjogMHgwMDAwMDAwMA0KCUhlaWdodDogVW5z
cGVjaWZpZWQNCglOdW1iZXIgT2YgUG93ZXIgQ29yZHM6IDENCglDb250YWluZWQgRWxlbWVudHM6
IDANCg0KSGFuZGxlIDB4MDAwNCwgRE1JIHR5cGUgNCwgNDIgYnl0ZXMNClByb2Nlc3NvciBJbmZv
cm1hdGlvbg0KCVNvY2tldCBEZXNpZ25hdGlvbjogQ1BVIDENCglUeXBlOiBDZW50cmFsIFByb2Nl
c3Nvcg0KCUZhbWlseTogWGVvbg0KCU1hbnVmYWN0dXJlcjogSW50ZWwNCglJRDogQTIgMDYgMDEg
MDAgRkYgRkIgRUIgQkYNCglTaWduYXR1cmU6IFR5cGUgMCwgRmFtaWx5IDYsIE1vZGVsIDI2LCBT
dGVwcGluZyAyDQoJRmxhZ3M6DQoJCUZQVSAoRmxvYXRpbmctcG9pbnQgdW5pdCBvbi1jaGlwKQ0K
CQlWTUUgKFZpcnR1YWwgbW9kZSBleHRlbnNpb24pDQoJCURFIChEZWJ1Z2dpbmcgZXh0ZW5zaW9u
KQ0KCQlQU0UgKFBhZ2Ugc2l6ZSBleHRlbnNpb24pDQoJCVRTQyAoVGltZSBzdGFtcCBjb3VudGVy
KQ0KCQlNU1IgKE1vZGVsIHNwZWNpZmljIHJlZ2lzdGVycykNCgkJUEFFIChQaHlzaWNhbCBhZGRy
ZXNzIGV4dGVuc2lvbikNCgkJTUNFIChNYWNoaW5lIGNoZWNrIGV4Y2VwdGlvbikNCgkJQ1g4IChD
TVBYQ0hHOCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpDQoJCUFQSUMgKE9uLWNoaXAgQVBJQyBoYXJk
d2FyZSBzdXBwb3J0ZWQpDQoJCVNFUCAoRmFzdCBzeXN0ZW0gY2FsbCkNCgkJTVRSUiAoTWVtb3J5
IHR5cGUgcmFuZ2UgcmVnaXN0ZXJzKQ0KCQlQR0UgKFBhZ2UgZ2xvYmFsIGVuYWJsZSkNCgkJTUNB
IChNYWNoaW5lIGNoZWNrIGFyY2hpdGVjdHVyZSkNCgkJQ01PViAoQ29uZGl0aW9uYWwgbW92ZSBp
bnN0cnVjdGlvbiBzdXBwb3J0ZWQpDQoJCVBBVCAoUGFnZSBhdHRyaWJ1dGUgdGFibGUpDQoJCVBT
RS0zNiAoMzYtYml0IHBhZ2Ugc2l6ZSBleHRlbnNpb24pDQoJCUNMRlNIIChDTEZMVVNIIGluc3Ry
dWN0aW9uIHN1cHBvcnRlZCkNCgkJRFMgKERlYnVnIHN0b3JlKQ0KCQlBQ1BJIChBQ1BJIHN1cHBv
cnRlZCkNCgkJTU1YIChNTVggdGVjaG5vbG9neSBzdXBwb3J0ZWQpDQoJCUZYU1IgKEZhc3QgZmxv
YXRpbmctcG9pbnQgc2F2ZSBhbmQgcmVzdG9yZSkNCgkJU1NFIChTdHJlYW1pbmcgU0lNRCBleHRl
bnNpb25zKQ0KCQlTU0UyIChTdHJlYW1pbmcgU0lNRCBleHRlbnNpb25zIDIpDQoJCVNTIChTZWxm
LXNub29wKQ0KCQlIVFQgKEh5cGVyLXRocmVhZGluZyB0ZWNobm9sb2d5KQ0KCQlUTSAoVGhlcm1h
bCBtb25pdG9yIHN1cHBvcnRlZCkNCgkJUEJFIChQZW5kaW5nIGJyZWFrIGVuYWJsZWQpDQoJVmVy
c2lvbjogR2VudWluZSBJbnRlbChSKSBDUFUgICAgICAgICAgIEAgMDAwMCBAIDIuNDBHSHoNCglW
b2x0YWdlOiBVbmtub3duDQoJRXh0ZXJuYWwgQ2xvY2s6IDEzMyBNSHoNCglNYXggU3BlZWQ6IDI0
MDAgTUh6DQoJQ3VycmVudCBTcGVlZDogMjQwMCBNSHoNCglTdGF0dXM6IFBvcHVsYXRlZCwgRW5h
YmxlZA0KCVVwZ3JhZGU6IE90aGVyDQoJTDEgQ2FjaGUgSGFuZGxlOiAweDAwMDUNCglMMiBDYWNo
ZSBIYW5kbGU6IDB4MDAwNg0KCUwzIENhY2hlIEhhbmRsZTogMHgwMDA3DQoJU2VyaWFsIE51bWJl
cjogVG8gQmUgRmlsbGVkIEJ5IE8uRS5NLg0KCUFzc2V0IFRhZzogVG8gQmUgRmlsbGVkIEJ5IE8u
RS5NLg0KCVBhcnQgTnVtYmVyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uDQoJQ29yZSBDb3VudDog
NA0KCUNvcmUgRW5hYmxlZDogNA0KCVRocmVhZCBDb3VudDogOA0KCUNoYXJhY3RlcmlzdGljczoN
CgkJNjQtYml0IGNhcGFibGUNCg0KSGFuZGxlIDB4MDAwNSwgRE1JIHR5cGUgNywgMTkgYnl0ZXMN
CkNhY2hlIEluZm9ybWF0aW9uDQoJU29ja2V0IERlc2lnbmF0aW9uOiBMMS1DYWNoZQ0KCUNvbmZp
Z3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMQ0KCU9wZXJhdGlvbmFsIE1v
ZGU6IFdyaXRlIFRocm91Z2gNCglMb2NhdGlvbjogSW50ZXJuYWwNCglJbnN0YWxsZWQgU2l6ZTog
MjU2IGtCDQoJTWF4aW11bSBTaXplOiAyNTYga0INCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoNCgkJ
T3RoZXINCglJbnN0YWxsZWQgU1JBTSBUeXBlOiBPdGhlcg0KCVNwZWVkOiBVbmtub3duDQoJRXJy
b3IgQ29ycmVjdGlvbiBUeXBlOiBQYXJpdHkNCglTeXN0ZW0gVHlwZTogSW5zdHJ1Y3Rpb24NCglB
c3NvY2lhdGl2aXR5OiA0LXdheSBTZXQtYXNzb2NpYXRpdmUNCg0KSGFuZGxlIDB4MDAwNiwgRE1J
IHR5cGUgNywgMTkgYnl0ZXMNCkNhY2hlIEluZm9ybWF0aW9uDQoJU29ja2V0IERlc2lnbmF0aW9u
OiBMMi1DYWNoZQ0KCUNvbmZpZ3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwg
Mg0KCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIFRocm91Z2gNCglMb2NhdGlvbjogSW50ZXJuYWwN
CglJbnN0YWxsZWQgU2l6ZTogMTAyNCBrQg0KCU1heGltdW0gU2l6ZTogMTAyNCBrQg0KCVN1cHBv
cnRlZCBTUkFNIFR5cGVzOg0KCQlPdGhlcg0KCUluc3RhbGxlZCBTUkFNIFR5cGU6IE90aGVyDQoJ
U3BlZWQ6IFVua25vd24NCglFcnJvciBDb3JyZWN0aW9uIFR5cGU6IFNpbmdsZS1iaXQgRUNDDQoJ
U3lzdGVtIFR5cGU6IFVuaWZpZWQNCglBc3NvY2lhdGl2aXR5OiA4LXdheSBTZXQtYXNzb2NpYXRp
dmUNCg0KSGFuZGxlIDB4MDAwNywgRE1JIHR5cGUgNywgMTkgYnl0ZXMNCkNhY2hlIEluZm9ybWF0
aW9uDQoJU29ja2V0IERlc2lnbmF0aW9uOiBMMy1DYWNoZQ0KCUNvbmZpZ3VyYXRpb246IEVuYWJs
ZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMw0KCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIEJhY2sN
CglMb2NhdGlvbjogSW50ZXJuYWwNCglJbnN0YWxsZWQgU2l6ZTogODE5MiBrQg0KCU1heGltdW0g
U2l6ZTogODE5MiBrQg0KCVN1cHBvcnRlZCBTUkFNIFR5cGVzOg0KCQlPdGhlcg0KCUluc3RhbGxl
ZCBTUkFNIFR5cGU6IE90aGVyDQoJU3BlZWQ6IFVua25vd24NCglFcnJvciBDb3JyZWN0aW9uIFR5
cGU6IFNpbmdsZS1iaXQgRUNDDQoJU3lzdGVtIFR5cGU6IFVuaWZpZWQNCglBc3NvY2lhdGl2aXR5
OiAxNi13YXkgU2V0LWFzc29jaWF0aXZlDQoNCkhhbmRsZSAweDAwMDgsIERNSSB0eXBlIDQsIDQy
IGJ5dGVzDQpQcm9jZXNzb3IgSW5mb3JtYXRpb24NCglTb2NrZXQgRGVzaWduYXRpb246IENQVSAy
DQoJVHlwZTogQ2VudHJhbCBQcm9jZXNzb3INCglGYW1pbHk6IFhlb24NCglNYW51ZmFjdHVyZXI6
IEludGVsDQoJSUQ6IEEyIDA2IDAxIDAwIEZGIEZCIEVCIEJGDQoJU2lnbmF0dXJlOiBUeXBlIDAs
IEZhbWlseSA2LCBNb2RlbCAyNiwgU3RlcHBpbmcgMg0KCUZsYWdzOg0KCQlGUFUgKEZsb2F0aW5n
LXBvaW50IHVuaXQgb24tY2hpcCkNCgkJVk1FIChWaXJ0dWFsIG1vZGUgZXh0ZW5zaW9uKQ0KCQlE
RSAoRGVidWdnaW5nIGV4dGVuc2lvbikNCgkJUFNFIChQYWdlIHNpemUgZXh0ZW5zaW9uKQ0KCQlU
U0MgKFRpbWUgc3RhbXAgY291bnRlcikNCgkJTVNSIChNb2RlbCBzcGVjaWZpYyByZWdpc3RlcnMp
DQoJCVBBRSAoUGh5c2ljYWwgYWRkcmVzcyBleHRlbnNpb24pDQoJCU1DRSAoTWFjaGluZSBjaGVj
ayBleGNlcHRpb24pDQoJCUNYOCAoQ01QWENIRzggaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQ0KCQlB
UElDIChPbi1jaGlwIEFQSUMgaGFyZHdhcmUgc3VwcG9ydGVkKQ0KCQlTRVAgKEZhc3Qgc3lzdGVt
IGNhbGwpDQoJCU1UUlIgKE1lbW9yeSB0eXBlIHJhbmdlIHJlZ2lzdGVycykNCgkJUEdFIChQYWdl
IGdsb2JhbCBlbmFibGUpDQoJCU1DQSAoTWFjaGluZSBjaGVjayBhcmNoaXRlY3R1cmUpDQoJCUNN
T1YgKENvbmRpdGlvbmFsIG1vdmUgaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQ0KCQlQQVQgKFBhZ2Ug
YXR0cmlidXRlIHRhYmxlKQ0KCQlQU0UtMzYgKDM2LWJpdCBwYWdlIHNpemUgZXh0ZW5zaW9uKQ0K
CQlDTEZTSCAoQ0xGTFVTSCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpDQoJCURTIChEZWJ1ZyBzdG9y
ZSkNCgkJQUNQSSAoQUNQSSBzdXBwb3J0ZWQpDQoJCU1NWCAoTU1YIHRlY2hub2xvZ3kgc3VwcG9y
dGVkKQ0KCQlGWFNSIChGYXN0IGZsb2F0aW5nLXBvaW50IHNhdmUgYW5kIHJlc3RvcmUpDQoJCVNT
RSAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9ucykNCgkJU1NFMiAoU3RyZWFtaW5nIFNJTUQgZXh0
ZW5zaW9ucyAyKQ0KCQlTUyAoU2VsZi1zbm9vcCkNCgkJSFRUIChIeXBlci10aHJlYWRpbmcgdGVj
aG5vbG9neSkNCgkJVE0gKFRoZXJtYWwgbW9uaXRvciBzdXBwb3J0ZWQpDQoJCVBCRSAoUGVuZGlu
ZyBicmVhayBlbmFibGVkKQ0KCVZlcnNpb246IEdlbnVpbmUgSW50ZWwoUikgQ1BVICAgICAgICAg
ICBAIDAwMDAgQCAyLjQwR0h6DQoJVm9sdGFnZTogVW5rbm93bg0KCUV4dGVybmFsIENsb2NrOiAx
MzMgTUh6DQoJTWF4IFNwZWVkOiAyNDAwIE1Ieg0KCUN1cnJlbnQgU3BlZWQ6IDI0MDAgTUh6DQoJ
U3RhdHVzOiBQb3B1bGF0ZWQsIEVuYWJsZWQNCglVcGdyYWRlOiBPdGhlcg0KCUwxIENhY2hlIEhh
bmRsZTogMHgwMDA5DQoJTDIgQ2FjaGUgSGFuZGxlOiAweDAwMEENCglMMyBDYWNoZSBIYW5kbGU6
IDB4MDAwQg0KCVNlcmlhbCBOdW1iZXI6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglBc3NldCBU
YWc6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglQYXJ0IE51bWJlcjogVG8gQmUgRmlsbGVkIEJ5
IE8uRS5NLg0KCUNvcmUgQ291bnQ6IDQNCglDb3JlIEVuYWJsZWQ6IDQNCglUaHJlYWQgQ291bnQ6
IDgNCglDaGFyYWN0ZXJpc3RpY3M6DQoJCTY0LWJpdCBjYXBhYmxlDQoNCkhhbmRsZSAweDAwMDks
IERNSSB0eXBlIDcsIDE5IGJ5dGVzDQpDYWNoZSBJbmZvcm1hdGlvbg0KCVNvY2tldCBEZXNpZ25h
dGlvbjogTDEtQ2FjaGUNCglDb25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExl
dmVsIDENCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBUaHJvdWdoDQoJTG9jYXRpb246IEludGVy
bmFsDQoJSW5zdGFsbGVkIFNpemU6IDI1NiBrQg0KCU1heGltdW0gU2l6ZTogMjU2IGtCDQoJU3Vw
cG9ydGVkIFNSQU0gVHlwZXM6DQoJCU90aGVyDQoJSW5zdGFsbGVkIFNSQU0gVHlwZTogT3RoZXIN
CglTcGVlZDogVW5rbm93bg0KCUVycm9yIENvcnJlY3Rpb24gVHlwZTogUGFyaXR5DQoJU3lzdGVt
IFR5cGU6IEluc3RydWN0aW9uDQoJQXNzb2NpYXRpdml0eTogNC13YXkgU2V0LWFzc29jaWF0aXZl
DQoNCkhhbmRsZSAweDAwMEEsIERNSSB0eXBlIDcsIDE5IGJ5dGVzDQpDYWNoZSBJbmZvcm1hdGlv
bg0KCVNvY2tldCBEZXNpZ25hdGlvbjogTDItQ2FjaGUNCglDb25maWd1cmF0aW9uOiBFbmFibGVk
LCBOb3QgU29ja2V0ZWQsIExldmVsIDINCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBUaHJvdWdo
DQoJTG9jYXRpb246IEludGVybmFsDQoJSW5zdGFsbGVkIFNpemU6IDEwMjQga0INCglNYXhpbXVt
IFNpemU6IDEwMjQga0INCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoNCgkJT3RoZXINCglJbnN0YWxs
ZWQgU1JBTSBUeXBlOiBPdGhlcg0KCVNwZWVkOiBVbmtub3duDQoJRXJyb3IgQ29ycmVjdGlvbiBU
eXBlOiBTaW5nbGUtYml0IEVDQw0KCVN5c3RlbSBUeXBlOiBVbmlmaWVkDQoJQXNzb2NpYXRpdml0
eTogOC13YXkgU2V0LWFzc29jaWF0aXZlDQoNCkhhbmRsZSAweDAwMEIsIERNSSB0eXBlIDcsIDE5
IGJ5dGVzDQpDYWNoZSBJbmZvcm1hdGlvbg0KCVNvY2tldCBEZXNpZ25hdGlvbjogTDMtQ2FjaGUN
CglDb25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDMNCglPcGVyYXRp
b25hbCBNb2RlOiBXcml0ZSBCYWNrDQoJTG9jYXRpb246IEludGVybmFsDQoJSW5zdGFsbGVkIFNp
emU6IDgxOTIga0INCglNYXhpbXVtIFNpemU6IDgxOTIga0INCglTdXBwb3J0ZWQgU1JBTSBUeXBl
czoNCgkJT3RoZXINCglJbnN0YWxsZWQgU1JBTSBUeXBlOiBPdGhlcg0KCVNwZWVkOiBVbmtub3du
DQoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQw0KCVN5c3RlbSBUeXBlOiBV
bmlmaWVkDQoJQXNzb2NpYXRpdml0eTogMTYtd2F5IFNldC1hc3NvY2lhdGl2ZQ0KDQpIYW5kbGUg
MHgwMDBDLCBETUkgdHlwZSA5LCAxNyBieXRlcw0KU3lzdGVtIFNsb3QgSW5mb3JtYXRpb24NCglE
ZXNpZ25hdGlvbjogUENJRTENCglUeXBlOiB4MTYgUENJIEV4cHJlc3MNCglDdXJyZW50IFVzYWdl
OiBBdmFpbGFibGUNCglMZW5ndGg6IExvbmcNCglJRDogMQ0KCUNoYXJhY3RlcmlzdGljczoNCgkJ
My4zIFYgaXMgcHJvdmlkZWQNCgkJT3BlbmluZyBpcyBzaGFyZWQNCgkJUE1FIHNpZ25hbCBpcyBz
dXBwb3J0ZWQNCg0KSGFuZGxlIDB4MDAwRCwgRE1JIHR5cGUgMTEsIDUgYnl0ZXMNCk9FTSBTdHJp
bmdzDQoJU3RyaW5nIDE6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4NCglTdHJpbmcgMjogVG8gQmUg
RmlsbGVkIEJ5IE8uRS5NLg0KDQpIYW5kbGUgMHgwMDBFLCBETUkgdHlwZSAxNSwgNTUgYnl0ZXMN
ClN5c3RlbSBFdmVudCBMb2cNCglBcmVhIExlbmd0aDogMTAwOCBieXRlcw0KCUhlYWRlciBTdGFy
dCBPZmZzZXQ6IDB4MDgxMA0KCURhdGEgU3RhcnQgT2Zmc2V0OiAweDA4MTANCglBY2Nlc3MgTWV0
aG9kOiBHZW5lcmFsLXB1cnBvc2Ugbm9uLXZvbGF0aWxlIGRhdGEgZnVuY3Rpb25zDQoJQWNjZXNz
IEFkZHJlc3M6IDB4MDAwMQ0KCVN0YXR1czogVmFsaWQsIE5vdCBGdWxsDQoJQ2hhbmdlIFRva2Vu
OiAweDAwMDAwMDAwDQoJSGVhZGVyIEZvcm1hdDogTm8gSGVhZGVyDQoJU3VwcG9ydGVkIExvZyBU
eXBlIERlc2NyaXB0b3JzOiAxNQ0KCURlc2NyaXB0b3IgMTogU2luZ2xlLWJpdCBFQ0MgbWVtb3J5
IGVycm9yDQoJRGF0YSBGb3JtYXQgMTogTXVsdGlwbGUtZXZlbnQgaGFuZGxlDQoJRGVzY3JpcHRv
ciAyOiBNdWx0aS1iaXQgRUNDIG1lbW9yeSBlcnJvcg0KCURhdGEgRm9ybWF0IDI6IE11bHRpcGxl
LWV2ZW50IGhhbmRsZQ0KCURlc2NyaXB0b3IgMzogUGFyaXR5IG1lbW9yeSBlcnJvcg0KCURhdGEg
Rm9ybWF0IDM6IE11bHRpcGxlLWV2ZW50DQoJRGVzY3JpcHRvciA0OiBJL08gY2hhbm5lbCBibG9j
aw0KCURhdGEgRm9ybWF0IDQ6IE11bHRpcGxlLWV2ZW50DQoJRGVzY3JpcHRvciA1OiBQT1NUIGVy
cm9yDQoJRGF0YSBGb3JtYXQgNTogUE9TVCByZXN1bHRzIGJpdG1hcA0KCURlc2NyaXB0b3IgNjog
UENJIHBhcml0eSBlcnJvcg0KCURhdGEgRm9ybWF0IDY6IE11bHRpcGxlLWV2ZW50IGhhbmRsZQ0K
CURlc2NyaXB0b3IgNzogUENJIHN5c3RlbSBlcnJvcg0KCURhdGEgRm9ybWF0IDc6IE11bHRpcGxl
LWV2ZW50IGhhbmRsZQ0KCURlc2NyaXB0b3IgODogU3lzdGVtIGxpbWl0IGV4Y2VlZGVkDQoJRGF0
YSBGb3JtYXQgODogTXVsdGlwbGUtZXZlbnQgc3lzdGVtIG1hbmFnZW1lbnQNCglEZXNjcmlwdG9y
IDk6IE9FTS1zcGVjaWZpYw0KCURhdGEgRm9ybWF0IDk6IFBPU1QgcmVzdWx0cyBiaXRtYXANCglE
ZXNjcmlwdG9yIDEwOiBPRU0tc3BlY2lmaWMNCglEYXRhIEZvcm1hdCAxMDogTXVsdGlwbGUtZXZl
bnQgaGFuZGxlDQoJRGVzY3JpcHRvciAxMTogT0VNLXNwZWNpZmljDQoJRGF0YSBGb3JtYXQgMTE6
IE11bHRpcGxlLWV2ZW50IGhhbmRsZQ0KCURlc2NyaXB0b3IgMTI6IE9FTS1zcGVjaWZpYw0KCURh
dGEgRm9ybWF0IDEyOiBNdWx0aXBsZS1ldmVudCBoYW5kbGUNCglEZXNjcmlwdG9yIDEzOiBPRU0t
c3BlY2lmaWMNCglEYXRhIEZvcm1hdCAxMzogTXVsdGlwbGUtZXZlbnQgaGFuZGxlDQoJRGVzY3Jp
cHRvciAxNDogT0VNLXNwZWNpZmljDQoJRGF0YSBGb3JtYXQgMTQ6IE11bHRpcGxlLWV2ZW50IGhh
bmRsZQ0KCURlc2NyaXB0b3IgMTU6IE9FTS1zcGVjaWZpYw0KCURhdGEgRm9ybWF0IDE1OiBNdWx0
aXBsZS1ldmVudCBoYW5kbGUNCg0KSGFuZGxlIDB4MDAwRiwgRE1JIHR5cGUgMTYsIDE1IGJ5dGVz
DQpQaHlzaWNhbCBNZW1vcnkgQXJyYXkNCglMb2NhdGlvbjogU3lzdGVtIEJvYXJkIE9yIE1vdGhl
cmJvYXJkDQoJVXNlOiBTeXN0ZW0gTWVtb3J5DQoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBNdWx0
aS1iaXQgRUNDDQoJTWF4aW11bSBDYXBhY2l0eTogMzg0IEdCDQoJRXJyb3IgSW5mb3JtYXRpb24g
SGFuZGxlOiBOb3QgUHJvdmlkZWQNCglOdW1iZXIgT2YgRGV2aWNlczogMTINCg0KSGFuZGxlIDB4
MDAxMCwgRE1JIHR5cGUgMTksIDE1IGJ5dGVzDQpNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MN
CglTdGFydGluZyBBZGRyZXNzOiAweDAwMDAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4MDQ0
NDNGRkZGRkYNCglSYW5nZSBTaXplOiAyNzk2MTYgTUINCglQaHlzaWNhbCBBcnJheSBIYW5kbGU6
IDB4MDAwRg0KCVBhcnRpdGlvbiBXaWR0aDogMA0KDQpIYW5kbGUgMHgwMDExLCBETUkgdHlwZSAx
NywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJheSBIYW5kbGU6IDB4MDAwRg0KCUVycm9y
IEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6IDcyIGJpdHMN
CglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFjdG9yOiBESU1N
DQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDEtRElNTTFBDQoJQmFuayBMb2NhdG9yOiBCQU5LMA0K
CVR5cGU6IEREUjMNCglUeXBlIERldGFpbDogT3RoZXINCglTcGVlZDogMTA2NiBNSHoNCglNYW51
ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJlcjogMDAwMDAwMDANCglBc3NldCBUYWc6DQoJUGFydCBO
dW1iZXI6IFNVUEVSVEFMRU5UMDINCglSYW5rOiBVbmtub3duDQoNCkhhbmRsZSAweDAwMTIsIERN
SSB0eXBlIDIwLCAxOSBieXRlcw0KTWVtb3J5IERldmljZSBNYXBwZWQgQWRkcmVzcw0KCVN0YXJ0
aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDANCglFbmRpbmcgQWRkcmVzczogMHgwMDEwMDAwMDNG
Rg0KCVJhbmdlIFNpemU6IDQxOTQzMDUga0INCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAw
MTENCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMTANCglQYXJ0aXRp
b24gUm93IFBvc2l0aW9uOiAxDQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bg0KCUludGVy
bGVhdmVkIERhdGEgRGVwdGg6IDINCg0KSGFuZGxlIDB4MDAxMywgRE1JIHR5cGUgMTcsIDI4IGJ5
dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJyYXkgSGFuZGxlOiAweDAwMEYNCglFcnJvciBJbmZvcm1h
dGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZA0KCVRvdGFsIFdpZHRoOiA3MiBiaXRzDQoJRGF0YSBX
aWR0aDogNjQgYml0cw0KCVNpemU6IDQwOTYgTUINCglGb3JtIEZhY3RvcjogRElNTQ0KCVNldDog
Tm9uZQ0KCUxvY2F0b3I6IFAxLURJTU0xQg0KCUJhbmsgTG9jYXRvcjogQkFOSzENCglUeXBlOiBE
RFIzDQoJVHlwZSBEZXRhaWw6IE90aGVyDQoJU3BlZWQ6IDEwNjYgTUh6DQoJTWFudWZhY3R1cmVy
Og0KCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwDQoJQXNzZXQgVGFnOg0KCVBhcnQgTnVtYmVyOiBT
VVBFUlRBTEVOVDAyDQoJUmFuazogVW5rbm93bg0KDQpIYW5kbGUgMHgwMDE0LCBETUkgdHlwZSAy
MCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MNCglTdGFydGluZyBBZGRy
ZXNzOiAweDAwMTAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4MDAyMDAwMDAzRkYNCglSYW5n
ZSBTaXplOiA0MTk0MzA1IGtCDQoJUGh5c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDEzDQoJTWVt
b3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEwDQoJUGFydGl0aW9uIFJvdyBQ
b3NpdGlvbjogMQ0KCUludGVybGVhdmUgUG9zaXRpb246IFVua25vd24NCglJbnRlcmxlYXZlZCBE
YXRhIERlcHRoOiAyDQoNCkhhbmRsZSAweDAwMTUsIERNSSB0eXBlIDE3LCAyOCBieXRlcw0KTWVt
b3J5IERldmljZQ0KCUFycmF5IEhhbmRsZTogMHgwMDBGDQoJRXJyb3IgSW5mb3JtYXRpb24gSGFu
ZGxlOiBOb3QgUHJvdmlkZWQNCglUb3RhbCBXaWR0aDogNzIgYml0cw0KCURhdGEgV2lkdGg6IDY0
IGJpdHMNCglTaXplOiA0MDk2IE1CDQoJRm9ybSBGYWN0b3I6IERJTU0NCglTZXQ6IE5vbmUNCglM
b2NhdG9yOiBQMS1ESU1NMkENCglCYW5rIExvY2F0b3I6IEJBTksyDQoJVHlwZTogRERSMw0KCVR5
cGUgRGV0YWlsOiBPdGhlcg0KCVNwZWVkOiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJp
YWwgTnVtYmVyOiAwMDAwMDAwMA0KCUFzc2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxF
TlQwMg0KCVJhbms6IFVua25vd24NCg0KSGFuZGxlIDB4MDAxNiwgRE1JIHR5cGUgMjAsIDE5IGJ5
dGVzDQpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgw
MDIwMDAwMDAwMA0KCUVuZGluZyBBZGRyZXNzOiAweDAwMzAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTog
NDE5NDMwNSBrQg0KCVBoeXNpY2FsIERldmljZSBIYW5kbGU6IDB4MDAxNQ0KCU1lbW9yeSBBcnJh
eSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246
IDENCglJbnRlcmxlYXZlIFBvc2l0aW9uOiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0
aDogMg0KDQpIYW5kbGUgMHgwMDE3LCBETUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZp
Y2UNCglBcnJheSBIYW5kbGU6IDB4MDAwRg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90
IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJ
U2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFjdG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjog
UDEtRElNTTJCDQoJQmFuayBMb2NhdG9yOiBCQU5LMw0KCVR5cGU6IEREUjMNCglUeXBlIERldGFp
bDogT3RoZXINCglTcGVlZDogMTA2NiBNSHoNCglNYW51ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJl
cjogMDAwMDAwMDANCglBc3NldCBUYWc6DQoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDINCglS
YW5rOiBVbmtub3duDQoNCkhhbmRsZSAweDAwMTgsIERNSSB0eXBlIDIwLCAxOSBieXRlcw0KTWVt
b3J5IERldmljZSBNYXBwZWQgQWRkcmVzcw0KCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAzMDAwMDAw
MDANCglFbmRpbmcgQWRkcmVzczogMHgwMDQwMDAwMDNGRg0KCVJhbmdlIFNpemU6IDQxOTQzMDUg
a0INCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTcNCglNZW1vcnkgQXJyYXkgTWFwcGVk
IEFkZHJlc3MgSGFuZGxlOiAweDAwMTANCglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxDQoJSW50
ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bg0KCUludGVybGVhdmVkIERhdGEgRGVwdGg6IDINCg0K
SGFuZGxlIDB4MDAxOSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJy
YXkgSGFuZGxlOiAweDAwMEYNCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRl
ZA0KCVRvdGFsIFdpZHRoOiA3MiBiaXRzDQoJRGF0YSBXaWR0aDogNjQgYml0cw0KCVNpemU6IDQw
OTYgTUINCglGb3JtIEZhY3RvcjogRElNTQ0KCVNldDogTm9uZQ0KCUxvY2F0b3I6IFAxLURJTU0z
QQ0KCUJhbmsgTG9jYXRvcjogQkFOSzQNCglUeXBlOiBERFIzDQoJVHlwZSBEZXRhaWw6IE90aGVy
DQoJU3BlZWQ6IDEwNjYgTUh6DQoJTWFudWZhY3R1cmVyOg0KCVNlcmlhbCBOdW1iZXI6IDAwMDAw
MDAwDQoJQXNzZXQgVGFnOg0KCVBhcnQgTnVtYmVyOiBTVVBFUlRBTEVOVDAyDQoJUmFuazogVW5r
bm93bg0KDQpIYW5kbGUgMHgwMDFBLCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZp
Y2UgTWFwcGVkIEFkZHJlc3MNCglTdGFydGluZyBBZGRyZXNzOiAweDAwNDAwMDAwMDAwDQoJRW5k
aW5nIEFkZHJlc3M6IDB4MDA1MDAwMDAzRkYNCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCDQoJUGh5
c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDE5DQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNz
IEhhbmRsZTogMHgwMDEwDQoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQ0KCUludGVybGVhdmUg
UG9zaXRpb246IFVua25vd24NCglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAyDQoNCkhhbmRsZSAw
eDAwMUIsIERNSSB0eXBlIDE3LCAyOCBieXRlcw0KTWVtb3J5IERldmljZQ0KCUFycmF5IEhhbmRs
ZTogMHgwMDBGDQoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxlOiBOb3QgUHJvdmlkZWQNCglUb3Rh
bCBXaWR0aDogNzIgYml0cw0KCURhdGEgV2lkdGg6IDY0IGJpdHMNCglTaXplOiA0MDk2IE1CDQoJ
Rm9ybSBGYWN0b3I6IERJTU0NCglTZXQ6IE5vbmUNCglMb2NhdG9yOiBQMS1ESU1NM0INCglCYW5r
IExvY2F0b3I6IEJBTks1DQoJVHlwZTogRERSMw0KCVR5cGUgRGV0YWlsOiBPdGhlcg0KCVNwZWVk
OiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJpYWwgTnVtYmVyOiAwMDAwMDAwMA0KCUFz
c2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQwMg0KCVJhbms6IFVua25vd24NCg0K
SGFuZGxlIDB4MDAxQywgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzDQpNZW1vcnkgRGV2aWNlIE1hcHBl
ZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDUwMDAwMDAwMA0KCUVuZGluZyBBZGRy
ZXNzOiAweDAwNjAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTogNDE5NDMwNSBrQg0KCVBoeXNpY2FsIERl
dmljZSBIYW5kbGU6IDB4MDAxQg0KCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6
IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDENCglJbnRlcmxlYXZlIFBvc2l0aW9u
OiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMg0KDQpIYW5kbGUgMHgwMDFELCBE
TUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJheSBIYW5kbGU6IDB4MDAw
Rg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6
IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFj
dG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDItRElNTTFBDQoJQmFuayBMb2NhdG9y
OiBCQU5LNg0KCVR5cGU6IEREUjMNCglUeXBlIERldGFpbDogT3RoZXINCglTcGVlZDogMTA2NiBN
SHoNCglNYW51ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJlcjogMDAwMDAwMDANCglBc3NldCBUYWc6
DQoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDINCglSYW5rOiBVbmtub3duDQoNCkhhbmRsZSAw
eDAwMUUsIERNSSB0eXBlIDIwLCAxOSBieXRlcw0KTWVtb3J5IERldmljZSBNYXBwZWQgQWRkcmVz
cw0KCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDANCglFbmRpbmcgQWRkcmVzczogMHgw
MDAwMDAwMDNGRg0KCVJhbmdlIFNpemU6IDEga0INCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAw
eDAwMUQNCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMTANCglQYXJ0
aXRpb24gUm93IFBvc2l0aW9uOiAxDQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bg0KCUlu
dGVybGVhdmVkIERhdGEgRGVwdGg6IDINCg0KSGFuZGxlIDB4MDAxRiwgRE1JIHR5cGUgMTcsIDI4
IGJ5dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJyYXkgSGFuZGxlOiAweDAwMEYNCglFcnJvciBJbmZv
cm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZA0KCVRvdGFsIFdpZHRoOiA3MiBiaXRzDQoJRGF0
YSBXaWR0aDogNjQgYml0cw0KCVNpemU6IDQwOTYgTUINCglGb3JtIEZhY3RvcjogRElNTQ0KCVNl
dDogTm9uZQ0KCUxvY2F0b3I6IFAyLURJTU0xQg0KCUJhbmsgTG9jYXRvcjogQkFOSzcNCglUeXBl
OiBERFIzDQoJVHlwZSBEZXRhaWw6IE90aGVyDQoJU3BlZWQ6IDEwNjYgTUh6DQoJTWFudWZhY3R1
cmVyOg0KCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwDQoJQXNzZXQgVGFnOg0KCVBhcnQgTnVtYmVy
OiBTVVBFUlRBTEVOVDAyDQoJUmFuazogVW5rbm93bg0KDQpIYW5kbGUgMHgwMDIwLCBETUkgdHlw
ZSAyMCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MNCglTdGFydGluZyBB
ZGRyZXNzOiAweDAwMDAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAzRkYNCglS
YW5nZSBTaXplOiAxIGtCDQoJUGh5c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDFGDQoJTWVtb3J5
IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEwDQoJUGFydGl0aW9uIFJvdyBQb3Np
dGlvbjogMQ0KCUludGVybGVhdmUgUG9zaXRpb246IFVua25vd24NCglJbnRlcmxlYXZlZCBEYXRh
IERlcHRoOiAyDQoNCkhhbmRsZSAweDAwMjEsIERNSSB0eXBlIDE3LCAyOCBieXRlcw0KTWVtb3J5
IERldmljZQ0KCUFycmF5IEhhbmRsZTogMHgwMDBGDQoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxl
OiBOb3QgUHJvdmlkZWQNCglUb3RhbCBXaWR0aDogNzIgYml0cw0KCURhdGEgV2lkdGg6IDY0IGJp
dHMNCglTaXplOiA0MDk2IE1CDQoJRm9ybSBGYWN0b3I6IERJTU0NCglTZXQ6IE5vbmUNCglMb2Nh
dG9yOiBQMi1ESU1NMkENCglCYW5rIExvY2F0b3I6IEJBTks4DQoJVHlwZTogRERSMw0KCVR5cGUg
RGV0YWlsOiBPdGhlcg0KCVNwZWVkOiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJpYWwg
TnVtYmVyOiAwMDAwMDAwMA0KCUFzc2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQw
Mg0KCVJhbms6IFVua25vd24NCg0KSGFuZGxlIDB4MDAyMiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVz
DQpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDAw
MDAwMDAwMA0KCUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTogMSBr
Qg0KCVBoeXNpY2FsIERldmljZSBIYW5kbGU6IDB4MDAyMQ0KCU1lbW9yeSBBcnJheSBNYXBwZWQg
QWRkcmVzcyBIYW5kbGU6IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDENCglJbnRl
cmxlYXZlIFBvc2l0aW9uOiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMg0KDQpI
YW5kbGUgMHgwMDIzLCBETUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJh
eSBIYW5kbGU6IDB4MDAwRg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVk
DQoJVG90YWwgV2lkdGg6IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5
NiBNQg0KCUZvcm0gRmFjdG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDItRElNTTJC
DQoJQmFuayBMb2NhdG9yOiBCQU5LOQ0KCVR5cGU6IEREUjMNCglUeXBlIERldGFpbDogT3RoZXIN
CglTcGVlZDogMTA2NiBNSHoNCglNYW51ZmFjdHVyZXI6DQoJU2VyaWFsIE51bWJlcjogMDAwMDAw
MDANCglBc3NldCBUYWc6DQoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDINCglSYW5rOiBVbmtu
b3duDQoNCkhhbmRsZSAweDAwMjQsIERNSSB0eXBlIDIwLCAxOSBieXRlcw0KTWVtb3J5IERldmlj
ZSBNYXBwZWQgQWRkcmVzcw0KCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDA2MDAwMDAwMDANCglFbmRp
bmcgQWRkcmVzczogMHgwMDcwMDAwMDNGRg0KCVJhbmdlIFNpemU6IDQxOTQzMDUga0INCglQaHlz
aWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMjMNCglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3Mg
SGFuZGxlOiAweDAwMTANCglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxDQoJSW50ZXJsZWF2ZSBQ
b3NpdGlvbjogVW5rbm93bg0KCUludGVybGVhdmVkIERhdGEgRGVwdGg6IDINCg0KSGFuZGxlIDB4
MDAyNSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzDQpNZW1vcnkgRGV2aWNlDQoJQXJyYXkgSGFuZGxl
OiAweDAwMEYNCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZA0KCVRvdGFs
IFdpZHRoOiA3MiBiaXRzDQoJRGF0YSBXaWR0aDogNjQgYml0cw0KCVNpemU6IDQwOTYgTUINCglG
b3JtIEZhY3RvcjogRElNTQ0KCVNldDogTm9uZQ0KCUxvY2F0b3I6IFAyLURJTU0zQQ0KCUJhbmsg
TG9jYXRvcjogQkFOSzEwDQoJVHlwZTogRERSMw0KCVR5cGUgRGV0YWlsOiBPdGhlcg0KCVNwZWVk
OiAxMDY2IE1Ieg0KCU1hbnVmYWN0dXJlcjoNCglTZXJpYWwgTnVtYmVyOiAwMDAwMDAwMA0KCUFz
c2V0IFRhZzoNCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQwMg0KCVJhbms6IFVua25vd24NCg0K
SGFuZGxlIDB4MDAyNiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzDQpNZW1vcnkgRGV2aWNlIE1hcHBl
ZCBBZGRyZXNzDQoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDcwMDAwMDAwMA0KCUVuZGluZyBBZGRy
ZXNzOiAweDAwODAwMDAwM0ZGDQoJUmFuZ2UgU2l6ZTogNDE5NDMwNSBrQg0KCVBoeXNpY2FsIERl
dmljZSBIYW5kbGU6IDB4MDAyNQ0KCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6
IDB4MDAxMA0KCVBhcnRpdGlvbiBSb3cgUG9zaXRpb246IDENCglJbnRlcmxlYXZlIFBvc2l0aW9u
OiBVbmtub3duDQoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMg0KDQpIYW5kbGUgMHgwMDI3LCBE
TUkgdHlwZSAxNywgMjggYnl0ZXMNCk1lbW9yeSBEZXZpY2UNCglBcnJheSBIYW5kbGU6IDB4MDAw
Rg0KCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkDQoJVG90YWwgV2lkdGg6
IDcyIGJpdHMNCglEYXRhIFdpZHRoOiA2NCBiaXRzDQoJU2l6ZTogNDA5NiBNQg0KCUZvcm0gRmFj
dG9yOiBESU1NDQoJU2V0OiBOb25lDQoJTG9jYXRvcjogUDItRElNTTNCDQoJQmFuayBMb2NhdG9y
OiBCQU5LMTENCglUeXBlOiBERFIzDQoJVHlwZSBEZXRhaWw6IE90aGVyDQoJU3BlZWQ6IDEwNjYg
TUh6DQoJTWFudWZhY3R1cmVyOg0KCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwDQoJQXNzZXQgVGFn
Og0KCVBhcnQgTnVtYmVyOiBTVVBFUlRBTEVOVDAyDQoJUmFuazogVW5rbm93bg0KDQpIYW5kbGUg
MHgwMDI4LCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMNCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJl
c3MNCglTdGFydGluZyBBZGRyZXNzOiAweDAwODAwMDAwMDAwDQoJRW5kaW5nIEFkZHJlc3M6IDB4
MDA5MDAwMDAzRkYNCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCDQoJUGh5c2ljYWwgRGV2aWNlIEhh
bmRsZTogMHgwMDI3DQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEw
DQoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQ0KCUludGVybGVhdmUgUG9zaXRpb246IFVua25v
d24NCglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAyDQoNCkhhbmRsZSAweDAwMjksIERNSSB0eXBl
IDMyLCAyMCBieXRlcw0KU3lzdGVtIEJvb3QgSW5mb3JtYXRpb24NCglTdGF0dXM6IE5vIGVycm9y
cyBkZXRlY3RlZA0KDQpIYW5kbGUgMHgwMDJBLCBETUkgdHlwZSAzOCwgMTggYnl0ZXMNCklQTUkg
RGV2aWNlIEluZm9ybWF0aW9uDQoJSW50ZXJmYWNlIFR5cGU6IEtDUyAoS2V5Ym9hcmQgQ29udHJv
bCBTdHlsZSkNCglTcGVjaWZpY2F0aW9uIFZlcnNpb246IDIuMA0KCUkyQyBTbGF2ZSBBZGRyZXNz
OiAweDEwDQoJTlYgU3RvcmFnZSBEZXZpY2U6IE5vdCBQcmVzZW50DQoJQmFzZSBBZGRyZXNzOiAw
eDAwMDAwMDAwMDAwMDBDQTIgKEkvTykNCglSZWdpc3RlciBTcGFjaW5nOiBTdWNjZXNzaXZlIEJ5
dGUgQm91bmRhcmllcw0KDQpIYW5kbGUgMHgwMDJCLCBETUkgdHlwZSAxMjcsIDQgYnl0ZXMNCkVu
ZCBPZiBUYWJsZQ0KDQoNCi0tIA0KTGVvbmlkIEthbGV2DQpDQSBUZWNobm9sb2dpZXMNClByaW5j
aXBhbCBTb2Z0d2FyZSBFbmdpbmVlcg0KVGVsOiAgICAgKzk3MiA0IDgyNSAzOTUyDQpNb2JpbGU6
ICArOTcyIDU0IDQ2MzE1MDgNCkxlb25pZC5LYWxldkBjYS5jb20NCg==

--_002_4F2188768090606cacom_
Content-Type: text/plain; name="dmidecode-eptfail"
Content-Description: dmidecode-eptfail
Content-Disposition: attachment; filename="dmidecode-eptfail"; size=19255;
	creation-date="Thu, 26 Jan 2012 17:08:07 GMT";
	modification-date="Thu, 26 Jan 2012 17:08:07 GMT"
Content-ID: <84EC5538FD1AF2418C2D79167F96121A@ca.com>
Content-Transfer-Encoding: base64

IyBkbWlkZWNvZGUgMi4xMApTTUJJT1MgMi42IHByZXNlbnQuCjQ0IHN0cnVjdHVyZXMgb2NjdXB5
aW5nIDI1NDkgYnl0ZXMuClRhYmxlIGF0IDB4MDAwOUVDMDAuCgpIYW5kbGUgMHgwMDAwLCBETUkg
dHlwZSAwLCAyNCBieXRlcwpCSU9TIEluZm9ybWF0aW9uCglWZW5kb3I6IEFtZXJpY2FuIE1lZ2F0
cmVuZHMgSW5jLgoJVmVyc2lvbjogMDgwMDE2IAoJUmVsZWFzZSBEYXRlOiAwMi8xMS8yMDExCglB
ZGRyZXNzOiAweEYwMDAwCglSdW50aW1lIFNpemU6IDY0IGtCCglST00gU2l6ZTogNDA5NiBrQgoJ
Q2hhcmFjdGVyaXN0aWNzOgoJCUlTQSBpcyBzdXBwb3J0ZWQKCQlQQ0kgaXMgc3VwcG9ydGVkCgkJ
UE5QIGlzIHN1cHBvcnRlZAoJCUJJT1MgaXMgdXBncmFkZWFibGUKCQlCSU9TIHNoYWRvd2luZyBp
cyBhbGxvd2VkCgkJRVNDRCBzdXBwb3J0IGlzIGF2YWlsYWJsZQoJCUJvb3QgZnJvbSBDRCBpcyBz
dXBwb3J0ZWQKCQlTZWxlY3RhYmxlIGJvb3QgaXMgc3VwcG9ydGVkCgkJQklPUyBST00gaXMgc29j
a2V0ZWQKCQlFREQgaXMgc3VwcG9ydGVkCgkJNS4yNSIvMS4yIE1CIGZsb3BweSBzZXJ2aWNlcyBh
cmUgc3VwcG9ydGVkIChpbnQgMTNoKQoJCTMuNSIvNzIwIGtCIGZsb3BweSBzZXJ2aWNlcyBhcmUg
c3VwcG9ydGVkIChpbnQgMTNoKQoJCTMuNSIvMi44OCBNQiBmbG9wcHkgc2VydmljZXMgYXJlIHN1
cHBvcnRlZCAoaW50IDEzaCkKCQlQcmludCBzY3JlZW4gc2VydmljZSBpcyBzdXBwb3J0ZWQgKGlu
dCA1aCkKCQk4MDQyIGtleWJvYXJkIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCA5aCkKCQlT
ZXJpYWwgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDE0aCkKCQlQcmludGVyIHNlcnZpY2Vz
IGFyZSBzdXBwb3J0ZWQgKGludCAxN2gpCgkJQ0dBL21vbm8gdmlkZW8gc2VydmljZXMgYXJlIHN1
cHBvcnRlZCAoaW50IDEwaCkKCQlBQ1BJIGlzIHN1cHBvcnRlZAoJCVVTQiBsZWdhY3kgaXMgc3Vw
cG9ydGVkCgkJTFMtMTIwIGJvb3QgaXMgc3VwcG9ydGVkCgkJQVRBUEkgWmlwIGRyaXZlIGJvb3Qg
aXMgc3VwcG9ydGVkCgkJQklPUyBib290IHNwZWNpZmljYXRpb24gaXMgc3VwcG9ydGVkCgkJVGFy
Z2V0ZWQgY29udGVudCBkaXN0cmlidXRpb24gaXMgc3VwcG9ydGVkCglCSU9TIFJldmlzaW9uOiA4
LjE2CgpIYW5kbGUgMHgwMDAxLCBETUkgdHlwZSAxLCAyNyBieXRlcwpTeXN0ZW0gSW5mb3JtYXRp
b24KCU1hbnVmYWN0dXJlcjogU3VwZXJtaWNybwoJUHJvZHVjdCBOYW1lOiBYOERUVC1ICglWZXJz
aW9uOiAxMjM0NTY3ODkwCglTZXJpYWwgTnVtYmVyOiAxMjM0NTY3ODkwCglVVUlEOiA1NDQ0Mzg1
OC00RTU0LTMwMDAtNDhGNC0wMDMwNDhGNDE3NzAKCVdha2UtdXAgVHlwZTogUG93ZXIgU3dpdGNo
CglTS1UgTnVtYmVyOiAxMjM0NTY3ODkwCglGYW1pbHk6IFNlcnZlcgoKSGFuZGxlIDB4MDAwMiwg
RE1JIHR5cGUgMiwgMTUgYnl0ZXMKQmFzZSBCb2FyZCBJbmZvcm1hdGlvbgoJTWFudWZhY3R1cmVy
OiBTdXBlcm1pY3JvCglQcm9kdWN0IE5hbWU6IFg4RFRULUgKCVZlcnNpb246IDEuMyAgICAgICAK
CVNlcmlhbCBOdW1iZXI6IDEyMzQ1Njc4OTAKCUFzc2V0IFRhZzogMTIzNDU2Nzg5MAoJRmVhdHVy
ZXM6CgkJQm9hcmQgaXMgYSBob3N0aW5nIGJvYXJkCgkJQm9hcmQgaXMgcmVwbGFjZWFibGUKCUxv
Y2F0aW9uIEluIENoYXNzaXM6IDEyMzQ1Njc4OTAKCUNoYXNzaXMgSGFuZGxlOiAweDAwMDMKCVR5
cGU6IE1vdGhlcmJvYXJkCglDb250YWluZWQgT2JqZWN0IEhhbmRsZXM6IDAKCkhhbmRsZSAweDAw
MDMsIERNSSB0eXBlIDMsIDIxIGJ5dGVzCkNoYXNzaXMgSW5mb3JtYXRpb24KCU1hbnVmYWN0dXJl
cjogU3VwZXJtaWNybwoJVHlwZTogTWFpbiBTZXJ2ZXIgQ2hhc3NpcwoJTG9jazogTm90IFByZXNl
bnQKCVZlcnNpb246IDEyMzQ1Njc4OTAKCVNlcmlhbCBOdW1iZXI6IDEyMzQ1Njc4OTAuCglBc3Nl
dCBUYWc6IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4KCUJvb3QtdXAgU3RhdGU6IFNhZmUKCVBvd2Vy
IFN1cHBseSBTdGF0ZTogU2FmZQoJVGhlcm1hbCBTdGF0ZTogU2FmZQoJU2VjdXJpdHkgU3RhdHVz
OiBOb25lCglPRU0gSW5mb3JtYXRpb246IDB4MDAwMDAwMDAKCUhlaWdodDogVW5zcGVjaWZpZWQK
CU51bWJlciBPZiBQb3dlciBDb3JkczogMQoJQ29udGFpbmVkIEVsZW1lbnRzOiAwCgpIYW5kbGUg
MHgwMDA0LCBETUkgdHlwZSA0LCA0MiBieXRlcwpQcm9jZXNzb3IgSW5mb3JtYXRpb24KCVNvY2tl
dCBEZXNpZ25hdGlvbjogQ1BVIDEKCVR5cGU6IENlbnRyYWwgUHJvY2Vzc29yCglGYW1pbHk6IFhl
b24KCU1hbnVmYWN0dXJlcjogSW50ZWwgICAgICAgICAgICAKCUlEOiBBMiAwNiAwMSAwMCBGRiBG
QiBFQiBCRgoJU2lnbmF0dXJlOiBUeXBlIDAsIEZhbWlseSA2LCBNb2RlbCAyNiwgU3RlcHBpbmcg
MgoJRmxhZ3M6CgkJRlBVIChGbG9hdGluZy1wb2ludCB1bml0IG9uLWNoaXApCgkJVk1FIChWaXJ0
dWFsIG1vZGUgZXh0ZW5zaW9uKQoJCURFIChEZWJ1Z2dpbmcgZXh0ZW5zaW9uKQoJCVBTRSAoUGFn
ZSBzaXplIGV4dGVuc2lvbikKCQlUU0MgKFRpbWUgc3RhbXAgY291bnRlcikKCQlNU1IgKE1vZGVs
IHNwZWNpZmljIHJlZ2lzdGVycykKCQlQQUUgKFBoeXNpY2FsIGFkZHJlc3MgZXh0ZW5zaW9uKQoJ
CU1DRSAoTWFjaGluZSBjaGVjayBleGNlcHRpb24pCgkJQ1g4IChDTVBYQ0hHOCBpbnN0cnVjdGlv
biBzdXBwb3J0ZWQpCgkJQVBJQyAoT24tY2hpcCBBUElDIGhhcmR3YXJlIHN1cHBvcnRlZCkKCQlT
RVAgKEZhc3Qgc3lzdGVtIGNhbGwpCgkJTVRSUiAoTWVtb3J5IHR5cGUgcmFuZ2UgcmVnaXN0ZXJz
KQoJCVBHRSAoUGFnZSBnbG9iYWwgZW5hYmxlKQoJCU1DQSAoTWFjaGluZSBjaGVjayBhcmNoaXRl
Y3R1cmUpCgkJQ01PViAoQ29uZGl0aW9uYWwgbW92ZSBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJ
UEFUIChQYWdlIGF0dHJpYnV0ZSB0YWJsZSkKCQlQU0UtMzYgKDM2LWJpdCBwYWdlIHNpemUgZXh0
ZW5zaW9uKQoJCUNMRlNIIChDTEZMVVNIIGluc3RydWN0aW9uIHN1cHBvcnRlZCkKCQlEUyAoRGVi
dWcgc3RvcmUpCgkJQUNQSSAoQUNQSSBzdXBwb3J0ZWQpCgkJTU1YIChNTVggdGVjaG5vbG9neSBz
dXBwb3J0ZWQpCgkJRlhTUiAoRmFzdCBmbG9hdGluZy1wb2ludCBzYXZlIGFuZCByZXN0b3JlKQoJ
CVNTRSAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9ucykKCQlTU0UyIChTdHJlYW1pbmcgU0lNRCBl
eHRlbnNpb25zIDIpCgkJU1MgKFNlbGYtc25vb3ApCgkJSFRUIChIeXBlci10aHJlYWRpbmcgdGVj
aG5vbG9neSkKCQlUTSAoVGhlcm1hbCBtb25pdG9yIHN1cHBvcnRlZCkKCQlQQkUgKFBlbmRpbmcg
YnJlYWsgZW5hYmxlZCkKCVZlcnNpb246IEdlbnVpbmUgSW50ZWwoUikgQ1BVICAgICAgICAgICBA
IDAwMDAgQCAyLjQwR0h6ICAgICAKCVZvbHRhZ2U6IFVua25vd24KCUV4dGVybmFsIENsb2NrOiAx
MzMgTUh6CglNYXggU3BlZWQ6IDI0MDAgTUh6CglDdXJyZW50IFNwZWVkOiAyNDAwIE1IegoJU3Rh
dHVzOiBQb3B1bGF0ZWQsIEVuYWJsZWQKCVVwZ3JhZGU6IE90aGVyCglMMSBDYWNoZSBIYW5kbGU6
IDB4MDAwNQoJTDIgQ2FjaGUgSGFuZGxlOiAweDAwMDYKCUwzIENhY2hlIEhhbmRsZTogMHgwMDA3
CglTZXJpYWwgTnVtYmVyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uCglBc3NldCBUYWc6IFRvIEJl
IEZpbGxlZCBCeSBPLkUuTS4KCVBhcnQgTnVtYmVyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uCglD
b3JlIENvdW50OiA0CglDb3JlIEVuYWJsZWQ6IDQKCVRocmVhZCBDb3VudDogOAoJQ2hhcmFjdGVy
aXN0aWNzOgoJCTY0LWJpdCBjYXBhYmxlCgpIYW5kbGUgMHgwMDA1LCBETUkgdHlwZSA3LCAxOSBi
eXRlcwpDYWNoZSBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2lnbmF0aW9uOiBMMS1DYWNoZQoJQ29u
ZmlndXJhdGlvbjogRW5hYmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAxCglPcGVyYXRpb25hbCBN
b2RlOiBXcml0ZSBUaHJvdWdoCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAy
NTYga0IKCU1heGltdW0gU2l6ZTogMjU2IGtCCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoKCQlPdGhl
cgoJSW5zdGFsbGVkIFNSQU0gVHlwZTogT3RoZXIKCVNwZWVkOiBVbmtub3duCglFcnJvciBDb3Jy
ZWN0aW9uIFR5cGU6IFBhcml0eQoJU3lzdGVtIFR5cGU6IEluc3RydWN0aW9uCglBc3NvY2lhdGl2
aXR5OiA0LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMDYsIERNSSB0eXBlIDcsIDE5
IGJ5dGVzCkNhY2hlIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWduYXRpb246IEwyLUNhY2hlCglD
b25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDIKCU9wZXJhdGlvbmFs
IE1vZGU6IFdyaXRlIFRocm91Z2gKCUxvY2F0aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6
IDEwMjQga0IKCU1heGltdW0gU2l6ZTogMTAyNCBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJ
T3RoZXIKCUluc3RhbGxlZCBTUkFNIFR5cGU6IE90aGVyCglTcGVlZDogVW5rbm93bgoJRXJyb3Ig
Q29ycmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJU3lzdGVtIFR5cGU6IFVuaWZpZWQKCUFz
c29jaWF0aXZpdHk6IDgtd2F5IFNldC1hc3NvY2lhdGl2ZQoKSGFuZGxlIDB4MDAwNywgRE1JIHR5
cGUgNywgMTkgYnl0ZXMKQ2FjaGUgSW5mb3JtYXRpb24KCVNvY2tldCBEZXNpZ25hdGlvbjogTDMt
Q2FjaGUKCUNvbmZpZ3VyYXRpb246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMwoJT3Bl
cmF0aW9uYWwgTW9kZTogV3JpdGUgQmFjawoJTG9jYXRpb246IEludGVybmFsCglJbnN0YWxsZWQg
U2l6ZTogODE5MiBrQgoJTWF4aW11bSBTaXplOiA4MTkyIGtCCglTdXBwb3J0ZWQgU1JBTSBUeXBl
czoKCQlPdGhlcgoJSW5zdGFsbGVkIFNSQU0gVHlwZTogT3RoZXIKCVNwZWVkOiBVbmtub3duCglF
cnJvciBDb3JyZWN0aW9uIFR5cGU6IFNpbmdsZS1iaXQgRUNDCglTeXN0ZW0gVHlwZTogVW5pZmll
ZAoJQXNzb2NpYXRpdml0eTogMTYtd2F5IFNldC1hc3NvY2lhdGl2ZQoKSGFuZGxlIDB4MDAwOCwg
RE1JIHR5cGUgNCwgNDIgYnl0ZXMKUHJvY2Vzc29yIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWdu
YXRpb246IENQVSAyCglUeXBlOiBDZW50cmFsIFByb2Nlc3NvcgoJRmFtaWx5OiBYZW9uCglNYW51
ZmFjdHVyZXI6IEludGVsICAgICAgICAgICAgCglJRDogQTIgMDYgMDEgMDAgRkYgRkIgRUIgQkYK
CVNpZ25hdHVyZTogVHlwZSAwLCBGYW1pbHkgNiwgTW9kZWwgMjYsIFN0ZXBwaW5nIDIKCUZsYWdz
OgoJCUZQVSAoRmxvYXRpbmctcG9pbnQgdW5pdCBvbi1jaGlwKQoJCVZNRSAoVmlydHVhbCBtb2Rl
IGV4dGVuc2lvbikKCQlERSAoRGVidWdnaW5nIGV4dGVuc2lvbikKCQlQU0UgKFBhZ2Ugc2l6ZSBl
eHRlbnNpb24pCgkJVFNDIChUaW1lIHN0YW1wIGNvdW50ZXIpCgkJTVNSIChNb2RlbCBzcGVjaWZp
YyByZWdpc3RlcnMpCgkJUEFFIChQaHlzaWNhbCBhZGRyZXNzIGV4dGVuc2lvbikKCQlNQ0UgKE1h
Y2hpbmUgY2hlY2sgZXhjZXB0aW9uKQoJCUNYOCAoQ01QWENIRzggaW5zdHJ1Y3Rpb24gc3VwcG9y
dGVkKQoJCUFQSUMgKE9uLWNoaXAgQVBJQyBoYXJkd2FyZSBzdXBwb3J0ZWQpCgkJU0VQIChGYXN0
IHN5c3RlbSBjYWxsKQoJCU1UUlIgKE1lbW9yeSB0eXBlIHJhbmdlIHJlZ2lzdGVycykKCQlQR0Ug
KFBhZ2UgZ2xvYmFsIGVuYWJsZSkKCQlNQ0EgKE1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJlKQoJ
CUNNT1YgKENvbmRpdGlvbmFsIG1vdmUgaW5zdHJ1Y3Rpb24gc3VwcG9ydGVkKQoJCVBBVCAoUGFn
ZSBhdHRyaWJ1dGUgdGFibGUpCgkJUFNFLTM2ICgzNi1iaXQgcGFnZSBzaXplIGV4dGVuc2lvbikK
CQlDTEZTSCAoQ0xGTFVTSCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJRFMgKERlYnVnIHN0b3Jl
KQoJCUFDUEkgKEFDUEkgc3VwcG9ydGVkKQoJCU1NWCAoTU1YIHRlY2hub2xvZ3kgc3VwcG9ydGVk
KQoJCUZYU1IgKEZhc3QgZmxvYXRpbmctcG9pbnQgc2F2ZSBhbmQgcmVzdG9yZSkKCQlTU0UgKFN0
cmVhbWluZyBTSU1EIGV4dGVuc2lvbnMpCgkJU1NFMiAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9u
cyAyKQoJCVNTIChTZWxmLXNub29wKQoJCUhUVCAoSHlwZXItdGhyZWFkaW5nIHRlY2hub2xvZ3kp
CgkJVE0gKFRoZXJtYWwgbW9uaXRvciBzdXBwb3J0ZWQpCgkJUEJFIChQZW5kaW5nIGJyZWFrIGVu
YWJsZWQpCglWZXJzaW9uOiBHZW51aW5lIEludGVsKFIpIENQVSAgICAgICAgICAgQCAwMDAwIEAg
Mi40MEdIeiAgICAgCglWb2x0YWdlOiBVbmtub3duCglFeHRlcm5hbCBDbG9jazogMTMzIE1IegoJ
TWF4IFNwZWVkOiAyNDAwIE1IegoJQ3VycmVudCBTcGVlZDogMjQwMCBNSHoKCVN0YXR1czogUG9w
dWxhdGVkLCBFbmFibGVkCglVcGdyYWRlOiBPdGhlcgoJTDEgQ2FjaGUgSGFuZGxlOiAweDAwMDkK
CUwyIENhY2hlIEhhbmRsZTogMHgwMDBBCglMMyBDYWNoZSBIYW5kbGU6IDB4MDAwQgoJU2VyaWFs
IE51bWJlcjogVG8gQmUgRmlsbGVkIEJ5IE8uRS5NLgoJQXNzZXQgVGFnOiBUbyBCZSBGaWxsZWQg
QnkgTy5FLk0uCglQYXJ0IE51bWJlcjogVG8gQmUgRmlsbGVkIEJ5IE8uRS5NLgoJQ29yZSBDb3Vu
dDogNAoJQ29yZSBFbmFibGVkOiA0CglUaHJlYWQgQ291bnQ6IDgKCUNoYXJhY3RlcmlzdGljczoK
CQk2NC1iaXQgY2FwYWJsZQoKSGFuZGxlIDB4MDAwOSwgRE1JIHR5cGUgNywgMTkgYnl0ZXMKQ2Fj
aGUgSW5mb3JtYXRpb24KCVNvY2tldCBEZXNpZ25hdGlvbjogTDEtQ2FjaGUKCUNvbmZpZ3VyYXRp
b246IEVuYWJsZWQsIE5vdCBTb2NrZXRlZCwgTGV2ZWwgMQoJT3BlcmF0aW9uYWwgTW9kZTogV3Jp
dGUgVGhyb3VnaAoJTG9jYXRpb246IEludGVybmFsCglJbnN0YWxsZWQgU2l6ZTogMjU2IGtCCglN
YXhpbXVtIFNpemU6IDI1NiBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJT3RoZXIKCUluc3Rh
bGxlZCBTUkFNIFR5cGU6IE90aGVyCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVjdGlvbiBU
eXBlOiBQYXJpdHkKCVN5c3RlbSBUeXBlOiBJbnN0cnVjdGlvbgoJQXNzb2NpYXRpdml0eTogNC13
YXkgU2V0LWFzc29jaWF0aXZlCgpIYW5kbGUgMHgwMDBBLCBETUkgdHlwZSA3LCAxOSBieXRlcwpD
YWNoZSBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2lnbmF0aW9uOiBMMi1DYWNoZQoJQ29uZmlndXJh
dGlvbjogRW5hYmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAyCglPcGVyYXRpb25hbCBNb2RlOiBX
cml0ZSBUaHJvdWdoCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAxMDI0IGtC
CglNYXhpbXVtIFNpemU6IDEwMjQga0IKCVN1cHBvcnRlZCBTUkFNIFR5cGVzOgoJCU90aGVyCglJ
bnN0YWxsZWQgU1JBTSBUeXBlOiBPdGhlcgoJU3BlZWQ6IFVua25vd24KCUVycm9yIENvcnJlY3Rp
b24gVHlwZTogU2luZ2xlLWJpdCBFQ0MKCVN5c3RlbSBUeXBlOiBVbmlmaWVkCglBc3NvY2lhdGl2
aXR5OiA4LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMEIsIERNSSB0eXBlIDcsIDE5
IGJ5dGVzCkNhY2hlIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWduYXRpb246IEwzLUNhY2hlCglD
b25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDMKCU9wZXJhdGlvbmFs
IE1vZGU6IFdyaXRlIEJhY2sKCUxvY2F0aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6IDgx
OTIga0IKCU1heGltdW0gU2l6ZTogODE5MiBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJT3Ro
ZXIKCUluc3RhbGxlZCBTUkFNIFR5cGU6IE90aGVyCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29y
cmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJU3lzdGVtIFR5cGU6IFVuaWZpZWQKCUFzc29j
aWF0aXZpdHk6IDE2LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMEMsIERNSSB0eXBl
IDksIDE3IGJ5dGVzClN5c3RlbSBTbG90IEluZm9ybWF0aW9uCglEZXNpZ25hdGlvbjogUENJRTEK
CVR5cGU6IHgxNiBQQ0kgRXhwcmVzcwoJQ3VycmVudCBVc2FnZTogQXZhaWxhYmxlCglMZW5ndGg6
IExvbmcKCUlEOiAxCglDaGFyYWN0ZXJpc3RpY3M6CgkJMy4zIFYgaXMgcHJvdmlkZWQKCQlPcGVu
aW5nIGlzIHNoYXJlZAoJCVBNRSBzaWduYWwgaXMgc3VwcG9ydGVkCgpIYW5kbGUgMHgwMDBELCBE
TUkgdHlwZSAxMSwgNSBieXRlcwpPRU0gU3RyaW5ncwoJU3RyaW5nIDE6IFRvIEJlIEZpbGxlZCBC
eSBPLkUuTS4KCVN0cmluZyAyOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0uCgpIYW5kbGUgMHgwMDBF
LCBETUkgdHlwZSAxNSwgNTUgYnl0ZXMKU3lzdGVtIEV2ZW50IExvZwoJQXJlYSBMZW5ndGg6IDEw
MDggYnl0ZXMKCUhlYWRlciBTdGFydCBPZmZzZXQ6IDB4MDgxMAoJRGF0YSBTdGFydCBPZmZzZXQ6
IDB4MDgxMAoJQWNjZXNzIE1ldGhvZDogR2VuZXJhbC1wdXJwb3NlIG5vbi12b2xhdGlsZSBkYXRh
IGZ1bmN0aW9ucwoJQWNjZXNzIEFkZHJlc3M6IDB4MDAwMQoJU3RhdHVzOiBWYWxpZCwgTm90IEZ1
bGwKCUNoYW5nZSBUb2tlbjogMHgwMDAwMDAwMAoJSGVhZGVyIEZvcm1hdDogTm8gSGVhZGVyCglT
dXBwb3J0ZWQgTG9nIFR5cGUgRGVzY3JpcHRvcnM6IDE1CglEZXNjcmlwdG9yIDE6IFNpbmdsZS1i
aXQgRUNDIG1lbW9yeSBlcnJvcgoJRGF0YSBGb3JtYXQgMTogTXVsdGlwbGUtZXZlbnQgaGFuZGxl
CglEZXNjcmlwdG9yIDI6IE11bHRpLWJpdCBFQ0MgbWVtb3J5IGVycm9yCglEYXRhIEZvcm1hdCAy
OiBNdWx0aXBsZS1ldmVudCBoYW5kbGUKCURlc2NyaXB0b3IgMzogUGFyaXR5IG1lbW9yeSBlcnJv
cgoJRGF0YSBGb3JtYXQgMzogTXVsdGlwbGUtZXZlbnQKCURlc2NyaXB0b3IgNDogSS9PIGNoYW5u
ZWwgYmxvY2sKCURhdGEgRm9ybWF0IDQ6IE11bHRpcGxlLWV2ZW50CglEZXNjcmlwdG9yIDU6IFBP
U1QgZXJyb3IKCURhdGEgRm9ybWF0IDU6IFBPU1QgcmVzdWx0cyBiaXRtYXAKCURlc2NyaXB0b3Ig
NjogUENJIHBhcml0eSBlcnJvcgoJRGF0YSBGb3JtYXQgNjogTXVsdGlwbGUtZXZlbnQgaGFuZGxl
CglEZXNjcmlwdG9yIDc6IFBDSSBzeXN0ZW0gZXJyb3IKCURhdGEgRm9ybWF0IDc6IE11bHRpcGxl
LWV2ZW50IGhhbmRsZQoJRGVzY3JpcHRvciA4OiBTeXN0ZW0gbGltaXQgZXhjZWVkZWQKCURhdGEg
Rm9ybWF0IDg6IE11bHRpcGxlLWV2ZW50IHN5c3RlbSBtYW5hZ2VtZW50CglEZXNjcmlwdG9yIDk6
IE9FTS1zcGVjaWZpYwoJRGF0YSBGb3JtYXQgOTogUE9TVCByZXN1bHRzIGJpdG1hcAoJRGVzY3Jp
cHRvciAxMDogT0VNLXNwZWNpZmljCglEYXRhIEZvcm1hdCAxMDogTXVsdGlwbGUtZXZlbnQgaGFu
ZGxlCglEZXNjcmlwdG9yIDExOiBPRU0tc3BlY2lmaWMKCURhdGEgRm9ybWF0IDExOiBNdWx0aXBs
ZS1ldmVudCBoYW5kbGUKCURlc2NyaXB0b3IgMTI6IE9FTS1zcGVjaWZpYwoJRGF0YSBGb3JtYXQg
MTI6IE11bHRpcGxlLWV2ZW50IGhhbmRsZQoJRGVzY3JpcHRvciAxMzogT0VNLXNwZWNpZmljCglE
YXRhIEZvcm1hdCAxMzogTXVsdGlwbGUtZXZlbnQgaGFuZGxlCglEZXNjcmlwdG9yIDE0OiBPRU0t
c3BlY2lmaWMKCURhdGEgRm9ybWF0IDE0OiBNdWx0aXBsZS1ldmVudCBoYW5kbGUKCURlc2NyaXB0
b3IgMTU6IE9FTS1zcGVjaWZpYwoJRGF0YSBGb3JtYXQgMTU6IE11bHRpcGxlLWV2ZW50IGhhbmRs
ZQoKSGFuZGxlIDB4MDAwRiwgRE1JIHR5cGUgMTYsIDE1IGJ5dGVzClBoeXNpY2FsIE1lbW9yeSBB
cnJheQoJTG9jYXRpb246IFN5c3RlbSBCb2FyZCBPciBNb3RoZXJib2FyZAoJVXNlOiBTeXN0ZW0g
TWVtb3J5CglFcnJvciBDb3JyZWN0aW9uIFR5cGU6IE11bHRpLWJpdCBFQ0MKCU1heGltdW0gQ2Fw
YWNpdHk6IDM4NCBHQgoJRXJyb3IgSW5mb3JtYXRpb24gSGFuZGxlOiBOb3QgUHJvdmlkZWQKCU51
bWJlciBPZiBEZXZpY2VzOiAxMgoKSGFuZGxlIDB4MDAxMCwgRE1JIHR5cGUgMTksIDE1IGJ5dGVz
Ck1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcwoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDAwMDAw
MDAwMAoJRW5kaW5nIEFkZHJlc3M6IDB4MDQ0NDNGRkZGRkYKCVJhbmdlIFNpemU6IDI3OTYxNiBN
QgoJUGh5c2ljYWwgQXJyYXkgSGFuZGxlOiAweDAwMEYKCVBhcnRpdGlvbiBXaWR0aDogMAoKSGFu
ZGxlIDB4MDAxMSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhh
bmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90
YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZv
cm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0xQQoJQmFuayBMb2Nh
dG9yOiBCQU5LMAoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBN
SHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAw
CglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAg
IAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAxMiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1l
bW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAw
MDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMTAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtC
CglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTEKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRk
cmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2
ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4
MDAxMywgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTog
MHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lk
dGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFj
dG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0xQgoJQmFuayBMb2NhdG9yOiBC
QU5LMQoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1h
bnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3Nl
dCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFu
azogVW5rbm93bgoKSGFuZGxlIDB4MDAxNCwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBE
ZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAxMDAwMDAwMDAKCUVu
ZGluZyBBZGRyZXNzOiAweDAwMjAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlz
aWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMTMKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBI
YW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3Np
dGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxNSwg
RE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBG
CglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcy
IGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBE
SU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0yQQoJQmFuayBMb2NhdG9yOiBCQU5LMgoJ
VHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0
dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6
ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5r
bm93bgoKSGFuZGxlIDB4MDAxNiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2Ug
TWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAyMDAwMDAwMDAKCUVuZGluZyBB
ZGRyZXNzOiAweDAwMzAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBE
ZXZpY2UgSGFuZGxlOiAweDAwMTUKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6
IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjog
VW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxNywgRE1JIHR5
cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJv
ciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMK
CURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglT
ZXQ6IE5vbmUKCUxvY2F0b3I6IFAxLURJTU0yQgoJQmFuayBMb2NhdG9yOiBCQU5LMwoJVHlwZTog
RERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjog
ICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAg
ICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoK
SGFuZGxlIDB4MDAxOCwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVk
IEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAzMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNz
OiAweDAwNDAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZpY2Ug
SGFuZGxlOiAweDAwMTcKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAx
MAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93
bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxOSwgRE1JIHR5cGUgMTcs
IDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZv
cm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEg
V2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5v
bmUKCUxvY2F0b3I6IFAxLURJTU0zQQoJQmFuayBMb2NhdG9yOiBCQU5LNAoJVHlwZTogRERSMwoJ
VHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAg
ICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAg
IAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxl
IDB4MDAxQSwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJl
c3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDA0MDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAw
NTAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxl
OiAweDAwMTkKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFy
dGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50
ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxQiwgRE1JIHR5cGUgMTcsIDI4IGJ5
dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlv
biBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6
IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxv
Y2F0b3I6IFAxLURJTU0zQgoJQmFuayBMb2NhdG9yOiBCQU5LNQoJVHlwZTogRERSMwoJVHlwZSBE
ZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAg
ICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFy
dCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAx
QywgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0
YXJ0aW5nIEFkZHJlc3M6IDB4MDA1MDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwNjAwMDAw
M0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAw
MUIKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9u
IFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2
ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAxRCwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1l
bW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5k
bGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJp
dHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6
IFAyLURJTU0xQQoJQmFuayBMb2NhdG9yOiBCQU5LNgoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6
IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNl
cmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1i
ZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAxRSwgRE1J
IHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5n
IEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGCglS
YW5nZSBTaXplOiAxIGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMUQKCU1lbW9yeSBB
cnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlv
bjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0
aDogMgoKSGFuZGxlIDB4MDAxRiwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UK
CUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92
aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQw
OTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0xQgoJ
QmFuayBMb2NhdG9yOiBCQU5LNwoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVl
ZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6
IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFM
RU5UMDIgICAgIAoJUmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAyMCwgRE1JIHR5cGUgMjAsIDE5
IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4
MDAwMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGCglSYW5nZSBTaXplOiAx
IGtCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAweDAwMUYKCU1lbW9yeSBBcnJheSBNYXBwZWQg
QWRkcmVzcyBIYW5kbGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJs
ZWF2ZSBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxl
IDB4MDAyMSwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRs
ZTogMHgwMDBGCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwg
V2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0g
RmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0yQQoJQmFuayBMb2NhdG9y
OiBCQU5LOAoJVHlwZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoK
CU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglB
c3NldCBUYWc6ICAgICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJ
UmFuazogVW5rbm93bgoKSGFuZGxlIDB4MDAyMiwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9y
eSBEZXZpY2UgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAK
CUVuZGluZyBBZGRyZXNzOiAweDAwMDAwMDAwM0ZGCglSYW5nZSBTaXplOiAxIGtCCglQaHlzaWNh
bCBEZXZpY2UgSGFuZGxlOiAweDAwMjEKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5k
bGU6IDB4MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlv
bjogVW5rbm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAyMywgRE1J
IHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglF
cnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJp
dHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1N
CglTZXQ6IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0yQgoJQmFuayBMb2NhdG9yOiBCQU5LOQoJVHlw
ZTogRERSMwoJVHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJl
cjogICAgICAgICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAg
ICAgICAgICAgIAoJUGFydCBOdW1iZXI6IFNVUEVSVEFMRU5UMDIgICAgIAoJUmFuazogVW5rbm93
bgoKSGFuZGxlIDB4MDAyNCwgRE1JIHR5cGUgMjAsIDE5IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFw
cGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDA2MDAwMDAwMDAKCUVuZGluZyBBZGRy
ZXNzOiAweDAwNzAwMDAwM0ZGCglSYW5nZSBTaXplOiA0MTk0MzA1IGtCCglQaHlzaWNhbCBEZXZp
Y2UgSGFuZGxlOiAweDAwMjMKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4
MDAxMAoJUGFydGl0aW9uIFJvdyBQb3NpdGlvbjogMQoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogVW5r
bm93bgoJSW50ZXJsZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAyNSwgRE1JIHR5cGUg
MTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDBGCglFcnJvciBJ
bmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURh
dGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDQwOTYgTUIKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6
IE5vbmUKCUxvY2F0b3I6IFAyLURJTU0zQQoJQmFuayBMb2NhdG9yOiBCQU5LMTAKCVR5cGU6IERE
UjMKCVR5cGUgRGV0YWlsOiBPdGhlcgoJU3BlZWQ6IDEwNjYgTUh6CglNYW51ZmFjdHVyZXI6ICAg
ICAgICAgICAgICAgCglTZXJpYWwgTnVtYmVyOiAwMDAwMDAwMAoJQXNzZXQgVGFnOiAgICAgICAg
ICAgICAgCglQYXJ0IE51bWJlcjogU1VQRVJUQUxFTlQwMiAgICAgCglSYW5rOiBVbmtub3duCgpI
YW5kbGUgMHgwMDI2LCBETUkgdHlwZSAyMCwgMTkgYnl0ZXMKTWVtb3J5IERldmljZSBNYXBwZWQg
QWRkcmVzcwoJU3RhcnRpbmcgQWRkcmVzczogMHgwMDcwMDAwMDAwMAoJRW5kaW5nIEFkZHJlc3M6
IDB4MDA4MDAwMDAzRkYKCVJhbmdlIFNpemU6IDQxOTQzMDUga0IKCVBoeXNpY2FsIERldmljZSBI
YW5kbGU6IDB4MDAyNQoJTWVtb3J5IEFycmF5IE1hcHBlZCBBZGRyZXNzIEhhbmRsZTogMHgwMDEw
CglQYXJ0aXRpb24gUm93IFBvc2l0aW9uOiAxCglJbnRlcmxlYXZlIFBvc2l0aW9uOiBVbmtub3du
CglJbnRlcmxlYXZlZCBEYXRhIERlcHRoOiAyCgpIYW5kbGUgMHgwMDI3LCBETUkgdHlwZSAxNywg
MjggYnl0ZXMKTWVtb3J5IERldmljZQoJQXJyYXkgSGFuZGxlOiAweDAwMEYKCUVycm9yIEluZm9y
bWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkCglUb3RhbCBXaWR0aDogNzIgYml0cwoJRGF0YSBX
aWR0aDogNjQgYml0cwoJU2l6ZTogNDA5NiBNQgoJRm9ybSBGYWN0b3I6IERJTU0KCVNldDogTm9u
ZQoJTG9jYXRvcjogUDItRElNTTNCCglCYW5rIExvY2F0b3I6IEJBTksxMQoJVHlwZTogRERSMwoJ
VHlwZSBEZXRhaWw6IE90aGVyCglTcGVlZDogMTA2NiBNSHoKCU1hbnVmYWN0dXJlcjogICAgICAg
ICAgICAgICAKCVNlcmlhbCBOdW1iZXI6IDAwMDAwMDAwCglBc3NldCBUYWc6ICAgICAgICAgICAg
ICAKCVBhcnQgTnVtYmVyOiBTVVBFUlRBTEVOVDAyICAgICAKCVJhbms6IFVua25vd24KCkhhbmRs
ZSAweDAwMjgsIERNSSB0eXBlIDIwLCAxOSBieXRlcwpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRy
ZXNzCglTdGFydGluZyBBZGRyZXNzOiAweDAwODAwMDAwMDAwCglFbmRpbmcgQWRkcmVzczogMHgw
MDkwMDAwMDNGRgoJUmFuZ2UgU2l6ZTogNDE5NDMwNSBrQgoJUGh5c2ljYWwgRGV2aWNlIEhhbmRs
ZTogMHgwMDI3CglNZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMTAKCVBh
cnRpdGlvbiBSb3cgUG9zaXRpb246IDEKCUludGVybGVhdmUgUG9zaXRpb246IFVua25vd24KCUlu
dGVybGVhdmVkIERhdGEgRGVwdGg6IDIKCkhhbmRsZSAweDAwMjksIERNSSB0eXBlIDMyLCAyMCBi
eXRlcwpTeXN0ZW0gQm9vdCBJbmZvcm1hdGlvbgoJU3RhdHVzOiBObyBlcnJvcnMgZGV0ZWN0ZWQK
CkhhbmRsZSAweDAwMkEsIERNSSB0eXBlIDM4LCAxOCBieXRlcwpJUE1JIERldmljZSBJbmZvcm1h
dGlvbgoJSW50ZXJmYWNlIFR5cGU6IEtDUyAoS2V5Ym9hcmQgQ29udHJvbCBTdHlsZSkKCVNwZWNp
ZmljYXRpb24gVmVyc2lvbjogMi4wCglJMkMgU2xhdmUgQWRkcmVzczogMHgxMAoJTlYgU3RvcmFn
ZSBEZXZpY2U6IE5vdCBQcmVzZW50CglCYXNlIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAwMENBMiAo
SS9PKQoJUmVnaXN0ZXIgU3BhY2luZzogU3VjY2Vzc2l2ZSBCeXRlIEJvdW5kYXJpZXMKCkhhbmRs
ZSAweDAwMkIsIERNSSB0eXBlIDEyNywgNCBieXRlcwpFbmQgT2YgVGFibGUKCg==

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

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

--_002_4F2188768090606cacom_--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBv-0002nf-7S; Wed, 01 Feb 2012 10:13:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RqjDk-0005DN-6X; Fri, 27 Jan 2012 10:39:52 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327660785!2418721!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3893 invoked from network); 27 Jan 2012 10:39:45 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 10:39:45 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0RAbs8i023292;
	Fri, 27 Jan 2012 12:37:54 +0200
Message-ID: <5C1125AAA6544C759D3072468263185C@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Florian Heigl" <florian.heigl@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host><3758972BBA474BCBB9CA5D1D316892E7@nobody><1327430498.7929.14.camel@mnetdjm5.mageenet.host><EE3AE950D047481283FF742510029D1E@nobody><1327510462.24561.351.camel@zakaz.uk.xensource.com><CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
	<1327577478.26983.73.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Jan 2012 12:38:40 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, SandiRomih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, Tobias Geiger <tobias.geiger@vido.info>,
	Doug Magee <djmagee@mageenet.net>,
	KonradRzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] xl vs xm - hernya (bad results)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Compare the two results on the same system.
xl - not sorted alphabetically and by memory shows the nonsense


# xl list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0   512     6        r--  
313260.0
c2                                           1  4096     5        r--  
111502.1
c3                                           4   512     5        r--  
6419.4
s1                                       6  1027     2        r--  19593.0
d70                                          7  1003     1        r--  
77161.6
d73                                          8   515     1        r--  
237146.7
v01                                         10    93     1        r--  
48162.9
t2                                          12   515     5        r--  
38607.5
a1                                       13  2050     4        r-- 160406.0
g4                                          15    99     1        r--  
15616.6
g3                                          18   131     1        r--  
43006.0
b1                                        20   512     5        r--   4133.2
t1                                          21   259     1        r--  
140468.7
d80                                         22   515     5        r--  
50262.9
g2                                          38    83     1        r--  
34071.0
d82                                         40   771     5        r--  
17699.5
j2                                          41  1027     5        r--  
68179.1
d75                                         43    99     1        r--  
13325.7
d74                                         52   771     1        r--  
9707.6
t3                                          53   515     5        r--  
7913.0


#xm list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0   512     6     r-----  
313274.1
a1                                       13  2048     4     -b---- 160412.8
b1                                        20   512     5     ------   4133.4
c2                                           1  4096     5     -b----  
111508.6
c3                                           4   512     5     -b----  
6419.5
d70                                          7  1000     1     -b----  
77163.8
d73                                          8   512     1     -b----  
237155.4
d74                                         52   768     1     -b----  
9709.6
d75                                         43    96     1     -b----  
13327.6
d80                                         22   512     5     -b----  
50266.4
d82                                         40   768     5     -b----  
17700.9
g2                                          38    80     1     -b----  
34073.4
g3                                          18   128     1     -b----  
43008.1
g4                                          15    96     1     -b----  
15617.3
j2                                          41  1024     5     -b----  
68192.6
s1                                       6  1024     2     -b----  19594.0
t1                                          21   256     1     r-----  
140478.2
t2                                          12   512     5     -b----  
38609.1
t3                                          53   512     5     -b----  
7914.8
v01                                         10    90     1     -b----  
48164.8


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBv-0002nf-7S; Wed, 01 Feb 2012 10:13:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RqjDk-0005DN-6X; Fri, 27 Jan 2012 10:39:52 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327660785!2418721!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3893 invoked from network); 27 Jan 2012 10:39:45 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 10:39:45 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0RAbs8i023292;
	Fri, 27 Jan 2012 12:37:54 +0200
Message-ID: <5C1125AAA6544C759D3072468263185C@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Florian Heigl" <florian.heigl@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host><3758972BBA474BCBB9CA5D1D316892E7@nobody><1327430498.7929.14.camel@mnetdjm5.mageenet.host><EE3AE950D047481283FF742510029D1E@nobody><1327510462.24561.351.camel@zakaz.uk.xensource.com><CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
	<1327577478.26983.73.camel@zakaz.uk.xensource.com>
Date: Fri, 27 Jan 2012 12:38:40 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, SandiRomih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, Tobias Geiger <tobias.geiger@vido.info>,
	Doug Magee <djmagee@mageenet.net>,
	KonradRzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] xl vs xm - hernya (bad results)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Compare the two results on the same system.
xl - not sorted alphabetically and by memory shows the nonsense


# xl list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0   512     6        r--  
313260.0
c2                                           1  4096     5        r--  
111502.1
c3                                           4   512     5        r--  
6419.4
s1                                       6  1027     2        r--  19593.0
d70                                          7  1003     1        r--  
77161.6
d73                                          8   515     1        r--  
237146.7
v01                                         10    93     1        r--  
48162.9
t2                                          12   515     5        r--  
38607.5
a1                                       13  2050     4        r-- 160406.0
g4                                          15    99     1        r--  
15616.6
g3                                          18   131     1        r--  
43006.0
b1                                        20   512     5        r--   4133.2
t1                                          21   259     1        r--  
140468.7
d80                                         22   515     5        r--  
50262.9
g2                                          38    83     1        r--  
34071.0
d82                                         40   771     5        r--  
17699.5
j2                                          41  1027     5        r--  
68179.1
d75                                         43    99     1        r--  
13325.7
d74                                         52   771     1        r--  
9707.6
t3                                          53   515     5        r--  
7913.0


#xm list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0   512     6     r-----  
313274.1
a1                                       13  2048     4     -b---- 160412.8
b1                                        20   512     5     ------   4133.4
c2                                           1  4096     5     -b----  
111508.6
c3                                           4   512     5     -b----  
6419.5
d70                                          7  1000     1     -b----  
77163.8
d73                                          8   512     1     -b----  
237155.4
d74                                         52   768     1     -b----  
9709.6
d75                                         43    96     1     -b----  
13327.6
d80                                         22   512     5     -b----  
50266.4
d82                                         40   768     5     -b----  
17700.9
g2                                          38    80     1     -b----  
34073.4
g3                                          18   128     1     -b----  
43008.1
g4                                          15    96     1     -b----  
15617.3
j2                                          41  1024     5     -b----  
68192.6
s1                                       6  1024     2     -b----  19594.0
t1                                          21   256     1     r-----  
140478.2
t2                                          12   512     5     -b----  
38609.1
t3                                          53   512     5     -b----  
7914.8
v01                                         10    90     1     -b----  
48164.8


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBw-0002oL-Vp; Wed, 01 Feb 2012 10:13:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rqjar-0006Yd-Lt; Fri, 27 Jan 2012 11:03:46 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327662186!50022861!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.6 required=7.0 tests=FORGED_MUA_OUTLOOK,
	HTML_90_100,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8810 invoked from network); 27 Jan 2012 11:03:07 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 11:03:07 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0RB1v1D024282;
	Fri, 27 Jan 2012 13:01:57 +0200
Message-ID: <67003516D77C4AE38E7F08CEEF127E89@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Florian Heigl" <florian.heigl@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host><3758972BBA474BCBB9CA5D1D316892E7@nobody><1327430498.7929.14.camel@mnetdjm5.mageenet.host><EE3AE950D047481283FF742510029D1E@nobody><1327510462.24561.351.camel@zakaz.uk.xensource.com><CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com><1327577478.26983.73.camel@zakaz.uk.xensource.com>
	<5C1125AAA6544C759D3072468263185C@nobody>
Date: Fri, 27 Jan 2012 13:02:43 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, SandiRomih <romihs.forums@gmail.com>,
	xen-users@lists.xensource.com, Tobias Geiger <tobias.geiger@vido.info>,
	Doug Magee <djmagee@mageenet.net>,
	KonradRzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: [Xen-devel] [Xen-users] xl vs xm - hernya (bad results)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3679858672347343400=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============3679858672347343400==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0234_01CCDCF3.F50B1690"

This is a multi-part message in MIME format.

------=_NextPart_000_0234_01CCDCF3.F50B1690
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry, quoting lines cut, and I repeat the message

Compare the two results on the same system.
xl - not sorted alphabetically and by memory shows the nonsense
# xl list
Name                                        ID   Mem VCPUs      State   =
Time(s)
Domain-0                                     0   512     6        r-- =
313260.0
c2                                           1  4096     5        r-- =
111502.1
c3                                           4   512     5        r--   =
6419.4
s1                                       6  1027     2        r--  =
19593.0
d70                                          7  1003     1        r--  =
77161.6
d73                                          8   515     1        r-- =
237146.7
v01                                         10    93     1        r--  =
48162.9
t2                                          12   515     5        r--  =
38607.5
a1                                       13  2050     4        r-- =
160406.0
g4                                          15    99     1        r--  =
15616.6
g3                                          18   131     1        r--  =
43006.0
b1                                        20   512     5        r--   =
4133.2
t1                                          21   259     1        r-- =
140468.7
d80                                         22   515     5        r--  =
50262.9
g2                                          38    83     1        r--  =
34071.0
d82                                         40   771     5        r--  =
17699.5
j2                                          41  1027     5        r--  =
68179.1
d75                                         43    99     1        r--  =
13325.7
d74                                         52   771     1        r--   =
9707.6
t3                                          53   515     5        r--   =
7913.0
# xm list
Name                                        ID   Mem VCPUs      State   =
Time(s)
Domain-0                                     0   512     6     r----- =
313274.1
a1                                       13  2048     4     -b---- =
160412.8
b1                                        20   512     5     ------   =
4133.4
c2                                           1  4096     5     -b---- =
111508.6
c3                                           4   512     5     -b----   =
6419.5
d70                                          7  1000     1     -b----  =
77163.8
d73                                          8   512     1     -b---- =
237155.4
d74                                         52   768     1     -b----   =
9709.6
d75                                         43    96     1     -b----  =
13327.6
d80                                         22   512     5     -b----  =
50266.4
d82                                         40   768     5     -b----  =
17700.9
g2                                          38    80     1     -b----  =
34073.4
g3                                          18   128     1     -b----  =
43008.1
g4                                          15    96     1     -b----  =
15617.3
j2                                          41  1024     5     -b----  =
68192.6
s1                                       6  1024     2     -b----  =
19594.0
t1                                          21   256     1     r----- =
140478.2
t2                                          12   512     5     -b----  =
38609.1
t3                                          53   512     5     -b----   =
7914.8
v01                                         10    90     1     -b----  =
48164.8

------=_NextPart_000_0234_01CCDCF3.F50B1690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY><!-- Template: 'Reply Mail (00000003)' --><!-- Greeting -->
<DIV><SPAN id=3Dresult_box lang=3Den class=3Dshort_text =
closure_uid_bkpfes=3D"182"=20
Kc=3D"null" a=3D"undefined" c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"23813"><SPAN=20
id=3Dresult_box lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
Kc=3D"null"=20
a=3D"undefined" c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"23937">Sorry</SPAN><SPAN=20
closure_uid_bkpfes=3D"23938">, quoting</SPAN> <SPAN class=3Dhps=20
closure_uid_bkpfes=3D"23939">lines</SPAN> <SPAN class=3Dhps=20
closure_uid_bkpfes=3D"23940">cut</SPAN><SPAN =
closure_uid_bkpfes=3D"23941">, and I=20
repeat</SPAN> <SPAN class=3Dhps closure_uid_bkpfes=3D"23942">the=20
message</SPAN></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
Kc=3D"null"=20
a=3D"undefined" c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"23813"><SPAN lang=3Den=20
class=3Dshort_text closure_uid_bkpfes=3D"182" Kc=3D"null" =
a=3D"undefined" c=3D"4"><SPAN=20
class=3Dhps =
closure_uid_bkpfes=3D"23942"></SPAN></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
Kc=3D"null"=20
a=3D"undefined" c=3D"4"><SPAN class=3Dhps closure_uid_bkpfes=3D"23816">
<DIV>Compare the two results on the same system.</DIV>
<DIV>xl - not sorted alphabetically and by memory shows the=20
nonsense</DIV></SPAN></SPAN></DIV>
<DIV><FONT size=3D2 face=3DArial># xl=20
list<BR>Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ID&nbsp;&nbsp; Mem VCPUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State&nbsp;&nbsp; =

Time(s)<BR>Domain-0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp;=20
6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
313260.0<BR>c2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp; 4096&nbsp;&nbsp;&nbsp;&nbsp; =
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
r--=20
111502.1<BR>c3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
4&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp;=20
6419.4<BR>s1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
6&nbsp; 1027&nbsp;&nbsp;&nbsp;&nbsp; =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
r--&nbsp;=20
19593.0<BR>d70&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
7&nbsp; 1003&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
r--&nbsp;=20
77161.6<BR>d73&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
8&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
237146.7<BR>v01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10&nbsp;&nbsp;&nbsp; 93&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
48162.9<BR>t2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
12&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
38607.5<BR>a1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
13&nbsp; 2050&nbsp;&nbsp;&nbsp;&nbsp;=20
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
160406.0<BR>g4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
15&nbsp;&nbsp;&nbsp; 99&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
15616.6<BR>g3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
18&nbsp;&nbsp; 131&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
43006.0<BR>b1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
20&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp;=20
4133.2<BR>t1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
21&nbsp;&nbsp; 259&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
140468.7<BR>d80&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
22&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
50262.9<BR>g2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
38&nbsp;&nbsp;&nbsp; 83&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
34071.0<BR>d82&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
40&nbsp;&nbsp; 771&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
17699.5<BR>j2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
41&nbsp; 1027&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
68179.1<BR>d75&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
43&nbsp;&nbsp;&nbsp; 99&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
13325.7<BR>d74&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
52&nbsp;&nbsp; 771&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp;=20
9707.6<BR>t3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
53&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp; 7913.0<BR># =
xm=20
list<BR>Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ID&nbsp;&nbsp; Mem VCPUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State&nbsp;&nbsp; =

Time(s)<BR>Domain-0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp;&nbsp; =
r-----=20
313274.1<BR>a1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
13&nbsp; 2048&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp; -b----=20
160412.8<BR>b1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
20&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
------&nbsp;&nbsp;=20
4133.4<BR>c2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp; 4096&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp; -b----=20
111508.6<BR>c3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
4&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;&nbsp;=20
6419.5<BR>d70&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
7&nbsp; 1000&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; =
-b----&nbsp;=20
77163.8<BR>d73&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
8&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; =
-b----=20
237155.4<BR>d74&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
52&nbsp;&nbsp; 768&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;&nbsp;=20
9709.6<BR>d75&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
43&nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
13327.6<BR>d80&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
22&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
50266.4<BR>d82&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
40&nbsp;&nbsp; 768&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
17700.9<BR>g2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
38&nbsp;&nbsp;&nbsp; 80&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
34073.4<BR>g3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
18&nbsp;&nbsp; 128&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
43008.1<BR>g4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
15&nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
15617.3<BR>j2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
41&nbsp; 1024&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp; =
-b----&nbsp;=20
68192.6<BR>s1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
6&nbsp; 1024&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp; =
-b----&nbsp;=20
19594.0<BR>t1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
21&nbsp;&nbsp; 256&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; =
r-----=20
140478.2<BR>t2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
12&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
38609.1<BR>t3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
53&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;&nbsp;=20
7914.8<BR>v01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10&nbsp;&nbsp;&nbsp; 90&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp; 48164.8<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0234_01CCDCF3.F50B1690--



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

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

--===============3679858672347343400==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXBw-0002oL-Vp; Wed, 01 Feb 2012 10:13:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1Rqjar-0006Yd-Lt; Fri, 27 Jan 2012 11:03:46 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327662186!50022861!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.6 required=7.0 tests=FORGED_MUA_OUTLOOK,
	HTML_90_100,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8810 invoked from network); 27 Jan 2012 11:03:07 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 11:03:07 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q0RB1v1D024282;
	Fri, 27 Jan 2012 13:01:57 +0200
Message-ID: <67003516D77C4AE38E7F08CEEF127E89@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Florian Heigl" <florian.heigl@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host><3758972BBA474BCBB9CA5D1D316892E7@nobody><1327430498.7929.14.camel@mnetdjm5.mageenet.host><EE3AE950D047481283FF742510029D1E@nobody><1327510462.24561.351.camel@zakaz.uk.xensource.com><CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com><1327577478.26983.73.camel@zakaz.uk.xensource.com>
	<5C1125AAA6544C759D3072468263185C@nobody>
Date: Fri, 27 Jan 2012 13:02:43 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: xen-devel@lists.xensource.com, SandiRomih <romihs.forums@gmail.com>,
	xen-users@lists.xensource.com, Tobias Geiger <tobias.geiger@vido.info>,
	Doug Magee <djmagee@mageenet.net>,
	KonradRzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: [Xen-devel] [Xen-users] xl vs xm - hernya (bad results)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3679858672347343400=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============3679858672347343400==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0234_01CCDCF3.F50B1690"

This is a multi-part message in MIME format.

------=_NextPart_000_0234_01CCDCF3.F50B1690
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry, quoting lines cut, and I repeat the message

Compare the two results on the same system.
xl - not sorted alphabetically and by memory shows the nonsense
# xl list
Name                                        ID   Mem VCPUs      State   =
Time(s)
Domain-0                                     0   512     6        r-- =
313260.0
c2                                           1  4096     5        r-- =
111502.1
c3                                           4   512     5        r--   =
6419.4
s1                                       6  1027     2        r--  =
19593.0
d70                                          7  1003     1        r--  =
77161.6
d73                                          8   515     1        r-- =
237146.7
v01                                         10    93     1        r--  =
48162.9
t2                                          12   515     5        r--  =
38607.5
a1                                       13  2050     4        r-- =
160406.0
g4                                          15    99     1        r--  =
15616.6
g3                                          18   131     1        r--  =
43006.0
b1                                        20   512     5        r--   =
4133.2
t1                                          21   259     1        r-- =
140468.7
d80                                         22   515     5        r--  =
50262.9
g2                                          38    83     1        r--  =
34071.0
d82                                         40   771     5        r--  =
17699.5
j2                                          41  1027     5        r--  =
68179.1
d75                                         43    99     1        r--  =
13325.7
d74                                         52   771     1        r--   =
9707.6
t3                                          53   515     5        r--   =
7913.0
# xm list
Name                                        ID   Mem VCPUs      State   =
Time(s)
Domain-0                                     0   512     6     r----- =
313274.1
a1                                       13  2048     4     -b---- =
160412.8
b1                                        20   512     5     ------   =
4133.4
c2                                           1  4096     5     -b---- =
111508.6
c3                                           4   512     5     -b----   =
6419.5
d70                                          7  1000     1     -b----  =
77163.8
d73                                          8   512     1     -b---- =
237155.4
d74                                         52   768     1     -b----   =
9709.6
d75                                         43    96     1     -b----  =
13327.6
d80                                         22   512     5     -b----  =
50266.4
d82                                         40   768     5     -b----  =
17700.9
g2                                          38    80     1     -b----  =
34073.4
g3                                          18   128     1     -b----  =
43008.1
g4                                          15    96     1     -b----  =
15617.3
j2                                          41  1024     5     -b----  =
68192.6
s1                                       6  1024     2     -b----  =
19594.0
t1                                          21   256     1     r----- =
140478.2
t2                                          12   512     5     -b----  =
38609.1
t3                                          53   512     5     -b----   =
7914.8
v01                                         10    90     1     -b----  =
48164.8

------=_NextPart_000_0234_01CCDCF3.F50B1690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY><!-- Template: 'Reply Mail (00000003)' --><!-- Greeting -->
<DIV><SPAN id=3Dresult_box lang=3Den class=3Dshort_text =
closure_uid_bkpfes=3D"182"=20
Kc=3D"null" a=3D"undefined" c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"23813"><SPAN=20
id=3Dresult_box lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
Kc=3D"null"=20
a=3D"undefined" c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"23937">Sorry</SPAN><SPAN=20
closure_uid_bkpfes=3D"23938">, quoting</SPAN> <SPAN class=3Dhps=20
closure_uid_bkpfes=3D"23939">lines</SPAN> <SPAN class=3Dhps=20
closure_uid_bkpfes=3D"23940">cut</SPAN><SPAN =
closure_uid_bkpfes=3D"23941">, and I=20
repeat</SPAN> <SPAN class=3Dhps closure_uid_bkpfes=3D"23942">the=20
message</SPAN></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
Kc=3D"null"=20
a=3D"undefined" c=3D"4"><SPAN class=3Dhps =
closure_uid_bkpfes=3D"23813"><SPAN lang=3Den=20
class=3Dshort_text closure_uid_bkpfes=3D"182" Kc=3D"null" =
a=3D"undefined" c=3D"4"><SPAN=20
class=3Dhps =
closure_uid_bkpfes=3D"23942"></SPAN></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3Den class=3Dshort_text closure_uid_bkpfes=3D"182" =
Kc=3D"null"=20
a=3D"undefined" c=3D"4"><SPAN class=3Dhps closure_uid_bkpfes=3D"23816">
<DIV>Compare the two results on the same system.</DIV>
<DIV>xl - not sorted alphabetically and by memory shows the=20
nonsense</DIV></SPAN></SPAN></DIV>
<DIV><FONT size=3D2 face=3DArial># xl=20
list<BR>Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ID&nbsp;&nbsp; Mem VCPUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State&nbsp;&nbsp; =

Time(s)<BR>Domain-0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp;=20
6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
313260.0<BR>c2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp; 4096&nbsp;&nbsp;&nbsp;&nbsp; =
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
r--=20
111502.1<BR>c3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
4&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp;=20
6419.4<BR>s1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
6&nbsp; 1027&nbsp;&nbsp;&nbsp;&nbsp; =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
r--&nbsp;=20
19593.0<BR>d70&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
7&nbsp; 1003&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
r--&nbsp;=20
77161.6<BR>d73&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
8&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
237146.7<BR>v01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10&nbsp;&nbsp;&nbsp; 93&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
48162.9<BR>t2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
12&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
38607.5<BR>a1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
13&nbsp; 2050&nbsp;&nbsp;&nbsp;&nbsp;=20
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
160406.0<BR>g4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
15&nbsp;&nbsp;&nbsp; 99&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
15616.6<BR>g3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
18&nbsp;&nbsp; 131&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
43006.0<BR>b1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
20&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp;=20
4133.2<BR>t1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
21&nbsp;&nbsp; 259&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--=20
140468.7<BR>d80&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
22&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
50262.9<BR>g2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
38&nbsp;&nbsp;&nbsp; 83&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
34071.0<BR>d82&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
40&nbsp;&nbsp; 771&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
17699.5<BR>j2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
41&nbsp; 1027&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
68179.1<BR>d75&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
43&nbsp;&nbsp;&nbsp; 99&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;=20
13325.7<BR>d74&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
52&nbsp;&nbsp; 771&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp;=20
9707.6<BR>t3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
53&nbsp;&nbsp; 515&nbsp;&nbsp;&nbsp;&nbsp;=20
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r--&nbsp;&nbsp; 7913.0<BR># =
xm=20
list<BR>Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ID&nbsp;&nbsp; Mem VCPUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State&nbsp;&nbsp; =

Time(s)<BR>Domain-0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp;&nbsp; =
r-----=20
313274.1<BR>a1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
13&nbsp; 2048&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp; -b----=20
160412.8<BR>b1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
20&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
------&nbsp;&nbsp;=20
4133.4<BR>c2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp; 4096&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp; -b----=20
111508.6<BR>c3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
4&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;&nbsp;=20
6419.5<BR>d70&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
7&nbsp; 1000&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; =
-b----&nbsp;=20
77163.8<BR>d73&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
8&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; =
-b----=20
237155.4<BR>d74&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
52&nbsp;&nbsp; 768&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;&nbsp;=20
9709.6<BR>d75&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
43&nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
13327.6<BR>d80&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
22&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
50266.4<BR>d82&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
40&nbsp;&nbsp; 768&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
17700.9<BR>g2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
38&nbsp;&nbsp;&nbsp; 80&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
34073.4<BR>g3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
18&nbsp;&nbsp; 128&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
43008.1<BR>g4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
15&nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
15617.3<BR>j2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
41&nbsp; 1024&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp; =
-b----&nbsp;=20
68192.6<BR>s1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
6&nbsp; 1024&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp; =
-b----&nbsp;=20
19594.0<BR>t1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
21&nbsp;&nbsp; 256&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; =
r-----=20
140478.2<BR>t2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
12&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;=20
38609.1<BR>t3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
53&nbsp;&nbsp; 512&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp;&nbsp;=20
7914.8<BR>v01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
10&nbsp;&nbsp;&nbsp; 90&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;=20
-b----&nbsp; 48164.8<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0234_01CCDCF3.F50B1690--



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

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

--===============3679858672347343400==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBy-0002ox-Nr; Wed, 01 Feb 2012 10:13:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maciej.rutecki@gmail.com>) id 1RrQxo-0000CJ-Vt
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 09:22:21 +0000
X-Env-Sender: maciej.rutecki@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327828913!63614391!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31165 invoked from network); 29 Jan 2012 09:21:53 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jan 2012 09:21:53 -0000
Received: by eaad12 with SMTP id d12so12866168eaa.30
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 01:22:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to
	:mime-version:content-type:content-transfer-encoding:message-id;
	bh=4XqC+v0nRl9Cf8jByfu3aIuR35SIY8ShK0GGT6ZfWVk=;
	b=dQRZZbuqW4UcSALkZ0CtGCKhJkPYZc8aeM7l5N4+B+yVMRJ7QQf+VP6iJoF6WriKlI
	xPZBXYjdj8xaXa5Kbq9u8tkaN6zJBZjYlpse8H9Shsb53WQfLV5I6jyuLpGkxjze26pb
	otSmsiJQrsn5ugDCtftz9aDyMf75AFbbqk7VI=
Received: by 10.213.22.84 with SMTP id m20mr799667ebb.38.1327828934312;
	Sun, 29 Jan 2012 01:22:14 -0800 (PST)
Received: from leon.localnet (89-77-8-196.dynamic.chello.pl. [89.77.8.196])
	by mx.google.com with ESMTPS id c16sm55715562eei.1.2012.01.29.01.22.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 29 Jan 2012 01:22:12 -0800 (PST)
From: Maciej Rutecki <maciej.rutecki@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sun, 29 Jan 2012 10:22:09 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0; KDE/4.6.5; x86_64; ; )
References: <20120123180601.GA24553@phenom.dumpdata.com>
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Message-Id: <201201291022.09258.maciej.rutecki@gmail.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
	function,
	it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: maciej.rutecki@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBjcmVhdGVkIGEgQnVnemlsbGEgZW50cnkgYXQgCmh0dHBzOi8vYnVnemlsbGEua2VybmVsLm9y
Zy9zaG93X2J1Zy5jZ2k/aWQ9NDI2ODMKZm9yIHlvdXIgYnVnIHJlcG9ydCwgcGxlYXNlIGFkZCB5
b3VyIGFkZHJlc3MgdG8gdGhlIENDIGxpc3QgaW4gdGhlcmUsIHRoYW5rcyEKCk9uIHBvbmllZHpp
YcWCZWssIDIzIHN0eWN6bmlhIDIwMTIgbyAxOTowNjowMSBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gV2hlbiBJIGJyaW5nIGEgQ1BVIGRvd24gaW4gYSBndWVzdCAod2hpY2ggc2hvdWxk
IGJlIHRoZSBzYW1lIGFzIGJyaW5naW5nIGEKPiBDUFUgZG93biB1c2luZyB0aGUgQUNQSSBmcmFt
ZXdvcmspLCBJIGdldCB0aGlzOgo+IAo+IFsgICAxNC40ODQyMDZdIFNNUCBhbHRlcm5hdGl2ZXM6
IHN3aXRjaGluZyB0byBVUCBjb2RlCj4gWyAgIDE0LjUxNDI4N10gLS0tLS0tLS0tLS0tWyBjdXQg
aGVyZSBdLS0tLS0tLS0tLS0tCj4gWyAgIDE0LjUxNDMxOF0gV0FSTklORzogYXQgL2hvbWUva29u
cmFkL2xpbnV4LWxpbnVzL2RyaXZlcnMvYmFzZS9jb3JlLmM6MTk0Cj4gZGV2aWNlX3JlbGVhc2Ur
MHg4Mi8weDkwKCkgWyAgIDE0LjUxNDM1NF0gRGV2aWNlICdjcHUxJyBkb2VzIG5vdCBoYXZlIGEK
PiByZWxlYXNlKCkgZnVuY3Rpb24sIGl0IGlzIGJyb2tlbiBhbmQgbXVzdCBiZSBmaXhlZC4gWyAg
IDE0LjUxNDM4Nl0gTW9kdWxlcwo+IGxpbmtlZCBpbjogcmFkZW9uIGZiY29uIHRpbGVibGl0IGZv
bnQgdHRtIGJpdGJsaXQgc29mdGN1cnNvcgo+IGRybV9rbXNfaGVscGVyIHhlbl9ibGtmcm9udCB4
ZW5fbmV0ZnJvbnQgeGVuX2ZiZnJvbnQgZmJfc3lzX2ZvcHMgc3lzaW1nYmx0Cj4gc3lzZmlsbHJl
Y3Qgc3lzY29weWFyZWEgeGVuX2tiZGZyb250IHhlbmZzIHhlbl9wcml2Y21kIFsgICAxNC41MTQ1
NTddIFBpZDoKPiAyMiwgY29tbTogeGVud2F0Y2ggTm90IHRhaW50ZWQgMy4zLjAtcmMxICMxCj4g
WyAgIDE0LjUxNDU4Nl0gQ2FsbCBUcmFjZToKPiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgx
MDg5N2ZhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwCj4gWyAgIDE0LjUxNTA5NF0g
IFs8ZmZmZmZmZmY4MTA4OThkMT5dIHdhcm5fc2xvd3BhdGhfZm10KzB4NDEvMHg1MAo+IFsgICAx
NC41MTUwOTRdICBbPGZmZmZmZmZmODEzZGVhMDI+XSBkZXZpY2VfcmVsZWFzZSsweDgyLzB4OTAK
PiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgxMmRmYjg1Pl0ga29iamVjdF9yZWxlYXNlKzB4
NDUvMHg5MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEyZGZhNGM+XSBrb2JqZWN0X3B1
dCsweDJjLzB4NjAKPiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgxM2RlNmEyPl0gcHV0X2Rl
dmljZSsweDEyLzB4MjAKPiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgxM2RmNDA5Pl0gZGV2
aWNlX3VucmVnaXN0ZXIrMHgxOS8weDIwCj4gWyAgIDE0LjUxNTA5NF0gIFs8ZmZmZmZmZmY4MTNl
NGVkZj5dIHVucmVnaXN0ZXJfY3B1KzB4NGYvMHg4MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZm
ZmZmODEwNTJjN2M+XSBhcmNoX3VucmVnaXN0ZXJfY3B1KzB4MWMvMHgyMAo+IFsgICAxNC41MTUw
OTRdICBbPGZmZmZmZmZmODEzN2Y3ODc+XSBoYW5kbGVfdmNwdV9ob3RwbHVnX2V2ZW50KzB4Yzcv
MHhkMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEzN2I5MDA+XSB4ZW53YXRjaF90aHJl
YWQrMHhiMC8weDE4MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEwYWQzZjA+XSA/IHdh
a2VfdXBfYml0KzB4NDAvMHg0MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEzN2I4NTA+
XSA/IHNwbGl0KzB4ZjAvMHhmMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEwYWNkMTY+
XSBrdGhyZWFkKzB4OTYvMHhhMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODE2MTUxZTQ+
XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDQvMHgxMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZm
ZmZmODE2MGNjODA+XSA/IHJldGludF9yZXN0b3JlX2FyZ3MrMHg1LzB4Ngo+IFsgICAxNC41MTUw
OTRdICBbPGZmZmZmZmZmODE2MTUxZTA+XSA/IGdzX2NoYW5nZSsweDEzLzB4MTMKPiBbICAgMTQu
NTE1MDk0XSAtLS1bIGVuZCB0cmFjZSA4ZjcwYWY1MWEyZTI2MTFmIF0tLS0KPiAKPiBMb29raW5n
IGF0ICJjb21taXQgZTAzMmQ4MDc3NDMxNTg2OWFhMjI4NWIyMTdmZGJiZmVkODZjMGI0OQo+IEF1
dGhvcjogR3JlZyBLcm9haC1IYXJ0bWFuIDxncmVna2hAc3VzZS5kZT4KPiBEYXRlOiAgIE1vbiBK
YW4gMTYgMTQ6NDA6MjggMjAxMiAtMDgwMAo+IAo+ICAgICBtY2U6IGZpeCB3YXJuaW5nIG1lc3Nh
Z2VzIGFib3V0IHN0YXRpYyBzdHJ1Y3QgbWNlX2RldmljZQo+ICIKPiAKPiBpdCBsb29rcyBsaWtl
IHRoZSBjb3JyZXQgZml4IGlzIHRvIG1ha2UgdGhlICdjcHVfZGV2aWNlcycgaW4KPiBhcmNoL3g4
Ni9rZXJuZWwvdG9wb2xvZ3kuYyB0byBiZSBjaGFuZ2VkIHRvIGJlIG1vcmUgZHluYW1pYwo+IChv
ciBwZXJoYXBzIGhhdmUgYW4gZW1wdHkgcmVsZWFzZSBmdW5jdGlvbik/Cj4gCj4gSXMgYW55Ym9k
eSBlbHNlIGhpdHRpbmcgdGhpcyB3aXRoIEFDUEkgQ1BVIGhvdC11bnBsdWc/IE9yIGRvIEkgaGF2
ZQo+IHRoZSBwcml2aWxpZ2Ugb2YgYmVpbmcgdGhlIGZpcnN0PyBPaCwgSSBoYWRuJ3QgZG9uZSBh
IGZ1bGwgYmlzZWN0aW9uCj4gYnV0IHYzLjIgZG9lcyBub3QgaGF2ZSB0aGlzLgo+IAo+IFRoZSBn
dWVzdCBjb25maWcgaXMgcXVpdGUgc2ltcGxlOgo+IGV4dHJhPSJjb25zb2xlPWh2YzAgZGVidWcg
ZWFybHlwcmludGs9eGVuIG1lbWJsb2NrPWRlYnVnIgo+IGtlcm5lbD0iL21udC9sYWIvYm9vdHN0
cmFwLXg4Nl82NC92bWxpbnV6Igo+IHJhbWRpc2s9Ii9tbnQvbGFiL2Jvb3RzdHJhcC14ODZfNjQv
aW5pdHJhbWZzLmNwaW8uZ3oiCj4gbWVtb3J5PTEwMjQKPiBtYXhtZW09MjA0OAo+IHZjcHVzPTIK
PiBuYW1lPSJib290c3RyYXAteDg2XzY0Igo+IG9uX2NyYXNoPSJwcmVzZXJ2ZSIKPiB2ZmIgPSBb
ICd2bmM9MSwgdm5jbGlzdGVuPTAuMC4wLjAsdm5jdW51c2VkPTEnXQo+IC0tCj4gVG8gdW5zdWJz
Y3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWtl
cm5lbCIgaW4KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVs
Lm9yZwo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFq
b3Jkb21vLWluZm8uaHRtbAo+IFBsZWFzZSByZWFkIHRoZSBGQVEgYXQgIGh0dHA6Ly93d3cudHV4
Lm9yZy9sa21sLwoKLS0gCk1hY2llaiBSdXRlY2tpCmh0dHA6Ly93d3cubXJ1dGVja2kucGwKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhl
bnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXBy-0002ox-Nr; Wed, 01 Feb 2012 10:13:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maciej.rutecki@gmail.com>) id 1RrQxo-0000CJ-Vt
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 09:22:21 +0000
X-Env-Sender: maciej.rutecki@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327828913!63614391!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31165 invoked from network); 29 Jan 2012 09:21:53 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jan 2012 09:21:53 -0000
Received: by eaad12 with SMTP id d12so12866168eaa.30
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 01:22:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to
	:mime-version:content-type:content-transfer-encoding:message-id;
	bh=4XqC+v0nRl9Cf8jByfu3aIuR35SIY8ShK0GGT6ZfWVk=;
	b=dQRZZbuqW4UcSALkZ0CtGCKhJkPYZc8aeM7l5N4+B+yVMRJ7QQf+VP6iJoF6WriKlI
	xPZBXYjdj8xaXa5Kbq9u8tkaN6zJBZjYlpse8H9Shsb53WQfLV5I6jyuLpGkxjze26pb
	otSmsiJQrsn5ugDCtftz9aDyMf75AFbbqk7VI=
Received: by 10.213.22.84 with SMTP id m20mr799667ebb.38.1327828934312;
	Sun, 29 Jan 2012 01:22:14 -0800 (PST)
Received: from leon.localnet (89-77-8-196.dynamic.chello.pl. [89.77.8.196])
	by mx.google.com with ESMTPS id c16sm55715562eei.1.2012.01.29.01.22.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 29 Jan 2012 01:22:12 -0800 (PST)
From: Maciej Rutecki <maciej.rutecki@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sun, 29 Jan 2012 10:22:09 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0; KDE/4.6.5; x86_64; ; )
References: <20120123180601.GA24553@phenom.dumpdata.com>
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Message-Id: <201201291022.09258.maciej.rutecki@gmail.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
	function,
	it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: maciej.rutecki@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBjcmVhdGVkIGEgQnVnemlsbGEgZW50cnkgYXQgCmh0dHBzOi8vYnVnemlsbGEua2VybmVsLm9y
Zy9zaG93X2J1Zy5jZ2k/aWQ9NDI2ODMKZm9yIHlvdXIgYnVnIHJlcG9ydCwgcGxlYXNlIGFkZCB5
b3VyIGFkZHJlc3MgdG8gdGhlIENDIGxpc3QgaW4gdGhlcmUsIHRoYW5rcyEKCk9uIHBvbmllZHpp
YcWCZWssIDIzIHN0eWN6bmlhIDIwMTIgbyAxOTowNjowMSBLb25yYWQgUnplc3p1dGVrIFdpbGsg
d3JvdGU6Cj4gV2hlbiBJIGJyaW5nIGEgQ1BVIGRvd24gaW4gYSBndWVzdCAod2hpY2ggc2hvdWxk
IGJlIHRoZSBzYW1lIGFzIGJyaW5naW5nIGEKPiBDUFUgZG93biB1c2luZyB0aGUgQUNQSSBmcmFt
ZXdvcmspLCBJIGdldCB0aGlzOgo+IAo+IFsgICAxNC40ODQyMDZdIFNNUCBhbHRlcm5hdGl2ZXM6
IHN3aXRjaGluZyB0byBVUCBjb2RlCj4gWyAgIDE0LjUxNDI4N10gLS0tLS0tLS0tLS0tWyBjdXQg
aGVyZSBdLS0tLS0tLS0tLS0tCj4gWyAgIDE0LjUxNDMxOF0gV0FSTklORzogYXQgL2hvbWUva29u
cmFkL2xpbnV4LWxpbnVzL2RyaXZlcnMvYmFzZS9jb3JlLmM6MTk0Cj4gZGV2aWNlX3JlbGVhc2Ur
MHg4Mi8weDkwKCkgWyAgIDE0LjUxNDM1NF0gRGV2aWNlICdjcHUxJyBkb2VzIG5vdCBoYXZlIGEK
PiByZWxlYXNlKCkgZnVuY3Rpb24sIGl0IGlzIGJyb2tlbiBhbmQgbXVzdCBiZSBmaXhlZC4gWyAg
IDE0LjUxNDM4Nl0gTW9kdWxlcwo+IGxpbmtlZCBpbjogcmFkZW9uIGZiY29uIHRpbGVibGl0IGZv
bnQgdHRtIGJpdGJsaXQgc29mdGN1cnNvcgo+IGRybV9rbXNfaGVscGVyIHhlbl9ibGtmcm9udCB4
ZW5fbmV0ZnJvbnQgeGVuX2ZiZnJvbnQgZmJfc3lzX2ZvcHMgc3lzaW1nYmx0Cj4gc3lzZmlsbHJl
Y3Qgc3lzY29weWFyZWEgeGVuX2tiZGZyb250IHhlbmZzIHhlbl9wcml2Y21kIFsgICAxNC41MTQ1
NTddIFBpZDoKPiAyMiwgY29tbTogeGVud2F0Y2ggTm90IHRhaW50ZWQgMy4zLjAtcmMxICMxCj4g
WyAgIDE0LjUxNDU4Nl0gQ2FsbCBUcmFjZToKPiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgx
MDg5N2ZhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwCj4gWyAgIDE0LjUxNTA5NF0g
IFs8ZmZmZmZmZmY4MTA4OThkMT5dIHdhcm5fc2xvd3BhdGhfZm10KzB4NDEvMHg1MAo+IFsgICAx
NC41MTUwOTRdICBbPGZmZmZmZmZmODEzZGVhMDI+XSBkZXZpY2VfcmVsZWFzZSsweDgyLzB4OTAK
PiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgxMmRmYjg1Pl0ga29iamVjdF9yZWxlYXNlKzB4
NDUvMHg5MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEyZGZhNGM+XSBrb2JqZWN0X3B1
dCsweDJjLzB4NjAKPiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgxM2RlNmEyPl0gcHV0X2Rl
dmljZSsweDEyLzB4MjAKPiBbICAgMTQuNTE1MDk0XSAgWzxmZmZmZmZmZjgxM2RmNDA5Pl0gZGV2
aWNlX3VucmVnaXN0ZXIrMHgxOS8weDIwCj4gWyAgIDE0LjUxNTA5NF0gIFs8ZmZmZmZmZmY4MTNl
NGVkZj5dIHVucmVnaXN0ZXJfY3B1KzB4NGYvMHg4MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZm
ZmZmODEwNTJjN2M+XSBhcmNoX3VucmVnaXN0ZXJfY3B1KzB4MWMvMHgyMAo+IFsgICAxNC41MTUw
OTRdICBbPGZmZmZmZmZmODEzN2Y3ODc+XSBoYW5kbGVfdmNwdV9ob3RwbHVnX2V2ZW50KzB4Yzcv
MHhkMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEzN2I5MDA+XSB4ZW53YXRjaF90aHJl
YWQrMHhiMC8weDE4MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEwYWQzZjA+XSA/IHdh
a2VfdXBfYml0KzB4NDAvMHg0MAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEzN2I4NTA+
XSA/IHNwbGl0KzB4ZjAvMHhmMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODEwYWNkMTY+
XSBrdGhyZWFkKzB4OTYvMHhhMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZmZmZmODE2MTUxZTQ+
XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDQvMHgxMAo+IFsgICAxNC41MTUwOTRdICBbPGZmZmZm
ZmZmODE2MGNjODA+XSA/IHJldGludF9yZXN0b3JlX2FyZ3MrMHg1LzB4Ngo+IFsgICAxNC41MTUw
OTRdICBbPGZmZmZmZmZmODE2MTUxZTA+XSA/IGdzX2NoYW5nZSsweDEzLzB4MTMKPiBbICAgMTQu
NTE1MDk0XSAtLS1bIGVuZCB0cmFjZSA4ZjcwYWY1MWEyZTI2MTFmIF0tLS0KPiAKPiBMb29raW5n
IGF0ICJjb21taXQgZTAzMmQ4MDc3NDMxNTg2OWFhMjI4NWIyMTdmZGJiZmVkODZjMGI0OQo+IEF1
dGhvcjogR3JlZyBLcm9haC1IYXJ0bWFuIDxncmVna2hAc3VzZS5kZT4KPiBEYXRlOiAgIE1vbiBK
YW4gMTYgMTQ6NDA6MjggMjAxMiAtMDgwMAo+IAo+ICAgICBtY2U6IGZpeCB3YXJuaW5nIG1lc3Nh
Z2VzIGFib3V0IHN0YXRpYyBzdHJ1Y3QgbWNlX2RldmljZQo+ICIKPiAKPiBpdCBsb29rcyBsaWtl
IHRoZSBjb3JyZXQgZml4IGlzIHRvIG1ha2UgdGhlICdjcHVfZGV2aWNlcycgaW4KPiBhcmNoL3g4
Ni9rZXJuZWwvdG9wb2xvZ3kuYyB0byBiZSBjaGFuZ2VkIHRvIGJlIG1vcmUgZHluYW1pYwo+IChv
ciBwZXJoYXBzIGhhdmUgYW4gZW1wdHkgcmVsZWFzZSBmdW5jdGlvbik/Cj4gCj4gSXMgYW55Ym9k
eSBlbHNlIGhpdHRpbmcgdGhpcyB3aXRoIEFDUEkgQ1BVIGhvdC11bnBsdWc/IE9yIGRvIEkgaGF2
ZQo+IHRoZSBwcml2aWxpZ2Ugb2YgYmVpbmcgdGhlIGZpcnN0PyBPaCwgSSBoYWRuJ3QgZG9uZSBh
IGZ1bGwgYmlzZWN0aW9uCj4gYnV0IHYzLjIgZG9lcyBub3QgaGF2ZSB0aGlzLgo+IAo+IFRoZSBn
dWVzdCBjb25maWcgaXMgcXVpdGUgc2ltcGxlOgo+IGV4dHJhPSJjb25zb2xlPWh2YzAgZGVidWcg
ZWFybHlwcmludGs9eGVuIG1lbWJsb2NrPWRlYnVnIgo+IGtlcm5lbD0iL21udC9sYWIvYm9vdHN0
cmFwLXg4Nl82NC92bWxpbnV6Igo+IHJhbWRpc2s9Ii9tbnQvbGFiL2Jvb3RzdHJhcC14ODZfNjQv
aW5pdHJhbWZzLmNwaW8uZ3oiCj4gbWVtb3J5PTEwMjQKPiBtYXhtZW09MjA0OAo+IHZjcHVzPTIK
PiBuYW1lPSJib290c3RyYXAteDg2XzY0Igo+IG9uX2NyYXNoPSJwcmVzZXJ2ZSIKPiB2ZmIgPSBb
ICd2bmM9MSwgdm5jbGlzdGVuPTAuMC4wLjAsdm5jdW51c2VkPTEnXQo+IC0tCj4gVG8gdW5zdWJz
Y3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWtl
cm5lbCIgaW4KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVs
Lm9yZwo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFq
b3Jkb21vLWluZm8uaHRtbAo+IFBsZWFzZSByZWFkIHRoZSBGQVEgYXQgIGh0dHA6Ly93d3cudHV4
Lm9yZy9sa21sLwoKLS0gCk1hY2llaiBSdXRlY2tpCmh0dHA6Ly93d3cubXJ1dGVja2kucGwKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhl
bnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 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.xensource.com>)
	id 1RsXC0-0002pj-DW; Wed, 01 Feb 2012 10:13:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <viral.vkm@gmail.com>) id 1RruPu-0000lW-2E
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:49:18 +0000
X-Env-Sender: viral.vkm@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327942151!12752240!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16613 invoked from network); 30 Jan 2012 16:49:12 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:49:12 -0000
Received: by wibhm2 with SMTP id hm2so13785656wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 08:49:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=PmLvbhDzGjiFyTMZg0ZQDI+YHMb5vPs3Uo3puii/pXU=;
	b=iHvfpJqxOTvF9fY+1PbE/xbCs7Zbhw2Xaf9N6SH+XIl89uitYd4zU368tnK5J0KEqw
	7AJYwCXzaDge7SUolRkW1xCZ/QeXcPZ7qPzSvX0Y9WbQwa6UFUX3RqaHB/XKLWpA8AcF
	Dc79o8C+MzR+v4bQp9tP3UPTw/tE+eEJhSY6o=
MIME-Version: 1.0
Received: by 10.180.24.105 with SMTP id t9mr28642463wif.19.1327942151775; Mon,
	30 Jan 2012 08:49:11 -0800 (PST)
Received: by 10.180.87.168 with HTTP; Mon, 30 Jan 2012 08:49:11 -0800 (PST)
In-Reply-To: <1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
Date: Mon, 30 Jan 2012 11:49:11 -0500
Message-ID: <CANX6Dak_1VQ1J8hRK+yd1-FmGOnd75BkNm2uUVKd_TNTiNLtxg@mail.gmail.com>
From: Viral Mehta <viral.vkm@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V3 04/16] netback: switch to per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Mon, Jan 30, 2012 at 9:45 AM, Wei Liu <wei.liu2@citrix.com> wrote:
>
> =A0 =A0 =A0 =A0skb_queue_head_init(&rxq);
> @@ -534,13 +527,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
> + =A0 =A0 =A0 BUG_ON(npo.meta_prod > MAX_PENDING_REQS);

While you are already here,
how about having WARN_ON() ?

>
> - =A0 =A0 =A0 if (!npo.copy_prod)
> + =A0 =A0 =A0 if (!npo.copy_prod) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 put_cpu_ptr(gco);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 put_cpu_ptr(m);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
> + =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> - =A0 =A0 =A0 ret =3D HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->gr=
ant_copy_op,
> + =A0 =A0 =A0 BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));

And may be here, too...

If there is serious bug, may be system will crash at a later point
But, IMHO, WARN_ON() is the correct function for drivers at least.

> + =A0 =A0 =A0 ret =3D HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0npo.copy_prod);
> =A0 =A0 =A0 =A0BUG_ON(ret !=3D 0);
>
-- =

Thanks,
Viral Mehta

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 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.xensource.com>)
	id 1RsXC0-0002pj-DW; Wed, 01 Feb 2012 10:13:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <viral.vkm@gmail.com>) id 1RruPu-0000lW-2E
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:49:18 +0000
X-Env-Sender: viral.vkm@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327942151!12752240!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16613 invoked from network); 30 Jan 2012 16:49:12 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:49:12 -0000
Received: by wibhm2 with SMTP id hm2so13785656wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 08:49:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=PmLvbhDzGjiFyTMZg0ZQDI+YHMb5vPs3Uo3puii/pXU=;
	b=iHvfpJqxOTvF9fY+1PbE/xbCs7Zbhw2Xaf9N6SH+XIl89uitYd4zU368tnK5J0KEqw
	7AJYwCXzaDge7SUolRkW1xCZ/QeXcPZ7qPzSvX0Y9WbQwa6UFUX3RqaHB/XKLWpA8AcF
	Dc79o8C+MzR+v4bQp9tP3UPTw/tE+eEJhSY6o=
MIME-Version: 1.0
Received: by 10.180.24.105 with SMTP id t9mr28642463wif.19.1327942151775; Mon,
	30 Jan 2012 08:49:11 -0800 (PST)
Received: by 10.180.87.168 with HTTP; Mon, 30 Jan 2012 08:49:11 -0800 (PST)
In-Reply-To: <1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
Date: Mon, 30 Jan 2012 11:49:11 -0500
Message-ID: <CANX6Dak_1VQ1J8hRK+yd1-FmGOnd75BkNm2uUVKd_TNTiNLtxg@mail.gmail.com>
From: Viral Mehta <viral.vkm@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V3 04/16] netback: switch to per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On Mon, Jan 30, 2012 at 9:45 AM, Wei Liu <wei.liu2@citrix.com> wrote:
>
> =A0 =A0 =A0 =A0skb_queue_head_init(&rxq);
> @@ -534,13 +527,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
> + =A0 =A0 =A0 BUG_ON(npo.meta_prod > MAX_PENDING_REQS);

While you are already here,
how about having WARN_ON() ?

>
> - =A0 =A0 =A0 if (!npo.copy_prod)
> + =A0 =A0 =A0 if (!npo.copy_prod) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 put_cpu_ptr(gco);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 put_cpu_ptr(m);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
> + =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> - =A0 =A0 =A0 ret =3D HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->gr=
ant_copy_op,
> + =A0 =A0 =A0 BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));

And may be here, too...

If there is serious bug, may be system will crash at a later point
But, IMHO, WARN_ON() is the correct function for drivers at least.

> + =A0 =A0 =A0 ret =3D HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0npo.copy_prod);
> =A0 =A0 =A0 =A0BUG_ON(ret !=3D 0);
>
-- =

Thanks,
Viral Mehta

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXC2-0002qF-G7; Wed, 01 Feb 2012 10:13:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1RrwZu-0004fi-U5
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:07:47 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327950459!12921368!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6985 invoked from network); 30 Jan 2012 19:07:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 19:07:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21425481"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:07:38 -0500
Received: from REDBLD-XS.ad.xensource.com (10.232.6.25) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:07:36 -0500
MIME-Version: 1.0
X-Mercurial-Node: 4952090d35e0cf5deb8697356a4862f776ba3a6f
Message-ID: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 30 Jan 2012 11:07:35 -0800
From: Santosh Jodh <santosh.jodh@citrix.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace malloc with alloc in hot paths for improved performance.

Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>

diff -r e2722b24dc09 -r 4952090d35e0 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_linux_osdep.c	Mon Jan 30 11:02:32 2012 -0800
@@ -242,7 +242,7 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
-        xen_pfn_t *pfn = malloc(num * sizeof(*pfn));
+        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
 
         if ( pfn )
         {
@@ -288,8 +288,6 @@ static void *linux_privcmd_map_foreign_b
                 break;
             }
 
-            free(pfn);
-
             if ( rc == -ENOENT && i == num )
                 rc = 0;
             else if ( rc )
@@ -524,7 +522,7 @@ static void *linux_gnttab_grant_map(xc_g
     if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
         domids_stride = 0;
 
-    map = malloc(sizeof(*map) +
+    map = alloca(sizeof(*map) +
                  (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
     if ( map == NULL )
         return NULL;
@@ -598,7 +596,6 @@ static void *linux_gnttab_grant_map(xc_g
     }
 
  out:
-    free(map);
 
     return addr;
 }

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:13:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXC2-0002qF-G7; Wed, 01 Feb 2012 10:13:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1RrwZu-0004fi-U5
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:07:47 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327950459!12921368!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6985 invoked from network); 30 Jan 2012 19:07:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 19:07:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21425481"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:07:38 -0500
Received: from REDBLD-XS.ad.xensource.com (10.232.6.25) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:07:36 -0500
MIME-Version: 1.0
X-Mercurial-Node: 4952090d35e0cf5deb8697356a4862f776ba3a6f
Message-ID: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 30 Jan 2012 11:07:35 -0800
From: Santosh Jodh <santosh.jodh@citrix.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 01 Feb 2012 10:12:42 +0000
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace malloc with alloc in hot paths for improved performance.

Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>

diff -r e2722b24dc09 -r 4952090d35e0 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_linux_osdep.c	Mon Jan 30 11:02:32 2012 -0800
@@ -242,7 +242,7 @@ static void *linux_privcmd_map_foreign_b
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
-        xen_pfn_t *pfn = malloc(num * sizeof(*pfn));
+        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
 
         if ( pfn )
         {
@@ -288,8 +288,6 @@ static void *linux_privcmd_map_foreign_b
                 break;
             }
 
-            free(pfn);
-
             if ( rc == -ENOENT && i == num )
                 rc = 0;
             else if ( rc )
@@ -524,7 +522,7 @@ static void *linux_gnttab_grant_map(xc_g
     if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
         domids_stride = 0;
 
-    map = malloc(sizeof(*map) +
+    map = alloca(sizeof(*map) +
                  (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
     if ( map == NULL )
         return NULL;
@@ -598,7 +596,6 @@ static void *linux_gnttab_grant_map(xc_g
     }
 
  out:
-    free(map);
 
     return addr;
 }

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:19:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 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.xensource.com>)
	id 1RsXHH-0000Rw-Ba; Wed, 01 Feb 2012 10:18:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsXH4-0000JW-5f
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:18:46 +0000
Received: from [85.158.138.51:17755] by server-8.bemta-3.messagelabs.com id
	88/91-31878-581192F4; Wed, 01 Feb 2012 10:18:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328091524!11548051!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23516 invoked from network); 1 Feb 2012 10:18:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 10:18:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 01 Feb 2012 10:18:43 +0000
Message-Id: <4F291F910200007800070467@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 01 Feb 2012 10:18:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <a8abf3fae8ae919141b4.1328037416@wotan.osrc.amd.com>
In-Reply-To: <a8abf3fae8ae919141b4.1328037416@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 20:16, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> @@ -502,6 +503,20 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /* 
> +         * Certain operations (e.g. CPU microcode updates) modify data which is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                domain_unpause(d);
> +                rcu_unlock_domain(d);
> +                break;

This "break" will only get you out of the while() loop, falling through
into the immediately following code (without holding the lock), which
is not what you want afaict.

Jan

> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:19:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 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.xensource.com>)
	id 1RsXHH-0000Rw-Ba; Wed, 01 Feb 2012 10:18:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsXH4-0000JW-5f
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:18:46 +0000
Received: from [85.158.138.51:17755] by server-8.bemta-3.messagelabs.com id
	88/91-31878-581192F4; Wed, 01 Feb 2012 10:18:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328091524!11548051!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23516 invoked from network); 1 Feb 2012 10:18:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 10:18:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 01 Feb 2012 10:18:43 +0000
Message-Id: <4F291F910200007800070467@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 01 Feb 2012 10:18:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <a8abf3fae8ae919141b4.1328037416@wotan.osrc.amd.com>
In-Reply-To: <a8abf3fae8ae919141b4.1328037416@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v3] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 20:16, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> @@ -502,6 +503,20 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /* 
> +         * Certain operations (e.g. CPU microcode updates) modify data which is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                domain_unpause(d);
> +                rcu_unlock_domain(d);
> +                break;

This "break" will only get you out of the while() loop, falling through
into the immediately following code (without holding the lock), which
is not what you want afaict.

Jan

> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXXO-0003TQ-Vn; Wed, 01 Feb 2012 10:35:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RsXXO-0003T2-1T
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:35:38 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328092512!64052762!1
X-Originating-IP: [98.139.212.170]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3344 invoked from network); 1 Feb 2012 10:35:12 -0000
Received: from nm11.bullet.mail.bf1.yahoo.com (HELO
	nm11.bullet.mail.bf1.yahoo.com) (98.139.212.170)
	by server-15.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 10:35:12 -0000
Received: from [98.139.212.150] by nm11.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:35:33 -0000
Received: from [98.139.212.203] by tm7.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:35:33 -0000
Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:35:33 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 22852.38633.bm@omp1012.mail.bf1.yahoo.com
Received: (qmail 6180 invoked by uid 60001); 1 Feb 2012 10:35:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1328092532; bh=0BHSRU3PNA5alLWWgJQDrMX0M5zuQvBDHeSChvRYtjY=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=qLIBLjTixZdu1MGbF4ovZLUp00DBelkXjWghG7RYfQI1fifh5kKsdqVM2kutKwtVrDOPBtmRP2Nnc+q2EvHeTvM7dFmW7D2aayiJvxJIou71FskYxKFtWVRutqEEsQ9XGY+FBiCPJ5iORwzAAYusz1qnw8VlMNR8rOP5VsPWxto=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=CdlGlA0Wrfs6qo9TNIxoW+bXUIsn/H87PxZ8FXSLVgwGwE+Sp3s088J0m/OsRgG205BWXvnS2UQZkYso58XmBYEla87JdfMypog8g2Y/Grrob3yOHKIiB7Uh69W4inaCtwrcmVcflSqofQ2pX2/65/j/c4BqByVaRdgDsJBA/Qg=;
X-YMail-OSG: RMoQxwoVM1l_weBE_skToa2j7DRXfYTgZOLEkZ.y.GJRzKW
	Xed7je9VdZwEoj0pAFXmLsdeSzpV3uYUUTjh9Tq9dHvzwrZCcZhzS2EfM6xx
	XHK_zemQYVMPHqaS5D.6v_21QKRUWAm1DSJmmXdXBcheAUNoKi15ue1t7V62
	K.yRLmcxOpyxWOhhaaO0PavSy.8WqlZMkJ2WlPxzmX3qxNn4FzVEO8GZGHyb
	20xFV8D4Yk92kaNKNnjhwnSZsXLq_A5St8VfivO9II.hDNLxrbSfSUUmOBBA
	HVZ.MDc5Vs_F1wcmvcYfg.spGvAhYAneIbMlhVHXKWsTwW2xf8X9GAKFiQKa
	b8MDtiL8AhTY7ucqdiAP.5CuFxTdf9qMKDCowS0Ar3TUvyOUX5s0JKQ9D55h
	.IFNARtYLnpsYuy9PhQqx6q7iM7XOCZdG4GZyCII2MbQc.XwyFdqYN5WKVXA
	ccENV0lJO5isilL6On9Ku42sy7FtP2FH1f_mHHfrLjuSs1E_CLA--
Received: from [76.73.45.34] by web160905.mail.bf1.yahoo.com via HTTP;
	Wed, 01 Feb 2012 02:35:32 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1328092532.918.YahooMailClassic@web160905.mail.bf1.yahoo.com>
Date: Wed, 1 Feb 2012 02:35:32 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328090692.17444.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3373448936787398232=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3373448936787398232==
Content-Type: multipart/alternative; boundary="-1879531-532089860-1328092532=:918"

---1879531-532089860-1328092532=:918
Content-Type: text/plain; charset=us-ascii

My question was not about configuration, its main propose is how I can embed some initialization parameters in the Xen source code - for example in domain_build.c- that would pass as the boot time parameters to Linux kernel which is lunching in dom0.

Thanks in advance,

---1879531-532089860-1328092532=:918
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">My question was not about configuration, its main propose is how I can embed some initialization parameters in the Xen source code - for example in domain_build.c- that would pass as the boot time parameters to Linux kernel which is lunching in dom0.<br><br>Thanks in advance,<br></td></tr></table>
---1879531-532089860-1328092532=:918--


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

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

--===============3373448936787398232==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXXO-0003TQ-Vn; Wed, 01 Feb 2012 10:35:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RsXXO-0003T2-1T
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:35:38 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328092512!64052762!1
X-Originating-IP: [98.139.212.170]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3344 invoked from network); 1 Feb 2012 10:35:12 -0000
Received: from nm11.bullet.mail.bf1.yahoo.com (HELO
	nm11.bullet.mail.bf1.yahoo.com) (98.139.212.170)
	by server-15.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 10:35:12 -0000
Received: from [98.139.212.150] by nm11.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:35:33 -0000
Received: from [98.139.212.203] by tm7.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:35:33 -0000
Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:35:33 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 22852.38633.bm@omp1012.mail.bf1.yahoo.com
Received: (qmail 6180 invoked by uid 60001); 1 Feb 2012 10:35:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1328092532; bh=0BHSRU3PNA5alLWWgJQDrMX0M5zuQvBDHeSChvRYtjY=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=qLIBLjTixZdu1MGbF4ovZLUp00DBelkXjWghG7RYfQI1fifh5kKsdqVM2kutKwtVrDOPBtmRP2Nnc+q2EvHeTvM7dFmW7D2aayiJvxJIou71FskYxKFtWVRutqEEsQ9XGY+FBiCPJ5iORwzAAYusz1qnw8VlMNR8rOP5VsPWxto=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=CdlGlA0Wrfs6qo9TNIxoW+bXUIsn/H87PxZ8FXSLVgwGwE+Sp3s088J0m/OsRgG205BWXvnS2UQZkYso58XmBYEla87JdfMypog8g2Y/Grrob3yOHKIiB7Uh69W4inaCtwrcmVcflSqofQ2pX2/65/j/c4BqByVaRdgDsJBA/Qg=;
X-YMail-OSG: RMoQxwoVM1l_weBE_skToa2j7DRXfYTgZOLEkZ.y.GJRzKW
	Xed7je9VdZwEoj0pAFXmLsdeSzpV3uYUUTjh9Tq9dHvzwrZCcZhzS2EfM6xx
	XHK_zemQYVMPHqaS5D.6v_21QKRUWAm1DSJmmXdXBcheAUNoKi15ue1t7V62
	K.yRLmcxOpyxWOhhaaO0PavSy.8WqlZMkJ2WlPxzmX3qxNn4FzVEO8GZGHyb
	20xFV8D4Yk92kaNKNnjhwnSZsXLq_A5St8VfivO9II.hDNLxrbSfSUUmOBBA
	HVZ.MDc5Vs_F1wcmvcYfg.spGvAhYAneIbMlhVHXKWsTwW2xf8X9GAKFiQKa
	b8MDtiL8AhTY7ucqdiAP.5CuFxTdf9qMKDCowS0Ar3TUvyOUX5s0JKQ9D55h
	.IFNARtYLnpsYuy9PhQqx6q7iM7XOCZdG4GZyCII2MbQc.XwyFdqYN5WKVXA
	ccENV0lJO5isilL6On9Ku42sy7FtP2FH1f_mHHfrLjuSs1E_CLA--
Received: from [76.73.45.34] by web160905.mail.bf1.yahoo.com via HTTP;
	Wed, 01 Feb 2012 02:35:32 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1328092532.918.YahooMailClassic@web160905.mail.bf1.yahoo.com>
Date: Wed, 1 Feb 2012 02:35:32 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328090692.17444.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3373448936787398232=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3373448936787398232==
Content-Type: multipart/alternative; boundary="-1879531-532089860-1328092532=:918"

---1879531-532089860-1328092532=:918
Content-Type: text/plain; charset=us-ascii

My question was not about configuration, its main propose is how I can embed some initialization parameters in the Xen source code - for example in domain_build.c- that would pass as the boot time parameters to Linux kernel which is lunching in dom0.

Thanks in advance,

---1879531-532089860-1328092532=:918
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">My question was not about configuration, its main propose is how I can embed some initialization parameters in the Xen source code - for example in domain_build.c- that would pass as the boot time parameters to Linux kernel which is lunching in dom0.<br><br>Thanks in advance,<br></td></tr></table>
---1879531-532089860-1328092532=:918--


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

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

--===============3373448936787398232==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:39:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXbC-0003mT-L8; Wed, 01 Feb 2012 10:39:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXbA-0003ly-Ne
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:39:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328092766!13006467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29762 invoked from network); 1 Feb 2012 10:39:26 -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;
	1 Feb 2012 10:39:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:39:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:39:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jack nemati <hn_nemati1985@yahoo.com>
Date: Wed, 1 Feb 2012 10:39:26 +0000
In-Reply-To: <1328092532.918.YahooMailClassic@web160905.mail.bf1.yahoo.com>
References: <1328092532.918.YahooMailClassic@web160905.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328092766.17444.48.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 10:35 +0000, jack nemati wrote:
> My question was not about configuration, its main propose is how I can
> embed some initialization parameters in the Xen source code - for
> example in domain_build.c- that would pass as the boot time parameters
> to Linux kernel which is lunching in dom0.

Why do you not do this via your bootloader configuration?

Ian.



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:39:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXbC-0003mT-L8; Wed, 01 Feb 2012 10:39:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXbA-0003ly-Ne
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:39:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328092766!13006467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29762 invoked from network); 1 Feb 2012 10:39:26 -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;
	1 Feb 2012 10:39:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411008"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:39:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:39:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jack nemati <hn_nemati1985@yahoo.com>
Date: Wed, 1 Feb 2012 10:39:26 +0000
In-Reply-To: <1328092532.918.YahooMailClassic@web160905.mail.bf1.yahoo.com>
References: <1328092532.918.YahooMailClassic@web160905.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328092766.17444.48.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 10:35 +0000, jack nemati wrote:
> My question was not about configuration, its main propose is how I can
> embed some initialization parameters in the Xen source code - for
> example in domain_build.c- that would pass as the boot time parameters
> to Linux kernel which is lunching in dom0.

Why do you not do this via your bootloader configuration?

Ian.



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXhi-00042e-Gp; Wed, 01 Feb 2012 10:46:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXhh-00042P-Ov
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:46:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328093171!12915812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2826 invoked from network); 1 Feb 2012 10:46:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 10:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:46:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:46:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 10:46:10 +0000
In-Reply-To: <CAP8mzPMHGfRRATgAya9vFqdcK85R_zUBXsa17S2URfpDqWEHMA@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
	<1328003681.26983.318.camel@zakaz.uk.xensource.com>
	<CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
	<CAP8mzPMHGfRRATgAya9vFqdcK85R_zUBXsa17S2URfpDqWEHMA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093170.17444.52.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 23:53 +0000, Shriram Rajagopalan wrote:
> On Tue, Jan 31, 2012 at 9:32 AM, Shriram Rajagopalan
> <rshriram@cs.ubc.ca> wrote:
>         On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         
>                 On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca
>                 wrote:
>                 
>                 > +int libxl__domain_resume_device_model(libxl__gc
>                 *gc, uint32_t domid)
>                 > +{
>                 > +
>                 > +    switch (libxl__device_model_version_running(gc,
>                 domid)) {
>                 > +    case
>                 LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
>                 > +        libxl__qemu_traditional_cmd(gc, domid,
>                 "continue");
>                 
>                 
>                 No libxl__wait_for_device_model -> "running"?
>                 
>                 
>         
>         Nope. Thats how xend/remus also does it.

That doesn't mean they are correct. How do you handle the error case
where qemu does not restart correctly?

>          There seems to be no reference to such a state anywhere.

I see several calls to libxl__wait_for_device_model with the parameter
running in the libxl code base:

$ rgrep -E "libxl__wait_for_device_model.*\"running\"" tools/libxl/
tools/libxl/libxl_pci.c:        if (libxl__wait_for_device_model(gc, domid, "running",
tools/libxl/libxl_pci.c:        if (libxl__wait_for_device_model(gc, domid, "running",
tools/libxl/libxl.c:            libxl__wait_for_device_model(gc, domid, "running",

>          [...]
>                 
>                 >
>                 > @@ -541,6 +596,17 @@ static int
>                 libxl__domain_suspend_common_
>                 >
>                 >      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did
>                 not suspend");
>                 >      return 0;
>                 > +
>                 > + suspend_dm:
>                 
>                 
>                 The goto's make the code flow a bit tricky to follow
>                 (this function is
>                 already a bit tricksy with the early exit for the
>                 evtchn suspend case).
>                 
>                 Why not pass si to libxl__domain_suspend_device_model
>                 and let it contain
>                 the "if !hvm return" and logging stuff so you can just
>                 call in in place
>                 of the two goto statements?
>                 
>                 
>         
>         will do. 
>         
>         
>         
> 
> I gave it a shot. Passing suspendinfo struct to suspend_device_model
> is not feasible, as the function is declared in libxl_internal.h, but
> suspendinfo struct declaration is local to libxl_dom.c.  I am not sure
> if its worthwhile to declare a private struct like suspendinfo in
> libxl_internal.h, just to get rid of this goto.

I see two choices, you could either have a forward declaration of
suspendinfo in libxl_internal.h or you could make
libxl__domain_suspend_device_model static/internal to libxl_dom.c. I
slightly prefer the latter unless there is some reason to expose it to
the rest of libxl.

The same would go for libxl__domain_resume_device_model apart from the
call from libxl_domain_resume in libxl.c. There's an argument that this
function should be in libxl_dom.c anyway.

> OTOH, passing a dummy hvm parameter to the function looks a bit silly
> 
> libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid, int
> hvm)
> 
> 
> What do you think? goto needs to go? 

Taking another look at the control flow perhaps it does make sense, if
you think of the label as the tail of the success case rather than
something specific to suspending the device model then it removes the
two "return success" cases and combines them into a common tail, so long
as all success cases go through here (which I think is the case).

We still have multiple error exit cases, including the one where you
just fall through the loop (which combined with the unusual 0==error
return is a little confusing), but I think we can live with those.

So on second thoughts I think just renaming the label "guest_suspended"
would be fine.

Whether you also want to make
libxl__domain_{suspend,resume}_device_model internal to libxl_dom.c is
up to you.

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXhi-00042e-Gp; Wed, 01 Feb 2012 10:46:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXhh-00042P-Ov
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:46:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328093171!12915812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2826 invoked from network); 1 Feb 2012 10:46:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 10:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:46:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:46:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 10:46:10 +0000
In-Reply-To: <CAP8mzPMHGfRRATgAya9vFqdcK85R_zUBXsa17S2URfpDqWEHMA@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
	<1328003681.26983.318.camel@zakaz.uk.xensource.com>
	<CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
	<CAP8mzPMHGfRRATgAya9vFqdcK85R_zUBXsa17S2URfpDqWEHMA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093170.17444.52.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 23:53 +0000, Shriram Rajagopalan wrote:
> On Tue, Jan 31, 2012 at 9:32 AM, Shriram Rajagopalan
> <rshriram@cs.ubc.ca> wrote:
>         On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         
>                 On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca
>                 wrote:
>                 
>                 > +int libxl__domain_resume_device_model(libxl__gc
>                 *gc, uint32_t domid)
>                 > +{
>                 > +
>                 > +    switch (libxl__device_model_version_running(gc,
>                 domid)) {
>                 > +    case
>                 LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
>                 > +        libxl__qemu_traditional_cmd(gc, domid,
>                 "continue");
>                 
>                 
>                 No libxl__wait_for_device_model -> "running"?
>                 
>                 
>         
>         Nope. Thats how xend/remus also does it.

That doesn't mean they are correct. How do you handle the error case
where qemu does not restart correctly?

>          There seems to be no reference to such a state anywhere.

I see several calls to libxl__wait_for_device_model with the parameter
running in the libxl code base:

$ rgrep -E "libxl__wait_for_device_model.*\"running\"" tools/libxl/
tools/libxl/libxl_pci.c:        if (libxl__wait_for_device_model(gc, domid, "running",
tools/libxl/libxl_pci.c:        if (libxl__wait_for_device_model(gc, domid, "running",
tools/libxl/libxl.c:            libxl__wait_for_device_model(gc, domid, "running",

>          [...]
>                 
>                 >
>                 > @@ -541,6 +596,17 @@ static int
>                 libxl__domain_suspend_common_
>                 >
>                 >      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did
>                 not suspend");
>                 >      return 0;
>                 > +
>                 > + suspend_dm:
>                 
>                 
>                 The goto's make the code flow a bit tricky to follow
>                 (this function is
>                 already a bit tricksy with the early exit for the
>                 evtchn suspend case).
>                 
>                 Why not pass si to libxl__domain_suspend_device_model
>                 and let it contain
>                 the "if !hvm return" and logging stuff so you can just
>                 call in in place
>                 of the two goto statements?
>                 
>                 
>         
>         will do. 
>         
>         
>         
> 
> I gave it a shot. Passing suspendinfo struct to suspend_device_model
> is not feasible, as the function is declared in libxl_internal.h, but
> suspendinfo struct declaration is local to libxl_dom.c.  I am not sure
> if its worthwhile to declare a private struct like suspendinfo in
> libxl_internal.h, just to get rid of this goto.

I see two choices, you could either have a forward declaration of
suspendinfo in libxl_internal.h or you could make
libxl__domain_suspend_device_model static/internal to libxl_dom.c. I
slightly prefer the latter unless there is some reason to expose it to
the rest of libxl.

The same would go for libxl__domain_resume_device_model apart from the
call from libxl_domain_resume in libxl.c. There's an argument that this
function should be in libxl_dom.c anyway.

> OTOH, passing a dummy hvm parameter to the function looks a bit silly
> 
> libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid, int
> hvm)
> 
> 
> What do you think? goto needs to go? 

Taking another look at the control flow perhaps it does make sense, if
you think of the label as the tail of the success case rather than
something specific to suspending the device model then it removes the
two "return success" cases and combines them into a common tail, so long
as all success cases go through here (which I think is the case).

We still have multiple error exit cases, including the one where you
just fall through the loop (which combined with the unusual 0==error
return is a little confusing), but I think we can live with those.

So on second thoughts I think just renaming the label "guest_suspended"
would be fine.

Whether you also want to make
libxl__domain_{suspend,resume}_device_model internal to libxl_dom.c is
up to you.

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:48:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXjG-00049p-1N; Wed, 01 Feb 2012 10:47:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXjE-00049N-N3
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328093266!13258313!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19948 invoked from network); 1 Feb 2012 10:47:46 -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;
	1 Feb 2012 10:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:47:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:47:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 10:47:45 +0000
In-Reply-To: <CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093265.17444.54.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> On Tue, Jan 31, 2012 at 2:00 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>         On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca
>         wrote:Please can you add a few words about what fast means and
>         when its use
>         
>         would be appropriate.
>         
>         I'm not sure fast is right word -- it happens that this
>         mechanism is
>         faster but isn't the real meaning "co-operative" or something
>         along
>         those lines?
>         
>         Would a better name be libxl_domain_suspend_cancel, sharing a
>         common
>         helper internally with libxl_domain_resume?
>         
> 
> The explanation is already there, on top of xc_domain_resume in libxc.

It says that fast == cooperative resume but my concern was whether
"fast" is the right word for this parameter. Fast isn't really the
salient property here -- the fact that it requires guest cooperation
(which does happen to make it faster) is.

Anyway, regardless of what it is called it should be explained as part
of the libxl function otherwise users of libxl are never going to see
it.

[...]
> As for guests supporting this fast suspend, almost all guests (pv/hvm
> linux/windows) do support suspend_cancel. IIRC, I think some very old
> kernels didnt have this ability.

Old kernel or not, how do we detect it?

Ian.




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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:48:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXjG-00049p-1N; Wed, 01 Feb 2012 10:47:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXjE-00049N-N3
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328093266!13258313!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19948 invoked from network); 1 Feb 2012 10:47:46 -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;
	1 Feb 2012 10:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:47:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:47:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 10:47:45 +0000
In-Reply-To: <CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093265.17444.54.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> On Tue, Jan 31, 2012 at 2:00 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>         On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca
>         wrote:Please can you add a few words about what fast means and
>         when its use
>         
>         would be appropriate.
>         
>         I'm not sure fast is right word -- it happens that this
>         mechanism is
>         faster but isn't the real meaning "co-operative" or something
>         along
>         those lines?
>         
>         Would a better name be libxl_domain_suspend_cancel, sharing a
>         common
>         helper internally with libxl_domain_resume?
>         
> 
> The explanation is already there, on top of xc_domain_resume in libxc.

It says that fast == cooperative resume but my concern was whether
"fast" is the right word for this parameter. Fast isn't really the
salient property here -- the fact that it requires guest cooperation
(which does happen to make it faster) is.

Anyway, regardless of what it is called it should be explained as part
of the libxl function otherwise users of libxl are never going to see
it.

[...]
> As for guests supporting this fast suspend, almost all guests (pv/hvm
> linux/windows) do support suspend_cancel. IIRC, I think some very old
> kernels didnt have this ability.

Old kernel or not, how do we detect it?

Ian.




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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:51:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXmQ-0004Wi-MT; Wed, 01 Feb 2012 10:51:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RsXmO-0004WR-Mp
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:51:08 +0000
Received: from [85.158.138.51:49985] by server-12.bemta-3.messagelabs.com id
	B1/59-24557-B19192F4; Wed, 01 Feb 2012 10:51:07 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328093466!7320485!1
X-Originating-IP: [98.139.213.154]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12573 invoked from network); 1 Feb 2012 10:51:07 -0000
Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm9-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.154)
	by server-7.tower-174.messagelabs.com with SMTP;
	1 Feb 2012 10:51:07 -0000
Received: from [98.139.212.153] by nm9.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:51:06 -0000
Received: from [98.139.212.250] by tm10.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:51:06 -0000
Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:51:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 187243.70609.bm@omp1059.mail.bf1.yahoo.com
Received: (qmail 49048 invoked by uid 60001); 1 Feb 2012 10:51:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1328093466; bh=zapglSTqsKlJpeldavNw/zT6PqAlRD0RN9QrdgUytOs=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=fPBiQO0cVXI1jQcl/Epm6XjlIKdKIVZnfmduTOCUX2p0UrtEjoyzDaJi6DxT58y6dyog4ZaZdbSl79zMI9RdUImL33ggiqT6jZof9rQs6A8pa19I9euDlKMHHNJ9SOUFJKo4IqOxmemVHezHSupIbcvncBuhS2fVHfif1dcGTlM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=Fe8cNsygnC8MFt1wlT0wB3RmO4pBQwkNOvmHWqyvq3IvXMvwMaER0rgw5Zyq8N+lIzealW9slwNymSkvXZQK39J+icddrtwBw8DhPKAFIJuRHYDOJEVwHVdRencBtfRVjE76FgRe57b5HisSgheAeQyAllINUBTWmjqCd6qb4NQ=;
X-YMail-OSG: UI_.Pi0VM1nd09MHTps_oM6SatPh6TvqOP4Ado4h5I1Ef5d
	UsimZRxrk.2DuulyymMQENpPABA5LbIK5MC6RJB0UVcLvdVNoSdQiPbdVMV3
	9OPYf8t_v0XyFijSlFT3CoIcuVVwkbHQOWEWkiWL8vNSB.JBCPuHicxJKb64
	nIEG4F2VABeYvsqHzu8.ZQeL2EyjsDL8sdpNO6r_aS.ZxprXtJdwM4vwPOOR
	9jhQcpe9gfKVnlUMee.c9cI3f6SUd1JJtFh5SzVVRjQm95aaMP6xyBFVT9.6
	jp0nMU9e_LRjO5M72uy4si8Hv15bvYHZkPxjqYzKwoNjAslUVsabhgLQ4rbK
	z6TfuXzja8mmqe5ZJDCDo.F_xxsf6AVn0_aEUcJHLB4P1qkVyi3.eJTs5Ybb
	9qZB.muoFgwZsz0_.CstXkfAdWNoAK8hJoL3vNfQkMOAT5vkLfSuFqE.G2qV
	AyTwOz3YaQVVa.Fc_b3SHXMwOK2gjc8lAJovnAk9JLYm9ax7LNI4r
Received: from [76.73.45.34] by web160902.mail.bf1.yahoo.com via HTTP;
	Wed, 01 Feb 2012 02:51:06 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1328093466.46828.YahooMailClassic@web160902.mail.bf1.yahoo.com>
Date: Wed, 1 Feb 2012 02:51:06 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2543522079264996684=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2543522079264996684==
Content-Type: multipart/alternative; boundary="498176207-2032622760-1328093466=:46828"

--498176207-2032622760-1328093466=:46828
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

is there any solution for it? Thanks

I want to do this in the hypervisor level, because I'm going to prevent ill=
egal=A0 modifications in the bootloader. as an instance, I want to prevent =
users from passing parameters such as noexec=3Doff in boot time to the kern=
el.


--498176207-2032622760-1328093466=:46828
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">is there any solution for it? Thanks<br><bloc=
kquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; =
padding-left: 5px;"><br><div id=3D"yiv1666725275"><table border=3D"0" cellp=
adding=3D"0" cellspacing=3D"0"><tbody><tr><td style=3D"font:inherit;" valig=
n=3D"top">I want to do this in the hypervisor level, because I'm going to p=
revent illegal&nbsp; modifications in the bootloader. as an instance, I wan=
t to prevent users from passing parameters such as noexec=3Doff in boot tim=
e to the kernel.<br><br></td></tr></tbody></table></div></blockquote></td><=
/tr></table>
--498176207-2032622760-1328093466=:46828--


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

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

--===============2543522079264996684==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:51:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXmQ-0004Wi-MT; Wed, 01 Feb 2012 10:51:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hn_nemati1985@yahoo.com>) id 1RsXmO-0004WR-Mp
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:51:08 +0000
Received: from [85.158.138.51:49985] by server-12.bemta-3.messagelabs.com id
	B1/59-24557-B19192F4; Wed, 01 Feb 2012 10:51:07 +0000
X-Env-Sender: hn_nemati1985@yahoo.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328093466!7320485!1
X-Originating-IP: [98.139.213.154]
X-SpamReason: No, hits=0.9 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12573 invoked from network); 1 Feb 2012 10:51:07 -0000
Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (HELO
	nm9-vm0.bullet.mail.bf1.yahoo.com) (98.139.213.154)
	by server-7.tower-174.messagelabs.com with SMTP;
	1 Feb 2012 10:51:07 -0000
Received: from [98.139.212.153] by nm9.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:51:06 -0000
Received: from [98.139.212.250] by tm10.bullet.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:51:06 -0000
Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP;
	01 Feb 2012 10:51:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 187243.70609.bm@omp1059.mail.bf1.yahoo.com
Received: (qmail 49048 invoked by uid 60001); 1 Feb 2012 10:51:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1328093466; bh=zapglSTqsKlJpeldavNw/zT6PqAlRD0RN9QrdgUytOs=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=fPBiQO0cVXI1jQcl/Epm6XjlIKdKIVZnfmduTOCUX2p0UrtEjoyzDaJi6DxT58y6dyog4ZaZdbSl79zMI9RdUImL33ggiqT6jZof9rQs6A8pa19I9euDlKMHHNJ9SOUFJKo4IqOxmemVHezHSupIbcvncBuhS2fVHfif1dcGTlM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=Fe8cNsygnC8MFt1wlT0wB3RmO4pBQwkNOvmHWqyvq3IvXMvwMaER0rgw5Zyq8N+lIzealW9slwNymSkvXZQK39J+icddrtwBw8DhPKAFIJuRHYDOJEVwHVdRencBtfRVjE76FgRe57b5HisSgheAeQyAllINUBTWmjqCd6qb4NQ=;
X-YMail-OSG: UI_.Pi0VM1nd09MHTps_oM6SatPh6TvqOP4Ado4h5I1Ef5d
	UsimZRxrk.2DuulyymMQENpPABA5LbIK5MC6RJB0UVcLvdVNoSdQiPbdVMV3
	9OPYf8t_v0XyFijSlFT3CoIcuVVwkbHQOWEWkiWL8vNSB.JBCPuHicxJKb64
	nIEG4F2VABeYvsqHzu8.ZQeL2EyjsDL8sdpNO6r_aS.ZxprXtJdwM4vwPOOR
	9jhQcpe9gfKVnlUMee.c9cI3f6SUd1JJtFh5SzVVRjQm95aaMP6xyBFVT9.6
	jp0nMU9e_LRjO5M72uy4si8Hv15bvYHZkPxjqYzKwoNjAslUVsabhgLQ4rbK
	z6TfuXzja8mmqe5ZJDCDo.F_xxsf6AVn0_aEUcJHLB4P1qkVyi3.eJTs5Ybb
	9qZB.muoFgwZsz0_.CstXkfAdWNoAK8hJoL3vNfQkMOAT5vkLfSuFqE.G2qV
	AyTwOz3YaQVVa.Fc_b3SHXMwOK2gjc8lAJovnAk9JLYm9ax7LNI4r
Received: from [76.73.45.34] by web160902.mail.bf1.yahoo.com via HTTP;
	Wed, 01 Feb 2012 02:51:06 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1328093466.46828.YahooMailClassic@web160902.mail.bf1.yahoo.com>
Date: Wed, 1 Feb 2012 02:51:06 -0800 (PST)
From: jack nemati <hn_nemati1985@yahoo.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2543522079264996684=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2543522079264996684==
Content-Type: multipart/alternative; boundary="498176207-2032622760-1328093466=:46828"

--498176207-2032622760-1328093466=:46828
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

is there any solution for it? Thanks

I want to do this in the hypervisor level, because I'm going to prevent ill=
egal=A0 modifications in the bootloader. as an instance, I want to prevent =
users from passing parameters such as noexec=3Doff in boot time to the kern=
el.


--498176207-2032622760-1328093466=:46828
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">is there any solution for it? Thanks<br><bloc=
kquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; =
padding-left: 5px;"><br><div id=3D"yiv1666725275"><table border=3D"0" cellp=
adding=3D"0" cellspacing=3D"0"><tbody><tr><td style=3D"font:inherit;" valig=
n=3D"top">I want to do this in the hypervisor level, because I'm going to p=
revent illegal&nbsp; modifications in the bootloader. as an instance, I wan=
t to prevent users from passing parameters such as noexec=3Doff in boot tim=
e to the kernel.<br><br></td></tr></tbody></table></div></blockquote></td><=
/tr></table>
--498176207-2032622760-1328093466=:46828--


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

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

--===============2543522079264996684==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:54:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXpC-0004jX-Gp; Wed, 01 Feb 2012 10:54:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXpB-0004jH-Rw
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:54:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328093635!12435973!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17794 invoked from network); 1 Feb 2012 10:53:55 -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;
	1 Feb 2012 10:53:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:53:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:53:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 10:53:54 +0000
In-Reply-To: <CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093634.17444.59.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> As for guests supporting this fast suspend, almost all guests (pv/hvm
> linux/windows) do support suspend_cancel. IIRC, I think some very old
> kernels didnt have this ability.

Slight aside, does Remus work with mainline Linux domU kernels? Users
seem to be under under that impression.

I know you had some patches at one point but I a) don't remember if they
went in and b) don't remember if they were sufficient.

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:54:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsXpC-0004jX-Gp; Wed, 01 Feb 2012 10:54:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXpB-0004jH-Rw
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:54:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328093635!12435973!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17794 invoked from network); 1 Feb 2012 10:53:55 -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;
	1 Feb 2012 10:53:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:53:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:53:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 10:53:54 +0000
In-Reply-To: <CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093634.17444.59.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> As for guests supporting this fast suspend, almost all guests (pv/hvm
> linux/windows) do support suspend_cancel. IIRC, I think some very old
> kernels didnt have this ability.

Slight aside, does Remus work with mainline Linux domU kernels? Users
seem to be under under that impression.

I know you had some patches at one point but I a) don't remember if they
went in and b) don't remember if they were sufficient.

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:56:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXrd-0004s7-2z; Wed, 01 Feb 2012 10:56:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXrb-0004rY-Bl
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328093785!8772586!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28371 invoked from network); 1 Feb 2012 10:56:25 -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;
	1 Feb 2012 10:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:56:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:56:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jack nemati <hn_nemati1985@yahoo.com>
Date: Wed, 1 Feb 2012 10:56:24 +0000
In-Reply-To: <1328093466.46828.YahooMailClassic@web160902.mail.bf1.yahoo.com>
References: <1328093466.46828.YahooMailClassic@web160902.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093785.17444.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 10:51 +0000, jack nemati wrote:
> is there any solution for it? Thanks
>         
>         I want to do this in the hypervisor level, because I'm going
>         to prevent illegal  modifications in the bootloader. as an
>         instance, I want to prevent users from passing parameters such
>         as noexec=off in boot time to the kernel.

But a user who can modify the command line can just as easily modify
which hypervisor binary they launch, at which point you need to start
thinking about trusted boot etc and if you are doing that you would
naturally measure the bootloader configuration too.

Anyway, you can do whatever checking or modifications you like to the
cmdline in construct_dom0().

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 10:56:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 10: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.xensource.com>)
	id 1RsXrd-0004s7-2z; Wed, 01 Feb 2012 10:56:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsXrb-0004rY-Bl
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 10:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328093785!8772586!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28371 invoked from network); 1 Feb 2012 10:56:25 -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;
	1 Feb 2012 10:56:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 10:56:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	10:56:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jack nemati <hn_nemati1985@yahoo.com>
Date: Wed, 1 Feb 2012 10:56:24 +0000
In-Reply-To: <1328093466.46828.YahooMailClassic@web160902.mail.bf1.yahoo.com>
References: <1328093466.46828.YahooMailClassic@web160902.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328093785.17444.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux kernel initialization using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 10:51 +0000, jack nemati wrote:
> is there any solution for it? Thanks
>         
>         I want to do this in the hypervisor level, because I'm going
>         to prevent illegal  modifications in the bootloader. as an
>         instance, I want to prevent users from passing parameters such
>         as noexec=off in boot time to the kernel.

But a user who can modify the command line can just as easily modify
which hypervisor binary they launch, at which point you need to start
thinking about trusted boot etc and if you are doing that you would
naturally measure the bootloader configuration too.

Anyway, you can do whatever checking or modifications you like to the
cmdline in construct_dom0().

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 11:08:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 11: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.xensource.com>)
	id 1RsY2e-0005Hw-CN; Wed, 01 Feb 2012 11:07:56 +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 1RsY2c-0005Hp-Hs
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 11:07:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328094352!62063037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 1 Feb 2012 11:05:52 -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;
	1 Feb 2012 11:05:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:07:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 11:07:50 +0000
Date: Wed, 1 Feb 2012 11:09:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120201010803.GD32295@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1202011108240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
	<20120131162759.GA18248@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
	<20120201010803.GD32295@andromeda.dapyr.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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] xen pvhvm: do not remap pirqs onto evtchns
 if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 31, 2012 at 04:40:26PM +0000, Stefano Stabellini wrote:
> > On Tue, 31 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > So the xen_have_vector_callback looks to be only set by
> > > 
> > > 1398         if (xen_feature(XENFEAT_hvm_callback_vector))
> > > 1399                 xen_have_vector_callback = 1;
> > > 
> > > So could this be just done via a check for that instead?
> > > 
> > 
> > Sure, but I don't think it would be better: using
> > xen_have_vector_callback is more consistent and give us the flexibility
> > of allowing users to manually override it in the future.
> 
> ok. applied. Hm, I was thinking to put on stable@kernel.org - but how
> far back should it go? 2.6.37?

Yes, I think is 2.6.37 when we introduced using XENFEAT_hvm_pirqs.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 11:08:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 11: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.xensource.com>)
	id 1RsY2e-0005Hw-CN; Wed, 01 Feb 2012 11:07:56 +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 1RsY2c-0005Hp-Hs
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 11:07:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328094352!62063037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 1 Feb 2012 11:05:52 -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;
	1 Feb 2012 11:05:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:07:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 11:07:50 +0000
Date: Wed, 1 Feb 2012 11:09:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120201010803.GD32295@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1202011108240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
	<20120131162759.GA18248@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
	<20120201010803.GD32295@andromeda.dapyr.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	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] xen pvhvm: do not remap pirqs onto evtchns
 if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 31, 2012 at 04:40:26PM +0000, Stefano Stabellini wrote:
> > On Tue, 31 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > So the xen_have_vector_callback looks to be only set by
> > > 
> > > 1398         if (xen_feature(XENFEAT_hvm_callback_vector))
> > > 1399                 xen_have_vector_callback = 1;
> > > 
> > > So could this be just done via a check for that instead?
> > > 
> > 
> > Sure, but I don't think it would be better: using
> > xen_have_vector_callback is more consistent and give us the flexibility
> > of allowing users to manually override it in the future.
> 
> ok. applied. Hm, I was thinking to put on stable@kernel.org - but how
> far back should it go? 2.6.37?

Yes, I think is 2.6.37 when we introduced using XENFEAT_hvm_pirqs.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 11:17:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 11: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.xensource.com>)
	id 1RsYBX-00060A-UN; Wed, 01 Feb 2012 11:17:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsYBV-0005yG-VC
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 11:17:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328095019!13179723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21204 invoked from network); 1 Feb 2012 11:17:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 11:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:16:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 11:17:00 +0000
Date: Wed, 1 Feb 2012 11:18:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120201011318.GE32295@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1202011110180.3196@kaball-desktop>
References: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120201011318.GE32295@andromeda.dapyr.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 04:02:31PM +0000, Stefano Stabellini wrote:
> > This patch implements support for multiple consoles:
> > consoles other than the first one are setup using the traditional xenbus
> > and grant-table based mechanism.
> > We use a list to keep track of the allocated consoles, we don't
> > expect too many of them anyway.
> >
> 
> So looks good. applied to #testing. How do I test "multiple" consoles?

Interesting question :)

First of all testing a pv console alongside an emulated serial is easy:
by default xl creates a pv console for all hvm guests. So you just need
to start using it (something like console=ttyS0 console=hvc0 on a PV on
HVM guest).
You can connect to the pv console with the following command:

xl console -t pv <domain_name>


Then, in order to test multiple pv consoles, you need the toolstack to
create more than one for you (see appended patch that creates 2 pv
consoles for PV on HVM guests). If you create two pv consoles, you can
connect to the second one with the following command:

xl console -t pv -n 1 <domain_name>

BTW in the patch below I am seeting QEMU as console backend because it
is the only one that can handle multiple pv consoles.


8<----

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e1c615f..ec2c362 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -554,14 +554,21 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
-        libxl_device_console console;
+        libxl_device_console console, console2;
         libxl_device_vkb vkb;
 
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
+        console.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
         libxl__device_console_add(gc, domid, &console, &state);
         libxl_device_console_dispose(&console);
+        ret = init_console_info(&console2, 1);
+        if ( ret )
+            goto error_out;
+        console2.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+        libxl__device_console_add(gc, domid, &console2, NULL);
+        libxl_device_console_dispose(&console2);
 
         ret = libxl_device_vkb_init(ctx, &vkb);
         if ( ret )

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 11:17:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 11: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.xensource.com>)
	id 1RsYBX-00060A-UN; Wed, 01 Feb 2012 11:17:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsYBV-0005yG-VC
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 11:17:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328095019!13179723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21204 invoked from network); 1 Feb 2012 11:17:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 11:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10411983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:16:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 11:17:00 +0000
Date: Wed, 1 Feb 2012 11:18:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120201011318.GE32295@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1202011110180.3196@kaball-desktop>
References: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120201011318.GE32295@andromeda.dapyr.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 04:02:31PM +0000, Stefano Stabellini wrote:
> > This patch implements support for multiple consoles:
> > consoles other than the first one are setup using the traditional xenbus
> > and grant-table based mechanism.
> > We use a list to keep track of the allocated consoles, we don't
> > expect too many of them anyway.
> >
> 
> So looks good. applied to #testing. How do I test "multiple" consoles?

Interesting question :)

First of all testing a pv console alongside an emulated serial is easy:
by default xl creates a pv console for all hvm guests. So you just need
to start using it (something like console=ttyS0 console=hvc0 on a PV on
HVM guest).
You can connect to the pv console with the following command:

xl console -t pv <domain_name>


Then, in order to test multiple pv consoles, you need the toolstack to
create more than one for you (see appended patch that creates 2 pv
consoles for PV on HVM guests). If you create two pv consoles, you can
connect to the second one with the following command:

xl console -t pv -n 1 <domain_name>

BTW in the patch below I am seeting QEMU as console backend because it
is the only one that can handle multiple pv consoles.


8<----

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e1c615f..ec2c362 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -554,14 +554,21 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
-        libxl_device_console console;
+        libxl_device_console console, console2;
         libxl_device_vkb vkb;
 
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
+        console.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
         libxl__device_console_add(gc, domid, &console, &state);
         libxl_device_console_dispose(&console);
+        ret = init_console_info(&console2, 1);
+        if ( ret )
+            goto error_out;
+        console2.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+        libxl__device_console_add(gc, domid, &console2, NULL);
+        libxl_device_console_dispose(&console2);
 
         ret = libxl_device_vkb_init(ctx, &vkb);
         if ( ret )

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 11:23:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 11:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsYHR-0006dO-UX; Wed, 01 Feb 2012 11:23:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsYHQ-0006cs-9n
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 11:23:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328095386!5921074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4186 invoked from network); 1 Feb 2012 11:23:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 11:23:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10412157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:23:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 11:23:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsYHJ-0006jn-2F;
	Wed, 01 Feb 2012 11:23:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsYHJ-0007Ly-0R;
	Wed, 01 Feb 2012 11:23:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11751-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 11:23:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11751: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11751 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11751/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 11746
 test-amd64-amd64-xl           9 guest-start        fail in 11746 pass in 11751

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10877
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10877
 test-amd64-i386-xl-credit2    7 debian-install   fail in 11746 REGR. vs. 10859

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-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               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-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install      fail in 11746 never pass

version targeted for testing:
 xen                  1b7e074ee1d6
baseline version:
 xen                  271e30252c16

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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=1b7e074ee1d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1b7e074ee1d6
+ branch=xen-4.0-testing
+ revision=1b7e074ee1d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 1b7e074ee1d6 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 2 files

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 11:23:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 11:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsYHR-0006dO-UX; Wed, 01 Feb 2012 11:23:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsYHQ-0006cs-9n
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 11:23:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328095386!5921074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4186 invoked from network); 1 Feb 2012 11:23:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 11:23:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10412157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:23:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 11:23:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsYHJ-0006jn-2F;
	Wed, 01 Feb 2012 11:23:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsYHJ-0007Ly-0R;
	Wed, 01 Feb 2012 11:23:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11751-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 11:23:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11751: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11751 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11751/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 11746
 test-amd64-amd64-xl           9 guest-start        fail in 11746 pass in 11751

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10877
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10877
 test-amd64-i386-xl-credit2    7 debian-install   fail in 11746 REGR. vs. 10859

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-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               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-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install      fail in 11746 never pass

version targeted for testing:
 xen                  1b7e074ee1d6
baseline version:
 xen                  271e30252c16

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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=1b7e074ee1d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1b7e074ee1d6
+ branch=xen-4.0-testing
+ revision=1b7e074ee1d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 1b7e074ee1d6 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 2 files

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 12:10:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 12: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.xensource.com>)
	id 1RsZ0c-0007ww-TP; Wed, 01 Feb 2012 12:09:54 +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 1RsZ0a-0007wr-Sz
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 12:09:53 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328098148!58324226!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32526 invoked from network); 1 Feb 2012 12:09:09 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 12:09:09 -0000
Received: by iaeh11 with SMTP id h11so6248973iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 04:09:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=Srxy8V0Geq0ScuTnbnQWaYmirtJHoFDUsgahPz2ptvg=;
	b=RwaZDrCv45EZG2GHPD5ksAtwDhSM/xjpy8q7oBgE3o8K/SF+V/im8u+uF/a9VEGGlQ
	oJKda8f6DJbJoXRqsgmoh2AExBvCJ48CFA1nHh23E3JvpYPVpU8A2JlRRywaY3vkE9q6
	sDHnAaDnWWypC2P0j5w0jZMyS0DsSXBmhv89k=
MIME-Version: 1.0
Received: by 10.42.168.6 with SMTP id u6mr18141081icy.9.1328097794281; Wed, 01
	Feb 2012 04:03:14 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Wed, 1 Feb 2012 04:03:14 -0800 (PST)
In-Reply-To: <4F2818C7.1050702@citrix.com>
References: <4F2818C7.1050702@citrix.com>
Date: Wed, 1 Feb 2012 12:03:14 +0000
X-Google-Sender-Auth: NHcsOYGQsft4-cD01po9bwWxREI
Message-ID: <CAFLBxZZLbqGwGv6f5tq=Cqo6tRo1XfYx=0DqyCn3EiiAJfHGtQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 4:37 PM, David Vrabel <david.vrabel@citrix.com> wro=
te:
> If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
> occurs while the CPU is in printk() then Xen may deadlock as
> pci_serr_error() calls console_force_unlock() which screws up the
> console lock.
>
> I don't think removing the console_force_unlock() is sufficient as it
> looks like printk() is unsafe to call from NMI context. =A0We would like
> keep the diagnostic. =A0Does the following (untested) patch to defer the
> printk() to a softirq look like a valid approach?
>
> I also considered passing the NMI to dom0 (like other NMIs are) but I
> couldn't see how NMIs were handled in the current upstream pv-ops kernels.

Thanks David.  Unfortunately reproducing the error condition isn't as
consistent as I remember.  In 6 manual invocations, I got one instance
of PCI SERR, in which the patch worked correctly (i.e., the error
message and did not crash the host).

 -George

>
> diff -r e2722b24dc09 xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c =A0 =A0 =A0Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/traps.c =A0 =A0 =A0Tue Jan 31 16:28:45 2012 +0000
> @@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
> =A0 =A0 st->vcpu =3D NULL;
> =A0}
>
> +static void pci_serr_softirq(void)
> +{
> + =A0 =A0printk("\n\nNMI - PCI system error (SERR)\n");
> +}
> +
> =A0void async_exception_cleanup(struct vcpu *curr)
> =A0{
> =A0 =A0 int trap;
> @@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int
>
> =A0static void pci_serr_error(struct cpu_user_regs *regs)
> =A0{
> - =A0 =A0console_force_unlock();
> - =A0 =A0printk("\n\nNMI - PCI system error (SERR)\n");
> -
> =A0 =A0 outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the P=
CI
> SERR error line. */
> +
> + =A0 =A0/* Would like to print a diagnostic here but can't call printk()
> + =A0 =A0 =A0 from NMI context -- raise a softirq instead. */
> + =A0 =A0raise_softirq(PCI_SERR_SOFTIRQ);
> =A0}
>
> =A0static void io_check_error(struct cpu_user_regs *regs)
> @@ -3563,6 +3569,7 @@ void __init trap_init(void)
> =A0 =A0 cpu_init();
>
> =A0 =A0 open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
> + =A0 =A0open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
> =A0}
>
> =A0long register_guest_nmi_callback(unsigned long address)
> diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
> --- a/xen/include/asm-x86/softirq.h =A0 =A0 Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/softirq.h =A0 =A0 Tue Jan 31 16:28:45 2012 +0000
> @@ -6,6 +6,7 @@
> =A0#define VCPU_KICK_SOFTIRQ =A0 =A0 =A0(NR_COMMON_SOFTIRQS + 2)
>
> =A0#define MACHINE_CHECK_SOFTIRQ =A0(NR_COMMON_SOFTIRQS + 3)
> -#define NR_ARCH_SOFTIRQS =A0 =A0 =A0 4
> +#define PCI_SERR_SOFTIRQ =A0 =A0 =A0 (NR_COMMON_SOFTIRQS + 4)
> +#define NR_ARCH_SOFTIRQS =A0 =A0 =A0 5
>
> =A0#endif /* __ASM_SOFTIRQ_H__ */
>
> David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 12:10:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 12: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.xensource.com>)
	id 1RsZ0c-0007ww-TP; Wed, 01 Feb 2012 12:09:54 +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 1RsZ0a-0007wr-Sz
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 12:09:53 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328098148!58324226!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32526 invoked from network); 1 Feb 2012 12:09:09 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 12:09:09 -0000
Received: by iaeh11 with SMTP id h11so6248973iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 04:09:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=Srxy8V0Geq0ScuTnbnQWaYmirtJHoFDUsgahPz2ptvg=;
	b=RwaZDrCv45EZG2GHPD5ksAtwDhSM/xjpy8q7oBgE3o8K/SF+V/im8u+uF/a9VEGGlQ
	oJKda8f6DJbJoXRqsgmoh2AExBvCJ48CFA1nHh23E3JvpYPVpU8A2JlRRywaY3vkE9q6
	sDHnAaDnWWypC2P0j5w0jZMyS0DsSXBmhv89k=
MIME-Version: 1.0
Received: by 10.42.168.6 with SMTP id u6mr18141081icy.9.1328097794281; Wed, 01
	Feb 2012 04:03:14 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Wed, 1 Feb 2012 04:03:14 -0800 (PST)
In-Reply-To: <4F2818C7.1050702@citrix.com>
References: <4F2818C7.1050702@citrix.com>
Date: Wed, 1 Feb 2012 12:03:14 +0000
X-Google-Sender-Auth: NHcsOYGQsft4-cD01po9bwWxREI
Message-ID: <CAFLBxZZLbqGwGv6f5tq=Cqo6tRo1XfYx=0DqyCn3EiiAJfHGtQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 4:37 PM, David Vrabel <david.vrabel@citrix.com> wro=
te:
> If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
> occurs while the CPU is in printk() then Xen may deadlock as
> pci_serr_error() calls console_force_unlock() which screws up the
> console lock.
>
> I don't think removing the console_force_unlock() is sufficient as it
> looks like printk() is unsafe to call from NMI context. =A0We would like
> keep the diagnostic. =A0Does the following (untested) patch to defer the
> printk() to a softirq look like a valid approach?
>
> I also considered passing the NMI to dom0 (like other NMIs are) but I
> couldn't see how NMIs were handled in the current upstream pv-ops kernels.

Thanks David.  Unfortunately reproducing the error condition isn't as
consistent as I remember.  In 6 manual invocations, I got one instance
of PCI SERR, in which the patch worked correctly (i.e., the error
message and did not crash the host).

 -George

>
> diff -r e2722b24dc09 xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c =A0 =A0 =A0Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/traps.c =A0 =A0 =A0Tue Jan 31 16:28:45 2012 +0000
> @@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
> =A0 =A0 st->vcpu =3D NULL;
> =A0}
>
> +static void pci_serr_softirq(void)
> +{
> + =A0 =A0printk("\n\nNMI - PCI system error (SERR)\n");
> +}
> +
> =A0void async_exception_cleanup(struct vcpu *curr)
> =A0{
> =A0 =A0 int trap;
> @@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int
>
> =A0static void pci_serr_error(struct cpu_user_regs *regs)
> =A0{
> - =A0 =A0console_force_unlock();
> - =A0 =A0printk("\n\nNMI - PCI system error (SERR)\n");
> -
> =A0 =A0 outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the P=
CI
> SERR error line. */
> +
> + =A0 =A0/* Would like to print a diagnostic here but can't call printk()
> + =A0 =A0 =A0 from NMI context -- raise a softirq instead. */
> + =A0 =A0raise_softirq(PCI_SERR_SOFTIRQ);
> =A0}
>
> =A0static void io_check_error(struct cpu_user_regs *regs)
> @@ -3563,6 +3569,7 @@ void __init trap_init(void)
> =A0 =A0 cpu_init();
>
> =A0 =A0 open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
> + =A0 =A0open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
> =A0}
>
> =A0long register_guest_nmi_callback(unsigned long address)
> diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
> --- a/xen/include/asm-x86/softirq.h =A0 =A0 Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/softirq.h =A0 =A0 Tue Jan 31 16:28:45 2012 +0000
> @@ -6,6 +6,7 @@
> =A0#define VCPU_KICK_SOFTIRQ =A0 =A0 =A0(NR_COMMON_SOFTIRQS + 2)
>
> =A0#define MACHINE_CHECK_SOFTIRQ =A0(NR_COMMON_SOFTIRQS + 3)
> -#define NR_ARCH_SOFTIRQS =A0 =A0 =A0 4
> +#define PCI_SERR_SOFTIRQ =A0 =A0 =A0 (NR_COMMON_SOFTIRQS + 4)
> +#define NR_ARCH_SOFTIRQS =A0 =A0 =A0 5
>
> =A0#endif /* __ASM_SOFTIRQ_H__ */
>
> David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 12:30:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 12:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsZK8-0008MS-Fs; Wed, 01 Feb 2012 12:30:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RsZK6-0008MN-IH
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 12:30:02 +0000
Received: from [85.158.138.51:65160] by server-1.bemta-3.messagelabs.com id
	B1/92-09565-940392F4; Wed, 01 Feb 2012 12:30:01 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328099398!7339261!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14421 invoked from network); 1 Feb 2012 12:30:00 -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;
	1 Feb 2012 12:30:00 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RsZK2-0007Rt-Cu
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:29:58 -0800
Date: Wed, 1 Feb 2012 04:29:58 -0800 (PST)
From: feisky <feiskyer@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1328099398393-5447334.post@n5.nabble.com>
In-Reply-To: <20100106202631.GK25902@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen guest disk online resize,
 xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Has anyone tried is this method ok?

--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-guest-disk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p5447334.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 12:30:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 12:30:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsZK8-0008MS-Fs; Wed, 01 Feb 2012 12:30:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RsZK6-0008MN-IH
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 12:30:02 +0000
Received: from [85.158.138.51:65160] by server-1.bemta-3.messagelabs.com id
	B1/92-09565-940392F4; Wed, 01 Feb 2012 12:30:01 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328099398!7339261!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14421 invoked from network); 1 Feb 2012 12:30:00 -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;
	1 Feb 2012 12:30:00 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RsZK2-0007Rt-Cu
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 04:29:58 -0800
Date: Wed, 1 Feb 2012 04:29:58 -0800 (PST)
From: feisky <feiskyer@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1328099398393-5447334.post@n5.nabble.com>
In-Reply-To: <20100106202631.GK25902@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen guest disk online resize,
 xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Has anyone tried is this method ok?

--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-guest-disk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p5447334.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 12:40:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 12: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.xensource.com>)
	id 1RsZTN-0000Ri-I2; Wed, 01 Feb 2012 12:39:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RsZTM-0000Rd-Eq
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 12:39:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328099945!58024881!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7464 invoked from network); 1 Feb 2012 12:39:06 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 12:39:06 -0000
Received: by pbds6 with SMTP id s6so7875356pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 04:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=QAauhqXKYXJ/1zbsNF7F+Dn5sVZMJ+ZMSRLFS7LbsaA=;
	b=i4tj47yxq7+KWWb9aLKoWBbHybUQGW0nHNyq8LRpEUEGOzxmkzS7iW+7u7Rdj+disE
	iY4r0404bk9dYqOCp1sRI9QqhzkkzG70VGtHbqGE1V27bFlsRaHkEgjjGga2Lngxfjyu
	lb5QuEXHfUEuQfD3y2qnsJDyDdv6TrhADGVG8=
MIME-Version: 1.0
Received: by 10.68.134.35 with SMTP id ph3mr13090672pbb.29.1328099973399; Wed,
	01 Feb 2012 04:39:33 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Wed, 1 Feb 2012 04:39:33 -0800 (PST)
Date: Wed, 1 Feb 2012 13:39:33 +0100
X-Google-Sender-Auth: 52zBBkAcs7_UCEDDrHJmYQI-Zss
Message-ID: <CAPLaKK5tqaO-jGMwMf16avhXGf-RF2NNGs3S1Le=M_wqz=0K8g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenstore watches and event queue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've been having some problems with xs_watch and xs_read_watch, here
is my scenario:

xs_watch("/some/xenstore/dir");
[... do some stuff...]
xs_read_watch(...);
[... do some processing ...]
[... xenstore changes ...]
xs_read_watch(...);

If someone modifies the xenstore entries I'm watching, but I'm not
currently on xs_read_watch, only the last modification is returned
when I call xs_read_watch, I would expect xenstore watches to have
some kind of queue, so multiple xenstore changes on watched dirs are
not lost if I'm not currently blocked on xs_read_watch. Is there
anyway to archive this?

Thanks, Roger.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 12:40:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 12: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.xensource.com>)
	id 1RsZTN-0000Ri-I2; Wed, 01 Feb 2012 12:39:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RsZTM-0000Rd-Eq
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 12:39:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328099945!58024881!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7464 invoked from network); 1 Feb 2012 12:39:06 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 12:39:06 -0000
Received: by pbds6 with SMTP id s6so7875356pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 04:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=QAauhqXKYXJ/1zbsNF7F+Dn5sVZMJ+ZMSRLFS7LbsaA=;
	b=i4tj47yxq7+KWWb9aLKoWBbHybUQGW0nHNyq8LRpEUEGOzxmkzS7iW+7u7Rdj+disE
	iY4r0404bk9dYqOCp1sRI9QqhzkkzG70VGtHbqGE1V27bFlsRaHkEgjjGga2Lngxfjyu
	lb5QuEXHfUEuQfD3y2qnsJDyDdv6TrhADGVG8=
MIME-Version: 1.0
Received: by 10.68.134.35 with SMTP id ph3mr13090672pbb.29.1328099973399; Wed,
	01 Feb 2012 04:39:33 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Wed, 1 Feb 2012 04:39:33 -0800 (PST)
Date: Wed, 1 Feb 2012 13:39:33 +0100
X-Google-Sender-Auth: 52zBBkAcs7_UCEDDrHJmYQI-Zss
Message-ID: <CAPLaKK5tqaO-jGMwMf16avhXGf-RF2NNGs3S1Le=M_wqz=0K8g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenstore watches and event queue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've been having some problems with xs_watch and xs_read_watch, here
is my scenario:

xs_watch("/some/xenstore/dir");
[... do some stuff...]
xs_read_watch(...);
[... do some processing ...]
[... xenstore changes ...]
xs_read_watch(...);

If someone modifies the xenstore entries I'm watching, but I'm not
currently on xs_read_watch, only the last modification is returned
when I call xs_read_watch, I would expect xenstore watches to have
some kind of queue, so multiple xenstore changes on watched dirs are
not lost if I'm not currently blocked on xs_read_watch. Is there
anyway to archive this?

Thanks, Roger.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:03:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsZq9-00014s-Jm; Wed, 01 Feb 2012 13:03:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RsZq7-00014j-QK
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:03:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328101379!13294128!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzMjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18058 invoked from network); 1 Feb 2012 13:03:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 13:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320642000"; d="scan'208";a="179944660"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 08:02:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 08:02:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11D2ZfG004864;
	Wed, 1 Feb 2012 05:02:36 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 13:02:16 +0000
Message-ID: <1328101336-9370-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: avoid deadlock after a PCI SERR NMI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
occurs while the CPU is in printk() then Xen may deadlock as
pci_serr_error() calls console_force_unlock() which screws up the
console lock.

printk() isn't safe to call from NMI context so defer the diagnostic
message to a softirq.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/arch/x86/traps.c          |   13 ++++++++++---
 xen/include/asm-x86/softirq.h |    3 ++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b6f7b9a..35c17f2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
     st->vcpu = NULL;
 }
 
+static void pci_serr_softirq(void)
+{
+    printk("\n\nNMI - PCI system error (SERR)\n");
+}
+
 void async_exception_cleanup(struct vcpu *curr)
 {
     int trap;
@@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int reason_idx)
 
 static void pci_serr_error(struct cpu_user_regs *regs)
 {
-    console_force_unlock();
-    printk("\n\nNMI - PCI system error (SERR)\n");
-
     outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI SERR error line. */
+
+    /* Would like to print a diagnostic here but can't call printk()
+       from NMI context -- raise a softirq instead. */
+    raise_softirq(PCI_SERR_SOFTIRQ);
 }
 
 static void io_check_error(struct cpu_user_regs *regs)
@@ -3563,6 +3569,7 @@ void __init trap_init(void)
     cpu_init();
 
     open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+    open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
 long register_guest_nmi_callback(unsigned long address)
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 4387803..9d8e2e1 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -6,6 +6,7 @@
 #define VCPU_KICK_SOFTIRQ      (NR_COMMON_SOFTIRQS + 2)
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
-#define NR_ARCH_SOFTIRQS       4
+#define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
+#define NR_ARCH_SOFTIRQS       5
 
 #endif /* __ASM_SOFTIRQ_H__ */
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:03:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsZq9-00014s-Jm; Wed, 01 Feb 2012 13:03:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RsZq7-00014j-QK
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:03:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328101379!13294128!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzMjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18058 invoked from network); 1 Feb 2012 13:03:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 13:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320642000"; d="scan'208";a="179944660"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 08:02:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 08:02:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11D2ZfG004864;
	Wed, 1 Feb 2012 05:02:36 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 13:02:16 +0000
Message-ID: <1328101336-9370-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: avoid deadlock after a PCI SERR NMI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
occurs while the CPU is in printk() then Xen may deadlock as
pci_serr_error() calls console_force_unlock() which screws up the
console lock.

printk() isn't safe to call from NMI context so defer the diagnostic
message to a softirq.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/arch/x86/traps.c          |   13 ++++++++++---
 xen/include/asm-x86/softirq.h |    3 ++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b6f7b9a..35c17f2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
     st->vcpu = NULL;
 }
 
+static void pci_serr_softirq(void)
+{
+    printk("\n\nNMI - PCI system error (SERR)\n");
+}
+
 void async_exception_cleanup(struct vcpu *curr)
 {
     int trap;
@@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int reason_idx)
 
 static void pci_serr_error(struct cpu_user_regs *regs)
 {
-    console_force_unlock();
-    printk("\n\nNMI - PCI system error (SERR)\n");
-
     outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI SERR error line. */
+
+    /* Would like to print a diagnostic here but can't call printk()
+       from NMI context -- raise a softirq instead. */
+    raise_softirq(PCI_SERR_SOFTIRQ);
 }
 
 static void io_check_error(struct cpu_user_regs *regs)
@@ -3563,6 +3569,7 @@ void __init trap_init(void)
     cpu_init();
 
     open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+    open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
 long register_guest_nmi_callback(unsigned long address)
diff --git a/xen/include/asm-x86/softirq.h b/xen/include/asm-x86/softirq.h
index 4387803..9d8e2e1 100644
--- a/xen/include/asm-x86/softirq.h
+++ b/xen/include/asm-x86/softirq.h
@@ -6,6 +6,7 @@
 #define VCPU_KICK_SOFTIRQ      (NR_COMMON_SOFTIRQS + 2)
 
 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
-#define NR_ARCH_SOFTIRQS       4
+#define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
+#define NR_ARCH_SOFTIRQS       5
 
 #endif /* __ASM_SOFTIRQ_H__ */
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:18:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13: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.xensource.com>)
	id 1Rsa4G-0001Na-9L; Wed, 01 Feb 2012 13:17:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rsa4F-0001Mr-N1
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:17:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328102257!12646995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30079 invoked from network); 1 Feb 2012 13:17:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 13:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10414756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:17:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:17:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsa46-0007Qn-WC;
	Wed, 01 Feb 2012 13:17:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsa46-0002LF-Mv;
	Wed, 01 Feb 2012 13:17:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 13:17:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11761: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 11643
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

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

version targeted for testing:
 xen                  ab397bd22b56
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 755 lines long.)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:18:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13: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.xensource.com>)
	id 1Rsa4G-0001Na-9L; Wed, 01 Feb 2012 13:17:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rsa4F-0001Mr-N1
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:17:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328102257!12646995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30079 invoked from network); 1 Feb 2012 13:17:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 13:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10414756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:17:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:17:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsa46-0007Qn-WC;
	Wed, 01 Feb 2012 13:17:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsa46-0002LF-Mv;
	Wed, 01 Feb 2012 13:17:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 13:17:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11761: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 11643
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

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

version targeted for testing:
 xen                  ab397bd22b56
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 755 lines long.)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:42:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13: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.xensource.com>)
	id 1RsaSC-0001sv-Ov; Wed, 01 Feb 2012 13:42:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsaSA-0001sq-HH
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:42:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328103739!10944451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6012 invoked from network); 1 Feb 2012 13:42:20 -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;
	1 Feb 2012 13:42:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10415303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:42:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:42:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsaS3-0007cN-08	for xen-devel@lists.xensource.com;
	Wed, 01 Feb 2012 13:42:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsaS2-0000ls-TA	for
	xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:42:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20265.16698.760545.40909@mariner.uk.xensource.com>
Date: Wed, 1 Feb 2012 13:42:18 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11761-mainreport@xen.org>
References: <osstest-11761-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11761: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11761: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    9 guest-start           fail REGR. vs. 11643

This is a Xen crash.  It may not necessarily be a regression since the
previous push; it might be a heisenbug or host-specific.

Log below.

Ian.

Feb  1 12:26:18.338551 [  324.242370] blkback: ring-ref 9, event-channel 28, protocol 1 (x86_32-abi)^M
Feb  1 12:26:18.342506 (XEN) Assertion 'test_bit(vector, desc->arch.used_vectors)' failed at irq.c:670
Feb  1 12:26:24.794531 (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
Feb  1 12:26:24.802505 (XEN) CPU:    0
Feb  1 12:26:24.802519 (XEN) RIP:    e008:[<ffff82c48016737b>] smp_irq_move_cleanup_interrupt+0x2bd/0x33a
Feb  1 12:26:24.814504 (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
Feb  1 12:26:24.814533 (XEN) rax: 0000000000000000   rbx: 00000000000000e5   rcx: ffff82c4802fc060
Feb  1 12:26:24.826505 (XEN) rdx: 00000000000000e5   rsi: 0000000000000082   rdi: ffff8301a7e005ac
Feb  1 12:26:24.826542 (XEN) rbp: ffff82c4802afd68   rsp: ffff82c4802afcd8   r8:  0000000000000020
Feb  1 12:26:24.838514 (XEN) r9:  0000000000000001   r10: ffff82c480226ed0   r11: 0000000000000000
Feb  1 12:26:24.846504 (XEN) r12: ffff8301a7e00580   r13: 0000000000000005   r14: ffff82c4802aff18
Feb  1 12:26:24.858495 (XEN) r15: ffff8301a7e005a8   cr0: 000000008005003b   cr4: 00000000000006f0
Feb  1 12:26:24.858531 (XEN) cr3: 00000001a7f57000   cr2: 00000000b7576ae0
Feb  1 12:26:24.873499 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
Feb  1 12:26:24.873536 (XEN) Xen stack trace from rsp=ffff82c4802afcd8:
Feb  1 12:26:24.885499 (XEN)    ffff82c4802afd38 ffff82c4802afd28 0000000000000000 ffff82c4802aff18
Feb  1 12:26:24.885539 (XEN)    ffff82c4802aff18 0000000000000000 ffff82c4802aff18 ffff82c4802fc060
Feb  1 12:26:24.890645 (XEN)    000000e500000082 ffff82c4802fc060 0000000000000000 0000000000000000
Feb  1 12:26:24.905500 (XEN)    ffff82c4802afd48 ffff8301a7e00580 00000000c1665eb0 ffff8300d7af8000
Feb  1 12:26:24.905535 (XEN)    0000000000000000 0000000000000000 00007d3b7fd50267 ffff82c480152820
Feb  1 12:26:24.917512 (XEN)    0000000000000000 0000000000000000 ffff8300d7af8000 00000000c1665eb0
Feb  1 12:26:24.929501 (XEN)    ffff82c4802afe58 ffff8301a7e00580 0000000000000000 ffff82c480226ed0
Feb  1 12:26:24.941494 (XEN)    0000000000000001 0000000000000020 0000000000000000 ffff82c4802fc05c
Feb  1 12:26:24.941534 (XEN)    ffff82c4802fb9a0 0000000000000082 ffff8301a7e005a8 0000002000000000
Feb  1 12:26:24.946503 (XEN)    ffff82c480168e64 000000000000e008 0000000000000296 ffff82c4802afe28
Feb  1 12:26:24.958495 (XEN)    0000000000000000 ffff82c480168e58 0000000000000000 0000000000000000
Feb  1 12:26:24.958530 (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff8301a7ffa300
Feb  1 12:26:24.970506 (XEN)    ffff82c4802afe78 ffff82c480168f12 ffff8301a7ffa300 ffff8301a7ffa300
Feb  1 12:26:24.982497 (XEN)    ffff82c4802afef8 ffff82c48021aeb8 ffffffff00000005 ffff82c4802afed0
Feb  1 12:26:24.982534 (XEN)    ffff82c4801251b1 ffff82c4802fc580 ffff82c4802aff18 ffff82c48025ac80
Feb  1 12:26:24.990507 (XEN)    ffff82c4802aff18 00000000ffffffff 0000000000000002 ffff82c4802afee0
Feb  1 12:26:25.002502 (XEN)    ffff8300d7af8000 0000000000000000 0000000000000000 0000000000000000
Feb  1 12:26:25.002541 (XEN)    00007d3b7fd500c7 ffff82c48021d61e 00000000c1002427 0000000000000021
Feb  1 12:26:25.014509 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Feb  1 12:26:25.026500 (XEN)    00000000c1665ea8 000000000000000c 0000000000000000 0000000000000000
Feb  1 12:26:25.026540 (XEN) Xen call trace:
Feb  1 12:26:25.034496 (XEN)    [<ffff82c48016737b>] smp_irq_move_cleanup_interrupt+0x2bd/0x33a
Feb  1 12:26:25.034531 (XEN)    [<ffff82c480152820>] irq_move_cleanup_interrupt+0x30/0x40
Feb  1 12:26:25.046505 (XEN)    [<ffff82c480168e64>] desc_guest_eoi+0x17b/0x1ea
Feb  1 12:26:25.046536 (XEN)    [<ffff82c480168f12>] pirq_guest_eoi+0x3f/0x46
Feb  1 12:26:25.058505 (XEN)    [<ffff82c48021aeb8>] compat_physdev_op+0x148/0x1080
Feb  1 12:26:25.058537 (XEN)    [<ffff82c48021d61e>] compat_hypercall+0xae/0x107
Feb  1 12:26:25.070507 (XEN)    
Feb  1 12:26:25.070530 (XEN) 
Feb  1 12:26:25.070540 (XEN) ****************************************
Feb  1 12:26:25.078568 (XEN) Panic on CPU 0:
Feb  1 12:26:25.078584 (XEN) Assertion 'test_bit(vector, desc->arch.used_vectors)' failed at irq.c:670
Feb  1 12:26:25.078610 (XEN) ****************************************
Feb  1 12:26:25.093501 (XEN) 
Feb  1 12:26:25.093518 (XEN) Reboot in five seconds...

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:42:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13: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.xensource.com>)
	id 1RsaSC-0001sv-Ov; Wed, 01 Feb 2012 13:42:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsaSA-0001sq-HH
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:42:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328103739!10944451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6012 invoked from network); 1 Feb 2012 13:42:20 -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;
	1 Feb 2012 13:42:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10415303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:42:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:42:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsaS3-0007cN-08	for xen-devel@lists.xensource.com;
	Wed, 01 Feb 2012 13:42:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsaS2-0000ls-TA	for
	xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:42:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20265.16698.760545.40909@mariner.uk.xensource.com>
Date: Wed, 1 Feb 2012 13:42:18 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11761-mainreport@xen.org>
References: <osstest-11761-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11761: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11761: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    9 guest-start           fail REGR. vs. 11643

This is a Xen crash.  It may not necessarily be a regression since the
previous push; it might be a heisenbug or host-specific.

Log below.

Ian.

Feb  1 12:26:18.338551 [  324.242370] blkback: ring-ref 9, event-channel 28, protocol 1 (x86_32-abi)^M
Feb  1 12:26:18.342506 (XEN) Assertion 'test_bit(vector, desc->arch.used_vectors)' failed at irq.c:670
Feb  1 12:26:24.794531 (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
Feb  1 12:26:24.802505 (XEN) CPU:    0
Feb  1 12:26:24.802519 (XEN) RIP:    e008:[<ffff82c48016737b>] smp_irq_move_cleanup_interrupt+0x2bd/0x33a
Feb  1 12:26:24.814504 (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
Feb  1 12:26:24.814533 (XEN) rax: 0000000000000000   rbx: 00000000000000e5   rcx: ffff82c4802fc060
Feb  1 12:26:24.826505 (XEN) rdx: 00000000000000e5   rsi: 0000000000000082   rdi: ffff8301a7e005ac
Feb  1 12:26:24.826542 (XEN) rbp: ffff82c4802afd68   rsp: ffff82c4802afcd8   r8:  0000000000000020
Feb  1 12:26:24.838514 (XEN) r9:  0000000000000001   r10: ffff82c480226ed0   r11: 0000000000000000
Feb  1 12:26:24.846504 (XEN) r12: ffff8301a7e00580   r13: 0000000000000005   r14: ffff82c4802aff18
Feb  1 12:26:24.858495 (XEN) r15: ffff8301a7e005a8   cr0: 000000008005003b   cr4: 00000000000006f0
Feb  1 12:26:24.858531 (XEN) cr3: 00000001a7f57000   cr2: 00000000b7576ae0
Feb  1 12:26:24.873499 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
Feb  1 12:26:24.873536 (XEN) Xen stack trace from rsp=ffff82c4802afcd8:
Feb  1 12:26:24.885499 (XEN)    ffff82c4802afd38 ffff82c4802afd28 0000000000000000 ffff82c4802aff18
Feb  1 12:26:24.885539 (XEN)    ffff82c4802aff18 0000000000000000 ffff82c4802aff18 ffff82c4802fc060
Feb  1 12:26:24.890645 (XEN)    000000e500000082 ffff82c4802fc060 0000000000000000 0000000000000000
Feb  1 12:26:24.905500 (XEN)    ffff82c4802afd48 ffff8301a7e00580 00000000c1665eb0 ffff8300d7af8000
Feb  1 12:26:24.905535 (XEN)    0000000000000000 0000000000000000 00007d3b7fd50267 ffff82c480152820
Feb  1 12:26:24.917512 (XEN)    0000000000000000 0000000000000000 ffff8300d7af8000 00000000c1665eb0
Feb  1 12:26:24.929501 (XEN)    ffff82c4802afe58 ffff8301a7e00580 0000000000000000 ffff82c480226ed0
Feb  1 12:26:24.941494 (XEN)    0000000000000001 0000000000000020 0000000000000000 ffff82c4802fc05c
Feb  1 12:26:24.941534 (XEN)    ffff82c4802fb9a0 0000000000000082 ffff8301a7e005a8 0000002000000000
Feb  1 12:26:24.946503 (XEN)    ffff82c480168e64 000000000000e008 0000000000000296 ffff82c4802afe28
Feb  1 12:26:24.958495 (XEN)    0000000000000000 ffff82c480168e58 0000000000000000 0000000000000000
Feb  1 12:26:24.958530 (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff8301a7ffa300
Feb  1 12:26:24.970506 (XEN)    ffff82c4802afe78 ffff82c480168f12 ffff8301a7ffa300 ffff8301a7ffa300
Feb  1 12:26:24.982497 (XEN)    ffff82c4802afef8 ffff82c48021aeb8 ffffffff00000005 ffff82c4802afed0
Feb  1 12:26:24.982534 (XEN)    ffff82c4801251b1 ffff82c4802fc580 ffff82c4802aff18 ffff82c48025ac80
Feb  1 12:26:24.990507 (XEN)    ffff82c4802aff18 00000000ffffffff 0000000000000002 ffff82c4802afee0
Feb  1 12:26:25.002502 (XEN)    ffff8300d7af8000 0000000000000000 0000000000000000 0000000000000000
Feb  1 12:26:25.002541 (XEN)    00007d3b7fd500c7 ffff82c48021d61e 00000000c1002427 0000000000000021
Feb  1 12:26:25.014509 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Feb  1 12:26:25.026500 (XEN)    00000000c1665ea8 000000000000000c 0000000000000000 0000000000000000
Feb  1 12:26:25.026540 (XEN) Xen call trace:
Feb  1 12:26:25.034496 (XEN)    [<ffff82c48016737b>] smp_irq_move_cleanup_interrupt+0x2bd/0x33a
Feb  1 12:26:25.034531 (XEN)    [<ffff82c480152820>] irq_move_cleanup_interrupt+0x30/0x40
Feb  1 12:26:25.046505 (XEN)    [<ffff82c480168e64>] desc_guest_eoi+0x17b/0x1ea
Feb  1 12:26:25.046536 (XEN)    [<ffff82c480168f12>] pirq_guest_eoi+0x3f/0x46
Feb  1 12:26:25.058505 (XEN)    [<ffff82c48021aeb8>] compat_physdev_op+0x148/0x1080
Feb  1 12:26:25.058537 (XEN)    [<ffff82c48021d61e>] compat_hypercall+0xae/0x107
Feb  1 12:26:25.070507 (XEN)    
Feb  1 12:26:25.070530 (XEN) 
Feb  1 12:26:25.070540 (XEN) ****************************************
Feb  1 12:26:25.078568 (XEN) Panic on CPU 0:
Feb  1 12:26:25.078584 (XEN) Assertion 'test_bit(vector, desc->arch.used_vectors)' failed at irq.c:670
Feb  1 12:26:25.078610 (XEN) ****************************************
Feb  1 12:26:25.093501 (XEN) 
Feb  1 12:26:25.093518 (XEN) Reboot in five seconds...

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsaVI-00020Z-J5; Wed, 01 Feb 2012 13:45:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsaVG-00020R-Ds
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:45:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328103932!12735427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18908 invoked from network); 1 Feb 2012 13:45:32 -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;
	1 Feb 2012 13:45:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10415388"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:45:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	13:45:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 1 Feb 2012 13:45:31 +0000
In-Reply-To: <CAPLaKK5tqaO-jGMwMf16avhXGf-RF2NNGs3S1Le=M_wqz=0K8g@mail.gmail.com>
References: <CAPLaKK5tqaO-jGMwMf16avhXGf-RF2NNGs3S1Le=M_wqz=0K8g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328103932.17444.67.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xenstore watches and event queue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTAxIGF0IDEyOjM5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IEkndmUgYmVlbiBoYXZpbmcgc29tZSBwcm9ibGVtcyB3aXRoIHhzX3dh
dGNoIGFuZCB4c19yZWFkX3dhdGNoLCBoZXJlCj4gaXMgbXkgc2NlbmFyaW86Cj4gCj4geHNfd2F0
Y2goIi9zb21lL3hlbnN0b3JlL2RpciIpOwo+IFsuLi4gZG8gc29tZSBzdHVmZi4uLl0KPiB4c19y
ZWFkX3dhdGNoKC4uLik7Cj4gWy4uLiBkbyBzb21lIHByb2Nlc3NpbmcgLi4uXQo+IFsuLi4geGVu
c3RvcmUgY2hhbmdlcyAuLi5dCj4geHNfcmVhZF93YXRjaCguLi4pOwo+IAo+IElmIHNvbWVvbmUg
bW9kaWZpZXMgdGhlIHhlbnN0b3JlIGVudHJpZXMgSSdtIHdhdGNoaW5nLCBidXQgSSdtIG5vdAo+
IGN1cnJlbnRseSBvbiB4c19yZWFkX3dhdGNoLCBvbmx5IHRoZSBsYXN0IG1vZGlmaWNhdGlvbiBp
cyByZXR1cm5lZAo+IHdoZW4gSSBjYWxsIHhzX3JlYWRfd2F0Y2gsIEkgd291bGQgZXhwZWN0IHhl
bnN0b3JlIHdhdGNoZXMgdG8gaGF2ZQo+IHNvbWUga2luZCBvZiBxdWV1ZSwgc28gbXVsdGlwbGUg
eGVuc3RvcmUgY2hhbmdlcyBvbiB3YXRjaGVkIGRpcnMgYXJlCj4gbm90IGxvc3QgaWYgSSdtIG5v
dCBjdXJyZW50bHkgYmxvY2tlZCBvbiB4c19yZWFkX3dhdGNoLiBJcyB0aGVyZQo+IGFueXdheSB0
byBhcmNoaXZlIHRoaXM/CgpJIHRoaW5rIHlvdSBuZWVkIHRvIGNvcGUgd2l0aCB0aGlzIHNjZW5h
cmlvIGFueXdheSBiZWNhdXNlIGV2ZW4gaWYgeW91CmdvdCBtdWx0aXBsZSB3YXRjaGVzIHlvdSB3
b3VsZCBuZWVkIHRvIGNvcGUgd2l0aCB0aGUgZmFjdCB0aGF0IHdoaWxlIHlvdQp3ZXJlIHByb2Nl
c3NpbmcgdGhlIGZpcnN0IG9uZSB0aGUgc3Vic2VxdWVudCB3cml0ZSB3b3VsZCBoYXZlIG9jY3Vy
cmVkCmFuZCBzbyB0aGUgdmFsdWUgb2YgdGhlIGtleSB5b3Ugd291bGQgc2VlIHdvdWxkIGJlIHRo
ZSBsYXRlc3QgdmFsdWUuClRoZW4gd2hlbiB5b3UgZ2V0IHRoZSBzZWNvbmQgd2F0Y2ggdGhlcmUg
d291bGQgYmUgbm8gYXBwYXJlbnQgY2hhbmdlCmV0Yy4KClNvIHRoZSB0aGluZ3MgeW91IGRvIGlu
IHJlYWN0aW9uIHRvIGEgeGVuc3RvcmUgd2F0Y2ggbmVlZCB0byBjb3BlIHdpdGgKc2tpcHBpbmcg
c3RhdGVzIGlmIHRoZXkgZG9uJ3QgZW5mb3JjZSB0aGUgc2VxdWVuY2luZyB2aWEgdGhlaXIgb3du
CnByb3RvY29scy4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsaVI-00020Z-J5; Wed, 01 Feb 2012 13:45:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsaVG-00020R-Ds
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:45:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328103932!12735427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18908 invoked from network); 1 Feb 2012 13:45:32 -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;
	1 Feb 2012 13:45:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10415388"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:45:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	13:45:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 1 Feb 2012 13:45:31 +0000
In-Reply-To: <CAPLaKK5tqaO-jGMwMf16avhXGf-RF2NNGs3S1Le=M_wqz=0K8g@mail.gmail.com>
References: <CAPLaKK5tqaO-jGMwMf16avhXGf-RF2NNGs3S1Le=M_wqz=0K8g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328103932.17444.67.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xenstore watches and event queue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTAxIGF0IDEyOjM5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IEkndmUgYmVlbiBoYXZpbmcgc29tZSBwcm9ibGVtcyB3aXRoIHhzX3dh
dGNoIGFuZCB4c19yZWFkX3dhdGNoLCBoZXJlCj4gaXMgbXkgc2NlbmFyaW86Cj4gCj4geHNfd2F0
Y2goIi9zb21lL3hlbnN0b3JlL2RpciIpOwo+IFsuLi4gZG8gc29tZSBzdHVmZi4uLl0KPiB4c19y
ZWFkX3dhdGNoKC4uLik7Cj4gWy4uLiBkbyBzb21lIHByb2Nlc3NpbmcgLi4uXQo+IFsuLi4geGVu
c3RvcmUgY2hhbmdlcyAuLi5dCj4geHNfcmVhZF93YXRjaCguLi4pOwo+IAo+IElmIHNvbWVvbmUg
bW9kaWZpZXMgdGhlIHhlbnN0b3JlIGVudHJpZXMgSSdtIHdhdGNoaW5nLCBidXQgSSdtIG5vdAo+
IGN1cnJlbnRseSBvbiB4c19yZWFkX3dhdGNoLCBvbmx5IHRoZSBsYXN0IG1vZGlmaWNhdGlvbiBp
cyByZXR1cm5lZAo+IHdoZW4gSSBjYWxsIHhzX3JlYWRfd2F0Y2gsIEkgd291bGQgZXhwZWN0IHhl
bnN0b3JlIHdhdGNoZXMgdG8gaGF2ZQo+IHNvbWUga2luZCBvZiBxdWV1ZSwgc28gbXVsdGlwbGUg
eGVuc3RvcmUgY2hhbmdlcyBvbiB3YXRjaGVkIGRpcnMgYXJlCj4gbm90IGxvc3QgaWYgSSdtIG5v
dCBjdXJyZW50bHkgYmxvY2tlZCBvbiB4c19yZWFkX3dhdGNoLiBJcyB0aGVyZQo+IGFueXdheSB0
byBhcmNoaXZlIHRoaXM/CgpJIHRoaW5rIHlvdSBuZWVkIHRvIGNvcGUgd2l0aCB0aGlzIHNjZW5h
cmlvIGFueXdheSBiZWNhdXNlIGV2ZW4gaWYgeW91CmdvdCBtdWx0aXBsZSB3YXRjaGVzIHlvdSB3
b3VsZCBuZWVkIHRvIGNvcGUgd2l0aCB0aGUgZmFjdCB0aGF0IHdoaWxlIHlvdQp3ZXJlIHByb2Nl
c3NpbmcgdGhlIGZpcnN0IG9uZSB0aGUgc3Vic2VxdWVudCB3cml0ZSB3b3VsZCBoYXZlIG9jY3Vy
cmVkCmFuZCBzbyB0aGUgdmFsdWUgb2YgdGhlIGtleSB5b3Ugd291bGQgc2VlIHdvdWxkIGJlIHRo
ZSBsYXRlc3QgdmFsdWUuClRoZW4gd2hlbiB5b3UgZ2V0IHRoZSBzZWNvbmQgd2F0Y2ggdGhlcmUg
d291bGQgYmUgbm8gYXBwYXJlbnQgY2hhbmdlCmV0Yy4KClNvIHRoZSB0aGluZ3MgeW91IGRvIGlu
IHJlYWN0aW9uIHRvIGEgeGVuc3RvcmUgd2F0Y2ggbmVlZCB0byBjb3BlIHdpdGgKc2tpcHBpbmcg
c3RhdGVzIGlmIHRoZXkgZG9uJ3QgZW5mb3JjZSB0aGUgc2VxdWVuY2luZyB2aWEgdGhlaXIgb3du
CnByb3RvY29scy4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:52:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13: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.xensource.com>)
	id 1RsabA-0002S6-55; Wed, 01 Feb 2012 13:51:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsab7-0002Rf-Qe
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:51:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328104295!13275812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6058 invoked from network); 1 Feb 2012 13:51:35 -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;
	1 Feb 2012 13:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10415677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:51:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:51:35 +0000
Date: Wed, 1 Feb 2012 13:53:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
	<CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All your comments make perfect sense, so I made all the changes you
suggested.

8<---


diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..958534c 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -682,6 +687,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 13:52:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 13: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.xensource.com>)
	id 1RsabA-0002S6-55; Wed, 01 Feb 2012 13:51:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsab7-0002Rf-Qe
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 13:51:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328104295!13275812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6058 invoked from network); 1 Feb 2012 13:51:35 -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;
	1 Feb 2012 13:51:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10415677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:51:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:51:35 +0000
Date: Wed, 1 Feb 2012 13:53:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
	<CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All your comments make perfect sense, so I made all the changes you
suggested.

8<---


diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..958534c 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -682,6 +687,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:13:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14: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.xensource.com>)
	id 1RsavJ-0003T0-NW; Wed, 01 Feb 2012 14:12:33 +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 1RsavI-0003Sr-9O
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:12:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328105498!52464676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24995 invoked from network); 1 Feb 2012 14:11:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10416375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:12:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:12:25 +0000
Date: Wed, 1 Feb 2012 14:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
	<3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328070813 28800
> # Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
> # Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 
> Implement QMP stop and resume functionality and split
> device model save into 3 parts:
>  suspend_dm(domid)
>  save_dm(domid, fd)
>  resume_dm(domid)
> 
> Integrate Device model suspend into suspend_common_callback
>
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
>      return rc ? 0 : 1;
>  }
>  
> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int ret = 0, fd2 = -1;
> +    const char *filename = libxl__device_model_savefile(gc, domid);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +                   "Saving device model state to %s", filename);
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> +        if (fd2 < 0) {
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                             "Unable to create a QEMU save file\n");
> +            return ERROR_FAIL;
> +        }
> +        /* Save DM state into fd2 */
> +        ret = libxl__qmp_migrate(gc, domid, fd2);
> +        if (ret)
> +            unlink(filename);
> +        close(fd2);
> +        fd2 = -1;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +

Why do you need to introduce libxl__qmp_stop and libxl__qmp_resume?

Also keep in mind that I am about to change the command sent to save the
state of devices to "save_devices" because "migrate" is not working
properly with Xen.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:13:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14: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.xensource.com>)
	id 1RsavJ-0003T0-NW; Wed, 01 Feb 2012 14:12:33 +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 1RsavI-0003Sr-9O
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:12:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328105498!52464676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24995 invoked from network); 1 Feb 2012 14:11:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="10416375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:12:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:12:25 +0000
Date: Wed, 1 Feb 2012 14:14:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
	<3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328070813 28800
> # Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
> # Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 
> Implement QMP stop and resume functionality and split
> device model save into 3 parts:
>  suspend_dm(domid)
>  save_dm(domid, fd)
>  resume_dm(domid)
> 
> Integrate Device model suspend into suspend_common_callback
>
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Tue Jan 31 20:33:33 2012 -0800
> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
>      return rc ? 0 : 1;
>  }
>  
> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int ret = 0, fd2 = -1;
> +    const char *filename = libxl__device_model_savefile(gc, domid);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +                   "Saving device model state to %s", filename);
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> +        if (fd2 < 0) {
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                             "Unable to create a QEMU save file\n");
> +            return ERROR_FAIL;
> +        }
> +        /* Save DM state into fd2 */
> +        ret = libxl__qmp_migrate(gc, domid, fd2);
> +        if (ret)
> +            unlink(filename);
> +        close(fd2);
> +        fd2 = -1;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +

Why do you need to introduce libxl__qmp_stop and libxl__qmp_resume?

Also keep in mind that I am about to change the command sent to save the
state of devices to "save_devices" because "migrate" is not working
properly with Xen.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:25:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsb7u-0003wb-17; Wed, 01 Feb 2012 14:25:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1Rsb7r-0003wW-Lp
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:25:32 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328106322!12740694!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6080 invoked from network); 1 Feb 2012 14:25:24 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:25:24 -0000
Received: by dadp13 with SMTP id p13so1140712dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 06:25:22 -0800 (PST)
Received: by 10.68.221.137 with SMTP id qe9mr15111328pbc.71.1328106322133;
	Wed, 01 Feb 2012 06:25:22 -0800 (PST)
Received: from [172.16.0.10] ([205.250.160.181])
	by mx.google.com with ESMTPS id w4sm56326547pbf.4.2012.02.01.06.25.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 06:25:20 -0800 (PST)
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
	<CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
	<alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <51F2CDA8-0721-416B-8CD6-38E3E139EBFD@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 06:25:15 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-01, at 5:53 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> All your comments make perfect sense, so I made all the changes you
> suggested.
> 
> 8<---
> 
> 
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..958534c 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
>         tailbuf_free_pv(&buf->u.pv);
> }
> 
> +struct toolstack_data_t {
> +    uint8_t *data;
> +    uint32_t len;
> +};
> +
> typedef struct {
>     void* pages;
>     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
> @@ -682,6 +687,8 @@ typedef struct {
>     uint64_t acpi_ioport_location;
>     uint64_t viridian;
>     uint64_t vm_generationid_addr;
> +
> +    struct toolstack_data_t tdata;
> } pagebuf_t;
> 
> static int pagebuf_init(pagebuf_t* buf)
> @@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
> 
> static void pagebuf_free(pagebuf_t* buf)
> {
> +    if (buf->tdata.data != NULL) {
> +        free(buf->tdata.data);
> +        buf->tdata.data = NULL;
> +    }
>     if (buf->pages) {
>         free(buf->pages);
>         buf->pages = NULL;
> @@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
>         }
>         return pagebuf_get_one(xch, ctx, buf, fd, dom);
> 
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
> +            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
> +            if ( buf->tdata.data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
> +            return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        }
> +
>     case XC_SAVE_ID_ENABLE_COMPRESSION:
>         /* We cannot set compression flag directly in pagebuf structure,
>          * since this pagebuf still has uncompressed pages that are yet to
> @@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int console_evtchn, unsigned long *console_mfn,
>                       unsigned int hvm, unsigned int pae, int superpages,
>                       int no_incr_generationid,
> -                      unsigned long *vm_generationid_addr)
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks)
> {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> 
>     pagebuf_t pagebuf;
>     tailbuf_t tailbuf, tmptail;
> +    struct toolstack_data_t tdata, tdatatmp;
>     void* vcpup;
>     uint64_t console_pfn = 0;
> 
> @@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>     pagebuf_init(&pagebuf);
>     memset(&tailbuf, 0, sizeof(tailbuf));
>     tailbuf.ishvm = hvm;
> +    memset(&tdata, 0, sizeof(tdata));
> 
>     memset(ctx, 0, sizeof(*ctx));
> 
> @@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
>     }
> 
> +    tdatatmp = tdata;
> +    tdata = pagebuf.tdata;
> +    pagebuf.tdata = tdatatmp;
> +
>     if ( ctx->last_checkpoint )
>     {
>         // DPRINTF("Last checkpoint, finishing\n");
> @@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>     goto out;
> 
>   finish_hvm:
> +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
> +            tdata.data != NULL )
> +    {
> +        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
> +                    callbacks->data) < 0 )
> +        {
> +            PERROR("error calling toolstack_restore");
> +            free(tdata.data);
> +            goto out;
> +        }
> +    }
> +    free(tdata.data);
> +
>     /* Dump the QEMU state to a state file for QEMU to load */
>     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
>         PERROR("Error dumping QEMU state to file");
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index f473dd7..318c433 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>         }
>     }
> 
> +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> +    {
> +        int id = XC_SAVE_ID_TOOLSTACK;
> +        uint8_t *buf;
> +        uint32_t len;
> +
> +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> +        {
> +            PERROR("Error calling toolstack_save");
> +            goto out;
> +        }
> +        wrexact(io_fd, &id, sizeof(id));
> +        wrexact(io_fd, &len, sizeof(len));
> +        wrexact(io_fd, buf, len);
> +        free(buf);
> +    }
> +
>     if ( !callbacks->checkpoint )
>     {
>         /*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 6026370..76aa475 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -44,6 +44,14 @@ struct save_callbacks {
>     /* Enable qemu-dm logging dirty pages to xen */
>     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
> 
> +    /* Save toolstack specific data
> +     * @param buf the buffer with the data to be saved
> +     * @param len the length of the buffer
> +     * The callee allocates the buffer, the caller frees it (buffer must
> +     * be free'able).
> +     */
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
> +
>     /* to be provided as the last argument to each callback function */
>     void* data;
> };
> @@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>                    unsigned long vm_generationid_addr);
> 
> 
> +/* callbacks provided by xc_domain_restore */
> +struct restore_callbacks {
> +    /* callback to restore toolstack specific data */
> +    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> +            uint32_t size, void* data);
> +
> +    /* to be provided as the last argument to each callback function */
> +    void* data;
> +};
> +
> /**
>  * This function will restore a saved domain.
>  *
> @@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>  * @parm superpages non-zero to allocate guest memory with superpages
>  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
>  * @parm vm_generationid_addr returned with the address of the generation id buffer
> + * @parm callbacks non-NULL to receive a callback to restore toolstack
> + *       specific data
>  * @return 0 on success, -1 on failure
>  */
> int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> @@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int console_evtchn, unsigned long *console_mfn,
>                       unsigned int hvm, unsigned int pae, int superpages,
>                       int no_incr_generationid,
> -              unsigned long *vm_generationid_addr);
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks);
> /**
>  * xc_domain_restore writes a file to disk that contains the device
>  * model saved state.
> diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
> index 6286b68..46fdeaa 100644
> --- a/tools/libxc/xg_save_restore.h
> +++ b/tools/libxc/xg_save_restore.h
> @@ -254,6 +254,7 @@
> #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
> #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
> #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
> +#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
> 
> /*
> ** We process save/restore/migrate in batches of pages; the below
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 91643a2..2c5eec5 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
>                            state->store_port, &state->store_mfn,
>                            state->console_port, &state->console_mfn,
>                            hvm, pae, superpages, no_incr_generationid,
> -                           &state->vm_generationid_addr);
> +                           &state->vm_generationid_addr, NULL);
>     if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>         return ERROR_FAIL;
> diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> index 63d53a8..306a10e 100644
> --- a/tools/xcutils/xc_restore.c
> +++ b/tools/xcutils/xc_restore.c
> @@ -47,7 +47,7 @@ main(int argc, char **argv)
> 
>     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
>                             console_evtchn, &console_mfn, hvm, pae, superpages,
> -                            0, NULL);
> +                            0, NULL, NULL);
> 
>     if ( ret == 0 )
>     {
> 

Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:25:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:25:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsb7u-0003wb-17; Wed, 01 Feb 2012 14:25:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1Rsb7r-0003wW-Lp
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:25:32 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328106322!12740694!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6080 invoked from network); 1 Feb 2012 14:25:24 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:25:24 -0000
Received: by dadp13 with SMTP id p13so1140712dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 06:25:22 -0800 (PST)
Received: by 10.68.221.137 with SMTP id qe9mr15111328pbc.71.1328106322133;
	Wed, 01 Feb 2012 06:25:22 -0800 (PST)
Received: from [172.16.0.10] ([205.250.160.181])
	by mx.google.com with ESMTPS id w4sm56326547pbf.4.2012.02.01.06.25.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 06:25:20 -0800 (PST)
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
	<CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
	<alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <51F2CDA8-0721-416B-8CD6-38E3E139EBFD@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 06:25:15 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-01, at 5:53 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> All your comments make perfect sense, so I made all the changes you
> suggested.
> 
> 8<---
> 
> 
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..958534c 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
>         tailbuf_free_pv(&buf->u.pv);
> }
> 
> +struct toolstack_data_t {
> +    uint8_t *data;
> +    uint32_t len;
> +};
> +
> typedef struct {
>     void* pages;
>     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
> @@ -682,6 +687,8 @@ typedef struct {
>     uint64_t acpi_ioport_location;
>     uint64_t viridian;
>     uint64_t vm_generationid_addr;
> +
> +    struct toolstack_data_t tdata;
> } pagebuf_t;
> 
> static int pagebuf_init(pagebuf_t* buf)
> @@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
> 
> static void pagebuf_free(pagebuf_t* buf)
> {
> +    if (buf->tdata.data != NULL) {
> +        free(buf->tdata.data);
> +        buf->tdata.data = NULL;
> +    }
>     if (buf->pages) {
>         free(buf->pages);
>         buf->pages = NULL;
> @@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
>         }
>         return pagebuf_get_one(xch, ctx, buf, fd, dom);
> 
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
> +            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
> +            if ( buf->tdata.data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
> +            return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        }
> +
>     case XC_SAVE_ID_ENABLE_COMPRESSION:
>         /* We cannot set compression flag directly in pagebuf structure,
>          * since this pagebuf still has uncompressed pages that are yet to
> @@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int console_evtchn, unsigned long *console_mfn,
>                       unsigned int hvm, unsigned int pae, int superpages,
>                       int no_incr_generationid,
> -                      unsigned long *vm_generationid_addr)
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks)
> {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> 
>     pagebuf_t pagebuf;
>     tailbuf_t tailbuf, tmptail;
> +    struct toolstack_data_t tdata, tdatatmp;
>     void* vcpup;
>     uint64_t console_pfn = 0;
> 
> @@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>     pagebuf_init(&pagebuf);
>     memset(&tailbuf, 0, sizeof(tailbuf));
>     tailbuf.ishvm = hvm;
> +    memset(&tdata, 0, sizeof(tdata));
> 
>     memset(ctx, 0, sizeof(*ctx));
> 
> @@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
>     }
> 
> +    tdatatmp = tdata;
> +    tdata = pagebuf.tdata;
> +    pagebuf.tdata = tdatatmp;
> +
>     if ( ctx->last_checkpoint )
>     {
>         // DPRINTF("Last checkpoint, finishing\n");
> @@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>     goto out;
> 
>   finish_hvm:
> +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
> +            tdata.data != NULL )
> +    {
> +        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
> +                    callbacks->data) < 0 )
> +        {
> +            PERROR("error calling toolstack_restore");
> +            free(tdata.data);
> +            goto out;
> +        }
> +    }
> +    free(tdata.data);
> +
>     /* Dump the QEMU state to a state file for QEMU to load */
>     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
>         PERROR("Error dumping QEMU state to file");
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index f473dd7..318c433 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>         }
>     }
> 
> +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> +    {
> +        int id = XC_SAVE_ID_TOOLSTACK;
> +        uint8_t *buf;
> +        uint32_t len;
> +
> +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> +        {
> +            PERROR("Error calling toolstack_save");
> +            goto out;
> +        }
> +        wrexact(io_fd, &id, sizeof(id));
> +        wrexact(io_fd, &len, sizeof(len));
> +        wrexact(io_fd, buf, len);
> +        free(buf);
> +    }
> +
>     if ( !callbacks->checkpoint )
>     {
>         /*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 6026370..76aa475 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -44,6 +44,14 @@ struct save_callbacks {
>     /* Enable qemu-dm logging dirty pages to xen */
>     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
> 
> +    /* Save toolstack specific data
> +     * @param buf the buffer with the data to be saved
> +     * @param len the length of the buffer
> +     * The callee allocates the buffer, the caller frees it (buffer must
> +     * be free'able).
> +     */
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
> +
>     /* to be provided as the last argument to each callback function */
>     void* data;
> };
> @@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>                    unsigned long vm_generationid_addr);
> 
> 
> +/* callbacks provided by xc_domain_restore */
> +struct restore_callbacks {
> +    /* callback to restore toolstack specific data */
> +    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> +            uint32_t size, void* data);
> +
> +    /* to be provided as the last argument to each callback function */
> +    void* data;
> +};
> +
> /**
>  * This function will restore a saved domain.
>  *
> @@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>  * @parm superpages non-zero to allocate guest memory with superpages
>  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
>  * @parm vm_generationid_addr returned with the address of the generation id buffer
> + * @parm callbacks non-NULL to receive a callback to restore toolstack
> + *       specific data
>  * @return 0 on success, -1 on failure
>  */
> int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> @@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                       unsigned int console_evtchn, unsigned long *console_mfn,
>                       unsigned int hvm, unsigned int pae, int superpages,
>                       int no_incr_generationid,
> -              unsigned long *vm_generationid_addr);
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks);
> /**
>  * xc_domain_restore writes a file to disk that contains the device
>  * model saved state.
> diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
> index 6286b68..46fdeaa 100644
> --- a/tools/libxc/xg_save_restore.h
> +++ b/tools/libxc/xg_save_restore.h
> @@ -254,6 +254,7 @@
> #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
> #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
> #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
> +#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
> 
> /*
> ** We process save/restore/migrate in batches of pages; the below
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 91643a2..2c5eec5 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
>                            state->store_port, &state->store_mfn,
>                            state->console_port, &state->console_mfn,
>                            hvm, pae, superpages, no_incr_generationid,
> -                           &state->vm_generationid_addr);
> +                           &state->vm_generationid_addr, NULL);
>     if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>         return ERROR_FAIL;
> diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> index 63d53a8..306a10e 100644
> --- a/tools/xcutils/xc_restore.c
> +++ b/tools/xcutils/xc_restore.c
> @@ -47,7 +47,7 @@ main(int argc, char **argv)
> 
>     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
>                             console_evtchn, &console_mfn, hvm, pae, superpages,
> -                            0, NULL);
> +                            0, NULL, NULL);
> 
>     if ( ret == 0 )
>     {
> 

Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:37:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsbJ5-0004Id-Il; Wed, 01 Feb 2012 14:37:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsbJ4-0004IY-3g
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:37:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328107020!12476691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25377 invoked from network); 1 Feb 2012 14:37:00 -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;
	1 Feb 2012 14:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:36:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	14:36:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Wed, 1 Feb 2012 14:36:59 +0000
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328107019.17444.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 12:04 +0000, Francisco Rocha wrote:
> Hi everyon,
> 
> I am new to Xen Development, so I don't know if it is a bug or my lack of knowledge regarding Xen dev.
> 
> I am running Fedora 16 x86-64 XFCE with the latest xen unstable and when I run the following code the machine reboots.

Ouch, it certainly shouldn't do that! Do you get any serial console
message or stack trace etc?

You might find it helpful to pass the "noreboot" option on the
hypervisor command line so that you have a chance to see the error
message.

Ian.


> 
> #include <xenctrl.h>
> 
> 
> int main(int argc, char **argv)
> {
>         xc_interface *xch;
>         xch = xc_interface_open(NULL, NULL, 0);
> 
>         printf("version: %d\n", xc_gnttab_get_version(xch, 1));
> 
>         xc_interface_close(xch);
> 
>         return 0;
> }
> 
> Can anyone help? Thank you for your time.
> 
> Cheers,
> Francisco
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:37:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsbJ5-0004Id-Il; Wed, 01 Feb 2012 14:37:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsbJ4-0004IY-3g
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:37:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328107020!12476691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25377 invoked from network); 1 Feb 2012 14:37:00 -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;
	1 Feb 2012 14:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:36:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	14:36:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Wed, 1 Feb 2012 14:36:59 +0000
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328107019.17444.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 12:04 +0000, Francisco Rocha wrote:
> Hi everyon,
> 
> I am new to Xen Development, so I don't know if it is a bug or my lack of knowledge regarding Xen dev.
> 
> I am running Fedora 16 x86-64 XFCE with the latest xen unstable and when I run the following code the machine reboots.

Ouch, it certainly shouldn't do that! Do you get any serial console
message or stack trace etc?

You might find it helpful to pass the "noreboot" option on the
hypervisor command line so that you have a chance to see the error
message.

Ian.


> 
> #include <xenctrl.h>
> 
> 
> int main(int argc, char **argv)
> {
>         xc_interface *xch;
>         xch = xc_interface_open(NULL, NULL, 0);
> 
>         printf("version: %d\n", xc_gnttab_get_version(xch, 1));
> 
>         xc_interface_close(xch);
> 
>         return 0;
> }
> 
> Can anyone help? Thank you for your time.
> 
> Cheers,
> Francisco
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsbL4-0004Nh-5O; Wed, 01 Feb 2012 14:39:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsbL2-0004NP-3S
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:39:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328107141!12745248!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 608 invoked from network); 1 Feb 2012 14:39:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:39:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:38:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:38:58 +0000
Date: Wed, 1 Feb 2012 14:40:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <51F2CDA8-0721-416B-8CD6-38E3E139EBFD@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202011440180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
	<CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
	<alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
	<51F2CDA8-0721-416B-8CD6-38E3E139EBFD@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Shriram Rajagopalan wrote:
> On 2012-02-01, at 5:53 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > All your comments make perfect sense, so I made all the changes you
> > suggested.
> > 
> > 8<---
> > 
> > 
> > diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> > index 3fda6f8..958534c 100644
> > --- a/tools/libxc/xc_domain_restore.c
> > +++ b/tools/libxc/xc_domain_restore.c
> > @@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
> >         tailbuf_free_pv(&buf->u.pv);
> > }
> > 
> > +struct toolstack_data_t {
> > +    uint8_t *data;
> > +    uint32_t len;
> > +};
> > +
> > typedef struct {
> >     void* pages;
> >     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
> > @@ -682,6 +687,8 @@ typedef struct {
> >     uint64_t acpi_ioport_location;
> >     uint64_t viridian;
> >     uint64_t vm_generationid_addr;
> > +
> > +    struct toolstack_data_t tdata;
> > } pagebuf_t;
> > 
> > static int pagebuf_init(pagebuf_t* buf)
> > @@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
> > 
> > static void pagebuf_free(pagebuf_t* buf)
> > {
> > +    if (buf->tdata.data != NULL) {
> > +        free(buf->tdata.data);
> > +        buf->tdata.data = NULL;
> > +    }
> >     if (buf->pages) {
> >         free(buf->pages);
> >         buf->pages = NULL;
> > @@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> >         }
> >         return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > 
> > +    case XC_SAVE_ID_TOOLSTACK:
> > +        {
> > +            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
> > +            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
> > +            if ( buf->tdata.data == NULL )
> > +            {
> > +                PERROR("error memory allocation");
> > +                return -1;
> > +            }
> > +            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
> > +            return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > +        }
> > +
> >     case XC_SAVE_ID_ENABLE_COMPRESSION:
> >         /* We cannot set compression flag directly in pagebuf structure,
> >          * since this pagebuf still has uncompressed pages that are yet to
> > @@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                       unsigned int console_evtchn, unsigned long *console_mfn,
> >                       unsigned int hvm, unsigned int pae, int superpages,
> >                       int no_incr_generationid,
> > -                      unsigned long *vm_generationid_addr)
> > +                      unsigned long *vm_generationid_addr,
> > +                      struct restore_callbacks *callbacks)
> > {
> >     DECLARE_DOMCTL;
> >     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> > @@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > 
> >     pagebuf_t pagebuf;
> >     tailbuf_t tailbuf, tmptail;
> > +    struct toolstack_data_t tdata, tdatatmp;
> >     void* vcpup;
> >     uint64_t console_pfn = 0;
> > 
> > @@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >     pagebuf_init(&pagebuf);
> >     memset(&tailbuf, 0, sizeof(tailbuf));
> >     tailbuf.ishvm = hvm;
> > +    memset(&tdata, 0, sizeof(tdata));
> > 
> >     memset(ctx, 0, sizeof(*ctx));
> > 
> > @@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
> >     }
> > 
> > +    tdatatmp = tdata;
> > +    tdata = pagebuf.tdata;
> > +    pagebuf.tdata = tdatatmp;
> > +
> >     if ( ctx->last_checkpoint )
> >     {
> >         // DPRINTF("Last checkpoint, finishing\n");
> > @@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >     goto out;
> > 
> >   finish_hvm:
> > +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
> > +            tdata.data != NULL )
> > +    {
> > +        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
> > +                    callbacks->data) < 0 )
> > +        {
> > +            PERROR("error calling toolstack_restore");
> > +            free(tdata.data);
> > +            goto out;
> > +        }
> > +    }
> > +    free(tdata.data);
> > +
> >     /* Dump the QEMU state to a state file for QEMU to load */
> >     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
> >         PERROR("Error dumping QEMU state to file");
> > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > index f473dd7..318c433 100644
> > --- a/tools/libxc/xc_domain_save.c
> > +++ b/tools/libxc/xc_domain_save.c
> > @@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >         }
> >     }
> > 
> > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > +    {
> > +        int id = XC_SAVE_ID_TOOLSTACK;
> > +        uint8_t *buf;
> > +        uint32_t len;
> > +
> > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > +        {
> > +            PERROR("Error calling toolstack_save");
> > +            goto out;
> > +        }
> > +        wrexact(io_fd, &id, sizeof(id));
> > +        wrexact(io_fd, &len, sizeof(len));
> > +        wrexact(io_fd, buf, len);
> > +        free(buf);
> > +    }
> > +
> >     if ( !callbacks->checkpoint )
> >     {
> >         /*
> > diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> > index 6026370..76aa475 100644
> > --- a/tools/libxc/xenguest.h
> > +++ b/tools/libxc/xenguest.h
> > @@ -44,6 +44,14 @@ struct save_callbacks {
> >     /* Enable qemu-dm logging dirty pages to xen */
> >     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
> > 
> > +    /* Save toolstack specific data
> > +     * @param buf the buffer with the data to be saved
> > +     * @param len the length of the buffer
> > +     * The callee allocates the buffer, the caller frees it (buffer must
> > +     * be free'able).
> > +     */
> > +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
> > +
> >     /* to be provided as the last argument to each callback function */
> >     void* data;
> > };
> > @@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >                    unsigned long vm_generationid_addr);
> > 
> > 
> > +/* callbacks provided by xc_domain_restore */
> > +struct restore_callbacks {
> > +    /* callback to restore toolstack specific data */
> > +    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> > +            uint32_t size, void* data);
> > +
> > +    /* to be provided as the last argument to each callback function */
> > +    void* data;
> > +};
> > +
> > /**
> >  * This function will restore a saved domain.
> >  *
> > @@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >  * @parm superpages non-zero to allocate guest memory with superpages
> >  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
> >  * @parm vm_generationid_addr returned with the address of the generation id buffer
> > + * @parm callbacks non-NULL to receive a callback to restore toolstack
> > + *       specific data
> >  * @return 0 on success, -1 on failure
> >  */
> > int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > @@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                       unsigned int console_evtchn, unsigned long *console_mfn,
> >                       unsigned int hvm, unsigned int pae, int superpages,
> >                       int no_incr_generationid,
> > -              unsigned long *vm_generationid_addr);
> > +                      unsigned long *vm_generationid_addr,
> > +                      struct restore_callbacks *callbacks);
> > /**
> >  * xc_domain_restore writes a file to disk that contains the device
> >  * model saved state.
> > diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
> > index 6286b68..46fdeaa 100644
> > --- a/tools/libxc/xg_save_restore.h
> > +++ b/tools/libxc/xg_save_restore.h
> > @@ -254,6 +254,7 @@
> > #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
> > #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
> > #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
> > +#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
> > 
> > /*
> > ** We process save/restore/migrate in batches of pages; the below
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 91643a2..2c5eec5 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
> >                            state->store_port, &state->store_mfn,
> >                            state->console_port, &state->console_mfn,
> >                            hvm, pae, superpages, no_incr_generationid,
> > -                           &state->vm_generationid_addr);
> > +                           &state->vm_generationid_addr, NULL);
> >     if ( rc ) {
> >         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
> >         return ERROR_FAIL;
> > diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> > index 63d53a8..306a10e 100644
> > --- a/tools/xcutils/xc_restore.c
> > +++ b/tools/xcutils/xc_restore.c
> > @@ -47,7 +47,7 @@ main(int argc, char **argv)
> > 
> >     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
> >                             console_evtchn, &console_mfn, hvm, pae, superpages,
> > -                            0, NULL);
> > +                            0, NULL, NULL);
> > 
> >     if ( ret == 0 )
> >     {
> > 
> 
> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 

Thanks, I'll resend the patch with a proper commit message.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsbL4-0004Nh-5O; Wed, 01 Feb 2012 14:39:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsbL2-0004NP-3S
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:39:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328107141!12745248!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 608 invoked from network); 1 Feb 2012 14:39:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:39:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:38:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:38:58 +0000
Date: Wed, 1 Feb 2012 14:40:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <51F2CDA8-0721-416B-8CD6-38E3E139EBFD@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202011440180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
	<CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
	<alpine.DEB.2.00.1202011350230.3196@kaball-desktop>
	<51F2CDA8-0721-416B-8CD6-38E3E139EBFD@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Shriram Rajagopalan wrote:
> On 2012-02-01, at 5:53 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > All your comments make perfect sense, so I made all the changes you
> > suggested.
> > 
> > 8<---
> > 
> > 
> > diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> > index 3fda6f8..958534c 100644
> > --- a/tools/libxc/xc_domain_restore.c
> > +++ b/tools/libxc/xc_domain_restore.c
> > @@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
> >         tailbuf_free_pv(&buf->u.pv);
> > }
> > 
> > +struct toolstack_data_t {
> > +    uint8_t *data;
> > +    uint32_t len;
> > +};
> > +
> > typedef struct {
> >     void* pages;
> >     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
> > @@ -682,6 +687,8 @@ typedef struct {
> >     uint64_t acpi_ioport_location;
> >     uint64_t viridian;
> >     uint64_t vm_generationid_addr;
> > +
> > +    struct toolstack_data_t tdata;
> > } pagebuf_t;
> > 
> > static int pagebuf_init(pagebuf_t* buf)
> > @@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
> > 
> > static void pagebuf_free(pagebuf_t* buf)
> > {
> > +    if (buf->tdata.data != NULL) {
> > +        free(buf->tdata.data);
> > +        buf->tdata.data = NULL;
> > +    }
> >     if (buf->pages) {
> >         free(buf->pages);
> >         buf->pages = NULL;
> > @@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> >         }
> >         return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > 
> > +    case XC_SAVE_ID_TOOLSTACK:
> > +        {
> > +            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
> > +            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
> > +            if ( buf->tdata.data == NULL )
> > +            {
> > +                PERROR("error memory allocation");
> > +                return -1;
> > +            }
> > +            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
> > +            return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > +        }
> > +
> >     case XC_SAVE_ID_ENABLE_COMPRESSION:
> >         /* We cannot set compression flag directly in pagebuf structure,
> >          * since this pagebuf still has uncompressed pages that are yet to
> > @@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                       unsigned int console_evtchn, unsigned long *console_mfn,
> >                       unsigned int hvm, unsigned int pae, int superpages,
> >                       int no_incr_generationid,
> > -                      unsigned long *vm_generationid_addr)
> > +                      unsigned long *vm_generationid_addr,
> > +                      struct restore_callbacks *callbacks)
> > {
> >     DECLARE_DOMCTL;
> >     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> > @@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > 
> >     pagebuf_t pagebuf;
> >     tailbuf_t tailbuf, tmptail;
> > +    struct toolstack_data_t tdata, tdatatmp;
> >     void* vcpup;
> >     uint64_t console_pfn = 0;
> > 
> > @@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >     pagebuf_init(&pagebuf);
> >     memset(&tailbuf, 0, sizeof(tailbuf));
> >     tailbuf.ishvm = hvm;
> > +    memset(&tdata, 0, sizeof(tdata));
> > 
> >     memset(ctx, 0, sizeof(*ctx));
> > 
> > @@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
> >     }
> > 
> > +    tdatatmp = tdata;
> > +    tdata = pagebuf.tdata;
> > +    pagebuf.tdata = tdatatmp;
> > +
> >     if ( ctx->last_checkpoint )
> >     {
> >         // DPRINTF("Last checkpoint, finishing\n");
> > @@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >     goto out;
> > 
> >   finish_hvm:
> > +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
> > +            tdata.data != NULL )
> > +    {
> > +        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
> > +                    callbacks->data) < 0 )
> > +        {
> > +            PERROR("error calling toolstack_restore");
> > +            free(tdata.data);
> > +            goto out;
> > +        }
> > +    }
> > +    free(tdata.data);
> > +
> >     /* Dump the QEMU state to a state file for QEMU to load */
> >     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
> >         PERROR("Error dumping QEMU state to file");
> > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > index f473dd7..318c433 100644
> > --- a/tools/libxc/xc_domain_save.c
> > +++ b/tools/libxc/xc_domain_save.c
> > @@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >         }
> >     }
> > 
> > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > +    {
> > +        int id = XC_SAVE_ID_TOOLSTACK;
> > +        uint8_t *buf;
> > +        uint32_t len;
> > +
> > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > +        {
> > +            PERROR("Error calling toolstack_save");
> > +            goto out;
> > +        }
> > +        wrexact(io_fd, &id, sizeof(id));
> > +        wrexact(io_fd, &len, sizeof(len));
> > +        wrexact(io_fd, buf, len);
> > +        free(buf);
> > +    }
> > +
> >     if ( !callbacks->checkpoint )
> >     {
> >         /*
> > diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> > index 6026370..76aa475 100644
> > --- a/tools/libxc/xenguest.h
> > +++ b/tools/libxc/xenguest.h
> > @@ -44,6 +44,14 @@ struct save_callbacks {
> >     /* Enable qemu-dm logging dirty pages to xen */
> >     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
> > 
> > +    /* Save toolstack specific data
> > +     * @param buf the buffer with the data to be saved
> > +     * @param len the length of the buffer
> > +     * The callee allocates the buffer, the caller frees it (buffer must
> > +     * be free'able).
> > +     */
> > +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
> > +
> >     /* to be provided as the last argument to each callback function */
> >     void* data;
> > };
> > @@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >                    unsigned long vm_generationid_addr);
> > 
> > 
> > +/* callbacks provided by xc_domain_restore */
> > +struct restore_callbacks {
> > +    /* callback to restore toolstack specific data */
> > +    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> > +            uint32_t size, void* data);
> > +
> > +    /* to be provided as the last argument to each callback function */
> > +    void* data;
> > +};
> > +
> > /**
> >  * This function will restore a saved domain.
> >  *
> > @@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >  * @parm superpages non-zero to allocate guest memory with superpages
> >  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
> >  * @parm vm_generationid_addr returned with the address of the generation id buffer
> > + * @parm callbacks non-NULL to receive a callback to restore toolstack
> > + *       specific data
> >  * @return 0 on success, -1 on failure
> >  */
> > int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > @@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >                       unsigned int console_evtchn, unsigned long *console_mfn,
> >                       unsigned int hvm, unsigned int pae, int superpages,
> >                       int no_incr_generationid,
> > -              unsigned long *vm_generationid_addr);
> > +                      unsigned long *vm_generationid_addr,
> > +                      struct restore_callbacks *callbacks);
> > /**
> >  * xc_domain_restore writes a file to disk that contains the device
> >  * model saved state.
> > diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
> > index 6286b68..46fdeaa 100644
> > --- a/tools/libxc/xg_save_restore.h
> > +++ b/tools/libxc/xg_save_restore.h
> > @@ -254,6 +254,7 @@
> > #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
> > #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
> > #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
> > +#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
> > 
> > /*
> > ** We process save/restore/migrate in batches of pages; the below
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 91643a2..2c5eec5 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
> >                            state->store_port, &state->store_mfn,
> >                            state->console_port, &state->console_mfn,
> >                            hvm, pae, superpages, no_incr_generationid,
> > -                           &state->vm_generationid_addr);
> > +                           &state->vm_generationid_addr, NULL);
> >     if ( rc ) {
> >         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
> >         return ERROR_FAIL;
> > diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> > index 63d53a8..306a10e 100644
> > --- a/tools/xcutils/xc_restore.c
> > +++ b/tools/xcutils/xc_restore.c
> > @@ -47,7 +47,7 @@ main(int argc, char **argv)
> > 
> >     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
> >                             console_evtchn, &console_mfn, hvm, pae, superpages,
> > -                            0, NULL);
> > +                            0, NULL, NULL);
> > 
> >     if ( ret == 0 )
> >     {
> > 
> 
> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 

Thanks, I'll resend the patch with a proper commit message.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:45:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 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.xensource.com>)
	id 1RsbRC-0004bM-WC; Wed, 01 Feb 2012 14:45:30 +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 1RsbRB-0004bH-1D
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:45:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328107496!58049693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7164 invoked from network); 1 Feb 2012 14:44:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:44:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:45:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:45:24 +0000
Date: Wed, 1 Feb 2012 14:47:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1202011441360.3196@kaball-desktop>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] qemu-xen: Pass through,
 utility functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jean Guyader wrote:
> Add a function to map a specific bar into a pt_dev.
> 
> Add a function that gets called everytime the bar of a pass
> through device gets remap.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |   34 ++++++++++++++++++++++++++++++++++
>  hw/pass-through.h |    3 +++
>  hw/pt-graphics.c  |    7 +++++++
>  3 files changed, 44 insertions(+), 0 deletions(-)

Could you please send inline patches in the future?


> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index dbe8804..1bdb223 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -93,6 +93,7 @@
>  #include <unistd.h>
>  #include <sys/ioctl.h>
>  #include <assert.h>
> +#include <sys/mman.h>
>  
>  extern int gfx_passthru;
>  int igd_passthru = 0;
> @@ -1155,6 +1156,9 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
>      if ( e_size == 0 )
>          return;
>  
> +    if (assigned_device->pci_dev->device_class == 0x0300)
> +        pt_graphic_bar_remap(assigned_device, i, first_map, DPCI_ADD_MAPPING);
> +
>      if ( !first_map && old_ebase != -1 )
>      {
>          if ( has_msix_mapping(assigned_device, i) )

Wouldn't it be better if we move this into _pt_iomem_helper?


> @@ -1969,6 +1973,9 @@ static void pt_unregister_regions(struct pt_dev *assigned_device)
>          if ( type == PCI_ADDRESS_SPACE_MEM ||
>               type == PCI_ADDRESS_SPACE_MEM_PREFETCH )
>          {
> +            if (assigned_device->pci_dev->device_class == 0x0300)
> +                pt_graphic_bar_remap(assigned_device, i, 0, DPCI_REMOVE_MAPPING);
> +
>              ret = xc_domain_memory_mapping(xc_handle, domid,
>                      assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
>                      assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
>
> @@ -2101,6 +2108,33 @@ int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len)
>      return ret;
>  }
>  
> +int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar)
> +{
> +    int fd;
> +    struct stat s;
> +    uint8_t *map;
> +
> +    char filename[1024];
> +
> +    snprintf(filename, 1024, "/sys/bus/pci/devices/0000:%02x:%02x.%01x/resource%d",
> +            pt_dev->pci_dev->bus,
> +            pt_dev->pci_dev->dev,
> +            pt_dev->pci_dev->func,
> +            bar);
> +    fd = open(filename, O_RDWR | O_SYNC);
> +    if (fd < 0)
> +        return fd;
> +    fstat(fd, &s);
> +
> +    map = mmap(0, s.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> +    if (map != MAP_FAILED)
> +    {
> +        pt_dev->bases[bar].map = map;
> +        return 0;
> +    }
> +    return errno;
> +}
> +
>  /* parse BAR */
>  static int pt_bar_reg_parse(
>          struct pt_dev *ptdev, struct pt_reg_info_tbl *reg)
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..26e6ff1 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -170,6 +170,7 @@ struct pt_region {
>          uint64_t pio_base;
>          uint64_t u;
>      } access;
> +    uint8_t *map;
>  };
>  
>  struct pt_msi_info {
> @@ -414,6 +415,7 @@ uint8_t pci_intx(struct pt_dev *ptdev);
>  struct pci_dev *pt_pci_get_dev(int bus, int dev, int func);
>  u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len);
>  int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len);
> +int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar);
>  void intel_pch_init(PCIBus *bus);
>  int register_vga_regions(struct pt_dev *real_device);
>  int unregister_vga_regions(struct pt_dev *real_device);
> @@ -422,6 +424,7 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map);

rename "int map" to "int op" for clarity


>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..5d5e5da 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -94,6 +94,13 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  }
>  
>  /*
> + * Callback whenever a bar get remapped
> + */
> +void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
> +{
> +}
> +
> +/*
>   * register VGA resources for the domain with assigned gfx
>   */
>  int register_vga_regions(struct pt_dev *real_device)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:45:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 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.xensource.com>)
	id 1RsbRC-0004bM-WC; Wed, 01 Feb 2012 14:45:30 +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 1RsbRB-0004bH-1D
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:45:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328107496!58049693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7164 invoked from network); 1 Feb 2012 14:44:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:44:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:45:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:45:24 +0000
Date: Wed, 1 Feb 2012 14:47:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1202011441360.3196@kaball-desktop>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] qemu-xen: Pass through,
 utility functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jean Guyader wrote:
> Add a function to map a specific bar into a pt_dev.
> 
> Add a function that gets called everytime the bar of a pass
> through device gets remap.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |   34 ++++++++++++++++++++++++++++++++++
>  hw/pass-through.h |    3 +++
>  hw/pt-graphics.c  |    7 +++++++
>  3 files changed, 44 insertions(+), 0 deletions(-)

Could you please send inline patches in the future?


> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index dbe8804..1bdb223 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -93,6 +93,7 @@
>  #include <unistd.h>
>  #include <sys/ioctl.h>
>  #include <assert.h>
> +#include <sys/mman.h>
>  
>  extern int gfx_passthru;
>  int igd_passthru = 0;
> @@ -1155,6 +1156,9 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
>      if ( e_size == 0 )
>          return;
>  
> +    if (assigned_device->pci_dev->device_class == 0x0300)
> +        pt_graphic_bar_remap(assigned_device, i, first_map, DPCI_ADD_MAPPING);
> +
>      if ( !first_map && old_ebase != -1 )
>      {
>          if ( has_msix_mapping(assigned_device, i) )

Wouldn't it be better if we move this into _pt_iomem_helper?


> @@ -1969,6 +1973,9 @@ static void pt_unregister_regions(struct pt_dev *assigned_device)
>          if ( type == PCI_ADDRESS_SPACE_MEM ||
>               type == PCI_ADDRESS_SPACE_MEM_PREFETCH )
>          {
> +            if (assigned_device->pci_dev->device_class == 0x0300)
> +                pt_graphic_bar_remap(assigned_device, i, 0, DPCI_REMOVE_MAPPING);
> +
>              ret = xc_domain_memory_mapping(xc_handle, domid,
>                      assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
>                      assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
>
> @@ -2101,6 +2108,33 @@ int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len)
>      return ret;
>  }
>  
> +int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar)
> +{
> +    int fd;
> +    struct stat s;
> +    uint8_t *map;
> +
> +    char filename[1024];
> +
> +    snprintf(filename, 1024, "/sys/bus/pci/devices/0000:%02x:%02x.%01x/resource%d",
> +            pt_dev->pci_dev->bus,
> +            pt_dev->pci_dev->dev,
> +            pt_dev->pci_dev->func,
> +            bar);
> +    fd = open(filename, O_RDWR | O_SYNC);
> +    if (fd < 0)
> +        return fd;
> +    fstat(fd, &s);
> +
> +    map = mmap(0, s.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> +    if (map != MAP_FAILED)
> +    {
> +        pt_dev->bases[bar].map = map;
> +        return 0;
> +    }
> +    return errno;
> +}
> +
>  /* parse BAR */
>  static int pt_bar_reg_parse(
>          struct pt_dev *ptdev, struct pt_reg_info_tbl *reg)
> diff --git a/hw/pass-through.h b/hw/pass-through.h
> index 884139c..26e6ff1 100644
> --- a/hw/pass-through.h
> +++ b/hw/pass-through.h
> @@ -170,6 +170,7 @@ struct pt_region {
>          uint64_t pio_base;
>          uint64_t u;
>      } access;
> +    uint8_t *map;
>  };
>  
>  struct pt_msi_info {
> @@ -414,6 +415,7 @@ uint8_t pci_intx(struct pt_dev *ptdev);
>  struct pci_dev *pt_pci_get_dev(int bus, int dev, int func);
>  u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len);
>  int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len);
> +int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar);
>  void intel_pch_init(PCIBus *bus);
>  int register_vga_regions(struct pt_dev *real_device);
>  int unregister_vga_regions(struct pt_dev *real_device);
> @@ -422,6 +424,7 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
>             uint16_t did, const char *name, uint16_t revision);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map);

rename "int map" to "int op" for clarity


>  
>  #endif /* __PASSTHROUGH_H__ */
>  
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..5d5e5da 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -94,6 +94,13 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  }
>  
>  /*
> + * Callback whenever a bar get remapped
> + */
> +void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
> +{
> +}
> +
> +/*
>   * register VGA resources for the domain with assigned gfx
>   */
>  int register_vga_regions(struct pt_dev *real_device)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:49:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14: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.xensource.com>)
	id 1RsbUc-0004z2-KS; Wed, 01 Feb 2012 14:49: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 1RsbUb-0004y9-92
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:49:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328107676!59323677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20725 invoked from network); 1 Feb 2012 14:47:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:48:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	14:48:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott <segfaultreloaded@gmail.com>
Date: Wed, 1 Feb 2012 14:48:48 +0000
In-Reply-To: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328107728.17444.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 13:15 +0000, John McDermott wrote:
> Xen Developers,
> 
> FYI, in 4.1-testing, tools/libxl/xl_cmdimpl.c, in function
> main_cpupoollist, the variable opt_long is set but not used. Tools
> won't make with this warning.

Our test system compilers obviously don't generate this particular
warning so it slipped through. Thanks for reporting.

Looks like fallout from 22838:aab67c1c6b87 which removed the (nop)
implementation of that option.

The following just nukes it altogether, the generic handling of
unsupported options already prints something.

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328107525 0
# Node ID 6e1db0380ba3467e26128706a62195bf2816e00e
# Parent  667da384457b0ec5f8f2ea4ec3c1ee43008e7ed5
xl: Drop -l option to xl cpupool-list

The implementation (which was a nop) was removed back in 22838:aab67c1c6b87 but
this now causes "set but not used" warnings from some compilers. Might as well
just nuke the option entirely.

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

diff -r 667da384457b -r 6e1db0380ba3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
@@ -5538,11 +5538,9 @@ int main_cpupoollist(int argc, char **ar
     int option_index = 0;
     static struct option long_options[] = {
         {"help", 0, 0, 'h'},
-        {"long", 0, 0, 'l'},
         {"cpus", 0, 0, 'c'},
         {0, 0, 0, 0}
     };
-    int opt_long = 0;
     int opt_cpus = 0;
     const char *pool = NULL;
     libxl_cpupoolinfo *poolinfo;
@@ -5552,7 +5550,7 @@ int main_cpupoollist(int argc, char **ar
     int ret = 0;
 
     while (1) {
-        opt = getopt_long(argc, argv, "hlc", long_options, &option_index);
+        opt = getopt_long(argc, argv, "hc", long_options, &option_index);
         if (opt == -1)
             break;
 
@@ -5560,9 +5558,6 @@ int main_cpupoollist(int argc, char **ar
         case 'h':
             help("cpupool-list");
             return 0;
-        case 'l':
-            opt_long = 1;
-            break;
         case 'c':
             opt_cpus = 1;
             break;



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:49:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14: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.xensource.com>)
	id 1RsbUc-0004z2-KS; Wed, 01 Feb 2012 14:49: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 1RsbUb-0004y9-92
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:49:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328107676!59323677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20725 invoked from network); 1 Feb 2012 14:47:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 14:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:48:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	14:48:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott <segfaultreloaded@gmail.com>
Date: Wed, 1 Feb 2012 14:48:48 +0000
In-Reply-To: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328107728.17444.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Andre Przywara <andre.przywara@amd.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 13:15 +0000, John McDermott wrote:
> Xen Developers,
> 
> FYI, in 4.1-testing, tools/libxl/xl_cmdimpl.c, in function
> main_cpupoollist, the variable opt_long is set but not used. Tools
> won't make with this warning.

Our test system compilers obviously don't generate this particular
warning so it slipped through. Thanks for reporting.

Looks like fallout from 22838:aab67c1c6b87 which removed the (nop)
implementation of that option.

The following just nukes it altogether, the generic handling of
unsupported options already prints something.

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328107525 0
# Node ID 6e1db0380ba3467e26128706a62195bf2816e00e
# Parent  667da384457b0ec5f8f2ea4ec3c1ee43008e7ed5
xl: Drop -l option to xl cpupool-list

The implementation (which was a nop) was removed back in 22838:aab67c1c6b87 but
this now causes "set but not used" warnings from some compilers. Might as well
just nuke the option entirely.

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

diff -r 667da384457b -r 6e1db0380ba3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
@@ -5538,11 +5538,9 @@ int main_cpupoollist(int argc, char **ar
     int option_index = 0;
     static struct option long_options[] = {
         {"help", 0, 0, 'h'},
-        {"long", 0, 0, 'l'},
         {"cpus", 0, 0, 'c'},
         {0, 0, 0, 0}
     };
-    int opt_long = 0;
     int opt_cpus = 0;
     const char *pool = NULL;
     libxl_cpupoolinfo *poolinfo;
@@ -5552,7 +5550,7 @@ int main_cpupoollist(int argc, char **ar
     int ret = 0;
 
     while (1) {
-        opt = getopt_long(argc, argv, "hlc", long_options, &option_index);
+        opt = getopt_long(argc, argv, "hc", long_options, &option_index);
         if (opt == -1)
             break;
 
@@ -5560,9 +5558,6 @@ int main_cpupoollist(int argc, char **ar
         case 'h':
             help("cpupool-list");
             return 0;
-        case 'l':
-            opt_long = 1;
-            break;
         case 'c':
             opt_cpus = 1;
             break;



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:51:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsbWI-0005AN-4s; Wed, 01 Feb 2012 14:50:46 +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 1RsbWG-0005AC-JY
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:50:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328107725!62104663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13835 invoked from network); 1 Feb 2012 14:48:45 -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;
	1 Feb 2012 14:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:50:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:50:42 +0000
Date: Wed, 1 Feb 2012 14:52:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1202011447450.3196@kaball-desktop>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jean Guyader wrote:
> 
> Reset Intel GPU fences when the domain starts (first mapping
> of Bar0).
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pt-graphics.c |  133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 133 insertions(+), 0 deletions(-)
> 
inline patches please


> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index 5d5e5da..7403abe 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,31 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +#define IGFX_CANTIGA            0x10
> +#define IGFX_IRONLAKE           0x20
> +#define IGFX_IBEXPEAK           0x30
> +#define IGFX_COUGARPOINT        0x40
> +
> +struct igfx_chip
> +{
> +    int chip;
> +    uint16_t device_id;
> +};
> +
> +struct igfx_chip igfx_chips[] =
> +{
> +    {IGFX_IRONLAKE,     0x0042},
> +    {IGFX_IRONLAKE,     0x0046},
> +    {IGFX_CANTIGA,      0x20e4},
> +    {IGFX_CANTIGA,      0x2a42},
> +    {IGFX_CANTIGA,      0x2e12},
> +    {IGFX_COUGARPOINT,  0x0152},
> +    {IGFX_COUGARPOINT,  0x0112},
> +    {IGFX_COUGARPOINT,  0x0116},
> +    {IGFX_COUGARPOINT,  0x0126},
> +    {0, 0}
> +};
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +62,98 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +static int igd_get_chip(struct pt_dev *p)
> +{
> +    int i;
> +    int chip = 0;
> +    int devid = p->pci_dev->device_id;
> +
> +    for (i = 0; igfx_chips[i].chip; i++)
> +        if (devid == igfx_chips[i].device_id)
> +        {
> +            chip = igfx_chips[i].chip;
> +            break;
> +        }
> +
> +    if (!chip)
> +    {
> +        if (devid & 0x2000)
> +            chip = IGFX_CANTIGA;
> +        else if (devid & 0x100)
> +            chip =  IGFX_COUGARPOINT;
> +        else
> +            chip = IGFX_IRONLAKE;
> +        PT_LOG("GUESS FOR CHIP 0x%04x as type %x", devid, chip);
> +    }
> +    return chip;
> +}
> +
> +
> +static uint32_t igd_mmio_read(struct pt_dev *p, uint32_t addr, uint8_t size)
> +{
> +    uint8_t *map = p->bases[0].map;
> +    uint32_t ret;
> +
> +    switch (size)
> +    {
> +        case 1:
> +            ret = *(volatile uint8_t *)(map + addr);
> +            break;
> +        case 2:
> +            ret = *(volatile uint16_t *)(map + addr);
> +            break;
> +        case 4:
> +            ret = *(volatile uint32_t *)(map + addr);
> +            break;
> +        default:
> +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> +    }
> +    return ret;
> +}

igd_mmio_read is currently unused


> +static void igd_mmio_write(struct pt_dev *p, uint32_t addr, uint32_t val,
> +                           uint8_t size)
> +{
> +    uint8_t *map = p->bases[0].map;
> +
> +    switch (size)
> +    {
> +        case 1:
> +            *(volatile uint8_t *)(map + addr) = (uint8_t)val;
> +            break;
> +        case 2:
> +            *(volatile uint16_t *)(map + addr) = (uint16_t)val;
> +            break;
> +        case 4:
> +            *(volatile uint32_t *)(map + addr) = (uint32_t)val;
> +            break;
> +        default:
> +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> +    }
> +}
> +
> +static void igd_reset_fences(struct pt_dev *pt_dev)
> +{
> +    int i = 0;
> +    uint32_t fence_addr;
> +
> +    switch (igd_get_chip(pt_dev))
> +    {
> +        case IGFX_CANTIGA:
> +        case IGFX_IRONLAKE:
> +        case IGFX_IBEXPEAK:
> +            fence_addr = 0x3000;
> +        case IGFX_COUGARPOINT:
> +            fence_addr = 0x100000;
> +    }
> +
> +    for (i = 0; i < 16; i++)
> +    {
> +        igd_mmio_write(pt_dev, fence_addr + (i << 4), 0, 4);
> +        igd_mmio_write(pt_dev, fence_addr + (i << 4) + 4, 0, 4);
> +    }
> +}
> +
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -98,6 +215,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>   */
>  void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
>  {
> +    /*
> +     * Reset the fence register on the first remap
> +     * of Bar0 for a Intel GPU
> +     */
> +    if (real_device->pci_dev->device_class == 0x0300 &&
> +            real_device->pci_dev->device_id == PCI_VENDOR_ID_INTEL &&
> +            bar == 0 && first_map && map == DPCI_ADD_MAPPING)
> +    {
> +        igd_reset_fences(real_device);
> +    }
>  }

coding style, see http://git.savannah.gnu.org/cgit/qemu.git/tree/CODING_STYLE


>  /*
> @@ -137,6 +264,12 @@ int register_vga_regions(struct pt_dev *real_device)
>          PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
>      }
>  
> +    if (vendor_id == PCI_VENDOR_ID_INTEL)
> +    {
> +        if (pt_pci_host_map_bar(real_device, 0) != 0)
> +            PT_LOG("Can't map Intel Bar 0\n");
> +    }

How fatal is this error? Maybe we need to return an error from
register_vga_regions and propagate it upward?

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 14:51:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 14:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsbWI-0005AN-4s; Wed, 01 Feb 2012 14:50:46 +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 1RsbWG-0005AC-JY
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 14:50:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328107725!62104663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13835 invoked from network); 1 Feb 2012 14:48:45 -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;
	1 Feb 2012 14:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10417346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 14:50:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 14:50:42 +0000
Date: Wed, 1 Feb 2012 14:52:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1202011447450.3196@kaball-desktop>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jean Guyader wrote:
> 
> Reset Intel GPU fences when the domain starts (first mapping
> of Bar0).
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pt-graphics.c |  133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 133 insertions(+), 0 deletions(-)
> 
inline patches please


> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index 5d5e5da..7403abe 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -13,6 +13,31 @@
>  extern int gfx_passthru;
>  extern int igd_passthru;
>  
> +#define IGFX_CANTIGA            0x10
> +#define IGFX_IRONLAKE           0x20
> +#define IGFX_IBEXPEAK           0x30
> +#define IGFX_COUGARPOINT        0x40
> +
> +struct igfx_chip
> +{
> +    int chip;
> +    uint16_t device_id;
> +};
> +
> +struct igfx_chip igfx_chips[] =
> +{
> +    {IGFX_IRONLAKE,     0x0042},
> +    {IGFX_IRONLAKE,     0x0046},
> +    {IGFX_CANTIGA,      0x20e4},
> +    {IGFX_CANTIGA,      0x2a42},
> +    {IGFX_CANTIGA,      0x2e12},
> +    {IGFX_COUGARPOINT,  0x0152},
> +    {IGFX_COUGARPOINT,  0x0112},
> +    {IGFX_COUGARPOINT,  0x0116},
> +    {IGFX_COUGARPOINT,  0x0126},
> +    {0, 0}
> +};
> +
>  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>  {
>      PT_LOG("pch_map_irq called\n");
> @@ -37,6 +62,98 @@ void intel_pch_init(PCIBus *bus)
>                          pch_map_irq, "intel_bridge_1f");
>  }
>  
> +static int igd_get_chip(struct pt_dev *p)
> +{
> +    int i;
> +    int chip = 0;
> +    int devid = p->pci_dev->device_id;
> +
> +    for (i = 0; igfx_chips[i].chip; i++)
> +        if (devid == igfx_chips[i].device_id)
> +        {
> +            chip = igfx_chips[i].chip;
> +            break;
> +        }
> +
> +    if (!chip)
> +    {
> +        if (devid & 0x2000)
> +            chip = IGFX_CANTIGA;
> +        else if (devid & 0x100)
> +            chip =  IGFX_COUGARPOINT;
> +        else
> +            chip = IGFX_IRONLAKE;
> +        PT_LOG("GUESS FOR CHIP 0x%04x as type %x", devid, chip);
> +    }
> +    return chip;
> +}
> +
> +
> +static uint32_t igd_mmio_read(struct pt_dev *p, uint32_t addr, uint8_t size)
> +{
> +    uint8_t *map = p->bases[0].map;
> +    uint32_t ret;
> +
> +    switch (size)
> +    {
> +        case 1:
> +            ret = *(volatile uint8_t *)(map + addr);
> +            break;
> +        case 2:
> +            ret = *(volatile uint16_t *)(map + addr);
> +            break;
> +        case 4:
> +            ret = *(volatile uint32_t *)(map + addr);
> +            break;
> +        default:
> +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> +    }
> +    return ret;
> +}

igd_mmio_read is currently unused


> +static void igd_mmio_write(struct pt_dev *p, uint32_t addr, uint32_t val,
> +                           uint8_t size)
> +{
> +    uint8_t *map = p->bases[0].map;
> +
> +    switch (size)
> +    {
> +        case 1:
> +            *(volatile uint8_t *)(map + addr) = (uint8_t)val;
> +            break;
> +        case 2:
> +            *(volatile uint16_t *)(map + addr) = (uint16_t)val;
> +            break;
> +        case 4:
> +            *(volatile uint32_t *)(map + addr) = (uint32_t)val;
> +            break;
> +        default:
> +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> +    }
> +}
> +
> +static void igd_reset_fences(struct pt_dev *pt_dev)
> +{
> +    int i = 0;
> +    uint32_t fence_addr;
> +
> +    switch (igd_get_chip(pt_dev))
> +    {
> +        case IGFX_CANTIGA:
> +        case IGFX_IRONLAKE:
> +        case IGFX_IBEXPEAK:
> +            fence_addr = 0x3000;
> +        case IGFX_COUGARPOINT:
> +            fence_addr = 0x100000;
> +    }
> +
> +    for (i = 0; i < 16; i++)
> +    {
> +        igd_mmio_write(pt_dev, fence_addr + (i << 4), 0, 4);
> +        igd_mmio_write(pt_dev, fence_addr + (i << 4) + 4, 0, 4);
> +    }
> +}
> +
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -98,6 +215,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>   */
>  void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
>  {
> +    /*
> +     * Reset the fence register on the first remap
> +     * of Bar0 for a Intel GPU
> +     */
> +    if (real_device->pci_dev->device_class == 0x0300 &&
> +            real_device->pci_dev->device_id == PCI_VENDOR_ID_INTEL &&
> +            bar == 0 && first_map && map == DPCI_ADD_MAPPING)
> +    {
> +        igd_reset_fences(real_device);
> +    }
>  }

coding style, see http://git.savannah.gnu.org/cgit/qemu.git/tree/CODING_STYLE


>  /*
> @@ -137,6 +264,12 @@ int register_vga_regions(struct pt_dev *real_device)
>          PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
>      }
>  
> +    if (vendor_id == PCI_VENDOR_ID_INTEL)
> +    {
> +        if (pt_pci_host_map_bar(real_device, 0) != 0)
> +            PT_LOG("Can't map Intel Bar 0\n");
> +    }

How fatal is this error? Maybe we need to return an error from
register_vga_regions and propagate it upward?

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsc4T-0006bX-MG; Wed, 01 Feb 2012 15:26:05 +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 1Rsc4S-0006bS-Jx
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:26:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328109926!50673543!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26760 invoked from network); 1 Feb 2012 15:25:26 -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;
	1 Feb 2012 15:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10418152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 15:26:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 15:26:03 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsc4R-0008Ba-4G;
	Wed, 01 Feb 2012 15:26:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsc4Q-0003Wv-VJ;
	Wed, 01 Feb 2012 15:26:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11770-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 15:26:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11770: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11770 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11770/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

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

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win            7 windows-install              fail   like 10764
 test-i386-i386-win           14 guest-start.2   fail in 11749 blocked in 10764

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-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11749 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11749 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsc4T-0006bX-MG; Wed, 01 Feb 2012 15:26:05 +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 1Rsc4S-0006bS-Jx
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:26:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328109926!50673543!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26760 invoked from network); 1 Feb 2012 15:25:26 -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;
	1 Feb 2012 15:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10418152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 15:26:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 15:26:03 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsc4R-0008Ba-4G;
	Wed, 01 Feb 2012 15:26:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsc4Q-0003Wv-VJ;
	Wed, 01 Feb 2012 15:26:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11770-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 15:26:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11770: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11770 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11770/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

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

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win            7 windows-install              fail   like 10764
 test-i386-i386-win           14 guest-start.2   fail in 11749 blocked in 10764

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-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11749 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11749 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15: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.xensource.com>)
	id 1Rsc53-0006eG-41; Wed, 01 Feb 2012 15:26:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rsc51-0006dr-Lf
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:26:39 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328109991!11107658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 927 invoked from network); 1 Feb 2012 15:26: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;
	1 Feb 2012 15:26:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10418162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 15:26:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 15:26:31 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1Rsc4s-0008Bm-QC;
	Wed, 01 Feb 2012 15:26:30 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rsc4g-0000It-S2;
	Wed, 01 Feb 2012 15:26:18 +0000
Date: Wed, 1 Feb 2012 15:26:18 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120201152618.GB25777@spongy.cam.xci-test.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<alpine.DEB.2.00.1202011441360.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202011441360.3196@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] qemu-xen: Pass through,
	utility functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02 02:47, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Jean Guyader wrote:
> > Add a function to map a specific bar into a pt_dev.
> > 
> > Add a function that gets called everytime the bar of a pass
> > through device gets remap.
> > 
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > ---
> >  hw/pass-through.c |   34 ++++++++++++++++++++++++++++++++++
> >  hw/pass-through.h |    3 +++
> >  hw/pt-graphics.c  |    7 +++++++
> >  3 files changed, 44 insertions(+), 0 deletions(-)
> 
> Could you please send inline patches in the future?
> 
> 
> > diff --git a/hw/pass-through.c b/hw/pass-through.c
> > index dbe8804..1bdb223 100644
> > --- a/hw/pass-through.c
> > +++ b/hw/pass-through.c
> > @@ -93,6 +93,7 @@
> >  #include <unistd.h>
> >  #include <sys/ioctl.h>
> >  #include <assert.h>
> > +#include <sys/mman.h>
> >  
> >  extern int gfx_passthru;
> >  int igd_passthru = 0;
> > @@ -1155,6 +1156,9 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
> >      if ( e_size == 0 )
> >          return;
> >  
> > +    if (assigned_device->pci_dev->device_class == 0x0300)
> > +        pt_graphic_bar_remap(assigned_device, i, first_map, DPCI_ADD_MAPPING);
> > +
> >      if ( !first_map && old_ebase != -1 )
> >      {
> >          if ( has_msix_mapping(assigned_device, i) )
> 
> Wouldn't it be better if we move this into _pt_iomem_helper?
> 
> 

It will be equivalent, but at least it will make the current pt_ioemu_map function
smaller which isn't a bad thing.

Jean

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15: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.xensource.com>)
	id 1Rsc53-0006eG-41; Wed, 01 Feb 2012 15:26:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rsc51-0006dr-Lf
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:26:39 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328109991!11107658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 927 invoked from network); 1 Feb 2012 15:26: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;
	1 Feb 2012 15:26:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10418162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 15:26:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 15:26:31 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1Rsc4s-0008Bm-QC;
	Wed, 01 Feb 2012 15:26:30 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rsc4g-0000It-S2;
	Wed, 01 Feb 2012 15:26:18 +0000
Date: Wed, 1 Feb 2012 15:26:18 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120201152618.GB25777@spongy.cam.xci-test.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<alpine.DEB.2.00.1202011441360.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202011441360.3196@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] qemu-xen: Pass through,
	utility functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02 02:47, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Jean Guyader wrote:
> > Add a function to map a specific bar into a pt_dev.
> > 
> > Add a function that gets called everytime the bar of a pass
> > through device gets remap.
> > 
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > ---
> >  hw/pass-through.c |   34 ++++++++++++++++++++++++++++++++++
> >  hw/pass-through.h |    3 +++
> >  hw/pt-graphics.c  |    7 +++++++
> >  3 files changed, 44 insertions(+), 0 deletions(-)
> 
> Could you please send inline patches in the future?
> 
> 
> > diff --git a/hw/pass-through.c b/hw/pass-through.c
> > index dbe8804..1bdb223 100644
> > --- a/hw/pass-through.c
> > +++ b/hw/pass-through.c
> > @@ -93,6 +93,7 @@
> >  #include <unistd.h>
> >  #include <sys/ioctl.h>
> >  #include <assert.h>
> > +#include <sys/mman.h>
> >  
> >  extern int gfx_passthru;
> >  int igd_passthru = 0;
> > @@ -1155,6 +1156,9 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
> >      if ( e_size == 0 )
> >          return;
> >  
> > +    if (assigned_device->pci_dev->device_class == 0x0300)
> > +        pt_graphic_bar_remap(assigned_device, i, first_map, DPCI_ADD_MAPPING);
> > +
> >      if ( !first_map && old_ebase != -1 )
> >      {
> >          if ( has_msix_mapping(assigned_device, i) )
> 
> Wouldn't it be better if we move this into _pt_iomem_helper?
> 
> 

It will be equivalent, but at least it will make the current pt_ioemu_map function
smaller which isn't a bad thing.

Jean

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:28:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15: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.xensource.com>)
	id 1Rsc6j-0006mM-Kj; Wed, 01 Feb 2012 15:28:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rsc6i-0006lt-7I
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:28:24 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328110097!5006279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26034 invoked from network); 1 Feb 2012 15:28:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 15:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10418218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 15:28:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 15:28:17 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1Rsc6b-0008CV-45;
	Wed, 01 Feb 2012 15:28:17 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rsc6P-0000JJ-63;
	Wed, 01 Feb 2012 15:28:05 +0000
Date: Wed, 1 Feb 2012 15:28:05 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120201152804.GC25777@spongy.cam.xci-test.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
	<alpine.DEB.2.00.1202011447450.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202011447450.3196@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02 02:52, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Jean Guyader wrote:
> > 
> > Reset Intel GPU fences when the domain starts (first mapping
> > of Bar0).
> > 
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > ---
> >  hw/pt-graphics.c |  133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 133 insertions(+), 0 deletions(-)
> > 
> inline patches please
> 
> 
> > diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> > index 5d5e5da..7403abe 100644
> > --- a/hw/pt-graphics.c
> > +++ b/hw/pt-graphics.c
> > @@ -13,6 +13,31 @@
> >  extern int gfx_passthru;
> >  extern int igd_passthru;
> >  
> > +#define IGFX_CANTIGA            0x10
> > +#define IGFX_IRONLAKE           0x20
> > +#define IGFX_IBEXPEAK           0x30
> > +#define IGFX_COUGARPOINT        0x40
> > +
> > +struct igfx_chip
> > +{
> > +    int chip;
> > +    uint16_t device_id;
> > +};
> > +
> > +struct igfx_chip igfx_chips[] =
> > +{
> > +    {IGFX_IRONLAKE,     0x0042},
> > +    {IGFX_IRONLAKE,     0x0046},
> > +    {IGFX_CANTIGA,      0x20e4},
> > +    {IGFX_CANTIGA,      0x2a42},
> > +    {IGFX_CANTIGA,      0x2e12},
> > +    {IGFX_COUGARPOINT,  0x0152},
> > +    {IGFX_COUGARPOINT,  0x0112},
> > +    {IGFX_COUGARPOINT,  0x0116},
> > +    {IGFX_COUGARPOINT,  0x0126},
> > +    {0, 0}
> > +};
> > +
> >  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
> >  {
> >      PT_LOG("pch_map_irq called\n");
> > @@ -37,6 +62,98 @@ void intel_pch_init(PCIBus *bus)
> >                          pch_map_irq, "intel_bridge_1f");
> >  }
> >  
> > +static int igd_get_chip(struct pt_dev *p)
> > +{
> > +    int i;
> > +    int chip = 0;
> > +    int devid = p->pci_dev->device_id;
> > +
> > +    for (i = 0; igfx_chips[i].chip; i++)
> > +        if (devid == igfx_chips[i].device_id)
> > +        {
> > +            chip = igfx_chips[i].chip;
> > +            break;
> > +        }
> > +
> > +    if (!chip)
> > +    {
> > +        if (devid & 0x2000)
> > +            chip = IGFX_CANTIGA;
> > +        else if (devid & 0x100)
> > +            chip =  IGFX_COUGARPOINT;
> > +        else
> > +            chip = IGFX_IRONLAKE;
> > +        PT_LOG("GUESS FOR CHIP 0x%04x as type %x", devid, chip);
> > +    }
> > +    return chip;
> > +}
> > +
> > +
> > +static uint32_t igd_mmio_read(struct pt_dev *p, uint32_t addr, uint8_t size)
> > +{
> > +    uint8_t *map = p->bases[0].map;
> > +    uint32_t ret;
> > +
> > +    switch (size)
> > +    {
> > +        case 1:
> > +            ret = *(volatile uint8_t *)(map + addr);
> > +            break;
> > +        case 2:
> > +            ret = *(volatile uint16_t *)(map + addr);
> > +            break;
> > +        case 4:
> > +            ret = *(volatile uint32_t *)(map + addr);
> > +            break;
> > +        default:
> > +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> > +    }
> > +    return ret;
> > +}
> 
> igd_mmio_read is currently unused
> 
> 
> > +static void igd_mmio_write(struct pt_dev *p, uint32_t addr, uint32_t val,
> > +                           uint8_t size)
> > +{
> > +    uint8_t *map = p->bases[0].map;
> > +
> > +    switch (size)
> > +    {
> > +        case 1:
> > +            *(volatile uint8_t *)(map + addr) = (uint8_t)val;
> > +            break;
> > +        case 2:
> > +            *(volatile uint16_t *)(map + addr) = (uint16_t)val;
> > +            break;
> > +        case 4:
> > +            *(volatile uint32_t *)(map + addr) = (uint32_t)val;
> > +            break;
> > +        default:
> > +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> > +    }
> > +}
> > +
> > +static void igd_reset_fences(struct pt_dev *pt_dev)
> > +{
> > +    int i = 0;
> > +    uint32_t fence_addr;
> > +
> > +    switch (igd_get_chip(pt_dev))
> > +    {
> > +        case IGFX_CANTIGA:
> > +        case IGFX_IRONLAKE:
> > +        case IGFX_IBEXPEAK:
> > +            fence_addr = 0x3000;
> > +        case IGFX_COUGARPOINT:
> > +            fence_addr = 0x100000;
> > +    }
> > +
> > +    for (i = 0; i < 16; i++)
> > +    {
> > +        igd_mmio_write(pt_dev, fence_addr + (i << 4), 0, 4);
> > +        igd_mmio_write(pt_dev, fence_addr + (i << 4) + 4, 0, 4);
> > +    }
> > +}
> > +
> >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> >  {
> >      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > @@ -98,6 +215,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
> >   */
> >  void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
> >  {
> > +    /*
> > +     * Reset the fence register on the first remap
> > +     * of Bar0 for a Intel GPU
> > +     */
> > +    if (real_device->pci_dev->device_class == 0x0300 &&
> > +            real_device->pci_dev->device_id == PCI_VENDOR_ID_INTEL &&
> > +            bar == 0 && first_map && map == DPCI_ADD_MAPPING)
> > +    {
> > +        igd_reset_fences(real_device);
> > +    }
> >  }
> 
> coding style, see http://git.savannah.gnu.org/cgit/qemu.git/tree/CODING_STYLE
> 
> 
> >  /*
> > @@ -137,6 +264,12 @@ int register_vga_regions(struct pt_dev *real_device)
> >          PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
> >      }
> >  
> > +    if (vendor_id == PCI_VENDOR_ID_INTEL)
> > +    {
> > +        if (pt_pci_host_map_bar(real_device, 0) != 0)
> > +            PT_LOG("Can't map Intel Bar 0\n");
> > +    }
> 
> How fatal is this error? Maybe we need to return an error from
> register_vga_regions and propagate it upward?

It's not actually fatal. If you don't reset the fences the VESA buffer
in the guest will look corrupted but appart for that it will work fine.
So I think I will just make my code silent if the map isn't mapped.

Jean

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:28:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15: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.xensource.com>)
	id 1Rsc6j-0006mM-Kj; Wed, 01 Feb 2012 15:28:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rsc6i-0006lt-7I
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:28:24 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328110097!5006279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26034 invoked from network); 1 Feb 2012 15:28:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 15:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10418218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 15:28:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 15:28:17 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1Rsc6b-0008CV-45;
	Wed, 01 Feb 2012 15:28:17 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rsc6P-0000JJ-63;
	Wed, 01 Feb 2012 15:28:05 +0000
Date: Wed, 1 Feb 2012 15:28:05 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120201152804.GC25777@spongy.cam.xci-test.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
	<alpine.DEB.2.00.1202011447450.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202011447450.3196@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02 02:52, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Jean Guyader wrote:
> > 
> > Reset Intel GPU fences when the domain starts (first mapping
> > of Bar0).
> > 
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > ---
> >  hw/pt-graphics.c |  133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 133 insertions(+), 0 deletions(-)
> > 
> inline patches please
> 
> 
> > diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> > index 5d5e5da..7403abe 100644
> > --- a/hw/pt-graphics.c
> > +++ b/hw/pt-graphics.c
> > @@ -13,6 +13,31 @@
> >  extern int gfx_passthru;
> >  extern int igd_passthru;
> >  
> > +#define IGFX_CANTIGA            0x10
> > +#define IGFX_IRONLAKE           0x20
> > +#define IGFX_IBEXPEAK           0x30
> > +#define IGFX_COUGARPOINT        0x40
> > +
> > +struct igfx_chip
> > +{
> > +    int chip;
> > +    uint16_t device_id;
> > +};
> > +
> > +struct igfx_chip igfx_chips[] =
> > +{
> > +    {IGFX_IRONLAKE,     0x0042},
> > +    {IGFX_IRONLAKE,     0x0046},
> > +    {IGFX_CANTIGA,      0x20e4},
> > +    {IGFX_CANTIGA,      0x2a42},
> > +    {IGFX_CANTIGA,      0x2e12},
> > +    {IGFX_COUGARPOINT,  0x0152},
> > +    {IGFX_COUGARPOINT,  0x0112},
> > +    {IGFX_COUGARPOINT,  0x0116},
> > +    {IGFX_COUGARPOINT,  0x0126},
> > +    {0, 0}
> > +};
> > +
> >  static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
> >  {
> >      PT_LOG("pch_map_irq called\n");
> > @@ -37,6 +62,98 @@ void intel_pch_init(PCIBus *bus)
> >                          pch_map_irq, "intel_bridge_1f");
> >  }
> >  
> > +static int igd_get_chip(struct pt_dev *p)
> > +{
> > +    int i;
> > +    int chip = 0;
> > +    int devid = p->pci_dev->device_id;
> > +
> > +    for (i = 0; igfx_chips[i].chip; i++)
> > +        if (devid == igfx_chips[i].device_id)
> > +        {
> > +            chip = igfx_chips[i].chip;
> > +            break;
> > +        }
> > +
> > +    if (!chip)
> > +    {
> > +        if (devid & 0x2000)
> > +            chip = IGFX_CANTIGA;
> > +        else if (devid & 0x100)
> > +            chip =  IGFX_COUGARPOINT;
> > +        else
> > +            chip = IGFX_IRONLAKE;
> > +        PT_LOG("GUESS FOR CHIP 0x%04x as type %x", devid, chip);
> > +    }
> > +    return chip;
> > +}
> > +
> > +
> > +static uint32_t igd_mmio_read(struct pt_dev *p, uint32_t addr, uint8_t size)
> > +{
> > +    uint8_t *map = p->bases[0].map;
> > +    uint32_t ret;
> > +
> > +    switch (size)
> > +    {
> > +        case 1:
> > +            ret = *(volatile uint8_t *)(map + addr);
> > +            break;
> > +        case 2:
> > +            ret = *(volatile uint16_t *)(map + addr);
> > +            break;
> > +        case 4:
> > +            ret = *(volatile uint32_t *)(map + addr);
> > +            break;
> > +        default:
> > +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> > +    }
> > +    return ret;
> > +}
> 
> igd_mmio_read is currently unused
> 
> 
> > +static void igd_mmio_write(struct pt_dev *p, uint32_t addr, uint32_t val,
> > +                           uint8_t size)
> > +{
> > +    uint8_t *map = p->bases[0].map;
> > +
> > +    switch (size)
> > +    {
> > +        case 1:
> > +            *(volatile uint8_t *)(map + addr) = (uint8_t)val;
> > +            break;
> > +        case 2:
> > +            *(volatile uint16_t *)(map + addr) = (uint16_t)val;
> > +            break;
> > +        case 4:
> > +            *(volatile uint32_t *)(map + addr) = (uint32_t)val;
> > +            break;
> > +        default:
> > +            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
> > +    }
> > +}
> > +
> > +static void igd_reset_fences(struct pt_dev *pt_dev)
> > +{
> > +    int i = 0;
> > +    uint32_t fence_addr;
> > +
> > +    switch (igd_get_chip(pt_dev))
> > +    {
> > +        case IGFX_CANTIGA:
> > +        case IGFX_IRONLAKE:
> > +        case IGFX_IBEXPEAK:
> > +            fence_addr = 0x3000;
> > +        case IGFX_COUGARPOINT:
> > +            fence_addr = 0x100000;
> > +    }
> > +
> > +    for (i = 0; i < 16; i++)
> > +    {
> > +        igd_mmio_write(pt_dev, fence_addr + (i << 4), 0, 4);
> > +        igd_mmio_write(pt_dev, fence_addr + (i << 4) + 4, 0, 4);
> > +    }
> > +}
> > +
> >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> >  {
> >      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > @@ -98,6 +215,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
> >   */
> >  void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
> >  {
> > +    /*
> > +     * Reset the fence register on the first remap
> > +     * of Bar0 for a Intel GPU
> > +     */
> > +    if (real_device->pci_dev->device_class == 0x0300 &&
> > +            real_device->pci_dev->device_id == PCI_VENDOR_ID_INTEL &&
> > +            bar == 0 && first_map && map == DPCI_ADD_MAPPING)
> > +    {
> > +        igd_reset_fences(real_device);
> > +    }
> >  }
> 
> coding style, see http://git.savannah.gnu.org/cgit/qemu.git/tree/CODING_STYLE
> 
> 
> >  /*
> > @@ -137,6 +264,12 @@ int register_vga_regions(struct pt_dev *real_device)
> >          PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
> >      }
> >  
> > +    if (vendor_id == PCI_VENDOR_ID_INTEL)
> > +    {
> > +        if (pt_pci_host_map_bar(real_device, 0) != 0)
> > +            PT_LOG("Can't map Intel Bar 0\n");
> > +    }
> 
> How fatal is this error? Maybe we need to return an error from
> register_vga_regions and propagate it upward?

It's not actually fatal. If you don't reset the fences the VESA buffer
in the guest will look corrupted but appart for that it will work fine.
So I think I will just make my code silent if the map isn't mapped.

Jean

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:48:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscQB-00077P-PW; Wed, 01 Feb 2012 15:48:31 +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 1RscQ9-00077K-Pw
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:48:29 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328111266!50677346!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5MzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16314 invoked from network); 1 Feb 2012 15:47:47 -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; 1 Feb 2012 15:47:47 -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 151B3160A;
	Wed,  1 Feb 2012 17:48:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DD53720058; Wed,  1 Feb 2012 17:48:21 +0200 (EET)
Date: Wed, 1 Feb 2012 17:48:21 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120201154821.GL12984@reaktio.net>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328093634.17444.59.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel
	in	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:
> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> > As for guests supporting this fast suspend, almost all guests (pv/hvm
> > linux/windows) do support suspend_cancel. IIRC, I think some very old
> > kernels didnt have this ability.
> 
> Slight aside, does Remus work with mainline Linux domU kernels? Users
> seem to be under under that impression.
> 
> I know you had some patches at one point but I a) don't remember if they
> went in and b) don't remember if they were sufficient.
> 

http://wiki.xen.org/wiki/Remus
"Linux 2.6.39.2 and later upstream kernel.org versions are now supported as PV domU kernels"

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:48:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscQB-00077P-PW; Wed, 01 Feb 2012 15:48:31 +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 1RscQ9-00077K-Pw
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:48:29 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328111266!50677346!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5MzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16314 invoked from network); 1 Feb 2012 15:47:47 -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; 1 Feb 2012 15:47:47 -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 151B3160A;
	Wed,  1 Feb 2012 17:48:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DD53720058; Wed,  1 Feb 2012 17:48:21 +0200 (EET)
Date: Wed, 1 Feb 2012 17:48:21 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120201154821.GL12984@reaktio.net>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328093634.17444.59.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel
	in	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:
> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> > As for guests supporting this fast suspend, almost all guests (pv/hvm
> > linux/windows) do support suspend_cancel. IIRC, I think some very old
> > kernels didnt have this ability.
> 
> Slight aside, does Remus work with mainline Linux domU kernels? Users
> seem to be under under that impression.
> 
> I know you had some patches at one point but I a) don't remember if they
> went in and b) don't remember if they were sufficient.
> 

http://wiki.xen.org/wiki/Remus
"Linux 2.6.39.2 and later upstream kernel.org versions are now supported as PV domU kernels"

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:51:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscT1-0007Df-CI; Wed, 01 Feb 2012 15:51:27 +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 1RscT0-0007DW-32
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:51:26 +0000
Received: from [85.158.138.51:17673] by server-7.bemta-3.messagelabs.com id
	FB/2D-31267-D7F592F4; Wed, 01 Feb 2012 15:51:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328111484!11390400!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5MzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15457 invoked from network); 1 Feb 2012 15:51:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 15:51: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 243BB169B;
	Wed,  1 Feb 2012 17:51:24 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0883320058; Wed,  1 Feb 2012 17:51:24 +0200 (EET)
Date: Wed, 1 Feb 2012 17:51:23 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: feisky <feiskyer@gmail.com>
Message-ID: <20120201155123.GM12984@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
	<1328099398393-5447334.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328099398393-5447334.post@n5.nabble.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen guest disk online resize,
	xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 04:29:58AM -0800, feisky wrote:
> Has anyone tried is this method ok?
> 

Yep, I've used it, and verified it works.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:51:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscT1-0007Df-CI; Wed, 01 Feb 2012 15:51:27 +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 1RscT0-0007DW-32
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:51:26 +0000
Received: from [85.158.138.51:17673] by server-7.bemta-3.messagelabs.com id
	FB/2D-31267-D7F592F4; Wed, 01 Feb 2012 15:51:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328111484!11390400!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5MzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15457 invoked from network); 1 Feb 2012 15:51:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 15:51: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 243BB169B;
	Wed,  1 Feb 2012 17:51:24 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0883320058; Wed,  1 Feb 2012 17:51:24 +0200 (EET)
Date: Wed, 1 Feb 2012 17:51:23 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: feisky <feiskyer@gmail.com>
Message-ID: <20120201155123.GM12984@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
	<1328099398393-5447334.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328099398393-5447334.post@n5.nabble.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen guest disk online resize,
	xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 04:29:58AM -0800, feisky wrote:
> Has anyone tried is this method ok?
> 

Yep, I've used it, and verified it works.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:58:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscZ9-0007bV-7n; Wed, 01 Feb 2012 15:57:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RscZ7-0007bJ-Um
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:57:46 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328111856!3590784!1
X-Originating-IP: [220.181.15.53]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2071 invoked from network); 1 Feb 2012 15:57:38 -0000
Received: from m15-53.126.com (HELO m15-53.126.com) (220.181.15.53)
	by server-5.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 15:57:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=PC0VyYs38wJNK/j
	Q4SL4CSF6p8J+lSnQEaYztPN9HLM=; b=U2RpsIhKAc1PoSXDtfnC9uBwqCea2a2
	nDdDWmJNoGXLaTHC6hFl9tRRTjJEAX3pWZz4kGvaBKPk6Uz5u0l8mWJpq0Al3KmL
	C0CmE9wdyRzYpcGso9rmTmrb1tCUaTs0+dzvid84lmlzInMZyeT7H19Hy8IBRRie
	ZrpPEZ0dNqg8=
Received: from hxkhust ( [119.98.61.190] ) by ajax-webmail-wmsvr53
	(Coremail) ; Wed, 1 Feb 2012 23:57:08 +0800 (CST)
Date: Wed, 1 Feb 2012 23:57:08 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
Message-ID: <786bd8ce.da09.13539a23d29.Coremail.hxkhust@126.com>
In-Reply-To: <20120201075100.GK12984@reaktio.net>
References: <20120201075100.GK12984@reaktio.net>
	<4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [119.98.61.190]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: Bk5NiWZvb3Rlcl9odG09MTg0OTo4MQ==
X-CM-TRANSID: NcqowEC5O0HlYClPJMkHAA--.5424W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbi4wlHBU3Lhs9n3AAAsc
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] about page cache architecture of the dom0 and domUs
 in xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9076112783105557776=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9076112783105557776==
Content-Type: multipart/alternative; 
	boundary="----=_Part_147828_1747968589.1328111828264"

------=_Part_147828_1747968589.1328111828264
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGksUGFzaSBLw6Rya2vDpGluZW4sCiAKSW4gbW9zdCBjYXNlcywgSSB1c2UgImZpbGU6Ly4uLiIg
b3IgInRhcDpxY293MjouLi4iICBmb3IgbXkgVk1zLldoZW4gSSB1c2UgInRhcDphaW86Li4iIGlu
IHRoZSBjb25maWd1cmF0aW9uLHNvbWd0aGluZyB3cm9uZyB3aWxsIGhhcHBlbi5BdCB0aGUgZmly
c3QgdGltZSBJIHNwZWN1bGF0ZSB0aGF0IHRoZSBibGt0YXAvYmxrdGFwMiBtb2R1bGUgaXMgbm90
IGluc3RhbGxlZCBzdWNjZXNzZnVsbHkuVGh1cyBzb21lIHRpbWUgYWdvIEkgdHJ5IHRvIGZpZ3Vy
ZSBvdXQgdGhlIHByb2JsZW0uSG93ZXZlciBJIGZhaWxlZCBpbiB0aGUgZW5kLkNvdWxkIHlvdSB0
ZWxsIG1lIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gImZpbGU6IiBhbmQgInRhcDphaW8iIGZyb20g
dGhlIHBhZ2UgY2FjaGUgYXJjaGl0ZWN0dXJlIHNpZGU/ClRoZSBhbnN3ZXIgdG8gdGhpcyBxdWVz
dGlvbiBpcyBvZiBpbXBvcnRhbmNlIGZvciBtZS5JIG5lZWQgeW91ciBoZWxwLlRoYW5rIHlvdS4g
CgpIWEsKCgoKQXQgMjAxMi0wMi0wMSAxNTo1MTowMCwiUGFzaSBLw6Rya2vDpGluZW4iIDxwYXNp
a0Bpa2kuZmk+IHdyb3RlOgo+T24gV2VkLCBGZWIgMDEsIDIwMTIgYXQgMTE6NTA6MDZBTSArMDgw
MCwgaHhraHVzdCB3cm90ZToKPj4gICAgSGksCj4+ICAgIEkgZW5jb3VudGVyIGEgcHJvYmxlbSB0
aGF0IGhhcyBwdXp6bGVkIG1lIGZvciBhIGxvbmcgdGltZS5PbiBhIFhlbgo+PiAgICB2aXJ0dWFs
aXphdGlvbiBwbGF0Zm9ybSwgc29tZSBWTXMgLHdob3NlIHZpcnR1YWwgZGlza3MgYXJlIGltYWdl
IGZpbGVzCj4+ICAgICxhcmUgcnVubmluZyBpbiBEb21Vcy5VbmRlciB0aGlzIHNpdHVhdGlvbiAs
ZG9lcyB0aGUgRG9tMCBjYWNoZSB0aGUgcGFnZXMKPj4gICAgZnJvbSB0aGUgVk1zP0RvZXMgdGhl
IGZpbGVzeXN0ZW0gaW4gRG9tMCBzZWUgdGhlIFZNcyBhcyBnZW5lcmFsIHByb2Nlc3Nlcz8KPj4g
Cj4KPkl0IGRlcGVuZHMgd2hpY2ggZGlzayBiYWNrZW5kIGRyaXZlciB5b3UncmUgdXNpbmcgZm9y
IHRoZSBkb21VIGRpc2tzLi4KPihmaWxlOiBvciB0YXA6YWlvOikKPgo+LS0gUGFzaQo+Cg==
------=_Part_147828_1747968589.1328111828264
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxESVY+SGksUGFzaSZuYnNwO0vDpHJra8OkaW5lbiw8L0RJVj4K
PERJVj4mbmJzcDs8L0RJVj4KPERJVj5JbiBtb3N0IGNhc2VzLCBJIHVzZSAiZmlsZTovLi4uIiBv
ciZuYnNwOyJ0YXA6cWNvdzI6Li4uIiZuYnNwOyBmb3IgbXkgVk1zLldoZW4gSSB1c2UgInRhcDph
aW86Li4iIGluIHRoZSBjb25maWd1cmF0aW9uLHNvbWd0aGluZyB3cm9uZyB3aWxsIGhhcHBlbi5B
dCB0aGUgZmlyc3QgdGltZSBJIHNwZWN1bGF0ZSB0aGF0IHRoZSBibGt0YXAvYmxrdGFwMiBtb2R1
bGUgaXMgbm90IGluc3RhbGxlZCBzdWNjZXNzZnVsbHkuVGh1cyBzb21lIHRpbWUgYWdvIEkgdHJ5
IHRvIGZpZ3VyZSBvdXQgdGhlIHByb2JsZW0uSG93ZXZlciBJJm5ic3A7ZmFpbGVkIGluIHRoZSBl
bmQuQ291bGQgeW91IHRlbGwgbWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAiZmlsZToiIGFuZCAi
dGFwOmFpbyIgZnJvbSB0aGUgcGFnZSBjYWNoZSBhcmNoaXRlY3R1cmUgc2lkZT88L0RJVj4KPERJ
Vj5UaGUgYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24gaXMmbmJzcDtvZiBpbXBvcnRhbmNlIGZvciBt
ZS5JIG5lZWQgeW91ciBoZWxwLlRoYW5rIHlvdS4mbmJzcDs8QlI+PEJSPkhYSzwvRElWPgo8RElW
PjwvRElWPgo8RElWIGlkPSJkaXZOZXRlYXNlTWFpbENhcmQiPjwvRElWPgo8RElWPjxCUj48L0RJ
Vj48UFJFPjxCUj5BdCZuYnNwOzIwMTItMDItMDEmbmJzcDsxNTo1MTowMCwiUGFzaSZuYnNwO0vD
pHJra8OkaW5lbiImbmJzcDsmbHQ7cGFzaWtAaWtpLmZpJmd0OyZuYnNwO3dyb3RlOgomZ3Q7T24m
bmJzcDtXZWQsJm5ic3A7RmViJm5ic3A7MDEsJm5ic3A7MjAxMiZuYnNwO2F0Jm5ic3A7MTE6NTA6
MDZBTSZuYnNwOyswODAwLCZuYnNwO2h4a2h1c3QmbmJzcDt3cm90ZToKJmd0OyZndDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDtIaSwKJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJJm5i
c3A7ZW5jb3VudGVyJm5ic3A7YSZuYnNwO3Byb2JsZW0mbmJzcDt0aGF0Jm5ic3A7aGFzJm5ic3A7
cHV6emxlZCZuYnNwO21lJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2xvbmcmbmJzcDt0aW1lLk9uJm5i
c3A7YSZuYnNwO1hlbgomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3ZpcnR1YWxpemF0
aW9uJm5ic3A7cGxhdGZvcm0sJm5ic3A7c29tZSZuYnNwO1ZNcyZuYnNwOyx3aG9zZSZuYnNwO3Zp
cnR1YWwmbmJzcDtkaXNrcyZuYnNwO2FyZSZuYnNwO2ltYWdlJm5ic3A7ZmlsZXMKJmd0OyZndDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDssYXJlJm5ic3A7cnVubmluZyZuYnNwO2luJm5ic3A7RG9t
VXMuVW5kZXImbmJzcDt0aGlzJm5ic3A7c2l0dWF0aW9uJm5ic3A7LGRvZXMmbmJzcDt0aGUmbmJz
cDtEb20wJm5ic3A7Y2FjaGUmbmJzcDt0aGUmbmJzcDtwYWdlcwomZ3Q7Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtWTXM/RG9lcyZuYnNwO3RoZSZuYnNwO2Zp
bGVzeXN0ZW0mbmJzcDtpbiZuYnNwO0RvbTAmbmJzcDtzZWUmbmJzcDt0aGUmbmJzcDtWTXMmbmJz
cDthcyZuYnNwO2dlbmVyYWwmbmJzcDtwcm9jZXNzZXM/CiZndDsmZ3Q7Jm5ic3A7CiZndDsKJmd0
O0l0Jm5ic3A7ZGVwZW5kcyZuYnNwO3doaWNoJm5ic3A7ZGlzayZuYnNwO2JhY2tlbmQmbmJzcDtk
cml2ZXImbmJzcDt5b3UncmUmbmJzcDt1c2luZyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2RvbVUm
bmJzcDtkaXNrcy4uCiZndDsoZmlsZTombmJzcDtvciZuYnNwO3RhcDphaW86KQomZ3Q7CiZndDst
LSZuYnNwO1Bhc2kKJmd0Owo8L1BSRT48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNl
Zm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4=
------=_Part_147828_1747968589.1328111828264--



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

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

--===============9076112783105557776==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:58:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscZ9-0007bV-7n; Wed, 01 Feb 2012 15:57:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RscZ7-0007bJ-Um
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:57:46 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328111856!3590784!1
X-Originating-IP: [220.181.15.53]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2071 invoked from network); 1 Feb 2012 15:57:38 -0000
Received: from m15-53.126.com (HELO m15-53.126.com) (220.181.15.53)
	by server-5.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 15:57:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=PC0VyYs38wJNK/j
	Q4SL4CSF6p8J+lSnQEaYztPN9HLM=; b=U2RpsIhKAc1PoSXDtfnC9uBwqCea2a2
	nDdDWmJNoGXLaTHC6hFl9tRRTjJEAX3pWZz4kGvaBKPk6Uz5u0l8mWJpq0Al3KmL
	C0CmE9wdyRzYpcGso9rmTmrb1tCUaTs0+dzvid84lmlzInMZyeT7H19Hy8IBRRie
	ZrpPEZ0dNqg8=
Received: from hxkhust ( [119.98.61.190] ) by ajax-webmail-wmsvr53
	(Coremail) ; Wed, 1 Feb 2012 23:57:08 +0800 (CST)
Date: Wed, 1 Feb 2012 23:57:08 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
Message-ID: <786bd8ce.da09.13539a23d29.Coremail.hxkhust@126.com>
In-Reply-To: <20120201075100.GK12984@reaktio.net>
References: <20120201075100.GK12984@reaktio.net>
	<4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [119.98.61.190]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: Bk5NiWZvb3Rlcl9odG09MTg0OTo4MQ==
X-CM-TRANSID: NcqowEC5O0HlYClPJMkHAA--.5424W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbi4wlHBU3Lhs9n3AAAsc
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] about page cache architecture of the dom0 and domUs
 in xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9076112783105557776=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9076112783105557776==
Content-Type: multipart/alternative; 
	boundary="----=_Part_147828_1747968589.1328111828264"

------=_Part_147828_1747968589.1328111828264
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGksUGFzaSBLw6Rya2vDpGluZW4sCiAKSW4gbW9zdCBjYXNlcywgSSB1c2UgImZpbGU6Ly4uLiIg
b3IgInRhcDpxY293MjouLi4iICBmb3IgbXkgVk1zLldoZW4gSSB1c2UgInRhcDphaW86Li4iIGlu
IHRoZSBjb25maWd1cmF0aW9uLHNvbWd0aGluZyB3cm9uZyB3aWxsIGhhcHBlbi5BdCB0aGUgZmly
c3QgdGltZSBJIHNwZWN1bGF0ZSB0aGF0IHRoZSBibGt0YXAvYmxrdGFwMiBtb2R1bGUgaXMgbm90
IGluc3RhbGxlZCBzdWNjZXNzZnVsbHkuVGh1cyBzb21lIHRpbWUgYWdvIEkgdHJ5IHRvIGZpZ3Vy
ZSBvdXQgdGhlIHByb2JsZW0uSG93ZXZlciBJIGZhaWxlZCBpbiB0aGUgZW5kLkNvdWxkIHlvdSB0
ZWxsIG1lIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gImZpbGU6IiBhbmQgInRhcDphaW8iIGZyb20g
dGhlIHBhZ2UgY2FjaGUgYXJjaGl0ZWN0dXJlIHNpZGU/ClRoZSBhbnN3ZXIgdG8gdGhpcyBxdWVz
dGlvbiBpcyBvZiBpbXBvcnRhbmNlIGZvciBtZS5JIG5lZWQgeW91ciBoZWxwLlRoYW5rIHlvdS4g
CgpIWEsKCgoKQXQgMjAxMi0wMi0wMSAxNTo1MTowMCwiUGFzaSBLw6Rya2vDpGluZW4iIDxwYXNp
a0Bpa2kuZmk+IHdyb3RlOgo+T24gV2VkLCBGZWIgMDEsIDIwMTIgYXQgMTE6NTA6MDZBTSArMDgw
MCwgaHhraHVzdCB3cm90ZToKPj4gICAgSGksCj4+ICAgIEkgZW5jb3VudGVyIGEgcHJvYmxlbSB0
aGF0IGhhcyBwdXp6bGVkIG1lIGZvciBhIGxvbmcgdGltZS5PbiBhIFhlbgo+PiAgICB2aXJ0dWFs
aXphdGlvbiBwbGF0Zm9ybSwgc29tZSBWTXMgLHdob3NlIHZpcnR1YWwgZGlza3MgYXJlIGltYWdl
IGZpbGVzCj4+ICAgICxhcmUgcnVubmluZyBpbiBEb21Vcy5VbmRlciB0aGlzIHNpdHVhdGlvbiAs
ZG9lcyB0aGUgRG9tMCBjYWNoZSB0aGUgcGFnZXMKPj4gICAgZnJvbSB0aGUgVk1zP0RvZXMgdGhl
IGZpbGVzeXN0ZW0gaW4gRG9tMCBzZWUgdGhlIFZNcyBhcyBnZW5lcmFsIHByb2Nlc3Nlcz8KPj4g
Cj4KPkl0IGRlcGVuZHMgd2hpY2ggZGlzayBiYWNrZW5kIGRyaXZlciB5b3UncmUgdXNpbmcgZm9y
IHRoZSBkb21VIGRpc2tzLi4KPihmaWxlOiBvciB0YXA6YWlvOikKPgo+LS0gUGFzaQo+Cg==
------=_Part_147828_1747968589.1328111828264
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxESVY+SGksUGFzaSZuYnNwO0vDpHJra8OkaW5lbiw8L0RJVj4K
PERJVj4mbmJzcDs8L0RJVj4KPERJVj5JbiBtb3N0IGNhc2VzLCBJIHVzZSAiZmlsZTovLi4uIiBv
ciZuYnNwOyJ0YXA6cWNvdzI6Li4uIiZuYnNwOyBmb3IgbXkgVk1zLldoZW4gSSB1c2UgInRhcDph
aW86Li4iIGluIHRoZSBjb25maWd1cmF0aW9uLHNvbWd0aGluZyB3cm9uZyB3aWxsIGhhcHBlbi5B
dCB0aGUgZmlyc3QgdGltZSBJIHNwZWN1bGF0ZSB0aGF0IHRoZSBibGt0YXAvYmxrdGFwMiBtb2R1
bGUgaXMgbm90IGluc3RhbGxlZCBzdWNjZXNzZnVsbHkuVGh1cyBzb21lIHRpbWUgYWdvIEkgdHJ5
IHRvIGZpZ3VyZSBvdXQgdGhlIHByb2JsZW0uSG93ZXZlciBJJm5ic3A7ZmFpbGVkIGluIHRoZSBl
bmQuQ291bGQgeW91IHRlbGwgbWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAiZmlsZToiIGFuZCAi
dGFwOmFpbyIgZnJvbSB0aGUgcGFnZSBjYWNoZSBhcmNoaXRlY3R1cmUgc2lkZT88L0RJVj4KPERJ
Vj5UaGUgYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24gaXMmbmJzcDtvZiBpbXBvcnRhbmNlIGZvciBt
ZS5JIG5lZWQgeW91ciBoZWxwLlRoYW5rIHlvdS4mbmJzcDs8QlI+PEJSPkhYSzwvRElWPgo8RElW
PjwvRElWPgo8RElWIGlkPSJkaXZOZXRlYXNlTWFpbENhcmQiPjwvRElWPgo8RElWPjxCUj48L0RJ
Vj48UFJFPjxCUj5BdCZuYnNwOzIwMTItMDItMDEmbmJzcDsxNTo1MTowMCwiUGFzaSZuYnNwO0vD
pHJra8OkaW5lbiImbmJzcDsmbHQ7cGFzaWtAaWtpLmZpJmd0OyZuYnNwO3dyb3RlOgomZ3Q7T24m
bmJzcDtXZWQsJm5ic3A7RmViJm5ic3A7MDEsJm5ic3A7MjAxMiZuYnNwO2F0Jm5ic3A7MTE6NTA6
MDZBTSZuYnNwOyswODAwLCZuYnNwO2h4a2h1c3QmbmJzcDt3cm90ZToKJmd0OyZndDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDtIaSwKJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJJm5i
c3A7ZW5jb3VudGVyJm5ic3A7YSZuYnNwO3Byb2JsZW0mbmJzcDt0aGF0Jm5ic3A7aGFzJm5ic3A7
cHV6emxlZCZuYnNwO21lJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2xvbmcmbmJzcDt0aW1lLk9uJm5i
c3A7YSZuYnNwO1hlbgomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3ZpcnR1YWxpemF0
aW9uJm5ic3A7cGxhdGZvcm0sJm5ic3A7c29tZSZuYnNwO1ZNcyZuYnNwOyx3aG9zZSZuYnNwO3Zp
cnR1YWwmbmJzcDtkaXNrcyZuYnNwO2FyZSZuYnNwO2ltYWdlJm5ic3A7ZmlsZXMKJmd0OyZndDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDssYXJlJm5ic3A7cnVubmluZyZuYnNwO2luJm5ic3A7RG9t
VXMuVW5kZXImbmJzcDt0aGlzJm5ic3A7c2l0dWF0aW9uJm5ic3A7LGRvZXMmbmJzcDt0aGUmbmJz
cDtEb20wJm5ic3A7Y2FjaGUmbmJzcDt0aGUmbmJzcDtwYWdlcwomZ3Q7Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtWTXM/RG9lcyZuYnNwO3RoZSZuYnNwO2Zp
bGVzeXN0ZW0mbmJzcDtpbiZuYnNwO0RvbTAmbmJzcDtzZWUmbmJzcDt0aGUmbmJzcDtWTXMmbmJz
cDthcyZuYnNwO2dlbmVyYWwmbmJzcDtwcm9jZXNzZXM/CiZndDsmZ3Q7Jm5ic3A7CiZndDsKJmd0
O0l0Jm5ic3A7ZGVwZW5kcyZuYnNwO3doaWNoJm5ic3A7ZGlzayZuYnNwO2JhY2tlbmQmbmJzcDtk
cml2ZXImbmJzcDt5b3UncmUmbmJzcDt1c2luZyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2RvbVUm
bmJzcDtkaXNrcy4uCiZndDsoZmlsZTombmJzcDtvciZuYnNwO3RhcDphaW86KQomZ3Q7CiZndDst
LSZuYnNwO1Bhc2kKJmd0Owo8L1BSRT48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNl
Zm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4=
------=_Part_147828_1747968589.1328111828264--



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

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

--===============9076112783105557776==--



From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15: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.xensource.com>)
	id 1RscZW-0007dz-07; Wed, 01 Feb 2012 15:58:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RscZU-0007dH-1O
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:58:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328111881!12135447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5329 invoked from network); 1 Feb 2012 15:58:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 15:58:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 01 Feb 2012 15:58:01 +0000
Message-Id: <4F296F180200007800070594@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 01 Feb 2012 15:58:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4F213167.3010400@amd.com>
In-Reply-To: <4F213167.3010400@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
 non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 11:56, Wei Wang <wei.wang2@amd.com> wrote:
>--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 24 16:46:17 2012 +0000
>+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Jan 26 11:50:02 2012 +0100
>@@ -805,6 +805,9 @@ int guest_iommu_set_base(struct domain *
>     p2m_type_t t;
>     struct guest_iommu *iommu = domain_iommu(d);
> 
>+    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>+        return 0;

Is it really appropriate/correct to return 0 here, while ...

>+
>     if ( !iommu )
>         return -EACCES;
> 

... here it is -EACCES? Further, are the extra checks needed at all
(i.e. wouldn't domain_iommu() return NULL in all of these cases
anyway due to the same checks being added to guest_iommu_init())?
If so, the checks you add to guest_iommu_destroy() are pointless
too.

Jan


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15: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.xensource.com>)
	id 1RscZW-0007dz-07; Wed, 01 Feb 2012 15:58:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RscZU-0007dH-1O
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:58:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328111881!12135447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5329 invoked from network); 1 Feb 2012 15:58:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 15:58:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 01 Feb 2012 15:58:01 +0000
Message-Id: <4F296F180200007800070594@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 01 Feb 2012 15:58:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4F213167.3010400@amd.com>
In-Reply-To: <4F213167.3010400@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
 non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 11:56, Wei Wang <wei.wang2@amd.com> wrote:
>--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 24 16:46:17 2012 +0000
>+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Jan 26 11:50:02 2012 +0100
>@@ -805,6 +805,9 @@ int guest_iommu_set_base(struct domain *
>     p2m_type_t t;
>     struct guest_iommu *iommu = domain_iommu(d);
> 
>+    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>+        return 0;

Is it really appropriate/correct to return 0 here, while ...

>+
>     if ( !iommu )
>         return -EACCES;
> 

... here it is -EACCES? Further, are the extra checks needed at all
(i.e. wouldn't domain_iommu() return NULL in all of these cases
anyway due to the same checks being added to guest_iommu_init())?
If so, the checks you add to guest_iommu_destroy() are pointless
too.

Jan


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscZw-0007hg-Eh; Wed, 01 Feb 2012 15:58:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RscZu-0007gv-Ma
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:58:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328111907!13243739!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17933 invoked from network); 1 Feb 2012 15:58:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 15:58:28 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 0D136714085;
	Wed,  1 Feb 2012 07:58:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QKxPLQOEXR/TJmsRMnhRLc+cKUDf+1FiTtf+rp4l1Wuy
	O8ORXBbItwBTASMvy7DSmSNt5eYQW8jARccAedVsNvRK4vqINBa2Ua9IWYYas9SM
	rGbQd+F2i0WmbO56KvpJLQj1wCbnpSQrsW1EsDra8Y9QRMrn25hsRNUOSpBD5sU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=VT/YfaG8Q/aUDkLovE934ep6xf0=; b=STXSjO42
	gW18wTJ8nYyohSYnTJlFaG2ODgGAbXDu8t0pJYS7UZNxO4TSYUffNjoZCb4+tbKJ
	nGOMALFY63YPagVRB3YKBrAr3Ou14EJxpmJnSgymiQWT4CfJkuanc4GDfUeyk2/5
	GFbvmazy3Lof5DDRysJH85Gu3wO40Ot5KEA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 7E804714070; 
	Wed,  1 Feb 2012 07:58:26 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 1 Feb 2012 07:58:26 -0800
Message-ID: <8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328089685.17444.15.camel@zakaz.uk.xensource.com>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
	<1328089685.17444.15.camel@zakaz.uk.xensource.com>
Date: Wed, 1 Feb 2012 07:58:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
>> Config.mk            |   1 +
>>  tools/Makefile       |   1 +
>>  tools/tests/Makefile |  20 ++++++++++++++++++++
>>  3 files changed, 22 insertions(+), 0 deletions(-)
>>
>>
>> Build tests as part of the tools build.
>>
>> It is enabled with CONFIG_TESTS in Config.mk
>>
>> Currently disabled build of tests/regressions and tests/xen-access (in
>> 32 bit
>> mode) as they fail.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Ack on the idea but the actual implementation fails for me:
>
> make[1]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools'
> make -C tests install
> make[2]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> make[3]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> make -C mce-test install
> make[4]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
> make[4]: *** No rule to make target `install'.  Stop.
>
> Grep seems to suggest that most of the tools/tests dirs are missing an
> install target, mce-test just happens to be first.
>
> I'm not sure if it makes sense to install any of these test things?
> Depending on the answer we could either hobble the install target in
> tools/tests/Makefile or add an install target to tools/tests/*/Makefile
> which is a nop or an actual install target as appropriate.

Vote is to hobble install target. Refresh of patch pasted below (also
added distclean).
Thanks!
Andres

# HG changeset patch
# Parent efc0802acb87aec9a4d578e741e209bef8c6fe52
Tools: build tests

Build tests as part of the tools build.

It is enabled with CONFIG_TESTS in Config.mk

Currently disabled build of tests/regressions and tests/xen-access (in 32
bit mode) as they fail.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r efc0802acb87 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -238,6 +238,7 @@ OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
 CONFIG_SYSTEM_LIBAIO ?= y
+CONFIG_TESTS       ?= y

 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
diff -r efc0802acb87 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -45,6 +45,7 @@ SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
 SUBDIRS-$(CONFIG_X86) += debugger/kdd
+SUBDIRS-$(CONFIG_TESTS) += tests

 # These don't cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
diff -r efc0802acb87 tools/tests/Makefile
--- /dev/null
+++ b/tools/tests/Makefile
@@ -0,0 +1,21 @@
+XEN_ROOT = $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS  += $(CFLAGS_libxenctrl)
+LDLIBS += $(LDLIBS_libxenctrl)
+
+SUBDIRS-y :=
+SUBDIRS-y += mce-test
+SUBDIRS-y += mem-sharing
+ifeq ($(XEN_TARGET_ARCH),__fixme__)
+SUBDIRS-y += regression
+endif
+SUBDIRS-y += x86_emulator
+ifneq ($(XEN_TARGET_ARCH),x86_32)
+SUBDIRS-y += xen-access
+endif
+
+.PHONY: all clean install distclean
+all clean distclean: %: subdirs-%
+
+install:



>
> Ian.
>
>
>



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 15:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 15:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscZw-0007hg-Eh; Wed, 01 Feb 2012 15:58:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RscZu-0007gv-Ma
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 15:58:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328111907!13243739!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17933 invoked from network); 1 Feb 2012 15:58:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 15:58:28 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 0D136714085;
	Wed,  1 Feb 2012 07:58:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QKxPLQOEXR/TJmsRMnhRLc+cKUDf+1FiTtf+rp4l1Wuy
	O8ORXBbItwBTASMvy7DSmSNt5eYQW8jARccAedVsNvRK4vqINBa2Ua9IWYYas9SM
	rGbQd+F2i0WmbO56KvpJLQj1wCbnpSQrsW1EsDra8Y9QRMrn25hsRNUOSpBD5sU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=VT/YfaG8Q/aUDkLovE934ep6xf0=; b=STXSjO42
	gW18wTJ8nYyohSYnTJlFaG2ODgGAbXDu8t0pJYS7UZNxO4TSYUffNjoZCb4+tbKJ
	nGOMALFY63YPagVRB3YKBrAr3Ou14EJxpmJnSgymiQWT4CfJkuanc4GDfUeyk2/5
	GFbvmazy3Lof5DDRysJH85Gu3wO40Ot5KEA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 7E804714070; 
	Wed,  1 Feb 2012 07:58:26 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 1 Feb 2012 07:58:26 -0800
Message-ID: <8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328089685.17444.15.camel@zakaz.uk.xensource.com>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
	<1328089685.17444.15.camel@zakaz.uk.xensource.com>
Date: Wed, 1 Feb 2012 07:58:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
>> Config.mk            |   1 +
>>  tools/Makefile       |   1 +
>>  tools/tests/Makefile |  20 ++++++++++++++++++++
>>  3 files changed, 22 insertions(+), 0 deletions(-)
>>
>>
>> Build tests as part of the tools build.
>>
>> It is enabled with CONFIG_TESTS in Config.mk
>>
>> Currently disabled build of tests/regressions and tests/xen-access (in
>> 32 bit
>> mode) as they fail.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Ack on the idea but the actual implementation fails for me:
>
> make[1]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools'
> make -C tests install
> make[2]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> make[3]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> make -C mce-test install
> make[4]: Entering directory
> `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
> make[4]: *** No rule to make target `install'.  Stop.
>
> Grep seems to suggest that most of the tools/tests dirs are missing an
> install target, mce-test just happens to be first.
>
> I'm not sure if it makes sense to install any of these test things?
> Depending on the answer we could either hobble the install target in
> tools/tests/Makefile or add an install target to tools/tests/*/Makefile
> which is a nop or an actual install target as appropriate.

Vote is to hobble install target. Refresh of patch pasted below (also
added distclean).
Thanks!
Andres

# HG changeset patch
# Parent efc0802acb87aec9a4d578e741e209bef8c6fe52
Tools: build tests

Build tests as part of the tools build.

It is enabled with CONFIG_TESTS in Config.mk

Currently disabled build of tests/regressions and tests/xen-access (in 32
bit mode) as they fail.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r efc0802acb87 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -238,6 +238,7 @@ OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
 CONFIG_SYSTEM_LIBAIO ?= y
+CONFIG_TESTS       ?= y

 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
diff -r efc0802acb87 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -45,6 +45,7 @@ SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
 SUBDIRS-$(CONFIG_X86) += debugger/kdd
+SUBDIRS-$(CONFIG_TESTS) += tests

 # These don't cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
diff -r efc0802acb87 tools/tests/Makefile
--- /dev/null
+++ b/tools/tests/Makefile
@@ -0,0 +1,21 @@
+XEN_ROOT = $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS  += $(CFLAGS_libxenctrl)
+LDLIBS += $(LDLIBS_libxenctrl)
+
+SUBDIRS-y :=
+SUBDIRS-y += mce-test
+SUBDIRS-y += mem-sharing
+ifeq ($(XEN_TARGET_ARCH),__fixme__)
+SUBDIRS-y += regression
+endif
+SUBDIRS-y += x86_emulator
+ifneq ($(XEN_TARGET_ARCH),x86_32)
+SUBDIRS-y += xen-access
+endif
+
+.PHONY: all clean install distclean
+all clean distclean: %: subdirs-%
+
+install:



>
> Ian.
>
>
>



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:03:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16: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.xensource.com>)
	id 1Rsce4-00005g-4a; Wed, 01 Feb 2012 16:02:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rsce2-0008WN-79
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:02:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328112164!13311568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7786 invoked from network); 1 Feb 2012 16:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10419177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16:02:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	16:02:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 1 Feb 2012 16:02:43 +0000
In-Reply-To: <20120201154821.GL12984@reaktio.net>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328112163.17444.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTAxIGF0IDE1OjQ4ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBXZWQsIEZlYiAwMSwgMjAxMiBhdCAxMDo1Mzo1NEFNICswMDAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBUdWUsIDIwMTItMDEtMzEgYXQgMTc6NTIgKzAwMDAsIFNocmlyYW0g
UmFqYWdvcGFsYW4gd3JvdGU6Cj4gPiA+IEFzIGZvciBndWVzdHMgc3VwcG9ydGluZyB0aGlzIGZh
c3Qgc3VzcGVuZCwgYWxtb3N0IGFsbCBndWVzdHMgKHB2L2h2bQo+ID4gPiBsaW51eC93aW5kb3dz
KSBkbyBzdXBwb3J0IHN1c3BlbmRfY2FuY2VsLiBJSVJDLCBJIHRoaW5rIHNvbWUgdmVyeSBvbGQK
PiA+ID4ga2VybmVscyBkaWRudCBoYXZlIHRoaXMgYWJpbGl0eS4KPiA+IAo+ID4gU2xpZ2h0IGFz
aWRlLCBkb2VzIFJlbXVzIHdvcmsgd2l0aCBtYWlubGluZSBMaW51eCBkb21VIGtlcm5lbHM/IFVz
ZXJzCj4gPiBzZWVtIHRvIGJlIHVuZGVyIHVuZGVyIHRoYXQgaW1wcmVzc2lvbi4KPiA+IAo+ID4g
SSBrbm93IHlvdSBoYWQgc29tZSBwYXRjaGVzIGF0IG9uZSBwb2ludCBidXQgSSBhKSBkb24ndCBy
ZW1lbWJlciBpZiB0aGV5Cj4gPiB3ZW50IGluIGFuZCBiKSBkb24ndCByZW1lbWJlciBpZiB0aGV5
IHdlcmUgc3VmZmljaWVudC4KPiA+IAo+IAo+IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9SZW11
cwo+ICJMaW51eCAyLjYuMzkuMiBhbmQgbGF0ZXIgdXBzdHJlYW0ga2VybmVsLm9yZyB2ZXJzaW9u
cyBhcmUgbm93IHN1cHBvcnRlZCBhcyBQViBkb21VIGtlcm5lbHMiCgpHcmVhdCwgc29tZW9uZSB3
YXMgc3VnZ2VzdGluZyBvbiBsaXN0IHRoYXQgdGhpcyB3YXNuJ3QgdGhlIGNhc2UuIE11c3QKZGln
IG91dCB0aGF0IG1haWwgYW5kIHJlc3BvbmQuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:03:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16: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.xensource.com>)
	id 1Rsce4-00005g-4a; Wed, 01 Feb 2012 16:02:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rsce2-0008WN-79
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:02:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328112164!13311568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7786 invoked from network); 1 Feb 2012 16:02:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10419177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16:02:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	16:02:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 1 Feb 2012 16:02:43 +0000
In-Reply-To: <20120201154821.GL12984@reaktio.net>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328112163.17444.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTAxIGF0IDE1OjQ4ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBXZWQsIEZlYiAwMSwgMjAxMiBhdCAxMDo1Mzo1NEFNICswMDAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBUdWUsIDIwMTItMDEtMzEgYXQgMTc6NTIgKzAwMDAsIFNocmlyYW0g
UmFqYWdvcGFsYW4gd3JvdGU6Cj4gPiA+IEFzIGZvciBndWVzdHMgc3VwcG9ydGluZyB0aGlzIGZh
c3Qgc3VzcGVuZCwgYWxtb3N0IGFsbCBndWVzdHMgKHB2L2h2bQo+ID4gPiBsaW51eC93aW5kb3dz
KSBkbyBzdXBwb3J0IHN1c3BlbmRfY2FuY2VsLiBJSVJDLCBJIHRoaW5rIHNvbWUgdmVyeSBvbGQK
PiA+ID4ga2VybmVscyBkaWRudCBoYXZlIHRoaXMgYWJpbGl0eS4KPiA+IAo+ID4gU2xpZ2h0IGFz
aWRlLCBkb2VzIFJlbXVzIHdvcmsgd2l0aCBtYWlubGluZSBMaW51eCBkb21VIGtlcm5lbHM/IFVz
ZXJzCj4gPiBzZWVtIHRvIGJlIHVuZGVyIHVuZGVyIHRoYXQgaW1wcmVzc2lvbi4KPiA+IAo+ID4g
SSBrbm93IHlvdSBoYWQgc29tZSBwYXRjaGVzIGF0IG9uZSBwb2ludCBidXQgSSBhKSBkb24ndCBy
ZW1lbWJlciBpZiB0aGV5Cj4gPiB3ZW50IGluIGFuZCBiKSBkb24ndCByZW1lbWJlciBpZiB0aGV5
IHdlcmUgc3VmZmljaWVudC4KPiA+IAo+IAo+IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9SZW11
cwo+ICJMaW51eCAyLjYuMzkuMiBhbmQgbGF0ZXIgdXBzdHJlYW0ga2VybmVsLm9yZyB2ZXJzaW9u
cyBhcmUgbm93IHN1cHBvcnRlZCBhcyBQViBkb21VIGtlcm5lbHMiCgpHcmVhdCwgc29tZW9uZSB3
YXMgc3VnZ2VzdGluZyBvbiBsaXN0IHRoYXQgdGhpcyB3YXNuJ3QgdGhlIGNhc2UuIE11c3QKZGln
IG91dCB0aGF0IG1haWwgYW5kIHJlc3BvbmQuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:14:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscpG-0000Pt-IW; Wed, 01 Feb 2012 16:14:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RscpF-0000Po-M8
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:14:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328112859!9185646!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12067 invoked from network); 1 Feb 2012 16:14:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:14:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10419548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16:14:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	16:14:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Wed, 1 Feb 2012 16:14:19 +0000
In-Reply-To: <8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
	<1328089685.17444.15.camel@zakaz.uk.xensource.com>
	<8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328112859.17444.94.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 15:58 +0000, Andres Lagar-Cavilla wrote:
> > On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
> >> Config.mk            |   1 +
> >>  tools/Makefile       |   1 +
> >>  tools/tests/Makefile |  20 ++++++++++++++++++++
> >>  3 files changed, 22 insertions(+), 0 deletions(-)
> >>
> >>
> >> Build tests as part of the tools build.
> >>
> >> It is enabled with CONFIG_TESTS in Config.mk
> >>
> >> Currently disabled build of tests/regressions and tests/xen-access (in
> >> 32 bit
> >> mode) as they fail.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > Ack on the idea but the actual implementation fails for me:
> >
> > make[1]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools'
> > make -C tests install
> > make[2]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> > make[3]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> > make -C mce-test install
> > make[4]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
> > make[4]: *** No rule to make target `install'.  Stop.
> >
> > Grep seems to suggest that most of the tools/tests dirs are missing an
> > install target, mce-test just happens to be first.
> >
> > I'm not sure if it makes sense to install any of these test things?
> > Depending on the answer we could either hobble the install target in
> > tools/tests/Makefile or add an install target to tools/tests/*/Makefile
> > which is a nop or an actual install target as appropriate.
> 
> Vote is to hobble install target. Refresh of patch pasted below (also
> added distclean).
> Thanks!
> Andres
> 
> # HG changeset patch
> # Parent efc0802acb87aec9a4d578e741e209bef8c6fe52
> Tools: build tests
> 
> Build tests as part of the tools build.
> 
> It is enabled with CONFIG_TESTS in Config.mk
> 
> Currently disabled build of tests/regressions and tests/xen-access (in 32
> bit mode) as they fail.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

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

> 
> diff -r efc0802acb87 Config.mk
> --- a/Config.mk
> +++ b/Config.mk
> @@ -238,6 +238,7 @@ OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
>  CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_TESTS       ?= y
> 
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> diff -r efc0802acb87 tools/Makefile
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -45,6 +45,7 @@ SUBDIRS-y += remus
>  SUBDIRS-$(CONFIG_X86) += xenpaging
>  SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
>  SUBDIRS-$(CONFIG_X86) += debugger/kdd
> +SUBDIRS-$(CONFIG_TESTS) += tests
> 
>  # These don't cross-compile
>  ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
> diff -r efc0802acb87 tools/tests/Makefile
> --- /dev/null
> +++ b/tools/tests/Makefile
> @@ -0,0 +1,21 @@
> +XEN_ROOT = $(CURDIR)/../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +CFLAGS  += $(CFLAGS_libxenctrl)
> +LDLIBS += $(LDLIBS_libxenctrl)
> +
> +SUBDIRS-y :=
> +SUBDIRS-y += mce-test
> +SUBDIRS-y += mem-sharing
> +ifeq ($(XEN_TARGET_ARCH),__fixme__)
> +SUBDIRS-y += regression
> +endif
> +SUBDIRS-y += x86_emulator
> +ifneq ($(XEN_TARGET_ARCH),x86_32)
> +SUBDIRS-y += xen-access
> +endif
> +
> +.PHONY: all clean install distclean
> +all clean distclean: %: subdirs-%
> +
> +install:
> 
> 
> 
> >
> > Ian.
> >
> >
> >
> 
> 



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:14:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RscpG-0000Pt-IW; Wed, 01 Feb 2012 16:14:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RscpF-0000Po-M8
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:14:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328112859!9185646!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12067 invoked from network); 1 Feb 2012 16:14:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:14:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10419548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16:14:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	16:14:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Wed, 1 Feb 2012 16:14:19 +0000
In-Reply-To: <8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
	<1328089685.17444.15.camel@zakaz.uk.xensource.com>
	<8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328112859.17444.94.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 15:58 +0000, Andres Lagar-Cavilla wrote:
> > On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
> >> Config.mk            |   1 +
> >>  tools/Makefile       |   1 +
> >>  tools/tests/Makefile |  20 ++++++++++++++++++++
> >>  3 files changed, 22 insertions(+), 0 deletions(-)
> >>
> >>
> >> Build tests as part of the tools build.
> >>
> >> It is enabled with CONFIG_TESTS in Config.mk
> >>
> >> Currently disabled build of tests/regressions and tests/xen-access (in
> >> 32 bit
> >> mode) as they fail.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > Ack on the idea but the actual implementation fails for me:
> >
> > make[1]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools'
> > make -C tests install
> > make[2]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> > make[3]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
> > make -C mce-test install
> > make[4]: Entering directory
> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
> > make[4]: *** No rule to make target `install'.  Stop.
> >
> > Grep seems to suggest that most of the tools/tests dirs are missing an
> > install target, mce-test just happens to be first.
> >
> > I'm not sure if it makes sense to install any of these test things?
> > Depending on the answer we could either hobble the install target in
> > tools/tests/Makefile or add an install target to tools/tests/*/Makefile
> > which is a nop or an actual install target as appropriate.
> 
> Vote is to hobble install target. Refresh of patch pasted below (also
> added distclean).
> Thanks!
> Andres
> 
> # HG changeset patch
> # Parent efc0802acb87aec9a4d578e741e209bef8c6fe52
> Tools: build tests
> 
> Build tests as part of the tools build.
> 
> It is enabled with CONFIG_TESTS in Config.mk
> 
> Currently disabled build of tests/regressions and tests/xen-access (in 32
> bit mode) as they fail.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

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

> 
> diff -r efc0802acb87 Config.mk
> --- a/Config.mk
> +++ b/Config.mk
> @@ -238,6 +238,7 @@ OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
>  CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_TESTS       ?= y
> 
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> diff -r efc0802acb87 tools/Makefile
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -45,6 +45,7 @@ SUBDIRS-y += remus
>  SUBDIRS-$(CONFIG_X86) += xenpaging
>  SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
>  SUBDIRS-$(CONFIG_X86) += debugger/kdd
> +SUBDIRS-$(CONFIG_TESTS) += tests
> 
>  # These don't cross-compile
>  ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
> diff -r efc0802acb87 tools/tests/Makefile
> --- /dev/null
> +++ b/tools/tests/Makefile
> @@ -0,0 +1,21 @@
> +XEN_ROOT = $(CURDIR)/../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +CFLAGS  += $(CFLAGS_libxenctrl)
> +LDLIBS += $(LDLIBS_libxenctrl)
> +
> +SUBDIRS-y :=
> +SUBDIRS-y += mce-test
> +SUBDIRS-y += mem-sharing
> +ifeq ($(XEN_TARGET_ARCH),__fixme__)
> +SUBDIRS-y += regression
> +endif
> +SUBDIRS-y += x86_emulator
> +ifneq ($(XEN_TARGET_ARCH),x86_32)
> +SUBDIRS-y += xen-access
> +endif
> +
> +.PHONY: all clean install distclean
> +all clean distclean: %: subdirs-%
> +
> +install:
> 
> 
> 
> >
> > Ian.
> >
> >
> >
> 
> 



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:15:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rscpv-0000S0-05; Wed, 01 Feb 2012 16:15:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rscpt-0000Rg-8n
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:15:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328112899!13276612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30545 invoked from network); 1 Feb 2012 16:14:59 -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;
	1 Feb 2012 16:14:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10419564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16: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.213.0; Wed, 1 Feb 2012
	16:14:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Santosh Jodh <santosh.jodh@citrix.com>
Date: Wed, 1 Feb 2012 16:14:58 +0000
In-Reply-To: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
References: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328112898.17444.96.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] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 19:07 +0000, Santosh Jodh wrote:
> Replace malloc with alloc in hot paths for improved performance.

This is a hot path in something like a userspace PV backend which is
frequently mapping guest domain pages, or something like that?

> Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>

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

> 
> diff -r e2722b24dc09 -r 4952090d35e0 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_linux_osdep.c	Mon Jan 30 11:02:32 2012 -0800
> @@ -242,7 +242,7 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
> -        xen_pfn_t *pfn = malloc(num * sizeof(*pfn));
> +        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
>  
>          if ( pfn )
>          {
> @@ -288,8 +288,6 @@ static void *linux_privcmd_map_foreign_b
>                  break;
>              }
>  
> -            free(pfn);
> -
>              if ( rc == -ENOENT && i == num )
>                  rc = 0;
>              else if ( rc )
> @@ -524,7 +522,7 @@ static void *linux_gnttab_grant_map(xc_g
>      if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>          domids_stride = 0;
>  
> -    map = malloc(sizeof(*map) +
> +    map = alloca(sizeof(*map) +
>                   (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
>      if ( map == NULL )
>          return NULL;
> @@ -598,7 +596,6 @@ static void *linux_gnttab_grant_map(xc_g
>      }
>  
>   out:
> -    free(map);
>  
>      return addr;
>  }



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:15:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rscpv-0000S0-05; Wed, 01 Feb 2012 16:15:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rscpt-0000Rg-8n
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:15:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328112899!13276612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30545 invoked from network); 1 Feb 2012 16:14:59 -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;
	1 Feb 2012 16:14:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10419564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16: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.213.0; Wed, 1 Feb 2012
	16:14:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Santosh Jodh <santosh.jodh@citrix.com>
Date: Wed, 1 Feb 2012 16:14:58 +0000
In-Reply-To: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
References: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328112898.17444.96.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] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 19:07 +0000, Santosh Jodh wrote:
> Replace malloc with alloc in hot paths for improved performance.

This is a hot path in something like a userspace PV backend which is
frequently mapping guest domain pages, or something like that?

> Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>

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

> 
> diff -r e2722b24dc09 -r 4952090d35e0 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_linux_osdep.c	Mon Jan 30 11:02:32 2012 -0800
> @@ -242,7 +242,7 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
> -        xen_pfn_t *pfn = malloc(num * sizeof(*pfn));
> +        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
>  
>          if ( pfn )
>          {
> @@ -288,8 +288,6 @@ static void *linux_privcmd_map_foreign_b
>                  break;
>              }
>  
> -            free(pfn);
> -
>              if ( rc == -ENOENT && i == num )
>                  rc = 0;
>              else if ( rc )
> @@ -524,7 +522,7 @@ static void *linux_gnttab_grant_map(xc_g
>      if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>          domids_stride = 0;
>  
> -    map = malloc(sizeof(*map) +
> +    map = alloca(sizeof(*map) +
>                   (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
>      if ( map == NULL )
>          return NULL;
> @@ -598,7 +596,6 @@ static void *linux_gnttab_grant_map(xc_g
>      }
>  
>   out:
> -    free(map);
>  
>      return addr;
>  }



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16: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.xensource.com>)
	id 1RscuW-0000vn-Qr; Wed, 01 Feb 2012 16:19:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1RscuV-0000vT-S2
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:19:52 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328113184!12495037!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkxNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28334 invoked from network); 1 Feb 2012 16:19:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320642000"; d="scan'208";a="21507513"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:19:44 -0500
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi;
	Wed, 1 Feb 2012 08:19:43 -0800
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 1 Feb 2012 08:19:41 -0800
Thread-Topic: [PATCH] perf: Replace malloc with alloca in hot path
Thread-Index: Aczg/KXECgBwzF73Qtmy/TlagiOOSAAAHixg
Message-ID: <7914B38A4445B34AA16EB9F1352942F1010A1ED29DF0@SJCPMAILBOX01.citrite.net>
References: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
	<1328112898.17444.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328112898.17444.96.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes - that is correct. This is used in the IO path for user mode block backend.

Thanks,
Santosh

-----Original Message-----
From: Ian Campbell 
Sent: Wednesday, February 01, 2012 8:15 AM
To: Santosh Jodh
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] perf: Replace malloc with alloca in hot path

On Mon, 2012-01-30 at 19:07 +0000, Santosh Jodh wrote:
> Replace malloc with alloc in hot paths for improved performance.

This is a hot path in something like a userspace PV backend which is frequently mapping guest domain pages, or something like that?

> Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>

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

> 
> diff -r e2722b24dc09 -r 4952090d35e0 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_linux_osdep.c	Mon Jan 30 11:02:32 2012 -0800
> @@ -242,7 +242,7 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
> -        xen_pfn_t *pfn = malloc(num * sizeof(*pfn));
> +        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
>  
>          if ( pfn )
>          {
> @@ -288,8 +288,6 @@ static void *linux_privcmd_map_foreign_b
>                  break;
>              }
>  
> -            free(pfn);
> -
>              if ( rc == -ENOENT && i == num )
>                  rc = 0;
>              else if ( rc )
> @@ -524,7 +522,7 @@ static void *linux_gnttab_grant_map(xc_g
>      if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>          domids_stride = 0;
>  
> -    map = malloc(sizeof(*map) +
> +    map = alloca(sizeof(*map) +
>                   (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
>      if ( map == NULL )
>          return NULL;
> @@ -598,7 +596,6 @@ static void *linux_gnttab_grant_map(xc_g
>      }
>  
>   out:
> -    free(map);
>  
>      return addr;
>  }


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16: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.xensource.com>)
	id 1RscuW-0000vn-Qr; Wed, 01 Feb 2012 16:19:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1RscuV-0000vT-S2
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:19:52 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328113184!12495037!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkxNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28334 invoked from network); 1 Feb 2012 16:19:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320642000"; d="scan'208";a="21507513"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 11:19:44 -0500
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi;
	Wed, 1 Feb 2012 08:19:43 -0800
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 1 Feb 2012 08:19:41 -0800
Thread-Topic: [PATCH] perf: Replace malloc with alloca in hot path
Thread-Index: Aczg/KXECgBwzF73Qtmy/TlagiOOSAAAHixg
Message-ID: <7914B38A4445B34AA16EB9F1352942F1010A1ED29DF0@SJCPMAILBOX01.citrite.net>
References: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
	<1328112898.17444.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328112898.17444.96.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes - that is correct. This is used in the IO path for user mode block backend.

Thanks,
Santosh

-----Original Message-----
From: Ian Campbell 
Sent: Wednesday, February 01, 2012 8:15 AM
To: Santosh Jodh
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] perf: Replace malloc with alloca in hot path

On Mon, 2012-01-30 at 19:07 +0000, Santosh Jodh wrote:
> Replace malloc with alloc in hot paths for improved performance.

This is a hot path in something like a userspace PV backend which is frequently mapping guest domain pages, or something like that?

> Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>

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

> 
> diff -r e2722b24dc09 -r 4952090d35e0 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_linux_osdep.c	Mon Jan 30 11:02:32 2012 -0800
> @@ -242,7 +242,7 @@ static void *linux_privcmd_map_foreign_b
>           * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
>           * IOCTL_PRIVCMD_MMAPBATCH.
>           */
> -        xen_pfn_t *pfn = malloc(num * sizeof(*pfn));
> +        xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
>  
>          if ( pfn )
>          {
> @@ -288,8 +288,6 @@ static void *linux_privcmd_map_foreign_b
>                  break;
>              }
>  
> -            free(pfn);
> -
>              if ( rc == -ENOENT && i == num )
>                  rc = 0;
>              else if ( rc )
> @@ -524,7 +522,7 @@ static void *linux_gnttab_grant_map(xc_g
>      if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>          domids_stride = 0;
>  
> -    map = malloc(sizeof(*map) +
> +    map = alloca(sizeof(*map) +
>                   (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
>      if ( map == NULL )
>          return NULL;
> @@ -598,7 +596,6 @@ static void *linux_gnttab_grant_map(xc_g
>      }
>  
>   out:
> -    free(map);
>  
>      return addr;
>  }


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:26:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsd0S-0001Jn-Kx; Wed, 01 Feb 2012 16:26:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rsd0Q-0001Jb-Bf
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:25:58 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328113546!13519608!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10313 invoked from network); 1 Feb 2012 16:25:48 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 16:25:48 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11GPeii023282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 1 Feb 2012 11:25:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q11GPeVG023280;
	Wed, 1 Feb 2012 11:25:40 -0500
Date: Wed, 1 Feb 2012 12:25:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Message-ID: <20120201162540.GA23047@andromeda.dapyr.net>
References: <4F218876.8090606@ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F218876.8090606@ca.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Help needed debugging "EPT Misconfiguration"
	exception on Intel CPU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 05:08:07PM +0000, Kalev, Leonid wrote:
> (note, please send a copy of replies to my e-mail, I am not subscribed to the 
> xen-devel list)
> 
> Before I get into details about the problem: I tried to identify the CPU as precisely 
> as possible (in case there are known problems with the specific model), but what I 
> found in the CPU identification information (as reported by the 'cpuid' instruction) 
> seems strange: unlike most Intel CPUs that report a sensible model name, which 
> generally matches the commercial name of the CPU, (e.g. "Intel(R) Core(TM) i5 CPU"), 
> on the server where I caught the EPT exception, the CPU model string reads:
> "Genuine Intel(R) CPU           @ 0000 @ 2.40GHz"

Hm, I only saw those on pre-production hardware - aka, Beta CPUS. Are
you sure this is not one of those?

> 
> This does not look like any CPU that Intel sells. The family, model and stepping 
> numbers are 6 26 and 2, respectively. I did not find any reference to this particular 
> combination of model ID numbers, except in just one or two forum posts on the Web, 
> referring to the same non-descript model string quoted above. One of the posts even 
> suggested that this might be a non-production CPU chip: 
> http://www.spinics.net/lists/kvm/msg58258.html
> 
> Now, to the problem itself:
> attempting to start a hardware-assisted virtual machine (HVM) on XEN 4.1.1 causes the 
> guest VM to crash instantly on startup. The crash is caused by a VM exit that is not 
> handled by XEN (and which cannot be handled in any way other than destroying the 
> guest VM): the VM exit reason is 49 (0x31), which is "EPT Misconfiguration".

So does this work with a different CPU in that motherboard?

> 
> According to the Intel Software Developer Manual (Vol 3B, Chapter 25 - VMX SUPPORT 
> FOR ADDRESS TRANSLATION), this VM exit means that an invalid value was found in the 
> extended page tables. Suspecting a software problem, I modified the XEN hypervisor to 
> provide additional information as follows:
> - read and display the value of the EPTP VM control field
> - read and display the value of the "Guest-physical address" control field (GPA)
> - use the guest-physical address value to traverse the EPT structures and display
>     all 4 levels of page table entries that pertain to the GPA reported by the CPU.
> 
> I was not able to find any error in the EPTP value, nor in the EPT table entries, 
> they all seem to be valid. Below, I am including:
> - the debug information displayed by XEN (with the additional instrumentation
>     that I added), with some bit-field analysis that I did manually (showing no
>     problems in the EPT entries)
> - the CPU information (xm info and /proc/cpuinfo)
> - memory map from BIOS
> 
> Also, the detailed DMI info from BIOS is attached as a text file (it doesn't show 
> anything different about the CPU, though).
> 
> ============= XEN console log, with comments from me ==========================
> (XEN) EPT Misconfiguration, gpa=00000000feffe000
> (XEN) domain->...->eptp   = 0x431b3d01e
> (XEN) vmread(EPT_POINTER) = 0x431b3d01e
> 
>     EPTP bits:
>     0-2   = 6; mem type (0 = UC, 6=WB, all other = invalid)
>     5-3   = 3 (should be = 3 (walk length - 1))
>     6-11  = 0 reserved
>     12-39 = 0x431b3d; addr of EPT PML4
>     40-64 = 0 ; reserved (40 is the addr sz of the CPU here, may vary on other CPUs, 
> max=48)
> 
> (XEN) p2m-ept.c:649:d3 Walking EPT tables for domain 3 gfn feffe
> (XEN) p2m-ept.c:668:d3  epte 1c00000431b3c007
>                                                 0-2 = 7: access allowed: rwx
>                                                 3-7 = 0: reserved
>                            8-11 = 0: ignored
>                                                 x-12 = 431b3c: address of next level EPT
>                            51-x - 0
>                            52-63 - ignored
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fb007
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fa007
> (XEN) p2m-ept.c:668:d3  epte 1c10000c213ee037 0-2 = 7: rwx
>                                     10000000000 (nb: addr size limit - 40 bits for
>                                                  this CPU, we're way below)
>                                                 3-5 = 6: type (0 = UC; 1 = WC; 4 = WT;
>                                                          5 = WP; 6 = WB)
>                            6   = 0:
>                            7-11 =0: (ignored)
>                            mfn=c213ee, (looks valid, mem extends from 100000 to 
> c40000, see mem map below)
>                            52=1;  52-63 should be ignored
> 
> (XEN) domain_crash called from vmx.c:2650
> (XEN) Domain 3 (vcpu#0) crashed on cpu#15:
> (XEN) ----[ Xen-4.1.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    15
> (XEN) RIP:    0000:[<0000000000000000>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 0000000000000001   rbx: 0000000000000000   rcx: 0000000000000000
> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
> (XEN) rbp: 0000000000000000   rsp: 0000000000000000   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000011   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: 0000
> 
>       CR0 = 0x10 = PE+ET
>       RFLAGS = RF + 2 (2 is always set)
> 
> ============= system info from XEN ============================
> # xm info
> host                   : 3tera-srv1
> release                : 3.0.4-40.xen0
> version                : #1 SMP Wed Dec 14 19:48:03 EST 2011
> machine                : i686
> nr_cpus                : 16
> nr_nodes               : 2
> cores_per_socket       : 4
> threads_per_core       : 2
> cpu_mhz                : 2400
> hw_caps                : 
> bfebfbff:28100800:00000000:00003b40:00bce3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 49142
> free_memory            : 47487
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : .1
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xfcc00000
> xen_changeset          : unavailable
> xen_commandline        : noht iommu=off dom0_vcpus_pin dom0_max_vcpus=1 dom0_mem=786432
> cc_compiler            : gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
> cc_compile_by          : 3tera
> cc_compile_domain      : (none)
> cc_compile_date        : Mon Jan 23 06:11:47 PST 2012
> xend_config_format     : 4
> 
> ============= CPU info (/proc/cpuinfo, from Dom0 - flags are filtered by XEN)
> # cat /proc/cpuinfo
> processor    : 0
> vendor_id    : GenuineIntel
> cpu family    : 6
> model        : 26
> model name    : Genuine Intel(R) CPU           @ 0000 @ 2.40GHz
> stepping    : 2
> cpu MHz        : 2400.112
> cache size    : 8192 KB
> physical id    : 0
> siblings    : 1
> core id        : 0
> cpu cores    : 1
> apicid        : 0
> initial apicid    : 0
> fdiv_bug    : no
> hlt_bug        : no
> f00f_bug    : no
> coma_bug    : no
> fpu        : yes
> fpu_exception    : yes
> cpuid level    : 11
> wp        : yes
> flags        : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse 
> sse2 ss ht nx lm constant_tsc up nonstop_tsc aperfmperf pni est ssse3 sse4_1 sse4_2 
> x2apic popcnt hypervisor ida dts
> bogomips    : 4800.22
> clflush size    : 64
> cache_alignment    : 64
> address sizes    : 40 bits physical, 48 bits virtual
> power management:
> 
> ============= BIOS memory map, as shown by XEN on boot ==========================
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009cc00 (usable)
> (XEN)  000000000009cc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e6000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000bf760000 (usable)
> (XEN)  00000000bf76e000 - 00000000bf770000 type 9
> (XEN)  00000000bf770000 - 00000000bf77e000 (ACPI data)
> (XEN)  00000000bf77e000 - 00000000bf7d0000 (ACPI NVS)
> (XEN)  00000000bf7d0000 - 00000000bf7e0000 (reserved)
> (XEN)  00000000bf7ec000 - 00000000c0000000 (reserved)
> (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ffc00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000c40000000 (usable)
> 
> -- 
> Leonid Kalev
> CA Technologies
> Principal Software Engineer
> Tel:     +972 4 825 3952
> Mobile:  +972 54 4631508
> Leonid.Kalev@ca.com
> 
> 
> dmidecode-eptfail
> 
> # dmidecode 2.10
> SMBIOS 2.6 present.
> 44 structures occupying 2549 bytes.
> Table at 0x0009EC00.
> 
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
> 	Vendor: American Megatrends Inc.
> 	Version: 080016
> 	Release Date: 02/11/2011
> 	Address: 0xF0000
> 	Runtime Size: 64 kB
> 	ROM Size: 4096 kB
> 	Characteristics:
> 		ISA is supported
> 		PCI is supported
> 		PNP is supported
> 		BIOS is upgradeable
> 		BIOS shadowing is allowed
> 		ESCD support is available
> 		Boot from CD is supported
> 		Selectable boot is supported
> 		BIOS ROM is socketed
> 		EDD is supported
> 		5.25"/1.2 MB floppy services are supported (int 13h)
> 		3.5"/720 kB floppy services are supported (int 13h)
> 		3.5"/2.88 MB floppy services are supported (int 13h)
> 		Print screen service is supported (int 5h)
> 		8042 keyboard services are supported (int 9h)
> 		Serial services are supported (int 14h)
> 		Printer services are supported (int 17h)
> 		CGA/mono video services are supported (int 10h)
> 		ACPI is supported
> 		USB legacy is supported
> 		LS-120 boot is supported
> 		ATAPI Zip drive boot is supported
> 		BIOS boot specification is supported
> 		Targeted content distribution is supported
> 	BIOS Revision: 8.16
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1234567890
> 	Serial Number: 1234567890
> 	UUID: 54443858-4E54-3000-48F4-003048F41770
> 	Wake-up Type: Power Switch
> 	SKU Number: 1234567890
> 	Family: Server
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1.3
> 	Serial Number: 1234567890
> 	Asset Tag: 1234567890
> 	Features:
> 		Board is a hosting board
> 		Board is replaceable
> 	Location In Chassis: 1234567890
> 	Chassis Handle: 0x0003
> 	Type: Motherboard
> 	Contained Object Handles: 0
> 
> Handle 0x0003, DMI type 3, 21 bytes
> Chassis Information
> 	Manufacturer: Supermicro
> 	Type: Main Server Chassis
> 	Lock: Not Present
> 	Version: 1234567890
> 	Serial Number: 1234567890.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Boot-up State: Safe
> 	Power Supply State: Safe
> 	Thermal State: Safe
> 	Security Status: None
> 	OEM Information: 0x00000000
> 	Height: Unspecified
> 	Number Of Power Cords: 1
> 	Contained Elements: 0
> 
> Handle 0x0004, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 1
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0005
> 	L2 Cache Handle: 0x0006
> 	L3 Cache Handle: 0x0007
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0005, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x0006, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x0007, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x0008, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 2
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0009
> 	L2 Cache Handle: 0x000A
> 	L3 Cache Handle: 0x000B
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0009, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x000A, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x000B, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x000C, DMI type 9, 17 bytes
> System Slot Information
> 	Designation: PCIE1
> 	Type: x16 PCI Express
> 	Current Usage: Available
> 	Length: Long
> 	ID: 1
> 	Characteristics:
> 		3.3 V is provided
> 		Opening is shared
> 		PME signal is supported
> 
> Handle 0x000D, DMI type 11, 5 bytes
> OEM Strings
> 	String 1: To Be Filled By O.E.M.
> 	String 2: To Be Filled By O.E.M.
> 
> Handle 0x000E, DMI type 15, 55 bytes
> System Event Log
> 	Area Length: 1008 bytes
> 	Header Start Offset: 0x0810
> 	Data Start Offset: 0x0810
> 	Access Method: General-purpose non-volatile data functions
> 	Access Address: 0x0001
> 	Status: Valid, Not Full
> 	Change Token: 0x00000000
> 	Header Format: No Header
> 	Supported Log Type Descriptors: 15
> 	Descriptor 1: Single-bit ECC memory error
> 	Data Format 1: Multiple-event handle
> 	Descriptor 2: Multi-bit ECC memory error
> 	Data Format 2: Multiple-event handle
> 	Descriptor 3: Parity memory error
> 	Data Format 3: Multiple-event
> 	Descriptor 4: I/O channel block
> 	Data Format 4: Multiple-event
> 	Descriptor 5: POST error
> 	Data Format 5: POST results bitmap
> 	Descriptor 6: PCI parity error
> 	Data Format 6: Multiple-event handle
> 	Descriptor 7: PCI system error
> 	Data Format 7: Multiple-event handle
> 	Descriptor 8: System limit exceeded
> 	Data Format 8: Multiple-event system management
> 	Descriptor 9: OEM-specific
> 	Data Format 9: POST results bitmap
> 	Descriptor 10: OEM-specific
> 	Data Format 10: Multiple-event handle
> 	Descriptor 11: OEM-specific
> 	Data Format 11: Multiple-event handle
> 	Descriptor 12: OEM-specific
> 	Data Format 12: Multiple-event handle
> 	Descriptor 13: OEM-specific
> 	Data Format 13: Multiple-event handle
> 	Descriptor 14: OEM-specific
> 	Data Format 14: Multiple-event handle
> 	Descriptor 15: OEM-specific
> 	Data Format 15: Multiple-event handle
> 
> Handle 0x000F, DMI type 16, 15 bytes
> Physical Memory Array
> 	Location: System Board Or Motherboard
> 	Use: System Memory
> 	Error Correction Type: Multi-bit ECC
> 	Maximum Capacity: 384 GB
> 	Error Information Handle: Not Provided
> 	Number Of Devices: 12
> 
> Handle 0x0010, DMI type 19, 15 bytes
> Memory Array Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x04443FFFFFF
> 	Range Size: 279616 MB
> 	Physical Array Handle: 0x000F
> 	Partition Width: 0
> 
> Handle 0x0011, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1A
> 	Bank Locator: BANK0
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0012, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x001000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0011
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0013, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1B
> 	Bank Locator: BANK1
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0014, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00100000000
> 	Ending Address: 0x002000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0013
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0015, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2A
> 	Bank Locator: BANK2
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0016, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00200000000
> 	Ending Address: 0x003000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0015
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0017, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2B
> 	Bank Locator: BANK3
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0018, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00300000000
> 	Ending Address: 0x004000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0017
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0019, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3A
> 	Bank Locator: BANK4
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x001A, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00400000000
> 	Ending Address: 0x005000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0019
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001B, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3B
> 	Bank Locator: BANK5
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x001C, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00500000000
> 	Ending Address: 0x006000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x001B
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001D, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1A
> 	Bank Locator: BANK6
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x001E, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001D
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001F, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1B
> 	Bank Locator: BANK7
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0020, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001F
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0021, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2A
> 	Bank Locator: BANK8
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0022, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x0021
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0023, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2B
> 	Bank Locator: BANK9
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0024, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00600000000
> 	Ending Address: 0x007000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0023
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0025, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3A
> 	Bank Locator: BANK10
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0026, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00700000000
> 	Ending Address: 0x008000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0025
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0027, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3B
> 	Bank Locator: BANK11
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0028, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00800000000
> 	Ending Address: 0x009000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0027
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0029, DMI type 32, 20 bytes
> System Boot Information
> 	Status: No errors detected
> 
> Handle 0x002A, DMI type 38, 18 bytes
> IPMI Device Information
> 	Interface Type: KCS (Keyboard Control Style)
> 	Specification Version: 2.0
> 	I2C Slave Address: 0x10
> 	NV Storage Device: Not Present
> 	Base Address: 0x0000000000000CA2 (I/O)
> 	Register Spacing: Successive Byte Boundaries
> 
> Handle 0x002B, DMI type 127, 4 bytes
> End Of Table
> 
> 
> -- 
> Leonid Kalev
> CA Technologies
> Principal Software Engineer
> Tel:     +972 4 825 3952
> Mobile:  +972 54 4631508
> Leonid.Kalev@ca.com

Content-Description: dmidecode-eptfail
> # dmidecode 2.10
> SMBIOS 2.6 present.
> 44 structures occupying 2549 bytes.
> Table at 0x0009EC00.
> 
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
> 	Vendor: American Megatrends Inc.
> 	Version: 080016 
> 	Release Date: 02/11/2011
> 	Address: 0xF0000
> 	Runtime Size: 64 kB
> 	ROM Size: 4096 kB
> 	Characteristics:
> 		ISA is supported
> 		PCI is supported
> 		PNP is supported
> 		BIOS is upgradeable
> 		BIOS shadowing is allowed
> 		ESCD support is available
> 		Boot from CD is supported
> 		Selectable boot is supported
> 		BIOS ROM is socketed
> 		EDD is supported
> 		5.25"/1.2 MB floppy services are supported (int 13h)
> 		3.5"/720 kB floppy services are supported (int 13h)
> 		3.5"/2.88 MB floppy services are supported (int 13h)
> 		Print screen service is supported (int 5h)
> 		8042 keyboard services are supported (int 9h)
> 		Serial services are supported (int 14h)
> 		Printer services are supported (int 17h)
> 		CGA/mono video services are supported (int 10h)
> 		ACPI is supported
> 		USB legacy is supported
> 		LS-120 boot is supported
> 		ATAPI Zip drive boot is supported
> 		BIOS boot specification is supported
> 		Targeted content distribution is supported
> 	BIOS Revision: 8.16
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1234567890
> 	Serial Number: 1234567890
> 	UUID: 54443858-4E54-3000-48F4-003048F41770
> 	Wake-up Type: Power Switch
> 	SKU Number: 1234567890
> 	Family: Server
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1.3       
> 	Serial Number: 1234567890
> 	Asset Tag: 1234567890
> 	Features:
> 		Board is a hosting board
> 		Board is replaceable
> 	Location In Chassis: 1234567890
> 	Chassis Handle: 0x0003
> 	Type: Motherboard
> 	Contained Object Handles: 0
> 
> Handle 0x0003, DMI type 3, 21 bytes
> Chassis Information
> 	Manufacturer: Supermicro
> 	Type: Main Server Chassis
> 	Lock: Not Present
> 	Version: 1234567890
> 	Serial Number: 1234567890.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Boot-up State: Safe
> 	Power Supply State: Safe
> 	Thermal State: Safe
> 	Security Status: None
> 	OEM Information: 0x00000000
> 	Height: Unspecified
> 	Number Of Power Cords: 1
> 	Contained Elements: 0
> 
> Handle 0x0004, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 1
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel            
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz     
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0005
> 	L2 Cache Handle: 0x0006
> 	L3 Cache Handle: 0x0007
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0005, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x0006, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x0007, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x0008, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 2
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel            
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz     
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0009
> 	L2 Cache Handle: 0x000A
> 	L3 Cache Handle: 0x000B
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0009, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x000A, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x000B, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x000C, DMI type 9, 17 bytes
> System Slot Information
> 	Designation: PCIE1
> 	Type: x16 PCI Express
> 	Current Usage: Available
> 	Length: Long
> 	ID: 1
> 	Characteristics:
> 		3.3 V is provided
> 		Opening is shared
> 		PME signal is supported
> 
> Handle 0x000D, DMI type 11, 5 bytes
> OEM Strings
> 	String 1: To Be Filled By O.E.M.
> 	String 2: To Be Filled By O.E.M.
> 
> Handle 0x000E, DMI type 15, 55 bytes
> System Event Log
> 	Area Length: 1008 bytes
> 	Header Start Offset: 0x0810
> 	Data Start Offset: 0x0810
> 	Access Method: General-purpose non-volatile data functions
> 	Access Address: 0x0001
> 	Status: Valid, Not Full
> 	Change Token: 0x00000000
> 	Header Format: No Header
> 	Supported Log Type Descriptors: 15
> 	Descriptor 1: Single-bit ECC memory error
> 	Data Format 1: Multiple-event handle
> 	Descriptor 2: Multi-bit ECC memory error
> 	Data Format 2: Multiple-event handle
> 	Descriptor 3: Parity memory error
> 	Data Format 3: Multiple-event
> 	Descriptor 4: I/O channel block
> 	Data Format 4: Multiple-event
> 	Descriptor 5: POST error
> 	Data Format 5: POST results bitmap
> 	Descriptor 6: PCI parity error
> 	Data Format 6: Multiple-event handle
> 	Descriptor 7: PCI system error
> 	Data Format 7: Multiple-event handle
> 	Descriptor 8: System limit exceeded
> 	Data Format 8: Multiple-event system management
> 	Descriptor 9: OEM-specific
> 	Data Format 9: POST results bitmap
> 	Descriptor 10: OEM-specific
> 	Data Format 10: Multiple-event handle
> 	Descriptor 11: OEM-specific
> 	Data Format 11: Multiple-event handle
> 	Descriptor 12: OEM-specific
> 	Data Format 12: Multiple-event handle
> 	Descriptor 13: OEM-specific
> 	Data Format 13: Multiple-event handle
> 	Descriptor 14: OEM-specific
> 	Data Format 14: Multiple-event handle
> 	Descriptor 15: OEM-specific
> 	Data Format 15: Multiple-event handle
> 
> Handle 0x000F, DMI type 16, 15 bytes
> Physical Memory Array
> 	Location: System Board Or Motherboard
> 	Use: System Memory
> 	Error Correction Type: Multi-bit ECC
> 	Maximum Capacity: 384 GB
> 	Error Information Handle: Not Provided
> 	Number Of Devices: 12
> 
> Handle 0x0010, DMI type 19, 15 bytes
> Memory Array Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x04443FFFFFF
> 	Range Size: 279616 MB
> 	Physical Array Handle: 0x000F
> 	Partition Width: 0
> 
> Handle 0x0011, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1A
> 	Bank Locator: BANK0
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0012, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x001000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0011
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0013, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1B
> 	Bank Locator: BANK1
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0014, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00100000000
> 	Ending Address: 0x002000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0013
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0015, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2A
> 	Bank Locator: BANK2
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0016, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00200000000
> 	Ending Address: 0x003000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0015
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0017, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2B
> 	Bank Locator: BANK3
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0018, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00300000000
> 	Ending Address: 0x004000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0017
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0019, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3A
> 	Bank Locator: BANK4
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x001A, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00400000000
> 	Ending Address: 0x005000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0019
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001B, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3B
> 	Bank Locator: BANK5
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x001C, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00500000000
> 	Ending Address: 0x006000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x001B
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001D, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1A
> 	Bank Locator: BANK6
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x001E, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001D
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001F, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1B
> 	Bank Locator: BANK7
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0020, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001F
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0021, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2A
> 	Bank Locator: BANK8
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0022, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x0021
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0023, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2B
> 	Bank Locator: BANK9
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0024, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00600000000
> 	Ending Address: 0x007000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0023
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0025, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3A
> 	Bank Locator: BANK10
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:              
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0026, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00700000000
> 	Ending Address: 0x008000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0025
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0027, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3B
> 	Bank Locator: BANK11
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:              
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0028, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00800000000
> 	Ending Address: 0x009000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0027
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0029, DMI type 32, 20 bytes
> System Boot Information
> 	Status: No errors detected
> 
> Handle 0x002A, DMI type 38, 18 bytes
> IPMI Device Information
> 	Interface Type: KCS (Keyboard Control Style)
> 	Specification Version: 2.0
> 	I2C Slave Address: 0x10
> 	NV Storage Device: Not Present
> 	Base Address: 0x0000000000000CA2 (I/O)
> 	Register Spacing: Successive Byte Boundaries
> 
> Handle 0x002B, DMI type 127, 4 bytes
> End Of Table
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:26:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsd0S-0001Jn-Kx; Wed, 01 Feb 2012 16:26:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rsd0Q-0001Jb-Bf
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:25:58 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328113546!13519608!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10313 invoked from network); 1 Feb 2012 16:25:48 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 16:25:48 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11GPeii023282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 1 Feb 2012 11:25:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q11GPeVG023280;
	Wed, 1 Feb 2012 11:25:40 -0500
Date: Wed, 1 Feb 2012 12:25:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Message-ID: <20120201162540.GA23047@andromeda.dapyr.net>
References: <4F218876.8090606@ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F218876.8090606@ca.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Help needed debugging "EPT Misconfiguration"
	exception on Intel CPU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 05:08:07PM +0000, Kalev, Leonid wrote:
> (note, please send a copy of replies to my e-mail, I am not subscribed to the 
> xen-devel list)
> 
> Before I get into details about the problem: I tried to identify the CPU as precisely 
> as possible (in case there are known problems with the specific model), but what I 
> found in the CPU identification information (as reported by the 'cpuid' instruction) 
> seems strange: unlike most Intel CPUs that report a sensible model name, which 
> generally matches the commercial name of the CPU, (e.g. "Intel(R) Core(TM) i5 CPU"), 
> on the server where I caught the EPT exception, the CPU model string reads:
> "Genuine Intel(R) CPU           @ 0000 @ 2.40GHz"

Hm, I only saw those on pre-production hardware - aka, Beta CPUS. Are
you sure this is not one of those?

> 
> This does not look like any CPU that Intel sells. The family, model and stepping 
> numbers are 6 26 and 2, respectively. I did not find any reference to this particular 
> combination of model ID numbers, except in just one or two forum posts on the Web, 
> referring to the same non-descript model string quoted above. One of the posts even 
> suggested that this might be a non-production CPU chip: 
> http://www.spinics.net/lists/kvm/msg58258.html
> 
> Now, to the problem itself:
> attempting to start a hardware-assisted virtual machine (HVM) on XEN 4.1.1 causes the 
> guest VM to crash instantly on startup. The crash is caused by a VM exit that is not 
> handled by XEN (and which cannot be handled in any way other than destroying the 
> guest VM): the VM exit reason is 49 (0x31), which is "EPT Misconfiguration".

So does this work with a different CPU in that motherboard?

> 
> According to the Intel Software Developer Manual (Vol 3B, Chapter 25 - VMX SUPPORT 
> FOR ADDRESS TRANSLATION), this VM exit means that an invalid value was found in the 
> extended page tables. Suspecting a software problem, I modified the XEN hypervisor to 
> provide additional information as follows:
> - read and display the value of the EPTP VM control field
> - read and display the value of the "Guest-physical address" control field (GPA)
> - use the guest-physical address value to traverse the EPT structures and display
>     all 4 levels of page table entries that pertain to the GPA reported by the CPU.
> 
> I was not able to find any error in the EPTP value, nor in the EPT table entries, 
> they all seem to be valid. Below, I am including:
> - the debug information displayed by XEN (with the additional instrumentation
>     that I added), with some bit-field analysis that I did manually (showing no
>     problems in the EPT entries)
> - the CPU information (xm info and /proc/cpuinfo)
> - memory map from BIOS
> 
> Also, the detailed DMI info from BIOS is attached as a text file (it doesn't show 
> anything different about the CPU, though).
> 
> ============= XEN console log, with comments from me ==========================
> (XEN) EPT Misconfiguration, gpa=00000000feffe000
> (XEN) domain->...->eptp   = 0x431b3d01e
> (XEN) vmread(EPT_POINTER) = 0x431b3d01e
> 
>     EPTP bits:
>     0-2   = 6; mem type (0 = UC, 6=WB, all other = invalid)
>     5-3   = 3 (should be = 3 (walk length - 1))
>     6-11  = 0 reserved
>     12-39 = 0x431b3d; addr of EPT PML4
>     40-64 = 0 ; reserved (40 is the addr sz of the CPU here, may vary on other CPUs, 
> max=48)
> 
> (XEN) p2m-ept.c:649:d3 Walking EPT tables for domain 3 gfn feffe
> (XEN) p2m-ept.c:668:d3  epte 1c00000431b3c007
>                                                 0-2 = 7: access allowed: rwx
>                                                 3-7 = 0: reserved
>                            8-11 = 0: ignored
>                                                 x-12 = 431b3c: address of next level EPT
>                            51-x - 0
>                            52-63 - ignored
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fb007
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fa007
> (XEN) p2m-ept.c:668:d3  epte 1c10000c213ee037 0-2 = 7: rwx
>                                     10000000000 (nb: addr size limit - 40 bits for
>                                                  this CPU, we're way below)
>                                                 3-5 = 6: type (0 = UC; 1 = WC; 4 = WT;
>                                                          5 = WP; 6 = WB)
>                            6   = 0:
>                            7-11 =0: (ignored)
>                            mfn=c213ee, (looks valid, mem extends from 100000 to 
> c40000, see mem map below)
>                            52=1;  52-63 should be ignored
> 
> (XEN) domain_crash called from vmx.c:2650
> (XEN) Domain 3 (vcpu#0) crashed on cpu#15:
> (XEN) ----[ Xen-4.1.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    15
> (XEN) RIP:    0000:[<0000000000000000>]
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (XEN) rax: 0000000000000001   rbx: 0000000000000000   rcx: 0000000000000000
> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
> (XEN) rbp: 0000000000000000   rsp: 0000000000000000   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000000000011   cr4: 0000000000000000
> (XEN) cr3: 0000000000000000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: 0000
> 
>       CR0 = 0x10 = PE+ET
>       RFLAGS = RF + 2 (2 is always set)
> 
> ============= system info from XEN ============================
> # xm info
> host                   : 3tera-srv1
> release                : 3.0.4-40.xen0
> version                : #1 SMP Wed Dec 14 19:48:03 EST 2011
> machine                : i686
> nr_cpus                : 16
> nr_nodes               : 2
> cores_per_socket       : 4
> threads_per_core       : 2
> cpu_mhz                : 2400
> hw_caps                : 
> bfebfbff:28100800:00000000:00003b40:00bce3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 49142
> free_memory            : 47487
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : .1
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xfcc00000
> xen_changeset          : unavailable
> xen_commandline        : noht iommu=off dom0_vcpus_pin dom0_max_vcpus=1 dom0_mem=786432
> cc_compiler            : gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
> cc_compile_by          : 3tera
> cc_compile_domain      : (none)
> cc_compile_date        : Mon Jan 23 06:11:47 PST 2012
> xend_config_format     : 4
> 
> ============= CPU info (/proc/cpuinfo, from Dom0 - flags are filtered by XEN)
> # cat /proc/cpuinfo
> processor    : 0
> vendor_id    : GenuineIntel
> cpu family    : 6
> model        : 26
> model name    : Genuine Intel(R) CPU           @ 0000 @ 2.40GHz
> stepping    : 2
> cpu MHz        : 2400.112
> cache size    : 8192 KB
> physical id    : 0
> siblings    : 1
> core id        : 0
> cpu cores    : 1
> apicid        : 0
> initial apicid    : 0
> fdiv_bug    : no
> hlt_bug        : no
> f00f_bug    : no
> coma_bug    : no
> fpu        : yes
> fpu_exception    : yes
> cpuid level    : 11
> wp        : yes
> flags        : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse 
> sse2 ss ht nx lm constant_tsc up nonstop_tsc aperfmperf pni est ssse3 sse4_1 sse4_2 
> x2apic popcnt hypervisor ida dts
> bogomips    : 4800.22
> clflush size    : 64
> cache_alignment    : 64
> address sizes    : 40 bits physical, 48 bits virtual
> power management:
> 
> ============= BIOS memory map, as shown by XEN on boot ==========================
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009cc00 (usable)
> (XEN)  000000000009cc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e6000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 00000000bf760000 (usable)
> (XEN)  00000000bf76e000 - 00000000bf770000 type 9
> (XEN)  00000000bf770000 - 00000000bf77e000 (ACPI data)
> (XEN)  00000000bf77e000 - 00000000bf7d0000 (ACPI NVS)
> (XEN)  00000000bf7d0000 - 00000000bf7e0000 (reserved)
> (XEN)  00000000bf7ec000 - 00000000c0000000 (reserved)
> (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
> (XEN)  00000000fee00000 - 00000000fee01000 (reserved)
> (XEN)  00000000ffc00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000c40000000 (usable)
> 
> -- 
> Leonid Kalev
> CA Technologies
> Principal Software Engineer
> Tel:     +972 4 825 3952
> Mobile:  +972 54 4631508
> Leonid.Kalev@ca.com
> 
> 
> dmidecode-eptfail
> 
> # dmidecode 2.10
> SMBIOS 2.6 present.
> 44 structures occupying 2549 bytes.
> Table at 0x0009EC00.
> 
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
> 	Vendor: American Megatrends Inc.
> 	Version: 080016
> 	Release Date: 02/11/2011
> 	Address: 0xF0000
> 	Runtime Size: 64 kB
> 	ROM Size: 4096 kB
> 	Characteristics:
> 		ISA is supported
> 		PCI is supported
> 		PNP is supported
> 		BIOS is upgradeable
> 		BIOS shadowing is allowed
> 		ESCD support is available
> 		Boot from CD is supported
> 		Selectable boot is supported
> 		BIOS ROM is socketed
> 		EDD is supported
> 		5.25"/1.2 MB floppy services are supported (int 13h)
> 		3.5"/720 kB floppy services are supported (int 13h)
> 		3.5"/2.88 MB floppy services are supported (int 13h)
> 		Print screen service is supported (int 5h)
> 		8042 keyboard services are supported (int 9h)
> 		Serial services are supported (int 14h)
> 		Printer services are supported (int 17h)
> 		CGA/mono video services are supported (int 10h)
> 		ACPI is supported
> 		USB legacy is supported
> 		LS-120 boot is supported
> 		ATAPI Zip drive boot is supported
> 		BIOS boot specification is supported
> 		Targeted content distribution is supported
> 	BIOS Revision: 8.16
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1234567890
> 	Serial Number: 1234567890
> 	UUID: 54443858-4E54-3000-48F4-003048F41770
> 	Wake-up Type: Power Switch
> 	SKU Number: 1234567890
> 	Family: Server
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1.3
> 	Serial Number: 1234567890
> 	Asset Tag: 1234567890
> 	Features:
> 		Board is a hosting board
> 		Board is replaceable
> 	Location In Chassis: 1234567890
> 	Chassis Handle: 0x0003
> 	Type: Motherboard
> 	Contained Object Handles: 0
> 
> Handle 0x0003, DMI type 3, 21 bytes
> Chassis Information
> 	Manufacturer: Supermicro
> 	Type: Main Server Chassis
> 	Lock: Not Present
> 	Version: 1234567890
> 	Serial Number: 1234567890.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Boot-up State: Safe
> 	Power Supply State: Safe
> 	Thermal State: Safe
> 	Security Status: None
> 	OEM Information: 0x00000000
> 	Height: Unspecified
> 	Number Of Power Cords: 1
> 	Contained Elements: 0
> 
> Handle 0x0004, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 1
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0005
> 	L2 Cache Handle: 0x0006
> 	L3 Cache Handle: 0x0007
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0005, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x0006, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x0007, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x0008, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 2
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0009
> 	L2 Cache Handle: 0x000A
> 	L3 Cache Handle: 0x000B
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0009, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x000A, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x000B, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x000C, DMI type 9, 17 bytes
> System Slot Information
> 	Designation: PCIE1
> 	Type: x16 PCI Express
> 	Current Usage: Available
> 	Length: Long
> 	ID: 1
> 	Characteristics:
> 		3.3 V is provided
> 		Opening is shared
> 		PME signal is supported
> 
> Handle 0x000D, DMI type 11, 5 bytes
> OEM Strings
> 	String 1: To Be Filled By O.E.M.
> 	String 2: To Be Filled By O.E.M.
> 
> Handle 0x000E, DMI type 15, 55 bytes
> System Event Log
> 	Area Length: 1008 bytes
> 	Header Start Offset: 0x0810
> 	Data Start Offset: 0x0810
> 	Access Method: General-purpose non-volatile data functions
> 	Access Address: 0x0001
> 	Status: Valid, Not Full
> 	Change Token: 0x00000000
> 	Header Format: No Header
> 	Supported Log Type Descriptors: 15
> 	Descriptor 1: Single-bit ECC memory error
> 	Data Format 1: Multiple-event handle
> 	Descriptor 2: Multi-bit ECC memory error
> 	Data Format 2: Multiple-event handle
> 	Descriptor 3: Parity memory error
> 	Data Format 3: Multiple-event
> 	Descriptor 4: I/O channel block
> 	Data Format 4: Multiple-event
> 	Descriptor 5: POST error
> 	Data Format 5: POST results bitmap
> 	Descriptor 6: PCI parity error
> 	Data Format 6: Multiple-event handle
> 	Descriptor 7: PCI system error
> 	Data Format 7: Multiple-event handle
> 	Descriptor 8: System limit exceeded
> 	Data Format 8: Multiple-event system management
> 	Descriptor 9: OEM-specific
> 	Data Format 9: POST results bitmap
> 	Descriptor 10: OEM-specific
> 	Data Format 10: Multiple-event handle
> 	Descriptor 11: OEM-specific
> 	Data Format 11: Multiple-event handle
> 	Descriptor 12: OEM-specific
> 	Data Format 12: Multiple-event handle
> 	Descriptor 13: OEM-specific
> 	Data Format 13: Multiple-event handle
> 	Descriptor 14: OEM-specific
> 	Data Format 14: Multiple-event handle
> 	Descriptor 15: OEM-specific
> 	Data Format 15: Multiple-event handle
> 
> Handle 0x000F, DMI type 16, 15 bytes
> Physical Memory Array
> 	Location: System Board Or Motherboard
> 	Use: System Memory
> 	Error Correction Type: Multi-bit ECC
> 	Maximum Capacity: 384 GB
> 	Error Information Handle: Not Provided
> 	Number Of Devices: 12
> 
> Handle 0x0010, DMI type 19, 15 bytes
> Memory Array Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x04443FFFFFF
> 	Range Size: 279616 MB
> 	Physical Array Handle: 0x000F
> 	Partition Width: 0
> 
> Handle 0x0011, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1A
> 	Bank Locator: BANK0
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0012, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x001000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0011
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0013, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1B
> 	Bank Locator: BANK1
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0014, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00100000000
> 	Ending Address: 0x002000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0013
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0015, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2A
> 	Bank Locator: BANK2
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0016, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00200000000
> 	Ending Address: 0x003000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0015
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0017, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2B
> 	Bank Locator: BANK3
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0018, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00300000000
> 	Ending Address: 0x004000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0017
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0019, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3A
> 	Bank Locator: BANK4
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x001A, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00400000000
> 	Ending Address: 0x005000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0019
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001B, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3B
> 	Bank Locator: BANK5
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x001C, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00500000000
> 	Ending Address: 0x006000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x001B
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001D, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1A
> 	Bank Locator: BANK6
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x001E, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001D
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001F, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1B
> 	Bank Locator: BANK7
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0020, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001F
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0021, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2A
> 	Bank Locator: BANK8
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0022, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x0021
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0023, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2B
> 	Bank Locator: BANK9
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0024, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00600000000
> 	Ending Address: 0x007000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0023
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0025, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3A
> 	Bank Locator: BANK10
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0026, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00700000000
> 	Ending Address: 0x008000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0025
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0027, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3B
> 	Bank Locator: BANK11
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:
> 	Serial Number: 00000000
> 	Asset Tag:
> 	Part Number: SUPERTALENT02
> 	Rank: Unknown
> 
> Handle 0x0028, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00800000000
> 	Ending Address: 0x009000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0027
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0029, DMI type 32, 20 bytes
> System Boot Information
> 	Status: No errors detected
> 
> Handle 0x002A, DMI type 38, 18 bytes
> IPMI Device Information
> 	Interface Type: KCS (Keyboard Control Style)
> 	Specification Version: 2.0
> 	I2C Slave Address: 0x10
> 	NV Storage Device: Not Present
> 	Base Address: 0x0000000000000CA2 (I/O)
> 	Register Spacing: Successive Byte Boundaries
> 
> Handle 0x002B, DMI type 127, 4 bytes
> End Of Table
> 
> 
> -- 
> Leonid Kalev
> CA Technologies
> Principal Software Engineer
> Tel:     +972 4 825 3952
> Mobile:  +972 54 4631508
> Leonid.Kalev@ca.com

Content-Description: dmidecode-eptfail
> # dmidecode 2.10
> SMBIOS 2.6 present.
> 44 structures occupying 2549 bytes.
> Table at 0x0009EC00.
> 
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
> 	Vendor: American Megatrends Inc.
> 	Version: 080016 
> 	Release Date: 02/11/2011
> 	Address: 0xF0000
> 	Runtime Size: 64 kB
> 	ROM Size: 4096 kB
> 	Characteristics:
> 		ISA is supported
> 		PCI is supported
> 		PNP is supported
> 		BIOS is upgradeable
> 		BIOS shadowing is allowed
> 		ESCD support is available
> 		Boot from CD is supported
> 		Selectable boot is supported
> 		BIOS ROM is socketed
> 		EDD is supported
> 		5.25"/1.2 MB floppy services are supported (int 13h)
> 		3.5"/720 kB floppy services are supported (int 13h)
> 		3.5"/2.88 MB floppy services are supported (int 13h)
> 		Print screen service is supported (int 5h)
> 		8042 keyboard services are supported (int 9h)
> 		Serial services are supported (int 14h)
> 		Printer services are supported (int 17h)
> 		CGA/mono video services are supported (int 10h)
> 		ACPI is supported
> 		USB legacy is supported
> 		LS-120 boot is supported
> 		ATAPI Zip drive boot is supported
> 		BIOS boot specification is supported
> 		Targeted content distribution is supported
> 	BIOS Revision: 8.16
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1234567890
> 	Serial Number: 1234567890
> 	UUID: 54443858-4E54-3000-48F4-003048F41770
> 	Wake-up Type: Power Switch
> 	SKU Number: 1234567890
> 	Family: Server
> 
> Handle 0x0002, DMI type 2, 15 bytes
> Base Board Information
> 	Manufacturer: Supermicro
> 	Product Name: X8DTT-H
> 	Version: 1.3       
> 	Serial Number: 1234567890
> 	Asset Tag: 1234567890
> 	Features:
> 		Board is a hosting board
> 		Board is replaceable
> 	Location In Chassis: 1234567890
> 	Chassis Handle: 0x0003
> 	Type: Motherboard
> 	Contained Object Handles: 0
> 
> Handle 0x0003, DMI type 3, 21 bytes
> Chassis Information
> 	Manufacturer: Supermicro
> 	Type: Main Server Chassis
> 	Lock: Not Present
> 	Version: 1234567890
> 	Serial Number: 1234567890.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Boot-up State: Safe
> 	Power Supply State: Safe
> 	Thermal State: Safe
> 	Security Status: None
> 	OEM Information: 0x00000000
> 	Height: Unspecified
> 	Number Of Power Cords: 1
> 	Contained Elements: 0
> 
> Handle 0x0004, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 1
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel            
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz     
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0005
> 	L2 Cache Handle: 0x0006
> 	L3 Cache Handle: 0x0007
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0005, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x0006, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x0007, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x0008, DMI type 4, 42 bytes
> Processor Information
> 	Socket Designation: CPU 2
> 	Type: Central Processor
> 	Family: Xeon
> 	Manufacturer: Intel            
> 	ID: A2 06 01 00 FF FB EB BF
> 	Signature: Type 0, Family 6, Model 26, Stepping 2
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		PAE (Physical address extension)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		APIC (On-chip APIC hardware supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		PSE-36 (36-bit page size extension)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		SS (Self-snoop)
> 		HTT (Hyper-threading technology)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Genuine Intel(R) CPU           @ 0000 @ 2.40GHz     
> 	Voltage: Unknown
> 	External Clock: 133 MHz
> 	Max Speed: 2400 MHz
> 	Current Speed: 2400 MHz
> 	Status: Populated, Enabled
> 	Upgrade: Other
> 	L1 Cache Handle: 0x0009
> 	L2 Cache Handle: 0x000A
> 	L3 Cache Handle: 0x000B
> 	Serial Number: To Be Filled By O.E.M.
> 	Asset Tag: To Be Filled By O.E.M.
> 	Part Number: To Be Filled By O.E.M.
> 	Core Count: 4
> 	Core Enabled: 4
> 	Thread Count: 8
> 	Characteristics:
> 		64-bit capable
> 
> Handle 0x0009, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L1-Cache
> 	Configuration: Enabled, Not Socketed, Level 1
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 256 kB
> 	Maximum Size: 256 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Parity
> 	System Type: Instruction
> 	Associativity: 4-way Set-associative
> 
> Handle 0x000A, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L2-Cache
> 	Configuration: Enabled, Not Socketed, Level 2
> 	Operational Mode: Write Through
> 	Location: Internal
> 	Installed Size: 1024 kB
> 	Maximum Size: 1024 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x000B, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: L3-Cache
> 	Configuration: Enabled, Not Socketed, Level 3
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 8192 kB
> 	Maximum Size: 8192 kB
> 	Supported SRAM Types:
> 		Other
> 	Installed SRAM Type: Other
> 	Speed: Unknown
> 	Error Correction Type: Single-bit ECC
> 	System Type: Unified
> 	Associativity: 16-way Set-associative
> 
> Handle 0x000C, DMI type 9, 17 bytes
> System Slot Information
> 	Designation: PCIE1
> 	Type: x16 PCI Express
> 	Current Usage: Available
> 	Length: Long
> 	ID: 1
> 	Characteristics:
> 		3.3 V is provided
> 		Opening is shared
> 		PME signal is supported
> 
> Handle 0x000D, DMI type 11, 5 bytes
> OEM Strings
> 	String 1: To Be Filled By O.E.M.
> 	String 2: To Be Filled By O.E.M.
> 
> Handle 0x000E, DMI type 15, 55 bytes
> System Event Log
> 	Area Length: 1008 bytes
> 	Header Start Offset: 0x0810
> 	Data Start Offset: 0x0810
> 	Access Method: General-purpose non-volatile data functions
> 	Access Address: 0x0001
> 	Status: Valid, Not Full
> 	Change Token: 0x00000000
> 	Header Format: No Header
> 	Supported Log Type Descriptors: 15
> 	Descriptor 1: Single-bit ECC memory error
> 	Data Format 1: Multiple-event handle
> 	Descriptor 2: Multi-bit ECC memory error
> 	Data Format 2: Multiple-event handle
> 	Descriptor 3: Parity memory error
> 	Data Format 3: Multiple-event
> 	Descriptor 4: I/O channel block
> 	Data Format 4: Multiple-event
> 	Descriptor 5: POST error
> 	Data Format 5: POST results bitmap
> 	Descriptor 6: PCI parity error
> 	Data Format 6: Multiple-event handle
> 	Descriptor 7: PCI system error
> 	Data Format 7: Multiple-event handle
> 	Descriptor 8: System limit exceeded
> 	Data Format 8: Multiple-event system management
> 	Descriptor 9: OEM-specific
> 	Data Format 9: POST results bitmap
> 	Descriptor 10: OEM-specific
> 	Data Format 10: Multiple-event handle
> 	Descriptor 11: OEM-specific
> 	Data Format 11: Multiple-event handle
> 	Descriptor 12: OEM-specific
> 	Data Format 12: Multiple-event handle
> 	Descriptor 13: OEM-specific
> 	Data Format 13: Multiple-event handle
> 	Descriptor 14: OEM-specific
> 	Data Format 14: Multiple-event handle
> 	Descriptor 15: OEM-specific
> 	Data Format 15: Multiple-event handle
> 
> Handle 0x000F, DMI type 16, 15 bytes
> Physical Memory Array
> 	Location: System Board Or Motherboard
> 	Use: System Memory
> 	Error Correction Type: Multi-bit ECC
> 	Maximum Capacity: 384 GB
> 	Error Information Handle: Not Provided
> 	Number Of Devices: 12
> 
> Handle 0x0010, DMI type 19, 15 bytes
> Memory Array Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x04443FFFFFF
> 	Range Size: 279616 MB
> 	Physical Array Handle: 0x000F
> 	Partition Width: 0
> 
> Handle 0x0011, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1A
> 	Bank Locator: BANK0
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0012, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x001000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0011
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0013, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM1B
> 	Bank Locator: BANK1
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0014, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00100000000
> 	Ending Address: 0x002000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0013
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0015, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2A
> 	Bank Locator: BANK2
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0016, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00200000000
> 	Ending Address: 0x003000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0015
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0017, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM2B
> 	Bank Locator: BANK3
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0018, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00300000000
> 	Ending Address: 0x004000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0017
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0019, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3A
> 	Bank Locator: BANK4
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x001A, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00400000000
> 	Ending Address: 0x005000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0019
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001B, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P1-DIMM3B
> 	Bank Locator: BANK5
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x001C, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00500000000
> 	Ending Address: 0x006000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x001B
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001D, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1A
> 	Bank Locator: BANK6
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x001E, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001D
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x001F, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM1B
> 	Bank Locator: BANK7
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0020, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x001F
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0021, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2A
> 	Bank Locator: BANK8
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0022, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x000000003FF
> 	Range Size: 1 kB
> 	Physical Device Handle: 0x0021
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0023, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM2B
> 	Bank Locator: BANK9
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:             
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0024, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00600000000
> 	Ending Address: 0x007000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0023
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0025, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3A
> 	Bank Locator: BANK10
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:              
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0026, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00700000000
> 	Ending Address: 0x008000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0025
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0027, DMI type 17, 28 bytes
> Memory Device
> 	Array Handle: 0x000F
> 	Error Information Handle: Not Provided
> 	Total Width: 72 bits
> 	Data Width: 64 bits
> 	Size: 4096 MB
> 	Form Factor: DIMM
> 	Set: None
> 	Locator: P2-DIMM3B
> 	Bank Locator: BANK11
> 	Type: DDR3
> 	Type Detail: Other
> 	Speed: 1066 MHz
> 	Manufacturer:               
> 	Serial Number: 00000000
> 	Asset Tag:              
> 	Part Number: SUPERTALENT02     
> 	Rank: Unknown
> 
> Handle 0x0028, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00800000000
> 	Ending Address: 0x009000003FF
> 	Range Size: 4194305 kB
> 	Physical Device Handle: 0x0027
> 	Memory Array Mapped Address Handle: 0x0010
> 	Partition Row Position: 1
> 	Interleave Position: Unknown
> 	Interleaved Data Depth: 2
> 
> Handle 0x0029, DMI type 32, 20 bytes
> System Boot Information
> 	Status: No errors detected
> 
> Handle 0x002A, DMI type 38, 18 bytes
> IPMI Device Information
> 	Interface Type: KCS (Keyboard Control Style)
> 	Specification Version: 2.0
> 	I2C Slave Address: 0x10
> 	NV Storage Device: Not Present
> 	Base Address: 0x0000000000000CA2 (I/O)
> 	Register Spacing: Successive Byte Boundaries
> 
> Handle 0x002B, DMI type 127, 4 bytes
> End Of Table
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsd2e-0001Tw-Dd; Wed, 01 Feb 2012 16:28:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rsd2d-0001Tg-KV
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:28:15 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328113686!12764785!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12644 invoked from network); 1 Feb 2012 16:28:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 16:28:08 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11GRxKX023367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 1 Feb 2012 11:27:59 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q11GRwUG023364;
	Wed, 1 Feb 2012 11:27:59 -0500
Date: Wed, 1 Feb 2012 12:27:58 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Olivier B." <xen.list@daevel.fr>
Message-ID: <20120201162758.GB23047@andromeda.dapyr.net>
References: <4F22F403.2030104@daevel.fr>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F22F403.2030104@daevel.fr>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux 3.2.2 & btrfs, on a DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 07:59:15PM +0100, Olivier B. wrote:
> Hi,
> 
> I switch one of my DomU to a 3.2.2 linux kernel (renamed in 2.6.42.2, for 
> compatibility with some software), and I have some problem with btrfs.

Hm, That looks like the spinlock bug:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html

Try applying that (or wait until 3.2.3 comes out) and see if that
makes a differnce.

Thanks!
> 
> I don't know if it's a btrfs or xen problem, the call trace is :
> 
> [56580.320024] INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies)
> [56580.320024] Pid: 11505, comm: btrfs-delayed-m Tainted: G         C   
> 2.6.42.2-dae-xen #2
> [56580.320024] Call Trace:
> [56580.320024]  <IRQ>  [<ffffffff81084719>] ? __rcu_pending+0x82/0x337
> [56580.320024]  [<ffffffff810678bd>] ? tick_nohz_handler+0xbe/0xbe
> [56580.320024]  [<ffffffff81084ccc>] ? rcu_check_callbacks+0x7e/0xae
> [56580.320024]  [<ffffffff81050d44>] ? update_process_times+0x31/0x63
> [56580.320024]  [<ffffffff8106791f>] ? tick_sched_timer+0x62/0x7e
> [56580.320024]  [<ffffffff8105e8b4>] ? __run_hrtimer.isra.28+0x52/0xaa
> [56580.320024]  [<ffffffff8105ee8c>] ? hrtimer_interrupt+0xd5/0x1a1
> [56580.320024]  [<ffffffff8100537e>] ? xen_timer_interrupt+0x28/0x159
> [56580.320024]  [<ffffffff81080097>] ? handle_irq_event_percpu+0x24/0x11c
> [56580.320024]  [<ffffffff810824b1>] ? handle_percpu_irq+0x35/0x4c
> [56580.320024]  [<ffffffff811cbe90>] ? __xen_evtchn_do_upcall+0x154/0x1eb
> [56580.320024]  [<ffffffff8100525c>] ? xen_force_evtchn_callback+0x9/0xa
> [56580.320024]  [<ffffffff811cd490>] ? xen_evtchn_do_upcall+0x22/0x32
> [56580.320024]  [<ffffffff812f863e>] ? xen_do_hypervisor_callback+0x1e/0x30
> [56580.320024]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [56580.320024]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [56580.320024]  [<ffffffff811cc7d5>] ? xen_poll_irq_timeout+0x38/0x44
> [56580.320024]  [<ffffffff812ee21f>] ? xen_spin_lock_slow+0x86/0xdf
> [56580.320024]  [<ffffffff8100688a>] ? __xen_spin_lock+0x32/0x3b
> [56580.320024]  [<ffffffff8106bd6a>] ? do_raw_spin_lock+0x5/0x8
> [56580.320024]  [<ffffffffa002badd>] ? 
> find_free_extent.constprop.77+0x495/0x94b [btrfs]
> [56580.320024]  [<ffffffffa00689fe>] ? 
> btrfs_add_delayed_tree_ref+0x77/0x120 [btrfs]
> [56580.320024]  [<ffffffffa002e61b>] ? btrfs_reserve_extent+0xa4/0x148 
> [btrfs]
> [56580.320024]  [<ffffffffa002eadb>] ? btrfs_alloc_free_block+0x15d/0x283 
> [btrfs]
> [56580.320024]  [<ffffffff81005842>] ? check_events+0x12/0x20
> [56580.320024]  [<ffffffffa0021f3a>] ? __btrfs_cow_block+0x102/0x32c [btrfs]
> [56580.320024]  [<ffffffffa0022257>] ? btrfs_cow_block+0xf3/0x102 [btrfs]
> [56580.320024]  [<ffffffffa0024c84>] ? btrfs_search_slot+0x225/0x64e [btrfs]
> [56580.320024]  [<ffffffffa00285f2>] ? 
> lookup_inline_extent_backref+0xa8/0x360 [btrfs]
> [56580.320024]  [<ffffffffa002a35c>] ? __btrfs_free_extent+0xcb/0x5c8 
> [btrfs]
> [56580.320024]  [<ffffffff812f1dac>] ? __slab_free+0xd6/0x206
> [56580.320024]  [<ffffffff810b9c65>] ? arch_local_irq_restore+0x7/0x8
> [56580.320024]  [<ffffffffa002d87e>] ? run_clustered_refs+0x65f/0x6a9 
> [btrfs]
> [56580.320024]  [<ffffffff81177fe4>] ? rb_next+0x39/0x3f
> [56580.320024]  [<ffffffffa002d991>] ? btrfs_run_delayed_refs+0xc9/0x185 
> [btrfs]
> [56580.320024]  [<ffffffff812ee18a>] ? xen_spin_unlock_slow+0x4d/0x5c
> [56580.320024]  [<ffffffffa003b13a>] ? __btrfs_end_transaction+0x90/0x1dd 
> [btrfs]
> [56580.320024]  [<ffffffffa006ff08>] ? 
> btrfs_async_run_delayed_node_done+0xf8/0x156 [btrfs]
> [56580.320024]  [<ffffffffa005a150>] ? worker_loop+0x16a/0x45a [btrfs]
> [56580.320024]  [<ffffffffa0059fe6>] ? btrfs_queue_worker+0x279/0x279 
> [btrfs]
> [56580.320024]  [<ffffffff8105bbba>] ? kthread+0x76/0x7e
> [56580.320024]  [<ffffffff812f84f4>] ? kernel_thread_helper+0x4/0x10
> [56580.320024]  [<ffffffff812f65b3>] ? int_ret_from_sys_call+0x7/0x1b
> [56580.320024]  [<ffffffff812f5cbc>] ? retint_restore_args+0x5/0x6
> [56580.320024]  [<ffffffff812f84f0>] ? gs_change+0x13/0x13
> 
> I had the problem with 3.2, 3.2.1, then 3.2.2. With and without the 
> renaming to 2.6.42.x.
> 
> The Xen version is 4.0.1 (from Debian amd64), and the Dom0 kernel is a 
> 3.1.0 (also from Debian).
> 
> Thanks for any advice,
> 
> Olivier B.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsd2e-0001Tw-Dd; Wed, 01 Feb 2012 16:28:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rsd2d-0001Tg-KV
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:28:15 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328113686!12764785!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12644 invoked from network); 1 Feb 2012 16:28:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 16:28:08 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q11GRxKX023367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 1 Feb 2012 11:27:59 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q11GRwUG023364;
	Wed, 1 Feb 2012 11:27:59 -0500
Date: Wed, 1 Feb 2012 12:27:58 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Olivier B." <xen.list@daevel.fr>
Message-ID: <20120201162758.GB23047@andromeda.dapyr.net>
References: <4F22F403.2030104@daevel.fr>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F22F403.2030104@daevel.fr>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux 3.2.2 & btrfs, on a DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 07:59:15PM +0100, Olivier B. wrote:
> Hi,
> 
> I switch one of my DomU to a 3.2.2 linux kernel (renamed in 2.6.42.2, for 
> compatibility with some software), and I have some problem with btrfs.

Hm, That looks like the spinlock bug:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html

Try applying that (or wait until 3.2.3 comes out) and see if that
makes a differnce.

Thanks!
> 
> I don't know if it's a btrfs or xen problem, the call trace is :
> 
> [56580.320024] INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies)
> [56580.320024] Pid: 11505, comm: btrfs-delayed-m Tainted: G         C   
> 2.6.42.2-dae-xen #2
> [56580.320024] Call Trace:
> [56580.320024]  <IRQ>  [<ffffffff81084719>] ? __rcu_pending+0x82/0x337
> [56580.320024]  [<ffffffff810678bd>] ? tick_nohz_handler+0xbe/0xbe
> [56580.320024]  [<ffffffff81084ccc>] ? rcu_check_callbacks+0x7e/0xae
> [56580.320024]  [<ffffffff81050d44>] ? update_process_times+0x31/0x63
> [56580.320024]  [<ffffffff8106791f>] ? tick_sched_timer+0x62/0x7e
> [56580.320024]  [<ffffffff8105e8b4>] ? __run_hrtimer.isra.28+0x52/0xaa
> [56580.320024]  [<ffffffff8105ee8c>] ? hrtimer_interrupt+0xd5/0x1a1
> [56580.320024]  [<ffffffff8100537e>] ? xen_timer_interrupt+0x28/0x159
> [56580.320024]  [<ffffffff81080097>] ? handle_irq_event_percpu+0x24/0x11c
> [56580.320024]  [<ffffffff810824b1>] ? handle_percpu_irq+0x35/0x4c
> [56580.320024]  [<ffffffff811cbe90>] ? __xen_evtchn_do_upcall+0x154/0x1eb
> [56580.320024]  [<ffffffff8100525c>] ? xen_force_evtchn_callback+0x9/0xa
> [56580.320024]  [<ffffffff811cd490>] ? xen_evtchn_do_upcall+0x22/0x32
> [56580.320024]  [<ffffffff812f863e>] ? xen_do_hypervisor_callback+0x1e/0x30
> [56580.320024]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [56580.320024]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [56580.320024]  [<ffffffff811cc7d5>] ? xen_poll_irq_timeout+0x38/0x44
> [56580.320024]  [<ffffffff812ee21f>] ? xen_spin_lock_slow+0x86/0xdf
> [56580.320024]  [<ffffffff8100688a>] ? __xen_spin_lock+0x32/0x3b
> [56580.320024]  [<ffffffff8106bd6a>] ? do_raw_spin_lock+0x5/0x8
> [56580.320024]  [<ffffffffa002badd>] ? 
> find_free_extent.constprop.77+0x495/0x94b [btrfs]
> [56580.320024]  [<ffffffffa00689fe>] ? 
> btrfs_add_delayed_tree_ref+0x77/0x120 [btrfs]
> [56580.320024]  [<ffffffffa002e61b>] ? btrfs_reserve_extent+0xa4/0x148 
> [btrfs]
> [56580.320024]  [<ffffffffa002eadb>] ? btrfs_alloc_free_block+0x15d/0x283 
> [btrfs]
> [56580.320024]  [<ffffffff81005842>] ? check_events+0x12/0x20
> [56580.320024]  [<ffffffffa0021f3a>] ? __btrfs_cow_block+0x102/0x32c [btrfs]
> [56580.320024]  [<ffffffffa0022257>] ? btrfs_cow_block+0xf3/0x102 [btrfs]
> [56580.320024]  [<ffffffffa0024c84>] ? btrfs_search_slot+0x225/0x64e [btrfs]
> [56580.320024]  [<ffffffffa00285f2>] ? 
> lookup_inline_extent_backref+0xa8/0x360 [btrfs]
> [56580.320024]  [<ffffffffa002a35c>] ? __btrfs_free_extent+0xcb/0x5c8 
> [btrfs]
> [56580.320024]  [<ffffffff812f1dac>] ? __slab_free+0xd6/0x206
> [56580.320024]  [<ffffffff810b9c65>] ? arch_local_irq_restore+0x7/0x8
> [56580.320024]  [<ffffffffa002d87e>] ? run_clustered_refs+0x65f/0x6a9 
> [btrfs]
> [56580.320024]  [<ffffffff81177fe4>] ? rb_next+0x39/0x3f
> [56580.320024]  [<ffffffffa002d991>] ? btrfs_run_delayed_refs+0xc9/0x185 
> [btrfs]
> [56580.320024]  [<ffffffff812ee18a>] ? xen_spin_unlock_slow+0x4d/0x5c
> [56580.320024]  [<ffffffffa003b13a>] ? __btrfs_end_transaction+0x90/0x1dd 
> [btrfs]
> [56580.320024]  [<ffffffffa006ff08>] ? 
> btrfs_async_run_delayed_node_done+0xf8/0x156 [btrfs]
> [56580.320024]  [<ffffffffa005a150>] ? worker_loop+0x16a/0x45a [btrfs]
> [56580.320024]  [<ffffffffa0059fe6>] ? btrfs_queue_worker+0x279/0x279 
> [btrfs]
> [56580.320024]  [<ffffffff8105bbba>] ? kthread+0x76/0x7e
> [56580.320024]  [<ffffffff812f84f4>] ? kernel_thread_helper+0x4/0x10
> [56580.320024]  [<ffffffff812f65b3>] ? int_ret_from_sys_call+0x7/0x1b
> [56580.320024]  [<ffffffff812f5cbc>] ? retint_restore_args+0x5/0x6
> [56580.320024]  [<ffffffff812f84f0>] ? gs_change+0x13/0x13
> 
> I had the problem with 3.2, 3.2.1, then 3.2.2. With and without the 
> renaming to 2.6.42.x.
> 
> The Xen version is 4.0.1 (from Debian amd64), and the Dom0 kernel is a 
> 3.1.0 (also from Debian).
> 
> Thanks for any advice,
> 
> Olivier B.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsd4z-0001cB-0r; Wed, 01 Feb 2012 16:30:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rsd4w-0001bh-VX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:30:39 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328113761!62173125!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26997 invoked from network); 1 Feb 2012 16:29:23 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.14)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Feb 2012 16:29:23 -0000
Received: from mail99-tx2-R.bigfish.com (10.9.14.241) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 1 Feb 2012 16:30:30 +0000
Received: from mail99-tx2 (localhost [127.0.0.1])	by mail99-tx2-R.bigfish.com
	(Postfix) with ESMTP id 3CA8E4053B;
	Wed,  1 Feb 2012 16:30:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2
	(MessageSwitch) id 1328113827406676_29722;
	Wed,  1 Feb 2012 16:30:27 +0000 (UTC)
Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.247])	by
	mail99-tx2.bigfish.com (Postfix) with ESMTP id 5E834200049;
	Wed,  1 Feb 2012 16:30:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server id
	14.1.225.23; Wed, 1 Feb 2012 16:30:26 +0000
X-WSS-ID: 0LYQ36N-02-04D-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 2923DC811B;	Wed,  1 Feb 2012 10:30:23 -0600 (CST)
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, 1 Feb 2012 10:30:36 -0600
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.289.1;
	Wed, 1 Feb 2012 10:30:24 -0600
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, 1 Feb 2012
	11:30:23 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 35D1249C078; Wed,  1 Feb 2012
	16:30:22 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 2C0632D202B; Wed,
	1 Feb 2012 17:30:22 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 789bbf4f478b0e81d71240a1f1147ef66a7c8848
Message-ID: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Wed, 1 Feb 2012 17:30:14 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1328108207 -3600
# Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r 789bbf4f478b tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Wed Feb 01 15:56:47 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Feb 01 15:56:47 2012 +0100
@@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +905,61 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+}
+
+void svm_host_osvw_init()
+{
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length = osvw_status = 0;
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +988,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1105,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1176,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1189,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1475,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1606,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Wed Feb 01 15:56:47 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+        ret = microcode_ops->start_update();
+        if ( ret != 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Feb 01 15:56:47 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +341,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } 
+    else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +405,19 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Wed Feb 01 15:56:47 2012 +0100
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /* 
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff -r e2722b24dc09 -r 789bbf4f478b xen/common/domctl.c
--- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/common/domctl.c	Wed Feb 01 15:56:47 2012 +0100
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
+        /* 
+         * Certain operations (e.g. CPU microcode updates) modify data which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                goto maxvcpu_out_novcpulock;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = 0;
 
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
+
+    maxvcpu_out_novcpulock:
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Wed Feb 01 15:56:47 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Wed Feb 01 15:56:47 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Feb 01 15:56:47 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/xen/domain.h
--- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/xen/domain.h	Wed Feb 01 15:56:47 2012 +0100
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
 
 void arch_vcpu_reset(struct vcpu *v);
 
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsd4z-0001cB-0r; Wed, 01 Feb 2012 16:30:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rsd4w-0001bh-VX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:30:39 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328113761!62173125!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26997 invoked from network); 1 Feb 2012 16:29:23 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.14)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	1 Feb 2012 16:29:23 -0000
Received: from mail99-tx2-R.bigfish.com (10.9.14.241) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 1 Feb 2012 16:30:30 +0000
Received: from mail99-tx2 (localhost [127.0.0.1])	by mail99-tx2-R.bigfish.com
	(Postfix) with ESMTP id 3CA8E4053B;
	Wed,  1 Feb 2012 16:30:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2
	(MessageSwitch) id 1328113827406676_29722;
	Wed,  1 Feb 2012 16:30:27 +0000 (UTC)
Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.247])	by
	mail99-tx2.bigfish.com (Postfix) with ESMTP id 5E834200049;
	Wed,  1 Feb 2012 16:30:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server id
	14.1.225.23; Wed, 1 Feb 2012 16:30:26 +0000
X-WSS-ID: 0LYQ36N-02-04D-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 2923DC811B;	Wed,  1 Feb 2012 10:30:23 -0600 (CST)
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, 1 Feb 2012 10:30:36 -0600
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.289.1;
	Wed, 1 Feb 2012 10:30:24 -0600
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, 1 Feb 2012
	11:30:23 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 35D1249C078; Wed,  1 Feb 2012
	16:30:22 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 2C0632D202B; Wed,
	1 Feb 2012 17:30:22 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 789bbf4f478b0e81d71240a1f1147ef66a7c8848
Message-ID: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Wed, 1 Feb 2012 17:30:14 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1328108207 -3600
# Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r 789bbf4f478b tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Wed Feb 01 15:56:47 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Wed Feb 01 15:56:47 2012 +0100
@@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +905,61 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+}
+
+void svm_host_osvw_init()
+{
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length = osvw_status = 0;
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +988,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1105,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1176,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1189,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1475,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1606,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Wed Feb 01 15:56:47 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+        ret = microcode_ops->start_update();
+        if ( ret != 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Feb 01 15:56:47 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +341,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } 
+    else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +405,19 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Wed Feb 01 15:56:47 2012 +0100
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /* 
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff -r e2722b24dc09 -r 789bbf4f478b xen/common/domctl.c
--- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/common/domctl.c	Wed Feb 01 15:56:47 2012 +0100
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
+        /* 
+         * Certain operations (e.g. CPU microcode updates) modify data which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                goto maxvcpu_out_novcpulock;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = 0;
 
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
+
+    maxvcpu_out_novcpulock:
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Wed Feb 01 15:56:47 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Wed Feb 01 15:56:47 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Feb 01 15:56:47 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {
diff -r e2722b24dc09 -r 789bbf4f478b xen/include/xen/domain.h
--- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/xen/domain.h	Wed Feb 01 15:56:47 2012 +0100
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
 
 void arch_vcpu_reset(struct vcpu *v);
 
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsdHL-0001s9-DK; Wed, 01 Feb 2012 16:43:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsdHJ-0001s4-Bv
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:43:25 +0000
Received: from [85.158.138.51:53638] by server-3.bemta-3.messagelabs.com id
	78/35-18959-CAB692F4; Wed, 01 Feb 2012 16:43:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328114603!7381255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3596 invoked from network); 1 Feb 2012 16:43:23 -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;
	1 Feb 2012 16:43:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10420370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16:43:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 16:43:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsdHF-0000CT-V8; Wed, 01 Feb 2012 16:43:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsdHF-0007hz-Td;
	Wed, 01 Feb 2012 16:43:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20265.27561.907043.477902@mariner.uk.xensource.com>
Date: Wed, 1 Feb 2012 16:43:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
References: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[GIT PULL] libxl API updates backlog"):
> I've built up a rather large backlog of patches. Many of them have been
> posted before and acked so rather than spam the list with another big
> mail bomb I am sending as a git pull request a large batch of those
> patches which have been acked.

Thanks.

This one had conflicts:

>       xl: use json output by default

I have applied the rest:

>       libxl: remove libxl_domain_create_info.poolname
>       libxl: name libxl_create_cpupool consistent with other functions
>       libxl: do not write/maintain "pool_name" in XenStore
>       libxl: remove comment support from IDL
>       libxl: use keyword arguments for field definitions in aggregate types
>       ocaml: use libxl IDL type helpers for C argument passing
>       libxl: define libxl_vnc_info to hold all info about the vnc info
>       libxl: define libxl_spice_info to hold all info about the spice server
>       libxl: define libxl_sdl_info to hold all info about the SDL config
>       libxl: plumb libxl_domain_config down into device model creation
>       libxl: now that dm creation takes domain_config stop passing down devices
>       libxl: remove redundant info from dm info
>       libxl: drop dm_info.dom_name
>       libxl: use vfb[0] directly for xenpv device model
>       libxl: move HVM emulated GFX support into b_info->u.hvm
>       libxl: HVM device configuration info build_info->u.hvm
>       libxl: move gfx_passthru setting to b_info->u.hvm
>       libxl: Remove libxl_device_model_info.type
>       libxl: remove uuid from device model info
>       libxl: move device model selection variables to b_info
>       libxl: move "saved_state" to libxl__domain_build_state
>       libxl: remove libxl_device_model_info
>       libxl: only write "disable_pf" key to xenstore when it makes sense
>       libxl: Rename libxl IDL infrastructure
>       libxl: de-hard-tabbify idl.txt
>       libxl: remove libxl_button_press in favour of libxl_send_trigger
>       ocaml: add helpers for Some/None option types
>       ocaml: Topology.get returns an array not a single element
>       libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps
>       libxl: drop libxl_cpuarray -- topology was the only user
>       libxl: add named enum for timer mode
>       docs: document /etc/xen/xl.conf
>       xl: allow enable automatic fallback to ACPI events if PV control not ava

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 16:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 16:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsdHL-0001s9-DK; Wed, 01 Feb 2012 16:43:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsdHJ-0001s4-Bv
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:43:25 +0000
Received: from [85.158.138.51:53638] by server-3.bemta-3.messagelabs.com id
	78/35-18959-CAB692F4; Wed, 01 Feb 2012 16:43:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328114603!7381255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3596 invoked from network); 1 Feb 2012 16:43:23 -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;
	1 Feb 2012 16:43:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="10420370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 16:43:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 16:43:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsdHF-0000CT-V8; Wed, 01 Feb 2012 16:43:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsdHF-0007hz-Td;
	Wed, 01 Feb 2012 16:43:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20265.27561.907043.477902@mariner.uk.xensource.com>
Date: Wed, 1 Feb 2012 16:43:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
References: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[GIT PULL] libxl API updates backlog"):
> I've built up a rather large backlog of patches. Many of them have been
> posted before and acked so rather than spam the list with another big
> mail bomb I am sending as a git pull request a large batch of those
> patches which have been acked.

Thanks.

This one had conflicts:

>       xl: use json output by default

I have applied the rest:

>       libxl: remove libxl_domain_create_info.poolname
>       libxl: name libxl_create_cpupool consistent with other functions
>       libxl: do not write/maintain "pool_name" in XenStore
>       libxl: remove comment support from IDL
>       libxl: use keyword arguments for field definitions in aggregate types
>       ocaml: use libxl IDL type helpers for C argument passing
>       libxl: define libxl_vnc_info to hold all info about the vnc info
>       libxl: define libxl_spice_info to hold all info about the spice server
>       libxl: define libxl_sdl_info to hold all info about the SDL config
>       libxl: plumb libxl_domain_config down into device model creation
>       libxl: now that dm creation takes domain_config stop passing down devices
>       libxl: remove redundant info from dm info
>       libxl: drop dm_info.dom_name
>       libxl: use vfb[0] directly for xenpv device model
>       libxl: move HVM emulated GFX support into b_info->u.hvm
>       libxl: HVM device configuration info build_info->u.hvm
>       libxl: move gfx_passthru setting to b_info->u.hvm
>       libxl: Remove libxl_device_model_info.type
>       libxl: remove uuid from device model info
>       libxl: move device model selection variables to b_info
>       libxl: move "saved_state" to libxl__domain_build_state
>       libxl: remove libxl_device_model_info
>       libxl: only write "disable_pf" key to xenstore when it makes sense
>       libxl: Rename libxl IDL infrastructure
>       libxl: de-hard-tabbify idl.txt
>       libxl: remove libxl_button_press in favour of libxl_send_trigger
>       ocaml: add helpers for Some/None option types
>       ocaml: Topology.get returns an array not a single element
>       libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps
>       libxl: drop libxl_cpuarray -- topology was the only user
>       libxl: add named enum for timer mode
>       docs: document /etc/xen/xl.conf
>       xl: allow enable automatic fallback to ACPI events if PV control not ava

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:00:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17: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.xensource.com>)
	id 1RsdX7-0002Ym-52; Wed, 01 Feb 2012 16:59:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RsdX5-0002Yh-CQ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:59:43 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328115575!8841873!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2306 invoked from network); 1 Feb 2012 16:59:37 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:59:37 -0000
Received: by dadp13 with SMTP id p13so1317098dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 08:59:34 -0800 (PST)
Received: by 10.68.218.104 with SMTP id pf8mr60828095pbc.24.1328115574915;
	Wed, 01 Feb 2012 08:59:34 -0800 (PST)
Received: from [25.66.133.92] ([74.198.150.220])
	by mx.google.com with ESMTPS id j4sm64533045pbg.12.2012.02.01.08.59.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 08:59:33 -0800 (PST)
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
	<3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
	<alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <B8188828-852E-45F6-B28A-5AE6CDF68602@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 08:59:27 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: AnthonyPerard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
	QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-01, at 6:14 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Wed, 1 Feb 2012, rshriram@cs.ubc.ca wrote:
>> # HG changeset patch
>> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> # Date 1328070813 28800
>> # Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
>> # Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
>> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
>> 
>> Implement QMP stop and resume functionality and split
>> device model save into 3 parts:
>> suspend_dm(domid)
>> save_dm(domid, fd)
>> resume_dm(domid)
>> 
>> Integrate Device model suspend into suspend_common_callback
>> 
>> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> 
>> diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
>> --- a/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
>> +++ b/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
>> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
>>     return rc ? 0 : 1;
>> }
>> 
>> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
>> +{
>> +    libxl_ctx *ctx = libxl__gc_owner(gc);
>> +    int ret = 0, fd2 = -1;
>> +    const char *filename = libxl__device_model_savefile(gc, domid);
>> +
>> +    switch (libxl__device_model_version_running(gc, domid)) {
>> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
>> +                   "Saving device model state to %s", filename);
>> +        libxl__qemu_traditional_cmd(gc, domid, "save");
>> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
>> +        break;
>> +    }
>> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>> +        if (libxl__qmp_stop(gc, domid))
>> +            return ERROR_FAIL;
>> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
>> +        if (fd2 < 0) {
>> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>> +                             "Unable to create a QEMU save file\n");
>> +            return ERROR_FAIL;
>> +        }
>> +        /* Save DM state into fd2 */
>> +        ret = libxl__qmp_migrate(gc, domid, fd2);
>> +        if (ret)
>> +            unlink(filename);
>> +        close(fd2);
>> +        fd2 = -1;
>> +        break;
>> +    default:
>> +        return ERROR_INVAL;
>> +    }
>> +
> 
> Why do you need to introduce libxl__qmp_stop and libxl__qmp_resume?
> 
> Also keep in mind that I am about to change the command sent to save the
> state of devices to "save_devices" because "migrate" is not working
> properly with Xen.
> 

I was modeling the qmp stuff similar to the old style qemu. 

Please correct me if I am wrong. Until qmp_migrate, qemu could still be writing data to the guest's memory right? 

So, I thought qmp_stop was a sure shot way to ensure such stuff is not happening under the hood. 

With qmp_stop came qmp_resume.



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:00:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17: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.xensource.com>)
	id 1RsdX7-0002Ym-52; Wed, 01 Feb 2012 16:59:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RsdX5-0002Yh-CQ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 16:59:43 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328115575!8841873!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2306 invoked from network); 1 Feb 2012 16:59:37 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 16:59:37 -0000
Received: by dadp13 with SMTP id p13so1317098dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 08:59:34 -0800 (PST)
Received: by 10.68.218.104 with SMTP id pf8mr60828095pbc.24.1328115574915;
	Wed, 01 Feb 2012 08:59:34 -0800 (PST)
Received: from [25.66.133.92] ([74.198.150.220])
	by mx.google.com with ESMTPS id j4sm64533045pbg.12.2012.02.01.08.59.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 08:59:33 -0800 (PST)
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
	<3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
	<alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <B8188828-852E-45F6-B28A-5AE6CDF68602@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 08:59:27 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: AnthonyPerard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
	QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-01, at 6:14 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Wed, 1 Feb 2012, rshriram@cs.ubc.ca wrote:
>> # HG changeset patch
>> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> # Date 1328070813 28800
>> # Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
>> # Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
>> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
>> 
>> Implement QMP stop and resume functionality and split
>> device model save into 3 parts:
>> suspend_dm(domid)
>> save_dm(domid, fd)
>> resume_dm(domid)
>> 
>> Integrate Device model suspend into suspend_common_callback
>> 
>> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> 
>> diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
>> --- a/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
>> +++ b/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
>> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
>>     return rc ? 0 : 1;
>> }
>> 
>> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
>> +{
>> +    libxl_ctx *ctx = libxl__gc_owner(gc);
>> +    int ret = 0, fd2 = -1;
>> +    const char *filename = libxl__device_model_savefile(gc, domid);
>> +
>> +    switch (libxl__device_model_version_running(gc, domid)) {
>> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
>> +                   "Saving device model state to %s", filename);
>> +        libxl__qemu_traditional_cmd(gc, domid, "save");
>> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
>> +        break;
>> +    }
>> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>> +        if (libxl__qmp_stop(gc, domid))
>> +            return ERROR_FAIL;
>> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
>> +        if (fd2 < 0) {
>> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>> +                             "Unable to create a QEMU save file\n");
>> +            return ERROR_FAIL;
>> +        }
>> +        /* Save DM state into fd2 */
>> +        ret = libxl__qmp_migrate(gc, domid, fd2);
>> +        if (ret)
>> +            unlink(filename);
>> +        close(fd2);
>> +        fd2 = -1;
>> +        break;
>> +    default:
>> +        return ERROR_INVAL;
>> +    }
>> +
> 
> Why do you need to introduce libxl__qmp_stop and libxl__qmp_resume?
> 
> Also keep in mind that I am about to change the command sent to save the
> state of devices to "save_devices" because "migrate" is not working
> properly with Xen.
> 

I was modeling the qmp stuff similar to the old style qemu. 

Please correct me if I am wrong. Until qmp_migrate, qemu could still be writing data to the guest's memory right? 

So, I thought qmp_stop was a sure shot way to ensure such stuff is not happening under the hood. 

With qmp_stop came qmp_resume.



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:22:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17: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.xensource.com>)
	id 1RsdsM-0003DW-Oc; Wed, 01 Feb 2012 17:21:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsdsL-0003DR-3X
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 17:21:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328116895!9678506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1234 invoked from network); 1 Feb 2012 17:21:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 17:21:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10421189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 17:21:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	17:21:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 17:21:34 +0000
In-Reply-To: <20265.27561.907043.477902@mariner.uk.xensource.com>
References: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
	<20265.27561.907043.477902@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328116894.17444.99.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 16:43 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[GIT PULL] libxl API updates backlog"):
> > I've built up a rather large backlog of patches. Many of them have been
> > posted before and acked so rather than spam the list with another big
> > mail bomb I am sending as a git pull request a large batch of those
> > patches which have been acked.
> 
> Thanks.
> 
> This one had conflicts:
> 
> >       xl: use json output by default

Rebased version below.

> I have applied the rest:

Thanks!

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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328115855 0
# Node ID 5926f25e1d8a847ad3dc74ab9bc582b365f352ec
# Parent  512bd9cd537d3846a12eebc255760fa7a2064a86
xl: use json output by default

Move the sxp producing code off into a separate file. It is supported
for legacy reasons and needn't be updated other than the improve
compatibility with xm.

libxl_domain_config is not currently generated by the IDL (adding the
necessary support for Array types is on my to do list) so hand code
the json generation function for now.

Since this rather directly exposes a libxl data structure it's not
clear what sort of forward compatibility guarantees we can
make. However it seems like it should be as stable as libxl's own API
(which we are looking to stabilise)

(Gratuitous string.h include needed for memset in libxl_util.h)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
[since last version -- update xendomains script patch merged in]

diff -r 512bd9cd537d -r 5926f25e1d8a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Feb 01 17:03:45 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Feb 01 17:04:15 2012 +0000
@@ -219,7 +219,7 @@ B<OPTIONS>
 =item B<-l>, B<--long>
 
 The output for B<xl list> is not the table view shown below, but 
-instead presents the data in SXP compatible format.
+instead presents the data in as a JSON data structure.
 
 =item B<-Z>, B<--context>
 Also prints the security labels.
diff -r 512bd9cd537d -r 5926f25e1d8a tools/hotplug/Linux/init.d/xendomains
--- a/tools/hotplug/Linux/init.d/xendomains	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/hotplug/Linux/init.d/xendomains	Wed Feb 01 17:04:15 2012 +0000
@@ -202,15 +202,20 @@ rdnames()
     done
 }
 
+LIST_GREP='((domain\|(domid\|(name\|^{$\|"name":\|"domid":'
 parseln()
 {
-    if [[ "$1" =~ '(domain' ]]; then
+    if [[ "$1" =~ '(domain' ]] || [[ "$1" = "{" ]]; then
         name=;id=
-    else if [[ "$1" =~ '(name' ]]; then
+    elif [[ "$1" =~ '(name' ]]; then
         name=$(echo $1 | sed -e 's/^.*(name \(.*\))$/\1/')
-    else if [[ "$1" =~ '(domid' ]]; then
+    elif [[ "$1" =~ '(domid' ]]; then
         id=$(echo $1 | sed -e 's/^.*(domid \(.*\))$/\1/')
-    fi; fi; fi
+    elif [[ "$1" =~ '"name":' ]]; then
+        name=$(echo $1 | sed -e 's/^.*"name": "\(.*\)",$/\1/')
+    elif [[ "$1" =~ '"domid":' ]]; then
+        id=$(echo $1 | sed -e 's/^.*"domid": \(.*\),$/\1/')
+    fi
 
     [ -n "$name" -a -n "$id" ] && return 0 || return 1
 }
@@ -228,7 +233,7 @@ is_running()
 		RC=0
 		;;
 	esac
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
     return $RC
 }
 
@@ -310,7 +315,7 @@ all_zombies()
 	if test "$state" != "-b---d" -a "$state" != "-----d"; then
 	    return 1;
 	fi
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
     return 0
 }
 
@@ -441,7 +446,7 @@ stop()
 	    fi
 	    kill $WDOG_PID >/dev/null 2>&1
 	fi
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
 
     # NB. this shuts down ALL Xen domains (politely), not just the ones in
     # AUTODIR/*
@@ -478,7 +483,7 @@ check_domain_up()
 		return 0
 		;;
 	esac
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
     return 1
 }
 
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/Makefile	Wed Feb 01 17:04:15 2012 +0000
@@ -66,7 +66,7 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_
 
 CLIENTS = xl testidl
 
-XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o
+XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Feb 01 17:04:15 2012 +0000
@@ -130,6 +130,7 @@
 #include <stdbool.h>
 #include <stdint.h>
 #include <stdarg.h>
+#include <string.h>
 #include <errno.h>
 #include <netinet/in.h>
 #include <sys/wait.h> /* for pid_t */
@@ -304,6 +305,7 @@ typedef struct {
     libxl_action_on_shutdown on_watchdog;
     libxl_action_on_shutdown on_crash;
 } libxl_domain_config;
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p);
 
 /* context functions */
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/libxl_json.c	Wed Feb 01 17:04:15 2012 +0000
@@ -843,6 +843,158 @@ out:
     return ret;
 }
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p)
+{
+    yajl_gen_status s;
+    int i;
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"c_info",
+                        sizeof("c_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_create_info_gen_json(hand, &p->c_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"b_info",
+                        sizeof("b_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_build_info_gen_json(hand, &p->b_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"disks",
+                        sizeof("disks")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_disks; i++) {
+        s = libxl_device_disk_gen_json(hand, &p->disks[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vifs",
+                        sizeof("vifs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vifs; i++) {
+        s = libxl_device_nic_gen_json(hand, &p->vifs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"pcidevs",
+                        sizeof("pcidevs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_pcidevs; i++) {
+        s = libxl_device_pci_gen_json(hand, &p->pcidevs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vfbs",
+                        sizeof("vfbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vfbs; i++) {
+        s = libxl_device_vfb_gen_json(hand, &p->vfbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vkbs",
+                        sizeof("vkbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vkbs; i++) {
+        s = libxl_device_vkb_gen_json(hand, &p->vkbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_poweroff",
+                        sizeof("on_poweroff")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_poweroff);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_reboot",
+                        sizeof("on_reboot")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_reboot);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_watchdog",
+                        sizeof("on_watchdog")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_watchdog);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_crash",
+                        sizeof("on_crash")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_crash);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    out:
+    return s;
+}
+
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p)
+{
+    return libxl__object_to_json(ctx, "libxl_domain_config",
+                        (libxl__gen_json_callback)&libxl_domain_config_gen_json,
+                        (void *)p);
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/libxl_json.h	Wed Feb 01 17:04:15 2012 +0000
@@ -70,4 +70,7 @@ static inline yajl_gen libxl__yajl_gen_a
 
 #endif /* !HAVE_YAJL_V2 */
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p);
+
 #endif /* LIBXL_JSON_H */
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl.c
--- a/tools/libxl/xl.c	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/xl.c	Wed Feb 01 17:04:15 2012 +0000
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 
@@ -78,6 +79,15 @@ static void parse_global_config(const ch
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
+    if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
+        if (!strcmp(buf, "json"))
+            default_output_format = OUTPUT_FORMAT_JSON;
+        else if (!strcmp(buf, "sxp"))
+            default_output_format = OUTPUT_FORMAT_SXP;
+        else {
+            fprintf(stderr, "invalid default output format \"%s\"\n", buf);
+        }
+    }
     xlu_cfg_destroy(config);
 }
 
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl.h
--- a/tools/libxl/xl.h	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/xl.h	Wed Feb 01 17:04:15 2012 +0000
@@ -111,6 +111,14 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 
+enum output_format {
+    OUTPUT_FORMAT_JSON,
+    OUTPUT_FORMAT_SXP,
+};
+extern enum output_format default_output_format;
+
+extern void printf_info_sexp(int domid, libxl_domain_config *d_config);
+
 #endif /* XL_H */
 
 /*
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 01 17:04:15 2012 +0000
@@ -38,6 +38,7 @@
 
 #include "libxl.h"
 #include "libxl_utils.h"
+#include "libxl_json.h"
 #include "libxlutil.h"
 #include "xl.h"
 
@@ -289,187 +290,66 @@ static void dolog(const char *file, int 
     free(s);
 }
 
-static void printf_info(int domid,
+static void printf_info(enum output_format output_format,
+                        int domid,
                         libxl_domain_config *d_config)
 {
-    int i;
-    libxl_dominfo info;
-
-    libxl_domain_create_info *c_info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    printf("(domain\n\t(domid %d)\n", domid);
-    printf("\t(create_info)\n");
-    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
-    printf("\t(ssidref %d)\n", c_info->ssidref);
-    printf("\t(name %s)\n", c_info->name);
-
-    /* retrieve the UUID from dominfo, since it is probably generated
-     * during parsing and thus does not match the real one
-     */
-    if (libxl_domain_info(ctx, &info, domid) == 0) {
-        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
-    } else {
-        printf("\t(uuid <unknown>)\n");
-    }
-
-    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
-    if (c_info->xsdata)
-        printf("\t(xsdata contains data)\n");
+    if (output_format == OUTPUT_FORMAT_SXP)
+        return printf_info_sexp(domid, d_config);
+
+    yajl_gen_config conf = { 1, "    " };
+    const char *buf;
+    unsigned int len = 0;
+    yajl_gen_status s;
+    yajl_gen hand;
+
+    hand = yajl_gen_alloc(&conf, NULL);
+    if (!hand) {
+        fprintf(stderr, "unable to allocate JSON generator\n");
+        return;
+    }
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"domid",
+                        sizeof("domid")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    if (domid != -1)
+        s = yajl_gen_integer(hand, domid);
     else
-        printf("\t(xsdata (null))\n");
-    if (c_info->platformdata)
-        printf("\t(platformdata contains data)\n");
-    else
-        printf("\t(platformdata (null))\n");
-
-
-    printf("\t(build_info)\n");
-    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", 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");
-            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
-                printf(" %s", b_info->u.pv.bootloader_args[i]);
-            printf(")\n");
-        }
-    }
-
-    printf("\t(image\n");
-    switch (c_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        printf("\t\t(hvm\n");
-        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
-        printf("\t\t\t(timer_mode %s)\n",
-               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
-        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
-
-        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
-        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
-        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
-        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
-        printf("\t\t)\n");
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        printf("\t\t(linux %d)\n", 0);
-        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
-        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
-        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
-        printf("\t\t)\n");
-        break;
-    default:
-        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
-        exit(1);
-    }
-    printf("\t)\n");
-
-    for (i = 0; i < d_config->num_disks; i++) {
-        printf("\t(device\n");
-        printf("\t\t(tap\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
-        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
-        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
-        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
-        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
-        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vifs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vif\n");
-        if (d_config->vifs[i].ifname)
-            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
-        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
-        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
-        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
-        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
-               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
-               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
-               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_pcidevs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(pci\n");
-        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
-               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
-               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
-               d_config->pcidevs[i].vdevfn);
-        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
-               d_config->pcidevs[i].msitranslate,
-               d_config->pcidevs[i].power_mgmt);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vfbs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vfb\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-    printf(")\n");
+        s = yajl_gen_null(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"config",
+                        sizeof("config")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_config_gen_json(hand, d_config);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_get_buf(hand, (const unsigned char **)&buf, &len);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    puts(buf);
+
+out:
+    yajl_gen_free(hand);
+
+    if (s != yajl_gen_status_ok)
+        fprintf(stderr,
+                "unable to format domain config as JSON (YAJL:%d)\n", s);
+
+    if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
 }
 
 static int parse_action_on_shutdown(const char *buf, libxl_action_on_shutdown *a)
@@ -682,7 +562,7 @@ static void parse_config_data(const char
         c_info->hap = l;
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
-        fprintf(stderr, "Domain name must be specified.");
+        fprintf(stderr, "Domain name must be specified.\n");
         exit(1);
     }
 
@@ -1723,7 +1603,7 @@ static int create_domain(struct domain_c
             dom_info->no_incr_generationid;
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config);
+        printf_info(default_output_format, -1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -2525,7 +2405,7 @@ static void list_domains_details(const l
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
         parse_config_data(config_file, (char *)data, len, &d_config);
-        printf_info(info[i].domid, &d_config);
+        printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl_sxp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/xl_sxp.c	Wed Feb 01 17:04:15 2012 +0000
@@ -0,0 +1,220 @@
+/*
+ * Copyright (C) 2009      Citrix Ltd.
+ * Author Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * Legacy SXP output handling
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+
+#include "libxl.h"
+#include "libxl_utils.h"
+#include "xl.h"
+
+/* In general you should not add new output to this function since it
+ * is intended only for legacy use.
+ */
+void printf_info_sexp(int domid, libxl_domain_config *d_config)
+{
+    int i;
+    libxl_dominfo info;
+
+    libxl_domain_create_info *c_info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    printf("(domain\n\t(domid %d)\n", domid);
+    printf("\t(create_info)\n");
+    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
+    printf("\t(hap %d)\n", c_info->hap);
+    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(ssidref %d)\n", c_info->ssidref);
+    printf("\t(name %s)\n", c_info->name);
+
+    /* retrieve the UUID from dominfo, since it is probably generated
+     * during parsing and thus does not match the real one
+     */
+    if (libxl_domain_info(ctx, &info, domid) == 0) {
+        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+    } else {
+        printf("\t(uuid <unknown>)\n");
+    }
+
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
+    if (c_info->xsdata)
+        printf("\t(xsdata contains data)\n");
+    else
+        printf("\t(xsdata (null))\n");
+    if (c_info->platformdata)
+        printf("\t(platformdata contains data)\n");
+    else
+        printf("\t(platformdata (null))\n");
+
+
+    printf("\t(build_info)\n");
+    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
+    printf("\t(max_memkb %d)\n", b_info->max_memkb);
+    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(nomigrate %d)\n", 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");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
+    }
+
+    printf("\t(image\n");
+    switch (c_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        printf("\t\t(hvm\n");
+        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
+        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
+        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
+        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
+        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
+        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
+        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
+        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
+        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
+
+        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
+        printf("\t\t)\n");
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        printf("\t\t(linux %d)\n", 0);
+        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
+        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
+        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
+        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t)\n");
+        break;
+    default:
+        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
+        exit(1);
+    }
+    printf("\t)\n");
+
+    for (i = 0; i < d_config->num_disks; i++) {
+        printf("\t(device\n");
+        printf("\t\t(tap\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
+        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
+        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
+        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
+        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
+        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vifs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vif\n");
+        if (d_config->vifs[i].ifname)
+            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
+        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
+        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
+        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
+        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
+               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
+               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
+               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_pcidevs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(pci\n");
+        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
+               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
+               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
+               d_config->pcidevs[i].vdevfn);
+        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
+               d_config->pcidevs[i].msitranslate,
+               d_config->pcidevs[i].power_mgmt);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vfbs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vfb\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+    printf(")\n");
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */




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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:22:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17: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.xensource.com>)
	id 1RsdsM-0003DW-Oc; Wed, 01 Feb 2012 17:21:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsdsL-0003DR-3X
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 17:21:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328116895!9678506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1234 invoked from network); 1 Feb 2012 17:21:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 17:21:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10421189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 17:21:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Feb 2012
	17:21:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 17:21:34 +0000
In-Reply-To: <20265.27561.907043.477902@mariner.uk.xensource.com>
References: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
	<20265.27561.907043.477902@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328116894.17444.99.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 16:43 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[GIT PULL] libxl API updates backlog"):
> > I've built up a rather large backlog of patches. Many of them have been
> > posted before and acked so rather than spam the list with another big
> > mail bomb I am sending as a git pull request a large batch of those
> > patches which have been acked.
> 
> Thanks.
> 
> This one had conflicts:
> 
> >       xl: use json output by default

Rebased version below.

> I have applied the rest:

Thanks!

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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328115855 0
# Node ID 5926f25e1d8a847ad3dc74ab9bc582b365f352ec
# Parent  512bd9cd537d3846a12eebc255760fa7a2064a86
xl: use json output by default

Move the sxp producing code off into a separate file. It is supported
for legacy reasons and needn't be updated other than the improve
compatibility with xm.

libxl_domain_config is not currently generated by the IDL (adding the
necessary support for Array types is on my to do list) so hand code
the json generation function for now.

Since this rather directly exposes a libxl data structure it's not
clear what sort of forward compatibility guarantees we can
make. However it seems like it should be as stable as libxl's own API
(which we are looking to stabilise)

(Gratuitous string.h include needed for memset in libxl_util.h)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
[since last version -- update xendomains script patch merged in]

diff -r 512bd9cd537d -r 5926f25e1d8a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Feb 01 17:03:45 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Feb 01 17:04:15 2012 +0000
@@ -219,7 +219,7 @@ B<OPTIONS>
 =item B<-l>, B<--long>
 
 The output for B<xl list> is not the table view shown below, but 
-instead presents the data in SXP compatible format.
+instead presents the data in as a JSON data structure.
 
 =item B<-Z>, B<--context>
 Also prints the security labels.
diff -r 512bd9cd537d -r 5926f25e1d8a tools/hotplug/Linux/init.d/xendomains
--- a/tools/hotplug/Linux/init.d/xendomains	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/hotplug/Linux/init.d/xendomains	Wed Feb 01 17:04:15 2012 +0000
@@ -202,15 +202,20 @@ rdnames()
     done
 }
 
+LIST_GREP='((domain\|(domid\|(name\|^{$\|"name":\|"domid":'
 parseln()
 {
-    if [[ "$1" =~ '(domain' ]]; then
+    if [[ "$1" =~ '(domain' ]] || [[ "$1" = "{" ]]; then
         name=;id=
-    else if [[ "$1" =~ '(name' ]]; then
+    elif [[ "$1" =~ '(name' ]]; then
         name=$(echo $1 | sed -e 's/^.*(name \(.*\))$/\1/')
-    else if [[ "$1" =~ '(domid' ]]; then
+    elif [[ "$1" =~ '(domid' ]]; then
         id=$(echo $1 | sed -e 's/^.*(domid \(.*\))$/\1/')
-    fi; fi; fi
+    elif [[ "$1" =~ '"name":' ]]; then
+        name=$(echo $1 | sed -e 's/^.*"name": "\(.*\)",$/\1/')
+    elif [[ "$1" =~ '"domid":' ]]; then
+        id=$(echo $1 | sed -e 's/^.*"domid": \(.*\),$/\1/')
+    fi
 
     [ -n "$name" -a -n "$id" ] && return 0 || return 1
 }
@@ -228,7 +233,7 @@ is_running()
 		RC=0
 		;;
 	esac
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
     return $RC
 }
 
@@ -310,7 +315,7 @@ all_zombies()
 	if test "$state" != "-b---d" -a "$state" != "-----d"; then
 	    return 1;
 	fi
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
     return 0
 }
 
@@ -441,7 +446,7 @@ stop()
 	    fi
 	    kill $WDOG_PID >/dev/null 2>&1
 	fi
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
 
     # NB. this shuts down ALL Xen domains (politely), not just the ones in
     # AUTODIR/*
@@ -478,7 +483,7 @@ check_domain_up()
 		return 0
 		;;
 	esac
-    done < <($CMD list -l | grep '(\(domain\|domid\|name\)')
+    done < <($CMD list -l | grep $LIST_GREP)
     return 1
 }
 
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/Makefile	Wed Feb 01 17:04:15 2012 +0000
@@ -66,7 +66,7 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_
 
 CLIENTS = xl testidl
 
-XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o
+XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Feb 01 17:04:15 2012 +0000
@@ -130,6 +130,7 @@
 #include <stdbool.h>
 #include <stdint.h>
 #include <stdarg.h>
+#include <string.h>
 #include <errno.h>
 #include <netinet/in.h>
 #include <sys/wait.h> /* for pid_t */
@@ -304,6 +305,7 @@ typedef struct {
     libxl_action_on_shutdown on_watchdog;
     libxl_action_on_shutdown on_crash;
 } libxl_domain_config;
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p);
 
 /* context functions */
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/libxl_json.c	Wed Feb 01 17:04:15 2012 +0000
@@ -843,6 +843,158 @@ out:
     return ret;
 }
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p)
+{
+    yajl_gen_status s;
+    int i;
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"c_info",
+                        sizeof("c_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_create_info_gen_json(hand, &p->c_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"b_info",
+                        sizeof("b_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_build_info_gen_json(hand, &p->b_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"disks",
+                        sizeof("disks")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_disks; i++) {
+        s = libxl_device_disk_gen_json(hand, &p->disks[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vifs",
+                        sizeof("vifs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vifs; i++) {
+        s = libxl_device_nic_gen_json(hand, &p->vifs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"pcidevs",
+                        sizeof("pcidevs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_pcidevs; i++) {
+        s = libxl_device_pci_gen_json(hand, &p->pcidevs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vfbs",
+                        sizeof("vfbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vfbs; i++) {
+        s = libxl_device_vfb_gen_json(hand, &p->vfbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vkbs",
+                        sizeof("vkbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vkbs; i++) {
+        s = libxl_device_vkb_gen_json(hand, &p->vkbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_poweroff",
+                        sizeof("on_poweroff")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_poweroff);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_reboot",
+                        sizeof("on_reboot")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_reboot);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_watchdog",
+                        sizeof("on_watchdog")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_watchdog);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_crash",
+                        sizeof("on_crash")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_crash);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    out:
+    return s;
+}
+
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p)
+{
+    return libxl__object_to_json(ctx, "libxl_domain_config",
+                        (libxl__gen_json_callback)&libxl_domain_config_gen_json,
+                        (void *)p);
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/libxl_json.h	Wed Feb 01 17:04:15 2012 +0000
@@ -70,4 +70,7 @@ static inline yajl_gen libxl__yajl_gen_a
 
 #endif /* !HAVE_YAJL_V2 */
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p);
+
 #endif /* LIBXL_JSON_H */
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl.c
--- a/tools/libxl/xl.c	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/xl.c	Wed Feb 01 17:04:15 2012 +0000
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 
@@ -78,6 +79,15 @@ static void parse_global_config(const ch
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
+    if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
+        if (!strcmp(buf, "json"))
+            default_output_format = OUTPUT_FORMAT_JSON;
+        else if (!strcmp(buf, "sxp"))
+            default_output_format = OUTPUT_FORMAT_SXP;
+        else {
+            fprintf(stderr, "invalid default output format \"%s\"\n", buf);
+        }
+    }
     xlu_cfg_destroy(config);
 }
 
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl.h
--- a/tools/libxl/xl.h	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/xl.h	Wed Feb 01 17:04:15 2012 +0000
@@ -111,6 +111,14 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 
+enum output_format {
+    OUTPUT_FORMAT_JSON,
+    OUTPUT_FORMAT_SXP,
+};
+extern enum output_format default_output_format;
+
+extern void printf_info_sexp(int domid, libxl_domain_config *d_config);
+
 #endif /* XL_H */
 
 /*
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 01 17:03:45 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 01 17:04:15 2012 +0000
@@ -38,6 +38,7 @@
 
 #include "libxl.h"
 #include "libxl_utils.h"
+#include "libxl_json.h"
 #include "libxlutil.h"
 #include "xl.h"
 
@@ -289,187 +290,66 @@ static void dolog(const char *file, int 
     free(s);
 }
 
-static void printf_info(int domid,
+static void printf_info(enum output_format output_format,
+                        int domid,
                         libxl_domain_config *d_config)
 {
-    int i;
-    libxl_dominfo info;
-
-    libxl_domain_create_info *c_info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    printf("(domain\n\t(domid %d)\n", domid);
-    printf("\t(create_info)\n");
-    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
-    printf("\t(ssidref %d)\n", c_info->ssidref);
-    printf("\t(name %s)\n", c_info->name);
-
-    /* retrieve the UUID from dominfo, since it is probably generated
-     * during parsing and thus does not match the real one
-     */
-    if (libxl_domain_info(ctx, &info, domid) == 0) {
-        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
-    } else {
-        printf("\t(uuid <unknown>)\n");
-    }
-
-    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
-    if (c_info->xsdata)
-        printf("\t(xsdata contains data)\n");
+    if (output_format == OUTPUT_FORMAT_SXP)
+        return printf_info_sexp(domid, d_config);
+
+    yajl_gen_config conf = { 1, "    " };
+    const char *buf;
+    unsigned int len = 0;
+    yajl_gen_status s;
+    yajl_gen hand;
+
+    hand = yajl_gen_alloc(&conf, NULL);
+    if (!hand) {
+        fprintf(stderr, "unable to allocate JSON generator\n");
+        return;
+    }
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"domid",
+                        sizeof("domid")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    if (domid != -1)
+        s = yajl_gen_integer(hand, domid);
     else
-        printf("\t(xsdata (null))\n");
-    if (c_info->platformdata)
-        printf("\t(platformdata contains data)\n");
-    else
-        printf("\t(platformdata (null))\n");
-
-
-    printf("\t(build_info)\n");
-    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", 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");
-            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
-                printf(" %s", b_info->u.pv.bootloader_args[i]);
-            printf(")\n");
-        }
-    }
-
-    printf("\t(image\n");
-    switch (c_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        printf("\t\t(hvm\n");
-        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
-        printf("\t\t\t(timer_mode %s)\n",
-               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
-        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
-
-        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
-        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
-        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
-        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
-        printf("\t\t)\n");
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        printf("\t\t(linux %d)\n", 0);
-        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
-        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
-        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
-        printf("\t\t)\n");
-        break;
-    default:
-        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
-        exit(1);
-    }
-    printf("\t)\n");
-
-    for (i = 0; i < d_config->num_disks; i++) {
-        printf("\t(device\n");
-        printf("\t\t(tap\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
-        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
-        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
-        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
-        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
-        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vifs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vif\n");
-        if (d_config->vifs[i].ifname)
-            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
-        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
-        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
-        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
-        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
-               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
-               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
-               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_pcidevs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(pci\n");
-        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
-               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
-               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
-               d_config->pcidevs[i].vdevfn);
-        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
-               d_config->pcidevs[i].msitranslate,
-               d_config->pcidevs[i].power_mgmt);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vfbs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vfb\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-    printf(")\n");
+        s = yajl_gen_null(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"config",
+                        sizeof("config")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_config_gen_json(hand, d_config);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_get_buf(hand, (const unsigned char **)&buf, &len);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    puts(buf);
+
+out:
+    yajl_gen_free(hand);
+
+    if (s != yajl_gen_status_ok)
+        fprintf(stderr,
+                "unable to format domain config as JSON (YAJL:%d)\n", s);
+
+    if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
 }
 
 static int parse_action_on_shutdown(const char *buf, libxl_action_on_shutdown *a)
@@ -682,7 +562,7 @@ static void parse_config_data(const char
         c_info->hap = l;
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
-        fprintf(stderr, "Domain name must be specified.");
+        fprintf(stderr, "Domain name must be specified.\n");
         exit(1);
     }
 
@@ -1723,7 +1603,7 @@ static int create_domain(struct domain_c
             dom_info->no_incr_generationid;
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config);
+        printf_info(default_output_format, -1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -2525,7 +2405,7 @@ static void list_domains_details(const l
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
         parse_config_data(config_file, (char *)data, len, &d_config);
-        printf_info(info[i].domid, &d_config);
+        printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);
diff -r 512bd9cd537d -r 5926f25e1d8a tools/libxl/xl_sxp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/xl_sxp.c	Wed Feb 01 17:04:15 2012 +0000
@@ -0,0 +1,220 @@
+/*
+ * Copyright (C) 2009      Citrix Ltd.
+ * Author Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * Legacy SXP output handling
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+
+#include "libxl.h"
+#include "libxl_utils.h"
+#include "xl.h"
+
+/* In general you should not add new output to this function since it
+ * is intended only for legacy use.
+ */
+void printf_info_sexp(int domid, libxl_domain_config *d_config)
+{
+    int i;
+    libxl_dominfo info;
+
+    libxl_domain_create_info *c_info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    printf("(domain\n\t(domid %d)\n", domid);
+    printf("\t(create_info)\n");
+    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
+    printf("\t(hap %d)\n", c_info->hap);
+    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(ssidref %d)\n", c_info->ssidref);
+    printf("\t(name %s)\n", c_info->name);
+
+    /* retrieve the UUID from dominfo, since it is probably generated
+     * during parsing and thus does not match the real one
+     */
+    if (libxl_domain_info(ctx, &info, domid) == 0) {
+        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+    } else {
+        printf("\t(uuid <unknown>)\n");
+    }
+
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
+    if (c_info->xsdata)
+        printf("\t(xsdata contains data)\n");
+    else
+        printf("\t(xsdata (null))\n");
+    if (c_info->platformdata)
+        printf("\t(platformdata contains data)\n");
+    else
+        printf("\t(platformdata (null))\n");
+
+
+    printf("\t(build_info)\n");
+    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
+    printf("\t(max_memkb %d)\n", b_info->max_memkb);
+    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(nomigrate %d)\n", 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");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
+    }
+
+    printf("\t(image\n");
+    switch (c_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        printf("\t\t(hvm\n");
+        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
+        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
+        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
+        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
+        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
+        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
+        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
+        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
+        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
+
+        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
+        printf("\t\t)\n");
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        printf("\t\t(linux %d)\n", 0);
+        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
+        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
+        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
+        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t)\n");
+        break;
+    default:
+        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
+        exit(1);
+    }
+    printf("\t)\n");
+
+    for (i = 0; i < d_config->num_disks; i++) {
+        printf("\t(device\n");
+        printf("\t\t(tap\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
+        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
+        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
+        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
+        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
+        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vifs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vif\n");
+        if (d_config->vifs[i].ifname)
+            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
+        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
+        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
+        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
+        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
+               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
+               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
+               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_pcidevs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(pci\n");
+        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
+               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
+               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
+               d_config->pcidevs[i].vdevfn);
+        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
+               d_config->pcidevs[i].msitranslate,
+               d_config->pcidevs[i].power_mgmt);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vfbs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vfb\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+    printf(")\n");
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */




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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:36:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rse6Y-0003R8-H6; Wed, 01 Feb 2012 17:36:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rse6W-0003R3-74
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 17:36:20 +0000
Received: from [85.158.138.51:5579] by server-2.bemta-3.messagelabs.com id
	85/D4-15021-318792F4; Wed, 01 Feb 2012 17:36:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328117777!11602948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 1 Feb 2012 17:36:18 -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;
	1 Feb 2012 17:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10421635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 17:36:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 17:36:14 +0000
Date: Wed, 1 Feb 2012 17:38:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <B8188828-852E-45F6-B28A-5AE6CDF68602@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202011727450.3196@kaball-desktop>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
	<3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
	<alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
	<B8188828-852E-45F6-B28A-5AE6CDF68602@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Shriram Rajagopalan wrote:
> On 2012-02-01, at 6:14 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Wed, 1 Feb 2012, rshriram@cs.ubc.ca wrote:
> >> # HG changeset patch
> >> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >> # Date 1328070813 28800
> >> # Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
> >> # Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
> >> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> >> 
> >> Implement QMP stop and resume functionality and split
> >> device model save into 3 parts:
> >> suspend_dm(domid)
> >> save_dm(domid, fd)
> >> resume_dm(domid)
> >> 
> >> Integrate Device model suspend into suspend_common_callback
> >> 
> >> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >> 
> >> diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
> >> --- a/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
> >> +++ b/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
> >> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
> >>     return rc ? 0 : 1;
> >> }
> >> 
> >> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> >> +{
> >> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> >> +    int ret = 0, fd2 = -1;
> >> +    const char *filename = libxl__device_model_savefile(gc, domid);
> >> +
> >> +    switch (libxl__device_model_version_running(gc, domid)) {
> >> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> >> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> >> +                   "Saving device model state to %s", filename);
> >> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> >> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> >> +        break;
> >> +    }
> >> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> >> +        if (libxl__qmp_stop(gc, domid))
> >> +            return ERROR_FAIL;
> >> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> >> +        if (fd2 < 0) {
> >> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >> +                             "Unable to create a QEMU save file\n");
> >> +            return ERROR_FAIL;
> >> +        }
> >> +        /* Save DM state into fd2 */
> >> +        ret = libxl__qmp_migrate(gc, domid, fd2);
> >> +        if (ret)
> >> +            unlink(filename);
> >> +        close(fd2);
> >> +        fd2 = -1;
> >> +        break;
> >> +    default:
> >> +        return ERROR_INVAL;
> >> +    }
> >> +
> > 
> > Why do you need to introduce libxl__qmp_stop and libxl__qmp_resume?
> > 
> > Also keep in mind that I am about to change the command sent to save the
> > state of devices to "save_devices" because "migrate" is not working
> > properly with Xen.
> > 
> 
> I was modeling the qmp stuff similar to the old style qemu. 
> 
> Please correct me if I am wrong. Until qmp_migrate, qemu could still be writing data to the guest's memory right? 
> 
> So, I thought qmp_stop was a sure shot way to ensure such stuff is not happening under the hood. 

That is correct, however qemu is synchronous, so if the VM is paused qemu
is not going to do anything because it is not receiving any ioreqs from
xen. Moreover during the device state save we temporarily stop qemu to
make sure that the device state we save is consistent.

That said, explicitly stopping and resuming qemu should be harmless.


> With qmp_stop came qmp_resume.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:36:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rse6Y-0003R8-H6; Wed, 01 Feb 2012 17:36:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rse6W-0003R3-74
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 17:36:20 +0000
Received: from [85.158.138.51:5579] by server-2.bemta-3.messagelabs.com id
	85/D4-15021-318792F4; Wed, 01 Feb 2012 17:36:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328117777!11602948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 1 Feb 2012 17:36:18 -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;
	1 Feb 2012 17:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10421635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 17:36:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 17:36:14 +0000
Date: Wed, 1 Feb 2012 17:38:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <B8188828-852E-45F6-B28A-5AE6CDF68602@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202011727450.3196@kaball-desktop>
References: <patchbomb.1328071099@athos.nss.cs.ubc.ca>
	<3ca830009da79443bb44.1328071102@athos.nss.cs.ubc.ca>
	<alpine.DEB.2.00.1202011402520.3196@kaball-desktop>
	<B8188828-852E-45F6-B28A-5AE6CDF68602@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V2] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 1 Feb 2012, Shriram Rajagopalan wrote:
> On 2012-02-01, at 6:14 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Wed, 1 Feb 2012, rshriram@cs.ubc.ca wrote:
> >> # HG changeset patch
> >> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >> # Date 1328070813 28800
> >> # Node ID 3ca830009da79443bb445d983a34f5f78664cdf4
> >> # Parent  9f0a67bd54db89a23078913db578df72c5dba2e3
> >> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> >> 
> >> Implement QMP stop and resume functionality and split
> >> device model save into 3 parts:
> >> suspend_dm(domid)
> >> save_dm(domid, fd)
> >> resume_dm(domid)
> >> 
> >> Integrate Device model suspend into suspend_common_callback
> >> 
> >> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >> 
> >> diff -r 9f0a67bd54db -r 3ca830009da7 tools/libxl/libxl_dom.c
> >> --- a/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
> >> +++ b/tools/libxl/libxl_dom.c    Tue Jan 31 20:33:33 2012 -0800
> >> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
> >>     return rc ? 0 : 1;
> >> }
> >> 
> >> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> >> +{
> >> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> >> +    int ret = 0, fd2 = -1;
> >> +    const char *filename = libxl__device_model_savefile(gc, domid);
> >> +
> >> +    switch (libxl__device_model_version_running(gc, domid)) {
> >> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> >> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> >> +                   "Saving device model state to %s", filename);
> >> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> >> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> >> +        break;
> >> +    }
> >> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> >> +        if (libxl__qmp_stop(gc, domid))
> >> +            return ERROR_FAIL;
> >> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> >> +        if (fd2 < 0) {
> >> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >> +                             "Unable to create a QEMU save file\n");
> >> +            return ERROR_FAIL;
> >> +        }
> >> +        /* Save DM state into fd2 */
> >> +        ret = libxl__qmp_migrate(gc, domid, fd2);
> >> +        if (ret)
> >> +            unlink(filename);
> >> +        close(fd2);
> >> +        fd2 = -1;
> >> +        break;
> >> +    default:
> >> +        return ERROR_INVAL;
> >> +    }
> >> +
> > 
> > Why do you need to introduce libxl__qmp_stop and libxl__qmp_resume?
> > 
> > Also keep in mind that I am about to change the command sent to save the
> > state of devices to "save_devices" because "migrate" is not working
> > properly with Xen.
> > 
> 
> I was modeling the qmp stuff similar to the old style qemu. 
> 
> Please correct me if I am wrong. Until qmp_migrate, qemu could still be writing data to the guest's memory right? 
> 
> So, I thought qmp_stop was a sure shot way to ensure such stuff is not happening under the hood. 

That is correct, however qemu is synchronous, so if the VM is paused qemu
is not going to do anything because it is not receiving any ioreqs from
xen. Moreover during the device state save we temporarily stop qemu to
make sure that the device state we save is consistent.

That said, explicitly stopping and resuming qemu should be harmless.


> With qmp_stop came qmp_resume.

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:41:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17: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.xensource.com>)
	id 1RseBD-0003aG-IW; Wed, 01 Feb 2012 17:41:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RseBB-0003Zm-1P; Wed, 01 Feb 2012 17:41:09 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328118061!2072746!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11136 invoked from network); 1 Feb 2012 17:41:02 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 17:41:02 -0000
Received: by vbbfq11 with SMTP id fq11so4343492vbb.30
	for <multiple recipients>; Wed, 01 Feb 2012 09:41:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=rmpdqpsk6zFchAMTkjrRJHEMV4tZoIGoFRNGX+zCOxE=;
	b=ZxfzY2SQdytLiD3mTVLLxX9me+QkbBjIXv9iuebuY3mUrqn5fjdlAs48wy4dDDLDn7
	xwPJR0e6WncAJw11e7rPjYYbeesApOpNB67lYLR8xblCgkhNKFrVaq3wylWOkprSToUd
	ErtrmhiKELK4OVR1ukRKeE6o0+j7wUHoAAseQ=
Received: by 10.52.27.20 with SMTP id p20mr13112477vdg.59.1328118060918;
	Wed, 01 Feb 2012 09:41:00 -0800 (PST)
Received: from [172.16.25.10] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id q18sm23032890vdi.10.2012.02.01.09.40.58
	(version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 09:40:59 -0800 (PST)
Message-ID: <4F297929.3070907@xen.org>
Date: Wed, 01 Feb 2012 17:40:57 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Reminder: Xen Hackathon hosted by Oracle, March 6-8,
 Santa Clara, CA, USA
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,

just a quick reminder that the Xen Hackathon is in Oracle, March 6-8, 
Santa Clara, CA, USA. We have originally planned for about 25 people, 
but already we have 14 people signed up. If you are planning to attend 
please sign up quickly, such that I get a feeling for the number of 
attendees. I can then go back to Oracle and see whether we can 
accommodate more people than we planned for.

* If you think you will attend please sign up at: 
http://wiki.xen.org/wiki/Hackathon/March2012
* If you think you may attend, but are not sure yet add, e.g. because 
you do not yet have travel approved, please add "(provisional)" next to 
your name
* If you can only attend part-time, please let us know which dates you 
want to attend.
* If you do not regularly contribute to the Xen a mailing lists, please 
add your e-mail address such that I can get in touch with you

Please also add topics and stuff you want to cover. Also please suggest 
evening social activities if you are from the area.

Best Regards
Lars

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 17:41:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 17: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.xensource.com>)
	id 1RseBD-0003aG-IW; Wed, 01 Feb 2012 17:41:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RseBB-0003Zm-1P; Wed, 01 Feb 2012 17:41:09 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328118061!2072746!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11136 invoked from network); 1 Feb 2012 17:41:02 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 17:41:02 -0000
Received: by vbbfq11 with SMTP id fq11so4343492vbb.30
	for <multiple recipients>; Wed, 01 Feb 2012 09:41:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=rmpdqpsk6zFchAMTkjrRJHEMV4tZoIGoFRNGX+zCOxE=;
	b=ZxfzY2SQdytLiD3mTVLLxX9me+QkbBjIXv9iuebuY3mUrqn5fjdlAs48wy4dDDLDn7
	xwPJR0e6WncAJw11e7rPjYYbeesApOpNB67lYLR8xblCgkhNKFrVaq3wylWOkprSToUd
	ErtrmhiKELK4OVR1ukRKeE6o0+j7wUHoAAseQ=
Received: by 10.52.27.20 with SMTP id p20mr13112477vdg.59.1328118060918;
	Wed, 01 Feb 2012 09:41:00 -0800 (PST)
Received: from [172.16.25.10] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id q18sm23032890vdi.10.2012.02.01.09.40.58
	(version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 09:40:59 -0800 (PST)
Message-ID: <4F297929.3070907@xen.org>
Date: Wed, 01 Feb 2012 17:40:57 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Reminder: Xen Hackathon hosted by Oracle, March 6-8,
 Santa Clara, CA, USA
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,

just a quick reminder that the Xen Hackathon is in Oracle, March 6-8, 
Santa Clara, CA, USA. We have originally planned for about 25 people, 
but already we have 14 people signed up. If you are planning to attend 
please sign up quickly, such that I get a feeling for the number of 
attendees. I can then go back to Oracle and see whether we can 
accommodate more people than we planned for.

* If you think you will attend please sign up at: 
http://wiki.xen.org/wiki/Hackathon/March2012
* If you think you may attend, but are not sure yet add, e.g. because 
you do not yet have travel approved, please add "(provisional)" next to 
your name
* If you can only attend part-time, please let us know which dates you 
want to attend.
* If you do not regularly contribute to the Xen a mailing lists, please 
add your e-mail address such that I can get in touch with you

Please also add topics and stuff you want to cover. Also please suggest 
evening social activities if you are from the area.

Best Regards
Lars

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:04:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:04:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RseXI-0004hl-B7; Wed, 01 Feb 2012 18:04:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RseXG-0004hd-Tm; Wed, 01 Feb 2012 18:03:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328119432!13320508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7374 invoked from network); 1 Feb 2012 18:03:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:03:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10422032"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 18:03:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 18:03:34 +0000
Date: Wed, 1 Feb 2012 18:05:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Likarpenkov Alexander <al@ohosting.org.ua>
In-Reply-To: <67003516D77C4AE38E7F08CEEF127E89@nobody>
Message-ID: <alpine.DEB.2.00.1202011800350.3196@kaball-desktop>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host><3758972BBA474BCBB9CA5D1D316892E7@nobody><1327430498.7929.14.camel@mnetdjm5.mageenet.host><EE3AE950D047481283FF742510029D1E@nobody><1327510462.24561.351.camel@zakaz.uk.xensource.com><CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com><1327577478.26983.73.camel@zakaz.uk.xensource.com>
	<5C1125AAA6544C759D3072468263185C@nobody>
	<67003516D77C4AE38E7F08CEEF127E89@nobody>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1178924071-1328119544=:3196"
Cc: Florian Heigl <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	SandiRomih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	KonradRzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] xl vs xm - hernya (bad results)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1178924071-1328119544=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Fri, 27 Jan 2012, Likarpenkov Alexander wrote:
> Sorry, quoting lines cut, and I repeat the message
>  
> Compare the two results on the same system.
> xl - not sorted alphabetically and by memory shows the nonsense
> # xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     6        r-- 313260.0
> c2                                           1  4096     5        r-- 111502.1
> c3                                           4   512     5        r--   6419.4
> s1                                       6  1027     2        r--  19593.0
> d70                                          7  1003     1        r--  77161.6
> d73                                          8   515     1        r-- 237146.7
> v01                                         10    93     1        r--  48162.9
> t2                                          12   515     5        r--  38607.5
> a1                                       13  2050     4        r-- 160406.0
> g4                                          15    99     1        r--  15616.6
> g3                                          18   131     1        r--  43006.0
> b1                                        20   512     5        r--   4133.2
> t1                                          21   259     1        r-- 140468.7
> d80                                         22   515     5        r--  50262.9
> g2                                          38    83     1        r--  34071.0
> d82                                         40   771     5        r--  17699.5
> j2                                          41  1027     5        r--  68179.1
> d75                                         43    99     1        r--  13325.7
> d74                                         52   771     1        r--   9707.6
> t3                                          53   515     5        r--   7913.0
> # xm list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     6     r----- 313274.1
> a1                                       13  2048     4     -b---- 160412.8
> b1                                        20   512     5     ------   4133.4
> c2                                           1  4096     5     -b---- 111508.6
> c3                                           4   512     5     -b----   6419.5
> d70                                          7  1000     1     -b----  77163.8
> d73                                          8   512     1     -b---- 237155.4
> d74                                         52   768     1     -b----   9709.6
> d75                                         43    96     1     -b----  13327.6
> d80                                         22   512     5     -b----  50266.4
> d82                                         40   768     5     -b----  17700.9
> g2                                          38    80     1     -b----  34073.4
> g3                                          18   128     1     -b----  43008.1
> g4                                          15    96     1     -b----  15617.3
> j2                                          41  1024     5     -b----  68192.6
> s1                                       6  1024     2     -b----  19594.0
> t1                                          21   256     1     r----- 140478.2
> t2                                          12   512     5     -b----  38609.1
> t3                                          53   512     5     -b----   7914.8
> v01                                         10    90     1     -b----  48164.8

xl and xm compute the amount of memory used by VMs differently, in
particular xl returns the current amount of memory used by the VM, as
reported by the hypervisor.

What Xen version are you using? Could you please post the xl and the xm
config files of one of the VMs that show up differently?

If you are creating the VMs using xm and then executing "xl list", you
should know that this is not a supported configuration: either you use
xm or xl, you shouldn't mix them.
--8323329-1178924071-1328119544=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-1178924071-1328119544=:3196--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:04:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:04:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RseXI-0004hl-B7; Wed, 01 Feb 2012 18:04:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RseXG-0004hd-Tm; Wed, 01 Feb 2012 18:03:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328119432!13320508!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7374 invoked from network); 1 Feb 2012 18:03:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:03:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10422032"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 18:03:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 18:03:34 +0000
Date: Wed, 1 Feb 2012 18:05:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Likarpenkov Alexander <al@ohosting.org.ua>
In-Reply-To: <67003516D77C4AE38E7F08CEEF127E89@nobody>
Message-ID: <alpine.DEB.2.00.1202011800350.3196@kaball-desktop>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info><20120124015021.GB24204@andromeda.dapyr.net><EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host><3758972BBA474BCBB9CA5D1D316892E7@nobody><1327430498.7929.14.camel@mnetdjm5.mageenet.host><EE3AE950D047481283FF742510029D1E@nobody><1327510462.24561.351.camel@zakaz.uk.xensource.com><CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com><1327577478.26983.73.camel@zakaz.uk.xensource.com>
	<5C1125AAA6544C759D3072468263185C@nobody>
	<67003516D77C4AE38E7F08CEEF127E89@nobody>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1178924071-1328119544=:3196"
Cc: Florian Heigl <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	SandiRomih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	KonradRzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] xl vs xm - hernya (bad results)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1178924071-1328119544=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Fri, 27 Jan 2012, Likarpenkov Alexander wrote:
> Sorry, quoting lines cut, and I repeat the message
>  
> Compare the two results on the same system.
> xl - not sorted alphabetically and by memory shows the nonsense
> # xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     6        r-- 313260.0
> c2                                           1  4096     5        r-- 111502.1
> c3                                           4   512     5        r--   6419.4
> s1                                       6  1027     2        r--  19593.0
> d70                                          7  1003     1        r--  77161.6
> d73                                          8   515     1        r-- 237146.7
> v01                                         10    93     1        r--  48162.9
> t2                                          12   515     5        r--  38607.5
> a1                                       13  2050     4        r-- 160406.0
> g4                                          15    99     1        r--  15616.6
> g3                                          18   131     1        r--  43006.0
> b1                                        20   512     5        r--   4133.2
> t1                                          21   259     1        r-- 140468.7
> d80                                         22   515     5        r--  50262.9
> g2                                          38    83     1        r--  34071.0
> d82                                         40   771     5        r--  17699.5
> j2                                          41  1027     5        r--  68179.1
> d75                                         43    99     1        r--  13325.7
> d74                                         52   771     1        r--   9707.6
> t3                                          53   515     5        r--   7913.0
> # xm list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     6     r----- 313274.1
> a1                                       13  2048     4     -b---- 160412.8
> b1                                        20   512     5     ------   4133.4
> c2                                           1  4096     5     -b---- 111508.6
> c3                                           4   512     5     -b----   6419.5
> d70                                          7  1000     1     -b----  77163.8
> d73                                          8   512     1     -b---- 237155.4
> d74                                         52   768     1     -b----   9709.6
> d75                                         43    96     1     -b----  13327.6
> d80                                         22   512     5     -b----  50266.4
> d82                                         40   768     5     -b----  17700.9
> g2                                          38    80     1     -b----  34073.4
> g3                                          18   128     1     -b----  43008.1
> g4                                          15    96     1     -b----  15617.3
> j2                                          41  1024     5     -b----  68192.6
> s1                                       6  1024     2     -b----  19594.0
> t1                                          21   256     1     r----- 140478.2
> t2                                          12   512     5     -b----  38609.1
> t3                                          53   512     5     -b----   7914.8
> v01                                         10    90     1     -b----  48164.8

xl and xm compute the amount of memory used by VMs differently, in
particular xl returns the current amount of memory used by the VM, as
reported by the hypervisor.

What Xen version are you using? Could you please post the xl and the xm
config files of one of the VMs that show up differently?

If you are creating the VMs using xm and then executing "xl list", you
should know that this is not a supported configuration: either you use
xm or xl, you shouldn't mix them.
--8323329-1178924071-1328119544=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-1178924071-1328119544=:3196--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:06:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RseZJ-0004md-3Z; Wed, 01 Feb 2012 18:06:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agent.peter123@gmail.com>) id 1RseZH-0004mT-EB
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:06:03 +0000
X-Env-Sender: agent.peter123@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328119556!12521959!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27370 invoked from network); 1 Feb 2012 18:05:57 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:05:57 -0000
Received: by qabg27 with SMTP id g27so4222154qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 10:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Mpw8SfoIohLZGGrEE8AuIlj5f6BJ2sfklmOy/ITZEDw=;
	b=ECdA2QZx/gx2ETlny936BT+RHw05aQMgbgRs5NMVirCrU8DnJkUeiKM4Ptqp/gnOzu
	mPFO8cclw8cqIl8EHRv3XEy9mg8jhhGHtzsEhNPoCWxtHrncuMt1tTZunDnBvmH+Oa0Y
	F6dZxCcYz2AiL+C02A3Pic2Dz7effXGGi1NeY=
MIME-Version: 1.0
Received: by 10.224.78.206 with SMTP id m14mr34697714qak.18.1328119555726;
	Wed, 01 Feb 2012 10:05:55 -0800 (PST)
Received: by 10.229.220.207 with HTTP; Wed, 1 Feb 2012 10:05:55 -0800 (PST)
Date: Wed, 1 Feb 2012 13:05:55 -0500
Message-ID: <CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QOdDodKoYdTR-Q@mail.gmail.com>
From: Peter Deng <agent.peter123@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen Mem Page Sharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1735768705244386958=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1735768705244386958==
Content-Type: multipart/alternative; boundary=20cf3074d3be569e2104b7eaee9c

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

Hi,

I'm am looking into and doing some research on Memory Page Sharing on Xen,
and I would like to know the current activity status regarding Xen's memory
management. Also, while looking through the source code, I am having some
trouble translating some of the functions, notably in mem_sharing.c, and
one function I would like to have explained is mem_sharing_audit(). One
that note, is there recent documentation on Xen code or do I need to trace
the logs to determine development changes?

Thanks,

Peter

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

<span style=3D"font-size:13px;font-family:Verdana,Geneva,Helvetica,Arial,sa=
ns-serif">Hi,</span><div style=3D"font-size:13px;font-family:Verdana,Geneva=
,Helvetica,Arial,sans-serif">
<br></div><div style=3D"font-size:13px;font-family:Verdana,Geneva,Helvetica=
,Arial,sans-serif">I&#39;m am looking into and doing some research on Memor=
y Page Sharing on Xen, and I would like to know the current activity status=
 regarding Xen&#39;s memory management. Also, while looking through the sou=
rce code, I am having some trouble translating some of the functions, notab=
ly in mem_sharing.c, and one function I would like to have explained is mem=
_sharing_audit(). One that note, is there recent documentation on Xen code =
or do I need to trace the logs to determine development changes?<br>
</div>

<div style=3D"font-size:13px;font-family:Verdana,Geneva,Helvetica,Arial,san=
s-serif"><br></div><div style=3D"font-size:13px;font-family:Verdana,Geneva,=
Helvetica,Arial,sans-serif">
Thanks,</div><div style=3D"font-size:13px;font-family:Verdana,Geneva,Helvet=
ica,Arial,sans-serif"><br></div><div style=3D"font-size:13px;font-family:Ve=
rdana,Geneva,Helvetica,Arial,sans-serif">
Peter<br></div>

--20cf3074d3be569e2104b7eaee9c--


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

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

--===============1735768705244386958==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:06:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RseZJ-0004md-3Z; Wed, 01 Feb 2012 18:06:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agent.peter123@gmail.com>) id 1RseZH-0004mT-EB
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:06:03 +0000
X-Env-Sender: agent.peter123@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328119556!12521959!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27370 invoked from network); 1 Feb 2012 18:05:57 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:05:57 -0000
Received: by qabg27 with SMTP id g27so4222154qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 10:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Mpw8SfoIohLZGGrEE8AuIlj5f6BJ2sfklmOy/ITZEDw=;
	b=ECdA2QZx/gx2ETlny936BT+RHw05aQMgbgRs5NMVirCrU8DnJkUeiKM4Ptqp/gnOzu
	mPFO8cclw8cqIl8EHRv3XEy9mg8jhhGHtzsEhNPoCWxtHrncuMt1tTZunDnBvmH+Oa0Y
	F6dZxCcYz2AiL+C02A3Pic2Dz7effXGGi1NeY=
MIME-Version: 1.0
Received: by 10.224.78.206 with SMTP id m14mr34697714qak.18.1328119555726;
	Wed, 01 Feb 2012 10:05:55 -0800 (PST)
Received: by 10.229.220.207 with HTTP; Wed, 1 Feb 2012 10:05:55 -0800 (PST)
Date: Wed, 1 Feb 2012 13:05:55 -0500
Message-ID: <CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QOdDodKoYdTR-Q@mail.gmail.com>
From: Peter Deng <agent.peter123@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen Mem Page Sharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1735768705244386958=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1735768705244386958==
Content-Type: multipart/alternative; boundary=20cf3074d3be569e2104b7eaee9c

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

Hi,

I'm am looking into and doing some research on Memory Page Sharing on Xen,
and I would like to know the current activity status regarding Xen's memory
management. Also, while looking through the source code, I am having some
trouble translating some of the functions, notably in mem_sharing.c, and
one function I would like to have explained is mem_sharing_audit(). One
that note, is there recent documentation on Xen code or do I need to trace
the logs to determine development changes?

Thanks,

Peter

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

<span style=3D"font-size:13px;font-family:Verdana,Geneva,Helvetica,Arial,sa=
ns-serif">Hi,</span><div style=3D"font-size:13px;font-family:Verdana,Geneva=
,Helvetica,Arial,sans-serif">
<br></div><div style=3D"font-size:13px;font-family:Verdana,Geneva,Helvetica=
,Arial,sans-serif">I&#39;m am looking into and doing some research on Memor=
y Page Sharing on Xen, and I would like to know the current activity status=
 regarding Xen&#39;s memory management. Also, while looking through the sou=
rce code, I am having some trouble translating some of the functions, notab=
ly in mem_sharing.c, and one function I would like to have explained is mem=
_sharing_audit(). One that note, is there recent documentation on Xen code =
or do I need to trace the logs to determine development changes?<br>
</div>

<div style=3D"font-size:13px;font-family:Verdana,Geneva,Helvetica,Arial,san=
s-serif"><br></div><div style=3D"font-size:13px;font-family:Verdana,Geneva,=
Helvetica,Arial,sans-serif">
Thanks,</div><div style=3D"font-size:13px;font-family:Verdana,Geneva,Helvet=
ica,Arial,sans-serif"><br></div><div style=3D"font-size:13px;font-family:Ve=
rdana,Geneva,Helvetica,Arial,sans-serif">
Peter<br></div>

--20cf3074d3be569e2104b7eaee9c--


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

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

--===============1735768705244386958==--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:08:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsebM-0004ud-Kz; Wed, 01 Feb 2012 18:08:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsebK-0004ty-RV
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328119684!2075729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22443 invoked from network); 1 Feb 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10422098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 18:08:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 18:08:04 +0000
Date: Wed, 1 Feb 2012 18:09:58 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

Important note: the second and third patches only make sense if the
corresponding QEMU's patches[1] are accepted.


[1] http://marc.info/?l=qemu-devel&m=132749682330542&w=2


Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_domain_restore.c |   46 ++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 ++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  143 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +---------------------
 tools/xcutils/xc_restore.c      |    2 +-
 8 files changed, 222 insertions(+), 94 deletions(-)


Cheers,

Stefano

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:08:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:08:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsebM-0004ud-Kz; Wed, 01 Feb 2012 18:08:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsebK-0004ty-RV
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328119684!2075729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjYxNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22443 invoked from network); 1 Feb 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320624000"; d="scan'208";a="10422098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 18:08:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 18:08:04 +0000
Date: Wed, 1 Feb 2012 18:09:58 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

Important note: the second and third patches only make sense if the
corresponding QEMU's patches[1] are accepted.


[1] http://marc.info/?l=qemu-devel&m=132749682330542&w=2


Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_domain_restore.c |   46 ++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 ++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  143 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +---------------------
 tools/xcutils/xc_restore.c      |    2 +-
 8 files changed, 222 insertions(+), 94 deletions(-)


Cheers,

Stefano

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:08:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsebs-0004xO-25; Wed, 01 Feb 2012 18:08: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 1Rsebr-0004xF-Bo
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:43 +0000
Received: from [85.158.138.51:62091] by server-12.bemta-3.messagelabs.com id
	CA/4D-21103-AAF792F4; Wed, 01 Feb 2012 18:08:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328119719!9753925!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzMjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9463 invoked from network); 1 Feb 2012 18:08:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320642000"; d="scan'208";a="179998317"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:08:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:08:38 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11I8VRY005383;
	Wed, 1 Feb 2012 10:08:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 18:10:37 +0000
Message-ID: <1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

---
 tools/libxc/xc_domain_restore.c |   46 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..958534c 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -682,6 +687,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:08:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsebs-0004xO-25; Wed, 01 Feb 2012 18:08: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 1Rsebr-0004xF-Bo
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:43 +0000
Received: from [85.158.138.51:62091] by server-12.bemta-3.messagelabs.com id
	CA/4D-21103-AAF792F4; Wed, 01 Feb 2012 18:08:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328119719!9753925!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzMjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9463 invoked from network); 1 Feb 2012 18:08:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320642000"; d="scan'208";a="179998317"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:08:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:08:38 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11I8VRY005383;
	Wed, 1 Feb 2012 10:08:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 18:10:37 +0000
Message-ID: <1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

---
 tools/libxc/xc_domain_restore.c |   46 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..958534c 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -682,6 +687,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1262,7 +1286,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1310,6 +1335,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1322,6 +1348,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1581,6 +1608,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2023,6 +2054,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsec0-0004zJ-MC; Wed, 01 Feb 2012 18:08:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rseby-0004yl-Ks
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:50 +0000
Received: from [85.158.138.51:62431] by server-8.bemta-3.messagelabs.com id
	6D/10-08780-1BF792F4; Wed, 01 Feb 2012 18:08:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328119727!11440470!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzMjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2024 invoked from network); 1 Feb 2012 18:08:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320642000"; d="scan'208";a="179998346"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:08:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:08:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11I8VRa005383;
	Wed, 1 Feb 2012 10:08:35 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 18:10:39 +0000
Message-ID: <1328119839-1168-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "save_devices" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "save_devices".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a6eb714..40ebcd1 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -771,18 +771,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..6d11cfe 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -619,7 +619,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 6d401b7..19bf699 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -533,52 +533,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -815,34 +769,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -852,23 +780,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "save_devices", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsec0-0004zJ-MC; Wed, 01 Feb 2012 18:08:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rseby-0004yl-Ks
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:50 +0000
Received: from [85.158.138.51:62431] by server-8.bemta-3.messagelabs.com id
	6D/10-08780-1BF792F4; Wed, 01 Feb 2012 18:08:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328119727!11440470!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzMjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2024 invoked from network); 1 Feb 2012 18:08:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320642000"; d="scan'208";a="179998346"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:08:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:08:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11I8VRa005383;
	Wed, 1 Feb 2012 10:08:35 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 18:10:39 +0000
Message-ID: <1328119839-1168-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/3] libxl_qmp: remove libxl__qmp_migrate,
	introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "save_devices" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "save_devices".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a6eb714..40ebcd1 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -771,18 +771,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..6d11cfe 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -619,7 +619,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 6d401b7..19bf699 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -533,52 +533,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -815,34 +769,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -852,23 +780,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "save_devices", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:09:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18: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.xensource.com>)
	id 1Rsec4-000506-3k; Wed, 01 Feb 2012 18:08:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsec2-0004yX-1s
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328119726!4102766!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkxNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27555 invoked from network); 1 Feb 2012 18:08:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320642000"; d="scan'208";a="21512000"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:08:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:08:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11I8VRZ005383;
	Wed, 1 Feb 2012 10:08:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 18:10:38 +0000
Message-ID: <1328119839-1168-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2c5eec5..a6eb714 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -349,6 +349,66 @@ out:
     return rc;
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -358,6 +418,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -365,6 +426,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = info->u.hvm.pae;
         no_incr_generationid = info->u.hvm.no_incr_generationid;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -379,7 +442,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -534,6 +597,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -596,6 +725,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 18:09:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 18: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.xensource.com>)
	id 1Rsec4-000506-3k; Wed, 01 Feb 2012 18:08:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsec2-0004yX-1s
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 18:08:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328119726!4102766!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkxNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27555 invoked from network); 1 Feb 2012 18:08:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 18:08:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,603,1320642000"; d="scan'208";a="21512000"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 13:08:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 13:08:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q11I8VRZ005383;
	Wed, 1 Feb 2012 10:08:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 1 Feb 2012 18:10:38 +0000
Message-ID: <1328119839-1168-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2c5eec5..a6eb714 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -349,6 +349,66 @@ out:
     return rc;
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -358,6 +418,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -365,6 +426,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = info->u.hvm.pae;
         no_incr_generationid = info->u.hvm.no_incr_generationid;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -379,7 +442,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -534,6 +597,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -596,6 +725,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYq-0006cD-67; Wed, 01 Feb 2012 19:09:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYn-0006b3-WB
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328123371!10995570!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30953 invoked from network); 1 Feb 2012 19:09:31 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Uiq025823
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S62004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:20 -0500
Message-Id: <1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add wrappers for getting and setting policy booleans by name or ID.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
 tools/flask/libflask/include/libflask.h |    3 ++
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
index d4b8ef0..412a05d 100644
--- a/tools/flask/libflask/flask_op.c
+++ b/tools/flask/libflask/flask_op.c
@@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
     return 0;
 }
 
+int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL2;
+    op.buf = buf;
+    op.size = 255;
+
+    snprintf(buf, sizeof buf, "%i", id);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i %s", curr, pend, name);
+
+    return rv;
+}
+
+int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL_NAMED;
+    op.buf = buf;
+    op.size = 255;
+
+    strncpy(buf, name, op.size);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i", curr, pend);
+
+    return rv;
+}
+
+int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
+{
+    flask_op_t op;
+    char buf[255];
+    int size = 255;
+
+    op.cmd = FLASK_SETBOOL_NAMED;
+    op.buf = buf;
+    op.size = size;
+
+    snprintf(buf, size, "%s %i %i", name, value, commit);
+
+    return xc_flask_op(xc_handle, &op);
+}
+
 int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext)
 {
     int err;
diff --git a/tools/flask/libflask/include/libflask.h b/tools/flask/libflask/include/libflask.h
index e4c34b8..b8a6ca9 100644
--- a/tools/flask/libflask/include/libflask.h
+++ b/tools/flask/libflask/include/libflask.h
@@ -21,6 +21,9 @@ int flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint
 int flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);
 int flask_getenforce(xc_interface *xc_handle);
 int flask_setenforce(xc_interface *xc_handle, int mode);
+int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend);
+int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend);
+int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit);
 int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext);
 int flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
                       char *scontext);
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYq-0006cD-67; Wed, 01 Feb 2012 19:09:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYn-0006b3-WB
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328123371!10995570!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30953 invoked from network); 1 Feb 2012 19:09:31 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Uiq025823
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S62004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:20 -0500
Message-Id: <1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add wrappers for getting and setting policy booleans by name or ID.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
 tools/flask/libflask/include/libflask.h |    3 ++
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
index d4b8ef0..412a05d 100644
--- a/tools/flask/libflask/flask_op.c
+++ b/tools/flask/libflask/flask_op.c
@@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
     return 0;
 }
 
+int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL2;
+    op.buf = buf;
+    op.size = 255;
+
+    snprintf(buf, sizeof buf, "%i", id);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i %s", curr, pend, name);
+
+    return rv;
+}
+
+int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL_NAMED;
+    op.buf = buf;
+    op.size = 255;
+
+    strncpy(buf, name, op.size);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i", curr, pend);
+
+    return rv;
+}
+
+int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
+{
+    flask_op_t op;
+    char buf[255];
+    int size = 255;
+
+    op.cmd = FLASK_SETBOOL_NAMED;
+    op.buf = buf;
+    op.size = size;
+
+    snprintf(buf, size, "%s %i %i", name, value, commit);
+
+    return xc_flask_op(xc_handle, &op);
+}
+
 int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext)
 {
     int err;
diff --git a/tools/flask/libflask/include/libflask.h b/tools/flask/libflask/include/libflask.h
index e4c34b8..b8a6ca9 100644
--- a/tools/flask/libflask/include/libflask.h
+++ b/tools/flask/libflask/include/libflask.h
@@ -21,6 +21,9 @@ int flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint
 int flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);
 int flask_getenforce(xc_interface *xc_handle);
 int flask_setenforce(xc_interface *xc_handle, int mode);
+int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend);
+int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend);
+int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit);
 int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext);
 int flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
                       char *scontext);
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYp-0006c2-Pi; Wed, 01 Feb 2012 19:09:39 +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 1RsfYn-0006b2-Ry
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328123327!62661939!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16440 invoked from network); 1 Feb 2012 19:08:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:08:47 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Ufo015476; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S60004479; 
	Wed, 1 Feb 2012 14:09:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:18 -0500
Message-Id: <1328123365-12490-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1/8] xen/xsm: fix incorrect handling of XSM hook
	return
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If the XSM hook denied access, the execution incorrectly continued on
after an extra unlock domain.

Reported-by: John McDermott <john.mcdermott@nrl.navy.mil>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 xen/arch/x86/domctl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9c9d5d1..831cdda 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -648,7 +648,7 @@ long arch_do_domctl(
 
         ret = xsm_machine_address_size(d, domctl->cmd);
         if ( ret )
-            rcu_unlock_domain(d);
+            goto set_machine_address_size_out;
 
         ret = -EBUSY;
         if ( d->tot_pages > 0 )
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYp-0006c2-Pi; Wed, 01 Feb 2012 19:09:39 +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 1RsfYn-0006b2-Ry
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328123327!62661939!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16440 invoked from network); 1 Feb 2012 19:08:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:08:47 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Ufo015476; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S60004479; 
	Wed, 1 Feb 2012 14:09:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:18 -0500
Message-Id: <1328123365-12490-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1/8] xen/xsm: fix incorrect handling of XSM hook
	return
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If the XSM hook denied access, the execution incorrectly continued on
after an extra unlock domain.

Reported-by: John McDermott <john.mcdermott@nrl.navy.mil>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 xen/arch/x86/domctl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9c9d5d1..831cdda 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -648,7 +648,7 @@ long arch_do_domctl(
 
         ret = xsm_machine_address_size(d, domctl->cmd);
         if ( ret )
-            rcu_unlock_domain(d);
+            goto set_machine_address_size_out;
 
         ret = -EBUSY;
         if ( d->tot_pages > 0 )
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYr-0006cU-9b; Wed, 01 Feb 2012 19:09:41 +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 1RsfYo-0006b5-Bv
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328123342!58086453!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19704 invoked from network); 1 Feb 2012 19:09:03 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:09:03 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Uiq025824
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S63004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:21 -0500
Message-Id: <1328123365-12490-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 4/8] flask: add flask-{get,set}-bool tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These utilities can be used to modify policy booleans, which allow
minor policy changes without reloading the security policy. This can be
used to make security policy change based on external information such
as time of day, user physical presence, completion of system boot, or
other relevant variables.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/Makefile   |    8 +++-
 tools/flask/utils/get-bool.c |   90 ++++++++++++++++++++++++++++++++++++++++++
 tools/flask/utils/set-bool.c |   72 +++++++++++++++++++++++++++++++++
 3 files changed, 169 insertions(+), 1 deletions(-)
 create mode 100644 tools/flask/utils/get-bool.c
 create mode 100644 tools/flask/utils/set-bool.c

diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index 171a728..3ac6ac2 100644
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -11,7 +11,7 @@ TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
 TESTENV  = XENSTORED_ROOTDIR=$(TESTDIR) XENSTORED_RUNDIR=$(TESTDIR)
 
-CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce flask-label-pci
+CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce flask-label-pci flask-get-bool flask-set-bool
 CLIENTS_SRCS := $(patsubst flask-%,%.c,$(CLIENTS))
 CLIENTS_OBJS := $(patsubst flask-%,%.o,$(CLIENTS))
 
@@ -30,6 +30,12 @@ flask-getenforce: getenforce.o
 flask-label-pci: label-pci.o
 	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
 
+flask-get-bool: get-bool.o
+	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+
+flask-set-bool: set-bool.o
+	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+
 .PHONY: clean
 clean: 
 	rm -f *.o *.opic *.so
diff --git a/tools/flask/utils/get-bool.c b/tools/flask/utils/get-bool.c
new file mode 100644
index 0000000..c0cd7c8
--- /dev/null
+++ b/tools/flask/utils/get-bool.c
@@ -0,0 +1,90 @@
+/*
+ *  Author:  Daniel De Graaf <dgdegra@tycho.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 <stdlib.h>
+#include <errno.h>
+#include <stdio.h>
+#include <xenctrl.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <string.h>
+#include <unistd.h>
+#include <inttypes.h>
+#include <libflask.h>
+
+static void usage(char **argv)
+{
+	fprintf(stderr, "Usage: %s {name|-a}\n", argv[0]);
+	exit(1);
+}
+
+static int all_bools(xc_interface *xch)
+{
+	int err = 0, i = 0, curr, pend;
+	char name[256];
+	while (1) {
+		err = flask_getbool_byid(xch, i, name, &curr, &pend);
+		if (err < 0) {
+			if (errno == ENOENT)
+				return 0;
+			fprintf(stderr, "flask_getbool: Unable to get boolean #%d: %s (%d)",
+				i, strerror(errno), err);
+			return 2;
+		}
+		if (curr == pend)
+			printf("%s: %d\n", name, curr);
+		else
+			printf("%s: %d (pending %d)\n", name, curr, pend);
+		i++;
+	}
+}
+
+int main(int argc, char **argv)
+{
+	int err = 0;
+	xc_interface *xch;
+	int curr, pend;
+
+	if (argc != 2)
+		usage(argv);
+
+	xch = xc_interface_open(0,0,0);
+	if ( !xch )
+	{
+		fprintf(stderr, "Unable to create interface to xenctrl: %s\n",
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	if (!strcmp(argv[1], "-a"))
+	{
+		err = all_bools(xch);
+		goto done;
+	}
+
+	err = flask_getbool_byname(xch, argv[1], &curr, &pend);
+	if (err) {
+		fprintf(stderr, "flask_getbool: Unable to get boolean %s: %s (%d)",
+			argv[1], strerror(errno), err);
+		err = 2;
+		goto done;
+	}
+
+	if (curr == pend)
+		printf("%s: %d\n", argv[1], curr);
+	else
+		printf("%s: %d (pending %d)\n", argv[1], curr, pend);
+
+ done:
+	if ( xch )
+		xc_interface_close(xch);
+
+	return err;
+}
diff --git a/tools/flask/utils/set-bool.c b/tools/flask/utils/set-bool.c
new file mode 100644
index 0000000..cde25cd
--- /dev/null
+++ b/tools/flask/utils/set-bool.c
@@ -0,0 +1,72 @@
+/*
+ *  Author:  Daniel De Graaf <dgdegra@tycho.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 <stdlib.h>
+#include <errno.h>
+#include <stdio.h>
+#include <xenctrl.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <string.h>
+#include <unistd.h>
+#include <inttypes.h>
+#include <libflask.h>
+
+static void usage(char **argv)
+{
+	fprintf(stderr, "Usage: %s name value\n", argv[0]);
+	exit(1);
+}
+
+static int str2bool(const char *str)
+{
+	if (str[0] == '0' || str[0] == '1')
+		return (str[0] == '1');
+	if (!strcasecmp(str, "enabled") || !strcasecmp(str, "on") || !strcasecmp(str, "y"))
+		return 1;
+	if (!strcasecmp(str, "disabled") || !strcasecmp(str, "off") || !strcasecmp(str, "n"))
+		return 0;
+	fprintf(stderr, "Unknown value %s\n", str);
+	exit(1);
+}
+
+int main(int argc, char **argv)
+{
+	int err = 0;
+	xc_interface *xch;
+	int value;
+
+	if (argc != 3)
+		usage(argv);
+
+	value = str2bool(argv[2]);
+
+	xch = xc_interface_open(0,0,0);
+	if ( !xch )
+	{
+		fprintf(stderr, "Unable to create interface to xenctrl: %s\n",
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	err = flask_setbool(xch, argv[1], value, 1);
+	if (err) {
+		fprintf(stderr, "flask_setbool: Unable to set boolean %s=%s: %s (%d)",
+			argv[1], argv[2], strerror(errno), err);
+		err = 2;
+		goto done;
+	}
+
+ done:
+	if ( xch )
+		xc_interface_close(xch);
+
+	return err;
+}
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYs-0006cz-Ft; Wed, 01 Feb 2012 19:09:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYp-0006b9-4L
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328123371!2082047!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6134 invoked from network); 1 Feb 2012 19:09:32 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:32 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Viq025829
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S64004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:22 -0500
Message-Id: <1328123365-12490-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 5/8] flask/policy: Add boolean example
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This shows an example boolean (prot_doms_locked) which can be set at
runtime to prevent dom0 from mapping memory of domains of type
prot_domU_t.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |    3 ++-
 tools/flask/policy/policy/modules/xen/xen.te |   10 +++++++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 285bb9f..5b4297d 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -55,10 +55,11 @@ kernel; it is normally placed either just above the dom0 kernel or at the end.
 Once dom0 is running, the policy can be reloaded using "xl loadpolicy".
 
 The example policy included with Xen demonstrates most of the features of FLASK
-that can be used without dom0 disaggregation. It has two main types for domUs:
+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
 
 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
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index fb71b75..f7343a2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -73,7 +73,7 @@ allow dom0_t domio_t:mmu { map_read map_write };
 
 domain_self_comms(dom0_t)
 
-auditallow dom0_t security_t:security { load_policy setenforce };
+auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
 ###############################################################################
 #
@@ -92,6 +92,14 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+gen_bool(prot_doms_locked, false)
+declare_domain(prot_domU_t)
+if (!prot_doms_locked) {
+	create_domain(dom0_t, prot_domU_t)
+}
+domain_comms(dom0_t, prot_domU_t)
+domain_comms(domU_t, prot_domU_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYq-0006cK-J8; Wed, 01 Feb 2012 19:09:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYn-0006b4-W5
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328123370!4654214!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8762 invoked from network); 1 Feb 2012 19:09:31 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Ufo015477
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S61004479; 
	Wed, 1 Feb 2012 14:09:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:19 -0500
Message-Id: <1328123365-12490-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/8] xsm/flask: allow policy booleans to be
	addressed by name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Booleans are currently only addressable by using a sequence number that
is not easily accessible to tools. Add new FLASK operations to get/set
booleans by name, and to get the name of a boolean given its ID.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/include/public/xsm/flask_op.h   |    5 +-
 xen/xsm/flask/flask_op.c            |  159 ++++++++++++++++++++++++++++++-----
 xen/xsm/flask/include/conditional.h |    5 +-
 xen/xsm/flask/ss/services.c         |   75 +++++++++++++----
 4 files changed, 207 insertions(+), 37 deletions(-)

diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index e2dd403..416ac08 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -47,8 +47,11 @@
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
+#define FLASK_GETBOOL_NAMED     23
+#define FLASK_GETBOOL2          24
+#define FLASK_SETBOOL_NAMED     25
 
-#define FLASK_LAST              FLASK_DEL_OCONTEXT
+#define FLASK_LAST              FLASK_SETBOOL_NAMED
 
 typedef struct flask_op {
     uint32_t  cmd;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 265a3cf..64d9ec5 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -47,7 +47,10 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_SETAVC_THRESHOLD | \
         1UL<<FLASK_MEMBER | \
         1UL<<FLASK_ADD_OCONTEXT | \
-        1UL<<FLASK_DEL_OCONTEXT \
+        1UL<<FLASK_DEL_OCONTEXT | \
+        1UL<<FLASK_GETBOOL_NAMED | \
+        1UL<<FLASK_GETBOOL2 | \
+        1UL<<FLASK_SETBOOL_NAMED \
     )
 
 #define FLASK_COPY_OUT \
@@ -65,7 +68,9 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_GETAVC_THRESHOLD | \
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
-        1UL<<FLASK_MEMBER \
+        1UL<<FLASK_MEMBER | \
+        1UL<<FLASK_GETBOOL_NAMED | \
+        1UL<<FLASK_GETBOOL2 \
     )
 
 static DEFINE_SPINLOCK(sel_sem);
@@ -73,6 +78,7 @@ static DEFINE_SPINLOCK(sel_sem);
 /* global data for booleans */
 static int bool_num = 0;
 static int *bool_pending_values = NULL;
+static int flask_security_make_bools(void);
 
 extern int ss_initialized;
 
@@ -573,7 +579,7 @@ static int flask_security_setavc_threshold(char *buf, uint32_t count)
 static int flask_security_set_bool(char *buf, uint32_t count)
 {
     int length = -EFAULT;
-    int i, new_value;
+    unsigned int i, new_value;
 
     spin_lock(&sel_sem);
 
@@ -585,10 +591,14 @@ static int flask_security_set_bool(char *buf, uint32_t count)
     if ( sscanf(buf, "%d %d", &i, &new_value) != 2 )
         goto out;
 
+    if (!bool_pending_values)
+        flask_security_make_bools();
+
+    if ( i >= bool_num )
+        goto out;
+
     if ( new_value )
-    {
         new_value = 1;
-    }
 
     bool_pending_values[i] = new_value;
     length = count;
@@ -598,6 +608,57 @@ static int flask_security_set_bool(char *buf, uint32_t count)
     return length;
 }
 
+static int flask_security_set_bool_name(char *buf, uint32_t count)
+{
+    int rv, num;
+    int i, new_value, commit;
+    int *values = NULL;
+    char *name;
+    
+    name = xmalloc_bytes(count);
+    if ( name == NULL )
+        return -ENOMEM;
+
+    spin_lock(&sel_sem);
+
+    rv = domain_has_security(current->domain, SECURITY__SETBOOL);
+    if ( rv )
+        goto out;
+    
+    rv = -EINVAL;
+    if ( sscanf(buf, "%s %d %d", name, &new_value, &commit) != 3 )
+        goto out;
+
+    i = security_find_bool(name);
+    if ( i < 0 )
+        goto out;
+
+    if ( new_value )
+        new_value = 1;
+
+    if ( commit ) {
+        rv = security_get_bools(&num, NULL, &values);
+        if ( rv != 0 )
+            goto out;
+        values[i] = new_value;
+        if (bool_pending_values)
+            bool_pending_values[i] = new_value;
+        rv = security_set_bools(num, values);
+        xfree(values);
+    } else {
+        if (!bool_pending_values)
+            flask_security_make_bools();
+
+        bool_pending_values[i] = new_value;
+        rv = count;
+    }
+
+ out:
+    xfree(name);
+    spin_unlock(&sel_sem);
+    return rv;
+}
+
 static int flask_security_commit_bools(char *buf, uint32_t count)
 {
     int length = -EFAULT;
@@ -613,7 +674,7 @@ static int flask_security_commit_bools(char *buf, uint32_t count)
     if ( sscanf(buf, "%d", &new_value) != 1 )
         goto out;
 
-    if ( new_value )
+    if ( new_value && bool_pending_values )
         security_set_bools(bool_num, bool_pending_values);
     
     length = count;
@@ -623,10 +684,11 @@ static int flask_security_commit_bools(char *buf, uint32_t count)
     return length;
 }
 
-static int flask_security_get_bool(char *buf, uint32_t count)
+static int flask_security_get_bool(char *buf, uint32_t count, int named)
 {
     int length;
-    int i, cur_enforcing;
+    int i, cur_enforcing, pend_enforcing;
+    char* name = NULL;
     
     spin_lock(&sel_sem);
     
@@ -641,25 +703,70 @@ static int flask_security_get_bool(char *buf, uint32_t count)
         goto out;
     }
 
+    if ( bool_pending_values )
+        pend_enforcing = bool_pending_values[i];
+    else
+        pend_enforcing = cur_enforcing;
+
+    if ( named )
+        name = security_get_bool_name(i);
+    if ( named && !name )
+        goto out;
+
     memset(buf, 0, count);
-    length = snprintf(buf, count, "%d %d", cur_enforcing,
-                      bool_pending_values[i]);
+    if ( named )
+        length = snprintf(buf, count, "%d %d %s", cur_enforcing,
+                          pend_enforcing, name);
+    else
+        length = snprintf(buf, count, "%d %d", cur_enforcing,
+                          pend_enforcing);
 
  out:
+    xfree(name);
     spin_unlock(&sel_sem);
     return length;
 }
 
+static int flask_security_get_bool_name(char *buf, uint32_t count)
+{
+    int rv = -ENOENT;
+    int i, cur_enforcing, pend_enforcing;
+    
+    spin_lock(&sel_sem);
+    
+    i = security_find_bool(buf);
+    if ( i < 0 )
+        goto out;
+
+    cur_enforcing = security_get_bool_value(i);
+    if ( cur_enforcing < 0 )
+    {
+        rv = cur_enforcing;
+        goto out;
+    }
+
+    if ( bool_pending_values )
+        pend_enforcing = bool_pending_values[i];
+    else
+        pend_enforcing = cur_enforcing;
+
+    memset(buf, 0, count);
+    rv = snprintf(buf, count, "%d %d", cur_enforcing, pend_enforcing);
+
+ out:
+    spin_unlock(&sel_sem);
+    return rv;
+}
+
 static int flask_security_make_bools(void)
 {
-    int i, ret = 0;
-    char **names = NULL;
+    int ret = 0;
     int num;
     int *values = NULL;
     
     xfree(bool_pending_values);
     
-    ret = security_get_bools(&num, &names, &values);
+    ret = security_get_bools(&num, NULL, &values);
     if ( ret != 0 )
         goto out;
 
@@ -667,12 +774,6 @@ static int flask_security_make_bools(void)
     bool_pending_values = values;
 
  out:
-    if ( names )
-    {
-        for ( i = 0; i < num; i++ )
-            xfree(names[i]);
-        xfree(names);
-    }    
     return ret;
 }
 
@@ -938,7 +1039,7 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 
     case FLASK_GETBOOL:
     {
-        length = flask_security_get_bool(arg, op->size);
+        length = flask_security_get_bool(arg, op->size, 0);
     }
     break;
 
@@ -1010,6 +1111,24 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         break;
     }
 
+    case FLASK_GETBOOL_NAMED:
+    {
+        length = flask_security_get_bool_name(arg, op->size);
+    }
+    break;
+
+    case FLASK_GETBOOL2:
+    {
+        length = flask_security_get_bool(arg, op->size, 1);
+    }
+    break;
+
+    case FLASK_SETBOOL_NAMED:
+    {
+        length = flask_security_set_bool_name(arg, op->size);
+    }
+    break;
+
     default:
         length = -ENOSYS;
         break;
diff --git a/xen/xsm/flask/include/conditional.h b/xen/xsm/flask/include/conditional.h
index bd3eb92..2fa0a30 100644
--- a/xen/xsm/flask/include/conditional.h
+++ b/xen/xsm/flask/include/conditional.h
@@ -17,6 +17,9 @@ int security_get_bools(int *len, char ***names, int **values);
 
 int security_set_bools(int len, int *values);
 
-int security_get_bool_value(int bool);
+int security_find_bool(const char *name);
+
+char *security_get_bool_name(unsigned int bool);
+int security_get_bool_value(unsigned int bool);
 
 #endif
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 3b0acf5..0189baf 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1883,12 +1883,30 @@ out:
     return rc;
 }
 
+int security_find_bool(const char *name)
+{
+    int i, rv = -ENOENT;
+    POLICY_RDLOCK;
+    for ( i = 0; i < policydb.p_bools.nprim; i++ )
+    {
+        if (!strcmp(name, policydb.p_bool_val_to_name[i]))
+        {
+            rv = i;
+            break;
+        }
+    }
+
+    POLICY_RDUNLOCK;
+    return rv;
+}
+
 int security_get_bools(int *len, char ***names, int **values)
 {
     int i, rc = -ENOMEM;
 
     POLICY_RDLOCK;
-    *names = NULL;
+    if ( names )
+        *names = NULL;
     *values = NULL;
 
     *len = policydb.p_bools.nprim;
@@ -1898,10 +1916,12 @@ int security_get_bools(int *len, char ***names, int **values)
         goto out;
     }
 
-    *names = (char**)xmalloc_array(char*, *len);
-    if ( !*names )
-        goto err;
-    memset(*names, 0, sizeof(char*) * *len);
+    if ( names ) {
+        *names = (char**)xmalloc_array(char*, *len);
+        if ( !*names )
+            goto err;
+        memset(*names, 0, sizeof(char*) * *len);
+    }
 
     *values = (int*)xmalloc_array(int, *len);
     if ( !*values )
@@ -1911,19 +1931,21 @@ int security_get_bools(int *len, char ***names, int **values)
     {
         size_t name_len;
         (*values)[i] = policydb.bool_val_to_struct[i]->state;
-        name_len = strlen(policydb.p_bool_val_to_name[i]) + 1;
-        (*names)[i] = (char*)xmalloc_array(char, name_len);
-        if ( !(*names)[i] )
-            goto err;
-        strlcpy((*names)[i], policydb.p_bool_val_to_name[i], name_len);
-        (*names)[i][name_len - 1] = 0;
+        if ( names ) {
+            name_len = strlen(policydb.p_bool_val_to_name[i]) + 1;
+            (*names)[i] = (char*)xmalloc_array(char, name_len);
+            if ( !(*names)[i] )
+                goto err;
+            strlcpy((*names)[i], policydb.p_bool_val_to_name[i], name_len);
+            (*names)[i][name_len - 1] = 0;
+        }
     }
     rc = 0;
 out:
     POLICY_RDUNLOCK;
     return rc;
 err:
-    if ( *names )
+    if ( names && *names )
     {
         for ( i = 0; i < *len; i++ )
             xfree((*names)[i]);
@@ -1984,17 +2006,17 @@ out:
     return rc;
 }
 
-int security_get_bool_value(int bool)
+int security_get_bool_value(unsigned int bool)
 {
     int rc = 0;
-    int len;
+    unsigned int len;
 
     POLICY_RDLOCK;
 
     len = policydb.p_bools.nprim;
     if ( bool >= len )
     {
-        rc = -EFAULT;
+        rc = -ENOENT;
         goto out;
     }
 
@@ -2004,6 +2026,29 @@ out:
     return rc;
 }
 
+char *security_get_bool_name(unsigned int bool)
+{
+    unsigned int len;
+    char *rv = NULL;
+
+    POLICY_RDLOCK;
+
+    len = policydb.p_bools.nprim;
+    if ( bool >= len )
+    {
+        goto out;
+    }
+
+    len = strlen(policydb.p_bool_val_to_name[bool]) + 1;
+    rv = xmalloc_array(char, len);
+    if ( !rv )
+        goto out;
+    memcpy(rv, policydb.p_bool_val_to_name[bool], len);
+out:
+    POLICY_RDUNLOCK;
+    return rv;
+}
+
 static int security_preserve_bools(struct policydb *p)
 {
     int rc, nbools = 0, *bvalues = NULL, i;
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYr-0006cd-MX; Wed, 01 Feb 2012 19:09:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYo-0006b6-L4
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328123372!3616600!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 1 Feb 2012 19:09:32 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:32 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Vfo015483
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S66004479; 
	Wed, 1 Feb 2012 14:09:31 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:24 -0500
Message-Id: <1328123365-12490-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 7/8] flask/policy: add device model types to
	example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds an example user for device_model_stubdomain_seclabel.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |    4 ++++
 tools/flask/policy/policy/modules/xen/xen.if |   11 ++++++++++-
 tools/flask/policy/policy/modules/xen/xen.te |   13 +++++++++++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 5b4297d..e2e415d 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -61,6 +61,10 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
 
+HVM domains with stubdomain device models use two types (one per domain):
+ - domHVM_t is an HVM domain that uses a stubdomain device model
+ - 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
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index dde7f90..87ef165 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -25,7 +25,7 @@ define(`create_domain', `
 	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 };
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
 	allow $1 $2_$1_channel:event create;
 ')
 
@@ -36,6 +36,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setvcpuaffinity setdomainmaxmem };
 ')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -75,6 +76,14 @@ define(`domain_self_comms', `
 	allow $1 $1: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 };
+')
 ################################################################################
 #
 # Device types and delegation (PCI passthrough)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index f7343a2..29885c4 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -100,6 +100,19 @@ if (!prot_doms_locked) {
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, 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)
+create_domain(dom0_t, domHVM_t)
+manage_domain(dom0_t, domHVM_t)
+domain_comms(dom0_t, domHVM_t)
+domain_self_comms(domHVM_t)
+
+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)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYr-0006cU-9b; Wed, 01 Feb 2012 19:09:41 +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 1RsfYo-0006b5-Bv
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328123342!58086453!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19704 invoked from network); 1 Feb 2012 19:09:03 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:09:03 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Uiq025824
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S63004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:21 -0500
Message-Id: <1328123365-12490-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 4/8] flask: add flask-{get,set}-bool tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These utilities can be used to modify policy booleans, which allow
minor policy changes without reloading the security policy. This can be
used to make security policy change based on external information such
as time of day, user physical presence, completion of system boot, or
other relevant variables.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/Makefile   |    8 +++-
 tools/flask/utils/get-bool.c |   90 ++++++++++++++++++++++++++++++++++++++++++
 tools/flask/utils/set-bool.c |   72 +++++++++++++++++++++++++++++++++
 3 files changed, 169 insertions(+), 1 deletions(-)
 create mode 100644 tools/flask/utils/get-bool.c
 create mode 100644 tools/flask/utils/set-bool.c

diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index 171a728..3ac6ac2 100644
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -11,7 +11,7 @@ TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
 TESTENV  = XENSTORED_ROOTDIR=$(TESTDIR) XENSTORED_RUNDIR=$(TESTDIR)
 
-CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce flask-label-pci
+CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce flask-label-pci flask-get-bool flask-set-bool
 CLIENTS_SRCS := $(patsubst flask-%,%.c,$(CLIENTS))
 CLIENTS_OBJS := $(patsubst flask-%,%.o,$(CLIENTS))
 
@@ -30,6 +30,12 @@ flask-getenforce: getenforce.o
 flask-label-pci: label-pci.o
 	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
 
+flask-get-bool: get-bool.o
+	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+
+flask-set-bool: set-bool.o
+	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+
 .PHONY: clean
 clean: 
 	rm -f *.o *.opic *.so
diff --git a/tools/flask/utils/get-bool.c b/tools/flask/utils/get-bool.c
new file mode 100644
index 0000000..c0cd7c8
--- /dev/null
+++ b/tools/flask/utils/get-bool.c
@@ -0,0 +1,90 @@
+/*
+ *  Author:  Daniel De Graaf <dgdegra@tycho.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 <stdlib.h>
+#include <errno.h>
+#include <stdio.h>
+#include <xenctrl.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <string.h>
+#include <unistd.h>
+#include <inttypes.h>
+#include <libflask.h>
+
+static void usage(char **argv)
+{
+	fprintf(stderr, "Usage: %s {name|-a}\n", argv[0]);
+	exit(1);
+}
+
+static int all_bools(xc_interface *xch)
+{
+	int err = 0, i = 0, curr, pend;
+	char name[256];
+	while (1) {
+		err = flask_getbool_byid(xch, i, name, &curr, &pend);
+		if (err < 0) {
+			if (errno == ENOENT)
+				return 0;
+			fprintf(stderr, "flask_getbool: Unable to get boolean #%d: %s (%d)",
+				i, strerror(errno), err);
+			return 2;
+		}
+		if (curr == pend)
+			printf("%s: %d\n", name, curr);
+		else
+			printf("%s: %d (pending %d)\n", name, curr, pend);
+		i++;
+	}
+}
+
+int main(int argc, char **argv)
+{
+	int err = 0;
+	xc_interface *xch;
+	int curr, pend;
+
+	if (argc != 2)
+		usage(argv);
+
+	xch = xc_interface_open(0,0,0);
+	if ( !xch )
+	{
+		fprintf(stderr, "Unable to create interface to xenctrl: %s\n",
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	if (!strcmp(argv[1], "-a"))
+	{
+		err = all_bools(xch);
+		goto done;
+	}
+
+	err = flask_getbool_byname(xch, argv[1], &curr, &pend);
+	if (err) {
+		fprintf(stderr, "flask_getbool: Unable to get boolean %s: %s (%d)",
+			argv[1], strerror(errno), err);
+		err = 2;
+		goto done;
+	}
+
+	if (curr == pend)
+		printf("%s: %d\n", argv[1], curr);
+	else
+		printf("%s: %d (pending %d)\n", argv[1], curr, pend);
+
+ done:
+	if ( xch )
+		xc_interface_close(xch);
+
+	return err;
+}
diff --git a/tools/flask/utils/set-bool.c b/tools/flask/utils/set-bool.c
new file mode 100644
index 0000000..cde25cd
--- /dev/null
+++ b/tools/flask/utils/set-bool.c
@@ -0,0 +1,72 @@
+/*
+ *  Author:  Daniel De Graaf <dgdegra@tycho.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 <stdlib.h>
+#include <errno.h>
+#include <stdio.h>
+#include <xenctrl.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <string.h>
+#include <unistd.h>
+#include <inttypes.h>
+#include <libflask.h>
+
+static void usage(char **argv)
+{
+	fprintf(stderr, "Usage: %s name value\n", argv[0]);
+	exit(1);
+}
+
+static int str2bool(const char *str)
+{
+	if (str[0] == '0' || str[0] == '1')
+		return (str[0] == '1');
+	if (!strcasecmp(str, "enabled") || !strcasecmp(str, "on") || !strcasecmp(str, "y"))
+		return 1;
+	if (!strcasecmp(str, "disabled") || !strcasecmp(str, "off") || !strcasecmp(str, "n"))
+		return 0;
+	fprintf(stderr, "Unknown value %s\n", str);
+	exit(1);
+}
+
+int main(int argc, char **argv)
+{
+	int err = 0;
+	xc_interface *xch;
+	int value;
+
+	if (argc != 3)
+		usage(argv);
+
+	value = str2bool(argv[2]);
+
+	xch = xc_interface_open(0,0,0);
+	if ( !xch )
+	{
+		fprintf(stderr, "Unable to create interface to xenctrl: %s\n",
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	err = flask_setbool(xch, argv[1], value, 1);
+	if (err) {
+		fprintf(stderr, "flask_setbool: Unable to set boolean %s=%s: %s (%d)",
+			argv[1], argv[2], strerror(errno), err);
+		err = 2;
+		goto done;
+	}
+
+ done:
+	if ( xch )
+		xc_interface_close(xch);
+
+	return err;
+}
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYq-0006cK-J8; Wed, 01 Feb 2012 19:09:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYn-0006b4-W5
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328123370!4654214!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8762 invoked from network); 1 Feb 2012 19:09:31 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Ufo015477
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:30 GMT
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 q11J9S61004479; 
	Wed, 1 Feb 2012 14:09:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:19 -0500
Message-Id: <1328123365-12490-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/8] xsm/flask: allow policy booleans to be
	addressed by name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Booleans are currently only addressable by using a sequence number that
is not easily accessible to tools. Add new FLASK operations to get/set
booleans by name, and to get the name of a boolean given its ID.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/include/public/xsm/flask_op.h   |    5 +-
 xen/xsm/flask/flask_op.c            |  159 ++++++++++++++++++++++++++++++-----
 xen/xsm/flask/include/conditional.h |    5 +-
 xen/xsm/flask/ss/services.c         |   75 +++++++++++++----
 4 files changed, 207 insertions(+), 37 deletions(-)

diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index e2dd403..416ac08 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -47,8 +47,11 @@
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
+#define FLASK_GETBOOL_NAMED     23
+#define FLASK_GETBOOL2          24
+#define FLASK_SETBOOL_NAMED     25
 
-#define FLASK_LAST              FLASK_DEL_OCONTEXT
+#define FLASK_LAST              FLASK_SETBOOL_NAMED
 
 typedef struct flask_op {
     uint32_t  cmd;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 265a3cf..64d9ec5 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -47,7 +47,10 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_SETAVC_THRESHOLD | \
         1UL<<FLASK_MEMBER | \
         1UL<<FLASK_ADD_OCONTEXT | \
-        1UL<<FLASK_DEL_OCONTEXT \
+        1UL<<FLASK_DEL_OCONTEXT | \
+        1UL<<FLASK_GETBOOL_NAMED | \
+        1UL<<FLASK_GETBOOL2 | \
+        1UL<<FLASK_SETBOOL_NAMED \
     )
 
 #define FLASK_COPY_OUT \
@@ -65,7 +68,9 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_GETAVC_THRESHOLD | \
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
-        1UL<<FLASK_MEMBER \
+        1UL<<FLASK_MEMBER | \
+        1UL<<FLASK_GETBOOL_NAMED | \
+        1UL<<FLASK_GETBOOL2 \
     )
 
 static DEFINE_SPINLOCK(sel_sem);
@@ -73,6 +78,7 @@ static DEFINE_SPINLOCK(sel_sem);
 /* global data for booleans */
 static int bool_num = 0;
 static int *bool_pending_values = NULL;
+static int flask_security_make_bools(void);
 
 extern int ss_initialized;
 
@@ -573,7 +579,7 @@ static int flask_security_setavc_threshold(char *buf, uint32_t count)
 static int flask_security_set_bool(char *buf, uint32_t count)
 {
     int length = -EFAULT;
-    int i, new_value;
+    unsigned int i, new_value;
 
     spin_lock(&sel_sem);
 
@@ -585,10 +591,14 @@ static int flask_security_set_bool(char *buf, uint32_t count)
     if ( sscanf(buf, "%d %d", &i, &new_value) != 2 )
         goto out;
 
+    if (!bool_pending_values)
+        flask_security_make_bools();
+
+    if ( i >= bool_num )
+        goto out;
+
     if ( new_value )
-    {
         new_value = 1;
-    }
 
     bool_pending_values[i] = new_value;
     length = count;
@@ -598,6 +608,57 @@ static int flask_security_set_bool(char *buf, uint32_t count)
     return length;
 }
 
+static int flask_security_set_bool_name(char *buf, uint32_t count)
+{
+    int rv, num;
+    int i, new_value, commit;
+    int *values = NULL;
+    char *name;
+    
+    name = xmalloc_bytes(count);
+    if ( name == NULL )
+        return -ENOMEM;
+
+    spin_lock(&sel_sem);
+
+    rv = domain_has_security(current->domain, SECURITY__SETBOOL);
+    if ( rv )
+        goto out;
+    
+    rv = -EINVAL;
+    if ( sscanf(buf, "%s %d %d", name, &new_value, &commit) != 3 )
+        goto out;
+
+    i = security_find_bool(name);
+    if ( i < 0 )
+        goto out;
+
+    if ( new_value )
+        new_value = 1;
+
+    if ( commit ) {
+        rv = security_get_bools(&num, NULL, &values);
+        if ( rv != 0 )
+            goto out;
+        values[i] = new_value;
+        if (bool_pending_values)
+            bool_pending_values[i] = new_value;
+        rv = security_set_bools(num, values);
+        xfree(values);
+    } else {
+        if (!bool_pending_values)
+            flask_security_make_bools();
+
+        bool_pending_values[i] = new_value;
+        rv = count;
+    }
+
+ out:
+    xfree(name);
+    spin_unlock(&sel_sem);
+    return rv;
+}
+
 static int flask_security_commit_bools(char *buf, uint32_t count)
 {
     int length = -EFAULT;
@@ -613,7 +674,7 @@ static int flask_security_commit_bools(char *buf, uint32_t count)
     if ( sscanf(buf, "%d", &new_value) != 1 )
         goto out;
 
-    if ( new_value )
+    if ( new_value && bool_pending_values )
         security_set_bools(bool_num, bool_pending_values);
     
     length = count;
@@ -623,10 +684,11 @@ static int flask_security_commit_bools(char *buf, uint32_t count)
     return length;
 }
 
-static int flask_security_get_bool(char *buf, uint32_t count)
+static int flask_security_get_bool(char *buf, uint32_t count, int named)
 {
     int length;
-    int i, cur_enforcing;
+    int i, cur_enforcing, pend_enforcing;
+    char* name = NULL;
     
     spin_lock(&sel_sem);
     
@@ -641,25 +703,70 @@ static int flask_security_get_bool(char *buf, uint32_t count)
         goto out;
     }
 
+    if ( bool_pending_values )
+        pend_enforcing = bool_pending_values[i];
+    else
+        pend_enforcing = cur_enforcing;
+
+    if ( named )
+        name = security_get_bool_name(i);
+    if ( named && !name )
+        goto out;
+
     memset(buf, 0, count);
-    length = snprintf(buf, count, "%d %d", cur_enforcing,
-                      bool_pending_values[i]);
+    if ( named )
+        length = snprintf(buf, count, "%d %d %s", cur_enforcing,
+                          pend_enforcing, name);
+    else
+        length = snprintf(buf, count, "%d %d", cur_enforcing,
+                          pend_enforcing);
 
  out:
+    xfree(name);
     spin_unlock(&sel_sem);
     return length;
 }
 
+static int flask_security_get_bool_name(char *buf, uint32_t count)
+{
+    int rv = -ENOENT;
+    int i, cur_enforcing, pend_enforcing;
+    
+    spin_lock(&sel_sem);
+    
+    i = security_find_bool(buf);
+    if ( i < 0 )
+        goto out;
+
+    cur_enforcing = security_get_bool_value(i);
+    if ( cur_enforcing < 0 )
+    {
+        rv = cur_enforcing;
+        goto out;
+    }
+
+    if ( bool_pending_values )
+        pend_enforcing = bool_pending_values[i];
+    else
+        pend_enforcing = cur_enforcing;
+
+    memset(buf, 0, count);
+    rv = snprintf(buf, count, "%d %d", cur_enforcing, pend_enforcing);
+
+ out:
+    spin_unlock(&sel_sem);
+    return rv;
+}
+
 static int flask_security_make_bools(void)
 {
-    int i, ret = 0;
-    char **names = NULL;
+    int ret = 0;
     int num;
     int *values = NULL;
     
     xfree(bool_pending_values);
     
-    ret = security_get_bools(&num, &names, &values);
+    ret = security_get_bools(&num, NULL, &values);
     if ( ret != 0 )
         goto out;
 
@@ -667,12 +774,6 @@ static int flask_security_make_bools(void)
     bool_pending_values = values;
 
  out:
-    if ( names )
-    {
-        for ( i = 0; i < num; i++ )
-            xfree(names[i]);
-        xfree(names);
-    }    
     return ret;
 }
 
@@ -938,7 +1039,7 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 
     case FLASK_GETBOOL:
     {
-        length = flask_security_get_bool(arg, op->size);
+        length = flask_security_get_bool(arg, op->size, 0);
     }
     break;
 
@@ -1010,6 +1111,24 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         break;
     }
 
+    case FLASK_GETBOOL_NAMED:
+    {
+        length = flask_security_get_bool_name(arg, op->size);
+    }
+    break;
+
+    case FLASK_GETBOOL2:
+    {
+        length = flask_security_get_bool(arg, op->size, 1);
+    }
+    break;
+
+    case FLASK_SETBOOL_NAMED:
+    {
+        length = flask_security_set_bool_name(arg, op->size);
+    }
+    break;
+
     default:
         length = -ENOSYS;
         break;
diff --git a/xen/xsm/flask/include/conditional.h b/xen/xsm/flask/include/conditional.h
index bd3eb92..2fa0a30 100644
--- a/xen/xsm/flask/include/conditional.h
+++ b/xen/xsm/flask/include/conditional.h
@@ -17,6 +17,9 @@ int security_get_bools(int *len, char ***names, int **values);
 
 int security_set_bools(int len, int *values);
 
-int security_get_bool_value(int bool);
+int security_find_bool(const char *name);
+
+char *security_get_bool_name(unsigned int bool);
+int security_get_bool_value(unsigned int bool);
 
 #endif
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 3b0acf5..0189baf 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1883,12 +1883,30 @@ out:
     return rc;
 }
 
+int security_find_bool(const char *name)
+{
+    int i, rv = -ENOENT;
+    POLICY_RDLOCK;
+    for ( i = 0; i < policydb.p_bools.nprim; i++ )
+    {
+        if (!strcmp(name, policydb.p_bool_val_to_name[i]))
+        {
+            rv = i;
+            break;
+        }
+    }
+
+    POLICY_RDUNLOCK;
+    return rv;
+}
+
 int security_get_bools(int *len, char ***names, int **values)
 {
     int i, rc = -ENOMEM;
 
     POLICY_RDLOCK;
-    *names = NULL;
+    if ( names )
+        *names = NULL;
     *values = NULL;
 
     *len = policydb.p_bools.nprim;
@@ -1898,10 +1916,12 @@ int security_get_bools(int *len, char ***names, int **values)
         goto out;
     }
 
-    *names = (char**)xmalloc_array(char*, *len);
-    if ( !*names )
-        goto err;
-    memset(*names, 0, sizeof(char*) * *len);
+    if ( names ) {
+        *names = (char**)xmalloc_array(char*, *len);
+        if ( !*names )
+            goto err;
+        memset(*names, 0, sizeof(char*) * *len);
+    }
 
     *values = (int*)xmalloc_array(int, *len);
     if ( !*values )
@@ -1911,19 +1931,21 @@ int security_get_bools(int *len, char ***names, int **values)
     {
         size_t name_len;
         (*values)[i] = policydb.bool_val_to_struct[i]->state;
-        name_len = strlen(policydb.p_bool_val_to_name[i]) + 1;
-        (*names)[i] = (char*)xmalloc_array(char, name_len);
-        if ( !(*names)[i] )
-            goto err;
-        strlcpy((*names)[i], policydb.p_bool_val_to_name[i], name_len);
-        (*names)[i][name_len - 1] = 0;
+        if ( names ) {
+            name_len = strlen(policydb.p_bool_val_to_name[i]) + 1;
+            (*names)[i] = (char*)xmalloc_array(char, name_len);
+            if ( !(*names)[i] )
+                goto err;
+            strlcpy((*names)[i], policydb.p_bool_val_to_name[i], name_len);
+            (*names)[i][name_len - 1] = 0;
+        }
     }
     rc = 0;
 out:
     POLICY_RDUNLOCK;
     return rc;
 err:
-    if ( *names )
+    if ( names && *names )
     {
         for ( i = 0; i < *len; i++ )
             xfree((*names)[i]);
@@ -1984,17 +2006,17 @@ out:
     return rc;
 }
 
-int security_get_bool_value(int bool)
+int security_get_bool_value(unsigned int bool)
 {
     int rc = 0;
-    int len;
+    unsigned int len;
 
     POLICY_RDLOCK;
 
     len = policydb.p_bools.nprim;
     if ( bool >= len )
     {
-        rc = -EFAULT;
+        rc = -ENOENT;
         goto out;
     }
 
@@ -2004,6 +2026,29 @@ out:
     return rc;
 }
 
+char *security_get_bool_name(unsigned int bool)
+{
+    unsigned int len;
+    char *rv = NULL;
+
+    POLICY_RDLOCK;
+
+    len = policydb.p_bools.nprim;
+    if ( bool >= len )
+    {
+        goto out;
+    }
+
+    len = strlen(policydb.p_bool_val_to_name[bool]) + 1;
+    rv = xmalloc_array(char, len);
+    if ( !rv )
+        goto out;
+    memcpy(rv, policydb.p_bool_val_to_name[bool], len);
+out:
+    POLICY_RDUNLOCK;
+    return rv;
+}
+
 static int security_preserve_bools(struct policydb *p)
 {
     int rc, nbools = 0, *bvalues = NULL, i;
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYs-0006co-3D; Wed, 01 Feb 2012 19:09:42 +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 1RsfYo-0006b8-U4
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328123335!50703165!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9790 invoked from network); 1 Feb 2012 19:08:55 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:08:55 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Viq025839
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S67004479; 
	Wed, 1 Feb 2012 14:09:31 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:25 -0500
Message-Id: <1328123365-12490-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 8/8] xsm/flask: Improve domain ID auditing in
	AVCs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         |   17 ++++++++++++-----
 xen/xsm/flask/hooks.c       |   18 ++++++++++++++++--
 xen/xsm/flask/include/avc.h |    4 +++-
 3 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 9475d92..3a60a3a 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -539,7 +539,7 @@ static struct avc_node *avc_insert(u32 ssid, u32 tsid, u16 tclass,
 void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
                struct av_decision *avd, int result, struct avc_audit_data *a)
 {
-    struct domain *d = current->domain;
+    struct domain *cdom = current->domain;
     u32 denied, audited;
 
     denied = requested & ~avd->allowed;
@@ -564,10 +564,17 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
     avc_dump_av(tclass, audited);
     printk(" for ");
 
-    if ( a && a->d )
-        d = a->d;
-    if ( d )
-        printk("domid=%d ", d->domain_id);
+    if ( a && (a->sdom || a->tdom) )
+    {
+        if ( a->sdom && a->tdom && a->sdom != a->tdom )
+            printk("domid=%d target=%d ", a->sdom->domain_id, a->tdom->domain_id);
+        else if ( a->sdom )
+            printk("domid=%d ", a->sdom->domain_id);
+        else
+            printk("target=%d ", a->tdom->domain_id);
+    }
+    else if ( cdom )
+        printk("domid=%d ", cdom->domain_id);
     switch ( a ? a->type : 0 ) {
     case AVC_AUDIT_DATA_DEV:
         printk("device=0x%lx ", a->device);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index ad1013f..649c473 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -37,11 +37,15 @@ static int domain_has_perm(struct domain *dom1, struct domain *dom2,
                            u16 class, u32 perms)
 {
     struct domain_security_struct *dsec1, *dsec2;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+    ad.sdom = dom1;
+    ad.tdom = dom2;
 
     dsec1 = dom1->ssid;
     dsec2 = dom2->ssid;
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, NULL);
+    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
 }
 
 static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
@@ -1323,6 +1327,7 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *t,
     unsigned long fmfn;
     struct domain_security_struct *dsec;
     u32 fsid;
+    struct avc_audit_data ad;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1337,13 +1342,22 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *t,
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
         map_perms |= MMU__MAP_WRITE;
 
+    AVC_AUDIT_DATA_INIT(&ad, RANGE);
     fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
 
+    ad.sdom = d;
+    ad.tdom = f;
+    ad.range.start = fpte;
+    ad.range.end = fmfn;
+
     rc = get_mfn_sid(fmfn, &fsid);
+
+    put_gfn(f, fmfn);
+
     if ( rc )
         return rc;
 
-    return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, NULL);
+    return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
 }
 
 static int flask_mmu_machphys_update(struct domain *d, unsigned long mfn)
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 1b19189..8fffbb6 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -38,10 +38,12 @@ struct sk_buff;
 /* Auxiliary data to use in generating the audit record. */
 struct avc_audit_data {
     char    type;
+#define AVC_AUDIT_DATA_NONE  0
 #define AVC_AUDIT_DATA_DEV   1
 #define AVC_AUDIT_DATA_IRQ   2
 #define AVC_AUDIT_DATA_RANGE 3
-    struct domain *d;
+    struct domain *sdom;
+    struct domain *tdom;
     union {
         unsigned long device;
         int irq;
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYl-0006bI-11; Wed, 01 Feb 2012 19:09:35 +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 1RsfYj-0006b7-SP
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328123253!62139805!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15426 invoked from network); 1 Feb 2012 19:07:34 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:07:34 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Viq025832
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S65004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:23 -0500
Message-Id: <1328123365-12490-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 6/8] libxl: Add device_model_stubdomain_seclabel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This allows the security label of stub domains to be specified.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/man/xl.cfg.pod.5       |    4 ++++
 tools/libxl/libxl_dm.c      |    1 +
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |   12 ++++++++++++
 4 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9d90290..8f171b4 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -789,6 +789,10 @@ 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 devide-model command
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5fec137..e99d173 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -703,6 +703,7 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
+    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 3c24626..b77bc65 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -217,6 +217,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too
     ("device_model",     string),
+    ("device_model_ssidref", uint32),
 
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0b811b5..e95bace 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1254,6 +1254,18 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         b_info->device_model_stubdomain = l;
 
+    if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel", &buf, 0)) {
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &b_info->device_model_ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: device_model_stubdomain_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid device_model_stubdomain_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
                                     &b_info->extra##type, 0);            \
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYl-0006bI-11; Wed, 01 Feb 2012 19:09:35 +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 1RsfYj-0006b7-SP
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328123253!62139805!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15426 invoked from network); 1 Feb 2012 19:07:34 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:07:34 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Viq025832
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S65004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:23 -0500
Message-Id: <1328123365-12490-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 6/8] libxl: Add device_model_stubdomain_seclabel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This allows the security label of stub domains to be specified.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/man/xl.cfg.pod.5       |    4 ++++
 tools/libxl/libxl_dm.c      |    1 +
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |   12 ++++++++++++
 4 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9d90290..8f171b4 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -789,6 +789,10 @@ 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 devide-model command
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5fec137..e99d173 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -703,6 +703,7 @@ static int libxl__create_stubdom(libxl__gc *gc,
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
+    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 3c24626..b77bc65 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -217,6 +217,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too
     ("device_model",     string),
+    ("device_model_ssidref", uint32),
 
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0b811b5..e95bace 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1254,6 +1254,18 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         b_info->device_model_stubdomain = l;
 
+    if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel", &buf, 0)) {
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &b_info->device_model_ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: device_model_stubdomain_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid device_model_stubdomain_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
                                     &b_info->extra##type, 0);            \
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYs-0006co-3D; Wed, 01 Feb 2012 19:09:42 +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 1RsfYo-0006b8-U4
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328123335!50703165!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9790 invoked from network); 1 Feb 2012 19:08:55 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:08:55 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Viq025839
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S67004479; 
	Wed, 1 Feb 2012 14:09:31 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:25 -0500
Message-Id: <1328123365-12490-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 8/8] xsm/flask: Improve domain ID auditing in
	AVCs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         |   17 ++++++++++++-----
 xen/xsm/flask/hooks.c       |   18 ++++++++++++++++--
 xen/xsm/flask/include/avc.h |    4 +++-
 3 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 9475d92..3a60a3a 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -539,7 +539,7 @@ static struct avc_node *avc_insert(u32 ssid, u32 tsid, u16 tclass,
 void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
                struct av_decision *avd, int result, struct avc_audit_data *a)
 {
-    struct domain *d = current->domain;
+    struct domain *cdom = current->domain;
     u32 denied, audited;
 
     denied = requested & ~avd->allowed;
@@ -564,10 +564,17 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
     avc_dump_av(tclass, audited);
     printk(" for ");
 
-    if ( a && a->d )
-        d = a->d;
-    if ( d )
-        printk("domid=%d ", d->domain_id);
+    if ( a && (a->sdom || a->tdom) )
+    {
+        if ( a->sdom && a->tdom && a->sdom != a->tdom )
+            printk("domid=%d target=%d ", a->sdom->domain_id, a->tdom->domain_id);
+        else if ( a->sdom )
+            printk("domid=%d ", a->sdom->domain_id);
+        else
+            printk("target=%d ", a->tdom->domain_id);
+    }
+    else if ( cdom )
+        printk("domid=%d ", cdom->domain_id);
     switch ( a ? a->type : 0 ) {
     case AVC_AUDIT_DATA_DEV:
         printk("device=0x%lx ", a->device);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index ad1013f..649c473 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -37,11 +37,15 @@ static int domain_has_perm(struct domain *dom1, struct domain *dom2,
                            u16 class, u32 perms)
 {
     struct domain_security_struct *dsec1, *dsec2;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+    ad.sdom = dom1;
+    ad.tdom = dom2;
 
     dsec1 = dom1->ssid;
     dsec2 = dom2->ssid;
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, NULL);
+    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
 }
 
 static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
@@ -1323,6 +1327,7 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *t,
     unsigned long fmfn;
     struct domain_security_struct *dsec;
     u32 fsid;
+    struct avc_audit_data ad;
 
     if (d != t)
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
@@ -1337,13 +1342,22 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *t,
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
         map_perms |= MMU__MAP_WRITE;
 
+    AVC_AUDIT_DATA_INIT(&ad, RANGE);
     fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
 
+    ad.sdom = d;
+    ad.tdom = f;
+    ad.range.start = fpte;
+    ad.range.end = fmfn;
+
     rc = get_mfn_sid(fmfn, &fsid);
+
+    put_gfn(f, fmfn);
+
     if ( rc )
         return rc;
 
-    return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, NULL);
+    return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
 }
 
 static int flask_mmu_machphys_update(struct domain *d, unsigned long mfn)
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 1b19189..8fffbb6 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -38,10 +38,12 @@ struct sk_buff;
 /* Auxiliary data to use in generating the audit record. */
 struct avc_audit_data {
     char    type;
+#define AVC_AUDIT_DATA_NONE  0
 #define AVC_AUDIT_DATA_DEV   1
 #define AVC_AUDIT_DATA_IRQ   2
 #define AVC_AUDIT_DATA_RANGE 3
-    struct domain *d;
+    struct domain *sdom;
+    struct domain *tdom;
     union {
         unsigned long device;
         int irq;
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYl-0006bP-Cp; Wed, 01 Feb 2012 19:09:35 +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 1RsfYk-0006b1-EJ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328123327!58392387!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19999 invoked from network); 1 Feb 2012 19:08:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:08:47 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Sfo015471
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:29 GMT
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 q11J9S5x004479
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 14:09:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:17 -0500
Message-Id: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 0/8] XSM/FLASK updates part 2: booleans, stubdoms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a continuation of the previous 10-patch series updating the
FLASK XSM security module and supporting libraries/tools.

Bugfix:
[PATCH 1/8] xen/xsm: fix incorrect handling of XSM hook return

FLASK boolean addressing by name with tools:
[PATCH 2/8] xsm/flask: allow policy booleans to be addressed by name
[PATCH 3/8] libflask: Add boolean manipulation functions
[PATCH 4/8] flask: add flask-{get,set}-bool tools
[PATCH 5/8] flask/policy: Add boolean example

Device model stub domain support:
[PATCH 6/8] libxl: Add device_model_stubdomain_seclabel
[PATCH 7/8] flask/policy: add device model types to example policy

Cleanup:
[PATCH 8/8] xsm/flask: Improve domain ID auditing in AVCs

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYs-0006cz-Ft; Wed, 01 Feb 2012 19:09:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYp-0006b9-4L
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328123371!2082047!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6134 invoked from network); 1 Feb 2012 19:09:32 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:32 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Viq025829
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S64004479; 
	Wed, 1 Feb 2012 14:09:30 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:22 -0500
Message-Id: <1328123365-12490-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 5/8] flask/policy: Add boolean example
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This shows an example boolean (prot_doms_locked) which can be set at
runtime to prevent dom0 from mapping memory of domains of type
prot_domU_t.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |    3 ++-
 tools/flask/policy/policy/modules/xen/xen.te |   10 +++++++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 285bb9f..5b4297d 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -55,10 +55,11 @@ kernel; it is normally placed either just above the dom0 kernel or at the end.
 Once dom0 is running, the policy can be reloaded using "xl loadpolicy".
 
 The example policy included with Xen demonstrates most of the features of FLASK
-that can be used without dom0 disaggregation. It has two main types for domUs:
+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
 
 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
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index fb71b75..f7343a2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -73,7 +73,7 @@ allow dom0_t domio_t:mmu { map_read map_write };
 
 domain_self_comms(dom0_t)
 
-auditallow dom0_t security_t:security { load_policy setenforce };
+auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
 ###############################################################################
 #
@@ -92,6 +92,14 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+gen_bool(prot_doms_locked, false)
+declare_domain(prot_domU_t)
+if (!prot_doms_locked) {
+	create_domain(dom0_t, prot_domU_t)
+}
+domain_comms(dom0_t, prot_domU_t)
+domain_comms(domU_t, prot_domU_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYl-0006bP-Cp; Wed, 01 Feb 2012 19:09:35 +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 1RsfYk-0006b1-EJ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328123327!58392387!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19999 invoked from network); 1 Feb 2012 19:08:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:08:47 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Sfo015471
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:29 GMT
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 q11J9S5x004479
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 14:09:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:17 -0500
Message-Id: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 0/8] XSM/FLASK updates part 2: booleans, stubdoms
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a continuation of the previous 10-patch series updating the
FLASK XSM security module and supporting libraries/tools.

Bugfix:
[PATCH 1/8] xen/xsm: fix incorrect handling of XSM hook return

FLASK boolean addressing by name with tools:
[PATCH 2/8] xsm/flask: allow policy booleans to be addressed by name
[PATCH 3/8] libflask: Add boolean manipulation functions
[PATCH 4/8] flask: add flask-{get,set}-bool tools
[PATCH 5/8] flask/policy: Add boolean example

Device model stub domain support:
[PATCH 6/8] libxl: Add device_model_stubdomain_seclabel
[PATCH 7/8] flask/policy: add device model types to example policy

Cleanup:
[PATCH 8/8] xsm/flask: Improve domain ID auditing in AVCs

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsfYr-0006cd-MX; Wed, 01 Feb 2012 19:09:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsfYo-0006b6-L4
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:09:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328123372!3616600!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5925 invoked from network); 1 Feb 2012 19:09:32 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:09:32 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q11J9Vfo015483
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 19:09:31 GMT
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 q11J9S66004479; 
	Wed, 1 Feb 2012 14:09:31 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 14:09:24 -0500
Message-Id: <1328123365-12490-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 7/8] flask/policy: add device model types to
	example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds an example user for device_model_stubdomain_seclabel.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |    4 ++++
 tools/flask/policy/policy/modules/xen/xen.if |   11 ++++++++++-
 tools/flask/policy/policy/modules/xen/xen.te |   13 +++++++++++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 5b4297d..e2e415d 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -61,6 +61,10 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
 
+HVM domains with stubdomain device models use two types (one per domain):
+ - domHVM_t is an HVM domain that uses a stubdomain device model
+ - 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
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index dde7f90..87ef165 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -25,7 +25,7 @@ define(`create_domain', `
 	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 };
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
 	allow $1 $2_$1_channel:event create;
 ')
 
@@ -36,6 +36,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setvcpuaffinity setdomainmaxmem };
 ')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -75,6 +76,14 @@ define(`domain_self_comms', `
 	allow $1 $1: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 };
+')
 ################################################################################
 #
 # Device types and delegation (PCI passthrough)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index f7343a2..29885c4 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -100,6 +100,19 @@ if (!prot_doms_locked) {
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, 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)
+create_domain(dom0_t, domHVM_t)
+manage_domain(dom0_t, domHVM_t)
+domain_comms(dom0_t, domHVM_t)
+domain_self_comms(domHVM_t)
+
+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)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.7.6


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:31:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsftM-0008TA-Qx; Wed, 01 Feb 2012 19:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RsftL-0008Sz-Ch
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:30:51 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328124615!5994805!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8338 invoked from network); 1 Feb 2012 19:30:38 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 19:30:38 -0000
Received: by dadp13 with SMTP id p13so1482743dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 11:30:11 -0800 (PST)
Received: by 10.68.132.66 with SMTP id os2mr275118pbb.50.1328124611831;
	Wed, 01 Feb 2012 11:30:11 -0800 (PST)
Received: from [128.189.240.109] (host109-240.wifi.ubc.ca. [128.189.240.109])
	by mx.google.com with ESMTPS id j5sm362665pbe.1.2012.02.01.11.30.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 11:30:10 -0800 (PST)
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328112163.17444.86.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 11:30:07 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjAxMi0wMi0wMSwgYXQgODowMiBBTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0
cml4LmNvbT4gd3JvdGU6Cgo+IE9uIFdlZCwgMjAxMi0wMi0wMSBhdCAxNTo0OCArMDAwMCwgUGFz
aSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIFdlZCwgRmViIDAxLCAyMDEyIGF0IDEwOjUzOjU0
QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+IE9uIFR1ZSwgMjAxMi0wMS0zMSBhdCAx
Nzo1MiArMDAwMCwgU2hyaXJhbSBSYWphZ29wYWxhbiB3cm90ZToKPj4+PiBBcyBmb3IgZ3Vlc3Rz
IHN1cHBvcnRpbmcgdGhpcyBmYXN0IHN1c3BlbmQsIGFsbW9zdCBhbGwgZ3Vlc3RzIChwdi9odm0K
Pj4+PiBsaW51eC93aW5kb3dzKSBkbyBzdXBwb3J0IHN1c3BlbmRfY2FuY2VsLiBJSVJDLCBJIHRo
aW5rIHNvbWUgdmVyeSBvbGQKPj4+PiBrZXJuZWxzIGRpZG50IGhhdmUgdGhpcyBhYmlsaXR5Lgo+
Pj4gCj4+PiBTbGlnaHQgYXNpZGUsIGRvZXMgUmVtdXMgd29yayB3aXRoIG1haW5saW5lIExpbnV4
IGRvbVUga2VybmVscz8gVXNlcnMKPj4+IHNlZW0gdG8gYmUgdW5kZXIgdW5kZXIgdGhhdCBpbXBy
ZXNzaW9uLgo+Pj4gCj4+PiBJIGtub3cgeW91IGhhZCBzb21lIHBhdGNoZXMgYXQgb25lIHBvaW50
IGJ1dCBJIGEpIGRvbid0IHJlbWVtYmVyIGlmIHRoZXkKPj4+IHdlbnQgaW4gYW5kIGIpIGRvbid0
IHJlbWVtYmVyIGlmIHRoZXkgd2VyZSBzdWZmaWNpZW50Lgo+Pj4gCj4+IAo+PiBodHRwOi8vd2lr
aS54ZW4ub3JnL3dpa2kvUmVtdXMKPj4gIkxpbnV4IDIuNi4zOS4yIGFuZCBsYXRlciB1cHN0cmVh
bSBrZXJuZWwub3JnIHZlcnNpb25zIGFyZSBub3cgc3VwcG9ydGVkIGFzIFBWIGRvbVUga2VybmVs
cyIKPiAKPiBHcmVhdCwgc29tZW9uZSB3YXMgc3VnZ2VzdGluZyBvbiBsaXN0IHRoYXQgdGhpcyB3
YXNuJ3QgdGhlIGNhc2UuIE11c3QKPiBkaWcgb3V0IHRoYXQgbWFpbCBhbmQgcmVzcG9uZC4KPiAK
PiBJYW4uCj4gCj4gCgpJIGFkZGVkIHRoZSBjb21tZW50cyBvbiB0b3Agb2YgdGhlIHNlY29uZCB2
ZXJzaW9uIG9mIHRoZSBwYXRjaCBzZXJpZXMuClBsZWFzZSBsZXQgbWUga25vdyBpZiBpdCBsb29r
cyBva2F5LgoKSSB3aWxsIGJlIHNwaW5uaW5nIG91dCBhIFYzIGFueXdheSwgc2luY2UgU3RlZmFu
byBoYXMgcmVtb3ZlZCAgcW1wX21pZ3JhdGUuCkJ1dCB0aGlzIHBhdGNoIHdvdWxkIHJlbWFpbiB0
aGUgc2FtZSwgaWYgaXQncyBjdXJyZW50IGZvcm0gaXMgb2theS4KClNocmlyYW0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNl
LmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:31:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsftM-0008TA-Qx; Wed, 01 Feb 2012 19:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RsftL-0008Sz-Ch
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:30:51 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328124615!5994805!1
X-Originating-IP: [209.85.210.48]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8338 invoked from network); 1 Feb 2012 19:30:38 -0000
Received: from mail-pz0-f48.google.com (HELO mail-pz0-f48.google.com)
	(209.85.210.48)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2012 19:30:38 -0000
Received: by dadp13 with SMTP id p13so1482743dad.7
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 11:30:11 -0800 (PST)
Received: by 10.68.132.66 with SMTP id os2mr275118pbb.50.1328124611831;
	Wed, 01 Feb 2012 11:30:11 -0800 (PST)
Received: from [128.189.240.109] (host109-240.wifi.ubc.ca. [128.189.240.109])
	by mx.google.com with ESMTPS id j5sm362665pbe.1.2012.02.01.11.30.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 11:30:10 -0800 (PST)
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328112163.17444.86.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 11:30:07 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjAxMi0wMi0wMSwgYXQgODowMiBBTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0
cml4LmNvbT4gd3JvdGU6Cgo+IE9uIFdlZCwgMjAxMi0wMi0wMSBhdCAxNTo0OCArMDAwMCwgUGFz
aSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIFdlZCwgRmViIDAxLCAyMDEyIGF0IDEwOjUzOjU0
QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+IE9uIFR1ZSwgMjAxMi0wMS0zMSBhdCAx
Nzo1MiArMDAwMCwgU2hyaXJhbSBSYWphZ29wYWxhbiB3cm90ZToKPj4+PiBBcyBmb3IgZ3Vlc3Rz
IHN1cHBvcnRpbmcgdGhpcyBmYXN0IHN1c3BlbmQsIGFsbW9zdCBhbGwgZ3Vlc3RzIChwdi9odm0K
Pj4+PiBsaW51eC93aW5kb3dzKSBkbyBzdXBwb3J0IHN1c3BlbmRfY2FuY2VsLiBJSVJDLCBJIHRo
aW5rIHNvbWUgdmVyeSBvbGQKPj4+PiBrZXJuZWxzIGRpZG50IGhhdmUgdGhpcyBhYmlsaXR5Lgo+
Pj4gCj4+PiBTbGlnaHQgYXNpZGUsIGRvZXMgUmVtdXMgd29yayB3aXRoIG1haW5saW5lIExpbnV4
IGRvbVUga2VybmVscz8gVXNlcnMKPj4+IHNlZW0gdG8gYmUgdW5kZXIgdW5kZXIgdGhhdCBpbXBy
ZXNzaW9uLgo+Pj4gCj4+PiBJIGtub3cgeW91IGhhZCBzb21lIHBhdGNoZXMgYXQgb25lIHBvaW50
IGJ1dCBJIGEpIGRvbid0IHJlbWVtYmVyIGlmIHRoZXkKPj4+IHdlbnQgaW4gYW5kIGIpIGRvbid0
IHJlbWVtYmVyIGlmIHRoZXkgd2VyZSBzdWZmaWNpZW50Lgo+Pj4gCj4+IAo+PiBodHRwOi8vd2lr
aS54ZW4ub3JnL3dpa2kvUmVtdXMKPj4gIkxpbnV4IDIuNi4zOS4yIGFuZCBsYXRlciB1cHN0cmVh
bSBrZXJuZWwub3JnIHZlcnNpb25zIGFyZSBub3cgc3VwcG9ydGVkIGFzIFBWIGRvbVUga2VybmVs
cyIKPiAKPiBHcmVhdCwgc29tZW9uZSB3YXMgc3VnZ2VzdGluZyBvbiBsaXN0IHRoYXQgdGhpcyB3
YXNuJ3QgdGhlIGNhc2UuIE11c3QKPiBkaWcgb3V0IHRoYXQgbWFpbCBhbmQgcmVzcG9uZC4KPiAK
PiBJYW4uCj4gCj4gCgpJIGFkZGVkIHRoZSBjb21tZW50cyBvbiB0b3Agb2YgdGhlIHNlY29uZCB2
ZXJzaW9uIG9mIHRoZSBwYXRjaCBzZXJpZXMuClBsZWFzZSBsZXQgbWUga25vdyBpZiBpdCBsb29r
cyBva2F5LgoKSSB3aWxsIGJlIHNwaW5uaW5nIG91dCBhIFYzIGFueXdheSwgc2luY2UgU3RlZmFu
byBoYXMgcmVtb3ZlZCAgcW1wX21pZ3JhdGUuCkJ1dCB0aGlzIHBhdGNoIHdvdWxkIHJlbWFpbiB0
aGUgc2FtZSwgaWYgaXQncyBjdXJyZW50IGZvcm0gaXMgb2theS4KClNocmlyYW0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNl
LmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8C-0000EI-N9; Wed, 01 Feb 2012 19:46:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8A-0000Dz-FZ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328125546!51190104!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4MjA1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30021 invoked from network); 1 Feb 2012 19:45:46 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-11.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:46 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 4216B604061;
	Wed,  1 Feb 2012 11:46:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=uIOmuNiwhzE0VCUiWsplK5s/JZFbqJCPVQ7Ll2z1rH5d
	N4CkvFUeiAl3wBh85IQt3y4LT7R3d4uANpM26tYj1RlodzWrd1K3QJLhOfktfcNc
	0Omfi5CyKSEkx1Qoq4XIdTqRmpHx9b8SFALkb+cFHw7HaZmfylD4MyD3GgRlQaM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=b6rKMVsuWf0MrDvXt3Z8h2DNitA=; b=sNff10zqF4s
	pe7oE7X5bsXvNpR2jnyHpL0RXHf2HJyJbVMECjb7QKAqj22KxdxpUGETJL0A/LXe
	hWNJNNiF2QETIWE/Xwws1iip/3343VksDyhcOTNedYhfQzbRaHrc9qQbhJacuTgX
	vXk0nYn0fsbbcGxwGFdeJoZEWR48GlJE=
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 9BFDB60407C; 
	Wed,  1 Feb 2012 11:46:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3de7e43b130a87d428e0f3852a1cd4bf71679966
Message-Id: <3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:55 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 9] x86/mm: Refactor possibly deadlocking
	get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c    |  35 +++++++--------
 xen/arch/x86/mm/mem_sharing.c |  28 +++++++------
 xen/include/asm-x86/p2m.h     |  91 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 122 insertions(+), 32 deletions(-)


When calling get_gfn multiple times on different gfn's in the same function, we
can easily deadlock if p2m lookups are locked. Thus, refactor these calls to
enforce simple deadlock-avoidance rules:
 - Lowest-numbered domain first
 - Lowest-numbered gfn first

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>

diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    unsigned long saddr, daddr, bytes, sgfn, dgfn;
+    unsigned long saddr, daddr, bytes;
     paddr_t sgpa, dgpa;
     uint32_t pfec = PFEC_page_present;
-    p2m_type_t p2mt;
+    p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
+    struct two_gfns *tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -693,26 +694,25 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    /* XXX In a fine-grained p2m locking scenario, we need to sort this
-     * get_gfn's, or else we might deadlock */
-    sgfn = sgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, sgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    tg = get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
+                      current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
+                      p2m_guest);
+    if ( !tg )
+        return X86EMUL_UNHANDLEABLE;
+
+    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
         rc = hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_gfn(current->domain, sgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
-    dgfn = dgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, dgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
     {
         rc = hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
@@ -730,8 +730,7 @@ static int hvmemul_rep_movs(
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -743,8 +742,7 @@ static int hvmemul_rep_movs(
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -757,8 +755,7 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_gfn(current->domain, sgfn);
-    put_gfn(current->domain, dgfn);
+    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -718,11 +718,13 @@ int mem_sharing_share_pages(struct domai
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    struct two_gfns *tg;
 
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn(sd, sgfn, &smfn_type);
-    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                      cd, cgfn, &cmfn_type, NULL, &cmfn,
+                      p2m_query);
+    if ( !tg )
+        return -ENOMEM;
 
     /* This tricky business is to avoid two callers deadlocking if 
      * grabbing pages in opposite client/source order */
@@ -819,8 +821,7 @@ int mem_sharing_share_pages(struct domai
     ret = 0;
     
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
@@ -834,11 +835,13 @@ int mem_sharing_add_to_physmap(struct do
     struct gfn_info *gfn_info;
     struct p2m_domain *p2m = p2m_get_hostp2m(cd);
     p2m_access_t a;
-    
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn_query(sd, sgfn, &smfn_type);
-    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+    struct two_gfns *tg;
+
+    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                      cd, cgfn, &cmfn_type, &a, &cmfn,
+                      p2m_query);
+    if ( !tg )
+        return -ENOMEM;
 
     /* Get the source shared page, check and lock */
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
@@ -886,8 +889,7 @@ int mem_sharing_add_to_physmap(struct do
 err_unlock:
     mem_sharing_page_unlock(spage);
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
diff -r 27031a8a4eff -r 3de7e43b130a xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -378,6 +378,97 @@ static inline unsigned long mfn_to_gfn(s
         return mfn_x(mfn);
 }
 
+/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
+struct two_gfns {
+    struct domain  *first_domain;
+    unsigned long   first_gfn;
+    struct domain  *second_domain;
+    unsigned long   second_gfn;
+};
+
+#define assign_pointers(dest, source)                                       \
+do {                                                                        \
+    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
+    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
+    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
+} while(0)
+
+/* Returns mfn, type and access for potential caller consumption, but any
+ * of those can be NULL */
+static inline struct two_gfns *get_two_gfns(struct domain *rd, unsigned long rgfn,
+        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain *ld, 
+        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
+        p2m_query_t q)
+{
+    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
+    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
+    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
+    
+    struct two_gfns *rval = xmalloc(struct two_gfns);
+    if ( !rval )
+        return NULL;
+
+    if ( rd == ld )
+    {
+        rval->first_domain = rval->second_domain = rd;
+
+        /* Sort by gfn */
+        if (rgfn <= lgfn)
+        {
+            rval->first_gfn     = rgfn;
+            rval->second_gfn    = lgfn;
+            assign_pointers(first, r);
+            assign_pointers(second, l);
+        } else {
+            rval->first_gfn     = lgfn;
+            rval->second_gfn    = rgfn;
+            assign_pointers(first, l);
+            assign_pointers(second, r);
+        }        
+    } else {
+        /* Sort by domain */
+        if ( rd->domain_id <= ld->domain_id )
+        {
+            rval->first_domain  = rd;
+            rval->first_gfn     = rgfn;
+            rval->second_domain = ld;
+            rval->second_gfn    = lgfn;
+            assign_pointers(first, r);
+            assign_pointers(second, l);
+        } else {
+            rval->first_domain  = ld;
+            rval->first_gfn     = lgfn;
+            rval->second_domain = rd;
+            rval->second_gfn    = rgfn;
+            assign_pointers(first, l);
+            assign_pointers(second, r);
+        }
+    }
+
+    /* Now do the gets */
+    *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
+                                      rval->first_gfn, first_t, first_a, q, NULL);
+    *second_mfn = get_gfn_type_access(p2m_get_hostp2m(rval->second_domain), 
+                                      rval->second_gfn, second_t, second_a, q, NULL);
+
+    return rval;
+}
+
+static inline void put_two_gfns(struct two_gfns **arg_ptr)
+{
+    struct two_gfns *arg;
+
+    if ( !arg_ptr || !(*arg_ptr) )
+        return;
+
+    arg = *arg_ptr;
+    put_gfn(arg->second_domain, arg->second_gfn);
+    put_gfn(arg->first_domain, arg->first_gfn);
+
+    xfree(arg);
+    *arg_ptr = NULL;
+}
+
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8C-0000EI-N9; Wed, 01 Feb 2012 19:46:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8A-0000Dz-FZ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328125546!51190104!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4MjA1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30021 invoked from network); 1 Feb 2012 19:45:46 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-11.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:46 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 4216B604061;
	Wed,  1 Feb 2012 11:46:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=uIOmuNiwhzE0VCUiWsplK5s/JZFbqJCPVQ7Ll2z1rH5d
	N4CkvFUeiAl3wBh85IQt3y4LT7R3d4uANpM26tYj1RlodzWrd1K3QJLhOfktfcNc
	0Omfi5CyKSEkx1Qoq4XIdTqRmpHx9b8SFALkb+cFHw7HaZmfylD4MyD3GgRlQaM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=b6rKMVsuWf0MrDvXt3Z8h2DNitA=; b=sNff10zqF4s
	pe7oE7X5bsXvNpR2jnyHpL0RXHf2HJyJbVMECjb7QKAqj22KxdxpUGETJL0A/LXe
	hWNJNNiF2QETIWE/Xwws1iip/3343VksDyhcOTNedYhfQzbRaHrc9qQbhJacuTgX
	vXk0nYn0fsbbcGxwGFdeJoZEWR48GlJE=
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 9BFDB60407C; 
	Wed,  1 Feb 2012 11:46:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3de7e43b130a87d428e0f3852a1cd4bf71679966
Message-Id: <3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:55 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 9] x86/mm: Refactor possibly deadlocking
	get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c    |  35 +++++++--------
 xen/arch/x86/mm/mem_sharing.c |  28 +++++++------
 xen/include/asm-x86/p2m.h     |  91 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 122 insertions(+), 32 deletions(-)


When calling get_gfn multiple times on different gfn's in the same function, we
can easily deadlock if p2m lookups are locked. Thus, refactor these calls to
enforce simple deadlock-avoidance rules:
 - Lowest-numbered domain first
 - Lowest-numbered gfn first

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>

diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    unsigned long saddr, daddr, bytes, sgfn, dgfn;
+    unsigned long saddr, daddr, bytes;
     paddr_t sgpa, dgpa;
     uint32_t pfec = PFEC_page_present;
-    p2m_type_t p2mt;
+    p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
+    struct two_gfns *tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -693,26 +694,25 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    /* XXX In a fine-grained p2m locking scenario, we need to sort this
-     * get_gfn's, or else we might deadlock */
-    sgfn = sgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, sgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    tg = get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
+                      current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
+                      p2m_guest);
+    if ( !tg )
+        return X86EMUL_UNHANDLEABLE;
+
+    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
         rc = hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_gfn(current->domain, sgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
-    dgfn = dgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, dgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
     {
         rc = hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
@@ -730,8 +730,7 @@ static int hvmemul_rep_movs(
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -743,8 +742,7 @@ static int hvmemul_rep_movs(
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -757,8 +755,7 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_gfn(current->domain, sgfn);
-    put_gfn(current->domain, dgfn);
+    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -718,11 +718,13 @@ int mem_sharing_share_pages(struct domai
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    struct two_gfns *tg;
 
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn(sd, sgfn, &smfn_type);
-    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                      cd, cgfn, &cmfn_type, NULL, &cmfn,
+                      p2m_query);
+    if ( !tg )
+        return -ENOMEM;
 
     /* This tricky business is to avoid two callers deadlocking if 
      * grabbing pages in opposite client/source order */
@@ -819,8 +821,7 @@ int mem_sharing_share_pages(struct domai
     ret = 0;
     
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
@@ -834,11 +835,13 @@ int mem_sharing_add_to_physmap(struct do
     struct gfn_info *gfn_info;
     struct p2m_domain *p2m = p2m_get_hostp2m(cd);
     p2m_access_t a;
-    
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn_query(sd, sgfn, &smfn_type);
-    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+    struct two_gfns *tg;
+
+    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                      cd, cgfn, &cmfn_type, &a, &cmfn,
+                      p2m_query);
+    if ( !tg )
+        return -ENOMEM;
 
     /* Get the source shared page, check and lock */
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
@@ -886,8 +889,7 @@ int mem_sharing_add_to_physmap(struct do
 err_unlock:
     mem_sharing_page_unlock(spage);
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
diff -r 27031a8a4eff -r 3de7e43b130a xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -378,6 +378,97 @@ static inline unsigned long mfn_to_gfn(s
         return mfn_x(mfn);
 }
 
+/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
+struct two_gfns {
+    struct domain  *first_domain;
+    unsigned long   first_gfn;
+    struct domain  *second_domain;
+    unsigned long   second_gfn;
+};
+
+#define assign_pointers(dest, source)                                       \
+do {                                                                        \
+    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
+    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
+    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
+} while(0)
+
+/* Returns mfn, type and access for potential caller consumption, but any
+ * of those can be NULL */
+static inline struct two_gfns *get_two_gfns(struct domain *rd, unsigned long rgfn,
+        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain *ld, 
+        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
+        p2m_query_t q)
+{
+    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
+    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
+    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
+    
+    struct two_gfns *rval = xmalloc(struct two_gfns);
+    if ( !rval )
+        return NULL;
+
+    if ( rd == ld )
+    {
+        rval->first_domain = rval->second_domain = rd;
+
+        /* Sort by gfn */
+        if (rgfn <= lgfn)
+        {
+            rval->first_gfn     = rgfn;
+            rval->second_gfn    = lgfn;
+            assign_pointers(first, r);
+            assign_pointers(second, l);
+        } else {
+            rval->first_gfn     = lgfn;
+            rval->second_gfn    = rgfn;
+            assign_pointers(first, l);
+            assign_pointers(second, r);
+        }        
+    } else {
+        /* Sort by domain */
+        if ( rd->domain_id <= ld->domain_id )
+        {
+            rval->first_domain  = rd;
+            rval->first_gfn     = rgfn;
+            rval->second_domain = ld;
+            rval->second_gfn    = lgfn;
+            assign_pointers(first, r);
+            assign_pointers(second, l);
+        } else {
+            rval->first_domain  = ld;
+            rval->first_gfn     = lgfn;
+            rval->second_domain = rd;
+            rval->second_gfn    = rgfn;
+            assign_pointers(first, l);
+            assign_pointers(second, r);
+        }
+    }
+
+    /* Now do the gets */
+    *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
+                                      rval->first_gfn, first_t, first_a, q, NULL);
+    *second_mfn = get_gfn_type_access(p2m_get_hostp2m(rval->second_domain), 
+                                      rval->second_gfn, second_t, second_a, q, NULL);
+
+    return rval;
+}
+
+static inline void put_two_gfns(struct two_gfns **arg_ptr)
+{
+    struct two_gfns *arg;
+
+    if ( !arg_ptr || !(*arg_ptr) )
+        return;
+
+    arg = *arg_ptr;
+    put_gfn(arg->second_domain, arg->second_gfn);
+    put_gfn(arg->first_domain, arg->first_gfn);
+
+    xfree(arg);
+    *arg_ptr = NULL;
+}
+
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8G-0000Fc-HM; Wed, 01 Feb 2012 19:46:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8F-0000E1-LV
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328125567!5041211!2
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 1 Feb 2012 19:46:09 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:46:09 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 07ADF604084;
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=sTTRDjFqevlZOJFHHPhEK0NX1awMmLIuJPc+fai4x6LF
	Z6BUJCWDxZSbuv4s7T9lxWkRRNnHZfyY2aF7ZPlytZKpVYl1KwWLAtoSL0jSOPQ1
	GT0nt0NnwXvDi7nQFK3cNMUhrOXKQAvyXsO9cwBLSUYLlnKmdqv8HvNdU8gPqAM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MK4pihpBW8wdYwsAFJ9WcWM0PqA=; b=dYO66t1EwB9
	Bvqpe/WjzgobZppO7NbRhQkw7Rj2Z5fiL0OPbAH2ox6Bd6B1i1/6sf34gBPvbCK7
	YjCUmg2Z9Jxo+oHGhNnxo7Oh76BqwFy+7GxwolFpxGMFralq1qNMASnQqSFrtej8
	TQ/gZwXVQEml16hDeDMXkIwz40Vltumc=
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 70EE460407C; 
	Wed,  1 Feb 2012 11:46:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8a920bcddd0f093456def366ea997f8a0b89f9af
Message-Id: <8a920bcddd0f093456de.1328125916@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:56 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 9] Reorder locks used by shadow code in
 anticipation of synchronized p2m lookups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c |   3 +++
 xen/arch/x86/mm/shadow/multi.c  |  18 +++++++++---------
 2 files changed, 12 insertions(+), 9 deletions(-)


Currently, mm-locks.h enforces a strict ordering between locks in the mm
layer lest there be an inversion in the order locks are taken and thus
the risk of deadlock.

Once p2m lookups becoming synchronized, get_gfn* calls take the p2m lock, and a
new set of inversion arises.  Reorder some of the locks in the shadow code so
that even in this case no deadlocks happen.

After this, synchronized p2m lookups are in principle ready to be enabled in
shadow mode.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3de7e43b130a -r 8a920bcddd0f xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3609,6 +3609,8 @@ int shadow_track_dirty_vram(struct domai
             || end_pfn >= p2m->max_mapped_pfn)
         return -EINVAL;
 
+    /* We perform p2m lookups, so lock the p2m upfront to avoid deadlock */
+    p2m_lock(p2m_get_hostp2m(d));
     paging_lock(d);
 
     if ( dirty_vram && (!nr ||
@@ -3782,6 +3784,7 @@ out_dirty_vram:
 
 out:
     paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
     return rc;
 }
 
diff -r 3de7e43b130a -r 8a920bcddd0f xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2444,7 +2444,7 @@ static int validate_gl1e(struct vcpu *v,
     perfc_incr(shadow_validate_gl1e_calls);
 
     gfn = guest_l1e_get_gfn(new_gl1e);
-    gmfn = get_gfn_query(v->domain, gfn, &p2mt);
+    gmfn = get_gfn_query_unlocked(v->domain, gfn_x(gfn), &p2mt);
 
     l1e_propagate_from_guest(v, new_gl1e, gmfn, &new_sl1e, ft_prefetch, p2mt);
     result |= shadow_set_l1e(v, sl1p, new_sl1e, p2mt, sl1mfn);
@@ -2466,7 +2466,6 @@ static int validate_gl1e(struct vcpu *v,
     }
 #endif /* OOS */
 
-    put_gfn(v->domain, gfn_x(gfn));
     return result;
 }
 
@@ -4715,8 +4714,6 @@ static void sh_pagetable_dying(struct vc
     unsigned long l3gfn;
     mfn_t l3mfn;
 
-    paging_lock(v->domain);
-
     gcr3 = (v->arch.hvm_vcpu.guest_cr[3]);
     /* fast path: the pagetable belongs to the current context */
     if ( gcr3 == gpa )
@@ -4728,8 +4725,11 @@ static void sh_pagetable_dying(struct vc
     {
         printk(XENLOG_DEBUG "sh_pagetable_dying: gpa not valid %"PRIpaddr"\n",
                gpa);
-        goto out;
+        goto out_put_gfn;
     }
+
+    paging_lock(v->domain);
+
     if ( !fast_path )
     {
         gl3pa = sh_map_domain_page(l3mfn);
@@ -4770,11 +4770,11 @@ static void sh_pagetable_dying(struct vc
 
     v->arch.paging.shadow.pagetable_dying = 1;
 
-out:
     if ( !fast_path )
         unmap_domain_page(gl3pa);
+    paging_unlock(v->domain);
+out_put_gfn:
     put_gfn(v->domain, l3gfn);
-    paging_unlock(v->domain);
 }
 #else
 static void sh_pagetable_dying(struct vcpu *v, paddr_t gpa)
@@ -4782,15 +4782,14 @@ static void sh_pagetable_dying(struct vc
     mfn_t smfn, gmfn;
     p2m_type_t p2mt;
 
+    gmfn = get_gfn_query(v->domain, _gfn(gpa >> PAGE_SHIFT), &p2mt);
     paging_lock(v->domain);
 
-    gmfn = get_gfn_query(v->domain, _gfn(gpa >> PAGE_SHIFT), &p2mt);
 #if GUEST_PAGING_LEVELS == 2
     smfn = shadow_hash_lookup(v, mfn_x(gmfn), SH_type_l2_32_shadow);
 #else
     smfn = shadow_hash_lookup(v, mfn_x(gmfn), SH_type_l4_64_shadow);
 #endif
-    put_gfn(v->domain, gpa >> PAGE_SHIFT);
     
     if ( mfn_valid(smfn) )
     {
@@ -4808,6 +4807,7 @@ static void sh_pagetable_dying(struct vc
     v->arch.paging.shadow.pagetable_dying = 1;
 
     paging_unlock(v->domain);
+    put_gfn(v->domain, gpa >> PAGE_SHIFT);
 }
 #endif
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8A-0000E0-Ax; Wed, 01 Feb 2012 19:46:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg88-0000Dt-NX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328125518!52511310!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjAzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7077 invoked from network); 1 Feb 2012 19:45:19 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:19 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 9C5CE60408C;
	Wed,  1 Feb 2012 11:46:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tePgFksxZvRZxjJtbUnM7T0n99ZhYH+6Mjxa/a/cu/za
	lOL2Ruk+trnDo6+C4uuTPy241ArpGcE4wxC4/eruKC9Nctw7sL+VNhEfRNm0g5Cn
	6Jmb4bdwrr4Pvc5gONSV3MmSaTu4VPh6SUPUPRqP5aBF2feDggz7JeaAQbabQtg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EuJtDsfTOmKn6a8254zY071BbrM=; b=BAfZLt54m84
	xMPGA/s6iKeBtw0iAiMcBw2Qzw9gZ1U1iqnu22MupYkJ+WE+QZqkTbmROGpf6Sbe
	48plw4idW0cuK95ggmgG03tSoB03v+UeJK61nQFlmZJ1970WMxnZU0vKLT9AHgC1
	VF91EyMBWc6O+I+B5oTYjGJf9JJkBgiw=
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 E504260407C; 
	Wed,  1 Feb 2012 11:46:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: decd21170c2a9883c6a91b953cebcba1747b54d4
Message-Id: <decd21170c2a9883c6a9.1328125913@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:53 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 9] x86/mm: Remove p2m_ram_paging_in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c         |  8 ++++----
 xen/arch/x86/mm/p2m-ept.c |  3 +--
 xen/arch/x86/mm/p2m.c     |  7 +++----
 xen/include/asm-x86/p2m.h |  7 ++-----
 4 files changed, 10 insertions(+), 15 deletions(-)


This state in the paging state machine became unnecessary after the last
few updates.

Once eliminated, rename p2m_ram_paging_in_start to p2m_ram_paging_in.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r aa58893caa60 -r decd21170c2a xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3573,7 +3573,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
+                    else if ( p2m_ram_paging_in == l1e_p2mt && 
                                 !mfn_valid(l1emfn) )
                     {
                         put_gfn(pg_owner, l1egfn);
@@ -3622,7 +3622,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && 
+                    else if ( p2m_ram_paging_in == l2e_p2mt && 
                                 !mfn_valid(l2emfn) )
                     {
                         put_gfn(pg_owner, l2egfn);
@@ -3657,7 +3657,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && 
+                    else if ( p2m_ram_paging_in == l3e_p2mt && 
                                 !mfn_valid(l3emfn) )
                     {
                         put_gfn(pg_owner, l3egfn);
@@ -3692,7 +3692,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && 
+                    else if ( p2m_ram_paging_in == l4e_p2mt && 
                                 !mfn_valid(l4emfn) )
                     {
                         put_gfn(pg_owner, l4egfn);
diff -r aa58893caa60 -r decd21170c2a xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -82,7 +82,6 @@ static void ept_p2m_type_to_flags(ept_en
         case p2m_ram_paging_out:
         case p2m_ram_paged:
         case p2m_ram_paging_in:
-        case p2m_ram_paging_in_start:
         default:
             entry->r = entry->w = entry->x = 0;
             break;
@@ -381,7 +380,7 @@ ept_set_entry(struct p2m_domain *p2m, un
         old_entry = *ept_entry;
 
         if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
-             (p2mt == p2m_ram_paging_in_start) )
+             (p2mt == p2m_ram_paging_in) )
         {
             /* Construct the new entry, and then write it once */
             new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
diff -r aa58893caa60 -r decd21170c2a xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -935,7 +935,7 @@ void p2m_mem_paging_populate(struct doma
         if ( p2mt == p2m_ram_paging_out )
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
 
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
     p2m_unlock(p2m);
 
@@ -994,7 +994,7 @@ int p2m_mem_paging_prep(struct domain *d
 
     ret = -ENOENT;
     /* Allow missing pages */
-    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
+    if ( (p2mt != p2m_ram_paging_in) && (p2mt != p2m_ram_paged) )
         goto out;
 
     /* Allocate a page if the gfn does not have one yet */
@@ -1086,8 +1086,7 @@ void p2m_mem_paging_resume(struct domain
             mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
-            if ( mfn_valid(mfn) && 
-                 (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+            if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
             {
                 set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
                                 paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
diff -r aa58893caa60 -r decd21170c2a xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -82,9 +82,8 @@ typedef enum {
     p2m_ram_paging_out = 9,       /* Memory that is being paged out */
     p2m_ram_paged = 10,           /* Memory that has been paged out */
     p2m_ram_paging_in = 11,       /* Memory that is being paged in */
-    p2m_ram_paging_in_start = 12, /* Memory that is being paged in */
-    p2m_ram_shared = 13,          /* Shared or sharable memory */
-    p2m_ram_broken = 14,          /* Broken page, access cause domain crash */
+    p2m_ram_shared = 12,          /* Shared or sharable memory */
+    p2m_ram_broken = 13,          /* Broken page, access cause domain crash */
 } p2m_type_t;
 
 /*
@@ -131,7 +130,6 @@ typedef enum {
                        | p2m_to_mask(p2m_ram_ro)              \
                        | p2m_to_mask(p2m_ram_paging_out)      \
                        | p2m_to_mask(p2m_ram_paged)           \
-                       | p2m_to_mask(p2m_ram_paging_in_start) \
                        | p2m_to_mask(p2m_ram_paging_in)       \
                        | p2m_to_mask(p2m_ram_shared))
 
@@ -158,7 +156,6 @@ typedef enum {
 
 #define P2M_PAGING_TYPES (p2m_to_mask(p2m_ram_paging_out)        \
                           | p2m_to_mask(p2m_ram_paged)           \
-                          | p2m_to_mask(p2m_ram_paging_in_start) \
                           | p2m_to_mask(p2m_ram_paging_in))
 
 #define P2M_PAGED_TYPES (p2m_to_mask(p2m_ram_paged))

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8F-0000F6-Mf; Wed, 01 Feb 2012 19:46:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8E-0000EX-9r
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328125528!62664949!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15236 invoked from network); 1 Feb 2012 19:45:29 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:29 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 6CD6F604084;
	Wed,  1 Feb 2012 11:46:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=D2gb+DrvQ97j+qxCxz2op4BITXXjRJerDE/htIcpS07/
	HeazcSJKpThk1KlWWOnIYP8UfMIDIffRNdo7ONyWKV2f6869CBrcDk8LwygO9hch
	kKpQTV1EYHyOUnI0yqZ4Zm23c2ZwL53sSs9Kyy/2RT83qbtl8ZKiOL4jLkjE0zY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=sMHBaKOffBT8jkRB10a3rbYe4NQ=; b=omBhQFndwbF
	XZCQeqdxNq/qyIJjwxJ3TH3VkO/YaVGi6rj+ZCJcXNEsEV58CYt3noKMPcrFcaRr
	T/Vsf/cWtsIb+a86Wip3yciJpvB5CNVhtmNk/mkl2PnewwEAcr7QrWswNls2fn98
	MeXeQh9lHeFmkQgrKKtyN4fQYIxrJCXA=
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 C4E9A60407C; 
	Wed,  1 Feb 2012 11:46:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 12f7da67cefe5b40202e066bcab88ed731292c18
Message-Id: <12f7da67cefe5b40202e.1328125920@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:52:00 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 9] x86/mm: Make sharing ASSERT check more
	accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 244804e8a002 -r 12f7da67cefe xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -197,7 +197,12 @@ static struct page_info* mem_sharing_loo
         struct page_info* page = mfn_to_page(_mfn(mfn));
         if ( page_get_owner(page) == dom_cow )
         {
-            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            /* Count has to be at least two, because we're called
+             * with the mfn locked (1) and this is supposed to be 
+             * a shared page (1). */
+            ASSERT( (page->u.inuse.type_info & 
+                     (PGT_shared_page | PGT_count_mask)) >=
+                    (PGT_shared_page | 2) ); 
             ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
             return page;
         }

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8F-0000F6-Mf; Wed, 01 Feb 2012 19:46:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8E-0000EX-9r
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328125528!62664949!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15236 invoked from network); 1 Feb 2012 19:45:29 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:29 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 6CD6F604084;
	Wed,  1 Feb 2012 11:46:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=D2gb+DrvQ97j+qxCxz2op4BITXXjRJerDE/htIcpS07/
	HeazcSJKpThk1KlWWOnIYP8UfMIDIffRNdo7ONyWKV2f6869CBrcDk8LwygO9hch
	kKpQTV1EYHyOUnI0yqZ4Zm23c2ZwL53sSs9Kyy/2RT83qbtl8ZKiOL4jLkjE0zY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=sMHBaKOffBT8jkRB10a3rbYe4NQ=; b=omBhQFndwbF
	XZCQeqdxNq/qyIJjwxJ3TH3VkO/YaVGi6rj+ZCJcXNEsEV58CYt3noKMPcrFcaRr
	T/Vsf/cWtsIb+a86Wip3yciJpvB5CNVhtmNk/mkl2PnewwEAcr7QrWswNls2fn98
	MeXeQh9lHeFmkQgrKKtyN4fQYIxrJCXA=
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 C4E9A60407C; 
	Wed,  1 Feb 2012 11:46:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 12f7da67cefe5b40202e066bcab88ed731292c18
Message-Id: <12f7da67cefe5b40202e.1328125920@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:52:00 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 9] x86/mm: Make sharing ASSERT check more
	accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 244804e8a002 -r 12f7da67cefe xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -197,7 +197,12 @@ static struct page_info* mem_sharing_loo
         struct page_info* page = mfn_to_page(_mfn(mfn));
         if ( page_get_owner(page) == dom_cow )
         {
-            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            /* Count has to be at least two, because we're called
+             * with the mfn locked (1) and this is supposed to be 
+             * a shared page (1). */
+            ASSERT( (page->u.inuse.type_info & 
+                     (PGT_shared_page | PGT_count_mask)) >=
+                    (PGT_shared_page | 2) ); 
             ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
             return page;
         }

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8K-0000Hh-5D; Wed, 01 Feb 2012 19:46:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8J-0000EW-15
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328125572!13319937!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16157 invoked from network); 1 Feb 2012 19:46:12 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 19:46:12 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8BEF1604061;
	Wed,  1 Feb 2012 11:46:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=o12klLfPtzvqt1HBMSOFnrtGKOrilyEmAPfOmhL6lwMf
	6O1HhT1NsLcuf2yuAWSvqVfwGGN71IYLVKPJpyRFme8pp6KFjZeJ9ZtVdotOIKTd
	QIY9Y+J4h8bgsNAMXiXIShpQUbXrorVupyuE+UNzuNqAgykUnWKwnDAT8gBeToU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=axGWMQEtWDyU50dpL3aF7ZQnJNQ=; b=n8w77Gi3X6q
	UQtMx0DfdCiV1x29XRasgSuR0wYSCe1NdXEMaucj5tNWXxWC5gZxUvLz9cDC6URz
	HTxnXD1bM4OLdpsG5KWcRTlrSfvroarHJSBJTJqd/Qpnm28mZb+Wi7ZvsYe1lliQ
	XwljT20VBSZqhlArtpXGDR8aG70X8euU=
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 C009860407C; 
	Wed,  1 Feb 2012 11:46:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 244804e8a0022cbbc848b66a80c56b3d969b4423
Message-Id: <244804e8a0022cbbc848.1328125919@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:59 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 9] x86/mm: Fix paging stats
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |   6 +++++-
 xen/arch/x86/mm/p2m.c         |  12 +++++++++++-
 xen/common/memory.c           |   2 +-
 xen/include/asm-x86/p2m.h     |   6 ++++--
 4 files changed, 21 insertions(+), 5 deletions(-)


There are several corner cases in which a page is paged back in, not by paging,
and the stats are not properly updated.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 75dec1a0ba2d -r 244804e8a002 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -881,8 +881,12 @@ int mem_sharing_add_to_physmap(struct do
         ret = -ENOENT;
         mem_sharing_gfn_destroy(cd, gfn_info);
         put_page_and_type(spage);
-    } else
+    } else {
         ret = 0;
+        /* There is a chance we're plugging a hole where a paged out page was */
+        if ( p2m_is_paging(cmfn_type) && (cmfn_type != p2m_ram_paging_out) )
+            atomic_dec(&cd->paged_pages);
+    }
 
     atomic_inc(&nr_saved_mfns);
 
diff -r 75dec1a0ba2d -r 244804e8a002 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -510,6 +510,11 @@ guest_physmap_add_entry(struct domain *d
             /* Count how man PoD entries we'll be replacing if successful */
             pod_count++;
         }
+        else if ( p2m_is_paging(ot) && (ot != p2m_ram_paging_out) )
+        {
+            /* We're plugging a hole in the physmap where a paged out page was */
+            atomic_dec(&d->paged_pages);
+        }
     }
 
     /* Then, look for m->p mappings for this range and deal with them */
@@ -878,7 +883,8 @@ int p2m_mem_paging_evict(struct domain *
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
+                                p2m_type_t p2mt)
 {
     mem_event_request_t req;
 
@@ -897,6 +903,10 @@ void p2m_mem_paging_drop_page(struct dom
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
+
+    /* Update stats unless the page hasn't yet been evicted */
+    if ( p2mt != p2m_ram_paging_out )
+        atomic_dec(&d->paged_pages);
 }
 
 /**
diff -r 75dec1a0ba2d -r 244804e8a002 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -166,7 +166,7 @@ int guest_remove_page(struct domain *d, 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
-        p2m_mem_paging_drop_page(d, gmfn);
+        p2m_mem_paging_drop_page(d, gmfn, p2mt);
         put_gfn(d, gmfn);
         return 1;
     }
diff -r 75dec1a0ba2d -r 244804e8a002 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -566,7 +566,8 @@ int p2m_mem_paging_nominate(struct domai
 /* Evict a frame */
 int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
+void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, 
+                                p2m_type_t p2mt);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
@@ -574,7 +575,8 @@ int p2m_mem_paging_prep(struct domain *d
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
+                                            p2m_type_t p2mt)
 { }
 static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 { }

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8K-0000Hh-5D; Wed, 01 Feb 2012 19:46:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8J-0000EW-15
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328125572!13319937!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16157 invoked from network); 1 Feb 2012 19:46:12 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 19:46:12 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8BEF1604061;
	Wed,  1 Feb 2012 11:46:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=o12klLfPtzvqt1HBMSOFnrtGKOrilyEmAPfOmhL6lwMf
	6O1HhT1NsLcuf2yuAWSvqVfwGGN71IYLVKPJpyRFme8pp6KFjZeJ9ZtVdotOIKTd
	QIY9Y+J4h8bgsNAMXiXIShpQUbXrorVupyuE+UNzuNqAgykUnWKwnDAT8gBeToU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=axGWMQEtWDyU50dpL3aF7ZQnJNQ=; b=n8w77Gi3X6q
	UQtMx0DfdCiV1x29XRasgSuR0wYSCe1NdXEMaucj5tNWXxWC5gZxUvLz9cDC6URz
	HTxnXD1bM4OLdpsG5KWcRTlrSfvroarHJSBJTJqd/Qpnm28mZb+Wi7ZvsYe1lliQ
	XwljT20VBSZqhlArtpXGDR8aG70X8euU=
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 C009860407C; 
	Wed,  1 Feb 2012 11:46:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 244804e8a0022cbbc848b66a80c56b3d969b4423
Message-Id: <244804e8a0022cbbc848.1328125919@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:59 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 9] x86/mm: Fix paging stats
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |   6 +++++-
 xen/arch/x86/mm/p2m.c         |  12 +++++++++++-
 xen/common/memory.c           |   2 +-
 xen/include/asm-x86/p2m.h     |   6 ++++--
 4 files changed, 21 insertions(+), 5 deletions(-)


There are several corner cases in which a page is paged back in, not by paging,
and the stats are not properly updated.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 75dec1a0ba2d -r 244804e8a002 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -881,8 +881,12 @@ int mem_sharing_add_to_physmap(struct do
         ret = -ENOENT;
         mem_sharing_gfn_destroy(cd, gfn_info);
         put_page_and_type(spage);
-    } else
+    } else {
         ret = 0;
+        /* There is a chance we're plugging a hole where a paged out page was */
+        if ( p2m_is_paging(cmfn_type) && (cmfn_type != p2m_ram_paging_out) )
+            atomic_dec(&cd->paged_pages);
+    }
 
     atomic_inc(&nr_saved_mfns);
 
diff -r 75dec1a0ba2d -r 244804e8a002 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -510,6 +510,11 @@ guest_physmap_add_entry(struct domain *d
             /* Count how man PoD entries we'll be replacing if successful */
             pod_count++;
         }
+        else if ( p2m_is_paging(ot) && (ot != p2m_ram_paging_out) )
+        {
+            /* We're plugging a hole in the physmap where a paged out page was */
+            atomic_dec(&d->paged_pages);
+        }
     }
 
     /* Then, look for m->p mappings for this range and deal with them */
@@ -878,7 +883,8 @@ int p2m_mem_paging_evict(struct domain *
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
+                                p2m_type_t p2mt)
 {
     mem_event_request_t req;
 
@@ -897,6 +903,10 @@ void p2m_mem_paging_drop_page(struct dom
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
+
+    /* Update stats unless the page hasn't yet been evicted */
+    if ( p2mt != p2m_ram_paging_out )
+        atomic_dec(&d->paged_pages);
 }
 
 /**
diff -r 75dec1a0ba2d -r 244804e8a002 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -166,7 +166,7 @@ int guest_remove_page(struct domain *d, 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
-        p2m_mem_paging_drop_page(d, gmfn);
+        p2m_mem_paging_drop_page(d, gmfn, p2mt);
         put_gfn(d, gmfn);
         return 1;
     }
diff -r 75dec1a0ba2d -r 244804e8a002 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -566,7 +566,8 @@ int p2m_mem_paging_nominate(struct domai
 /* Evict a frame */
 int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
+void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn, 
+                                p2m_type_t p2mt);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
@@ -574,7 +575,8 @@ int p2m_mem_paging_prep(struct domain *d
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
+                                            p2m_type_t p2mt)
 { }
 static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 { }

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8A-0000E0-Ax; Wed, 01 Feb 2012 19:46:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg88-0000Dt-NX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328125518!52511310!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjAzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7077 invoked from network); 1 Feb 2012 19:45:19 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:19 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 9C5CE60408C;
	Wed,  1 Feb 2012 11:46:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tePgFksxZvRZxjJtbUnM7T0n99ZhYH+6Mjxa/a/cu/za
	lOL2Ruk+trnDo6+C4uuTPy241ArpGcE4wxC4/eruKC9Nctw7sL+VNhEfRNm0g5Cn
	6Jmb4bdwrr4Pvc5gONSV3MmSaTu4VPh6SUPUPRqP5aBF2feDggz7JeaAQbabQtg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EuJtDsfTOmKn6a8254zY071BbrM=; b=BAfZLt54m84
	xMPGA/s6iKeBtw0iAiMcBw2Qzw9gZ1U1iqnu22MupYkJ+WE+QZqkTbmROGpf6Sbe
	48plw4idW0cuK95ggmgG03tSoB03v+UeJK61nQFlmZJ1970WMxnZU0vKLT9AHgC1
	VF91EyMBWc6O+I+B5oTYjGJf9JJkBgiw=
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 E504260407C; 
	Wed,  1 Feb 2012 11:46:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: decd21170c2a9883c6a91b953cebcba1747b54d4
Message-Id: <decd21170c2a9883c6a9.1328125913@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:53 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 9] x86/mm: Remove p2m_ram_paging_in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c         |  8 ++++----
 xen/arch/x86/mm/p2m-ept.c |  3 +--
 xen/arch/x86/mm/p2m.c     |  7 +++----
 xen/include/asm-x86/p2m.h |  7 ++-----
 4 files changed, 10 insertions(+), 15 deletions(-)


This state in the paging state machine became unnecessary after the last
few updates.

Once eliminated, rename p2m_ram_paging_in_start to p2m_ram_paging_in.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r aa58893caa60 -r decd21170c2a xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3573,7 +3573,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
+                    else if ( p2m_ram_paging_in == l1e_p2mt && 
                                 !mfn_valid(l1emfn) )
                     {
                         put_gfn(pg_owner, l1egfn);
@@ -3622,7 +3622,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l2e_p2mt && 
+                    else if ( p2m_ram_paging_in == l2e_p2mt && 
                                 !mfn_valid(l2emfn) )
                     {
                         put_gfn(pg_owner, l2egfn);
@@ -3657,7 +3657,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l3e_p2mt && 
+                    else if ( p2m_ram_paging_in == l3e_p2mt && 
                                 !mfn_valid(l3emfn) )
                     {
                         put_gfn(pg_owner, l3egfn);
@@ -3692,7 +3692,7 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l4e_p2mt && 
+                    else if ( p2m_ram_paging_in == l4e_p2mt && 
                                 !mfn_valid(l4emfn) )
                     {
                         put_gfn(pg_owner, l4egfn);
diff -r aa58893caa60 -r decd21170c2a xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -82,7 +82,6 @@ static void ept_p2m_type_to_flags(ept_en
         case p2m_ram_paging_out:
         case p2m_ram_paged:
         case p2m_ram_paging_in:
-        case p2m_ram_paging_in_start:
         default:
             entry->r = entry->w = entry->x = 0;
             break;
@@ -381,7 +380,7 @@ ept_set_entry(struct p2m_domain *p2m, un
         old_entry = *ept_entry;
 
         if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
-             (p2mt == p2m_ram_paging_in_start) )
+             (p2mt == p2m_ram_paging_in) )
         {
             /* Construct the new entry, and then write it once */
             new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
diff -r aa58893caa60 -r decd21170c2a xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -935,7 +935,7 @@ void p2m_mem_paging_populate(struct doma
         if ( p2mt == p2m_ram_paging_out )
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
 
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
+        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
     p2m_unlock(p2m);
 
@@ -994,7 +994,7 @@ int p2m_mem_paging_prep(struct domain *d
 
     ret = -ENOENT;
     /* Allow missing pages */
-    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
+    if ( (p2mt != p2m_ram_paging_in) && (p2mt != p2m_ram_paged) )
         goto out;
 
     /* Allocate a page if the gfn does not have one yet */
@@ -1086,8 +1086,7 @@ void p2m_mem_paging_resume(struct domain
             mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
-            if ( mfn_valid(mfn) && 
-                 (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+            if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
             {
                 set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
                                 paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
diff -r aa58893caa60 -r decd21170c2a xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -82,9 +82,8 @@ typedef enum {
     p2m_ram_paging_out = 9,       /* Memory that is being paged out */
     p2m_ram_paged = 10,           /* Memory that has been paged out */
     p2m_ram_paging_in = 11,       /* Memory that is being paged in */
-    p2m_ram_paging_in_start = 12, /* Memory that is being paged in */
-    p2m_ram_shared = 13,          /* Shared or sharable memory */
-    p2m_ram_broken = 14,          /* Broken page, access cause domain crash */
+    p2m_ram_shared = 12,          /* Shared or sharable memory */
+    p2m_ram_broken = 13,          /* Broken page, access cause domain crash */
 } p2m_type_t;
 
 /*
@@ -131,7 +130,6 @@ typedef enum {
                        | p2m_to_mask(p2m_ram_ro)              \
                        | p2m_to_mask(p2m_ram_paging_out)      \
                        | p2m_to_mask(p2m_ram_paged)           \
-                       | p2m_to_mask(p2m_ram_paging_in_start) \
                        | p2m_to_mask(p2m_ram_paging_in)       \
                        | p2m_to_mask(p2m_ram_shared))
 
@@ -158,7 +156,6 @@ typedef enum {
 
 #define P2M_PAGING_TYPES (p2m_to_mask(p2m_ram_paging_out)        \
                           | p2m_to_mask(p2m_ram_paged)           \
-                          | p2m_to_mask(p2m_ram_paging_in_start) \
                           | p2m_to_mask(p2m_ram_paging_in))
 
 #define P2M_PAGED_TYPES (p2m_to_mask(p2m_ram_paged))

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8J-0000HP-PE; Wed, 01 Feb 2012 19:46:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8I-0000Ew-AG
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328125529!62664952!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15260 invoked from network); 1 Feb 2012 19:45:29 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:29 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 435F3604061;
	Wed,  1 Feb 2012 11:46:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ppilk9lqHMrjey0RPgaRAROvbY2Y0ZoJeeh2JSSxkOrn
	4kbiIuU8VZlTNSQgQt7mn30EqpVZm9LUuVNZFxjkOEi+FiKVbrtZzcrx1eAyODBy
	b+XdAXZAruGg0+dcPXDAgbynOfhfgHE7+0pbmDn2RDEQIWAoidtRdu6sKlRHKH8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fS+zfjnX/h7wnf2oLm3kadHZ1f0=; b=UQH0gvyHwmw
	7CRqB1JXSbmYcyxVuL3rAqhobM5GRasWAjZOYwn2nZPazfINAjughNp2K4/kq3xx
	RAjl3g6DH6qY+4yU0NYJOKKyw/elWctlFo82ZVdceVcRIZKZjRktpuFQjI0IPO5B
	UuSjcOlglT4oPxvOFWO2GG8s3IEBgOMo=
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 9BB2460407C; 
	Wed,  1 Feb 2012 11:46:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9a55109e4d7eb1b467203aaab5239d1daf1bb664
Message-Id: <9a55109e4d7eb1b46720.1328125921@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:52:01 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 9 of 9] x86/mm: Make debug_{gfn, mfn,
 gref} calls to sharing more useful and correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  224 +++++++++++++++++++++--------------------
 1 files changed, 115 insertions(+), 109 deletions(-)


Have them used locked accesors to the gfn and the underlying shared mfn.

Have them return the number of shared refs to the underlying mfn.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 12f7da67cefe -r 9a55109e4d7e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -45,13 +45,13 @@ typedef struct pg_lock_data {
 
 DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
+#define MEM_SHARING_DEBUG(_f, _a...)                                  \
+    debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 #if MEM_SHARING_AUDIT
 
 static void mem_sharing_audit(void);
 
-#define MEM_SHARING_DEBUG(_f, _a...)                                  \
-    debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
-
 static struct list_head shr_audit_list;
 static spinlock_t shr_audit_lock;
 DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
@@ -400,111 +400,6 @@ int mem_sharing_sharing_resume(struct do
     return 0;
 }
 
-int mem_sharing_debug_mfn(unsigned long mfn)
-{
-    struct page_info *page;
-
-    if ( !mfn_valid(_mfn(mfn)) )
-    {
-        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn);
-        return -1;
-    }
-    page = mfn_to_page(_mfn(mfn));
-
-    gdprintk(XENLOG_DEBUG, 
-            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
-            mfn_x(page_to_mfn(page)), 
-            page->count_info, 
-            page->u.inuse.type_info,
-            page_get_owner(page)->domain_id);
-
-    return 0;
-}
-
-int mem_sharing_debug_gfn(struct domain *d, unsigned long gfn)
-{
-    p2m_type_t p2mt;
-    mfn_t mfn;
-
-    mfn = get_gfn_query_unlocked(d, gfn, &p2mt);
-
-    gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
-               d->domain_id, 
-               gfn);
-    return mem_sharing_debug_mfn(mfn_x(mfn));
-}
-
-#define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
-#define shared_entry_v1(t, e) \
-    ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
-#define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
-#define shared_entry_v2(t, e) \
-    ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
-#define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
-#define status_entry(t, e) \
-    ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
-
-static grant_entry_header_t *
-shared_entry_header(struct grant_table *t, grant_ref_t ref)
-{
-    ASSERT (t->gt_version != 0);
-    if ( t->gt_version == 1 )
-        return (grant_entry_header_t*)&shared_entry_v1(t, ref);
-    else
-        return &shared_entry_v2(t, ref).hdr;
-}
-
-static int mem_sharing_gref_to_gfn(struct domain *d, 
-                                   grant_ref_t ref, 
-                                   unsigned long *gfn)
-{
-    if ( d->grant_table->gt_version < 1 )
-        return -1;
-
-    if ( d->grant_table->gt_version == 1 ) 
-    {
-        grant_entry_v1_t *sha1;
-        sha1 = &shared_entry_v1(d->grant_table, ref);
-        *gfn = sha1->frame;
-    } 
-    else 
-    {
-        grant_entry_v2_t *sha2;
-        sha2 = &shared_entry_v2(d->grant_table, ref);
-        *gfn = sha2->full_page.frame;
-    }
- 
-    return 0;
-}
-
-
-int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
-{
-    grant_entry_header_t *shah;
-    uint16_t status;
-    unsigned long gfn;
-
-    if ( d->grant_table->gt_version < 1 )
-    {
-        gdprintk(XENLOG_ERR, 
-                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
-                d->domain_id, ref);
-        return -1;
-    }
-    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
-    shah = shared_entry_header(d->grant_table, ref);
-    if ( d->grant_table->gt_version == 1 ) 
-        status = shah->flags;
-    else 
-        status = status_entry(d->grant_table, ref);
-    
-    gdprintk(XENLOG_DEBUG,
-            "==> Grant [dom=%d,ref=%d], status=%x. ", 
-            d->domain_id, ref, status);
-
-    return mem_sharing_debug_gfn(d, gfn); 
-}
-
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d, 
                        struct page_info *page, 
@@ -606,6 +501,117 @@ static inline struct page_info *__grab_s
     return pg;
 }
 
+int mem_sharing_debug_mfn(mfn_t mfn)
+{
+    struct page_info *page;
+    int num_refs;
+
+    if ( (page = __grab_shared_page(mfn)) == NULL)
+    {
+        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn_x(mfn));
+        return -1;
+    }
+
+    MEM_SHARING_DEBUG( 
+            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
+            mfn_x(page_to_mfn(page)), 
+            page->count_info, 
+            page->u.inuse.type_info,
+            page_get_owner(page)->domain_id);
+
+    /* -1 because the page is locked and that's an additional type ref */
+    num_refs = ((int) (page->u.inuse.type_info & PGT_count_mask)) - 1;
+    mem_sharing_page_unlock(page);
+    return num_refs;
+}
+
+int mem_sharing_debug_gfn(struct domain *d, unsigned long gfn)
+{
+    p2m_type_t p2mt;
+    mfn_t mfn;
+    int num_refs;
+
+    mfn = get_gfn_query(d, gfn, &p2mt);
+
+    MEM_SHARING_DEBUG("Debug for domain=%d, gfn=%lx, ", 
+               d->domain_id, 
+               gfn);
+    num_refs = mem_sharing_debug_mfn(mfn);
+    put_gfn(d, gfn);
+    return num_refs;
+}
+
+#define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
+#define shared_entry_v1(t, e) \
+    ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
+#define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
+#define shared_entry_v2(t, e) \
+    ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
+#define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
+#define status_entry(t, e) \
+    ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
+
+static grant_entry_header_t *
+shared_entry_header(struct grant_table *t, grant_ref_t ref)
+{
+    ASSERT (t->gt_version != 0);
+    if ( t->gt_version == 1 )
+        return (grant_entry_header_t*)&shared_entry_v1(t, ref);
+    else
+        return &shared_entry_v2(t, ref).hdr;
+}
+
+static int mem_sharing_gref_to_gfn(struct domain *d, 
+                                   grant_ref_t ref, 
+                                   unsigned long *gfn)
+{
+    if ( d->grant_table->gt_version < 1 )
+        return -1;
+
+    if ( d->grant_table->gt_version == 1 ) 
+    {
+        grant_entry_v1_t *sha1;
+        sha1 = &shared_entry_v1(d->grant_table, ref);
+        *gfn = sha1->frame;
+    } 
+    else 
+    {
+        grant_entry_v2_t *sha2;
+        sha2 = &shared_entry_v2(d->grant_table, ref);
+        *gfn = sha2->full_page.frame;
+    }
+ 
+    return 0;
+}
+
+
+int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
+{
+    grant_entry_header_t *shah;
+    uint16_t status;
+    unsigned long gfn;
+
+    if ( d->grant_table->gt_version < 1 )
+    {
+        MEM_SHARING_DEBUG( 
+                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
+                d->domain_id, ref);
+        return -1;
+    }
+    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
+    shah = shared_entry_header(d->grant_table, ref);
+    if ( d->grant_table->gt_version == 1 ) 
+        status = shah->flags;
+    else 
+        status = status_entry(d->grant_table, ref);
+    
+    MEM_SHARING_DEBUG(
+            "==> Grant [dom=%d,ref=%d], status=%x. ", 
+            d->domain_id, ref, status);
+
+    return mem_sharing_debug_gfn(d, gfn); 
+}
+
 int mem_sharing_nominate_page(struct domain *d,
                               unsigned long gfn,
                               int expected_refcnt,
@@ -1169,7 +1175,7 @@ int mem_sharing_domctl(struct domain *d,
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
-            rc = mem_sharing_debug_mfn(mfn);
+            rc = mem_sharing_debug_mfn(_mfn(mfn));
         }
         break;
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8G-0000Fc-HM; Wed, 01 Feb 2012 19:46:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8F-0000E1-LV
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328125567!5041211!2
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 1 Feb 2012 19:46:09 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:46:09 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 07ADF604084;
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=sTTRDjFqevlZOJFHHPhEK0NX1awMmLIuJPc+fai4x6LF
	Z6BUJCWDxZSbuv4s7T9lxWkRRNnHZfyY2aF7ZPlytZKpVYl1KwWLAtoSL0jSOPQ1
	GT0nt0NnwXvDi7nQFK3cNMUhrOXKQAvyXsO9cwBLSUYLlnKmdqv8HvNdU8gPqAM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MK4pihpBW8wdYwsAFJ9WcWM0PqA=; b=dYO66t1EwB9
	Bvqpe/WjzgobZppO7NbRhQkw7Rj2Z5fiL0OPbAH2ox6Bd6B1i1/6sf34gBPvbCK7
	YjCUmg2Z9Jxo+oHGhNnxo7Oh76BqwFy+7GxwolFpxGMFralq1qNMASnQqSFrtej8
	TQ/gZwXVQEml16hDeDMXkIwz40Vltumc=
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 70EE460407C; 
	Wed,  1 Feb 2012 11:46:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8a920bcddd0f093456def366ea997f8a0b89f9af
Message-Id: <8a920bcddd0f093456de.1328125916@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:56 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 9] Reorder locks used by shadow code in
 anticipation of synchronized p2m lookups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c |   3 +++
 xen/arch/x86/mm/shadow/multi.c  |  18 +++++++++---------
 2 files changed, 12 insertions(+), 9 deletions(-)


Currently, mm-locks.h enforces a strict ordering between locks in the mm
layer lest there be an inversion in the order locks are taken and thus
the risk of deadlock.

Once p2m lookups becoming synchronized, get_gfn* calls take the p2m lock, and a
new set of inversion arises.  Reorder some of the locks in the shadow code so
that even in this case no deadlocks happen.

After this, synchronized p2m lookups are in principle ready to be enabled in
shadow mode.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3de7e43b130a -r 8a920bcddd0f xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3609,6 +3609,8 @@ int shadow_track_dirty_vram(struct domai
             || end_pfn >= p2m->max_mapped_pfn)
         return -EINVAL;
 
+    /* We perform p2m lookups, so lock the p2m upfront to avoid deadlock */
+    p2m_lock(p2m_get_hostp2m(d));
     paging_lock(d);
 
     if ( dirty_vram && (!nr ||
@@ -3782,6 +3784,7 @@ out_dirty_vram:
 
 out:
     paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
     return rc;
 }
 
diff -r 3de7e43b130a -r 8a920bcddd0f xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2444,7 +2444,7 @@ static int validate_gl1e(struct vcpu *v,
     perfc_incr(shadow_validate_gl1e_calls);
 
     gfn = guest_l1e_get_gfn(new_gl1e);
-    gmfn = get_gfn_query(v->domain, gfn, &p2mt);
+    gmfn = get_gfn_query_unlocked(v->domain, gfn_x(gfn), &p2mt);
 
     l1e_propagate_from_guest(v, new_gl1e, gmfn, &new_sl1e, ft_prefetch, p2mt);
     result |= shadow_set_l1e(v, sl1p, new_sl1e, p2mt, sl1mfn);
@@ -2466,7 +2466,6 @@ static int validate_gl1e(struct vcpu *v,
     }
 #endif /* OOS */
 
-    put_gfn(v->domain, gfn_x(gfn));
     return result;
 }
 
@@ -4715,8 +4714,6 @@ static void sh_pagetable_dying(struct vc
     unsigned long l3gfn;
     mfn_t l3mfn;
 
-    paging_lock(v->domain);
-
     gcr3 = (v->arch.hvm_vcpu.guest_cr[3]);
     /* fast path: the pagetable belongs to the current context */
     if ( gcr3 == gpa )
@@ -4728,8 +4725,11 @@ static void sh_pagetable_dying(struct vc
     {
         printk(XENLOG_DEBUG "sh_pagetable_dying: gpa not valid %"PRIpaddr"\n",
                gpa);
-        goto out;
+        goto out_put_gfn;
     }
+
+    paging_lock(v->domain);
+
     if ( !fast_path )
     {
         gl3pa = sh_map_domain_page(l3mfn);
@@ -4770,11 +4770,11 @@ static void sh_pagetable_dying(struct vc
 
     v->arch.paging.shadow.pagetable_dying = 1;
 
-out:
     if ( !fast_path )
         unmap_domain_page(gl3pa);
+    paging_unlock(v->domain);
+out_put_gfn:
     put_gfn(v->domain, l3gfn);
-    paging_unlock(v->domain);
 }
 #else
 static void sh_pagetable_dying(struct vcpu *v, paddr_t gpa)
@@ -4782,15 +4782,14 @@ static void sh_pagetable_dying(struct vc
     mfn_t smfn, gmfn;
     p2m_type_t p2mt;
 
+    gmfn = get_gfn_query(v->domain, _gfn(gpa >> PAGE_SHIFT), &p2mt);
     paging_lock(v->domain);
 
-    gmfn = get_gfn_query(v->domain, _gfn(gpa >> PAGE_SHIFT), &p2mt);
 #if GUEST_PAGING_LEVELS == 2
     smfn = shadow_hash_lookup(v, mfn_x(gmfn), SH_type_l2_32_shadow);
 #else
     smfn = shadow_hash_lookup(v, mfn_x(gmfn), SH_type_l4_64_shadow);
 #endif
-    put_gfn(v->domain, gpa >> PAGE_SHIFT);
     
     if ( mfn_valid(smfn) )
     {
@@ -4808,6 +4807,7 @@ static void sh_pagetable_dying(struct vc
     v->arch.paging.shadow.pagetable_dying = 1;
 
     paging_unlock(v->domain);
+    put_gfn(v->domain, gpa >> PAGE_SHIFT);
 }
 #endif
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8J-0000HP-PE; Wed, 01 Feb 2012 19:46:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8I-0000Ew-AG
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:18 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328125529!62664952!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15260 invoked from network); 1 Feb 2012 19:45:29 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:29 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 435F3604061;
	Wed,  1 Feb 2012 11:46:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ppilk9lqHMrjey0RPgaRAROvbY2Y0ZoJeeh2JSSxkOrn
	4kbiIuU8VZlTNSQgQt7mn30EqpVZm9LUuVNZFxjkOEi+FiKVbrtZzcrx1eAyODBy
	b+XdAXZAruGg0+dcPXDAgbynOfhfgHE7+0pbmDn2RDEQIWAoidtRdu6sKlRHKH8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fS+zfjnX/h7wnf2oLm3kadHZ1f0=; b=UQH0gvyHwmw
	7CRqB1JXSbmYcyxVuL3rAqhobM5GRasWAjZOYwn2nZPazfINAjughNp2K4/kq3xx
	RAjl3g6DH6qY+4yU0NYJOKKyw/elWctlFo82ZVdceVcRIZKZjRktpuFQjI0IPO5B
	UuSjcOlglT4oPxvOFWO2GG8s3IEBgOMo=
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 9BB2460407C; 
	Wed,  1 Feb 2012 11:46:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9a55109e4d7eb1b467203aaab5239d1daf1bb664
Message-Id: <9a55109e4d7eb1b46720.1328125921@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:52:01 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 9 of 9] x86/mm: Make debug_{gfn, mfn,
 gref} calls to sharing more useful and correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  224 +++++++++++++++++++++--------------------
 1 files changed, 115 insertions(+), 109 deletions(-)


Have them used locked accesors to the gfn and the underlying shared mfn.

Have them return the number of shared refs to the underlying mfn.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 12f7da67cefe -r 9a55109e4d7e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -45,13 +45,13 @@ typedef struct pg_lock_data {
 
 DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
+#define MEM_SHARING_DEBUG(_f, _a...)                                  \
+    debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 #if MEM_SHARING_AUDIT
 
 static void mem_sharing_audit(void);
 
-#define MEM_SHARING_DEBUG(_f, _a...)                                  \
-    debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
-
 static struct list_head shr_audit_list;
 static spinlock_t shr_audit_lock;
 DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
@@ -400,111 +400,6 @@ int mem_sharing_sharing_resume(struct do
     return 0;
 }
 
-int mem_sharing_debug_mfn(unsigned long mfn)
-{
-    struct page_info *page;
-
-    if ( !mfn_valid(_mfn(mfn)) )
-    {
-        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn);
-        return -1;
-    }
-    page = mfn_to_page(_mfn(mfn));
-
-    gdprintk(XENLOG_DEBUG, 
-            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
-            mfn_x(page_to_mfn(page)), 
-            page->count_info, 
-            page->u.inuse.type_info,
-            page_get_owner(page)->domain_id);
-
-    return 0;
-}
-
-int mem_sharing_debug_gfn(struct domain *d, unsigned long gfn)
-{
-    p2m_type_t p2mt;
-    mfn_t mfn;
-
-    mfn = get_gfn_query_unlocked(d, gfn, &p2mt);
-
-    gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
-               d->domain_id, 
-               gfn);
-    return mem_sharing_debug_mfn(mfn_x(mfn));
-}
-
-#define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
-#define shared_entry_v1(t, e) \
-    ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
-#define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
-#define shared_entry_v2(t, e) \
-    ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
-#define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
-#define status_entry(t, e) \
-    ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
-
-static grant_entry_header_t *
-shared_entry_header(struct grant_table *t, grant_ref_t ref)
-{
-    ASSERT (t->gt_version != 0);
-    if ( t->gt_version == 1 )
-        return (grant_entry_header_t*)&shared_entry_v1(t, ref);
-    else
-        return &shared_entry_v2(t, ref).hdr;
-}
-
-static int mem_sharing_gref_to_gfn(struct domain *d, 
-                                   grant_ref_t ref, 
-                                   unsigned long *gfn)
-{
-    if ( d->grant_table->gt_version < 1 )
-        return -1;
-
-    if ( d->grant_table->gt_version == 1 ) 
-    {
-        grant_entry_v1_t *sha1;
-        sha1 = &shared_entry_v1(d->grant_table, ref);
-        *gfn = sha1->frame;
-    } 
-    else 
-    {
-        grant_entry_v2_t *sha2;
-        sha2 = &shared_entry_v2(d->grant_table, ref);
-        *gfn = sha2->full_page.frame;
-    }
- 
-    return 0;
-}
-
-
-int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
-{
-    grant_entry_header_t *shah;
-    uint16_t status;
-    unsigned long gfn;
-
-    if ( d->grant_table->gt_version < 1 )
-    {
-        gdprintk(XENLOG_ERR, 
-                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
-                d->domain_id, ref);
-        return -1;
-    }
-    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
-    shah = shared_entry_header(d->grant_table, ref);
-    if ( d->grant_table->gt_version == 1 ) 
-        status = shah->flags;
-    else 
-        status = status_entry(d->grant_table, ref);
-    
-    gdprintk(XENLOG_DEBUG,
-            "==> Grant [dom=%d,ref=%d], status=%x. ", 
-            d->domain_id, ref, status);
-
-    return mem_sharing_debug_gfn(d, gfn); 
-}
-
 /* Functions that change a page's type and ownership */
 static int page_make_sharable(struct domain *d, 
                        struct page_info *page, 
@@ -606,6 +501,117 @@ static inline struct page_info *__grab_s
     return pg;
 }
 
+int mem_sharing_debug_mfn(mfn_t mfn)
+{
+    struct page_info *page;
+    int num_refs;
+
+    if ( (page = __grab_shared_page(mfn)) == NULL)
+    {
+        gdprintk(XENLOG_ERR, "Invalid MFN=%lx\n", mfn_x(mfn));
+        return -1;
+    }
+
+    MEM_SHARING_DEBUG( 
+            "Debug page: MFN=%lx is ci=%lx, ti=%lx, owner_id=%d\n",
+            mfn_x(page_to_mfn(page)), 
+            page->count_info, 
+            page->u.inuse.type_info,
+            page_get_owner(page)->domain_id);
+
+    /* -1 because the page is locked and that's an additional type ref */
+    num_refs = ((int) (page->u.inuse.type_info & PGT_count_mask)) - 1;
+    mem_sharing_page_unlock(page);
+    return num_refs;
+}
+
+int mem_sharing_debug_gfn(struct domain *d, unsigned long gfn)
+{
+    p2m_type_t p2mt;
+    mfn_t mfn;
+    int num_refs;
+
+    mfn = get_gfn_query(d, gfn, &p2mt);
+
+    MEM_SHARING_DEBUG("Debug for domain=%d, gfn=%lx, ", 
+               d->domain_id, 
+               gfn);
+    num_refs = mem_sharing_debug_mfn(mfn);
+    put_gfn(d, gfn);
+    return num_refs;
+}
+
+#define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t))
+#define shared_entry_v1(t, e) \
+    ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1])
+#define SHGNT_PER_PAGE_V2 (PAGE_SIZE / sizeof(grant_entry_v2_t))
+#define shared_entry_v2(t, e) \
+    ((t)->shared_v2[(e)/SHGNT_PER_PAGE_V2][(e)%SHGNT_PER_PAGE_V2])
+#define STGNT_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
+#define status_entry(t, e) \
+    ((t)->status[(e)/STGNT_PER_PAGE][(e)%STGNT_PER_PAGE])
+
+static grant_entry_header_t *
+shared_entry_header(struct grant_table *t, grant_ref_t ref)
+{
+    ASSERT (t->gt_version != 0);
+    if ( t->gt_version == 1 )
+        return (grant_entry_header_t*)&shared_entry_v1(t, ref);
+    else
+        return &shared_entry_v2(t, ref).hdr;
+}
+
+static int mem_sharing_gref_to_gfn(struct domain *d, 
+                                   grant_ref_t ref, 
+                                   unsigned long *gfn)
+{
+    if ( d->grant_table->gt_version < 1 )
+        return -1;
+
+    if ( d->grant_table->gt_version == 1 ) 
+    {
+        grant_entry_v1_t *sha1;
+        sha1 = &shared_entry_v1(d->grant_table, ref);
+        *gfn = sha1->frame;
+    } 
+    else 
+    {
+        grant_entry_v2_t *sha2;
+        sha2 = &shared_entry_v2(d->grant_table, ref);
+        *gfn = sha2->full_page.frame;
+    }
+ 
+    return 0;
+}
+
+
+int mem_sharing_debug_gref(struct domain *d, grant_ref_t ref)
+{
+    grant_entry_header_t *shah;
+    uint16_t status;
+    unsigned long gfn;
+
+    if ( d->grant_table->gt_version < 1 )
+    {
+        MEM_SHARING_DEBUG( 
+                "Asked to debug [dom=%d,gref=%d], but not yet inited.\n",
+                d->domain_id, ref);
+        return -1;
+    }
+    (void)mem_sharing_gref_to_gfn(d, ref, &gfn); 
+    shah = shared_entry_header(d->grant_table, ref);
+    if ( d->grant_table->gt_version == 1 ) 
+        status = shah->flags;
+    else 
+        status = status_entry(d->grant_table, ref);
+    
+    MEM_SHARING_DEBUG(
+            "==> Grant [dom=%d,ref=%d], status=%x. ", 
+            d->domain_id, ref, status);
+
+    return mem_sharing_debug_gfn(d, gfn); 
+}
+
 int mem_sharing_nominate_page(struct domain *d,
                               unsigned long gfn,
                               int expected_refcnt,
@@ -1169,7 +1175,7 @@ int mem_sharing_domctl(struct domain *d,
         case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
-            rc = mem_sharing_debug_mfn(mfn);
+            rc = mem_sharing_debug_mfn(_mfn(mfn));
         }
         break;
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8I-0000GQ-Bf; Wed, 01 Feb 2012 19:46:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8H-0000ED-86
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328125516!54984789!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzczNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3053 invoked from network); 1 Feb 2012 19:45:17 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-3.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:17 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 877C3604084;
	Wed,  1 Feb 2012 11:46:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=KppOh3RXACOOQCQH6rcZTk2etope6Jed/yEC1IrJBZ4j
	o7cVcKCdcfI3orkM6lSbZgPPnVhChWi2RrODswBESYdPCI375yiuKsDp/AB8nrWI
	a3MD+OU+xv5UUp31+I8fGLf5vvAsJql3JBd6dvXlinPYvUFI9eRtF8QQrfsL8ds=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=kspQgmlDTbQp4vwrTdiUhUMMaOE=; b=DRZQw4LO0TO
	+LSF5dDXMcF40FyyeRXWl6i/gmhNnf58mTF8m+kIcLOfHxsCuyIx1QJiauE0Aan4
	sOkrW+NZP5zkWkKKjDKg/gC6f8NB5be+XF3IGH1RNqZSQ2V+TkOnM2fI0Y2olqR7
	oJDlJSW5TJtQhFR0gQVZkaRfmZnYNUHk=
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 E9EC460407C; 
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 75dec1a0ba2d731ee9778eccfb4998c73c8ecf35
Message-Id: <75dec1a0ba2d731ee977.1328125918@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 9] x86/mm: Fix balooning+sharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/memory.c |  12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)


Never mind that ballooning a shared page makes no sense. We still fix it
because it may be exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1c61573d1765 -r 75dec1a0ba2d xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -185,12 +185,14 @@ int guest_remove_page(struct domain *d, 
 #ifdef CONFIG_X86
     /* If gmfn is shared, just drop the guest reference (which may or may not
      * free the page) */
-    if(p2m_is_shared(p2mt))
+    if ( p2m_is_shared(p2mt) )
     {
-        put_page_and_type(page);
-        guest_physmap_remove_page(d, gmfn, mfn, 0);
-        put_gfn(d, gmfn);
-        return 1;
+        /* Unshare the page, bail out on error. We unshare because 
+         * we might be the only one using this shared page, and we
+         * need to trigger proper cleanup. Once done, this is 
+         * like any other page. */
+        if ( mem_sharing_unshare_page(d, gmfn, 0) )
+            return 0;
     }
 
 #endif /* CONFIG_X86 */

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8H-0000GD-Vh; Wed, 01 Feb 2012 19:46:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8G-0000EC-NC
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328125570!14909377!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTg3MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29436 invoked from network); 1 Feb 2012 19:46:10 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-2.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:46:10 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id B8BDD604061;
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=qszAw2ayyRXNuNHlJWsSPyg3kD6Jp/NHkscK0tY64lIj
	G6Y6F0s5FIqYcukz6A4PDFYhroDwvw8hfKtXNwDcQkEpXyYdQ8Tt9okXgBx7K9XQ
	B1UspIv7IyHyBK93ucIF4rwDJdhDSaAZ1VzL2/FdpTotErQMjew8UquIUw2Na44=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=a7OIrawuXpJWk3MX4i4aFJM24oE=; b=o5HklncmgLm
	87KKTKHLcVbU0rDDC2xD1Gee585dovwgrUJVV5AbQD6XxGaI5DYnYYpZwwpQxazJ
	lPfCxzK6jhUX2IHw3EiznbRtQo2lCK0DqC6H6grTqLBktMcMJ5Nw0Y0jkgYMplHX
	Fdh2ck1jS/4N6rRc1OeuajAkvHeykkbY=
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 363A860407C; 
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1c61573d17650c67448cf6f86d8a3c60613e3462
Message-Id: <1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:57 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 9] x86/mm: When removing/adding a page
 from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)


When removing the m2p mapping it is unconditionally set to invalid, which
breaks sharing.

When adding to the physmap, if the previous holder of that entry is a shared
page, we unshare to default to normal case handling.

And, we cannot add a shared page directly to the physmap. Proper interfaces
must be employed, otherwise book-keeping goes awry.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8a920bcddd0f -r 1c61573d1765 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -419,7 +419,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         for ( i = 0; i < (1UL << page_order); i++ )
         {
             mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
-            if ( !p2m_is_grant(t) )
+            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
         }
@@ -481,6 +481,17 @@ guest_physmap_add_entry(struct domain *d
     for ( i = 0; i < (1UL << page_order); i++ )
     {
         omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+        if ( p2m_is_shared(ot) )
+        {
+            /* Do an unshare to cleanly take care of all corner 
+             * cases. */
+            int rc;
+            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
+            if ( rc )
+                return rc;
+            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+            ASSERT(!p2m_is_shared(ot));
+        }
         if ( p2m_is_grant(ot) )
         {
             /* Really shouldn't be unmapping grant maps this way */
@@ -504,6 +515,14 @@ guest_physmap_add_entry(struct domain *d
     /* Then, look for m->p mappings for this range and deal with them */
     for ( i = 0; i < (1UL << page_order); i++ )
     {
+        if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) == dom_cow )
+        {
+            /* This is no way to add a shared page to your physmap! */
+            gdprintk(XENLOG_ERR, "Adding shared mfn %lx directly to dom %hu "
+                        "physmap not allowed.\n", mfn+i, d->domain_id);
+            p2m_unlock(p2m);
+            return -EINVAL;
+        }
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8E-0000EY-4M; Wed, 01 Feb 2012 19:46:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8C-0000Ds-WC
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328125566!12911299!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTg3MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6065 invoked from network); 1 Feb 2012 19:46:06 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:46:06 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id B4951604092;
	Wed,  1 Feb 2012 11:46:05 -0800 (PST)
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=fJIig68htA23NJMS5j8HsF
	wOYl9P+Mil+Dti1d+cMuBwNM7HkO1TOTR30FXUnfW2Z+WBAyUoHaAhuKVVN6PUrh
	oTBYZD6oX99AuxzuEeZq6wvYRRuCLhg7JzLnG3jT2mXTrG7T98ve6G+cEqqRolXX
	NwryRhRNYOXrEYniUSNA8=
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=/8GfUdybAsOk
	7vQ9WAwcNj2yzKM=; b=DvvTAaAP4zvRcnURTwfIFHbqgR94hQ+GGb6yTXQuFBjA
	WzWureoDilnywFXPPIdudC+3ztA86cwGV25ljtqlB23wljo9KCSzMtW4N8fwWcvn
	fkYFPtvZOdRF/r4etTzXUqhuiChv64kaTOCMZWoRoUl5Ym25Fo/54qhD5e4bO38=
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 E9057604084; 
	Wed,  1 Feb 2012 11:46:04 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:52 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] x86/mm: Fixes to sharing, paging and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series aggregates a number of fixes to different areas of mm:

Sharing:
 - Make sharing play nice with balloon
 - Make physmap manipulations deall correctly with shared pages
 - Make sharing debug calls use locked accessors and return useful information

Paging:
 - Eliminate a needless state in the paging state machine
 - Fix stats/accounting
 - Fix page type check when nominating or evicting a page

P2M:
This changes clear hurdles in advance of a fully-synchronized p2m
 - Eliminate possibility of deadlock in nested lookups
 - Reorder some locks taken by the sharing subsystem

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c               |    8 +-
 xen/arch/x86/mm/p2m-ept.c       |    3 +-
 xen/arch/x86/mm/p2m.c           |    7 +-
 xen/include/asm-x86/p2m.h       |    7 +-
 xen/arch/x86/mm/p2m.c           |    4 +-
 xen/arch/x86/hvm/emulate.c      |   35 ++---
 xen/arch/x86/mm/mem_sharing.c   |   28 ++--
 xen/include/asm-x86/p2m.h       |   91 ++++++++++++++++
 xen/arch/x86/mm/shadow/common.c |    3 +
 xen/arch/x86/mm/shadow/multi.c  |   18 +-
 xen/arch/x86/mm/p2m.c           |   21 +++-
 xen/common/memory.c             |   12 +-
 xen/arch/x86/mm/mem_sharing.c   |    6 +-
 xen/arch/x86/mm/p2m.c           |   12 +-
 xen/common/memory.c             |    2 +-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/arch/x86/mm/mem_sharing.c   |    7 +-
 xen/arch/x86/mm/mem_sharing.c   |  224 ++++++++++++++++++++-------------------
 18 files changed, 315 insertions(+), 179 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8I-0000GQ-Bf; Wed, 01 Feb 2012 19:46:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8H-0000ED-86
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328125516!54984789!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzczNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3053 invoked from network); 1 Feb 2012 19:45:17 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-3.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:45:17 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 877C3604084;
	Wed,  1 Feb 2012 11:46:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=KppOh3RXACOOQCQH6rcZTk2etope6Jed/yEC1IrJBZ4j
	o7cVcKCdcfI3orkM6lSbZgPPnVhChWi2RrODswBESYdPCI375yiuKsDp/AB8nrWI
	a3MD+OU+xv5UUp31+I8fGLf5vvAsJql3JBd6dvXlinPYvUFI9eRtF8QQrfsL8ds=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=kspQgmlDTbQp4vwrTdiUhUMMaOE=; b=DRZQw4LO0TO
	+LSF5dDXMcF40FyyeRXWl6i/gmhNnf58mTF8m+kIcLOfHxsCuyIx1QJiauE0Aan4
	sOkrW+NZP5zkWkKKjDKg/gC6f8NB5be+XF3IGH1RNqZSQ2V+TkOnM2fI0Y2olqR7
	oJDlJSW5TJtQhFR0gQVZkaRfmZnYNUHk=
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 E9EC460407C; 
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 75dec1a0ba2d731ee9778eccfb4998c73c8ecf35
Message-Id: <75dec1a0ba2d731ee977.1328125918@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 9] x86/mm: Fix balooning+sharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/memory.c |  12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)


Never mind that ballooning a shared page makes no sense. We still fix it
because it may be exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1c61573d1765 -r 75dec1a0ba2d xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -185,12 +185,14 @@ int guest_remove_page(struct domain *d, 
 #ifdef CONFIG_X86
     /* If gmfn is shared, just drop the guest reference (which may or may not
      * free the page) */
-    if(p2m_is_shared(p2mt))
+    if ( p2m_is_shared(p2mt) )
     {
-        put_page_and_type(page);
-        guest_physmap_remove_page(d, gmfn, mfn, 0);
-        put_gfn(d, gmfn);
-        return 1;
+        /* Unshare the page, bail out on error. We unshare because 
+         * we might be the only one using this shared page, and we
+         * need to trigger proper cleanup. Once done, this is 
+         * like any other page. */
+        if ( mem_sharing_unshare_page(d, gmfn, 0) )
+            return 0;
     }
 
 #endif /* CONFIG_X86 */

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8G-0000FS-4i; Wed, 01 Feb 2012 19:46:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8F-0000Dy-15
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328125567!5041211!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32614 invoked from network); 1 Feb 2012 19:46:08 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:46:08 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 6CB6360408D;
	Wed,  1 Feb 2012 11:46:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cC7x3LbllWkX67Kgn3ZwDqZV6bdkTPxF19KswRejUed8
	52ltu2JU7ZCA5AbF7vD+PhExzZRMXV7qrdH1gp/BOamwT59EbnxeGiX5m+gpqmTR
	z9IQnRRaAUs3ddHTi+OECuSUpN9Wa/NR2bGJpDJSIpVE/lQbwPOnltfCDJcRguc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BCefQ3/frUlnEdVDoSzIGBJmbW0=; b=fWt6jfAD1Ba
	rqR/WOFjHYufup3xT8JDeV7r4dakk8xECIrry35GzhdzGes335cDh5YqJsE3dFjh
	u24w5FlOOHn+N8v5kZj7uIxURyo3Z+cIDuV3DvLSG9zYI0QIqSCiqLGsJguMYWPJ
	EWWSlkGGGIrYyj5lkSGv+6QDJAxsoSn0=
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 CDEC260407C; 
	Wed,  1 Feb 2012 11:46:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 27031a8a4effeb184ee6e142b7c5435b04d1cc15
Message-Id: <27031a8a4effeb184ee6.1328125914@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:54 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 9] x86/mm: Don't fail to nominate for
 paging on type flag, rather look at type count
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Xen doesn't clean the type flag when dropping the type count for a page to
zero. So, looking at the type flag when nominating a page for paging it's
incorrect. Look at the type count instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r decd21170c2a -r 27031a8a4eff xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -761,7 +761,7 @@ int p2m_mem_paging_nominate(struct domai
          (1 | PGC_allocated) )
         goto out;
 
-    if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
         goto out;
 
     /* Fix p2m entry */
@@ -823,7 +823,7 @@ int p2m_mem_paging_evict(struct domain *
          (2 | PGC_allocated) )
         goto out_put;
 
-    if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
         goto out_put;
 
     /* Decrement guest domain's ref count of the page */

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8E-0000EY-4M; Wed, 01 Feb 2012 19:46:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8C-0000Ds-WC
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328125566!12911299!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTg3MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6065 invoked from network); 1 Feb 2012 19:46:06 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:46:06 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id B4951604092;
	Wed,  1 Feb 2012 11:46:05 -0800 (PST)
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=fJIig68htA23NJMS5j8HsF
	wOYl9P+Mil+Dti1d+cMuBwNM7HkO1TOTR30FXUnfW2Z+WBAyUoHaAhuKVVN6PUrh
	oTBYZD6oX99AuxzuEeZq6wvYRRuCLhg7JzLnG3jT2mXTrG7T98ve6G+cEqqRolXX
	NwryRhRNYOXrEYniUSNA8=
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=/8GfUdybAsOk
	7vQ9WAwcNj2yzKM=; b=DvvTAaAP4zvRcnURTwfIFHbqgR94hQ+GGb6yTXQuFBjA
	WzWureoDilnywFXPPIdudC+3ztA86cwGV25ljtqlB23wljo9KCSzMtW4N8fwWcvn
	fkYFPtvZOdRF/r4etTzXUqhuiChv64kaTOCMZWoRoUl5Ym25Fo/54qhD5e4bO38=
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 E9057604084; 
	Wed,  1 Feb 2012 11:46:04 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:52 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] x86/mm: Fixes to sharing, paging and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series aggregates a number of fixes to different areas of mm:

Sharing:
 - Make sharing play nice with balloon
 - Make physmap manipulations deall correctly with shared pages
 - Make sharing debug calls use locked accessors and return useful information

Paging:
 - Eliminate a needless state in the paging state machine
 - Fix stats/accounting
 - Fix page type check when nominating or evicting a page

P2M:
This changes clear hurdles in advance of a fully-synchronized p2m
 - Eliminate possibility of deadlock in nested lookups
 - Reorder some locks taken by the sharing subsystem

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm.c               |    8 +-
 xen/arch/x86/mm/p2m-ept.c       |    3 +-
 xen/arch/x86/mm/p2m.c           |    7 +-
 xen/include/asm-x86/p2m.h       |    7 +-
 xen/arch/x86/mm/p2m.c           |    4 +-
 xen/arch/x86/hvm/emulate.c      |   35 ++---
 xen/arch/x86/mm/mem_sharing.c   |   28 ++--
 xen/include/asm-x86/p2m.h       |   91 ++++++++++++++++
 xen/arch/x86/mm/shadow/common.c |    3 +
 xen/arch/x86/mm/shadow/multi.c  |   18 +-
 xen/arch/x86/mm/p2m.c           |   21 +++-
 xen/common/memory.c             |   12 +-
 xen/arch/x86/mm/mem_sharing.c   |    6 +-
 xen/arch/x86/mm/p2m.c           |   12 +-
 xen/common/memory.c             |    2 +-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/arch/x86/mm/mem_sharing.c   |    7 +-
 xen/arch/x86/mm/mem_sharing.c   |  224 ++++++++++++++++++++-------------------
 18 files changed, 315 insertions(+), 179 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8H-0000GD-Vh; Wed, 01 Feb 2012 19:46:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8G-0000EC-NC
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328125570!14909377!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTg3MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29436 invoked from network); 1 Feb 2012 19:46:10 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-2.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:46:10 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id B8BDD604061;
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=qszAw2ayyRXNuNHlJWsSPyg3kD6Jp/NHkscK0tY64lIj
	G6Y6F0s5FIqYcukz6A4PDFYhroDwvw8hfKtXNwDcQkEpXyYdQ8Tt9okXgBx7K9XQ
	B1UspIv7IyHyBK93ucIF4rwDJdhDSaAZ1VzL2/FdpTotErQMjew8UquIUw2Na44=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=a7OIrawuXpJWk3MX4i4aFJM24oE=; b=o5HklncmgLm
	87KKTKHLcVbU0rDDC2xD1Gee585dovwgrUJVV5AbQD6XxGaI5DYnYYpZwwpQxazJ
	lPfCxzK6jhUX2IHw3EiznbRtQo2lCK0DqC6H6grTqLBktMcMJ5Nw0Y0jkgYMplHX
	Fdh2ck1jS/4N6rRc1OeuajAkvHeykkbY=
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 363A860407C; 
	Wed,  1 Feb 2012 11:46:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1c61573d17650c67448cf6f86d8a3c60613e3462
Message-Id: <1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:57 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 9] x86/mm: When removing/adding a page
 from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)


When removing the m2p mapping it is unconditionally set to invalid, which
breaks sharing.

When adding to the physmap, if the previous holder of that entry is a shared
page, we unshare to default to normal case handling.

And, we cannot add a shared page directly to the physmap. Proper interfaces
must be employed, otherwise book-keeping goes awry.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8a920bcddd0f -r 1c61573d1765 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -419,7 +419,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         for ( i = 0; i < (1UL << page_order); i++ )
         {
             mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
-            if ( !p2m_is_grant(t) )
+            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
         }
@@ -481,6 +481,17 @@ guest_physmap_add_entry(struct domain *d
     for ( i = 0; i < (1UL << page_order); i++ )
     {
         omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+        if ( p2m_is_shared(ot) )
+        {
+            /* Do an unshare to cleanly take care of all corner 
+             * cases. */
+            int rc;
+            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
+            if ( rc )
+                return rc;
+            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+            ASSERT(!p2m_is_shared(ot));
+        }
         if ( p2m_is_grant(ot) )
         {
             /* Really shouldn't be unmapping grant maps this way */
@@ -504,6 +515,14 @@ guest_physmap_add_entry(struct domain *d
     /* Then, look for m->p mappings for this range and deal with them */
     for ( i = 0; i < (1UL << page_order); i++ )
     {
+        if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) == dom_cow )
+        {
+            /* This is no way to add a shared page to your physmap! */
+            gdprintk(XENLOG_ERR, "Adding shared mfn %lx directly to dom %hu "
+                        "physmap not allowed.\n", mfn+i, d->domain_id);
+            p2m_unlock(p2m);
+            return -EINVAL;
+        }
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsg8G-0000FS-4i; Wed, 01 Feb 2012 19:46:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsg8F-0000Dy-15
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:46:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328125567!5041211!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32614 invoked from network); 1 Feb 2012 19:46:08 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:46:08 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 6CB6360408D;
	Wed,  1 Feb 2012 11:46:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cC7x3LbllWkX67Kgn3ZwDqZV6bdkTPxF19KswRejUed8
	52ltu2JU7ZCA5AbF7vD+PhExzZRMXV7qrdH1gp/BOamwT59EbnxeGiX5m+gpqmTR
	z9IQnRRaAUs3ddHTi+OECuSUpN9Wa/NR2bGJpDJSIpVE/lQbwPOnltfCDJcRguc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=BCefQ3/frUlnEdVDoSzIGBJmbW0=; b=fWt6jfAD1Ba
	rqR/WOFjHYufup3xT8JDeV7r4dakk8xECIrry35GzhdzGes335cDh5YqJsE3dFjh
	u24w5FlOOHn+N8v5kZj7uIxURyo3Z+cIDuV3DvLSG9zYI0QIqSCiqLGsJguMYWPJ
	EWWSlkGGGIrYyj5lkSGv+6QDJAxsoSn0=
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 CDEC260407C; 
	Wed,  1 Feb 2012 11:46:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 27031a8a4effeb184ee6e142b7c5435b04d1cc15
Message-Id: <27031a8a4effeb184ee6.1328125914@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:51:54 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 9] x86/mm: Don't fail to nominate for
 paging on type flag, rather look at type count
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Xen doesn't clean the type flag when dropping the type count for a page to
zero. So, looking at the type flag when nominating a page for paging it's
incorrect. Look at the type count instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r decd21170c2a -r 27031a8a4eff xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -761,7 +761,7 @@ int p2m_mem_paging_nominate(struct domai
          (1 | PGC_allocated) )
         goto out;
 
-    if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
         goto out;
 
     /* Fix p2m entry */
@@ -823,7 +823,7 @@ int p2m_mem_paging_evict(struct domain *
          (2 | PGC_allocated) )
         goto out_put;
 
-    if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_none )
+    if ( (page->u.inuse.type_info & PGT_count_mask) != 0 )
         goto out_put;
 
     /* Decrement guest domain's ref count of the page */

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:48:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:48: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.xensource.com>)
	id 1RsgAV-0001Lj-Uy; Wed, 01 Feb 2012 19:48:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RsgAV-0001KZ-6c
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:48:35 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328125706!9693778!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26113 invoked from network); 1 Feb 2012 19:48:28 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 19:48:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=sSprVWm2XcsM
	eKIlC0lF9QrRGnA=; b=MdxsdWyGFh2JDNVR8IMqxqsgcQzM8PKF+doAP3sDRwul
	eoZ4B2PCizD+hGQtKDM4HkBUwz+KyAbyAkncDuSILyee5QrsdDM++b1C35Hl/J7F
	vFJv3D3SXzq5W4UUfvFSPLg1DO5Gt4e30FQI93L6UYsubYRorAxuphHzg4ajOsQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=j2EY81
	hs6NDWyh/Xd5aQPM6FReunLkpiTLvYE/EHrfJnGnnX5pg6I7HfuSt9lx1r4LaIOs
	19gPCBzCOvdPS2rzNH8XH+x5nUtxIEzjEo2IWTchy9Ea2/YB8GZwfcwJANF/rv+2
	zqS6iPr+lrskORJ63dvUrvL3WsLYMi42shEro=
Received: (qmail 21965 invoked from network); 1 Feb 2012 19:48:25 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	1 Feb 2012 19:48:25 -0000
Message-ID: <4F299707.3080704@gt.net>
Date: Wed, 01 Feb 2012 11:48:23 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
In-Reply-To: <20120201013036.GA12637@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/31/2012 5:30 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 31, 2012 at 01:42:23PM -0800, Nathan March wrote:
>> Hi All,
>>
>> We've got a xen setup based around a dell iscsi device with each xen
>> host having 2 lun's, we then run multipath on top of that. After adding
>> a couple new virtual disks the other day, a couple of our online stable
>> VM's suddenly hard locked up. Attaching to the console gave me nothing,
>> looked like they lost their disk devices.
>>
>> Attempting to restart them on the same dom0 failed with hot plug errors,
>> as did attempting to start them on a few different dom0's. After doing a
>> "multipath -F" to remove unused devices and manually bringing in just
>> the selected LUN's via "multipath diskname", I was able to successfully
>> start them. This initially made me think perhaps I was hitting some sort
>> of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun
>> = 1088 iscsi connections). Just to be clear, the problem occurred on
>> multiple dom0's at the same time so it definitely seems iscsi related.
>>
>> Now, a day later, I'm debugging this further and I'm again unable to
>> start VM's, even with all extra multipath devices removed. I rebooted
>> one of the dom0's and was able to successfully migrate our production
>> VM's off a broken server, so I've now got an empty dom0 that's unable to
>> start any vm's.
>>
>> Starting a VM results in the following in xend.log:
>>
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:628)
>> hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
>> [2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices
>> failed.
>> Traceback (most recent call last):
>>    File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line
>> 85, in perform
>>      return op_method(op, req)
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line
>> 85, in op_wait_for_devices
>>      return self.dom.waitForDevices()
>>    File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
>> line 1237, in waitForDevices
>>      self.getDeviceController(devclass).waitForDevices()
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 140, in waitForDevices
>>      return map(self.waitForDevice, self.deviceIDs())
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 155, in waitForDevice
>>      (devid, self.deviceClass))
>> VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.
>
> Was there anything in the kernel (dmesg) about vifs? What does your
> /proc/interrupts look like? Can you provide the dmesg that you get
> during startup. I am mainly looking for:
>
> NR_IRQS:16640 nr_irqs:1536 16
>
> How many guests are your running when this happens?
>
> One theory is that your are running out dom0 interrupts. Thought
> I *think* that was made dynamic in 3.0..
>
>
> Thought that does explain your iSCSI network wonky in the guest -
> was there anything in the dmesg when the guest started going bad?

Was running approximately 15 guests, although this persisted after 
migrating them off.

Nothing in dmesg (dom0 dmesg or xm dmesg) that looked abnormal at all, 
no references to vifs. Asides from the inability to start a VM, I 
couldn't seem to find any sort of error anywhere.

All the hosts show the same irq counts:[   34.903763] NR_IRQS:4352 
nr_irqs:4352 16

Unfortunately I'm not able to reproduce this now, but I've posted 
several different copies of /proc/interrupts here: 
http://pastebin.com/n7PWNeaZ

Full xm / kernel dmesg is uploaded here: http://pastebin.com/AtCvFBDS

>> [2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071)
>> XendDomainInfo.destroy: domid=35
>> [2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying
>> device model
>>
>> I tried turning up udev's log level but that didn't reveal anything.
>> Reading the xenstore for the vif doesn't show anything unusual either:
>>
>> ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
>> 0 = ""
>>   bridge = "vlan91"
>>   domain = "nathanxenuk1"
>>   handle = "0"
>>   uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
>>   script = "/etc/xen/scripts/vif-bridge"
>>   state = "1"
>>   frontend = "/local/domain/35/device/vif/0"
>>   mac = "00:16:3d:03:00:44"
>>   online = "1"
>>   frontend-id = "35"
>>
>> The bridge device (vlan91) exists, trying a different bridge doesn't
>> matter. Removing the VIF completely results in the same error for the
>> VBD. Adding debugging to the hotplug/network scripts didn't reveal
>> anything, it looks like they aren't even being executed yet. Nothing is
>> logged to xen-hotplug.log.
> OK, so that would imply the kernel hasn't been able to do the right
> thing. Hmm.
>
> What do you see when this happens with udev --monitor --kernel --udev
> --property ?

The remaining server I thought was doing this is apparently not (I was 
probably mistaken), so the 2 that were definitely doing it have been 
rebooted and I can't reproduce this at the moment.

I've been abusing a free server all morning with a loop to 
spawn/shutdown a VM repeatedly and flush / rescan multipath to see if I 
can reproduce this again. No luck so far unfortunately, but I'll keep 
trying.


>> The only thing I can think of that this may be related to, is gentoo
>> defaulted to a 10mb /dev which we filled up a few months back. We upped
>> the size to 50mb in the mount options and everything's been completely
>> stable since (~33 days). None of the /dev on the dom0's is higher than
>> 25% usage. Asides from adding the new luns, no changes have been made in
>> the past month.
>>
>> To try and test if removing some devices would solve anything, I tried
>> doing an "iscsiadm -m node --logout" and it promptly hard locked the
>> entire box. After a reboot, I was unable to reproduce the problem on
>> that particular dom0.
>>
>> I've still got 1 dom0 that's exhibiting the problem, if anyone is able
>> to suggest any further debugging steps?
>>
>> - Nathan
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:48:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:48: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.xensource.com>)
	id 1RsgAV-0001Lj-Uy; Wed, 01 Feb 2012 19:48:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RsgAV-0001KZ-6c
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:48:35 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328125706!9693778!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26113 invoked from network); 1 Feb 2012 19:48:28 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 19:48:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=sSprVWm2XcsM
	eKIlC0lF9QrRGnA=; b=MdxsdWyGFh2JDNVR8IMqxqsgcQzM8PKF+doAP3sDRwul
	eoZ4B2PCizD+hGQtKDM4HkBUwz+KyAbyAkncDuSILyee5QrsdDM++b1C35Hl/J7F
	vFJv3D3SXzq5W4UUfvFSPLg1DO5Gt4e30FQI93L6UYsubYRorAxuphHzg4ajOsQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=j2EY81
	hs6NDWyh/Xd5aQPM6FReunLkpiTLvYE/EHrfJnGnnX5pg6I7HfuSt9lx1r4LaIOs
	19gPCBzCOvdPS2rzNH8XH+x5nUtxIEzjEo2IWTchy9Ea2/YB8GZwfcwJANF/rv+2
	zqS6iPr+lrskORJ63dvUrvL3WsLYMi42shEro=
Received: (qmail 21965 invoked from network); 1 Feb 2012 19:48:25 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	1 Feb 2012 19:48:25 -0000
Message-ID: <4F299707.3080704@gt.net>
Date: Wed, 01 Feb 2012 11:48:23 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
In-Reply-To: <20120201013036.GA12637@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/31/2012 5:30 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 31, 2012 at 01:42:23PM -0800, Nathan March wrote:
>> Hi All,
>>
>> We've got a xen setup based around a dell iscsi device with each xen
>> host having 2 lun's, we then run multipath on top of that. After adding
>> a couple new virtual disks the other day, a couple of our online stable
>> VM's suddenly hard locked up. Attaching to the console gave me nothing,
>> looked like they lost their disk devices.
>>
>> Attempting to restart them on the same dom0 failed with hot plug errors,
>> as did attempting to start them on a few different dom0's. After doing a
>> "multipath -F" to remove unused devices and manually bringing in just
>> the selected LUN's via "multipath diskname", I was able to successfully
>> start them. This initially made me think perhaps I was hitting some sort
>> of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun
>> = 1088 iscsi connections). Just to be clear, the problem occurred on
>> multiple dom0's at the same time so it definitely seems iscsi related.
>>
>> Now, a day later, I'm debugging this further and I'm again unable to
>> start VM's, even with all extra multipath devices removed. I rebooted
>> one of the dom0's and was able to successfully migrate our production
>> VM's off a broken server, so I've now got an empty dom0 that's unable to
>> start any vm's.
>>
>> Starting a VM results in the following in xend.log:
>>
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:628)
>> hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
>> [2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices
>> failed.
>> Traceback (most recent call last):
>>    File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line
>> 85, in perform
>>      return op_method(op, req)
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line
>> 85, in op_wait_for_devices
>>      return self.dom.waitForDevices()
>>    File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
>> line 1237, in waitForDevices
>>      self.getDeviceController(devclass).waitForDevices()
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 140, in waitForDevices
>>      return map(self.waitForDevice, self.deviceIDs())
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 155, in waitForDevice
>>      (devid, self.deviceClass))
>> VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.
>
> Was there anything in the kernel (dmesg) about vifs? What does your
> /proc/interrupts look like? Can you provide the dmesg that you get
> during startup. I am mainly looking for:
>
> NR_IRQS:16640 nr_irqs:1536 16
>
> How many guests are your running when this happens?
>
> One theory is that your are running out dom0 interrupts. Thought
> I *think* that was made dynamic in 3.0..
>
>
> Thought that does explain your iSCSI network wonky in the guest -
> was there anything in the dmesg when the guest started going bad?

Was running approximately 15 guests, although this persisted after 
migrating them off.

Nothing in dmesg (dom0 dmesg or xm dmesg) that looked abnormal at all, 
no references to vifs. Asides from the inability to start a VM, I 
couldn't seem to find any sort of error anywhere.

All the hosts show the same irq counts:[   34.903763] NR_IRQS:4352 
nr_irqs:4352 16

Unfortunately I'm not able to reproduce this now, but I've posted 
several different copies of /proc/interrupts here: 
http://pastebin.com/n7PWNeaZ

Full xm / kernel dmesg is uploaded here: http://pastebin.com/AtCvFBDS

>> [2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071)
>> XendDomainInfo.destroy: domid=35
>> [2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying
>> device model
>>
>> I tried turning up udev's log level but that didn't reveal anything.
>> Reading the xenstore for the vif doesn't show anything unusual either:
>>
>> ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
>> 0 = ""
>>   bridge = "vlan91"
>>   domain = "nathanxenuk1"
>>   handle = "0"
>>   uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
>>   script = "/etc/xen/scripts/vif-bridge"
>>   state = "1"
>>   frontend = "/local/domain/35/device/vif/0"
>>   mac = "00:16:3d:03:00:44"
>>   online = "1"
>>   frontend-id = "35"
>>
>> The bridge device (vlan91) exists, trying a different bridge doesn't
>> matter. Removing the VIF completely results in the same error for the
>> VBD. Adding debugging to the hotplug/network scripts didn't reveal
>> anything, it looks like they aren't even being executed yet. Nothing is
>> logged to xen-hotplug.log.
> OK, so that would imply the kernel hasn't been able to do the right
> thing. Hmm.
>
> What do you see when this happens with udev --monitor --kernel --udev
> --property ?

The remaining server I thought was doing this is apparently not (I was 
probably mistaken), so the 2 that were definitely doing it have been 
rebooted and I can't reproduce this at the moment.

I've been abusing a free server all morning with a loop to 
spawn/shutdown a VM repeatedly and flush / rescan multipath to see if I 
can reproduce this again. No luck so far unfortunately, but I'll keep 
trying.


>> The only thing I can think of that this may be related to, is gentoo
>> defaulted to a 10mb /dev which we filled up a few months back. We upped
>> the size to 50mb in the mount options and everything's been completely
>> stable since (~33 days). None of the /dev on the dom0's is higher than
>> 25% usage. Asides from adding the new luns, no changes have been made in
>> the past month.
>>
>> To try and test if removing some devices would solve anything, I tried
>> doing an "iscsiadm -m node --logout" and it promptly hard locked the
>> entire box. After a reboot, I was unable to reproduce the problem on
>> that particular dom0.
>>
>> I've still got 1 dom0 that's exhibiting the problem, if anyone is able
>> to suggest any further debugging steps?
>>
>> - Nathan
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


-- 
Nathan March<nathan@gt.net>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgCP-0001wq-Gv; Wed, 01 Feb 2012 19:50:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCN-0001vO-OQ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328125758!62196513!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzczNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25177 invoked from network); 1 Feb 2012 19:49:18 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:49:18 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 6C1424B008F;
	Wed,  1 Feb 2012 11:50:26 -0800 (PST)
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=vZTKWQwPcUJIHSP/JZAMSG
	tqMrT+isEPf5HUyHGcQAx8QoT+UDdBAljbxzERbks5FUc//DL7Z/mK67fCkr1Ix3
	lXwNqz4xie7uwdrqOuXtvKPZsFkNTnbJ6T8LdciO7Dr0pF53gxd8NsI94a82Bg4r
	NEN0VYDskUsB4RtM24w80=
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=FCERAp8It8bL
	5qxWblJd95akeXw=; b=AO0O1OiN7ipdKmemI2jZoQUUumGYqQm8IjYEg3id5AKY
	ybq4G1lVf1oa5xYHOx/cnoJJAKfiXWvzcYBvExpHaBjaGqldwpQ7MIwoI9dSpBAX
	uMTiSDBRh+1aY8tto21A9S6oGOj+BPgM9auitqaL9sey38OuRZGSwJ/Umg0ONHE=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 67C0E4B0084; 
	Wed,  1 Feb 2012 11:50:25 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Synchronized p2m lookups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Up until now, p2m lookups (get_gfn*) in the x86 architecture were not
synchronized against concurrent updates. With the addition of sharing and
paging subsystems that can dynamically modify the p2m, the need for
synchronized lookups becomes more pressing.

Without synchronized lookups, we've encountered host crashes triggered by race
conditions, particularly when exercising the sharing subsystem.

In this patch series we make p2m lookups fully synchronized. We still use a
single per-domain p2m lock (profiling work tbd may or may not indicate the need
for fine-grained locking).

We only enforce locking of p2m queries for hap-assisted domains. These are the
domains (in the case of EPT) that can exercise the paging and sharing
subsystems and thus most in need of synchronized lookups.

While the code *should* work for domains relying on shadow paging, it has not
been tested, hence we do not enable this at the moment.

Finally, the locking discipline in the PoD subsystem has been updated, since
PoD relied on some assumptions about the way the p2m lock is used.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/hap/hap.c        |    6 ++
 xen/arch/x86/mm/mm-locks.h       |   40 ++++++++-----
 xen/arch/x86/mm/p2m.c            |   21 ++++++-
 xen/include/asm-x86/p2m.h        |   47 ++++++++++------
 xen/arch/x86/mm/mem_sharing.c    |    2 -
 xen/arch/x86/mm/mm-locks.h       |    4 +-
 xen/arch/x86/mm/p2m-ept.c        |   33 +----------
 xen/arch/x86/mm/p2m-pod.c        |   14 +++-
 xen/arch/x86/mm/p2m-pt.c         |   45 ++------------
 xen/arch/x86/mm/p2m.c            |   64 +++++++++++----------
 xen/arch/x86/mm/mm-locks.h       |   10 +++
 xen/arch/x86/mm/p2m-pod.c        |  112 +++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m-pt.c         |    1 +
 xen/arch/x86/mm/p2m.c            |    8 ++-
 xen/include/asm-x86/p2m.h        |   27 ++------
 xen/arch/x86/hvm/emulate.c       |    2 +-
 xen/arch/x86/hvm/hvm.c           |   25 +++++--
 xen/arch/x86/mm.c                |   10 +-
 xen/arch/x86/mm/guest_walk.c     |    2 +-
 xen/arch/x86/mm/hap/guest_walk.c |    6 +-
 xen/arch/x86/mm/mem_access.c     |   10 +++
 xen/arch/x86/mm/mem_event.c      |    5 +
 xen/arch/x86/mm/p2m.c            |   52 ++++++++++--------
 xen/common/grant_table.c         |    2 +-
 xen/common/memory.c              |    2 +-
 xen/include/asm-x86/mem_access.h |    1 +
 xen/include/asm-x86/mem_event.h  |    3 +
 xen/include/asm-x86/p2m.h        |    6 +-
 xen/arch/x86/mm/p2m.c            |    4 +-
 29 files changed, 312 insertions(+), 252 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgCP-0001wq-Gv; Wed, 01 Feb 2012 19:50:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCN-0001vO-OQ
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328125758!62196513!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzczNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25177 invoked from network); 1 Feb 2012 19:49:18 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 19:49:18 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 6C1424B008F;
	Wed,  1 Feb 2012 11:50:26 -0800 (PST)
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=vZTKWQwPcUJIHSP/JZAMSG
	tqMrT+isEPf5HUyHGcQAx8QoT+UDdBAljbxzERbks5FUc//DL7Z/mK67fCkr1Ix3
	lXwNqz4xie7uwdrqOuXtvKPZsFkNTnbJ6T8LdciO7Dr0pF53gxd8NsI94a82Bg4r
	NEN0VYDskUsB4RtM24w80=
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=FCERAp8It8bL
	5qxWblJd95akeXw=; b=AO0O1OiN7ipdKmemI2jZoQUUumGYqQm8IjYEg3id5AKY
	ybq4G1lVf1oa5xYHOx/cnoJJAKfiXWvzcYBvExpHaBjaGqldwpQ7MIwoI9dSpBAX
	uMTiSDBRh+1aY8tto21A9S6oGOj+BPgM9auitqaL9sey38OuRZGSwJ/Umg0ONHE=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 67C0E4B0084; 
	Wed,  1 Feb 2012 11:50:25 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Synchronized p2m lookups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Up until now, p2m lookups (get_gfn*) in the x86 architecture were not
synchronized against concurrent updates. With the addition of sharing and
paging subsystems that can dynamically modify the p2m, the need for
synchronized lookups becomes more pressing.

Without synchronized lookups, we've encountered host crashes triggered by race
conditions, particularly when exercising the sharing subsystem.

In this patch series we make p2m lookups fully synchronized. We still use a
single per-domain p2m lock (profiling work tbd may or may not indicate the need
for fine-grained locking).

We only enforce locking of p2m queries for hap-assisted domains. These are the
domains (in the case of EPT) that can exercise the paging and sharing
subsystems and thus most in need of synchronized lookups.

While the code *should* work for domains relying on shadow paging, it has not
been tested, hence we do not enable this at the moment.

Finally, the locking discipline in the PoD subsystem has been updated, since
PoD relied on some assumptions about the way the p2m lock is used.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/hap/hap.c        |    6 ++
 xen/arch/x86/mm/mm-locks.h       |   40 ++++++++-----
 xen/arch/x86/mm/p2m.c            |   21 ++++++-
 xen/include/asm-x86/p2m.h        |   47 ++++++++++------
 xen/arch/x86/mm/mem_sharing.c    |    2 -
 xen/arch/x86/mm/mm-locks.h       |    4 +-
 xen/arch/x86/mm/p2m-ept.c        |   33 +----------
 xen/arch/x86/mm/p2m-pod.c        |   14 +++-
 xen/arch/x86/mm/p2m-pt.c         |   45 ++------------
 xen/arch/x86/mm/p2m.c            |   64 +++++++++++----------
 xen/arch/x86/mm/mm-locks.h       |   10 +++
 xen/arch/x86/mm/p2m-pod.c        |  112 +++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m-pt.c         |    1 +
 xen/arch/x86/mm/p2m.c            |    8 ++-
 xen/include/asm-x86/p2m.h        |   27 ++------
 xen/arch/x86/hvm/emulate.c       |    2 +-
 xen/arch/x86/hvm/hvm.c           |   25 +++++--
 xen/arch/x86/mm.c                |   10 +-
 xen/arch/x86/mm/guest_walk.c     |    2 +-
 xen/arch/x86/mm/hap/guest_walk.c |    6 +-
 xen/arch/x86/mm/mem_access.c     |   10 +++
 xen/arch/x86/mm/mem_event.c      |    5 +
 xen/arch/x86/mm/p2m.c            |   52 ++++++++++--------
 xen/common/grant_table.c         |    2 +-
 xen/common/memory.c              |    2 +-
 xen/include/asm-x86/mem_access.h |    1 +
 xen/include/asm-x86/mem_event.h  |    3 +
 xen/include/asm-x86/p2m.h        |    6 +-
 xen/arch/x86/mm/p2m.c            |    4 +-
 29 files changed, 312 insertions(+), 252 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgCT-0001zq-TN; Wed, 01 Feb 2012 19:50:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCS-0001w1-52
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328125829!12163139!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjAzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3444 invoked from network); 1 Feb 2012 19:50:29 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-13.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:50:29 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EA0AE4B0097;
	Wed,  1 Feb 2012 11:50:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tn+TFMTQvyha3/1pwTJFNsN7c76b++X8V7xEO6b0G/2x
	4O6J7Ov6XOfCKnfgVFmt0yLByJKClBYTvkI6CNFusjSFa5fI4rRO/b43MQoWNCAQ
	qDLIgrSURme0C/YCKqJZFmrH3IK8wzuIrefr51+tgSRySFwdl7H1hSVBljRke8E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=julWjPP/XxIFy/ZctTVwQhuv8qg=; b=hQPD10h+B5I
	GKfyzEzo+ctA7qOumYF5dzdSeziIc2D6P4FAdhIcSrH9Li1yoAdoIt5wrJUlG2tx
	OMKWOHCoia0euBS7Ov3KPDEhSxcoJzcKKV85u5aJzPiMMhfxhlYlv+jBEhV99Kk2
	2E3ULWeT4S33fEvyh8+acIH8U/sgHb68=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id AE1804B0084; 
	Wed,  1 Feb 2012 11:50:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 223512f9fb5b9204a1b3d0d4a67050858d7d6dd0
Message-Id: <223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:05 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Make p2m lookups fully synchronized wrt
	modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c  |   6 +++++
 xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
 xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
 xen/include/asm-x86/p2m.h  |  47 ++++++++++++++++++++++++++++-----------------
 4 files changed, 79 insertions(+), 35 deletions(-)


We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.

The lock is always taken recursively, as there are many paths that
do get_gfn, and later, another attempt at grabbing the p2m_lock

The lock is not taken for shadow lookups, as the testing needed to rule out the
possibility of locking inversions and deadlock has not yet been carried out for
shadow-paging. This is tolerable as long as shadows do not gain support for
paging or sharing.

HAP (EPT) lookups and all modifications do take the lock.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -786,7 +786,12 @@ hap_paging_get_mode(struct vcpu *v)
 static void hap_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
+    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
+    p2m_type_t t;
 
+    /* We hold onto the cr3 as it may be modified later, and
+     * we need to respect lock ordering */
+    (void)get_gfn(d, cr3_gfn, &t);
     paging_lock(d);
 
     v->arch.paging.mode = hap_paging_get_mode(v);
@@ -803,6 +808,7 @@ static void hap_update_paging_modes(stru
     hap_update_cr3(v, 0);
 
     paging_unlock(d);
+    put_gfn(d, cr3_gfn);
 }
 
 #if CONFIG_PAGING_LEVELS == 3
diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
+declare_mm_lock(nestedp2m)
+#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
+#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
+
+/* P2M lock (per-p2m-table)
+ * 
+ * This protects all queries and updates to the p2m table. 
+ *
+ * A note about ordering:
+ *   The order established here is enforced on all mutations of a p2m.
+ *   For lookups, the order established here is enforced only for hap
+ *   domains (1. shadow domains present a few nasty inversions; 
+ *            2. shadow domains do not support paging and sharing, 
+ *               the main sources of dynamic p2m mutations)
+ * 
+ * The lock is recursive as it is common for a code path to look up a gfn
+ * and later mutate it.
+ */
+
+declare_mm_lock(p2m)
+#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+
 /* Sharing per page lock
  *
  * This is an external lock, not represented by an mm_lock_t. The memory
@@ -167,21 +192,6 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
-declare_mm_lock(nestedp2m)
-#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
-#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
-
-/* P2M lock (per-p2m-table)
- * 
- * This protects all updates to the p2m table.  Updates are expected to
- * be safe against concurrent reads, which do *not* require the lock. */
-
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -144,9 +144,9 @@ void p2m_change_entry_type_global(struct
     p2m_unlock(p2m);
 }
 
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order)
+                    unsigned int *page_order, bool_t locked)
 {
     mfn_t mfn;
 
@@ -158,6 +158,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
         return _mfn(gfn);
     }
 
+    /* For now only perform locking on hap domains */
+    if ( locked && (hap_enabled(p2m->domain)) )
+        /* Grab the lock here, don't release until put_gfn */
+        p2m_lock(p2m);
+
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
@@ -182,6 +187,18 @@ mfn_t get_gfn_type_access(struct p2m_dom
     return mfn;
 }
 
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
+{
+    if ( !p2m || !paging_mode_translate(p2m->domain) 
+              || !hap_enabled(p2m->domain) )
+        /* Nothing to do in this case */
+        return;
+
+    ASSERT(p2m_locked_by_me(p2m));
+
+    p2m_unlock(p2m);
+}
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 9a55109e4d7e -r 223512f9fb5b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -309,9 +309,14 @@ struct p2m_domain *p2m_get_p2m(struct vc
 
 #define p2m_get_pagetable(p2m)  ((p2m)->phys_table)
 
-/**** p2m query accessors. After calling any of the variants below, you
- * need to call put_gfn(domain, gfn). If you don't, you'll lock the
- * hypervisor. ****/
+/**** p2m query accessors. They lock p2m_lock, and thus serialize
+ * lookups wrt modifications. They _do not_ release the lock on exit.
+ * After calling any of the variants below, caller needs to use
+ * put_gfn. ****/
+
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+                    unsigned int *page_order, bool_t locked);
 
 /* Read a particular P2M table, mapping pages as we go.  Most callers
  * should _not_ call this directly; use the other get_gfn* functions
@@ -320,9 +325,8 @@ struct p2m_domain *p2m_get_p2m(struct vc
  * If the lookup succeeds, the return value is != INVALID_MFN and 
  * *page_order is filled in with the order of the superpage (if any) that
  * the entry was found in.  */
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
-                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order);
+#define get_gfn_type_access(p, g, t, a, q, o)   \
+        __get_gfn_type_access((p), (g), (t), (a), (q), (o), 1)
 
 /* General conversion function from gfn to mfn */
 static inline mfn_t get_gfn_type(struct domain *d,
@@ -353,21 +357,28 @@ static inline unsigned long get_gfn_unty
     return INVALID_MFN;
 }
 
-/* This is a noop for now. */
-static inline void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
-{
-}
+/* Will release the p2m_lock for this gfn entry. */
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
 #define put_gfn(d, gfn) __put_gfn(p2m_get_hostp2m((d)), (gfn))
 
-/* These are identical for now. The intent is to have the caller not worry 
- * about put_gfn. To only be used in printk's, crash situations, or to 
- * peek at a type. You're not holding the p2m entry exclsively after calling
- * this. */
-#define get_gfn_unlocked(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
-#define get_gfn_query_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_guest_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_guest)
-#define get_gfn_unshare_unlocked(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
+/* The intent of the "unlocked" accessor is to have the caller not worry about
+ * put_gfn. They apply to very specific situations: debug printk's, dumps 
+ * during a domain crash, or to peek at a p2m entry/type. Caller is not 
+ * holding the p2m entry exclusively during or after calling this. 
+ *
+ * Note that an unlocked accessor only makes sense for a "query" lookup.
+ * Any other type of query can cause a change in the p2m and may need to
+ * perform locking.
+ */
+static inline mfn_t get_gfn_query_unlocked(struct domain *d, 
+                                           unsigned long gfn, 
+                                           p2m_type_t *t)
+{
+    p2m_access_t a;
+    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 
+                                    p2m_query, NULL, 0);
+}
 
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgCT-0001zq-TN; Wed, 01 Feb 2012 19:50:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCS-0001w1-52
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328125829!12163139!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjAzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3444 invoked from network); 1 Feb 2012 19:50:29 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-13.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:50:29 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EA0AE4B0097;
	Wed,  1 Feb 2012 11:50:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tn+TFMTQvyha3/1pwTJFNsN7c76b++X8V7xEO6b0G/2x
	4O6J7Ov6XOfCKnfgVFmt0yLByJKClBYTvkI6CNFusjSFa5fI4rRO/b43MQoWNCAQ
	qDLIgrSURme0C/YCKqJZFmrH3IK8wzuIrefr51+tgSRySFwdl7H1hSVBljRke8E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=julWjPP/XxIFy/ZctTVwQhuv8qg=; b=hQPD10h+B5I
	GKfyzEzo+ctA7qOumYF5dzdSeziIc2D6P4FAdhIcSrH9Li1yoAdoIt5wrJUlG2tx
	OMKWOHCoia0euBS7Ov3KPDEhSxcoJzcKKV85u5aJzPiMMhfxhlYlv+jBEhV99Kk2
	2E3ULWeT4S33fEvyh8+acIH8U/sgHb68=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id AE1804B0084; 
	Wed,  1 Feb 2012 11:50:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 223512f9fb5b9204a1b3d0d4a67050858d7d6dd0
Message-Id: <223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:05 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Make p2m lookups fully synchronized wrt
	modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c  |   6 +++++
 xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
 xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
 xen/include/asm-x86/p2m.h  |  47 ++++++++++++++++++++++++++++-----------------
 4 files changed, 79 insertions(+), 35 deletions(-)


We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.

The lock is always taken recursively, as there are many paths that
do get_gfn, and later, another attempt at grabbing the p2m_lock

The lock is not taken for shadow lookups, as the testing needed to rule out the
possibility of locking inversions and deadlock has not yet been carried out for
shadow-paging. This is tolerable as long as shadows do not gain support for
paging or sharing.

HAP (EPT) lookups and all modifications do take the lock.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -786,7 +786,12 @@ hap_paging_get_mode(struct vcpu *v)
 static void hap_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
+    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
+    p2m_type_t t;
 
+    /* We hold onto the cr3 as it may be modified later, and
+     * we need to respect lock ordering */
+    (void)get_gfn(d, cr3_gfn, &t);
     paging_lock(d);
 
     v->arch.paging.mode = hap_paging_get_mode(v);
@@ -803,6 +808,7 @@ static void hap_update_paging_modes(stru
     hap_update_cr3(v, 0);
 
     paging_unlock(d);
+    put_gfn(d, cr3_gfn);
 }
 
 #if CONFIG_PAGING_LEVELS == 3
diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
+declare_mm_lock(nestedp2m)
+#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
+#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
+
+/* P2M lock (per-p2m-table)
+ * 
+ * This protects all queries and updates to the p2m table. 
+ *
+ * A note about ordering:
+ *   The order established here is enforced on all mutations of a p2m.
+ *   For lookups, the order established here is enforced only for hap
+ *   domains (1. shadow domains present a few nasty inversions; 
+ *            2. shadow domains do not support paging and sharing, 
+ *               the main sources of dynamic p2m mutations)
+ * 
+ * The lock is recursive as it is common for a code path to look up a gfn
+ * and later mutate it.
+ */
+
+declare_mm_lock(p2m)
+#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+
 /* Sharing per page lock
  *
  * This is an external lock, not represented by an mm_lock_t. The memory
@@ -167,21 +192,6 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
-declare_mm_lock(nestedp2m)
-#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
-#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
-
-/* P2M lock (per-p2m-table)
- * 
- * This protects all updates to the p2m table.  Updates are expected to
- * be safe against concurrent reads, which do *not* require the lock. */
-
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -144,9 +144,9 @@ void p2m_change_entry_type_global(struct
     p2m_unlock(p2m);
 }
 
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order)
+                    unsigned int *page_order, bool_t locked)
 {
     mfn_t mfn;
 
@@ -158,6 +158,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
         return _mfn(gfn);
     }
 
+    /* For now only perform locking on hap domains */
+    if ( locked && (hap_enabled(p2m->domain)) )
+        /* Grab the lock here, don't release until put_gfn */
+        p2m_lock(p2m);
+
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
@@ -182,6 +187,18 @@ mfn_t get_gfn_type_access(struct p2m_dom
     return mfn;
 }
 
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
+{
+    if ( !p2m || !paging_mode_translate(p2m->domain) 
+              || !hap_enabled(p2m->domain) )
+        /* Nothing to do in this case */
+        return;
+
+    ASSERT(p2m_locked_by_me(p2m));
+
+    p2m_unlock(p2m);
+}
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 9a55109e4d7e -r 223512f9fb5b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -309,9 +309,14 @@ struct p2m_domain *p2m_get_p2m(struct vc
 
 #define p2m_get_pagetable(p2m)  ((p2m)->phys_table)
 
-/**** p2m query accessors. After calling any of the variants below, you
- * need to call put_gfn(domain, gfn). If you don't, you'll lock the
- * hypervisor. ****/
+/**** p2m query accessors. They lock p2m_lock, and thus serialize
+ * lookups wrt modifications. They _do not_ release the lock on exit.
+ * After calling any of the variants below, caller needs to use
+ * put_gfn. ****/
+
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+                    unsigned int *page_order, bool_t locked);
 
 /* Read a particular P2M table, mapping pages as we go.  Most callers
  * should _not_ call this directly; use the other get_gfn* functions
@@ -320,9 +325,8 @@ struct p2m_domain *p2m_get_p2m(struct vc
  * If the lookup succeeds, the return value is != INVALID_MFN and 
  * *page_order is filled in with the order of the superpage (if any) that
  * the entry was found in.  */
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
-                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order);
+#define get_gfn_type_access(p, g, t, a, q, o)   \
+        __get_gfn_type_access((p), (g), (t), (a), (q), (o), 1)
 
 /* General conversion function from gfn to mfn */
 static inline mfn_t get_gfn_type(struct domain *d,
@@ -353,21 +357,28 @@ static inline unsigned long get_gfn_unty
     return INVALID_MFN;
 }
 
-/* This is a noop for now. */
-static inline void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
-{
-}
+/* Will release the p2m_lock for this gfn entry. */
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
 #define put_gfn(d, gfn) __put_gfn(p2m_get_hostp2m((d)), (gfn))
 
-/* These are identical for now. The intent is to have the caller not worry 
- * about put_gfn. To only be used in printk's, crash situations, or to 
- * peek at a type. You're not holding the p2m entry exclsively after calling
- * this. */
-#define get_gfn_unlocked(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
-#define get_gfn_query_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_guest_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_guest)
-#define get_gfn_unshare_unlocked(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
+/* The intent of the "unlocked" accessor is to have the caller not worry about
+ * put_gfn. They apply to very specific situations: debug printk's, dumps 
+ * during a domain crash, or to peek at a p2m entry/type. Caller is not 
+ * holding the p2m entry exclusively during or after calling this. 
+ *
+ * Note that an unlocked accessor only makes sense for a "query" lookup.
+ * Any other type of query can cause a change in the p2m and may need to
+ * perform locking.
+ */
+static inline mfn_t get_gfn_query_unlocked(struct domain *d, 
+                                           unsigned long gfn, 
+                                           p2m_type_t *t)
+{
+    p2m_access_t a;
+    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 
+                                    p2m_query, NULL, 0);
+}
 
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgCW-00021V-Ge; Wed, 01 Feb 2012 19:50:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCV-0001xU-9T
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328125832!13093754!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc1NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32674 invoked from network); 1 Feb 2012 19:50:32 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:50:32 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EFCE44B0097;
	Wed,  1 Feb 2012 11:50:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YLxNhN2zuLp4cu+5RaZ4O7FbmtZTYm2CtasydT9sHdcd
	SMO+wOmSBxxPW4V/RIUcnJ24AMQ8vEWqg+2u9GThKv/5sBapSTrL8FXrU602yG2M
	/sZ0s7q7eYPoKiPVY1PSv/kXUhLeMIu2Q/KLveOH7SXDktCnvaPBYDJVyp55W34=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=FjG7DXoBbX+i3BMLbl9pLnmkn/A=; b=Usuu32sF0aX
	74WlRloKXTE+OjbQ6Yghc9ureD9gkNm8sUdTN9gyCDxgbk0WQ0JEmB37HPHDO8zz
	DXRFZD4ue1GLNwShL03pMM/EfMVnWuDK20lERQIo+7JPYkiQmvnGDi2sS+Jfx5km
	ov8kknwMFrBgDpaWhGeYh2713Jy75G+o=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id CF0284B0084; 
	Wed,  1 Feb 2012 11:50:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 211872232129d7c6f4d0fff121da6f4c3b433e56
Message-Id: <211872232129d7c6f4d0.1328126168@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Re-order calls to put_gfn() around wait
 queu invocations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c       |   2 +-
 xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
 xen/arch/x86/mm.c                |  10 +++---
 xen/arch/x86/mm/guest_walk.c     |   2 +-
 xen/arch/x86/mm/hap/guest_walk.c |   6 +---
 xen/arch/x86/mm/mem_access.c     |  10 +++++++
 xen/arch/x86/mm/mem_event.c      |   5 +++
 xen/arch/x86/mm/p2m.c            |  52 ++++++++++++++++++++++-----------------
 xen/common/grant_table.c         |   2 +-
 xen/common/memory.c              |   2 +-
 xen/include/asm-x86/mem_access.h |   1 +
 xen/include/asm-x86/mem_event.h  |   3 ++
 xen/include/asm-x86/p2m.h        |   6 +++-
 13 files changed, 80 insertions(+), 46 deletions(-)


Since we use wait queues to handle potential ring congestion cases,
code paths that try to generate a mem event while holding a gfn lock
would go to sleep in non-preemptible mode.

Most such code paths can be fixed by simply postponing event generation until
locks are released.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,8 +67,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(curr->domain, ram_gfn); 
         p2m_mem_paging_populate(curr->domain, ram_gfn);
-        put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -64,6 +64,7 @@
 #include <public/version.h>
 #include <public/memory.h>
 #include <asm/mem_event.h>
+#include <asm/mem_access.h>
 #include <public/mem_event.h>
 
 bool_t __read_mostly hvm_enabled;
@@ -363,8 +364,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gmfn);
         p2m_mem_paging_populate(d, gmfn);
-        put_gfn(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
@@ -1195,7 +1196,8 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc, fall_through = 0;
+    int rc, fall_through = 0, paged = 0;
+    mem_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1270,7 +1272,7 @@ int hvm_hap_nested_page_fault(unsigned l
         if ( violation )
         {
             if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
-                                        access_w, access_x) )
+                                        access_w, access_x, &req_ptr) )
             {
                 fall_through = 1;
             } else {
@@ -1297,7 +1299,7 @@ int hvm_hap_nested_page_fault(unsigned l
 #ifdef __x86_64__
     /* Check if the page has been paged out */
     if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
-        p2m_mem_paging_populate(v->domain, gfn);
+        paged = 1;
 
     /* Mem sharing: unshare the page and try again */
     if ( access_w && (p2mt == p2m_ram_shared) )
@@ -1343,6 +1345,13 @@ int hvm_hap_nested_page_fault(unsigned l
 
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
+    if ( paged )
+        p2m_mem_paging_populate(v->domain, gfn);
+    if ( req_ptr )
+    {
+        mem_access_send_req(v->domain, req_ptr);
+        xfree(req_ptr);
+    }
     return rc;
 }
 
@@ -1849,8 +1858,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gfn);
         p2m_mem_paging_populate(d, gfn);
-        put_gfn(d, gfn);
         return NULL;
     }
 
@@ -2325,8 +2334,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(curr->domain, gfn);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
@@ -3923,8 +3932,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
             }
@@ -4040,8 +4049,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
             }
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3536,8 +3536,8 @@ int do_mmu_update(
 
             if ( p2m_is_paged(p2mt) )
             {
+                put_gfn(pt_owner, gmfn);
                 p2m_mem_paging_populate(pg_owner, gmfn);
-                put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
@@ -3568,8 +3568,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
+                        put_gfn(pg_owner, l1egfn);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3617,8 +3617,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l2e_p2mt) )
                     {
+                        put_gfn(pg_owner, l2egfn);
                         p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3652,8 +3652,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l3e_p2mt) )
                     {
+                        put_gfn(pg_owner, l3egfn);
                         p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3687,8 +3687,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l4e_p2mt) )
                     {
+                        put_gfn(pg_owner, l4egfn);
                         p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
                     }
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,8 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
+        __put_gfn(p2m, gfn_x(gfn));
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-        __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,10 +64,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
-
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
+        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
@@ -101,10 +100,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -47,6 +47,16 @@ int mem_access_domctl(struct domain *d, 
     return rc;
 }
 
+int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+{
+    int rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
+        return rc;
+
+    mem_event_put_request(d, &d->mem_event->access, req);
+
+    return 0;
+} 
 
 /*
  * Local variables:
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -423,6 +423,11 @@ static int mem_event_wait_slot(struct me
     return rc;
 }
 
+bool_t mem_event_check_ring(struct mem_event_domain *med)
+{
+    return (med->ring_page != NULL);
+}
+
 /*
  * Determines whether or not the current vCPU belongs to the target domain,
  * and calls the appropriate wait function.  If it is a guest vCPU, then we
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1152,17 +1152,18 @@ void p2m_mem_paging_resume(struct domain
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x)
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
-    
+    mem_event_request_t *req;
+
     /* First, handle rx2rw conversion automatically */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
@@ -1181,7 +1182,7 @@ bool_t p2m_mem_access_check(unsigned lon
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
+    if ( !mem_event_check_ring(&d->mem_event->access) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
@@ -1205,29 +1206,34 @@ bool_t p2m_mem_access_check(unsigned lon
         }
     }
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_ACCESS;
-    req.reason = MEM_EVENT_REASON_VIOLATION;
+    *req_ptr = NULL;
+    req = xmalloc(mem_event_request_t);
+    if ( req )
+    {
+        *req_ptr = req;
+        memset(req, 0, sizeof(req));
+        req->type = MEM_EVENT_TYPE_ACCESS;
+        req->reason = MEM_EVENT_REASON_VIOLATION;
+
+        /* Pause the current VCPU */
+        if ( p2ma != p2m_access_n2rwx )
+            req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+
+        /* Send request to mem event */
+        req->gfn = gfn;
+        req->offset = gpa & ((1 << PAGE_SHIFT) - 1);
+        req->gla_valid = gla_valid;
+        req->gla = gla;
+        req->access_r = access_r;
+        req->access_w = access_w;
+        req->access_x = access_x;
+    
+        req->vcpu_id = v->vcpu_id;
+    }
 
     /* Pause the current VCPU */
     if ( p2ma != p2m_access_n2rwx )
-    {
         vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    } 
-
-    /* Send request to mem event */
-    req.gfn = gfn;
-    req.offset = gpa & ((1 << PAGE_SHIFT) - 1);
-    req.gla_valid = gla_valid;
-    req.gla = gla;
-    req.access_r = access_r;
-    req.access_w = access_w;
-    req.access_x = access_x;
-    
-    req.vcpu_id = v->vcpu_id;
-
-    mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU may be paused, return whether we promoted automatically */
     return (p2ma == p2m_access_n2rwx);
diff -r 56ceab0118cb -r 211872232129 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -164,8 +164,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(rd, gfn);
             p2m_mem_paging_populate(rd, gfn);
-            put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
     } else {
diff -r 56ceab0118cb -r 211872232129 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -166,8 +166,8 @@ int guest_remove_page(struct domain *d, 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
+        put_gfn(d, gmfn);
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
-        put_gfn(d, gmfn);
         return 1;
     }
 #else
diff -r 56ceab0118cb -r 211872232129 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -23,6 +23,7 @@
 
 int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                       XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
 /*
diff -r 56ceab0118cb -r 211872232129 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,6 +24,9 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
+/* Returns whether a ring has been set up */
+bool_t mem_event_check_ring(struct mem_event_domain *med);
+
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
  * available space. For success or -EBUSY, the vCPU may be left blocked
  * temporarily to ensure that the ring does not lose future events.  In
diff -r 56ceab0118cb -r 211872232129 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -587,7 +587,8 @@ static inline void p2m_mem_paging_popula
  * the rw2rx conversion. Boolean return value indicates if access rights have 
  * been promoted with no underlying vcpu pause. */
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x);
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
 
@@ -604,7 +605,8 @@ int p2m_get_mem_access(struct domain *d,
 #else
 static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
-                                        bool_t access_w, bool_t access_x)
+                                        bool_t access_w, bool_t access_x,
+                                        mem_event_request_t **req_ptr);
 { return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgCW-00021V-Ge; Wed, 01 Feb 2012 19:50:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCV-0001xU-9T
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328125832!13093754!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc1NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32674 invoked from network); 1 Feb 2012 19:50:32 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:50:32 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EFCE44B0097;
	Wed,  1 Feb 2012 11:50:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YLxNhN2zuLp4cu+5RaZ4O7FbmtZTYm2CtasydT9sHdcd
	SMO+wOmSBxxPW4V/RIUcnJ24AMQ8vEWqg+2u9GThKv/5sBapSTrL8FXrU602yG2M
	/sZ0s7q7eYPoKiPVY1PSv/kXUhLeMIu2Q/KLveOH7SXDktCnvaPBYDJVyp55W34=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=FjG7DXoBbX+i3BMLbl9pLnmkn/A=; b=Usuu32sF0aX
	74WlRloKXTE+OjbQ6Yghc9ureD9gkNm8sUdTN9gyCDxgbk0WQ0JEmB37HPHDO8zz
	DXRFZD4ue1GLNwShL03pMM/EfMVnWuDK20lERQIo+7JPYkiQmvnGDi2sS+Jfx5km
	ov8kknwMFrBgDpaWhGeYh2713Jy75G+o=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id CF0284B0084; 
	Wed,  1 Feb 2012 11:50:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 211872232129d7c6f4d0fff121da6f4c3b433e56
Message-Id: <211872232129d7c6f4d0.1328126168@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Re-order calls to put_gfn() around wait
 queu invocations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c       |   2 +-
 xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
 xen/arch/x86/mm.c                |  10 +++---
 xen/arch/x86/mm/guest_walk.c     |   2 +-
 xen/arch/x86/mm/hap/guest_walk.c |   6 +---
 xen/arch/x86/mm/mem_access.c     |  10 +++++++
 xen/arch/x86/mm/mem_event.c      |   5 +++
 xen/arch/x86/mm/p2m.c            |  52 ++++++++++++++++++++++-----------------
 xen/common/grant_table.c         |   2 +-
 xen/common/memory.c              |   2 +-
 xen/include/asm-x86/mem_access.h |   1 +
 xen/include/asm-x86/mem_event.h  |   3 ++
 xen/include/asm-x86/p2m.h        |   6 +++-
 13 files changed, 80 insertions(+), 46 deletions(-)


Since we use wait queues to handle potential ring congestion cases,
code paths that try to generate a mem event while holding a gfn lock
would go to sleep in non-preemptible mode.

Most such code paths can be fixed by simply postponing event generation until
locks are released.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,8 +67,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(curr->domain, ram_gfn); 
         p2m_mem_paging_populate(curr->domain, ram_gfn);
-        put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -64,6 +64,7 @@
 #include <public/version.h>
 #include <public/memory.h>
 #include <asm/mem_event.h>
+#include <asm/mem_access.h>
 #include <public/mem_event.h>
 
 bool_t __read_mostly hvm_enabled;
@@ -363,8 +364,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gmfn);
         p2m_mem_paging_populate(d, gmfn);
-        put_gfn(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
@@ -1195,7 +1196,8 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc, fall_through = 0;
+    int rc, fall_through = 0, paged = 0;
+    mem_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1270,7 +1272,7 @@ int hvm_hap_nested_page_fault(unsigned l
         if ( violation )
         {
             if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
-                                        access_w, access_x) )
+                                        access_w, access_x, &req_ptr) )
             {
                 fall_through = 1;
             } else {
@@ -1297,7 +1299,7 @@ int hvm_hap_nested_page_fault(unsigned l
 #ifdef __x86_64__
     /* Check if the page has been paged out */
     if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
-        p2m_mem_paging_populate(v->domain, gfn);
+        paged = 1;
 
     /* Mem sharing: unshare the page and try again */
     if ( access_w && (p2mt == p2m_ram_shared) )
@@ -1343,6 +1345,13 @@ int hvm_hap_nested_page_fault(unsigned l
 
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
+    if ( paged )
+        p2m_mem_paging_populate(v->domain, gfn);
+    if ( req_ptr )
+    {
+        mem_access_send_req(v->domain, req_ptr);
+        xfree(req_ptr);
+    }
     return rc;
 }
 
@@ -1849,8 +1858,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gfn);
         p2m_mem_paging_populate(d, gfn);
-        put_gfn(d, gfn);
         return NULL;
     }
 
@@ -2325,8 +2334,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(curr->domain, gfn);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
@@ -3923,8 +3932,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
             }
@@ -4040,8 +4049,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
             }
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3536,8 +3536,8 @@ int do_mmu_update(
 
             if ( p2m_is_paged(p2mt) )
             {
+                put_gfn(pt_owner, gmfn);
                 p2m_mem_paging_populate(pg_owner, gmfn);
-                put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
@@ -3568,8 +3568,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
+                        put_gfn(pg_owner, l1egfn);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3617,8 +3617,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l2e_p2mt) )
                     {
+                        put_gfn(pg_owner, l2egfn);
                         p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3652,8 +3652,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l3e_p2mt) )
                     {
+                        put_gfn(pg_owner, l3egfn);
                         p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3687,8 +3687,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l4e_p2mt) )
                     {
+                        put_gfn(pg_owner, l4egfn);
                         p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
                     }
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,8 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
+        __put_gfn(p2m, gfn_x(gfn));
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-        __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,10 +64,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
-
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
+        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
@@ -101,10 +100,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -47,6 +47,16 @@ int mem_access_domctl(struct domain *d, 
     return rc;
 }
 
+int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+{
+    int rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
+        return rc;
+
+    mem_event_put_request(d, &d->mem_event->access, req);
+
+    return 0;
+} 
 
 /*
  * Local variables:
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -423,6 +423,11 @@ static int mem_event_wait_slot(struct me
     return rc;
 }
 
+bool_t mem_event_check_ring(struct mem_event_domain *med)
+{
+    return (med->ring_page != NULL);
+}
+
 /*
  * Determines whether or not the current vCPU belongs to the target domain,
  * and calls the appropriate wait function.  If it is a guest vCPU, then we
diff -r 56ceab0118cb -r 211872232129 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1152,17 +1152,18 @@ void p2m_mem_paging_resume(struct domain
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x)
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
-    
+    mem_event_request_t *req;
+
     /* First, handle rx2rw conversion automatically */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
@@ -1181,7 +1182,7 @@ bool_t p2m_mem_access_check(unsigned lon
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
+    if ( !mem_event_check_ring(&d->mem_event->access) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
@@ -1205,29 +1206,34 @@ bool_t p2m_mem_access_check(unsigned lon
         }
     }
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_ACCESS;
-    req.reason = MEM_EVENT_REASON_VIOLATION;
+    *req_ptr = NULL;
+    req = xmalloc(mem_event_request_t);
+    if ( req )
+    {
+        *req_ptr = req;
+        memset(req, 0, sizeof(req));
+        req->type = MEM_EVENT_TYPE_ACCESS;
+        req->reason = MEM_EVENT_REASON_VIOLATION;
+
+        /* Pause the current VCPU */
+        if ( p2ma != p2m_access_n2rwx )
+            req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+
+        /* Send request to mem event */
+        req->gfn = gfn;
+        req->offset = gpa & ((1 << PAGE_SHIFT) - 1);
+        req->gla_valid = gla_valid;
+        req->gla = gla;
+        req->access_r = access_r;
+        req->access_w = access_w;
+        req->access_x = access_x;
+    
+        req->vcpu_id = v->vcpu_id;
+    }
 
     /* Pause the current VCPU */
     if ( p2ma != p2m_access_n2rwx )
-    {
         vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    } 
-
-    /* Send request to mem event */
-    req.gfn = gfn;
-    req.offset = gpa & ((1 << PAGE_SHIFT) - 1);
-    req.gla_valid = gla_valid;
-    req.gla = gla;
-    req.access_r = access_r;
-    req.access_w = access_w;
-    req.access_x = access_x;
-    
-    req.vcpu_id = v->vcpu_id;
-
-    mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU may be paused, return whether we promoted automatically */
     return (p2ma == p2m_access_n2rwx);
diff -r 56ceab0118cb -r 211872232129 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -164,8 +164,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(rd, gfn);
             p2m_mem_paging_populate(rd, gfn);
-            put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
     } else {
diff -r 56ceab0118cb -r 211872232129 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -166,8 +166,8 @@ int guest_remove_page(struct domain *d, 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
+        put_gfn(d, gmfn);
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
-        put_gfn(d, gmfn);
         return 1;
     }
 #else
diff -r 56ceab0118cb -r 211872232129 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -23,6 +23,7 @@
 
 int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                       XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
 /*
diff -r 56ceab0118cb -r 211872232129 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,6 +24,9 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
+/* Returns whether a ring has been set up */
+bool_t mem_event_check_ring(struct mem_event_domain *med);
+
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
  * available space. For success or -EBUSY, the vCPU may be left blocked
  * temporarily to ensure that the ring does not lose future events.  In
diff -r 56ceab0118cb -r 211872232129 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -587,7 +587,8 @@ static inline void p2m_mem_paging_popula
  * the rw2rx conversion. Boolean return value indicates if access rights have 
  * been promoted with no underlying vcpu pause. */
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x);
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
 
@@ -604,7 +605,8 @@ int p2m_get_mem_access(struct domain *d,
 #else
 static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
-                                        bool_t access_w, bool_t access_x)
+                                        bool_t access_w, bool_t access_x,
+                                        mem_event_request_t **req_ptr);
 { return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgCX-00022I-VQ; Wed, 01 Feb 2012 19:50:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCW-0001xg-1O
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328125829!13088777!4
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc1NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1453 invoked from network); 1 Feb 2012 19:50:33 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-15.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:50:33 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 961554B008F;
	Wed,  1 Feb 2012 11:50:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mD74z7J9kvSMmCshoN+NBN+tljyvL8IdRNXWBT8H0Qsj
	oVpqcMquqWLsBa65JP+iy9WTny3Pvksd0CGNhsMf5T7MspsWWbpho4gq2BirrWoS
	v9bBJ0ebDev2cBvdRhVtGIM60NW6UpFClM+ztbU9wX/VcdSURw+HfoDs3vpSOUc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=vUBScEjPeOVBm+rOaSrpkRcSwoc=; b=qlExOioXFi1
	FGzW6l1StPiSDUAVyNUEBkXG0jwmZntsaXJ2oTOBZIe9rRDHIgJapRNSKzFQbFsg
	6RLFq59z3RRKj+l+TzRE+uSWDzAJXmeCCp3HaXeth8yU73jfmZMPnBMaw+wtMn/Z
	zVaOLO282clLj4Xgsg+XgNWc3X9ayhyg=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 6CDFD4B0084; 
	Wed,  1 Feb 2012 11:50:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a8ba1fc6e4b3c4229bbfd9268949ad629835ccaf
Message-Id: <a8ba1fc6e4b3c4229bbf.1328126169@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] x86/mm: Revert changeset
	24582:f6c33cfe7333
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


With synchronized p2m lookups this is no longer needed, and we can lock the p2m
up-front.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 211872232129 -r a8ba1fc6e4b3 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -361,6 +361,8 @@ void p2m_teardown(struct p2m_domain *p2m
     if (p2m == NULL)
         return;
 
+    p2m_lock(p2m);
+
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
@@ -374,8 +376,6 @@ void p2m_teardown(struct p2m_domain *p2m
     }
 #endif
 
-    p2m_lock(p2m);
-
     p2m->phys_table = pagetable_null();
 
     while ( (pg = page_list_remove_head(&p2m->pages)) )

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgCX-00022I-VQ; Wed, 01 Feb 2012 19:50:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCW-0001xg-1O
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328125829!13088777!4
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc1NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1453 invoked from network); 1 Feb 2012 19:50:33 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-15.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:50:33 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 961554B008F;
	Wed,  1 Feb 2012 11:50:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mD74z7J9kvSMmCshoN+NBN+tljyvL8IdRNXWBT8H0Qsj
	oVpqcMquqWLsBa65JP+iy9WTny3Pvksd0CGNhsMf5T7MspsWWbpho4gq2BirrWoS
	v9bBJ0ebDev2cBvdRhVtGIM60NW6UpFClM+ztbU9wX/VcdSURw+HfoDs3vpSOUc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=vUBScEjPeOVBm+rOaSrpkRcSwoc=; b=qlExOioXFi1
	FGzW6l1StPiSDUAVyNUEBkXG0jwmZntsaXJ2oTOBZIe9rRDHIgJapRNSKzFQbFsg
	6RLFq59z3RRKj+l+TzRE+uSWDzAJXmeCCp3HaXeth8yU73jfmZMPnBMaw+wtMn/Z
	zVaOLO282clLj4Xgsg+XgNWc3X9ayhyg=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 6CDFD4B0084; 
	Wed,  1 Feb 2012 11:50:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a8ba1fc6e4b3c4229bbfd9268949ad629835ccaf
Message-Id: <a8ba1fc6e4b3c4229bbf.1328126169@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] x86/mm: Revert changeset
	24582:f6c33cfe7333
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


With synchronized p2m lookups this is no longer needed, and we can lock the p2m
up-front.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 211872232129 -r a8ba1fc6e4b3 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -361,6 +361,8 @@ void p2m_teardown(struct p2m_domain *p2m
     if (p2m == NULL)
         return;
 
+    p2m_lock(p2m);
+
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
@@ -374,8 +376,6 @@ void p2m_teardown(struct p2m_domain *p2m
     }
 #endif
 
-    p2m_lock(p2m);
-
     p2m->phys_table = pagetable_null();
 
     while ( (pg = page_list_remove_head(&p2m->pages)) )

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgCY-00022c-B8; Wed, 01 Feb 2012 19:50:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCW-0001xl-8n
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328125830!10035995!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc1NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13375 invoked from network); 1 Feb 2012 19:50:31 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:50:31 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 92FD74B0062;
	Wed,  1 Feb 2012 11:50:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=crNVcpYCw2FFCZ/LOqBB/YePDvTlmXulLwZryKvvrBPY
	P0CWuVj/I7GN1HNP7jwwmH3Lr8GtwTjOnQ2QJfOBr/LXRQjlYuWB6Du4K0dEuULe
	QHPrR9oly7smbjcHz3xOY3fijn46gGyItyNcCXshEMLKhDcAAtYYibT7ubQ2Jjg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EB6Fsr3RGqzQIbOmTSa+QEPYkRc=; b=gEe36LPx+Qh
	8HhrSWJmPut3jLoT8ZaIxyAXmLb82Zp5yUxu//+sN/5DIbsMqaeGDaVX6LeEGkPc
	btrqUeynd+zX44hyyUUT7IJjryKNL5fMJ7pbJSvQVXRWWXQT25W31DfZxl17h81/
	scKtvTz4u8iIVuhCWM4tzuM/JgPFdutY=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 6228C4B0084; 
	Wed,  1 Feb 2012 11:50:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 56ceab0118cba85cdcd3eaa944eff8836b0a4c37
Message-Id: <56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mm-locks.h |   10 ++++
 xen/arch/x86/mm/p2m-pod.c  |  112 ++++++++++++++++++++++++++------------------
 xen/arch/x86/mm/p2m-pt.c   |    1 +
 xen/arch/x86/mm/p2m.c      |    8 ++-
 xen/include/asm-x86/p2m.h  |   27 +++-------
 5 files changed, 93 insertions(+), 65 deletions(-)


The PoD layer has a comples locking discipline. It relies on the
p2m being globally locked, and it also relies on the page alloc
lock to protect some of its data structures. Replace this all by an
explicit pod lock: per p2m, order enforced.

Three consequences:
    - Critical sections in the pod code protected by the page alloc
      lock are now reduced to modifications of the domain page list.
    - When the p2m lock becomes fine-grained, there are no
      assumptions broken in the PoD layer.
    - The locking is easier to understand.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -194,6 +194,16 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
+/* PoD lock (per-p2m-table)
+ * 
+ * Protects private PoD data structs: entry and cache
+ * counts, page lists, sweep parameters. */
+
+declare_mm_lock(pod)
+#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
+#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
+
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -100,7 +100,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
     }
 #endif
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(pod_locked_by_me(p2m));
 
     /*
      * Pages from domain_alloc and returned by the balloon driver aren't
@@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         unmap_domain_page(b);
     }
 
+    /* First, take all pages off the domain list */
     lock_page_alloc(p2m);
-
-    /* First, take all pages off the domain list */
     for(i=0; i < 1 << order ; i++)
     {
         p = page + i;
         page_list_del(p, &d->page_list);
     }
 
+    /* Ensure that the PoD cache has never been emptied.  
+     * This may cause "zombie domains" since the page will never be freed. */
+    BUG_ON( d->arch.relmem != RELMEM_not_started );
+
+    unlock_page_alloc(p2m);
+
     /* Then add the first one to the appropriate populate-on-demand list */
     switch(order)
     {
@@ -138,25 +143,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         BUG();
     }
 
-    /* Ensure that the PoD cache has never been emptied.  
-     * This may cause "zombie domains" since the page will never be freed. */
-    BUG_ON( d->arch.relmem != RELMEM_not_started );
-
-    unlock_page_alloc(p2m);
-
     return 0;
 }
 
 /* Get a page of size order from the populate-on-demand cache.  Will break
  * down 2-meg pages into singleton pages automatically.  Returns null if
- * a superpage is requested and no superpages are available.  Must be called
- * with the d->page_lock held. */
+ * a superpage is requested and no superpages are available. */
 static struct page_info * p2m_pod_cache_get(struct p2m_domain *p2m,
                                             unsigned long order)
 {
     struct page_info *p = NULL;
     int i;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
     {
         return NULL;
@@ -185,7 +185,7 @@ static struct page_info * p2m_pod_cache_
     case PAGE_ORDER_2M:
         BUG_ON( page_list_empty(&p2m->pod.super) );
         p = page_list_remove_head(&p2m->pod.super);
-        p2m->pod.count -= 1 << order; /* Lock: page_alloc */
+        p2m->pod.count -= 1 << order;
         break;
     case PAGE_ORDER_4K:
         BUG_ON( page_list_empty(&p2m->pod.single) );
@@ -197,11 +197,13 @@ static struct page_info * p2m_pod_cache_
     }
 
     /* Put the pages back on the domain page_list */
+    lock_page_alloc(p2m);
     for ( i = 0 ; i < (1 << order); i++ )
     {
         BUG_ON(page_get_owner(p + i) != p2m->domain);
         page_list_add_tail(p + i, &p2m->domain->page_list);
     }
+    unlock_page_alloc(p2m);
 
     return p;
 }
@@ -213,6 +215,8 @@ p2m_pod_set_cache_target(struct p2m_doma
     struct domain *d = p2m->domain;
     int ret = 0;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     /* Increasing the target */
     while ( pod_target > p2m->pod.count )
     {
@@ -250,17 +254,13 @@ p2m_pod_set_cache_target(struct p2m_doma
     }
 
     /* Decreasing the target */
-    /* We hold the p2m lock here, so we don't need to worry about
+    /* We hold the pod lock here, so we don't need to worry about
      * cache disappearing under our feet. */
     while ( pod_target < p2m->pod.count )
     {
         struct page_info * page;
         int order, i;
 
-        /* Grab the lock before checking that pod.super is empty, or the last
-         * entries may disappear before we grab the lock. */
-        lock_page_alloc(p2m);
-
         if ( (p2m->pod.count - pod_target) > SUPERPAGE_PAGES
              && !page_list_empty(&p2m->pod.super) )
             order = PAGE_ORDER_2M;
@@ -271,8 +271,6 @@ p2m_pod_set_cache_target(struct p2m_doma
 
         ASSERT(page != NULL);
 
-        unlock_page_alloc(p2m);
-
         /* Then free them */
         for ( i = 0 ; i < (1 << order) ; i++ )
         {
@@ -348,7 +346,7 @@ p2m_pod_set_mem_target(struct domain *d,
     int ret = 0;
     unsigned long populated;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
 
     /* P == B: Nothing to do. */
     if ( p2m->pod.entry_count == 0 )
@@ -377,7 +375,7 @@ p2m_pod_set_mem_target(struct domain *d,
     ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
 
 out:
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
 
     return ret;
 }
@@ -390,7 +388,7 @@ p2m_pod_empty_cache(struct domain *d)
 
     /* After this barrier no new PoD activities can happen. */
     BUG_ON(!d->is_dying);
-    spin_barrier(&p2m->lock.lock);
+    spin_barrier(&p2m->pod.lock.lock);
 
     lock_page_alloc(p2m);
 
@@ -431,7 +429,7 @@ p2m_pod_offline_or_broken_hit(struct pag
     if ( !(d = page_get_owner(p)) || !(p2m = p2m_get_hostp2m(d)) )
         return 0;
 
-    lock_page_alloc(p2m);
+    pod_lock(p2m);
     bmfn = mfn_x(page_to_mfn(p));
     page_list_for_each_safe(q, tmp, &p2m->pod.super)
     {
@@ -462,12 +460,14 @@ p2m_pod_offline_or_broken_hit(struct pag
         }
     }
 
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 0;
 
 pod_hit:
+    lock_page_alloc(p2m);
     page_list_add_tail(p, &d->arch.relmem_list);
     unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 1;
 }
 
@@ -486,9 +486,9 @@ p2m_pod_offline_or_broken_replace(struct
     if ( unlikely(!p) )
         return;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
     p2m_pod_cache_add(p2m, p, PAGE_ORDER_4K);
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
     return;
 }
 
@@ -511,18 +511,18 @@ p2m_pod_decrease_reservation(struct doma
 
     int steal_for_cache = 0;
     int pod = 0, nonpod = 0, ram = 0;
-    
+
+    gfn_lock(p2m, gpfn, order);
+    pod_lock(p2m);    
 
     /* If we don't have any outstanding PoD entries, let things take their
      * course */
     if ( p2m->pod.entry_count == 0 )
-        goto out;
+        goto out_unlock;
 
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    gfn_lock(p2m, gpfn, order);
-
     if ( unlikely(d->is_dying) )
         goto out_unlock;
 
@@ -554,7 +554,7 @@ p2m_pod_decrease_reservation(struct doma
         /* All PoD: Mark the whole region invalid and tell caller
          * we're done. */
         set_p2m_entry(p2m, gpfn, _mfn(INVALID_MFN), order, p2m_invalid, p2m->default_access);
-        p2m->pod.entry_count-=(1<<order); /* Lock: p2m */
+        p2m->pod.entry_count-=(1<<order);
         BUG_ON(p2m->pod.entry_count < 0);
         ret = 1;
         goto out_entry_check;
@@ -578,7 +578,7 @@ p2m_pod_decrease_reservation(struct doma
         if ( t == p2m_populate_on_demand )
         {
             set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, p2m->default_access);
-            p2m->pod.entry_count--; /* Lock: p2m */
+            p2m->pod.entry_count--;
             BUG_ON(p2m->pod.entry_count < 0);
             pod--;
         }
@@ -615,9 +615,8 @@ out_entry_check:
     }
 
 out_unlock:
+    pod_unlock(p2m);
     gfn_unlock(p2m, gpfn, order);
-
-out:
     return ret;
 }
 
@@ -630,7 +629,8 @@ void p2m_pod_dump_data(struct domain *d)
 
 
 /* Search for all-zero superpages to be reclaimed as superpages for the
- * PoD cache. Must be called w/ p2m lock held, page_alloc lock not held. */
+ * PoD cache. Must be called w/ pod lock held, must lock the superpage
+ * in the p2m */
 static int
 p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn)
 {
@@ -642,6 +642,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     int max_ref = 1;
     struct domain *d = p2m->domain;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( !superpage_aligned(gfn) )
         goto out;
 
@@ -649,6 +651,10 @@ p2m_pod_zero_check_superpage(struct p2m_
     if ( paging_mode_shadow(d) )
         max_ref++;
 
+    /* NOTE: this is why we don't enforce deadlock constraints between p2m 
+     * and pod locks */
+    gfn_lock(p2m, gfn, SUPERPAGE_ORDER);
+
     /* Look up the mfns, checking to make sure they're the same mfn
      * and aligned, and mapping them. */
     for ( i=0; i<SUPERPAGE_PAGES; i++ )
@@ -761,6 +767,7 @@ out_reset:
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);
     
 out:
+    gfn_unlock(p2m, gfn, SUPERPAGE_ORDER);
     return ret;
 }
 
@@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
     limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
 
     /* FIXME: Figure out how to avoid superpages */
+    /* NOTE: Promote to globally locking the p2m. This will get complicated
+     * in a fine-grained scenario. Even if we're to lock each gfn 
+     * individually we must be careful about recursion limits and 
+     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock constraints 
+     * between p2m and pod locks */
+    p2m_lock(p2m);
     for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
     {
         p2m_access_t a;
@@ -940,7 +953,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
         /* Stop if we're past our limit and we have found *something*.
          *
          * NB that this is a zero-sum game; we're increasing our cache size
-         * by re-increasing our 'debt'.  Since we hold the p2m lock,
+         * by re-increasing our 'debt'.  Since we hold the pod lock,
          * (entry_count - count) must remain the same. */
         if ( p2m->pod.count > 0 && i < limit )
             break;
@@ -949,6 +962,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
     if ( j )
         p2m_pod_zero_check(p2m, gfns, j);
 
+    p2m_unlock(p2m);
     p2m->pod.reclaim_single = i ? i - 1 : i;
 
 }
@@ -965,8 +979,9 @@ p2m_pod_demand_populate(struct p2m_domai
     int i;
 
     ASSERT(gfn_locked_by_me(p2m, gfn));
+    pod_lock(p2m);
 
-    /* This check is done with the p2m lock held.  This will make sure that
+    /* This check is done with the pod lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
      * won't start until we're done. */
     if ( unlikely(d->is_dying) )
@@ -977,6 +992,7 @@ p2m_pod_demand_populate(struct p2m_domai
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
     {
+        pod_unlock(p2m);
         gfn_aligned = (gfn >> order) << order;
         /* Note that we are supposed to call set_p2m_entry() 512 times to 
          * split 1GB into 512 2MB pages here. But We only do once here because
@@ -1000,11 +1016,15 @@ p2m_pod_demand_populate(struct p2m_domai
 
         /* If we're low, start a sweep */
         if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
+            /* Note that sweeps scan other ranges in the p2m. In an scenario
+             * in which p2m locks are order-enforced wrt pod lock and p2m 
+             * locks are fine grained, this will result in deadlock panic */
             p2m_pod_emergency_sweep_super(p2m);
 
         if ( page_list_empty(&p2m->pod.single) &&
              ( ( order == PAGE_ORDER_4K )
                || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
+            /* Same comment regarding deadlock applies */
             p2m_pod_emergency_sweep(p2m);
     }
 
@@ -1012,8 +1032,6 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( q == p2m_guest && gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    lock_page_alloc(p2m);
-
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 
@@ -1026,8 +1044,6 @@ p2m_pod_demand_populate(struct p2m_domai
 
     BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
 
-    unlock_page_alloc(p2m);
-
     gfn_aligned = (gfn >> order) << order;
 
     set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw, p2m->default_access);
@@ -1038,7 +1054,7 @@ p2m_pod_demand_populate(struct p2m_domai
         paging_mark_dirty(d, mfn_x(mfn) + i);
     }
     
-    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
+    p2m->pod.entry_count -= (1 << order);
     BUG_ON(p2m->pod.entry_count < 0);
 
     if ( tb_init_done )
@@ -1056,20 +1072,24 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    pod_unlock(p2m);
     return 0;
 out_of_memory:
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 " pod_entries %" PRIi32 "\n",
            __func__, d->tot_pages, p2m->pod.entry_count);
     domain_crash(d);
 out_fail:
+    pod_unlock(p2m);
     return -1;
 remap_and_retry:
     BUG_ON(order != PAGE_ORDER_2M);
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     /* Remap this 2-meg region in singleton chunks */
+    /* NOTE: In a p2m fine-grained lock scenario this might
+     * need promoting the gfn lock from gfn->2M superpage */
     gfn_aligned = (gfn>>order)<<order;
     for(i=0; i<(1<<order); i++)
         set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
@@ -1137,9 +1157,11 @@ guest_physmap_mark_populate_on_demand(st
         rc = -EINVAL;
     else
     {
-        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
+        pod_lock(p2m);
+        p2m->pod.entry_count += 1 << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
+        pod_unlock(p2m);
     }
 
     gfn_unlock(p2m, gfn, order);
diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain 
     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) );
diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
     mm_lock_init(&p2m->lock);
+    mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
     INIT_PAGE_LIST_HEAD(&p2m->pod.super);
@@ -587,8 +588,10 @@ guest_physmap_add_entry(struct domain *d
             rc = -EINVAL;
         else
         {
-            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
+            pod_lock(p2m);
+            p2m->pod.entry_count -= pod_count;
             BUG_ON(p2m->pod.entry_count < 0);
+            pod_unlock(p2m);
         }
     }
 
@@ -1372,6 +1375,7 @@ p2m_flush_table(struct p2m_domain *p2m)
     /* "Host" p2m tables can have shared entries &c that need a bit more 
      * care when discarding them */
     ASSERT(p2m_is_nestedp2m(p2m));
+    /* Nested p2m's do not do pod, hence the asserts (and no pod lock)*/
     ASSERT(page_list_empty(&p2m->pod.super));
     ASSERT(page_list_empty(&p2m->pod.single));
 
@@ -1529,6 +1533,7 @@ void audit_p2m(struct domain *d,
     P2M_PRINTK("p2m audit starts\n");
 
     p2m_lock(p2m);
+    pod_lock(p2m);
 
     if (p2m->audit_p2m)
         pmbad = p2m->audit_p2m(p2m);
@@ -1589,6 +1594,7 @@ void audit_p2m(struct domain *d,
     }
     spin_unlock(&d->page_alloc_lock);
 
+    pod_unlock(p2m);
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
diff -r fb9c06df05f2 -r 56ceab0118cb xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -261,25 +261,12 @@ struct p2m_domain {
     unsigned long max_mapped_pfn;
 
     /* Populate-on-demand variables
-     * NB on locking.  {super,single,count} are
-     * covered by d->page_alloc_lock, since they're almost always used in
-     * conjunction with that functionality.  {entry_count} is covered by
-     * the domain p2m lock, since it's almost always used in conjunction
-     * with changing the p2m tables.
-     *
-     * At this point, both locks are held in two places.  In both,
-     * the order is [p2m,page_alloc]:
-     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
-     *   which grabs page_alloc
-     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
-     *   double-demand-populating of pages, the page_alloc lock to
-     *   protect moving stuff from the PoD cache to the domain page list.
-     *
-     * We enforce this lock ordering through a construct in mm-locks.h.
-     * This demands, however, that we store the previous lock-ordering
-     * level in effect before grabbing the page_alloc lock. The unlock
-     * level is stored in the arch section of the domain struct.
-     */
+     * All variables are protected with the pod lock. We cannot rely on
+     * the p2m lock if it's turned into a fine-grained lock.
+     * We only use the domain page_alloc lock for additions and 
+     * deletions to the domain's page list. Because we use it nested
+     * within the PoD lock, we enforce it's ordering (by remembering
+     * the unlock level in the arch_domain sub struct). */
     struct {
         struct page_list_head super,   /* List of superpages                */
                          single;       /* Non-super lists                   */
@@ -288,6 +275,8 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+        mm_lock_t        lock;         /* Locking of private pod structs,   *
+                                        * not relying on the p2m lock.      */
     } pod;
 };
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:50:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgCY-00022c-B8; Wed, 01 Feb 2012 19:50:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgCW-0001xl-8n
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:50:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328125830!10035995!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc1NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13375 invoked from network); 1 Feb 2012 19:50:31 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 19:50:31 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 92FD74B0062;
	Wed,  1 Feb 2012 11:50:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=crNVcpYCw2FFCZ/LOqBB/YePDvTlmXulLwZryKvvrBPY
	P0CWuVj/I7GN1HNP7jwwmH3Lr8GtwTjOnQ2QJfOBr/LXRQjlYuWB6Du4K0dEuULe
	QHPrR9oly7smbjcHz3xOY3fijn46gGyItyNcCXshEMLKhDcAAtYYibT7ubQ2Jjg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=EB6Fsr3RGqzQIbOmTSa+QEPYkRc=; b=gEe36LPx+Qh
	8HhrSWJmPut3jLoT8ZaIxyAXmLb82Zp5yUxu//+sN/5DIbsMqaeGDaVX6LeEGkPc
	btrqUeynd+zX44hyyUUT7IJjryKNL5fMJ7pbJSvQVXRWWXQT25W31DfZxl17h81/
	scKtvTz4u8iIVuhCWM4tzuM/JgPFdutY=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 6228C4B0084; 
	Wed,  1 Feb 2012 11:50:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 56ceab0118cba85cdcd3eaa944eff8836b0a4c37
Message-Id: <56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mm-locks.h |   10 ++++
 xen/arch/x86/mm/p2m-pod.c  |  112 ++++++++++++++++++++++++++------------------
 xen/arch/x86/mm/p2m-pt.c   |    1 +
 xen/arch/x86/mm/p2m.c      |    8 ++-
 xen/include/asm-x86/p2m.h  |   27 +++-------
 5 files changed, 93 insertions(+), 65 deletions(-)


The PoD layer has a comples locking discipline. It relies on the
p2m being globally locked, and it also relies on the page alloc
lock to protect some of its data structures. Replace this all by an
explicit pod lock: per p2m, order enforced.

Three consequences:
    - Critical sections in the pod code protected by the page alloc
      lock are now reduced to modifications of the domain page list.
    - When the p2m lock becomes fine-grained, there are no
      assumptions broken in the PoD layer.
    - The locking is easier to understand.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -194,6 +194,16 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
+/* PoD lock (per-p2m-table)
+ * 
+ * Protects private PoD data structs: entry and cache
+ * counts, page lists, sweep parameters. */
+
+declare_mm_lock(pod)
+#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
+#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
+
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -100,7 +100,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
     }
 #endif
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(pod_locked_by_me(p2m));
 
     /*
      * Pages from domain_alloc and returned by the balloon driver aren't
@@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         unmap_domain_page(b);
     }
 
+    /* First, take all pages off the domain list */
     lock_page_alloc(p2m);
-
-    /* First, take all pages off the domain list */
     for(i=0; i < 1 << order ; i++)
     {
         p = page + i;
         page_list_del(p, &d->page_list);
     }
 
+    /* Ensure that the PoD cache has never been emptied.  
+     * This may cause "zombie domains" since the page will never be freed. */
+    BUG_ON( d->arch.relmem != RELMEM_not_started );
+
+    unlock_page_alloc(p2m);
+
     /* Then add the first one to the appropriate populate-on-demand list */
     switch(order)
     {
@@ -138,25 +143,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         BUG();
     }
 
-    /* Ensure that the PoD cache has never been emptied.  
-     * This may cause "zombie domains" since the page will never be freed. */
-    BUG_ON( d->arch.relmem != RELMEM_not_started );
-
-    unlock_page_alloc(p2m);
-
     return 0;
 }
 
 /* Get a page of size order from the populate-on-demand cache.  Will break
  * down 2-meg pages into singleton pages automatically.  Returns null if
- * a superpage is requested and no superpages are available.  Must be called
- * with the d->page_lock held. */
+ * a superpage is requested and no superpages are available. */
 static struct page_info * p2m_pod_cache_get(struct p2m_domain *p2m,
                                             unsigned long order)
 {
     struct page_info *p = NULL;
     int i;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
     {
         return NULL;
@@ -185,7 +185,7 @@ static struct page_info * p2m_pod_cache_
     case PAGE_ORDER_2M:
         BUG_ON( page_list_empty(&p2m->pod.super) );
         p = page_list_remove_head(&p2m->pod.super);
-        p2m->pod.count -= 1 << order; /* Lock: page_alloc */
+        p2m->pod.count -= 1 << order;
         break;
     case PAGE_ORDER_4K:
         BUG_ON( page_list_empty(&p2m->pod.single) );
@@ -197,11 +197,13 @@ static struct page_info * p2m_pod_cache_
     }
 
     /* Put the pages back on the domain page_list */
+    lock_page_alloc(p2m);
     for ( i = 0 ; i < (1 << order); i++ )
     {
         BUG_ON(page_get_owner(p + i) != p2m->domain);
         page_list_add_tail(p + i, &p2m->domain->page_list);
     }
+    unlock_page_alloc(p2m);
 
     return p;
 }
@@ -213,6 +215,8 @@ p2m_pod_set_cache_target(struct p2m_doma
     struct domain *d = p2m->domain;
     int ret = 0;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     /* Increasing the target */
     while ( pod_target > p2m->pod.count )
     {
@@ -250,17 +254,13 @@ p2m_pod_set_cache_target(struct p2m_doma
     }
 
     /* Decreasing the target */
-    /* We hold the p2m lock here, so we don't need to worry about
+    /* We hold the pod lock here, so we don't need to worry about
      * cache disappearing under our feet. */
     while ( pod_target < p2m->pod.count )
     {
         struct page_info * page;
         int order, i;
 
-        /* Grab the lock before checking that pod.super is empty, or the last
-         * entries may disappear before we grab the lock. */
-        lock_page_alloc(p2m);
-
         if ( (p2m->pod.count - pod_target) > SUPERPAGE_PAGES
              && !page_list_empty(&p2m->pod.super) )
             order = PAGE_ORDER_2M;
@@ -271,8 +271,6 @@ p2m_pod_set_cache_target(struct p2m_doma
 
         ASSERT(page != NULL);
 
-        unlock_page_alloc(p2m);
-
         /* Then free them */
         for ( i = 0 ; i < (1 << order) ; i++ )
         {
@@ -348,7 +346,7 @@ p2m_pod_set_mem_target(struct domain *d,
     int ret = 0;
     unsigned long populated;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
 
     /* P == B: Nothing to do. */
     if ( p2m->pod.entry_count == 0 )
@@ -377,7 +375,7 @@ p2m_pod_set_mem_target(struct domain *d,
     ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
 
 out:
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
 
     return ret;
 }
@@ -390,7 +388,7 @@ p2m_pod_empty_cache(struct domain *d)
 
     /* After this barrier no new PoD activities can happen. */
     BUG_ON(!d->is_dying);
-    spin_barrier(&p2m->lock.lock);
+    spin_barrier(&p2m->pod.lock.lock);
 
     lock_page_alloc(p2m);
 
@@ -431,7 +429,7 @@ p2m_pod_offline_or_broken_hit(struct pag
     if ( !(d = page_get_owner(p)) || !(p2m = p2m_get_hostp2m(d)) )
         return 0;
 
-    lock_page_alloc(p2m);
+    pod_lock(p2m);
     bmfn = mfn_x(page_to_mfn(p));
     page_list_for_each_safe(q, tmp, &p2m->pod.super)
     {
@@ -462,12 +460,14 @@ p2m_pod_offline_or_broken_hit(struct pag
         }
     }
 
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 0;
 
 pod_hit:
+    lock_page_alloc(p2m);
     page_list_add_tail(p, &d->arch.relmem_list);
     unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 1;
 }
 
@@ -486,9 +486,9 @@ p2m_pod_offline_or_broken_replace(struct
     if ( unlikely(!p) )
         return;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
     p2m_pod_cache_add(p2m, p, PAGE_ORDER_4K);
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
     return;
 }
 
@@ -511,18 +511,18 @@ p2m_pod_decrease_reservation(struct doma
 
     int steal_for_cache = 0;
     int pod = 0, nonpod = 0, ram = 0;
-    
+
+    gfn_lock(p2m, gpfn, order);
+    pod_lock(p2m);    
 
     /* If we don't have any outstanding PoD entries, let things take their
      * course */
     if ( p2m->pod.entry_count == 0 )
-        goto out;
+        goto out_unlock;
 
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    gfn_lock(p2m, gpfn, order);
-
     if ( unlikely(d->is_dying) )
         goto out_unlock;
 
@@ -554,7 +554,7 @@ p2m_pod_decrease_reservation(struct doma
         /* All PoD: Mark the whole region invalid and tell caller
          * we're done. */
         set_p2m_entry(p2m, gpfn, _mfn(INVALID_MFN), order, p2m_invalid, p2m->default_access);
-        p2m->pod.entry_count-=(1<<order); /* Lock: p2m */
+        p2m->pod.entry_count-=(1<<order);
         BUG_ON(p2m->pod.entry_count < 0);
         ret = 1;
         goto out_entry_check;
@@ -578,7 +578,7 @@ p2m_pod_decrease_reservation(struct doma
         if ( t == p2m_populate_on_demand )
         {
             set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, p2m->default_access);
-            p2m->pod.entry_count--; /* Lock: p2m */
+            p2m->pod.entry_count--;
             BUG_ON(p2m->pod.entry_count < 0);
             pod--;
         }
@@ -615,9 +615,8 @@ out_entry_check:
     }
 
 out_unlock:
+    pod_unlock(p2m);
     gfn_unlock(p2m, gpfn, order);
-
-out:
     return ret;
 }
 
@@ -630,7 +629,8 @@ void p2m_pod_dump_data(struct domain *d)
 
 
 /* Search for all-zero superpages to be reclaimed as superpages for the
- * PoD cache. Must be called w/ p2m lock held, page_alloc lock not held. */
+ * PoD cache. Must be called w/ pod lock held, must lock the superpage
+ * in the p2m */
 static int
 p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn)
 {
@@ -642,6 +642,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     int max_ref = 1;
     struct domain *d = p2m->domain;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( !superpage_aligned(gfn) )
         goto out;
 
@@ -649,6 +651,10 @@ p2m_pod_zero_check_superpage(struct p2m_
     if ( paging_mode_shadow(d) )
         max_ref++;
 
+    /* NOTE: this is why we don't enforce deadlock constraints between p2m 
+     * and pod locks */
+    gfn_lock(p2m, gfn, SUPERPAGE_ORDER);
+
     /* Look up the mfns, checking to make sure they're the same mfn
      * and aligned, and mapping them. */
     for ( i=0; i<SUPERPAGE_PAGES; i++ )
@@ -761,6 +767,7 @@ out_reset:
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);
     
 out:
+    gfn_unlock(p2m, gfn, SUPERPAGE_ORDER);
     return ret;
 }
 
@@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
     limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
 
     /* FIXME: Figure out how to avoid superpages */
+    /* NOTE: Promote to globally locking the p2m. This will get complicated
+     * in a fine-grained scenario. Even if we're to lock each gfn 
+     * individually we must be careful about recursion limits and 
+     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock constraints 
+     * between p2m and pod locks */
+    p2m_lock(p2m);
     for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
     {
         p2m_access_t a;
@@ -940,7 +953,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
         /* Stop if we're past our limit and we have found *something*.
          *
          * NB that this is a zero-sum game; we're increasing our cache size
-         * by re-increasing our 'debt'.  Since we hold the p2m lock,
+         * by re-increasing our 'debt'.  Since we hold the pod lock,
          * (entry_count - count) must remain the same. */
         if ( p2m->pod.count > 0 && i < limit )
             break;
@@ -949,6 +962,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
     if ( j )
         p2m_pod_zero_check(p2m, gfns, j);
 
+    p2m_unlock(p2m);
     p2m->pod.reclaim_single = i ? i - 1 : i;
 
 }
@@ -965,8 +979,9 @@ p2m_pod_demand_populate(struct p2m_domai
     int i;
 
     ASSERT(gfn_locked_by_me(p2m, gfn));
+    pod_lock(p2m);
 
-    /* This check is done with the p2m lock held.  This will make sure that
+    /* This check is done with the pod lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
      * won't start until we're done. */
     if ( unlikely(d->is_dying) )
@@ -977,6 +992,7 @@ p2m_pod_demand_populate(struct p2m_domai
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
     {
+        pod_unlock(p2m);
         gfn_aligned = (gfn >> order) << order;
         /* Note that we are supposed to call set_p2m_entry() 512 times to 
          * split 1GB into 512 2MB pages here. But We only do once here because
@@ -1000,11 +1016,15 @@ p2m_pod_demand_populate(struct p2m_domai
 
         /* If we're low, start a sweep */
         if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
+            /* Note that sweeps scan other ranges in the p2m. In an scenario
+             * in which p2m locks are order-enforced wrt pod lock and p2m 
+             * locks are fine grained, this will result in deadlock panic */
             p2m_pod_emergency_sweep_super(p2m);
 
         if ( page_list_empty(&p2m->pod.single) &&
              ( ( order == PAGE_ORDER_4K )
                || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
+            /* Same comment regarding deadlock applies */
             p2m_pod_emergency_sweep(p2m);
     }
 
@@ -1012,8 +1032,6 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( q == p2m_guest && gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    lock_page_alloc(p2m);
-
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 
@@ -1026,8 +1044,6 @@ p2m_pod_demand_populate(struct p2m_domai
 
     BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
 
-    unlock_page_alloc(p2m);
-
     gfn_aligned = (gfn >> order) << order;
 
     set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw, p2m->default_access);
@@ -1038,7 +1054,7 @@ p2m_pod_demand_populate(struct p2m_domai
         paging_mark_dirty(d, mfn_x(mfn) + i);
     }
     
-    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
+    p2m->pod.entry_count -= (1 << order);
     BUG_ON(p2m->pod.entry_count < 0);
 
     if ( tb_init_done )
@@ -1056,20 +1072,24 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    pod_unlock(p2m);
     return 0;
 out_of_memory:
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 " pod_entries %" PRIi32 "\n",
            __func__, d->tot_pages, p2m->pod.entry_count);
     domain_crash(d);
 out_fail:
+    pod_unlock(p2m);
     return -1;
 remap_and_retry:
     BUG_ON(order != PAGE_ORDER_2M);
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     /* Remap this 2-meg region in singleton chunks */
+    /* NOTE: In a p2m fine-grained lock scenario this might
+     * need promoting the gfn lock from gfn->2M superpage */
     gfn_aligned = (gfn>>order)<<order;
     for(i=0; i<(1<<order); i++)
         set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
@@ -1137,9 +1157,11 @@ guest_physmap_mark_populate_on_demand(st
         rc = -EINVAL;
     else
     {
-        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
+        pod_lock(p2m);
+        p2m->pod.entry_count += 1 << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
+        pod_unlock(p2m);
     }
 
     gfn_unlock(p2m, gfn, order);
diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain 
     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) );
diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
     mm_lock_init(&p2m->lock);
+    mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
     INIT_PAGE_LIST_HEAD(&p2m->pod.super);
@@ -587,8 +588,10 @@ guest_physmap_add_entry(struct domain *d
             rc = -EINVAL;
         else
         {
-            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
+            pod_lock(p2m);
+            p2m->pod.entry_count -= pod_count;
             BUG_ON(p2m->pod.entry_count < 0);
+            pod_unlock(p2m);
         }
     }
 
@@ -1372,6 +1375,7 @@ p2m_flush_table(struct p2m_domain *p2m)
     /* "Host" p2m tables can have shared entries &c that need a bit more 
      * care when discarding them */
     ASSERT(p2m_is_nestedp2m(p2m));
+    /* Nested p2m's do not do pod, hence the asserts (and no pod lock)*/
     ASSERT(page_list_empty(&p2m->pod.super));
     ASSERT(page_list_empty(&p2m->pod.single));
 
@@ -1529,6 +1533,7 @@ void audit_p2m(struct domain *d,
     P2M_PRINTK("p2m audit starts\n");
 
     p2m_lock(p2m);
+    pod_lock(p2m);
 
     if (p2m->audit_p2m)
         pmbad = p2m->audit_p2m(p2m);
@@ -1589,6 +1594,7 @@ void audit_p2m(struct domain *d,
     }
     spin_unlock(&d->page_alloc_lock);
 
+    pod_unlock(p2m);
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
diff -r fb9c06df05f2 -r 56ceab0118cb xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -261,25 +261,12 @@ struct p2m_domain {
     unsigned long max_mapped_pfn;
 
     /* Populate-on-demand variables
-     * NB on locking.  {super,single,count} are
-     * covered by d->page_alloc_lock, since they're almost always used in
-     * conjunction with that functionality.  {entry_count} is covered by
-     * the domain p2m lock, since it's almost always used in conjunction
-     * with changing the p2m tables.
-     *
-     * At this point, both locks are held in two places.  In both,
-     * the order is [p2m,page_alloc]:
-     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
-     *   which grabs page_alloc
-     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
-     *   double-demand-populating of pages, the page_alloc lock to
-     *   protect moving stuff from the PoD cache to the domain page list.
-     *
-     * We enforce this lock ordering through a construct in mm-locks.h.
-     * This demands, however, that we store the previous lock-ordering
-     * level in effect before grabbing the page_alloc lock. The unlock
-     * level is stored in the arch section of the domain struct.
-     */
+     * All variables are protected with the pod lock. We cannot rely on
+     * the p2m lock if it's turned into a fine-grained lock.
+     * We only use the domain page_alloc lock for additions and 
+     * deletions to the domain's page list. Because we use it nested
+     * within the PoD lock, we enforce it's ordering (by remembering
+     * the unlock level in the arch_domain sub struct). */
     struct {
         struct page_list_head super,   /* List of superpages                */
                          single;       /* Non-super lists                   */
@@ -288,6 +275,8 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+        mm_lock_t        lock;         /* Locking of private pod structs,   *
+                                        * not relying on the p2m lock.      */
     } pod;
 };
 

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:55:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgHK-00039u-B3; Wed, 01 Feb 2012 19:55:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgHI-00038q-Ku
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:55:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328126129!13030102!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12263 invoked from network); 1 Feb 2012 19:55:30 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-8.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:55:30 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 202A64B0091;
	Wed,  1 Feb 2012 11:50:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UldlLCFQ2hH9UpSYu7GIa5cp+WlYqth4Md9vqz1MGAmb
	wlllTweBUs8/bFm9DMZ9e/2h+w4xOJJMSu6/gCyiLpAFeluykPa2FiCswnmFc9PI
	1D1HvJ4RM/g2YJ62Oqx2CMXlTGfb6UHGf8EXBHGYNGzOtlLbllPmZhPxY4KepEU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fvYX9jdjZTG2lpuDJ07u9IpR/QM=; b=QGMH9DO5dfb
	RlMiPpnYob0xoFmObrn3tb3aOQ3bX1qkVkQDAwEkgIWi4y5JYhRoKhoRDANFr4Cu
	ExMKXztNOHeczaKirwAhqUoZ+C+kqL9mMcbfDB+RvVDgjQkMjCwnqee/4skZQRsS
	44/d8EuYyTSBSsUJGDXwwJy/Ufw3Vc6M=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 27EDB4B0084; 
	Wed,  1 Feb 2012 11:50:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: fb9c06df05f20461744a8bfed34591fedf488ce2
Message-Id: <fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m lockups
 are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |   2 -
 xen/arch/x86/mm/mm-locks.h    |   4 ++-
 xen/arch/x86/mm/p2m-ept.c     |  33 ++-------------------
 xen/arch/x86/mm/p2m-pod.c     |  14 ++++++---
 xen/arch/x86/mm/p2m-pt.c      |  45 +++++------------------------
 xen/arch/x86/mm/p2m.c         |  64 ++++++++++++++++++++++--------------------
 6 files changed, 58 insertions(+), 104 deletions(-)


With p2m lookups fully synchronized, many routines need not
call p2m_lock any longer. Also, many routines can logically
assert holding the p2m for a specific gfn.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -882,9 +882,7 @@ int mem_sharing_add_to_physmap(struct do
         goto err_unlock;
     }
 
-    p2m_lock(p2m);
     ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
-    p2m_unlock(p2m);
 
     /* Tempted to turn this into an assert */
     if ( !ret )
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -165,9 +165,11 @@ declare_mm_lock(nestedp2m)
 
 declare_mm_lock(p2m)
 #define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
 #define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
 #define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
 
 /* Sharing per page lock
  *
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -46,31 +46,6 @@ static inline bool_t is_epte_valid(ept_e
     return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
 }
 
-/* Non-ept "lock-and-check" wrapper */
-static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      ept_entry_t *entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( entry->sa_p2mt != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_access_t access)
 {
     /* First apply type permissions */
@@ -551,8 +526,8 @@ static mfn_t ept_get_entry(struct p2m_do
             index = gfn_remainder >> ( i * EPT_TABLE_ORDER);
             ept_entry = table + index;
 
-            if ( !ept_pod_check_and_populate(p2m, gfn,
-                                             ept_entry, 9, q) )
+            if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                            PAGE_ORDER_2M, q) )
                 goto retry;
             else
                 goto out;
@@ -574,8 +549,8 @@ static mfn_t ept_get_entry(struct p2m_do
 
         ASSERT(i == 0);
         
-        if ( ept_pod_check_and_populate(p2m, gfn,
-                                        ept_entry, 0, q) )
+        if ( p2m_pod_demand_populate(p2m, gfn, 
+                                        PAGE_ORDER_4K, q) )
             goto out;
     }
 
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -521,7 +521,7 @@ p2m_pod_decrease_reservation(struct doma
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gpfn, order);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -615,7 +615,7 @@ out_entry_check:
     }
 
 out_unlock:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gpfn, order);
 
 out:
     return ret;
@@ -964,7 +964,7 @@ p2m_pod_demand_populate(struct p2m_domai
     mfn_t mfn;
     int i;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     /* This check is done with the p2m lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
@@ -972,6 +972,7 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( unlikely(d->is_dying) )
         goto out_fail;
 
+    
     /* Because PoD does not have cache list for 1GB pages, it has to remap
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
@@ -981,6 +982,9 @@ p2m_pod_demand_populate(struct p2m_domai
          * split 1GB into 512 2MB pages here. But We only do once here because
          * set_p2m_entry() should automatically shatter the 1GB page into 
          * 512 2MB pages. The rest of 511 calls are unnecessary.
+         *
+         * NOTE: In a fine-grained p2m locking scenario this operation
+         * may need to promote its locking from gfn->1g superpage
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
@@ -1104,7 +1108,7 @@ guest_physmap_mark_populate_on_demand(st
     if ( rc != 0 )
         return rc;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, order);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1138,7 +1142,7 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, order);
 
 out:
     return rc;
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -473,31 +473,6 @@ out:
 }
 
 
-/* Non-ept "lock-and-check" wrapper */
-static int p2m_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      l1_pgentry_t *p2m_entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 /* 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, 
@@ -540,8 +515,7 @@ pod_retry_l3:
             /* The read has succeeded, so we know that mapping exists */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) &l3e, PAGE_ORDER_1G, q) )
+                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__);
@@ -593,8 +567,8 @@ pod_retry_l2:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 p2m_entry, 9, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
 
                 /* Allocate failed. */
@@ -651,8 +625,8 @@ pod_retry_l1:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)p2m_entry, 0, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
 
                 /* Allocate failed. */
@@ -742,8 +716,7 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) l3e, PAGE_ORDER_1G, q) )
+                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
                     gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 }
@@ -781,8 +754,7 @@ pod_retry_l2:
         if ( p2m_flags_to_type(l2e_get_flags(*l2e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l2e, PAGE_ORDER_2M, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
             } else
                 *t = p2m_populate_on_demand;
@@ -815,8 +787,7 @@ pod_retry_l1:
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l1e, PAGE_ORDER_4K, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
                 *t = p2m_populate_on_demand;
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -161,7 +161,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     /* For now only perform locking on hap domains */
     if ( locked && (hap_enabled(p2m->domain)) )
         /* Grab the lock here, don't release until put_gfn */
-        p2m_lock(p2m);
+        gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
@@ -194,9 +194,9 @@ void __put_gfn(struct p2m_domain *p2m, u
         /* Nothing to do in this case */
         return;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 }
 
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
@@ -207,7 +207,7 @@ int set_p2m_entry(struct p2m_domain *p2m
     unsigned int order;
     int rc = 1;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     while ( todo )
     {
@@ -429,6 +429,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         return;
     }
 
+    ASSERT(gfn_locked_by_me(p2m, gfn));
     P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
     if ( mfn_valid(_mfn(mfn)) )
@@ -449,9 +450,9 @@ guest_physmap_remove_page(struct domain 
                           unsigned long mfn, unsigned int page_order)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, page_order);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, page_order);
 }
 
 int
@@ -609,13 +610,13 @@ p2m_type_t p2m_change_type(struct domain
 
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
     if ( pt == ot )
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return pt;
 }
@@ -664,7 +665,7 @@ set_mmio_p2m_entry(struct domain *d, uns
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     if ( p2m_is_grant(ot) )
     {
@@ -680,7 +681,7 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_mmio_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -700,7 +701,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
 
     /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
@@ -713,7 +714,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
 
 out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return rc;
 }
@@ -730,7 +731,7 @@ set_shared_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(p2m->domain) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     /* At the moment we only allow p2m change if gfn has already been made
      * sharable first */
@@ -742,7 +743,7 @@ set_shared_p2m_entry(struct domain *d, u
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_shared, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_shared_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -778,7 +779,7 @@ int p2m_mem_paging_nominate(struct domai
     mfn_t mfn;
     int ret;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -810,7 +811,7 @@ int p2m_mem_paging_nominate(struct domai
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -842,7 +843,7 @@ int p2m_mem_paging_evict(struct domain *
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EINVAL;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     /* Get mfn */
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -887,7 +888,7 @@ int p2m_mem_paging_evict(struct domain *
     put_page(page);
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -972,7 +973,7 @@ void p2m_mem_paging_populate(struct doma
     req.type = MEM_EVENT_TYPE_PAGING;
 
     /* Fix p2m mapping */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
@@ -983,7 +984,7 @@ void p2m_mem_paging_populate(struct doma
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Pause domain if request came from guest and gfn has paging type */
     if ( p2m_is_paging(p2mt) && v->domain == d )
@@ -1034,7 +1035,7 @@ int p2m_mem_paging_prep(struct domain *d
              (!access_ok(user_ptr, PAGE_SIZE)) )
             return -EINVAL;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -1093,7 +1094,7 @@ int p2m_mem_paging_prep(struct domain *d
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -1128,7 +1129,7 @@ void p2m_mem_paging_resume(struct domain
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
-            p2m_lock(p2m);
+            gfn_lock(p2m, rsp.gfn, 0);
             mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
@@ -1139,7 +1140,7 @@ void p2m_mem_paging_resume(struct domain
                                 p2m_ram_rw, a);
                 set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
             }
-            p2m_unlock(p2m);
+            gfn_unlock(p2m, rsp.gfn, 0);
         }
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
@@ -1160,13 +1161,13 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_access_t p2ma;
     
     /* First, handle rx2rw conversion automatically */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
-        p2m_unlock(p2m);
+        gfn_unlock(p2m, gfn, 0);
         return 1;
     }
     else if ( p2ma == p2m_access_n2rwx )
@@ -1174,7 +1175,7 @@ bool_t p2m_mem_access_check(unsigned lon
         ASSERT(access_w || access_r || access_x);
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
     if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
@@ -1193,9 +1194,9 @@ bool_t p2m_mem_access_check(unsigned lon
             if ( p2ma != p2m_access_n2rwx )
             {
                 /* A listener is not required, so clear the access restrictions */
-                p2m_lock(p2m);
+                gfn_lock(p2m, gfn, 0);
                 p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-                p2m_unlock(p2m);
+                gfn_unlock(p2m, gfn, 0);
             }
             return 1;
         }
@@ -1326,7 +1327,10 @@ int p2m_get_mem_access(struct domain *d,
         return 0;
     }
 
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL);
+    gfn_unlock(p2m, gfn, 0);
+
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     
@@ -1445,7 +1449,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
             nestedp2m_unlock(d);
             return p2m;
         }
-        p2m_unlock(p2m);
+        gfn_unlock(p2m, gfn, 0);
     }
 
     /* All p2m's are or were in use. Take the least recent used one,

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 19:55:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 19: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.xensource.com>)
	id 1RsgHK-00039u-B3; Wed, 01 Feb 2012 19:55:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgHI-00038q-Ku
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 19:55:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328126129!13030102!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12263 invoked from network); 1 Feb 2012 19:55:30 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-8.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 19:55:30 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 202A64B0091;
	Wed,  1 Feb 2012 11:50:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UldlLCFQ2hH9UpSYu7GIa5cp+WlYqth4Md9vqz1MGAmb
	wlllTweBUs8/bFm9DMZ9e/2h+w4xOJJMSu6/gCyiLpAFeluykPa2FiCswnmFc9PI
	1D1HvJ4RM/g2YJ62Oqx2CMXlTGfb6UHGf8EXBHGYNGzOtlLbllPmZhPxY4KepEU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fvYX9jdjZTG2lpuDJ07u9IpR/QM=; b=QGMH9DO5dfb
	RlMiPpnYob0xoFmObrn3tb3aOQ3bX1qkVkQDAwEkgIWi4y5JYhRoKhoRDANFr4Cu
	ExMKXztNOHeczaKirwAhqUoZ+C+kqL9mMcbfDB+RvVDgjQkMjCwnqee/4skZQRsS
	44/d8EuYyTSBSsUJGDXwwJy/Ufw3Vc6M=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 27EDB4B0084; 
	Wed,  1 Feb 2012 11:50:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: fb9c06df05f20461744a8bfed34591fedf488ce2
Message-Id: <fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126164@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 14:56:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m lockups
 are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |   2 -
 xen/arch/x86/mm/mm-locks.h    |   4 ++-
 xen/arch/x86/mm/p2m-ept.c     |  33 ++-------------------
 xen/arch/x86/mm/p2m-pod.c     |  14 ++++++---
 xen/arch/x86/mm/p2m-pt.c      |  45 +++++------------------------
 xen/arch/x86/mm/p2m.c         |  64 ++++++++++++++++++++++--------------------
 6 files changed, 58 insertions(+), 104 deletions(-)


With p2m lookups fully synchronized, many routines need not
call p2m_lock any longer. Also, many routines can logically
assert holding the p2m for a specific gfn.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -882,9 +882,7 @@ int mem_sharing_add_to_physmap(struct do
         goto err_unlock;
     }
 
-    p2m_lock(p2m);
     ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
-    p2m_unlock(p2m);
 
     /* Tempted to turn this into an assert */
     if ( !ret )
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -165,9 +165,11 @@ declare_mm_lock(nestedp2m)
 
 declare_mm_lock(p2m)
 #define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
 #define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
 #define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
 
 /* Sharing per page lock
  *
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -46,31 +46,6 @@ static inline bool_t is_epte_valid(ept_e
     return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
 }
 
-/* Non-ept "lock-and-check" wrapper */
-static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      ept_entry_t *entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( entry->sa_p2mt != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_access_t access)
 {
     /* First apply type permissions */
@@ -551,8 +526,8 @@ static mfn_t ept_get_entry(struct p2m_do
             index = gfn_remainder >> ( i * EPT_TABLE_ORDER);
             ept_entry = table + index;
 
-            if ( !ept_pod_check_and_populate(p2m, gfn,
-                                             ept_entry, 9, q) )
+            if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                            PAGE_ORDER_2M, q) )
                 goto retry;
             else
                 goto out;
@@ -574,8 +549,8 @@ static mfn_t ept_get_entry(struct p2m_do
 
         ASSERT(i == 0);
         
-        if ( ept_pod_check_and_populate(p2m, gfn,
-                                        ept_entry, 0, q) )
+        if ( p2m_pod_demand_populate(p2m, gfn, 
+                                        PAGE_ORDER_4K, q) )
             goto out;
     }
 
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -521,7 +521,7 @@ p2m_pod_decrease_reservation(struct doma
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gpfn, order);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -615,7 +615,7 @@ out_entry_check:
     }
 
 out_unlock:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gpfn, order);
 
 out:
     return ret;
@@ -964,7 +964,7 @@ p2m_pod_demand_populate(struct p2m_domai
     mfn_t mfn;
     int i;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     /* This check is done with the p2m lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
@@ -972,6 +972,7 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( unlikely(d->is_dying) )
         goto out_fail;
 
+    
     /* Because PoD does not have cache list for 1GB pages, it has to remap
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
@@ -981,6 +982,9 @@ p2m_pod_demand_populate(struct p2m_domai
          * split 1GB into 512 2MB pages here. But We only do once here because
          * set_p2m_entry() should automatically shatter the 1GB page into 
          * 512 2MB pages. The rest of 511 calls are unnecessary.
+         *
+         * NOTE: In a fine-grained p2m locking scenario this operation
+         * may need to promote its locking from gfn->1g superpage
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
@@ -1104,7 +1108,7 @@ guest_physmap_mark_populate_on_demand(st
     if ( rc != 0 )
         return rc;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, order);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1138,7 +1142,7 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, order);
 
 out:
     return rc;
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -473,31 +473,6 @@ out:
 }
 
 
-/* Non-ept "lock-and-check" wrapper */
-static int p2m_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      l1_pgentry_t *p2m_entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 /* 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, 
@@ -540,8 +515,7 @@ pod_retry_l3:
             /* The read has succeeded, so we know that mapping exists */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) &l3e, PAGE_ORDER_1G, q) )
+                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__);
@@ -593,8 +567,8 @@ pod_retry_l2:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 p2m_entry, 9, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
 
                 /* Allocate failed. */
@@ -651,8 +625,8 @@ pod_retry_l1:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)p2m_entry, 0, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
 
                 /* Allocate failed. */
@@ -742,8 +716,7 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) l3e, PAGE_ORDER_1G, q) )
+                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
                     gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 }
@@ -781,8 +754,7 @@ pod_retry_l2:
         if ( p2m_flags_to_type(l2e_get_flags(*l2e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l2e, PAGE_ORDER_2M, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
             } else
                 *t = p2m_populate_on_demand;
@@ -815,8 +787,7 @@ pod_retry_l1:
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l1e, PAGE_ORDER_4K, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
                 *t = p2m_populate_on_demand;
diff -r 223512f9fb5b -r fb9c06df05f2 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -161,7 +161,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     /* For now only perform locking on hap domains */
     if ( locked && (hap_enabled(p2m->domain)) )
         /* Grab the lock here, don't release until put_gfn */
-        p2m_lock(p2m);
+        gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
@@ -194,9 +194,9 @@ void __put_gfn(struct p2m_domain *p2m, u
         /* Nothing to do in this case */
         return;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 }
 
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
@@ -207,7 +207,7 @@ int set_p2m_entry(struct p2m_domain *p2m
     unsigned int order;
     int rc = 1;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     while ( todo )
     {
@@ -429,6 +429,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         return;
     }
 
+    ASSERT(gfn_locked_by_me(p2m, gfn));
     P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
     if ( mfn_valid(_mfn(mfn)) )
@@ -449,9 +450,9 @@ guest_physmap_remove_page(struct domain 
                           unsigned long mfn, unsigned int page_order)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, page_order);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, page_order);
 }
 
 int
@@ -609,13 +610,13 @@ p2m_type_t p2m_change_type(struct domain
 
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
     if ( pt == ot )
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return pt;
 }
@@ -664,7 +665,7 @@ set_mmio_p2m_entry(struct domain *d, uns
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     if ( p2m_is_grant(ot) )
     {
@@ -680,7 +681,7 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_mmio_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -700,7 +701,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
 
     /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
@@ -713,7 +714,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
 
 out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return rc;
 }
@@ -730,7 +731,7 @@ set_shared_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(p2m->domain) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     /* At the moment we only allow p2m change if gfn has already been made
      * sharable first */
@@ -742,7 +743,7 @@ set_shared_p2m_entry(struct domain *d, u
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_shared, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_shared_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -778,7 +779,7 @@ int p2m_mem_paging_nominate(struct domai
     mfn_t mfn;
     int ret;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -810,7 +811,7 @@ int p2m_mem_paging_nominate(struct domai
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -842,7 +843,7 @@ int p2m_mem_paging_evict(struct domain *
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EINVAL;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     /* Get mfn */
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -887,7 +888,7 @@ int p2m_mem_paging_evict(struct domain *
     put_page(page);
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -972,7 +973,7 @@ void p2m_mem_paging_populate(struct doma
     req.type = MEM_EVENT_TYPE_PAGING;
 
     /* Fix p2m mapping */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
@@ -983,7 +984,7 @@ void p2m_mem_paging_populate(struct doma
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Pause domain if request came from guest and gfn has paging type */
     if ( p2m_is_paging(p2mt) && v->domain == d )
@@ -1034,7 +1035,7 @@ int p2m_mem_paging_prep(struct domain *d
              (!access_ok(user_ptr, PAGE_SIZE)) )
             return -EINVAL;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -1093,7 +1094,7 @@ int p2m_mem_paging_prep(struct domain *d
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -1128,7 +1129,7 @@ void p2m_mem_paging_resume(struct domain
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
-            p2m_lock(p2m);
+            gfn_lock(p2m, rsp.gfn, 0);
             mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
@@ -1139,7 +1140,7 @@ void p2m_mem_paging_resume(struct domain
                                 p2m_ram_rw, a);
                 set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
             }
-            p2m_unlock(p2m);
+            gfn_unlock(p2m, rsp.gfn, 0);
         }
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
@@ -1160,13 +1161,13 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_access_t p2ma;
     
     /* First, handle rx2rw conversion automatically */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
-        p2m_unlock(p2m);
+        gfn_unlock(p2m, gfn, 0);
         return 1;
     }
     else if ( p2ma == p2m_access_n2rwx )
@@ -1174,7 +1175,7 @@ bool_t p2m_mem_access_check(unsigned lon
         ASSERT(access_w || access_r || access_x);
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
     if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
@@ -1193,9 +1194,9 @@ bool_t p2m_mem_access_check(unsigned lon
             if ( p2ma != p2m_access_n2rwx )
             {
                 /* A listener is not required, so clear the access restrictions */
-                p2m_lock(p2m);
+                gfn_lock(p2m, gfn, 0);
                 p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-                p2m_unlock(p2m);
+                gfn_unlock(p2m, gfn, 0);
             }
             return 1;
         }
@@ -1326,7 +1327,10 @@ int p2m_get_mem_access(struct domain *d,
         return 0;
     }
 
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL);
+    gfn_unlock(p2m, gfn, 0);
+
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     
@@ -1445,7 +1449,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
             nestedp2m_unlock(d);
             return p2m;
         }
-        p2m_unlock(p2m);
+        gfn_unlock(p2m, gfn, 0);
     }
 
     /* All p2m's are or were in use. Take the least recent used one,

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:04:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgPy-0003Rb-IM; Wed, 01 Feb 2012 20:04:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgPw-0003RU-QL
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:04:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328126666!13332608!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23325 invoked from network); 1 Feb 2012 20:04:26 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 20:04:26 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id CB1BC30008F;
	Wed,  1 Feb 2012 12:04:25 -0800 (PST)
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=i0FR/0uAUc2fm950pPldzR
	1lkcz1XvTgqkMX2nfe3DJ6SWWlLSdI6VoFcraaCILCRMcmwsXUjwrel3vuHjvKkC
	+H9CJosWAH75FlYLXyw64uD0HEAOyEgRIFRd2BG+sa+8KPmIudmV+Mz6QPGrjmcL
	B0ZwCk8wbrvqd9L/o3xAA=
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=3re0OK4pxKWI
	TzwoDDxPmdO/A5A=; b=r3M03jH8/GmrDT8xUsAuf7CnBr1thMT8WIE9QPxH9knj
	1eRvXTeqAK6RdYGg/3spZrcsWSttNGa+bmXFLjwgFxb7FsEJ5mD08eCu+FLO/ZEc
	W35DyfX8TUj6kWqJ8GVISsDYnUM2chIp16MTGVBJTDJBxff4/089Gv/HVIUfnsA=
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 D3502300064; 
	Wed,  1 Feb 2012 12:04:23 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 15:09:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] x86/mm: Switch paging/sharing/access
 per-page ops to memops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

A new tools-only section is added to the public memory.h header.

This is a backwards-incompatible ABI change. It's been floating on the list for
a couple weeks now, with no nacks thus far.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 tools/libxc/xc_memshr.c              |   11 ++
 tools/libxc/xenctrl.h                |    1 +
 tools/tests/mem-sharing/memshrtool.c |   11 ++
 xen/arch/x86/mm/mem_sharing.c        |   13 +-
 xen/arch/x86/x86_64/compat/mm.c      |    3 +
 xen/arch/x86/x86_64/mm.c             |    2 +
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 xen/include/public/memory.h          |    1 +
 28 files changed, 458 insertions(+), 284 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:04:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgPy-0003Rb-IM; Wed, 01 Feb 2012 20:04:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgPw-0003RU-QL
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:04:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328126666!13332608!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23325 invoked from network); 1 Feb 2012 20:04:26 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 20:04:26 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id CB1BC30008F;
	Wed,  1 Feb 2012 12:04:25 -0800 (PST)
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=i0FR/0uAUc2fm950pPldzR
	1lkcz1XvTgqkMX2nfe3DJ6SWWlLSdI6VoFcraaCILCRMcmwsXUjwrel3vuHjvKkC
	+H9CJosWAH75FlYLXyw64uD0HEAOyEgRIFRd2BG+sa+8KPmIudmV+Mz6QPGrjmcL
	B0ZwCk8wbrvqd9L/o3xAA=
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=3re0OK4pxKWI
	TzwoDDxPmdO/A5A=; b=r3M03jH8/GmrDT8xUsAuf7CnBr1thMT8WIE9QPxH9knj
	1eRvXTeqAK6RdYGg/3spZrcsWSttNGa+bmXFLjwgFxb7FsEJ5mD08eCu+FLO/ZEc
	W35DyfX8TUj6kWqJ8GVISsDYnUM2chIp16MTGVBJTDJBxff4/089Gv/HVIUfnsA=
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 D3502300064; 
	Wed,  1 Feb 2012 12:04:23 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 15:09:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] x86/mm: Switch paging/sharing/access
 per-page ops to memops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

A new tools-only section is added to the public memory.h header.

This is a backwards-incompatible ABI change. It's been floating on the list for
a couple weeks now, with no nacks thus far.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 tools/libxc/xc_memshr.c              |   11 ++
 tools/libxc/xenctrl.h                |    1 +
 tools/tests/mem-sharing/memshrtool.c |   11 ++
 xen/arch/x86/mm/mem_sharing.c        |   13 +-
 xen/arch/x86/x86_64/compat/mm.c      |    3 +
 xen/arch/x86/x86_64/mm.c             |    2 +
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 xen/include/public/memory.h          |    1 +
 28 files changed, 458 insertions(+), 284 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:04:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgPz-0003Rq-V1; Wed, 01 Feb 2012 20:04:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgPy-0003RW-I9
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:04:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328126539!50997327!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzczNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13145 invoked from network); 1 Feb 2012 20:02:19 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 20:02:19 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1C89B30008F;
	Wed,  1 Feb 2012 12:04:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vlYzX65kDHNfZ33T7lROUCohLfWKl1lIBeeauhmEnqxG
	x2Ks30b/jpIou88PbTrtZkAv3BgEeiamUWXou9ZbjH9tP11j0u9Oba9q8Oc/0zeh
	5nG0BrW5Vnu21NROnrM0rKKIWvC0jNWTH1vle2+A+Ng8JunRZYX9+GjN29JP5JE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=xzPRQ7YbV7CJSQDgJ7N+Gera2OA=; b=l5wwPs5j/sA
	sHRmyOeJC9JsLkVTz8HS6Bkr1F6MB4u21CMWpOA0mvTvmOnoPg91rbZ2ERJZRVLF
	+pNMDnY+rU4/dPfnp+YLcn2kfWIwGwc5xIwjEfBhQ0p8IRFFGXjOfjgfabxqM+vI
	+ZR0ELb99SCU4gsZqXb6aMJuyi/R4300=
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 BBB67300090; 
	Wed,  1 Feb 2012 12:04:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f0aec2898b83ac79d16c509fa769ffec2202f35d
Message-Id: <f0aec2898b83ac79d16c.1328126980@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126978@xdev.gridcentric.ca>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 15:09:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c              |  11 +++++++++++
 tools/libxc/xenctrl.h                |   1 +
 tools/tests/mem-sharing/memshrtool.c |  11 +++++++++++
 xen/arch/x86/mm/mem_sharing.c        |  13 ++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   3 +++
 xen/arch/x86/x86_64/mm.c             |   2 ++
 xen/include/asm-x86/mem_sharing.h    |   3 ++-
 xen/include/public/memory.h          |   1 +
 8 files changed, 37 insertions(+), 8 deletions(-)


Remove costly mem_sharting audits from the inline path, and instead make them
callable as a memop.

Have the audit function return the number of errors detected.

Update memshrtool to be able to trigger audits.

Set sharing audits as enabled by default.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 8e64acc49aa8 -r f0aec2898b83 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,6 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_audit(xc_interface *xch)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_audit;
+
+    return do_memory_op(xch, XENMEM_sharing_op, &mso, sizeof(mso));
+}
+
 long xc_sharing_freed_pages(xc_interface *xch)
 {
     return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
diff -r 8e64acc49aa8 -r f0aec2898b83 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1947,6 +1947,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
diff -r 8e64acc49aa8 -r f0aec2898b83 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -27,6 +27,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
     return 1;
 }
 
@@ -160,6 +161,16 @@ int main(int argc, const char** argv)
         gfn = strtol(argv[3], NULL, 0);
         R(xc_memshr_debug_gfn(xch, domid, gfn));
     }
+    else if( !strcasecmp(cmd, "audit") )
+    {
+        int rc = xc_memshr_audit(xch);
+        if ( rc < 0 )
+        {
+            printf("error executing xc_memshr_audit: %s\n", strerror(errno));
+            return rc;
+        }
+        printf("Audit returned %d errors.\n", rc);
+    }
 
     return 0;
 }
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -50,8 +50,6 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #if MEM_SHARING_AUDIT
 
-static void mem_sharing_audit(void);
-
 static struct list_head shr_audit_list;
 static spinlock_t shr_audit_lock;
 DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
@@ -81,7 +79,10 @@ static inline void audit_del_list(struct
 
 #else
 
-#define mem_sharing_audit() ((void)0)
+int mem_sharing_audit(void)
+{
+    return -ENOSYS;
+}
 
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
@@ -212,7 +213,7 @@ static struct page_info* mem_sharing_loo
 }
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
+int mem_sharing_audit(void)
 {
     int errors = 0;
     unsigned long count_expected;
@@ -338,6 +339,7 @@ static void mem_sharing_audit(void)
         errors++;
     }
 
+    return errors;
 }
 #endif
 
@@ -918,7 +920,6 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1182,8 +1183,6 @@ int mem_sharing_memop(struct domain *d, 
             break;
     }
 
-    mem_sharing_audit();
-
     return rc;
 }
 
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -3,6 +3,7 @@
 #include <compat/memory.h>
 #include <compat/xen.h>
 #include <asm/mem_event.h>
+#include <asm/mem_sharing.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -228,6 +229,8 @@ int compat_arch_memory_op(int op, XEN_GU
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1117,6 +1117,8 @@ long subarch_memory_op(int op, XEN_GUEST
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -26,7 +26,7 @@
 #include <public/memory.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -61,6 +61,7 @@ int mem_sharing_memop(struct domain *d,
                        xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
 #else 
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -333,6 +333,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op
 #define XENMEM_sharing_op_debug_mfn         5
 #define XENMEM_sharing_op_debug_gref        6
 #define XENMEM_sharing_op_add_physmap       7
+#define XENMEM_sharing_op_audit             8
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:04:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsgPz-0003Rq-V1; Wed, 01 Feb 2012 20:04:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgPy-0003RW-I9
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:04:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328126539!50997327!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzczNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13145 invoked from network); 1 Feb 2012 20:02:19 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-27.messagelabs.com with SMTP;
	1 Feb 2012 20:02:19 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1C89B30008F;
	Wed,  1 Feb 2012 12:04:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vlYzX65kDHNfZ33T7lROUCohLfWKl1lIBeeauhmEnqxG
	x2Ks30b/jpIou88PbTrtZkAv3BgEeiamUWXou9ZbjH9tP11j0u9Oba9q8Oc/0zeh
	5nG0BrW5Vnu21NROnrM0rKKIWvC0jNWTH1vle2+A+Ng8JunRZYX9+GjN29JP5JE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=xzPRQ7YbV7CJSQDgJ7N+Gera2OA=; b=l5wwPs5j/sA
	sHRmyOeJC9JsLkVTz8HS6Bkr1F6MB4u21CMWpOA0mvTvmOnoPg91rbZ2ERJZRVLF
	+pNMDnY+rU4/dPfnp+YLcn2kfWIwGwc5xIwjEfBhQ0p8IRFFGXjOfjgfabxqM+vI
	+ZR0ELb99SCU4gsZqXb6aMJuyi/R4300=
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 BBB67300090; 
	Wed,  1 Feb 2012 12:04:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f0aec2898b83ac79d16c509fa769ffec2202f35d
Message-Id: <f0aec2898b83ac79d16c.1328126980@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126978@xdev.gridcentric.ca>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 15:09:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c              |  11 +++++++++++
 tools/libxc/xenctrl.h                |   1 +
 tools/tests/mem-sharing/memshrtool.c |  11 +++++++++++
 xen/arch/x86/mm/mem_sharing.c        |  13 ++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   3 +++
 xen/arch/x86/x86_64/mm.c             |   2 ++
 xen/include/asm-x86/mem_sharing.h    |   3 ++-
 xen/include/public/memory.h          |   1 +
 8 files changed, 37 insertions(+), 8 deletions(-)


Remove costly mem_sharting audits from the inline path, and instead make them
callable as a memop.

Have the audit function return the number of errors detected.

Update memshrtool to be able to trigger audits.

Set sharing audits as enabled by default.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 8e64acc49aa8 -r f0aec2898b83 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,6 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_audit(xc_interface *xch)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_audit;
+
+    return do_memory_op(xch, XENMEM_sharing_op, &mso, sizeof(mso));
+}
+
 long xc_sharing_freed_pages(xc_interface *xch)
 {
     return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
diff -r 8e64acc49aa8 -r f0aec2898b83 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1947,6 +1947,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
diff -r 8e64acc49aa8 -r f0aec2898b83 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -27,6 +27,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
     return 1;
 }
 
@@ -160,6 +161,16 @@ int main(int argc, const char** argv)
         gfn = strtol(argv[3], NULL, 0);
         R(xc_memshr_debug_gfn(xch, domid, gfn));
     }
+    else if( !strcasecmp(cmd, "audit") )
+    {
+        int rc = xc_memshr_audit(xch);
+        if ( rc < 0 )
+        {
+            printf("error executing xc_memshr_audit: %s\n", strerror(errno));
+            return rc;
+        }
+        printf("Audit returned %d errors.\n", rc);
+    }
 
     return 0;
 }
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -50,8 +50,6 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #if MEM_SHARING_AUDIT
 
-static void mem_sharing_audit(void);
-
 static struct list_head shr_audit_list;
 static spinlock_t shr_audit_lock;
 DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
@@ -81,7 +79,10 @@ static inline void audit_del_list(struct
 
 #else
 
-#define mem_sharing_audit() ((void)0)
+int mem_sharing_audit(void)
+{
+    return -ENOSYS;
+}
 
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
@@ -212,7 +213,7 @@ static struct page_info* mem_sharing_loo
 }
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
+int mem_sharing_audit(void)
 {
     int errors = 0;
     unsigned long count_expected;
@@ -338,6 +339,7 @@ static void mem_sharing_audit(void)
         errors++;
     }
 
+    return errors;
 }
 #endif
 
@@ -918,7 +920,6 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1182,8 +1183,6 @@ int mem_sharing_memop(struct domain *d, 
             break;
     }
 
-    mem_sharing_audit();
-
     return rc;
 }
 
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -3,6 +3,7 @@
 #include <compat/memory.h>
 #include <compat/xen.h>
 #include <asm/mem_event.h>
+#include <asm/mem_sharing.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -228,6 +229,8 @@ int compat_arch_memory_op(int op, XEN_GU
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1117,6 +1117,8 @@ long subarch_memory_op(int op, XEN_GUEST
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -26,7 +26,7 @@
 #include <public/memory.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -61,6 +61,7 @@ int mem_sharing_memop(struct domain *d,
                        xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
 #else 
diff -r 8e64acc49aa8 -r f0aec2898b83 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -333,6 +333,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op
 #define XENMEM_sharing_op_debug_mfn         5
 #define XENMEM_sharing_op_debug_gref        6
 #define XENMEM_sharing_op_add_physmap       7
+#define XENMEM_sharing_op_audit             8
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:04:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20: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.xensource.com>)
	id 1RsgQ1-0003S1-BK; Wed, 01 Feb 2012 20:04:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgPz-0003RV-4p
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:04:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328126668!12521140!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26701 invoked from network); 1 Feb 2012 20:04:28 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 20:04:28 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 8D0A7300080;
	Wed,  1 Feb 2012 12:04:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Fc7HmV3aqzmgojTe+0y/J6P6XOtFaGyvOQrHvE8IxSu4
	CZBCMBoOW0ZiI6rQv64DiqrZgh5S3bR6na05BQRyZ42Og65l6C9xe6RexvEYss1E
	GVRFj8ujLPviNkxeIKQrIYBSQkdO6JEOA57YSoqgTYtfJDQhRYQgLoj7BF95w/k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7IhYrpVsPhnoxKdgVNxcZHJUye4=; b=ekKGEoHhjd8
	i0hs3T8/VHF5StzCXvHqrsRarQiu8aA4vsQkQVTnIsOtLk1QShIaRb1Rqirw3Lmu
	T6en+c3Ky4217IMV3edQTbh2aKoGBlosHxgcSTZVVm6rRNe8yqBi1gjLzSFW8Zgq
	jSFRVDG5jSqfs6wCznk5huN8KyqVeewE=
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 0762A300095; 
	Wed,  1 Feb 2012 12:04:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8e64acc49aa80c1860b262789f47444e30470f66
Message-Id: <8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126978@xdev.gridcentric.ca>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 15:09:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 20 files changed, 421 insertions(+), 276 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -81,10 +81,10 @@ int xc_mem_paging_load(xc_interface *xch
     if ( mlock(buffer, XC_PAGE_SIZE) )
         return -1;
         
-    rc = xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                buffer, NULL, gfn);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     old_errno = errno;
     (void) munlock(buffer, XC_PAGE_SIZE);
@@ -95,10 +95,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,86 +143,72 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 long xc_sharing_freed_pages(xc_interface *xch)
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1879,8 +1879,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r abfc492fd04d -r 8e64acc49aa8 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r abfc492fd04d -r 8e64acc49aa8 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -34,9 +34,9 @@ static int usage(const char* prog)
     int rc = f; \
     if ( rc < 0 ) { \
         printf("error executing %s: %s\n", #f, \
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_S_HANDLE_INVALID) ? \
                 "problem with client handle" :\
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_C_HANDLE_INVALID) ? \
                 "problem with source handle" : strerror(errno)); \
         return rc; \
     } \
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -460,6 +461,54 @@ static void mem_access_notification(stru
     p2m_mem_access_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 )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -533,11 +582,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -572,14 +618,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -751,12 +751,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
         {
@@ -764,12 +764,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn);
         if ( spage == NULL )
         {
@@ -784,14 +784,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->sharing->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->sharing->handle != ch )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
@@ -855,7 +855,7 @@ int mem_sharing_add_to_physmap(struct do
         return -ENOMEM;
 
     /* Get the source shared page, check and lock */
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn);
     if ( spage == NULL )
         goto err_out;
@@ -869,7 +869,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1020,9 +1020,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1030,14 +1030,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1048,7 +1041,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1063,7 +1056,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1072,38 +1065,38 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1115,11 +1108,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1128,20 +1121,20 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1151,11 +1144,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1163,21 +1156,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(_mfn(mfn));
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1194,6 +1187,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -42,6 +42,8 @@ void mem_event_put_request(struct domain
 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 -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,43 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
-
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,63 +755,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-/* The following allows sharing of grant refs. This is useful
- * for sharing utilities sitting as "filters" in IO backends
- * (e.g. memshr + blktap(2)). The IO backend is only exposed 
- * to grant references, and this allows sharing of the grefs */
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
-
-#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
-    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
-    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
-    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
-
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        uint8_t enable;                   /* CONTROL */
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -289,6 +289,12 @@ struct xen_pod_target {
 };
 typedef struct xen_pod_target xen_pod_target_t;
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
 /*
  * Get the number of MFNs saved through memory sharing.
  * The call never fails. 
@@ -296,6 +302,87 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t     op;         /* XENMEM_*_op_* */
+    domid_t     domain;
+    
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_aligned_t    buffer;
+    /* Other OPs */
+    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t     op;     /* XENMEM_sharing_op_* */
+    domid_t     domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_aligned_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
+            uint64_aligned_t client_handle; /* IN: handle to the client page */
+            domid_t  client_domain; /* IN: the client domain id */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_aligned_t gfn;      /* IN: gfn to debug          */
+                uint64_aligned_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:04:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20: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.xensource.com>)
	id 1RsgQ1-0003S1-BK; Wed, 01 Feb 2012 20:04:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsgPz-0003RV-4p
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:04:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328126668!12521140!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkxMjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26701 invoked from network); 1 Feb 2012 20:04:28 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-216.messagelabs.com with SMTP;
	1 Feb 2012 20:04:28 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 8D0A7300080;
	Wed,  1 Feb 2012 12:04:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Fc7HmV3aqzmgojTe+0y/J6P6XOtFaGyvOQrHvE8IxSu4
	CZBCMBoOW0ZiI6rQv64DiqrZgh5S3bR6na05BQRyZ42Og65l6C9xe6RexvEYss1E
	GVRFj8ujLPviNkxeIKQrIYBSQkdO6JEOA57YSoqgTYtfJDQhRYQgLoj7BF95w/k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7IhYrpVsPhnoxKdgVNxcZHJUye4=; b=ekKGEoHhjd8
	i0hs3T8/VHF5StzCXvHqrsRarQiu8aA4vsQkQVTnIsOtLk1QShIaRb1Rqirw3Lmu
	T6en+c3Ky4217IMV3edQTbh2aKoGBlosHxgcSTZVVm6rRNe8yqBi1gjLzSFW8Zgq
	jSFRVDG5jSqfs6wCznk5huN8KyqVeewE=
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 0762A300095; 
	Wed,  1 Feb 2012 12:04:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8e64acc49aa80c1860b262789f47444e30470f66
Message-Id: <8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328126978@xdev.gridcentric.ca>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 01 Feb 2012 15:09:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 20 files changed, 421 insertions(+), 276 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -81,10 +81,10 @@ int xc_mem_paging_load(xc_interface *xch
     if ( mlock(buffer, XC_PAGE_SIZE) )
         return -1;
         
-    rc = xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                buffer, NULL, gfn);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     old_errno = errno;
     (void) munlock(buffer, XC_PAGE_SIZE);
@@ -95,10 +95,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,86 +143,72 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 long xc_sharing_freed_pages(xc_interface *xch)
diff -r abfc492fd04d -r 8e64acc49aa8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1879,8 +1879,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r abfc492fd04d -r 8e64acc49aa8 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r abfc492fd04d -r 8e64acc49aa8 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -34,9 +34,9 @@ static int usage(const char* prog)
     int rc = f; \
     if ( rc < 0 ) { \
         printf("error executing %s: %s\n", #f, \
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_S_HANDLE_INVALID) ? \
                 "problem with client handle" :\
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_C_HANDLE_INVALID) ? \
                 "problem with source handle" : strerror(errno)); \
         return rc; \
     } \
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -460,6 +461,54 @@ static void mem_access_notification(stru
     p2m_mem_access_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 )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -533,11 +582,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -572,14 +618,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -751,12 +751,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
         {
@@ -764,12 +764,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn);
         if ( spage == NULL )
         {
@@ -784,14 +784,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->sharing->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->sharing->handle != ch )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
@@ -855,7 +855,7 @@ int mem_sharing_add_to_physmap(struct do
         return -ENOMEM;
 
     /* Get the source shared page, check and lock */
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn);
     if ( spage == NULL )
         goto err_out;
@@ -869,7 +869,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1020,9 +1020,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1030,14 +1030,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1048,7 +1041,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1063,7 +1056,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1072,38 +1065,38 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1115,11 +1108,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1128,20 +1121,20 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1151,11 +1144,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1163,21 +1156,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(_mfn(mfn));
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1194,6 +1187,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -42,6 +42,8 @@ void mem_event_put_request(struct domain
 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 -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,43 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
-
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,63 +755,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-/* The following allows sharing of grant refs. This is useful
- * for sharing utilities sitting as "filters" in IO backends
- * (e.g. memshr + blktap(2)). The IO backend is only exposed 
- * to grant references, and this allows sharing of the grefs */
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
-
-#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
-    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
-    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
-    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
-
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        uint8_t enable;                   /* CONTROL */
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r abfc492fd04d -r 8e64acc49aa8 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -289,6 +289,12 @@ struct xen_pod_target {
 };
 typedef struct xen_pod_target xen_pod_target_t;
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
 /*
  * Get the number of MFNs saved through memory sharing.
  * The call never fails. 
@@ -296,6 +302,87 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t     op;         /* XENMEM_*_op_* */
+    domid_t     domain;
+    
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_aligned_t    buffer;
+    /* Other OPs */
+    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t     op;     /* XENMEM_sharing_op_* */
+    domid_t     domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_aligned_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
+            uint64_aligned_t client_handle; /* IN: handle to the client page */
+            domid_t  client_domain; /* IN: the client domain id */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_aligned_t gfn;      /* IN: gfn to debug          */
+                uint64_aligned_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:50:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20: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.xensource.com>)
	id 1Rsh7V-00054P-8S; Wed, 01 Feb 2012 20:49:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsh7T-00054E-Np
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:49:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328129365!13259739!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjAzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18643 invoked from network); 1 Feb 2012 20:49:25 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 20:49:25 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 6A1DF76C07F;
	Wed,  1 Feb 2012 12:49:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=DsdXP1F7
	qO2YJXSW7aTHEnHviARhwJnVmcv7LA+HiR5bkTrIDH6SLyoENaN+Dsn72DRpKLOv
	zzqMewKcojEvAFjIIh0FIIrelaKjQYsM2zhWjU9124cErGFvu7m+qtqpsoxNgZU5
	JpSn7yY4u2zMiFa12EjDIimwgCyYsEXGpDc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	GLgbQflkEhHAb9mip2l53eH3alw=; b=ldQnJCKhyoKnvKvROvryYN7csSVdzF/3
	efZXWM+6QOM67mNhx7w52VlhyKCS54+VBqJyfJVBH3CYgX3Qa0IzXI5QuIZ5ysIA
	FIECT92w1d1uqso+bMPM4AedBnhb9CmcvoTzIkduhyfBc/2Cjdp2lsm4zXILZCXs
	H0B7lDZu9Eg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 4725A76C06E; 
	Wed,  1 Feb 2012 12:49:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 1 Feb 2012 12:49:24 -0800
Message-ID: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
Date: Wed, 1 Feb 2012 12:49:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 tim@xen.org,
 keir@xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: [Xen-devel] Domain relinquish resources racing with p2m access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So we've run into this interesting (race?) condition while doing
stress-testing. We pummel the domain with paging, sharing and mmap
operations from dom0, and concurrently we launch a domain destruction.
Often we get in the logs something along these lines

(XEN) mm.c:958:d0 Error getting mfn 859b1a (pfn ffffffffffffffff) from L1
entry 8000000859b1a625 for l1e_owner=0, pg_owner=1

We're using the synchronized p2m patches just posted, so my analysis is as
follows:

- the domain destroy domctl kicks in. It calls relinquish resources. This
disowns and puts most domain pages, resulting in invalid (0xff...ff) m2p
entries

- In parallel, a do_mmu_update is making progress, it has no issues
performing a p2m lookup because the p2m has not been torn down yet; we
haven't gotten to the RCU callback. Eventually, the mapping fails in
page_get_owner in get_pafe_from_l1e.

The map is failed, as expected, but what makes me uneasy is the fact that
there is a still active p2m lurking around, with seemingly valid
translations to valid mfn's, while all the domain pages are gone.

Is this a race condition? Can this lead to trouble?

Thanks!
Andres


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 20:50:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 20: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.xensource.com>)
	id 1Rsh7V-00054P-8S; Wed, 01 Feb 2012 20:49:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rsh7T-00054E-Np
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 20:49:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328129365!13259739!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMjAzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18643 invoked from network); 1 Feb 2012 20:49:25 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-182.messagelabs.com with SMTP;
	1 Feb 2012 20:49:25 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 6A1DF76C07F;
	Wed,  1 Feb 2012 12:49:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=DsdXP1F7
	qO2YJXSW7aTHEnHviARhwJnVmcv7LA+HiR5bkTrIDH6SLyoENaN+Dsn72DRpKLOv
	zzqMewKcojEvAFjIIh0FIIrelaKjQYsM2zhWjU9124cErGFvu7m+qtqpsoxNgZU5
	JpSn7yY4u2zMiFa12EjDIimwgCyYsEXGpDc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	GLgbQflkEhHAb9mip2l53eH3alw=; b=ldQnJCKhyoKnvKvROvryYN7csSVdzF/3
	efZXWM+6QOM67mNhx7w52VlhyKCS54+VBqJyfJVBH3CYgX3Qa0IzXI5QuIZ5ysIA
	FIECT92w1d1uqso+bMPM4AedBnhb9CmcvoTzIkduhyfBc/2Cjdp2lsm4zXILZCXs
	H0B7lDZu9Eg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 4725A76C06E; 
	Wed,  1 Feb 2012 12:49:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 1 Feb 2012 12:49:24 -0800
Message-ID: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
Date: Wed, 1 Feb 2012 12:49:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 tim@xen.org,
 keir@xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: [Xen-devel] Domain relinquish resources racing with p2m access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So we've run into this interesting (race?) condition while doing
stress-testing. We pummel the domain with paging, sharing and mmap
operations from dom0, and concurrently we launch a domain destruction.
Often we get in the logs something along these lines

(XEN) mm.c:958:d0 Error getting mfn 859b1a (pfn ffffffffffffffff) from L1
entry 8000000859b1a625 for l1e_owner=0, pg_owner=1

We're using the synchronized p2m patches just posted, so my analysis is as
follows:

- the domain destroy domctl kicks in. It calls relinquish resources. This
disowns and puts most domain pages, resulting in invalid (0xff...ff) m2p
entries

- In parallel, a do_mmu_update is making progress, it has no issues
performing a p2m lookup because the p2m has not been torn down yet; we
haven't gotten to the RCU callback. Eventually, the mapping fails in
page_get_owner in get_pafe_from_l1e.

The map is failed, as expected, but what makes me uneasy is the fact that
there is a still active p2m lurking around, with seemingly valid
translations to valid mfn's, while all the domain pages are gone.

Is this a race condition? Can this lead to trouble?

Thanks!
Andres


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RshaM-0005xL-O4; Wed, 01 Feb 2012 21:19:22 +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 1RshaL-0005xC-Jh
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:19:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328131122!50713835!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyMjcwOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18360 invoked from network); 1 Feb 2012 21:18:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 21:18:43 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q11LJHV4022297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 1 Feb 2012 21:19:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q11LJHWY006314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 1 Feb 2012 21:19:17 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
	q11LJGHV024769; Wed, 1 Feb 2012 15:19:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 01 Feb 2012 13:19:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7050E4047A; Wed,  1 Feb 2012 16:16:43 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 16:16:38 -0500
Message-Id: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F29AC56.00BC,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [PATCH] small fixes to 3.3 (and 3.2) CPU hotplug code.
	(v1)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While I was playing with 'xm vcpu-set X N' I realized that the VCPU hotplug
code in 3.2 spews tons of messages. Found out that we were missing an preempt_*
call. While at it, I fixed also an annoying message ("XENBUS: Unable to ..")
that shows up during bootup.

Anyhow, these are going for 3.3 and CC-ing stable on the:
 [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG:


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RshaM-0005xL-O4; Wed, 01 Feb 2012 21:19:22 +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 1RshaL-0005xC-Jh
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:19:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328131122!50713835!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyMjcwOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18360 invoked from network); 1 Feb 2012 21:18:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 21:18:43 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q11LJHV4022297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 1 Feb 2012 21:19:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q11LJHWY006314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 1 Feb 2012 21:19:17 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
	q11LJGHV024769; Wed, 1 Feb 2012 15:19:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 01 Feb 2012 13:19:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7050E4047A; Wed,  1 Feb 2012 16:16:43 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 16:16:38 -0500
Message-Id: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F29AC56.00BC,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [PATCH] small fixes to 3.3 (and 3.2) CPU hotplug code.
	(v1)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While I was playing with 'xm vcpu-set X N' I realized that the VCPU hotplug
code in 3.2 spews tons of messages. Found out that we were missing an preempt_*
call. While at it, I fixed also an annoying message ("XENBUS: Unable to ..")
that shows up during bootup.

Anyhow, these are going for 3.3 and CC-ing stable on the:
 [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG:


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RshaT-0005xt-Gs; Wed, 01 Feb 2012 21:19:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RshaS-0005xI-1G
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:19:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328131160!8868609!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyMjcwOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22076 invoked from network); 1 Feb 2012 21:19:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 21:19:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q11LJJOs022323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 1 Feb 2012 21:19:20 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
	q11LJIhr007259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 1 Feb 2012 21:19:18 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
	q11LJHfZ024775; Wed, 1 Feb 2012 15:19:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 01 Feb 2012 13:19:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8355740B34; Wed,  1 Feb 2012 16:16:44 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 16:16:40 -0500
Message-Id: <1328131000-13485-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
References: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F29AC58.0052,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/bootup: During bootup suppress XENBUS:
	Unable to read cpu state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When the initial domain starts, it prints (depending on the
amount of CPUs) a slew of
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state

which provide no useful information - as the error is a valid
issue - but not on the initial domain. The reason is that the
XenStore is not accessible at that time (it is after all the
first guest) so the CPU hotplug watch cannot parse "availability/cpu"
attribute.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/cpu_hotplug.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 14e2d99..4dcfced 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -30,7 +30,8 @@ static int vcpu_online(unsigned int cpu)
 	sprintf(dir, "cpu/%u", cpu);
 	err = xenbus_scanf(XBT_NIL, dir, "availability", "%s", state);
 	if (err != 1) {
-		printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
+		if (!xen_initial_domain())
+			printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
 		return err;
 	}
 
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RshaT-0005xt-Gs; Wed, 01 Feb 2012 21:19:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RshaS-0005xI-1G
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:19:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328131160!8868609!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyMjcwOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22076 invoked from network); 1 Feb 2012 21:19:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 21:19:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q11LJJOs022323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 1 Feb 2012 21:19:20 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
	q11LJIhr007259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 1 Feb 2012 21:19:18 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
	q11LJHfZ024775; Wed, 1 Feb 2012 15:19:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 01 Feb 2012 13:19:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8355740B34; Wed,  1 Feb 2012 16:16:44 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 16:16:40 -0500
Message-Id: <1328131000-13485-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
References: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F29AC58.0052,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/bootup: During bootup suppress XENBUS:
	Unable to read cpu state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When the initial domain starts, it prints (depending on the
amount of CPUs) a slew of
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state
XENBUS: Unable to read cpu state

which provide no useful information - as the error is a valid
issue - but not on the initial domain. The reason is that the
XenStore is not accessible at that time (it is after all the
first guest) so the CPU hotplug watch cannot parse "availability/cpu"
attribute.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/cpu_hotplug.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 14e2d99..4dcfced 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -30,7 +30,8 @@ static int vcpu_online(unsigned int cpu)
 	sprintf(dir, "cpu/%u", cpu);
 	err = xenbus_scanf(XBT_NIL, dir, "availability", "%s", state);
 	if (err != 1) {
-		printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
+		if (!xen_initial_domain())
+			printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
 		return err;
 	}
 
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:19:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21: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.xensource.com>)
	id 1RshaS-0005xf-4C; Wed, 01 Feb 2012 21:19:28 +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 1RshaQ-0005xD-Jk
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:19:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328131090!62203695!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDQ1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 822 invoked from network); 1 Feb 2012 21:18:11 -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; 1 Feb 2012 21:18:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q11LJIib022303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 1 Feb 2012 21:19:18 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
	q11LJHhb024493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 1 Feb 2012 21:19:18 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
	q11LJH3Y022072; Wed, 1 Feb 2012 15:19:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 01 Feb 2012 13:19:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 79C784047A; Wed,  1 Feb 2012 16:16:44 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 16:16:39 -0500
Message-Id: <1328131000-13485-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
References: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F29AC57.0006,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] xen/smp: Fix CPU online/offline bug
	triggering a BUG: scheduling while atomic.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a user offlines a VCPU and then onlines it, we get:

NMI watchdog disabled (cpu2): hardware events not enabled
BUG: scheduling while atomic: swapper/2/0/0x00000002
Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod libcrc32c crc32c radeon fbco
 ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:

Pid: 0, comm: swapper/2 Tainted: G           O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
Call Trace:
 [<ffffffff81070571>] __schedule_bug+0x61/0x70
 [<ffffffff8158eb78>] __schedule+0x798/0x850
 [<ffffffff8158ed6a>] schedule+0x3a/0x50
 [<ffffffff810349be>] cpu_idle+0xbe/0xe0
 [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10

The reason for this should be obvious from this call-chain:
cpu_bringup_and_idle:
 \- cpu_bringup
  |   \-[preempt_disable]
  |
  |- cpu_idle
       \- play_dead [assuming the user offlined the VCPU]
       |     \
       |     +- (xen_play_dead)
       |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
       |          |                       onlines it starts from here]
       |          \- cpu_bringup [preempt_disable]
       |
       +- preempt_enable_no_reschedule()
       +- schedule()
       \- preempt_enable()

So we have two preempt_disble() and one preempt_enable(). Calling
preempt_enable() after the cpu_bringup() in the xen_play_dead
fixes the imbalance.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/smp.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 041d4fe..501d4e0 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -409,6 +409,13 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
 	play_dead_common();
 	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
 	cpu_bringup();
+	/*
+	 * Balance out the preempt calls - as we are running in cpu_idle
+	 * loop which has been called at bootup from cpu_bringup_and_idle.
+	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
+	 * preempt_disable() So this preempt_enable will balance it out.
+	 */
+	preempt_enable();
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:19:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21: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.xensource.com>)
	id 1RshaS-0005xf-4C; Wed, 01 Feb 2012 21:19:28 +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 1RshaQ-0005xD-Jk
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:19:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328131090!62203695!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDQ1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 822 invoked from network); 1 Feb 2012 21:18:11 -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; 1 Feb 2012 21:18:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q11LJIib022303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 1 Feb 2012 21:19:18 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
	q11LJHhb024493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 1 Feb 2012 21:19:18 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
	q11LJH3Y022072; Wed, 1 Feb 2012 15:19:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 01 Feb 2012 13:19:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 79C784047A; Wed,  1 Feb 2012 16:16:44 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed,  1 Feb 2012 16:16:39 -0500
Message-Id: <1328131000-13485-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
References: <1328131000-13485-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F29AC57.0006,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] xen/smp: Fix CPU online/offline bug
	triggering a BUG: scheduling while atomic.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a user offlines a VCPU and then onlines it, we get:

NMI watchdog disabled (cpu2): hardware events not enabled
BUG: scheduling while atomic: swapper/2/0/0x00000002
Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod libcrc32c crc32c radeon fbco
 ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:

Pid: 0, comm: swapper/2 Tainted: G           O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
Call Trace:
 [<ffffffff81070571>] __schedule_bug+0x61/0x70
 [<ffffffff8158eb78>] __schedule+0x798/0x850
 [<ffffffff8158ed6a>] schedule+0x3a/0x50
 [<ffffffff810349be>] cpu_idle+0xbe/0xe0
 [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10

The reason for this should be obvious from this call-chain:
cpu_bringup_and_idle:
 \- cpu_bringup
  |   \-[preempt_disable]
  |
  |- cpu_idle
       \- play_dead [assuming the user offlined the VCPU]
       |     \
       |     +- (xen_play_dead)
       |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
       |          |                       onlines it starts from here]
       |          \- cpu_bringup [preempt_disable]
       |
       +- preempt_enable_no_reschedule()
       +- schedule()
       \- preempt_enable()

So we have two preempt_disble() and one preempt_enable(). Calling
preempt_enable() after the cpu_bringup() in the xen_play_dead
fixes the imbalance.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/smp.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 041d4fe..501d4e0 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -409,6 +409,13 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
 	play_dead_common();
 	HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
 	cpu_bringup();
+	/*
+	 * Balance out the preempt calls - as we are running in cpu_idle
+	 * loop which has been called at bootup from cpu_bringup_and_idle.
+	 * The cpucpu_bringup_and_idle called cpu_bringup which made a
+	 * preempt_disable() So this preempt_enable will balance it out.
+	 */
+	preempt_enable();
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:27:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21: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.xensource.com>)
	id 1Rshi5-0006e0-FL; Wed, 01 Feb 2012 21:27:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rshi4-0006dv-1v
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:27:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328131633!4666982!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4Mzc1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13573 invoked from network); 1 Feb 2012 21:27:13 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-16.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 21:27:13 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 2430930007B;
	Wed,  1 Feb 2012 13:27:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=rNz3WQG2DljfPcJ2Daw9m6L9Bhdfzl7pLJMBcLAnlZ11
	OZuvpA7F9b6LR5iby6kUd9h4ypjDZp7Errd9NyPGGah88H/Z4udnvS6aCfqyEki6
	5GJARRIloTMTeVcV9Vn29uJum0cN24kerAFHQEt/M+Q1KamwHCJCnxCNgUa1MRs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=FtmnCfXwScm1DW+gQGM7YT8BsVk=; b=Rlpj1zNS
	vmtZEY5pJdpTbzAhSfzssvWeqHxT+8KWgf0SJaaigB6JHtonWGZck035SycaMWuI
	DnnvDdI4DM5w8FjPg7XYmSpuWXQVuvGPrCBahEGYj+ZMhis8phWAWe7O+dr42ZK4
	noPvUsM3nW92vOEdqrtwZA9w09SjKzWv8QQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id D7818300064; 
	Wed,  1 Feb 2012 13:27:12 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 1 Feb 2012 13:27:13 -0800
Message-ID: <281657402b3bef225c5a60183324d531.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2283.1328119723.1471.xen-devel@lists.xensource.com>
References: <mailman.2283.1328119723.1471.xen-devel@lists.xensource.com>
Date: Wed, 1 Feb 2012 13:27:13 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: agent.peter123@gmail.com
Subject: Re: [Xen-devel] Xen Mem Page Sharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 1 Feb 2012 13:05:55 -0500
> From: Peter Deng <agent.peter123@gmail.com>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Xen Mem Page Sharing
> Message-ID:
> 	<CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QOdDodKoYdTR-Q@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I'm am looking into and doing some research on Memory Page Sharing on Xen,
> and I would like to know the current activity status regarding Xen's
> memory
> management. Also, while looking through the source code, I am having some
> trouble translating some of the functions, notably in mem_sharing.c, and
> one function I would like to have explained is mem_sharing_audit(). One
> that note, is there recent documentation on Xen code or do I need to trace
> the logs to determine development changes?

Quite recently we effectively overhauled all the sharing support in the
hypervisor. So it's best you check out the latest xen-unstable tree.

The interface is relatively simple. You identify a page that is a
candidate for sharing and you call nominate(domain, gfn). You get back a
64 bit handle. This is a unique identifier for this *version* of this
guest page. Should the page change (writes) the handle won't be valid
anymore.

Once you have two candidates you can coalesce them by calling
share(source_domain, source_gfn, source_handle, client_domain, client_gfn,
client_handle). Voila! you've shared and saved memory. You can reshare (to
coalesce > 2 guest pages into a single backing shared page), but keep in
mind that the client gfn and handle won't be valid anymore for further
sharing.

All the user-space visible code is in tools/libxc/xc_memshr.c, with
prototypes in tools/libxc/xenctrl.h. As you found out, the hypervisor code
is in arch/x86/mm/mem_sharing.c

It is crucial to understand that the hypervisor won't check the contents
of the pages. If you select the wrong candidates for sharing, you will
crash your guest(s). However, the hypervisor will ensure that pages are
properly unshared when writes happen.

Hope this helps, agent Peter!
Andres
>
> Thanks,
>
> Peter



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 21:27:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 21: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.xensource.com>)
	id 1Rshi5-0006e0-FL; Wed, 01 Feb 2012 21:27:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rshi4-0006dv-1v
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:27:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328131633!4666982!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4Mzc1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13573 invoked from network); 1 Feb 2012 21:27:13 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-16.tower-21.messagelabs.com with SMTP;
	1 Feb 2012 21:27:13 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 2430930007B;
	Wed,  1 Feb 2012 13:27:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=rNz3WQG2DljfPcJ2Daw9m6L9Bhdfzl7pLJMBcLAnlZ11
	OZuvpA7F9b6LR5iby6kUd9h4ypjDZp7Errd9NyPGGah88H/Z4udnvS6aCfqyEki6
	5GJARRIloTMTeVcV9Vn29uJum0cN24kerAFHQEt/M+Q1KamwHCJCnxCNgUa1MRs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=FtmnCfXwScm1DW+gQGM7YT8BsVk=; b=Rlpj1zNS
	vmtZEY5pJdpTbzAhSfzssvWeqHxT+8KWgf0SJaaigB6JHtonWGZck035SycaMWuI
	DnnvDdI4DM5w8FjPg7XYmSpuWXQVuvGPrCBahEGYj+ZMhis8phWAWe7O+dr42ZK4
	noPvUsM3nW92vOEdqrtwZA9w09SjKzWv8QQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id D7818300064; 
	Wed,  1 Feb 2012 13:27:12 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Wed, 1 Feb 2012 13:27:13 -0800
Message-ID: <281657402b3bef225c5a60183324d531.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2283.1328119723.1471.xen-devel@lists.xensource.com>
References: <mailman.2283.1328119723.1471.xen-devel@lists.xensource.com>
Date: Wed, 1 Feb 2012 13:27:13 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: agent.peter123@gmail.com
Subject: Re: [Xen-devel] Xen Mem Page Sharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 1 Feb 2012 13:05:55 -0500
> From: Peter Deng <agent.peter123@gmail.com>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Xen Mem Page Sharing
> Message-ID:
> 	<CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QOdDodKoYdTR-Q@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I'm am looking into and doing some research on Memory Page Sharing on Xen,
> and I would like to know the current activity status regarding Xen's
> memory
> management. Also, while looking through the source code, I am having some
> trouble translating some of the functions, notably in mem_sharing.c, and
> one function I would like to have explained is mem_sharing_audit(). One
> that note, is there recent documentation on Xen code or do I need to trace
> the logs to determine development changes?

Quite recently we effectively overhauled all the sharing support in the
hypervisor. So it's best you check out the latest xen-unstable tree.

The interface is relatively simple. You identify a page that is a
candidate for sharing and you call nominate(domain, gfn). You get back a
64 bit handle. This is a unique identifier for this *version* of this
guest page. Should the page change (writes) the handle won't be valid
anymore.

Once you have two candidates you can coalesce them by calling
share(source_domain, source_gfn, source_handle, client_domain, client_gfn,
client_handle). Voila! you've shared and saved memory. You can reshare (to
coalesce > 2 guest pages into a single backing shared page), but keep in
mind that the client gfn and handle won't be valid anymore for further
sharing.

All the user-space visible code is in tools/libxc/xc_memshr.c, with
prototypes in tools/libxc/xenctrl.h. As you found out, the hypervisor code
is in arch/x86/mm/mem_sharing.c

It is crucial to understand that the hypervisor won't check the contents
of the pages. If you select the wrong candidates for sharing, you will
crash your guest(s). However, the hypervisor will ensure that pages are
properly unshared when writes happen.

Hope this helps, agent Peter!
Andres
>
> Thanks,
>
> Peter



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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 22:33:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 22: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.xensource.com>)
	id 1Rsija-00081a-Gz; Wed, 01 Feb 2012 22:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RsijY-00081Q-Ug
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 22:32:57 +0000
Received: from [85.158.138.51:21498] by server-11.bemta-3.messagelabs.com id
	A5/21-21643-89DB92F4; Wed, 01 Feb 2012 22:32:56 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328135573!9767580!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzOTUw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20486 invoked from network); 1 Feb 2012 22:32:54 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-174.messagelabs.com with SMTP;
	1 Feb 2012 22:32:54 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 01 Feb 2012 14:32:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105161821"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by orsmga002.jf.intel.com with ESMTP; 01 Feb 2012 14:32:53 -0800
Received: from orsmsx103.amr.corp.intel.com (10.22.225.130) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 1 Feb 2012 14:32:51 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.3]) by
	ORSMSX103.amr.corp.intel.com ([169.254.2.175]) with mapi id
	14.01.0355.002; Wed, 1 Feb 2012 14:32:51 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/2] qemu-xen: Intel GPU passthrough
Thread-Index: AQHM4Ee75/rim/f1mEKeG2G7LWq5R5YooNRQ
Date: Wed, 1 Feb 2012 22:32:51 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD40A3F18@ORSMSX105.amr.corp.intel.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
In-Reply-To: <1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
Content-Type: multipart/mixed;
	boundary="_002_003AAFE53969E14CB1F09B6FD68C3CD40A3F18ORSMSX105amrcorpi_"
MIME-Version: 1.0
Cc: "Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

SGkgSmVhbiwNCg0KSSBoYXZlIGZvbGxvd2luZyBxdWVzdGlvbnMgYWJvdXQgdGhlIHBhdGNoOg0K
DQoxKSBIb3cgaXMgdGhlIG5ldyBmdW5jdGlvbiBwdF9wY2lfaG9zdF9tYXBfYmFyKCkgdXNlZD8g
IEkgc2VlIGZ1bmN0aW9uIGRlZmluaXRpb24gYnV0IGRvIG5vdCBzZWUgd2hlcmUgaXQgaXMgY2Fs
bGVkLg0KDQoyKSBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHB0X2dyYXBoaWNfYmFyX3JlbWFwKCk/
ICBJdCBzZWVtcyB0byBiZSBkZWZpbmVkIGFzIE5VTEwgYXMgc2hvd24gYmVsb3cuDQoNCi8qDQor
ICogQ2FsbGJhY2sgd2hlbmV2ZXIgYSBiYXIgZ2V0IHJlbWFwcGVkDQorICovDQordm9pZCBwdF9n
cmFwaGljX2Jhcl9yZW1hcChzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSwgaW50IGJhciwgaW50
IGZpcnN0X21hcCwgaW50IG1hcCkNCit7DQorfQ0KDQpBbGxlbg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogSmVhbiBHdXlhZGVyIFttYWlsdG86amVhbi5ndXlhZGVyQGV1LmNp
dHJpeC5jb21dIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAzMSwgMjAxMiAxMDo0MCBBTQ0KVG86
IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tDQpDYzogS2F5LCBBbGxlbiBNOyBJYW4uSmFj
a3NvbkBldS5jaXRyaXguY29tOyBKZWFuIEd1eWFkZXINClN1YmplY3Q6IFtQQVRDSCAyLzJdIHFl
bXUteGVuOiBJbnRlbCBHUFUgcGFzc3Rocm91Z2gNCg0KDQpSZXNldCBJbnRlbCBHUFUgZmVuY2Vz
IHdoZW4gdGhlIGRvbWFpbiBzdGFydHMgKGZpcnN0IG1hcHBpbmcgb2YgQmFyMCkuDQoNClNpZ25l
ZC1vZmYtYnk6IEplYW4gR3V5YWRlciA8amVhbi5ndXlhZGVyQGV1LmNpdHJpeC5jb20+DQotLS0N
CiBody9wdC1ncmFwaGljcy5jIHwgIDEzMyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysNCiAxIGZpbGVzIGNoYW5nZWQsIDEzMyBpbnNlcnRpb25z
KCspLCAwIGRlbGV0aW9ucygtKQ0KDQo=

--_002_003AAFE53969E14CB1F09B6FD68C3CD40A3F18ORSMSX105amrcorpi_
Content-Type: application/octet-stream;
	name="0001-qemu-xen-Pass-through-utility-functions.patch"
Content-Description: 0001-qemu-xen-Pass-through-utility-functions.patch
Content-Disposition: attachment;
	filename="0001-qemu-xen-Pass-through-utility-functions.patch"; size=3913;
	creation-date="Wed, 01 Feb 2012 22:31:40 GMT";
	modification-date="Wed, 01 Feb 2012 22:31:40 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMNCmluZGV4
IGRiZTg4MDQuLjFiZGIyMjMgMTAwNjQ0DQotLS0gYS9ody9wYXNzLXRocm91Z2guYw0KKysrIGIv
aHcvcGFzcy10aHJvdWdoLmMNCkBAIC05Myw2ICs5Myw3IEBADQogI2luY2x1ZGUgPHVuaXN0ZC5o
Pg0KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4NCiAjaW5jbHVkZSA8YXNzZXJ0Lmg+DQorI2luY2x1
ZGUgPHN5cy9tbWFuLmg+DQogDQogZXh0ZXJuIGludCBnZnhfcGFzc3RocnU7DQogaW50IGlnZF9w
YXNzdGhydSA9IDA7DQpAQCAtMTE1NSw2ICsxMTU2LDkgQEAgc3RhdGljIHZvaWQgcHRfaW9tZW1f
bWFwKFBDSURldmljZSAqZCwgaW50IGksIHVpbnQzMl90IGVfcGh5cywgdWludDMyX3QgZV9zaXpl
LA0KICAgICBpZiAoIGVfc2l6ZSA9PSAwICkNCiAgICAgICAgIHJldHVybjsNCiANCisgICAgaWYg
KGFzc2lnbmVkX2RldmljZS0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzID09IDB4MDMwMCkNCisgICAg
ICAgIHB0X2dyYXBoaWNfYmFyX3JlbWFwKGFzc2lnbmVkX2RldmljZSwgaSwgZmlyc3RfbWFwLCBE
UENJX0FERF9NQVBQSU5HKTsNCisNCiAgICAgaWYgKCAhZmlyc3RfbWFwICYmIG9sZF9lYmFzZSAh
PSAtMSApDQogICAgIHsNCiAgICAgICAgIGlmICggaGFzX21zaXhfbWFwcGluZyhhc3NpZ25lZF9k
ZXZpY2UsIGkpICkNCkBAIC0xOTY5LDYgKzE5NzMsOSBAQCBzdGF0aWMgdm9pZCBwdF91bnJlZ2lz
dGVyX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqYXNzaWduZWRfZGV2aWNlKQ0KICAgICAgICAgaWYg
KCB0eXBlID09IFBDSV9BRERSRVNTX1NQQUNFX01FTSB8fA0KICAgICAgICAgICAgICB0eXBlID09
IFBDSV9BRERSRVNTX1NQQUNFX01FTV9QUkVGRVRDSCApDQogICAgICAgICB7DQorICAgICAgICAg
ICAgaWYgKGFzc2lnbmVkX2RldmljZS0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzID09IDB4MDMwMCkN
CisgICAgICAgICAgICAgICAgcHRfZ3JhcGhpY19iYXJfcmVtYXAoYXNzaWduZWRfZGV2aWNlLCBp
LCAwLCBEUENJX1JFTU9WRV9NQVBQSU5HKTsNCisNCiAgICAgICAgICAgICByZXQgPSB4Y19kb21h
aW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwNCiAgICAgICAgICAgICAgICAgICAg
IGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFzZSA+PiBYQ19QQUdFX1NISUZULA0K
ICAgICAgICAgICAgICAgICAgICAgYXNzaWduZWRfZGV2aWNlLT5iYXNlc1tpXS5hY2Nlc3MubWFk
ZHIgPj4gWENfUEFHRV9TSElGVCwNCkBAIC0yMTAxLDYgKzIxMDgsMzMgQEAgaW50IHB0X3BjaV9o
b3N0X3dyaXRlKHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2LCB1MzIgYWRkciwgdTMyIHZhbCwgaW50
IGxlbikNCiAgICAgcmV0dXJuIHJldDsNCiB9DQogDQoraW50IHB0X3BjaV9ob3N0X21hcF9iYXIo
c3RydWN0IHB0X2RldiAqcHRfZGV2LCBpbnQgYmFyKQ0KK3sNCisgICAgaW50IGZkOw0KKyAgICBz
dHJ1Y3Qgc3RhdCBzOw0KKyAgICB1aW50OF90ICptYXA7DQorDQorICAgIGNoYXIgZmlsZW5hbWVb
MTAyNF07DQorDQorICAgIHNucHJpbnRmKGZpbGVuYW1lLCAxMDI0LCAiL3N5cy9idXMvcGNpL2Rl
dmljZXMvMDAwMDolMDJ4OiUwMnguJTAxeC9yZXNvdXJjZSVkIiwNCisgICAgICAgICAgICBwdF9k
ZXYtPnBjaV9kZXYtPmJ1cywNCisgICAgICAgICAgICBwdF9kZXYtPnBjaV9kZXYtPmRldiwNCisg
ICAgICAgICAgICBwdF9kZXYtPnBjaV9kZXYtPmZ1bmMsDQorICAgICAgICAgICAgYmFyKTsNCisg
ICAgZmQgPSBvcGVuKGZpbGVuYW1lLCBPX1JEV1IgfCBPX1NZTkMpOw0KKyAgICBpZiAoZmQgPCAw
KQ0KKyAgICAgICAgcmV0dXJuIGZkOw0KKyAgICBmc3RhdChmZCwgJnMpOw0KKw0KKyAgICBtYXAg
PSBtbWFwKDAsIHMuc3Rfc2l6ZSwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwgTUFQX1NIQVJFRCwg
ZmQsIDApOw0KKyAgICBpZiAobWFwICE9IE1BUF9GQUlMRUQpDQorICAgIHsNCisgICAgICAgIHB0
X2Rldi0+YmFzZXNbYmFyXS5tYXAgPSBtYXA7DQorICAgICAgICByZXR1cm4gMDsNCisgICAgfQ0K
KyAgICByZXR1cm4gZXJybm87DQorfQ0KKw0KIC8qIHBhcnNlIEJBUiAqLw0KIHN0YXRpYyBpbnQg
cHRfYmFyX3JlZ19wYXJzZSgNCiAgICAgICAgIHN0cnVjdCBwdF9kZXYgKnB0ZGV2LCBzdHJ1Y3Qg
cHRfcmVnX2luZm9fdGJsICpyZWcpDQpkaWZmIC0tZ2l0IGEvaHcvcGFzcy10aHJvdWdoLmggYi9o
dy9wYXNzLXRocm91Z2guaA0KaW5kZXggODg0MTM5Yy4uMjZlNmZmMSAxMDA2NDQNCi0tLSBhL2h3
L3Bhc3MtdGhyb3VnaC5oDQorKysgYi9ody9wYXNzLXRocm91Z2guaA0KQEAgLTE3MCw2ICsxNzAs
NyBAQCBzdHJ1Y3QgcHRfcmVnaW9uIHsNCiAgICAgICAgIHVpbnQ2NF90IHBpb19iYXNlOw0KICAg
ICAgICAgdWludDY0X3QgdTsNCiAgICAgfSBhY2Nlc3M7DQorICAgIHVpbnQ4X3QgKm1hcDsNCiB9
Ow0KIA0KIHN0cnVjdCBwdF9tc2lfaW5mbyB7DQpAQCAtNDE0LDYgKzQxNSw3IEBAIHVpbnQ4X3Qg
cGNpX2ludHgoc3RydWN0IHB0X2RldiAqcHRkZXYpOw0KIHN0cnVjdCBwY2lfZGV2ICpwdF9wY2lf
Z2V0X2RldihpbnQgYnVzLCBpbnQgZGV2LCBpbnQgZnVuYyk7DQogdTMyIHB0X3BjaV9ob3N0X3Jl
YWQoc3RydWN0IHBjaV9kZXYgKnBjaV9kZXYsIHUzMiBhZGRyLCBpbnQgbGVuKTsNCiBpbnQgcHRf
cGNpX2hvc3Rfd3JpdGUoc3RydWN0IHBjaV9kZXYgKnBjaV9kZXYsIHUzMiBhZGRyLCB1MzIgdmFs
LCBpbnQgbGVuKTsNCitpbnQgcHRfcGNpX2hvc3RfbWFwX2JhcihzdHJ1Y3QgcHRfZGV2ICpwdF9k
ZXYsIGludCBiYXIpOw0KIHZvaWQgaW50ZWxfcGNoX2luaXQoUENJQnVzICpidXMpOw0KIGludCBy
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSk7DQogaW50IHVu
cmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpOw0KQEAgLTQy
Miw2ICs0MjQsNyBAQCBQQ0lCdXMgKmludGVsX3BjaV9icmlkZ2VfaW5pdChQQ0lCdXMgKmJ1cywg
aW50IGRldmZuLCB1aW50MTZfdCB2aWQsDQogICAgICAgICAgICB1aW50MTZfdCBkaWQsIGNvbnN0
IGNoYXIgKm5hbWUsIHVpbnQxNl90IHJldmlzaW9uKTsNCiB2b2lkIGlnZF9wY2lfd3JpdGUoUENJ
RGV2aWNlICpwY2lfZGV2LCB1aW50MzJfdCBjb25maWdfYWRkciwgdWludDMyX3QgdmFsLCBpbnQg
bGVuKTsNCiB1aW50MzJfdCBpZ2RfcGNpX3JlYWQoUENJRGV2aWNlICpwY2lfZGV2LCB1aW50MzJf
dCBjb25maWdfYWRkciwgaW50IGxlbik7DQordm9pZCBwdF9ncmFwaGljX2Jhcl9yZW1hcChzdHJ1
Y3QgcHRfZGV2ICpyZWFsX2RldmljZSwgaW50IGJhciwgaW50IGZpcnN0X21hcCwgaW50IG1hcCk7
DQogDQogI2VuZGlmIC8qIF9fUEFTU1RIUk9VR0hfSF9fICovDQogDQpkaWZmIC0tZ2l0IGEvaHcv
cHQtZ3JhcGhpY3MuYyBiL2h3L3B0LWdyYXBoaWNzLmMNCmluZGV4IGZlYzczOTAuLjVkNWU1ZGEg
MTAwNjQ0DQotLS0gYS9ody9wdC1ncmFwaGljcy5jDQorKysgYi9ody9wdC1ncmFwaGljcy5jDQpA
QCAtOTQsNiArOTQsMTMgQEAgdWludDMyX3QgaWdkX3BjaV9yZWFkKFBDSURldmljZSAqcGNpX2Rl
diwgdWludDMyX3QgY29uZmlnX2FkZHIsIGludCBsZW4pDQogfQ0KIA0KIC8qDQorICogQ2FsbGJh
Y2sgd2hlbmV2ZXIgYSBiYXIgZ2V0IHJlbWFwcGVkDQorICovDQordm9pZCBwdF9ncmFwaGljX2Jh
cl9yZW1hcChzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSwgaW50IGJhciwgaW50IGZpcnN0X21h
cCwgaW50IG1hcCkNCit7DQorfQ0KKw0KKy8qDQogICogcmVnaXN0ZXIgVkdBIHJlc291cmNlcyBm
b3IgdGhlIGRvbWFpbiB3aXRoIGFzc2lnbmVkIGdmeA0KICAqLw0KIGludCByZWdpc3Rlcl92Z2Ff
cmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkNCg==

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

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

--_002_003AAFE53969E14CB1F09B6FD68C3CD40A3F18ORSMSX105amrcorpi_--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 22:33:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 22: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.xensource.com>)
	id 1Rsija-00081a-Gz; Wed, 01 Feb 2012 22:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RsijY-00081Q-Ug
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 22:32:57 +0000
Received: from [85.158.138.51:21498] by server-11.bemta-3.messagelabs.com id
	A5/21-21643-89DB92F4; Wed, 01 Feb 2012 22:32:56 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328135573!9767580!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzOTUw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20486 invoked from network); 1 Feb 2012 22:32:54 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-174.messagelabs.com with SMTP;
	1 Feb 2012 22:32:54 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 01 Feb 2012 14:32:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105161821"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by orsmga002.jf.intel.com with ESMTP; 01 Feb 2012 14:32:53 -0800
Received: from orsmsx103.amr.corp.intel.com (10.22.225.130) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 1 Feb 2012 14:32:51 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.3]) by
	ORSMSX103.amr.corp.intel.com ([169.254.2.175]) with mapi id
	14.01.0355.002; Wed, 1 Feb 2012 14:32:51 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/2] qemu-xen: Intel GPU passthrough
Thread-Index: AQHM4Ee75/rim/f1mEKeG2G7LWq5R5YooNRQ
Date: Wed, 1 Feb 2012 22:32:51 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD40A3F18@ORSMSX105.amr.corp.intel.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
	<1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
In-Reply-To: <1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.140]
Content-Type: multipart/mixed;
	boundary="_002_003AAFE53969E14CB1F09B6FD68C3CD40A3F18ORSMSX105amrcorpi_"
MIME-Version: 1.0
Cc: "Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

SGkgSmVhbiwNCg0KSSBoYXZlIGZvbGxvd2luZyBxdWVzdGlvbnMgYWJvdXQgdGhlIHBhdGNoOg0K
DQoxKSBIb3cgaXMgdGhlIG5ldyBmdW5jdGlvbiBwdF9wY2lfaG9zdF9tYXBfYmFyKCkgdXNlZD8g
IEkgc2VlIGZ1bmN0aW9uIGRlZmluaXRpb24gYnV0IGRvIG5vdCBzZWUgd2hlcmUgaXQgaXMgY2Fs
bGVkLg0KDQoyKSBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHB0X2dyYXBoaWNfYmFyX3JlbWFwKCk/
ICBJdCBzZWVtcyB0byBiZSBkZWZpbmVkIGFzIE5VTEwgYXMgc2hvd24gYmVsb3cuDQoNCi8qDQor
ICogQ2FsbGJhY2sgd2hlbmV2ZXIgYSBiYXIgZ2V0IHJlbWFwcGVkDQorICovDQordm9pZCBwdF9n
cmFwaGljX2Jhcl9yZW1hcChzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSwgaW50IGJhciwgaW50
IGZpcnN0X21hcCwgaW50IG1hcCkNCit7DQorfQ0KDQpBbGxlbg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogSmVhbiBHdXlhZGVyIFttYWlsdG86amVhbi5ndXlhZGVyQGV1LmNp
dHJpeC5jb21dIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAzMSwgMjAxMiAxMDo0MCBBTQ0KVG86
IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tDQpDYzogS2F5LCBBbGxlbiBNOyBJYW4uSmFj
a3NvbkBldS5jaXRyaXguY29tOyBKZWFuIEd1eWFkZXINClN1YmplY3Q6IFtQQVRDSCAyLzJdIHFl
bXUteGVuOiBJbnRlbCBHUFUgcGFzc3Rocm91Z2gNCg0KDQpSZXNldCBJbnRlbCBHUFUgZmVuY2Vz
IHdoZW4gdGhlIGRvbWFpbiBzdGFydHMgKGZpcnN0IG1hcHBpbmcgb2YgQmFyMCkuDQoNClNpZ25l
ZC1vZmYtYnk6IEplYW4gR3V5YWRlciA8amVhbi5ndXlhZGVyQGV1LmNpdHJpeC5jb20+DQotLS0N
CiBody9wdC1ncmFwaGljcy5jIHwgIDEzMyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysNCiAxIGZpbGVzIGNoYW5nZWQsIDEzMyBpbnNlcnRpb25z
KCspLCAwIGRlbGV0aW9ucygtKQ0KDQo=

--_002_003AAFE53969E14CB1F09B6FD68C3CD40A3F18ORSMSX105amrcorpi_
Content-Type: application/octet-stream;
	name="0001-qemu-xen-Pass-through-utility-functions.patch"
Content-Description: 0001-qemu-xen-Pass-through-utility-functions.patch
Content-Disposition: attachment;
	filename="0001-qemu-xen-Pass-through-utility-functions.patch"; size=3913;
	creation-date="Wed, 01 Feb 2012 22:31:40 GMT";
	modification-date="Wed, 01 Feb 2012 22:31:40 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMNCmluZGV4
IGRiZTg4MDQuLjFiZGIyMjMgMTAwNjQ0DQotLS0gYS9ody9wYXNzLXRocm91Z2guYw0KKysrIGIv
aHcvcGFzcy10aHJvdWdoLmMNCkBAIC05Myw2ICs5Myw3IEBADQogI2luY2x1ZGUgPHVuaXN0ZC5o
Pg0KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4NCiAjaW5jbHVkZSA8YXNzZXJ0Lmg+DQorI2luY2x1
ZGUgPHN5cy9tbWFuLmg+DQogDQogZXh0ZXJuIGludCBnZnhfcGFzc3RocnU7DQogaW50IGlnZF9w
YXNzdGhydSA9IDA7DQpAQCAtMTE1NSw2ICsxMTU2LDkgQEAgc3RhdGljIHZvaWQgcHRfaW9tZW1f
bWFwKFBDSURldmljZSAqZCwgaW50IGksIHVpbnQzMl90IGVfcGh5cywgdWludDMyX3QgZV9zaXpl
LA0KICAgICBpZiAoIGVfc2l6ZSA9PSAwICkNCiAgICAgICAgIHJldHVybjsNCiANCisgICAgaWYg
KGFzc2lnbmVkX2RldmljZS0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzID09IDB4MDMwMCkNCisgICAg
ICAgIHB0X2dyYXBoaWNfYmFyX3JlbWFwKGFzc2lnbmVkX2RldmljZSwgaSwgZmlyc3RfbWFwLCBE
UENJX0FERF9NQVBQSU5HKTsNCisNCiAgICAgaWYgKCAhZmlyc3RfbWFwICYmIG9sZF9lYmFzZSAh
PSAtMSApDQogICAgIHsNCiAgICAgICAgIGlmICggaGFzX21zaXhfbWFwcGluZyhhc3NpZ25lZF9k
ZXZpY2UsIGkpICkNCkBAIC0xOTY5LDYgKzE5NzMsOSBAQCBzdGF0aWMgdm9pZCBwdF91bnJlZ2lz
dGVyX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqYXNzaWduZWRfZGV2aWNlKQ0KICAgICAgICAgaWYg
KCB0eXBlID09IFBDSV9BRERSRVNTX1NQQUNFX01FTSB8fA0KICAgICAgICAgICAgICB0eXBlID09
IFBDSV9BRERSRVNTX1NQQUNFX01FTV9QUkVGRVRDSCApDQogICAgICAgICB7DQorICAgICAgICAg
ICAgaWYgKGFzc2lnbmVkX2RldmljZS0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzID09IDB4MDMwMCkN
CisgICAgICAgICAgICAgICAgcHRfZ3JhcGhpY19iYXJfcmVtYXAoYXNzaWduZWRfZGV2aWNlLCBp
LCAwLCBEUENJX1JFTU9WRV9NQVBQSU5HKTsNCisNCiAgICAgICAgICAgICByZXQgPSB4Y19kb21h
aW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwNCiAgICAgICAgICAgICAgICAgICAg
IGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFzZSA+PiBYQ19QQUdFX1NISUZULA0K
ICAgICAgICAgICAgICAgICAgICAgYXNzaWduZWRfZGV2aWNlLT5iYXNlc1tpXS5hY2Nlc3MubWFk
ZHIgPj4gWENfUEFHRV9TSElGVCwNCkBAIC0yMTAxLDYgKzIxMDgsMzMgQEAgaW50IHB0X3BjaV9o
b3N0X3dyaXRlKHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2LCB1MzIgYWRkciwgdTMyIHZhbCwgaW50
IGxlbikNCiAgICAgcmV0dXJuIHJldDsNCiB9DQogDQoraW50IHB0X3BjaV9ob3N0X21hcF9iYXIo
c3RydWN0IHB0X2RldiAqcHRfZGV2LCBpbnQgYmFyKQ0KK3sNCisgICAgaW50IGZkOw0KKyAgICBz
dHJ1Y3Qgc3RhdCBzOw0KKyAgICB1aW50OF90ICptYXA7DQorDQorICAgIGNoYXIgZmlsZW5hbWVb
MTAyNF07DQorDQorICAgIHNucHJpbnRmKGZpbGVuYW1lLCAxMDI0LCAiL3N5cy9idXMvcGNpL2Rl
dmljZXMvMDAwMDolMDJ4OiUwMnguJTAxeC9yZXNvdXJjZSVkIiwNCisgICAgICAgICAgICBwdF9k
ZXYtPnBjaV9kZXYtPmJ1cywNCisgICAgICAgICAgICBwdF9kZXYtPnBjaV9kZXYtPmRldiwNCisg
ICAgICAgICAgICBwdF9kZXYtPnBjaV9kZXYtPmZ1bmMsDQorICAgICAgICAgICAgYmFyKTsNCisg
ICAgZmQgPSBvcGVuKGZpbGVuYW1lLCBPX1JEV1IgfCBPX1NZTkMpOw0KKyAgICBpZiAoZmQgPCAw
KQ0KKyAgICAgICAgcmV0dXJuIGZkOw0KKyAgICBmc3RhdChmZCwgJnMpOw0KKw0KKyAgICBtYXAg
PSBtbWFwKDAsIHMuc3Rfc2l6ZSwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwgTUFQX1NIQVJFRCwg
ZmQsIDApOw0KKyAgICBpZiAobWFwICE9IE1BUF9GQUlMRUQpDQorICAgIHsNCisgICAgICAgIHB0
X2Rldi0+YmFzZXNbYmFyXS5tYXAgPSBtYXA7DQorICAgICAgICByZXR1cm4gMDsNCisgICAgfQ0K
KyAgICByZXR1cm4gZXJybm87DQorfQ0KKw0KIC8qIHBhcnNlIEJBUiAqLw0KIHN0YXRpYyBpbnQg
cHRfYmFyX3JlZ19wYXJzZSgNCiAgICAgICAgIHN0cnVjdCBwdF9kZXYgKnB0ZGV2LCBzdHJ1Y3Qg
cHRfcmVnX2luZm9fdGJsICpyZWcpDQpkaWZmIC0tZ2l0IGEvaHcvcGFzcy10aHJvdWdoLmggYi9o
dy9wYXNzLXRocm91Z2guaA0KaW5kZXggODg0MTM5Yy4uMjZlNmZmMSAxMDA2NDQNCi0tLSBhL2h3
L3Bhc3MtdGhyb3VnaC5oDQorKysgYi9ody9wYXNzLXRocm91Z2guaA0KQEAgLTE3MCw2ICsxNzAs
NyBAQCBzdHJ1Y3QgcHRfcmVnaW9uIHsNCiAgICAgICAgIHVpbnQ2NF90IHBpb19iYXNlOw0KICAg
ICAgICAgdWludDY0X3QgdTsNCiAgICAgfSBhY2Nlc3M7DQorICAgIHVpbnQ4X3QgKm1hcDsNCiB9
Ow0KIA0KIHN0cnVjdCBwdF9tc2lfaW5mbyB7DQpAQCAtNDE0LDYgKzQxNSw3IEBAIHVpbnQ4X3Qg
cGNpX2ludHgoc3RydWN0IHB0X2RldiAqcHRkZXYpOw0KIHN0cnVjdCBwY2lfZGV2ICpwdF9wY2lf
Z2V0X2RldihpbnQgYnVzLCBpbnQgZGV2LCBpbnQgZnVuYyk7DQogdTMyIHB0X3BjaV9ob3N0X3Jl
YWQoc3RydWN0IHBjaV9kZXYgKnBjaV9kZXYsIHUzMiBhZGRyLCBpbnQgbGVuKTsNCiBpbnQgcHRf
cGNpX2hvc3Rfd3JpdGUoc3RydWN0IHBjaV9kZXYgKnBjaV9kZXYsIHUzMiBhZGRyLCB1MzIgdmFs
LCBpbnQgbGVuKTsNCitpbnQgcHRfcGNpX2hvc3RfbWFwX2JhcihzdHJ1Y3QgcHRfZGV2ICpwdF9k
ZXYsIGludCBiYXIpOw0KIHZvaWQgaW50ZWxfcGNoX2luaXQoUENJQnVzICpidXMpOw0KIGludCBy
ZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSk7DQogaW50IHVu
cmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpOw0KQEAgLTQy
Miw2ICs0MjQsNyBAQCBQQ0lCdXMgKmludGVsX3BjaV9icmlkZ2VfaW5pdChQQ0lCdXMgKmJ1cywg
aW50IGRldmZuLCB1aW50MTZfdCB2aWQsDQogICAgICAgICAgICB1aW50MTZfdCBkaWQsIGNvbnN0
IGNoYXIgKm5hbWUsIHVpbnQxNl90IHJldmlzaW9uKTsNCiB2b2lkIGlnZF9wY2lfd3JpdGUoUENJ
RGV2aWNlICpwY2lfZGV2LCB1aW50MzJfdCBjb25maWdfYWRkciwgdWludDMyX3QgdmFsLCBpbnQg
bGVuKTsNCiB1aW50MzJfdCBpZ2RfcGNpX3JlYWQoUENJRGV2aWNlICpwY2lfZGV2LCB1aW50MzJf
dCBjb25maWdfYWRkciwgaW50IGxlbik7DQordm9pZCBwdF9ncmFwaGljX2Jhcl9yZW1hcChzdHJ1
Y3QgcHRfZGV2ICpyZWFsX2RldmljZSwgaW50IGJhciwgaW50IGZpcnN0X21hcCwgaW50IG1hcCk7
DQogDQogI2VuZGlmIC8qIF9fUEFTU1RIUk9VR0hfSF9fICovDQogDQpkaWZmIC0tZ2l0IGEvaHcv
cHQtZ3JhcGhpY3MuYyBiL2h3L3B0LWdyYXBoaWNzLmMNCmluZGV4IGZlYzczOTAuLjVkNWU1ZGEg
MTAwNjQ0DQotLS0gYS9ody9wdC1ncmFwaGljcy5jDQorKysgYi9ody9wdC1ncmFwaGljcy5jDQpA
QCAtOTQsNiArOTQsMTMgQEAgdWludDMyX3QgaWdkX3BjaV9yZWFkKFBDSURldmljZSAqcGNpX2Rl
diwgdWludDMyX3QgY29uZmlnX2FkZHIsIGludCBsZW4pDQogfQ0KIA0KIC8qDQorICogQ2FsbGJh
Y2sgd2hlbmV2ZXIgYSBiYXIgZ2V0IHJlbWFwcGVkDQorICovDQordm9pZCBwdF9ncmFwaGljX2Jh
cl9yZW1hcChzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSwgaW50IGJhciwgaW50IGZpcnN0X21h
cCwgaW50IG1hcCkNCit7DQorfQ0KKw0KKy8qDQogICogcmVnaXN0ZXIgVkdBIHJlc291cmNlcyBm
b3IgdGhlIGRvbWFpbiB3aXRoIGFzc2lnbmVkIGdmeA0KICAqLw0KIGludCByZWdpc3Rlcl92Z2Ff
cmVnaW9ucyhzdHJ1Y3QgcHRfZGV2ICpyZWFsX2RldmljZSkNCg==

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

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

--_002_003AAFE53969E14CB1F09B6FD68C3CD40A3F18ORSMSX105amrcorpi_--


From xen-devel-bounces@lists.xensource.com Wed Feb 01 22:37:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 22: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.xensource.com>)
	id 1Rsinq-0008G5-Ec; Wed, 01 Feb 2012 22:37:22 +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 1Rsino-0008Fv-Cq
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 22:37:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328135767!62208721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22269 invoked from network); 1 Feb 2012 22:36:07 -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;
	1 Feb 2012 22:36:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,604,1320624000"; d="scan'208";a="10425064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 22:37:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 22:37:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsinj-0002Gy-E7;
	Wed, 01 Feb 2012 22:37:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsinj-0004pk-Do;
	Wed, 01 Feb 2012 22:37:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11782-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 22:37:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11782: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   10 guest-saverestore         fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

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

version targeted for testing:
 xen                  ab397bd22b56
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 755 lines long.)

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

From xen-devel-bounces@lists.xensource.com Wed Feb 01 22:37:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 01 Feb 2012 22: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.xensource.com>)
	id 1Rsinq-0008G5-Ec; Wed, 01 Feb 2012 22:37:22 +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 1Rsino-0008Fv-Cq
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 22:37:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328135767!62208721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22269 invoked from network); 1 Feb 2012 22:36:07 -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;
	1 Feb 2012 22:36:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,604,1320624000"; d="scan'208";a="10425064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2012 22:37:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 1 Feb 2012 22:37:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsinj-0002Gy-E7;
	Wed, 01 Feb 2012 22:37:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsinj-0004pk-Do;
	Wed, 01 Feb 2012 22:37:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11782-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 1 Feb 2012 22:37:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11782: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   10 guest-saverestore         fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

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

version targeted for testing:
 xen                  ab397bd22b56
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 755 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 02:24:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 02: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.xensource.com>)
	id 1RsmL8-0002BJ-Fw; Thu, 02 Feb 2012 02:23:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsmL6-0002BE-Nt
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 02:23:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328149430!12492669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17121 invoked from network); 2 Feb 2012 02:23:50 -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;
	2 Feb 2012 02:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,605,1320624000"; d="scan'208";a="10426787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 02:23:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 02:23:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsmKo-0003WJ-92;
	Thu, 02 Feb 2012 02:23:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsmKo-0007bR-4U;
	Thu, 02 Feb 2012 02:23:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11789-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 02:23:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11789: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11789 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11789/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2         fail pass in 11770
 test-amd64-i386-xl-credit2    7 debian-install     fail in 11770 pass in 11789
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 11770 pass in 11789
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 11770 pass in 11789

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764
 test-i386-i386-win            7 windows-install       fail in 11770 like 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 02:24:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 02: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.xensource.com>)
	id 1RsmL8-0002BJ-Fw; Thu, 02 Feb 2012 02:23:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsmL6-0002BE-Nt
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 02:23:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328149430!12492669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17121 invoked from network); 2 Feb 2012 02:23:50 -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;
	2 Feb 2012 02:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,605,1320624000"; d="scan'208";a="10426787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 02:23:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 02:23:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsmKo-0003WJ-92;
	Thu, 02 Feb 2012 02:23:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsmKo-0007bR-4U;
	Thu, 02 Feb 2012 02:23:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11789-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 02:23:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11789: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11789 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11789/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2         fail pass in 11770
 test-amd64-i386-xl-credit2    7 debian-install     fail in 11770 pass in 11789
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 11770 pass in 11789
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 11770 pass in 11789

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764
 test-i386-i386-win            7 windows-install       fail in 11770 like 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 05:32:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 05:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RspH5-0005OZ-Vq; Thu, 02 Feb 2012 05:31:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RspH4-0005OT-6h
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 05:31:58 +0000
Received: from [85.158.138.51:22605] by server-5.bemta-3.messagelabs.com id
	5E/8F-25695-DCF1A2F4; Thu, 02 Feb 2012 05:31:57 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328160714!11582036!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27446 invoked from network); 2 Feb 2012 05:31:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Feb 2012 05:31:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RspH0-0007uP-AX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:31:54 -0800
Date: Wed, 1 Feb 2012 21:31:54 -0800 (PST)
From: feisky <feiskyer@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <CAJ44hTfqRtVEWej2hWGVRBt=Y+HsA6ajG4Qvy4dq8h3r88m+7w@mail.gmail.com>
In-Reply-To: <20120201155123.GM12984@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
	<1328099398393-5447334.post@n5.nabble.com>
	<20120201155123.GM12984@reaktio.net>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen guest disk online resize,
 xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4035352202127381332=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4035352202127381332==
Content-Type: multipart/alternative; 
	boundary="----=_Part_986_32024105.1328160714320"

------=_Part_986_32024105.1328160714320
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Could you send your patch to me?

thanks.

On Wed, Feb 1, 2012 at 11:52 PM, Pasi K=C3=A4rkk=C3=A4inen [via Xen] <
ml-node+s1045712n5447888h47@n5.nabble.com> wrote:

> On Wed, Feb 01, 2012 at 04:29:58AM -0800, feisky wrote:
> > Has anyone tried is this method ok?
> >
>
> Yep, I've used it, and verified it works.
>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email] <http://user/SendEmail.jtp?type=3Dnode&node=3D5447888&i=3D=
0>
> http://lists.xensource.com/xen-devel
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://xen.1045712.n5.nabble.com/Xen-guest-disk-online-resize-xenstore-bl=
kback-blkfront-questions-tp2547847p5447888.html
>  To unsubscribe from Xen guest disk online resize,
> xenstore/blkback/blkfront questions, click here<http://xen.1045712.n5.nab=
ble.com/template/NamlServlet.jtp?macro=3Dunsubscribe_by_code&node=3D2547847=
&code=3DZmVpc2t5ZXJAZ21haWwuY29tfDI1NDc4NDd8MTg5Nzg0NTI4Nw=3D=3D>
> .
> NAML<http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=3Dma=
cro_viewer&id=3Dinstant_html%21nabble%3Aemail.naml&base=3Dnabble.naml.names=
paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.w=
eb.template.NodeNamespace&breadcrumbs=3Dnotify_subscribers%21nabble%3Aemail=
.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aem=
ail.naml>
>


--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-guest-di=
sk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p5449661.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_986_32024105.1328160714320
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

Could you send your patch to me?=C2=A0<div><br></div><div>thanks.<br><br><d=
iv class=3D"gmail_quote">On Wed, Feb 1, 2012 at 11:52 PM, Pasi K=C3=A4rkk=
=C3=A4inen [via Xen] <span dir=3D"ltr">&lt;<a href=3D"/user/SendEmail.jtp?t=
ype=3Dnode&node=3D5449661&i=3D0" target=3D"_top" rel=3D"nofollow" link=3D"e=
xternal">[hidden email]</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">

=09On Wed, Feb 01, 2012 at 04:29:58AM -0800, feisky wrote:
<br>&gt; Has anyone tried is this method ok?
<br>&gt;=20
<br><br>Yep, I&#39;ve used it, and verified it works.
<br><br>-- Pasi
<br><br><br></div></div>_______________________________________________
<br>Xen-devel mailing list
<br><a href=3D"http://user/SendEmail.jtp?type=3Dnode&amp;node=3D5447888&amp=
;i=3D0" rel=3D"nofollow" link=3D"external" target=3D"_blank">[hidden email]=
</a>
<br><a href=3D"http://lists.xensource.com/xen-devel" rel=3D"nofollow" link=
=3D"external" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br=
>
=09
=09<br>
=09<br>
=09<hr noshade size=3D"1" color=3D"#cccccc">
=09<div style=3D"color:#444;font:12px tahoma,geneva,helvetica,arial,sans-se=
rif">
=09=09<div style=3D"font-weight:bold">If you reply to this email, your mess=
age will be added to the discussion below:</div>
=09=09<a href=3D"http://xen.1045712.n5.nabble.com/Xen-guest-disk-online-res=
ize-xenstore-blkback-blkfront-questions-tp2547847p5447888.html" target=3D"_=
blank" rel=3D"nofollow" link=3D"external">http://xen.1045712.n5.nabble.com/=
Xen-guest-disk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p=
5447888.html</a>
=09</div>
=09<div style=3D"color:#666;font:11px tahoma,geneva,helvetica,arial,sans-se=
rif;margin-top:.4em;line-height:1.5em">
=09=09
=09=09To unsubscribe from Xen guest disk online resize, xenstore/blkback/bl=
kfront questions, <a href=3D"" target=3D"_blank" rel=3D"nofollow" link=3D"e=
xternal">click here</a>.<br>


=09=09<a href=3D"http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?=
macro=3Dmacro_viewer&amp;id=3Dinstant_html%21nabble%3Aemail.naml&amp;base=
=3Dnabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNam=
espace-nabble.view.web.template.NodeNamespace&amp;breadcrumbs=3Dnotify_subs=
cribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_ins=
tant_email%21nabble%3Aemail.naml" rel=3D"nofollow" style=3D"font:9px serif"=
 target=3D"_blank" link=3D"external">NAML</a>
=09</div></blockquote></div><br></div>

=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/X=
en-guest-disk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p5=
449661.html">Re: Xen guest disk online resize, xenstore/blkback/blkfront qu=
estions</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_986_32024105.1328160714320--


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

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

--===============4035352202127381332==--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 05:32:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 05:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RspH5-0005OZ-Vq; Thu, 02 Feb 2012 05:31:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RspH4-0005OT-6h
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 05:31:58 +0000
Received: from [85.158.138.51:22605] by server-5.bemta-3.messagelabs.com id
	5E/8F-25695-DCF1A2F4; Thu, 02 Feb 2012 05:31:57 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328160714!11582036!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27446 invoked from network); 2 Feb 2012 05:31:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Feb 2012 05:31:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RspH0-0007uP-AX
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 21:31:54 -0800
Date: Wed, 1 Feb 2012 21:31:54 -0800 (PST)
From: feisky <feiskyer@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <CAJ44hTfqRtVEWej2hWGVRBt=Y+HsA6ajG4Qvy4dq8h3r88m+7w@mail.gmail.com>
In-Reply-To: <20120201155123.GM12984@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
	<1328099398393-5447334.post@n5.nabble.com>
	<20120201155123.GM12984@reaktio.net>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen guest disk online resize,
 xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4035352202127381332=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4035352202127381332==
Content-Type: multipart/alternative; 
	boundary="----=_Part_986_32024105.1328160714320"

------=_Part_986_32024105.1328160714320
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Could you send your patch to me?

thanks.

On Wed, Feb 1, 2012 at 11:52 PM, Pasi K=C3=A4rkk=C3=A4inen [via Xen] <
ml-node+s1045712n5447888h47@n5.nabble.com> wrote:

> On Wed, Feb 01, 2012 at 04:29:58AM -0800, feisky wrote:
> > Has anyone tried is this method ok?
> >
>
> Yep, I've used it, and verified it works.
>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email] <http://user/SendEmail.jtp?type=3Dnode&node=3D5447888&i=3D=
0>
> http://lists.xensource.com/xen-devel
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://xen.1045712.n5.nabble.com/Xen-guest-disk-online-resize-xenstore-bl=
kback-blkfront-questions-tp2547847p5447888.html
>  To unsubscribe from Xen guest disk online resize,
> xenstore/blkback/blkfront questions, click here<http://xen.1045712.n5.nab=
ble.com/template/NamlServlet.jtp?macro=3Dunsubscribe_by_code&node=3D2547847=
&code=3DZmVpc2t5ZXJAZ21haWwuY29tfDI1NDc4NDd8MTg5Nzg0NTI4Nw=3D=3D>
> .
> NAML<http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=3Dma=
cro_viewer&id=3Dinstant_html%21nabble%3Aemail.naml&base=3Dnabble.naml.names=
paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.w=
eb.template.NodeNamespace&breadcrumbs=3Dnotify_subscribers%21nabble%3Aemail=
.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aem=
ail.naml>
>


--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-guest-di=
sk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p5449661.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_986_32024105.1328160714320
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

Could you send your patch to me?=C2=A0<div><br></div><div>thanks.<br><br><d=
iv class=3D"gmail_quote">On Wed, Feb 1, 2012 at 11:52 PM, Pasi K=C3=A4rkk=
=C3=A4inen [via Xen] <span dir=3D"ltr">&lt;<a href=3D"/user/SendEmail.jtp?t=
ype=3Dnode&node=3D5449661&i=3D0" target=3D"_top" rel=3D"nofollow" link=3D"e=
xternal">[hidden email]</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">

=09On Wed, Feb 01, 2012 at 04:29:58AM -0800, feisky wrote:
<br>&gt; Has anyone tried is this method ok?
<br>&gt;=20
<br><br>Yep, I&#39;ve used it, and verified it works.
<br><br>-- Pasi
<br><br><br></div></div>_______________________________________________
<br>Xen-devel mailing list
<br><a href=3D"http://user/SendEmail.jtp?type=3Dnode&amp;node=3D5447888&amp=
;i=3D0" rel=3D"nofollow" link=3D"external" target=3D"_blank">[hidden email]=
</a>
<br><a href=3D"http://lists.xensource.com/xen-devel" rel=3D"nofollow" link=
=3D"external" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br=
>
=09
=09<br>
=09<br>
=09<hr noshade size=3D"1" color=3D"#cccccc">
=09<div style=3D"color:#444;font:12px tahoma,geneva,helvetica,arial,sans-se=
rif">
=09=09<div style=3D"font-weight:bold">If you reply to this email, your mess=
age will be added to the discussion below:</div>
=09=09<a href=3D"http://xen.1045712.n5.nabble.com/Xen-guest-disk-online-res=
ize-xenstore-blkback-blkfront-questions-tp2547847p5447888.html" target=3D"_=
blank" rel=3D"nofollow" link=3D"external">http://xen.1045712.n5.nabble.com/=
Xen-guest-disk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p=
5447888.html</a>
=09</div>
=09<div style=3D"color:#666;font:11px tahoma,geneva,helvetica,arial,sans-se=
rif;margin-top:.4em;line-height:1.5em">
=09=09
=09=09To unsubscribe from Xen guest disk online resize, xenstore/blkback/bl=
kfront questions, <a href=3D"" target=3D"_blank" rel=3D"nofollow" link=3D"e=
xternal">click here</a>.<br>


=09=09<a href=3D"http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?=
macro=3Dmacro_viewer&amp;id=3Dinstant_html%21nabble%3Aemail.naml&amp;base=
=3Dnabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNam=
espace-nabble.view.web.template.NodeNamespace&amp;breadcrumbs=3Dnotify_subs=
cribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_ins=
tant_email%21nabble%3Aemail.naml" rel=3D"nofollow" style=3D"font:9px serif"=
 target=3D"_blank" link=3D"external">NAML</a>
=09</div></blockquote></div><br></div>

=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/X=
en-guest-disk-online-resize-xenstore-blkback-blkfront-questions-tp2547847p5=
449661.html">Re: Xen guest disk online resize, xenstore/blkback/blkfront qu=
estions</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_986_32024105.1328160714320--


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

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

--===============4035352202127381332==--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 05:37:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 05: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.xensource.com>)
	id 1RspMB-0005WJ-Nr; Thu, 02 Feb 2012 05:37:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RspMA-0005W8-8v
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 05:37:14 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328161024!13196853!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NzczNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18025 invoked from network); 2 Feb 2012 05:37:05 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 05:37:05 -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=F8FBmxMOfg7fjxlf2uYInpu3p2wjzRqo1RrfJnPUm2P79APxSGlYEwCD
	n1/1v/xZpBkaMEX35QOsoNi09WlxUqlQ7ba8jUH3VZZVuOjuaejQgi7QQ
	migDZFSsRxLLOC+xsQiu2Lqw+1VsCEXj8MTk5DQ1uGZggUeoz3dt4GURK
	ao130Q1EB4EChKuBfadz4Jkk9a+nO8T+bpzCFrPeJTPHYWRgQWOLiu1J2
	2Tv+jda/ro5KisgqWPqBCixrLRzKC;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328161026; x=1359697026;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=YfVXPscjg+Wd7j7+quUjqBiqkOgDhmzDBNvJ6rwO4ec=;
	b=U5hlnLSq2iPZe/EPgGrPXk4MuFl5zs+JRt2aVmAst/jqCEopooiTWq2M
	pMOwmGMl3YT2ewJoHIIRrW462Tr9xHG51FIzDE1E19yWGBD2gpz9WVvCe
	B5ROF3inVgVyTFWkb1hvhpKKRZT6bdbpvW3LSPoCF3f00zPvbiCQEJCse
	0+GQwgWdxng7M9dovoVtdPrejVa9dFoh/+SXv6qbOd3jnbVrxBPgTYDCw
	AtqPzh8ahRxmGc3LaAnfkcXnpAuEL;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,606,1320620400"; d="scan'208";a="85133827"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 02 Feb 2012 06:37:03 +0100
X-IronPort-AV: E=Sophos;i="4.71,605,1320620400"; d="scan'208";a="128202695"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 02 Feb 2012 06:37:03 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 0E9C576C0C0;
	Thu,  2 Feb 2012 06:37:03 +0100 (CET)
Message-ID: <4F2A20FF.90607@ts.fujitsu.com>
Date: Thu, 02 Feb 2012 06:37:03 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328107728.17444.81.camel@zakaz.uk.xensource.com>
Cc: John McDermott <segfaultreloaded@gmail.com>,
	Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/01/2012 03:48 PM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 13:15 +0000, John McDermott wrote:
>> Xen Developers,
>>
>> FYI, in 4.1-testing, tools/libxl/xl_cmdimpl.c, in function
>> main_cpupoollist, the variable opt_long is set but not used. Tools
>> won't make with this warning.
> Our test system compilers obviously don't generate this particular
> warning so it slipped through. Thanks for reporting.
>
> Looks like fallout from 22838:aab67c1c6b87 which removed the (nop)
> implementation of that option.
>
> The following just nukes it altogether, the generic handling of
> unsupported options already prints something.
>
> Ian.
>
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1328107525 0
> # Node ID 6e1db0380ba3467e26128706a62195bf2816e00e
> # Parent  667da384457b0ec5f8f2ea4ec3c1ee43008e7ed5
> xl: Drop -l option to xl cpupool-list
>
> The implementation (which was a nop) was removed back in 22838:aab67c1c6b87 but
> this now causes "set but not used" warnings from some compilers. Might as well
> just nuke the option entirely.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>

Acked-by: juergen.gross@ts.fujitsu.com

> diff -r 667da384457b -r 6e1db0380ba3 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
> @@ -5538,11 +5538,9 @@ int main_cpupoollist(int argc, char **ar
>       int option_index = 0;
>       static struct option long_options[] = {
>           {"help", 0, 0, 'h'},
> -        {"long", 0, 0, 'l'},
>           {"cpus", 0, 0, 'c'},
>           {0, 0, 0, 0}
>       };
> -    int opt_long = 0;
>       int opt_cpus = 0;
>       const char *pool = NULL;
>       libxl_cpupoolinfo *poolinfo;
> @@ -5552,7 +5550,7 @@ int main_cpupoollist(int argc, char **ar
>       int ret = 0;
>
>       while (1) {
> -        opt = getopt_long(argc, argv, "hlc", long_options,&option_index);
> +        opt = getopt_long(argc, argv, "hc", long_options,&option_index);
>           if (opt == -1)
>               break;
>
> @@ -5560,9 +5558,6 @@ int main_cpupoollist(int argc, char **ar
>           case 'h':
>               help("cpupool-list");
>               return 0;
> -        case 'l':
> -            opt_long = 1;
> -            break;
>           case 'c':
>               opt_cpus = 1;
>               break;
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


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


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 05:37:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 05: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.xensource.com>)
	id 1RspMB-0005WJ-Nr; Thu, 02 Feb 2012 05:37:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RspMA-0005W8-8v
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 05:37:14 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328161024!13196853!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NzczNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18025 invoked from network); 2 Feb 2012 05:37:05 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 05:37:05 -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=F8FBmxMOfg7fjxlf2uYInpu3p2wjzRqo1RrfJnPUm2P79APxSGlYEwCD
	n1/1v/xZpBkaMEX35QOsoNi09WlxUqlQ7ba8jUH3VZZVuOjuaejQgi7QQ
	migDZFSsRxLLOC+xsQiu2Lqw+1VsCEXj8MTk5DQ1uGZggUeoz3dt4GURK
	ao130Q1EB4EChKuBfadz4Jkk9a+nO8T+bpzCFrPeJTPHYWRgQWOLiu1J2
	2Tv+jda/ro5KisgqWPqBCixrLRzKC;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328161026; x=1359697026;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=YfVXPscjg+Wd7j7+quUjqBiqkOgDhmzDBNvJ6rwO4ec=;
	b=U5hlnLSq2iPZe/EPgGrPXk4MuFl5zs+JRt2aVmAst/jqCEopooiTWq2M
	pMOwmGMl3YT2ewJoHIIRrW462Tr9xHG51FIzDE1E19yWGBD2gpz9WVvCe
	B5ROF3inVgVyTFWkb1hvhpKKRZT6bdbpvW3LSPoCF3f00zPvbiCQEJCse
	0+GQwgWdxng7M9dovoVtdPrejVa9dFoh/+SXv6qbOd3jnbVrxBPgTYDCw
	AtqPzh8ahRxmGc3LaAnfkcXnpAuEL;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,606,1320620400"; d="scan'208";a="85133827"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 02 Feb 2012 06:37:03 +0100
X-IronPort-AV: E=Sophos;i="4.71,605,1320620400"; d="scan'208";a="128202695"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 02 Feb 2012 06:37:03 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 0E9C576C0C0;
	Thu,  2 Feb 2012 06:37:03 +0100 (CET)
Message-ID: <4F2A20FF.90607@ts.fujitsu.com>
Date: Thu, 02 Feb 2012 06:37:03 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328107728.17444.81.camel@zakaz.uk.xensource.com>
Cc: John McDermott <segfaultreloaded@gmail.com>,
	Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/01/2012 03:48 PM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 13:15 +0000, John McDermott wrote:
>> Xen Developers,
>>
>> FYI, in 4.1-testing, tools/libxl/xl_cmdimpl.c, in function
>> main_cpupoollist, the variable opt_long is set but not used. Tools
>> won't make with this warning.
> Our test system compilers obviously don't generate this particular
> warning so it slipped through. Thanks for reporting.
>
> Looks like fallout from 22838:aab67c1c6b87 which removed the (nop)
> implementation of that option.
>
> The following just nukes it altogether, the generic handling of
> unsupported options already prints something.
>
> Ian.
>
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1328107525 0
> # Node ID 6e1db0380ba3467e26128706a62195bf2816e00e
> # Parent  667da384457b0ec5f8f2ea4ec3c1ee43008e7ed5
> xl: Drop -l option to xl cpupool-list
>
> The implementation (which was a nop) was removed back in 22838:aab67c1c6b87 but
> this now causes "set but not used" warnings from some compilers. Might as well
> just nuke the option entirely.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>

Acked-by: juergen.gross@ts.fujitsu.com

> diff -r 667da384457b -r 6e1db0380ba3 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 01 14:45:25 2012 +0000
> @@ -5538,11 +5538,9 @@ int main_cpupoollist(int argc, char **ar
>       int option_index = 0;
>       static struct option long_options[] = {
>           {"help", 0, 0, 'h'},
> -        {"long", 0, 0, 'l'},
>           {"cpus", 0, 0, 'c'},
>           {0, 0, 0, 0}
>       };
> -    int opt_long = 0;
>       int opt_cpus = 0;
>       const char *pool = NULL;
>       libxl_cpupoolinfo *poolinfo;
> @@ -5552,7 +5550,7 @@ int main_cpupoollist(int argc, char **ar
>       int ret = 0;
>
>       while (1) {
> -        opt = getopt_long(argc, argv, "hlc", long_options,&option_index);
> +        opt = getopt_long(argc, argv, "hc", long_options,&option_index);
>           if (opt == -1)
>               break;
>
> @@ -5560,9 +5558,6 @@ int main_cpupoollist(int argc, char **ar
>           case 'h':
>               help("cpupool-list");
>               return 0;
> -        case 'l':
> -            opt_long = 1;
> -            break;
>           case 'c':
>               opt_cpus = 1;
>               break;
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


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


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 05:47:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 05:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RspVZ-0005m9-0k; Thu, 02 Feb 2012 05:46:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RspVX-0005m4-1z
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 05:46:55 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328161607!13129706!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15849 invoked from network); 2 Feb 2012 05:46:48 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 05:46:48 -0000
Received: by iaeh11 with SMTP id h11so10552562iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 21:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=ei8g5wbeEpPm0UhgdCRSNcHx4neevYIoU8mp3LUrLj0=;
	b=WUPtP/1f7ZnYUciHD5Vqej02JLmag+fUGfpUQG6E9L5KPw28L3BtP7nEeBfx27FPUT
	eRG7vvgPgv84Z/JPNDYApS9E93OQI4qwA8ZAM3obW1b0M0N7/qbBkhZvJssZPRtPAZod
	H870VEhXdB1nkcBvqc6arH1v2POA2xEz0kSfY=
Received: by 10.42.168.197 with SMTP id x5mr1422319icy.6.1328161607255; Wed,
	01 Feb 2012 21:46:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.30.75 with HTTP; Wed, 1 Feb 2012 21:46:32 -0800 (PST)
From: Feisky <feiskyer@gmail.com>
Date: Thu, 2 Feb 2012 13:46:32 +0800
Message-ID: <CAJ44hTdGCK_e02u4uT625UKeY_Dje9d=aTCVXHURTtH4GOisyw@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenstore-write: could not write path
	backend/vbd/1/2050/hotplug-error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0493724914283477084=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0493724914283477084==
Content-Type: multipart/alternative; boundary=90e6ba6e89cace07de04b7f4b866

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

After a few times of building xen by source, I can't start domU anyway. I
tried "yum erase xen kernel-xen" and "yum install xen kernel-xen" again,
but the problem is still exist.

There are xenstore-write errors in /var/log/xen/xen-hotplug.log:

xenstore-write: could not write path backend/vbd/1/2050/hotplug-error
xenstore-write: could not write path backend/vbd/1/2049/hotplug-error
xenstore-write: could not write path backend/vif/1/0/hotplug-error
xenstore-write: could not write path backend/vbd/1/2050/hotplug-error
xenstore-write: could not write path backend/vbd/1/2049/hotplug-error
xenstore-write: could not write path backend/vif/1/0/hotplug-error

--90e6ba6e89cace07de04b7f4b866
Content-Type: text/html; charset=ISO-8859-1

<div>After a few times of building xen by source, I can&#39;t start domU anyway. I tried &quot;yum erase xen kernel-xen&quot; and &quot;yum install xen kernel-xen&quot; again, but the problem is still exist.</div><div><br>

</div><div>There are xenstore-write errors in /var/log/xen/xen-hotplug.log:</div><div><br></div><div>xenstore-write: could not write path backend/vbd/1/2050/hotplug-error</div><div>xenstore-write: could not write path backend/vbd/1/2049/hotplug-error</div>

<div>xenstore-write: could not write path backend/vif/1/0/hotplug-error</div><div>xenstore-write: could not write path backend/vbd/1/2050/hotplug-error</div><div>xenstore-write: could not write path backend/vbd/1/2049/hotplug-error</div>

<div>xenstore-write: could not write path backend/vif/1/0/hotplug-error</div>

--90e6ba6e89cace07de04b7f4b866--


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

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

--===============0493724914283477084==--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 05:47:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 05:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RspVZ-0005m9-0k; Thu, 02 Feb 2012 05:46:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <feiskyer@gmail.com>) id 1RspVX-0005m4-1z
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 05:46:55 +0000
X-Env-Sender: feiskyer@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328161607!13129706!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15849 invoked from network); 2 Feb 2012 05:46:48 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 05:46:48 -0000
Received: by iaeh11 with SMTP id h11so10552562iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 21:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=ei8g5wbeEpPm0UhgdCRSNcHx4neevYIoU8mp3LUrLj0=;
	b=WUPtP/1f7ZnYUciHD5Vqej02JLmag+fUGfpUQG6E9L5KPw28L3BtP7nEeBfx27FPUT
	eRG7vvgPgv84Z/JPNDYApS9E93OQI4qwA8ZAM3obW1b0M0N7/qbBkhZvJssZPRtPAZod
	H870VEhXdB1nkcBvqc6arH1v2POA2xEz0kSfY=
Received: by 10.42.168.197 with SMTP id x5mr1422319icy.6.1328161607255; Wed,
	01 Feb 2012 21:46:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.30.75 with HTTP; Wed, 1 Feb 2012 21:46:32 -0800 (PST)
From: Feisky <feiskyer@gmail.com>
Date: Thu, 2 Feb 2012 13:46:32 +0800
Message-ID: <CAJ44hTdGCK_e02u4uT625UKeY_Dje9d=aTCVXHURTtH4GOisyw@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenstore-write: could not write path
	backend/vbd/1/2050/hotplug-error
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0493724914283477084=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0493724914283477084==
Content-Type: multipart/alternative; boundary=90e6ba6e89cace07de04b7f4b866

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

After a few times of building xen by source, I can't start domU anyway. I
tried "yum erase xen kernel-xen" and "yum install xen kernel-xen" again,
but the problem is still exist.

There are xenstore-write errors in /var/log/xen/xen-hotplug.log:

xenstore-write: could not write path backend/vbd/1/2050/hotplug-error
xenstore-write: could not write path backend/vbd/1/2049/hotplug-error
xenstore-write: could not write path backend/vif/1/0/hotplug-error
xenstore-write: could not write path backend/vbd/1/2050/hotplug-error
xenstore-write: could not write path backend/vbd/1/2049/hotplug-error
xenstore-write: could not write path backend/vif/1/0/hotplug-error

--90e6ba6e89cace07de04b7f4b866
Content-Type: text/html; charset=ISO-8859-1

<div>After a few times of building xen by source, I can&#39;t start domU anyway. I tried &quot;yum erase xen kernel-xen&quot; and &quot;yum install xen kernel-xen&quot; again, but the problem is still exist.</div><div><br>

</div><div>There are xenstore-write errors in /var/log/xen/xen-hotplug.log:</div><div><br></div><div>xenstore-write: could not write path backend/vbd/1/2050/hotplug-error</div><div>xenstore-write: could not write path backend/vbd/1/2049/hotplug-error</div>

<div>xenstore-write: could not write path backend/vif/1/0/hotplug-error</div><div>xenstore-write: could not write path backend/vbd/1/2050/hotplug-error</div><div>xenstore-write: could not write path backend/vbd/1/2049/hotplug-error</div>

<div>xenstore-write: could not write path backend/vif/1/0/hotplug-error</div>

--90e6ba6e89cace07de04b7f4b866--


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

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

--===============0493724914283477084==--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:05:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07: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.xensource.com>)
	id 1RsqiT-0007HW-Ui; Thu, 02 Feb 2012 07:04:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsqiS-0007HR-0V
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:04:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328166251!13609613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11579 invoked from network); 2 Feb 2012 07:04:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 07:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10428651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 07: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.213.0; Thu, 2 Feb 2012 07:04:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsqiF-0005BX-Hn;
	Thu, 02 Feb 2012 07:04:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsqiF-0000yR-Gf;
	Thu, 02 Feb 2012 07:04:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11807-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 07:04:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  a91aa7a582fb
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1232 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:05:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07: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.xensource.com>)
	id 1RsqiT-0007HW-Ui; Thu, 02 Feb 2012 07:04:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsqiS-0007HR-0V
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:04:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328166251!13609613!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11579 invoked from network); 2 Feb 2012 07:04:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 07:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10428651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 07: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.213.0; Thu, 2 Feb 2012 07:04:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsqiF-0005BX-Hn;
	Thu, 02 Feb 2012 07:04:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsqiF-0000yR-Gf;
	Thu, 02 Feb 2012 07:04:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11807-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 07:04:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  a91aa7a582fb
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1232 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:05:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07:05:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsqj6-0007Ik-CL; Thu, 02 Feb 2012 07:05:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rsqj4-0007Id-Nu
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:04:59 +0000
Received: from [85.158.138.51:59427] by server-1.bemta-3.messagelabs.com id
	80/8D-23590-9953A2F4; Thu, 02 Feb 2012 07:04:57 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328166294!11658247!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1241 invoked from network); 2 Feb 2012 07:04:56 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Feb 2012 07:04:56 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1274pEr030311
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 23:04:52 -0800
Received: by bkbzv3 with SMTP id zv3so3674303bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 23:04:49 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr678641bkc.13.1328166289351; Wed,
	01 Feb 2012 23:04:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 1 Feb 2012 23:04:09 -0800 (PST)
In-Reply-To: <A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
	<A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 23:04:09 -0800
Message-ID: <CAP8mzPMe=EA55r4ZWcfVW7SOmuYu=_QGgKNUeN8T696xyeQ2zQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6169475836216819250=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6169475836216819250==
Content-Type: multipart/alternative; boundary=000e0ce04044e124d704b7f5cf82

--000e0ce04044e124d704b7f5cf82
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/2/1 Shriram Rajagopalan <rshriram@cs.ubc.ca>

> On 2012-02-01, at 8:02 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:
> >> On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:
> >>> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> >>>> As for guests supporting this fast suspend, almost all guests (pv/hv=
m
> >>>> linux/windows) do support suspend_cancel. IIRC, I think some very ol=
d
> >>>> kernels didnt have this ability.
> >>>
>

xenstore entry, local/domain/<domid>/image/suspend-cancel - this entry
indicates
if the guest supports co-operative suspend or not.
 But unfortunately, I coundnt find any reference in xend, that "creates"
this entry.
 There are references in xen/ and the tools/ folder, that read the
SUSPEND_CANCEL entry,
  like readnotes, XendDomainInfo.py, xen/common/libelf/libelf-dominfo.c

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

<div class=3D"gmail_quote">2012/2/1 Shriram Rajagopalan <span dir=3D"ltr">&=
lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</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"HOEnZb"><div class=3D"h5">On 2012-02-01, at 8:02 AM, Ian Camp=
bell &lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com=
</a>&gt; wrote:<br>
<br>
&gt; On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:<br>
&gt;&gt; On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:<br>
&gt;&gt;&gt; On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:<=
br>
&gt;&gt;&gt;&gt; As for guests supporting this fast suspend, almost all gue=
sts (pv/hvm<br>
&gt;&gt;&gt;&gt; linux/windows) do support suspend_cancel. IIRC, I think so=
me very old<br>
&gt;&gt;&gt;&gt; kernels didnt have this ability.<br>
&gt;&gt;&gt;<br></div></div></blockquote><div><br></div></div>xenstore entr=
y, local/domain/&lt;domid&gt;/image/suspend-cancel - this entry indicates<b=
r>if the guest supports co-operative suspend or not. <br>=A0But unfortunate=
ly, I coundnt find any reference in xend, that &quot;creates&quot; this ent=
ry.<br>

=A0There are references in xen/ and the tools/ folder, that read the SUSPEN=
D_CANCEL entry,<br>=A0 like readnotes, XendDomainInfo.py, xen/common/libelf=
/libelf-dominfo.c <br>=A0<br>

--000e0ce04044e124d704b7f5cf82--


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

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

--===============6169475836216819250==--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:05:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07:05:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsqj6-0007Ik-CL; Thu, 02 Feb 2012 07:05:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rsqj4-0007Id-Nu
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:04:59 +0000
Received: from [85.158.138.51:59427] by server-1.bemta-3.messagelabs.com id
	80/8D-23590-9953A2F4; Thu, 02 Feb 2012 07:04:57 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328166294!11658247!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1241 invoked from network); 2 Feb 2012 07:04:56 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Feb 2012 07:04:56 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1274pEr030311
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 1 Feb 2012 23:04:52 -0800
Received: by bkbzv3 with SMTP id zv3so3674303bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 23:04:49 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr678641bkc.13.1328166289351; Wed,
	01 Feb 2012 23:04:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 1 Feb 2012 23:04:09 -0800 (PST)
In-Reply-To: <A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
	<A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 1 Feb 2012 23:04:09 -0800
Message-ID: <CAP8mzPMe=EA55r4ZWcfVW7SOmuYu=_QGgKNUeN8T696xyeQ2zQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6169475836216819250=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6169475836216819250==
Content-Type: multipart/alternative; boundary=000e0ce04044e124d704b7f5cf82

--000e0ce04044e124d704b7f5cf82
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/2/1 Shriram Rajagopalan <rshriram@cs.ubc.ca>

> On 2012-02-01, at 8:02 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:
> >> On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:
> >>> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> >>>> As for guests supporting this fast suspend, almost all guests (pv/hv=
m
> >>>> linux/windows) do support suspend_cancel. IIRC, I think some very ol=
d
> >>>> kernels didnt have this ability.
> >>>
>

xenstore entry, local/domain/<domid>/image/suspend-cancel - this entry
indicates
if the guest supports co-operative suspend or not.
 But unfortunately, I coundnt find any reference in xend, that "creates"
this entry.
 There are references in xen/ and the tools/ folder, that read the
SUSPEND_CANCEL entry,
  like readnotes, XendDomainInfo.py, xen/common/libelf/libelf-dominfo.c

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

<div class=3D"gmail_quote">2012/2/1 Shriram Rajagopalan <span dir=3D"ltr">&=
lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</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"HOEnZb"><div class=3D"h5">On 2012-02-01, at 8:02 AM, Ian Camp=
bell &lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com=
</a>&gt; wrote:<br>
<br>
&gt; On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:<br>
&gt;&gt; On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:<br>
&gt;&gt;&gt; On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:<=
br>
&gt;&gt;&gt;&gt; As for guests supporting this fast suspend, almost all gue=
sts (pv/hvm<br>
&gt;&gt;&gt;&gt; linux/windows) do support suspend_cancel. IIRC, I think so=
me very old<br>
&gt;&gt;&gt;&gt; kernels didnt have this ability.<br>
&gt;&gt;&gt;<br></div></div></blockquote><div><br></div></div>xenstore entr=
y, local/domain/&lt;domid&gt;/image/suspend-cancel - this entry indicates<b=
r>if the guest supports co-operative suspend or not. <br>=A0But unfortunate=
ly, I coundnt find any reference in xend, that &quot;creates&quot; this ent=
ry.<br>

=A0There are references in xen/ and the tools/ folder, that read the SUSPEN=
D_CANCEL entry,<br>=A0 like readnotes, XendDomainInfo.py, xen/common/libelf=
/libelf-dominfo.c <br>=A0<br>

--000e0ce04044e124d704b7f5cf82--


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

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

--===============6169475836216819250==--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:59:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsrZN-0008Ml-Vg; Thu, 02 Feb 2012 07:59:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsrZM-0008Mg-Lt
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:59:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328169534!12843828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15635 invoked from network); 2 Feb 2012 07:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 07:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10429211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 07:58: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.213.0; Thu, 2 Feb 2012
	07:58:53 +0000
Message-ID: <1328169532.28964.58.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 2 Feb 2012 07:58:52 +0000
In-Reply-To: <A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
	<A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:30 +0000, Shriram Rajagopalan wrote:
> On 2012-02-01, at 8:02 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> =

> > On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:
> >> On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:
> >>> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> >>>> As for guests supporting this fast suspend, almost all guests (pv/hvm
> >>>> linux/windows) do support suspend_cancel. IIRC, I think some very old
> >>>> kernels didnt have this ability.
> >>> =

> >>> Slight aside, does Remus work with mainline Linux domU kernels? Users
> >>> seem to be under under that impression.
> >>> =

> >>> I know you had some patches at one point but I a) don't remember if t=
hey
> >>> went in and b) don't remember if they were sufficient.
> >>> =

> >> =

> >> http://wiki.xen.org/wiki/Remus
> >> "Linux 2.6.39.2 and later upstream kernel.org versions are now support=
ed as PV domU kernels"
> > =

> > Great, someone was suggesting on list that this wasn't the case. Must
> > dig out that mail and respond.
> > =

> > Ian.
> > =

> > =

> =

> I added the comments on top of the second version of the patch series.
> Please let me know if it looks okay.
> =

> I will be spinning out a V3 anyway, since Stefano has removed  qmp_migrat=
e.
> But this patch would remain the same, if it's current form is okay.

If you are respinning anyway then putting a comment in the header rather
than the implementation would be better since that is where users of the
library will be looking for it.

The comment from xc_resume.c which you copied explains the two modes but
doesn't actually say how the fast parameter relates to them. A better
comment to lift would be the description of @fast from xenctrl.h:

	"fast [means] use cooperative resume (guest must support this)"

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:59:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsrZN-0008Ml-Vg; Thu, 02 Feb 2012 07:59:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsrZM-0008Mg-Lt
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:59:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328169534!12843828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15635 invoked from network); 2 Feb 2012 07:58:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 07:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10429211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 07:58: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.213.0; Thu, 2 Feb 2012
	07:58:53 +0000
Message-ID: <1328169532.28964.58.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 2 Feb 2012 07:58:52 +0000
In-Reply-To: <A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
	<A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:30 +0000, Shriram Rajagopalan wrote:
> On 2012-02-01, at 8:02 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> =

> > On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:
> >> On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell wrote:
> >>> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan wrote:
> >>>> As for guests supporting this fast suspend, almost all guests (pv/hvm
> >>>> linux/windows) do support suspend_cancel. IIRC, I think some very old
> >>>> kernels didnt have this ability.
> >>> =

> >>> Slight aside, does Remus work with mainline Linux domU kernels? Users
> >>> seem to be under under that impression.
> >>> =

> >>> I know you had some patches at one point but I a) don't remember if t=
hey
> >>> went in and b) don't remember if they were sufficient.
> >>> =

> >> =

> >> http://wiki.xen.org/wiki/Remus
> >> "Linux 2.6.39.2 and later upstream kernel.org versions are now support=
ed as PV domU kernels"
> > =

> > Great, someone was suggesting on list that this wasn't the case. Must
> > dig out that mail and respond.
> > =

> > Ian.
> > =

> > =

> =

> I added the comments on top of the second version of the patch series.
> Please let me know if it looks okay.
> =

> I will be spinning out a V3 anyway, since Stefano has removed  qmp_migrat=
e.
> But this patch would remain the same, if it's current form is okay.

If you are respinning anyway then putting a comment in the header rather
than the implementation would be better since that is where users of the
library will be looking for it.

The comment from xc_resume.c which you copied explains the two modes but
doesn't actually say how the fast parameter relates to them. A better
comment to lift would be the description of @fast from xenctrl.h:

	"fast [means] use cooperative resume (guest must support this)"

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsrZl-0008Nu-C0; Thu, 02 Feb 2012 07:59: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 1RsrZk-0008Nf-Dp
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:59:24 +0000
Received: from [85.158.138.51:27327] by server-8.bemta-3.messagelabs.com id
	78/44-08780-B524A2F4; Thu, 02 Feb 2012 07:59:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328169562!11673162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 2 Feb 2012 07:59:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 07:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10429217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 07:59: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.213.0; Thu, 2 Feb 2012
	07:59:21 +0000
Message-ID: <1328169560.28964.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 2 Feb 2012 07:59:20 +0000
In-Reply-To: <CAP8mzPMe=EA55r4ZWcfVW7SOmuYu=_QGgKNUeN8T696xyeQ2zQ@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
	<A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
	<CAP8mzPMe=EA55r4ZWcfVW7SOmuYu=_QGgKNUeN8T696xyeQ2zQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 07:04 +0000, Shriram Rajagopalan wrote:
> 2012/2/1 Shriram Rajagopalan <rshriram@cs.ubc.ca>
>         On 2012-02-01, at 8:02 AM, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         =

>         > On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:
>         >> On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell
>         wrote:
>         >>> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan
>         wrote:
>         >>>> As for guests supporting this fast suspend, almost all
>         guests (pv/hvm
>         >>>> linux/windows) do support suspend_cancel. IIRC, I think
>         some very old
>         >>>> kernels didnt have this ability.
>         >>>
>         =

> =

> =

> xenstore entry, local/domain/<domid>/image/suspend-cancel - this entry
> indicates if the guest supports co-operative suspend or not. =

>  But unfortunately, I coundnt find any reference in xend, that
> "creates" this entry.  There are references in xen/ and the tools/
> folder, that read the SUSPEND_CANCEL entry,   like readnotes,
> XendDomainInfo.py, xen/common/libelf/libelf-dominfo.c =


The value of this setting needs to come from the kernel itself. In
arch/x86/xen/xen-head.S I see:
        ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long 1)

Is something (presumably the toolstack, in collaboration with libelf and
xc_dom_mumble) supposed to reflect this into XenStore somehow? (and
preserve it on migration etc etc)

It looks like xend just assumes it to be true, judging from the various =

	# TODO: currently assumes SUSPEND_CANCEL is available
comments. I guess assumption that just gets reflected into XS somewhere?

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 07:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 07:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsrZl-0008Nu-C0; Thu, 02 Feb 2012 07:59: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 1RsrZk-0008Nf-Dp
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 07:59:24 +0000
Received: from [85.158.138.51:27327] by server-8.bemta-3.messagelabs.com id
	78/44-08780-B524A2F4; Thu, 02 Feb 2012 07:59:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328169562!11673162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 2 Feb 2012 07:59:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 07:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10429217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 07:59: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.213.0; Thu, 2 Feb 2012
	07:59:21 +0000
Message-ID: <1328169560.28964.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 2 Feb 2012 07:59:20 +0000
In-Reply-To: <CAP8mzPMe=EA55r4ZWcfVW7SOmuYu=_QGgKNUeN8T696xyeQ2zQ@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
	<CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
	<1328093634.17444.59.camel@zakaz.uk.xensource.com>
	<20120201154821.GL12984@reaktio.net>
	<1328112163.17444.86.camel@zakaz.uk.xensource.com>
	<A1D4A426-207A-44B9-AB61-EBBA5515C003@cs.ubc.ca>
	<CAP8mzPMe=EA55r4ZWcfVW7SOmuYu=_QGgKNUeN8T696xyeQ2zQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 07:04 +0000, Shriram Rajagopalan wrote:
> 2012/2/1 Shriram Rajagopalan <rshriram@cs.ubc.ca>
>         On 2012-02-01, at 8:02 AM, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         =

>         > On Wed, 2012-02-01 at 15:48 +0000, Pasi K=E4rkk=E4inen wrote:
>         >> On Wed, Feb 01, 2012 at 10:53:54AM +0000, Ian Campbell
>         wrote:
>         >>> On Tue, 2012-01-31 at 17:52 +0000, Shriram Rajagopalan
>         wrote:
>         >>>> As for guests supporting this fast suspend, almost all
>         guests (pv/hvm
>         >>>> linux/windows) do support suspend_cancel. IIRC, I think
>         some very old
>         >>>> kernels didnt have this ability.
>         >>>
>         =

> =

> =

> xenstore entry, local/domain/<domid>/image/suspend-cancel - this entry
> indicates if the guest supports co-operative suspend or not. =

>  But unfortunately, I coundnt find any reference in xend, that
> "creates" this entry.  There are references in xen/ and the tools/
> folder, that read the SUSPEND_CANCEL entry,   like readnotes,
> XendDomainInfo.py, xen/common/libelf/libelf-dominfo.c =


The value of this setting needs to come from the kernel itself. In
arch/x86/xen/xen-head.S I see:
        ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long 1)

Is something (presumably the toolstack, in collaboration with libelf and
xc_dom_mumble) supposed to reflect this into XenStore somehow? (and
preserve it on migration etc etc)

It looks like xend just assumes it to be true, judging from the various =

	# TODO: currently assumes SUSPEND_CANCEL is available
comments. I guess assumption that just gets reflected into XS somewhere?

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 08:58:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 08:58:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RssU4-0002By-VH; Thu, 02 Feb 2012 08:57:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RssU3-0002Bt-W1
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 08:57:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328173049!2152527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32139 invoked from network); 2 Feb 2012 08:57:29 -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;
	2 Feb 2012 08:57:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10430365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 08:57:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 08:57:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RssTw-0005n6-Hk;
	Thu, 02 Feb 2012 08:57:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RssTo-0008ND-Le;
	Thu, 02 Feb 2012 08:57:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11818-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 08:57:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11818: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11818 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11818/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 08:58:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 08:58:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RssU4-0002By-VH; Thu, 02 Feb 2012 08:57:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RssU3-0002Bt-W1
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 08:57:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328173049!2152527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Njg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32139 invoked from network); 2 Feb 2012 08:57:29 -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;
	2 Feb 2012 08:57:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10430365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 08:57:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 08:57:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RssTw-0005n6-Hk;
	Thu, 02 Feb 2012 08:57:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RssTo-0008ND-Le;
	Thu, 02 Feb 2012 08:57:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11818-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 08:57:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11818: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11818 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11818/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 09:06:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 09:06:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsscH-0002QW-E8; Thu, 02 Feb 2012 09:06: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 1RsscG-0002QR-2D
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 09:06:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328173525!50768855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19507 invoked from network); 2 Feb 2012 09:05:26 -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;
	2 Feb 2012 09:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10430570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 09:06:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	09:06:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 2 Feb 2012 09:06:02 +0000
In-Reply-To: <1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328173562.17444.108.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 3/8] libflask: Add boolean manipulation
 functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
> Add wrappers for getting and setting policy booleans by name or ID.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
>  tools/flask/libflask/include/libflask.h |    3 ++
>  2 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
> index d4b8ef0..412a05d 100644
> --- a/tools/flask/libflask/flask_op.c
> +++ b/tools/flask/libflask/flask_op.c
> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
>      return 0;
>  }
>  
> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
> +{
> +    flask_op_t op;
> +    char buf[255];
> +    int rv;
> +
> +    op.cmd = FLASK_GETBOOL2;
> +    op.buf = buf;
> +    op.size = 255;

sizeof(buf)? Here and elsewhere (including a few existing locations in
flask_op.c).

> +
> +    snprintf(buf, sizeof buf, "%i", id);
> +
> +    rv = xc_flask_op(xc_handle, &op);
> +
> +    if ( rv )
> +        return rv;
> +    
> +    sscanf(buf, "%i %i %s", curr, pend, name);

Do you care about sscanf failures?

It seems from other uses in the file that buf can contain binary data so
would it make sense to make this two ints as binary followed by a
string? That would remove string parsing here and in the hypervisor
(which seems more critical to me?)

Is there a defined maximum for the length of "name"?

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 09:06:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 09:06:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsscH-0002QW-E8; Thu, 02 Feb 2012 09:06: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 1RsscG-0002QR-2D
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 09:06:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328173525!50768855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19507 invoked from network); 2 Feb 2012 09:05:26 -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;
	2 Feb 2012 09:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10430570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 09:06:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	09:06:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 2 Feb 2012 09:06:02 +0000
In-Reply-To: <1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328173562.17444.108.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 3/8] libflask: Add boolean manipulation
 functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
> Add wrappers for getting and setting policy booleans by name or ID.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
>  tools/flask/libflask/include/libflask.h |    3 ++
>  2 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
> index d4b8ef0..412a05d 100644
> --- a/tools/flask/libflask/flask_op.c
> +++ b/tools/flask/libflask/flask_op.c
> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
>      return 0;
>  }
>  
> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
> +{
> +    flask_op_t op;
> +    char buf[255];
> +    int rv;
> +
> +    op.cmd = FLASK_GETBOOL2;
> +    op.buf = buf;
> +    op.size = 255;

sizeof(buf)? Here and elsewhere (including a few existing locations in
flask_op.c).

> +
> +    snprintf(buf, sizeof buf, "%i", id);
> +
> +    rv = xc_flask_op(xc_handle, &op);
> +
> +    if ( rv )
> +        return rv;
> +    
> +    sscanf(buf, "%i %i %s", curr, pend, name);

Do you care about sscanf failures?

It seems from other uses in the file that buf can contain binary data so
would it make sense to make this two ints as binary followed by a
string? That would remove string parsing here and in the hypervisor
(which seems more critical to me?)

Is there a defined maximum for the length of "name"?

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 09:12:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 09: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.xensource.com>)
	id 1RssiO-0002ZQ-9x; Thu, 02 Feb 2012 09:12:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RssiM-0002ZI-VQ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 09:12:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328173935!13388501!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTk5Njc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18742 invoked from network); 2 Feb 2012 09:12:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 09:12: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 5552110C2;
	Thu,  2 Feb 2012 11:12:15 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3A6DE20058; Thu,  2 Feb 2012 11:12:15 +0200 (EET)
Date: Thu, 2 Feb 2012 11:12:15 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: feisky <feiskyer@gmail.com>
Message-ID: <20120202091214.GN12984@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
	<1328099398393-5447334.post@n5.nabble.com>
	<20120201155123.GM12984@reaktio.net>
	<CAJ44hTfqRtVEWej2hWGVRBt=Y+HsA6ajG4Qvy4dq8h3r88m+7w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ44hTfqRtVEWej2hWGVRBt=Y+HsA6ajG4Qvy4dq8h3r88m+7w@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen guest disk online resize,
	xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgMDEsIDIwMTIgYXQgMDk6MzE6NTRQTSAtMDgwMCwgZmVpc2t5IHdyb3RlOgo+
ICAgIENvdWxkIHlvdSBzZW5kIHlvdXIgcGF0Y2ggdG8gbWU/w4IKPiAgICB0aGFua3MuCj4gCgpJ
dCBkb2Vzbid0IHJlcXVpcmUgcGF0Y2hlcy4gU3VwcG9ydCBmb3Igb25saW5lIGRvbVUgZGlzayBy
ZXNpemUKaXMgaW4gdXBzdHJlYW0ga2VybmVsLm9yZyBrZXJuZWxzIChhbmQgaW4gcmhlbC9zbGVz
IHZlbmRvciBrZXJuZWxzKS4KCkl0IG9ubHkgcmVxdWlyZXMgc3VwcG9ydCBmcm9tIHhlbi1ibGti
YWNrIGFuZCB4ZW4tYmxrZnJvbnQsCmFuZCBMVk0gdm9sdW1lcyBpbiBkb20wLgoKLS0gUGFzaQoK
PiAgICBPbiBXZWQsIEZlYiAxLCAyMDEyIGF0IDExOjUyIFBNLCBQYXNpIEvDg+KCrHJra8OD4oKs
aW5lbiBbdmlhIFhlbl0gPFsxXVtoaWRkZW4KPiAgICBlbWFpbF0+IHdyb3RlOgo+IAo+ICAgICAg
T24gV2VkLCBGZWIgMDEsIDIwMTIgYXQgMDQ6Mjk6NThBTSAtMDgwMCwgZmVpc2t5IHdyb3RlOgo+
ICAgICAgPiBIYXMgYW55b25lIHRyaWVkIGlzIHRoaXMgbWV0aG9kIG9rPwo+ICAgICAgPgo+IAo+
ICAgICAgWWVwLCBJJ3ZlIHVzZWQgaXQsIGFuZCB2ZXJpZmllZCBpdCB3b3Jrcy4KPiAKPiAgICAg
IC0tIFBhc2kKPiAKPiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCj4gICAgICBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gICAgICBbMl1baGlkZGVu
IGVtYWlsXQo+ICAgICAgWzNdaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4g
Cj4gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiAgICAgIElmIHlvdSByZXBseSB0byB0aGlzIGVt
YWlsLCB5b3VyIG1lc3NhZ2Ugd2lsbCBiZSBhZGRlZCB0byB0aGUgZGlzY3Vzc2lvbgo+ICAgICAg
YmVsb3c6Cj4gICAgICBbNF1odHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9YZW4tZ3Vl
c3QtZGlzay1vbmxpbmUtcmVzaXplLXhlbnN0b3JlLWJsa2JhY2stYmxrZnJvbnQtcXVlc3Rpb25z
LXRwMjU0Nzg0N3A1NDQ3ODg4Lmh0bWwKPiAgICAgIFRvIHVuc3Vic2NyaWJlIGZyb20gWGVuIGd1
ZXN0IGRpc2sgb25saW5lIHJlc2l6ZSwKPiAgICAgIHhlbnN0b3JlL2Jsa2JhY2svYmxrZnJvbnQg
cXVlc3Rpb25zLCBbNV1jbGljayBoZXJlLgo+ICAgICAgWzZdTkFNTAo+IAo+ICAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiAgICBWaWV3IHRoaXMgbWVz
c2FnZSBpbiBjb250ZXh0OiBbN11SZTogWGVuIGd1ZXN0IGRpc2sgb25saW5lIHJlc2l6ZSwKPiAg
ICB4ZW5zdG9yZS9ibGtiYWNrL2Jsa2Zyb250IHF1ZXN0aW9ucwo+ICAgIFNlbnQgZnJvbSB0aGUg
WzhdWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCj4gCj4gUmVm
ZXJlbmNlcwo+IAo+ICAgIFZpc2libGUgbGlua3MKPiAgICAxLiBmaWxlOi8vL3VzZXIvU2VuZEVt
YWlsLmp0cD90eXBlPW5vZGUmbm9kZT01NDQ5NjYxJmk9MAo+ICAgIDIuIGh0dHA6Ly91c2VyL1Nl
bmRFbWFpbC5qdHA/dHlwZT1ub2RlJm5vZGU9NTQ0Nzg4OCZpPTAKPiAgICAzLiBodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPiAgICA0LiBodHRwOi8veGVuLjEwNDU3MTIubjUu
bmFiYmxlLmNvbS9YZW4tZ3Vlc3QtZGlzay1vbmxpbmUtcmVzaXplLXhlbnN0b3JlLWJsa2JhY2st
YmxrZnJvbnQtcXVlc3Rpb25zLXRwMjU0Nzg0N3A1NDQ3ODg4Lmh0bWwKPiAgICA1LiBmaWxlOi8v
L3RtcC8KPiAgICA2LiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS90ZW1wbGF0ZS9O
YW1sU2VydmxldC5qdHA/bWFjcm89bWFjcm9fdmlld2VyJmlkPWluc3RhbnRfaHRtbCUyMW5hYmJs
ZSUzQWVtYWlsLm5hbWwmYmFzZT1uYWJibGUubmFtbC5uYW1lc3BhY2VzLkJhc2ljTmFtZXNwYWNl
LW5hYmJsZS52aWV3LndlYi50ZW1wbGF0ZS5OYWJibGVOYW1lc3BhY2UtbmFiYmxlLnZpZXcud2Vi
LnRlbXBsYXRlLk5vZGVOYW1lc3BhY2UmYnJlYWRjcnVtYnM9bm90aWZ5X3N1YnNjcmliZXJzJTIx
bmFiYmxlJTNBZW1haWwubmFtbC1pbnN0YW50X2VtYWlscyUyMW5hYmJsZSUzQWVtYWlsLm5hbWwt
c2VuZF9pbnN0YW50X2VtYWlsJTIxbmFiYmxlJTNBZW1haWwubmFtbAo+ICAgIDcuIGh0dHA6Ly94
ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL1hlbi1ndWVzdC1kaXNrLW9ubGluZS1yZXNpemUteGVu
c3RvcmUtYmxrYmFjay1ibGtmcm9udC1xdWVzdGlvbnMtdHAyNTQ3ODQ3cDU0NDk2NjEuaHRtbAo+
ICAgIDguIGh0dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL1hlbi1EZXYtZjI0NzM3Mzgu
aHRtbAoKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+
IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 09:12:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 09: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.xensource.com>)
	id 1RssiO-0002ZQ-9x; Thu, 02 Feb 2012 09:12:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RssiM-0002ZI-VQ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 09:12:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328173935!13388501!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTk5Njc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18742 invoked from network); 2 Feb 2012 09:12:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 09:12: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 5552110C2;
	Thu,  2 Feb 2012 11:12:15 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3A6DE20058; Thu,  2 Feb 2012 11:12:15 +0200 (EET)
Date: Thu, 2 Feb 2012 11:12:15 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: feisky <feiskyer@gmail.com>
Message-ID: <20120202091214.GN12984@reaktio.net>
References: <20100106202631.GK25902@reaktio.net>
	<1328099398393-5447334.post@n5.nabble.com>
	<20120201155123.GM12984@reaktio.net>
	<CAJ44hTfqRtVEWej2hWGVRBt=Y+HsA6ajG4Qvy4dq8h3r88m+7w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ44hTfqRtVEWej2hWGVRBt=Y+HsA6ajG4Qvy4dq8h3r88m+7w@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen guest disk online resize,
	xenstore/blkback/blkfront questions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgMDEsIDIwMTIgYXQgMDk6MzE6NTRQTSAtMDgwMCwgZmVpc2t5IHdyb3RlOgo+
ICAgIENvdWxkIHlvdSBzZW5kIHlvdXIgcGF0Y2ggdG8gbWU/w4IKPiAgICB0aGFua3MuCj4gCgpJ
dCBkb2Vzbid0IHJlcXVpcmUgcGF0Y2hlcy4gU3VwcG9ydCBmb3Igb25saW5lIGRvbVUgZGlzayBy
ZXNpemUKaXMgaW4gdXBzdHJlYW0ga2VybmVsLm9yZyBrZXJuZWxzIChhbmQgaW4gcmhlbC9zbGVz
IHZlbmRvciBrZXJuZWxzKS4KCkl0IG9ubHkgcmVxdWlyZXMgc3VwcG9ydCBmcm9tIHhlbi1ibGti
YWNrIGFuZCB4ZW4tYmxrZnJvbnQsCmFuZCBMVk0gdm9sdW1lcyBpbiBkb20wLgoKLS0gUGFzaQoK
PiAgICBPbiBXZWQsIEZlYiAxLCAyMDEyIGF0IDExOjUyIFBNLCBQYXNpIEvDg+KCrHJra8OD4oKs
aW5lbiBbdmlhIFhlbl0gPFsxXVtoaWRkZW4KPiAgICBlbWFpbF0+IHdyb3RlOgo+IAo+ICAgICAg
T24gV2VkLCBGZWIgMDEsIDIwMTIgYXQgMDQ6Mjk6NThBTSAtMDgwMCwgZmVpc2t5IHdyb3RlOgo+
ICAgICAgPiBIYXMgYW55b25lIHRyaWVkIGlzIHRoaXMgbWV0aG9kIG9rPwo+ICAgICAgPgo+IAo+
ICAgICAgWWVwLCBJJ3ZlIHVzZWQgaXQsIGFuZCB2ZXJpZmllZCBpdCB3b3Jrcy4KPiAKPiAgICAg
IC0tIFBhc2kKPiAKPiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCj4gICAgICBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gICAgICBbMl1baGlkZGVu
IGVtYWlsXQo+ICAgICAgWzNdaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4g
Cj4gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiAgICAgIElmIHlvdSByZXBseSB0byB0aGlzIGVt
YWlsLCB5b3VyIG1lc3NhZ2Ugd2lsbCBiZSBhZGRlZCB0byB0aGUgZGlzY3Vzc2lvbgo+ICAgICAg
YmVsb3c6Cj4gICAgICBbNF1odHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9YZW4tZ3Vl
c3QtZGlzay1vbmxpbmUtcmVzaXplLXhlbnN0b3JlLWJsa2JhY2stYmxrZnJvbnQtcXVlc3Rpb25z
LXRwMjU0Nzg0N3A1NDQ3ODg4Lmh0bWwKPiAgICAgIFRvIHVuc3Vic2NyaWJlIGZyb20gWGVuIGd1
ZXN0IGRpc2sgb25saW5lIHJlc2l6ZSwKPiAgICAgIHhlbnN0b3JlL2Jsa2JhY2svYmxrZnJvbnQg
cXVlc3Rpb25zLCBbNV1jbGljayBoZXJlLgo+ICAgICAgWzZdTkFNTAo+IAo+ICAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiAgICBWaWV3IHRoaXMgbWVz
c2FnZSBpbiBjb250ZXh0OiBbN11SZTogWGVuIGd1ZXN0IGRpc2sgb25saW5lIHJlc2l6ZSwKPiAg
ICB4ZW5zdG9yZS9ibGtiYWNrL2Jsa2Zyb250IHF1ZXN0aW9ucwo+ICAgIFNlbnQgZnJvbSB0aGUg
WzhdWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCj4gCj4gUmVm
ZXJlbmNlcwo+IAo+ICAgIFZpc2libGUgbGlua3MKPiAgICAxLiBmaWxlOi8vL3VzZXIvU2VuZEVt
YWlsLmp0cD90eXBlPW5vZGUmbm9kZT01NDQ5NjYxJmk9MAo+ICAgIDIuIGh0dHA6Ly91c2VyL1Nl
bmRFbWFpbC5qdHA/dHlwZT1ub2RlJm5vZGU9NTQ0Nzg4OCZpPTAKPiAgICAzLiBodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPiAgICA0LiBodHRwOi8veGVuLjEwNDU3MTIubjUu
bmFiYmxlLmNvbS9YZW4tZ3Vlc3QtZGlzay1vbmxpbmUtcmVzaXplLXhlbnN0b3JlLWJsa2JhY2st
YmxrZnJvbnQtcXVlc3Rpb25zLXRwMjU0Nzg0N3A1NDQ3ODg4Lmh0bWwKPiAgICA1LiBmaWxlOi8v
L3RtcC8KPiAgICA2LiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS90ZW1wbGF0ZS9O
YW1sU2VydmxldC5qdHA/bWFjcm89bWFjcm9fdmlld2VyJmlkPWluc3RhbnRfaHRtbCUyMW5hYmJs
ZSUzQWVtYWlsLm5hbWwmYmFzZT1uYWJibGUubmFtbC5uYW1lc3BhY2VzLkJhc2ljTmFtZXNwYWNl
LW5hYmJsZS52aWV3LndlYi50ZW1wbGF0ZS5OYWJibGVOYW1lc3BhY2UtbmFiYmxlLnZpZXcud2Vi
LnRlbXBsYXRlLk5vZGVOYW1lc3BhY2UmYnJlYWRjcnVtYnM9bm90aWZ5X3N1YnNjcmliZXJzJTIx
bmFiYmxlJTNBZW1haWwubmFtbC1pbnN0YW50X2VtYWlscyUyMW5hYmJsZSUzQWVtYWlsLm5hbWwt
c2VuZF9pbnN0YW50X2VtYWlsJTIxbmFiYmxlJTNBZW1haWwubmFtbAo+ICAgIDcuIGh0dHA6Ly94
ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL1hlbi1ndWVzdC1kaXNrLW9ubGluZS1yZXNpemUteGVu
c3RvcmUtYmxrYmFjay1ibGtmcm9udC1xdWVzdGlvbnMtdHAyNTQ3ODQ3cDU0NDk2NjEuaHRtbAo+
ICAgIDguIGh0dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL1hlbi1EZXYtZjI0NzM3Mzgu
aHRtbAoKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+
IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 09:50:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 09:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RstJ5-0003EJ-HA; Thu, 02 Feb 2012 09:50:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RstJ3-0003EE-PJ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 09:50:18 +0000
Received: from [85.158.138.51:55692] by server-7.bemta-3.messagelabs.com id
	D0/B2-28646-85C5A2F4; Thu, 02 Feb 2012 09:50:16 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328176213!11615175!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNTU=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNTU=\n,HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13436 invoked from network); 2 Feb 2012 09:50:15 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-3.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 09:50:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=earEvh7//5kSIiLMPxGG5/TeYlPVKoJgwD
	oxp7BVYpI=; b=YbYfhn7KXq49DLzp6WuuvyBBSu0Ibwd4DJLRw4B7Ud5KVjkmfF
	7DOrn/JCa5NxE6Xio7rgfe+zLdFoaI2xTNFrsX57JR+x8YnfdMt1FBPArwtT2N/v
	BoQQIDUrv/NJamz7mI2OeLkG28KIyNFlKIkY/jJK8Q0jZy5mnVthSoHN4=
Received: from hxkhust ( [211.69.198.241] ) by ajax-webmail-wmsvr25
	(Coremail) ; Thu, 2 Feb 2012 17:50:07 +0800 (CST)
Date: Thu, 2 Feb 2012 17:50:07 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <1ca8a9b.1eafe.1353d7896db.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [211.69.198.241]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: 24h9YGZvb3Rlcl9odG09OTUxOjgx
X-CM-TRANSID: GcqowGDZf0FQXCpPMQULAA--.730W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiEwJIBU0vJTFqFAABsV
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] About Page Cache In Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2832872364246821424=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2832872364246821424==
Content-Type: multipart/alternative; 
	boundary="----=_Part_332798_1777203717.1328176207579"

------=_Part_332798_1777203717.1328176207579
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
 
As far as we know,due to linux filesystem,if a page cached in memroy is needed by some process,the process get it from the memory rather than the disk device.On xen platform,under most condition,we use full-virtualization VMs' virtual disk image files as  templets.Thus some other full-virtualization VMs based on these templets  will share the page data in the templets.
Here some questions puzzled me.Is the VMM aware of the pages cached in VMs?Are VMs to be the VMM what processes to the operating system on which they are running?if a page which is cached in the VM A and come from the templet is needed by another VM B,does the VM B get it from the VM A's memory?
thank you for your help.
 
hxk  
------=_Part_332798_1777203717.1328176207579
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>As far as we know,due to linux filesystem,if a page cached in memroy is needed by some process,the process&nbsp;get it from the memory&nbsp;rather than the disk device.On xen platform,under most condition,we use full-virtualization VMs' virtual disk image files as&nbsp; templets.Thus some other full-virtualization VMs&nbsp;based on these templets&nbsp;&nbsp;will share the page data in the templets.</DIV>
<DIV>Here some questions puzzled me.Is the VMM&nbsp;aware of the pages cached in VMs?Are VMs to be the VMM what processes to the operating system on which they are running?if a page which is cached in&nbsp;the&nbsp;VM A&nbsp;and come from the templet is needed by&nbsp;another VM B,does&nbsp;the VM B&nbsp;get it from the VM A's memory?</DIV>
<DIV>thank you for your help.</DIV>
<DIV>&nbsp;</DIV>
<DIV>hxk&nbsp;&nbsp;</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_332798_1777203717.1328176207579--



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

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

--===============2832872364246821424==--



From xen-devel-bounces@lists.xensource.com Thu Feb 02 09:50:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 09:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RstJ5-0003EJ-HA; Thu, 02 Feb 2012 09:50:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RstJ3-0003EE-PJ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 09:50:18 +0000
Received: from [85.158.138.51:55692] by server-7.bemta-3.messagelabs.com id
	D0/B2-28646-85C5A2F4; Thu, 02 Feb 2012 09:50:16 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328176213!11615175!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNTU=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNTU=\n,HTML_30_40,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13436 invoked from network); 2 Feb 2012 09:50:15 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-3.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 09:50:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=earEvh7//5kSIiLMPxGG5/TeYlPVKoJgwD
	oxp7BVYpI=; b=YbYfhn7KXq49DLzp6WuuvyBBSu0Ibwd4DJLRw4B7Ud5KVjkmfF
	7DOrn/JCa5NxE6Xio7rgfe+zLdFoaI2xTNFrsX57JR+x8YnfdMt1FBPArwtT2N/v
	BoQQIDUrv/NJamz7mI2OeLkG28KIyNFlKIkY/jJK8Q0jZy5mnVthSoHN4=
Received: from hxkhust ( [211.69.198.241] ) by ajax-webmail-wmsvr25
	(Coremail) ; Thu, 2 Feb 2012 17:50:07 +0800 (CST)
Date: Thu, 2 Feb 2012 17:50:07 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <1ca8a9b.1eafe.1353d7896db.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [211.69.198.241]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: 24h9YGZvb3Rlcl9odG09OTUxOjgx
X-CM-TRANSID: GcqowGDZf0FQXCpPMQULAA--.730W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiEwJIBU0vJTFqFAABsV
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] About Page Cache In Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2832872364246821424=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2832872364246821424==
Content-Type: multipart/alternative; 
	boundary="----=_Part_332798_1777203717.1328176207579"

------=_Part_332798_1777203717.1328176207579
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
 
As far as we know,due to linux filesystem,if a page cached in memroy is needed by some process,the process get it from the memory rather than the disk device.On xen platform,under most condition,we use full-virtualization VMs' virtual disk image files as  templets.Thus some other full-virtualization VMs based on these templets  will share the page data in the templets.
Here some questions puzzled me.Is the VMM aware of the pages cached in VMs?Are VMs to be the VMM what processes to the operating system on which they are running?if a page which is cached in the VM A and come from the templet is needed by another VM B,does the VM B get it from the VM A's memory?
thank you for your help.
 
hxk  
------=_Part_332798_1777203717.1328176207579
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>As far as we know,due to linux filesystem,if a page cached in memroy is needed by some process,the process&nbsp;get it from the memory&nbsp;rather than the disk device.On xen platform,under most condition,we use full-virtualization VMs' virtual disk image files as&nbsp; templets.Thus some other full-virtualization VMs&nbsp;based on these templets&nbsp;&nbsp;will share the page data in the templets.</DIV>
<DIV>Here some questions puzzled me.Is the VMM&nbsp;aware of the pages cached in VMs?Are VMs to be the VMM what processes to the operating system on which they are running?if a page which is cached in&nbsp;the&nbsp;VM A&nbsp;and come from the templet is needed by&nbsp;another VM B,does&nbsp;the VM B&nbsp;get it from the VM A's memory?</DIV>
<DIV>thank you for your help.</DIV>
<DIV>&nbsp;</DIV>
<DIV>hxk&nbsp;&nbsp;</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_332798_1777203717.1328176207579--



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

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

--===============2832872364246821424==--



From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:18:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RstjF-0003pC-QK; Thu, 02 Feb 2012 10:17:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1RstjE-0003p7-92
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 10:17:20 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328177833!12600646!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27261 invoked from network); 2 Feb 2012 10:17:14 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 10:17:14 -0000
Received: by iaeh11 with SMTP id h11so11800110iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 02:17:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=uPqo5aRzxCe51M8cs2HH3xHiqYwWsbyefpqTro6wafc=;
	b=e+sAlrQXLokAYZvMlrdmJ03QWdJjld66yZ31+T+ioNL5AfDknCf6a+L5LCqJsehESz
	TW7IGKOxgsY2+342NBZcnOVUXCA2S9nqp3TTY2DT5gGKXYBvXNu22FLV1opgEUoJAlWE
	/JcVnC8sPSM+AhgTT11gZ5FZ7uJw0QvSEox9o=
Received: by 10.50.140.105 with SMTP id rf9mr7210182igb.24.1328177832868;
	Thu, 02 Feb 2012 02:17:12 -0800 (PST)
Received: from [112.22.177.46] ([112.22.177.46])
	by mx.google.com with ESMTPS id ut1sm3300317igc.2.2012.02.02.02.17.09
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 02:17:11 -0800 (PST)
Message-ID: <4F2A62A2.1010505@gmail.com>
Date: Thu, 02 Feb 2012 18:17:06 +0800
From: "nai.xia" <nai.xia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Joe Epstein <jepstein98@gmail.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: [Xen-devel] Is this a data corruption bug for p2m_ram_shared page
	in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

In hvm_hap_nested_page_fault(), it seems that all valid write faults are now handled
by p2m_mem_access_check(), right? Then when will mem_sharing_unshare_page()
be called? And if p2m->access_required == false, the access restrictions is cleared
, then the data in this shared page could be corrupted by this page write access?


Thanks,

Nai

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:18:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RstjF-0003pC-QK; Thu, 02 Feb 2012 10:17:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1RstjE-0003p7-92
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 10:17:20 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328177833!12600646!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27261 invoked from network); 2 Feb 2012 10:17:14 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 10:17:14 -0000
Received: by iaeh11 with SMTP id h11so11800110iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 02:17:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:content-type:content-transfer-encoding;
	bh=uPqo5aRzxCe51M8cs2HH3xHiqYwWsbyefpqTro6wafc=;
	b=e+sAlrQXLokAYZvMlrdmJ03QWdJjld66yZ31+T+ioNL5AfDknCf6a+L5LCqJsehESz
	TW7IGKOxgsY2+342NBZcnOVUXCA2S9nqp3TTY2DT5gGKXYBvXNu22FLV1opgEUoJAlWE
	/JcVnC8sPSM+AhgTT11gZ5FZ7uJw0QvSEox9o=
Received: by 10.50.140.105 with SMTP id rf9mr7210182igb.24.1328177832868;
	Thu, 02 Feb 2012 02:17:12 -0800 (PST)
Received: from [112.22.177.46] ([112.22.177.46])
	by mx.google.com with ESMTPS id ut1sm3300317igc.2.2012.02.02.02.17.09
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 02:17:11 -0800 (PST)
Message-ID: <4F2A62A2.1010505@gmail.com>
Date: Thu, 02 Feb 2012 18:17:06 +0800
From: "nai.xia" <nai.xia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Joe Epstein <jepstein98@gmail.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: [Xen-devel] Is this a data corruption bug for p2m_ram_shared page
	in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

In hvm_hap_nested_page_fault(), it seems that all valid write faults are now handled
by p2m_mem_access_check(), right? Then when will mem_sharing_unshare_page()
be called? And if p2m->access_required == false, the access restrictions is cleared
, then the data in this shared page could be corrupted by this page write access?


Thanks,

Nai

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:26:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10: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.xensource.com>)
	id 1RstrU-0004HO-PX; Thu, 02 Feb 2012 10:25:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1RstrS-0004HJ-V4
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 10:25:51 +0000
Received: from [85.158.138.51:55411] by server-9.bemta-3.messagelabs.com id
	96/E4-21252-EA46A2F4; Thu, 02 Feb 2012 10:25:50 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328178348!11622179!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15744 invoked from network); 2 Feb 2012 10:25:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 10:25:49 -0000
Received: by iaeh11 with SMTP id h11so11839031iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 02:25:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=Q4juELbZ/Z/sA0IA2Kzo7zJxGlbuO0Jyhw27sXhQe6Q=;
	b=hlWOEsOI6GLObMTrjLF/gtfoJWpt6xOIJPtq6OV6Z06s+jIJGLIiMEqcP7IO6xL9Ad
	nS+1e0gkVOwyruI/4JtB9d54vebOYE552WqQPsT9wArhAjoIhyWPXwnv1ahV0mWqs5zW
	iJwyUmR7O6FxLWyPKxsHzm7ax9ahkDSsVies8=
Received: by 10.43.47.135 with SMTP id us7mr1993203icb.31.1328178347724;
	Thu, 02 Feb 2012 02:25:47 -0800 (PST)
Received: from [112.22.177.46] ([112.22.177.46])
	by mx.google.com with ESMTPS id d15sm4200650ibf.7.2012.02.02.02.25.45
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 02:25:46 -0800 (PST)
Message-ID: <4F2A64A7.9080902@gmail.com>
Date: Thu, 02 Feb 2012 18:25:43 +0800
From: "nai.xia" <nai.xia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Joe Epstein <jepstein98@gmail.com>
References: <4F2A62A2.1010505@gmail.com>
In-Reply-To: <4F2A62A2.1010505@gmail.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] Is this a data corruption bug for p2m_ram_shared
	page in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgpPbiAyMDEy5bm0MDLmnIgwMuaXpSAxODoxNywgbmFpLnhpYSB3cm90ZToKPiBIaSwKPgo+IElu
IGh2bV9oYXBfbmVzdGVkX3BhZ2VfZmF1bHQoKSwgaXQgc2VlbXMgdGhhdCBhbGwgdmFsaWQgd3Jp
dGUgZmF1bHRzIGFyZSBub3cgaGFuZGxlZAo+IGJ5IHAybV9tZW1fYWNjZXNzX2NoZWNrKCksIHJp
Z2h0PyBUaGVuIHdoZW4gd2lsbCBtZW1fc2hhcmluZ191bnNoYXJlX3BhZ2UoKQo+IGJlIGNhbGxl
ZD8gQW5kIGlmIHAybS0+YWNjZXNzX3JlcXVpcmVkID09IGZhbHNlLCB0aGUgYWNjZXNzIHJlc3Ry
aWN0aW9ucyBpcyBjbGVhcmVkCgpPaCwgc29ycnksIEkgbm90aWNlIHRoYXQgd2l0aCBwMm1fcmFt
X3NoYXJlZCwgdGhlIHdyaXRlIHBlcm1pc3Npb25zIGlzIGFsd2F5cyBjbGVhcmVkLgpCdXQsIHN0
aWxsLCB0aGlzIHNlZW1zIGNhbm5vdCBsZWFkIHRvIHRoZSBjYWxsIG9mIG1lbV9zaGFyaW5nX3Vu
c2hhcmVfcGFnZSgpIGFuZCB0aGlzCndyaXRlIGZhdWx0IHdpbGwgaGFwcGVuIGFnYWluIGFuZCBh
Z2Fpbj8KCgpUaGFua3MsCgpOYWkKCgo+ICwgdGhlbiB0aGUgZGF0YSBpbiB0aGlzIHNoYXJlZCBw
YWdlIGNvdWxkIGJlIGNvcnJ1cHRlZCBieSB0aGlzIHBhZ2Ugd3JpdGUgYWNjZXNzPwo+Cj4KPiBU
aGFua3MsCj4KPiBOYWkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:26:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10: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.xensource.com>)
	id 1RstrU-0004HO-PX; Thu, 02 Feb 2012 10:25:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1RstrS-0004HJ-V4
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 10:25:51 +0000
Received: from [85.158.138.51:55411] by server-9.bemta-3.messagelabs.com id
	96/E4-21252-EA46A2F4; Thu, 02 Feb 2012 10:25:50 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328178348!11622179!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15744 invoked from network); 2 Feb 2012 10:25:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 10:25:49 -0000
Received: by iaeh11 with SMTP id h11so11839031iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 02:25:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=Q4juELbZ/Z/sA0IA2Kzo7zJxGlbuO0Jyhw27sXhQe6Q=;
	b=hlWOEsOI6GLObMTrjLF/gtfoJWpt6xOIJPtq6OV6Z06s+jIJGLIiMEqcP7IO6xL9Ad
	nS+1e0gkVOwyruI/4JtB9d54vebOYE552WqQPsT9wArhAjoIhyWPXwnv1ahV0mWqs5zW
	iJwyUmR7O6FxLWyPKxsHzm7ax9ahkDSsVies8=
Received: by 10.43.47.135 with SMTP id us7mr1993203icb.31.1328178347724;
	Thu, 02 Feb 2012 02:25:47 -0800 (PST)
Received: from [112.22.177.46] ([112.22.177.46])
	by mx.google.com with ESMTPS id d15sm4200650ibf.7.2012.02.02.02.25.45
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 02:25:46 -0800 (PST)
Message-ID: <4F2A64A7.9080902@gmail.com>
Date: Thu, 02 Feb 2012 18:25:43 +0800
From: "nai.xia" <nai.xia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Joe Epstein <jepstein98@gmail.com>
References: <4F2A62A2.1010505@gmail.com>
In-Reply-To: <4F2A62A2.1010505@gmail.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] Is this a data corruption bug for p2m_ram_shared
	page in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgpPbiAyMDEy5bm0MDLmnIgwMuaXpSAxODoxNywgbmFpLnhpYSB3cm90ZToKPiBIaSwKPgo+IElu
IGh2bV9oYXBfbmVzdGVkX3BhZ2VfZmF1bHQoKSwgaXQgc2VlbXMgdGhhdCBhbGwgdmFsaWQgd3Jp
dGUgZmF1bHRzIGFyZSBub3cgaGFuZGxlZAo+IGJ5IHAybV9tZW1fYWNjZXNzX2NoZWNrKCksIHJp
Z2h0PyBUaGVuIHdoZW4gd2lsbCBtZW1fc2hhcmluZ191bnNoYXJlX3BhZ2UoKQo+IGJlIGNhbGxl
ZD8gQW5kIGlmIHAybS0+YWNjZXNzX3JlcXVpcmVkID09IGZhbHNlLCB0aGUgYWNjZXNzIHJlc3Ry
aWN0aW9ucyBpcyBjbGVhcmVkCgpPaCwgc29ycnksIEkgbm90aWNlIHRoYXQgd2l0aCBwMm1fcmFt
X3NoYXJlZCwgdGhlIHdyaXRlIHBlcm1pc3Npb25zIGlzIGFsd2F5cyBjbGVhcmVkLgpCdXQsIHN0
aWxsLCB0aGlzIHNlZW1zIGNhbm5vdCBsZWFkIHRvIHRoZSBjYWxsIG9mIG1lbV9zaGFyaW5nX3Vu
c2hhcmVfcGFnZSgpIGFuZCB0aGlzCndyaXRlIGZhdWx0IHdpbGwgaGFwcGVuIGFnYWluIGFuZCBh
Z2Fpbj8KCgpUaGFua3MsCgpOYWkKCgo+ICwgdGhlbiB0aGUgZGF0YSBpbiB0aGlzIHNoYXJlZCBw
YWdlIGNvdWxkIGJlIGNvcnJ1cHRlZCBieSB0aGlzIHBhZ2Ugd3JpdGUgYWNjZXNzPwo+Cj4KPiBU
aGFua3MsCj4KPiBOYWkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHp-0004pP-Fb; Thu, 02 Feb 2012 10:53:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RsY84-0005T2-Cu; Wed, 01 Feb 2012 11:13:32 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328094804!4957027!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30772 invoked from network); 1 Feb 2012 11:13:25 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 11:13:25 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q11BBBmn027031;
	Wed, 1 Feb 2012 13:11:12 +0200
Message-ID: <5B696C874F614E368C693BA9534772C6@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Likarpenkov Alexander" <al@ohosting.org.ua>,
	"Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><20120120203205.GW12984@reaktio.net><CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com><20120124015519.GD24204@andromeda.dapyr.net>
	<CB80CA1EF1C6430A9DFE83632834AFC6@nobody>
Date: Wed, 1 Feb 2012 13:12:24 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm really sorry. something I do not understand true

 LA> You yourself do something you can do, or is your only one link to the
 LA> internet? You are able to answer questions or do not have enough of the
 LA> cerebellum? Or config files provided or not flood.

 KRW>> On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
 ??>>> Pasi,
 ??>>>
 ??>>> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
 ??>>>
 ??>>> (XEN) I/O virtualisation enabled
 ??>>>
 ??>>> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
 ??>>> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
 ??>>> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
 ??>>>
 ??>>> But I dont think I have this message (I am not near my system now, so
 ??>>> I can not confirm)
 ??>>>
 ??>>> (XEN) I/O virtualisation for PV guests enabled
 ??>>>
 ??>>> I believe that many have managed to get VGA passthru working, but
 ??>>> they generally dont post their stories. one only finds the problems
 ??>>> they are encountering when searching about this. That is why it would
 ??>>> be nice to put together a kind of manual in the wiki which would have
 ??>>> all this info together in one location.

 KRW>> http://lmgtfy.com/?q=Xen+VGA+passthrough


--
? ?????????, ??????????? ?????????
??????? ???????-???????????
???????? IT, ???????????????????? ?????? VEGA
E-mail: al@ohosting.org.ua
???:  +380 63 617-18-62 


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHp-0004pP-Fb; Thu, 02 Feb 2012 10:53:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RsY84-0005T2-Cu; Wed, 01 Feb 2012 11:13:32 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328094804!4957027!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30772 invoked from network); 1 Feb 2012 11:13:25 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 11:13:25 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q11BBBmn027031;
	Wed, 1 Feb 2012 13:11:12 +0200
Message-ID: <5B696C874F614E368C693BA9534772C6@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Likarpenkov Alexander" <al@ohosting.org.ua>,
	"Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><20120120203205.GW12984@reaktio.net><CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com><20120124015519.GD24204@andromeda.dapyr.net>
	<CB80CA1EF1C6430A9DFE83632834AFC6@nobody>
Date: Wed, 1 Feb 2012 13:12:24 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm really sorry. something I do not understand true

 LA> You yourself do something you can do, or is your only one link to the
 LA> internet? You are able to answer questions or do not have enough of the
 LA> cerebellum? Or config files provided or not flood.

 KRW>> On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
 ??>>> Pasi,
 ??>>>
 ??>>> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
 ??>>>
 ??>>> (XEN) I/O virtualisation enabled
 ??>>>
 ??>>> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
 ??>>> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
 ??>>> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
 ??>>>
 ??>>> But I dont think I have this message (I am not near my system now, so
 ??>>> I can not confirm)
 ??>>>
 ??>>> (XEN) I/O virtualisation for PV guests enabled
 ??>>>
 ??>>> I believe that many have managed to get VGA passthru working, but
 ??>>> they generally dont post their stories. one only finds the problems
 ??>>> they are encountering when searching about this. That is why it would
 ??>>> be nice to put together a kind of manual in the wiki which would have
 ??>>> all this info together in one location.

 KRW>> http://lmgtfy.com/?q=Xen+VGA+passthrough


--
? ?????????, ??????????? ?????????
??????? ???????-???????????
???????? IT, ???????????????????? ?????? VEGA
E-mail: al@ohosting.org.ua
???:  +380 63 617-18-62 


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHq-0004pd-6d; Thu, 02 Feb 2012 10:53:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hbomb.ustc@gmail.com>) id 1Rskxy-0002pE-RL
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 00:55:59 +0000
X-Env-Sender: hbomb.ustc@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328144152!9715473!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23407 invoked from network); 2 Feb 2012 00:55:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 00:55:52 -0000
Received: by werb14 with SMTP id b14so3438139wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 16:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=sMPJrtccwprONs53oIVhm3l9IbvHsDGuvLclZcYPGiE=;
	b=B79JP5B2rmOO0ckgUjEUSHdYh7K2OiRJCffN58XdniyLau8oNTiwMetyiSkFtWHX5m
	Xl+5w+MRdxnSX2Sp6e+ocKOh2YM1iCHVWwAyL2UcDqKOqEHJWA0nku7GS6S1vgDy/AQi
	ftlSdmJCzIyJvTicX/E46UTGVpgOTFA4udDKM=
MIME-Version: 1.0
Received: by 10.216.134.74 with SMTP id r52mr299609wei.19.1328144152689; Wed,
	01 Feb 2012 16:55:52 -0800 (PST)
Received: by 10.223.143.69 with HTTP; Wed, 1 Feb 2012 16:55:52 -0800 (PST)
Date: Thu, 2 Feb 2012 08:55:52 +0800
Message-ID: <CACPcZCOWWTOMgj18C_E+Mmhu9e8-ucejwgaLvwXgvh6ZH91F7g@mail.gmail.com>
From: hbomb ustc <hbomb.ustc@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Subject: [Xen-devel] Question about USB3.0 in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Greetings,

I am working on XHCI driver but without any experience of Xen. I googled one
topic, "http://wiki.xen.org/xenwiki/XenUSBPassthrough" said it support USB1.1
and USB2.0. Here is my questions.

Does Xen support USB3.0?

If not, is there a plan and how to do for supporting USB3.0?

Thanks.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHq-0004pd-6d; Thu, 02 Feb 2012 10:53:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hbomb.ustc@gmail.com>) id 1Rskxy-0002pE-RL
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 00:55:59 +0000
X-Env-Sender: hbomb.ustc@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328144152!9715473!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23407 invoked from network); 2 Feb 2012 00:55:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 00:55:52 -0000
Received: by werb14 with SMTP id b14so3438139wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 01 Feb 2012 16:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=sMPJrtccwprONs53oIVhm3l9IbvHsDGuvLclZcYPGiE=;
	b=B79JP5B2rmOO0ckgUjEUSHdYh7K2OiRJCffN58XdniyLau8oNTiwMetyiSkFtWHX5m
	Xl+5w+MRdxnSX2Sp6e+ocKOh2YM1iCHVWwAyL2UcDqKOqEHJWA0nku7GS6S1vgDy/AQi
	ftlSdmJCzIyJvTicX/E46UTGVpgOTFA4udDKM=
MIME-Version: 1.0
Received: by 10.216.134.74 with SMTP id r52mr299609wei.19.1328144152689; Wed,
	01 Feb 2012 16:55:52 -0800 (PST)
Received: by 10.223.143.69 with HTTP; Wed, 1 Feb 2012 16:55:52 -0800 (PST)
Date: Thu, 2 Feb 2012 08:55:52 +0800
Message-ID: <CACPcZCOWWTOMgj18C_E+Mmhu9e8-ucejwgaLvwXgvh6ZH91F7g@mail.gmail.com>
From: hbomb ustc <hbomb.ustc@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Subject: [Xen-devel] Question about USB3.0 in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Greetings,

I am working on XHCI driver but without any experience of Xen. I googled one
topic, "http://wiki.xen.org/xenwiki/XenUSBPassthrough" said it support USB1.1
and USB2.0. Here is my questions.

Does Xen support USB3.0?

If not, is there a plan and how to do for supporting USB3.0?

Thanks.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHp-0004pW-RC; Thu, 02 Feb 2012 10:53:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1RsiZx-0007k5-7t
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 22:23:01 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328134953!51201300!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 1 Feb 2012 22:22:34 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 22:22:34 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 08EA5210AF
	for <xen-devel@lists.xensource.com>;
	Wed,  1 Feb 2012 17:22:54 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Wed, 01 Feb 2012 17:22:55 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=PaXwoSv6s2DuuURdJLICAv4Un0M=; b=kWAGsBcG7K6LDGQIhizZcCQgtNjQ
	X05wV8NlieRVeRNHDlNflaxA8VABo3C5kaagAjDJIn56E4ywTAGdRYdP3GR+6UUk
	YVf1e0sqzXyfWkrgUqfmLmYS0ojYETiNYsKs+QI0ssmjWElOBOZ/Q03qaX6ZobeA
	SrrlEIoXP8F96WY=
X-Sasl-enc: 4odZveX+FgxsDLVCscFxhYmIRHKFVTcq8OzAQpiPv7vX 1328134974
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 613754825E3;
	Wed,  1 Feb 2012 17:22:54 -0500 (EST)
Date: Wed, 1 Feb 2012 14:22:50 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120201222250.GA3854@kroah.com>
References: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
> 
> [   14.484206] SMP alternatives: switching to UP code
> [   14.514287] ------------[ cut here ]------------
> [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [   14.514586] Call Trace:
> [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> 
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date:   Mon Jan 16 14:40:28 2012 -0800
> 
>     mce: fix warning messages about static struct mce_device
> "
> 
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
> 
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.

Does the patch below solve the problem for you?

thanks,

greg k-h


diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index db87e78..23f2c4c 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -208,6 +208,25 @@ static ssize_t print_cpus_offline(struct device *dev,
 }
 static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
 
+static void cpu_device_release(struct device *dev)
+{
+	/*
+	 * This is an empty function to prevent the driver core from spitting a
+	 * warning at us.  Yes, I know this is directly opposite of what the
+	 * documentation for the driver core and kobjects say, and the author
+	 * of this code has already been publically ridiculed for doing
+	 * something as foolish as this.  However, at this point in time, it is
+	 * the only way to handle the issue of statically allocated cpu
+	 * devices.  The different architectures will have their cpu device
+	 * code reworked to properly handle this in the near future, so this
+	 * function will then be changed to correctly free up the memory held
+	 * by the cpu device.
+	 *
+	 * Never copy this way of doing things, or you too will be made fun of
+	 * on the linux-kerenl list, you have been warned.
+	 */
+}
+
 /*
  * register_cpu - Setup a sysfs device for a CPU.
  * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
@@ -223,6 +242,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
 	cpu->node_id = cpu_to_node(num);
 	cpu->dev.id = num;
 	cpu->dev.bus = &cpu_subsys;
+	cpu->dev.release = cpu_device_release;
 	error = device_register(&cpu->dev);
 	if (!error && cpu->hotpluggable)
 		register_cpu_control(cpu);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHp-0004pW-RC; Thu, 02 Feb 2012 10:53:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1RsiZx-0007k5-7t
	for xen-devel@lists.xensource.com; Wed, 01 Feb 2012 22:23:01 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328134953!51201300!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 1 Feb 2012 22:22:34 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2012 22:22:34 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 08EA5210AF
	for <xen-devel@lists.xensource.com>;
	Wed,  1 Feb 2012 17:22:54 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Wed, 01 Feb 2012 17:22:55 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=PaXwoSv6s2DuuURdJLICAv4Un0M=; b=kWAGsBcG7K6LDGQIhizZcCQgtNjQ
	X05wV8NlieRVeRNHDlNflaxA8VABo3C5kaagAjDJIn56E4ywTAGdRYdP3GR+6UUk
	YVf1e0sqzXyfWkrgUqfmLmYS0ojYETiNYsKs+QI0ssmjWElOBOZ/Q03qaX6ZobeA
	SrrlEIoXP8F96WY=
X-Sasl-enc: 4odZveX+FgxsDLVCscFxhYmIRHKFVTcq8OzAQpiPv7vX 1328134974
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 613754825E3;
	Wed,  1 Feb 2012 17:22:54 -0500 (EST)
Date: Wed, 1 Feb 2012 14:22:50 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120201222250.GA3854@kroah.com>
References: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
> 
> [   14.484206] SMP alternatives: switching to UP code
> [   14.514287] ------------[ cut here ]------------
> [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [   14.514586] Call Trace:
> [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> 
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date:   Mon Jan 16 14:40:28 2012 -0800
> 
>     mce: fix warning messages about static struct mce_device
> "
> 
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
> 
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.

Does the patch below solve the problem for you?

thanks,

greg k-h


diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index db87e78..23f2c4c 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -208,6 +208,25 @@ static ssize_t print_cpus_offline(struct device *dev,
 }
 static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
 
+static void cpu_device_release(struct device *dev)
+{
+	/*
+	 * This is an empty function to prevent the driver core from spitting a
+	 * warning at us.  Yes, I know this is directly opposite of what the
+	 * documentation for the driver core and kobjects say, and the author
+	 * of this code has already been publically ridiculed for doing
+	 * something as foolish as this.  However, at this point in time, it is
+	 * the only way to handle the issue of statically allocated cpu
+	 * devices.  The different architectures will have their cpu device
+	 * code reworked to properly handle this in the near future, so this
+	 * function will then be changed to correctly free up the memory held
+	 * by the cpu device.
+	 *
+	 * Never copy this way of doing things, or you too will be made fun of
+	 * on the linux-kerenl list, you have been warned.
+	 */
+}
+
 /*
  * register_cpu - Setup a sysfs device for a CPU.
  * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
@@ -223,6 +242,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
 	cpu->node_id = cpu_to_node(num);
 	cpu->dev.id = num;
 	cpu->dev.bus = &cpu_subsys;
+	cpu->dev.release = cpu_device_release;
 	error = device_register(&cpu->dev);
 	if (!error && cpu->hotpluggable)
 		register_cpu_control(cpu);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHp-0004pI-2x; Thu, 02 Feb 2012 10:53:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RsXUl-00031l-7A; Wed, 01 Feb 2012 10:32:55 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328092368!12373639!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11652 invoked from network); 1 Feb 2012 10:32:49 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 10:32:49 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q11AUYD9024647;
	Wed, 1 Feb 2012 12:30:36 +0200
Message-ID: <CB80CA1EF1C6430A9DFE83632834AFC6@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><20120120203205.GW12984@reaktio.net><CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
	<20120124015519.GD24204@andromeda.dapyr.net>
Date: Wed, 1 Feb 2012 12:31:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

You yourself do something you can do, or is your only one link to the 
internet? You are able to answer questions or do not have enough of the 
cerebellum? Or config files provided or not flood.

 KRW> On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
 ??>> Pasi,
 ??>>
 ??>> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
 ??>>
 ??>> (XEN) I/O virtualisation enabled
 ??>>
 ??>> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
 ??>> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
 ??>> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
 ??>>
 ??>> But I dont think I have this message (I am not near my system now, so
 ??>> I can not confirm)
 ??>>
 ??>> (XEN) I/O virtualisation for PV guests enabled
 ??>>
 ??>> I believe that many have managed to get VGA passthru working, but they
 ??>> generally dont post their stories. one only finds the problems they
 ??>> are encountering when searching about this. That is why it would be
 ??>> nice to put together a kind of manual in the wiki which would have all
 ??>> this info together in one location.

 KRW> http://lmgtfy.com/?q=Xen+VGA+passthrough


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 10:53:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 10:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsuHp-0004pI-2x; Thu, 02 Feb 2012 10:53:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <al@ohosting.org.ua>)
	id 1RsXUl-00031l-7A; Wed, 01 Feb 2012 10:32:55 +0000
X-Env-Sender: al@ohosting.org.ua
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328092368!12373639!1
X-Originating-IP: [195.248.169.244]
X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_MUA_OUTLOOK
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11652 invoked from network); 1 Feb 2012 10:32:49 -0000
Received: from ohosting.org.ua (HELO c2.ohosting.org.ua) (195.248.169.244)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2012 10:32:49 -0000
Received: from nobody (ns4.o.dp.ua [195.248.169.251]) (authenticated bits=0)
	by c2.ohosting.org.ua (8.14.5/8.14.5) with ESMTP id q11AUYD9024647;
	Wed, 1 Feb 2012 12:30:36 +0200
Message-ID: <CB80CA1EF1C6430A9DFE83632834AFC6@nobody>
From: "Likarpenkov Alexander" <al@ohosting.org.ua>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Sandi Romih" <romihs.forums@gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><20120120154745.GV12984@reaktio.net><CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com><20120120203205.GW12984@reaktio.net><CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
	<20120124015519.GD24204@andromeda.dapyr.net>
Date: Wed, 1 Feb 2012 12:31:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16
X-Mailman-Approved-At: Thu, 02 Feb 2012 10:53:03 +0000
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

You yourself do something you can do, or is your only one link to the 
internet? You are able to answer questions or do not have enough of the 
cerebellum? Or config files provided or not flood.

 KRW> On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
 ??>> Pasi,
 ??>>
 ??>> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
 ??>>
 ??>> (XEN) I/O virtualisation enabled
 ??>>
 ??>> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
 ??>> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
 ??>> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
 ??>>
 ??>> But I dont think I have this message (I am not near my system now, so
 ??>> I can not confirm)
 ??>>
 ??>> (XEN) I/O virtualisation for PV guests enabled
 ??>>
 ??>> I believe that many have managed to get VGA passthru working, but they
 ??>> generally dont post their stories. one only finds the problems they
 ??>> are encountering when searching about this. That is why it would be
 ??>> nice to put together a kind of manual in the wiki which would have all
 ??>> this info together in one location.

 KRW> http://lmgtfy.com/?q=Xen+VGA+passthrough


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:01:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11: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.xensource.com>)
	id 1RsuQ4-0006Hf-Hr; Thu, 02 Feb 2012 11:01:36 +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 1RsuQ3-0006HW-At
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:01:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328180468!51271872!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11616 invoked from network); 2 Feb 2012 11:01:09 -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; 2 Feb 2012 11:01:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsuPt-000DAf-M6; Thu, 02 Feb 2012 11:01:25 +0000
Date: Thu, 2 Feb 2012 11:01:24 +0000
From: Tim Deegan <tim@xen.org>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120202110124.GD48883@ocelot.phlegethon.org>
References: <20120130094722.GB96325@ocelot.phlegethon.org>
	<298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
	<78371237.7e0e.13532919b2f.Coremail.hxkhust@126.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <78371237.7e0e.13532919b2f.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello, 

Please don't top-post. 

At 15:01 +0800 on 31 Jan (1328022097), hxkhust wrote:
> Is the (prototype) memory-sharing code mentioned in your last email
> already offered in Xen resource code?

Yes; see changeset 20693:617071a8c638 and thereabouts.  But that code
went in about two years ago, and has been unmaintained since then, so I
would be very surprised if it's working now.  

You should also look at the recent patches that Andres Lagar-Cavilla has
been sending, whioch update the hypervisor side of the page-sharing
code. 

Cheers,

Tim.

> At 2012-01-30 17:47:31,"Tim Deegan" <tim@xen.org> wrote:
> >Hi,
> >
> >At 16:11 +0800 on 30 Jan (1327939919), hxkhust wrote:
> >> On a physical machine with xen virtualization platform installed ,VM
> >> A,VM B are VM C's virtual disks are all image files,among which VM A
> >> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
> >> format. And VM A and VM B's virtual disk image files are based on VM
> >> C's virtual disk image file.Now these three VMs are running on the
> >> same physical machine with xen installed. In the process of running VM
> >> A get a page data from VM C's virtual disk image file. After that ,VM
> >> B also need to get the same page data as VM A got just now.Under this
> >> situation, does VMM copy the page data from VM A's memory to VM B's
> >> memory or get the page data from VM C's virtual disk image file in the
> >> physical disk again?
> >
> >It reads it from the disk again, unless you're using the (prototype)
> >memory-sharing code that's in blktap.
> >
> >> Or if I would like to figure out this problem,what shall I do?
> >
> >Instrument the disk, or read the code.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:01:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11: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.xensource.com>)
	id 1RsuQ4-0006Hf-Hr; Thu, 02 Feb 2012 11:01:36 +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 1RsuQ3-0006HW-At
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:01:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328180468!51271872!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11616 invoked from network); 2 Feb 2012 11:01:09 -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; 2 Feb 2012 11:01:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsuPt-000DAf-M6; Thu, 02 Feb 2012 11:01:25 +0000
Date: Thu, 2 Feb 2012 11:01:24 +0000
From: Tim Deegan <tim@xen.org>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120202110124.GD48883@ocelot.phlegethon.org>
References: <20120130094722.GB96325@ocelot.phlegethon.org>
	<298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
	<78371237.7e0e.13532919b2f.Coremail.hxkhust@126.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <78371237.7e0e.13532919b2f.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello, 

Please don't top-post. 

At 15:01 +0800 on 31 Jan (1328022097), hxkhust wrote:
> Is the (prototype) memory-sharing code mentioned in your last email
> already offered in Xen resource code?

Yes; see changeset 20693:617071a8c638 and thereabouts.  But that code
went in about two years ago, and has been unmaintained since then, so I
would be very surprised if it's working now.  

You should also look at the recent patches that Andres Lagar-Cavilla has
been sending, whioch update the hypervisor side of the page-sharing
code. 

Cheers,

Tim.

> At 2012-01-30 17:47:31,"Tim Deegan" <tim@xen.org> wrote:
> >Hi,
> >
> >At 16:11 +0800 on 30 Jan (1327939919), hxkhust wrote:
> >> On a physical machine with xen virtualization platform installed ,VM
> >> A,VM B are VM C's virtual disks are all image files,among which VM A
> >> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
> >> format. And VM A and VM B's virtual disk image files are based on VM
> >> C's virtual disk image file.Now these three VMs are running on the
> >> same physical machine with xen installed. In the process of running VM
> >> A get a page data from VM C's virtual disk image file. After that ,VM
> >> B also need to get the same page data as VM A got just now.Under this
> >> situation, does VMM copy the page data from VM A's memory to VM B's
> >> memory or get the page data from VM C's virtual disk image file in the
> >> physical disk again?
> >
> >It reads it from the disk again, unless you're using the (prototype)
> >memory-sharing code that's in blktap.
> >
> >> Or if I would like to figure out this problem,what shall I do?
> >
> >Instrument the disk, or read the code.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:20:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11: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.xensource.com>)
	id 1RsuhV-0006kU-9z; Thu, 02 Feb 2012 11:19:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RsuhT-0006jM-Vo
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:19:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328181569!5137493!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7263 invoked from network); 2 Feb 2012 11:19:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 11:19:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsuhL-000DFm-5w; Thu, 02 Feb 2012 11:19:27 +0000
Date: Thu, 2 Feb 2012 11:19:27 +0000
From: Tim Deegan <tim@xen.org>
To: "nai.xia" <nai.xia@gmail.com>
Message-ID: <20120202111927.GE48883@ocelot.phlegethon.org>
References: <4F2A62A2.1010505@gmail.com> <4F2A64A7.9080902@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F2A64A7.9080902@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Joe Epstein <jepstein98@gmail.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] Is this a data corruption bug for p2m_ram_shared
	page in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 18:25 +0800 on 02 Feb (1328207143), nai.xia wrote:
> On 2012???02???02??? 18:17, nai.xia wrote:
> >In hvm_hap_nested_page_fault(), it seems that all valid write faults are 
> >now handled
> >by p2m_mem_access_check(), right? Then when will mem_sharing_unshare_page()
> >be called? And if p2m->access_required == false, the access restrictions 
> >is cleared
> 
> Oh, sorry, I notice that with p2m_ram_shared, the write permissions is
> always cleared.  But, still, this seems cannot lead to the call of
> mem_sharing_unshare_page() and this write fault will happen again and
> again?

There's an explicit call of mem_sharing_unshare_page() in
hvm_hap_nested_page_fault(); the only thing that will skip that is if
the fault is caused by a p2m_access violation, in which case 
we report the fault on the p2m_access ring and wait for the consumer of
that ring to fix the problem. 

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:20:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11: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.xensource.com>)
	id 1RsuhV-0006kU-9z; Thu, 02 Feb 2012 11:19:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RsuhT-0006jM-Vo
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:19:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328181569!5137493!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7263 invoked from network); 2 Feb 2012 11:19:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 11:19:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsuhL-000DFm-5w; Thu, 02 Feb 2012 11:19:27 +0000
Date: Thu, 2 Feb 2012 11:19:27 +0000
From: Tim Deegan <tim@xen.org>
To: "nai.xia" <nai.xia@gmail.com>
Message-ID: <20120202111927.GE48883@ocelot.phlegethon.org>
References: <4F2A62A2.1010505@gmail.com> <4F2A64A7.9080902@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F2A64A7.9080902@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Joe Epstein <jepstein98@gmail.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] Is this a data corruption bug for p2m_ram_shared
	page in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 18:25 +0800 on 02 Feb (1328207143), nai.xia wrote:
> On 2012???02???02??? 18:17, nai.xia wrote:
> >In hvm_hap_nested_page_fault(), it seems that all valid write faults are 
> >now handled
> >by p2m_mem_access_check(), right? Then when will mem_sharing_unshare_page()
> >be called? And if p2m->access_required == false, the access restrictions 
> >is cleared
> 
> Oh, sorry, I notice that with p2m_ram_shared, the write permissions is
> always cleared.  But, still, this seems cannot lead to the call of
> mem_sharing_unshare_page() and this write fault will happen again and
> again?

There's an explicit call of mem_sharing_unshare_page() in
hvm_hap_nested_page_fault(); the only thing that will skip that is if
the fault is caused by a p2m_access violation, in which case 
we report the fault on the p2m_access ring and wait for the consumer of
that ring to fix the problem. 

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:26:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11: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.xensource.com>)
	id 1Rsuo9-0007FE-6W; Thu, 02 Feb 2012 11:26:29 +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 1Rsuo7-0007F9-Vx
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:26:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328181865!62235682!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11779 invoked from network); 2 Feb 2012 11:24:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 11:24:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rsuo1-000DIC-Tl; Thu, 02 Feb 2012 11:26:22 +0000
Date: Thu, 2 Feb 2012 11:26:20 +0000
From: Tim Deegan <tim@xen.org>
To: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Message-ID: <20120202112620.GF48883@ocelot.phlegethon.org>
References: <4F218876.8090606@ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F218876.8090606@ca.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Help needed debugging "EPT Misconfiguration"
	exception on Intel CPU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 17:08 +0000 on 26 Jan (1327597687), Kalev, Leonid wrote:
> (XEN) EPT Misconfiguration, gpa=00000000feffe000
> (XEN) domain->...->eptp   = 0x431b3d01e
> (XEN) vmread(EPT_POINTER) = 0x431b3d01e
> 
>     EPTP bits:
>     0-2   = 6; mem type (0 = UC, 6=WB, all other = invalid)
>     5-3   = 3 (should be = 3 (walk length - 1))
>     6-11  = 0 reserved
>     12-39 = 0x431b3d; addr of EPT PML4
>     40-64 = 0 ; reserved (40 is the addr sz of the CPU here, may vary on other CPUs, 
> max=48)
> 
> (XEN) p2m-ept.c:649:d3 Walking EPT tables for domain 3 gfn feffe
> (XEN) p2m-ept.c:668:d3  epte 1c00000431b3c007
>                                                 0-2 = 7: access allowed: rwx
>                                                 3-7 = 0: reserved
>                            8-11 = 0: ignored
>                                                 x-12 = 431b3c: address of next level EPT
>                            51-x - 0
>                            52-63 - ignored
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fb007
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fa007
> (XEN) p2m-ept.c:668:d3  epte 1c10000c213ee037 0-2 = 7: rwx
>                                     10000000000 (nb: addr size limit - 40 bits for
>                                                  this CPU, we're way below)
>                                                 3-5 = 6: type (0 = UC; 1 = WC; 4 = WT;
>                                                          5 = WP; 6 = WB)
>                            6   = 0:
>                            7-11 =0: (ignored)
>                            mfn=c213ee, (looks valid, mem extends from 100000 to 
> c40000, see mem map below)
>                            52=1;  52-63 should be ignored

Yeah, those entries look fine.  Certainly they don't have any of the
problems listed in section 25.2.3.1 of the SDM under "EPT
Misconfigurations", so I suspect there must be something odd about the
non-production CPU you're using.  

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:26:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11: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.xensource.com>)
	id 1Rsuo9-0007FE-6W; Thu, 02 Feb 2012 11:26:29 +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 1Rsuo7-0007F9-Vx
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:26:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328181865!62235682!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11779 invoked from network); 2 Feb 2012 11:24:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 11:24:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rsuo1-000DIC-Tl; Thu, 02 Feb 2012 11:26:22 +0000
Date: Thu, 2 Feb 2012 11:26:20 +0000
From: Tim Deegan <tim@xen.org>
To: "Kalev, Leonid" <Leonid.Kalev@ca.com>
Message-ID: <20120202112620.GF48883@ocelot.phlegethon.org>
References: <4F218876.8090606@ca.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F218876.8090606@ca.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Help needed debugging "EPT Misconfiguration"
	exception on Intel CPU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 17:08 +0000 on 26 Jan (1327597687), Kalev, Leonid wrote:
> (XEN) EPT Misconfiguration, gpa=00000000feffe000
> (XEN) domain->...->eptp   = 0x431b3d01e
> (XEN) vmread(EPT_POINTER) = 0x431b3d01e
> 
>     EPTP bits:
>     0-2   = 6; mem type (0 = UC, 6=WB, all other = invalid)
>     5-3   = 3 (should be = 3 (walk length - 1))
>     6-11  = 0 reserved
>     12-39 = 0x431b3d; addr of EPT PML4
>     40-64 = 0 ; reserved (40 is the addr sz of the CPU here, may vary on other CPUs, 
> max=48)
> 
> (XEN) p2m-ept.c:649:d3 Walking EPT tables for domain 3 gfn feffe
> (XEN) p2m-ept.c:668:d3  epte 1c00000431b3c007
>                                                 0-2 = 7: access allowed: rwx
>                                                 3-7 = 0: reserved
>                            8-11 = 0: ignored
>                                                 x-12 = 431b3c: address of next level EPT
>                            51-x - 0
>                            52-63 - ignored
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fb007
> (XEN) p2m-ept.c:668:d3  epte 1c000004374fa007
> (XEN) p2m-ept.c:668:d3  epte 1c10000c213ee037 0-2 = 7: rwx
>                                     10000000000 (nb: addr size limit - 40 bits for
>                                                  this CPU, we're way below)
>                                                 3-5 = 6: type (0 = UC; 1 = WC; 4 = WT;
>                                                          5 = WP; 6 = WB)
>                            6   = 0:
>                            7-11 =0: (ignored)
>                            mfn=c213ee, (looks valid, mem extends from 100000 to 
> c40000, see mem map below)
>                            52=1;  52-63 should be ignored

Yeah, those entries look fine.  Certainly they don't have any of the
problems listed in section 25.2.3.1 of the SDM under "EPT
Misconfigurations", so I suspect there must be something odd about the
non-production CPU you're using.  

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:48:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsv9Z-0007dQ-8f; Thu, 02 Feb 2012 11:48:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1Rsv9X-0007dL-D1
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:48:35 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328183264!52607580!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15542 invoked from network); 2 Feb 2012 11:47:46 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 11:47:46 -0000
Received: by iaeh11 with SMTP id h11so12205972iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 03:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=CTn9hMkhwUJ/0rPsHQaT9EDUSpwv+Waq3WTiMoUiKpM=;
	b=pFtHtD5Cc4VW5yJ67vNd6dFHnzz7OcIdPSGpnqeFvLl1RqRSuRT+g2k4MVaErZbT8P
	z8xz2Pm0DIT7hfZPHQlJRofVWrvFijIPMTbhhImVeh8lle0/QqA6FFJArbUnsybxejyY
	VKZl6TS5R4RsyrASf71gjD/IGpDjVymOMLYQc=
Received: by 10.50.11.202 with SMTP id s10mr2817235igb.25.1328183312827;
	Thu, 02 Feb 2012 03:48:32 -0800 (PST)
Received: from [112.22.177.46] ([112.22.177.46])
	by mx.google.com with ESMTPS id x18sm4541227ibi.2.2012.02.02.03.48.29
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 03:48:31 -0800 (PST)
Message-ID: <4F2A780A.5080002@gmail.com>
Date: Thu, 02 Feb 2012 19:48:26 +0800
From: "nai.xia" <nai.xia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <4F2A62A2.1010505@gmail.com> <4F2A64A7.9080902@gmail.com>
	<20120202111927.GE48883@ocelot.phlegethon.org>
In-Reply-To: <20120202111927.GE48883@ocelot.phlegethon.org>
Cc: Joe Epstein <jepstein98@gmail.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] Is this a data corruption bug for p2m_ram_shared
 page in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgpPbiAyMDEy5bm0MDLmnIgwMuaXpSAxOToxOSwgVGltIERlZWdhbiB3cm90ZToKPiBBdCAxODoy
NSArMDgwMCBvbiAwMiBGZWIgKDEzMjgyMDcxNDMpLCBuYWkueGlhIHdyb3RlOgo+PiBPbiAyMDEy
Pz8/MDI/Pz8wMj8/PyAxODoxNywgbmFpLnhpYSB3cm90ZToKPj4+IEluIGh2bV9oYXBfbmVzdGVk
X3BhZ2VfZmF1bHQoKSwgaXQgc2VlbXMgdGhhdCBhbGwgdmFsaWQgd3JpdGUgZmF1bHRzIGFyZQo+
Pj4gbm93IGhhbmRsZWQKPj4+IGJ5IHAybV9tZW1fYWNjZXNzX2NoZWNrKCksIHJpZ2h0PyBUaGVu
IHdoZW4gd2lsbCBtZW1fc2hhcmluZ191bnNoYXJlX3BhZ2UoKQo+Pj4gYmUgY2FsbGVkPyBBbmQg
aWYgcDJtLT5hY2Nlc3NfcmVxdWlyZWQgPT0gZmFsc2UsIHRoZSBhY2Nlc3MgcmVzdHJpY3Rpb25z
Cj4+PiBpcyBjbGVhcmVkCj4+Cj4+IE9oLCBzb3JyeSwgSSBub3RpY2UgdGhhdCB3aXRoIHAybV9y
YW1fc2hhcmVkLCB0aGUgd3JpdGUgcGVybWlzc2lvbnMgaXMKPj4gYWx3YXlzIGNsZWFyZWQuICBC
dXQsIHN0aWxsLCB0aGlzIHNlZW1zIGNhbm5vdCBsZWFkIHRvIHRoZSBjYWxsIG9mCj4+IG1lbV9z
aGFyaW5nX3Vuc2hhcmVfcGFnZSgpIGFuZCB0aGlzIHdyaXRlIGZhdWx0IHdpbGwgaGFwcGVuIGFn
YWluIGFuZAo+PiBhZ2Fpbj8KPgo+IFRoZXJlJ3MgYW4gZXhwbGljaXQgY2FsbCBvZiBtZW1fc2hh
cmluZ191bnNoYXJlX3BhZ2UoKSBpbgo+IGh2bV9oYXBfbmVzdGVkX3BhZ2VfZmF1bHQoKTsgdGhl
IG9ubHkgdGhpbmcgdGhhdCB3aWxsIHNraXAgdGhhdCBpcyBpZgo+IHRoZSBmYXVsdCBpcyBjYXVz
ZWQgYnkgYSBwMm1fYWNjZXNzIHZpb2xhdGlvbiwgaW4gd2hpY2ggY2FzZQo+IHdlIHJlcG9ydCB0
aGUgZmF1bHQgb24gdGhlIHAybV9hY2Nlc3MgcmluZyBhbmQgd2FpdCBmb3IgdGhlIGNvbnN1bWVy
IG9mCj4gdGhhdCByaW5nIHRvIGZpeCB0aGUgcHJvYmxlbS4KCk9oLCB5ZXMhIEkgd2FzIG1pc3Rh
a2VuIHRoYXQgdGhlIHdyaXRlIGZsYWcgb2YgcDJtX2FjY2VzcyB3b3VsZCBhbHNvIGJlCnJlbW92
ZWQgZm9yIHAybV9yYW1fc2hhcmVkIHBhZ2VzIGp1c3QgbGlrZSBlbnRyeS0+dyBpbiBlcHRfc2V0
X2VudHJ5KCkuCkkgYW0gY2xlYXIgYWJvdXQgdGhlIHJvbGUgb2YgdGhlIHAybV9hY2Nlc3NfdCBu
b3cuCgpUaGFua3MgZm9yIHRoZSByZXBseSEgOikKCgpSZWdhcmRzLAoKTmFpCgo+Cj4gQ2hlZXJz
LAo+Cj4gVGltLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 11:48:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 11:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsv9Z-0007dQ-8f; Thu, 02 Feb 2012 11:48:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1Rsv9X-0007dL-D1
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 11:48:35 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328183264!52607580!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15542 invoked from network); 2 Feb 2012 11:47:46 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 11:47:46 -0000
Received: by iaeh11 with SMTP id h11so12205972iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 03:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=CTn9hMkhwUJ/0rPsHQaT9EDUSpwv+Waq3WTiMoUiKpM=;
	b=pFtHtD5Cc4VW5yJ67vNd6dFHnzz7OcIdPSGpnqeFvLl1RqRSuRT+g2k4MVaErZbT8P
	z8xz2Pm0DIT7hfZPHQlJRofVWrvFijIPMTbhhImVeh8lle0/QqA6FFJArbUnsybxejyY
	VKZl6TS5R4RsyrASf71gjD/IGpDjVymOMLYQc=
Received: by 10.50.11.202 with SMTP id s10mr2817235igb.25.1328183312827;
	Thu, 02 Feb 2012 03:48:32 -0800 (PST)
Received: from [112.22.177.46] ([112.22.177.46])
	by mx.google.com with ESMTPS id x18sm4541227ibi.2.2012.02.02.03.48.29
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 03:48:31 -0800 (PST)
Message-ID: <4F2A780A.5080002@gmail.com>
Date: Thu, 02 Feb 2012 19:48:26 +0800
From: "nai.xia" <nai.xia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <4F2A62A2.1010505@gmail.com> <4F2A64A7.9080902@gmail.com>
	<20120202111927.GE48883@ocelot.phlegethon.org>
In-Reply-To: <20120202111927.GE48883@ocelot.phlegethon.org>
Cc: Joe Epstein <jepstein98@gmail.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] Is this a data corruption bug for p2m_ram_shared
 page in hvm_hap_nested_page_fault()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgpPbiAyMDEy5bm0MDLmnIgwMuaXpSAxOToxOSwgVGltIERlZWdhbiB3cm90ZToKPiBBdCAxODoy
NSArMDgwMCBvbiAwMiBGZWIgKDEzMjgyMDcxNDMpLCBuYWkueGlhIHdyb3RlOgo+PiBPbiAyMDEy
Pz8/MDI/Pz8wMj8/PyAxODoxNywgbmFpLnhpYSB3cm90ZToKPj4+IEluIGh2bV9oYXBfbmVzdGVk
X3BhZ2VfZmF1bHQoKSwgaXQgc2VlbXMgdGhhdCBhbGwgdmFsaWQgd3JpdGUgZmF1bHRzIGFyZQo+
Pj4gbm93IGhhbmRsZWQKPj4+IGJ5IHAybV9tZW1fYWNjZXNzX2NoZWNrKCksIHJpZ2h0PyBUaGVu
IHdoZW4gd2lsbCBtZW1fc2hhcmluZ191bnNoYXJlX3BhZ2UoKQo+Pj4gYmUgY2FsbGVkPyBBbmQg
aWYgcDJtLT5hY2Nlc3NfcmVxdWlyZWQgPT0gZmFsc2UsIHRoZSBhY2Nlc3MgcmVzdHJpY3Rpb25z
Cj4+PiBpcyBjbGVhcmVkCj4+Cj4+IE9oLCBzb3JyeSwgSSBub3RpY2UgdGhhdCB3aXRoIHAybV9y
YW1fc2hhcmVkLCB0aGUgd3JpdGUgcGVybWlzc2lvbnMgaXMKPj4gYWx3YXlzIGNsZWFyZWQuICBC
dXQsIHN0aWxsLCB0aGlzIHNlZW1zIGNhbm5vdCBsZWFkIHRvIHRoZSBjYWxsIG9mCj4+IG1lbV9z
aGFyaW5nX3Vuc2hhcmVfcGFnZSgpIGFuZCB0aGlzIHdyaXRlIGZhdWx0IHdpbGwgaGFwcGVuIGFn
YWluIGFuZAo+PiBhZ2Fpbj8KPgo+IFRoZXJlJ3MgYW4gZXhwbGljaXQgY2FsbCBvZiBtZW1fc2hh
cmluZ191bnNoYXJlX3BhZ2UoKSBpbgo+IGh2bV9oYXBfbmVzdGVkX3BhZ2VfZmF1bHQoKTsgdGhl
IG9ubHkgdGhpbmcgdGhhdCB3aWxsIHNraXAgdGhhdCBpcyBpZgo+IHRoZSBmYXVsdCBpcyBjYXVz
ZWQgYnkgYSBwMm1fYWNjZXNzIHZpb2xhdGlvbiwgaW4gd2hpY2ggY2FzZQo+IHdlIHJlcG9ydCB0
aGUgZmF1bHQgb24gdGhlIHAybV9hY2Nlc3MgcmluZyBhbmQgd2FpdCBmb3IgdGhlIGNvbnN1bWVy
IG9mCj4gdGhhdCByaW5nIHRvIGZpeCB0aGUgcHJvYmxlbS4KCk9oLCB5ZXMhIEkgd2FzIG1pc3Rh
a2VuIHRoYXQgdGhlIHdyaXRlIGZsYWcgb2YgcDJtX2FjY2VzcyB3b3VsZCBhbHNvIGJlCnJlbW92
ZWQgZm9yIHAybV9yYW1fc2hhcmVkIHBhZ2VzIGp1c3QgbGlrZSBlbnRyeS0+dyBpbiBlcHRfc2V0
X2VudHJ5KCkuCkkgYW0gY2xlYXIgYWJvdXQgdGhlIHJvbGUgb2YgdGhlIHAybV9hY2Nlc3NfdCBu
b3cuCgpUaGFua3MgZm9yIHRoZSByZXBseSEgOikKCgpSZWdhcmRzLAoKTmFpCgo+Cj4gQ2hlZXJz
LAo+Cj4gVGltLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:27:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvki-00009I-HC; Thu, 02 Feb 2012 12:27:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rsvkh-00009D-N6
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:26:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328185613!12801024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7201 invoked from network); 2 Feb 2012 12:26:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 12:26:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:26:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	12:26:53 +0000
Message-ID: <1328185611.5359.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 2 Feb 2012 12:26:51 +0000
In-Reply-To: <6fde017c419e70925f15.1326761318@debian.localdomain>
References: <6fde017c419e70925f15.1326761318@debian.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 00:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1326219181 -3600
> # Node ID 6fde017c419e70925f15eb00e8266107011e21cb
> # Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
> build: add autoconf to replace custom checks in tools/check
[...]

I'm afraid I get tonnes of rejects from this due to whitespace
corruption.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:27:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvki-00009I-HC; Thu, 02 Feb 2012 12:27:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rsvkh-00009D-N6
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:26:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328185613!12801024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7201 invoked from network); 2 Feb 2012 12:26:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 12:26:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:26:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	12:26:53 +0000
Message-ID: <1328185611.5359.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 2 Feb 2012 12:26:51 +0000
In-Reply-To: <6fde017c419e70925f15.1326761318@debian.localdomain>
References: <6fde017c419e70925f15.1326761318@debian.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 00:48 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1326219181 -3600
> # Node ID 6fde017c419e70925f15eb00e8266107011e21cb
> # Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
> build: add autoconf to replace custom checks in tools/check
[...]

I'm afraid I get tonnes of rejects from this due to whitespace
corruption.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:31:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvp3-0000Gu-7M; Thu, 02 Feb 2012 12:31:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rsvp1-0000Ge-LD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:31:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328185880!15014475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26645 invoked from network); 2 Feb 2012 12:31:20 -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;
	2 Feb 2012 12:31:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:31:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 12:31:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsvot-00077o-MW;
	Thu, 02 Feb 2012 12:31:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsvot-0000kq-6f;
	Thu, 02 Feb 2012 12:31:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11823-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 12:31:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11823: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   12 guest-saverestore.2       fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 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-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  a91aa7a582fb
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1232 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:31:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvp3-0000Gu-7M; Thu, 02 Feb 2012 12:31:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rsvp1-0000Ge-LD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:31:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328185880!15014475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26645 invoked from network); 2 Feb 2012 12:31:20 -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;
	2 Feb 2012 12:31:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:31:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 12:31:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rsvot-00077o-MW;
	Thu, 02 Feb 2012 12:31:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rsvot-0000kq-6f;
	Thu, 02 Feb 2012 12:31:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11823-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 12:31:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11823: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   12 guest-saverestore.2       fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 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-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  a91aa7a582fb
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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 1232 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:33:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvqf-0000Mm-NA; Thu, 02 Feb 2012 12:33:09 +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 1Rsvqe-0000Mc-8Q
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:33:08 +0000
Received: from [85.158.138.51:36419] by server-11.bemta-3.messagelabs.com id
	DE/1C-21643-3828A2F4; Thu, 02 Feb 2012 12:33:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328185976!11717787!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28895 invoked from network); 2 Feb 2012 12:33:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:33:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsvqP-000Dd4-Gk; Thu, 02 Feb 2012 12:32:53 +0000
Date: Thu, 2 Feb 2012 12:32:52 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202123252.GG48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 9] x86/mm: Fixes to sharing,
	paging and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:51 -0500 on 01 Feb (1328107912), Andres Lagar-Cavilla wrote:
> This patch series aggregates a number of fixes to different areas of mm:
> 
> Sharing:
>  - Make sharing play nice with balloon
>  - Make physmap manipulations deall correctly with shared pages
>  - Make sharing debug calls use locked accessors and return useful information
> 
> Paging:
>  - Eliminate a needless state in the paging state machine
>  - Fix stats/accounting
>  - Fix page type check when nominating or evicting a page
> 
> P2M:
> This changes clear hurdles in advance of a fully-synchronized p2m
>  - Eliminate possibility of deadlock in nested lookups
>  - Reorder some locks taken by the sharing subsystem
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

 - #3 and #5 I'll comment on separately
 - #6 I applied, but updated to remove the outdated comment just above.
 - #8 I applied, but removed the type from the check, because it makes no
      sense with the >=. 
 - the others I appled as-is.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:33:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvqf-0000Mm-NA; Thu, 02 Feb 2012 12:33:09 +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 1Rsvqe-0000Mc-8Q
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:33:08 +0000
Received: from [85.158.138.51:36419] by server-11.bemta-3.messagelabs.com id
	DE/1C-21643-3828A2F4; Thu, 02 Feb 2012 12:33:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328185976!11717787!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28895 invoked from network); 2 Feb 2012 12:33:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:33:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsvqP-000Dd4-Gk; Thu, 02 Feb 2012 12:32:53 +0000
Date: Thu, 2 Feb 2012 12:32:52 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202123252.GG48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328125912@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 9] x86/mm: Fixes to sharing,
	paging and p2m
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:51 -0500 on 01 Feb (1328107912), Andres Lagar-Cavilla wrote:
> This patch series aggregates a number of fixes to different areas of mm:
> 
> Sharing:
>  - Make sharing play nice with balloon
>  - Make physmap manipulations deall correctly with shared pages
>  - Make sharing debug calls use locked accessors and return useful information
> 
> Paging:
>  - Eliminate a needless state in the paging state machine
>  - Fix stats/accounting
>  - Fix page type check when nominating or evicting a page
> 
> P2M:
> This changes clear hurdles in advance of a fully-synchronized p2m
>  - Eliminate possibility of deadlock in nested lookups
>  - Reorder some locks taken by the sharing subsystem
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

 - #3 and #5 I'll comment on separately
 - #6 I applied, but updated to remove the outdated comment just above.
 - #8 I applied, but removed the type from the check, because it makes no
      sense with the >=. 
 - the others I appled as-is.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:34:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:34:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvrf-0000U7-Cs; Thu, 02 Feb 2012 12:34: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 1Rsvrd-0000Tr-NE
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:34:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328185917!51101700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19128 invoked from network); 2 Feb 2012 12:31:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 12:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:34:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 12:34:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rsvrb-00078n-HI; Thu, 02 Feb 2012 12:34:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rsvrb-0008Uz-Ek;
	Thu, 02 Feb 2012 12:34:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.33471.444202.819846@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 12:34:07 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11807-mainreport@xen.org>
References: <osstest-11807-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Wang <wei.wang2@amd.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11807: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    9 guest-start            fail REGR. vs. 11643
>  test-amd64-i386-xl-win7-amd64  7 windows-install       fail REGR. vs. 11643

Both of these seem to be high-probability heisenbugs.  In both cases
LThe failure seems to be much more likely (perhaps even restricted to)
on certain hosts, and now that my tester is "sticky" when it sees a
fail these will give us more trouble.

For this one
>  test-amd64-i386-xl-win7-amd64  7 windows-install       fail REGR. vs. 11643
the failure mode is that Windows sits waiting at a login screen rather
than logging in the user which is supposed to run the test responder
which was installed with the image.  Most likely cause is that it has
stopped making progress for some reason.  None of the logs seem
interesting.

This one
>  test-amd64-i386-xl-credit2    9 guest-start            fail REGR. vs. 11643
which occasionally also manifests as various other failures of the
same test run, is this assertion:

Feb  2 02:34:49.293506 (XEN) Assertion 'test_bit(vector, desc->arch.used_vectors)' failed at irq.c:670

which I mentioned yesterday.  My bisector had a go at the
guest-saverestore test and produced inconclusive results but looking
at the revision graph output I suspect that something between
24612:54000bca7a6a (probably good) and 24620:926e0820d615 (definitely
bad) may be implicated.

Given that this bug seems to be pretty specific to a particular host,
which happens to be a dual-socket six-core AMD Opteron 2427, I'm
wondering whether 24613:04623ceabb72 "amd iommu: disable iommu
emulation on non-iommu systems" might be relevant.

Suggestions for either bug, and offers to debug these, gratefully
received.  Failing that we will probably get lucky and get a push
eventually.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:34:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:34:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvrf-0000U7-Cs; Thu, 02 Feb 2012 12:34: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 1Rsvrd-0000Tr-NE
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:34:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328185917!51101700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19128 invoked from network); 2 Feb 2012 12:31:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 12:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:34:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 12:34:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rsvrb-00078n-HI; Thu, 02 Feb 2012 12:34:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rsvrb-0008Uz-Ek;
	Thu, 02 Feb 2012 12:34:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.33471.444202.819846@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 12:34:07 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11807-mainreport@xen.org>
References: <osstest-11807-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Wang <wei.wang2@amd.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11807: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    9 guest-start            fail REGR. vs. 11643
>  test-amd64-i386-xl-win7-amd64  7 windows-install       fail REGR. vs. 11643

Both of these seem to be high-probability heisenbugs.  In both cases
LThe failure seems to be much more likely (perhaps even restricted to)
on certain hosts, and now that my tester is "sticky" when it sees a
fail these will give us more trouble.

For this one
>  test-amd64-i386-xl-win7-amd64  7 windows-install       fail REGR. vs. 11643
the failure mode is that Windows sits waiting at a login screen rather
than logging in the user which is supposed to run the test responder
which was installed with the image.  Most likely cause is that it has
stopped making progress for some reason.  None of the logs seem
interesting.

This one
>  test-amd64-i386-xl-credit2    9 guest-start            fail REGR. vs. 11643
which occasionally also manifests as various other failures of the
same test run, is this assertion:

Feb  2 02:34:49.293506 (XEN) Assertion 'test_bit(vector, desc->arch.used_vectors)' failed at irq.c:670

which I mentioned yesterday.  My bisector had a go at the
guest-saverestore test and produced inconclusive results but looking
at the revision graph output I suspect that something between
24612:54000bca7a6a (probably good) and 24620:926e0820d615 (definitely
bad) may be implicated.

Given that this bug seems to be pretty specific to a particular host,
which happens to be a dual-socket six-core AMD Opteron 2427, I'm
wondering whether 24613:04623ceabb72 "amd iommu: disable iommu
emulation on non-iommu systems" might be relevant.

Suggestions for either bug, and offers to debug these, gratefully
received.  Failing that we will probably get lucky and get a push
eventually.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:38:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsvvN-0000jX-1V; Thu, 02 Feb 2012 12:38:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsvvK-0000j6-VQ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328186219!62767544!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11116 invoked from network); 2 Feb 2012 12:36:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:36:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 02 Feb 2012 12:37:43 +0000
Message-Id: <4F2A91A502000078000707E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 02 Feb 2012 12:37:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "hbomb ustc" <hbomb.ustc@gmail.com>
References: <CACPcZCOWWTOMgj18C_E+Mmhu9e8-ucejwgaLvwXgvh6ZH91F7g@mail.gmail.com>
In-Reply-To: <CACPcZCOWWTOMgj18C_E+Mmhu9e8-ucejwgaLvwXgvh6ZH91F7g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Question about USB3.0 in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.02.12 at 01:55, hbomb ustc <hbomb.ustc@gmail.com> wrote:
> Greetings,
> 
> I am working on XHCI driver but without any experience of Xen. I googled one
> topic, "http://wiki.xen.org/xenwiki/XenUSBPassthrough" said it support 
> USB1.1
> and USB2.0. Here is my questions.
> 
> Does Xen support USB3.0?

Are you talking about passthrough of such devices (which I assume
will require some work in USB frontend and/or backend, but I'm not
a USB expert to be certain) or simple support of such devices when
the entire HC is being seen by the target domain (should work with
no extra effort)?

Jan

> If not, is there a plan and how to do for supporting USB3.0?
> 
> Thanks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:38:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsvvN-0000jX-1V; Thu, 02 Feb 2012 12:38:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsvvK-0000j6-VQ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328186219!62767544!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11116 invoked from network); 2 Feb 2012 12:36:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:36:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 02 Feb 2012 12:37:43 +0000
Message-Id: <4F2A91A502000078000707E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 02 Feb 2012 12:37:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "hbomb ustc" <hbomb.ustc@gmail.com>
References: <CACPcZCOWWTOMgj18C_E+Mmhu9e8-ucejwgaLvwXgvh6ZH91F7g@mail.gmail.com>
In-Reply-To: <CACPcZCOWWTOMgj18C_E+Mmhu9e8-ucejwgaLvwXgvh6ZH91F7g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Question about USB3.0 in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.02.12 at 01:55, hbomb ustc <hbomb.ustc@gmail.com> wrote:
> Greetings,
> 
> I am working on XHCI driver but without any experience of Xen. I googled one
> topic, "http://wiki.xen.org/xenwiki/XenUSBPassthrough" said it support 
> USB1.1
> and USB2.0. Here is my questions.
> 
> Does Xen support USB3.0?

Are you talking about passthrough of such devices (which I assume
will require some work in USB frontend and/or backend, but I'm not
a USB expert to be certain) or simple support of such devices when
the entire HC is being seen by the target domain (should work with
no extra effort)?

Jan

> If not, is there a plan and how to do for supporting USB3.0?
> 
> Thanks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvwu-0000ql-HR; Thu, 02 Feb 2012 12:39:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rsvws-0000qQ-IG
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:39:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328186367!12828117!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12532 invoked from network); 2 Feb 2012 12:39:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:39:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rsvwk-000Dfh-U2; Thu, 02 Feb 2012 12:39:26 +0000
Date: Thu, 2 Feb 2012 12:39:26 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202123926.GH48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 9] x86/mm: Refactor possibly
	deadlocking get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:51 -0500 on 01 Feb (1328107915), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c    |  35 +++++++--------
>  xen/arch/x86/mm/mem_sharing.c |  28 +++++++------
>  xen/include/asm-x86/p2m.h     |  91 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 122 insertions(+), 32 deletions(-)
> 
> 
> When calling get_gfn multiple times on different gfn's in the same function, we
> can easily deadlock if p2m lookups are locked. Thus, refactor these calls to
> enforce simple deadlock-avoidance rules:
>  - Lowest-numbered domain first
>  - Lowest-numbered gfn first

This is a good idea, and I like the get_two_gfns() abstraction, but: 
 - I think the two_gfns struct should proabbly just live on the stack
   instead of malloc()ing it up every time.  It's not very big.
 - the implementation of get_two_gfns() seems to be very complex; I'm
   sure it could be simplified.  At the very least, you could avoid a
   bit of duplication by just deciding once which order to do the gets
   in and then running all the setu and get code once.

Cheers,

Tim.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>
> 
> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
>  {
>      struct hvm_emulate_ctxt *hvmemul_ctxt =
>          container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> -    unsigned long saddr, daddr, bytes, sgfn, dgfn;
> +    unsigned long saddr, daddr, bytes;
>      paddr_t sgpa, dgpa;
>      uint32_t pfec = PFEC_page_present;
> -    p2m_type_t p2mt;
> +    p2m_type_t sp2mt, dp2mt;
>      int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
>      char *buf;
> +    struct two_gfns *tg;
>  
>      rc = hvmemul_virtual_to_linear(
>          src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
> @@ -693,26 +694,25 @@ static int hvmemul_rep_movs(
>      if ( rc != X86EMUL_OKAY )
>          return rc;
>  
> -    /* XXX In a fine-grained p2m locking scenario, we need to sort this
> -     * get_gfn's, or else we might deadlock */
> -    sgfn = sgpa >> PAGE_SHIFT;
> -    (void)get_gfn(current->domain, sgfn, &p2mt);
> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
> +    tg = get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
> +                      current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
> +                      p2m_guest);
> +    if ( !tg )
> +        return X86EMUL_UNHANDLEABLE;
> +
> +    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
>      {
>          rc = hvmemul_do_mmio(
>              sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
> -        put_gfn(current->domain, sgfn);
> +        put_two_gfns(&tg);
>          return rc;
>      }
>  
> -    dgfn = dgpa >> PAGE_SHIFT;
> -    (void)get_gfn(current->domain, dgfn, &p2mt);
> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
> +    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
>      {
>          rc = hvmemul_do_mmio(
>              dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
> -        put_gfn(current->domain, sgfn);
> -        put_gfn(current->domain, dgfn);
> +        put_two_gfns(&tg);
>          return rc;
>      }
>  
> @@ -730,8 +730,7 @@ static int hvmemul_rep_movs(
>       */
>      if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
>      {
> -        put_gfn(current->domain, sgfn);
> -        put_gfn(current->domain, dgfn);
> +        put_two_gfns(&tg);
>          return X86EMUL_UNHANDLEABLE;
>      }
>  
> @@ -743,8 +742,7 @@ static int hvmemul_rep_movs(
>      buf = xmalloc_bytes(bytes);
>      if ( buf == NULL )
>      {
> -        put_gfn(current->domain, sgfn);
> -        put_gfn(current->domain, dgfn);
> +        put_two_gfns(&tg);
>          return X86EMUL_UNHANDLEABLE;
>      }
>  
> @@ -757,8 +755,7 @@ static int hvmemul_rep_movs(
>          rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
>  
>      xfree(buf);
> -    put_gfn(current->domain, sgfn);
> -    put_gfn(current->domain, dgfn);
> +    put_two_gfns(&tg);
>  
>      if ( rc == HVMCOPY_gfn_paged_out )
>          return X86EMUL_RETRY;
> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -718,11 +718,13 @@ int mem_sharing_share_pages(struct domai
>      int ret = -EINVAL;
>      mfn_t smfn, cmfn;
>      p2m_type_t smfn_type, cmfn_type;
> +    struct two_gfns *tg;
>  
> -    /* XXX if sd == cd handle potential deadlock by ordering
> -     * the get_ and put_gfn's */
> -    smfn = get_gfn(sd, sgfn, &smfn_type);
> -    cmfn = get_gfn(cd, cgfn, &cmfn_type);
> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
> +                      cd, cgfn, &cmfn_type, NULL, &cmfn,
> +                      p2m_query);
> +    if ( !tg )
> +        return -ENOMEM;
>  
>      /* This tricky business is to avoid two callers deadlocking if 
>       * grabbing pages in opposite client/source order */
> @@ -819,8 +821,7 @@ int mem_sharing_share_pages(struct domai
>      ret = 0;
>      
>  err_out:
> -    put_gfn(cd, cgfn);
> -    put_gfn(sd, sgfn);
> +    put_two_gfns(&tg);
>      return ret;
>  }
>  
> @@ -834,11 +835,13 @@ int mem_sharing_add_to_physmap(struct do
>      struct gfn_info *gfn_info;
>      struct p2m_domain *p2m = p2m_get_hostp2m(cd);
>      p2m_access_t a;
> -    
> -    /* XXX if sd == cd handle potential deadlock by ordering
> -     * the get_ and put_gfn's */
> -    smfn = get_gfn_query(sd, sgfn, &smfn_type);
> -    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
> +    struct two_gfns *tg;
> +
> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
> +                      cd, cgfn, &cmfn_type, &a, &cmfn,
> +                      p2m_query);
> +    if ( !tg )
> +        return -ENOMEM;
>  
>      /* Get the source shared page, check and lock */
>      ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
> @@ -886,8 +889,7 @@ int mem_sharing_add_to_physmap(struct do
>  err_unlock:
>      mem_sharing_page_unlock(spage);
>  err_out:
> -    put_gfn(cd, cgfn);
> -    put_gfn(sd, sgfn);
> +    put_two_gfns(&tg);
>      return ret;
>  }
>  
> diff -r 27031a8a4eff -r 3de7e43b130a xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -378,6 +378,97 @@ static inline unsigned long mfn_to_gfn(s
>          return mfn_x(mfn);
>  }
>  
> +/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
> +struct two_gfns {
> +    struct domain  *first_domain;
> +    unsigned long   first_gfn;
> +    struct domain  *second_domain;
> +    unsigned long   second_gfn;
> +};
> +
> +#define assign_pointers(dest, source)                                       \
> +do {                                                                        \
> +    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
> +    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
> +    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
> +} while(0)
> +
> +/* Returns mfn, type and access for potential caller consumption, but any
> + * of those can be NULL */
> +static inline struct two_gfns *get_two_gfns(struct domain *rd, unsigned long rgfn,
> +        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain *ld, 
> +        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
> +        p2m_query_t q)
> +{
> +    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
> +    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
> +    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
> +    
> +    struct two_gfns *rval = xmalloc(struct two_gfns);
> +    if ( !rval )
> +        return NULL;
> +
> +    if ( rd == ld )
> +    {
> +        rval->first_domain = rval->second_domain = rd;
> +
> +        /* Sort by gfn */
> +        if (rgfn <= lgfn)
> +        {
> +            rval->first_gfn     = rgfn;
> +            rval->second_gfn    = lgfn;
> +            assign_pointers(first, r);
> +            assign_pointers(second, l);
> +        } else {
> +            rval->first_gfn     = lgfn;
> +            rval->second_gfn    = rgfn;
> +            assign_pointers(first, l);
> +            assign_pointers(second, r);
> +        }        
> +    } else {
> +        /* Sort by domain */
> +        if ( rd->domain_id <= ld->domain_id )
> +        {
> +            rval->first_domain  = rd;
> +            rval->first_gfn     = rgfn;
> +            rval->second_domain = ld;
> +            rval->second_gfn    = lgfn;
> +            assign_pointers(first, r);
> +            assign_pointers(second, l);
> +        } else {
> +            rval->first_domain  = ld;
> +            rval->first_gfn     = lgfn;
> +            rval->second_domain = rd;
> +            rval->second_gfn    = rgfn;
> +            assign_pointers(first, l);
> +            assign_pointers(second, r);
> +        }
> +    }
> +
> +    /* Now do the gets */
> +    *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
> +                                      rval->first_gfn, first_t, first_a, q, NULL);
> +    *second_mfn = get_gfn_type_access(p2m_get_hostp2m(rval->second_domain), 
> +                                      rval->second_gfn, second_t, second_a, q, NULL);
> +
> +    return rval;
> +}
> +
> +static inline void put_two_gfns(struct two_gfns **arg_ptr)
> +{
> +    struct two_gfns *arg;
> +
> +    if ( !arg_ptr || !(*arg_ptr) )
> +        return;
> +
> +    arg = *arg_ptr;
> +    put_gfn(arg->second_domain, arg->second_gfn);
> +    put_gfn(arg->first_domain, arg->first_gfn);
> +
> +    xfree(arg);
> +    *arg_ptr = NULL;
> +}
> +
>  /* Init the datastructures for later use by the p2m code */
>  int p2m_init(struct domain *d);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvwu-0000ql-HR; Thu, 02 Feb 2012 12:39:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rsvws-0000qQ-IG
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:39:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328186367!12828117!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12532 invoked from network); 2 Feb 2012 12:39:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:39:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rsvwk-000Dfh-U2; Thu, 02 Feb 2012 12:39:26 +0000
Date: Thu, 2 Feb 2012 12:39:26 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202123926.GH48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 9] x86/mm: Refactor possibly
	deadlocking get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:51 -0500 on 01 Feb (1328107915), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c    |  35 +++++++--------
>  xen/arch/x86/mm/mem_sharing.c |  28 +++++++------
>  xen/include/asm-x86/p2m.h     |  91 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 122 insertions(+), 32 deletions(-)
> 
> 
> When calling get_gfn multiple times on different gfn's in the same function, we
> can easily deadlock if p2m lookups are locked. Thus, refactor these calls to
> enforce simple deadlock-avoidance rules:
>  - Lowest-numbered domain first
>  - Lowest-numbered gfn first

This is a good idea, and I like the get_two_gfns() abstraction, but: 
 - I think the two_gfns struct should proabbly just live on the stack
   instead of malloc()ing it up every time.  It's not very big.
 - the implementation of get_two_gfns() seems to be very complex; I'm
   sure it could be simplified.  At the very least, you could avoid a
   bit of duplication by just deciding once which order to do the gets
   in and then running all the setu and get code once.

Cheers,

Tim.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>
> 
> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
>  {
>      struct hvm_emulate_ctxt *hvmemul_ctxt =
>          container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> -    unsigned long saddr, daddr, bytes, sgfn, dgfn;
> +    unsigned long saddr, daddr, bytes;
>      paddr_t sgpa, dgpa;
>      uint32_t pfec = PFEC_page_present;
> -    p2m_type_t p2mt;
> +    p2m_type_t sp2mt, dp2mt;
>      int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
>      char *buf;
> +    struct two_gfns *tg;
>  
>      rc = hvmemul_virtual_to_linear(
>          src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
> @@ -693,26 +694,25 @@ static int hvmemul_rep_movs(
>      if ( rc != X86EMUL_OKAY )
>          return rc;
>  
> -    /* XXX In a fine-grained p2m locking scenario, we need to sort this
> -     * get_gfn's, or else we might deadlock */
> -    sgfn = sgpa >> PAGE_SHIFT;
> -    (void)get_gfn(current->domain, sgfn, &p2mt);
> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
> +    tg = get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
> +                      current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
> +                      p2m_guest);
> +    if ( !tg )
> +        return X86EMUL_UNHANDLEABLE;
> +
> +    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
>      {
>          rc = hvmemul_do_mmio(
>              sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
> -        put_gfn(current->domain, sgfn);
> +        put_two_gfns(&tg);
>          return rc;
>      }
>  
> -    dgfn = dgpa >> PAGE_SHIFT;
> -    (void)get_gfn(current->domain, dgfn, &p2mt);
> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
> +    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
>      {
>          rc = hvmemul_do_mmio(
>              dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
> -        put_gfn(current->domain, sgfn);
> -        put_gfn(current->domain, dgfn);
> +        put_two_gfns(&tg);
>          return rc;
>      }
>  
> @@ -730,8 +730,7 @@ static int hvmemul_rep_movs(
>       */
>      if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
>      {
> -        put_gfn(current->domain, sgfn);
> -        put_gfn(current->domain, dgfn);
> +        put_two_gfns(&tg);
>          return X86EMUL_UNHANDLEABLE;
>      }
>  
> @@ -743,8 +742,7 @@ static int hvmemul_rep_movs(
>      buf = xmalloc_bytes(bytes);
>      if ( buf == NULL )
>      {
> -        put_gfn(current->domain, sgfn);
> -        put_gfn(current->domain, dgfn);
> +        put_two_gfns(&tg);
>          return X86EMUL_UNHANDLEABLE;
>      }
>  
> @@ -757,8 +755,7 @@ static int hvmemul_rep_movs(
>          rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
>  
>      xfree(buf);
> -    put_gfn(current->domain, sgfn);
> -    put_gfn(current->domain, dgfn);
> +    put_two_gfns(&tg);
>  
>      if ( rc == HVMCOPY_gfn_paged_out )
>          return X86EMUL_RETRY;
> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -718,11 +718,13 @@ int mem_sharing_share_pages(struct domai
>      int ret = -EINVAL;
>      mfn_t smfn, cmfn;
>      p2m_type_t smfn_type, cmfn_type;
> +    struct two_gfns *tg;
>  
> -    /* XXX if sd == cd handle potential deadlock by ordering
> -     * the get_ and put_gfn's */
> -    smfn = get_gfn(sd, sgfn, &smfn_type);
> -    cmfn = get_gfn(cd, cgfn, &cmfn_type);
> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
> +                      cd, cgfn, &cmfn_type, NULL, &cmfn,
> +                      p2m_query);
> +    if ( !tg )
> +        return -ENOMEM;
>  
>      /* This tricky business is to avoid two callers deadlocking if 
>       * grabbing pages in opposite client/source order */
> @@ -819,8 +821,7 @@ int mem_sharing_share_pages(struct domai
>      ret = 0;
>      
>  err_out:
> -    put_gfn(cd, cgfn);
> -    put_gfn(sd, sgfn);
> +    put_two_gfns(&tg);
>      return ret;
>  }
>  
> @@ -834,11 +835,13 @@ int mem_sharing_add_to_physmap(struct do
>      struct gfn_info *gfn_info;
>      struct p2m_domain *p2m = p2m_get_hostp2m(cd);
>      p2m_access_t a;
> -    
> -    /* XXX if sd == cd handle potential deadlock by ordering
> -     * the get_ and put_gfn's */
> -    smfn = get_gfn_query(sd, sgfn, &smfn_type);
> -    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
> +    struct two_gfns *tg;
> +
> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
> +                      cd, cgfn, &cmfn_type, &a, &cmfn,
> +                      p2m_query);
> +    if ( !tg )
> +        return -ENOMEM;
>  
>      /* Get the source shared page, check and lock */
>      ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
> @@ -886,8 +889,7 @@ int mem_sharing_add_to_physmap(struct do
>  err_unlock:
>      mem_sharing_page_unlock(spage);
>  err_out:
> -    put_gfn(cd, cgfn);
> -    put_gfn(sd, sgfn);
> +    put_two_gfns(&tg);
>      return ret;
>  }
>  
> diff -r 27031a8a4eff -r 3de7e43b130a xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -378,6 +378,97 @@ static inline unsigned long mfn_to_gfn(s
>          return mfn_x(mfn);
>  }
>  
> +/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
> +struct two_gfns {
> +    struct domain  *first_domain;
> +    unsigned long   first_gfn;
> +    struct domain  *second_domain;
> +    unsigned long   second_gfn;
> +};
> +
> +#define assign_pointers(dest, source)                                       \
> +do {                                                                        \
> +    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
> +    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
> +    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
> +} while(0)
> +
> +/* Returns mfn, type and access for potential caller consumption, but any
> + * of those can be NULL */
> +static inline struct two_gfns *get_two_gfns(struct domain *rd, unsigned long rgfn,
> +        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain *ld, 
> +        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
> +        p2m_query_t q)
> +{
> +    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
> +    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
> +    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
> +    
> +    struct two_gfns *rval = xmalloc(struct two_gfns);
> +    if ( !rval )
> +        return NULL;
> +
> +    if ( rd == ld )
> +    {
> +        rval->first_domain = rval->second_domain = rd;
> +
> +        /* Sort by gfn */
> +        if (rgfn <= lgfn)
> +        {
> +            rval->first_gfn     = rgfn;
> +            rval->second_gfn    = lgfn;
> +            assign_pointers(first, r);
> +            assign_pointers(second, l);
> +        } else {
> +            rval->first_gfn     = lgfn;
> +            rval->second_gfn    = rgfn;
> +            assign_pointers(first, l);
> +            assign_pointers(second, r);
> +        }        
> +    } else {
> +        /* Sort by domain */
> +        if ( rd->domain_id <= ld->domain_id )
> +        {
> +            rval->first_domain  = rd;
> +            rval->first_gfn     = rgfn;
> +            rval->second_domain = ld;
> +            rval->second_gfn    = lgfn;
> +            assign_pointers(first, r);
> +            assign_pointers(second, l);
> +        } else {
> +            rval->first_domain  = ld;
> +            rval->first_gfn     = lgfn;
> +            rval->second_domain = rd;
> +            rval->second_gfn    = rgfn;
> +            assign_pointers(first, l);
> +            assign_pointers(second, r);
> +        }
> +    }
> +
> +    /* Now do the gets */
> +    *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
> +                                      rval->first_gfn, first_t, first_a, q, NULL);
> +    *second_mfn = get_gfn_type_access(p2m_get_hostp2m(rval->second_domain), 
> +                                      rval->second_gfn, second_t, second_a, q, NULL);
> +
> +    return rval;
> +}
> +
> +static inline void put_two_gfns(struct two_gfns **arg_ptr)
> +{
> +    struct two_gfns *arg;
> +
> +    if ( !arg_ptr || !(*arg_ptr) )
> +        return;
> +
> +    arg = *arg_ptr;
> +    put_gfn(arg->second_domain, arg->second_gfn);
> +    put_gfn(arg->first_domain, arg->first_gfn);
> +
> +    xfree(arg);
> +    *arg_ptr = NULL;
> +}
> +
>  /* Init the datastructures for later use by the p2m code */
>  int p2m_init(struct domain *d);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:41:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvyf-00010L-7e; Thu, 02 Feb 2012 12:41:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rsvyd-000109-VU
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:41:24 +0000
Received: from [85.158.138.51:47021] by server-6.bemta-3.messagelabs.com id
	C4/9B-01423-2748A2F4; Thu, 02 Feb 2012 12:41:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328186480!11713067!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27207 invoked from network); 2 Feb 2012 12:41:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:41:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsvyY-000Dgd-PK; Thu, 02 Feb 2012 12:41:18 +0000
Date: Thu, 2 Feb 2012 12:41:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202124118.GI48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: When removing/adding a page
	from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:51 -0500 on 01 Feb (1328107917), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/p2m.c |  21 ++++++++++++++++++++-
>  1 files changed, 20 insertions(+), 1 deletions(-)
> 
> 
> When removing the m2p mapping it is unconditionally set to invalid, which
> breaks sharing.
> 
> When adding to the physmap, if the previous holder of that entry is a shared
> page, we unshare to default to normal case handling.
> 
> And, we cannot add a shared page directly to the physmap. Proper interfaces
> must be employed, otherwise book-keeping goes awry.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 8a920bcddd0f -r 1c61573d1765 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -419,7 +419,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
>          for ( i = 0; i < (1UL << page_order); i++ )
>          {
>              mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
> -            if ( !p2m_is_grant(t) )
> +            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
>                  set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
>              ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
>          }
> @@ -481,6 +481,17 @@ guest_physmap_add_entry(struct domain *d
>      for ( i = 0; i < (1UL << page_order); i++ )
>      {
>          omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
> +        if ( p2m_is_shared(ot) )
> +        {
> +            /* Do an unshare to cleanly take care of all corner 
> +             * cases. */
> +            int rc;
> +            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
> +            if ( rc )
> +                return rc;

You're holding the p2m lock here!  Also, I don't think you can call
mem_sharing_unshare_page() with that held - wasn't that the reason for 
cset f6c33cfe7333 ?

Tim.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:41:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsvyf-00010L-7e; Thu, 02 Feb 2012 12:41:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rsvyd-000109-VU
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:41:24 +0000
Received: from [85.158.138.51:47021] by server-6.bemta-3.messagelabs.com id
	C4/9B-01423-2748A2F4; Thu, 02 Feb 2012 12:41:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328186480!11713067!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27207 invoked from network); 2 Feb 2012 12:41:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 12:41:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsvyY-000Dgd-PK; Thu, 02 Feb 2012 12:41:18 +0000
Date: Thu, 2 Feb 2012 12:41:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202124118.GI48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: When removing/adding a page
	from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:51 -0500 on 01 Feb (1328107917), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/p2m.c |  21 ++++++++++++++++++++-
>  1 files changed, 20 insertions(+), 1 deletions(-)
> 
> 
> When removing the m2p mapping it is unconditionally set to invalid, which
> breaks sharing.
> 
> When adding to the physmap, if the previous holder of that entry is a shared
> page, we unshare to default to normal case handling.
> 
> And, we cannot add a shared page directly to the physmap. Proper interfaces
> must be employed, otherwise book-keeping goes awry.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 8a920bcddd0f -r 1c61573d1765 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -419,7 +419,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
>          for ( i = 0; i < (1UL << page_order); i++ )
>          {
>              mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
> -            if ( !p2m_is_grant(t) )
> +            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
>                  set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
>              ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
>          }
> @@ -481,6 +481,17 @@ guest_physmap_add_entry(struct domain *d
>      for ( i = 0; i < (1UL << page_order); i++ )
>      {
>          omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
> +        if ( p2m_is_shared(ot) )
> +        {
> +            /* Do an unshare to cleanly take care of all corner 
> +             * cases. */
> +            int rc;
> +            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
> +            if ( rc )
> +                return rc;

You're holding the p2m lock here!  Also, I don't think you can call
mem_sharing_unshare_page() with that held - wasn't that the reason for 
cset f6c33cfe7333 ?

Tim.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:54:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswBR-0001fD-LN; Thu, 02 Feb 2012 12:54:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RswBQ-0001f8-6T
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:54:36 +0000
Received: from [85.158.138.51:30656] by server-1.bemta-3.messagelabs.com id
	7B/56-23590-B878A2F4; Thu, 02 Feb 2012 12:54:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328187273!11718410!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25743 invoked from network); 2 Feb 2012 12:54:34 -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; 2 Feb 2012 12:54:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswBG-000DoG-ST; Thu, 02 Feb 2012 12:54:27 +0000
Date: Thu, 2 Feb 2012 12:54:25 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202125425.GJ48883@ocelot.phlegethon.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] x86/mm: Switch paging/sharing/access
	per-page ops to memops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:09 -0500 on 01 Feb (1328108978), Andres Lagar-Cavilla wrote:
> Per page operations in the paging, sharing, and access tracking subsystems are
> all implemented with domctls (e.g. a domctl to evict one page, or to share one
> page).
> 
> Under heavy load, the domctl path reveals a lack of scalability. The domctl
> lock serializes dom0's vcpus in the hypervisor. When performing thousands of
> per-page operations on dozens of domains, these vcpus will spin in the
> hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
> vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
> its other work-starved processes.
> 
> We retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page
> operations to use the memory_op hypercalls (e.g XENMEM_*).
> 
> A new tools-only section is added to the public memory.h header.
> 
> This is a backwards-incompatible ABI change. It's been floating on the list for
> a couple weeks now, with no nacks thus far.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

For the hypervisor parts, 
Acked-by: Tim Deegan <tim@xen.org>

so this can all go in once the tools parts have been reviewed. 

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:54:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswBR-0001fD-LN; Thu, 02 Feb 2012 12:54:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RswBQ-0001f8-6T
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:54:36 +0000
Received: from [85.158.138.51:30656] by server-1.bemta-3.messagelabs.com id
	7B/56-23590-B878A2F4; Thu, 02 Feb 2012 12:54:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328187273!11718410!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25743 invoked from network); 2 Feb 2012 12:54:34 -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; 2 Feb 2012 12:54:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswBG-000DoG-ST; Thu, 02 Feb 2012 12:54:27 +0000
Date: Thu, 2 Feb 2012 12:54:25 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202125425.GJ48883@ocelot.phlegethon.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328126978@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] x86/mm: Switch paging/sharing/access
	per-page ops to memops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:09 -0500 on 01 Feb (1328108978), Andres Lagar-Cavilla wrote:
> Per page operations in the paging, sharing, and access tracking subsystems are
> all implemented with domctls (e.g. a domctl to evict one page, or to share one
> page).
> 
> Under heavy load, the domctl path reveals a lack of scalability. The domctl
> lock serializes dom0's vcpus in the hypervisor. When performing thousands of
> per-page operations on dozens of domains, these vcpus will spin in the
> hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
> vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
> its other work-starved processes.
> 
> We retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page
> operations to use the memory_op hypercalls (e.g XENMEM_*).
> 
> A new tools-only section is added to the public memory.h header.
> 
> This is a backwards-incompatible ABI change. It's been floating on the list for
> a couple weeks now, with no nacks thus far.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

For the hypervisor parts, 
Acked-by: Tim Deegan <tim@xen.org>

so this can all go in once the tools parts have been reviewed. 

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:57:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswDa-0001kz-9l; Thu, 02 Feb 2012 12:56:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RswDY-0001ko-UB
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:56:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328187402!9659505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29029 invoked from network); 2 Feb 2012 12:56:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 12:56:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:56:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	12:56:41 +0000
Message-ID: <1328187397.5359.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Thu, 2 Feb 2012 12:56:37 +0000
In-Reply-To: <8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> 
> 
> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> +                        unsigned int op, unsigned int mode,
> +                        uint64_t gfn, void *buffer)
> +{
> +    xen_mem_event_op_t meo;
> +
> +    memset(&meo, 0, sizeof(meo));
> +
> +    meo.op      = op;
> +    meo.domain  = domain_id;
> +    meo.gfn     = gfn;
> +    meo.buffer  = (unsigned long) buffer;

Hypercall arguments need to use the xc_hypercall_buffer stuff in order
to ensure that the memory is safe to access from a hypercall (in
particular that it is mlocked or similar)-- I don't see where that
happens for this buffer.

meo itself is bounced by do_memory_op so that is OK.

I was also a little suspicious of ring_addr and shared_addr in
xc_mem_event_control in this regard.

Or does the mem sharing code make it's own arrangements for these sorts
of things somewhere?

Ian.

> +
> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
> +} 




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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 12:57:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 12:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswDa-0001kz-9l; Thu, 02 Feb 2012 12:56:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RswDY-0001ko-UB
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 12:56:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328187402!9659505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29029 invoked from network); 2 Feb 2012 12:56:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 12:56:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10436725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 12:56:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	12:56:41 +0000
Message-ID: <1328187397.5359.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Thu, 2 Feb 2012 12:56:37 +0000
In-Reply-To: <8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> 
> 
> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> +                        unsigned int op, unsigned int mode,
> +                        uint64_t gfn, void *buffer)
> +{
> +    xen_mem_event_op_t meo;
> +
> +    memset(&meo, 0, sizeof(meo));
> +
> +    meo.op      = op;
> +    meo.domain  = domain_id;
> +    meo.gfn     = gfn;
> +    meo.buffer  = (unsigned long) buffer;

Hypercall arguments need to use the xc_hypercall_buffer stuff in order
to ensure that the memory is safe to access from a hypercall (in
particular that it is mlocked or similar)-- I don't see where that
happens for this buffer.

meo itself is bounced by do_memory_op so that is OK.

I was also a little suspicious of ring_addr and shared_addr in
xc_mem_event_control in this regard.

Or does the mem sharing code make it's own arrangements for these sorts
of things somewhere?

Ian.

> +
> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
> +} 




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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:08:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswOp-00022t-Mz; Thu, 02 Feb 2012 13:08:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RswOp-00022o-32
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:08:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328188100!10157539!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21084 invoked from network); 2 Feb 2012 13:08:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:08:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswOg-000DtC-ND; Thu, 02 Feb 2012 13:08:18 +0000
Date: Thu, 2 Feb 2012 13:08:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202130818.GK48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 5] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108165), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/hap/hap.c  |   6 +++++
>  xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
>  xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
>  xen/include/asm-x86/p2m.h  |  47 ++++++++++++++++++++++++++++-----------------
>  4 files changed, 79 insertions(+), 35 deletions(-)
> 
> 
> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
> 
> The lock is always taken recursively, as there are many paths that
> do get_gfn, and later, another attempt at grabbing the p2m_lock
> 
> The lock is not taken for shadow lookups, as the testing needed to rule out the
> possibility of locking inversions and deadlock has not yet been carried out for
> shadow-paging. This is tolerable as long as shadows do not gain support for
> paging or sharing.

Are you aware of any inversions or are you just suggesting there might
be some left?

> HAP (EPT) lookups and all modifications do take the lock.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/hap/hap.c
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -786,7 +786,12 @@ hap_paging_get_mode(struct vcpu *v)
>  static void hap_update_paging_modes(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> +    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
> +    p2m_type_t t;
>  
> +    /* We hold onto the cr3 as it may be modified later, and
> +     * we need to respect lock ordering */
> +    (void)get_gfn(d, cr3_gfn, &t);

Don't you need to check for errors?

>      paging_lock(d);
>  
>      v->arch.paging.mode = hap_paging_get_mode(v);
> @@ -803,6 +808,7 @@ static void hap_update_paging_modes(stru
>      hap_update_cr3(v, 0);
>  
>      paging_unlock(d);
> +    put_gfn(d, cr3_gfn);
>  }
>  
>  #if CONFIG_PAGING_LEVELS == 3
> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/mm-locks.h
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
>   *                                                                      *
>   ************************************************************************/
>  
> +declare_mm_lock(nestedp2m)
> +#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
> +#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
> +
> +/* P2M lock (per-p2m-table)
> + * 
> + * This protects all queries and updates to the p2m table. 
> + *
> + * A note about ordering:
> + *   The order established here is enforced on all mutations of a p2m.
> + *   For lookups, the order established here is enforced only for hap
> + *   domains (1. shadow domains present a few nasty inversions; 
> + *            2. shadow domains do not support paging and sharing, 
> + *               the main sources of dynamic p2m mutations)
> + * 
> + * The lock is recursive as it is common for a code path to look up a gfn
> + * and later mutate it.
> + */
> +
> +declare_mm_lock(p2m)
> +#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
> +#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
> +#define p2m_unlock(p)         mm_unlock(&(p)->lock)
> +#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
> +
>  /* Sharing per page lock
>   *
>   * This is an external lock, not represented by an mm_lock_t. The memory

Since you've just reversed the locking order between this page-sharing
lock and the p2m lock, you need to update the comment that describes
it.  Also, presumably, the code that it describes?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:08:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswOp-00022t-Mz; Thu, 02 Feb 2012 13:08:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RswOp-00022o-32
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:08:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328188100!10157539!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21084 invoked from network); 2 Feb 2012 13:08:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:08:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswOg-000DtC-ND; Thu, 02 Feb 2012 13:08:18 +0000
Date: Thu, 2 Feb 2012 13:08:18 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202130818.GK48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 5] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108165), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/hap/hap.c  |   6 +++++
>  xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
>  xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
>  xen/include/asm-x86/p2m.h  |  47 ++++++++++++++++++++++++++++-----------------
>  4 files changed, 79 insertions(+), 35 deletions(-)
> 
> 
> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
> 
> The lock is always taken recursively, as there are many paths that
> do get_gfn, and later, another attempt at grabbing the p2m_lock
> 
> The lock is not taken for shadow lookups, as the testing needed to rule out the
> possibility of locking inversions and deadlock has not yet been carried out for
> shadow-paging. This is tolerable as long as shadows do not gain support for
> paging or sharing.

Are you aware of any inversions or are you just suggesting there might
be some left?

> HAP (EPT) lookups and all modifications do take the lock.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/hap/hap.c
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -786,7 +786,12 @@ hap_paging_get_mode(struct vcpu *v)
>  static void hap_update_paging_modes(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> +    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
> +    p2m_type_t t;
>  
> +    /* We hold onto the cr3 as it may be modified later, and
> +     * we need to respect lock ordering */
> +    (void)get_gfn(d, cr3_gfn, &t);

Don't you need to check for errors?

>      paging_lock(d);
>  
>      v->arch.paging.mode = hap_paging_get_mode(v);
> @@ -803,6 +808,7 @@ static void hap_update_paging_modes(stru
>      hap_update_cr3(v, 0);
>  
>      paging_unlock(d);
> +    put_gfn(d, cr3_gfn);
>  }
>  
>  #if CONFIG_PAGING_LEVELS == 3
> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/mm-locks.h
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
>   *                                                                      *
>   ************************************************************************/
>  
> +declare_mm_lock(nestedp2m)
> +#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
> +#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
> +
> +/* P2M lock (per-p2m-table)
> + * 
> + * This protects all queries and updates to the p2m table. 
> + *
> + * A note about ordering:
> + *   The order established here is enforced on all mutations of a p2m.
> + *   For lookups, the order established here is enforced only for hap
> + *   domains (1. shadow domains present a few nasty inversions; 
> + *            2. shadow domains do not support paging and sharing, 
> + *               the main sources of dynamic p2m mutations)
> + * 
> + * The lock is recursive as it is common for a code path to look up a gfn
> + * and later mutate it.
> + */
> +
> +declare_mm_lock(p2m)
> +#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
> +#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
> +#define p2m_unlock(p)         mm_unlock(&(p)->lock)
> +#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
> +
>  /* Sharing per page lock
>   *
>   * This is an external lock, not represented by an mm_lock_t. The memory

Since you've just reversed the locking order between this page-sharing
lock and the p2m lock, you need to update the comment that describes
it.  Also, presumably, the code that it describes?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:10:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:10:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswQy-00028B-7z; Thu, 02 Feb 2012 13:10:40 +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 1RswQx-000285-I3
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:10:39 +0000
Received: from [85.158.138.51:5089] by server-4.bemta-3.messagelabs.com id
	C5/3F-07654-E4B8A2F4; Thu, 02 Feb 2012 13:10:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328188237!6570942!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27133 invoked from network); 2 Feb 2012 13:10:38 -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; 2 Feb 2012 13:10:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswQt-000Dtw-Cw; Thu, 02 Feb 2012 13:10:35 +0000
Date: Thu, 2 Feb 2012 13:10:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202131034.GL48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m
	lockups are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108166), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |   2 -
>  xen/arch/x86/mm/mm-locks.h    |   4 ++-
>  xen/arch/x86/mm/p2m-ept.c     |  33 ++-------------------
>  xen/arch/x86/mm/p2m-pod.c     |  14 ++++++---
>  xen/arch/x86/mm/p2m-pt.c      |  45 +++++------------------------
>  xen/arch/x86/mm/p2m.c         |  64 ++++++++++++++++++++++--------------------
>  6 files changed, 58 insertions(+), 104 deletions(-)
> 
> 
> With p2m lookups fully synchronized, many routines need not
> call p2m_lock any longer. Also, many routines can logically
> assert holding the p2m for a specific gfn.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

This looks OK to me, but I'd like an Ack from George as well for the PoD
changes. 

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:10:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:10:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswQy-00028B-7z; Thu, 02 Feb 2012 13:10:40 +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 1RswQx-000285-I3
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:10:39 +0000
Received: from [85.158.138.51:5089] by server-4.bemta-3.messagelabs.com id
	C5/3F-07654-E4B8A2F4; Thu, 02 Feb 2012 13:10:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328188237!6570942!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27133 invoked from network); 2 Feb 2012 13:10:38 -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; 2 Feb 2012 13:10:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswQt-000Dtw-Cw; Thu, 02 Feb 2012 13:10:35 +0000
Date: Thu, 2 Feb 2012 13:10:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202131034.GL48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m
	lockups are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108166), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |   2 -
>  xen/arch/x86/mm/mm-locks.h    |   4 ++-
>  xen/arch/x86/mm/p2m-ept.c     |  33 ++-------------------
>  xen/arch/x86/mm/p2m-pod.c     |  14 ++++++---
>  xen/arch/x86/mm/p2m-pt.c      |  45 +++++------------------------
>  xen/arch/x86/mm/p2m.c         |  64 ++++++++++++++++++++++--------------------
>  6 files changed, 58 insertions(+), 104 deletions(-)
> 
> 
> With p2m lookups fully synchronized, many routines need not
> call p2m_lock any longer. Also, many routines can logically
> assert holding the p2m for a specific gfn.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

This looks OK to me, but I'd like an Ack from George as well for the PoD
changes. 

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:14:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswUY-0002Ir-T8; Thu, 02 Feb 2012 13:14:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswUW-0002Ij-QM
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:14:21 +0000
Received: from [85.158.138.51:50870] by server-7.bemta-3.messagelabs.com id
	16/57-28646-B2C8A2F4; Thu, 02 Feb 2012 13:14:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328188456!6571570!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12781 invoked from network); 2 Feb 2012 13:14:18 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:14:18 -0000
Received: by damc16 with SMTP id c16so11649408dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=urD5qaz+RmhQTTfaBV5oh5f7C7X2dnloUDYjguXE/Vg=;
	b=s/ahYNmnZCiNB07n1FvevDkZFMAS0wDhMad5pZLlgn9TpnXxpZljcN4hdQGIKC8F7f
	5Lsqu/pza54FYw3sMCDpgPaD2V2wKrb2pTK1wzJ+OEfsixgFpw7OHhMO43Z1gWXSNUF7
	IUKBhrNF9hFfxqjFWWc68jwib7RrGMFvcilto=
MIME-Version: 1.0
Received: by 10.68.218.68 with SMTP id pe4mr7695156pbc.97.1328188456138; Thu,
	02 Feb 2012 05:14:16 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Thu, 2 Feb 2012 05:14:16 -0800 (PST)
In-Reply-To: <1328185611.5359.6.camel@zakaz.uk.xensource.com>
References: <6fde017c419e70925f15.1326761318@debian.localdomain>
	<1328185611.5359.6.camel@zakaz.uk.xensource.com>
Date: Thu, 2 Feb 2012 14:14:16 +0100
X-Google-Sender-Auth: _3ace9EgT3Eu7LIiefIDRyveyk8
Message-ID: <CAPLaKK4bR6V-ObCk5CW2JOUTyi2214TSQZp5Fc4xgcJ=eg8EZg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVHVl
LCAyMDEyLTAxLTE3IGF0IDAwOjQ4ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNjIxOTE4MSAtMzYwMAo+PiAjIE5vZGUgSUQgNmZk
ZTAxN2M0MTllNzA5MjVmMTVlYjAwZTgyNjYxMDcwMTFlMjFjYgo+PiAjIFBhcmVudCDCoDViMjY3
NmFjMTMyMTg5NTE2OThjNDlmYTAzNTBmMmFjNDgyMjBmM2QKPj4gYnVpbGQ6IGFkZCBhdXRvY29u
ZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2sKPiBbLi4uXQo+Cj4gSSdt
IGFmcmFpZCBJIGdldCB0b25uZXMgb2YgcmVqZWN0cyBmcm9tIHRoaXMgZHVlIHRvIHdoaXRlc3Bh
Y2UKPiBjb3JydXB0aW9uLgoKRG9uJ3Qga25vdyB3aGF0IGhhcHBlbmVkLCBidXQgc29tZSBvZiBt
eSBwYXRjaGVzIGdvdCBjb3JydXB0ZWQgb3IKc29tZXRoaW5nLiBJIGdldCBhIG1lc3NhZ2Ugc2F5
aW5nIHBhdGNoIHdhcyBub3QgYXBwbGllZCBzdWNjZXNzZnVsbHksCmJ1dCB0aGVyZSBhcmUgbm90
IHJlamVjdHMsIGFuZCB0aGUgcGF0Y2ggc2VlbXMgdG8gYXBwbHkgb2suIElmIEkKdXBkYXRlIHRo
ZW0gKGhnIHFyZWZyZXNoKSBJIGdldCB0aGUgc2FtZSBlcnJvciBhZnRlciBJIHFwb3AgYW5kIHFw
dXNoCnRoZW0uIERvIHlvdSBrbm93IGFueXdheSB0byBzb2x2ZSB0aGlzIGVhc2lseT8KClRoYW5r
cywgUm9nZXIuCgo+IElhbi4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:14:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswUY-0002Ir-T8; Thu, 02 Feb 2012 13:14:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswUW-0002Ij-QM
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:14:21 +0000
Received: from [85.158.138.51:50870] by server-7.bemta-3.messagelabs.com id
	16/57-28646-B2C8A2F4; Thu, 02 Feb 2012 13:14:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328188456!6571570!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12781 invoked from network); 2 Feb 2012 13:14:18 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:14:18 -0000
Received: by damc16 with SMTP id c16so11649408dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=urD5qaz+RmhQTTfaBV5oh5f7C7X2dnloUDYjguXE/Vg=;
	b=s/ahYNmnZCiNB07n1FvevDkZFMAS0wDhMad5pZLlgn9TpnXxpZljcN4hdQGIKC8F7f
	5Lsqu/pza54FYw3sMCDpgPaD2V2wKrb2pTK1wzJ+OEfsixgFpw7OHhMO43Z1gWXSNUF7
	IUKBhrNF9hFfxqjFWWc68jwib7RrGMFvcilto=
MIME-Version: 1.0
Received: by 10.68.218.68 with SMTP id pe4mr7695156pbc.97.1328188456138; Thu,
	02 Feb 2012 05:14:16 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Thu, 2 Feb 2012 05:14:16 -0800 (PST)
In-Reply-To: <1328185611.5359.6.camel@zakaz.uk.xensource.com>
References: <6fde017c419e70925f15.1326761318@debian.localdomain>
	<1328185611.5359.6.camel@zakaz.uk.xensource.com>
Date: Thu, 2 Feb 2012 14:14:16 +0100
X-Google-Sender-Auth: _3ace9EgT3Eu7LIiefIDRyveyk8
Message-ID: <CAPLaKK4bR6V-ObCk5CW2JOUTyi2214TSQZp5Fc4xgcJ=eg8EZg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVHVl
LCAyMDEyLTAxLTE3IGF0IDAwOjQ4ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNjIxOTE4MSAtMzYwMAo+PiAjIE5vZGUgSUQgNmZk
ZTAxN2M0MTllNzA5MjVmMTVlYjAwZTgyNjYxMDcwMTFlMjFjYgo+PiAjIFBhcmVudCDCoDViMjY3
NmFjMTMyMTg5NTE2OThjNDlmYTAzNTBmMmFjNDgyMjBmM2QKPj4gYnVpbGQ6IGFkZCBhdXRvY29u
ZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2sKPiBbLi4uXQo+Cj4gSSdt
IGFmcmFpZCBJIGdldCB0b25uZXMgb2YgcmVqZWN0cyBmcm9tIHRoaXMgZHVlIHRvIHdoaXRlc3Bh
Y2UKPiBjb3JydXB0aW9uLgoKRG9uJ3Qga25vdyB3aGF0IGhhcHBlbmVkLCBidXQgc29tZSBvZiBt
eSBwYXRjaGVzIGdvdCBjb3JydXB0ZWQgb3IKc29tZXRoaW5nLiBJIGdldCBhIG1lc3NhZ2Ugc2F5
aW5nIHBhdGNoIHdhcyBub3QgYXBwbGllZCBzdWNjZXNzZnVsbHksCmJ1dCB0aGVyZSBhcmUgbm90
IHJlamVjdHMsIGFuZCB0aGUgcGF0Y2ggc2VlbXMgdG8gYXBwbHkgb2suIElmIEkKdXBkYXRlIHRo
ZW0gKGhnIHFyZWZyZXNoKSBJIGdldCB0aGUgc2FtZSBlcnJvciBhZnRlciBJIHFwb3AgYW5kIHFw
dXNoCnRoZW0uIERvIHlvdSBrbm93IGFueXdheSB0byBzb2x2ZSB0aGlzIGVhc2lseT8KClRoYW5r
cywgUm9nZXIuCgo+IElhbi4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:14:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswUu-0002L1-NW; Thu, 02 Feb 2012 13:14:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RswUt-0002Kf-Fe
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:14:43 +0000
Received: from [85.158.138.51:56652] by server-4.bemta-3.messagelabs.com id
	80/C7-07654-24C8A2F4; Thu, 02 Feb 2012 13:14:42 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328188478!11519518!1
X-Originating-IP: [220.181.15.23]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDY3MDQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDY3MDQ=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27997 invoked from network); 2 Feb 2012 13:14:40 -0000
Received: from m15-23.126.com (HELO m15-23.126.com) (220.181.15.23)
	by server-14.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 13:14:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=ofcYZsafmHwZTUT
	SNyaHgB3i17iluizmmDaQp6vZNl4=; b=chEGczjMVk7eYkE9eyIsxBkSz33WO83
	yyxgRsl6BG/+feM2EYfeLsRqYhtXNxPpw+VR4SeKubzcqPGw0HnA4yQanWHea/As
	sfdu6jaNwzWhIzuMli+sG+T/JGCnM709NKdTM8H8asa350pBEaPd4acbsxH4voz3
	KADkc0ZrV09c=
Received: from hxkhust ( [119.98.187.105] ) by ajax-webmail-wmsvr23
	(Coremail) ; Thu, 2 Feb 2012 21:14:29 +0800 (CST)
Date: Thu, 2 Feb 2012 21:14:29 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
Message-ID: <58335eef.202ee.1353e33afdf.Coremail.hxkhust@126.com>
In-Reply-To: <20120201075100.GK12984@reaktio.net>
References: <20120201075100.GK12984@reaktio.net>
	<4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [119.98.187.105]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: aM/X0GZvb3Rlcl9odG09MjE2Mjo4MQ==
X-CM-TRANSID: F8qowGAZv0A1jCpPCCULAA--.4989W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbitBdIBUX9gpDXSwACsa
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] about page cache architecture of the dom0 and domUs
 in xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7528324433235625063=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7528324433235625063==
Content-Type: multipart/alternative; 
	boundary="----=_Part_349565_463448455.1328188469215"

------=_Part_349565_463448455.1328188469215
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGksUGFzaSBLw6Rya2vDpGluZW4sCgpBdCAyMDEyLTAyLTAxIDE1OjUxOjAwLCJQYXNpIEvDpHJr
a8OkaW5lbiIgPHBhc2lrQGlraS5maT4gd3JvdGU6Cj5PbiBXZWQsIEZlYiAwMSwgMjAxMiBhdCAx
MTo1MDowNkFNICswODAwLCBoeGtodXN0IHdyb3RlOgo+PiAgICBIaSwKPj4gICAgSSBlbmNvdW50
ZXIgYSBwcm9ibGVtIHRoYXQgaGFzIHB1enpsZWQgbWUgZm9yIGEgbG9uZyB0aW1lLk9uIGEgWGVu
Cj4+ICAgIHZpcnR1YWxpemF0aW9uIHBsYXRmb3JtLCBzb21lIFZNcyAsd2hvc2UgdmlydHVhbCBk
aXNrcyBhcmUgaW1hZ2UgZmlsZXMKPj4gICAgLGFyZSBydW5uaW5nIGluIERvbVVzLlVuZGVyIHRo
aXMgc2l0dWF0aW9uICxkb2VzIHRoZSBEb20wIGNhY2hlIHRoZSBwYWdlcwo+PiAgICBmcm9tIHRo
ZSBWTXM/RG9lcyB0aGUgZmlsZXN5c3RlbSBpbiBEb20wIHNlZSB0aGUgVk1zIGFzIGdlbmVyYWwg
cHJvY2Vzc2VzPwo+PiAKPgo+SXQgZGVwZW5kcyB3aGljaCBkaXNrIGJhY2tlbmQgZHJpdmVyIHlv
dSdyZSB1c2luZyBmb3IgdGhlIGRvbVUgZGlza3MuLgo+KGZpbGU6IG9yIHRhcDphaW86KQo+Cj4t
LSBQYXNpCj4KIApJbiB0aGUgbGFzdCBlbWFpbCBJIHRvcC1wb3N0IGFuZCBUaW0gcmVtaW5kIG1l
IG9mIHRoYXQgLHNvIEkgc2VuZCB0aGUgc2FtZSBjb250ZW50IHRvIHlvdSBhZ2Fpbi4gCgpJbiBt
b3N0IGNhc2VzLCBJIHVzZSAiZmlsZTovLi4uIiBvciAidGFwOnFjb3cyOi4uLiIgIGZvciBteSBW
TXMuV2hlbiBJIHVzZSAidGFwOmFpbzouLiIgaW4gdGhlIGNvbmZpZ3VyYXRpb24sc29tZ3RoaW5n
IHdyb25nIHdpbGwgaGFwcGVuLkF0IHRoZSBmaXJzdCB0aW1lIEkgc3BlY3VsYXRlIHRoYXQgdGhl
IGJsa3RhcC9ibGt0YXAyIG1vZHVsZSBpcyBub3QgaW5zdGFsbGVkIHN1Y2Nlc3NmdWxseS5UaHVz
IHNvbWUgdGltZSBhZ28gSSB0cnkgdG8gZmlndXJlIG91dCB0aGUgcHJvYmxlbS5Ib3dldmVyIEkg
ZmFpbGVkIGluIHRoZSBlbmQuQ291bGQgeW91IHRlbGwgbWUgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl
biAiZmlsZToiIGFuZCAidGFwOmFpbyIgZnJvbSB0aGUgcGFnZSBjYWNoZSBhcmNoaXRlY3R1cmUg
c2lkZT8KVGhlIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIGlzIG9mIGltcG9ydGFuY2UgZm9yIG1l
LkkgbmVlZCB5b3VyIGhlbHAuVGhhbmsgeW91LiAKCkhYSwoKCg==
------=_Part_349565_463448455.1328188469215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxESVYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxLjc7IEZPTlQtRkFN
SUxZOiBhcmlhbDsgQ09MT1I6ICMwMDAwMDA7IEZPTlQtU0laRTogMTRweCI+CjxESVY+SGksUGFz
aSZuYnNwO0vDpHJra8OkaW5lbiw8L0RJVj4KPERJVj48QlI+QXQmbmJzcDsyMDEyLTAyLTAxJm5i
c3A7MTU6NTE6MDAsIlBhc2kmbmJzcDtLw6Rya2vDpGluZW4iJm5ic3A7Jmx0OzxBIGhyZWY9Im1h
aWx0bzpwYXNpa0Bpa2kuZmkiPnBhc2lrQGlraS5maTwvQT4mZ3Q7Jm5ic3A7d3JvdGU6PEJSPiZn
dDtPbiZuYnNwO1dlZCwmbmJzcDtGZWImbmJzcDswMSwmbmJzcDsyMDEyJm5ic3A7YXQmbmJzcDsx
MTo1MDowNkFNJm5ic3A7KzA4MDAsJm5ic3A7aHhraHVzdCZuYnNwO3dyb3RlOjxCUj4mZ3Q7Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hpLDxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO0kmbmJzcDtlbmNvdW50ZXImbmJzcDthJm5ic3A7cHJvYmxlbSZuYnNwO3RoYXQmbmJz
cDtoYXMmbmJzcDtwdXp6bGVkJm5ic3A7bWUmbmJzcDtmb3ImbmJzcDthJm5ic3A7bG9uZyZuYnNw
O3RpbWUuT24mbmJzcDthJm5ic3A7WGVuPEJSPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7dmlydHVhbGl6YXRpb24mbmJzcDtwbGF0Zm9ybSwmbmJzcDtzb21lJm5ic3A7Vk1zJm5ic3A7
LHdob3NlJm5ic3A7dmlydHVhbCZuYnNwO2Rpc2tzJm5ic3A7YXJlJm5ic3A7aW1hZ2UmbmJzcDtm
aWxlczxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyxhcmUmbmJzcDtydW5uaW5n
Jm5ic3A7aW4mbmJzcDtEb21Vcy5VbmRlciZuYnNwO3RoaXMmbmJzcDtzaXR1YXRpb24mbmJzcDss
ZG9lcyZuYnNwO3RoZSZuYnNwO0RvbTAmbmJzcDtjYWNoZSZuYnNwO3RoZSZuYnNwO3BhZ2VzPEJS
PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO1ZNcz9E
b2VzJm5ic3A7dGhlJm5ic3A7ZmlsZXN5c3RlbSZuYnNwO2luJm5ic3A7RG9tMCZuYnNwO3NlZSZu
YnNwO3RoZSZuYnNwO1ZNcyZuYnNwO2FzJm5ic3A7Z2VuZXJhbCZuYnNwO3Byb2Nlc3Nlcz88QlI+
Jmd0OyZndDsmbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7SXQmbmJzcDtkZXBlbmRzJm5ic3A7d2hpY2gm
bmJzcDtkaXNrJm5ic3A7YmFja2VuZCZuYnNwO2RyaXZlciZuYnNwO3lvdSdyZSZuYnNwO3VzaW5n
Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZG9tVSZuYnNwO2Rpc2tzLi48QlI+Jmd0OyhmaWxlOiZu
YnNwO29yJm5ic3A7dGFwOmFpbzopPEJSPiZndDs8QlI+Jmd0Oy0tJm5ic3A7UGFzaTxCUj4mZ3Q7
PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SW4gdGhlIGxhc3QgZW1haWwmbmJzcDtJIHRv
cC1wb3N0IGFuZCBUaW0gcmVtaW5kIG1lIG9mIHRoYXQmbmJzcDssc28mbmJzcDtJIHNlbmQgdGhl
IHNhbWUgY29udGVudCB0byB5b3UgYWdhaW4uJm5ic3A7PEJSPjwvRElWPgo8RElWPkluIG1vc3Qg
Y2FzZXMsIEkgdXNlICJmaWxlOi8uLi4iIG9yJm5ic3A7InRhcDpxY293MjouLi4iJm5ic3A7IGZv
ciBteSBWTXMuV2hlbiBJIHVzZSAidGFwOmFpbzouLiIgaW4gdGhlIGNvbmZpZ3VyYXRpb24sc29t
Z3RoaW5nIHdyb25nIHdpbGwgaGFwcGVuLkF0IHRoZSBmaXJzdCB0aW1lIEkgc3BlY3VsYXRlIHRo
YXQgdGhlIGJsa3RhcC9ibGt0YXAyIG1vZHVsZSBpcyBub3QgaW5zdGFsbGVkIHN1Y2Nlc3NmdWxs
eS5UaHVzIHNvbWUgdGltZSBhZ28gSSB0cnkgdG8gZmlndXJlIG91dCB0aGUgcHJvYmxlbS5Ib3dl
dmVyIEkmbmJzcDtmYWlsZWQgaW4gdGhlIGVuZC5Db3VsZCB5b3UgdGVsbCBtZSB0aGUgZGlmZmVy
ZW5jZSBiZXR3ZWVuICJmaWxlOiIgYW5kICJ0YXA6YWlvIiBmcm9tIHRoZSBwYWdlIGNhY2hlIGFy
Y2hpdGVjdHVyZSBzaWRlPzwvRElWPgo8RElWPlRoZSBhbnN3ZXIgdG8gdGhpcyBxdWVzdGlvbiBp
cyZuYnNwO29mIGltcG9ydGFuY2UgZm9yIG1lLkkgbmVlZCB5b3VyIGhlbHAuVGhhbmsgeW91LiZu
YnNwOzxCUj48QlI+SFhLPC9ESVY+PC9ESVY+PEJSPjxCUj48U1BBTiB0aXRsZT0ibmV0ZWFzZWZv
b3RlciI+PFNQQU4gaWQ9Im5ldGVhc2VfbWFpbF9mb290ZXIiPjwvU1BBTj48L1NQQU4+PC9kaXY+
PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHNwYW4gaWQ9Im5ldGVhc2VfbWFp
bF9mb290ZXIiPjwvc3Bhbj48L3NwYW4+
------=_Part_349565_463448455.1328188469215--



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

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

--===============7528324433235625063==--



From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:14:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswUu-0002L1-NW; Thu, 02 Feb 2012 13:14:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RswUt-0002Kf-Fe
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:14:43 +0000
Received: from [85.158.138.51:56652] by server-4.bemta-3.messagelabs.com id
	80/C7-07654-24C8A2F4; Thu, 02 Feb 2012 13:14:42 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328188478!11519518!1
X-Originating-IP: [220.181.15.23]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDY3MDQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDY3MDQ=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27997 invoked from network); 2 Feb 2012 13:14:40 -0000
Received: from m15-23.126.com (HELO m15-23.126.com) (220.181.15.23)
	by server-14.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 13:14:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=ofcYZsafmHwZTUT
	SNyaHgB3i17iluizmmDaQp6vZNl4=; b=chEGczjMVk7eYkE9eyIsxBkSz33WO83
	yyxgRsl6BG/+feM2EYfeLsRqYhtXNxPpw+VR4SeKubzcqPGw0HnA4yQanWHea/As
	sfdu6jaNwzWhIzuMli+sG+T/JGCnM709NKdTM8H8asa350pBEaPd4acbsxH4voz3
	KADkc0ZrV09c=
Received: from hxkhust ( [119.98.187.105] ) by ajax-webmail-wmsvr23
	(Coremail) ; Thu, 2 Feb 2012 21:14:29 +0800 (CST)
Date: Thu, 2 Feb 2012 21:14:29 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
Message-ID: <58335eef.202ee.1353e33afdf.Coremail.hxkhust@126.com>
In-Reply-To: <20120201075100.GK12984@reaktio.net>
References: <20120201075100.GK12984@reaktio.net>
	<4ba27b10.6198.13537089f14.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [119.98.187.105]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: aM/X0GZvb3Rlcl9odG09MjE2Mjo4MQ==
X-CM-TRANSID: F8qowGAZv0A1jCpPCCULAA--.4989W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbitBdIBUX9gpDXSwACsa
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] about page cache architecture of the dom0 and domUs
 in xen platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7528324433235625063=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7528324433235625063==
Content-Type: multipart/alternative; 
	boundary="----=_Part_349565_463448455.1328188469215"

------=_Part_349565_463448455.1328188469215
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGksUGFzaSBLw6Rya2vDpGluZW4sCgpBdCAyMDEyLTAyLTAxIDE1OjUxOjAwLCJQYXNpIEvDpHJr
a8OkaW5lbiIgPHBhc2lrQGlraS5maT4gd3JvdGU6Cj5PbiBXZWQsIEZlYiAwMSwgMjAxMiBhdCAx
MTo1MDowNkFNICswODAwLCBoeGtodXN0IHdyb3RlOgo+PiAgICBIaSwKPj4gICAgSSBlbmNvdW50
ZXIgYSBwcm9ibGVtIHRoYXQgaGFzIHB1enpsZWQgbWUgZm9yIGEgbG9uZyB0aW1lLk9uIGEgWGVu
Cj4+ICAgIHZpcnR1YWxpemF0aW9uIHBsYXRmb3JtLCBzb21lIFZNcyAsd2hvc2UgdmlydHVhbCBk
aXNrcyBhcmUgaW1hZ2UgZmlsZXMKPj4gICAgLGFyZSBydW5uaW5nIGluIERvbVVzLlVuZGVyIHRo
aXMgc2l0dWF0aW9uICxkb2VzIHRoZSBEb20wIGNhY2hlIHRoZSBwYWdlcwo+PiAgICBmcm9tIHRo
ZSBWTXM/RG9lcyB0aGUgZmlsZXN5c3RlbSBpbiBEb20wIHNlZSB0aGUgVk1zIGFzIGdlbmVyYWwg
cHJvY2Vzc2VzPwo+PiAKPgo+SXQgZGVwZW5kcyB3aGljaCBkaXNrIGJhY2tlbmQgZHJpdmVyIHlv
dSdyZSB1c2luZyBmb3IgdGhlIGRvbVUgZGlza3MuLgo+KGZpbGU6IG9yIHRhcDphaW86KQo+Cj4t
LSBQYXNpCj4KIApJbiB0aGUgbGFzdCBlbWFpbCBJIHRvcC1wb3N0IGFuZCBUaW0gcmVtaW5kIG1l
IG9mIHRoYXQgLHNvIEkgc2VuZCB0aGUgc2FtZSBjb250ZW50IHRvIHlvdSBhZ2Fpbi4gCgpJbiBt
b3N0IGNhc2VzLCBJIHVzZSAiZmlsZTovLi4uIiBvciAidGFwOnFjb3cyOi4uLiIgIGZvciBteSBW
TXMuV2hlbiBJIHVzZSAidGFwOmFpbzouLiIgaW4gdGhlIGNvbmZpZ3VyYXRpb24sc29tZ3RoaW5n
IHdyb25nIHdpbGwgaGFwcGVuLkF0IHRoZSBmaXJzdCB0aW1lIEkgc3BlY3VsYXRlIHRoYXQgdGhl
IGJsa3RhcC9ibGt0YXAyIG1vZHVsZSBpcyBub3QgaW5zdGFsbGVkIHN1Y2Nlc3NmdWxseS5UaHVz
IHNvbWUgdGltZSBhZ28gSSB0cnkgdG8gZmlndXJlIG91dCB0aGUgcHJvYmxlbS5Ib3dldmVyIEkg
ZmFpbGVkIGluIHRoZSBlbmQuQ291bGQgeW91IHRlbGwgbWUgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl
biAiZmlsZToiIGFuZCAidGFwOmFpbyIgZnJvbSB0aGUgcGFnZSBjYWNoZSBhcmNoaXRlY3R1cmUg
c2lkZT8KVGhlIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIGlzIG9mIGltcG9ydGFuY2UgZm9yIG1l
LkkgbmVlZCB5b3VyIGhlbHAuVGhhbmsgeW91LiAKCkhYSwoKCg==
------=_Part_349565_463448455.1328188469215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxESVYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxLjc7IEZPTlQtRkFN
SUxZOiBhcmlhbDsgQ09MT1I6ICMwMDAwMDA7IEZPTlQtU0laRTogMTRweCI+CjxESVY+SGksUGFz
aSZuYnNwO0vDpHJra8OkaW5lbiw8L0RJVj4KPERJVj48QlI+QXQmbmJzcDsyMDEyLTAyLTAxJm5i
c3A7MTU6NTE6MDAsIlBhc2kmbmJzcDtLw6Rya2vDpGluZW4iJm5ic3A7Jmx0OzxBIGhyZWY9Im1h
aWx0bzpwYXNpa0Bpa2kuZmkiPnBhc2lrQGlraS5maTwvQT4mZ3Q7Jm5ic3A7d3JvdGU6PEJSPiZn
dDtPbiZuYnNwO1dlZCwmbmJzcDtGZWImbmJzcDswMSwmbmJzcDsyMDEyJm5ic3A7YXQmbmJzcDsx
MTo1MDowNkFNJm5ic3A7KzA4MDAsJm5ic3A7aHhraHVzdCZuYnNwO3dyb3RlOjxCUj4mZ3Q7Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hpLDxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO0kmbmJzcDtlbmNvdW50ZXImbmJzcDthJm5ic3A7cHJvYmxlbSZuYnNwO3RoYXQmbmJz
cDtoYXMmbmJzcDtwdXp6bGVkJm5ic3A7bWUmbmJzcDtmb3ImbmJzcDthJm5ic3A7bG9uZyZuYnNw
O3RpbWUuT24mbmJzcDthJm5ic3A7WGVuPEJSPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7dmlydHVhbGl6YXRpb24mbmJzcDtwbGF0Zm9ybSwmbmJzcDtzb21lJm5ic3A7Vk1zJm5ic3A7
LHdob3NlJm5ic3A7dmlydHVhbCZuYnNwO2Rpc2tzJm5ic3A7YXJlJm5ic3A7aW1hZ2UmbmJzcDtm
aWxlczxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyxhcmUmbmJzcDtydW5uaW5n
Jm5ic3A7aW4mbmJzcDtEb21Vcy5VbmRlciZuYnNwO3RoaXMmbmJzcDtzaXR1YXRpb24mbmJzcDss
ZG9lcyZuYnNwO3RoZSZuYnNwO0RvbTAmbmJzcDtjYWNoZSZuYnNwO3RoZSZuYnNwO3BhZ2VzPEJS
PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO1ZNcz9E
b2VzJm5ic3A7dGhlJm5ic3A7ZmlsZXN5c3RlbSZuYnNwO2luJm5ic3A7RG9tMCZuYnNwO3NlZSZu
YnNwO3RoZSZuYnNwO1ZNcyZuYnNwO2FzJm5ic3A7Z2VuZXJhbCZuYnNwO3Byb2Nlc3Nlcz88QlI+
Jmd0OyZndDsmbmJzcDs8QlI+Jmd0OzxCUj4mZ3Q7SXQmbmJzcDtkZXBlbmRzJm5ic3A7d2hpY2gm
bmJzcDtkaXNrJm5ic3A7YmFja2VuZCZuYnNwO2RyaXZlciZuYnNwO3lvdSdyZSZuYnNwO3VzaW5n
Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZG9tVSZuYnNwO2Rpc2tzLi48QlI+Jmd0OyhmaWxlOiZu
YnNwO29yJm5ic3A7dGFwOmFpbzopPEJSPiZndDs8QlI+Jmd0Oy0tJm5ic3A7UGFzaTxCUj4mZ3Q7
PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SW4gdGhlIGxhc3QgZW1haWwmbmJzcDtJIHRv
cC1wb3N0IGFuZCBUaW0gcmVtaW5kIG1lIG9mIHRoYXQmbmJzcDssc28mbmJzcDtJIHNlbmQgdGhl
IHNhbWUgY29udGVudCB0byB5b3UgYWdhaW4uJm5ic3A7PEJSPjwvRElWPgo8RElWPkluIG1vc3Qg
Y2FzZXMsIEkgdXNlICJmaWxlOi8uLi4iIG9yJm5ic3A7InRhcDpxY293MjouLi4iJm5ic3A7IGZv
ciBteSBWTXMuV2hlbiBJIHVzZSAidGFwOmFpbzouLiIgaW4gdGhlIGNvbmZpZ3VyYXRpb24sc29t
Z3RoaW5nIHdyb25nIHdpbGwgaGFwcGVuLkF0IHRoZSBmaXJzdCB0aW1lIEkgc3BlY3VsYXRlIHRo
YXQgdGhlIGJsa3RhcC9ibGt0YXAyIG1vZHVsZSBpcyBub3QgaW5zdGFsbGVkIHN1Y2Nlc3NmdWxs
eS5UaHVzIHNvbWUgdGltZSBhZ28gSSB0cnkgdG8gZmlndXJlIG91dCB0aGUgcHJvYmxlbS5Ib3dl
dmVyIEkmbmJzcDtmYWlsZWQgaW4gdGhlIGVuZC5Db3VsZCB5b3UgdGVsbCBtZSB0aGUgZGlmZmVy
ZW5jZSBiZXR3ZWVuICJmaWxlOiIgYW5kICJ0YXA6YWlvIiBmcm9tIHRoZSBwYWdlIGNhY2hlIGFy
Y2hpdGVjdHVyZSBzaWRlPzwvRElWPgo8RElWPlRoZSBhbnN3ZXIgdG8gdGhpcyBxdWVzdGlvbiBp
cyZuYnNwO29mIGltcG9ydGFuY2UgZm9yIG1lLkkgbmVlZCB5b3VyIGhlbHAuVGhhbmsgeW91LiZu
YnNwOzxCUj48QlI+SFhLPC9ESVY+PC9ESVY+PEJSPjxCUj48U1BBTiB0aXRsZT0ibmV0ZWFzZWZv
b3RlciI+PFNQQU4gaWQ9Im5ldGVhc2VfbWFpbF9mb290ZXIiPjwvU1BBTj48L1NQQU4+PC9kaXY+
PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHNwYW4gaWQ9Im5ldGVhc2VfbWFp
bF9mb290ZXIiPjwvc3Bhbj48L3NwYW4+
------=_Part_349565_463448455.1328188469215--



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

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

--===============7528324433235625063==--



From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:14:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswUt-0002Kj-A6; Thu, 02 Feb 2012 13:14:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RswUr-0002Ji-6u
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:14:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328188474!4233373!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6259 invoked from network); 2 Feb 2012 13:14:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:14:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswUj-000Dv9-E2; Thu, 02 Feb 2012 13:14:33 +0000
Date: Thu, 2 Feb 2012 13:14:33 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202131433.GM48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108167), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mm-locks.h |   10 ++++
>  xen/arch/x86/mm/p2m-pod.c  |  112 ++++++++++++++++++++++++++------------------
>  xen/arch/x86/mm/p2m-pt.c   |    1 +
>  xen/arch/x86/mm/p2m.c      |    8 ++-
>  xen/include/asm-x86/p2m.h  |   27 +++-------
>  5 files changed, 93 insertions(+), 65 deletions(-)
> 
> 
> The PoD layer has a comples locking discipline. It relies on the
> p2m being globally locked, and it also relies on the page alloc
> lock to protect some of its data structures. Replace this all by an
> explicit pod lock: per p2m, order enforced.
> 
> Three consequences:
>     - Critical sections in the pod code protected by the page alloc
>       lock are now reduced to modifications of the domain page list.
>     - When the p2m lock becomes fine-grained, there are no
>       assumptions broken in the PoD layer.
>     - The locking is easier to understand.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

This needs an Ack from George, too.  Also:

> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
>  
>      /* FIXME: Figure out how to avoid superpages */
> +    /* NOTE: Promote to globally locking the p2m. This will get complicated
> +     * in a fine-grained scenario. Even if we're to lock each gfn 
> +     * individually we must be careful about recursion limits and 
> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock constraints 
> +     * between p2m and pod locks */
> +    p2m_lock(p2m);

That's a scary comment.  It looks to me as if the mm-locks.h mechanism
_does_ enforce those constraints - am I missing something?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:14:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswUt-0002Kj-A6; Thu, 02 Feb 2012 13:14:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RswUr-0002Ji-6u
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:14:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328188474!4233373!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6259 invoked from network); 2 Feb 2012 13:14:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:14:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswUj-000Dv9-E2; Thu, 02 Feb 2012 13:14:33 +0000
Date: Thu, 2 Feb 2012 13:14:33 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202131433.GM48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108167), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mm-locks.h |   10 ++++
>  xen/arch/x86/mm/p2m-pod.c  |  112 ++++++++++++++++++++++++++------------------
>  xen/arch/x86/mm/p2m-pt.c   |    1 +
>  xen/arch/x86/mm/p2m.c      |    8 ++-
>  xen/include/asm-x86/p2m.h  |   27 +++-------
>  5 files changed, 93 insertions(+), 65 deletions(-)
> 
> 
> The PoD layer has a comples locking discipline. It relies on the
> p2m being globally locked, and it also relies on the page alloc
> lock to protect some of its data structures. Replace this all by an
> explicit pod lock: per p2m, order enforced.
> 
> Three consequences:
>     - Critical sections in the pod code protected by the page alloc
>       lock are now reduced to modifications of the domain page list.
>     - When the p2m lock becomes fine-grained, there are no
>       assumptions broken in the PoD layer.
>     - The locking is easier to understand.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

This needs an Ack from George, too.  Also:

> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
>  
>      /* FIXME: Figure out how to avoid superpages */
> +    /* NOTE: Promote to globally locking the p2m. This will get complicated
> +     * in a fine-grained scenario. Even if we're to lock each gfn 
> +     * individually we must be careful about recursion limits and 
> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock constraints 
> +     * between p2m and pod locks */
> +    p2m_lock(p2m);

That's a scary comment.  It looks to me as if the mm-locks.h mechanism
_does_ enforce those constraints - am I missing something?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswcS-0003C8-0k; Thu, 02 Feb 2012 13:22:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RswcP-0003B9-FT
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:22:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328188942!13119913!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3172 invoked from network); 2 Feb 2012 13:22:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:22:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 02 Feb 2012 13:22:21 +0000
Message-Id: <4F2A9C1C0200007800070823@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 02 Feb 2012 13:22:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
In-Reply-To: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.02.12 at 17:30, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1328108207 -3600
> # Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> x86/AMD: Add support for AMD's OSVW feature in guests.
> 
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on 
> family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> necessary: HLT and IO instructions are intercepted and therefore there is no
> reason for erratum 400 workaround in the guest.
> 
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.

As I was about to apply this to my local tree to give it a try, I had
to realize that the microcode integration is still not correct: There
is (at least from an abstract perspective) no guarantee for
cpu_request_microcode() to be called on all CPUs, yet you want
svm_host_osvw_init() to be re-run on all of them. If you choose
to not deal with this in a formally correct way, it should be stated
so in a code comment (to lower the risk of surprises when someone
touches that code) that this is not possible in practice because
collect_cpu_info() won't currently fail for CPUs of interest.

Further you need to serialize against onlining of CPUs while in
svm_host_osvw_reset(), and similarly protect the updating of the
globals in svm_host_osvw_init(). Probably a private locked shared
between those two functions is the best route to go here.

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> diff -r e2722b24dc09 -r 789bbf4f478b tools/libxc/xc_cpuid_x86.c
> --- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_cpuid_x86.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +                    bitmaskof(X86_FEATURE_OSVW) |
>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/hvm/svm/svm.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
>  
>  static bool_t amd_erratum383_found __read_mostly;
>  
> +/* OSVW bits */
> +static uint64_t osvw_length, osvw_status;
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -902,6 +905,61 @@ static void svm_do_resume(struct vcpu *v
>      reset_stack_and_jump(svm_asm_do_resume);
>  }
>  
> +static void svm_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return;
> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
> +    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 
> 298
> +     * is present (because we really don't know).
> +     */
> +    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
> +        vcpu->arch.hvm_svm.osvw.status |= 1;
> +}
> +
> +void svm_host_osvw_reset()
> +{
> +    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
> +    osvw_status = 0;
> +}
> +
> +void svm_host_osvw_init()
> +{
> +    /* 
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor 
> and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
> +    {
> +        uint64_t len, status;
> +         
> +        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
> +            len = status = 0;
> +
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +    }
> +    else
> +        osvw_length = osvw_status = 0;
> +}
> +
>  static int svm_domain_initialise(struct domain *d)
>  {
>      return 0;
> @@ -930,6 +988,9 @@ static int svm_vcpu_initialise(struct vc
>      }
>  
>      vpmu_initialise(v);
> +
> +    svm_guest_osvw_init(v);
> +
>      return 0;
>  }
>  
> @@ -1044,6 +1105,27 @@ static void svm_init_erratum_383(struct 
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, 
> bool_t read)
> +{
> +    uint eax, ebx, ecx, edx;
> +     
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
> +        return -1;
> +
> +    if ( read )
> +    {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.hvm_svm.osvw.length;
> +        else
> +            *val = v->arch.hvm_svm.osvw.status;
> +    } 
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> @@ -1094,6 +1176,9 @@ static int svm_cpu_up(void)
>      }
>  #endif
>  
> +    /* Initialize OSVW bits to be used by guests */
> +    svm_host_osvw_init();
> +
>      return 0;
>  }
>  
> @@ -1104,6 +1189,8 @@ struct hvm_function_table * __init start
>      if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
>          return NULL;
>  
> +    svm_host_osvw_reset();
> +
>      if ( svm_cpu_up() )
>      {
>          printk("SVM: failed to initialise.\n");
> @@ -1388,6 +1475,13 @@ static int svm_msr_read_intercept(unsign
>          vpmu_do_rdmsr(msr, msr_content);
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, msr_content, 1);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_rdmsr(v, msr, msr_content);
>          if ( ret < 0 )
> @@ -1512,6 +1606,13 @@ static int svm_msr_write_intercept(unsig
>           */
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, &msr_content, 0);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_wrmsr(v, msr, msr_content);
>          if ( ret < 0 )
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode.c
> --- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +        ret = microcode_ops->start_update();
> +        if ( ret != 0 )
> +        {
> +            xfree(info);
> +            return ret;
> +        }
> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode_amd.c
> --- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode_amd.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -25,6 +25,7 @@
>  #include <asm/msr.h>
>  #include <asm/processor.h>
>  #include <asm/microcode.h>
> +#include <asm/hvm/svm/svm.h>
>  
>  struct equiv_cpu_entry {
>      uint32_t installed_cpu;
> @@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! Wrong "
>                 "microcode patch file magic\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_amd = xmalloc(struct microcode_amd);
> @@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! "
>                 "Can not allocate memory for microcode patch\n");
> -        return -ENOMEM;
> +        error = -ENOMEM;
> +        goto out;
>      }
>  
>      error = install_equiv_cpu_table(mc_amd, buf, &offset);
> @@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
>      {
>          xfree(mc_amd);
>          printk(KERN_ERR "microcode: installing equivalent cpu table 
> failed\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_old = uci->mc.mc_amd;
> @@ -337,13 +341,19 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    } 
> +    else 
> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> @@ -395,11 +405,19 @@ err1:
>      return -ENOMEM;
>  }
>  
> +static int start_update(void) 
> +{
> +    svm_host_osvw_reset();
> +
> +    return 0;
> +}
> +
>  static const struct microcode_ops microcode_amd_ops = {
>      .microcode_resume_match           = microcode_resume_match,
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
> +    .start_update                     = start_update,
>  };
>  
>  static __init int microcode_init_amd(void)
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/platform_hypercall.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        /* 
> +         * alloc_vpcu() will access data which is modified during
> +         * microcode update
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        spin_unlock(&vcpu_alloc_lock);
>      }
>      break;
>  
> diff -r e2722b24dc09 -r 789bbf4f478b xen/common/domctl.c
> --- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/common/domctl.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -29,6 +29,7 @@
>  #include <xsm/xsm.h>
>  
>  static DEFINE_SPINLOCK(domctl_lock);
> +DEFINE_SPINLOCK(vcpu_alloc_lock);
>  
>  int cpumask_to_xenctl_cpumap(
>      struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> @@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /* 
> +         * Certain operations (e.g. CPU microcode updates) modify data 
> which is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                goto maxvcpu_out_novcpulock;
> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> @@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          ret = 0;
>  
>      maxvcpu_out:
> +        spin_unlock(&vcpu_alloc_lock);
> +
> +    maxvcpu_out_novcpulock:
>          domain_unpause(d);
>          rcu_unlock_domain(d);
>      }
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/svm.h
> --- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/svm.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
>                                    ~TSC_RATIO_RSVD_BITS )
>  #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
>  
> +extern void svm_host_osvw_reset(void);
> +extern void svm_host_osvw_init(void);
> +
>  #endif /* __ASM_X86_HVM_SVM_H__ */
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/vmcb.h
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -516,6 +516,12 @@ struct arch_svm_struct {
>      
>      /* AMD lightweight profiling MSR */
>      uint64_t guest_lwp_cfg;
> +
> +    /* OSVW MSRs */
> +    struct {
> +        u64 length;
> +        u64 status;
> +    } osvw;
>  };
>  
>  struct vmcb_struct *alloc_vmcb(void);
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/microcode.h
> --- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/microcode.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -11,6 +11,7 @@ struct microcode_ops {
>      int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
>      int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
>      int (*apply_microcode)(int cpu);
> +    int (*start_update)(void);
>  };
>  
>  struct cpu_signature {
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/xen/domain.h
> --- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/xen/domain.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
>  
>  void arch_vcpu_reset(struct vcpu *v);
>  
> +extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswcS-0003C8-0k; Thu, 02 Feb 2012 13:22:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RswcP-0003B9-FT
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:22:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328188942!13119913!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3172 invoked from network); 2 Feb 2012 13:22:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:22:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 02 Feb 2012 13:22:21 +0000
Message-Id: <4F2A9C1C0200007800070823@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 02 Feb 2012 13:22:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
In-Reply-To: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 01.02.12 at 17:30, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1328108207 -3600
> # Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> x86/AMD: Add support for AMD's OSVW feature in guests.
> 
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on 
> family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> necessary: HLT and IO instructions are intercepted and therefore there is no
> reason for erratum 400 workaround in the guest.
> 
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.

As I was about to apply this to my local tree to give it a try, I had
to realize that the microcode integration is still not correct: There
is (at least from an abstract perspective) no guarantee for
cpu_request_microcode() to be called on all CPUs, yet you want
svm_host_osvw_init() to be re-run on all of them. If you choose
to not deal with this in a formally correct way, it should be stated
so in a code comment (to lower the risk of surprises when someone
touches that code) that this is not possible in practice because
collect_cpu_info() won't currently fail for CPUs of interest.

Further you need to serialize against onlining of CPUs while in
svm_host_osvw_reset(), and similarly protect the updating of the
globals in svm_host_osvw_init(). Probably a private locked shared
between those two functions is the best route to go here.

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> diff -r e2722b24dc09 -r 789bbf4f478b tools/libxc/xc_cpuid_x86.c
> --- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_cpuid_x86.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +                    bitmaskof(X86_FEATURE_OSVW) |
>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/hvm/svm/svm.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
>  
>  static bool_t amd_erratum383_found __read_mostly;
>  
> +/* OSVW bits */
> +static uint64_t osvw_length, osvw_status;
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -902,6 +905,61 @@ static void svm_do_resume(struct vcpu *v
>      reset_stack_and_jump(svm_asm_do_resume);
>  }
>  
> +static void svm_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return;
> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
> +    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 
> 298
> +     * is present (because we really don't know).
> +     */
> +    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
> +        vcpu->arch.hvm_svm.osvw.status |= 1;
> +}
> +
> +void svm_host_osvw_reset()
> +{
> +    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
> +    osvw_status = 0;
> +}
> +
> +void svm_host_osvw_init()
> +{
> +    /* 
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor 
> and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
> +    {
> +        uint64_t len, status;
> +         
> +        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
> +            len = status = 0;
> +
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +    }
> +    else
> +        osvw_length = osvw_status = 0;
> +}
> +
>  static int svm_domain_initialise(struct domain *d)
>  {
>      return 0;
> @@ -930,6 +988,9 @@ static int svm_vcpu_initialise(struct vc
>      }
>  
>      vpmu_initialise(v);
> +
> +    svm_guest_osvw_init(v);
> +
>      return 0;
>  }
>  
> @@ -1044,6 +1105,27 @@ static void svm_init_erratum_383(struct 
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, 
> bool_t read)
> +{
> +    uint eax, ebx, ecx, edx;
> +     
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
> +        return -1;
> +
> +    if ( read )
> +    {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.hvm_svm.osvw.length;
> +        else
> +            *val = v->arch.hvm_svm.osvw.status;
> +    } 
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> @@ -1094,6 +1176,9 @@ static int svm_cpu_up(void)
>      }
>  #endif
>  
> +    /* Initialize OSVW bits to be used by guests */
> +    svm_host_osvw_init();
> +
>      return 0;
>  }
>  
> @@ -1104,6 +1189,8 @@ struct hvm_function_table * __init start
>      if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
>          return NULL;
>  
> +    svm_host_osvw_reset();
> +
>      if ( svm_cpu_up() )
>      {
>          printk("SVM: failed to initialise.\n");
> @@ -1388,6 +1475,13 @@ static int svm_msr_read_intercept(unsign
>          vpmu_do_rdmsr(msr, msr_content);
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, msr_content, 1);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_rdmsr(v, msr, msr_content);
>          if ( ret < 0 )
> @@ -1512,6 +1606,13 @@ static int svm_msr_write_intercept(unsig
>           */
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, &msr_content, 0);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_wrmsr(v, msr, msr_content);
>          if ( ret < 0 )
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode.c
> --- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +        ret = microcode_ops->start_update();
> +        if ( ret != 0 )
> +        {
> +            xfree(info);
> +            return ret;
> +        }
> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/microcode_amd.c
> --- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode_amd.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -25,6 +25,7 @@
>  #include <asm/msr.h>
>  #include <asm/processor.h>
>  #include <asm/microcode.h>
> +#include <asm/hvm/svm/svm.h>
>  
>  struct equiv_cpu_entry {
>      uint32_t installed_cpu;
> @@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! Wrong "
>                 "microcode patch file magic\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_amd = xmalloc(struct microcode_amd);
> @@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! "
>                 "Can not allocate memory for microcode patch\n");
> -        return -ENOMEM;
> +        error = -ENOMEM;
> +        goto out;
>      }
>  
>      error = install_equiv_cpu_table(mc_amd, buf, &offset);
> @@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
>      {
>          xfree(mc_amd);
>          printk(KERN_ERR "microcode: installing equivalent cpu table 
> failed\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_old = uci->mc.mc_amd;
> @@ -337,13 +341,19 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    } 
> +    else 
> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> @@ -395,11 +405,19 @@ err1:
>      return -ENOMEM;
>  }
>  
> +static int start_update(void) 
> +{
> +    svm_host_osvw_reset();
> +
> +    return 0;
> +}
> +
>  static const struct microcode_ops microcode_amd_ops = {
>      .microcode_resume_match           = microcode_resume_match,
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
> +    .start_update                     = start_update,
>  };
>  
>  static __init int microcode_init_amd(void)
> diff -r e2722b24dc09 -r 789bbf4f478b xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/platform_hypercall.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        /* 
> +         * alloc_vpcu() will access data which is modified during
> +         * microcode update
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        spin_unlock(&vcpu_alloc_lock);
>      }
>      break;
>  
> diff -r e2722b24dc09 -r 789bbf4f478b xen/common/domctl.c
> --- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/common/domctl.c	Wed Feb 01 15:56:47 2012 +0100
> @@ -29,6 +29,7 @@
>  #include <xsm/xsm.h>
>  
>  static DEFINE_SPINLOCK(domctl_lock);
> +DEFINE_SPINLOCK(vcpu_alloc_lock);
>  
>  int cpumask_to_xenctl_cpumap(
>      struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> @@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /* 
> +         * Certain operations (e.g. CPU microcode updates) modify data 
> which is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                goto maxvcpu_out_novcpulock;
> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> @@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          ret = 0;
>  
>      maxvcpu_out:
> +        spin_unlock(&vcpu_alloc_lock);
> +
> +    maxvcpu_out_novcpulock:
>          domain_unpause(d);
>          rcu_unlock_domain(d);
>      }
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/svm.h
> --- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/svm.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
>                                    ~TSC_RATIO_RSVD_BITS )
>  #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
>  
> +extern void svm_host_osvw_reset(void);
> +extern void svm_host_osvw_init(void);
> +
>  #endif /* __ASM_X86_HVM_SVM_H__ */
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/hvm/svm/vmcb.h
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -516,6 +516,12 @@ struct arch_svm_struct {
>      
>      /* AMD lightweight profiling MSR */
>      uint64_t guest_lwp_cfg;
> +
> +    /* OSVW MSRs */
> +    struct {
> +        u64 length;
> +        u64 status;
> +    } osvw;
>  };
>  
>  struct vmcb_struct *alloc_vmcb(void);
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/asm-x86/microcode.h
> --- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/microcode.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -11,6 +11,7 @@ struct microcode_ops {
>      int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
>      int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
>      int (*apply_microcode)(int cpu);
> +    int (*start_update)(void);
>  };
>  
>  struct cpu_signature {
> diff -r e2722b24dc09 -r 789bbf4f478b xen/include/xen/domain.h
> --- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/xen/domain.h	Wed Feb 01 15:56:47 2012 +0100
> @@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
>  
>  void arch_vcpu_reset(struct vcpu *v);
>  
> +extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:23:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswd1-0003GE-EH; Thu, 02 Feb 2012 13:23:07 +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 1Rswd0-0003G5-Oe
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:23:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328188943!58511156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30331 invoked from network); 2 Feb 2012 13:22:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:22:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10437812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 13: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.213.0; Thu, 2 Feb 2012
	13:23:05 +0000
Message-ID: <1328188984.2924.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Thu, 2 Feb 2012 13:23:04 +0000
In-Reply-To: <CAPLaKK4bR6V-ObCk5CW2JOUTyi2214TSQZp5Fc4xgcJ=eg8EZg@mail.gmail.com>
References: <6fde017c419e70925f15.1326761318@debian.localdomain>
	<1328185611.5359.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK4bR6V-ObCk5CW2JOUTyi2214TSQZp5Fc4xgcJ=eg8EZg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAyLTAyIGF0IDEzOjE0ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ID4g
T24gVHVlLCAyMDEyLTAxLTE3IGF0IDAwOjQ4ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gPj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+PiAjIERhdGUgMTMyNjIxOTE4MSAtMzYwMAo+ID4+
ICMgTm9kZSBJRCA2ZmRlMDE3YzQxOWU3MDkyNWYxNWViMDBlODI2NjEwNzAxMWUyMWNiCj4gPj4g
IyBQYXJlbnQgIDViMjY3NmFjMTMyMTg5NTE2OThjNDlmYTAzNTBmMmFjNDgyMjBmM2QKPiA+PiBi
dWlsZDogYWRkIGF1dG9jb25mIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVj
awo+ID4gWy4uLl0KPiA+Cj4gPiBJJ20gYWZyYWlkIEkgZ2V0IHRvbm5lcyBvZiByZWplY3RzIGZy
b20gdGhpcyBkdWUgdG8gd2hpdGVzcGFjZQo+ID4gY29ycnVwdGlvbi4KPiAKPiBEb24ndCBrbm93
IHdoYXQgaGFwcGVuZWQsIGJ1dCBzb21lIG9mIG15IHBhdGNoZXMgZ290IGNvcnJ1cHRlZCBvcgo+
IHNvbWV0aGluZy4gSSBnZXQgYSBtZXNzYWdlIHNheWluZyBwYXRjaCB3YXMgbm90IGFwcGxpZWQg
c3VjY2Vzc2Z1bGx5LAo+IGJ1dCB0aGVyZSBhcmUgbm90IHJlamVjdHMsIGFuZCB0aGUgcGF0Y2gg
c2VlbXMgdG8gYXBwbHkgb2suIElmIEkKPiB1cGRhdGUgdGhlbSAoaGcgcXJlZnJlc2gpIEkgZ2V0
IHRoZSBzYW1lIGVycm9yIGFmdGVyIEkgcXBvcCBhbmQgcXB1c2gKPiB0aGVtLiBEbyB5b3Uga25v
dyBhbnl3YXkgdG8gc29sdmUgdGhpcyBlYXNpbHk/CgpZb3UgbWlnaHQgYmUgYWJsZSB0byByZXNj
dWUgc29tZXRoaW5nIGZyb20gLmhnL3BhdGNoZXMgYnV0IG90aGVyIHRoYW4KdGhhdCBJIGRvbid0
IGhhdmUgYW55IGlkZWEgd2hhdCBtaWdodCBiZSBnb2luZyBvbi4uLgoKSWFuLgoKCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:23:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswd1-0003GE-EH; Thu, 02 Feb 2012 13:23:07 +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 1Rswd0-0003G5-Oe
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:23:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328188943!58511156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30331 invoked from network); 2 Feb 2012 13:22:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:22:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="10437812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 13: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.213.0; Thu, 2 Feb 2012
	13:23:05 +0000
Message-ID: <1328188984.2924.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Thu, 2 Feb 2012 13:23:04 +0000
In-Reply-To: <CAPLaKK4bR6V-ObCk5CW2JOUTyi2214TSQZp5Fc4xgcJ=eg8EZg@mail.gmail.com>
References: <6fde017c419e70925f15.1326761318@debian.localdomain>
	<1328185611.5359.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK4bR6V-ObCk5CW2JOUTyi2214TSQZp5Fc4xgcJ=eg8EZg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAyLTAyIGF0IDEzOjE0ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ID4g
T24gVHVlLCAyMDEyLTAxLTE3IGF0IDAwOjQ4ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gPj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+PiAjIERhdGUgMTMyNjIxOTE4MSAtMzYwMAo+ID4+
ICMgTm9kZSBJRCA2ZmRlMDE3YzQxOWU3MDkyNWYxNWViMDBlODI2NjEwNzAxMWUyMWNiCj4gPj4g
IyBQYXJlbnQgIDViMjY3NmFjMTMyMTg5NTE2OThjNDlmYTAzNTBmMmFjNDgyMjBmM2QKPiA+PiBi
dWlsZDogYWRkIGF1dG9jb25mIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVj
awo+ID4gWy4uLl0KPiA+Cj4gPiBJJ20gYWZyYWlkIEkgZ2V0IHRvbm5lcyBvZiByZWplY3RzIGZy
b20gdGhpcyBkdWUgdG8gd2hpdGVzcGFjZQo+ID4gY29ycnVwdGlvbi4KPiAKPiBEb24ndCBrbm93
IHdoYXQgaGFwcGVuZWQsIGJ1dCBzb21lIG9mIG15IHBhdGNoZXMgZ290IGNvcnJ1cHRlZCBvcgo+
IHNvbWV0aGluZy4gSSBnZXQgYSBtZXNzYWdlIHNheWluZyBwYXRjaCB3YXMgbm90IGFwcGxpZWQg
c3VjY2Vzc2Z1bGx5LAo+IGJ1dCB0aGVyZSBhcmUgbm90IHJlamVjdHMsIGFuZCB0aGUgcGF0Y2gg
c2VlbXMgdG8gYXBwbHkgb2suIElmIEkKPiB1cGRhdGUgdGhlbSAoaGcgcXJlZnJlc2gpIEkgZ2V0
IHRoZSBzYW1lIGVycm9yIGFmdGVyIEkgcXBvcCBhbmQgcXB1c2gKPiB0aGVtLiBEbyB5b3Uga25v
dyBhbnl3YXkgdG8gc29sdmUgdGhpcyBlYXNpbHk/CgpZb3UgbWlnaHQgYmUgYWJsZSB0byByZXNj
dWUgc29tZXRoaW5nIGZyb20gLmhnL3BhdGNoZXMgYnV0IG90aGVyIHRoYW4KdGhhdCBJIGRvbid0
IGhhdmUgYW55IGlkZWEgd2hhdCBtaWdodCBiZSBnb2luZyBvbi4uLgoKSWFuLgoKCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:26:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswgP-0003Tm-2N; Thu, 02 Feb 2012 13:26:37 +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 1RswgN-0003TN-73
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:26:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328189058!51110703!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7816 invoked from network); 2 Feb 2012 13:24:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:24:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswgF-000E1T-3x; Thu, 02 Feb 2012 13:26:27 +0000
Date: Thu, 2 Feb 2012 13:26:27 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202132627.GN48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<211872232129d7c6f4d0.1328126168@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <211872232129d7c6f4d0.1328126168@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 5] Re-order calls to put_gfn() around
	wait queu invocations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108168), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c       |   2 +-
>  xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
>  xen/arch/x86/mm.c                |  10 +++---
>  xen/arch/x86/mm/guest_walk.c     |   2 +-
>  xen/arch/x86/mm/hap/guest_walk.c |   6 +---
>  xen/arch/x86/mm/mem_access.c     |  10 +++++++
>  xen/arch/x86/mm/mem_event.c      |   5 +++
>  xen/arch/x86/mm/p2m.c            |  52 ++++++++++++++++++++++-----------------
>  xen/common/grant_table.c         |   2 +-
>  xen/common/memory.c              |   2 +-
>  xen/include/asm-x86/mem_access.h |   1 +
>  xen/include/asm-x86/mem_event.h  |   3 ++
>  xen/include/asm-x86/p2m.h        |   6 +++-
>  13 files changed, 80 insertions(+), 46 deletions(-)
> 
> 
> Since we use wait queues to handle potential ring congestion cases,
> code paths that try to generate a mem event while holding a gfn lock
> would go to sleep in non-preemptible mode.
> 
> Most such code paths can be fixed by simply postponing event generation until
> locks are released.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Looks OK, once the preceding patches are sorted out.  If you add some
comments to p2m_mem_access_check() describing its new argument and what
the caller's supposed to do about it, you can put my Ack on this next time.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:26:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswgP-0003Tm-2N; Thu, 02 Feb 2012 13:26:37 +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 1RswgN-0003TN-73
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:26:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328189058!51110703!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7816 invoked from network); 2 Feb 2012 13:24:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:24:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswgF-000E1T-3x; Thu, 02 Feb 2012 13:26:27 +0000
Date: Thu, 2 Feb 2012 13:26:27 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202132627.GN48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<211872232129d7c6f4d0.1328126168@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <211872232129d7c6f4d0.1328126168@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 5] Re-order calls to put_gfn() around
	wait queu invocations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108168), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c       |   2 +-
>  xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
>  xen/arch/x86/mm.c                |  10 +++---
>  xen/arch/x86/mm/guest_walk.c     |   2 +-
>  xen/arch/x86/mm/hap/guest_walk.c |   6 +---
>  xen/arch/x86/mm/mem_access.c     |  10 +++++++
>  xen/arch/x86/mm/mem_event.c      |   5 +++
>  xen/arch/x86/mm/p2m.c            |  52 ++++++++++++++++++++++-----------------
>  xen/common/grant_table.c         |   2 +-
>  xen/common/memory.c              |   2 +-
>  xen/include/asm-x86/mem_access.h |   1 +
>  xen/include/asm-x86/mem_event.h  |   3 ++
>  xen/include/asm-x86/p2m.h        |   6 +++-
>  13 files changed, 80 insertions(+), 46 deletions(-)
> 
> 
> Since we use wait queues to handle potential ring congestion cases,
> code paths that try to generate a mem event while holding a gfn lock
> would go to sleep in non-preemptible mode.
> 
> Most such code paths can be fixed by simply postponing event generation until
> locks are released.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Looks OK, once the preceding patches are sorted out.  If you add some
comments to p2m_mem_access_check() describing its new argument and what
the caller's supposed to do about it, you can put my Ack on this next time.

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:27:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswhS-0003ZB-Hq; Thu, 02 Feb 2012 13:27:42 +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 1RswhQ-0003Yj-Ov
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:27:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328189136!62258097!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6708 invoked from network); 2 Feb 2012 13:25:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:25:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswhK-000E1n-6j; Thu, 02 Feb 2012 13:27:34 +0000
Date: Thu, 2 Feb 2012 13:27:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202132734.GO48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<a8ba1fc6e4b3c4229bbf.1328126169@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a8ba1fc6e4b3c4229bbf.1328126169@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 5] x86/mm: Revert changeset
	24582:f6c33cfe7333
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108169), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/p2m.c |  4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> With synchronized p2m lookups this is no longer needed, and we can lock the p2m
> up-front.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tjd-xen@phlegethon.org>
(once the earlier patches are in, of course!)

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:27:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:27:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswhS-0003ZB-Hq; Thu, 02 Feb 2012 13:27:42 +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 1RswhQ-0003Yj-Ov
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:27:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328189136!62258097!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6708 invoked from network); 2 Feb 2012 13:25:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:25:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswhK-000E1n-6j; Thu, 02 Feb 2012 13:27:34 +0000
Date: Thu, 2 Feb 2012 13:27:34 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202132734.GO48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<a8ba1fc6e4b3c4229bbf.1328126169@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a8ba1fc6e4b3c4229bbf.1328126169@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 5] x86/mm: Revert changeset
	24582:f6c33cfe7333
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:56 -0500 on 01 Feb (1328108169), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/p2m.c |  4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> With synchronized p2m lookups this is no longer needed, and we can lock the p2m
> up-front.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tjd-xen@phlegethon.org>
(once the earlier patches are in, of course!)

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:35:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswod-0003pf-Ei; Thu, 02 Feb 2012 13:35:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rswoc-0003pa-Pr
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:35:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328189700!13363378!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32420 invoked from network); 2 Feb 2012 13:35:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:35:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswoV-000E2v-K1; Thu, 02 Feb 2012 13:34:59 +0000
Date: Thu, 2 Feb 2012 13:34:59 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202133459.GP48883@ocelot.phlegethon.org>
References: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] Domain relinquish resources racing with p2m access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:49 -0800 on 01 Feb (1328100564), Andres Lagar-Cavilla wrote:
> So we've run into this interesting (race?) condition while doing
> stress-testing. We pummel the domain with paging, sharing and mmap
> operations from dom0, and concurrently we launch a domain destruction.
> Often we get in the logs something along these lines
> 
> (XEN) mm.c:958:d0 Error getting mfn 859b1a (pfn ffffffffffffffff) from L1
> entry 8000000859b1a625 for l1e_owner=0, pg_owner=1
> 
> We're using the synchronized p2m patches just posted, so my analysis is as
> follows:
> 
> - the domain destroy domctl kicks in. It calls relinquish resources. This
> disowns and puts most domain pages, resulting in invalid (0xff...ff) m2p
> entries
> 
> - In parallel, a do_mmu_update is making progress, it has no issues
> performing a p2m lookup because the p2m has not been torn down yet; we
> haven't gotten to the RCU callback. Eventually, the mapping fails in
> page_get_owner in get_pafe_from_l1e.
> 
> The map is failed, as expected, but what makes me uneasy is the fact that
> there is a still active p2m lurking around, with seemingly valid
> translations to valid mfn's, while all the domain pages are gone.

Yes.  That's OK as long as we know that any user of that page will
fail, but I'm not sure that we do.   

At one point we talked about get_gfn() taking a refcount on the
underlying MFN, which would fix this more cleanly.  ISTR the problem was
how to make sure the refcount was moved when the gfn->mfn mapping
changed. 

Can you stick a WARN() in mm.c to get the actual path that leads to the
failure?

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:35:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswod-0003pf-Ei; Thu, 02 Feb 2012 13:35:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rswoc-0003pa-Pr
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:35:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328189700!13363378!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32420 invoked from network); 2 Feb 2012 13:35:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 13:35:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RswoV-000E2v-K1; Thu, 02 Feb 2012 13:34:59 +0000
Date: Thu, 2 Feb 2012 13:34:59 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120202133459.GP48883@ocelot.phlegethon.org>
References: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] Domain relinquish resources racing with p2m access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:49 -0800 on 01 Feb (1328100564), Andres Lagar-Cavilla wrote:
> So we've run into this interesting (race?) condition while doing
> stress-testing. We pummel the domain with paging, sharing and mmap
> operations from dom0, and concurrently we launch a domain destruction.
> Often we get in the logs something along these lines
> 
> (XEN) mm.c:958:d0 Error getting mfn 859b1a (pfn ffffffffffffffff) from L1
> entry 8000000859b1a625 for l1e_owner=0, pg_owner=1
> 
> We're using the synchronized p2m patches just posted, so my analysis is as
> follows:
> 
> - the domain destroy domctl kicks in. It calls relinquish resources. This
> disowns and puts most domain pages, resulting in invalid (0xff...ff) m2p
> entries
> 
> - In parallel, a do_mmu_update is making progress, it has no issues
> performing a p2m lookup because the p2m has not been torn down yet; we
> haven't gotten to the RCU callback. Eventually, the mapping fails in
> page_get_owner in get_pafe_from_l1e.
> 
> The map is failed, as expected, but what makes me uneasy is the fact that
> there is a still active p2m lurking around, with seemingly valid
> translations to valid mfn's, while all the domain pages are gone.

Yes.  That's OK as long as we know that any user of that page will
fail, but I'm not sure that we do.   

At one point we talked about get_gfn() taking a refcount on the
underlying MFN, which would fix this more cleanly.  ISTR the problem was
how to make sure the refcount was moved when the gfn->mfn mapping
changed. 

Can you stick a WARN() in mm.c to get the actual path that leads to the
failure?

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswsy-0003xo-5q; Thu, 02 Feb 2012 13:39:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswsx-0003xj-B6
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:35 +0000
Received: from [85.158.138.51:19683] by server-1.bemta-3.messagelabs.com id
	57/2D-23590-6129A2F4; Thu, 02 Feb 2012 13:39:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328189973!11700763!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10956 invoked from network); 2 Feb 2012 13:39:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:33 -0000
Received: by werb14 with SMTP id b14so4652590wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rwTlCTxeyRGnS9/nWPoDNCDHpg7N6D/UZllB1+UZ7uA=;
	b=bY5PdEF4gXF7OOPbn/LUKYuKc1Jmp7UjNgbhJ737ywaXrCHN7ShPifz5FPUAX2iBnm
	+u2GxKswzrAOnXqHr1xfKYp6h/wRBvhALNZfqIebam3O8SKNKLrHETbw3tgAn8BhF+dy
	MWW56UF+4skh3aXsBvtVjma0yWsrmBEx/Y8To=
Received: by 10.216.133.70 with SMTP id p48mr4618463wei.23.1328189973437;
	Thu, 02 Feb 2012 05:39:33 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e38c059da393c3fa2ee222d2e90275ca88b85d4f
Message-Id: <e38c059da393c3fa2ee2.1328189196@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:36 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 29 RFC] libxl: Atomicaly check backend
 state and set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326548456 -3600
# Node ID e38c059da393c3fa2ee222d2e90275ca88b85d4f
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: Atomicaly check backend state and set it to 5 at device_remove

libxl__device_remove was setting backend state to 5, which could
create a race condition, since the previous check for state != 4 and
setting state to 5 was not done inside the same transaction, so the
kernel could change the state to 6 in the space between the check for
state != 4 and setting it to 5.

The state != 4 check and setting it to 5 should happen in the same
transaction, to assure that nobody is modifying it behind our back.

Changes since v1:

 * Do the check and set in the same transaction, instead of removing
   the set state to 5.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e2722b24dc09 -r e38c059da393 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_device.c	Sat Jan 14 14:40:56 2012 +0100
@@ -433,19 +433,23 @@ int libxl__device_remove(libxl__gc *gc, 
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
 
-    if (!state)
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
+    if (!state) {
+        xs_transaction_end(ctx->xsh, t, 0);
         goto out;
+    }
     if (atoi(state) != 4) {
+        xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
     }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswsy-0003xo-5q; Thu, 02 Feb 2012 13:39:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswsx-0003xj-B6
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:35 +0000
Received: from [85.158.138.51:19683] by server-1.bemta-3.messagelabs.com id
	57/2D-23590-6129A2F4; Thu, 02 Feb 2012 13:39:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328189973!11700763!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10956 invoked from network); 2 Feb 2012 13:39:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:33 -0000
Received: by werb14 with SMTP id b14so4652590wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rwTlCTxeyRGnS9/nWPoDNCDHpg7N6D/UZllB1+UZ7uA=;
	b=bY5PdEF4gXF7OOPbn/LUKYuKc1Jmp7UjNgbhJ737ywaXrCHN7ShPifz5FPUAX2iBnm
	+u2GxKswzrAOnXqHr1xfKYp6h/wRBvhALNZfqIebam3O8SKNKLrHETbw3tgAn8BhF+dy
	MWW56UF+4skh3aXsBvtVjma0yWsrmBEx/Y8To=
Received: by 10.216.133.70 with SMTP id p48mr4618463wei.23.1328189973437;
	Thu, 02 Feb 2012 05:39:33 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e38c059da393c3fa2ee222d2e90275ca88b85d4f
Message-Id: <e38c059da393c3fa2ee2.1328189196@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:36 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 29 RFC] libxl: Atomicaly check backend
 state and set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326548456 -3600
# Node ID e38c059da393c3fa2ee222d2e90275ca88b85d4f
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: Atomicaly check backend state and set it to 5 at device_remove

libxl__device_remove was setting backend state to 5, which could
create a race condition, since the previous check for state != 4 and
setting state to 5 was not done inside the same transaction, so the
kernel could change the state to 6 in the space between the check for
state != 4 and setting it to 5.

The state != 4 check and setting it to 5 should happen in the same
transaction, to assure that nobody is modifying it behind our back.

Changes since v1:

 * Do the check and set in the same transaction, instead of removing
   the set state to 5.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e2722b24dc09 -r e38c059da393 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_device.c	Sat Jan 14 14:40:56 2012 +0100
@@ -433,19 +433,23 @@ int libxl__device_remove(libxl__gc *gc, 
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
 
-    if (!state)
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
+    if (!state) {
+        xs_transaction_end(ctx->xsh, t, 0);
         goto out;
+    }
     if (atoi(state) != 4) {
+        xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
     }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswt3-0003zE-JA; Thu, 02 Feb 2012 13:39:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswt1-0003yf-QD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:40 +0000
Received: from [85.158.138.51:57237] by server-4.bemta-3.messagelabs.com id
	78/3D-07654-B129A2F4; Thu, 02 Feb 2012 13:39:39 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16826 invoked from network); 2 Feb 2012 13:39:38 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:38 -0000
Received: by wibhm2 with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=HJkbQ3D61G5gplxjGxP1AxY5VDUjCzgPJAxuNuVNC3k=;
	b=XrsL2AHYXez6LLK81IHlscgyW4PcsTEHP99TfHNoFmsm4SZIdvzu547js2LiyCRfzN
	6QknXalSdF/HH4aOWeCp3d83eoaz2zLj717qVkQth5GVQX9FFBG6QzMsZmwVZgVU3KA2
	hDQ2GxbN2EDiE4y/kYZEiaCR1UIOGLdCbQvBQ=
Received: by 10.180.101.200 with SMTP id fi8mr4580419wib.20.1328189978054;
	Thu, 02 Feb 2012 05:39:38 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b380ea895013853efd335c3fba4fe22f27ce1de1
Message-Id: <b380ea895013853efd33.1328189198@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 29 RFC] libxl: allow libxl__exec to take a
 parameter containing the env variables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328175734 -3600
# Node ID b380ea895013853efd335c3fba4fe22f27ce1de1
# Parent  9a8ccac7b5986622f76fb8c501d2ef500f2d77a1
libxl: allow libxl__exec to take a parameter containing the env variables

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Thu Feb 02 10:42:14 2012 +0100
@@ -940,7 +940,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 02 10:42:14 2012 +0100
@@ -111,12 +111,12 @@ static int open_xenconsoled_pty(int *mas
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_dm.c	Thu Feb 02 10:42:14 2012 +0100
@@ -874,7 +874,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Thu Feb 02 10:42:14 2012 +0100
@@ -72,7 +72,7 @@ static void check_open_fds(const char *w
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdout
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 10:42:14 2012 +0100
@@ -479,7 +479,7 @@ typedef struct {
  /* low-level stuff, for synchronous subprocesses etc. */
 
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswt0-0003yQ-P7; Thu, 02 Feb 2012 13:39:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswsy-0003xq-ND
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328189921!55100967!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18100 invoked from network); 2 Feb 2012 13:38:41 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:38:41 -0000
Received: by wgbdr13 with SMTP id dr13so2335049wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=4prF4WXoT8XygzQ8qzhDMXcDDA9p2I/fIP9im09a7yo=;
	b=IboOzH4MOhicHeMLQziBZLrHVuLsmzTy/LxnpqUEgSEhdDNRsH66OuQfcdHXJf7aHC
	Z5ObxAa04BfTb6OfqMkYpMhgZ2huITdPLLUzLds5rzHl3jHH2F3s9kvJkLexsCs4N5bW
	5TT7Y1qcpJcwcxsQqvxI0cMo68jjU0ugjHsps=
Received: by 10.180.78.6 with SMTP id x6mr15062706wiw.18.1328189975325;
	Thu, 02 Feb 2012 05:39:35 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9a8ccac7b5986622f76fb8c501d2ef500f2d77a1
Message-Id: <9a8ccac7b5986622f76f.1328189197@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:37 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 29 RFC] hotplug/block: get the type of
 block device from file path (NetBSD)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 9a8ccac7b5986622f76fb8c501d2ef500f2d77a1
# Parent  e38c059da393c3fa2ee222d2e90275ca88b85d4f
hotplug/block: get the type of block device from file path (NetBSD)

Guess the type of block device to attach based on the file name
present in xenstore, since new Xen versions don't make a difference
between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e38c059da393 -r 9a8ccac7b598 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 14:40:56 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,9 +19,14 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
 xparams=$(xenstore-read "$xpath/params")
 
+if [ -f $xparams ]; then
+	xtype="file"
+else
+	xtype="phy"
+fi
+
 case $xstatus in
 6)
 	# device removed

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswt3-0003zE-JA; Thu, 02 Feb 2012 13:39:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswt1-0003yf-QD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:40 +0000
Received: from [85.158.138.51:57237] by server-4.bemta-3.messagelabs.com id
	78/3D-07654-B129A2F4; Thu, 02 Feb 2012 13:39:39 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16826 invoked from network); 2 Feb 2012 13:39:38 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:38 -0000
Received: by wibhm2 with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=HJkbQ3D61G5gplxjGxP1AxY5VDUjCzgPJAxuNuVNC3k=;
	b=XrsL2AHYXez6LLK81IHlscgyW4PcsTEHP99TfHNoFmsm4SZIdvzu547js2LiyCRfzN
	6QknXalSdF/HH4aOWeCp3d83eoaz2zLj717qVkQth5GVQX9FFBG6QzMsZmwVZgVU3KA2
	hDQ2GxbN2EDiE4y/kYZEiaCR1UIOGLdCbQvBQ=
Received: by 10.180.101.200 with SMTP id fi8mr4580419wib.20.1328189978054;
	Thu, 02 Feb 2012 05:39:38 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b380ea895013853efd335c3fba4fe22f27ce1de1
Message-Id: <b380ea895013853efd33.1328189198@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 29 RFC] libxl: allow libxl__exec to take a
 parameter containing the env variables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328175734 -3600
# Node ID b380ea895013853efd335c3fba4fe22f27ce1de1
# Parent  9a8ccac7b5986622f76fb8c501d2ef500f2d77a1
libxl: allow libxl__exec to take a parameter containing the env variables

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Thu Feb 02 10:42:14 2012 +0100
@@ -940,7 +940,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 02 10:42:14 2012 +0100
@@ -111,12 +111,12 @@ static int open_xenconsoled_pty(int *mas
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_dm.c	Thu Feb 02 10:42:14 2012 +0100
@@ -874,7 +874,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Thu Feb 02 10:42:14 2012 +0100
@@ -72,7 +72,7 @@ static void check_open_fds(const char *w
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -95,6 +95,11 @@ void libxl__exec(int stdinfd, int stdout
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff -r 9a8ccac7b598 -r b380ea895013 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 10:42:14 2012 +0100
@@ -479,7 +479,7 @@ typedef struct {
  /* low-level stuff, for synchronous subprocesses etc. */
 
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswt0-0003yQ-P7; Thu, 02 Feb 2012 13:39:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswsy-0003xq-ND
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328189921!55100967!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18100 invoked from network); 2 Feb 2012 13:38:41 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:38:41 -0000
Received: by wgbdr13 with SMTP id dr13so2335049wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=4prF4WXoT8XygzQ8qzhDMXcDDA9p2I/fIP9im09a7yo=;
	b=IboOzH4MOhicHeMLQziBZLrHVuLsmzTy/LxnpqUEgSEhdDNRsH66OuQfcdHXJf7aHC
	Z5ObxAa04BfTb6OfqMkYpMhgZ2huITdPLLUzLds5rzHl3jHH2F3s9kvJkLexsCs4N5bW
	5TT7Y1qcpJcwcxsQqvxI0cMo68jjU0ugjHsps=
Received: by 10.180.78.6 with SMTP id x6mr15062706wiw.18.1328189975325;
	Thu, 02 Feb 2012 05:39:35 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9a8ccac7b5986622f76fb8c501d2ef500f2d77a1
Message-Id: <9a8ccac7b5986622f76f.1328189197@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:37 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 29 RFC] hotplug/block: get the type of
 block device from file path (NetBSD)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 9a8ccac7b5986622f76fb8c501d2ef500f2d77a1
# Parent  e38c059da393c3fa2ee222d2e90275ca88b85d4f
hotplug/block: get the type of block device from file path (NetBSD)

Guess the type of block device to attach based on the file name
present in xenstore, since new Xen versions don't make a difference
between a block device or an image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e38c059da393 -r 9a8ccac7b598 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 14:40:56 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,9 +19,14 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
 xparams=$(xenstore-read "$xpath/params")
 
+if [ -f $xparams ]; then
+	xtype="file"
+else
+	xtype="phy"
+fi
+
 case $xstatus in
 6)
 	# device removed

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswt1-0003yZ-5H; Thu, 02 Feb 2012 13:39:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswsz-0003y8-MD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:37 +0000
Received: from [85.158.138.51:21859] by server-3.bemta-3.messagelabs.com id
	FE/FC-18959-8129A2F4; Thu, 02 Feb 2012 13:39:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328189973!11700763!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11044 invoked from network); 2 Feb 2012 13:39:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:35 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4652590wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=DV/cVTN9jzyDrIzY3L13ZQypezgkNHqaLa4eOVnoWqM=;
	b=eIfFR70xdj2dZaAR4mOG4DWVyp51+I9Px27FRQ8meq8xqQ9cCFi0vUGnegKEcvWmtC
	qFO8zOblI78vwLAS/21/79BgN1My6haB9O+0MsxljrqbqfT0bo/fTWAA/ggVRoJ6bt7B
	+8yGaJ9v9cPXOXli0QDUPId1YFrjI1J+pmaE4=
Received: by 10.216.137.147 with SMTP id y19mr4589432wei.34.1328189971456;
	Thu, 02 Feb 2012 05:39:31 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:30 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:35 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 29 RFC] libxl: move device plug/unplug to
 a separate daemon
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is the first attempt to delegate hotplug device plug/unplug to a 
separate daemon. This will also allow to plug/unplug devices from a 
domain different than Dom0, usually called a "driver domain".

This series contain a mix of bug fixes, mainly for device 
unplug/destroy synchronization, and a set of new functions that 
describe a new protocol to be used when delegating the plug/unplug of 
devices to a daemon, called xldeviced (xl-device-daemon).

As a very important note, I would like to add that this has only been 
tested with PV DomUs, and that qdisk support is missing (xldeviced is 
not prepared to launch a qemu-dm to support qdisk devices). I will 
work on that, but I think there's already a lot of stuff on this that 
needs proper review.

The series has the following order:

 * patches 1-15: set everything necessary to execute hotplug scripts 
   from libxl directly.

 * patches 16-25: add necessary libxl functions to delegate hotplug 
   addition to a different daemon

 * patches 26-29: introduce xldeviced and start using it by default.

Patch 20 contains a good description of the interaction between xl and 
xldeviced, and the xenstore entries used to accomplish this task.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswt1-0003yZ-5H; Thu, 02 Feb 2012 13:39:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswsz-0003y8-MD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:37 +0000
Received: from [85.158.138.51:21859] by server-3.bemta-3.messagelabs.com id
	FE/FC-18959-8129A2F4; Thu, 02 Feb 2012 13:39:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328189973!11700763!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11044 invoked from network); 2 Feb 2012 13:39:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:35 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4652590wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=DV/cVTN9jzyDrIzY3L13ZQypezgkNHqaLa4eOVnoWqM=;
	b=eIfFR70xdj2dZaAR4mOG4DWVyp51+I9Px27FRQ8meq8xqQ9cCFi0vUGnegKEcvWmtC
	qFO8zOblI78vwLAS/21/79BgN1My6haB9O+0MsxljrqbqfT0bo/fTWAA/ggVRoJ6bt7B
	+8yGaJ9v9cPXOXli0QDUPId1YFrjI1J+pmaE4=
Received: by 10.216.137.147 with SMTP id y19mr4589432wei.34.1328189971456;
	Thu, 02 Feb 2012 05:39:31 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:30 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:35 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 29 RFC] libxl: move device plug/unplug to
 a separate daemon
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is the first attempt to delegate hotplug device plug/unplug to a 
separate daemon. This will also allow to plug/unplug devices from a 
domain different than Dom0, usually called a "driver domain".

This series contain a mix of bug fixes, mainly for device 
unplug/destroy synchronization, and a set of new functions that 
describe a new protocol to be used when delegating the plug/unplug of 
devices to a daemon, called xldeviced (xl-device-daemon).

As a very important note, I would like to add that this has only been 
tested with PV DomUs, and that qdisk support is missing (xldeviced is 
not prepared to launch a qemu-dm to support qdisk devices). I will 
work on that, but I think there's already a lot of stuff on this that 
needs proper review.

The series has the following order:

 * patches 1-15: set everything necessary to execute hotplug scripts 
   from libxl directly.

 * patches 16-25: add necessary libxl functions to delegate hotplug 
   addition to a different daemon

 * patches 26-29: introduce xldeviced and start using it by default.

Patch 20 contains a good description of the interaction between xl and 
xldeviced, and the xenstore entries used to accomplish this task.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswtD-00041x-1f; Thu, 02 Feb 2012 13:39:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtB-00041C-8z
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328189921!55100967!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18787 invoked from network); 2 Feb 2012 13:38:53 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:38:53 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr13so2335049wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=fxDJMzg6M5tELV/hX2ufTk0fH4S+f2aapYoPuePsfds=;
	b=OA3+NQLPVWkrSn3N3lNm1a3mp1wDZklrAUtThL3nuXfxuyayu+FAkWJuMpGElt3YI5
	+qwz5O4BJ221vgV+booZ8AZ63artolN7QW4Z5wlsEF08Ieo5O+6ndkQO1kbiZJNtOCgT
	jfOjYpMBYeqi7ko/EOJI/WYht3H3m0dI2RvP8=
Received: by 10.180.92.227 with SMTP id cp3mr4653286wib.13.1328189987936;
	Thu, 02 Feb 2012 05:39:47 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 70e65c85e4c0af5be0d309ce7e5eec2a170cfcf7
Message-Id: <70e65c85e4c0af5be0d3.1328189199@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:39 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 29 RFC] libxl: add libxl__forkexec
	function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 70e65c85e4c0af5be0d309ce7e5eec2a170cfcf7
# Parent  b380ea895013853efd335c3fba4fe22f27ce1de1
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b380ea895013 -r 70e65c85e4c0 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Thu Feb 02 10:42:14 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Sat Jan 14 19:04:48 2012 +0100
@@ -443,6 +443,42 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, const char *arg0, char **args,
+                    char **env, const char *what)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, arg0, args, env);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                                 "waitpid failed for %s\n",
+                                 what);
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          what, pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r b380ea895013 -r 70e65c85e4c0 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 10:42:14 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
@@ -481,6 +481,21 @@ typedef struct {
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args, char **env); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * argv0: file name associated with the file being executed.
+ * args: list of arguments. See execvp(3) man page for more info.
+ * env: environment variables. See execvp(3) man page for more info.
+ *
+ * Returns -1 if the execution fails or the exit status, as reported
+ * by waitpid, on success.
+ *
+ * Logs errors.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, const char *arg0, char **args,
+                            char **env, const char *what);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:39:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswtD-00041x-1f; Thu, 02 Feb 2012 13:39:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtB-00041C-8z
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328189921!55100967!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18787 invoked from network); 2 Feb 2012 13:38:53 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:38:53 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr13so2335049wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=fxDJMzg6M5tELV/hX2ufTk0fH4S+f2aapYoPuePsfds=;
	b=OA3+NQLPVWkrSn3N3lNm1a3mp1wDZklrAUtThL3nuXfxuyayu+FAkWJuMpGElt3YI5
	+qwz5O4BJ221vgV+booZ8AZ63artolN7QW4Z5wlsEF08Ieo5O+6ndkQO1kbiZJNtOCgT
	jfOjYpMBYeqi7ko/EOJI/WYht3H3m0dI2RvP8=
Received: by 10.180.92.227 with SMTP id cp3mr4653286wib.13.1328189987936;
	Thu, 02 Feb 2012 05:39:47 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 70e65c85e4c0af5be0d309ce7e5eec2a170cfcf7
Message-Id: <70e65c85e4c0af5be0d3.1328189199@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:39 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 29 RFC] libxl: add libxl__forkexec
	function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 70e65c85e4c0af5be0d309ce7e5eec2a170cfcf7
# Parent  b380ea895013853efd335c3fba4fe22f27ce1de1
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b380ea895013 -r 70e65c85e4c0 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Thu Feb 02 10:42:14 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Sat Jan 14 19:04:48 2012 +0100
@@ -443,6 +443,42 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, const char *arg0, char **args,
+                    char **env, const char *what)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, arg0, args, env);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                                 "waitpid failed for %s\n",
+                                 what);
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          what, pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r b380ea895013 -r 70e65c85e4c0 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 10:42:14 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
@@ -481,6 +481,21 @@ typedef struct {
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args, char **env); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * argv0: file name associated with the file being executed.
+ * args: list of arguments. See execvp(3) man page for more info.
+ * env: environment variables. See execvp(3) man page for more info.
+ *
+ * Returns -1 if the execution fails or the exit status, as reported
+ * by waitpid, on success.
+ *
+ * Logs errors.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, const char *arg0, char **args,
+                            char **env, const char *what);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswtH-00044O-Ef; Thu, 02 Feb 2012 13:39:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtG-00043d-83
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:54 +0000
Received: from [85.158.138.51:23284] by server-9.bemta-3.messagelabs.com id
	F8/40-21252-9229A2F4; Thu, 02 Feb 2012 13:39:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17941 invoked from network); 2 Feb 2012 13:39:52 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:52 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JK5T507SAnAC4KsIGN/GZHVw8ZFJ5kzySJuY7AXSfIk=;
	b=Aac8MNFYesuRGhgZ2wJINeRP4KJzwiyttdT2ykt1Bpz5DqxBGLAlKs996syQi9oV6q
	Czkyi9JekKsQGn2Vz8G+W2LcbRwFSuV65r+NRvB1U8x8I2Dais6SE8wowMBt5rOYQcSh
	PIrti2MvyRJULsjOAH0bJqvN33ski2S8YGN34=
Received: by 10.180.84.105 with SMTP id x9mr17834821wiy.19.1328189992657;
	Thu, 02 Feb 2012 05:39:52 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 98c4670598600f62df864840a0cffb96ad9553f2
Message-Id: <98c4670598600f62df86.1328189200@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 29 RFC] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 98c4670598600f62df864840a0cffb96ad9553f2
# Parent  70e65c85e4c0af5be0d309ce7e5eec2a170cfcf7
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices (with backend PHY or TAP) to initialize
(switch to state 2). This is necessary because we need to call the
hotplug scripts when state is 2, otherwise the execution fails. Make
use of the newly introduced function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 70e65c85e4c0 -r 98c467059860 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
@@ -1002,6 +1002,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1106,6 +1108,27 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        be_path = libxl__device_backend_path(gc, &device);
+        state_path = libxl__sprintf(gc, "%s/state", be_path);
+        state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+        if (atoi(state) != XenbusStateInitWait) {
+            xs_watch(ctx->xsh, state_path, be_path);
+            tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+            tv.tv_usec = 0;
+            rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait,
+                                              NULL);
+            xs_unwatch(ctx->xsh, state_path, be_path);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unable to initialize disk device: %s",
+                           disk->pdev_path);
+                goto out_free;
+            }
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1481,6 +1504,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1555,8 +1580,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswtH-00044O-Ef; Thu, 02 Feb 2012 13:39:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtG-00043d-83
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:54 +0000
Received: from [85.158.138.51:23284] by server-9.bemta-3.messagelabs.com id
	F8/40-21252-9229A2F4; Thu, 02 Feb 2012 13:39:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17941 invoked from network); 2 Feb 2012 13:39:52 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:52 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JK5T507SAnAC4KsIGN/GZHVw8ZFJ5kzySJuY7AXSfIk=;
	b=Aac8MNFYesuRGhgZ2wJINeRP4KJzwiyttdT2ykt1Bpz5DqxBGLAlKs996syQi9oV6q
	Czkyi9JekKsQGn2Vz8G+W2LcbRwFSuV65r+NRvB1U8x8I2Dais6SE8wowMBt5rOYQcSh
	PIrti2MvyRJULsjOAH0bJqvN33ski2S8YGN34=
Received: by 10.180.84.105 with SMTP id x9mr17834821wiy.19.1328189992657;
	Thu, 02 Feb 2012 05:39:52 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 98c4670598600f62df864840a0cffb96ad9553f2
Message-Id: <98c4670598600f62df86.1328189200@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 29 RFC] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 98c4670598600f62df864840a0cffb96ad9553f2
# Parent  70e65c85e4c0af5be0d309ce7e5eec2a170cfcf7
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices (with backend PHY or TAP) to initialize
(switch to state 2). This is necessary because we need to call the
hotplug scripts when state is 2, otherwise the execution fails. Make
use of the newly introduced function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 70e65c85e4c0 -r 98c467059860 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
@@ -1002,6 +1002,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1106,6 +1108,27 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        be_path = libxl__device_backend_path(gc, &device);
+        state_path = libxl__sprintf(gc, "%s/state", be_path);
+        state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+        if (atoi(state) != XenbusStateInitWait) {
+            xs_watch(ctx->xsh, state_path, be_path);
+            tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+            tv.tv_usec = 0;
+            rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait,
+                                              NULL);
+            xs_unwatch(ctx->xsh, state_path, be_path);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unable to initialize disk device: %s",
+                           disk->pdev_path);
+                goto out_free;
+            }
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1481,6 +1504,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1555,8 +1580,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswtL-00045b-0D; Thu, 02 Feb 2012 13:39:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtK-000459-1K
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328189921!55100967!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19313 invoked from network); 2 Feb 2012 13:39:02 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:02 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr13so2335049wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=02sX51wyDPkZmo8oSxgSTlLCW/oMhmqn4YqGysOkljQ=;
	b=HG69u7RmuOFRGzbOHu5qOkG21y9fX6sq74zXA+h9YM4uWU5T4yr/ft8eLd8PSS62Pj
	vxKWyDfhTu9ODmOW+Qy/ZyIgJH9jDbOfwDmJhFxfeZ8vRnJcnoyqlfOjzlPi4bSbQOGS
	6HB47lOCw4iP5kjkSTvO6LeF8Z9+pI3f979Wo=
Received: by 10.180.92.71 with SMTP id ck7mr5996485wib.3.1328189996594;
	Thu, 02 Feb 2012 05:39:56 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2c5bf4967eb769c69de665fc84a4d3c0d87d3440
Message-Id: <2c5bf4967eb769c69de6.1328189201@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:41 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 29 RFC] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 2c5bf4967eb769c69de665fc84a4d3c0d87d3440
# Parent  98c4670598600f62df864840a0cffb96ad9553f2
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state. This patch also
changes the behaviour of xenbackend to pass an action instead of a
state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 98c467059860 -r 2c5bf4967eb7 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
@@ -18,7 +18,7 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xparams=$(xenstore-read "$xpath/params")
 
 if [ -f $xparams ]; then
@@ -27,8 +27,8 @@ else
 	xtype="phy"
 fi
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -46,7 +46,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 98c467059860 -r 2c5bf4967eb7 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 98c467059860 -r 2c5bf4967eb7 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 98c467059860 -r 2c5bf4967eb7 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -149,6 +152,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *p;
 	char buf[80];
@@ -297,11 +301,13 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action);
 			break;
 
 		default:

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswtL-00045b-0D; Thu, 02 Feb 2012 13:39:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtK-000459-1K
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:39:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328189921!55100967!3
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19313 invoked from network); 2 Feb 2012 13:39:02 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:02 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr13so2335049wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:39:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=02sX51wyDPkZmo8oSxgSTlLCW/oMhmqn4YqGysOkljQ=;
	b=HG69u7RmuOFRGzbOHu5qOkG21y9fX6sq74zXA+h9YM4uWU5T4yr/ft8eLd8PSS62Pj
	vxKWyDfhTu9ODmOW+Qy/ZyIgJH9jDbOfwDmJhFxfeZ8vRnJcnoyqlfOjzlPi4bSbQOGS
	6HB47lOCw4iP5kjkSTvO6LeF8Z9+pI3f979Wo=
Received: by 10.180.92.71 with SMTP id ck7mr5996485wib.3.1328189996594;
	Thu, 02 Feb 2012 05:39:56 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2c5bf4967eb769c69de665fc84a4d3c0d87d3440
Message-Id: <2c5bf4967eb769c69de6.1328189201@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:41 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 29 RFC] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 2c5bf4967eb769c69de665fc84a4d3c0d87d3440
# Parent  98c4670598600f62df864840a0cffb96ad9553f2
hotplug NetBSD: pass an action instead of a state to hotplug scripts

change second parameter of NetBSD hotplug scripts to take an action
(CONNECT/DISCONNECT) instead of a xenbus state. This patch also
changes the behaviour of xenbackend to pass an action instead of a
state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 98c467059860 -r 2c5bf4967eb7 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
@@ -18,7 +18,7 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xparams=$(xenstore-read "$xpath/params")
 
 if [ -f $xparams ]; then
@@ -27,8 +27,8 @@ else
 	xtype="phy"
 fi
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -46,7 +46,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 98c467059860 -r 2c5bf4967eb7 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 98c467059860 -r 2c5bf4967eb7 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 98c467059860 -r 2c5bf4967eb7 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -149,6 +152,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *p;
 	char buf[80];
@@ -297,11 +301,13 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action);
 			break;
 
 		default:

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswtQ-00048w-KI; Thu, 02 Feb 2012 13:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtO-00047Z-SV
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:03 +0000
Received: from [85.158.138.51:63033] by server-2.bemta-3.messagelabs.com id
	27/F4-15021-1329A2F4; Thu, 02 Feb 2012 13:40:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!3
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18466 invoked from network); 2 Feb 2012 13:40:01 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:01 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=996docU3kfc/gHM8I84Davei0YyRB1Indcx3hFR9I3g=;
	b=sZUfv3bz2GT/fJQdHfz4SMKzkqBB3XckiURsQDZJv10QBnKFEY3Eng+gJKh7/Txn7L
	emo7Jw6L9C4l3jZ/JRZcic7+ZD/WcdLH2sXfAu5GUfkrj0gjD6aFh6NSg8dtfo535NMw
	Beyxq8AMhQ3tKn1l08eLbIdNwhO7ec8EjLPJU=
Received: by 10.180.92.226 with SMTP id cp2mr4646075wib.10.1328190000974;
	Thu, 02 Feb 2012 05:40:00 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b7a3fb7c90a2a08da7348075ba4589d4f2cc19b
Message-Id: <7b7a3fb7c90a2a08da73.1328189202@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 29 RFC] libxl: perform xenstore device
	cleanup from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328176485 -3600
# Node ID 7b7a3fb7c90a2a08da7348075ba4589d4f2cc19b
# Parent  2c5bf4967eb769c69de665fc84a4d3c0d87d3440
libxl: perform xenstore device cleanup from libxl

Perform cleanup of xenstore device entries in libxl, instead of
relying on xen-hotplug-cleanup script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2c5bf4967eb7 -r 7b7a3fb7c90a tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 10:54:45 2012 +0100
@@ -406,6 +406,28 @@ start:
     return rc;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
+
 /*
  * Handler function for device destruction to be passed to
  * libxl__wait_for_device_state
@@ -413,14 +435,26 @@ start:
 static int destroy_device(libxl__gc *gc, char **l1, char *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__device dev;
+    int rc = -1;
 
     xs_unwatch(ctx->xsh, l1[0], l1[1]);
-    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+
+    rc = libxl__parse_backend_path(gc, l1[0], &dev);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to generate device from backend path %s",
+                   l1[0]);
+        goto out;
+    }
+
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, &dev));
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                "Destroyed device backend at %s",
                l1[XS_WATCH_TOKEN]);
-
-    return 0;
+    rc = 0;
+out:
+    return rc;
 }
 
 /*
@@ -446,7 +480,7 @@ retry_transaction:
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
+        libxl__xs_path_cleanup(gc, be_path);
         goto out;
     }
 
@@ -483,12 +517,11 @@ out:
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswtQ-00048w-KI; Thu, 02 Feb 2012 13:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtO-00047Z-SV
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:03 +0000
Received: from [85.158.138.51:63033] by server-2.bemta-3.messagelabs.com id
	27/F4-15021-1329A2F4; Thu, 02 Feb 2012 13:40:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!3
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18466 invoked from network); 2 Feb 2012 13:40:01 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:01 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=996docU3kfc/gHM8I84Davei0YyRB1Indcx3hFR9I3g=;
	b=sZUfv3bz2GT/fJQdHfz4SMKzkqBB3XckiURsQDZJv10QBnKFEY3Eng+gJKh7/Txn7L
	emo7Jw6L9C4l3jZ/JRZcic7+ZD/WcdLH2sXfAu5GUfkrj0gjD6aFh6NSg8dtfo535NMw
	Beyxq8AMhQ3tKn1l08eLbIdNwhO7ec8EjLPJU=
Received: by 10.180.92.226 with SMTP id cp2mr4646075wib.10.1328190000974;
	Thu, 02 Feb 2012 05:40:00 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.39.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:39:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b7a3fb7c90a2a08da7348075ba4589d4f2cc19b
Message-Id: <7b7a3fb7c90a2a08da73.1328189202@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 29 RFC] libxl: perform xenstore device
	cleanup from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328176485 -3600
# Node ID 7b7a3fb7c90a2a08da7348075ba4589d4f2cc19b
# Parent  2c5bf4967eb769c69de665fc84a4d3c0d87d3440
libxl: perform xenstore device cleanup from libxl

Perform cleanup of xenstore device entries in libxl, instead of
relying on xen-hotplug-cleanup script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2c5bf4967eb7 -r 7b7a3fb7c90a tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 10:54:45 2012 +0100
@@ -406,6 +406,28 @@ start:
     return rc;
 }
 
+static int libxl__xs_path_cleanup(libxl__gc *gc, char *path)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
+
 /*
  * Handler function for device destruction to be passed to
  * libxl__wait_for_device_state
@@ -413,14 +435,26 @@ start:
 static int destroy_device(libxl__gc *gc, char **l1, char *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__device dev;
+    int rc = -1;
 
     xs_unwatch(ctx->xsh, l1[0], l1[1]);
-    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+
+    rc = libxl__parse_backend_path(gc, l1[0], &dev);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to generate device from backend path %s",
+                   l1[0]);
+        goto out;
+    }
+
+    libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, &dev));
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                "Destroyed device backend at %s",
                l1[XS_WATCH_TOKEN]);
-
-    return 0;
+    rc = 0;
+out:
+    return rc;
 }
 
 /*
@@ -446,7 +480,7 @@ retry_transaction:
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
+        libxl__xs_path_cleanup(gc, be_path);
         goto out;
     }
 
@@ -483,12 +517,11 @@ out:
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
-    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    libxl__xs_path_cleanup(gc, be_path);
+    libxl__xs_path_cleanup(gc, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswtV-0004CG-21; Thu, 02 Feb 2012 13:40:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtT-0004Ar-NH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:07 +0000
Received: from [85.158.138.51:24114] by server-12.bemta-3.messagelabs.com id
	D8/CB-21103-6329A2F4; Thu, 02 Feb 2012 13:40:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!4
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19119 invoked from network); 2 Feb 2012 13:40:06 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:06 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=6bHsYSPpdDgbIBpYv+NHU8xFCSfpiD58RT5Lxvm3A0E=;
	b=n5DjfNwt3TxkmUUMJYNM27qSSAEBl/NXQanOG1KiirA8cYBwB7mwfiCUQK7KpfHqBi
	0lktvH2HmE/0NOY+fi3lRn+ZNMVHDofXj7BdQvZ6Eklgj1cABR2YBZV0lyyzML/acZ2o
	Bqqpr6l+fMLIWHIlFgDZPw0EdTlIQZi+bTv7o=
Received: by 10.180.95.1 with SMTP id dg1mr4591538wib.21.1328190006040;
	Thu, 02 Feb 2012 05:40:06 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1efb9ee82433896e5a68f9a510f1f5542f071bd3
Message-Id: <1efb9ee82433896e5a68.1328189203@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:43 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 29 RFC] libxl: remove force parameter from
 libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328176666 -3600
# Node ID 1efb9ee82433896e5a68f9a510f1f5542f071bd3
# Parent  7b7a3fb7c90a2a08da7348075ba4589d4f2cc19b
libxl: remove force parameter from libxl__device_remove

All callers where using the wait parameter from
libxl__device_remove, so it's safe to simplify the logic of the
function and assume that the callers always want libxl__device_remove
to wait for the unplug of the device.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7b7a3fb7c90a -r 1efb9ee82433 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 10:54:45 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 10:57:46 2012 +0100
@@ -1149,7 +1149,7 @@ int libxl_device_disk_remove(libxl_ctx *
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1617,7 +1617,7 @@ int libxl_device_nic_remove(libxl_ctx *c
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1957,7 +1957,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -2074,7 +2074,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
diff -r 7b7a3fb7c90a -r 1efb9ee82433 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 10:54:45 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 10:57:46 2012 +0100
@@ -461,13 +461,14 @@ out:
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__device_remove(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state;
+    struct timeval tv;
     int rc = 0;
 
 retry_transaction:
@@ -498,18 +499,13 @@ retry_transaction:
     xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+    tv.tv_usec = 0;
+    rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                      destroy_device);
+    if (rc < 0) /* an error or timeout occurred, clear watches */
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:
     return rc;
diff -r 7b7a3fb7c90a -r 1efb9ee82433 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 10:54:45 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 10:57:46 2012 +0100
@@ -303,7 +303,7 @@ typedef struct {
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
+_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswtV-0004CG-21; Thu, 02 Feb 2012 13:40:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswtT-0004Ar-NH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:07 +0000
Received: from [85.158.138.51:24114] by server-12.bemta-3.messagelabs.com id
	D8/CB-21103-6329A2F4; Thu, 02 Feb 2012 13:40:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!4
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19119 invoked from network); 2 Feb 2012 13:40:06 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:06 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=6bHsYSPpdDgbIBpYv+NHU8xFCSfpiD58RT5Lxvm3A0E=;
	b=n5DjfNwt3TxkmUUMJYNM27qSSAEBl/NXQanOG1KiirA8cYBwB7mwfiCUQK7KpfHqBi
	0lktvH2HmE/0NOY+fi3lRn+ZNMVHDofXj7BdQvZ6Eklgj1cABR2YBZV0lyyzML/acZ2o
	Bqqpr6l+fMLIWHIlFgDZPw0EdTlIQZi+bTv7o=
Received: by 10.180.95.1 with SMTP id dg1mr4591538wib.21.1328190006040;
	Thu, 02 Feb 2012 05:40:06 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1efb9ee82433896e5a68f9a510f1f5542f071bd3
Message-Id: <1efb9ee82433896e5a68.1328189203@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:43 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 29 RFC] libxl: remove force parameter from
 libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328176666 -3600
# Node ID 1efb9ee82433896e5a68f9a510f1f5542f071bd3
# Parent  7b7a3fb7c90a2a08da7348075ba4589d4f2cc19b
libxl: remove force parameter from libxl__device_remove

All callers where using the wait parameter from
libxl__device_remove, so it's safe to simplify the logic of the
function and assume that the callers always want libxl__device_remove
to wait for the unplug of the device.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 7b7a3fb7c90a -r 1efb9ee82433 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 10:54:45 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 10:57:46 2012 +0100
@@ -1149,7 +1149,7 @@ int libxl_device_disk_remove(libxl_ctx *
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1617,7 +1617,7 @@ int libxl_device_nic_remove(libxl_ctx *c
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1957,7 +1957,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -2074,7 +2074,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
diff -r 7b7a3fb7c90a -r 1efb9ee82433 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 10:54:45 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 10:57:46 2012 +0100
@@ -461,13 +461,14 @@ out:
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__device_remove(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state;
+    struct timeval tv;
     int rc = 0;
 
 retry_transaction:
@@ -498,18 +499,13 @@ retry_transaction:
     xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+    tv.tv_usec = 0;
+    rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                      destroy_device);
+    if (rc < 0) /* an error or timeout occurred, clear watches */
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:
     return rc;
diff -r 7b7a3fb7c90a -r 1efb9ee82433 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 10:54:45 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 10:57:46 2012 +0100
@@ -303,7 +303,7 @@ typedef struct {
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
+_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswtb-0004G8-Eo; Thu, 02 Feb 2012 13:40:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswta-0004Er-3l
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:14 +0000
Received: from [85.158.138.51:24969] by server-4.bemta-3.messagelabs.com id
	A5/8E-07654-D329A2F4; Thu, 02 Feb 2012 13:40:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!5
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20273 invoked from network); 2 Feb 2012 13:40:12 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:12 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=gyUUcrZsfNadZ2mPM1gvmD/ycraBPBkdB4+ymbw++uU=;
	b=BcDspMwAR4wsSPNRbH5OUHu+qaGB0a9XNl9KrYceAjU+II7HgHK4Iee72iTMSQ4/eW
	36d9ODx2pgzZDiGOdS8AQ+/Qvs1YgzpF7BomgKbpEb2yigAIfXwna0pvVnqSlVvWdjxk
	lC6X/ut/8aD9w9f5Iyp7xCuwa5qmirhMoVJbU=
Received: by 10.180.80.68 with SMTP id p4mr17834363wix.21.1328190012564;
	Thu, 02 Feb 2012 05:40:12 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 80835b6fed80331703a525a3b6ac98153d9868f6
Message-Id: <80835b6fed80331703a5.1328189205@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:45 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 29 RFC] libxl: destroy devices before
	device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328177046 -3600
# Node ID 80835b6fed80331703a525a3b6ac98153d9868f6
# Parent  8a5a82c9819558015ac75afdef28ee3d88d4f334
libxl: destroy devices before device model

Destroying the device model before unplugging the devices prevented
from doing a clean unplug, since libxl was waiting for dm  devices
to shutdown when the userspace process was already killed.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8a5a82c98195 -r 80835b6fed80 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:01:05 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:04:06 2012 +0100
@@ -791,15 +791,15 @@ int libxl_domain_destroy(libxl_ctx *ctx,
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
+    if (libxl__devices_destroy(gc, domid) < 0)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
     if (dm_present) {
         if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
-                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswtb-0004G8-Eo; Thu, 02 Feb 2012 13:40:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswta-0004Er-3l
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:14 +0000
Received: from [85.158.138.51:24969] by server-4.bemta-3.messagelabs.com id
	A5/8E-07654-D329A2F4; Thu, 02 Feb 2012 13:40:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!5
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20273 invoked from network); 2 Feb 2012 13:40:12 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:12 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=gyUUcrZsfNadZ2mPM1gvmD/ycraBPBkdB4+ymbw++uU=;
	b=BcDspMwAR4wsSPNRbH5OUHu+qaGB0a9XNl9KrYceAjU+II7HgHK4Iee72iTMSQ4/eW
	36d9ODx2pgzZDiGOdS8AQ+/Qvs1YgzpF7BomgKbpEb2yigAIfXwna0pvVnqSlVvWdjxk
	lC6X/ut/8aD9w9f5Iyp7xCuwa5qmirhMoVJbU=
Received: by 10.180.80.68 with SMTP id p4mr17834363wix.21.1328190012564;
	Thu, 02 Feb 2012 05:40:12 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 80835b6fed80331703a525a3b6ac98153d9868f6
Message-Id: <80835b6fed80331703a5.1328189205@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:45 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 29 RFC] libxl: destroy devices before
	device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328177046 -3600
# Node ID 80835b6fed80331703a525a3b6ac98153d9868f6
# Parent  8a5a82c9819558015ac75afdef28ee3d88d4f334
libxl: destroy devices before device model

Destroying the device model before unplugging the devices prevented
from doing a clean unplug, since libxl was waiting for dm  devices
to shutdown when the userspace process was already killed.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8a5a82c98195 -r 80835b6fed80 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:01:05 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:04:06 2012 +0100
@@ -791,15 +791,15 @@ int libxl_domain_destroy(libxl_ctx *ctx,
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
+    if (libxl__devices_destroy(gc, domid) < 0)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
     if (dm_present) {
         if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
-                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswtf-0004JD-8i; Thu, 02 Feb 2012 13:40:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswte-0004Hr-4C
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:18 +0000
Received: from [85.158.138.51:2827] by server-9.bemta-3.messagelabs.com id
	5C/01-21252-1429A2F4; Thu, 02 Feb 2012 13:40:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!6
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20606 invoked from network); 2 Feb 2012 13:40:16 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:16 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=kTwS56tZjIaCd3v+1jq0NI4skue1oq6tT0avKF6iH2o=;
	b=PhuHgMJwyfT+L8lxq3M8jJtn9N2thPvJJTnTVA98RhOo+dnkhsNA0apiX7OpV55YaE
	DHIqZGku3tZrdeG9sN+hf9Be9vpzmr349+szvEOYhzKOw/F6upc0sGOpAwwrJnmeOSML
	4LVr/vCE8zfE3ZH/HX6whR4ES71ICEq7ctQW0=
Received: by 10.180.24.7 with SMTP id q7mr4646021wif.14.1328190016504;
	Thu, 02 Feb 2012 05:40:16 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6c2690921fba580dd7dd836da3be484dee049be0
Message-Id: <6c2690921fba580dd7dd.1328189207@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:47 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 29 RFC] libxl: add hotplug script calling
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328177424 -3600
# Node ID 6c2690921fba580dd7dd836da3be484dee049be0
# Parent  5e488e0c02b8c769e94c2f734c0c209739d9cb01
libxl: add hotplug script calling for NetBSD

Hotplug scripts in NetBSD are in charge of adding the virtual DomU
network interface to the desired bridge and also mount the vnd device
to use virtual images as block devices. The following scripts are
currently implemented:

 * block: executed when a vbd is used, is in charge mounting the
   virtual image to the vnd device and setting the state of xenstore
   to 4 (connected). When using a physical partition, the script only
   sets the state to 4.

 * vif-bridge: adds the virtual DomU interface to the desired bridge.

 * vif-ip: configures the physical network interface assigned to the
   DomU.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5e488e0c02b8 -r 6c2690921fba tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_netbsd.c	Thu Feb 02 11:10:24 2012 +0100
@@ -30,5 +30,50 @@ int libxl__try_phy_backend(mode_t st_mod
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
-    return 0;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    if (dev->backend_kind != LIBXL__DEVICE_KIND_VIF &&
+        dev->backend_kind != LIBXL__DEVICE_KIND_VBD)
+        return 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, NULL, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
 }

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswtf-0004JD-8i; Thu, 02 Feb 2012 13:40:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswte-0004Hr-4C
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:18 +0000
Received: from [85.158.138.51:2827] by server-9.bemta-3.messagelabs.com id
	5C/01-21252-1429A2F4; Thu, 02 Feb 2012 13:40:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!6
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20606 invoked from network); 2 Feb 2012 13:40:16 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:16 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=kTwS56tZjIaCd3v+1jq0NI4skue1oq6tT0avKF6iH2o=;
	b=PhuHgMJwyfT+L8lxq3M8jJtn9N2thPvJJTnTVA98RhOo+dnkhsNA0apiX7OpV55YaE
	DHIqZGku3tZrdeG9sN+hf9Be9vpzmr349+szvEOYhzKOw/F6upc0sGOpAwwrJnmeOSML
	4LVr/vCE8zfE3ZH/HX6whR4ES71ICEq7ctQW0=
Received: by 10.180.24.7 with SMTP id q7mr4646021wif.14.1328190016504;
	Thu, 02 Feb 2012 05:40:16 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6c2690921fba580dd7dd836da3be484dee049be0
Message-Id: <6c2690921fba580dd7dd.1328189207@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:47 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 29 RFC] libxl: add hotplug script calling
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328177424 -3600
# Node ID 6c2690921fba580dd7dd836da3be484dee049be0
# Parent  5e488e0c02b8c769e94c2f734c0c209739d9cb01
libxl: add hotplug script calling for NetBSD

Hotplug scripts in NetBSD are in charge of adding the virtual DomU
network interface to the desired bridge and also mount the vnd device
to use virtual images as block devices. The following scripts are
currently implemented:

 * block: executed when a vbd is used, is in charge mounting the
   virtual image to the vnd device and setting the state of xenstore
   to 4 (connected). When using a physical partition, the script only
   sets the state to 4.

 * vif-bridge: adds the virtual DomU interface to the desired bridge.

 * vif-ip: configures the physical network interface assigned to the
   DomU.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5e488e0c02b8 -r 6c2690921fba tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_netbsd.c	Thu Feb 02 11:10:24 2012 +0100
@@ -30,5 +30,50 @@ int libxl__try_phy_backend(mode_t st_mod
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
-    return 0;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    if (dev->backend_kind != LIBXL__DEVICE_KIND_VIF &&
+        dev->backend_kind != LIBXL__DEVICE_KIND_VBD)
+        return 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, NULL, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
 }

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rswte-0004Ip-Rk; Thu, 02 Feb 2012 13:40:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtc-0004Gv-VI
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:17 +0000
Received: from [85.158.138.51:25190] by server-5.bemta-3.messagelabs.com id
	64/98-25695-0429A2F4; Thu, 02 Feb 2012 13:40:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11997 invoked from network); 2 Feb 2012 13:40:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:15 -0000
Received: by werb14 with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=qgebtn8O6KmdnIAK/Fbkm6omiZuHY08/NNjskaFoN78=;
	b=t8PpSedaonxTushBr+mbswhx4rTIA46I8N9AgjnahfTTfzRd3MFd8U13P8JmxMmOsM
	4dU85Bee+BWjEw8agA9BLgNhrFOw4rQ+rjFg0R1B367Da3ogbwh9htl8d3k6BEOTCNF1
	F4v4yqOb1NxeapjXUtNAdrdJwilX5VoRcyprY=
Received: by 10.216.132.148 with SMTP id o20mr4591429wei.33.1328190014507;
	Thu, 02 Feb 2012 05:40:14 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5e488e0c02b8c769e94c2f734c0c209739d9cb01
Message-Id: <5e488e0c02b8c769e94c.1328189206@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:46 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 29 RFC] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 5e488e0c02b8c769e94c2f734c0c209739d9cb01
# Parent  80835b6fed80331703a525a3b6ac98153d9868f6
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. This
patch adds the necessary functions to call hotplug scripts, but the
implementation of those functions is left empty and will be filled in
future patches.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1049,6 +1049,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1061,6 +1066,10 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
 
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
@@ -1129,6 +1138,16 @@ int libxl_device_disk_add(libxl_ctx *ctx
             }
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for disk: %s",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1597,6 +1616,16 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -448,10 +448,15 @@ static int destroy_device(libxl__gc *gc,
         goto out;
     }
 
+    rc = libxl__device_hotplug(gc, &dev, DISCONNECT);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to execute hotplug script for "
+                   "device with backend path %s", l1[0]);
+        goto out;
+    }
+
     libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, &dev));
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-               "Destroyed device backend at %s",
-               l1[XS_WATCH_TOKEN]);
     rc = 0;
 out:
     return rc;
@@ -480,6 +485,12 @@ retry_transaction:
     }
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
+        rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+        if (rc < 0) {
+             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                        "failed to execute hotplug script for "
+                        "device with backend path %s", be_path);
+        }
         libxl__device_destroy_tapdisk(gc, be_path);
         libxl__xs_path_cleanup(gc, be_path);
         goto out;
@@ -524,13 +535,16 @@ int libxl__device_destroy(libxl__gc *gc,
 {
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    int rc;
 
+    libxl__xs_path_cleanup(gc, fe_path);
+    /* Wait for backend status to disconnect */
+    rc = libxl__device_remove(gc, dev);
     libxl__xs_path_cleanup(gc, be_path);
-    libxl__xs_path_cleanup(gc, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    return 0;
+    return rc;
 }
 
 int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -342,6 +342,25 @@ typedef int libxl__device_state_handler(
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -24,3 +24,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts call function */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rswte-0004Ip-Rk; Thu, 02 Feb 2012 13:40:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtc-0004Gv-VI
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:17 +0000
Received: from [85.158.138.51:25190] by server-5.bemta-3.messagelabs.com id
	64/98-25695-0429A2F4; Thu, 02 Feb 2012 13:40:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11997 invoked from network); 2 Feb 2012 13:40:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:15 -0000
Received: by werb14 with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=qgebtn8O6KmdnIAK/Fbkm6omiZuHY08/NNjskaFoN78=;
	b=t8PpSedaonxTushBr+mbswhx4rTIA46I8N9AgjnahfTTfzRd3MFd8U13P8JmxMmOsM
	4dU85Bee+BWjEw8agA9BLgNhrFOw4rQ+rjFg0R1B367Da3ogbwh9htl8d3k6BEOTCNF1
	F4v4yqOb1NxeapjXUtNAdrdJwilX5VoRcyprY=
Received: by 10.216.132.148 with SMTP id o20mr4591429wei.33.1328190014507;
	Thu, 02 Feb 2012 05:40:14 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5e488e0c02b8c769e94c2f734c0c209739d9cb01
Message-Id: <5e488e0c02b8c769e94c.1328189206@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:46 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 29 RFC] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 5e488e0c02b8c769e94c2f734c0c209739d9cb01
# Parent  80835b6fed80331703a525a3b6ac98153d9868f6
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. This
patch adds the necessary functions to call hotplug scripts, but the
implementation of those functions is left empty and will be filled in
future patches.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1049,6 +1049,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1061,6 +1066,10 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
 
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
@@ -1129,6 +1138,16 @@ int libxl_device_disk_add(libxl_ctx *ctx
             }
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for disk: %s",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1597,6 +1616,16 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -448,10 +448,15 @@ static int destroy_device(libxl__gc *gc,
         goto out;
     }
 
+    rc = libxl__device_hotplug(gc, &dev, DISCONNECT);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to execute hotplug script for "
+                   "device with backend path %s", l1[0]);
+        goto out;
+    }
+
     libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, &dev));
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-               "Destroyed device backend at %s",
-               l1[XS_WATCH_TOKEN]);
     rc = 0;
 out:
     return rc;
@@ -480,6 +485,12 @@ retry_transaction:
     }
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
+        rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+        if (rc < 0) {
+             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                        "failed to execute hotplug script for "
+                        "device with backend path %s", be_path);
+        }
         libxl__device_destroy_tapdisk(gc, be_path);
         libxl__xs_path_cleanup(gc, be_path);
         goto out;
@@ -524,13 +535,16 @@ int libxl__device_destroy(libxl__gc *gc,
 {
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
+    int rc;
 
+    libxl__xs_path_cleanup(gc, fe_path);
+    /* Wait for backend status to disconnect */
+    rc = libxl__device_remove(gc, dev);
     libxl__xs_path_cleanup(gc, be_path);
-    libxl__xs_path_cleanup(gc, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    return 0;
+    return rc;
 }
 
 int libxl__devices_destroy(libxl__gc *gc, uint32_t domid)
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -342,6 +342,25 @@ typedef int libxl__device_state_handler(
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+
+/* Action to pass to hotplug caller functions */
+typedef enum {
+    CONNECT = 1,
+    DISCONNECT = 2
+} libxl__hotplug_action;
+
+/*
+ * libxl__device_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ * action: action to execute
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                                  libxl__hotplug_action action);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r 80835b6fed80 -r 5e488e0c02b8 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Thu Feb 02 11:04:06 2012 +0100
+++ b/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -24,3 +24,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts call function */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswth-0004LV-Sz; Thu, 02 Feb 2012 13:40:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtg-0004Jt-IX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:20 +0000
Received: from [85.158.138.51:25521] by server-7.bemta-3.messagelabs.com id
	6D/B2-28646-3429A2F4; Thu, 02 Feb 2012 13:40:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!7
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20817 invoked from network); 2 Feb 2012 13:40:18 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:18 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=e21pjXFa5Aq3A3ndpm0YGwK/WkkR8/z9N3TFl2AMZvw=;
	b=mV8c7TXz5TQm46QhtiU70H63tjTs++BPS+8x5pWK3+o1GbxCj4tjvdxuqZQFPKO1Nk
	VOeWeM6aA2JfwZzVEyW0Hrw2Noi8DvTHWs6oFpaIjDuXYGdd7dq6RtNikL7RaKAuX+N/
	zwfCBTLAfnRQ9shNnQzmgQgyIz/4quyHZsV0I=
Received: by 10.180.95.105 with SMTP id dj9mr4584640wib.18.1328190018709;
	Thu, 02 Feb 2012 05:40:18 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 98a4f01033786a2fc15b4130897c35f64a676e40
Message-Id: <98a4f01033786a2fc15b.1328189208@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:48 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 29 RFC] libxl: add hotplug script calls
	for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328177591 -3600
# Node ID 98a4f01033786a2fc15b4130897c35f64a676e40
# Parent  6c2690921fba580dd7dd836da3be484dee049be0
libxl: add hotplug script calls for Linux

This patchs adds the necessary logic to call hotplug scripts directly
from libxl. Linux hotplug scritps read most parameters from the caller
environment (since udev set this parameters automatically). In this
implementation we fake udev parameters, so no changes are needed to
the scripts itself.

Currently, the following scripts are called:

 * block: used when disk backend is PHY.

 * blktap: used when disk backend is TAP.

 * vif-*: used when adding a network interface and can be manually set
   by the user.

udev rules descrive more device types, currently the following scripts
are NOT executed from libxl because I wasn't able to find any support
for this device types in libxl:

 * vtpm

 * vif2

 * vscsi

 * vif-setup with devices of type tap*

This patch just adds the necessary code, but hotplug scripts are NOT
called from libxl yet, following patches will disable udev rules and
use this calls instead.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6c2690921fba -r 98a4f0103378 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Feb 02 11:10:24 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Thu Feb 02 11:13:11 2012 +0100
@@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod
     return 1;
 }
 
+/* Hotplug scripts helpers */
+#if 0
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    flexarray_t *f_env;
+    int nr = 0;
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
+                               libxl__sprintf(gc, "%s/%s",
+                                              be_path,
+                                              "script")));
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        flexarray_set(f_env, nr++, "vif");
+        flexarray_set(f_env, nr++,
+                      libxl__sprintf(gc, "%s%u.%d",
+                      libxl__device_kind_to_string(dev->backend_kind),
+                      dev->domid, dev->devid));
+    }
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
 /* Hotplug scripts caller functions */
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
+    flexarray_set(f_args, nr++, "type_if=vif");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+#endif /* 0 */
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
-    return 0;
+    int rc = 0;
+#if 0
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+#endif /* 0 */
+    return rc;
 }

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswth-0004LV-Sz; Thu, 02 Feb 2012 13:40:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtg-0004Jt-IX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:20 +0000
Received: from [85.158.138.51:25521] by server-7.bemta-3.messagelabs.com id
	6D/B2-28646-3429A2F4; Thu, 02 Feb 2012 13:40:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!7
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20817 invoked from network); 2 Feb 2012 13:40:18 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:18 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=e21pjXFa5Aq3A3ndpm0YGwK/WkkR8/z9N3TFl2AMZvw=;
	b=mV8c7TXz5TQm46QhtiU70H63tjTs++BPS+8x5pWK3+o1GbxCj4tjvdxuqZQFPKO1Nk
	VOeWeM6aA2JfwZzVEyW0Hrw2Noi8DvTHWs6oFpaIjDuXYGdd7dq6RtNikL7RaKAuX+N/
	zwfCBTLAfnRQ9shNnQzmgQgyIz/4quyHZsV0I=
Received: by 10.180.95.105 with SMTP id dj9mr4584640wib.18.1328190018709;
	Thu, 02 Feb 2012 05:40:18 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 98a4f01033786a2fc15b4130897c35f64a676e40
Message-Id: <98a4f01033786a2fc15b.1328189208@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:48 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 29 RFC] libxl: add hotplug script calls
	for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328177591 -3600
# Node ID 98a4f01033786a2fc15b4130897c35f64a676e40
# Parent  6c2690921fba580dd7dd836da3be484dee049be0
libxl: add hotplug script calls for Linux

This patchs adds the necessary logic to call hotplug scripts directly
from libxl. Linux hotplug scritps read most parameters from the caller
environment (since udev set this parameters automatically). In this
implementation we fake udev parameters, so no changes are needed to
the scripts itself.

Currently, the following scripts are called:

 * block: used when disk backend is PHY.

 * blktap: used when disk backend is TAP.

 * vif-*: used when adding a network interface and can be manually set
   by the user.

udev rules descrive more device types, currently the following scripts
are NOT executed from libxl because I wasn't able to find any support
for this device types in libxl:

 * vtpm

 * vif2

 * vscsi

 * vif-setup with devices of type tap*

This patch just adds the necessary code, but hotplug scripts are NOT
called from libxl yet, following patches will disable udev rules and
use this calls instead.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6c2690921fba -r 98a4f0103378 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Feb 02 11:10:24 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Thu Feb 02 11:13:11 2012 +0100
@@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod
     return 1;
 }
 
+/* Hotplug scripts helpers */
+#if 0
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    flexarray_t *f_env;
+    int nr = 0;
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
+                               libxl__sprintf(gc, "%s/%s",
+                                              be_path,
+                                              "script")));
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        flexarray_set(f_env, nr++, "vif");
+        flexarray_set(f_env, nr++,
+                      libxl__sprintf(gc, "%s%u.%d",
+                      libxl__device_kind_to_string(dev->backend_kind),
+                      dev->domid, dev->devid));
+    }
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
 /* Hotplug scripts caller functions */
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
+    flexarray_set(f_args, nr++, "type_if=vif");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+#endif /* 0 */
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
-    return 0;
+    int rc = 0;
+#if 0
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+#endif /* 0 */
+    return rc;
 }

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswtk-0004OA-Br; Thu, 02 Feb 2012 13:40:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswti-0004Lq-PT
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:23 +0000
Received: from [85.158.138.51:25790] by server-1.bemta-3.messagelabs.com id
	91/FE-23590-5429A2F4; Thu, 02 Feb 2012 13:40:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12474 invoked from network); 2 Feb 2012 13:40:20 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:20 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=dnuD9rXB6H+o0bzCK5747ueMP3/+lgzOqDamOvKO2iY=;
	b=vmCEGfFHx+Yw8QZqNzadb1KU14FXqvViHzFn8DZFErXoAt4GaVvYbM2uIuShAd6Qd5
	rO2cBWV2aHp9+CNkOgl+qJ+FUiWQsAub6xXqxv44iri4OeGh/KV7v1akZH5++ZxzF9p5
	WABVDw+FfPoJgMXwKi7viDbKNVmrmxUV4UrOU=
Received: by 10.216.132.4 with SMTP id n4mr4626704wei.19.1328190020834;
	Thu, 02 Feb 2012 05:40:20 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6a7a2cc36fe7cadd7d0a50f6f265b6833a7b4e1f
Message-Id: <6a7a2cc36fe7cadd7d0a.1328189209@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:49 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 29 RFC] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 6a7a2cc36fe7cadd7d0a50f6f265b6833a7b4e1f
# Parent  98a4f01033786a2fc15b4130897c35f64a676e40
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 98a4f0103378 -r 6a7a2cc36fe7 tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r 98a4f0103378 -r 6a7a2cc36fe7 tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Thu Feb 02 11:13:11 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 98a4f0103378 -r 6a7a2cc36fe7 tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Thu Feb 02 11:13:11 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswtk-0004OA-Br; Thu, 02 Feb 2012 13:40:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswti-0004Lq-PT
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:23 +0000
Received: from [85.158.138.51:25790] by server-1.bemta-3.messagelabs.com id
	91/FE-23590-5429A2F4; Thu, 02 Feb 2012 13:40:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12474 invoked from network); 2 Feb 2012 13:40:20 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:20 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=dnuD9rXB6H+o0bzCK5747ueMP3/+lgzOqDamOvKO2iY=;
	b=vmCEGfFHx+Yw8QZqNzadb1KU14FXqvViHzFn8DZFErXoAt4GaVvYbM2uIuShAd6Qd5
	rO2cBWV2aHp9+CNkOgl+qJ+FUiWQsAub6xXqxv44iri4OeGh/KV7v1akZH5++ZxzF9p5
	WABVDw+FfPoJgMXwKi7viDbKNVmrmxUV4UrOU=
Received: by 10.216.132.4 with SMTP id n4mr4626704wei.19.1328190020834;
	Thu, 02 Feb 2012 05:40:20 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6a7a2cc36fe7cadd7d0a50f6f265b6833a7b4e1f
Message-Id: <6a7a2cc36fe7cadd7d0a.1328189209@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:49 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 14 of 29 RFC] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 6a7a2cc36fe7cadd7d0a50f6f265b6833a7b4e1f
# Parent  98a4f01033786a2fc15b4130897c35f64a676e40
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 98a4f0103378 -r 6a7a2cc36fe7 tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r 98a4f0103378 -r 6a7a2cc36fe7 tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Thu Feb 02 11:13:11 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 98a4f0103378 -r 6a7a2cc36fe7 tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Thu Feb 02 11:13:11 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswto-0004SR-PL; Thu, 02 Feb 2012 13:40:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtn-0004QM-7h
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:27 +0000
Received: from [85.158.138.51:3605] by server-6.bemta-3.messagelabs.com id
	09/5C-01423-A429A2F4; Thu, 02 Feb 2012 13:40:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 2 Feb 2012 13:40:25 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:25 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=LGL/jKe2rKSGgDMgqpXEpbIQ7WyDwBHeNsHezdO8gMU=;
	b=VSPMmwPDA9OzItl6+pg5OUSR2EcPOiC1oykqGnJ26RU/faMQ5Gf+r9W1mdoecwbWgh
	cJblk37pkp/Sjs0znuyHD46gogLepq7+vNpT2VPeE4oXp/3NQMQA6+tOtHnrTtCUq3KF
	dYCT/LSmGCh7N7iXLUJbinxWf18FTqiAbbwbs=
Received: by 10.216.131.21 with SMTP id l21mr4571629wei.39.1328190025440;
	Thu, 02 Feb 2012 05:40:25 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 88e1905ef078040a1d943ae08186373e2f4d3857
Message-Id: <88e1905ef078040a1d94.1328189211@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:51 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 16 of 29 RFC] libxl: introduce
	libxl__device_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178086 -3600
# Node ID 88e1905ef078040a1d943ae08186373e2f4d3857
# Parent  a7ef1bfa694bf581310e0242616a480e1c5e61b7
libxl: introduce libxl__device_hotplug_path

Get xenstore hotplug path from a given libxl__device. Used in the same
way as libxl__device_frontend_path or libxl__device_backend_path.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a7ef1bfa694b -r 88e1905ef078 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:21:26 2012 +0100
@@ -40,6 +40,14 @@ char *libxl__device_backend_path(libxl__
                           device->domid, device->devid);
 }
 
+char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device)
+{
+    return libxl__sprintf(gc, "/hotplug/%u/%u/%s/%u", device->backend_domid,
+                          device->domid,
+                          libxl__device_kind_to_string(device->backend_kind),
+                          device->devid);
+}
+
 int libxl__parse_backend_path(libxl__gc *gc,
                               const char *path,
                               libxl__device *dev)
diff -r a7ef1bfa694b -r 88e1905ef078 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:21:26 2012 +0100
@@ -301,6 +301,7 @@ typedef struct {
                              char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswto-0004SR-PL; Thu, 02 Feb 2012 13:40:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtn-0004QM-7h
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:27 +0000
Received: from [85.158.138.51:3605] by server-6.bemta-3.messagelabs.com id
	09/5C-01423-A429A2F4; Thu, 02 Feb 2012 13:40:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 2 Feb 2012 13:40:25 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:25 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=LGL/jKe2rKSGgDMgqpXEpbIQ7WyDwBHeNsHezdO8gMU=;
	b=VSPMmwPDA9OzItl6+pg5OUSR2EcPOiC1oykqGnJ26RU/faMQ5Gf+r9W1mdoecwbWgh
	cJblk37pkp/Sjs0znuyHD46gogLepq7+vNpT2VPeE4oXp/3NQMQA6+tOtHnrTtCUq3KF
	dYCT/LSmGCh7N7iXLUJbinxWf18FTqiAbbwbs=
Received: by 10.216.131.21 with SMTP id l21mr4571629wei.39.1328190025440;
	Thu, 02 Feb 2012 05:40:25 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 88e1905ef078040a1d943ae08186373e2f4d3857
Message-Id: <88e1905ef078040a1d94.1328189211@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:51 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 16 of 29 RFC] libxl: introduce
	libxl__device_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178086 -3600
# Node ID 88e1905ef078040a1d943ae08186373e2f4d3857
# Parent  a7ef1bfa694bf581310e0242616a480e1c5e61b7
libxl: introduce libxl__device_hotplug_path

Get xenstore hotplug path from a given libxl__device. Used in the same
way as libxl__device_frontend_path or libxl__device_backend_path.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a7ef1bfa694b -r 88e1905ef078 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:21:26 2012 +0100
@@ -40,6 +40,14 @@ char *libxl__device_backend_path(libxl__
                           device->domid, device->devid);
 }
 
+char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device)
+{
+    return libxl__sprintf(gc, "/hotplug/%u/%u/%s/%u", device->backend_domid,
+                          device->domid,
+                          libxl__device_kind_to_string(device->backend_kind),
+                          device->devid);
+}
+
 int libxl__parse_backend_path(libxl__gc *gc,
                               const char *path,
                               libxl__device *dev)
diff -r a7ef1bfa694b -r 88e1905ef078 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:21:26 2012 +0100
@@ -301,6 +301,7 @@ typedef struct {
                              char **bents, char **fents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
+_hidden char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rswtq-0004UG-6K; Thu, 02 Feb 2012 13:40:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswto-0004Rr-NH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328189998!58205295!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31348 invoked from network); 2 Feb 2012 13:39:58 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:58 -0000
Received: by wgbdt11 with SMTP id dt11so8379970wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=mTPzIM0/baTvf+Z3MlKLV3nsx1AplbsOPYxY5PAHT0k=;
	b=ipxsGOf7Kkto9W7F7gpwcPHIBVCKqxcZOf/V8jr3zPF+1TUNi1EZHvTKBktlIwBL55
	E5VzYzl7VL2yWqZ5gD6kaA+1ckdN/6WQvUp+mDt72e2bCQN7031yH/0+nsWo5C0W7qqI
	AxAXeCOyMpuRJqcMwXpIgO1Uzgp/2ieRvxtCg=
Received: by 10.180.95.105 with SMTP id dj9mr4585524wib.18.1328190027416;
	Thu, 02 Feb 2012 05:40:27 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6a6e7a195412935609c18bc7d52767f41521875b
Message-Id: <6a6e7a195412935609c1.1328189212@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:52 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 17 of 29 RFC] libxl: add enum with possible
	hotplug state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178267 -3600
# Node ID 6a6e7a195412935609c18bc7d52767f41521875b
# Parent  88e1905ef078040a1d943ae08186373e2f4d3857
libxl: add enum with possible hotplug state

enum describing the possible state of the hotplug device entries in
xenstore.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 88e1905ef078 -r 6a6e7a195412 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:21:26 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:24:27 2012 +0100
@@ -351,6 +351,17 @@ typedef enum {
     DISCONNECT = 2
 } libxl__hotplug_action;
 
+/* Possible hotplug state in xenstore */
+typedef enum {
+    HOTPLUG_DEVICE_ERROR = -1,
+    HOTPLUG_DEVICE_INIT = 0,
+    HOTPLUG_DEVICE_CONNECT = 1,
+    HOTPLUG_DEVICE_CONNECTED = 2,
+    HOTPLUG_DEVICE_DISCONNECT = 3,
+    HOTPLUG_DEVICE_DISCONNECTED = 4,
+    HOTPLUG_DEVICE_FORCE_DISCONNECT = 5,
+} libxl__hotplug_status;
+
 /*
  * libxl__device_hotplug - generic function to execute hotplug scripts
  * gc: allocation pool

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rswtq-0004UG-6K; Thu, 02 Feb 2012 13:40:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswto-0004Rr-NH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328189998!58205295!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31348 invoked from network); 2 Feb 2012 13:39:58 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:58 -0000
Received: by wgbdt11 with SMTP id dt11so8379970wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=mTPzIM0/baTvf+Z3MlKLV3nsx1AplbsOPYxY5PAHT0k=;
	b=ipxsGOf7Kkto9W7F7gpwcPHIBVCKqxcZOf/V8jr3zPF+1TUNi1EZHvTKBktlIwBL55
	E5VzYzl7VL2yWqZ5gD6kaA+1ckdN/6WQvUp+mDt72e2bCQN7031yH/0+nsWo5C0W7qqI
	AxAXeCOyMpuRJqcMwXpIgO1Uzgp/2ieRvxtCg=
Received: by 10.180.95.105 with SMTP id dj9mr4585524wib.18.1328190027416;
	Thu, 02 Feb 2012 05:40:27 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6a6e7a195412935609c18bc7d52767f41521875b
Message-Id: <6a6e7a195412935609c1.1328189212@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:52 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 17 of 29 RFC] libxl: add enum with possible
	hotplug state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178267 -3600
# Node ID 6a6e7a195412935609c18bc7d52767f41521875b
# Parent  88e1905ef078040a1d943ae08186373e2f4d3857
libxl: add enum with possible hotplug state

enum describing the possible state of the hotplug device entries in
xenstore.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 88e1905ef078 -r 6a6e7a195412 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:21:26 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:24:27 2012 +0100
@@ -351,6 +351,17 @@ typedef enum {
     DISCONNECT = 2
 } libxl__hotplug_action;
 
+/* Possible hotplug state in xenstore */
+typedef enum {
+    HOTPLUG_DEVICE_ERROR = -1,
+    HOTPLUG_DEVICE_INIT = 0,
+    HOTPLUG_DEVICE_CONNECT = 1,
+    HOTPLUG_DEVICE_CONNECTED = 2,
+    HOTPLUG_DEVICE_DISCONNECT = 3,
+    HOTPLUG_DEVICE_DISCONNECTED = 4,
+    HOTPLUG_DEVICE_FORCE_DISCONNECT = 5,
+} libxl__hotplug_status;
+
 /*
  * libxl__device_hotplug - generic function to execute hotplug scripts
  * gc: allocation pool

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswts-0004X7-Jr; Thu, 02 Feb 2012 13:40:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtq-0004UQ-Q4
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328189992!50820476!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17048 invoked from network); 2 Feb 2012 13:39:52 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:52 -0000
Received: by wgbdr13 with SMTP id dr13so2336011wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=X2/+Fqu3yKh1btc/qnI7uku6kc5yMEFkQIKkr16yaNM=;
	b=SjW+y9Ai9XyrCuZkcbPBpINCfiWpT4tTTmzvQIzmp+m3/GtyQIvYR/5hCc/abwp4sT
	8hmyHtc7xNX36ZI68IIoCnOQ+F3x2Zb3bEPZkDVTqxLSzoSY6WPx1flw6RSjfRivBW+U
	8lCbwi3M3Li7TaJgfj/z0WkJIM3TNdXowyMBk=
Received: by 10.180.101.101 with SMTP id ff5mr18048345wib.14.1328190029504;
	Thu, 02 Feb 2012 05:40:29 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 94733bc9cc2fbeaa08a660ec90dcd9c5ad924e1b
Message-Id: <94733bc9cc2fbeaa08a6.1328189213@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:53 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 18 of 29 RFC] libxl: introduce
 libxl__device_generic_hotplug_add
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178447 -3600
# Node ID 94733bc9cc2fbeaa08a660ec90dcd9c5ad924e1b
# Parent  6a6e7a195412935609c18bc7d52767f41521875b
libxl: introduce libxl__device_generic_hotplug_add

Add an array of xenstore entries for the given libxl__device to
xenstore.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6a6e7a195412 -r 94733bc9cc2f tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:24:27 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:27:27 2012 +0100
@@ -118,6 +118,42 @@ retry_transaction:
     return 0;
 }
 
+int libxl__device_generic_hotplug_add(libxl__gc *gc, libxl__device *device,
+                                      char **hents)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *hotplug_path;
+    xs_transaction_t t;
+    struct xs_permissions hotplug_perms[2];
+
+    hotplug_path = libxl__device_hotplug_path(gc, device);
+
+    hotplug_perms[0].id = 0;
+    hotplug_perms[0].perms = XS_PERM_NONE;
+    hotplug_perms[1].id = device->backend_domid;
+    hotplug_perms[1].perms = XS_PERM_NONE;
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+
+    if (hents) {
+        xs_rm(ctx->xsh, t, hotplug_path);
+        xs_mkdir(ctx->xsh, t, hotplug_path);
+        xs_set_permissions(ctx->xsh, t, hotplug_path, hotplug_perms,
+                           ARRAY_SIZE(hotplug_perms));
+        libxl__xs_writev(gc, t, hotplug_path, hents);
+    }
+
+    if (!xs_transaction_end(ctx->xsh, t, 0)) {
+        if (errno == EAGAIN)
+            goto retry_transaction;
+        else
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
+    }
+
+    return 0;
+}
+
 typedef struct {
     libxl__gc *gc;
     libxl_device_disk *disk;
diff -r 6a6e7a195412 -r 94733bc9cc2f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:24:27 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:27:27 2012 +0100
@@ -299,6 +299,9 @@ typedef struct {
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents);
+_hidden int libxl__device_generic_hotplug_add(libxl__gc *gc,
+                                              libxl__device *device,
+                                              char **hents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswts-0004X7-Jr; Thu, 02 Feb 2012 13:40:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtq-0004UQ-Q4
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328189992!50820476!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17048 invoked from network); 2 Feb 2012 13:39:52 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:39:52 -0000
Received: by wgbdr13 with SMTP id dr13so2336011wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=X2/+Fqu3yKh1btc/qnI7uku6kc5yMEFkQIKkr16yaNM=;
	b=SjW+y9Ai9XyrCuZkcbPBpINCfiWpT4tTTmzvQIzmp+m3/GtyQIvYR/5hCc/abwp4sT
	8hmyHtc7xNX36ZI68IIoCnOQ+F3x2Zb3bEPZkDVTqxLSzoSY6WPx1flw6RSjfRivBW+U
	8lCbwi3M3Li7TaJgfj/z0WkJIM3TNdXowyMBk=
Received: by 10.180.101.101 with SMTP id ff5mr18048345wib.14.1328190029504;
	Thu, 02 Feb 2012 05:40:29 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 94733bc9cc2fbeaa08a660ec90dcd9c5ad924e1b
Message-Id: <94733bc9cc2fbeaa08a6.1328189213@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:53 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 18 of 29 RFC] libxl: introduce
 libxl__device_generic_hotplug_add
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178447 -3600
# Node ID 94733bc9cc2fbeaa08a660ec90dcd9c5ad924e1b
# Parent  6a6e7a195412935609c18bc7d52767f41521875b
libxl: introduce libxl__device_generic_hotplug_add

Add an array of xenstore entries for the given libxl__device to
xenstore.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6a6e7a195412 -r 94733bc9cc2f tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:24:27 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:27:27 2012 +0100
@@ -118,6 +118,42 @@ retry_transaction:
     return 0;
 }
 
+int libxl__device_generic_hotplug_add(libxl__gc *gc, libxl__device *device,
+                                      char **hents)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *hotplug_path;
+    xs_transaction_t t;
+    struct xs_permissions hotplug_perms[2];
+
+    hotplug_path = libxl__device_hotplug_path(gc, device);
+
+    hotplug_perms[0].id = 0;
+    hotplug_perms[0].perms = XS_PERM_NONE;
+    hotplug_perms[1].id = device->backend_domid;
+    hotplug_perms[1].perms = XS_PERM_NONE;
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+
+    if (hents) {
+        xs_rm(ctx->xsh, t, hotplug_path);
+        xs_mkdir(ctx->xsh, t, hotplug_path);
+        xs_set_permissions(ctx->xsh, t, hotplug_path, hotplug_perms,
+                           ARRAY_SIZE(hotplug_perms));
+        libxl__xs_writev(gc, t, hotplug_path, hents);
+    }
+
+    if (!xs_transaction_end(ctx->xsh, t, 0)) {
+        if (errno == EAGAIN)
+            goto retry_transaction;
+        else
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed");
+    }
+
+    return 0;
+}
+
 typedef struct {
     libxl__gc *gc;
     libxl_device_disk *disk;
diff -r 6a6e7a195412 -r 94733bc9cc2f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:24:27 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:27:27 2012 +0100
@@ -299,6 +299,9 @@ typedef struct {
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents);
+_hidden int libxl__device_generic_hotplug_add(libxl__gc *gc,
+                                              libxl__device *device,
+                                              char **hents);
 _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswtw-0004by-7Q; Thu, 02 Feb 2012 13:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtu-0004YT-45
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:34 +0000
Received: from [85.158.138.51:28732] by server-5.bemta-3.messagelabs.com id
	4C/49-25695-1529A2F4; Thu, 02 Feb 2012 13:40:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!4
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13471 invoked from network); 2 Feb 2012 13:40:32 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:32 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=J5MF0cpbCG8akWUFDaFrEPvmblfAO3PKc7VhHD1Khp4=;
	b=Mxd2XOqA0xkPEm9B3vynnYKxSonpObl4cP/0TeFe7hJMwUHbUfgv6r5ElfR63Vw/R8
	Ubm/Wc7e3gb12UwwkeoGCLWFmgpeamicS9uIww9ZAWtnH/2rbh1MTV18wJOQQItdJjv4
	V8jBfYYVl7BK1GniEMY+xSJ9A9ftitYTkXV9I=
Received: by 10.180.96.161 with SMTP id dt1mr18161572wib.13.1328190032322;
	Thu, 02 Feb 2012 05:40:32 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 937bbe68a1942e22c40aa18c8bb66490aec56945
Message-Id: <937bbe68a1942e22c40a.1328189214@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:54 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 19 of 29 RFC] libxl: add
	libxl__device_hotplug_disconnect
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178627 -3600
# Node ID 937bbe68a1942e22c40aa18c8bb66490aec56945
# Parent  94733bc9cc2fbeaa08a660ec90dcd9c5ad924e1b
libxl: add libxl__device_hotplug_disconnect

Sets the necessary xenstore entries to trigger the unplug of a device,
and waits for the device to react (either by setting the device state
to disconnected or to error).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 94733bc9cc2f -r 937bbe68a194 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:27:27 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:30:27 2012 +0100
@@ -405,7 +405,7 @@ int libxl__device_disk_dev_number(const 
  * or timeout occurred.
  */
 int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
-                                 XenbusState state,
+                                 int state,
                                  libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -413,6 +413,7 @@ int libxl__wait_for_device_state(libxl__
     unsigned int n;
     fd_set rfds;
     char **l1 = NULL;
+    char *entry;
 
 start:
     rc = 1;
@@ -431,6 +432,10 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
+                entry = strrchr(l1[0], '/');
+                if (!entry || strcmp(entry, "/state"))
+                    goto start;
+
                 char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
                 if (!sstate || atoi(sstate) == state) {
@@ -575,6 +580,71 @@ out:
     return rc;
 }
 
+int libxl__device_hotplug_disconnect(libxl__gc *gc, libxl__device *dev,
+                                     libxl__hotplug_status disconnect_param)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    xs_transaction_t t;
+    char *hotplug_path = libxl__device_hotplug_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", hotplug_path);
+    char *state;
+    struct timeval tv;
+    int rc = 0;
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disconnecting device with path %s and "
+                                      "state %s", hotplug_path, state);
+    if (!state) {
+        xs_transaction_end(ctx->xsh, t, 0);
+        goto out;
+    }
+    if (atoi(state) != HOTPLUG_DEVICE_CONNECTED) {
+        xs_transaction_end(ctx->xsh, t, 0);
+        goto out;
+    }
+    libxl__xs_write(gc, t, state_path, "%d", disconnect_param);
+    if (!xs_transaction_end(ctx->xsh, t, 0)) {
+        if (errno == EAGAIN)
+            goto retry_transaction;
+        else {
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    xs_watch(ctx->xsh, state_path, hotplug_path);
+
+    tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+    tv.tv_usec = 0;
+    rc = libxl__wait_for_device_state(gc, &tv, HOTPLUG_DEVICE_DISCONNECTED,
+                                      NULL);
+    xs_unwatch(ctx->xsh, state_path, hotplug_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+    if (!state) {
+        goto out;
+    }
+    if (atoi(state) == HOTPLUG_DEVICE_ERROR) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "Error while unplug of "
+                   "device with hotplug path %s", hotplug_path);
+        rc = ERROR_FAIL;
+    } else if (rc == ERROR_TIMEDOUT) {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Timeout while waiting for unplug of "
+                   "device with hotplug path %s", hotplug_path);
+    } else if (rc == ERROR_FAIL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to destroy device with "
+                   "hotplug path %s", hotplug_path);
+    }
+
+out:
+    libxl__xs_path_cleanup(gc, hotplug_path);
+    return rc;
+}
+
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
     char *be_path = libxl__device_backend_path(gc, dev);
diff -r 94733bc9cc2f -r 937bbe68a194 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:27:27 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:30:27 2012 +0100
@@ -334,7 +334,7 @@ typedef int libxl__device_state_handler(
  * Returns 0 on success, and < 0 on error.
  */
 _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
-                                         XenbusState state,
+                                         int state,
                                          libxl__device_state_handler handler);
 
 /*
@@ -366,6 +366,16 @@ typedef enum {
 } libxl__hotplug_status;
 
 /*
+ * libxl__device_hotplug_disconnect - disconnect remove device
+ * disconnect_param: action to use when disconnecting the device, either
+ * HOTPLUG_DEVICE_DISCONNECT or HOTPLUG_DEVICE_FORCE_DISCONNECT
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_hotplug_disconnect(libxl__gc *gc, libxl__device *dev,
+                                       libxl__hotplug_status disconnect_param);
+
+/*
  * libxl__device_hotplug - generic function to execute hotplug scripts
  * gc: allocation pool
  * dev: reference to the device that executes the hotplug scripts

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswtw-0004by-7Q; Thu, 02 Feb 2012 13:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtu-0004YT-45
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:34 +0000
Received: from [85.158.138.51:28732] by server-5.bemta-3.messagelabs.com id
	4C/49-25695-1529A2F4; Thu, 02 Feb 2012 13:40:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!4
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13471 invoked from network); 2 Feb 2012 13:40:32 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:32 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=J5MF0cpbCG8akWUFDaFrEPvmblfAO3PKc7VhHD1Khp4=;
	b=Mxd2XOqA0xkPEm9B3vynnYKxSonpObl4cP/0TeFe7hJMwUHbUfgv6r5ElfR63Vw/R8
	Ubm/Wc7e3gb12UwwkeoGCLWFmgpeamicS9uIww9ZAWtnH/2rbh1MTV18wJOQQItdJjv4
	V8jBfYYVl7BK1GniEMY+xSJ9A9ftitYTkXV9I=
Received: by 10.180.96.161 with SMTP id dt1mr18161572wib.13.1328190032322;
	Thu, 02 Feb 2012 05:40:32 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 937bbe68a1942e22c40aa18c8bb66490aec56945
Message-Id: <937bbe68a1942e22c40a.1328189214@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:54 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 19 of 29 RFC] libxl: add
	libxl__device_hotplug_disconnect
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178627 -3600
# Node ID 937bbe68a1942e22c40aa18c8bb66490aec56945
# Parent  94733bc9cc2fbeaa08a660ec90dcd9c5ad924e1b
libxl: add libxl__device_hotplug_disconnect

Sets the necessary xenstore entries to trigger the unplug of a device,
and waits for the device to react (either by setting the device state
to disconnected or to error).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 94733bc9cc2f -r 937bbe68a194 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:27:27 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:30:27 2012 +0100
@@ -405,7 +405,7 @@ int libxl__device_disk_dev_number(const 
  * or timeout occurred.
  */
 int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
-                                 XenbusState state,
+                                 int state,
                                  libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -413,6 +413,7 @@ int libxl__wait_for_device_state(libxl__
     unsigned int n;
     fd_set rfds;
     char **l1 = NULL;
+    char *entry;
 
 start:
     rc = 1;
@@ -431,6 +432,10 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
+                entry = strrchr(l1[0], '/');
+                if (!entry || strcmp(entry, "/state"))
+                    goto start;
+
                 char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
                 if (!sstate || atoi(sstate) == state) {
@@ -575,6 +580,71 @@ out:
     return rc;
 }
 
+int libxl__device_hotplug_disconnect(libxl__gc *gc, libxl__device *dev,
+                                     libxl__hotplug_status disconnect_param)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    xs_transaction_t t;
+    char *hotplug_path = libxl__device_hotplug_path(gc, dev);
+    char *state_path = libxl__sprintf(gc, "%s/state", hotplug_path);
+    char *state;
+    struct timeval tv;
+    int rc = 0;
+
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disconnecting device with path %s and "
+                                      "state %s", hotplug_path, state);
+    if (!state) {
+        xs_transaction_end(ctx->xsh, t, 0);
+        goto out;
+    }
+    if (atoi(state) != HOTPLUG_DEVICE_CONNECTED) {
+        xs_transaction_end(ctx->xsh, t, 0);
+        goto out;
+    }
+    libxl__xs_write(gc, t, state_path, "%d", disconnect_param);
+    if (!xs_transaction_end(ctx->xsh, t, 0)) {
+        if (errno == EAGAIN)
+            goto retry_transaction;
+        else {
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    xs_watch(ctx->xsh, state_path, hotplug_path);
+
+    tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+    tv.tv_usec = 0;
+    rc = libxl__wait_for_device_state(gc, &tv, HOTPLUG_DEVICE_DISCONNECTED,
+                                      NULL);
+    xs_unwatch(ctx->xsh, state_path, hotplug_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+    if (!state) {
+        goto out;
+    }
+    if (atoi(state) == HOTPLUG_DEVICE_ERROR) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "Error while unplug of "
+                   "device with hotplug path %s", hotplug_path);
+        rc = ERROR_FAIL;
+    } else if (rc == ERROR_TIMEDOUT) {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Timeout while waiting for unplug of "
+                   "device with hotplug path %s", hotplug_path);
+    } else if (rc == ERROR_FAIL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to destroy device with "
+                   "hotplug path %s", hotplug_path);
+    }
+
+out:
+    libxl__xs_path_cleanup(gc, hotplug_path);
+    return rc;
+}
+
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
 {
     char *be_path = libxl__device_backend_path(gc, dev);
diff -r 94733bc9cc2f -r 937bbe68a194 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:27:27 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:30:27 2012 +0100
@@ -334,7 +334,7 @@ typedef int libxl__device_state_handler(
  * Returns 0 on success, and < 0 on error.
  */
 _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
-                                         XenbusState state,
+                                         int state,
                                          libxl__device_state_handler handler);
 
 /*
@@ -366,6 +366,16 @@ typedef enum {
 } libxl__hotplug_status;
 
 /*
+ * libxl__device_hotplug_disconnect - disconnect remove device
+ * disconnect_param: action to use when disconnecting the device, either
+ * HOTPLUG_DEVICE_DISCONNECT or HOTPLUG_DEVICE_FORCE_DISCONNECT
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_hotplug_disconnect(libxl__gc *gc, libxl__device *dev,
+                                       libxl__hotplug_status disconnect_param);
+
+/*
  * libxl__device_hotplug - generic function to execute hotplug scripts
  * gc: allocation pool
  * dev: reference to the device that executes the hotplug scripts

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswty-0004fm-LP; Thu, 02 Feb 2012 13:40:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtw-0004bU-B6
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:36 +0000
Received: from [85.158.138.51:28916] by server-6.bemta-3.messagelabs.com id
	50/BC-01423-3529A2F4; Thu, 02 Feb 2012 13:40:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!8
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21838 invoked from network); 2 Feb 2012 13:40:34 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:34 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VhqbvMvvz2mvRsXcAlgU9PkMb1BgOZKFcW6CdmlsqUQ=;
	b=lh9CN/zWnpACH2L/+qhMjwvEj3ZlNNhEyVrGInpKTye16nRDz9b4drHDnXXAMSOCwP
	Bm5n++YLvgvq4tFnsxJbvWX/dEQrRb8KzRC5ZpnN2/2lx/USqpdNagDFc1hUt7wCP4/X
	YAVu481//QvLnijtI3wpGpjtq13csCEoX1x1Q=
Received: by 10.180.103.68 with SMTP id fu4mr1516128wib.7.1328190034315;
	Thu, 02 Feb 2012 05:40:34 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bc38aa2e11e21b34dbc29a81f069133a3276848a
Message-Id: <bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:55 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178807 -3600
# Node ID bc38aa2e11e21b34dbc29a81f069133a3276848a
# Parent  937bbe68a1942e22c40aa18c8bb66490aec56945
libxl: introduce libxl hotplug public API functions

These functions mimic the name used by the local device functions,
following the nomenclature:

libxl_device_<type>_hotplug_<action>

They also take the same parameters as they local counterparts (ctx,
domid and libxl_device_<type>). The list of added functions:

libxl_device_disk_hotplug_add
libxl_device_disk_hotplug_remove
libxl_device_disk_hotplug_destroy
libxl_device_nic_hotplug_add
libxl_device_nic_hotplug_remove
libxl_device_nic_hotplug_destroy

The xenstore structure used by vbd disk entries:

/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/pdev_path
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/vdev
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/script
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/removable
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/readwrite
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/is_cdrom
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/state

and vif devices use the following:

/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype

This will allow us to pass the libxl_device_disk and libxl_device_nic
struct from Dom0 to driver domain, and execute the necessary backends
there.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 937bbe68a194 -r bc38aa2e11e2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:30:27 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:33:27 2012 +0100
@@ -996,6 +996,85 @@ static int libxl__device_from_disk(libxl
     return 0;
 }
 
+int libxl_device_disk_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_device_disk *disk)
+{
+    GC_INIT(ctx);
+    flexarray_t *hotplug;
+    libxl__device device;
+    char *h_path, *state_path, *state;
+    struct timeval tv;
+    int rc;
+
+    /* 
+     * Always set backend to PHY and let the driver domain decide the most
+     * suitable backend to use
+     */
+    disk->backend = LIBXL_DISK_BACKEND_PHY;
+
+    hotplug = flexarray_make(14, 1);
+    if (!hotplug) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    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;
+    }
+
+    flexarray_append(hotplug, "pdev_path");
+    flexarray_append(hotplug, libxl__strdup(gc, disk->pdev_path));
+    flexarray_append(hotplug, "vdev");
+    flexarray_append(hotplug, libxl__strdup(gc, disk->vdev));
+    if (disk->script) {
+        flexarray_append(hotplug, "script");
+        flexarray_append(hotplug, libxl__strdup(gc, disk->script));
+    }
+    flexarray_append(hotplug, "removable");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->removable));
+    flexarray_append(hotplug, "readwrite");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->readwrite));
+    flexarray_append(hotplug, "is_cdrom");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->is_cdrom));
+    flexarray_append(hotplug, "format");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->format));
+    flexarray_append(hotplug, "state");
+    flexarray_append(hotplug, "1");
+
+    libxl__device_generic_hotplug_add(gc, &device,
+        libxl__xs_kvs_of_flexarray(gc, hotplug, hotplug->count));
+
+    /* Wait for device init or error */
+    h_path = libxl__device_hotplug_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", h_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != HOTPLUG_DEVICE_CONNECTED) {
+        xs_watch(ctx->xsh, state_path, h_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, HOTPLUG_DEVICE_CONNECTED,
+                                          NULL);
+        xs_unwatch(ctx->xsh, state_path, h_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
+
+    rc = 0;
+out_free:
+    flexarray_free(hotplug);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
@@ -1174,6 +1253,23 @@ out:
     return rc;
 }
 
+int libxl_device_disk_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_disk *disk)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device,
+                                          HOTPLUG_DEVICE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk)
 {
@@ -1190,6 +1286,23 @@ out:
     return rc;
 }
 
+int libxl_device_disk_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                      libxl_device_disk *disk)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device,
+                                          HOTPLUG_DEVICE_FORCE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 static void libxl__device_disk_from_xs_be(libxl__gc *gc,
                                           const char *be_path,
                                           libxl_device_disk *disk)
@@ -1516,6 +1629,85 @@ static int libxl__device_from_nic(libxl_
     return 0;
 }
 
+int libxl_device_nic_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_device_nic *nic)
+{
+    GC_INIT(ctx);
+    flexarray_t *hotplug;
+    libxl__device device;
+    char *h_path, *state_path, *state;
+    struct timeval tv;
+    int rc;
+
+    hotplug = flexarray_make(18, 1);
+    if (!hotplug) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    if (rc != 0)
+        goto out_free;
+
+    flexarray_append(hotplug, "mtu");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", nic->mtu));
+    if (nic->model) {
+        flexarray_append(hotplug, "model");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->model));
+    }
+    flexarray_append(hotplug, "mac");
+    flexarray_append(hotplug, libxl__sprintf(gc,
+                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
+    if (nic->ip) {
+        flexarray_append(hotplug, "ip");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->ip));
+    }
+    flexarray_append(hotplug, "bridge");
+    flexarray_append(hotplug, libxl__strdup(gc, nic->bridge));
+    if (nic->ifname) {
+        flexarray_append(hotplug, "ifname");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->ifname));
+    }
+    if (nic->script) {
+        flexarray_append(hotplug, "script");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->script));
+    }
+    flexarray_append(hotplug, "nictype");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", nic->nictype));
+    flexarray_append(hotplug, "state");
+    flexarray_append(hotplug, "1");
+
+    libxl__device_generic_hotplug_add(gc, &device,
+        libxl__xs_kvs_of_flexarray(gc, hotplug, hotplug->count));
+
+    /* Wait for device init or error */
+    h_path = libxl__device_hotplug_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", h_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != HOTPLUG_DEVICE_CONNECTED) {
+        xs_watch(ctx->xsh, state_path, h_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, HOTPLUG_DEVICE_CONNECTED,
+                                          NULL);
+        xs_unwatch(ctx->xsh, state_path, h_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
+
+    rc = 0;
+out_free:
+    flexarray_free(hotplug);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
 {
     GC_INIT(ctx);
@@ -1652,6 +1844,22 @@ out:
     return rc;
 }
 
+int libxl_device_nic_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                    libxl_device_nic *nic)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device, HOTPLUG_DEVICE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_nic *nic)
 {
@@ -1668,6 +1876,23 @@ out:
     return rc;
 }
 
+int libxl_device_nic_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_nic *nic)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device,
+                                          HOTPLUG_DEVICE_FORCE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 static void libxl__device_nic_from_xs_be(libxl__gc *gc,
                                          const char *be_path,
                                          libxl_device_nic *nic)
diff -r 937bbe68a194 -r bc38aa2e11e2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 11:30:27 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Feb 02 11:33:27 2012 +0100
@@ -416,6 +416,11 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *
  *    Initalises device to a default configuration.
  *
+ * libxl_device_<type>_hotplug_add(ctx, domid, device):
+ *
+ *   Creates the necessary xenstore entries to trigger the execution of
+ *   a device addition, possibly on a different domain.
+ *
  * libxl_device_<type>_add(ctx, domid, device):
  *
  *   Adds the given device to the specified domain. This can be called
@@ -425,6 +430,10 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *   domain to connect to the device and therefore cannot block on the
  *   guest.
  *
+ * libxl_device_<type>_hotplug_remove(ctx, domid, device):
+ *
+ *   Request the removal of the given device and waits for the result.
+ *
  * libxl_device_<type>_remove(ctx, domid, device):
  *
  *   Removes the given device from the specified domain by performing
@@ -442,14 +451,25 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *
  *   This function does not interact with the guest and therefore
  *   cannot block on the guest.
+ *
+ * libxl_device_<type>_hotplug_destroy(ctx, domid, device):
+ *
+ *   Requests de destruction of the given device and waits for the result.
+ *
  */
 
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
+int libxl_device_disk_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_disk *disk);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
+int libxl_device_disk_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                      libxl_device_disk *disk);
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
@@ -470,9 +490,15 @@ int libxl_device_disk_local_detach(libxl
 
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
+int libxl_device_nic_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                 libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                    libxl_device_nic *nic);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswty-0004fm-LP; Thu, 02 Feb 2012 13:40:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtw-0004bU-B6
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:36 +0000
Received: from [85.158.138.51:28916] by server-6.bemta-3.messagelabs.com id
	50/BC-01423-3529A2F4; Thu, 02 Feb 2012 13:40:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!8
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21838 invoked from network); 2 Feb 2012 13:40:34 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:34 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VhqbvMvvz2mvRsXcAlgU9PkMb1BgOZKFcW6CdmlsqUQ=;
	b=lh9CN/zWnpACH2L/+qhMjwvEj3ZlNNhEyVrGInpKTye16nRDz9b4drHDnXXAMSOCwP
	Bm5n++YLvgvq4tFnsxJbvWX/dEQrRb8KzRC5ZpnN2/2lx/USqpdNagDFc1hUt7wCP4/X
	YAVu481//QvLnijtI3wpGpjtq13csCEoX1x1Q=
Received: by 10.180.103.68 with SMTP id fu4mr1516128wib.7.1328190034315;
	Thu, 02 Feb 2012 05:40:34 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bc38aa2e11e21b34dbc29a81f069133a3276848a
Message-Id: <bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:55 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178807 -3600
# Node ID bc38aa2e11e21b34dbc29a81f069133a3276848a
# Parent  937bbe68a1942e22c40aa18c8bb66490aec56945
libxl: introduce libxl hotplug public API functions

These functions mimic the name used by the local device functions,
following the nomenclature:

libxl_device_<type>_hotplug_<action>

They also take the same parameters as they local counterparts (ctx,
domid and libxl_device_<type>). The list of added functions:

libxl_device_disk_hotplug_add
libxl_device_disk_hotplug_remove
libxl_device_disk_hotplug_destroy
libxl_device_nic_hotplug_add
libxl_device_nic_hotplug_remove
libxl_device_nic_hotplug_destroy

The xenstore structure used by vbd disk entries:

/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/pdev_path
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/vdev
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/script
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/removable
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/readwrite
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/is_cdrom
/hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/state

and vif devices use the following:

/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
/hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype

This will allow us to pass the libxl_device_disk and libxl_device_nic
struct from Dom0 to driver domain, and execute the necessary backends
there.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 937bbe68a194 -r bc38aa2e11e2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:30:27 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:33:27 2012 +0100
@@ -996,6 +996,85 @@ static int libxl__device_from_disk(libxl
     return 0;
 }
 
+int libxl_device_disk_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_device_disk *disk)
+{
+    GC_INIT(ctx);
+    flexarray_t *hotplug;
+    libxl__device device;
+    char *h_path, *state_path, *state;
+    struct timeval tv;
+    int rc;
+
+    /* 
+     * Always set backend to PHY and let the driver domain decide the most
+     * suitable backend to use
+     */
+    disk->backend = LIBXL_DISK_BACKEND_PHY;
+
+    hotplug = flexarray_make(14, 1);
+    if (!hotplug) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    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;
+    }
+
+    flexarray_append(hotplug, "pdev_path");
+    flexarray_append(hotplug, libxl__strdup(gc, disk->pdev_path));
+    flexarray_append(hotplug, "vdev");
+    flexarray_append(hotplug, libxl__strdup(gc, disk->vdev));
+    if (disk->script) {
+        flexarray_append(hotplug, "script");
+        flexarray_append(hotplug, libxl__strdup(gc, disk->script));
+    }
+    flexarray_append(hotplug, "removable");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->removable));
+    flexarray_append(hotplug, "readwrite");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->readwrite));
+    flexarray_append(hotplug, "is_cdrom");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->is_cdrom));
+    flexarray_append(hotplug, "format");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", disk->format));
+    flexarray_append(hotplug, "state");
+    flexarray_append(hotplug, "1");
+
+    libxl__device_generic_hotplug_add(gc, &device,
+        libxl__xs_kvs_of_flexarray(gc, hotplug, hotplug->count));
+
+    /* Wait for device init or error */
+    h_path = libxl__device_hotplug_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", h_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != HOTPLUG_DEVICE_CONNECTED) {
+        xs_watch(ctx->xsh, state_path, h_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, HOTPLUG_DEVICE_CONNECTED,
+                                          NULL);
+        xs_unwatch(ctx->xsh, state_path, h_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
+
+    rc = 0;
+out_free:
+    flexarray_free(hotplug);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 {
     GC_INIT(ctx);
@@ -1174,6 +1253,23 @@ out:
     return rc;
 }
 
+int libxl_device_disk_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_disk *disk)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device,
+                                          HOTPLUG_DEVICE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk)
 {
@@ -1190,6 +1286,23 @@ out:
     return rc;
 }
 
+int libxl_device_disk_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                      libxl_device_disk *disk)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_disk(gc, domid, disk, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device,
+                                          HOTPLUG_DEVICE_FORCE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 static void libxl__device_disk_from_xs_be(libxl__gc *gc,
                                           const char *be_path,
                                           libxl_device_disk *disk)
@@ -1516,6 +1629,85 @@ static int libxl__device_from_nic(libxl_
     return 0;
 }
 
+int libxl_device_nic_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_device_nic *nic)
+{
+    GC_INIT(ctx);
+    flexarray_t *hotplug;
+    libxl__device device;
+    char *h_path, *state_path, *state;
+    struct timeval tv;
+    int rc;
+
+    hotplug = flexarray_make(18, 1);
+    if (!hotplug) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    if (rc != 0)
+        goto out_free;
+
+    flexarray_append(hotplug, "mtu");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", nic->mtu));
+    if (nic->model) {
+        flexarray_append(hotplug, "model");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->model));
+    }
+    flexarray_append(hotplug, "mac");
+    flexarray_append(hotplug, libxl__sprintf(gc,
+                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
+    if (nic->ip) {
+        flexarray_append(hotplug, "ip");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->ip));
+    }
+    flexarray_append(hotplug, "bridge");
+    flexarray_append(hotplug, libxl__strdup(gc, nic->bridge));
+    if (nic->ifname) {
+        flexarray_append(hotplug, "ifname");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->ifname));
+    }
+    if (nic->script) {
+        flexarray_append(hotplug, "script");
+        flexarray_append(hotplug, libxl__strdup(gc, nic->script));
+    }
+    flexarray_append(hotplug, "nictype");
+    flexarray_append(hotplug, libxl__sprintf(gc, "%d", nic->nictype));
+    flexarray_append(hotplug, "state");
+    flexarray_append(hotplug, "1");
+
+    libxl__device_generic_hotplug_add(gc, &device,
+        libxl__xs_kvs_of_flexarray(gc, hotplug, hotplug->count));
+
+    /* Wait for device init or error */
+    h_path = libxl__device_hotplug_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", h_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != HOTPLUG_DEVICE_CONNECTED) {
+        xs_watch(ctx->xsh, state_path, h_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, HOTPLUG_DEVICE_CONNECTED,
+                                          NULL);
+        xs_unwatch(ctx->xsh, state_path, h_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
+
+    rc = 0;
+out_free:
+    flexarray_free(hotplug);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic)
 {
     GC_INIT(ctx);
@@ -1652,6 +1844,22 @@ out:
     return rc;
 }
 
+int libxl_device_nic_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                    libxl_device_nic *nic)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device, HOTPLUG_DEVICE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
                                   libxl_device_nic *nic)
 {
@@ -1668,6 +1876,23 @@ out:
     return rc;
 }
 
+int libxl_device_nic_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_nic *nic)
+{
+    GC_INIT(ctx);
+    libxl__device device;
+    int rc;
+
+    rc = libxl__device_from_nic(gc, domid, nic, &device);
+    if (rc != 0) goto out;
+
+    rc = libxl__device_hotplug_disconnect(gc, &device,
+                                          HOTPLUG_DEVICE_FORCE_DISCONNECT);
+out:
+    GC_FREE;
+    return rc;
+}
+
 static void libxl__device_nic_from_xs_be(libxl__gc *gc,
                                          const char *be_path,
                                          libxl_device_nic *nic)
diff -r 937bbe68a194 -r bc38aa2e11e2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 11:30:27 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Feb 02 11:33:27 2012 +0100
@@ -416,6 +416,11 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *
  *    Initalises device to a default configuration.
  *
+ * libxl_device_<type>_hotplug_add(ctx, domid, device):
+ *
+ *   Creates the necessary xenstore entries to trigger the execution of
+ *   a device addition, possibly on a different domain.
+ *
  * libxl_device_<type>_add(ctx, domid, device):
  *
  *   Adds the given device to the specified domain. This can be called
@@ -425,6 +430,10 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *   domain to connect to the device and therefore cannot block on the
  *   guest.
  *
+ * libxl_device_<type>_hotplug_remove(ctx, domid, device):
+ *
+ *   Request the removal of the given device and waits for the result.
+ *
  * libxl_device_<type>_remove(ctx, domid, device):
  *
  *   Removes the given device from the specified domain by performing
@@ -442,14 +451,25 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *
  *   This function does not interact with the guest and therefore
  *   cannot block on the guest.
+ *
+ * libxl_device_<type>_hotplug_destroy(ctx, domid, device):
+ *
+ *   Requests de destruction of the given device and waits for the result.
+ *
  */
 
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
+int libxl_device_disk_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_disk *disk);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
+int libxl_device_disk_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                      libxl_device_disk *disk);
 
 libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
@@ -470,9 +490,15 @@ int libxl_device_disk_local_detach(libxl
 
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
+int libxl_device_nic_hotplug_add(libxl_ctx *ctx, uint32_t domid,
+                                 libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_hotplug_remove(libxl_ctx *ctx, uint32_t domid,
+                                    libxl_device_nic *nic);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_hotplug_destroy(libxl_ctx *ctx, uint32_t domid,
+                                     libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswu1-0004j0-1t; Thu, 02 Feb 2012 13:40:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtz-0004gc-R0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:40 +0000
Received: from [85.158.138.51:4492] by server-7.bemta-3.messagelabs.com id
	CE/73-28646-6529A2F4; Thu, 02 Feb 2012 13:40:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!5
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13711 invoked from network); 2 Feb 2012 13:40:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:37 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=PTS9LjTsXU+HGM3hSUn5+c1JUe0ekeEOx3SM8GlYYtc=;
	b=vIFg56bpPMg6WPNka3Fz/RoBl9VfchU3aRqB2TF5eWnDgQBVopNX2xbSw0djDkE4st
	+vuSFmyfBnPib+tSvVI7IX4JXhdk37MZFPtjWZjV7fc2gg5NkEsR6hhrM5ZXkkfkpUm9
	da0AAQxGwdfKxuRuYta9ObZhdE3TVbam6QUr0=
Received: by 10.216.140.15 with SMTP id d15mr4616520wej.16.1328190037040;
	Thu, 02 Feb 2012 05:40:37 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 346d86654b1dd81b5aba821bf9732844bb35c7a3
Message-Id: <346d86654b1dd81b5aba.1328189216@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:56 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 21 of 29 RFC] libxl: add
	libxl__parse_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178994 -3600
# Node ID 346d86654b1dd81b5aba821bf9732844bb35c7a3
# Parent  bc38aa2e11e21b34dbc29a81f069133a3276848a
libxl: add libxl__parse_hotplug_path

Generate libxl__device from hotplug path.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r bc38aa2e11e2 -r 346d86654b1d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:33:27 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:36:34 2012 +0100
@@ -66,6 +66,24 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__parse_hotplug_path(libxl__gc *gc,
+                              const char *path,
+                              libxl__device *dev)
+{
+    /* /hotplug/<backend_domid>/<frontend_domid>/<kind> */
+    char strkind[16]; /* Longest is actually "console" */
+    int rc = sscanf(path, "/hotplug/%u/%u/%15[^/]/%d",
+                    &dev->backend_domid,
+                    &dev->domid,
+                    strkind,
+                    &dev->devid);
+
+    if (rc != 4)
+        return ERROR_FAIL;
+
+    return libxl__device_kind_from_string(strkind, &dev->backend_kind);
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
diff -r bc38aa2e11e2 -r 346d86654b1d tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:33:27 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:36:34 2012 +0100
@@ -307,6 +307,9 @@ typedef struct {
 _hidden char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
+_hidden int libxl__parse_hotplug_path(libxl__gc *gc,
+                                      const char *path,
+                                      libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswu1-0004j0-1t; Thu, 02 Feb 2012 13:40:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswtz-0004gc-R0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:40 +0000
Received: from [85.158.138.51:4492] by server-7.bemta-3.messagelabs.com id
	CE/73-28646-6529A2F4; Thu, 02 Feb 2012 13:40:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!5
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13711 invoked from network); 2 Feb 2012 13:40:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:37 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=PTS9LjTsXU+HGM3hSUn5+c1JUe0ekeEOx3SM8GlYYtc=;
	b=vIFg56bpPMg6WPNka3Fz/RoBl9VfchU3aRqB2TF5eWnDgQBVopNX2xbSw0djDkE4st
	+vuSFmyfBnPib+tSvVI7IX4JXhdk37MZFPtjWZjV7fc2gg5NkEsR6hhrM5ZXkkfkpUm9
	da0AAQxGwdfKxuRuYta9ObZhdE3TVbam6QUr0=
Received: by 10.216.140.15 with SMTP id d15mr4616520wej.16.1328190037040;
	Thu, 02 Feb 2012 05:40:37 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 346d86654b1dd81b5aba821bf9732844bb35c7a3
Message-Id: <346d86654b1dd81b5aba.1328189216@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:56 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 21 of 29 RFC] libxl: add
	libxl__parse_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328178994 -3600
# Node ID 346d86654b1dd81b5aba821bf9732844bb35c7a3
# Parent  bc38aa2e11e21b34dbc29a81f069133a3276848a
libxl: add libxl__parse_hotplug_path

Generate libxl__device from hotplug path.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r bc38aa2e11e2 -r 346d86654b1d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:33:27 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:36:34 2012 +0100
@@ -66,6 +66,24 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__parse_hotplug_path(libxl__gc *gc,
+                              const char *path,
+                              libxl__device *dev)
+{
+    /* /hotplug/<backend_domid>/<frontend_domid>/<kind> */
+    char strkind[16]; /* Longest is actually "console" */
+    int rc = sscanf(path, "/hotplug/%u/%u/%15[^/]/%d",
+                    &dev->backend_domid,
+                    &dev->domid,
+                    strkind,
+                    &dev->devid);
+
+    if (rc != 4)
+        return ERROR_FAIL;
+
+    return libxl__device_kind_from_string(strkind, &dev->backend_kind);
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
diff -r bc38aa2e11e2 -r 346d86654b1d tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:33:27 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:36:34 2012 +0100
@@ -307,6 +307,9 @@ typedef struct {
 _hidden char *libxl__device_hotplug_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
+_hidden int libxl__parse_hotplug_path(libxl__gc *gc,
+                                      const char *path,
+                                      libxl__device *dev);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswu2-0004lO-Ho; Thu, 02 Feb 2012 13:40:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswu1-0004ix-Iu
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:41 +0000
Received: from [85.158.138.51:29310] by server-4.bemta-3.messagelabs.com id
	36/8F-07654-8529A2F4; Thu, 02 Feb 2012 13:40:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!9
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22142 invoked from network); 2 Feb 2012 13:40:40 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:40 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Ke+bEeczc6YGfI1Qs5b7GUNodvL2UFAi62kGD8rVM94=;
	b=T+13RFk5mtXGKdKu0adPOl15T1xs/YS56TgweptyOSgjYd+GLPoUCI+o+s5KtOyd8G
	TU8w/tZXUwr0Fo5oLzYae5Fu5yt0FD1KBtCWgcnB6SBCZwuQl7HV26k7q9k0nilBVwXz
	+EtUN51GkJXPG9j9ts9KF1aUalmrxDP2n8htY=
Received: by 10.180.95.105 with SMTP id dj9mr4586775wib.18.1328190039980;
	Thu, 02 Feb 2012 05:40:39 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 478459fa6bfce280bf31e1d971c5f2b39eee6986
Message-Id: <478459fa6bfce280bf31.1328189217@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:57 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 22 of 29 RFC] libxl: add
	libxl__parse_disk_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179164 -3600
# Node ID 478459fa6bfce280bf31e1d971c5f2b39eee6986
# Parent  346d86654b1dd81b5aba821bf9732844bb35c7a3
libxl: add libxl__parse_disk_hotplug_path

Create a libxl_device_disk from hotplug xenstore information.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 346d86654b1d -r 478459fa6bfc tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:36:34 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:39:24 2012 +0100
@@ -84,6 +84,45 @@ int libxl__parse_hotplug_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__parse_disk_hotplug_path(libxl__gc *gc,
+                                   const char *path,
+                                   libxl_device_disk *disk)
+{
+    char *value;
+
+    disk->pdev_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                  path, 
+                                                                  "pdev_path"));
+
+    disk->vdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                 "vdev"));
+
+    disk->script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                   path,
+                                                                   "script"));
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "removable"));
+    if (value)
+        disk->removable = atoi(value);
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "readwrite"));
+    if (value)
+        disk->readwrite = atoi(value);
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "is_cdrom"));
+    if (value)
+        disk->is_cdrom = atoi(value);
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "format"));
+    if (value)
+        disk->format = atoi(value);
+
+    return 0;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
diff -r 346d86654b1d -r 478459fa6bfc tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:36:34 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:39:24 2012 +0100
@@ -310,6 +310,9 @@ typedef struct {
 _hidden int libxl__parse_hotplug_path(libxl__gc *gc,
                                       const char *path,
                                       libxl__device *dev);
+_hidden int libxl__parse_disk_hotplug_path(libxl__gc *gc,
+                                           const char *path,
+                                           libxl_device_disk *disk);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1Rswu2-0004lO-Ho; Thu, 02 Feb 2012 13:40:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswu1-0004ix-Iu
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:41 +0000
Received: from [85.158.138.51:29310] by server-4.bemta-3.messagelabs.com id
	36/8F-07654-8529A2F4; Thu, 02 Feb 2012 13:40:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!9
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22142 invoked from network); 2 Feb 2012 13:40:40 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:40 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Ke+bEeczc6YGfI1Qs5b7GUNodvL2UFAi62kGD8rVM94=;
	b=T+13RFk5mtXGKdKu0adPOl15T1xs/YS56TgweptyOSgjYd+GLPoUCI+o+s5KtOyd8G
	TU8w/tZXUwr0Fo5oLzYae5Fu5yt0FD1KBtCWgcnB6SBCZwuQl7HV26k7q9k0nilBVwXz
	+EtUN51GkJXPG9j9ts9KF1aUalmrxDP2n8htY=
Received: by 10.180.95.105 with SMTP id dj9mr4586775wib.18.1328190039980;
	Thu, 02 Feb 2012 05:40:39 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 478459fa6bfce280bf31e1d971c5f2b39eee6986
Message-Id: <478459fa6bfce280bf31.1328189217@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:57 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 22 of 29 RFC] libxl: add
	libxl__parse_disk_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179164 -3600
# Node ID 478459fa6bfce280bf31e1d971c5f2b39eee6986
# Parent  346d86654b1dd81b5aba821bf9732844bb35c7a3
libxl: add libxl__parse_disk_hotplug_path

Create a libxl_device_disk from hotplug xenstore information.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 346d86654b1d -r 478459fa6bfc tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:36:34 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:39:24 2012 +0100
@@ -84,6 +84,45 @@ int libxl__parse_hotplug_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__parse_disk_hotplug_path(libxl__gc *gc,
+                                   const char *path,
+                                   libxl_device_disk *disk)
+{
+    char *value;
+
+    disk->pdev_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                  path, 
+                                                                  "pdev_path"));
+
+    disk->vdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                 "vdev"));
+
+    disk->script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s",
+                                                                   path,
+                                                                   "script"));
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "removable"));
+    if (value)
+        disk->removable = atoi(value);
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "readwrite"));
+    if (value)
+        disk->readwrite = atoi(value);
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "is_cdrom"));
+    if (value)
+        disk->is_cdrom = atoi(value);
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "format"));
+    if (value)
+        disk->format = atoi(value);
+
+    return 0;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
diff -r 346d86654b1d -r 478459fa6bfc tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:36:34 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:39:24 2012 +0100
@@ -310,6 +310,9 @@ typedef struct {
 _hidden int libxl__parse_hotplug_path(libxl__gc *gc,
                                       const char *path,
                                       libxl__device *dev);
+_hidden int libxl__parse_disk_hotplug_path(libxl__gc *gc,
+                                           const char *path,
+                                           libxl_device_disk *disk);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswu6-0004rq-5W; Thu, 02 Feb 2012 13:40:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswu3-0004mU-Rq
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:44 +0000
Received: from [85.158.138.51:29475] by server-5.bemta-3.messagelabs.com id
	72/C9-25695-A529A2F4; Thu, 02 Feb 2012 13:40:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!10
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22558 invoked from network); 2 Feb 2012 13:40:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:42 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ywofbuTkLTmam9cjuyw4VhbPNAwp31ONjQBaKfEpqHM=;
	b=BCRPh8Yz+XcT08OnsZrf57pwIAFNYzCK4smOSCptlsJmsh+UBokcviKopb6f+tuMPr
	txp4Z0gkGTQAS+Oeh49o6f+qFnQA2UdQqQ8lQL+VHRyVwGnk6OFHTZjRTrhQw2mrUPvP
	oA0o3ogYqzH99hgVOtiK55KYim/cK1bWwMpC4=
Received: by 10.180.100.228 with SMTP id fb4mr4729345wib.1.1328190041974;
	Thu, 02 Feb 2012 05:40:41 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:40 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2708343292be6facb6a2d8aaf9a9d95afa61b7f6
Message-Id: <2708343292be6facb6a2.1328189218@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:58 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 23 of 29 RFC] libxl: add
	libxl__parse_nic_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179333 -3600
# Node ID 2708343292be6facb6a2d8aaf9a9d95afa61b7f6
# Parent  478459fa6bfce280bf31e1d971c5f2b39eee6986
libxl: add libxl__parse_nic_hotplug_path

Create a libxl_device_nic from hotplug xenstore information.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 478459fa6bfc -r 2708343292be tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:39:24 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:42:13 2012 +0100
@@ -123,6 +123,56 @@ int libxl__parse_disk_hotplug_path(libxl
     return 0;
 }
 
+int libxl__parse_nic_hotplug_path(libxl__gc *gc,
+                                  const char *path,
+                                  libxl_device_nic *nic)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *value;
+
+    if (sscanf(path, "/hotplug/%*u/%*u/vif/%d", &nic->devid) != 1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to get nic device id from "
+                                          "%s", path);
+        return -1;
+    }
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "mtu"));
+    if (value)
+        nic->mtu = atoi(value);
+
+    nic->model = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                 "model"));
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "mac"));
+    if (value) {
+        if (sscanf(value, LIBXL_MAC_FMT, LIBXL_MAC_BYTES(&nic->mac)) != 6) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to parse mac %s", value);
+            return -1;
+        }
+    }
+
+    nic->ip = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                              "ip"));
+
+    nic->bridge = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                  "bridge"));
+    nic->ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                  "ifname"));
+
+    nic->script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                  "script"));
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "nictype"));
+    if (value)
+        nic->nictype = atoi(value);
+
+    return 0;
+}
+
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
diff -r 478459fa6bfc -r 2708343292be tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:39:24 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:42:13 2012 +0100
@@ -313,6 +313,9 @@ typedef struct {
 _hidden int libxl__parse_disk_hotplug_path(libxl__gc *gc,
                                            const char *path,
                                            libxl_device_disk *disk);
+_hidden int libxl__parse_nic_hotplug_path(libxl__gc *gc,
+                                          const char *path,
+                                          libxl_device_nic *nic);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswu6-0004rq-5W; Thu, 02 Feb 2012 13:40:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswu3-0004mU-Rq
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:44 +0000
Received: from [85.158.138.51:29475] by server-5.bemta-3.messagelabs.com id
	72/C9-25695-A529A2F4; Thu, 02 Feb 2012 13:40:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!10
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22558 invoked from network); 2 Feb 2012 13:40:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:42 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ywofbuTkLTmam9cjuyw4VhbPNAwp31ONjQBaKfEpqHM=;
	b=BCRPh8Yz+XcT08OnsZrf57pwIAFNYzCK4smOSCptlsJmsh+UBokcviKopb6f+tuMPr
	txp4Z0gkGTQAS+Oeh49o6f+qFnQA2UdQqQ8lQL+VHRyVwGnk6OFHTZjRTrhQw2mrUPvP
	oA0o3ogYqzH99hgVOtiK55KYim/cK1bWwMpC4=
Received: by 10.180.100.228 with SMTP id fb4mr4729345wib.1.1328190041974;
	Thu, 02 Feb 2012 05:40:41 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:40 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2708343292be6facb6a2d8aaf9a9d95afa61b7f6
Message-Id: <2708343292be6facb6a2.1328189218@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:58 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 23 of 29 RFC] libxl: add
	libxl__parse_nic_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179333 -3600
# Node ID 2708343292be6facb6a2d8aaf9a9d95afa61b7f6
# Parent  478459fa6bfce280bf31e1d971c5f2b39eee6986
libxl: add libxl__parse_nic_hotplug_path

Create a libxl_device_nic from hotplug xenstore information.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 478459fa6bfc -r 2708343292be tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 11:39:24 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:42:13 2012 +0100
@@ -123,6 +123,56 @@ int libxl__parse_disk_hotplug_path(libxl
     return 0;
 }
 
+int libxl__parse_nic_hotplug_path(libxl__gc *gc,
+                                  const char *path,
+                                  libxl_device_nic *nic)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *value;
+
+    if (sscanf(path, "/hotplug/%*u/%*u/vif/%d", &nic->devid) != 1) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to get nic device id from "
+                                          "%s", path);
+        return -1;
+    }
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "mtu"));
+    if (value)
+        nic->mtu = atoi(value);
+
+    nic->model = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                 "model"));
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "mac"));
+    if (value) {
+        if (sscanf(value, LIBXL_MAC_FMT, LIBXL_MAC_BYTES(&nic->mac)) != 6) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to parse mac %s", value);
+            return -1;
+        }
+    }
+
+    nic->ip = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                              "ip"));
+
+    nic->bridge = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                  "bridge"));
+    nic->ifname = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                  "ifname"));
+
+    nic->script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                                  "script"));
+
+    value = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", path,
+                                                            "nictype"));
+    if (value)
+        nic->nictype = atoi(value);
+
+    return 0;
+}
+
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
diff -r 478459fa6bfc -r 2708343292be tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:39:24 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:42:13 2012 +0100
@@ -313,6 +313,9 @@ typedef struct {
 _hidden int libxl__parse_disk_hotplug_path(libxl__gc *gc,
                                            const char *path,
                                            libxl_device_disk *disk);
+_hidden int libxl__parse_nic_hotplug_path(libxl__gc *gc,
+                                          const char *path,
+                                          libxl_device_nic *nic);
 _hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswu8-0004vM-Ir; Thu, 02 Feb 2012 13:40:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswu6-0004rx-SC
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:47 +0000
Received: from [85.158.138.51:29706] by server-3.bemta-3.messagelabs.com id
	A8/AF-18959-D529A2F4; Thu, 02 Feb 2012 13:40:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!11
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22709 invoked from network); 2 Feb 2012 13:40:45 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:45 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ZZWwUg6oGIHCFwOLG1AbSxZR5GJYfGqktpPvnN+gGwk=;
	b=aPcXmCDbQt1wezN4Qo+8YC0+kCVfcsHaO/XkJsrUyEAKG7bNm0x3OEVRlYN4Pw+ANz
	3GB2nM7UfHBvGZUyi+Nj3Rpw229RZ4253IHkRfH2xA1fBCTIbzXpUVyd9xmD6S6Cy6Bo
	oxS5bD2c9MrKVa4VHQEeMGDLS/PlX4QxVoUys=
Received: by 10.180.103.68 with SMTP id fu4mr1517178wib.7.1328190044871;
	Thu, 02 Feb 2012 05:40:44 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
Message-Id: <1506b1f2ab0fe5f4cd5b.1328189219@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 24 of 29 RFC] libxl: add
	libxl_setup_hotplug_listener
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179503 -3600
# Node ID 1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
# Parent  2708343292be6facb6a2d8aaf9a9d95afa61b7f6
libxl: add libxl_setup_hotplug_listener

Setup a xenstore watch on /hotplug/<domid> to react to hotplug
changes.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2708343292be -r 1506b1f2ab0f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:42:13 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:45:03 2012 +0100
@@ -949,6 +949,40 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 }
 
 /******************************************************************************/
+/*
+ * Hotplug functions
+ *
+ */
+
+int libxl_setup_hotplug_listener(libxl_ctx *ctx)
+{
+    GC_INIT(ctx);
+    char *hotplug_path, *id;
+    int rc;
+
+    id = libxl__xs_read(gc, XBT_NULL, "domid");
+    if (!id) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to get domid");
+        rc = -1;
+        goto out;
+    }
+    hotplug_path = libxl__sprintf(gc, "/hotplug/%s", id);
+
+    xs_mkdir(ctx->xsh, XBT_NULL, hotplug_path);
+
+    if (!xs_watch(ctx->xsh, hotplug_path, hotplug_path)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to watch /hotplug/%s", id);
+        rc = -1;
+        goto out;
+    }
+
+    rc = 0;
+out:
+    GC_FREE;
+    return rc;
+}
+
+/******************************************************************************/
 
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
 {
diff -r 2708343292be -r 1506b1f2ab0f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 11:42:13 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Feb 02 11:45:03 2012 +0100
@@ -456,6 +456,14 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *
  *   Requests de destruction of the given device and waits for the result.
  *
+ * Hotplug
+ * -------
+ *
+ * libxl_setup_hotplug_listener(ctx):
+ *
+ *   Set the necessary watches to start monitoring /hotplug/ entries for
+ *   the caller domain.
+ *
  */
 
 /* Disks */
@@ -523,6 +531,9 @@ int libxl_device_pci_remove(libxl_ctx *c
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
 
+/* Hotplug */
+int libxl_setup_hotplug_listener(libxl_ctx *ctx);
+
 /*
  * Parse a PCI BDF into a PCI device structure.
  */

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswu8-0004vM-Ir; Thu, 02 Feb 2012 13:40:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rswu6-0004rx-SC
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:47 +0000
Received: from [85.158.138.51:29706] by server-3.bemta-3.messagelabs.com id
	A8/AF-18959-D529A2F4; Thu, 02 Feb 2012 13:40:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!11
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22709 invoked from network); 2 Feb 2012 13:40:45 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:45 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ZZWwUg6oGIHCFwOLG1AbSxZR5GJYfGqktpPvnN+gGwk=;
	b=aPcXmCDbQt1wezN4Qo+8YC0+kCVfcsHaO/XkJsrUyEAKG7bNm0x3OEVRlYN4Pw+ANz
	3GB2nM7UfHBvGZUyi+Nj3Rpw229RZ4253IHkRfH2xA1fBCTIbzXpUVyd9xmD6S6Cy6Bo
	oxS5bD2c9MrKVa4VHQEeMGDLS/PlX4QxVoUys=
Received: by 10.180.103.68 with SMTP id fu4mr1517178wib.7.1328190044871;
	Thu, 02 Feb 2012 05:40:44 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
Message-Id: <1506b1f2ab0fe5f4cd5b.1328189219@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 24 of 29 RFC] libxl: add
	libxl_setup_hotplug_listener
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179503 -3600
# Node ID 1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
# Parent  2708343292be6facb6a2d8aaf9a9d95afa61b7f6
libxl: add libxl_setup_hotplug_listener

Setup a xenstore watch on /hotplug/<domid> to react to hotplug
changes.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2708343292be -r 1506b1f2ab0f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:42:13 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:45:03 2012 +0100
@@ -949,6 +949,40 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 }
 
 /******************************************************************************/
+/*
+ * Hotplug functions
+ *
+ */
+
+int libxl_setup_hotplug_listener(libxl_ctx *ctx)
+{
+    GC_INIT(ctx);
+    char *hotplug_path, *id;
+    int rc;
+
+    id = libxl__xs_read(gc, XBT_NULL, "domid");
+    if (!id) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to get domid");
+        rc = -1;
+        goto out;
+    }
+    hotplug_path = libxl__sprintf(gc, "/hotplug/%s", id);
+
+    xs_mkdir(ctx->xsh, XBT_NULL, hotplug_path);
+
+    if (!xs_watch(ctx->xsh, hotplug_path, hotplug_path)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to watch /hotplug/%s", id);
+        rc = -1;
+        goto out;
+    }
+
+    rc = 0;
+out:
+    GC_FREE;
+    return rc;
+}
+
+/******************************************************************************/
 
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
 {
diff -r 2708343292be -r 1506b1f2ab0f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 11:42:13 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Feb 02 11:45:03 2012 +0100
@@ -456,6 +456,14 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *
  *   Requests de destruction of the given device and waits for the result.
  *
+ * Hotplug
+ * -------
+ *
+ * libxl_setup_hotplug_listener(ctx):
+ *
+ *   Set the necessary watches to start monitoring /hotplug/ entries for
+ *   the caller domain.
+ *
  */
 
 /* Disks */
@@ -523,6 +531,9 @@ int libxl_device_pci_remove(libxl_ctx *c
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
 
+/* Hotplug */
+int libxl_setup_hotplug_listener(libxl_ctx *ctx);
+
 /*
  * Parse a PCI BDF into a PCI device structure.
  */

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswuA-0004zV-Ve; Thu, 02 Feb 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 <royger@gmail.com>) id 1Rswu9-0004vm-EJ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:49 +0000
Received: from [85.158.138.51:29892] by server-10.bemta-3.messagelabs.com id
	8D/A4-06813-0629A2F4; Thu, 02 Feb 2012 13:40:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!12
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22785 invoked from network); 2 Feb 2012 13:40:47 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:47 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=wByyDj0Xc8ckMvhaiet3YnXAzh7zju13hUFZWy3JBpk=;
	b=KpvxwS8O1AMgx2SWG5C2N3W2iItD17yuceJX3ZJN5jqbuwBlGu1xKq9p5kEc5FfTzO
	jP61ToEo3TtR8DO3GOMi6YTlzeFCAMJHeG8g9gN7FrQE0V+rkG+JtkNEMfzJzElATxZo
	8Oxvyof5S2arQZ1KjZcKfd4CiUNquEFLt+yEU=
Received: by 10.180.109.77 with SMTP id hq13mr17981191wib.7.1328190047375;
	Thu, 02 Feb 2012 05:40:47 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 94532199f647fc03816fc5ae50ab53c8c5b80cd8
Message-Id: <94532199f647fc03816f.1328189220@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179686 -3600
# Node ID 94532199f647fc03816fc5ae50ab53c8c5b80cd8
# Parent  1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
libxl: add libxl_hotplug_dispatch

Added a new function to libxl API to handle device hotplug. Actions to
execute upon hotplug device state changes are handled using the
libxl_device_disk_hotplug_actions and libxl_device_nic_hotplug_actions
depending on the type of device. Currently only VIF and VBD devices
are handled by the hotplug mechanism.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:45:03 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:48:06 2012 +0100
@@ -982,6 +982,188 @@ out:
     return rc;
 }
 
+static int libxl__hotplug_generic_dispatcher(libxl__gc *gc, char *path,
+                                uint32_t domid,
+                                libxl__hotplug_status state,
+                                libxl__device_generic_hotplug_actions *action,
+                                void *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *spath = libxl__sprintf(gc, "%s/state", path);
+    int rc = 0;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "processing device %s with state %d",
+                                      path, state);
+    switch(state) {
+    case HOTPLUG_DEVICE_INIT:
+        if (action->init) {
+            rc = action->init(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to init"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECT);
+        break;
+    case HOTPLUG_DEVICE_CONNECT:
+        if (action->connect) {
+            rc = action->connect(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to connect"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECTED);
+        break;
+    case HOTPLUG_DEVICE_CONNECTED:
+        if (action->connected) {
+            rc = action->connected(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
+                                                  "connected action on"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        break;
+    case HOTPLUG_DEVICE_DISCONNECT:
+        if (action->disconnect) {
+            rc = action->disconnect(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to unplug"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                        HOTPLUG_DEVICE_DISCONNECTED);
+        break;
+    case HOTPLUG_DEVICE_DISCONNECTED:
+        if (action->disconnected) {
+            rc = action->disconnected(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
+                                                  "unpluged action on"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        break;
+    case HOTPLUG_DEVICE_FORCE_DISCONNECT:
+        if (action->force_disconnect) {
+            rc = action->force_disconnect(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to force "
+                                                  "disconnect device "
+                                                  "%s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                        HOTPLUG_DEVICE_DISCONNECTED);
+        break;
+    case HOTPLUG_DEVICE_ERROR:
+        if (action->error)
+            rc = action->error(ctx, domid, device);
+        break;
+    }
+    return rc;
+}
+
+int libxl_hotplug_dispatch(libxl_ctx *ctx,
+                           libxl_device_disk_hotplug_actions *disk_handler,
+                           libxl_device_nic_hotplug_actions *nic_handler)
+{
+    unsigned int n;
+    char **l1, *sstate, *entry, *spath;
+    libxl__device dev;
+    libxl_device_disk disk;
+    libxl_device_nic nic;
+    libxl__hotplug_status state;
+
+    for (;;) {
+        GC_INIT(ctx);
+        l1 = xs_read_watch(ctx->xsh, &n);
+        if (!l1) {
+            continue;
+        }
+
+        /* Only react to "state" changes */
+        entry = strrchr(l1[0], '/');
+        if (!entry || strcmp(entry, "/state"))
+            goto next;
+
+        spath = libxl__strdup(gc, l1[0]);
+        /* Fetch state info */
+        sstate = libxl__xs_read(gc, XBT_NULL, l1[0]);
+        if (!sstate) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse state"
+                                              "from %s", l1[0]);
+            goto next;
+        }
+        state = atoi(sstate);
+
+        /* remove "state" part from path */
+        *entry = '\0';
+        if (libxl__parse_hotplug_path(gc, l1[0], &dev) < 0)
+            goto next;
+
+        switch(dev.backend_kind) {
+        case LIBXL__DEVICE_KIND_VBD:
+            libxl_device_disk_init(ctx, &disk);
+            if (libxl__parse_disk_hotplug_path(gc, l1[0], &disk)) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse disk data"
+                                                  "from %s", l1[0]);
+                goto next;
+            }
+            /* Choose suitable backend */
+            disk.backend = LIBXL_DISK_BACKEND_UNKNOWN;
+            if (libxl__device_disk_set_backend(gc, &disk) < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "no suitable backend for"
+                                                  "disk %s", disk.pdev_path);
+                goto next;
+            }
+            libxl__hotplug_generic_dispatcher(gc, l1[0], dev.domid, state,
+                    (libxl__device_generic_hotplug_actions *) disk_handler,
+                    (void *) &disk);
+            break;
+        case LIBXL__DEVICE_KIND_VIF:
+            libxl_device_nic_init(ctx, &nic);
+            if (libxl__parse_nic_hotplug_path(gc, l1[0], &nic)) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse nic data"
+                                                  "from %s", l1[0]);
+                goto next;
+            }
+            libxl__hotplug_generic_dispatcher(gc, l1[0], dev.domid, state,
+                    (libxl__device_generic_hotplug_actions *) nic_handler,
+                    (void *) &nic);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to handle device type %s from %s",
+                       libxl__device_kind_to_string(dev.backend_kind), l1[0]);
+            break;
+        }
+next:
+        free(l1);
+        GC_FREE;
+    }
+}
+
 /******************************************************************************/
 
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 11:45:03 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Feb 02 11:48:06 2012 +0100
@@ -464,6 +464,12 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *   Set the necessary watches to start monitoring /hotplug/ entries for
  *   the caller domain.
  *
+ * libxl_hotplug_dispatch(ctx, disk_handler, nic_handler):
+ *
+ *   React to /hotplug/<domid> changes and execute the necessary handlers
+ *   based on the passed disk_handler and nic_handler structs that contain
+ *   the pointers to the functions to be executed.
+ *
  */
 
 /* Disks */
@@ -532,7 +538,37 @@ int libxl_device_pci_destroy(libxl_ctx *
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
 
 /* Hotplug */
+typedef int libxl_device_disk_hotplug_handler(libxl_ctx *ctx,
+                                              uint32_t domid,
+                                              libxl_device_disk *disk);
+typedef int libxl_device_nic_hotplug_handler(libxl_ctx *ctx,
+                                             uint32_t domid,
+                                             libxl_device_nic *nic);
+
+typedef struct libxl_device_disk_hotplug_actions {
+    libxl_device_disk_hotplug_handler *init;
+    libxl_device_disk_hotplug_handler *connect;
+    libxl_device_disk_hotplug_handler *connected;
+    libxl_device_disk_hotplug_handler *disconnect;
+    libxl_device_disk_hotplug_handler *disconnected;
+    libxl_device_disk_hotplug_handler *force_disconnect;
+    libxl_device_disk_hotplug_handler *error;
+} libxl_device_disk_hotplug_actions;
+
+typedef struct libxl_device_nic_hotplug_actions {
+    libxl_device_nic_hotplug_handler *init;
+    libxl_device_nic_hotplug_handler *connect;
+    libxl_device_nic_hotplug_handler *connected;
+    libxl_device_nic_hotplug_handler *disconnect;
+    libxl_device_nic_hotplug_handler *disconnected;
+    libxl_device_nic_hotplug_handler *force_disconnect;
+    libxl_device_nic_hotplug_handler *error;
+} libxl_device_nic_hotplug_actions;
+
 int libxl_setup_hotplug_listener(libxl_ctx *ctx);
+int libxl_hotplug_dispatch(libxl_ctx *ctx,
+                           libxl_device_disk_hotplug_actions *disk_handler,
+                           libxl_device_nic_hotplug_actions *nic_handler);
 
 /*
  * Parse a PCI BDF into a PCI device structure.
diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:45:03 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:48:06 2012 +0100
@@ -384,6 +384,22 @@ typedef enum {
 _hidden int libxl__device_hotplug_disconnect(libxl__gc *gc, libxl__device *dev,
                                        libxl__hotplug_status disconnect_param);
 
+/* Generic handlers for hotplug devices */
+/* Hotplug */
+typedef int libxl__device_generic_hotplug_handler(libxl_ctx *ctx,
+                                                 uint32_t domid,
+                                                 void *device);
+
+typedef struct libxl__device_generic_hotplug_actions {
+    libxl__device_generic_hotplug_handler *init;
+    libxl__device_generic_hotplug_handler *connect;
+    libxl__device_generic_hotplug_handler *connected;
+    libxl__device_generic_hotplug_handler *disconnect;
+    libxl__device_generic_hotplug_handler *disconnected;
+    libxl__device_generic_hotplug_handler *force_disconnect;
+    libxl__device_generic_hotplug_handler *error;
+} libxl__device_generic_hotplug_actions;
+
 /*
  * libxl__device_hotplug - generic function to execute hotplug scripts
  * gc: allocation pool

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswuA-0004zV-Ve; Thu, 02 Feb 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 <royger@gmail.com>) id 1Rswu9-0004vm-EJ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:49 +0000
Received: from [85.158.138.51:29892] by server-10.bemta-3.messagelabs.com id
	8D/A4-06813-0629A2F4; Thu, 02 Feb 2012 13:40:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!12
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22785 invoked from network); 2 Feb 2012 13:40:47 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:47 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=wByyDj0Xc8ckMvhaiet3YnXAzh7zju13hUFZWy3JBpk=;
	b=KpvxwS8O1AMgx2SWG5C2N3W2iItD17yuceJX3ZJN5jqbuwBlGu1xKq9p5kEc5FfTzO
	jP61ToEo3TtR8DO3GOMi6YTlzeFCAMJHeG8g9gN7FrQE0V+rkG+JtkNEMfzJzElATxZo
	8Oxvyof5S2arQZ1KjZcKfd4CiUNquEFLt+yEU=
Received: by 10.180.109.77 with SMTP id hq13mr17981191wib.7.1328190047375;
	Thu, 02 Feb 2012 05:40:47 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 94532199f647fc03816fc5ae50ab53c8c5b80cd8
Message-Id: <94532199f647fc03816f.1328189220@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328179686 -3600
# Node ID 94532199f647fc03816fc5ae50ab53c8c5b80cd8
# Parent  1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
libxl: add libxl_hotplug_dispatch

Added a new function to libxl API to handle device hotplug. Actions to
execute upon hotplug device state changes are handled using the
libxl_device_disk_hotplug_actions and libxl_device_nic_hotplug_actions
depending on the type of device. Currently only VIF and VBD devices
are handled by the hotplug mechanism.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 11:45:03 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 11:48:06 2012 +0100
@@ -982,6 +982,188 @@ out:
     return rc;
 }
 
+static int libxl__hotplug_generic_dispatcher(libxl__gc *gc, char *path,
+                                uint32_t domid,
+                                libxl__hotplug_status state,
+                                libxl__device_generic_hotplug_actions *action,
+                                void *device)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *spath = libxl__sprintf(gc, "%s/state", path);
+    int rc = 0;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "processing device %s with state %d",
+                                      path, state);
+    switch(state) {
+    case HOTPLUG_DEVICE_INIT:
+        if (action->init) {
+            rc = action->init(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to init"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECT);
+        break;
+    case HOTPLUG_DEVICE_CONNECT:
+        if (action->connect) {
+            rc = action->connect(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to connect"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECTED);
+        break;
+    case HOTPLUG_DEVICE_CONNECTED:
+        if (action->connected) {
+            rc = action->connected(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
+                                                  "connected action on"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        break;
+    case HOTPLUG_DEVICE_DISCONNECT:
+        if (action->disconnect) {
+            rc = action->disconnect(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to unplug"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                        HOTPLUG_DEVICE_DISCONNECTED);
+        break;
+    case HOTPLUG_DEVICE_DISCONNECTED:
+        if (action->disconnected) {
+            rc = action->disconnected(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
+                                                  "unpluged action on"
+                                                  " device %s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        break;
+    case HOTPLUG_DEVICE_FORCE_DISCONNECT:
+        if (action->force_disconnect) {
+            rc = action->force_disconnect(ctx, domid, device);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to force "
+                                                  "disconnect device "
+                                                  "%s", path);
+                libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                                HOTPLUG_DEVICE_ERROR);
+                break;
+            }
+        }
+        libxl__xs_write(gc, XBT_NULL, spath, "%d",
+                        HOTPLUG_DEVICE_DISCONNECTED);
+        break;
+    case HOTPLUG_DEVICE_ERROR:
+        if (action->error)
+            rc = action->error(ctx, domid, device);
+        break;
+    }
+    return rc;
+}
+
+int libxl_hotplug_dispatch(libxl_ctx *ctx,
+                           libxl_device_disk_hotplug_actions *disk_handler,
+                           libxl_device_nic_hotplug_actions *nic_handler)
+{
+    unsigned int n;
+    char **l1, *sstate, *entry, *spath;
+    libxl__device dev;
+    libxl_device_disk disk;
+    libxl_device_nic nic;
+    libxl__hotplug_status state;
+
+    for (;;) {
+        GC_INIT(ctx);
+        l1 = xs_read_watch(ctx->xsh, &n);
+        if (!l1) {
+            continue;
+        }
+
+        /* Only react to "state" changes */
+        entry = strrchr(l1[0], '/');
+        if (!entry || strcmp(entry, "/state"))
+            goto next;
+
+        spath = libxl__strdup(gc, l1[0]);
+        /* Fetch state info */
+        sstate = libxl__xs_read(gc, XBT_NULL, l1[0]);
+        if (!sstate) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse state"
+                                              "from %s", l1[0]);
+            goto next;
+        }
+        state = atoi(sstate);
+
+        /* remove "state" part from path */
+        *entry = '\0';
+        if (libxl__parse_hotplug_path(gc, l1[0], &dev) < 0)
+            goto next;
+
+        switch(dev.backend_kind) {
+        case LIBXL__DEVICE_KIND_VBD:
+            libxl_device_disk_init(ctx, &disk);
+            if (libxl__parse_disk_hotplug_path(gc, l1[0], &disk)) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse disk data"
+                                                  "from %s", l1[0]);
+                goto next;
+            }
+            /* Choose suitable backend */
+            disk.backend = LIBXL_DISK_BACKEND_UNKNOWN;
+            if (libxl__device_disk_set_backend(gc, &disk) < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "no suitable backend for"
+                                                  "disk %s", disk.pdev_path);
+                goto next;
+            }
+            libxl__hotplug_generic_dispatcher(gc, l1[0], dev.domid, state,
+                    (libxl__device_generic_hotplug_actions *) disk_handler,
+                    (void *) &disk);
+            break;
+        case LIBXL__DEVICE_KIND_VIF:
+            libxl_device_nic_init(ctx, &nic);
+            if (libxl__parse_nic_hotplug_path(gc, l1[0], &nic)) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to parse nic data"
+                                                  "from %s", l1[0]);
+                goto next;
+            }
+            libxl__hotplug_generic_dispatcher(gc, l1[0], dev.domid, state,
+                    (libxl__device_generic_hotplug_actions *) nic_handler,
+                    (void *) &nic);
+            break;
+        default:
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to handle device type %s from %s",
+                       libxl__device_kind_to_string(dev.backend_kind), l1[0]);
+            break;
+        }
+next:
+        free(l1);
+        GC_FREE;
+    }
+}
+
 /******************************************************************************/
 
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 11:45:03 2012 +0100
+++ b/tools/libxl/libxl.h	Thu Feb 02 11:48:06 2012 +0100
@@ -464,6 +464,12 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  *   Set the necessary watches to start monitoring /hotplug/ entries for
  *   the caller domain.
  *
+ * libxl_hotplug_dispatch(ctx, disk_handler, nic_handler):
+ *
+ *   React to /hotplug/<domid> changes and execute the necessary handlers
+ *   based on the passed disk_handler and nic_handler structs that contain
+ *   the pointers to the functions to be executed.
+ *
  */
 
 /* Disks */
@@ -532,7 +538,37 @@ int libxl_device_pci_destroy(libxl_ctx *
 libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num);
 
 /* Hotplug */
+typedef int libxl_device_disk_hotplug_handler(libxl_ctx *ctx,
+                                              uint32_t domid,
+                                              libxl_device_disk *disk);
+typedef int libxl_device_nic_hotplug_handler(libxl_ctx *ctx,
+                                             uint32_t domid,
+                                             libxl_device_nic *nic);
+
+typedef struct libxl_device_disk_hotplug_actions {
+    libxl_device_disk_hotplug_handler *init;
+    libxl_device_disk_hotplug_handler *connect;
+    libxl_device_disk_hotplug_handler *connected;
+    libxl_device_disk_hotplug_handler *disconnect;
+    libxl_device_disk_hotplug_handler *disconnected;
+    libxl_device_disk_hotplug_handler *force_disconnect;
+    libxl_device_disk_hotplug_handler *error;
+} libxl_device_disk_hotplug_actions;
+
+typedef struct libxl_device_nic_hotplug_actions {
+    libxl_device_nic_hotplug_handler *init;
+    libxl_device_nic_hotplug_handler *connect;
+    libxl_device_nic_hotplug_handler *connected;
+    libxl_device_nic_hotplug_handler *disconnect;
+    libxl_device_nic_hotplug_handler *disconnected;
+    libxl_device_nic_hotplug_handler *force_disconnect;
+    libxl_device_nic_hotplug_handler *error;
+} libxl_device_nic_hotplug_actions;
+
 int libxl_setup_hotplug_listener(libxl_ctx *ctx);
+int libxl_hotplug_dispatch(libxl_ctx *ctx,
+                           libxl_device_disk_hotplug_actions *disk_handler,
+                           libxl_device_nic_hotplug_actions *nic_handler);
 
 /*
  * Parse a PCI BDF into a PCI device structure.
diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 11:45:03 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 11:48:06 2012 +0100
@@ -384,6 +384,22 @@ typedef enum {
 _hidden int libxl__device_hotplug_disconnect(libxl__gc *gc, libxl__device *dev,
                                        libxl__hotplug_status disconnect_param);
 
+/* Generic handlers for hotplug devices */
+/* Hotplug */
+typedef int libxl__device_generic_hotplug_handler(libxl_ctx *ctx,
+                                                 uint32_t domid,
+                                                 void *device);
+
+typedef struct libxl__device_generic_hotplug_actions {
+    libxl__device_generic_hotplug_handler *init;
+    libxl__device_generic_hotplug_handler *connect;
+    libxl__device_generic_hotplug_handler *connected;
+    libxl__device_generic_hotplug_handler *disconnect;
+    libxl__device_generic_hotplug_handler *disconnected;
+    libxl__device_generic_hotplug_handler *force_disconnect;
+    libxl__device_generic_hotplug_handler *error;
+} libxl__device_generic_hotplug_actions;
+
 /*
  * libxl__device_hotplug - generic function to execute hotplug scripts
  * gc: allocation pool

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1RswuE-000553-Cg; Thu, 02 Feb 2012 13:40:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuB-00050I-VC
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:52 +0000
Received: from [85.158.138.51:30077] by server-5.bemta-3.messagelabs.com id
	B8/1A-25695-3629A2F4; Thu, 02 Feb 2012 13:40:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!13
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22909 invoked from network); 2 Feb 2012 13:40:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:50 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=snZ7/VSdbaL8u+HGjtPRpTNlEpBD1zyiy8c86tCUWb0=;
	b=cVBKUNJr9dYgQX7Lxfw3rK36jUPas0heZed5BdnHrzk7NGsFpUJuoe0WI4Im0xk0Og
	asbc2An7hA1xWTfUEogZo4R+SSxXk6Hei3tPyG3ll0Ajsvgxg9sROFRb0x/41G9k6XTM
	O31m0wUKbaQKgwQ8680PXsWw3FkTqWwT7rA8I=
Received: by 10.180.93.132 with SMTP id cu4mr17971754wib.9.1328190049922;
	Thu, 02 Feb 2012 05:40:49 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e904f98a4445fee7489490b5ccc00b7bb62d796d
Message-Id: <e904f98a4445fee74894.1328189221@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:01 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 26 of 29 RFC] xldeviced: new daemon to execute
	hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI4MTc5OTA5IC0zNjAwCiMgTm9kZSBJRCBlOTA0Zjk4YTQ0
NDVmZWU3NDg5NDkwYjVjY2MwMGI3YmI2MmQ3OTZkCiMgUGFyZW50ICA5NDUzMjE5OWY2NDdmYzAz
ODE2ZmM1YWU1MGFiNTNjOGM1YjgwY2Q4CnhsZGV2aWNlZDogbmV3IGRhZW1vbiB0byBleGVjdXRl
IGhvdHBsdWcgc2NyaXB0cwoKVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIHhsZGV2aWNlZCwgYSBuZXcg
ZGFlbW9uIHRoYXQgbW9uaXRvcnMKL2hvdHBsdWcvPGRvbWlkPiBhbmQgaXMgaW4gY2hhcmdlIG9m
IGF0dGFjaGluZyB0aGUgcGFzc2VkIGRldmljZXMgdG8KdGhlIGRlc2lyZWQgRG9tVS4gTWFrZXMg
dXNlIG9mIHRoZSBwcmV2aW91c2x5IGludHJvZHVjZWQgbGlieGwgaG90cGx1ZwpmdW5jdGlvbnMu
CgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1
PgoKZGlmZiAtciA5NDUzMjE5OWY2NDcgLXIgZTkwNGY5OGE0NDQ1IHRvb2xzL2xpYnhsL01ha2Vm
aWxlCi0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlCVRodSBGZWIgMDIgMTE6NDg6MDYgMjAxMiAr
MDEwMAorKysgYi90b29scy9saWJ4bC9NYWtlZmlsZQlUaHUgRmViIDAyIDExOjUxOjQ5IDIwMTIg
KzAxMDAKQEAgLTEzLDcgKzEzLDcgQEAgWExVTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtV2Vycm9y
IC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RoIC1XbWlzc2luZy1kZWNsYXJhdGlvbnMgXAogCS1Xbm8t
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1XZm9ybWF0LW5vbmxpdGVyYWwKLUNGTEFHUyAr
PSAtSS4gLWZQSUMKK0NGTEFHUyArPSAtSS4gLWZQSUMgLWcKIAogaWZlcSAoJChDT05GSUdfTGlu
dXgpLHkpCiBMSUJVVUlEX0xJQlMgKz0gLWx1dWlkCkBAIC02MCwxMiArNjAsMTYgQEAgTElCWExV
X09CSlMgPSBsaWJ4bHVfY2ZnX3kubyBsaWJ4bHVfY2ZnXwogCWxpYnhsdV9kaXNrX2wubyBsaWJ4
bHVfZGlzay5vCiAkKExJQlhMVV9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwp
ICMgRm9yIHhlbnRvb2xsb2cuaAogCi1DTElFTlRTID0geGwgdGVzdGlkbAorQ0xJRU5UUyA9IHhs
IHhsZGV2aWNlZCB0ZXN0aWRsCiAKIFhMX09CSlMgPSB4bC5vIHhsX2NtZGltcGwubyB4bF9jbWR0
YWJsZS5vCiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3Ig
eGVudG9vbGxvZy5oCiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVubGlnaHQp
CiAKK1hMREVWSUNFRF9PQkpTID0geGxkZXZpY2VkLm8KKyQoWExERVZJQ0VEX09CSlMpOiBDRkxB
R1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3IgeGVudG9vbGxvZy5oCiskKFhMREVWSUNF
RF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmxpZ2h0KQorCiB0ZXN0aWRsLm86IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5saWdodCkKIHRlc3Rp
ZGwuYzogbGlieGxfdHlwZXMuaWRsIGdlbnRlc3QucHkgbGlieGwuaCAkKEFVVE9JTkNTKQogCSQo
UFlUSE9OKSBnZW50ZXN0LnB5IGxpYnhsX3R5cGVzLmlkbCB0ZXN0aWRsLmMubmV3CkBAIC0xNDAs
OCArMTQ0LDEyIEBAIGxpYnhsdXRpbC5hOiAkKExJQlhMVV9PQkpTKQogeGw6ICQoWExfT0JKUykg
bGlieGx1dGlsLnNvIGxpYnhlbmxpZ2h0LnNvCiAJJChDQykgJChMREZMQUdTKSAtbyAkQCAkKFhM
X09CSlMpIGxpYnhsdXRpbC5zbyAkKExETElCU19saWJ4ZW5saWdodCkgJChMRExJQlNfbGlieGVu
Y3RybCkgJChBUFBFTkRfTERGTEFHUykKIAoreGxkZXZpY2VkOiAkKFhMREVWSUNFRF9PQkpTKSBs
aWJ4bHV0aWwuc28gbGlieGVubGlnaHQuc28KKwkkKENDKSAkKExERkxBR1MpIC1vICRAICQoWExE
RVZJQ0VEX09CSlMpIGxpYnhsdXRpbC5zbyAkKExETElCU19saWJ4ZW5saWdodCkgJChMRExJQlNf
bGlieGVuY3RybCkgJChBUFBFTkRfTERGTEFHUykKKwogdGVzdGlkbDogdGVzdGlkbC5vIGxpYnhs
dXRpbC5zbyBsaWJ4ZW5saWdodC5zbwogCSQoQ0MpICQoTERGTEFHUykgLW8gJEAgdGVzdGlkbC5v
IGxpYnhsdXRpbC5zbyAkKExETElCU19saWJ4ZW5saWdodCkgJChMRExJQlNfbGlieGVuY3RybCkg
JChBUFBFTkRfTERGTEFHUykKKyAgICAKIAogLlBIT05ZOiBpbnN0YWxsCiBpbnN0YWxsOiBhbGwK
QEAgLTE1MSw2ICsxNTksNyBAQCBpbnN0YWxsOiBhbGwKIAkkKElOU1RBTExfRElSKSAkKERFU1RE
SVIpJChCQVNIX0NPTVBMRVRJT05fRElSKQogCSQoSU5TVEFMTF9ESVIpICQoREVTVERJUikkKFhF
Tl9SVU5fRElSKQogCSQoSU5TVEFMTF9QUk9HKSB4bCAkKERFU1RESVIpJChTQklORElSKQorCSQo
SU5TVEFMTF9QUk9HKSB4bGRldmljZWQgJChERVNURElSKSQoU0JJTkRJUikKIAkkKElOU1RBTExf
UFJPRykgbGlieGVubGlnaHQuc28uJChNQUpPUikuJChNSU5PUikgJChERVNURElSKSQoTElCRElS
KQogCWxuIC1zZiBsaWJ4ZW5saWdodC5zby4kKE1BSk9SKS4kKE1JTk9SKSAkKERFU1RESVIpJChM
SUJESVIpL2xpYnhlbmxpZ2h0LnNvLiQoTUFKT1IpCiAJbG4gLXNmIGxpYnhlbmxpZ2h0LnNvLiQo
TUFKT1IpICQoREVTVERJUikkKExJQkRJUikvbGlieGVubGlnaHQuc28KZGlmZiAtciA5NDUzMjE5
OWY2NDcgLXIgZTkwNGY5OGE0NDQ1IHRvb2xzL2xpYnhsL3hsZGV2aWNlZC5jCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL3hsZGV2
aWNlZC5jCVRodSBGZWIgMDIgMTE6NTE6NDkgMjAxMiArMDEwMApAQCAtMCwwICsxLDE4NyBAQAor
LyoKKyAqIENvcHlyaWdodCAoQykgMjAxMgorICogQXV0aG9yIFJvZ2VyIFBhdSBNb25uw6kgPHJv
Z2VyLnBhdUBlbnRlbC51cGMuZWR1PgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3
YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJs
aXNoZWQKKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IHZlcnNpb24gMi4xIG9u
bHkuIHdpdGggdGhlIHNwZWNpYWwKKyAqIGV4Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBp
biBmaWxlIExJQ0VOU0UuCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRo
ZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFO
VFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklM
SVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05V
IExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKi8KKwor
I2luY2x1ZGUgImxpYnhsX29zZGVwcy5oIgorCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVk
ZSA8dW5pc3RkLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+
CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPGFz
c2VydC5oPgorCisjaW5jbHVkZSA8eGVuY3RybC5oPgorI2luY2x1ZGUgPHhzLmg+CisKKyNpbmNs
dWRlICJsaWJ4bC5oIgorI2luY2x1ZGUgImxpYnhsX3V0aWxzLmgiCisjaW5jbHVkZSAibGlieGx1
dGlsLmgiCisjaW5jbHVkZSAieGxkZXZpY2VkLmgiCisKK3hlbnRvb2xsb2dfbG9nZ2VyX3N0ZGlv
c3RyZWFtICpsb2dnZXI7CitsaWJ4bF9jdHggKmN0eDsKKworc3RhdGljIHhlbnRvb2xsb2dfbGV2
ZWwgbWlubXNnbGV2ZWwgPSBYVExfUFJPR1JFU1M7CitzdHJ1Y3QgeHNfaGFuZGxlICp4czsKKwor
bGlieGxfZGV2aWNlX2Rpc2tfaG90cGx1Z19hY3Rpb25zIGRpc2tfaGFuZGxlciA9IHsKKyAgICAu
Y29ubmVjdCA9IGxpYnhsX2RldmljZV9kaXNrX2FkZCwKKyAgICAuZGlzY29ubmVjdCA9IGxpYnhs
X2RldmljZV9kaXNrX3JlbW92ZSwKKyAgICAuZm9yY2VfZGlzY29ubmVjdCA9IGxpYnhsX2Rldmlj
ZV9kaXNrX2Rlc3Ryb3ksCit9OworCitsaWJ4bF9kZXZpY2VfbmljX2hvdHBsdWdfYWN0aW9ucyBu
aWNfaGFuZGxlciA9IHsKKyAgICAuY29ubmVjdCA9IGxpYnhsX2RldmljZV9uaWNfYWRkLAorICAg
IC5kaXNjb25uZWN0ID0gbGlieGxfZGV2aWNlX25pY19yZW1vdmUsCisgICAgLmZvcmNlX2Rpc2Nv
bm5lY3QgPSBsaWJ4bF9kZXZpY2VfbmljX2Rlc3Ryb3ksCit9OworCitzdGF0aWMgaW50IGNyZWF0
ZV9waWRmaWxlKGNoYXIgKmZpbGUpCit7CisgICAgcGlkX3QgcGlkOworICAgIGludCByYywgZmQ7
CisgICAgY2hhciAqczsKKworICAgIGZkID0gb3BlbihmaWxlLCBPX1dST05MWXxPX0NSRUFUfE9f
VFJVTkMsIFNfSVJVU1J8U19JV1VTUik7CisgICAgaWYgKGZkIDwgMCkgeworICAgICAgICBMT0co
InVuYWJsZSB0byBvcGVuIHBpZGZpbGUgJXMiLCBmaWxlKTsKKyAgICAgICAgcmV0dXJuIC0xOwor
ICAgIH0KKyAgICBwaWQgPSBnZXRwaWQoKTsKKyAgICByYyA9IGFzcHJpbnRmKCZzLCAiJWRcbiIs
IHBpZCk7CisgICAgaWYgKHJjIDwgMCkKKyAgICAgICAgcmV0dXJuIC0xOworICAgIGxpYnhsX3dy
aXRlX2V4YWN0bHkoTlVMTCwgZmQsIHMsIHJjLCBOVUxMLCBOVUxMKTsKKworICAgIGNsb3NlKGZk
KTsKKyAgICByZXR1cm4gMDsKK30KKworaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQor
eworICAgIGludCBvcHQgPSAwOworICAgIGludCBkYWVtb25pemUgPSAxOworICAgIGludCBzdGF0
dXMsIHJjID0gMCwgcmV0ID0gMDsKKyAgICBjaGFyICpsb2dmaWxlbmFtZSA9ICJ4bGRldmljZWQi
OworICAgIGNoYXIgKnBpZGZpbGUgPSBQSURGSUxFOworICAgIGludCBsb2dmaWxlOworCisgICAg
d2hpbGUgKChvcHQgPSBnZXRvcHQoYXJnYywgYXJndiwgIit2ZnA6IikpID49IDApIHsKKyAgICAg
ICAgc3dpdGNoIChvcHQpIHsKKyAgICAgICAgY2FzZSAndic6CisgICAgICAgICAgICBpZiAobWlu
bXNnbGV2ZWwgPiAwKSBtaW5tc2dsZXZlbC0tOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAg
IGNhc2UgJ2YnOgorICAgICAgICAgICAgZGFlbW9uaXplID0gMDsKKyAgICAgICAgICAgIGJyZWFr
OworICAgICAgICBjYXNlICdwJzoKKyAgICAgICAgICAgIHBpZGZpbGUgPSBvcHRhcmc7CisgICAg
ICAgICAgICBicmVhazsKKyAgICAgICAgZGVmYXVsdDoKKyAgICAgICAgICAgIGZwcmludGYoc3Rk
ZXJyLCAidW5rbm93biBnbG9iYWwgb3B0aW9uXG4iKTsKKyAgICAgICAgICAgIGV4aXQoMik7Cisg
ICAgICAgIH0KKyAgICB9CisKKyAgICBsb2dnZXIgPSB4dGxfY3JlYXRlbG9nZ2VyX3N0ZGlvc3Ry
ZWFtKHN0ZGVyciwgbWlubXNnbGV2ZWwsICAwKTsKKyAgICBpZiAoIWxvZ2dlcikgZXhpdCgxKTsK
KworICAgIGlmIChsaWJ4bF9jdHhfYWxsb2MoJmN0eCwgTElCWExfVkVSU0lPTiwgMCwgKHhlbnRv
b2xsb2dfbG9nZ2VyKilsb2dnZXIpKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiY2Fubm90
IGluaXQgeGxkZXZpY2VkIGNvbnRleHRcbiIpOworICAgICAgICBleGl0KDEpOworICAgIH0KKwor
ICAgIGlmIChkYWVtb25pemUpIHsKKyAgICAgICAgY2hhciAqZnVsbG5hbWU7CisgICAgICAgIHBp
ZF90IGNoaWxkMSwgZ290X2NoaWxkOworICAgICAgICBpbnQgbnVsbGZkOworCisgICAgICAgIGNo
aWxkMSA9IGxpYnhsX2ZvcmsoY3R4KTsKKyAgICAgICAgaWYgKGNoaWxkMSkgeworCisgICAgICAg
ICAgICBmb3IgKDs7KSB7CisgICAgICAgICAgICAgICAgZ290X2NoaWxkID0gd2FpdHBpZChjaGls
ZDEsICZzdGF0dXMsIDApOworICAgICAgICAgICAgICAgIGlmIChnb3RfY2hpbGQgPT0gY2hpbGQx
KSBicmVhazsKKyAgICAgICAgICAgICAgICBhc3NlcnQoZ290X2NoaWxkID09IC0xKTsKKyAgICAg
ICAgICAgICAgICBpZiAoZXJybm8gIT0gRUlOVFIpIHsKKyAgICAgICAgICAgICAgICAgICAgcGVy
cm9yKCJmYWlsZWQgdG8gd2FpdCBmb3IgZGFlbW9uaXppbmcgY2hpbGQiKTsKKyAgICAgICAgICAg
ICAgICAgICAgcmV0ID0gRVJST1JfRkFJTDsKKyAgICAgICAgICAgICAgICAgICAgZ290byBvdXQ7
CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgfQorICAgICAgICAgICAgaWYgKHN0YXR1
cykgeworICAgICAgICAgICAgICAgIGxpYnhsX3JlcG9ydF9jaGlsZF9leGl0c3RhdHVzKGN0eCwg
WFRMX0VSUk9SLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgImRhZW1vbml6aW5nIGNoaWxk
IiwgY2hpbGQxLCBzdGF0dXMpOworICAgICAgICAgICAgICAgIHJldCA9IEVSUk9SX0ZBSUw7Cisg
ICAgICAgICAgICAgICAgZ290byBvdXQ7CisgICAgICAgICAgICB9CisgICAgICAgICAgICByZXQg
PSAwOworICAgICAgICAgICAgZ290byBvdXQ7CisgICAgICAgIH0KKworICAgICAgICByYyA9IGxp
YnhsX2N0eF9wb3N0Zm9yayhjdHgpOworICAgICAgICBpZiAocmMpIHsKKyAgICAgICAgICAgIExP
RygiZmFpbGVkIHRvIHJlaW5pdGlhbGlzZSBjb250ZXh0IGFmdGVyIGZvcmsiKTsKKyAgICAgICAg
ICAgIGV4aXQoLTEpOworICAgICAgICB9CisKKyAgICAgICAgcmMgPSBsaWJ4bF9jcmVhdGVfbG9n
ZmlsZShjdHgsIGxvZ2ZpbGVuYW1lLCAmZnVsbG5hbWUpOworICAgICAgICBpZiAocmMpIHsKKyAg
ICAgICAgICAgIExPRygiZmFpbGVkIHRvIG9wZW4gbG9nZmlsZSAlczogJXMiLGZ1bGxuYW1lLHN0
cmVycm9yKGVycm5vKSk7CisgICAgICAgICAgICBleGl0KC0xKTsKKyAgICAgICAgfQorCisgICAg
ICAgIENIS19FUlJOTygoIGxvZ2ZpbGUgPSBvcGVuKGZ1bGxuYW1lLCBPX1dST05MWXxPX0NSRUFU
fE9fQVBQRU5ELAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwNjQ0KSApPDAp
OworICAgICAgICBmcmVlKGZ1bGxuYW1lKTsKKworICAgICAgICBDSEtfRVJSTk8oKCBudWxsZmQg
PSBvcGVuKCIvZGV2L251bGwiLCBPX1JET05MWSkgKTwwKTsKKyAgICAgICAgZHVwMihudWxsZmQs
IDApOworICAgICAgICBkdXAyKGxvZ2ZpbGUsIDEpOworICAgICAgICBkdXAyKGxvZ2ZpbGUsIDIp
OworCisgICAgICAgIENIS19FUlJOTyhkYWVtb24oMCwgMSkgPCAwKTsKKyAgICB9CisgICAgLyog
V3JpdGUgcGlkICovCisgICAgaWYgKGNyZWF0ZV9waWRmaWxlKHBpZGZpbGUpIDwgMCkgeworICAg
ICAgICBMT0coInVuYWJsZSB0byB3cml0ZSBwaWQgdG8gJXMiLCBwaWRmaWxlKTsKKyAgICAgICAg
Z290byBvdXRfY2xlYW47CisgICAgfQorCisgICAgLyogV2F0Y2ggL2hvdHBsdWcvPG15X2RvbV9p
ZD4gZm9yIGNoYW5nZXMgKi8KKyAgICByZXQgPSBsaWJ4bF9zZXR1cF9ob3RwbHVnX2xpc3RlbmVy
KGN0eCk7CisgICAgaWYgKHJldCA8IDApIHsKKyAgICAgICAgTE9HKCJGYWlsZWQgdG8gc2V0dXAg
eGVuc3RvcmUgd2F0Y2hlcyIpOworICAgICAgICBnb3RvIG91dF9jbGVhbjsKKyAgICB9CisKKyAg
ICByZXQgPSBsaWJ4bF9ob3RwbHVnX2Rpc3BhdGNoKGN0eCwgJmRpc2tfaGFuZGxlciwgJm5pY19o
YW5kbGVyKTsKKworb3V0X2NsZWFuOgorICAgIHVubGluayhwaWRmaWxlKTsKK291dDoKKyAgICBs
aWJ4bF9jdHhfZnJlZShjdHgpOworICAgIHh0bF9sb2dnZXJfZGVzdHJveSgoeGVudG9vbGxvZ19s
b2dnZXIqKWxvZ2dlcik7CisgICAgcmV0dXJuIHJldDsKK30KKworLyoKKyAqIExvY2FsIHZhcmlh
YmxlczoKKyAqIG1vZGU6IEMKKyAqIGMtYmFzaWMtb2Zmc2V0OiA0CisgKiBpbmRlbnQtdGFicy1t
b2RlOiBuaWwKKyAqIEVuZDoKKyAqLwpkaWZmIC1yIDk0NTMyMTk5ZjY0NyAtciBlOTA0Zjk4YTQ0
NDUgdG9vbHMvbGlieGwveGxkZXZpY2VkLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwveGxkZXZpY2VkLmgJVGh1IEZlYiAwMiAx
MTo1MTo0OSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNjIgQEAKKy8qCisgKiBDb3B5cmlnaHQgKEMp
IDIwMTIKKyAqIEF1dGhvciBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAZW50ZWwudXBjLmVk
dT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3Ry
aWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg
TGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkCisgKiBieSB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyB2ZXJzaW9uIDIuMSBvbmx5LiB3aXRoIHRoZSBzcGVjaWFs
CisgKiBleGNlcHRpb24gb24gbGlua2luZyBkZXNjcmliZWQgaW4gZmlsZSBMSUNFTlNFLgorICoK
KyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBB
IFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorICovCisKKyNpZm5kZWYgWExERVZJQ0VEX0gK
KyNkZWZpbmUgWExERVZJQ0VEX0gKKworI2luY2x1ZGUgInhlbnRvb2xsb2cuaCIKKworZXh0ZXJu
IGxpYnhsX2N0eCAqY3R4OworZXh0ZXJuIHhlbnRvb2xsb2dfbG9nZ2VyX3N0ZGlvc3RyZWFtICps
b2dnZXI7CitpbnQgbG9nZmlsZSA9IDI7CisKKyNkZWZpbmUgUElERklMRSAiL3Zhci9ydW4veGxk
ZXZpY2VkLnBpZCIKKworI2RlZmluZSBMT0coX2YsIF9hLi4uKSAgIGRvbG9nKF9fRklMRV9fLCBf
X0xJTkVfXywgX19mdW5jX18sIF9mICJcbiIsICMjX2EpCisKK3N0YXRpYyB2b2lkIGRvbG9nKGNv
bnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBjb25zdCBjaGFyICpmdW5jLCBjaGFyICpmbXQsIC4u
LikKKyAgICAgX19hdHRyaWJ1dGVfXygoZm9ybWF0KHByaW50Ziw0LDUpKSk7CisKK3N0YXRpYyB2
b2lkIGRvbG9nKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBjb25zdCBjaGFyICpmdW5jLCBj
aGFyICpmbXQsIC4uLikKK3sKKyAgICB2YV9saXN0IGFwOworICAgIGNoYXIgKnM7CisgICAgaW50
IHJjOworCisgICAgdmFfc3RhcnQoYXAsIGZtdCk7CisgICAgcmMgPSB2YXNwcmludGYoJnMsIGZt
dCwgYXApOworICAgIHZhX2VuZChhcCk7CisgICAgaWYgKHJjID49IDApCisgICAgICAgIGxpYnhs
X3dyaXRlX2V4YWN0bHkoTlVMTCwgbG9nZmlsZSwgcywgcmMsIE5VTEwsIE5VTEwpOworfQorCisj
ZGVmaW5lIENIS19FUlJOTyggY2FsbCApICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgIGludCBjaGtfZXJybm8gPSAoY2FsbCk7ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIGlmIChjaGtfZXJybm8g
PCAwKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg
ICAgICAgICBmcHJpbnRmKHN0ZGVyciwieGw6IGZhdGFsIGVycm9yOiAlczolZDogJXM6ICVzXG4i
LCAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgIF9fRklMRV9fLF9fTElORV9fLCBzdHJl
cnJvcihjaGtfZXJybm8pLCAjY2FsbCk7ICAgICBcCisgICAgICAgICAgICBleGl0KC1FUlJPUl9G
QUlMKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAg
IH0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCisgICAgfSkKKworI2VuZGlmIC8qIFhMREVWSUNFRF9IICovCisKKy8qCisgKiBM
b2NhbCB2YXJpYWJsZXM6CisgKiBtb2RlOiBDCisgKiBjLWJhc2ljLW9mZnNldDogNAorICogaW5k
ZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1RswuE-000553-Cg; Thu, 02 Feb 2012 13:40:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuB-00050I-VC
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:52 +0000
Received: from [85.158.138.51:30077] by server-5.bemta-3.messagelabs.com id
	B8/1A-25695-3629A2F4; Thu, 02 Feb 2012 13:40:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!13
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22909 invoked from network); 2 Feb 2012 13:40:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:50 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=snZ7/VSdbaL8u+HGjtPRpTNlEpBD1zyiy8c86tCUWb0=;
	b=cVBKUNJr9dYgQX7Lxfw3rK36jUPas0heZed5BdnHrzk7NGsFpUJuoe0WI4Im0xk0Og
	asbc2An7hA1xWTfUEogZo4R+SSxXk6Hei3tPyG3ll0Ajsvgxg9sROFRb0x/41G9k6XTM
	O31m0wUKbaQKgwQ8680PXsWw3FkTqWwT7rA8I=
Received: by 10.180.93.132 with SMTP id cu4mr17971754wib.9.1328190049922;
	Thu, 02 Feb 2012 05:40:49 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e904f98a4445fee7489490b5ccc00b7bb62d796d
Message-Id: <e904f98a4445fee74894.1328189221@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:01 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 26 of 29 RFC] xldeviced: new daemon to execute
	hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI4MTc5OTA5IC0zNjAwCiMgTm9kZSBJRCBlOTA0Zjk4YTQ0
NDVmZWU3NDg5NDkwYjVjY2MwMGI3YmI2MmQ3OTZkCiMgUGFyZW50ICA5NDUzMjE5OWY2NDdmYzAz
ODE2ZmM1YWU1MGFiNTNjOGM1YjgwY2Q4CnhsZGV2aWNlZDogbmV3IGRhZW1vbiB0byBleGVjdXRl
IGhvdHBsdWcgc2NyaXB0cwoKVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIHhsZGV2aWNlZCwgYSBuZXcg
ZGFlbW9uIHRoYXQgbW9uaXRvcnMKL2hvdHBsdWcvPGRvbWlkPiBhbmQgaXMgaW4gY2hhcmdlIG9m
IGF0dGFjaGluZyB0aGUgcGFzc2VkIGRldmljZXMgdG8KdGhlIGRlc2lyZWQgRG9tVS4gTWFrZXMg
dXNlIG9mIHRoZSBwcmV2aW91c2x5IGludHJvZHVjZWQgbGlieGwgaG90cGx1ZwpmdW5jdGlvbnMu
CgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1
PgoKZGlmZiAtciA5NDUzMjE5OWY2NDcgLXIgZTkwNGY5OGE0NDQ1IHRvb2xzL2xpYnhsL01ha2Vm
aWxlCi0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlCVRodSBGZWIgMDIgMTE6NDg6MDYgMjAxMiAr
MDEwMAorKysgYi90b29scy9saWJ4bC9NYWtlZmlsZQlUaHUgRmViIDAyIDExOjUxOjQ5IDIwMTIg
KzAxMDAKQEAgLTEzLDcgKzEzLDcgQEAgWExVTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtV2Vycm9y
IC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RoIC1XbWlzc2luZy1kZWNsYXJhdGlvbnMgXAogCS1Xbm8t
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50IC1XZm9ybWF0LW5vbmxpdGVyYWwKLUNGTEFHUyAr
PSAtSS4gLWZQSUMKK0NGTEFHUyArPSAtSS4gLWZQSUMgLWcKIAogaWZlcSAoJChDT05GSUdfTGlu
dXgpLHkpCiBMSUJVVUlEX0xJQlMgKz0gLWx1dWlkCkBAIC02MCwxMiArNjAsMTYgQEAgTElCWExV
X09CSlMgPSBsaWJ4bHVfY2ZnX3kubyBsaWJ4bHVfY2ZnXwogCWxpYnhsdV9kaXNrX2wubyBsaWJ4
bHVfZGlzay5vCiAkKExJQlhMVV9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwp
ICMgRm9yIHhlbnRvb2xsb2cuaAogCi1DTElFTlRTID0geGwgdGVzdGlkbAorQ0xJRU5UUyA9IHhs
IHhsZGV2aWNlZCB0ZXN0aWRsCiAKIFhMX09CSlMgPSB4bC5vIHhsX2NtZGltcGwubyB4bF9jbWR0
YWJsZS5vCiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3Ig
eGVudG9vbGxvZy5oCiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVubGlnaHQp
CiAKK1hMREVWSUNFRF9PQkpTID0geGxkZXZpY2VkLm8KKyQoWExERVZJQ0VEX09CSlMpOiBDRkxB
R1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3IgeGVudG9vbGxvZy5oCiskKFhMREVWSUNF
RF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmxpZ2h0KQorCiB0ZXN0aWRsLm86IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5saWdodCkKIHRlc3Rp
ZGwuYzogbGlieGxfdHlwZXMuaWRsIGdlbnRlc3QucHkgbGlieGwuaCAkKEFVVE9JTkNTKQogCSQo
UFlUSE9OKSBnZW50ZXN0LnB5IGxpYnhsX3R5cGVzLmlkbCB0ZXN0aWRsLmMubmV3CkBAIC0xNDAs
OCArMTQ0LDEyIEBAIGxpYnhsdXRpbC5hOiAkKExJQlhMVV9PQkpTKQogeGw6ICQoWExfT0JKUykg
bGlieGx1dGlsLnNvIGxpYnhlbmxpZ2h0LnNvCiAJJChDQykgJChMREZMQUdTKSAtbyAkQCAkKFhM
X09CSlMpIGxpYnhsdXRpbC5zbyAkKExETElCU19saWJ4ZW5saWdodCkgJChMRExJQlNfbGlieGVu
Y3RybCkgJChBUFBFTkRfTERGTEFHUykKIAoreGxkZXZpY2VkOiAkKFhMREVWSUNFRF9PQkpTKSBs
aWJ4bHV0aWwuc28gbGlieGVubGlnaHQuc28KKwkkKENDKSAkKExERkxBR1MpIC1vICRAICQoWExE
RVZJQ0VEX09CSlMpIGxpYnhsdXRpbC5zbyAkKExETElCU19saWJ4ZW5saWdodCkgJChMRExJQlNf
bGlieGVuY3RybCkgJChBUFBFTkRfTERGTEFHUykKKwogdGVzdGlkbDogdGVzdGlkbC5vIGxpYnhs
dXRpbC5zbyBsaWJ4ZW5saWdodC5zbwogCSQoQ0MpICQoTERGTEFHUykgLW8gJEAgdGVzdGlkbC5v
IGxpYnhsdXRpbC5zbyAkKExETElCU19saWJ4ZW5saWdodCkgJChMRExJQlNfbGlieGVuY3RybCkg
JChBUFBFTkRfTERGTEFHUykKKyAgICAKIAogLlBIT05ZOiBpbnN0YWxsCiBpbnN0YWxsOiBhbGwK
QEAgLTE1MSw2ICsxNTksNyBAQCBpbnN0YWxsOiBhbGwKIAkkKElOU1RBTExfRElSKSAkKERFU1RE
SVIpJChCQVNIX0NPTVBMRVRJT05fRElSKQogCSQoSU5TVEFMTF9ESVIpICQoREVTVERJUikkKFhF
Tl9SVU5fRElSKQogCSQoSU5TVEFMTF9QUk9HKSB4bCAkKERFU1RESVIpJChTQklORElSKQorCSQo
SU5TVEFMTF9QUk9HKSB4bGRldmljZWQgJChERVNURElSKSQoU0JJTkRJUikKIAkkKElOU1RBTExf
UFJPRykgbGlieGVubGlnaHQuc28uJChNQUpPUikuJChNSU5PUikgJChERVNURElSKSQoTElCRElS
KQogCWxuIC1zZiBsaWJ4ZW5saWdodC5zby4kKE1BSk9SKS4kKE1JTk9SKSAkKERFU1RESVIpJChM
SUJESVIpL2xpYnhlbmxpZ2h0LnNvLiQoTUFKT1IpCiAJbG4gLXNmIGxpYnhlbmxpZ2h0LnNvLiQo
TUFKT1IpICQoREVTVERJUikkKExJQkRJUikvbGlieGVubGlnaHQuc28KZGlmZiAtciA5NDUzMjE5
OWY2NDcgLXIgZTkwNGY5OGE0NDQ1IHRvb2xzL2xpYnhsL3hsZGV2aWNlZC5jCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL3hsZGV2
aWNlZC5jCVRodSBGZWIgMDIgMTE6NTE6NDkgMjAxMiArMDEwMApAQCAtMCwwICsxLDE4NyBAQAor
LyoKKyAqIENvcHlyaWdodCAoQykgMjAxMgorICogQXV0aG9yIFJvZ2VyIFBhdSBNb25uw6kgPHJv
Z2VyLnBhdUBlbnRlbC51cGMuZWR1PgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3
YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJs
aXNoZWQKKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IHZlcnNpb24gMi4xIG9u
bHkuIHdpdGggdGhlIHNwZWNpYWwKKyAqIGV4Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBp
biBmaWxlIExJQ0VOU0UuCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRo
ZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFO
VFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklM
SVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05V
IExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKi8KKwor
I2luY2x1ZGUgImxpYnhsX29zZGVwcy5oIgorCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVk
ZSA8dW5pc3RkLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+
CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPGFz
c2VydC5oPgorCisjaW5jbHVkZSA8eGVuY3RybC5oPgorI2luY2x1ZGUgPHhzLmg+CisKKyNpbmNs
dWRlICJsaWJ4bC5oIgorI2luY2x1ZGUgImxpYnhsX3V0aWxzLmgiCisjaW5jbHVkZSAibGlieGx1
dGlsLmgiCisjaW5jbHVkZSAieGxkZXZpY2VkLmgiCisKK3hlbnRvb2xsb2dfbG9nZ2VyX3N0ZGlv
c3RyZWFtICpsb2dnZXI7CitsaWJ4bF9jdHggKmN0eDsKKworc3RhdGljIHhlbnRvb2xsb2dfbGV2
ZWwgbWlubXNnbGV2ZWwgPSBYVExfUFJPR1JFU1M7CitzdHJ1Y3QgeHNfaGFuZGxlICp4czsKKwor
bGlieGxfZGV2aWNlX2Rpc2tfaG90cGx1Z19hY3Rpb25zIGRpc2tfaGFuZGxlciA9IHsKKyAgICAu
Y29ubmVjdCA9IGxpYnhsX2RldmljZV9kaXNrX2FkZCwKKyAgICAuZGlzY29ubmVjdCA9IGxpYnhs
X2RldmljZV9kaXNrX3JlbW92ZSwKKyAgICAuZm9yY2VfZGlzY29ubmVjdCA9IGxpYnhsX2Rldmlj
ZV9kaXNrX2Rlc3Ryb3ksCit9OworCitsaWJ4bF9kZXZpY2VfbmljX2hvdHBsdWdfYWN0aW9ucyBu
aWNfaGFuZGxlciA9IHsKKyAgICAuY29ubmVjdCA9IGxpYnhsX2RldmljZV9uaWNfYWRkLAorICAg
IC5kaXNjb25uZWN0ID0gbGlieGxfZGV2aWNlX25pY19yZW1vdmUsCisgICAgLmZvcmNlX2Rpc2Nv
bm5lY3QgPSBsaWJ4bF9kZXZpY2VfbmljX2Rlc3Ryb3ksCit9OworCitzdGF0aWMgaW50IGNyZWF0
ZV9waWRmaWxlKGNoYXIgKmZpbGUpCit7CisgICAgcGlkX3QgcGlkOworICAgIGludCByYywgZmQ7
CisgICAgY2hhciAqczsKKworICAgIGZkID0gb3BlbihmaWxlLCBPX1dST05MWXxPX0NSRUFUfE9f
VFJVTkMsIFNfSVJVU1J8U19JV1VTUik7CisgICAgaWYgKGZkIDwgMCkgeworICAgICAgICBMT0co
InVuYWJsZSB0byBvcGVuIHBpZGZpbGUgJXMiLCBmaWxlKTsKKyAgICAgICAgcmV0dXJuIC0xOwor
ICAgIH0KKyAgICBwaWQgPSBnZXRwaWQoKTsKKyAgICByYyA9IGFzcHJpbnRmKCZzLCAiJWRcbiIs
IHBpZCk7CisgICAgaWYgKHJjIDwgMCkKKyAgICAgICAgcmV0dXJuIC0xOworICAgIGxpYnhsX3dy
aXRlX2V4YWN0bHkoTlVMTCwgZmQsIHMsIHJjLCBOVUxMLCBOVUxMKTsKKworICAgIGNsb3NlKGZk
KTsKKyAgICByZXR1cm4gMDsKK30KKworaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQor
eworICAgIGludCBvcHQgPSAwOworICAgIGludCBkYWVtb25pemUgPSAxOworICAgIGludCBzdGF0
dXMsIHJjID0gMCwgcmV0ID0gMDsKKyAgICBjaGFyICpsb2dmaWxlbmFtZSA9ICJ4bGRldmljZWQi
OworICAgIGNoYXIgKnBpZGZpbGUgPSBQSURGSUxFOworICAgIGludCBsb2dmaWxlOworCisgICAg
d2hpbGUgKChvcHQgPSBnZXRvcHQoYXJnYywgYXJndiwgIit2ZnA6IikpID49IDApIHsKKyAgICAg
ICAgc3dpdGNoIChvcHQpIHsKKyAgICAgICAgY2FzZSAndic6CisgICAgICAgICAgICBpZiAobWlu
bXNnbGV2ZWwgPiAwKSBtaW5tc2dsZXZlbC0tOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAg
IGNhc2UgJ2YnOgorICAgICAgICAgICAgZGFlbW9uaXplID0gMDsKKyAgICAgICAgICAgIGJyZWFr
OworICAgICAgICBjYXNlICdwJzoKKyAgICAgICAgICAgIHBpZGZpbGUgPSBvcHRhcmc7CisgICAg
ICAgICAgICBicmVhazsKKyAgICAgICAgZGVmYXVsdDoKKyAgICAgICAgICAgIGZwcmludGYoc3Rk
ZXJyLCAidW5rbm93biBnbG9iYWwgb3B0aW9uXG4iKTsKKyAgICAgICAgICAgIGV4aXQoMik7Cisg
ICAgICAgIH0KKyAgICB9CisKKyAgICBsb2dnZXIgPSB4dGxfY3JlYXRlbG9nZ2VyX3N0ZGlvc3Ry
ZWFtKHN0ZGVyciwgbWlubXNnbGV2ZWwsICAwKTsKKyAgICBpZiAoIWxvZ2dlcikgZXhpdCgxKTsK
KworICAgIGlmIChsaWJ4bF9jdHhfYWxsb2MoJmN0eCwgTElCWExfVkVSU0lPTiwgMCwgKHhlbnRv
b2xsb2dfbG9nZ2VyKilsb2dnZXIpKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiY2Fubm90
IGluaXQgeGxkZXZpY2VkIGNvbnRleHRcbiIpOworICAgICAgICBleGl0KDEpOworICAgIH0KKwor
ICAgIGlmIChkYWVtb25pemUpIHsKKyAgICAgICAgY2hhciAqZnVsbG5hbWU7CisgICAgICAgIHBp
ZF90IGNoaWxkMSwgZ290X2NoaWxkOworICAgICAgICBpbnQgbnVsbGZkOworCisgICAgICAgIGNo
aWxkMSA9IGxpYnhsX2ZvcmsoY3R4KTsKKyAgICAgICAgaWYgKGNoaWxkMSkgeworCisgICAgICAg
ICAgICBmb3IgKDs7KSB7CisgICAgICAgICAgICAgICAgZ290X2NoaWxkID0gd2FpdHBpZChjaGls
ZDEsICZzdGF0dXMsIDApOworICAgICAgICAgICAgICAgIGlmIChnb3RfY2hpbGQgPT0gY2hpbGQx
KSBicmVhazsKKyAgICAgICAgICAgICAgICBhc3NlcnQoZ290X2NoaWxkID09IC0xKTsKKyAgICAg
ICAgICAgICAgICBpZiAoZXJybm8gIT0gRUlOVFIpIHsKKyAgICAgICAgICAgICAgICAgICAgcGVy
cm9yKCJmYWlsZWQgdG8gd2FpdCBmb3IgZGFlbW9uaXppbmcgY2hpbGQiKTsKKyAgICAgICAgICAg
ICAgICAgICAgcmV0ID0gRVJST1JfRkFJTDsKKyAgICAgICAgICAgICAgICAgICAgZ290byBvdXQ7
CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgfQorICAgICAgICAgICAgaWYgKHN0YXR1
cykgeworICAgICAgICAgICAgICAgIGxpYnhsX3JlcG9ydF9jaGlsZF9leGl0c3RhdHVzKGN0eCwg
WFRMX0VSUk9SLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgImRhZW1vbml6aW5nIGNoaWxk
IiwgY2hpbGQxLCBzdGF0dXMpOworICAgICAgICAgICAgICAgIHJldCA9IEVSUk9SX0ZBSUw7Cisg
ICAgICAgICAgICAgICAgZ290byBvdXQ7CisgICAgICAgICAgICB9CisgICAgICAgICAgICByZXQg
PSAwOworICAgICAgICAgICAgZ290byBvdXQ7CisgICAgICAgIH0KKworICAgICAgICByYyA9IGxp
YnhsX2N0eF9wb3N0Zm9yayhjdHgpOworICAgICAgICBpZiAocmMpIHsKKyAgICAgICAgICAgIExP
RygiZmFpbGVkIHRvIHJlaW5pdGlhbGlzZSBjb250ZXh0IGFmdGVyIGZvcmsiKTsKKyAgICAgICAg
ICAgIGV4aXQoLTEpOworICAgICAgICB9CisKKyAgICAgICAgcmMgPSBsaWJ4bF9jcmVhdGVfbG9n
ZmlsZShjdHgsIGxvZ2ZpbGVuYW1lLCAmZnVsbG5hbWUpOworICAgICAgICBpZiAocmMpIHsKKyAg
ICAgICAgICAgIExPRygiZmFpbGVkIHRvIG9wZW4gbG9nZmlsZSAlczogJXMiLGZ1bGxuYW1lLHN0
cmVycm9yKGVycm5vKSk7CisgICAgICAgICAgICBleGl0KC0xKTsKKyAgICAgICAgfQorCisgICAg
ICAgIENIS19FUlJOTygoIGxvZ2ZpbGUgPSBvcGVuKGZ1bGxuYW1lLCBPX1dST05MWXxPX0NSRUFU
fE9fQVBQRU5ELAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwNjQ0KSApPDAp
OworICAgICAgICBmcmVlKGZ1bGxuYW1lKTsKKworICAgICAgICBDSEtfRVJSTk8oKCBudWxsZmQg
PSBvcGVuKCIvZGV2L251bGwiLCBPX1JET05MWSkgKTwwKTsKKyAgICAgICAgZHVwMihudWxsZmQs
IDApOworICAgICAgICBkdXAyKGxvZ2ZpbGUsIDEpOworICAgICAgICBkdXAyKGxvZ2ZpbGUsIDIp
OworCisgICAgICAgIENIS19FUlJOTyhkYWVtb24oMCwgMSkgPCAwKTsKKyAgICB9CisgICAgLyog
V3JpdGUgcGlkICovCisgICAgaWYgKGNyZWF0ZV9waWRmaWxlKHBpZGZpbGUpIDwgMCkgeworICAg
ICAgICBMT0coInVuYWJsZSB0byB3cml0ZSBwaWQgdG8gJXMiLCBwaWRmaWxlKTsKKyAgICAgICAg
Z290byBvdXRfY2xlYW47CisgICAgfQorCisgICAgLyogV2F0Y2ggL2hvdHBsdWcvPG15X2RvbV9p
ZD4gZm9yIGNoYW5nZXMgKi8KKyAgICByZXQgPSBsaWJ4bF9zZXR1cF9ob3RwbHVnX2xpc3RlbmVy
KGN0eCk7CisgICAgaWYgKHJldCA8IDApIHsKKyAgICAgICAgTE9HKCJGYWlsZWQgdG8gc2V0dXAg
eGVuc3RvcmUgd2F0Y2hlcyIpOworICAgICAgICBnb3RvIG91dF9jbGVhbjsKKyAgICB9CisKKyAg
ICByZXQgPSBsaWJ4bF9ob3RwbHVnX2Rpc3BhdGNoKGN0eCwgJmRpc2tfaGFuZGxlciwgJm5pY19o
YW5kbGVyKTsKKworb3V0X2NsZWFuOgorICAgIHVubGluayhwaWRmaWxlKTsKK291dDoKKyAgICBs
aWJ4bF9jdHhfZnJlZShjdHgpOworICAgIHh0bF9sb2dnZXJfZGVzdHJveSgoeGVudG9vbGxvZ19s
b2dnZXIqKWxvZ2dlcik7CisgICAgcmV0dXJuIHJldDsKK30KKworLyoKKyAqIExvY2FsIHZhcmlh
YmxlczoKKyAqIG1vZGU6IEMKKyAqIGMtYmFzaWMtb2Zmc2V0OiA0CisgKiBpbmRlbnQtdGFicy1t
b2RlOiBuaWwKKyAqIEVuZDoKKyAqLwpkaWZmIC1yIDk0NTMyMTk5ZjY0NyAtciBlOTA0Zjk4YTQ0
NDUgdG9vbHMvbGlieGwveGxkZXZpY2VkLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwveGxkZXZpY2VkLmgJVGh1IEZlYiAwMiAx
MTo1MTo0OSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNjIgQEAKKy8qCisgKiBDb3B5cmlnaHQgKEMp
IDIwMTIKKyAqIEF1dGhvciBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAZW50ZWwudXBjLmVk
dT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3Ry
aWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg
TGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkCisgKiBieSB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyB2ZXJzaW9uIDIuMSBvbmx5LiB3aXRoIHRoZSBzcGVjaWFs
CisgKiBleGNlcHRpb24gb24gbGlua2luZyBkZXNjcmliZWQgaW4gZmlsZSBMSUNFTlNFLgorICoK
KyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBB
IFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorICovCisKKyNpZm5kZWYgWExERVZJQ0VEX0gK
KyNkZWZpbmUgWExERVZJQ0VEX0gKKworI2luY2x1ZGUgInhlbnRvb2xsb2cuaCIKKworZXh0ZXJu
IGxpYnhsX2N0eCAqY3R4OworZXh0ZXJuIHhlbnRvb2xsb2dfbG9nZ2VyX3N0ZGlvc3RyZWFtICps
b2dnZXI7CitpbnQgbG9nZmlsZSA9IDI7CisKKyNkZWZpbmUgUElERklMRSAiL3Zhci9ydW4veGxk
ZXZpY2VkLnBpZCIKKworI2RlZmluZSBMT0coX2YsIF9hLi4uKSAgIGRvbG9nKF9fRklMRV9fLCBf
X0xJTkVfXywgX19mdW5jX18sIF9mICJcbiIsICMjX2EpCisKK3N0YXRpYyB2b2lkIGRvbG9nKGNv
bnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBjb25zdCBjaGFyICpmdW5jLCBjaGFyICpmbXQsIC4u
LikKKyAgICAgX19hdHRyaWJ1dGVfXygoZm9ybWF0KHByaW50Ziw0LDUpKSk7CisKK3N0YXRpYyB2
b2lkIGRvbG9nKGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lLCBjb25zdCBjaGFyICpmdW5jLCBj
aGFyICpmbXQsIC4uLikKK3sKKyAgICB2YV9saXN0IGFwOworICAgIGNoYXIgKnM7CisgICAgaW50
IHJjOworCisgICAgdmFfc3RhcnQoYXAsIGZtdCk7CisgICAgcmMgPSB2YXNwcmludGYoJnMsIGZt
dCwgYXApOworICAgIHZhX2VuZChhcCk7CisgICAgaWYgKHJjID49IDApCisgICAgICAgIGxpYnhs
X3dyaXRlX2V4YWN0bHkoTlVMTCwgbG9nZmlsZSwgcywgcmMsIE5VTEwsIE5VTEwpOworfQorCisj
ZGVmaW5lIENIS19FUlJOTyggY2FsbCApICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgIGludCBjaGtfZXJybm8gPSAoY2FsbCk7ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIGlmIChjaGtfZXJybm8g
PCAwKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg
ICAgICAgICBmcHJpbnRmKHN0ZGVyciwieGw6IGZhdGFsIGVycm9yOiAlczolZDogJXM6ICVzXG4i
LCAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgIF9fRklMRV9fLF9fTElORV9fLCBzdHJl
cnJvcihjaGtfZXJybm8pLCAjY2FsbCk7ICAgICBcCisgICAgICAgICAgICBleGl0KC1FUlJPUl9G
QUlMKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAg
IH0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCisgICAgfSkKKworI2VuZGlmIC8qIFhMREVWSUNFRF9IICovCisKKy8qCisgKiBM
b2NhbCB2YXJpYWJsZXM6CisgKiBtb2RlOiBDCisgKiBjLWJhc2ljLW9mZnNldDogNAorICogaW5k
ZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1RswuF-00056b-36; Thu, 02 Feb 2012 13:40:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuD-00052b-Ca
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328189992!50820476!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18961 invoked from network); 2 Feb 2012 13:40:15 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:15 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr13so2336011wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zDv9D8EIDaPmr9vcONQZBsSoHI5Ib91Y6s726BWexYQ=;
	b=rDylHZ2s80epEs3HT+7iqJtiB6p3Kcs5lz1VpOYwonScslmb77qvY8mbAvPCZtn9Z+
	XUlfXOLxUPs5PvWGuvxnI0d3MScV/+/oXFggRP8Fny7DLc2k9cJmhX1GfvaNumdNZJYb
	4CehXEKArmXt8hiMHfJm4oQ7AH6Ql3Vi6b7vM=
Received: by 10.181.12.106 with SMTP id ep10mr17960555wid.8.1328190051829;
	Thu, 02 Feb 2012 05:40:51 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 42bd734ce75d232194372c329a9af9b73e9090fb
Message-Id: <42bd734ce75d23219437.1328189222@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:02 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 27 of 29 RFC] init: updated Linux and NetBSD
 init scripts to launch xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328180098 -3600
# Node ID 42bd734ce75d232194372c329a9af9b73e9090fb
# Parent  e904f98a4445fee7489490b5ccc00b7bb62d796d
init: updated Linux and NetBSD init scripts to launch xldeviced

Updated both init scripts to launch xldeviced when starting
xencommons.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e904f98a4445 -r 42bd734ce75d tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 02 11:51:49 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Thu Feb 02 11:54:58 2012 +0100
@@ -27,6 +27,7 @@ fi
 test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
 
 XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid
+XLDEVICED_PIDFILE=/var/run/xldeviced.pid
 shopt -s extglob
 
 # not running in Xen dom0 or domU
@@ -95,13 +96,16 @@ do_start () {
 
 		echo Setting domain 0 name...
 		xenstore-write "/local/domain/0/name" "Domain-0"
+		echo Setting domain 0 id...
+		xenstore-write "/local/domain/0/domid" "0"
 	fi
 
 	echo Starting xenconsoled...
 	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
-	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
-	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting xldeviced...
+	test -z "$XLDEVICED_DEBUG" || XLDEVICED_ARGS="-vvv"
+	xldeviced -p $XLDEVICED_PIDFILE $XLDEVICED_ARGS
 }
 do_stop () {
         echo Stopping xenconsoled
@@ -110,7 +114,12 @@ do_stop () {
 		while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
 		rm -f $XENCONSOLED_PIDFILE
 	fi
-
+	echo Stopping xldeviced
+	if read 2>/dev/null <$XLDEVICED_PIDFILE pid; then
+		kill $pid
+		while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
+		rm -f $XLDEVICED_PIDFILE
+	fi
 	echo WARNING: Not stopping xenstored, as it cannot be restarted.
 }
 
diff -r e904f98a4445 -r 42bd734ce75d tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Thu Feb 02 11:51:49 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Thu Feb 02 11:54:58 2012 +0100
@@ -22,6 +22,7 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
+XLDEVICED_PIDFILE="/var/run/xldeviced.pid"
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -42,7 +43,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled."
+		printf "Starting xenservices: xenstored, xenconsoled, xldeviced."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -54,7 +55,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled."
+		printf "Starting xenservices: xenconsoled, xldeviced."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -63,21 +64,26 @@ xen_startcmd()
 	fi
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
+	${SBINDIR}/xldeviced -p ${XLDEVICED_PIDFILE}
 
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
 	${BINDIR}/xenstore-write "/local/domain/0/name" "Domain-0"
+	printf "Setting domain 0 id.\n"
+	${BINDIR}/xenstore-write "/local/domain/0/domid" "0"
 }
 
 xen_stop()
 {
 	pids=""
-	printf "Stopping xencommons.\n"
+	printf "Stopping xencommons, xldeviced.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
+	rc_pid=$(check_pidfile ${XLDEVICED_PIDFILE} ${SBINDIR}/xldeviced)
+	pids="$pids $rc_pid"
 
 	kill -${sig_stop:-TERM} $pids
 	wait_for_pids $pids
@@ -95,12 +101,17 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	xldeviced_pid=$(check_pidfile ${XLDEVICED_PIDFILE} ${SBINDIR}/xldeviced)
+	if test -n ${xldeviced_pid}; then
+		pids="$pids $xldeviced_pid"
+	fi
+
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid" -a -n "$xldeviced_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid" -a -z "$xldeviced_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -116,6 +127,11 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
+	if test -n $xldeviced_pid; then
+		echo "xldeviced is running as pid $xldeviced_pid."
+	else
+		echo "xldeviced is not running."
+	fi
 }
 
 load_rc_config $name

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1RswuF-00056b-36; Thu, 02 Feb 2012 13:40:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuD-00052b-Ca
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328189992!50820476!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18961 invoked from network); 2 Feb 2012 13:40:15 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:15 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr13so2336011wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zDv9D8EIDaPmr9vcONQZBsSoHI5Ib91Y6s726BWexYQ=;
	b=rDylHZ2s80epEs3HT+7iqJtiB6p3Kcs5lz1VpOYwonScslmb77qvY8mbAvPCZtn9Z+
	XUlfXOLxUPs5PvWGuvxnI0d3MScV/+/oXFggRP8Fny7DLc2k9cJmhX1GfvaNumdNZJYb
	4CehXEKArmXt8hiMHfJm4oQ7AH6Ql3Vi6b7vM=
Received: by 10.181.12.106 with SMTP id ep10mr17960555wid.8.1328190051829;
	Thu, 02 Feb 2012 05:40:51 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 42bd734ce75d232194372c329a9af9b73e9090fb
Message-Id: <42bd734ce75d23219437.1328189222@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:02 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 27 of 29 RFC] init: updated Linux and NetBSD
 init scripts to launch xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328180098 -3600
# Node ID 42bd734ce75d232194372c329a9af9b73e9090fb
# Parent  e904f98a4445fee7489490b5ccc00b7bb62d796d
init: updated Linux and NetBSD init scripts to launch xldeviced

Updated both init scripts to launch xldeviced when starting
xencommons.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r e904f98a4445 -r 42bd734ce75d tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 02 11:51:49 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Thu Feb 02 11:54:58 2012 +0100
@@ -27,6 +27,7 @@ fi
 test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
 
 XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid
+XLDEVICED_PIDFILE=/var/run/xldeviced.pid
 shopt -s extglob
 
 # not running in Xen dom0 or domU
@@ -95,13 +96,16 @@ do_start () {
 
 		echo Setting domain 0 name...
 		xenstore-write "/local/domain/0/name" "Domain-0"
+		echo Setting domain 0 id...
+		xenstore-write "/local/domain/0/domid" "0"
 	fi
 
 	echo Starting xenconsoled...
 	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
 	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
-	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
-	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	echo Starting xldeviced...
+	test -z "$XLDEVICED_DEBUG" || XLDEVICED_ARGS="-vvv"
+	xldeviced -p $XLDEVICED_PIDFILE $XLDEVICED_ARGS
 }
 do_stop () {
         echo Stopping xenconsoled
@@ -110,7 +114,12 @@ do_stop () {
 		while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
 		rm -f $XENCONSOLED_PIDFILE
 	fi
-
+	echo Stopping xldeviced
+	if read 2>/dev/null <$XLDEVICED_PIDFILE pid; then
+		kill $pid
+		while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
+		rm -f $XLDEVICED_PIDFILE
+	fi
 	echo WARNING: Not stopping xenstored, as it cannot be restarted.
 }
 
diff -r e904f98a4445 -r 42bd734ce75d tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Thu Feb 02 11:51:49 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Thu Feb 02 11:54:58 2012 +0100
@@ -22,6 +22,7 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
+XLDEVICED_PIDFILE="/var/run/xldeviced.pid"
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -42,7 +43,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled."
+		printf "Starting xenservices: xenstored, xenconsoled, xldeviced."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -54,7 +55,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled."
+		printf "Starting xenservices: xenconsoled, xldeviced."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -63,21 +64,26 @@ xen_startcmd()
 	fi
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
+	${SBINDIR}/xldeviced -p ${XLDEVICED_PIDFILE}
 
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
 	${BINDIR}/xenstore-write "/local/domain/0/name" "Domain-0"
+	printf "Setting domain 0 id.\n"
+	${BINDIR}/xenstore-write "/local/domain/0/domid" "0"
 }
 
 xen_stop()
 {
 	pids=""
-	printf "Stopping xencommons.\n"
+	printf "Stopping xencommons, xldeviced.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
+	rc_pid=$(check_pidfile ${XLDEVICED_PIDFILE} ${SBINDIR}/xldeviced)
+	pids="$pids $rc_pid"
 
 	kill -${sig_stop:-TERM} $pids
 	wait_for_pids $pids
@@ -95,12 +101,17 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	xldeviced_pid=$(check_pidfile ${XLDEVICED_PIDFILE} ${SBINDIR}/xldeviced)
+	if test -n ${xldeviced_pid}; then
+		pids="$pids $xldeviced_pid"
+	fi
+
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid" -a -n "$xldeviced_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid" -a -z "$xldeviced_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -116,6 +127,11 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
+	if test -n $xldeviced_pid; then
+		echo "xldeviced is running as pid $xldeviced_pid."
+	else
+		echo "xldeviced is not running."
+	fi
 }
 
 load_rc_config $name

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswuJ-0005F3-Ik; Thu, 02 Feb 2012 13:40:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuH-0005At-Pu
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:58 +0000
Received: from [85.158.138.51:30563] by server-7.bemta-3.messagelabs.com id
	50/44-28646-8629A2F4; Thu, 02 Feb 2012 13:40:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!6
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14837 invoked from network); 2 Feb 2012 13:40:55 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:55 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=32tDPt8jwhDQsX5FA3Q3SoJueAoFJyuQs9Lqn+CJGIw=;
	b=pWYfbZbfjD5jl5p/VSpCMg2UXysdSkozETmbZjy3o0rrIb5/Wxk+k0MNV2UTA8QBbB
	0bjk242quZu5w5+7PdDAhe5ffRmCESBcLTmz8CYwwjmtj1yLnSgtP7odNETP8XF+rV4J
	E6lQxB4ydvjW0DLJWE8M4JxNI+OGQY9k3/fxE=
Received: by 10.180.94.68 with SMTP id da4mr4589940wib.22.1328190055742;
	Thu, 02 Feb 2012 05:40:55 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7de94a26474f869177ce16b59b61421bf342f820
Message-Id: <7de94a26474f869177ce.1328189224@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328189192 -3600
# Node ID 7de94a26474f869177ce16b59b61421bf342f820
# Parent  35164add2785b8606c0e9b771206d83862afd2c6
libxl: delegate plug/unplug of disk and nic devices to xldeviced

Change the calls to libxl_device_<type>_<action> to
libxl_device_<type>_hotplug_<action> for disk and nic device types.
Alsoe enables hotplug script calling from libxl itself, by disabling
some udev rules and removing the commented code in
libxl__device_hotplug.

Bootloading is handled attaching the requested device to Dom0 (xvda),
and executing pygrub against that device (/dev/xvda). This should be
fixed in future versions, since xvda might already be in use.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 35164add2785 -r 7de94a26474f tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Thu Feb 02 14:26:32 2012 +0100
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+# SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 14:26:32 2012 +0100
@@ -1714,12 +1714,12 @@ int libxl_cdrom_insert(libxl_ctx *ctx, u
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_hotplug_remove(ctx, domid, disks + i);
+    libxl_device_disk_hotplug_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_hotplug_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_hotplug_add(ctx, stubdomid, disk);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1735,52 +1735,13 @@ char * libxl_device_disk_local_attach(li
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
+    rc = libxl_device_disk_hotplug_add(ctx, 0, disk);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to attach disk %s to Dom0",
+                                          disk->pdev_path);
+        goto out;
     }
+    dev = libxl__sprintf(gc, "/dev/%s", disk->vdev);
 
  out:
     if (dev != NULL)
@@ -1791,14 +1752,17 @@ char * libxl_device_disk_local_attach(li
 
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
+    GC_INIT(ctx);
+    int rc;
+
+    rc = libxl_device_disk_hotplug_destroy(ctx, 0, disk);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to attach disk %s to Dom0",
+                                          disk->pdev_path);
+    }
+
+    GC_FREE;
+    return rc;
 }
 
 /******************************************************************************/
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_create.c	Thu Feb 02 14:26:32 2012 +0100
@@ -500,12 +500,11 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
-
+#if 0
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
-        if (ret) goto error_out;
+        d_config->disks[i].backend = LIBXL_DISK_BACKEND_PHY;
     }
-
+#endif
     if ( restore_fd < 0 ) {
         ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
         if (ret) {
@@ -534,7 +533,7 @@ static int do_domain_create(libxl__gc *g
     store_libxl_entry(gc, domid, dm_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_hotplug_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -543,7 +542,7 @@ static int do_domain_create(libxl__gc *g
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_hotplug_add(ctx, domid, &d_config->vifs[i]);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 14:26:32 2012 +0100
@@ -805,7 +805,20 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                libxl__device_destroy(gc, &dev);
+                switch(dev.kind) {
+                case LIBXL__DEVICE_KIND_VIF:
+                case LIBXL__DEVICE_KIND_VBD:
+                case LIBXL__DEVICE_KIND_QDISK:
+                    libxl__device_hotplug_disconnect(gc, &dev,
+                             HOTPLUG_DEVICE_FORCE_DISCONNECT);
+                    break;
+                case LIBXL__DEVICE_KIND_PCI:
+                case LIBXL__DEVICE_KIND_VFB:
+                case LIBXL__DEVICE_KIND_VKBD:
+                case LIBXL__DEVICE_KIND_CONSOLE:
+                    libxl__device_destroy(gc, &dev);
+                    break;
+                }
             }
         }
     }
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Feb 02 14:26:32 2012 +0100
@@ -674,12 +674,12 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &disks[i]);
+        ret = libxl_device_disk_hotplug_add(ctx, domid, &disks[i]);
         if (ret)
             goto out_free;
     }
     for (i = 0; i < num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &vifs[i]);
+        ret = libxl_device_nic_hotplug_add(ctx, domid, &vifs[i]);
         if (ret)
             goto out_free;
     }
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Thu Feb 02 14:26:32 2012 +0100
@@ -27,7 +27,7 @@ int libxl__try_phy_backend(mode_t st_mod
 }
 
 /* Hotplug scripts helpers */
-#if 0
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -175,12 +175,12 @@ out:
     free(args);
     return rc;
 }
-#endif /* 0 */
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
     int rc = 0;
-#if 0
+
     switch (dev->backend_kind) {
     case LIBXL__DEVICE_KIND_VIF:
         rc = libxl__hotplug_nic(gc, dev, action);
@@ -192,6 +192,6 @@ int libxl__device_hotplug(libxl__gc *gc,
         rc = 0;
         break;
     }
-#endif /* 0 */
+
     return rc;
 }
diff -r 35164add2785 -r 7de94a26474f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 14:26:32 2012 +0100
@@ -4574,7 +4574,7 @@ int main_networkattach(int argc, char **
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_hotplug_add(ctx, domid, &nic)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
@@ -4684,7 +4684,7 @@ int main_blockattach(int argc, char **ar
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_hotplug_add(ctx, fe_domid, &disk)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
@@ -4742,7 +4742,7 @@ int main_blockdetach(int argc, char **ar
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_hotplug_remove(ctx, domid, &disk) < 0) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     return 0;

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswuJ-0005F3-Ik; Thu, 02 Feb 2012 13:40:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuH-0005At-Pu
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:40:58 +0000
Received: from [85.158.138.51:30563] by server-7.bemta-3.messagelabs.com id
	50/44-28646-8629A2F4; Thu, 02 Feb 2012 13:40:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!6
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14837 invoked from network); 2 Feb 2012 13:40:55 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:55 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=32tDPt8jwhDQsX5FA3Q3SoJueAoFJyuQs9Lqn+CJGIw=;
	b=pWYfbZbfjD5jl5p/VSpCMg2UXysdSkozETmbZjy3o0rrIb5/Wxk+k0MNV2UTA8QBbB
	0bjk242quZu5w5+7PdDAhe5ffRmCESBcLTmz8CYwwjmtj1yLnSgtP7odNETP8XF+rV4J
	E6lQxB4ydvjW0DLJWE8M4JxNI+OGQY9k3/fxE=
Received: by 10.180.94.68 with SMTP id da4mr4589940wib.22.1328190055742;
	Thu, 02 Feb 2012 05:40:55 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7de94a26474f869177ce16b59b61421bf342f820
Message-Id: <7de94a26474f869177ce.1328189224@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328189192 -3600
# Node ID 7de94a26474f869177ce16b59b61421bf342f820
# Parent  35164add2785b8606c0e9b771206d83862afd2c6
libxl: delegate plug/unplug of disk and nic devices to xldeviced

Change the calls to libxl_device_<type>_<action> to
libxl_device_<type>_hotplug_<action> for disk and nic device types.
Alsoe enables hotplug script calling from libxl itself, by disabling
some udev rules and removing the commented code in
libxl__device_hotplug.

Bootloading is handled attaching the requested device to Dom0 (xvda),
and executing pygrub against that device (/dev/xvda). This should be
fixed in future versions, since xvda might already be in use.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 35164add2785 -r 7de94a26474f tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Thu Feb 02 14:26:32 2012 +0100
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+# SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Feb 02 14:26:32 2012 +0100
@@ -1714,12 +1714,12 @@ int libxl_cdrom_insert(libxl_ctx *ctx, u
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
-    libxl_device_disk_add(ctx, domid, disk);
+    libxl_device_disk_hotplug_remove(ctx, domid, disks + i);
+    libxl_device_disk_hotplug_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
-        libxl_device_disk_add(ctx, stubdomid, disk);
+        libxl_device_disk_hotplug_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_hotplug_add(ctx, stubdomid, disk);
     }
 out:
     for (i = 0; i < num; i++)
@@ -1735,52 +1735,13 @@ char * libxl_device_disk_local_attach(li
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
-    if (rc) goto out;
-
-    switch (disk->backend) {
-        case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        case LIBXL_DISK_BACKEND_TAP:
-            switch (disk->format) {
-            case LIBXL_DISK_FORMAT_RAW:
-                /* optimise away the early tapdisk attach in this case */
-                LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching"
-                           " tap disk %s directly (ie without using blktap)",
-                           disk->pdev_path);
-                dev = disk->pdev_path;
-                break;
-            case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
-                break;
-            case LIBXL_DISK_FORMAT_QCOW:
-            case LIBXL_DISK_FORMAT_QCOW2:
-                abort(); /* prevented by libxl__device_disk_set_backend */
-            default:
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                           "unrecognized disk format: %d", disk->format);
-                break;
-            }
-            break;
-        case LIBXL_DISK_BACKEND_QDISK:
-            if (disk->format != LIBXL_DISK_FORMAT_RAW) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally"
-                           " attach a qdisk image if the format is not raw");
-                break;
-            }
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
-            break;
-        default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend "
-                "type: %d", disk->backend);
-            break;
+    rc = libxl_device_disk_hotplug_add(ctx, 0, disk);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to attach disk %s to Dom0",
+                                          disk->pdev_path);
+        goto out;
     }
+    dev = libxl__sprintf(gc, "/dev/%s", disk->vdev);
 
  out:
     if (dev != NULL)
@@ -1791,14 +1752,17 @@ char * libxl_device_disk_local_attach(li
 
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk)
 {
-    /* Nothing to do for PHYSTYPE_PHY. */
-
-    /*
-     * For other device types assume that the blktap2 process is
-     * needed by the soon to be started domain and do nothing.
-     */
-
-    return 0;
+    GC_INIT(ctx);
+    int rc;
+
+    rc = libxl_device_disk_hotplug_destroy(ctx, 0, disk);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to attach disk %s to Dom0",
+                                          disk->pdev_path);
+    }
+
+    GC_FREE;
+    return rc;
 }
 
 /******************************************************************************/
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_create.c	Thu Feb 02 14:26:32 2012 +0100
@@ -500,12 +500,11 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
-
+#if 0
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
-        if (ret) goto error_out;
+        d_config->disks[i].backend = LIBXL_DISK_BACKEND_PHY;
     }
-
+#endif
     if ( restore_fd < 0 ) {
         ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid);
         if (ret) {
@@ -534,7 +533,7 @@ static int do_domain_create(libxl__gc *g
     store_libxl_entry(gc, domid, dm_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
+        ret = libxl_device_disk_hotplug_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add disk %d to domain: %d", i, ret);
@@ -543,7 +542,7 @@ static int do_domain_create(libxl__gc *g
         }
     }
     for (i = 0; i < d_config->num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]);
+        ret = libxl_device_nic_hotplug_add(ctx, domid, &d_config->vifs[i]);
         if (ret) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "cannot add nic %d to domain: %d", i, ret);
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 14:26:32 2012 +0100
@@ -805,7 +805,20 @@ int libxl__devices_destroy(libxl__gc *gc
                 dev.kind = kind;
                 dev.devid = atoi(devs[j]);
 
-                libxl__device_destroy(gc, &dev);
+                switch(dev.kind) {
+                case LIBXL__DEVICE_KIND_VIF:
+                case LIBXL__DEVICE_KIND_VBD:
+                case LIBXL__DEVICE_KIND_QDISK:
+                    libxl__device_hotplug_disconnect(gc, &dev,
+                             HOTPLUG_DEVICE_FORCE_DISCONNECT);
+                    break;
+                case LIBXL__DEVICE_KIND_PCI:
+                case LIBXL__DEVICE_KIND_VFB:
+                case LIBXL__DEVICE_KIND_VKBD:
+                case LIBXL__DEVICE_KIND_CONSOLE:
+                    libxl__device_destroy(gc, &dev);
+                    break;
+                }
             }
         }
     }
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Feb 02 14:26:32 2012 +0100
@@ -674,12 +674,12 @@ retry_transaction:
             goto retry_transaction;
 
     for (i = 0; i < num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &disks[i]);
+        ret = libxl_device_disk_hotplug_add(ctx, domid, &disks[i]);
         if (ret)
             goto out_free;
     }
     for (i = 0; i < num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &vifs[i]);
+        ret = libxl_device_nic_hotplug_add(ctx, domid, &vifs[i]);
         if (ret)
             goto out_free;
     }
diff -r 35164add2785 -r 7de94a26474f tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Thu Feb 02 14:26:32 2012 +0100
@@ -27,7 +27,7 @@ int libxl__try_phy_backend(mode_t st_mod
 }
 
 /* Hotplug scripts helpers */
-#if 0
+
 static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -175,12 +175,12 @@ out:
     free(args);
     return rc;
 }
-#endif /* 0 */
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
     int rc = 0;
-#if 0
+
     switch (dev->backend_kind) {
     case LIBXL__DEVICE_KIND_VIF:
         rc = libxl__hotplug_nic(gc, dev, action);
@@ -192,6 +192,6 @@ int libxl__device_hotplug(libxl__gc *gc,
         rc = 0;
         break;
     }
-#endif /* 0 */
+
     return rc;
 }
diff -r 35164add2785 -r 7de94a26474f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 14:25:12 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 14:26:32 2012 +0100
@@ -4574,7 +4574,7 @@ int main_networkattach(int argc, char **
             return 1;
         }
     }
-    if (libxl_device_nic_add(ctx, domid, &nic)) {
+    if (libxl_device_nic_hotplug_add(ctx, domid, &nic)) {
         fprintf(stderr, "libxl_device_nic_add failed.\n");
         return 1;
     }
@@ -4684,7 +4684,7 @@ int main_blockattach(int argc, char **ar
         return 0;
     }
 
-    if (libxl_device_disk_add(ctx, fe_domid, &disk)) {
+    if (libxl_device_disk_hotplug_add(ctx, fe_domid, &disk)) {
         fprintf(stderr, "libxl_device_disk_add failed.\n");
     }
     return 0;
@@ -4742,7 +4742,7 @@ int main_blockdetach(int argc, char **ar
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_hotplug_remove(ctx, domid, &disk) < 0) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     return 0;

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswuL-0005Hg-02; Thu, 02 Feb 2012 13:41:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuK-00055j-2c
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:41:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328189998!58205295!2
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 754 invoked from network); 2 Feb 2012 13:40:25 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:25 -0000
Received: by mail-ww0-f41.google.com with SMTP id dt11so8379970wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=FPU2BEr9Foeuzp6gTNNxazJkPepkIT3QOc+4Eo/iFR0=;
	b=mImLkLYnlTRX+mXeBKN95k6YwsfygWoHKNmlZUoJfLKPIB5NbtVNowyoLwj+qOZMrp
	oqycxL5aAeyY1LrcA1Gl5G+O3h1Ds7P5uhrFhCA8hP4+OEz66DId9iCW3AzTlRdcdVEv
	xcFnoLViw6HR1eGiMVXPqPFvHrV1phpwkAK88=
Received: by 10.180.80.8 with SMTP id n8mr4675019wix.14.1328190053865;
	Thu, 02 Feb 2012 05:40:53 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 35164add2785b8606c0e9b771206d83862afd2c6
Message-Id: <35164add2785b8606c0e.1328189223@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:03 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328189112 -3600
# Node ID 35164add2785b8606c0e9b771206d83862afd2c6
# Parent  42bd734ce75d232194372c329a9af9b73e9090fb
libxl: add libxl__find_free_vdev

Add a function that returns the first free xvd<x> device, used to
attach a DomU image and execute the bootloader against that.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 42bd734ce75d -r 35164add2785 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 02 11:54:58 2012 +0100
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 02 14:25:12 2012 +0100
@@ -318,6 +318,39 @@ static void parse_bootloader_result(libx
     }
 }
 
+static char *libxl__find_free_vdev(libxl__gc *gc)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *vdev;
+    libxl_device_disk *list;
+    int num;
+    int used;
+
+    list = libxl_device_disk_list(ctx, 0, &num);
+    if (!list || num == 0) {
+        return "xvda";
+    }
+
+    for (char device = 'a'; device <= 'z'; device += 1) {
+        used = 0;
+        vdev = libxl__sprintf(gc, "xvd%c", device);
+        if (!vdev) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to allocate memory");
+            return NULL;
+        }
+        for (int i = 0; i < num; i++) {
+            if (strcmp(list[0].vdev, vdev) == 0) {
+                used = 1;
+                break;
+            }
+        }
+        if (!used)
+            return vdev;
+    }
+    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to find a free device");
+    return NULL;
+}
+
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
@@ -328,6 +361,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    char *vdev_save = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -378,6 +412,11 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
+    vdev_save = disk->vdev;
+    disk->vdev = libxl__find_free_vdev(gc);
+    if (!disk->vdev)
+        goto out_close;
+
     diskpath = libxl_device_disk_local_attach(ctx, disk);
     if (!diskpath) {
         goto out_close;
@@ -446,6 +485,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 out_close:
     if (diskpath) {
         libxl_device_disk_local_detach(ctx, disk);
+        if (vdev_save)
+            disk->vdev = vdev_save;
         free(diskpath);
     }
     if (fifo_fd > -1)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswuL-0005Hg-02; Thu, 02 Feb 2012 13:41:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuK-00055j-2c
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:41:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328189998!58205295!2
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 754 invoked from network); 2 Feb 2012 13:40:25 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:40:25 -0000
Received: by mail-ww0-f41.google.com with SMTP id dt11so8379970wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=FPU2BEr9Foeuzp6gTNNxazJkPepkIT3QOc+4Eo/iFR0=;
	b=mImLkLYnlTRX+mXeBKN95k6YwsfygWoHKNmlZUoJfLKPIB5NbtVNowyoLwj+qOZMrp
	oqycxL5aAeyY1LrcA1Gl5G+O3h1Ds7P5uhrFhCA8hP4+OEz66DId9iCW3AzTlRdcdVEv
	xcFnoLViw6HR1eGiMVXPqPFvHrV1phpwkAK88=
Received: by 10.180.80.8 with SMTP id n8mr4675019wix.14.1328190053865;
	Thu, 02 Feb 2012 05:40:53 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 35164add2785b8606c0e9b771206d83862afd2c6
Message-Id: <35164add2785b8606c0e.1328189223@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:27:03 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328189112 -3600
# Node ID 35164add2785b8606c0e9b771206d83862afd2c6
# Parent  42bd734ce75d232194372c329a9af9b73e9090fb
libxl: add libxl__find_free_vdev

Add a function that returns the first free xvd<x> device, used to
attach a DomU image and execute the bootloader against that.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 42bd734ce75d -r 35164add2785 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 02 11:54:58 2012 +0100
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 02 14:25:12 2012 +0100
@@ -318,6 +318,39 @@ static void parse_bootloader_result(libx
     }
 }
 
+static char *libxl__find_free_vdev(libxl__gc *gc)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *vdev;
+    libxl_device_disk *list;
+    int num;
+    int used;
+
+    list = libxl_device_disk_list(ctx, 0, &num);
+    if (!list || num == 0) {
+        return "xvda";
+    }
+
+    for (char device = 'a'; device <= 'z'; device += 1) {
+        used = 0;
+        vdev = libxl__sprintf(gc, "xvd%c", device);
+        if (!vdev) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to allocate memory");
+            return NULL;
+        }
+        for (int i = 0; i < num; i++) {
+            if (strcmp(list[0].vdev, vdev) == 0) {
+                used = 1;
+                break;
+            }
+        }
+        if (!used)
+            return vdev;
+    }
+    LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to find a free device");
+    return NULL;
+}
+
 int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_domain_build_info *info,
                          libxl_device_disk *disk,
@@ -328,6 +361,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     char *fifo = NULL;
     char *diskpath = NULL;
     char **args = NULL;
+    char *vdev_save = NULL;
 
     char tempdir_template[] = "/var/run/libxl/bl.XXXXXX";
     char *tempdir;
@@ -378,6 +412,11 @@ int libxl_run_bootloader(libxl_ctx *ctx,
         goto out_close;
     }
 
+    vdev_save = disk->vdev;
+    disk->vdev = libxl__find_free_vdev(gc);
+    if (!disk->vdev)
+        goto out_close;
+
     diskpath = libxl_device_disk_local_attach(ctx, disk);
     if (!diskpath) {
         goto out_close;
@@ -446,6 +485,8 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 out_close:
     if (diskpath) {
         libxl_device_disk_local_detach(ctx, disk);
+        if (vdev_save)
+            disk->vdev = vdev_save;
         free(diskpath);
     }
     if (fifo_fd > -1)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswuN-0005M3-6Z; Thu, 02 Feb 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 <royger@gmail.com>) id 1RswuM-0005At-AJ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:41:02 +0000
Received: from [85.158.138.51:30967] by server-7.bemta-3.messagelabs.com id
	67/74-28646-D629A2F4; Thu, 02 Feb 2012 13:41:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!7
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15458 invoked from network); 2 Feb 2012 13:41:01 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:41:01 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:41:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=w8nRQAkrQgMhSxgFunc3MyGVOWln2pgwpAjl1c5KKoM=;
	b=Vh6lHGcU9fNNPpK8JHHINMju8spsEUDfEUN49iK0ssQX1TXpklsdC5QlS/Z9CJNZ7n
	/XiMO8kPDVLUPnVxkznJ3ixbpe8EUX1MuPGiFeTce8wFhaugs+/aLW6yVNNUACwTOvMR
	KIAWdfKbKJwwtfh+HZvAjX5k9PaGqlVRHy44A=
Received: by 10.216.137.147 with SMTP id y19mr4590738wei.34.1328190023499;
	Thu, 02 Feb 2012 05:40:23 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a7ef1bfa694bf581310e0242616a480e1c5e61b7
Message-Id: <a7ef1bfa694bf581310e.1328189210@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:50 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 29 RFC] NetBSD/xencommons: remove xend
 precmd folder creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID a7ef1bfa694bf581310e0242616a480e1c5e61b7
# Parent  6a7a2cc36fe7cadd7d0a50f6f265b6833a7b4e1f
NetBSD/xencommons: remove xend precmd folder creation

Since xend is not started by xencommons move the creation of the
necessary xend folders to xend init script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6a7a2cc36fe7 -r a7ef1bfa694b tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Sat Jan 14 19:04:48 2012 +0100
@@ -27,8 +27,6 @@ XENCONSOLED_PIDFILE="/var/run/xenconsole
 
 xen_precmd()
 {
-	mkdir -p /var/run/xend || exit 1
-	mkdir -p /var/run/xend/boot || exit 1
 	mkdir -p /var/run/xenstored || exit 1
 }
 
diff -r 6a7a2cc36fe7 -r a7ef1bfa694b tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xend	Sat Jan 14 19:04:48 2012 +0100
@@ -15,10 +15,17 @@ export PATH
 
 name="xend"
 rcvar=$name
+start_precmd="xen_precmd"
 command="${SBINDIR}/xend"
 command_args="start"
 command_interpreter=`head -n 1 ${command} | awk '{ print substr($0,3) }'`
 sig_stop="SIGKILL"
 
+xen_precmd()
+{
+	mkdir -p /var/run/xend || exit 1
+	mkdir -p /var/run/xend/boot || exit 1
+}
+
 load_rc_config $name
 run_rc_command "$1"

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswuN-0005M3-6Z; Thu, 02 Feb 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 <royger@gmail.com>) id 1RswuM-0005At-AJ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:41:02 +0000
Received: from [85.158.138.51:30967] by server-7.bemta-3.messagelabs.com id
	67/74-28646-D629A2F4; Thu, 02 Feb 2012 13:41:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328190014!11558498!7
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15458 invoked from network); 2 Feb 2012 13:41:01 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:41:01 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so4654079wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:41:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=w8nRQAkrQgMhSxgFunc3MyGVOWln2pgwpAjl1c5KKoM=;
	b=Vh6lHGcU9fNNPpK8JHHINMju8spsEUDfEUN49iK0ssQX1TXpklsdC5QlS/Z9CJNZ7n
	/XiMO8kPDVLUPnVxkznJ3ixbpe8EUX1MuPGiFeTce8wFhaugs+/aLW6yVNNUACwTOvMR
	KIAWdfKbKJwwtfh+HZvAjX5k9PaGqlVRHy44A=
Received: by 10.216.137.147 with SMTP id y19mr4590738wei.34.1328190023499;
	Thu, 02 Feb 2012 05:40:23 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a7ef1bfa694bf581310e0242616a480e1c5e61b7
Message-Id: <a7ef1bfa694bf581310e.1328189210@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:50 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 15 of 29 RFC] NetBSD/xencommons: remove xend
 precmd folder creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID a7ef1bfa694bf581310e0242616a480e1c5e61b7
# Parent  6a7a2cc36fe7cadd7d0a50f6f265b6833a7b4e1f
NetBSD/xencommons: remove xend precmd folder creation

Since xend is not started by xencommons move the creation of the
necessary xend folders to xend init script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6a7a2cc36fe7 -r a7ef1bfa694b tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Sat Jan 14 19:04:48 2012 +0100
@@ -27,8 +27,6 @@ XENCONSOLED_PIDFILE="/var/run/xenconsole
 
 xen_precmd()
 {
-	mkdir -p /var/run/xend || exit 1
-	mkdir -p /var/run/xend/boot || exit 1
 	mkdir -p /var/run/xenstored || exit 1
 }
 
diff -r 6a7a2cc36fe7 -r a7ef1bfa694b tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xend	Sat Jan 14 19:04:48 2012 +0100
@@ -15,10 +15,17 @@ export PATH
 
 name="xend"
 rcvar=$name
+start_precmd="xen_precmd"
 command="${SBINDIR}/xend"
 command_args="start"
 command_interpreter=`head -n 1 ${command} | awk '{ print substr($0,3) }'`
 sig_stop="SIGKILL"
 
+xen_precmd()
+{
+	mkdir -p /var/run/xend || exit 1
+	mkdir -p /var/run/xend/boot || exit 1
+}
+
 load_rc_config $name
 run_rc_command "$1"

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswuO-0005PI-Kp; Thu, 02 Feb 2012 13:41:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuN-0005Ki-Ds
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:41:03 +0000
Received: from [85.158.138.51:31003] by server-2.bemta-3.messagelabs.com id
	72/47-15021-E629A2F4; Thu, 02 Feb 2012 13:41:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!14
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23429 invoked from network); 2 Feb 2012 13:41:00 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:41:00 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:41:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VVUuv5wm/V+NXj21gLGjaGe4y6Bk1ozk5a4ajXtAryo=;
	b=DuF/jFv0humLroN7h4IIyzdL3aqq7qADnGNBXg9jbQuO/OZIKQ/8Wg0ACn6moTLU8R
	QIw0bzpi/uSV++Mnjzh1HCgI9wuko5lVlZYpM3y5QK1cU0QdXDvWyJ287d9GgErAGkCs
	sQeG6mLDQsXicnSRzGs02GeW6nasEqLMooRcE=
Received: by 10.180.82.227 with SMTP id l3mr2754898wiy.1.1328190010506;
	Thu, 02 Feb 2012 05:40:10 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8a5a82c9819558015ac75afdef28ee3d88d4f334
Message-Id: <8a5a82c9819558015ac7.1328189204@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:44 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 29 RFC] libxl: add better error checking
 on libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328176865 -3600
# Node ID 8a5a82c9819558015ac75afdef28ee3d88d4f334
# Parent  1efb9ee82433896e5a68f9a510f1f5542f071bd3
libxl: add better error checking on libxl__device_remove

Check return value of libxl__wait_for_device_state on
libxl__device_remove and print an error message accordingly.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1efb9ee82433 -r 8a5a82c98195 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 10:57:46 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:01:05 2012 +0100
@@ -503,8 +503,17 @@ retry_transaction:
     tv.tv_usec = 0;
     rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
                                       destroy_device);
-    if (rc < 0) /* an error or timeout occurred, clear watches */
+    if (rc == ERROR_TIMEDOUT) {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Timeout while waiting for unplug of "
+                   "device with backend path %s", be_path);
         xs_unwatch(ctx->xsh, state_path, be_path);
+    } else if (rc == ERROR_FAIL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to destroy device with "
+                   "backend path %s", be_path);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    }
     xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:41:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13: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.xensource.com>)
	id 1RswuO-0005PI-Kp; Thu, 02 Feb 2012 13:41:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RswuN-0005Ki-Ds
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:41:03 +0000
Received: from [85.158.138.51:31003] by server-2.bemta-3.messagelabs.com id
	72/47-15021-E629A2F4; Thu, 02 Feb 2012 13:41:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328189978!11669984!14
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23429 invoked from network); 2 Feb 2012 13:41:00 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 13:41:00 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so4567318wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 05:41:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VVUuv5wm/V+NXj21gLGjaGe4y6Bk1ozk5a4ajXtAryo=;
	b=DuF/jFv0humLroN7h4IIyzdL3aqq7qADnGNBXg9jbQuO/OZIKQ/8Wg0ACn6moTLU8R
	QIw0bzpi/uSV++Mnjzh1HCgI9wuko5lVlZYpM3y5QK1cU0QdXDvWyJ287d9GgErAGkCs
	sQeG6mLDQsXicnSRzGs02GeW6nasEqLMooRcE=
Received: by 10.180.82.227 with SMTP id l3mr2754898wiy.1.1328190010506;
	Thu, 02 Feb 2012 05:40:10 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id q7sm51678007wix.5.2012.02.02.05.40.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 05:40:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8a5a82c9819558015ac75afdef28ee3d88d4f334
Message-Id: <8a5a82c9819558015ac7.1328189204@debian.localdomain>
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 02 Feb 2012 14:26:44 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 29 RFC] libxl: add better error checking
 on libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328176865 -3600
# Node ID 8a5a82c9819558015ac75afdef28ee3d88d4f334
# Parent  1efb9ee82433896e5a68f9a510f1f5542f071bd3
libxl: add better error checking on libxl__device_remove

Check return value of libxl__wait_for_device_state on
libxl__device_remove and print an error message accordingly.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 1efb9ee82433 -r 8a5a82c98195 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Thu Feb 02 10:57:46 2012 +0100
+++ b/tools/libxl/libxl_device.c	Thu Feb 02 11:01:05 2012 +0100
@@ -503,8 +503,17 @@ retry_transaction:
     tv.tv_usec = 0;
     rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
                                       destroy_device);
-    if (rc < 0) /* an error or timeout occurred, clear watches */
+    if (rc == ERROR_TIMEDOUT) {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Timeout while waiting for unplug of "
+                   "device with backend path %s", be_path);
         xs_unwatch(ctx->xsh, state_path, be_path);
+    } else if (rc == ERROR_FAIL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to destroy device with "
+                   "backend path %s", be_path);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    }
     xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:44:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswy2-00088T-35; Thu, 02 Feb 2012 13:44:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rswy0-000858-2C
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:44:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328190280!13144564!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkzOTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5620 invoked from network); 2 Feb 2012 13:44:41 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-8.tower-216.messagelabs.com with SMTP;
	2 Feb 2012 13:44:41 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 2FA961A8083;
	Thu,  2 Feb 2012 05:44:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DJTSZzyt7boRbs9+PZAAdvnrxUHASbHSTh7VXmi70oyM
	gBFHnCNhQHZxXb209DvizOAk9y9sXHRUVEUYKbRHi81i1EHTFRYWvLqTybBU5UuD
	7I1AeDf4pd1gRcQ3U8ZajLOj555i+PVZ3s7gyuUUMkIyaSXxP3ajgkI539/k2TE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=mhIMgro730tea3VC/kwEjq4Zqyg=; b=g5isegaA
	iIUJvsh9HUnd9OnkzAXqvdhqp5ZhVCDEepWkkebPfspVvknVqwBoEE9S/C9EZ4QJ
	p4i2uqBgA+azIXaVkDwTcp7BolhBTyKRtKFOv7oPIWQjQzifrzJ7cCJUgKHBCMEV
	GeY3pkfRTogcpQ9ZfYL1arQ8TgyFAJYTBHU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id D010E1A8076; 
	Thu,  2 Feb 2012 05:44:39 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 05:44:40 -0800
Message-ID: <40266f74e9c627c2d8d00fa091b01fed.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202123926.GH48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
	<20120202123926.GH48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 05:44:40 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 9] x86/mm: Refactor possibly
 deadlocking get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:51 -0500 on 01 Feb (1328107915), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/hvm/emulate.c    |  35 +++++++--------
>>  xen/arch/x86/mm/mem_sharing.c |  28 +++++++------
>>  xen/include/asm-x86/p2m.h     |  91
>> +++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 122 insertions(+), 32 deletions(-)
>>
>>
>> When calling get_gfn multiple times on different gfn's in the same
>> function, we
>> can easily deadlock if p2m lookups are locked. Thus, refactor these
>> calls to
>> enforce simple deadlock-avoidance rules:
>>  - Lowest-numbered domain first
>>  - Lowest-numbered gfn first
>
> This is a good idea, and I like the get_two_gfns() abstraction, but:
>  - I think the two_gfns struct should proabbly just live on the stack
>    instead of malloc()ing it up every time.  It's not very big.
>  - the implementation of get_two_gfns() seems to be very complex; I'm
>    sure it could be simplified.  At the very least, you could avoid a
>    bit of duplication by just deciding once which order to do the gets
>    in and then running all the setu and get code once.
Reasonable. Will do both, repost later.
Thanks!
Andres
>
> Cheers,
>
> Tim.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>
>>
>> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/hvm/emulate.c
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
>>  {
>>      struct hvm_emulate_ctxt *hvmemul_ctxt =
>>          container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>> -    unsigned long saddr, daddr, bytes, sgfn, dgfn;
>> +    unsigned long saddr, daddr, bytes;
>>      paddr_t sgpa, dgpa;
>>      uint32_t pfec = PFEC_page_present;
>> -    p2m_type_t p2mt;
>> +    p2m_type_t sp2mt, dp2mt;
>>      int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
>>      char *buf;
>> +    struct two_gfns *tg;
>>
>>      rc = hvmemul_virtual_to_linear(
>>          src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
>> @@ -693,26 +694,25 @@ static int hvmemul_rep_movs(
>>      if ( rc != X86EMUL_OKAY )
>>          return rc;
>>
>> -    /* XXX In a fine-grained p2m locking scenario, we need to sort this
>> -     * get_gfn's, or else we might deadlock */
>> -    sgfn = sgpa >> PAGE_SHIFT;
>> -    (void)get_gfn(current->domain, sgfn, &p2mt);
>> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
>> +    tg = get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt,
>> NULL, NULL,
>> +                      current->domain, dgpa >> PAGE_SHIFT, &dp2mt,
>> NULL, NULL,
>> +                      p2m_guest);
>> +    if ( !tg )
>> +        return X86EMUL_UNHANDLEABLE;
>> +
>> +    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
>>      {
>>          rc = hvmemul_do_mmio(
>>              sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
>> -        put_gfn(current->domain, sgfn);
>> +        put_two_gfns(&tg);
>>          return rc;
>>      }
>>
>> -    dgfn = dgpa >> PAGE_SHIFT;
>> -    (void)get_gfn(current->domain, dgfn, &p2mt);
>> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
>> +    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
>>      {
>>          rc = hvmemul_do_mmio(
>>              dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
>> -        put_gfn(current->domain, sgfn);
>> -        put_gfn(current->domain, dgfn);
>> +        put_two_gfns(&tg);
>>          return rc;
>>      }
>>
>> @@ -730,8 +730,7 @@ static int hvmemul_rep_movs(
>>       */
>>      if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
>>      {
>> -        put_gfn(current->domain, sgfn);
>> -        put_gfn(current->domain, dgfn);
>> +        put_two_gfns(&tg);
>>          return X86EMUL_UNHANDLEABLE;
>>      }
>>
>> @@ -743,8 +742,7 @@ static int hvmemul_rep_movs(
>>      buf = xmalloc_bytes(bytes);
>>      if ( buf == NULL )
>>      {
>> -        put_gfn(current->domain, sgfn);
>> -        put_gfn(current->domain, dgfn);
>> +        put_two_gfns(&tg);
>>          return X86EMUL_UNHANDLEABLE;
>>      }
>>
>> @@ -757,8 +755,7 @@ static int hvmemul_rep_movs(
>>          rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
>>
>>      xfree(buf);
>> -    put_gfn(current->domain, sgfn);
>> -    put_gfn(current->domain, dgfn);
>> +    put_two_gfns(&tg);
>>
>>      if ( rc == HVMCOPY_gfn_paged_out )
>>          return X86EMUL_RETRY;
>> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -718,11 +718,13 @@ int mem_sharing_share_pages(struct domai
>>      int ret = -EINVAL;
>>      mfn_t smfn, cmfn;
>>      p2m_type_t smfn_type, cmfn_type;
>> +    struct two_gfns *tg;
>>
>> -    /* XXX if sd == cd handle potential deadlock by ordering
>> -     * the get_ and put_gfn's */
>> -    smfn = get_gfn(sd, sgfn, &smfn_type);
>> -    cmfn = get_gfn(cd, cgfn, &cmfn_type);
>> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
>> +                      cd, cgfn, &cmfn_type, NULL, &cmfn,
>> +                      p2m_query);
>> +    if ( !tg )
>> +        return -ENOMEM;
>>
>>      /* This tricky business is to avoid two callers deadlocking if
>>       * grabbing pages in opposite client/source order */
>> @@ -819,8 +821,7 @@ int mem_sharing_share_pages(struct domai
>>      ret = 0;
>>
>>  err_out:
>> -    put_gfn(cd, cgfn);
>> -    put_gfn(sd, sgfn);
>> +    put_two_gfns(&tg);
>>      return ret;
>>  }
>>
>> @@ -834,11 +835,13 @@ int mem_sharing_add_to_physmap(struct do
>>      struct gfn_info *gfn_info;
>>      struct p2m_domain *p2m = p2m_get_hostp2m(cd);
>>      p2m_access_t a;
>> -
>> -    /* XXX if sd == cd handle potential deadlock by ordering
>> -     * the get_ and put_gfn's */
>> -    smfn = get_gfn_query(sd, sgfn, &smfn_type);
>> -    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query,
>> NULL);
>> +    struct two_gfns *tg;
>> +
>> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
>> +                      cd, cgfn, &cmfn_type, &a, &cmfn,
>> +                      p2m_query);
>> +    if ( !tg )
>> +        return -ENOMEM;
>>
>>      /* Get the source shared page, check and lock */
>>      ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
>> @@ -886,8 +889,7 @@ int mem_sharing_add_to_physmap(struct do
>>  err_unlock:
>>      mem_sharing_page_unlock(spage);
>>  err_out:
>> -    put_gfn(cd, cgfn);
>> -    put_gfn(sd, sgfn);
>> +    put_two_gfns(&tg);
>>      return ret;
>>  }
>>
>> diff -r 27031a8a4eff -r 3de7e43b130a xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -378,6 +378,97 @@ static inline unsigned long mfn_to_gfn(s
>>          return mfn_x(mfn);
>>  }
>>
>> +/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
>> +struct two_gfns {
>> +    struct domain  *first_domain;
>> +    unsigned long   first_gfn;
>> +    struct domain  *second_domain;
>> +    unsigned long   second_gfn;
>> +};
>> +
>> +#define assign_pointers(dest, source)
>>     \
>> +do {
>>     \
>> +    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ##
>> _mfn;  \
>> +    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ##
>> _a;    \
>> +    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ##
>> _t;    \
>> +} while(0)
>> +
>> +/* Returns mfn, type and access for potential caller consumption, but
>> any
>> + * of those can be NULL */
>> +static inline struct two_gfns *get_two_gfns(struct domain *rd, unsigned
>> long rgfn,
>> +        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain
>> *ld,
>> +        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t
>> *lmfn,
>> +        p2m_query_t q)
>> +{
>> +    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
>> +    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
>> +    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
>> +
>> +    struct two_gfns *rval = xmalloc(struct two_gfns);
>> +    if ( !rval )
>> +        return NULL;
>> +
>> +    if ( rd == ld )
>> +    {
>> +        rval->first_domain = rval->second_domain = rd;
>> +
>> +        /* Sort by gfn */
>> +        if (rgfn <= lgfn)
>> +        {
>> +            rval->first_gfn     = rgfn;
>> +            rval->second_gfn    = lgfn;
>> +            assign_pointers(first, r);
>> +            assign_pointers(second, l);
>> +        } else {
>> +            rval->first_gfn     = lgfn;
>> +            rval->second_gfn    = rgfn;
>> +            assign_pointers(first, l);
>> +            assign_pointers(second, r);
>> +        }
>> +    } else {
>> +        /* Sort by domain */
>> +        if ( rd->domain_id <= ld->domain_id )
>> +        {
>> +            rval->first_domain  = rd;
>> +            rval->first_gfn     = rgfn;
>> +            rval->second_domain = ld;
>> +            rval->second_gfn    = lgfn;
>> +            assign_pointers(first, r);
>> +            assign_pointers(second, l);
>> +        } else {
>> +            rval->first_domain  = ld;
>> +            rval->first_gfn     = lgfn;
>> +            rval->second_domain = rd;
>> +            rval->second_gfn    = rgfn;
>> +            assign_pointers(first, l);
>> +            assign_pointers(second, r);
>> +        }
>> +    }
>> +
>> +    /* Now do the gets */
>> +    *first_mfn  =
>> get_gfn_type_access(p2m_get_hostp2m(rval->first_domain),
>> +                                      rval->first_gfn, first_t,
>> first_a, q, NULL);
>> +    *second_mfn =
>> get_gfn_type_access(p2m_get_hostp2m(rval->second_domain),
>> +                                      rval->second_gfn, second_t,
>> second_a, q, NULL);
>> +
>> +    return rval;
>> +}
>> +
>> +static inline void put_two_gfns(struct two_gfns **arg_ptr)
>> +{
>> +    struct two_gfns *arg;
>> +
>> +    if ( !arg_ptr || !(*arg_ptr) )
>> +        return;
>> +
>> +    arg = *arg_ptr;
>> +    put_gfn(arg->second_domain, arg->second_gfn);
>> +    put_gfn(arg->first_domain, arg->first_gfn);
>> +
>> +    xfree(arg);
>> +    *arg_ptr = NULL;
>> +}
>> +
>>  /* Init the datastructures for later use by the p2m code */
>>  int p2m_init(struct domain *d);
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:44:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rswy2-00088T-35; Thu, 02 Feb 2012 13:44:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rswy0-000858-2C
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:44:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328190280!13144564!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkzOTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5620 invoked from network); 2 Feb 2012 13:44:41 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-8.tower-216.messagelabs.com with SMTP;
	2 Feb 2012 13:44:41 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 2FA961A8083;
	Thu,  2 Feb 2012 05:44:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=DJTSZzyt7boRbs9+PZAAdvnrxUHASbHSTh7VXmi70oyM
	gBFHnCNhQHZxXb209DvizOAk9y9sXHRUVEUYKbRHi81i1EHTFRYWvLqTybBU5UuD
	7I1AeDf4pd1gRcQ3U8ZajLOj555i+PVZ3s7gyuUUMkIyaSXxP3ajgkI539/k2TE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=mhIMgro730tea3VC/kwEjq4Zqyg=; b=g5isegaA
	iIUJvsh9HUnd9OnkzAXqvdhqp5ZhVCDEepWkkebPfspVvknVqwBoEE9S/C9EZ4QJ
	p4i2uqBgA+azIXaVkDwTcp7BolhBTyKRtKFOv7oPIWQjQzifrzJ7cCJUgKHBCMEV
	GeY3pkfRTogcpQ9ZfYL1arQ8TgyFAJYTBHU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id D010E1A8076; 
	Thu,  2 Feb 2012 05:44:39 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 05:44:40 -0800
Message-ID: <40266f74e9c627c2d8d00fa091b01fed.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202123926.GH48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<3de7e43b130a87d428e0.1328125915@xdev.gridcentric.ca>
	<20120202123926.GH48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 05:44:40 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 9] x86/mm: Refactor possibly
 deadlocking get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:51 -0500 on 01 Feb (1328107915), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/hvm/emulate.c    |  35 +++++++--------
>>  xen/arch/x86/mm/mem_sharing.c |  28 +++++++------
>>  xen/include/asm-x86/p2m.h     |  91
>> +++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 122 insertions(+), 32 deletions(-)
>>
>>
>> When calling get_gfn multiple times on different gfn's in the same
>> function, we
>> can easily deadlock if p2m lookups are locked. Thus, refactor these
>> calls to
>> enforce simple deadlock-avoidance rules:
>>  - Lowest-numbered domain first
>>  - Lowest-numbered gfn first
>
> This is a good idea, and I like the get_two_gfns() abstraction, but:
>  - I think the two_gfns struct should proabbly just live on the stack
>    instead of malloc()ing it up every time.  It's not very big.
>  - the implementation of get_two_gfns() seems to be very complex; I'm
>    sure it could be simplified.  At the very least, you could avoid a
>    bit of duplication by just deciding once which order to do the gets
>    in and then running all the setu and get code once.
Reasonable. Will do both, repost later.
Thanks!
Andres
>
> Cheers,
>
> Tim.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>
>>
>> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/hvm/emulate.c
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
>>  {
>>      struct hvm_emulate_ctxt *hvmemul_ctxt =
>>          container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>> -    unsigned long saddr, daddr, bytes, sgfn, dgfn;
>> +    unsigned long saddr, daddr, bytes;
>>      paddr_t sgpa, dgpa;
>>      uint32_t pfec = PFEC_page_present;
>> -    p2m_type_t p2mt;
>> +    p2m_type_t sp2mt, dp2mt;
>>      int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
>>      char *buf;
>> +    struct two_gfns *tg;
>>
>>      rc = hvmemul_virtual_to_linear(
>>          src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
>> @@ -693,26 +694,25 @@ static int hvmemul_rep_movs(
>>      if ( rc != X86EMUL_OKAY )
>>          return rc;
>>
>> -    /* XXX In a fine-grained p2m locking scenario, we need to sort this
>> -     * get_gfn's, or else we might deadlock */
>> -    sgfn = sgpa >> PAGE_SHIFT;
>> -    (void)get_gfn(current->domain, sgfn, &p2mt);
>> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
>> +    tg = get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt,
>> NULL, NULL,
>> +                      current->domain, dgpa >> PAGE_SHIFT, &dp2mt,
>> NULL, NULL,
>> +                      p2m_guest);
>> +    if ( !tg )
>> +        return X86EMUL_UNHANDLEABLE;
>> +
>> +    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
>>      {
>>          rc = hvmemul_do_mmio(
>>              sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
>> -        put_gfn(current->domain, sgfn);
>> +        put_two_gfns(&tg);
>>          return rc;
>>      }
>>
>> -    dgfn = dgpa >> PAGE_SHIFT;
>> -    (void)get_gfn(current->domain, dgfn, &p2mt);
>> -    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
>> +    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
>>      {
>>          rc = hvmemul_do_mmio(
>>              dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
>> -        put_gfn(current->domain, sgfn);
>> -        put_gfn(current->domain, dgfn);
>> +        put_two_gfns(&tg);
>>          return rc;
>>      }
>>
>> @@ -730,8 +730,7 @@ static int hvmemul_rep_movs(
>>       */
>>      if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
>>      {
>> -        put_gfn(current->domain, sgfn);
>> -        put_gfn(current->domain, dgfn);
>> +        put_two_gfns(&tg);
>>          return X86EMUL_UNHANDLEABLE;
>>      }
>>
>> @@ -743,8 +742,7 @@ static int hvmemul_rep_movs(
>>      buf = xmalloc_bytes(bytes);
>>      if ( buf == NULL )
>>      {
>> -        put_gfn(current->domain, sgfn);
>> -        put_gfn(current->domain, dgfn);
>> +        put_two_gfns(&tg);
>>          return X86EMUL_UNHANDLEABLE;
>>      }
>>
>> @@ -757,8 +755,7 @@ static int hvmemul_rep_movs(
>>          rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
>>
>>      xfree(buf);
>> -    put_gfn(current->domain, sgfn);
>> -    put_gfn(current->domain, dgfn);
>> +    put_two_gfns(&tg);
>>
>>      if ( rc == HVMCOPY_gfn_paged_out )
>>          return X86EMUL_RETRY;
>> diff -r 27031a8a4eff -r 3de7e43b130a xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -718,11 +718,13 @@ int mem_sharing_share_pages(struct domai
>>      int ret = -EINVAL;
>>      mfn_t smfn, cmfn;
>>      p2m_type_t smfn_type, cmfn_type;
>> +    struct two_gfns *tg;
>>
>> -    /* XXX if sd == cd handle potential deadlock by ordering
>> -     * the get_ and put_gfn's */
>> -    smfn = get_gfn(sd, sgfn, &smfn_type);
>> -    cmfn = get_gfn(cd, cgfn, &cmfn_type);
>> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
>> +                      cd, cgfn, &cmfn_type, NULL, &cmfn,
>> +                      p2m_query);
>> +    if ( !tg )
>> +        return -ENOMEM;
>>
>>      /* This tricky business is to avoid two callers deadlocking if
>>       * grabbing pages in opposite client/source order */
>> @@ -819,8 +821,7 @@ int mem_sharing_share_pages(struct domai
>>      ret = 0;
>>
>>  err_out:
>> -    put_gfn(cd, cgfn);
>> -    put_gfn(sd, sgfn);
>> +    put_two_gfns(&tg);
>>      return ret;
>>  }
>>
>> @@ -834,11 +835,13 @@ int mem_sharing_add_to_physmap(struct do
>>      struct gfn_info *gfn_info;
>>      struct p2m_domain *p2m = p2m_get_hostp2m(cd);
>>      p2m_access_t a;
>> -
>> -    /* XXX if sd == cd handle potential deadlock by ordering
>> -     * the get_ and put_gfn's */
>> -    smfn = get_gfn_query(sd, sgfn, &smfn_type);
>> -    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query,
>> NULL);
>> +    struct two_gfns *tg;
>> +
>> +    tg = get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
>> +                      cd, cgfn, &cmfn_type, &a, &cmfn,
>> +                      p2m_query);
>> +    if ( !tg )
>> +        return -ENOMEM;
>>
>>      /* Get the source shared page, check and lock */
>>      ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
>> @@ -886,8 +889,7 @@ int mem_sharing_add_to_physmap(struct do
>>  err_unlock:
>>      mem_sharing_page_unlock(spage);
>>  err_out:
>> -    put_gfn(cd, cgfn);
>> -    put_gfn(sd, sgfn);
>> +    put_two_gfns(&tg);
>>      return ret;
>>  }
>>
>> diff -r 27031a8a4eff -r 3de7e43b130a xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -378,6 +378,97 @@ static inline unsigned long mfn_to_gfn(s
>>          return mfn_x(mfn);
>>  }
>>
>> +/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
>> +struct two_gfns {
>> +    struct domain  *first_domain;
>> +    unsigned long   first_gfn;
>> +    struct domain  *second_domain;
>> +    unsigned long   second_gfn;
>> +};
>> +
>> +#define assign_pointers(dest, source)
>>     \
>> +do {
>>     \
>> +    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ##
>> _mfn;  \
>> +    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ##
>> _a;    \
>> +    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ##
>> _t;    \
>> +} while(0)
>> +
>> +/* Returns mfn, type and access for potential caller consumption, but
>> any
>> + * of those can be NULL */
>> +static inline struct two_gfns *get_two_gfns(struct domain *rd, unsigned
>> long rgfn,
>> +        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain
>> *ld,
>> +        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t
>> *lmfn,
>> +        p2m_query_t q)
>> +{
>> +    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
>> +    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
>> +    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
>> +
>> +    struct two_gfns *rval = xmalloc(struct two_gfns);
>> +    if ( !rval )
>> +        return NULL;
>> +
>> +    if ( rd == ld )
>> +    {
>> +        rval->first_domain = rval->second_domain = rd;
>> +
>> +        /* Sort by gfn */
>> +        if (rgfn <= lgfn)
>> +        {
>> +            rval->first_gfn     = rgfn;
>> +            rval->second_gfn    = lgfn;
>> +            assign_pointers(first, r);
>> +            assign_pointers(second, l);
>> +        } else {
>> +            rval->first_gfn     = lgfn;
>> +            rval->second_gfn    = rgfn;
>> +            assign_pointers(first, l);
>> +            assign_pointers(second, r);
>> +        }
>> +    } else {
>> +        /* Sort by domain */
>> +        if ( rd->domain_id <= ld->domain_id )
>> +        {
>> +            rval->first_domain  = rd;
>> +            rval->first_gfn     = rgfn;
>> +            rval->second_domain = ld;
>> +            rval->second_gfn    = lgfn;
>> +            assign_pointers(first, r);
>> +            assign_pointers(second, l);
>> +        } else {
>> +            rval->first_domain  = ld;
>> +            rval->first_gfn     = lgfn;
>> +            rval->second_domain = rd;
>> +            rval->second_gfn    = rgfn;
>> +            assign_pointers(first, l);
>> +            assign_pointers(second, r);
>> +        }
>> +    }
>> +
>> +    /* Now do the gets */
>> +    *first_mfn  =
>> get_gfn_type_access(p2m_get_hostp2m(rval->first_domain),
>> +                                      rval->first_gfn, first_t,
>> first_a, q, NULL);
>> +    *second_mfn =
>> get_gfn_type_access(p2m_get_hostp2m(rval->second_domain),
>> +                                      rval->second_gfn, second_t,
>> second_a, q, NULL);
>> +
>> +    return rval;
>> +}
>> +
>> +static inline void put_two_gfns(struct two_gfns **arg_ptr)
>> +{
>> +    struct two_gfns *arg;
>> +
>> +    if ( !arg_ptr || !(*arg_ptr) )
>> +        return;
>> +
>> +    arg = *arg_ptr;
>> +    put_gfn(arg->second_domain, arg->second_gfn);
>> +    put_gfn(arg->first_domain, arg->first_gfn);
>> +
>> +    xfree(arg);
>> +    *arg_ptr = NULL;
>> +}
>> +
>>  /* Init the datastructures for later use by the p2m code */
>>  int p2m_init(struct domain *d);
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:46:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswzI-000083-IU; Thu, 02 Feb 2012 13:46:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RswzG-00007N-Dn
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:46:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328190316!52630416!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17940 invoked from network); 2 Feb 2012 13:45:16 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 13:45:16 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 274CF71406B;
	Thu,  2 Feb 2012 05:46:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Cns1Vj4cTfTfZMPi4dCMkKIf+pIswpPIbYABEtvakrTH
	eRuQ2Uawi5T+DIaTr5K8BkSgfL4DSSrnv6B5JySPNyxeH3VfcYFTyxt7PElYKzxw
	sAqJuibGn2Ca4qV1wq9PblrGaE7KiRBEyn3dL2cFtiRSXrSuhh7pXLCVRKXCLbo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=zKfnGr6RhezTtduUMBtnMdXFg7Q=; b=XZxVFCfa
	WdwrH5NZVg4o/0Olhihi6mbkaV2ie7PNE8SMT0Vt5bdF8Zsx1JCjQby2yyLSQRZn
	fQiQHcD3nwdlf/Z5A+FoOvheowrk4mcdLv2TPX2ARNi0i8/4X2AY55G/hqh2i+/j
	CrQOZmBlpPNjR1CtKoOjKuoNAvylm8br94E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id CF1E471406A; 
	Thu,  2 Feb 2012 05:46:03 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 05:46:04 -0800
Message-ID: <098b8cacfeda78519afc2bbd4a731021.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202124118.GI48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
	<20120202124118.GI48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 05:46:04 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: When removing/adding a page
 from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:51 -0500 on 01 Feb (1328107917), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/p2m.c |  21 ++++++++++++++++++++-
>>  1 files changed, 20 insertions(+), 1 deletions(-)
>>
>>
>> When removing the m2p mapping it is unconditionally set to invalid,
>> which
>> breaks sharing.
>>
>> When adding to the physmap, if the previous holder of that entry is a
>> shared
>> page, we unshare to default to normal case handling.
>>
>> And, we cannot add a shared page directly to the physmap. Proper
>> interfaces
>> must be employed, otherwise book-keeping goes awry.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 8a920bcddd0f -r 1c61573d1765 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -419,7 +419,7 @@ p2m_remove_page(struct p2m_domain *p2m,
>>          for ( i = 0; i < (1UL << page_order); i++ )
>>          {
>>              mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a,
>> p2m_query, NULL);
>> -            if ( !p2m_is_grant(t) )
>> +            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
>>                  set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
>>              ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
>>          }
>> @@ -481,6 +481,17 @@ guest_physmap_add_entry(struct domain *d
>>      for ( i = 0; i < (1UL << page_order); i++ )
>>      {
>>          omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
>> +        if ( p2m_is_shared(ot) )
>> +        {
>> +            /* Do an unshare to cleanly take care of all corner
>> +             * cases. */
>> +            int rc;
>> +            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
>> +            if ( rc )
>> +                return rc;
>
> You're holding the p2m lock here!  Also, I don't think you can call
> mem_sharing_unshare_page() with that held - wasn't that the reason for
> cset f6c33cfe7333 ?
D'oh!
This patch has to follow the locking p2m series. Before reposting, I'll
have to make sure nothing breaks when applying after locking p2m.

Good catch!
Andres
>
> Tim.
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 13:46:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 13:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RswzI-000083-IU; Thu, 02 Feb 2012 13:46:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RswzG-00007N-Dn
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 13:46:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328190316!52630416!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17940 invoked from network); 2 Feb 2012 13:45:16 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 13:45:16 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 274CF71406B;
	Thu,  2 Feb 2012 05:46:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Cns1Vj4cTfTfZMPi4dCMkKIf+pIswpPIbYABEtvakrTH
	eRuQ2Uawi5T+DIaTr5K8BkSgfL4DSSrnv6B5JySPNyxeH3VfcYFTyxt7PElYKzxw
	sAqJuibGn2Ca4qV1wq9PblrGaE7KiRBEyn3dL2cFtiRSXrSuhh7pXLCVRKXCLbo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=zKfnGr6RhezTtduUMBtnMdXFg7Q=; b=XZxVFCfa
	WdwrH5NZVg4o/0Olhihi6mbkaV2ie7PNE8SMT0Vt5bdF8Zsx1JCjQby2yyLSQRZn
	fQiQHcD3nwdlf/Z5A+FoOvheowrk4mcdLv2TPX2ARNi0i8/4X2AY55G/hqh2i+/j
	CrQOZmBlpPNjR1CtKoOjKuoNAvylm8br94E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id CF1E471406A; 
	Thu,  2 Feb 2012 05:46:03 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 05:46:04 -0800
Message-ID: <098b8cacfeda78519afc2bbd4a731021.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202124118.GI48883@ocelot.phlegethon.org>
References: <patchbomb.1328125912@xdev.gridcentric.ca>
	<1c61573d17650c67448c.1328125917@xdev.gridcentric.ca>
	<20120202124118.GI48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 05:46:04 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: When removing/adding a page
 from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:51 -0500 on 01 Feb (1328107917), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/p2m.c |  21 ++++++++++++++++++++-
>>  1 files changed, 20 insertions(+), 1 deletions(-)
>>
>>
>> When removing the m2p mapping it is unconditionally set to invalid,
>> which
>> breaks sharing.
>>
>> When adding to the physmap, if the previous holder of that entry is a
>> shared
>> page, we unshare to default to normal case handling.
>>
>> And, we cannot add a shared page directly to the physmap. Proper
>> interfaces
>> must be employed, otherwise book-keeping goes awry.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 8a920bcddd0f -r 1c61573d1765 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -419,7 +419,7 @@ p2m_remove_page(struct p2m_domain *p2m,
>>          for ( i = 0; i < (1UL << page_order); i++ )
>>          {
>>              mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a,
>> p2m_query, NULL);
>> -            if ( !p2m_is_grant(t) )
>> +            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
>>                  set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
>>              ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
>>          }
>> @@ -481,6 +481,17 @@ guest_physmap_add_entry(struct domain *d
>>      for ( i = 0; i < (1UL << page_order); i++ )
>>      {
>>          omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
>> +        if ( p2m_is_shared(ot) )
>> +        {
>> +            /* Do an unshare to cleanly take care of all corner
>> +             * cases. */
>> +            int rc;
>> +            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
>> +            if ( rc )
>> +                return rc;
>
> You're holding the p2m lock here!  Also, I don't think you can call
> mem_sharing_unshare_page() with that held - wasn't that the reason for
> cset f6c33cfe7333 ?
D'oh!
This patch has to follow the locking p2m series. Before reposting, I'll
have to make sure nothing breaks when applying after locking p2m.

Good catch!
Andres
>
> Tim.
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:01:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsxEF-0001Fd-Lc; Thu, 02 Feb 2012 14:01:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsxED-0001FS-PB
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:01:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328191287!13415477!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxOTMzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12486 invoked from network); 2 Feb 2012 14:01:27 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-182.messagelabs.com with SMTP;
	2 Feb 2012 14:01:27 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 39B9571406B;
	Thu,  2 Feb 2012 06:01:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YgU0DeZFTUHGFodIsjU5FGXeHTiqeHGGfpkj2SYQ+UQQ
	Bap/OjvE41bQsdb9FNZ7G34VxSStJguJkxk77uYeDdBpNQkeYWyyktkH89oFBquk
	xw31lz3KN+8/Y87uiRV/xDiqVuMgS2XEOVMEn0s/SXaWJYYJWWZfENCogxeThFg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=lTb7FF3w2SnxJ560eqSTTUYYS6w=; b=OuIOU/yz
	87aAbE41uUF13gf8FSwrtk0fIDC5zUbwGLmFlL4djYPYzgs48io6QqW7y45FjJOS
	g6riN6/ldYc0g9xdE4rxFStSfdKm7D6xb7eYEtP6v6pJJflX93wUH1cpuztgdIDD
	Sd7AHHt6eJBKNl+gl3QJHj6D1IE+fRH7Pd4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id AEA6871406A; 
	Thu,  2 Feb 2012 06:01:25 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 06:01:26 -0800
Message-ID: <fc122e59af05d45de854a259f6fac62d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202130818.GK48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
	<20120202130818.GK48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 06:01:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 5] Make p2m lookups fully synchronized
 wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:56 -0500 on 01 Feb (1328108165), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/hap/hap.c  |   6 +++++
>>  xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
>>  xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
>>  xen/include/asm-x86/p2m.h  |  47
>> ++++++++++++++++++++++++++++-----------------
>>  4 files changed, 79 insertions(+), 35 deletions(-)
>>
>>
>> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
>>
>> The lock is always taken recursively, as there are many paths that
>> do get_gfn, and later, another attempt at grabbing the p2m_lock
>>
>> The lock is not taken for shadow lookups, as the testing needed to rule
>> out the
>> possibility of locking inversions and deadlock has not yet been carried
>> out for
>> shadow-paging. This is tolerable as long as shadows do not gain support
>> for
>> paging or sharing.
>
> Are you aware of any inversions or are you just suggesting there might
> be some left?

I'm not aware of any inversions. A previously posted patch cleans up all
that I could see. But I have not tested shadows, so I don't feel
comfortable about enabling it just yet.

>
>> HAP (EPT) lookups and all modifications do take the lock.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -786,7 +786,12 @@ hap_paging_get_mode(struct vcpu *v)
>>  static void hap_update_paging_modes(struct vcpu *v)
>>  {
>>      struct domain *d = v->domain;
>> +    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
>> +    p2m_type_t t;
>>
>> +    /* We hold onto the cr3 as it may be modified later, and
>> +     * we need to respect lock ordering */
>> +    (void)get_gfn(d, cr3_gfn, &t);
>
> Don't you need to check for errors?
Good to have, yes. As in, bail out if !p2m_is_ram || !mfn_valid.

>
>>      paging_lock(d);
>>
>>      v->arch.paging.mode = hap_paging_get_mode(v);
>> @@ -803,6 +808,7 @@ static void hap_update_paging_modes(stru
>>      hap_update_cr3(v, 0);
>>
>>      paging_unlock(d);
>> +    put_gfn(d, cr3_gfn);
>>  }
>>
>>  #if CONFIG_PAGING_LEVELS == 3
>> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/mm-locks.h
>> --- a/xen/arch/x86/mm/mm-locks.h
>> +++ b/xen/arch/x86/mm/mm-locks.h
>> @@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
>>   *
>> *
>>   ************************************************************************/
>>
>> +declare_mm_lock(nestedp2m)
>> +#define nestedp2m_lock(d)   mm_lock(nestedp2m,
>> &(d)->arch.nested_p2m_lock)
>> +#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
>> +
>> +/* P2M lock (per-p2m-table)
>> + *
>> + * This protects all queries and updates to the p2m table.
>> + *
>> + * A note about ordering:
>> + *   The order established here is enforced on all mutations of a p2m.
>> + *   For lookups, the order established here is enforced only for hap
>> + *   domains (1. shadow domains present a few nasty inversions;
>> + *            2. shadow domains do not support paging and sharing,
>> + *               the main sources of dynamic p2m mutations)
>> + *
>> + * The lock is recursive as it is common for a code path to look up a
>> gfn
>> + * and later mutate it.
>> + */
>> +
>> +declare_mm_lock(p2m)
>> +#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
>> +#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
>> +#define p2m_unlock(p)         mm_unlock(&(p)->lock)
>> +#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
>> +
>>  /* Sharing per page lock
>>   *
>>   * This is an external lock, not represented by an mm_lock_t. The
>> memory
>
> Since you've just reversed the locking order between this page-sharing
> lock and the p2m lock, you need to update the comment that describes
> it.  Also, presumably, the code that it describes?
The comment might be stale, certainly, will look into it.

The code is just fine, per testing. The next patch does a proper cleanup:
the "complicated condition" is grabbing a p2m lock nested inside a
page-sharing critical section. But thanks to this patch, the p2m lock will
have been taken before, so no race (hope that makes sense).

Bottomline is, correct with this patch, clean with next.

Thanks!
Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:01:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:01:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsxEF-0001Fd-Lc; Thu, 02 Feb 2012 14:01:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsxED-0001FS-PB
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:01:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328191287!13415477!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxOTMzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12486 invoked from network); 2 Feb 2012 14:01:27 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-182.messagelabs.com with SMTP;
	2 Feb 2012 14:01:27 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 39B9571406B;
	Thu,  2 Feb 2012 06:01:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YgU0DeZFTUHGFodIsjU5FGXeHTiqeHGGfpkj2SYQ+UQQ
	Bap/OjvE41bQsdb9FNZ7G34VxSStJguJkxk77uYeDdBpNQkeYWyyktkH89oFBquk
	xw31lz3KN+8/Y87uiRV/xDiqVuMgS2XEOVMEn0s/SXaWJYYJWWZfENCogxeThFg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=lTb7FF3w2SnxJ560eqSTTUYYS6w=; b=OuIOU/yz
	87aAbE41uUF13gf8FSwrtk0fIDC5zUbwGLmFlL4djYPYzgs48io6QqW7y45FjJOS
	g6riN6/ldYc0g9xdE4rxFStSfdKm7D6xb7eYEtP6v6pJJflX93wUH1cpuztgdIDD
	Sd7AHHt6eJBKNl+gl3QJHj6D1IE+fRH7Pd4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id AEA6871406A; 
	Thu,  2 Feb 2012 06:01:25 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 06:01:26 -0800
Message-ID: <fc122e59af05d45de854a259f6fac62d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202130818.GK48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<223512f9fb5b9204a1b3.1328126165@xdev.gridcentric.ca>
	<20120202130818.GK48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 06:01:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 5] Make p2m lookups fully synchronized
 wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:56 -0500 on 01 Feb (1328108165), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/hap/hap.c  |   6 +++++
>>  xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
>>  xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
>>  xen/include/asm-x86/p2m.h  |  47
>> ++++++++++++++++++++++++++++-----------------
>>  4 files changed, 79 insertions(+), 35 deletions(-)
>>
>>
>> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
>>
>> The lock is always taken recursively, as there are many paths that
>> do get_gfn, and later, another attempt at grabbing the p2m_lock
>>
>> The lock is not taken for shadow lookups, as the testing needed to rule
>> out the
>> possibility of locking inversions and deadlock has not yet been carried
>> out for
>> shadow-paging. This is tolerable as long as shadows do not gain support
>> for
>> paging or sharing.
>
> Are you aware of any inversions or are you just suggesting there might
> be some left?

I'm not aware of any inversions. A previously posted patch cleans up all
that I could see. But I have not tested shadows, so I don't feel
comfortable about enabling it just yet.

>
>> HAP (EPT) lookups and all modifications do take the lock.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -786,7 +786,12 @@ hap_paging_get_mode(struct vcpu *v)
>>  static void hap_update_paging_modes(struct vcpu *v)
>>  {
>>      struct domain *d = v->domain;
>> +    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
>> +    p2m_type_t t;
>>
>> +    /* We hold onto the cr3 as it may be modified later, and
>> +     * we need to respect lock ordering */
>> +    (void)get_gfn(d, cr3_gfn, &t);
>
> Don't you need to check for errors?
Good to have, yes. As in, bail out if !p2m_is_ram || !mfn_valid.

>
>>      paging_lock(d);
>>
>>      v->arch.paging.mode = hap_paging_get_mode(v);
>> @@ -803,6 +808,7 @@ static void hap_update_paging_modes(stru
>>      hap_update_cr3(v, 0);
>>
>>      paging_unlock(d);
>> +    put_gfn(d, cr3_gfn);
>>  }
>>
>>  #if CONFIG_PAGING_LEVELS == 3
>> diff -r 9a55109e4d7e -r 223512f9fb5b xen/arch/x86/mm/mm-locks.h
>> --- a/xen/arch/x86/mm/mm-locks.h
>> +++ b/xen/arch/x86/mm/mm-locks.h
>> @@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
>>   *
>> *
>>   ************************************************************************/
>>
>> +declare_mm_lock(nestedp2m)
>> +#define nestedp2m_lock(d)   mm_lock(nestedp2m,
>> &(d)->arch.nested_p2m_lock)
>> +#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
>> +
>> +/* P2M lock (per-p2m-table)
>> + *
>> + * This protects all queries and updates to the p2m table.
>> + *
>> + * A note about ordering:
>> + *   The order established here is enforced on all mutations of a p2m.
>> + *   For lookups, the order established here is enforced only for hap
>> + *   domains (1. shadow domains present a few nasty inversions;
>> + *            2. shadow domains do not support paging and sharing,
>> + *               the main sources of dynamic p2m mutations)
>> + *
>> + * The lock is recursive as it is common for a code path to look up a
>> gfn
>> + * and later mutate it.
>> + */
>> +
>> +declare_mm_lock(p2m)
>> +#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
>> +#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
>> +#define p2m_unlock(p)         mm_unlock(&(p)->lock)
>> +#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
>> +
>>  /* Sharing per page lock
>>   *
>>   * This is an external lock, not represented by an mm_lock_t. The
>> memory
>
> Since you've just reversed the locking order between this page-sharing
> lock and the p2m lock, you need to update the comment that describes
> it.  Also, presumably, the code that it describes?
The comment might be stale, certainly, will look into it.

The code is just fine, per testing. The next patch does a proper cleanup:
the "complicated condition" is grabbing a p2m lock nested inside a
page-sharing critical section. But thanks to this patch, the p2m lock will
have been taken before, so no race (hope that makes sense).

Bottomline is, correct with this patch, clean with next.

Thanks!
Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:04:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:04:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsxGj-0001Uz-FF; Thu, 02 Feb 2012 14:04:09 +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 1RsxGi-0001Us-FP
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:04:08 +0000
Received: from [85.158.138.51:38872] by server-10.bemta-3.messagelabs.com id
	D6/2D-06813-7D79A2F4; Thu, 02 Feb 2012 14:04:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328191446!11736595!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7573 invoked from network); 2 Feb 2012 14:04:06 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-11.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 14:04:06 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 23B9F458081;
	Thu,  2 Feb 2012 06:04:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Lr+UEMrlxteQPNNaU+1MASPKj14sl+b0i2YQW/KT3wV7
	0CDg2u0e5iTWZOvhkBpqLq4Xl4vWcNgRWT1FF4H3HyL7QFnUuI/zRB8QuBOl1prl
	40cBQjpBVMWi0c8O6L7cquJOj70SadUtVaM6Q/FPG3BNv+mQSRkvak2Xa48d4zo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=rzbsLtnUuU3pKNm8KMekSWPCkNM=; b=m0bsGmfq
	9C1chRjh/XVocWjOX7dVm8oHO8k2TNLjm/XKBTZAUny+qwMTwiY9bqCTtMSY2dKu
	mxJzAhcrQEWTjuYpT/5Lv1nQyXepTsbnVKndXB7QCBix93z+VjDc1nT5MKiSyvzH
	EDumuLXfq60dIEsYSkX+QNBMsoMvpio3afw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id BC50945807B; 
	Thu,  2 Feb 2012 06:04:05 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 06:04:06 -0800
Message-ID: <5f8a579543cd9d4f86099af183c363bc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202131433.GM48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
	<20120202131433.GM48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 06:04:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:56 -0500 on 01 Feb (1328108167), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mm-locks.h |   10 ++++
>>  xen/arch/x86/mm/p2m-pod.c  |  112
>> ++++++++++++++++++++++++++------------------
>>  xen/arch/x86/mm/p2m-pt.c   |    1 +
>>  xen/arch/x86/mm/p2m.c      |    8 ++-
>>  xen/include/asm-x86/p2m.h  |   27 +++-------
>>  5 files changed, 93 insertions(+), 65 deletions(-)
>>
>>
>> The PoD layer has a comples locking discipline. It relies on the
>> p2m being globally locked, and it also relies on the page alloc
>> lock to protect some of its data structures. Replace this all by an
>> explicit pod lock: per p2m, order enforced.
>>
>> Three consequences:
>>     - Critical sections in the pod code protected by the page alloc
>>       lock are now reduced to modifications of the domain page list.
>>     - When the p2m lock becomes fine-grained, there are no
>>       assumptions broken in the PoD layer.
>>     - The locking is easier to understand.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> This needs an Ack from George, too.  Also:
>
>> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
>>
>>      /* FIXME: Figure out how to avoid superpages */
>> +    /* NOTE: Promote to globally locking the p2m. This will get
>> complicated
>> +     * in a fine-grained scenario. Even if we're to lock each gfn
>> +     * individually we must be careful about recursion limits and
>> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock
>> constraints
>> +     * between p2m and pod locks */
>> +    p2m_lock(p2m);
>
> That's a scary comment.  It looks to me as if the mm-locks.h mechanism
> _does_ enforce those constraints - am I missing something?

The problem is that the recurse count of a spinlock is not particularly
wide. So if you have a loop that does a lot of nested get_gfn*, you may
overflow.

The funny bit is that we do enforce ordering, so that part of the comment
is stale. Will update.

Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:04:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:04:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsxGj-0001Uz-FF; Thu, 02 Feb 2012 14:04:09 +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 1RsxGi-0001Us-FP
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:04:08 +0000
Received: from [85.158.138.51:38872] by server-10.bemta-3.messagelabs.com id
	D6/2D-06813-7D79A2F4; Thu, 02 Feb 2012 14:04:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328191446!11736595!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7573 invoked from network); 2 Feb 2012 14:04:06 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-11.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 14:04:06 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 23B9F458081;
	Thu,  2 Feb 2012 06:04:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Lr+UEMrlxteQPNNaU+1MASPKj14sl+b0i2YQW/KT3wV7
	0CDg2u0e5iTWZOvhkBpqLq4Xl4vWcNgRWT1FF4H3HyL7QFnUuI/zRB8QuBOl1prl
	40cBQjpBVMWi0c8O6L7cquJOj70SadUtVaM6Q/FPG3BNv+mQSRkvak2Xa48d4zo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=rzbsLtnUuU3pKNm8KMekSWPCkNM=; b=m0bsGmfq
	9C1chRjh/XVocWjOX7dVm8oHO8k2TNLjm/XKBTZAUny+qwMTwiY9bqCTtMSY2dKu
	mxJzAhcrQEWTjuYpT/5Lv1nQyXepTsbnVKndXB7QCBix93z+VjDc1nT5MKiSyvzH
	EDumuLXfq60dIEsYSkX+QNBMsoMvpio3afw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id BC50945807B; 
	Thu,  2 Feb 2012 06:04:05 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 06:04:06 -0800
Message-ID: <5f8a579543cd9d4f86099af183c363bc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202131433.GM48883@ocelot.phlegethon.org>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
	<20120202131433.GM48883@ocelot.phlegethon.org>
Date: Thu, 2 Feb 2012 06:04:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 14:56 -0500 on 01 Feb (1328108167), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mm-locks.h |   10 ++++
>>  xen/arch/x86/mm/p2m-pod.c  |  112
>> ++++++++++++++++++++++++++------------------
>>  xen/arch/x86/mm/p2m-pt.c   |    1 +
>>  xen/arch/x86/mm/p2m.c      |    8 ++-
>>  xen/include/asm-x86/p2m.h  |   27 +++-------
>>  5 files changed, 93 insertions(+), 65 deletions(-)
>>
>>
>> The PoD layer has a comples locking discipline. It relies on the
>> p2m being globally locked, and it also relies on the page alloc
>> lock to protect some of its data structures. Replace this all by an
>> explicit pod lock: per p2m, order enforced.
>>
>> Three consequences:
>>     - Critical sections in the pod code protected by the page alloc
>>       lock are now reduced to modifications of the domain page list.
>>     - When the p2m lock becomes fine-grained, there are no
>>       assumptions broken in the PoD layer.
>>     - The locking is easier to understand.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> This needs an Ack from George, too.  Also:
>
>> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
>>
>>      /* FIXME: Figure out how to avoid superpages */
>> +    /* NOTE: Promote to globally locking the p2m. This will get
>> complicated
>> +     * in a fine-grained scenario. Even if we're to lock each gfn
>> +     * individually we must be careful about recursion limits and
>> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock
>> constraints
>> +     * between p2m and pod locks */
>> +    p2m_lock(p2m);
>
> That's a scary comment.  It looks to me as if the mm-locks.h mechanism
> _does_ enforce those constraints - am I missing something?

The problem is that the recurse count of a spinlock is not particularly
wide. So if you have a loop that does a lot of nested get_gfn*, you may
overflow.

The funny bit is that we do enforce ordering, so that part of the comment
is stale. Will update.

Andres
>
> Cheers,
>
> Tim.
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:22:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1RsxYQ-0001qz-EZ; Thu, 02 Feb 2012 14:22:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsxYO-0001qq-VV
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:22:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328192537!13452256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22490 invoked from network); 2 Feb 2012 14:22:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 14:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10439942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:22:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 14:22:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsxYH-0007k0-2D;
	Thu, 02 Feb 2012 14:22:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsxYG-0001Qn-TF;
	Thu, 02 Feb 2012 14:22:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11824-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 14:22:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11824: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11824 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11824/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:22:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1RsxYQ-0001qz-EZ; Thu, 02 Feb 2012 14:22:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsxYO-0001qq-VV
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:22:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328192537!13452256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22490 invoked from network); 2 Feb 2012 14:22:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 14:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10439942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:22:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 14:22:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsxYH-0007k0-2D;
	Thu, 02 Feb 2012 14:22:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsxYG-0001Qn-TF;
	Thu, 02 Feb 2012 14:22:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11824-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 14:22:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11824: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11824 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11824/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:25:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1RsxbJ-00022r-6P; Thu, 02 Feb 2012 14:25:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsxbI-00022S-F3
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:25:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328192672!62787483!1
X-Originating-IP: [208.97.132.202]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21137 invoked from network); 2 Feb 2012 14:24:32 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 14:24:32 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 40D27604078;
	Thu,  2 Feb 2012 06:25:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Y/TAZyAvkS71CH15wfumnaTBx4iDLFF2f47BVKqirkWw
	czBu9+IHvjhGlG82JyvcAh/jfKsF5Ayoarh0f4TbjhpOMiE488MOc2eQxN/OPbm8
	mdRzsSZ4QoqVz2470a8Szgg+5RF6f3RsbetHPVnik1qHE2UzSeW6aYhOSRt9V+k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=4Xhqnu/aeMJMneA8p96POpvPf5w=; b=uXcSdAuG
	jUx5NspvgDkSo+O7LcR97H8KqT8joMuvEja35665/304O6+AVmv7u7/umfuXtiFs
	EQCk6s1rmtg95w6BUlXefFQxofkvtj+upcvW46wuAA+OgwjpbfbBh0wOOwkqXSBP
	eBLXu+qxhyPyKf96UepTCOl9Pgk6J6QQizA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 8C28C604061; 
	Thu,  2 Feb 2012 06:25:15 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 06:25:16 -0800
Message-ID: <148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328187397.5359.9.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
Date: Thu, 2 Feb 2012 06:25:16 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
>>
>>
>> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> +                        unsigned int op, unsigned int mode,
>> +                        uint64_t gfn, void *buffer)
>> +{
>> +    xen_mem_event_op_t meo;
>> +
>> +    memset(&meo, 0, sizeof(meo));
>> +
>> +    meo.op      = op;
>> +    meo.domain  = domain_id;
>> +    meo.gfn     = gfn;
>> +    meo.buffer  = (unsigned long) buffer;
>
> Hypercall arguments need to use the xc_hypercall_buffer stuff in order
> to ensure that the memory is safe to access from a hypercall (in
> particular that it is mlocked or similar)-- I don't see where that
> happens for this buffer.
>
> meo itself is bounced by do_memory_op so that is OK.
>
> I was also a little suspicious of ring_addr and shared_addr in
> xc_mem_event_control in this regard.
>
> Or does the mem sharing code make it's own arrangements for these sorts
> of things somewhere?

It's rather unclean. They do not get mlock'ed (and there is no sanity
check to ensure they're page-aligned). They should follow the pattern
established in xc_mem_paging_load. I'll get on it, probably a separate
patch.

There is a far more insidious problem that I'm not sure how to solve. Say
the pager dies unexpectedly. The page hosting the ring is returned to
dom0's free page pool, and then re-assigned to some other process. Xen
never gets to find out. At best, the domain crashes before an event is
generated. Perhaps, Xen posts at least one event. Worst-case scenario, the
guest generates a spate of events. Cases 2 & 3 corrupt the memory of some
other dom0 process.

I'm glad I got that off my chest :) While being a very rare race condition
(haven't actually experienced it), I am quite unsure of how to tackle it
cleanly.

Andres
>
> Ian.
>
>> +
>> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
>> +}
>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:25:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1RsxbJ-00022r-6P; Thu, 02 Feb 2012 14:25:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RsxbI-00022S-F3
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:25:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328192672!62787483!1
X-Originating-IP: [208.97.132.202]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21137 invoked from network); 2 Feb 2012 14:24:32 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 14:24:32 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 40D27604078;
	Thu,  2 Feb 2012 06:25:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Y/TAZyAvkS71CH15wfumnaTBx4iDLFF2f47BVKqirkWw
	czBu9+IHvjhGlG82JyvcAh/jfKsF5Ayoarh0f4TbjhpOMiE488MOc2eQxN/OPbm8
	mdRzsSZ4QoqVz2470a8Szgg+5RF6f3RsbetHPVnik1qHE2UzSeW6aYhOSRt9V+k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=4Xhqnu/aeMJMneA8p96POpvPf5w=; b=uXcSdAuG
	jUx5NspvgDkSo+O7LcR97H8KqT8joMuvEja35665/304O6+AVmv7u7/umfuXtiFs
	EQCk6s1rmtg95w6BUlXefFQxofkvtj+upcvW46wuAA+OgwjpbfbBh0wOOwkqXSBP
	eBLXu+qxhyPyKf96UepTCOl9Pgk6J6QQizA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 8C28C604061; 
	Thu,  2 Feb 2012 06:25:15 -0800 (PST)
Received: from 69.165.140.174 (proxying for 69.165.140.174)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 06:25:16 -0800
Message-ID: <148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328187397.5359.9.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
Date: Thu, 2 Feb 2012 06:25:16 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
>>
>>
>> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> +                        unsigned int op, unsigned int mode,
>> +                        uint64_t gfn, void *buffer)
>> +{
>> +    xen_mem_event_op_t meo;
>> +
>> +    memset(&meo, 0, sizeof(meo));
>> +
>> +    meo.op      = op;
>> +    meo.domain  = domain_id;
>> +    meo.gfn     = gfn;
>> +    meo.buffer  = (unsigned long) buffer;
>
> Hypercall arguments need to use the xc_hypercall_buffer stuff in order
> to ensure that the memory is safe to access from a hypercall (in
> particular that it is mlocked or similar)-- I don't see where that
> happens for this buffer.
>
> meo itself is bounced by do_memory_op so that is OK.
>
> I was also a little suspicious of ring_addr and shared_addr in
> xc_mem_event_control in this regard.
>
> Or does the mem sharing code make it's own arrangements for these sorts
> of things somewhere?

It's rather unclean. They do not get mlock'ed (and there is no sanity
check to ensure they're page-aligned). They should follow the pattern
established in xc_mem_paging_load. I'll get on it, probably a separate
patch.

There is a far more insidious problem that I'm not sure how to solve. Say
the pager dies unexpectedly. The page hosting the ring is returned to
dom0's free page pool, and then re-assigned to some other process. Xen
never gets to find out. At best, the domain crashes before an event is
generated. Perhaps, Xen posts at least one event. Worst-case scenario, the
guest generates a spate of events. Cases 2 & 3 corrupt the memory of some
other dom0 process.

I'm glad I got that off my chest :) While being a very rare race condition
(haven't actually experienced it), I am quite unsure of how to tackle it
cleanly.

Andres
>
> Ian.
>
>> +
>> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
>> +}
>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:29:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1Rsxek-0002Fq-RQ; Thu, 02 Feb 2012 14:28:58 +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 1Rsxej-0002Fk-0P
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:28:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328192895!50829591!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20460 invoked from network); 2 Feb 2012 14:28:15 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 14:28:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q12ESovM019433; Thu, 2 Feb 2012 14:28:50 GMT
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 q12ESooA000694; 
	Thu, 2 Feb 2012 09:28:50 -0500
Message-ID: <4F2A9DA4.7090500@tycho.nsa.gov>
Date: Thu, 02 Feb 2012 09:28:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1328173562.17444.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328173562.17444.108.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation
	functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/02/2012 04:06 AM, Ian Campbell wrote:
> On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
>> Add wrappers for getting and setting policy booleans by name or ID.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
>>  tools/flask/libflask/include/libflask.h |    3 ++
>>  2 files changed, 62 insertions(+), 0 deletions(-)
>>
>> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
>> index d4b8ef0..412a05d 100644
>> --- a/tools/flask/libflask/flask_op.c
>> +++ b/tools/flask/libflask/flask_op.c
>> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
>>      return 0;
>>  }
>>  
>> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
>> +{
>> +    flask_op_t op;
>> +    char buf[255];
>> +    int rv;
>> +
>> +    op.cmd = FLASK_GETBOOL2;
>> +    op.buf = buf;
>> +    op.size = 255;
> 
> sizeof(buf)? Here and elsewhere (including a few existing locations in
> flask_op.c).
> 
>> +
>> +    snprintf(buf, sizeof buf, "%i", id);
>> +
>> +    rv = xc_flask_op(xc_handle, &op);
>> +
>> +    if ( rv )
>> +        return rv;
>> +    
>> +    sscanf(buf, "%i %i %s", curr, pend, name);
> 
> Do you care about sscanf failures?
 
A failure here would be a sign of the hypervisor having made a format change
that is not backwards compatible. Checking it would be more complete, however.

> It seems from other uses in the file that buf can contain binary data so
> would it make sense to make this two ints as binary followed by a
> string? That would remove string parsing here and in the hypervisor
> (which seems more critical to me?)

That also seems far simpler to me; however, all the current FLASK hypercalls
are done via string parsing so deviating from this for new operations would
make them inconsistent.

If we didn't have to care about backwards compatibility I would convert the
entire flask_op hypercall to use a union-of-structures similar to domctl
because the string parsing introduces unneeded complexity.

> Is there a defined maximum for the length of "name"?

INITCONTEXTLEN = 256.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:29:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1Rsxek-0002Fq-RQ; Thu, 02 Feb 2012 14:28:58 +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 1Rsxej-0002Fk-0P
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:28:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328192895!50829591!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20460 invoked from network); 2 Feb 2012 14:28:15 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 14:28:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q12ESovM019433; Thu, 2 Feb 2012 14:28:50 GMT
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 q12ESooA000694; 
	Thu, 2 Feb 2012 09:28:50 -0500
Message-ID: <4F2A9DA4.7090500@tycho.nsa.gov>
Date: Thu, 02 Feb 2012 09:28:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1328173562.17444.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328173562.17444.108.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation
	functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/02/2012 04:06 AM, Ian Campbell wrote:
> On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
>> Add wrappers for getting and setting policy booleans by name or ID.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
>>  tools/flask/libflask/include/libflask.h |    3 ++
>>  2 files changed, 62 insertions(+), 0 deletions(-)
>>
>> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
>> index d4b8ef0..412a05d 100644
>> --- a/tools/flask/libflask/flask_op.c
>> +++ b/tools/flask/libflask/flask_op.c
>> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
>>      return 0;
>>  }
>>  
>> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
>> +{
>> +    flask_op_t op;
>> +    char buf[255];
>> +    int rv;
>> +
>> +    op.cmd = FLASK_GETBOOL2;
>> +    op.buf = buf;
>> +    op.size = 255;
> 
> sizeof(buf)? Here and elsewhere (including a few existing locations in
> flask_op.c).
> 
>> +
>> +    snprintf(buf, sizeof buf, "%i", id);
>> +
>> +    rv = xc_flask_op(xc_handle, &op);
>> +
>> +    if ( rv )
>> +        return rv;
>> +    
>> +    sscanf(buf, "%i %i %s", curr, pend, name);
> 
> Do you care about sscanf failures?
 
A failure here would be a sign of the hypervisor having made a format change
that is not backwards compatible. Checking it would be more complete, however.

> It seems from other uses in the file that buf can contain binary data so
> would it make sense to make this two ints as binary followed by a
> string? That would remove string parsing here and in the hypervisor
> (which seems more critical to me?)

That also seems far simpler to me; however, all the current FLASK hypercalls
are done via string parsing so deviating from this for new operations would
make them inconsistent.

If we didn't have to care about backwards compatibility I would convert the
entire flask_op hypercall to use a union-of-structures similar to domctl
because the string parsing introduces unneeded complexity.

> Is there a defined maximum for the length of "name"?

INITCONTEXTLEN = 256.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsxhJ-0002RY-DZ; Thu, 02 Feb 2012 14:31:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsxhH-0002Qs-AY
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:31:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328193088!6118002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23906 invoked from network); 2 Feb 2012 14:31:29 -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;
	2 Feb 2012 14:31:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180123259"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 09:31:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 09:31:27 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12EVN9g008082;
	Thu, 2 Feb 2012 06:31:24 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
Date: Thu, 2 Feb 2012 14:31:22 +0000
Message-ID: <1328193082.21722.31.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m
 lockups are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
> @@ -1445,7 +1449,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
>              nestedp2m_unlock(d);
>              return p2m;
>          }
> -        p2m_unlock(p2m);
> +        gfn_unlock(p2m, gfn, 0);
>      }

It looks like maybe you forgot to change the corresponding p2m_lock() to
gfn_lock(), here in p2m.c:p2m_get_nestedp2m()?

Other than that, I think the PoD stuff looks fine.  So regarding PoD
stuff:
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsxhJ-0002RY-DZ; Thu, 02 Feb 2012 14:31:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsxhH-0002Qs-AY
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:31:35 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328193088!6118002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23906 invoked from network); 2 Feb 2012 14:31:29 -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;
	2 Feb 2012 14:31:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180123259"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 09:31:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 09:31:27 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12EVN9g008082;
	Thu, 2 Feb 2012 06:31:24 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
Date: Thu, 2 Feb 2012 14:31:22 +0000
Message-ID: <1328193082.21722.31.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m
 lockups are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
> @@ -1445,7 +1449,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
>              nestedp2m_unlock(d);
>              return p2m;
>          }
> -        p2m_unlock(p2m);
> +        gfn_unlock(p2m, gfn, 0);
>      }

It looks like maybe you forgot to change the corresponding p2m_lock() to
gfn_lock(), here in p2m.c:p2m_get_nestedp2m()?

Other than that, I think the PoD stuff looks fine.  So regarding PoD
stuff:
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1RsxrB-0002tx-J4; Thu, 02 Feb 2012 14:41:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsxrA-0002tp-C7
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:41:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328193701!9821357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7249 invoked from network); 2 Feb 2012 14:41:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 14:41:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10440637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:41:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:41:41 +0000
Message-ID: <1328193700.2924.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 2 Feb 2012 14:41:40 +0000
In-Reply-To: <1328119839-1168-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 3/3] libxl_qmp: remove libxl__qmp_migrate,
 introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 18:10 +0000, Stefano Stabellini wrote:
> Following the recent changes to upstream Qemu, the best monitor command
> to suit or needs is "save_devices" rather than "migrate".
> This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
> instead, that uses "save_devices".
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c      |   11 +-----
>  tools/libxl/libxl_internal.h |    2 +-
>  tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
>  3 files changed, 5 insertions(+), 90 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index a6eb714..40ebcd1 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -771,18 +771,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>          break;
>      }
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> -        if (fd2 < 0) {
> -            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> -                             "Unable to create a QEMU save file\n");
> -            return ERROR_FAIL;
> -        }
> -        /* Save DM state into fd2 */
> -        ret = libxl__qmp_migrate(gc, domid, fd2);
> +        ret = libxl__qmp_save(gc, domid, (char *)filename);

I don't think you need this cast, your qmp_save takes a const char *.

Otherwise this all looks alright to me.

Ian.

>          if (ret)
>              goto out;
> -        close(fd2);
> -        fd2 = -1;
>          break;
>      default:
>          return ERROR_INVAL;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 3c8da45..6d11cfe 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -619,7 +619,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
>  _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
>                                 libxl_device_pci *pcidev);
>  /* Save current QEMU state into fd. */
> -_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
> +_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
>  /* close and free the QMP handler */
>  _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
>  /* remove the socket file, if the file has already been removed,
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 6d401b7..19bf699 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -533,52 +533,6 @@ out:
>      return rc;
>  }
>  
> -static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
> -                       libxl_key_value_list *args,
> -                       qmp_callback_t callback, void *opaque,
> -                       qmp_request_context *context,
> -                       int fd)
> -{
> -    struct msghdr msg = { 0 };
> -    struct cmsghdr *cmsg;
> -    char control[CMSG_SPACE(sizeof (fd))];
> -    struct iovec iov;
> -    char *buf = NULL;
> -
> -    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
> -
> -    /* Response data */
> -    iov.iov_base = buf;
> -    iov.iov_len  = strlen(buf);
> -
> -    /* compose the message */
> -    msg.msg_iov = &iov;
> -    msg.msg_iovlen = 1;
> -    msg.msg_control = control;
> -    msg.msg_controllen = sizeof (control);
> -
> -    /* attach open fd */
> -    cmsg = CMSG_FIRSTHDR(&msg);
> -    cmsg->cmsg_level = SOL_SOCKET;
> -    cmsg->cmsg_type = SCM_RIGHTS;
> -    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
> -    *(int *)CMSG_DATA(cmsg) = fd;
> -
> -    msg.msg_controllen = cmsg->cmsg_len;
> -
> -    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
> -        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
> -                         "Failed to send a QMP message to QEMU.");
> -        return ERROR_FAIL;
> -    }
> -    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
> -                            "CRLF", "QMP socket")) {
> -        return ERROR_FAIL;
> -    }
> -
> -    return qmp->last_id_used;
> -}
> -
>  static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>                                  libxl_key_value_list *args,
>                                  qmp_callback_t callback, void *opaque,
> @@ -815,34 +769,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
>      return qmp_device_del(gc, domid, id);
>  }
>  
> -static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
> -                     int fd, const char *name)
> -{
> -    flexarray_t *parameters = NULL;
> -    libxl_key_value_list args = NULL;
> -    int rc = 0;
> -
> -    parameters = flexarray_make(2, 1);
> -    if (!parameters)
> -        return ERROR_NOMEM;
> -    flexarray_append_pair(parameters, "fdname", (char*)name);
> -    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
> -    if (!args) {
> -        rc = ERROR_NOMEM;
> -        goto out;
> -    }
> -
> -    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
> -        rc = ERROR_FAIL;
> -    }
> -out:
> -    flexarray_free(parameters);
> -    return rc;
> -}
> -
> -int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
> +int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
>  {
> -#define MIGRATE_FD_NAME "dm-migrate"
>      libxl__qmp_handler *qmp = NULL;
>      flexarray_t *parameters = NULL;
>      libxl_key_value_list args = NULL;
> @@ -852,23 +780,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
>      if (!qmp)
>          return ERROR_FAIL;
>  
> -    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
> -    if (rc)
> -        goto out;
> -
>      parameters = flexarray_make(2, 1);
>      if (!parameters) {
>          rc = ERROR_NOMEM;
>          goto out;
>      }
> -    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
> +    flexarray_append_pair(parameters, "filename", (char *)filename);
>      args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
>      if (!args) {
>          rc = ERROR_NOMEM;
>          goto out2;
>      }
>  
> -    rc = qmp_synchronous_send(qmp, "migrate", &args,
> +    rc = qmp_synchronous_send(qmp, "save_devices", &args,
>                                NULL, NULL, qmp->timeout);
>  
>  out2:



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1RsxrB-0002tx-J4; Thu, 02 Feb 2012 14:41:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsxrA-0002tp-C7
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:41:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328193701!9821357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7249 invoked from network); 2 Feb 2012 14:41:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 14:41:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10440637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:41:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:41:41 +0000
Message-ID: <1328193700.2924.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 2 Feb 2012 14:41:40 +0000
In-Reply-To: <1328119839-1168-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 3/3] libxl_qmp: remove libxl__qmp_migrate,
 introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 18:10 +0000, Stefano Stabellini wrote:
> Following the recent changes to upstream Qemu, the best monitor command
> to suit or needs is "save_devices" rather than "migrate".
> This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
> instead, that uses "save_devices".
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c      |   11 +-----
>  tools/libxl/libxl_internal.h |    2 +-
>  tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
>  3 files changed, 5 insertions(+), 90 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index a6eb714..40ebcd1 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -771,18 +771,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>          break;
>      }
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> -        if (fd2 < 0) {
> -            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> -                             "Unable to create a QEMU save file\n");
> -            return ERROR_FAIL;
> -        }
> -        /* Save DM state into fd2 */
> -        ret = libxl__qmp_migrate(gc, domid, fd2);
> +        ret = libxl__qmp_save(gc, domid, (char *)filename);

I don't think you need this cast, your qmp_save takes a const char *.

Otherwise this all looks alright to me.

Ian.

>          if (ret)
>              goto out;
> -        close(fd2);
> -        fd2 = -1;
>          break;
>      default:
>          return ERROR_INVAL;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 3c8da45..6d11cfe 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -619,7 +619,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
>  _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
>                                 libxl_device_pci *pcidev);
>  /* Save current QEMU state into fd. */
> -_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
> +_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
>  /* close and free the QMP handler */
>  _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
>  /* remove the socket file, if the file has already been removed,
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 6d401b7..19bf699 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -533,52 +533,6 @@ out:
>      return rc;
>  }
>  
> -static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
> -                       libxl_key_value_list *args,
> -                       qmp_callback_t callback, void *opaque,
> -                       qmp_request_context *context,
> -                       int fd)
> -{
> -    struct msghdr msg = { 0 };
> -    struct cmsghdr *cmsg;
> -    char control[CMSG_SPACE(sizeof (fd))];
> -    struct iovec iov;
> -    char *buf = NULL;
> -
> -    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
> -
> -    /* Response data */
> -    iov.iov_base = buf;
> -    iov.iov_len  = strlen(buf);
> -
> -    /* compose the message */
> -    msg.msg_iov = &iov;
> -    msg.msg_iovlen = 1;
> -    msg.msg_control = control;
> -    msg.msg_controllen = sizeof (control);
> -
> -    /* attach open fd */
> -    cmsg = CMSG_FIRSTHDR(&msg);
> -    cmsg->cmsg_level = SOL_SOCKET;
> -    cmsg->cmsg_type = SCM_RIGHTS;
> -    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
> -    *(int *)CMSG_DATA(cmsg) = fd;
> -
> -    msg.msg_controllen = cmsg->cmsg_len;
> -
> -    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
> -        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
> -                         "Failed to send a QMP message to QEMU.");
> -        return ERROR_FAIL;
> -    }
> -    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
> -                            "CRLF", "QMP socket")) {
> -        return ERROR_FAIL;
> -    }
> -
> -    return qmp->last_id_used;
> -}
> -
>  static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
>                                  libxl_key_value_list *args,
>                                  qmp_callback_t callback, void *opaque,
> @@ -815,34 +769,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
>      return qmp_device_del(gc, domid, id);
>  }
>  
> -static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
> -                     int fd, const char *name)
> -{
> -    flexarray_t *parameters = NULL;
> -    libxl_key_value_list args = NULL;
> -    int rc = 0;
> -
> -    parameters = flexarray_make(2, 1);
> -    if (!parameters)
> -        return ERROR_NOMEM;
> -    flexarray_append_pair(parameters, "fdname", (char*)name);
> -    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
> -    if (!args) {
> -        rc = ERROR_NOMEM;
> -        goto out;
> -    }
> -
> -    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
> -        rc = ERROR_FAIL;
> -    }
> -out:
> -    flexarray_free(parameters);
> -    return rc;
> -}
> -
> -int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
> +int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
>  {
> -#define MIGRATE_FD_NAME "dm-migrate"
>      libxl__qmp_handler *qmp = NULL;
>      flexarray_t *parameters = NULL;
>      libxl_key_value_list args = NULL;
> @@ -852,23 +780,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
>      if (!qmp)
>          return ERROR_FAIL;
>  
> -    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
> -    if (rc)
> -        goto out;
> -
>      parameters = flexarray_make(2, 1);
>      if (!parameters) {
>          rc = ERROR_NOMEM;
>          goto out;
>      }
> -    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
> +    flexarray_append_pair(parameters, "filename", (char *)filename);
>      args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
>      if (!args) {
>          rc = ERROR_NOMEM;
>          goto out2;
>      }
>  
> -    rc = qmp_synchronous_send(qmp, "migrate", &args,
> +    rc = qmp_synchronous_send(qmp, "save_devices", &args,
>                                NULL, NULL, qmp->timeout);
>  
>  out2:



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:50:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1RsxzS-0003Bx-Uj; Thu, 02 Feb 2012 14:50:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsxzR-0003Bs-Sa
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:50:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328194214!5179440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11171 invoked from network); 2 Feb 2012 14:50:14 -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;
	2 Feb 2012 14:50:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10440982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:50:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:50:13 +0000
Message-ID: <1328194212.2924.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 2 Feb 2012 14:50:12 +0000
In-Reply-To: <4F2A9DA4.7090500@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1328173562.17444.108.camel@zakaz.uk.xensource.com>
	<4F2A9DA4.7090500@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation
 functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 14:28 +0000, Daniel De Graaf wrote:
> On 02/02/2012 04:06 AM, Ian Campbell wrote:
> > On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
> >> Add wrappers for getting and setting policy booleans by name or ID.
> >>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> ---
> >>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
> >>  tools/flask/libflask/include/libflask.h |    3 ++
> >>  2 files changed, 62 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
> >> index d4b8ef0..412a05d 100644
> >> --- a/tools/flask/libflask/flask_op.c
> >> +++ b/tools/flask/libflask/flask_op.c
> >> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
> >>      return 0;
> >>  }
> >>  
> >> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
> >> +{
> >> +    flask_op_t op;
> >> +    char buf[255];
> >> +    int rv;
> >> +
> >> +    op.cmd = FLASK_GETBOOL2;
> >> +    op.buf = buf;
> >> +    op.size = 255;
> > 
> > sizeof(buf)? Here and elsewhere (including a few existing locations in
> > flask_op.c).
> > 
> >> +
> >> +    snprintf(buf, sizeof buf, "%i", id);
> >> +
> >> +    rv = xc_flask_op(xc_handle, &op);
> >> +
> >> +    if ( rv )
> >> +        return rv;
> >> +    
> >> +    sscanf(buf, "%i %i %s", curr, pend, name);
> > 
> > Do you care about sscanf failures?
>  
> A failure here would be a sign of the hypervisor having made a format change
> that is not backwards compatible. Checking it would be more complete, however.
> 
> > It seems from other uses in the file that buf can contain binary data so
> > would it make sense to make this two ints as binary followed by a
> > string? That would remove string parsing here and in the hypervisor
> > (which seems more critical to me?)
> 
> That also seems far simpler to me; however, all the current FLASK hypercalls
> are done via string parsing so deviating from this for new operations would
> make them inconsistent.

OK. I thought I'd seen some binary muddling in their but I must have
been mistaken.

> If we didn't have to care about backwards compatibility I would convert the
> entire flask_op hypercall to use a union-of-structures similar to domctl
> because the string parsing introduces unneeded complexity.

How much do we care about backwards compat for this interface? Isn't it
a tools only dom0 interface?

> > Is there a defined maximum for the length of "name"?
> 
> INITCONTEXTLEN = 256.

So the max size of the buffer is 256 + whatever two int and two spaces
might maximally take, but your buffer is exactly 256.



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:50:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1RsxzS-0003Bx-Uj; Thu, 02 Feb 2012 14:50:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsxzR-0003Bs-Sa
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:50:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328194214!5179440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11171 invoked from network); 2 Feb 2012 14:50:14 -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;
	2 Feb 2012 14:50:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10440982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:50:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:50:13 +0000
Message-ID: <1328194212.2924.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 2 Feb 2012 14:50:12 +0000
In-Reply-To: <4F2A9DA4.7090500@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1328173562.17444.108.camel@zakaz.uk.xensource.com>
	<4F2A9DA4.7090500@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation
 functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 14:28 +0000, Daniel De Graaf wrote:
> On 02/02/2012 04:06 AM, Ian Campbell wrote:
> > On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
> >> Add wrappers for getting and setting policy booleans by name or ID.
> >>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> ---
> >>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
> >>  tools/flask/libflask/include/libflask.h |    3 ++
> >>  2 files changed, 62 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
> >> index d4b8ef0..412a05d 100644
> >> --- a/tools/flask/libflask/flask_op.c
> >> +++ b/tools/flask/libflask/flask_op.c
> >> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
> >>      return 0;
> >>  }
> >>  
> >> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
> >> +{
> >> +    flask_op_t op;
> >> +    char buf[255];
> >> +    int rv;
> >> +
> >> +    op.cmd = FLASK_GETBOOL2;
> >> +    op.buf = buf;
> >> +    op.size = 255;
> > 
> > sizeof(buf)? Here and elsewhere (including a few existing locations in
> > flask_op.c).
> > 
> >> +
> >> +    snprintf(buf, sizeof buf, "%i", id);
> >> +
> >> +    rv = xc_flask_op(xc_handle, &op);
> >> +
> >> +    if ( rv )
> >> +        return rv;
> >> +    
> >> +    sscanf(buf, "%i %i %s", curr, pend, name);
> > 
> > Do you care about sscanf failures?
>  
> A failure here would be a sign of the hypervisor having made a format change
> that is not backwards compatible. Checking it would be more complete, however.
> 
> > It seems from other uses in the file that buf can contain binary data so
> > would it make sense to make this two ints as binary followed by a
> > string? That would remove string parsing here and in the hypervisor
> > (which seems more critical to me?)
> 
> That also seems far simpler to me; however, all the current FLASK hypercalls
> are done via string parsing so deviating from this for new operations would
> make them inconsistent.

OK. I thought I'd seen some binary muddling in their but I must have
been mistaken.

> If we didn't have to care about backwards compatibility I would convert the
> entire flask_op hypercall to use a union-of-structures similar to domctl
> because the string parsing introduces unneeded complexity.

How much do we care about backwards compat for this interface? Isn't it
a tools only dom0 interface?

> > Is there a defined maximum for the length of "name"?
> 
> INITCONTEXTLEN = 256.

So the max size of the buffer is 256 + whatever two int and two spaces
might maximally take, but your buffer is exactly 256.



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:58:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsy6d-0003gz-SU; Thu, 02 Feb 2012 14:57:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)
	id 1Rsy6b-0003gK-Up; Thu, 02 Feb 2012 14:57:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328194659!4797113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31089 invoked from network); 2 Feb 2012 14:57:39 -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;
	2 Feb 2012 14:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10441362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:57:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 14:57:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rsy6U-0007vv-Nu; Thu, 02 Feb 2012 14:57:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rsy6U-00010X-MQ;
	Thu, 02 Feb 2012 14:57:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="HHZH3Hmzow"
Content-Transfer-Encoding: 7bit
Message-ID: <20266.42082.681461.226312@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 14:57:38 +0000
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	oss-security@lists.openwall.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen Security Advisory 6 (CVE-2012-0029) - HVM e1000,
	buffer overflow
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: security@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--HHZH3Hmzow
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

              Xen Security Advisory CVE-2012-0029 / XSA-6

            qemu-dm Local Privilege Escalation Vulnerability

ISSUE DESCRIPTION
=================

Heap-based buffer overflow in the process_tx_desc function in the
e1000 emulation allows the guest to cause a denial of service (QEMU
crash) and possibly execute arbitrary code via crafted legacy mode
packets.

Upstream qemu has already released an advisory hence there is no
embargo.

VULNERABLE SYSTEMS
==================

The vulnerability impacts any host running HVM (Fully-Emulated) guests
which are configured with an e1000 NIC (using "model=e1000") in their
VIF configuration. Note that the default emulated NIC is "rtl8139"
which is not vulnerable.

Hosts which run only PV guests or which use the default rtl813939 NIC
are not effected.

MITIGATION
==========

Switching all HVM guests to a different emulated NIC (e.g. rtl8139,
which is the default) or PV network drivers will remove this
vulnerability.

Enabling device model stub domains for such guests will also mitigate
any arbitrary code execution exploit by restricting it to the stub
domain only.

RESOLUTION
==========

This issue is resolved in the following changesets:
  qemu-xen-unstable.git      ebe37b2a3f844bad02dcc30d081f39eda06118f8
  qemu-xen-4.1-testing.git   3cf61880403b4e484539596a95937cc066243388
  qemu-xen-4.0-testing.git   36984c285a765541b04f378bfa84d2c850c167d3

In each case the QEMU_TAG in the corresponding xen.hg repository has
been updated so that a completely fresh build will pick up the fix:
  xen-unstable.hg      24673:fcc071c31e3a3ccc5dfaefd091eedbb608604928
  xen-4.1-testing.hg   23224:cccd6c68e1b9527f556deef760713380801db9b5
  xen-4.0-testing.hg   21563:3feb83eed6bdd515b90aca528c1ebd83dfb7a378
(Currently in http://xenbits.xen.org/staging/xen-*.hg; will be
 in http://xenbits.xen.org/staging/xen*.hg after automated tests.)


PATCH INFORMATION
=================

The patch is 65f82df0d7a71ce1b10cd4c5ab08888d176ac840 in the upstream
qemu.git tree.  A backported version, as has been applied to
qemu-xen-*.git, is attached as cve-2012-0029-qemu-xen-unstable.patch.

$ sha256sum cve-2012-0029-qemu-xen-unstable.patch 
dae528d93e44494ad0d682dc40b19ff8232cff5807ff331bef3d91ca169de9af  cve-2012-0029-qemu-xen-unstable.patch

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

iQEcBAEBAgAGBQJPKqLEAAoJEIP+FMlX6CvZoNIIAJIFsDhYfTBS9+06lMm6hX9u
lPJG/Or2d5KhfaQZlBfLG0SRG8wtALsmXY5z6anxFG+NG7uBDb3oOj+gd+7d/gIk
8NXQPgs4/MpoaeSjdxm/+XkBfNSladUy8S47BLvpExtW68WLQ5EEw12jU0hGgZEJ
/pI7in1Ypw3PBAFQM7hHraqV4u0akOes+do/TXHA98P/xE4UG3dsEz+YSWjnxw3C
wd7xibqYNU7/OQmWbnc6CSGo6pEgrg7UsYe+KIs7H83oHrZgQpnDpqzGyAldBFqW
hheFNzCKe7armeMDqxhm3D3ksMjck2yhENb7D9ebJNl/SXle/dLoyOfAOCWEZ1A=
=sC0B
-----END PGP SIGNATURE-----


--HHZH3Hmzow
Content-Type: text/plain; name="cve-2012-0029-qemu-xen-unstable.patch"
Content-Description: CVE-2012-0029 fix for qemu-xen
Content-Disposition: inline;
	filename="cve-2012-0029-qemu-xen-unstable.patch"
Content-Transfer-Encoding: 7bit

diff --git a/hw/e1000.c b/hw/e1000.c
index bb3689e..97104ed 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
             bytes = split_size;
             if (tp->size + bytes > msh)
                 bytes = msh - tp->size;
+
+            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
             cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
             if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
                 memmove(tp->header, tp->data, hdr);
@@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
         // context descriptor TSE is not set, while data descriptor TSE is set
         DBGOUT(TXERR, "TCP segmentaion Error\n");
     } else {
+        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
         cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
         tp->size += split_size;
     }

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

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

--HHZH3Hmzow--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14:58:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsy6d-0003gz-SU; Thu, 02 Feb 2012 14:57:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)
	id 1Rsy6b-0003gK-Up; Thu, 02 Feb 2012 14:57:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328194659!4797113!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31089 invoked from network); 2 Feb 2012 14:57:39 -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;
	2 Feb 2012 14:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10441362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:57:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 14:57:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rsy6U-0007vv-Nu; Thu, 02 Feb 2012 14:57:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rsy6U-00010X-MQ;
	Thu, 02 Feb 2012 14:57:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="HHZH3Hmzow"
Content-Transfer-Encoding: 7bit
Message-ID: <20266.42082.681461.226312@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 14:57:38 +0000
To: xen-announce@lists.xensource.com, xen-devel@lists.xensource.com,
	oss-security@lists.openwall.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen Security Advisory 6 (CVE-2012-0029) - HVM e1000,
	buffer overflow
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: security@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--HHZH3Hmzow
Content-Type: text/plain; charset="us-ascii"
Content-Description: message body text
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

              Xen Security Advisory CVE-2012-0029 / XSA-6

            qemu-dm Local Privilege Escalation Vulnerability

ISSUE DESCRIPTION
=================

Heap-based buffer overflow in the process_tx_desc function in the
e1000 emulation allows the guest to cause a denial of service (QEMU
crash) and possibly execute arbitrary code via crafted legacy mode
packets.

Upstream qemu has already released an advisory hence there is no
embargo.

VULNERABLE SYSTEMS
==================

The vulnerability impacts any host running HVM (Fully-Emulated) guests
which are configured with an e1000 NIC (using "model=e1000") in their
VIF configuration. Note that the default emulated NIC is "rtl8139"
which is not vulnerable.

Hosts which run only PV guests or which use the default rtl813939 NIC
are not effected.

MITIGATION
==========

Switching all HVM guests to a different emulated NIC (e.g. rtl8139,
which is the default) or PV network drivers will remove this
vulnerability.

Enabling device model stub domains for such guests will also mitigate
any arbitrary code execution exploit by restricting it to the stub
domain only.

RESOLUTION
==========

This issue is resolved in the following changesets:
  qemu-xen-unstable.git      ebe37b2a3f844bad02dcc30d081f39eda06118f8
  qemu-xen-4.1-testing.git   3cf61880403b4e484539596a95937cc066243388
  qemu-xen-4.0-testing.git   36984c285a765541b04f378bfa84d2c850c167d3

In each case the QEMU_TAG in the corresponding xen.hg repository has
been updated so that a completely fresh build will pick up the fix:
  xen-unstable.hg      24673:fcc071c31e3a3ccc5dfaefd091eedbb608604928
  xen-4.1-testing.hg   23224:cccd6c68e1b9527f556deef760713380801db9b5
  xen-4.0-testing.hg   21563:3feb83eed6bdd515b90aca528c1ebd83dfb7a378
(Currently in http://xenbits.xen.org/staging/xen-*.hg; will be
 in http://xenbits.xen.org/staging/xen*.hg after automated tests.)


PATCH INFORMATION
=================

The patch is 65f82df0d7a71ce1b10cd4c5ab08888d176ac840 in the upstream
qemu.git tree.  A backported version, as has been applied to
qemu-xen-*.git, is attached as cve-2012-0029-qemu-xen-unstable.patch.

$ sha256sum cve-2012-0029-qemu-xen-unstable.patch 
dae528d93e44494ad0d682dc40b19ff8232cff5807ff331bef3d91ca169de9af  cve-2012-0029-qemu-xen-unstable.patch

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

iQEcBAEBAgAGBQJPKqLEAAoJEIP+FMlX6CvZoNIIAJIFsDhYfTBS9+06lMm6hX9u
lPJG/Or2d5KhfaQZlBfLG0SRG8wtALsmXY5z6anxFG+NG7uBDb3oOj+gd+7d/gIk
8NXQPgs4/MpoaeSjdxm/+XkBfNSladUy8S47BLvpExtW68WLQ5EEw12jU0hGgZEJ
/pI7in1Ypw3PBAFQM7hHraqV4u0akOes+do/TXHA98P/xE4UG3dsEz+YSWjnxw3C
wd7xibqYNU7/OQmWbnc6CSGo6pEgrg7UsYe+KIs7H83oHrZgQpnDpqzGyAldBFqW
hheFNzCKe7armeMDqxhm3D3ksMjck2yhENb7D9ebJNl/SXle/dLoyOfAOCWEZ1A=
=sC0B
-----END PGP SIGNATURE-----


--HHZH3Hmzow
Content-Type: text/plain; name="cve-2012-0029-qemu-xen-unstable.patch"
Content-Description: CVE-2012-0029 fix for qemu-xen
Content-Disposition: inline;
	filename="cve-2012-0029-qemu-xen-unstable.patch"
Content-Transfer-Encoding: 7bit

diff --git a/hw/e1000.c b/hw/e1000.c
index bb3689e..97104ed 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
             bytes = split_size;
             if (tp->size + bytes > msh)
                 bytes = msh - tp->size;
+
+            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
             cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
             if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
                 memmove(tp->header, tp->data, hdr);
@@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
         // context descriptor TSE is not set, while data descriptor TSE is set
         DBGOUT(TXERR, "TCP segmentaion Error\n");
     } else {
+        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
         cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
         tp->size += split_size;
     }

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

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

--HHZH3Hmzow--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:58:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1Rsy7B-0003ku-Di; Thu, 02 Feb 2012 14:58:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rsy7A-0003k6-D0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:58:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328194694!13046348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23449 invoked from network); 2 Feb 2012 14:58:14 -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;
	2 Feb 2012 14:58:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10441418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:58:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:58:13 +0000
Message-ID: <1328194692.2924.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Thu, 2 Feb 2012 14:58:12 +0000
In-Reply-To: <148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> >>
> >>
> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> >> +                        unsigned int op, unsigned int mode,
> >> +                        uint64_t gfn, void *buffer)
> >> +{
> >> +    xen_mem_event_op_t meo;
> >> +
> >> +    memset(&meo, 0, sizeof(meo));
> >> +
> >> +    meo.op      = op;
> >> +    meo.domain  = domain_id;
> >> +    meo.gfn     = gfn;
> >> +    meo.buffer  = (unsigned long) buffer;
> >
> > Hypercall arguments need to use the xc_hypercall_buffer stuff in order
> > to ensure that the memory is safe to access from a hypercall (in
> > particular that it is mlocked or similar)-- I don't see where that
> > happens for this buffer.
> >
> > meo itself is bounced by do_memory_op so that is OK.
> >
> > I was also a little suspicious of ring_addr and shared_addr in
> > xc_mem_event_control in this regard.
> >
> > Or does the mem sharing code make it's own arrangements for these sorts
> > of things somewhere?
> 
> It's rather unclean. They do not get mlock'ed (and there is no sanity
> check to ensure they're page-aligned). They should follow the pattern
> established in xc_mem_paging_load. I'll get on it, probably a separate
> patch.

If you are reworking this It Would Be Nice If (tm) you could make it use
xc_hypercall_buffer_alloc and friends to allocate and manage the buffer
while you are there e.g. the void *buffer above would become struct
xc_hypercall_buffer *buffer -- see xc_perfc_query for example.

It happens that mlock has roughly the semantics we need (and so it
mostly works) but it is not guaranteed by the specs. At some point we
may wish to do something more robust and using the common interface will
mean that the sharing code will benefit from that too.

> There is a far more insidious problem that I'm not sure how to solve. Say
> the pager dies unexpectedly. The page hosting the ring is returned to
> dom0's free page pool, and then re-assigned to some other process. Xen
> never gets to find out. At best, the domain crashes before an event is
> generated. Perhaps, Xen posts at least one event. Worst-case scenario, the
> guest generates a spate of events. Cases 2 & 3 corrupt the memory of some
> other dom0 process.

How does the memory actually get mapped? Or is it actually memory
belonging to the user process?

The gntalloc driver presumably has a similar sort of problem, might be
interesting to take inspiration from there?

There's the possibility of having a paging specific driver which takes
care of this and all the userspace does is mmap /dev/xen/pager or
whatever.

> I'm glad I got that off my chest :) While being a very rare race condition
> (haven't actually experienced it), I am quite unsure of how to tackle it
> cleanly.
> 
> Andres
> >
> > Ian.
> >
> >> +
> >> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
> >> +}
> >
> >
> >
> >
> 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 14:58:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 14: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.xensource.com>)
	id 1Rsy7B-0003ku-Di; Thu, 02 Feb 2012 14:58:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rsy7A-0003k6-D0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:58:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328194694!13046348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23449 invoked from network); 2 Feb 2012 14:58:14 -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;
	2 Feb 2012 14:58:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10441418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 14:58:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:58:13 +0000
Message-ID: <1328194692.2924.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Thu, 2 Feb 2012 14:58:12 +0000
In-Reply-To: <148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> >>
> >>
> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> >> +                        unsigned int op, unsigned int mode,
> >> +                        uint64_t gfn, void *buffer)
> >> +{
> >> +    xen_mem_event_op_t meo;
> >> +
> >> +    memset(&meo, 0, sizeof(meo));
> >> +
> >> +    meo.op      = op;
> >> +    meo.domain  = domain_id;
> >> +    meo.gfn     = gfn;
> >> +    meo.buffer  = (unsigned long) buffer;
> >
> > Hypercall arguments need to use the xc_hypercall_buffer stuff in order
> > to ensure that the memory is safe to access from a hypercall (in
> > particular that it is mlocked or similar)-- I don't see where that
> > happens for this buffer.
> >
> > meo itself is bounced by do_memory_op so that is OK.
> >
> > I was also a little suspicious of ring_addr and shared_addr in
> > xc_mem_event_control in this regard.
> >
> > Or does the mem sharing code make it's own arrangements for these sorts
> > of things somewhere?
> 
> It's rather unclean. They do not get mlock'ed (and there is no sanity
> check to ensure they're page-aligned). They should follow the pattern
> established in xc_mem_paging_load. I'll get on it, probably a separate
> patch.

If you are reworking this It Would Be Nice If (tm) you could make it use
xc_hypercall_buffer_alloc and friends to allocate and manage the buffer
while you are there e.g. the void *buffer above would become struct
xc_hypercall_buffer *buffer -- see xc_perfc_query for example.

It happens that mlock has roughly the semantics we need (and so it
mostly works) but it is not guaranteed by the specs. At some point we
may wish to do something more robust and using the common interface will
mean that the sharing code will benefit from that too.

> There is a far more insidious problem that I'm not sure how to solve. Say
> the pager dies unexpectedly. The page hosting the ring is returned to
> dom0's free page pool, and then re-assigned to some other process. Xen
> never gets to find out. At best, the domain crashes before an event is
> generated. Perhaps, Xen posts at least one event. Worst-case scenario, the
> guest generates a spate of events. Cases 2 & 3 corrupt the memory of some
> other dom0 process.

How does the memory actually get mapped? Or is it actually memory
belonging to the user process?

The gntalloc driver presumably has a similar sort of problem, might be
interesting to take inspiration from there?

There's the possibility of having a paging specific driver which takes
care of this and all the userspace does is mmap /dev/xen/pager or
whatever.

> I'm glad I got that off my chest :) While being a very rare race condition
> (haven't actually experienced it), I am quite unsure of how to tackle it
> cleanly.
> 
> Andres
> >
> > Ian.
> >
> >> +
> >> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
> >> +}
> >
> >
> >
> >
> 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:22:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyTu-0004pP-7p; Thu, 02 Feb 2012 15:21:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsyTt-0004oy-0o
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:21:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328196102!13163414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28652 invoked from network); 2 Feb 2012 15:21: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;
	2 Feb 2012 15:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10442891"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:21:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:21:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsyTm-00084P-5S;
	Thu, 02 Feb 2012 15:21:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsyTl-0002FD-Cl;
	Thu, 02 Feb 2012 15:21:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11825-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 15:21:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 11643
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 11643
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 11643
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 build-i386                    4 xen-build                    fail   like 11637
 build-i386-oldkern            4 xen-build                    fail   like 11637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e2e2df4224e2
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.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                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 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-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 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 1340 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:22:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyTu-0004pP-7p; Thu, 02 Feb 2012 15:21:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsyTt-0004oy-0o
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:21:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328196102!13163414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28652 invoked from network); 2 Feb 2012 15:21: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;
	2 Feb 2012 15:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10442891"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:21:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:21:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RsyTm-00084P-5S;
	Thu, 02 Feb 2012 15:21:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsyTl-0002FD-Cl;
	Thu, 02 Feb 2012 15:21:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11825-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 15:21:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 11643
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 11643
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 11643
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 build-i386                    4 xen-build                    fail   like 11637
 build-i386-oldkern            4 xen-build                    fail   like 11637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e2e2df4224e2
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.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                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 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-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 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 1340 lines long.)

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:22:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15: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.xensource.com>)
	id 1RsyUR-0004tK-MR; Thu, 02 Feb 2012 15:22:23 +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 1RsyUQ-0004sd-4z
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:22:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328196082!55121074!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13946 invoked from network); 2 Feb 2012 15:21:23 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 15:21:23 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q12FMFnp014399; Thu, 2 Feb 2012 15:22:15 GMT
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 q12FMEYQ004874; 
	Thu, 2 Feb 2012 10:22:14 -0500
Message-ID: <4F2AAA28.1030707@tycho.nsa.gov>
Date: Thu, 02 Feb 2012 10:22:16 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1328173562.17444.108.camel@zakaz.uk.xensource.com>
	<4F2A9DA4.7090500@tycho.nsa.gov>
	<1328194212.2924.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328194212.2924.22.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation
	functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/02/2012 09:50 AM, Ian Campbell wrote:
> On Thu, 2012-02-02 at 14:28 +0000, Daniel De Graaf wrote:
>> On 02/02/2012 04:06 AM, Ian Campbell wrote:
>>> On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
>>>> Add wrappers for getting and setting policy booleans by name or ID.
>>>>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> ---
>>>>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
>>>>  tools/flask/libflask/include/libflask.h |    3 ++
>>>>  2 files changed, 62 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
>>>> index d4b8ef0..412a05d 100644
>>>> --- a/tools/flask/libflask/flask_op.c
>>>> +++ b/tools/flask/libflask/flask_op.c
>>>> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
>>>>      return 0;
>>>>  }
>>>>  
>>>> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
>>>> +{
>>>> +    flask_op_t op;
>>>> +    char buf[255];
>>>> +    int rv;
>>>> +
>>>> +    op.cmd = FLASK_GETBOOL2;
>>>> +    op.buf = buf;
>>>> +    op.size = 255;
>>>
>>> sizeof(buf)? Here and elsewhere (including a few existing locations in
>>> flask_op.c).
>>>
>>>> +
>>>> +    snprintf(buf, sizeof buf, "%i", id);
>>>> +
>>>> +    rv = xc_flask_op(xc_handle, &op);
>>>> +
>>>> +    if ( rv )
>>>> +        return rv;
>>>> +    
>>>> +    sscanf(buf, "%i %i %s", curr, pend, name);
>>>
>>> Do you care about sscanf failures?
>>  
>> A failure here would be a sign of the hypervisor having made a format change
>> that is not backwards compatible. Checking it would be more complete, however.
>>
>>> It seems from other uses in the file that buf can contain binary data so
>>> would it make sense to make this two ints as binary followed by a
>>> string? That would remove string parsing here and in the hypervisor
>>> (which seems more critical to me?)
>>
>> That also seems far simpler to me; however, all the current FLASK hypercalls
>> are done via string parsing so deviating from this for new operations would
>> make them inconsistent.
> 
> OK. I thought I'd seen some binary muddling in their but I must have
> been mistaken.

Loading a policy seems to be the only operation not involving scanf.

>> If we didn't have to care about backwards compatibility I would convert the
>> entire flask_op hypercall to use a union-of-structures similar to domctl
>> because the string parsing introduces unneeded complexity.
> 
> How much do we care about backwards compat for this interface? Isn't it
> a tools only dom0 interface?
 
Looking over the users - yes, it is, so we should be fine breaking compat
here. This would also eliminate all in-hypervisor users of *scanf. I'll try
and see what a patch fixing this would look like.

I also noticed that libxc and libflask have parallel implementations of some
funcitons: xc_flask_getenforce from libxc and flask_getenforce from libflask.
Not sure if this is a leftover from before ACM support was removed, but it
appears that libflask can be eliminated completely (or remain only as a shim
to call libxc functions).

>>> Is there a defined maximum for the length of "name"?
>>
>> INITCONTEXTLEN = 256.
> 
> So the max size of the buffer is 256 + whatever two int and two spaces
> might maximally take, but your buffer is exactly 256.
> 

Agreed, it would be better to adjust this to a larger buffer.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:22:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15: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.xensource.com>)
	id 1RsyUR-0004tK-MR; Thu, 02 Feb 2012 15:22:23 +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 1RsyUQ-0004sd-4z
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:22:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328196082!55121074!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13946 invoked from network); 2 Feb 2012 15:21:23 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 15:21:23 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q12FMFnp014399; Thu, 2 Feb 2012 15:22:15 GMT
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 q12FMEYQ004874; 
	Thu, 2 Feb 2012 10:22:14 -0500
Message-ID: <4F2AAA28.1030707@tycho.nsa.gov>
Date: Thu, 02 Feb 2012 10:22:16 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1328173562.17444.108.camel@zakaz.uk.xensource.com>
	<4F2A9DA4.7090500@tycho.nsa.gov>
	<1328194212.2924.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328194212.2924.22.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/8] libflask: Add boolean manipulation
	functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/02/2012 09:50 AM, Ian Campbell wrote:
> On Thu, 2012-02-02 at 14:28 +0000, Daniel De Graaf wrote:
>> On 02/02/2012 04:06 AM, Ian Campbell wrote:
>>> On Wed, 2012-02-01 at 19:09 +0000, Daniel De Graaf wrote:
>>>> Add wrappers for getting and setting policy booleans by name or ID.
>>>>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> ---
>>>>  tools/flask/libflask/flask_op.c         |   59 +++++++++++++++++++++++++++++++
>>>>  tools/flask/libflask/include/libflask.h |    3 ++
>>>>  2 files changed, 62 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
>>>> index d4b8ef0..412a05d 100644
>>>> --- a/tools/flask/libflask/flask_op.c
>>>> +++ b/tools/flask/libflask/flask_op.c
>>>> @@ -109,6 +109,65 @@ int flask_setenforce(xc_interface *xc_handle, int mode)
>>>>      return 0;
>>>>  }
>>>>  
>>>> +int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
>>>> +{
>>>> +    flask_op_t op;
>>>> +    char buf[255];
>>>> +    int rv;
>>>> +
>>>> +    op.cmd = FLASK_GETBOOL2;
>>>> +    op.buf = buf;
>>>> +    op.size = 255;
>>>
>>> sizeof(buf)? Here and elsewhere (including a few existing locations in
>>> flask_op.c).
>>>
>>>> +
>>>> +    snprintf(buf, sizeof buf, "%i", id);
>>>> +
>>>> +    rv = xc_flask_op(xc_handle, &op);
>>>> +
>>>> +    if ( rv )
>>>> +        return rv;
>>>> +    
>>>> +    sscanf(buf, "%i %i %s", curr, pend, name);
>>>
>>> Do you care about sscanf failures?
>>  
>> A failure here would be a sign of the hypervisor having made a format change
>> that is not backwards compatible. Checking it would be more complete, however.
>>
>>> It seems from other uses in the file that buf can contain binary data so
>>> would it make sense to make this two ints as binary followed by a
>>> string? That would remove string parsing here and in the hypervisor
>>> (which seems more critical to me?)
>>
>> That also seems far simpler to me; however, all the current FLASK hypercalls
>> are done via string parsing so deviating from this for new operations would
>> make them inconsistent.
> 
> OK. I thought I'd seen some binary muddling in their but I must have
> been mistaken.

Loading a policy seems to be the only operation not involving scanf.

>> If we didn't have to care about backwards compatibility I would convert the
>> entire flask_op hypercall to use a union-of-structures similar to domctl
>> because the string parsing introduces unneeded complexity.
> 
> How much do we care about backwards compat for this interface? Isn't it
> a tools only dom0 interface?
 
Looking over the users - yes, it is, so we should be fine breaking compat
here. This would also eliminate all in-hypervisor users of *scanf. I'll try
and see what a patch fixing this would look like.

I also noticed that libxc and libflask have parallel implementations of some
funcitons: xc_flask_getenforce from libxc and flask_getenforce from libflask.
Not sure if this is a leftover from before ACM support was removed, but it
appears that libflask can be eliminated completely (or remain only as a shim
to call libxc functions).

>>> Is there a defined maximum for the length of "name"?
>>
>> INITCONTEXTLEN = 256.
> 
> So the max size of the buffer is 256 + whatever two int and two spaces
> might maximally take, but your buffer is exactly 256.
> 

Agreed, it would be better to adjust this to a larger buffer.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:28:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15: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.xensource.com>)
	id 1RsyaA-0005HQ-MV; Thu, 02 Feb 2012 15:28:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RsyaA-0005HA-5h
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:28:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328196486!11289102!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 2 Feb 2012 15:28:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 15:28:11 -0000
Received: by werb14 with SMTP id b14so4905893wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 07:28:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=VIuA4zepUGmiFQf/gnq9KUMikfptwPswPtmIVRKHn9Q=;
	b=MLhgmohO+CXEoBsVJiiuDYuqqnzT42a+cOJCL+RqOTzM/Z3oTEvW5l1l37WbMUigHy
	n1+/M7GWujdnru7a2Pk90VmVTVWnJ3B3oJ6ayWmrfdTRHoXlGUcp9IBLB82YwYDFI0PU
	KZecws3HV0k0TlmxlPmAvtxb1NHHoG/Y/f7Fc=
Received: by 10.216.135.193 with SMTP id u43mr1360585wei.34.1328196486444;
	Thu, 02 Feb 2012 07:28:06 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l6sm365311wiv.11.2012.02.02.07.28.04
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 07:28:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 02 Feb 2012 15:28:02 +0000
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB505C02.38E31%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 6/8] libxl: Add
	device_model_stubdomain_seclabel
Thread-Index: Aczhv0BCSk9GL7/qfEC2d3yuUuM0Sw==
In-Reply-To: <1328123365-12490-7-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6/8] libxl: Add
 device_model_stubdomain_seclabel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/2012 19:09, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> This allows the security label of stub domains to be specified.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

This and patch 7/8 I assume will be picked up by a libxl maintainer (cc'ing
Ian Jackson). All your other outstanding patches I have now applied.

 -- Keir

> ---
>  docs/man/xl.cfg.pod.5       |    4 ++++
>  tools/libxl/libxl_dm.c      |    1 +
>  tools/libxl/libxl_types.idl |    1 +
>  tools/libxl/xl_cmdimpl.c    |   12 ++++++++++++
>  4 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9d90290..8f171b4 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -789,6 +789,10 @@ 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 devide-model command
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 5fec137..e99d173 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -703,6 +703,7 @@ static int libxl__create_stubdom(libxl__gc *gc,
>      dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
>      dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
>                                      libxl__domid_to_name(gc, guest_domid));
> +    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
>  
>      libxl_uuid_generate(&dm_config.c_info.uuid);
>  
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 3c24626..b77bc65 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -217,6 +217,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      ("device_model_stubdomain", bool),
>      # you set device_model you must set device_model_version too
>      ("device_model",     string),
> +    ("device_model_ssidref", uint32),
>  
>      # extra parameters pass directly to qemu, NULL terminated
>      ("extra",            libxl_string_list),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 0b811b5..e95bace 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1254,6 +1254,18 @@ skip_vfb:
>      if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l,
> 0))
>          b_info->device_model_stubdomain = l;
>  
> +    if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel",
> &buf, 0)) {
> +        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
> +                                    &b_info->device_model_ssidref);
> +        if (e) {
> +            if (errno == ENOSYS) {
> +                fprintf(stderr, "XSM Disabled:
> device_model_stubdomain_seclabel not supported\n");
> +            } else {
> +                fprintf(stderr, "Invalid device_model_stubdomain_seclabel:
> %s\n", buf);
> +                exit(1);
> +            }
> +        }
> +    }
>  #define parse_extra_args(type)                                            \
>      e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
>                                      &b_info->extra##type, 0);            \



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:28:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15: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.xensource.com>)
	id 1RsyaA-0005HQ-MV; Thu, 02 Feb 2012 15:28:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RsyaA-0005HA-5h
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:28:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328196486!11289102!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 2 Feb 2012 15:28:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 15:28:11 -0000
Received: by werb14 with SMTP id b14so4905893wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 07:28:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=VIuA4zepUGmiFQf/gnq9KUMikfptwPswPtmIVRKHn9Q=;
	b=MLhgmohO+CXEoBsVJiiuDYuqqnzT42a+cOJCL+RqOTzM/Z3oTEvW5l1l37WbMUigHy
	n1+/M7GWujdnru7a2Pk90VmVTVWnJ3B3oJ6ayWmrfdTRHoXlGUcp9IBLB82YwYDFI0PU
	KZecws3HV0k0TlmxlPmAvtxb1NHHoG/Y/f7Fc=
Received: by 10.216.135.193 with SMTP id u43mr1360585wei.34.1328196486444;
	Thu, 02 Feb 2012 07:28:06 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l6sm365311wiv.11.2012.02.02.07.28.04
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 07:28:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 02 Feb 2012 15:28:02 +0000
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB505C02.38E31%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 6/8] libxl: Add
	device_model_stubdomain_seclabel
Thread-Index: Aczhv0BCSk9GL7/qfEC2d3yuUuM0Sw==
In-Reply-To: <1328123365-12490-7-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6/8] libxl: Add
 device_model_stubdomain_seclabel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/2012 19:09, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> This allows the security label of stub domains to be specified.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

This and patch 7/8 I assume will be picked up by a libxl maintainer (cc'ing
Ian Jackson). All your other outstanding patches I have now applied.

 -- Keir

> ---
>  docs/man/xl.cfg.pod.5       |    4 ++++
>  tools/libxl/libxl_dm.c      |    1 +
>  tools/libxl/libxl_types.idl |    1 +
>  tools/libxl/xl_cmdimpl.c    |   12 ++++++++++++
>  4 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9d90290..8f171b4 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -789,6 +789,10 @@ 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 devide-model command
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 5fec137..e99d173 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -703,6 +703,7 @@ static int libxl__create_stubdom(libxl__gc *gc,
>      dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
>      dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
>                                      libxl__domid_to_name(gc, guest_domid));
> +    dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref;
>  
>      libxl_uuid_generate(&dm_config.c_info.uuid);
>  
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 3c24626..b77bc65 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -217,6 +217,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      ("device_model_stubdomain", bool),
>      # you set device_model you must set device_model_version too
>      ("device_model",     string),
> +    ("device_model_ssidref", uint32),
>  
>      # extra parameters pass directly to qemu, NULL terminated
>      ("extra",            libxl_string_list),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 0b811b5..e95bace 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1254,6 +1254,18 @@ skip_vfb:
>      if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l,
> 0))
>          b_info->device_model_stubdomain = l;
>  
> +    if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel",
> &buf, 0)) {
> +        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
> +                                    &b_info->device_model_ssidref);
> +        if (e) {
> +            if (errno == ENOSYS) {
> +                fprintf(stderr, "XSM Disabled:
> device_model_stubdomain_seclabel not supported\n");
> +            } else {
> +                fprintf(stderr, "Invalid device_model_stubdomain_seclabel:
> %s\n", buf);
> +                exit(1);
> +            }
> +        }
> +    }
>  #define parse_extra_args(type)                                            \
>      e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
>                                      &b_info->extra##type, 0);            \



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:32:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsydb-0005aD-B0; Thu, 02 Feb 2012 15:31:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rsyda-0005Ys-7s
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:31:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328196703!13230475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23644 invoked from network); 2 Feb 2012 15:31:43 -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;
	2 Feb 2012 15:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10443468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:31:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:31:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsydS-00088C-Ky; Thu, 02 Feb 2012 15:31:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsydS-00014k-JU;
	Thu, 02 Feb 2012 15:31:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.44126.591097.812929@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 15:31:42 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>
In-Reply-To: <osstest-11825-mainreport@xen.org>
References: <osstest-11825-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11825: regressions - FAIL"):
>  build-i386                    4 xen-build                 fail   like 11637

gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -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/osstest/build.11825.build-i386/xen-unstable/xen/include  -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ -include /home/osstest/build.11825.build-i386/xen-unstable/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .memory.o.d -c memory.c -o memory.o
cc1: warnings being treated as errors
memory.c: In function 'guest_remove_page':
memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
make[4]: *** [memory.o] Error 1
make[4]: Leaving directory `/home/osstest/build.11825.build-i386/xen-unstable/xen/common'
make[3]: *** [/home/osstest/build.11825.build-i386/xen-unstable/xen/common/built_in.o] Error 2

I think this is due to the changeset below.

Ian.

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1328185651 0
# Node ID e2e2df4224e221ff7bbb9a75083d3b21f70a47d2
# Parent  23fe4a60190f11efc750af51f55228183f7bb736
x86/mm: Fix balooning+sharing

Never mind that ballooning a shared page makes no sense. We still fix it
because it may be exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>

diff -r 23fe4a60190f -r e2e2df4224e2 xen/common/memory.c
--- a/xen/common/memory.c	Thu Feb 02 12:23:18 2012 +0000
+++ b/xen/common/memory.c	Thu Feb 02 12:27:31 2012 +0000
@@ -183,14 +183,14 @@ int guest_remove_page(struct domain *d, 
             
     page = mfn_to_page(mfn);
 #ifdef CONFIG_X86
-    /* If gmfn is shared, just drop the guest reference (which may or may not
-     * free the page) */
-    if(p2m_is_shared(p2mt))
+    if ( p2m_is_shared(p2mt) )
     {
-        put_page_and_type(page);
-        guest_physmap_remove_page(d, gmfn, mfn, 0);
-        put_gfn(d, gmfn);
-        return 1;
+        /* Unshare the page, bail out on error. We unshare because 
+         * we might be the only one using this shared page, and we
+         * need to trigger proper cleanup. Once done, this is 
+         * like any other page. */
+        if ( mem_sharing_unshare_page(d, gmfn, 0) )
+            return 0;
     }
 
 #endif /* CONFIG_X86 */

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:32:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsydb-0005aD-B0; Thu, 02 Feb 2012 15:31:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rsyda-0005Ys-7s
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:31:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328196703!13230475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23644 invoked from network); 2 Feb 2012 15:31:43 -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;
	2 Feb 2012 15:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10443468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:31:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:31:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsydS-00088C-Ky; Thu, 02 Feb 2012 15:31:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsydS-00014k-JU;
	Thu, 02 Feb 2012 15:31:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.44126.591097.812929@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 15:31:42 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>
In-Reply-To: <osstest-11825-mainreport@xen.org>
References: <osstest-11825-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11825: regressions - FAIL"):
>  build-i386                    4 xen-build                 fail   like 11637

gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -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/osstest/build.11825.build-i386/xen-unstable/xen/include  -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ -include /home/osstest/build.11825.build-i386/xen-unstable/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .memory.o.d -c memory.c -o memory.o
cc1: warnings being treated as errors
memory.c: In function 'guest_remove_page':
memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
make[4]: *** [memory.o] Error 1
make[4]: Leaving directory `/home/osstest/build.11825.build-i386/xen-unstable/xen/common'
make[3]: *** [/home/osstest/build.11825.build-i386/xen-unstable/xen/common/built_in.o] Error 2

I think this is due to the changeset below.

Ian.

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1328185651 0
# Node ID e2e2df4224e221ff7bbb9a75083d3b21f70a47d2
# Parent  23fe4a60190f11efc750af51f55228183f7bb736
x86/mm: Fix balooning+sharing

Never mind that ballooning a shared page makes no sense. We still fix it
because it may be exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>

diff -r 23fe4a60190f -r e2e2df4224e2 xen/common/memory.c
--- a/xen/common/memory.c	Thu Feb 02 12:23:18 2012 +0000
+++ b/xen/common/memory.c	Thu Feb 02 12:27:31 2012 +0000
@@ -183,14 +183,14 @@ int guest_remove_page(struct domain *d, 
             
     page = mfn_to_page(mfn);
 #ifdef CONFIG_X86
-    /* If gmfn is shared, just drop the guest reference (which may or may not
-     * free the page) */
-    if(p2m_is_shared(p2mt))
+    if ( p2m_is_shared(p2mt) )
     {
-        put_page_and_type(page);
-        guest_physmap_remove_page(d, gmfn, mfn, 0);
-        put_gfn(d, gmfn);
-        return 1;
+        /* Unshare the page, bail out on error. We unshare because 
+         * we might be the only one using this shared page, and we
+         * need to trigger proper cleanup. Once done, this is 
+         * like any other page. */
+        if ( mem_sharing_unshare_page(d, gmfn, 0) )
+            return 0;
     }
 
 #endif /* CONFIG_X86 */

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:33:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyfG-0005kw-B1; Thu, 02 Feb 2012 15:33:34 +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 1RsyfE-0005ju-PM
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:33:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328196757!51155949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16167 invoked from network); 2 Feb 2012 15:32:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 15:32:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180137501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 10:33:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 10:33:18 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12FXGcT008246;
	Thu, 2 Feb 2012 07:33:16 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
Date: Thu, 2 Feb 2012 15:33:15 +0000
Message-ID: <1328196795.21722.86.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>          unmap_domain_page(b);
>      }
> 
> +    /* First, take all pages off the domain list */
>      lock_page_alloc(p2m);
> -
> -    /* First, take all pages off the domain list */
>      for(i=0; i < 1 << order ; i++)
>      {
>          p = page + i;
>          page_list_del(p, &d->page_list);
>      }
> 
> +    /* Ensure that the PoD cache has never been emptied.
> +     * This may cause "zombie domains" since the page will never be freed. */
> +    BUG_ON( d->arch.relmem != RELMEM_not_started );
> +
> +    unlock_page_alloc(p2m);
> +

This assert should stay where it is.  The idea is to verify
after-the-fact that the page_list_add_tail()s *have not* raced with
emptying the PoD cache.  Having the assert before cannot guarantee that
they *will not* race with emptying the PoD cache.  Alternately, if we're
positive that condition can never happen again, we should just remove
the BUG_ON().

If I recall correctly, I put this in here because something ended up
calling cache_add after empty_cache(), potentially with the p2m lock
already held; that's why I put the BUG_ON() there to begin with.

> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
> 
>      /* FIXME: Figure out how to avoid superpages */
> +    /* NOTE: Promote to globally locking the p2m. This will get complicated
> +     * in a fine-grained scenario. Even if we're to lock each gfn
> +     * individually we must be careful about recursion limits and
> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock constraints
> +     * between p2m and pod locks */
> +    p2m_lock(p2m);
>      for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
>      {
>          p2m_access_t a;
> @@ -940,7 +953,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>          /* Stop if we're past our limit and we have found *something*.
>           *
>           * NB that this is a zero-sum game; we're increasing our cache size
> -         * by re-increasing our 'debt'.  Since we hold the p2m lock,
> +         * by re-increasing our 'debt'.  Since we hold the pod lock,
>           * (entry_count - count) must remain the same. */
>          if ( p2m->pod.count > 0 && i < limit )
>              break;
> @@ -949,6 +962,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>      if ( j )
>          p2m_pod_zero_check(p2m, gfns, j);
> 
> +    p2m_unlock(p2m);
>      p2m->pod.reclaim_single = i ? i - 1 : i;
> 
>  }
> @@ -965,8 +979,9 @@ p2m_pod_demand_populate(struct p2m_domai
>      int i;
> 
>      ASSERT(gfn_locked_by_me(p2m, gfn));
> +    pod_lock(p2m);
> 
> -    /* This check is done with the p2m lock held.  This will make sure that
> +    /* This check is done with the pod lock held.  This will make sure that
>       * even if d->is_dying changes under our feet, p2m_pod_empty_cache()
>       * won't start until we're done. */
>      if ( unlikely(d->is_dying) )
> @@ -977,6 +992,7 @@ p2m_pod_demand_populate(struct p2m_domai
>       * 1GB region to 2MB chunks for a retry. */
>      if ( order == PAGE_ORDER_1G )
>      {
> +        pod_unlock(p2m);
>          gfn_aligned = (gfn >> order) << order;
>          /* Note that we are supposed to call set_p2m_entry() 512 times to
>           * split 1GB into 512 2MB pages here. But We only do once here because
> @@ -1000,11 +1016,15 @@ p2m_pod_demand_populate(struct p2m_domai
> 
>          /* If we're low, start a sweep */
>          if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
> +            /* Note that sweeps scan other ranges in the p2m. In an scenario
> +             * in which p2m locks are order-enforced wrt pod lock and p2m
> +             * locks are fine grained, this will result in deadlock panic */
>              p2m_pod_emergency_sweep_super(p2m);
> 
>          if ( page_list_empty(&p2m->pod.single) &&
>               ( ( order == PAGE_ORDER_4K )
>                 || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
> +            /* Same comment regarding deadlock applies */
>              p2m_pod_emergency_sweep(p2m);
>      }
> 

Regarding locking on emergency sweeps: I think it should suffice if we
could do the equivalent of a spin_trylock() on each gpfn, and just move
on (not checking that gfn) if it fails.  What do you think?

Other than that, I don't see anything wrong with this locking at first
glance; but it's complicated enough that I don't think I've quite
grokked it yet.  I'll look at it again tomorrow and see if things are
more clear. :-)

-George


> @@ -1012,8 +1032,6 @@ p2m_pod_demand_populate(struct p2m_domai
>      if ( q == p2m_guest && gfn > p2m->pod.max_guest )
>          p2m->pod.max_guest = gfn;
> 
> -    lock_page_alloc(p2m);
> -
>      if ( p2m->pod.count == 0 )
>          goto out_of_memory;
> 
> @@ -1026,8 +1044,6 @@ p2m_pod_demand_populate(struct p2m_domai
> 
>      BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
> 
> -    unlock_page_alloc(p2m);
> -
>      gfn_aligned = (gfn >> order) << order;
> 
>      set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw, p2m->default_access);
> @@ -1038,7 +1054,7 @@ p2m_pod_demand_populate(struct p2m_domai
>          paging_mark_dirty(d, mfn_x(mfn) + i);
>      }
> 
> -    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
> +    p2m->pod.entry_count -= (1 << order);
>      BUG_ON(p2m->pod.entry_count < 0);
> 
>      if ( tb_init_done )
> @@ -1056,20 +1072,24 @@ p2m_pod_demand_populate(struct p2m_domai
>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>      }
> 
> +    pod_unlock(p2m);
>      return 0;
>  out_of_memory:
> -    unlock_page_alloc(p2m);
> +    pod_unlock(p2m);
> 
>      printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 " pod_entries %" PRIi32 "\n",
>             __func__, d->tot_pages, p2m->pod.entry_count);
>      domain_crash(d);
>  out_fail:
> +    pod_unlock(p2m);
>      return -1;
>  remap_and_retry:
>      BUG_ON(order != PAGE_ORDER_2M);
> -    unlock_page_alloc(p2m);
> +    pod_unlock(p2m);
> 
>      /* Remap this 2-meg region in singleton chunks */
> +    /* NOTE: In a p2m fine-grained lock scenario this might
> +     * need promoting the gfn lock from gfn->2M superpage */
>      gfn_aligned = (gfn>>order)<<order;
>      for(i=0; i<(1<<order); i++)
>          set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
> @@ -1137,9 +1157,11 @@ guest_physmap_mark_populate_on_demand(st
>          rc = -EINVAL;
>      else
>      {
> -        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
> +        pod_lock(p2m);
> +        p2m->pod.entry_count += 1 << order;
>          p2m->pod.entry_count -= pod_count;
>          BUG_ON(p2m->pod.entry_count < 0);
> +        pod_unlock(p2m);
>      }
> 
>      gfn_unlock(p2m, gfn, order);
> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pt.c
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>      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) );
> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
>  static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
>  {
>      mm_lock_init(&p2m->lock);
> +    mm_lock_init(&p2m->pod.lock);
>      INIT_LIST_HEAD(&p2m->np2m_list);
>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>      INIT_PAGE_LIST_HEAD(&p2m->pod.super);
> @@ -587,8 +588,10 @@ guest_physmap_add_entry(struct domain *d
>              rc = -EINVAL;
>          else
>          {
> -            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
> +            pod_lock(p2m);
> +            p2m->pod.entry_count -= pod_count;
>              BUG_ON(p2m->pod.entry_count < 0);
> +            pod_unlock(p2m);
>          }
>      }
> 
> @@ -1372,6 +1375,7 @@ p2m_flush_table(struct p2m_domain *p2m)
>      /* "Host" p2m tables can have shared entries &c that need a bit more
>       * care when discarding them */
>      ASSERT(p2m_is_nestedp2m(p2m));
> +    /* Nested p2m's do not do pod, hence the asserts (and no pod lock)*/
>      ASSERT(page_list_empty(&p2m->pod.super));
>      ASSERT(page_list_empty(&p2m->pod.single));
> 
> @@ -1529,6 +1533,7 @@ void audit_p2m(struct domain *d,
>      P2M_PRINTK("p2m audit starts\n");
> 
>      p2m_lock(p2m);
> +    pod_lock(p2m);
> 
>      if (p2m->audit_p2m)
>          pmbad = p2m->audit_p2m(p2m);
> @@ -1589,6 +1594,7 @@ void audit_p2m(struct domain *d,
>      }
>      spin_unlock(&d->page_alloc_lock);
> 
> +    pod_unlock(p2m);
>      p2m_unlock(p2m);
> 
>      P2M_PRINTK("p2m audit complete\n");
> diff -r fb9c06df05f2 -r 56ceab0118cb xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -261,25 +261,12 @@ struct p2m_domain {
>      unsigned long max_mapped_pfn;
> 
>      /* Populate-on-demand variables
> -     * NB on locking.  {super,single,count} are
> -     * covered by d->page_alloc_lock, since they're almost always used in
> -     * conjunction with that functionality.  {entry_count} is covered by
> -     * the domain p2m lock, since it's almost always used in conjunction
> -     * with changing the p2m tables.
> -     *
> -     * At this point, both locks are held in two places.  In both,
> -     * the order is [p2m,page_alloc]:
> -     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
> -     *   which grabs page_alloc
> -     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
> -     *   double-demand-populating of pages, the page_alloc lock to
> -     *   protect moving stuff from the PoD cache to the domain page list.
> -     *
> -     * We enforce this lock ordering through a construct in mm-locks.h.
> -     * This demands, however, that we store the previous lock-ordering
> -     * level in effect before grabbing the page_alloc lock. The unlock
> -     * level is stored in the arch section of the domain struct.
> -     */
> +     * All variables are protected with the pod lock. We cannot rely on
> +     * the p2m lock if it's turned into a fine-grained lock.
> +     * We only use the domain page_alloc lock for additions and
> +     * deletions to the domain's page list. Because we use it nested
> +     * within the PoD lock, we enforce it's ordering (by remembering
> +     * the unlock level in the arch_domain sub struct). */
>      struct {
>          struct page_list_head super,   /* List of superpages                */
>                           single;       /* Non-super lists                   */
> @@ -288,6 +275,8 @@ struct p2m_domain {
>          unsigned         reclaim_super; /* Last gpfn of a scan */
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest demand-populate */
> +        mm_lock_t        lock;         /* Locking of private pod structs,   *
> +                                        * not relying on the p2m lock.      */
>      } pod;
>  };
> 



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:33:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyfG-0005kw-B1; Thu, 02 Feb 2012 15:33:34 +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 1RsyfE-0005ju-PM
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:33:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328196757!51155949!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16167 invoked from network); 2 Feb 2012 15:32:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 15:32:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180137501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 10:33:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 10:33:18 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12FXGcT008246;
	Thu, 2 Feb 2012 07:33:16 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
Date: Thu, 2 Feb 2012 15:33:15 +0000
Message-ID: <1328196795.21722.86.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>          unmap_domain_page(b);
>      }
> 
> +    /* First, take all pages off the domain list */
>      lock_page_alloc(p2m);
> -
> -    /* First, take all pages off the domain list */
>      for(i=0; i < 1 << order ; i++)
>      {
>          p = page + i;
>          page_list_del(p, &d->page_list);
>      }
> 
> +    /* Ensure that the PoD cache has never been emptied.
> +     * This may cause "zombie domains" since the page will never be freed. */
> +    BUG_ON( d->arch.relmem != RELMEM_not_started );
> +
> +    unlock_page_alloc(p2m);
> +

This assert should stay where it is.  The idea is to verify
after-the-fact that the page_list_add_tail()s *have not* raced with
emptying the PoD cache.  Having the assert before cannot guarantee that
they *will not* race with emptying the PoD cache.  Alternately, if we're
positive that condition can never happen again, we should just remove
the BUG_ON().

If I recall correctly, I put this in here because something ended up
calling cache_add after empty_cache(), potentially with the p2m lock
already held; that's why I put the BUG_ON() there to begin with.

> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
> 
>      /* FIXME: Figure out how to avoid superpages */
> +    /* NOTE: Promote to globally locking the p2m. This will get complicated
> +     * in a fine-grained scenario. Even if we're to lock each gfn
> +     * individually we must be careful about recursion limits and
> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock constraints
> +     * between p2m and pod locks */
> +    p2m_lock(p2m);
>      for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
>      {
>          p2m_access_t a;
> @@ -940,7 +953,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>          /* Stop if we're past our limit and we have found *something*.
>           *
>           * NB that this is a zero-sum game; we're increasing our cache size
> -         * by re-increasing our 'debt'.  Since we hold the p2m lock,
> +         * by re-increasing our 'debt'.  Since we hold the pod lock,
>           * (entry_count - count) must remain the same. */
>          if ( p2m->pod.count > 0 && i < limit )
>              break;
> @@ -949,6 +962,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>      if ( j )
>          p2m_pod_zero_check(p2m, gfns, j);
> 
> +    p2m_unlock(p2m);
>      p2m->pod.reclaim_single = i ? i - 1 : i;
> 
>  }
> @@ -965,8 +979,9 @@ p2m_pod_demand_populate(struct p2m_domai
>      int i;
> 
>      ASSERT(gfn_locked_by_me(p2m, gfn));
> +    pod_lock(p2m);
> 
> -    /* This check is done with the p2m lock held.  This will make sure that
> +    /* This check is done with the pod lock held.  This will make sure that
>       * even if d->is_dying changes under our feet, p2m_pod_empty_cache()
>       * won't start until we're done. */
>      if ( unlikely(d->is_dying) )
> @@ -977,6 +992,7 @@ p2m_pod_demand_populate(struct p2m_domai
>       * 1GB region to 2MB chunks for a retry. */
>      if ( order == PAGE_ORDER_1G )
>      {
> +        pod_unlock(p2m);
>          gfn_aligned = (gfn >> order) << order;
>          /* Note that we are supposed to call set_p2m_entry() 512 times to
>           * split 1GB into 512 2MB pages here. But We only do once here because
> @@ -1000,11 +1016,15 @@ p2m_pod_demand_populate(struct p2m_domai
> 
>          /* If we're low, start a sweep */
>          if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
> +            /* Note that sweeps scan other ranges in the p2m. In an scenario
> +             * in which p2m locks are order-enforced wrt pod lock and p2m
> +             * locks are fine grained, this will result in deadlock panic */
>              p2m_pod_emergency_sweep_super(p2m);
> 
>          if ( page_list_empty(&p2m->pod.single) &&
>               ( ( order == PAGE_ORDER_4K )
>                 || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
> +            /* Same comment regarding deadlock applies */
>              p2m_pod_emergency_sweep(p2m);
>      }
> 

Regarding locking on emergency sweeps: I think it should suffice if we
could do the equivalent of a spin_trylock() on each gpfn, and just move
on (not checking that gfn) if it fails.  What do you think?

Other than that, I don't see anything wrong with this locking at first
glance; but it's complicated enough that I don't think I've quite
grokked it yet.  I'll look at it again tomorrow and see if things are
more clear. :-)

-George


> @@ -1012,8 +1032,6 @@ p2m_pod_demand_populate(struct p2m_domai
>      if ( q == p2m_guest && gfn > p2m->pod.max_guest )
>          p2m->pod.max_guest = gfn;
> 
> -    lock_page_alloc(p2m);
> -
>      if ( p2m->pod.count == 0 )
>          goto out_of_memory;
> 
> @@ -1026,8 +1044,6 @@ p2m_pod_demand_populate(struct p2m_domai
> 
>      BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
> 
> -    unlock_page_alloc(p2m);
> -
>      gfn_aligned = (gfn >> order) << order;
> 
>      set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw, p2m->default_access);
> @@ -1038,7 +1054,7 @@ p2m_pod_demand_populate(struct p2m_domai
>          paging_mark_dirty(d, mfn_x(mfn) + i);
>      }
> 
> -    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
> +    p2m->pod.entry_count -= (1 << order);
>      BUG_ON(p2m->pod.entry_count < 0);
> 
>      if ( tb_init_done )
> @@ -1056,20 +1072,24 @@ p2m_pod_demand_populate(struct p2m_domai
>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>      }
> 
> +    pod_unlock(p2m);
>      return 0;
>  out_of_memory:
> -    unlock_page_alloc(p2m);
> +    pod_unlock(p2m);
> 
>      printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 " pod_entries %" PRIi32 "\n",
>             __func__, d->tot_pages, p2m->pod.entry_count);
>      domain_crash(d);
>  out_fail:
> +    pod_unlock(p2m);
>      return -1;
>  remap_and_retry:
>      BUG_ON(order != PAGE_ORDER_2M);
> -    unlock_page_alloc(p2m);
> +    pod_unlock(p2m);
> 
>      /* Remap this 2-meg region in singleton chunks */
> +    /* NOTE: In a p2m fine-grained lock scenario this might
> +     * need promoting the gfn lock from gfn->2M superpage */
>      gfn_aligned = (gfn>>order)<<order;
>      for(i=0; i<(1<<order); i++)
>          set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
> @@ -1137,9 +1157,11 @@ guest_physmap_mark_populate_on_demand(st
>          rc = -EINVAL;
>      else
>      {
> -        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
> +        pod_lock(p2m);
> +        p2m->pod.entry_count += 1 << order;
>          p2m->pod.entry_count -= pod_count;
>          BUG_ON(p2m->pod.entry_count < 0);
> +        pod_unlock(p2m);
>      }
> 
>      gfn_unlock(p2m, gfn, order);
> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pt.c
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>      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) );
> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
>  static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
>  {
>      mm_lock_init(&p2m->lock);
> +    mm_lock_init(&p2m->pod.lock);
>      INIT_LIST_HEAD(&p2m->np2m_list);
>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>      INIT_PAGE_LIST_HEAD(&p2m->pod.super);
> @@ -587,8 +588,10 @@ guest_physmap_add_entry(struct domain *d
>              rc = -EINVAL;
>          else
>          {
> -            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
> +            pod_lock(p2m);
> +            p2m->pod.entry_count -= pod_count;
>              BUG_ON(p2m->pod.entry_count < 0);
> +            pod_unlock(p2m);
>          }
>      }
> 
> @@ -1372,6 +1375,7 @@ p2m_flush_table(struct p2m_domain *p2m)
>      /* "Host" p2m tables can have shared entries &c that need a bit more
>       * care when discarding them */
>      ASSERT(p2m_is_nestedp2m(p2m));
> +    /* Nested p2m's do not do pod, hence the asserts (and no pod lock)*/
>      ASSERT(page_list_empty(&p2m->pod.super));
>      ASSERT(page_list_empty(&p2m->pod.single));
> 
> @@ -1529,6 +1533,7 @@ void audit_p2m(struct domain *d,
>      P2M_PRINTK("p2m audit starts\n");
> 
>      p2m_lock(p2m);
> +    pod_lock(p2m);
> 
>      if (p2m->audit_p2m)
>          pmbad = p2m->audit_p2m(p2m);
> @@ -1589,6 +1594,7 @@ void audit_p2m(struct domain *d,
>      }
>      spin_unlock(&d->page_alloc_lock);
> 
> +    pod_unlock(p2m);
>      p2m_unlock(p2m);
> 
>      P2M_PRINTK("p2m audit complete\n");
> diff -r fb9c06df05f2 -r 56ceab0118cb xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -261,25 +261,12 @@ struct p2m_domain {
>      unsigned long max_mapped_pfn;
> 
>      /* Populate-on-demand variables
> -     * NB on locking.  {super,single,count} are
> -     * covered by d->page_alloc_lock, since they're almost always used in
> -     * conjunction with that functionality.  {entry_count} is covered by
> -     * the domain p2m lock, since it's almost always used in conjunction
> -     * with changing the p2m tables.
> -     *
> -     * At this point, both locks are held in two places.  In both,
> -     * the order is [p2m,page_alloc]:
> -     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
> -     *   which grabs page_alloc
> -     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
> -     *   double-demand-populating of pages, the page_alloc lock to
> -     *   protect moving stuff from the PoD cache to the domain page list.
> -     *
> -     * We enforce this lock ordering through a construct in mm-locks.h.
> -     * This demands, however, that we store the previous lock-ordering
> -     * level in effect before grabbing the page_alloc lock. The unlock
> -     * level is stored in the arch section of the domain struct.
> -     */
> +     * All variables are protected with the pod lock. We cannot rely on
> +     * the p2m lock if it's turned into a fine-grained lock.
> +     * We only use the domain page_alloc lock for additions and
> +     * deletions to the domain's page list. Because we use it nested
> +     * within the PoD lock, we enforce it's ordering (by remembering
> +     * the unlock level in the arch_domain sub struct). */
>      struct {
>          struct page_list_head super,   /* List of superpages                */
>                           single;       /* Non-super lists                   */
> @@ -288,6 +275,8 @@ struct p2m_domain {
>          unsigned         reclaim_super; /* Last gpfn of a scan */
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest demand-populate */
> +        mm_lock_t        lock;         /* Locking of private pod structs,   *
> +                                        * not relying on the p2m lock.      */
>      } pod;
>  };
> 



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:49:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyuK-000682-SQ; Thu, 02 Feb 2012 15:49: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 1RsyuK-00067x-4V
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:49:08 +0000
Received: from [85.158.138.51:62874] by server-11.bemta-3.messagelabs.com id
	19/CF-21643-370BA2F4; Thu, 02 Feb 2012 15:49:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328197746!11680603!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6814 invoked from network); 2 Feb 2012 15:49:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 15:49:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsyuG-000EXC-9V; Thu, 02 Feb 2012 15:49:04 +0000
Date: Thu, 2 Feb 2012 15:49:04 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120202154904.GQ48883@ocelot.phlegethon.org>
References: <osstest-11825-mainreport@xen.org>
	<20266.44126.591097.812929@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20266.44126.591097.812929@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:31 +0000 on 02 Feb (1328196702), Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 11825: regressions - FAIL"):
> >  build-i386                    4 xen-build                 fail   like 11637
> 
> gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -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/osstest/build.11825.build-i386/xen-unstable/xen/include  -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ -include /home/osstest/build.11825.build-i386/xen-unstable/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .memory.o.d -c memory.c -o memory.o
> cc1: warnings being treated as errors
> memory.c: In function 'guest_remove_page':
> memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
> memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
> make[4]: *** [memory.o] Error 1

Oops!  Fixed by 24691:3432abcf9380.

Cheers,

Tim.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:49:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyuK-000682-SQ; Thu, 02 Feb 2012 15:49: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 1RsyuK-00067x-4V
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:49:08 +0000
Received: from [85.158.138.51:62874] by server-11.bemta-3.messagelabs.com id
	19/CF-21643-370BA2F4; Thu, 02 Feb 2012 15:49:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328197746!11680603!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6814 invoked from network); 2 Feb 2012 15:49:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 15:49:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsyuG-000EXC-9V; Thu, 02 Feb 2012 15:49:04 +0000
Date: Thu, 2 Feb 2012 15:49:04 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120202154904.GQ48883@ocelot.phlegethon.org>
References: <osstest-11825-mainreport@xen.org>
	<20266.44126.591097.812929@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20266.44126.591097.812929@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:31 +0000 on 02 Feb (1328196702), Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 11825: regressions - FAIL"):
> >  build-i386                    4 xen-build                 fail   like 11637
> 
> gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -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/osstest/build.11825.build-i386/xen-unstable/xen/include  -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.11825.build-i386/xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ -include /home/osstest/build.11825.build-i386/xen-unstable/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .memory.o.d -c memory.c -o memory.o
> cc1: warnings being treated as errors
> memory.c: In function 'guest_remove_page':
> memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
> memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
> make[4]: *** [memory.o] Error 1

Oops!  Fixed by 24691:3432abcf9380.

Cheers,

Tim.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:50:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rsyv0-0006AX-9n; Thu, 02 Feb 2012 15:49:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Rsyuz-0006A9-0T
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:49:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328197781!13456883!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16939 invoked from network); 2 Feb 2012 15:49:42 -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;
	2 Feb 2012 15:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21550183"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 10:49:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	10:49:40 -0500
Message-ID: <4F2AB092.7020003@citrix.com>
Date: Thu, 2 Feb 2012 15:49:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <osstest-11807-mainreport@xen.org>
	<20266.33471.444202.819846@mariner.uk.xensource.com>
In-Reply-To: <20266.33471.444202.819846@mariner.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050602000407060003090507"
Cc: Wei Wang <wei.wang2@amd.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050602000407060003090507
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This patch ought to help narrow down the problem.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050602000407060003090507
Content-Type: text/x-patch; name="irq-migration-debug.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="irq-migration-debug.patch"

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864
IRQ: Add extra debugging to help track down why this assertion is failing

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e2722b24dc09 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -608,6 +608,8 @@ void move_native_irq(struct irq_desc *de
     desc->handler->enable(desc);
 }
 
+static void dump_irqs(unsigned char key);
+
 fastcall void smp_irq_move_cleanup_interrupt(struct cpu_user_regs *regs)
 {
     unsigned vector, me;
@@ -667,7 +669,18 @@ fastcall void smp_irq_move_cleanup_inter
 
             if ( desc->arch.used_vectors )
             {
-                ASSERT(test_bit(vector, desc->arch.used_vectors));
+                if ( unlikely(!test_bit(vector, desc->arch.used_vectors)) )
+                {
+                    bitmap_scnlistprintf(keyhandler_scratch,
+                                         sizeof(keyhandler_scratch),
+                                         desc->arch.used_vectors->_bits,
+                                         NR_VECTORS);
+                    printk("*** IRQ BUG found ***\n"
+                           "CPU%d -Testing vector %d from bitmap %s\n",
+                           me, vector, keyhandler_scratch);
+                    dump_irqs('i');
+                    BUG();
+                }
                 clear_bit(vector, desc->arch.used_vectors);
             }
         }

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

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

--------------050602000407060003090507--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:50:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rsyv0-0006AX-9n; Thu, 02 Feb 2012 15:49:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1Rsyuz-0006A9-0T
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:49:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328197781!13456883!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16939 invoked from network); 2 Feb 2012 15:49:42 -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;
	2 Feb 2012 15:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21550183"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 10:49:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	10:49:40 -0500
Message-ID: <4F2AB092.7020003@citrix.com>
Date: Thu, 2 Feb 2012 15:49:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <osstest-11807-mainreport@xen.org>
	<20266.33471.444202.819846@mariner.uk.xensource.com>
In-Reply-To: <20266.33471.444202.819846@mariner.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050602000407060003090507"
Cc: Wei Wang <wei.wang2@amd.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050602000407060003090507
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This patch ought to help narrow down the problem.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050602000407060003090507
Content-Type: text/x-patch; name="irq-migration-debug.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="irq-migration-debug.patch"

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864
IRQ: Add extra debugging to help track down why this assertion is failing

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e2722b24dc09 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -608,6 +608,8 @@ void move_native_irq(struct irq_desc *de
     desc->handler->enable(desc);
 }
 
+static void dump_irqs(unsigned char key);
+
 fastcall void smp_irq_move_cleanup_interrupt(struct cpu_user_regs *regs)
 {
     unsigned vector, me;
@@ -667,7 +669,18 @@ fastcall void smp_irq_move_cleanup_inter
 
             if ( desc->arch.used_vectors )
             {
-                ASSERT(test_bit(vector, desc->arch.used_vectors));
+                if ( unlikely(!test_bit(vector, desc->arch.used_vectors)) )
+                {
+                    bitmap_scnlistprintf(keyhandler_scratch,
+                                         sizeof(keyhandler_scratch),
+                                         desc->arch.used_vectors->_bits,
+                                         NR_VECTORS);
+                    printk("*** IRQ BUG found ***\n"
+                           "CPU%d -Testing vector %d from bitmap %s\n",
+                           me, vector, keyhandler_scratch);
+                    dump_irqs('i');
+                    BUG();
+                }
                 clear_bit(vector, desc->arch.used_vectors);
             }
         }

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

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

--------------050602000407060003090507--


From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:51:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsywM-0006LQ-07; Thu, 02 Feb 2012 15:51: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 1RsywJ-0006L6-Q0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:51:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328197833!50845096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31527 invoked from network); 2 Feb 2012 15:50:33 -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;
	2 Feb 2012 15:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10444343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:51:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:51:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsywI-0008EW-A9; Thu, 02 Feb 2012 15:51:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsywI-0003TG-9P;
	Thu, 02 Feb 2012 15:51:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.45294.278782.694368@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 15:51:10 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>
In-Reply-To: <20266.44126.591097.812929@mariner.uk.xensource.com>
References: <osstest-11825-mainreport@xen.org>
	<20266.44126.591097.812929@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [xen-unstable test] 11825: regressions - FAIL"):
> memory.c: In function 'guest_remove_page':
> memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
> memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
> make[4]: *** [memory.o] Error 1
> make[4]: Leaving directory `/home/osstest/build.11825.build-i386/xen-unstable/xen/common'
> make[3]: *** [/home/osstest/build.11825.build-i386/xen-unstable/xen/common/built_in.o] Error 2

The patch below fixes it for me, but I'm not sure whether replacing
CONFIG_X86 with __x86_64__ is proper.


x86/mm: Fix 32-bit build by disabling some memory sharing code

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r dcc6d57e4c07 xen/common/memory.c
--- a/xen/common/memory.c	Thu Feb 02 15:28:58 2012 +0000
+++ b/xen/common/memory.c	Thu Feb 02 15:49:50 2012 +0000
@@ -182,7 +182,7 @@ int guest_remove_page(struct domain *d, 
     }
             
     page = mfn_to_page(mfn);
-#ifdef CONFIG_X86
+#ifdef __x86_64__
     if ( p2m_is_shared(p2mt) )
     {
         /* Unshare the page, bail out on error. We unshare because 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:51:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsywM-0006LQ-07; Thu, 02 Feb 2012 15:51: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 1RsywJ-0006L6-Q0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:51:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328197833!50845096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31527 invoked from network); 2 Feb 2012 15:50:33 -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;
	2 Feb 2012 15:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10444343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:51:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:51:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsywI-0008EW-A9; Thu, 02 Feb 2012 15:51:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsywI-0003TG-9P;
	Thu, 02 Feb 2012 15:51:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.45294.278782.694368@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 15:51:10 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>
In-Reply-To: <20266.44126.591097.812929@mariner.uk.xensource.com>
References: <osstest-11825-mainreport@xen.org>
	<20266.44126.591097.812929@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [xen-unstable test] 11825: regressions - FAIL"):
> memory.c: In function 'guest_remove_page':
> memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
> memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
> make[4]: *** [memory.o] Error 1
> make[4]: Leaving directory `/home/osstest/build.11825.build-i386/xen-unstable/xen/common'
> make[3]: *** [/home/osstest/build.11825.build-i386/xen-unstable/xen/common/built_in.o] Error 2

The patch below fixes it for me, but I'm not sure whether replacing
CONFIG_X86 with __x86_64__ is proper.


x86/mm: Fix 32-bit build by disabling some memory sharing code

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r dcc6d57e4c07 xen/common/memory.c
--- a/xen/common/memory.c	Thu Feb 02 15:28:58 2012 +0000
+++ b/xen/common/memory.c	Thu Feb 02 15:49:50 2012 +0000
@@ -182,7 +182,7 @@ int guest_remove_page(struct domain *d, 
     }
             
     page = mfn_to_page(mfn);
-#ifdef CONFIG_X86
+#ifdef __x86_64__
     if ( p2m_is_shared(p2mt) )
     {
         /* Unshare the page, bail out on error. We unshare because 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:52:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyxO-0006Ug-Ex; Thu, 02 Feb 2012 15:52: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 1RsyxM-0006UE-RM
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:52:17 +0000
Received: from [85.158.138.51:33301] by server-10.bemta-3.messagelabs.com id
	E0/CE-06813-D21BA2F4; Thu, 02 Feb 2012 15:52:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328197933!11750970!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5060 invoked from network); 2 Feb 2012 15:52:13 -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;
	2 Feb 2012 15:52:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10444531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:52:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:52:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsyxI-0008Et-LO; Thu, 02 Feb 2012 15:52:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsyxI-0003TY-Kh;
	Thu, 02 Feb 2012 15:52:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.45356.629462.89387@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 15:52:12 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120202154904.GQ48883@ocelot.phlegethon.org>
References: <osstest-11825-mainreport@xen.org>
	<20266.44126.591097.812929@mariner.uk.xensource.com>
	<20120202154904.GQ48883@ocelot.phlegethon.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>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan writes ("Re: [xen-unstable test] 11825: regressions - FAIL"):
> At 15:31 +0000 on 02 Feb (1328196702), Ian Jackson wrote:
> > xen.org writes ("[xen-unstable test] 11825: regressions - FAIL"):
> > >  build-i386                    4 xen-build                 fail   like 11637
...
> > cc1: warnings being treated as errors
> > memory.c: In function 'guest_remove_page':
> > memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
> > memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
> > make[4]: *** [memory.o] Error 1
> 
> Oops!  Fixed by 24691:3432abcf9380.

Ah, great, thanks.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 15:52:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 15:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsyxO-0006Ug-Ex; Thu, 02 Feb 2012 15:52: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 1RsyxM-0006UE-RM
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 15:52:17 +0000
Received: from [85.158.138.51:33301] by server-10.bemta-3.messagelabs.com id
	E0/CE-06813-D21BA2F4; Thu, 02 Feb 2012 15:52:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328197933!11750970!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5060 invoked from network); 2 Feb 2012 15:52:13 -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;
	2 Feb 2012 15:52:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10444531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 15:52:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 15:52:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsyxI-0008Et-LO; Thu, 02 Feb 2012 15:52:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsyxI-0003TY-Kh;
	Thu, 02 Feb 2012 15:52:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20266.45356.629462.89387@mariner.uk.xensource.com>
Date: Thu, 2 Feb 2012 15:52:12 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120202154904.GQ48883@ocelot.phlegethon.org>
References: <osstest-11825-mainreport@xen.org>
	<20266.44126.591097.812929@mariner.uk.xensource.com>
	<20120202154904.GQ48883@ocelot.phlegethon.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>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11825: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan writes ("Re: [xen-unstable test] 11825: regressions - FAIL"):
> At 15:31 +0000 on 02 Feb (1328196702), Ian Jackson wrote:
> > xen.org writes ("[xen-unstable test] 11825: regressions - FAIL"):
> > >  build-i386                    4 xen-build                 fail   like 11637
...
> > cc1: warnings being treated as errors
> > memory.c: In function 'guest_remove_page':
> > memory.c:192: error: implicit declaration of function 'mem_sharing_unshare_page'
> > memory.c:192: error: nested extern declaration of 'mem_sharing_unshare_page'
> > make[4]: *** [memory.o] Error 1
> 
> Oops!  Fixed by 24691:3432abcf9380.

Ah, great, thanks.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszdG-0008Au-8R; Thu, 02 Feb 2012 16:35:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RszdE-0008Ap-P0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:35:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328200526!2242431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3346 invoked from network); 2 Feb 2012 16:35:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:35:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10446642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 16:35:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 16:35:25 +0000
Date: Thu, 2 Feb 2012 16:37:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH 00/11] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Ian Campbell (4):
      arm: add stub hvm/save.h
      libxl: do not allocate e820 for non x86 guests.
      blktap2/libvhd: Build shared objects using -fPIC.
      tools: only compile libfsimage/xfs on X86

Stefano Stabellini (7):
      arm: few missing #define
      arm: arch_dump_shared_mem_info as a no-op
      arm: compile libxc
      arm: compile libxenguest
      arm: compile libxl
      arm: compile memshr
      arm: compile xentrace

 tools/blktap2/vhd/lib/Makefile         |   13 +++-
 tools/libfsimage/Makefile              |    3 +-
 tools/libxc/Makefile                   |   16 ++++-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h              |   60 ++++++++++++++++++
 tools/libxc/xc_dom_arm.c               |   49 +++++++++++++++
 tools/libxc/xc_nohvm.c                 |   31 +++++++++
 tools/libxc/xc_nomigrate.c             |   40 ++++++++++++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    1 +
 tools/libxl/libxl_create.c             |    3 +-
 tools/libxl/libxl_json.c               |    8 +++
 tools/libxl/libxl_nocpuid.c            |    2 +-
 tools/libxl/libxl_pci.c                |    2 +
 tools/memshr/bidir-hash.c              |   31 +++++++++
 tools/xentrace/xenctx.c                |   12 ++++
 xen/arch/arm/mm.c                      |    4 +
 xen/include/public/arch-arm.h          |    2 +
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 xen/include/public/io/protocols.h      |    3 +
 22 files changed, 423 insertions(+), 10 deletions(-)


A git tree based on 28b2fd7fcdc735178c509a895e52db07964c7b1b, plus my
previous arm patch series, is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-1

Cheers,

Stefano

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszdG-0008Au-8R; Thu, 02 Feb 2012 16:35:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RszdE-0008Ap-P0
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:35:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328200526!2242431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3346 invoked from network); 2 Feb 2012 16:35:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:35:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10446642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 16:35:25 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 16:35:25 +0000
Date: Thu, 2 Feb 2012 16:37:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Tim Deegan <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH 00/11] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Ian Campbell (4):
      arm: add stub hvm/save.h
      libxl: do not allocate e820 for non x86 guests.
      blktap2/libvhd: Build shared objects using -fPIC.
      tools: only compile libfsimage/xfs on X86

Stefano Stabellini (7):
      arm: few missing #define
      arm: arch_dump_shared_mem_info as a no-op
      arm: compile libxc
      arm: compile libxenguest
      arm: compile libxl
      arm: compile memshr
      arm: compile xentrace

 tools/blktap2/vhd/lib/Makefile         |   13 +++-
 tools/libfsimage/Makefile              |    3 +-
 tools/libxc/Makefile                   |   16 ++++-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h              |   60 ++++++++++++++++++
 tools/libxc/xc_dom_arm.c               |   49 +++++++++++++++
 tools/libxc/xc_nohvm.c                 |   31 +++++++++
 tools/libxc/xc_nomigrate.c             |   40 ++++++++++++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    1 +
 tools/libxl/libxl_create.c             |    3 +-
 tools/libxl/libxl_json.c               |    8 +++
 tools/libxl/libxl_nocpuid.c            |    2 +-
 tools/libxl/libxl_pci.c                |    2 +
 tools/memshr/bidir-hash.c              |   31 +++++++++
 tools/xentrace/xenctx.c                |   12 ++++
 xen/arch/arm/mm.c                      |    4 +
 xen/include/public/arch-arm.h          |    2 +
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 xen/include/public/io/protocols.h      |    3 +
 22 files changed, 423 insertions(+), 10 deletions(-)


A git tree based on 28b2fd7fcdc735178c509a895e52db07964c7b1b, plus my
previous arm patch series, is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-1

Cheers,

Stefano

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszds-0008Cg-MN; Thu, 02 Feb 2012 16:36:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdr-0008Bz-7f
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328200563!13394251!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7957 invoked from network); 2 Feb 2012 16:36:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553912"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2f008368;
	Thu, 2 Feb 2012 08:35:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:00 +0000
Message-ID: <1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 01/11] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Few missing #define are the cause of a compile failure with
XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
native compilation). This patch fill the gaps.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm.h     |    2 ++
 xen/include/public/io/protocols.h |    3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c430cf3..e04c4fd 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
 
 struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
+typedef unsigned long xen_callback_t;
+
 #endif
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
index 77bd1bd..0b7a2ea 100644
--- a/xen/include/public/io/protocols.h
+++ b/xen/include/public/io/protocols.h
@@ -26,6 +26,7 @@
 #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -33,6 +34,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
 #elif defined(__ia64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszds-0008Cg-MN; Thu, 02 Feb 2012 16:36:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdr-0008Bz-7f
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328200563!13394251!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7957 invoked from network); 2 Feb 2012 16:36:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553912"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2f008368;
	Thu, 2 Feb 2012 08:35:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:00 +0000
Message-ID: <1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 01/11] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Few missing #define are the cause of a compile failure with
XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
native compilation). This patch fill the gaps.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm.h     |    2 ++
 xen/include/public/io/protocols.h |    3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c430cf3..e04c4fd 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
 
 struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
+typedef unsigned long xen_callback_t;
+
 #endif
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
index 77bd1bd..0b7a2ea 100644
--- a/xen/include/public/io/protocols.h
+++ b/xen/include/public/io/protocols.h
@@ -26,6 +26,7 @@
 #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -33,6 +34,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
 #elif defined(__ia64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszdy-0008DD-44; Thu, 02 Feb 2012 16:36:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdw-0008CV-Mv
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328200563!13394251!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8248 invoked from network); 2 Feb 2012 16:36:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2j008368;
	Thu, 2 Feb 2012 08:36:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:04 +0000
Message-ID: <1328200690-26454-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 05/11] blktap2/libvhd: Build shared objects
	using -fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap2/vhd/lib/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile
index b72e4d9..1acee70 100644
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -49,27 +49,32 @@ LIB-SRCS        += atomicio.c
 LIB-OBJS         = $(patsubst %.c,%.o,$(LIB-SRCS))
 LIB-OBJS        += $(LVM-UTIL-OBJ)
 
+LIB-PICOBJS      = $(patsubst %.o,%.opic,$(LIB-OBJS))
+
 LIBVHD           = libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 all: build
 
-build: $(LIBVHD-BUILD)
+build: libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 libvhd.a: $(LIB-OBJS)
+	$(AR) rc $@ $^
+
+libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR): $(LIB-PICOBJS)
 	$(CC) -Wl,$(SONAME_LDFLAG),$(LIBVHD-SONAME) $(SHLIB_LDFLAGS) \
 		$(LDFLAGS) -o libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $^ $(LIBS)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) libvhd.so
-	$(AR) rc $@ $^
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) $(LIBVHD) $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so
 
 clean:
-	rm -rf *.a *.so* *.o *~ $(DEPS) $(LIBVHD)
+	rm -rf *.a *.so* *.o *.opic *~ $(DEPS) $(LIBVHD)
 
 .PHONY: all build clean install libvhd
 
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszdy-0008DD-44; Thu, 02 Feb 2012 16:36:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdw-0008CV-Mv
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328200563!13394251!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8248 invoked from network); 2 Feb 2012 16:36:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2j008368;
	Thu, 2 Feb 2012 08:36:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:04 +0000
Message-ID: <1328200690-26454-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 05/11] blktap2/libvhd: Build shared objects
	using -fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap2/vhd/lib/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile
index b72e4d9..1acee70 100644
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -49,27 +49,32 @@ LIB-SRCS        += atomicio.c
 LIB-OBJS         = $(patsubst %.c,%.o,$(LIB-SRCS))
 LIB-OBJS        += $(LVM-UTIL-OBJ)
 
+LIB-PICOBJS      = $(patsubst %.o,%.opic,$(LIB-OBJS))
+
 LIBVHD           = libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 all: build
 
-build: $(LIBVHD-BUILD)
+build: libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 libvhd.a: $(LIB-OBJS)
+	$(AR) rc $@ $^
+
+libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR): $(LIB-PICOBJS)
 	$(CC) -Wl,$(SONAME_LDFLAG),$(LIBVHD-SONAME) $(SHLIB_LDFLAGS) \
 		$(LDFLAGS) -o libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $^ $(LIBS)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) libvhd.so
-	$(AR) rc $@ $^
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) $(LIBVHD) $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so
 
 clean:
-	rm -rf *.a *.so* *.o *~ $(DEPS) $(LIBVHD)
+	rm -rf *.a *.so* *.o *.opic *~ $(DEPS) $(LIBVHD)
 
 .PHONY: all build clean install libvhd
 
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze0-0008Dl-Gy; Thu, 02 Feb 2012 16:36:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdy-0008DB-DH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:18 +0000
Received: from [85.158.138.51:40877] by server-11.bemta-3.messagelabs.com id
	0F/50-21643-18BBA2F4; Thu, 02 Feb 2012 16:36:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328200574!11588408!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25898 invoked from network); 2 Feb 2012 16:36:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180153723"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2g008368;
	Thu, 2 Feb 2012 08:35:58 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:01 +0000
Message-ID: <1328200690-26454-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 02/11] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze0-0008Dl-Gy; Thu, 02 Feb 2012 16:36:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdy-0008DB-DH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:18 +0000
Received: from [85.158.138.51:40877] by server-11.bemta-3.messagelabs.com id
	0F/50-21643-18BBA2F4; Thu, 02 Feb 2012 16:36:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328200574!11588408!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25898 invoked from network); 2 Feb 2012 16:36:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180153723"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2g008368;
	Thu, 2 Feb 2012 08:35:58 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:01 +0000
Message-ID: <1328200690-26454-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 02/11] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze8-0008H8-6M; Thu, 02 Feb 2012 16:36:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze6-0008E0-DU
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16828 invoked from network); 2 Feb 2012 16:36:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553963"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2m008368;
	Thu, 2 Feb 2012 08:36:07 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:07 +0000
Message-ID: <1328200690-26454-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 08/11] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_json.c    |    8 ++++++++
 tools/libxl/libxl_nocpuid.c |    2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3c3661b..5dcaa0e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -32,6 +32,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 6ff2910..f35943b 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,6 +140,7 @@ out:
     return s;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                 libxl_cpuid_policy_list *pcpuid)
 {
@@ -199,6 +200,13 @@ empty:
 out:
     return s;
 }
+#else
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+#endif
 
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..313d55b 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze8-0008H8-6M; Thu, 02 Feb 2012 16:36:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze6-0008E0-DU
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16828 invoked from network); 2 Feb 2012 16:36:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553963"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2m008368;
	Thu, 2 Feb 2012 08:36:07 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:07 +0000
Message-ID: <1328200690-26454-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 08/11] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_json.c    |    8 ++++++++
 tools/libxl/libxl_nocpuid.c |    2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3c3661b..5dcaa0e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -32,6 +32,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 6ff2910..f35943b 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,6 +140,7 @@ out:
     return s;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                 libxl_cpuid_policy_list *pcpuid)
 {
@@ -199,6 +200,13 @@ empty:
 out:
     return s;
 }
+#else
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+#endif
 
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..313d55b 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze9-0008I3-KP; Thu, 02 Feb 2012 16:36:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze8-0008Et-Ta
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17236 invoked from network); 2 Feb 2012 16:36:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553965"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2o008368;
	Thu, 2 Feb 2012 08:36:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:09 +0000
Message-ID: <1328200690-26454-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 10/11] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..29c70e1 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef unsigned long long guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze1-0008E7-Au; Thu, 02 Feb 2012 16:36:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdz-0008DS-QH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:20 +0000
Received: from [85.158.138.51:40979] by server-2.bemta-3.messagelabs.com id
	F6/41-15021-28BBA2F4; Thu, 02 Feb 2012 16:36:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328200574!11588408!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26005 invoked from network); 2 Feb 2012 16:36:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180153739"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:13 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2i008368;
	Thu, 2 Feb 2012 08:36:01 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:03 +0000
Message-ID: <1328200690-26454-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 04/11] libxl: do not allocate e820 for non x86
	guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ++-
 tools/libxl/libxl_pci.c    |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e1c615f..05c0b67 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -652,7 +652,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
+#if defined(__i386__) || defined(__x86_64__)
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         d_config->b_info.u.pv.e820_host) {
         int rc;
@@ -662,6 +662,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
                       rc, errno);
     }
+#endif
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 99591c2..c545b85 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1149,6 +1149,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -1390,6 +1391,7 @@ int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_conf
     }
     return 0;
 }
+#endif
 
 /*
  * Local variables:
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze9-0008I3-KP; Thu, 02 Feb 2012 16:36:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze8-0008Et-Ta
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17236 invoked from network); 2 Feb 2012 16:36:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553965"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2o008368;
	Thu, 2 Feb 2012 08:36:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:09 +0000
Message-ID: <1328200690-26454-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 10/11] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..29c70e1 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef unsigned long long guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze1-0008E7-Au; Thu, 02 Feb 2012 16:36:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdz-0008DS-QH
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:20 +0000
Received: from [85.158.138.51:40979] by server-2.bemta-3.messagelabs.com id
	F6/41-15021-28BBA2F4; Thu, 02 Feb 2012 16:36:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328200574!11588408!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26005 invoked from network); 2 Feb 2012 16:36:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180153739"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:13 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2i008368;
	Thu, 2 Feb 2012 08:36:01 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:03 +0000
Message-ID: <1328200690-26454-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 04/11] libxl: do not allocate e820 for non x86
	guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ++-
 tools/libxl/libxl_pci.c    |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e1c615f..05c0b67 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -652,7 +652,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
+#if defined(__i386__) || defined(__x86_64__)
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         d_config->b_info.u.pv.e820_host) {
         int rc;
@@ -662,6 +662,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
                       rc, errno);
     }
+#endif
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 99591c2..c545b85 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1149,6 +1149,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -1390,6 +1391,7 @@ int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_conf
     }
     return 0;
 }
+#endif
 
 /*
  * Local variables:
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze0-0008Dx-TS; Thu, 02 Feb 2012 16:36:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdz-0008DK-80
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:19 +0000
Received: from [85.158.138.51:40913] by server-1.bemta-3.messagelabs.com id
	45/2D-23590-28BBA2F4; Thu, 02 Feb 2012 16:36:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328200574!11588408!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25957 invoked from network); 2 Feb 2012 16:36:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180153731"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:11 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2h008368;
	Thu, 2 Feb 2012 08:36:00 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:02 +0000
Message-ID: <1328200690-26454-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 03/11] arm: arch_dump_shared_mem_info as a no-op
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/mm.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..7ce9a70 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -311,6 +311,10 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+}
 /*
  * Local variables:
  * mode: C
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze0-0008Dx-TS; Thu, 02 Feb 2012 16:36:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rszdz-0008DK-80
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:19 +0000
Received: from [85.158.138.51:40913] by server-1.bemta-3.messagelabs.com id
	45/2D-23590-28BBA2F4; Thu, 02 Feb 2012 16:36:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328200574!11588408!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25957 invoked from network); 2 Feb 2012 16:36:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180153731"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:11 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2h008368;
	Thu, 2 Feb 2012 08:36:00 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:02 +0000
Message-ID: <1328200690-26454-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 03/11] arm: arch_dump_shared_mem_info as a no-op
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/mm.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..7ce9a70 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -311,6 +311,10 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+}
 /*
  * Local variables:
  * mode: C
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze6-0008GD-CK; Thu, 02 Feb 2012 16:36:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze4-0008DV-S3
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16731 invoked from network); 2 Feb 2012 16:36:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553960"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2k008368;
	Thu, 2 Feb 2012 08:36:04 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:05 +0000
Message-ID: <1328200690-26454-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 06/11] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 7813331..a8235fb 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze6-0008GD-CK; Thu, 02 Feb 2012 16:36:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze4-0008DV-S3
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16731 invoked from network); 2 Feb 2012 16:36:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553960"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2k008368;
	Thu, 2 Feb 2012 08:36:04 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:05 +0000
Message-ID: <1328200690-26454-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 06/11] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 7813331..a8235fb 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze7-0008Gs-QQ; Thu, 02 Feb 2012 16:36:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze5-0008Dk-QX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16769 invoked from network); 2 Feb 2012 16:36:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553962"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2l008368;
	Thu, 2 Feb 2012 08:36:06 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:06 +0000
Message-ID: <1328200690-26454-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 07/11] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Also provide empty implementations of xc_domain_save, xc_domain_restore
and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
set.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile       |   15 ++++++++++--
 tools/libxc/xc_dom_arm.c   |   49 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nohvm.c     |   31 +++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c |   40 +++++++++++++++++++++++++++++++++++
 4 files changed, 132 insertions(+), 3 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 create mode 100644 tools/libxc/xc_nohvm.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..57ceee6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,17 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
+ifeq ($(CONFIG_HVM),y)
+GUEST_SRCS-y += xc_hvm_build.c
+else
+GUEST_SRCS-y += xc_nohvm.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -62,6 +70,7 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nohvm.c b/tools/libxc/xc_nohvm.c
new file mode 100644
index 0000000..a899f7c
--- /dev/null
+++ b/tools/libxc/xc_nohvm.c
@@ -0,0 +1,31 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..63090e0
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,40 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      unsigned int console_evtchn, unsigned long *console_mfn,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze7-0008Gs-QQ; Thu, 02 Feb 2012 16:36:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze5-0008Dk-QX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16769 invoked from network); 2 Feb 2012 16:36:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553962"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2l008368;
	Thu, 2 Feb 2012 08:36:06 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:06 +0000
Message-ID: <1328200690-26454-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 07/11] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Also provide empty implementations of xc_domain_save, xc_domain_restore
and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
set.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile       |   15 ++++++++++--
 tools/libxc/xc_dom_arm.c   |   49 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nohvm.c     |   31 +++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c |   40 +++++++++++++++++++++++++++++++++++
 4 files changed, 132 insertions(+), 3 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 create mode 100644 tools/libxc/xc_nohvm.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..57ceee6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,17 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
+ifeq ($(CONFIG_HVM),y)
+GUEST_SRCS-y += xc_hvm_build.c
+else
+GUEST_SRCS-y += xc_nohvm.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -62,6 +70,7 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nohvm.c b/tools/libxc/xc_nohvm.c
new file mode 100644
index 0000000..a899f7c
--- /dev/null
+++ b/tools/libxc/xc_nohvm.c
@@ -0,0 +1,31 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..63090e0
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,40 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      unsigned int console_evtchn, unsigned long *console_mfn,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze5-0008Fv-UB; Thu, 02 Feb 2012 16:36:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze4-0008DR-7d
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 2 Feb 2012 16:36:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553959"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2n008368;
	Thu, 2 Feb 2012 08:36:08 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:08 +0000
Message-ID: <1328200690-26454-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 09/11] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rsze5-0008Fv-UB; Thu, 02 Feb 2012 16:36:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rsze4-0008DR-7d
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328200576!13235478!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 2 Feb 2012 16:36:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553959"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2n008368;
	Thu, 2 Feb 2012 08:36:08 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:08 +0000
Message-ID: <1328200690-26454-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 09/11] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszeJ-0008Qv-7E; Thu, 02 Feb 2012 16:36:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RszeI-0008KV-5x
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328200589!11157285!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 2 Feb 2012 16:36:31 -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;
	2 Feb 2012 16:36:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553968"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:28 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2p008368;
	Thu, 2 Feb 2012 08:36:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:10 +0000
Message-ID: <1328200690-26454-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 11/11] tools: only compile libfsimage/xfs on X86
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

xfs is not portable, only compile it on X86

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libfsimage/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 2deb830..bcb8b40 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,7 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS-y = common ufs reiserfs iso9660 fat zfs xfs
+SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC="$(CC)" ./check-libext2fs)
 
 .PHONY: all clean install
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszeJ-0008Qv-7E; Thu, 02 Feb 2012 16:36:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RszeI-0008KV-5x
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:36:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328200589!11157285!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 2 Feb 2012 16:36:31 -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;
	2 Feb 2012 16:36:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21553968"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:36:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:36:28 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GZt2p008368;
	Thu, 2 Feb 2012 08:36:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:38:10 +0000
Message-ID: <1328200690-26454-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH 11/11] tools: only compile libfsimage/xfs on X86
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

xfs is not portable, only compile it on X86

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libfsimage/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 2deb830..bcb8b40 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,7 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS-y = common ufs reiserfs iso9660 fat zfs xfs
+SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC="$(CC)" ./check-libext2fs)
 
 .PHONY: all clean install
-- 
1.7.8.3


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:41:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszip-0001Ky-13; Thu, 02 Feb 2012 16:41:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rszin-0001Kb-74
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:41:17 +0000
Received: from [85.158.138.51:12966] by server-5.bemta-3.messagelabs.com id
	6C/A1-25695-CACBA2F4; Thu, 02 Feb 2012 16:41:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328200874!11762429!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26539 invoked from network); 2 Feb 2012 16:41:14 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 16:41:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rszij-000Eht-O7; Thu, 02 Feb 2012 16:41:13 +0000
Date: Thu, 2 Feb 2012 16:41:13 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120202164113.GR48883@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
	<1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 01/11] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:38 +0000 on 02 Feb (1328200680), Stefano Stabellini wrote:
> Few missing #define are the cause of a compile failure with
> XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> native compilation). This patch fill the gaps.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/include/public/arch-arm.h     |    2 ++
>  xen/include/public/io/protocols.h |    3 +++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index c430cf3..e04c4fd 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
>  
>  struct arch_shared_info { };
>  typedef struct arch_shared_info arch_shared_info_t;
> +typedef unsigned long xen_callback_t;

Can we make all new public interfaces explicitly sized, please?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:41:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszip-0001Ky-13; Thu, 02 Feb 2012 16:41:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rszin-0001Kb-74
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:41:17 +0000
Received: from [85.158.138.51:12966] by server-5.bemta-3.messagelabs.com id
	6C/A1-25695-CACBA2F4; Thu, 02 Feb 2012 16:41:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328200874!11762429!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26539 invoked from network); 2 Feb 2012 16:41:14 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 16:41:14 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rszij-000Eht-O7; Thu, 02 Feb 2012 16:41:13 +0000
Date: Thu, 2 Feb 2012 16:41:13 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120202164113.GR48883@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
	<1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 01/11] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:38 +0000 on 02 Feb (1328200680), Stefano Stabellini wrote:
> Few missing #define are the cause of a compile failure with
> XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> native compilation). This patch fill the gaps.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/include/public/arch-arm.h     |    2 ++
>  xen/include/public/io/protocols.h |    3 +++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index c430cf3..e04c4fd 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
>  
>  struct arch_shared_info { };
>  typedef struct arch_shared_info arch_shared_info_t;
> +typedef unsigned long xen_callback_t;

Can we make all new public interfaces explicitly sized, please?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:44:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1RszmC-0001ef-MO; Thu, 02 Feb 2012 16:44:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RszmB-0001eU-Tp
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:44:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328201081!12612240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28598 invoked from network); 2 Feb 2012 16:44:41 -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;
	2 Feb 2012 16:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10447028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 16:44:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 16:44:40 +0000
Date: Thu, 2 Feb 2012 16:46:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327077375-7623-25-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1202021645430.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
	<1327077375-7623-25-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 25/27] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Stefano Stabellini wrote:
> Makefile and config options for the ARM architecture.
> 
> 
> Changes in v2:
> 
> - move patch at the end of the series.

The other generic patches of this series have been applied, but this one
hasn't.  Could you please apply this patch or tell me whether I have to
change something?


> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> ---
>  config/arm.mk         |   18 +++++++++++
>  xen/arch/arm/Makefile |   76 +++++++++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/Rules.mk |   29 ++++++++++++++++++
>  3 files changed, 123 insertions(+), 0 deletions(-)
>  create mode 100644 config/arm.mk
>  create mode 100644 xen/arch/arm/Makefile
>  create mode 100644 xen/arch/arm/Rules.mk
> 
> diff --git a/config/arm.mk b/config/arm.mk
> new file mode 100644
> index 0000000..f64f0c1
> --- /dev/null
> +++ b/config/arm.mk
> @@ -0,0 +1,18 @@
> +CONFIG_ARM := y
> +CONFIG_ARM_32 := y
> +CONFIG_ARM_$(XEN_OS) := y
> +
> +# -march= -mcpu=
> +
> +# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
> +CFLAGS += -marm
> +
> +HAS_PL011 := y
> +
> +# Use only if calling $(LD) directly.
> +#LDFLAGS_DIRECT_OpenBSD = _obsd
> +#LDFLAGS_DIRECT_FreeBSD = _fbsd
> +LDFLAGS_DIRECT_Linux = _linux
> +LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> +
> +CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> new file mode 100644
> index 0000000..5a07ae7
> --- /dev/null
> +++ b/xen/arch/arm/Makefile
> @@ -0,0 +1,76 @@
> +subdir-y += lib
> +
> +obj-y += dummy.o
> +obj-y += entry.o
> +obj-y += domain.o
> +obj-y += domain_build.o
> +obj-y += gic.o
> +obj-y += io.o
> +obj-y += irq.o
> +obj-y += mm.o
> +obj-y += p2m.o
> +obj-y += guestcopy.o
> +obj-y += setup.o
> +obj-y += time.o
> +obj-y += smpboot.o
> +obj-y += smp.o
> +obj-y += shutdown.o
> +obj-y += traps.o
> +obj-y += vgic.o
> +obj-y += vtimer.o
> +
> +#obj-bin-y += ....o
> +
> +ALL_OBJS := head.o $(ALL_OBJS)
> +
> +$(TARGET): $(TARGET)-syms
> +	# XXX: VE model loads by VMA so instead of
> +	# making a proper ELF we link with LMA == VMA and adjust crudely
> +	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
> +	# XXX strip it
> +
> +#$(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/'`
> +
> +ifeq ($(lto),y)
> +# Gather all LTO objects together
> +prelink_lto.o: $(ALL_OBJS)
> +	$(LD_LTO) -r -o $@ $^
> +
> +# Link it with all the binary objects
> +prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
> +	$(LD) $(LDFLAGS) -r -o $@ $^
> +else
> +prelink.o: $(ALL_OBJS)
> +	$(LD) $(LDFLAGS) -r -o $@ $^
> +endif
> +
> +$(BASEDIR)/common/symbols-dummy.o:
> +	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
> +
> +$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> +	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> +	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
> +	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> +	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> +	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
> +	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
> +	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +	    $(@D)/.$(@F).1.o -o $@
> +	rm -f $(@D)/.$(@F).[0-9]*
> +
> +asm-offsets.s: asm-offsets.c
> +	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
> +
> +xen.lds: xen.lds.S
> +	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
> +	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
> +	mv -f .xen.lds.d.new .xen.lds.d
> +
> +.PHONY: clean
> +clean::
> +	rm -f asm-offsets.s xen.lds
> +	rm -f $(BASEDIR)/.xen-syms.[0-9]*
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> new file mode 100644
> index 0000000..336e209
> --- /dev/null
> +++ b/xen/arch/arm/Rules.mk
> @@ -0,0 +1,29 @@
> +########################################
> +# arm-specific definitions
> +
> +#
> +# If you change any of these configuration options then you must
> +# 'make clean' before rebuilding.
> +#
> +
> +CFLAGS += -fno-builtin -fno-common -Wredundant-decls
> +CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
> +CFLAGS += -I$(BASEDIR)/include
> +
> +# Prevent floating-point variables from creeping into Xen.
> +CFLAGS += -msoft-float
> +
> +$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> +$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
> +
> +arm := y
> +
> +ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
> +CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
> +endif
> +
> +CFLAGS += -march=armv7-a -mcpu=cortex-a15
> +
> +# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
> +check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
> +$(eval $(check-y))
> -- 
> 1.7.2.5
> 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:44:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1RszmC-0001ef-MO; Thu, 02 Feb 2012 16:44:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RszmB-0001eU-Tp
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:44:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328201081!12612240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28598 invoked from network); 2 Feb 2012 16:44:41 -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;
	2 Feb 2012 16:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10447028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 16:44:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 16:44:40 +0000
Date: Thu, 2 Feb 2012 16:46:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327077375-7623-25-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1202021645430.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
	<1327077375-7623-25-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 25/27] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Stefano Stabellini wrote:
> Makefile and config options for the ARM architecture.
> 
> 
> Changes in v2:
> 
> - move patch at the end of the series.

The other generic patches of this series have been applied, but this one
hasn't.  Could you please apply this patch or tell me whether I have to
change something?


> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> ---
>  config/arm.mk         |   18 +++++++++++
>  xen/arch/arm/Makefile |   76 +++++++++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/Rules.mk |   29 ++++++++++++++++++
>  3 files changed, 123 insertions(+), 0 deletions(-)
>  create mode 100644 config/arm.mk
>  create mode 100644 xen/arch/arm/Makefile
>  create mode 100644 xen/arch/arm/Rules.mk
> 
> diff --git a/config/arm.mk b/config/arm.mk
> new file mode 100644
> index 0000000..f64f0c1
> --- /dev/null
> +++ b/config/arm.mk
> @@ -0,0 +1,18 @@
> +CONFIG_ARM := y
> +CONFIG_ARM_32 := y
> +CONFIG_ARM_$(XEN_OS) := y
> +
> +# -march= -mcpu=
> +
> +# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
> +CFLAGS += -marm
> +
> +HAS_PL011 := y
> +
> +# Use only if calling $(LD) directly.
> +#LDFLAGS_DIRECT_OpenBSD = _obsd
> +#LDFLAGS_DIRECT_FreeBSD = _fbsd
> +LDFLAGS_DIRECT_Linux = _linux
> +LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> +
> +CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> new file mode 100644
> index 0000000..5a07ae7
> --- /dev/null
> +++ b/xen/arch/arm/Makefile
> @@ -0,0 +1,76 @@
> +subdir-y += lib
> +
> +obj-y += dummy.o
> +obj-y += entry.o
> +obj-y += domain.o
> +obj-y += domain_build.o
> +obj-y += gic.o
> +obj-y += io.o
> +obj-y += irq.o
> +obj-y += mm.o
> +obj-y += p2m.o
> +obj-y += guestcopy.o
> +obj-y += setup.o
> +obj-y += time.o
> +obj-y += smpboot.o
> +obj-y += smp.o
> +obj-y += shutdown.o
> +obj-y += traps.o
> +obj-y += vgic.o
> +obj-y += vtimer.o
> +
> +#obj-bin-y += ....o
> +
> +ALL_OBJS := head.o $(ALL_OBJS)
> +
> +$(TARGET): $(TARGET)-syms
> +	# XXX: VE model loads by VMA so instead of
> +	# making a proper ELF we link with LMA == VMA and adjust crudely
> +	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
> +	# XXX strip it
> +
> +#$(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/'`
> +
> +ifeq ($(lto),y)
> +# Gather all LTO objects together
> +prelink_lto.o: $(ALL_OBJS)
> +	$(LD_LTO) -r -o $@ $^
> +
> +# Link it with all the binary objects
> +prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
> +	$(LD) $(LDFLAGS) -r -o $@ $^
> +else
> +prelink.o: $(ALL_OBJS)
> +	$(LD) $(LDFLAGS) -r -o $@ $^
> +endif
> +
> +$(BASEDIR)/common/symbols-dummy.o:
> +	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
> +
> +$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> +	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> +	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
> +	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> +	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> +	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
> +	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
> +	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +	    $(@D)/.$(@F).1.o -o $@
> +	rm -f $(@D)/.$(@F).[0-9]*
> +
> +asm-offsets.s: asm-offsets.c
> +	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
> +
> +xen.lds: xen.lds.S
> +	$(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o $@ $<
> +	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
> +	mv -f .xen.lds.d.new .xen.lds.d
> +
> +.PHONY: clean
> +clean::
> +	rm -f asm-offsets.s xen.lds
> +	rm -f $(BASEDIR)/.xen-syms.[0-9]*
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> new file mode 100644
> index 0000000..336e209
> --- /dev/null
> +++ b/xen/arch/arm/Rules.mk
> @@ -0,0 +1,29 @@
> +########################################
> +# arm-specific definitions
> +
> +#
> +# If you change any of these configuration options then you must
> +# 'make clean' before rebuilding.
> +#
> +
> +CFLAGS += -fno-builtin -fno-common -Wredundant-decls
> +CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
> +CFLAGS += -I$(BASEDIR)/include
> +
> +# Prevent floating-point variables from creeping into Xen.
> +CFLAGS += -msoft-float
> +
> +$(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
> +$(call cc-option-add,CFLAGS,CC,-Wnested-externs)
> +
> +arm := y
> +
> +ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
> +CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
> +endif
> +
> +CFLAGS += -march=armv7-a -mcpu=cortex-a15
> +
> +# Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
> +check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")
> +$(eval $(check-y))
> -- 
> 1.7.2.5
> 

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:44:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszmI-0001fC-3c; Thu, 02 Feb 2012 16:44:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RszmG-0001eZ-KK
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:44:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328201081!12612240!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28706 invoked from network); 2 Feb 2012 16:44: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;
	2 Feb 2012 16:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10447033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 16: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.213.0; Thu, 2 Feb 2012
	16:44:46 +0000
Message-ID: <1328201084.6133.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 2 Feb 2012 16:44:44 +0000
In-Reply-To: <20120202164113.GR48883@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
	<1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120202164113.GR48883@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01/11] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 16:41 +0000, Tim Deegan wrote:
> At 16:38 +0000 on 02 Feb (1328200680), Stefano Stabellini wrote:
> > Few missing #define are the cause of a compile failure with
> > XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> > native compilation). This patch fill the gaps.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/include/public/arch-arm.h     |    2 ++
> >  xen/include/public/io/protocols.h |    3 +++
> >  2 files changed, 5 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> > index c430cf3..e04c4fd 100644
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
> >  
> >  struct arch_shared_info { };
> >  typedef struct arch_shared_info arch_shared_info_t;
> > +typedef unsigned long xen_callback_t;
> 
> Can we make all new public interfaces explicitly sized, please?

Yes please, and explicitly sized in a way which is compatible with 64
bits too (i.e. u64 here rather than u32 even though PC happens to be 32
bits).

I'd quite like to do a sweep of the existing interfaces and arrange this
to be the case even for existing interfaces when used on new
architectures. I expect that will be an enormous amount of churn though
-- possibly not worth it.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:44:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszmI-0001fC-3c; Thu, 02 Feb 2012 16:44:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RszmG-0001eZ-KK
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:44:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328201081!12612240!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28706 invoked from network); 2 Feb 2012 16:44: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;
	2 Feb 2012 16:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="10447033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 16: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.213.0; Thu, 2 Feb 2012
	16:44:46 +0000
Message-ID: <1328201084.6133.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 2 Feb 2012 16:44:44 +0000
In-Reply-To: <20120202164113.GR48883@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1202021536090.3196@kaball-desktop>
	<1328200690-26454-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120202164113.GR48883@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01/11] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 16:41 +0000, Tim Deegan wrote:
> At 16:38 +0000 on 02 Feb (1328200680), Stefano Stabellini wrote:
> > Few missing #define are the cause of a compile failure with
> > XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> > native compilation). This patch fill the gaps.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/include/public/arch-arm.h     |    2 ++
> >  xen/include/public/io/protocols.h |    3 +++
> >  2 files changed, 5 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> > index c430cf3..e04c4fd 100644
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
> >  
> >  struct arch_shared_info { };
> >  typedef struct arch_shared_info arch_shared_info_t;
> > +typedef unsigned long xen_callback_t;
> 
> Can we make all new public interfaces explicitly sized, please?

Yes please, and explicitly sized in a way which is compatible with 64
bits too (i.e. u64 here rather than u32 even though PC happens to be 32
bits).

I'd quite like to do a sweep of the existing interfaces and arrange this
to be the case even for existing interfaces when used on new
architectures. I expect that will be an enormous amount of churn though
-- possibly not worth it.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqm-0002FF-Lh; Thu, 02 Feb 2012 16:49:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszql-0002Eh-CG
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:31 +0000
Received: from [85.158.138.51:61376] by server-3.bemta-3.messagelabs.com id
	26/F5-18959-A9EBA2F4; Thu, 02 Feb 2012 16:49:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328201367!11758309!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22062 invoked from network); 2 Feb 2012 16:49:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157175"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:26 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPm008442;
	Thu, 2 Feb 2012 08:49:25 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:11 +0000
Message-ID: <1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |    6 +
 drivers/net/xen-netback/netback.c   |  158 ++++++++++++------------------
 drivers/net/xen-netback/page_pool.c |  185 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   63 ++++++++++++
 5 files changed, 317 insertions(+), 97 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..288b2f3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+	struct xenvif *vif;
+};
+typedef unsigned int pending_ring_idx_t;
+
 struct xen_netbk;
 
 struct xenvif {
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..d11205f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -46,12 +47,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-	struct xenvif *vif;
-};
-typedef unsigned int pending_ring_idx_t;
-
 struct netbk_rx_meta {
 	int id;
 	int size;
@@ -65,21 +60,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +69,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -100,7 +80,6 @@ struct xen_netbk {
 
 	atomic_t netfront_count;
 
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
 	u16 pending_ring[MAX_PENDING_REQS];
@@ -160,7 +139,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +148,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +338,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,10 +367,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
-			struct pending_tx_info *src_pend;
-
-			src_pend = &netbk->pending_tx_info[idx];
+			struct pending_tx_info *src_pend = to_txinfo(idx);
 
 			copy_gop->source.domid = src_pend->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
@@ -906,11 +843,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -931,8 +868,8 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	for (i = start; i < shinfo->nr_frags; i++, txp++) {
 		struct page *page;
 		pending_ring_idx_t index;
-		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		index = pending_index(netbk->pending_cons++);
 		pending_idx = netbk->pending_ring[index];
@@ -940,6 +877,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -953,9 +893,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 
 		gop++;
 
-		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
+		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
 		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -968,8 +908,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct pending_tx_info *pending_tx_info;
+	int idx;
+	struct xenvif *vif = NULL;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -980,7 +921,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[index];
+		pending_tx_info = to_txinfo(idx);
+		txp = &pending_tx_info->req;
+		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
 		xenvif_put(vif);
@@ -1005,7 +949,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		txp = &to_txinfo(idx)->req;
+		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
@@ -1042,10 +988,15 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		struct xen_netif_tx_request *txp;
 		struct page *page;
 		u16 pending_idx;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		txp = &pending_tx_info->req;
 		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
@@ -1053,7 +1004,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(page);
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1233,6 +1184,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int work_to_do;
 		unsigned int data_len;
 		pending_ring_idx_t index;
+		int pool_idx;
+		struct pending_tx_info *pending_tx_info;
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
@@ -1347,9 +1300,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		pool_idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(pool_idx);
+
+		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1397,10 +1353,16 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
-		txp = &netbk->pending_tx_info[pending_idx].req;
+
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		vif = pending_tx_info->vif;
+		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
 		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
@@ -1480,12 +1442,14 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
+	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	idx = netbk->mmap_pages[pending_idx];
+	pending_tx_info = to_txinfo(idx);
 
 	vif = pending_tx_info->vif;
 
@@ -1496,9 +1460,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1645,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..294f48b
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,185 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * 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 "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	int idx;
+
+	spin_lock(&pool_lock);
+
+	if (free_count == 0) {
+		spin_unlock(&pool_lock);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock(&pool_lock);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	spin_lock(&pool_lock);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock(&pool_lock);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
+
+struct pending_tx_info *to_txinfo(int idx)
+{
+	return &pool[idx].tx_info;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..572b037
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,63 @@
+/*
+ * 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 __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	struct pending_tx_info tx_info;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page            *to_page(int idx);
+struct xen_netbk       *to_netbk(int idx);
+struct pending_tx_info *to_txinfo(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqm-0002FF-Lh; Thu, 02 Feb 2012 16:49:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszql-0002Eh-CG
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:31 +0000
Received: from [85.158.138.51:61376] by server-3.bemta-3.messagelabs.com id
	26/F5-18959-A9EBA2F4; Thu, 02 Feb 2012 16:49:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328201367!11758309!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22062 invoked from network); 2 Feb 2012 16:49:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157175"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:26 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPm008442;
	Thu, 2 Feb 2012 08:49:25 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:11 +0000
Message-ID: <1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |    6 +
 drivers/net/xen-netback/netback.c   |  158 ++++++++++++------------------
 drivers/net/xen-netback/page_pool.c |  185 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   63 ++++++++++++
 5 files changed, 317 insertions(+), 97 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..288b2f3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+	struct xenvif *vif;
+};
+typedef unsigned int pending_ring_idx_t;
+
 struct xen_netbk;
 
 struct xenvif {
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..d11205f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -46,12 +47,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-	struct xenvif *vif;
-};
-typedef unsigned int pending_ring_idx_t;
-
 struct netbk_rx_meta {
 	int id;
 	int size;
@@ -65,21 +60,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +69,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -100,7 +80,6 @@ struct xen_netbk {
 
 	atomic_t netfront_count;
 
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
 	u16 pending_ring[MAX_PENDING_REQS];
@@ -160,7 +139,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +148,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +338,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,10 +367,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
-			struct pending_tx_info *src_pend;
-
-			src_pend = &netbk->pending_tx_info[idx];
+			struct pending_tx_info *src_pend = to_txinfo(idx);
 
 			copy_gop->source.domid = src_pend->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
@@ -906,11 +843,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -931,8 +868,8 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	for (i = start; i < shinfo->nr_frags; i++, txp++) {
 		struct page *page;
 		pending_ring_idx_t index;
-		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		index = pending_index(netbk->pending_cons++);
 		pending_idx = netbk->pending_ring[index];
@@ -940,6 +877,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -953,9 +893,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 
 		gop++;
 
-		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
+		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
 		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -968,8 +908,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct pending_tx_info *pending_tx_info;
+	int idx;
+	struct xenvif *vif = NULL;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -980,7 +921,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[index];
+		pending_tx_info = to_txinfo(idx);
+		txp = &pending_tx_info->req;
+		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
 		xenvif_put(vif);
@@ -1005,7 +949,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		txp = &to_txinfo(idx)->req;
+		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
@@ -1042,10 +988,15 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		struct xen_netif_tx_request *txp;
 		struct page *page;
 		u16 pending_idx;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		txp = &pending_tx_info->req;
 		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
@@ -1053,7 +1004,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(page);
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1233,6 +1184,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int work_to_do;
 		unsigned int data_len;
 		pending_ring_idx_t index;
+		int pool_idx;
+		struct pending_tx_info *pending_tx_info;
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
@@ -1347,9 +1300,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		pool_idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(pool_idx);
+
+		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1397,10 +1353,16 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
-		txp = &netbk->pending_tx_info[pending_idx].req;
+
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		vif = pending_tx_info->vif;
+		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
 		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
@@ -1480,12 +1442,14 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
+	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	idx = netbk->mmap_pages[pending_idx];
+	pending_tx_info = to_txinfo(idx);
 
 	vif = pending_tx_info->vif;
 
@@ -1496,9 +1460,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1645,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..294f48b
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,185 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * 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 "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	int idx;
+
+	spin_lock(&pool_lock);
+
+	if (free_count == 0) {
+		spin_unlock(&pool_lock);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock(&pool_lock);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	spin_lock(&pool_lock);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock(&pool_lock);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
+
+struct pending_tx_info *to_txinfo(int idx)
+{
+	return &pool[idx].tx_info;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..572b037
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,63 @@
+/*
+ * 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 __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	struct pending_tx_info tx_info;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page            *to_page(int idx);
+struct xen_netbk       *to_netbk(int idx);
+struct pending_tx_info *to_txinfo(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszqm-0002F2-8Q; Thu, 02 Feb 2012 16:49:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqk-0002Eb-ON
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:30 +0000
Received: from [85.158.138.51:61332] by server-2.bemta-3.messagelabs.com id
	33/8E-15021-99EBA2F4; Thu, 02 Feb 2012 16:49:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27290 invoked from network); 2 Feb 2012 16:49:28 -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;
	2 Feb 2012 16:49:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555446"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:28 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPn008442;
	Thu, 2 Feb 2012 08:49:26 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:12 +0000
Message-ID: <1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 288b2f3..372c7f5 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -126,6 +126,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d11205f..3059684 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,5 +1670,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	xenvif_xenbus_exit();
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszqm-0002F2-8Q; Thu, 02 Feb 2012 16:49:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqk-0002Eb-ON
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:30 +0000
Received: from [85.158.138.51:61332] by server-2.bemta-3.messagelabs.com id
	33/8E-15021-99EBA2F4; Thu, 02 Feb 2012 16:49:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27290 invoked from network); 2 Feb 2012 16:49:28 -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;
	2 Feb 2012 16:49:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555446"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:28 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPn008442;
	Thu, 2 Feb 2012 08:49:26 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:12 +0000
Message-ID: <1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 288b2f3..372c7f5 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -126,6 +126,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d11205f..3059684 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,5 +1670,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	xenvif_xenbus_exit();
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszqo-0002Fy-NC; Thu, 02 Feb 2012 16:49:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqn-0002Eo-PZ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:34 +0000
Received: from [85.158.138.51:63538] by server-1.bemta-3.messagelabs.com id
	8B/0A-23590-D9EBA2F4; Thu, 02 Feb 2012 16:49:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328201367!11758309!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22489 invoked from network); 2 Feb 2012 16:49:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157187"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:30 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPp008442;
	Thu, 2 Feb 2012 08:49:29 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:14 +0000
Message-ID: <1328201363-13915-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 04/13] netback: switch to NAPI + kthread
	model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

Changes in V4:

Remove unwanted notification generation during NAPI processing.

In original implementation, tx_build_gops tends to update req_event
pointer every time it sees tx error or finish one batch. Remove those
code to only update req_event pointer when we really want to shut down
NAPI.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   36 ++--
 drivers/net/xen-netback/interface.c |   95 ++++++---
 drivers/net/xen-netback/netback.c   |  381 +++++++++++------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 195 insertions(+), 318 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 372c7f5..1e4d462 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -61,14 +60,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -99,11 +101,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +120,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -140,18 +135,8 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
-/* Receive an SKB from the frontend */
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
@@ -161,4 +146,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+int xen_netbk_tx_action(struct xen_netbk *netbk, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 4795c0f..1d9688a 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  64
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,38 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done;
+
+	work_done = xen_netbk_tx_action(vif->netbk, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do || work_done < 0)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +105,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -105,11 +119,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	return NETDEV_TX_OK;
 }
 
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
-{
-	netif_rx_ni(skb);
-}
-
 void xenvif_notify_tx_completion(struct xenvif *vif)
 {
 	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
@@ -124,16 +133,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +267,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +295,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -326,7 +333,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -337,7 +360,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -356,11 +385,15 @@ void xenvif_disconnect(struct xenvif *vif)
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3059684..8e4c9a9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -61,24 +61,15 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
 
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
@@ -93,42 +84,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -179,11 +142,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -368,8 +326,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
+			struct xen_netbk *rnetbk = to_netbk(idx);
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = rnetbk->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -527,11 +486,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -541,6 +507,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -641,25 +608,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -672,86 +633,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do be's rx,
+	 * which means fe's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -793,8 +685,6 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -894,8 +784,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info->vif = vif;
+
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -910,7 +799,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = NULL;
+	struct xenvif *vif = netbk->vif;
+
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -924,10 +814,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		idx = netbk->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
-		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -951,11 +839,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		/* Error on this fragment: respond to client with an error. */
 		idx = netbk->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
-		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1171,10 +1057,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1187,26 +1072,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
-		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
+		work_to_do = RING_HAS_UNCONSUMED_REQUESTS(&vif->tx);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1221,14 +1099,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1236,7 +1114,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1246,7 +1124,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1275,7 +1153,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1284,7 +1162,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1305,7 +1183,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		pending_tx_info->vif = vif;
+
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1329,12 +1207,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
 
 		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
 			break;
@@ -1343,14 +1220,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static int xen_netbk_tx_submit(struct xen_netbk *netbk,
+				struct gnttab_copy *tco,
+				int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
+	int work_done = 0;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 		int idx;
@@ -1361,7 +1242,6 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		idx = netbk->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
-		vif = pending_tx_info->vif;
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
@@ -1415,31 +1295,41 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
-		xenvif_receive_skb(vif, skb);
+		work_done++;
+
+		netif_receive_skb(skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 {
 	unsigned nr_gops;
 	int ret;
+	int work_done;
+
+	if (unlikely(!tx_work_todo(netbk)))
+		return 0;
 
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
-		return;
+		return 0;
+
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
+	work_done = xen_netbk_tx_submit(netbk, netbk->tx_copy_ops, budget);
 
+	return work_done;
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
@@ -1451,15 +1341,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	idx = netbk->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1516,37 +1402,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1592,78 +1454,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
+
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
+
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
+
+	return netbk;
+}
 
-		kthread_bind(netbk->task, group);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
 
-		atomic_set(&netbk->netfront_count, 0);
+		if (kthread_should_stop())
+			break;
 
-		wake_up_process(netbk->task);
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1672,14 +1530,7 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
 	xenvif_xenbus_exit();
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer_sync(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 }
 module_exit(netback_exit);
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszqo-0002Fy-NC; Thu, 02 Feb 2012 16:49:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqn-0002Eo-PZ
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:34 +0000
Received: from [85.158.138.51:63538] by server-1.bemta-3.messagelabs.com id
	8B/0A-23590-D9EBA2F4; Thu, 02 Feb 2012 16:49:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328201367!11758309!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22489 invoked from network); 2 Feb 2012 16:49:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157187"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:30 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPp008442;
	Thu, 2 Feb 2012 08:49:29 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:14 +0000
Message-ID: <1328201363-13915-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 04/13] netback: switch to NAPI + kthread
	model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

Changes in V4:

Remove unwanted notification generation during NAPI processing.

In original implementation, tx_build_gops tends to update req_event
pointer every time it sees tx error or finish one batch. Remove those
code to only update req_event pointer when we really want to shut down
NAPI.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   36 ++--
 drivers/net/xen-netback/interface.c |   95 ++++++---
 drivers/net/xen-netback/netback.c   |  381 +++++++++++------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 195 insertions(+), 318 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 372c7f5..1e4d462 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -61,14 +60,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -99,11 +101,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +120,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -140,18 +135,8 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
-/* Receive an SKB from the frontend */
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
@@ -161,4 +146,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+int xen_netbk_tx_action(struct xen_netbk *netbk, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 4795c0f..1d9688a 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  64
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,38 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done;
+
+	work_done = xen_netbk_tx_action(vif->netbk, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do || work_done < 0)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +105,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -105,11 +119,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	return NETDEV_TX_OK;
 }
 
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
-{
-	netif_rx_ni(skb);
-}
-
 void xenvif_notify_tx_completion(struct xenvif *vif)
 {
 	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
@@ -124,16 +133,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +267,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +295,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -326,7 +333,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -337,7 +360,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -356,11 +385,15 @@ void xenvif_disconnect(struct xenvif *vif)
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3059684..8e4c9a9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -61,24 +61,15 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
 
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
@@ -93,42 +84,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -179,11 +142,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -368,8 +326,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
+			struct xen_netbk *rnetbk = to_netbk(idx);
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = rnetbk->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -527,11 +486,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -541,6 +507,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -641,25 +608,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -672,86 +633,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do be's rx,
+	 * which means fe's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -793,8 +685,6 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -894,8 +784,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info->vif = vif;
+
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -910,7 +799,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = NULL;
+	struct xenvif *vif = netbk->vif;
+
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -924,10 +814,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		idx = netbk->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
-		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -951,11 +839,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		/* Error on this fragment: respond to client with an error. */
 		idx = netbk->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
-		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1171,10 +1057,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1187,26 +1072,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
-		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
+		work_to_do = RING_HAS_UNCONSUMED_REQUESTS(&vif->tx);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1221,14 +1099,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1236,7 +1114,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1246,7 +1124,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1275,7 +1153,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1284,7 +1162,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1305,7 +1183,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		pending_tx_info->vif = vif;
+
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1329,12 +1207,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
 
 		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
 			break;
@@ -1343,14 +1220,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static int xen_netbk_tx_submit(struct xen_netbk *netbk,
+				struct gnttab_copy *tco,
+				int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
+	int work_done = 0;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 		int idx;
@@ -1361,7 +1242,6 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		idx = netbk->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
-		vif = pending_tx_info->vif;
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
@@ -1415,31 +1295,41 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
-		xenvif_receive_skb(vif, skb);
+		work_done++;
+
+		netif_receive_skb(skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 {
 	unsigned nr_gops;
 	int ret;
+	int work_done;
+
+	if (unlikely(!tx_work_todo(netbk)))
+		return 0;
 
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
-		return;
+		return 0;
+
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
+	work_done = xen_netbk_tx_submit(netbk, netbk->tx_copy_ops, budget);
 
+	return work_done;
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
@@ -1451,15 +1341,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	idx = netbk->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1516,37 +1402,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1592,78 +1454,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
+
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
+
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
+
+	return netbk;
+}
 
-		kthread_bind(netbk->task, group);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
 
-		atomic_set(&netbk->netfront_count, 0);
+		if (kthread_should_stop())
+			break;
 
-		wake_up_process(netbk->task);
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1672,14 +1530,7 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
 	xenvif_xenbus_exit();
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer_sync(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 }
 module_exit(netback_exit);
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszql-0002Ep-SW; Thu, 02 Feb 2012 16:49:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqk-0002EW-7O
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:30 +0000
Received: from [85.158.138.51:61234] by server-6.bemta-3.messagelabs.com id
	C4/C0-01423-89EBA2F4; Thu, 02 Feb 2012 16:49:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27228 invoked from network); 2 Feb 2012 16:49:27 -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;
	2 Feb 2012 16:49:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555434"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:25 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPl008442;
	Thu, 2 Feb 2012 08:49:24 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:10 +0000
Message-ID: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4] Xen netback / netfront improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes in V4:
 - Squash several patches
 - Per-cpu scratch improvement, guard against race condition, NUMA
   awared allocation
 - Extend xenbus ring mapping interface to benifit all Xen BE / FE
 - Remove RX protocol stub patch

Changes in V3:
 - Rework of per-cpu scratch space
 - Multi page ring support
 - Split event channels
 - Rx protocol stub
 - Fix a minor bug in module_put path

Changes in V2:
 - Fix minor bugs in V1
 - Embed pending_tx_info into page pool
 - Per-cpu scratch space
 - Notification code path clean up

This version has been tested by 
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

V1:
A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall memory consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, the code path is cleaned up in a separated patch.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.

-----
 drivers/block/xen-blkback/xenbus.c    |    8 +-
 drivers/block/xen-blkfront.c          |    5 +-
 drivers/net/xen-netback/Makefile      |    2 +-
 drivers/net/xen-netback/common.h      |  107 +++--
 drivers/net/xen-netback/interface.c   |  230 ++++++--
 drivers/net/xen-netback/netback.c     |  999 +++++++++++++++------------------
 drivers/net/xen-netback/page_pool.c   |  185 ++++++
 drivers/net/xen-netback/page_pool.h   |   66 +++
 drivers/net/xen-netback/xenbus.c      |  178 ++++++-
 drivers/net/xen-netfront.c            |  393 ++++++++++----
 drivers/pci/xen-pcifront.c            |    5 +-
 drivers/scsi/xen-scsiback/common.h    |    3 +-
 drivers/scsi/xen-scsiback/interface.c |    6 +-
 drivers/scsi/xen-scsiback/xenbus.c    |    4 +-
 drivers/scsi/xen-scsifront/xenbus.c   |    5 +-
 drivers/xen/xen-pciback/xenbus.c      |   11 +-
 drivers/xen/xenbus/xenbus_client.c    |  282 +++++++---
 include/xen/xenbus.h                  |   15 +-
 18 files changed, 1646 insertions(+), 858 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszql-0002Ep-SW; Thu, 02 Feb 2012 16:49:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqk-0002EW-7O
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:30 +0000
Received: from [85.158.138.51:61234] by server-6.bemta-3.messagelabs.com id
	C4/C0-01423-89EBA2F4; Thu, 02 Feb 2012 16:49:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27228 invoked from network); 2 Feb 2012 16:49:27 -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;
	2 Feb 2012 16:49:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555434"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:25 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPl008442;
	Thu, 2 Feb 2012 08:49:24 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:10 +0000
Message-ID: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4] Xen netback / netfront improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes in V4:
 - Squash several patches
 - Per-cpu scratch improvement, guard against race condition, NUMA
   awared allocation
 - Extend xenbus ring mapping interface to benifit all Xen BE / FE
 - Remove RX protocol stub patch

Changes in V3:
 - Rework of per-cpu scratch space
 - Multi page ring support
 - Split event channels
 - Rx protocol stub
 - Fix a minor bug in module_put path

Changes in V2:
 - Fix minor bugs in V1
 - Embed pending_tx_info into page pool
 - Per-cpu scratch space
 - Notification code path clean up

This version has been tested by 
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

V1:
A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall memory consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, the code path is cleaned up in a separated patch.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.

-----
 drivers/block/xen-blkback/xenbus.c    |    8 +-
 drivers/block/xen-blkfront.c          |    5 +-
 drivers/net/xen-netback/Makefile      |    2 +-
 drivers/net/xen-netback/common.h      |  107 +++--
 drivers/net/xen-netback/interface.c   |  230 ++++++--
 drivers/net/xen-netback/netback.c     |  999 +++++++++++++++------------------
 drivers/net/xen-netback/page_pool.c   |  185 ++++++
 drivers/net/xen-netback/page_pool.h   |   66 +++
 drivers/net/xen-netback/xenbus.c      |  178 ++++++-
 drivers/net/xen-netfront.c            |  393 ++++++++++----
 drivers/pci/xen-pcifront.c            |    5 +-
 drivers/scsi/xen-scsiback/common.h    |    3 +-
 drivers/scsi/xen-scsiback/interface.c |    6 +-
 drivers/scsi/xen-scsiback/xenbus.c    |    4 +-
 drivers/scsi/xen-scsifront/xenbus.c   |    5 +-
 drivers/xen/xen-pciback/xenbus.c      |   11 +-
 drivers/xen/xenbus/xenbus_client.c    |  282 +++++++---
 include/xen/xenbus.h                  |   15 +-
 18 files changed, 1646 insertions(+), 858 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszqo-0002Fi-9N; Thu, 02 Feb 2012 16:49:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszql-0002Eo-Up
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:32 +0000
Received: from [85.158.138.51:20839] by server-1.bemta-3.messagelabs.com id
	33/F9-23590-B9EBA2F4; Thu, 02 Feb 2012 16:49:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328201367!11758309!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22374 invoked from network); 2 Feb 2012 16:49:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157182"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:29 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPo008442;
	Thu, 2 Feb 2012 08:49:28 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:13 +0000
Message-ID: <1328201363-13915-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 03/13] netback: add module get/put
	operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems -- guest's network interface just mysteriously stops
working.

disconnect function may get called by the generic framework even
before vif connects.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..4795c0f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -312,6 +312,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -339,12 +341,15 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
+	module_put(THIS_MODULE);
 	return err;
 }
 
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+	int need_module_put = 0;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
@@ -359,12 +364,17 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq)
+	if (vif->irq) {
 		unbind_from_irqhandler(vif->irq, vif);
+		need_module_put = 1;
+	}
 
 	unregister_netdev(vif->dev);
 
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	if (need_module_put)
+		module_put(THIS_MODULE);
 }
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16: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.xensource.com>)
	id 1Rszqo-0002Fi-9N; Thu, 02 Feb 2012 16:49:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszql-0002Eo-Up
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:32 +0000
Received: from [85.158.138.51:20839] by server-1.bemta-3.messagelabs.com id
	33/F9-23590-B9EBA2F4; Thu, 02 Feb 2012 16:49:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328201367!11758309!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22374 invoked from network); 2 Feb 2012 16:49:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157182"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:29 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPo008442;
	Thu, 2 Feb 2012 08:49:28 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:13 +0000
Message-ID: <1328201363-13915-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 03/13] netback: add module get/put
	operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems -- guest's network interface just mysteriously stops
working.

disconnect function may get called by the generic framework even
before vif connects.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..4795c0f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -312,6 +312,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -339,12 +341,15 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
+	module_put(THIS_MODULE);
 	return err;
 }
 
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+	int need_module_put = 0;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
@@ -359,12 +364,17 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq)
+	if (vif->irq) {
 		unbind_from_irqhandler(vif->irq, vif);
+		need_module_put = 1;
+	}
 
 	unregister_netdev(vif->dev);
 
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	if (need_module_put)
+		module_put(THIS_MODULE);
 }
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqr-0002HI-FT; Thu, 02 Feb 2012 16:49:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqp-0002Fr-78
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:35 +0000
Received: from [85.158.138.51:63582] by server-4.bemta-3.messagelabs.com id
	C6/48-07654-E9EBA2F4; Thu, 02 Feb 2012 16:49:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27460 invoked from network); 2 Feb 2012 16:49:32 -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;
	2 Feb 2012 16:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555466"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:32 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPq008442;
	Thu, 2 Feb 2012 08:49:30 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:15 +0000
Message-ID: <1328201363-13915-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 05/13] netback: switch to per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, given that there are maximum nr_online_cpus netbacks
running, we can use per-cpu scratch space, thus shrinking size of
struct xen_netbk.

Changes in V4:

Carefully guard against CPU hotplug race condition. NAPI and kthread
will bail when scratch spaces are not available.

Scratch space allocation is NUMA awared.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |   15 ++
 drivers/net/xen-netback/netback.c |  261 ++++++++++++++++++++++++++++++-------
 2 files changed, 229 insertions(+), 47 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 1e4d462..65df480 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,21 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#define DRV_NAME "netback: "
+
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 };
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 8e4c9a9..5584853 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1,3 +1,4 @@
+
 /*
  * Back-end of the driver for virtual network devices. This portion of the
  * driver exports a 'unified' network-device interface that can be accessed
@@ -38,6 +39,7 @@
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
 #include <linux/udp.h>
+#include <linux/cpu.h>
 
 #include <net/tcp.h>
 
@@ -47,18 +49,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
 
-#define MAX_PENDING_REQS 256
+DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
+/*
+ * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+ * head/fragment page uses 2 copy operations because it
+ * straddles two buffers in the frontend.
+ */
+DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
+DEFINE_PER_CPU(struct netbk_rx_meta *, meta);
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
 	struct sk_buff_head rx_queue;
@@ -71,17 +72,7 @@ struct xen_netbk {
 
 	struct xenvif *vif;
 
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
 	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
@@ -508,12 +499,29 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
+	static int unusable_count;
+
+	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
+	struct netbk_rx_meta *m = get_cpu_var(meta);
 
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = gco,
+		.meta  = m,
 	};
 
+	if (gco == NULL || m == NULL) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		if (unusable_count == 1000) {
+			pr_alert("CPU %x scratch space is not usable,"
+				 " not doing any TX work for vif%u.%u\n",
+				 smp_processor_id(),
+				 netbk->vif->domid, netbk->vif->handle);
+			unusable_count = 0;
+		}
+		return;
+	}
+
 	skb_queue_head_init(&rxq);
 
 	count = 0;
@@ -534,13 +542,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
-	if (!npo.copy_prod)
+	if (!npo.copy_prod) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
 		return;
+	}
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
@@ -549,14 +560,14 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 		vif = netdev_priv(skb->dev);
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -581,12 +592,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					m[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -594,7 +605,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -604,7 +615,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 m + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -622,6 +633,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
+
+	put_cpu_var(grant_copy_op);
+	put_cpu_var(meta);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1052,9 +1066,10 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+					struct gnttab_copy *tco)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
 	struct xenvif *vif = netbk->vif;
@@ -1213,18 +1228,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		vif->tx.req_cons = idx;
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - tco;
 }
 
 static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 				struct gnttab_copy *tco,
 				int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
 	struct xenvif *vif = netbk->vif;
 	int work_done = 0;
@@ -1309,20 +1324,42 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 	unsigned nr_gops;
 	int ret;
 	int work_done;
+	struct gnttab_copy *tco;
+	static int unusable_count;
 
 	if (unlikely(!tx_work_todo(netbk)))
 		return 0;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	tco = get_cpu_var(tx_copy_ops);
+
+	if (tco == NULL) {
+		put_cpu_var(tx_copy_ops);
+		unusable_count++;
+		if (unusable_count == 1000) {
+			pr_alert("CPU %x scratch space"
+				 " is not usable,"
+				 " not doing any RX work for vif%u.%u\n",
+				 smp_processor_id(),
+				 netbk->vif->domid, netbk->vif->handle);
+			unusable_count = 0;
+		}
+		return -ENOMEM;
+	}
+
+	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
 
-	if (nr_gops == 0)
+	if (nr_gops == 0) {
+		put_cpu_var(tx_copy_ops);
 		return 0;
+	}
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+					tco, nr_gops);
 	BUG_ON(ret);
 
-	work_done = xen_netbk_tx_submit(netbk, netbk->tx_copy_ops, budget);
+	work_done = xen_netbk_tx_submit(netbk, tco, budget);
+
+	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
@@ -1461,7 +1498,7 @@ struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 
 	netbk = vzalloc(sizeof(struct xen_netbk));
 	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
+		pr_alert(DRV_NAME "%s: out of memory\n", __func__);
 		return NULL;
 	}
 
@@ -1507,31 +1544,161 @@ int xen_netbk_kthread(void *data)
 	return 0;
 }
 
+static int __create_percpu_scratch_space(unsigned int cpu)
+{
+	/* Guard against race condition */
+	if (per_cpu(tx_copy_ops, cpu) ||
+	    per_cpu(grant_copy_op, cpu) ||
+	    per_cpu(meta, cpu))
+		return 0;
+
+	per_cpu(tx_copy_ops, cpu) =
+		vzalloc_node(sizeof(struct gnttab_copy) * MAX_PENDING_REQS,
+			     cpu_to_node(cpu));
+
+	if (!per_cpu(tx_copy_ops, cpu))
+		per_cpu(tx_copy_ops, cpu) = vzalloc(sizeof(struct gnttab_copy)
+						    * MAX_PENDING_REQS);
+
+	per_cpu(grant_copy_op, cpu) =
+		vzalloc_node(sizeof(struct gnttab_copy)
+			     * 2 * XEN_NETIF_RX_RING_SIZE, cpu_to_node(cpu));
+
+	if (!per_cpu(grant_copy_op, cpu))
+		per_cpu(grant_copy_op, cpu) =
+			vzalloc(sizeof(struct gnttab_copy)
+				* 2 * XEN_NETIF_RX_RING_SIZE);
+
+
+	per_cpu(meta, cpu) = vzalloc_node(sizeof(struct xenvif_rx_meta)
+					  * 2 * XEN_NETIF_RX_RING_SIZE,
+					  cpu_to_node(cpu));
+	if (!per_cpu(meta, cpu))
+		per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
+					     * 2 * XEN_NETIF_RX_RING_SIZE);
+
+	if (!per_cpu(tx_copy_ops, cpu) ||
+	    !per_cpu(grant_copy_op, cpu) ||
+	    !per_cpu(meta, cpu))
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void __free_percpu_scratch_space(unsigned int cpu)
+{
+	/* freeing NULL pointer is legit */
+	/* carefully work around race condition */
+	void *tmp;
+	tmp = per_cpu(tx_copy_ops, cpu);
+	per_cpu(tx_copy_ops, cpu) = NULL;
+	vfree(tmp);
+
+	tmp = per_cpu(grant_copy_op, cpu);
+	per_cpu(grant_copy_op, cpu) = NULL;
+	vfree(tmp);
+
+	tmp = per_cpu(meta, cpu);
+	per_cpu(meta, cpu) = NULL;
+	vfree(tmp);
+}
+
+static int __netback_percpu_callback(struct notifier_block *nfb,
+				     unsigned long action, void *hcpu)
+{
+	unsigned int cpu = (unsigned long)hcpu;
+	int rc = NOTIFY_DONE;
+
+	switch (action) {
+	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
+		pr_info("CPU %x online, creating scratch space\n", cpu);
+		rc = __create_percpu_scratch_space(cpu);
+		if (rc) {
+			pr_alert("failed to create scratch space"
+				 " for CPU %x\n", cpu);
+			/* FIXME: nothing more we can do here, we will
+			 * print out warning message when thread or
+			 * NAPI runs on this cpu. Also stop getting
+			 * called in the future.
+			 */
+			__free_percpu_scratch_space(cpu);
+			rc = NOTIFY_BAD;
+		} else {
+			rc = NOTIFY_OK;
+		}
+		break;
+	case CPU_DEAD:
+	case CPU_DEAD_FROZEN:
+		pr_info("CPU %x offline, destroying scratch space\n",
+			cpu);
+		__free_percpu_scratch_space(cpu);
+		rc = NOTIFY_OK;
+		break;
+	default:
+		break;
+	}
+
+	return rc;
+}
+
+static struct notifier_block netback_notifier_block = {
+	.notifier_call = __netback_percpu_callback,
+};
 
 static int __init netback_init(void)
 {
-	int rc = 0;
+	int rc = -ENOMEM;
+	int cpu;
 
 	if (!xen_domain())
 		return -ENODEV;
 
+	/* Don't need to disable preempt here, since nobody else will
+	 * touch these percpu areas during start up. */
+	for_each_online_cpu(cpu) {
+		rc = __create_percpu_scratch_space(cpu);
+
+		if (rc)
+			goto failed_init;
+	}
+
+	register_hotcpu_notifier(&netback_notifier_block);
+
 	rc = page_pool_init();
 	if (rc)
-		goto failed_init;
+		goto failed_init_pool;
 
-	return xenvif_xenbus_init();
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto failed_init_xenbus;
 
-failed_init:
 	return rc;
 
+failed_init_xenbus:
+	page_pool_destroy();
+failed_init_pool:
+	unregister_hotcpu_notifier(&netback_notifier_block);
+failed_init:
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
+	return rc;
 }
 
 module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
+	int cpu;
+
 	xenvif_xenbus_exit();
 	page_pool_destroy();
+
+	unregister_hotcpu_notifier(&netback_notifier_block);
+
+	/* Since we're here, nobody else will touch per-cpu area. */
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqr-0002HI-FT; Thu, 02 Feb 2012 16:49:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqp-0002Fr-78
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:35 +0000
Received: from [85.158.138.51:63582] by server-4.bemta-3.messagelabs.com id
	C6/48-07654-E9EBA2F4; Thu, 02 Feb 2012 16:49:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27460 invoked from network); 2 Feb 2012 16:49:32 -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;
	2 Feb 2012 16:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555466"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:32 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPq008442;
	Thu, 2 Feb 2012 08:49:30 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:15 +0000
Message-ID: <1328201363-13915-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 05/13] netback: switch to per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, given that there are maximum nr_online_cpus netbacks
running, we can use per-cpu scratch space, thus shrinking size of
struct xen_netbk.

Changes in V4:

Carefully guard against CPU hotplug race condition. NAPI and kthread
will bail when scratch spaces are not available.

Scratch space allocation is NUMA awared.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |   15 ++
 drivers/net/xen-netback/netback.c |  261 ++++++++++++++++++++++++++++++-------
 2 files changed, 229 insertions(+), 47 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 1e4d462..65df480 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,21 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#define DRV_NAME "netback: "
+
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 };
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 8e4c9a9..5584853 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1,3 +1,4 @@
+
 /*
  * Back-end of the driver for virtual network devices. This portion of the
  * driver exports a 'unified' network-device interface that can be accessed
@@ -38,6 +39,7 @@
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
 #include <linux/udp.h>
+#include <linux/cpu.h>
 
 #include <net/tcp.h>
 
@@ -47,18 +49,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
 
-#define MAX_PENDING_REQS 256
+DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
+/*
+ * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+ * head/fragment page uses 2 copy operations because it
+ * straddles two buffers in the frontend.
+ */
+DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
+DEFINE_PER_CPU(struct netbk_rx_meta *, meta);
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
 	struct sk_buff_head rx_queue;
@@ -71,17 +72,7 @@ struct xen_netbk {
 
 	struct xenvif *vif;
 
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
 	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
@@ -508,12 +499,29 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
+	static int unusable_count;
+
+	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
+	struct netbk_rx_meta *m = get_cpu_var(meta);
 
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = gco,
+		.meta  = m,
 	};
 
+	if (gco == NULL || m == NULL) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		if (unusable_count == 1000) {
+			pr_alert("CPU %x scratch space is not usable,"
+				 " not doing any TX work for vif%u.%u\n",
+				 smp_processor_id(),
+				 netbk->vif->domid, netbk->vif->handle);
+			unusable_count = 0;
+		}
+		return;
+	}
+
 	skb_queue_head_init(&rxq);
 
 	count = 0;
@@ -534,13 +542,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
-	if (!npo.copy_prod)
+	if (!npo.copy_prod) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
 		return;
+	}
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
@@ -549,14 +560,14 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 		vif = netdev_priv(skb->dev);
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -581,12 +592,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					m[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -594,7 +605,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -604,7 +615,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 m + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -622,6 +633,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
+
+	put_cpu_var(grant_copy_op);
+	put_cpu_var(meta);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1052,9 +1066,10 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+					struct gnttab_copy *tco)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
 	struct xenvif *vif = netbk->vif;
@@ -1213,18 +1228,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		vif->tx.req_cons = idx;
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - tco;
 }
 
 static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 				struct gnttab_copy *tco,
 				int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
 	struct xenvif *vif = netbk->vif;
 	int work_done = 0;
@@ -1309,20 +1324,42 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 	unsigned nr_gops;
 	int ret;
 	int work_done;
+	struct gnttab_copy *tco;
+	static int unusable_count;
 
 	if (unlikely(!tx_work_todo(netbk)))
 		return 0;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	tco = get_cpu_var(tx_copy_ops);
+
+	if (tco == NULL) {
+		put_cpu_var(tx_copy_ops);
+		unusable_count++;
+		if (unusable_count == 1000) {
+			pr_alert("CPU %x scratch space"
+				 " is not usable,"
+				 " not doing any RX work for vif%u.%u\n",
+				 smp_processor_id(),
+				 netbk->vif->domid, netbk->vif->handle);
+			unusable_count = 0;
+		}
+		return -ENOMEM;
+	}
+
+	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
 
-	if (nr_gops == 0)
+	if (nr_gops == 0) {
+		put_cpu_var(tx_copy_ops);
 		return 0;
+	}
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+					tco, nr_gops);
 	BUG_ON(ret);
 
-	work_done = xen_netbk_tx_submit(netbk, netbk->tx_copy_ops, budget);
+	work_done = xen_netbk_tx_submit(netbk, tco, budget);
+
+	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
@@ -1461,7 +1498,7 @@ struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 
 	netbk = vzalloc(sizeof(struct xen_netbk));
 	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
+		pr_alert(DRV_NAME "%s: out of memory\n", __func__);
 		return NULL;
 	}
 
@@ -1507,31 +1544,161 @@ int xen_netbk_kthread(void *data)
 	return 0;
 }
 
+static int __create_percpu_scratch_space(unsigned int cpu)
+{
+	/* Guard against race condition */
+	if (per_cpu(tx_copy_ops, cpu) ||
+	    per_cpu(grant_copy_op, cpu) ||
+	    per_cpu(meta, cpu))
+		return 0;
+
+	per_cpu(tx_copy_ops, cpu) =
+		vzalloc_node(sizeof(struct gnttab_copy) * MAX_PENDING_REQS,
+			     cpu_to_node(cpu));
+
+	if (!per_cpu(tx_copy_ops, cpu))
+		per_cpu(tx_copy_ops, cpu) = vzalloc(sizeof(struct gnttab_copy)
+						    * MAX_PENDING_REQS);
+
+	per_cpu(grant_copy_op, cpu) =
+		vzalloc_node(sizeof(struct gnttab_copy)
+			     * 2 * XEN_NETIF_RX_RING_SIZE, cpu_to_node(cpu));
+
+	if (!per_cpu(grant_copy_op, cpu))
+		per_cpu(grant_copy_op, cpu) =
+			vzalloc(sizeof(struct gnttab_copy)
+				* 2 * XEN_NETIF_RX_RING_SIZE);
+
+
+	per_cpu(meta, cpu) = vzalloc_node(sizeof(struct xenvif_rx_meta)
+					  * 2 * XEN_NETIF_RX_RING_SIZE,
+					  cpu_to_node(cpu));
+	if (!per_cpu(meta, cpu))
+		per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
+					     * 2 * XEN_NETIF_RX_RING_SIZE);
+
+	if (!per_cpu(tx_copy_ops, cpu) ||
+	    !per_cpu(grant_copy_op, cpu) ||
+	    !per_cpu(meta, cpu))
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void __free_percpu_scratch_space(unsigned int cpu)
+{
+	/* freeing NULL pointer is legit */
+	/* carefully work around race condition */
+	void *tmp;
+	tmp = per_cpu(tx_copy_ops, cpu);
+	per_cpu(tx_copy_ops, cpu) = NULL;
+	vfree(tmp);
+
+	tmp = per_cpu(grant_copy_op, cpu);
+	per_cpu(grant_copy_op, cpu) = NULL;
+	vfree(tmp);
+
+	tmp = per_cpu(meta, cpu);
+	per_cpu(meta, cpu) = NULL;
+	vfree(tmp);
+}
+
+static int __netback_percpu_callback(struct notifier_block *nfb,
+				     unsigned long action, void *hcpu)
+{
+	unsigned int cpu = (unsigned long)hcpu;
+	int rc = NOTIFY_DONE;
+
+	switch (action) {
+	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
+		pr_info("CPU %x online, creating scratch space\n", cpu);
+		rc = __create_percpu_scratch_space(cpu);
+		if (rc) {
+			pr_alert("failed to create scratch space"
+				 " for CPU %x\n", cpu);
+			/* FIXME: nothing more we can do here, we will
+			 * print out warning message when thread or
+			 * NAPI runs on this cpu. Also stop getting
+			 * called in the future.
+			 */
+			__free_percpu_scratch_space(cpu);
+			rc = NOTIFY_BAD;
+		} else {
+			rc = NOTIFY_OK;
+		}
+		break;
+	case CPU_DEAD:
+	case CPU_DEAD_FROZEN:
+		pr_info("CPU %x offline, destroying scratch space\n",
+			cpu);
+		__free_percpu_scratch_space(cpu);
+		rc = NOTIFY_OK;
+		break;
+	default:
+		break;
+	}
+
+	return rc;
+}
+
+static struct notifier_block netback_notifier_block = {
+	.notifier_call = __netback_percpu_callback,
+};
 
 static int __init netback_init(void)
 {
-	int rc = 0;
+	int rc = -ENOMEM;
+	int cpu;
 
 	if (!xen_domain())
 		return -ENODEV;
 
+	/* Don't need to disable preempt here, since nobody else will
+	 * touch these percpu areas during start up. */
+	for_each_online_cpu(cpu) {
+		rc = __create_percpu_scratch_space(cpu);
+
+		if (rc)
+			goto failed_init;
+	}
+
+	register_hotcpu_notifier(&netback_notifier_block);
+
 	rc = page_pool_init();
 	if (rc)
-		goto failed_init;
+		goto failed_init_pool;
 
-	return xenvif_xenbus_init();
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto failed_init_xenbus;
 
-failed_init:
 	return rc;
 
+failed_init_xenbus:
+	page_pool_destroy();
+failed_init_pool:
+	unregister_hotcpu_notifier(&netback_notifier_block);
+failed_init:
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
+	return rc;
 }
 
 module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
+	int cpu;
+
 	xenvif_xenbus_exit();
 	page_pool_destroy();
+
+	unregister_hotcpu_notifier(&netback_notifier_block);
+
+	/* Since we're here, nobody else will touch per-cpu area. */
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqt-0002JK-Tz; Thu, 02 Feb 2012 16:49:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqr-0002Eo-Ms
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:38 +0000
Received: from [85.158.138.51:63782] by server-1.bemta-3.messagelabs.com id
	2F/2A-23590-1AEBA2F4; Thu, 02 Feb 2012 16:49:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27544 invoked from network); 2 Feb 2012 16:49:35 -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;
	2 Feb 2012 16:49:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555480"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:34 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPs008442;
	Thu, 2 Feb 2012 08:49:33 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:17 +0000
Message-ID: <1328201363-13915-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 07/13] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   26 ++--
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  210 +++++++++++++++++-----------------
 3 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index ea91bb6..b7d4442 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -48,7 +48,7 @@
 #define DRV_NAME "netback: "
 #include "page_pool.h"
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -141,30 +141,30 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-int xen_netbk_tx_action(struct xenvif *vif, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 9b7d596..b2bde8f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -69,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done;
 
-	work_done = xen_netbk_tx_action(vif, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -102,12 +102,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -133,7 +133,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -330,7 +330,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -343,7 +343,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -367,7 +367,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -400,7 +400,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index ef9cfbe..384f4e5 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -58,9 +58,9 @@ DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
  * straddles two buffers in the frontend.
  */
 DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
-DEFINE_PER_CPU(struct netbk_rx_meta *, meta);
+DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -128,7 +128,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -137,16 +137,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -192,9 +192,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -233,15 +233,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -261,13 +261,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -346,14 +346,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -390,30 +390,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -432,9 +432,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -462,12 +462,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -484,7 +484,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 	static int unusable_count;
 
 	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
-	struct netbk_rx_meta *m = get_cpu_var(meta);
+	struct xenvif_rx_meta *m = get_cpu_var(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -513,7 +513,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -558,7 +558,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -594,9 +594,9 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
-					 m + npo.meta_cons + 1,
-					 sco->meta_slots_used);
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
 		if (ret)
@@ -612,20 +612,20 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 
 	put_cpu_var(grant_copy_op);
 	put_cpu_var(meta);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -662,11 +662,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -679,7 +679,7 @@ static void netbk_tx_err(struct xenvif *vif,
 	vif->tx.req_cons = cons;
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -720,9 +720,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -733,10 +733,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -754,7 +754,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -782,9 +782,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -821,7 +821,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -838,10 +838,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -852,7 +852,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -878,15 +878,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -914,9 +914,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -1041,8 +1041,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
-					struct gnttab_copy *tco)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif,
+				     struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
@@ -1083,18 +1083,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1102,7 +1102,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1112,7 +1112,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1128,7 +1128,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1139,18 +1139,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1191,11 +1191,11 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
@@ -1209,9 +1209,9 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 	return gop - tco;
 }
 
-static int xen_netbk_tx_submit(struct xenvif *vif,
-			       struct gnttab_copy *tco,
-			       int budget)
+static int xenvif_tx_submit(struct xenvif *vif,
+			    struct gnttab_copy *tco,
+			    int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
@@ -1233,7 +1233,7 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1250,7 +1250,7 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1258,7 +1258,7 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1292,7 +1292,8 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 }
 
 /* Called after netfront has transmitted */
-int xen_netbk_tx_action(struct xenvif *vif, int budget)
+
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
@@ -1319,7 +1320,7 @@ int xen_netbk_tx_action(struct xenvif *vif, int budget)
 		return -ENOMEM;
 	}
 
-	nr_gops = xen_netbk_tx_build_gops(vif, tco);
+	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_var(tx_copy_ops);
@@ -1330,14 +1331,14 @@ int xen_netbk_tx_action(struct xenvif *vif, int budget)
 					tco, nr_gops);
 	BUG_ON(ret);
 
-	work_done = xen_netbk_tx_submit(vif, tco, budget);
+	work_done = xenvif_tx_submit(vif, tco, budget);
 
 	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1418,7 +1419,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1428,9 +1429,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1459,11 +1460,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1477,7 +1478,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	return 0;
@@ -1508,7 +1509,6 @@ static int __create_percpu_scratch_space(unsigned int cpu)
 			vzalloc(sizeof(struct gnttab_copy)
 				* 2 * XEN_NETIF_RX_RING_SIZE);
 
-
 	per_cpu(meta, cpu) = vzalloc_node(sizeof(struct xenvif_rx_meta)
 					  * 2 * XEN_NETIF_RX_RING_SIZE,
 					  cpu_to_node(cpu));
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqt-0002JK-Tz; Thu, 02 Feb 2012 16:49:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqr-0002Eo-Ms
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:38 +0000
Received: from [85.158.138.51:63782] by server-1.bemta-3.messagelabs.com id
	2F/2A-23590-1AEBA2F4; Thu, 02 Feb 2012 16:49:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27544 invoked from network); 2 Feb 2012 16:49:35 -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;
	2 Feb 2012 16:49:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555480"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:34 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPs008442;
	Thu, 2 Feb 2012 08:49:33 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:17 +0000
Message-ID: <1328201363-13915-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 07/13] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   26 ++--
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  210 +++++++++++++++++-----------------
 3 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index ea91bb6..b7d4442 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -48,7 +48,7 @@
 #define DRV_NAME "netback: "
 #include "page_pool.h"
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -141,30 +141,30 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-int xen_netbk_tx_action(struct xenvif *vif, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 9b7d596..b2bde8f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -69,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done;
 
-	work_done = xen_netbk_tx_action(vif, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -102,12 +102,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -133,7 +133,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -330,7 +330,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -343,7 +343,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -367,7 +367,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -400,7 +400,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index ef9cfbe..384f4e5 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -58,9 +58,9 @@ DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
  * straddles two buffers in the frontend.
  */
 DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
-DEFINE_PER_CPU(struct netbk_rx_meta *, meta);
+DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -128,7 +128,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -137,16 +137,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -192,9 +192,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -233,15 +233,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -261,13 +261,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -346,14 +346,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -390,30 +390,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -432,9 +432,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -462,12 +462,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -484,7 +484,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 	static int unusable_count;
 
 	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
-	struct netbk_rx_meta *m = get_cpu_var(meta);
+	struct xenvif_rx_meta *m = get_cpu_var(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -513,7 +513,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -558,7 +558,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -594,9 +594,9 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
-					 m + npo.meta_cons + 1,
-					 sco->meta_slots_used);
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
 		if (ret)
@@ -612,20 +612,20 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 
 	put_cpu_var(grant_copy_op);
 	put_cpu_var(meta);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -662,11 +662,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -679,7 +679,7 @@ static void netbk_tx_err(struct xenvif *vif,
 	vif->tx.req_cons = cons;
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -720,9 +720,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -733,10 +733,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -754,7 +754,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -782,9 +782,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -821,7 +821,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -838,10 +838,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -852,7 +852,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -878,15 +878,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -914,9 +914,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -1041,8 +1041,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
-					struct gnttab_copy *tco)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif,
+				     struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
@@ -1083,18 +1083,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1102,7 +1102,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1112,7 +1112,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1128,7 +1128,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1139,18 +1139,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1191,11 +1191,11 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
@@ -1209,9 +1209,9 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 	return gop - tco;
 }
 
-static int xen_netbk_tx_submit(struct xenvif *vif,
-			       struct gnttab_copy *tco,
-			       int budget)
+static int xenvif_tx_submit(struct xenvif *vif,
+			    struct gnttab_copy *tco,
+			    int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
@@ -1233,7 +1233,7 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1250,7 +1250,7 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1258,7 +1258,7 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1292,7 +1292,8 @@ static int xen_netbk_tx_submit(struct xenvif *vif,
 }
 
 /* Called after netfront has transmitted */
-int xen_netbk_tx_action(struct xenvif *vif, int budget)
+
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
@@ -1319,7 +1320,7 @@ int xen_netbk_tx_action(struct xenvif *vif, int budget)
 		return -ENOMEM;
 	}
 
-	nr_gops = xen_netbk_tx_build_gops(vif, tco);
+	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_var(tx_copy_ops);
@@ -1330,14 +1331,14 @@ int xen_netbk_tx_action(struct xenvif *vif, int budget)
 					tco, nr_gops);
 	BUG_ON(ret);
 
-	work_done = xen_netbk_tx_submit(vif, tco, budget);
+	work_done = xenvif_tx_submit(vif, tco, budget);
 
 	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1418,7 +1419,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1428,9 +1429,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1459,11 +1460,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1477,7 +1478,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	return 0;
@@ -1508,7 +1509,6 @@ static int __create_percpu_scratch_space(unsigned int cpu)
 			vzalloc(sizeof(struct gnttab_copy)
 				* 2 * XEN_NETIF_RX_RING_SIZE);
 
-
 	per_cpu(meta, cpu) = vzalloc_node(sizeof(struct xenvif_rx_meta)
 					  * 2 * XEN_NETIF_RX_RING_SIZE,
 					  cpu_to_node(cpu));
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqv-0002Lb-Jz; Thu, 02 Feb 2012 16:49:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqu-0002Iy-9J
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:40 +0000
Received: from [85.158.138.51:21281] by server-5.bemta-3.messagelabs.com id
	C1/D1-25695-3AEBA2F4; Thu, 02 Feb 2012 16:49:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27647 invoked from network); 2 Feb 2012 16:49:38 -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;
	2 Feb 2012 16:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555492"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:37 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPu008442;
	Thu, 2 Feb 2012 08:49:35 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:19 +0000
Message-ID: <1328201363-13915-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 09/13] Bundle fix for xen backends and
	frontends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/block/xen-blkback/xenbus.c    |    8 +++++---
 drivers/block/xen-blkfront.c          |    5 +++--
 drivers/net/xen-netback/netback.c     |    4 ++--
 drivers/net/xen-netfront.c            |    9 +++++----
 drivers/pci/xen-pcifront.c            |    5 +++--
 drivers/scsi/xen-scsiback/common.h    |    3 ++-
 drivers/scsi/xen-scsiback/interface.c |    6 ++++--
 drivers/scsi/xen-scsiback/xenbus.c    |    4 ++--
 drivers/scsi/xen-scsifront/xenbus.c   |    5 +++--
 drivers/xen/xen-pciback/xenbus.c      |   11 ++++++-----
 10 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 9e9c8a1..ef7e88b 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -122,7 +122,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	return blkif;
 }
 
-static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
+static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page[],
+			 int nr_pages,
 			 unsigned int evtchn)
 {
 	int err;
@@ -131,7 +132,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
 	if (blkif->irq)
 		return 0;
 
-	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring);
+	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page,
+				     nr_pages, &blkif->blk_ring);
 	if (err < 0)
 		return err;
 
@@ -779,7 +781,7 @@ static int connect_ring(struct backend_info *be)
 		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
 
 	/* Map the shared frame, irq etc. */
-	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
+	err = xen_blkif_map(be->blkif, &ring_ref, 1, evtchn);
 	if (err) {
 		xenbus_dev_fatal(dev, err, "mapping ring-ref %lu port %u",
 				 ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..2c6443a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -827,6 +827,7 @@ static int setup_blkring(struct xenbus_device *dev,
 {
 	struct blkif_sring *sring;
 	int err;
+	int grefs[1];
 
 	info->ring_ref = GRANT_INVALID_REF;
 
@@ -840,13 +841,13 @@ static int setup_blkring(struct xenbus_device *dev,
 
 	sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(info->ring.sring));
+	err = xenbus_grant_ring(dev, info->ring.sring, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)sring);
 		info->ring.sring = NULL;
 		goto fail;
 	}
-	info->ring_ref = err;
+	info->ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 384f4e5..cb1a661 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1440,7 +1440,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
 	int err = -ENOMEM;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     tx_ring_ref, &addr);
+				     &tx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
@@ -1448,7 +1448,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
 	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     rx_ring_ref, &addr);
+				     &rx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 01f589d..b7ff815 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1482,6 +1482,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	int grefs[1];
 	struct net_device *netdev = info->netdev;
 
 	info->tx_ring_ref = GRANT_INVALID_REF;
@@ -1505,13 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(txs);
 	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	err = xenbus_grant_ring(dev, txs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)txs);
 		goto fail;
 	}
 
-	info->tx_ring_ref = err;
+	info->tx_ring_ref = grefs[0];
 	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
@@ -1521,12 +1522,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(rxs);
 	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
+	err = xenbus_grant_ring(dev, rxs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)rxs);
 		goto fail;
 	}
-	info->rx_ring_ref = err;
+	info->rx_ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 7cf3d2f..394c926 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -767,12 +767,13 @@ static int pcifront_publish_info(struct pcifront_device *pdev)
 {
 	int err = 0;
 	struct xenbus_transaction trans;
+	int grefs[1];
 
-	err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
+	err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, grefs);
 	if (err < 0)
 		goto out;
 
-	pdev->gnt_ref = err;
+	pdev->gnt_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
 	if (err)
diff --git a/drivers/scsi/xen-scsiback/common.h b/drivers/scsi/xen-scsiback/common.h
index dafa79e..4d13617 100644
--- a/drivers/scsi/xen-scsiback/common.h
+++ b/drivers/scsi/xen-scsiback/common.h
@@ -150,7 +150,8 @@ typedef struct {
 
 irqreturn_t scsiback_intr(int, void *);
 int scsiback_init_sring(struct vscsibk_info *info,
-		unsigned long ring_ref, unsigned int evtchn);
+			int ring_ref[], int nr_refs,
+			unsigned int evtchn);
 int scsiback_schedule(void *data);
 
 
diff --git a/drivers/scsi/xen-scsiback/interface.c b/drivers/scsi/xen-scsiback/interface.c
index 663568e..fad0a63 100644
--- a/drivers/scsi/xen-scsiback/interface.c
+++ b/drivers/scsi/xen-scsiback/interface.c
@@ -60,7 +60,8 @@ struct vscsibk_info *vscsibk_info_alloc(domid_t domid)
 }
 
 int scsiback_init_sring(struct vscsibk_info *info,
-		unsigned long ring_ref, unsigned int evtchn)
+			int ring_ref[], int nr_refs,
+			unsigned int evtchn)
 {
 	struct vscsiif_sring *sring;
 	int err;
@@ -73,7 +74,8 @@ int scsiback_init_sring(struct vscsibk_info *info,
 		return -1;
 	}
 
-	err = xenbus_map_ring_valloc(info->dev, ring_ref, &info->ring_area);
+	err = xenbus_map_ring_valloc(info->dev, ring_ref, nr_refs,
+				     &info->ring_area);
 	if (err < 0)
 		return -ENOMEM;
 
diff --git a/drivers/scsi/xen-scsiback/xenbus.c b/drivers/scsi/xen-scsiback/xenbus.c
index 2869f89..81d5598 100644
--- a/drivers/scsi/xen-scsiback/xenbus.c
+++ b/drivers/scsi/xen-scsiback/xenbus.c
@@ -60,7 +60,7 @@ static int __vscsiif_name(struct backend_info *be, char *buf)
 static int scsiback_map(struct backend_info *be)
 {
 	struct xenbus_device *dev = be->dev;
-	unsigned long ring_ref = 0;
+	int ring_ref = 0;
 	unsigned int evtchn = 0;
 	int err;
 	char name[TASK_COMM_LEN];
@@ -72,7 +72,7 @@ static int scsiback_map(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "reading %s ring", dev->otherend);
 		return err;
 	}
-	err = scsiback_init_sring(be->info, ring_ref, evtchn);
+	err = scsiback_init_sring(be->info, &ring_ref, 1, evtchn);
 	if (err)
 		return err;
 
diff --git a/drivers/scsi/xen-scsifront/xenbus.c b/drivers/scsi/xen-scsifront/xenbus.c
index bc5c289..8726410 100644
--- a/drivers/scsi/xen-scsifront/xenbus.c
+++ b/drivers/scsi/xen-scsifront/xenbus.c
@@ -60,6 +60,7 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
 	struct xenbus_device *dev = info->dev;
 	struct vscsiif_sring *sring;
 	int err = -ENOMEM;
+	int grefs[1];
 
 
 	info->ring_ref = GRANT_INVALID_REF;
@@ -73,14 +74,14 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
 	SHARED_RING_INIT(sring);
 	FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(sring));
+	err = xenbus_grant_ring(dev, sring, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long) sring);
 		info->ring.sring = NULL;
 		xenbus_dev_fatal(dev, err, "fail to grant shared ring (Front to Back)");
 		goto free_sring;
 	}
-	info->ring_ref = err;
+	info->ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 5a42ae7..0d8a98c 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -98,17 +98,18 @@ static void free_pdev(struct xen_pcibk_device *pdev)
 	kfree(pdev);
 }
 
-static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref,
-			     int remote_evtchn)
+static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref[],
+			       int nr_grefs,
+			       int remote_evtchn)
 {
 	int err = 0;
 	void *vaddr;
 
 	dev_dbg(&pdev->xdev->dev,
 		"Attaching to frontend resources - gnt_ref=%d evtchn=%d\n",
-		gnt_ref, remote_evtchn);
+		gnt_ref[0], remote_evtchn);
 
-	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr);
+	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, nr_grefs, &vaddr);
 	if (err < 0) {
 		xenbus_dev_fatal(pdev->xdev, err,
 				"Error mapping other domain page in ours.");
@@ -172,7 +173,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
 		goto out;
 	}
 
-	err = xen_pcibk_do_attach(pdev, gnt_ref, remote_evtchn);
+	err = xen_pcibk_do_attach(pdev, &gnt_ref, 1, remote_evtchn);
 	if (err)
 		goto out;
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqv-0002Lb-Jz; Thu, 02 Feb 2012 16:49:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqu-0002Iy-9J
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:40 +0000
Received: from [85.158.138.51:21281] by server-5.bemta-3.messagelabs.com id
	C1/D1-25695-3AEBA2F4; Thu, 02 Feb 2012 16:49:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27647 invoked from network); 2 Feb 2012 16:49:38 -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;
	2 Feb 2012 16:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555492"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:37 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPu008442;
	Thu, 2 Feb 2012 08:49:35 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:19 +0000
Message-ID: <1328201363-13915-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 09/13] Bundle fix for xen backends and
	frontends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/block/xen-blkback/xenbus.c    |    8 +++++---
 drivers/block/xen-blkfront.c          |    5 +++--
 drivers/net/xen-netback/netback.c     |    4 ++--
 drivers/net/xen-netfront.c            |    9 +++++----
 drivers/pci/xen-pcifront.c            |    5 +++--
 drivers/scsi/xen-scsiback/common.h    |    3 ++-
 drivers/scsi/xen-scsiback/interface.c |    6 ++++--
 drivers/scsi/xen-scsiback/xenbus.c    |    4 ++--
 drivers/scsi/xen-scsifront/xenbus.c   |    5 +++--
 drivers/xen/xen-pciback/xenbus.c      |   11 ++++++-----
 10 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 9e9c8a1..ef7e88b 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -122,7 +122,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	return blkif;
 }
 
-static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
+static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page[],
+			 int nr_pages,
 			 unsigned int evtchn)
 {
 	int err;
@@ -131,7 +132,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
 	if (blkif->irq)
 		return 0;
 
-	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring);
+	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page,
+				     nr_pages, &blkif->blk_ring);
 	if (err < 0)
 		return err;
 
@@ -779,7 +781,7 @@ static int connect_ring(struct backend_info *be)
 		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
 
 	/* Map the shared frame, irq etc. */
-	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
+	err = xen_blkif_map(be->blkif, &ring_ref, 1, evtchn);
 	if (err) {
 		xenbus_dev_fatal(dev, err, "mapping ring-ref %lu port %u",
 				 ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..2c6443a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -827,6 +827,7 @@ static int setup_blkring(struct xenbus_device *dev,
 {
 	struct blkif_sring *sring;
 	int err;
+	int grefs[1];
 
 	info->ring_ref = GRANT_INVALID_REF;
 
@@ -840,13 +841,13 @@ static int setup_blkring(struct xenbus_device *dev,
 
 	sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(info->ring.sring));
+	err = xenbus_grant_ring(dev, info->ring.sring, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)sring);
 		info->ring.sring = NULL;
 		goto fail;
 	}
-	info->ring_ref = err;
+	info->ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 384f4e5..cb1a661 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1440,7 +1440,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
 	int err = -ENOMEM;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     tx_ring_ref, &addr);
+				     &tx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
@@ -1448,7 +1448,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
 	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     rx_ring_ref, &addr);
+				     &rx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 01f589d..b7ff815 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1482,6 +1482,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	int grefs[1];
 	struct net_device *netdev = info->netdev;
 
 	info->tx_ring_ref = GRANT_INVALID_REF;
@@ -1505,13 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(txs);
 	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	err = xenbus_grant_ring(dev, txs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)txs);
 		goto fail;
 	}
 
-	info->tx_ring_ref = err;
+	info->tx_ring_ref = grefs[0];
 	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
@@ -1521,12 +1522,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(rxs);
 	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
+	err = xenbus_grant_ring(dev, rxs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)rxs);
 		goto fail;
 	}
-	info->rx_ring_ref = err;
+	info->rx_ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 7cf3d2f..394c926 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -767,12 +767,13 @@ static int pcifront_publish_info(struct pcifront_device *pdev)
 {
 	int err = 0;
 	struct xenbus_transaction trans;
+	int grefs[1];
 
-	err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
+	err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, grefs);
 	if (err < 0)
 		goto out;
 
-	pdev->gnt_ref = err;
+	pdev->gnt_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
 	if (err)
diff --git a/drivers/scsi/xen-scsiback/common.h b/drivers/scsi/xen-scsiback/common.h
index dafa79e..4d13617 100644
--- a/drivers/scsi/xen-scsiback/common.h
+++ b/drivers/scsi/xen-scsiback/common.h
@@ -150,7 +150,8 @@ typedef struct {
 
 irqreturn_t scsiback_intr(int, void *);
 int scsiback_init_sring(struct vscsibk_info *info,
-		unsigned long ring_ref, unsigned int evtchn);
+			int ring_ref[], int nr_refs,
+			unsigned int evtchn);
 int scsiback_schedule(void *data);
 
 
diff --git a/drivers/scsi/xen-scsiback/interface.c b/drivers/scsi/xen-scsiback/interface.c
index 663568e..fad0a63 100644
--- a/drivers/scsi/xen-scsiback/interface.c
+++ b/drivers/scsi/xen-scsiback/interface.c
@@ -60,7 +60,8 @@ struct vscsibk_info *vscsibk_info_alloc(domid_t domid)
 }
 
 int scsiback_init_sring(struct vscsibk_info *info,
-		unsigned long ring_ref, unsigned int evtchn)
+			int ring_ref[], int nr_refs,
+			unsigned int evtchn)
 {
 	struct vscsiif_sring *sring;
 	int err;
@@ -73,7 +74,8 @@ int scsiback_init_sring(struct vscsibk_info *info,
 		return -1;
 	}
 
-	err = xenbus_map_ring_valloc(info->dev, ring_ref, &info->ring_area);
+	err = xenbus_map_ring_valloc(info->dev, ring_ref, nr_refs,
+				     &info->ring_area);
 	if (err < 0)
 		return -ENOMEM;
 
diff --git a/drivers/scsi/xen-scsiback/xenbus.c b/drivers/scsi/xen-scsiback/xenbus.c
index 2869f89..81d5598 100644
--- a/drivers/scsi/xen-scsiback/xenbus.c
+++ b/drivers/scsi/xen-scsiback/xenbus.c
@@ -60,7 +60,7 @@ static int __vscsiif_name(struct backend_info *be, char *buf)
 static int scsiback_map(struct backend_info *be)
 {
 	struct xenbus_device *dev = be->dev;
-	unsigned long ring_ref = 0;
+	int ring_ref = 0;
 	unsigned int evtchn = 0;
 	int err;
 	char name[TASK_COMM_LEN];
@@ -72,7 +72,7 @@ static int scsiback_map(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "reading %s ring", dev->otherend);
 		return err;
 	}
-	err = scsiback_init_sring(be->info, ring_ref, evtchn);
+	err = scsiback_init_sring(be->info, &ring_ref, 1, evtchn);
 	if (err)
 		return err;
 
diff --git a/drivers/scsi/xen-scsifront/xenbus.c b/drivers/scsi/xen-scsifront/xenbus.c
index bc5c289..8726410 100644
--- a/drivers/scsi/xen-scsifront/xenbus.c
+++ b/drivers/scsi/xen-scsifront/xenbus.c
@@ -60,6 +60,7 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
 	struct xenbus_device *dev = info->dev;
 	struct vscsiif_sring *sring;
 	int err = -ENOMEM;
+	int grefs[1];
 
 
 	info->ring_ref = GRANT_INVALID_REF;
@@ -73,14 +74,14 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
 	SHARED_RING_INIT(sring);
 	FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(sring));
+	err = xenbus_grant_ring(dev, sring, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long) sring);
 		info->ring.sring = NULL;
 		xenbus_dev_fatal(dev, err, "fail to grant shared ring (Front to Back)");
 		goto free_sring;
 	}
-	info->ring_ref = err;
+	info->ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 5a42ae7..0d8a98c 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -98,17 +98,18 @@ static void free_pdev(struct xen_pcibk_device *pdev)
 	kfree(pdev);
 }
 
-static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref,
-			     int remote_evtchn)
+static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref[],
+			       int nr_grefs,
+			       int remote_evtchn)
 {
 	int err = 0;
 	void *vaddr;
 
 	dev_dbg(&pdev->xdev->dev,
 		"Attaching to frontend resources - gnt_ref=%d evtchn=%d\n",
-		gnt_ref, remote_evtchn);
+		gnt_ref[0], remote_evtchn);
 
-	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr);
+	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, nr_grefs, &vaddr);
 	if (err < 0) {
 		xenbus_dev_fatal(pdev->xdev, err,
 				"Error mapping other domain page in ours.");
@@ -172,7 +173,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
 		goto out;
 	}
 
-	err = xen_pcibk_do_attach(pdev, gnt_ref, remote_evtchn);
+	err = xen_pcibk_do_attach(pdev, &gnt_ref, 1, remote_evtchn);
 	if (err)
 		goto out;
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqy-0002O5-4f; Thu, 02 Feb 2012 16:49:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqw-0002Fr-7F
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:42 +0000
Received: from [85.158.138.51:64060] by server-4.bemta-3.messagelabs.com id
	0D/78-07654-5AEBA2F4; Thu, 02 Feb 2012 16:49:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27788 invoked from network); 2 Feb 2012 16:49:40 -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;
	2 Feb 2012 16:49:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555505"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:40 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPw008442;
	Thu, 2 Feb 2012 08:49:38 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:21 +0000
Message-ID: <1328201363-13915-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 11/13] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Originally, netback and netfront only use one event channel to do tx /
rx notification. This may cause unnecessary wake-up of NAPI / kthread.

When guest tx is completed, netback will only notify tx_irq.

If feature-split-event-channels ==0, rx_irq = tx_irq, so
RX protocol will just work as expected.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |    7 ++-
 drivers/net/xen-netback/interface.c |   82 +++++++++++++++++++++++++++--------
 drivers/net/xen-netback/netback.c   |    4 +-
 drivers/net/xen-netback/xenbus.c    |   51 +++++++++++++++++----
 4 files changed, 111 insertions(+), 33 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 1bb16ec..a0497fc 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -85,8 +85,9 @@ struct xenvif {
 
 	u8               fe_dev_addr[6];
 
-	/* Physical parameters of the comms window. */
-	unsigned int     irq;
+	/* When feature-split-event-channels = 0, tx_irq = rx_irq */
+	unsigned int tx_irq;
+	unsigned int rx_irq;
 
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
@@ -145,7 +146,7 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
-		   unsigned int evtchn);
+		   unsigned int tx_evtchn, unsigned int rx_evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index e1aa003..c6dbd50 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -51,19 +51,35 @@ static int xenvif_rx_schedulable(struct xenvif *vif)
 	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
-static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (xenvif_rx_schedulable(vif))
-		netif_wake_queue(vif->dev);
-
 	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
 		napi_schedule(&vif->napi);
 
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
+{
+	struct xenvif *vif = dev_id;
+
+	if (xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif))
+		netif_wake_queue(vif->dev);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+{
+	xenvif_tx_interrupt(irq, dev_id);
+
+	xenvif_rx_interrupt(irq, dev_id);
+
+	return IRQ_HANDLED;
+}
+
 static int xenvif_poll(struct napi_struct *napi, int budget)
 {
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
@@ -132,14 +148,16 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
-	enable_irq(vif->irq);
+	enable_irq(vif->tx_irq);
+	enable_irq(vif->rx_irq);
 	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
 	napi_disable(&vif->napi);
-	disable_irq(vif->irq);
+	disable_irq(vif->tx_irq);
+	disable_irq(vif->rx_irq);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -322,7 +340,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
-		   unsigned int evtchn)
+		   unsigned int tx_evtchn, unsigned int rx_evtchn)
 {
 	int err = -ENOMEM;
 	void *addr;
@@ -331,7 +349,7 @@ int xenvif_connect(struct xenvif *vif,
 	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
-	if (vif->irq)
+	if (vif->tx_irq)
 		return 0;
 
 	__module_get(THIS_MODULE);
@@ -358,13 +376,34 @@ int xenvif_connect(struct xenvif *vif,
 	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
 	vif->nr_rx_handles = rx_ring_ref_count;
 
-	err = bind_interdomain_evtchn_to_irqhandler(
-		vif->domid, evtchn, xenvif_interrupt, 0,
-		vif->dev->name, vif);
-	if (err < 0)
-		goto err_rx_unmap;
-	vif->irq = err;
-	disable_irq(vif->irq);
+	if (tx_evtchn == rx_evtchn) { /* feature-split-event-channels == 0 */
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = vif->rx_irq = err;
+		disable_irq(vif->tx_irq);
+		disable_irq(vif->rx_irq);
+	} else {
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = err;
+		disable_irq(vif->tx_irq);
+
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0) {
+			unbind_from_irqhandler(vif->tx_irq, vif);
+			goto err_rx_unmap;
+		}
+		vif->rx_irq = err;
+		disable_irq(vif->rx_irq);
+	}
 
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xenvif_kthread,
@@ -389,7 +428,12 @@ int xenvif_connect(struct xenvif *vif,
 
 	return 0;
 err_unbind:
-	unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq == vif->rx_irq)
+		unbind_from_irqhandler(vif->tx_irq, vif);
+	else {
+		unbind_from_irqhandler(vif->tx_irq, vif);
+		unbind_from_irqhandler(vif->rx_irq, vif);
+	}
 err_rx_unmap:
 	xenvif_unmap_frontend_ring(vif, (void *)vif->tx.sring);
 err_tx_unmap:
@@ -419,10 +463,12 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq) {
-		unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq) {
+		unbind_from_irqhandler(vif->tx_irq, vif);
 		need_module_put = 1;
 	}
+	if (vif->tx_irq != vif->rx_irq)
+		unbind_from_irqhandler(vif->rx_irq, vif);
 
 	unregister_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 60c8951..957cf9d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -622,7 +622,7 @@ void xenvif_rx_action(struct xenvif *vif)
 	}
 
 	if (need_to_notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->rx_irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
 		xenvif_kick_thread(vif);
@@ -1392,7 +1392,7 @@ static void make_tx_response(struct xenvif *vif,
 	vif->tx.rsp_prod_pvt = ++i;
 	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->tx, notify);
 	if (notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->tx_irq);
 }
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 79499fc..3772e0c 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		err = xenbus_printf(xbt, dev->nodename,
+				    "feature-split-event-channels",
+				    "%u", 1);
+		if (err) {
+			message = "writing feature-split-event-channels";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned int evtchn, rx_copy;
+	unsigned int tx_evtchn, rx_evtchn, rx_copy;
 	int err;
 	int val;
 	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
@@ -417,12 +425,30 @@ static int connect_rings(struct backend_info *be)
 	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "event-channel", "%u", &evtchn, NULL);
+			    "event-channel", "%u", &tx_evtchn, NULL);
 	if (err) {
-		xenbus_dev_fatal(dev, err,
-				 "reading %s/event-channel",
-				 dev->otherend);
-		return err;
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-tx", "%u", &tx_evtchn,
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-tx",
+					 dev->otherend);
+			return err;
+		}
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-rx", "%u", &rx_evtchn,
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-rx",
+					 dev->otherend);
+			return err;
+		}
+		dev_info(&dev->dev, "split event channels\n");
+	} else {
+		rx_evtchn = tx_evtchn;
+		dev_info(&dev->dev, "single event channel\n");
 	}
 
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
@@ -559,12 +585,17 @@ static int connect_rings(struct backend_info *be)
 	err = xenvif_connect(vif,
 			     tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn);
+			     tx_evtchn, rx_evtchn);
 	if (err) {
 		int i;
-		xenbus_dev_fatal(dev, err,
-				 "binding port %u",
-				 evtchn);
+		if (tx_evtchn == rx_evtchn)
+			xenbus_dev_fatal(dev, err,
+					 "binding port %u",
+					 tx_evtchn);
+		else
+			xenbus_dev_fatal(dev, err,
+					 "binding tx port %u, rx port %u",
+					 tx_evtchn, rx_evtchn);
 		for (i = 0; i < (1U << tx_ring_order); i++)
 			xenbus_dev_fatal(dev, err,
 					 "mapping tx ring handle: %lu",
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszqy-0002O5-4f; Thu, 02 Feb 2012 16:49:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszqw-0002Fr-7F
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:42 +0000
Received: from [85.158.138.51:64060] by server-4.bemta-3.messagelabs.com id
	0D/78-07654-5AEBA2F4; Thu, 02 Feb 2012 16:49:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27788 invoked from network); 2 Feb 2012 16:49:40 -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;
	2 Feb 2012 16:49:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555505"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:40 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPw008442;
	Thu, 2 Feb 2012 08:49:38 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:21 +0000
Message-ID: <1328201363-13915-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 11/13] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Originally, netback and netfront only use one event channel to do tx /
rx notification. This may cause unnecessary wake-up of NAPI / kthread.

When guest tx is completed, netback will only notify tx_irq.

If feature-split-event-channels ==0, rx_irq = tx_irq, so
RX protocol will just work as expected.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |    7 ++-
 drivers/net/xen-netback/interface.c |   82 +++++++++++++++++++++++++++--------
 drivers/net/xen-netback/netback.c   |    4 +-
 drivers/net/xen-netback/xenbus.c    |   51 +++++++++++++++++----
 4 files changed, 111 insertions(+), 33 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 1bb16ec..a0497fc 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -85,8 +85,9 @@ struct xenvif {
 
 	u8               fe_dev_addr[6];
 
-	/* Physical parameters of the comms window. */
-	unsigned int     irq;
+	/* When feature-split-event-channels = 0, tx_irq = rx_irq */
+	unsigned int tx_irq;
+	unsigned int rx_irq;
 
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
@@ -145,7 +146,7 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
-		   unsigned int evtchn);
+		   unsigned int tx_evtchn, unsigned int rx_evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index e1aa003..c6dbd50 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -51,19 +51,35 @@ static int xenvif_rx_schedulable(struct xenvif *vif)
 	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
-static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (xenvif_rx_schedulable(vif))
-		netif_wake_queue(vif->dev);
-
 	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
 		napi_schedule(&vif->napi);
 
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
+{
+	struct xenvif *vif = dev_id;
+
+	if (xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif))
+		netif_wake_queue(vif->dev);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+{
+	xenvif_tx_interrupt(irq, dev_id);
+
+	xenvif_rx_interrupt(irq, dev_id);
+
+	return IRQ_HANDLED;
+}
+
 static int xenvif_poll(struct napi_struct *napi, int budget)
 {
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
@@ -132,14 +148,16 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
-	enable_irq(vif->irq);
+	enable_irq(vif->tx_irq);
+	enable_irq(vif->rx_irq);
 	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
 	napi_disable(&vif->napi);
-	disable_irq(vif->irq);
+	disable_irq(vif->tx_irq);
+	disable_irq(vif->rx_irq);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -322,7 +340,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
-		   unsigned int evtchn)
+		   unsigned int tx_evtchn, unsigned int rx_evtchn)
 {
 	int err = -ENOMEM;
 	void *addr;
@@ -331,7 +349,7 @@ int xenvif_connect(struct xenvif *vif,
 	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
-	if (vif->irq)
+	if (vif->tx_irq)
 		return 0;
 
 	__module_get(THIS_MODULE);
@@ -358,13 +376,34 @@ int xenvif_connect(struct xenvif *vif,
 	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
 	vif->nr_rx_handles = rx_ring_ref_count;
 
-	err = bind_interdomain_evtchn_to_irqhandler(
-		vif->domid, evtchn, xenvif_interrupt, 0,
-		vif->dev->name, vif);
-	if (err < 0)
-		goto err_rx_unmap;
-	vif->irq = err;
-	disable_irq(vif->irq);
+	if (tx_evtchn == rx_evtchn) { /* feature-split-event-channels == 0 */
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = vif->rx_irq = err;
+		disable_irq(vif->tx_irq);
+		disable_irq(vif->rx_irq);
+	} else {
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = err;
+		disable_irq(vif->tx_irq);
+
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0) {
+			unbind_from_irqhandler(vif->tx_irq, vif);
+			goto err_rx_unmap;
+		}
+		vif->rx_irq = err;
+		disable_irq(vif->rx_irq);
+	}
 
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xenvif_kthread,
@@ -389,7 +428,12 @@ int xenvif_connect(struct xenvif *vif,
 
 	return 0;
 err_unbind:
-	unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq == vif->rx_irq)
+		unbind_from_irqhandler(vif->tx_irq, vif);
+	else {
+		unbind_from_irqhandler(vif->tx_irq, vif);
+		unbind_from_irqhandler(vif->rx_irq, vif);
+	}
 err_rx_unmap:
 	xenvif_unmap_frontend_ring(vif, (void *)vif->tx.sring);
 err_tx_unmap:
@@ -419,10 +463,12 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq) {
-		unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq) {
+		unbind_from_irqhandler(vif->tx_irq, vif);
 		need_module_put = 1;
 	}
+	if (vif->tx_irq != vif->rx_irq)
+		unbind_from_irqhandler(vif->rx_irq, vif);
 
 	unregister_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 60c8951..957cf9d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -622,7 +622,7 @@ void xenvif_rx_action(struct xenvif *vif)
 	}
 
 	if (need_to_notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->rx_irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
 		xenvif_kick_thread(vif);
@@ -1392,7 +1392,7 @@ static void make_tx_response(struct xenvif *vif,
 	vif->tx.rsp_prod_pvt = ++i;
 	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->tx, notify);
 	if (notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->tx_irq);
 }
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 79499fc..3772e0c 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		err = xenbus_printf(xbt, dev->nodename,
+				    "feature-split-event-channels",
+				    "%u", 1);
+		if (err) {
+			message = "writing feature-split-event-channels";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned int evtchn, rx_copy;
+	unsigned int tx_evtchn, rx_evtchn, rx_copy;
 	int err;
 	int val;
 	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
@@ -417,12 +425,30 @@ static int connect_rings(struct backend_info *be)
 	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "event-channel", "%u", &evtchn, NULL);
+			    "event-channel", "%u", &tx_evtchn, NULL);
 	if (err) {
-		xenbus_dev_fatal(dev, err,
-				 "reading %s/event-channel",
-				 dev->otherend);
-		return err;
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-tx", "%u", &tx_evtchn,
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-tx",
+					 dev->otherend);
+			return err;
+		}
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-rx", "%u", &rx_evtchn,
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-rx",
+					 dev->otherend);
+			return err;
+		}
+		dev_info(&dev->dev, "split event channels\n");
+	} else {
+		rx_evtchn = tx_evtchn;
+		dev_info(&dev->dev, "single event channel\n");
 	}
 
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
@@ -559,12 +585,17 @@ static int connect_rings(struct backend_info *be)
 	err = xenvif_connect(vif,
 			     tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn);
+			     tx_evtchn, rx_evtchn);
 	if (err) {
 		int i;
-		xenbus_dev_fatal(dev, err,
-				 "binding port %u",
-				 evtchn);
+		if (tx_evtchn == rx_evtchn)
+			xenbus_dev_fatal(dev, err,
+					 "binding port %u",
+					 tx_evtchn);
+		else
+			xenbus_dev_fatal(dev, err,
+					 "binding tx port %u, rx port %u",
+					 tx_evtchn, rx_evtchn);
 		for (i = 0; i < (1U << tx_ring_order); i++)
 			xenbus_dev_fatal(dev, err,
 					 "mapping tx ring handle: %lu",
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszr2-0002SY-KW; Thu, 02 Feb 2012 16:49:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr1-0002P6-9x
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:47 +0000
Received: from [85.158.138.51:21616] by server-9.bemta-3.messagelabs.com id
	9B/AB-21252-8AEBA2F4; Thu, 02 Feb 2012 16:49:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27863 invoked from network); 2 Feb 2012 16:49:43 -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;
	2 Feb 2012 16:49:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555519"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:42 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNQ0008442;
	Thu, 2 Feb 2012 08:49:41 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:23 +0000
Message-ID: <1328201363-13915-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 13/13] netfront: split event channels
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If this feature is not activated, rx_irq = tx_irq. See corresponding
netback change log for details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  178 +++++++++++++++++++++++++++++++++++--------
 1 files changed, 145 insertions(+), 33 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index a1cfb24..9d70665 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -98,7 +98,9 @@ struct netfront_info {
 
 	unsigned long rx_gso_checksum_fixup;
 
-	unsigned int evtchn;
+	unsigned int tx_evtchn, rx_evtchn;
+	unsigned int tx_irq, rx_irq;
+
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
@@ -342,7 +344,7 @@ no_skb:
  push:
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->rx_irq);
 }
 
 static int xennet_open(struct net_device *dev)
@@ -575,7 +577,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->tx_irq);
 
 	u64_stats_update_begin(&stats->syncp);
 	stats->tx_bytes += skb->len;
@@ -1240,22 +1242,36 @@ static int xennet_set_features(struct net_device *dev, u32 features)
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+static irqreturn_t xennet_tx_interrupt(int irq, void *dev_id)
 {
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
 	unsigned long flags;
 
 	spin_lock_irqsave(&np->tx_lock, flags);
+	xennet_tx_buf_gc(dev);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
+	return IRQ_HANDLED;
+}
 
-	spin_unlock_irqrestore(&np->tx_lock, flags);
+static irqreturn_t xennet_rx_interrupt(int irq, void *dev_id)
+{
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
+
+	if (likely(netif_carrier_ok(dev) &&
+		   RING_HAS_UNCONSUMED_RESPONSES(&np->rx)))
+		napi_schedule(&np->napi);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	xennet_tx_interrupt(irq, dev_id);
+
+	xennet_rx_interrupt(irq, dev_id);
 
 	return IRQ_HANDLED;
 }
@@ -1431,9 +1447,15 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 	spin_unlock_irq(&info->tx_lock);
 	spin_unlock_bh(&info->rx_lock);
 
-	if (info->netdev->irq)
-		unbind_from_irqhandler(info->netdev->irq, info->netdev);
-	info->evtchn = info->netdev->irq = 0;
+	if (info->tx_irq && (info->tx_irq == info->rx_irq))
+		unbind_from_irqhandler(info->tx_irq, info);
+	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
+		unbind_from_irqhandler(info->tx_irq, info);
+		unbind_from_irqhandler(info->rx_irq, info);
+	}
+
+	info->tx_evtchn = info->tx_irq = 0;
+	info->rx_evtchn = info->rx_irq = 0;
 
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
 	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
@@ -1483,11 +1505,80 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
 	return 0;
 }
 
+static int setup_netfront_single(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+
+	if (err < 0)
+		goto fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_fail;
+	info->rx_evtchn = info->tx_evtchn;
+	info->rx_irq = info->tx_irq = err;
+	dev_info(&info->xbdev->dev, "single event channel, irq = %d\n",
+		 info->tx_irq);
+
+	return 0;
+
+bind_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+fail:
+	return err;
+}
+
+static int setup_netfront_split(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+	if (err)
+		goto fail;
+	err = xenbus_alloc_evtchn(info->xbdev, &info->rx_evtchn);
+	if (err)
+		goto alloc_rx_evtchn_fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_tx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_tx_fail;
+	info->tx_irq = err;
+	err = bind_evtchn_to_irqhandler(info->rx_evtchn,
+					xennet_rx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_rx_fail;
+
+	info->rx_irq = err;
+	dev_info(&info->xbdev->dev, "split event channels,"
+		 " tx_irq = %d, rx_irq = %d\n",
+		 info->tx_irq, info->rx_irq);
+
+
+	return 0;
+
+bind_rx_fail:
+	unbind_from_irqhandler(info->tx_irq, info);
+bind_tx_fail:
+	xenbus_free_evtchn(info->xbdev, info->rx_evtchn);
+alloc_rx_evtchn_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+fail:
+	return err;
+}
+
 static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 {
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	unsigned int feature_split_evtchn;
 	struct net_device *netdev = info->netdev;
 	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
 	int i;
@@ -1507,6 +1598,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 
 	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-split-event-channels", "%u",
+			   &feature_split_evtchn);
+
+	if (err < 0)
+		feature_split_evtchn = 0;
+
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
 			   "max-tx-ring-page-order", "%u",
 			   &max_tx_ring_page_order);
 	if (err < 0) {
@@ -1568,21 +1666,17 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 
 	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
-	err = xenbus_alloc_evtchn(dev, &info->evtchn);
-	if (err)
-		goto alloc_evtchn_fail;
+	if (!feature_split_evtchn)
+		err = setup_netfront_single(info);
+	else
+		err = setup_netfront_split(info);
 
-	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					0, netdev->name, netdev);
-	if (err < 0)
-		goto bind_fail;
-	netdev->irq = err;
+	if (err)
+		goto setup_evtchn_failed;
 
 	return 0;
 
-bind_fail:
-	xenbus_free_evtchn(dev, info->evtchn);
-alloc_evtchn_fail:
+setup_evtchn_failed:
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
 grant_rx_ring_fail:
 	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
@@ -1659,11 +1753,27 @@ again:
 		}
 	}
 
-	err = xenbus_printf(xbt, dev->nodename,
-			    "event-channel", "%u", info->evtchn);
-	if (err) {
-		message = "writing event-channel";
-		goto abort_transaction;
+
+	if (info->tx_evtchn == info->rx_evtchn) {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-tx", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel-tx";
+			goto abort_transaction;
+		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-rx", "%u", info->rx_evtchn);
+		if (err) {
+			message = "writing event-channel-rx";
+			goto abort_transaction;
+		}
 	}
 
 	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
@@ -1777,7 +1887,9 @@ static int xennet_connect(struct net_device *dev)
 	 * packets.
 	 */
 	netif_carrier_on(np->netdev);
-	notify_remote_via_irq(np->netdev->irq);
+	notify_remote_via_irq(np->tx_irq);
+	if (np->tx_irq != np->rx_irq)
+		notify_remote_via_irq(np->rx_irq);
 	xennet_tx_buf_gc(dev);
 	xennet_alloc_rx_buffers(dev);
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:49:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rszr2-0002SY-KW; Thu, 02 Feb 2012 16:49:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr1-0002P6-9x
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:47 +0000
Received: from [85.158.138.51:21616] by server-9.bemta-3.messagelabs.com id
	9B/AB-21252-8AEBA2F4; Thu, 02 Feb 2012 16:49:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328201366!11555508!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27863 invoked from network); 2 Feb 2012 16:49:43 -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;
	2 Feb 2012 16:49:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="21555519"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:42 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNQ0008442;
	Thu, 2 Feb 2012 08:49:41 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:23 +0000
Message-ID: <1328201363-13915-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 13/13] netfront: split event channels
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If this feature is not activated, rx_irq = tx_irq. See corresponding
netback change log for details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  178 +++++++++++++++++++++++++++++++++++--------
 1 files changed, 145 insertions(+), 33 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index a1cfb24..9d70665 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -98,7 +98,9 @@ struct netfront_info {
 
 	unsigned long rx_gso_checksum_fixup;
 
-	unsigned int evtchn;
+	unsigned int tx_evtchn, rx_evtchn;
+	unsigned int tx_irq, rx_irq;
+
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
@@ -342,7 +344,7 @@ no_skb:
  push:
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->rx_irq);
 }
 
 static int xennet_open(struct net_device *dev)
@@ -575,7 +577,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->tx_irq);
 
 	u64_stats_update_begin(&stats->syncp);
 	stats->tx_bytes += skb->len;
@@ -1240,22 +1242,36 @@ static int xennet_set_features(struct net_device *dev, u32 features)
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+static irqreturn_t xennet_tx_interrupt(int irq, void *dev_id)
 {
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
 	unsigned long flags;
 
 	spin_lock_irqsave(&np->tx_lock, flags);
+	xennet_tx_buf_gc(dev);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
+	return IRQ_HANDLED;
+}
 
-	spin_unlock_irqrestore(&np->tx_lock, flags);
+static irqreturn_t xennet_rx_interrupt(int irq, void *dev_id)
+{
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
+
+	if (likely(netif_carrier_ok(dev) &&
+		   RING_HAS_UNCONSUMED_RESPONSES(&np->rx)))
+		napi_schedule(&np->napi);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	xennet_tx_interrupt(irq, dev_id);
+
+	xennet_rx_interrupt(irq, dev_id);
 
 	return IRQ_HANDLED;
 }
@@ -1431,9 +1447,15 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 	spin_unlock_irq(&info->tx_lock);
 	spin_unlock_bh(&info->rx_lock);
 
-	if (info->netdev->irq)
-		unbind_from_irqhandler(info->netdev->irq, info->netdev);
-	info->evtchn = info->netdev->irq = 0;
+	if (info->tx_irq && (info->tx_irq == info->rx_irq))
+		unbind_from_irqhandler(info->tx_irq, info);
+	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
+		unbind_from_irqhandler(info->tx_irq, info);
+		unbind_from_irqhandler(info->rx_irq, info);
+	}
+
+	info->tx_evtchn = info->tx_irq = 0;
+	info->rx_evtchn = info->rx_irq = 0;
 
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
 	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
@@ -1483,11 +1505,80 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
 	return 0;
 }
 
+static int setup_netfront_single(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+
+	if (err < 0)
+		goto fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_fail;
+	info->rx_evtchn = info->tx_evtchn;
+	info->rx_irq = info->tx_irq = err;
+	dev_info(&info->xbdev->dev, "single event channel, irq = %d\n",
+		 info->tx_irq);
+
+	return 0;
+
+bind_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+fail:
+	return err;
+}
+
+static int setup_netfront_split(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+	if (err)
+		goto fail;
+	err = xenbus_alloc_evtchn(info->xbdev, &info->rx_evtchn);
+	if (err)
+		goto alloc_rx_evtchn_fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_tx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_tx_fail;
+	info->tx_irq = err;
+	err = bind_evtchn_to_irqhandler(info->rx_evtchn,
+					xennet_rx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_rx_fail;
+
+	info->rx_irq = err;
+	dev_info(&info->xbdev->dev, "split event channels,"
+		 " tx_irq = %d, rx_irq = %d\n",
+		 info->tx_irq, info->rx_irq);
+
+
+	return 0;
+
+bind_rx_fail:
+	unbind_from_irqhandler(info->tx_irq, info);
+bind_tx_fail:
+	xenbus_free_evtchn(info->xbdev, info->rx_evtchn);
+alloc_rx_evtchn_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+fail:
+	return err;
+}
+
 static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 {
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	unsigned int feature_split_evtchn;
 	struct net_device *netdev = info->netdev;
 	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
 	int i;
@@ -1507,6 +1598,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 
 	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-split-event-channels", "%u",
+			   &feature_split_evtchn);
+
+	if (err < 0)
+		feature_split_evtchn = 0;
+
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
 			   "max-tx-ring-page-order", "%u",
 			   &max_tx_ring_page_order);
 	if (err < 0) {
@@ -1568,21 +1666,17 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 
 	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
-	err = xenbus_alloc_evtchn(dev, &info->evtchn);
-	if (err)
-		goto alloc_evtchn_fail;
+	if (!feature_split_evtchn)
+		err = setup_netfront_single(info);
+	else
+		err = setup_netfront_split(info);
 
-	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					0, netdev->name, netdev);
-	if (err < 0)
-		goto bind_fail;
-	netdev->irq = err;
+	if (err)
+		goto setup_evtchn_failed;
 
 	return 0;
 
-bind_fail:
-	xenbus_free_evtchn(dev, info->evtchn);
-alloc_evtchn_fail:
+setup_evtchn_failed:
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
 grant_rx_ring_fail:
 	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
@@ -1659,11 +1753,27 @@ again:
 		}
 	}
 
-	err = xenbus_printf(xbt, dev->nodename,
-			    "event-channel", "%u", info->evtchn);
-	if (err) {
-		message = "writing event-channel";
-		goto abort_transaction;
+
+	if (info->tx_evtchn == info->rx_evtchn) {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-tx", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel-tx";
+			goto abort_transaction;
+		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-rx", "%u", info->rx_evtchn);
+		if (err) {
+			message = "writing event-channel-rx";
+			goto abort_transaction;
+		}
 	}
 
 	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
@@ -1777,7 +1887,9 @@ static int xennet_connect(struct net_device *dev)
 	 * packets.
 	 */
 	netif_carrier_on(np->netdev);
-	notify_remote_via_irq(np->netdev->irq);
+	notify_remote_via_irq(np->tx_irq);
+	if (np->tx_irq != np->rx_irq)
+		notify_remote_via_irq(np->rx_irq);
 	xennet_tx_buf_gc(dev);
 	xennet_alloc_rx_buffers(dev);
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rszr5-0002VQ-8Z; Thu, 02 Feb 2012 16:49:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr2-0002NN-Od
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328201377!13178025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27088 invoked from network); 2 Feb 2012 16:49:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157199"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:33 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPr008442;
	Thu, 2 Feb 2012 08:49:32 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:16 +0000
Message-ID: <1328201363-13915-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 06/13] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   35 +++---
 drivers/net/xen-netback/interface.c |   36 +++---
 drivers/net/xen-netback/netback.c   |  219 +++++++++++++----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   13 ++-
 5 files changed, 124 insertions(+), 189 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 65df480..ea91bb6 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -46,6 +46,7 @@
 #include <xen/xenbus.h>
 
 #define DRV_NAME "netback: "
+#include "page_pool.h"
 
 struct netbk_rx_meta {
 	int id;
@@ -53,28 +54,21 @@ struct netbk_rx_meta {
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
-
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
-struct xen_netbk;
+#define MAX_PENDING_REQS 256
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -117,6 +111,16 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	u16 pending_ring[MAX_PENDING_REQS];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -124,9 +128,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -161,12 +162,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-int xen_netbk_tx_action(struct xen_netbk *netbk, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+int xen_netbk_tx_action(struct xenvif *vif, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1d9688a..9b7d596 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,9 +55,6 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
-		return IRQ_NONE;
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
@@ -72,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done;
 
-	work_done = xen_netbk_tx_action(vif->netbk, budget);
+	work_done = xen_netbk_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -96,7 +93,8 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
+	/* Drop the packet if vif is not ready */
+	if (vif->task == NULL)
 		goto drop;
 
 	/* Drop the packet if the target domain has no receive buffers. */
@@ -253,6 +251,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -267,7 +266,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -286,6 +284,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -333,14 +342,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -348,7 +349,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -363,8 +364,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -390,9 +389,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 5584853..ef9cfbe 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,28 +60,13 @@ DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
 DEFINE_PER_CPU(struct netbk_rx_meta *, meta);
 
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-
-	struct xenvif *vif;
-
-	u16 pending_ring[MAX_PENDING_REQS];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -90,16 +75,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -127,10 +112,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -317,9 +302,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
-			struct xen_netbk *rnetbk = to_netbk(idx);
+			struct xenvif *rvif = to_vif(idx);
 
-			copy_gop->source.domid = rnetbk->vif->domid;
+			copy_gop->source.domid = rvif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -477,16 +462,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -516,7 +498,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			pr_alert("CPU %x scratch space is not usable,"
 				 " not doing any TX work for vif%u.%u\n",
 				 smp_processor_id(),
-				 netbk->vif->domid, netbk->vif->handle);
+				 vif->domid, vif->handle);
 			unusable_count = 0;
 		}
 		return;
@@ -526,7 +508,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -558,8 +540,6 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
-
 		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
@@ -631,8 +611,8 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 
 	put_cpu_var(grant_copy_op);
 	put_cpu_var(meta);
@@ -640,11 +620,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
-
-	skb_queue_tail(&netbk->rx_queue, skb);
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -742,21 +720,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -775,13 +752,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		int idx;
 		struct pending_tx_info *pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		gop->source.u.ref = txp->gref;
@@ -805,7 +782,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
@@ -813,8 +790,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = netbk->vif;
-
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -824,12 +799,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		idx = netbk->mmap_pages[index];
+		index = pending_index(vif->pending_prod++);
+		idx = vif->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -846,16 +821,16 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -863,10 +838,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -877,7 +852,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -893,11 +868,11 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
@@ -905,7 +880,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1066,15 +1041,14 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 					struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1142,8 +1116,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1173,7 +1147,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1193,7 +1167,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 
 		gop++;
 
-		pool_idx = netbk->mmap_pages[pending_idx];
+		pool_idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(pool_idx);
 
 		memcpy(&pending_tx_info->req,
@@ -1213,11 +1187,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1235,17 +1209,16 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 	return gop - tco;
 }
 
-static int xen_netbk_tx_submit(struct xen_netbk *netbk,
-				struct gnttab_copy *tco,
-				int budget)
+static int xen_netbk_tx_submit(struct xenvif *vif,
+			       struct gnttab_copy *tco,
+			       int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 	int work_done = 0;
 
 	while ((work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
@@ -1254,13 +1227,13 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		pending_idx = *((u16 *)skb->data);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1269,7 +1242,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1277,7 +1250,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1285,7 +1258,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1319,7 +1292,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
+int xen_netbk_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
@@ -1327,7 +1300,7 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 	struct gnttab_copy *tco;
 	static int unusable_count;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return 0;
 
 	tco = get_cpu_var(tx_copy_ops);
@@ -1340,13 +1313,13 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 				 " is not usable,"
 				 " not doing any RX work for vif%u.%u\n",
 				 smp_processor_id(),
-				 netbk->vif->domid, netbk->vif->handle);
+				 vif->domid, vif->handle);
 			unusable_count = 0;
 		}
 		return -ENOMEM;
 	}
 
-	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+	nr_gops = xen_netbk_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_var(tx_copy_ops);
@@ -1357,35 +1330,34 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 					tco, nr_gops);
 	BUG_ON(ret);
 
-	work_done = xen_netbk_tx_submit(netbk, tco, budget);
+	work_done = xen_netbk_tx_submit(vif, tco, budget);
 
 	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	idx = netbk->mmap_pages[pending_idx];
+	idx = vif->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1432,15 +1404,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1491,54 +1463,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		pr_alert(DRV_NAME "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 294f48b..ce00a93 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -102,7 +102,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -118,7 +118,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -131,7 +131,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -174,9 +174,9 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
 
 struct pending_tx_info *to_txinfo(int idx)
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 572b037..efae17c 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -27,7 +27,10 @@
 #ifndef __PAGE_POOL_H__
 #define __PAGE_POOL_H__
 
-#include "common.h"
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
 
 typedef uint32_t idx_t;
 
@@ -38,8 +41,8 @@ struct page_pool_entry {
 	struct page *page;
 	struct pending_tx_info tx_info;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -52,12 +55,12 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
 struct page            *to_page(int idx);
-struct xen_netbk       *to_netbk(int idx);
+struct xenvif          *to_vif(int idx);
 struct pending_tx_info *to_txinfo(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rszr5-0002VQ-8Z; Thu, 02 Feb 2012 16:49:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr2-0002NN-Od
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328201377!13178025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27088 invoked from network); 2 Feb 2012 16:49:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157199"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:33 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPr008442;
	Thu, 2 Feb 2012 08:49:32 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:16 +0000
Message-ID: <1328201363-13915-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 06/13] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   35 +++---
 drivers/net/xen-netback/interface.c |   36 +++---
 drivers/net/xen-netback/netback.c   |  219 +++++++++++++----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   13 ++-
 5 files changed, 124 insertions(+), 189 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 65df480..ea91bb6 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -46,6 +46,7 @@
 #include <xen/xenbus.h>
 
 #define DRV_NAME "netback: "
+#include "page_pool.h"
 
 struct netbk_rx_meta {
 	int id;
@@ -53,28 +54,21 @@ struct netbk_rx_meta {
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
-
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
-struct xen_netbk;
+#define MAX_PENDING_REQS 256
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -117,6 +111,16 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	u16 pending_ring[MAX_PENDING_REQS];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -124,9 +128,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -161,12 +162,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-int xen_netbk_tx_action(struct xen_netbk *netbk, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+int xen_netbk_tx_action(struct xenvif *vif, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1d9688a..9b7d596 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,9 +55,6 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
-		return IRQ_NONE;
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
@@ -72,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done;
 
-	work_done = xen_netbk_tx_action(vif->netbk, budget);
+	work_done = xen_netbk_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -96,7 +93,8 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
+	/* Drop the packet if vif is not ready */
+	if (vif->task == NULL)
 		goto drop;
 
 	/* Drop the packet if the target domain has no receive buffers. */
@@ -253,6 +251,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -267,7 +266,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -286,6 +284,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -333,14 +342,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -348,7 +349,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -363,8 +364,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -390,9 +389,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 5584853..ef9cfbe 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -60,28 +60,13 @@ DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
 DEFINE_PER_CPU(struct netbk_rx_meta *, meta);
 
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-
-	struct xenvif *vif;
-
-	u16 pending_ring[MAX_PENDING_REQS];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -90,16 +75,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -127,10 +112,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -317,9 +302,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
-			struct xen_netbk *rnetbk = to_netbk(idx);
+			struct xenvif *rvif = to_vif(idx);
 
-			copy_gop->source.domid = rnetbk->vif->domid;
+			copy_gop->source.domid = rvif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -477,16 +462,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -516,7 +498,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			pr_alert("CPU %x scratch space is not usable,"
 				 " not doing any TX work for vif%u.%u\n",
 				 smp_processor_id(),
-				 netbk->vif->domid, netbk->vif->handle);
+				 vif->domid, vif->handle);
 			unusable_count = 0;
 		}
 		return;
@@ -526,7 +508,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -558,8 +540,6 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
-
 		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
@@ -631,8 +611,8 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 
 	put_cpu_var(grant_copy_op);
 	put_cpu_var(meta);
@@ -640,11 +620,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
-
-	skb_queue_tail(&netbk->rx_queue, skb);
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -742,21 +720,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -775,13 +752,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		int idx;
 		struct pending_tx_info *pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		gop->source.u.ref = txp->gref;
@@ -805,7 +782,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
@@ -813,8 +790,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = netbk->vif;
-
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -824,12 +799,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		idx = netbk->mmap_pages[index];
+		index = pending_index(vif->pending_prod++);
+		idx = vif->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -846,16 +821,16 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -863,10 +838,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -877,7 +852,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -893,11 +868,11 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
@@ -905,7 +880,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1066,15 +1041,14 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 					struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1142,8 +1116,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1173,7 +1147,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1193,7 +1167,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 
 		gop++;
 
-		pool_idx = netbk->mmap_pages[pending_idx];
+		pool_idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(pool_idx);
 
 		memcpy(&pending_tx_info->req,
@@ -1213,11 +1187,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1235,17 +1209,16 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 	return gop - tco;
 }
 
-static int xen_netbk_tx_submit(struct xen_netbk *netbk,
-				struct gnttab_copy *tco,
-				int budget)
+static int xen_netbk_tx_submit(struct xenvif *vif,
+			       struct gnttab_copy *tco,
+			       int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 	int work_done = 0;
 
 	while ((work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
@@ -1254,13 +1227,13 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		pending_idx = *((u16 *)skb->data);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1269,7 +1242,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1277,7 +1250,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1285,7 +1258,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1319,7 +1292,7 @@ static int xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
+int xen_netbk_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
@@ -1327,7 +1300,7 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 	struct gnttab_copy *tco;
 	static int unusable_count;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return 0;
 
 	tco = get_cpu_var(tx_copy_ops);
@@ -1340,13 +1313,13 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 				 " is not usable,"
 				 " not doing any RX work for vif%u.%u\n",
 				 smp_processor_id(),
-				 netbk->vif->domid, netbk->vif->handle);
+				 vif->domid, vif->handle);
 			unusable_count = 0;
 		}
 		return -ENOMEM;
 	}
 
-	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+	nr_gops = xen_netbk_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_var(tx_copy_ops);
@@ -1357,35 +1330,34 @@ int xen_netbk_tx_action(struct xen_netbk *netbk, int budget)
 					tco, nr_gops);
 	BUG_ON(ret);
 
-	work_done = xen_netbk_tx_submit(netbk, tco, budget);
+	work_done = xen_netbk_tx_submit(vif, tco, budget);
 
 	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	idx = netbk->mmap_pages[pending_idx];
+	idx = vif->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1432,15 +1404,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1491,54 +1463,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		pr_alert(DRV_NAME "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 294f48b..ce00a93 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -102,7 +102,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -118,7 +118,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -131,7 +131,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -174,9 +174,9 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
 
 struct pending_tx_info *to_txinfo(int idx)
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 572b037..efae17c 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -27,7 +27,10 @@
 #ifndef __PAGE_POOL_H__
 #define __PAGE_POOL_H__
 
-#include "common.h"
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
 
 typedef uint32_t idx_t;
 
@@ -38,8 +41,8 @@ struct page_pool_entry {
 	struct page *page;
 	struct pending_tx_info tx_info;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -52,12 +55,12 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
 struct page            *to_page(int idx);
-struct xen_netbk       *to_netbk(int idx);
+struct xenvif          *to_vif(int idx);
 struct pending_tx_info *to_txinfo(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rszr5-0002Vk-Lh; Thu, 02 Feb 2012 16:49:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr4-0002PY-Hd
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328201377!13178025!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27150 invoked from network); 2 Feb 2012 16:49:43 -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;
	2 Feb 2012 16:49:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157211"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:35 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPt008442;
	Thu, 2 Feb 2012 08:49:34 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:18 +0000
Message-ID: <1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend interface to
	support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/xenbus/xenbus_client.c |  282 +++++++++++++++++++++++++-----------
 include/xen/xenbus.h               |   15 ++-
 2 files changed, 206 insertions(+), 91 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 566d2ad..d73b9c6 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -53,14 +53,16 @@ struct xenbus_map_node {
 		struct vm_struct *area; /* PV */
 		struct page *page;     /* HVM */
 	};
-	grant_handle_t handle;
+	grant_handle_t handle[XENBUS_MAX_RING_PAGES];
+	unsigned int   nr_handles;
 };
 
 static DEFINE_SPINLOCK(xenbus_valloc_lock);
 static LIST_HEAD(xenbus_valloc_pages);
 
 struct xenbus_ring_ops {
-	int (*map)(struct xenbus_device *dev, int gnt, void **vaddr);
+	int (*map)(struct xenbus_device *dev, int gnt[], int nr_gnts,
+		   void **vaddr);
 	int (*unmap)(struct xenbus_device *dev, void *vaddr);
 };
 
@@ -356,17 +358,38 @@ static void xenbus_switch_fatal(struct xenbus_device *dev, int depth, int err,
 /**
  * xenbus_grant_ring
  * @dev: xenbus device
- * @ring_mfn: mfn of ring to grant
-
- * Grant access to the given @ring_mfn to the peer of the given device.  Return
- * 0 on success, or -errno on error.  On error, the device will switch to
- * XenbusStateClosing, and the error will be saved in the store.
+ * @vaddr: starting virtual address of the ring
+ * @nr_pages: number of page to be granted
+ * @grefs: grant reference array to be filled in
+ * Grant access to the given @vaddr to the peer of the given device.
+ * Then fill in @grefs with grant references.  Return 0 on success, or
+ * -errno on error.  On error, the device will switch to
+ * XenbusStateClosing, and the first error will be saved in the store.
  */
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn)
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_pages, int grefs[])
 {
-	int err = gnttab_grant_foreign_access(dev->otherend_id, ring_mfn, 0);
-	if (err < 0)
-		xenbus_dev_fatal(dev, err, "granting access to ring page");
+	int i;
+	int err;
+
+	for (i = 0; i < nr_pages; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		err = gnttab_grant_foreign_access(dev->otherend_id,
+						  virt_to_mfn(addr), 0);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err,
+					 "granting access to ring page");
+			goto fail;
+		}
+		grefs[i] = err;
+	}
+
+	return 0;
+
+fail:
+	for ( ; i >= 0; i--)
+		gnttab_end_foreign_access_ref(grefs[i], 0);
 	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_grant_ring);
@@ -447,7 +470,8 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 /**
  * xenbus_map_ring_valloc
  * @dev: xenbus device
- * @gnt_ref: grant reference
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant reference
  * @vaddr: pointer to address to be filled out by mapping
  *
  * Based on Rusty Russell's skeleton driver's map_page.
@@ -458,52 +482,74 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
  * or -ENOMEM on error. If an error is returned, device will switch to
  * XenbusStateClosing and the error message will be saved in XenStore.
  */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref[],
+			   int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_ref, vaddr);
+	return ring_ops->map(dev, gnt_ref, nr_grefs, vaddr);
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
+static int __xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev,
+					struct xenbus_map_node *node);
+
 static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
-				     int gnt_ref, void **vaddr)
+				     int gnt_ref[], int nr_grefs, void **vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
-		.ref   = gnt_ref,
-		.dom   = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op[XENBUS_MAX_RING_PAGES];
 	struct xenbus_map_node *node;
 	struct vm_struct *area;
-	pte_t *pte;
+	pte_t *pte[XENBUS_MAX_RING_PAGES];
+	int i;
+	int err = 0;
 
 	*vaddr = NULL;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	area = alloc_vm_area(PAGE_SIZE, &pte);
+	area = alloc_vm_area(PAGE_SIZE * nr_grefs, pte);
 	if (!area) {
 		kfree(node);
 		return -ENOMEM;
 	}
 
-	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
+	for (i = 0; i < nr_grefs; i++) {
+		op[i].flags = GNTMAP_host_map | GNTMAP_contains_pte,
+		op[i].ref   = gnt_ref[i],
+		op[i].dom   = dev->otherend_id,
+		op[i].host_addr = arbitrary_virt_to_machine(pte[i]).maddr;
+	};
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, op, nr_grefs))
 		BUG();
 
-	if (op.status != GNTST_okay) {
-		free_vm_area(area);
-		kfree(node);
-		xenbus_dev_fatal(dev, op.status,
+	node->nr_handles = nr_grefs;
+	node->area = area;
+
+	for (i = 0; i < nr_grefs; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			node->handle[i] = INVALID_GRANT_HANDLE;
+			continue;
+		}
+		node->handle[i] = op[i].handle;
+	}
+
+	if (err != 0) {
+		for (i = 0; i < nr_grefs; i++)
+			xenbus_dev_fatal(dev, op[i].status,
 				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-		return op.status;
+				 gnt_ref[i], dev->otherend_id);
+
+		__xenbus_unmap_ring_vfree_pv(dev, node);
+
+		return err;
 	}
 
-	node->handle = op.handle;
-	node->area = area;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_add(&node->next, &xenbus_valloc_pages);
@@ -514,28 +560,34 @@ static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
 }
 
 static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
-				      int gnt_ref, void **vaddr)
+				      int gnt_ref[], int nr_grefs, void **vaddr)
 {
 	struct xenbus_map_node *node;
 	int err;
 	void *addr;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	*vaddr = NULL;
 
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	err = alloc_xenballooned_pages(nr_grefs, &node->page,
+				       false /* lowmem */);
 	if (err)
 		goto out_err;
 
 	addr = pfn_to_kaddr(page_to_pfn(node->page));
 
-	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	err = xenbus_map_ring(dev, gnt_ref, nr_grefs, node->handle, addr);
 	if (err)
 		goto out_err;
 
+	node->nr_handles = nr_grefs;
+
 	spin_lock(&xenbus_valloc_lock);
 	list_add(&node->next, &xenbus_valloc_pages);
 	spin_unlock(&xenbus_valloc_lock);
@@ -544,7 +596,7 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 	return 0;
 
  out_err:
-	free_xenballooned_pages(1, &node->page);
+	free_xenballooned_pages(nr_grefs, &node->page);
 	kfree(node);
 	return err;
 }
@@ -553,36 +605,52 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 /**
  * xenbus_map_ring
  * @dev: xenbus device
- * @gnt_ref: grant reference
- * @handle: pointer to grant handle to be filled
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant reference
+ * @handle: pointer to grant handle array to be filled, mind the size
  * @vaddr: address to be mapped to
  *
- * Map a page of memory into this domain from another domain's grant table.
+ * Map pages of memory into this domain from another domain's grant table.
  * xenbus_map_ring does not allocate the virtual address space (you must do
- * this yourself!). It only maps in the page to the specified address.
+ * this yourself!). It only maps in the pages to the specified address.
  * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
  * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
+ * XenbusStateClosing and the last error message will be saved in XenStore.
  */
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-		    grant_handle_t *handle, void *vaddr)
+int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref[], int nr_grefs,
+		    grant_handle_t handle[], void *vaddr)
 {
-	struct gnttab_map_grant_ref op;
-
-	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
-			  dev->otherend_id);
+	struct gnttab_map_grant_ref op[XENBUS_MAX_RING_PAGES];
+	int i;
+	int err = GNTST_okay;	/* 0 */
+
+	for (i = 0; i < nr_grefs; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		gnttab_set_map_op(&op[i], (phys_addr_t)addr,
+				  GNTMAP_host_map, gnt_ref[i],
+				  dev->otherend_id);
+	}
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, op, nr_grefs))
 		BUG();
 
-	if (op.status != GNTST_okay) {
-		xenbus_dev_fatal(dev, op.status,
+
+	for (i = 0; i < nr_grefs; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			xenbus_dev_fatal(dev, err,
 				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-	} else
-		*handle = op.handle;
+				 gnt_ref[i], dev->otherend_id);
+			handle[i] = INVALID_GRANT_HANDLE;
+		} else
+			handle[i] = op[i].handle;
+	}
+
+	if (err != GNTST_okay)
+		xenbus_unmap_ring(dev, handle, nr_grefs, vaddr);
 
-	return op.status;
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
@@ -605,13 +673,53 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 }
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int __xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev,
+					struct xenbus_map_node *node)
+{
+	struct gnttab_unmap_grant_ref op[XENBUS_MAX_RING_PAGES];
+	unsigned int level;
+	int i, j;
+	int err = GNTST_okay;
+
+	j = 0;
+	for (i = 0; i < node->nr_handles; i++) {
+		unsigned long vaddr = (unsigned long)node->area->addr +
+			(PAGE_SIZE * i);
+		if (node->handle[i] != INVALID_GRANT_HANDLE) {
+			memset(&op[j], 0, sizeof(op[0]));
+			op[j].host_addr = arbitrary_virt_to_machine(
+				lookup_address(vaddr, &level)).maddr;
+			op[j].handle = node->handle[i];
+			j++;
+			node->handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
+
+	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, j))
+		BUG();
+
+	node->nr_handles = 0;
+
+	for (i = 0; i < j; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			xenbus_dev_error(dev, err,
+				 "unmapping page %d at handle %d error %d",
+				 i, op[i].handle, err);
+		}
+	}
+
+	if (err == GNTST_okay)
+		free_vm_area(node->area);
+
+	kfree(node);
+
+	return err;
+}
+
 static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct xenbus_map_node *node;
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-	};
-	unsigned int level;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_for_each_entry(node, &xenbus_valloc_pages, next) {
@@ -630,29 +738,14 @@ static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = node->handle;
-	op.host_addr = arbitrary_virt_to_machine(
-		lookup_address((unsigned long)vaddr, &level)).maddr;
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
-		BUG();
-
-	if (op.status == GNTST_okay)
-		free_vm_area(node->area);
-	else
-		xenbus_dev_error(dev, op.status,
-				 "unmapping page at handle %d error %d",
-				 node->handle, op.status);
-
-	kfree(node);
-	return op.status;
+	return __xenbus_unmap_ring_vfree_pv(dev, node);
 }
 
 static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 {
 	int rv;
 	struct xenbus_map_node *node;
-	void *addr;
+	void *addr = NULL;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_for_each_entry(node, &xenbus_valloc_pages, next) {
@@ -672,10 +765,10 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	rv = xenbus_unmap_ring(dev, node->handle, addr);
+	rv = xenbus_unmap_ring(dev, node->handle, node->nr_handles, addr);
 
 	if (!rv)
-		free_xenballooned_pages(1, &node->page);
+		free_xenballooned_pages(node->nr_handles, &node->page);
 	else
 		WARN(1, "Leaking %p\n", vaddr);
 
@@ -687,6 +780,7 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
  * xenbus_unmap_ring
  * @dev: xenbus device
  * @handle: grant handle
+ * @nr_handles: number of grant handle
  * @vaddr: addr to unmap
  *
  * Unmap a page of memory in this domain that was imported from another domain.
@@ -694,21 +788,37 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
  * (see xen/include/interface/grant_table.h).
  */
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr)
+		      grant_handle_t handle[], int nr_handles,
+		      void *vaddr)
 {
-	struct gnttab_unmap_grant_ref op;
-
-	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
+	struct gnttab_unmap_grant_ref op[XENBUS_MAX_RING_PAGES];
+	int i, j;
+	int err = GNTST_okay;
+
+	j = 0;
+	for (i = 0; i < nr_handles; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		if (handle[i] != INVALID_GRANT_HANDLE) {
+			gnttab_set_unmap_op(&op[j++], (phys_addr_t)addr,
+					    GNTMAP_host_map, handle[i]);
+			handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, j))
 		BUG();
 
-	if (op.status != GNTST_okay)
-		xenbus_dev_error(dev, op.status,
+	for (i = 0; i < j; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			xenbus_dev_error(dev, err,
 				 "unmapping page at handle %d error %d",
-				 handle, op.status);
+				 handle[i], err);
+		}
+	}
 
-	return op.status;
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring);
 
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index e8c599b..284647f 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -46,6 +46,10 @@
 #include <xen/interface/io/xenbus.h>
 #include <xen/interface/io/xs_wire.h>
 
+#define XENBUS_MAX_RING_PAGE_ORDER 2
+#define XENBUS_MAX_RING_PAGES      4
+#define INVALID_GRANT_HANDLE       (~0U)
+
 /* Register callback to watch this node. */
 struct xenbus_watch
 {
@@ -195,15 +199,16 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch,
 			 const char *pathfmt, ...);
 
 int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn);
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_pages, int grefs[]);
 int xenbus_map_ring_valloc(struct xenbus_device *dev,
-			   int gnt_ref, void **vaddr);
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-			   grant_handle_t *handle, void *vaddr);
+			   int gnt_ref[], int nr_grefs, void **vaddr);
+int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref[], int nr_grefs,
+			   grant_handle_t handle[], void *vaddr);
 
 int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr);
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr);
+		      grant_handle_t handle[], int nr_handles, void *vaddr);
 
 int xenbus_alloc_evtchn(struct xenbus_device *dev, int *port);
 int xenbus_bind_evtchn(struct xenbus_device *dev, int remote_port, int *port);
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rszr5-0002Vk-Lh; Thu, 02 Feb 2012 16:49:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr4-0002PY-Hd
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328201377!13178025!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27150 invoked from network); 2 Feb 2012 16:49:43 -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;
	2 Feb 2012 16:49:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157211"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:35 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPt008442;
	Thu, 2 Feb 2012 08:49:34 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:18 +0000
Message-ID: <1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend interface to
	support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/xenbus/xenbus_client.c |  282 +++++++++++++++++++++++++-----------
 include/xen/xenbus.h               |   15 ++-
 2 files changed, 206 insertions(+), 91 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 566d2ad..d73b9c6 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -53,14 +53,16 @@ struct xenbus_map_node {
 		struct vm_struct *area; /* PV */
 		struct page *page;     /* HVM */
 	};
-	grant_handle_t handle;
+	grant_handle_t handle[XENBUS_MAX_RING_PAGES];
+	unsigned int   nr_handles;
 };
 
 static DEFINE_SPINLOCK(xenbus_valloc_lock);
 static LIST_HEAD(xenbus_valloc_pages);
 
 struct xenbus_ring_ops {
-	int (*map)(struct xenbus_device *dev, int gnt, void **vaddr);
+	int (*map)(struct xenbus_device *dev, int gnt[], int nr_gnts,
+		   void **vaddr);
 	int (*unmap)(struct xenbus_device *dev, void *vaddr);
 };
 
@@ -356,17 +358,38 @@ static void xenbus_switch_fatal(struct xenbus_device *dev, int depth, int err,
 /**
  * xenbus_grant_ring
  * @dev: xenbus device
- * @ring_mfn: mfn of ring to grant
-
- * Grant access to the given @ring_mfn to the peer of the given device.  Return
- * 0 on success, or -errno on error.  On error, the device will switch to
- * XenbusStateClosing, and the error will be saved in the store.
+ * @vaddr: starting virtual address of the ring
+ * @nr_pages: number of page to be granted
+ * @grefs: grant reference array to be filled in
+ * Grant access to the given @vaddr to the peer of the given device.
+ * Then fill in @grefs with grant references.  Return 0 on success, or
+ * -errno on error.  On error, the device will switch to
+ * XenbusStateClosing, and the first error will be saved in the store.
  */
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn)
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_pages, int grefs[])
 {
-	int err = gnttab_grant_foreign_access(dev->otherend_id, ring_mfn, 0);
-	if (err < 0)
-		xenbus_dev_fatal(dev, err, "granting access to ring page");
+	int i;
+	int err;
+
+	for (i = 0; i < nr_pages; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		err = gnttab_grant_foreign_access(dev->otherend_id,
+						  virt_to_mfn(addr), 0);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err,
+					 "granting access to ring page");
+			goto fail;
+		}
+		grefs[i] = err;
+	}
+
+	return 0;
+
+fail:
+	for ( ; i >= 0; i--)
+		gnttab_end_foreign_access_ref(grefs[i], 0);
 	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_grant_ring);
@@ -447,7 +470,8 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 /**
  * xenbus_map_ring_valloc
  * @dev: xenbus device
- * @gnt_ref: grant reference
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant reference
  * @vaddr: pointer to address to be filled out by mapping
  *
  * Based on Rusty Russell's skeleton driver's map_page.
@@ -458,52 +482,74 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
  * or -ENOMEM on error. If an error is returned, device will switch to
  * XenbusStateClosing and the error message will be saved in XenStore.
  */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref[],
+			   int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_ref, vaddr);
+	return ring_ops->map(dev, gnt_ref, nr_grefs, vaddr);
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
+static int __xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev,
+					struct xenbus_map_node *node);
+
 static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
-				     int gnt_ref, void **vaddr)
+				     int gnt_ref[], int nr_grefs, void **vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
-		.ref   = gnt_ref,
-		.dom   = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op[XENBUS_MAX_RING_PAGES];
 	struct xenbus_map_node *node;
 	struct vm_struct *area;
-	pte_t *pte;
+	pte_t *pte[XENBUS_MAX_RING_PAGES];
+	int i;
+	int err = 0;
 
 	*vaddr = NULL;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	area = alloc_vm_area(PAGE_SIZE, &pte);
+	area = alloc_vm_area(PAGE_SIZE * nr_grefs, pte);
 	if (!area) {
 		kfree(node);
 		return -ENOMEM;
 	}
 
-	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
+	for (i = 0; i < nr_grefs; i++) {
+		op[i].flags = GNTMAP_host_map | GNTMAP_contains_pte,
+		op[i].ref   = gnt_ref[i],
+		op[i].dom   = dev->otherend_id,
+		op[i].host_addr = arbitrary_virt_to_machine(pte[i]).maddr;
+	};
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, op, nr_grefs))
 		BUG();
 
-	if (op.status != GNTST_okay) {
-		free_vm_area(area);
-		kfree(node);
-		xenbus_dev_fatal(dev, op.status,
+	node->nr_handles = nr_grefs;
+	node->area = area;
+
+	for (i = 0; i < nr_grefs; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			node->handle[i] = INVALID_GRANT_HANDLE;
+			continue;
+		}
+		node->handle[i] = op[i].handle;
+	}
+
+	if (err != 0) {
+		for (i = 0; i < nr_grefs; i++)
+			xenbus_dev_fatal(dev, op[i].status,
 				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-		return op.status;
+				 gnt_ref[i], dev->otherend_id);
+
+		__xenbus_unmap_ring_vfree_pv(dev, node);
+
+		return err;
 	}
 
-	node->handle = op.handle;
-	node->area = area;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_add(&node->next, &xenbus_valloc_pages);
@@ -514,28 +560,34 @@ static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
 }
 
 static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
-				      int gnt_ref, void **vaddr)
+				      int gnt_ref[], int nr_grefs, void **vaddr)
 {
 	struct xenbus_map_node *node;
 	int err;
 	void *addr;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	*vaddr = NULL;
 
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	err = alloc_xenballooned_pages(nr_grefs, &node->page,
+				       false /* lowmem */);
 	if (err)
 		goto out_err;
 
 	addr = pfn_to_kaddr(page_to_pfn(node->page));
 
-	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	err = xenbus_map_ring(dev, gnt_ref, nr_grefs, node->handle, addr);
 	if (err)
 		goto out_err;
 
+	node->nr_handles = nr_grefs;
+
 	spin_lock(&xenbus_valloc_lock);
 	list_add(&node->next, &xenbus_valloc_pages);
 	spin_unlock(&xenbus_valloc_lock);
@@ -544,7 +596,7 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 	return 0;
 
  out_err:
-	free_xenballooned_pages(1, &node->page);
+	free_xenballooned_pages(nr_grefs, &node->page);
 	kfree(node);
 	return err;
 }
@@ -553,36 +605,52 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 /**
  * xenbus_map_ring
  * @dev: xenbus device
- * @gnt_ref: grant reference
- * @handle: pointer to grant handle to be filled
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant reference
+ * @handle: pointer to grant handle array to be filled, mind the size
  * @vaddr: address to be mapped to
  *
- * Map a page of memory into this domain from another domain's grant table.
+ * Map pages of memory into this domain from another domain's grant table.
  * xenbus_map_ring does not allocate the virtual address space (you must do
- * this yourself!). It only maps in the page to the specified address.
+ * this yourself!). It only maps in the pages to the specified address.
  * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
  * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
+ * XenbusStateClosing and the last error message will be saved in XenStore.
  */
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-		    grant_handle_t *handle, void *vaddr)
+int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref[], int nr_grefs,
+		    grant_handle_t handle[], void *vaddr)
 {
-	struct gnttab_map_grant_ref op;
-
-	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
-			  dev->otherend_id);
+	struct gnttab_map_grant_ref op[XENBUS_MAX_RING_PAGES];
+	int i;
+	int err = GNTST_okay;	/* 0 */
+
+	for (i = 0; i < nr_grefs; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		gnttab_set_map_op(&op[i], (phys_addr_t)addr,
+				  GNTMAP_host_map, gnt_ref[i],
+				  dev->otherend_id);
+	}
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, op, nr_grefs))
 		BUG();
 
-	if (op.status != GNTST_okay) {
-		xenbus_dev_fatal(dev, op.status,
+
+	for (i = 0; i < nr_grefs; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			xenbus_dev_fatal(dev, err,
 				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-	} else
-		*handle = op.handle;
+				 gnt_ref[i], dev->otherend_id);
+			handle[i] = INVALID_GRANT_HANDLE;
+		} else
+			handle[i] = op[i].handle;
+	}
+
+	if (err != GNTST_okay)
+		xenbus_unmap_ring(dev, handle, nr_grefs, vaddr);
 
-	return op.status;
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
@@ -605,13 +673,53 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 }
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int __xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev,
+					struct xenbus_map_node *node)
+{
+	struct gnttab_unmap_grant_ref op[XENBUS_MAX_RING_PAGES];
+	unsigned int level;
+	int i, j;
+	int err = GNTST_okay;
+
+	j = 0;
+	for (i = 0; i < node->nr_handles; i++) {
+		unsigned long vaddr = (unsigned long)node->area->addr +
+			(PAGE_SIZE * i);
+		if (node->handle[i] != INVALID_GRANT_HANDLE) {
+			memset(&op[j], 0, sizeof(op[0]));
+			op[j].host_addr = arbitrary_virt_to_machine(
+				lookup_address(vaddr, &level)).maddr;
+			op[j].handle = node->handle[i];
+			j++;
+			node->handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
+
+	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, j))
+		BUG();
+
+	node->nr_handles = 0;
+
+	for (i = 0; i < j; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			xenbus_dev_error(dev, err,
+				 "unmapping page %d at handle %d error %d",
+				 i, op[i].handle, err);
+		}
+	}
+
+	if (err == GNTST_okay)
+		free_vm_area(node->area);
+
+	kfree(node);
+
+	return err;
+}
+
 static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct xenbus_map_node *node;
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-	};
-	unsigned int level;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_for_each_entry(node, &xenbus_valloc_pages, next) {
@@ -630,29 +738,14 @@ static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = node->handle;
-	op.host_addr = arbitrary_virt_to_machine(
-		lookup_address((unsigned long)vaddr, &level)).maddr;
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
-		BUG();
-
-	if (op.status == GNTST_okay)
-		free_vm_area(node->area);
-	else
-		xenbus_dev_error(dev, op.status,
-				 "unmapping page at handle %d error %d",
-				 node->handle, op.status);
-
-	kfree(node);
-	return op.status;
+	return __xenbus_unmap_ring_vfree_pv(dev, node);
 }
 
 static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 {
 	int rv;
 	struct xenbus_map_node *node;
-	void *addr;
+	void *addr = NULL;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_for_each_entry(node, &xenbus_valloc_pages, next) {
@@ -672,10 +765,10 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	rv = xenbus_unmap_ring(dev, node->handle, addr);
+	rv = xenbus_unmap_ring(dev, node->handle, node->nr_handles, addr);
 
 	if (!rv)
-		free_xenballooned_pages(1, &node->page);
+		free_xenballooned_pages(node->nr_handles, &node->page);
 	else
 		WARN(1, "Leaking %p\n", vaddr);
 
@@ -687,6 +780,7 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
  * xenbus_unmap_ring
  * @dev: xenbus device
  * @handle: grant handle
+ * @nr_handles: number of grant handle
  * @vaddr: addr to unmap
  *
  * Unmap a page of memory in this domain that was imported from another domain.
@@ -694,21 +788,37 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
  * (see xen/include/interface/grant_table.h).
  */
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr)
+		      grant_handle_t handle[], int nr_handles,
+		      void *vaddr)
 {
-	struct gnttab_unmap_grant_ref op;
-
-	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
+	struct gnttab_unmap_grant_ref op[XENBUS_MAX_RING_PAGES];
+	int i, j;
+	int err = GNTST_okay;
+
+	j = 0;
+	for (i = 0; i < nr_handles; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		if (handle[i] != INVALID_GRANT_HANDLE) {
+			gnttab_set_unmap_op(&op[j++], (phys_addr_t)addr,
+					    GNTMAP_host_map, handle[i]);
+			handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, j))
 		BUG();
 
-	if (op.status != GNTST_okay)
-		xenbus_dev_error(dev, op.status,
+	for (i = 0; i < j; i++) {
+		if (op[i].status != GNTST_okay) {
+			err = op[i].status;
+			xenbus_dev_error(dev, err,
 				 "unmapping page at handle %d error %d",
-				 handle, op.status);
+				 handle[i], err);
+		}
+	}
 
-	return op.status;
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring);
 
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index e8c599b..284647f 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -46,6 +46,10 @@
 #include <xen/interface/io/xenbus.h>
 #include <xen/interface/io/xs_wire.h>
 
+#define XENBUS_MAX_RING_PAGE_ORDER 2
+#define XENBUS_MAX_RING_PAGES      4
+#define INVALID_GRANT_HANDLE       (~0U)
+
 /* Register callback to watch this node. */
 struct xenbus_watch
 {
@@ -195,15 +199,16 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch,
 			 const char *pathfmt, ...);
 
 int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn);
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_pages, int grefs[]);
 int xenbus_map_ring_valloc(struct xenbus_device *dev,
-			   int gnt_ref, void **vaddr);
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-			   grant_handle_t *handle, void *vaddr);
+			   int gnt_ref[], int nr_grefs, void **vaddr);
+int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref[], int nr_grefs,
+			   grant_handle_t handle[], void *vaddr);
 
 int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr);
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr);
+		      grant_handle_t handle[], int nr_handles, void *vaddr);
 
 int xenbus_alloc_evtchn(struct xenbus_device *dev, int *port);
 int xenbus_bind_evtchn(struct xenbus_device *dev, int remote_port, int *port);
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rszr7-0002XD-8e; Thu, 02 Feb 2012 16:49:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr5-0002Ps-0n
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328201382!13466188!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9694 invoked from network); 2 Feb 2012 16:49:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157218"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:38 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPv008442;
	Thu, 2 Feb 2012 08:49:37 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:20 +0000
Message-ID: <1328201363-13915-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 10/13] netback: multi page ring support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Extend netback to support multi page ring.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   35 +++++++---
 drivers/net/xen-netback/interface.c |   43 ++++++++++--
 drivers/net/xen-netback/netback.c   |   74 ++++++++------------
 drivers/net/xen-netback/xenbus.c    |  129 +++++++++++++++++++++++++++++++++--
 4 files changed, 213 insertions(+), 68 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index b7d4442..1bb16ec 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -59,10 +59,18 @@ struct xenvif_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define NETBK_TX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
+#define NETBK_RX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
 
-#define MAX_PENDING_REQS 256
+#define NETBK_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
+#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
+
+#define NETBK_MAX_TX_RING_SIZE NETBK_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
+#define NETBK_MAX_RX_RING_SIZE NETBK_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
+
+#define MAX_PENDING_REQS NETBK_MAX_TX_RING_SIZE
 
 struct xenvif {
 	/* Unique identifier for this interface. */
@@ -83,6 +91,8 @@ struct xenvif {
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
+	int nr_tx_handles;
+	int nr_rx_handles;
 
 	/* Frontend feature information. */
 	u8 can_sg:1;
@@ -132,8 +142,10 @@ struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn);
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
+		   unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -146,10 +158,12 @@ int xenvif_rx_ring_full(struct xenvif *vif);
 int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif *vif);
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_ring(struct xenvif *vif, void *addr);
+int xenvif_map_frontend_ring(struct xenvif *vif,
+			     void **vaddr,
+			     int domid,
+			     int ring_ref[],
+			     unsigned int  ring_ref_count);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_check_rx_xenvif(struct xenvif *vif);
@@ -167,4 +181,7 @@ void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
 
+extern unsigned int MODPARM_netback_max_tx_ring_page_order;
+extern unsigned int MODPARM_netback_max_rx_ring_page_order;
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b2bde8f..e1aa003 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -319,10 +319,16 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn)
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
+		   unsigned int evtchn)
 {
 	int err = -ENOMEM;
+	void *addr;
+	struct xen_netif_tx_sring *txs;
+	struct xen_netif_rx_sring *rxs;
+	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -330,15 +336,33 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
-	if (err < 0)
+	for (i = 0; i < tx_ring_ref_count; i++)
+		tmp[i] = tx_ring_ref[i];
+
+	err = xenvif_map_frontend_ring(vif, &addr, vif->domid,
+				       tmp, tx_ring_ref_count);
+	if (err)
 		goto err;
+	txs = addr;
+	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE * tx_ring_ref_count);
+	vif->nr_tx_handles = tx_ring_ref_count;
+
+	for (i = 0; i < rx_ring_ref_count; i++)
+		tmp[i] = rx_ring_ref[i];
+
+	err = xenvif_map_frontend_ring(vif, &addr, vif->domid,
+					tmp, rx_ring_ref_count);
+	if (err)
+		goto err_tx_unmap;
+	rxs = addr;
+	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
+	vif->nr_rx_handles = rx_ring_ref_count;
 
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
 		vif->dev->name, vif);
 	if (err < 0)
-		goto err_unmap;
+		goto err_rx_unmap;
 	vif->irq = err;
 	disable_irq(vif->irq);
 
@@ -366,8 +390,10 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	return 0;
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
-err_unmap:
-	xenvif_unmap_frontend_rings(vif);
+err_rx_unmap:
+	xenvif_unmap_frontend_ring(vif, (void *)vif->tx.sring);
+err_tx_unmap:
+	xenvif_unmap_frontend_ring(vif, (void *)vif->rx.sring);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -400,7 +426,8 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xenvif_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_ring(vif, (void *)vif->tx.sring);
+	xenvif_unmap_frontend_ring(vif, (void *)vif->rx.sring);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index cb1a661..60c8951 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,6 +49,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_rx_ring_page_order,
+		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_ring_page_order,
+		 "Maximum supported receiver ring page order");
+
+unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_tx_ring_page_order,
+		   MODPARM_netback_max_tx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_tx_ring_page_order,
+		 "Maximum supported transmitter ring page order");
 
 DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
@@ -134,7 +145,8 @@ int xenvif_rx_ring_full(struct xenvif *vif)
 	RING_IDX needed = max_required_rx_slots(vif);
 
 	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
+	       ((vif->rx.rsp_prod_pvt +
+		 NETBK_RX_RING_SIZE(vif->nr_rx_handles) - peek) < needed);
 }
 
 int xenvif_must_stop_queue(struct xenvif *vif)
@@ -520,7 +532,8 @@ void xenvif_rx_action(struct xenvif *vif)
 		__skb_queue_tail(&rxq, skb);
 
 		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
+		if (count + MAX_SKB_FRAGS >=
+		    NETBK_RX_RING_SIZE(vif->nr_rx_handles))
 			break;
 	}
 
@@ -532,7 +545,7 @@ void xenvif_rx_action(struct xenvif *vif)
 		return;
 	}
 
-	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
@@ -1419,48 +1432,22 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xenvif_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_ring(struct xenvif *vif, void *addr)
 {
-	if (vif->tx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->tx.sring);
-	if (vif->rx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->rx.sring);
+	if (addr)
+		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), addr);
 }
 
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_ring(struct xenvif *vif,
+			      void **vaddr,
+			      int domid,
+			      int ring_ref[],
+			      unsigned int  ring_ref_count)
 {
-	void *addr;
-	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
-
-	int err = -ENOMEM;
+	int err = 0;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &tx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
-
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &rx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
-
-	vif->rx_req_cons_peek = 0;
-
-	return 0;
-
-err:
-	xenvif_unmap_frontend_rings(vif);
+				     ring_ref, ring_ref_count, vaddr);
 	return err;
 }
 
@@ -1486,7 +1473,6 @@ int xenvif_kthread(void *data)
 
 static int __create_percpu_scratch_space(unsigned int cpu)
 {
-	/* Guard against race condition */
 	if (per_cpu(tx_copy_ops, cpu) ||
 	    per_cpu(grant_copy_op, cpu) ||
 	    per_cpu(meta, cpu))
@@ -1502,19 +1488,19 @@ static int __create_percpu_scratch_space(unsigned int cpu)
 
 	per_cpu(grant_copy_op, cpu) =
 		vzalloc_node(sizeof(struct gnttab_copy)
-			     * 2 * XEN_NETIF_RX_RING_SIZE, cpu_to_node(cpu));
+			     * 2 * NETBK_MAX_RX_RING_SIZE, cpu_to_node(cpu));
 
 	if (!per_cpu(grant_copy_op, cpu))
 		per_cpu(grant_copy_op, cpu) =
 			vzalloc(sizeof(struct gnttab_copy)
-				* 2 * XEN_NETIF_RX_RING_SIZE);
+				* 2 * NETBK_MAX_RX_RING_SIZE);
 
 	per_cpu(meta, cpu) = vzalloc_node(sizeof(struct xenvif_rx_meta)
-					  * 2 * XEN_NETIF_RX_RING_SIZE,
+					  * 2 * NETBK_MAX_RX_RING_SIZE,
 					  cpu_to_node(cpu));
 	if (!per_cpu(meta, cpu))
 		per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
-					     * 2 * XEN_NETIF_RX_RING_SIZE);
+					     * 2 * NETBK_MAX_RX_RING_SIZE);
 
 	if (!per_cpu(tx_copy_ops, cpu) ||
 	    !per_cpu(grant_copy_op, cpu) ||
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index f1e89ca..79499fc 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -113,6 +113,23 @@ static int netback_probe(struct xenbus_device *dev,
 			message = "writing feature-rx-flip";
 			goto abort_transaction;
 		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-tx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_tx_ring_page_order);
+		if (err) {
+			message = "writing max-tx-ring-page-order";
+			goto abort_transaction;
+		}
+
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-rx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_rx_ring_page_order);
+		if (err) {
+			message = "writing max-rx-ring-page-order";
+			goto abort_transaction;
+		}
 
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
@@ -391,22 +408,108 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned long tx_ring_ref, rx_ring_ref;
 	unsigned int evtchn, rx_copy;
 	int err;
 	int val;
+	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned int  tx_ring_order;
+	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "tx-ring-ref", "%lu", &tx_ring_ref,
-			    "rx-ring-ref", "%lu", &rx_ring_ref,
 			    "event-channel", "%u", &evtchn, NULL);
 	if (err) {
 		xenbus_dev_fatal(dev, err,
-				 "reading %s/ring-ref and event-channel",
+				 "reading %s/event-channel",
 				 dev->otherend);
 		return err;
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
+			   &tx_ring_order);
+	if (err < 0) {
+		tx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
+				   &tx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/tx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << tx_ring_order); i++) {
+			char ring_ref_name[sizeof("tx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "tx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &tx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-order", "%u",
+			   &rx_ring_order);
+	if (err < 0) {
+		rx_ring_order = 0;
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-ref", "%lu",
+				   &rx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/rx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (rx_ring_order > MODPARM_netback_max_rx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/rx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << rx_ring_order); i++) {
+			char ring_ref_name[sizeof("rx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "rx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &rx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -453,11 +556,23 @@ static int connect_rings(struct backend_info *be)
 	vif->csum = !val;
 
 	/* Map the shared frame, irq etc. */
-	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
+	err = xenvif_connect(vif,
+			     tx_ring_ref, (1U << tx_ring_order),
+			     rx_ring_ref, (1U << rx_ring_order),
+			     evtchn);
 	if (err) {
+		int i;
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames %lu/%lu port %u",
-				 tx_ring_ref, rx_ring_ref, evtchn);
+				 "binding port %u",
+				 evtchn);
+		for (i = 0; i < (1U << tx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping tx ring handle: %lu",
+					 tx_ring_ref[i]);
+		for (i = 0; i < (1U << rx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping rx ring handle: %lu",
+					 tx_ring_ref[i]);
 		return err;
 	}
 	return 0;
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:49:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 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.xensource.com>)
	id 1Rszr7-0002XD-8e; Thu, 02 Feb 2012 16:49:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rszr5-0002Ps-0n
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328201382!13466188!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9694 invoked from network); 2 Feb 2012 16:49:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157218"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:38 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPv008442;
	Thu, 2 Feb 2012 08:49:37 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:20 +0000
Message-ID: <1328201363-13915-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 10/13] netback: multi page ring support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Extend netback to support multi page ring.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   35 +++++++---
 drivers/net/xen-netback/interface.c |   43 ++++++++++--
 drivers/net/xen-netback/netback.c   |   74 ++++++++------------
 drivers/net/xen-netback/xenbus.c    |  129 +++++++++++++++++++++++++++++++++--
 4 files changed, 213 insertions(+), 68 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index b7d4442..1bb16ec 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -59,10 +59,18 @@ struct xenvif_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define NETBK_TX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
+#define NETBK_RX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
 
-#define MAX_PENDING_REQS 256
+#define NETBK_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
+#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
+
+#define NETBK_MAX_TX_RING_SIZE NETBK_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
+#define NETBK_MAX_RX_RING_SIZE NETBK_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
+
+#define MAX_PENDING_REQS NETBK_MAX_TX_RING_SIZE
 
 struct xenvif {
 	/* Unique identifier for this interface. */
@@ -83,6 +91,8 @@ struct xenvif {
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
+	int nr_tx_handles;
+	int nr_rx_handles;
 
 	/* Frontend feature information. */
 	u8 can_sg:1;
@@ -132,8 +142,10 @@ struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn);
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
+		   unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -146,10 +158,12 @@ int xenvif_rx_ring_full(struct xenvif *vif);
 int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif *vif);
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_ring(struct xenvif *vif, void *addr);
+int xenvif_map_frontend_ring(struct xenvif *vif,
+			     void **vaddr,
+			     int domid,
+			     int ring_ref[],
+			     unsigned int  ring_ref_count);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_check_rx_xenvif(struct xenvif *vif);
@@ -167,4 +181,7 @@ void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
 
+extern unsigned int MODPARM_netback_max_tx_ring_page_order;
+extern unsigned int MODPARM_netback_max_rx_ring_page_order;
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b2bde8f..e1aa003 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -319,10 +319,16 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn)
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
+		   unsigned int evtchn)
 {
 	int err = -ENOMEM;
+	void *addr;
+	struct xen_netif_tx_sring *txs;
+	struct xen_netif_rx_sring *rxs;
+	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -330,15 +336,33 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
-	if (err < 0)
+	for (i = 0; i < tx_ring_ref_count; i++)
+		tmp[i] = tx_ring_ref[i];
+
+	err = xenvif_map_frontend_ring(vif, &addr, vif->domid,
+				       tmp, tx_ring_ref_count);
+	if (err)
 		goto err;
+	txs = addr;
+	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE * tx_ring_ref_count);
+	vif->nr_tx_handles = tx_ring_ref_count;
+
+	for (i = 0; i < rx_ring_ref_count; i++)
+		tmp[i] = rx_ring_ref[i];
+
+	err = xenvif_map_frontend_ring(vif, &addr, vif->domid,
+					tmp, rx_ring_ref_count);
+	if (err)
+		goto err_tx_unmap;
+	rxs = addr;
+	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
+	vif->nr_rx_handles = rx_ring_ref_count;
 
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
 		vif->dev->name, vif);
 	if (err < 0)
-		goto err_unmap;
+		goto err_rx_unmap;
 	vif->irq = err;
 	disable_irq(vif->irq);
 
@@ -366,8 +390,10 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	return 0;
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
-err_unmap:
-	xenvif_unmap_frontend_rings(vif);
+err_rx_unmap:
+	xenvif_unmap_frontend_ring(vif, (void *)vif->tx.sring);
+err_tx_unmap:
+	xenvif_unmap_frontend_ring(vif, (void *)vif->rx.sring);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -400,7 +426,8 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xenvif_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_ring(vif, (void *)vif->tx.sring);
+	xenvif_unmap_frontend_ring(vif, (void *)vif->rx.sring);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index cb1a661..60c8951 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,6 +49,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_rx_ring_page_order,
+		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_ring_page_order,
+		 "Maximum supported receiver ring page order");
+
+unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_tx_ring_page_order,
+		   MODPARM_netback_max_tx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_tx_ring_page_order,
+		 "Maximum supported transmitter ring page order");
 
 DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
@@ -134,7 +145,8 @@ int xenvif_rx_ring_full(struct xenvif *vif)
 	RING_IDX needed = max_required_rx_slots(vif);
 
 	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
+	       ((vif->rx.rsp_prod_pvt +
+		 NETBK_RX_RING_SIZE(vif->nr_rx_handles) - peek) < needed);
 }
 
 int xenvif_must_stop_queue(struct xenvif *vif)
@@ -520,7 +532,8 @@ void xenvif_rx_action(struct xenvif *vif)
 		__skb_queue_tail(&rxq, skb);
 
 		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
+		if (count + MAX_SKB_FRAGS >=
+		    NETBK_RX_RING_SIZE(vif->nr_rx_handles))
 			break;
 	}
 
@@ -532,7 +545,7 @@ void xenvif_rx_action(struct xenvif *vif)
 		return;
 	}
 
-	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
@@ -1419,48 +1432,22 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xenvif_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_ring(struct xenvif *vif, void *addr)
 {
-	if (vif->tx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->tx.sring);
-	if (vif->rx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->rx.sring);
+	if (addr)
+		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), addr);
 }
 
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_ring(struct xenvif *vif,
+			      void **vaddr,
+			      int domid,
+			      int ring_ref[],
+			      unsigned int  ring_ref_count)
 {
-	void *addr;
-	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
-
-	int err = -ENOMEM;
+	int err = 0;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &tx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
-
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &rx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
-
-	vif->rx_req_cons_peek = 0;
-
-	return 0;
-
-err:
-	xenvif_unmap_frontend_rings(vif);
+				     ring_ref, ring_ref_count, vaddr);
 	return err;
 }
 
@@ -1486,7 +1473,6 @@ int xenvif_kthread(void *data)
 
 static int __create_percpu_scratch_space(unsigned int cpu)
 {
-	/* Guard against race condition */
 	if (per_cpu(tx_copy_ops, cpu) ||
 	    per_cpu(grant_copy_op, cpu) ||
 	    per_cpu(meta, cpu))
@@ -1502,19 +1488,19 @@ static int __create_percpu_scratch_space(unsigned int cpu)
 
 	per_cpu(grant_copy_op, cpu) =
 		vzalloc_node(sizeof(struct gnttab_copy)
-			     * 2 * XEN_NETIF_RX_RING_SIZE, cpu_to_node(cpu));
+			     * 2 * NETBK_MAX_RX_RING_SIZE, cpu_to_node(cpu));
 
 	if (!per_cpu(grant_copy_op, cpu))
 		per_cpu(grant_copy_op, cpu) =
 			vzalloc(sizeof(struct gnttab_copy)
-				* 2 * XEN_NETIF_RX_RING_SIZE);
+				* 2 * NETBK_MAX_RX_RING_SIZE);
 
 	per_cpu(meta, cpu) = vzalloc_node(sizeof(struct xenvif_rx_meta)
-					  * 2 * XEN_NETIF_RX_RING_SIZE,
+					  * 2 * NETBK_MAX_RX_RING_SIZE,
 					  cpu_to_node(cpu));
 	if (!per_cpu(meta, cpu))
 		per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
-					     * 2 * XEN_NETIF_RX_RING_SIZE);
+					     * 2 * NETBK_MAX_RX_RING_SIZE);
 
 	if (!per_cpu(tx_copy_ops, cpu) ||
 	    !per_cpu(grant_copy_op, cpu) ||
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index f1e89ca..79499fc 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -113,6 +113,23 @@ static int netback_probe(struct xenbus_device *dev,
 			message = "writing feature-rx-flip";
 			goto abort_transaction;
 		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-tx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_tx_ring_page_order);
+		if (err) {
+			message = "writing max-tx-ring-page-order";
+			goto abort_transaction;
+		}
+
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-rx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_rx_ring_page_order);
+		if (err) {
+			message = "writing max-rx-ring-page-order";
+			goto abort_transaction;
+		}
 
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
@@ -391,22 +408,108 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned long tx_ring_ref, rx_ring_ref;
 	unsigned int evtchn, rx_copy;
 	int err;
 	int val;
+	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned int  tx_ring_order;
+	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "tx-ring-ref", "%lu", &tx_ring_ref,
-			    "rx-ring-ref", "%lu", &rx_ring_ref,
 			    "event-channel", "%u", &evtchn, NULL);
 	if (err) {
 		xenbus_dev_fatal(dev, err,
-				 "reading %s/ring-ref and event-channel",
+				 "reading %s/event-channel",
 				 dev->otherend);
 		return err;
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
+			   &tx_ring_order);
+	if (err < 0) {
+		tx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
+				   &tx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/tx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << tx_ring_order); i++) {
+			char ring_ref_name[sizeof("tx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "tx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &tx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-order", "%u",
+			   &rx_ring_order);
+	if (err < 0) {
+		rx_ring_order = 0;
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-ref", "%lu",
+				   &rx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/rx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (rx_ring_order > MODPARM_netback_max_rx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/rx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << rx_ring_order); i++) {
+			char ring_ref_name[sizeof("rx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "rx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &rx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -453,11 +556,23 @@ static int connect_rings(struct backend_info *be)
 	vif->csum = !val;
 
 	/* Map the shared frame, irq etc. */
-	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
+	err = xenvif_connect(vif,
+			     tx_ring_ref, (1U << tx_ring_order),
+			     rx_ring_ref, (1U << rx_ring_order),
+			     evtchn);
 	if (err) {
+		int i;
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames %lu/%lu port %u",
-				 tx_ring_ref, rx_ring_ref, evtchn);
+				 "binding port %u",
+				 evtchn);
+		for (i = 0; i < (1U << tx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping tx ring handle: %lu",
+					 tx_ring_ref[i]);
+		for (i = 0; i < (1U << rx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping rx ring handle: %lu",
+					 tx_ring_ref[i]);
 		return err;
 	}
 	return 0;
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:50:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszrD-0002ed-LZ; Thu, 02 Feb 2012 16:49:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RszrB-0002bm-Cq
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328201365!58240386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7113 invoked from network); 2 Feb 2012 16:49:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157228"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:41 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPx008442;
	Thu, 2 Feb 2012 08:49:40 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:22 +0000
Message-ID: <1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  228 ++++++++++++++++++++++++++++++--------------
 1 files changed, 156 insertions(+), 72 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b7ff815..a1cfb24 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -66,9 +66,18 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
+#define XENNET_MAX_RING_PAGE_ORDER 2
+#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
+
+#define NET_TX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define NET_RX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
+
+#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
+#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
+
+#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
 
 struct netfront_stats {
 	u64			rx_packets;
@@ -84,12 +93,19 @@ struct netfront_info {
 
 	struct napi_struct napi;
 
+	/* Statistics */
+	struct netfront_stats __percpu *stats;
+
+	unsigned long rx_gso_checksum_fixup;
+
 	unsigned int evtchn;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
 	struct xen_netif_tx_front_ring tx;
-	int tx_ring_ref;
+	int tx_ring_ref[XENNET_MAX_RING_PAGES];
+	int tx_ring_page_order;
+	int tx_ring_pages;
 
 	/*
 	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
@@ -103,36 +119,33 @@ struct netfront_info {
 	union skb_entry {
 		struct sk_buff *skb;
 		unsigned long link;
-	} tx_skbs[NET_TX_RING_SIZE];
+	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
 	grant_ref_t gref_tx_head;
-	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
 	unsigned tx_skb_freelist;
 
 	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
 	struct xen_netif_rx_front_ring rx;
-	int rx_ring_ref;
+	int rx_ring_ref[XENNET_MAX_RING_PAGES];
+	int rx_ring_page_order;
+	int rx_ring_pages;
 
 	/* Receive-ring batched refills. */
 #define RX_MIN_TARGET 8
 #define RX_DFL_MIN_TARGET 64
-#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
 	unsigned rx_min_target, rx_max_target, rx_target;
 	struct sk_buff_head rx_batch;
 
 	struct timer_list rx_refill_timer;
 
-	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
 	grant_ref_t gref_rx_head;
-	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
-
-	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
-	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
-	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
-
-	/* Statistics */
-	struct netfront_stats __percpu *stats;
+	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
 
-	unsigned long rx_gso_checksum_fixup;
+	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
 };
 
 struct netfront_rx_info {
@@ -170,15 +183,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
 	return id;
 }
 
-static int xennet_rxidx(RING_IDX idx)
+static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
 {
-	return idx & (NET_RX_RING_SIZE - 1);
+	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
 }
 
 static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 					 RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	struct sk_buff *skb = np->rx_skbs[i];
 	np->rx_skbs[i] = NULL;
 	return skb;
@@ -187,7 +200,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
 					    RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	grant_ref_t ref = np->grant_rx_ref[i];
 	np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	return ref;
@@ -300,7 +313,7 @@ no_skb:
 
 		skb->dev = dev;
 
-		id = xennet_rxidx(req_prod + i);
+		id = xennet_rxidx(req_prod + i, np);
 
 		BUG_ON(np->rx_skbs[id]);
 		np->rx_skbs[id] = skb;
@@ -596,7 +609,7 @@ static int xennet_close(struct net_device *dev)
 static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
 				grant_ref_t ref)
 {
-	int new = xennet_rxidx(np->rx.req_prod_pvt);
+	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
 
 	BUG_ON(np->rx_skbs[new]);
 	np->rx_skbs[new] = skb;
@@ -1089,7 +1102,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
 	struct sk_buff *skb;
 	int i;
 
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
 		/* Skip over entries which are actually freelist references */
 		if (skb_entry_is_link(&np->tx_skbs[i]))
 			continue;
@@ -1123,7 +1136,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
 
 	spin_lock_bh(&np->rx_lock);
 
-	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
 		ref = np->grant_rx_ref[id];
 		if (ref == GRANT_INVALID_REF) {
 			unused++;
@@ -1305,13 +1318,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	np->tx_skb_freelist = 0;
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
 		skb_entry_set_link(&np->tx_skbs[i], i+1);
 		np->grant_tx_ref[i] = GRANT_INVALID_REF;
 	}
 
 	/* Clear out rx_skbs */
-	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
 		np->rx_skbs[i] = NULL;
 		np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	}
@@ -1409,13 +1422,6 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
 	return err;
 }
 
-static void xennet_end_access(int ref, void *page)
-{
-	/* This frees the page as a side-effect */
-	if (ref != GRANT_INVALID_REF)
-		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
-}
-
 static void xennet_disconnect_backend(struct netfront_info *info)
 {
 	/* Stop old i/f to prevent errors whilst we rebuild the state. */
@@ -1429,12 +1435,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 		unbind_from_irqhandler(info->netdev->irq, info->netdev);
 	info->evtchn = info->netdev->irq = 0;
 
-	/* End access and free the pages */
-	xennet_end_access(info->tx_ring_ref, info->tx.sring);
-	xennet_end_access(info->rx_ring_ref, info->rx.sring);
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
 	info->tx.sring = NULL;
 	info->rx.sring = NULL;
 }
@@ -1482,11 +1488,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
-	int grefs[1];
 	struct net_device *netdev = info->netdev;
+	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	int i;
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
+	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
 	netdev->irq = 0;
@@ -1497,50 +1506,91 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-tx-ring-page-order", "%u",
+			   &max_tx_ring_page_order);
+	if (err < 0) {
+		info->tx_ring_page_order = 0;
+		dev_info(&dev->dev, "single tx ring\n");
+	} else {
+		info->tx_ring_page_order = max_tx_ring_page_order;
+		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
+			 max_tx_ring_page_order);
+	}
+	info->tx_ring_pages = (1U << info->tx_ring_page_order);
+
+	txs = (struct xen_netif_tx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->tx_ring_page_order);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
 		goto fail;
 	}
 	SHARED_RING_INIT(txs);
-	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
+
+	err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
+				info->tx_ring_ref);
+
+	if (err < 0)
+		goto grant_tx_ring_fail;
 
-	err = xenbus_grant_ring(dev, txs, 1, grefs);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-rx-ring-page-order", "%u",
+			   &max_rx_ring_page_order);
 	if (err < 0) {
-		free_page((unsigned long)txs);
-		goto fail;
+		info->rx_ring_page_order = 0;
+		dev_info(&dev->dev, "single rx ring\n");
+	} else {
+		info->rx_ring_page_order = max_rx_ring_page_order;
+		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
+			 max_rx_ring_page_order);
 	}
+	info->rx_ring_pages = (1U << info->rx_ring_page_order);
 
-	info->tx_ring_ref = grefs[0];
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	rxs = (struct xen_netif_rx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->rx_ring_page_order);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
-		goto fail;
+		goto alloc_rx_ring_fail;
 	}
 	SHARED_RING_INIT(rxs);
-	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
-	err = xenbus_grant_ring(dev, rxs, 1, grefs);
-	if (err < 0) {
-		free_page((unsigned long)rxs);
-		goto fail;
-	}
-	info->rx_ring_ref = grefs[0];
+	err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
+				info->rx_ring_ref);
+
+	if (err < 0)
+		goto grant_rx_ring_fail;
+
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
-		goto fail;
+		goto alloc_evtchn_fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
 					0, netdev->name, netdev);
 	if (err < 0)
-		goto fail;
+		goto bind_fail;
 	netdev->irq = err;
+
 	return 0;
 
- fail:
+bind_fail:
+	xenbus_free_evtchn(dev, info->evtchn);
+alloc_evtchn_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+grant_rx_ring_fail:
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
+alloc_rx_ring_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+grant_tx_ring_fail:
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+fail:
 	return err;
 }
 
@@ -1551,6 +1601,7 @@ static int talk_to_netback(struct xenbus_device *dev,
 	const char *message;
 	struct xenbus_transaction xbt;
 	int err;
+	int i;
 
 	/* Create shared ring, alloc event channel. */
 	err = setup_netfront(dev, info);
@@ -1564,18 +1615,50 @@ again:
 		goto destroy_ring;
 	}
 
-	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
-			    info->tx_ring_ref);
-	if (err) {
-		message = "writing tx ring-ref";
-		goto abort_transaction;
+	if (info->tx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
+				    info->tx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
+				    info->tx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->tx_ring_pages; i++) {
+			char name[sizeof("tx-ring-ref")+2];
+			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->tx_ring_ref[i]);
+			if (err) {
+				message = "writing tx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
-	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
-			    info->rx_ring_ref);
-	if (err) {
-		message = "writing rx ring-ref";
-		goto abort_transaction;
+
+	if (info->rx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
+				    info->rx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
+				    info->rx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->rx_ring_pages; i++) {
+			char name[sizeof("rx-ring-ref")+2];
+			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->rx_ring_ref[i]);
+			if (err) {
+				message = "writing rx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
+
 	err = xenbus_printf(xbt, dev->nodename,
 			    "event-channel", "%u", info->evtchn);
 	if (err) {
@@ -1662,7 +1745,8 @@ static int xennet_connect(struct net_device *dev)
 	xennet_release_tx_bufs(np);
 
 	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
-	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
+	     i++) {
 		skb_frag_t *frag;
 		const struct page *page;
 		if (!np->rx_skbs[i])
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 16:50:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 16:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RszrD-0002ed-LZ; Thu, 02 Feb 2012 16:49:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RszrB-0002bm-Cq
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 16:49:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328201365!58240386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7113 invoked from network); 2 Feb 2012 16:49:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 16:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,609,1320642000"; d="scan'208";a="180157228"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 11:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 11:49:41 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q12GnNPx008442;
	Thu, 2 Feb 2012 08:49:40 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Thu, 2 Feb 2012 16:49:22 +0000
Message-ID: <1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  228 ++++++++++++++++++++++++++++++--------------
 1 files changed, 156 insertions(+), 72 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b7ff815..a1cfb24 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -66,9 +66,18 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
+#define XENNET_MAX_RING_PAGE_ORDER 2
+#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
+
+#define NET_TX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define NET_RX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
+
+#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
+#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
+
+#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
 
 struct netfront_stats {
 	u64			rx_packets;
@@ -84,12 +93,19 @@ struct netfront_info {
 
 	struct napi_struct napi;
 
+	/* Statistics */
+	struct netfront_stats __percpu *stats;
+
+	unsigned long rx_gso_checksum_fixup;
+
 	unsigned int evtchn;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
 	struct xen_netif_tx_front_ring tx;
-	int tx_ring_ref;
+	int tx_ring_ref[XENNET_MAX_RING_PAGES];
+	int tx_ring_page_order;
+	int tx_ring_pages;
 
 	/*
 	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
@@ -103,36 +119,33 @@ struct netfront_info {
 	union skb_entry {
 		struct sk_buff *skb;
 		unsigned long link;
-	} tx_skbs[NET_TX_RING_SIZE];
+	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
 	grant_ref_t gref_tx_head;
-	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
 	unsigned tx_skb_freelist;
 
 	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
 	struct xen_netif_rx_front_ring rx;
-	int rx_ring_ref;
+	int rx_ring_ref[XENNET_MAX_RING_PAGES];
+	int rx_ring_page_order;
+	int rx_ring_pages;
 
 	/* Receive-ring batched refills. */
 #define RX_MIN_TARGET 8
 #define RX_DFL_MIN_TARGET 64
-#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
 	unsigned rx_min_target, rx_max_target, rx_target;
 	struct sk_buff_head rx_batch;
 
 	struct timer_list rx_refill_timer;
 
-	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
 	grant_ref_t gref_rx_head;
-	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
-
-	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
-	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
-	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
-
-	/* Statistics */
-	struct netfront_stats __percpu *stats;
+	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
 
-	unsigned long rx_gso_checksum_fixup;
+	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
 };
 
 struct netfront_rx_info {
@@ -170,15 +183,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
 	return id;
 }
 
-static int xennet_rxidx(RING_IDX idx)
+static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
 {
-	return idx & (NET_RX_RING_SIZE - 1);
+	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
 }
 
 static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 					 RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	struct sk_buff *skb = np->rx_skbs[i];
 	np->rx_skbs[i] = NULL;
 	return skb;
@@ -187,7 +200,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
 					    RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	grant_ref_t ref = np->grant_rx_ref[i];
 	np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	return ref;
@@ -300,7 +313,7 @@ no_skb:
 
 		skb->dev = dev;
 
-		id = xennet_rxidx(req_prod + i);
+		id = xennet_rxidx(req_prod + i, np);
 
 		BUG_ON(np->rx_skbs[id]);
 		np->rx_skbs[id] = skb;
@@ -596,7 +609,7 @@ static int xennet_close(struct net_device *dev)
 static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
 				grant_ref_t ref)
 {
-	int new = xennet_rxidx(np->rx.req_prod_pvt);
+	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
 
 	BUG_ON(np->rx_skbs[new]);
 	np->rx_skbs[new] = skb;
@@ -1089,7 +1102,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
 	struct sk_buff *skb;
 	int i;
 
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
 		/* Skip over entries which are actually freelist references */
 		if (skb_entry_is_link(&np->tx_skbs[i]))
 			continue;
@@ -1123,7 +1136,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
 
 	spin_lock_bh(&np->rx_lock);
 
-	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
 		ref = np->grant_rx_ref[id];
 		if (ref == GRANT_INVALID_REF) {
 			unused++;
@@ -1305,13 +1318,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	np->tx_skb_freelist = 0;
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
 		skb_entry_set_link(&np->tx_skbs[i], i+1);
 		np->grant_tx_ref[i] = GRANT_INVALID_REF;
 	}
 
 	/* Clear out rx_skbs */
-	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
 		np->rx_skbs[i] = NULL;
 		np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	}
@@ -1409,13 +1422,6 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
 	return err;
 }
 
-static void xennet_end_access(int ref, void *page)
-{
-	/* This frees the page as a side-effect */
-	if (ref != GRANT_INVALID_REF)
-		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
-}
-
 static void xennet_disconnect_backend(struct netfront_info *info)
 {
 	/* Stop old i/f to prevent errors whilst we rebuild the state. */
@@ -1429,12 +1435,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 		unbind_from_irqhandler(info->netdev->irq, info->netdev);
 	info->evtchn = info->netdev->irq = 0;
 
-	/* End access and free the pages */
-	xennet_end_access(info->tx_ring_ref, info->tx.sring);
-	xennet_end_access(info->rx_ring_ref, info->rx.sring);
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
 	info->tx.sring = NULL;
 	info->rx.sring = NULL;
 }
@@ -1482,11 +1488,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
-	int grefs[1];
 	struct net_device *netdev = info->netdev;
+	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	int i;
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
+	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
 	netdev->irq = 0;
@@ -1497,50 +1506,91 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-tx-ring-page-order", "%u",
+			   &max_tx_ring_page_order);
+	if (err < 0) {
+		info->tx_ring_page_order = 0;
+		dev_info(&dev->dev, "single tx ring\n");
+	} else {
+		info->tx_ring_page_order = max_tx_ring_page_order;
+		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
+			 max_tx_ring_page_order);
+	}
+	info->tx_ring_pages = (1U << info->tx_ring_page_order);
+
+	txs = (struct xen_netif_tx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->tx_ring_page_order);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
 		goto fail;
 	}
 	SHARED_RING_INIT(txs);
-	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
+
+	err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
+				info->tx_ring_ref);
+
+	if (err < 0)
+		goto grant_tx_ring_fail;
 
-	err = xenbus_grant_ring(dev, txs, 1, grefs);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-rx-ring-page-order", "%u",
+			   &max_rx_ring_page_order);
 	if (err < 0) {
-		free_page((unsigned long)txs);
-		goto fail;
+		info->rx_ring_page_order = 0;
+		dev_info(&dev->dev, "single rx ring\n");
+	} else {
+		info->rx_ring_page_order = max_rx_ring_page_order;
+		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
+			 max_rx_ring_page_order);
 	}
+	info->rx_ring_pages = (1U << info->rx_ring_page_order);
 
-	info->tx_ring_ref = grefs[0];
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	rxs = (struct xen_netif_rx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->rx_ring_page_order);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
-		goto fail;
+		goto alloc_rx_ring_fail;
 	}
 	SHARED_RING_INIT(rxs);
-	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
-	err = xenbus_grant_ring(dev, rxs, 1, grefs);
-	if (err < 0) {
-		free_page((unsigned long)rxs);
-		goto fail;
-	}
-	info->rx_ring_ref = grefs[0];
+	err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
+				info->rx_ring_ref);
+
+	if (err < 0)
+		goto grant_rx_ring_fail;
+
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
-		goto fail;
+		goto alloc_evtchn_fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
 					0, netdev->name, netdev);
 	if (err < 0)
-		goto fail;
+		goto bind_fail;
 	netdev->irq = err;
+
 	return 0;
 
- fail:
+bind_fail:
+	xenbus_free_evtchn(dev, info->evtchn);
+alloc_evtchn_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+grant_rx_ring_fail:
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
+alloc_rx_ring_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+grant_tx_ring_fail:
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+fail:
 	return err;
 }
 
@@ -1551,6 +1601,7 @@ static int talk_to_netback(struct xenbus_device *dev,
 	const char *message;
 	struct xenbus_transaction xbt;
 	int err;
+	int i;
 
 	/* Create shared ring, alloc event channel. */
 	err = setup_netfront(dev, info);
@@ -1564,18 +1615,50 @@ again:
 		goto destroy_ring;
 	}
 
-	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
-			    info->tx_ring_ref);
-	if (err) {
-		message = "writing tx ring-ref";
-		goto abort_transaction;
+	if (info->tx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
+				    info->tx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
+				    info->tx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->tx_ring_pages; i++) {
+			char name[sizeof("tx-ring-ref")+2];
+			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->tx_ring_ref[i]);
+			if (err) {
+				message = "writing tx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
-	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
-			    info->rx_ring_ref);
-	if (err) {
-		message = "writing rx ring-ref";
-		goto abort_transaction;
+
+	if (info->rx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
+				    info->rx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
+				    info->rx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->rx_ring_pages; i++) {
+			char name[sizeof("rx-ring-ref")+2];
+			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->rx_ring_ref[i]);
+			if (err) {
+				message = "writing rx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
+
 	err = xenbus_printf(xbt, dev->nodename,
 			    "event-channel", "%u", info->evtchn);
 	if (err) {
@@ -1662,7 +1745,8 @@ static int xennet_connect(struct net_device *dev)
 	xennet_release_tx_bufs(np);
 
 	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
-	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
+	     i++) {
 		skb_frag_t *frag;
 		const struct page *page;
 		if (!np->rx_skbs[i])
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt09W-0004tA-SC; Thu, 02 Feb 2012 17:08:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt09W-0004sz-1q
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:08:54 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328202527!13180533!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28112 invoked from network); 2 Feb 2012 17:08:47 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 17:08:47 -0000
Received: by wgbdt11 with SMTP id dt11so246700wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 09:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=Mdn3aAazQo1jbyrl2Gh5xXar69DtsSJYutZ8W7QLx/A=;
	b=i7zBT5UN21e/UxsPtFdZSTgI+TwZr7Fd730PyeI2e31GunBivRDwaWz05IRzpQZBMA
	3+0jUIG5qIAk1UQd5JqFzFPCCzCKNDy8YjpBbgbY9xF/zWDJRC6K+WOi0lMiBMERL7Du
	Jkpi7umsUY5XTyYzsgXo/AiDuwCtDH2z3cOx0=
Received: by 10.181.12.106 with SMTP id ep10mr19272738wid.8.1328202527435;
	Thu, 02 Feb 2012 09:08:47 -0800 (PST)
Received: from [10.150.51.216] (gw0.net.jmsp.net. [212.23.165.14])
	by mx.google.com with ESMTPS id di5sm8892180wib.3.2012.02.02.09.08.45
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:08:46 -0800 (PST)
Message-ID: <1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 02 Feb 2012 18:08:44 +0100
In-Reply-To: <1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNjo0OSArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cj4gRW5hYmxlcyB1c2VycyB0byB1bmxvYWQgbmV0YmFjayBtb2R1bGUuCj4gCj4gUmV2aWV3
ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiBU
ZXN0ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4K
PiBTaWduZWQtb2ZmLWJ5OiBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPgo+IC0tLQo+ICBk
cml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaCAgfCAgICAxICsKPiAgZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jIHwgICAxNCArKysrKysrKysrKysrKwo+ICBkcml2ZXJzL25l
dC94ZW4tbmV0YmFjay94ZW5idXMuYyAgfCAgICA1ICsrKysrCj4gIDMgZmlsZXMgY2hhbmdlZCwg
MjAgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKPiAKPiBkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9uZXQveGVuLW5ldGJhY2svY29tbW9uLmggYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21t
b24uaAo+IGluZGV4IDI4OGIyZjMuLjM3MmM3ZjUgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svY29tbW9uLmgKPiArKysgYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21t
b24uaAo+IEBAIC0xMjYsNiArMTI2LDcgQEAgdm9pZCB4ZW52aWZfZ2V0KHN0cnVjdCB4ZW52aWYg
KnZpZik7Cj4gIHZvaWQgeGVudmlmX3B1dChzdHJ1Y3QgeGVudmlmICp2aWYpOwo+ICAKPiAgaW50
IHhlbnZpZl94ZW5idXNfaW5pdCh2b2lkKTsKPiArdm9pZCB4ZW52aWZfeGVuYnVzX2V4aXQodm9p
ZCk7Cj4gIAo+ICBpbnQgeGVudmlmX3NjaGVkdWxhYmxlKHN0cnVjdCB4ZW52aWYgKnZpZik7Cj4g
IAo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMgYi9kcml2
ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKPiBpbmRleCBkMTEyMDVmLi4zMDU5Njg0IDEw
MDY0NAo+IC0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwo+ICsrKyBiL2Ry
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwo+IEBAIC0xNjcwLDUgKzE2NzAsMTkgQEAg
ZmFpbGVkX2luaXQ6Cj4gIAo+ICBtb2R1bGVfaW5pdChuZXRiYWNrX2luaXQpOwo+ICAKCldoaWxl
IHJldmlld2luZyB0aGlzIGNvZGUsIEkgY2FuIHNlZSBjdXJyZW50IG5ldGJhY2tfaW5pdCgpIGlz
IGJ1Z2d5LgoKSXQgYXNzdW1lcyBhbGwgb25saW5lIGNwdXMgeGVuX25ldGJrX2dyb3VwX25yIGFy
ZSBudW1iZXJlZCBmcm9tIDAgdG8KeGVuX25ldGJrX2dyb3VwX25yLTEKClRoaXMgaXMgbm90IHJp
Z2h0LgoKSW5zdGVhZCBvZiB1c2luZyA6Cgp4ZW5fbmV0YmsgPSB2emFsbG9jKHNpemVvZihzdHJ1
Y3QgeGVuX25ldGJrKSAqIHhlbl9uZXRia19ncm91cF9ucik7CgpZb3Ugc2hvdWxkIHVzZSBhIHBl
cmNwdSB2YXJpYWJsZSB0byBnZXQgcHJvcGVyIE5VTUEgcHJvcGVydGllcy4KCkFuZCBpbnN0ZWFk
IG9mIGxvb3BpbmcgbGlrZSA6Cgpmb3IgKGdyb3VwID0gMDsgZ3JvdXAgPCB4ZW5fbmV0YmtfZ3Jv
dXBfbnI7IGdyb3VwKyspIHsKCllvdSBtdXN0IHVzZSA6Cgpmb3JfZWFjaF9vbmxpbmVfY3B1KGNw
dSkgewoJLi4uCn0KClsgYW5kIGFsc28gdXNlIGt0aHJlYWRfY3JlYXRlX29uX25vZGUoKSBpbnN0
ZWFkIG9mIGt0aHJlYWRfY3JlYXRlKCkgXQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt09W-0004tA-SC; Thu, 02 Feb 2012 17:08:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt09W-0004sz-1q
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:08:54 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328202527!13180533!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28112 invoked from network); 2 Feb 2012 17:08:47 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 17:08:47 -0000
Received: by wgbdt11 with SMTP id dt11so246700wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 09:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=Mdn3aAazQo1jbyrl2Gh5xXar69DtsSJYutZ8W7QLx/A=;
	b=i7zBT5UN21e/UxsPtFdZSTgI+TwZr7Fd730PyeI2e31GunBivRDwaWz05IRzpQZBMA
	3+0jUIG5qIAk1UQd5JqFzFPCCzCKNDy8YjpBbgbY9xF/zWDJRC6K+WOi0lMiBMERL7Du
	Jkpi7umsUY5XTyYzsgXo/AiDuwCtDH2z3cOx0=
Received: by 10.181.12.106 with SMTP id ep10mr19272738wid.8.1328202527435;
	Thu, 02 Feb 2012 09:08:47 -0800 (PST)
Received: from [10.150.51.216] (gw0.net.jmsp.net. [212.23.165.14])
	by mx.google.com with ESMTPS id di5sm8892180wib.3.2012.02.02.09.08.45
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:08:46 -0800 (PST)
Message-ID: <1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 02 Feb 2012 18:08:44 +0100
In-Reply-To: <1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNjo0OSArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cj4gRW5hYmxlcyB1c2VycyB0byB1bmxvYWQgbmV0YmFjayBtb2R1bGUuCj4gCj4gUmV2aWV3
ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPiBU
ZXN0ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4K
PiBTaWduZWQtb2ZmLWJ5OiBXZWkgTGl1IDx3ZWkubGl1MkBjaXRyaXguY29tPgo+IC0tLQo+ICBk
cml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaCAgfCAgICAxICsKPiAgZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jIHwgICAxNCArKysrKysrKysrKysrKwo+ICBkcml2ZXJzL25l
dC94ZW4tbmV0YmFjay94ZW5idXMuYyAgfCAgICA1ICsrKysrCj4gIDMgZmlsZXMgY2hhbmdlZCwg
MjAgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKPiAKPiBkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9uZXQveGVuLW5ldGJhY2svY29tbW9uLmggYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21t
b24uaAo+IGluZGV4IDI4OGIyZjMuLjM3MmM3ZjUgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svY29tbW9uLmgKPiArKysgYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21t
b24uaAo+IEBAIC0xMjYsNiArMTI2LDcgQEAgdm9pZCB4ZW52aWZfZ2V0KHN0cnVjdCB4ZW52aWYg
KnZpZik7Cj4gIHZvaWQgeGVudmlmX3B1dChzdHJ1Y3QgeGVudmlmICp2aWYpOwo+ICAKPiAgaW50
IHhlbnZpZl94ZW5idXNfaW5pdCh2b2lkKTsKPiArdm9pZCB4ZW52aWZfeGVuYnVzX2V4aXQodm9p
ZCk7Cj4gIAo+ICBpbnQgeGVudmlmX3NjaGVkdWxhYmxlKHN0cnVjdCB4ZW52aWYgKnZpZik7Cj4g
IAo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMgYi9kcml2
ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKPiBpbmRleCBkMTEyMDVmLi4zMDU5Njg0IDEw
MDY0NAo+IC0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwo+ICsrKyBiL2Ry
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwo+IEBAIC0xNjcwLDUgKzE2NzAsMTkgQEAg
ZmFpbGVkX2luaXQ6Cj4gIAo+ICBtb2R1bGVfaW5pdChuZXRiYWNrX2luaXQpOwo+ICAKCldoaWxl
IHJldmlld2luZyB0aGlzIGNvZGUsIEkgY2FuIHNlZSBjdXJyZW50IG5ldGJhY2tfaW5pdCgpIGlz
IGJ1Z2d5LgoKSXQgYXNzdW1lcyBhbGwgb25saW5lIGNwdXMgeGVuX25ldGJrX2dyb3VwX25yIGFy
ZSBudW1iZXJlZCBmcm9tIDAgdG8KeGVuX25ldGJrX2dyb3VwX25yLTEKClRoaXMgaXMgbm90IHJp
Z2h0LgoKSW5zdGVhZCBvZiB1c2luZyA6Cgp4ZW5fbmV0YmsgPSB2emFsbG9jKHNpemVvZihzdHJ1
Y3QgeGVuX25ldGJrKSAqIHhlbl9uZXRia19ncm91cF9ucik7CgpZb3Ugc2hvdWxkIHVzZSBhIHBl
cmNwdSB2YXJpYWJsZSB0byBnZXQgcHJvcGVyIE5VTUEgcHJvcGVydGllcy4KCkFuZCBpbnN0ZWFk
IG9mIGxvb3BpbmcgbGlrZSA6Cgpmb3IgKGdyb3VwID0gMDsgZ3JvdXAgPCB4ZW5fbmV0YmtfZ3Jv
dXBfbnI7IGdyb3VwKyspIHsKCllvdSBtdXN0IHVzZSA6Cgpmb3JfZWFjaF9vbmxpbmVfY3B1KGNw
dSkgewoJLi4uCn0KClsgYW5kIGFsc28gdXNlIGt0aHJlYWRfY3JlYXRlX29uX25vZGUoKSBpbnN0
ZWFkIG9mIGt0aHJlYWRfY3JlYXRlKCkgXQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt0QK-0005hp-4q; Thu, 02 Feb 2012 17:26:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt0QH-0005hM-Tz
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:26:14 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328203513!55141992!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1896 invoked from network); 2 Feb 2012 17:25:13 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 17:25:13 -0000
Received: by werb14 with SMTP id b14so5176645wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 09:26:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=b6mvX638op5jpYsWwNN+a9Z1ArWXaij1kJbBfzVms3M=;
	b=FEAnSTTLwcGHOxQY1eKMvRuYNc1CmX24JV/8KnyopD7BXKlsgFn6cgbaSVa8QUh6gP
	fes36vIr8Mip8XN0ynDszoIJAMjLo2putmfMInwcdmtfjokOvKlbMUaS67lxSZFpOu1E
	T7QfPdtTHIPVBXhmGB6jz5iMpcInD2VGGWj1s=
Received: by 10.216.137.82 with SMTP id x60mr1514250wei.42.1328203567552;
	Thu, 02 Feb 2012 09:26:07 -0800 (PST)
Received: from [10.150.51.216] (gw0.net.jmsp.net. [212.23.165.14])
	by mx.google.com with ESMTPS id x7sm1007449wif.10.2012.02.02.09.26.05
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:26:06 -0800 (PST)
Message-ID: <1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 02 Feb 2012 18:26:05 +0100
In-Reply-To: <1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNjo0OSArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cj4gQSBnbG9iYWwgcGFnZSBwb29sLiBTaW5jZSB3ZSBhcmUgbW92aW5nIHRvIDE6MSBtb2Rl
bCBuZXRiYWNrLCBpdCBpcwo+IGJldHRlciB0byBsaW1pdCB0b3RhbCBSQU0gY29uc3VtZWQgYnkg
YWxsIHRoZSB2aWZzLgo+IAo+IFdpdGggdGhpcyBwYXRjaCwgZWFjaCB2aWYgZ2V0cyBwYWdlIGZy
b20gdGhlIHBvb2wgYW5kIHB1dHMgdGhlIHBhZ2UKPiBiYWNrIHdoZW4gaXQgaXMgZmluaXNoZWQg
d2l0aCB0aGUgcGFnZS4KPiAKPiBUaGlzIHBvb2wgaXMgb25seSBtZWFudCB0byBhY2Nlc3Mgdmlh
IGV4cG9ydGVkIGludGVyZmFjZXMuIEludGVybmFscwo+IGFyZSBzdWJqZWN0IHRvIGNoYW5nZSB3
aGVuIHdlIGRpc2NvdmVyIG5ldyByZXF1aXJlbWVudHMgZm9yIHRoZSBwb29sLgo+IAo+IEN1cnJl
bnQgZXhwb3J0ZWQgaW50ZXJmYWNlcyBpbmNsdWRlOgo+IAo+IHBhZ2VfcG9vbF9pbml0OiBwb29s
IGluaXQKPiBwYWdlX3Bvb2xfZGVzdHJveTogcG9vbCBkZXN0cnVjdGlvbgo+IHBhZ2VfcG9vbF9n
ZXQ6IGdldCBhIHBhZ2UgZnJvbSBwb29sCj4gcGFnZV9wb29sX3B1dDogcHV0IHBhZ2UgYmFjayB0
byBwb29sCj4gaXNfaW5fcG9vbDogdGVsbCB3aGV0aGVyIGEgcGFnZSBiZWxvbmdzIHRvIHRoZSBw
b29sCj4gCj4gQ3VycmVudCBpbXBsZW1lbnRhdGlvbiBoYXMgZm9sbG93aW5nIGRlZmVjdHM6Cj4g
IC0gR2xvYmFsIGxvY2tpbmcKPiAgLSBObyBzdGFydmUgcHJldmVudGlvbiBtZWNoYW5pc20gLyBy
ZXNlcnZhdGlvbiBsb2dpYwo+IAo+IEdsb2JhbCBsb2NraW5nIHRlbmRzIHRvIGNhdXNlIGNvbnRl
bnRpb24gb24gdGhlIHBvb2wuIE5vIHJlc2VydmF0aW9uCj4gbG9naWMgbWF5IGNhdXNlIHZpZiB0
byBzdGFydmUuIEEgcG9zc2libGUgc29sdXRpb24gdG8gdGhlc2UgdHdvCj4gcHJvYmxlbXMgd2ls
bCBiZSBlYWNoIHZpZiBtYWludGFpbnMgaXRzIGxvY2FsIGNhY2hlIGFuZCBjbGFpbXMgYQo+IHBv
cnRpb24gb2YgdGhlIHBvb2wuIEhvd2V2ZXIgdGhlIGltcGxlbWVudGF0aW9uIHdpbGwgYmUgdHJp
Y2t5IHdoZW4KPiBjb21pbmcgdG8gcG9vbCBtYW5hZ2VtZW50LCBzbyBsZXQncyB3b3JyeSBhYm91
dCB0aGF0IGxhdGVyLgo+IAo+IFJldmlld2VkLWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtv
bnJhZC53aWxrQG9yYWNsZS5jb20+Cj4gVGVzdGVkLWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsg
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+Cj4gU2lnbmVkLW9mZi1ieTogV2VpIExpdSA8d2VpLmxp
dTJAY2l0cml4LmNvbT4KPiAtLS0KCkhtbSwgdGhpcyBraW5kIG9mIHN0dWZmIHNob3VsZCBiZSBk
aXNjdXNzZWQgb24gbGttbC4KCkkgZG91YnQgd2Ugd2FudCB5ZXQgYW5vdGhlciBtZW1vcnkgYWxs
b2NhdG9yLCB3aXRoIGEgZ2xvYmFsIGxvY2sKKGNvbnRlbmRlZCksIGFuZCBubyBOVU1BIHByb3Bl
cnRpZXMuCgoKPiAraW50IHBhZ2VfcG9vbF9pbml0KCkKPiArewo+ICsJaW50IGNwdXMgPSAwOwo+
ICsJaW50IGk7Cj4gKwo+ICsJY3B1cyA9IG51bV9vbmxpbmVfY3B1cygpOwo+ICsJcG9vbF9zaXpl
ID0gY3B1cyAqIEVOVFJJRVNfUEVSX0NQVTsKPiArCj4gKwlwb29sID0gdnphbGxvYyhzaXplb2Yo
c3RydWN0IHBhZ2VfcG9vbF9lbnRyeSkgKiBwb29sX3NpemUpOwo+ICsKPiArCWlmICghcG9vbCkK
PiArCQlyZXR1cm4gLUVOT01FTTsKPiArCj4gKwlmb3IgKGkgPSAwOyBpIDwgcG9vbF9zaXplIC0g
MTsgaSsrKQo+ICsJCXBvb2xbaV0udS5mbCA9IGkrMTsKPiArCXBvb2xbcG9vbF9zaXplLTFdLnUu
ZmwgPSBJTlZBTElEX0VOVFJZOwo+ICsJZnJlZV9jb3VudCA9IHBvb2xfc2l6ZTsKPiArCWZyZWVf
aGVhZCA9IDA7Cj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KPiArCgpudW1fb25saW5lX2NwdXMoKSBk
aXNlYXNlIG9uY2UgYWdhaW4uCgpjb2RlIGRlcGVuZGluZyBvbiBudW1fb25saW5lX2NwdXMoKSBp
cyBhbHdheXMgc3VzcGljaW91cy4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt0QK-0005hp-4q; Thu, 02 Feb 2012 17:26:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt0QH-0005hM-Tz
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:26:14 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328203513!55141992!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1896 invoked from network); 2 Feb 2012 17:25:13 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 17:25:13 -0000
Received: by werb14 with SMTP id b14so5176645wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 09:26:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=b6mvX638op5jpYsWwNN+a9Z1ArWXaij1kJbBfzVms3M=;
	b=FEAnSTTLwcGHOxQY1eKMvRuYNc1CmX24JV/8KnyopD7BXKlsgFn6cgbaSVa8QUh6gP
	fes36vIr8Mip8XN0ynDszoIJAMjLo2putmfMInwcdmtfjokOvKlbMUaS67lxSZFpOu1E
	T7QfPdtTHIPVBXhmGB6jz5iMpcInD2VGGWj1s=
Received: by 10.216.137.82 with SMTP id x60mr1514250wei.42.1328203567552;
	Thu, 02 Feb 2012 09:26:07 -0800 (PST)
Received: from [10.150.51.216] (gw0.net.jmsp.net. [212.23.165.14])
	by mx.google.com with ESMTPS id x7sm1007449wif.10.2012.02.02.09.26.05
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:26:06 -0800 (PST)
Message-ID: <1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 02 Feb 2012 18:26:05 +0100
In-Reply-To: <1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNjo0OSArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cj4gQSBnbG9iYWwgcGFnZSBwb29sLiBTaW5jZSB3ZSBhcmUgbW92aW5nIHRvIDE6MSBtb2Rl
bCBuZXRiYWNrLCBpdCBpcwo+IGJldHRlciB0byBsaW1pdCB0b3RhbCBSQU0gY29uc3VtZWQgYnkg
YWxsIHRoZSB2aWZzLgo+IAo+IFdpdGggdGhpcyBwYXRjaCwgZWFjaCB2aWYgZ2V0cyBwYWdlIGZy
b20gdGhlIHBvb2wgYW5kIHB1dHMgdGhlIHBhZ2UKPiBiYWNrIHdoZW4gaXQgaXMgZmluaXNoZWQg
d2l0aCB0aGUgcGFnZS4KPiAKPiBUaGlzIHBvb2wgaXMgb25seSBtZWFudCB0byBhY2Nlc3Mgdmlh
IGV4cG9ydGVkIGludGVyZmFjZXMuIEludGVybmFscwo+IGFyZSBzdWJqZWN0IHRvIGNoYW5nZSB3
aGVuIHdlIGRpc2NvdmVyIG5ldyByZXF1aXJlbWVudHMgZm9yIHRoZSBwb29sLgo+IAo+IEN1cnJl
bnQgZXhwb3J0ZWQgaW50ZXJmYWNlcyBpbmNsdWRlOgo+IAo+IHBhZ2VfcG9vbF9pbml0OiBwb29s
IGluaXQKPiBwYWdlX3Bvb2xfZGVzdHJveTogcG9vbCBkZXN0cnVjdGlvbgo+IHBhZ2VfcG9vbF9n
ZXQ6IGdldCBhIHBhZ2UgZnJvbSBwb29sCj4gcGFnZV9wb29sX3B1dDogcHV0IHBhZ2UgYmFjayB0
byBwb29sCj4gaXNfaW5fcG9vbDogdGVsbCB3aGV0aGVyIGEgcGFnZSBiZWxvbmdzIHRvIHRoZSBw
b29sCj4gCj4gQ3VycmVudCBpbXBsZW1lbnRhdGlvbiBoYXMgZm9sbG93aW5nIGRlZmVjdHM6Cj4g
IC0gR2xvYmFsIGxvY2tpbmcKPiAgLSBObyBzdGFydmUgcHJldmVudGlvbiBtZWNoYW5pc20gLyBy
ZXNlcnZhdGlvbiBsb2dpYwo+IAo+IEdsb2JhbCBsb2NraW5nIHRlbmRzIHRvIGNhdXNlIGNvbnRl
bnRpb24gb24gdGhlIHBvb2wuIE5vIHJlc2VydmF0aW9uCj4gbG9naWMgbWF5IGNhdXNlIHZpZiB0
byBzdGFydmUuIEEgcG9zc2libGUgc29sdXRpb24gdG8gdGhlc2UgdHdvCj4gcHJvYmxlbXMgd2ls
bCBiZSBlYWNoIHZpZiBtYWludGFpbnMgaXRzIGxvY2FsIGNhY2hlIGFuZCBjbGFpbXMgYQo+IHBv
cnRpb24gb2YgdGhlIHBvb2wuIEhvd2V2ZXIgdGhlIGltcGxlbWVudGF0aW9uIHdpbGwgYmUgdHJp
Y2t5IHdoZW4KPiBjb21pbmcgdG8gcG9vbCBtYW5hZ2VtZW50LCBzbyBsZXQncyB3b3JyeSBhYm91
dCB0aGF0IGxhdGVyLgo+IAo+IFJldmlld2VkLWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtv
bnJhZC53aWxrQG9yYWNsZS5jb20+Cj4gVGVzdGVkLWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsg
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+Cj4gU2lnbmVkLW9mZi1ieTogV2VpIExpdSA8d2VpLmxp
dTJAY2l0cml4LmNvbT4KPiAtLS0KCkhtbSwgdGhpcyBraW5kIG9mIHN0dWZmIHNob3VsZCBiZSBk
aXNjdXNzZWQgb24gbGttbC4KCkkgZG91YnQgd2Ugd2FudCB5ZXQgYW5vdGhlciBtZW1vcnkgYWxs
b2NhdG9yLCB3aXRoIGEgZ2xvYmFsIGxvY2sKKGNvbnRlbmRlZCksIGFuZCBubyBOVU1BIHByb3Bl
cnRpZXMuCgoKPiAraW50IHBhZ2VfcG9vbF9pbml0KCkKPiArewo+ICsJaW50IGNwdXMgPSAwOwo+
ICsJaW50IGk7Cj4gKwo+ICsJY3B1cyA9IG51bV9vbmxpbmVfY3B1cygpOwo+ICsJcG9vbF9zaXpl
ID0gY3B1cyAqIEVOVFJJRVNfUEVSX0NQVTsKPiArCj4gKwlwb29sID0gdnphbGxvYyhzaXplb2Yo
c3RydWN0IHBhZ2VfcG9vbF9lbnRyeSkgKiBwb29sX3NpemUpOwo+ICsKPiArCWlmICghcG9vbCkK
PiArCQlyZXR1cm4gLUVOT01FTTsKPiArCj4gKwlmb3IgKGkgPSAwOyBpIDwgcG9vbF9zaXplIC0g
MTsgaSsrKQo+ICsJCXBvb2xbaV0udS5mbCA9IGkrMTsKPiArCXBvb2xbcG9vbF9zaXplLTFdLnUu
ZmwgPSBJTlZBTElEX0VOVFJZOwo+ICsJZnJlZV9jb3VudCA9IHBvb2xfc2l6ZTsKPiArCWZyZWVf
aGVhZCA9IDA7Cj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KPiArCgpudW1fb25saW5lX2NwdXMoKSBk
aXNlYXNlIG9uY2UgYWdhaW4uCgpjb2RlIGRlcGVuZGluZyBvbiBudW1fb25saW5lX2NwdXMoKSBp
cyBhbHdheXMgc3VzcGljaW91cy4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17: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.xensource.com>)
	id 1Rt0SI-0005th-M1; Thu, 02 Feb 2012 17:28:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rt0SI-0005tH-0F
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:28:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328203669!51339933!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29083 invoked from network); 2 Feb 2012 17:27:49 -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;
	2 Feb 2012 17:27:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,610,1320624000"; d="scan'208";a="10448803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 17:28:11 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	17:28:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Thu, 2 Feb 2012 17:28:30 +0000
Message-ID: <1328203710.5553.94.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAyLTAyIGF0IDE3OjA4ICswMDAwLCBFcmljIER1bWF6ZXQgd3JvdGU6Cj4g
TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNjo0OSArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cj4gPiBFbmFibGVzIHVzZXJzIHRvIHVubG9hZCBuZXRiYWNrIG1vZHVsZS4KPiA+IAo+ID4g
UmV2aWV3ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNv
bT4KPiA+IFRlc3RlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFj
bGUuY29tPgo+ID4gU2lnbmVkLW9mZi1ieTogV2VpIExpdSA8d2VpLmxpdTJAY2l0cml4LmNvbT4K
PiA+IC0tLQo+ID4gIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oICB8ICAgIDEgKwo+
ID4gIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYyB8ICAgMTQgKysrKysrKysrKysr
KysKPiA+ICBkcml2ZXJzL25ldC94ZW4tbmV0YmFjay94ZW5idXMuYyAgfCAgICA1ICsrKysrCj4g
PiAgMyBmaWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQo+ID4g
Cj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svY29tbW9uLmggYi9kcml2
ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaAo+ID4gaW5kZXggMjg4YjJmMy4uMzcyYzdmNSAx
MDA2NDQKPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oCj4gPiArKysg
Yi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaAo+ID4gQEAgLTEyNiw2ICsxMjYsNyBA
QCB2b2lkIHhlbnZpZl9nZXQoc3RydWN0IHhlbnZpZiAqdmlmKTsKPiA+ICB2b2lkIHhlbnZpZl9w
dXQoc3RydWN0IHhlbnZpZiAqdmlmKTsKPiA+ICAKPiA+ICBpbnQgeGVudmlmX3hlbmJ1c19pbml0
KHZvaWQpOwo+ID4gK3ZvaWQgeGVudmlmX3hlbmJ1c19leGl0KHZvaWQpOwo+ID4gIAo+ID4gIGlu
dCB4ZW52aWZfc2NoZWR1bGFibGUoc3RydWN0IHhlbnZpZiAqdmlmKTsKPiA+ICAKPiA+IGRpZmYg
LS1naXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMgYi9kcml2ZXJzL25ldC94
ZW4tbmV0YmFjay9uZXRiYWNrLmMKPiA+IGluZGV4IGQxMTIwNWYuLjMwNTk2ODQgMTAwNjQ0Cj4g
PiAtLS0gYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKPiA+ICsrKyBiL2RyaXZl
cnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwo+ID4gQEAgLTE2NzAsNSArMTY3MCwxOSBAQCBm
YWlsZWRfaW5pdDoKPiA+ICAKPiA+ICBtb2R1bGVfaW5pdChuZXRiYWNrX2luaXQpOwo+ID4gIAo+
IAo+IFdoaWxlIHJldmlld2luZyB0aGlzIGNvZGUsIEkgY2FuIHNlZSBjdXJyZW50IG5ldGJhY2tf
aW5pdCgpIGlzIGJ1Z2d5Lgo+IAo+IEl0IGFzc3VtZXMgYWxsIG9ubGluZSBjcHVzIHhlbl9uZXRi
a19ncm91cF9uciBhcmUgbnVtYmVyZWQgZnJvbSAwIHRvCj4geGVuX25ldGJrX2dyb3VwX25yLTEK
PiAKPiBUaGlzIGlzIG5vdCByaWdodC4KPiAKCllvdSdyZSByaWdodCBhYm91dCB0aGlzLgoKQnV0
IHRoaXMgcGFydCBpcyBkZXN0aW5lZCB0byBnZXQgd2lwZWQgb3V0IChpbiB0aGUgdmVyeSBuZWFy
IGZ1dHVyZT8pIC0tCnNlZSBmb2xsb3dpbmcgcGF0Y2hlcy4gU28gSSBkb24ndCB0aGluayBpdCBp
cyB3b3J0aHkgdG8gZml4IHRoaXMuCgoKV2VpLgoKPiBJbnN0ZWFkIG9mIHVzaW5nIDoKPiAKPiB4
ZW5fbmV0YmsgPSB2emFsbG9jKHNpemVvZihzdHJ1Y3QgeGVuX25ldGJrKSAqIHhlbl9uZXRia19n
cm91cF9ucik7Cj4gCj4gWW91IHNob3VsZCB1c2UgYSBwZXJjcHUgdmFyaWFibGUgdG8gZ2V0IHBy
b3BlciBOVU1BIHByb3BlcnRpZXMuCj4gCj4gQW5kIGluc3RlYWQgb2YgbG9vcGluZyBsaWtlIDoK
PiAKPiBmb3IgKGdyb3VwID0gMDsgZ3JvdXAgPCB4ZW5fbmV0YmtfZ3JvdXBfbnI7IGdyb3VwKysp
IHsKPiAKPiBZb3UgbXVzdCB1c2UgOgo+IAo+IGZvcl9lYWNoX29ubGluZV9jcHUoY3B1KSB7Cj4g
CS4uLgo+IH0KPiAKPiBbIGFuZCBhbHNvIHVzZSBrdGhyZWFkX2NyZWF0ZV9vbl9ub2RlKCkgaW5z
dGVhZCBvZiBrdGhyZWFkX2NyZWF0ZSgpIF0KPiAKPiAKPiAKCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17: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.xensource.com>)
	id 1Rt0SI-0005th-M1; Thu, 02 Feb 2012 17:28:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rt0SI-0005tH-0F
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:28:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328203669!51339933!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29083 invoked from network); 2 Feb 2012 17:27:49 -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;
	2 Feb 2012 17:27:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,610,1320624000"; d="scan'208";a="10448803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 17:28:11 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	17:28:11 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Thu, 2 Feb 2012 17:28:30 +0000
Message-ID: <1328203710.5553.94.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAyLTAyIGF0IDE3OjA4ICswMDAwLCBFcmljIER1bWF6ZXQgd3JvdGU6Cj4g
TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNjo0OSArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cj4gPiBFbmFibGVzIHVzZXJzIHRvIHVubG9hZCBuZXRiYWNrIG1vZHVsZS4KPiA+IAo+ID4g
UmV2aWV3ZWQtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNv
bT4KPiA+IFRlc3RlZC1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFj
bGUuY29tPgo+ID4gU2lnbmVkLW9mZi1ieTogV2VpIExpdSA8d2VpLmxpdTJAY2l0cml4LmNvbT4K
PiA+IC0tLQo+ID4gIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oICB8ICAgIDEgKwo+
ID4gIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYyB8ICAgMTQgKysrKysrKysrKysr
KysKPiA+ICBkcml2ZXJzL25ldC94ZW4tbmV0YmFjay94ZW5idXMuYyAgfCAgICA1ICsrKysrCj4g
PiAgMyBmaWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQo+ID4g
Cj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svY29tbW9uLmggYi9kcml2
ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaAo+ID4gaW5kZXggMjg4YjJmMy4uMzcyYzdmNSAx
MDA2NDQKPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oCj4gPiArKysg
Yi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaAo+ID4gQEAgLTEyNiw2ICsxMjYsNyBA
QCB2b2lkIHhlbnZpZl9nZXQoc3RydWN0IHhlbnZpZiAqdmlmKTsKPiA+ICB2b2lkIHhlbnZpZl9w
dXQoc3RydWN0IHhlbnZpZiAqdmlmKTsKPiA+ICAKPiA+ICBpbnQgeGVudmlmX3hlbmJ1c19pbml0
KHZvaWQpOwo+ID4gK3ZvaWQgeGVudmlmX3hlbmJ1c19leGl0KHZvaWQpOwo+ID4gIAo+ID4gIGlu
dCB4ZW52aWZfc2NoZWR1bGFibGUoc3RydWN0IHhlbnZpZiAqdmlmKTsKPiA+ICAKPiA+IGRpZmYg
LS1naXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMgYi9kcml2ZXJzL25ldC94
ZW4tbmV0YmFjay9uZXRiYWNrLmMKPiA+IGluZGV4IGQxMTIwNWYuLjMwNTk2ODQgMTAwNjQ0Cj4g
PiAtLS0gYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKPiA+ICsrKyBiL2RyaXZl
cnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwo+ID4gQEAgLTE2NzAsNSArMTY3MCwxOSBAQCBm
YWlsZWRfaW5pdDoKPiA+ICAKPiA+ICBtb2R1bGVfaW5pdChuZXRiYWNrX2luaXQpOwo+ID4gIAo+
IAo+IFdoaWxlIHJldmlld2luZyB0aGlzIGNvZGUsIEkgY2FuIHNlZSBjdXJyZW50IG5ldGJhY2tf
aW5pdCgpIGlzIGJ1Z2d5Lgo+IAo+IEl0IGFzc3VtZXMgYWxsIG9ubGluZSBjcHVzIHhlbl9uZXRi
a19ncm91cF9uciBhcmUgbnVtYmVyZWQgZnJvbSAwIHRvCj4geGVuX25ldGJrX2dyb3VwX25yLTEK
PiAKPiBUaGlzIGlzIG5vdCByaWdodC4KPiAKCllvdSdyZSByaWdodCBhYm91dCB0aGlzLgoKQnV0
IHRoaXMgcGFydCBpcyBkZXN0aW5lZCB0byBnZXQgd2lwZWQgb3V0IChpbiB0aGUgdmVyeSBuZWFy
IGZ1dHVyZT8pIC0tCnNlZSBmb2xsb3dpbmcgcGF0Y2hlcy4gU28gSSBkb24ndCB0aGluayBpdCBp
cyB3b3J0aHkgdG8gZml4IHRoaXMuCgoKV2VpLgoKPiBJbnN0ZWFkIG9mIHVzaW5nIDoKPiAKPiB4
ZW5fbmV0YmsgPSB2emFsbG9jKHNpemVvZihzdHJ1Y3QgeGVuX25ldGJrKSAqIHhlbl9uZXRia19n
cm91cF9ucik7Cj4gCj4gWW91IHNob3VsZCB1c2UgYSBwZXJjcHUgdmFyaWFibGUgdG8gZ2V0IHBy
b3BlciBOVU1BIHByb3BlcnRpZXMuCj4gCj4gQW5kIGluc3RlYWQgb2YgbG9vcGluZyBsaWtlIDoK
PiAKPiBmb3IgKGdyb3VwID0gMDsgZ3JvdXAgPCB4ZW5fbmV0YmtfZ3JvdXBfbnI7IGdyb3VwKysp
IHsKPiAKPiBZb3UgbXVzdCB1c2UgOgo+IAo+IGZvcl9lYWNoX29ubGluZV9jcHUoY3B1KSB7Cj4g
CS4uLgo+IH0KPiAKPiBbIGFuZCBhbHNvIHVzZSBrdGhyZWFkX2NyZWF0ZV9vbl9ub2RlKCkgaW5z
dGVhZCBvZiBrdGhyZWFkX2NyZWF0ZSgpIF0KPiAKPiAKPiAKCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:47:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt0kB-0006ZT-Fz; Thu, 02 Feb 2012 17:46:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rt0k9-0006ZJ-KV
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:46:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328204795!13072317!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI0ODMz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13209 invoked from network); 2 Feb 2012 17:46:37 -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; 2 Feb 2012 17:46:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q12HkCfQ012438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 2 Feb 2012 17:46:13 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q12Hk98w014602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 2 Feb 2012 17:46:09 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q12Hk7Om019709; Thu, 2 Feb 2012 11:46:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 02 Feb 2012 09:46:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D6D040465; Thu,  2 Feb 2012 12:43:30 -0500 (EST)
Date: Thu, 2 Feb 2012 12:43:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Message-ID: <20120202174330.GA9311@phenom.dumpdata.com>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120201222250.GA3854@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120201222250.GA3854@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F2ACBE6.0093,ss=1,re=0.000,fgs=0
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 02:22:50PM -0800, Greg KH wrote:
> On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> > When I bring a CPU down in a guest (which should be the same as bringing a
> > CPU down using the ACPI framework), I get this:
> > 
> > [   14.484206] SMP alternatives: switching to UP code
> > [   14.514287] ------------[ cut here ]------------
> > [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> > [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> > [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> > [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> > [   14.514586] Call Trace:
> > [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> > [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> > [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> > [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> > [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> > [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> > [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> > [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> > [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> > [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> > [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> > [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> > [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> > [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> > [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> > [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> > [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> > [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> > 
> > Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> > Author: Greg Kroah-Hartman <gregkh@suse.de>
> > Date:   Mon Jan 16 14:40:28 2012 -0800
> > 
> >     mce: fix warning messages about static struct mce_device
> > "
> > 
> > it looks like the corret fix is to make the 'cpu_devices' in
> > arch/x86/kernel/topology.c to be changed to be more dynamic
> > (or perhaps have an empty release function)?
> > 
> > Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> > the privilige of being the first? Oh, I hadn't done a full bisection
> > but v3.2 does not have this.
> 
> Does the patch below solve the problem for you?

Hey Greg,

Indeed it does.

For the patch below, please put 'Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>'

Thanks!
> 
> thanks,
> 
> greg k-h
> 
> 
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index db87e78..23f2c4c 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -208,6 +208,25 @@ static ssize_t print_cpus_offline(struct device *dev,
>  }
>  static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
>  
> +static void cpu_device_release(struct device *dev)
> +{
> +	/*
> +	 * This is an empty function to prevent the driver core from spitting a
> +	 * warning at us.  Yes, I know this is directly opposite of what the
> +	 * documentation for the driver core and kobjects say, and the author
> +	 * of this code has already been publically ridiculed for doing
> +	 * something as foolish as this.  However, at this point in time, it is
> +	 * the only way to handle the issue of statically allocated cpu
> +	 * devices.  The different architectures will have their cpu device
> +	 * code reworked to properly handle this in the near future, so this
> +	 * function will then be changed to correctly free up the memory held
> +	 * by the cpu device.
> +	 *
> +	 * Never copy this way of doing things, or you too will be made fun of
> +	 * on the linux-kerenl list, you have been warned.
> +	 */
> +}
> +
>  /*
>   * register_cpu - Setup a sysfs device for a CPU.
>   * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
> @@ -223,6 +242,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
>  	cpu->node_id = cpu_to_node(num);
>  	cpu->dev.id = num;
>  	cpu->dev.bus = &cpu_subsys;
> +	cpu->dev.release = cpu_device_release;
>  	error = device_register(&cpu->dev);
>  	if (!error && cpu->hotpluggable)
>  		register_cpu_control(cpu);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:47:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt0kB-0006ZT-Fz; Thu, 02 Feb 2012 17:46:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rt0k9-0006ZJ-KV
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:46:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328204795!13072317!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI0ODMz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13209 invoked from network); 2 Feb 2012 17:46:37 -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; 2 Feb 2012 17:46:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q12HkCfQ012438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 2 Feb 2012 17:46:13 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q12Hk98w014602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 2 Feb 2012 17:46:09 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q12Hk7Om019709; Thu, 2 Feb 2012 11:46:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 02 Feb 2012 09:46:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D6D040465; Thu,  2 Feb 2012 12:43:30 -0500 (EST)
Date: Thu, 2 Feb 2012 12:43:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Message-ID: <20120202174330.GA9311@phenom.dumpdata.com>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120201222250.GA3854@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120201222250.GA3854@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F2ACBE6.0093,ss=1,re=0.000,fgs=0
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 01, 2012 at 02:22:50PM -0800, Greg KH wrote:
> On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> > When I bring a CPU down in a guest (which should be the same as bringing a
> > CPU down using the ACPI framework), I get this:
> > 
> > [   14.484206] SMP alternatives: switching to UP code
> > [   14.514287] ------------[ cut here ]------------
> > [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> > [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> > [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> > [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> > [   14.514586] Call Trace:
> > [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> > [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> > [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> > [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> > [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> > [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> > [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> > [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> > [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> > [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> > [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> > [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> > [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> > [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> > [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> > [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> > [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> > [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> > 
> > Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> > Author: Greg Kroah-Hartman <gregkh@suse.de>
> > Date:   Mon Jan 16 14:40:28 2012 -0800
> > 
> >     mce: fix warning messages about static struct mce_device
> > "
> > 
> > it looks like the corret fix is to make the 'cpu_devices' in
> > arch/x86/kernel/topology.c to be changed to be more dynamic
> > (or perhaps have an empty release function)?
> > 
> > Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> > the privilige of being the first? Oh, I hadn't done a full bisection
> > but v3.2 does not have this.
> 
> Does the patch below solve the problem for you?

Hey Greg,

Indeed it does.

For the patch below, please put 'Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>'

Thanks!
> 
> thanks,
> 
> greg k-h
> 
> 
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index db87e78..23f2c4c 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -208,6 +208,25 @@ static ssize_t print_cpus_offline(struct device *dev,
>  }
>  static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
>  
> +static void cpu_device_release(struct device *dev)
> +{
> +	/*
> +	 * This is an empty function to prevent the driver core from spitting a
> +	 * warning at us.  Yes, I know this is directly opposite of what the
> +	 * documentation for the driver core and kobjects say, and the author
> +	 * of this code has already been publically ridiculed for doing
> +	 * something as foolish as this.  However, at this point in time, it is
> +	 * the only way to handle the issue of statically allocated cpu
> +	 * devices.  The different architectures will have their cpu device
> +	 * code reworked to properly handle this in the near future, so this
> +	 * function will then be changed to correctly free up the memory held
> +	 * by the cpu device.
> +	 *
> +	 * Never copy this way of doing things, or you too will be made fun of
> +	 * on the linux-kerenl list, you have been warned.
> +	 */
> +}
> +
>  /*
>   * register_cpu - Setup a sysfs device for a CPU.
>   * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
> @@ -223,6 +242,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
>  	cpu->node_id = cpu_to_node(num);
>  	cpu->dev.id = num;
>  	cpu->dev.bus = &cpu_subsys;
> +	cpu->dev.release = cpu_device_release;
>  	error = device_register(&cpu->dev);
>  	if (!error && cpu->hotpluggable)
>  		register_cpu_control(cpu);

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:49:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17: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.xensource.com>)
	id 1Rt0mS-0006gA-1N; Thu, 02 Feb 2012 17:49:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt0mQ-0006g1-AX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:49:06 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328204940!13473296!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28831 invoked from network); 2 Feb 2012 17:49:00 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 17:49:00 -0000
Received: by wibhm2 with SMTP id hm2so5138502wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 09:48:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=GC2fHriSa40QoNj6hNpt1TdWQo7GGTi2q9JZ+jcRlBo=;
	b=F/4TVcYnkfZbz9FEFJMFq4Y1Sds7Z+VYLTXU9XDBooeUh4p3ZBmSDaprchtqRbPIAh
	s9Obf7hGjLEdyrmq20QbBPeV1Qio0iR4yznCZNzqRxtFRw2f4qjiThREWRGk9yZ6076Z
	icDWLohllBEitrofj06Dj0l2bp7cXUft3KOeY=
Received: by 10.180.24.166 with SMTP id v6mr19629484wif.10.1328204939927;
	Thu, 02 Feb 2012 09:48:59 -0800 (PST)
Received: from [10.150.51.216] (gw0.net.jmsp.net. [212.23.165.14])
	by mx.google.com with ESMTPS id m8sm9133937wia.11.2012.02.02.09.48.57
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:48:58 -0800 (PST)
Message-ID: <1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 02 Feb 2012 18:48:56 +0100
In-Reply-To: <1328203710.5553.94.camel@leeds.uk.xensource.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNzoyOCArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cgo+IFlvdSdyZSByaWdodCBhYm91dCB0aGlzLgo+IAo+IEJ1dCB0aGlzIHBhcnQgaXMgZGVz
dGluZWQgdG8gZ2V0IHdpcGVkIG91dCAoaW4gdGhlIHZlcnkgbmVhciBmdXR1cmU/KSAtLQo+IHNl
ZSBmb2xsb3dpbmcgcGF0Y2hlcy4gU28gSSBkb24ndCB0aGluayBpdCBpcyB3b3J0aHkgdG8gZml4
IHRoaXMuCj4gCgpCZWZvcmUgYWRkaW5nIG5ldyBidWdzLCB5b3UgbXVzdCBmaXggcHJldmlvdXMg
b25lcy4KCkRvIHlvdSB0aGluayBzdGFibGUgdGVhbXMgd2lsbCBkbyB0aGUgYmFja3BvcnQgb2Yg
YWxsIHlvdXIgdXBjb21pbmcKcGF0Y2hlcyA/CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 02 17:49:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 17: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.xensource.com>)
	id 1Rt0mS-0006gA-1N; Thu, 02 Feb 2012 17:49:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt0mQ-0006g1-AX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 17:49:06 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328204940!13473296!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28831 invoked from network); 2 Feb 2012 17:49:00 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 17:49:00 -0000
Received: by wibhm2 with SMTP id hm2so5138502wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 09:48:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=GC2fHriSa40QoNj6hNpt1TdWQo7GGTi2q9JZ+jcRlBo=;
	b=F/4TVcYnkfZbz9FEFJMFq4Y1Sds7Z+VYLTXU9XDBooeUh4p3ZBmSDaprchtqRbPIAh
	s9Obf7hGjLEdyrmq20QbBPeV1Qio0iR4yznCZNzqRxtFRw2f4qjiThREWRGk9yZ6076Z
	icDWLohllBEitrofj06Dj0l2bp7cXUft3KOeY=
Received: by 10.180.24.166 with SMTP id v6mr19629484wif.10.1328204939927;
	Thu, 02 Feb 2012 09:48:59 -0800 (PST)
Received: from [10.150.51.216] (gw0.net.jmsp.net. [212.23.165.14])
	by mx.google.com with ESMTPS id m8sm9133937wia.11.2012.02.02.09.48.57
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:48:58 -0800 (PST)
Message-ID: <1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 02 Feb 2012 18:48:56 +0100
In-Reply-To: <1328203710.5553.94.camel@leeds.uk.xensource.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxNzoyOCArMDAwMCwgV2VpIExpdSBhIMOpY3Jp
dCA6Cgo+IFlvdSdyZSByaWdodCBhYm91dCB0aGlzLgo+IAo+IEJ1dCB0aGlzIHBhcnQgaXMgZGVz
dGluZWQgdG8gZ2V0IHdpcGVkIG91dCAoaW4gdGhlIHZlcnkgbmVhciBmdXR1cmU/KSAtLQo+IHNl
ZSBmb2xsb3dpbmcgcGF0Y2hlcy4gU28gSSBkb24ndCB0aGluayBpdCBpcyB3b3J0aHkgdG8gZml4
IHRoaXMuCj4gCgpCZWZvcmUgYWRkaW5nIG5ldyBidWdzLCB5b3UgbXVzdCBmaXggcHJldmlvdXMg
b25lcy4KCkRvIHlvdSB0aGluayBzdGFibGUgdGVhbXMgd2lsbCBkbyB0aGUgYmFja3BvcnQgb2Yg
YWxsIHlvdXIgdXBjb21pbmcKcGF0Y2hlcyA/CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 02 18:35:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 18: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.xensource.com>)
	id 1Rt1V0-0008Ex-3n; Thu, 02 Feb 2012 18:35: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 1Rt1Uy-0008Es-OD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 18:35:09 +0000
Received: from [85.158.138.51:55358] by server-7.bemta-3.messagelabs.com id
	C2/5A-28646-B57DA2F4; Thu, 02 Feb 2012 18:35:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328207706!11601491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16021 invoked from network); 2 Feb 2012 18:35:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 18:35:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208";a="10450967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 18:35:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 18:35:06 +0000
Date: Thu, 2 Feb 2012 18:37:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <94532199f647fc03816f.1328189220@debian.localdomain>
Message-ID: <alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<94532199f647fc03816f.1328189220@debian.localdomain>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add
 libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2 Feb 2012, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1328179686 -3600
> # Node ID 94532199f647fc03816fc5ae50ab53c8c5b80cd8
> # Parent  1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
> libxl: add libxl_hotplug_dispatch
> 
> Added a new function to libxl API to handle device hotplug. Actions to
> execute upon hotplug device state changes are handled using the
> libxl_device_disk_hotplug_actions and libxl_device_nic_hotplug_actions
> depending on the type of device. Currently only VIF and VBD devices
> are handled by the hotplug mechanism.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c       Thu Feb 02 11:45:03 2012 +0100
> +++ b/tools/libxl/libxl.c       Thu Feb 02 11:48:06 2012 +0100
> @@ -982,6 +982,188 @@ out:
>      return rc;
>  }
> 
> +static int libxl__hotplug_generic_dispatcher(libxl__gc *gc, char *path,
> +                                uint32_t domid,
> +                                libxl__hotplug_status state,
> +                                libxl__device_generic_hotplug_actions *action,
> +                                void *device)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *spath = libxl__sprintf(gc, "%s/state", path);
> +    int rc = 0;
> +
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "processing device %s with state %d",
> +                                      path, state);
> +    switch(state) {
> +    case HOTPLUG_DEVICE_INIT:
> +        if (action->init) {
> +            rc = action->init(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to init"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECT);
> +        break;
> +    case HOTPLUG_DEVICE_CONNECT:
> +        if (action->connect) {
> +            rc = action->connect(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to connect"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECTED);
> +        break;
> +    case HOTPLUG_DEVICE_CONNECTED:
> +        if (action->connected) {
> +            rc = action->connected(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> +                                                  "connected action on"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        break;
> +    case HOTPLUG_DEVICE_DISCONNECT:
> +        if (action->disconnect) {
> +            rc = action->disconnect(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to unplug"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                        HOTPLUG_DEVICE_DISCONNECTED);
> +        break;
> +    case HOTPLUG_DEVICE_DISCONNECTED:
> +        if (action->disconnected) {
> +            rc = action->disconnected(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> +                                                  "unpluged action on"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        break;
> +    case HOTPLUG_DEVICE_FORCE_DISCONNECT:
> +        if (action->force_disconnect) {
> +            rc = action->force_disconnect(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to force "
> +                                                  "disconnect device "
> +                                                  "%s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                        HOTPLUG_DEVICE_DISCONNECTED);
> +        break;
> +    case HOTPLUG_DEVICE_ERROR:
> +        if (action->error)
> +            rc = action->error(ctx, domid, device);
> +        break;
> +    }
> +    return rc;

I can see that we are writing an error code to xenstore in case of
errors, but I fail to see where we are writing back a positive response.
Of course the caller of libxl_device_disk/nic_hotplug_add could watch
the backend state waiting for it to come up, but I think that having an
explicit ACK under /hotplug would be much better.

I haven't reviewed all the patches in detail but I think that this
series is going in the right thing direction, from the architectural
point of view.
The main requests for changes will probably be regarding event handling
and the usage of the new APIs.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 18:35:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 18: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.xensource.com>)
	id 1Rt1V0-0008Ex-3n; Thu, 02 Feb 2012 18:35: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 1Rt1Uy-0008Es-OD
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 18:35:09 +0000
Received: from [85.158.138.51:55358] by server-7.bemta-3.messagelabs.com id
	C2/5A-28646-B57DA2F4; Thu, 02 Feb 2012 18:35:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328207706!11601491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16021 invoked from network); 2 Feb 2012 18:35:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 18:35:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208";a="10450967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 18:35:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 18:35:06 +0000
Date: Thu, 2 Feb 2012 18:37:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <94532199f647fc03816f.1328189220@debian.localdomain>
Message-ID: <alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<94532199f647fc03816f.1328189220@debian.localdomain>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add
 libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2 Feb 2012, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1328179686 -3600
> # Node ID 94532199f647fc03816fc5ae50ab53c8c5b80cd8
> # Parent  1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
> libxl: add libxl_hotplug_dispatch
> 
> Added a new function to libxl API to handle device hotplug. Actions to
> execute upon hotplug device state changes are handled using the
> libxl_device_disk_hotplug_actions and libxl_device_nic_hotplug_actions
> depending on the type of device. Currently only VIF and VBD devices
> are handled by the hotplug mechanism.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c       Thu Feb 02 11:45:03 2012 +0100
> +++ b/tools/libxl/libxl.c       Thu Feb 02 11:48:06 2012 +0100
> @@ -982,6 +982,188 @@ out:
>      return rc;
>  }
> 
> +static int libxl__hotplug_generic_dispatcher(libxl__gc *gc, char *path,
> +                                uint32_t domid,
> +                                libxl__hotplug_status state,
> +                                libxl__device_generic_hotplug_actions *action,
> +                                void *device)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *spath = libxl__sprintf(gc, "%s/state", path);
> +    int rc = 0;
> +
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "processing device %s with state %d",
> +                                      path, state);
> +    switch(state) {
> +    case HOTPLUG_DEVICE_INIT:
> +        if (action->init) {
> +            rc = action->init(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to init"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECT);
> +        break;
> +    case HOTPLUG_DEVICE_CONNECT:
> +        if (action->connect) {
> +            rc = action->connect(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to connect"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECTED);
> +        break;
> +    case HOTPLUG_DEVICE_CONNECTED:
> +        if (action->connected) {
> +            rc = action->connected(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> +                                                  "connected action on"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        break;
> +    case HOTPLUG_DEVICE_DISCONNECT:
> +        if (action->disconnect) {
> +            rc = action->disconnect(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to unplug"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                        HOTPLUG_DEVICE_DISCONNECTED);
> +        break;
> +    case HOTPLUG_DEVICE_DISCONNECTED:
> +        if (action->disconnected) {
> +            rc = action->disconnected(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> +                                                  "unpluged action on"
> +                                                  " device %s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        break;
> +    case HOTPLUG_DEVICE_FORCE_DISCONNECT:
> +        if (action->force_disconnect) {
> +            rc = action->force_disconnect(ctx, domid, device);
> +            if (rc < 0) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to force "
> +                                                  "disconnect device "
> +                                                  "%s", path);
> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                                HOTPLUG_DEVICE_ERROR);
> +                break;
> +            }
> +        }
> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> +                        HOTPLUG_DEVICE_DISCONNECTED);
> +        break;
> +    case HOTPLUG_DEVICE_ERROR:
> +        if (action->error)
> +            rc = action->error(ctx, domid, device);
> +        break;
> +    }
> +    return rc;

I can see that we are writing an error code to xenstore in case of
errors, but I fail to see where we are writing back a positive response.
Of course the caller of libxl_device_disk/nic_hotplug_add could watch
the backend state waiting for it to come up, but I think that having an
explicit ACK under /hotplug would be much better.

I haven't reviewed all the patches in detail but I think that this
series is going in the right thing direction, from the architectural
point of view.
The main requests for changes will probably be regarding event handling
and the usage of the new APIs.

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 18:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 18: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.xensource.com>)
	id 1Rt1ez-0008RZ-Lo; Thu, 02 Feb 2012 18:45:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rt1ex-0008RU-MU
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 18:45:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328208317!15072887!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13122 invoked from network); 2 Feb 2012 18:45:19 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 18:45:19 -0000
Received: by pbds6 with SMTP id s6so16493656pbd.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 10:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=y+KZxPj2PZ0rDjM722ixwCedMFZ9sOgn64JRXPa+k3k=;
	b=HiryrBCidLt7tkKpSVG8jQBBXS8MapA8atktT0t+u+1bcGfGtQntb2zVJJ8qJBfoCA
	NF3E/TktNuBP6lOoGmNU4U+VdqQwYT0T31csc7u+k2Cb5AiwPLw1oE0QIAc+rQU+X26y
	QMZi0SN/VjWyaI0qZy2BeiYfrpD03yjVc55P4=
MIME-Version: 1.0
Received: by 10.68.218.231 with SMTP id pj7mr9964508pbc.63.1328208316909; Thu,
	02 Feb 2012 10:45:16 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Thu, 2 Feb 2012 10:45:16 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<94532199f647fc03816f.1328189220@debian.localdomain>
	<alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
Date: Thu, 2 Feb 2012 19:45:16 +0100
X-Google-Sender-Auth: bbZ8pys15AfNxw8WRtwtS_ENq5U
Message-ID: <CAPLaKK6Kf7+oBNFZsk6cr=7FRXWEMU7NojoQ=OrBVQ7Za6hw6w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add
	libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIgU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4
LmNvbT46Cj4gT24gVGh1LCAyIEZlYiAyMDEyLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyODE3OTY4NiAtMzYwMAo+PiAjIE5vZGUgSUQgOTQ1
MzIxOTlmNjQ3ZmMwMzgxNmZjNWFlNTBhYjUzYzhjNWI4MGNkOAo+PiAjIFBhcmVudCDCoDE1MDZi
MWYyYWIwZmU1ZjRjZDViY2Q4NmE1NjZkNWE3YmU1ZjgzOGIKPj4gbGlieGw6IGFkZCBsaWJ4bF9o
b3RwbHVnX2Rpc3BhdGNoCj4+Cj4+IEFkZGVkIGEgbmV3IGZ1bmN0aW9uIHRvIGxpYnhsIEFQSSB0
byBoYW5kbGUgZGV2aWNlIGhvdHBsdWcuIEFjdGlvbnMgdG8KPj4gZXhlY3V0ZSB1cG9uIGhvdHBs
dWcgZGV2aWNlIHN0YXRlIGNoYW5nZXMgYXJlIGhhbmRsZWQgdXNpbmcgdGhlCj4+IGxpYnhsX2Rl
dmljZV9kaXNrX2hvdHBsdWdfYWN0aW9ucyBhbmQgbGlieGxfZGV2aWNlX25pY19ob3RwbHVnX2Fj
dGlvbnMKPj4gZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIGRldmljZS4gQ3VycmVudGx5IG9ubHkg
VklGIGFuZCBWQkQgZGV2aWNlcwo+PiBhcmUgaGFuZGxlZCBieSB0aGUgaG90cGx1ZyBtZWNoYW5p
c20uCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVs
LnVwYy5lZHU+Cj4+Cj4+IGRpZmYgLXIgMTUwNmIxZjJhYjBmIC1yIDk0NTMyMTk5ZjY0NyB0b29s
cy9saWJ4bC9saWJ4bC5jCj4+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMgwqAgwqAgwqAgVGh1
IEZlYiAwMiAxMTo0NTowMyAyMDEyICswMTAwCj4+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMg
wqAgwqAgwqAgVGh1IEZlYiAwMiAxMTo0ODowNiAyMDEyICswMTAwCj4+IEBAIC05ODIsNiArOTgy
LDE4OCBAQCBvdXQ6Cj4+IMKgIMKgIMKgcmV0dXJuIHJjOwo+PiDCoH0KPj4KPj4gK3N0YXRpYyBp
bnQgbGlieGxfX2hvdHBsdWdfZ2VuZXJpY19kaXNwYXRjaGVyKGxpYnhsX19nYyAqZ2MsIGNoYXIg
KnBhdGgsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqB1aW50MzJfdCBkb21pZCwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoGxpYnhsX19ob3RwbHVnX3N0YXR1cyBzdGF0ZSwKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19kZXZpY2VfZ2VuZXJp
Y19ob3RwbHVnX2FjdGlvbnMgKmFjdGlvbiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZvaWQgKmRldmljZSkKPj4gK3sKPj4gKyDCoCDCoGxpYnhs
X2N0eCAqY3R4ID0gbGlieGxfX2djX293bmVyKGdjKTsKPj4gKyDCoCDCoGNoYXIgKnNwYXRoID0g
bGlieGxfX3NwcmludGYoZ2MsICIlcy9zdGF0ZSIsIHBhdGgpOwo+PiArIMKgIMKgaW50IHJjID0g
MDsKPj4gKwo+PiArIMKgIMKgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfREVCVUcsICJwcm9j
ZXNzaW5nIGRldmljZSAlcyB3aXRoIHN0YXRlICVkIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhdGgsIHN0YXRlKTsKPj4gKyDC
oCDCoHN3aXRjaChzdGF0ZSkgewo+PiArIMKgIMKgY2FzZSBIT1RQTFVHX0RFVklDRV9JTklUOgo+
PiArIMKgIMKgIMKgIMKgaWYgKGFjdGlvbi0+aW5pdCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
cmMgPSBhY3Rpb24tPmluaXQoY3R4LCBkb21pZCwgZGV2aWNlKTsKPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoGlmIChyYyA8IDApIHsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExJQlhMX19MT0co
Y3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGluaXQiCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAiIGRldmljZSAlcyIsIHBhdGgpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGli
eGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgc3BhdGgsICIlZCIsCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBIT1RQTFVHX0RFVklDRV9FUlJPUik7
Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoCDCoCDCoCDCoCDC
oH0KPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoGxpYnhsX194c193cml0ZShnYywg
WEJUX05VTEwsIHNwYXRoLCAiJWQiLCBIT1RQTFVHX0RFVklDRV9DT05ORUNUKTsKPj4gKyDCoCDC
oCDCoCDCoGJyZWFrOwo+PiArIMKgIMKgY2FzZSBIT1RQTFVHX0RFVklDRV9DT05ORUNUOgo+PiAr
IMKgIMKgIMKgIMKgaWYgKGFjdGlvbi0+Y29ubmVjdCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
cmMgPSBhY3Rpb24tPmNvbm5lY3QoY3R4LCBkb21pZCwgZGV2aWNlKTsKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoGlmIChyYyA8IDApIHsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExJQlhMX19M
T0coY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGNvbm5lY3QiCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAiIGRldmljZSAlcyIsIHBhdGgpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgbGlieGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgc3BhdGgsICIlZCIsCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBIT1RQTFVHX0RFVklDRV9F
UlJPUik7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoGxpYnhsX194c193cml0
ZShnYywgWEJUX05VTEwsIHNwYXRoLCAiJWQiLCBIT1RQTFVHX0RFVklDRV9DT05ORUNURUQpOwo+
PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqBjYXNlIEhPVFBMVUdfREVWSUNFX0NPTk5F
Q1RFRDoKPj4gKyDCoCDCoCDCoCDCoGlmIChhY3Rpb24tPmNvbm5lY3RlZCkgewo+PiArIMKgIMKg
IMKgIMKgIMKgIMKgcmMgPSBhY3Rpb24tPmNvbm5lY3RlZChjdHgsIGRvbWlkLCBkZXZpY2UpOwo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgaWYgKHJjIDwgMCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gZXhlY3V0
ZSAiCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiY29ubmVjdGVkIGFjdGlvbiBvbiIKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCIgZGV2aWNlICVzIiwgcGF0aCk7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxMLCBzcGF0aCwgIiVkIiwKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEhPVFBMVUdfREVWSUNF
X0VSUk9SKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJyZWFrOwo+PiArIMKgIMKgIMKg
IMKgIMKgIMKgfQo+PiArIMKgIMKgIMKgIMKgfQo+PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsg
wqAgwqBjYXNlIEhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1Q6Cj4+ICsgwqAgwqAgwqAgwqBpZiAo
YWN0aW9uLT5kaXNjb25uZWN0KSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqByYyA9IGFjdGlvbi0+
ZGlzY29ubmVjdChjdHgsIGRvbWlkLCBkZXZpY2UpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgaWYg
KHJjIDwgMCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTElCWExfX0xPRyhjdHgsIExJ
QlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gdW5wbHVnIgo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IiBkZXZpY2UgJXMiLCBwYXRoKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX194
c193cml0ZShnYywgWEJUX05VTEwsIHNwYXRoLCAiJWQiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSE9UUExVR19ERVZJQ0VfRVJST1IpOwo+PiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqB9Cj4+
ICsgwqAgwqAgwqAgwqB9Cj4+ICsgwqAgwqAgwqAgwqBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9O
VUxMLCBzcGF0aCwgIiVkIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oEhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1RFRCk7Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4g
KyDCoCDCoGNhc2UgSE9UUExVR19ERVZJQ0VfRElTQ09OTkVDVEVEOgo+PiArIMKgIMKgIMKgIMKg
aWYgKGFjdGlvbi0+ZGlzY29ubmVjdGVkKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqByYyA9IGFj
dGlvbi0+ZGlzY29ubmVjdGVkKGN0eCwgZG9taWQsIGRldmljZSk7Cj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqBpZiAocmMgPCAwKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBMSUJYTF9fTE9H
KGN0eCwgTElCWExfX0xPR19FUlJPUiwgInVuYWJsZSB0byBleGVjdXRlICIKPj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCJ1bnBsdWdlZCBhY3Rpb24gb24iCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiIGRl
dmljZSAlcyIsIHBhdGgpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlieGxfX3hzX3dy
aXRlKGdjLCBYQlRfTlVMTCwgc3BhdGgsICIlZCIsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBIT1RQTFVHX0RFVklDRV9FUlJPUik7Cj4+ICsgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoH0KPj4gKyDC
oCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoGJyZWFrOwo+PiArIMKgIMKgY2FzZSBIT1RQTFVH
X0RFVklDRV9GT1JDRV9ESVNDT05ORUNUOgo+PiArIMKgIMKgIMKgIMKgaWYgKGFjdGlvbi0+Zm9y
Y2VfZGlzY29ubmVjdCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKgcmMgPSBhY3Rpb24tPmZvcmNl
X2Rpc2Nvbm5lY3QoY3R4LCBkb21pZCwgZGV2aWNlKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoGlm
IChyYyA8IDApIHsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExJQlhMX19MT0coY3R4LCBM
SUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGZvcmNlICIKPj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCJkaXNjb25uZWN0IGRldmljZSAiCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiJXMiLCBwYXRoKTsK
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX194c193cml0ZShnYywgWEJUX05VTEws
IHNwYXRoLCAiJWQiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgSE9UUExVR19ERVZJQ0VfRVJST1IpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgYnJlYWs7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqB9Cj4+ICsgwqAgwqAgwqAgwqB9Cj4+ICsg
wqAgwqAgwqAgwqBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxMLCBzcGF0aCwgIiVkIiwKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEhPVFBMVUdfREVWSUNFX0RJU0NP
Tk5FQ1RFRCk7Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoGNhc2UgSE9UUExVR19E
RVZJQ0VfRVJST1I6Cj4+ICsgwqAgwqAgwqAgwqBpZiAoYWN0aW9uLT5lcnJvcikKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoHJjID0gYWN0aW9uLT5lcnJvcihjdHgsIGRvbWlkLCBkZXZpY2UpOwo+PiAr
IMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqB9Cj4+ICsgwqAgwqByZXR1cm4gcmM7Cj4KPiBJ
IGNhbiBzZWUgdGhhdCB3ZSBhcmUgd3JpdGluZyBhbiBlcnJvciBjb2RlIHRvIHhlbnN0b3JlIGlu
IGNhc2Ugb2YKPiBlcnJvcnMsIGJ1dCBJIGZhaWwgdG8gc2VlIHdoZXJlIHdlIGFyZSB3cml0aW5n
IGJhY2sgYSBwb3NpdGl2ZSByZXNwb25zZS4KPiBPZiBjb3Vyc2UgdGhlIGNhbGxlciBvZiBsaWJ4
bF9kZXZpY2VfZGlzay9uaWNfaG90cGx1Z19hZGQgY291bGQgd2F0Y2gKPiB0aGUgYmFja2VuZCBz
dGF0ZSB3YWl0aW5nIGZvciBpdCB0byBjb21lIHVwLCBidXQgSSB0aGluayB0aGF0IGhhdmluZyBh
bgo+IGV4cGxpY2l0IEFDSyB1bmRlciAvaG90cGx1ZyB3b3VsZCBiZSBtdWNoIGJldHRlci4KClRo
ZSBTZXF1ZW5jZSBpcyB0aGUgZm9sbG93aW5nLCBidXQgSSdtIG5vdCByZWFsbHkgc3VyZSB0aGlz
IGlzIHRoZQptb3N0IGNvcnJlY3Qgd2F5LiBBbGwgc3RhdGVzIGNhbiBnbyB0byBIT1RQTFVHX0RF
VklDRV9FUlJPUiwgYW5kIHRoZQpmb2xsb3dpbmcgc3RhdGUgY2hhbmdlczoKCkhPVFBMVUdfREVW
SUNFX0lOSVQgbm8gc3RhdGUgY2hhbmdlCkhPVFBMVUdfREVWSUNFX0NPTk5FQ1QgLT4gSE9UUExV
R19ERVZJQ0VfQ09OTkVDVEVEIChvbiBzdWNjZXNzKQpIT1RQTFVHX0RFVklDRV9DT05ORUNURUQg
bm8gY2hhbmdlCkhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1QgLT4gSE9UUExVR19ERVZJQ0VfRElT
Q09OTkVDVEVEIChvbiBzdWNjZXNzKQpIT1RQTFVHX0RFVklDRV9GT1JDRV9ESVNDT05ORUNUIC0+
IEhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1RFRCAob24gc3VjY2VzcykKCgo+IEkgaGF2ZW4ndCBy
ZXZpZXdlZCBhbGwgdGhlIHBhdGNoZXMgaW4gZGV0YWlsIGJ1dCBJIHRoaW5rIHRoYXQgdGhpcwo+
IHNlcmllcyBpcyBnb2luZyBpbiB0aGUgcmlnaHQgdGhpbmcgZGlyZWN0aW9uLCBmcm9tIHRoZSBh
cmNoaXRlY3R1cmFsCj4gcG9pbnQgb2Ygdmlldy4KPiBUaGUgbWFpbiByZXF1ZXN0cyBmb3IgY2hh
bmdlcyB3aWxsIHByb2JhYmx5IGJlIHJlZ2FyZGluZyBldmVudCBoYW5kbGluZwo+IGFuZCB0aGUg
dXNhZ2Ugb2YgdGhlIG5ldyBBUElzLgoKSSBndWVzcyBzbywgd2hlbiBJYW4gSmFja3NvbiBldmVu
dCBBUEkgaXMgYWxsIGluIEkgd2lsbCBwcm9iYWJseSBoYXZlCnRvIHJld3JpdGUgc29tZSBwYXJ0
cyBvZiB0aGUgY29kZS4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 18:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 18: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.xensource.com>)
	id 1Rt1ez-0008RZ-Lo; Thu, 02 Feb 2012 18:45:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rt1ex-0008RU-MU
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 18:45:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328208317!15072887!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13122 invoked from network); 2 Feb 2012 18:45:19 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 18:45:19 -0000
Received: by pbds6 with SMTP id s6so16493656pbd.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 10:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=y+KZxPj2PZ0rDjM722ixwCedMFZ9sOgn64JRXPa+k3k=;
	b=HiryrBCidLt7tkKpSVG8jQBBXS8MapA8atktT0t+u+1bcGfGtQntb2zVJJ8qJBfoCA
	NF3E/TktNuBP6lOoGmNU4U+VdqQwYT0T31csc7u+k2Cb5AiwPLw1oE0QIAc+rQU+X26y
	QMZi0SN/VjWyaI0qZy2BeiYfrpD03yjVc55P4=
MIME-Version: 1.0
Received: by 10.68.218.231 with SMTP id pj7mr9964508pbc.63.1328208316909; Thu,
	02 Feb 2012 10:45:16 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Thu, 2 Feb 2012 10:45:16 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<94532199f647fc03816f.1328189220@debian.localdomain>
	<alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
Date: Thu, 2 Feb 2012 19:45:16 +0100
X-Google-Sender-Auth: bbZ8pys15AfNxw8WRtwtS_ENq5U
Message-ID: <CAPLaKK6Kf7+oBNFZsk6cr=7FRXWEMU7NojoQ=OrBVQ7Za6hw6w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add
	libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIgU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4
LmNvbT46Cj4gT24gVGh1LCAyIEZlYiAyMDEyLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyODE3OTY4NiAtMzYwMAo+PiAjIE5vZGUgSUQgOTQ1
MzIxOTlmNjQ3ZmMwMzgxNmZjNWFlNTBhYjUzYzhjNWI4MGNkOAo+PiAjIFBhcmVudCDCoDE1MDZi
MWYyYWIwZmU1ZjRjZDViY2Q4NmE1NjZkNWE3YmU1ZjgzOGIKPj4gbGlieGw6IGFkZCBsaWJ4bF9o
b3RwbHVnX2Rpc3BhdGNoCj4+Cj4+IEFkZGVkIGEgbmV3IGZ1bmN0aW9uIHRvIGxpYnhsIEFQSSB0
byBoYW5kbGUgZGV2aWNlIGhvdHBsdWcuIEFjdGlvbnMgdG8KPj4gZXhlY3V0ZSB1cG9uIGhvdHBs
dWcgZGV2aWNlIHN0YXRlIGNoYW5nZXMgYXJlIGhhbmRsZWQgdXNpbmcgdGhlCj4+IGxpYnhsX2Rl
dmljZV9kaXNrX2hvdHBsdWdfYWN0aW9ucyBhbmQgbGlieGxfZGV2aWNlX25pY19ob3RwbHVnX2Fj
dGlvbnMKPj4gZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIGRldmljZS4gQ3VycmVudGx5IG9ubHkg
VklGIGFuZCBWQkQgZGV2aWNlcwo+PiBhcmUgaGFuZGxlZCBieSB0aGUgaG90cGx1ZyBtZWNoYW5p
c20uCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVs
LnVwYy5lZHU+Cj4+Cj4+IGRpZmYgLXIgMTUwNmIxZjJhYjBmIC1yIDk0NTMyMTk5ZjY0NyB0b29s
cy9saWJ4bC9saWJ4bC5jCj4+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMgwqAgwqAgwqAgVGh1
IEZlYiAwMiAxMTo0NTowMyAyMDEyICswMTAwCj4+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMg
wqAgwqAgwqAgVGh1IEZlYiAwMiAxMTo0ODowNiAyMDEyICswMTAwCj4+IEBAIC05ODIsNiArOTgy
LDE4OCBAQCBvdXQ6Cj4+IMKgIMKgIMKgcmV0dXJuIHJjOwo+PiDCoH0KPj4KPj4gK3N0YXRpYyBp
bnQgbGlieGxfX2hvdHBsdWdfZ2VuZXJpY19kaXNwYXRjaGVyKGxpYnhsX19nYyAqZ2MsIGNoYXIg
KnBhdGgsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqB1aW50MzJfdCBkb21pZCwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoGxpYnhsX19ob3RwbHVnX3N0YXR1cyBzdGF0ZSwKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19kZXZpY2VfZ2VuZXJp
Y19ob3RwbHVnX2FjdGlvbnMgKmFjdGlvbiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZvaWQgKmRldmljZSkKPj4gK3sKPj4gKyDCoCDCoGxpYnhs
X2N0eCAqY3R4ID0gbGlieGxfX2djX293bmVyKGdjKTsKPj4gKyDCoCDCoGNoYXIgKnNwYXRoID0g
bGlieGxfX3NwcmludGYoZ2MsICIlcy9zdGF0ZSIsIHBhdGgpOwo+PiArIMKgIMKgaW50IHJjID0g
MDsKPj4gKwo+PiArIMKgIMKgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfREVCVUcsICJwcm9j
ZXNzaW5nIGRldmljZSAlcyB3aXRoIHN0YXRlICVkIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhdGgsIHN0YXRlKTsKPj4gKyDC
oCDCoHN3aXRjaChzdGF0ZSkgewo+PiArIMKgIMKgY2FzZSBIT1RQTFVHX0RFVklDRV9JTklUOgo+
PiArIMKgIMKgIMKgIMKgaWYgKGFjdGlvbi0+aW5pdCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
cmMgPSBhY3Rpb24tPmluaXQoY3R4LCBkb21pZCwgZGV2aWNlKTsKPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoGlmIChyYyA8IDApIHsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExJQlhMX19MT0co
Y3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGluaXQiCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAiIGRldmljZSAlcyIsIHBhdGgpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGli
eGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgc3BhdGgsICIlZCIsCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBIT1RQTFVHX0RFVklDRV9FUlJPUik7
Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoCDCoCDCoCDCoCDC
oH0KPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoGxpYnhsX194c193cml0ZShnYywg
WEJUX05VTEwsIHNwYXRoLCAiJWQiLCBIT1RQTFVHX0RFVklDRV9DT05ORUNUKTsKPj4gKyDCoCDC
oCDCoCDCoGJyZWFrOwo+PiArIMKgIMKgY2FzZSBIT1RQTFVHX0RFVklDRV9DT05ORUNUOgo+PiAr
IMKgIMKgIMKgIMKgaWYgKGFjdGlvbi0+Y29ubmVjdCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
cmMgPSBhY3Rpb24tPmNvbm5lY3QoY3R4LCBkb21pZCwgZGV2aWNlKTsKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoGlmIChyYyA8IDApIHsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExJQlhMX19M
T0coY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGNvbm5lY3QiCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAiIGRldmljZSAlcyIsIHBhdGgpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgbGlieGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgc3BhdGgsICIlZCIsCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBIT1RQTFVHX0RFVklDRV9F
UlJPUik7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoGxpYnhsX194c193cml0
ZShnYywgWEJUX05VTEwsIHNwYXRoLCAiJWQiLCBIT1RQTFVHX0RFVklDRV9DT05ORUNURUQpOwo+
PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqBjYXNlIEhPVFBMVUdfREVWSUNFX0NPTk5F
Q1RFRDoKPj4gKyDCoCDCoCDCoCDCoGlmIChhY3Rpb24tPmNvbm5lY3RlZCkgewo+PiArIMKgIMKg
IMKgIMKgIMKgIMKgcmMgPSBhY3Rpb24tPmNvbm5lY3RlZChjdHgsIGRvbWlkLCBkZXZpY2UpOwo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgaWYgKHJjIDwgMCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gZXhlY3V0
ZSAiCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiY29ubmVjdGVkIGFjdGlvbiBvbiIKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCIgZGV2aWNlICVzIiwgcGF0aCk7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxMLCBzcGF0aCwgIiVkIiwKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEhPVFBMVUdfREVWSUNF
X0VSUk9SKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJyZWFrOwo+PiArIMKgIMKgIMKg
IMKgIMKgIMKgfQo+PiArIMKgIMKgIMKgIMKgfQo+PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsg
wqAgwqBjYXNlIEhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1Q6Cj4+ICsgwqAgwqAgwqAgwqBpZiAo
YWN0aW9uLT5kaXNjb25uZWN0KSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqByYyA9IGFjdGlvbi0+
ZGlzY29ubmVjdChjdHgsIGRvbWlkLCBkZXZpY2UpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgaWYg
KHJjIDwgMCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTElCWExfX0xPRyhjdHgsIExJ
QlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gdW5wbHVnIgo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IiBkZXZpY2UgJXMiLCBwYXRoKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX194
c193cml0ZShnYywgWEJUX05VTEwsIHNwYXRoLCAiJWQiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSE9UUExVR19ERVZJQ0VfRVJST1IpOwo+PiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqB9Cj4+
ICsgwqAgwqAgwqAgwqB9Cj4+ICsgwqAgwqAgwqAgwqBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9O
VUxMLCBzcGF0aCwgIiVkIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oEhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1RFRCk7Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4g
KyDCoCDCoGNhc2UgSE9UUExVR19ERVZJQ0VfRElTQ09OTkVDVEVEOgo+PiArIMKgIMKgIMKgIMKg
aWYgKGFjdGlvbi0+ZGlzY29ubmVjdGVkKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqByYyA9IGFj
dGlvbi0+ZGlzY29ubmVjdGVkKGN0eCwgZG9taWQsIGRldmljZSk7Cj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqBpZiAocmMgPCAwKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBMSUJYTF9fTE9H
KGN0eCwgTElCWExfX0xPR19FUlJPUiwgInVuYWJsZSB0byBleGVjdXRlICIKPj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCJ1bnBsdWdlZCBhY3Rpb24gb24iCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiIGRl
dmljZSAlcyIsIHBhdGgpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlieGxfX3hzX3dy
aXRlKGdjLCBYQlRfTlVMTCwgc3BhdGgsICIlZCIsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBIT1RQTFVHX0RFVklDRV9FUlJPUik7Cj4+ICsgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoH0KPj4gKyDC
oCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDCoGJyZWFrOwo+PiArIMKgIMKgY2FzZSBIT1RQTFVH
X0RFVklDRV9GT1JDRV9ESVNDT05ORUNUOgo+PiArIMKgIMKgIMKgIMKgaWYgKGFjdGlvbi0+Zm9y
Y2VfZGlzY29ubmVjdCkgewo+PiArIMKgIMKgIMKgIMKgIMKgIMKgcmMgPSBhY3Rpb24tPmZvcmNl
X2Rpc2Nvbm5lY3QoY3R4LCBkb21pZCwgZGV2aWNlKTsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoGlm
IChyYyA8IDApIHsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExJQlhMX19MT0coY3R4LCBM
SUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGZvcmNlICIKPj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCJkaXNjb25uZWN0IGRldmljZSAiCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiJXMiLCBwYXRoKTsK
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX194c193cml0ZShnYywgWEJUX05VTEws
IHNwYXRoLCAiJWQiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgSE9UUExVR19ERVZJQ0VfRVJST1IpOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgYnJlYWs7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqB9Cj4+ICsgwqAgwqAgwqAgwqB9Cj4+ICsg
wqAgwqAgwqAgwqBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxMLCBzcGF0aCwgIiVkIiwKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEhPVFBMVUdfREVWSUNFX0RJU0NP
Tk5FQ1RFRCk7Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoGNhc2UgSE9UUExVR19E
RVZJQ0VfRVJST1I6Cj4+ICsgwqAgwqAgwqAgwqBpZiAoYWN0aW9uLT5lcnJvcikKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoHJjID0gYWN0aW9uLT5lcnJvcihjdHgsIGRvbWlkLCBkZXZpY2UpOwo+PiAr
IMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqB9Cj4+ICsgwqAgwqByZXR1cm4gcmM7Cj4KPiBJ
IGNhbiBzZWUgdGhhdCB3ZSBhcmUgd3JpdGluZyBhbiBlcnJvciBjb2RlIHRvIHhlbnN0b3JlIGlu
IGNhc2Ugb2YKPiBlcnJvcnMsIGJ1dCBJIGZhaWwgdG8gc2VlIHdoZXJlIHdlIGFyZSB3cml0aW5n
IGJhY2sgYSBwb3NpdGl2ZSByZXNwb25zZS4KPiBPZiBjb3Vyc2UgdGhlIGNhbGxlciBvZiBsaWJ4
bF9kZXZpY2VfZGlzay9uaWNfaG90cGx1Z19hZGQgY291bGQgd2F0Y2gKPiB0aGUgYmFja2VuZCBz
dGF0ZSB3YWl0aW5nIGZvciBpdCB0byBjb21lIHVwLCBidXQgSSB0aGluayB0aGF0IGhhdmluZyBh
bgo+IGV4cGxpY2l0IEFDSyB1bmRlciAvaG90cGx1ZyB3b3VsZCBiZSBtdWNoIGJldHRlci4KClRo
ZSBTZXF1ZW5jZSBpcyB0aGUgZm9sbG93aW5nLCBidXQgSSdtIG5vdCByZWFsbHkgc3VyZSB0aGlz
IGlzIHRoZQptb3N0IGNvcnJlY3Qgd2F5LiBBbGwgc3RhdGVzIGNhbiBnbyB0byBIT1RQTFVHX0RF
VklDRV9FUlJPUiwgYW5kIHRoZQpmb2xsb3dpbmcgc3RhdGUgY2hhbmdlczoKCkhPVFBMVUdfREVW
SUNFX0lOSVQgbm8gc3RhdGUgY2hhbmdlCkhPVFBMVUdfREVWSUNFX0NPTk5FQ1QgLT4gSE9UUExV
R19ERVZJQ0VfQ09OTkVDVEVEIChvbiBzdWNjZXNzKQpIT1RQTFVHX0RFVklDRV9DT05ORUNURUQg
bm8gY2hhbmdlCkhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1QgLT4gSE9UUExVR19ERVZJQ0VfRElT
Q09OTkVDVEVEIChvbiBzdWNjZXNzKQpIT1RQTFVHX0RFVklDRV9GT1JDRV9ESVNDT05ORUNUIC0+
IEhPVFBMVUdfREVWSUNFX0RJU0NPTk5FQ1RFRCAob24gc3VjY2VzcykKCgo+IEkgaGF2ZW4ndCBy
ZXZpZXdlZCBhbGwgdGhlIHBhdGNoZXMgaW4gZGV0YWlsIGJ1dCBJIHRoaW5rIHRoYXQgdGhpcwo+
IHNlcmllcyBpcyBnb2luZyBpbiB0aGUgcmlnaHQgdGhpbmcgZGlyZWN0aW9uLCBmcm9tIHRoZSBh
cmNoaXRlY3R1cmFsCj4gcG9pbnQgb2Ygdmlldy4KPiBUaGUgbWFpbiByZXF1ZXN0cyBmb3IgY2hh
bmdlcyB3aWxsIHByb2JhYmx5IGJlIHJlZ2FyZGluZyBldmVudCBoYW5kbGluZwo+IGFuZCB0aGUg
dXNhZ2Ugb2YgdGhlIG5ldyBBUElzLgoKSSBndWVzcyBzbywgd2hlbiBJYW4gSmFja3NvbiBldmVu
dCBBUEkgaXMgYWxsIGluIEkgd2lsbCBwcm9iYWJseSBoYXZlCnRvIHJld3JpdGUgc29tZSBwYXJ0
cyBvZiB0aGUgY29kZS4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 19:24:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 19: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.xensource.com>)
	id 1Rt2GC-0001Ib-Jx; Thu, 02 Feb 2012 19:23:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rt2GA-0001II-Rg
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:23:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328210628!13496321!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzg5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17895 invoked from network); 2 Feb 2012 19:23:48 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.74) by server-3.tower-182.messagelabs.com with SMTP;
	2 Feb 2012 19:23:48 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id BBCA94B0097;
	Thu,  2 Feb 2012 11:23:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=TDDHOPumuRL//E0/GLbuCi+6mvll16iGrWnSe78XbQ/n
	elBO+ByWRRv9VYjQevGK50XCx+M/WPIgZSnj/g7mQMrqC7CvMs1cQJaeQL4rxF/X
	U7MgEYpolLW32J34d+gh0rp3cmhZ1Rkf07pBl4pYKJUvDr1djuMaVtLKPUDAZqs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=QXUbORhnyVBouHVNJnm6wMcPj0I=; b=KxArhLGU
	TBugxcMu4hkAjHfpeQf6G/azxurSAmSY82tIm1K8wEEz4AtmHDn9Rp1hINNfN4uF
	pDv3Uzer6/iVf8bBzny+hfNNk+FaiN9kI9wvkTWiTVivED9MvOpn9hrUsczfHbGi
	FkS6YNiW+jofMzt/5tU/01L0x41I2HpHxtI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 473534B0091; 
	Thu,  2 Feb 2012 11:23:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 11:23:47 -0800
Message-ID: <ad9e420b897cc380cc1e375d23d70433.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CABFkyn9EYfq7T0cmDDGyUQkpCce7_unLkzOrgDFDDhJHQhtTzw@mail.gmail.com>
References: <CABFkyn9EYfq7T0cmDDGyUQkpCce7_unLkzOrgDFDDhJHQhtTzw@mail.gmail.com>
Date: Thu, 2 Feb 2012 11:23:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Patrick Wilbur" <patrick.wilbur@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Cloning a VM and copy-on-write deduplicating memory
 using CoW page sharing in Xen 4+
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hey all,
> Hey Andres,
>
> I'm looking to clone a VM into several extremely-similar VMs, and I'm
> hoping to also make use of your lovely new CoW page sharing capabilities
> in
> Xen 4.
>
> From my understanding of a previous thread where Andres described the
> process of sharing/coalescing memory between VMs, it sounds like I will
> need to "manually" coalesce each page using a homebrew tool of mine.  The
> issue I have with doing this is it seems like I'd need to pause, save mem,
> load mem in a new VM, coalesce, and resume two VMs, which seems painful
> and
> wasteful of a process for cloning!

Patrick,
that is indeed painful and wasteful. That is why we added
xc_memshr_add_to_physmap. Now you can do Potemkin-/SnowFlock-like cloning
in a few lines of code. You still want the source VM to be paused,
obviously.

Yuengling is my favourite US beer ;)

Andres

>
> Is there an easier way to do this, or should we add a new feature for CoW
> cloning of VMs in Xen via a userspace tool?
>
> Thanks,
> Pat Wilbur & team
>
>
> --
> Patrick F. Wilbur
> Researcher, Consultant, Educator,
> Computer Science Graduate at Clarkson University
>
> DONE RIGHT THE FIRST TIME: Consulting and hiring information:
> http://pdub.net/consulting/ & http://pdub.net/hiring/
>
> patrick.wilbur@gmail.com
> wilburpf@clarkson.edu
>
> Check out our book: http://runningxen.com
> My website: http://pdub.net
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 19:24:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 19: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.xensource.com>)
	id 1Rt2GC-0001Ib-Jx; Thu, 02 Feb 2012 19:23:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rt2GA-0001II-Rg
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:23:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328210628!13496321!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzg5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17895 invoked from network); 2 Feb 2012 19:23:48 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.74) by server-3.tower-182.messagelabs.com with SMTP;
	2 Feb 2012 19:23:48 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id BBCA94B0097;
	Thu,  2 Feb 2012 11:23:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=TDDHOPumuRL//E0/GLbuCi+6mvll16iGrWnSe78XbQ/n
	elBO+ByWRRv9VYjQevGK50XCx+M/WPIgZSnj/g7mQMrqC7CvMs1cQJaeQL4rxF/X
	U7MgEYpolLW32J34d+gh0rp3cmhZ1Rkf07pBl4pYKJUvDr1djuMaVtLKPUDAZqs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=QXUbORhnyVBouHVNJnm6wMcPj0I=; b=KxArhLGU
	TBugxcMu4hkAjHfpeQf6G/azxurSAmSY82tIm1K8wEEz4AtmHDn9Rp1hINNfN4uF
	pDv3Uzer6/iVf8bBzny+hfNNk+FaiN9kI9wvkTWiTVivED9MvOpn9hrUsczfHbGi
	FkS6YNiW+jofMzt/5tU/01L0x41I2HpHxtI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 473534B0091; 
	Thu,  2 Feb 2012 11:23:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 11:23:47 -0800
Message-ID: <ad9e420b897cc380cc1e375d23d70433.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CABFkyn9EYfq7T0cmDDGyUQkpCce7_unLkzOrgDFDDhJHQhtTzw@mail.gmail.com>
References: <CABFkyn9EYfq7T0cmDDGyUQkpCce7_unLkzOrgDFDDhJHQhtTzw@mail.gmail.com>
Date: Thu, 2 Feb 2012 11:23:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Patrick Wilbur" <patrick.wilbur@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Cloning a VM and copy-on-write deduplicating memory
 using CoW page sharing in Xen 4+
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hey all,
> Hey Andres,
>
> I'm looking to clone a VM into several extremely-similar VMs, and I'm
> hoping to also make use of your lovely new CoW page sharing capabilities
> in
> Xen 4.
>
> From my understanding of a previous thread where Andres described the
> process of sharing/coalescing memory between VMs, it sounds like I will
> need to "manually" coalesce each page using a homebrew tool of mine.  The
> issue I have with doing this is it seems like I'd need to pause, save mem,
> load mem in a new VM, coalesce, and resume two VMs, which seems painful
> and
> wasteful of a process for cloning!

Patrick,
that is indeed painful and wasteful. That is why we added
xc_memshr_add_to_physmap. Now you can do Potemkin-/SnowFlock-like cloning
in a few lines of code. You still want the source VM to be paused,
obviously.

Yuengling is my favourite US beer ;)

Andres

>
> Is there an easier way to do this, or should we add a new feature for CoW
> cloning of VMs in Xen via a userspace tool?
>
> Thanks,
> Pat Wilbur & team
>
>
> --
> Patrick F. Wilbur
> Researcher, Consultant, Educator,
> Computer Science Graduate at Clarkson University
>
> DONE RIGHT THE FIRST TIME: Consulting and hiring information:
> http://pdub.net/consulting/ & http://pdub.net/hiring/
>
> patrick.wilbur@gmail.com
> wilburpf@clarkson.edu
>
> Check out our book: http://runningxen.com
> My website: http://pdub.net
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 19:41:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 19: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.xensource.com>)
	id 1Rt2WZ-0001cC-Cj; Thu, 02 Feb 2012 19:40:51 +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 1Rt2WX-0001c7-Fo
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:40:49 +0000
Received: from [85.158.138.51:62881] by server-1.bemta-3.messagelabs.com id
	7A/E4-23590-0C6EA2F4; Thu, 02 Feb 2012 19:40:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328211647!9922003!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc2MTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21864 invoked from network); 2 Feb 2012 19:40:48 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 19:40:48 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 2886D76C06E;
	Thu,  2 Feb 2012 11:40:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=L3hRwlpWaPOj8AebWTDCTfqt8x6xsk5uxQno0fEanzNy
	sjpvJvPnh360PwpZBbfTkYphGVDpzhUCDL5d4PM8AIkMvcLDxh5J/YMmF7opO4AS
	dQU131hSc48DCAbEAiWhVbyefhnU1iarCE+6pHRHFF73sXe3rT5abZVT9ctZBSs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=gDJVeYqlQj2KmFlOe9ADyvF+cQY=; b=dpvIphxY
	2dGPq7YgQOebENmPbe9j+kQoSxNEHqjWuLlKJmlzQd7pp8lO8lzphF1yUA0vNwPf
	XZZS/WMd1Ma4+rVKqdXflu/ODwTXKB1B9VnbINOSaQlrBhzMT/zj7mb0i46RH/br
	W5zxs+4tuWi6XHurcQLNAOVgtGYPHCEStDA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 5A59276C069; 
	Thu,  2 Feb 2012 11:40:46 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 11:40:46 -0800
Message-ID: <fff17a2aed000e6aad496ed020eb7a9d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328193082.21722.31.camel@elijah>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
	<1328193082.21722.31.camel@elijah>
Date: Thu, 2 Feb 2012 11:40:46 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <george.dunlap@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m
 lockups are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
>> @@ -1445,7 +1449,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
>>              nestedp2m_unlock(d);
>>              return p2m;
>>          }
>> -        p2m_unlock(p2m);
>> +        gfn_unlock(p2m, gfn, 0);
>>      }
>
> It looks like maybe you forgot to change the corresponding p2m_lock() to
> gfn_lock(), here in p2m.c:p2m_get_nestedp2m()?

Good catch! (evil macro argument squashing!)
Thanks
Andres

>
> Other than that, I think the PoD stuff looks fine.  So regarding PoD
> stuff:
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 19:41:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 19: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.xensource.com>)
	id 1Rt2WZ-0001cC-Cj; Thu, 02 Feb 2012 19:40:51 +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 1Rt2WX-0001c7-Fo
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:40:49 +0000
Received: from [85.158.138.51:62881] by server-1.bemta-3.messagelabs.com id
	7A/E4-23590-0C6EA2F4; Thu, 02 Feb 2012 19:40:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328211647!9922003!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc2MTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21864 invoked from network); 2 Feb 2012 19:40:48 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 19:40:48 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 2886D76C06E;
	Thu,  2 Feb 2012 11:40:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=L3hRwlpWaPOj8AebWTDCTfqt8x6xsk5uxQno0fEanzNy
	sjpvJvPnh360PwpZBbfTkYphGVDpzhUCDL5d4PM8AIkMvcLDxh5J/YMmF7opO4AS
	dQU131hSc48DCAbEAiWhVbyefhnU1iarCE+6pHRHFF73sXe3rT5abZVT9ctZBSs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=gDJVeYqlQj2KmFlOe9ADyvF+cQY=; b=dpvIphxY
	2dGPq7YgQOebENmPbe9j+kQoSxNEHqjWuLlKJmlzQd7pp8lO8lzphF1yUA0vNwPf
	XZZS/WMd1Ma4+rVKqdXflu/ODwTXKB1B9VnbINOSaQlrBhzMT/zj7mb0i46RH/br
	W5zxs+4tuWi6XHurcQLNAOVgtGYPHCEStDA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 5A59276C069; 
	Thu,  2 Feb 2012 11:40:46 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 11:40:46 -0800
Message-ID: <fff17a2aed000e6aad496ed020eb7a9d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328193082.21722.31.camel@elijah>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<fb9c06df05f20461744a.1328126166@xdev.gridcentric.ca>
	<1328193082.21722.31.camel@elijah>
Date: Thu, 2 Feb 2012 11:40:46 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <george.dunlap@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 5] Clean up locking now that p2m
 lockups are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
>> @@ -1445,7 +1449,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
>>              nestedp2m_unlock(d);
>>              return p2m;
>>          }
>> -        p2m_unlock(p2m);
>> +        gfn_unlock(p2m, gfn, 0);
>>      }
>
> It looks like maybe you forgot to change the corresponding p2m_lock() to
> gfn_lock(), here in p2m.c:p2m_get_nestedp2m()?

Good catch! (evil macro argument squashing!)
Thanks
Andres

>
> Other than that, I think the PoD stuff looks fine.  So regarding PoD
> stuff:
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:00:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt2oc-0002Lu-6F; Thu, 02 Feb 2012 19:59:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rt2ob-0002Lp-8T
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:59:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328212763!9721063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3722 invoked from network); 2 Feb 2012 19:59:23 -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;
	2 Feb 2012 19:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208";a="10452934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 19:59:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	19:59:22 +0000
Message-ID: <1328212761.28964.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 2 Feb 2012 19:59:21 +0000
In-Reply-To: <1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 17:48 +0000, Eric Dumazet wrote:
> Le jeudi 02 f=E9vrier 2012 =E0 17:28 +0000, Wei Liu a =E9crit :
> =

> > You're right about this.
> > =

> > But this part is destined to get wiped out (in the very near future?) --
> > see following patches. So I don't think it is worthy to fix this.
> > =

> =

> Before adding new bugs, you must fix previous ones.

I've never heard of this requirement before! It's a wonder anyone ever
gets anything done.

Anyway, I think it would be reasonable to just remove the kthread_bind
call from this loop. We don't actually want/need a thread per online CPU
in any strict sense, we just want there to be some number of worker
threads available and ~numcpus at start of day is a good enough
approximation for that number. There have been patches floating around
in the past which make the number of groups a module parameter which
would also be a reasonable thing to dig out if we weren't just about to
remove all this code anyway.

So removing the kthread_bind is good enough for the short term, and for
stable if people feel that is necessary, and we can continue in mainline
with the direction Wei's patches are taking us.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:00:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt2oc-0002Lu-6F; Thu, 02 Feb 2012 19:59:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rt2ob-0002Lp-8T
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:59:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328212763!9721063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3722 invoked from network); 2 Feb 2012 19:59:23 -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;
	2 Feb 2012 19:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208";a="10452934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 19:59:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	19:59:22 +0000
Message-ID: <1328212761.28964.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 2 Feb 2012 19:59:21 +0000
In-Reply-To: <1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 17:48 +0000, Eric Dumazet wrote:
> Le jeudi 02 f=E9vrier 2012 =E0 17:28 +0000, Wei Liu a =E9crit :
> =

> > You're right about this.
> > =

> > But this part is destined to get wiped out (in the very near future?) --
> > see following patches. So I don't think it is worthy to fix this.
> > =

> =

> Before adding new bugs, you must fix previous ones.

I've never heard of this requirement before! It's a wonder anyone ever
gets anything done.

Anyway, I think it would be reasonable to just remove the kthread_bind
call from this loop. We don't actually want/need a thread per online CPU
in any strict sense, we just want there to be some number of worker
threads available and ~numcpus at start of day is a good enough
approximation for that number. There have been patches floating around
in the past which make the number of groups a module parameter which
would also be a reasonable thing to dig out if we weren't just about to
remove all this code anyway.

So removing the kthread_bind is good enough for the short term, and for
stable if people feel that is necessary, and we can continue in mainline
with the direction Wei's patches are taking us.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:03:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt2sK-0002W5-RX; Thu, 02 Feb 2012 20:03:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rt2sI-0002Vx-NA
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:03:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328212991!13256117!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27549 invoked from network); 2 Feb 2012 20:03:12 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-15.tower-216.messagelabs.com with SMTP;
	2 Feb 2012 20:03:12 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id DD664714085;
	Thu,  2 Feb 2012 12:03:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=HuMkoCub1RDBx7rMJSGW38EvFNu5J4CqLC7sGCIUzjh9
	3SkK4uKIzhAB+1c6un0LT2p+lm9f+h2i3SMvoBx+UFaJ4hZaXBRQIWDMjqd1+bIA
	5KEMOpBw8Ospon9qTjYV9jop3dlq8wxC8Id0P0z4U0i6eA3fk41MFwCAwv14wvw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jf2dvYoxowmPQ72qfYp0F9m9Il8=; b=ZV3DLY01
	JV2q4+pue0vuMo4sRhyJtcoo53TZxG6QvIxhRDZ5yk0+qQZ2ViN9wv5sFwSrGiu0
	UGD0IhvG4nmIVRnSina6eRtIKDjl3Kb0imUCp/UL6UZbOz0vix9fdP3Kx6xV6oR7
	7NPTnYN0GE3pfyK3XYMLr2EEZ6H7/4Fg2Zg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 16D9171406F; 
	Thu,  2 Feb 2012 12:03:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 12:03:10 -0800
Message-ID: <8fd8606528b049181ebe62ead547f17d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328196795.21722.86.camel@elijah>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
	<1328196795.21722.86.camel@elijah>
Date: Thu, 2 Feb 2012 12:03:10 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <george.dunlap@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
>> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>>          unmap_domain_page(b);
>>      }
>>
>> +    /* First, take all pages off the domain list */
>>      lock_page_alloc(p2m);
>> -
>> -    /* First, take all pages off the domain list */
>>      for(i=0; i < 1 << order ; i++)
>>      {
>>          p = page + i;
>>          page_list_del(p, &d->page_list);
>>      }
>>
>> +    /* Ensure that the PoD cache has never been emptied.
>> +     * This may cause "zombie domains" since the page will never be
>> freed. */
>> +    BUG_ON( d->arch.relmem != RELMEM_not_started );
>> +
>> +    unlock_page_alloc(p2m);
>> +
>
> This assert should stay where it is.  The idea is to verify
> after-the-fact that the page_list_add_tail()s *have not* raced with
> emptying the PoD cache.  Having the assert before cannot guarantee that
> they *will not* race with emptying the PoD cache.  Alternately, if we're
> positive that condition can never happen again, we should just remove
> the BUG_ON().

As is, the code in cache_add mutually excludes p2m_pod_empty_cache until
pod_lock is released by the caller. So, the page_list_add_tails()s cannot
race with emptying the PoD cache.

On further look, the BUG_ON can go. relmem moves out of _not_started only
after p2m_pod_empty_cache has finished. So, transitively, we're safe.

Emptying the pod cache does the spin barrier. Question: should it not take
the lock after the spin barrier, to be super safe?

Thanks!
Andres

>
> If I recall correctly, I put this in here because something ended up
> calling cache_add after empty_cache(), potentially with the p2m lock
> already held; that's why I put the BUG_ON() there to begin with.
>
>> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
>>
>>      /* FIXME: Figure out how to avoid superpages */
>> +    /* NOTE: Promote to globally locking the p2m. This will get
>> complicated
>> +     * in a fine-grained scenario. Even if we're to lock each gfn
>> +     * individually we must be careful about recursion limits and
>> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock
>> constraints
>> +     * between p2m and pod locks */
>> +    p2m_lock(p2m);
>>      for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
>>      {
>>          p2m_access_t a;
>> @@ -940,7 +953,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>          /* Stop if we're past our limit and we have found *something*.
>>           *
>>           * NB that this is a zero-sum game; we're increasing our cache
>> size
>> -         * by re-increasing our 'debt'.  Since we hold the p2m lock,
>> +         * by re-increasing our 'debt'.  Since we hold the pod lock,
>>           * (entry_count - count) must remain the same. */
>>          if ( p2m->pod.count > 0 && i < limit )
>>              break;
>> @@ -949,6 +962,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>      if ( j )
>>          p2m_pod_zero_check(p2m, gfns, j);
>>
>> +    p2m_unlock(p2m);
>>      p2m->pod.reclaim_single = i ? i - 1 : i;
>>
>>  }
>> @@ -965,8 +979,9 @@ p2m_pod_demand_populate(struct p2m_domai
>>      int i;
>>
>>      ASSERT(gfn_locked_by_me(p2m, gfn));
>> +    pod_lock(p2m);
>>
>> -    /* This check is done with the p2m lock held.  This will make sure
>> that
>> +    /* This check is done with the pod lock held.  This will make sure
>> that
>>       * even if d->is_dying changes under our feet,
>> p2m_pod_empty_cache()
>>       * won't start until we're done. */
>>      if ( unlikely(d->is_dying) )
>> @@ -977,6 +992,7 @@ p2m_pod_demand_populate(struct p2m_domai
>>       * 1GB region to 2MB chunks for a retry. */
>>      if ( order == PAGE_ORDER_1G )
>>      {
>> +        pod_unlock(p2m);
>>          gfn_aligned = (gfn >> order) << order;
>>          /* Note that we are supposed to call set_p2m_entry() 512 times
>> to
>>           * split 1GB into 512 2MB pages here. But We only do once here
>> because
>> @@ -1000,11 +1016,15 @@ p2m_pod_demand_populate(struct p2m_domai
>>
>>          /* If we're low, start a sweep */
>>          if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super)
>> )
>> +            /* Note that sweeps scan other ranges in the p2m. In an
>> scenario
>> +             * in which p2m locks are order-enforced wrt pod lock and
>> p2m
>> +             * locks are fine grained, this will result in deadlock
>> panic */
>>              p2m_pod_emergency_sweep_super(p2m);
>>
>>          if ( page_list_empty(&p2m->pod.single) &&
>>               ( ( order == PAGE_ORDER_4K )
>>                 || (order == PAGE_ORDER_2M &&
>> page_list_empty(&p2m->pod.super) ) ) )
>> +            /* Same comment regarding deadlock applies */
>>              p2m_pod_emergency_sweep(p2m);
>>      }
>>
>

You know what, these comments are *old*. I really need to cut down on the
FUD factor :) As is, there is no risk of deadlock.

With a (hypothetical as of today) fine-grained p2m locking approach, I
want to leave a "be careful" reminder. And document your trylock
suggestion, which I believe to be accurate.

Thanks for the detailed look!
Andres

> Regarding locking on emergency sweeps: I think it should suffice if we
> could do the equivalent of a spin_trylock() on each gpfn, and just move
> on (not checking that gfn) if it fails.  What do you think?
>
> Other than that, I don't see anything wrong with this locking at first
> glance; but it's complicated enough that I don't think I've quite
> grokked it yet.  I'll look at it again tomorrow and see if things are
> more clear. :-)
>
> -George
>
>
>> @@ -1012,8 +1032,6 @@ p2m_pod_demand_populate(struct p2m_domai
>>      if ( q == p2m_guest && gfn > p2m->pod.max_guest )
>>          p2m->pod.max_guest = gfn;
>>
>> -    lock_page_alloc(p2m);
>> -
>>      if ( p2m->pod.count == 0 )
>>          goto out_of_memory;
>>
>> @@ -1026,8 +1044,6 @@ p2m_pod_demand_populate(struct p2m_domai
>>
>>      BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
>>
>> -    unlock_page_alloc(p2m);
>> -
>>      gfn_aligned = (gfn >> order) << order;
>>
>>      set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw,
>> p2m->default_access);
>> @@ -1038,7 +1054,7 @@ p2m_pod_demand_populate(struct p2m_domai
>>          paging_mark_dirty(d, mfn_x(mfn) + i);
>>      }
>>
>> -    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
>> +    p2m->pod.entry_count -= (1 << order);
>>      BUG_ON(p2m->pod.entry_count < 0);
>>
>>      if ( tb_init_done )
>> @@ -1056,20 +1072,24 @@ p2m_pod_demand_populate(struct p2m_domai
>>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>>      }
>>
>> +    pod_unlock(p2m);
>>      return 0;
>>  out_of_memory:
>> -    unlock_page_alloc(p2m);
>> +    pod_unlock(p2m);
>>
>>      printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 "
>> pod_entries %" PRIi32 "\n",
>>             __func__, d->tot_pages, p2m->pod.entry_count);
>>      domain_crash(d);
>>  out_fail:
>> +    pod_unlock(p2m);
>>      return -1;
>>  remap_and_retry:
>>      BUG_ON(order != PAGE_ORDER_2M);
>> -    unlock_page_alloc(p2m);
>> +    pod_unlock(p2m);
>>
>>      /* Remap this 2-meg region in singleton chunks */
>> +    /* NOTE: In a p2m fine-grained lock scenario this might
>> +     * need promoting the gfn lock from gfn->2M superpage */
>>      gfn_aligned = (gfn>>order)<<order;
>>      for(i=0; i<(1<<order); i++)
>>          set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
>> @@ -1137,9 +1157,11 @@ guest_physmap_mark_populate_on_demand(st
>>          rc = -EINVAL;
>>      else
>>      {
>> -        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
>> +        pod_lock(p2m);
>> +        p2m->pod.entry_count += 1 << order;
>>          p2m->pod.entry_count -= pod_count;
>>          BUG_ON(p2m->pod.entry_count < 0);
>> +        pod_unlock(p2m);
>>      }
>>
>>      gfn_unlock(p2m, gfn, order);
>> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pt.c
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>      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)
>> );
>> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
>>  static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
>>  {
>>      mm_lock_init(&p2m->lock);
>> +    mm_lock_init(&p2m->pod.lock);
>>      INIT_LIST_HEAD(&p2m->np2m_list);
>>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>>      INIT_PAGE_LIST_HEAD(&p2m->pod.super);
>> @@ -587,8 +588,10 @@ guest_physmap_add_entry(struct domain *d
>>              rc = -EINVAL;
>>          else
>>          {
>> -            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
>> +            pod_lock(p2m);
>> +            p2m->pod.entry_count -= pod_count;
>>              BUG_ON(p2m->pod.entry_count < 0);
>> +            pod_unlock(p2m);
>>          }
>>      }
>>
>> @@ -1372,6 +1375,7 @@ p2m_flush_table(struct p2m_domain *p2m)
>>      /* "Host" p2m tables can have shared entries &c that need a bit
>> more
>>       * care when discarding them */
>>      ASSERT(p2m_is_nestedp2m(p2m));
>> +    /* Nested p2m's do not do pod, hence the asserts (and no pod
>> lock)*/
>>      ASSERT(page_list_empty(&p2m->pod.super));
>>      ASSERT(page_list_empty(&p2m->pod.single));
>>
>> @@ -1529,6 +1533,7 @@ void audit_p2m(struct domain *d,
>>      P2M_PRINTK("p2m audit starts\n");
>>
>>      p2m_lock(p2m);
>> +    pod_lock(p2m);
>>
>>      if (p2m->audit_p2m)
>>          pmbad = p2m->audit_p2m(p2m);
>> @@ -1589,6 +1594,7 @@ void audit_p2m(struct domain *d,
>>      }
>>      spin_unlock(&d->page_alloc_lock);
>>
>> +    pod_unlock(p2m);
>>      p2m_unlock(p2m);
>>
>>      P2M_PRINTK("p2m audit complete\n");
>> diff -r fb9c06df05f2 -r 56ceab0118cb xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -261,25 +261,12 @@ struct p2m_domain {
>>      unsigned long max_mapped_pfn;
>>
>>      /* Populate-on-demand variables
>> -     * NB on locking.  {super,single,count} are
>> -     * covered by d->page_alloc_lock, since they're almost always used
>> in
>> -     * conjunction with that functionality.  {entry_count} is covered
>> by
>> -     * the domain p2m lock, since it's almost always used in
>> conjunction
>> -     * with changing the p2m tables.
>> -     *
>> -     * At this point, both locks are held in two places.  In both,
>> -     * the order is [p2m,page_alloc]:
>> -     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
>> -     *   which grabs page_alloc
>> -     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
>> -     *   double-demand-populating of pages, the page_alloc lock to
>> -     *   protect moving stuff from the PoD cache to the domain page
>> list.
>> -     *
>> -     * We enforce this lock ordering through a construct in mm-locks.h.
>> -     * This demands, however, that we store the previous lock-ordering
>> -     * level in effect before grabbing the page_alloc lock. The unlock
>> -     * level is stored in the arch section of the domain struct.
>> -     */
>> +     * All variables are protected with the pod lock. We cannot rely on
>> +     * the p2m lock if it's turned into a fine-grained lock.
>> +     * We only use the domain page_alloc lock for additions and
>> +     * deletions to the domain's page list. Because we use it nested
>> +     * within the PoD lock, we enforce it's ordering (by remembering
>> +     * the unlock level in the arch_domain sub struct). */
>>      struct {
>>          struct page_list_head super,   /* List of superpages
>>     */
>>                           single;       /* Non-super lists
>>     */
>> @@ -288,6 +275,8 @@ struct p2m_domain {
>>          unsigned         reclaim_super; /* Last gpfn of a scan */
>>          unsigned         reclaim_single; /* Last gpfn of a scan */
>>          unsigned         max_guest;    /* gpfn of max guest
>> demand-populate */
>> +        mm_lock_t        lock;         /* Locking of private pod
>> structs,   *
>> +                                        * not relying on the p2m lock.
>>     */
>>      } pod;
>>  };
>>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:03:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt2sK-0002W5-RX; Thu, 02 Feb 2012 20:03:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rt2sI-0002Vx-NA
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:03:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328212991!13256117!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk5MjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27549 invoked from network); 2 Feb 2012 20:03:12 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-15.tower-216.messagelabs.com with SMTP;
	2 Feb 2012 20:03:12 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id DD664714085;
	Thu,  2 Feb 2012 12:03:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=HuMkoCub1RDBx7rMJSGW38EvFNu5J4CqLC7sGCIUzjh9
	3SkK4uKIzhAB+1c6un0LT2p+lm9f+h2i3SMvoBx+UFaJ4hZaXBRQIWDMjqd1+bIA
	5KEMOpBw8Ospon9qTjYV9jop3dlq8wxC8Id0P0z4U0i6eA3fk41MFwCAwv14wvw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jf2dvYoxowmPQ72qfYp0F9m9Il8=; b=ZV3DLY01
	JV2q4+pue0vuMo4sRhyJtcoo53TZxG6QvIxhRDZ5yk0+qQZ2ViN9wv5sFwSrGiu0
	UGD0IhvG4nmIVRnSina6eRtIKDjl3Kb0imUCp/UL6UZbOz0vix9fdP3Kx6xV6oR7
	7NPTnYN0GE3pfyK3XYMLr2EEZ6H7/4Fg2Zg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 16D9171406F; 
	Thu,  2 Feb 2012 12:03:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 12:03:10 -0800
Message-ID: <8fd8606528b049181ebe62ead547f17d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328196795.21722.86.camel@elijah>
References: <patchbomb.1328126164@xdev.gridcentric.ca>
	<56ceab0118cba85cdcd3.1328126167@xdev.gridcentric.ca>
	<1328196795.21722.86.camel@elijah>
Date: Thu, 2 Feb 2012 12:03:10 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <george.dunlap@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 5] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 19:56 +0000, Andres Lagar-Cavilla wrote:
>> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>>          unmap_domain_page(b);
>>      }
>>
>> +    /* First, take all pages off the domain list */
>>      lock_page_alloc(p2m);
>> -
>> -    /* First, take all pages off the domain list */
>>      for(i=0; i < 1 << order ; i++)
>>      {
>>          p = page + i;
>>          page_list_del(p, &d->page_list);
>>      }
>>
>> +    /* Ensure that the PoD cache has never been emptied.
>> +     * This may cause "zombie domains" since the page will never be
>> freed. */
>> +    BUG_ON( d->arch.relmem != RELMEM_not_started );
>> +
>> +    unlock_page_alloc(p2m);
>> +
>
> This assert should stay where it is.  The idea is to verify
> after-the-fact that the page_list_add_tail()s *have not* raced with
> emptying the PoD cache.  Having the assert before cannot guarantee that
> they *will not* race with emptying the PoD cache.  Alternately, if we're
> positive that condition can never happen again, we should just remove
> the BUG_ON().

As is, the code in cache_add mutually excludes p2m_pod_empty_cache until
pod_lock is released by the caller. So, the page_list_add_tails()s cannot
race with emptying the PoD cache.

On further look, the BUG_ON can go. relmem moves out of _not_started only
after p2m_pod_empty_cache has finished. So, transitively, we're safe.

Emptying the pod cache does the spin barrier. Question: should it not take
the lock after the spin barrier, to be super safe?

Thanks!
Andres

>
> If I recall correctly, I put this in here because something ended up
> calling cache_add after empty_cache(), potentially with the p2m lock
> already held; that's why I put the BUG_ON() there to begin with.
>
>> @@ -922,6 +929,12 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>      limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
>>
>>      /* FIXME: Figure out how to avoid superpages */
>> +    /* NOTE: Promote to globally locking the p2m. This will get
>> complicated
>> +     * in a fine-grained scenario. Even if we're to lock each gfn
>> +     * individually we must be careful about recursion limits and
>> +     * POD_SWEEP_STRIDE. This is why we don't enforce deadlock
>> constraints
>> +     * between p2m and pod locks */
>> +    p2m_lock(p2m);
>>      for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
>>      {
>>          p2m_access_t a;
>> @@ -940,7 +953,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>          /* Stop if we're past our limit and we have found *something*.
>>           *
>>           * NB that this is a zero-sum game; we're increasing our cache
>> size
>> -         * by re-increasing our 'debt'.  Since we hold the p2m lock,
>> +         * by re-increasing our 'debt'.  Since we hold the pod lock,
>>           * (entry_count - count) must remain the same. */
>>          if ( p2m->pod.count > 0 && i < limit )
>>              break;
>> @@ -949,6 +962,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
>>      if ( j )
>>          p2m_pod_zero_check(p2m, gfns, j);
>>
>> +    p2m_unlock(p2m);
>>      p2m->pod.reclaim_single = i ? i - 1 : i;
>>
>>  }
>> @@ -965,8 +979,9 @@ p2m_pod_demand_populate(struct p2m_domai
>>      int i;
>>
>>      ASSERT(gfn_locked_by_me(p2m, gfn));
>> +    pod_lock(p2m);
>>
>> -    /* This check is done with the p2m lock held.  This will make sure
>> that
>> +    /* This check is done with the pod lock held.  This will make sure
>> that
>>       * even if d->is_dying changes under our feet,
>> p2m_pod_empty_cache()
>>       * won't start until we're done. */
>>      if ( unlikely(d->is_dying) )
>> @@ -977,6 +992,7 @@ p2m_pod_demand_populate(struct p2m_domai
>>       * 1GB region to 2MB chunks for a retry. */
>>      if ( order == PAGE_ORDER_1G )
>>      {
>> +        pod_unlock(p2m);
>>          gfn_aligned = (gfn >> order) << order;
>>          /* Note that we are supposed to call set_p2m_entry() 512 times
>> to
>>           * split 1GB into 512 2MB pages here. But We only do once here
>> because
>> @@ -1000,11 +1016,15 @@ p2m_pod_demand_populate(struct p2m_domai
>>
>>          /* If we're low, start a sweep */
>>          if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super)
>> )
>> +            /* Note that sweeps scan other ranges in the p2m. In an
>> scenario
>> +             * in which p2m locks are order-enforced wrt pod lock and
>> p2m
>> +             * locks are fine grained, this will result in deadlock
>> panic */
>>              p2m_pod_emergency_sweep_super(p2m);
>>
>>          if ( page_list_empty(&p2m->pod.single) &&
>>               ( ( order == PAGE_ORDER_4K )
>>                 || (order == PAGE_ORDER_2M &&
>> page_list_empty(&p2m->pod.super) ) ) )
>> +            /* Same comment regarding deadlock applies */
>>              p2m_pod_emergency_sweep(p2m);
>>      }
>>
>

You know what, these comments are *old*. I really need to cut down on the
FUD factor :) As is, there is no risk of deadlock.

With a (hypothetical as of today) fine-grained p2m locking approach, I
want to leave a "be careful" reminder. And document your trylock
suggestion, which I believe to be accurate.

Thanks for the detailed look!
Andres

> Regarding locking on emergency sweeps: I think it should suffice if we
> could do the equivalent of a spin_trylock() on each gpfn, and just move
> on (not checking that gfn) if it fails.  What do you think?
>
> Other than that, I don't see anything wrong with this locking at first
> glance; but it's complicated enough that I don't think I've quite
> grokked it yet.  I'll look at it again tomorrow and see if things are
> more clear. :-)
>
> -George
>
>
>> @@ -1012,8 +1032,6 @@ p2m_pod_demand_populate(struct p2m_domai
>>      if ( q == p2m_guest && gfn > p2m->pod.max_guest )
>>          p2m->pod.max_guest = gfn;
>>
>> -    lock_page_alloc(p2m);
>> -
>>      if ( p2m->pod.count == 0 )
>>          goto out_of_memory;
>>
>> @@ -1026,8 +1044,6 @@ p2m_pod_demand_populate(struct p2m_domai
>>
>>      BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
>>
>> -    unlock_page_alloc(p2m);
>> -
>>      gfn_aligned = (gfn >> order) << order;
>>
>>      set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw,
>> p2m->default_access);
>> @@ -1038,7 +1054,7 @@ p2m_pod_demand_populate(struct p2m_domai
>>          paging_mark_dirty(d, mfn_x(mfn) + i);
>>      }
>>
>> -    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
>> +    p2m->pod.entry_count -= (1 << order);
>>      BUG_ON(p2m->pod.entry_count < 0);
>>
>>      if ( tb_init_done )
>> @@ -1056,20 +1072,24 @@ p2m_pod_demand_populate(struct p2m_domai
>>          __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
>>      }
>>
>> +    pod_unlock(p2m);
>>      return 0;
>>  out_of_memory:
>> -    unlock_page_alloc(p2m);
>> +    pod_unlock(p2m);
>>
>>      printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 "
>> pod_entries %" PRIi32 "\n",
>>             __func__, d->tot_pages, p2m->pod.entry_count);
>>      domain_crash(d);
>>  out_fail:
>> +    pod_unlock(p2m);
>>      return -1;
>>  remap_and_retry:
>>      BUG_ON(order != PAGE_ORDER_2M);
>> -    unlock_page_alloc(p2m);
>> +    pod_unlock(p2m);
>>
>>      /* Remap this 2-meg region in singleton chunks */
>> +    /* NOTE: In a p2m fine-grained lock scenario this might
>> +     * need promoting the gfn lock from gfn->2M superpage */
>>      gfn_aligned = (gfn>>order)<<order;
>>      for(i=0; i<(1<<order); i++)
>>          set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
>> @@ -1137,9 +1157,11 @@ guest_physmap_mark_populate_on_demand(st
>>          rc = -EINVAL;
>>      else
>>      {
>> -        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
>> +        pod_lock(p2m);
>> +        p2m->pod.entry_count += 1 << order;
>>          p2m->pod.entry_count -= pod_count;
>>          BUG_ON(p2m->pod.entry_count < 0);
>> +        pod_unlock(p2m);
>>      }
>>
>>      gfn_unlock(p2m, gfn, order);
>> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m-pt.c
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>      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)
>> );
>> diff -r fb9c06df05f2 -r 56ceab0118cb xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
>>  static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
>>  {
>>      mm_lock_init(&p2m->lock);
>> +    mm_lock_init(&p2m->pod.lock);
>>      INIT_LIST_HEAD(&p2m->np2m_list);
>>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>>      INIT_PAGE_LIST_HEAD(&p2m->pod.super);
>> @@ -587,8 +588,10 @@ guest_physmap_add_entry(struct domain *d
>>              rc = -EINVAL;
>>          else
>>          {
>> -            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
>> +            pod_lock(p2m);
>> +            p2m->pod.entry_count -= pod_count;
>>              BUG_ON(p2m->pod.entry_count < 0);
>> +            pod_unlock(p2m);
>>          }
>>      }
>>
>> @@ -1372,6 +1375,7 @@ p2m_flush_table(struct p2m_domain *p2m)
>>      /* "Host" p2m tables can have shared entries &c that need a bit
>> more
>>       * care when discarding them */
>>      ASSERT(p2m_is_nestedp2m(p2m));
>> +    /* Nested p2m's do not do pod, hence the asserts (and no pod
>> lock)*/
>>      ASSERT(page_list_empty(&p2m->pod.super));
>>      ASSERT(page_list_empty(&p2m->pod.single));
>>
>> @@ -1529,6 +1533,7 @@ void audit_p2m(struct domain *d,
>>      P2M_PRINTK("p2m audit starts\n");
>>
>>      p2m_lock(p2m);
>> +    pod_lock(p2m);
>>
>>      if (p2m->audit_p2m)
>>          pmbad = p2m->audit_p2m(p2m);
>> @@ -1589,6 +1594,7 @@ void audit_p2m(struct domain *d,
>>      }
>>      spin_unlock(&d->page_alloc_lock);
>>
>> +    pod_unlock(p2m);
>>      p2m_unlock(p2m);
>>
>>      P2M_PRINTK("p2m audit complete\n");
>> diff -r fb9c06df05f2 -r 56ceab0118cb xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -261,25 +261,12 @@ struct p2m_domain {
>>      unsigned long max_mapped_pfn;
>>
>>      /* Populate-on-demand variables
>> -     * NB on locking.  {super,single,count} are
>> -     * covered by d->page_alloc_lock, since they're almost always used
>> in
>> -     * conjunction with that functionality.  {entry_count} is covered
>> by
>> -     * the domain p2m lock, since it's almost always used in
>> conjunction
>> -     * with changing the p2m tables.
>> -     *
>> -     * At this point, both locks are held in two places.  In both,
>> -     * the order is [p2m,page_alloc]:
>> -     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
>> -     *   which grabs page_alloc
>> -     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
>> -     *   double-demand-populating of pages, the page_alloc lock to
>> -     *   protect moving stuff from the PoD cache to the domain page
>> list.
>> -     *
>> -     * We enforce this lock ordering through a construct in mm-locks.h.
>> -     * This demands, however, that we store the previous lock-ordering
>> -     * level in effect before grabbing the page_alloc lock. The unlock
>> -     * level is stored in the arch section of the domain struct.
>> -     */
>> +     * All variables are protected with the pod lock. We cannot rely on
>> +     * the p2m lock if it's turned into a fine-grained lock.
>> +     * We only use the domain page_alloc lock for additions and
>> +     * deletions to the domain's page list. Because we use it nested
>> +     * within the PoD lock, we enforce it's ordering (by remembering
>> +     * the unlock level in the arch_domain sub struct). */
>>      struct {
>>          struct page_list_head super,   /* List of superpages
>>     */
>>                           single;       /* Non-super lists
>>     */
>> @@ -288,6 +275,8 @@ struct p2m_domain {
>>          unsigned         reclaim_super; /* Last gpfn of a scan */
>>          unsigned         reclaim_single; /* Last gpfn of a scan */
>>          unsigned         max_guest;    /* gpfn of max guest
>> demand-populate */
>> +        mm_lock_t        lock;         /* Locking of private pod
>> structs,   *
>> +                                        * not relying on the p2m lock.
>>     */
>>      } pod;
>>  };
>>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:24:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3Bw-0003Ld-EJ; Thu, 02 Feb 2012 20:23:36 +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 1Rt3Bv-0003LY-9o
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:23:35 +0000
Received: from [85.158.138.51:18596] by server-8.bemta-3.messagelabs.com id
	43/37-08780-6C0FA2F4; Thu, 02 Feb 2012 20:23:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328214212!11785658!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1252 invoked from network); 2 Feb 2012 20:23:33 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.81) by server-11.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 20:23:33 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5212F1A8095;
	Thu,  2 Feb 2012 12:23:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PuBQAgJN7X2mVLu7ZpFtEQGuSWEdbMsbZItJnWBHEMIG
	ZSoM9H2SeAPZa0bXgS0RYtJn1+ksL68TyjtP5oUVeUQEgQJg9P9RjYAKOjD7DzBb
	OINQ7EczsiMRtPoh8dXBcsT7LsFbU4rnUwmbHLxqL1nCWB1t9jwVF+dIj2sCDX4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=MxaU/AcZbiW4nrXiuvaAykRYm58=; b=NRShTsBc
	cwSu40VL1FqrUl0K/HFTLvw7czq+jJD/DsjqIc/AgMEvyBQZtRbfDm0rxpbdXdtG
	Vs5r6DtQfoJQTtqAmN/a0QuMdJh2GvbTWMLdU/P6JoeG0oLwvu20gmXMkafwCEQp
	6M7BKJTmPTTMmYH66EETl4FXbF+DpiC869E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 6CB661A8063; 
	Thu,  2 Feb 2012 12:23:31 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 12:23:32 -0800
Message-ID: <69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328194692.2924.29.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
Date: Thu, 2 Feb 2012 12:23:32 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
>> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
>> >>
>> >>
>> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> >> +                        unsigned int op, unsigned int mode,
>> >> +                        uint64_t gfn, void *buffer)
>> >> +{
>> >> +    xen_mem_event_op_t meo;
>> >> +
>> >> +    memset(&meo, 0, sizeof(meo));
>> >> +
>> >> +    meo.op      = op;
>> >> +    meo.domain  = domain_id;
>> >> +    meo.gfn     = gfn;
>> >> +    meo.buffer  = (unsigned long) buffer;
>> >
>> > Hypercall arguments need to use the xc_hypercall_buffer stuff in order
>> > to ensure that the memory is safe to access from a hypercall (in
>> > particular that it is mlocked or similar)-- I don't see where that
>> > happens for this buffer.
>> >
>> > meo itself is bounced by do_memory_op so that is OK.
>> >
>> > I was also a little suspicious of ring_addr and shared_addr in
>> > xc_mem_event_control in this regard.
>> >
>> > Or does the mem sharing code make it's own arrangements for these
>> sorts
>> > of things somewhere?
>>
>> It's rather unclean. They do not get mlock'ed (and there is no sanity
>> check to ensure they're page-aligned). They should follow the pattern
>> established in xc_mem_paging_load. I'll get on it, probably a separate
>> patch.
>
> If you are reworking this It Would Be Nice If (tm) you could make it use
> xc_hypercall_buffer_alloc and friends to allocate and manage the buffer
> while you are there e.g. the void *buffer above would become struct
> xc_hypercall_buffer *buffer -- see xc_perfc_query for example.

Took me a while to grok those hypercall buffer macros. Conclusion: that
would need to change callers of paging_load (xenpaging in tree).

Can we keep this separate? domctl interface also suffers from all these
problems. domctl->memops switch is orthogonal to the buffer badness. I
want to tackle one problem at a time.

>
> It happens that mlock has roughly the semantics we need (and so it
> mostly works) but it is not guaranteed by the specs. At some point we
> may wish to do something more robust and using the common interface will
> mean that the sharing code will benefit from that too.
>
>> There is a far more insidious problem that I'm not sure how to solve.
>> Say
>> the pager dies unexpectedly. The page hosting the ring is returned to
>> dom0's free page pool, and then re-assigned to some other process. Xen
>> never gets to find out. At best, the domain crashes before an event is
>> generated. Perhaps, Xen posts at least one event. Worst-case scenario,
>> the
>> guest generates a spate of events. Cases 2 & 3 corrupt the memory of
>> some
>> other dom0 process.
>
> How does the memory actually get mapped? Or is it actually memory
> belonging to the user process?

The user process memory is mapped by Xen: user virtual address -> mfn ->
map_domain_page. Ugly.

Agree with you that the best way to solve it is with a dom0 kernel driver.

Thanks!
Andres
>
> The gntalloc driver presumably has a similar sort of problem, might be
> interesting to take inspiration from there?
>
> There's the possibility of having a paging specific driver which takes
> care of this and all the userspace does is mmap /dev/xen/pager or
> whatever.
>
>> I'm glad I got that off my chest :) While being a very rare race
>> condition
>> (haven't actually experienced it), I am quite unsure of how to tackle it
>> cleanly.
>>
>> Andres
>> >
>> > Ian.
>> >
>> >> +
>> >> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
>> >> +}
>> >
>> >
>> >
>> >
>>
>>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:24:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3Bw-0003Ld-EJ; Thu, 02 Feb 2012 20:23:36 +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 1Rt3Bv-0003LY-9o
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:23:35 +0000
Received: from [85.158.138.51:18596] by server-8.bemta-3.messagelabs.com id
	43/37-08780-6C0FA2F4; Thu, 02 Feb 2012 20:23:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328214212!11785658!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIxMDQ1\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1252 invoked from network); 2 Feb 2012 20:23:33 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.81) by server-11.tower-174.messagelabs.com with SMTP;
	2 Feb 2012 20:23:33 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5212F1A8095;
	Thu,  2 Feb 2012 12:23:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PuBQAgJN7X2mVLu7ZpFtEQGuSWEdbMsbZItJnWBHEMIG
	ZSoM9H2SeAPZa0bXgS0RYtJn1+ksL68TyjtP5oUVeUQEgQJg9P9RjYAKOjD7DzBb
	OINQ7EczsiMRtPoh8dXBcsT7LsFbU4rnUwmbHLxqL1nCWB1t9jwVF+dIj2sCDX4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=MxaU/AcZbiW4nrXiuvaAykRYm58=; b=NRShTsBc
	cwSu40VL1FqrUl0K/HFTLvw7czq+jJD/DsjqIc/AgMEvyBQZtRbfDm0rxpbdXdtG
	Vs5r6DtQfoJQTtqAmN/a0QuMdJh2GvbTWMLdU/P6JoeG0oLwvu20gmXMkafwCEQp
	6M7BKJTmPTTMmYH66EETl4FXbF+DpiC869E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 6CB661A8063; 
	Thu,  2 Feb 2012 12:23:31 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 12:23:32 -0800
Message-ID: <69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328194692.2924.29.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
Date: Thu, 2 Feb 2012 12:23:32 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
>> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
>> >>
>> >>
>> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> >> +                        unsigned int op, unsigned int mode,
>> >> +                        uint64_t gfn, void *buffer)
>> >> +{
>> >> +    xen_mem_event_op_t meo;
>> >> +
>> >> +    memset(&meo, 0, sizeof(meo));
>> >> +
>> >> +    meo.op      = op;
>> >> +    meo.domain  = domain_id;
>> >> +    meo.gfn     = gfn;
>> >> +    meo.buffer  = (unsigned long) buffer;
>> >
>> > Hypercall arguments need to use the xc_hypercall_buffer stuff in order
>> > to ensure that the memory is safe to access from a hypercall (in
>> > particular that it is mlocked or similar)-- I don't see where that
>> > happens for this buffer.
>> >
>> > meo itself is bounced by do_memory_op so that is OK.
>> >
>> > I was also a little suspicious of ring_addr and shared_addr in
>> > xc_mem_event_control in this regard.
>> >
>> > Or does the mem sharing code make it's own arrangements for these
>> sorts
>> > of things somewhere?
>>
>> It's rather unclean. They do not get mlock'ed (and there is no sanity
>> check to ensure they're page-aligned). They should follow the pattern
>> established in xc_mem_paging_load. I'll get on it, probably a separate
>> patch.
>
> If you are reworking this It Would Be Nice If (tm) you could make it use
> xc_hypercall_buffer_alloc and friends to allocate and manage the buffer
> while you are there e.g. the void *buffer above would become struct
> xc_hypercall_buffer *buffer -- see xc_perfc_query for example.

Took me a while to grok those hypercall buffer macros. Conclusion: that
would need to change callers of paging_load (xenpaging in tree).

Can we keep this separate? domctl interface also suffers from all these
problems. domctl->memops switch is orthogonal to the buffer badness. I
want to tackle one problem at a time.

>
> It happens that mlock has roughly the semantics we need (and so it
> mostly works) but it is not guaranteed by the specs. At some point we
> may wish to do something more robust and using the common interface will
> mean that the sharing code will benefit from that too.
>
>> There is a far more insidious problem that I'm not sure how to solve.
>> Say
>> the pager dies unexpectedly. The page hosting the ring is returned to
>> dom0's free page pool, and then re-assigned to some other process. Xen
>> never gets to find out. At best, the domain crashes before an event is
>> generated. Perhaps, Xen posts at least one event. Worst-case scenario,
>> the
>> guest generates a spate of events. Cases 2 & 3 corrupt the memory of
>> some
>> other dom0 process.
>
> How does the memory actually get mapped? Or is it actually memory
> belonging to the user process?

The user process memory is mapped by Xen: user virtual address -> mfn ->
map_domain_page. Ugly.

Agree with you that the best way to solve it is with a dom0 kernel driver.

Thanks!
Andres
>
> The gntalloc driver presumably has a similar sort of problem, might be
> interesting to take inspiration from there?
>
> There's the possibility of having a paging specific driver which takes
> care of this and all the userspace does is mmap /dev/xen/pager or
> whatever.
>
>> I'm glad I got that off my chest :) While being a very rare race
>> condition
>> (haven't actually experienced it), I am quite unsure of how to tackle it
>> cleanly.
>>
>> Andres
>> >
>> > Ian.
>> >
>> >> +
>> >> +    return do_memory_op(xch, mode, &meo, sizeof(meo));
>> >> +}
>> >
>> >
>> >
>> >
>>
>>
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt3E8-0003Qo-W7; Thu, 02 Feb 2012 20:25:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rt3E7-0003QW-LP
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:25:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328214345!13198822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14101 invoked from network); 2 Feb 2012 20:25:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:25:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208";a="10453171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 20:25:44 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	20:25:44 +0000
Message-ID: <1328214343.13189.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Thu, 2 Feb 2012 20:25:43 +0000
In-Reply-To: <69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
	<69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 20:23 +0000, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
> >> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> >> >>
> >> >>
> >> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> >> >> +                        unsigned int op, unsigned int mode,
> >> >> +                        uint64_t gfn, void *buffer)
> >> >> +{
> >> >> +    xen_mem_event_op_t meo;
> >> >> +
> >> >> +    memset(&meo, 0, sizeof(meo));
> >> >> +
> >> >> +    meo.op      = op;
> >> >> +    meo.domain  = domain_id;
> >> >> +    meo.gfn     = gfn;
> >> >> +    meo.buffer  = (unsigned long) buffer;
> >> >
> >> > Hypercall arguments need to use the xc_hypercall_buffer stuff in order
> >> > to ensure that the memory is safe to access from a hypercall (in
> >> > particular that it is mlocked or similar)-- I don't see where that
> >> > happens for this buffer.
> >> >
> >> > meo itself is bounced by do_memory_op so that is OK.
> >> >
> >> > I was also a little suspicious of ring_addr and shared_addr in
> >> > xc_mem_event_control in this regard.
> >> >
> >> > Or does the mem sharing code make it's own arrangements for these
> >> sorts
> >> > of things somewhere?
> >>
> >> It's rather unclean. They do not get mlock'ed (and there is no sanity
> >> check to ensure they're page-aligned). They should follow the pattern
> >> established in xc_mem_paging_load. I'll get on it, probably a separate
> >> patch.
> >
> > If you are reworking this It Would Be Nice If (tm) you could make it use
> > xc_hypercall_buffer_alloc and friends to allocate and manage the buffer
> > while you are there e.g. the void *buffer above would become struct
> > xc_hypercall_buffer *buffer -- see xc_perfc_query for example.
> 
> Took me a while to grok those hypercall buffer macros. Conclusion: that
> would need to change callers of paging_load (xenpaging in tree).

Yes, in this case you probably want to bubble their use right up to the
top level rather than bouncing in the internals like we do for smaller
and.or more transient data.

> Can we keep this separate? domctl interface also suffers from all these
> problems. domctl->memops switch is orthogonal to the buffer badness. I
> want to tackle one problem at a time.

Sure, read "IWBNI" as "in the fullness of time" ;-)

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt3E8-0003Qo-W7; Thu, 02 Feb 2012 20:25:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rt3E7-0003QW-LP
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:25:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328214345!13198822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14101 invoked from network); 2 Feb 2012 20:25:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:25:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208";a="10453171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 20:25:44 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	20:25:44 +0000
Message-ID: <1328214343.13189.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Thu, 2 Feb 2012 20:25:43 +0000
In-Reply-To: <69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
	<69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 20:23 +0000, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
> >> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> >> >>
> >> >>
> >> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> >> >> +                        unsigned int op, unsigned int mode,
> >> >> +                        uint64_t gfn, void *buffer)
> >> >> +{
> >> >> +    xen_mem_event_op_t meo;
> >> >> +
> >> >> +    memset(&meo, 0, sizeof(meo));
> >> >> +
> >> >> +    meo.op      = op;
> >> >> +    meo.domain  = domain_id;
> >> >> +    meo.gfn     = gfn;
> >> >> +    meo.buffer  = (unsigned long) buffer;
> >> >
> >> > Hypercall arguments need to use the xc_hypercall_buffer stuff in order
> >> > to ensure that the memory is safe to access from a hypercall (in
> >> > particular that it is mlocked or similar)-- I don't see where that
> >> > happens for this buffer.
> >> >
> >> > meo itself is bounced by do_memory_op so that is OK.
> >> >
> >> > I was also a little suspicious of ring_addr and shared_addr in
> >> > xc_mem_event_control in this regard.
> >> >
> >> > Or does the mem sharing code make it's own arrangements for these
> >> sorts
> >> > of things somewhere?
> >>
> >> It's rather unclean. They do not get mlock'ed (and there is no sanity
> >> check to ensure they're page-aligned). They should follow the pattern
> >> established in xc_mem_paging_load. I'll get on it, probably a separate
> >> patch.
> >
> > If you are reworking this It Would Be Nice If (tm) you could make it use
> > xc_hypercall_buffer_alloc and friends to allocate and manage the buffer
> > while you are there e.g. the void *buffer above would become struct
> > xc_hypercall_buffer *buffer -- see xc_perfc_query for example.
> 
> Took me a while to grok those hypercall buffer macros. Conclusion: that
> would need to change callers of paging_load (xenpaging in tree).

Yes, in this case you probably want to bubble their use right up to the
top level rather than bouncing in the internals like we do for smaller
and.or more transient data.

> Can we keep this separate? domctl interface also suffers from all these
> problems. domctl->memops switch is orthogonal to the buffer badness. I
> want to tackle one problem at a time.

Sure, read "IWBNI" as "in the fullness of time" ;-)

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:29:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3Hf-0003b6-Ki; Thu, 02 Feb 2012 20:29:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rt3He-0003au-PO
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:29:30 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328214563!13716136!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1983 invoked from network); 2 Feb 2012 20:29:24 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE002.bigfish.com) (65.55.88.13)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	2 Feb 2012 20:29:24 -0000
Received: from mail83-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 2 Feb 2012 20:29:21 +0000
Received: from mail83-tx2 (localhost [127.0.0.1])	by mail83-tx2-R.bigfish.com
	(Postfix) with ESMTP id 73E131401F3;
	Thu,  2 Feb 2012 20:29:22 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail83-tx2 (localhost.localdomain [127.0.0.1]) by mail83-tx2
	(MessageSwitch) id 1328214561264631_20476;
	Thu,  2 Feb 2012 20:29:21 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.251])	by
	mail83-tx2.bigfish.com (Postfix) with ESMTP id 2E534420049;
	Thu,  2 Feb 2012 20:29:21 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Thu, 2 Feb 2012 20:29:18 +0000
X-WSS-ID: 0LYS8WS-02-6D3-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 2B36AC8219;	Thu,  2 Feb 2012 14:29:15 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 2 Feb 2012 14:29:33 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:29:17 -0600
Message-ID: <4F2AF21C.3090305@amd.com>
Date: Thu, 2 Feb 2012 15:29:16 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
In-Reply-To: <4F2A9C1C0200007800070823@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/02/12 08:22, Jan Beulich wrote:
>>>> On 01.02.12 at 17:30, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # Date 1328108207 -3600
>> # Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>>
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on
>> family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
>> necessary: HLT and IO instructions are intercepted and therefore there is no
>> reason for erratum 400 workaround in the guest.
>>
>> This patch allows us to present a guest with certain errata as fixed,
>> regardless of the state of actual hardware.
>
> As I was about to apply this to my local tree to give it a try, I had
> to realize that the microcode integration is still not correct: There
> is (at least from an abstract perspective) no guarantee for
> cpu_request_microcode() to be called on all CPUs, yet you want
> svm_host_osvw_init() to be re-run on all of them. If you choose
> to not deal with this in a formally correct way, it should be stated
> so in a code comment (to lower the risk of surprises when someone
> touches that code) that this is not possible in practice because
> collect_cpu_info() won't currently fail for CPUs of interest.

What if svm_host_osvw_init() is called from collect_cpu_info()? There 
may be cases when svm_host_osvw_init() is called multiple times for the 
same cpu but that should be harmless (and the routine will be renamed to 
svm_host_osvw_update()).

This would change a bit the scope of things that collect_cpu_info() is 
expected to do though. But then one could argue that stashing OSVW bits 
is to some extent also collecting CPU info, albeit for a different purpose.


-boris


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:29:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3Hf-0003b6-Ki; Thu, 02 Feb 2012 20:29:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rt3He-0003au-PO
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:29:30 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328214563!13716136!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1983 invoked from network); 2 Feb 2012 20:29:24 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE002.bigfish.com) (65.55.88.13)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	2 Feb 2012 20:29:24 -0000
Received: from mail83-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 2 Feb 2012 20:29:21 +0000
Received: from mail83-tx2 (localhost [127.0.0.1])	by mail83-tx2-R.bigfish.com
	(Postfix) with ESMTP id 73E131401F3;
	Thu,  2 Feb 2012 20:29:22 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail83-tx2 (localhost.localdomain [127.0.0.1]) by mail83-tx2
	(MessageSwitch) id 1328214561264631_20476;
	Thu,  2 Feb 2012 20:29:21 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.251])	by
	mail83-tx2.bigfish.com (Postfix) with ESMTP id 2E534420049;
	Thu,  2 Feb 2012 20:29:21 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Thu, 2 Feb 2012 20:29:18 +0000
X-WSS-ID: 0LYS8WS-02-6D3-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 2B36AC8219;	Thu,  2 Feb 2012 14:29:15 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 2 Feb 2012 14:29:33 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Thu, 2 Feb 2012
	14:29:17 -0600
Message-ID: <4F2AF21C.3090305@amd.com>
Date: Thu, 2 Feb 2012 15:29:16 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
In-Reply-To: <4F2A9C1C0200007800070823@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/02/12 08:22, Jan Beulich wrote:
>>>> On 01.02.12 at 17:30, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # Date 1328108207 -3600
>> # Node ID 789bbf4f478b0e81d71240a1f1147ef66a7c8848
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>>
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on
>> family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
>> necessary: HLT and IO instructions are intercepted and therefore there is no
>> reason for erratum 400 workaround in the guest.
>>
>> This patch allows us to present a guest with certain errata as fixed,
>> regardless of the state of actual hardware.
>
> As I was about to apply this to my local tree to give it a try, I had
> to realize that the microcode integration is still not correct: There
> is (at least from an abstract perspective) no guarantee for
> cpu_request_microcode() to be called on all CPUs, yet you want
> svm_host_osvw_init() to be re-run on all of them. If you choose
> to not deal with this in a formally correct way, it should be stated
> so in a code comment (to lower the risk of surprises when someone
> touches that code) that this is not possible in practice because
> collect_cpu_info() won't currently fail for CPUs of interest.

What if svm_host_osvw_init() is called from collect_cpu_info()? There 
may be cases when svm_host_osvw_init() is called multiple times for the 
same cpu but that should be harmless (and the routine will be renamed to 
svm_host_osvw_update()).

This would change a bit the scope of things that collect_cpu_info() is 
expected to do though. But then one could argue that stashing OSVW bits 
is to some extent also collecting CPU info, albeit for a different purpose.


-boris


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:34:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3MX-0003mc-Ce; Thu, 02 Feb 2012 20:34:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt3MV-0003mV-Hn
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:34:31 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328214815!55158764!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4029 invoked from network); 2 Feb 2012 20:33:36 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:33:36 -0000
Received: by werb14 with SMTP id b14so5562821wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 12:34:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=CfoGlu1RebMtdamL4P3m3ZRX5IJJQzyWmw7gsfUtTS0=;
	b=M20DxzCiKPbbG7hO6of1i1zk7lXTZ/H7aSgs3EMgWeeaa1B1kSBMOQLlUAY4lfKSDc
	BGM+Cj9iV6F30xBZrPKYPzDkoaPmPuxpjzPJXTDlu9Nd7Yo9GQVN1nE7Mek1fxSEaKqR
	1P6slE1824P5Wqk4QIDzfSHRbx2I/3fUf8kfU=
Received: by 10.216.136.200 with SMTP id w50mr1843772wei.2.1328214870012;
	Thu, 02 Feb 2012 12:34:30 -0800 (PST)
Received: from [192.168.1.97] (122.237.66.86.rev.sfr.net. [86.66.237.122])
	by mx.google.com with ESMTPS id cb8sm2097833wib.0.2012.02.02.12.34.27
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 12:34:29 -0800 (PST)
Message-ID: <1328214866.2480.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 02 Feb 2012 21:34:26 +0100
In-Reply-To: <1328212761.28964.77.camel@dagon.hellion.org.uk>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxOTo1OSArMDAwMCwgSWFuIENhbXBiZWxsIGEg
w6ljcml0IDoKPiBPbiBUaHUsIDIwMTItMDItMDIgYXQgMTc6NDggKzAwMDAsIEVyaWMgRHVtYXpl
dCB3cm90ZToKPiA+IExlIGpldWRpIDAyIGbDqXZyaWVyIDIwMTIgw6AgMTc6MjggKzAwMDAsIFdl
aSBMaXUgYSDDqWNyaXQgOgo+ID4gCj4gPiA+IFlvdSdyZSByaWdodCBhYm91dCB0aGlzLgo+ID4g
PiAKPiA+ID4gQnV0IHRoaXMgcGFydCBpcyBkZXN0aW5lZCB0byBnZXQgd2lwZWQgb3V0IChpbiB0
aGUgdmVyeSBuZWFyIGZ1dHVyZT8pIC0tCj4gPiA+IHNlZSBmb2xsb3dpbmcgcGF0Y2hlcy4gU28g
SSBkb24ndCB0aGluayBpdCBpcyB3b3J0aHkgdG8gZml4IHRoaXMuCj4gPiA+IAo+ID4gCj4gPiBC
ZWZvcmUgYWRkaW5nIG5ldyBidWdzLCB5b3UgbXVzdCBmaXggcHJldmlvdXMgb25lcy4KPiAKPiBJ
J3ZlIG5ldmVyIGhlYXJkIG9mIHRoaXMgcmVxdWlyZW1lbnQgYmVmb3JlISBJdCdzIGEgd29uZGVy
IGFueW9uZSBldmVyCj4gZ2V0cyBhbnl0aGluZyBkb25lLgo+IAo+IEFueXdheSwgSSB0aGluayBp
dCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIGp1c3QgcmVtb3ZlIHRoZSBrdGhyZWFkX2JpbmQKPiBj
YWxsIGZyb20gdGhpcyBsb29wLiBXZSBkb24ndCBhY3R1YWxseSB3YW50L25lZWQgYSB0aHJlYWQg
cGVyIG9ubGluZSBDUFUKPiBpbiBhbnkgc3RyaWN0IHNlbnNlLCB3ZSBqdXN0IHdhbnQgdGhlcmUg
dG8gYmUgc29tZSBudW1iZXIgb2Ygd29ya2VyCj4gdGhyZWFkcyBhdmFpbGFibGUgYW5kIH5udW1j
cHVzIGF0IHN0YXJ0IG9mIGRheSBpcyBhIGdvb2QgZW5vdWdoCj4gYXBwcm94aW1hdGlvbiBmb3Ig
dGhhdCBudW1iZXIuIFRoZXJlIGhhdmUgYmVlbiBwYXRjaGVzIGZsb2F0aW5nIGFyb3VuZAo+IGlu
IHRoZSBwYXN0IHdoaWNoIG1ha2UgdGhlIG51bWJlciBvZiBncm91cHMgYSBtb2R1bGUgcGFyYW1l
dGVyIHdoaWNoCj4gd291bGQgYWxzbyBiZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZGlnIG91dCBp
ZiB3ZSB3ZXJlbid0IGp1c3QgYWJvdXQgdG8KPiByZW1vdmUgYWxsIHRoaXMgY29kZSBhbnl3YXku
Cj4gCj4gU28gcmVtb3ZpbmcgdGhlIGt0aHJlYWRfYmluZCBpcyBnb29kIGVub3VnaCBmb3IgdGhl
IHNob3J0IHRlcm0sIGFuZCBmb3IKPiBzdGFibGUgaWYgcGVvcGxlIGZlZWwgdGhhdCBpcyBuZWNl
c3NhcnksIGFuZCB3ZSBjYW4gY29udGludWUgaW4gbWFpbmxpbmUKPiB3aXRoIHRoZSBkaXJlY3Rp
b24gV2VpJ3MgcGF0Y2hlcyBhcmUgdGFraW5nIHVzLgo+IAoKVGhhdCBzb3VuZHMgYSByaWdodCBm
aXguCgpXaHkgZG8gdGhpbmsgaXRzIG5vdCByZWFzb25hYmxlIHRoYXQgSSBhc2sgYSBidWcgZml4
ID8KCk5leHQgdGltZSwgZG9udCBib3RoZXIgc2VuZCBwYXRjaGVzIGZvciByZXZpZXcgaWYgeW91
IGRvbnQgd2FudApyZXZpZXdlcnMuCgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:34:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:34:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3MX-0003mc-Ce; Thu, 02 Feb 2012 20:34:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt3MV-0003mV-Hn
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:34:31 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328214815!55158764!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4029 invoked from network); 2 Feb 2012 20:33:36 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:33:36 -0000
Received: by werb14 with SMTP id b14so5562821wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 12:34:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=CfoGlu1RebMtdamL4P3m3ZRX5IJJQzyWmw7gsfUtTS0=;
	b=M20DxzCiKPbbG7hO6of1i1zk7lXTZ/H7aSgs3EMgWeeaa1B1kSBMOQLlUAY4lfKSDc
	BGM+Cj9iV6F30xBZrPKYPzDkoaPmPuxpjzPJXTDlu9Nd7Yo9GQVN1nE7Mek1fxSEaKqR
	1P6slE1824P5Wqk4QIDzfSHRbx2I/3fUf8kfU=
Received: by 10.216.136.200 with SMTP id w50mr1843772wei.2.1328214870012;
	Thu, 02 Feb 2012 12:34:30 -0800 (PST)
Received: from [192.168.1.97] (122.237.66.86.rev.sfr.net. [86.66.237.122])
	by mx.google.com with ESMTPS id cb8sm2097833wib.0.2012.02.02.12.34.27
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 12:34:29 -0800 (PST)
Message-ID: <1328214866.2480.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 02 Feb 2012 21:34:26 +0100
In-Reply-To: <1328212761.28964.77.camel@dagon.hellion.org.uk>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAxOTo1OSArMDAwMCwgSWFuIENhbXBiZWxsIGEg
w6ljcml0IDoKPiBPbiBUaHUsIDIwMTItMDItMDIgYXQgMTc6NDggKzAwMDAsIEVyaWMgRHVtYXpl
dCB3cm90ZToKPiA+IExlIGpldWRpIDAyIGbDqXZyaWVyIDIwMTIgw6AgMTc6MjggKzAwMDAsIFdl
aSBMaXUgYSDDqWNyaXQgOgo+ID4gCj4gPiA+IFlvdSdyZSByaWdodCBhYm91dCB0aGlzLgo+ID4g
PiAKPiA+ID4gQnV0IHRoaXMgcGFydCBpcyBkZXN0aW5lZCB0byBnZXQgd2lwZWQgb3V0IChpbiB0
aGUgdmVyeSBuZWFyIGZ1dHVyZT8pIC0tCj4gPiA+IHNlZSBmb2xsb3dpbmcgcGF0Y2hlcy4gU28g
SSBkb24ndCB0aGluayBpdCBpcyB3b3J0aHkgdG8gZml4IHRoaXMuCj4gPiA+IAo+ID4gCj4gPiBC
ZWZvcmUgYWRkaW5nIG5ldyBidWdzLCB5b3UgbXVzdCBmaXggcHJldmlvdXMgb25lcy4KPiAKPiBJ
J3ZlIG5ldmVyIGhlYXJkIG9mIHRoaXMgcmVxdWlyZW1lbnQgYmVmb3JlISBJdCdzIGEgd29uZGVy
IGFueW9uZSBldmVyCj4gZ2V0cyBhbnl0aGluZyBkb25lLgo+IAo+IEFueXdheSwgSSB0aGluayBp
dCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIGp1c3QgcmVtb3ZlIHRoZSBrdGhyZWFkX2JpbmQKPiBj
YWxsIGZyb20gdGhpcyBsb29wLiBXZSBkb24ndCBhY3R1YWxseSB3YW50L25lZWQgYSB0aHJlYWQg
cGVyIG9ubGluZSBDUFUKPiBpbiBhbnkgc3RyaWN0IHNlbnNlLCB3ZSBqdXN0IHdhbnQgdGhlcmUg
dG8gYmUgc29tZSBudW1iZXIgb2Ygd29ya2VyCj4gdGhyZWFkcyBhdmFpbGFibGUgYW5kIH5udW1j
cHVzIGF0IHN0YXJ0IG9mIGRheSBpcyBhIGdvb2QgZW5vdWdoCj4gYXBwcm94aW1hdGlvbiBmb3Ig
dGhhdCBudW1iZXIuIFRoZXJlIGhhdmUgYmVlbiBwYXRjaGVzIGZsb2F0aW5nIGFyb3VuZAo+IGlu
IHRoZSBwYXN0IHdoaWNoIG1ha2UgdGhlIG51bWJlciBvZiBncm91cHMgYSBtb2R1bGUgcGFyYW1l
dGVyIHdoaWNoCj4gd291bGQgYWxzbyBiZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZGlnIG91dCBp
ZiB3ZSB3ZXJlbid0IGp1c3QgYWJvdXQgdG8KPiByZW1vdmUgYWxsIHRoaXMgY29kZSBhbnl3YXku
Cj4gCj4gU28gcmVtb3ZpbmcgdGhlIGt0aHJlYWRfYmluZCBpcyBnb29kIGVub3VnaCBmb3IgdGhl
IHNob3J0IHRlcm0sIGFuZCBmb3IKPiBzdGFibGUgaWYgcGVvcGxlIGZlZWwgdGhhdCBpcyBuZWNl
c3NhcnksIGFuZCB3ZSBjYW4gY29udGludWUgaW4gbWFpbmxpbmUKPiB3aXRoIHRoZSBkaXJlY3Rp
b24gV2VpJ3MgcGF0Y2hlcyBhcmUgdGFraW5nIHVzLgo+IAoKVGhhdCBzb3VuZHMgYSByaWdodCBm
aXguCgpXaHkgZG8gdGhpbmsgaXRzIG5vdCByZWFzb25hYmxlIHRoYXQgSSBhc2sgYSBidWcgZml4
ID8KCk5leHQgdGltZSwgZG9udCBib3RoZXIgc2VuZCBwYXRjaGVzIGZvciByZXZpZXcgaWYgeW91
IGRvbnQgd2FudApyZXZpZXdlcnMuCgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:38:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt3Pg-0003u5-0l; Thu, 02 Feb 2012 20:37:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt3Pe-0003tp-PX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:37:47 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328215060!13487318!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14617 invoked from network); 2 Feb 2012 20:37:40 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:37:40 -0000
Received: by werb14 with SMTP id b14so5571567wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 12:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=UqtBcr+1HlOC1KQiJUiZzo0NFJAQboBuru1dww5qICA=;
	b=nOmxynyZD0rUdEUOCdJzXIzvZfluCW5309APShSLsBavRDJTouWuORdfcqMYGZmri2
	6hXFDA18e1P2CgB0heP/i50y9Pt3d+4pNK1CYKaaMt4Tu1Ka+c/8/2i7TJwJ/Su5VTS3
	tq9fIWnaFBB8V3wqgrEjXs+CFd+MNr6AnvOwk=
Received: by 10.216.131.6 with SMTP id l6mr1779407wei.45.1328215060459;
	Thu, 02 Feb 2012 12:37:40 -0800 (PST)
Received: from [192.168.1.97] (122.237.66.86.rev.sfr.net. [86.66.237.122])
	by mx.google.com with ESMTPS id cb8sm2113745wib.0.2012.02.02.12.37.38
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 12:37:39 -0800 (PST)
Message-ID: <1328215057.2480.20.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 02 Feb 2012 21:37:37 +0100
In-Reply-To: <1328214866.2480.18.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAyMTozNCArMDEwMCwgRXJpYyBEdW1hemV0IGEg
w6ljcml0IDoKCj4gVGhhdCBzb3VuZHMgYSByaWdodCBmaXguCj4gCj4gV2h5IGRvIHRoaW5rIGl0
cyBub3QgcmVhc29uYWJsZSB0aGF0IEkgYXNrIGEgYnVnIGZpeCA/Cj4gCj4gTmV4dCB0aW1lLCBk
b250IGJvdGhlciBzZW5kIHBhdGNoZXMgZm9yIHJldmlldyBpZiB5b3UgZG9udCB3YW50Cj4gcmV2
aWV3ZXJzLgoKRllJLCBoZXJlIHRoZSB0cmFjZSB5b3UgY2FuIGdldCByaWdodCBub3cgd2l0aCB0
aGlzIGJ1ZyA6CgpbIDExODAuMTE0NjgyXSBXQVJOSU5HOiBhdCBhcmNoL3g4Ni9rZXJuZWwvc21w
LmM6MTIwIG5hdGl2ZV9zbXBfc2VuZF9yZXNjaGVkdWxlKzB4NWIvMHg2MCgpClsgMTE4MC4xMTQ2
ODVdIEhhcmR3YXJlIG5hbWU6IFByb0xpYW50IEJMNDYwYyBHNgpbIDExODAuMTE0Njg2XSBNb2R1
bGVzIGxpbmtlZCBpbjogaXBtaV9kZXZpbnRmIG5mc2QgZXhwb3J0ZnMgaXBtaV9zaSBocGlsbyBi
bngyeCBjcmMzMmMgbGliY3JjMzJjIG1kaW8gW2xhc3QgdW5sb2FkZWQ6IHNjc2lfd2FpdF9zY2Fu
XQpbIDExODAuMTE0Njk3XSBQaWQ6IDcsIGNvbW06IG1pZ3JhdGlvbi8xIE5vdCB0YWludGVkIDMu
My4wLXJjMisgIzYwOQpbIDExODAuMTE0Njk5XSBDYWxsIFRyYWNlOgpbIDExODAuMTE0NzAxXSAg
PElSUT4gIFs8ZmZmZmZmZmY4MTAzN2FkZj5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2YvMHhj
MApbIDExODAuMTE0NzA4XSAgWzxmZmZmZmZmZjgxMDM3YjNhPl0gd2Fybl9zbG93cGF0aF9udWxs
KzB4MWEvMHgyMApbIDExODAuMTE0NzExXSAgWzxmZmZmZmZmZjgxMDFlY2ZiPl0gbmF0aXZlX3Nt
cF9zZW5kX3Jlc2NoZWR1bGUrMHg1Yi8weDYwClsgMTE4MC4xMTQ3MTVdICBbPGZmZmZmZmZmODEw
NzQ0ZWM+XSB0cmlnZ2VyX2xvYWRfYmFsYW5jZSsweDI4Yy8weDM3MApbIDExODAuMTE0NzIwXSAg
WzxmZmZmZmZmZjgxMDZiZTE0Pl0gc2NoZWR1bGVyX3RpY2srMHgxMTQvMHgxNjAKWyAxMTgwLjEx
NDcyNF0gIFs8ZmZmZmZmZmY4MTA0OTU2ZT5dIHVwZGF0ZV9wcm9jZXNzX3RpbWVzKzB4NmUvMHg5
MApbIDExODAuMTE0NzI5XSAgWzxmZmZmZmZmZjgxMDhjNjE0Pl0gdGlja19zY2hlZF90aW1lcisw
eDY0LzB4YzAKWyAxMTgwLjExNDczM10gIFs8ZmZmZmZmZmY4MTA1ZmU1ND5dIF9fcnVuX2hydGlt
ZXIrMHg4NC8weDFmMApbIDExODAuMTE0NzM2XSAgWzxmZmZmZmZmZjgxMDhjNWIwPl0gPyB0aWNr
X25vaHpfaGFuZGxlcisweGYwLzB4ZjAKWyAxMTgwLjExNDczOV0gIFs8ZmZmZmZmZmY4MTAzZjI3
MT5dID8gX19kb19zb2Z0aXJxKzB4MTAxLzB4MjQwClsgMTE4MC4xMTQ3NDJdICBbPGZmZmZmZmZm
ODEwNjA3ODM+XSBocnRpbWVyX2ludGVycnVwdCsweGYzLzB4MjIwClsgMTE4MC4xMTQ3NDddICBb
PGZmZmZmZmZmODEwYTkwYjA+XSA/IHF1ZXVlX3N0b3BfY3B1c193b3JrKzB4MTAwLzB4MTAwClsg
MTE4MC4xMTQ3NTFdICBbPGZmZmZmZmZmODE3MWVlMDk+XSBzbXBfYXBpY190aW1lcl9pbnRlcnJ1
cHQrMHg2OS8weDk5ClsgMTE4MC4xMTQ3NTRdICBbPGZmZmZmZmZmODE3MWRkNGI+XSBhcGljX3Rp
bWVyX2ludGVycnVwdCsweDZiLzB4NzAKWyAxMTgwLjExNDc1Nl0gIDxFT0k+ICBbPGZmZmZmZmZm
ODEwYTkxNDM+XSA/IHN0b3BfbWFjaGluZV9jcHVfc3RvcCsweDkzLzB4YzAKWyAxMTgwLjExNDc2
MV0gIFs8ZmZmZmZmZmY4MTBhOGRhNz5dIGNwdV9zdG9wcGVyX3RocmVhZCsweGQ3LzB4MWEwClsg
MTE4MC4xMTQ3NjZdICBbPGZmZmZmZmZmODE3MTNkYzc+XSA/IF9fc2NoZWR1bGUrMHgzYTcvMHg3
ZTAKWyAxMTgwLjExNDc2OF0gIFs8ZmZmZmZmZmY4MTA2NDA1OD5dID8gX193YWtlX3VwX2NvbW1v
bisweDU4LzB4OTAKWyAxMTgwLjExNDc3MV0gIFs8ZmZmZmZmZmY4MTBhOGNkMD5dID8gY3B1X3N0
b3Bfc2lnbmFsX2RvbmUrMHg0MC8weDQwClsgMTE4MC4xMTQ3NzNdICBbPGZmZmZmZmZmODEwNWI1
YzM+XSBrdGhyZWFkKzB4OTMvMHhhMApbIDExODAuMTE0Nzc2XSAgWzxmZmZmZmZmZjgxNzFlNTk0
Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg0LzB4MTAKWyAxMTgwLjExNDc3OV0gIFs8ZmZmZmZm
ZmY4MTA1YjUzMD5dID8ga3RocmVhZF9mcmVlemFibGVfc2hvdWxkX3N0b3ArMHg4MC8weDgwClsg
MTE4MC4xMTQ3ODFdICBbPGZmZmZmZmZmODE3MWU1OTA+XSA/IGdzX2NoYW5nZSsweGIvMHhiCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:38:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20: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.xensource.com>)
	id 1Rt3Pg-0003u5-0l; Thu, 02 Feb 2012 20:37:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rt3Pe-0003tp-PX
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:37:47 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328215060!13487318!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14617 invoked from network); 2 Feb 2012 20:37:40 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:37:40 -0000
Received: by werb14 with SMTP id b14so5571567wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 12:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=UqtBcr+1HlOC1KQiJUiZzo0NFJAQboBuru1dww5qICA=;
	b=nOmxynyZD0rUdEUOCdJzXIzvZfluCW5309APShSLsBavRDJTouWuORdfcqMYGZmri2
	6hXFDA18e1P2CgB0heP/i50y9Pt3d+4pNK1CYKaaMt4Tu1Ka+c/8/2i7TJwJ/Su5VTS3
	tq9fIWnaFBB8V3wqgrEjXs+CFd+MNr6AnvOwk=
Received: by 10.216.131.6 with SMTP id l6mr1779407wei.45.1328215060459;
	Thu, 02 Feb 2012 12:37:40 -0800 (PST)
Received: from [192.168.1.97] (122.237.66.86.rev.sfr.net. [86.66.237.122])
	by mx.google.com with ESMTPS id cb8sm2113745wib.0.2012.02.02.12.37.38
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 12:37:39 -0800 (PST)
Message-ID: <1328215057.2480.20.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 02 Feb 2012 21:37:37 +0100
In-Reply-To: <1328214866.2480.18.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgamV1ZGkgMDIgZsOpdnJpZXIgMjAxMiDDoCAyMTozNCArMDEwMCwgRXJpYyBEdW1hemV0IGEg
w6ljcml0IDoKCj4gVGhhdCBzb3VuZHMgYSByaWdodCBmaXguCj4gCj4gV2h5IGRvIHRoaW5rIGl0
cyBub3QgcmVhc29uYWJsZSB0aGF0IEkgYXNrIGEgYnVnIGZpeCA/Cj4gCj4gTmV4dCB0aW1lLCBk
b250IGJvdGhlciBzZW5kIHBhdGNoZXMgZm9yIHJldmlldyBpZiB5b3UgZG9udCB3YW50Cj4gcmV2
aWV3ZXJzLgoKRllJLCBoZXJlIHRoZSB0cmFjZSB5b3UgY2FuIGdldCByaWdodCBub3cgd2l0aCB0
aGlzIGJ1ZyA6CgpbIDExODAuMTE0NjgyXSBXQVJOSU5HOiBhdCBhcmNoL3g4Ni9rZXJuZWwvc21w
LmM6MTIwIG5hdGl2ZV9zbXBfc2VuZF9yZXNjaGVkdWxlKzB4NWIvMHg2MCgpClsgMTE4MC4xMTQ2
ODVdIEhhcmR3YXJlIG5hbWU6IFByb0xpYW50IEJMNDYwYyBHNgpbIDExODAuMTE0Njg2XSBNb2R1
bGVzIGxpbmtlZCBpbjogaXBtaV9kZXZpbnRmIG5mc2QgZXhwb3J0ZnMgaXBtaV9zaSBocGlsbyBi
bngyeCBjcmMzMmMgbGliY3JjMzJjIG1kaW8gW2xhc3QgdW5sb2FkZWQ6IHNjc2lfd2FpdF9zY2Fu
XQpbIDExODAuMTE0Njk3XSBQaWQ6IDcsIGNvbW06IG1pZ3JhdGlvbi8xIE5vdCB0YWludGVkIDMu
My4wLXJjMisgIzYwOQpbIDExODAuMTE0Njk5XSBDYWxsIFRyYWNlOgpbIDExODAuMTE0NzAxXSAg
PElSUT4gIFs8ZmZmZmZmZmY4MTAzN2FkZj5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2YvMHhj
MApbIDExODAuMTE0NzA4XSAgWzxmZmZmZmZmZjgxMDM3YjNhPl0gd2Fybl9zbG93cGF0aF9udWxs
KzB4MWEvMHgyMApbIDExODAuMTE0NzExXSAgWzxmZmZmZmZmZjgxMDFlY2ZiPl0gbmF0aXZlX3Nt
cF9zZW5kX3Jlc2NoZWR1bGUrMHg1Yi8weDYwClsgMTE4MC4xMTQ3MTVdICBbPGZmZmZmZmZmODEw
NzQ0ZWM+XSB0cmlnZ2VyX2xvYWRfYmFsYW5jZSsweDI4Yy8weDM3MApbIDExODAuMTE0NzIwXSAg
WzxmZmZmZmZmZjgxMDZiZTE0Pl0gc2NoZWR1bGVyX3RpY2srMHgxMTQvMHgxNjAKWyAxMTgwLjEx
NDcyNF0gIFs8ZmZmZmZmZmY4MTA0OTU2ZT5dIHVwZGF0ZV9wcm9jZXNzX3RpbWVzKzB4NmUvMHg5
MApbIDExODAuMTE0NzI5XSAgWzxmZmZmZmZmZjgxMDhjNjE0Pl0gdGlja19zY2hlZF90aW1lcisw
eDY0LzB4YzAKWyAxMTgwLjExNDczM10gIFs8ZmZmZmZmZmY4MTA1ZmU1ND5dIF9fcnVuX2hydGlt
ZXIrMHg4NC8weDFmMApbIDExODAuMTE0NzM2XSAgWzxmZmZmZmZmZjgxMDhjNWIwPl0gPyB0aWNr
X25vaHpfaGFuZGxlcisweGYwLzB4ZjAKWyAxMTgwLjExNDczOV0gIFs8ZmZmZmZmZmY4MTAzZjI3
MT5dID8gX19kb19zb2Z0aXJxKzB4MTAxLzB4MjQwClsgMTE4MC4xMTQ3NDJdICBbPGZmZmZmZmZm
ODEwNjA3ODM+XSBocnRpbWVyX2ludGVycnVwdCsweGYzLzB4MjIwClsgMTE4MC4xMTQ3NDddICBb
PGZmZmZmZmZmODEwYTkwYjA+XSA/IHF1ZXVlX3N0b3BfY3B1c193b3JrKzB4MTAwLzB4MTAwClsg
MTE4MC4xMTQ3NTFdICBbPGZmZmZmZmZmODE3MWVlMDk+XSBzbXBfYXBpY190aW1lcl9pbnRlcnJ1
cHQrMHg2OS8weDk5ClsgMTE4MC4xMTQ3NTRdICBbPGZmZmZmZmZmODE3MWRkNGI+XSBhcGljX3Rp
bWVyX2ludGVycnVwdCsweDZiLzB4NzAKWyAxMTgwLjExNDc1Nl0gIDxFT0k+ICBbPGZmZmZmZmZm
ODEwYTkxNDM+XSA/IHN0b3BfbWFjaGluZV9jcHVfc3RvcCsweDkzLzB4YzAKWyAxMTgwLjExNDc2
MV0gIFs8ZmZmZmZmZmY4MTBhOGRhNz5dIGNwdV9zdG9wcGVyX3RocmVhZCsweGQ3LzB4MWEwClsg
MTE4MC4xMTQ3NjZdICBbPGZmZmZmZmZmODE3MTNkYzc+XSA/IF9fc2NoZWR1bGUrMHgzYTcvMHg3
ZTAKWyAxMTgwLjExNDc2OF0gIFs8ZmZmZmZmZmY4MTA2NDA1OD5dID8gX193YWtlX3VwX2NvbW1v
bisweDU4LzB4OTAKWyAxMTgwLjExNDc3MV0gIFs8ZmZmZmZmZmY4MTBhOGNkMD5dID8gY3B1X3N0
b3Bfc2lnbmFsX2RvbmUrMHg0MC8weDQwClsgMTE4MC4xMTQ3NzNdICBbPGZmZmZmZmZmODEwNWI1
YzM+XSBrdGhyZWFkKzB4OTMvMHhhMApbIDExODAuMTE0Nzc2XSAgWzxmZmZmZmZmZjgxNzFlNTk0
Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg0LzB4MTAKWyAxMTgwLjExNDc3OV0gIFs8ZmZmZmZm
ZmY4MTA1YjUzMD5dID8ga3RocmVhZF9mcmVlemFibGVfc2hvdWxkX3N0b3ArMHg4MC8weDgwClsg
MTE4MC4xMTQ3ODFdICBbPGZmZmZmZmZmODE3MWU1OTA+XSA/IGdzX2NoYW5nZSsweGIvMHhiCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:50:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:50:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3bx-0004cK-C3; Thu, 02 Feb 2012 20:50:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rt3bw-0004bv-LS
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:50:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328215822!13733627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23687 invoked from network); 2 Feb 2012 20:50:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,348,1325462400"; d="scan'208";a="10453357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 20:50: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.213.0; Thu, 2 Feb 2012
	20:50:21 +0000
Message-ID: <1328215821.13189.24.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 2 Feb 2012 20:50:21 +0000
In-Reply-To: <1328214866.2480.18.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:
> Le jeudi 02 f=E9vrier 2012 =E0 19:59 +0000, Ian Campbell a =E9crit :
> > On Thu, 2012-02-02 at 17:48 +0000, Eric Dumazet wrote:
> > > Le jeudi 02 f=E9vrier 2012 =E0 17:28 +0000, Wei Liu a =E9crit :
> > > =

> > > > You're right about this.
> > > > =

> > > > But this part is destined to get wiped out (in the very near future=
?) --
> > > > see following patches. So I don't think it is worthy to fix this.
> > > > =

> > > =

> > > Before adding new bugs, you must fix previous ones.
> > =

> > I've never heard of this requirement before! It's a wonder anyone ever
> > gets anything done.
> > =

> > Anyway, I think it would be reasonable to just remove the kthread_bind
> > call from this loop. We don't actually want/need a thread per online CPU
> > in any strict sense, we just want there to be some number of worker
> > threads available and ~numcpus at start of day is a good enough
> > approximation for that number. There have been patches floating around
> > in the past which make the number of groups a module parameter which
> > would also be a reasonable thing to dig out if we weren't just about to
> > remove all this code anyway.
> > =

> > So removing the kthread_bind is good enough for the short term, and for
> > stable if people feel that is necessary, and we can continue in mainline
> > with the direction Wei's patches are taking us.
> > =

> =

> That sounds a right fix.
>
> Why do think its not reasonable that I ask a bug fix ?

I don't think it is at all unreasonable to ask for bug fixes but in this
case Wei's series is removing the code in question (which would also
undoubtedly fix the bug).

As it happens the fix turns out to be simple but if it were complex I
would perhaps have disagreed more strongly about spending effort fixing
code that is removed 2 patches later, although obviously that would have
depended on the specifics of the fix in that case.

> Next time, dont bother send patches for review if you dont want
> reviewers.

The review which you are doing is certainly very much appreciated, I'm
sorry if my disagreement over this one point gave/gives the impression
that it is not.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 20:50:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 20:50:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt3bx-0004cK-C3; Thu, 02 Feb 2012 20:50:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rt3bw-0004bv-LS
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 20:50:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328215822!13733627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23687 invoked from network); 2 Feb 2012 20:50:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 20:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,348,1325462400"; d="scan'208";a="10453357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 20:50: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.213.0; Thu, 2 Feb 2012
	20:50:21 +0000
Message-ID: <1328215821.13189.24.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 2 Feb 2012 20:50:21 +0000
In-Reply-To: <1328214866.2480.18.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:
> Le jeudi 02 f=E9vrier 2012 =E0 19:59 +0000, Ian Campbell a =E9crit :
> > On Thu, 2012-02-02 at 17:48 +0000, Eric Dumazet wrote:
> > > Le jeudi 02 f=E9vrier 2012 =E0 17:28 +0000, Wei Liu a =E9crit :
> > > =

> > > > You're right about this.
> > > > =

> > > > But this part is destined to get wiped out (in the very near future=
?) --
> > > > see following patches. So I don't think it is worthy to fix this.
> > > > =

> > > =

> > > Before adding new bugs, you must fix previous ones.
> > =

> > I've never heard of this requirement before! It's a wonder anyone ever
> > gets anything done.
> > =

> > Anyway, I think it would be reasonable to just remove the kthread_bind
> > call from this loop. We don't actually want/need a thread per online CPU
> > in any strict sense, we just want there to be some number of worker
> > threads available and ~numcpus at start of day is a good enough
> > approximation for that number. There have been patches floating around
> > in the past which make the number of groups a module parameter which
> > would also be a reasonable thing to dig out if we weren't just about to
> > remove all this code anyway.
> > =

> > So removing the kthread_bind is good enough for the short term, and for
> > stable if people feel that is necessary, and we can continue in mainline
> > with the direction Wei's patches are taking us.
> > =

> =

> That sounds a right fix.
>
> Why do think its not reasonable that I ask a bug fix ?

I don't think it is at all unreasonable to ask for bug fixes but in this
case Wei's series is removing the code in question (which would also
undoubtedly fix the bug).

As it happens the fix turns out to be simple but if it were complex I
would perhaps have disagreed more strongly about spending effort fixing
code that is removed 2 patches later, although obviously that would have
depended on the specifics of the fix in that case.

> Next time, dont bother send patches for review if you dont want
> reviewers.

The review which you are doing is certainly very much appreciated, I'm
sorry if my disagreement over this one point gave/gives the impression
that it is not.

Ian.


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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 21:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 21: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.xensource.com>)
	id 1Rt3xJ-0004wB-Ir; Thu, 02 Feb 2012 21:12:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qrux.qed@gmail.com>) id 1Rt3xI-0004w6-H1
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 21:12:32 +0000
X-Env-Sender: qrux.qed@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328217143!13438666!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17823 invoked from network); 2 Feb 2012 21:12:25 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 21:12:25 -0000
Received: by damc16 with SMTP id c16so13926248dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 13:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=content-type:mime-version:subject:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=UbPnhIvUvi3jtUHZvh1gqcZKB2l0zQtw1TPL3gN0BiE=;
	b=cXXDMIiX5Tf9EqDGHvojWkVNZPW0LBts+BWhioR6ILFKKE1do0y1nCZC81jp5fyNkM
	Qd9yZVa0KDu0+GDyZ//K1aubYB8OMF/3apc7UYT0eVWYzntSMOyE0Y0sjKyKmg8HdmpP
	tpblYzL3YuNvkmvcNOaz/vi6m+rTNcCpmoo10=
Received: by 10.68.73.105 with SMTP id k9mr10212266pbv.121.1328217143264;
	Thu, 02 Feb 2012 13:12:23 -0800 (PST)
Received: from [192.168.0.6] (c-71-198-0-100.hsd1.ca.comcast.net.
	[71.198.0.100])
	by mx.google.com with ESMTPS id i10sm8109011pbg.10.2012.02.02.13.12.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 13:12:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Qrux <qrux.qed@gmail.com>
In-Reply-To: <mailman.2350.1328186375.1471.xen-devel@lists.xensource.com>
Date: Thu, 2 Feb 2012 13:12:19 -0800
Message-Id: <CE5198A7-8FA3-4F24-8AD1-582FF84EEAFF@gmail.com>
References: <mailman.2350.1328186375.1471.xen-devel@lists.xensource.com>
To: xen-devel@lists.xensource.com
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 38 - autoconf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 2, 2012, at 4:39 AM, xen-devel-request@lists.xensource.com wrote:

> Today's Topics:
> 
>   1. Re: [PATCH v4] build: add autoconf to replace custom checks
>      in tools/check (Ian Campbell)

Howdy all,

I'm new to the Xen-Devel list, but I've been using Xen for many years.  Xen is a great product, and the collective work you've done has been amazing.  I'm excited to see a digest post about moving toward autoconf.  Along those lines, I have some input for the build process.  There may be bits that are factually wrong; and I'd be happy to stand corrected; however, much of what follows are perceptions, which I think could be equally important to the long term success of Xen, especially with competitors like KVM.

(I sent this to Ian, and he felt it belonged on the list.)

* * *

I've been using Xen on openSUSE for a long time.  My use case for Xen:

	* Pure 64-bit dom0.
	* Pure 64-bit pure PV domUs.
	* No need for X11--CLI management is fine.
	* No need for VGA-passthrough (ssh is enough).
	* No need for any fancy device-handling or HVM support.

After two ugly hacks, (but a "working" hypervisor, dom0, and domU), my sense of the Xen build process is, basically, that it tries to build too much stuff.  For example, the Hypervisor is separated from the tools.  Good.  But, all the tools are bunched together, including xl, xm, firmware, PVHVM stuff.  Bad?  That seems like a horrid lack of separation.  And, my perception is that configuration is harder--or perhaps scarier--that it needs to be, with a top-level Config.mk containing variables (which are easy enough to toggle) but also tons of logic (which makes me not want to work in that file).

Long story short, what I thought was the most "baseline" case (64-bit dom0, 64-bit domUs, pure PV, no HVM or PVHVM, no X11, and just wanting the xl tools) turned out to be much uglier than it seems was necessary.  As you move toward autoconf, I would hope that there will be (somewhat comprehensible) switches like:

	--with-X11-tools
	--without-X11-tools
	--with-xm
	--without-xm
	--no-32-bit-support

I propose that the configure process tries to separate as much as possible; e.g., keep all the tools apart from each other, and separate out mandatory (e.g., xl) from not (X11 stuff) and "possibly necessary based on your use case" (e.g., tools/firmware for HVM guests).

I also propose that when Xen is to be built from source, the build system should aggressively prune non-critical items (i.e., not the hypervisor or xl/xm); i.e., those parts should not be included unless specified (e.g., tools/firmware).  Whatever is in the default build should allow a user to run SOME specific baseline dom0/domU configuration (I would think the PV default is the least dependent mode), but leave everything else to the builder.

Why do I think that?  Because of the adage:

	"Make it easy to do what's easy, and possible to do what's hard."

Integration is the value-add provided by commercial distros. They have the resources to put full-time staff onto issues, even if they're simply liaising with the Xen developers.  But, small-system-builders--many of which provided the critical mass for Xen to come up--can get bogged down in these complex dependencies.

Sure, branding is important from Xen's marketing perspective; it's nice to be able to release a fully-functional product that does everything it says "on the box".  But, again, I think that's something that the commercial groups are doing fine with.  They can release their implementation that supports every bell and whistle.  But, I would still submit that folks who compile Xen themselves would like a slightly less "hairy" experience, and could live without certain features.  They would also have commercial distros to fall back on, or let other non-commercial projects (NetBSD, Ubuntu, LFS) catch up, and inform them.  So, since that's already the case, shouldn't the default Xen build require as little as possible--but be aggressive in building a usable target, even if some features are missing?

TL;DR--

	* Define "baseline" functionality with a minimum set of dependencies.

	* Have autoconf fail if those deps aren't met.

	* If those deps *are* met (kernel settings, compiler, etc)...

	* ...be able to build a "baseline" that allows Xen to function.

	* Add other tools (with external dependencies) purely as opt-ins.

I think that would follow the principle of least-surprise, in a configuration sense.  Other large systems, like Apache or PHP or Postgres, seem to try to detect features, and incorporate them if found.  But, if those features don't exist, they don't hamper the parts that can be properly built.  I think those systems aggressively try to successfully build a target.  And, the default configuration is obviously a subset of all the available features, which are left to the builder's choice.  There *is* a sense of what a "baseline" build for those systems is like, even if it's a de-facto result of C;M;MI.  I believe that my system (LFS) is as bare a system as one can reasonably have (that's not embedded).  I'd be happy to help test the build.

Again, I respect all the hard and wonderful work that's been done.  Yet, I think these are important issues that may influence the future of Xen's success.  KVM is a gnarly competitor, and it seems to build with relative ease (granted, it's a Linux-host-only solution).  Sure, Xen is a Type-1 hypervisor, is mature, and has a lot of users.  But, its perceived complexity seems to be many many orders of magnitude higher that the perceived benefit.  That doesn't seem good for Xen's brand...

I hope this will spark some dialogue, and I'm happy to participate further either privately or on the lists.

	Q




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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 21:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 21: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.xensource.com>)
	id 1Rt3xJ-0004wB-Ir; Thu, 02 Feb 2012 21:12:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qrux.qed@gmail.com>) id 1Rt3xI-0004w6-H1
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 21:12:32 +0000
X-Env-Sender: qrux.qed@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328217143!13438666!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17823 invoked from network); 2 Feb 2012 21:12:25 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 21:12:25 -0000
Received: by damc16 with SMTP id c16so13926248dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 13:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=content-type:mime-version:subject:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=UbPnhIvUvi3jtUHZvh1gqcZKB2l0zQtw1TPL3gN0BiE=;
	b=cXXDMIiX5Tf9EqDGHvojWkVNZPW0LBts+BWhioR6ILFKKE1do0y1nCZC81jp5fyNkM
	Qd9yZVa0KDu0+GDyZ//K1aubYB8OMF/3apc7UYT0eVWYzntSMOyE0Y0sjKyKmg8HdmpP
	tpblYzL3YuNvkmvcNOaz/vi6m+rTNcCpmoo10=
Received: by 10.68.73.105 with SMTP id k9mr10212266pbv.121.1328217143264;
	Thu, 02 Feb 2012 13:12:23 -0800 (PST)
Received: from [192.168.0.6] (c-71-198-0-100.hsd1.ca.comcast.net.
	[71.198.0.100])
	by mx.google.com with ESMTPS id i10sm8109011pbg.10.2012.02.02.13.12.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 02 Feb 2012 13:12:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Qrux <qrux.qed@gmail.com>
In-Reply-To: <mailman.2350.1328186375.1471.xen-devel@lists.xensource.com>
Date: Thu, 2 Feb 2012 13:12:19 -0800
Message-Id: <CE5198A7-8FA3-4F24-8AD1-582FF84EEAFF@gmail.com>
References: <mailman.2350.1328186375.1471.xen-devel@lists.xensource.com>
To: xen-devel@lists.xensource.com
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 38 - autoconf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 2, 2012, at 4:39 AM, xen-devel-request@lists.xensource.com wrote:

> Today's Topics:
> 
>   1. Re: [PATCH v4] build: add autoconf to replace custom checks
>      in tools/check (Ian Campbell)

Howdy all,

I'm new to the Xen-Devel list, but I've been using Xen for many years.  Xen is a great product, and the collective work you've done has been amazing.  I'm excited to see a digest post about moving toward autoconf.  Along those lines, I have some input for the build process.  There may be bits that are factually wrong; and I'd be happy to stand corrected; however, much of what follows are perceptions, which I think could be equally important to the long term success of Xen, especially with competitors like KVM.

(I sent this to Ian, and he felt it belonged on the list.)

* * *

I've been using Xen on openSUSE for a long time.  My use case for Xen:

	* Pure 64-bit dom0.
	* Pure 64-bit pure PV domUs.
	* No need for X11--CLI management is fine.
	* No need for VGA-passthrough (ssh is enough).
	* No need for any fancy device-handling or HVM support.

After two ugly hacks, (but a "working" hypervisor, dom0, and domU), my sense of the Xen build process is, basically, that it tries to build too much stuff.  For example, the Hypervisor is separated from the tools.  Good.  But, all the tools are bunched together, including xl, xm, firmware, PVHVM stuff.  Bad?  That seems like a horrid lack of separation.  And, my perception is that configuration is harder--or perhaps scarier--that it needs to be, with a top-level Config.mk containing variables (which are easy enough to toggle) but also tons of logic (which makes me not want to work in that file).

Long story short, what I thought was the most "baseline" case (64-bit dom0, 64-bit domUs, pure PV, no HVM or PVHVM, no X11, and just wanting the xl tools) turned out to be much uglier than it seems was necessary.  As you move toward autoconf, I would hope that there will be (somewhat comprehensible) switches like:

	--with-X11-tools
	--without-X11-tools
	--with-xm
	--without-xm
	--no-32-bit-support

I propose that the configure process tries to separate as much as possible; e.g., keep all the tools apart from each other, and separate out mandatory (e.g., xl) from not (X11 stuff) and "possibly necessary based on your use case" (e.g., tools/firmware for HVM guests).

I also propose that when Xen is to be built from source, the build system should aggressively prune non-critical items (i.e., not the hypervisor or xl/xm); i.e., those parts should not be included unless specified (e.g., tools/firmware).  Whatever is in the default build should allow a user to run SOME specific baseline dom0/domU configuration (I would think the PV default is the least dependent mode), but leave everything else to the builder.

Why do I think that?  Because of the adage:

	"Make it easy to do what's easy, and possible to do what's hard."

Integration is the value-add provided by commercial distros. They have the resources to put full-time staff onto issues, even if they're simply liaising with the Xen developers.  But, small-system-builders--many of which provided the critical mass for Xen to come up--can get bogged down in these complex dependencies.

Sure, branding is important from Xen's marketing perspective; it's nice to be able to release a fully-functional product that does everything it says "on the box".  But, again, I think that's something that the commercial groups are doing fine with.  They can release their implementation that supports every bell and whistle.  But, I would still submit that folks who compile Xen themselves would like a slightly less "hairy" experience, and could live without certain features.  They would also have commercial distros to fall back on, or let other non-commercial projects (NetBSD, Ubuntu, LFS) catch up, and inform them.  So, since that's already the case, shouldn't the default Xen build require as little as possible--but be aggressive in building a usable target, even if some features are missing?

TL;DR--

	* Define "baseline" functionality with a minimum set of dependencies.

	* Have autoconf fail if those deps aren't met.

	* If those deps *are* met (kernel settings, compiler, etc)...

	* ...be able to build a "baseline" that allows Xen to function.

	* Add other tools (with external dependencies) purely as opt-ins.

I think that would follow the principle of least-surprise, in a configuration sense.  Other large systems, like Apache or PHP or Postgres, seem to try to detect features, and incorporate them if found.  But, if those features don't exist, they don't hamper the parts that can be properly built.  I think those systems aggressively try to successfully build a target.  And, the default configuration is obviously a subset of all the available features, which are left to the builder's choice.  There *is* a sense of what a "baseline" build for those systems is like, even if it's a de-facto result of C;M;MI.  I believe that my system (LFS) is as bare a system as one can reasonably have (that's not embedded).  I'd be happy to help test the build.

Again, I respect all the hard and wonderful work that's been done.  Yet, I think these are important issues that may influence the future of Xen's success.  KVM is a gnarly competitor, and it seems to build with relative ease (granted, it's a Linux-host-only solution).  Sure, Xen is a Type-1 hypervisor, is mature, and has a lot of users.  But, its perceived complexity seems to be many many orders of magnitude higher that the perceived benefit.  That doesn't seem good for Xen's brand...

I hope this will spark some dialogue, and I'm happy to participate further either privately or on the lists.

	Q




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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 22:17:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 22:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt4xb-0006iw-03; Thu, 02 Feb 2012 22:16:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rt4xY-0006iT-QK
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 22:16:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328221006!12652451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21705 invoked from network); 2 Feb 2012 22:16:46 -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;
	2 Feb 2012 22:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,348,1325462400"; d="scan'208";a="10454315"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 22:16:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 22:16:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rt4xR-00024Z-Ba;
	Thu, 02 Feb 2012 22:16:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rt4xR-0002Zp-1a;
	Thu, 02 Feb 2012 22:16:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11828-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 22:16:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11828: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11828 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11828/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 22:17:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 22:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt4xb-0006iw-03; Thu, 02 Feb 2012 22:16:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rt4xY-0006iT-QK
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 22:16:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328221006!12652451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzA3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21705 invoked from network); 2 Feb 2012 22:16:46 -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;
	2 Feb 2012 22:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,348,1325462400"; d="scan'208";a="10454315"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2012 22:16:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 2 Feb 2012 22:16:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rt4xR-00024Z-Ba;
	Thu, 02 Feb 2012 22:16:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rt4xR-0002Zp-1a;
	Thu, 02 Feb 2012 22:16:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11828-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 2 Feb 2012 22:16:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11828: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11828 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11828/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 23:10:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 23:10:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt5n0-000894-LM; Thu, 02 Feb 2012 23:10:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rt5mz-00088v-6F
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 23:10:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328224153!58578196!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13097 invoked from network); 2 Feb 2012 23:09:14 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 23:09:14 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id B6EFE458083;
	Thu,  2 Feb 2012 15:09:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Pra7gdtgrmZWk2aJRY5PNWERGC4yPQl57HJ5Y2tfg1s7
	zSee2OfExEWkBUnqmCDLeL4cRM+wF5JrBeJtVpO1fyooi+VHk1HFKiHlLN2rX8yd
	xX5meFZ1mlB/tNv8hFyYqThwfuTsaPqWMNd1rH6LMBGMKI7QbcNaYuIdHWtddvU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=JiZzdAB4gMgNMYUQRqduqWe8K7A=; b=a72yxYhW
	oDfetVK7U07zkXUKdO5fa1XE2w4rtRJpRJANIiL/KyTefSj05VvwOMPPhRxOiG82
	+bSkWwdvC4JEmedGDoWr5m4nEUJbl2vP42PTascgjDA50T8dCJlIcXFF/htHUnBd
	MOcVEvg7Ablk++3oh8rnnf9fUmuwa70uuKo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 308AE458085; 
	Thu,  2 Feb 2012 15:09:55 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 15:09:55 -0800
Message-ID: <d39dc69631e498c64e1e36fcc246ccb6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328214343.13189.4.camel@dagon.hellion.org.uk>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
	<69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
	<1328214343.13189.4.camel@dagon.hellion.org.uk>
Date: Thu, 2 Feb 2012 15:09:55 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-02-02 at 20:23 +0000, Andres Lagar-Cavilla wrote:
>> > On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
>> >> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
>> >> >>
>> >> >>
>> >> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> >> >> +                        unsigned int op, unsigned int mode,
>> >> >> +                        uint64_t gfn, void *buffer)
>> >> >> +{
>> >> >> +    xen_mem_event_op_t meo;
>> >> >> +
>> >> >> +    memset(&meo, 0, sizeof(meo));
>> >> >> +
>> >> >> +    meo.op      = op;
>> >> >> +    meo.domain  = domain_id;
>> >> >> +    meo.gfn     = gfn;
>> >> >> +    meo.buffer  = (unsigned long) buffer;
>> >> >
>> >> > Hypercall arguments need to use the xc_hypercall_buffer stuff in
>> order
>> >> > to ensure that the memory is safe to access from a hypercall (in
>> >> > particular that it is mlocked or similar)-- I don't see where that
>> >> > happens for this buffer.
>> >> >
>> >> > meo itself is bounced by do_memory_op so that is OK.
>> >> >
>> >> > I was also a little suspicious of ring_addr and shared_addr in
>> >> > xc_mem_event_control in this regard.
>> >> >
>> >> > Or does the mem sharing code make it's own arrangements for these
>> >> sorts
>> >> > of things somewhere?
>> >>
>> >> It's rather unclean. They do not get mlock'ed (and there is no sanity
>> >> check to ensure they're page-aligned). They should follow the pattern
>> >> established in xc_mem_paging_load. I'll get on it, probably a
>> separate
>> >> patch.
>> >
>> > If you are reworking this It Would Be Nice If (tm) you could make it
>> use
>> > xc_hypercall_buffer_alloc and friends to allocate and manage the
>> buffer
>> > while you are there e.g. the void *buffer above would become struct
>> > xc_hypercall_buffer *buffer -- see xc_perfc_query for example.
>>
>> Took me a while to grok those hypercall buffer macros. Conclusion: that
>> would need to change callers of paging_load (xenpaging in tree).
>
> Yes, in this case you probably want to bubble their use right up to the
> top level rather than bouncing in the internals like we do for smaller
> and.or more transient data.
>
>> Can we keep this separate? domctl interface also suffers from all these
>> problems. domctl->memops switch is orthogonal to the buffer badness. I
>> want to tackle one problem at a time.
>
> Sure, read "IWBNI" as "in the fullness of time" ;-)

Ok, trying to mb() what's needed now and what will take place in the
fullness of time:
- ring creation when initializing mem event is ugly, but cannot be fixed
short of a kernel driver. I will however produce a patch now that at least
mlock's these guys.
- All libxc consumers of these interfaces should be updated to init these
magic pages (and the paging load buffer) using xc_hypercall_buffer_alloc
in their own code.

Cheers,
Andres
>
> Ian.
>
>
>



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

From xen-devel-bounces@lists.xensource.com Thu Feb 02 23:10:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 02 Feb 2012 23:10:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt5n0-000894-LM; Thu, 02 Feb 2012 23:10:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rt5mz-00088v-6F
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 23:10:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328224153!58578196!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13097 invoked from network); 2 Feb 2012 23:09:14 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 23:09:14 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id B6EFE458083;
	Thu,  2 Feb 2012 15:09:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Pra7gdtgrmZWk2aJRY5PNWERGC4yPQl57HJ5Y2tfg1s7
	zSee2OfExEWkBUnqmCDLeL4cRM+wF5JrBeJtVpO1fyooi+VHk1HFKiHlLN2rX8yd
	xX5meFZ1mlB/tNv8hFyYqThwfuTsaPqWMNd1rH6LMBGMKI7QbcNaYuIdHWtddvU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=JiZzdAB4gMgNMYUQRqduqWe8K7A=; b=a72yxYhW
	oDfetVK7U07zkXUKdO5fa1XE2w4rtRJpRJANIiL/KyTefSj05VvwOMPPhRxOiG82
	+bSkWwdvC4JEmedGDoWr5m4nEUJbl2vP42PTascgjDA50T8dCJlIcXFF/htHUnBd
	MOcVEvg7Ablk++3oh8rnnf9fUmuwa70uuKo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 308AE458085; 
	Thu,  2 Feb 2012 15:09:55 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 2 Feb 2012 15:09:55 -0800
Message-ID: <d39dc69631e498c64e1e36fcc246ccb6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328214343.13189.4.camel@dagon.hellion.org.uk>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
	<69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
	<1328214343.13189.4.camel@dagon.hellion.org.uk>
Date: Thu, 2 Feb 2012 15:09:55 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-02-02 at 20:23 +0000, Andres Lagar-Cavilla wrote:
>> > On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
>> >> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
>> >> >>
>> >> >>
>> >> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> >> >> +                        unsigned int op, unsigned int mode,
>> >> >> +                        uint64_t gfn, void *buffer)
>> >> >> +{
>> >> >> +    xen_mem_event_op_t meo;
>> >> >> +
>> >> >> +    memset(&meo, 0, sizeof(meo));
>> >> >> +
>> >> >> +    meo.op      = op;
>> >> >> +    meo.domain  = domain_id;
>> >> >> +    meo.gfn     = gfn;
>> >> >> +    meo.buffer  = (unsigned long) buffer;
>> >> >
>> >> > Hypercall arguments need to use the xc_hypercall_buffer stuff in
>> order
>> >> > to ensure that the memory is safe to access from a hypercall (in
>> >> > particular that it is mlocked or similar)-- I don't see where that
>> >> > happens for this buffer.
>> >> >
>> >> > meo itself is bounced by do_memory_op so that is OK.
>> >> >
>> >> > I was also a little suspicious of ring_addr and shared_addr in
>> >> > xc_mem_event_control in this regard.
>> >> >
>> >> > Or does the mem sharing code make it's own arrangements for these
>> >> sorts
>> >> > of things somewhere?
>> >>
>> >> It's rather unclean. They do not get mlock'ed (and there is no sanity
>> >> check to ensure they're page-aligned). They should follow the pattern
>> >> established in xc_mem_paging_load. I'll get on it, probably a
>> separate
>> >> patch.
>> >
>> > If you are reworking this It Would Be Nice If (tm) you could make it
>> use
>> > xc_hypercall_buffer_alloc and friends to allocate and manage the
>> buffer
>> > while you are there e.g. the void *buffer above would become struct
>> > xc_hypercall_buffer *buffer -- see xc_perfc_query for example.
>>
>> Took me a while to grok those hypercall buffer macros. Conclusion: that
>> would need to change callers of paging_load (xenpaging in tree).
>
> Yes, in this case you probably want to bubble their use right up to the
> top level rather than bouncing in the internals like we do for smaller
> and.or more transient data.
>
>> Can we keep this separate? domctl interface also suffers from all these
>> problems. domctl->memops switch is orthogonal to the buffer badness. I
>> want to tackle one problem at a time.
>
> Sure, read "IWBNI" as "in the fullness of time" ;-)

Ok, trying to mb() what's needed now and what will take place in the
fullness of time:
- ring creation when initializing mem event is ugly, but cannot be fixed
short of a kernel driver. I will however produce a patch now that at least
mlock's these guys.
- All libxc consumers of these interfaces should be updated to init these
magic pages (and the paging load buffer) using xc_hypercall_buffer_alloc
in their own code.

Cheers,
Andres
>
> Ian.
>
>
>



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 00:25:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 00: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.xensource.com>)
	id 1Rt6x2-00027S-GG; Fri, 03 Feb 2012 00:24:28 +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 1Rt6x1-00027N-4P
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 00:24:27 +0000
Received: from [85.158.138.51:21494] by server-2.bemta-3.messagelabs.com id
	27/6F-15021-A392B2F4; Fri, 03 Feb 2012 00:24:26 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328228663!11808398!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyODExOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 3 Feb 2012 00:24:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 00:24:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q130OL33023917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 00:24: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
	q130OKcm020881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 00:24: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
	q130OKvE020580
	for <xen-devel@lists.xensource.com>; Thu, 2 Feb 2012 18:24:20 -0600
MIME-Version: 1.0
Message-ID: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
Date: Thu, 2 Feb 2012 16:24:22 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xensource.com
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F2B2936.007A,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm building xen-devel from scratch for the first time in a long
time on a clean EL6u1 machine and running into a couple of problems.

1) The build of tools/firmware/etherboot does a wget of a weird
   pxe tar file that looks like it has a git hash in the filename.
   I hacked around that (to wget the 1.0.0 version of the file).
2) Building blktap2 complains about a missing "uuid/uuid.h".  I
   did install the uuid and uuid-devel packages and there IS
   a /usr/include/uuid.h but no /usr/include/uuid/uuid.h.  I found
   I also needed to install libuuid-devel (which didn't get
   checked in advance apparently, just uuid-devel and uuid I think).
3) Missing texinfo package stops the build before it successfully
   completes.  Can this be check'ed in advance?

Since I haven't built xen-devel in a long time, I don't know if
these are recent problems with tip or old problems that don't
show up on [Debian and whatever other envs other developers are
using] but do show up on EL6.  So I thought I'd report them.




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 00:25:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 00: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.xensource.com>)
	id 1Rt6x2-00027S-GG; Fri, 03 Feb 2012 00:24:28 +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 1Rt6x1-00027N-4P
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 00:24:27 +0000
Received: from [85.158.138.51:21494] by server-2.bemta-3.messagelabs.com id
	27/6F-15021-A392B2F4; Fri, 03 Feb 2012 00:24:26 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328228663!11808398!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyODExOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 3 Feb 2012 00:24:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 00:24:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q130OL33023917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 00:24: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
	q130OKcm020881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 00:24: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
	q130OKvE020580
	for <xen-devel@lists.xensource.com>; Thu, 2 Feb 2012 18:24:20 -0600
MIME-Version: 1.0
Message-ID: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
Date: Thu, 2 Feb 2012 16:24:22 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xensource.com
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F2B2936.007A,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm building xen-devel from scratch for the first time in a long
time on a clean EL6u1 machine and running into a couple of problems.

1) The build of tools/firmware/etherboot does a wget of a weird
   pxe tar file that looks like it has a git hash in the filename.
   I hacked around that (to wget the 1.0.0 version of the file).
2) Building blktap2 complains about a missing "uuid/uuid.h".  I
   did install the uuid and uuid-devel packages and there IS
   a /usr/include/uuid.h but no /usr/include/uuid/uuid.h.  I found
   I also needed to install libuuid-devel (which didn't get
   checked in advance apparently, just uuid-devel and uuid I think).
3) Missing texinfo package stops the build before it successfully
   completes.  Can this be check'ed in advance?

Since I haven't built xen-devel in a long time, I don't know if
these are recent problems with tip or old problems that don't
show up on [Debian and whatever other envs other developers are
using] but do show up on EL6.  So I thought I'd report them.




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 01:32:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 01:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt80M-0007Lq-1g; Fri, 03 Feb 2012 01:31:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jordi.Jacobs@howest.be>) id 1Rt80K-0007Ll-NI
	for Xen-devel@lists.xensource.com; Fri, 03 Feb 2012 01:31:56 +0000
Received: from [85.158.138.51:39280] by server-2.bemta-3.messagelabs.com id
	DD/50-15021-B093B2F4; Fri, 03 Feb 2012 01:31:55 +0000
X-Env-Sender: Jordi.Jacobs@howest.be
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328232714!11771562!1
X-Originating-IP: [193.191.136.242]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 3 Feb 2012 01:31:54 -0000
Received: from smtp1.howest.be (HELO EDGE1.howest.be) (193.191.136.242)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 01:31:54 -0000
Received: from MAIL1.hogeschool-wvl.be (172.20.1.43) by EDGE1.howest.be
	(192.168.2.23) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Fri, 3 Feb 2012 02:31:09 +0100
Received: from MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43]) by
	MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43%12]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 02:31:28 +0100
From: Jacobs Jordi <Jordi.Jacobs@howest.be>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Thread-Topic: 1 GPU multiple VMs
Thread-Index: AcziEI9YhPf/uaMKQPWlLvKH91C0fw==
Date: Fri, 3 Feb 2012 01:31:27 +0000
Message-ID: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
Accept-Language: en-US, nl-BE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.2.236]
MIME-Version: 1.0
Subject: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3384327807758012938=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3384327807758012938==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_"

--_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am wondering how GPU sharing could/should be implemented for the Xen Hype=
rvisor.

I have come across several papers that explain many possibilities on GPU sh=
aring for multiple VMs but I'm not sure wich one would be the best solution=
 for Xen.

API remoting (gallium3D) (ex. Xen3D project)
Mediated passthrough (Multiplexing the GPU while maintaining the different =
contexts.)

Can you guys give me your idea on the matter?
Please also mention any existing projects you know that are related to this=
 problem.

Thanks in advance,

Jordi

--_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style id=3D"owaParaStyle" type=3D"text/css">=0A=
<!--=0A=
p=0A=
	{margin-top:0;=0A=
	margin-bottom:0}=0A=
-->=0A=
P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi=3D"0" fpstyle=3D"1">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">
<div style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); fon=
t-size: 10pt;">
Hi,<br>
<br>
I am wondering how GPU sharing could/should be implemented for the Xen Hype=
rvisor.<br>
<br>
I have come across several papers that explain many possibilities on GPU sh=
aring for multiple VMs but I'm not sure wich one would be the best solution=
 for Xen.<br>
<br>
API remoting (gallium3D) (ex. Xen3D project)<br>
Mediated passthrough (Multiplexing the GPU while maintaining the different =
contexts.)<br>
<br>
Can you guys give me your idea on the matter?<br>
Please also mention any existing projects you know that are related to this=
 problem.<br>
<br>
Thanks in advance,<br>
<br>
Jordi<br>
</div>
</div>
</body>
</html>

--_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_--


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

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

--===============3384327807758012938==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 01:32:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 01:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rt80M-0007Lq-1g; Fri, 03 Feb 2012 01:31:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jordi.Jacobs@howest.be>) id 1Rt80K-0007Ll-NI
	for Xen-devel@lists.xensource.com; Fri, 03 Feb 2012 01:31:56 +0000
Received: from [85.158.138.51:39280] by server-2.bemta-3.messagelabs.com id
	DD/50-15021-B093B2F4; Fri, 03 Feb 2012 01:31:55 +0000
X-Env-Sender: Jordi.Jacobs@howest.be
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328232714!11771562!1
X-Originating-IP: [193.191.136.242]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 3 Feb 2012 01:31:54 -0000
Received: from smtp1.howest.be (HELO EDGE1.howest.be) (193.191.136.242)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 01:31:54 -0000
Received: from MAIL1.hogeschool-wvl.be (172.20.1.43) by EDGE1.howest.be
	(192.168.2.23) with Microsoft SMTP Server (TLS) id 14.1.355.2;
	Fri, 3 Feb 2012 02:31:09 +0100
Received: from MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43]) by
	MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43%12]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 02:31:28 +0100
From: Jacobs Jordi <Jordi.Jacobs@howest.be>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Thread-Topic: 1 GPU multiple VMs
Thread-Index: AcziEI9YhPf/uaMKQPWlLvKH91C0fw==
Date: Fri, 3 Feb 2012 01:31:27 +0000
Message-ID: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
Accept-Language: en-US, nl-BE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.2.236]
MIME-Version: 1.0
Subject: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3384327807758012938=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3384327807758012938==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_"

--_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am wondering how GPU sharing could/should be implemented for the Xen Hype=
rvisor.

I have come across several papers that explain many possibilities on GPU sh=
aring for multiple VMs but I'm not sure wich one would be the best solution=
 for Xen.

API remoting (gallium3D) (ex. Xen3D project)
Mediated passthrough (Multiplexing the GPU while maintaining the different =
contexts.)

Can you guys give me your idea on the matter?
Please also mention any existing projects you know that are related to this=
 problem.

Thanks in advance,

Jordi

--_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style id=3D"owaParaStyle" type=3D"text/css">=0A=
<!--=0A=
p=0A=
	{margin-top:0;=0A=
	margin-bottom:0}=0A=
-->=0A=
P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi=3D"0" fpstyle=3D"1">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">
<div style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); fon=
t-size: 10pt;">
Hi,<br>
<br>
I am wondering how GPU sharing could/should be implemented for the Xen Hype=
rvisor.<br>
<br>
I have come across several papers that explain many possibilities on GPU sh=
aring for multiple VMs but I'm not sure wich one would be the best solution=
 for Xen.<br>
<br>
API remoting (gallium3D) (ex. Xen3D project)<br>
Mediated passthrough (Multiplexing the GPU while maintaining the different =
contexts.)<br>
<br>
Can you guys give me your idea on the matter?<br>
Please also mention any existing projects you know that are related to this=
 problem.<br>
<br>
Thanks in advance,<br>
<br>
Jordi<br>
</div>
</div>
</body>
</html>

--_000_8D0A507D03F2B0499D85192120C2158F11386D23MAIL1hogeschool_--


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

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

--===============3384327807758012938==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 02:37:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 02: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.xensource.com>)
	id 1Rt91T-0000gO-Go; Fri, 03 Feb 2012 02:37:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rt91S-0000gJ-0T
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 02:37:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328236621!9747091!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyODExOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29619 invoked from network); 3 Feb 2012 02:37:03 -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; 3 Feb 2012 02:37:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q132ax4Q014386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 02:36: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
	q132awZ9003343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 02:36:59 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
	q132awdF020122; Thu, 2 Feb 2012 20:36:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 02 Feb 2012 18:36:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A142B4047A; Thu,  2 Feb 2012 21:34:20 -0500 (EST)
Date: Thu, 2 Feb 2012 21:34:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120203023420.GA25511@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-10-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328201363-13915-10-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F2B484C.001A,ss=1,re=-2.300,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 09/13] Bundle fix for xen backends
	and frontends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 04:49:19PM +0000, Wei Liu wrote:
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/block/xen-blkback/xenbus.c    |    8 +++++---
>  drivers/block/xen-blkfront.c          |    5 +++--
>  drivers/net/xen-netback/netback.c     |    4 ++--
>  drivers/net/xen-netfront.c            |    9 +++++----
>  drivers/pci/xen-pcifront.c            |    5 +++--
>  drivers/scsi/xen-scsiback/common.h    |    3 ++-
>  drivers/scsi/xen-scsiback/interface.c |    6 ++++--
>  drivers/scsi/xen-scsiback/xenbus.c    |    4 ++--
>  drivers/scsi/xen-scsifront/xenbus.c   |    5 +++--

Heheh. If you could seperate the scsi[back|front] from this
patchset that would be great. The reason is that SCSI front/back
aren't yet ready for upstream.

>  drivers/xen/xen-pciback/xenbus.c      |   11 ++++++-----
>  10 files changed, 35 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 9e9c8a1..ef7e88b 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -122,7 +122,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	return blkif;
>  }
>  
> -static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
> +static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page[],
> +			 int nr_pages,
>  			 unsigned int evtchn)
>  {
>  	int err;
> @@ -131,7 +132,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
>  	if (blkif->irq)
>  		return 0;
>  
> -	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring);
> +	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page,
> +				     nr_pages, &blkif->blk_ring);
>  	if (err < 0)
>  		return err;
>  
> @@ -779,7 +781,7 @@ static int connect_ring(struct backend_info *be)
>  		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
>  
>  	/* Map the shared frame, irq etc. */
> -	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> +	err = xen_blkif_map(be->blkif, &ring_ref, 1, evtchn);
>  	if (err) {
>  		xenbus_dev_fatal(dev, err, "mapping ring-ref %lu port %u",
>  				 ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..2c6443a 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -827,6 +827,7 @@ static int setup_blkring(struct xenbus_device *dev,
>  {
>  	struct blkif_sring *sring;
>  	int err;
> +	int grefs[1];
>  
>  	info->ring_ref = GRANT_INVALID_REF;
>  
> @@ -840,13 +841,13 @@ static int setup_blkring(struct xenbus_device *dev,
>  
>  	sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(info->ring.sring));
> +	err = xenbus_grant_ring(dev, info->ring.sring, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long)sring);
>  		info->ring.sring = NULL;
>  		goto fail;
>  	}
> -	info->ring_ref = err;
> +	info->ring_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 384f4e5..cb1a661 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1440,7 +1440,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
>  	int err = -ENOMEM;
>  
>  	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     tx_ring_ref, &addr);
> +				     &tx_ring_ref, 1, &addr);
>  	if (err)
>  		goto err;
>  
> @@ -1448,7 +1448,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
>  	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
>  
>  	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     rx_ring_ref, &addr);
> +				     &rx_ring_ref, 1, &addr);
>  	if (err)
>  		goto err;
>  
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 01f589d..b7ff815 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1482,6 +1482,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	struct xen_netif_tx_sring *txs;
>  	struct xen_netif_rx_sring *rxs;
>  	int err;
> +	int grefs[1];
>  	struct net_device *netdev = info->netdev;
>  
>  	info->tx_ring_ref = GRANT_INVALID_REF;
> @@ -1505,13 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	SHARED_RING_INIT(txs);
>  	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
> +	err = xenbus_grant_ring(dev, txs, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long)txs);
>  		goto fail;
>  	}
>  
> -	info->tx_ring_ref = err;
> +	info->tx_ring_ref = grefs[0];
>  	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
>  	if (!rxs) {
>  		err = -ENOMEM;
> @@ -1521,12 +1522,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	SHARED_RING_INIT(rxs);
>  	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
> +	err = xenbus_grant_ring(dev, rxs, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long)rxs);
>  		goto fail;
>  	}
> -	info->rx_ring_ref = err;
> +	info->rx_ring_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 7cf3d2f..394c926 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -767,12 +767,13 @@ static int pcifront_publish_info(struct pcifront_device *pdev)
>  {
>  	int err = 0;
>  	struct xenbus_transaction trans;
> +	int grefs[1];
>  
> -	err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
> +	err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, grefs);
>  	if (err < 0)
>  		goto out;
>  
> -	pdev->gnt_ref = err;
> +	pdev->gnt_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
>  	if (err)
> diff --git a/drivers/scsi/xen-scsiback/common.h b/drivers/scsi/xen-scsiback/common.h
> index dafa79e..4d13617 100644
> --- a/drivers/scsi/xen-scsiback/common.h
> +++ b/drivers/scsi/xen-scsiback/common.h
> @@ -150,7 +150,8 @@ typedef struct {
>  
>  irqreturn_t scsiback_intr(int, void *);
>  int scsiback_init_sring(struct vscsibk_info *info,
> -		unsigned long ring_ref, unsigned int evtchn);
> +			int ring_ref[], int nr_refs,
> +			unsigned int evtchn);
>  int scsiback_schedule(void *data);
>  
>  
> diff --git a/drivers/scsi/xen-scsiback/interface.c b/drivers/scsi/xen-scsiback/interface.c
> index 663568e..fad0a63 100644
> --- a/drivers/scsi/xen-scsiback/interface.c
> +++ b/drivers/scsi/xen-scsiback/interface.c
> @@ -60,7 +60,8 @@ struct vscsibk_info *vscsibk_info_alloc(domid_t domid)
>  }
>  
>  int scsiback_init_sring(struct vscsibk_info *info,
> -		unsigned long ring_ref, unsigned int evtchn)
> +			int ring_ref[], int nr_refs,
> +			unsigned int evtchn)
>  {
>  	struct vscsiif_sring *sring;
>  	int err;
> @@ -73,7 +74,8 @@ int scsiback_init_sring(struct vscsibk_info *info,
>  		return -1;
>  	}
>  
> -	err = xenbus_map_ring_valloc(info->dev, ring_ref, &info->ring_area);
> +	err = xenbus_map_ring_valloc(info->dev, ring_ref, nr_refs,
> +				     &info->ring_area);
>  	if (err < 0)
>  		return -ENOMEM;
>  
> diff --git a/drivers/scsi/xen-scsiback/xenbus.c b/drivers/scsi/xen-scsiback/xenbus.c
> index 2869f89..81d5598 100644
> --- a/drivers/scsi/xen-scsiback/xenbus.c
> +++ b/drivers/scsi/xen-scsiback/xenbus.c
> @@ -60,7 +60,7 @@ static int __vscsiif_name(struct backend_info *be, char *buf)
>  static int scsiback_map(struct backend_info *be)
>  {
>  	struct xenbus_device *dev = be->dev;
> -	unsigned long ring_ref = 0;
> +	int ring_ref = 0;
>  	unsigned int evtchn = 0;
>  	int err;
>  	char name[TASK_COMM_LEN];
> @@ -72,7 +72,7 @@ static int scsiback_map(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "reading %s ring", dev->otherend);
>  		return err;
>  	}
> -	err = scsiback_init_sring(be->info, ring_ref, evtchn);
> +	err = scsiback_init_sring(be->info, &ring_ref, 1, evtchn);
>  	if (err)
>  		return err;
>  
> diff --git a/drivers/scsi/xen-scsifront/xenbus.c b/drivers/scsi/xen-scsifront/xenbus.c
> index bc5c289..8726410 100644
> --- a/drivers/scsi/xen-scsifront/xenbus.c
> +++ b/drivers/scsi/xen-scsifront/xenbus.c
> @@ -60,6 +60,7 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
>  	struct xenbus_device *dev = info->dev;
>  	struct vscsiif_sring *sring;
>  	int err = -ENOMEM;
> +	int grefs[1];
>  
>  
>  	info->ring_ref = GRANT_INVALID_REF;
> @@ -73,14 +74,14 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
>  	SHARED_RING_INIT(sring);
>  	FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(sring));
> +	err = xenbus_grant_ring(dev, sring, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long) sring);
>  		info->ring.sring = NULL;
>  		xenbus_dev_fatal(dev, err, "fail to grant shared ring (Front to Back)");
>  		goto free_sring;
>  	}
> -	info->ring_ref = err;
> +	info->ring_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 5a42ae7..0d8a98c 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -98,17 +98,18 @@ static void free_pdev(struct xen_pcibk_device *pdev)
>  	kfree(pdev);
>  }
>  
> -static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref,
> -			     int remote_evtchn)
> +static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref[],
> +			       int nr_grefs,
> +			       int remote_evtchn)
>  {
>  	int err = 0;
>  	void *vaddr;
>  
>  	dev_dbg(&pdev->xdev->dev,
>  		"Attaching to frontend resources - gnt_ref=%d evtchn=%d\n",
> -		gnt_ref, remote_evtchn);
> +		gnt_ref[0], remote_evtchn);
>  
> -	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr);
> +	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, nr_grefs, &vaddr);
>  	if (err < 0) {
>  		xenbus_dev_fatal(pdev->xdev, err,
>  				"Error mapping other domain page in ours.");
> @@ -172,7 +173,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
>  		goto out;
>  	}
>  
> -	err = xen_pcibk_do_attach(pdev, gnt_ref, remote_evtchn);
> +	err = xen_pcibk_do_attach(pdev, &gnt_ref, 1, remote_evtchn);
>  	if (err)
>  		goto out;
>  
> -- 
> 1.7.2.5

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 02:37:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 02: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.xensource.com>)
	id 1Rt91T-0000gO-Go; Fri, 03 Feb 2012 02:37:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rt91S-0000gJ-0T
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 02:37:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328236621!9747091!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyODExOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29619 invoked from network); 3 Feb 2012 02:37:03 -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; 3 Feb 2012 02:37:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q132ax4Q014386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 02:36: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
	q132awZ9003343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 02:36:59 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
	q132awdF020122; Thu, 2 Feb 2012 20:36:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 02 Feb 2012 18:36:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A142B4047A; Thu,  2 Feb 2012 21:34:20 -0500 (EST)
Date: Thu, 2 Feb 2012 21:34:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120203023420.GA25511@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-10-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328201363-13915-10-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F2B484C.001A,ss=1,re=-2.300,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 09/13] Bundle fix for xen backends
	and frontends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 04:49:19PM +0000, Wei Liu wrote:
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/block/xen-blkback/xenbus.c    |    8 +++++---
>  drivers/block/xen-blkfront.c          |    5 +++--
>  drivers/net/xen-netback/netback.c     |    4 ++--
>  drivers/net/xen-netfront.c            |    9 +++++----
>  drivers/pci/xen-pcifront.c            |    5 +++--
>  drivers/scsi/xen-scsiback/common.h    |    3 ++-
>  drivers/scsi/xen-scsiback/interface.c |    6 ++++--
>  drivers/scsi/xen-scsiback/xenbus.c    |    4 ++--
>  drivers/scsi/xen-scsifront/xenbus.c   |    5 +++--

Heheh. If you could seperate the scsi[back|front] from this
patchset that would be great. The reason is that SCSI front/back
aren't yet ready for upstream.

>  drivers/xen/xen-pciback/xenbus.c      |   11 ++++++-----
>  10 files changed, 35 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 9e9c8a1..ef7e88b 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -122,7 +122,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	return blkif;
>  }
>  
> -static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
> +static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page[],
> +			 int nr_pages,
>  			 unsigned int evtchn)
>  {
>  	int err;
> @@ -131,7 +132,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
>  	if (blkif->irq)
>  		return 0;
>  
> -	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring);
> +	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page,
> +				     nr_pages, &blkif->blk_ring);
>  	if (err < 0)
>  		return err;
>  
> @@ -779,7 +781,7 @@ static int connect_ring(struct backend_info *be)
>  		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
>  
>  	/* Map the shared frame, irq etc. */
> -	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> +	err = xen_blkif_map(be->blkif, &ring_ref, 1, evtchn);
>  	if (err) {
>  		xenbus_dev_fatal(dev, err, "mapping ring-ref %lu port %u",
>  				 ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..2c6443a 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -827,6 +827,7 @@ static int setup_blkring(struct xenbus_device *dev,
>  {
>  	struct blkif_sring *sring;
>  	int err;
> +	int grefs[1];
>  
>  	info->ring_ref = GRANT_INVALID_REF;
>  
> @@ -840,13 +841,13 @@ static int setup_blkring(struct xenbus_device *dev,
>  
>  	sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(info->ring.sring));
> +	err = xenbus_grant_ring(dev, info->ring.sring, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long)sring);
>  		info->ring.sring = NULL;
>  		goto fail;
>  	}
> -	info->ring_ref = err;
> +	info->ring_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 384f4e5..cb1a661 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1440,7 +1440,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
>  	int err = -ENOMEM;
>  
>  	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     tx_ring_ref, &addr);
> +				     &tx_ring_ref, 1, &addr);
>  	if (err)
>  		goto err;
>  
> @@ -1448,7 +1448,7 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
>  	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
>  
>  	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     rx_ring_ref, &addr);
> +				     &rx_ring_ref, 1, &addr);
>  	if (err)
>  		goto err;
>  
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 01f589d..b7ff815 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1482,6 +1482,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	struct xen_netif_tx_sring *txs;
>  	struct xen_netif_rx_sring *rxs;
>  	int err;
> +	int grefs[1];
>  	struct net_device *netdev = info->netdev;
>  
>  	info->tx_ring_ref = GRANT_INVALID_REF;
> @@ -1505,13 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	SHARED_RING_INIT(txs);
>  	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
> +	err = xenbus_grant_ring(dev, txs, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long)txs);
>  		goto fail;
>  	}
>  
> -	info->tx_ring_ref = err;
> +	info->tx_ring_ref = grefs[0];
>  	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
>  	if (!rxs) {
>  		err = -ENOMEM;
> @@ -1521,12 +1522,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	SHARED_RING_INIT(rxs);
>  	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
> +	err = xenbus_grant_ring(dev, rxs, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long)rxs);
>  		goto fail;
>  	}
> -	info->rx_ring_ref = err;
> +	info->rx_ring_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 7cf3d2f..394c926 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -767,12 +767,13 @@ static int pcifront_publish_info(struct pcifront_device *pdev)
>  {
>  	int err = 0;
>  	struct xenbus_transaction trans;
> +	int grefs[1];
>  
> -	err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
> +	err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, grefs);
>  	if (err < 0)
>  		goto out;
>  
> -	pdev->gnt_ref = err;
> +	pdev->gnt_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
>  	if (err)
> diff --git a/drivers/scsi/xen-scsiback/common.h b/drivers/scsi/xen-scsiback/common.h
> index dafa79e..4d13617 100644
> --- a/drivers/scsi/xen-scsiback/common.h
> +++ b/drivers/scsi/xen-scsiback/common.h
> @@ -150,7 +150,8 @@ typedef struct {
>  
>  irqreturn_t scsiback_intr(int, void *);
>  int scsiback_init_sring(struct vscsibk_info *info,
> -		unsigned long ring_ref, unsigned int evtchn);
> +			int ring_ref[], int nr_refs,
> +			unsigned int evtchn);
>  int scsiback_schedule(void *data);
>  
>  
> diff --git a/drivers/scsi/xen-scsiback/interface.c b/drivers/scsi/xen-scsiback/interface.c
> index 663568e..fad0a63 100644
> --- a/drivers/scsi/xen-scsiback/interface.c
> +++ b/drivers/scsi/xen-scsiback/interface.c
> @@ -60,7 +60,8 @@ struct vscsibk_info *vscsibk_info_alloc(domid_t domid)
>  }
>  
>  int scsiback_init_sring(struct vscsibk_info *info,
> -		unsigned long ring_ref, unsigned int evtchn)
> +			int ring_ref[], int nr_refs,
> +			unsigned int evtchn)
>  {
>  	struct vscsiif_sring *sring;
>  	int err;
> @@ -73,7 +74,8 @@ int scsiback_init_sring(struct vscsibk_info *info,
>  		return -1;
>  	}
>  
> -	err = xenbus_map_ring_valloc(info->dev, ring_ref, &info->ring_area);
> +	err = xenbus_map_ring_valloc(info->dev, ring_ref, nr_refs,
> +				     &info->ring_area);
>  	if (err < 0)
>  		return -ENOMEM;
>  
> diff --git a/drivers/scsi/xen-scsiback/xenbus.c b/drivers/scsi/xen-scsiback/xenbus.c
> index 2869f89..81d5598 100644
> --- a/drivers/scsi/xen-scsiback/xenbus.c
> +++ b/drivers/scsi/xen-scsiback/xenbus.c
> @@ -60,7 +60,7 @@ static int __vscsiif_name(struct backend_info *be, char *buf)
>  static int scsiback_map(struct backend_info *be)
>  {
>  	struct xenbus_device *dev = be->dev;
> -	unsigned long ring_ref = 0;
> +	int ring_ref = 0;
>  	unsigned int evtchn = 0;
>  	int err;
>  	char name[TASK_COMM_LEN];
> @@ -72,7 +72,7 @@ static int scsiback_map(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "reading %s ring", dev->otherend);
>  		return err;
>  	}
> -	err = scsiback_init_sring(be->info, ring_ref, evtchn);
> +	err = scsiback_init_sring(be->info, &ring_ref, 1, evtchn);
>  	if (err)
>  		return err;
>  
> diff --git a/drivers/scsi/xen-scsifront/xenbus.c b/drivers/scsi/xen-scsifront/xenbus.c
> index bc5c289..8726410 100644
> --- a/drivers/scsi/xen-scsifront/xenbus.c
> +++ b/drivers/scsi/xen-scsifront/xenbus.c
> @@ -60,6 +60,7 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
>  	struct xenbus_device *dev = info->dev;
>  	struct vscsiif_sring *sring;
>  	int err = -ENOMEM;
> +	int grefs[1];
>  
>  
>  	info->ring_ref = GRANT_INVALID_REF;
> @@ -73,14 +74,14 @@ static int scsifront_alloc_ring(struct vscsifrnt_info *info)
>  	SHARED_RING_INIT(sring);
>  	FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(sring));
> +	err = xenbus_grant_ring(dev, sring, 1, grefs);
>  	if (err < 0) {
>  		free_page((unsigned long) sring);
>  		info->ring.sring = NULL;
>  		xenbus_dev_fatal(dev, err, "fail to grant shared ring (Front to Back)");
>  		goto free_sring;
>  	}
> -	info->ring_ref = err;
> +	info->ring_ref = grefs[0];
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 5a42ae7..0d8a98c 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -98,17 +98,18 @@ static void free_pdev(struct xen_pcibk_device *pdev)
>  	kfree(pdev);
>  }
>  
> -static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref,
> -			     int remote_evtchn)
> +static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref[],
> +			       int nr_grefs,
> +			       int remote_evtchn)
>  {
>  	int err = 0;
>  	void *vaddr;
>  
>  	dev_dbg(&pdev->xdev->dev,
>  		"Attaching to frontend resources - gnt_ref=%d evtchn=%d\n",
> -		gnt_ref, remote_evtchn);
> +		gnt_ref[0], remote_evtchn);
>  
> -	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr);
> +	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, nr_grefs, &vaddr);
>  	if (err < 0) {
>  		xenbus_dev_fatal(pdev->xdev, err,
>  				"Error mapping other domain page in ours.");
> @@ -172,7 +173,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
>  		goto out;
>  	}
>  
> -	err = xen_pcibk_do_attach(pdev, gnt_ref, remote_evtchn);
> +	err = xen_pcibk_do_attach(pdev, &gnt_ref, 1, remote_evtchn);
>  	if (err)
>  		goto out;
>  
> -- 
> 1.7.2.5

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 04:18:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 04:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtAak-0003SH-Dv; Fri, 03 Feb 2012 04:17:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtAai-0003RX-Id
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 04:17:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328242654!9880350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2933 invoked from network); 3 Feb 2012 04:17:34 -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 Feb 2012 04:17:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10456477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 04:17:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 04:17:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtAac-00046E-0D;
	Fri, 03 Feb 2012 04:17:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtAab-0001WO-RD;
	Fri, 03 Feb 2012 04:17:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11829-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 04:17:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11829: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11829 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11829/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-win           14 guest-start.2             fail REGR. vs. 11751

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

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-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-rhel6hvm-amd  7 redhat-install               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-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  3feb83eed6bd
baseline version:
 xen                  1b7e074ee1d6

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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:   21563:3feb83eed6bd
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 02 14:00:32 2012 +0000
    
    Update QEMU_TAG, for CVE-2012-0029
    
    
changeset:   21562:1b7e074ee1d6
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Jan 31 11:49:30 2012 +0000
    
    vesa: flush lfb after zeroing
    
    If Xen is going to relinquish the VGA console, flush the linear frame
    buffer after zeroing it in vesa_endboot().
    
    Failing to do so in some circumstances leads to the actual linear
    framebuffer on the graphics card still containing the output of the
    Xen boot console can lead to ugly graphics output when dom0 is setting
    up the graphics card for its own use.
    
    While the patch is quite large, it is mostly just code motion to
    prevent having to forward declare lfb_flush().  The only functional
    change to vesa_endboot() is to insert a call to lbf_flush().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24615:ac9f32525376
    xen-unstable date:        Sat Jan 28 13:42:25 2012 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 04:18:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 04:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtAak-0003SH-Dv; Fri, 03 Feb 2012 04:17:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtAai-0003RX-Id
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 04:17:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328242654!9880350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2933 invoked from network); 3 Feb 2012 04:17:34 -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 Feb 2012 04:17:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10456477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 04:17:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 04:17:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtAac-00046E-0D;
	Fri, 03 Feb 2012 04:17:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtAab-0001WO-RD;
	Fri, 03 Feb 2012 04:17:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11829-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 04:17:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11829: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11829 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11829/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-win           14 guest-start.2             fail REGR. vs. 11751

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

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-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-rhel6hvm-amd  7 redhat-install               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-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  3feb83eed6bd
baseline version:
 xen                  1b7e074ee1d6

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://www.chiark.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:   21563:3feb83eed6bd
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 02 14:00:32 2012 +0000
    
    Update QEMU_TAG, for CVE-2012-0029
    
    
changeset:   21562:1b7e074ee1d6
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Jan 31 11:49:30 2012 +0000
    
    vesa: flush lfb after zeroing
    
    If Xen is going to relinquish the VGA console, flush the linear frame
    buffer after zeroing it in vesa_endboot().
    
    Failing to do so in some circumstances leads to the actual linear
    framebuffer on the graphics card still containing the output of the
    Xen boot console can lead to ugly graphics output when dom0 is setting
    up the graphics card for its own use.
    
    While the patch is quite large, it is mostly just code motion to
    prevent having to forward declare lfb_flush().  The only functional
    change to vesa_endboot() is to insert a call to lbf_flush().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24615:ac9f32525376
    xen-unstable date:        Sat Jan 28 13:42:25 2012 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 04:54:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 04: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.xensource.com>)
	id 1RtB9T-0004uh-07; Fri, 03 Feb 2012 04:53:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RtB9R-0004u2-4q
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 04:53:33 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328244806!13208650!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwNTAy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31296 invoked from network); 3 Feb 2012 04:53:27 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-216.messagelabs.com with SMTP;
	3 Feb 2012 04:53:27 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 02 Feb 2012 20:53:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="102749052"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by azsmga001.ch.intel.com with ESMTP; 02 Feb 2012 20:53:25 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 3 Feb 2012 12:52:13 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 3 Feb 2012 12:52:12 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 12:52:11 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:24593 & Dom0:20a27c1e
Thread-Index: AQHM4i+WXZEJFXZBp0Ct7NFyYLOklQ==
Date: Fri, 3 Feb 2012 04:52:10 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FCB6673@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24593 & Dom0:20a27c1e
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report for xen-unstable tree. We found a new issue
After statically assigning a VF to SLES11 SP2 guest with runlevel 5, when connecting this guest via VNC, it displays blank screen. 

Version Info
=================================================================
xen-changeset:   24593:e2722b24dc09
pvops git: Jeremy's tree
commit 20a27c1e25b8550066902c9d6ca91631e656dfa3
=================================================================

New issue(1)
==============
1. blank screen in SLES11 SP2 RC3 guest with a VF statically assigned
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805
    ---- Jan@novell already has a patch to fix this issue.

Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752



Thanks
Zhou, Chao


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 04:54:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 04: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.xensource.com>)
	id 1RtB9T-0004uh-07; Fri, 03 Feb 2012 04:53:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RtB9R-0004u2-4q
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 04:53:33 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328244806!13208650!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwNTAy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31296 invoked from network); 3 Feb 2012 04:53:27 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-216.messagelabs.com with SMTP;
	3 Feb 2012 04:53:27 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 02 Feb 2012 20:53:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="102749052"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by azsmga001.ch.intel.com with ESMTP; 02 Feb 2012 20:53:25 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 3 Feb 2012 12:52:13 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 3 Feb 2012 12:52:12 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 12:52:11 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:24593 & Dom0:20a27c1e
Thread-Index: AQHM4i+WXZEJFXZBp0Ct7NFyYLOklQ==
Date: Fri, 3 Feb 2012 04:52:10 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FCB6673@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24593 & Dom0:20a27c1e
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report for xen-unstable tree. We found a new issue
After statically assigning a VF to SLES11 SP2 guest with runlevel 5, when connecting this guest via VNC, it displays blank screen. 

Version Info
=================================================================
xen-changeset:   24593:e2722b24dc09
pvops git: Jeremy's tree
commit 20a27c1e25b8550066902c9d6ca91631e656dfa3
=================================================================

New issue(1)
==============
1. blank screen in SLES11 SP2 RC3 guest with a VF statically assigned
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805
    ---- Jan@novell already has a patch to fix this issue.

Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
  http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752



Thanks
Zhou, Chao


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:17:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05: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.xensource.com>)
	id 1RtBW8-0005pB-LM; Fri, 03 Feb 2012 05:17:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtBW7-0005p5-6w
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:16:59 +0000
Received: from [85.158.138.51:36439] by server-4.bemta-3.messagelabs.com id
	91/4D-07654-ACD6B2F4; Fri, 03 Feb 2012 05:16:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328246217!11786033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24733 invoked from network); 3 Feb 2012 05:16:57 -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;
	3 Feb 2012 05:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10456981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 05:16:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 05:16:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtBW5-0004Pq-0z;
	Fri, 03 Feb 2012 05:16:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtBW3-0005QY-Cv;
	Fri, 03 Feb 2012 05:16:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11830-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 05:16:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 11830: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11830 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11830/

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen                  cccd6c68e1b9
baseline version:
 xen                  00c4b19f2648

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Keir Fraser <keir@xen.org>
  Paulian Bogdan Marinca <paulian@marinca.net>
  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-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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=cccd6c68e1b9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cccd6c68e1b9
+ branch=xen-4.1-testing
+ revision=cccd6c68e1b9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r cccd6c68e1b9 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:17:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05: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.xensource.com>)
	id 1RtBW8-0005pB-LM; Fri, 03 Feb 2012 05:17:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtBW7-0005p5-6w
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:16:59 +0000
Received: from [85.158.138.51:36439] by server-4.bemta-3.messagelabs.com id
	91/4D-07654-ACD6B2F4; Fri, 03 Feb 2012 05:16:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328246217!11786033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24733 invoked from network); 3 Feb 2012 05:16:57 -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;
	3 Feb 2012 05:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10456981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 05:16:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 05:16:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtBW5-0004Pq-0z;
	Fri, 03 Feb 2012 05:16:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtBW3-0005QY-Cv;
	Fri, 03 Feb 2012 05:16:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11830-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 05:16:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 11830: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11830 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11830/

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen                  cccd6c68e1b9
baseline version:
 xen                  00c4b19f2648

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Keir Fraser <keir@xen.org>
  Paulian Bogdan Marinca <paulian@marinca.net>
  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-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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=cccd6c68e1b9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cccd6c68e1b9
+ branch=xen-4.1-testing
+ revision=cccd6c68e1b9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r cccd6c68e1b9 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBeu-0006dR-5p; Fri, 03 Feb 2012 05:26:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBes-0006ce-8p
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:02 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18659 invoked from network); 3 Feb 2012 05:25:55 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:55 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDp095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: a1b6e68ff241424d1a9a788f5e789eba9ef8a7c0
Message-Id: <a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:20 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0527 (UTC)
	FILETIME=[4BD419F0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  305 ++++++++++++++++++++++++++++++++++-------
 1 files changed, 250 insertions(+), 55 deletions(-)


  o Document the XenBus nodes used in this protocol
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a56382286b67 -r a1b6e68ff241 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,246 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *----------------------- Backend Device Identification -----------------------
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      A free formatted string providing sufficient information for the
+ *      backend driver to open the backing device.  (e.g. the path to the
+ *      file or block device representing the backing store.)
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-aligment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The native sector size, in bytes, of the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of its native
+ *      sector size ("sector-size").
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +297,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * command on a native device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +339,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +353,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBeu-0006dR-5p; Fri, 03 Feb 2012 05:26:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBes-0006ce-8p
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:02 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18659 invoked from network); 3 Feb 2012 05:25:55 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:55 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDp095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: a1b6e68ff241424d1a9a788f5e789eba9ef8a7c0
Message-Id: <a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:20 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0527 (UTC)
	FILETIME=[4BD419F0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  305 ++++++++++++++++++++++++++++++++++-------
 1 files changed, 250 insertions(+), 55 deletions(-)


  o Document the XenBus nodes used in this protocol
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a56382286b67 -r a1b6e68ff241 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,246 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *----------------------- Backend Device Identification -----------------------
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      A free formatted string providing sufficient information for the
+ *      backend driver to open the backing device.  (e.g. the path to the
+ *      file or block device representing the backing store.)
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-aligment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The native sector size, in bytes, of the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of its native
+ *      sector size ("sector-size").
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +297,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * command on a native device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +339,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +353,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05: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.xensource.com>)
	id 1RtBet-0006dG-Q7; Fri, 03 Feb 2012 05:26:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBes-0006cf-8r
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:02 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18672 invoked from network); 3 Feb 2012 05:25:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDq095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 65403351f4b4158da7fb0f0f2b1e97f217f3c71b
Message-Id: <65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:21 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0542 (UTC)
	FILETIME=[4BD663E0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)


Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a1b6e68ff241 -r 65403351f4b4 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -393,6 +393,28 @@ DEFINE_RING_TYPES(blkif, struct blkif_re
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
 
+/*
+ * Xen-defined major numbers for virtual block devices.
+ */
+#define XEN_IDE0_MAJOR          3
+#define XEN_IDE1_MAJOR          22
+#define XEN_SCSI_DISK0_MAJOR    8
+#define XEN_SCSI_DISK1_MAJOR    65
+#define XEN_SCSI_DISK2_MAJOR    66
+#define XEN_SCSI_DISK3_MAJOR    67
+#define XEN_SCSI_DISK4_MAJOR    68
+#define XEN_SCSI_DISK5_MAJOR    69
+#define XEN_SCSI_DISK6_MAJOR    70
+#define XEN_SCSI_DISK7_MAJOR    71
+#define XEN_SCSI_DISK8_MAJOR    128
+#define XEN_SCSI_DISK9_MAJOR    129
+#define XEN_SCSI_DISK10_MAJOR   130
+#define XEN_SCSI_DISK11_MAJOR   131
+#define XEN_SCSI_DISK12_MAJOR   132
+#define XEN_SCSI_DISK13_MAJOR   133
+#define XEN_SCSI_DISK14_MAJOR   134
+#define XEN_SCSI_DISK15_MAJOR   135
+
 #endif /* __XEN_PUBLIC_IO_BLKIF_H__ */
 
 /*

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05: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.xensource.com>)
	id 1RtBet-0006dG-Q7; Fri, 03 Feb 2012 05:26:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBes-0006cf-8r
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:02 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18672 invoked from network); 3 Feb 2012 05:25:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDq095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 65403351f4b4158da7fb0f0f2b1e97f217f3c71b
Message-Id: <65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:21 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0542 (UTC)
	FILETIME=[4BD663E0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)


Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a1b6e68ff241 -r 65403351f4b4 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -393,6 +393,28 @@ DEFINE_RING_TYPES(blkif, struct blkif_re
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
 
+/*
+ * Xen-defined major numbers for virtual block devices.
+ */
+#define XEN_IDE0_MAJOR          3
+#define XEN_IDE1_MAJOR          22
+#define XEN_SCSI_DISK0_MAJOR    8
+#define XEN_SCSI_DISK1_MAJOR    65
+#define XEN_SCSI_DISK2_MAJOR    66
+#define XEN_SCSI_DISK3_MAJOR    67
+#define XEN_SCSI_DISK4_MAJOR    68
+#define XEN_SCSI_DISK5_MAJOR    69
+#define XEN_SCSI_DISK6_MAJOR    70
+#define XEN_SCSI_DISK7_MAJOR    71
+#define XEN_SCSI_DISK8_MAJOR    128
+#define XEN_SCSI_DISK9_MAJOR    129
+#define XEN_SCSI_DISK10_MAJOR   130
+#define XEN_SCSI_DISK11_MAJOR   131
+#define XEN_SCSI_DISK12_MAJOR   132
+#define XEN_SCSI_DISK13_MAJOR   133
+#define XEN_SCSI_DISK14_MAJOR   134
+#define XEN_SCSI_DISK15_MAJOR   135
+
 #endif /* __XEN_PUBLIC_IO_BLKIF_H__ */
 
 /*

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBeu-0006de-J2; Fri, 03 Feb 2012 05:26:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBet-0006cg-B1
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:03 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18691 invoked from network); 3 Feb 2012 05:25:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDr095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: c3609ad53946fb9131d80d0fd89faaf37fae6f28
Message-Id: <c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:22 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0542 (UTC)
	FILETIME=[4BD663E0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and Citrix
 blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  101 ++++++++++++++++++++++++++++++++++++-----
 1 files changed, 87 insertions(+), 14 deletions(-)


No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 65403351f4b4 -r c3609ad53946 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -100,6 +100,25 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *----------------------- Backend Device Identification -----------------------
  * mode
  *      Values:         "r" (read only), "w" (writable)
@@ -124,7 +143,7 @@
  * discard-aligment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -132,7 +151,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -176,10 +195,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "ring-pages" sized
+ *      list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -187,6 +216,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -201,12 +249,25 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     For full interoperability, block front and backends should support
+ *     both methods of negotiating this capability.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -224,20 +285,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -254,20 +321,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBeu-0006de-J2; Fri, 03 Feb 2012 05:26:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBet-0006cg-B1
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:03 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18691 invoked from network); 3 Feb 2012 05:25:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDr095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: c3609ad53946fb9131d80d0fd89faaf37fae6f28
Message-Id: <c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:22 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0542 (UTC)
	FILETIME=[4BD663E0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and Citrix
 blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  101 ++++++++++++++++++++++++++++++++++++-----
 1 files changed, 87 insertions(+), 14 deletions(-)


No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 65403351f4b4 -r c3609ad53946 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -100,6 +100,25 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *----------------------- Backend Device Identification -----------------------
  * mode
  *      Values:         "r" (read only), "w" (writable)
@@ -124,7 +143,7 @@
  * discard-aligment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -132,7 +151,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -176,10 +195,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "ring-pages" sized
+ *      list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -187,6 +216,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -201,12 +249,25 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     For full interoperability, block front and backends should support
+ *     both methods of negotiating this capability.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -224,20 +285,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -254,20 +321,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBeu-0006dl-WF; Fri, 03 Feb 2012 05:26:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBet-0006ch-Uh
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:04 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!6
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18704 invoked from network); 3 Feb 2012 05:25:57 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:57 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDs095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: f5c2e866c661d5000fb27bb370b8eae6521a870e
Message-Id: <f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:23 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0558 (UTC)
	FILETIME=[4BD8D4E0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the request
 number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  106 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 103 insertions(+), 3 deletions(-)


Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
      Drivers must be updated to, at minimum, use
      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
      with this header file.

This extension first appeared in FreeBSD.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r c3609ad53946 -r f5c2e866c661 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -119,6 +119,29 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent requests supported by the backend.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  255
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  255 * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *----------------------- Backend Device Identification -----------------------
  * mode
  *      Values:         "r" (read only), "w" (writable)
@@ -235,6 +258,31 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
+ *
+ *      The maximum number of concurrent requests that will be issued by
+ *      the frontend.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -392,11 +440,21 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -411,9 +469,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -421,11 +495,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -462,6 +547,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBeu-0006dl-WF; Fri, 03 Feb 2012 05:26:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBet-0006ch-Uh
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:04 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!6
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18704 invoked from network); 3 Feb 2012 05:25:57 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:57 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDs095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: f5c2e866c661d5000fb27bb370b8eae6521a870e
Message-Id: <f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:23 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0558 (UTC)
	FILETIME=[4BD8D4E0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the request
 number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  106 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 103 insertions(+), 3 deletions(-)


Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
      Drivers must be updated to, at minimum, use
      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
      with this header file.

This extension first appeared in FreeBSD.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r c3609ad53946 -r f5c2e866c661 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -119,6 +119,29 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent requests supported by the backend.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  255
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  255 * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *----------------------- Backend Device Identification -----------------------
  * mode
  *      Values:         "r" (read only), "w" (writable)
@@ -235,6 +258,31 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
+ *
+ *      The maximum number of concurrent requests that will be issued by
+ *      the frontend.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -392,11 +440,21 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -411,9 +469,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -421,11 +495,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -462,6 +547,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBes-0006cx-DK; Fri, 03 Feb 2012 05:26:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBer-0006cd-0e
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:01 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18642 invoked from network); 3 Feb 2012 05:25:54 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:54 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDo095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: a56382286b6789e407f6c7a69a0d2416c1c1a406
Message-Id: <a56382286b6789e407f6.1328246659@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:19 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0511 (UTC)
	FILETIME=[4BD1A8F0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 5] blkif.h: Miscelaneous style fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)


  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r e2722b24dc09 -r a56382286b67 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBes-0006cx-DK; Fri, 03 Feb 2012 05:26:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBer-0006cd-0e
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:01 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18642 invoked from network); 3 Feb 2012 05:25:54 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:54 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDo095844;
	Thu, 2 Feb 2012 22:25:52 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: a56382286b6789e407f6c7a69a0d2416c1c1a406
Message-Id: <a56382286b6789e407f6.1328246659@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:19 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0511 (UTC)
	FILETIME=[4BD1A8F0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 5] blkif.h: Miscelaneous style fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/public/io/blkif.h |  9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)


  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r e2722b24dc09 -r a56382286b67 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBer-0006cq-Uk; Fri, 03 Feb 2012 05:26:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBeq-0006cc-2d
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:00 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18625 invoked from network); 3 Feb 2012 05:25:53 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:53 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDn095844;
	Thu, 2 Feb 2012 22:25:51 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:18 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0495 (UTC)
	FILETIME=[4BCF37F0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 5] blkif.h: Document protocol and existing
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.  I assembled
this information by reviewing xend, various versions of the Linux
blkif drivers, fixing bugs in the FreeBSD blkfront driver, and
writing and testing a blkback driver for FreeBSD.

Even with this experience, given this interface was previously only
documented in source code, I'm sure there are mistakes or ommissions
in what I've done here.  Corrections welcome.

All but the last patch in the series is source compatible with
existing drivers.  This final patch adds FreeBSD's extension to
allow an I/O to span multiple ring entries.  The number of outstanding
requests, and the max I/O size and number of segments per request,
can all be negotiated.  Drivers offering this extension are backwards
compatible with existing drivers, but the definition of
BLKIF_MAX_SEGMENTS_PER_REQUEST has been changed to reflect the new
limit of 255.  A global replacement of BLKIF_MAX_SEGMENTS_PER_REQUEST
with BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK is all that's required to
adjust drivers without the extension to this header change.

--
Justin

 xen/include/public/io/blkif.h |    9 +-
 xen/include/public/io/blkif.h |  305 ++++++++++++++++++++++++++++++++++-------
 xen/include/public/io/blkif.h |   22 +++
 xen/include/public/io/blkif.h |  101 +++++++++++-
 xen/include/public/io/blkif.h |  106 ++++++++++++++-
 5 files changed, 466 insertions(+), 77 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:26:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBer-0006cq-Uk; Fri, 03 Feb 2012 05:26:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtBeq-0006cc-2d
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:26:00 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328246753!11216188!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18625 invoked from network); 3 Feb 2012 05:25:53 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-13.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 05:25:53 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 2 Feb 2012 22:25:52 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q135PpDn095844;
	Thu, 2 Feb 2012 22:25:51 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1328246658@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Thu, 02 Feb 2012 22:24:18 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 03 Feb 2012 05:25:52.0495 (UTC)
	FILETIME=[4BCF37F0:01CCE234]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 5] blkif.h: Document protocol and existing
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.  I assembled
this information by reviewing xend, various versions of the Linux
blkif drivers, fixing bugs in the FreeBSD blkfront driver, and
writing and testing a blkback driver for FreeBSD.

Even with this experience, given this interface was previously only
documented in source code, I'm sure there are mistakes or ommissions
in what I've done here.  Corrections welcome.

All but the last patch in the series is source compatible with
existing drivers.  This final patch adds FreeBSD's extension to
allow an I/O to span multiple ring entries.  The number of outstanding
requests, and the max I/O size and number of segments per request,
can all be negotiated.  Drivers offering this extension are backwards
compatible with existing drivers, but the definition of
BLKIF_MAX_SEGMENTS_PER_REQUEST has been changed to reflect the new
limit of 255.  A global replacement of BLKIF_MAX_SEGMENTS_PER_REQUEST
with BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK is all that's required to
adjust drivers without the extension to this header change.

--
Justin

 xen/include/public/io/blkif.h |    9 +-
 xen/include/public/io/blkif.h |  305 ++++++++++++++++++++++++++++++++++-------
 xen/include/public/io/blkif.h |   22 +++
 xen/include/public/io/blkif.h |  101 +++++++++++-
 xen/include/public/io/blkif.h |  106 ++++++++++++++-
 5 files changed, 466 insertions(+), 77 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:39:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBrH-0007Y9-LL; Fri, 03 Feb 2012 05:38:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maillists.shan@gmail.com>) id 1RtBrF-0007Y0-RK
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:38:50 +0000
X-Env-Sender: maillists.shan@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328247521!12924290!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16963 invoked from network); 3 Feb 2012 05:38:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 05:38:43 -0000
Received: by damc16 with SMTP id c16so16120830dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 21:38:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=AZ17vGrdJzMki5JptxuEQatac7bSG9feS70/ZdFKHXc=;
	b=R4JcbiY5PhaFxgcl/ngvDtRia4fmVi27YChZzP57e8duRzJ7oL75B2+bpdH2klDhMn
	UxhFbiswp7ltoIeJkNDrjBHiqts2dC8081GAydW8e+NE+MApkVrixs8VnbvzVsPiKTxv
	F3u7lPfmAMsIVy9avhrTtfWfnobWrr7ytNMVY=
MIME-Version: 1.0
Received: by 10.68.234.138 with SMTP id ue10mr14562345pbc.48.1328247521221;
	Thu, 02 Feb 2012 21:38:41 -0800 (PST)
Received: by 10.142.142.6 with HTTP; Thu, 2 Feb 2012 21:38:41 -0800 (PST)
In-Reply-To: <4F1EE714020000780006EB0C@nat28.tlf.novell.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1ED189.70401@citrix.com>
	<4F1EE714020000780006EB0C@nat28.tlf.novell.com>
Date: Fri, 3 Feb 2012 13:38:41 +0800
Message-ID: <CAFQ2Z+cFb6sk=MkvRcrano7PTJaN2KJBhFvO7TWzHc+KHV6b4g@mail.gmail.com>
From: Haitao Shan <maillists.shan@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xensource.com,
	"Dugger, Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We've tested the commit using standard NIC and SR-IOV NIC. It works fine.

Shan Haitao

2012/1/25 Jan Beulich <JBeulich@suse.com>:
>>>> On 24.01.12 at 16:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 20/01/12 16:33, Jan Beulich wrote:
>>> This addresses a number of problems in msixtbl_{read,write}():
>>> - address alignment was not checked, allowing for memory corruption in
>>> =A0 the hypervisor (write case) or returning of hypervisor private data
>>> =A0 to the guest (read case)
>>> - the interrupt mask bit was permitted to be written by the guest
>>> =A0 (while Xen's interrupt flow control routines need to control it)
>>> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>>> =A0 numbers (making it unobvious why they have these values, and making
>>> =A0 the latter non-portable)
>>> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>>> =A0 non-zero table offset); this was also affecting host MSI-X code
>>> - struct msixtbl_entry's table_flags[] was one element larger than
>>> =A0 necessary due to improper open-coding of BITS_TO_LONGS()
>>> - msixtbl_read() unconditionally accessed the physical table, even
>>> =A0 though the data was only needed in a quarter of all cases
>>> - various calculations were done unnecessarily for both of the rather
>>> =A0 distinct code paths in msixtbl_read()
>>>
>>> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
>>> chosen to be 3.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> Tested by backport to XenServer 6.0 (Xen-4.1.1) =A0The only conflicts we=
re
>> with the context around adding the two new header files, and <xen/pfn.h>
>> which is a new header file.
>>
>> Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> Thanks a lot, Andrew! (Keir had already committed the patch.)
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 05:39:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 05:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtBrH-0007Y9-LL; Fri, 03 Feb 2012 05:38:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maillists.shan@gmail.com>) id 1RtBrF-0007Y0-RK
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 05:38:50 +0000
X-Env-Sender: maillists.shan@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328247521!12924290!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16963 invoked from network); 3 Feb 2012 05:38:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 05:38:43 -0000
Received: by damc16 with SMTP id c16so16120830dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 21:38:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=AZ17vGrdJzMki5JptxuEQatac7bSG9feS70/ZdFKHXc=;
	b=R4JcbiY5PhaFxgcl/ngvDtRia4fmVi27YChZzP57e8duRzJ7oL75B2+bpdH2klDhMn
	UxhFbiswp7ltoIeJkNDrjBHiqts2dC8081GAydW8e+NE+MApkVrixs8VnbvzVsPiKTxv
	F3u7lPfmAMsIVy9avhrTtfWfnobWrr7ytNMVY=
MIME-Version: 1.0
Received: by 10.68.234.138 with SMTP id ue10mr14562345pbc.48.1328247521221;
	Thu, 02 Feb 2012 21:38:41 -0800 (PST)
Received: by 10.142.142.6 with HTTP; Thu, 2 Feb 2012 21:38:41 -0800 (PST)
In-Reply-To: <4F1EE714020000780006EB0C@nat28.tlf.novell.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1ED189.70401@citrix.com>
	<4F1EE714020000780006EB0C@nat28.tlf.novell.com>
Date: Fri, 3 Feb 2012 13:38:41 +0800
Message-ID: <CAFQ2Z+cFb6sk=MkvRcrano7PTJaN2KJBhFvO7TWzHc+KHV6b4g@mail.gmail.com>
From: Haitao Shan <maillists.shan@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xensource.com,
	"Dugger, Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We've tested the commit using standard NIC and SR-IOV NIC. It works fine.

Shan Haitao

2012/1/25 Jan Beulich <JBeulich@suse.com>:
>>>> On 24.01.12 at 16:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 20/01/12 16:33, Jan Beulich wrote:
>>> This addresses a number of problems in msixtbl_{read,write}():
>>> - address alignment was not checked, allowing for memory corruption in
>>> =A0 the hypervisor (write case) or returning of hypervisor private data
>>> =A0 to the guest (read case)
>>> - the interrupt mask bit was permitted to be written by the guest
>>> =A0 (while Xen's interrupt flow control routines need to control it)
>>> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>>> =A0 numbers (making it unobvious why they have these values, and making
>>> =A0 the latter non-portable)
>>> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>>> =A0 non-zero table offset); this was also affecting host MSI-X code
>>> - struct msixtbl_entry's table_flags[] was one element larger than
>>> =A0 necessary due to improper open-coding of BITS_TO_LONGS()
>>> - msixtbl_read() unconditionally accessed the physical table, even
>>> =A0 though the data was only needed in a quarter of all cases
>>> - various calculations were done unnecessarily for both of the rather
>>> =A0 distinct code paths in msixtbl_read()
>>>
>>> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
>>> chosen to be 3.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> Tested by backport to XenServer 6.0 (Xen-4.1.1) =A0The only conflicts we=
re
>> with the context around adding the two new header files, and <xen/pfn.h>
>> which is a new header file.
>>
>> Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> Thanks a lot, Andrew! (Keir had already committed the patch.)
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:23:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtCXn-00004t-Fy; Fri, 03 Feb 2012 06:22: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 1RtCXl-0008Vb-Ps
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:22:46 +0000
Received: from [85.158.138.51:9026] by server-11.bemta-3.messagelabs.com id
	75/4D-21643-43D7B2F4; Fri, 03 Feb 2012 06:22:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328250163!11815928!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14864 invoked from network); 3 Feb 2012 06:22:43 -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;
	3 Feb 2012 06:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10457587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 06:22:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 06:22:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtCXi-0004ow-DD;
	Fri, 03 Feb 2012 06:22:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtCXg-0002v9-Ae;
	Fri, 03 Feb 2012 06:22:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11831-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 06:22:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11831: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 11643
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 11643
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 11643
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 build-i386                    4 xen-build                    fail   like 11637
 build-i386-oldkern            4 xen-build                    fail   like 11637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fcc071c31e3a
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.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                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 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-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 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 1355 lines long.)

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:23:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtCXn-00004t-Fy; Fri, 03 Feb 2012 06:22: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 1RtCXl-0008Vb-Ps
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:22:46 +0000
Received: from [85.158.138.51:9026] by server-11.bemta-3.messagelabs.com id
	75/4D-21643-43D7B2F4; Fri, 03 Feb 2012 06:22:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328250163!11815928!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14864 invoked from network); 3 Feb 2012 06:22:43 -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;
	3 Feb 2012 06:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10457587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 06:22:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 06:22:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtCXi-0004ow-DD;
	Fri, 03 Feb 2012 06:22:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtCXg-0002v9-Ae;
	Fri, 03 Feb 2012 06:22:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11831-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 06:22:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11831: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 11643
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 11643
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 11643
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 11643
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 11643
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 11643
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 build-i386                    4 xen-build                    fail   like 11637
 build-i386-oldkern            4 xen-build                    fail   like 11637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fcc071c31e3a
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.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                                           fail    
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 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-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 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 1355 lines long.)

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:38:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtCmm-0000lz-3a; Fri, 03 Feb 2012 06:38:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtCmk-0000lu-ST
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:38:15 +0000
Received: from [85.158.138.51:15029] by server-11.bemta-3.messagelabs.com id
	67/D8-21643-5D08B2F4; Fri, 03 Feb 2012 06:38:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328251093!6666016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10641 invoked from network); 3 Feb 2012 06:38:13 -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;
	3 Feb 2012 06:38:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10457689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 06:38:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	06:38:12 +0000
Message-ID: <1328251092.13189.29.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 3 Feb 2012 06:38:12 +0000
In-Reply-To: <CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 22:52 +0000, Paul Gortmaker wrote:
> On Thu, Feb 2, 2012 at 3:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:
> 
> [...]
> 
> >
> > I don't think it is at all unreasonable to ask for bug fixes but in this
> > case Wei's series is removing the code in question (which would also
> > undoubtedly fix the bug).
> >
> > As it happens the fix turns out to be simple but if it were complex I
> > would perhaps have disagreed more strongly about spending effort fixing
> > code that is removed 2 patches later, although obviously that would have
> > depended on the specifics of the fix in that case.
> 
> Lots of people are relying on git bisect.  If you introduce build failures
> or known bugs into any point in history, you take away from the value
> in git bisect.  Sure, it happens by accident, but it shouldn't ever be
> done knowingly.

Sure. In this case the bug has been there since 2.6.39, it isn't
introduced by this series.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:38:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtCmm-0000lz-3a; Fri, 03 Feb 2012 06:38:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtCmk-0000lu-ST
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:38:15 +0000
Received: from [85.158.138.51:15029] by server-11.bemta-3.messagelabs.com id
	67/D8-21643-5D08B2F4; Fri, 03 Feb 2012 06:38:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328251093!6666016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10641 invoked from network); 3 Feb 2012 06:38:13 -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;
	3 Feb 2012 06:38:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,350,1325462400"; d="scan'208";a="10457689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 06:38:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	06:38:12 +0000
Message-ID: <1328251092.13189.29.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 3 Feb 2012 06:38:12 +0000
In-Reply-To: <CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 22:52 +0000, Paul Gortmaker wrote:
> On Thu, Feb 2, 2012 at 3:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:
> 
> [...]
> 
> >
> > I don't think it is at all unreasonable to ask for bug fixes but in this
> > case Wei's series is removing the code in question (which would also
> > undoubtedly fix the bug).
> >
> > As it happens the fix turns out to be simple but if it were complex I
> > would perhaps have disagreed more strongly about spending effort fixing
> > code that is removed 2 patches later, although obviously that would have
> > depended on the specifics of the fix in that case.
> 
> Lots of people are relying on git bisect.  If you introduce build failures
> or known bugs into any point in history, you take away from the value
> in git bisect.  Sure, it happens by accident, but it shouldn't ever be
> done knowingly.

Sure. In this case the bug has been there since 2.6.39, it isn't
introduced by this series.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtD4F-00015W-A0; Fri, 03 Feb 2012 06:56:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4E-000159-6b
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:18 +0000
Received: from [85.158.138.51:36723] by server-9.bemta-3.messagelabs.com id
	BD/75-21252-1158B2F4; Fri, 03 Feb 2012 06:56:17 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328252174!11648903!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27410 invoked from network); 3 Feb 2012 06:56:15 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:56:15 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6vM016349; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u69n016346;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 340dd6a3f0dab2fcba83a68dea072e9d9af20182
Message-Id: <340dd6a3f0dab2fcba83.1328251797@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:57 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 6 V3] libxl: helper function to send
	commands to	traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251592 28800
# Node ID 340dd6a3f0dab2fcba83a68dea072e9d9af20182
# Parent  4612cca7fb7c06e83a205510f6c2e43d5f246582
libxl: helper function to send commands to traditional qemu

Introduce a helper function to send commands to traditional
qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
libxl__domain_save_device_model and libxl_domain_unpause have
been refactored to use this function.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:32 2012 -0800
@@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__qemu_traditional_cmd(gc, domid, "continue");
             libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:32 2012 -0800
@@ -409,6 +409,15 @@ static int libxl__toolstack_restore(uint
     return 0;
 }
 
+int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                const char *cmd)
+{
+    char *path = NULL;
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                          domid);
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -761,12 +770,9 @@ int libxl__domain_save_device_model(libx
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                    "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
     }
diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:32 2012 -0800
@@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
               libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
+_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl_pci.c	Thu Feb 02 22:46:32 2012 -0800
@@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
         libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                         pcidev->bus, pcidev->dev, pcidev->func);
     }
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
-    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
+
+    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
     rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
                                       pci_ins_check, state);
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
@@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
     libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                     pcidev->bus, pcidev->dev, pcidev->func);
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
 
     /* Remove all functions at once atomically by only signalling
      * device-model for function 0 */
     if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
-        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
+        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
         if (libxl__wait_for_device_model(gc, domid, "pci-removed",
                                          NULL, NULL, NULL) < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtD4F-00015W-A0; Fri, 03 Feb 2012 06:56:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4E-000159-6b
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:18 +0000
Received: from [85.158.138.51:36723] by server-9.bemta-3.messagelabs.com id
	BD/75-21252-1158B2F4; Fri, 03 Feb 2012 06:56:17 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328252174!11648903!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27410 invoked from network); 3 Feb 2012 06:56:15 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:56:15 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6vM016349; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u69n016346;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 340dd6a3f0dab2fcba83a68dea072e9d9af20182
Message-Id: <340dd6a3f0dab2fcba83.1328251797@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:57 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 6 V3] libxl: helper function to send
	commands to	traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251592 28800
# Node ID 340dd6a3f0dab2fcba83a68dea072e9d9af20182
# Parent  4612cca7fb7c06e83a205510f6c2e43d5f246582
libxl: helper function to send commands to traditional qemu

Introduce a helper function to send commands to traditional
qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
libxl__domain_save_device_model and libxl_domain_unpause have
been refactored to use this function.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:32 2012 -0800
@@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__qemu_traditional_cmd(gc, domid, "continue");
             libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:32 2012 -0800
@@ -409,6 +409,15 @@ static int libxl__toolstack_restore(uint
     return 0;
 }
 
+int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                const char *cmd)
+{
+    char *path = NULL;
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                          domid);
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -761,12 +770,9 @@ int libxl__domain_save_device_model(libx
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                    "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
     }
diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:32 2012 -0800
@@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
               libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
+_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
diff -r 4612cca7fb7c -r 340dd6a3f0da tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 02 22:46:17 2012 -0800
+++ b/tools/libxl/libxl_pci.c	Thu Feb 02 22:46:32 2012 -0800
@@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
         libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                         pcidev->bus, pcidev->dev, pcidev->func);
     }
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
-    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
+
+    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
     rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
                                       pci_ins_check, state);
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
@@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
     libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                     pcidev->bus, pcidev->dev, pcidev->func);
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
 
     /* Remove all functions at once atomically by only signalling
      * device-model for function 0 */
     if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
-        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
+        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
         if (libxl__wait_for_device_model(gc, domid, "pci-removed",
                                          NULL, NULL, NULL) < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtD4P-00016v-Ng; Fri, 03 Feb 2012 06:56:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4O-00015y-4W
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:28 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328252179!13757107!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20128 invoked from network); 3 Feb 2012 06:56:21 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 06:56:21 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6qY016377; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6sF016374;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 62c4fd2fe9bbc2c283e3998d852317a48e9f9770
Message-Id: <62c4fd2fe9bbc2c283e3.1328251801@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:50:01 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 6 V3] libxl: refactor migrate_domain and
	generalize	migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 62c4fd2fe9bbc2c283e3998d852317a48e9f9770
# Parent  f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r f853c88f0230 -r 62c4fd2fe9bb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2616,53 +2653,17 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
+                                uint8_t *config_data, int config_len,
+                                const char *rune)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
-    uint8_t *config_data;
-    int config_len;
-
-    save_domain_core_begin(domain_spec, override_config_file,
-                           &config_data, &config_len);
-
-    if (!config_len) {
-        fprintf(stderr, "No config file stored for running domain and "
-                "none supplied - cannot migrate.\n");
+    int rc = 0;
+
+    if (send_fd < 0 || recv_fd < 0) {
+        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
     rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
@@ -2675,6 +2676,34 @@ static void migrate_domain(const char *d
     save_domain_core_writeconfig(send_fd, "migration stream",
                                  config_data, config_len);
 
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    pid_t child = -1;
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    uint8_t *config_data;
+    int config_len;
+
+    save_domain_core_begin(domain_spec, override_config_file,
+                           &config_data, &config_len);
+
+    if (!config_len) {
+        fprintf(stderr, "No config file stored for running domain and "
+                "none supplied - cannot migrate.\n");
+        exit(1);
+    }
+
+    child = create_migration_child(rune, &send_fd, &recv_fd);
+
+    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                        rune);
+
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2798,7 +2827,8 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2810,7 +2840,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2822,7 +2852,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2836,13 +2866,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2861,7 +2891,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2869,7 +2899,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2887,7 +2917,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -2983,7 +3013,9 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    STDOUT_FILENO, STDIN_FILENO);
+
     return 0;
 }
 

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06: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.xensource.com>)
	id 1RtD4P-00016v-Ng; Fri, 03 Feb 2012 06:56:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4O-00015y-4W
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:28 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328252179!13757107!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20128 invoked from network); 3 Feb 2012 06:56:21 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 06:56:21 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6qY016377; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6sF016374;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 62c4fd2fe9bbc2c283e3998d852317a48e9f9770
Message-Id: <62c4fd2fe9bbc2c283e3.1328251801@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:50:01 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 6 V3] libxl: refactor migrate_domain and
	generalize	migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 62c4fd2fe9bbc2c283e3998d852317a48e9f9770
# Parent  f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r f853c88f0230 -r 62c4fd2fe9bb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2616,53 +2653,17 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
+                                uint8_t *config_data, int config_len,
+                                const char *rune)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
-    uint8_t *config_data;
-    int config_len;
-
-    save_domain_core_begin(domain_spec, override_config_file,
-                           &config_data, &config_len);
-
-    if (!config_len) {
-        fprintf(stderr, "No config file stored for running domain and "
-                "none supplied - cannot migrate.\n");
+    int rc = 0;
+
+    if (send_fd < 0 || recv_fd < 0) {
+        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
     rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
@@ -2675,6 +2676,34 @@ static void migrate_domain(const char *d
     save_domain_core_writeconfig(send_fd, "migration stream",
                                  config_data, config_len);
 
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    pid_t child = -1;
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    uint8_t *config_data;
+    int config_len;
+
+    save_domain_core_begin(domain_spec, override_config_file,
+                           &config_data, &config_len);
+
+    if (!config_len) {
+        fprintf(stderr, "No config file stored for running domain and "
+                "none supplied - cannot migrate.\n");
+        exit(1);
+    }
+
+    child = create_migration_child(rune, &send_fd, &recv_fd);
+
+    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                        rune);
+
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2798,7 +2827,8 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2810,7 +2840,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2822,7 +2852,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2836,13 +2866,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2861,7 +2891,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2869,7 +2899,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2887,7 +2917,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -2983,7 +3013,9 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    STDOUT_FILENO, STDIN_FILENO);
+
     return 0;
 }
 

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD4E-00015E-Nx; Fri, 03 Feb 2012 06:56:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4C-00014y-Va
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:17 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328252136!50913649!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7686 invoked from network); 3 Feb 2012 06:55:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 06:55:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6s3016363; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6nO016360;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 329b3c94c618addb1e802cebc7fe23b12b432398
Message-Id: <329b3c94c618addb1e80.1328251799@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:59 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 6 V3] libxl: QMP stop/resume & refactor
	QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 329b3c94c618addb1e802cebc7fe23b12b432398
# Parent  636da26c40d37b84a93b6a6c3881b2fccc768aa2
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
@@ -488,6 +488,54 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        /* Save DM state into filename */
+        ret = libxl__qmp_save(gc, domid, filename);
+        if (ret)
+            unlink(filename);
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        libxl__wait_for_device_model(gc, domid, "running", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -517,7 +565,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto guest_suspended;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -595,7 +643,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto guest_suspended;
             }
         }
 
@@ -604,6 +652,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ guest_suspended:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
@@ -768,23 +827,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        ret = libxl__qmp_save(gc, domid, (char *)filename);
-        if (ret)
-            goto out;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
@@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_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);
 /* close and free the QMP handler */
diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
@@ -802,6 +802,38 @@ out:
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD4E-00015E-Nx; Fri, 03 Feb 2012 06:56:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4C-00014y-Va
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:17 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328252136!50913649!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7686 invoked from network); 3 Feb 2012 06:55:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 06:55:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6s3016363; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6nO016360;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 329b3c94c618addb1e802cebc7fe23b12b432398
Message-Id: <329b3c94c618addb1e80.1328251799@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:59 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 6 V3] libxl: QMP stop/resume & refactor
	QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 329b3c94c618addb1e802cebc7fe23b12b432398
# Parent  636da26c40d37b84a93b6a6c3881b2fccc768aa2
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
@@ -488,6 +488,54 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        /* Save DM state into filename */
+        ret = libxl__qmp_save(gc, domid, filename);
+        if (ret)
+            unlink(filename);
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        libxl__wait_for_device_model(gc, domid, "running", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -517,7 +565,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto guest_suspended;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -595,7 +643,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto guest_suspended;
             }
         }
 
@@ -604,6 +652,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ guest_suspended:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
@@ -768,23 +827,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        ret = libxl__qmp_save(gc, domid, (char *)filename);
-        if (ret)
-            goto out;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
@@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_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);
 /* close and free the QMP handler */
diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
@@ -802,6 +802,38 @@ out:
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD4T-00017n-Hp; Fri, 03 Feb 2012 06:56:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4S-00016X-N9
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:32 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328252182!13526130!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29905 invoked from network); 3 Feb 2012 06:56:24 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:56:24 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6Oe016356; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6qG016353;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 636da26c40d37b84a93b6a6c3881b2fccc768aa2
Message-Id: <636da26c40d37b84a93b.1328251798@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:58 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 6 V3] libxl: bugfix: create_domain() return
	to caller if	!daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 636da26c40d37b84a93b6a6c3881b2fccc768aa2
# Parent  340dd6a3f0dab2fcba83a68dea072e9d9af20182
libxl: bugfix: create_domain() return to caller if !daemonize

Currently the create_domain function does not honor
the daemonize flag properly. It exits irrespective of
the value of the flag. This patch fixes the issue.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 340dd6a3f0da -r 636da26c40d3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:32 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -1814,7 +1814,7 @@ waitpid_out:
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD4T-00017n-Hp; Fri, 03 Feb 2012 06:56:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4S-00016X-N9
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:32 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328252182!13526130!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29905 invoked from network); 3 Feb 2012 06:56:24 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:56:24 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6Oe016356; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6qG016353;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: 636da26c40d37b84a93b6a6c3881b2fccc768aa2
Message-Id: <636da26c40d37b84a93b.1328251798@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:58 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 6 V3] libxl: bugfix: create_domain() return
	to caller if	!daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 636da26c40d37b84a93b6a6c3881b2fccc768aa2
# Parent  340dd6a3f0dab2fcba83a68dea072e9d9af20182
libxl: bugfix: create_domain() return to caller if !daemonize

Currently the create_domain function does not honor
the daemonize flag properly. It exits irrespective of
the value of the flag. This patch fixes the issue.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 340dd6a3f0da -r 636da26c40d3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:32 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -1814,7 +1814,7 @@ waitpid_out:
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD4R-00017F-5F; Fri, 03 Feb 2012 06:56:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4P-00016B-C0
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328252180!10260131!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26185 invoked from network); 3 Feb 2012 06:56:22 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 06:56:22 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u7uD016384; Thu, 2 Feb 2012 22:56:07 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6lW016381;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: c7abecc14cceb18140335ebe20faad826282cd1f
Message-Id: <c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:50:02 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 6 V3] libxl: resume instead of unpause on
	xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID c7abecc14cceb18140335ebe20faad826282cd1f
# Parent  62c4fd2fe9bbc2c283e3998d852317a48e9f9770
libxl: resume instead of unpause on xl save -c

The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
So call libxl_domain_resume instead of libxl_domain_unpause, when taking
a checkpoint of the domain (using xl save -c).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 62c4fd2fe9bb -r c7abecc14cce tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
     close(fd);
 
     if (checkpoint)
-        libxl_domain_unpause(ctx, domid);
+        libxl_domain_resume(ctx, domid, 1);
     else
         libxl_domain_destroy(ctx, domid);
 

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:56:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD4R-00017F-5F; Fri, 03 Feb 2012 06:56:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD4P-00016B-C0
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:56:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328252180!10260131!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26185 invoked from network); 3 Feb 2012 06:56:22 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 06:56:22 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u7uD016384; Thu, 2 Feb 2012 22:56:07 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6lW016381;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: c7abecc14cceb18140335ebe20faad826282cd1f
Message-Id: <c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:50:02 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 6 V3] libxl: resume instead of unpause on
	xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID c7abecc14cceb18140335ebe20faad826282cd1f
# Parent  62c4fd2fe9bbc2c283e3998d852317a48e9f9770
libxl: resume instead of unpause on xl save -c

The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
So call libxl_domain_resume instead of libxl_domain_unpause, when taking
a checkpoint of the domain (using xl save -c).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 62c4fd2fe9bb -r c7abecc14cce tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
     close(fd);
 
     if (checkpoint)
-        libxl_domain_unpause(ctx, domid);
+        libxl_domain_resume(ctx, domid, 1);
     else
         libxl_domain_destroy(ctx, domid);
 

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:57:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD5I-0001JW-16; Fri, 03 Feb 2012 06:57:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD5G-0001I4-Ez
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:57:22 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328252234!13774329!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18748 invoked from network); 3 Feb 2012 06:57:16 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:57:16 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6C9016342; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u5IZ016339;
	Thu, 2 Feb 2012 22:56:05 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:56 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 6 V3] libxl: refactor suspend/resume code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyBwYXRjaCBzZXJpZXMgcmVmYWN0b3JzIHRoZSBzdXNwZW5kL3Jlc3VtZSBjb2RlIHRvIG1p
bmltaXplClJlbXVzIHNwZWNpZmljIGNvZGUgaW4gbGlieGwuIFRoZXJlIGFyZSBhIGNvdXBsZSBv
ZiB0cml2aWFsIGJ1ZwpmaXhlcyB0b28uCgpUaGVzZSBwYXRjaGVzIGRlcGVuZCBvbiBTdGVmYW5v
J3MgInY0IGxpYnhsOiBzYXZlL3Jlc3Rv4oCLcmUgcWVtdSBwaHlzbWFwIgoKCkNoYW5nZXMgaW4g
VjM6CgoxLiByZWJhc2UgcGF0Y2hlcyBiYXNlZCBvbiBTdGVmYW5vJ3MgcGF0Y2hlcwogICB1c2Ug
cW1wX3NhdmUgaW5zdGVhZCBvZiBxbXBfbWlncmF0ZQoyLiBjaGVjayBpZiBxZW11IG1vdmVzIHRv
ICJydW5uaW5nIiBzdGF0ZSBhZnRlciByZXN1bWluZyB0aGUgZGV2aWNlIG1vZGVsCjMuIE1vdmVk
IGNvbW1lbnRzIG9uIHRoZSBjby1vcGVyYXRpdmUgc3VzcGVuZCB0byBsaWJ4bC5oCgoKQ2hhbmdl
cyBpbiBWMjoKMS4gbWlncmF0ZSBjb2RlIGlzIHJlZmFjdG9yZWQgYXMgc2F2ZV9jb25maWcgLCBj
cmVhdGUgY2hpbGQsCiAgIGRvX3ByZWFtYmxlIGluc3RlYWQgb2YgY29hZWxzY2luZyB0aGVtIGFs
bCBpbnRvIG9uZSBzaW5nbGUKICAgZnVuY3Rpb24uCjIuIE1vcmUgZG9jdW1lbnRhdGlvbiBmb3Ig
c3VzcGVuZF9jYW5jZWwgcGFyYW1ldGVyIGluIGRvbWFpbl9yZXN1bWUKMy4gTWlub3Igbml0cwoK
c2hyaXJhbQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:57:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD5I-0001JW-16; Fri, 03 Feb 2012 06:57:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD5G-0001I4-Ez
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:57:22 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328252234!13774329!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18748 invoked from network); 3 Feb 2012 06:57:16 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:57:16 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6C9016342; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u5IZ016339;
	Thu, 2 Feb 2012 22:56:05 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:49:56 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 6 V3] libxl: refactor suspend/resume code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyBwYXRjaCBzZXJpZXMgcmVmYWN0b3JzIHRoZSBzdXNwZW5kL3Jlc3VtZSBjb2RlIHRvIG1p
bmltaXplClJlbXVzIHNwZWNpZmljIGNvZGUgaW4gbGlieGwuIFRoZXJlIGFyZSBhIGNvdXBsZSBv
ZiB0cml2aWFsIGJ1ZwpmaXhlcyB0b28uCgpUaGVzZSBwYXRjaGVzIGRlcGVuZCBvbiBTdGVmYW5v
J3MgInY0IGxpYnhsOiBzYXZlL3Jlc3Rv4oCLcmUgcWVtdSBwaHlzbWFwIgoKCkNoYW5nZXMgaW4g
VjM6CgoxLiByZWJhc2UgcGF0Y2hlcyBiYXNlZCBvbiBTdGVmYW5vJ3MgcGF0Y2hlcwogICB1c2Ug
cW1wX3NhdmUgaW5zdGVhZCBvZiBxbXBfbWlncmF0ZQoyLiBjaGVjayBpZiBxZW11IG1vdmVzIHRv
ICJydW5uaW5nIiBzdGF0ZSBhZnRlciByZXN1bWluZyB0aGUgZGV2aWNlIG1vZGVsCjMuIE1vdmVk
IGNvbW1lbnRzIG9uIHRoZSBjby1vcGVyYXRpdmUgc3VzcGVuZCB0byBsaWJ4bC5oCgoKQ2hhbmdl
cyBpbiBWMjoKMS4gbWlncmF0ZSBjb2RlIGlzIHJlZmFjdG9yZWQgYXMgc2F2ZV9jb25maWcgLCBj
cmVhdGUgY2hpbGQsCiAgIGRvX3ByZWFtYmxlIGluc3RlYWQgb2YgY29hZWxzY2luZyB0aGVtIGFs
bCBpbnRvIG9uZSBzaW5nbGUKICAgZnVuY3Rpb24uCjIuIE1vcmUgZG9jdW1lbnRhdGlvbiBmb3Ig
c3VzcGVuZF9jYW5jZWwgcGFyYW1ldGVyIGluIGRvbWFpbl9yZXN1bWUKMy4gTWlub3Igbml0cwoK
c2hyaXJhbQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:57:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD5J-0001Jy-EE; Fri, 03 Feb 2012 06:57:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD5I-0001IM-15
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:57:24 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328252234!13774329!2
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18799 invoked from network); 3 Feb 2012 06:57:17 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:57:17 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6Qm016370; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6M5016367;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
Message-Id: <f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:50:00 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
# Parent  329b3c94c618addb1e802cebc7fe23b12b432398
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
@@ -268,7 +268,12 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+
+/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
+ *   If this parameter is true, use co-operative resume. The guest
+ *   must support this.
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 1);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 1);
     exit(-ERROR_FAIL);
 
  failed_badly:

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 06:57:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 06:57:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtD5J-0001Jy-EE; Fri, 03 Feb 2012 06:57:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtD5I-0001IM-15
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 06:57:24 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328252234!13774329!2
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18799 invoked from network); 3 Feb 2012 06:57:17 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 06:57:17 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q136u6Qm016370; Thu, 2 Feb 2012 22:56:06 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q136u6M5016367;
	Thu, 2 Feb 2012 22:56:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
Message-Id: <f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 22:50:00 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
# Parent  329b3c94c618addb1e802cebc7fe23b12b432398
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
@@ -268,7 +268,12 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+
+/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
+ *   If this parameter is true, use co-operative resume. The guest
+ *   must support this.
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 1);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 1);
     exit(-ERROR_FAIL);
 
  failed_badly:

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:04:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDCN-0002Ln-Ga; Fri, 03 Feb 2012 07:04:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtDCL-0002Lf-3n
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:04:41 +0000
Received: from [85.158.138.51:9958] by server-12.bemta-3.messagelabs.com id
	F4/A6-21103-8078B2F4; Fri, 03 Feb 2012 07:04:40 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328252677!11824216!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22082 invoked from network); 3 Feb 2012 07:04:39 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 07:04:39 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1374Wc2016500; Thu, 2 Feb 2012 23:04:32 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1374Wfm016497;
	Thu, 2 Feb 2012 23:04:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: 90e59c643c00c079996e13b75f89d1f0cd931a02
Message-Id: <90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 23:00:14 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V3] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 90e59c643c00c079996e13b75f89d1f0cd931a02
# Parent  c7abecc14cceb18140335ebe20faad826282cd1f
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.
 * Introduce a new public API, libxl_domain_remus_start (currently a stub)
   that sets up the network and disk buffer and initiates continuous
   checkpointing.

 * Future patches will augument these callbacks/functions with more functionalities
   like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -471,6 +471,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = ERROR_INVAL;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
@@ -480,7 +515,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
@@ -467,6 +467,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -731,9 +733,43 @@ static int libxl__toolstack_save(uint32_
     return 0;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -764,10 +800,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -791,7 +837,27 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        /* save_callbacks:
+         * suspend - called after expiration of checkpoint interval,
+         *           to *suspend* the domain.
+         *
+         * postcopy - called after the domain's dirty pages have been
+         *            copied into an output buffer. We *resume* the domain
+         *            & the device model, return to the caller. Caller then
+         *            flushes the output buffer, while the domain continues to run.
+         *
+         * checkpoint - called after the memory checkpoint has been flushed out
+         *              into the network. Send the saved device state, *wait*
+         *              for checkpoint ack and *release* the network buffer (TBD).
+         *              Then *sleep* for the checkpoint interval.
+         */
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Thu Feb 02 22:46:33 2012 -0800
@@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:04:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDCN-0002Ln-Ga; Fri, 03 Feb 2012 07:04:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtDCL-0002Lf-3n
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:04:41 +0000
Received: from [85.158.138.51:9958] by server-12.bemta-3.messagelabs.com id
	F4/A6-21103-8078B2F4; Fri, 03 Feb 2012 07:04:40 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328252677!11824216!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22082 invoked from network); 3 Feb 2012 07:04:39 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 07:04:39 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1374Wc2016500; Thu, 2 Feb 2012 23:04:32 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1374Wfm016497;
	Thu, 2 Feb 2012 23:04:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: 90e59c643c00c079996e13b75f89d1f0cd931a02
Message-Id: <90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 23:00:14 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V3] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 90e59c643c00c079996e13b75f89d1f0cd931a02
# Parent  c7abecc14cceb18140335ebe20faad826282cd1f
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.
 * Introduce a new public API, libxl_domain_remus_start (currently a stub)
   that sets up the network and disk buffer and initiates continuous
   checkpointing.

 * Future patches will augument these callbacks/functions with more functionalities
   like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -471,6 +471,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = ERROR_INVAL;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
@@ -480,7 +515,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
@@ -467,6 +467,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -731,9 +733,43 @@ static int libxl__toolstack_save(uint32_
     return 0;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -764,10 +800,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -791,7 +837,27 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        /* save_callbacks:
+         * suspend - called after expiration of checkpoint interval,
+         *           to *suspend* the domain.
+         *
+         * postcopy - called after the domain's dirty pages have been
+         *            copied into an output buffer. We *resume* the domain
+         *            & the device model, return to the caller. Caller then
+         *            flushes the output buffer, while the domain continues to run.
+         *
+         * checkpoint - called after the memory checkpoint has been flushed out
+         *              into the network. Send the saved device state, *wait*
+         *              for checkpoint ack and *release* the network buffer (TBD).
+         *              Then *sleep* for the checkpoint interval.
+         */
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Thu Feb 02 22:46:33 2012 -0800
@@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:04:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDCP-0002M6-Uh; Fri, 03 Feb 2012 07:04:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtDCP-0002Lb-0G
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:04:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328252615!59571114!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17608 invoked from network); 3 Feb 2012 07:03:37 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 07:03:37 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1374Wgx016493; Thu, 2 Feb 2012 23:04:32 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1374WKN016490;
	Thu, 2 Feb 2012 23:04:32 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 23:00:13 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V3] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyBwYXRjaCBzZXJpZXMgaW50cm9kdWNlcyBhIGJhc2ljIGZyYW1ld29yayB0byBpbmNvcnBv
cmF0ZSAKUmVtdXMgaW50byB0aGUgbGlieGwgdG9vbHN0YWNrLiBUaGUgb25seSBmdW5jdGlvbmFs
aXR5IGN1cnJlbnRseSAKaW1wbGVtZW50ZWQgaXMgbWVtb3J5IGNoZWNrcG9pbnRpbmcuCgpUaGVz
ZSBwYXRjaGVzIGRlcGVuZCBvbiAiVjMgbGlieGw6IHJlZmFjdG9yIHN1c3BlbmQvcmVzdW1lIGNv
ZGUiIHBhdGNoIHNlcmllcy4KIGFuZCBhbHNvIG9uIFN0ZWZhbm8ncyAiVjQgbGlieGw6IHNhdmUv
cmVzdG/igItyZSBxZW11IHBoeXNtYXAiCgpDaGFuZ2VzIGluIFYzOgogKiBSZWJhc2VkIHcuci50
IFN0ZWZhbm8ncyBwYXRjaGVzLgoKQ2hhbmdlcyBpbiBWMjoKICogTW92ZSBsaWJ4bF9kb21haW5f
cmVtdXNfc3RhcnQgaW50byB0aGUgc2F2ZV9jYWxsYmFja3MgaW1wbGVtZW50YXRpb24gcGF0Y2gK
ICogcmV0dXJuIHByb3BlciBlcnJvciBjb2RlcyBpbnN0ZWFkIG9mIC0xLgogKiBBZGQgZG9jdW1l
bnRhdGlvbiB0byBkb2NzL21hbi94bC5wb2QuMQoKU2hyaXJhbQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:04:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDCP-0002M6-Uh; Fri, 03 Feb 2012 07:04:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtDCP-0002Lb-0G
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:04:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328252615!59571114!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17608 invoked from network); 3 Feb 2012 07:03:37 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 07:03:37 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1374Wgx016493; Thu, 2 Feb 2012 23:04:32 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1374WKN016490;
	Thu, 2 Feb 2012 23:04:32 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 23:00:13 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V3] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyBwYXRjaCBzZXJpZXMgaW50cm9kdWNlcyBhIGJhc2ljIGZyYW1ld29yayB0byBpbmNvcnBv
cmF0ZSAKUmVtdXMgaW50byB0aGUgbGlieGwgdG9vbHN0YWNrLiBUaGUgb25seSBmdW5jdGlvbmFs
aXR5IGN1cnJlbnRseSAKaW1wbGVtZW50ZWQgaXMgbWVtb3J5IGNoZWNrcG9pbnRpbmcuCgpUaGVz
ZSBwYXRjaGVzIGRlcGVuZCBvbiAiVjMgbGlieGw6IHJlZmFjdG9yIHN1c3BlbmQvcmVzdW1lIGNv
ZGUiIHBhdGNoIHNlcmllcy4KIGFuZCBhbHNvIG9uIFN0ZWZhbm8ncyAiVjQgbGlieGw6IHNhdmUv
cmVzdG/igItyZSBxZW11IHBoeXNtYXAiCgpDaGFuZ2VzIGluIFYzOgogKiBSZWJhc2VkIHcuci50
IFN0ZWZhbm8ncyBwYXRjaGVzLgoKQ2hhbmdlcyBpbiBWMjoKICogTW92ZSBsaWJ4bF9kb21haW5f
cmVtdXNfc3RhcnQgaW50byB0aGUgc2F2ZV9jYWxsYmFja3MgaW1wbGVtZW50YXRpb24gcGF0Y2gK
ICogcmV0dXJuIHByb3BlciBlcnJvciBjb2RlcyBpbnN0ZWFkIG9mIC0xLgogKiBBZGQgZG9jdW1l
bnRhdGlvbiB0byBkb2NzL21hbi94bC5wb2QuMQoKU2hyaXJhbQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:04:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:04:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDCR-0002MS-BY; Fri, 03 Feb 2012 07:04:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtDCP-0002Ld-Gx
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:04:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328252677!13475103!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1247 invoked from network); 3 Feb 2012 07:04:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 07:04:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1374WSL016507; Thu, 2 Feb 2012 23:04:32 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1374WaE016504;
	Thu, 2 Feb 2012 23:04:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2965835b0c0062a359ac04c715d7af52c6ba60ee
Message-Id: <2965835b0c0062a359ac.1328252415@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 23:00:15 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V3] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 2965835b0c0062a359ac04c715d7af52c6ba60ee
# Parent  90e59c643c00c079996e13b75f89d1f0cd931a02
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 90e59c643c00 -r 2965835b0c00 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
+++ b/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
@@ -348,6 +348,39 @@ Send <config> instead of config file fro
 
 =back
 
+=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
+
+Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
+between the two hosts.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-i> I<MS>
+
+Checkpoint domain memory every MS milliseconds (default 200ms).
+
+=item B<-b>
+
+Replicate memory checkpoints to /dev/null (blackhole).
+
+=item B<-u>
+
+Disable memory checkpoint compression.
+
+=item B<-s> I<sshcommand>
+
+Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
+<host> instead of ssh <host> xl migrate-receive -r [-e].
+
+=item B<-e>
+
+On the new host, do not wait in the background (on <host>) for the death of the
+domain. See the corresponding option of the I<create> subcommand.
+
+=back
+
 =item B<pause> I<domain-id>
 
 Pause a domain.  When in a paused state the domain will still consume
diff -r 90e59c643c00 -r 2965835b0c00 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl.h	Thu Feb 02 22:46:33 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 90e59c643c00 -r 2965835b0c00 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2828,7 +2828,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 send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    STDOUT_FILENO, STDIN_FILENO);
+                    STDOUT_FILENO, STDIN_FILENO,
+                    remus);
 
     return 0;
 }
@@ -5951,6 +5990,106 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+    uint8_t *config_data;
+    int config_len;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    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");
+            exit(-1);
+        }
+    } else {
+
+        /*
+         * TODO: change this to plain TCP socket based channel
+         * instead of SSH. For both live-migration and Remus.
+         */
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        child = create_migration_child(rune, &send_fd, &recv_fd);
+
+        migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                            rune);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 90e59c643c00 -r 2965835b0c00 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Thu Feb 02 22:46:33 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r [-e]\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:04:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:04:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDCR-0002MS-BY; Fri, 03 Feb 2012 07:04:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RtDCP-0002Ld-Gx
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:04:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328252677!13475103!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1247 invoked from network); 3 Feb 2012 07:04:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 07:04:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1374WSL016507; Thu, 2 Feb 2012 23:04:32 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1374WaE016504;
	Thu, 2 Feb 2012 23:04:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2965835b0c0062a359ac04c715d7af52c6ba60ee
Message-Id: <2965835b0c0062a359ac.1328252415@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 02 Feb 2012 23:00:15 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V3] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328251593 28800
# Node ID 2965835b0c0062a359ac04c715d7af52c6ba60ee
# Parent  90e59c643c00c079996e13b75f89d1f0cd931a02
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 90e59c643c00 -r 2965835b0c00 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
+++ b/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
@@ -348,6 +348,39 @@ Send <config> instead of config file fro
 
 =back
 
+=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
+
+Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
+between the two hosts.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-i> I<MS>
+
+Checkpoint domain memory every MS milliseconds (default 200ms).
+
+=item B<-b>
+
+Replicate memory checkpoints to /dev/null (blackhole).
+
+=item B<-u>
+
+Disable memory checkpoint compression.
+
+=item B<-s> I<sshcommand>
+
+Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
+<host> instead of ssh <host> xl migrate-receive -r [-e].
+
+=item B<-e>
+
+On the new host, do not wait in the background (on <host>) for the death of the
+domain. See the corresponding option of the I<create> subcommand.
+
+=back
+
 =item B<pause> I<domain-id>
 
 Pause a domain.  When in a paused state the domain will still consume
diff -r 90e59c643c00 -r 2965835b0c00 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl.h	Thu Feb 02 22:46:33 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 90e59c643c00 -r 2965835b0c00 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
@@ -2828,7 +2828,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 send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2863,6 +2863,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -2989,10 +3024,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3006,6 +3041,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3014,7 +3052,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    STDOUT_FILENO, STDIN_FILENO);
+                    STDOUT_FILENO, STDIN_FILENO,
+                    remus);
 
     return 0;
 }
@@ -5951,6 +5990,106 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+    uint8_t *config_data;
+    int config_len;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    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");
+            exit(-1);
+        }
+    } else {
+
+        /*
+         * TODO: change this to plain TCP socket based channel
+         * instead of SSH. For both live-migration and Remus.
+         */
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        child = create_migration_child(rune, &send_fd, &recv_fd);
+
+        migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                            rune);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 90e59c643c00 -r 2965835b0c00 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Feb 02 22:46:33 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Thu Feb 02 22:46:33 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r [-e]\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:18:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07: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.xensource.com>)
	id 1RtDPU-0003FL-VH; Fri, 03 Feb 2012 07:18:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RtDPS-0003FD-Qa
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:18:15 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328253487!13529104!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIxODY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14713 invoked from network); 3 Feb 2012 07:18:07 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	3 Feb 2012 07:18:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 02 Feb 2012 23:18:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105798788"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 02 Feb 2012 23:18:04 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 3 Feb 2012 15:18:02 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 3 Feb 2012 15:18:01 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 15:18:01 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, George Dunlap <george.dunlap@citrix.com>, 
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] vMCE vs migration
Thread-Index: AQHM2b+3mIIv8qUEcUC7dztSHU+i2ZYazHkAgAAK9YCAA4VsAIAGFO4AgAZhOvA=
Date: Fri, 3 Feb 2012 07:18:00 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
In-Reply-To: <4F26AD7C020000780006FDC1@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: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com>
>>>> wrote: 
>> On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>>>>>> On 24.01.12 at 11:29, George Dunlap
>>>>>> <George.Dunlap@eu.citrix.com> wrote: 
>>>> On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com>
>>>> wrote: 
>>>>> x86's vMCE implementation lets a guest know of as many MCE
>>>>> reporting banks as there are in the host. While a PV guest could
>>>>> be expected to deal with this number changing (particularly
>>>>> decreasing) during migration (not currently handled anywhere
>>>>> afaict), for HVM guests this is certainly wrong. 
>>>>> 
>>>>> At least to me it isn't, however, clear how to properly handle
>>>>> this. The easiest would appear to be to save and restore the
>>>>> number of banks 
>>>>> the guest was made believe it can access, making vmce_{rd,wr}msr()
>>>>> silently tolerate accesses between the host and guest values.
>>>> 
>>>> We ran into this in the XS 6.0 release as well.  I think that the
>>>> ideal thing to do would be to have a parameter that can be set at
>>>> boot, to say how many vMCE banks a guest has, defaulting to the
>>>> number of MCE banks on the host.  This parameter would be
>>>> preserved across migration.  Ideally, a pool-aware toolstack like
>>>> xapi would then set this value to be the value of the host in the
>>>> pool with the largest number of banks, allowing a guest to access
>>>> all the banks on any host to which it migrates. 
>>>> 
>>>> What do you think?
>>> 
>>> That sounds like the way to go.
>> 
>> So should we put this on IanC's to-do-be-done list?  Are you going to
>> put it on your to-do list? :-)
> 
> Below/attached a draft patch (compile tested only), handling save/
> restore of the bank count, but not allowing for a config setting to
> specify its initial value (yet).
> 
> Jan
> 
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
> 
>          domctl.cmd = XEN_DOMCTL_get_ext_vcpucontext;
>          domctl.domain = dom;
> +        memset(&domctl.u, 0, sizeof(domctl.u));
>          domctl.u.ext_vcpucontext.vcpu = i;
>          if ( xc_domctl(xch, &domctl) < 0 )
>          {
> --- a/tools/misc/xen-hvmctx.c
> +++ b/tools/misc/xen-hvmctx.c
> @@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
>             (unsigned long long) p.apic_assist);
>  }
> 
> +static void dump_vmce_vcpu(void)
> +{
> +    HVM_SAVE_TYPE(VMCE_VCPU) p;
> +    READ(p);
> +    printf("    VMCE_VCPU: nr_banks %u\n", p.nr_banks);
> +}
> +
>  int main(int argc, char **argv)
>  {
>      int entry, domid;
> @@ -449,6 +456,7 @@ int main(int argc, char **argv)
>          case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
>          case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain();
>          break; case HVM_SAVE_CODE(VIRIDIAN_VCPU):
> dump_viridian_vcpu(); break; +        case HVM_SAVE_CODE(VMCE_VCPU):
>          dump_vmce_vcpu(); break; case HVM_SAVE_CODE(END): break;
>          default:
>              printf(" ** Don't understand type %u: skipping\n",
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -3,6 +3,7 @@
>  #define _MCE_H
> 
>  #include <xen/init.h>
> +#include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <asm/types.h>
>  #include <asm/traps.h>
> @@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
>  u64 mce_cap_init(void);
>  extern int firstbank;
> 
> -int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
> -int intel_mce_wrmsr(uint32_t msr, uint64_t val);
> +int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t
> *val); +int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t
> val); 
> 
>  struct mcinfo_extended *intel_get_extended_msrs(
>      struct mcinfo_global *mig, struct mc_info *mi);
> @@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
> 
>  extern int vmce_init(struct cpuinfo_x86 *c);
> 
> -static inline int mce_vendor_bank_msr(uint32_t msr)
> +static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t
>  msr) {
>      if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> -         msr >= MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 +
> nr_mce_banks) ) +         msr >= MSR_IA32_MC0_CTL2 &&
> +         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
>            return 1;
>      return 0;
>  }
> 
> -static inline int mce_bank_msr(uint32_t msr)
> +static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
>  {
> -    if ( (msr >= MSR_IA32_MC0_CTL && msr <
> MSR_IA32_MCx_CTL(nr_mce_banks)) || 
> -        mce_vendor_bank_msr(msr) )
> +    if ( (msr >= MSR_IA32_MC0_CTL &&
> +          msr < MSR_IA32_MCx_CTL(v->arch.nr_vmce_banks)) ||
> +         mce_vendor_bank_msr(v, msr) )
>          return 1;
>      return 0;
>  }
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
>  }
> 
>  /* intel specific MCA MSR */
> -int intel_mce_wrmsr(uint32_t msr, uint64_t val)
> +int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
>  {
>      int ret = 0;
> 
> -    if (msr >= MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 +
> nr_mce_banks)) +    if ( msr >= MSR_IA32_MC0_CTL2 &&
> +         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
>      {
>          mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
>                   "Guest should not write this MSR!\n");
> @@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
>      return ret;
>  }
> 
> -int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
> +int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t
>  *val) {
>      int ret = 0;
> 
> -    if (msr >= MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 +
> nr_mce_banks)) +    if ( msr >= MSR_IA32_MC0_CTL2 &&
> +         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
>      {
>          mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
>                   "Guest should not read this MSR!\n");
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -10,6 +10,7 @@
>  #include <xen/delay.h>
>  #include <xen/smp.h>
>  #include <xen/mm.h>
> +#include <xen/hvm/save.h>
>  #include <asm/processor.h>
>  #include <public/sysctl.h>
>  #include <asm/system.h>
> @@ -61,21 +62,26 @@ void vmce_destroy_msr(struct domain *d)
>      dom_vmce(d) = NULL;
>  }
> 
> -static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t
> *val) +void vmce_init_vcpu(struct vcpu *v)
>  {
> -    int bank, ret = 1;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    v->arch.nr_vmce_banks = nr_mce_banks;
> +}
> +
> +static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr,
> uint64_t *val) +{
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -1;
> +    *val = 0;
> 
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        *val = vmce->mci_ctl[bank] &
> -            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> +        if ( bank < nr_mce_banks )
> +            *val = vmce->mci_ctl[bank] &
> +                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
>          mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
>                     bank, *val);
>          break;
> @@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_rdmsr(msr, val);
> +            ret = intel_mce_rdmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain
>   */
>  int vmce_rdmsr(uint32_t msr, uint64_t *val)
>  {
> -    struct domain *d = current->domain;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    const struct vcpu *cur = current;
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      *val = 0;
> 
> -    spin_lock(&dom_vmce(d)->lock);
> +    spin_lock(&vmce->lock);
> 
>      switch ( msr )
>      {
> @@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
>                     *val);
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val)
>          : 0; break;
>      }
> 
> -    spin_unlock(&dom_vmce(d)->lock);
> +    spin_unlock(&vmce->lock);
>      return ret;
>  }
> 
> -static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
> +static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
>  {
> -    int bank, ret = 1;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry = NULL;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -EINVAL;
> -
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        vmce->mci_ctl[bank] = val;
> +        if ( bank < nr_mce_banks )
> +            vmce->mci_ctl[bank] = val;
>          break;
>      case MSR_IA32_MC0_STATUS:
>          /* Give the first entry of the list, it corresponds to
> current @@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain
>           * the guest, this node will be deleted.
>           * Only error bank is written. Non-error banks simply return.
>           */
> -        if ( !list_empty(&dom_vmce(d)->impact_header) )
> +        if ( !list_empty(&vmce->impact_header) )
>          {
> -            entry = list_entry(dom_vmce(d)->impact_header.next,
> +            entry = list_entry(vmce->impact_header.next,
>                                 struct bank_entry, list);
>              if ( entry->bank == bank )
>                  entry->mci_status = val;
> @@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_wrmsr(msr, val);
> +            ret = intel_mce_wrmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain
>   */
>  int vmce_wrmsr(u32 msr, u64 val)
>  {
> -    struct domain *d = current->domain;
> +    struct vcpu *cur = current;
>      struct bank_entry *entry = NULL;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      if ( !g_mcg_cap )
> @@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          vmce->mcg_status = val;
>          mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n",
>          val); /* For HVM guest, this is the point for deleting vMCE
> injection node */ -        if ( d->is_hvm && (vmce->nr_injection > 0)
> ) +        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
>          {
>              vmce->nr_injection--; /* Should be 0 */
>              if ( !list_empty(&vmce->impact_header) )
> @@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          ret = -1;
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val)
>          : 0; break;
>      }
> 
> @@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
>      return ret;
>  }
> 
> +static int vmce_save_vcpu_ctxt(struct domain *d,
> hvm_domain_context_t *h) +{
> +    struct vcpu *v;
> +    int err = 0;
> +
> +    for_each_vcpu( d, v ) {
> +        struct hvm_vmce_vcpu ctxt = {
> +            .nr_banks = v->arch.nr_vmce_banks
> +        };
> +
> +        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> +        if ( err )
> +            break;
> +    }
> +
> +    return err;
> +}
> +
> +static int vmce_load_vcpu_ctxt(struct domain *d,
> hvm_domain_context_t *h) +{
> +    unsigned int vcpuid = hvm_load_instance(h);
> +    struct vcpu *v;
> +    struct hvm_vmce_vcpu ctxt;
> +    int err;
> +
> +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> +    {
> +        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n",
> vcpuid); +        return -EINVAL;
> +    }
> +
> +    err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
> +    if ( !err )
> +        v->arch.nr_vmce_banks = ctxt.nr_banks;
> +
> +    return err;
> +}
> +
> +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> +                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
> +
>  int inject_vmce(struct domain *d)
>  {
>      int cpu = smp_processor_id();
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
> 
>      v->arch.pv_vcpu.ctrlreg[4] =
> real_cr4_to_pv_guest_cr4(mmu_cr4_features); 
> 
> +    vmce_init_vcpu(v);
> +
>      rc = is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
>   done:
>      if ( rc )
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1027,11 +1027,12 @@ long arch_do_domctl(
>                  evc->syscall32_callback_eip    = 0;
>                  evc->syscall32_disables_events = 0;
>              }
> +            evc->nr_mce_banks = v->arch.nr_vmce_banks;
>          }
>          else
>          {
>              ret = -EINVAL;
> -            if ( evc->size != sizeof(*evc) )
> +            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
>                  goto ext_vcpucontext_out;
>  #ifdef __x86_64__
>              if ( !is_hvm_domain(d) )
> @@ -1059,6 +1060,16 @@ long arch_do_domctl(
>                   (evc->syscall32_callback_cs & ~3) ||
>                   evc->syscall32_callback_eip )
>                  goto ext_vcpucontext_out;
> +
> +            if ( evc->size >= offsetof(typeof(*evc),
> mbz[ARRAY_SIZE(evc->mbz)]) ) +            {
> +                unsigned int i;
> +
> +                for ( i = 0; i < ARRAY_SIZE(evc->mbz); ++i )
> +                    if ( evc->mbz[i] )
> +                        goto ext_vcpucontext_out;
> +                v->arch.nr_vmce_banks = evc->nr_mce_banks;
> +            }
>          }
> 
>          ret = 0;
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -488,6 +488,8 @@ struct arch_vcpu
>      /* This variable determines whether nonlazy extended state has
>       been used, * and thus should be saved/restored. */
>      bool_t nonlazy_xstate_used;
> +
> +    uint8_t nr_vmce_banks;
> 
>      struct paging_vcpu paging;
> 
> --- a/xen/include/asm-x86/mce.h
> +++ b/xen/include/asm-x86/mce.h
> @@ -28,6 +28,7 @@ struct domain_mca_msrs
>  /* Guest vMCE MSRs virtualization */
>  extern int vmce_init_msr(struct domain *d);
>  extern void vmce_destroy_msr(struct domain *d);
> +extern void vmce_init_vcpu(struct vcpu *);
>  extern int vmce_wrmsr(uint32_t msr, uint64_t val);
>  extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
> 
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
> 
>  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct
> hvm_viridian_vcpu_context); 
> 
> +struct hvm_vmce_vcpu {
> +    uint8_t nr_banks;
> +};
> +
> +DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
> +
>  /*
>   * Largest type-code in use
>   */
> -#define HVM_SAVE_CODE_MAX 17
> +#define HVM_SAVE_CODE_MAX 18
> 
>  #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
>      uint32_t         vcpu;
>      /*
>       * SET: Size of struct (IN)
> -     * GET: Size of struct (OUT)
> +     * GET: Size of struct (OUT, up to 128 bytes)
>       */
>      uint32_t         size;
>  #if defined(__i386__) || defined(__x86_64__)
> @@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
>      uint16_t         sysenter_callback_cs;
>      uint8_t          syscall32_disables_events;
>      uint8_t          sysenter_disables_events;
> +    uint8_t          nr_mce_banks;
> +    /* This array can be split and used for future extension. */
> +    /* It is there just to grow the structure beyond 4.1's size. */
> +    uint8_t          mbz[9];
>  #endif
>  };
>  typedef struct xen_domctl_ext_vcpucontext
> xen_domctl_ext_vcpucontext_t; 

Jan,

How about use static bank size, say 256, which architecture (IA32_MCG_CAP MSR) defined max bank number?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:18:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07: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.xensource.com>)
	id 1RtDPU-0003FL-VH; Fri, 03 Feb 2012 07:18:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RtDPS-0003FD-Qa
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:18:15 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328253487!13529104!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIxODY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14713 invoked from network); 3 Feb 2012 07:18:07 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	3 Feb 2012 07:18:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 02 Feb 2012 23:18:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105798788"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 02 Feb 2012 23:18:04 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 3 Feb 2012 15:18:02 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 3 Feb 2012 15:18:01 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 15:18:01 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, George Dunlap <george.dunlap@citrix.com>, 
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] vMCE vs migration
Thread-Index: AQHM2b+3mIIv8qUEcUC7dztSHU+i2ZYazHkAgAAK9YCAA4VsAIAGFO4AgAZhOvA=
Date: Fri, 3 Feb 2012 07:18:00 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
In-Reply-To: <4F26AD7C020000780006FDC1@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: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Jiang,
	Yunhong" <yunhong.jiang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com>
>>>> wrote: 
>> On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>>>>>> On 24.01.12 at 11:29, George Dunlap
>>>>>> <George.Dunlap@eu.citrix.com> wrote: 
>>>> On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com>
>>>> wrote: 
>>>>> x86's vMCE implementation lets a guest know of as many MCE
>>>>> reporting banks as there are in the host. While a PV guest could
>>>>> be expected to deal with this number changing (particularly
>>>>> decreasing) during migration (not currently handled anywhere
>>>>> afaict), for HVM guests this is certainly wrong. 
>>>>> 
>>>>> At least to me it isn't, however, clear how to properly handle
>>>>> this. The easiest would appear to be to save and restore the
>>>>> number of banks 
>>>>> the guest was made believe it can access, making vmce_{rd,wr}msr()
>>>>> silently tolerate accesses between the host and guest values.
>>>> 
>>>> We ran into this in the XS 6.0 release as well.  I think that the
>>>> ideal thing to do would be to have a parameter that can be set at
>>>> boot, to say how many vMCE banks a guest has, defaulting to the
>>>> number of MCE banks on the host.  This parameter would be
>>>> preserved across migration.  Ideally, a pool-aware toolstack like
>>>> xapi would then set this value to be the value of the host in the
>>>> pool with the largest number of banks, allowing a guest to access
>>>> all the banks on any host to which it migrates. 
>>>> 
>>>> What do you think?
>>> 
>>> That sounds like the way to go.
>> 
>> So should we put this on IanC's to-do-be-done list?  Are you going to
>> put it on your to-do list? :-)
> 
> Below/attached a draft patch (compile tested only), handling save/
> restore of the bank count, but not allowing for a config setting to
> specify its initial value (yet).
> 
> Jan
> 
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
> 
>          domctl.cmd = XEN_DOMCTL_get_ext_vcpucontext;
>          domctl.domain = dom;
> +        memset(&domctl.u, 0, sizeof(domctl.u));
>          domctl.u.ext_vcpucontext.vcpu = i;
>          if ( xc_domctl(xch, &domctl) < 0 )
>          {
> --- a/tools/misc/xen-hvmctx.c
> +++ b/tools/misc/xen-hvmctx.c
> @@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
>             (unsigned long long) p.apic_assist);
>  }
> 
> +static void dump_vmce_vcpu(void)
> +{
> +    HVM_SAVE_TYPE(VMCE_VCPU) p;
> +    READ(p);
> +    printf("    VMCE_VCPU: nr_banks %u\n", p.nr_banks);
> +}
> +
>  int main(int argc, char **argv)
>  {
>      int entry, domid;
> @@ -449,6 +456,7 @@ int main(int argc, char **argv)
>          case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
>          case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain();
>          break; case HVM_SAVE_CODE(VIRIDIAN_VCPU):
> dump_viridian_vcpu(); break; +        case HVM_SAVE_CODE(VMCE_VCPU):
>          dump_vmce_vcpu(); break; case HVM_SAVE_CODE(END): break;
>          default:
>              printf(" ** Don't understand type %u: skipping\n",
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -3,6 +3,7 @@
>  #define _MCE_H
> 
>  #include <xen/init.h>
> +#include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <asm/types.h>
>  #include <asm/traps.h>
> @@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
>  u64 mce_cap_init(void);
>  extern int firstbank;
> 
> -int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
> -int intel_mce_wrmsr(uint32_t msr, uint64_t val);
> +int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t
> *val); +int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t
> val); 
> 
>  struct mcinfo_extended *intel_get_extended_msrs(
>      struct mcinfo_global *mig, struct mc_info *mi);
> @@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
> 
>  extern int vmce_init(struct cpuinfo_x86 *c);
> 
> -static inline int mce_vendor_bank_msr(uint32_t msr)
> +static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t
>  msr) {
>      if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> -         msr >= MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 +
> nr_mce_banks) ) +         msr >= MSR_IA32_MC0_CTL2 &&
> +         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
>            return 1;
>      return 0;
>  }
> 
> -static inline int mce_bank_msr(uint32_t msr)
> +static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
>  {
> -    if ( (msr >= MSR_IA32_MC0_CTL && msr <
> MSR_IA32_MCx_CTL(nr_mce_banks)) || 
> -        mce_vendor_bank_msr(msr) )
> +    if ( (msr >= MSR_IA32_MC0_CTL &&
> +          msr < MSR_IA32_MCx_CTL(v->arch.nr_vmce_banks)) ||
> +         mce_vendor_bank_msr(v, msr) )
>          return 1;
>      return 0;
>  }
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
>  }
> 
>  /* intel specific MCA MSR */
> -int intel_mce_wrmsr(uint32_t msr, uint64_t val)
> +int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
>  {
>      int ret = 0;
> 
> -    if (msr >= MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 +
> nr_mce_banks)) +    if ( msr >= MSR_IA32_MC0_CTL2 &&
> +         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
>      {
>          mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
>                   "Guest should not write this MSR!\n");
> @@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
>      return ret;
>  }
> 
> -int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
> +int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t
>  *val) {
>      int ret = 0;
> 
> -    if (msr >= MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 +
> nr_mce_banks)) +    if ( msr >= MSR_IA32_MC0_CTL2 &&
> +         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
>      {
>          mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
>                   "Guest should not read this MSR!\n");
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -10,6 +10,7 @@
>  #include <xen/delay.h>
>  #include <xen/smp.h>
>  #include <xen/mm.h>
> +#include <xen/hvm/save.h>
>  #include <asm/processor.h>
>  #include <public/sysctl.h>
>  #include <asm/system.h>
> @@ -61,21 +62,26 @@ void vmce_destroy_msr(struct domain *d)
>      dom_vmce(d) = NULL;
>  }
> 
> -static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t
> *val) +void vmce_init_vcpu(struct vcpu *v)
>  {
> -    int bank, ret = 1;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    v->arch.nr_vmce_banks = nr_mce_banks;
> +}
> +
> +static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr,
> uint64_t *val) +{
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -1;
> +    *val = 0;
> 
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        *val = vmce->mci_ctl[bank] &
> -            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> +        if ( bank < nr_mce_banks )
> +            *val = vmce->mci_ctl[bank] &
> +                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
>          mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
>                     bank, *val);
>          break;
> @@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_rdmsr(msr, val);
> +            ret = intel_mce_rdmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain
>   */
>  int vmce_rdmsr(uint32_t msr, uint64_t *val)
>  {
> -    struct domain *d = current->domain;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    const struct vcpu *cur = current;
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      *val = 0;
> 
> -    spin_lock(&dom_vmce(d)->lock);
> +    spin_lock(&vmce->lock);
> 
>      switch ( msr )
>      {
> @@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
>                     *val);
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val)
>          : 0; break;
>      }
> 
> -    spin_unlock(&dom_vmce(d)->lock);
> +    spin_unlock(&vmce->lock);
>      return ret;
>  }
> 
> -static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
> +static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
>  {
> -    int bank, ret = 1;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry = NULL;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -EINVAL;
> -
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        vmce->mci_ctl[bank] = val;
> +        if ( bank < nr_mce_banks )
> +            vmce->mci_ctl[bank] = val;
>          break;
>      case MSR_IA32_MC0_STATUS:
>          /* Give the first entry of the list, it corresponds to
> current @@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain
>           * the guest, this node will be deleted.
>           * Only error bank is written. Non-error banks simply return.
>           */
> -        if ( !list_empty(&dom_vmce(d)->impact_header) )
> +        if ( !list_empty(&vmce->impact_header) )
>          {
> -            entry = list_entry(dom_vmce(d)->impact_header.next,
> +            entry = list_entry(vmce->impact_header.next,
>                                 struct bank_entry, list);
>              if ( entry->bank == bank )
>                  entry->mci_status = val;
> @@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_wrmsr(msr, val);
> +            ret = intel_mce_wrmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain
>   */
>  int vmce_wrmsr(u32 msr, u64 val)
>  {
> -    struct domain *d = current->domain;
> +    struct vcpu *cur = current;
>      struct bank_entry *entry = NULL;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      if ( !g_mcg_cap )
> @@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          vmce->mcg_status = val;
>          mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n",
>          val); /* For HVM guest, this is the point for deleting vMCE
> injection node */ -        if ( d->is_hvm && (vmce->nr_injection > 0)
> ) +        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
>          {
>              vmce->nr_injection--; /* Should be 0 */
>              if ( !list_empty(&vmce->impact_header) )
> @@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          ret = -1;
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val)
>          : 0; break;
>      }
> 
> @@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
>      return ret;
>  }
> 
> +static int vmce_save_vcpu_ctxt(struct domain *d,
> hvm_domain_context_t *h) +{
> +    struct vcpu *v;
> +    int err = 0;
> +
> +    for_each_vcpu( d, v ) {
> +        struct hvm_vmce_vcpu ctxt = {
> +            .nr_banks = v->arch.nr_vmce_banks
> +        };
> +
> +        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> +        if ( err )
> +            break;
> +    }
> +
> +    return err;
> +}
> +
> +static int vmce_load_vcpu_ctxt(struct domain *d,
> hvm_domain_context_t *h) +{
> +    unsigned int vcpuid = hvm_load_instance(h);
> +    struct vcpu *v;
> +    struct hvm_vmce_vcpu ctxt;
> +    int err;
> +
> +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> +    {
> +        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n",
> vcpuid); +        return -EINVAL;
> +    }
> +
> +    err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
> +    if ( !err )
> +        v->arch.nr_vmce_banks = ctxt.nr_banks;
> +
> +    return err;
> +}
> +
> +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> +                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
> +
>  int inject_vmce(struct domain *d)
>  {
>      int cpu = smp_processor_id();
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
> 
>      v->arch.pv_vcpu.ctrlreg[4] =
> real_cr4_to_pv_guest_cr4(mmu_cr4_features); 
> 
> +    vmce_init_vcpu(v);
> +
>      rc = is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
>   done:
>      if ( rc )
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1027,11 +1027,12 @@ long arch_do_domctl(
>                  evc->syscall32_callback_eip    = 0;
>                  evc->syscall32_disables_events = 0;
>              }
> +            evc->nr_mce_banks = v->arch.nr_vmce_banks;
>          }
>          else
>          {
>              ret = -EINVAL;
> -            if ( evc->size != sizeof(*evc) )
> +            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
>                  goto ext_vcpucontext_out;
>  #ifdef __x86_64__
>              if ( !is_hvm_domain(d) )
> @@ -1059,6 +1060,16 @@ long arch_do_domctl(
>                   (evc->syscall32_callback_cs & ~3) ||
>                   evc->syscall32_callback_eip )
>                  goto ext_vcpucontext_out;
> +
> +            if ( evc->size >= offsetof(typeof(*evc),
> mbz[ARRAY_SIZE(evc->mbz)]) ) +            {
> +                unsigned int i;
> +
> +                for ( i = 0; i < ARRAY_SIZE(evc->mbz); ++i )
> +                    if ( evc->mbz[i] )
> +                        goto ext_vcpucontext_out;
> +                v->arch.nr_vmce_banks = evc->nr_mce_banks;
> +            }
>          }
> 
>          ret = 0;
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -488,6 +488,8 @@ struct arch_vcpu
>      /* This variable determines whether nonlazy extended state has
>       been used, * and thus should be saved/restored. */
>      bool_t nonlazy_xstate_used;
> +
> +    uint8_t nr_vmce_banks;
> 
>      struct paging_vcpu paging;
> 
> --- a/xen/include/asm-x86/mce.h
> +++ b/xen/include/asm-x86/mce.h
> @@ -28,6 +28,7 @@ struct domain_mca_msrs
>  /* Guest vMCE MSRs virtualization */
>  extern int vmce_init_msr(struct domain *d);
>  extern void vmce_destroy_msr(struct domain *d);
> +extern void vmce_init_vcpu(struct vcpu *);
>  extern int vmce_wrmsr(uint32_t msr, uint64_t val);
>  extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
> 
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
> 
>  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct
> hvm_viridian_vcpu_context); 
> 
> +struct hvm_vmce_vcpu {
> +    uint8_t nr_banks;
> +};
> +
> +DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
> +
>  /*
>   * Largest type-code in use
>   */
> -#define HVM_SAVE_CODE_MAX 17
> +#define HVM_SAVE_CODE_MAX 18
> 
>  #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
>      uint32_t         vcpu;
>      /*
>       * SET: Size of struct (IN)
> -     * GET: Size of struct (OUT)
> +     * GET: Size of struct (OUT, up to 128 bytes)
>       */
>      uint32_t         size;
>  #if defined(__i386__) || defined(__x86_64__)
> @@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
>      uint16_t         sysenter_callback_cs;
>      uint8_t          syscall32_disables_events;
>      uint8_t          sysenter_disables_events;
> +    uint8_t          nr_mce_banks;
> +    /* This array can be split and used for future extension. */
> +    /* It is there just to grow the structure beyond 4.1's size. */
> +    uint8_t          mbz[9];
>  #endif
>  };
>  typedef struct xen_domctl_ext_vcpucontext
> xen_domctl_ext_vcpucontext_t; 

Jan,

How about use static bank size, say 256, which architecture (IA32_MCG_CAP MSR) defined max bank number?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:25:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07: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.xensource.com>)
	id 1RtDWM-0003SK-4s; Fri, 03 Feb 2012 07:25:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1RtDWK-0003SC-Jw
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:25:20 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328253913!12739145!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17379 invoked from network); 3 Feb 2012 07:25:14 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 07:25:14 -0000
Received: by werb14 with SMTP id b14so6586723wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 23:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=skVSM1s84q9kPLuEmJ5GuiG4ZL3ggexm039BXpks8cg=;
	b=xP7Z37QSAlBFlNLu1hTm0gxKDR/x4seSvbyg8shrCSt0VRCKQesIav6Awp0IKig6Nv
	IL63gtTuMDNTBUvewtnvZTbzpExgTmaJth42H9+uHiDU6V5wXM010QaN7AelbHksjlWk
	8u9z8ryYl+u4RPOVvm/IR8FPm6kHfAAuO9LBU=
Received: by 10.216.131.91 with SMTP id l69mr5781581wei.28.1328253913606;
	Thu, 02 Feb 2012 23:25:13 -0800 (PST)
Received: from [192.168.1.97] (122.237.66.86.rev.sfr.net. [86.66.237.122])
	by mx.google.com with ESMTPS id ho4sm4566078wib.3.2012.02.02.23.25.11
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 23:25:12 -0800 (PST)
Message-ID: <1328253910.2480.41.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 03 Feb 2012 08:25:10 +0100
In-Reply-To: <1328251092.13189.29.camel@dagon.hellion.org.uk>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
	<1328251092.13189.29.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgdmVuZHJlZGkgMDMgZsOpdnJpZXIgMjAxMiDDoCAwNjozOCArMDAwMCwgSWFuIENhbXBiZWxs
IGEgw6ljcml0IDoKPiBPbiBUaHUsIDIwMTItMDItMDIgYXQgMjI6NTIgKzAwMDAsIFBhdWwgR29y
dG1ha2VyIHdyb3RlOgo+ID4gT24gVGh1LCBGZWIgMiwgMjAxMiBhdCAzOjUwIFBNLCBJYW4gQ2Ft
cGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPiA+ID4gT24gVGh1LCAyMDEy
LTAyLTAyIGF0IDIwOjM0ICswMDAwLCBFcmljIER1bWF6ZXQgd3JvdGU6Cj4gPiAKPiA+IFsuLi5d
Cj4gPiAKPiA+ID4KPiA+ID4gSSBkb24ndCB0aGluayBpdCBpcyBhdCBhbGwgdW5yZWFzb25hYmxl
IHRvIGFzayBmb3IgYnVnIGZpeGVzIGJ1dCBpbiB0aGlzCj4gPiA+IGNhc2UgV2VpJ3Mgc2VyaWVz
IGlzIHJlbW92aW5nIHRoZSBjb2RlIGluIHF1ZXN0aW9uICh3aGljaCB3b3VsZCBhbHNvCj4gPiA+
IHVuZG91YnRlZGx5IGZpeCB0aGUgYnVnKS4KPiA+ID4KPiA+ID4gQXMgaXQgaGFwcGVucyB0aGUg
Zml4IHR1cm5zIG91dCB0byBiZSBzaW1wbGUgYnV0IGlmIGl0IHdlcmUgY29tcGxleCBJCj4gPiA+
IHdvdWxkIHBlcmhhcHMgaGF2ZSBkaXNhZ3JlZWQgbW9yZSBzdHJvbmdseSBhYm91dCBzcGVuZGlu
ZyBlZmZvcnQgZml4aW5nCj4gPiA+IGNvZGUgdGhhdCBpcyByZW1vdmVkIDIgcGF0Y2hlcyBsYXRl
ciwgYWx0aG91Z2ggb2J2aW91c2x5IHRoYXQgd291bGQgaGF2ZQo+ID4gPiBkZXBlbmRlZCBvbiB0
aGUgc3BlY2lmaWNzIG9mIHRoZSBmaXggaW4gdGhhdCBjYXNlLgo+ID4gCj4gPiBMb3RzIG9mIHBl
b3BsZSBhcmUgcmVseWluZyBvbiBnaXQgYmlzZWN0LiAgSWYgeW91IGludHJvZHVjZSBidWlsZCBm
YWlsdXJlcwo+ID4gb3Iga25vd24gYnVncyBpbnRvIGFueSBwb2ludCBpbiBoaXN0b3J5LCB5b3Ug
dGFrZSBhd2F5IGZyb20gdGhlIHZhbHVlCj4gPiBpbiBnaXQgYmlzZWN0LiAgU3VyZSwgaXQgaGFw
cGVucyBieSBhY2NpZGVudCwgYnV0IGl0IHNob3VsZG4ndCBldmVyIGJlCj4gPiBkb25lIGtub3dp
bmdseS4KPiAKPiBTdXJlLiBJbiB0aGlzIGNhc2UgdGhlIGJ1ZyBoYXMgYmVlbiB0aGVyZSBzaW5j
ZSAyLjYuMzksIGl0IGlzbid0Cj4gaW50cm9kdWNlZCBieSB0aGlzIHNlcmllcy4KPiAKCldlIGFy
ZSBzdHVjayByaWdodCBub3cgd2l0aCBhIGJ1ZyBpbnRyb2R1Y2VkIGluIDIuNi4zOSwgKElQIHJl
ZGlyZWN0cyksCmFuZCBiZWNhdXNlIGZpeCB3YXMgZG9uZSBpbiAzLjEsIHdlIGFyZSB1bmFibGUg
dG8gcHJvdmlkZSBhIGZpeCBmbwpzdGFibGUgMy4wIGtlcm5lbC4KClNvbWV0aGluZyB0aGF0IHRh
a2VzIDE1IG1pbnV0ZXMgdG8gZml4IG5vdywgY2FuIHRha2Ugc2V2ZXJhbCBkYXlzIG9mCndvcmsg
bGF0ZXIuCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:25:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07: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.xensource.com>)
	id 1RtDWM-0003SK-4s; Fri, 03 Feb 2012 07:25:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1RtDWK-0003SC-Jw
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:25:20 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328253913!12739145!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17379 invoked from network); 3 Feb 2012 07:25:14 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 07:25:14 -0000
Received: by werb14 with SMTP id b14so6586723wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 23:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=skVSM1s84q9kPLuEmJ5GuiG4ZL3ggexm039BXpks8cg=;
	b=xP7Z37QSAlBFlNLu1hTm0gxKDR/x4seSvbyg8shrCSt0VRCKQesIav6Awp0IKig6Nv
	IL63gtTuMDNTBUvewtnvZTbzpExgTmaJth42H9+uHiDU6V5wXM010QaN7AelbHksjlWk
	8u9z8ryYl+u4RPOVvm/IR8FPm6kHfAAuO9LBU=
Received: by 10.216.131.91 with SMTP id l69mr5781581wei.28.1328253913606;
	Thu, 02 Feb 2012 23:25:13 -0800 (PST)
Received: from [192.168.1.97] (122.237.66.86.rev.sfr.net. [86.66.237.122])
	by mx.google.com with ESMTPS id ho4sm4566078wib.3.2012.02.02.23.25.11
	(version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 23:25:12 -0800 (PST)
Message-ID: <1328253910.2480.41.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 03 Feb 2012 08:25:10 +0100
In-Reply-To: <1328251092.13189.29.camel@dagon.hellion.org.uk>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
	<1328251092.13189.29.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TGUgdmVuZHJlZGkgMDMgZsOpdnJpZXIgMjAxMiDDoCAwNjozOCArMDAwMCwgSWFuIENhbXBiZWxs
IGEgw6ljcml0IDoKPiBPbiBUaHUsIDIwMTItMDItMDIgYXQgMjI6NTIgKzAwMDAsIFBhdWwgR29y
dG1ha2VyIHdyb3RlOgo+ID4gT24gVGh1LCBGZWIgMiwgMjAxMiBhdCAzOjUwIFBNLCBJYW4gQ2Ft
cGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPiA+ID4gT24gVGh1LCAyMDEy
LTAyLTAyIGF0IDIwOjM0ICswMDAwLCBFcmljIER1bWF6ZXQgd3JvdGU6Cj4gPiAKPiA+IFsuLi5d
Cj4gPiAKPiA+ID4KPiA+ID4gSSBkb24ndCB0aGluayBpdCBpcyBhdCBhbGwgdW5yZWFzb25hYmxl
IHRvIGFzayBmb3IgYnVnIGZpeGVzIGJ1dCBpbiB0aGlzCj4gPiA+IGNhc2UgV2VpJ3Mgc2VyaWVz
IGlzIHJlbW92aW5nIHRoZSBjb2RlIGluIHF1ZXN0aW9uICh3aGljaCB3b3VsZCBhbHNvCj4gPiA+
IHVuZG91YnRlZGx5IGZpeCB0aGUgYnVnKS4KPiA+ID4KPiA+ID4gQXMgaXQgaGFwcGVucyB0aGUg
Zml4IHR1cm5zIG91dCB0byBiZSBzaW1wbGUgYnV0IGlmIGl0IHdlcmUgY29tcGxleCBJCj4gPiA+
IHdvdWxkIHBlcmhhcHMgaGF2ZSBkaXNhZ3JlZWQgbW9yZSBzdHJvbmdseSBhYm91dCBzcGVuZGlu
ZyBlZmZvcnQgZml4aW5nCj4gPiA+IGNvZGUgdGhhdCBpcyByZW1vdmVkIDIgcGF0Y2hlcyBsYXRl
ciwgYWx0aG91Z2ggb2J2aW91c2x5IHRoYXQgd291bGQgaGF2ZQo+ID4gPiBkZXBlbmRlZCBvbiB0
aGUgc3BlY2lmaWNzIG9mIHRoZSBmaXggaW4gdGhhdCBjYXNlLgo+ID4gCj4gPiBMb3RzIG9mIHBl
b3BsZSBhcmUgcmVseWluZyBvbiBnaXQgYmlzZWN0LiAgSWYgeW91IGludHJvZHVjZSBidWlsZCBm
YWlsdXJlcwo+ID4gb3Iga25vd24gYnVncyBpbnRvIGFueSBwb2ludCBpbiBoaXN0b3J5LCB5b3Ug
dGFrZSBhd2F5IGZyb20gdGhlIHZhbHVlCj4gPiBpbiBnaXQgYmlzZWN0LiAgU3VyZSwgaXQgaGFw
cGVucyBieSBhY2NpZGVudCwgYnV0IGl0IHNob3VsZG4ndCBldmVyIGJlCj4gPiBkb25lIGtub3dp
bmdseS4KPiAKPiBTdXJlLiBJbiB0aGlzIGNhc2UgdGhlIGJ1ZyBoYXMgYmVlbiB0aGVyZSBzaW5j
ZSAyLjYuMzksIGl0IGlzbid0Cj4gaW50cm9kdWNlZCBieSB0aGlzIHNlcmllcy4KPiAKCldlIGFy
ZSBzdHVjayByaWdodCBub3cgd2l0aCBhIGJ1ZyBpbnRyb2R1Y2VkIGluIDIuNi4zOSwgKElQIHJl
ZGlyZWN0cyksCmFuZCBiZWNhdXNlIGZpeCB3YXMgZG9uZSBpbiAzLjEsIHdlIGFyZSB1bmFibGUg
dG8gcHJvdmlkZSBhIGZpeCBmbwpzdGFibGUgMy4wIGtlcm5lbC4KClNvbWV0aGluZyB0aGF0IHRh
a2VzIDE1IG1pbnV0ZXMgdG8gZml4IG5vdywgY2FuIHRha2Ugc2V2ZXJhbCBkYXlzIG9mCndvcmsg
bGF0ZXIuCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:53:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDxi-0004lU-MG; Fri, 03 Feb 2012 07:53:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtDxh-0004lP-9r
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:53:37 +0000
Received: from [85.158.138.51:55809] by server-4.bemta-3.messagelabs.com id
	91/79-07654-0829B2F4; Fri, 03 Feb 2012 07:53:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328255615!7606887!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18836 invoked from network); 3 Feb 2012 07:53:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 07:53:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 07:53:34 +0000
Message-Id: <4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 07:53:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
In-Reply-To: <4F2AF21C.3090305@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.02.12 at 21:29, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/02/12 08:22, Jan Beulich wrote:
>> As I was about to apply this to my local tree to give it a try, I had
>> to realize that the microcode integration is still not correct: There
>> is (at least from an abstract perspective) no guarantee for
>> cpu_request_microcode() to be called on all CPUs, yet you want
>> svm_host_osvw_init() to be re-run on all of them. If you choose
>> to not deal with this in a formally correct way, it should be stated
>> so in a code comment (to lower the risk of surprises when someone
>> touches that code) that this is not possible in practice because
>> collect_cpu_info() won't currently fail for CPUs of interest.
> 
> What if svm_host_osvw_init() is called from collect_cpu_info()? There 
> may be cases when svm_host_osvw_init() is called multiple times for the 
> same cpu but that should be harmless (and the routine will be renamed to 
> svm_host_osvw_update()).

Wouldn't that result in workaround bits that might get cleared with
the pending microcode update to get (and remain) set, as they're
being or-ed together over all invocations of the function after any
svm_host_osvw_reset()?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 07:53:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 07:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtDxi-0004lU-MG; Fri, 03 Feb 2012 07:53:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtDxh-0004lP-9r
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 07:53:37 +0000
Received: from [85.158.138.51:55809] by server-4.bemta-3.messagelabs.com id
	91/79-07654-0829B2F4; Fri, 03 Feb 2012 07:53:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328255615!7606887!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18836 invoked from network); 3 Feb 2012 07:53:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 07:53:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 07:53:34 +0000
Message-Id: <4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 07:53:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
In-Reply-To: <4F2AF21C.3090305@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 02.02.12 at 21:29, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/02/12 08:22, Jan Beulich wrote:
>> As I was about to apply this to my local tree to give it a try, I had
>> to realize that the microcode integration is still not correct: There
>> is (at least from an abstract perspective) no guarantee for
>> cpu_request_microcode() to be called on all CPUs, yet you want
>> svm_host_osvw_init() to be re-run on all of them. If you choose
>> to not deal with this in a formally correct way, it should be stated
>> so in a code comment (to lower the risk of surprises when someone
>> touches that code) that this is not possible in practice because
>> collect_cpu_info() won't currently fail for CPUs of interest.
> 
> What if svm_host_osvw_init() is called from collect_cpu_info()? There 
> may be cases when svm_host_osvw_init() is called multiple times for the 
> same cpu but that should be harmless (and the routine will be renamed to 
> svm_host_osvw_update()).

Wouldn't that result in workaround bits that might get cleared with
the pending microcode update to get (and remain) set, as they're
being or-ed together over all invocations of the function after any
svm_host_osvw_reset()?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08: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.xensource.com>)
	id 1RtE6D-0005RP-H9; Fri, 03 Feb 2012 08:02:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtE6C-0005RK-Df
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:02:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328256137!12691563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4925 invoked from network); 3 Feb 2012 08:02:17 -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;
	3 Feb 2012 08:02:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10458715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:02:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:02:17 +0000
Message-ID: <1328256136.13189.34.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 3 Feb 2012 08:02:16 +0000
In-Reply-To: <1328253910.2480.41.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
	<1328251092.13189.29.camel@dagon.hellion.org.uk>
	<1328253910.2480.41.camel@edumazet-laptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:25 +0000, Eric Dumazet wrote:
> Le vendredi 03 f=E9vrier 2012 =E0 06:38 +0000, Ian Campbell a =E9crit :
> > On Thu, 2012-02-02 at 22:52 +0000, Paul Gortmaker wrote:
> > > On Thu, Feb 2, 2012 at 3:50 PM, Ian Campbell <Ian.Campbell@citrix.com=
> wrote:
> > > > On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:
> > > =

> > > [...]
> > > =

> > > >
> > > > I don't think it is at all unreasonable to ask for bug fixes but in=
 this
> > > > case Wei's series is removing the code in question (which would also
> > > > undoubtedly fix the bug).
> > > >
> > > > As it happens the fix turns out to be simple but if it were complex=
 I
> > > > would perhaps have disagreed more strongly about spending effort fi=
xing
> > > > code that is removed 2 patches later, although obviously that would=
 have
> > > > depended on the specifics of the fix in that case.
> > > =

> > > Lots of people are relying on git bisect.  If you introduce build fai=
lures
> > > or known bugs into any point in history, you take away from the value
> > > in git bisect.  Sure, it happens by accident, but it shouldn't ever be
> > > done knowingly.
> > =

> > Sure. In this case the bug has been there since 2.6.39, it isn't
> > introduced by this series.
> > =

> =

> We are stuck right now with a bug introduced in 2.6.39, (IP redirects),
> and because fix was done in 3.1, we are unable to provide a fix fo
> stable 3.0 kernel.
> =

> Something that takes 15 minutes to fix now, can take several days of
> work later.

Sure.

Here is the patch. I've compile tested it but not run it yet since I'm
supposed to be packing for a trip, I'll be back on Wednesday. It seems
straight forward enough though.

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

>From 6f3d3068f6e049c2d810f9fc667d57667bea77dc Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 3 Feb 2012 07:47:23 +0000
Subject: [PATCH] xen: netback: do not bind netback threads to specific CPUs

netback_init does not take proper account of which CPUs is online. However =
we
don't require a thread per CPU, just a pool of worker threads, of which the
number of CPUs at start of day is as good a number as any.

Therefore do not bind netback threads to particular CPUs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Wei Lui <wei.lui2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/ne=
tback.c
index 59effac..31ad3ee 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,8 +1670,6 @@ static int __init netback_init(void)
 			goto failed_init;
 		}
 =

-		kthread_bind(netbk->task, group);
-
 		INIT_LIST_HEAD(&netbk->net_schedule_list);
 =

 		spin_lock_init(&netbk->net_schedule_list_lock);
-- =

1.7.2.5




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08: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.xensource.com>)
	id 1RtE6D-0005RP-H9; Fri, 03 Feb 2012 08:02:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtE6C-0005RK-Df
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:02:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328256137!12691563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4925 invoked from network); 3 Feb 2012 08:02:17 -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;
	3 Feb 2012 08:02:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10458715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:02:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:02:17 +0000
Message-ID: <1328256136.13189.34.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 3 Feb 2012 08:02:16 +0000
In-Reply-To: <1328253910.2480.41.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
	<1328251092.13189.29.camel@dagon.hellion.org.uk>
	<1328253910.2480.41.camel@edumazet-laptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:25 +0000, Eric Dumazet wrote:
> Le vendredi 03 f=E9vrier 2012 =E0 06:38 +0000, Ian Campbell a =E9crit :
> > On Thu, 2012-02-02 at 22:52 +0000, Paul Gortmaker wrote:
> > > On Thu, Feb 2, 2012 at 3:50 PM, Ian Campbell <Ian.Campbell@citrix.com=
> wrote:
> > > > On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:
> > > =

> > > [...]
> > > =

> > > >
> > > > I don't think it is at all unreasonable to ask for bug fixes but in=
 this
> > > > case Wei's series is removing the code in question (which would also
> > > > undoubtedly fix the bug).
> > > >
> > > > As it happens the fix turns out to be simple but if it were complex=
 I
> > > > would perhaps have disagreed more strongly about spending effort fi=
xing
> > > > code that is removed 2 patches later, although obviously that would=
 have
> > > > depended on the specifics of the fix in that case.
> > > =

> > > Lots of people are relying on git bisect.  If you introduce build fai=
lures
> > > or known bugs into any point in history, you take away from the value
> > > in git bisect.  Sure, it happens by accident, but it shouldn't ever be
> > > done knowingly.
> > =

> > Sure. In this case the bug has been there since 2.6.39, it isn't
> > introduced by this series.
> > =

> =

> We are stuck right now with a bug introduced in 2.6.39, (IP redirects),
> and because fix was done in 3.1, we are unable to provide a fix fo
> stable 3.0 kernel.
> =

> Something that takes 15 minutes to fix now, can take several days of
> work later.

Sure.

Here is the patch. I've compile tested it but not run it yet since I'm
supposed to be packing for a trip, I'll be back on Wednesday. It seems
straight forward enough though.

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

>From 6f3d3068f6e049c2d810f9fc667d57667bea77dc Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 3 Feb 2012 07:47:23 +0000
Subject: [PATCH] xen: netback: do not bind netback threads to specific CPUs

netback_init does not take proper account of which CPUs is online. However =
we
don't require a thread per CPU, just a pool of worker threads, of which the
number of CPUs at start of day is as good a number as any.

Therefore do not bind netback threads to particular CPUs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Wei Lui <wei.lui2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/ne=
tback.c
index 59effac..31ad3ee 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,8 +1670,6 @@ static int __init netback_init(void)
 			goto failed_init;
 		}
 =

-		kthread_bind(netbk->task, group);
-
 		INIT_LIST_HEAD(&netbk->net_schedule_list);
 =

 		spin_lock_init(&netbk->net_schedule_list_lock);
-- =

1.7.2.5




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:09:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 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.xensource.com>)
	id 1RtECd-0005kS-L3; Fri, 03 Feb 2012 08:09:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtECb-0005jl-OW
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:09:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328256535!13226275!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12450 invoked from network); 3 Feb 2012 08:08:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 08:08:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 08:08:54 +0000
Message-Id: <4F2BA4230200007800070AE0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 08:08:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 08:18, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> How about use static bank size, say 256, which architecture (IA32_MCG_CAP 
> MSR) defined max bank number?

The maximum, if any, is 32 (beyond which collision with other defined
MSRs would arise). But with the possibility of having a discontiguous
or relocated MSR space, I don't think any static maximum would be a
good idea.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:09:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 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.xensource.com>)
	id 1RtECd-0005kS-L3; Fri, 03 Feb 2012 08:09:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtECb-0005jl-OW
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:09:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328256535!13226275!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12450 invoked from network); 3 Feb 2012 08:08:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 08:08:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 08:08:54 +0000
Message-Id: <4F2BA4230200007800070AE0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 08:08:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 08:18, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> How about use static bank size, say 256, which architecture (IA32_MCG_CAP 
> MSR) defined max bank number?

The maximum, if any, is 32 (beyond which collision with other defined
MSRs would arise). But with the possibility of having a discontiguous
or relocated MSR space, I don't think any static maximum would be a
good idea.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:17:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtEKn-0006JW-PV; Fri, 03 Feb 2012 08:17: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 1RtEKl-0006JM-In
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:17:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328256997!52732323!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22328 invoked from network); 3 Feb 2012 08:16:38 -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;
	3 Feb 2012 08:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10458926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:17:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 08:17:26 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtEKj-0005b6-W4;
	Fri, 03 Feb 2012 08:17:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtEKh-0004IC-KP;
	Fri, 03 Feb 2012 08:17:25 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11850-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 08:17:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11850: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11850 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11850/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:17:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtEKn-0006JW-PV; Fri, 03 Feb 2012 08:17: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 1RtEKl-0006JM-In
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:17:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328256997!52732323!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22328 invoked from network); 3 Feb 2012 08:16:38 -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;
	3 Feb 2012 08:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10458926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:17:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 08:17:26 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtEKj-0005b6-W4;
	Fri, 03 Feb 2012 08:17:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtEKh-0004IC-KP;
	Fri, 03 Feb 2012 08:17:25 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11850-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 08:17:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11850: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11850 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11850/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:39:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08: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.xensource.com>)
	id 1RtEg8-0007G2-Nx; Fri, 03 Feb 2012 08:39:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtEg7-0007Fx-RQ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:39:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328258365!11379820!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18235 invoked from network); 3 Feb 2012 08:39:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 08:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10459284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:39:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:39:25 +0000
Message-ID: <1328258364.13189.47.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Date: Fri, 3 Feb 2012 08:39:24 +0000
In-Reply-To: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
References: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 00:24 +0000, Dan Magenheimer wrote:
> I'm building xen-devel from scratch for the first time in a long
> time on a clean EL6u1 machine and running into a couple of problems.
> 
> 1) The build of tools/firmware/etherboot does a wget of a weird
>    pxe tar file that looks like it has a git hash in the filename.
>    I hacked around that (to wget the 1.0.0 version of the file).

This one is known. ixpe hasn't done a release for ages but we needed a
newer version for some bug fixes, hence we depend on a git revision now.

It is expected that the wget fails and then it falls back to generating
the tarball locally from a git checkout. I think this is pretty lame but
it is apparently a consequence of how the Makefile is structured. We
previously discussed putting a copy of that tarball on xenbits -- not
sure what happened to that plan but I have done it now and the wget
works for me (TM).

> 2) Building blktap2 complains about a missing "uuid/uuid.h".  I
>    did install the uuid and uuid-devel packages and there IS
>    a /usr/include/uuid.h but no /usr/include/uuid/uuid.h.  I found
>    I also needed to install libuuid-devel (which didn't get
>    checked in advance apparently, just uuid-devel and uuid I think).

tools/check/check_uuid_devel looks for both "uuid.h" and "uuid/uuid.h",
in that order but at least some headers (e.g. libxl_uuid.h, blktap's
ones etc) use:
	#if __linux__
	#include <uuid/uuid.h>
	#elif __BSD__
	#include <uuid.h>

It seems that on EL you can end up with uuid.h but not uuid/uuid.h which
confuses the check into succeeding where it shouldn't.

Please can you confirm that on EL6 uuid-devel
includes /usr/include/uuid.h and libuuid-devel
includes /usr/include/uuid/uuid.h

Roger, can you handle this (Linux vs. BSD?) header distinction in your
autoconf patch?

> 3) Missing texinfo package stops the build before it successfully
>    completes.  Can this be check'ed in advance?

Please can you post this log so we can find where the texinfo
requirement comes from?

Normally for these things we would patch them to only build the docs if
the required tool is present.

> Since I haven't built xen-devel in a long time, I don't know if
> these are recent problems with tip or old problems that don't
> show up on [Debian and whatever other envs other developers are
> using] but do show up on EL6.  So I thought I'd report them.

I think it's a mixture of old and new. Thanks for reporting.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:39:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08: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.xensource.com>)
	id 1RtEg8-0007G2-Nx; Fri, 03 Feb 2012 08:39:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtEg7-0007Fx-RQ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:39:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328258365!11379820!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18235 invoked from network); 3 Feb 2012 08:39:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 08:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10459284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:39:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:39:25 +0000
Message-ID: <1328258364.13189.47.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Date: Fri, 3 Feb 2012 08:39:24 +0000
In-Reply-To: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
References: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 00:24 +0000, Dan Magenheimer wrote:
> I'm building xen-devel from scratch for the first time in a long
> time on a clean EL6u1 machine and running into a couple of problems.
> 
> 1) The build of tools/firmware/etherboot does a wget of a weird
>    pxe tar file that looks like it has a git hash in the filename.
>    I hacked around that (to wget the 1.0.0 version of the file).

This one is known. ixpe hasn't done a release for ages but we needed a
newer version for some bug fixes, hence we depend on a git revision now.

It is expected that the wget fails and then it falls back to generating
the tarball locally from a git checkout. I think this is pretty lame but
it is apparently a consequence of how the Makefile is structured. We
previously discussed putting a copy of that tarball on xenbits -- not
sure what happened to that plan but I have done it now and the wget
works for me (TM).

> 2) Building blktap2 complains about a missing "uuid/uuid.h".  I
>    did install the uuid and uuid-devel packages and there IS
>    a /usr/include/uuid.h but no /usr/include/uuid/uuid.h.  I found
>    I also needed to install libuuid-devel (which didn't get
>    checked in advance apparently, just uuid-devel and uuid I think).

tools/check/check_uuid_devel looks for both "uuid.h" and "uuid/uuid.h",
in that order but at least some headers (e.g. libxl_uuid.h, blktap's
ones etc) use:
	#if __linux__
	#include <uuid/uuid.h>
	#elif __BSD__
	#include <uuid.h>

It seems that on EL you can end up with uuid.h but not uuid/uuid.h which
confuses the check into succeeding where it shouldn't.

Please can you confirm that on EL6 uuid-devel
includes /usr/include/uuid.h and libuuid-devel
includes /usr/include/uuid/uuid.h

Roger, can you handle this (Linux vs. BSD?) header distinction in your
autoconf patch?

> 3) Missing texinfo package stops the build before it successfully
>    completes.  Can this be check'ed in advance?

Please can you post this log so we can find where the texinfo
requirement comes from?

Normally for these things we would patch them to only build the docs if
the required tool is present.

> Since I haven't built xen-devel in a long time, I don't know if
> these are recent problems with tip or old problems that don't
> show up on [Debian and whatever other envs other developers are
> using] but do show up on EL6.  So I thought I'd report them.

I think it's a mixture of old and new. Thanks for reporting.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:41:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtEhT-0007L4-CQ; Fri, 03 Feb 2012 08:40:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtEhR-0007Ki-P2
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:40:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328258447!13230994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 3 Feb 2012 08:40:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 08:40:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10459301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:40: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.213.0; Fri, 3 Feb 2012
	08:40:47 +0000
Message-ID: <1328258446.13189.48.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Fri, 3 Feb 2012 08:40:46 +0000
In-Reply-To: <d39dc69631e498c64e1e36fcc246ccb6.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
	<69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
	<1328214343.13189.4.camel@dagon.hellion.org.uk>
	<d39dc69631e498c64e1e36fcc246ccb6.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 23:09 +0000, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-02-02 at 20:23 +0000, Andres Lagar-Cavilla wrote:
> >> > On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
> >> >> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> >> >> >>
> >> >> >>
> >> >> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> >> >> >> +                        unsigned int op, unsigned int mode,
> >> >> >> +                        uint64_t gfn, void *buffer)
> >> >> >> +{
> >> >> >> +    xen_mem_event_op_t meo;
> >> >> >> +
> >> >> >> +    memset(&meo, 0, sizeof(meo));
> >> >> >> +
> >> >> >> +    meo.op      = op;
> >> >> >> +    meo.domain  = domain_id;
> >> >> >> +    meo.gfn     = gfn;
> >> >> >> +    meo.buffer  = (unsigned long) buffer;
> >> >> >
> >> >> > Hypercall arguments need to use the xc_hypercall_buffer stuff in
> >> order
> >> >> > to ensure that the memory is safe to access from a hypercall (in
> >> >> > particular that it is mlocked or similar)-- I don't see where that
> >> >> > happens for this buffer.
> >> >> >
> >> >> > meo itself is bounced by do_memory_op so that is OK.
> >> >> >
> >> >> > I was also a little suspicious of ring_addr and shared_addr in
> >> >> > xc_mem_event_control in this regard.
> >> >> >
> >> >> > Or does the mem sharing code make it's own arrangements for these
> >> >> sorts
> >> >> > of things somewhere?
> >> >>
> >> >> It's rather unclean. They do not get mlock'ed (and there is no sanity
> >> >> check to ensure they're page-aligned). They should follow the pattern
> >> >> established in xc_mem_paging_load. I'll get on it, probably a
> >> separate
> >> >> patch.
> >> >
> >> > If you are reworking this It Would Be Nice If (tm) you could make it
> >> use
> >> > xc_hypercall_buffer_alloc and friends to allocate and manage the
> >> buffer
> >> > while you are there e.g. the void *buffer above would become struct
> >> > xc_hypercall_buffer *buffer -- see xc_perfc_query for example.
> >>
> >> Took me a while to grok those hypercall buffer macros. Conclusion: that
> >> would need to change callers of paging_load (xenpaging in tree).
> >
> > Yes, in this case you probably want to bubble their use right up to the
> > top level rather than bouncing in the internals like we do for smaller
> > and.or more transient data.
> >
> >> Can we keep this separate? domctl interface also suffers from all these
> >> problems. domctl->memops switch is orthogonal to the buffer badness. I
> >> want to tackle one problem at a time.
> >
> > Sure, read "IWBNI" as "in the fullness of time" ;-)
> 
> Ok, trying to mb() what's needed now and what will take place in the
> fullness of time:
> - ring creation when initializing mem event is ugly, but cannot be fixed
> short of a kernel driver. I will however produce a patch now that at least
> mlock's these guys.

Sounds good.

mb() goes here ;-)

> - All libxc consumers of these interfaces should be updated to init these
> magic pages (and the paging load buffer) using xc_hypercall_buffer_alloc
> in their own code.

Correct, this can be done whenever though.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 08:41:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 08:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtEhT-0007L4-CQ; Fri, 03 Feb 2012 08:40:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtEhR-0007Ki-P2
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 08:40:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328258447!13230994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzI3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 3 Feb 2012 08:40:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 08:40:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10459301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:40: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.213.0; Fri, 3 Feb 2012
	08:40:47 +0000
Message-ID: <1328258446.13189.48.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Fri, 3 Feb 2012 08:40:46 +0000
In-Reply-To: <d39dc69631e498c64e1e36fcc246ccb6.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328126978@xdev.gridcentric.ca>
	<8e64acc49aa80c1860b2.1328126979@xdev.gridcentric.ca>
	<1328187397.5359.9.camel@zakaz.uk.xensource.com>
	<148b4d34646effc399f9eab9c07c30c2.squirrel@webmail.lagarcavilla.org>
	<1328194692.2924.29.camel@zakaz.uk.xensource.com>
	<69c1675a2a6774a3e5172b02762b0e3d.squirrel@webmail.lagarcavilla.org>
	<1328214343.13189.4.camel@dagon.hellion.org.uk>
	<d39dc69631e498c64e1e36fcc246ccb6.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 23:09 +0000, Andres Lagar-Cavilla wrote:
> > On Thu, 2012-02-02 at 20:23 +0000, Andres Lagar-Cavilla wrote:
> >> > On Thu, 2012-02-02 at 14:25 +0000, Andres Lagar-Cavilla wrote:
> >> >> > On Wed, 2012-02-01 at 20:09 +0000, Andres Lagar-Cavilla wrote:
> >> >> >>
> >> >> >>
> >> >> >> +int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> >> >> >> +                        unsigned int op, unsigned int mode,
> >> >> >> +                        uint64_t gfn, void *buffer)
> >> >> >> +{
> >> >> >> +    xen_mem_event_op_t meo;
> >> >> >> +
> >> >> >> +    memset(&meo, 0, sizeof(meo));
> >> >> >> +
> >> >> >> +    meo.op      = op;
> >> >> >> +    meo.domain  = domain_id;
> >> >> >> +    meo.gfn     = gfn;
> >> >> >> +    meo.buffer  = (unsigned long) buffer;
> >> >> >
> >> >> > Hypercall arguments need to use the xc_hypercall_buffer stuff in
> >> order
> >> >> > to ensure that the memory is safe to access from a hypercall (in
> >> >> > particular that it is mlocked or similar)-- I don't see where that
> >> >> > happens for this buffer.
> >> >> >
> >> >> > meo itself is bounced by do_memory_op so that is OK.
> >> >> >
> >> >> > I was also a little suspicious of ring_addr and shared_addr in
> >> >> > xc_mem_event_control in this regard.
> >> >> >
> >> >> > Or does the mem sharing code make it's own arrangements for these
> >> >> sorts
> >> >> > of things somewhere?
> >> >>
> >> >> It's rather unclean. They do not get mlock'ed (and there is no sanity
> >> >> check to ensure they're page-aligned). They should follow the pattern
> >> >> established in xc_mem_paging_load. I'll get on it, probably a
> >> separate
> >> >> patch.
> >> >
> >> > If you are reworking this It Would Be Nice If (tm) you could make it
> >> use
> >> > xc_hypercall_buffer_alloc and friends to allocate and manage the
> >> buffer
> >> > while you are there e.g. the void *buffer above would become struct
> >> > xc_hypercall_buffer *buffer -- see xc_perfc_query for example.
> >>
> >> Took me a while to grok those hypercall buffer macros. Conclusion: that
> >> would need to change callers of paging_load (xenpaging in tree).
> >
> > Yes, in this case you probably want to bubble their use right up to the
> > top level rather than bouncing in the internals like we do for smaller
> > and.or more transient data.
> >
> >> Can we keep this separate? domctl interface also suffers from all these
> >> problems. domctl->memops switch is orthogonal to the buffer badness. I
> >> want to tackle one problem at a time.
> >
> > Sure, read "IWBNI" as "in the fullness of time" ;-)
> 
> Ok, trying to mb() what's needed now and what will take place in the
> fullness of time:
> - ring creation when initializing mem event is ugly, but cannot be fixed
> short of a kernel driver. I will however produce a patch now that at least
> mlock's these guys.

Sounds good.

mb() goes here ;-)

> - All libxc consumers of these interfaces should be updated to init these
> magic pages (and the paging load buffer) using xc_hypercall_buffer_alloc
> in their own code.

Correct, this can be done whenever though.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 09:53:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 09:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtFp7-0001bG-Qn; Fri, 03 Feb 2012 09:52:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtFp6-0001aE-EZ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 09:52:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328262765!13801569!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13559 invoked from network); 3 Feb 2012 09:52:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 09:52:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 09:52:45 +0000
Message-Id: <4F2BBC7C0200007800070B37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 09:52:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.  I assembled
> this information by reviewing xend, various versions of the Linux
> blkif drivers, fixing bugs in the FreeBSD blkfront driver, and
> writing and testing a blkback driver for FreeBSD.

Thanks for doing this!

> All but the last patch in the series is source compatible with
> existing drivers.  This final patch adds FreeBSD's extension to
> allow an I/O to span multiple ring entries.  The number of outstanding
> requests, and the max I/O size and number of segments per request,
> can all be negotiated.  Drivers offering this extension are backwards
> compatible with existing drivers, but the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has been changed to reflect the new
> limit of 255.  A global replacement of BLKIF_MAX_SEGMENTS_PER_REQUEST
> with BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK is all that's required to
> adjust drivers without the extension to this header change.

No, this sort of change is just not valid to be done. Changes to
public headers must always (default to) be backwards compatible.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 09:53:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 09:53:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtFp7-0001bG-Qn; Fri, 03 Feb 2012 09:52:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtFp6-0001aE-EZ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 09:52:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328262765!13801569!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13559 invoked from network); 3 Feb 2012 09:52:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 09:52:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 09:52:45 +0000
Message-Id: <4F2BBC7C0200007800070B37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 09:52:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.  I assembled
> this information by reviewing xend, various versions of the Linux
> blkif drivers, fixing bugs in the FreeBSD blkfront driver, and
> writing and testing a blkback driver for FreeBSD.

Thanks for doing this!

> All but the last patch in the series is source compatible with
> existing drivers.  This final patch adds FreeBSD's extension to
> allow an I/O to span multiple ring entries.  The number of outstanding
> requests, and the max I/O size and number of segments per request,
> can all be negotiated.  Drivers offering this extension are backwards
> compatible with existing drivers, but the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has been changed to reflect the new
> limit of 255.  A global replacement of BLKIF_MAX_SEGMENTS_PER_REQUEST
> with BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK is all that's required to
> adjust drivers without the extension to this header change.

No, this sort of change is just not valid to be done. Changes to
public headers must always (default to) be backwards compatible.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 09:56:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 09: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.xensource.com>)
	id 1RtFs2-0001te-Ef; Fri, 03 Feb 2012 09:55:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtFs1-0001tM-40
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 09:55:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328262946!13783978!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 3 Feb 2012 09:55:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 09:55:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 09:55:46 +0000
Message-Id: <4F2BBD2F0200007800070B3A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 09:55:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-11831-mainreport@xen.org>
In-Reply-To: <osstest-11831-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 11831: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 07:22, xen.org <ian.jackson@eu.citrix.com> wrote:
> Regressions which are regarded as allowable (not blocking):
>  build-i386                    4 xen-build                    fail   like 11637
>  build-i386-oldkern            4 xen-build                    fail   like 11637

Is that really the way things should work?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 09:56:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 09: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.xensource.com>)
	id 1RtFs2-0001te-Ef; Fri, 03 Feb 2012 09:55:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtFs1-0001tM-40
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 09:55:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328262946!13783978!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 3 Feb 2012 09:55:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 09:55:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 09:55:46 +0000
Message-Id: <4F2BBD2F0200007800070B3A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 09:55:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-11831-mainreport@xen.org>
In-Reply-To: <osstest-11831-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 11831: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 07:22, xen.org <ian.jackson@eu.citrix.com> wrote:
> Regressions which are regarded as allowable (not blocking):
>  build-i386                    4 xen-build                    fail   like 11637
>  build-i386-oldkern            4 xen-build                    fail   like 11637

Is that really the way things should work?

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 11:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 11:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtHId-0005dL-Mc; Fri, 03 Feb 2012 11:27:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RtHIc-0005dA-4o
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 11:27:26 +0000
Received: from [85.158.139.83:11405] by server-10.bemta-5.messagelabs.com id
	93/C4-18919-D94CB2F4; Fri, 03 Feb 2012 11:27:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328268444!13514487!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29026 invoked from network); 3 Feb 2012 11:27:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 11:27:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10463927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 11:27:24 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	11:27:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <1328253910.2480.41.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
	<1328251092.13189.29.camel@dagon.hellion.org.uk>
	<1328253910.2480.41.camel@edumazet-laptop>
Date: Fri, 3 Feb 2012 11:27:45 +0000
Message-ID: <1328268465.7388.5.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>, Paul
	Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:25 +0000, Eric Dumazet wrote:
> 
> We are stuck right now with a bug introduced in 2.6.39, (IP redirects),
> and because fix was done in 3.1, we are unable to provide a fix fo
> stable 3.0 kernel.
> 
> Something that takes 15 minutes to fix now, can take several days of
> work later.
> 
> 
> 

You're right.

Will stick Ian's patch in front of my next series. Thanks for your
effort in reviewing.



Wei.


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 11:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 11:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtHId-0005dL-Mc; Fri, 03 Feb 2012 11:27:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RtHIc-0005dA-4o
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 11:27:26 +0000
Received: from [85.158.139.83:11405] by server-10.bemta-5.messagelabs.com id
	93/C4-18919-D94CB2F4; Fri, 03 Feb 2012 11:27:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328268444!13514487!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29026 invoked from network); 3 Feb 2012 11:27:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 11:27:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10463927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 11:27:24 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	11:27:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <1328253910.2480.41.camel@edumazet-laptop>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
	<CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
	<1328251092.13189.29.camel@dagon.hellion.org.uk>
	<1328253910.2480.41.camel@edumazet-laptop>
Date: Fri, 3 Feb 2012 11:27:45 +0000
Message-ID: <1328268465.7388.5.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>, Paul
	Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:25 +0000, Eric Dumazet wrote:
> 
> We are stuck right now with a bug introduced in 2.6.39, (IP redirects),
> and because fix was done in 3.1, we are unable to provide a fix fo
> stable 3.0 kernel.
> 
> Something that takes 15 minutes to fix now, can take several days of
> work later.
> 
> 
> 

You're right.

Will stick Ian's patch in front of my next series. Thanks for your
effort in reviewing.



Wei.


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 11:37:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 11:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtHRn-0005xE-RS; Fri, 03 Feb 2012 11:36: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 1RtHRm-0005x5-0u
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 11:36:54 +0000
Received: from [85.158.138.51:4871] by server-12.bemta-3.messagelabs.com id
	29/0A-21103-5D6CB2F4; Fri, 03 Feb 2012 11:36:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328269012!11860875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22638 invoked from network); 3 Feb 2012 11:36:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 11:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10465179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 11:36:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 11:36:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtHRj-0006to-Bt;
	Fri, 03 Feb 2012 11:36:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtHRj-0002ML-B2;
	Fri, 03 Feb 2012 11:36:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11853-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 11:36:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11853: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11853 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11853/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                    fail pass in 11829
 test-i386-i386-win           14 guest-start.2      fail in 11829 pass in 11853

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

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-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-rhel6hvm-amd  7 redhat-install               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-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 11829 never pass

version targeted for testing:
 xen                  3feb83eed6bd
baseline version:
 xen                  1b7e074ee1d6

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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=3feb83eed6bd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3feb83eed6bd
+ branch=xen-4.0-testing
+ revision=3feb83eed6bd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 3feb83eed6bd 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 1 changesets with 1 changes to 1 files

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 11:37:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 11:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtHRn-0005xE-RS; Fri, 03 Feb 2012 11:36: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 1RtHRm-0005x5-0u
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 11:36:54 +0000
Received: from [85.158.138.51:4871] by server-12.bemta-3.messagelabs.com id
	29/0A-21103-5D6CB2F4; Fri, 03 Feb 2012 11:36:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328269012!11860875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22638 invoked from network); 3 Feb 2012 11:36:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 11:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,351,1325462400"; d="scan'208";a="10465179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 11:36:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 11:36:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtHRj-0006to-Bt;
	Fri, 03 Feb 2012 11:36:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtHRj-0002ML-B2;
	Fri, 03 Feb 2012 11:36:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11853-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 11:36:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 11853: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11853 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11853/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                    fail pass in 11829
 test-i386-i386-win           14 guest-start.2      fail in 11829 pass in 11853

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

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-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-rhel6hvm-amd  7 redhat-install               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-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 11829 never pass

version targeted for testing:
 xen                  3feb83eed6bd
baseline version:
 xen                  1b7e074ee1d6

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


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

Logs, config files, etc. are available at
    http://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=3feb83eed6bd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3feb83eed6bd
+ branch=xen-4.0-testing
+ revision=3feb83eed6bd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r 3feb83eed6bd 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 1 changesets with 1 changes to 1 files

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 12:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 12:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtIDr-0007m6-Qk; Fri, 03 Feb 2012 12:26:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RtIDq-0007m1-KR
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 12:26:34 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328271987!11846130!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11758 invoked from network); 3 Feb 2012 12:26:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	3 Feb 2012 12:26:28 -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 q13CQOZh012718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 07:26:24 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q13CQLPx010552; Fri, 3 Feb 2012 07:26:21 -0500
Message-ID: <4F2BD2CC.4050906@redhat.com>
Date: Fri, 03 Feb 2012 13:27:56 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>	<20120126181900.GB25572@phenom.dumpdata.com>
	<1327660589.2585.14.camel@leeni.uk.xensource.com>
In-Reply-To: <1327660589.2585.14.camel@leeni.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"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] xen-netfront: correct
	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/12 11:36, Wei Liu wrote:
> On Thu, 2012-01-26 at 18:19 +0000, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jan 26, 2012 at 05:23:23PM +0000, Wei Liu wrote:
>>
>> Can you give some more details please? What is the impact of
>> not having this? Should it be backported to stable?
>>
>
> I think it will not cause crash, only the scratch space size is
> affected, thus impacting tx batching a bit.
>
> As the tx structure is bigger than rx structure. I think scratch space
> size is likely to shrink after correction.

It also seems to affect the netfront_tx_slot_available() function, 
making it stricter (likely). Before the patch, the function may have 
reported available slots when there were none, causing spurious(?) queue 
wakeups in xennet_maybe_wake_tx(), and not stopping the queue in 
xennet_start_xmit() when it should have(?).

It seems there are no further uses of TX_MAX_TARGET, and for bounds 
checking NET_TX_RING_SIZE was used (which was always correct). So I 
guess the typo may have caused some performance degradation.

I can't either prove or disprove a DoS-like busy loop in the pre-patch form.

Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 12:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 12:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtIDr-0007m6-Qk; Fri, 03 Feb 2012 12:26:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RtIDq-0007m1-KR
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 12:26:34 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328271987!11846130!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11758 invoked from network); 3 Feb 2012 12:26:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	3 Feb 2012 12:26:28 -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 q13CQOZh012718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 07:26:24 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q13CQLPx010552; Fri, 3 Feb 2012 07:26:21 -0500
Message-ID: <4F2BD2CC.4050906@redhat.com>
Date: Fri, 03 Feb 2012 13:27:56 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>	<20120126181900.GB25572@phenom.dumpdata.com>
	<1327660589.2585.14.camel@leeni.uk.xensource.com>
In-Reply-To: <1327660589.2585.14.camel@leeni.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"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] xen-netfront: correct
	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/12 11:36, Wei Liu wrote:
> On Thu, 2012-01-26 at 18:19 +0000, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jan 26, 2012 at 05:23:23PM +0000, Wei Liu wrote:
>>
>> Can you give some more details please? What is the impact of
>> not having this? Should it be backported to stable?
>>
>
> I think it will not cause crash, only the scratch space size is
> affected, thus impacting tx batching a bit.
>
> As the tx structure is bigger than rx structure. I think scratch space
> size is likely to shrink after correction.

It also seems to affect the netfront_tx_slot_available() function, 
making it stricter (likely). Before the patch, the function may have 
reported available slots when there were none, causing spurious(?) queue 
wakeups in xennet_maybe_wake_tx(), and not stopping the queue in 
xennet_start_xmit() when it should have(?).

It seems there are no further uses of TX_MAX_TARGET, and for bounds 
checking NET_TX_RING_SIZE was used (which was always correct). So I 
guess the typo may have caused some performance degradation.

I can't either prove or disprove a DoS-like busy loop in the pre-patch form.

Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 12:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 12:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtILu-0007yO-Bm; Fri, 03 Feb 2012 12:34:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RtILt-0007y5-D5
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 12:34:53 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328272486!9951171!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk1MjAz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29806 invoked from network); 3 Feb 2012 12:34:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 12:34:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 03 Feb 2012 04:34:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105886743"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 03 Feb 2012 04:34:43 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 3 Feb 2012 20:34:41 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 20:34:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] vMCE vs migration
Thread-Index: AQHM4ksQmIIv8qUEcUC7dztSHU+i2ZYrFbpQ
Date: Fri, 3 Feb 2012 12:34:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
	<4F2BA4230200007800070AE0@nat28.tlf.novell.com>
In-Reply-To: <4F2BA4230200007800070AE0@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: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>, "Jiang, 
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 03.02.12 at 08:18, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> How about use static bank size, say 256, which architecture
>> (IA32_MCG_CAP MSR) defined max bank number?
> 
> The maximum, if any, is 32 (beyond which collision with other defined
> MSRs would arise). But with the possibility of having a discontiguous
> or relocated MSR space, I don't think any static maximum would be a
> good idea.
> 
> Jan

The advantages of static max bank is simple, any disadvantages of static solution?
or, can we use bank_entry listed in vmce->impact_header for mci_ctl, like what mci_status/mci_addr/mci_misc do?
I just think the patch may be too complicated for a minor issue.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 12:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 12:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtILu-0007yO-Bm; Fri, 03 Feb 2012 12:34:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RtILt-0007y5-D5
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 12:34:53 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328272486!9951171!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk1MjAz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29806 invoked from network); 3 Feb 2012 12:34:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 12:34:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 03 Feb 2012 04:34:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105886743"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 03 Feb 2012 04:34:43 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 3 Feb 2012 20:34:41 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 3 Feb 2012 20:34:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] vMCE vs migration
Thread-Index: AQHM4ksQmIIv8qUEcUC7dztSHU+i2ZYrFbpQ
Date: Fri, 3 Feb 2012 12:34:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
	<4F2BA4230200007800070AE0@nat28.tlf.novell.com>
In-Reply-To: <4F2BA4230200007800070AE0@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: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>, "Jiang, 
	Yunhong" <yunhong.jiang@intel.com>, "Shan, Haitao" <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 03.02.12 at 08:18, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> How about use static bank size, say 256, which architecture
>> (IA32_MCG_CAP MSR) defined max bank number?
> 
> The maximum, if any, is 32 (beyond which collision with other defined
> MSRs would arise). But with the possibility of having a discontiguous
> or relocated MSR space, I don't think any static maximum would be a
> good idea.
> 
> Jan

The advantages of static max bank is simple, any disadvantages of static solution?
or, can we use bank_entry listed in vmce->impact_header for mci_ctl, like what mci_status/mci_addr/mci_misc do?
I just think the patch may be too complicated for a minor issue.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 12:59:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 12: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.xensource.com>)
	id 1RtIir-0000Tn-7W; Fri, 03 Feb 2012 12:58:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RtIiq-0000Tc-2D
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 12:58:36 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328273908!11851178!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11252 invoked from network); 3 Feb 2012 12:58:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	3 Feb 2012 12:58:29 -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 q13CwNnS010820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 07:58:23 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q13CwLEN002141; Fri, 3 Feb 2012 07:58:22 -0500
Message-ID: <4F2BDA4C.7060601@redhat.com>
Date: Fri, 03 Feb 2012 13:59:56 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>	<20120126181900.GB25572@phenom.dumpdata.com>	<1327660589.2585.14.camel@leeni.uk.xensource.com>
	<4F2BD2CC.4050906@redhat.com>
In-Reply-To: <4F2BD2CC.4050906@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"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] xen-netfront:
	correct	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 13:27, Laszlo Ersek wrote:
> On 01/27/12 11:36, Wei Liu wrote:

>> As the tx structure is bigger than rx structure. I think scratch space
>> size is likely to shrink after correction.
>
> It also seems to affect the netfront_tx_slot_available() function,
> making it stricter (likely). Before the patch, the function may have
> reported available slots when there were none, causing spurious(?) queue
> wakeups in xennet_maybe_wake_tx(), and not stopping the queue in
> xennet_start_xmit() when it should have(?).

(Eyeballing the source makes me think

   NET_TX_RING_SIZE == (4096 - 16 - 48) / (5 * 4) == 201
   NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 4) == 252

but I didn't try to verify them.)

Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 12:59:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 12: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.xensource.com>)
	id 1RtIir-0000Tn-7W; Fri, 03 Feb 2012 12:58:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RtIiq-0000Tc-2D
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 12:58:36 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328273908!11851178!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11252 invoked from network); 3 Feb 2012 12:58:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-174.messagelabs.com with SMTP;
	3 Feb 2012 12:58:29 -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 q13CwNnS010820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 07:58:23 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q13CwLEN002141; Fri, 3 Feb 2012 07:58:22 -0500
Message-ID: <4F2BDA4C.7060601@redhat.com>
Date: Fri, 03 Feb 2012 13:59:56 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>	<20120126181900.GB25572@phenom.dumpdata.com>	<1327660589.2585.14.camel@leeni.uk.xensource.com>
	<4F2BD2CC.4050906@redhat.com>
In-Reply-To: <4F2BD2CC.4050906@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"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] xen-netfront:
	correct	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 13:27, Laszlo Ersek wrote:
> On 01/27/12 11:36, Wei Liu wrote:

>> As the tx structure is bigger than rx structure. I think scratch space
>> size is likely to shrink after correction.
>
> It also seems to affect the netfront_tx_slot_available() function,
> making it stricter (likely). Before the patch, the function may have
> reported available slots when there were none, causing spurious(?) queue
> wakeups in xennet_maybe_wake_tx(), and not stopping the queue in
> xennet_start_xmit() when it should have(?).

(Eyeballing the source makes me think

   NET_TX_RING_SIZE == (4096 - 16 - 48) / (5 * 4) == 201
   NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 4) == 252

but I didn't try to verify them.)

Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:27:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJAH-0001AW-Or; Fri, 03 Feb 2012 13:26:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJAG-0001AR-7G
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:26:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328275609!9835655!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3777 invoked from network); 3 Feb 2012 13:26:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:26:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:26:48 +0000
Message-Id: <4F2BEEA70200007800070E81@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:26:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,"Laszlo Ersek" <lersek@redhat.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
	<20120126181900.GB25572@phenom.dumpdata.com>
	<1327660589.2585.14.camel@leeni.uk.xensource.com>
	<4F2BD2CC.4050906@redhat.com> <4F2BDA4C.7060601@redhat.com>
In-Reply-To: <4F2BDA4C.7060601@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"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] xen-netfront:
 correct	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 13:59, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/03/12 13:27, Laszlo Ersek wrote:
>> On 01/27/12 11:36, Wei Liu wrote:
> 
>>> As the tx structure is bigger than rx structure. I think scratch space
>>> size is likely to shrink after correction.
>>
>> It also seems to affect the netfront_tx_slot_available() function,
>> making it stricter (likely). Before the patch, the function may have
>> reported available slots when there were none, causing spurious(?) queue
>> wakeups in xennet_maybe_wake_tx(), and not stopping the queue in
>> xennet_start_xmit() when it should have(?).
> 
> (Eyeballing the source makes me think
> 
>    NET_TX_RING_SIZE == (4096 - 16 - 48) / (5 * 4) == 201
>    NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 4) == 252

NET_TX_RING_SIZE == (4096 - 16 - 48) / (6 * 2) == 336
NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 2) == 504

and with {R,T}X_MAX_TARGET capped to 256 the change really is
benign without multi-page ring support afaict.

Jan

> but I didn't try to verify them.)
> 
> Laszlo
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:27:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJAH-0001AW-Or; Fri, 03 Feb 2012 13:26:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJAG-0001AR-7G
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:26:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328275609!9835655!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3777 invoked from network); 3 Feb 2012 13:26:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:26:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:26:48 +0000
Message-Id: <4F2BEEA70200007800070E81@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:26:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,"Laszlo Ersek" <lersek@redhat.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
	<20120126181900.GB25572@phenom.dumpdata.com>
	<1327660589.2585.14.camel@leeni.uk.xensource.com>
	<4F2BD2CC.4050906@redhat.com> <4F2BDA4C.7060601@redhat.com>
In-Reply-To: <4F2BDA4C.7060601@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"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] xen-netfront:
 correct	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 13:59, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/03/12 13:27, Laszlo Ersek wrote:
>> On 01/27/12 11:36, Wei Liu wrote:
> 
>>> As the tx structure is bigger than rx structure. I think scratch space
>>> size is likely to shrink after correction.
>>
>> It also seems to affect the netfront_tx_slot_available() function,
>> making it stricter (likely). Before the patch, the function may have
>> reported available slots when there were none, causing spurious(?) queue
>> wakeups in xennet_maybe_wake_tx(), and not stopping the queue in
>> xennet_start_xmit() when it should have(?).
> 
> (Eyeballing the source makes me think
> 
>    NET_TX_RING_SIZE == (4096 - 16 - 48) / (5 * 4) == 201
>    NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 4) == 252

NET_TX_RING_SIZE == (4096 - 16 - 48) / (6 * 2) == 336
NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 2) == 504

and with {R,T}X_MAX_TARGET capped to 256 the change really is
benign without multi-page ring support afaict.

Jan

> but I didn't try to verify them.)
> 
> Laszlo
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:31:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJDy-0001Gj-DK; Fri, 03 Feb 2012 13:30:46 +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 1RtJDw-0001GT-M3
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:30:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328275816!51462896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6397 invoked from network); 3 Feb 2012 13:30:17 -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;
	3 Feb 2012 13:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21590613"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:30:38 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:30:38 -0500
Message-ID: <4F2BE17D.2010207@citrix.com>
Date: Fri, 3 Feb 2012 13:30:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000509050901020101050202"
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] IO-APIC: tweak debug key info formatting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000509050901020101050202
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

The formatting of the IO-APIC debug key info has niggled me for a while,
and with the latest interrupt bug I am chasing, has finally motivated me
to fix it.

The attached patch causes all columns to line up, and removes the comma
which served no purpose in combination with the spaces already present.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000509050901020101050202
Content-Type: text/x-patch; name="dump_ioapic_irq_info_format.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="dump_ioapic_irq_info_format.patch"

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864
Change io_apic debug information format to align columns

Having the columns aligned makes for much easier reading.  Also remove
the commas which only add to visual clutter in combination with
spaces.

Furthermore, printing fewer characters makes it less likely that the
serial buffer will overflow resulting in loss of critical debugging
information.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e2722b24dc09 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2406,13 +2406,13 @@ void dump_ioapic_irq_info(void)
             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
             spin_unlock_irqrestore(&ioapic_lock, flags);
 
-            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
-                   "delivery_status=%d, polarity=%d, irr=%d, "
-                   "trigger=%s, mask=%d, dest_id:%d\n",
+            printk("vector=%3u delivery_mode=%u dest_mode=%s "
+                   "delivery_status=%d polarity=%d irr=%d "
+                   "trigger=%s mask=%d dest_id:%d\n",
                    rte.vector, rte.delivery_mode,
-                   rte.dest_mode ? "logical" : "physical",
+                   rte.dest_mode ? "logical " : "physical",
                    rte.delivery_status, rte.polarity, rte.irr,
-                   rte.trigger ? "level" : "edge", rte.mask,
+                   rte.trigger ? "level" : "edge ", rte.mask,
                    rte.dest.logical.logical_dest);
 
             if ( entry->next == 0 )

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

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

--------------000509050901020101050202--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:31:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJDy-0001Gj-DK; Fri, 03 Feb 2012 13:30:46 +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 1RtJDw-0001GT-M3
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:30:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328275816!51462896!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6397 invoked from network); 3 Feb 2012 13:30:17 -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;
	3 Feb 2012 13:30:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21590613"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:30:38 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:30:38 -0500
Message-ID: <4F2BE17D.2010207@citrix.com>
Date: Fri, 3 Feb 2012 13:30:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000509050901020101050202"
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] IO-APIC: tweak debug key info formatting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000509050901020101050202
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

The formatting of the IO-APIC debug key info has niggled me for a while,
and with the latest interrupt bug I am chasing, has finally motivated me
to fix it.

The attached patch causes all columns to line up, and removes the comma
which served no purpose in combination with the spaces already present.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000509050901020101050202
Content-Type: text/x-patch; name="dump_ioapic_irq_info_format.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="dump_ioapic_irq_info_format.patch"

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864
Change io_apic debug information format to align columns

Having the columns aligned makes for much easier reading.  Also remove
the commas which only add to visual clutter in combination with
spaces.

Furthermore, printing fewer characters makes it less likely that the
serial buffer will overflow resulting in loss of critical debugging
information.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e2722b24dc09 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2406,13 +2406,13 @@ void dump_ioapic_irq_info(void)
             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
             spin_unlock_irqrestore(&ioapic_lock, flags);
 
-            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
-                   "delivery_status=%d, polarity=%d, irr=%d, "
-                   "trigger=%s, mask=%d, dest_id:%d\n",
+            printk("vector=%3u delivery_mode=%u dest_mode=%s "
+                   "delivery_status=%d polarity=%d irr=%d "
+                   "trigger=%s mask=%d dest_id:%d\n",
                    rte.vector, rte.delivery_mode,
-                   rte.dest_mode ? "logical" : "physical",
+                   rte.dest_mode ? "logical " : "physical",
                    rte.delivery_status, rte.polarity, rte.irr,
-                   rte.trigger ? "level" : "edge", rte.mask,
+                   rte.trigger ? "level" : "edge ", rte.mask,
                    rte.dest.logical.logical_dest);
 
             if ( entry->next == 0 )

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

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

--------------000509050901020101050202--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:32:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJFA-0001L4-SS; Fri, 03 Feb 2012 13:32:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJF9-0001Kg-Dl
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:31:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328275913!9971873!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10756 invoked from network); 3 Feb 2012 13:31:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:31:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:31:52 +0000
Message-Id: <4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:31:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
In-Reply-To: <65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

These being mostly meaningless to non-Linux, I don't think they
belong here.

Jan

> --- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> @@ -393,6 +393,28 @@ DEFINE_RING_TYPES(blkif, struct blkif_re
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
>  
> +/*
> + * Xen-defined major numbers for virtual block devices.
> + */
> +#define XEN_IDE0_MAJOR          3
> +#define XEN_IDE1_MAJOR          22
> +#define XEN_SCSI_DISK0_MAJOR    8
> +#define XEN_SCSI_DISK1_MAJOR    65
> +#define XEN_SCSI_DISK2_MAJOR    66
> +#define XEN_SCSI_DISK3_MAJOR    67
> +#define XEN_SCSI_DISK4_MAJOR    68
> +#define XEN_SCSI_DISK5_MAJOR    69
> +#define XEN_SCSI_DISK6_MAJOR    70
> +#define XEN_SCSI_DISK7_MAJOR    71
> +#define XEN_SCSI_DISK8_MAJOR    128
> +#define XEN_SCSI_DISK9_MAJOR    129
> +#define XEN_SCSI_DISK10_MAJOR   130
> +#define XEN_SCSI_DISK11_MAJOR   131
> +#define XEN_SCSI_DISK12_MAJOR   132
> +#define XEN_SCSI_DISK13_MAJOR   133
> +#define XEN_SCSI_DISK14_MAJOR   134
> +#define XEN_SCSI_DISK15_MAJOR   135
> +
>  #endif /* __XEN_PUBLIC_IO_BLKIF_H__ */
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:32:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:32:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJFA-0001L4-SS; Fri, 03 Feb 2012 13:32:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJF9-0001Kg-Dl
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:31:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328275913!9971873!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10756 invoked from network); 3 Feb 2012 13:31:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:31:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:31:52 +0000
Message-Id: <4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:31:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
In-Reply-To: <65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

These being mostly meaningless to non-Linux, I don't think they
belong here.

Jan

> --- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> @@ -393,6 +393,28 @@ DEFINE_RING_TYPES(blkif, struct blkif_re
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
>  
> +/*
> + * Xen-defined major numbers for virtual block devices.
> + */
> +#define XEN_IDE0_MAJOR          3
> +#define XEN_IDE1_MAJOR          22
> +#define XEN_SCSI_DISK0_MAJOR    8
> +#define XEN_SCSI_DISK1_MAJOR    65
> +#define XEN_SCSI_DISK2_MAJOR    66
> +#define XEN_SCSI_DISK3_MAJOR    67
> +#define XEN_SCSI_DISK4_MAJOR    68
> +#define XEN_SCSI_DISK5_MAJOR    69
> +#define XEN_SCSI_DISK6_MAJOR    70
> +#define XEN_SCSI_DISK7_MAJOR    71
> +#define XEN_SCSI_DISK8_MAJOR    128
> +#define XEN_SCSI_DISK9_MAJOR    129
> +#define XEN_SCSI_DISK10_MAJOR   130
> +#define XEN_SCSI_DISK11_MAJOR   131
> +#define XEN_SCSI_DISK12_MAJOR   132
> +#define XEN_SCSI_DISK13_MAJOR   133
> +#define XEN_SCSI_DISK14_MAJOR   134
> +#define XEN_SCSI_DISK15_MAJOR   135
> +
>  #endif /* __XEN_PUBLIC_IO_BLKIF_H__ */
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:34:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJH4-0001UK-Dp; Fri, 03 Feb 2012 13:33:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJH3-0001Tr-NC
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:33:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328276031!12809380!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16841 invoked from network); 3 Feb 2012 13:33:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:33:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:33:51 +0000
Message-Id: <4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:33:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
In-Reply-To: <c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> @@ -187,6 +216,25 @@
>   *      The machine ABI rules governing the format of all ring request and
>   *      response structures.
>   *
> + * ring-page-order
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)

Why not just max-ring-page-order. After all, the value is meaningless
for a backend that only exposes max-ring-pages.

> + *      Notes:          1, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units
> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> + *      etc.).
> + *
> + * ring-pages
> + *      Values:         <uint32_t>
> + *      Default Value:  1
> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))

Similarly here - just max-ring-pages should do.

> + *      Notes:          2, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units of
> + *      machine pages.  The value must be a power of 2.
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:34:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJH4-0001UK-Dp; Fri, 03 Feb 2012 13:33:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJH3-0001Tr-NC
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:33:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328276031!12809380!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16841 invoked from network); 3 Feb 2012 13:33:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:33:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:33:51 +0000
Message-Id: <4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:33:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
In-Reply-To: <c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> @@ -187,6 +216,25 @@
>   *      The machine ABI rules governing the format of all ring request and
>   *      response structures.
>   *
> + * ring-page-order
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)

Why not just max-ring-page-order. After all, the value is meaningless
for a backend that only exposes max-ring-pages.

> + *      Notes:          1, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units
> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> + *      etc.).
> + *
> + * ring-pages
> + *      Values:         <uint32_t>
> + *      Default Value:  1
> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))

Similarly here - just max-ring-pages should do.

> + *      Notes:          2, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units of
> + *      machine pages.  The value must be a power of 2.
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:34:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJHj-0001Yh-S7; Fri, 03 Feb 2012 13:34:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJHi-0001Xv-7W
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:34:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328276070!15188257!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23273 invoked from network); 3 Feb 2012 13:34:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:34:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:34:30 +0000
Message-Id: <4F2BF0750200007800070EB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:34:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
In-Reply-To: <f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> xen/include/public/io/blkif.h |  106 ++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 103 insertions(+), 3 deletions(-)
> 
> 
> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>       Drivers must be updated to, at minimum, use
>       BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>       with this header file.

NAK. No backwards incompatible changes allowed in public headers.

Jan

> This extension first appeared in FreeBSD.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r c3609ad53946 -r f5c2e866c661 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> @@ -119,6 +119,29 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent requests supported by the backend.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  255
> + *
> + *      The maximum value of blkif_request.nr_segments supported by
> + *      the backend.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  255 * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by a
> + *      request type that accesses frontend memory (currently 
> BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *----------------------- Backend Device Identification -----------------------
>   * mode
>   *      Values:         "r" (read only), "w" (writable)
> @@ -235,6 +258,31 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
> + *
> + *      The maximum number of concurrent requests that will be issued by
> + *      the frontend.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  MIN(255, backend/max-request-segments)
> + *
> + *      The maximum value the frontend will set in the
> + *      blkif_request.nr_segments field.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  max-request-segments * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by
> + *      a request type that accesses frontend memory (currently 
> BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -392,11 +440,21 @@
>  #define BLKIF_OP_DISCARD           5
>  
>  /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
>   * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
>   * NB. This could be 12 if the ring indexes weren't stored in the same 
> page.
>   */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
>  
>  /*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -411,9 +469,25 @@ struct blkif_request_segment {
>      /* @last_sect: last sector in frame to transfer (inclusive).     */
>      uint8_t     first_sect, last_sect;
>  };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>  
>  /*
>   * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note:  Due to the way Xen request rings operate, the producer and
> + *        consumer indices of the ring must be incremented by the
> + *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + *        (e.g. a response to a 3 ring entry request must also consume
> + *        3 entries in the ring, even though only the first ring entry
> + *        in the response has any data.)
>   */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
> @@ -421,11 +495,22 @@ struct blkif_request {
>      blkif_vdev_t   handle;       /* only for read/write requests         */
>      uint64_t       id;           /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> -    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
>  };
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
>   * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
> @@ -462,6 +547,21 @@ typedef struct blkif_response blkif_resp
>   */
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
> +    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
> +    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
> +     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
> +    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:34:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJHj-0001Yh-S7; Fri, 03 Feb 2012 13:34:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJHi-0001Xv-7W
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:34:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328276070!15188257!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23273 invoked from network); 3 Feb 2012 13:34:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:34:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:34:30 +0000
Message-Id: <4F2BF0750200007800070EB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:34:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
In-Reply-To: <f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> xen/include/public/io/blkif.h |  106 ++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 103 insertions(+), 3 deletions(-)
> 
> 
> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>       Drivers must be updated to, at minimum, use
>       BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>       with this header file.

NAK. No backwards incompatible changes allowed in public headers.

Jan

> This extension first appeared in FreeBSD.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r c3609ad53946 -r f5c2e866c661 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Thu Feb 02 16:19:57 2012 -0700
> @@ -119,6 +119,29 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent requests supported by the backend.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  255
> + *
> + *      The maximum value of blkif_request.nr_segments supported by
> + *      the backend.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  255 * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by a
> + *      request type that accesses frontend memory (currently 
> BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *----------------------- Backend Device Identification -----------------------
>   * mode
>   *      Values:         "r" (read only), "w" (writable)
> @@ -235,6 +258,31 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
> + *
> + *      The maximum number of concurrent requests that will be issued by
> + *      the frontend.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  MIN(255, backend/max-request-segments)
> + *
> + *      The maximum value the frontend will set in the
> + *      blkif_request.nr_segments field.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  max-request-segments * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by
> + *      a request type that accesses frontend memory (currently 
> BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -392,11 +440,21 @@
>  #define BLKIF_OP_DISCARD           5
>  
>  /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
>   * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
>   * NB. This could be 12 if the ring indexes weren't stored in the same 
> page.
>   */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
>  
>  /*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -411,9 +469,25 @@ struct blkif_request_segment {
>      /* @last_sect: last sector in frame to transfer (inclusive).     */
>      uint8_t     first_sect, last_sect;
>  };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>  
>  /*
>   * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note:  Due to the way Xen request rings operate, the producer and
> + *        consumer indices of the ring must be incremented by the
> + *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + *        (e.g. a response to a 3 ring entry request must also consume
> + *        3 entries in the ring, even though only the first ring entry
> + *        in the response has any data.)
>   */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
> @@ -421,11 +495,22 @@ struct blkif_request {
>      blkif_vdev_t   handle;       /* only for read/write requests         */
>      uint64_t       id;           /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> -    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
>  };
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
>   * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
> @@ -462,6 +547,21 @@ typedef struct blkif_response blkif_resp
>   */
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
> +    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
> +    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
> +     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
> +    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:38:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJLK-0001sg-Ng; Fri, 03 Feb 2012 13:38:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RtJLJ-0001sG-6h
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:38:21 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328276294!12744969!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16191 invoked from network); 3 Feb 2012 13:38:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	3 Feb 2012 13:38:14 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q13Dc9De022473
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 08:38:09 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q13Dc7xE032302; Fri, 3 Feb 2012 08:38:07 -0500
Message-ID: <4F2BE39E.9030101@redhat.com>
Date: Fri, 03 Feb 2012 14:39:42 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>	<20120126181900.GB25572@phenom.dumpdata.com>	<1327660589.2585.14.camel@leeni.uk.xensource.com>	<4F2BD2CC.4050906@redhat.com>
	<4F2BDA4C.7060601@redhat.com>
	<4F2BEEA70200007800070E81@nat28.tlf.novell.com>
In-Reply-To: <4F2BEEA70200007800070E81@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen-netfront:
	correct	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 14:26, Jan Beulich wrote:
>>>> On 03.02.12 at 13:59, Laszlo Ersek<lersek@redhat.com>  wrote:

>> (Eyeballing the source makes me think
>>
>>     NET_TX_RING_SIZE == (4096 - 16 - 48) / (5 * 4) == 201
>>     NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 4) == 252
>
> NET_TX_RING_SIZE == (4096 - 16 - 48) / (6 * 2) == 336
> NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 2) == 504

Sorry, I wasn't sure if gcc would pack them without 
__attribute__((packed)) :) Dumb mistake, admittedly.

Thanks,
Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:38:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJLK-0001sg-Ng; Fri, 03 Feb 2012 13:38:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RtJLJ-0001sG-6h
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:38:21 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328276294!12744969!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16191 invoked from network); 3 Feb 2012 13:38:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	3 Feb 2012 13:38:14 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q13Dc9De022473
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 08:38:09 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q13Dc7xE032302; Fri, 3 Feb 2012 08:38:07 -0500
Message-ID: <4F2BE39E.9030101@redhat.com>
Date: Fri, 03 Feb 2012 14:39:42 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Mnenhy/0.8.4
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>	<20120126181900.GB25572@phenom.dumpdata.com>	<1327660589.2585.14.camel@leeni.uk.xensource.com>	<4F2BD2CC.4050906@redhat.com>
	<4F2BDA4C.7060601@redhat.com>
	<4F2BEEA70200007800070E81@nat28.tlf.novell.com>
In-Reply-To: <4F2BEEA70200007800070E81@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen-netfront:
	correct	MAX_TX_TARGET	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 14:26, Jan Beulich wrote:
>>>> On 03.02.12 at 13:59, Laszlo Ersek<lersek@redhat.com>  wrote:

>> (Eyeballing the source makes me think
>>
>>     NET_TX_RING_SIZE == (4096 - 16 - 48) / (5 * 4) == 201
>>     NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 4) == 252
>
> NET_TX_RING_SIZE == (4096 - 16 - 48) / (6 * 2) == 336
> NET_RX_RING_SIZE == (4096 - 16 - 48) / (4 * 2) == 504

Sorry, I wasn't sure if gcc would pack them without 
__attribute__((packed)) :) Dumb mistake, admittedly.

Thanks,
Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:43:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 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.xensource.com>)
	id 1RtJPf-00023E-NM; Fri, 03 Feb 2012 13:42:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RtJPd-00022g-Oq; Fri, 03 Feb 2012 13:42:50 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328276562!13046231!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21262 invoked from network); 3 Feb 2012 13:42:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 13:42:42 -0000
Received: by wibhm2 with SMTP id hm2so7261341wib.30
	for <multiple recipients>; Fri, 03 Feb 2012 05:42:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=rXJSwMJJcdGbI5GWy5kM1PwYR/7sBouCMtRkaP3Q76I=;
	b=rrNsi7pEC3K8eivaQS84H7FeQTF0yuOWEa+suHdoVum6fgvYXNp+230/gS2ZSV4v6v
	l1lpR+X7Uqf1/2Bi25p4/JzDi7hHitELQFvafFvPJSXhhvFJnitaaDfGqR2kdwEokcbx
	wrvqRaYFbAcZVgAML0aoY+HXQfAK06BjvNOOQ=
Received: by 10.180.89.71 with SMTP id bm7mr24788379wib.20.1328276562323;
	Fri, 03 Feb 2012 05:42:42 -0800 (PST)
Received: from [172.16.26.10] (d54C6D43E.access.telenet.be. [84.198.212.62])
	by mx.google.com with ESMTPS id hc10sm6629996wib.8.2012.02.03.05.42.38
	(version=SSLv3 cipher=OTHER); Fri, 03 Feb 2012 05:42:41 -0800 (PST)
Message-ID: <4F2BE44B.5030003@xen.org>
Date: Fri, 03 Feb 2012 13:42:35 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: [Xen-devel] Give us feedback for the new Xen.org site
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5185850873046149366=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Dear Community Members,

I am finally able to build a new website for Xen.org. The aim of this 
work is to create an engaging and integrated community web site that 
invites participation and acts as a portal for Xen users, developers and 
companies in the eco-system. You can give input on the site by going to 
http://wiki.xen.org/wiki/New_Xen_Website

The new site will have several main areas:

The home page, which mainly acts as an aggregator for news and activity 
happening in the community. This should make it easier for newcomers to 
Xen, to have a brief look and get a feeling of the vibrancy of the Xen 
community.There is actually a lot of activity today: it is merely 
obscured and hidden as the activity is dispersed to many places. The 
home page will also provide a window into the new Xen.org blog, as well 
as sections for Xen events, etc.

An area for users. This area will provide information about Xen and Xen 
projects, will help you learn about Xen, will point people to downloads 
and Linux/Unix distributions that contain Xen, will help you find 
documentation,will help you get help and support, etc. Xen has 
traditionally been a very developer focused community.As a consequence 
we have not supported our users that well. I have some open questions in 
this area, where I will be looking for your input. For example: is there 
a preference for mailing lists, forums, or stackoverflow like 
functionality? How should we best link to Linux distributions and other 
projects that distribute Xen?

An eco-system area: this is essentially a searchable directory of 
product and projects that use Xen, modify Xen, build on top of Xen, 
distribute Xen, etc. It is also a directory of research around Xen and 
services such as consultancy, training, hosting and cloud vendors that 
are built on top of Xen. This section will be fairly interactive: the 
intention is that if you are a vendor, you can add an entry to the 
directory which will be approved by a moderator moderator before 
publication. As a user of the directory, you can rate, recommend, 
comment on vendors, products, projects, etc.

An area for developers: this contains project descriptions, links to 
downloads, codelines, information about governance, mailing lists, etc.

Other changes: the site will have the capability to register users. 
Generally, all areas of the site will be accessible without any user 
account, except for areas where you need to write to the site and 
identification is thus necessary. We envisage that we will be able to 
implement single sign-on capability for the new site and at least theXen 
wiki. There will be user profiles that allow you to provide information 
about how you use Xen, but ultimately you only have to provide what you 
are comfortable with. The idea is for example that I can implement 
functionality such as the old community spotlight section by just 
maintaining a list of profile names. Name, pictures, bio, etc. would be 
managed and maintained by you. I am also looking at capabilities, such 
as being able to send newsletters, to registered site users.

*Where I need your input*

**

We will consult you on questions such as look and feel, on a new or 
revamped Xen logo, on new panda's, on navigation, on some of the 
headlines and taglines.

In some areas we do not quite know what you want from Xen.org: e.g. 
should we have a user mailing list, user fora and/or support forum 
functionality similar to stackoverflow? Should we make the developer 
mailing lists accessible via the website?

I also wanted to get views on whether it is OK to require logging into 
the site before you download a Xen or XCP binary. My thinking is that 
this is not good, but that it is OK to ask you nicely to sign in and/or 
create an account before you download. Having some information about its 
users is important to maintain the long term health of an open source 
project: today Xen has very little information about its users. 
Mainly,because we never asked. Providing information is an easy way how 
you can give something back to the community.

Another area where we will consult you is on how we migrate you from 
existing systems to the new one. Is it OK, to migrate existing users to 
the new site (using some kind of opt-out or activation scheme)? Is it 
not, etc.?

Links to feedback sheets, mockups, etc. can be found here: 
http://wiki.xen.org/wiki/New_Xen_Website

Looking forward to hear from you

Best Regards
Lars
**


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

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-1">
    <!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-GB</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin-top:0cm;
	mso-para-margin-right:0cm;
	mso-para-margin-bottom:10.0pt;
	mso-para-margin-left:0cm;
	line-height:115%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;
	mso-fareast-language:EN-US;}
</style>
<![endif]-->
    <p class="MsoNormal">Dear Community Members,<o:p></o:p></p>
    <p class="MsoNormal">I am finally able to build a new website for
      Xen.org. The
      aim of this work is to create an engaging and integrated community
      web site
      that invites participation and acts as a portal for Xen users,
      developers and
      companies in the eco-system. You can give input on the site by
      going to <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/New_Xen_Website">http://wiki.xen.org/wiki/New_Xen_Website</a><br>
    </p>
    <p class="MsoNormal">The new site will have several main areas:<o:p></o:p></p>
    <p class="MsoNormal">The home page, which mainly acts as an
      aggregator for news
      and activity happening in the community. This should make it
      easier for
      newcomers to Xen, to have a brief look and get a feeling of the
      vibrancy of the
      Xen community.<span style="mso-spacerun:yes">&nbsp; </span>There is
      actually a lot
      of activity today: it is merely obscured and hidden as the
      activity is
      dispersed to many places. The home page will also provide a window
      into the new
      Xen.org blog, as well as sections for Xen events, etc.<o:p></o:p></p>
    <p class="MsoNormal">An area for users. This area will provide
      information
      about Xen and Xen projects, will help you learn about Xen, will
      point people to
      downloads and Linux/Unix distributions that contain Xen, will help
      you find
      documentation,<span style="mso-spacerun:yes">&nbsp; </span>will help
      you get help
      and support, etc. Xen has traditionally been a very developer
      focused
      community.<span style="mso-spacerun:yes">&nbsp; </span>As a
      consequence we have not
      supported our users that well. I have some open questions in this
      area, where I
      will be looking for your input. For example: is there a preference
      for mailing
      lists, forums, or stackoverflow like functionality? How should we
      best link to
      Linux distributions and other projects that distribute Xen?<o:p></o:p></p>
    <p class="MsoNormal">An eco-system area: this is essentially a
      searchable
      directory of product and projects that use Xen, modify Xen, build
      on top of
      Xen, distribute Xen, etc. It is also a directory of research
      around Xen and
      services such as consultancy, training, hosting and cloud vendors
      that are
      built on top of Xen. This section will be fairly interactive: the
      intention is
      that if you are a vendor, you can add an entry to the directory
      which will be
      approved by a moderator moderator before publication. As a user of
      the
      directory, you can rate, recommend, comment on vendors, products,
      projects,
      etc.<o:p></o:p></p>
    <p class="MsoNormal">An area for developers: this contains project
      descriptions, links to downloads, codelines, information about
      governance,
      mailing lists, etc.<o:p></o:p></p>
    <p class="MsoNormal">Other changes: the site will have the
      capability to
      register users. Generally, all areas of the site will be
      accessible without any
      user account, except for areas where you need to write to the site
      and
      identification is thus necessary. We envisage that we will be able
      to implement
      single sign-on capability for the new site and at least the<span
        style="mso-spacerun:yes">&nbsp; </span>Xen wiki. There will be user
      profiles that
      allow you to provide information about how you use Xen, but
      ultimately you only
      have to provide what you are comfortable with. The idea is for
      example that I
      can implement functionality such as the old community spotlight
      section by just
      maintaining a list of profile names. Name, pictures, bio, etc.
      would be managed
      and maintained by you. I am also looking at capabilities, such as
      being able to
      send newsletters, to registered site users.<o:p></o:p></p>
    <p class="MsoNormal"><b>Where I need your input<o:p></o:p></b></p>
    <b>
    </b>
    <p class="MsoNormal">We will consult you on questions such as look
      and feel, on a
      new or revamped Xen logo, on new panda's, on navigation, on some
      of the
      headlines and taglines.<o:p></o:p></p>
    <p class="MsoNormal"><o:p></o:p>In some areas we do not quite know
      what you want from
      Xen.org: e.g. should we have a user mailing list, user fora and/or
      support
      forum functionality similar to stackoverflow? Should we make the
      developer
      mailing lists accessible via the website? <o:p></o:p>
    </p>
    <p class="MsoNormal">I also wanted to get views on whether it is OK
      to require
      logging into the site before you download a Xen or XCP binary. My
      thinking is
      that this is not good, but that it is OK to ask you nicely to sign
      in and/or
      create an account before you download. Having some information
      about its users
      is important to maintain the long term health of an open source
      project: today
      Xen has very little information about its users. Mainly,<span
        style="mso-spacerun:yes">&nbsp; </span>because we never asked.
      Providing information
      is an easy way how you can give something back to the community.<o:p></o:p></p>
    <p class="MsoNormal">Another area where we will consult you is on
      how we migrate
      you from existing systems to the new one. Is it OK, to migrate
      existing users
      to the new site (using some kind of opt-out or activation scheme)?
      Is it not,
      etc.?<br>
      <o:p></o:p></p>
    <p class="MsoNormal">Links to feedback sheets, mockups, etc. can be
      found here: <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/New_Xen_Website">http://wiki.xen.org/wiki/New_Xen_Website</a><br>
    </p>
    <p class="MsoNormal">Looking forward to hear from you<br>
    </p>
    <p class="MsoNormal">Best Regards<br>
      Lars<br>
      <b></b></p>
    <o:p></o:p>
    <meta name="ProgId" content="Word.Document">
    <meta name="Generator" content="Microsoft Word 14">
    <meta name="Originator" content="Microsoft Word 14">
    <link rel="File-List"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">
    <link rel="themeData"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx">
    <link rel="colorSchemeMapping"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">
    <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:10.0pt;
	margin-left:0cm;
	line-height:115%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;
	mso-fareast-language:EN-US;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;
	mso-fareast-language:EN-US;}
.MsoPapDefault
	{mso-style-type:export-only;
	margin-bottom:10.0pt;
	line-height:115%;}
@page WordSection1
	{size:595.3pt 841.9pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
  </body>
</html>

--------------070106040103040206070901--


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

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

--===============5185850873046149366==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:43:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 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.xensource.com>)
	id 1RtJPf-00023E-NM; Fri, 03 Feb 2012 13:42:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RtJPd-00022g-Oq; Fri, 03 Feb 2012 13:42:50 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328276562!13046231!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21262 invoked from network); 3 Feb 2012 13:42:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 13:42:42 -0000
Received: by wibhm2 with SMTP id hm2so7261341wib.30
	for <multiple recipients>; Fri, 03 Feb 2012 05:42:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=rXJSwMJJcdGbI5GWy5kM1PwYR/7sBouCMtRkaP3Q76I=;
	b=rrNsi7pEC3K8eivaQS84H7FeQTF0yuOWEa+suHdoVum6fgvYXNp+230/gS2ZSV4v6v
	l1lpR+X7Uqf1/2Bi25p4/JzDi7hHitELQFvafFvPJSXhhvFJnitaaDfGqR2kdwEokcbx
	wrvqRaYFbAcZVgAML0aoY+HXQfAK06BjvNOOQ=
Received: by 10.180.89.71 with SMTP id bm7mr24788379wib.20.1328276562323;
	Fri, 03 Feb 2012 05:42:42 -0800 (PST)
Received: from [172.16.26.10] (d54C6D43E.access.telenet.be. [84.198.212.62])
	by mx.google.com with ESMTPS id hc10sm6629996wib.8.2012.02.03.05.42.38
	(version=SSLv3 cipher=OTHER); Fri, 03 Feb 2012 05:42:41 -0800 (PST)
Message-ID: <4F2BE44B.5030003@xen.org>
Date: Fri, 03 Feb 2012 13:42:35 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: [Xen-devel] Give us feedback for the new Xen.org site
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5185850873046149366=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Dear Community Members,

I am finally able to build a new website for Xen.org. The aim of this 
work is to create an engaging and integrated community web site that 
invites participation and acts as a portal for Xen users, developers and 
companies in the eco-system. You can give input on the site by going to 
http://wiki.xen.org/wiki/New_Xen_Website

The new site will have several main areas:

The home page, which mainly acts as an aggregator for news and activity 
happening in the community. This should make it easier for newcomers to 
Xen, to have a brief look and get a feeling of the vibrancy of the Xen 
community.There is actually a lot of activity today: it is merely 
obscured and hidden as the activity is dispersed to many places. The 
home page will also provide a window into the new Xen.org blog, as well 
as sections for Xen events, etc.

An area for users. This area will provide information about Xen and Xen 
projects, will help you learn about Xen, will point people to downloads 
and Linux/Unix distributions that contain Xen, will help you find 
documentation,will help you get help and support, etc. Xen has 
traditionally been a very developer focused community.As a consequence 
we have not supported our users that well. I have some open questions in 
this area, where I will be looking for your input. For example: is there 
a preference for mailing lists, forums, or stackoverflow like 
functionality? How should we best link to Linux distributions and other 
projects that distribute Xen?

An eco-system area: this is essentially a searchable directory of 
product and projects that use Xen, modify Xen, build on top of Xen, 
distribute Xen, etc. It is also a directory of research around Xen and 
services such as consultancy, training, hosting and cloud vendors that 
are built on top of Xen. This section will be fairly interactive: the 
intention is that if you are a vendor, you can add an entry to the 
directory which will be approved by a moderator moderator before 
publication. As a user of the directory, you can rate, recommend, 
comment on vendors, products, projects, etc.

An area for developers: this contains project descriptions, links to 
downloads, codelines, information about governance, mailing lists, etc.

Other changes: the site will have the capability to register users. 
Generally, all areas of the site will be accessible without any user 
account, except for areas where you need to write to the site and 
identification is thus necessary. We envisage that we will be able to 
implement single sign-on capability for the new site and at least theXen 
wiki. There will be user profiles that allow you to provide information 
about how you use Xen, but ultimately you only have to provide what you 
are comfortable with. The idea is for example that I can implement 
functionality such as the old community spotlight section by just 
maintaining a list of profile names. Name, pictures, bio, etc. would be 
managed and maintained by you. I am also looking at capabilities, such 
as being able to send newsletters, to registered site users.

*Where I need your input*

**

We will consult you on questions such as look and feel, on a new or 
revamped Xen logo, on new panda's, on navigation, on some of the 
headlines and taglines.

In some areas we do not quite know what you want from Xen.org: e.g. 
should we have a user mailing list, user fora and/or support forum 
functionality similar to stackoverflow? Should we make the developer 
mailing lists accessible via the website?

I also wanted to get views on whether it is OK to require logging into 
the site before you download a Xen or XCP binary. My thinking is that 
this is not good, but that it is OK to ask you nicely to sign in and/or 
create an account before you download. Having some information about its 
users is important to maintain the long term health of an open source 
project: today Xen has very little information about its users. 
Mainly,because we never asked. Providing information is an easy way how 
you can give something back to the community.

Another area where we will consult you is on how we migrate you from 
existing systems to the new one. Is it OK, to migrate existing users to 
the new site (using some kind of opt-out or activation scheme)? Is it 
not, etc.?

Links to feedback sheets, mockups, etc. can be found here: 
http://wiki.xen.org/wiki/New_Xen_Website

Looking forward to hear from you

Best Regards
Lars
**


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

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-1">
    <!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-GB</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin-top:0cm;
	mso-para-margin-right:0cm;
	mso-para-margin-bottom:10.0pt;
	mso-para-margin-left:0cm;
	line-height:115%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;
	mso-fareast-language:EN-US;}
</style>
<![endif]-->
    <p class="MsoNormal">Dear Community Members,<o:p></o:p></p>
    <p class="MsoNormal">I am finally able to build a new website for
      Xen.org. The
      aim of this work is to create an engaging and integrated community
      web site
      that invites participation and acts as a portal for Xen users,
      developers and
      companies in the eco-system. You can give input on the site by
      going to <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/New_Xen_Website">http://wiki.xen.org/wiki/New_Xen_Website</a><br>
    </p>
    <p class="MsoNormal">The new site will have several main areas:<o:p></o:p></p>
    <p class="MsoNormal">The home page, which mainly acts as an
      aggregator for news
      and activity happening in the community. This should make it
      easier for
      newcomers to Xen, to have a brief look and get a feeling of the
      vibrancy of the
      Xen community.<span style="mso-spacerun:yes">&nbsp; </span>There is
      actually a lot
      of activity today: it is merely obscured and hidden as the
      activity is
      dispersed to many places. The home page will also provide a window
      into the new
      Xen.org blog, as well as sections for Xen events, etc.<o:p></o:p></p>
    <p class="MsoNormal">An area for users. This area will provide
      information
      about Xen and Xen projects, will help you learn about Xen, will
      point people to
      downloads and Linux/Unix distributions that contain Xen, will help
      you find
      documentation,<span style="mso-spacerun:yes">&nbsp; </span>will help
      you get help
      and support, etc. Xen has traditionally been a very developer
      focused
      community.<span style="mso-spacerun:yes">&nbsp; </span>As a
      consequence we have not
      supported our users that well. I have some open questions in this
      area, where I
      will be looking for your input. For example: is there a preference
      for mailing
      lists, forums, or stackoverflow like functionality? How should we
      best link to
      Linux distributions and other projects that distribute Xen?<o:p></o:p></p>
    <p class="MsoNormal">An eco-system area: this is essentially a
      searchable
      directory of product and projects that use Xen, modify Xen, build
      on top of
      Xen, distribute Xen, etc. It is also a directory of research
      around Xen and
      services such as consultancy, training, hosting and cloud vendors
      that are
      built on top of Xen. This section will be fairly interactive: the
      intention is
      that if you are a vendor, you can add an entry to the directory
      which will be
      approved by a moderator moderator before publication. As a user of
      the
      directory, you can rate, recommend, comment on vendors, products,
      projects,
      etc.<o:p></o:p></p>
    <p class="MsoNormal">An area for developers: this contains project
      descriptions, links to downloads, codelines, information about
      governance,
      mailing lists, etc.<o:p></o:p></p>
    <p class="MsoNormal">Other changes: the site will have the
      capability to
      register users. Generally, all areas of the site will be
      accessible without any
      user account, except for areas where you need to write to the site
      and
      identification is thus necessary. We envisage that we will be able
      to implement
      single sign-on capability for the new site and at least the<span
        style="mso-spacerun:yes">&nbsp; </span>Xen wiki. There will be user
      profiles that
      allow you to provide information about how you use Xen, but
      ultimately you only
      have to provide what you are comfortable with. The idea is for
      example that I
      can implement functionality such as the old community spotlight
      section by just
      maintaining a list of profile names. Name, pictures, bio, etc.
      would be managed
      and maintained by you. I am also looking at capabilities, such as
      being able to
      send newsletters, to registered site users.<o:p></o:p></p>
    <p class="MsoNormal"><b>Where I need your input<o:p></o:p></b></p>
    <b>
    </b>
    <p class="MsoNormal">We will consult you on questions such as look
      and feel, on a
      new or revamped Xen logo, on new panda's, on navigation, on some
      of the
      headlines and taglines.<o:p></o:p></p>
    <p class="MsoNormal"><o:p></o:p>In some areas we do not quite know
      what you want from
      Xen.org: e.g. should we have a user mailing list, user fora and/or
      support
      forum functionality similar to stackoverflow? Should we make the
      developer
      mailing lists accessible via the website? <o:p></o:p>
    </p>
    <p class="MsoNormal">I also wanted to get views on whether it is OK
      to require
      logging into the site before you download a Xen or XCP binary. My
      thinking is
      that this is not good, but that it is OK to ask you nicely to sign
      in and/or
      create an account before you download. Having some information
      about its users
      is important to maintain the long term health of an open source
      project: today
      Xen has very little information about its users. Mainly,<span
        style="mso-spacerun:yes">&nbsp; </span>because we never asked.
      Providing information
      is an easy way how you can give something back to the community.<o:p></o:p></p>
    <p class="MsoNormal">Another area where we will consult you is on
      how we migrate
      you from existing systems to the new one. Is it OK, to migrate
      existing users
      to the new site (using some kind of opt-out or activation scheme)?
      Is it not,
      etc.?<br>
      <o:p></o:p></p>
    <p class="MsoNormal">Links to feedback sheets, mockups, etc. can be
      found here: <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/New_Xen_Website">http://wiki.xen.org/wiki/New_Xen_Website</a><br>
    </p>
    <p class="MsoNormal">Looking forward to hear from you<br>
    </p>
    <p class="MsoNormal">Best Regards<br>
      Lars<br>
      <b></b></p>
    <o:p></o:p>
    <meta name="ProgId" content="Word.Document">
    <meta name="Generator" content="Microsoft Word 14">
    <meta name="Originator" content="Microsoft Word 14">
    <link rel="File-List"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">
    <link rel="themeData"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx">
    <link rel="colorSchemeMapping"
href="file:///C:%5CUsers%5CLARSK%7E1.CIT%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">
    <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:10.0pt;
	margin-left:0cm;
	line-height:115%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;
	mso-fareast-language:EN-US;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;
	mso-fareast-language:EN-US;}
.MsoPapDefault
	{mso-style-type:export-only;
	margin-bottom:10.0pt;
	line-height:115%;}
@page WordSection1
	{size:595.3pt 841.9pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
  </body>
</html>

--------------070106040103040206070901--


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

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

--===============5185850873046149366==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:44:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJRJ-0002KV-Bn; Fri, 03 Feb 2012 13:44:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJRH-0002JF-Ss
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:44:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328276665!13824156!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23858 invoked from network); 3 Feb 2012 13:44: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:44:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:44:25 +0000
Message-Id: <4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:44:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F2BE17D.2010207@citrix.com>
In-Reply-To: <4F2BE17D.2010207@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] IO-APIC: tweak debug key info formatting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 14:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>Furthermore, printing fewer characters makes it less likely that the
>serial buffer will overflow resulting in loss of critical debugging
>information.

For that part, shortening some of the strings would certainly be
desirable too (delivery_mode being the worst).

>--- a/xen/arch/x86/io_apic.c
>+++ b/xen/arch/x86/io_apic.c
>@@ -2406,13 +2406,13 @@ void dump_ioapic_irq_info(void)
>             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
>             spin_unlock_irqrestore(&ioapic_lock, flags);
> 
>-            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
>-                   "delivery_status=%d, polarity=%d, irr=%d, "
>-                   "trigger=%s, mask=%d, dest_id:%d\n",
>+            printk("vector=%3u delivery_mode=%u dest_mode=%s "

Could you please print the vector as %02x instead? We should really
do this consistently everywhere, and vectors in decimal are pretty
meaningless anyway (as one will always need to convert them for
purposes of priority determination or comparison with #define-s in
the sources).

Jan

>+                   "delivery_status=%d polarity=%d irr=%d "
>+                   "trigger=%s mask=%d dest_id:%d\n",
>                    rte.vector, rte.delivery_mode,
>-                   rte.dest_mode ? "logical" : "physical",
>+                   rte.dest_mode ? "logical " : "physical",
>                    rte.delivery_status, rte.polarity, rte.irr,
>-                   rte.trigger ? "level" : "edge", rte.mask,
>+                   rte.trigger ? "level" : "edge ", rte.mask,
>                    rte.dest.logical.logical_dest);
> 
>             if ( entry->next == 0 )



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:44:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJRJ-0002KV-Bn; Fri, 03 Feb 2012 13:44:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJRH-0002JF-Ss
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:44:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328276665!13824156!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23858 invoked from network); 3 Feb 2012 13:44: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 13:44:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 13:44:25 +0000
Message-Id: <4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 13:44:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F2BE17D.2010207@citrix.com>
In-Reply-To: <4F2BE17D.2010207@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] IO-APIC: tweak debug key info formatting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 14:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>Furthermore, printing fewer characters makes it less likely that the
>serial buffer will overflow resulting in loss of critical debugging
>information.

For that part, shortening some of the strings would certainly be
desirable too (delivery_mode being the worst).

>--- a/xen/arch/x86/io_apic.c
>+++ b/xen/arch/x86/io_apic.c
>@@ -2406,13 +2406,13 @@ void dump_ioapic_irq_info(void)
>             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
>             spin_unlock_irqrestore(&ioapic_lock, flags);
> 
>-            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
>-                   "delivery_status=%d, polarity=%d, irr=%d, "
>-                   "trigger=%s, mask=%d, dest_id:%d\n",
>+            printk("vector=%3u delivery_mode=%u dest_mode=%s "

Could you please print the vector as %02x instead? We should really
do this consistently everywhere, and vectors in decimal are pretty
meaningless anyway (as one will always need to convert them for
purposes of priority determination or comparison with #define-s in
the sources).

Jan

>+                   "delivery_status=%d polarity=%d irr=%d "
>+                   "trigger=%s mask=%d dest_id:%d\n",
>                    rte.vector, rte.delivery_mode,
>-                   rte.dest_mode ? "logical" : "physical",
>+                   rte.dest_mode ? "logical " : "physical",
>                    rte.delivery_status, rte.polarity, rte.irr,
>-                   rte.trigger ? "level" : "edge", rte.mask,
>+                   rte.trigger ? "level" : "edge ", rte.mask,
>                    rte.dest.logical.logical_dest);
> 
>             if ( entry->next == 0 )



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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:49:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJW0-00038I-5b; Fri, 03 Feb 2012 13:49:24 +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 1RtJVy-000387-Qf
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:49:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328276891!62476978!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4378 invoked from network); 3 Feb 2012 13:48:12 -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;
	3 Feb 2012 13:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180284562"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:49:20 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:49:19 -0500
Message-ID: <4F2BE5DE.6060908@citrix.com>
Date: Fri, 3 Feb 2012 13:49:18 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2BE17D.2010207@citrix.com>
	<4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
In-Reply-To: <4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] IO-APIC: tweak debug key info formatting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 03/02/12 13:44, Jan Beulich wrote:
>>>> On 03.02.12 at 14:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Furthermore, printing fewer characters makes it less likely that the
>> serial buffer will overflow resulting in loss of critical debugging
>> information.
> For that part, shortening some of the strings would certainly be
> desirable too (delivery_mode being the worst).

I was considering that as well, but just wanted to get the alignment
issue sorted first.  I will respin the patch with much shorter lines.

>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -2406,13 +2406,13 @@ void dump_ioapic_irq_info(void)
>>             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
>>             spin_unlock_irqrestore(&ioapic_lock, flags);
>>
>> -            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
>> -                   "delivery_status=%d, polarity=%d, irr=%d, "
>> -                   "trigger=%s, mask=%d, dest_id:%d\n",
>> +            printk("vector=%3u delivery_mode=%u dest_mode=%s "
> Could you please print the vector as %02x instead? We should really
> do this consistently everywhere, and vectors in decimal are pretty
> meaningless anyway (as one will always need to convert them for
> purposes of priority determination or comparison with #define-s in
> the sources).

Very true - I agree as well.

> Jan
>
>> +                   "delivery_status=%d polarity=%d irr=%d "
>> +                   "trigger=%s mask=%d dest_id:%d\n",
>>                    rte.vector, rte.delivery_mode,
>> -                   rte.dest_mode ? "logical" : "physical",
>> +                   rte.dest_mode ? "logical " : "physical",
>>                    rte.delivery_status, rte.polarity, rte.irr,
>> -                   rte.trigger ? "level" : "edge", rte.mask,
>> +                   rte.trigger ? "level" : "edge ", rte.mask,
>>                    rte.dest.logical.logical_dest);
>>
>>             if ( entry->next == 0 )
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:49:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJW0-00038I-5b; Fri, 03 Feb 2012 13:49:24 +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 1RtJVy-000387-Qf
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 13:49:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328276891!62476978!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4378 invoked from network); 3 Feb 2012 13:48:12 -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;
	3 Feb 2012 13:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180284562"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 08:49:20 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	08:49:19 -0500
Message-ID: <4F2BE5DE.6060908@citrix.com>
Date: Fri, 3 Feb 2012 13:49:18 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2BE17D.2010207@citrix.com>
	<4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
In-Reply-To: <4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] IO-APIC: tweak debug key info formatting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 03/02/12 13:44, Jan Beulich wrote:
>>>> On 03.02.12 at 14:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Furthermore, printing fewer characters makes it less likely that the
>> serial buffer will overflow resulting in loss of critical debugging
>> information.
> For that part, shortening some of the strings would certainly be
> desirable too (delivery_mode being the worst).

I was considering that as well, but just wanted to get the alignment
issue sorted first.  I will respin the patch with much shorter lines.

>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -2406,13 +2406,13 @@ void dump_ioapic_irq_info(void)
>>             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
>>             spin_unlock_irqrestore(&ioapic_lock, flags);
>>
>> -            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
>> -                   "delivery_status=%d, polarity=%d, irr=%d, "
>> -                   "trigger=%s, mask=%d, dest_id:%d\n",
>> +            printk("vector=%3u delivery_mode=%u dest_mode=%s "
> Could you please print the vector as %02x instead? We should really
> do this consistently everywhere, and vectors in decimal are pretty
> meaningless anyway (as one will always need to convert them for
> purposes of priority determination or comparison with #define-s in
> the sources).

Very true - I agree as well.

> Jan
>
>> +                   "delivery_status=%d polarity=%d irr=%d "
>> +                   "trigger=%s mask=%d dest_id:%d\n",
>>                    rte.vector, rte.delivery_mode,
>> -                   rte.dest_mode ? "logical" : "physical",
>> +                   rte.dest_mode ? "logical " : "physical",
>>                    rte.delivery_status, rte.polarity, rte.irr,
>> -                   rte.trigger ? "level" : "edge", rte.mask,
>> +                   rte.trigger ? "level" : "edge ", rte.mask,
>>                    rte.dest.logical.logical_dest);
>>
>>             if ( entry->next == 0 )
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJfi-0003WP-Eh; Fri, 03 Feb 2012 13:59:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patrick.wilbur@gmail.com>) id 1Rt27S-0000nc-9K
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:14:54 +0000
X-Env-Sender: patrick.wilbur@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328210087!13330327!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29162 invoked from network); 2 Feb 2012 19:14:47 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 19:14:47 -0000
Received: by bkbzv3 with SMTP id zv3so4907317bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 11:14:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:cc:content-type;
	bh=147gOvw88SvgMchtudRHVtW4bTH/Sy90ZnMVVF+ZrEc=;
	b=ckjG3gQXdgr0OkHqMyDCdu/PmVkM2OOirkoMH66yPUjz0AsiuwEa+UB9N+T+Uj6niA
	xt7h1D1EAD+P/eaayyDveltz+QpKzfPsXbvGwsa4ctH6OpAqfjECxyv2TXFsnMbgDwlp
	AfwEriZYsCO8gePKZZAHbs+gS6x7lOaaOgUFk=
Received: by 10.204.16.136 with SMTP id o8mr1982245bka.119.1328210087367; Thu,
	02 Feb 2012 11:14:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.116.146 with HTTP; Thu, 2 Feb 2012 11:14:27 -0800 (PST)
From: Patrick Wilbur <patrick.wilbur@gmail.com>
Date: Thu, 2 Feb 2012 14:14:27 -0500
Message-ID: <CABFkyn9EYfq7T0cmDDGyUQkpCce7_unLkzOrgDFDDhJHQhtTzw@mail.gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Cc: andres@lagarcavilla.org
Subject: [Xen-devel] Cloning a VM and copy-on-write deduplicating memory
 using CoW page sharing in Xen 4+
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3805093157115238287=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3805093157115238287==
Content-Type: multipart/alternative; boundary=00032555a60a71d49004b80002e8

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

Hey all,
Hey Andres,

I'm looking to clone a VM into several extremely-similar VMs, and I'm
hoping to also make use of your lovely new CoW page sharing capabilities in
Xen 4.

>From my understanding of a previous thread where Andres described the
process of sharing/coalescing memory between VMs, it sounds like I will
need to "manually" coalesce each page using a homebrew tool of mine.  The
issue I have with doing this is it seems like I'd need to pause, save mem,
load mem in a new VM, coalesce, and resume two VMs, which seems painful and
wasteful of a process for cloning!

Is there an easier way to do this, or should we add a new feature for CoW
cloning of VMs in Xen via a userspace tool?

Thanks,
Pat Wilbur & team


--
Patrick F. Wilbur
Researcher, Consultant, Educator,
Computer Science Graduate at Clarkson University

DONE RIGHT THE FIRST TIME: Consulting and hiring information:
http://pdub.net/consulting/ & http://pdub.net/hiring/

patrick.wilbur@gmail.com
wilburpf@clarkson.edu

Check out our book: http://runningxen.com
My website: http://pdub.net

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

Hey all,<div>Hey Andres,</div><div><br></div><div>I&#39;m looking to clone =
a VM into several extremely-similar VMs, and I&#39;m hoping to also make us=
e of your lovely new CoW page sharing capabilities in Xen 4. =A0</div><div>

<br></div><div>From my understanding of a previous thread where Andres desc=
ribed the process of sharing/coalescing memory between VMs, it sounds like =
I will need to &quot;manually&quot; coalesce each page using a homebrew too=
l of mine. =A0The issue I have with doing this is it seems like I&#39;d nee=
d to pause, save mem, load mem in a new VM, coalesce, and resume two VMs, w=
hich seems painful and wasteful of a process for cloning!</div>

<div><br></div><div>Is there an easier way to do this, or should we add a n=
ew feature for CoW cloning of VMs in Xen via a userspace tool?</div><div><b=
r></div><div>Thanks,</div><div>Pat Wilbur &amp; team<br clear=3D"all"><br>

<br>--<br>Patrick F. Wilbur<div>Researcher, Consultant, Educator,<br>Comput=
er Science Graduate at=A0Clarkson University<div><br></div><div>DONE RIGHT =
THE FIRST TIME: Consulting and hiring information: <a href=3D"http://pdub.n=
et/consulting/" target=3D"_blank">http://pdub.net/consulting/</a>=A0&amp;=
=A0<a href=3D"http://pdub.net/hiring/" target=3D"_blank">http://pdub.net/hi=
ring/</a><br>

<br><a href=3D"mailto:patrick.wilbur@gmail.com" target=3D"_blank">patrick.w=
ilbur@gmail.com</a><br><a href=3D"mailto:wilburpf@clarkson.edu" target=3D"_=
blank">wilburpf@clarkson.edu</a><br><br>Check out our book: <a href=3D"http=
://runningxen.com" target=3D"_blank">http://runningxen.com</a><br>

<div>My website: <a href=3D"http://pdub.net" target=3D"_blank">http://pdub.=
net</a></div><div><br></div></div><div><br></div></div><br>
</div>

--00032555a60a71d49004b80002e8--


--===============3805093157115238287==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3805093157115238287==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJfi-0003WP-Eh; Fri, 03 Feb 2012 13:59:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <patrick.wilbur@gmail.com>) id 1Rt27S-0000nc-9K
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 19:14:54 +0000
X-Env-Sender: patrick.wilbur@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328210087!13330327!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29162 invoked from network); 2 Feb 2012 19:14:47 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 19:14:47 -0000
Received: by bkbzv3 with SMTP id zv3so4907317bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 11:14:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:cc:content-type;
	bh=147gOvw88SvgMchtudRHVtW4bTH/Sy90ZnMVVF+ZrEc=;
	b=ckjG3gQXdgr0OkHqMyDCdu/PmVkM2OOirkoMH66yPUjz0AsiuwEa+UB9N+T+Uj6niA
	xt7h1D1EAD+P/eaayyDveltz+QpKzfPsXbvGwsa4ctH6OpAqfjECxyv2TXFsnMbgDwlp
	AfwEriZYsCO8gePKZZAHbs+gS6x7lOaaOgUFk=
Received: by 10.204.16.136 with SMTP id o8mr1982245bka.119.1328210087367; Thu,
	02 Feb 2012 11:14:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.116.146 with HTTP; Thu, 2 Feb 2012 11:14:27 -0800 (PST)
From: Patrick Wilbur <patrick.wilbur@gmail.com>
Date: Thu, 2 Feb 2012 14:14:27 -0500
Message-ID: <CABFkyn9EYfq7T0cmDDGyUQkpCce7_unLkzOrgDFDDhJHQhtTzw@mail.gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Cc: andres@lagarcavilla.org
Subject: [Xen-devel] Cloning a VM and copy-on-write deduplicating memory
 using CoW page sharing in Xen 4+
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3805093157115238287=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3805093157115238287==
Content-Type: multipart/alternative; boundary=00032555a60a71d49004b80002e8

--00032555a60a71d49004b80002e8
Content-Type: text/plain; charset=ISO-8859-1

Hey all,
Hey Andres,

I'm looking to clone a VM into several extremely-similar VMs, and I'm
hoping to also make use of your lovely new CoW page sharing capabilities in
Xen 4.

>From my understanding of a previous thread where Andres described the
process of sharing/coalescing memory between VMs, it sounds like I will
need to "manually" coalesce each page using a homebrew tool of mine.  The
issue I have with doing this is it seems like I'd need to pause, save mem,
load mem in a new VM, coalesce, and resume two VMs, which seems painful and
wasteful of a process for cloning!

Is there an easier way to do this, or should we add a new feature for CoW
cloning of VMs in Xen via a userspace tool?

Thanks,
Pat Wilbur & team


--
Patrick F. Wilbur
Researcher, Consultant, Educator,
Computer Science Graduate at Clarkson University

DONE RIGHT THE FIRST TIME: Consulting and hiring information:
http://pdub.net/consulting/ & http://pdub.net/hiring/

patrick.wilbur@gmail.com
wilburpf@clarkson.edu

Check out our book: http://runningxen.com
My website: http://pdub.net

--00032555a60a71d49004b80002e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey all,<div>Hey Andres,</div><div><br></div><div>I&#39;m looking to clone =
a VM into several extremely-similar VMs, and I&#39;m hoping to also make us=
e of your lovely new CoW page sharing capabilities in Xen 4. =A0</div><div>

<br></div><div>From my understanding of a previous thread where Andres desc=
ribed the process of sharing/coalescing memory between VMs, it sounds like =
I will need to &quot;manually&quot; coalesce each page using a homebrew too=
l of mine. =A0The issue I have with doing this is it seems like I&#39;d nee=
d to pause, save mem, load mem in a new VM, coalesce, and resume two VMs, w=
hich seems painful and wasteful of a process for cloning!</div>

<div><br></div><div>Is there an easier way to do this, or should we add a n=
ew feature for CoW cloning of VMs in Xen via a userspace tool?</div><div><b=
r></div><div>Thanks,</div><div>Pat Wilbur &amp; team<br clear=3D"all"><br>

<br>--<br>Patrick F. Wilbur<div>Researcher, Consultant, Educator,<br>Comput=
er Science Graduate at=A0Clarkson University<div><br></div><div>DONE RIGHT =
THE FIRST TIME: Consulting and hiring information: <a href=3D"http://pdub.n=
et/consulting/" target=3D"_blank">http://pdub.net/consulting/</a>=A0&amp;=
=A0<a href=3D"http://pdub.net/hiring/" target=3D"_blank">http://pdub.net/hi=
ring/</a><br>

<br><a href=3D"mailto:patrick.wilbur@gmail.com" target=3D"_blank">patrick.w=
ilbur@gmail.com</a><br><a href=3D"mailto:wilburpf@clarkson.edu" target=3D"_=
blank">wilburpf@clarkson.edu</a><br><br>Check out our book: <a href=3D"http=
://runningxen.com" target=3D"_blank">http://runningxen.com</a><br>

<div>My website: <a href=3D"http://pdub.net" target=3D"_blank">http://pdub.=
net</a></div><div><br></div></div><div><br></div></div><br>
</div>

--00032555a60a71d49004b80002e8--


--===============3805093157115238287==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3805093157115238287==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJfi-0003WF-1y; Fri, 03 Feb 2012 13:59:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1Rt1ZT-0008OZ-8A
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 18:39:47 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328207980!13076987!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7832 invoked from network); 2 Feb 2012 18:39:41 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 18:39:41 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1A18221806
	for <xen-devel@lists.xensource.com>;
	Thu,  2 Feb 2012 13:39:40 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Thu, 02 Feb 2012 13:39:40 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=0lYWcW5Rmb7q7kpf7mw7Zo8GZhI=; b=OHulENz62mcKT11TpEBjD80FrBbf
	gUxNw+Eh1eOvOAK3Y+ZkxsnG4TmulmbUpbvWxm/6CJ1ctihGlSvcEJN5Sqe3qRv+
	mqSus0/X/lzhgF7UyER3PXDHRSm+HmnNZmJoeKG0QVVoZFKF8cN8Swq5Kb7lYjk8
	YEbu7qPygZjQK1E=
X-Sasl-enc: 3WicSn3qgjWnZ9PxcpmWGu2dgQMvnIPXZh4yp12yZR8E 1328207979
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 783768E017E;
	Thu,  2 Feb 2012 13:39:39 -0500 (EST)
Date: Thu, 2 Feb 2012 10:38:51 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120202183851.GA28193@kroah.com>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120201222250.GA3854@kroah.com>
	<20120202174330.GA9311@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120202174330.GA9311@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 12:43:30PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 01, 2012 at 02:22:50PM -0800, Greg KH wrote:
> > Does the patch below solve the problem for you?
> 
> Hey Greg,
> 
> Indeed it does.
> 
> For the patch below, please put 'Tested-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>'

Wonderful, thanks for testing, I'll queue this up soon.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJfi-0003WF-1y; Fri, 03 Feb 2012 13:59:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1Rt1ZT-0008OZ-8A
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 18:39:47 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328207980!13076987!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7832 invoked from network); 2 Feb 2012 18:39:41 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Feb 2012 18:39:41 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1A18221806
	for <xen-devel@lists.xensource.com>;
	Thu,  2 Feb 2012 13:39:40 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Thu, 02 Feb 2012 13:39:40 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:cc:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	bh=0lYWcW5Rmb7q7kpf7mw7Zo8GZhI=; b=OHulENz62mcKT11TpEBjD80FrBbf
	gUxNw+Eh1eOvOAK3Y+ZkxsnG4TmulmbUpbvWxm/6CJ1ctihGlSvcEJN5Sqe3qRv+
	mqSus0/X/lzhgF7UyER3PXDHRSm+HmnNZmJoeKG0QVVoZFKF8cN8Swq5Kb7lYjk8
	YEbu7qPygZjQK1E=
X-Sasl-enc: 3WicSn3qgjWnZ9PxcpmWGu2dgQMvnIPXZh4yp12yZR8E 1328207979
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 783768E017E;
	Thu,  2 Feb 2012 13:39:39 -0500 (EST)
Date: Thu, 2 Feb 2012 10:38:51 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120202183851.GA28193@kroah.com>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120201222250.GA3854@kroah.com>
	<20120202174330.GA9311@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120202174330.GA9311@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Cc: x86@kernel.org, kay.sievers@vrfy.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 12:43:30PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 01, 2012 at 02:22:50PM -0800, Greg KH wrote:
> > Does the patch below solve the problem for you?
> 
> Hey Greg,
> 
> Indeed it does.
> 
> For the patch below, please put 'Tested-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>'

Wonderful, thanks for testing, I'll queue this up soon.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJfh-0003W3-L2; Fri, 03 Feb 2012 13:59:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xenxen@163.com>) id 1RsxGs-0001Vp-Ss
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:04:19 +0000
X-Env-Sender: xenxen@163.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328191433!64260469!1
X-Originating-IP: [220.181.13.22]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjIyID0+IDQ3NzE=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjIyID0+IDQ3NzE=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31477 invoked from network); 2 Feb 2012 14:03:55 -0000
Received: from m13-22.163.com (HELO m13-22.163.com) (220.181.13.22)
	by server-15.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 14:03:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=NqzxAnj3p9+Z9B+P3vMa00NqRN2N6aYyrz
	l+W+Sb7xU=; b=lVVzWQtwCBm+Bdx+beJGo3wHMx8Y+tJAr22WIGEEkUpuNNPcup
	2KUefXOEGdSK8gfqehcfrybbd1/yw//XsECGnyIFv9l+PwnO07ZGp6cyjUYKlhyg
	hM+heUGd3/7sQ6sRkcKO9JzSKkWH5dQ+Ef8XBAv3K5IDzKRNIUl9k/ceE=
Received: from xenxen ( [121.32.195.95] ) by ajax-webmail-wmsvr22 (Coremail)
	; Thu, 2 Feb 2012 22:04:08 +0800 (CST)
Date: Thu, 2 Feb 2012 22:04:08 +0800 (CST)
From: xenxen <xenxen@163.com>
To: xen-devel@lists.xensource.com
Message-ID: <1e54aa3d.1d7ff.1353e612660.Coremail.xenxen@163.com>
MIME-Version: 1.0
X-Originating-IP: [121.32.195.95]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: IO5bnWZvb3Rlcl9odG09NTc1Ojgx
X-CM-TRANSID: FsGowGBZ_0DZlypPXwkMAA--.51810W
X-CM-SenderInfo: x0hq5vrq6rljoofrz/1tbiygRItE3UoOH60AACsC
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Subject: [Xen-devel] questions about minios idd
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0448417333753654158=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0448417333753654158==
Content-Type: multipart/alternative; 
	boundary="----=_Part_343305_1364796670.1328191448672"

------=_Part_343305_1364796670.1328191448672
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Dear Xen.org
 
I want to ask questions about IDD(isolated driver domain).
 
1. Can the minios inlcuded in the Xen sourcecode be used to be IDD domain?
 
2. If it does, I can't find the corresponding backend driver and the orignal device driver in the minios of the Xen, please tell me where I can find the backend driver and the orignal device driver.
 
Thank you very much.
------=_Part_343305_1364796670.1328191448672
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Dear Xen.org</DIV>
<DIV>&nbsp;</DIV>
<DIV>I want to ask questions about IDD(isolated driver domain).</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. Can the minios inlcuded in the Xen sourcecode be used to be IDD domain?</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. If it does, I can't find the corresponding backend driver and the orignal device driver in the minios of the Xen, please tell me where I can find the backend driver and the orignal device driver.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you very much.</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_343305_1364796670.1328191448672--



--===============0448417333753654158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0448417333753654158==--



From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13:59:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJfh-0003W3-L2; Fri, 03 Feb 2012 13:59:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xenxen@163.com>) id 1RsxGs-0001Vp-Ss
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 14:04:19 +0000
X-Env-Sender: xenxen@163.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328191433!64260469!1
X-Originating-IP: [220.181.13.22]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjIyID0+IDQ3NzE=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjIyID0+IDQ3NzE=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31477 invoked from network); 2 Feb 2012 14:03:55 -0000
Received: from m13-22.163.com (HELO m13-22.163.com) (220.181.13.22)
	by server-15.tower-27.messagelabs.com with SMTP;
	2 Feb 2012 14:03:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=NqzxAnj3p9+Z9B+P3vMa00NqRN2N6aYyrz
	l+W+Sb7xU=; b=lVVzWQtwCBm+Bdx+beJGo3wHMx8Y+tJAr22WIGEEkUpuNNPcup
	2KUefXOEGdSK8gfqehcfrybbd1/yw//XsECGnyIFv9l+PwnO07ZGp6cyjUYKlhyg
	hM+heUGd3/7sQ6sRkcKO9JzSKkWH5dQ+Ef8XBAv3K5IDzKRNIUl9k/ceE=
Received: from xenxen ( [121.32.195.95] ) by ajax-webmail-wmsvr22 (Coremail)
	; Thu, 2 Feb 2012 22:04:08 +0800 (CST)
Date: Thu, 2 Feb 2012 22:04:08 +0800 (CST)
From: xenxen <xenxen@163.com>
To: xen-devel@lists.xensource.com
Message-ID: <1e54aa3d.1d7ff.1353e612660.Coremail.xenxen@163.com>
MIME-Version: 1.0
X-Originating-IP: [121.32.195.95]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: IO5bnWZvb3Rlcl9odG09NTc1Ojgx
X-CM-TRANSID: FsGowGBZ_0DZlypPXwkMAA--.51810W
X-CM-SenderInfo: x0hq5vrq6rljoofrz/1tbiygRItE3UoOH60AACsC
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Subject: [Xen-devel] questions about minios idd
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0448417333753654158=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0448417333753654158==
Content-Type: multipart/alternative; 
	boundary="----=_Part_343305_1364796670.1328191448672"

------=_Part_343305_1364796670.1328191448672
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Dear Xen.org
 
I want to ask questions about IDD(isolated driver domain).
 
1. Can the minios inlcuded in the Xen sourcecode be used to be IDD domain?
 
2. If it does, I can't find the corresponding backend driver and the orignal device driver in the minios of the Xen, please tell me where I can find the backend driver and the orignal device driver.
 
Thank you very much.
------=_Part_343305_1364796670.1328191448672
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Dear Xen.org</DIV>
<DIV>&nbsp;</DIV>
<DIV>I want to ask questions about IDD(isolated driver domain).</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. Can the minios inlcuded in the Xen sourcecode be used to be IDD domain?</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. If it does, I can't find the corresponding backend driver and the orignal device driver in the minios of the Xen, please tell me where I can find the backend driver and the orignal device driver.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you very much.</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_343305_1364796670.1328191448672--



--===============0448417333753654158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0448417333753654158==--



From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJfi-0003Wd-S6; Fri, 03 Feb 2012 13:59:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paul.gortmaker@gmail.com>) id 1Rt5Vf-0007sJ-Mf
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 22:52:07 +0000
X-Env-Sender: paul.gortmaker@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328223075!52850826!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18175 invoked from network); 2 Feb 2012 22:51:16 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 22:51:16 -0000
Received: by yenq6 with SMTP id q6so29568570yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 14:52:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=7vkS/c988al+U5B12mt7aMr3fmxwBOtj5oRWcB/M45M=;
	b=f4FSrjrJyiDNvn+Z5YNB+mobH3yRowlekY3+3H25s2NgWn4AdUgdYqM3omrEeKEmIg
	hYk37aDEVGkPeY7VP2SKG8VA+6xjUEfKmEKzNoi7rqT0bzudZyR9atTD88mzWOXkvml5
	//t1WeYaR3WAigvfVVwaMNnv9DQktWFNDoUTU=
MIME-Version: 1.0
Received: by 10.236.154.137 with SMTP id h9mr7653363yhk.91.1328223125057; Thu,
	02 Feb 2012 14:52:05 -0800 (PST)
Received: by 10.147.83.5 with HTTP; Thu, 2 Feb 2012 14:52:04 -0800 (PST)
In-Reply-To: <1328215821.13189.24.camel@dagon.hellion.org.uk>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
Date: Thu, 2 Feb 2012 17:52:04 -0500
X-Google-Sender-Auth: IIK8T2C4ehoeJCXpWPeqBVqOuG8
Message-ID: <CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 2, 2012 at 3:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:

[...]

>
> I don't think it is at all unreasonable to ask for bug fixes but in this
> case Wei's series is removing the code in question (which would also
> undoubtedly fix the bug).
>
> As it happens the fix turns out to be simple but if it were complex I
> would perhaps have disagreed more strongly about spending effort fixing
> code that is removed 2 patches later, although obviously that would have
> depended on the specifics of the fix in that case.

Lots of people are relying on git bisect.  If you introduce build failures
or known bugs into any point in history, you take away from the value
in git bisect.  Sure, it happens by accident, but it shouldn't ever be
done knowingly.

Paul.

>
>> Next time, dont bother send patches for review if you dont want
>> reviewers.
>
> The review which you are doing is certainly very much appreciated, I'm
> sorry if my disagreement over this one point gave/gives the impression
> that it is not.
>
> Ian.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 13:59:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 13: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.xensource.com>)
	id 1RtJfi-0003Wd-S6; Fri, 03 Feb 2012 13:59:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paul.gortmaker@gmail.com>) id 1Rt5Vf-0007sJ-Mf
	for xen-devel@lists.xensource.com; Thu, 02 Feb 2012 22:52:07 +0000
X-Env-Sender: paul.gortmaker@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328223075!52850826!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18175 invoked from network); 2 Feb 2012 22:51:16 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2012 22:51:16 -0000
Received: by yenq6 with SMTP id q6so29568570yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 02 Feb 2012 14:52:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=7vkS/c988al+U5B12mt7aMr3fmxwBOtj5oRWcB/M45M=;
	b=f4FSrjrJyiDNvn+Z5YNB+mobH3yRowlekY3+3H25s2NgWn4AdUgdYqM3omrEeKEmIg
	hYk37aDEVGkPeY7VP2SKG8VA+6xjUEfKmEKzNoi7rqT0bzudZyR9atTD88mzWOXkvml5
	//t1WeYaR3WAigvfVVwaMNnv9DQktWFNDoUTU=
MIME-Version: 1.0
Received: by 10.236.154.137 with SMTP id h9mr7653363yhk.91.1328223125057; Thu,
	02 Feb 2012 14:52:05 -0800 (PST)
Received: by 10.147.83.5 with HTTP; Thu, 2 Feb 2012 14:52:04 -0800 (PST)
In-Reply-To: <1328215821.13189.24.camel@dagon.hellion.org.uk>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-3-git-send-email-wei.liu2@citrix.com>
	<1328202524.11534.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328203710.5553.94.camel@leeds.uk.xensource.com>
	<1328204936.13262.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<1328212761.28964.77.camel@dagon.hellion.org.uk>
	<1328214866.2480.18.camel@edumazet-laptop>
	<1328215821.13189.24.camel@dagon.hellion.org.uk>
Date: Thu, 2 Feb 2012 17:52:04 -0500
X-Google-Sender-Auth: IIK8T2C4ehoeJCXpWPeqBVqOuG8
Message-ID: <CAP=VYLq3CZBjC2ecOdGqAejN5Atu9kd1HovhQwc-eVk-q8ArJA@mail.gmail.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Fri, 03 Feb 2012 13:59:24 +0000
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 02/13] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 2, 2012 at 3:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> On Thu, 2012-02-02 at 20:34 +0000, Eric Dumazet wrote:

[...]

>
> I don't think it is at all unreasonable to ask for bug fixes but in this
> case Wei's series is removing the code in question (which would also
> undoubtedly fix the bug).
>
> As it happens the fix turns out to be simple but if it were complex I
> would perhaps have disagreed more strongly about spending effort fixing
> code that is removed 2 patches later, although obviously that would have
> depended on the specifics of the fix in that case.

Lots of people are relying on git bisect.  If you introduce build failures
or known bugs into any point in history, you take away from the value
in git bisect.  Sure, it happens by accident, but it shouldn't ever be
done knowingly.

Paul.

>
>> Next time, dont bother send patches for review if you dont want
>> reviewers.
>
> The review which you are doing is certainly very much appreciated, I'm
> sorry if my disagreement over this one point gave/gives the impression
> that it is not.
>
> Ian.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:03:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14: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.xensource.com>)
	id 1RtJjd-0004vf-H4; Fri, 03 Feb 2012 14:03:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RtJjb-0004uf-TS
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:03:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328277799!12805647!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1272 invoked from network); 3 Feb 2012 14:03:21 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:03:21 -0000
Received: by damc16 with SMTP id c16so18133417dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 06:03:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=24ErT7bdQnVxjeajXlfAzJbmkKpLKFLub+n/M1i/fUg=;
	b=lfGW9VND4D9d+Z8VzfSn5zjTecFtDYxu3GC62ZFqmROP0BUuuCowAXckT5P0GD2RvQ
	BHklH3gXihH9lN6D1jNR+BaQvZJQ6XK2AnFBWmA9AvZ6+/CjRJ9EVR3HTyYr1I6eBXd6
	bYo7Q/AG3ndlM8BA6c4sHa3ICz/mLA2jCv+CI=
MIME-Version: 1.0
Received: by 10.68.219.232 with SMTP id pr8mr17986647pbc.12.1328277799558;
	Fri, 03 Feb 2012 06:03:19 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Fri, 3 Feb 2012 06:03:19 -0800 (PST)
In-Reply-To: <1328258364.13189.47.camel@dagon.hellion.org.uk>
References: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
	<1328258364.13189.47.camel@dagon.hellion.org.uk>
Date: Fri, 3 Feb 2012 15:03:19 +0100
X-Google-Sender-Auth: HQqzZAH85XTwAmwJFtFlAFfkpjU
Message-ID: <CAPLaKK4AE1MeTeh1PDn-_6ZWijDwCYMiPYyDTZ_q83Nv4=KenQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gRnJp
LCAyMDEyLTAyLTAzIGF0IDAwOjI0ICswMDAwLCBEYW4gTWFnZW5oZWltZXIgd3JvdGU6Cj4+IEkn
bSBidWlsZGluZyB4ZW4tZGV2ZWwgZnJvbSBzY3JhdGNoIGZvciB0aGUgZmlyc3QgdGltZSBpbiBh
IGxvbmcKPj4gdGltZSBvbiBhIGNsZWFuIEVMNnUxIG1hY2hpbmUgYW5kIHJ1bm5pbmcgaW50byBh
IGNvdXBsZSBvZiBwcm9ibGVtcy4KPj4KPj4gMSkgVGhlIGJ1aWxkIG9mIHRvb2xzL2Zpcm13YXJl
L2V0aGVyYm9vdCBkb2VzIGEgd2dldCBvZiBhIHdlaXJkCj4+IMKgIMKgcHhlIHRhciBmaWxlIHRo
YXQgbG9va3MgbGlrZSBpdCBoYXMgYSBnaXQgaGFzaCBpbiB0aGUgZmlsZW5hbWUuCj4+IMKgIMKg
SSBoYWNrZWQgYXJvdW5kIHRoYXQgKHRvIHdnZXQgdGhlIDEuMC4wIHZlcnNpb24gb2YgdGhlIGZp
bGUpLgo+Cj4gVGhpcyBvbmUgaXMga25vd24uIGl4cGUgaGFzbid0IGRvbmUgYSByZWxlYXNlIGZv
ciBhZ2VzIGJ1dCB3ZSBuZWVkZWQgYQo+IG5ld2VyIHZlcnNpb24gZm9yIHNvbWUgYnVnIGZpeGVz
LCBoZW5jZSB3ZSBkZXBlbmQgb24gYSBnaXQgcmV2aXNpb24gbm93Lgo+Cj4gSXQgaXMgZXhwZWN0
ZWQgdGhhdCB0aGUgd2dldCBmYWlscyBhbmQgdGhlbiBpdCBmYWxscyBiYWNrIHRvIGdlbmVyYXRp
bmcKPiB0aGUgdGFyYmFsbCBsb2NhbGx5IGZyb20gYSBnaXQgY2hlY2tvdXQuIEkgdGhpbmsgdGhp
cyBpcyBwcmV0dHkgbGFtZSBidXQKPiBpdCBpcyBhcHBhcmVudGx5IGEgY29uc2VxdWVuY2Ugb2Yg
aG93IHRoZSBNYWtlZmlsZSBpcyBzdHJ1Y3R1cmVkLiBXZQo+IHByZXZpb3VzbHkgZGlzY3Vzc2Vk
IHB1dHRpbmcgYSBjb3B5IG9mIHRoYXQgdGFyYmFsbCBvbiB4ZW5iaXRzIC0tIG5vdAo+IHN1cmUg
d2hhdCBoYXBwZW5lZCB0byB0aGF0IHBsYW4gYnV0IEkgaGF2ZSBkb25lIGl0IG5vdyBhbmQgdGhl
IHdnZXQKPiB3b3JrcyBmb3IgbWUgKFRNKS4KPgo+PiAyKSBCdWlsZGluZyBibGt0YXAyIGNvbXBs
YWlucyBhYm91dCBhIG1pc3NpbmcgInV1aWQvdXVpZC5oIi4gwqBJCj4+IMKgIMKgZGlkIGluc3Rh
bGwgdGhlIHV1aWQgYW5kIHV1aWQtZGV2ZWwgcGFja2FnZXMgYW5kIHRoZXJlIElTCj4+IMKgIMKg
YSAvdXNyL2luY2x1ZGUvdXVpZC5oIGJ1dCBubyAvdXNyL2luY2x1ZGUvdXVpZC91dWlkLmguIMKg
SSBmb3VuZAo+PiDCoCDCoEkgYWxzbyBuZWVkZWQgdG8gaW5zdGFsbCBsaWJ1dWlkLWRldmVsICh3
aGljaCBkaWRuJ3QgZ2V0Cj4+IMKgIMKgY2hlY2tlZCBpbiBhZHZhbmNlIGFwcGFyZW50bHksIGp1
c3QgdXVpZC1kZXZlbCBhbmQgdXVpZCBJIHRoaW5rKS4KPgo+IHRvb2xzL2NoZWNrL2NoZWNrX3V1
aWRfZGV2ZWwgbG9va3MgZm9yIGJvdGggInV1aWQuaCIgYW5kICJ1dWlkL3V1aWQuaCIsCj4gaW4g
dGhhdCBvcmRlciBidXQgYXQgbGVhc3Qgc29tZSBoZWFkZXJzIChlLmcuIGxpYnhsX3V1aWQuaCwg
YmxrdGFwJ3MKPiBvbmVzIGV0YykgdXNlOgo+IMKgIMKgIMKgIMKgI2lmIF9fbGludXhfXwo+IMKg
IMKgIMKgIMKgI2luY2x1ZGUgPHV1aWQvdXVpZC5oPgo+IMKgIMKgIMKgIMKgI2VsaWYgX19CU0Rf
Xwo+IMKgIMKgIMKgIMKgI2luY2x1ZGUgPHV1aWQuaD4KPgo+IEl0IHNlZW1zIHRoYXQgb24gRUwg
eW91IGNhbiBlbmQgdXAgd2l0aCB1dWlkLmggYnV0IG5vdCB1dWlkL3V1aWQuaCB3aGljaAo+IGNv
bmZ1c2VzIHRoZSBjaGVjayBpbnRvIHN1Y2NlZWRpbmcgd2hlcmUgaXQgc2hvdWxkbid0Lgo+Cj4g
UGxlYXNlIGNhbiB5b3UgY29uZmlybSB0aGF0IG9uIEVMNiB1dWlkLWRldmVsCj4gaW5jbHVkZXMg
L3Vzci9pbmNsdWRlL3V1aWQuaCBhbmQgbGlidXVpZC1kZXZlbAo+IGluY2x1ZGVzIC91c3IvaW5j
bHVkZS91dWlkL3V1aWQuaAo+Cj4gUm9nZXIsIGNhbiB5b3UgaGFuZGxlIHRoaXMgKExpbnV4IHZz
LiBCU0Q/KSBoZWFkZXIgZGlzdGluY3Rpb24gaW4geW91cgo+IGF1dG9jb25mIHBhdGNoPwoKSSd2
ZSBzZW5kIGFuIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IGNvbnRhaW5zIHRoaXMgY2hlY2suIFRoZSBw
YXRjaCBsb29rcwpvayBpbiBteSByZXBvc2l0b3J5LCBhbmQgdGhpcyB0aW1lIEkndmUgc2VudCBp
dCBhcyBhbiBhdHRhY2htZW50LApsZXQncyBzZWUgaWYgdGhhdCBzb2x2ZXMgdGhlIHdoaXRlc3Bh
Y2UgcHJvYmxlbS4KCj4+IDMpIE1pc3NpbmcgdGV4aW5mbyBwYWNrYWdlIHN0b3BzIHRoZSBidWls
ZCBiZWZvcmUgaXQgc3VjY2Vzc2Z1bGx5Cj4+IMKgIMKgY29tcGxldGVzLiDCoENhbiB0aGlzIGJl
IGNoZWNrJ2VkIGluIGFkdmFuY2U/Cj4KPiBQbGVhc2UgY2FuIHlvdSBwb3N0IHRoaXMgbG9nIHNv
IHdlIGNhbiBmaW5kIHdoZXJlIHRoZSB0ZXhpbmZvCj4gcmVxdWlyZW1lbnQgY29tZXMgZnJvbT8K
Pgo+IE5vcm1hbGx5IGZvciB0aGVzZSB0aGluZ3Mgd2Ugd291bGQgcGF0Y2ggdGhlbSB0byBvbmx5
IGJ1aWxkIHRoZSBkb2NzIGlmCj4gdGhlIHJlcXVpcmVkIHRvb2wgaXMgcHJlc2VudC4KPgo+PiBT
aW5jZSBJIGhhdmVuJ3QgYnVpbHQgeGVuLWRldmVsIGluIGEgbG9uZyB0aW1lLCBJIGRvbid0IGtu
b3cgaWYKPj4gdGhlc2UgYXJlIHJlY2VudCBwcm9ibGVtcyB3aXRoIHRpcCBvciBvbGQgcHJvYmxl
bXMgdGhhdCBkb24ndAo+PiBzaG93IHVwIG9uIFtEZWJpYW4gYW5kIHdoYXRldmVyIG90aGVyIGVu
dnMgb3RoZXIgZGV2ZWxvcGVycyBhcmUKPj4gdXNpbmddIGJ1dCBkbyBzaG93IHVwIG9uIEVMNi4g
wqBTbyBJIHRob3VnaHQgSSdkIHJlcG9ydCB0aGVtLgo+Cj4gSSB0aGluayBpdCdzIGEgbWl4dHVy
ZSBvZiBvbGQgYW5kIG5ldy4gVGhhbmtzIGZvciByZXBvcnRpbmcuCj4KPiBJYW4uCj4KPgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:03:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14: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.xensource.com>)
	id 1RtJjd-0004vf-H4; Fri, 03 Feb 2012 14:03:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RtJjb-0004uf-TS
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:03:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328277799!12805647!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1272 invoked from network); 3 Feb 2012 14:03:21 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:03:21 -0000
Received: by damc16 with SMTP id c16so18133417dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 06:03:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=24ErT7bdQnVxjeajXlfAzJbmkKpLKFLub+n/M1i/fUg=;
	b=lfGW9VND4D9d+Z8VzfSn5zjTecFtDYxu3GC62ZFqmROP0BUuuCowAXckT5P0GD2RvQ
	BHklH3gXihH9lN6D1jNR+BaQvZJQ6XK2AnFBWmA9AvZ6+/CjRJ9EVR3HTyYr1I6eBXd6
	bYo7Q/AG3ndlM8BA6c4sHa3ICz/mLA2jCv+CI=
MIME-Version: 1.0
Received: by 10.68.219.232 with SMTP id pr8mr17986647pbc.12.1328277799558;
	Fri, 03 Feb 2012 06:03:19 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Fri, 3 Feb 2012 06:03:19 -0800 (PST)
In-Reply-To: <1328258364.13189.47.camel@dagon.hellion.org.uk>
References: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
	<1328258364.13189.47.camel@dagon.hellion.org.uk>
Date: Fri, 3 Feb 2012 15:03:19 +0100
X-Google-Sender-Auth: HQqzZAH85XTwAmwJFtFlAFfkpjU
Message-ID: <CAPLaKK4AE1MeTeh1PDn-_6ZWijDwCYMiPYyDTZ_q83Nv4=KenQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gRnJp
LCAyMDEyLTAyLTAzIGF0IDAwOjI0ICswMDAwLCBEYW4gTWFnZW5oZWltZXIgd3JvdGU6Cj4+IEkn
bSBidWlsZGluZyB4ZW4tZGV2ZWwgZnJvbSBzY3JhdGNoIGZvciB0aGUgZmlyc3QgdGltZSBpbiBh
IGxvbmcKPj4gdGltZSBvbiBhIGNsZWFuIEVMNnUxIG1hY2hpbmUgYW5kIHJ1bm5pbmcgaW50byBh
IGNvdXBsZSBvZiBwcm9ibGVtcy4KPj4KPj4gMSkgVGhlIGJ1aWxkIG9mIHRvb2xzL2Zpcm13YXJl
L2V0aGVyYm9vdCBkb2VzIGEgd2dldCBvZiBhIHdlaXJkCj4+IMKgIMKgcHhlIHRhciBmaWxlIHRo
YXQgbG9va3MgbGlrZSBpdCBoYXMgYSBnaXQgaGFzaCBpbiB0aGUgZmlsZW5hbWUuCj4+IMKgIMKg
SSBoYWNrZWQgYXJvdW5kIHRoYXQgKHRvIHdnZXQgdGhlIDEuMC4wIHZlcnNpb24gb2YgdGhlIGZp
bGUpLgo+Cj4gVGhpcyBvbmUgaXMga25vd24uIGl4cGUgaGFzbid0IGRvbmUgYSByZWxlYXNlIGZv
ciBhZ2VzIGJ1dCB3ZSBuZWVkZWQgYQo+IG5ld2VyIHZlcnNpb24gZm9yIHNvbWUgYnVnIGZpeGVz
LCBoZW5jZSB3ZSBkZXBlbmQgb24gYSBnaXQgcmV2aXNpb24gbm93Lgo+Cj4gSXQgaXMgZXhwZWN0
ZWQgdGhhdCB0aGUgd2dldCBmYWlscyBhbmQgdGhlbiBpdCBmYWxscyBiYWNrIHRvIGdlbmVyYXRp
bmcKPiB0aGUgdGFyYmFsbCBsb2NhbGx5IGZyb20gYSBnaXQgY2hlY2tvdXQuIEkgdGhpbmsgdGhp
cyBpcyBwcmV0dHkgbGFtZSBidXQKPiBpdCBpcyBhcHBhcmVudGx5IGEgY29uc2VxdWVuY2Ugb2Yg
aG93IHRoZSBNYWtlZmlsZSBpcyBzdHJ1Y3R1cmVkLiBXZQo+IHByZXZpb3VzbHkgZGlzY3Vzc2Vk
IHB1dHRpbmcgYSBjb3B5IG9mIHRoYXQgdGFyYmFsbCBvbiB4ZW5iaXRzIC0tIG5vdAo+IHN1cmUg
d2hhdCBoYXBwZW5lZCB0byB0aGF0IHBsYW4gYnV0IEkgaGF2ZSBkb25lIGl0IG5vdyBhbmQgdGhl
IHdnZXQKPiB3b3JrcyBmb3IgbWUgKFRNKS4KPgo+PiAyKSBCdWlsZGluZyBibGt0YXAyIGNvbXBs
YWlucyBhYm91dCBhIG1pc3NpbmcgInV1aWQvdXVpZC5oIi4gwqBJCj4+IMKgIMKgZGlkIGluc3Rh
bGwgdGhlIHV1aWQgYW5kIHV1aWQtZGV2ZWwgcGFja2FnZXMgYW5kIHRoZXJlIElTCj4+IMKgIMKg
YSAvdXNyL2luY2x1ZGUvdXVpZC5oIGJ1dCBubyAvdXNyL2luY2x1ZGUvdXVpZC91dWlkLmguIMKg
SSBmb3VuZAo+PiDCoCDCoEkgYWxzbyBuZWVkZWQgdG8gaW5zdGFsbCBsaWJ1dWlkLWRldmVsICh3
aGljaCBkaWRuJ3QgZ2V0Cj4+IMKgIMKgY2hlY2tlZCBpbiBhZHZhbmNlIGFwcGFyZW50bHksIGp1
c3QgdXVpZC1kZXZlbCBhbmQgdXVpZCBJIHRoaW5rKS4KPgo+IHRvb2xzL2NoZWNrL2NoZWNrX3V1
aWRfZGV2ZWwgbG9va3MgZm9yIGJvdGggInV1aWQuaCIgYW5kICJ1dWlkL3V1aWQuaCIsCj4gaW4g
dGhhdCBvcmRlciBidXQgYXQgbGVhc3Qgc29tZSBoZWFkZXJzIChlLmcuIGxpYnhsX3V1aWQuaCwg
YmxrdGFwJ3MKPiBvbmVzIGV0YykgdXNlOgo+IMKgIMKgIMKgIMKgI2lmIF9fbGludXhfXwo+IMKg
IMKgIMKgIMKgI2luY2x1ZGUgPHV1aWQvdXVpZC5oPgo+IMKgIMKgIMKgIMKgI2VsaWYgX19CU0Rf
Xwo+IMKgIMKgIMKgIMKgI2luY2x1ZGUgPHV1aWQuaD4KPgo+IEl0IHNlZW1zIHRoYXQgb24gRUwg
eW91IGNhbiBlbmQgdXAgd2l0aCB1dWlkLmggYnV0IG5vdCB1dWlkL3V1aWQuaCB3aGljaAo+IGNv
bmZ1c2VzIHRoZSBjaGVjayBpbnRvIHN1Y2NlZWRpbmcgd2hlcmUgaXQgc2hvdWxkbid0Lgo+Cj4g
UGxlYXNlIGNhbiB5b3UgY29uZmlybSB0aGF0IG9uIEVMNiB1dWlkLWRldmVsCj4gaW5jbHVkZXMg
L3Vzci9pbmNsdWRlL3V1aWQuaCBhbmQgbGlidXVpZC1kZXZlbAo+IGluY2x1ZGVzIC91c3IvaW5j
bHVkZS91dWlkL3V1aWQuaAo+Cj4gUm9nZXIsIGNhbiB5b3UgaGFuZGxlIHRoaXMgKExpbnV4IHZz
LiBCU0Q/KSBoZWFkZXIgZGlzdGluY3Rpb24gaW4geW91cgo+IGF1dG9jb25mIHBhdGNoPwoKSSd2
ZSBzZW5kIGFuIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IGNvbnRhaW5zIHRoaXMgY2hlY2suIFRoZSBw
YXRjaCBsb29rcwpvayBpbiBteSByZXBvc2l0b3J5LCBhbmQgdGhpcyB0aW1lIEkndmUgc2VudCBp
dCBhcyBhbiBhdHRhY2htZW50LApsZXQncyBzZWUgaWYgdGhhdCBzb2x2ZXMgdGhlIHdoaXRlc3Bh
Y2UgcHJvYmxlbS4KCj4+IDMpIE1pc3NpbmcgdGV4aW5mbyBwYWNrYWdlIHN0b3BzIHRoZSBidWls
ZCBiZWZvcmUgaXQgc3VjY2Vzc2Z1bGx5Cj4+IMKgIMKgY29tcGxldGVzLiDCoENhbiB0aGlzIGJl
IGNoZWNrJ2VkIGluIGFkdmFuY2U/Cj4KPiBQbGVhc2UgY2FuIHlvdSBwb3N0IHRoaXMgbG9nIHNv
IHdlIGNhbiBmaW5kIHdoZXJlIHRoZSB0ZXhpbmZvCj4gcmVxdWlyZW1lbnQgY29tZXMgZnJvbT8K
Pgo+IE5vcm1hbGx5IGZvciB0aGVzZSB0aGluZ3Mgd2Ugd291bGQgcGF0Y2ggdGhlbSB0byBvbmx5
IGJ1aWxkIHRoZSBkb2NzIGlmCj4gdGhlIHJlcXVpcmVkIHRvb2wgaXMgcHJlc2VudC4KPgo+PiBT
aW5jZSBJIGhhdmVuJ3QgYnVpbHQgeGVuLWRldmVsIGluIGEgbG9uZyB0aW1lLCBJIGRvbid0IGtu
b3cgaWYKPj4gdGhlc2UgYXJlIHJlY2VudCBwcm9ibGVtcyB3aXRoIHRpcCBvciBvbGQgcHJvYmxl
bXMgdGhhdCBkb24ndAo+PiBzaG93IHVwIG9uIFtEZWJpYW4gYW5kIHdoYXRldmVyIG90aGVyIGVu
dnMgb3RoZXIgZGV2ZWxvcGVycyBhcmUKPj4gdXNpbmddIGJ1dCBkbyBzaG93IHVwIG9uIEVMNi4g
wqBTbyBJIHRob3VnaHQgSSdkIHJlcG9ydCB0aGVtLgo+Cj4gSSB0aGluayBpdCdzIGEgbWl4dHVy
ZSBvZiBvbGQgYW5kIG5ldy4gVGhhbmtzIGZvciByZXBvcnRpbmcuCj4KPiBJYW4uCj4KPgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:05:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14: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.xensource.com>)
	id 1RtJl0-00058o-64; Fri, 03 Feb 2012 14:04:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJky-00057k-RP
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:04:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328277886!9976695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9099 invoked from network); 3 Feb 2012 14:04:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 14:04:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 14:04:45 +0000
Message-Id: <4F2BF78C0200007800070F50@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 14:04:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
	<4F2BA4230200007800070AE0@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 13:34, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 03.02.12 at 08:18, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> How about use static bank size, say 256, which architecture
>>> (IA32_MCG_CAP MSR) defined max bank number?
>> 
>> The maximum, if any, is 32 (beyond which collision with other defined
>> MSRs would arise). But with the possibility of having a discontiguous
>> or relocated MSR space, I don't think any static maximum would be a
>> good idea.
>> 
>> Jan
> 
> The advantages of static max bank is simple, any disadvantages of static 
> solution?

Lack of forward compatibility. I may even be that the use of uint8_t
wasn't really a good choice of mine.

> or, can we use bank_entry listed in vmce->impact_header for mci_ctl, like what 
> mci_status/mci_addr/mci_misc do?

I don't think so - the control register (obviously) must be accessible
independent of any ongoing (latched) MCE.

> I just think the patch may be too complicated for a minor issue.

Is a guest crash minor? After all there is no guarantee that the
accesses to these MSRs are exception handler protected in a
way similar to what current Linux does.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:05:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14: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.xensource.com>)
	id 1RtJl0-00058o-64; Fri, 03 Feb 2012 14:04:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJky-00057k-RP
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:04:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328277886!9976695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9099 invoked from network); 3 Feb 2012 14:04:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 14:04:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 14:04:45 +0000
Message-Id: <4F2BF78C0200007800070F50@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 14:04:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
	<4F2BA4230200007800070AE0@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 13:34, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 03.02.12 at 08:18, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> How about use static bank size, say 256, which architecture
>>> (IA32_MCG_CAP MSR) defined max bank number?
>> 
>> The maximum, if any, is 32 (beyond which collision with other defined
>> MSRs would arise). But with the possibility of having a discontiguous
>> or relocated MSR space, I don't think any static maximum would be a
>> good idea.
>> 
>> Jan
> 
> The advantages of static max bank is simple, any disadvantages of static 
> solution?

Lack of forward compatibility. I may even be that the use of uint8_t
wasn't really a good choice of mine.

> or, can we use bank_entry listed in vmce->impact_header for mci_ctl, like what 
> mci_status/mci_addr/mci_misc do?

I don't think so - the control register (obviously) must be accessible
independent of any ongoing (latched) MCE.

> I just think the patch may be too complicated for a minor issue.

Is a guest crash minor? After all there is no guarantee that the
accesses to these MSRs are exception handler protected in a
way similar to what current Linux does.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:05:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJlQ-0005DG-KH; Fri, 03 Feb 2012 14:05:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RtJlO-0005C8-DH
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:05:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328277910!11819912!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23264 invoked from network); 3 Feb 2012 14:05:12 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 14:05:12 -0000
Received: from mail151-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:05:08 +0000
Received: from mail151-ch1 (localhost [127.0.0.1])	by
	mail151-ch1-R.bigfish.com (Postfix) with ESMTP id 37FDF140567;
	Fri,  3 Feb 2012 14:05:10 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1
	(MessageSwitch) id 1328277907600371_9205;
	Fri,  3 Feb 2012 14:05:07 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.233])	by mail151-ch1.bigfish.com (Postfix) with ESMTP id
	8ED5520004B;	Fri,  3 Feb 2012 14:05:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:05:01 +0000
X-WSS-ID: 0LYTLSD-01-BEB-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 25381102800B;	Fri,  3 Feb 2012 08:05:01 -0600 (CST)
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;
	Fri, 3 Feb 2012 08:05:20 -0600
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.289.1;
	Fri, 3 Feb 2012 08:05:01 -0600
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, 3 Feb 2012
	09:04:59 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9EDFD49C0F1; Fri,  3 Feb 2012
	14:04:58 +0000 (GMT)
Message-ID: <4F2BEA93.6090401@amd.com>
Date: Fri, 3 Feb 2012 15:09:23 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F213167.3010400@amd.com>
	<4F296F180200007800070594@nat28.tlf.novell.com>
In-Reply-To: <4F296F180200007800070594@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
	non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/01/2012 04:58 PM, Jan Beulich wrote:
>>>> On 26.01.12 at 11:56, Wei Wang<wei.wang2@amd.com>  wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 24 16:46:17 2012 +0000
>> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Jan 26 11:50:02 2012 +0100
>> @@ -805,6 +805,9 @@ int guest_iommu_set_base(struct domain *
>>      p2m_type_t t;
>>      struct guest_iommu *iommu = domain_iommu(d);
>>
>> +    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>> +        return 0;
>
> Is it really appropriate/correct to return 0 here, while ...


good point, will be fixed in the next try. No one use 
guest_iommu_set_base so far until remaining patches got committed.

>> +
>>      if ( !iommu )
>>          return -EACCES;

>
> ... here it is -EACCES? Further, are the extra checks needed at all
> (i.e. wouldn't domain_iommu() return NULL in all of these cases
> anyway due to the same checks being added to guest_iommu_init())?
> If so, the checks you add to guest_iommu_destroy() are pointless
> too.

It is just to make sure those functions are not called by an unexpected 
code path since it is non-static. But I can remove it if you prefer that.


Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:05:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJlQ-0005DG-KH; Fri, 03 Feb 2012 14:05:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RtJlO-0005C8-DH
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:05:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328277910!11819912!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23264 invoked from network); 3 Feb 2012 14:05:12 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 14:05:12 -0000
Received: from mail151-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:05:08 +0000
Received: from mail151-ch1 (localhost [127.0.0.1])	by
	mail151-ch1-R.bigfish.com (Postfix) with ESMTP id 37FDF140567;
	Fri,  3 Feb 2012 14:05:10 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1
	(MessageSwitch) id 1328277907600371_9205;
	Fri,  3 Feb 2012 14:05:07 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.233])	by mail151-ch1.bigfish.com (Postfix) with ESMTP id
	8ED5520004B;	Fri,  3 Feb 2012 14:05:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:05:01 +0000
X-WSS-ID: 0LYTLSD-01-BEB-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 25381102800B;	Fri,  3 Feb 2012 08:05:01 -0600 (CST)
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;
	Fri, 3 Feb 2012 08:05:20 -0600
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.289.1;
	Fri, 3 Feb 2012 08:05:01 -0600
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, 3 Feb 2012
	09:04:59 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9EDFD49C0F1; Fri,  3 Feb 2012
	14:04:58 +0000 (GMT)
Message-ID: <4F2BEA93.6090401@amd.com>
Date: Fri, 3 Feb 2012 15:09:23 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F213167.3010400@amd.com>
	<4F296F180200007800070594@nat28.tlf.novell.com>
In-Reply-To: <4F296F180200007800070594@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
	non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/01/2012 04:58 PM, Jan Beulich wrote:
>>>> On 26.01.12 at 11:56, Wei Wang<wei.wang2@amd.com>  wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 24 16:46:17 2012 +0000
>> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Jan 26 11:50:02 2012 +0100
>> @@ -805,6 +805,9 @@ int guest_iommu_set_base(struct domain *
>>      p2m_type_t t;
>>      struct guest_iommu *iommu = domain_iommu(d);
>>
>> +    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>> +        return 0;
>
> Is it really appropriate/correct to return 0 here, while ...


good point, will be fixed in the next try. No one use 
guest_iommu_set_base so far until remaining patches got committed.

>> +
>>      if ( !iommu )
>>          return -EACCES;

>
> ... here it is -EACCES? Further, are the extra checks needed at all
> (i.e. wouldn't domain_iommu() return NULL in all of these cases
> anyway due to the same checks being added to guest_iommu_init())?
> If so, the checks you add to guest_iommu_destroy() are pointless
> too.

It is just to make sure those functions are not called by an unexpected 
code path since it is non-static. But I can remove it if you prefer that.


Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:06:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJme-0005Qy-3F; Fri, 03 Feb 2012 14:06:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RtJmc-0005Pu-U6
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:06:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328277986!13621725!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15884 invoked from network); 3 Feb 2012 14:06:28 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:06:28 -0000
Received: by pbds6 with SMTP id s6so21412277pbd.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 06:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=iOqpR5Zg7IMEjUf+v23tt3NKlFkpySxZWEcBEh+bCLA=;
	b=p+jZd6fMZqCGVaCo1ZtdOSf8esPN/UUSM3BC4cXxUty6mpCtjaoz/scM+44iSpjGAB
	nXSdfS6C4oJu6ec8M8S14gCCXXT88h/7zYF0JSBtsuSQlk5oYWe2fO/2Qudjyvyj9saq
	PRTVWp7e2R/hnkRrdDy8/LodggBS5tIY8XTX8=
MIME-Version: 1.0
Received: by 10.68.235.103 with SMTP id ul7mr18153013pbc.46.1328277985641;
	Fri, 03 Feb 2012 06:06:25 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Fri, 3 Feb 2012 06:06:25 -0800 (PST)
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
Date: Fri, 3 Feb 2012 15:06:25 +0100
X-Google-Sender-Auth: d1AEN0m2dpdrApagxODS3EklYdg
Message-ID: <CAPLaKK7ESo0U76zLX7ot_ccRCaZQxZ5QAGioBQuC9Y9jSbM=mQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 29 RFC] libxl: move device plug/unplug
	to a separate daemon
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT46Cj4gVGhp
cyBpcyB0aGUgZmlyc3QgYXR0ZW1wdCB0byBkZWxlZ2F0ZSBob3RwbHVnIGRldmljZSBwbHVnL3Vu
cGx1ZyB0byBhCj4gc2VwYXJhdGUgZGFlbW9uLiBUaGlzIHdpbGwgYWxzbyBhbGxvdyB0byBwbHVn
L3VucGx1ZyBkZXZpY2VzIGZyb20gYQo+IGRvbWFpbiBkaWZmZXJlbnQgdGhhbiBEb20wLCB1c3Vh
bGx5IGNhbGxlZCBhICJkcml2ZXIgZG9tYWluIi4KPgo+IFRoaXMgc2VyaWVzIGNvbnRhaW4gYSBt
aXggb2YgYnVnIGZpeGVzLCBtYWlubHkgZm9yIGRldmljZQo+IHVucGx1Zy9kZXN0cm95IHN5bmNo
cm9uaXphdGlvbiwgYW5kIGEgc2V0IG9mIG5ldyBmdW5jdGlvbnMgdGhhdAo+IGRlc2NyaWJlIGEg
bmV3IHByb3RvY29sIHRvIGJlIHVzZWQgd2hlbiBkZWxlZ2F0aW5nIHRoZSBwbHVnL3VucGx1ZyBv
Zgo+IGRldmljZXMgdG8gYSBkYWVtb24sIGNhbGxlZCB4bGRldmljZWQgKHhsLWRldmljZS1kYWVt
b24pLgo+Cj4gQXMgYSB2ZXJ5IGltcG9ydGFudCBub3RlLCBJIHdvdWxkIGxpa2UgdG8gYWRkIHRo
YXQgdGhpcyBoYXMgb25seSBiZWVuCj4gdGVzdGVkIHdpdGggUFYgRG9tVXMsIGFuZCB0aGF0IHFk
aXNrIHN1cHBvcnQgaXMgbWlzc2luZyAoeGxkZXZpY2VkIGlzCj4gbm90IHByZXBhcmVkIHRvIGxh
dW5jaCBhIHFlbXUtZG0gdG8gc3VwcG9ydCBxZGlzayBkZXZpY2VzKS4gSSB3aWxsCgpJJ3ZlIGFk
ZGVkIHFkaXNrIHN1cHBvcnQgdG8geGxkZXZpY2VkLCBidXQgSSB3aWxsIHdhaXQgYSBsaXR0bGUg
YmVmb3JlCnBvc3RpbmcgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBzZXJpZXMsIHRvIGhhdmUg
c29tZSBjb21tZW50cyBhbmQKYWRkcmVzcyBpbml0aWFsIGlzc3VlcyBiZWZvcmUgc2VuZGluZyBz
byBtdWNoIGNodW5rLiBJIHdpbGwgYWxzbyB0cnkKdG8gdGVzdCB0aGlzIGFnYWluc3QgSFZNIERv
bVVzIHRoZSBuZXh0IHdlZWsuCgo+IHdvcmsgb24gdGhhdCwgYnV0IEkgdGhpbmsgdGhlcmUncyBh
bHJlYWR5IGEgbG90IG9mIHN0dWZmIG9uIHRoaXMgdGhhdAo+IG5lZWRzIHByb3BlciByZXZpZXcu
Cj4KPiBUaGUgc2VyaWVzIGhhcyB0aGUgZm9sbG93aW5nIG9yZGVyOgo+Cj4gwqAqIHBhdGNoZXMg
MS0xNTogc2V0IGV2ZXJ5dGhpbmcgbmVjZXNzYXJ5IHRvIGV4ZWN1dGUgaG90cGx1ZyBzY3JpcHRz
Cj4gwqAgZnJvbSBsaWJ4bCBkaXJlY3RseS4KPgo+IMKgKiBwYXRjaGVzIDE2LTI1OiBhZGQgbmVj
ZXNzYXJ5IGxpYnhsIGZ1bmN0aW9ucyB0byBkZWxlZ2F0ZSBob3RwbHVnCj4gwqAgYWRkaXRpb24g
dG8gYSBkaWZmZXJlbnQgZGFlbW9uCj4KPiDCoCogcGF0Y2hlcyAyNi0yOTogaW50cm9kdWNlIHhs
ZGV2aWNlZCBhbmQgc3RhcnQgdXNpbmcgaXQgYnkgZGVmYXVsdC4KPgo+IFBhdGNoIDIwIGNvbnRh
aW5zIGEgZ29vZCBkZXNjcmlwdGlvbiBvZiB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiB4bCBhbmQK
PiB4bGRldmljZWQsIGFuZCB0aGUgeGVuc3RvcmUgZW50cmllcyB1c2VkIHRvIGFjY29tcGxpc2gg
dGhpcyB0YXNrLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:06:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:06:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJme-0005Qy-3F; Fri, 03 Feb 2012 14:06:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RtJmc-0005Pu-U6
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:06:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328277986!13621725!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15884 invoked from network); 3 Feb 2012 14:06:28 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:06:28 -0000
Received: by pbds6 with SMTP id s6so21412277pbd.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 06:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=iOqpR5Zg7IMEjUf+v23tt3NKlFkpySxZWEcBEh+bCLA=;
	b=p+jZd6fMZqCGVaCo1ZtdOSf8esPN/UUSM3BC4cXxUty6mpCtjaoz/scM+44iSpjGAB
	nXSdfS6C4oJu6ec8M8S14gCCXXT88h/7zYF0JSBtsuSQlk5oYWe2fO/2Qudjyvyj9saq
	PRTVWp7e2R/hnkRrdDy8/LodggBS5tIY8XTX8=
MIME-Version: 1.0
Received: by 10.68.235.103 with SMTP id ul7mr18153013pbc.46.1328277985641;
	Fri, 03 Feb 2012 06:06:25 -0800 (PST)
Received: by 10.142.238.6 with HTTP; Fri, 3 Feb 2012 06:06:25 -0800 (PST)
In-Reply-To: <patchbomb.1328189195@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
Date: Fri, 3 Feb 2012 15:06:25 +0100
X-Google-Sender-Auth: d1AEN0m2dpdrApagxODS3EklYdg
Message-ID: <CAPLaKK7ESo0U76zLX7ot_ccRCaZQxZ5QAGioBQuC9Y9jSbM=mQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 29 RFC] libxl: move device plug/unplug
	to a separate daemon
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT46Cj4gVGhp
cyBpcyB0aGUgZmlyc3QgYXR0ZW1wdCB0byBkZWxlZ2F0ZSBob3RwbHVnIGRldmljZSBwbHVnL3Vu
cGx1ZyB0byBhCj4gc2VwYXJhdGUgZGFlbW9uLiBUaGlzIHdpbGwgYWxzbyBhbGxvdyB0byBwbHVn
L3VucGx1ZyBkZXZpY2VzIGZyb20gYQo+IGRvbWFpbiBkaWZmZXJlbnQgdGhhbiBEb20wLCB1c3Vh
bGx5IGNhbGxlZCBhICJkcml2ZXIgZG9tYWluIi4KPgo+IFRoaXMgc2VyaWVzIGNvbnRhaW4gYSBt
aXggb2YgYnVnIGZpeGVzLCBtYWlubHkgZm9yIGRldmljZQo+IHVucGx1Zy9kZXN0cm95IHN5bmNo
cm9uaXphdGlvbiwgYW5kIGEgc2V0IG9mIG5ldyBmdW5jdGlvbnMgdGhhdAo+IGRlc2NyaWJlIGEg
bmV3IHByb3RvY29sIHRvIGJlIHVzZWQgd2hlbiBkZWxlZ2F0aW5nIHRoZSBwbHVnL3VucGx1ZyBv
Zgo+IGRldmljZXMgdG8gYSBkYWVtb24sIGNhbGxlZCB4bGRldmljZWQgKHhsLWRldmljZS1kYWVt
b24pLgo+Cj4gQXMgYSB2ZXJ5IGltcG9ydGFudCBub3RlLCBJIHdvdWxkIGxpa2UgdG8gYWRkIHRo
YXQgdGhpcyBoYXMgb25seSBiZWVuCj4gdGVzdGVkIHdpdGggUFYgRG9tVXMsIGFuZCB0aGF0IHFk
aXNrIHN1cHBvcnQgaXMgbWlzc2luZyAoeGxkZXZpY2VkIGlzCj4gbm90IHByZXBhcmVkIHRvIGxh
dW5jaCBhIHFlbXUtZG0gdG8gc3VwcG9ydCBxZGlzayBkZXZpY2VzKS4gSSB3aWxsCgpJJ3ZlIGFk
ZGVkIHFkaXNrIHN1cHBvcnQgdG8geGxkZXZpY2VkLCBidXQgSSB3aWxsIHdhaXQgYSBsaXR0bGUg
YmVmb3JlCnBvc3RpbmcgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBzZXJpZXMsIHRvIGhhdmUg
c29tZSBjb21tZW50cyBhbmQKYWRkcmVzcyBpbml0aWFsIGlzc3VlcyBiZWZvcmUgc2VuZGluZyBz
byBtdWNoIGNodW5rLiBJIHdpbGwgYWxzbyB0cnkKdG8gdGVzdCB0aGlzIGFnYWluc3QgSFZNIERv
bVVzIHRoZSBuZXh0IHdlZWsuCgo+IHdvcmsgb24gdGhhdCwgYnV0IEkgdGhpbmsgdGhlcmUncyBh
bHJlYWR5IGEgbG90IG9mIHN0dWZmIG9uIHRoaXMgdGhhdAo+IG5lZWRzIHByb3BlciByZXZpZXcu
Cj4KPiBUaGUgc2VyaWVzIGhhcyB0aGUgZm9sbG93aW5nIG9yZGVyOgo+Cj4gwqAqIHBhdGNoZXMg
MS0xNTogc2V0IGV2ZXJ5dGhpbmcgbmVjZXNzYXJ5IHRvIGV4ZWN1dGUgaG90cGx1ZyBzY3JpcHRz
Cj4gwqAgZnJvbSBsaWJ4bCBkaXJlY3RseS4KPgo+IMKgKiBwYXRjaGVzIDE2LTI1OiBhZGQgbmVj
ZXNzYXJ5IGxpYnhsIGZ1bmN0aW9ucyB0byBkZWxlZ2F0ZSBob3RwbHVnCj4gwqAgYWRkaXRpb24g
dG8gYSBkaWZmZXJlbnQgZGFlbW9uCj4KPiDCoCogcGF0Y2hlcyAyNi0yOTogaW50cm9kdWNlIHhs
ZGV2aWNlZCBhbmQgc3RhcnQgdXNpbmcgaXQgYnkgZGVmYXVsdC4KPgo+IFBhdGNoIDIwIGNvbnRh
aW5zIGEgZ29vZCBkZXNjcmlwdGlvbiBvZiB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiB4bCBhbmQK
PiB4bGRldmljZWQsIGFuZCB0aGUgeGVuc3RvcmUgZW50cmllcyB1c2VkIHRvIGFjY29tcGxpc2gg
dGhpcyB0YXNrLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:11:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJr5-0006If-5u; Fri, 03 Feb 2012 14:11:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJr3-0006Hr-It
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:11:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328278263!12750511!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18604 invoked from network); 3 Feb 2012 14:11:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 14:11:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 14:11:03 +0000
Message-Id: <4F2BF9050200007800070F69@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 14:11:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4F213167.3010400@amd.com>
	<4F296F180200007800070594@nat28.tlf.novell.com>
	<4F2BEA93.6090401@amd.com>
In-Reply-To: <4F2BEA93.6090401@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
 non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 15:09, Wei Wang <wei.wang2@amd.com> wrote:
> On 02/01/2012 04:58 PM, Jan Beulich wrote:
>> ... Further, are the extra checks needed at all
>> (i.e. wouldn't domain_iommu() return NULL in all of these cases
>> anyway due to the same checks being added to guest_iommu_init())?
>> If so, the checks you add to guest_iommu_destroy() are pointless
>> too.
> 
> It is just to make sure those functions are not called by an unexpected 
> code path since it is non-static. But I can remove it if you prefer that.

Keir already committed the patch, but converting things like this
(where the impossible is being checked) to assertions is preferred
imo (meaning less redundant, possibly dead code in production
builds), so a follow-up patch would be appreciated.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:11:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtJr5-0006If-5u; Fri, 03 Feb 2012 14:11:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtJr3-0006Hr-It
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:11:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328278263!12750511!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18604 invoked from network); 3 Feb 2012 14:11:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 14:11:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 14:11:03 +0000
Message-Id: <4F2BF9050200007800070F69@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 14:11:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <4F213167.3010400@amd.com>
	<4F296F180200007800070594@nat28.tlf.novell.com>
	<4F2BEA93.6090401@amd.com>
In-Reply-To: <4F2BEA93.6090401@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
 non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 15:09, Wei Wang <wei.wang2@amd.com> wrote:
> On 02/01/2012 04:58 PM, Jan Beulich wrote:
>> ... Further, are the extra checks needed at all
>> (i.e. wouldn't domain_iommu() return NULL in all of these cases
>> anyway due to the same checks being added to guest_iommu_init())?
>> If so, the checks you add to guest_iommu_destroy() are pointless
>> too.
> 
> It is just to make sure those functions are not called by an unexpected 
> code path since it is non-static. But I can remove it if you prefer that.

Keir already committed the patch, but converting things like this
(where the impossible is being checked) to assertions is preferred
imo (meaning less redundant, possibly dead code in production
builds), so a follow-up patch would be appreciated.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:24:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 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.xensource.com>)
	id 1RtK3U-00070v-IG; Fri, 03 Feb 2012 14:24:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RtK3T-00070q-AZ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:23:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328279032!13454345!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19743 invoked from network); 3 Feb 2012 14:23:53 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.144)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 14:23:53 -0000
Received: from mail22-db3-R.bigfish.com (10.3.81.243) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:23:50 +0000
Received: from mail22-db3 (localhost [127.0.0.1])	by mail22-db3-R.bigfish.com
	(Postfix) with ESMTP id 85EDF1805BF;
	Fri,  3 Feb 2012 14:23:52 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail22-db3 (localhost.localdomain [127.0.0.1]) by mail22-db3
	(MessageSwitch) id 132827903064809_7285; Fri,  3 Feb 2012 14:23:50 +0000
	(UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.234])	by
	mail22-db3.bigfish.com (Postfix) with ESMTP id 0AE462A0045;
	Fri,  3 Feb 2012 14:23:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:23:46 +0000
X-WSS-ID: 0LYTMNL-01-0GM-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 25B8610280E8;	Fri,  3 Feb 2012 08:23:45 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 3 Feb 2012 08:24:04 -0600
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.289.1;
	Fri, 3 Feb 2012 08:23:46 -0600
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, 3 Feb 2012
	09:23:45 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 42EAD49C0F1; Fri,  3 Feb 2012
	14:23:44 +0000 (GMT)
Message-ID: <4F2BEEF9.1050909@amd.com>
Date: Fri, 3 Feb 2012 15:28:09 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F213167.3010400@amd.com>
	<4F296F180200007800070594@nat28.tlf.novell.com>
	<4F2BEA93.6090401@amd.com>
	<4F2BF9050200007800070F69@nat28.tlf.novell.com>
In-Reply-To: <4F2BF9050200007800070F69@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
	non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/2012 03:11 PM, Jan Beulich wrote:
>>>> On 03.02.12 at 15:09, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 02/01/2012 04:58 PM, Jan Beulich wrote:
>>> ... Further, are the extra checks needed at all
>>> (i.e. wouldn't domain_iommu() return NULL in all of these cases
>>> anyway due to the same checks being added to guest_iommu_init())?
>>> If so, the checks you add to guest_iommu_destroy() are pointless
>>> too.
>>
>> It is just to make sure those functions are not called by an unexpected
>> code path since it is non-static. But I can remove it if you prefer that.
>
> Keir already committed the patch, but converting things like this
> (where the impossible is being checked) to assertions is preferred
> imo (meaning less redundant, possibly dead code in production
> builds), so a follow-up patch would be appreciated.
No problem. Do it right away.
Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:24:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 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.xensource.com>)
	id 1RtK3U-00070v-IG; Fri, 03 Feb 2012 14:24:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RtK3T-00070q-AZ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:23:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328279032!13454345!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19743 invoked from network); 3 Feb 2012 14:23:53 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.144)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 14:23:53 -0000
Received: from mail22-db3-R.bigfish.com (10.3.81.243) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:23:50 +0000
Received: from mail22-db3 (localhost [127.0.0.1])	by mail22-db3-R.bigfish.com
	(Postfix) with ESMTP id 85EDF1805BF;
	Fri,  3 Feb 2012 14:23:52 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail22-db3 (localhost.localdomain [127.0.0.1]) by mail22-db3
	(MessageSwitch) id 132827903064809_7285; Fri,  3 Feb 2012 14:23:50 +0000
	(UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.234])	by
	mail22-db3.bigfish.com (Postfix) with ESMTP id 0AE462A0045;
	Fri,  3 Feb 2012 14:23:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 14:23:46 +0000
X-WSS-ID: 0LYTMNL-01-0GM-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 25B8610280E8;	Fri,  3 Feb 2012 08:23:45 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 3 Feb 2012 08:24:04 -0600
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.289.1;
	Fri, 3 Feb 2012 08:23:46 -0600
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, 3 Feb 2012
	09:23:45 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 42EAD49C0F1; Fri,  3 Feb 2012
	14:23:44 +0000 (GMT)
Message-ID: <4F2BEEF9.1050909@amd.com>
Date: Fri, 3 Feb 2012 15:28:09 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F213167.3010400@amd.com>
	<4F296F180200007800070594@nat28.tlf.novell.com>
	<4F2BEA93.6090401@amd.com>
	<4F2BF9050200007800070F69@nat28.tlf.novell.com>
In-Reply-To: <4F2BF9050200007800070F69@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: KeirFraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on
	non-iommu systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/2012 03:11 PM, Jan Beulich wrote:
>>>> On 03.02.12 at 15:09, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 02/01/2012 04:58 PM, Jan Beulich wrote:
>>> ... Further, are the extra checks needed at all
>>> (i.e. wouldn't domain_iommu() return NULL in all of these cases
>>> anyway due to the same checks being added to guest_iommu_init())?
>>> If so, the checks you add to guest_iommu_destroy() are pointless
>>> too.
>>
>> It is just to make sure those functions are not called by an unexpected
>> code path since it is non-static. But I can remove it if you prefer that.
>
> Keir already committed the patch, but converting things like this
> (where the impossible is being checked) to assertions is preferred
> imo (meaning less redundant, possibly dead code in production
> builds), so a follow-up patch would be appreciated.
No problem. Do it right away.
Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:50:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14: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.xensource.com>)
	id 1RtKSf-0008G2-Jy; Fri, 03 Feb 2012 14:50:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtKSd-0008Fx-R2
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:50:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328280593!13320630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7370 invoked from network); 3 Feb 2012 14:49:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:49:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10472125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:49:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:49:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtKSW-0008B6-UM;
	Fri, 03 Feb 2012 14:49:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtKSW-000706-O6;
	Fri, 03 Feb 2012 14:49:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11857-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 14:49:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11857: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11857 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11857/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3432abcf9380
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.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>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 1600 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:50:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14: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.xensource.com>)
	id 1RtKSf-0008G2-Jy; Fri, 03 Feb 2012 14:50:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtKSd-0008Fx-R2
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:50:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328280593!13320630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7370 invoked from network); 3 Feb 2012 14:49:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:49:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10472125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:49:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:49:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtKSW-0008B6-UM;
	Fri, 03 Feb 2012 14:49:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtKSW-000706-O6;
	Fri, 03 Feb 2012 14:49:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11857-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 14:49:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11857: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11857 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11857/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3432abcf9380
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.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>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 1600 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:59:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKbJ-0008Pi-RN; Fri, 03 Feb 2012 14:58:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtKbH-0008Pd-JL
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:58:55 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328281127!13630655!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12224 invoked from network); 3 Feb 2012 14:58:49 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 14:58:49 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
Thread-Index: AQHM4nh5cktTzJ95FkaSaySuJubVe5YruRGA
Date: Fri, 3 Feb 2012 14:58:46 +0000
Message-ID: <08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
In-Reply-To: <4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <095EC5DCAB0EB745ADAAD65365D2002B@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> @@ -187,6 +216,25 @@
>>  *      The machine ABI rules governing the format of all ring request and
>>  *      response structures.
>>  *
>> + * ring-page-order
>> + *      Values:         <uint32_t>
>> + *      Default Value:  0
>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> 
> Why not just max-ring-page-order. After all, the value is meaningless
> for a backend that only exposes max-ring-pages.
> 
>> + *      Notes:          1, 3
>> + *
>> + *      The size of the frontend allocated request ring buffer in units
>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>> + *      etc.).
>> + *
>> + * ring-pages
>> + *      Values:         <uint32_t>
>> + *      Default Value:  1
>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> 
> Similarly here - just max-ring-pages should do.

This patch documents existing extensions.  For a new driver to properly negotiate a
multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
you must use the XenBus node names as I've defined them here.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 14:59:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 14:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKbJ-0008Pi-RN; Fri, 03 Feb 2012 14:58:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtKbH-0008Pd-JL
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:58:55 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328281127!13630655!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12224 invoked from network); 3 Feb 2012 14:58:49 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 14:58:49 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
Thread-Index: AQHM4nh5cktTzJ95FkaSaySuJubVe5YruRGA
Date: Fri, 3 Feb 2012 14:58:46 +0000
Message-ID: <08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
In-Reply-To: <4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <095EC5DCAB0EB745ADAAD65365D2002B@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> @@ -187,6 +216,25 @@
>>  *      The machine ABI rules governing the format of all ring request and
>>  *      response structures.
>>  *
>> + * ring-page-order
>> + *      Values:         <uint32_t>
>> + *      Default Value:  0
>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> 
> Why not just max-ring-page-order. After all, the value is meaningless
> for a backend that only exposes max-ring-pages.
> 
>> + *      Notes:          1, 3
>> + *
>> + *      The size of the frontend allocated request ring buffer in units
>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>> + *      etc.).
>> + *
>> + * ring-pages
>> + *      Values:         <uint32_t>
>> + *      Default Value:  1
>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> 
> Similarly here - just max-ring-pages should do.

This patch documents existing extensions.  For a new driver to properly negotiate a
multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
you must use the XenBus node names as I've defined them here.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:02:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15: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.xensource.com>)
	id 1RtKeN-000088-Pc; Fri, 03 Feb 2012 15:02:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtKeM-00007x-CG
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:02:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328281201!62437172!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5021 invoked from network); 3 Feb 2012 15:00:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 15:00:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 15:01:59 +0000
Message-Id: <4F2C04F50200007800071056@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 15:01:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
In-Reply-To: <08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 15:58, Justin Gibbs <justing@spectralogic.com> wrote:
> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> 
>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>> @@ -187,6 +216,25 @@
>>>  *      The machine ABI rules governing the format of all ring request and
>>>  *      response structures.
>>>  *
>>> + * ring-page-order
>>> + *      Values:         <uint32_t>
>>> + *      Default Value:  0
>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>> 
>> Why not just max-ring-page-order. After all, the value is meaningless
>> for a backend that only exposes max-ring-pages.
>> 
>>> + *      Notes:          1, 3
>>> + *
>>> + *      The size of the frontend allocated request ring buffer in units
>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>> + *      etc.).
>>> + *
>>> + * ring-pages
>>> + *      Values:         <uint32_t>
>>> + *      Default Value:  1
>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>> 
>> Similarly here - just max-ring-pages should do.
> 
> This patch documents existing extensions.  For a new driver to properly 
> negotiate a
> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest 
> (ring-page-order),
> you must use the XenBus node names as I've defined them here.

That wasn't my point. I was exclusively asking the maximum values to
get simplified.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:02:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15: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.xensource.com>)
	id 1RtKeN-000088-Pc; Fri, 03 Feb 2012 15:02:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtKeM-00007x-CG
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:02:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328281201!62437172!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5021 invoked from network); 3 Feb 2012 15:00:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 15:00:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 15:01:59 +0000
Message-Id: <4F2C04F50200007800071056@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 15:01:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
In-Reply-To: <08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 15:58, Justin Gibbs <justing@spectralogic.com> wrote:
> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> 
>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>> @@ -187,6 +216,25 @@
>>>  *      The machine ABI rules governing the format of all ring request and
>>>  *      response structures.
>>>  *
>>> + * ring-page-order
>>> + *      Values:         <uint32_t>
>>> + *      Default Value:  0
>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>> 
>> Why not just max-ring-page-order. After all, the value is meaningless
>> for a backend that only exposes max-ring-pages.
>> 
>>> + *      Notes:          1, 3
>>> + *
>>> + *      The size of the frontend allocated request ring buffer in units
>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>> + *      etc.).
>>> + *
>>> + * ring-pages
>>> + *      Values:         <uint32_t>
>>> + *      Default Value:  1
>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>> 
>> Similarly here - just max-ring-pages should do.
> 
> This patch documents existing extensions.  For a new driver to properly 
> negotiate a
> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest 
> (ring-page-order),
> you must use the XenBus node names as I've defined them here.

That wasn't my point. I was exclusively asking the maximum values to
get simplified.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:09:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKlH-0000LQ-Lw; Fri, 03 Feb 2012 15:09:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtKlF-0000LI-Rg
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:09:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328281747!10346079!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5249 invoked from network); 3 Feb 2012 15:09:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 15:09:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 15:09:07 +0000
Message-Id: <4F2C06A00200007800071071@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 15:09:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use 'bool' for boolean variables. Do proper section placement.
Eliminate an unnecessary export.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>

---
 drivers/xen/tmem.c |   21 ++++++++-------------
 include/xen/tmem.h |    6 +++++-
 2 files changed, 13 insertions(+), 14 deletions(-)

--- 3.3-rc2/drivers/xen/tmem.c
+++ 3.3-rc2-xen-tmem-cleanup/drivers/xen/tmem.c
@@ -9,7 +9,6 @@
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
-#include <linux/module.h>
 #include <linux/cleancache.h>
 
 /* temporary ifdef until include/linux/frontswap.h is upstream */
@@ -128,15 +127,13 @@ static int xen_tmem_flush_object(u32 poo
 	return xen_tmem_op(TMEM_FLUSH_OBJECT, pool_id, oid, 0, 0, 0, 0, 0);
 }
 
-int tmem_enabled __read_mostly;
-EXPORT_SYMBOL(tmem_enabled);
+bool __read_mostly tmem_enabled = false;
 
 static int __init enable_tmem(char *s)
 {
-	tmem_enabled = 1;
+	tmem_enabled = true;
 	return 1;
 }
-
 __setup("tmem", enable_tmem);
 
 #ifdef CONFIG_CLEANCACHE
@@ -229,17 +226,16 @@ static int tmem_cleancache_init_shared_f
 	return xen_tmem_new_pool(shared_uuid, TMEM_POOL_SHARED, pagesize);
 }
 
-static int use_cleancache = 1;
+static bool __initdata use_cleancache = true;
 
 static int __init no_cleancache(char *s)
 {
-	use_cleancache = 0;
+	use_cleancache = false;
 	return 1;
 }
-
 __setup("nocleancache", no_cleancache);
 
-static struct cleancache_ops tmem_cleancache_ops = {
+static struct cleancache_ops __initdata tmem_cleancache_ops = {
 	.put_page = tmem_cleancache_put_page,
 	.get_page = tmem_cleancache_get_page,
 	.flush_page = tmem_cleancache_flush_page,
@@ -356,17 +352,16 @@ static void tmem_frontswap_init(unsigned
 		    xen_tmem_new_pool(private, TMEM_POOL_PERSIST, PAGE_SIZE);
 }
 
-static int __initdata use_frontswap = 1;
+static bool __initdata use_frontswap = true;
 
 static int __init no_frontswap(char *s)
 {
-	use_frontswap = 0;
+	use_frontswap = false;
 	return 1;
 }
-
 __setup("nofrontswap", no_frontswap);
 
-static struct frontswap_ops tmem_frontswap_ops = {
+static struct frontswap_ops __initdata tmem_frontswap_ops = {
 	.put_page = tmem_frontswap_put_page,
 	.get_page = tmem_frontswap_get_page,
 	.flush_page = tmem_frontswap_flush_page,
--- 3.3-rc2/include/xen/tmem.h
+++ 3.3-rc2-xen-tmem-cleanup/include/xen/tmem.h
@@ -1,5 +1,9 @@
 #ifndef _XEN_TMEM_H
 #define _XEN_TMEM_H
+
+#include <linux/types.h>
+
 /* defined in drivers/xen/tmem.c */
-extern int tmem_enabled;
+extern bool tmem_enabled;
+
 #endif /* _XEN_TMEM_H */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:09:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKlH-0000LQ-Lw; Fri, 03 Feb 2012 15:09:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtKlF-0000LI-Rg
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:09:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328281747!10346079!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5249 invoked from network); 3 Feb 2012 15:09:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 15:09:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 15:09:07 +0000
Message-Id: <4F2C06A00200007800071071@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 15:09:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use 'bool' for boolean variables. Do proper section placement.
Eliminate an unnecessary export.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>

---
 drivers/xen/tmem.c |   21 ++++++++-------------
 include/xen/tmem.h |    6 +++++-
 2 files changed, 13 insertions(+), 14 deletions(-)

--- 3.3-rc2/drivers/xen/tmem.c
+++ 3.3-rc2-xen-tmem-cleanup/drivers/xen/tmem.c
@@ -9,7 +9,6 @@
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
-#include <linux/module.h>
 #include <linux/cleancache.h>
 
 /* temporary ifdef until include/linux/frontswap.h is upstream */
@@ -128,15 +127,13 @@ static int xen_tmem_flush_object(u32 poo
 	return xen_tmem_op(TMEM_FLUSH_OBJECT, pool_id, oid, 0, 0, 0, 0, 0);
 }
 
-int tmem_enabled __read_mostly;
-EXPORT_SYMBOL(tmem_enabled);
+bool __read_mostly tmem_enabled = false;
 
 static int __init enable_tmem(char *s)
 {
-	tmem_enabled = 1;
+	tmem_enabled = true;
 	return 1;
 }
-
 __setup("tmem", enable_tmem);
 
 #ifdef CONFIG_CLEANCACHE
@@ -229,17 +226,16 @@ static int tmem_cleancache_init_shared_f
 	return xen_tmem_new_pool(shared_uuid, TMEM_POOL_SHARED, pagesize);
 }
 
-static int use_cleancache = 1;
+static bool __initdata use_cleancache = true;
 
 static int __init no_cleancache(char *s)
 {
-	use_cleancache = 0;
+	use_cleancache = false;
 	return 1;
 }
-
 __setup("nocleancache", no_cleancache);
 
-static struct cleancache_ops tmem_cleancache_ops = {
+static struct cleancache_ops __initdata tmem_cleancache_ops = {
 	.put_page = tmem_cleancache_put_page,
 	.get_page = tmem_cleancache_get_page,
 	.flush_page = tmem_cleancache_flush_page,
@@ -356,17 +352,16 @@ static void tmem_frontswap_init(unsigned
 		    xen_tmem_new_pool(private, TMEM_POOL_PERSIST, PAGE_SIZE);
 }
 
-static int __initdata use_frontswap = 1;
+static bool __initdata use_frontswap = true;
 
 static int __init no_frontswap(char *s)
 {
-	use_frontswap = 0;
+	use_frontswap = false;
 	return 1;
 }
-
 __setup("nofrontswap", no_frontswap);
 
-static struct frontswap_ops tmem_frontswap_ops = {
+static struct frontswap_ops __initdata tmem_frontswap_ops = {
 	.put_page = tmem_frontswap_put_page,
 	.get_page = tmem_frontswap_get_page,
 	.flush_page = tmem_frontswap_flush_page,
--- 3.3-rc2/include/xen/tmem.h
+++ 3.3-rc2-xen-tmem-cleanup/include/xen/tmem.h
@@ -1,5 +1,9 @@
 #ifndef _XEN_TMEM_H
 #define _XEN_TMEM_H
+
+#include <linux/types.h>
+
 /* defined in drivers/xen/tmem.c */
-extern int tmem_enabled;
+extern bool tmem_enabled;
+
 #endif /* _XEN_TMEM_H */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpH-0000TM-GT; Fri, 03 Feb 2012 15:13:23 +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 1RtKpF-0000TB-To
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328281927!62491939!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11920 invoked from network); 3 Feb 2012 15:12:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP;
	3 Feb 2012 15:12:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDEeo012503; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD65024513; 
	Fri, 3 Feb 2012 10:13:14 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:13:01 -0500
Message-Id: <1328281981-17399-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen: Remove unused vsscanf/sscanf functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/vsprintf.c |  236 -------------------------------------------------
 xen/include/xen/lib.h |    4 -
 2 files changed, 0 insertions(+), 240 deletions(-)

diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index d9128e1..00a6e09 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -512,223 +512,6 @@ int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
 EXPORT_SYMBOL(vscnprintf);
 
 /**
- * vsscanf - Unformat a buffer into a list of arguments
- * @buf:    input buffer
- * @fmt:    format of buffer
- * @args:   arguments
- */
-int vsscanf(const char * buf, const char * fmt, va_list args)
-{
-    const char *str = buf;
-    const char *next;
-    char digit;
-    int num = 0;
-    int qualifier;
-    int base;
-    int field_width;
-    int is_sign = 0;
-
-    while (*fmt && *str) {
-        /* skip any white space in format */
-        /* white space in format matchs any amount of
-         * white space, including none, in the input.
-         */
-        if (isspace(*fmt)) {
-            while (isspace(*fmt))
-                ++fmt;
-            while (isspace(*str))
-                ++str;
-        }
-
-        /* anything that is not a conversion must match exactly */
-        if (*fmt != '%' && *fmt) {
-            if (*fmt++ != *str++)
-                break;
-            continue;
-        }
-
-        if (!*fmt)
-            break;
-        ++fmt;
-
-        /* skip this conversion.
-         * advance both strings to next white space
-         */
-        if (*fmt == '*') {
-            while (!isspace(*fmt) && *fmt)
-                fmt++;
-            while (!isspace(*str) && *str)
-                str++;
-            continue;
-        }
-
-        /* get field width */
-        field_width = -1;
-        if (isdigit(*fmt))
-            field_width = skip_atoi(&fmt);
-
-        /* get conversion qualifier */
-        qualifier = -1;
-        if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' || *fmt == 'Z'
-            || *fmt == 'z') {
-            qualifier = *fmt++;
-            if (unlikely(qualifier == *fmt)) {
-                if (qualifier == 'h') {
-                    qualifier = 'H';
-                    fmt++;
-                } else if (qualifier == 'l') {
-                    qualifier = 'L';
-                    fmt++;
-                }
-            }
-        }
-        base = 10;
-        is_sign = 0;
-
-        if (!*fmt || !*str)
-            break;
-
-        switch(*fmt++) {
-            case 'c': {
-                char *s = (char *) va_arg(args,char*);
-                if (field_width == -1)
-                    field_width = 1;
-                do {
-                    *s++ = *str++;
-                } while (--field_width > 0 && *str);
-                num++;
-            }
-            continue;
-            case 's': {
-                char *s = (char *) va_arg(args, char *);
-                if(field_width == -1)
-                    field_width = INT_MAX;
-                /* first, skip leading white space in buffer */
-                while (isspace(*str))
-                    str++;
-
-                /* now copy until next white space */
-                while (*str && !isspace(*str) && field_width--)
-                    *s++ = *str++;
-                *s = '\0';
-                num++;
-            }
-            continue;
-            case 'n': {
-            /* return number of characters read so far */
-                int *i = (int *)va_arg(args,int*);
-                *i = str - buf;
-            }
-            continue;
-            case 'o':
-                base = 8;
-            break;
-            case 'x':
-            case 'X':
-                base = 16;
-            break;
-            case 'i':
-                base = 0;
-            case 'd':
-                is_sign = 1;
-            case 'u':
-            break;
-            case '%':
-                /* looking for '%' in str */
-                if (*str++ != '%') 
-                    return num;
-            continue;
-            default:
-                /* invalid format; stop here */
-                return num;
-        }
-
-        /* have some sort of integer conversion.
-         * first, skip white space in buffer.
-         */
-        while (isspace(*str))
-            str++;
-
-        digit = *str;
-        if (is_sign && digit == '-')
-            digit = *(str + 1);
-
-        if (!digit || (base == 16 && !isxdigit(digit))
-                || (base == 10 && !isdigit(digit))
-                || (base == 8 && (!isdigit(digit) || digit > '7'))
-                || (base == 0 && !isdigit(digit)))
-            break;
-
-        switch(qualifier) {
-            case 'H': /* that's 'hh' in format */
-                if (is_sign) {
-                    signed char *s = (signed char *) va_arg(args,signed char *);
-                    *s = (signed char) simple_strtol(str,&next,base);
-                } else {
-                    unsigned char *s = (unsigned char *) 
-                                                va_arg(args, unsigned char *);
-                    *s = (unsigned char) simple_strtoul(str, &next, base);
-                }
-            break;
-            case 'h':
-                if (is_sign) {
-                    short *s = (short *) va_arg(args,short *);
-                    *s = (short) simple_strtol(str,&next,base);
-                } else {
-                    unsigned short *s = (unsigned short *) 
-                                                va_arg(args, unsigned short *);
-                    *s = (unsigned short) simple_strtoul(str, &next, base);
-                }
-            break;
-            case 'l':
-                if (is_sign) {
-                    long *l = (long *) va_arg(args,long *);
-                    *l = simple_strtol(str,&next,base);
-                } else {
-                    unsigned long *l = (unsigned long*) 
-                                                    va_arg(args,unsigned long*);
-                    *l = simple_strtoul(str,&next,base);
-                }
-            break;
-            case 'L':
-                if (is_sign) {
-                    long long *l = (long long*) va_arg(args,long long *);
-                    *l = simple_strtoll(str,&next,base);
-                } else {
-                    unsigned long long *l = (unsigned long long*) 
-                                            va_arg(args,unsigned long long*);
-                    *l = simple_strtoull(str,&next,base);
-                }
-            break;
-            case 'Z':
-            case 'z': {
-                size_t *s = (size_t*) va_arg(args,size_t*);
-                *s = (size_t) simple_strtoul(str,&next,base);
-            }
-            break;
-            default:
-                if (is_sign) {
-                    int *i = (int *) va_arg(args, int*);
-                    *i = (int) simple_strtol(str,&next,base);
-                } else {
-                    unsigned int *i = (unsigned int*) 
-                                                    va_arg(args, unsigned int*);
-                    *i = (unsigned int) simple_strtoul(str,&next,base);
-                }
-            break;
-        }
-        num++;
-
-        if (!next)
-            break;
-        str = next;
-    }
-    return num;
-}
-
-EXPORT_SYMBOL(vsscanf);
-
-/**
  * snprintf - Format a string and place it in a buffer
  * @buf: The buffer to place the result into
  * @size: The size of the buffer, including the trailing null space
@@ -779,25 +562,6 @@ int scnprintf(char * buf, size_t size, const char *fmt, ...)
 }
 EXPORT_SYMBOL(scnprintf);
 
-/**
- * sscanf - Unformat a buffer into a list of arguments
- * @buf:    input buffer
- * @fmt:    formatting of buffer
- * @...:    resulting arguments
- */
-int sscanf(const char * buf, const char * fmt, ...)
-{
-    va_list args;
-    int i;
-
-    va_start(args,fmt);
-    i = vsscanf(buf,fmt,args);
-    va_end(args);
-    return i;
-}
-
-EXPORT_SYMBOL(sscanf);
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index c8cd9fc..d6f9182 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -89,10 +89,6 @@ extern int scnprintf(char * buf, size_t size, const char * fmt, ...)
     __attribute__ ((format (printf, 3, 4)));
 extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
     __attribute__ ((format (printf, 3, 0)));
-extern int sscanf(const char * buf, const char * fmt, ...)
-    __attribute__ ((format (scanf, 2, 3)));
-extern int vsscanf(const char * buf, const char * fmt, va_list args)
-    __attribute__ ((format (scanf, 2, 0)));
 
 long simple_strtol(
     const char *cp,const char **endp, unsigned int base);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpH-0000TM-GT; Fri, 03 Feb 2012 15:13:23 +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 1RtKpF-0000TB-To
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328281927!62491939!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11920 invoked from network); 3 Feb 2012 15:12:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP;
	3 Feb 2012 15:12:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDEeo012503; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD65024513; 
	Fri, 3 Feb 2012 10:13:14 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:13:01 -0500
Message-Id: <1328281981-17399-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen: Remove unused vsscanf/sscanf functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/vsprintf.c |  236 -------------------------------------------------
 xen/include/xen/lib.h |    4 -
 2 files changed, 0 insertions(+), 240 deletions(-)

diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index d9128e1..00a6e09 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -512,223 +512,6 @@ int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
 EXPORT_SYMBOL(vscnprintf);
 
 /**
- * vsscanf - Unformat a buffer into a list of arguments
- * @buf:    input buffer
- * @fmt:    format of buffer
- * @args:   arguments
- */
-int vsscanf(const char * buf, const char * fmt, va_list args)
-{
-    const char *str = buf;
-    const char *next;
-    char digit;
-    int num = 0;
-    int qualifier;
-    int base;
-    int field_width;
-    int is_sign = 0;
-
-    while (*fmt && *str) {
-        /* skip any white space in format */
-        /* white space in format matchs any amount of
-         * white space, including none, in the input.
-         */
-        if (isspace(*fmt)) {
-            while (isspace(*fmt))
-                ++fmt;
-            while (isspace(*str))
-                ++str;
-        }
-
-        /* anything that is not a conversion must match exactly */
-        if (*fmt != '%' && *fmt) {
-            if (*fmt++ != *str++)
-                break;
-            continue;
-        }
-
-        if (!*fmt)
-            break;
-        ++fmt;
-
-        /* skip this conversion.
-         * advance both strings to next white space
-         */
-        if (*fmt == '*') {
-            while (!isspace(*fmt) && *fmt)
-                fmt++;
-            while (!isspace(*str) && *str)
-                str++;
-            continue;
-        }
-
-        /* get field width */
-        field_width = -1;
-        if (isdigit(*fmt))
-            field_width = skip_atoi(&fmt);
-
-        /* get conversion qualifier */
-        qualifier = -1;
-        if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' || *fmt == 'Z'
-            || *fmt == 'z') {
-            qualifier = *fmt++;
-            if (unlikely(qualifier == *fmt)) {
-                if (qualifier == 'h') {
-                    qualifier = 'H';
-                    fmt++;
-                } else if (qualifier == 'l') {
-                    qualifier = 'L';
-                    fmt++;
-                }
-            }
-        }
-        base = 10;
-        is_sign = 0;
-
-        if (!*fmt || !*str)
-            break;
-
-        switch(*fmt++) {
-            case 'c': {
-                char *s = (char *) va_arg(args,char*);
-                if (field_width == -1)
-                    field_width = 1;
-                do {
-                    *s++ = *str++;
-                } while (--field_width > 0 && *str);
-                num++;
-            }
-            continue;
-            case 's': {
-                char *s = (char *) va_arg(args, char *);
-                if(field_width == -1)
-                    field_width = INT_MAX;
-                /* first, skip leading white space in buffer */
-                while (isspace(*str))
-                    str++;
-
-                /* now copy until next white space */
-                while (*str && !isspace(*str) && field_width--)
-                    *s++ = *str++;
-                *s = '\0';
-                num++;
-            }
-            continue;
-            case 'n': {
-            /* return number of characters read so far */
-                int *i = (int *)va_arg(args,int*);
-                *i = str - buf;
-            }
-            continue;
-            case 'o':
-                base = 8;
-            break;
-            case 'x':
-            case 'X':
-                base = 16;
-            break;
-            case 'i':
-                base = 0;
-            case 'd':
-                is_sign = 1;
-            case 'u':
-            break;
-            case '%':
-                /* looking for '%' in str */
-                if (*str++ != '%') 
-                    return num;
-            continue;
-            default:
-                /* invalid format; stop here */
-                return num;
-        }
-
-        /* have some sort of integer conversion.
-         * first, skip white space in buffer.
-         */
-        while (isspace(*str))
-            str++;
-
-        digit = *str;
-        if (is_sign && digit == '-')
-            digit = *(str + 1);
-
-        if (!digit || (base == 16 && !isxdigit(digit))
-                || (base == 10 && !isdigit(digit))
-                || (base == 8 && (!isdigit(digit) || digit > '7'))
-                || (base == 0 && !isdigit(digit)))
-            break;
-
-        switch(qualifier) {
-            case 'H': /* that's 'hh' in format */
-                if (is_sign) {
-                    signed char *s = (signed char *) va_arg(args,signed char *);
-                    *s = (signed char) simple_strtol(str,&next,base);
-                } else {
-                    unsigned char *s = (unsigned char *) 
-                                                va_arg(args, unsigned char *);
-                    *s = (unsigned char) simple_strtoul(str, &next, base);
-                }
-            break;
-            case 'h':
-                if (is_sign) {
-                    short *s = (short *) va_arg(args,short *);
-                    *s = (short) simple_strtol(str,&next,base);
-                } else {
-                    unsigned short *s = (unsigned short *) 
-                                                va_arg(args, unsigned short *);
-                    *s = (unsigned short) simple_strtoul(str, &next, base);
-                }
-            break;
-            case 'l':
-                if (is_sign) {
-                    long *l = (long *) va_arg(args,long *);
-                    *l = simple_strtol(str,&next,base);
-                } else {
-                    unsigned long *l = (unsigned long*) 
-                                                    va_arg(args,unsigned long*);
-                    *l = simple_strtoul(str,&next,base);
-                }
-            break;
-            case 'L':
-                if (is_sign) {
-                    long long *l = (long long*) va_arg(args,long long *);
-                    *l = simple_strtoll(str,&next,base);
-                } else {
-                    unsigned long long *l = (unsigned long long*) 
-                                            va_arg(args,unsigned long long*);
-                    *l = simple_strtoull(str,&next,base);
-                }
-            break;
-            case 'Z':
-            case 'z': {
-                size_t *s = (size_t*) va_arg(args,size_t*);
-                *s = (size_t) simple_strtoul(str,&next,base);
-            }
-            break;
-            default:
-                if (is_sign) {
-                    int *i = (int *) va_arg(args, int*);
-                    *i = (int) simple_strtol(str,&next,base);
-                } else {
-                    unsigned int *i = (unsigned int*) 
-                                                    va_arg(args, unsigned int*);
-                    *i = (unsigned int) simple_strtoul(str,&next,base);
-                }
-            break;
-        }
-        num++;
-
-        if (!next)
-            break;
-        str = next;
-    }
-    return num;
-}
-
-EXPORT_SYMBOL(vsscanf);
-
-/**
  * snprintf - Format a string and place it in a buffer
  * @buf: The buffer to place the result into
  * @size: The size of the buffer, including the trailing null space
@@ -779,25 +562,6 @@ int scnprintf(char * buf, size_t size, const char *fmt, ...)
 }
 EXPORT_SYMBOL(scnprintf);
 
-/**
- * sscanf - Unformat a buffer into a list of arguments
- * @buf:    input buffer
- * @fmt:    formatting of buffer
- * @...:    resulting arguments
- */
-int sscanf(const char * buf, const char * fmt, ...)
-{
-    va_list args;
-    int i;
-
-    va_start(args,fmt);
-    i = vsscanf(buf,fmt,args);
-    va_end(args);
-    return i;
-}
-
-EXPORT_SYMBOL(sscanf);
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index c8cd9fc..d6f9182 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -89,10 +89,6 @@ extern int scnprintf(char * buf, size_t size, const char * fmt, ...)
     __attribute__ ((format (printf, 3, 4)));
 extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
     __attribute__ ((format (printf, 3, 0)));
-extern int sscanf(const char * buf, const char * fmt, ...)
-    __attribute__ ((format (scanf, 2, 3)));
-extern int vsscanf(const char * buf, const char * fmt, va_list args)
-    __attribute__ ((format (scanf, 2, 0)));
 
 long simple_strtol(
     const char *cp,const char **endp, unsigned int base);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpH-0000TX-TU; Fri, 03 Feb 2012 15:13:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpH-0000T9-2b
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328281996!13604849!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13254 invoked from network); 3 Feb 2012 15:13:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-182.messagelabs.com with SMTP;
	3 Feb 2012 15:13:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDDni011007; Fri, 3 Feb 2012 15:13:13 GMT
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 q13FDD61024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:12:57 -0500
Message-Id: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: keir@xen.org, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 0/4] Update flask_op hypercall interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The FLASK hypercall interface originally attempted to emulate the
read/write interface used by SELinux, passing human-readable strings to
and from the hypervisor. This resulted in unnecessary string parsing and
conversion in the hypervisor and toolstack.

This series (primarily patch #3) converts the hypercall to use a
union-of-structures similar to the other Xen hypercalls. The wrappers in
libxc have been updated to preserve API compatibility where possible.

[PATCH 1/4] tools/flask: remove libflask
[PATCH 2/4] .gitignore/.hgignore: add missing output files
[PATCH 3/4] flask: Update flask_op hypercall structure
[PATCH 4/4] xen: Remove unused vsscanf/sscanf functions

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpH-0000TX-TU; Fri, 03 Feb 2012 15:13:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpH-0000T9-2b
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328281996!13604849!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13254 invoked from network); 3 Feb 2012 15:13:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-182.messagelabs.com with SMTP;
	3 Feb 2012 15:13:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDDni011007; Fri, 3 Feb 2012 15:13:13 GMT
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 q13FDD61024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:12:57 -0500
Message-Id: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: keir@xen.org, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 0/4] Update flask_op hypercall interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The FLASK hypercall interface originally attempted to emulate the
read/write interface used by SELinux, passing human-readable strings to
and from the hypervisor. This resulted in unnecessary string parsing and
conversion in the hypervisor and toolstack.

This series (primarily patch #3) converts the hypercall to use a
union-of-structures similar to the other Xen hypercalls. The wrappers in
libxc have been updated to preserve API compatibility where possible.

[PATCH 1/4] tools/flask: remove libflask
[PATCH 2/4] .gitignore/.hgignore: add missing output files
[PATCH 3/4] flask: Update flask_op hypercall structure
[PATCH 4/4] xen: Remove unused vsscanf/sscanf functions

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpJ-0000Tg-AH; Fri, 03 Feb 2012 15:13:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpH-0000TA-Du
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328281996!13324441!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5545 invoked from network); 3 Feb 2012 15:13:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-216.messagelabs.com with SMTP;
	3 Feb 2012 15:13:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDEni011011; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD63024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:12:59 -0500
Message-Id: <1328281981-17399-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/4] .gitignore/.hgignore: add missing output
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 - extras/mini-os/include/list.h (already in .hgignore)
 - tools/flask/flask-{get,set}-bool
 - tools/flask/loadpolicy no longer exists
 - tools/xenstore/init-xenstore-domain

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 .gitignore |    5 ++++-
 .hgignore  |    4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 13d3e94..d1c4e46 100644
--- a/.gitignore
+++ b/.gitignore
@@ -64,6 +64,7 @@ extras/mini-os/include/ia64/mini-os
 extras/mini-os/include/ia64/offsets.h
 extras/mini-os/include/x86/mini-os
 extras/mini-os/include/xen
+extras/mini-os/include/list.h
 extras/mini-os/mini-os*
 install/*
 linux-[^/]*-paravirt/*
@@ -150,10 +151,11 @@ tools/firmware/rombios/rombios[^/]*.s
 tools/firmware/rombios/32bit/32bitbios_flat.h
 tools/firmware/vgabios/vbetables-gen
 tools/firmware/vgabios/vbetables.h
-tools/flask/loadpolicy/flask-loadpolicy
 tools/flask/utils/flask-getenforce
+tools/flask/utils/flask-get-bool
 tools/flask/utils/flask-loadpolicy
 tools/flask/utils/flask-setenforce
+tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
 tools/fs-back/fs-backend
 tools/hotplug/common/hotplugpath.sh
@@ -236,6 +238,7 @@ tools/xenpaging/xenpaging
 tools/xenpmd/xenpmd
 tools/xenstat/xentop/xentop
 tools/xenstore/testsuite/tmp/*
+tools/xenstore/init-xenstore-domain
 tools/xenstore/xen
 tools/xenstore/xenstore
 tools/xenstore/xenstore-chmod
diff --git a/.hgignore b/.hgignore
index 2b5cfe5..f474c42 100644
--- a/.hgignore
+++ b/.hgignore
@@ -154,10 +154,11 @@
 ^tools/firmware/rombios/32bit/32bitbios_flat\.h$
 ^tools/firmware/vgabios/vbetables-gen$
 ^tools/firmware/vgabios/vbetables\.h$
-^tools/flask/loadpolicy/flask-loadpolicy$
 ^tools/flask/utils/flask-getenforce$
+^tools/flask/utils/flask-get-bool$
 ^tools/flask/utils/flask-loadpolicy$
 ^tools/flask/utils/flask-setenforce$
+^tools/flask/utils/flask-set-bool$
 ^tools/flask/utils/flask-label-pci$
 ^tools/fs-back/fs-backend$
 ^tools/hotplug/common/hotplugpath\.sh$
@@ -249,6 +250,7 @@
 ^tools/xenpmd/xenpmd$
 ^tools/xenstat/xentop/xentop$
 ^tools/xenstore/testsuite/tmp/.*$
+^tools/xenstore/init-xenstore-domain$
 ^tools/xenstore/xen$
 ^tools/xenstore/xenstore$
 ^tools/xenstore/xenstore-chmod$
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpJ-0000Tg-AH; Fri, 03 Feb 2012 15:13:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpH-0000TA-Du
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328281996!13324441!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5545 invoked from network); 3 Feb 2012 15:13:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-216.messagelabs.com with SMTP;
	3 Feb 2012 15:13:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDEni011011; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD63024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:12:59 -0500
Message-Id: <1328281981-17399-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/4] .gitignore/.hgignore: add missing output
	files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 - extras/mini-os/include/list.h (already in .hgignore)
 - tools/flask/flask-{get,set}-bool
 - tools/flask/loadpolicy no longer exists
 - tools/xenstore/init-xenstore-domain

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 .gitignore |    5 ++++-
 .hgignore  |    4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 13d3e94..d1c4e46 100644
--- a/.gitignore
+++ b/.gitignore
@@ -64,6 +64,7 @@ extras/mini-os/include/ia64/mini-os
 extras/mini-os/include/ia64/offsets.h
 extras/mini-os/include/x86/mini-os
 extras/mini-os/include/xen
+extras/mini-os/include/list.h
 extras/mini-os/mini-os*
 install/*
 linux-[^/]*-paravirt/*
@@ -150,10 +151,11 @@ tools/firmware/rombios/rombios[^/]*.s
 tools/firmware/rombios/32bit/32bitbios_flat.h
 tools/firmware/vgabios/vbetables-gen
 tools/firmware/vgabios/vbetables.h
-tools/flask/loadpolicy/flask-loadpolicy
 tools/flask/utils/flask-getenforce
+tools/flask/utils/flask-get-bool
 tools/flask/utils/flask-loadpolicy
 tools/flask/utils/flask-setenforce
+tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
 tools/fs-back/fs-backend
 tools/hotplug/common/hotplugpath.sh
@@ -236,6 +238,7 @@ tools/xenpaging/xenpaging
 tools/xenpmd/xenpmd
 tools/xenstat/xentop/xentop
 tools/xenstore/testsuite/tmp/*
+tools/xenstore/init-xenstore-domain
 tools/xenstore/xen
 tools/xenstore/xenstore
 tools/xenstore/xenstore-chmod
diff --git a/.hgignore b/.hgignore
index 2b5cfe5..f474c42 100644
--- a/.hgignore
+++ b/.hgignore
@@ -154,10 +154,11 @@
 ^tools/firmware/rombios/32bit/32bitbios_flat\.h$
 ^tools/firmware/vgabios/vbetables-gen$
 ^tools/firmware/vgabios/vbetables\.h$
-^tools/flask/loadpolicy/flask-loadpolicy$
 ^tools/flask/utils/flask-getenforce$
+^tools/flask/utils/flask-get-bool$
 ^tools/flask/utils/flask-loadpolicy$
 ^tools/flask/utils/flask-setenforce$
+^tools/flask/utils/flask-set-bool$
 ^tools/flask/utils/flask-label-pci$
 ^tools/fs-back/fs-backend$
 ^tools/hotplug/common/hotplugpath\.sh$
@@ -249,6 +250,7 @@
 ^tools/xenpmd/xenpmd$
 ^tools/xenstat/xentop/xentop$
 ^tools/xenstore/testsuite/tmp/.*$
+^tools/xenstore/init-xenstore-domain$
 ^tools/xenstore/xen$
 ^tools/xenstore/xenstore$
 ^tools/xenstore/xenstore-chmod$
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpL-0000U7-Nj; Fri, 03 Feb 2012 15:13:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpJ-0000TC-Sp
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:26 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328281996!11872902!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21901 invoked from network); 3 Feb 2012 15:13:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-174.messagelabs.com with SMTP;
	3 Feb 2012 15:13:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDEni011012; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD64024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:13:00 -0500
Message-Id: <1328281981-17399-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/4] flask: Update flask_op hypercall structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of placing string parsing inside the hypervisor, use binary
structures like other Xen hypercalls do.

This patch also removes libflask; if the old flask_* namespace is needed
for longer backwards compatability (it was noted as deprecated in July
2010), a shim redirecting to the proper xc_flask_* calls can be created.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_flask.c            |  471 +++++++---------
 tools/libxc/xc_private.h          |    2 +
 tools/libxc/xenctrl.h             |    4 +-
 xen/include/public/xsm/flask_op.h |  146 +++++-
 xen/xsm/flask/avc.c               |   13 +-
 xen/xsm/flask/flask_op.c          | 1128 +++++++++++--------------------------
 xen/xsm/flask/include/avc.h       |    3 +-
 xen/xsm/flask/include/security.h  |    4 +-
 xen/xsm/flask/ss/services.c       |   11 +-
 9 files changed, 683 insertions(+), 1099 deletions(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index d268098..80c5a2d 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -30,18 +30,21 @@
 #include <sys/ioctl.h>
 #include <stdint.h>
 
-#define OCON_PIRQ_STR   "pirq"
-#define OCON_IOPORT_STR "ioport"
-#define OCON_IOMEM_STR  "iomem"
-#define OCON_DEVICE_STR "pcidevice"
+#define OCON_ISID    0    /* initial SIDs */
+#define OCON_PIRQ    1    /* physical irqs */
+#define OCON_IOPORT  2    /* io ports */
+#define OCON_IOMEM   3    /* io memory */
+#define OCON_DEVICE  4    /* pci devices */
 #define INITCONTEXTLEN  256
 
-int xc_flask_op(xc_interface *xch, flask_op_t *op)
+int xc_flask_op(xc_interface *xch, xen_flask_op_t *op)
 {
     int ret = -1;
     DECLARE_HYPERCALL;
     DECLARE_HYPERCALL_BOUNCE(op, sizeof(*op), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
 
+    op->interface_version = XEN_FLASK_INTERFACE_VERSION;
+
     if ( xc_hypercall_bounce_pre(xch, op) )
     {
         PERROR("Could not bounce memory for flask op hypercall");
@@ -63,402 +66,360 @@ int xc_flask_op(xc_interface *xch, flask_op_t *op)
     return ret;
 }
 
-int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size)
+int xc_flask_load(xc_interface *xch, char *buf, uint32_t size)
 {
     int err;
-    flask_op_t op;
-    
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(buf, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    if ( xc_hypercall_bounce_pre(xch, buf) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
+
     op.cmd = FLASK_LOAD;
-    op.buf = buf;
-    op.size = size;
+    op.u.load.size = size;
+    set_xen_guest_handle(op.u.load.buffer, buf);
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
+    err = xc_flask_op(xch, &op);
 
-    return 0;
+    xc_hypercall_bounce_post(xch, buf);
+
+    return err;
 }
 
-int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid)
+int xc_flask_context_to_sid(xc_interface *xch, char *buf, uint32_t size, uint32_t *sid)
 {
     int err;
-    flask_op_t op;
-    
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(buf, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+    if ( xc_hypercall_bounce_pre(xch, buf) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
+
     op.cmd = FLASK_CONTEXT_TO_SID;
-    op.buf = buf;
-    op.size = size;
+    op.u.sid_context.size = size;
+    set_xen_guest_handle(op.u.sid_context.context, buf);
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-    
-    sscanf(buf, "%u", sid);
+    err = xc_flask_op(xch, &op);
 
-    return 0;
+    if ( !err )
+        *sid = op.u.sid_context.sid;
+
+    xc_hypercall_bounce_post(xch, buf);
+
+    return err;
 }
 
-int xc_flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size)
+int xc_flask_sid_to_context(xc_interface *xch, int sid, char *buf, uint32_t size)
 {
     int err;
-    flask_op_t op;
-    
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(buf, size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, buf) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
+
     op.cmd = FLASK_SID_TO_CONTEXT;
-    op.buf = buf;
-    op.size = size;
+    op.u.sid_context.sid = sid;
+    op.u.sid_context.size = size;
+    set_xen_guest_handle(op.u.sid_context.context, buf);
     
-    snprintf(buf, size, "%u", sid);
+    err = xc_flask_op(xch, &op);
 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
+    xc_hypercall_bounce_post(xch, buf);
+   
+    return err;
 }
 
-int xc_flask_getenforce(xc_interface *xc_handle)
+int xc_flask_getenforce(xc_interface *xch)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int mode;
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_GETENFORCE;
-    op.buf = buf;
-    op.size = size;
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &mode);
-
-    return mode;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_setenforce(xc_interface *xc_handle, int mode)
+int xc_flask_setenforce(xc_interface *xch, int mode)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];
-    int size = 20; 
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_SETENFORCE;
-    op.buf = buf;
-    op.size = size;
+    op.u.enforce.enforcing = mode;
    
-    snprintf(buf, size, "%i", mode);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_getbool_byid(xc_interface *xc_handle, int id, char *name, uint32_t size, int *curr, int *pend)
+int xc_flask_getbool_byid(xc_interface *xch, int id, char *name, uint32_t size, int *curr, int *pend)
 {
-    flask_op_t op;
-    char buf[255];
     int rv;
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(name, size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, name) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
 
-    op.cmd = FLASK_GETBOOL2;
-    op.buf = buf;
-    op.size = 255;
+    op.cmd = FLASK_GETBOOL;
+    op.u.boolean.bool_id = id;
+    op.u.boolean.size = size;
+    set_xen_guest_handle(op.u.boolean.name, name);
 
-    snprintf(buf, sizeof buf, "%i", id);
+    rv = xc_flask_op(xch, &op);
 
-    rv = xc_flask_op(xc_handle, &op);
+    xc_hypercall_bounce_post(xch, name);
 
     if ( rv )
         return rv;
     
-    sscanf(buf, "%i %i %s", curr, pend, name);
+    if ( curr )
+        *curr = op.u.boolean.enforcing;
+    if ( pend )
+        *pend = op.u.boolean.pending;
 
     return rv;
 }
 
-int xc_flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
+int xc_flask_getbool_byname(xc_interface *xch, char *name, int *curr, int *pend)
 {
-    flask_op_t op;
-    char buf[255];
     int rv;
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(name, strlen(name), XC_HYPERCALL_BUFFER_BOUNCE_IN);
 
-    op.cmd = FLASK_GETBOOL_NAMED;
-    op.buf = buf;
-    op.size = 255;
+    op.cmd = FLASK_GETBOOL;
+    op.u.boolean.bool_id = -1;
+    op.u.boolean.size = strlen(name);
+    set_xen_guest_handle(op.u.boolean.name, name);
 
-    strncpy(buf, name, op.size);
+    rv = xc_flask_op(xch, &op);
 
-    rv = xc_flask_op(xc_handle, &op);
+    xc_hypercall_bounce_post(xch, name);
 
     if ( rv )
         return rv;
     
-    sscanf(buf, "%i %i", curr, pend);
+    if ( curr )
+        *curr = op.u.boolean.enforcing;
+    if ( pend )
+        *pend = op.u.boolean.pending;
 
     return rv;
 }
 
-int xc_flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
+int xc_flask_setbool(xc_interface *xch, char *name, int value, int commit)
 {
-    flask_op_t op;
-    char buf[255];
-    int size = 255;
+    int rv;
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(name, strlen(name), XC_HYPERCALL_BUFFER_BOUNCE_IN);
 
-    op.cmd = FLASK_SETBOOL_NAMED;
-    op.buf = buf;
-    op.size = size;
+    op.cmd = FLASK_SETBOOL;
+    op.u.boolean.bool_id = -1;
+    op.u.boolean.new_value = value;
+    op.u.boolean.commit = 1;
+    op.u.boolean.size = strlen(name);
+    set_xen_guest_handle(op.u.boolean.name, name);
 
-    snprintf(buf, size, "%s %i %i", name, value, commit);
+    rv = xc_flask_op(xch, &op);
 
-    return xc_flask_op(xc_handle, &op);
+    xc_hypercall_bounce_post(xch, name);
+
+    return rv;
 }
 
-static int xc_flask_add(xc_interface *xc_handle, char *cat, char *arg, char *scontext)
+
+static int xc_flask_add(xc_interface *xch, uint32_t ocon, uint64_t low, uint64_t high, char *scontext)
 {
-    char buf[512];
-    flask_op_t op;
+    uint32_t sid;
+    int err;
+    DECLARE_FLASK_OP;
+
+    err = xc_flask_context_to_sid(xch, scontext, strlen(scontext), &sid);
+    if ( err )
+        return err;
 
-    memset(buf, 0, 512);
-    snprintf(buf, 512, "%s %255s %s", cat, scontext, arg);
     op.cmd = FLASK_ADD_OCONTEXT;
-    op.buf = buf;
-    op.size = 512;
+    op.u.ocontext.ocon = ocon;
+    op.u.ocontext.sid = sid;
+    op.u.ocontext.low = low;
+    op.u.ocontext.high = high;
     
-    return xc_flask_op(xc_handle, &op);
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext)
+int xc_flask_add_pirq(xc_interface *xch, unsigned int pirq, char *scontext)
 {
-    char arg[16];
-
-    snprintf(arg, 16, "%u", pirq);
-    return xc_flask_add(xc_handle, OCON_PIRQ_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_PIRQ, pirq, pirq, scontext);
 }
 
-int xc_flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
+int xc_flask_add_ioport(xc_interface *xch, unsigned long low, unsigned long high,
                       char *scontext)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_add(xc_handle, OCON_IOPORT_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_IOPORT, low, high, scontext);
 }
 
-int xc_flask_add_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high,
+int xc_flask_add_iomem(xc_interface *xch, unsigned long low, unsigned long high,
                      char *scontext)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_add(xc_handle, OCON_IOMEM_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_IOMEM, low, high, scontext);
 }
 
-int xc_flask_add_device(xc_interface *xc_handle, unsigned long device, char *scontext)
+int xc_flask_add_device(xc_interface *xch, unsigned long device, char *scontext)
 {
-    char arg[32];
-
-    snprintf(arg, 32, "%lu", device);
-    return xc_flask_add(xc_handle, OCON_DEVICE_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_DEVICE, device, device, scontext);
 }
 
-static int xc_flask_del(xc_interface *xc_handle, char *cat, char *arg)
+static int xc_flask_del(xc_interface *xch, uint32_t ocon, uint64_t low, uint64_t high)
 {
-    char buf[256];
-    flask_op_t op;
+    DECLARE_FLASK_OP;
 
-    memset(buf, 0, 256);
-    snprintf(buf, 256, "%s %s", cat, arg);
     op.cmd = FLASK_DEL_OCONTEXT;
-    op.buf = buf;
-    op.size = 256;
+    op.u.ocontext.ocon = ocon;
+    op.u.ocontext.low = low;
+    op.u.ocontext.high = high;
     
-    return xc_flask_op(xc_handle, &op);
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_del_pirq(xc_interface *xc_handle, unsigned int pirq)
+int xc_flask_del_pirq(xc_interface *xch, unsigned int pirq)
 {
-    char arg[16];
-
-    snprintf(arg, 16, "%u", pirq);
-    return xc_flask_del(xc_handle, OCON_PIRQ_STR, arg);
+    return xc_flask_del(xch, OCON_PIRQ, pirq, pirq);
 }
 
-int xc_flask_del_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high)
+int xc_flask_del_ioport(xc_interface *xch, unsigned long low, unsigned long high)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_del(xc_handle, OCON_IOPORT_STR, arg);
+    return xc_flask_del(xch, OCON_IOPORT, low, high);
 }
 
-int xc_flask_del_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high)
+int xc_flask_del_iomem(xc_interface *xch, unsigned long low, unsigned long high)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_del(xc_handle, OCON_IOMEM_STR, arg);
+    return xc_flask_del(xch, OCON_IOMEM, low, high);
 }
 
-int xc_flask_del_device(xc_interface *xc_handle, unsigned long device)
+int xc_flask_del_device(xc_interface *xch, unsigned long device)
 {
-    char arg[32];
-
-    snprintf(arg, 32, "%lu", device);
-    return xc_flask_del(xc_handle, OCON_DEVICE_STR, arg);
+    return xc_flask_del(xch, OCON_DEVICE, device, device);
 }
 
-int xc_flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
+int xc_flask_access(xc_interface *xch, const char *scon, const char *tcon,
                 uint16_t tclass, uint32_t req,
                 uint32_t *allowed, uint32_t *decided,
                 uint32_t *auditallow, uint32_t *auditdeny,
                 uint32_t *seqno)
 {
-/* maximum number of digits in a 16-bit decimal number: */
-#define MAX_SHORT_DEC_LEN 5
-
-    char *buf;
-    int bufLen;
+    DECLARE_FLASK_OP;
     int err;
-    flask_op_t op;
-    uint32_t dummy_allowed;
-    uint32_t dummy_decided;
-    uint32_t dummy_auditallow;
-    uint32_t dummy_auditdeny;
-    uint32_t dummy_seqno;
-  
-    if (!allowed)
-        allowed = &dummy_allowed;
-    if (!decided)
-        decided = &dummy_decided;
-    if (!auditallow)
-        auditallow = &dummy_auditallow;
-    if (!auditdeny)
-        auditdeny = &dummy_auditdeny;
-    if (!seqno)
-        seqno = &dummy_seqno;
-
-    if (!scon)
-        return -EINVAL;
-    if (!tcon)
-        return -EINVAL;
-
-    bufLen = strlen(scon) + 1 + strlen(tcon) + 1 +
-        MAX_SHORT_DEC_LEN + 1 +
-        sizeof(req)*2 + 1;
-    buf = malloc(bufLen);
-    snprintf(buf, bufLen, "%s %s %hu %x", scon, tcon, tclass, req);
+
+    err = xc_flask_context_to_sid(xch, (char*)scon, strlen(scon), &op.u.access.ssid);
+    if ( err )
+        return err;
+    err = xc_flask_context_to_sid(xch, (char*)tcon, strlen(tcon), &op.u.access.tsid);
+    if ( err )
+        return err;
 
     op.cmd = FLASK_ACCESS;
-    op.buf = buf;
-    op.size = strlen(buf)+1;
+    op.u.access.tclass = tclass;
+    op.u.access.req = req;
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
+    err = xc_flask_op(xch, &op);
+
+    if ( err )
         return err;
-    }
-   
-    if (sscanf(op.buf, "%x %x %x %x %u",
-               allowed, decided,
-               auditallow, auditdeny,
-               seqno) != 5) {
-        err = -EILSEQ;
-    }
 
-    err = ((*allowed & req) == req)? 0 : -EPERM;
+    if ( allowed )
+        *allowed = op.u.access.allowed;
+    if ( decided )
+        *decided = 0xffffffff;
+    if ( auditallow )
+        *auditallow = op.u.access.audit_allow;
+    if ( auditdeny )
+        *auditdeny = op.u.access.audit_deny;
+    if ( seqno )
+        *seqno = op.u.access.seqno;
 
-    return err;
+    if ( (op.u.access.allowed & req) != req )
+        err = -EPERM;
 
+    return err;
 }
 
-int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size)
+int xc_flask_avc_hashstats(xc_interface *xch, char *buf, int size)
 {
     int err;
-    flask_op_t op;
+    DECLARE_FLASK_OP;
   
     op.cmd = FLASK_AVC_HASHSTATS;
-    op.buf = buf;
-    op.size = size;
   
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
+    err = xc_flask_op(xch, &op);
 
-    return 0;
+    snprintf(buf, size,
+             "entries: %d\nbuckets used: %d/%d\nlongest chain: %d\n",
+             op.u.hash_stats.entries, op.u.hash_stats.buckets_used,
+             op.u.hash_stats.buckets_total, op.u.hash_stats.max_chain_len);
+
+    return err;
 }
 
-int xc_flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size)
+int xc_flask_avc_cachestats(xc_interface *xch, char *buf, int size)
 {
-    int err;
-    flask_op_t op;
+    int err, n;
+    int i = 0;
+    DECLARE_FLASK_OP;
+
+    n = snprintf(buf, size, "lookups hits misses allocations reclaims frees\n");
+    buf += n;
+    size -= n;
   
     op.cmd = FLASK_AVC_CACHESTATS;
-    op.buf = buf;
-    op.size = size;
-  
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
+    while ( size > 0 )
     {
-        free(buf);
-        return err;
+        op.u.cache_stats.cpu = i;
+        err = xc_flask_op(xch, &op);
+        if ( err && errno == ENOENT )
+            return 0;
+        if ( err )
+            return err;
+        n = snprintf(buf, size, "%u %u %u %u %u %u\n",
+                     op.u.cache_stats.lookups, op.u.cache_stats.hits,
+                     op.u.cache_stats.misses, op.u.cache_stats.allocations,
+                     op.u.cache_stats.reclaims, op.u.cache_stats.frees);
+        buf += n;
+        size -= n;
+        i++;
     }
 
     return 0;
 }
 
-int xc_flask_policyvers(xc_interface *xc_handle, char *buf, int size)
+int xc_flask_policyvers(xc_interface *xch)
 {
-    int err;
-    flask_op_t op;
-  
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_POLICYVERS;
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
 
-    return 0;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_getavc_threshold(xc_interface *xc_handle)
+int xc_flask_getavc_threshold(xc_interface *xch)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int threshold;
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_GETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &threshold);
-
-    return threshold;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold)
+int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_SETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
+    op.u.setavc_threshold.threshold = threshold;
 
-    snprintf(buf, size, "%i", threshold);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
+    return xc_flask_op(xch, &op);
 }
 
 /*
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 3687561..7b83ef3 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -42,11 +42,13 @@
 #define DECLARE_DOMCTL struct xen_domctl domctl = { 0 }
 #define DECLARE_SYSCTL struct xen_sysctl sysctl = { 0 }
 #define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = { 0 }
+#define DECLARE_FLASK_OP struct xen_flask_op op = { 0 }
 #else
 #define DECLARE_HYPERCALL privcmd_hypercall_t hypercall
 #define DECLARE_DOMCTL struct xen_domctl domctl
 #define DECLARE_SYSCTL struct xen_sysctl sysctl
 #define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
+#define DECLARE_FLASK_OP struct xen_flask_op op
 #endif
 
 #undef PAGE_SHIFT
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 1e7c32b..6b3202e 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1328,7 +1328,7 @@ int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl);
 
 int xc_version(xc_interface *xch, int cmd, void *arg);
 
-int xc_flask_op(xc_interface *xch, flask_op_t *op);
+int xc_flask_op(xc_interface *xch, xen_flask_op_t *op);
 
 /*
  * Subscribe to state changes in a domain via evtchn.
@@ -1976,7 +1976,7 @@ int xc_flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
                   uint32_t *auditallow, uint32_t *auditdeny,
                   uint32_t *seqno);
 int xc_flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size);
-int xc_flask_policyvers(xc_interface *xc_handle, char *buf, int size);
+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);
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 416ac08..83dcd99 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -25,6 +25,118 @@
 #ifndef __FLASK_OP_H__
 #define __FLASK_OP_H__
 
+#define XEN_FLASK_INTERFACE_VERSION 1
+
+struct xen_flask_load {
+    XEN_GUEST_HANDLE(char) buffer;
+    uint32_t size;
+};
+
+struct xen_flask_setenforce {
+    uint32_t enforcing;
+};
+
+struct xen_flask_sid_context {
+    /* IN/OUT: sid to convert to/from string */
+    uint32_t sid;
+    /* IN: size of the context buffer
+     * OUT: actual size of the output context string
+     */
+    uint32_t size;
+    XEN_GUEST_HANDLE(char) context;
+};
+
+struct xen_flask_access {
+    /* IN: access request */
+    uint32_t ssid;
+    uint32_t tsid;
+    uint32_t tclass;
+    uint32_t req;
+    /* OUT: AVC data */
+    uint32_t allowed;
+    uint32_t audit_allow;
+    uint32_t audit_deny;
+    uint32_t seqno;
+};
+
+struct xen_flask_transition {
+    /* IN: transition SIDs and class */
+    uint32_t ssid;
+    uint32_t tsid;
+    uint32_t tclass;
+    /* OUT: new SID */
+    uint32_t newsid;
+};
+
+struct xen_flask_userlist {
+    /* IN: starting SID for list */
+    uint32_t start_sid;
+    /* IN: size of user string and output buffer
+     * OUT: number of SIDs returned */
+    uint32_t size;
+    union {
+        /* IN: user to enumerate SIDs */
+        XEN_GUEST_HANDLE(char) user;
+        /* OUT: SID list */
+        XEN_GUEST_HANDLE(uint32) sids;
+    } u;
+};
+
+struct xen_flask_boolean {
+    /* IN/OUT: numeric identifier for boolean [GET/SET]
+     * If -1, name will be used and bool_id will be filled in. */
+    uint32_t bool_id;
+    /* OUT: current enforcing value of boolean [GET/SET] */
+    uint8_t enforcing;
+    /* OUT: pending value of boolean [GET/SET] */
+    uint8_t pending;
+    /* IN: new value of boolean [SET] */
+    uint8_t new_value;
+    /* IN: commit new value instead of only setting pending [SET] */
+    uint8_t commit;
+    /* IN: size of boolean name buffer [GET/SET]
+     * OUT: actual size of name [GET only] */
+    uint32_t size;
+    /* IN: if bool_id is -1, used to find boolean [GET/SET]
+     * OUT: textual name of boolean [GET only]
+     */
+    XEN_GUEST_HANDLE(char) name;
+};
+
+struct xen_flask_setavc_threshold {
+    /* IN */
+    uint32_t threshold;
+};
+
+struct xen_flask_hash_stats {
+    /* OUT */
+    uint32_t entries;
+    uint32_t buckets_used;
+    uint32_t buckets_total;
+    uint32_t max_chain_len;
+};
+
+struct xen_flask_cache_stats {
+    /* IN */
+    uint32_t cpu;
+    /* OUT */
+    uint32_t lookups;
+    uint32_t hits;
+    uint32_t misses;
+    uint32_t allocations;
+    uint32_t reclaims;
+    uint32_t frees;
+};
+
+struct xen_flask_ocontext {
+    /* IN */
+    uint32_t ocon;
+    uint32_t sid;
+    uint64_t low, high;
+};
+
+struct xen_flask_op {
+    uint32_t cmd;
 #define FLASK_LOAD              1
 #define FLASK_GETENFORCE        2
 #define FLASK_SETENFORCE        3
@@ -47,18 +159,26 @@
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
-#define FLASK_GETBOOL_NAMED     23
-#define FLASK_GETBOOL2          24
-#define FLASK_SETBOOL_NAMED     25
-
-#define FLASK_LAST              FLASK_SETBOOL_NAMED
-
-typedef struct flask_op {
-    uint32_t  cmd;
-    uint32_t  size;
-    char      *buf;
-} flask_op_t;
-
-DEFINE_XEN_GUEST_HANDLE(flask_op_t);
+    uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
+    union {
+        struct xen_flask_load load;
+        struct xen_flask_setenforce enforce;
+        /* FLASK_CONTEXT_TO_SID and FLASK_SID_TO_CONTEXT */
+        struct xen_flask_sid_context sid_context;
+        struct xen_flask_access access;
+        /* FLASK_CREATE, FLASK_RELABEL, FLASK_MEMBER */
+        struct xen_flask_transition transition;
+        struct xen_flask_userlist userlist;
+        /* FLASK_GETBOOL, FLASK_SETBOOL */
+        struct xen_flask_boolean boolean;
+        struct xen_flask_setavc_threshold setavc_threshold;
+        struct xen_flask_hash_stats hash_stats;
+        struct xen_flask_cache_stats cache_stats;
+        /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
+        struct xen_flask_ocontext ocontext;
+    } u;
+};
+typedef struct xen_flask_op xen_flask_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_flask_op_t);
 
 #endif
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 3a60a3a..74f160d 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -28,6 +28,7 @@
 #include <xen/rcupdate.h>
 #include <asm/atomic.h>
 #include <asm/current.h>
+#include <public/xsm/flask_op.h>
 
 #include "avc.h"
 #include "avc_ss.h"
@@ -251,7 +252,7 @@ void __init avc_init(void)
     printk("AVC INITIALIZED\n");
 }
 
-int avc_get_hash_stats(char *buf, uint32_t size)
+int avc_get_hash_stats(struct xen_flask_hash_stats *arg)
 {
     int i, chain_len, max_chain_len, slots_used;
     struct avc_node *node;
@@ -279,10 +280,12 @@ int avc_get_hash_stats(char *buf, uint32_t size)
 
     rcu_read_unlock(&avc_rcu_lock);
     
-    return snprintf(buf, size, "entries: %d\nbuckets used: %d/%d\n"
-                    "longest chain: %d\n",
-                    atomic_read(&avc_cache.active_nodes),
-                    slots_used, AVC_CACHE_SLOTS, max_chain_len);
+    arg->entries = atomic_read(&avc_cache.active_nodes);
+    arg->buckets_used = slots_used;
+    arg->buckets_total = AVC_CACHE_SLOTS;
+    arg->max_chain_len = max_chain_len;
+
+    return 0;
 }
 
 static void avc_node_free(struct rcu_head *rhead)
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 64d9ec5..00a0af2 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -30,48 +30,21 @@ integer_param("flask_enabled", flask_enabled);
 #endif
 
 #define MAX_POLICY_SIZE 0x4000000
-#define FLASK_COPY_IN \
-    ( \
-        1UL<<FLASK_LOAD | \
-        1UL<<FLASK_SETENFORCE | \
-        1UL<<FLASK_CONTEXT_TO_SID | \
-        1UL<<FLASK_SID_TO_CONTEXT | \
-        1UL<<FLASK_ACCESS | \
-        1UL<<FLASK_CREATE | \
-        1UL<<FLASK_RELABEL | \
-        1UL<<FLASK_USER | \
-        1UL<<FLASK_GETBOOL | \
-        1UL<<FLASK_SETBOOL | \
-        1UL<<FLASK_COMMITBOOLS | \
-        1UL<<FLASK_DISABLE | \
-        1UL<<FLASK_SETAVC_THRESHOLD | \
-        1UL<<FLASK_MEMBER | \
-        1UL<<FLASK_ADD_OCONTEXT | \
-        1UL<<FLASK_DEL_OCONTEXT | \
-        1UL<<FLASK_GETBOOL_NAMED | \
-        1UL<<FLASK_GETBOOL2 | \
-        1UL<<FLASK_SETBOOL_NAMED \
-    )
 
 #define FLASK_COPY_OUT \
     ( \
-        1UL<<FLASK_GETENFORCE | \
         1UL<<FLASK_CONTEXT_TO_SID | \
         1UL<<FLASK_SID_TO_CONTEXT | \
         1UL<<FLASK_ACCESS | \
         1UL<<FLASK_CREATE | \
         1UL<<FLASK_RELABEL | \
         1UL<<FLASK_USER | \
-        1UL<<FLASK_POLICYVERS | \
         1UL<<FLASK_GETBOOL | \
-        1UL<<FLASK_MLS | \
-        1UL<<FLASK_GETAVC_THRESHOLD | \
+        1UL<<FLASK_SETBOOL | \
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
         1UL<<FLASK_MEMBER | \
-        1UL<<FLASK_GETBOOL_NAMED | \
-        1UL<<FLASK_GETBOOL2 \
-    )
+   0)
 
 static DEFINE_SPINLOCK(sel_sem);
 
@@ -96,412 +69,186 @@ static int domain_has_security(struct domain *d, u32 perms)
                         perms, NULL);
 }
 
-static int flask_security_user(char *buf, uint32_t size)
-{
-    char *page = NULL;
-    char *con, *user, *ptr;
-    u32 sid, *sids;
-    int length;
-    char *newcon;
-    int i, rc;
-    u32 len, nsids;
-        
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_USER);
-    if ( length )
-        return length;
-            
-    length = -ENOMEM;
-    con = xmalloc_array(char, size+1);
-    if ( !con )
-        return length;
-    memset(con, 0, size+1);
-    
-    user = xmalloc_array(char, size+1);
-    if ( !user )
-        goto out;
-    memset(user, 0, size+1);
-    
-    length = -ENOMEM;
-    page = xmalloc_bytes(PAGE_SIZE);
-    if ( !page )
-        goto out2;
-    memset(page, 0, PAGE_SIZE);
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%s %s", con, user) != 2 )
-        goto out2;
-
-    length = security_context_to_sid(con, strlen(con)+1, &sid);
-    if ( length < 0 )
-        goto out2;
-            
-    length = security_get_user_sids(sid, user, &sids, &nsids);
-    if ( length < 0 )
-        goto out2;
-    
-    length = snprintf(page, PAGE_SIZE, "%u", nsids) + 1;
-    ptr = page + length;
-    for ( i = 0; i < nsids; i++ )
-    {
-        rc = security_sid_to_context(sids[i], &newcon, &len);
-        if ( rc )
-        {
-            length = rc;
-            goto out3;
-        }
-        if ( (length + len) >= PAGE_SIZE )
-        {
-            xfree(newcon);
-            length = -ERANGE;
-            goto out3;
-        }
-        memcpy(ptr, newcon, len);
-        xfree(newcon);
-        ptr += len;
-        length += len;
-    }
-    
-    if ( length > size )
-    {
-        printk( "%s:  context size (%u) exceeds payload "
-                "max\n", __FUNCTION__, length);
-        length = -ERANGE;
-        goto out3;
-    }
-
-    memset(buf, 0, size);
-    memcpy(buf, page, length);
-        
- out3:
-    xfree(sids);
- out2:
-    if ( page )
-        xfree(page);
-    xfree(user);
- out:
-    xfree(con);
-    return length;
-}
-
-static int flask_security_relabel(char *buf, uint32_t size)
+static int flask_copyin_string(XEN_GUEST_HANDLE(char) u_buf, char **buf, uint32_t size)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid, newsid;
-    u16 tclass;
-    int length;
-    char *newcon;
-    u32 len;
+    char *tmp = xmalloc_bytes(size + 1);
+    if ( !tmp )
+        return -ENOMEM;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_RELABEL);
-    if ( length )
-        return length;
-            
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if ( !scon )
-        return length;
-    memset(scon, 0, size+1);
-        
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
-        goto out;
-    memset(tcon, 0, size+1);
-        
-    length = -EINVAL;
-    if ( sscanf(buf, "%s %s %hu", scon, tcon, &tclass) != 3 )
-        goto out2;
-            
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
-            
-    length = security_change_sid(ssid, tsid, tclass, &newsid);
-    if ( length < 0 )
-        goto out2;
-            
-    length = security_sid_to_context(newsid, &newcon, &len);
-    if ( length < 0 )
-        goto out2;
-            
-    if ( len > size )
+    if ( copy_from_guest(tmp, u_buf, size) )
     {
-        printk( "%s:  context size (%u) exceeds payload "
-                "max\n", __FUNCTION__, len);
-        length = -ERANGE;
-        goto out3;
+        xfree(tmp);
+        return -EFAULT;
     }
+    tmp[size] = 0;
 
-    memset(buf, 0, size);
-    memcpy(buf, newcon, len);
-    length = len;
-
- out3:
-    xfree(newcon);
- out2:
-    xfree(tcon);
- out:
-    xfree(scon);
-    return length;
+    *buf = tmp;
+    return 0;
 }
 
-static int flask_security_create(char *buf, uint32_t size)
+static int flask_security_user(struct xen_flask_userlist *arg)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid, newsid;
-    u16 tclass;
-    int length;
-    char *newcon;
-    u32 len;
+    char *user;
+    u32 *sids;
+    u32 nsids;
+    int rv;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_CREATE);
-    if ( length )
-        return length;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_USER);
+    if ( rv )
+        return rv;
 
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if ( !scon )
-        return length;
-    memset(scon, 0, size+1);
+    rv = flask_copyin_string(arg->u.user, &user, arg->size);
+    if ( rv )
+        return rv;
 
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
+    rv = security_get_user_sids(arg->start_sid, user, &sids, &nsids);
+    if ( rv < 0 )
         goto out;
-    memset(tcon, 0, size+1);
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%s %s %hu", scon, tcon, &tclass) != 3 )
-        goto out2;
-
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
 
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
+    if ( nsids * sizeof(sids[0]) > arg->size )
+        nsids = arg->size / sizeof(sids[0]);
 
-    length = security_transition_sid(ssid, tsid, tclass, &newsid);
-    if ( length < 0 )
-        goto out2;
+    arg->size = nsids;
 
-    length = security_sid_to_context(newsid, &newcon, &len);
-    if ( length < 0 )    
-        goto out2;
-
-    if ( len > size )
-    {
-        printk( "%s:  context size (%u) exceeds payload "
-                "max\n", __FUNCTION__, len);
-        length = -ERANGE;
-        goto out3;
-    }
+    if ( copy_to_guest(arg->u.sids, sids, nsids) )
+        rv = -EFAULT;
 
-    memset(buf, 0, size);
-    memcpy(buf, newcon, len);
-    length = len;
-        
- out3:
-    xfree(newcon);
- out2:
-    xfree(tcon);
+    xfree(sids);
  out:
-    xfree(scon);
-    return length;
+    xfree(user);
+    return rv;
 }
 
-static int flask_security_access(char *buf, uint32_t size)
+static int flask_security_relabel(struct xen_flask_transition *arg)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid;
-    u16 tclass;
-    u32 req;
-    struct av_decision avd;
-    int length;
+    int rv;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_AV);
-    if ( length )
-        return length;
-
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if (!scon)
-        return length;
-    memset(scon, 0, size+1);
-
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
-        goto out;
-    memset( tcon, 0, size+1 );
-
-    length = -EINVAL;
-    if (sscanf(buf, "%s %s %hu %x", scon, tcon, &tclass, &req) != 4)
-        goto out2;
-
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
-
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_RELABEL);
+    if ( rv )
+        return rv;
 
-    length = security_compute_av(ssid, tsid, tclass, req, &avd);
-    if ( length < 0 )
-        goto out2;
+    rv = security_change_sid(arg->ssid, arg->tsid, arg->tclass, &arg->newsid);
 
-    memset(buf, 0, size);
-    length = snprintf(buf, size, "%x %x %x %x %u", 
-                      avd.allowed, 0xffffffff,
-                      avd.auditallow, avd.auditdeny, 
-                      avd.seqno);
-                
- out2:
-    xfree(tcon);
- out:
-    xfree(scon);
-    return length;
+    return rv;
 }
 
-static int flask_security_member(char *buf, uint32_t size)
+static int flask_security_create(struct xen_flask_transition *arg)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid, newsid;
-    u16 tclass;
-    int length;
-    char *newcon;
-    u32 len;
+    int rv;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_MEMBER);
-    if ( length )
-        return length;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_CREATE);
+    if ( rv )
+        return rv;
 
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if ( !scon )
-        return length;
-    memset(scon, 0, size+1);
+    rv = security_transition_sid(arg->ssid, arg->tsid, arg->tclass, &arg->newsid);
 
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
-        goto out;
-    memset(tcon, 0, size+1);
+    return rv;
+}
 
-    length = -EINVAL;
-    if ( sscanf(buf, "%s, %s, %hu", scon, tcon, &tclass) != 3 )
-        goto out2;
+static int flask_security_access(struct xen_flask_access *arg)
+{
+    struct av_decision avd;
+    int rv;
 
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_AV);
+    if ( rv )
+        return rv;
 
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
+    rv = security_compute_av(arg->ssid, arg->tsid, arg->tclass, arg->req, &avd);
+    if ( rv < 0 )
+        return rv;
 
-    length = security_member_sid(ssid, tsid, tclass, &newsid);
-    if ( length < 0 )
-        goto out2;
+    arg->allowed = avd.allowed;
+    arg->audit_allow = avd.auditallow;
+    arg->audit_deny = avd.auditdeny;
+    arg->seqno = avd.seqno;
+                
+    return rv;
+}
 
-    length = security_sid_to_context(newsid, &newcon, &len);
-    if ( length < 0 )
-        goto out2;
+static int flask_security_member(struct xen_flask_transition *arg)
+{
+    int rv;
 
-    if ( len > size )
-    {
-        printk("%s:  context size (%u) exceeds payload "
-               "max\n", __FUNCTION__, len);
-        length = -ERANGE;
-        goto out3;
-    }
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_MEMBER);
+    if ( rv )
+        return rv;
 
-    memset(buf, 0, size);
-    memcpy(buf, newcon, len);
-    length = len;
+    rv = security_member_sid(arg->ssid, arg->tsid, arg->tclass, &arg->newsid);
 
- out3:
-    xfree(newcon);
- out2:
-    xfree(tcon);
- out:
-    xfree(scon);
-    return length;
+    return rv;
 }
 
-static int flask_security_setenforce(char *buf, uint32_t count)
+static int flask_security_setenforce(struct xen_flask_setenforce *arg)
 {
-    int length;
-    int new_value;
+    int enforce = !!(arg->enforcing);
+    int rv;
 
-    if ( sscanf(buf, "%d", &new_value) != 1 )
-        return -EINVAL;
+    if ( enforce == flask_enforcing )
+        return 0;
 
-    if ( new_value != flask_enforcing )
-    {
-        length = domain_has_security(current->domain, SECURITY__SETENFORCE);
-        if ( length )
-            goto out;
-        flask_enforcing = new_value;
-        if ( flask_enforcing )
-            avc_ss_reset(0);
-    }
-    length = count;
+    rv = domain_has_security(current->domain, SECURITY__SETENFORCE);
+    if ( rv )
+        return rv;
 
- out:
-    return length;
+    flask_enforcing = enforce;
+
+    if ( flask_enforcing )
+        avc_ss_reset(0);
+
+    return 0;
 }
 
-static int flask_security_context(char *buf, uint32_t count)
+static int flask_security_context(struct xen_flask_sid_context *arg)
 {
-    u32 sid;
-    int length;
+    int rv;
+    char *buf;
 
-    length = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
-    if ( length )
-        goto out;
+    rv = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
+    if ( rv )
+        return rv;
 
-    length = security_context_to_sid(buf, count, &sid);
-    if ( length < 0 )
-        goto out;
+    rv = flask_copyin_string(arg->context, &buf, arg->size);
+    if ( rv )
+        return rv;
 
-    memset(buf, 0, count);
-    length = snprintf(buf, count, "%u", sid);
+    rv = security_context_to_sid(buf, arg->size, &arg->sid);
+    if ( rv < 0 )
+        goto out;
 
  out:
-    return length;
+    xfree(buf);
+
+    return rv;
 }
 
-static int flask_security_sid(char *buf, uint32_t count)
+static int flask_security_sid(struct xen_flask_sid_context *arg)
 {
+    int rv;
     char *context;
-    u32 sid;
     u32 len;
-    int length;
 
-    length = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
-    if ( length )
-        goto out;
+    rv = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
+    if ( rv )
+        return rv;
 
-    if ( sscanf(buf, "%u", &sid) != 1 )
-        goto out;
+    rv = security_sid_to_context(arg->sid, &context, &len);
+    if ( rv < 0 )
+        return rv;
 
-    length = security_sid_to_context(sid, &context, &len);
-    if ( length < 0 )
-        goto out;
+    rv = 0;
 
-    if ( len > count )
-        return -ERANGE; 
+    if ( len > arg->size )
+        rv = -ERANGE;
 
-    memset(buf, 0, count);
-    memcpy(buf, context, len);
-    length = len;
+    arg->size = len;
+
+    if ( !rv && copy_to_guest(arg->context, context, len) )
+        rv = -EFAULT;
 
     xfree(context);
 
- out:
-    return length;
+    return rv;
 }
 
 int flask_disable(void)
@@ -530,229 +277,154 @@ int flask_disable(void)
     return 0;
 }
 
-static int flask_security_disable(char *buf, uint32_t count)
-{
-    int length;
-    int new_value;
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%d", &new_value) != 1 )
-        goto out;
-
-    if ( new_value )
-    {
-        length = flask_disable();
-        if ( length < 0 )
-            goto out;
-    }
-
-    length = count;
-
- out:
-    return length;
-}
-
-static int flask_security_setavc_threshold(char *buf, uint32_t count)
+static int flask_security_setavc_threshold(struct xen_flask_setavc_threshold *arg)
 {
-    int ret;
-    int new_value;
-
-    if ( sscanf(buf, "%u", &new_value) != 1 )
-    {
-        ret = -EINVAL;
-        goto out;
-    }
+    int rv = 0;
 
-    if ( new_value != avc_cache_threshold )
+    if ( arg->threshold != avc_cache_threshold )
     {
-        ret = domain_has_security(current->domain, SECURITY__SETSECPARAM);
-        if ( ret )
+        rv = domain_has_security(current->domain, SECURITY__SETSECPARAM);
+        if ( rv )
             goto out;
-        avc_cache_threshold = new_value;
+        avc_cache_threshold = arg->threshold;
     }
-    ret = count;
 
  out:
-    return ret;
+    return rv;
 }
 
-static int flask_security_set_bool(char *buf, uint32_t count)
+static int flask_security_resolve_bool(struct xen_flask_boolean *arg)
 {
-    int length = -EFAULT;
-    unsigned int i, new_value;
-
-    spin_lock(&sel_sem);
-
-    length = domain_has_security(current->domain, SECURITY__SETBOOL);
-    if ( length )
-        goto out;
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%d %d", &i, &new_value) != 2 )
-        goto out;
+    char *name;
+    int rv;
 
-    if (!bool_pending_values)
-        flask_security_make_bools();
+    if ( arg->bool_id != -1 )
+        return 0;
 
-    if ( i >= bool_num )
-        goto out;
+    rv = flask_copyin_string(arg->name, &name, arg->size);
+    if ( rv )
+        return rv;
 
-    if ( new_value )
-        new_value = 1;
+    arg->bool_id = security_find_bool(name);
+    arg->size = 0;
 
-    bool_pending_values[i] = new_value;
-    length = count;
+    xfree(name);
 
- out:
-    spin_unlock(&sel_sem);
-    return length;
+    return 0;
 }
 
-static int flask_security_set_bool_name(char *buf, uint32_t count)
+static int flask_security_set_bool(struct xen_flask_boolean *arg)
 {
-    int rv, num;
-    int i, new_value, commit;
-    int *values = NULL;
-    char *name;
-    
-    name = xmalloc_bytes(count);
-    if ( name == NULL )
-        return -ENOMEM;
+    int rv;
 
-    spin_lock(&sel_sem);
+    rv = flask_security_resolve_bool(arg);
+    if ( rv )
+        return rv;
 
     rv = domain_has_security(current->domain, SECURITY__SETBOOL);
     if ( rv )
-        goto out;
-    
-    rv = -EINVAL;
-    if ( sscanf(buf, "%s %d %d", name, &new_value, &commit) != 3 )
-        goto out;
+        return rv;
 
-    i = security_find_bool(name);
-    if ( i < 0 )
-        goto out;
+    spin_lock(&sel_sem);
 
-    if ( new_value )
-        new_value = 1;
+    if ( arg->commit )
+    {
+        int num;
+        int *values;
 
-    if ( commit ) {
         rv = security_get_bools(&num, NULL, &values);
         if ( rv != 0 )
             goto out;
-        values[i] = new_value;
-        if (bool_pending_values)
-            bool_pending_values[i] = new_value;
+
+        if ( arg->bool_id >= num )
+        {
+            rv = -ENOENT;
+            goto out;
+        }
+        values[arg->bool_id] = !!(arg->new_value);
+
+        arg->enforcing = arg->pending = !!(arg->new_value);
+
+        if ( bool_pending_values )
+            bool_pending_values[arg->bool_id] = !!(arg->new_value);
+
         rv = security_set_bools(num, values);
         xfree(values);
-    } else {
-        if (!bool_pending_values)
+    }
+    else
+    {
+        if ( !bool_pending_values )
             flask_security_make_bools();
 
-        bool_pending_values[i] = new_value;
-        rv = count;
+        if ( arg->bool_id >= bool_num )
+            goto out;
+
+        bool_pending_values[arg->bool_id] = !!(arg->new_value);
+        arg->pending = !!(arg->new_value);
+        arg->enforcing = security_get_bool_value(arg->bool_id);
+
+        rv = 0;
     }
 
  out:
-    xfree(name);
     spin_unlock(&sel_sem);
     return rv;
 }
 
-static int flask_security_commit_bools(char *buf, uint32_t count)
+static int flask_security_commit_bools(void)
 {
-    int length = -EFAULT;
-    int new_value;
+    int rv;
 
     spin_lock(&sel_sem);
 
-    length = domain_has_security(current->domain, SECURITY__SETBOOL);
-    if ( length )
-        goto out;
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%d", &new_value) != 1 )
+    rv = domain_has_security(current->domain, SECURITY__SETBOOL);
+    if ( rv )
         goto out;
 
-    if ( new_value && bool_pending_values )
-        security_set_bools(bool_num, bool_pending_values);
+    if ( bool_pending_values )
+        rv = security_set_bools(bool_num, bool_pending_values);
     
-    length = count;
-
  out:
     spin_unlock(&sel_sem);
-    return length;
+    return rv;
 }
 
-static int flask_security_get_bool(char *buf, uint32_t count, int named)
+static int flask_security_get_bool(struct xen_flask_boolean *arg)
 {
-    int length;
-    int i, cur_enforcing, pend_enforcing;
-    char* name = NULL;
-    
-    spin_lock(&sel_sem);
-    
-    length = -EINVAL;
-    if ( sscanf(buf, "%d", &i) != 1 )
-        goto out;
+    int rv;
 
-    cur_enforcing = security_get_bool_value(i);
-    if ( cur_enforcing < 0 )
-    {
-        length = cur_enforcing;
-        goto out;
-    }
+    rv = flask_security_resolve_bool(arg);
+    if ( rv )
+        return rv;
 
-    if ( bool_pending_values )
-        pend_enforcing = bool_pending_values[i];
-    else
-        pend_enforcing = cur_enforcing;
+    spin_lock(&sel_sem);
 
-    if ( named )
-        name = security_get_bool_name(i);
-    if ( named && !name )
+    rv = security_get_bool_value(arg->bool_id);
+    if ( rv < 0 )
         goto out;
 
-    memset(buf, 0, count);
-    if ( named )
-        length = snprintf(buf, count, "%d %d %s", cur_enforcing,
-                          pend_enforcing, name);
-    else
-        length = snprintf(buf, count, "%d %d", cur_enforcing,
-                          pend_enforcing);
+    arg->enforcing = rv;
 
- out:
-    xfree(name);
-    spin_unlock(&sel_sem);
-    return length;
-}
+    if ( bool_pending_values )
+        arg->pending = bool_pending_values[arg->bool_id];
+    else
+        arg->pending = rv;
 
-static int flask_security_get_bool_name(char *buf, uint32_t count)
-{
-    int rv = -ENOENT;
-    int i, cur_enforcing, pend_enforcing;
-    
-    spin_lock(&sel_sem);
-    
-    i = security_find_bool(buf);
-    if ( i < 0 )
-        goto out;
+    rv = 0;
 
-    cur_enforcing = security_get_bool_value(i);
-    if ( cur_enforcing < 0 )
+    if ( arg->size )
     {
-        rv = cur_enforcing;
-        goto out;
+        char *nameout = security_get_bool_name(arg->bool_id);
+        size_t nameout_len = strlen(nameout);
+        if ( nameout_len > arg->size )
+            rv = -ERANGE;
+        arg->size = nameout_len;
+ 
+        if ( !rv && copy_to_guest(arg->name, nameout, nameout_len) )
+            rv = -EFAULT;
+        xfree(nameout);
     }
 
-    if ( bool_pending_values )
-        pend_enforcing = bool_pending_values[i];
-    else
-        pend_enforcing = cur_enforcing;
-
-    memset(buf, 0, count);
-    rv = snprintf(buf, count, "%d %d", cur_enforcing, pend_enforcing);
-
  out:
     spin_unlock(&sel_sem);
     return rv;
@@ -779,380 +451,212 @@ static int flask_security_make_bools(void)
 
 #ifdef FLASK_AVC_STATS
 
-static int flask_security_avc_cachestats(char *buf, uint32_t count)
+static int flask_security_avc_cachestats(struct xen_flask_cache_stats *arg)
 {
-    char *page = NULL;
-    int len = 0;
-    int length = 0;
-    int cpu;
     struct avc_cache_stats *st;
 
-    page = (char *)xmalloc_bytes(PAGE_SIZE);
-    if ( !page )
-        return -ENOMEM;
-    memset(page, 0, PAGE_SIZE);
+    if ( arg->cpu > nr_cpu_ids )
+        return -ENOENT;
+    if ( !cpu_online(arg->cpu) )
+        return -ENOENT;
 
-    len = snprintf(page, PAGE_SIZE, "lookups hits misses allocations reclaims "
-                   "frees\n");
-    if ( len > count ) {
-        length = -EINVAL;
-        goto out;
-    }
-    
-    memcpy(buf, page, len);
-    buf += len;
-    length += len;
-    count -= len;
+    st = &per_cpu(avc_cache_stats, arg->cpu);
 
-    for_each_online_cpu ( cpu )
-    {
-        st = &per_cpu(avc_cache_stats, cpu);
+    arg->lookups = st->lookups;
+    arg->hits = st->hits;
+    arg->misses = st->misses;
+    arg->allocations = st->allocations;
+    arg->reclaims = st->reclaims;
+    arg->frees = st->frees;
 
-        len = snprintf(page, PAGE_SIZE, "%u %u %u %u %u %u\n", st->lookups,
-                       st->hits, st->misses, st->allocations,
-                       st->reclaims, st->frees);
-        if ( len > count ) {
-            length = -EINVAL;
-            goto out;
-        }
-        memcpy(buf, page, len);
-        buf += len;
-        length += len;
-        count -= len;
-    }
-
- out:
-    xfree(page);    
-    return length;
+    return 0;
 }
 
 #endif
 
-static int flask_security_load(char *buf, uint32_t count)
+static int flask_security_load(struct xen_flask_load *load)
 {
     int ret;
-    int length;
-
-    spin_lock(&sel_sem);
+    void *buf = NULL;
 
-    length = domain_has_security(current->domain, SECURITY__LOAD_POLICY);
-    if ( length )
-        goto out;
-
-    length = security_load_policy(buf, count);
-    if ( length )
-        goto out;
-
-    ret = flask_security_make_bools();
+    ret = domain_has_security(current->domain, SECURITY__LOAD_POLICY);
     if ( ret )
-        length = ret;
-    else
-        length = count;
+        return ret;
 
- out:
-    spin_unlock(&sel_sem);
-    return length;
-}
-
-static int flask_ocontext_del(char *buf, uint32_t size)
-{
-    int len = 0;
-    char *ocontext;
-    unsigned long low  = 0;
-    unsigned long high = 0;
-
-    len = domain_has_security(current->domain, SECURITY__DEL_OCONTEXT);
-    if ( len )
-        return len;
+    if ( load->size > MAX_POLICY_SIZE )
+        return -EINVAL;
 
-    if ( (ocontext = xmalloc_bytes(size) ) == NULL )
+    buf = xmalloc_bytes(load->size);
+    if ( !buf )
         return -ENOMEM;
 
-    len = sscanf(buf, "%s %lu %lu", ocontext, &low, &high);
-    if ( len < 2 )
+    if ( copy_from_guest(buf, load->buffer, load->size) )
     {
-        len = -EINVAL;
-        goto out;
+        ret = -EFAULT;
+        goto out_free;
     }
-    else if ( len == 2 )
-        high = low;
 
-    if ( low > high )
-    {
-        len = -EINVAL;
+    spin_lock(&sel_sem);
+
+    ret = security_load_policy(buf, load->size);
+    if ( ret )
         goto out;
-    }
 
-    len = security_ocontext_del(ocontext, low, high);
+    xfree(bool_pending_values);
+    bool_pending_values = NULL;
+    ret = 0;
+
  out:
-    xfree(ocontext);
-    return len;
+    spin_unlock(&sel_sem);
+ out_free:
+    xfree(buf);
+    return ret;
 }
 
-static int flask_ocontext_add(char *buf, uint32_t size)
+static int flask_ocontext_del(struct xen_flask_ocontext *arg)
 {
-    int len = 0;
-    u32 sid = 0;
-    unsigned long low  = 0;
-    unsigned long high = 0;
-    char *scontext;
-    char *ocontext;
-
-    len = domain_has_security(current->domain, SECURITY__ADD_OCONTEXT);
-    if ( len )
-        return len;
-
-    if ( (scontext = xmalloc_bytes(size) ) == NULL )
-        return -ENOMEM;
+    int rv;
 
-    if ( (ocontext = xmalloc_bytes(size) ) == NULL )
-    {
-        xfree(scontext);
-        return -ENOMEM;
-    }
-
-    memset(scontext, 0, size);
-    memset(ocontext, 0, size);
+    if ( arg->low > arg->high )
+        return -EINVAL;
 
-    len = sscanf(buf, "%s %s %lu %lu", ocontext, scontext, &low, &high);
-    if ( len < 3 )
-    {
-        len = -EINVAL;
-        goto out;
-    }
-    else if ( len == 3 )
-        high = low;
+    rv = domain_has_security(current->domain, SECURITY__DEL_OCONTEXT);
+    if ( rv )
+        return rv;
 
-    if ( low > high )
-    {
-        len = -EINVAL;
-        goto out;
-    }
-    len = security_context_to_sid(scontext, strlen(scontext)+1, &sid);
-    if ( len < 0 )
-    {
-        len = -EINVAL;
-        goto out;
-    }
-    len = security_ocontext_add(ocontext, low, high, sid);
- out:
-    xfree(ocontext);
-    xfree(scontext);
-    return len;
+    return security_ocontext_del(arg->ocon, arg->low, arg->high);
 }
 
-long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
+static int flask_ocontext_add(struct xen_flask_ocontext *arg)
 {
-    flask_op_t curop, *op = &curop;
-    int rc = 0;
-    int length = 0;
-    char *arg = NULL;
+    int rv;
 
-    if ( copy_from_guest(op, u_flask_op, 1) )
-        return -EFAULT;
-
-    if ( op->cmd > FLASK_LAST)
+    if ( arg->low > arg->high )
         return -EINVAL;
 
-    if ( op->size > MAX_POLICY_SIZE )
-        return -EINVAL;
+    rv = domain_has_security(current->domain, SECURITY__ADD_OCONTEXT);
+    if ( rv )
+        return rv;
 
-    if ( (op->buf == NULL && op->size != 0) || 
-         (op->buf != NULL && op->size == 0) )
-        return -EINVAL;
+    return security_ocontext_add(arg->ocon, arg->low, arg->high, arg->sid);
+}
 
-    arg = xmalloc_bytes(op->size + 1);
-    if ( !arg )
-        return -ENOMEM;
+long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
+{
+    xen_flask_op_t op;
+    int rv;
 
-    memset(arg, 0, op->size + 1);
+    if ( copy_from_guest(&op, u_flask_op, 1) )
+        return -EFAULT;
 
-    if ( (FLASK_COPY_IN&(1UL<<op->cmd)) && op->buf != NULL && 
-         copy_from_guest(arg, guest_handle_from_ptr(op->buf, char), op->size) )
-    {
-        rc = -EFAULT;
-        goto out;
-    }
+    if ( op.interface_version != XEN_FLASK_INTERFACE_VERSION )
+        return -ENOSYS;
 
-    switch ( op->cmd )
+    switch ( op.cmd )
     {
-
     case FLASK_LOAD:
-    {
-        length = flask_security_load(arg, op->size);
-    }
-    break;
-    
+        rv = flask_security_load(&op.u.load);
+        break;
+
     case FLASK_GETENFORCE:
-    {
-        length = snprintf(arg, op->size, "%d", flask_enforcing);
-    }
-    break;    
+        rv = flask_enforcing;
+        break;
 
     case FLASK_SETENFORCE:
-    {
-        length = flask_security_setenforce(arg, op->size);
-    }
-    break;    
+        rv = flask_security_setenforce(&op.u.enforce);
+        break;
 
     case FLASK_CONTEXT_TO_SID:
-    {
-        length = flask_security_context(arg, op->size);
-    }
-    break;    
+        rv = flask_security_context(&op.u.sid_context);
+        break;
 
     case FLASK_SID_TO_CONTEXT:
-    {
-        length = flask_security_sid(arg, op->size);
-    }
-    break; 
+        rv = flask_security_sid(&op.u.sid_context);
+        break;
 
     case FLASK_ACCESS:
-    {
-        length = flask_security_access(arg, op->size);
-    }
-    break;    
+        rv = flask_security_access(&op.u.access);
+        break;
 
     case FLASK_CREATE:
-    {
-        length = flask_security_create(arg, op->size);
-    }
-    break;    
+        rv = flask_security_create(&op.u.transition);
+        break;
 
     case FLASK_RELABEL:
-    {
-        length = flask_security_relabel(arg, op->size);
-    }
-    break;
+        rv = flask_security_relabel(&op.u.transition);
+        break;
 
     case FLASK_USER:
-    {
-        length = flask_security_user(arg, op->size);
-    }
-    break;    
+        rv = flask_security_user(&op.u.userlist);
+        break;
 
     case FLASK_POLICYVERS:
-    {
-        length = snprintf(arg, op->size, "%d", POLICYDB_VERSION_MAX);
-    }
-    break;    
+        rv = POLICYDB_VERSION_MAX;
+        break;
 
     case FLASK_GETBOOL:
-    {
-        length = flask_security_get_bool(arg, op->size, 0);
-    }
-    break;
+        rv = flask_security_get_bool(&op.u.boolean);
+        break;
 
     case FLASK_SETBOOL:
-    {
-        length = flask_security_set_bool(arg, op->size);
-    }
-    break;
+        rv = flask_security_set_bool(&op.u.boolean);
+        break;
 
     case FLASK_COMMITBOOLS:
-    {
-        length = flask_security_commit_bools(arg, op->size);
-    }
-    break;
+        rv = flask_security_commit_bools();
+        break;
 
     case FLASK_MLS:
-    {
-        length = snprintf(arg, op->size, "%d", flask_mls_enabled);
-    }
-    break;    
+        rv = flask_mls_enabled;
+        break;    
 
     case FLASK_DISABLE:
-    {
-        length = flask_security_disable(arg, op->size);
-    }
-    break;    
+        rv = flask_disable();
+        break;
 
     case FLASK_GETAVC_THRESHOLD:
-    {
-        length = snprintf(arg, op->size, "%d", avc_cache_threshold);
-    }
-    break;
+        rv = avc_cache_threshold;
+        break;
 
     case FLASK_SETAVC_THRESHOLD:
-    {
-        length = flask_security_setavc_threshold(arg, op->size);
-    }
-    break;
+        rv = flask_security_setavc_threshold(&op.u.setavc_threshold);
+        break;
 
     case FLASK_AVC_HASHSTATS:
-    {
-        length = avc_get_hash_stats(arg, op->size);
-    }
-    break;
+        rv = avc_get_hash_stats(&op.u.hash_stats);
+        break;
 
-#ifdef FLASK_AVC_STATS    
+#ifdef FLASK_AVC_STATS
     case FLASK_AVC_CACHESTATS:
-    {
-        length = flask_security_avc_cachestats(arg, op->size);
-    }
-    break;
+        rv = flask_security_avc_cachestats(&op.u.cache_stats);
+        break;
 #endif
 
     case FLASK_MEMBER:
-    {
-        length = flask_security_member(arg, op->size);
-    }
-    break;    
+        rv = flask_security_member(&op.u.transition);
+        break;
 
     case FLASK_ADD_OCONTEXT:
-    {
-        length = flask_ocontext_add(arg, op->size);
+        rv = flask_ocontext_add(&op.u.ocontext);
         break;
-    }
 
     case FLASK_DEL_OCONTEXT:
-    {
-        length = flask_ocontext_del(arg, op->size);
+        rv = flask_ocontext_del(&op.u.ocontext);
         break;
-    }
-
-    case FLASK_GETBOOL_NAMED:
-    {
-        length = flask_security_get_bool_name(arg, op->size);
-    }
-    break;
-
-    case FLASK_GETBOOL2:
-    {
-        length = flask_security_get_bool(arg, op->size, 1);
-    }
-    break;
-
-    case FLASK_SETBOOL_NAMED:
-    {
-        length = flask_security_set_bool_name(arg, op->size);
-    }
-    break;
 
     default:
-        length = -ENOSYS;
-        break;
-
+        rv = -ENOSYS;
     }
 
-    if ( length < 0 )
-    {
-        rc = length;
+    if ( rv < 0 )
         goto out;
-    }
-    
-    if ( (FLASK_COPY_OUT&(1UL<<op->cmd)) && op->buf != NULL && 
-         copy_to_guest(guest_handle_from_ptr(op->buf, char), arg, op->size) )
+
+    if ( (FLASK_COPY_OUT&(1UL<<op.cmd)) )
     {
-        rc = -EFAULT;
-        goto out;
+        if ( copy_to_guest(u_flask_op, &op, 1) )
+            rv = -EFAULT;
     }
 
-    op->size = length;
-    if ( copy_to_guest(u_flask_op, op, 1) )
-        rc = -EFAULT;
-
  out:
-    xfree(arg);
-    return rc;
+    return rv;
 }
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 8fffbb6..0f62891 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -104,7 +104,8 @@ int avc_add_callback(int (*callback)(u32 event, u32 ssid, u32 tsid,
                                     u32 ssid, u32 tsid, u16 tclass, u32 perms);
 
 /* Exported to selinuxfs */
-int avc_get_hash_stats(char *buf, uint32_t size);
+struct xen_flask_hash_stats;
+int avc_get_hash_stats(struct xen_flask_hash_stats *arg);
 extern unsigned int avc_cache_threshold;
 
 #ifdef FLASK_AVC_STATS
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 67ca6d0..348f018 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -90,8 +90,8 @@ int security_iterate_iomem_sids(unsigned long start, unsigned long end,
 int security_iterate_ioport_sids(u32 start, u32 end,
                                 security_iterate_fn fn, void *data);
 
-int security_ocontext_add(char *ocontext, unsigned long low,
+int security_ocontext_add(u32 ocontext, unsigned long low,
                            unsigned long high, u32 sid);
 
-int security_ocontext_del(char *ocontext, unsigned int low, unsigned int high);
+int security_ocontext_del(u32 ocontext, unsigned int low, unsigned int high);
 #endif /* _FLASK_SECURITY_H_ */
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 0189baf..363f586 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -2097,17 +2097,14 @@ int determine_ocontext( char *ocontext )
         return -1;
 }
 
-int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
+int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
                             ,u32 sid )
 {
     int ret = 0;
-    int ocon = 0;
     struct ocontext *c;
     struct ocontext *prev;
     struct ocontext *add;
 
-    if ( (ocon = determine_ocontext(ocontext)) < 0 )
-        return -EINVAL;
     if ( (add = xmalloc(struct ocontext)) == NULL )
         return -ENOMEM;
     memset(add, 0, sizeof(struct ocontext));
@@ -2254,15 +2251,11 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
     return ret;
 }
 
-int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
+int security_ocontext_del( u32 ocon, unsigned int low, unsigned int high )
 {
     int ret = 0;
-    int ocon = 0;
     struct ocontext *c, *before_c;
 
-    if ( (ocon = determine_ocontext(ocontext)) < 0 )
-        return -EINVAL;
-
     POLICY_WRLOCK;
     switch( ocon )
     {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpL-0000U7-Nj; Fri, 03 Feb 2012 15:13:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpJ-0000TC-Sp
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:26 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328281996!11872902!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21901 invoked from network); 3 Feb 2012 15:13:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-174.messagelabs.com with SMTP;
	3 Feb 2012 15:13:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDEni011012; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD64024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:13:00 -0500
Message-Id: <1328281981-17399-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/4] flask: Update flask_op hypercall structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of placing string parsing inside the hypervisor, use binary
structures like other Xen hypercalls do.

This patch also removes libflask; if the old flask_* namespace is needed
for longer backwards compatability (it was noted as deprecated in July
2010), a shim redirecting to the proper xc_flask_* calls can be created.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_flask.c            |  471 +++++++---------
 tools/libxc/xc_private.h          |    2 +
 tools/libxc/xenctrl.h             |    4 +-
 xen/include/public/xsm/flask_op.h |  146 +++++-
 xen/xsm/flask/avc.c               |   13 +-
 xen/xsm/flask/flask_op.c          | 1128 +++++++++++--------------------------
 xen/xsm/flask/include/avc.h       |    3 +-
 xen/xsm/flask/include/security.h  |    4 +-
 xen/xsm/flask/ss/services.c       |   11 +-
 9 files changed, 683 insertions(+), 1099 deletions(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index d268098..80c5a2d 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -30,18 +30,21 @@
 #include <sys/ioctl.h>
 #include <stdint.h>
 
-#define OCON_PIRQ_STR   "pirq"
-#define OCON_IOPORT_STR "ioport"
-#define OCON_IOMEM_STR  "iomem"
-#define OCON_DEVICE_STR "pcidevice"
+#define OCON_ISID    0    /* initial SIDs */
+#define OCON_PIRQ    1    /* physical irqs */
+#define OCON_IOPORT  2    /* io ports */
+#define OCON_IOMEM   3    /* io memory */
+#define OCON_DEVICE  4    /* pci devices */
 #define INITCONTEXTLEN  256
 
-int xc_flask_op(xc_interface *xch, flask_op_t *op)
+int xc_flask_op(xc_interface *xch, xen_flask_op_t *op)
 {
     int ret = -1;
     DECLARE_HYPERCALL;
     DECLARE_HYPERCALL_BOUNCE(op, sizeof(*op), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
 
+    op->interface_version = XEN_FLASK_INTERFACE_VERSION;
+
     if ( xc_hypercall_bounce_pre(xch, op) )
     {
         PERROR("Could not bounce memory for flask op hypercall");
@@ -63,402 +66,360 @@ int xc_flask_op(xc_interface *xch, flask_op_t *op)
     return ret;
 }
 
-int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size)
+int xc_flask_load(xc_interface *xch, char *buf, uint32_t size)
 {
     int err;
-    flask_op_t op;
-    
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(buf, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    if ( xc_hypercall_bounce_pre(xch, buf) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
+
     op.cmd = FLASK_LOAD;
-    op.buf = buf;
-    op.size = size;
+    op.u.load.size = size;
+    set_xen_guest_handle(op.u.load.buffer, buf);
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
+    err = xc_flask_op(xch, &op);
 
-    return 0;
+    xc_hypercall_bounce_post(xch, buf);
+
+    return err;
 }
 
-int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid)
+int xc_flask_context_to_sid(xc_interface *xch, char *buf, uint32_t size, uint32_t *sid)
 {
     int err;
-    flask_op_t op;
-    
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(buf, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+    if ( xc_hypercall_bounce_pre(xch, buf) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
+
     op.cmd = FLASK_CONTEXT_TO_SID;
-    op.buf = buf;
-    op.size = size;
+    op.u.sid_context.size = size;
+    set_xen_guest_handle(op.u.sid_context.context, buf);
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-    
-    sscanf(buf, "%u", sid);
+    err = xc_flask_op(xch, &op);
 
-    return 0;
+    if ( !err )
+        *sid = op.u.sid_context.sid;
+
+    xc_hypercall_bounce_post(xch, buf);
+
+    return err;
 }
 
-int xc_flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size)
+int xc_flask_sid_to_context(xc_interface *xch, int sid, char *buf, uint32_t size)
 {
     int err;
-    flask_op_t op;
-    
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(buf, size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, buf) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
+
     op.cmd = FLASK_SID_TO_CONTEXT;
-    op.buf = buf;
-    op.size = size;
+    op.u.sid_context.sid = sid;
+    op.u.sid_context.size = size;
+    set_xen_guest_handle(op.u.sid_context.context, buf);
     
-    snprintf(buf, size, "%u", sid);
+    err = xc_flask_op(xch, &op);
 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
+    xc_hypercall_bounce_post(xch, buf);
+   
+    return err;
 }
 
-int xc_flask_getenforce(xc_interface *xc_handle)
+int xc_flask_getenforce(xc_interface *xch)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int mode;
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_GETENFORCE;
-    op.buf = buf;
-    op.size = size;
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &mode);
-
-    return mode;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_setenforce(xc_interface *xc_handle, int mode)
+int xc_flask_setenforce(xc_interface *xch, int mode)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];
-    int size = 20; 
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_SETENFORCE;
-    op.buf = buf;
-    op.size = size;
+    op.u.enforce.enforcing = mode;
    
-    snprintf(buf, size, "%i", mode);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_getbool_byid(xc_interface *xc_handle, int id, char *name, uint32_t size, int *curr, int *pend)
+int xc_flask_getbool_byid(xc_interface *xch, int id, char *name, uint32_t size, int *curr, int *pend)
 {
-    flask_op_t op;
-    char buf[255];
     int rv;
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(name, size, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+    if ( xc_hypercall_bounce_pre(xch, name) )
+    {
+        PERROR("Could not bounce memory for flask op hypercall");
+        return -1;
+    }
 
-    op.cmd = FLASK_GETBOOL2;
-    op.buf = buf;
-    op.size = 255;
+    op.cmd = FLASK_GETBOOL;
+    op.u.boolean.bool_id = id;
+    op.u.boolean.size = size;
+    set_xen_guest_handle(op.u.boolean.name, name);
 
-    snprintf(buf, sizeof buf, "%i", id);
+    rv = xc_flask_op(xch, &op);
 
-    rv = xc_flask_op(xc_handle, &op);
+    xc_hypercall_bounce_post(xch, name);
 
     if ( rv )
         return rv;
     
-    sscanf(buf, "%i %i %s", curr, pend, name);
+    if ( curr )
+        *curr = op.u.boolean.enforcing;
+    if ( pend )
+        *pend = op.u.boolean.pending;
 
     return rv;
 }
 
-int xc_flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
+int xc_flask_getbool_byname(xc_interface *xch, char *name, int *curr, int *pend)
 {
-    flask_op_t op;
-    char buf[255];
     int rv;
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(name, strlen(name), XC_HYPERCALL_BUFFER_BOUNCE_IN);
 
-    op.cmd = FLASK_GETBOOL_NAMED;
-    op.buf = buf;
-    op.size = 255;
+    op.cmd = FLASK_GETBOOL;
+    op.u.boolean.bool_id = -1;
+    op.u.boolean.size = strlen(name);
+    set_xen_guest_handle(op.u.boolean.name, name);
 
-    strncpy(buf, name, op.size);
+    rv = xc_flask_op(xch, &op);
 
-    rv = xc_flask_op(xc_handle, &op);
+    xc_hypercall_bounce_post(xch, name);
 
     if ( rv )
         return rv;
     
-    sscanf(buf, "%i %i", curr, pend);
+    if ( curr )
+        *curr = op.u.boolean.enforcing;
+    if ( pend )
+        *pend = op.u.boolean.pending;
 
     return rv;
 }
 
-int xc_flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
+int xc_flask_setbool(xc_interface *xch, char *name, int value, int commit)
 {
-    flask_op_t op;
-    char buf[255];
-    int size = 255;
+    int rv;
+    DECLARE_FLASK_OP;
+    DECLARE_HYPERCALL_BOUNCE(name, strlen(name), XC_HYPERCALL_BUFFER_BOUNCE_IN);
 
-    op.cmd = FLASK_SETBOOL_NAMED;
-    op.buf = buf;
-    op.size = size;
+    op.cmd = FLASK_SETBOOL;
+    op.u.boolean.bool_id = -1;
+    op.u.boolean.new_value = value;
+    op.u.boolean.commit = 1;
+    op.u.boolean.size = strlen(name);
+    set_xen_guest_handle(op.u.boolean.name, name);
 
-    snprintf(buf, size, "%s %i %i", name, value, commit);
+    rv = xc_flask_op(xch, &op);
 
-    return xc_flask_op(xc_handle, &op);
+    xc_hypercall_bounce_post(xch, name);
+
+    return rv;
 }
 
-static int xc_flask_add(xc_interface *xc_handle, char *cat, char *arg, char *scontext)
+
+static int xc_flask_add(xc_interface *xch, uint32_t ocon, uint64_t low, uint64_t high, char *scontext)
 {
-    char buf[512];
-    flask_op_t op;
+    uint32_t sid;
+    int err;
+    DECLARE_FLASK_OP;
+
+    err = xc_flask_context_to_sid(xch, scontext, strlen(scontext), &sid);
+    if ( err )
+        return err;
 
-    memset(buf, 0, 512);
-    snprintf(buf, 512, "%s %255s %s", cat, scontext, arg);
     op.cmd = FLASK_ADD_OCONTEXT;
-    op.buf = buf;
-    op.size = 512;
+    op.u.ocontext.ocon = ocon;
+    op.u.ocontext.sid = sid;
+    op.u.ocontext.low = low;
+    op.u.ocontext.high = high;
     
-    return xc_flask_op(xc_handle, &op);
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext)
+int xc_flask_add_pirq(xc_interface *xch, unsigned int pirq, char *scontext)
 {
-    char arg[16];
-
-    snprintf(arg, 16, "%u", pirq);
-    return xc_flask_add(xc_handle, OCON_PIRQ_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_PIRQ, pirq, pirq, scontext);
 }
 
-int xc_flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
+int xc_flask_add_ioport(xc_interface *xch, unsigned long low, unsigned long high,
                       char *scontext)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_add(xc_handle, OCON_IOPORT_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_IOPORT, low, high, scontext);
 }
 
-int xc_flask_add_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high,
+int xc_flask_add_iomem(xc_interface *xch, unsigned long low, unsigned long high,
                      char *scontext)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_add(xc_handle, OCON_IOMEM_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_IOMEM, low, high, scontext);
 }
 
-int xc_flask_add_device(xc_interface *xc_handle, unsigned long device, char *scontext)
+int xc_flask_add_device(xc_interface *xch, unsigned long device, char *scontext)
 {
-    char arg[32];
-
-    snprintf(arg, 32, "%lu", device);
-    return xc_flask_add(xc_handle, OCON_DEVICE_STR, arg, scontext);
+    return xc_flask_add(xch, OCON_DEVICE, device, device, scontext);
 }
 
-static int xc_flask_del(xc_interface *xc_handle, char *cat, char *arg)
+static int xc_flask_del(xc_interface *xch, uint32_t ocon, uint64_t low, uint64_t high)
 {
-    char buf[256];
-    flask_op_t op;
+    DECLARE_FLASK_OP;
 
-    memset(buf, 0, 256);
-    snprintf(buf, 256, "%s %s", cat, arg);
     op.cmd = FLASK_DEL_OCONTEXT;
-    op.buf = buf;
-    op.size = 256;
+    op.u.ocontext.ocon = ocon;
+    op.u.ocontext.low = low;
+    op.u.ocontext.high = high;
     
-    return xc_flask_op(xc_handle, &op);
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_del_pirq(xc_interface *xc_handle, unsigned int pirq)
+int xc_flask_del_pirq(xc_interface *xch, unsigned int pirq)
 {
-    char arg[16];
-
-    snprintf(arg, 16, "%u", pirq);
-    return xc_flask_del(xc_handle, OCON_PIRQ_STR, arg);
+    return xc_flask_del(xch, OCON_PIRQ, pirq, pirq);
 }
 
-int xc_flask_del_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high)
+int xc_flask_del_ioport(xc_interface *xch, unsigned long low, unsigned long high)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_del(xc_handle, OCON_IOPORT_STR, arg);
+    return xc_flask_del(xch, OCON_IOPORT, low, high);
 }
 
-int xc_flask_del_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high)
+int xc_flask_del_iomem(xc_interface *xch, unsigned long low, unsigned long high)
 {
-    char arg[64];
-
-    snprintf(arg, 64, "%lu %lu", low, high);
-    return xc_flask_del(xc_handle, OCON_IOMEM_STR, arg);
+    return xc_flask_del(xch, OCON_IOMEM, low, high);
 }
 
-int xc_flask_del_device(xc_interface *xc_handle, unsigned long device)
+int xc_flask_del_device(xc_interface *xch, unsigned long device)
 {
-    char arg[32];
-
-    snprintf(arg, 32, "%lu", device);
-    return xc_flask_del(xc_handle, OCON_DEVICE_STR, arg);
+    return xc_flask_del(xch, OCON_DEVICE, device, device);
 }
 
-int xc_flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
+int xc_flask_access(xc_interface *xch, const char *scon, const char *tcon,
                 uint16_t tclass, uint32_t req,
                 uint32_t *allowed, uint32_t *decided,
                 uint32_t *auditallow, uint32_t *auditdeny,
                 uint32_t *seqno)
 {
-/* maximum number of digits in a 16-bit decimal number: */
-#define MAX_SHORT_DEC_LEN 5
-
-    char *buf;
-    int bufLen;
+    DECLARE_FLASK_OP;
     int err;
-    flask_op_t op;
-    uint32_t dummy_allowed;
-    uint32_t dummy_decided;
-    uint32_t dummy_auditallow;
-    uint32_t dummy_auditdeny;
-    uint32_t dummy_seqno;
-  
-    if (!allowed)
-        allowed = &dummy_allowed;
-    if (!decided)
-        decided = &dummy_decided;
-    if (!auditallow)
-        auditallow = &dummy_auditallow;
-    if (!auditdeny)
-        auditdeny = &dummy_auditdeny;
-    if (!seqno)
-        seqno = &dummy_seqno;
-
-    if (!scon)
-        return -EINVAL;
-    if (!tcon)
-        return -EINVAL;
-
-    bufLen = strlen(scon) + 1 + strlen(tcon) + 1 +
-        MAX_SHORT_DEC_LEN + 1 +
-        sizeof(req)*2 + 1;
-    buf = malloc(bufLen);
-    snprintf(buf, bufLen, "%s %s %hu %x", scon, tcon, tclass, req);
+
+    err = xc_flask_context_to_sid(xch, (char*)scon, strlen(scon), &op.u.access.ssid);
+    if ( err )
+        return err;
+    err = xc_flask_context_to_sid(xch, (char*)tcon, strlen(tcon), &op.u.access.tsid);
+    if ( err )
+        return err;
 
     op.cmd = FLASK_ACCESS;
-    op.buf = buf;
-    op.size = strlen(buf)+1;
+    op.u.access.tclass = tclass;
+    op.u.access.req = req;
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
+    err = xc_flask_op(xch, &op);
+
+    if ( err )
         return err;
-    }
-   
-    if (sscanf(op.buf, "%x %x %x %x %u",
-               allowed, decided,
-               auditallow, auditdeny,
-               seqno) != 5) {
-        err = -EILSEQ;
-    }
 
-    err = ((*allowed & req) == req)? 0 : -EPERM;
+    if ( allowed )
+        *allowed = op.u.access.allowed;
+    if ( decided )
+        *decided = 0xffffffff;
+    if ( auditallow )
+        *auditallow = op.u.access.audit_allow;
+    if ( auditdeny )
+        *auditdeny = op.u.access.audit_deny;
+    if ( seqno )
+        *seqno = op.u.access.seqno;
 
-    return err;
+    if ( (op.u.access.allowed & req) != req )
+        err = -EPERM;
 
+    return err;
 }
 
-int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size)
+int xc_flask_avc_hashstats(xc_interface *xch, char *buf, int size)
 {
     int err;
-    flask_op_t op;
+    DECLARE_FLASK_OP;
   
     op.cmd = FLASK_AVC_HASHSTATS;
-    op.buf = buf;
-    op.size = size;
   
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
+    err = xc_flask_op(xch, &op);
 
-    return 0;
+    snprintf(buf, size,
+             "entries: %d\nbuckets used: %d/%d\nlongest chain: %d\n",
+             op.u.hash_stats.entries, op.u.hash_stats.buckets_used,
+             op.u.hash_stats.buckets_total, op.u.hash_stats.max_chain_len);
+
+    return err;
 }
 
-int xc_flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size)
+int xc_flask_avc_cachestats(xc_interface *xch, char *buf, int size)
 {
-    int err;
-    flask_op_t op;
+    int err, n;
+    int i = 0;
+    DECLARE_FLASK_OP;
+
+    n = snprintf(buf, size, "lookups hits misses allocations reclaims frees\n");
+    buf += n;
+    size -= n;
   
     op.cmd = FLASK_AVC_CACHESTATS;
-    op.buf = buf;
-    op.size = size;
-  
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
+    while ( size > 0 )
     {
-        free(buf);
-        return err;
+        op.u.cache_stats.cpu = i;
+        err = xc_flask_op(xch, &op);
+        if ( err && errno == ENOENT )
+            return 0;
+        if ( err )
+            return err;
+        n = snprintf(buf, size, "%u %u %u %u %u %u\n",
+                     op.u.cache_stats.lookups, op.u.cache_stats.hits,
+                     op.u.cache_stats.misses, op.u.cache_stats.allocations,
+                     op.u.cache_stats.reclaims, op.u.cache_stats.frees);
+        buf += n;
+        size -= n;
+        i++;
     }
 
     return 0;
 }
 
-int xc_flask_policyvers(xc_interface *xc_handle, char *buf, int size)
+int xc_flask_policyvers(xc_interface *xch)
 {
-    int err;
-    flask_op_t op;
-  
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_POLICYVERS;
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
 
-    return 0;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_getavc_threshold(xc_interface *xc_handle)
+int xc_flask_getavc_threshold(xc_interface *xch)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int threshold;
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_GETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
     
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &threshold);
-
-    return threshold;
+    return xc_flask_op(xch, &op);
 }
 
-int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold)
+int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
 {
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
- 
+    DECLARE_FLASK_OP;
     op.cmd = FLASK_SETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
+    op.u.setavc_threshold.threshold = threshold;
 
-    snprintf(buf, size, "%i", threshold);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
+    return xc_flask_op(xch, &op);
 }
 
 /*
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 3687561..7b83ef3 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -42,11 +42,13 @@
 #define DECLARE_DOMCTL struct xen_domctl domctl = { 0 }
 #define DECLARE_SYSCTL struct xen_sysctl sysctl = { 0 }
 #define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = { 0 }
+#define DECLARE_FLASK_OP struct xen_flask_op op = { 0 }
 #else
 #define DECLARE_HYPERCALL privcmd_hypercall_t hypercall
 #define DECLARE_DOMCTL struct xen_domctl domctl
 #define DECLARE_SYSCTL struct xen_sysctl sysctl
 #define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
+#define DECLARE_FLASK_OP struct xen_flask_op op
 #endif
 
 #undef PAGE_SHIFT
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 1e7c32b..6b3202e 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1328,7 +1328,7 @@ int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl);
 
 int xc_version(xc_interface *xch, int cmd, void *arg);
 
-int xc_flask_op(xc_interface *xch, flask_op_t *op);
+int xc_flask_op(xc_interface *xch, xen_flask_op_t *op);
 
 /*
  * Subscribe to state changes in a domain via evtchn.
@@ -1976,7 +1976,7 @@ int xc_flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
                   uint32_t *auditallow, uint32_t *auditdeny,
                   uint32_t *seqno);
 int xc_flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size);
-int xc_flask_policyvers(xc_interface *xc_handle, char *buf, int size);
+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);
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 416ac08..83dcd99 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -25,6 +25,118 @@
 #ifndef __FLASK_OP_H__
 #define __FLASK_OP_H__
 
+#define XEN_FLASK_INTERFACE_VERSION 1
+
+struct xen_flask_load {
+    XEN_GUEST_HANDLE(char) buffer;
+    uint32_t size;
+};
+
+struct xen_flask_setenforce {
+    uint32_t enforcing;
+};
+
+struct xen_flask_sid_context {
+    /* IN/OUT: sid to convert to/from string */
+    uint32_t sid;
+    /* IN: size of the context buffer
+     * OUT: actual size of the output context string
+     */
+    uint32_t size;
+    XEN_GUEST_HANDLE(char) context;
+};
+
+struct xen_flask_access {
+    /* IN: access request */
+    uint32_t ssid;
+    uint32_t tsid;
+    uint32_t tclass;
+    uint32_t req;
+    /* OUT: AVC data */
+    uint32_t allowed;
+    uint32_t audit_allow;
+    uint32_t audit_deny;
+    uint32_t seqno;
+};
+
+struct xen_flask_transition {
+    /* IN: transition SIDs and class */
+    uint32_t ssid;
+    uint32_t tsid;
+    uint32_t tclass;
+    /* OUT: new SID */
+    uint32_t newsid;
+};
+
+struct xen_flask_userlist {
+    /* IN: starting SID for list */
+    uint32_t start_sid;
+    /* IN: size of user string and output buffer
+     * OUT: number of SIDs returned */
+    uint32_t size;
+    union {
+        /* IN: user to enumerate SIDs */
+        XEN_GUEST_HANDLE(char) user;
+        /* OUT: SID list */
+        XEN_GUEST_HANDLE(uint32) sids;
+    } u;
+};
+
+struct xen_flask_boolean {
+    /* IN/OUT: numeric identifier for boolean [GET/SET]
+     * If -1, name will be used and bool_id will be filled in. */
+    uint32_t bool_id;
+    /* OUT: current enforcing value of boolean [GET/SET] */
+    uint8_t enforcing;
+    /* OUT: pending value of boolean [GET/SET] */
+    uint8_t pending;
+    /* IN: new value of boolean [SET] */
+    uint8_t new_value;
+    /* IN: commit new value instead of only setting pending [SET] */
+    uint8_t commit;
+    /* IN: size of boolean name buffer [GET/SET]
+     * OUT: actual size of name [GET only] */
+    uint32_t size;
+    /* IN: if bool_id is -1, used to find boolean [GET/SET]
+     * OUT: textual name of boolean [GET only]
+     */
+    XEN_GUEST_HANDLE(char) name;
+};
+
+struct xen_flask_setavc_threshold {
+    /* IN */
+    uint32_t threshold;
+};
+
+struct xen_flask_hash_stats {
+    /* OUT */
+    uint32_t entries;
+    uint32_t buckets_used;
+    uint32_t buckets_total;
+    uint32_t max_chain_len;
+};
+
+struct xen_flask_cache_stats {
+    /* IN */
+    uint32_t cpu;
+    /* OUT */
+    uint32_t lookups;
+    uint32_t hits;
+    uint32_t misses;
+    uint32_t allocations;
+    uint32_t reclaims;
+    uint32_t frees;
+};
+
+struct xen_flask_ocontext {
+    /* IN */
+    uint32_t ocon;
+    uint32_t sid;
+    uint64_t low, high;
+};
+
+struct xen_flask_op {
+    uint32_t cmd;
 #define FLASK_LOAD              1
 #define FLASK_GETENFORCE        2
 #define FLASK_SETENFORCE        3
@@ -47,18 +159,26 @@
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
-#define FLASK_GETBOOL_NAMED     23
-#define FLASK_GETBOOL2          24
-#define FLASK_SETBOOL_NAMED     25
-
-#define FLASK_LAST              FLASK_SETBOOL_NAMED
-
-typedef struct flask_op {
-    uint32_t  cmd;
-    uint32_t  size;
-    char      *buf;
-} flask_op_t;
-
-DEFINE_XEN_GUEST_HANDLE(flask_op_t);
+    uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
+    union {
+        struct xen_flask_load load;
+        struct xen_flask_setenforce enforce;
+        /* FLASK_CONTEXT_TO_SID and FLASK_SID_TO_CONTEXT */
+        struct xen_flask_sid_context sid_context;
+        struct xen_flask_access access;
+        /* FLASK_CREATE, FLASK_RELABEL, FLASK_MEMBER */
+        struct xen_flask_transition transition;
+        struct xen_flask_userlist userlist;
+        /* FLASK_GETBOOL, FLASK_SETBOOL */
+        struct xen_flask_boolean boolean;
+        struct xen_flask_setavc_threshold setavc_threshold;
+        struct xen_flask_hash_stats hash_stats;
+        struct xen_flask_cache_stats cache_stats;
+        /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
+        struct xen_flask_ocontext ocontext;
+    } u;
+};
+typedef struct xen_flask_op xen_flask_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_flask_op_t);
 
 #endif
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 3a60a3a..74f160d 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -28,6 +28,7 @@
 #include <xen/rcupdate.h>
 #include <asm/atomic.h>
 #include <asm/current.h>
+#include <public/xsm/flask_op.h>
 
 #include "avc.h"
 #include "avc_ss.h"
@@ -251,7 +252,7 @@ void __init avc_init(void)
     printk("AVC INITIALIZED\n");
 }
 
-int avc_get_hash_stats(char *buf, uint32_t size)
+int avc_get_hash_stats(struct xen_flask_hash_stats *arg)
 {
     int i, chain_len, max_chain_len, slots_used;
     struct avc_node *node;
@@ -279,10 +280,12 @@ int avc_get_hash_stats(char *buf, uint32_t size)
 
     rcu_read_unlock(&avc_rcu_lock);
     
-    return snprintf(buf, size, "entries: %d\nbuckets used: %d/%d\n"
-                    "longest chain: %d\n",
-                    atomic_read(&avc_cache.active_nodes),
-                    slots_used, AVC_CACHE_SLOTS, max_chain_len);
+    arg->entries = atomic_read(&avc_cache.active_nodes);
+    arg->buckets_used = slots_used;
+    arg->buckets_total = AVC_CACHE_SLOTS;
+    arg->max_chain_len = max_chain_len;
+
+    return 0;
 }
 
 static void avc_node_free(struct rcu_head *rhead)
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 64d9ec5..00a0af2 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -30,48 +30,21 @@ integer_param("flask_enabled", flask_enabled);
 #endif
 
 #define MAX_POLICY_SIZE 0x4000000
-#define FLASK_COPY_IN \
-    ( \
-        1UL<<FLASK_LOAD | \
-        1UL<<FLASK_SETENFORCE | \
-        1UL<<FLASK_CONTEXT_TO_SID | \
-        1UL<<FLASK_SID_TO_CONTEXT | \
-        1UL<<FLASK_ACCESS | \
-        1UL<<FLASK_CREATE | \
-        1UL<<FLASK_RELABEL | \
-        1UL<<FLASK_USER | \
-        1UL<<FLASK_GETBOOL | \
-        1UL<<FLASK_SETBOOL | \
-        1UL<<FLASK_COMMITBOOLS | \
-        1UL<<FLASK_DISABLE | \
-        1UL<<FLASK_SETAVC_THRESHOLD | \
-        1UL<<FLASK_MEMBER | \
-        1UL<<FLASK_ADD_OCONTEXT | \
-        1UL<<FLASK_DEL_OCONTEXT | \
-        1UL<<FLASK_GETBOOL_NAMED | \
-        1UL<<FLASK_GETBOOL2 | \
-        1UL<<FLASK_SETBOOL_NAMED \
-    )
 
 #define FLASK_COPY_OUT \
     ( \
-        1UL<<FLASK_GETENFORCE | \
         1UL<<FLASK_CONTEXT_TO_SID | \
         1UL<<FLASK_SID_TO_CONTEXT | \
         1UL<<FLASK_ACCESS | \
         1UL<<FLASK_CREATE | \
         1UL<<FLASK_RELABEL | \
         1UL<<FLASK_USER | \
-        1UL<<FLASK_POLICYVERS | \
         1UL<<FLASK_GETBOOL | \
-        1UL<<FLASK_MLS | \
-        1UL<<FLASK_GETAVC_THRESHOLD | \
+        1UL<<FLASK_SETBOOL | \
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
         1UL<<FLASK_MEMBER | \
-        1UL<<FLASK_GETBOOL_NAMED | \
-        1UL<<FLASK_GETBOOL2 \
-    )
+   0)
 
 static DEFINE_SPINLOCK(sel_sem);
 
@@ -96,412 +69,186 @@ static int domain_has_security(struct domain *d, u32 perms)
                         perms, NULL);
 }
 
-static int flask_security_user(char *buf, uint32_t size)
-{
-    char *page = NULL;
-    char *con, *user, *ptr;
-    u32 sid, *sids;
-    int length;
-    char *newcon;
-    int i, rc;
-    u32 len, nsids;
-        
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_USER);
-    if ( length )
-        return length;
-            
-    length = -ENOMEM;
-    con = xmalloc_array(char, size+1);
-    if ( !con )
-        return length;
-    memset(con, 0, size+1);
-    
-    user = xmalloc_array(char, size+1);
-    if ( !user )
-        goto out;
-    memset(user, 0, size+1);
-    
-    length = -ENOMEM;
-    page = xmalloc_bytes(PAGE_SIZE);
-    if ( !page )
-        goto out2;
-    memset(page, 0, PAGE_SIZE);
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%s %s", con, user) != 2 )
-        goto out2;
-
-    length = security_context_to_sid(con, strlen(con)+1, &sid);
-    if ( length < 0 )
-        goto out2;
-            
-    length = security_get_user_sids(sid, user, &sids, &nsids);
-    if ( length < 0 )
-        goto out2;
-    
-    length = snprintf(page, PAGE_SIZE, "%u", nsids) + 1;
-    ptr = page + length;
-    for ( i = 0; i < nsids; i++ )
-    {
-        rc = security_sid_to_context(sids[i], &newcon, &len);
-        if ( rc )
-        {
-            length = rc;
-            goto out3;
-        }
-        if ( (length + len) >= PAGE_SIZE )
-        {
-            xfree(newcon);
-            length = -ERANGE;
-            goto out3;
-        }
-        memcpy(ptr, newcon, len);
-        xfree(newcon);
-        ptr += len;
-        length += len;
-    }
-    
-    if ( length > size )
-    {
-        printk( "%s:  context size (%u) exceeds payload "
-                "max\n", __FUNCTION__, length);
-        length = -ERANGE;
-        goto out3;
-    }
-
-    memset(buf, 0, size);
-    memcpy(buf, page, length);
-        
- out3:
-    xfree(sids);
- out2:
-    if ( page )
-        xfree(page);
-    xfree(user);
- out:
-    xfree(con);
-    return length;
-}
-
-static int flask_security_relabel(char *buf, uint32_t size)
+static int flask_copyin_string(XEN_GUEST_HANDLE(char) u_buf, char **buf, uint32_t size)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid, newsid;
-    u16 tclass;
-    int length;
-    char *newcon;
-    u32 len;
+    char *tmp = xmalloc_bytes(size + 1);
+    if ( !tmp )
+        return -ENOMEM;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_RELABEL);
-    if ( length )
-        return length;
-            
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if ( !scon )
-        return length;
-    memset(scon, 0, size+1);
-        
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
-        goto out;
-    memset(tcon, 0, size+1);
-        
-    length = -EINVAL;
-    if ( sscanf(buf, "%s %s %hu", scon, tcon, &tclass) != 3 )
-        goto out2;
-            
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
-            
-    length = security_change_sid(ssid, tsid, tclass, &newsid);
-    if ( length < 0 )
-        goto out2;
-            
-    length = security_sid_to_context(newsid, &newcon, &len);
-    if ( length < 0 )
-        goto out2;
-            
-    if ( len > size )
+    if ( copy_from_guest(tmp, u_buf, size) )
     {
-        printk( "%s:  context size (%u) exceeds payload "
-                "max\n", __FUNCTION__, len);
-        length = -ERANGE;
-        goto out3;
+        xfree(tmp);
+        return -EFAULT;
     }
+    tmp[size] = 0;
 
-    memset(buf, 0, size);
-    memcpy(buf, newcon, len);
-    length = len;
-
- out3:
-    xfree(newcon);
- out2:
-    xfree(tcon);
- out:
-    xfree(scon);
-    return length;
+    *buf = tmp;
+    return 0;
 }
 
-static int flask_security_create(char *buf, uint32_t size)
+static int flask_security_user(struct xen_flask_userlist *arg)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid, newsid;
-    u16 tclass;
-    int length;
-    char *newcon;
-    u32 len;
+    char *user;
+    u32 *sids;
+    u32 nsids;
+    int rv;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_CREATE);
-    if ( length )
-        return length;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_USER);
+    if ( rv )
+        return rv;
 
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if ( !scon )
-        return length;
-    memset(scon, 0, size+1);
+    rv = flask_copyin_string(arg->u.user, &user, arg->size);
+    if ( rv )
+        return rv;
 
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
+    rv = security_get_user_sids(arg->start_sid, user, &sids, &nsids);
+    if ( rv < 0 )
         goto out;
-    memset(tcon, 0, size+1);
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%s %s %hu", scon, tcon, &tclass) != 3 )
-        goto out2;
-
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
 
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
+    if ( nsids * sizeof(sids[0]) > arg->size )
+        nsids = arg->size / sizeof(sids[0]);
 
-    length = security_transition_sid(ssid, tsid, tclass, &newsid);
-    if ( length < 0 )
-        goto out2;
+    arg->size = nsids;
 
-    length = security_sid_to_context(newsid, &newcon, &len);
-    if ( length < 0 )    
-        goto out2;
-
-    if ( len > size )
-    {
-        printk( "%s:  context size (%u) exceeds payload "
-                "max\n", __FUNCTION__, len);
-        length = -ERANGE;
-        goto out3;
-    }
+    if ( copy_to_guest(arg->u.sids, sids, nsids) )
+        rv = -EFAULT;
 
-    memset(buf, 0, size);
-    memcpy(buf, newcon, len);
-    length = len;
-        
- out3:
-    xfree(newcon);
- out2:
-    xfree(tcon);
+    xfree(sids);
  out:
-    xfree(scon);
-    return length;
+    xfree(user);
+    return rv;
 }
 
-static int flask_security_access(char *buf, uint32_t size)
+static int flask_security_relabel(struct xen_flask_transition *arg)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid;
-    u16 tclass;
-    u32 req;
-    struct av_decision avd;
-    int length;
+    int rv;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_AV);
-    if ( length )
-        return length;
-
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if (!scon)
-        return length;
-    memset(scon, 0, size+1);
-
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
-        goto out;
-    memset( tcon, 0, size+1 );
-
-    length = -EINVAL;
-    if (sscanf(buf, "%s %s %hu %x", scon, tcon, &tclass, &req) != 4)
-        goto out2;
-
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
-
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_RELABEL);
+    if ( rv )
+        return rv;
 
-    length = security_compute_av(ssid, tsid, tclass, req, &avd);
-    if ( length < 0 )
-        goto out2;
+    rv = security_change_sid(arg->ssid, arg->tsid, arg->tclass, &arg->newsid);
 
-    memset(buf, 0, size);
-    length = snprintf(buf, size, "%x %x %x %x %u", 
-                      avd.allowed, 0xffffffff,
-                      avd.auditallow, avd.auditdeny, 
-                      avd.seqno);
-                
- out2:
-    xfree(tcon);
- out:
-    xfree(scon);
-    return length;
+    return rv;
 }
 
-static int flask_security_member(char *buf, uint32_t size)
+static int flask_security_create(struct xen_flask_transition *arg)
 {
-    char *scon, *tcon;
-    u32 ssid, tsid, newsid;
-    u16 tclass;
-    int length;
-    char *newcon;
-    u32 len;
+    int rv;
 
-    length = domain_has_security(current->domain, SECURITY__COMPUTE_MEMBER);
-    if ( length )
-        return length;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_CREATE);
+    if ( rv )
+        return rv;
 
-    length = -ENOMEM;
-    scon = xmalloc_array(char, size+1);
-    if ( !scon )
-        return length;
-    memset(scon, 0, size+1);
+    rv = security_transition_sid(arg->ssid, arg->tsid, arg->tclass, &arg->newsid);
 
-    tcon = xmalloc_array(char, size+1);
-    if ( !tcon )
-        goto out;
-    memset(tcon, 0, size+1);
+    return rv;
+}
 
-    length = -EINVAL;
-    if ( sscanf(buf, "%s, %s, %hu", scon, tcon, &tclass) != 3 )
-        goto out2;
+static int flask_security_access(struct xen_flask_access *arg)
+{
+    struct av_decision avd;
+    int rv;
 
-    length = security_context_to_sid(scon, strlen(scon)+1, &ssid);
-    if ( length < 0 )
-        goto out2;
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_AV);
+    if ( rv )
+        return rv;
 
-    length = security_context_to_sid(tcon, strlen(tcon)+1, &tsid);
-    if ( length < 0 )
-        goto out2;
+    rv = security_compute_av(arg->ssid, arg->tsid, arg->tclass, arg->req, &avd);
+    if ( rv < 0 )
+        return rv;
 
-    length = security_member_sid(ssid, tsid, tclass, &newsid);
-    if ( length < 0 )
-        goto out2;
+    arg->allowed = avd.allowed;
+    arg->audit_allow = avd.auditallow;
+    arg->audit_deny = avd.auditdeny;
+    arg->seqno = avd.seqno;
+                
+    return rv;
+}
 
-    length = security_sid_to_context(newsid, &newcon, &len);
-    if ( length < 0 )
-        goto out2;
+static int flask_security_member(struct xen_flask_transition *arg)
+{
+    int rv;
 
-    if ( len > size )
-    {
-        printk("%s:  context size (%u) exceeds payload "
-               "max\n", __FUNCTION__, len);
-        length = -ERANGE;
-        goto out3;
-    }
+    rv = domain_has_security(current->domain, SECURITY__COMPUTE_MEMBER);
+    if ( rv )
+        return rv;
 
-    memset(buf, 0, size);
-    memcpy(buf, newcon, len);
-    length = len;
+    rv = security_member_sid(arg->ssid, arg->tsid, arg->tclass, &arg->newsid);
 
- out3:
-    xfree(newcon);
- out2:
-    xfree(tcon);
- out:
-    xfree(scon);
-    return length;
+    return rv;
 }
 
-static int flask_security_setenforce(char *buf, uint32_t count)
+static int flask_security_setenforce(struct xen_flask_setenforce *arg)
 {
-    int length;
-    int new_value;
+    int enforce = !!(arg->enforcing);
+    int rv;
 
-    if ( sscanf(buf, "%d", &new_value) != 1 )
-        return -EINVAL;
+    if ( enforce == flask_enforcing )
+        return 0;
 
-    if ( new_value != flask_enforcing )
-    {
-        length = domain_has_security(current->domain, SECURITY__SETENFORCE);
-        if ( length )
-            goto out;
-        flask_enforcing = new_value;
-        if ( flask_enforcing )
-            avc_ss_reset(0);
-    }
-    length = count;
+    rv = domain_has_security(current->domain, SECURITY__SETENFORCE);
+    if ( rv )
+        return rv;
 
- out:
-    return length;
+    flask_enforcing = enforce;
+
+    if ( flask_enforcing )
+        avc_ss_reset(0);
+
+    return 0;
 }
 
-static int flask_security_context(char *buf, uint32_t count)
+static int flask_security_context(struct xen_flask_sid_context *arg)
 {
-    u32 sid;
-    int length;
+    int rv;
+    char *buf;
 
-    length = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
-    if ( length )
-        goto out;
+    rv = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
+    if ( rv )
+        return rv;
 
-    length = security_context_to_sid(buf, count, &sid);
-    if ( length < 0 )
-        goto out;
+    rv = flask_copyin_string(arg->context, &buf, arg->size);
+    if ( rv )
+        return rv;
 
-    memset(buf, 0, count);
-    length = snprintf(buf, count, "%u", sid);
+    rv = security_context_to_sid(buf, arg->size, &arg->sid);
+    if ( rv < 0 )
+        goto out;
 
  out:
-    return length;
+    xfree(buf);
+
+    return rv;
 }
 
-static int flask_security_sid(char *buf, uint32_t count)
+static int flask_security_sid(struct xen_flask_sid_context *arg)
 {
+    int rv;
     char *context;
-    u32 sid;
     u32 len;
-    int length;
 
-    length = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
-    if ( length )
-        goto out;
+    rv = domain_has_security(current->domain, SECURITY__CHECK_CONTEXT);
+    if ( rv )
+        return rv;
 
-    if ( sscanf(buf, "%u", &sid) != 1 )
-        goto out;
+    rv = security_sid_to_context(arg->sid, &context, &len);
+    if ( rv < 0 )
+        return rv;
 
-    length = security_sid_to_context(sid, &context, &len);
-    if ( length < 0 )
-        goto out;
+    rv = 0;
 
-    if ( len > count )
-        return -ERANGE; 
+    if ( len > arg->size )
+        rv = -ERANGE;
 
-    memset(buf, 0, count);
-    memcpy(buf, context, len);
-    length = len;
+    arg->size = len;
+
+    if ( !rv && copy_to_guest(arg->context, context, len) )
+        rv = -EFAULT;
 
     xfree(context);
 
- out:
-    return length;
+    return rv;
 }
 
 int flask_disable(void)
@@ -530,229 +277,154 @@ int flask_disable(void)
     return 0;
 }
 
-static int flask_security_disable(char *buf, uint32_t count)
-{
-    int length;
-    int new_value;
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%d", &new_value) != 1 )
-        goto out;
-
-    if ( new_value )
-    {
-        length = flask_disable();
-        if ( length < 0 )
-            goto out;
-    }
-
-    length = count;
-
- out:
-    return length;
-}
-
-static int flask_security_setavc_threshold(char *buf, uint32_t count)
+static int flask_security_setavc_threshold(struct xen_flask_setavc_threshold *arg)
 {
-    int ret;
-    int new_value;
-
-    if ( sscanf(buf, "%u", &new_value) != 1 )
-    {
-        ret = -EINVAL;
-        goto out;
-    }
+    int rv = 0;
 
-    if ( new_value != avc_cache_threshold )
+    if ( arg->threshold != avc_cache_threshold )
     {
-        ret = domain_has_security(current->domain, SECURITY__SETSECPARAM);
-        if ( ret )
+        rv = domain_has_security(current->domain, SECURITY__SETSECPARAM);
+        if ( rv )
             goto out;
-        avc_cache_threshold = new_value;
+        avc_cache_threshold = arg->threshold;
     }
-    ret = count;
 
  out:
-    return ret;
+    return rv;
 }
 
-static int flask_security_set_bool(char *buf, uint32_t count)
+static int flask_security_resolve_bool(struct xen_flask_boolean *arg)
 {
-    int length = -EFAULT;
-    unsigned int i, new_value;
-
-    spin_lock(&sel_sem);
-
-    length = domain_has_security(current->domain, SECURITY__SETBOOL);
-    if ( length )
-        goto out;
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%d %d", &i, &new_value) != 2 )
-        goto out;
+    char *name;
+    int rv;
 
-    if (!bool_pending_values)
-        flask_security_make_bools();
+    if ( arg->bool_id != -1 )
+        return 0;
 
-    if ( i >= bool_num )
-        goto out;
+    rv = flask_copyin_string(arg->name, &name, arg->size);
+    if ( rv )
+        return rv;
 
-    if ( new_value )
-        new_value = 1;
+    arg->bool_id = security_find_bool(name);
+    arg->size = 0;
 
-    bool_pending_values[i] = new_value;
-    length = count;
+    xfree(name);
 
- out:
-    spin_unlock(&sel_sem);
-    return length;
+    return 0;
 }
 
-static int flask_security_set_bool_name(char *buf, uint32_t count)
+static int flask_security_set_bool(struct xen_flask_boolean *arg)
 {
-    int rv, num;
-    int i, new_value, commit;
-    int *values = NULL;
-    char *name;
-    
-    name = xmalloc_bytes(count);
-    if ( name == NULL )
-        return -ENOMEM;
+    int rv;
 
-    spin_lock(&sel_sem);
+    rv = flask_security_resolve_bool(arg);
+    if ( rv )
+        return rv;
 
     rv = domain_has_security(current->domain, SECURITY__SETBOOL);
     if ( rv )
-        goto out;
-    
-    rv = -EINVAL;
-    if ( sscanf(buf, "%s %d %d", name, &new_value, &commit) != 3 )
-        goto out;
+        return rv;
 
-    i = security_find_bool(name);
-    if ( i < 0 )
-        goto out;
+    spin_lock(&sel_sem);
 
-    if ( new_value )
-        new_value = 1;
+    if ( arg->commit )
+    {
+        int num;
+        int *values;
 
-    if ( commit ) {
         rv = security_get_bools(&num, NULL, &values);
         if ( rv != 0 )
             goto out;
-        values[i] = new_value;
-        if (bool_pending_values)
-            bool_pending_values[i] = new_value;
+
+        if ( arg->bool_id >= num )
+        {
+            rv = -ENOENT;
+            goto out;
+        }
+        values[arg->bool_id] = !!(arg->new_value);
+
+        arg->enforcing = arg->pending = !!(arg->new_value);
+
+        if ( bool_pending_values )
+            bool_pending_values[arg->bool_id] = !!(arg->new_value);
+
         rv = security_set_bools(num, values);
         xfree(values);
-    } else {
-        if (!bool_pending_values)
+    }
+    else
+    {
+        if ( !bool_pending_values )
             flask_security_make_bools();
 
-        bool_pending_values[i] = new_value;
-        rv = count;
+        if ( arg->bool_id >= bool_num )
+            goto out;
+
+        bool_pending_values[arg->bool_id] = !!(arg->new_value);
+        arg->pending = !!(arg->new_value);
+        arg->enforcing = security_get_bool_value(arg->bool_id);
+
+        rv = 0;
     }
 
  out:
-    xfree(name);
     spin_unlock(&sel_sem);
     return rv;
 }
 
-static int flask_security_commit_bools(char *buf, uint32_t count)
+static int flask_security_commit_bools(void)
 {
-    int length = -EFAULT;
-    int new_value;
+    int rv;
 
     spin_lock(&sel_sem);
 
-    length = domain_has_security(current->domain, SECURITY__SETBOOL);
-    if ( length )
-        goto out;
-
-    length = -EINVAL;
-    if ( sscanf(buf, "%d", &new_value) != 1 )
+    rv = domain_has_security(current->domain, SECURITY__SETBOOL);
+    if ( rv )
         goto out;
 
-    if ( new_value && bool_pending_values )
-        security_set_bools(bool_num, bool_pending_values);
+    if ( bool_pending_values )
+        rv = security_set_bools(bool_num, bool_pending_values);
     
-    length = count;
-
  out:
     spin_unlock(&sel_sem);
-    return length;
+    return rv;
 }
 
-static int flask_security_get_bool(char *buf, uint32_t count, int named)
+static int flask_security_get_bool(struct xen_flask_boolean *arg)
 {
-    int length;
-    int i, cur_enforcing, pend_enforcing;
-    char* name = NULL;
-    
-    spin_lock(&sel_sem);
-    
-    length = -EINVAL;
-    if ( sscanf(buf, "%d", &i) != 1 )
-        goto out;
+    int rv;
 
-    cur_enforcing = security_get_bool_value(i);
-    if ( cur_enforcing < 0 )
-    {
-        length = cur_enforcing;
-        goto out;
-    }
+    rv = flask_security_resolve_bool(arg);
+    if ( rv )
+        return rv;
 
-    if ( bool_pending_values )
-        pend_enforcing = bool_pending_values[i];
-    else
-        pend_enforcing = cur_enforcing;
+    spin_lock(&sel_sem);
 
-    if ( named )
-        name = security_get_bool_name(i);
-    if ( named && !name )
+    rv = security_get_bool_value(arg->bool_id);
+    if ( rv < 0 )
         goto out;
 
-    memset(buf, 0, count);
-    if ( named )
-        length = snprintf(buf, count, "%d %d %s", cur_enforcing,
-                          pend_enforcing, name);
-    else
-        length = snprintf(buf, count, "%d %d", cur_enforcing,
-                          pend_enforcing);
+    arg->enforcing = rv;
 
- out:
-    xfree(name);
-    spin_unlock(&sel_sem);
-    return length;
-}
+    if ( bool_pending_values )
+        arg->pending = bool_pending_values[arg->bool_id];
+    else
+        arg->pending = rv;
 
-static int flask_security_get_bool_name(char *buf, uint32_t count)
-{
-    int rv = -ENOENT;
-    int i, cur_enforcing, pend_enforcing;
-    
-    spin_lock(&sel_sem);
-    
-    i = security_find_bool(buf);
-    if ( i < 0 )
-        goto out;
+    rv = 0;
 
-    cur_enforcing = security_get_bool_value(i);
-    if ( cur_enforcing < 0 )
+    if ( arg->size )
     {
-        rv = cur_enforcing;
-        goto out;
+        char *nameout = security_get_bool_name(arg->bool_id);
+        size_t nameout_len = strlen(nameout);
+        if ( nameout_len > arg->size )
+            rv = -ERANGE;
+        arg->size = nameout_len;
+ 
+        if ( !rv && copy_to_guest(arg->name, nameout, nameout_len) )
+            rv = -EFAULT;
+        xfree(nameout);
     }
 
-    if ( bool_pending_values )
-        pend_enforcing = bool_pending_values[i];
-    else
-        pend_enforcing = cur_enforcing;
-
-    memset(buf, 0, count);
-    rv = snprintf(buf, count, "%d %d", cur_enforcing, pend_enforcing);
-
  out:
     spin_unlock(&sel_sem);
     return rv;
@@ -779,380 +451,212 @@ static int flask_security_make_bools(void)
 
 #ifdef FLASK_AVC_STATS
 
-static int flask_security_avc_cachestats(char *buf, uint32_t count)
+static int flask_security_avc_cachestats(struct xen_flask_cache_stats *arg)
 {
-    char *page = NULL;
-    int len = 0;
-    int length = 0;
-    int cpu;
     struct avc_cache_stats *st;
 
-    page = (char *)xmalloc_bytes(PAGE_SIZE);
-    if ( !page )
-        return -ENOMEM;
-    memset(page, 0, PAGE_SIZE);
+    if ( arg->cpu > nr_cpu_ids )
+        return -ENOENT;
+    if ( !cpu_online(arg->cpu) )
+        return -ENOENT;
 
-    len = snprintf(page, PAGE_SIZE, "lookups hits misses allocations reclaims "
-                   "frees\n");
-    if ( len > count ) {
-        length = -EINVAL;
-        goto out;
-    }
-    
-    memcpy(buf, page, len);
-    buf += len;
-    length += len;
-    count -= len;
+    st = &per_cpu(avc_cache_stats, arg->cpu);
 
-    for_each_online_cpu ( cpu )
-    {
-        st = &per_cpu(avc_cache_stats, cpu);
+    arg->lookups = st->lookups;
+    arg->hits = st->hits;
+    arg->misses = st->misses;
+    arg->allocations = st->allocations;
+    arg->reclaims = st->reclaims;
+    arg->frees = st->frees;
 
-        len = snprintf(page, PAGE_SIZE, "%u %u %u %u %u %u\n", st->lookups,
-                       st->hits, st->misses, st->allocations,
-                       st->reclaims, st->frees);
-        if ( len > count ) {
-            length = -EINVAL;
-            goto out;
-        }
-        memcpy(buf, page, len);
-        buf += len;
-        length += len;
-        count -= len;
-    }
-
- out:
-    xfree(page);    
-    return length;
+    return 0;
 }
 
 #endif
 
-static int flask_security_load(char *buf, uint32_t count)
+static int flask_security_load(struct xen_flask_load *load)
 {
     int ret;
-    int length;
-
-    spin_lock(&sel_sem);
+    void *buf = NULL;
 
-    length = domain_has_security(current->domain, SECURITY__LOAD_POLICY);
-    if ( length )
-        goto out;
-
-    length = security_load_policy(buf, count);
-    if ( length )
-        goto out;
-
-    ret = flask_security_make_bools();
+    ret = domain_has_security(current->domain, SECURITY__LOAD_POLICY);
     if ( ret )
-        length = ret;
-    else
-        length = count;
+        return ret;
 
- out:
-    spin_unlock(&sel_sem);
-    return length;
-}
-
-static int flask_ocontext_del(char *buf, uint32_t size)
-{
-    int len = 0;
-    char *ocontext;
-    unsigned long low  = 0;
-    unsigned long high = 0;
-
-    len = domain_has_security(current->domain, SECURITY__DEL_OCONTEXT);
-    if ( len )
-        return len;
+    if ( load->size > MAX_POLICY_SIZE )
+        return -EINVAL;
 
-    if ( (ocontext = xmalloc_bytes(size) ) == NULL )
+    buf = xmalloc_bytes(load->size);
+    if ( !buf )
         return -ENOMEM;
 
-    len = sscanf(buf, "%s %lu %lu", ocontext, &low, &high);
-    if ( len < 2 )
+    if ( copy_from_guest(buf, load->buffer, load->size) )
     {
-        len = -EINVAL;
-        goto out;
+        ret = -EFAULT;
+        goto out_free;
     }
-    else if ( len == 2 )
-        high = low;
 
-    if ( low > high )
-    {
-        len = -EINVAL;
+    spin_lock(&sel_sem);
+
+    ret = security_load_policy(buf, load->size);
+    if ( ret )
         goto out;
-    }
 
-    len = security_ocontext_del(ocontext, low, high);
+    xfree(bool_pending_values);
+    bool_pending_values = NULL;
+    ret = 0;
+
  out:
-    xfree(ocontext);
-    return len;
+    spin_unlock(&sel_sem);
+ out_free:
+    xfree(buf);
+    return ret;
 }
 
-static int flask_ocontext_add(char *buf, uint32_t size)
+static int flask_ocontext_del(struct xen_flask_ocontext *arg)
 {
-    int len = 0;
-    u32 sid = 0;
-    unsigned long low  = 0;
-    unsigned long high = 0;
-    char *scontext;
-    char *ocontext;
-
-    len = domain_has_security(current->domain, SECURITY__ADD_OCONTEXT);
-    if ( len )
-        return len;
-
-    if ( (scontext = xmalloc_bytes(size) ) == NULL )
-        return -ENOMEM;
+    int rv;
 
-    if ( (ocontext = xmalloc_bytes(size) ) == NULL )
-    {
-        xfree(scontext);
-        return -ENOMEM;
-    }
-
-    memset(scontext, 0, size);
-    memset(ocontext, 0, size);
+    if ( arg->low > arg->high )
+        return -EINVAL;
 
-    len = sscanf(buf, "%s %s %lu %lu", ocontext, scontext, &low, &high);
-    if ( len < 3 )
-    {
-        len = -EINVAL;
-        goto out;
-    }
-    else if ( len == 3 )
-        high = low;
+    rv = domain_has_security(current->domain, SECURITY__DEL_OCONTEXT);
+    if ( rv )
+        return rv;
 
-    if ( low > high )
-    {
-        len = -EINVAL;
-        goto out;
-    }
-    len = security_context_to_sid(scontext, strlen(scontext)+1, &sid);
-    if ( len < 0 )
-    {
-        len = -EINVAL;
-        goto out;
-    }
-    len = security_ocontext_add(ocontext, low, high, sid);
- out:
-    xfree(ocontext);
-    xfree(scontext);
-    return len;
+    return security_ocontext_del(arg->ocon, arg->low, arg->high);
 }
 
-long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
+static int flask_ocontext_add(struct xen_flask_ocontext *arg)
 {
-    flask_op_t curop, *op = &curop;
-    int rc = 0;
-    int length = 0;
-    char *arg = NULL;
+    int rv;
 
-    if ( copy_from_guest(op, u_flask_op, 1) )
-        return -EFAULT;
-
-    if ( op->cmd > FLASK_LAST)
+    if ( arg->low > arg->high )
         return -EINVAL;
 
-    if ( op->size > MAX_POLICY_SIZE )
-        return -EINVAL;
+    rv = domain_has_security(current->domain, SECURITY__ADD_OCONTEXT);
+    if ( rv )
+        return rv;
 
-    if ( (op->buf == NULL && op->size != 0) || 
-         (op->buf != NULL && op->size == 0) )
-        return -EINVAL;
+    return security_ocontext_add(arg->ocon, arg->low, arg->high, arg->sid);
+}
 
-    arg = xmalloc_bytes(op->size + 1);
-    if ( !arg )
-        return -ENOMEM;
+long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
+{
+    xen_flask_op_t op;
+    int rv;
 
-    memset(arg, 0, op->size + 1);
+    if ( copy_from_guest(&op, u_flask_op, 1) )
+        return -EFAULT;
 
-    if ( (FLASK_COPY_IN&(1UL<<op->cmd)) && op->buf != NULL && 
-         copy_from_guest(arg, guest_handle_from_ptr(op->buf, char), op->size) )
-    {
-        rc = -EFAULT;
-        goto out;
-    }
+    if ( op.interface_version != XEN_FLASK_INTERFACE_VERSION )
+        return -ENOSYS;
 
-    switch ( op->cmd )
+    switch ( op.cmd )
     {
-
     case FLASK_LOAD:
-    {
-        length = flask_security_load(arg, op->size);
-    }
-    break;
-    
+        rv = flask_security_load(&op.u.load);
+        break;
+
     case FLASK_GETENFORCE:
-    {
-        length = snprintf(arg, op->size, "%d", flask_enforcing);
-    }
-    break;    
+        rv = flask_enforcing;
+        break;
 
     case FLASK_SETENFORCE:
-    {
-        length = flask_security_setenforce(arg, op->size);
-    }
-    break;    
+        rv = flask_security_setenforce(&op.u.enforce);
+        break;
 
     case FLASK_CONTEXT_TO_SID:
-    {
-        length = flask_security_context(arg, op->size);
-    }
-    break;    
+        rv = flask_security_context(&op.u.sid_context);
+        break;
 
     case FLASK_SID_TO_CONTEXT:
-    {
-        length = flask_security_sid(arg, op->size);
-    }
-    break; 
+        rv = flask_security_sid(&op.u.sid_context);
+        break;
 
     case FLASK_ACCESS:
-    {
-        length = flask_security_access(arg, op->size);
-    }
-    break;    
+        rv = flask_security_access(&op.u.access);
+        break;
 
     case FLASK_CREATE:
-    {
-        length = flask_security_create(arg, op->size);
-    }
-    break;    
+        rv = flask_security_create(&op.u.transition);
+        break;
 
     case FLASK_RELABEL:
-    {
-        length = flask_security_relabel(arg, op->size);
-    }
-    break;
+        rv = flask_security_relabel(&op.u.transition);
+        break;
 
     case FLASK_USER:
-    {
-        length = flask_security_user(arg, op->size);
-    }
-    break;    
+        rv = flask_security_user(&op.u.userlist);
+        break;
 
     case FLASK_POLICYVERS:
-    {
-        length = snprintf(arg, op->size, "%d", POLICYDB_VERSION_MAX);
-    }
-    break;    
+        rv = POLICYDB_VERSION_MAX;
+        break;
 
     case FLASK_GETBOOL:
-    {
-        length = flask_security_get_bool(arg, op->size, 0);
-    }
-    break;
+        rv = flask_security_get_bool(&op.u.boolean);
+        break;
 
     case FLASK_SETBOOL:
-    {
-        length = flask_security_set_bool(arg, op->size);
-    }
-    break;
+        rv = flask_security_set_bool(&op.u.boolean);
+        break;
 
     case FLASK_COMMITBOOLS:
-    {
-        length = flask_security_commit_bools(arg, op->size);
-    }
-    break;
+        rv = flask_security_commit_bools();
+        break;
 
     case FLASK_MLS:
-    {
-        length = snprintf(arg, op->size, "%d", flask_mls_enabled);
-    }
-    break;    
+        rv = flask_mls_enabled;
+        break;    
 
     case FLASK_DISABLE:
-    {
-        length = flask_security_disable(arg, op->size);
-    }
-    break;    
+        rv = flask_disable();
+        break;
 
     case FLASK_GETAVC_THRESHOLD:
-    {
-        length = snprintf(arg, op->size, "%d", avc_cache_threshold);
-    }
-    break;
+        rv = avc_cache_threshold;
+        break;
 
     case FLASK_SETAVC_THRESHOLD:
-    {
-        length = flask_security_setavc_threshold(arg, op->size);
-    }
-    break;
+        rv = flask_security_setavc_threshold(&op.u.setavc_threshold);
+        break;
 
     case FLASK_AVC_HASHSTATS:
-    {
-        length = avc_get_hash_stats(arg, op->size);
-    }
-    break;
+        rv = avc_get_hash_stats(&op.u.hash_stats);
+        break;
 
-#ifdef FLASK_AVC_STATS    
+#ifdef FLASK_AVC_STATS
     case FLASK_AVC_CACHESTATS:
-    {
-        length = flask_security_avc_cachestats(arg, op->size);
-    }
-    break;
+        rv = flask_security_avc_cachestats(&op.u.cache_stats);
+        break;
 #endif
 
     case FLASK_MEMBER:
-    {
-        length = flask_security_member(arg, op->size);
-    }
-    break;    
+        rv = flask_security_member(&op.u.transition);
+        break;
 
     case FLASK_ADD_OCONTEXT:
-    {
-        length = flask_ocontext_add(arg, op->size);
+        rv = flask_ocontext_add(&op.u.ocontext);
         break;
-    }
 
     case FLASK_DEL_OCONTEXT:
-    {
-        length = flask_ocontext_del(arg, op->size);
+        rv = flask_ocontext_del(&op.u.ocontext);
         break;
-    }
-
-    case FLASK_GETBOOL_NAMED:
-    {
-        length = flask_security_get_bool_name(arg, op->size);
-    }
-    break;
-
-    case FLASK_GETBOOL2:
-    {
-        length = flask_security_get_bool(arg, op->size, 1);
-    }
-    break;
-
-    case FLASK_SETBOOL_NAMED:
-    {
-        length = flask_security_set_bool_name(arg, op->size);
-    }
-    break;
 
     default:
-        length = -ENOSYS;
-        break;
-
+        rv = -ENOSYS;
     }
 
-    if ( length < 0 )
-    {
-        rc = length;
+    if ( rv < 0 )
         goto out;
-    }
-    
-    if ( (FLASK_COPY_OUT&(1UL<<op->cmd)) && op->buf != NULL && 
-         copy_to_guest(guest_handle_from_ptr(op->buf, char), arg, op->size) )
+
+    if ( (FLASK_COPY_OUT&(1UL<<op.cmd)) )
     {
-        rc = -EFAULT;
-        goto out;
+        if ( copy_to_guest(u_flask_op, &op, 1) )
+            rv = -EFAULT;
     }
 
-    op->size = length;
-    if ( copy_to_guest(u_flask_op, op, 1) )
-        rc = -EFAULT;
-
  out:
-    xfree(arg);
-    return rc;
+    return rv;
 }
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 8fffbb6..0f62891 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -104,7 +104,8 @@ int avc_add_callback(int (*callback)(u32 event, u32 ssid, u32 tsid,
                                     u32 ssid, u32 tsid, u16 tclass, u32 perms);
 
 /* Exported to selinuxfs */
-int avc_get_hash_stats(char *buf, uint32_t size);
+struct xen_flask_hash_stats;
+int avc_get_hash_stats(struct xen_flask_hash_stats *arg);
 extern unsigned int avc_cache_threshold;
 
 #ifdef FLASK_AVC_STATS
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 67ca6d0..348f018 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -90,8 +90,8 @@ int security_iterate_iomem_sids(unsigned long start, unsigned long end,
 int security_iterate_ioport_sids(u32 start, u32 end,
                                 security_iterate_fn fn, void *data);
 
-int security_ocontext_add(char *ocontext, unsigned long low,
+int security_ocontext_add(u32 ocontext, unsigned long low,
                            unsigned long high, u32 sid);
 
-int security_ocontext_del(char *ocontext, unsigned int low, unsigned int high);
+int security_ocontext_del(u32 ocontext, unsigned int low, unsigned int high);
 #endif /* _FLASK_SECURITY_H_ */
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 0189baf..363f586 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -2097,17 +2097,14 @@ int determine_ocontext( char *ocontext )
         return -1;
 }
 
-int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
+int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
                             ,u32 sid )
 {
     int ret = 0;
-    int ocon = 0;
     struct ocontext *c;
     struct ocontext *prev;
     struct ocontext *add;
 
-    if ( (ocon = determine_ocontext(ocontext)) < 0 )
-        return -EINVAL;
     if ( (add = xmalloc(struct ocontext)) == NULL )
         return -ENOMEM;
     memset(add, 0, sizeof(struct ocontext));
@@ -2254,15 +2251,11 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
     return ret;
 }
 
-int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
+int security_ocontext_del( u32 ocon, unsigned int low, unsigned int high )
 {
     int ret = 0;
-    int ocon = 0;
     struct ocontext *c, *before_c;
 
-    if ( (ocon = determine_ocontext(ocontext)) < 0 )
-        return -EINVAL;
-
     POLICY_WRLOCK;
     switch( ocon )
     {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpS-0000Wc-E9; Fri, 03 Feb 2012 15:13:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpR-0000UC-9I
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328281996!4965698!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5402 invoked from network); 3 Feb 2012 15:13:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 15:13:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDDni011010; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD62024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:12:58 -0500
Message-Id: <1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/4] tools/flask: remove libflask
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This library has been deprecated since July 2010; remove the in-tree
users and library.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/Makefile                    |    1 -
 tools/flask/libflask/Makefile           |   58 ----
 tools/flask/libflask/flask_op.c         |  559 -------------------------------
 tools/flask/libflask/include/libflask.h |   57 ----
 tools/flask/utils/Makefile              |   15 +-
 tools/flask/utils/get-bool.c            |    9 +-
 tools/flask/utils/getenforce.c          |    3 +-
 tools/flask/utils/label-pci.c           |   17 +-
 tools/flask/utils/loadpolicy.c          |    3 +-
 tools/flask/utils/set-bool.c            |    5 +-
 tools/flask/utils/setenforce.c          |    7 +-
 tools/libxc/xc_flask.c                  |   59 ++++
 tools/libxc/xenctrl.h                   |    3 +
 tools/python/setup.py                   |    2 +-
 tools/python/xen/lowlevel/flask/flask.c |   13 +-
 15 files changed, 94 insertions(+), 717 deletions(-)
 delete mode 100644 tools/flask/libflask/Makefile
 delete mode 100644 tools/flask/libflask/flask_op.c
 delete mode 100644 tools/flask/libflask/include/libflask.h

diff --git a/tools/flask/Makefile b/tools/flask/Makefile
index a27b265..add9035 100644
--- a/tools/flask/Makefile
+++ b/tools/flask/Makefile
@@ -2,7 +2,6 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 SUBDIRS :=
-SUBDIRS += libflask
 SUBDIRS += utils
 
 .PHONY: all clean install
diff --git a/tools/flask/libflask/Makefile b/tools/flask/libflask/Makefile
deleted file mode 100644
index 12c1c90..0000000
--- a/tools/flask/libflask/Makefile
+++ /dev/null
@@ -1,58 +0,0 @@
-MAJOR    = 1.0
-MINOR    = 0
-
-XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-SRCS       :=
-SRCS       += flask_op.c
-
-CFLAGS   += -Werror
-CFLAGS   += -fno-strict-aliasing
-CFLAGS   += -I./include $(CFLAGS_libxenctrl) $(CFLAGS_xeninclude)
-
-LIB_OBJS := $(patsubst %.c,%.o,$(SRCS))
-PIC_OBJS := $(patsubst %.c,%.opic,$(SRCS))
-
-LIB := libflask.a
-LIB += libflask.so libflask.so.$(MAJOR) libflask.so.$(MAJOR).$(MINOR)
-
-.PHONY: all
-all: build
-
-.PHONY: build
-build:
-	$(MAKE) $(LIB)
-
-.PHONY: install
-install: build
-	$(INSTALL_DIR) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_PROG) libflask.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) libflask.a $(DESTDIR)$(LIBDIR)
-	ln -sf libflask.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libflask.so.$(MAJOR)
-	ln -sf libflask.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libflask.so
-	$(INSTALL_DATA) include/libflask.h $(DESTDIR)$(INCLUDEDIR)/xen/xsm
-
-.PHONY: TAGS
-TAGS:
-	etags -t *.c *.h
-
-.PHONY: clean
-clean:
-	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) *~ $(DEPS) xen
-
-# libflask
-
-libflask.a: $(LIB_OBJS)
-	$(AR) rc $@ $^
-
-libflask.so: libflask.so.$(MAJOR)
-	ln -sf $< $@
-libflask.so.$(MAJOR): libflask.so.$(MAJOR).$(MINOR)
-	ln -sf $< $@
-
-libflask.so.$(MAJOR).$(MINOR): $(PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libflask.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LDLIBS_libxenctrl)
-
--include $(DEPS)
diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
deleted file mode 100644
index 412a05d..0000000
--- a/tools/flask/libflask/flask_op.c
+++ /dev/null
@@ -1,559 +0,0 @@
-/*
- *
- *  Authors:  Michael LeMay, <mdlemay@epoch.ncsc.mil>
- *            George Coker, <gscoker@alpha.ncsc.mil>
- *
- *  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 <unistd.h>
-#include <stdio.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <string.h>
-#include <sys/mman.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <stdlib.h>
-#include <stdint.h>
-#include <sys/ioctl.h>
-#include <libflask.h>
-
-int flask_load(xc_interface *xc_handle, char *buf, uint32_t size)
-{
-    int err;
-    flask_op_t op;
-    
-    op.cmd = FLASK_LOAD;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
-
-int flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid)
-{
-    int err;
-    flask_op_t op;
-    
-    op.cmd = FLASK_CONTEXT_TO_SID;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-    
-    sscanf(buf, "%u", sid);
-
-    return 0;
-}
-
-int flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size)
-{
-    int err;
-    flask_op_t op;
-    
-    op.cmd = FLASK_SID_TO_CONTEXT;
-    op.buf = buf;
-    op.size = size;
-    
-    snprintf(buf, size, "%u", sid);
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
-
-int flask_getenforce(xc_interface *xc_handle)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int mode;
- 
-    op.cmd = FLASK_GETENFORCE;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &mode);
-
-    return mode;
-}
-
-int flask_setenforce(xc_interface *xc_handle, int mode)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];
-    int size = 20; 
- 
-    op.cmd = FLASK_SETENFORCE;
-    op.buf = buf;
-    op.size = size;
-   
-    snprintf(buf, size, "%i", mode);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
-
-int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
-{
-    flask_op_t op;
-    char buf[255];
-    int rv;
-
-    op.cmd = FLASK_GETBOOL2;
-    op.buf = buf;
-    op.size = 255;
-
-    snprintf(buf, sizeof buf, "%i", id);
-
-    rv = xc_flask_op(xc_handle, &op);
-
-    if ( rv )
-        return rv;
-    
-    sscanf(buf, "%i %i %s", curr, pend, name);
-
-    return rv;
-}
-
-int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
-{
-    flask_op_t op;
-    char buf[255];
-    int rv;
-
-    op.cmd = FLASK_GETBOOL_NAMED;
-    op.buf = buf;
-    op.size = 255;
-
-    strncpy(buf, name, op.size);
-
-    rv = xc_flask_op(xc_handle, &op);
-
-    if ( rv )
-        return rv;
-    
-    sscanf(buf, "%i %i", curr, pend);
-
-    return rv;
-}
-
-int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
-{
-    flask_op_t op;
-    char buf[255];
-    int size = 255;
-
-    op.cmd = FLASK_SETBOOL_NAMED;
-    op.buf = buf;
-    op.size = size;
-
-    snprintf(buf, size, "%s %i %i", name, value, commit);
-
-    return xc_flask_op(xc_handle, &op);
-}
-
-int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *pirq_s = OCON_PIRQ_STR;
-    int size = INITCONTEXTLEN + strlen(pirq_s) + (sizeof(unsigned int)) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %u", pirq_s, scontext, pirq);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                      char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *ioport = OCON_IOPORT_STR;
-    int size = INITCONTEXTLEN + strlen(ioport) +
-                (sizeof(unsigned long) * 2) + (sizeof(char) * 4);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %lu %lu", ioport, scontext, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_add_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                     char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *iomem = OCON_IOMEM_STR;
-    int size = INITCONTEXTLEN + strlen(iomem) +
-                (sizeof(unsigned long) * 2) + (sizeof(char) * 4);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %lu %lu", iomem, scontext, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_add_device(xc_interface *xc_handle, unsigned long device, char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *dev = OCON_DEVICE_STR;
-    int size = INITCONTEXTLEN + strlen(dev) + (sizeof(unsigned long)) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %lu", dev, scontext, device);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_pirq(xc_interface *xc_handle, unsigned int pirq)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *pirq_s = OCON_PIRQ_STR;
-    int size = strlen(pirq_s) + (sizeof(unsigned int)) +
-                (sizeof(char) * 2);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %u", pirq_s, pirq);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *ioport = OCON_IOPORT_STR;
-    int size = strlen(ioport) + (sizeof(unsigned long) * 2) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %lu %lu", ioport, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *iomem = OCON_IOMEM_STR;
-    int size = strlen(iomem) + (sizeof(unsigned long) * 2) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %lu %lu", iomem, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_device(xc_interface *xc_handle, unsigned long device)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *dev = OCON_DEVICE_STR;
-    int size = strlen(dev) + (sizeof(unsigned long)) + (sizeof(char) * 2);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %lu", dev, device);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
-                u_int16_t tclass, u_int32_t req,
-                u_int32_t *allowed, u_int32_t *decided,
-                u_int32_t *auditallow, u_int32_t *auditdeny,
-                u_int32_t *seqno)
-{
-/* maximum number of digits in a 16-bit decimal number: */
-#define MAX_SHORT_DEC_LEN 5
-
-    char *buf;
-    int bufLen;
-    int err;
-    flask_op_t op;
-    u_int32_t dummy_allowed;
-    u_int32_t dummy_decided;
-    u_int32_t dummy_auditallow;
-    u_int32_t dummy_auditdeny;
-    u_int32_t dummy_seqno;
-  
-    if (!allowed)
-        allowed = &dummy_allowed;
-    if (!decided)
-        decided = &dummy_decided;
-    if (!auditallow)
-        auditallow = &dummy_auditallow;
-    if (!auditdeny)
-        auditdeny = &dummy_auditdeny;
-    if (!seqno)
-        seqno = &dummy_seqno;
-
-    if (!scon)
-        return -EINVAL;
-    if (!tcon)
-        return -EINVAL;
-
-    bufLen = strlen(scon) + 1 + strlen(tcon) + 1 +
-        MAX_SHORT_DEC_LEN + 1 +
-        sizeof(req)*2 + 1;
-    buf = malloc(bufLen);
-    snprintf(buf, bufLen, "%s %s %hu %x", scon, tcon, tclass, req);
-
-    op.cmd = FLASK_ACCESS;
-    op.buf = buf;
-    op.size = strlen(buf)+1;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-   
-    if (sscanf(op.buf, "%x %x %x %x %u",
-               allowed, decided,
-               auditallow, auditdeny,
-               seqno) != 5) {
-        err = -EILSEQ;
-    }
-
-    err = ((*allowed & req) == req)? 0 : -EPERM;
-
-    return err;
-
-}
-
-int flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size)
-{
-    int err;
-    flask_op_t op;
-  
-    op.cmd = FLASK_AVC_HASHSTATS;
-    op.buf = buf;
-    op.size = size;
-  
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    return 0;
-}
-
-int flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size)
-{
-    int err;
-    flask_op_t op;
-  
-    op.cmd = FLASK_AVC_CACHESTATS;
-    op.buf = buf;
-    op.size = size;
-  
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    return 0;
-}
-
-int flask_policyvers(xc_interface *xc_handle, char *buf, int size)
-{
-    int err;
-    flask_op_t op;
-  
-    op.cmd = FLASK_POLICYVERS;
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    return 0;
-}
-
-int flask_getavc_threshold(xc_interface *xc_handle)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int threshold;
- 
-    op.cmd = FLASK_GETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &threshold);
-
-    return threshold;
-}
-
-int flask_setavc_threshold(xc_interface *xc_handle, int threshold)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
- 
-    op.cmd = FLASK_SETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
-
-    snprintf(buf, size, "%i", threshold);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
diff --git a/tools/flask/libflask/include/libflask.h b/tools/flask/libflask/include/libflask.h
deleted file mode 100644
index b8a6ca9..0000000
--- a/tools/flask/libflask/include/libflask.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- *
- *  Authors:  Michael LeMay, <mdlemay@epoch.ncsc.mil>
- *            George Coker, <gscoker@alpha.ncsc.mil>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2,
- *  as published by the Free Software Foundation.
- */
-
-#ifndef __LIBFLASK_H__
-#define __LIBFLASK_H__
-
-#include <stdint.h>
-#include <xen/xen.h>
-#include <xen/xsm/flask_op.h>
-#include <xenctrl.h>
-
-int flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
-int flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
-int flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);
-int flask_getenforce(xc_interface *xc_handle);
-int flask_setenforce(xc_interface *xc_handle, int mode);
-int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend);
-int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend);
-int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit);
-int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext);
-int flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                      char *scontext);
-int flask_add_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                     char *scontext);
-int flask_add_device(xc_interface *xc_handle, unsigned long device, char *scontext);
-int flask_del_pirq(xc_interface *xc_handle, unsigned int pirq);
-int flask_del_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high);
-int flask_del_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high);
-int flask_del_device(xc_interface *xc_handle, unsigned long device);
-int flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
-                  u_int16_t tclass, u_int32_t req,
-                  u_int32_t *allowed, u_int32_t *decided,
-                  u_int32_t *auditallow, u_int32_t *auditdeny,
-                  u_int32_t *seqno);
-int flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size);
-int flask_policyvers(xc_interface *xc_handle, char *buf, int size);
-int flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
-int flask_getavc_threshold(xc_interface *xc_handle);
-int flask_setavc_threshold(xc_interface *xc_handle, int threshold);
-#define flask_add_single_ioport(x, l, s) flask_add_ioport(x, l, l, s)
-#define flask_add_single_iomem(x, l, s) flask_add_iomem(x, l, l, s)
-#define flask_del_single_ioport(x, l) flask_del_ioport(x, l, l)
-#define flask_del_single_iomem(x, l) flask_del_iomem(x, l, l);
-
-#define OCON_PIRQ_STR   "pirq"
-#define OCON_IOPORT_STR "ioport"
-#define OCON_IOMEM_STR  "iomem"
-#define OCON_DEVICE_STR "pcidevice"
-#define INITCONTEXTLEN  256
-#endif /* __LIBFLASK_H__ */
diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index 3ac6ac2..458f9aa 100644
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -1,11 +1,8 @@
 XEN_ROOT=$(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-LIBFLASK_ROOT = $(XEN_ROOT)/tools/flask/libflask
-
 CFLAGS += -Wall -g -Werror
 CFLAGS += $(CFLAGS_libxenctrl)
-CFLAGS += -I$(LIBFLASK_ROOT)/include
 
 TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
@@ -19,22 +16,22 @@ CLIENTS_OBJS := $(patsubst flask-%,%.o,$(CLIENTS))
 all: $(CLIENTS)
 
 flask-loadpolicy: loadpolicy.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-setenforce: setenforce.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-getenforce: getenforce.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-label-pci: label-pci.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-get-bool: get-bool.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-set-bool: set-bool.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 .PHONY: clean
 clean: 
diff --git a/tools/flask/utils/get-bool.c b/tools/flask/utils/get-bool.c
index c0cd7c8..7833522 100644
--- a/tools/flask/utils/get-bool.c
+++ b/tools/flask/utils/get-bool.c
@@ -16,7 +16,6 @@
 #include <string.h>
 #include <unistd.h>
 #include <inttypes.h>
-#include <libflask.h>
 
 static void usage(char **argv)
 {
@@ -29,11 +28,11 @@ static int all_bools(xc_interface *xch)
 	int err = 0, i = 0, curr, pend;
 	char name[256];
 	while (1) {
-		err = flask_getbool_byid(xch, i, name, &curr, &pend);
+		err = xc_flask_getbool_byid(xch, i, name, sizeof name, &curr, &pend);
 		if (err < 0) {
 			if (errno == ENOENT)
 				return 0;
-			fprintf(stderr, "flask_getbool: Unable to get boolean #%d: %s (%d)",
+			fprintf(stderr, "xc_flask_getbool: Unable to get boolean #%d: %s (%d)",
 				i, strerror(errno), err);
 			return 2;
 		}
@@ -69,9 +68,9 @@ int main(int argc, char **argv)
 		goto done;
 	}
 
-	err = flask_getbool_byname(xch, argv[1], &curr, &pend);
+	err = xc_flask_getbool_byname(xch, argv[1], &curr, &pend);
 	if (err) {
-		fprintf(stderr, "flask_getbool: Unable to get boolean %s: %s (%d)",
+		fprintf(stderr, "xc_flask_getbool: Unable to get boolean %s: %s (%d)",
 			argv[1], strerror(errno), err);
 		err = 2;
 		goto done;
diff --git a/tools/flask/utils/getenforce.c b/tools/flask/utils/getenforce.c
index 281fc81..fedf336 100644
--- a/tools/flask/utils/getenforce.c
+++ b/tools/flask/utils/getenforce.c
@@ -16,7 +16,6 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
-#include <libflask.h>
 
 static void usage (int argCnt, const char *args[])
 {
@@ -41,7 +40,7 @@ int main (int argCnt, const char *args[])
         goto done;
     }
 
-    ret = flask_getenforce(xch);
+    ret = xc_flask_getenforce(xch);
     if ( ret < 0 )
     {
         errno = -ret;
diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index da0cb61..9ddb713 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -16,7 +16,6 @@
 #include <string.h>
 #include <unistd.h>
 #include <inttypes.h>
-#include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
 #define IORESOURCE_TYPE_BITS    0x00001f00  /* Resource type */
@@ -69,9 +68,9 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	ret = flask_add_device(xch, sbdf, argv[2]);
+	ret = xc_flask_add_device(xch, sbdf, argv[2]);
 	if (ret) {
-		fprintf(stderr, "flask_add_device: Unable to set context of PCI device %s (0x%x) to %s: %d\n",
+		fprintf(stderr, "xc_flask_add_device: Unable to set context of PCI device %s (0x%x) to %s: %d\n",
 			argv[1], sbdf, argv[2], ret);
 		err = 2;
 		goto done;
@@ -80,9 +79,9 @@ int main (int argCnt, char *argv[])
 	while (fscanf(f, "0x%"SCNx64" 0x%"SCNx64" 0x%"SCNx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
 			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
-			ret = flask_add_ioport(xch, start, end, argv[2]);
+			ret = xc_flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
+				fprintf(stderr, "xc_flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -90,9 +89,9 @@ int main (int argCnt, char *argv[])
 			start >>= 12;
 			end >>= 12;
 			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
-			ret = flask_add_iomem(xch, start, end, argv[2]);
+			ret = xc_flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
+				fprintf(stderr, "xc_flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -108,9 +107,9 @@ int main (int argCnt, char *argv[])
 	if (fscanf(f, "%" SCNu64, &start) != 1)
 		start = 0;
 	if (start) {
-		ret = flask_add_pirq(xch, start, argv[2]);
+		ret = xc_flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
+			fprintf(stderr, "xc_flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
diff --git a/tools/flask/utils/loadpolicy.c b/tools/flask/utils/loadpolicy.c
index 4e99c71..f347b97 100644
--- a/tools/flask/utils/loadpolicy.c
+++ b/tools/flask/utils/loadpolicy.c
@@ -17,7 +17,6 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
-#include <libflask.h>
 
 #define USE_MMAP
 
@@ -94,7 +93,7 @@ int main (int argCnt, const char *args[])
     }
 #endif
 
-    ret = flask_load(xch, polMemCp, info.st_size);
+    ret = xc_flask_load(xch, polMemCp, info.st_size);
     if ( ret < 0 )
     {
         errno = -ret;
diff --git a/tools/flask/utils/set-bool.c b/tools/flask/utils/set-bool.c
index cde25cd..4b847c5 100644
--- a/tools/flask/utils/set-bool.c
+++ b/tools/flask/utils/set-bool.c
@@ -16,7 +16,6 @@
 #include <string.h>
 #include <unistd.h>
 #include <inttypes.h>
-#include <libflask.h>
 
 static void usage(char **argv)
 {
@@ -56,9 +55,9 @@ int main(int argc, char **argv)
 		goto done;
 	}
 
-	err = flask_setbool(xch, argv[1], value, 1);
+	err = xc_flask_setbool(xch, argv[1], value, 1);
 	if (err) {
-		fprintf(stderr, "flask_setbool: Unable to set boolean %s=%s: %s (%d)",
+		fprintf(stderr, "xc_flask_setbool: Unable to set boolean %s=%s: %s (%d)",
 			argv[1], argv[2], strerror(errno), err);
 		err = 2;
 		goto done;
diff --git a/tools/flask/utils/setenforce.c b/tools/flask/utils/setenforce.c
index 63928bd..0a92d53 100644
--- a/tools/flask/utils/setenforce.c
+++ b/tools/flask/utils/setenforce.c
@@ -16,7 +16,6 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
-#include <libflask.h>
 
 static void usage (int argCnt, const char *args[])
 {
@@ -45,12 +44,12 @@ int main (int argCnt, const char *args[])
 
     if( strlen(args[1]) == 1 && (args[1][0] == '0' || args[1][0] == '1')){
         mode = strtol(args[1], &end, 10);
-        ret = flask_setenforce(xch, mode);
+        ret = xc_flask_setenforce(xch, mode);
     } else {
         if( strcasecmp(args[1], "enforcing") == 0 ){
-            ret = flask_setenforce(xch, 1);
+            ret = xc_flask_setenforce(xch, 1);
         } else if( strcasecmp(args[1], "permissive") == 0 ){
-            ret = flask_setenforce(xch, 0);
+            ret = xc_flask_setenforce(xch, 0);
         } else {
             usage(argCnt, args);
         }
diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 27794a8..d268098 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -151,6 +151,65 @@ int xc_flask_setenforce(xc_interface *xc_handle, int mode)
     return 0;
 }
 
+int xc_flask_getbool_byid(xc_interface *xc_handle, int id, char *name, uint32_t size, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL2;
+    op.buf = buf;
+    op.size = 255;
+
+    snprintf(buf, sizeof buf, "%i", id);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i %s", curr, pend, name);
+
+    return rv;
+}
+
+int xc_flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL_NAMED;
+    op.buf = buf;
+    op.size = 255;
+
+    strncpy(buf, name, op.size);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i", curr, pend);
+
+    return rv;
+}
+
+int xc_flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
+{
+    flask_op_t op;
+    char buf[255];
+    int size = 255;
+
+    op.cmd = FLASK_SETBOOL_NAMED;
+    op.buf = buf;
+    op.size = size;
+
+    snprintf(buf, size, "%s %i %i", name, value, commit);
+
+    return xc_flask_op(xc_handle, &op);
+}
+
 static int xc_flask_add(xc_interface *xc_handle, char *cat, char *arg, char *scontext)
 {
     char buf[512];
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index f0edde6..1e7c32b 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1957,6 +1957,9 @@ int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, u
 int xc_flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);
 int xc_flask_getenforce(xc_interface *xc_handle);
 int xc_flask_setenforce(xc_interface *xc_handle, int mode);
+int xc_flask_getbool_byid(xc_interface *xc_handle, int id, char *name, uint32_t size, int *curr, int *pend);
+int xc_flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend);
+int xc_flask_setbool(xc_interface *xc_handle, char *name, int value, int commit);
 int xc_flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext);
 int xc_flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
                       char *scontext);
diff --git a/tools/python/setup.py b/tools/python/setup.py
index 81540bc..e9061c8 100644
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -48,7 +48,7 @@ flask = Extension("flask",
                include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
                                       "../flask/libflask/include" ],
                library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
-               libraries          = [ "xenctrl", "flask" ],
+               libraries          = [ "xenctrl" ],
                depends            = [ PATH_LIBXC + "/libxenctrl.so",
                                       XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
                sources            = [ "xen/lowlevel/flask/flask.c" ])
diff --git a/tools/python/xen/lowlevel/flask/flask.c b/tools/python/xen/lowlevel/flask/flask.c
index 64e8d63..c3fcf3b 100644
--- a/tools/python/xen/lowlevel/flask/flask.c
+++ b/tools/python/xen/lowlevel/flask/flask.c
@@ -12,7 +12,6 @@
 
 #include <Python.h>
 #include <xenctrl.h>
-#include <libflask.h>
 
 #define PKG "xen.lowlevel.flask"
 #define CLS "flask"
@@ -58,7 +57,7 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_context_to_sid(xc_handle, buf, len, &sid);
+    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
         
     xc_interface_close(xc_handle);
 
@@ -92,7 +91,7 @@ static PyObject *pyflask_sid_to_context(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_sid_to_context(xc_handle, sid, ctx, ctx_len);
+    ret = xc_flask_sid_to_context(xc_handle, sid, ctx, ctx_len);
     
     xc_interface_close(xc_handle);
     
@@ -121,7 +120,7 @@ static PyObject *pyflask_load(PyObject *self, PyObject *args, PyObject *kwds)
         return PyErr_SetFromErrno(xc_error_obj);
     }
 
-    ret = flask_load(xc_handle, policy, len);
+    ret = xc_flask_load(xc_handle, policy, len);
 
     xc_interface_close(xc_handle);
 
@@ -143,7 +142,7 @@ static PyObject *pyflask_getenforce(PyObject *self)
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_getenforce(xc_handle);
+    ret = xc_flask_getenforce(xc_handle);
     
     xc_interface_close(xc_handle);
     
@@ -173,7 +172,7 @@ static PyObject *pyflask_setenforce(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_setenforce(xc_handle, mode);
+    ret = xc_flask_setenforce(xc_handle, mode);
     
     xc_interface_close(xc_handle);
     
@@ -209,7 +208,7 @@ static PyObject *pyflask_access(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_access(xc_handle, scon, tcon, tclass, req, &allowed, &decided,
+    ret = xc_flask_access(xc_handle, scon, tcon, tclass, req, &allowed, &decided,
                         &auditallow, &auditdeny, &seqno);
         
     xc_interface_close(xc_handle);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:13:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKpS-0000Wc-E9; Fri, 03 Feb 2012 15:13:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RtKpR-0000UC-9I
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:13:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328281996!4965698!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5402 invoked from network); 3 Feb 2012 15:13:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-21.messagelabs.com with SMTP;
	3 Feb 2012 15:13:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q13FDDni011010; Fri, 3 Feb 2012 15:13:14 GMT
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 q13FDD62024513; 
	Fri, 3 Feb 2012 10:13:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri,  3 Feb 2012 10:12:58 -0500
Message-Id: <1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/4] tools/flask: remove libflask
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This library has been deprecated since July 2010; remove the in-tree
users and library.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/Makefile                    |    1 -
 tools/flask/libflask/Makefile           |   58 ----
 tools/flask/libflask/flask_op.c         |  559 -------------------------------
 tools/flask/libflask/include/libflask.h |   57 ----
 tools/flask/utils/Makefile              |   15 +-
 tools/flask/utils/get-bool.c            |    9 +-
 tools/flask/utils/getenforce.c          |    3 +-
 tools/flask/utils/label-pci.c           |   17 +-
 tools/flask/utils/loadpolicy.c          |    3 +-
 tools/flask/utils/set-bool.c            |    5 +-
 tools/flask/utils/setenforce.c          |    7 +-
 tools/libxc/xc_flask.c                  |   59 ++++
 tools/libxc/xenctrl.h                   |    3 +
 tools/python/setup.py                   |    2 +-
 tools/python/xen/lowlevel/flask/flask.c |   13 +-
 15 files changed, 94 insertions(+), 717 deletions(-)
 delete mode 100644 tools/flask/libflask/Makefile
 delete mode 100644 tools/flask/libflask/flask_op.c
 delete mode 100644 tools/flask/libflask/include/libflask.h

diff --git a/tools/flask/Makefile b/tools/flask/Makefile
index a27b265..add9035 100644
--- a/tools/flask/Makefile
+++ b/tools/flask/Makefile
@@ -2,7 +2,6 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 SUBDIRS :=
-SUBDIRS += libflask
 SUBDIRS += utils
 
 .PHONY: all clean install
diff --git a/tools/flask/libflask/Makefile b/tools/flask/libflask/Makefile
deleted file mode 100644
index 12c1c90..0000000
--- a/tools/flask/libflask/Makefile
+++ /dev/null
@@ -1,58 +0,0 @@
-MAJOR    = 1.0
-MINOR    = 0
-
-XEN_ROOT = $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-SRCS       :=
-SRCS       += flask_op.c
-
-CFLAGS   += -Werror
-CFLAGS   += -fno-strict-aliasing
-CFLAGS   += -I./include $(CFLAGS_libxenctrl) $(CFLAGS_xeninclude)
-
-LIB_OBJS := $(patsubst %.c,%.o,$(SRCS))
-PIC_OBJS := $(patsubst %.c,%.opic,$(SRCS))
-
-LIB := libflask.a
-LIB += libflask.so libflask.so.$(MAJOR) libflask.so.$(MAJOR).$(MINOR)
-
-.PHONY: all
-all: build
-
-.PHONY: build
-build:
-	$(MAKE) $(LIB)
-
-.PHONY: install
-install: build
-	$(INSTALL_DIR) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_PROG) libflask.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)
-	$(INSTALL_DATA) libflask.a $(DESTDIR)$(LIBDIR)
-	ln -sf libflask.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libflask.so.$(MAJOR)
-	ln -sf libflask.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libflask.so
-	$(INSTALL_DATA) include/libflask.h $(DESTDIR)$(INCLUDEDIR)/xen/xsm
-
-.PHONY: TAGS
-TAGS:
-	etags -t *.c *.h
-
-.PHONY: clean
-clean:
-	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) *~ $(DEPS) xen
-
-# libflask
-
-libflask.a: $(LIB_OBJS)
-	$(AR) rc $@ $^
-
-libflask.so: libflask.so.$(MAJOR)
-	ln -sf $< $@
-libflask.so.$(MAJOR): libflask.so.$(MAJOR).$(MINOR)
-	ln -sf $< $@
-
-libflask.so.$(MAJOR).$(MINOR): $(PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libflask.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LDLIBS_libxenctrl)
-
--include $(DEPS)
diff --git a/tools/flask/libflask/flask_op.c b/tools/flask/libflask/flask_op.c
deleted file mode 100644
index 412a05d..0000000
--- a/tools/flask/libflask/flask_op.c
+++ /dev/null
@@ -1,559 +0,0 @@
-/*
- *
- *  Authors:  Michael LeMay, <mdlemay@epoch.ncsc.mil>
- *            George Coker, <gscoker@alpha.ncsc.mil>
- *
- *  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 <unistd.h>
-#include <stdio.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <string.h>
-#include <sys/mman.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <stdlib.h>
-#include <stdint.h>
-#include <sys/ioctl.h>
-#include <libflask.h>
-
-int flask_load(xc_interface *xc_handle, char *buf, uint32_t size)
-{
-    int err;
-    flask_op_t op;
-    
-    op.cmd = FLASK_LOAD;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
-
-int flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid)
-{
-    int err;
-    flask_op_t op;
-    
-    op.cmd = FLASK_CONTEXT_TO_SID;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-    
-    sscanf(buf, "%u", sid);
-
-    return 0;
-}
-
-int flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size)
-{
-    int err;
-    flask_op_t op;
-    
-    op.cmd = FLASK_SID_TO_CONTEXT;
-    op.buf = buf;
-    op.size = size;
-    
-    snprintf(buf, size, "%u", sid);
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
-
-int flask_getenforce(xc_interface *xc_handle)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int mode;
- 
-    op.cmd = FLASK_GETENFORCE;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &mode);
-
-    return mode;
-}
-
-int flask_setenforce(xc_interface *xc_handle, int mode)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];
-    int size = 20; 
- 
-    op.cmd = FLASK_SETENFORCE;
-    op.buf = buf;
-    op.size = size;
-   
-    snprintf(buf, size, "%i", mode);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
-
-int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend)
-{
-    flask_op_t op;
-    char buf[255];
-    int rv;
-
-    op.cmd = FLASK_GETBOOL2;
-    op.buf = buf;
-    op.size = 255;
-
-    snprintf(buf, sizeof buf, "%i", id);
-
-    rv = xc_flask_op(xc_handle, &op);
-
-    if ( rv )
-        return rv;
-    
-    sscanf(buf, "%i %i %s", curr, pend, name);
-
-    return rv;
-}
-
-int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
-{
-    flask_op_t op;
-    char buf[255];
-    int rv;
-
-    op.cmd = FLASK_GETBOOL_NAMED;
-    op.buf = buf;
-    op.size = 255;
-
-    strncpy(buf, name, op.size);
-
-    rv = xc_flask_op(xc_handle, &op);
-
-    if ( rv )
-        return rv;
-    
-    sscanf(buf, "%i %i", curr, pend);
-
-    return rv;
-}
-
-int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
-{
-    flask_op_t op;
-    char buf[255];
-    int size = 255;
-
-    op.cmd = FLASK_SETBOOL_NAMED;
-    op.buf = buf;
-    op.size = size;
-
-    snprintf(buf, size, "%s %i %i", name, value, commit);
-
-    return xc_flask_op(xc_handle, &op);
-}
-
-int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *pirq_s = OCON_PIRQ_STR;
-    int size = INITCONTEXTLEN + strlen(pirq_s) + (sizeof(unsigned int)) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %u", pirq_s, scontext, pirq);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                      char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *ioport = OCON_IOPORT_STR;
-    int size = INITCONTEXTLEN + strlen(ioport) +
-                (sizeof(unsigned long) * 2) + (sizeof(char) * 4);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %lu %lu", ioport, scontext, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_add_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                     char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *iomem = OCON_IOMEM_STR;
-    int size = INITCONTEXTLEN + strlen(iomem) +
-                (sizeof(unsigned long) * 2) + (sizeof(char) * 4);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %lu %lu", iomem, scontext, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_add_device(xc_interface *xc_handle, unsigned long device, char *scontext)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *dev = OCON_DEVICE_STR;
-    int size = INITCONTEXTLEN + strlen(dev) + (sizeof(unsigned long)) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_ADD_OCONTEXT;
-    snprintf(buf, size, "%s %255s %lu", dev, scontext, device);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_pirq(xc_interface *xc_handle, unsigned int pirq)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *pirq_s = OCON_PIRQ_STR;
-    int size = strlen(pirq_s) + (sizeof(unsigned int)) +
-                (sizeof(char) * 2);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %u", pirq_s, pirq);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *ioport = OCON_IOPORT_STR;
-    int size = strlen(ioport) + (sizeof(unsigned long) * 2) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %lu %lu", ioport, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *iomem = OCON_IOMEM_STR;
-    int size = strlen(iomem) + (sizeof(unsigned long) * 2) +
-                (sizeof(char) * 3);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %lu %lu", iomem, low, high);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_del_device(xc_interface *xc_handle, unsigned long device)
-{
-    int err;
-    flask_op_t op;
-    char *buf;
-    char *dev = OCON_DEVICE_STR;
-    int size = strlen(dev) + (sizeof(unsigned long)) + (sizeof(char) * 2);
-
-    if ( (buf = (char *) malloc(size)) == NULL )
-        return -ENOMEM;
-    memset(buf, 0, size);
-
-    op.cmd = FLASK_DEL_OCONTEXT;
-    snprintf(buf, size, "%s %lu", dev, device);
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    free(buf);
-    return 0;
-
-}
-
-int flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
-                u_int16_t tclass, u_int32_t req,
-                u_int32_t *allowed, u_int32_t *decided,
-                u_int32_t *auditallow, u_int32_t *auditdeny,
-                u_int32_t *seqno)
-{
-/* maximum number of digits in a 16-bit decimal number: */
-#define MAX_SHORT_DEC_LEN 5
-
-    char *buf;
-    int bufLen;
-    int err;
-    flask_op_t op;
-    u_int32_t dummy_allowed;
-    u_int32_t dummy_decided;
-    u_int32_t dummy_auditallow;
-    u_int32_t dummy_auditdeny;
-    u_int32_t dummy_seqno;
-  
-    if (!allowed)
-        allowed = &dummy_allowed;
-    if (!decided)
-        decided = &dummy_decided;
-    if (!auditallow)
-        auditallow = &dummy_auditallow;
-    if (!auditdeny)
-        auditdeny = &dummy_auditdeny;
-    if (!seqno)
-        seqno = &dummy_seqno;
-
-    if (!scon)
-        return -EINVAL;
-    if (!tcon)
-        return -EINVAL;
-
-    bufLen = strlen(scon) + 1 + strlen(tcon) + 1 +
-        MAX_SHORT_DEC_LEN + 1 +
-        sizeof(req)*2 + 1;
-    buf = malloc(bufLen);
-    snprintf(buf, bufLen, "%s %s %hu %x", scon, tcon, tclass, req);
-
-    op.cmd = FLASK_ACCESS;
-    op.buf = buf;
-    op.size = strlen(buf)+1;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-   
-    if (sscanf(op.buf, "%x %x %x %x %u",
-               allowed, decided,
-               auditallow, auditdeny,
-               seqno) != 5) {
-        err = -EILSEQ;
-    }
-
-    err = ((*allowed & req) == req)? 0 : -EPERM;
-
-    return err;
-
-}
-
-int flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size)
-{
-    int err;
-    flask_op_t op;
-  
-    op.cmd = FLASK_AVC_HASHSTATS;
-    op.buf = buf;
-    op.size = size;
-  
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    return 0;
-}
-
-int flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size)
-{
-    int err;
-    flask_op_t op;
-  
-    op.cmd = FLASK_AVC_CACHESTATS;
-    op.buf = buf;
-    op.size = size;
-  
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    return 0;
-}
-
-int flask_policyvers(xc_interface *xc_handle, char *buf, int size)
-{
-    int err;
-    flask_op_t op;
-  
-    op.cmd = FLASK_POLICYVERS;
-    op.buf = buf;
-    op.size = size;
-
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-    {
-        free(buf);
-        return err;
-    }
-
-    return 0;
-}
-
-int flask_getavc_threshold(xc_interface *xc_handle)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
-    int threshold;
- 
-    op.cmd = FLASK_GETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
-    
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    sscanf(buf, "%i", &threshold);
-
-    return threshold;
-}
-
-int flask_setavc_threshold(xc_interface *xc_handle, int threshold)
-{
-    int err;
-    flask_op_t op;
-    char buf[20];            
-    int size = 20;
- 
-    op.cmd = FLASK_SETAVC_THRESHOLD;
-    op.buf = buf;
-    op.size = size;
-
-    snprintf(buf, size, "%i", threshold);
- 
-    if ( (err = xc_flask_op(xc_handle, &op)) != 0 )
-        return err;
-
-    return 0;
-}
diff --git a/tools/flask/libflask/include/libflask.h b/tools/flask/libflask/include/libflask.h
deleted file mode 100644
index b8a6ca9..0000000
--- a/tools/flask/libflask/include/libflask.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- *
- *  Authors:  Michael LeMay, <mdlemay@epoch.ncsc.mil>
- *            George Coker, <gscoker@alpha.ncsc.mil>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2,
- *  as published by the Free Software Foundation.
- */
-
-#ifndef __LIBFLASK_H__
-#define __LIBFLASK_H__
-
-#include <stdint.h>
-#include <xen/xen.h>
-#include <xen/xsm/flask_op.h>
-#include <xenctrl.h>
-
-int flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
-int flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
-int flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);
-int flask_getenforce(xc_interface *xc_handle);
-int flask_setenforce(xc_interface *xc_handle, int mode);
-int flask_getbool_byid(xc_interface *xc_handle, int id, char *name, int *curr, int *pend);
-int flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend);
-int flask_setbool(xc_interface *xc_handle, char *name, int value, int commit);
-int flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext);
-int flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                      char *scontext);
-int flask_add_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high,
-                     char *scontext);
-int flask_add_device(xc_interface *xc_handle, unsigned long device, char *scontext);
-int flask_del_pirq(xc_interface *xc_handle, unsigned int pirq);
-int flask_del_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high);
-int flask_del_iomem(xc_interface *xc_handle, unsigned long low, unsigned long high);
-int flask_del_device(xc_interface *xc_handle, unsigned long device);
-int flask_access(xc_interface *xc_handle, const char *scon, const char *tcon,
-                  u_int16_t tclass, u_int32_t req,
-                  u_int32_t *allowed, u_int32_t *decided,
-                  u_int32_t *auditallow, u_int32_t *auditdeny,
-                  u_int32_t *seqno);
-int flask_avc_cachestats(xc_interface *xc_handle, char *buf, int size);
-int flask_policyvers(xc_interface *xc_handle, char *buf, int size);
-int flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
-int flask_getavc_threshold(xc_interface *xc_handle);
-int flask_setavc_threshold(xc_interface *xc_handle, int threshold);
-#define flask_add_single_ioport(x, l, s) flask_add_ioport(x, l, l, s)
-#define flask_add_single_iomem(x, l, s) flask_add_iomem(x, l, l, s)
-#define flask_del_single_ioport(x, l) flask_del_ioport(x, l, l)
-#define flask_del_single_iomem(x, l) flask_del_iomem(x, l, l);
-
-#define OCON_PIRQ_STR   "pirq"
-#define OCON_IOPORT_STR "ioport"
-#define OCON_IOMEM_STR  "iomem"
-#define OCON_DEVICE_STR "pcidevice"
-#define INITCONTEXTLEN  256
-#endif /* __LIBFLASK_H__ */
diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index 3ac6ac2..458f9aa 100644
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -1,11 +1,8 @@
 XEN_ROOT=$(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-LIBFLASK_ROOT = $(XEN_ROOT)/tools/flask/libflask
-
 CFLAGS += -Wall -g -Werror
 CFLAGS += $(CFLAGS_libxenctrl)
-CFLAGS += -I$(LIBFLASK_ROOT)/include
 
 TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
@@ -19,22 +16,22 @@ CLIENTS_OBJS := $(patsubst flask-%,%.o,$(CLIENTS))
 all: $(CLIENTS)
 
 flask-loadpolicy: loadpolicy.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-setenforce: setenforce.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-getenforce: getenforce.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-label-pci: label-pci.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-get-bool: get-bool.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 flask-set-bool: set-bool.o
-	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+	$(CC) $(LDFLAGS) $< $(LDLIBS) $(LDLIBS_libxenctrl) -o $@
 
 .PHONY: clean
 clean: 
diff --git a/tools/flask/utils/get-bool.c b/tools/flask/utils/get-bool.c
index c0cd7c8..7833522 100644
--- a/tools/flask/utils/get-bool.c
+++ b/tools/flask/utils/get-bool.c
@@ -16,7 +16,6 @@
 #include <string.h>
 #include <unistd.h>
 #include <inttypes.h>
-#include <libflask.h>
 
 static void usage(char **argv)
 {
@@ -29,11 +28,11 @@ static int all_bools(xc_interface *xch)
 	int err = 0, i = 0, curr, pend;
 	char name[256];
 	while (1) {
-		err = flask_getbool_byid(xch, i, name, &curr, &pend);
+		err = xc_flask_getbool_byid(xch, i, name, sizeof name, &curr, &pend);
 		if (err < 0) {
 			if (errno == ENOENT)
 				return 0;
-			fprintf(stderr, "flask_getbool: Unable to get boolean #%d: %s (%d)",
+			fprintf(stderr, "xc_flask_getbool: Unable to get boolean #%d: %s (%d)",
 				i, strerror(errno), err);
 			return 2;
 		}
@@ -69,9 +68,9 @@ int main(int argc, char **argv)
 		goto done;
 	}
 
-	err = flask_getbool_byname(xch, argv[1], &curr, &pend);
+	err = xc_flask_getbool_byname(xch, argv[1], &curr, &pend);
 	if (err) {
-		fprintf(stderr, "flask_getbool: Unable to get boolean %s: %s (%d)",
+		fprintf(stderr, "xc_flask_getbool: Unable to get boolean %s: %s (%d)",
 			argv[1], strerror(errno), err);
 		err = 2;
 		goto done;
diff --git a/tools/flask/utils/getenforce.c b/tools/flask/utils/getenforce.c
index 281fc81..fedf336 100644
--- a/tools/flask/utils/getenforce.c
+++ b/tools/flask/utils/getenforce.c
@@ -16,7 +16,6 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
-#include <libflask.h>
 
 static void usage (int argCnt, const char *args[])
 {
@@ -41,7 +40,7 @@ int main (int argCnt, const char *args[])
         goto done;
     }
 
-    ret = flask_getenforce(xch);
+    ret = xc_flask_getenforce(xch);
     if ( ret < 0 )
     {
         errno = -ret;
diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
index da0cb61..9ddb713 100644
--- a/tools/flask/utils/label-pci.c
+++ b/tools/flask/utils/label-pci.c
@@ -16,7 +16,6 @@
 #include <string.h>
 #include <unistd.h>
 #include <inttypes.h>
-#include <libflask.h>
 
 /* Pulled from linux/include/linux/ioport.h */
 #define IORESOURCE_TYPE_BITS    0x00001f00  /* Resource type */
@@ -69,9 +68,9 @@ int main (int argCnt, char *argv[])
 		goto done;
 	}
 
-	ret = flask_add_device(xch, sbdf, argv[2]);
+	ret = xc_flask_add_device(xch, sbdf, argv[2]);
 	if (ret) {
-		fprintf(stderr, "flask_add_device: Unable to set context of PCI device %s (0x%x) to %s: %d\n",
+		fprintf(stderr, "xc_flask_add_device: Unable to set context of PCI device %s (0x%x) to %s: %d\n",
 			argv[1], sbdf, argv[2], ret);
 		err = 2;
 		goto done;
@@ -80,9 +79,9 @@ int main (int argCnt, char *argv[])
 	while (fscanf(f, "0x%"SCNx64" 0x%"SCNx64" 0x%"SCNx64"\n", &start, &end, &flags) == 3) {
 		if (flags & IORESOURCE_IO) {
 			// printf("Port %"PRIx64"-%"PRIx64"\n", start, end);
-			ret = flask_add_ioport(xch, start, end, argv[2]);
+			ret = xc_flask_add_ioport(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
+				fprintf(stderr, "xc_flask_add_ioport %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -90,9 +89,9 @@ int main (int argCnt, char *argv[])
 			start >>= 12;
 			end >>= 12;
 			// printf("IOMEM %"PRIx64"-%"PRIx64"\n", start, end);
-			ret = flask_add_iomem(xch, start, end, argv[2]);
+			ret = xc_flask_add_iomem(xch, start, end, argv[2]);
 			if (ret) {
-				fprintf(stderr, "flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
+				fprintf(stderr, "xc_flask_add_iomem %"PRIx64"-%"PRIx64" failed: %d\n",
 						start, end, ret);
 				err = 2;
 			}
@@ -108,9 +107,9 @@ int main (int argCnt, char *argv[])
 	if (fscanf(f, "%" SCNu64, &start) != 1)
 		start = 0;
 	if (start) {
-		ret = flask_add_pirq(xch, start, argv[2]);
+		ret = xc_flask_add_pirq(xch, start, argv[2]);
 		if (ret) {
-			fprintf(stderr, "flask_add_pirq %"PRIu64" failed: %d\n",
+			fprintf(stderr, "xc_flask_add_pirq %"PRIu64" failed: %d\n",
 					start, ret);
 			err = 2;
 		}
diff --git a/tools/flask/utils/loadpolicy.c b/tools/flask/utils/loadpolicy.c
index 4e99c71..f347b97 100644
--- a/tools/flask/utils/loadpolicy.c
+++ b/tools/flask/utils/loadpolicy.c
@@ -17,7 +17,6 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
-#include <libflask.h>
 
 #define USE_MMAP
 
@@ -94,7 +93,7 @@ int main (int argCnt, const char *args[])
     }
 #endif
 
-    ret = flask_load(xch, polMemCp, info.st_size);
+    ret = xc_flask_load(xch, polMemCp, info.st_size);
     if ( ret < 0 )
     {
         errno = -ret;
diff --git a/tools/flask/utils/set-bool.c b/tools/flask/utils/set-bool.c
index cde25cd..4b847c5 100644
--- a/tools/flask/utils/set-bool.c
+++ b/tools/flask/utils/set-bool.c
@@ -16,7 +16,6 @@
 #include <string.h>
 #include <unistd.h>
 #include <inttypes.h>
-#include <libflask.h>
 
 static void usage(char **argv)
 {
@@ -56,9 +55,9 @@ int main(int argc, char **argv)
 		goto done;
 	}
 
-	err = flask_setbool(xch, argv[1], value, 1);
+	err = xc_flask_setbool(xch, argv[1], value, 1);
 	if (err) {
-		fprintf(stderr, "flask_setbool: Unable to set boolean %s=%s: %s (%d)",
+		fprintf(stderr, "xc_flask_setbool: Unable to set boolean %s=%s: %s (%d)",
 			argv[1], argv[2], strerror(errno), err);
 		err = 2;
 		goto done;
diff --git a/tools/flask/utils/setenforce.c b/tools/flask/utils/setenforce.c
index 63928bd..0a92d53 100644
--- a/tools/flask/utils/setenforce.c
+++ b/tools/flask/utils/setenforce.c
@@ -16,7 +16,6 @@
 #include <sys/stat.h>
 #include <string.h>
 #include <unistd.h>
-#include <libflask.h>
 
 static void usage (int argCnt, const char *args[])
 {
@@ -45,12 +44,12 @@ int main (int argCnt, const char *args[])
 
     if( strlen(args[1]) == 1 && (args[1][0] == '0' || args[1][0] == '1')){
         mode = strtol(args[1], &end, 10);
-        ret = flask_setenforce(xch, mode);
+        ret = xc_flask_setenforce(xch, mode);
     } else {
         if( strcasecmp(args[1], "enforcing") == 0 ){
-            ret = flask_setenforce(xch, 1);
+            ret = xc_flask_setenforce(xch, 1);
         } else if( strcasecmp(args[1], "permissive") == 0 ){
-            ret = flask_setenforce(xch, 0);
+            ret = xc_flask_setenforce(xch, 0);
         } else {
             usage(argCnt, args);
         }
diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 27794a8..d268098 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -151,6 +151,65 @@ int xc_flask_setenforce(xc_interface *xc_handle, int mode)
     return 0;
 }
 
+int xc_flask_getbool_byid(xc_interface *xc_handle, int id, char *name, uint32_t size, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL2;
+    op.buf = buf;
+    op.size = 255;
+
+    snprintf(buf, sizeof buf, "%i", id);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i %s", curr, pend, name);
+
+    return rv;
+}
+
+int xc_flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend)
+{
+    flask_op_t op;
+    char buf[255];
+    int rv;
+
+    op.cmd = FLASK_GETBOOL_NAMED;
+    op.buf = buf;
+    op.size = 255;
+
+    strncpy(buf, name, op.size);
+
+    rv = xc_flask_op(xc_handle, &op);
+
+    if ( rv )
+        return rv;
+    
+    sscanf(buf, "%i %i", curr, pend);
+
+    return rv;
+}
+
+int xc_flask_setbool(xc_interface *xc_handle, char *name, int value, int commit)
+{
+    flask_op_t op;
+    char buf[255];
+    int size = 255;
+
+    op.cmd = FLASK_SETBOOL_NAMED;
+    op.buf = buf;
+    op.size = size;
+
+    snprintf(buf, size, "%s %i %i", name, value, commit);
+
+    return xc_flask_op(xc_handle, &op);
+}
+
 static int xc_flask_add(xc_interface *xc_handle, char *cat, char *arg, char *scontext)
 {
     char buf[512];
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index f0edde6..1e7c32b 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1957,6 +1957,9 @@ int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, u
 int xc_flask_sid_to_context(xc_interface *xc_handle, int sid, char *buf, uint32_t size);
 int xc_flask_getenforce(xc_interface *xc_handle);
 int xc_flask_setenforce(xc_interface *xc_handle, int mode);
+int xc_flask_getbool_byid(xc_interface *xc_handle, int id, char *name, uint32_t size, int *curr, int *pend);
+int xc_flask_getbool_byname(xc_interface *xc_handle, char *name, int *curr, int *pend);
+int xc_flask_setbool(xc_interface *xc_handle, char *name, int value, int commit);
 int xc_flask_add_pirq(xc_interface *xc_handle, unsigned int pirq, char *scontext);
 int xc_flask_add_ioport(xc_interface *xc_handle, unsigned long low, unsigned long high,
                       char *scontext);
diff --git a/tools/python/setup.py b/tools/python/setup.py
index 81540bc..e9061c8 100644
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -48,7 +48,7 @@ flask = Extension("flask",
                include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
                                       "../flask/libflask/include" ],
                library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
-               libraries          = [ "xenctrl", "flask" ],
+               libraries          = [ "xenctrl" ],
                depends            = [ PATH_LIBXC + "/libxenctrl.so",
                                       XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
                sources            = [ "xen/lowlevel/flask/flask.c" ])
diff --git a/tools/python/xen/lowlevel/flask/flask.c b/tools/python/xen/lowlevel/flask/flask.c
index 64e8d63..c3fcf3b 100644
--- a/tools/python/xen/lowlevel/flask/flask.c
+++ b/tools/python/xen/lowlevel/flask/flask.c
@@ -12,7 +12,6 @@
 
 #include <Python.h>
 #include <xenctrl.h>
-#include <libflask.h>
 
 #define PKG "xen.lowlevel.flask"
 #define CLS "flask"
@@ -58,7 +57,7 @@ static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_context_to_sid(xc_handle, buf, len, &sid);
+    ret = xc_flask_context_to_sid(xc_handle, buf, len, &sid);
         
     xc_interface_close(xc_handle);
 
@@ -92,7 +91,7 @@ static PyObject *pyflask_sid_to_context(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_sid_to_context(xc_handle, sid, ctx, ctx_len);
+    ret = xc_flask_sid_to_context(xc_handle, sid, ctx, ctx_len);
     
     xc_interface_close(xc_handle);
     
@@ -121,7 +120,7 @@ static PyObject *pyflask_load(PyObject *self, PyObject *args, PyObject *kwds)
         return PyErr_SetFromErrno(xc_error_obj);
     }
 
-    ret = flask_load(xc_handle, policy, len);
+    ret = xc_flask_load(xc_handle, policy, len);
 
     xc_interface_close(xc_handle);
 
@@ -143,7 +142,7 @@ static PyObject *pyflask_getenforce(PyObject *self)
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_getenforce(xc_handle);
+    ret = xc_flask_getenforce(xc_handle);
     
     xc_interface_close(xc_handle);
     
@@ -173,7 +172,7 @@ static PyObject *pyflask_setenforce(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_setenforce(xc_handle, mode);
+    ret = xc_flask_setenforce(xc_handle, mode);
     
     xc_interface_close(xc_handle);
     
@@ -209,7 +208,7 @@ static PyObject *pyflask_access(PyObject *self, PyObject *args,
         return PyErr_SetFromErrno(xc_error_obj);
     }
     
-    ret = flask_access(xc_handle, scon, tcon, tclass, req, &allowed, &decided,
+    ret = xc_flask_access(xc_handle, scon, tcon, tclass, req, &allowed, &decided,
                         &auditallow, &auditdeny, &seqno);
         
     xc_interface_close(xc_handle);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:20:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKvU-0001Lx-Kh; Fri, 03 Feb 2012 15:19:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtKvT-0001LI-5T
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:19:47 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328282379!10044175!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2455 invoked from network); 3 Feb 2012 15:19:40 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 15:19:40 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
Thread-Index: AQHM4nh5cktTzJ95FkaSaySuJubVe5YruRGAgAAA4oCAAATygA==
Date: Fri, 3 Feb 2012 15:19:37 +0000
Message-ID: <33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
In-Reply-To: <4F2C04F50200007800071056@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <588067665D2FEA4DA8590415C948A073@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 8:01 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 15:58, Justin Gibbs <justing@spectralogic.com> wrote:
>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>> 
>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>>> @@ -187,6 +216,25 @@
>>>> *      The machine ABI rules governing the format of all ring request and
>>>> *      response structures.
>>>> *
>>>> + * ring-page-order
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  0
>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>> 
>>> Why not just max-ring-page-order. After all, the value is meaningless
>>> for a backend that only exposes max-ring-pages.
>>> 
>>>> + *      Notes:          1, 3
>>>> + *
>>>> + *      The size of the frontend allocated request ring buffer in units
>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>>> + *      etc.).
>>>> + *
>>>> + * ring-pages
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  1
>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>> 
>>> Similarly here - just max-ring-pages should do.
>> 
>> This patch documents existing extensions.  For a new driver to properly 
>> negotiate a
>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest 
>> (ring-page-order),
>> you must use the XenBus node names as I've defined them here.
> 
> That wasn't my point. I was exclusively asking the maximum values to
> get simplified.
> 
> Jan

I see now.  Sorry for misunderstanding.

In the introduction section, you'll see this text:

 * Any specified default value is in effect if the corresponding XenBus node
 * is not present in the XenStore.

This drastically simplified (shortened) a spec that is already quite long.  However,
if this is the rule, both types of "max ring size" values are "in effect" even if a back-end
does not provide them both.  So how do you resolve the conflict?  A fully interoperable
front should allocate the largest possible ring and advertise that size through both
mechanisms in a fully consistent manner. That's what I was trying to indicate by
writing the spec this way.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:20:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:20:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtKvU-0001Lx-Kh; Fri, 03 Feb 2012 15:19:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtKvT-0001LI-5T
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:19:47 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328282379!10044175!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2455 invoked from network); 3 Feb 2012 15:19:40 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 15:19:40 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
Thread-Index: AQHM4nh5cktTzJ95FkaSaySuJubVe5YruRGAgAAA4oCAAATygA==
Date: Fri, 3 Feb 2012 15:19:37 +0000
Message-ID: <33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
In-Reply-To: <4F2C04F50200007800071056@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <588067665D2FEA4DA8590415C948A073@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 8:01 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 15:58, Justin Gibbs <justing@spectralogic.com> wrote:
>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>> 
>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>>> @@ -187,6 +216,25 @@
>>>> *      The machine ABI rules governing the format of all ring request and
>>>> *      response structures.
>>>> *
>>>> + * ring-page-order
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  0
>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>> 
>>> Why not just max-ring-page-order. After all, the value is meaningless
>>> for a backend that only exposes max-ring-pages.
>>> 
>>>> + *      Notes:          1, 3
>>>> + *
>>>> + *      The size of the frontend allocated request ring buffer in units
>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>>> + *      etc.).
>>>> + *
>>>> + * ring-pages
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  1
>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>> 
>>> Similarly here - just max-ring-pages should do.
>> 
>> This patch documents existing extensions.  For a new driver to properly 
>> negotiate a
>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest 
>> (ring-page-order),
>> you must use the XenBus node names as I've defined them here.
> 
> That wasn't my point. I was exclusively asking the maximum values to
> get simplified.
> 
> Jan

I see now.  Sorry for misunderstanding.

In the introduction section, you'll see this text:

 * Any specified default value is in effect if the corresponding XenBus node
 * is not present in the XenStore.

This drastically simplified (shortened) a spec that is already quite long.  However,
if this is the rule, both types of "max ring size" values are "in effect" even if a back-end
does not provide them both.  So how do you resolve the conflict?  A fully interoperable
front should allocate the largest possible ring and advertise that size through both
mechanisms in a fully consistent manner. That's what I was trying to indicate by
writing the spec this way.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:27:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtL2h-00023u-Dw; Fri, 03 Feb 2012 15:27:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RtL2f-00023h-MJ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:27:13 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328282826!13326297!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23300 invoked from network); 3 Feb 2012 15:27:07 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 15:27:07 -0000
Received: from mail52-ch1-R.bigfish.com (10.43.68.229) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 15:27:03 +0000
Received: from mail52-ch1 (localhost [127.0.0.1])	by mail52-ch1-R.bigfish.com
	(Postfix) with ESMTP id 981883E0610;
	Fri,  3 Feb 2012 15:27:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail52-ch1 (localhost.localdomain [127.0.0.1]) by mail52-ch1
	(MessageSwitch) id 1328282824157078_32695;
	Fri,  3 Feb 2012 15:27:04 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.227])	by mail52-ch1.bigfish.com (Postfix) with ESMTP id
	20C372C0045;	Fri,  3 Feb 2012 15:27:04 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 15:26:59 +0000
X-WSS-ID: 0LYTPKZ-02-38J-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 29044C8011;	Fri,  3 Feb 2012 09:26:58 -0600 (CST)
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, 3 Feb 2012 09:27:18 -0600
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.289.1;
	Fri, 3 Feb 2012 09:26:59 -0600
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, 3 Feb 2012
	10:26:55 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E979B49C0F1; Fri,  3 Feb 2012
	15:26:53 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D26EA5940FF; Fri,  3 Feb 2012
	16:26:53 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 58a2281581a4c4171ca52549b3e8062b9733ec2b
Message-ID: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 3 Feb 2012 16:29:11 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Campbell@citrix.com>,
	<Ian.Jackson@eu.citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] amd iommu: Fix a return value of
	guest_iommu_set_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328282938 -3600
# Node ID 58a2281581a4c4171ca52549b3e8062b9733ec2b
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
amd iommu: Fix a return value of guest_iommu_set_base()
Remove a unnecessary check in guest_iommu_destroy()

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3432abcf9380 -r 58a2281581a4 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 03 16:28:58 2012 +0100
@@ -806,7 +806,7 @@ int guest_iommu_set_base(struct domain *
     struct guest_iommu *iommu = domain_iommu(d);
 
     if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return 0;
+        return -EACCES;
 
     if ( !iommu )
         return -EACCES;
@@ -896,9 +896,6 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return;
-
     iommu = domain_iommu(d);
     if ( !iommu )
         return;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:27:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtL2h-00023u-Dw; Fri, 03 Feb 2012 15:27:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RtL2f-00023h-MJ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:27:13 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328282826!13326297!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23300 invoked from network); 3 Feb 2012 15:27:07 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 15:27:07 -0000
Received: from mail52-ch1-R.bigfish.com (10.43.68.229) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 15:27:03 +0000
Received: from mail52-ch1 (localhost [127.0.0.1])	by mail52-ch1-R.bigfish.com
	(Postfix) with ESMTP id 981883E0610;
	Fri,  3 Feb 2012 15:27:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail52-ch1 (localhost.localdomain [127.0.0.1]) by mail52-ch1
	(MessageSwitch) id 1328282824157078_32695;
	Fri,  3 Feb 2012 15:27:04 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.227])	by mail52-ch1.bigfish.com (Postfix) with ESMTP id
	20C372C0045;	Fri,  3 Feb 2012 15:27:04 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 15:26:59 +0000
X-WSS-ID: 0LYTPKZ-02-38J-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 29044C8011;	Fri,  3 Feb 2012 09:26:58 -0600 (CST)
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, 3 Feb 2012 09:27:18 -0600
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.289.1;
	Fri, 3 Feb 2012 09:26:59 -0600
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, 3 Feb 2012
	10:26:55 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E979B49C0F1; Fri,  3 Feb 2012
	15:26:53 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D26EA5940FF; Fri,  3 Feb 2012
	16:26:53 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 58a2281581a4c4171ca52549b3e8062b9733ec2b
Message-ID: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 3 Feb 2012 16:29:11 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <Ian.Campbell@citrix.com>,
	<Ian.Jackson@eu.citrix.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] amd iommu: Fix a return value of
	guest_iommu_set_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328282938 -3600
# Node ID 58a2281581a4c4171ca52549b3e8062b9733ec2b
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
amd iommu: Fix a return value of guest_iommu_set_base()
Remove a unnecessary check in guest_iommu_destroy()

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3432abcf9380 -r 58a2281581a4 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 03 16:28:58 2012 +0100
@@ -806,7 +806,7 @@ int guest_iommu_set_base(struct domain *
     struct guest_iommu *iommu = domain_iommu(d);
 
     if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return 0;
+        return -EACCES;
 
     if ( !iommu )
         return -EACCES;
@@ -896,9 +896,6 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return;
-
     iommu = domain_iommu(d);
     if ( !iommu )
         return;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:47:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLM7-0002PY-BQ; Fri, 03 Feb 2012 15:47:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtLM5-0002PT-Qt
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:47:18 +0000
Received: from [193.109.254.147:47450] by server-1.bemta-14.messagelabs.com id
	CB/ED-21323-5810C2F4; Fri, 03 Feb 2012 15:47:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328283986!51307083!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11316 invoked from network); 3 Feb 2012 15:46:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 15:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10474978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 15:47:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 15:47:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RtLM4-0008UE-20; Fri, 03 Feb 2012 15:47:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RtLM3-0005SB-WB;
	Fri, 03 Feb 2012 15:47:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20268.387.946628.198322@mariner.uk.xensource.com>
Date: Fri, 3 Feb 2012 15:47:15 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F2BBD2F0200007800070B3A@nat28.tlf.novell.com>
References: <osstest-11831-mainreport@xen.org>
	<4F2BBD2F0200007800070B3A@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] 11831: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 11831: regressions - FAIL"):
> >>> On 03.02.12 at 07:22, xen.org <ian.jackson@eu.citrix.com> wrote:
> > Regressions which are regarded as allowable (not blocking):
> >  build-i386                    4 xen-build                fail   like 11637
> >  build-i386-oldkern            4 xen-build                fail   like 11637
> 
> Is that really the way things should work?

11637 broke because of a bug in the test harness relating to the new
qemu-upstream-unstable build.  I fixed that, but from the system's
point of view that means that 11637's builds weren't reliable either.

So this is a bug because we shouldn't be tolerating heisenbugs in the
build; any baseline passed build should be enough to block a push if
the corresponding staging build failed.  I've made what I think is a
suitable change, which is now undergoing testing to check that it
works.

There's also a separate bug which is that it failed to notice for many
tests that they were blocked by lack of the build:

> >  test-amd64-i386-xl            4 xen-install          fail REGR. vs. 11643

But happily this blocked the push of the broken build.  I will push a
fix for this other bug when the first bugfix has made it through the
tester.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:47:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLM7-0002PY-BQ; Fri, 03 Feb 2012 15:47:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtLM5-0002PT-Qt
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:47:18 +0000
Received: from [193.109.254.147:47450] by server-1.bemta-14.messagelabs.com id
	CB/ED-21323-5810C2F4; Fri, 03 Feb 2012 15:47:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328283986!51307083!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11316 invoked from network); 3 Feb 2012 15:46:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 15:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10474978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 15:47:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 15:47:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RtLM4-0008UE-20; Fri, 03 Feb 2012 15:47:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RtLM3-0005SB-WB;
	Fri, 03 Feb 2012 15:47:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20268.387.946628.198322@mariner.uk.xensource.com>
Date: Fri, 3 Feb 2012 15:47:15 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F2BBD2F0200007800070B3A@nat28.tlf.novell.com>
References: <osstest-11831-mainreport@xen.org>
	<4F2BBD2F0200007800070B3A@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] 11831: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 11831: regressions - FAIL"):
> >>> On 03.02.12 at 07:22, xen.org <ian.jackson@eu.citrix.com> wrote:
> > Regressions which are regarded as allowable (not blocking):
> >  build-i386                    4 xen-build                fail   like 11637
> >  build-i386-oldkern            4 xen-build                fail   like 11637
> 
> Is that really the way things should work?

11637 broke because of a bug in the test harness relating to the new
qemu-upstream-unstable build.  I fixed that, but from the system's
point of view that means that 11637's builds weren't reliable either.

So this is a bug because we shouldn't be tolerating heisenbugs in the
build; any baseline passed build should be enough to block a push if
the corresponding staging build failed.  I've made what I think is a
suitable change, which is now undergoing testing to check that it
works.

There's also a separate bug which is that it failed to notice for many
tests that they were blocked by lack of the build:

> >  test-amd64-i386-xl            4 xen-install          fail REGR. vs. 11643

But happily this blocked the push of the broken build.  I will push a
fix for this other bug when the first bugfix has made it through the
tester.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:50:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLOW-0002X3-US; Fri, 03 Feb 2012 15:49:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtLOV-0002Ws-Q6
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:49:48 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328284180!13066257!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21216 invoked from network); 3 Feb 2012 15:49:41 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 15:49:41 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for
	virtual block device major numbers
Thread-Index: AQHM4ng4/GI3PXkLt06Ij7IAivebnZYrxz8A
Date: Fri, 3 Feb 2012 15:49:29 +0000
Message-ID: <AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
In-Reply-To: <4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <8AC3E98F5B4AEA459B722611191CCE61@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 6:31 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
> These being mostly meaningless to non-Linux, I don't think they
> belong here.
> 
> Jan

[blkif major number #defines deleted]

Front and backends must use some common convention for communicating this
virtual device mapping.  Since Linux was the first Dom0, all blkif drivers that I'm
aware of, regardless of OS platform, reference the Linux values.

The mapping really only matters for HVM guests and the hand-off between a
QEMU emulated device and the PV driver.  To avoid confusion (e.g. name of
root mount device, device names in fstab), the PV drivers export alias devices named
to match the devices QEMU emulates.  The only way to do this successfully is to
know the major number scheme used by  Dom0/QEMU.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 15:50:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 15:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLOW-0002X3-US; Fri, 03 Feb 2012 15:49:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RtLOV-0002Ws-Q6
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 15:49:48 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328284180!13066257!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21216 invoked from network); 3 Feb 2012 15:49:41 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 15:49:41 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for
	virtual block device major numbers
Thread-Index: AQHM4ng4/GI3PXkLt06Ij7IAivebnZYrxz8A
Date: Fri, 3 Feb 2012 15:49:29 +0000
Message-ID: <AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
In-Reply-To: <4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <8AC3E98F5B4AEA459B722611191CCE61@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 6:31 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
> These being mostly meaningless to non-Linux, I don't think they
> belong here.
> 
> Jan

[blkif major number #defines deleted]

Front and backends must use some common convention for communicating this
virtual device mapping.  Since Linux was the first Dom0, all blkif drivers that I'm
aware of, regardless of OS platform, reference the Linux values.

The mapping really only matters for HVM guests and the hand-off between a
QEMU emulated device and the PV driver.  To avoid confusion (e.g. name of
root mount device, device names in fstab), the PV drivers export alias devices named
to match the devices QEMU emulates.  The only way to do this successfully is to
know the major number scheme used by  Dom0/QEMU.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtLkr-0003Rn-CG; Fri, 03 Feb 2012 16:12:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtLkq-0003RR-EL
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:12:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328285565!13308743!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16767 invoked from network); 3 Feb 2012 16:12:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:12:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:12:45 +0000
Message-Id: <4F2C158C02000078000711D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:12:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
In-Reply-To: <33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
> However,
> if this is the rule, both types of "max ring size" values are "in effect" 
> even if a back-end
> does not provide them both.  So how do you resolve the conflict?  A fully 
> interoperable
> front should allocate the largest possible ring and advertise that size 
> through both
> mechanisms in a fully consistent manner. That's what I was trying to 
> indicate by
> writing the spec this way.

Hmm, I would think a fully compatible frontend should bail (revert to
single page ring) on inconsistent max-ring-pages and
max-ring-page-order, if both are provided by the backend. The limit
for ring-pages should always be max-ring-pages, while the one for
ring-page-order should always be max-ring-page-order. Any mixture
is an error, unless both values are consistent with one another.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtLkr-0003Rn-CG; Fri, 03 Feb 2012 16:12:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtLkq-0003RR-EL
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:12:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328285565!13308743!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16767 invoked from network); 3 Feb 2012 16:12:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:12:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:12:45 +0000
Message-Id: <4F2C158C02000078000711D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:12:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
In-Reply-To: <33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
> However,
> if this is the rule, both types of "max ring size" values are "in effect" 
> even if a back-end
> does not provide them both.  So how do you resolve the conflict?  A fully 
> interoperable
> front should allocate the largest possible ring and advertise that size 
> through both
> mechanisms in a fully consistent manner. That's what I was trying to 
> indicate by
> writing the spec this way.

Hmm, I would think a fully compatible frontend should bail (revert to
single page ring) on inconsistent max-ring-pages and
max-ring-page-order, if both are provided by the backend. The limit
for ring-pages should always be max-ring-pages, while the one for
ring-page-order should always be max-ring-page-order. Any mixture
is an error, unless both values are consistent with one another.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:14:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLmL-0003Z9-Sy; Fri, 03 Feb 2012 16:14:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RtLmK-0003Yc-4V
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:14:24 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328285657!7688373!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26313 invoked from network); 3 Feb 2012 16:14:17 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.209)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 16:14:17 -0000
Received: from mail57-am1-R.bigfish.com (10.3.201.234) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:14:14 +0000
Received: from mail57-am1 (localhost [127.0.0.1])	by mail57-am1-R.bigfish.com
	(Postfix) with ESMTP id 308F026052E;
	Fri,  3 Feb 2012 16:14:17 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1432N1418M98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1
	(MessageSwitch) id 1328285606377578_25833;
	Fri,  3 Feb 2012 16:13:26 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.238])	by
	mail57-am1.bigfish.com (Postfix) with ESMTP id 5776E2E0303;
	Fri,  3 Feb 2012 16:13:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:13:19 +0000
X-WSS-ID: 0LYTRQ6-02-6X7-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 26775C821D;	Fri,  3 Feb 2012 10:13:18 -0600 (CST)
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, 3 Feb 2012 10:13:38 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	10:13:19 -0600
Message-ID: <4F2C079E.6070404@amd.com>
Date: Fri, 3 Feb 2012 11:13:18 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
In-Reply-To: <4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 02:53, Jan Beulich wrote:
>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> On 02/02/12 08:22, Jan Beulich wrote:
>>> As I was about to apply this to my local tree to give it a try, I had
>>> to realize that the microcode integration is still not correct: There
>>> is (at least from an abstract perspective) no guarantee for
>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>> to not deal with this in a formally correct way, it should be stated
>>> so in a code comment (to lower the risk of surprises when someone
>>> touches that code) that this is not possible in practice because
>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>
>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>> may be cases when svm_host_osvw_init() is called multiple times for the
>> same cpu but that should be harmless (and the routine will be renamed to
>> svm_host_osvw_update()).
>
> Wouldn't that result in workaround bits that might get cleared with
> the pending microcode update to get (and remain) set, as they're
> being or-ed together over all invocations of the function after any
> svm_host_osvw_reset()?


I think that would be an OK but not optimal situation: more bits will 
end up being set than necessary, meaning that workarounds will need to 
be applied where they may not be required. But that should not affect 
correctness. I am not sure it's worth optimizing for this case since I 
think onlining a core while doing a microcode update is a rather 
uncommon occurrence.

What could have been a problem is the case when a core that's coming up 
has more bits set than other cores and doesn't get to go into 
cpu_request_microcode(). Since collect_cpu_info() is always invoked on 
the onlining path we will not miss a call into svm_host_osvw_init().


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:14:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLmL-0003Z9-Sy; Fri, 03 Feb 2012 16:14:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RtLmK-0003Yc-4V
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:14:24 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328285657!7688373!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26313 invoked from network); 3 Feb 2012 16:14:17 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.209)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 16:14:17 -0000
Received: from mail57-am1-R.bigfish.com (10.3.201.234) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:14:14 +0000
Received: from mail57-am1 (localhost [127.0.0.1])	by mail57-am1-R.bigfish.com
	(Postfix) with ESMTP id 308F026052E;
	Fri,  3 Feb 2012 16:14:17 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1432N1418M98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1
	(MessageSwitch) id 1328285606377578_25833;
	Fri,  3 Feb 2012 16:13:26 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.238])	by
	mail57-am1.bigfish.com (Postfix) with ESMTP id 5776E2E0303;
	Fri,  3 Feb 2012 16:13:26 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:13:19 +0000
X-WSS-ID: 0LYTRQ6-02-6X7-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 26775C821D;	Fri,  3 Feb 2012 10:13:18 -0600 (CST)
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, 3 Feb 2012 10:13:38 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	10:13:19 -0600
Message-ID: <4F2C079E.6070404@amd.com>
Date: Fri, 3 Feb 2012 11:13:18 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
In-Reply-To: <4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 02:53, Jan Beulich wrote:
>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> On 02/02/12 08:22, Jan Beulich wrote:
>>> As I was about to apply this to my local tree to give it a try, I had
>>> to realize that the microcode integration is still not correct: There
>>> is (at least from an abstract perspective) no guarantee for
>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>> to not deal with this in a formally correct way, it should be stated
>>> so in a code comment (to lower the risk of surprises when someone
>>> touches that code) that this is not possible in practice because
>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>
>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>> may be cases when svm_host_osvw_init() is called multiple times for the
>> same cpu but that should be harmless (and the routine will be renamed to
>> svm_host_osvw_update()).
>
> Wouldn't that result in workaround bits that might get cleared with
> the pending microcode update to get (and remain) set, as they're
> being or-ed together over all invocations of the function after any
> svm_host_osvw_reset()?


I think that would be an OK but not optimal situation: more bits will 
end up being set than necessary, meaning that workarounds will need to 
be applied where they may not be required. But that should not affect 
correctness. I am not sure it's worth optimizing for this case since I 
think onlining a core while doing a microcode update is a rather 
uncommon occurrence.

What could have been a problem is the case when a core that's coming up 
has more bits set than other cores and doesn't get to go into 
cpu_request_microcode(). Since collect_cpu_info() is always invoked on 
the onlining path we will not miss a call into svm_host_osvw_init().


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLxf-00048q-Qp; Fri, 03 Feb 2012 16:26:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtLxd-00048l-H5
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:26:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328286358!13850238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15715 invoked from network); 3 Feb 2012 16:25:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:25:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:25:58 +0000
Message-Id: <4F2C18A40200007800071223@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:25:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
	<4F2C079E.6070404@amd.com>
In-Reply-To: <4F2C079E.6070404@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 17:13, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/03/12 02:53, Jan Beulich wrote:
>>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> On 02/02/12 08:22, Jan Beulich wrote:
>>>> As I was about to apply this to my local tree to give it a try, I had
>>>> to realize that the microcode integration is still not correct: There
>>>> is (at least from an abstract perspective) no guarantee for
>>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>>> to not deal with this in a formally correct way, it should be stated
>>>> so in a code comment (to lower the risk of surprises when someone
>>>> touches that code) that this is not possible in practice because
>>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>>
>>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>>> may be cases when svm_host_osvw_init() is called multiple times for the
>>> same cpu but that should be harmless (and the routine will be renamed to
>>> svm_host_osvw_update()).
>>
>> Wouldn't that result in workaround bits that might get cleared with
>> the pending microcode update to get (and remain) set, as they're
>> being or-ed together over all invocations of the function after any
>> svm_host_osvw_reset()?
> 
> 
> I think that would be an OK but not optimal situation: more bits will 
> end up being set than necessary, meaning that workarounds will need to 
> be applied where they may not be required. But that should not affect 
> correctness. I am not sure it's worth optimizing for this case since I 
> think onlining a core while doing a microcode update is a rather 
> uncommon occurrence.

How is that related to CPU onlining? If you put the call into
collect_cpu_info(), that'll affect all CPUs currently online as well
(and, as I said, negate the effect of possibly cleared OSVW bits
that the pending microcode updated might have). The only case
where calling svm_host_osvw_init() from collect_cpu_info() would
be correct is if the latter returns an error. Which, as I noted
before, can only happen for non-AMD or pre-Fam10 CPUs (on
all of which calling the function is pointless). So we're back to me
asking that this simply be explained in a code comment in lieu of
a proper abstraction of the situation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:26:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtLxf-00048q-Qp; Fri, 03 Feb 2012 16:26:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtLxd-00048l-H5
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:26:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328286358!13850238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15715 invoked from network); 3 Feb 2012 16:25:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:25:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:25:58 +0000
Message-Id: <4F2C18A40200007800071223@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:25:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
	<4F2C079E.6070404@amd.com>
In-Reply-To: <4F2C079E.6070404@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 17:13, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/03/12 02:53, Jan Beulich wrote:
>>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> On 02/02/12 08:22, Jan Beulich wrote:
>>>> As I was about to apply this to my local tree to give it a try, I had
>>>> to realize that the microcode integration is still not correct: There
>>>> is (at least from an abstract perspective) no guarantee for
>>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>>> to not deal with this in a formally correct way, it should be stated
>>>> so in a code comment (to lower the risk of surprises when someone
>>>> touches that code) that this is not possible in practice because
>>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>>
>>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>>> may be cases when svm_host_osvw_init() is called multiple times for the
>>> same cpu but that should be harmless (and the routine will be renamed to
>>> svm_host_osvw_update()).
>>
>> Wouldn't that result in workaround bits that might get cleared with
>> the pending microcode update to get (and remain) set, as they're
>> being or-ed together over all invocations of the function after any
>> svm_host_osvw_reset()?
> 
> 
> I think that would be an OK but not optimal situation: more bits will 
> end up being set than necessary, meaning that workarounds will need to 
> be applied where they may not be required. But that should not affect 
> correctness. I am not sure it's worth optimizing for this case since I 
> think onlining a core while doing a microcode update is a rather 
> uncommon occurrence.

How is that related to CPU onlining? If you put the call into
collect_cpu_info(), that'll affect all CPUs currently online as well
(and, as I said, negate the effect of possibly cleared OSVW bits
that the pending microcode updated might have). The only case
where calling svm_host_osvw_init() from collect_cpu_info() would
be correct is if the latter returns an error. Which, as I noted
before, can only happen for non-AMD or pre-Fam10 CPUs (on
all of which calling the function is pointless). So we're back to me
asking that this simply be explained in a code comment in lieu of
a proper abstraction of the situation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:33:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtM49-0004K6-TO; Fri, 03 Feb 2012 16:32:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1RtM48-0004Jo-Ar
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:32:48 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328286760!10357601!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26297 invoked from network); 3 Feb 2012 16:32:41 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 16:32:41 -0000
Received: by iaeh11 with SMTP id h11so20960891iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 08:32:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=iGiXhA/6K3THvp/EAxgJ6pK+/8kjzYfoXUL/AibPefA=;
	b=HL8xSGpUI+YckZHy2pFCiUz31WxLxEt5kGpHPt6p59CATPwUOzDMxMNJiNlD9J0N/s
	QP10uc09lqG7D/RCtGRoRBUdZ94CAJNPfUPxa9rEflakttQo7LrBl5ERwiv0dfqxC1R+
	N5zthI57nRJfXQBihETwJSJFZJp60IQRxTmwY=
MIME-Version: 1.0
Received: by 10.50.6.194 with SMTP id d2mr9339132iga.24.1328286760084; Fri, 03
	Feb 2012 08:32:40 -0800 (PST)
Received: by 10.231.132.71 with HTTP; Fri, 3 Feb 2012 08:32:40 -0800 (PST)
Date: Fri, 3 Feb 2012 19:32:40 +0300
Message-ID: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was experimenting with DomU redundancy and load balancing,
and I think this GPF started to show up after a couple of DomUs
with CARP and HAProxy were added that constantly generate
a strong flow of network traffic by pinging target machines
and each other as well. Or may be it is not related to CARP
and pinging, but just depends on traffic volume: the more VMs
added and running, the more chances that Dom0-DomU networking
will collapse, the critical point being 8 guest domains, while I need 10.

I can't give exact steps to reproduce, as it happens randomly,
usually without any correlated user activity, after several hours
(or several minutes) of normal performance. But sometimes
it happens not so long after a balancer's DomU startup or shutdown.
After GPF happens, all VMs loose their networking connectivity.

Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)
with Xen version 4.1.2_05-1.9, which is patched as described
in openSUSE bug 727081 (bugzilla.novell.com/show_bug.cgi?id=727081).
Supposedly "offending" DomU is paravirtualized NetBSD 5.1.1
for AMD64 with recompiled kernel (CARP enabled, no more changes).
Other VMs are openSUSE 11.4 and 12.1 for AMD64.


Trace log in /var/log/messages always looks similar (varying digits
replaced with asterisks ***):


general protection fault: 0000 [#1] SMP
CPU {core-number}
Modules linked in: 8250 8250_pnp af_packet asus_wmi ata_generic
blkback_pagemap blkbk blktap bridge btrfs button cdrom dm_mod
domctl drm drm_kms_helper edd eeepc_wmi ehci_hcd evtchn fuse
gntdev hid hwmon i2c_algo_bit i2c_core i2c_i801 i915
iTCO_vendor_support iTCO_wdt linear llc lzo_compress mei(C)
microcode netbk parport parport_pc pata_via pci_hotplug pcspkr
ppdev processor r8169 rfkill serial_core [serio_raw] sg
snd snd_hda_codec snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_intel snd_hwdep snd_mixer_oss snd_page_alloc snd_pcm
snd_pcm_oss snd_seq snd_seq_device snd_timer soundcore
sparse_keymap sr_mod stp thermal_sys uas usbbk usbcore
usbhid usb_storage video wmi xenblk xenbus_be xennet zlib_deflate

Pid: {process-id}, comm: netback/{0/1} Tainted: G
         C  3.1.0-1.2-xen #1 System manufacturer System Product Name/P8H67-M
RIP: e030:[<ffffffff803e7451>]  [<ffffffff803e7451>]
skb_release_data.part.47+0x61/0xc0
RSP: e02b:ffff880******d40  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff880********0 RCX: ffff880******000
RDX: {..RCX.+.0e80..} RSI: 00000000000000** RDI: 00***c**00000000
RBP: {.....RBX......} R08: {..RCX.-.cff0..} R09: 0000000*********
R10: 000000000000000* R11: {.task.+.0470..} R12: ffff880026a51000
R13: ffff880********0 R14: ffffc900048****0 R15: 0000000000000001
FS:  00007f*******7*0(0000) GS:ffff880******000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000***********0 CR3: 0000000******000 CR4: 0000000000042660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/{0/1} (pid: {process-id}, threadinfo ffff880******000,
task ffff880********0)
Stack:
 0000000000000000 {.....RBX......} 0000000000000000 ffffffff803e7511
 {.....RBX......} ffffffffa0***d2c {.....task.....} {thread.+.1e00.}
 {thread.+.1db0.} {.R14.-.22a40..} ffffc9000000000* 0000000000000000
Call Trace:
 [<ffffffff803e7511>] __kfree_skb+0x11/0x20
 [<ffffffffa0***d2c>] net_rx_action+0x66c/0x9c0 [netbk]
 [<ffffffffa0***72a>] netbk_action_thread+0x5a/0x270 [netbk]
 [<ffffffff8006438e>] kthread+0x7e/0x90
 [<ffffffff8050f814>] kernel_thread_helper+0x4/0x10
Code: 48 8b 7c 02 08 e8 90 69 cf ff 8b 95 d0 00 00 00
  48 8b 8d d8 00 00 00 48 01 ca 0f b7 02 39 c3 7c
  d1 f6 42 0c 10 74 1e 48 8b 7a 30
RIP  [<ffffffff803e7451>] skb_release_data.part.47+0x61/0xc0
 RSP <ffff880******d40>
---[ end trace **************** ]---


Preceeding and subsequent messages don't seem to be related with GPF,
time gap is from minutes to half an hour or even more. But if this could give
some insight, I will post them, too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:33:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtM49-0004K6-TO; Fri, 03 Feb 2012 16:32:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1RtM48-0004Jo-Ar
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:32:48 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328286760!10357601!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26297 invoked from network); 3 Feb 2012 16:32:41 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 16:32:41 -0000
Received: by iaeh11 with SMTP id h11so20960891iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 08:32:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=iGiXhA/6K3THvp/EAxgJ6pK+/8kjzYfoXUL/AibPefA=;
	b=HL8xSGpUI+YckZHy2pFCiUz31WxLxEt5kGpHPt6p59CATPwUOzDMxMNJiNlD9J0N/s
	QP10uc09lqG7D/RCtGRoRBUdZ94CAJNPfUPxa9rEflakttQo7LrBl5ERwiv0dfqxC1R+
	N5zthI57nRJfXQBihETwJSJFZJp60IQRxTmwY=
MIME-Version: 1.0
Received: by 10.50.6.194 with SMTP id d2mr9339132iga.24.1328286760084; Fri, 03
	Feb 2012 08:32:40 -0800 (PST)
Received: by 10.231.132.71 with HTTP; Fri, 3 Feb 2012 08:32:40 -0800 (PST)
Date: Fri, 3 Feb 2012 19:32:40 +0300
Message-ID: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was experimenting with DomU redundancy and load balancing,
and I think this GPF started to show up after a couple of DomUs
with CARP and HAProxy were added that constantly generate
a strong flow of network traffic by pinging target machines
and each other as well. Or may be it is not related to CARP
and pinging, but just depends on traffic volume: the more VMs
added and running, the more chances that Dom0-DomU networking
will collapse, the critical point being 8 guest domains, while I need 10.

I can't give exact steps to reproduce, as it happens randomly,
usually without any correlated user activity, after several hours
(or several minutes) of normal performance. But sometimes
it happens not so long after a balancer's DomU startup or shutdown.
After GPF happens, all VMs loose their networking connectivity.

Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)
with Xen version 4.1.2_05-1.9, which is patched as described
in openSUSE bug 727081 (bugzilla.novell.com/show_bug.cgi?id=727081).
Supposedly "offending" DomU is paravirtualized NetBSD 5.1.1
for AMD64 with recompiled kernel (CARP enabled, no more changes).
Other VMs are openSUSE 11.4 and 12.1 for AMD64.


Trace log in /var/log/messages always looks similar (varying digits
replaced with asterisks ***):


general protection fault: 0000 [#1] SMP
CPU {core-number}
Modules linked in: 8250 8250_pnp af_packet asus_wmi ata_generic
blkback_pagemap blkbk blktap bridge btrfs button cdrom dm_mod
domctl drm drm_kms_helper edd eeepc_wmi ehci_hcd evtchn fuse
gntdev hid hwmon i2c_algo_bit i2c_core i2c_i801 i915
iTCO_vendor_support iTCO_wdt linear llc lzo_compress mei(C)
microcode netbk parport parport_pc pata_via pci_hotplug pcspkr
ppdev processor r8169 rfkill serial_core [serio_raw] sg
snd snd_hda_codec snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_intel snd_hwdep snd_mixer_oss snd_page_alloc snd_pcm
snd_pcm_oss snd_seq snd_seq_device snd_timer soundcore
sparse_keymap sr_mod stp thermal_sys uas usbbk usbcore
usbhid usb_storage video wmi xenblk xenbus_be xennet zlib_deflate

Pid: {process-id}, comm: netback/{0/1} Tainted: G
         C  3.1.0-1.2-xen #1 System manufacturer System Product Name/P8H67-M
RIP: e030:[<ffffffff803e7451>]  [<ffffffff803e7451>]
skb_release_data.part.47+0x61/0xc0
RSP: e02b:ffff880******d40  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff880********0 RCX: ffff880******000
RDX: {..RCX.+.0e80..} RSI: 00000000000000** RDI: 00***c**00000000
RBP: {.....RBX......} R08: {..RCX.-.cff0..} R09: 0000000*********
R10: 000000000000000* R11: {.task.+.0470..} R12: ffff880026a51000
R13: ffff880********0 R14: ffffc900048****0 R15: 0000000000000001
FS:  00007f*******7*0(0000) GS:ffff880******000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000***********0 CR3: 0000000******000 CR4: 0000000000042660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/{0/1} (pid: {process-id}, threadinfo ffff880******000,
task ffff880********0)
Stack:
 0000000000000000 {.....RBX......} 0000000000000000 ffffffff803e7511
 {.....RBX......} ffffffffa0***d2c {.....task.....} {thread.+.1e00.}
 {thread.+.1db0.} {.R14.-.22a40..} ffffc9000000000* 0000000000000000
Call Trace:
 [<ffffffff803e7511>] __kfree_skb+0x11/0x20
 [<ffffffffa0***d2c>] net_rx_action+0x66c/0x9c0 [netbk]
 [<ffffffffa0***72a>] netbk_action_thread+0x5a/0x270 [netbk]
 [<ffffffff8006438e>] kthread+0x7e/0x90
 [<ffffffff8050f814>] kernel_thread_helper+0x4/0x10
Code: 48 8b 7c 02 08 e8 90 69 cf ff 8b 95 d0 00 00 00
  48 8b 8d d8 00 00 00 48 01 ca 0f b7 02 39 c3 7c
  d1 f6 42 0c 10 74 1e 48 8b 7a 30
RIP  [<ffffffff803e7451>] skb_release_data.part.47+0x61/0xc0
 RSP <ffff880******d40>
---[ end trace **************** ]---


Preceeding and subsequent messages don't seem to be related with GPF,
time gap is from minutes to half an hour or even more. But if this could give
some insight, I will post them, too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:35:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtM6p-0004Qq-FH; Fri, 03 Feb 2012 16:35:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtM6n-0004Qf-NP
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:35:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328286927!9999247!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6738 invoked from network); 3 Feb 2012 16:35:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:35:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:35:27 +0000
Message-Id: <4F2C1ADC0200007800071232@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:35:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
In-Reply-To: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] amd iommu: Fix a return value of
 guest_iommu_set_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1328282938 -3600
> # Node ID 58a2281581a4c4171ca52549b3e8062b9733ec2b
> # Parent  3432abcf9380d3840ca38439a304f74a37d155fc
> amd iommu: Fix a return value of guest_iommu_set_base()
> Remove a unnecessary check in guest_iommu_destroy()
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 3432abcf9380 -r 58a2281581a4 xen/drivers/passthrough/amd/iommu_guest.c
> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 03 16:28:58 2012 
> +0100
> @@ -806,7 +806,7 @@ int guest_iommu_set_base(struct domain *
>      struct guest_iommu *iommu = domain_iommu(d);
>  
>      if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
> -        return 0;
> +        return -EACCES;

But as indicated before, all three checks above are redundant with
the one check below. Hence I suggested to remove the checks above,
and if you wish put an ASSERT() past the !iommu check below.

Jan

>  
>      if ( !iommu )
>          return -EACCES;
> @@ -896,9 +896,6 @@ void guest_iommu_destroy(struct domain *
>  {
>      struct guest_iommu *iommu;
>  
> -    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
> -        return;
> -
>      iommu = domain_iommu(d);
>      if ( !iommu )
>          return;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:35:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtM6p-0004Qq-FH; Fri, 03 Feb 2012 16:35:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtM6n-0004Qf-NP
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:35:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328286927!9999247!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6738 invoked from network); 3 Feb 2012 16:35:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:35:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:35:27 +0000
Message-Id: <4F2C1ADC0200007800071232@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:35:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
In-Reply-To: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] amd iommu: Fix a return value of
 guest_iommu_set_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 16:29, Wei Wang <wei.wang2@amd.com> wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1328282938 -3600
> # Node ID 58a2281581a4c4171ca52549b3e8062b9733ec2b
> # Parent  3432abcf9380d3840ca38439a304f74a37d155fc
> amd iommu: Fix a return value of guest_iommu_set_base()
> Remove a unnecessary check in guest_iommu_destroy()
> 
> Signed-off-by: Wei Wang <wei.wang2@amd.com>
> 
> diff -r 3432abcf9380 -r 58a2281581a4 xen/drivers/passthrough/amd/iommu_guest.c
> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 03 16:28:58 2012 
> +0100
> @@ -806,7 +806,7 @@ int guest_iommu_set_base(struct domain *
>      struct guest_iommu *iommu = domain_iommu(d);
>  
>      if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
> -        return 0;
> +        return -EACCES;

But as indicated before, all three checks above are redundant with
the one check below. Hence I suggested to remove the checks above,
and if you wish put an ASSERT() past the !iommu check below.

Jan

>  
>      if ( !iommu )
>          return -EACCES;
> @@ -896,9 +896,6 @@ void guest_iommu_destroy(struct domain *
>  {
>      struct guest_iommu *iommu;
>  
> -    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
> -        return;
> -
>      iommu = domain_iommu(d);
>      if ( !iommu )
>          return;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:36:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtM7v-0004V7-TU; Fri, 03 Feb 2012 16:36:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RtM7v-0004UW-8u
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:36:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328286995!13592280!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21471 invoked from network); 3 Feb 2012 16:36:36 -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;
	3 Feb 2012 16:36:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180321339"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 11:36:34 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	11:36:34 -0500
Message-ID: <4F2C0D11.2020405@citrix.com>
Date: Fri, 3 Feb 2012 16:36:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2BE17D.2010207@citrix.com>	<4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
	<4F2BE5DE.6060908@citrix.com>
In-Reply-To: <4F2BE5DE.6060908@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000908090503070204070902"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] IO-APIC: tweak debug key info formatting v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000908090503070204070902
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Respun to reduce the verbosity of names written out for each line. 
Contractions are:

vector -> vec
delivery_mode -> delivery
dest_mode -> dest
delivery_status -> status
trigger -> trig

In addition:
    vector is printed in hex
    dest and trig mode binary choices are represented with single
characters rather than full names
    delivery mode is converted from a number to a short string.

Output on one of my text boxes is as follows:

idol login: (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
switch input to DOM0)
(XEN) Guest interrupt information:
<... snip ...>
(XEN)    IRQ:  22 affinity:1 vec:b0 type=IO-APIC-level   status=00000010
in-flight=0 domain-list=0: 22(----),
(XEN)    IRQ:  23 affinity:1 vec:c0 type=IO-APIC-level   status=00000010
in-flight=0 domain-list=0: 23(----),
(XEN)    IRQ:  24 affinity:1 vec:41 type=PCI-MSI         status=00000010
in-flight=0 domain-list=0:279(----),
(XEN)    IRQ:  25 affinity:1 vec:31 type=PCI-MSI         status=00000010
in-flight=0 domain-list=0:278(----),
(XEN) IO-APIC interrupt information:
(XEN)     IRQ  0 Vec240:
(XEN)       Apic 0x00, Pin  2: vec=f0 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  1 Vec 40:
(XEN)       Apic 0x00, Pin  1: vec=28 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  3 Vec 48:
(XEN)       Apic 0x00, Pin  3: vec=30 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  4 Vec241:
(XEN)       Apic 0x00, Pin  4: vec=f1 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  5 Vec 56:
(XEN)       Apic 0x00, Pin  5: vec=38 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  6 Vec 64:
(XEN)       Apic 0x00, Pin  6: vec=40 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  7 Vec 72:
(XEN)       Apic 0x00, Pin  7: vec=48 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  8 Vec 80:
(XEN)       Apic 0x00, Pin  8: vec=50 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  9 Vec 88:
(XEN)       Apic 0x00, Pin  9: vec=58 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=L mask=0 dest_id:1
<... snip ...>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000908090503070204070902
Content-Type: text/x-patch; name="dump_ioapic_irq_info_format.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="dump_ioapic_irq_info_format.patch"

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864
IO-APIC: Reformat IO-APIC RTE debug info (v2)

Having the columns aligned makes for much easier reading.  Also remove
the commas which only add to visual clutter in combination with
spaces.

Furthermore, printing fewer characters makes it less likely that the
serial buffer will overflow resulting in loss of critical debugging
information.

Changes since v1:
 *  Format vector as hex rather than dec
 *  Contract some names
 *  destination mode uses 'L' or 'P' instead of full words
 *  trigger mode uses 'L' or 'E' instead of full words
 *  delivery mode uses short string instead of a number

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e2722b24dc09 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2374,6 +2374,23 @@ int ioapic_guest_write(unsigned long phy
     return 0;
 }
 
+static const char * delivery_mode_2_str(
+    const enum ioapic_irq_destination_types mode)
+{
+    switch ( mode )
+    {
+    case dest_Fixed: return "Fixed";
+    case dest_LowestPrio: return "LoPri";
+    case dest_SMI: return "SMI";
+    case dest_NMI: return "NMI";
+    case dest_INIT: return "INIT";
+    case dest_ExtINT: return "ExINT";
+    case dest__reserved_1:
+    case dest__reserved_2: return "Resvd";
+    default: return "INVAL";
+    }
+}
+
 void dump_ioapic_irq_info(void)
 {
     struct irq_pin_list *entry;
@@ -2406,13 +2423,12 @@ void dump_ioapic_irq_info(void)
             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
             spin_unlock_irqrestore(&ioapic_lock, flags);
 
-            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
-                   "delivery_status=%d, polarity=%d, irr=%d, "
-                   "trigger=%s, mask=%d, dest_id:%d\n",
-                   rte.vector, rte.delivery_mode,
-                   rte.dest_mode ? "logical" : "physical",
+            printk("vec=%02x delivery=%-5s dest=%c status=%d "
+                   "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n",
+                   rte.vector, delivery_mode_2_str(rte.delivery_mode),
+                   rte.dest_mode ? 'L' : 'P',
                    rte.delivery_status, rte.polarity, rte.irr,
-                   rte.trigger ? "level" : "edge", rte.mask,
+                   rte.trigger ? 'L' : 'E', rte.mask,
                    rte.dest.logical.logical_dest);
 
             if ( entry->next == 0 )

--------------000908090503070204070902
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000908090503070204070902--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:36:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtM7v-0004V7-TU; Fri, 03 Feb 2012 16:36:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RtM7v-0004UW-8u
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:36:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328286995!13592280!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21471 invoked from network); 3 Feb 2012 16:36:36 -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;
	3 Feb 2012 16:36:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180321339"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 11:36:34 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	11:36:34 -0500
Message-ID: <4F2C0D11.2020405@citrix.com>
Date: Fri, 3 Feb 2012 16:36:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2BE17D.2010207@citrix.com>	<4F2BF2C80200007800070EDD@nat28.tlf.novell.com>
	<4F2BE5DE.6060908@citrix.com>
In-Reply-To: <4F2BE5DE.6060908@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000908090503070204070902"
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] IO-APIC: tweak debug key info formatting v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000908090503070204070902
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Respun to reduce the verbosity of names written out for each line. 
Contractions are:

vector -> vec
delivery_mode -> delivery
dest_mode -> dest
delivery_status -> status
trigger -> trig

In addition:
    vector is printed in hex
    dest and trig mode binary choices are represented with single
characters rather than full names
    delivery mode is converted from a number to a short string.

Output on one of my text boxes is as follows:

idol login: (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
switch input to DOM0)
(XEN) Guest interrupt information:
<... snip ...>
(XEN)    IRQ:  22 affinity:1 vec:b0 type=IO-APIC-level   status=00000010
in-flight=0 domain-list=0: 22(----),
(XEN)    IRQ:  23 affinity:1 vec:c0 type=IO-APIC-level   status=00000010
in-flight=0 domain-list=0: 23(----),
(XEN)    IRQ:  24 affinity:1 vec:41 type=PCI-MSI         status=00000010
in-flight=0 domain-list=0:279(----),
(XEN)    IRQ:  25 affinity:1 vec:31 type=PCI-MSI         status=00000010
in-flight=0 domain-list=0:278(----),
(XEN) IO-APIC interrupt information:
(XEN)     IRQ  0 Vec240:
(XEN)       Apic 0x00, Pin  2: vec=f0 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  1 Vec 40:
(XEN)       Apic 0x00, Pin  1: vec=28 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  3 Vec 48:
(XEN)       Apic 0x00, Pin  3: vec=30 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  4 Vec241:
(XEN)       Apic 0x00, Pin  4: vec=f1 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  5 Vec 56:
(XEN)       Apic 0x00, Pin  5: vec=38 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  6 Vec 64:
(XEN)       Apic 0x00, Pin  6: vec=40 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  7 Vec 72:
(XEN)       Apic 0x00, Pin  7: vec=48 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  8 Vec 80:
(XEN)       Apic 0x00, Pin  8: vec=50 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=E mask=0 dest_id:1
(XEN)     IRQ  9 Vec 88:
(XEN)       Apic 0x00, Pin  9: vec=58 delivery=LoPri dest=L status=0
polarity=0 irr=0 trig=L mask=0 dest_id:1
<... snip ...>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000908090503070204070902
Content-Type: text/x-patch; name="dump_ioapic_irq_info_format.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="dump_ioapic_irq_info_format.patch"

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864
IO-APIC: Reformat IO-APIC RTE debug info (v2)

Having the columns aligned makes for much easier reading.  Also remove
the commas which only add to visual clutter in combination with
spaces.

Furthermore, printing fewer characters makes it less likely that the
serial buffer will overflow resulting in loss of critical debugging
information.

Changes since v1:
 *  Format vector as hex rather than dec
 *  Contract some names
 *  destination mode uses 'L' or 'P' instead of full words
 *  trigger mode uses 'L' or 'E' instead of full words
 *  delivery mode uses short string instead of a number

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r e2722b24dc09 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2374,6 +2374,23 @@ int ioapic_guest_write(unsigned long phy
     return 0;
 }
 
+static const char * delivery_mode_2_str(
+    const enum ioapic_irq_destination_types mode)
+{
+    switch ( mode )
+    {
+    case dest_Fixed: return "Fixed";
+    case dest_LowestPrio: return "LoPri";
+    case dest_SMI: return "SMI";
+    case dest_NMI: return "NMI";
+    case dest_INIT: return "INIT";
+    case dest_ExtINT: return "ExINT";
+    case dest__reserved_1:
+    case dest__reserved_2: return "Resvd";
+    default: return "INVAL";
+    }
+}
+
 void dump_ioapic_irq_info(void)
 {
     struct irq_pin_list *entry;
@@ -2406,13 +2423,12 @@ void dump_ioapic_irq_info(void)
             *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
             spin_unlock_irqrestore(&ioapic_lock, flags);
 
-            printk("vector=%u, delivery_mode=%u, dest_mode=%s, "
-                   "delivery_status=%d, polarity=%d, irr=%d, "
-                   "trigger=%s, mask=%d, dest_id:%d\n",
-                   rte.vector, rte.delivery_mode,
-                   rte.dest_mode ? "logical" : "physical",
+            printk("vec=%02x delivery=%-5s dest=%c status=%d "
+                   "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n",
+                   rte.vector, delivery_mode_2_str(rte.delivery_mode),
+                   rte.dest_mode ? 'L' : 'P',
                    rte.delivery_status, rte.polarity, rte.irr,
-                   rte.trigger ? "level" : "edge", rte.mask,
+                   rte.trigger ? 'L' : 'E', rte.mask,
                    rte.dest.logical.logical_dest);
 
             if ( entry->next == 0 )

--------------000908090503070204070902
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000908090503070204070902--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:41:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtMCD-0004ij-NH; Fri, 03 Feb 2012 16:41:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtMCC-0004iY-Dg
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:41:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328287262!13624381!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13415 invoked from network); 3 Feb 2012 16:41:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 16:41:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10477888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 16:41:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 16:41:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtMC5-0000Ki-Hw;
	Fri, 03 Feb 2012 16:41:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtMC5-0004V5-84;
	Fri, 03 Feb 2012 16:41:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11859-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 16:41:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11859: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11859 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11859/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:41:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtMCD-0004ij-NH; Fri, 03 Feb 2012 16:41:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtMCC-0004iY-Dg
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:41:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328287262!13624381!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13415 invoked from network); 3 Feb 2012 16:41:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 16:41:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10477888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 16:41:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 16:41:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtMC5-0000Ki-Hw;
	Fri, 03 Feb 2012 16:41:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtMC5-0004V5-84;
	Fri, 03 Feb 2012 16:41:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11859-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 16:41:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11859: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11859 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11859/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:49:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtMJb-00054T-LN; Fri, 03 Feb 2012 16:48:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RtMJa-00053Q-9l
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:48:46 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328287659!59673000!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17995 invoked from network); 3 Feb 2012 16:47:40 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.11)
	by server-2.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 16:47:40 -0000
Received: from mail47-tx2-R.bigfish.com (10.9.14.245) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:48:37 +0000
Received: from mail47-tx2 (localhost [127.0.0.1])	by mail47-tx2-R.bigfish.com
	(Postfix) with ESMTP id 4C887100590;
	Fri,  3 Feb 2012 16:48:40 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1432N1418M98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail47-tx2 (localhost.localdomain [127.0.0.1]) by mail47-tx2
	(MessageSwitch) id 1328287719159016_20199;
	Fri,  3 Feb 2012 16:48:39 +0000 (UTC)
Received: from TX2EHSMHS045.bigfish.com (unknown [10.9.14.242])	by
	mail47-tx2.bigfish.com (Postfix) with ESMTP id 165E680046;
	Fri,  3 Feb 2012 16:48:39 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS045.bigfish.com (10.9.99.145) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:48:36 +0000
X-WSS-ID: 0LYTTCY-01-B1E-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 20FB310280EF;	Fri,  3 Feb 2012 10:48:34 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 3 Feb 2012 10:48:53 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	10:48:34 -0600
Message-ID: <4F2C0FE1.3030304@amd.com>
Date: Fri, 3 Feb 2012 11:48:33 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
	<4F2C079E.6070404@amd.com>
	<4F2C18A40200007800071223@nat28.tlf.novell.com>
In-Reply-To: <4F2C18A40200007800071223@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 11:25, Jan Beulich wrote:
>>>> On 03.02.12 at 17:13, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> On 02/03/12 02:53, Jan Beulich wrote:
>>>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>> On 02/02/12 08:22, Jan Beulich wrote:
>>>>> As I was about to apply this to my local tree to give it a try, I had
>>>>> to realize that the microcode integration is still not correct: There
>>>>> is (at least from an abstract perspective) no guarantee for
>>>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>>>> to not deal with this in a formally correct way, it should be stated
>>>>> so in a code comment (to lower the risk of surprises when someone
>>>>> touches that code) that this is not possible in practice because
>>>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>>>
>>>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>>>> may be cases when svm_host_osvw_init() is called multiple times for the
>>>> same cpu but that should be harmless (and the routine will be renamed to
>>>> svm_host_osvw_update()).
>>>
>>> Wouldn't that result in workaround bits that might get cleared with
>>> the pending microcode update to get (and remain) set, as they're
>>> being or-ed together over all invocations of the function after any
>>> svm_host_osvw_reset()?
>>
>>
>> I think that would be an OK but not optimal situation: more bits will
>> end up being set than necessary, meaning that workarounds will need to
>> be applied where they may not be required. But that should not affect
>> correctness. I am not sure it's worth optimizing for this case since I
>> think onlining a core while doing a microcode update is a rather
>> uncommon occurrence.
>
> How is that related to CPU onlining? If you put the call into
> collect_cpu_info(), that'll affect all CPUs currently online as well
> (and, as I said, negate the effect of possibly cleared OSVW bits
> that the pending microcode updated might have). The only case
> where calling svm_host_osvw_init() from collect_cpu_info() would
> be correct is if the latter returns an error. Which, as I noted
> before, can only happen for non-AMD or pre-Fam10 CPUs (on
> all of which calling the function is pointless). So we're back to me
> asking that this simply be explained in a code comment in lieu of
> a proper abstraction of the situation.


OK, I misunderstood your original comment then. I thought you were 
talking about a race between microcode update and onlining a core.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:49:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtMJb-00054T-LN; Fri, 03 Feb 2012 16:48:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RtMJa-00053Q-9l
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:48:46 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328287659!59673000!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17995 invoked from network); 3 Feb 2012 16:47:40 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.11)
	by server-2.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Feb 2012 16:47:40 -0000
Received: from mail47-tx2-R.bigfish.com (10.9.14.245) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:48:37 +0000
Received: from mail47-tx2 (localhost [127.0.0.1])	by mail47-tx2-R.bigfish.com
	(Postfix) with ESMTP id 4C887100590;
	Fri,  3 Feb 2012 16:48:40 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1432N1418M98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail47-tx2 (localhost.localdomain [127.0.0.1]) by mail47-tx2
	(MessageSwitch) id 1328287719159016_20199;
	Fri,  3 Feb 2012 16:48:39 +0000 (UTC)
Received: from TX2EHSMHS045.bigfish.com (unknown [10.9.14.242])	by
	mail47-tx2.bigfish.com (Postfix) with ESMTP id 165E680046;
	Fri,  3 Feb 2012 16:48:39 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS045.bigfish.com (10.9.99.145) with Microsoft SMTP Server id
	14.1.225.23; Fri, 3 Feb 2012 16:48:36 +0000
X-WSS-ID: 0LYTTCY-01-B1E-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 20FB310280EF;	Fri,  3 Feb 2012 10:48:34 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 3 Feb 2012 10:48:53 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	10:48:34 -0600
Message-ID: <4F2C0FE1.3030304@amd.com>
Date: Fri, 3 Feb 2012 11:48:33 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
	<4F2C079E.6070404@amd.com>
	<4F2C18A40200007800071223@nat28.tlf.novell.com>
In-Reply-To: <4F2C18A40200007800071223@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/12 11:25, Jan Beulich wrote:
>>>> On 03.02.12 at 17:13, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> On 02/03/12 02:53, Jan Beulich wrote:
>>>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>> On 02/02/12 08:22, Jan Beulich wrote:
>>>>> As I was about to apply this to my local tree to give it a try, I had
>>>>> to realize that the microcode integration is still not correct: There
>>>>> is (at least from an abstract perspective) no guarantee for
>>>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>>>> to not deal with this in a formally correct way, it should be stated
>>>>> so in a code comment (to lower the risk of surprises when someone
>>>>> touches that code) that this is not possible in practice because
>>>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>>>
>>>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>>>> may be cases when svm_host_osvw_init() is called multiple times for the
>>>> same cpu but that should be harmless (and the routine will be renamed to
>>>> svm_host_osvw_update()).
>>>
>>> Wouldn't that result in workaround bits that might get cleared with
>>> the pending microcode update to get (and remain) set, as they're
>>> being or-ed together over all invocations of the function after any
>>> svm_host_osvw_reset()?
>>
>>
>> I think that would be an OK but not optimal situation: more bits will
>> end up being set than necessary, meaning that workarounds will need to
>> be applied where they may not be required. But that should not affect
>> correctness. I am not sure it's worth optimizing for this case since I
>> think onlining a core while doing a microcode update is a rather
>> uncommon occurrence.
>
> How is that related to CPU onlining? If you put the call into
> collect_cpu_info(), that'll affect all CPUs currently online as well
> (and, as I said, negate the effect of possibly cleared OSVW bits
> that the pending microcode updated might have). The only case
> where calling svm_host_osvw_init() from collect_cpu_info() would
> be correct is if the latter returns an error. Which, as I noted
> before, can only happen for non-AMD or pre-Fam10 CPUs (on
> all of which calling the function is pointless). So we're back to me
> asking that this simply be explained in a code comment in lieu of
> a proper abstraction of the situation.


OK, I misunderstood your original comment then. I thought you were 
talking about a race between microcode update and onlining a core.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtMSd-0005P0-TC; Fri, 03 Feb 2012 16:58:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RtMSc-0005Ov-TF
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:58:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328288279!9993578!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23478 invoked from network); 3 Feb 2012 16:58:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 16:58:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13GvuLW008925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 16:57: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
	q13Gvt24011105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 16:57:56 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
	q13GvsCr001299; Fri, 3 Feb 2012 10:57:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 08:57:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B90CB40334; Fri,  3 Feb 2012 11:55:16 -0500 (EST)
Date: Fri, 3 Feb 2012 11:55:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120203165516.GA20005@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F2C1215.0081,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> 

So this does the job but with this patch you introduce a compile bisection
bug, which is a not good. The way around is that in this patch you also
introduce temporary scaffolding so that the drivers can build. Something
as simple as an function that calls the new version, but has the right
arguments. Then the next patch (the one that actually does change
the backends, will back that wrapper out).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16: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.xensource.com>)
	id 1RtMSd-0005P0-TC; Fri, 03 Feb 2012 16:58:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RtMSc-0005Ov-TF
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:58:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328288279!9993578!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23478 invoked from network); 3 Feb 2012 16:58:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 16:58:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13GvuLW008925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 16:57: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
	q13Gvt24011105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 16:57:56 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
	q13GvsCr001299; Fri, 3 Feb 2012 10:57:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 08:57:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B90CB40334; Fri,  3 Feb 2012 11:55:16 -0500 (EST)
Date: Fri, 3 Feb 2012 11:55:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120203165516.GA20005@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F2C1215.0081,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> 

So this does the job but with this patch you introduce a compile bisection
bug, which is a not good. The way around is that in this patch you also
introduce temporary scaffolding so that the drivers can build. Something
as simple as an function that calls the new version, but has the right
arguments. Then the next patch (the one that actually does change
the backends, will back that wrapper out).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtMTy-0005T3-CF; Fri, 03 Feb 2012 16:59:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtMTx-0005Si-Bl
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:59:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328288362!11886219!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14151 invoked from network); 3 Feb 2012 16:59:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:59:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:59:21 +0000
Message-Id: <4F2C20780200007800071273@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:59:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
	<4F2C079E.6070404@amd.com>
	<4F2C18A40200007800071223@nat28.tlf.novell.com>
	<4F2C0FE1.3030304@amd.com>
In-Reply-To: <4F2C0FE1.3030304@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 17:48, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/03/12 11:25, Jan Beulich wrote:
>>>>> On 03.02.12 at 17:13, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> On 02/03/12 02:53, Jan Beulich wrote:
>>>>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>>> On 02/02/12 08:22, Jan Beulich wrote:
>>>>>> As I was about to apply this to my local tree to give it a try, I had
>>>>>> to realize that the microcode integration is still not correct: There
>>>>>> is (at least from an abstract perspective) no guarantee for
>>>>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>>>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>>>>> to not deal with this in a formally correct way, it should be stated
>>>>>> so in a code comment (to lower the risk of surprises when someone
>>>>>> touches that code) that this is not possible in practice because
>>>>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>>>>
>>>>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>>>>> may be cases when svm_host_osvw_init() is called multiple times for the
>>>>> same cpu but that should be harmless (and the routine will be renamed to
>>>>> svm_host_osvw_update()).
>>>>
>>>> Wouldn't that result in workaround bits that might get cleared with
>>>> the pending microcode update to get (and remain) set, as they're
>>>> being or-ed together over all invocations of the function after any
>>>> svm_host_osvw_reset()?
>>>
>>>
>>> I think that would be an OK but not optimal situation: more bits will
>>> end up being set than necessary, meaning that workarounds will need to
>>> be applied where they may not be required. But that should not affect
>>> correctness. I am not sure it's worth optimizing for this case since I
>>> think onlining a core while doing a microcode update is a rather
>>> uncommon occurrence.
>>
>> How is that related to CPU onlining? If you put the call into
>> collect_cpu_info(), that'll affect all CPUs currently online as well
>> (and, as I said, negate the effect of possibly cleared OSVW bits
>> that the pending microcode updated might have). The only case
>> where calling svm_host_osvw_init() from collect_cpu_info() would
>> be correct is if the latter returns an error. Which, as I noted
>> before, can only happen for non-AMD or pre-Fam10 CPUs (on
>> all of which calling the function is pointless). So we're back to me
>> asking that this simply be explained in a code comment in lieu of
>> a proper abstraction of the situation.
> 
> 
> OK, I misunderstood your original comment then. I thought you were 
> talking about a race between microcode update and onlining a core.

That was a second concern, easily taken care of by adding locking
in _init() and _reset().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 16:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 16:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtMTy-0005T3-CF; Fri, 03 Feb 2012 16:59:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RtMTx-0005Si-Bl
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 16:59:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328288362!11886219!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14151 invoked from network); 3 Feb 2012 16:59:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 16:59:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 03 Feb 2012 16:59:21 +0000
Message-Id: <4F2C20780200007800071273@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 03 Feb 2012 16:59:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <789bbf4f478b0e81d712.1328113814@wotan.osrc.amd.com>
	<4F2A9C1C0200007800070823@nat28.tlf.novell.com>
	<4F2AF21C.3090305@amd.com>
	<4F2BA08C0200007800070AC9@nat28.tlf.novell.com>
	<4F2C079E.6070404@amd.com>
	<4F2C18A40200007800071223@nat28.tlf.novell.com>
	<4F2C0FE1.3030304@amd.com>
In-Reply-To: <4F2C0FE1.3030304@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v4] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 03.02.12 at 17:48, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/03/12 11:25, Jan Beulich wrote:
>>>>> On 03.02.12 at 17:13, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> On 02/03/12 02:53, Jan Beulich wrote:
>>>>>>> On 02.02.12 at 21:29, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>>> On 02/02/12 08:22, Jan Beulich wrote:
>>>>>> As I was about to apply this to my local tree to give it a try, I had
>>>>>> to realize that the microcode integration is still not correct: There
>>>>>> is (at least from an abstract perspective) no guarantee for
>>>>>> cpu_request_microcode() to be called on all CPUs, yet you want
>>>>>> svm_host_osvw_init() to be re-run on all of them. If you choose
>>>>>> to not deal with this in a formally correct way, it should be stated
>>>>>> so in a code comment (to lower the risk of surprises when someone
>>>>>> touches that code) that this is not possible in practice because
>>>>>> collect_cpu_info() won't currently fail for CPUs of interest.
>>>>>
>>>>> What if svm_host_osvw_init() is called from collect_cpu_info()? There
>>>>> may be cases when svm_host_osvw_init() is called multiple times for the
>>>>> same cpu but that should be harmless (and the routine will be renamed to
>>>>> svm_host_osvw_update()).
>>>>
>>>> Wouldn't that result in workaround bits that might get cleared with
>>>> the pending microcode update to get (and remain) set, as they're
>>>> being or-ed together over all invocations of the function after any
>>>> svm_host_osvw_reset()?
>>>
>>>
>>> I think that would be an OK but not optimal situation: more bits will
>>> end up being set than necessary, meaning that workarounds will need to
>>> be applied where they may not be required. But that should not affect
>>> correctness. I am not sure it's worth optimizing for this case since I
>>> think onlining a core while doing a microcode update is a rather
>>> uncommon occurrence.
>>
>> How is that related to CPU onlining? If you put the call into
>> collect_cpu_info(), that'll affect all CPUs currently online as well
>> (and, as I said, negate the effect of possibly cleared OSVW bits
>> that the pending microcode updated might have). The only case
>> where calling svm_host_osvw_init() from collect_cpu_info() would
>> be correct is if the latter returns an error. Which, as I noted
>> before, can only happen for non-AMD or pre-Fam10 CPUs (on
>> all of which calling the function is pointless). So we're back to me
>> asking that this simply be explained in a code comment in lieu of
>> a proper abstraction of the situation.
> 
> 
> OK, I misunderstood your original comment then. I thought you were 
> talking about a race between microcode update and onlining a core.

That was a second concern, easily taken care of by adding locking
in _init() and _reset().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 17:20:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 17:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtMo0-0005xq-AA; Fri, 03 Feb 2012 17:20:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RtMny-0005wl-HU
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 17:20:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328289604!13633915!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24768 invoked from network); 3 Feb 2012 17:20:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 17:20:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10479190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 17:20:04 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	17:20:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120203165516.GA20005@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
Date: Fri, 3 Feb 2012 17:20:25 +0000
Message-ID: <1328289625.7388.38.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> > 
> 
> So this does the job but with this patch you introduce a compile bisection
> bug, which is a not good. The way around is that in this patch you also
> introduce temporary scaffolding so that the drivers can build. Something
> as simple as an function that calls the new version, but has the right
> arguments. Then the next patch (the one that actually does change
> the backends, will back that wrapper out).
> 

How about squashing these two patches. The changes in backends are
trivial.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 17:20:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 17:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtMo0-0005xq-AA; Fri, 03 Feb 2012 17:20:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RtMny-0005wl-HU
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 17:20:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328289604!13633915!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24768 invoked from network); 3 Feb 2012 17:20:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 17:20:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="10479190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 17:20:04 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 3 Feb 2012
	17:20:04 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120203165516.GA20005@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
Date: Fri, 3 Feb 2012 17:20:25 +0000
Message-ID: <1328289625.7388.38.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> > 
> 
> So this does the job but with this patch you introduce a compile bisection
> bug, which is a not good. The way around is that in this patch you also
> introduce temporary scaffolding so that the drivers can build. Something
> as simple as an function that calls the new version, but has the right
> arguments. Then the next patch (the one that actually does change
> the backends, will back that wrapper out).
> 

How about squashing these two patches. The changes in backends are
trivial.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 17:39:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 17:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtN5x-0006B7-1Q; Fri, 03 Feb 2012 17:38:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RtN5v-0006B2-FX
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 17:38:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328290705!13405324!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7811 invoked from network); 3 Feb 2012 17:38:37 -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; 3 Feb 2012 17:38:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13HcNL5030006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 17:38:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q13HcMoC008110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 17:38:22 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
	q13HcMIZ028787; Fri, 3 Feb 2012 11:38:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 09:38:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6964540461; Fri,  3 Feb 2012 12:35:43 -0500 (EST)
Date: Fri, 3 Feb 2012 12:35:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120203173543.GA2391@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
	<1328289625.7388.38.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328289625.7388.38.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F2C1B90.004A,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 05:20:25PM +0000, Wei Liu wrote:
> On Fri, 2012-02-03 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> > > 
> > 
> > So this does the job but with this patch you introduce a compile bisection
> > bug, which is a not good. The way around is that in this patch you also
> > introduce temporary scaffolding so that the drivers can build. Something
> > as simple as an function that calls the new version, but has the right
> > arguments. Then the next patch (the one that actually does change
> > the backends, will back that wrapper out).
> > 
> 
> How about squashing these two patches. The changes in backends are
> trivial.

That could be done as well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 17:39:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 17:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtN5x-0006B7-1Q; Fri, 03 Feb 2012 17:38:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RtN5v-0006B2-FX
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 17:38:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328290705!13405324!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7811 invoked from network); 3 Feb 2012 17:38:37 -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; 3 Feb 2012 17:38:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13HcNL5030006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 17:38:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q13HcMoC008110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 17:38:22 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
	q13HcMIZ028787; Fri, 3 Feb 2012 11:38:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 09:38:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6964540461; Fri,  3 Feb 2012 12:35:43 -0500 (EST)
Date: Fri, 3 Feb 2012 12:35:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120203173543.GA2391@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
	<1328289625.7388.38.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328289625.7388.38.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F2C1B90.004A,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 05:20:25PM +0000, Wei Liu wrote:
> On Fri, 2012-02-03 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> > > 
> > 
> > So this does the job but with this patch you introduce a compile bisection
> > bug, which is a not good. The way around is that in this patch you also
> > introduce temporary scaffolding so that the drivers can build. Something
> > as simple as an function that calls the new version, but has the right
> > arguments. Then the next patch (the one that actually does change
> > the backends, will back that wrapper out).
> > 
> 
> How about squashing these two patches. The changes in backends are
> trivial.

That could be done as well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 18:10:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 18:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtNaD-0007JB-CL; Fri, 03 Feb 2012 18:10:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RtNaC-0007Ix-12
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 18:10:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328292593!13881113!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDIyODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29282 invoked from network); 3 Feb 2012 18:09:54 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 18:09:54 -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 3136E186A;
	Fri,  3 Feb 2012 20:09:53 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EA0C820056; Fri,  3 Feb 2012 20:09:52 +0200 (EET)
Date: Fri, 3 Feb 2012 20:09:52 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xensource.com
Message-ID: <20120203180952.GP12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
	Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

IIRC there was some discussion earlier about these messages in Xen's dmesg:

(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.

At least on my systems there's continuous flood of those messages, so they will fill up the
Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuable information, just those messages.

I seem to be getting those messages even when there's only dom0 running.
Is the plan to drop those messages? What's causing them? 

hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=470035,
they're related to dom0 kernel acpi-cpufreq ?

Also it seems there was discussion about the subject on 2011/08:
http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00561.html


Xen hypervisor 4.1.2.
dom0 Linux kernel 3.2.2.


Thanks,

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 18:10:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 18:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtNaD-0007JB-CL; Fri, 03 Feb 2012 18:10:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RtNaC-0007Ix-12
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 18:10:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328292593!13881113!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDIyODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29282 invoked from network); 3 Feb 2012 18:09:54 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 18:09:54 -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 3136E186A;
	Fri,  3 Feb 2012 20:09:53 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EA0C820056; Fri,  3 Feb 2012 20:09:52 +0200 (EET)
Date: Fri, 3 Feb 2012 20:09:52 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xensource.com
Message-ID: <20120203180952.GP12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
	Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

IIRC there was some discussion earlier about these messages in Xen's dmesg:

(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.

At least on my systems there's continuous flood of those messages, so they will fill up the
Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuable information, just those messages.

I seem to be getting those messages even when there's only dom0 running.
Is the plan to drop those messages? What's causing them? 

hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=470035,
they're related to dom0 kernel acpi-cpufreq ?

Also it seems there was discussion about the subject on 2011/08:
http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00561.html


Xen hypervisor 4.1.2.
dom0 Linux kernel 3.2.2.


Thanks,

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 18:58:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 18: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.xensource.com>)
	id 1RtOL4-0000NS-NN; Fri, 03 Feb 2012 18:58:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RtOL2-0000ND-La
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 18:58:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328295496!6301299!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyOTg5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15727 invoked from network); 3 Feb 2012 18:58:18 -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; 3 Feb 2012 18:58:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13Iw6Bl013518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 18:58:07 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
	q13Iw6ts005758
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 18:58:06 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
	q13Iw5vv022345; Fri, 3 Feb 2012 12:58:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 10:58:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7A76F40B35; Fri,  3 Feb 2012 13:55:27 -0500 (EST)
Date: Fri, 3 Feb 2012 13:55:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120203185527.GA9290@phenom.dumpdata.com>
References: <20120203180952.GP12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120203180952.GP12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F2C2E3F.00A4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
 Domain attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> IIRC there was some discussion earlier about these messages in Xen's dmes=
g:
> =

> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> =

> At least on my systems there's continuous flood of those messages, so the=
y will fill up the
> Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuable=
 information, just those messages.

Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
which is the intel_ips driver doing.

> =

> I seem to be getting those messages even when there's only dom0 running.
> Is the plan to drop those messages? What's causing them? =


Looks to be the intel-ips. If you rename it does the issue disappear?
> =

> hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cgi?=
id=3D470035,
> they're related to dom0 kernel acpi-cpufreq ?
> =

> Also it seems there was discussion about the subject on 2011/08:
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00561=
.html
> =

> =

> Xen hypervisor 4.1.2.
> dom0 Linux kernel 3.2.2.
> =

> =

> Thanks,
> =

> -- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 18:58:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 18: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.xensource.com>)
	id 1RtOL4-0000NS-NN; Fri, 03 Feb 2012 18:58:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RtOL2-0000ND-La
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 18:58:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328295496!6301299!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyOTg5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15727 invoked from network); 3 Feb 2012 18:58:18 -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; 3 Feb 2012 18:58:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13Iw6Bl013518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 18:58:07 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
	q13Iw6ts005758
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 18:58:06 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
	q13Iw5vv022345; Fri, 3 Feb 2012 12:58:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 10:58:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7A76F40B35; Fri,  3 Feb 2012 13:55:27 -0500 (EST)
Date: Fri, 3 Feb 2012 13:55:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120203185527.GA9290@phenom.dumpdata.com>
References: <20120203180952.GP12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120203180952.GP12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F2C2E3F.00A4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
 Domain attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> IIRC there was some discussion earlier about these messages in Xen's dmes=
g:
> =

> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000=
000000c800c8 to 0x0000000080c880c8.
> =

> At least on my systems there's continuous flood of those messages, so the=
y will fill up the
> Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuable=
 information, just those messages.

Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
which is the intel_ips driver doing.

> =

> I seem to be getting those messages even when there's only dom0 running.
> Is the plan to drop those messages? What's causing them? =


Looks to be the intel-ips. If you rename it does the issue disappear?
> =

> hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cgi?=
id=3D470035,
> they're related to dom0 kernel acpi-cpufreq ?
> =

> Also it seems there was discussion about the subject on 2011/08:
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00561=
.html
> =

> =

> Xen hypervisor 4.1.2.
> dom0 Linux kernel 3.2.2.
> =

> =

> Thanks,
> =

> -- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObj-0000c9-P3; Fri, 03 Feb 2012 19:15:39 +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 1RtObi-0000c0-9P
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4913 invoked from network); 3 Feb 2012 19:14:48 -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;
	3 Feb 2012 19:14:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612430"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:36 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVps011693;
	Fri, 3 Feb 2012 11:15:35 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:12 +0000
Message-ID: <1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial page
	tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add a 1:1 mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/head.S |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9951f37..8385481 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -202,6 +202,11 @@ hyp:
 	add   r4, r4, #8
 	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #endif
+	mov   r3, #0x0
+	orr   r2, r8, #0xe00
+	orr   r2, r2, #0x07d
+	mov   r4, r8, lsr #18        /* Slot for (r8 == atag_paddr) */
+	strd  r2, r3, [r1, r4]       /* Map DTB there */
 
 	PRINT("- Turning on paging -\r\n")
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObr-0000eW-UF; Fri, 03 Feb 2012 19:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObo-0000c7-VZ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328296535!6302620!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14966 invoked from network); 3 Feb 2012 19:15:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 19:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:33 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpp011693;
	Fri, 3 Feb 2012 11:15:32 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:09 +0000
Message-ID: <1328296515-25876-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/7] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git

This will be used by Xen to parse the DTBs provided by bootloaders on
ARM platforms.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/Makefile.libfdt   |   10 +
 xen/common/libfdt/TODO              |    3 +
 xen/common/libfdt/fdt.c             |  222 +++++++
 xen/common/libfdt/fdt.h             |   60 ++
 xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
 xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
 xen/common/libfdt/fdt_strerror.c    |   96 +++
 xen/common/libfdt/fdt_sw.c          |  256 ++++++++
 xen/common/libfdt/fdt_wip.c         |  118 ++++
 xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
 xen/common/libfdt/libfdt_env.h      |   23 +
 xen/common/libfdt/libfdt_internal.h |   95 +++
 xen/common/libfdt/version.lds       |   54 ++
 13 files changed, 3211 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile.libfdt
 create mode 100644 xen/common/libfdt/TODO
 create mode 100644 xen/common/libfdt/fdt.c
 create mode 100644 xen/common/libfdt/fdt.h
 create mode 100644 xen/common/libfdt/fdt_ro.c
 create mode 100644 xen/common/libfdt/fdt_rw.c
 create mode 100644 xen/common/libfdt/fdt_strerror.c
 create mode 100644 xen/common/libfdt/fdt_sw.c
 create mode 100644 xen/common/libfdt/fdt_wip.c
 create mode 100644 xen/common/libfdt/libfdt.h
 create mode 100644 xen/common/libfdt/libfdt_env.h
 create mode 100644 xen/common/libfdt/libfdt_internal.h
 create mode 100644 xen/common/libfdt/version.lds

diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
new file mode 100644
index 0000000..d55a6f8
--- /dev/null
+++ b/xen/common/libfdt/Makefile.libfdt
@@ -0,0 +1,10 @@
+# Makefile.libfdt
+#
+# This is not a complete Makefile of itself.  Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_VERSION = version.lds
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
new file mode 100644
index 0000000..288437e
--- /dev/null
+++ b/xen/common/libfdt/TODO
@@ -0,0 +1,3 @@
+- Tree traversal functions
+- Graft function
+- Complete libfdt.h documenting comments
diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
new file mode 100644
index 0000000..e56833a
--- /dev/null
+++ b/xen/common/libfdt/fdt.c
@@ -0,0 +1,222 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_check_header(const void *fdt)
+{
+	if (fdt_magic(fdt) == FDT_MAGIC) {
+		/* Complete tree */
+		if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+		if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+	} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+		/* Unfinished sequential-write blob */
+		if (fdt_size_dt_struct(fdt) == 0)
+			return -FDT_ERR_BADSTATE;
+	} else {
+		return -FDT_ERR_BADMAGIC;
+	}
+
+	return 0;
+}
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
+{
+	const char *p;
+
+	if (fdt_version(fdt) >= 0x11)
+		if (((offset + len) < offset)
+		    || ((offset + len) > fdt_size_dt_struct(fdt)))
+			return NULL;
+
+	p = _fdt_offset_ptr(fdt, offset);
+
+	if (p + len < p)
+		return NULL;
+	return p;
+}
+
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+	const uint32_t *tagp, *lenp;
+	uint32_t tag;
+	int offset = startoffset;
+	const char *p;
+
+	*nextoffset = -FDT_ERR_TRUNCATED;
+	tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
+	if (!tagp)
+		return FDT_END; /* premature end */
+	tag = fdt32_to_cpu(*tagp);
+	offset += FDT_TAGSIZE;
+
+	*nextoffset = -FDT_ERR_BADSTRUCTURE;
+	switch (tag) {
+	case FDT_BEGIN_NODE:
+		/* skip name */
+		do {
+			p = fdt_offset_ptr(fdt, offset++, 1);
+		} while (p && (*p != '\0'));
+		if (!p)
+			return FDT_END; /* premature end */
+		break;
+
+	case FDT_PROP:
+		lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
+		if (!lenp)
+			return FDT_END; /* premature end */
+		/* skip-name offset, length and value */
+		offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+			+ fdt32_to_cpu(*lenp);
+		break;
+
+	case FDT_END:
+	case FDT_END_NODE:
+	case FDT_NOP:
+		break;
+
+	default:
+		return FDT_END;
+	}
+
+	if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
+		return FDT_END; /* premature end */
+
+	*nextoffset = FDT_TAGALIGN(offset);
+	return tag;
+}
+
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int _fdt_check_prop_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int fdt_next_node(const void *fdt, int offset, int *depth)
+{
+	int nextoffset = 0;
+	uint32_t tag;
+
+	if (offset >= 0)
+		if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+			return nextoffset;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_PROP:
+		case FDT_NOP:
+			break;
+
+		case FDT_BEGIN_NODE:
+			if (depth)
+				(*depth)++;
+			break;
+
+		case FDT_END_NODE:
+			if (depth && ((--(*depth)) < 0))
+				return nextoffset;
+			break;
+
+		case FDT_END:
+			if ((nextoffset >= 0)
+			    || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
+				return -FDT_ERR_NOTFOUND;
+			else
+				return nextoffset;
+		}
+	} while (tag != FDT_BEGIN_NODE);
+
+	return offset;
+}
+
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+{
+	int len = strlen(s) + 1;
+	const char *last = strtab + tabsize - len;
+	const char *p;
+
+	for (p = strtab; p <= last; p++)
+		if (memcmp(p, s, len) == 0)
+			return p;
+	return NULL;
+}
+
+int fdt_move(const void *fdt, void *buf, int bufsize)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_totalsize(fdt) > bufsize)
+		return -FDT_ERR_NOSPACE;
+
+	memmove(buf, fdt, fdt_totalsize(fdt));
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
new file mode 100644
index 0000000..48ccfd9
--- /dev/null
+++ b/xen/common/libfdt/fdt.h
@@ -0,0 +1,60 @@
+#ifndef _FDT_H
+#define _FDT_H
+
+#ifndef __ASSEMBLY__
+
+struct fdt_header {
+	uint32_t magic;			 /* magic word FDT_MAGIC */
+	uint32_t totalsize;		 /* total size of DT block */
+	uint32_t off_dt_struct;		 /* offset to structure */
+	uint32_t off_dt_strings;	 /* offset to strings */
+	uint32_t off_mem_rsvmap;	 /* offset to memory reserve map */
+	uint32_t version;		 /* format version */
+	uint32_t last_comp_version;	 /* last compatible version */
+
+	/* version 2 fields below */
+	uint32_t boot_cpuid_phys;	 /* Which physical CPU id we're
+					    booting on */
+	/* version 3 fields below */
+	uint32_t size_dt_strings;	 /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;	 /* size of the structure block */
+};
+
+struct fdt_reserve_entry {
+	uint64_t address;
+	uint64_t size;
+};
+
+struct fdt_node_header {
+	uint32_t tag;
+	char name[0];
+};
+
+struct fdt_property {
+	uint32_t tag;
+	uint32_t len;
+	uint32_t nameoff;
+	char data[0];
+};
+
+#endif /* !__ASSEMBLY */
+
+#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_TAGSIZE	sizeof(uint32_t)
+
+#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
+#define FDT_END_NODE	0x2		/* End node */
+#define FDT_PROP	0x3		/* Property: name off,
+					   size, content */
+#define FDT_NOP		0x4		/* nop */
+#define FDT_END		0x9
+
+#define FDT_V1_SIZE	(7*sizeof(uint32_t))
+#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(uint32_t))
+#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V16_SIZE	FDT_V3_SIZE
+#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(uint32_t))
+
+#endif /* _FDT_H */
diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
new file mode 100644
index 0000000..02b6d68
--- /dev/null
+++ b/xen/common/libfdt/fdt_ro.c
@@ -0,0 +1,574 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_nodename_eq(const void *fdt, int offset,
+			    const char *s, int len)
+{
+	const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+
+	if (! p)
+		/* short match */
+		return 0;
+
+	if (memcmp(p, s, len) != 0)
+		return 0;
+
+	if (p[len] == '\0')
+		return 1;
+	else if (!memchr(s, '@', len) && (p[len] == '@'))
+		return 1;
+	else
+		return 0;
+}
+
+const char *fdt_string(const void *fdt, int stroffset)
+{
+	return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+}
+
+static int _fdt_string_eq(const void *fdt, int stroffset,
+			  const char *s, int len)
+{
+	const char *p = fdt_string(fdt, stroffset);
+
+	return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+}
+
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
+{
+	FDT_CHECK_HEADER(fdt);
+	*address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
+	*size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+	return 0;
+}
+
+int fdt_num_mem_rsv(const void *fdt)
+{
+	int i = 0;
+
+	while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+		i++;
+	return i;
+}
+
+static int _nextprop(const void *fdt, int offset)
+{
+	uint32_t tag;
+	int nextoffset;
+
+	do {
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_END:
+			if (nextoffset >= 0)
+				return -FDT_ERR_BADSTRUCTURE;
+			else
+				return nextoffset;
+
+		case FDT_PROP:
+			return offset;
+		}
+		offset = nextoffset;
+	} while (tag == FDT_NOP);
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
+			       const char *name, int namelen)
+{
+	int depth;
+
+	FDT_CHECK_HEADER(fdt);
+
+	for (depth = 0;
+	     (offset >= 0) && (depth >= 0);
+	     offset = fdt_next_node(fdt, offset, &depth))
+		if ((depth == 1)
+		    && _fdt_nodename_eq(fdt, offset, name, namelen))
+			return offset;
+
+	if (depth < 0)
+		return -FDT_ERR_NOTFOUND;
+	return offset; /* error */
+}
+
+int fdt_subnode_offset(const void *fdt, int parentoffset,
+		       const char *name)
+{
+	return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_path_offset(const void *fdt, const char *path)
+{
+	const char *end = path + strlen(path);
+	const char *p = path;
+	int offset = 0;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* see if we have an alias */
+	if (*path != '/') {
+		const char *q = strchr(path, '/');
+
+		if (!q)
+			q = end;
+
+		p = fdt_get_alias_namelen(fdt, p, q - p);
+		if (!p)
+			return -FDT_ERR_BADPATH;
+		offset = fdt_path_offset(fdt, p);
+
+		p = q;
+	}
+
+	while (*p) {
+		const char *q;
+
+		while (*p == '/')
+			p++;
+		if (! *p)
+			return offset;
+		q = strchr(p, '/');
+		if (! q)
+			q = end;
+
+		offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
+		if (offset < 0)
+			return offset;
+
+		p = q;
+	}
+
+	return offset;
+}
+
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+	const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
+	int err;
+
+	if (((err = fdt_check_header(fdt)) != 0)
+	    || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+			goto fail;
+
+	if (len)
+		*len = strlen(nh->name);
+
+	return nh->name;
+
+ fail:
+	if (len)
+		*len = err;
+	return NULL;
+}
+
+int fdt_first_property_offset(const void *fdt, int nodeoffset)
+{
+	int offset;
+
+	if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+int fdt_next_property_offset(const void *fdt, int offset)
+{
+	if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp)
+{
+	int err;
+	const struct fdt_property *prop;
+
+	if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
+		if (lenp)
+			*lenp = err;
+		return NULL;
+	}
+
+	prop = _fdt_offset_ptr(fdt, offset);
+
+	if (lenp)
+		*lenp = fdt32_to_cpu(prop->len);
+
+	return prop;
+}
+
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int offset,
+						    const char *name,
+						    int namelen, int *lenp)
+{
+	for (offset = fdt_first_property_offset(fdt, offset);
+	     (offset >= 0);
+	     (offset = fdt_next_property_offset(fdt, offset))) {
+		const struct fdt_property *prop;
+
+		if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
+			offset = -FDT_ERR_INTERNAL;
+			break;
+		}
+		if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
+				   name, namelen))
+			return prop;
+	}
+
+	if (lenp)
+		*lenp = offset;
+	return NULL;
+}
+
+const struct fdt_property *fdt_get_property(const void *fdt,
+					    int nodeoffset,
+					    const char *name, int *lenp)
+{
+	return fdt_get_property_namelen(fdt, nodeoffset, name,
+					strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
+	if (! prop)
+		return NULL;
+
+	return prop->data;
+}
+
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_by_offset(fdt, offset, lenp);
+	if (!prop)
+		return NULL;
+	if (namep)
+		*namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+	return prop->data;
+}
+
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp)
+{
+	return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
+{
+	const uint32_t *php;
+	int len;
+
+	/* FIXME: This is a bit sub-optimal, since we potentially scan
+	 * over all the properties twice. */
+	php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
+	if (!php || (len != sizeof(*php))) {
+		php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
+		if (!php || (len != sizeof(*php)))
+			return 0;
+	}
+
+	return fdt32_to_cpu(*php);
+}
+
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen)
+{
+	int aliasoffset;
+
+	aliasoffset = fdt_path_offset(fdt, "/aliases");
+	if (aliasoffset < 0)
+		return NULL;
+
+	return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+	return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+	int pdepth = 0, p = 0;
+	int offset, depth, namelen;
+	const char *name;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (buflen < 2)
+		return -FDT_ERR_NOSPACE;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		while (pdepth > depth) {
+			do {
+				p--;
+			} while (buf[p-1] != '/');
+			pdepth--;
+		}
+
+		if (pdepth >= depth) {
+			name = fdt_get_name(fdt, offset, &namelen);
+			if (!name)
+				return namelen;
+			if ((p + namelen + 1) <= buflen) {
+				memcpy(buf + p, name, namelen);
+				p += namelen;
+				buf[p++] = '/';
+				pdepth++;
+			}
+		}
+
+		if (offset == nodeoffset) {
+			if (pdepth < (depth + 1))
+				return -FDT_ERR_NOSPACE;
+
+			if (p > 1) /* special case so that root path is "/", not "" */
+				p--;
+			buf[p] = '\0';
+			return 0;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth)
+{
+	int offset, depth;
+	int supernodeoffset = -FDT_ERR_INTERNAL;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (supernodedepth < 0)
+		return -FDT_ERR_NOTFOUND;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		if (depth == supernodedepth)
+			supernodeoffset = offset;
+
+		if (offset == nodeoffset) {
+			if (nodedepth)
+				*nodedepth = depth;
+
+			if (supernodedepth > depth)
+				return -FDT_ERR_NOTFOUND;
+			else
+				return supernodeoffset;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+	int nodedepth;
+	int err;
+
+	err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+	if (err)
+		return (err < 0) ? err : -FDT_ERR_INTERNAL;
+	return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+	int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+	if (nodedepth < 0)
+		return nodedepth;
+	return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+					    nodedepth - 1, NULL);
+}
+
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen)
+{
+	int offset;
+	const void *val;
+	int len;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_getprop(), then if that didn't
+	 * find what we want, we scan over them again making our way
+	 * to the next node.  Still it's the easiest to implement
+	 * approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		val = fdt_getprop(fdt, offset, propname, &len);
+		if (val && (len == proplen)
+		    && (memcmp(val, propval, len) == 0))
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
+{
+	int offset;
+
+	if ((phandle == 0) || (phandle == -1))
+		return -FDT_ERR_BADPHANDLE;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we
+	 * potentially scan each property of a node in
+	 * fdt_get_phandle(), then if that didn't find what
+	 * we want, we scan over them again making our way to the next
+	 * node.  Still it's the easiest to implement approach;
+	 * performance can come later. */
+	for (offset = fdt_next_node(fdt, -1, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		if (fdt_get_phandle(fdt, offset) == phandle)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+				    const char *str)
+{
+	int len = strlen(str);
+	const char *p;
+
+	while (listlen >= len) {
+		if (memcmp(str, strlist, len+1) == 0)
+			return 1;
+		p = memchr(strlist, '\0', listlen);
+		if (!p)
+			return 0; /* malformed strlist.. */
+		listlen -= (p-strlist) + 1;
+		strlist = p + 1;
+	}
+	return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible)
+{
+	const void *prop;
+	int len;
+
+	prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+	if (!prop)
+		return len;
+	if (_fdt_stringlist_contains(prop, len, compatible))
+		return 0;
+	else
+		return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible)
+{
+	int offset, err;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_node_check_compatible(), then if
+	 * that didn't find what we want, we scan over them again
+	 * making our way to the next node.  Still it's the easiest to
+	 * implement approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		err = fdt_node_check_compatible(fdt, offset, compatible);
+		if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
+			return err;
+		else if (err == 0)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
new file mode 100644
index 0000000..994037b
--- /dev/null
+++ b/xen/common/libfdt/fdt_rw.c
@@ -0,0 +1,465 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_blocks_misordered(const void *fdt,
+			      int mem_rsv_size, int struct_size)
+{
+	return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
+		|| (fdt_off_dt_struct(fdt) <
+		    (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
+		|| (fdt_off_dt_strings(fdt) <
+		    (fdt_off_dt_struct(fdt) + struct_size))
+		|| (fdt_totalsize(fdt) <
+		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
+}
+
+static int _fdt_rw_check_header(void *fdt)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_version(fdt) < 17)
+		return -FDT_ERR_BADVERSION;
+	if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
+				   fdt_size_dt_struct(fdt)))
+		return -FDT_ERR_BADLAYOUT;
+	if (fdt_version(fdt) > 17)
+		fdt_set_version(fdt, 17);
+
+	return 0;
+}
+
+#define FDT_RW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_rw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static inline int _fdt_data_size(void *fdt)
+{
+	return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+}
+
+static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
+{
+	char *p = splicepoint;
+	char *end = (char *)fdt + _fdt_data_size(fdt);
+
+	if (((p + oldlen) < p) || ((p + oldlen) > end))
+		return -FDT_ERR_BADOFFSET;
+	if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
+		return -FDT_ERR_NOSPACE;
+	memmove(p + newlen, p + oldlen, end - p - oldlen);
+	return 0;
+}
+
+static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
+			       int oldn, int newn)
+{
+	int delta = (newn - oldn) * sizeof(*p);
+	int err;
+	err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
+	if (err)
+		return err;
+	fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_struct(void *fdt, void *p,
+			      int oldlen, int newlen)
+{
+	int delta = newlen - oldlen;
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
+		return err;
+
+	fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_string(void *fdt, int newlen)
+{
+	void *p = (char *)fdt
+		+ fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, 0, newlen)))
+		return err;
+
+	fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
+	const char *p;
+	char *new;
+	int len = strlen(s) + 1;
+	int err;
+
+	p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
+	if (p)
+		/* found it */
+		return (p - strtab);
+
+	new = strtab + fdt_size_dt_strings(fdt);
+	err = _fdt_splice_string(fdt, len);
+	if (err)
+		return err;
+
+	memcpy(new, s, len);
+	return (new - strtab);
+}
+
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
+	err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
+	if (err)
+		return err;
+
+	re->address = cpu_to_fdt64(address);
+	re->size = cpu_to_fdt64(size);
+	return 0;
+}
+
+int fdt_del_mem_rsv(void *fdt, int n)
+{
+	struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	if (n >= fdt_num_mem_rsv(fdt))
+		return -FDT_ERR_NOTFOUND;
+
+	err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
+	if (err)
+		return err;
+	return 0;
+}
+
+static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
+				int len, struct fdt_property **prop)
+{
+	int oldlen;
+	int err;
+
+	*prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
+	if (! (*prop))
+		return oldlen;
+
+	if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
+				      FDT_TAGALIGN(len))))
+		return err;
+
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
+			     int len, struct fdt_property **prop)
+{
+	int proplen;
+	int nextoffset;
+	int namestroff;
+	int err;
+
+	if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return nextoffset;
+
+	namestroff = _fdt_find_add_string(fdt, name);
+	if (namestroff < 0)
+		return namestroff;
+
+	*prop = _fdt_offset_ptr_w(fdt, nextoffset);
+	proplen = sizeof(**prop) + FDT_TAGALIGN(len);
+
+	err = _fdt_splice_struct(fdt, *prop, 0, proplen);
+	if (err)
+		return err;
+
+	(*prop)->tag = cpu_to_fdt32(FDT_PROP);
+	(*prop)->nameoff = cpu_to_fdt32(namestroff);
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+	char *namep;
+	int oldlen, newlen;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
+	if (!namep)
+		return oldlen;
+
+	newlen = strlen(name);
+
+	err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
+				 FDT_TAGALIGN(newlen+1));
+	if (err)
+		return err;
+
+	memcpy(namep, name, newlen+1);
+	return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len)
+{
+	struct fdt_property *prop;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
+	if (err == -FDT_ERR_NOTFOUND)
+		err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
+	if (err)
+		return err;
+
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_delprop(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len, proplen;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	proplen = sizeof(*prop) + FDT_TAGALIGN(len);
+	return _fdt_splice_struct(fdt, prop, proplen, 0);
+}
+
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen)
+{
+	struct fdt_node_header *nh;
+	int offset, nextoffset;
+	int nodelen;
+	int err;
+	uint32_t tag;
+	uint32_t *endtag;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
+	if (offset >= 0)
+		return -FDT_ERR_EXISTS;
+	else if (offset != -FDT_ERR_NOTFOUND)
+		return offset;
+
+	/* Try to place the new node after the parent's properties */
+	fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+	} while ((tag == FDT_PROP) || (tag == FDT_NOP));
+
+	nh = _fdt_offset_ptr_w(fdt, offset);
+	nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
+
+	err = _fdt_splice_struct(fdt, nh, 0, nodelen);
+	if (err)
+		return err;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
+	memcpy(nh->name, name, namelen);
+	endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
+	*endtag = cpu_to_fdt32(FDT_END_NODE);
+
+	return offset;
+}
+
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
+{
+	return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_del_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
+				  endoffset - nodeoffset, 0);
+}
+
+static void _fdt_packblocks(const char *old, char *new,
+			    int mem_rsv_size, int struct_size)
+{
+	int mem_rsv_off, struct_off, strings_off;
+
+	mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
+	struct_off = mem_rsv_off + mem_rsv_size;
+	strings_off = struct_off + struct_size;
+
+	memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
+	fdt_set_off_mem_rsvmap(new, mem_rsv_off);
+
+	memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
+	fdt_set_off_dt_struct(new, struct_off);
+	fdt_set_size_dt_struct(new, struct_size);
+
+	memmove(new + strings_off, old + fdt_off_dt_strings(old),
+		fdt_size_dt_strings(old));
+	fdt_set_off_dt_strings(new, strings_off);
+	fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
+}
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize)
+{
+	int err;
+	int mem_rsv_size, struct_size;
+	int newsize;
+	const char *fdtstart = fdt;
+	const char *fdtend = fdtstart + fdt_totalsize(fdt);
+	char *tmp;
+
+	FDT_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+
+	if (fdt_version(fdt) >= 17) {
+		struct_size = fdt_size_dt_struct(fdt);
+	} else {
+		struct_size = 0;
+		while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
+			;
+		if (struct_size < 0)
+			return struct_size;
+	}
+
+	if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
+		/* no further work necessary */
+		err = fdt_move(fdt, buf, bufsize);
+		if (err)
+			return err;
+		fdt_set_version(buf, 17);
+		fdt_set_size_dt_struct(buf, struct_size);
+		fdt_set_totalsize(buf, bufsize);
+		return 0;
+	}
+
+	/* Need to reorder */
+	newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
+		+ struct_size + fdt_size_dt_strings(fdt);
+
+	if (bufsize < newsize)
+		return -FDT_ERR_NOSPACE;
+
+	/* First attempt to build converted tree at beginning of buffer */
+	tmp = buf;
+	/* But if that overlaps with the old tree... */
+	if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
+		/* Try right after the old tree instead */
+		tmp = (char *)(uintptr_t)fdtend;
+		if ((tmp + newsize) > ((char *)buf + bufsize))
+			return -FDT_ERR_NOSPACE;
+	}
+
+	_fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
+	memmove(buf, tmp, newsize);
+
+	fdt_set_magic(buf, FDT_MAGIC);
+	fdt_set_totalsize(buf, bufsize);
+	fdt_set_version(buf, 17);
+	fdt_set_last_comp_version(buf, 16);
+	fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
+
+	return 0;
+}
+
+int fdt_pack(void *fdt)
+{
+	int mem_rsv_size;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+	_fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
+	fdt_set_totalsize(fdt, _fdt_data_size(fdt));
+
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
new file mode 100644
index 0000000..e6c3cee
--- /dev/null
+++ b/xen/common/libfdt/fdt_strerror.c
@@ -0,0 +1,96 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+struct fdt_errtabent {
+	const char *str;
+};
+
+#define FDT_ERRTABENT(val) \
+	[(val)] = { .str = #val, }
+
+static struct fdt_errtabent fdt_errtable[] = {
+	FDT_ERRTABENT(FDT_ERR_NOTFOUND),
+	FDT_ERRTABENT(FDT_ERR_EXISTS),
+	FDT_ERRTABENT(FDT_ERR_NOSPACE),
+
+	FDT_ERRTABENT(FDT_ERR_BADOFFSET),
+	FDT_ERRTABENT(FDT_ERR_BADPATH),
+	FDT_ERRTABENT(FDT_ERR_BADSTATE),
+
+	FDT_ERRTABENT(FDT_ERR_TRUNCATED),
+	FDT_ERRTABENT(FDT_ERR_BADMAGIC),
+	FDT_ERRTABENT(FDT_ERR_BADVERSION),
+	FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
+	FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+};
+#define FDT_ERRTABSIZE	(sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
+
+const char *fdt_strerror(int errval)
+{
+	if (errval > 0)
+		return "<valid offset/length>";
+	else if (errval == 0)
+		return "<no error>";
+	else if (errval > -FDT_ERRTABSIZE) {
+		const char *s = fdt_errtable[-errval].str;
+
+		if (s)
+			return s;
+	}
+
+	return "<unknown error>";
+}
diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
new file mode 100644
index 0000000..55ebebf
--- /dev/null
+++ b/xen/common/libfdt/fdt_sw.c
@@ -0,0 +1,256 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_sw_check_header(void *fdt)
+{
+	if (fdt_magic(fdt) != FDT_SW_MAGIC)
+		return -FDT_ERR_BADMAGIC;
+	/* FIXME: should check more details about the header state */
+	return 0;
+}
+
+#define FDT_SW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_sw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static void *_fdt_grab_space(void *fdt, size_t len)
+{
+	int offset = fdt_size_dt_struct(fdt);
+	int spaceleft;
+
+	spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
+		- fdt_size_dt_strings(fdt);
+
+	if ((offset + len < offset) || (offset + len > spaceleft))
+		return NULL;
+
+	fdt_set_size_dt_struct(fdt, offset + len);
+	return _fdt_offset_ptr_w(fdt, offset);
+}
+
+int fdt_create(void *buf, int bufsize)
+{
+	void *fdt = buf;
+
+	if (bufsize < sizeof(struct fdt_header))
+		return -FDT_ERR_NOSPACE;
+
+	memset(buf, 0, bufsize);
+
+	fdt_set_magic(fdt, FDT_SW_MAGIC);
+	fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+	fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+	fdt_set_totalsize(fdt,  bufsize);
+
+	fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
+					      sizeof(struct fdt_reserve_entry)));
+	fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
+	fdt_set_off_dt_strings(fdt, bufsize);
+
+	return 0;
+}
+
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int offset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	if (fdt_size_dt_struct(fdt))
+		return -FDT_ERR_BADSTATE;
+
+	offset = fdt_off_dt_struct(fdt);
+	if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
+		return -FDT_ERR_NOSPACE;
+
+	re = (struct fdt_reserve_entry *)((char *)fdt + offset);
+	re->address = cpu_to_fdt64(addr);
+	re->size = cpu_to_fdt64(size);
+
+	fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
+
+	return 0;
+}
+
+int fdt_finish_reservemap(void *fdt)
+{
+	return fdt_add_reservemap_entry(fdt, 0, 0);
+}
+
+int fdt_begin_node(void *fdt, const char *name)
+{
+	struct fdt_node_header *nh;
+	int namelen = strlen(name) + 1;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
+	if (! nh)
+		return -FDT_ERR_NOSPACE;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memcpy(nh->name, name, namelen);
+	return 0;
+}
+
+int fdt_end_node(void *fdt)
+{
+	uint32_t *en;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	en = _fdt_grab_space(fdt, FDT_TAGSIZE);
+	if (! en)
+		return -FDT_ERR_NOSPACE;
+
+	*en = cpu_to_fdt32(FDT_END_NODE);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_totalsize(fdt);
+	const char *p;
+	int strtabsize = fdt_size_dt_strings(fdt);
+	int len = strlen(s) + 1;
+	int struct_top, offset;
+
+	p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
+	if (p)
+		return p - strtab;
+
+	/* Add it */
+	offset = -strtabsize - len;
+	struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	if (fdt_totalsize(fdt) + offset < struct_top)
+		return 0; /* no more room :( */
+
+	memcpy(strtab + offset, s, len);
+	fdt_set_size_dt_strings(fdt, strtabsize + len);
+	return offset;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+	struct fdt_property *prop;
+	int nameoff;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nameoff = _fdt_find_add_string(fdt, name);
+	if (nameoff == 0)
+		return -FDT_ERR_NOSPACE;
+
+	prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
+	if (! prop)
+		return -FDT_ERR_NOSPACE;
+
+	prop->tag = cpu_to_fdt32(FDT_PROP);
+	prop->nameoff = cpu_to_fdt32(nameoff);
+	prop->len = cpu_to_fdt32(len);
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_finish(void *fdt)
+{
+	char *p = (char *)fdt;
+	uint32_t *end;
+	int oldstroffset, newstroffset;
+	uint32_t tag;
+	int offset, nextoffset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	/* Add terminator */
+	end = _fdt_grab_space(fdt, sizeof(*end));
+	if (! end)
+		return -FDT_ERR_NOSPACE;
+	*end = cpu_to_fdt32(FDT_END);
+
+	/* Relocate the string table */
+	oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
+	newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
+	fdt_set_off_dt_strings(fdt, newstroffset);
+
+	/* Walk the structure, correcting string offsets */
+	offset = 0;
+	while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
+		if (tag == FDT_PROP) {
+			struct fdt_property *prop =
+				_fdt_offset_ptr_w(fdt, offset);
+			int nameoff;
+
+			nameoff = fdt32_to_cpu(prop->nameoff);
+			nameoff += fdt_size_dt_strings(fdt);
+			prop->nameoff = cpu_to_fdt32(nameoff);
+		}
+		offset = nextoffset;
+	}
+	if (nextoffset < 0)
+		return nextoffset;
+
+	/* Finally, adjust the header */
+	fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
+	fdt_set_magic(fdt, FDT_MAGIC);
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
new file mode 100644
index 0000000..6025fa1
--- /dev/null
+++ b/xen/common/libfdt/fdt_wip.c
@@ -0,0 +1,118 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len)
+{
+	void *propval;
+	int proplen;
+
+	propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
+	if (! propval)
+		return proplen;
+
+	if (proplen != len)
+		return -FDT_ERR_NOSPACE;
+
+	memcpy(propval, val, len);
+	return 0;
+}
+
+static void _fdt_nop_region(void *start, int len)
+{
+	uint32_t *p;
+
+	for (p = start; (char *)p < ((char *)start + len); p++)
+		*p = cpu_to_fdt32(FDT_NOP);
+}
+
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len;
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	_fdt_nop_region(prop, len + sizeof(*prop));
+
+	return 0;
+}
+
+int _fdt_node_end_offset(void *fdt, int offset)
+{
+	int depth = 0;
+
+	while ((offset >= 0) && (depth >= 0))
+		offset = fdt_next_node(fdt, offset, &depth);
+
+	return offset;
+}
+
+int fdt_nop_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	_fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
+			endoffset - nodeoffset);
+	return 0;
+}
diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
new file mode 100644
index 0000000..55f3eb3
--- /dev/null
+++ b/xen/common/libfdt/libfdt.h
@@ -0,0 +1,1235 @@
+#ifndef _LIBFDT_H
+#define _LIBFDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <libfdt_env.h>
+#include <fdt.h>
+
+#define FDT_FIRST_SUPPORTED_VERSION	0x10
+#define FDT_LAST_SUPPORTED_VERSION	0x11
+
+/* Error codes: informative error codes */
+#define FDT_ERR_NOTFOUND	1
+	/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
+#define FDT_ERR_EXISTS		2
+	/* FDT_ERR_EXISTS: Attemped to create a node or property which
+	 * already exists */
+#define FDT_ERR_NOSPACE		3
+	/* FDT_ERR_NOSPACE: Operation needed to expand the device
+	 * tree, but its buffer did not have sufficient space to
+	 * contain the expanded tree. Use fdt_open_into() to move the
+	 * device tree to a buffer with more space. */
+
+/* Error codes: codes for bad parameters */
+#define FDT_ERR_BADOFFSET	4
+	/* FDT_ERR_BADOFFSET: Function was passed a structure block
+	 * offset which is out-of-bounds, or which points to an
+	 * unsuitable part of the structure for the operation. */
+#define FDT_ERR_BADPATH		5
+	/* FDT_ERR_BADPATH: Function was passed a badly formatted path
+	 * (e.g. missing a leading / for a function which requires an
+	 * absolute path) */
+#define FDT_ERR_BADPHANDLE	6
+	/* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
+	 * value.  phandle values of 0 and -1 are not permitted. */
+#define FDT_ERR_BADSTATE	7
+	/* FDT_ERR_BADSTATE: Function was passed an incomplete device
+	 * tree created by the sequential-write functions, which is
+	 * not sufficiently complete for the requested operation. */
+
+/* Error codes: codes for bad device tree blobs */
+#define FDT_ERR_TRUNCATED	8
+	/* FDT_ERR_TRUNCATED: Structure block of the given device tree
+	 * ends without an FDT_END tag. */
+#define FDT_ERR_BADMAGIC	9
+	/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+	 * device tree at all - it is missing the flattened device
+	 * tree magic number. */
+#define FDT_ERR_BADVERSION	10
+	/* FDT_ERR_BADVERSION: Given device tree has a version which
+	 * can't be handled by the requested operation.  For
+	 * read-write functions, this may mean that fdt_open_into() is
+	 * required to convert the tree to the expected version. */
+#define FDT_ERR_BADSTRUCTURE	11
+	/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+	 * structure block or other serious error (e.g. misnested
+	 * nodes, or subnodes preceding properties). */
+#define FDT_ERR_BADLAYOUT	12
+	/* FDT_ERR_BADLAYOUT: For read-write functions, the given
+	 * device tree has it's sub-blocks in an order that the
+	 * function can't handle (memory reserve map, then structure,
+	 * then strings).  Use fdt_open_into() to reorganize the tree
+	 * into a form suitable for the read-write operations. */
+
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL	13
+	/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+	 * Should never be returned, if it is, it indicates a bug in
+	 * libfdt itself. */
+
+#define FDT_ERR_MAX		13
+
+/**********************************************************************/
+/* Low-level functions (you probably don't need these)                */
+/**********************************************************************/
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
+{
+	return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
+}
+
+uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+
+/**********************************************************************/
+/* Traversal functions                                                */
+/**********************************************************************/
+
+int fdt_next_node(const void *fdt, int offset, int *depth);
+
+/**********************************************************************/
+/* General functions                                                  */
+/**********************************************************************/
+
+#define fdt_get_header(fdt, field) \
+	(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
+#define fdt_magic(fdt) 			(fdt_get_header(fdt, magic))
+#define fdt_totalsize(fdt)		(fdt_get_header(fdt, totalsize))
+#define fdt_off_dt_struct(fdt)		(fdt_get_header(fdt, off_dt_struct))
+#define fdt_off_dt_strings(fdt)		(fdt_get_header(fdt, off_dt_strings))
+#define fdt_off_mem_rsvmap(fdt)		(fdt_get_header(fdt, off_mem_rsvmap))
+#define fdt_version(fdt)		(fdt_get_header(fdt, version))
+#define fdt_last_comp_version(fdt) 	(fdt_get_header(fdt, last_comp_version))
+#define fdt_boot_cpuid_phys(fdt) 	(fdt_get_header(fdt, boot_cpuid_phys))
+#define fdt_size_dt_strings(fdt) 	(fdt_get_header(fdt, size_dt_strings))
+#define fdt_size_dt_struct(fdt)		(fdt_get_header(fdt, size_dt_struct))
+
+#define __fdt_set_hdr(name) \
+	static inline void fdt_set_##name(void *fdt, uint32_t val) \
+	{ \
+		struct fdt_header *fdth = (struct fdt_header*)fdt; \
+		fdth->name = cpu_to_fdt32(val); \
+	}
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
+
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ *     0, if the buffer appears to contain a valid device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings, as above
+ */
+int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize.  The buffer may overlap
+ * with the existing device tree blob at fdt.  Therefore,
+ *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_move(const void *fdt, void *buf, int bufsize);
+
+/**********************************************************************/
+/* Read-only functions                                                */
+/**********************************************************************/
+
+/**
+ * fdt_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ *     a pointer to the string, on success
+ *     NULL, if stroffset is out of bounds
+ */
+const char *fdt_string(const void *fdt, int stroffset);
+
+/**
+ * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map.  This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ *     the number of entries
+ */
+int fdt_num_mem_rsv(const void *fdt);
+
+/**
+ * fdt_get_mem_rsv - retrieve one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
+/**
+ * fdt_subnode_offset_namelen - find a subnode based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_subnode_offset(), but only examine the first
+ * namelen characters of name for matching the subnode name.  This is
+ * useful for finding subnodes based on a portion of a larger string,
+ * such as a full path.
+ */
+int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+			       const char *name, int namelen);
+/**
+ * fdt_subnode_offset - find a subnode of a given node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_subnode_offset() finds a subnode of the node at structure block
+ * offset parentoffset with the given name.  name may include a unit
+ * address, in which case fdt_subnode_offset() will find the subnode
+ * with that unit address, or the unit address may be omitted, in
+ * which case fdt_subnode_offset() will find an arbitrary subnode
+ * whose name excluding unit address matches the given name.
+ *
+ * returns:
+ *	structure block offset of the requested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_path_offset - find a tree node by its full path
+ * @fdt: pointer to the device tree blob
+ * @path: full path of the node to locate
+ *
+ * fdt_path_offset() finds a node of a given path in the device tree.
+ * Each path component may omit the unit address portion, but the
+ * results of this are undefined if any such path component is
+ * ambiguous (that is if there are multiple nodes at the relevant
+ * level matching the given component, differentiated only by unit
+ * address).
+ *
+ * returns:
+ *	structure block offset of the node with the requested path (>=0), on success
+ *	-FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
+ *	-FDT_ERR_NOTFOUND, if the requested node does not exist
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_path_offset(const void *fdt, const char *path);
+
+/**
+ * fdt_get_name - retrieve the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the starting node
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_name() retrieves the name (including unit address) of the
+ * device tree node at structure block offset nodeoffset.  If lenp is
+ * non-NULL, the length of this name is also returned, in the integer
+ * pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the node's name, on success
+ *		If lenp is non-NULL, *lenp contains the length of that name (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE, standard meanings
+ */
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+
+/**
+ * fdt_first_property_offset - find the offset of a node's first property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ *
+ * fdt_first_property_offset() finds the first property of the node at
+ * the given structure block offset.
+ *
+ * returns:
+ *	structure block offset of the property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested node has no properties
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_first_property_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_next_property_offset - step through a node's properties
+ * @fdt: pointer to the device tree blob
+ * @offset: structure block offset of a property
+ *
+ * fdt_next_property_offset() finds the property immediately after the
+ * one at the given structure block offset.  This will be a property
+ * of the same node as the given property.
+ *
+ * returns:
+ *	structure block offset of the next property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the given property is the last in its node
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_next_property_offset(const void *fdt, int offset);
+
+/**
+ * fdt_get_property_by_offset - retrieve the property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @offset: offset of the property to retrieve
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property_by_offset() retrieves a pointer to the
+ * fdt_property structure within the device tree blob at the given
+ * offset.  If lenp is non-NULL, the length of the property value is
+ * also returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp);
+
+/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int nodeoffset,
+						    const char *name,
+						    int namelen, int *lenp);
+
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset.  If lenp is
+ * non-NULL, the length of the property value is also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
+					    const char *name, int *lenp);
+static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
+						      const char *name,
+						      int *lenp)
+{
+	return (struct fdt_property *)(uintptr_t)
+		fdt_get_property(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_getprop_by_offset - retrieve the value of a property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @ffset: offset of the property to read
+ * @namep: pointer to a string variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop_by_offset() retrieves a pointer to the value of the
+ * property at structure block offset 'offset' (this will be a pointer
+ * to within the device blob itself, not a copy of the value).  If
+ * lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.  If namep is non-NULL,
+ * the property's namne will also be returned in the char * pointed to
+ * by namep (this will be a pointer to within the device tree's string
+ * block, not a new copy of the name).
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *		if namep is non-NULL *namep contiains a pointer to the property
+ *		name.
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp);
+
+/**
+ * fdt_getprop_namelen - get property value based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_getprop(), but only examine the first namelen
+ * characters of name for matching the property name.
+ */
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp);
+
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp);
+static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
+				  const char *name, int *lenp)
+{
+	return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_get_phandle - retrieve the phandle of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the node
+ *
+ * fdt_get_phandle() retrieves the phandle of the device tree node at
+ * structure block offset nodeoffset.
+ *
+ * returns:
+ *	the phandle of the node at nodeoffset, on success (!= 0, != -1)
+ *	0, if the node has no phandle, or another error occurs
+ */
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_get_alias_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias.  That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ *	a pointer to the expansion of the alias named 'name', of it exists
+ *	NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	0, on success
+ *		buf contains the absolute path of the node at
+ *		nodeoffset, as a NUL-terminated string.
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ *		characters and will not fit in the given buffer.
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth).  So
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node.  If the node at
+ * nodeoffset has depth D, then:
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ *	structure block offset of the node at node offset's ancestor
+ *		of depth supernodedepth (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+*	-FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node.  The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	depth of the node at nodeoffset (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ *	structure block offset of the parent of the node at nodeoffset
+ *		(>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_node_offset_by_prop_value - find nodes with a given property value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @propname: property name to check
+ * @propval: property value to search for
+ * @proplen: length of the value in propval
+ *
+ * fdt_node_offset_by_prop_value() returns the offset of the first
+ * node after startoffset, which has a property named propname whose
+ * value is of length proplen and has value equal to propval; or if
+ * startoffset is -1, the very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
+ *					       propval, proplen);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
+ *						       propval, proplen);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen);
+
+/**
+ * fdt_node_offset_by_phandle - find the node with a given phandle
+ * @fdt: pointer to the device tree blob
+ * @phandle: phandle value
+ *
+ * fdt_node_offset_by_phandle() returns the offset of the node
+ * which has the given phandle value.  If there is more than one node
+ * in the tree with the given phandle (an invalid tree), results are
+ * undefined.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0), on success
+ *	-FDT_ERR_NOTFOUND, no node with that phandle exists
+ *	-FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
+
+/**
+ * fdt_node_check_compatible: check a node's compatible property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ *	0, if the node has a 'compatible' property listing the given string
+ *	1, if the node has a 'compatible' property, but it does not list
+ *		the given string
+ *	-FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * 	-FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible);
+
+/**
+ * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @compatible: 'compatible' string to match against
+ *
+ * fdt_node_offset_by_compatible() returns the offset of the first
+ * node after startoffset, which has a 'compatible' property which
+ * lists the given compatible string; or if startoffset is -1, the
+ * very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible);
+
+/**********************************************************************/
+/* Write-in-place functions                                           */
+/**********************************************************************/
+
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+					   const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Sequential write functions                                         */
+/**********************************************************************/
+
+int fdt_create(void *buf, int bufsize);
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
+int fdt_finish_reservemap(void *fdt);
+int fdt_begin_node(void *fdt, const char *name);
+int fdt_property(void *fdt, const char *name, const void *val, int len);
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_property(fdt, name, &val, sizeof(val));
+}
+#define fdt_property_string(fdt, name, str) \
+	fdt_property(fdt, name, str, strlen(str)+1)
+int fdt_end_node(void *fdt);
+int fdt_finish(void *fdt);
+
+/**********************************************************************/
+/* Read-write functions                                               */
+/**********************************************************************/
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize);
+int fdt_pack(void *fdt);
+
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_mem_rsv(void *fdt, int n);
+
+/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string.  NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ *		to contain the new name
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+				   uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_string(fdt, nodeoffset, name, str) \
+	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Debugging / informational functions                                */
+/**********************************************************************/
+
+const char *fdt_strerror(int errval);
+
+#endif /* _LIBFDT_H */
diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
new file mode 100644
index 0000000..449bf60
--- /dev/null
+++ b/xen/common/libfdt/libfdt_env.h
@@ -0,0 +1,23 @@
+#ifndef _LIBFDT_ENV_H
+#define _LIBFDT_ENV_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <string.h>
+
+#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
+static inline uint32_t fdt32_to_cpu(uint32_t x)
+{
+	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
+}
+#define cpu_to_fdt32(x) fdt32_to_cpu(x)
+
+static inline uint64_t fdt64_to_cpu(uint64_t x)
+{
+	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
+		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
+}
+#define cpu_to_fdt64(x) fdt64_to_cpu(x)
+#undef _B
+
+#endif /* _LIBFDT_ENV_H */
diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
new file mode 100644
index 0000000..381133b
--- /dev/null
+++ b/xen/common/libfdt/libfdt_internal.h
@@ -0,0 +1,95 @@
+#ifndef _LIBFDT_INTERNAL_H
+#define _LIBFDT_INTERNAL_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include <fdt.h>
+
+#define FDT_ALIGN(x, a)		(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)		(FDT_ALIGN((x), FDT_TAGSIZE))
+
+#define FDT_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = fdt_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+int _fdt_check_node_offset(const void *fdt, int offset);
+int _fdt_check_prop_offset(const void *fdt, int offset);
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
+int _fdt_node_end_offset(void *fdt, int nodeoffset);
+
+static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
+{
+	return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
+}
+
+static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
+{
+	return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
+}
+
+static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
+{
+	const struct fdt_reserve_entry *rsv_table =
+		(const struct fdt_reserve_entry *)
+		((const char *)fdt + fdt_off_mem_rsvmap(fdt));
+
+	return rsv_table + n;
+}
+static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
+{
+	return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
+}
+
+#define FDT_SW_MAGIC		(~FDT_MAGIC)
+
+#endif /* _LIBFDT_INTERNAL_H */
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
new file mode 100644
index 0000000..3c3994e
--- /dev/null
+++ b/xen/common/libfdt/version.lds
@@ -0,0 +1,54 @@
+LIBFDT_1.2 {
+	global:
+		fdt_next_node;
+		fdt_check_header;
+		fdt_move;
+		fdt_string;
+		fdt_num_mem_rsv;
+		fdt_get_mem_rsv;
+		fdt_subnode_offset_namelen;
+		fdt_subnode_offset;
+		fdt_path_offset;
+		fdt_get_name;
+		fdt_get_property_namelen;
+		fdt_get_property;
+		fdt_getprop_namelen;
+		fdt_getprop;
+		fdt_get_phandle;
+		fdt_get_alias_namelen;
+		fdt_get_alias;
+		fdt_get_path;
+		fdt_supernode_atdepth_offset;
+		fdt_node_depth;
+		fdt_parent_offset;
+		fdt_node_offset_by_prop_value;
+		fdt_node_offset_by_phandle;
+		fdt_node_check_compatible;
+		fdt_node_offset_by_compatible;
+		fdt_setprop_inplace;
+		fdt_nop_property;
+		fdt_nop_node;
+		fdt_create;
+		fdt_add_reservemap_entry;
+		fdt_finish_reservemap;
+		fdt_begin_node;
+		fdt_property;
+		fdt_end_node;
+		fdt_finish;
+		fdt_open_into;
+		fdt_pack;
+		fdt_add_mem_rsv;
+		fdt_del_mem_rsv;
+		fdt_set_name;
+		fdt_setprop;
+		fdt_delprop;
+		fdt_add_subnode_namelen;
+		fdt_add_subnode;
+		fdt_del_node;
+		fdt_strerror;
+		fdt_offset_ptr;
+		fdt_next_tag;
+
+	local:
+		*;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObj-0000c9-P3; Fri, 03 Feb 2012 19:15:39 +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 1RtObi-0000c0-9P
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4913 invoked from network); 3 Feb 2012 19:14:48 -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;
	3 Feb 2012 19:14:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612430"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:36 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVps011693;
	Fri, 3 Feb 2012 11:15:35 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:12 +0000
Message-ID: <1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial page
	tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add a 1:1 mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/head.S |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9951f37..8385481 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -202,6 +202,11 @@ hyp:
 	add   r4, r4, #8
 	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #endif
+	mov   r3, #0x0
+	orr   r2, r8, #0xe00
+	orr   r2, r2, #0x07d
+	mov   r4, r8, lsr #18        /* Slot for (r8 == atag_paddr) */
+	strd  r2, r3, [r1, r4]       /* Map DTB there */
 
 	PRINT("- Turning on paging -\r\n")
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObr-0000eW-UF; Fri, 03 Feb 2012 19:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObo-0000c7-VZ
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328296535!6302620!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14966 invoked from network); 3 Feb 2012 19:15:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 19:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:33 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpp011693;
	Fri, 3 Feb 2012 11:15:32 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:09 +0000
Message-ID: <1328296515-25876-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/7] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git

This will be used by Xen to parse the DTBs provided by bootloaders on
ARM platforms.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/Makefile.libfdt   |   10 +
 xen/common/libfdt/TODO              |    3 +
 xen/common/libfdt/fdt.c             |  222 +++++++
 xen/common/libfdt/fdt.h             |   60 ++
 xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
 xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
 xen/common/libfdt/fdt_strerror.c    |   96 +++
 xen/common/libfdt/fdt_sw.c          |  256 ++++++++
 xen/common/libfdt/fdt_wip.c         |  118 ++++
 xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
 xen/common/libfdt/libfdt_env.h      |   23 +
 xen/common/libfdt/libfdt_internal.h |   95 +++
 xen/common/libfdt/version.lds       |   54 ++
 13 files changed, 3211 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile.libfdt
 create mode 100644 xen/common/libfdt/TODO
 create mode 100644 xen/common/libfdt/fdt.c
 create mode 100644 xen/common/libfdt/fdt.h
 create mode 100644 xen/common/libfdt/fdt_ro.c
 create mode 100644 xen/common/libfdt/fdt_rw.c
 create mode 100644 xen/common/libfdt/fdt_strerror.c
 create mode 100644 xen/common/libfdt/fdt_sw.c
 create mode 100644 xen/common/libfdt/fdt_wip.c
 create mode 100644 xen/common/libfdt/libfdt.h
 create mode 100644 xen/common/libfdt/libfdt_env.h
 create mode 100644 xen/common/libfdt/libfdt_internal.h
 create mode 100644 xen/common/libfdt/version.lds

diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
new file mode 100644
index 0000000..d55a6f8
--- /dev/null
+++ b/xen/common/libfdt/Makefile.libfdt
@@ -0,0 +1,10 @@
+# Makefile.libfdt
+#
+# This is not a complete Makefile of itself.  Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_VERSION = version.lds
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
new file mode 100644
index 0000000..288437e
--- /dev/null
+++ b/xen/common/libfdt/TODO
@@ -0,0 +1,3 @@
+- Tree traversal functions
+- Graft function
+- Complete libfdt.h documenting comments
diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
new file mode 100644
index 0000000..e56833a
--- /dev/null
+++ b/xen/common/libfdt/fdt.c
@@ -0,0 +1,222 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_check_header(const void *fdt)
+{
+	if (fdt_magic(fdt) == FDT_MAGIC) {
+		/* Complete tree */
+		if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+		if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+	} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+		/* Unfinished sequential-write blob */
+		if (fdt_size_dt_struct(fdt) == 0)
+			return -FDT_ERR_BADSTATE;
+	} else {
+		return -FDT_ERR_BADMAGIC;
+	}
+
+	return 0;
+}
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
+{
+	const char *p;
+
+	if (fdt_version(fdt) >= 0x11)
+		if (((offset + len) < offset)
+		    || ((offset + len) > fdt_size_dt_struct(fdt)))
+			return NULL;
+
+	p = _fdt_offset_ptr(fdt, offset);
+
+	if (p + len < p)
+		return NULL;
+	return p;
+}
+
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+	const uint32_t *tagp, *lenp;
+	uint32_t tag;
+	int offset = startoffset;
+	const char *p;
+
+	*nextoffset = -FDT_ERR_TRUNCATED;
+	tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
+	if (!tagp)
+		return FDT_END; /* premature end */
+	tag = fdt32_to_cpu(*tagp);
+	offset += FDT_TAGSIZE;
+
+	*nextoffset = -FDT_ERR_BADSTRUCTURE;
+	switch (tag) {
+	case FDT_BEGIN_NODE:
+		/* skip name */
+		do {
+			p = fdt_offset_ptr(fdt, offset++, 1);
+		} while (p && (*p != '\0'));
+		if (!p)
+			return FDT_END; /* premature end */
+		break;
+
+	case FDT_PROP:
+		lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
+		if (!lenp)
+			return FDT_END; /* premature end */
+		/* skip-name offset, length and value */
+		offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+			+ fdt32_to_cpu(*lenp);
+		break;
+
+	case FDT_END:
+	case FDT_END_NODE:
+	case FDT_NOP:
+		break;
+
+	default:
+		return FDT_END;
+	}
+
+	if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
+		return FDT_END; /* premature end */
+
+	*nextoffset = FDT_TAGALIGN(offset);
+	return tag;
+}
+
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int _fdt_check_prop_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int fdt_next_node(const void *fdt, int offset, int *depth)
+{
+	int nextoffset = 0;
+	uint32_t tag;
+
+	if (offset >= 0)
+		if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+			return nextoffset;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_PROP:
+		case FDT_NOP:
+			break;
+
+		case FDT_BEGIN_NODE:
+			if (depth)
+				(*depth)++;
+			break;
+
+		case FDT_END_NODE:
+			if (depth && ((--(*depth)) < 0))
+				return nextoffset;
+			break;
+
+		case FDT_END:
+			if ((nextoffset >= 0)
+			    || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
+				return -FDT_ERR_NOTFOUND;
+			else
+				return nextoffset;
+		}
+	} while (tag != FDT_BEGIN_NODE);
+
+	return offset;
+}
+
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+{
+	int len = strlen(s) + 1;
+	const char *last = strtab + tabsize - len;
+	const char *p;
+
+	for (p = strtab; p <= last; p++)
+		if (memcmp(p, s, len) == 0)
+			return p;
+	return NULL;
+}
+
+int fdt_move(const void *fdt, void *buf, int bufsize)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_totalsize(fdt) > bufsize)
+		return -FDT_ERR_NOSPACE;
+
+	memmove(buf, fdt, fdt_totalsize(fdt));
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
new file mode 100644
index 0000000..48ccfd9
--- /dev/null
+++ b/xen/common/libfdt/fdt.h
@@ -0,0 +1,60 @@
+#ifndef _FDT_H
+#define _FDT_H
+
+#ifndef __ASSEMBLY__
+
+struct fdt_header {
+	uint32_t magic;			 /* magic word FDT_MAGIC */
+	uint32_t totalsize;		 /* total size of DT block */
+	uint32_t off_dt_struct;		 /* offset to structure */
+	uint32_t off_dt_strings;	 /* offset to strings */
+	uint32_t off_mem_rsvmap;	 /* offset to memory reserve map */
+	uint32_t version;		 /* format version */
+	uint32_t last_comp_version;	 /* last compatible version */
+
+	/* version 2 fields below */
+	uint32_t boot_cpuid_phys;	 /* Which physical CPU id we're
+					    booting on */
+	/* version 3 fields below */
+	uint32_t size_dt_strings;	 /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;	 /* size of the structure block */
+};
+
+struct fdt_reserve_entry {
+	uint64_t address;
+	uint64_t size;
+};
+
+struct fdt_node_header {
+	uint32_t tag;
+	char name[0];
+};
+
+struct fdt_property {
+	uint32_t tag;
+	uint32_t len;
+	uint32_t nameoff;
+	char data[0];
+};
+
+#endif /* !__ASSEMBLY */
+
+#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_TAGSIZE	sizeof(uint32_t)
+
+#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
+#define FDT_END_NODE	0x2		/* End node */
+#define FDT_PROP	0x3		/* Property: name off,
+					   size, content */
+#define FDT_NOP		0x4		/* nop */
+#define FDT_END		0x9
+
+#define FDT_V1_SIZE	(7*sizeof(uint32_t))
+#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(uint32_t))
+#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V16_SIZE	FDT_V3_SIZE
+#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(uint32_t))
+
+#endif /* _FDT_H */
diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
new file mode 100644
index 0000000..02b6d68
--- /dev/null
+++ b/xen/common/libfdt/fdt_ro.c
@@ -0,0 +1,574 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_nodename_eq(const void *fdt, int offset,
+			    const char *s, int len)
+{
+	const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+
+	if (! p)
+		/* short match */
+		return 0;
+
+	if (memcmp(p, s, len) != 0)
+		return 0;
+
+	if (p[len] == '\0')
+		return 1;
+	else if (!memchr(s, '@', len) && (p[len] == '@'))
+		return 1;
+	else
+		return 0;
+}
+
+const char *fdt_string(const void *fdt, int stroffset)
+{
+	return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+}
+
+static int _fdt_string_eq(const void *fdt, int stroffset,
+			  const char *s, int len)
+{
+	const char *p = fdt_string(fdt, stroffset);
+
+	return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+}
+
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
+{
+	FDT_CHECK_HEADER(fdt);
+	*address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
+	*size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+	return 0;
+}
+
+int fdt_num_mem_rsv(const void *fdt)
+{
+	int i = 0;
+
+	while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+		i++;
+	return i;
+}
+
+static int _nextprop(const void *fdt, int offset)
+{
+	uint32_t tag;
+	int nextoffset;
+
+	do {
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_END:
+			if (nextoffset >= 0)
+				return -FDT_ERR_BADSTRUCTURE;
+			else
+				return nextoffset;
+
+		case FDT_PROP:
+			return offset;
+		}
+		offset = nextoffset;
+	} while (tag == FDT_NOP);
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
+			       const char *name, int namelen)
+{
+	int depth;
+
+	FDT_CHECK_HEADER(fdt);
+
+	for (depth = 0;
+	     (offset >= 0) && (depth >= 0);
+	     offset = fdt_next_node(fdt, offset, &depth))
+		if ((depth == 1)
+		    && _fdt_nodename_eq(fdt, offset, name, namelen))
+			return offset;
+
+	if (depth < 0)
+		return -FDT_ERR_NOTFOUND;
+	return offset; /* error */
+}
+
+int fdt_subnode_offset(const void *fdt, int parentoffset,
+		       const char *name)
+{
+	return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_path_offset(const void *fdt, const char *path)
+{
+	const char *end = path + strlen(path);
+	const char *p = path;
+	int offset = 0;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* see if we have an alias */
+	if (*path != '/') {
+		const char *q = strchr(path, '/');
+
+		if (!q)
+			q = end;
+
+		p = fdt_get_alias_namelen(fdt, p, q - p);
+		if (!p)
+			return -FDT_ERR_BADPATH;
+		offset = fdt_path_offset(fdt, p);
+
+		p = q;
+	}
+
+	while (*p) {
+		const char *q;
+
+		while (*p == '/')
+			p++;
+		if (! *p)
+			return offset;
+		q = strchr(p, '/');
+		if (! q)
+			q = end;
+
+		offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
+		if (offset < 0)
+			return offset;
+
+		p = q;
+	}
+
+	return offset;
+}
+
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+	const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
+	int err;
+
+	if (((err = fdt_check_header(fdt)) != 0)
+	    || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+			goto fail;
+
+	if (len)
+		*len = strlen(nh->name);
+
+	return nh->name;
+
+ fail:
+	if (len)
+		*len = err;
+	return NULL;
+}
+
+int fdt_first_property_offset(const void *fdt, int nodeoffset)
+{
+	int offset;
+
+	if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+int fdt_next_property_offset(const void *fdt, int offset)
+{
+	if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp)
+{
+	int err;
+	const struct fdt_property *prop;
+
+	if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
+		if (lenp)
+			*lenp = err;
+		return NULL;
+	}
+
+	prop = _fdt_offset_ptr(fdt, offset);
+
+	if (lenp)
+		*lenp = fdt32_to_cpu(prop->len);
+
+	return prop;
+}
+
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int offset,
+						    const char *name,
+						    int namelen, int *lenp)
+{
+	for (offset = fdt_first_property_offset(fdt, offset);
+	     (offset >= 0);
+	     (offset = fdt_next_property_offset(fdt, offset))) {
+		const struct fdt_property *prop;
+
+		if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
+			offset = -FDT_ERR_INTERNAL;
+			break;
+		}
+		if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
+				   name, namelen))
+			return prop;
+	}
+
+	if (lenp)
+		*lenp = offset;
+	return NULL;
+}
+
+const struct fdt_property *fdt_get_property(const void *fdt,
+					    int nodeoffset,
+					    const char *name, int *lenp)
+{
+	return fdt_get_property_namelen(fdt, nodeoffset, name,
+					strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
+	if (! prop)
+		return NULL;
+
+	return prop->data;
+}
+
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_by_offset(fdt, offset, lenp);
+	if (!prop)
+		return NULL;
+	if (namep)
+		*namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+	return prop->data;
+}
+
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp)
+{
+	return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
+{
+	const uint32_t *php;
+	int len;
+
+	/* FIXME: This is a bit sub-optimal, since we potentially scan
+	 * over all the properties twice. */
+	php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
+	if (!php || (len != sizeof(*php))) {
+		php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
+		if (!php || (len != sizeof(*php)))
+			return 0;
+	}
+
+	return fdt32_to_cpu(*php);
+}
+
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen)
+{
+	int aliasoffset;
+
+	aliasoffset = fdt_path_offset(fdt, "/aliases");
+	if (aliasoffset < 0)
+		return NULL;
+
+	return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+	return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+	int pdepth = 0, p = 0;
+	int offset, depth, namelen;
+	const char *name;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (buflen < 2)
+		return -FDT_ERR_NOSPACE;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		while (pdepth > depth) {
+			do {
+				p--;
+			} while (buf[p-1] != '/');
+			pdepth--;
+		}
+
+		if (pdepth >= depth) {
+			name = fdt_get_name(fdt, offset, &namelen);
+			if (!name)
+				return namelen;
+			if ((p + namelen + 1) <= buflen) {
+				memcpy(buf + p, name, namelen);
+				p += namelen;
+				buf[p++] = '/';
+				pdepth++;
+			}
+		}
+
+		if (offset == nodeoffset) {
+			if (pdepth < (depth + 1))
+				return -FDT_ERR_NOSPACE;
+
+			if (p > 1) /* special case so that root path is "/", not "" */
+				p--;
+			buf[p] = '\0';
+			return 0;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth)
+{
+	int offset, depth;
+	int supernodeoffset = -FDT_ERR_INTERNAL;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (supernodedepth < 0)
+		return -FDT_ERR_NOTFOUND;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		if (depth == supernodedepth)
+			supernodeoffset = offset;
+
+		if (offset == nodeoffset) {
+			if (nodedepth)
+				*nodedepth = depth;
+
+			if (supernodedepth > depth)
+				return -FDT_ERR_NOTFOUND;
+			else
+				return supernodeoffset;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+	int nodedepth;
+	int err;
+
+	err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+	if (err)
+		return (err < 0) ? err : -FDT_ERR_INTERNAL;
+	return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+	int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+	if (nodedepth < 0)
+		return nodedepth;
+	return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+					    nodedepth - 1, NULL);
+}
+
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen)
+{
+	int offset;
+	const void *val;
+	int len;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_getprop(), then if that didn't
+	 * find what we want, we scan over them again making our way
+	 * to the next node.  Still it's the easiest to implement
+	 * approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		val = fdt_getprop(fdt, offset, propname, &len);
+		if (val && (len == proplen)
+		    && (memcmp(val, propval, len) == 0))
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
+{
+	int offset;
+
+	if ((phandle == 0) || (phandle == -1))
+		return -FDT_ERR_BADPHANDLE;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we
+	 * potentially scan each property of a node in
+	 * fdt_get_phandle(), then if that didn't find what
+	 * we want, we scan over them again making our way to the next
+	 * node.  Still it's the easiest to implement approach;
+	 * performance can come later. */
+	for (offset = fdt_next_node(fdt, -1, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		if (fdt_get_phandle(fdt, offset) == phandle)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+				    const char *str)
+{
+	int len = strlen(str);
+	const char *p;
+
+	while (listlen >= len) {
+		if (memcmp(str, strlist, len+1) == 0)
+			return 1;
+		p = memchr(strlist, '\0', listlen);
+		if (!p)
+			return 0; /* malformed strlist.. */
+		listlen -= (p-strlist) + 1;
+		strlist = p + 1;
+	}
+	return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible)
+{
+	const void *prop;
+	int len;
+
+	prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+	if (!prop)
+		return len;
+	if (_fdt_stringlist_contains(prop, len, compatible))
+		return 0;
+	else
+		return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible)
+{
+	int offset, err;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_node_check_compatible(), then if
+	 * that didn't find what we want, we scan over them again
+	 * making our way to the next node.  Still it's the easiest to
+	 * implement approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		err = fdt_node_check_compatible(fdt, offset, compatible);
+		if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
+			return err;
+		else if (err == 0)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
new file mode 100644
index 0000000..994037b
--- /dev/null
+++ b/xen/common/libfdt/fdt_rw.c
@@ -0,0 +1,465 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_blocks_misordered(const void *fdt,
+			      int mem_rsv_size, int struct_size)
+{
+	return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
+		|| (fdt_off_dt_struct(fdt) <
+		    (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
+		|| (fdt_off_dt_strings(fdt) <
+		    (fdt_off_dt_struct(fdt) + struct_size))
+		|| (fdt_totalsize(fdt) <
+		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
+}
+
+static int _fdt_rw_check_header(void *fdt)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_version(fdt) < 17)
+		return -FDT_ERR_BADVERSION;
+	if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
+				   fdt_size_dt_struct(fdt)))
+		return -FDT_ERR_BADLAYOUT;
+	if (fdt_version(fdt) > 17)
+		fdt_set_version(fdt, 17);
+
+	return 0;
+}
+
+#define FDT_RW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_rw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static inline int _fdt_data_size(void *fdt)
+{
+	return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+}
+
+static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
+{
+	char *p = splicepoint;
+	char *end = (char *)fdt + _fdt_data_size(fdt);
+
+	if (((p + oldlen) < p) || ((p + oldlen) > end))
+		return -FDT_ERR_BADOFFSET;
+	if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
+		return -FDT_ERR_NOSPACE;
+	memmove(p + newlen, p + oldlen, end - p - oldlen);
+	return 0;
+}
+
+static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
+			       int oldn, int newn)
+{
+	int delta = (newn - oldn) * sizeof(*p);
+	int err;
+	err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
+	if (err)
+		return err;
+	fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_struct(void *fdt, void *p,
+			      int oldlen, int newlen)
+{
+	int delta = newlen - oldlen;
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
+		return err;
+
+	fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_string(void *fdt, int newlen)
+{
+	void *p = (char *)fdt
+		+ fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, 0, newlen)))
+		return err;
+
+	fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
+	const char *p;
+	char *new;
+	int len = strlen(s) + 1;
+	int err;
+
+	p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
+	if (p)
+		/* found it */
+		return (p - strtab);
+
+	new = strtab + fdt_size_dt_strings(fdt);
+	err = _fdt_splice_string(fdt, len);
+	if (err)
+		return err;
+
+	memcpy(new, s, len);
+	return (new - strtab);
+}
+
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
+	err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
+	if (err)
+		return err;
+
+	re->address = cpu_to_fdt64(address);
+	re->size = cpu_to_fdt64(size);
+	return 0;
+}
+
+int fdt_del_mem_rsv(void *fdt, int n)
+{
+	struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	if (n >= fdt_num_mem_rsv(fdt))
+		return -FDT_ERR_NOTFOUND;
+
+	err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
+	if (err)
+		return err;
+	return 0;
+}
+
+static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
+				int len, struct fdt_property **prop)
+{
+	int oldlen;
+	int err;
+
+	*prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
+	if (! (*prop))
+		return oldlen;
+
+	if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
+				      FDT_TAGALIGN(len))))
+		return err;
+
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
+			     int len, struct fdt_property **prop)
+{
+	int proplen;
+	int nextoffset;
+	int namestroff;
+	int err;
+
+	if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return nextoffset;
+
+	namestroff = _fdt_find_add_string(fdt, name);
+	if (namestroff < 0)
+		return namestroff;
+
+	*prop = _fdt_offset_ptr_w(fdt, nextoffset);
+	proplen = sizeof(**prop) + FDT_TAGALIGN(len);
+
+	err = _fdt_splice_struct(fdt, *prop, 0, proplen);
+	if (err)
+		return err;
+
+	(*prop)->tag = cpu_to_fdt32(FDT_PROP);
+	(*prop)->nameoff = cpu_to_fdt32(namestroff);
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+	char *namep;
+	int oldlen, newlen;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
+	if (!namep)
+		return oldlen;
+
+	newlen = strlen(name);
+
+	err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
+				 FDT_TAGALIGN(newlen+1));
+	if (err)
+		return err;
+
+	memcpy(namep, name, newlen+1);
+	return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len)
+{
+	struct fdt_property *prop;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
+	if (err == -FDT_ERR_NOTFOUND)
+		err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
+	if (err)
+		return err;
+
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_delprop(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len, proplen;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	proplen = sizeof(*prop) + FDT_TAGALIGN(len);
+	return _fdt_splice_struct(fdt, prop, proplen, 0);
+}
+
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen)
+{
+	struct fdt_node_header *nh;
+	int offset, nextoffset;
+	int nodelen;
+	int err;
+	uint32_t tag;
+	uint32_t *endtag;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
+	if (offset >= 0)
+		return -FDT_ERR_EXISTS;
+	else if (offset != -FDT_ERR_NOTFOUND)
+		return offset;
+
+	/* Try to place the new node after the parent's properties */
+	fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+	} while ((tag == FDT_PROP) || (tag == FDT_NOP));
+
+	nh = _fdt_offset_ptr_w(fdt, offset);
+	nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
+
+	err = _fdt_splice_struct(fdt, nh, 0, nodelen);
+	if (err)
+		return err;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
+	memcpy(nh->name, name, namelen);
+	endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
+	*endtag = cpu_to_fdt32(FDT_END_NODE);
+
+	return offset;
+}
+
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
+{
+	return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_del_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
+				  endoffset - nodeoffset, 0);
+}
+
+static void _fdt_packblocks(const char *old, char *new,
+			    int mem_rsv_size, int struct_size)
+{
+	int mem_rsv_off, struct_off, strings_off;
+
+	mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
+	struct_off = mem_rsv_off + mem_rsv_size;
+	strings_off = struct_off + struct_size;
+
+	memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
+	fdt_set_off_mem_rsvmap(new, mem_rsv_off);
+
+	memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
+	fdt_set_off_dt_struct(new, struct_off);
+	fdt_set_size_dt_struct(new, struct_size);
+
+	memmove(new + strings_off, old + fdt_off_dt_strings(old),
+		fdt_size_dt_strings(old));
+	fdt_set_off_dt_strings(new, strings_off);
+	fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
+}
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize)
+{
+	int err;
+	int mem_rsv_size, struct_size;
+	int newsize;
+	const char *fdtstart = fdt;
+	const char *fdtend = fdtstart + fdt_totalsize(fdt);
+	char *tmp;
+
+	FDT_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+
+	if (fdt_version(fdt) >= 17) {
+		struct_size = fdt_size_dt_struct(fdt);
+	} else {
+		struct_size = 0;
+		while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
+			;
+		if (struct_size < 0)
+			return struct_size;
+	}
+
+	if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
+		/* no further work necessary */
+		err = fdt_move(fdt, buf, bufsize);
+		if (err)
+			return err;
+		fdt_set_version(buf, 17);
+		fdt_set_size_dt_struct(buf, struct_size);
+		fdt_set_totalsize(buf, bufsize);
+		return 0;
+	}
+
+	/* Need to reorder */
+	newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
+		+ struct_size + fdt_size_dt_strings(fdt);
+
+	if (bufsize < newsize)
+		return -FDT_ERR_NOSPACE;
+
+	/* First attempt to build converted tree at beginning of buffer */
+	tmp = buf;
+	/* But if that overlaps with the old tree... */
+	if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
+		/* Try right after the old tree instead */
+		tmp = (char *)(uintptr_t)fdtend;
+		if ((tmp + newsize) > ((char *)buf + bufsize))
+			return -FDT_ERR_NOSPACE;
+	}
+
+	_fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
+	memmove(buf, tmp, newsize);
+
+	fdt_set_magic(buf, FDT_MAGIC);
+	fdt_set_totalsize(buf, bufsize);
+	fdt_set_version(buf, 17);
+	fdt_set_last_comp_version(buf, 16);
+	fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
+
+	return 0;
+}
+
+int fdt_pack(void *fdt)
+{
+	int mem_rsv_size;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+	_fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
+	fdt_set_totalsize(fdt, _fdt_data_size(fdt));
+
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
new file mode 100644
index 0000000..e6c3cee
--- /dev/null
+++ b/xen/common/libfdt/fdt_strerror.c
@@ -0,0 +1,96 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+struct fdt_errtabent {
+	const char *str;
+};
+
+#define FDT_ERRTABENT(val) \
+	[(val)] = { .str = #val, }
+
+static struct fdt_errtabent fdt_errtable[] = {
+	FDT_ERRTABENT(FDT_ERR_NOTFOUND),
+	FDT_ERRTABENT(FDT_ERR_EXISTS),
+	FDT_ERRTABENT(FDT_ERR_NOSPACE),
+
+	FDT_ERRTABENT(FDT_ERR_BADOFFSET),
+	FDT_ERRTABENT(FDT_ERR_BADPATH),
+	FDT_ERRTABENT(FDT_ERR_BADSTATE),
+
+	FDT_ERRTABENT(FDT_ERR_TRUNCATED),
+	FDT_ERRTABENT(FDT_ERR_BADMAGIC),
+	FDT_ERRTABENT(FDT_ERR_BADVERSION),
+	FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
+	FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+};
+#define FDT_ERRTABSIZE	(sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
+
+const char *fdt_strerror(int errval)
+{
+	if (errval > 0)
+		return "<valid offset/length>";
+	else if (errval == 0)
+		return "<no error>";
+	else if (errval > -FDT_ERRTABSIZE) {
+		const char *s = fdt_errtable[-errval].str;
+
+		if (s)
+			return s;
+	}
+
+	return "<unknown error>";
+}
diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
new file mode 100644
index 0000000..55ebebf
--- /dev/null
+++ b/xen/common/libfdt/fdt_sw.c
@@ -0,0 +1,256 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_sw_check_header(void *fdt)
+{
+	if (fdt_magic(fdt) != FDT_SW_MAGIC)
+		return -FDT_ERR_BADMAGIC;
+	/* FIXME: should check more details about the header state */
+	return 0;
+}
+
+#define FDT_SW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_sw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static void *_fdt_grab_space(void *fdt, size_t len)
+{
+	int offset = fdt_size_dt_struct(fdt);
+	int spaceleft;
+
+	spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
+		- fdt_size_dt_strings(fdt);
+
+	if ((offset + len < offset) || (offset + len > spaceleft))
+		return NULL;
+
+	fdt_set_size_dt_struct(fdt, offset + len);
+	return _fdt_offset_ptr_w(fdt, offset);
+}
+
+int fdt_create(void *buf, int bufsize)
+{
+	void *fdt = buf;
+
+	if (bufsize < sizeof(struct fdt_header))
+		return -FDT_ERR_NOSPACE;
+
+	memset(buf, 0, bufsize);
+
+	fdt_set_magic(fdt, FDT_SW_MAGIC);
+	fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+	fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+	fdt_set_totalsize(fdt,  bufsize);
+
+	fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
+					      sizeof(struct fdt_reserve_entry)));
+	fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
+	fdt_set_off_dt_strings(fdt, bufsize);
+
+	return 0;
+}
+
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int offset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	if (fdt_size_dt_struct(fdt))
+		return -FDT_ERR_BADSTATE;
+
+	offset = fdt_off_dt_struct(fdt);
+	if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
+		return -FDT_ERR_NOSPACE;
+
+	re = (struct fdt_reserve_entry *)((char *)fdt + offset);
+	re->address = cpu_to_fdt64(addr);
+	re->size = cpu_to_fdt64(size);
+
+	fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
+
+	return 0;
+}
+
+int fdt_finish_reservemap(void *fdt)
+{
+	return fdt_add_reservemap_entry(fdt, 0, 0);
+}
+
+int fdt_begin_node(void *fdt, const char *name)
+{
+	struct fdt_node_header *nh;
+	int namelen = strlen(name) + 1;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
+	if (! nh)
+		return -FDT_ERR_NOSPACE;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memcpy(nh->name, name, namelen);
+	return 0;
+}
+
+int fdt_end_node(void *fdt)
+{
+	uint32_t *en;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	en = _fdt_grab_space(fdt, FDT_TAGSIZE);
+	if (! en)
+		return -FDT_ERR_NOSPACE;
+
+	*en = cpu_to_fdt32(FDT_END_NODE);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_totalsize(fdt);
+	const char *p;
+	int strtabsize = fdt_size_dt_strings(fdt);
+	int len = strlen(s) + 1;
+	int struct_top, offset;
+
+	p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
+	if (p)
+		return p - strtab;
+
+	/* Add it */
+	offset = -strtabsize - len;
+	struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	if (fdt_totalsize(fdt) + offset < struct_top)
+		return 0; /* no more room :( */
+
+	memcpy(strtab + offset, s, len);
+	fdt_set_size_dt_strings(fdt, strtabsize + len);
+	return offset;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+	struct fdt_property *prop;
+	int nameoff;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nameoff = _fdt_find_add_string(fdt, name);
+	if (nameoff == 0)
+		return -FDT_ERR_NOSPACE;
+
+	prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
+	if (! prop)
+		return -FDT_ERR_NOSPACE;
+
+	prop->tag = cpu_to_fdt32(FDT_PROP);
+	prop->nameoff = cpu_to_fdt32(nameoff);
+	prop->len = cpu_to_fdt32(len);
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_finish(void *fdt)
+{
+	char *p = (char *)fdt;
+	uint32_t *end;
+	int oldstroffset, newstroffset;
+	uint32_t tag;
+	int offset, nextoffset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	/* Add terminator */
+	end = _fdt_grab_space(fdt, sizeof(*end));
+	if (! end)
+		return -FDT_ERR_NOSPACE;
+	*end = cpu_to_fdt32(FDT_END);
+
+	/* Relocate the string table */
+	oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
+	newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
+	fdt_set_off_dt_strings(fdt, newstroffset);
+
+	/* Walk the structure, correcting string offsets */
+	offset = 0;
+	while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
+		if (tag == FDT_PROP) {
+			struct fdt_property *prop =
+				_fdt_offset_ptr_w(fdt, offset);
+			int nameoff;
+
+			nameoff = fdt32_to_cpu(prop->nameoff);
+			nameoff += fdt_size_dt_strings(fdt);
+			prop->nameoff = cpu_to_fdt32(nameoff);
+		}
+		offset = nextoffset;
+	}
+	if (nextoffset < 0)
+		return nextoffset;
+
+	/* Finally, adjust the header */
+	fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
+	fdt_set_magic(fdt, FDT_MAGIC);
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
new file mode 100644
index 0000000..6025fa1
--- /dev/null
+++ b/xen/common/libfdt/fdt_wip.c
@@ -0,0 +1,118 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len)
+{
+	void *propval;
+	int proplen;
+
+	propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
+	if (! propval)
+		return proplen;
+
+	if (proplen != len)
+		return -FDT_ERR_NOSPACE;
+
+	memcpy(propval, val, len);
+	return 0;
+}
+
+static void _fdt_nop_region(void *start, int len)
+{
+	uint32_t *p;
+
+	for (p = start; (char *)p < ((char *)start + len); p++)
+		*p = cpu_to_fdt32(FDT_NOP);
+}
+
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len;
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	_fdt_nop_region(prop, len + sizeof(*prop));
+
+	return 0;
+}
+
+int _fdt_node_end_offset(void *fdt, int offset)
+{
+	int depth = 0;
+
+	while ((offset >= 0) && (depth >= 0))
+		offset = fdt_next_node(fdt, offset, &depth);
+
+	return offset;
+}
+
+int fdt_nop_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	_fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
+			endoffset - nodeoffset);
+	return 0;
+}
diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
new file mode 100644
index 0000000..55f3eb3
--- /dev/null
+++ b/xen/common/libfdt/libfdt.h
@@ -0,0 +1,1235 @@
+#ifndef _LIBFDT_H
+#define _LIBFDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <libfdt_env.h>
+#include <fdt.h>
+
+#define FDT_FIRST_SUPPORTED_VERSION	0x10
+#define FDT_LAST_SUPPORTED_VERSION	0x11
+
+/* Error codes: informative error codes */
+#define FDT_ERR_NOTFOUND	1
+	/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
+#define FDT_ERR_EXISTS		2
+	/* FDT_ERR_EXISTS: Attemped to create a node or property which
+	 * already exists */
+#define FDT_ERR_NOSPACE		3
+	/* FDT_ERR_NOSPACE: Operation needed to expand the device
+	 * tree, but its buffer did not have sufficient space to
+	 * contain the expanded tree. Use fdt_open_into() to move the
+	 * device tree to a buffer with more space. */
+
+/* Error codes: codes for bad parameters */
+#define FDT_ERR_BADOFFSET	4
+	/* FDT_ERR_BADOFFSET: Function was passed a structure block
+	 * offset which is out-of-bounds, or which points to an
+	 * unsuitable part of the structure for the operation. */
+#define FDT_ERR_BADPATH		5
+	/* FDT_ERR_BADPATH: Function was passed a badly formatted path
+	 * (e.g. missing a leading / for a function which requires an
+	 * absolute path) */
+#define FDT_ERR_BADPHANDLE	6
+	/* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
+	 * value.  phandle values of 0 and -1 are not permitted. */
+#define FDT_ERR_BADSTATE	7
+	/* FDT_ERR_BADSTATE: Function was passed an incomplete device
+	 * tree created by the sequential-write functions, which is
+	 * not sufficiently complete for the requested operation. */
+
+/* Error codes: codes for bad device tree blobs */
+#define FDT_ERR_TRUNCATED	8
+	/* FDT_ERR_TRUNCATED: Structure block of the given device tree
+	 * ends without an FDT_END tag. */
+#define FDT_ERR_BADMAGIC	9
+	/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+	 * device tree at all - it is missing the flattened device
+	 * tree magic number. */
+#define FDT_ERR_BADVERSION	10
+	/* FDT_ERR_BADVERSION: Given device tree has a version which
+	 * can't be handled by the requested operation.  For
+	 * read-write functions, this may mean that fdt_open_into() is
+	 * required to convert the tree to the expected version. */
+#define FDT_ERR_BADSTRUCTURE	11
+	/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+	 * structure block or other serious error (e.g. misnested
+	 * nodes, or subnodes preceding properties). */
+#define FDT_ERR_BADLAYOUT	12
+	/* FDT_ERR_BADLAYOUT: For read-write functions, the given
+	 * device tree has it's sub-blocks in an order that the
+	 * function can't handle (memory reserve map, then structure,
+	 * then strings).  Use fdt_open_into() to reorganize the tree
+	 * into a form suitable for the read-write operations. */
+
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL	13
+	/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+	 * Should never be returned, if it is, it indicates a bug in
+	 * libfdt itself. */
+
+#define FDT_ERR_MAX		13
+
+/**********************************************************************/
+/* Low-level functions (you probably don't need these)                */
+/**********************************************************************/
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
+{
+	return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
+}
+
+uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+
+/**********************************************************************/
+/* Traversal functions                                                */
+/**********************************************************************/
+
+int fdt_next_node(const void *fdt, int offset, int *depth);
+
+/**********************************************************************/
+/* General functions                                                  */
+/**********************************************************************/
+
+#define fdt_get_header(fdt, field) \
+	(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
+#define fdt_magic(fdt) 			(fdt_get_header(fdt, magic))
+#define fdt_totalsize(fdt)		(fdt_get_header(fdt, totalsize))
+#define fdt_off_dt_struct(fdt)		(fdt_get_header(fdt, off_dt_struct))
+#define fdt_off_dt_strings(fdt)		(fdt_get_header(fdt, off_dt_strings))
+#define fdt_off_mem_rsvmap(fdt)		(fdt_get_header(fdt, off_mem_rsvmap))
+#define fdt_version(fdt)		(fdt_get_header(fdt, version))
+#define fdt_last_comp_version(fdt) 	(fdt_get_header(fdt, last_comp_version))
+#define fdt_boot_cpuid_phys(fdt) 	(fdt_get_header(fdt, boot_cpuid_phys))
+#define fdt_size_dt_strings(fdt) 	(fdt_get_header(fdt, size_dt_strings))
+#define fdt_size_dt_struct(fdt)		(fdt_get_header(fdt, size_dt_struct))
+
+#define __fdt_set_hdr(name) \
+	static inline void fdt_set_##name(void *fdt, uint32_t val) \
+	{ \
+		struct fdt_header *fdth = (struct fdt_header*)fdt; \
+		fdth->name = cpu_to_fdt32(val); \
+	}
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
+
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ *     0, if the buffer appears to contain a valid device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings, as above
+ */
+int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize.  The buffer may overlap
+ * with the existing device tree blob at fdt.  Therefore,
+ *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_move(const void *fdt, void *buf, int bufsize);
+
+/**********************************************************************/
+/* Read-only functions                                                */
+/**********************************************************************/
+
+/**
+ * fdt_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ *     a pointer to the string, on success
+ *     NULL, if stroffset is out of bounds
+ */
+const char *fdt_string(const void *fdt, int stroffset);
+
+/**
+ * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map.  This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ *     the number of entries
+ */
+int fdt_num_mem_rsv(const void *fdt);
+
+/**
+ * fdt_get_mem_rsv - retrieve one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
+/**
+ * fdt_subnode_offset_namelen - find a subnode based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_subnode_offset(), but only examine the first
+ * namelen characters of name for matching the subnode name.  This is
+ * useful for finding subnodes based on a portion of a larger string,
+ * such as a full path.
+ */
+int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+			       const char *name, int namelen);
+/**
+ * fdt_subnode_offset - find a subnode of a given node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_subnode_offset() finds a subnode of the node at structure block
+ * offset parentoffset with the given name.  name may include a unit
+ * address, in which case fdt_subnode_offset() will find the subnode
+ * with that unit address, or the unit address may be omitted, in
+ * which case fdt_subnode_offset() will find an arbitrary subnode
+ * whose name excluding unit address matches the given name.
+ *
+ * returns:
+ *	structure block offset of the requested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_path_offset - find a tree node by its full path
+ * @fdt: pointer to the device tree blob
+ * @path: full path of the node to locate
+ *
+ * fdt_path_offset() finds a node of a given path in the device tree.
+ * Each path component may omit the unit address portion, but the
+ * results of this are undefined if any such path component is
+ * ambiguous (that is if there are multiple nodes at the relevant
+ * level matching the given component, differentiated only by unit
+ * address).
+ *
+ * returns:
+ *	structure block offset of the node with the requested path (>=0), on success
+ *	-FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
+ *	-FDT_ERR_NOTFOUND, if the requested node does not exist
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_path_offset(const void *fdt, const char *path);
+
+/**
+ * fdt_get_name - retrieve the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the starting node
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_name() retrieves the name (including unit address) of the
+ * device tree node at structure block offset nodeoffset.  If lenp is
+ * non-NULL, the length of this name is also returned, in the integer
+ * pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the node's name, on success
+ *		If lenp is non-NULL, *lenp contains the length of that name (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE, standard meanings
+ */
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+
+/**
+ * fdt_first_property_offset - find the offset of a node's first property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ *
+ * fdt_first_property_offset() finds the first property of the node at
+ * the given structure block offset.
+ *
+ * returns:
+ *	structure block offset of the property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested node has no properties
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_first_property_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_next_property_offset - step through a node's properties
+ * @fdt: pointer to the device tree blob
+ * @offset: structure block offset of a property
+ *
+ * fdt_next_property_offset() finds the property immediately after the
+ * one at the given structure block offset.  This will be a property
+ * of the same node as the given property.
+ *
+ * returns:
+ *	structure block offset of the next property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the given property is the last in its node
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_next_property_offset(const void *fdt, int offset);
+
+/**
+ * fdt_get_property_by_offset - retrieve the property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @offset: offset of the property to retrieve
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property_by_offset() retrieves a pointer to the
+ * fdt_property structure within the device tree blob at the given
+ * offset.  If lenp is non-NULL, the length of the property value is
+ * also returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp);
+
+/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int nodeoffset,
+						    const char *name,
+						    int namelen, int *lenp);
+
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset.  If lenp is
+ * non-NULL, the length of the property value is also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
+					    const char *name, int *lenp);
+static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
+						      const char *name,
+						      int *lenp)
+{
+	return (struct fdt_property *)(uintptr_t)
+		fdt_get_property(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_getprop_by_offset - retrieve the value of a property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @ffset: offset of the property to read
+ * @namep: pointer to a string variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop_by_offset() retrieves a pointer to the value of the
+ * property at structure block offset 'offset' (this will be a pointer
+ * to within the device blob itself, not a copy of the value).  If
+ * lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.  If namep is non-NULL,
+ * the property's namne will also be returned in the char * pointed to
+ * by namep (this will be a pointer to within the device tree's string
+ * block, not a new copy of the name).
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *		if namep is non-NULL *namep contiains a pointer to the property
+ *		name.
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp);
+
+/**
+ * fdt_getprop_namelen - get property value based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_getprop(), but only examine the first namelen
+ * characters of name for matching the property name.
+ */
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp);
+
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp);
+static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
+				  const char *name, int *lenp)
+{
+	return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_get_phandle - retrieve the phandle of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the node
+ *
+ * fdt_get_phandle() retrieves the phandle of the device tree node at
+ * structure block offset nodeoffset.
+ *
+ * returns:
+ *	the phandle of the node at nodeoffset, on success (!= 0, != -1)
+ *	0, if the node has no phandle, or another error occurs
+ */
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_get_alias_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias.  That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ *	a pointer to the expansion of the alias named 'name', of it exists
+ *	NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	0, on success
+ *		buf contains the absolute path of the node at
+ *		nodeoffset, as a NUL-terminated string.
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ *		characters and will not fit in the given buffer.
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth).  So
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node.  If the node at
+ * nodeoffset has depth D, then:
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ *	structure block offset of the node at node offset's ancestor
+ *		of depth supernodedepth (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+*	-FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node.  The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	depth of the node at nodeoffset (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ *	structure block offset of the parent of the node at nodeoffset
+ *		(>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_node_offset_by_prop_value - find nodes with a given property value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @propname: property name to check
+ * @propval: property value to search for
+ * @proplen: length of the value in propval
+ *
+ * fdt_node_offset_by_prop_value() returns the offset of the first
+ * node after startoffset, which has a property named propname whose
+ * value is of length proplen and has value equal to propval; or if
+ * startoffset is -1, the very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
+ *					       propval, proplen);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
+ *						       propval, proplen);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen);
+
+/**
+ * fdt_node_offset_by_phandle - find the node with a given phandle
+ * @fdt: pointer to the device tree blob
+ * @phandle: phandle value
+ *
+ * fdt_node_offset_by_phandle() returns the offset of the node
+ * which has the given phandle value.  If there is more than one node
+ * in the tree with the given phandle (an invalid tree), results are
+ * undefined.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0), on success
+ *	-FDT_ERR_NOTFOUND, no node with that phandle exists
+ *	-FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
+
+/**
+ * fdt_node_check_compatible: check a node's compatible property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ *	0, if the node has a 'compatible' property listing the given string
+ *	1, if the node has a 'compatible' property, but it does not list
+ *		the given string
+ *	-FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * 	-FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible);
+
+/**
+ * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @compatible: 'compatible' string to match against
+ *
+ * fdt_node_offset_by_compatible() returns the offset of the first
+ * node after startoffset, which has a 'compatible' property which
+ * lists the given compatible string; or if startoffset is -1, the
+ * very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible);
+
+/**********************************************************************/
+/* Write-in-place functions                                           */
+/**********************************************************************/
+
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+					   const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Sequential write functions                                         */
+/**********************************************************************/
+
+int fdt_create(void *buf, int bufsize);
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
+int fdt_finish_reservemap(void *fdt);
+int fdt_begin_node(void *fdt, const char *name);
+int fdt_property(void *fdt, const char *name, const void *val, int len);
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_property(fdt, name, &val, sizeof(val));
+}
+#define fdt_property_string(fdt, name, str) \
+	fdt_property(fdt, name, str, strlen(str)+1)
+int fdt_end_node(void *fdt);
+int fdt_finish(void *fdt);
+
+/**********************************************************************/
+/* Read-write functions                                               */
+/**********************************************************************/
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize);
+int fdt_pack(void *fdt);
+
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_mem_rsv(void *fdt, int n);
+
+/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string.  NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ *		to contain the new name
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+				   uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_string(fdt, nodeoffset, name, str) \
+	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Debugging / informational functions                                */
+/**********************************************************************/
+
+const char *fdt_strerror(int errval);
+
+#endif /* _LIBFDT_H */
diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
new file mode 100644
index 0000000..449bf60
--- /dev/null
+++ b/xen/common/libfdt/libfdt_env.h
@@ -0,0 +1,23 @@
+#ifndef _LIBFDT_ENV_H
+#define _LIBFDT_ENV_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <string.h>
+
+#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
+static inline uint32_t fdt32_to_cpu(uint32_t x)
+{
+	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
+}
+#define cpu_to_fdt32(x) fdt32_to_cpu(x)
+
+static inline uint64_t fdt64_to_cpu(uint64_t x)
+{
+	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
+		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
+}
+#define cpu_to_fdt64(x) fdt64_to_cpu(x)
+#undef _B
+
+#endif /* _LIBFDT_ENV_H */
diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
new file mode 100644
index 0000000..381133b
--- /dev/null
+++ b/xen/common/libfdt/libfdt_internal.h
@@ -0,0 +1,95 @@
+#ifndef _LIBFDT_INTERNAL_H
+#define _LIBFDT_INTERNAL_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include <fdt.h>
+
+#define FDT_ALIGN(x, a)		(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)		(FDT_ALIGN((x), FDT_TAGSIZE))
+
+#define FDT_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = fdt_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+int _fdt_check_node_offset(const void *fdt, int offset);
+int _fdt_check_prop_offset(const void *fdt, int offset);
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
+int _fdt_node_end_offset(void *fdt, int nodeoffset);
+
+static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
+{
+	return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
+}
+
+static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
+{
+	return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
+}
+
+static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
+{
+	const struct fdt_reserve_entry *rsv_table =
+		(const struct fdt_reserve_entry *)
+		((const char *)fdt + fdt_off_mem_rsvmap(fdt));
+
+	return rsv_table + n;
+}
+static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
+{
+	return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
+}
+
+#define FDT_SW_MAGIC		(~FDT_MAGIC)
+
+#endif /* _LIBFDT_INTERNAL_H */
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
new file mode 100644
index 0000000..3c3994e
--- /dev/null
+++ b/xen/common/libfdt/version.lds
@@ -0,0 +1,54 @@
+LIBFDT_1.2 {
+	global:
+		fdt_next_node;
+		fdt_check_header;
+		fdt_move;
+		fdt_string;
+		fdt_num_mem_rsv;
+		fdt_get_mem_rsv;
+		fdt_subnode_offset_namelen;
+		fdt_subnode_offset;
+		fdt_path_offset;
+		fdt_get_name;
+		fdt_get_property_namelen;
+		fdt_get_property;
+		fdt_getprop_namelen;
+		fdt_getprop;
+		fdt_get_phandle;
+		fdt_get_alias_namelen;
+		fdt_get_alias;
+		fdt_get_path;
+		fdt_supernode_atdepth_offset;
+		fdt_node_depth;
+		fdt_parent_offset;
+		fdt_node_offset_by_prop_value;
+		fdt_node_offset_by_phandle;
+		fdt_node_check_compatible;
+		fdt_node_offset_by_compatible;
+		fdt_setprop_inplace;
+		fdt_nop_property;
+		fdt_nop_node;
+		fdt_create;
+		fdt_add_reservemap_entry;
+		fdt_finish_reservemap;
+		fdt_begin_node;
+		fdt_property;
+		fdt_end_node;
+		fdt_finish;
+		fdt_open_into;
+		fdt_pack;
+		fdt_add_mem_rsv;
+		fdt_del_mem_rsv;
+		fdt_set_name;
+		fdt_setprop;
+		fdt_delprop;
+		fdt_add_subnode_namelen;
+		fdt_add_subnode;
+		fdt_del_node;
+		fdt_strerror;
+		fdt_offset_ptr;
+		fdt_next_tag;
+
+	local:
+		*;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObs-0000f1-Lg; Fri, 03 Feb 2012 19:15:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObq-0000cW-C8
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328296538!13086900!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6083 invoked from network); 3 Feb 2012 19:15:39 -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;
	3 Feb 2012 19:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350661"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:38 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpv011693;
	Fri, 3 Feb 2012 11:15:38 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:15 +0000
Message-ID: <1328296515-25876-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/7] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Prior to setting up the page tables, parse the DTB for the location
and size of RAM.

Use this information to get the physical address to relocate Xen to in
setup_pagetables().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/mm.c             |    3 +-
 xen/arch/arm/setup.c          |    3 +
 xen/common/Makefile           |    3 +
 xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/mm.h      |    5 +-
 xen/include/xen/device_tree.h |   36 ++++++++
 6 files changed, 225 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/device_tree.c
 create mode 100644 xen/include/xen/device_tree.h

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..20968e0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -20,6 +20,7 @@
 #include <xen/config.h>
 #include <xen/compile.h>
 #include <xen/types.h>
+#include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
@@ -159,7 +160,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
         write_pte(xen_second + second_linear_offset(dest_va), pte);
     }
 
-    xen_paddr = XEN_PADDR;
+    xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the empty L2 above the fixmap */
     dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 33c880e..ef50ccc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -19,6 +19,7 @@
 
 #include <xen/config.h>
 #include <xen/compile.h>
+#include <xen/device_tree.h>
 #include <xen/domain_page.h>
 #include <xen/types.h>
 #include <xen/string.h>
@@ -70,6 +71,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 {
     int i;
 
+    device_tree_early_init((void *)atag_paddr);
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 7a3cd38..2f9b674 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-y += bitmap.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-y += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
@@ -60,3 +61,5 @@ subdir-$(ia64) += hvm
 
 subdir-y += libelf
 subdir-y += libfdt
+
+CFLAGS += -Ilibfdt
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
new file mode 100644
index 0000000..a60ff6d
--- /dev/null
+++ b/xen/common/device_tree.c
@@ -0,0 +1,179 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/device_tree.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#include <libfdt.h>
+
+struct dt_early_info __initdata early_info;
+
+static void __init get_val(const u32 **cell, u32 cells, u64 *val)
+{
+    *val = 0;
+
+    while (cells--) {
+        *val <<= 32;
+        *val |= fdt32_to_cpu(*(*cell)++);
+    }
+}
+
+static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
+                                u64 *start, u64 *size)
+{
+    get_val(cell, address_cells, start);
+    get_val(cell, size_cells, size);
+}
+
+static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if (!prop || prop->len < sizeof(u32))
+        return 0; /* default to 0 */
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+static void __init process_memory_node(const void *fdt, int node,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    size_t reg_cells;
+    int i;
+    int banks;
+    const u32 *cell;
+    paddr_t start, size;
+
+    if (address_cells < 1 || size_cells < 1) {
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if (!prop) {
+        early_printk("fdt: node `%s': missing `reg' property\n",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    reg_cells = address_cells + size_cells;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
+
+    for (i = 0; i < banks; i++) {
+        get_register(&cell, address_cells, size_cells, &start, &size);
+        early_info.mem.bank[early_info.mem.nr_banks].start = start;
+        early_info.mem.bank[early_info.mem.nr_banks].size = size;
+        early_info.mem.nr_banks++;
+    }
+}
+
+#define MAX_DEPTH 16
+
+static void __init early_scan(const void *fdt)
+{
+    int node;
+    int depth;
+    const char *name;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+
+    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= MAX_DEPTH) {
+            early_printk("fdt: node '%s': nested too deep\n",
+                         fdt_get_name(fdt, node, NULL));
+            continue;
+        }
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        if (strncmp(name, "memory", 6) == 0)
+            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
+    }
+}
+
+static void __init early_print_info(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    int i;
+
+    for (i = 0; i < mi->nr_banks; i++)
+        early_printk("RAM: %016llx - %016llx\n",
+                     mi->bank[i].start, mi->bank[i].start + mi->bank[i].size - 1);
+}
+
+/**
+ * device_tree_early_init - initialize early info from a DTB
+ * @fdt: flattened device tree binary
+ */
+void __init device_tree_early_init(const void *fdt)
+{
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if (ret < 0)
+        early_panic("No valid device tree\n");
+
+    early_scan(fdt);
+    early_print_info();
+}
+
+/**
+ * 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
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..8efa63b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -6,9 +6,8 @@
 #include <asm/page.h>
 #include <public/xen.h>
 
-/* Find a suitable place at the top of memory for Xen to live */
-/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
-#define XEN_PADDR 0x80ffe00000ull
+/* Align Xen to a 2 MiB boundary. */
+#define XEN_PADDR_ALIGN (1 << 21)
 
 /*
  * Per-page-frame information.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
new file mode 100644
index 0000000..eb7f219
--- /dev/null
+++ b/xen/include/xen/device_tree.h
@@ -0,0 +1,36 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __XEN_DEVICE_TREE_H__
+#define __XEN_DEVICE_TREE_H__
+
+#include <xen/types.h>
+
+#define NR_MEM_BANKS 8
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+};
+
+struct dt_mem_info {
+    int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};    
+
+struct dt_early_info {
+    struct dt_mem_info mem;
+};
+
+extern struct dt_early_info early_info;
+
+void device_tree_early_init(const void *fdt);
+paddr_t device_tree_get_xen_paddr(void);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObs-0000f1-Lg; Fri, 03 Feb 2012 19:15:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObq-0000cW-C8
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328296538!13086900!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6083 invoked from network); 3 Feb 2012 19:15:39 -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;
	3 Feb 2012 19:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350661"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:38 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpv011693;
	Fri, 3 Feb 2012 11:15:38 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:15 +0000
Message-ID: <1328296515-25876-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/7] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Prior to setting up the page tables, parse the DTB for the location
and size of RAM.

Use this information to get the physical address to relocate Xen to in
setup_pagetables().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/mm.c             |    3 +-
 xen/arch/arm/setup.c          |    3 +
 xen/common/Makefile           |    3 +
 xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/mm.h      |    5 +-
 xen/include/xen/device_tree.h |   36 ++++++++
 6 files changed, 225 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/device_tree.c
 create mode 100644 xen/include/xen/device_tree.h

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..20968e0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -20,6 +20,7 @@
 #include <xen/config.h>
 #include <xen/compile.h>
 #include <xen/types.h>
+#include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
@@ -159,7 +160,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
         write_pte(xen_second + second_linear_offset(dest_va), pte);
     }
 
-    xen_paddr = XEN_PADDR;
+    xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the empty L2 above the fixmap */
     dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 33c880e..ef50ccc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -19,6 +19,7 @@
 
 #include <xen/config.h>
 #include <xen/compile.h>
+#include <xen/device_tree.h>
 #include <xen/domain_page.h>
 #include <xen/types.h>
 #include <xen/string.h>
@@ -70,6 +71,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 {
     int i;
 
+    device_tree_early_init((void *)atag_paddr);
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 7a3cd38..2f9b674 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-y += bitmap.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-y += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
@@ -60,3 +61,5 @@ subdir-$(ia64) += hvm
 
 subdir-y += libelf
 subdir-y += libfdt
+
+CFLAGS += -Ilibfdt
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
new file mode 100644
index 0000000..a60ff6d
--- /dev/null
+++ b/xen/common/device_tree.c
@@ -0,0 +1,179 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/device_tree.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#include <libfdt.h>
+
+struct dt_early_info __initdata early_info;
+
+static void __init get_val(const u32 **cell, u32 cells, u64 *val)
+{
+    *val = 0;
+
+    while (cells--) {
+        *val <<= 32;
+        *val |= fdt32_to_cpu(*(*cell)++);
+    }
+}
+
+static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
+                                u64 *start, u64 *size)
+{
+    get_val(cell, address_cells, start);
+    get_val(cell, size_cells, size);
+}
+
+static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if (!prop || prop->len < sizeof(u32))
+        return 0; /* default to 0 */
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+static void __init process_memory_node(const void *fdt, int node,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    size_t reg_cells;
+    int i;
+    int banks;
+    const u32 *cell;
+    paddr_t start, size;
+
+    if (address_cells < 1 || size_cells < 1) {
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if (!prop) {
+        early_printk("fdt: node `%s': missing `reg' property\n",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    reg_cells = address_cells + size_cells;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
+
+    for (i = 0; i < banks; i++) {
+        get_register(&cell, address_cells, size_cells, &start, &size);
+        early_info.mem.bank[early_info.mem.nr_banks].start = start;
+        early_info.mem.bank[early_info.mem.nr_banks].size = size;
+        early_info.mem.nr_banks++;
+    }
+}
+
+#define MAX_DEPTH 16
+
+static void __init early_scan(const void *fdt)
+{
+    int node;
+    int depth;
+    const char *name;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+
+    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= MAX_DEPTH) {
+            early_printk("fdt: node '%s': nested too deep\n",
+                         fdt_get_name(fdt, node, NULL));
+            continue;
+        }
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        if (strncmp(name, "memory", 6) == 0)
+            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
+    }
+}
+
+static void __init early_print_info(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    int i;
+
+    for (i = 0; i < mi->nr_banks; i++)
+        early_printk("RAM: %016llx - %016llx\n",
+                     mi->bank[i].start, mi->bank[i].start + mi->bank[i].size - 1);
+}
+
+/**
+ * device_tree_early_init - initialize early info from a DTB
+ * @fdt: flattened device tree binary
+ */
+void __init device_tree_early_init(const void *fdt)
+{
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if (ret < 0)
+        early_panic("No valid device tree\n");
+
+    early_scan(fdt);
+    early_print_info();
+}
+
+/**
+ * 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
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..8efa63b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -6,9 +6,8 @@
 #include <asm/page.h>
 #include <public/xen.h>
 
-/* Find a suitable place at the top of memory for Xen to live */
-/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
-#define XEN_PADDR 0x80ffe00000ull
+/* Align Xen to a 2 MiB boundary. */
+#define XEN_PADDR_ALIGN (1 << 21)
 
 /*
  * Per-page-frame information.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
new file mode 100644
index 0000000..eb7f219
--- /dev/null
+++ b/xen/include/xen/device_tree.h
@@ -0,0 +1,36 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __XEN_DEVICE_TREE_H__
+#define __XEN_DEVICE_TREE_H__
+
+#include <xen/types.h>
+
+#define NR_MEM_BANKS 8
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+};
+
+struct dt_mem_info {
+    int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};    
+
+struct dt_early_info {
+    struct dt_mem_info mem;
+};
+
+extern struct dt_early_info early_info;
+
+void device_tree_early_init(const void *fdt);
+paddr_t device_tree_get_xen_paddr(void);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObr-0000e6-3w; Fri, 03 Feb 2012 19:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObp-0000c6-2M
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328296536!6302621!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14993 invoked from network); 3 Feb 2012 19:15:38 -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;
	3 Feb 2012 19:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350651"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:35 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpr011693;
	Fri, 3 Feb 2012 11:15:34 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:11 +0000
Message-ID: <1328296515-25876-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/7] arm: link a device tree blob into the xen
	image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Link a device tree blob (DTB) into the xen image.  This is loaded to
start of RAM + 0x100 and xen_start() is called with the correct
address in atag_paddr.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile  |    7 +++++--
 xen/arch/arm/dtb.S     |    2 ++
 xen/arch/arm/head.S    |    5 +++++
 xen/arch/arm/xen.lds.S |    6 ++++++
 4 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/dtb.S

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..ac346a5 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,5 +1,6 @@
 subdir-y += lib
 
+obj-y += dtb.o
 obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
@@ -27,7 +28,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
-	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	# XXX strip it
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
@@ -50,7 +51,7 @@ endif
 $(BASEDIR)/common/symbols-dummy.o:
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
 
-$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o dtb.o
 	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
@@ -71,6 +72,8 @@ xen.lds: xen.lds.S
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
+dtb.o: platform.dtb
+
 .PHONY: clean
 clean::
 	rm -f asm-offsets.s xen.lds
diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
new file mode 100644
index 0000000..0728c04
--- /dev/null
+++ b/xen/arch/arm/dtb.S
@@ -0,0 +1,2 @@
+        .section .dtb,#alloc
+        .incbin "platform.dtb"
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index b98c921..9951f37 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -55,6 +55,11 @@ start:
 	adr   r9, start              /* r9  := paddr (start) */
 	sub   r10, r9, r0            /* r10 := phys-offset */
 
+        /* FIXME: using the DTB in the .dtb section. */
+        mov   r7, #0
+        ldr   r8, =_sdtb
+        add   r8, r10
+
 #ifdef EARLY_UART_ADDRESS
 	/* Say hello */
 	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5a62e2c..4bcca57 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -122,6 +122,12 @@ SECTIONS
   } :text
   _end = . ;
 
+  /* FIXME: don't yet have a bootloader to provide the DTB, link it
+     into Xen in its own section. */
+  . = 0x100;
+  _sdtb = .;
+  .dtb : { dtb.o(.dtb) }
+
   /* Sections to be discarded */
   /DISCARD/ : {
        *(.exit.text)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObl-0000ck-Me; Fri, 03 Feb 2012 19:15:41 +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 1RtObk-0000bn-OY
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4802 invoked from network); 3 Feb 2012 19:14:46 -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;
	3 Feb 2012 19:14:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612421"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:32 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q13JFVpo011693	for
	<xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 11:15:31 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:08 +0000
Message-ID: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/7] RFC: arm: (really) minimal device tree
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This set of patches adds libfdt and some minimal infrastructure for
parsing a DTB.  The DTB is linked into the Xen image since there isn't
a bootloader when running on the model. Information on available RAM
is obtained and used to get the address to relocate Xen to (the MM is
still initialized with hard-coded values, I'll be fixing this next).

I also added an early_printk() function since its needed when doing
the early scan of the DTB.  It's not very platform-independant but it
should do for now.

So, not really a lot here but I think it would be useful to get the
basic infrastructure reviewed a bit before making more use of it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObr-0000e6-3w; Fri, 03 Feb 2012 19:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObp-0000c6-2M
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328296536!6302621!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14993 invoked from network); 3 Feb 2012 19:15:38 -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;
	3 Feb 2012 19:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350651"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:35 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpr011693;
	Fri, 3 Feb 2012 11:15:34 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:11 +0000
Message-ID: <1328296515-25876-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/7] arm: link a device tree blob into the xen
	image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Link a device tree blob (DTB) into the xen image.  This is loaded to
start of RAM + 0x100 and xen_start() is called with the correct
address in atag_paddr.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile  |    7 +++++--
 xen/arch/arm/dtb.S     |    2 ++
 xen/arch/arm/head.S    |    5 +++++
 xen/arch/arm/xen.lds.S |    6 ++++++
 4 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/dtb.S

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..ac346a5 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,5 +1,6 @@
 subdir-y += lib
 
+obj-y += dtb.o
 obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
@@ -27,7 +28,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
-	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	# XXX strip it
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
@@ -50,7 +51,7 @@ endif
 $(BASEDIR)/common/symbols-dummy.o:
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
 
-$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o dtb.o
 	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
@@ -71,6 +72,8 @@ xen.lds: xen.lds.S
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
+dtb.o: platform.dtb
+
 .PHONY: clean
 clean::
 	rm -f asm-offsets.s xen.lds
diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
new file mode 100644
index 0000000..0728c04
--- /dev/null
+++ b/xen/arch/arm/dtb.S
@@ -0,0 +1,2 @@
+        .section .dtb,#alloc
+        .incbin "platform.dtb"
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index b98c921..9951f37 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -55,6 +55,11 @@ start:
 	adr   r9, start              /* r9  := paddr (start) */
 	sub   r10, r9, r0            /* r10 := phys-offset */
 
+        /* FIXME: using the DTB in the .dtb section. */
+        mov   r7, #0
+        ldr   r8, =_sdtb
+        add   r8, r10
+
 #ifdef EARLY_UART_ADDRESS
 	/* Say hello */
 	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5a62e2c..4bcca57 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -122,6 +122,12 @@ SECTIONS
   } :text
   _end = . ;
 
+  /* FIXME: don't yet have a bootloader to provide the DTB, link it
+     into Xen in its own section. */
+  . = 0x100;
+  _sdtb = .;
+  .dtb : { dtb.o(.dtb) }
+
   /* Sections to be discarded */
   /DISCARD/ : {
        *(.exit.text)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObl-0000ck-Me; Fri, 03 Feb 2012 19:15:41 +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 1RtObk-0000bn-OY
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4802 invoked from network); 3 Feb 2012 19:14:46 -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;
	3 Feb 2012 19:14:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612421"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:32 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q13JFVpo011693	for
	<xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 11:15:31 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:08 +0000
Message-ID: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/7] RFC: arm: (really) minimal device tree
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This set of patches adds libfdt and some minimal infrastructure for
parsing a DTB.  The DTB is linked into the Xen image since there isn't
a bootloader when running on the model. Information on available RAM
is obtained and used to get the address to relocate Xen to (the MM is
still initialized with hard-coded values, I'll be fixing this next).

I also added an early_printk() function since its needed when doing
the early scan of the DTB.  It's not very platform-independant but it
should do for now.

So, not really a lot here but I think it would be useful to get the
basic infrastructure reviewed a bit before making more use of it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtObr-0000eL-GZ; Fri, 03 Feb 2012 19:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObp-0000c8-A7
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328296536!6302621!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15010 invoked from network); 3 Feb 2012 19:15:38 -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;
	3 Feb 2012 19:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350658"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpt011693;
	Fri, 3 Feb 2012 11:15:36 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:13 +0000
Message-ID: <1328296515-25876-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/7] libfdt: fixup libfdt_env.h for xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/libfdt_env.h |   27 ++++++++++-----------------
 xen/include/xen/types.h        |    2 ++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
index 449bf60..8c0c030 100644
--- a/xen/common/libfdt/libfdt_env.h
+++ b/xen/common/libfdt/libfdt_env.h
@@ -1,23 +1,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <stdint.h>
-#include <string.h>
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <asm/byteorder.h>
 
-#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
-static inline uint32_t fdt32_to_cpu(uint32_t x)
-{
-	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
-}
-#define cpu_to_fdt32(x) fdt32_to_cpu(x)
-
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
-	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
-		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
-}
-#define cpu_to_fdt64(x) fdt64_to_cpu(x)
-#undef _B
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
 
 #endif /* _LIBFDT_ENV_H */
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index fd89c98..727d5a5 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -58,4 +58,6 @@ typedef __u32 __be32;
 typedef __u64 __le64;
 typedef __u64 __be64;
 
+typedef unsigned long uintptr_t;
+
 #endif /* __TYPES_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtObr-0000eL-GZ; Fri, 03 Feb 2012 19:15:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RtObp-0000c8-A7
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328296536!6302621!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15010 invoked from network); 3 Feb 2012 19:15:38 -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;
	3 Feb 2012 19:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="180350658"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpt011693;
	Fri, 3 Feb 2012 11:15:36 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:13 +0000
Message-ID: <1328296515-25876-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/7] libfdt: fixup libfdt_env.h for xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/libfdt_env.h |   27 ++++++++++-----------------
 xen/include/xen/types.h        |    2 ++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
index 449bf60..8c0c030 100644
--- a/xen/common/libfdt/libfdt_env.h
+++ b/xen/common/libfdt/libfdt_env.h
@@ -1,23 +1,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <stdint.h>
-#include <string.h>
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <asm/byteorder.h>
 
-#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
-static inline uint32_t fdt32_to_cpu(uint32_t x)
-{
-	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
-}
-#define cpu_to_fdt32(x) fdt32_to_cpu(x)
-
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
-	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
-		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
-}
-#define cpu_to_fdt64(x) fdt64_to_cpu(x)
-#undef _B
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
 
 #endif /* _LIBFDT_ENV_H */
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index fd89c98..727d5a5 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -58,4 +58,6 @@ typedef __u32 __be32;
 typedef __u64 __le64;
 typedef __u64 __be64;
 
+typedef unsigned long uintptr_t;
+
 #endif /* __TYPES_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtObh-0000bt-C9; Fri, 03 Feb 2012 19:15:37 +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 1RtObg-0000bo-8R
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 3 Feb 2012 19:14:46 -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;
	3 Feb 2012 19:14:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:34 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpq011693;
	Fri, 3 Feb 2012 11:15:33 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:10 +0000
Message-ID: <1328296515-25876-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/7] libfdt: add to build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/Makefile        |    1 +
 xen/common/libfdt/Makefile |    5 +++++
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..7a3cd38 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,3 +59,4 @@ subdir-$(x86_64) += hvm
 subdir-$(ia64) += hvm
 
 subdir-y += libelf
+subdir-y += libfdt
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
new file mode 100644
index 0000000..0e65bc0
--- /dev/null
+++ b/xen/common/libfdt/Makefile
@@ -0,0 +1,5 @@
+include Makefile.libfdt
+
+obj-y += $(LIBFDT_OBJS)
+
+CFLAGS += -I.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtObh-0000bt-C9; Fri, 03 Feb 2012 19:15:37 +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 1RtObg-0000bo-8R
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 3 Feb 2012 19:14:46 -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;
	3 Feb 2012 19:14:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:34 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpq011693;
	Fri, 3 Feb 2012 11:15:33 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:10 +0000
Message-ID: <1328296515-25876-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/7] libfdt: add to build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/Makefile        |    1 +
 xen/common/libfdt/Makefile |    5 +++++
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..7a3cd38 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,3 +59,4 @@ subdir-$(x86_64) += hvm
 subdir-$(ia64) += hvm
 
 subdir-y += libelf
+subdir-y += libfdt
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
new file mode 100644
index 0000000..0e65bc0
--- /dev/null
+++ b/xen/common/libfdt/Makefile
@@ -0,0 +1,5 @@
+include Makefile.libfdt
+
+obj-y += $(LIBFDT_OBJS)
+
+CFLAGS += -I.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObl-0000cb-9i; Fri, 03 Feb 2012 19:15:41 +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 1RtObj-0000c5-SO
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4927 invoked from network); 3 Feb 2012 19:14:50 -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;
	3 Feb 2012 19:14:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612432"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpu011693;
	Fri, 3 Feb 2012 11:15:37 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:14 +0000
Message-ID: <1328296515-25876-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/7] arm: add early_printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add early_printk() which can be used before setup_pagetables().  This
will be used when doing the early parsing of the DTB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/early_printk.c        |   72 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/early_printk.h |   27 +++++++++++++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/early_printk.c
 create mode 100644 xen/include/asm-arm/early_printk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ac346a5..4794cfc 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-y += lib
 
 obj-y += dtb.o
 obj-y += dummy.o
+obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
new file mode 100644
index 0000000..1d9787b
--- /dev/null
+++ b/xen/arch/arm/early_printk.c
@@ -0,0 +1,72 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+static void __init early_putch(char c)
+{
+    volatile uint32_t *r;
+
+    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
+                     + XEN_VIRT_START + (1 << 21));
+
+    /* FIXME: assuming a PL011 UART. */
+    while(*(r + 0x6) & 0x8)
+        ;
+    *r = c;
+}
+
+static void __init early_puts(const char *s)
+{
+    while (*s != '\0') {
+        if (*s == '\n')
+            early_putch('\r');
+        early_putch(*s);
+        s++;
+    }
+}
+
+static void __init early_vprintk(const char *fmt, va_list args)
+{
+    char buf[80];
+
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    early_puts(buf);
+}
+
+void __init early_printk(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+}
+
+void __attribute__((noreturn)) __init
+early_panic(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+
+    while(1);
+}
+
+#endif /* #ifdef EARLY_UART_ADDRESS */
diff --git a/xen/include/asm-arm/early_printk.h b/xen/include/asm-arm/early_printk.h
new file mode 100644
index 0000000..f45f21e
--- /dev/null
+++ b/xen/include/asm-arm/early_printk.h
@@ -0,0 +1,27 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARM_EARLY_PRINTK_H__
+#define __ARM_EARLY_PRINTK_H__
+
+#include <xen/config.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+void early_printk(const char *fmt, ...);
+void early_panic(const char *fmt, ...);
+
+#else
+
+static inline void early_printk(const char *fmt, ...) {}
+static inline void early_panic(const char *fmt, ...) {}
+
+#endif
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 19:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 19: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.xensource.com>)
	id 1RtObl-0000cb-9i; Fri, 03 Feb 2012 19:15:41 +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 1RtObj-0000c5-SO
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 19:15:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328296484!52838160!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA1Mjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4927 invoked from network); 3 Feb 2012 19:14:50 -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;
	3 Feb 2012 19:14:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="21612432"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 14:15:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 14:15:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q13JFVpu011693;
	Fri, 3 Feb 2012 11:15:37 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 3 Feb 2012 19:15:14 +0000
Message-ID: <1328296515-25876-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/7] arm: add early_printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add early_printk() which can be used before setup_pagetables().  This
will be used when doing the early parsing of the DTB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/early_printk.c        |   72 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/early_printk.h |   27 +++++++++++++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/early_printk.c
 create mode 100644 xen/include/asm-arm/early_printk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ac346a5..4794cfc 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-y += lib
 
 obj-y += dtb.o
 obj-y += dummy.o
+obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
new file mode 100644
index 0000000..1d9787b
--- /dev/null
+++ b/xen/arch/arm/early_printk.c
@@ -0,0 +1,72 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+static void __init early_putch(char c)
+{
+    volatile uint32_t *r;
+
+    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
+                     + XEN_VIRT_START + (1 << 21));
+
+    /* FIXME: assuming a PL011 UART. */
+    while(*(r + 0x6) & 0x8)
+        ;
+    *r = c;
+}
+
+static void __init early_puts(const char *s)
+{
+    while (*s != '\0') {
+        if (*s == '\n')
+            early_putch('\r');
+        early_putch(*s);
+        s++;
+    }
+}
+
+static void __init early_vprintk(const char *fmt, va_list args)
+{
+    char buf[80];
+
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    early_puts(buf);
+}
+
+void __init early_printk(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+}
+
+void __attribute__((noreturn)) __init
+early_panic(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+
+    while(1);
+}
+
+#endif /* #ifdef EARLY_UART_ADDRESS */
diff --git a/xen/include/asm-arm/early_printk.h b/xen/include/asm-arm/early_printk.h
new file mode 100644
index 0000000..f45f21e
--- /dev/null
+++ b/xen/include/asm-arm/early_printk.h
@@ -0,0 +1,27 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARM_EARLY_PRINTK_H__
+#define __ARM_EARLY_PRINTK_H__
+
+#include <xen/config.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+void early_printk(const char *fmt, ...);
+void early_panic(const char *fmt, ...);
+
+#else
+
+static inline void early_printk(const char *fmt, ...) {}
+static inline void early_panic(const char *fmt, ...) {}
+
+#endif
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 20:22:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 20:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtPeE-0004LZ-Vf; Fri, 03 Feb 2012 20:22:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RtPeD-0004LR-M6
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 20:22:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328300530!13243292!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9455 invoked from network); 3 Feb 2012 20:22:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 20:22:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RtPe5-000Mww-0n; Fri, 03 Feb 2012 20:22:09 +0000
Date: Fri, 3 Feb 2012 20:22:08 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120203202208.GC78380@ocelot.phlegethon.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-4-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328296515-25876-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/7] arm: link a device tree blob into the
	xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:15 +0000 on 03 Feb (1328296511), David Vrabel wrote:
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index b98c921..9951f37 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -55,6 +55,11 @@ start:
>  	adr   r9, start              /* r9  := paddr (start) */
>  	sub   r10, r9, r0            /* r10 := phys-offset */
>  
> +        /* FIXME: using the DTB in the .dtb section. */

The rest of this file uses leading tabs for indentation (not for any
particular reason except emascs did it by default).  I'd be happy with a
patch to change to spaces throughout but I'd rather not mix.

> +        mov   r7, #0

Why?

> +        ldr   r8, =_sdtb
> +        add   r8, r10

This should have a comment like 'r8  := paddr (DTB)', to make it clear
what you're overriding the previous r8 value with.  (Yes, I'm being picky
but I really believe you can't over-comment asm, specially wierd start
of day stuff.)

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 20:22:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 20:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtPeE-0004LZ-Vf; Fri, 03 Feb 2012 20:22:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RtPeD-0004LR-M6
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 20:22:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328300530!13243292!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9455 invoked from network); 3 Feb 2012 20:22:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 20:22:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RtPe5-000Mww-0n; Fri, 03 Feb 2012 20:22:09 +0000
Date: Fri, 3 Feb 2012 20:22:08 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120203202208.GC78380@ocelot.phlegethon.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-4-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328296515-25876-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/7] arm: link a device tree blob into the
	xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:15 +0000 on 03 Feb (1328296511), David Vrabel wrote:
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index b98c921..9951f37 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -55,6 +55,11 @@ start:
>  	adr   r9, start              /* r9  := paddr (start) */
>  	sub   r10, r9, r0            /* r10 := phys-offset */
>  
> +        /* FIXME: using the DTB in the .dtb section. */

The rest of this file uses leading tabs for indentation (not for any
particular reason except emascs did it by default).  I'd be happy with a
patch to change to spaces throughout but I'd rather not mix.

> +        mov   r7, #0

Why?

> +        ldr   r8, =_sdtb
> +        add   r8, r10

This should have a comment like 'r8  := paddr (DTB)', to make it clear
what you're overriding the previous r8 value with.  (Yes, I'm being picky
but I really believe you can't over-comment asm, specially wierd start
of day stuff.)

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:19:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtQWt-000595-60; Fri, 03 Feb 2012 21:18:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RtQWq-00058y-Ty
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 21:18:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328303918!15239623!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16840 invoked from network); 3 Feb 2012 21:18:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 21:18:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RtQWj-000N3y-11; Fri, 03 Feb 2012 21:18:37 +0000
Date: Fri, 3 Feb 2012 21:18:36 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120203211836.GD78380@ocelot.phlegethon.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial
	page tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:15 +0000 on 03 Feb (1328296512), David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Add a 1:1 mapping for the device tree blob in the initial page tables.
> This will allow the DTB to be parsed for memory information prior to
> setting up the real page tables.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/head.S |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 9951f37..8385481 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -202,6 +202,11 @@ hyp:
>  	add   r4, r4, #8
>  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>  #endif
> +	mov   r3, #0x0
> +	orr   r2, r8, #0xe00
> +	orr   r2, r2, #0x07d
> +	mov   r4, r8, lsr #18        /* Slot for (r8 == atag_paddr) */
> +	strd  r2, r3, [r1, r4]       /* Map DTB there */

It might be better to map the DTB at a fixed VA (say, the next
second-level slot up from the fixmap one) so we don't have to worry
about the DTB's PA clashing with Xen's VAs.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:19:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtQWt-000595-60; Fri, 03 Feb 2012 21:18:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RtQWq-00058y-Ty
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 21:18:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328303918!15239623!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16840 invoked from network); 3 Feb 2012 21:18:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Feb 2012 21:18:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RtQWj-000N3y-11; Fri, 03 Feb 2012 21:18:37 +0000
Date: Fri, 3 Feb 2012 21:18:36 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120203211836.GD78380@ocelot.phlegethon.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial
	page tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:15 +0000 on 03 Feb (1328296512), David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Add a 1:1 mapping for the device tree blob in the initial page tables.
> This will allow the DTB to be parsed for memory information prior to
> setting up the real page tables.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/head.S |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 9951f37..8385481 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -202,6 +202,11 @@ hyp:
>  	add   r4, r4, #8
>  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>  #endif
> +	mov   r3, #0x0
> +	orr   r2, r8, #0xe00
> +	orr   r2, r2, #0x07d
> +	mov   r4, r8, lsr #18        /* Slot for (r8 == atag_paddr) */
> +	strd  r2, r3, [r1, r4]       /* Map DTB there */

It might be better to map the DTB at a fixed VA (say, the next
second-level slot up from the fixmap one) so we don't have to worry
about the DTB's PA clashing with Xen's VAs.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:31:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtQiM-0005R0-GN; Fri, 03 Feb 2012 21:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RtPS4-0003tw-Oz
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 20:09:44 +0000
Received: from [85.158.143.35:47493] by server-1.bemta-4.messagelabs.com id
	32/9D-29738-80F3C2F4; Fri, 03 Feb 2012 20:09:44 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328299782!1911150!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14429 invoked from network); 3 Feb 2012 20:09:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 20:09:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13K9eEh012150
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 20:09:40 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
	q13K9cNd002178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 20:09: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
	q13K9cCa001153; Fri, 3 Feb 2012 14:09:38 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 12:09:38 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
Message-Id: <9ae3b2b7b494ab8fbc54.1328299821@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Fri, 03 Feb 2012 15:10:21 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F2C3F05.001A,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Fri, 03 Feb 2012 21:30:32 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>, Zhigang Wang <w1z2g3@gmail.com>
Subject: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328294351 18000
# Node ID 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: fix bootloader args setting

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r e2722b24dc09 -r 9ae3b2b7b494 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Feb 03 13:39:11 2012 -0500
@@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *p = info->u.pv.bootloader_args[0];
-        while (*(p++))
-            flexarray_set(args, nr++, p);
+        char **p = info->u.pv.bootloader_args;
+        while (*p) {
+            flexarray_set(args, nr++, *p);
+            p++;
+        }
     }
 
     flexarray_set(args, nr++, disk);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:31:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtQiM-0005R0-GN; Fri, 03 Feb 2012 21:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RtPS4-0003tw-Oz
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 20:09:44 +0000
Received: from [85.158.143.35:47493] by server-1.bemta-4.messagelabs.com id
	32/9D-29738-80F3C2F4; Fri, 03 Feb 2012 20:09:44 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328299782!1911150!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14429 invoked from network); 3 Feb 2012 20:09:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 20:09:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13K9eEh012150
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 3 Feb 2012 20:09:40 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
	q13K9cNd002178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 3 Feb 2012 20:09: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
	q13K9cCa001153; Fri, 3 Feb 2012 14:09:38 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 12:09:38 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
Message-Id: <9ae3b2b7b494ab8fbc54.1328299821@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Fri, 03 Feb 2012 15:10:21 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F2C3F05.001A,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Fri, 03 Feb 2012 21:30:32 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>, Zhigang Wang <w1z2g3@gmail.com>
Subject: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328294351 18000
# Node ID 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: fix bootloader args setting

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r e2722b24dc09 -r 9ae3b2b7b494 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Feb 03 13:39:11 2012 -0500
@@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *p = info->u.pv.bootloader_args[0];
-        while (*(p++))
-            flexarray_set(args, nr++, p);
+        char **p = info->u.pv.bootloader_args;
+        while (*p) {
+            flexarray_set(args, nr++, *p);
+            p++;
+        }
     }
 
     flexarray_set(args, nr++, disk);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21: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.xensource.com>)
	id 1RtQiK-0005Qp-SQ; Fri, 03 Feb 2012 21:30:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RtO2E-0008DX-8K
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 18:38:58 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328294330!4447072!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21138 invoked from network); 3 Feb 2012 18:38:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 18:38:52 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13IcnEB003549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 18:38:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q13IcmCi009113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 18:38: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
	q13IcmoR005882
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 12:38:48 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 10:38:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
Message-Id: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Fri, 03 Feb 2012 13:39:58 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F2C29BA.0086,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Fri, 03 Feb 2012 21:30:32 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328294351 18000
# Node ID 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: fix bootloader args setting

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r e2722b24dc09 -r 9ae3b2b7b494 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Feb 03 13:39:11 2012 -0500
@@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *p = info->u.pv.bootloader_args[0];
-        while (*(p++))
-            flexarray_set(args, nr++, p);
+        char **p = info->u.pv.bootloader_args;
+        while (*p) {
+            flexarray_set(args, nr++, *p);
+            p++;
+        }
     }
 
     flexarray_set(args, nr++, disk);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21: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.xensource.com>)
	id 1RtQiK-0005Qp-SQ; Fri, 03 Feb 2012 21:30:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RtO2E-0008DX-8K
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 18:38:58 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328294330!4447072!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI4MzYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21138 invoked from network); 3 Feb 2012 18:38:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Feb 2012 18:38:52 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q13IcnEB003549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 18:38:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q13IcmCi009113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 18:38: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
	q13IcmoR005882
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 12:38:48 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 03 Feb 2012 10:38:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
Message-Id: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Fri, 03 Feb 2012 13:39:58 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F2C29BA.0086,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Fri, 03 Feb 2012 21:30:32 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328294351 18000
# Node ID 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: fix bootloader args setting

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r e2722b24dc09 -r 9ae3b2b7b494 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Feb 03 13:39:11 2012 -0500
@@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *p = info->u.pv.bootloader_args[0];
-        while (*(p++))
-            flexarray_set(args, nr++, p);
+        char **p = info->u.pv.bootloader_args;
+        while (*p) {
+            flexarray_set(args, nr++, *p);
+            p++;
+        }
     }
 
     flexarray_set(args, nr++, disk);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21: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.xensource.com>)
	id 1RtQiI-0005Qi-E0; Fri, 03 Feb 2012 21:30:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RtJhE-00040p-VB
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:01:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328277653!13593206!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17219 invoked from network); 3 Feb 2012 14:00:54 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:00:54 -0000
Received: by wibhm2 with SMTP id hm2so7299690wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 06:00:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to;
	bh=YdoNxvwop33RfHl88IqibVkkd06gLqSc7Pm4Zz12t80=;
	b=AUj4ec+97GyucYoQk5NGMrfQ+BbA1fYInEAYTsaolfVSpVCEELFzwv3WqEZpCFNSH1
	4ze9JNH9cqYpLzRgdyo6g0A+aWbqJyM+gRPPWSfLGccx++xk2ErZuVGcsjndoUw4vf3d
	hK7TdJn+ahSOM30lciU/GS4MNMMzD5Le4v3yU=
Received: by 10.180.14.129 with SMTP id p1mr11724249wic.16.1328277653791;
	Fri, 03 Feb 2012 06:00:53 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id eq5sm17697948wib.2.2012.02.03.06.00.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 03 Feb 2012 06:00:50 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============6253512272991086591=="
MIME-Version: 1.0
X-Mercurial-Node: 837570e539a114f47d8a98b7a281481a81ac856f
Message-Id: <837570e539a114f47d8a.1326258829@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 11 Jan 2012 06:13:49 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 03 Feb 2012 21:30:32 +0000
Subject: [Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6253512272991086591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is still not used anywhere, and is automatically created by
autoheader, altough this migh change when we start to include this
file.

Just a first release, and since it's my first autoconf script I guess
there will be many things to polish here... Please review and comment.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |      6 +
 Config.mk                         |     30 -
 Makefile                          |      2 -
 README                            |      4 +
 autogen.sh                        |      9 +
 config/Tools.mk.in                |     50 +
 configure                         |      2 +
 tools/Makefile                    |      3 +-
 tools/Rules.mk                    |      7 +-
 tools/blktap/drivers/Makefile     |      2 +-
 tools/blktap/drivers/check_gcrypt |     14 -
 tools/check/Makefile              |     26 -
 tools/check/README                |     20 -
 tools/check/check_brctl           |     13 -
 tools/check/check_crypto_lib      |     11 -
 tools/check/check_curl            |     13 -
 tools/check/check_iproute         |     15 -
 tools/check/check_libaio_devel    |     11 -
 tools/check/check_libaio_lib      |      9 -
 tools/check/check_openssl_devel   |      6 -
 tools/check/check_python          |     13 -
 tools/check/check_python_devel    |     17 -
 tools/check/check_python_xml      |     12 -
 tools/check/check_udev            |     22 -
 tools/check/check_uuid_devel      |      7 -
 tools/check/check_x11_devel       |      9 -
 tools/check/check_xgettext        |      6 -
 tools/check/check_xml2            |     14 -
 tools/check/check_yajl_devel      |      8 -
 tools/check/check_yajl_lib        |      6 -
 tools/check/check_zlib_devel      |      6 -
 tools/check/check_zlib_lib        |     12 -
 tools/check/chk                   |     63 -
 tools/check/funcs.sh              |    106 -
 tools/config.guess                |   1522 +++++
 tools/config.h.in                 |    468 +
 tools/config.sub                  |   1771 ++++++
 tools/configure                   |  10204 ++++++++++++++++++++++++++++++++++++
 tools/configure.ac                |    191 +
 tools/debugger/gdbsx/xg/Makefile  |      1 -
 tools/install.sh                  |      1 +
 tools/libfsimage/Makefile         |      6 +-
 tools/libfsimage/check-libext2fs  |     21 -
 tools/libxen/Makefile             |      8 +-
 tools/m4/default_lib.m4           |      8 +
 tools/m4/disable_feature.m4       |     13 +
 tools/m4/enable_feature.m4        |     13 +
 tools/m4/ocaml.m4                 |    241 +
 tools/m4/path_or_fail.m4          |      6 +
 tools/m4/python_devel.m4          |     18 +
 tools/m4/python_version.m4        |     12 +
 tools/m4/python_xml.m4            |     10 +
 tools/m4/set_cflags_ldflags.m4    |     20 +
 tools/m4/udev.m4                  |     32 +
 tools/m4/uuid.m4                  |     10 +
 version.sh                        |      5 +
 56 files changed, 14633 insertions(+), 502 deletions(-)



--===============6253512272991086591==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MjU4NDI1IC0zNjAwCiMgTm9kZSBJRCA4Mzc1NzBlNTM5
YTExNGY0N2Q4YTk4YjdhMjgxNDgxYTgxYWM4NTZmCiMgUGFyZW50ICBlMjcyMmIyNGRjMDk2MmRl
MzcyMTUzMjBiMDVkMWJiN2M0YzQyODY0CmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdoZXJl
LCBhbmQgaXMgYXV0b21hdGljYWxseSBjcmVhdGVkIGJ5CmF1dG9oZWFkZXIsIGFsdG91Z2ggdGhp
cyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvIGluY2x1ZGUgdGhpcwpmaWxlLgoKSnVzdCBh
IGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJ
IGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjM6CgogKiBDb3BpZWQgY29uZmln
Lmd1ZXNzIGFuZCBjb25maWcuc3ViIGZyb20gYXV0b21ha2UgMS4xMS4KCiAqIEFkZGVkIGEgdGVz
dCB0byBjaGVjayBmb3IgdXVpZC5oIG9uIEJTRCBhbmQgdXVpZC91dWlkLmggb24gTGludXguCgpD
aGFuZ2VzIHNpbmNlIHYyOgoKICogQ2hhbmdlZCBvcmRlciBvZiBjb25maWcvVG9vbHMubWsgaW5j
bHVkZS4KCiAqIEFkZGVkICItZSIgdG8gYXV0b2dlbi5zaCBzaGViYW5nLgoKICogQWRkZWQgbmVj
ZXNzYXJ5IGZpbGVzIChjb25maWcuKikgYW5kIG91dHB1dCBmcm9tIEF1dG9oZWFkZXIgYW5kCiAg
IEF1dG9jb25mLgoKICogUmVtb3ZlZCBBdXRvY29uZiBmcm9tIGJ1aWxkIGRlcGVuZGVuY2llcyBh
bmQgdXBkYXRlZCBSRUFETUUuCgpDaGFuZ2VzIHNpbmNlIHYxOgoKICogTW92ZWQgYXV0b2NvbmYg
c3R1ZmYgaW5zaWRlIHRvb2xzIGZvbGRlci4KCiAqIEFkZCBNYWtlZmlsZSBydWxlcyBmb3IgY2xl
YW5pbmcuCgogKiBSZW1vdmVkIEF1dG9tYWtlIGRlcGVuZGVuY3kuCgogKiBDcmVhdGUgYXV0b2dl
bi5zaCB0byBhdXRvbWF0aWNhbGx5IGNyZWF0ZSBjb25maWd1cmUgc2NyaXB0IHdoZW4KICAgYnVp
bGRpbmcgZnJvbSBzb3VyY2UgcmVwb3NpdG9yeS4KCiAqIENhY2hlZCB2YWx1ZXMgb2Ygb3B0aW9u
cyBwYXNzZWQgZnJvbSBjb21tYW5kIGxpbmUuCgogKiBBZGQgbmVjZXNzYXJ5IGlnbm9yZXMgdG8g
LmhnaWdub3JlLgoKICogQWRkZWQgQXV0b2NvbmYgdG8gdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVz
LgoKICogQ2hhbmdlZCBoeXBlbiB0byB1bmRlcnNjb3JlIGluIFhNTDIgYW5kIENVUkwgdmFyaWFi
bGUgbmFtZXMuCgogKiBBZGRlZCBzY3JpcHQgdG8gZ2V0IHZlcnNpb24gZnJvbSB4ZW4vTWFrZWZp
bGUuCgogKiBTZXQgT2NhbWwgdG9vbHMgdG8gb3B0aW9uYWwuCgogKiBBZGRlZCBwcm9jZWRlbmNl
IG9mIG00L29jYW1sLm00LgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5w
YXVAZW50ZWwudXBjLmVkdT4KCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSAu
aGdpZ25vcmUKLS0tIGEvLmhnaWdub3JlCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAor
KysgYi8uaGdpZ25vcmUJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0zMTIsNiAr
MzEyLDEyIEBACiBedG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2Nh
bWwvbGlicy94bC94ZW5saWdodFwubWxpJAogXnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3Rv
cmVkJAorXnRvb2xzL2F1dG9tNHRlXC5jYWNoZSQKK150b29scy9jb25maWdcLmgkCitedG9vbHMv
Y29uZmlnXC5sb2ckCitedG9vbHMvY29uZmlnXC5zdGF0dXMkCitedG9vbHMvY29uZmlnXC5jYWNo
ZSQKK15jb25maWcvVG9vbHNcLm1rJAogXnhlbi9cLmJhbm5lci4qJAogXnhlbi9CTE9HJAogXnhl
bi9TeXN0ZW0ubWFwJApkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgQ29uZmln
Lm1rCi0tLSBhL0NvbmZpZy5tawlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIGIv
Q29uZmlnLm1rCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtNzAsOSArNzAsNiBA
QCBFWFRSQV9JTkNMVURFUyArPSAkKEVYVFJBX1BSRUZJWCkvaW5jbHVkCiBFWFRSQV9MSUIgKz0g
JChFWFRSQV9QUkVGSVgpLyQoTElCTEVBRkRJUikKIGVuZGlmCiAKLUJJU09OCT89IGJpc29uCi1G
TEVYCT89IGZsZXgKLQogUFlUSE9OICAgICAgPz0gcHl0aG9uCiBQWVRIT05fUFJFRklYX0FSRyA/
PSAtLXByZWZpeD0iJChQUkVGSVgpIgogIyBUaGUgYWJvdmUgcmVxdWlyZXMgdGhhdCBQUkVGSVgg
Y29udGFpbnMgKm5vIHNwYWNlcyouIFRoaXMgdmFyaWFibGUgaXMgaGVyZQpAQCAtMTc1LDkgKzE3
Miw2IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9M
REZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZM
QUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tf
TElCID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lO
Q0xVREVTID0gJChFWFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9J
TkNMVURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyAr
PSAtZm5vLWV4Y2VwdGlvbnMKIApAQCAtMTg2LDE2ICsxODAsNiBAQCBDT05GSUdfTElCSUNPTlYg
ICA6PSAkKHNoZWxsIGV4cG9ydCBPUz0iCiAgICAgICAgICAgICAgICAgICAgICAgIC4gJChYRU5f
Uk9PVCkvdG9vbHMvY2hlY2svZnVuY3Muc2g7IFwKICAgICAgICAgICAgICAgICAgICAgICAgaGFz
X2xpYiBsaWJpY29udi5zbyAmJiBlY2hvICd5JyB8fCBlY2hvICduJykKIAotIyBFbmFibGUgWFNN
IHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1G
TEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxFKQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0b3Jp
ZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHByb3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBm
YXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0j
IG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCBy
ZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9I
VFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4KLUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVT
X1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhl
IGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2VyZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9u
CiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmlnaW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVk
IGFzIGEgY29tbWVudApAQCAtMjI4LDE3ICsyMTIsMyBAQCBRRU1VX1RBRyA/PSBiYjM2ZDYzMmU0
Y2FiZjQ3ODgyYWRmZjA3YTQ1CiAKICMgU2hvcnQgYW5zd2VyIC0tIGRvIG5vdCBlbmFibGUgdGhp
cyB1bmxlc3MgeW91IGtub3cgd2hhdCB5b3UgYXJlCiAjIGRvaW5nIGFuZCBhcmUgcHJlcGFyZWQg
Zm9yIHNvbWUgcGFpbi4KLQotIyBPcHRpb25hbCBjb21wb25lbnRzCi1YRU5TVEFUX1hFTlRPUCAg
ICAgPz0geQotVlRQTV9UT09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQSV9CSU5ESU5HUyA/PSBu
Ci1QWVRIT05fVE9PTFMgICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAgICAgID89IHkKLUNPTkZJ
R19NSU5JVEVSTSAgICA/PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0gbgotQ09ORklHX1NZU1RF
TV9MSUJBSU8gPz0geQotCi1pZmVxICgkKE9DQU1MX1RPT0xTKSx5KQotT0NBTUxfVE9PTFMgOj0g
JChzaGVsbCBvY2FtbG9wdCAtdiA+IC9kZXYvbnVsbCAyPiYxICYmIGVjaG8gInkiIHx8IGVjaG8g
Im4iKQotZW5kaWYKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIE1ha2VmaWxl
Ci0tLSBhL01ha2VmaWxlCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgYi9NYWtl
ZmlsZQlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTQwLDExICs0MCw5IEBAIGRp
c3Q6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0OiBkaXN0LXhlbiBkaXN0LWtlcm5l
bHMgZGlzdC10b29scyBkaXN0LXN0dWJkb20gZGlzdC1kb2NzIGRpc3QtbWlzYwogCiBkaXN0LW1p
c2M6Ci0JJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawogCSQoSU5TVEFMTF9EQVRBKSAu
L0NPUFlJTkcgJChESVNURElSKQogCSQoSU5TVEFMTF9EQVRBKSAuL1JFQURNRSAkKERJU1RESVIp
CiAJJChJTlNUQUxMX1BST0cpIC4vaW5zdGFsbC5zaCAkKERJU1RESVIpCi0JJChJTlNUQUxMX1BS
T0cpIHRvb2xzL2NoZWNrL2NoayB0b29scy9jaGVjay9jaGVja18qIHRvb2xzL2NoZWNrL2Z1bmNz
LnNoICQoRElTVERJUikvY2hlY2sKIGRpc3QtJTogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwK
IGRpc3QtJTogaW5zdGFsbC0lCiAJQDogIyBkbyBub3RoaW5nCmRpZmYgLXIgZTI3MjJiMjRkYzA5
IC1yIDgzNzU3MGU1MzlhMSBSRUFETUUKLS0tIGEvUkVBRE1FCVRodSBKYW4gMjYgMTc6NDM6MzEg
MjAxMiArMDAwMAorKysgYi9SRUFETUUJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBA
IC04OSw5ICs4OSwxMyBAQCAyLiBjZCB0byB4ZW4tdW5zdGFibGUgKG9yIHdoYXRldmVyIHlvdSBz
CiAzLiBGb3IgdGhlIHZlcnkgZmlyc3QgYnVpbGQsIG9yIGlmIHlvdSB3YW50IHRvIGRlc3Ryb3kg
YnVpbGQgdHJlZXMsCiAgICBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgc3RlcHM6CiAKKyAgICAjIC4v
Y29uZmlndXJlCiAgICAgIyBtYWtlIHdvcmxkCiAgICAgIyBtYWtlIGluc3RhbGwKIAorICAgSWYg
eW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29uZmlndXJlIC0taGVscCB0byBzZWUgdGhlIGxpc3Qg
b2YKKyAgIG9wdGlvbnMgYXZhaWxhYmxlIG9wdGlvbnMgd2hlbiBidWlsZGluZyBhbmQgaW5zdGFs
bGluZyBYZW4uCisKICAgIFRoaXMgd2lsbCBjcmVhdGUgYW5kIGluc3RhbGwgb250byB0aGUgbG9j
YWwgbWFjaGluZS4gSXQgd2lsbCBidWlsZAogICAgdGhlIHhlbiBiaW5hcnkgKHhlbi5neiksIHRo
ZSB0b29scyBhbmQgdGhlIGRvY3VtZW50YXRpb24uCiAKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIg
ODM3NTcwZTUzOWExIGF1dG9nZW4uc2gKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIvYXV0b2dlbi5zaAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAx
MDAKQEAgLTAsMCArMSw5IEBACisjIS9iaW4vc2ggLWUKK3JtIC1yZiBjb25maWd1cmUKK2NkIHRv
b2xzCithdXRvaGVhZGVyCithdXRvY29uZgorY2QgLi4KK2VjaG8gIiMhL2Jpbi9zaCAtZSIgPj4g
Y29uZmlndXJlCitlY2hvICJjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSBcJEAiID4+IGNvbmZpZ3Vy
ZQorY2htb2QgK3ggY29uZmlndXJlCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1Mzlh
MSBjb25maWcvVG9vbHMubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvY29uZmlnL1Rvb2xzLm1rLmluCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAx
MiArMDEwMApAQCAtMCwwICsxLDUwIEBACisjIFByZWZpeCBhbmQgaW5zdGFsbCBmb2xkZXIKK1BS
RUZJWCAgICAgICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJfeDg2XzY0ICAgOj0gQExJ
Ql9QQVRIQAorCisjIEEgZGVidWcgYnVpbGQgb2YgdG9vbHM/CitkZWJ1ZyAgICAgICAgICAgICAg
IDo9IEBkZWJ1Z0AKKworIyBUb29scyBwYXRoCitCSVNPTiAgICAgICAgICAgICAgIDo9IEBCSVNP
TkAKK0ZMRVggICAgICAgICAgICAgICAgOj0gQEZMRVhACitQWVRIT04gICAgICAgICAgICAgIDo9
IEBQWVRIT05ACitQWVRIT05fUEFUSCAgICAgICAgIDo9IEBQWVRIT05QQVRIQAorUEVSTCAgICAg
ICAgICAgICAgICA6PSBAUEVSTEAKK0JSQ1RMICAgICAgICAgICAgICAgOj0gQEJSQ1RMQAorSVAg
ICAgICAgICAgICAgICAgICA6PSBASVBACitDVVJMX0NPTkZJRyAgICAgICAgIDo9IEBDVVJMQAor
WE1MMl9DT05GSUcgICAgICAgICA6PSBAWE1MQAorQkFTSCAgICAgICAgICAgICAgICA6PSBAQkFT
SEAKK1hHRVRUVEVYVCAgICAgICAgICAgOj0gQFhHRVRURVhUQAorCisjIEV4dHJhIGZvbGRlciBm
b3IgbGlicy9pbmNsdWRlcworUFJFUEVORF9JTkNMVURFUyAgICA6PSBAUFJFUEVORF9JTkNMVURF
U0AKK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElCQAorQVBQRU5EX0lOQ0xVREVT
ICAgICA6PSBAQVBQRU5EX0lOQ0xVREVTQAorQVBQRU5EX0xJQiAgICAgICAgICA6PSBAQVBQRU5E
X0xJQkAKKworIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2sp
LgorWFNNX0VOQUJMRSAgICAgICAgICA6PSBAeHNtQAorRkxBU0tfRU5BQkxFICAgICAgICA6PSBA
eHNtQAorCisjIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3du
IHByb3RvY29sPworIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3
aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCisjIG1heSBibG9jayBpdCkuIFdlIG1ha2Ug
aXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25sb2FkcworIyBm
YWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVu
dC4KK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBACisKKyMgT3B0aW9uYWwgY29tcG9u
ZW50cworWEVOU1RBVF9YRU5UT1AgICAgICA6PSBAbW9uaXRvcnNACitWVFBNX1RPT0xTICAgICAg
ICAgIDo9IEB2dHBtQAorTElCWEVOQVBJX0JJTkRJTkdTICA6PSBAeGFwaUAKK1BZVEhPTl9UT09M
UyAgICAgICAgOj0gQHB5dGhvbnRvb2xzQAorT0NBTUxfVE9PTFMgICAgICAgICA6PSBAb2NhbWx0
b29sc0AKK0NPTkZJR19NSU5JVEVSTSAgICAgOj0gQG1pbml0ZXJtQAorQ09ORklHX0xPTU9VTlQg
ICAgICA6PSBAbG9tb3VudEAKKworI1N5c3RlbSBvcHRpb25zCitDT05GSUdfU1lTVEVNX0xJQkFJ
Tzo9IEBzeXN0ZW1fYWlvQAorQ09ORklHX0xJQklDT05WICAgICA6PSBAbGliaWNvbnZACitDT05G
SUdfR0NSWVBUICAgICAgIDo9IEBsaWJnY3J5cHRACitDT05GSUdfRVhUMkZTICAgICAgIDo9IEBs
aWJleHQyZnNACmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSBjb25maWd1cmUK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvY29uZmln
dXJlCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDIgQEAKKyMhL2Jp
bi9zaCAtZQorY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgJEAKZGlmZiAtciBlMjcyMmIyNGRjMDkg
LXIgODM3NTcwZTUzOWExIHRvb2xzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL01ha2VmaWxlCVRodSBK
YW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgYi90b29scy9NYWtlZmlsZQlXZWQgSmFuIDEx
IDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTYsNyArNiw2IEBAIFNVQkRJUlMtbGliYWlvIDo9IGxp
YmFpbwogZW5kaWYKIAogU1VCRElSUy15IDo9Ci1TVUJESVJTLXkgKz0gY2hlY2sKIFNVQkRJUlMt
eSArPSBpbmNsdWRlCiBTVUJESVJTLXkgKz0gbGlieGMKIFNVQkRJUlMteSArPSBmbGFzawpAQCAt
NzgsNiArNzcsOCBAQCBjbGVhbjogc3ViZGlycy1jbGVhbgogZGlzdGNsZWFuOiBzdWJkaXJzLWRp
c3RjbGVhbgogCXJtIC1yZiBxZW11LXhlbi10cmFkaXRpb25hbC1kaXIgcWVtdS14ZW4tdHJhZGl0
aW9uYWwtZGlyLXJlbW90ZQogCXJtIC1yZiBxZW11LXhlbi1kaXIgcWVtdS14ZW4tZGlyLXJlbW90
ZQorCXJtIC1yZiAuLi9jb25maWcvVG9vbHMubWsgY29uZmlnLmggY29uZmlnLmxvZyBjb25maWcu
c3RhdHVzIFwKKwkJY29uZmlnLmNhY2hlIGF1dG9tNHRlLmNhY2hlCiAKIGlmbmVxICgkKFhFTl9D
T01QSUxFX0FSQ0gpLCQoWEVOX1RBUkdFVF9BUkNIKSkKIElPRU1VX0NPTkZJR1VSRV9DUk9TUyA/
PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXApkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1
NzBlNTM5YTEgdG9vbHMvUnVsZXMubWsKLS0tIGEvdG9vbHMvUnVsZXMubWsJVGh1IEphbiAyNiAx
Nzo0MzozMSAyMDEyICswMDAwCisrKyBiL3Rvb2xzL1J1bGVzLm1rCVdlZCBKYW4gMTEgMDY6MDc6
MDUgMjAxMiArMDEwMApAQCAtNCw2ICs0LDcgQEAKIGFsbDoKIAogaW5jbHVkZSAkKFhFTl9ST09U
KS9Db25maWcubWsKK2luY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1rCiAKIGV4cG9y
dCBfSU5TVEFMTCA6PSAkKElOU1RBTEwpCiBJTlNUQUxMID0gJChYRU5fUk9PVCkvdG9vbHMvY3Jv
c3MtaW5zdGFsbApAQCAtODAsOCArODEsNiBAQCBjaGVjay0kKENPTkZJR19YODYpID0gJChjYWxs
IGNjLXZlci1jaGVjCiAgICAgICAgICAgICAgICAgICAgICAgICAiWGVuIHJlcXVpcmVzIGF0IGxl
YXN0IGdjYy0zLjQiKQogJChldmFsICQoY2hlY2steSkpCiAKLV9QWVRIT05fUEFUSCA6PSAkKHNo
ZWxsIHdoaWNoICQoUFlUSE9OKSkKLVBZVEhPTl9QQVRIID89ICQoX1BZVEhPTl9QQVRIKQogSU5T
VEFMTF9QWVRIT05fUFJPRyA9IFwKIAkkKFhFTl9ST09UKS90b29scy9weXRob24vaW5zdGFsbC13
cmFwICIkKFBZVEhPTl9QQVRIKSIgJChJTlNUQUxMX1BST0cpCiAKQEAgLTEwOSwzICsxMDgsNyBA
QCBzdWJkaXItYWxsLSUgc3ViZGlyLWNsZWFuLSUgc3ViZGlyLWluc3RhCiAKIHN1YmRpci1kaXN0
Y2xlYW4tJTogLnBob255CiAJJChNQUtFKSAtQyAkKiBjbGVhbgorCiskKFhFTl9ST09UKS9jb25m
aWcvVG9vbHMubWs6CisJQGVjaG8gIllvdSBoYXZlIHRvIHJ1biAuL2NvbmZpZ3VyZSBiZWZvcmUg
YnVpbGRpbmcgb3IgaW5zdGFsbGluZyB0aGUgdG9vbHMiCisJQGV4aXQgMQpkaWZmIC1yIGUyNzIy
YjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUKLS0t
IGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEy
ICswMDAwCisrKyBiL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVdlZCBKYW4gMTEgMDY6
MDc6MDUgMjAxMiArMDEwMApAQCAtMTMsNyArMTMsNyBAQCBDRkxBR1MgICArPSAkKENGTEFHU19s
aWJ4ZW5zdG9yZSkKIENGTEFHUyAgICs9IC1JICQoTUVNU0hSX0RJUikKIENGTEFHUyAgICs9IC1E
X0dOVV9TT1VSQ0UKIAotaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0ICQoQ0MpKSx5ZXMp
CitpZmVxICgkQ09ORklHX0dDUllQVCx5KQogQ0ZMQUdTICs9IC1EVVNFX0dDUllQVAogQ1JZUFRf
TElCIDo9IC1sZ2NyeXB0CiBlbHNlCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1Mzlh
MSB0b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQKLS0tIGEvdG9vbHMvYmxrdGFwL2Ry
aXZlcnMvY2hlY2tfZ2NyeXB0CVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCArMCwwIEBACi0j
IS9iaW4vc2gKLQotY2F0ID4gLmdjcnlwdC5jIDw8IEVPRgotI2luY2x1ZGUgPGdjcnlwdC5oPgot
aW50IG1haW4odm9pZCkgeyByZXR1cm4gMDsgfQotRU9GCi0KLWlmICQxIC1vIC5nY3J5cHQgLmdj
cnlwdC5jIC1sZ2NyeXB0IDI+L2Rldi9udWxsIDsgdGhlbgotICBlY2hvICJ5ZXMiCi1lbHNlCi0g
IGVjaG8gIm5vIgotZmkKLQotcm0gLWYgLmdjcnlwdCoKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIg
ODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2NoZWNrL01ha2Vm
aWxlCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyNiArMCwwIEBACi1YRU5fUk9PVCA9ICQoQ1VS
RElSKS8uLi8uLgotaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawotCi0jIEV4cG9y
dCB0aGUgbmVjZXNzYXJ5IGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgdGhlIHRlc3RzCi1leHBv
cnQgUFlUSE9OCi1leHBvcnQgTElCWEVOQVBJX0JJTkRJTkdTCi1leHBvcnQgQ0hFQ0tfSU5DTFVE
RVMKLWV4cG9ydCBDSEVDS19MSUIKLWV4cG9ydCBDT05GSUdfU1lTVEVNX0xJQkFJTwotCi0uUEhP
Tlk6IGFsbCBpbnN0YWxsCi1hbGwgaW5zdGFsbDogY2hlY2stYnVpbGQKLQotIyBDaGVjayB0aGlz
IG1hY2hpbmUgaXMgT0sgZm9yIGJ1aWxkaW5nIG9uLgotLlBIT05ZOiBjaGVjay1idWlsZAotY2hl
Y2stYnVpbGQ6Ci0JLi9jaGsgYnVpbGQKLQotIyBDaGVjayB0aGlzIG1hY2hpbmUgaXMgT0sgZm9y
IGluc3RhbGxpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWluc3RhbGwKLWNoZWNrLWluc3RhbGw6Ci0J
Li9jaGsgaW5zdGFsbAotCi0uUEhPTlk6IGNsZWFuCi1jbGVhbjoKLQkuL2NoayBjbGVhbgpkaWZm
IC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svUkVBRE1FCi0tLSBh
L3Rvb2xzL2NoZWNrL1JFQURNRQlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjAgKzAsMCBAQAot
Q2hlY2tzIGZvciB0aGUgc3VpdGFiaWxpdHkgb2YgYSBtYWNoaW5lIGZvciBYZW4gYnVpbGQgb3Ig
aW5zdGFsbC4KLVRvIGNoZWNrIGZvciBidWlsZCBzdWl0YWJpbGl0eSB1c2UKLQotICAgICAgICAu
L2NoayBidWlsZAotCi1UbyBjaGVjayBmb3IgaW5zdGFsbCBzdWl0YWJpbGl0eSB1c2UKLQotICAg
ICAgICAuL2NoayBpbnN0YWxsCi0KLVRoZSBjaGsgc2NyaXB0IHdpbGwgcnVuIGNoZWNrcyBpbiB0
aGlzIGRpcmVjdG9yeSBhbmQgcHJpbnQKLXRoZSBvbmVzIHRoYXQgZmFpbGVkLiBJdCBwcmludHMg
bm90aGluZyBpZiBjaGVja3Mgc3VjY2VlZC4KLVRoZSBjaGsgc2NyaXB0IGV4aXRzIHdpdGggMCBv
biBzdWNjZXNzIGFuZCAxIG9uIGZhaWx1cmUuCi0KLVRoZSBjaGsgc2NyaXB0IHJ1bnMgZXhlY3V0
YWJsZSBmaWxlcyBpbiB0aGlzIGRpcmVjdG9yeSB3aG9zZQotbmFtZXMgYmVnaW4gd2l0aCAnY2hl
Y2tfJy4gRmlsZXMgY29udGFpbmluZyBDSEVDSy1CVUlMRAotYXJlIHJ1biBmb3IgdGhlIGJ1aWxk
IGNoZWNrLCBhbmQgZmlsZXMgY29udGFpbmluZyBDSEVDSy1JTlNUQUxMCi1hcmUgcnVuIGZvciB0
aGUgaW5zdGFsbCBjaGVjay4KLQotRGV0YWlsZWQgb3V0cHV0IGZyb20gdGhlIGNoZWNrIHNjcmlw
dHMgaXMgaW4gLmNoa2J1aWxkIGZvciBidWlsZAotYW5kIC5jaGtpbnN0YWxsIGZvciBpbnN0YWxs
LgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3
NTcwZTUzOWExIHRvb2xzL2NoZWNrL2NoZWNrX2JyY3RsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X2JyY3RsCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0
QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgYnJjb25maWcgOzsKLUxpbnV4KQotCWhhc19vcl9m
YWlsIGJyY3RsIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2FjCmRpZmYgLXIgZTI3
MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja19jcnlwdG9fbGliCi0t
LSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4g
Li9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRCU0R8T3BlbkJTRCkKLQlleGl0
IDAgOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJjcnlwdG8uc28gfHwgZmFpbCAibWlzc2luZyBsaWJj
cnlwdG8uc28iCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVj
ay9jaGVja19jdXJsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2N1cmwJVGh1IEphbiAyNiAxNzo0
MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNU
QUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICIkTElCWEVOQVBJX0JJTkRJTkdTIiAhPSAieSIg
XTsgdGhlbgotCWVjaG8gLW4gInVudXNlZCwgIgotCWV4aXQgMAotZmkKLQotaGFzX29yX2ZhaWwg
Y3VybC1jb25maWcKLWN1cmxfbGlicz1gY3VybC1jb25maWcgLS1saWJzYCB8fCBmYWlsICJjdXJs
LWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICRjdXJsX2xpYnMgfHwgZmFpbCAiZGVw
ZW5kZW5jeSBsaWJyYXJpZXMgZm9yIGN1cmwgYXJlIG1pc3NpbmciCmRpZmYgLXIgZTI3MjJiMjRk
YzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja19pcHJvdXRlCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX2lwcm91dGUJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE1ICswLDAgQEAK
LSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1QQVRIPS9zYmlu
OiRQQVRICi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9m
YWlsIGlmY29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBpcCA7OwotKikKLQlmYWlsICJ1
bmtub3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEg
dG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2xp
YmFpb19kZXZlbAlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19TWVNURU1f
TElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaWYgISBoYXNfaGVhZGVy
IGxpYmFpby5oIDsgdGhlbgotICAgIGZhaWwgImNhbid0IGZpbmQgbGliYWlvIGhlYWRlcnMsIGlu
c3RhbGwgbGliYWlvIGRldmVsIHBhY2thZ2Ugb3Igc2V0IENPTkZJR19TWVNURU1fTElCQUlPPW4i
Ci1maQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svY2hl
Y2tfbGliYWlvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9fbGliCVRodSBKYW4g
MjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVD
Sy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19TWVNURU1fTElCQUlP
fSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaGFzX2xpYiBsaWJhaW8uc28gfHwg
ZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8iCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1
MzlhMSB0b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX29wZW5zc2xfZGV2ZWwJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIG9wZW5z
c2wvbWQ1LmggfHwgZmFpbCAibWlzc2luZyBvcGVuc3NsIGhlYWRlcnMiCmRpZmYgLXIgZTI3MjJi
MjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja19weXRob24KLS0tIGEvdG9v
bHMvY2hlY2svY2hlY2tfcHl0aG9uCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gK
LQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLQotJHtQ
WVRIT059IC1jICcKLWltcG9ydCBzeXMKLXN5cy5leGl0KHN5cy52ZXJzaW9uX2luZm9bMF0gPCAy
IG9yIHN5cy52ZXJzaW9uX2luZm9bMV0gPCAzKQotJyB8fCBmYWlsICJuZWVkIHB5dGhvbiB2ZXJz
aW9uID49IDIuMyIKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2No
ZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja19weXRob25fZGV2
ZWwJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE3ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAg
UFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0ke1BZVEhPTn0gLWMg
JwotaW1wb3J0IG9zLnBhdGgsIHN5cwotZm9yIHAgaW4gc3lzLnBhdGg6Ci0JaWYgb3MucGF0aC5l
eGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6Ci0JCXN5cy5leGl0KDApCi1zeXMuZXhpdCgx
KQotJyB8fCBmYWlsICJjYW4ndCBmaW5kIHB5dGhvbiBkZXZlbCBmaWxlcyIKZGlmZiAtciBlMjcy
MmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94bWwKLS0t
IGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0K
LWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3Jf
ZmFpbCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJyAy
Pi9kZXYvbnVsbCB8fCBcCi1mYWlsICJjYW4ndCBpbXBvcnQgeG1sLmRvbS5taW5pZG9tIgpkaWZm
IC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svY2hlY2tfdWRldgot
LS0gYS90b29scy9jaGVjay9jaGVja191ZGV2CVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAw
MAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMiAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2Fz
ZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgdm5jb25maWcK
LQk7OwotTGludXgpCi0JaGFzIC9zYmluL3VkZXZhZG0gJiYgXAotCQl1ZGV2dmVyPWAvc2Jpbi91
ZGV2YWRtIGluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbIC16ICIkdWRldnZlciIgXSAm
JiBoYXNfb3JfZmFpbCB1ZGV2aW5mbyAmJiBcCi0JCXVkZXZ2ZXI9YHVkZXZpbmZvIC1WIHwgYXdr
ICd7cHJpbnQgJE5GfSdgCi0JWyAiJHVkZXZ2ZXIiIC1nZSA1OSBdIDI+L2Rldi9udWxsIHx8IFwK
LQkJaGFzIGhvdHBsdWcgfHwgXAotCQlmYWlsICJ1ZGV2IGlzIHRvbyBvbGQsIHVwZ3JhZGUgdG8g
dmVyc2lvbiA1OSBvciBsYXRlciIKLQk7OwotKikKLQlmYWlsICJ1bmtub3duIE9TIgotCTs7Ci1l
c2FjCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVj
a191dWlkX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwJVGh1IEphbiAy
NiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4g
Li9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHV1aWQuaCB8fCBcCi1oYXNfaGVhZGVyIHV1aWQvdXVp
ZC5oIHx8IGZhaWwgIm1pc3NpbmcgdXVpZCBoZWFkZXJzIChwYWNrYWdlIHV1aWQtZGV2KSIKZGlm
ZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL2NoZWNrX3gxMV9k
ZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwJVGh1IEphbiAyNiAxNzo0Mzoz
MSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5z
aAotCi1oYXNfaGVhZGVyIFgxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDEx
UjYvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAotaGFzX2hlYWRlciAvdXNyL1gxMVI3L2lu
Y2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLXdhcm5pbmcgImNhbid0IGZpbmQgWDExIGhlYWRl
cnMiCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVj
a194Z2V0dGV4dAotLS0gYS90b29scy9jaGVjay9jaGVja194Z2V0dGV4dAlUaHUgSmFuIDI2IDE3
OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1
bmNzLnNoCi0KLWhhc19vcl9mYWlsIHhnZXR0ZXh0CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgz
NzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja194bWwyCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3htbDIJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBD
SEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICEgIiRMSUJY
RU5BUElfQklORElOR1MiID0gInkiIF0KLXRoZW4KLSAgICBlY2hvIC1uICJ1bnVzZWQsICIKLSAg
ICBleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIHhtbDItY29uZmlnCi14bWwyX2xpYnM9YHhtbDIt
Y29uZmlnIC0tbGlic2AgfHwgZmFpbCAieG1sMi1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3Rf
bGluayAkeG1sMl9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciB4bWwyIGFy
ZSBtaXNzaW5nIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hl
Y2svY2hlY2tfeWFqbF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja195YWpsX2RldmVsCVRo
dSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMApAQCAtMSw4ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlM
RAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB5YWpsL3lhamxfcGFyc2UuaCB8fCBmYWls
ICJjYW4ndCBmaW5kIHlhamwveWFqbF9wYXJzZS5oIgotaGFzX2hlYWRlciB5YWpsL3lhamxfZ2Vu
LmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfZ2VuLmgiCi1oYXNfbGliIGxpYnlhamwu
c28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJ5YWpsLnNvIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAt
ciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfeWFqbF9saWIJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWhh
c19saWIgbGlieWFqbC5zby4xIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5zby4xIHZlcnNp
b24gMSIKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL2No
ZWNrX3psaWJfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9kZXZlbAlUaHUgSmFu
IDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQot
LiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgemxpYi5oIHx8IGZhaWwgImNhbid0IGZpbmQgemxp
YiBoZWFkZXJzIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hl
Y2svY2hlY2tfemxpYl9saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9saWIJVGh1IEph
biAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBD
SEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRC
U0R8T3BlbkJTRCkKLQlleGl0IDAKLQk7OwotZXNhYwotCi1oYXNfbGliIGxpYnouc28gfHwgZmFp
bCAiY2FuJ3QgZmluZCB6bGliIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEg
dG9vbHMvY2hlY2svY2hrCi0tLSBhL3Rvb2xzL2NoZWNrL2NoawlUaHUgSmFuIDI2IDE3OjQzOjMx
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsNjMgKzAsMCBAQAotIyEvYmluL3NoCi0KLWZ1bmNfdXNhZ2UgKCkKLXsKLSAgICBlY2hv
ICJVc2FnZToiCi0gICAgZWNobyAiCSQwIFtidWlsZHxpbnN0YWxsfGNsZWFuXSIKLSAgICBlY2hv
Ci0gICAgZWNobyAiQ2hlY2sgc3VpdGFiaWxpdHkgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLiIK
LSAgICBlY2hvICJFeGl0IHdpdGggMCBpZiBPSywgMSBpZiBub3QuIgotICAgIGVjaG8KLSAgICBl
Y2hvICJDYWxsaW5nIHdpdGggJ2NsZWFuJyByZW1vdmVzIGdlbmVyYXRlZCBmaWxlcy4iCi0gICAg
ZXhpdCAxCi19Ci0KLVBBVEg9JFBBVEg6L3NiaW46L3Vzci9zYmluCi1PUz1gdW5hbWUgLXNgCi1l
eHBvcnQgUEFUSCBPUwotCi1pZiBbICIkT1MiID0gIlN1bk9TIiBdOyB0aGVuCi0JZXhpdCAwCi1m
aQotCi1jYXNlICQxIGluCi0gICAgYnVpbGQpCi0gICAgICAgIGNoZWNrPSJDSEVDSy1CVUlMRCIK
LSAgICAgICAgOzsKLSAgICBpbnN0YWxsKQotICAgICAgICBjaGVjaz0iQ0hFQ0stSU5TVEFMTCIK
LSAgICAgICAgOzsKLSAgICBjbGVhbikKLSAgICAgICAgZXhpdCAwCi0gICAgICAgIDs7Ci0gICAg
KikKLSAgICAgICAgZnVuY191c2FnZQotICAgICAgICA7OwotZXNhYwotCi1mYWlsZWQ9MAotCi1l
Y2hvICJYZW4gJHtjaGVja30gIiBgZGF0ZWAKLWZvciBmIGluIGNoZWNrXyogOyBkbwotICAgIGNh
c2UgJGYgaW4KLSAgICAgICAgKn4pCi0gICAgICAgICAgICBjb250aW51ZQotICAgICAgICAgICAg
OzsKLSAgICAgICAgKikKLSAgICAgICAgICAgIDs7Ci0gICAgZXNhYwotICAgIGlmICEgWyAteCAk
ZiBdIDsgdGhlbgotICAgICAgICBjb250aW51ZQotICAgIGZpCi0gICAgaWYgISBncmVwIC1GcSAi
JGNoZWNrIiAkZiA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAgIGVjaG8gLW4g
IkNoZWNraW5nICRmOiAiCi0gICAgaWYgLi8kZiAyPiYxIDsgdGhlbgotICAgICAgICBlY2hvIE9L
Ci0gICAgZWxzZQotICAgICAgICBmYWlsZWQ9MQotICAgIGZpCi1kb25lCi0KLWV4aXQgJHtmYWls
ZWR9CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9mdW5j
cy5zaAotLS0gYS90b29scy9jaGVjay9mdW5jcy5zaAlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTA2ICswLDAgQEAKLSMgaGFzIGlzIHRoZSBzYW1lIGFzIHdoaWNoLCBleGNlcHQgaXQgaGFuZGxl
cyBjcm9zcyBlbnZpcm9ubWVudHMKLWhhcygpIHsKLQlpZiBbIC16ICIkQ1JPU1NfQ09NUElMRSIg
XTsgdGhlbgotCQljb21tYW5kIHdoaWNoICIkQCIKLQkJcmV0dXJuICQ/Ci0JZmkKLQotCWNoZWNr
X3N5c19yb290IHx8IHJldHVybiAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQgcG9sbHV0aW9u
IG9mIGNhbGxlcidzIElGUwotCSgKLQlJRlM9OgotCWZvciBwIGluICRQQVRIOyBkbwotCQlpZiBb
IC14ICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiIF07IHRoZW4KLQkJCWVjaG8gIiRDUk9TU19TWVNf
Uk9PVC8kcC8kMSIKLQkJCXJldHVybiAwCi0JCWZpCi0JZG9uZQotCXJldHVybiAxCi0JKQotfQot
Ci1oYXNfb3JfZmFpbCgpIHsKLQloYXMgIiQxIiA+L2Rldi9udWxsIHx8IGZhaWwgImNhbid0IGZp
bmQgJDEiCi19Ci0KLWhhc19oZWFkZXIoKSB7Ci0JY2hlY2tfc3lzX3Jvb3QgfHwgcmV0dXJuIDEK
LQotCWNhc2UgJDEgaW4KLQkJLyopIDs7Ci0JCSopCi0JCWlmIFsgLXIgIiRDUk9TU19TWVNfUk9P
VC91c3IvaW5jbHVkZS8kMSIgXTsgdGhlbgotCQkJcmV0dXJuIDAKLQkJZmkKLQkJZm9yIHBhdGgg
aW4gJHtDSEVDS19JTkNMVURFU307IGRvCi0JCQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JPT1Qke3Bh
dGh9LyQxIiBdOyB0aGVuCi0JCQkJcmV0dXJuIDAKLQkJCWZpCi0JCWRvbmUKLQkJOzsKLQllc2Fj
Ci0KLQlyZXR1cm4gMQotfQotCi1oYXNfbGliKCkgewotCWNoZWNrX3N5c19yb290IHx8IHJldHVy
biAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQgcG9sbHV0aW9uIG9mIGNhbGxlcidzIGVudmly
b25tZW50Ci0JKAotCVBBVEg9L3NiaW46JFBBVEggICAgICAgICMgZm9yIGxkY29uZmlnCi0JTElC
UkFSSUVTPSIkQ0hFQ0tfTElCIC91c3IvbGliIgotCi0JIyBUaGlzIHJlbGF0aXZlbHkgY29tbW9u
IGluIGEgc3lzLXJvb3Q7IGxpYnMgYXJlIGluc3RhbGxlZCBidXQKLQkjIGxkY29uZmlnIGhhc24n
dCBydW4gdGhlcmUsIHNvIGxkY29uZmlnIC1wIHdvbid0IHdvcmsuCi0JaWYgWyAiJE9TIiA9IExp
bnV4IC1hICEgLWYgIiRDUk9TU19TWVNfUk9PVC9ldGMvbGQuc28uY2FjaGUiIF07IHRoZW4KLQkg
ICAgZWNobyAiUGxlYXNlIHJ1biBsZGNvbmZpZyAtciBcIiRDUk9TU19TWVNfUk9PVFwiIHRvIGdl
bmVyYXRlIGxkLnNvLmNhY2hlIgotCSAgICAjIGZhbGwgdGhyb3VnaDsgbGRjb25maWcgdGVzdCBi
ZWxvdyBzaG91bGQgZmFpbAotCWZpCi0JaWYgWyAiJHtPU30iID0gIkxpbnV4IiBdOyB0aGVuCi0J
CWxkY29uZmlnIC1wICR7Q1JPU1NfU1lTX1JPT1QrLXIgIiRDUk9TU19TWVNfUk9PVCJ9IHwgZ3Jl
cCAtRnEgIiQxIgotCQlyZXR1cm4gJD8KLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJOZXRCU0QiIF07
IHRoZW4KLQkJbHMgLTEgJHtMSUJSQVJJRVN9IHwgZ3JlcCAtRnEgIiQxIgotCQlyZXR1cm4gJD8K
LQlmaQotCXJldHVybiAxCi0JKQotfQotCi10ZXN0X2xpbmsoKSB7Ci0JIyBzdWJzaGVsbCB0byB0
cmFwIHJlbW92YWwgb2YgdG1wZmlsZQotCSgKLQl1bnNldCB0bXBmaWxlCi0JdHJhcCAncm0gLWYg
IiR0bXBmaWxlIjsgZXhpdCcgMCAxIDIgMTUKLQl0bXBmaWxlPWBta3RlbXBgIHx8IHJldHVybiAx
Ci0JbGQgIiRAIiAtbyAiJHRtcGZpbGUiID4vZGV2L251bGwgMj4mMQotCXJldHVybiAkPwotCSkK
LX0KLQotIyB0aGlzIGZ1bmN0aW9uIGlzIHVzZWQgY29tbW9ubHkgYWJvdmUKLWNoZWNrX3N5c19y
b290KCkgewotCVsgLXogIiRDUk9TU19DT01QSUxFIiBdICYmIHJldHVybiAwCi0JaWYgWyAteiAi
JENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gInBsZWFzZSBzZXQgQ1JPU1NfU1lTX1JP
T1QgaW4gdGhlIGVudmlyb25tZW50IgotCQlyZXR1cm4gMQotCWZpCi0JaWYgWyAhIC1kICIkQ1JP
U1NfU1lTX1JPT1QiIF07IHRoZW4KLQkJZWNobyAibm8gc3lzLXJvb3QgZm91bmQgYXQgJENST1NT
X1NZU19ST09UIgotCQlyZXR1cm4gMQotCWZpCi19Ci0KLXdhcm5pbmcoKSB7Ci0JZWNobwotCWVj
aG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLX0KLQotZmFpbCgpIHsK
LQllY2hvCi0JZWNobyAiICoqKiBgYmFzZW5hbWUgIiQwImAgRkFJTEVEJHsqKzogJCp9IgotCWV4
aXQgMQotfQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY29uZmln
Lmd1ZXNzCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL2NvbmZpZy5ndWVzcwlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAs
MCArMSwxNTIyIEBACisjISAvYmluL3NoCisjIEF0dGVtcHQgdG8gZ3Vlc3MgYSBjYW5vbmljYWwg
c3lzdGVtIG5hbWUuCisjICAgQ29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAx
OTk2LCAxOTk3LCAxOTk4LCAxOTk5LAorIyAgIDIwMDAsIDIwMDEsIDIwMDIsIDIwMDMsIDIwMDQs
IDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDksIDIwMTAsCisjICAgMjAxMSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24sIEluYy4KKwordGltZXN0YW1wPScyMDExLTExLTExJworCisjIFRoaXMg
ZmlsZSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5IGl0CisjIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgYXMgcHVibGlzaGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhl
ciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxh
dGVyIHZlcnNpb24uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9w
ZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp
dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25n
IHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisj
IEZvdW5kYXRpb24sIEluYy4sIDUxIEZyYW5rbGluIFN0cmVldCAtIEZpZnRoIEZsb29yLCBCb3N0
b24sIE1BCisjIDAyMTEwLTEzMDEsIFVTQS4KKyMKKyMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0
byB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGlmIHlvdQorIyBkaXN0cmlidXRlIHRo
aXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSB0aGF0IGNvbnRhaW5zIGEKKyMgY29uZmlndXJh
dGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5k
ZXIKKyMgdGhlIHNhbWUgZGlzdHJpYnV0aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJl
c3Qgb2YgdGhhdCBwcm9ncmFtLgorCisKKyMgT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3Ro
bmVyLiAgUGxlYXNlIHNlbmQgcGF0Y2hlcyAoY29udGV4dAorIyBkaWZmIGZvcm1hdCkgdG8gPGNv
bmZpZy1wYXRjaGVzQGdudS5vcmc+IGFuZCBpbmNsdWRlIGEgQ2hhbmdlTG9nCisjIGVudHJ5Lgor
IworIyBUaGlzIHNjcmlwdCBhdHRlbXB0cyB0byBndWVzcyBhIGNhbm9uaWNhbCBzeXN0ZW0gbmFt
ZSBzaW1pbGFyIHRvCisjIGNvbmZpZy5zdWIuICBJZiBpdCBzdWNjZWVkcywgaXQgcHJpbnRzIHRo
ZSBzeXN0ZW0gbmFtZSBvbiBzdGRvdXQsIGFuZAorIyBleGl0cyB3aXRoIDAuICBPdGhlcndpc2Us
IGl0IGV4aXRzIHdpdGggMS4KKyMKKyMgWW91IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9m
IHRoaXMgc2NyaXB0IGZyb206CisjIGh0dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIv
P3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47Zj1jb25maWcuZ3Vlc3M7aGI9SEVBRAorCittZT1g
ZWNobyAiJDAiIHwgc2VkIC1lICdzLC4qLywsJ2AKKwordXNhZ2U9IlwKK1VzYWdlOiAkMCBbT1BU
SU9OXQorCitPdXRwdXQgdGhlIGNvbmZpZ3VyYXRpb24gbmFtZSBvZiB0aGUgc3lzdGVtIFxgJG1l
JyBpcyBydW4gb24uCisKK09wZXJhdGlvbiBtb2RlczoKKyAgLWgsIC0taGVscCAgICAgICAgIHBy
aW50IHRoaXMgaGVscCwgdGhlbiBleGl0CisgIC10LCAtLXRpbWUtc3RhbXAgICBwcmludCBkYXRl
IG9mIGxhc3QgbW9kaWZpY2F0aW9uLCB0aGVuIGV4aXQKKyAgLXYsIC0tdmVyc2lvbiAgICAgIHBy
aW50IHZlcnNpb24gbnVtYmVyLCB0aGVuIGV4aXQKKworUmVwb3J0IGJ1Z3MgYW5kIHBhdGNoZXMg
dG8gPGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+LiIKKwordmVyc2lvbj0iXAorR05VIGNvbmZpZy5n
dWVzcyAoJHRpbWVzdGFtcCkKKworT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3RobmVyLgor
Q29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAx
OTk5LCAyMDAwLAorMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAw
OCwgMjAwOSwgMjAxMCwgMjAxMSBGcmVlCitTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1Ro
aXMgaXMgZnJlZSBzb2Z0d2FyZTsgc2VlIHRoZSBzb3VyY2UgZm9yIGNvcHlpbmcgY29uZGl0aW9u
cy4gIFRoZXJlIGlzIE5PCit3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBv
ciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iCisKK2hlbHA9IgorVHJ5IFxgJG1l
IC0taGVscCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIgorCisjIFBhcnNlIGNvbW1hbmQgbGluZQor
d2hpbGUgdGVzdCAkIyAtZ3QgMCA7IGRvCisgIGNhc2UgJDEgaW4KKyAgICAtLXRpbWUtc3RhbXAg
fCAtLXRpbWUqIHwgLXQgKQorICAgICAgIGVjaG8gIiR0aW1lc3RhbXAiIDsgZXhpdCA7OworICAg
IC0tdmVyc2lvbiB8IC12ICkKKyAgICAgICBlY2hvICIkdmVyc2lvbiIgOyBleGl0IDs7CisgICAg
LS1oZWxwIHwgLS1oKiB8IC1oICkKKyAgICAgICBlY2hvICIkdXNhZ2UiOyBleGl0IDs7CisgICAg
LS0gKSAgICAgIyBTdG9wIG9wdGlvbiBwcm9jZXNzaW5nCisgICAgICAgc2hpZnQ7IGJyZWFrIDs7
CisgICAgLSApCSMgVXNlIHN0ZGluIGFzIGlucHV0LgorICAgICAgIGJyZWFrIDs7CisgICAgLSog
KQorICAgICAgIGVjaG8gIiRtZTogaW52YWxpZCBvcHRpb24gJDEkaGVscCIgPiYyCisgICAgICAg
ZXhpdCAxIDs7CisgICAgKiApCisgICAgICAgYnJlYWsgOzsKKyAgZXNhYworZG9uZQorCitpZiB0
ZXN0ICQjICE9IDA7IHRoZW4KKyAgZWNobyAiJG1lOiB0b28gbWFueSBhcmd1bWVudHMkaGVscCIg
PiYyCisgIGV4aXQgMQorZmkKKwordHJhcCAnZXhpdCAxJyAxIDIgMTUKKworIyBDQ19GT1JfQlVJ
TEQgLS0gY29tcGlsZXIgdXNlZCBieSB0aGlzIHNjcmlwdC4gTm90ZSB0aGF0IHRoZSB1c2Ugb2Yg
YQorIyBjb21waWxlciB0byBhaWQgaW4gc3lzdGVtIGRldGVjdGlvbiBpcyBkaXNjb3VyYWdlZCBh
cyBpdCByZXF1aXJlcworIyB0ZW1wb3JhcnkgZmlsZXMgdG8gYmUgY3JlYXRlZCBhbmQsIGFzIHlv
dSBjYW4gc2VlIGJlbG93LCBpdCBpcyBhCisjIGhlYWRhY2hlIHRvIGRlYWwgd2l0aCBpbiBhIHBv
cnRhYmxlIGZhc2hpb24uCisKKyMgSGlzdG9yaWNhbGx5LCBgQ0NfRk9SX0JVSUxEJyB1c2VkIHRv
IGJlIG5hbWVkIGBIT1NUX0NDJy4gV2Ugc3RpbGwKKyMgdXNlIGBIT1NUX0NDJyBpZiBkZWZpbmVk
LCBidXQgaXQgaXMgZGVwcmVjYXRlZC4KKworIyBQb3J0YWJsZSB0bXAgZGlyZWN0b3J5IGNyZWF0
aW9uIGluc3BpcmVkIGJ5IHRoZSBBdXRvY29uZiB0ZWFtLgorCitzZXRfY2NfZm9yX2J1aWxkPScK
K3RyYXAgImV4aXRjb2RlPVwkPzsgKHJtIC1mIFwkdG1wZmlsZXMgMj4vZGV2L251bGw7IHJtZGly
IFwkdG1wIDI+L2Rldi9udWxsKSAmJiBleGl0IFwkZXhpdGNvZGUiIDAgOwordHJhcCAicm0gLWYg
XCR0bXBmaWxlcyAyPi9kZXYvbnVsbDsgcm1kaXIgXCR0bXAgMj4vZGV2L251bGw7IGV4aXQgMSIg
MSAyIDEzIDE1IDsKKzogJHtUTVBESVI9L3RtcH0gOworIHsgdG1wPWAodW1hc2sgMDc3ICYmIG1r
dGVtcCAtZCAiJFRNUERJUi9jZ1hYWFhYWCIpIDI+L2Rldi9udWxsYCAmJiB0ZXN0IC1uICIkdG1w
IiAmJiB0ZXN0IC1kICIkdG1wIiA7IH0gfHwKKyB7IHRlc3QgLW4gIiRSQU5ET00iICYmIHRtcD0k
VE1QRElSL2NnJCQtJFJBTkRPTSAmJiAodW1hc2sgMDc3ICYmIG1rZGlyICR0bXApIDsgfSB8fAor
IHsgdG1wPSRUTVBESVIvY2ctJCQgJiYgKHVtYXNrIDA3NyAmJiBta2RpciAkdG1wKSAmJiBlY2hv
ICJXYXJuaW5nOiBjcmVhdGluZyBpbnNlY3VyZSB0ZW1wIGRpcmVjdG9yeSIgPiYyIDsgfSB8fAor
IHsgZWNobyAiJG1lOiBjYW5ub3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGRpcmVjdG9yeSBpbiAkVE1Q
RElSIiA+JjIgOyBleGl0IDEgOyB9IDsKK2R1bW15PSR0bXAvZHVtbXkgOwordG1wZmlsZXM9IiRk
dW1teS5jICRkdW1teS5vICRkdW1teS5yZWwgJGR1bW15IiA7CitjYXNlICRDQ19GT1JfQlVJTEQs
JEhPU1RfQ0MsJENDIGluCisgLCwpICAgIGVjaG8gImludCB4OyIgPiAkZHVtbXkuYyA7CisJZm9y
IGMgaW4gY2MgZ2NjIGM4OSBjOTkgOyBkbworCSAgaWYgKCRjIC1jIC1vICRkdW1teS5vICRkdW1t
eS5jKSA+L2Rldi9udWxsIDI+JjEgOyB0aGVuCisJICAgICBDQ19GT1JfQlVJTEQ9IiRjIjsgYnJl
YWsgOworCSAgZmkgOworCWRvbmUgOworCWlmIHRlc3QgeCIkQ0NfRk9SX0JVSUxEIiA9IHggOyB0
aGVuCisJICBDQ19GT1JfQlVJTEQ9bm9fY29tcGlsZXJfZm91bmQgOworCWZpCisJOzsKKyAsLCop
ICAgQ0NfRk9SX0JVSUxEPSRDQyA7OworICwqLCopICBDQ19GT1JfQlVJTEQ9JEhPU1RfQ0MgOzsK
K2VzYWMgOyBzZXRfY2NfZm9yX2J1aWxkPSA7JworCisjIFRoaXMgaXMgbmVlZGVkIHRvIGZpbmQg
dW5hbWUgb24gYSBQeXJhbWlkIE9TeCB3aGVuIHJ1biBpbiB0aGUgQlNEIHVuaXZlcnNlLgorIyAo
Z2hhemlAbm9jLnJ1dGdlcnMuZWR1IDE5OTQtMDgtMjQpCitpZiAodGVzdCAtZiAvLmF0dGJpbi91
bmFtZSkgPi9kZXYvbnVsbCAyPiYxIDsgdGhlbgorCVBBVEg9JFBBVEg6Ly5hdHRiaW4gOyBleHBv
cnQgUEFUSAorZmkKKworVU5BTUVfTUFDSElORT1gKHVuYW1lIC1tKSAyPi9kZXYvbnVsbGAgfHwg
VU5BTUVfTUFDSElORT11bmtub3duCitVTkFNRV9SRUxFQVNFPWAodW5hbWUgLXIpIDI+L2Rldi9u
dWxsYCB8fCBVTkFNRV9SRUxFQVNFPXVua25vd24KK1VOQU1FX1NZU1RFTT1gKHVuYW1lIC1zKSAy
Pi9kZXYvbnVsbGAgIHx8IFVOQU1FX1NZU1RFTT11bmtub3duCitVTkFNRV9WRVJTSU9OPWAodW5h
bWUgLXYpIDI+L2Rldi9udWxsYCB8fCBVTkFNRV9WRVJTSU9OPXVua25vd24KKworIyBOb3RlOiBv
cmRlciBpcyBzaWduaWZpY2FudCAtIHRoZSBjYXNlIGJyYW5jaGVzIGFyZSBub3QgZXhjbHVzaXZl
LgorCitjYXNlICIke1VOQU1FX01BQ0hJTkV9OiR7VU5BTUVfU1lTVEVNfToke1VOQU1FX1JFTEVB
U0V9OiR7VU5BTUVfVkVSU0lPTn0iIGluCisgICAgKjpOZXRCU0Q6KjoqKQorCSMgTmV0QlNEIChu
YnNkKSB0YXJnZXRzIHNob3VsZCAod2hlcmUgYXBwbGljYWJsZSkgbWF0Y2ggb25lIG9yCisJIyBt
b3JlIG9mIHRoZSB0dXBwbGVzOiAqLSotbmV0YnNkZWxmKiwgKi0qLW5ldGJzZGFvdXQqLAorCSMg
Ki0qLW5ldGJzZGVjb2ZmKiBhbmQgKi0qLW5ldGJzZCouICBGb3IgdGFyZ2V0cyB0aGF0IHJlY2Vu
dGx5CisJIyBzd2l0Y2hlZCB0byBFTEYsICotKi1uZXRic2QqIHdvdWxkIHNlbGVjdCB0aGUgb2xk
CisJIyBvYmplY3QgZmlsZSBmb3JtYXQuICBUaGlzIHByb3ZpZGVzIGJvdGggZm9yd2FyZAorCSMg
Y29tcGF0aWJpbGl0eSBhbmQgYSBjb25zaXN0ZW50IG1lY2hhbmlzbSBmb3Igc2VsZWN0aW5nIHRo
ZQorCSMgb2JqZWN0IGZpbGUgZm9ybWF0LgorCSMKKwkjIE5vdGU6IE5ldEJTRCBkb2Vzbid0IHBh
cnRpY3VsYXJseSBjYXJlIGFib3V0IHRoZSB2ZW5kb3IKKwkjIHBvcnRpb24gb2YgdGhlIG5hbWUu
ICBXZSBhbHdheXMgc2V0IGl0IHRvICJ1bmtub3duIi4KKwlzeXNjdGw9InN5c2N0bCAtbiBody5t
YWNoaW5lX2FyY2giCisJVU5BTUVfTUFDSElORV9BUkNIPWAoL3NiaW4vJHN5c2N0bCAyPi9kZXYv
bnVsbCB8fCBcCisJICAgIC91c3Ivc2Jpbi8kc3lzY3RsIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5r
bm93bilgCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FX0FSQ0h9IiBpbgorCSAgICBhcm1lYikgbWFj
aGluZT1hcm1lYi11bmtub3duIDs7CisJICAgIGFybSopIG1hY2hpbmU9YXJtLXVua25vd24gOzsK
KwkgICAgc2gzZWwpIG1hY2hpbmU9c2hsLXVua25vd24gOzsKKwkgICAgc2gzZWIpIG1hY2hpbmU9
c2gtdW5rbm93biA7OworCSAgICBzaDVlbCkgbWFjaGluZT1zaDVsZS11bmtub3duIDs7CisJICAg
ICopIG1hY2hpbmU9JHtVTkFNRV9NQUNISU5FX0FSQ0h9LXVua25vd24gOzsKKwllc2FjCisJIyBU
aGUgT3BlcmF0aW5nIFN5c3RlbSBpbmNsdWRpbmcgb2JqZWN0IGZvcm1hdCwgaWYgaXQgaGFzIHN3
aXRjaGVkCisJIyB0byBFTEYgcmVjZW50bHksIG9yIHdpbGwgaW4gdGhlIGZ1dHVyZS4KKwljYXNl
ICIke1VOQU1FX01BQ0hJTkVfQVJDSH0iIGluCisJICAgIGFybSp8aTM4NnxtNjhrfG5zMzJrfHNo
Myp8c3BhcmN8dmF4KQorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCWlmIGVjaG8gX19FTEZf
XyB8ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCBcCisJCQl8IGdyZXAgLXEgX19FTEZf
XworCQl0aGVuCisJCSAgICAjIE9uY2UgYWxsIHV0aWxpdGllcyBjYW4gYmUgRUNPRkYgKG5ldGJz
ZGVjb2ZmKSBvciBhLm91dCAobmV0YnNkYW91dCkuCisJCSAgICAjIFJldHVybiBuZXRic2QgZm9y
IGVpdGhlci4gIEZJWD8KKwkJICAgIG9zPW5ldGJzZAorCQllbHNlCisJCSAgICBvcz1uZXRic2Rl
bGYKKwkJZmkKKwkJOzsKKwkgICAgKikKKwkJb3M9bmV0YnNkCisJCTs7CisJZXNhYworCSMgVGhl
IE9TIHJlbGVhc2UKKwkjIERlYmlhbiBHTlUvTmV0QlNEIG1hY2hpbmVzIGhhdmUgYSBkaWZmZXJl
bnQgdXNlcmxhbmQsIGFuZAorCSMgdGh1cywgbmVlZCBhIGRpc3RpbmN0IHRyaXBsZXQuIEhvd2V2
ZXIsIHRoZXkgZG8gbm90IG5lZWQKKwkjIGtlcm5lbCB2ZXJzaW9uIGluZm9ybWF0aW9uLCBzbyBp
dCBjYW4gYmUgcmVwbGFjZWQgd2l0aCBhCisJIyBzdWl0YWJsZSB0YWcsIGluIHRoZSBzdHlsZSBv
ZiBsaW51eC1nbnUuCisJY2FzZSAiJHtVTkFNRV9WRVJTSU9OfSIgaW4KKwkgICAgRGViaWFuKikK
KwkJcmVsZWFzZT0nLWdudScKKwkJOzsKKwkgICAgKikKKwkJcmVsZWFzZT1gZWNobyAke1VOQU1F
X1JFTEVBU0V9fHNlZCAtZSAncy9bLV9dLiovXC4vJ2AKKwkJOzsKKwllc2FjCisJIyBTaW5jZSBD
UFVfVFlQRS1NQU5VRkFDVFVSRVItS0VSTkVMLU9QRVJBVElOR19TWVNURU06CisJIyBjb250YWlu
cyByZWR1bmRhbnQgaW5mb3JtYXRpb24sIHRoZSBzaG9ydGVyIGZvcm06CisJIyBDUFVfVFlQRS1N
QU5VRkFDVFVSRVItT1BFUkFUSU5HX1NZU1RFTSBpcyB1c2VkLgorCWVjaG8gIiR7bWFjaGluZX0t
JHtvc30ke3JlbGVhc2V9IgorCWV4aXQgOzsKKyAgICAqOk9wZW5CU0Q6KjoqKQorCVVOQU1FX01B
Q0hJTkVfQVJDSD1gYXJjaCB8IHNlZCAncy9PcGVuQlNELi8vJ2AKKwllY2hvICR7VU5BTUVfTUFD
SElORV9BUkNIfS11bmtub3duLW9wZW5ic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAg
ICo6ZWtrb0JTRDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tZWtrb2JzZCR7
VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpTb2xpZEJTRDoqOiopCisJZWNobyAke1VO
QU1FX01BQ0hJTkV9LXVua25vd24tc29saWRic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7Owor
ICAgIG1hY3BwYzpNaXJCU0Q6KjoqKQorCWVjaG8gcG93ZXJwYy11bmtub3duLW1pcmJzZCR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpNaXJCU0Q6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLW1pcmJzZCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgYWxw
aGE6T1NGMToqOiopCisJY2FzZSAkVU5BTUVfUkVMRUFTRSBpbgorCSo0LjApCisJCVVOQU1FX1JF
TEVBU0U9YC91c3Ivc2Jpbi9zaXplciAtdiB8IGF3ayAne3ByaW50ICQzfSdgCisJCTs7CisJKjUu
KikKKwkJVU5BTUVfUkVMRUFTRT1gL3Vzci9zYmluL3NpemVyIC12IHwgYXdrICd7cHJpbnQgJDR9
J2AKKwkJOzsKKwllc2FjCisJIyBBY2NvcmRpbmcgdG8gQ29tcGFxLCAvdXNyL3NiaW4vcHNyaW5m
byBoYXMgYmVlbiBhdmFpbGFibGUgb24KKwkjIE9TRi8xIGFuZCBUcnU2NCBzeXN0ZW1zIHByb2R1
Y2VkIHNpbmNlIDE5OTUuICBJIGhvcGUgdGhhdAorCSMgY292ZXJzIG1vc3Qgc3lzdGVtcyBydW5u
aW5nIHRvZGF5LiAgVGhpcyBjb2RlIHBpcGVzIHRoZSBDUFUKKwkjIHR5cGVzIHRocm91Z2ggaGVh
ZCAtbiAxLCBzbyB3ZSBvbmx5IGRldGVjdCB0aGUgdHlwZSBvZiBDUFUgMC4KKwlBTFBIQV9DUFVf
VFlQRT1gL3Vzci9zYmluL3BzcmluZm8gLXYgfCBzZWQgLW4gLWUgJ3MvXiAgVGhlIGFscGhhIFwo
LipcKSBwcm9jZXNzb3IuKiQvXDEvcCcgfCBoZWFkIC1uIDFgCisJY2FzZSAiJEFMUEhBX0NQVV9U
WVBFIiBpbgorCSAgICAiRVY0ICgyMTA2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsK
KwkgICAgIkVWNC41ICgyMTA2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAg
IkxDQTQgKDIxMDY2LzIxMDY4KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhIiA7OworCSAgICAi
RVY1ICgyMTE2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NSIgOzsKKwkgICAgIkVWNS42
ICgyMTE2NEEpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjU2IiA7OworCSAgICAiRVY1LjYg
KDIxMTY0UEMpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFwY2E1NiIgOzsKKwkgICAgIkVWNS43
ICgyMTE2NFBDKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhcGNhNTciIDs7CisJICAgICJFVjYg
KDIxMjY0KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2IiA7OworCSAgICAiRVY2LjcgKDIx
MjY0QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjciIDs7CisJICAgICJFVjYuOENCICgy
MTI2NEMpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY4IiA7OworCSAgICAiRVY2LjhBTCAo
MjEyNjRCKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OCIgOzsKKwkgICAgIkVWNi44Q1gg
KDIxMjY0RCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjgiIDs7CisJICAgICJFVjYuOUEg
KDIxMjY0L0VWNjlBKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OSIgOzsKKwkgICAgIkVW
NyAoMjEzNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjciIDs7CisJICAgICJFVjcuOSAo
MjEzNjRBKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY3OSIgOzsKKwllc2FjCisJIyBBIFBu
Lm4gdmVyc2lvbiBpcyBhIHBhdGNoZWQgdmVyc2lvbi4KKwkjIEEgVm4ubiB2ZXJzaW9uIGlzIGEg
cmVsZWFzZWQgdmVyc2lvbi4KKwkjIEEgVG4ubiB2ZXJzaW9uIGlzIGEgcmVsZWFzZWQgZmllbGQg
dGVzdCB2ZXJzaW9uLgorCSMgQSBYbi5uIHZlcnNpb24gaXMgYW4gdW5yZWxlYXNlZCBleHBlcmlt
ZW50YWwgYmFzZWxldmVsLgorCSMgMS4yIHVzZXMgIjEuMiIgZm9yIHVuYW1lIC1yLgorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1kZWMtb3NmYGVjaG8gJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAn
cy9eW1BWVFhdLy8nIHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hp
amtsbW5vcHFyc3R1dnd4eXonYAorCSMgUmVzZXQgRVhJVCB0cmFwIGJlZm9yZSBleGl0aW5nIHRv
IGF2b2lkIHNwdXJpb3VzIG5vbi16ZXJvIGV4aXQgY29kZS4KKwlleGl0Y29kZT0kPworCXRyYXAg
JycgMAorCWV4aXQgJGV4aXRjb2RlIDs7CisgICAgQWxwaGFcICo6V2luZG93c19OVCo6KikKKwkj
IEhvdyBkbyB3ZSBrbm93IGl0J3MgSW50ZXJpeCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyBQT1NJ
WCBzdWJzeXN0ZW0/CisJIyBTaG91bGQgd2UgY2hhbmdlIFVOQU1FX01BQ0hJTkUgYmFzZWQgb24g
dGhlIG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFkCisJIyBvZiB0aGUgc3BlY2lmaWMgQWxwaGEgbW9k
ZWw/CisJZWNobyBhbHBoYS1wYy1pbnRlcml4CisJZXhpdCA7OworICAgIDIxMDY0OldpbmRvd3Nf
TlQ6NTA6MykKKwllY2hvIGFscGhhLWRlYy13aW5udDMuNQorCWV4aXQgOzsKKyAgICBBbWlnYSo6
VU5JWF9TeXN0ZW1fVjo0LjA6KikKKwllY2hvIG02OGstdW5rbm93bi1zeXN2NAorCWV4aXQgOzsK
KyAgICAqOltBYV1taWdhW09vXVtTc106KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtu
b3duLWFtaWdhb3MKKwlleGl0IDs7CisgICAgKjpbTW1db3JwaFtPb11bU3NdOio6KikKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1tb3JwaG9zCisJZXhpdCA7OworICAgICo6T1MvMzkw
Oio6KikKKwllY2hvIGkzNzAtaWJtLW9wZW5lZGl0aW9uCisJZXhpdCA7OworICAgICo6ei9WTToq
OiopCisJZWNobyBzMzkwLWlibS16dm1vZQorCWV4aXQgOzsKKyAgICAqOk9TNDAwOio6KikKKwll
Y2hvIHBvd2VycGMtaWJtLW9zNDAwCisJZXhpdCA7OworICAgIGFybTpSSVNDKjoxLlswMTJdKjoq
fGFybTpyaXNjaXg6MS5bMDEyXSo6KikKKwllY2hvIGFybS1hY29ybi1yaXNjaXgke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIGFybTpyaXNjb3M6KjoqfGFybTpSSVNDT1M6KjoqKQorCWVj
aG8gYXJtLXVua25vd24tcmlzY29zCisJZXhpdCA7OworICAgIFNSMj8wMTpISS1VWC9NUFA6Kjoq
IHwgU1I4MDAwOkhJLVVYL01QUDoqOiopCisJZWNobyBocHBhMS4xLWhpdGFjaGktaGl1eG1wcAor
CWV4aXQgOzsKKyAgICBQeXJhbWlkKjpPU3gqOio6KiB8IE1JUyo6T1N4KjoqOiogfCBNSVMqOlNN
UF9EQy1PU3gqOio6KikKKwkjIGFrZWVAd3BkaXMwMy53cGFmYi5hZi5taWwgKEVhcmxlIEYuIEFr
ZSkgY29udHJpYnV0ZWQgTUlTIGFuZCBOSUxFLgorCWlmIHRlc3QgImAoL2Jpbi91bml2ZXJzZSkg
Mj4vZGV2L251bGxgIiA9IGF0dCA7IHRoZW4KKwkJZWNobyBweXJhbWlkLXB5cmFtaWQtc3lzdjMK
KwllbHNlCisJCWVjaG8gcHlyYW1pZC1weXJhbWlkLWJzZAorCWZpCisJZXhpdCA7OworICAgIE5J
TEUqOio6KjpkY29zeCkKKwllY2hvIHB5cmFtaWQtcHlyYW1pZC1zdnI0CisJZXhpdCA7OworICAg
IERSUz82MDAwOnVuaXg6NC4wOjYqKQorCWVjaG8gc3BhcmMtaWNsLW54NgorCWV4aXQgOzsKKyAg
ICBEUlM/NjAwMDpVTklYX1NWOjQuMio6NyogfCBEUlM/NjAwMDppc2lzOjQuMio6NyopCisJY2Fz
ZSBgL3Vzci9iaW4vdW5hbWUgLXBgIGluCisJICAgIHNwYXJjKSBlY2hvIHNwYXJjLWljbC1ueDc7
IGV4aXQgOzsKKwllc2FjIDs7CisgICAgczM5MHg6U3VuT1M6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1pYm0tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5d
Ki8vJ2AKKwlleGl0IDs7CisgICAgc3VuNEg6U3VuT1M6NS4qOiopCisJZWNobyBzcGFyYy1oYWwt
c29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0
IDs7CisgICAgc3VuNCo6U3VuT1M6NS4qOiogfCB0YWRwb2xlKjpTdW5PUzo1Lio6KikKKwllY2hv
IHNwYXJjLXN1bi1zb2xhcmlzMmBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0q
Ly8nYAorCWV4aXQgOzsKKyAgICBpODZwYzpBdXJvcmFVWDo1Lio6KiB8IGk4NnhlbjpBdXJvcmFV
WDo1Lio6KikKKwllY2hvIGkzODYtcGMtYXVyb3JhdXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGk4NnBjOlN1bk9TOjUuKjoqIHwgaTg2eGVuOlN1bk9TOjUuKjoqKQorCWV2YWwgJHNl
dF9jY19mb3JfYnVpbGQKKwlTVU5fQVJDSD0iaTM4NiIKKwkjIElmIHRoZXJlIGlzIGEgY29tcGls
ZXIsIHNlZSBpZiBpdCBpcyBjb25maWd1cmVkIGZvciA2NC1iaXQgb2JqZWN0cy4KKwkjIE5vdGUg
dGhhdCB0aGUgU3VuIGNjIGRvZXMgbm90IHR1cm4gX19MUDY0X18gaW50byAxIGxpa2UgZ2NjIGRv
ZXMuCisJIyBUaGlzIHRlc3Qgd29ya3MgZm9yIGJvdGggY29tcGlsZXJzLgorCWlmIFsgIiRDQ19G
T1JfQlVJTEQiICE9ICdub19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCSAgICBpZiAoZWNobyAn
I2lmZGVmIF9fYW1kNjQnOyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicpIHwgXAor
CQkoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwgXAorCQlncmVwIElT
XzY0QklUX0FSQ0ggPi9kZXYvbnVsbAorCSAgICB0aGVuCisJCVNVTl9BUkNIPSJ4ODZfNjQiCisJ
ICAgIGZpCisJZmkKKwllY2hvICR7U1VOX0FSQ0h9LXBjLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9S
RUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjYq
OiopCisJIyBBY2NvcmRpbmcgdG8gY29uZmlnLnN1YiwgdGhpcyBpcyB0aGUgcHJvcGVyIHdheSB0
byBjYW5vbmljYWxpemUKKwkjIFN1bk9TNi4gIEhhcmQgdG8gZ3Vlc3MgZXhhY3RseSB3aGF0IFN1
bk9TNiB3aWxsIGJlIGxpa2UsIGJ1dAorCSMgaXQncyBsaWtlbHkgdG8gYmUgbW9yZSBsaWtlIFNv
bGFyaXMgdGhhbiBTdW5PUzQuCisJZWNobyBzcGFyYy1zdW4tc29sYXJpczNgZWNobyAke1VOQU1F
X1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgc3VuNCo6U3VuT1M6
KjoqKQorCWNhc2UgImAvdXNyL2Jpbi9hcmNoIC1rYCIgaW4KKwkgICAgU2VyaWVzKnxTNCopCisJ
CVVOQU1FX1JFTEVBU0U9YHVuYW1lIC12YAorCQk7OworCWVzYWMKKwkjIEphcGFuZXNlIExhbmd1
YWdlIHZlcnNpb25zIGhhdmUgYSB2ZXJzaW9uIG51bWJlciBsaWtlIGA0LjEuMy1KTCcuCisJZWNo
byBzcGFyYy1zdW4tc3Vub3NgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vJ2AK
KwlleGl0IDs7CisgICAgc3VuMyo6U3VuT1M6KjoqKQorCWVjaG8gbTY4ay1zdW4tc3Vub3Mke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHN1bio6Kjo0LjJCU0Q6KikKKwlVTkFNRV9SRUxF
QVNFPWAoc2VkIDFxIC9ldGMvbW90ZCB8IGF3ayAne3ByaW50IHN1YnN0cigkNSwxLDMpfScpIDI+
L2Rldi9udWxsYAorCXRlc3QgIngke1VOQU1FX1JFTEVBU0V9IiA9ICJ4IiAmJiBVTkFNRV9SRUxF
QVNFPTMKKwljYXNlICJgL2Jpbi9hcmNoYCIgaW4KKwkgICAgc3VuMykKKwkJZWNobyBtNjhrLXN1
bi1zdW5vcyR7VU5BTUVfUkVMRUFTRX0KKwkJOzsKKwkgICAgc3VuNCkKKwkJZWNobyBzcGFyYy1z
dW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJCTs7CisJZXNhYworCWV4aXQgOzsKKyAgICBhdXNo
cDpTdW5PUzoqOiopCisJZWNobyBzcGFyYy1hdXNwZXgtc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgICMgVGhlIHNpdHVhdGlvbiBmb3IgTWlOVCBpcyBhIGxpdHRsZSBjb25mdXNp
bmcuICBUaGUgbWFjaGluZSBuYW1lCisgICAgIyBjYW4gYmUgdmlydHVhbGx5IGV2ZXJ5dGhpbmcg
KGV2ZXJ5dGhpbmcgd2hpY2ggaXMgbm90CisgICAgIyAiYXRhcmlzdCIgb3IgImF0YXJpc3RlIiBh
dCBsZWFzdCBzaG91bGQgaGF2ZSBhIHByb2Nlc3NvcgorICAgICMgPiBtNjgwMDApLiAgVGhlIHN5
c3RlbSBuYW1lIHJhbmdlcyBmcm9tICJNaU5UIiBvdmVyICJGcmVlTWlOVCIKKyAgICAjIHRvIHRo
ZSBsb3dlcmNhc2UgdmVyc2lvbiAibWludCIgKG9yICJmcmVlbWludCIpLiAgRmluYWxseQorICAg
ICMgdGhlIHN5c3RlbSBuYW1lICJUT1MiIGRlbm90ZXMgYSBzeXN0ZW0gd2hpY2ggaXMgYWN0dWFs
bHkgbm90CisgICAgIyBNaU5ULiAgQnV0IE1pTlQgaXMgZG93bndhcmQgY29tcGF0aWJsZSB0byBU
T1MsIHNvIHRoaXMgc2hvdWxkCisgICAgIyBiZSBubyBwcm9ibGVtLgorICAgIGF0YXJpc3RbZV06
Kk1pTlQ6KjoqIHwgYXRhcmlzdFtlXToqbWludDoqOiogfCBhdGFyaXN0W2VdOipUT1M6KjoqKQor
CWVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBhdGFy
aSo6Kk1pTlQ6KjoqIHwgYXRhcmkqOiptaW50Oio6KiB8IGF0YXJpc3RbZV06KlRPUzoqOiopCisJ
ZWNobyBtNjhrLWF0YXJpLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICpmYWxj
b24qOipNaU5UOio6KiB8ICpmYWxjb24qOiptaW50Oio6KiB8ICpmYWxjb24qOipUT1M6KjoqKQor
CWVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBtaWxh
bio6Kk1pTlQ6KjoqIHwgbWlsYW4qOiptaW50Oio6KiB8ICptaWxhbio6KlRPUzoqOiopCisJZWNo
byBtNjhrLW1pbGFuLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIGhhZGVzKjoq
TWlOVDoqOiogfCBoYWRlcyo6Km1pbnQ6KjoqIHwgKmhhZGVzKjoqVE9TOio6KikKKwllY2hvIG02
OGstaGFkZXMtbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjoqTWlOVDoqOiog
fCAqOiptaW50Oio6KiB8ICo6KlRPUzoqOiopCisJZWNobyBtNjhrLXVua25vd24tbWludCR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgbTY4azptYWNodGVuOio6KikKKwllY2hvIG02OGst
YXBwbGUtbWFjaHRlbiR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgcG93ZXJwYzptYWNo
dGVuOio6KikKKwllY2hvIHBvd2VycGMtYXBwbGUtbWFjaHRlbiR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgUklTQyo6TWFjaDoqOiopCisJZWNobyBtaXBzLWRlYy1tYWNoX2JzZDQuMwor
CWV4aXQgOzsKKyAgICBSSVNDKjpVTFRSSVg6KjoqKQorCWVjaG8gbWlwcy1kZWMtdWx0cml4JHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBWQVgqOlVMVFJJWCo6KjoqKQorCWVjaG8gdmF4
LWRlYy11bHRyaXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIDIwMjA6Q0xJWDoqOiog
fCAyNDMwOkNMSVg6KjoqKQorCWVjaG8gY2xpcHBlci1pbnRlcmdyYXBoLWNsaXgke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIG1pcHM6KjoqOlVNSVBTIHwgbWlwczoqOio6UklTQ29zKQor
CWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYwor
I2lmZGVmIF9fY3BsdXNwbHVzCisjaW5jbHVkZSA8c3RkaW8uaD4gIC8qIGZvciBwcmludGYoKSBw
cm90b3R5cGUgKi8KKwlpbnQgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkgeworI2Vsc2UK
KwlpbnQgbWFpbiAoYXJnYywgYXJndikgaW50IGFyZ2M7IGNoYXIgKmFyZ3ZbXTsgeworI2VuZGlm
CisJI2lmIGRlZmluZWQgKGhvc3RfbWlwcykgJiYgZGVmaW5lZCAoTUlQU0VCKQorCSNpZiBkZWZp
bmVkIChTWVNUWVBFX1NZU1YpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzeXN2XG4i
LCBhcmd2WzFdKTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfU1ZS
NCkKKwkgIHByaW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc3N2cjRcbiIsIGFyZ3ZbMV0pOyBleGl0
ICgwKTsKKwkjZW5kaWYKKwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9CU0Q0MykgfHwgZGVmaW5lZChT
WVNUWVBFX0JTRCkKKwkgIHByaW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc2JzZFxuIiwgYXJndlsx
XSk7IGV4aXQgKDApOworCSNlbmRpZgorCSNlbmRpZgorCSAgZXhpdCAoLTEpOworCX0KK0VPRgor
CSRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmCisJICBkdW1teWFyZz1gZWNobyAi
JHtVTkFNRV9SRUxFQVNFfSIgfCBzZWQgLW4gJ3MvXChbMC05XSpcKS4qL1wxL3AnYCAmJgorCSAg
U1lTVEVNX05BTUU9YCRkdW1teSAkZHVtbXlhcmdgICYmCisJICAgIHsgZWNobyAiJFNZU1RFTV9O
QU1FIjsgZXhpdDsgfQorCWVjaG8gbWlwcy1taXBzLXJpc2NvcyR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgTW90b3JvbGE6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93ZXJwYy1tb3Rv
cm9sYS1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBNb3Rvcm9sYToqOjQuMzpQTDgtKikKKwllY2hv
IHBvd2VycGMtaGFycmlzLXBvd2VybWF4CisJZXhpdCA7OworICAgIE5pZ2h0X0hhd2s6KjoqOlBv
d2VyTUFYX09TIHwgU3luZXJneTpQb3dlck1BWF9PUzoqOiopCisJZWNobyBwb3dlcnBjLWhhcnJp
cy1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBOaWdodF9IYXdrOlBvd2VyX1VOSVg6KjoqKQorCWVj
aG8gcG93ZXJwYy1oYXJyaXMtcG93ZXJ1bml4CisJZXhpdCA7OworICAgIG04OGs6Q1gvVVg6Nyo6
KikKKwllY2hvIG04OGstaGFycmlzLWN4dXg3CisJZXhpdCA7OworICAgIG04OGs6Kjo0KjpSNCop
CisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3Y0CisJZXhpdCA7OworICAgIG04OGs6KjozKjpSMyop
CisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIEFWaWlPTjpkZ3V4Oio6
KikKKwkjIERHL1VYIHJldHVybnMgQVZpaU9OIGZvciBhbGwgYXJjaGl0ZWN0dXJlcworCVVOQU1F
X1BST0NFU1NPUj1gL3Vzci9iaW4vdW5hbWUgLXBgCisJaWYgWyAkVU5BTUVfUFJPQ0VTU09SID0g
bWM4ODEwMCBdIHx8IFsgJFVOQU1FX1BST0NFU1NPUiA9IG1jODgxMTAgXQorCXRoZW4KKwkgICAg
aWYgWyAke1RBUkdFVF9CSU5BUllfSU5URVJGQUNFfXggPSBtODhrZGd1eGVsZnggXSB8fCBcCisJ
ICAgICAgIFsgJHtUQVJHRVRfQklOQVJZX0lOVEVSRkFDRX14ID0geCBdCisJICAgIHRoZW4KKwkJ
ZWNobyBtODhrLWRnLWRndXgke1VOQU1FX1JFTEVBU0V9CisJICAgIGVsc2UKKwkJZWNobyBtODhr
LWRnLWRndXhiY3Mke1VOQU1FX1JFTEVBU0V9CisJICAgIGZpCisJZWxzZQorCSAgICBlY2hvIGk1
ODYtZGctZGd1eCR7VU5BTUVfUkVMRUFTRX0KKwlmaQorCWV4aXQgOzsKKyAgICBNODgqOkRvbHBo
aW5PUzoqOiopCSMgRG9scGhpbk9TIChTVlIzKQorCWVjaG8gbTg4ay1kb2xwaGluLXN5c3YzCisJ
ZXhpdCA7OworICAgIE04OCo6KjpSMyo6KikKKwkjIERlbHRhIDg4ayBzeXN0ZW0gcnVubmluZyBT
VlIzCisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIFhEODgqOio6Kjoq
KSAjIFRla3Ryb25peCBYRDg4IHN5c3RlbSBydW5uaW5nIFVUZWtWIChTVlIzKQorCWVjaG8gbTg4
ay10ZWt0cm9uaXgtc3lzdjMKKwlleGl0IDs7CisgICAgVGVrNDNbMC05XVswLTldOlVUZWs6Kjoq
KSAjIFRla3Ryb25peCA0MzAwIHN5c3RlbSBydW5uaW5nIFVUZWsgKEJTRCkKKwllY2hvIG02OGst
dGVrdHJvbml4LWJzZAorCWV4aXQgOzsKKyAgICAqOklSSVgqOio6KikKKwllY2hvIG1pcHMtc2dp
LWlyaXhgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vZydgCisJZXhpdCA7Owor
ICAgID8/Pz8/Pz8/OkFJWD86WzEyXS4xOjIpICAgIyBBSVggMi4yLjEgb3IgQUlYIDIuMS4xIGlz
IFJUL1BDIEFJWC4KKwllY2hvIHJvbXAtaWJtLWFpeCAgICAgIyB1bmFtZSAtbSBnaXZlcyBhbiA4
IGhleC1jb2RlIENQVSBpZAorCWV4aXQgOzsgICAgICAgICAgICAgICAjIE5vdGUgdGhhdDogZWNo
byAiJ2B1bmFtZSAtc2AnIiBnaXZlcyAnQUlYICcKKyAgICBpKjg2OkFJWDoqOiopCisJZWNobyBp
Mzg2LWlibS1haXgKKwlleGl0IDs7CisgICAgaWE2NDpBSVg6KjoqKQorCWlmIFsgLXggL3Vzci9i
aW4vb3NsZXZlbCBdIDsgdGhlbgorCQlJQk1fUkVWPWAvdXNyL2Jpbi9vc2xldmVsYAorCWVsc2UK
KwkJSUJNX1JFVj0ke1VOQU1FX1ZFUlNJT059LiR7VU5BTUVfUkVMRUFTRX0KKwlmaQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1pYm0tYWl4JHtJQk1fUkVWfQorCWV4aXQgOzsKKyAgICAqOkFJWDoy
OjMpCisJaWYgZ3JlcCBib3MzMjUgL3Vzci9pbmNsdWRlL3N0ZGlvLmggPi9kZXYvbnVsbCAyPiYx
OyB0aGVuCisJCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJc2VkICdzL14JCS8vJyA8PCBFT0Yg
PiRkdW1teS5jCisJCSNpbmNsdWRlIDxzeXMvc3lzdGVtY2ZnLmg+CisKKwkJbWFpbigpCisJCQl7
CisJCQlpZiAoIV9fcG93ZXJfcGMoKSkKKwkJCQlleGl0KDEpOworCQkJcHV0cygicG93ZXJwYy1p
Ym0tYWl4My4yLjUiKTsKKwkJCWV4aXQoMCk7CisJCQl9CitFT0YKKwkJaWYgJENDX0ZPUl9CVUlM
RCAtbyAkZHVtbXkgJGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRkdW1teWAKKwkJdGhlbgorCQkJ
ZWNobyAiJFNZU1RFTV9OQU1FIgorCQllbHNlCisJCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yLjUK
KwkJZmkKKwllbGlmIGdyZXAgYm9zMzI0IC91c3IvaW5jbHVkZS9zdGRpby5oID4vZGV2L251bGwg
Mj4mMTsgdGhlbgorCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yLjQKKwllbHNlCisJCWVjaG8gcnM2
MDAwLWlibS1haXgzLjIKKwlmaQorCWV4aXQgOzsKKyAgICAqOkFJWDoqOls0NTY3XSkKKwlJQk1f
Q1BVX0lEPWAvdXNyL3NiaW4vbHNkZXYgLUMgLWMgcHJvY2Vzc29yIC1TIGF2YWlsYWJsZSB8IHNl
ZCAxcSB8IGF3ayAneyBwcmludCAkMSB9J2AKKwlpZiAvdXNyL3NiaW4vbHNhdHRyIC1FbCAke0lC
TV9DUFVfSUR9IHwgZ3JlcCAnIFBPV0VSJyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKwkJSUJNX0FS
Q0g9cnM2MDAwCisJZWxzZQorCQlJQk1fQVJDSD1wb3dlcnBjCisJZmkKKwlpZiBbIC14IC91c3Iv
YmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1gL3Vzci9iaW4vb3NsZXZlbGAKKwllbHNl
CisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VOQU1FX1JFTEVBU0V9CisJZmkKKwllY2hv
ICR7SUJNX0FSQ0h9LWlibS1haXgke0lCTV9SRVZ9CisJZXhpdCA7OworICAgICo6QUlYOio6KikK
KwllY2hvIHJzNjAwMC1pYm0tYWl4CisJZXhpdCA7OworICAgIGlibXJ0OjQuNEJTRDoqfHJvbXAt
aWJtOkJTRDoqKQorCWVjaG8gcm9tcC1pYm0tYnNkNC40CisJZXhpdCA7OworICAgIGlibXJ0OipC
U0Q6Knxyb21wLWlibTpCU0Q6KikgICAgICAgICAgICAjIGNvdmVycyBSVC9QQyBCU0QgYW5kCisJ
ZWNobyByb21wLWlibS1ic2Qke1VOQU1FX1JFTEVBU0V9ICAgIyA0LjMgd2l0aCB1bmFtZSBhZGRl
ZCB0bworCWV4aXQgOzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgcmVwb3J0OiByb21w
LWlibSBCU0QgNC4zCisgICAgKjpCT1NYOio6KikKKwllY2hvIHJzNjAwMC1idWxsLWJvc3gKKwll
eGl0IDs7CisgICAgRFBYLzI/MDA6Qi5PLlMuOio6KikKKwllY2hvIG02OGstYnVsbC1zeXN2Mwor
CWV4aXQgOzsKKyAgICA5MDAwL1szNF0/Pzo0LjNic2Q6MS4qOiopCisJZWNobyBtNjhrLWhwLWJz
ZAorCWV4aXQgOzsKKyAgICBocDMwMDo0LjRCU0Q6KjoqIHwgOTAwMC9bMzRdPz86NC4zYnNkOjIu
KjoqKQorCWVjaG8gbTY4ay1ocC1ic2Q0LjQKKwlleGl0IDs7CisgICAgOTAwMC9bMzQ2NzhdPz86
SFAtVVg6KjoqKQorCUhQVVhfUkVWPWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1te
Ll0qLlswQl0qLy8nYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORX0iIGluCisJICAgIDkwMDAvMzE/
ICkgICAgICAgICAgICBIUF9BUkNIPW02ODAwMCA7OworCSAgICA5MDAwL1szNF0/PyApICAgICAg
ICAgSFBfQVJDSD1tNjhrIDs7CisJICAgIDkwMDAvWzY3OF1bMC05XVswLTldKQorCQlpZiBbIC14
IC91c3IvYmluL2dldGNvbmYgXTsgdGhlbgorCQkgICAgc2NfY3B1X3ZlcnNpb249YC91c3IvYmlu
L2dldGNvbmYgU0NfQ1BVX1ZFUlNJT04gMj4vZGV2L251bGxgCisJCSAgICBzY19rZXJuZWxfYml0
cz1gL3Vzci9iaW4vZ2V0Y29uZiBTQ19LRVJORUxfQklUUyAyPi9kZXYvbnVsbGAKKwkJICAgIGNh
c2UgIiR7c2NfY3B1X3ZlcnNpb259IiBpbgorCQkgICAgICA1MjMpIEhQX0FSQ0g9ImhwcGExLjAi
IDs7ICMgQ1BVX1BBX1JJU0MxXzAKKwkJICAgICAgNTI4KSBIUF9BUkNIPSJocHBhMS4xIiA7OyAj
IENQVV9QQV9SSVNDMV8xCisJCSAgICAgIDUzMikgICAgICAgICAgICAgICAgICAgICAgIyBDUFVf
UEFfUklTQzJfMAorCQkJY2FzZSAiJHtzY19rZXJuZWxfYml0c30iIGluCisJCQkgIDMyKSBIUF9B
UkNIPSJocHBhMi4wbiIgOzsKKwkJCSAgNjQpIEhQX0FSQ0g9ImhwcGEyLjB3IiA7OworCQkJICAn
JykgSFBfQVJDSD0iaHBwYTIuMCIgOzsgICAjIEhQLVVYIDEwLjIwCisJCQllc2FjIDs7CisJCSAg
ICBlc2FjCisJCWZpCisJCWlmIFsgIiR7SFBfQVJDSH0iID0gIiIgXTsgdGhlbgorCQkgICAgZXZh
bCAkc2V0X2NjX2Zvcl9idWlsZAorCQkgICAgc2VkICdzL14JCS8vJyA8PCBFT0YgPiRkdW1teS5j
CisKKwkJI2RlZmluZSBfSFBVWF9TT1VSQ0UKKwkJI2luY2x1ZGUgPHN0ZGxpYi5oPgorCQkjaW5j
bHVkZSA8dW5pc3RkLmg+CisKKwkJaW50IG1haW4gKCkKKwkJeworCQkjaWYgZGVmaW5lZChfU0Nf
S0VSTkVMX0JJVFMpCisJCSAgICBsb25nIGJpdHMgPSBzeXNjb25mKF9TQ19LRVJORUxfQklUUyk7
CisJCSNlbmRpZgorCQkgICAgbG9uZyBjcHUgID0gc3lzY29uZiAoX1NDX0NQVV9WRVJTSU9OKTsK
KworCQkgICAgc3dpdGNoIChjcHUpCisJCQl7CisJCQljYXNlIENQVV9QQV9SSVNDMV8wOiBwdXRz
ICgiaHBwYTEuMCIpOyBicmVhazsKKwkJCWNhc2UgQ1BVX1BBX1JJU0MxXzE6IHB1dHMgKCJocHBh
MS4xIik7IGJyZWFrOworCQkJY2FzZSBDUFVfUEFfUklTQzJfMDoKKwkJI2lmIGRlZmluZWQoX1ND
X0tFUk5FTF9CSVRTKQorCQkJICAgIHN3aXRjaCAoYml0cykKKwkJCQl7CisJCQkJY2FzZSA2NDog
cHV0cyAoImhwcGEyLjB3Iik7IGJyZWFrOworCQkJCWNhc2UgMzI6IHB1dHMgKCJocHBhMi4wbiIp
OyBicmVhazsKKwkJCQlkZWZhdWx0OiBwdXRzICgiaHBwYTIuMCIpOyBicmVhazsKKwkJCQl9IGJy
ZWFrOworCQkjZWxzZSAgLyogIWRlZmluZWQoX1NDX0tFUk5FTF9CSVRTKSAqLworCQkJICAgIHB1
dHMgKCJocHBhMi4wIik7IGJyZWFrOworCQkjZW5kaWYKKwkJCWRlZmF1bHQ6IHB1dHMgKCJocHBh
MS4wIik7IGJyZWFrOworCQkJfQorCQkgICAgZXhpdCAoMCk7CisJCX0KK0VPRgorCQkgICAgKEND
T1BUUz0gJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgMj4vZGV2L251bGwpICYmIEhQ
X0FSQ0g9YCRkdW1teWAKKwkJICAgIHRlc3QgLXogIiRIUF9BUkNIIiAmJiBIUF9BUkNIPWhwcGEK
KwkJZmkgOzsKKwllc2FjCisJaWYgWyAke0hQX0FSQ0h9ID0gImhwcGEyLjB3IiBdCisJdGhlbgor
CSAgICBldmFsICRzZXRfY2NfZm9yX2J1aWxkCisKKwkgICAgIyBocHBhMi4wdy1ocC1ocHV4KiBo
YXMgYSA2NC1iaXQga2VybmVsIGFuZCBhIGNvbXBpbGVyIGdlbmVyYXRpbmcKKwkgICAgIyAzMi1i
aXQgY29kZS4gIGhwcGE2NC1ocC1ocHV4KiBoYXMgdGhlIHNhbWUga2VybmVsIGFuZCBhIGNvbXBp
bGVyCisJICAgICMgZ2VuZXJhdGluZyA2NC1iaXQgY29kZS4gIEdOVSBhbmQgSFAgdXNlIGRpZmZl
cmVudCBub21lbmNsYXR1cmU6CisJICAgICMKKwkgICAgIyAkIENDX0ZPUl9CVUlMRD1jYyAuL2Nv
bmZpZy5ndWVzcworCSAgICAjID0+IGhwcGEyLjB3LWhwLWhwdXgxMS4yMworCSAgICAjICQgQ0Nf
Rk9SX0JVSUxEPSJjYyArREEyLjB3IiAuL2NvbmZpZy5ndWVzcworCSAgICAjID0+IGhwcGE2NC1o
cC1ocHV4MTEuMjMKKworCSAgICBpZiBlY2hvIF9fTFA2NF9fIHwgKENDT1BUUz0gJENDX0ZPUl9C
VUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8CisJCWdyZXAgLXEgX19MUDY0X18KKwkgICAgdGhlbgor
CQlIUF9BUkNIPSJocHBhMi4wdyIKKwkgICAgZWxzZQorCQlIUF9BUkNIPSJocHBhNjQiCisJICAg
IGZpCisJZmkKKwllY2hvICR7SFBfQVJDSH0taHAtaHB1eCR7SFBVWF9SRVZ9CisJZXhpdCA7Owor
ICAgIGlhNjQ6SFAtVVg6KjoqKQorCUhQVVhfUkVWPWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2Vk
IC1lICdzL1teLl0qLlswQl0qLy8nYAorCWVjaG8gaWE2NC1ocC1ocHV4JHtIUFVYX1JFVn0KKwll
eGl0IDs7CisgICAgMzA1MCo6SEktVVg6KjoqKQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlz
ZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworCSNpbmNsdWRlIDx1bmlzdGQuaD4KKwlpbnQK
KwltYWluICgpCisJeworCSAgbG9uZyBjcHUgPSBzeXNjb25mIChfU0NfQ1BVX1ZFUlNJT04pOwor
CSAgLyogVGhlIG9yZGVyIG1hdHRlcnMsIGJlY2F1c2UgQ1BVX0lTX0hQX01DNjhLIGVycm9uZW91
c2x5IHJldHVybnMKKwkgICAgIHRydWUgZm9yIENQVV9QQV9SSVNDMV8wLiAgQ1BVX0lTX1BBX1JJ
U0MgcmV0dXJucyBjb3JyZWN0CisJICAgICByZXN1bHRzLCBob3dldmVyLiAgKi8KKwkgIGlmIChD
UFVfSVNfUEFfUklTQyAoY3B1KSkKKwkgICAgeworCSAgICAgIHN3aXRjaCAoY3B1KQorCQl7CisJ
CSAgY2FzZSBDUFVfUEFfUklTQzFfMDogcHV0cyAoImhwcGExLjAtaGl0YWNoaS1oaXV4d2UyIik7
IGJyZWFrOworCQkgIGNhc2UgQ1BVX1BBX1JJU0MxXzE6IHB1dHMgKCJocHBhMS4xLWhpdGFjaGkt
aGl1eHdlMiIpOyBicmVhazsKKwkJICBjYXNlIENQVV9QQV9SSVNDMl8wOiBwdXRzICgiaHBwYTIu
MC1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJCSAgZGVmYXVsdDogcHV0cyAoImhwcGEtaGl0
YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQl9CisJICAgIH0KKwkgIGVsc2UgaWYgKENQVV9JU19I
UF9NQzY4SyAoY3B1KSkKKwkgICAgcHV0cyAoIm02OGstaGl0YWNoaS1oaXV4d2UyIik7CisJICBl
bHNlIHB1dHMgKCJ1bmtub3duLWhpdGFjaGktaGl1eHdlMiIpOworCSAgZXhpdCAoMCk7CisJfQor
RU9GCisJJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRk
dW1teWAgJiYKKwkJeyBlY2hvICIkU1lTVEVNX05BTUUiOyBleGl0OyB9CisJZWNobyB1bmtub3du
LWhpdGFjaGktaGl1eHdlMgorCWV4aXQgOzsKKyAgICA5MDAwLzc/Pzo0LjNic2Q6KjoqIHwgOTAw
MC84P1s3OV06NC4zYnNkOio6KiApCisJZWNobyBocHBhMS4xLWhwLWJzZAorCWV4aXQgOzsKKyAg
ICA5MDAwLzg/Pzo0LjNic2Q6KjoqKQorCWVjaG8gaHBwYTEuMC1ocC1ic2QKKwlleGl0IDs7Cisg
ICAgKjk/Pyo6TVBFL2lYOio6KiB8ICozMDAwKjpNUEUvaVg6KjoqKQorCWVjaG8gaHBwYTEuMC1o
cC1tcGVpeAorCWV4aXQgOzsKKyAgICBocDc/PzpPU0YxOio6KiB8IGhwOD9bNzldOk9TRjE6Kjoq
ICkKKwllY2hvIGhwcGExLjEtaHAtb3NmCisJZXhpdCA7OworICAgIGhwOD8/Ok9TRjE6KjoqKQor
CWVjaG8gaHBwYTEuMC1ocC1vc2YKKwlleGl0IDs7CisgICAgaSo4NjpPU0YxOio6KikKKwlpZiBb
IC14IC91c3Ivc2Jpbi9zeXN2ZXJzaW9uIF0gOyB0aGVuCisJICAgIGVjaG8gJHtVTkFNRV9NQUNI
SU5FfS11bmtub3duLW9zZjFtaworCWVsc2UKKwkgICAgZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tb3NmMQorCWZpCisJZXhpdCA7OworICAgIHBhcmlzYyo6TGl0ZXMqOio6KikKKwllY2hv
IGhwcGExLjEtaHAtbGl0ZXMKKwlleGl0IDs7CisgICAgQzEqOkNvbnZleE9TOio6KiB8IGNvbnZl
eDpDb252ZXhPUzpDMSo6KikKKwllY2hvIGMxLWNvbnZleC1ic2QKKwlleGl0IDs7CisgICAgQzIq
OkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMio6KikKKwlpZiBnZXRzeXNpbmZvIC1m
IHNjYWxhcl9hY2MKKwl0aGVuIGVjaG8gYzMyLWNvbnZleC1ic2QKKwllbHNlIGVjaG8gYzItY29u
dmV4LWJzZAorCWZpCisJZXhpdCA7OworICAgIEMzNCo6Q29udmV4T1M6KjoqIHwgY29udmV4OkNv
bnZleE9TOkMzNCo6KikKKwllY2hvIGMzNC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIEMzOCo6
Q29udmV4T1M6KjoqIHwgY29udmV4OkNvbnZleE9TOkMzOCo6KikKKwllY2hvIGMzOC1jb252ZXgt
YnNkCisJZXhpdCA7OworICAgIEM0KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzQq
OiopCisJZWNobyBjNC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIENSQVkqWS1NUDoqOio6KikK
KwllY2hvIHltcC1jcmF5LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5d
KiQvLlgvJworCWV4aXQgOzsKKyAgICBDUkFZKltBLVpdOTA6KjoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSBcCisJfCBzZWQgLWUgJ3MvQ1JB
WS4qXChbQS1aXTkwXCkvXDEvJyBcCisJICAgICAgLWUgeS9BQkNERUZHSElKS0xNTk9QUVJTVFVW
V1hZWi9hYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ei8gXAorCSAgICAgIC1lICdzL1wuW14uXSok
Ly5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpUUzoqOio6KikKKwllY2hvIHQ5MC1jcmF5LXVuaWNv
cyR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5dKiQvLlgvJworCWV4aXQgOzsKKyAg
ICBDUkFZKlQzRToqOio6KikKKwllY2hvIGFscGhhZXY1LWNyYXktdW5pY29zbWske1VOQU1FX1JF
TEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpTVjE6
KjoqOiopCisJZWNobyBzdjEtY3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdz
L1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgKjpVTklDT1MvbXA6KjoqKQorCWVjaG8gY3Jh
eW52LWNyYXktdW5pY29zbXAke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5Y
LycKKwlleGl0IDs7CisgICAgRjMwWzAxXTpVTklYX1N5c3RlbV9WOio6KiB8IEY3MDA6VU5JWF9T
eXN0ZW1fVjoqOiopCisJRlVKSVRTVV9QUk9DPWB1bmFtZSAtbSB8IHRyICdBQkNERUZHSElKS0xN
Tk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6J2AKKwlGVUpJVFNVX1NZ
Uz1gdW5hbWUgLXAgfCB0ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVonICdhYmNkZWZnaGlq
a2xtbm9wcXJzdHV2d3h5eicgfCBzZWQgLWUgJ3MvXC8vLydgCisJRlVKSVRTVV9SRUw9YGVjaG8g
JHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy8gL18vJ2AKKwllY2hvICIke0ZVSklUU1VfUFJP
Q30tZnVqaXRzdS0ke0ZVSklUU1VfU1lTfSR7RlVKSVRTVV9SRUx9IgorCWV4aXQgOzsKKyAgICA1
MDAwOlVOSVhfU3lzdGVtX1Y6NC4qOiopCisJRlVKSVRTVV9TWVM9YHVuYW1lIC1wIHwgdHIgJ0FC
Q0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHwg
c2VkIC1lICdzL1wvLy8nYAorCUZVSklUU1VfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCB0
ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVonICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5
eicgfCBzZWQgLWUgJ3MvIC9fLydgCisJZWNobyAic3BhcmMtZnVqaXRzdS0ke0ZVSklUU1VfU1lT
fSR7RlVKSVRTVV9SRUx9IgorCWV4aXQgOzsKKyAgICBpKjg2OkJTRC8zODY6KjoqIHwgaSo4NjpC
U0QvT1M6KjoqIHwgKjpBc2NlbmRcIEVtYmVkZGVkL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tcGMtYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgc3BhcmMqOkJTRC9P
UzoqOiopCisJZWNobyBzcGFyYy11bmtub3duLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgICo6QlNEL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1ic2Rp
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOkZyZWVCU0Q6KjoqKQorCVVOQU1FX1BS
T0NFU1NPUj1gL3Vzci9iaW4vdW5hbWUgLXBgCisJY2FzZSAke1VOQU1FX1BST0NFU1NPUn0gaW4K
KwkgICAgYW1kNjQpCisJCWVjaG8geDg2XzY0LXVua25vd24tZnJlZWJzZGBlY2hvICR7VU5BTUVf
UkVMRUFTRX18c2VkIC1lICdzL1stKF0uKi8vJ2AgOzsKKwkgICAgKikKKwkJZWNobyAke1VOQU1F
X1BST0NFU1NPUn0tdW5rbm93bi1mcmVlYnNkYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvWy0oXS4qLy8nYCA7OworCWVzYWMKKwlleGl0IDs7CisgICAgaSo6Q1lHV0lOKjoqKQorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS1wYy1jeWd3aW4KKwlleGl0IDs7CisgICAgKjpNSU5HVyo6KikK
KwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbWluZ3czMgorCWV4aXQgOzsKKyAgICBpKjpNU1lT
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1tc3lzCisJZXhpdCA7OworICAgIGkqOndp
bmRvd3MzMio6KikKKwkjIHVuYW1lIC1tIGluY2x1ZGVzICItcGMiIG9uIHRoaXMgc3lzdGVtLgor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1taW5ndzMyCisJZXhpdCA7OworICAgIGkqOlBXKjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1wdzMyCisJZXhpdCA7OworICAgICo6SW50ZXJpeCo6
KikKKwljYXNlICR7VU5BTUVfTUFDSElORX0gaW4KKwkgICAgeDg2KQorCQllY2hvIGk1ODYtcGMt
aW50ZXJpeCR7VU5BTUVfUkVMRUFTRX0KKwkJZXhpdCA7OworCSAgICBhdXRoZW50aWNhbWQgfCBn
ZW51aW5laW50ZWwgfCBFTTY0VCkKKwkJZWNobyB4ODZfNjQtdW5rbm93bi1pbnRlcml4JHtVTkFN
RV9SRUxFQVNFfQorCQlleGl0IDs7CisJICAgIElBNjQpCisJCWVjaG8gaWE2NC11bmtub3duLWlu
dGVyaXgke1VOQU1FX1JFTEVBU0V9CisJCWV4aXQgOzsKKwllc2FjIDs7CisgICAgWzM0NV04NjpX
aW5kb3dzXzk1OiogfCBbMzQ1XTg2OldpbmRvd3NfOTg6KiB8IFszNDVdODY6V2luZG93c19OVDoq
KQorCWVjaG8gaSR7VU5BTUVfTUFDSElORX0tcGMtbWtzCisJZXhpdCA7OworICAgIDg2NjQ6V2lu
ZG93c19OVDoqKQorCWVjaG8geDg2XzY0LXBjLW1rcworCWV4aXQgOzsKKyAgICBpKjpXaW5kb3dz
X05UKjoqIHwgUGVudGl1bSo6V2luZG93c19OVCo6KikKKwkjIEhvdyBkbyB3ZSBrbm93IGl0J3Mg
SW50ZXJpeCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyBQT1NJWCBzdWJzeXN0ZW0/CisJIyBJdCBh
bHNvIGNvbmZsaWN0cyB3aXRoIHByZS0yLjAgdmVyc2lvbnMgb2YgQVQmVCBVV0lOLiBTaG91bGQg
d2UKKwkjIFVOQU1FX01BQ0hJTkUgYmFzZWQgb24gdGhlIG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFk
IG9mIGkzODY/CisJZWNobyBpNTg2LXBjLWludGVyaXgKKwlleGl0IDs7CisgICAgaSo6VVdJTio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtdXdpbgorCWV4aXQgOzsKKyAgICBhbWQ2NDpD
WUdXSU4qOio6KiB8IHg4Nl82NDpDWUdXSU4qOio6KikKKwllY2hvIHg4Nl82NC11bmtub3duLWN5
Z3dpbgorCWV4aXQgOzsKKyAgICBwKjpDWUdXSU4qOiopCisJZWNobyBwb3dlcnBjbGUtdW5rbm93
bi1jeWd3aW4KKwlleGl0IDs7CisgICAgcHJlcCo6U3VuT1M6NS4qOiopCisJZWNobyBwb3dlcnBj
bGUtdW5rbm93bi1zb2xhcmlzMmBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0q
Ly8nYAorCWV4aXQgOzsKKyAgICAqOkdOVToqOiopCisJIyB0aGUgR05VIHN5c3RlbQorCWVjaG8g
YGVjaG8gJHtVTkFNRV9NQUNISU5FfXxzZWQgLWUgJ3MsWy0vXS4qJCwsJ2AtdW5rbm93bi1nbnVg
ZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncywvLiokLCwnYAorCWV4aXQgOzsKKyAgICAq
OkdOVS8qOio6KikKKwkjIG90aGVyIHN5c3RlbXMgd2l0aCBHTlUgbGliYyBhbmQgdXNlcmxhbmQK
KwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1gZWNobyAke1VOQU1FX1NZU1RFTX0gfCBz
ZWQgJ3MsXlteL10qLywsJyB8IHRyICdbQS1aXScgJ1thLXpdJ2BgZWNobyAke1VOQU1FX1JFTEVB
U0V9fHNlZCAtZSAncy9bLShdLiovLydgLWdudQorCWV4aXQgOzsKKyAgICBpKjg2Ok1pbml4Oio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbWluaXgKKwlleGl0IDs7CisgICAgYWxwaGE6
TGludXg6KjoqKQorCWNhc2UgYHNlZCAtbiAnL15jcHUgbW9kZWwvcy9eLio6IFwoLipcKS9cMS9w
JyA8IC9wcm9jL2NwdWluZm9gIGluCisJICBFVjUpICAgVU5BTUVfTUFDSElORT1hbHBoYWV2NSA7
OworCSAgRVY1NikgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjU2IDs7CisJICBQQ0E1NikgVU5BTUVf
TUFDSElORT1hbHBoYXBjYTU2IDs7CisJICBQQ0E1NykgVU5BTUVfTUFDSElORT1hbHBoYXBjYTU2
IDs7CisJICBFVjYpICAgVU5BTUVfTUFDSElORT1hbHBoYWV2NiA7OworCSAgRVY2NykgIFVOQU1F
X01BQ0hJTkU9YWxwaGFldjY3IDs7CisJICBFVjY4KikgVU5BTUVfTUFDSElORT1hbHBoYWV2Njgg
OzsKKwllc2FjCisJb2JqZHVtcCAtLXByaXZhdGUtaGVhZGVycyAvYmluL3NoIHwgZ3JlcCAtcSBs
ZC5zby4xCisJaWYgdGVzdCAiJD8iID0gMCA7IHRoZW4gTElCQz0ibGliYzEiIDsgZWxzZSBMSUJD
PSIiIDsgZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUke0xJQkN9
CisJZXhpdCA7OworICAgIGFybSo6TGludXg6KjoqKQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQK
KwlpZiBlY2hvIF9fQVJNX0VBQklfXyB8ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCBc
CisJICAgIHwgZ3JlcCAtcSBfX0FSTV9FQUJJX18KKwl0aGVuCisJICAgIGVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWVsc2UKKwkgICAgaWYgZWNobyBfX0FSTV9QQ1Nf
VkZQIHwgJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsIFwKKwkJfCBncmVwIC1xIF9fQVJN
X1BDU19WRlAKKwkgICAgdGhlbgorCQllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51
eC1nbnVlYWJpCisJICAgIGVsc2UKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGlu
dXgtZ251ZWFiaWhmCisJICAgIGZpCisJZmkKKwlleGl0IDs7CisgICAgYXZyMzIqOkxpbnV4Oio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7Cisg
ICAgY3JpczpMaW51eDoqOiopCisJZWNobyBjcmlzLWF4aXMtbGludXgtZ251CisJZXhpdCA7Owor
ICAgIGNyaXN2MzI6TGludXg6KjoqKQorCWVjaG8gY3Jpc3YzMi1heGlzLWxpbnV4LWdudQorCWV4
aXQgOzsKKyAgICBmcnY6TGludXg6KjoqKQorCWVjaG8gZnJ2LXVua25vd24tbGludXgtZ251CisJ
ZXhpdCA7OworICAgIGhleGFnb246TGludXg6KjoqKQorCWVjaG8gaGV4YWdvbi11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBpKjg2OkxpbnV4Oio6KikKKwlMSUJDPWdudQorCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworCSNpZmRl
ZiBfX2RpZXRsaWJjX18KKwlMSUJDPWRpZXRsaWJjCisJI2VuZGlmCitFT0YKKwlldmFsIGAkQ0Nf
Rk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxsIHwgZ3JlcCAnXkxJQkMnYAorCWVjaG8g
IiR7VU5BTUVfTUFDSElORX0tcGMtbGludXgtJHtMSUJDfSIKKwlleGl0IDs7CisgICAgaWE2NDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhp
dCA7OworICAgIG0zMnIqOkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgbTY4KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIG1pcHM6TGludXg6Kjoq
IHwgbWlwczY0OkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14J
Ly8nIDw8IEVPRiA+JGR1bW15LmMKKwkjdW5kZWYgQ1BVCisJI3VuZGVmICR7VU5BTUVfTUFDSElO
RX0KKwkjdW5kZWYgJHtVTkFNRV9NQUNISU5FfWVsCisJI2lmIGRlZmluZWQoX19NSVBTRUxfXykg
fHwgZGVmaW5lZChfX01JUFNFTCkgfHwgZGVmaW5lZChfTUlQU0VMKSB8fCBkZWZpbmVkKE1JUFNF
TCkKKwlDUFU9JHtVTkFNRV9NQUNISU5FfWVsCisJI2Vsc2UKKwkjaWYgZGVmaW5lZChfX01JUFNF
Ql9fKSB8fCBkZWZpbmVkKF9fTUlQU0VCKSB8fCBkZWZpbmVkKF9NSVBTRUIpIHx8IGRlZmluZWQo
TUlQU0VCKQorCUNQVT0ke1VOQU1FX01BQ0hJTkV9CisJI2Vsc2UKKwlDUFU9CisJI2VuZGlmCisJ
I2VuZGlmCitFT0YKKwlldmFsIGAkQ0NfRk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxs
IHwgZ3JlcCAnXkNQVSdgCisJdGVzdCB4IiR7Q1BVfSIgIT0geCAmJiB7IGVjaG8gIiR7Q1BVfS11
bmtub3duLWxpbnV4LWdudSI7IGV4aXQ7IH0KKwk7OworICAgIG9yMzI6TGludXg6KjoqKQorCWVj
aG8gb3IzMi11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYWRyZTpMaW51eDoqOiop
CisJZWNobyBzcGFyYy11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYXJpc2M2NDpM
aW51eDoqOiogfCBocHBhNjQ6TGludXg6KjoqKQorCWVjaG8gaHBwYTY0LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHBhcmlzYzpMaW51eDoqOiogfCBocHBhOkxpbnV4Oio6KikKKwkj
IExvb2sgZm9yIENQVSBsZXZlbAorCWNhc2UgYGdyZXAgJ15jcHVbXmEtel0qOicgL3Byb2MvY3B1
aW5mbyAyPi9kZXYvbnVsbCB8IGN1dCAtZCcgJyAtZjJgIGluCisJICBQQTcqKSBlY2hvIGhwcGEx
LjEtdW5rbm93bi1saW51eC1nbnUgOzsKKwkgIFBBOCopIGVjaG8gaHBwYTIuMC11bmtub3duLWxp
bnV4LWdudSA7OworCSAgKikgICAgZWNobyBocHBhLXVua25vd24tbGludXgtZ251IDs7CisJZXNh
YworCWV4aXQgOzsKKyAgICBwcGM2NDpMaW51eDoqOiopCisJZWNobyBwb3dlcnBjNjQtdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgcHBjOkxpbnV4Oio6KikKKwllY2hvIHBvd2VycGMt
dW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgczM5MDpMaW51eDoqOiogfCBzMzkweDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LWlibS1saW51eAorCWV4aXQgOzsKKyAg
ICBzaDY0KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHNoKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9
LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHNwYXJjOkxpbnV4Oio6KiB8IHNwYXJj
NjQ6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQor
CWV4aXQgOzsKKyAgICB0aWxlKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHZheDpMaW51eDoqOiopCisJZWNobyAke1VO
QU1FX01BQ0hJTkV9LWRlYy1saW51eC1nbnUKKwlleGl0IDs7CisgICAgeDg2XzY0OkxpbnV4Oio6
KikKKwllY2hvIHg4Nl82NC11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB4dGVuc2Eq
OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwll
eGl0IDs7CisgICAgaSo4NjpEWU5JWC9wdHg6NCo6KikKKwkjIHB0eCA0LjAgZG9lcyB1bmFtZSAt
cyBjb3JyZWN0bHksIHdpdGggRFlOSVgvcHR4IGluIHRoZXJlLgorCSMgZWFybGllciB2ZXJzaW9u
cyBhcmUgbWVzc2VkIHVwIGFuZCBwdXQgdGhlIG5vZGVuYW1lIGluIGJvdGgKKwkjIHN5c25hbWUg
YW5kIG5vZGVuYW1lLgorCWVjaG8gaTM4Ni1zZXF1ZW50LXN5c3Y0CisJZXhpdCA7OworICAgIGkq
ODY6VU5JWF9TVjo0LjJNUDoyLiopCisJIyBVbml4d2FyZSBpcyBhbiBvZmZzaG9vdCBvZiBTVlI0
LCBidXQgaXQgaGFzIGl0cyBvd24gdmVyc2lvbgorCSMgbnVtYmVyIHNlcmllcyBzdGFydGluZyB3
aXRoIDIuLi4KKwkjIEkgYW0gbm90IHBvc2l0aXZlIHRoYXQgb3RoZXIgU1ZSNCBzeXN0ZW1zIHdv
bid0IG1hdGNoIHRoaXMsCisJIyBJIGp1c3QgaGF2ZSB0byBob3BlLiAgLS0gcm1zLgorCSMgVXNl
IHN5c3Y0LjJ1dy4uLiBzbyB0aGF0IHN5c3Y0KiBtYXRjaGVzIGl0LgorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1wYy1zeXN2NC4ydXcke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6
T1MvMjoqOiopCisJIyBJZiB3ZSB3ZXJlIGFibGUgdG8gZmluZCBgdW5hbWUnLCB0aGVuIEVNWCBV
bml4IGNvbXBhdGliaWxpdHkKKwkjIGlzIHByb2JhYmx5IGluc3RhbGxlZC4KKwllY2hvICR7VU5B
TUVfTUFDSElORX0tcGMtb3MyLWVteAorCWV4aXQgOzsKKyAgICBpKjg2OlhUUy0zMDA6KjpTVE9Q
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXN0b3AKKwlleGl0IDs7CisgICAgaSo4
NjphdGhlb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWF0aGVvcworCWV4
aXQgOzsKKyAgICBpKjg2OnN5bGxhYmxlOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMt
c3lsbGFibGUKKwlleGl0IDs7CisgICAgaSo4NjpMeW54T1M6Mi4qOiogfCBpKjg2Okx5bnhPUzoz
LlswMV0qOiogfCBpKjg2Okx5bnhPUzo0LlswMl0qOiopCisJZWNobyBpMzg2LXVua25vd24tbHlu
eG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBpKjg2OipET1M6KjoqKQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1wYy1tc2Rvc2RqZ3BwCisJZXhpdCA7OworICAgIGkqODY6Kjo0Lio6
KiB8IGkqODY6U1lTVEVNX1Y6NC4qOiopCisJVU5BTUVfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFT
RX0gfCBzZWQgJ3MvXC9NUCQvLydgCisJaWYgZ3JlcCBOb3ZlbGwgL3Vzci9pbmNsdWRlL2xpbmsu
aCA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11
bml2ZWwtc3lzdiR7VU5BTUVfUkVMfQorCWVsc2UKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBj
LXN5c3Yke1VOQU1FX1JFTH0KKwlmaQorCWV4aXQgOzsKKyAgICBpKjg2Oio6NTpbNjc4XSopCisJ
IyBVbml4V2FyZSA3LngsIE9wZW5VTklYIGFuZCBPcGVuU2VydmVyIDYuCisJY2FzZSBgL2Jpbi91
bmFtZSAtWCB8IGdyZXAgIl5NYWNoaW5lImAgaW4KKwkgICAgKjQ4NiopCSAgICAgVU5BTUVfTUFD
SElORT1pNDg2IDs7CisJICAgICpQZW50aXVtKQkgICAgIFVOQU1FX01BQ0hJTkU9aTU4NiA7Owor
CSAgICAqUGVudCp8KkNlbGVyb24pIFVOQU1FX01BQ0hJTkU9aTY4NiA7OworCWVzYWMKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zeXN2JHtVTkFNRV9SRUxFQVNFfSR7VU5BTUVfU1lT
VEVNfSR7VU5BTUVfVkVSU0lPTn0KKwlleGl0IDs7CisgICAgaSo4NjoqOjMuMjoqKQorCWlmIHRl
c3QgLWYgL3Vzci9vcHRpb25zL2NiLm5hbWU7IHRoZW4KKwkJVU5BTUVfUkVMPWBzZWQgLW4gJ3Mv
LipWZXJzaW9uIC8vcCcgPC91c3Ivb3B0aW9ucy9jYi5uYW1lYAorCQllY2hvICR7VU5BTUVfTUFD
SElORX0tcGMtaXNjJFVOQU1FX1JFTAorCWVsaWYgL2Jpbi91bmFtZSAtWCAyPi9kZXYvbnVsbCA+
L2Rldi9udWxsIDsgdGhlbgorCQlVTkFNRV9SRUw9YCgvYmluL3VuYW1lIC1YfGdyZXAgUmVsZWFz
ZXxzZWQgLWUgJ3MvLio9IC8vJylgCisJCSgvYmluL3VuYW1lIC1YfGdyZXAgaTgwNDg2ID4vZGV2
L251bGwpICYmIFVOQU1FX01BQ0hJTkU9aTQ4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFj
aGluZS4qUGVudGl1bScgPi9kZXYvbnVsbCkgXAorCQkJJiYgVU5BTUVfTUFDSElORT1pNTg2CisJ
CSgvYmluL3VuYW1lIC1YfGdyZXAgJ15NYWNoaW5lLipQZW50ICpJSScgPi9kZXYvbnVsbCkgXAor
CQkJJiYgVU5BTUVfTUFDSElORT1pNjg2CisJCSgvYmluL3VuYW1lIC1YfGdyZXAgJ15NYWNoaW5l
LipQZW50aXVtIFBybycgPi9kZXYvbnVsbCkgXAorCQkJJiYgVU5BTUVfTUFDSElORT1pNjg2CisJ
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1zY28kVU5BTUVfUkVMCisJZWxzZQorCQllY2hvICR7
VU5BTUVfTUFDSElORX0tcGMtc3lzdjMyCisJZmkKKwlleGl0IDs7CisgICAgcGM6KjoqOiopCisJ
IyBMZWZ0IGhlcmUgZm9yIGNvbXBhdGliaWxpdHk6CisJIyB1bmFtZSAtbSBwcmludHMgZm9yIERK
R1BQIGFsd2F5cyAncGMnLCBidXQgaXQgcHJpbnRzIG5vdGhpbmcgYWJvdXQKKwkjIHRoZSBwcm9j
ZXNzb3IsIHNvIHdlIHBsYXkgc2FmZSBieSBhc3N1bWluZyBpNTg2LgorCSMgTm90ZTogd2hhdGV2
ZXIgdGhpcyBpcywgaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB3aGF0IGNvbmZpZy5zdWIKKwkjIHBy
aW50cyBmb3IgdGhlICJkamdwcCIgaG9zdCwgb3IgZWxzZSBHREIgY29uZmlndXJ5IHdpbGwgZGVj
aWRlIHRoYXQKKwkjIHRoaXMgaXMgYSBjcm9zcy1idWlsZC4KKwllY2hvIGk1ODYtcGMtbXNkb3Nk
amdwcAorCWV4aXQgOzsKKyAgICBJbnRlbDpNYWNoOjMqOiopCisJZWNobyBpMzg2LXBjLW1hY2gz
CisJZXhpdCA7OworICAgIHBhcmFnb246KjoqOiopCisJZWNobyBpODYwLWludGVsLW9zZjEKKwll
eGl0IDs7CisgICAgaTg2MDoqOjQuKjoqKSAjIGk4NjAtU1ZSNAorCWlmIGdyZXAgU3RhcmRlbnQg
L3Vzci9pbmNsdWRlL3N5cy91YWRtaW4uaCA+L2Rldi9udWxsIDI+JjEgOyB0aGVuCisJICBlY2hv
IGk4NjAtc3RhcmRlbnQtc3lzdiR7VU5BTUVfUkVMRUFTRX0gIyBTdGFyZGVudCBWaXN0cmEgaTg2
MC1TVlI0CisJZWxzZSAjIEFkZCBvdGhlciBpODYwLVNWUjQgdmVuZG9ycyBiZWxvdyBhcyB0aGV5
IGFyZSBkaXNjb3ZlcmVkLgorCSAgZWNobyBpODYwLXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFT
RX0gICMgVW5rbm93biBpODYwLVNWUjQKKwlmaQorCWV4aXQgOzsKKyAgICBtaW5pKjpDVElYOlNZ
Uyo1OiopCisJIyAibWluaWZyYW1lIgorCWVjaG8gbTY4MDEwLWNvbnZlcmdlbnQtc3lzdgorCWV4
aXQgOzsKKyAgICBtYzY4azpVTklYOlNZU1RFTTU6My41MW0pCisJZWNobyBtNjhrLWNvbnZlcmdl
bnQtc3lzdgorCWV4aXQgOzsKKyAgICBNNjgwPzA6RC1OSVg6NS4zOiopCisJZWNobyBtNjhrLWRp
YWItZG5peAorCWV4aXQgOzsKKyAgICBNNjgqOio6UjNWWzU2NzhdKjoqKQorCXRlc3QgLXIgL3N5
c1Y2OCAmJiB7IGVjaG8gJ202OGstbW90b3JvbGEtc3lzdic7IGV4aXQ7IH0gOzsKKyAgICAzWzM0
NV0/PzoqOjQuMDozLjAgfCAzWzM0XT8/QToqOjQuMDozLjAgfCAzWzM0XT8/LCo6Kjo0LjA6My4w
IHwgM1szNF0/Py8qOio6NC4wOjMuMCB8IDQ0MDA6Kjo0LjA6My4wIHwgNDg1MDoqOjQuMDozLjAg
fCBTS0E0MDoqOjQuMDozLjAgfCBTRFMyOio6NC4wOjMuMCB8IFNIRzI6Kjo0LjA6My4wIHwgUzc1
MDEqOio6NC4wOjMuMCkKKwlPU19SRUw9JycKKwl0ZXN0IC1yIC9ldGMvLnJlbGlkIFwKKwkmJiBP
U19SRUw9LmBzZWQgLW4gJ3MvW14gXSogW14gXSogXChbMC05XVswLTldXCkuKi9cMS9wJyA8IC9l
dGMvLnJlbGlkYAorCS9iaW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCBncmVwIDg2ID4vZGV2L251
bGwgXAorCSAgJiYgeyBlY2hvIGk0ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkv
YmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIGVudGl1bSA+L2Rldi9udWxsIFwK
KwkgICYmIHsgZWNobyBpNTg2LW5jci1zeXN2NC4zJHtPU19SRUx9OyBleGl0OyB9IDs7CisgICAg
M1szNF0/PzoqOjQuMDoqIHwgM1szNF0/PywqOio6NC4wOiopCisJL2Jpbi91bmFtZSAtcCAyPi9k
ZXYvbnVsbCB8IGdyZXAgODYgPi9kZXYvbnVsbCBcCisJICAmJiB7IGVjaG8gaTQ4Ni1uY3Itc3lz
djQ7IGV4aXQ7IH0gOzsKKyAgICBOQ1IqOio6NC4yOiogfCBNUFJBUyo6Kjo0LjI6KikKKwlPU19S
RUw9Jy4zJworCXRlc3QgLXIgL2V0Yy8ucmVsaWQgXAorCSAgICAmJiBPU19SRUw9LmBzZWQgLW4g
J3MvW14gXSogW14gXSogXChbMC05XVswLTldXCkuKi9cMS9wJyA8IC9ldGMvLnJlbGlkYAorCS9i
aW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCBncmVwIDg2ID4vZGV2L251bGwgXAorCSAgICAmJiB7
IGVjaG8gaTQ4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAg
Mj4vZGV2L251bGwgfCAvYmluL2dyZXAgZW50aXVtID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVj
aG8gaTU4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAgMj4v
ZGV2L251bGwgfCAvYmluL2dyZXAgcHRlcm9uID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8g
aTU4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfSA7OworICAgIG02OCo6THlueE9TOjIu
KjoqIHwgbTY4KjpMeW54T1M6My4wKjoqKQorCWVjaG8gbTY4ay11bmtub3duLWx5bnhvcyR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgbWM2ODAzMDpVTklYX1N5c3RlbV9WOjQuKjoqKQor
CWVjaG8gbTY4ay1hdGFyaS1zeXN2NAorCWV4aXQgOzsKKyAgICBUU1VOQU1JOkx5bnhPUzoyLio6
KikKKwllY2hvIHNwYXJjLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsK
KyAgICByczYwMDA6THlueE9TOjIuKjoqKQorCWVjaG8gcnM2MDAwLXVua25vd24tbHlueG9zJHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBQb3dlclBDOkx5bnhPUzoyLio6KiB8IFBvd2Vy
UEM6THlueE9TOjMuWzAxXSo6KiB8IFBvd2VyUEM6THlueE9TOjQuWzAyXSo6KikKKwllY2hvIHBv
d2VycGMtdW5rbm93bi1seW54b3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFNNW0JF
XVM6VU5JWF9TVjoqOiopCisJZWNobyBtaXBzLWRkZS1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICBSTSo6UmVsaWFudFVOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAor
CWV4aXQgOzsKKyAgICBSTSo6U0lOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAorCWV4
aXQgOzsKKyAgICAqOlNJTklYLSo6KjoqKQorCWlmIHVuYW1lIC1wIDI+L2Rldi9udWxsID4vZGV2
L251bGwgOyB0aGVuCisJCVVOQU1FX01BQ0hJTkU9YCh1bmFtZSAtcCkgMj4vZGV2L251bGxgCisJ
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1zbmktc3lzdjQKKwllbHNlCisJCWVjaG8gbnMzMmstc25p
LXN5c3YKKwlmaQorCWV4aXQgOzsKKyAgICBQRU5USVVNOio6NC4wKjoqKQkjIFVuaXN5cyBgQ2xl
YXJQYXRoIEhNUCBJWCA0MDAwJyBTVlI0L01QIGVmZm9ydAorCQkJIyBzYXlzIDxSaWNoYXJkLk0u
QmFydGVsQGNjTWFpbC5DZW5zdXMuR09WPgorCWVjaG8gaTU4Ni11bmlzeXMtc3lzdjQKKwlleGl0
IDs7CisgICAgKjpVTklYX1N5c3RlbV9WOjQqOkZUWCopCisJIyBGcm9tIEdlcmFsZCBIZXdlcyA8
aGV3ZXNAb3Blbm1hcmtldC5jb20+LgorCSMgSG93IGFib3V0IGRpZmZlcmVudGlhdGluZyBiZXR3
ZWVuIHN0cmF0dXMgYXJjaGl0ZWN0dXJlcz8gLWRqbQorCWVjaG8gaHBwYTEuMS1zdHJhdHVzLXN5
c3Y0CisJZXhpdCA7OworICAgICo6KjoqOkZUWCopCisJIyBGcm9tIHNlYW5mQHN3ZGMuc3RyYXR1
cy5jb20uCisJZWNobyBpODYwLXN0cmF0dXMtc3lzdjQKKwlleGl0IDs7CisgICAgaSo4NjpWT1M6
KjoqKQorCSMgRnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS1zdHJhdHVzLXZvcworCWV4aXQgOzsKKyAgICAqOlZPUzoqOiopCisJIyBGcm9tIFBhdWwu
R3JlZW5Ac3RyYXR1cy5jb20uCisJZWNobyBocHBhMS4xLXN0cmF0dXMtdm9zCisJZXhpdCA7Owor
ICAgIG1jNjgqOkEvVVg6KjoqKQorCWVjaG8gbTY4ay1hcHBsZS1hdXgke1VOQU1FX1JFTEVBU0V9
CisJZXhpdCA7OworICAgIG5ld3MqOk5FV1MtT1M6Nio6KikKKwllY2hvIG1pcHMtc29ueS1uZXdz
b3M2CisJZXhpdCA7OworICAgIFJbMzRdMDAwOipTeXN0ZW1fVio6KjoqIHwgUjQwMDA6VU5JWF9T
WVNWOio6KiB8IFIqMDAwOlVOSVhfU1Y6KjoqKQorCWlmIFsgLWQgL3Vzci9uZWMgXTsgdGhlbgor
CQllY2hvIG1pcHMtbmVjLXN5c3Yke1VOQU1FX1JFTEVBU0V9CisJZWxzZQorCQllY2hvIG1pcHMt
dW5rbm93bi1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWZpCisJZXhpdCA7OworICAgIEJlQm94OkJl
T1M6KjoqKQkjIEJlT1MgcnVubmluZyBvbiBoYXJkd2FyZSBtYWRlIGJ5IEJlLCBQUEMgb25seS4K
KwllY2hvIHBvd2VycGMtYmUtYmVvcworCWV4aXQgOzsKKyAgICBCZU1hYzpCZU9TOio6KikJIyBC
ZU9TIHJ1bm5pbmcgb24gTWFjIG9yIE1hYyBjbG9uZSwgUFBDIG9ubHkuCisJZWNobyBwb3dlcnBj
LWFwcGxlLWJlb3MKKwlleGl0IDs7CisgICAgQmVQQzpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcg
b24gSW50ZWwgUEMgY29tcGF0aWJsZS4KKwllY2hvIGk1ODYtcGMtYmVvcworCWV4aXQgOzsKKyAg
ICBCZVBDOkhhaWt1Oio6KikJIyBIYWlrdSBydW5uaW5nIG9uIEludGVsIFBDIGNvbXBhdGlibGUu
CisJZWNobyBpNTg2LXBjLWhhaWt1CisJZXhpdCA7OworICAgIFNYLTQ6U1VQRVItVVg6KjoqKQor
CWVjaG8gc3g0LW5lYy1zdXBlcnV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC01
OlNVUEVSLVVYOio6KikKKwllY2hvIHN4NS1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgU1gtNjpTVVBFUi1VWDoqOiopCisJZWNobyBzeDYtbmVjLXN1cGVydXgke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFNYLTc6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g3
LW5lYy1zdXBlcnV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC04OlNVUEVSLVVY
Oio6KikKKwllY2hvIHN4OC1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7Cisg
ICAgU1gtOFI6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g4ci1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgUG93ZXIqOlJoYXBzb2R5Oio6KikKKwllY2hvIHBvd2VycGMt
YXBwbGUtcmhhcHNvZHkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6UmhhcHNvZHk6
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1hcHBsZS1yaGFwc29keSR7VU5BTUVfUkVMRUFT
RX0KKwlleGl0IDs7CisgICAgKjpEYXJ3aW46KjoqKQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUg
LXBgIHx8IFVOQU1FX1BST0NFU1NPUj11bmtub3duCisJY2FzZSAkVU5BTUVfUFJPQ0VTU09SIGlu
CisJICAgIGkzODYpCisJCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJaWYgWyAiJENDX0ZPUl9C
VUlMRCIgIT0gJ25vX2NvbXBpbGVyX2ZvdW5kJyBdOyB0aGVuCisJCSAgaWYgKGVjaG8gJyNpZmRl
ZiBfX0xQNjRfXyc7IGVjaG8gSVNfNjRCSVRfQVJDSDsgZWNobyAnI2VuZGlmJykgfCBcCisJCSAg
ICAgIChDQ09QVFM9ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCkgfCBcCisJCSAgICAg
IGdyZXAgSVNfNjRCSVRfQVJDSCA+L2Rldi9udWxsCisJCSAgdGhlbgorCQkgICAgICBVTkFNRV9Q
Uk9DRVNTT1I9Ing4Nl82NCIKKwkJICBmaQorCQlmaSA7OworCSAgICB1bmtub3duKSBVTkFNRV9Q
Uk9DRVNTT1I9cG93ZXJwYyA7OworCWVzYWMKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS1hcHBs
ZS1kYXJ3aW4ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6cHJvY250byo6KjoqIHwg
KjpRTlg6WzAxMjM0NTY3ODldKjoqKQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUgLXBgCisJaWYg
dGVzdCAiJFVOQU1FX1BST0NFU1NPUiIgPSAieDg2IjsgdGhlbgorCQlVTkFNRV9QUk9DRVNTT1I9
aTM4NgorCQlVTkFNRV9NQUNISU5FPXBjCisJZmkKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS0k
e1VOQU1FX01BQ0hJTkV9LW50by1xbngke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6
UU5YOio6NCopCisJZWNobyBpMzg2LXBjLXFueAorCWV4aXQgOzsKKyAgICBORU8tPzpOT05TVE9Q
X0tFUk5FTDoqOiopCisJZWNobyBuZW8tdGFuZGVtLW5zayR7VU5BTUVfUkVMRUFTRX0KKwlleGl0
IDs7CisgICAgTlNFLT86Tk9OU1RPUF9LRVJORUw6KjoqKQorCWVjaG8gbnNlLXRhbmRlbS1uc2sk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIE5TUi0/Ok5PTlNUT1BfS0VSTkVMOio6KikK
KwllY2hvIG5zci10YW5kZW0tbnNrJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOk5v
blN0b3AtVVg6KjoqKQorCWVjaG8gbWlwcy1jb21wYXEtbm9uc3RvcHV4CisJZXhpdCA7OworICAg
IEJTMjAwMDpQT1NJWCo6KjoqKQorCWVjaG8gYnMyMDAwLXNpZW1lbnMtc3lzdgorCWV4aXQgOzsK
KyAgICBEUy8qOlVOSVhfU3lzdGVtX1Y6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS0ke1VO
QU1FX1NZU1RFTX0tJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlBsYW45Oio6KikK
KwkjICJ1bmFtZSAtbSIgaXMgbm90IGNvbnNpc3RlbnQsIHNvIHVzZSAkY3B1dHlwZSBpbnN0ZWFk
LiAzODYKKwkjIGlzIGNvbnZlcnRlZCB0byBpMzg2IGZvciBjb25zaXN0ZW5jeSB3aXRoIG90aGVy
IHg4NgorCSMgb3BlcmF0aW5nIHN5c3RlbXMuCisJaWYgdGVzdCAiJGNwdXR5cGUiID0gIjM4NiI7
IHRoZW4KKwkgICAgVU5BTUVfTUFDSElORT1pMzg2CisJZWxzZQorCSAgICBVTkFNRV9NQUNISU5F
PSIkY3B1dHlwZSIKKwlmaQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXBsYW45CisJ
ZXhpdCA7OworICAgICo6VE9QUy0xMDoqOiopCisJZWNobyBwZHAxMC11bmtub3duLXRvcHMxMAor
CWV4aXQgOzsKKyAgICAqOlRFTkVYOio6KikKKwllY2hvIHBkcDEwLXVua25vd24tdGVuZXgKKwll
eGl0IDs7CisgICAgS1MxMDpUT1BTLTIwOio6KiB8IEtMMTA6VE9QUy0yMDoqOiogfCBUWVBFNDpU
T1BTLTIwOio6KikKKwllY2hvIHBkcDEwLWRlYy10b3BzMjAKKwlleGl0IDs7CisgICAgWEtMLTE6
VE9QUy0yMDoqOiogfCBUWVBFNTpUT1BTLTIwOio6KikKKwllY2hvIHBkcDEwLXhrbC10b3BzMjAK
KwlleGl0IDs7CisgICAgKjpUT1BTLTIwOio6KikKKwllY2hvIHBkcDEwLXVua25vd24tdG9wczIw
CisJZXhpdCA7OworICAgICo6SVRTOio6KikKKwllY2hvIHBkcDEwLXVua25vd24taXRzCisJZXhp
dCA7OworICAgIFNFSToqOio6U0VJVVgpCisJZWNobyBtaXBzLXNlaS1zZWl1eCR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgKjpEcmFnb25GbHk6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS11bmtub3duLWRyYWdvbmZseWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1st
KF0uKi8vJ2AKKwlleGl0IDs7CisgICAgKjoqVk1TOio6KikKKwlVTkFNRV9NQUNISU5FPWAodW5h
bWUgLXApIDI+L2Rldi9udWxsYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORX0iIGluCisJICAgIEEq
KSBlY2hvIGFscGhhLWRlYy12bXMgOyBleGl0IDs7CisJICAgIEkqKSBlY2hvIGlhNjQtZGVjLXZt
cyA7IGV4aXQgOzsKKwkgICAgViopIGVjaG8gdmF4LWRlYy12bXMgOyBleGl0IDs7CisJZXNhYyA7
OworICAgICo6WEVOSVg6KjpTeXNWKQorCWVjaG8gaTM4Ni1wYy14ZW5peAorCWV4aXQgOzsKKyAg
ICBpKjg2OnNreW9zOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc2t5b3NgZWNobyAk
e1VOQU1FX1JFTEVBU0V9YCB8IHNlZCAtZSAncy8gLiokLy8nCisJZXhpdCA7OworICAgIGkqODY6
cmRvczoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXJkb3MKKwlleGl0IDs7CisgICAg
aSo4NjpBUk9TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtYXJvcworCWV4aXQgOzsK
K2VzYWMKKworI2VjaG8gJyhObyB1bmFtZSBjb21tYW5kIG9yIHVuYW1lIG91dHB1dCBub3QgcmVj
b2duaXplZC4pJyAxPiYyCisjZWNobyAiJHtVTkFNRV9NQUNISU5FfToke1VOQU1FX1NZU1RFTX06
JHtVTkFNRV9SRUxFQVNFfToke1VOQU1FX1ZFUlNJT059IiAxPiYyCisKK2V2YWwgJHNldF9jY19m
b3JfYnVpbGQKK2NhdCA+JGR1bW15LmMgPDxFT0YKKyNpZmRlZiBfU0VRVUVOVF8KKyMgaW5jbHVk
ZSA8c3lzL3R5cGVzLmg+CisjIGluY2x1ZGUgPHN5cy91dHNuYW1lLmg+CisjZW5kaWYKK21haW4g
KCkKK3sKKyNpZiBkZWZpbmVkIChzb255KQorI2lmIGRlZmluZWQgKE1JUFNFQikKKyAgLyogQkZE
IHdhbnRzICJic2QiIGluc3RlYWQgb2YgIm5ld3NvcyIuICBQZXJoYXBzIEJGRCBzaG91bGQgYmUg
Y2hhbmdlZCwKKyAgICAgSSBkb24ndCBrbm93Li4uLiAgKi8KKyAgcHJpbnRmICgibWlwcy1zb255
LWJzZFxuIik7IGV4aXQgKDApOworI2Vsc2UKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyAgcHJp
bnRmICgibTY4ay1zb255LW5ld3NvcyVzXG4iLAorI2lmZGVmIE5FV1NPUzQKKwkiNCIKKyNlbHNl
CisJIiIKKyNlbmRpZgorCSk7IGV4aXQgKDApOworI2VuZGlmCisjZW5kaWYKKworI2lmIGRlZmlu
ZWQgKF9fYXJtKSAmJiBkZWZpbmVkIChfX2Fjb3JuKSAmJiBkZWZpbmVkIChfX3VuaXgpCisgIHBy
aW50ZiAoImFybS1hY29ybi1yaXNjaXhcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVm
aW5lZCAoaHAzMDApICYmICFkZWZpbmVkIChocHV4KQorICBwcmludGYgKCJtNjhrLWhwLWJzZFxu
Iik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBkZWZpbmVkIChOZVhUKQorI2lmICFkZWZpbmVk
IChfX0FSQ0hJVEVDVFVSRV9fKQorI2RlZmluZSBfX0FSQ0hJVEVDVFVSRV9fICJtNjhrIgorI2Vu
ZGlmCisgIGludCB2ZXJzaW9uOworICB2ZXJzaW9uPWAoaG9zdGluZm8gfCBzZWQgLW4gJ3MvLipO
ZVhUIE1hY2ggXChbMC05XSpcKS4qL1wxL3AnKSAyPi9kZXYvbnVsbGA7CisgIGlmICh2ZXJzaW9u
IDwgNCkKKyAgICBwcmludGYgKCIlcy1uZXh0LW5leHRzdGVwJWRcbiIsIF9fQVJDSElURUNUVVJF
X18sIHZlcnNpb24pOworICBlbHNlCisgICAgcHJpbnRmICgiJXMtbmV4dC1vcGVuc3RlcCVkXG4i
LCBfX0FSQ0hJVEVDVFVSRV9fLCB2ZXJzaW9uKTsKKyAgZXhpdCAoMCk7CisjZW5kaWYKKworI2lm
IGRlZmluZWQgKE1VTFRJTUFYKSB8fCBkZWZpbmVkIChuMTYpCisjaWYgZGVmaW5lZCAoVU1BWFYp
CisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1zeXN2XG4iKTsgZXhpdCAoMCk7CisjZWxzZQorI2lm
IGRlZmluZWQgKENNVSkKKyAgcHJpbnRmICgibnMzMmstZW5jb3JlLW1hY2hcbiIpOyBleGl0ICgw
KTsKKyNlbHNlCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1ic2RcbiIpOyBleGl0ICgwKTsKKyNl
bmRpZgorI2VuZGlmCisjZW5kaWYKKworI2lmIGRlZmluZWQgKF9fMzg2QlNEX18pCisgIHByaW50
ZiAoImkzODYtcGMtYnNkXG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKworI2lmIGRlZmluZWQgKHNl
cXVlbnQpCisjaWYgZGVmaW5lZCAoaTM4NikKKyAgcHJpbnRmICgiaTM4Ni1zZXF1ZW50LWR5bml4
XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNpZiBkZWZpbmVkIChuczMyMDAwKQorICBwcmludGYg
KCJuczMyay1zZXF1ZW50LWR5bml4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNlbmRpZgorCisj
aWYgZGVmaW5lZCAoX1NFUVVFTlRfKQorICAgIHN0cnVjdCB1dHNuYW1lIHVuOworCisgICAgdW5h
bWUoJnVuKTsKKworICAgIGlmIChzdHJuY21wKHVuLnZlcnNpb24sICJWMiIsIDIpID09IDApIHsK
KwlwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4MlxuIik7IGV4aXQgKDApOworICAgIH0KKyAgICBp
ZiAoc3RybmNtcCh1bi52ZXJzaW9uLCAiVjEiLCAyKSA9PSAwKSB7IC8qIFhYWCBpcyBWMSBjb3Jy
ZWN0PyAqLworCXByaW50ZiAoImkzODYtc2VxdWVudC1wdHgxXG4iKTsgZXhpdCAoMCk7CisgICAg
fQorICAgIHByaW50ZiAoImkzODYtc2VxdWVudC1wdHhcbiIpOyBleGl0ICgwKTsKKworI2VuZGlm
CisKKyNpZiBkZWZpbmVkICh2YXgpCisjIGlmICFkZWZpbmVkICh1bHRyaXgpCisjICBpbmNsdWRl
IDxzeXMvcGFyYW0uaD4KKyMgIGlmIGRlZmluZWQgKEJTRCkKKyMgICBpZiBCU0QgPT0gNDMKKyAg
ICAgIHByaW50ZiAoInZheC1kZWMtYnNkNC4zXG4iKTsgZXhpdCAoMCk7CisjICAgZWxzZQorIyAg
ICBpZiBCU0QgPT0gMTk5MDA2CisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZDQuM3Jlbm9cbiIp
OyBleGl0ICgwKTsKKyMgICAgZWxzZQorICAgICAgcHJpbnRmICgidmF4LWRlYy1ic2RcbiIpOyBl
eGl0ICgwKTsKKyMgICAgZW5kaWYKKyMgICBlbmRpZgorIyAgZWxzZQorICAgIHByaW50ZiAoInZh
eC1kZWMtYnNkXG4iKTsgZXhpdCAoMCk7CisjICBlbmRpZgorIyBlbHNlCisgICAgcHJpbnRmICgi
dmF4LWRlYy11bHRyaXhcbiIpOyBleGl0ICgwKTsKKyMgZW5kaWYKKyNlbmRpZgorCisjaWYgZGVm
aW5lZCAoYWxsaWFudCkgJiYgZGVmaW5lZCAoaTg2MCkKKyAgcHJpbnRmICgiaTg2MC1hbGxpYW50
LWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyAgZXhpdCAoMSk7Cit9CitFT0YKKworJEND
X0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgMj4vZGV2L251bGwgJiYgU1lTVEVNX05BTUU9
YCRkdW1teWAgJiYKKwl7IGVjaG8gIiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKworIyBBcG9sbG9z
IHB1dCB0aGUgc3lzdGVtIHR5cGUgaW4gdGhlIGVudmlyb25tZW50LgorCit0ZXN0IC1kIC91c3Iv
YXBvbGxvICYmIHsgZWNobyAke0lTUH0tYXBvbGxvLSR7U1lTVFlQRX07IGV4aXQ7IH0KKworIyBD
b252ZXggdmVyc2lvbnMgdGhhdCBwcmVkYXRlIHVuYW1lIGNhbiB1c2UgZ2V0c3lzaW5mbygxKQor
CitpZiBbIC14IC91c3IvY29udmV4L2dldHN5c2luZm8gXQordGhlbgorICAgIGNhc2UgYGdldHN5
c2luZm8gLWYgY3B1X3R5cGVgIGluCisgICAgYzEqKQorCWVjaG8gYzEtY29udmV4LWJzZAorCWV4
aXQgOzsKKyAgICBjMiopCisJaWYgZ2V0c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhlbiBlY2hv
IGMzMi1jb252ZXgtYnNkCisJZWxzZSBlY2hvIGMyLWNvbnZleC1ic2QKKwlmaQorCWV4aXQgOzsK
KyAgICBjMzQqKQorCWVjaG8gYzM0LWNvbnZleC1ic2QKKwlleGl0IDs7CisgICAgYzM4KikKKwll
Y2hvIGMzOC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGM0KikKKwllY2hvIGM0LWNvbnZleC1i
c2QKKwlleGl0IDs7CisgICAgZXNhYworZmkKKworY2F0ID4mMiA8PEVPRgorJDA6IHVuYWJsZSB0
byBndWVzcyBzeXN0ZW0gdHlwZQorCitUaGlzIHNjcmlwdCwgbGFzdCBtb2RpZmllZCAkdGltZXN0
YW1wLCBoYXMgZmFpbGVkIHRvIHJlY29nbml6ZQordGhlIG9wZXJhdGluZyBzeXN0ZW0geW91IGFy
ZSB1c2luZy4gSXQgaXMgYWR2aXNlZCB0aGF0IHlvdQorZG93bmxvYWQgdGhlIG1vc3QgdXAgdG8g
ZGF0ZSB2ZXJzaW9uIG9mIHRoZSBjb25maWcgc2NyaXB0cyBmcm9tCisKKyAgaHR0cDovL2dpdC5z
YXZhbm5haC5nbnUub3JnL2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZp
Zy5ndWVzcztoYj1IRUFECithbmQKKyAgaHR0cDovL2dpdC5zYXZhbm5haC5nbnUub3JnL2dpdHdl
Yi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZpZy5zdWI7aGI9SEVBRAorCitJZiB0
aGUgdmVyc2lvbiB5b3UgcnVuICgkMCkgaXMgYWxyZWFkeSB1cCB0byBkYXRlLCBwbGVhc2UKK3Nl
bmQgdGhlIGZvbGxvd2luZyBkYXRhIGFuZCBhbnkgaW5mb3JtYXRpb24geW91IHRoaW5rIG1pZ2h0
IGJlCitwZXJ0aW5lbnQgdG8gPGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+IGluIG9yZGVyIHRvIHBy
b3ZpZGUgdGhlIG5lZWRlZAoraW5mb3JtYXRpb24gdG8gaGFuZGxlIHlvdXIgc3lzdGVtLgorCitj
b25maWcuZ3Vlc3MgdGltZXN0YW1wID0gJHRpbWVzdGFtcAorCit1bmFtZSAtbSA9IGAodW5hbWUg
LW0pIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1yID0gYCh1bmFtZSAtcikg
Mj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXMgPSBgKHVuYW1lIC1zKSAyPi9k
ZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtdiA9IGAodW5hbWUgLXYpIDI+L2Rldi9u
dWxsIHx8IGVjaG8gdW5rbm93bmAKKworL3Vzci9iaW4vdW5hbWUgLXAgPSBgKC91c3IvYmluL3Vu
YW1lIC1wKSAyPi9kZXYvbnVsbGAKKy9iaW4vdW5hbWUgLVggICAgID0gYCgvYmluL3VuYW1lIC1Y
KSAyPi9kZXYvbnVsbGAKKworaG9zdGluZm8gICAgICAgICAgICAgICA9IGAoaG9zdGluZm8pIDI+
L2Rldi9udWxsYAorL2Jpbi91bml2ZXJzZSAgICAgICAgICA9IGAoL2Jpbi91bml2ZXJzZSkgMj4v
ZGV2L251bGxgCisvdXNyL2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jpbi9hcmNoIC1rKSAy
Pi9kZXYvbnVsbGAKKy9iaW4vYXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkgMj4vZGV2
L251bGxgCisvdXNyL2Jpbi9vc2xldmVsICAgICAgID0gYCgvdXNyL2Jpbi9vc2xldmVsKSAyPi9k
ZXYvbnVsbGAKKy91c3IvY29udmV4L2dldHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dldHN5c2lu
Zm8pIDI+L2Rldi9udWxsYAorCitVTkFNRV9NQUNISU5FID0gJHtVTkFNRV9NQUNISU5FfQorVU5B
TUVfUkVMRUFTRSA9ICR7VU5BTUVfUkVMRUFTRX0KK1VOQU1FX1NZU1RFTSAgPSAke1VOQU1FX1NZ
U1RFTX0KK1VOQU1FX1ZFUlNJT04gPSAke1VOQU1FX1ZFUlNJT059CitFT0YKKworZXhpdCAxCisK
KyMgTG9jYWwgdmFyaWFibGVzOgorIyBldmFsOiAoYWRkLWhvb2sgJ3dyaXRlLWZpbGUtaG9va3Mg
J3RpbWUtc3RhbXApCisjIHRpbWUtc3RhbXAtc3RhcnQ6ICJ0aW1lc3RhbXA9JyIKKyMgdGltZS1z
dGFtcC1mb3JtYXQ6ICIlOnktJTAybS0lMDJkIgorIyB0aW1lLXN0YW1wLWVuZDogIiciCisjIEVu
ZDoKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NvbmZpZy5oLmlu
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L2NvbmZpZy5oLmluCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDQ2
OCBAQAorLyogY29uZmlnLmguaW4uICBHZW5lcmF0ZWQgZnJvbSBjb25maWd1cmUuYWMgYnkgYXV0
b2hlYWRlci4gICovCisKKy8qIERlZmluZSB0byBvbmUgb2YgYF9nZXRiNjcnLCBgR0VUQjY3Jywg
YGdldGI2NycgZm9yIENyYXktMiBhbmQgQ3JheS1ZTVAKKyAgIHN5c3RlbXMuIFRoaXMgZnVuY3Rp
b24gaXMgcmVxdWlyZWQgZm9yIGBhbGxvY2EuYycgc3VwcG9ydCBvbiB0aG9zZSBzeXN0ZW1zLgor
ICAgKi8KKyN1bmRlZiBDUkFZX1NUQUNLU0VHX0VORAorCisvKiBEZWZpbmUgdG8gMSBpZiB1c2lu
ZyBgYWxsb2NhLmMnLiAqLworI3VuZGVmIENfQUxMT0NBCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgYWxhcm0nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQUxBUk0KKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgYGFsbG9jYScsIGFzIGEgZnVuY3Rpb24gb3IgbWFjcm8u
ICovCisjdW5kZWYgSEFWRV9BTExPQ0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgPGFs
bG9jYS5oPiBhbmQgaXQgc2hvdWxkIGJlIHVzZWQgKG5vdCBvbiBVbHRyaXgpLgorICAgKi8KKyN1
bmRlZiBIQVZFX0FMTE9DQV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8YXJw
YS9pbmV0Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfQVJQQV9JTkVUX0gKKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBhdGV4aXQnIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfQVRFWElUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgYnplcm8nIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQlpFUk8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIGBjbG9ja19nZXR0aW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0NMT0NLX0dF
VFRJTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBkdXAyJyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX0RVUDIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxm
Y250bC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0ZDTlRMX0gKKworLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmZGF0YXN5bmMnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfRkRBVEFTWU5DCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZm9yaycgZnVu
Y3Rpb24uICovCisjdW5kZWYgSEFWRV9GT1JLCisKKy8qIERlZmluZSB0byAxIGlmIGZzZWVrbyAo
YW5kIHByZXN1bWFibHkgZnRlbGxvKSBleGlzdHMgYW5kIGlzIGRlY2xhcmVkLiAqLworI3VuZGVm
IEhBVkVfRlNFRUtPCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZnRydW5jYXRl
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0ZUUlVOQ0FURQorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYGdldGN3ZCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRDV0QK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRob3N0YnluYW1lJyBmdW5jdGlv
bi4gKi8KKyN1bmRlZiBIQVZFX0dFVEhPU1RCWU5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBnZXRob3N0bmFtZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRIT1NU
TkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldHBhZ2VzaXplJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVFBBR0VTSVpFCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgZ2V0dGltZW9mZGF5JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVFRJ
TUVPRkRBWQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGluZXRfbnRvYScgZnVu
Y3Rpb24uICovCisjdW5kZWYgSEFWRV9JTkVUX05UT0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0lOVFRZ
UEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBpc2FzY2lpJyBmdW5jdGlv
bi4gKi8KKyN1bmRlZiBIQVZFX0lTQVNDSUkKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBjcnlwdG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KKyN1bmRlZiBIQVZFX0xJQkNSWVBU
TworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpYmludGwuaD4gaGVhZGVyIGZp
bGUuICovCisjdW5kZWYgSEFWRV9MSUJJTlRMX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIGBydCcgbGlicmFyeSAoLWxydCkuICovCisjdW5kZWYgSEFWRV9MSUJSVAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHV1aWQnIGxpYnJhcnkgKC1sdXVpZCkuICovCisj
dW5kZWYgSEFWRV9MSUJVVUlECisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgeWFq
bCcgbGlicmFyeSAoLWx5YWpsKS4gKi8KKyN1bmRlZiBIQVZFX0xJQllBSkwKKworLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIGB6JyBsaWJyYXJ5ICgtbHopLiAqLworI3VuZGVmIEhBVkVf
TElCWgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpbWl0cy5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0xJTUlUU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgbG9jYWx0aW1lX3InIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTE9DQUxUSU1F
X1IKKworLyogRGVmaW5lIHRvIDEgaWYgeW91ciBzeXN0ZW0gaGFzIGEgR05VIGxpYmMgY29tcGF0
aWJsZSBgbWFsbG9jJyBmdW5jdGlvbiwgYW5kCisgICB0byAwIG90aGVyd2lzZS4gKi8KKyN1bmRl
ZiBIQVZFX01BTExPQworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG1hbGxvYy5o
PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01BTExPQ19ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgbWVtY2hyJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01FTUNI
UgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbW1vdmUnIGZ1bmN0aW9uLiAq
LworI3VuZGVmIEhBVkVfTUVNTU9WRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
PG1lbW9yeS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01FTU9SWV9ICisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtc2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBI
QVZFX01FTVNFVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1rZGlyJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRElSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZl
IHRoZSBgbWtmaWZvJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRklGTworCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3UgaGF2ZSBhIHdvcmtpbmcgYG1tYXAnIHN5c3RlbSBjYWxsLiAqLworI3Vu
ZGVmIEhBVkVfTU1BUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG11bm1hcCcg
ZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NVU5NQVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxuZXRkYi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX05FVERCX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxuZXRpbmV0L2luLmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfTkVUSU5FVF9JTl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgcGF0aGNvbmYnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUEFUSENPTkYK
KworLyogRGVmaW5lIHRvIDEgaWYgdGhlIHN5c3RlbSBoYXMgdGhlIHR5cGUgYHB0cmRpZmZfdCcu
ICovCisjdW5kZWYgSEFWRV9QVFJESUZGX1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91ciBzeXN0
ZW0gaGFzIGEgR05VIGxpYmMgY29tcGF0aWJsZSBgcmVhbGxvYycgZnVuY3Rpb24sCisgICBhbmQg
dG8gMCBvdGhlcndpc2UuICovCisjdW5kZWYgSEFWRV9SRUFMTE9DCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgcmVhbHBhdGgnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUkVB
TFBBVEgKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGByZWdjb21wJyBmdW5jdGlv
bi4gKi8KKyN1bmRlZiBIQVZFX1JFR0NPTVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBybWRpcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9STURJUgorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHNlbGVjdCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9T
RUxFQ1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzZXRlbnYnIGZ1bmN0aW9u
LiAqLworI3VuZGVmIEhBVkVfU0VURU5WCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgc29ja2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NPQ0tFVAorCisvKiBEZWZpbmUg
dG8gMSBpZiBzdGRib29sLmggY29uZm9ybXMgdG8gQzk5LiAqLworI3VuZGVmIEhBVkVfU1REQk9P
TF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkZGVmLmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfU1REREVGX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzdGRpbnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERJTlRfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGxpYi5oPiBoZWFkZXIgZmlsZS4g
Ki8KKyN1bmRlZiBIQVZFX1NURExJQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgc3RyY2FzZWNtcCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJDQVNFQ01QCisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyY2hyJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1NUUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmNzcG4n
IGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ1NQTgorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgYHN0cmR1cCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJEVVAKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJlcnJvcicgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9TVFJFUlJPUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0
cmluZ3MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVFJJTkdTX0gKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdHJpbmcuaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9TVFJJTkdfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cm5k
dXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSTkRVUAorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYHN0cnBicmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSUEJS
SworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnJjaHInIGZ1bmN0aW9uLiAq
LworI3VuZGVmIEhBVkVfU1RSUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHN0cnNwbicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJTUE4KKworLyogRGVmaW5lIHRv
IDEgaWYgeW91IGhhdmUgdGhlIGBzdHJzdHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RS
U1RSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RydG9sJyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX1NUUlRPTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHN0cnRvdWwnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSVE9VTAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnRvdWxsJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X1NUUlRPVUxMCisKKy8qIERlZmluZSB0byAxIGlmIGBzdF9ibGtzaXplJyBpcyBhIG1lbWJlciBv
ZiBgc3RydWN0IHN0YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxLU0laRQor
CisvKiBEZWZpbmUgdG8gMSBpZiBgc3RfYmxvY2tzJyBpcyBhIG1lbWJlciBvZiBgc3RydWN0IHN0
YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTCisKKy8qIERlZmluZSB0
byAxIGlmIGBzdF9yZGV2JyBpcyBhIG1lbWJlciBvZiBgc3RydWN0IHN0YXQnLiAqLworI3VuZGVm
IEhBVkVfU1RSVUNUX1NUQVRfU1RfUkRFVgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3VyIGBzdHJ1
Y3Qgc3RhdCcgaGFzIGBzdF9ibG9ja3MnLiBEZXByZWNhdGVkLCB1c2UKKyAgIGBIQVZFX1NUUlVD
VF9TVEFUX1NUX0JMT0NLUycgaW5zdGVhZC4gKi8KKyN1bmRlZiBIQVZFX1NUX0JMT0NLUworCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5c2xvZy5oPiBoZWFkZXIgZmlsZS4gKi8K
KyN1bmRlZiBIQVZFX1NZU0xPR19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8
c3lzL2ZpbGUuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfRklMRV9ICisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL2lvY3RsLmg+IGhlYWRlciBmaWxlLiAq
LworI3VuZGVmIEhBVkVfU1lTX0lPQ1RMX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDxzeXMvbW91bnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfTU9VTlRf
SAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9wYXJhbS5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19QQVJBTV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSA8c3lzL3NvY2tldC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZ
U19TT0NLRVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0dmZz
Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1NUQVRWRlNfSAorCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0Lmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfU1lTX1NUQVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5
cy90aW1lLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1RJTUVfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy90eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8K
KyN1bmRlZiBIQVZFX1NZU19UWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSA8dGVybWlvcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1RFUk1JT1NfSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHR6c2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1RaU0VUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgdW5hbWUnIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVU5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDx1bmlzdGQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9VTklTVERfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHZmb3JrJyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX1ZGT1JLCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8dmZvcmsu
aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9WRk9SS19ICisKKy8qIERlZmluZSB0byAx
IGlmIGBmb3JrJyB3b3Jrcy4gKi8KKyN1bmRlZiBIQVZFX1dPUktJTkdfRk9SSworCisvKiBEZWZp
bmUgdG8gMSBpZiBgdmZvcmsnIHdvcmtzLiAqLworI3VuZGVmIEhBVkVfV09SS0lOR19WRk9SSwor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAorCisvKiBEZWZp
bmUgdG8gMSBpZiB0aGUgc3lzdGVtIGhhcyB0aGUgdHlwZSBgX0Jvb2wnLiAqLworI3VuZGVmIEhB
VkVfX0JPT0wKKworLyogRGVmaW5lIHRvIDEgaWYgYGxzdGF0JyBkZXJlZmVyZW5jZXMgYSBzeW1s
aW5rIHNwZWNpZmllZCB3aXRoIGEgdHJhaWxpbmcKKyAgIHNsYXNoLiAqLworI3VuZGVmIExTVEFU
X0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCisKKy8qIERlZmluZSB0byAxIGlmIGBtYWpvcicsIGBt
aW5vcicsIGFuZCBgbWFrZWRldicgYXJlIGRlY2xhcmVkIGluIDxta2Rldi5oPi4KKyAgICovCisj
dW5kZWYgTUFKT1JfSU5fTUtERVYKKworLyogRGVmaW5lIHRvIDEgaWYgYG1ham9yJywgYG1pbm9y
JywgYW5kIGBtYWtlZGV2JyBhcmUgZGVjbGFyZWQgaW4KKyAgIDxzeXNtYWNyb3MuaD4uICovCisj
dW5kZWYgTUFKT1JfSU5fU1lTTUFDUk9TCisKKy8qIERlZmluZSB0byB0aGUgYWRkcmVzcyB3aGVy
ZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLworI3VuZGVm
IFBBQ0tBR0VfQlVHUkVQT1JUCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1lIG9mIHRoaXMg
cGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX05BTUUKKworLyogRGVmaW5lIHRvIHRoZSBmdWxs
IG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfU1RS
SU5HCisKKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBzaG9ydCBuYW1lIG9mIHRoaXMgcGFj
a2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1RBUk5BTUUKKworLyogRGVmaW5lIHRvIHRoZSBob21l
IHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1VSTAorCisvKiBEZWZp
bmUgdG8gdGhlIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfVkVS
U0lPTgorCisvKiBJZiB1c2luZyB0aGUgQyBpbXBsZW1lbnRhdGlvbiBvZiBhbGxvY2EsIGRlZmlu
ZSBpZiB5b3Uga25vdyB0aGUKKyAgIGRpcmVjdGlvbiBvZiBzdGFjayBncm93dGggZm9yIHlvdXIg
c3lzdGVtOyBvdGhlcndpc2UgaXQgd2lsbCBiZQorICAgYXV0b21hdGljYWxseSBkZWR1Y2VkIGF0
IHJ1bnRpbWUuCisJU1RBQ0tfRElSRUNUSU9OID4gMCA9PiBncm93cyB0b3dhcmQgaGlnaGVyIGFk
ZHJlc3NlcworCVNUQUNLX0RJUkVDVElPTiA8IDAgPT4gZ3Jvd3MgdG93YXJkIGxvd2VyIGFkZHJl
c3NlcworCVNUQUNLX0RJUkVDVElPTiA9IDAgPT4gZGlyZWN0aW9uIG9mIGdyb3d0aCB1bmtub3du
ICovCisjdW5kZWYgU1RBQ0tfRElSRUNUSU9OCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZl
IHRoZSBBTlNJIEMgaGVhZGVyIGZpbGVzLiAqLworI3VuZGVmIFNURENfSEVBREVSUworCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgY2FuIHNhZmVseSBpbmNsdWRlIGJvdGggPHN5cy90aW1lLmg+IGFu
ZCA8dGltZS5oPi4gKi8KKyN1bmRlZiBUSU1FX1dJVEhfU1lTX1RJTUUKKworLyogRW5hYmxlIGV4
dGVuc2lvbnMgb24gQUlYIDMsIEludGVyaXguICAqLworI2lmbmRlZiBfQUxMX1NPVVJDRQorIyB1
bmRlZiBfQUxMX1NPVVJDRQorI2VuZGlmCisvKiBFbmFibGUgR05VIGV4dGVuc2lvbnMgb24gc3lz
dGVtcyB0aGF0IGhhdmUgdGhlbS4gICovCisjaWZuZGVmIF9HTlVfU09VUkNFCisjIHVuZGVmIF9H
TlVfU09VUkNFCisjZW5kaWYKKy8qIEVuYWJsZSB0aHJlYWRpbmcgZXh0ZW5zaW9ucyBvbiBTb2xh
cmlzLiAgKi8KKyNpZm5kZWYgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTCisjIHVuZGVmIF9QT1NJ
WF9QVEhSRUFEX1NFTUFOVElDUworI2VuZGlmCisvKiBFbmFibGUgZXh0ZW5zaW9ucyBvbiBIUCBO
b25TdG9wLiAgKi8KKyNpZm5kZWYgX1RBTkRFTV9TT1VSQ0UKKyMgdW5kZWYgX1RBTkRFTV9TT1VS
Q0UKKyNlbmRpZgorLyogRW5hYmxlIGdlbmVyYWwgZXh0ZW5zaW9ucyBvbiBTb2xhcmlzLiAgKi8K
KyNpZm5kZWYgX19FWFRFTlNJT05TX18KKyMgdW5kZWYgX19FWFRFTlNJT05TX18KKyNlbmRpZgor
CisKKy8qIERlZmluZSB0byAxIHRvIG1ha2UgZnNlZWtvIHZpc2libGUgb24gc29tZSBob3N0cyAo
ZS5nLiBnbGliYyAyLjIpLiAqLworI3VuZGVmIF9MQVJHRUZJTEVfU09VUkNFCisKKy8qIERlZmlu
ZSB0byAxIGlmIG9uIE1JTklYLiAqLworI3VuZGVmIF9NSU5JWAorCisvKiBEZWZpbmUgdG8gMiBp
ZiB0aGUgc3lzdGVtIGRvZXMgbm90IHByb3ZpZGUgUE9TSVguMSBmZWF0dXJlcyBleGNlcHQgd2l0
aAorICAgdGhpcyBkZWZpbmVkLiAqLworI3VuZGVmIF9QT1NJWF8xX1NPVVJDRQorCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3UgbmVlZCB0byBpbiBvcmRlciBmb3IgYHN0YXQnIGFuZCBvdGhlciB0aGlu
Z3MgdG8gd29yay4gKi8KKyN1bmRlZiBfUE9TSVhfU09VUkNFCisKKy8qIERlZmluZSBmb3IgU29s
YXJpcyAyLjUuMSBzbyB0aGUgdWludDMyX3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisg
ICA8cHRocmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVk
ZWYgd2VyZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50
YXggZXJyb3IuICovCisjdW5kZWYgX1VJTlQzMl9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAy
LjUuMSBzbyB0aGUgdWludDY0X3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisgICA8cHRo
cmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVkZWYgd2Vy
ZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50YXggZXJy
b3IuICovCisjdW5kZWYgX1VJTlQ2NF9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAyLjUuMSBz
byB0aGUgdWludDhfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+
LCBvciA8c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93
ZWQsIHRoZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8K
KyN1bmRlZiBfVUlOVDhfVAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBk
b2Vzbid0IGRlZmluZS4gKi8KKyN1bmRlZiBnaWRfdAorCisvKiBEZWZpbmUgdG8gYF9faW5saW5l
X18nIG9yIGBfX2lubGluZScgaWYgdGhhdCdzIHdoYXQgdGhlIEMgY29tcGlsZXIKKyAgIGNhbGxz
IGl0LCBvciB0byBub3RoaW5nIGlmICdpbmxpbmUnIGlzIG5vdCBzdXBwb3J0ZWQgdW5kZXIgYW55
IG5hbWUuICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cworI3VuZGVmIGlubGluZQorI2VuZGlmCisK
Ky8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGgg
ZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFy
ZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIGludDE2X3QKKworLyogRGVm
aW5lIHRvIHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5
IDMyIGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1
ZGVzIGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MzJfdAorCisvKiBEZWZpbmUgdG8g
dGhlIHR5cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkgNjQgYml0
cyBpZgorICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8g
bm90IGRlZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQ2NF90CisKKy8qIERlZmluZSB0byB0aGUgdHlw
ZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMgaWYgc3Vj
aAorICAgYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5vdCBkZWZp
bmUgaXQuICovCisjdW5kZWYgaW50OF90CisKKy8qIERlZmluZSB0byBycGxfbWFsbG9jIGlmIHRo
ZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiBtYWxsb2MK
KworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVmaW5lLiAq
LworI3VuZGVmIG1vZGVfdAorCisvKiBEZWZpbmUgdG8gYGxvbmcgaW50JyBpZiA8c3lzL3R5cGVz
Lmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBvZmZfdAorCisvKiBEZWZpbmUgdG8gYGlu
dCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgcGlkX3QKKwor
LyogRGVmaW5lIHRvIHJwbF9yZWFsbG9jIGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91
bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiByZWFsbG9jCisKKy8qIERlZmluZSB0byB0aGUgZXF1aXZh
bGVudCBvZiB0aGUgQzk5ICdyZXN0cmljdCcga2V5d29yZCwgb3IgdG8KKyAgIG5vdGhpbmcgaWYg
dGhpcyBpcyBub3Qgc3VwcG9ydGVkLiAgRG8gbm90IGRlZmluZSBpZiByZXN0cmljdCBpcworICAg
c3VwcG9ydGVkIGRpcmVjdGx5LiAgKi8KKyN1bmRlZiByZXN0cmljdAorLyogV29yayBhcm91bmQg
YSBidWcgaW4gU3VuIEMrKzogaXQgZG9lcyBub3Qgc3VwcG9ydCBfUmVzdHJpY3Qgb3IKKyAgIF9f
cmVzdHJpY3RfXywgZXZlbiB0aG91Z2ggdGhlIGNvcnJlc3BvbmRpbmcgU3VuIEMgY29tcGlsZXIg
ZW5kcyB1cCB3aXRoCisgICAiI2RlZmluZSByZXN0cmljdCBfUmVzdHJpY3QiIG9yICIjZGVmaW5l
IHJlc3RyaWN0IF9fcmVzdHJpY3RfXyIgaW4gdGhlCisgICBwcmV2aW91cyBsaW5lLiAgUGVyaGFw
cyBzb21lIGZ1dHVyZSB2ZXJzaW9uIG9mIFN1biBDKysgd2lsbCB3b3JrIHdpdGgKKyAgIHJlc3Ry
aWN0OyBpZiBzbywgaG9wZWZ1bGx5IGl0IGRlZmluZXMgX19SRVNUUklDVCBsaWtlIFN1biBDIGRv
ZXMuICAqLworI2lmIGRlZmluZWQgX19TVU5QUk9fQ0MgJiYgIWRlZmluZWQgX19SRVNUUklDVAor
IyBkZWZpbmUgX1Jlc3RyaWN0CisjIGRlZmluZSBfX3Jlc3RyaWN0X18KKyNlbmRpZgorCisvKiBE
ZWZpbmUgdG8gYHVuc2lnbmVkIGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUu
ICovCisjdW5kZWYgc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+
IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBzc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50
JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5lLiAqLworI3VuZGVmIHVpZF90CisKKy8q
IERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGgg
ZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFy
ZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQxNl90CisKKy8qIERl
ZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhh
Y3RseSAzMiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBp
bmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQzMl90CisKKy8qIERlZmlu
ZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3Rs
eSA2NCBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNs
dWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQ2NF90CisKKy8qIERlZmluZSB0
byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4
IGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVz
IGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDhfdAorCisvKiBEZWZpbmUgYXMgYGZv
cmsnIGlmIGB2Zm9yaycgZG9lcyBub3Qgd29yay4gKi8KKyN1bmRlZiB2Zm9yawpkaWZmIC1yIGUy
NzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY29uZmlnLnN1YgotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuc3ViCVdl
ZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDE3NzEgQEAKKyMhIC9iaW4v
c2gKKyMgQ29uZmlndXJhdGlvbiB2YWxpZGF0aW9uIHN1YnJvdXRpbmUgc2NyaXB0LgorIyAgIENv
cHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5
OSwKKyMgICAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAy
MDA4LCAyMDA5LCAyMDEwLAorIyAgIDIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMu
CisKK3RpbWVzdGFtcD0nMjAxMS0xMS0xMScKKworIyBUaGlzIGZpbGUgaXMgKGluIHByaW5jaXBs
ZSkgY29tbW9uIHRvIEFMTCBHTlUgc29mdHdhcmUuCisjIFRoZSBwcmVzZW5jZSBvZiBhIG1hY2hp
bmUgaW4gdGhpcyBmaWxlIHN1Z2dlc3RzIHRoYXQgU09NRSBHTlUgc29mdHdhcmUKKyMgY2FuIGhh
bmRsZSB0aGF0IG1hY2hpbmUuICBJdCBkb2VzIG5vdCBpbXBseSBBTEwgR05VIHNvZnR3YXJlIGNh
bi4KKyMKKyMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIg
b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1
dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisjIGJ1dCBXSVRIT1VUIEFO
WSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNI
QU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUK
KyMgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91
IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UKKyMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZy
ZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3RyZWV0IC0gRmlm
dGggRmxvb3IsIEJvc3RvbiwgTUEKKyMgMDIxMTAtMTMwMSwgVVNBLgorIworIyBBcyBhIHNwZWNp
YWwgZXhjZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91Cisj
IGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMg
YQorIyBjb25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkg
aW5jbHVkZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3Ug
dXNlIGZvciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKworIyBQbGVhc2Ugc2VuZCBwYXRj
aGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4gIFN1Ym1pdCBhIGNvbnRleHQKKyMgZGlm
ZiBhbmQgYSBwcm9wZXJseSBmb3JtYXR0ZWQgR05VIENoYW5nZUxvZyBlbnRyeS4KKyMKKyMgQ29u
ZmlndXJhdGlvbiBzdWJyb3V0aW5lIHRvIHZhbGlkYXRlIGFuZCBjYW5vbmljYWxpemUgYSBjb25m
aWd1cmF0aW9uIHR5cGUuCisjIFN1cHBseSB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24gdHlw
ZSBhcyBhbiBhcmd1bWVudC4KKyMgSWYgaXQgaXMgaW52YWxpZCwgd2UgcHJpbnQgYW4gZXJyb3Ig
bWVzc2FnZSBvbiBzdGRlcnIgYW5kIGV4aXQgd2l0aCBjb2RlIDEuCisjIE90aGVyd2lzZSwgd2Ug
cHJpbnQgdGhlIGNhbm9uaWNhbCBjb25maWcgdHlwZSBvbiBzdGRvdXQgYW5kIHN1Y2NlZWQuCisK
KyMgWW91IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgc2NyaXB0IGZyb206Cisj
IGh0dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2Jf
cGxhaW47Zj1jb25maWcuc3ViO2hiPUhFQUQKKworIyBUaGlzIGZpbGUgaXMgc3VwcG9zZWQgdG8g
YmUgdGhlIHNhbWUgZm9yIGFsbCBHTlUgcGFja2FnZXMKKyMgYW5kIHJlY29nbml6ZSBhbGwgdGhl
IENQVSB0eXBlcywgc3lzdGVtIHR5cGVzIGFuZCBhbGlhc2VzCisjIHRoYXQgYXJlIG1lYW5pbmdm
dWwgd2l0aCAqYW55KiBHTlUgc29mdHdhcmUuCisjIEVhY2ggcGFja2FnZSBpcyByZXNwb25zaWJs
ZSBmb3IgcmVwb3J0aW5nIHdoaWNoIHZhbGlkIGNvbmZpZ3VyYXRpb25zCisjIGl0IGRvZXMgbm90
IHN1cHBvcnQuICBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaAorIyBhIGZh
aWx1cmUgdG8gc3VwcG9ydCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZnJvbSBhIG1lYW5pbmdsZXNz
CisjIGNvbmZpZ3VyYXRpb24uCisKKyMgVGhlIGdvYWwgb2YgdGhpcyBmaWxlIGlzIHRvIG1hcCBh
bGwgdGhlIHZhcmlvdXMgdmFyaWF0aW9ucyBvZiBhIGdpdmVuCisjIG1hY2hpbmUgc3BlY2lmaWNh
dGlvbiBpbnRvIGEgc2luZ2xlIHNwZWNpZmljYXRpb24gaW4gdGhlIGZvcm06CisjCUNQVV9UWVBF
LU1BTlVGQUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNCisjIG9yIGluIHNvbWUgY2FzZXMsIHRoZSBu
ZXdlciBmb3VyLXBhcnQgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVS
QVRJTkdfU1lTVEVNCisjIEl0IGlzIHdyb25nIHRvIGVjaG8gYW55IG90aGVyIHR5cGUgb2Ygc3Bl
Y2lmaWNhdGlvbi4KKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdl
PSJcCitVc2FnZTogJDAgW09QVElPTl0gQ1BVLU1GUi1PUFNZUworICAgICAgICQwIFtPUFRJT05d
IEFMSUFTCisKK0Nhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gbmFtZS4KKworT3BlcmF0aW9u
IG1vZGVzOgorICAtaCwgLS1oZWxwICAgICAgICAgcHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQK
KyAgLXQsIC0tdGltZS1zdGFtcCAgIHByaW50IGRhdGUgb2YgbGFzdCBtb2RpZmljYXRpb24sIHRo
ZW4gZXhpdAorICAtdiwgLS12ZXJzaW9uICAgICAgcHJpbnQgdmVyc2lvbiBudW1iZXIsIHRoZW4g
ZXhpdAorCitSZXBvcnQgYnVncyBhbmQgcGF0Y2hlcyB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9y
Zz4uIgorCit2ZXJzaW9uPSJcCitHTlUgY29uZmlnLnN1YiAoJHRpbWVzdGFtcCkKKworQ29weXJp
Z2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LCAy
MDAwLAorMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCwgMjAw
OSwgMjAxMCwgMjAxMSBGcmVlCitTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1RoaXMgaXMg
ZnJlZSBzb2Z0d2FyZTsgc2VlIHRoZSBzb3VyY2UgZm9yIGNvcHlpbmcgY29uZGl0aW9ucy4gIFRo
ZXJlIGlzIE5PCit3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iCisKK2hlbHA9IgorVHJ5IFxgJG1lIC0taGVs
cCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIgorCisjIFBhcnNlIGNvbW1hbmQgbGluZQord2hpbGUg
dGVzdCAkIyAtZ3QgMCA7IGRvCisgIGNhc2UgJDEgaW4KKyAgICAtLXRpbWUtc3RhbXAgfCAtLXRp
bWUqIHwgLXQgKQorICAgICAgIGVjaG8gIiR0aW1lc3RhbXAiIDsgZXhpdCA7OworICAgIC0tdmVy
c2lvbiB8IC12ICkKKyAgICAgICBlY2hvICIkdmVyc2lvbiIgOyBleGl0IDs7CisgICAgLS1oZWxw
IHwgLS1oKiB8IC1oICkKKyAgICAgICBlY2hvICIkdXNhZ2UiOyBleGl0IDs7CisgICAgLS0gKSAg
ICAgIyBTdG9wIG9wdGlvbiBwcm9jZXNzaW5nCisgICAgICAgc2hpZnQ7IGJyZWFrIDs7CisgICAg
LSApCSMgVXNlIHN0ZGluIGFzIGlucHV0LgorICAgICAgIGJyZWFrIDs7CisgICAgLSogKQorICAg
ICAgIGVjaG8gIiRtZTogaW52YWxpZCBvcHRpb24gJDEkaGVscCIKKyAgICAgICBleGl0IDEgOzsK
KworICAgICpsb2NhbCopCisgICAgICAgIyBGaXJzdCBwYXNzIHRocm91Z2ggYW55IGxvY2FsIG1h
Y2hpbmUgdHlwZXMuCisgICAgICAgZWNobyAkMQorICAgICAgIGV4aXQgOzsKKworICAgICogKQor
ICAgICAgIGJyZWFrIDs7CisgIGVzYWMKK2RvbmUKKworY2FzZSAkIyBpbgorIDApIGVjaG8gIiRt
ZTogbWlzc2luZyBhcmd1bWVudCRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworIDEpIDs7CisgKikg
ZWNobyAiJG1lOiB0b28gbWFueSBhcmd1bWVudHMkaGVscCIgPiYyCisgICAgZXhpdCAxOzsKK2Vz
YWMKKworIyBTZXBhcmF0ZSB3aGF0IHRoZSB1c2VyIGdhdmUgaW50byBDUFUtQ09NUEFOWSBhbmQg
T1Mgb3IgS0VSTkVMLU9TIChpZiBhbnkpLgorIyBIZXJlIHdlIG11c3QgcmVjb2duaXplIGFsbCB0
aGUgdmFsaWQgS0VSTkVMLU9TIGNvbWJpbmF0aW9ucy4KK21heWJlX29zPWBlY2hvICQxIHwgc2Vk
ICdzL15cKC4qXCktXChbXi1dKi1bXi1dKlwpJC9cMi8nYAorY2FzZSAkbWF5YmVfb3MgaW4KKyAg
bnRvLXFueCogfCBsaW51eC1nbnUqIHwgbGludXgtYW5kcm9pZCogfCBsaW51eC1kaWV0bGliYyB8
IGxpbnV4LW5ld2xpYiogfCBcCisgIGxpbnV4LXVjbGliYyogfCB1Y2xpbnV4LXVjbGliYyogfCB1
Y2xpbnV4LWdudSogfCBrZnJlZWJzZCotZ251KiB8IFwKKyAga25ldGJzZCotZ251KiB8IG5ldGJz
ZCotZ251KiB8IFwKKyAga29wZW5zb2xhcmlzKi1nbnUqIHwgXAorICBzdG9ybS1jaGFvcyogfCBv
czItZW14KiB8IHJ0bWstbm92YSopCisgICAgb3M9LSRtYXliZV9vcworICAgIGJhc2ljX21hY2hp
bmU9YGVjaG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0qXCkkL1wxLydgCisgICAg
OzsKKyAgKikKKyAgICBiYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzLy1bXi1dKiQvLydg
CisgICAgaWYgWyAkYmFzaWNfbWFjaGluZSAhPSAkMSBdCisgICAgdGhlbiBvcz1gZWNobyAkMSB8
IHNlZCAncy8uKi0vLS8nYAorICAgIGVsc2Ugb3M9OyBmaQorICAgIDs7Citlc2FjCisKKyMjIyBM
ZXQncyByZWNvZ25pemUgY29tbW9uIG1hY2hpbmVzIGFzIG5vdCBiZWluZyBvcGVyYXRpbmcgc3lz
dGVtcyBzbworIyMjIHRoYXQgdGhpbmdzIGxpa2UgY29uZmlnLnN1YiBkZWNzdGF0aW9uLTMxMDAg
d29yay4gIFdlIGFsc28KKyMjIyByZWNvZ25pemUgc29tZSBtYW51ZmFjdHVyZXJzIGFzIG5vdCBi
ZWluZyBvcGVyYXRpbmcgc3lzdGVtcywgc28gd2UKKyMjIyBjYW4gcHJvdmlkZSBkZWZhdWx0IG9w
ZXJhdGluZyBzeXN0ZW1zIGJlbG93LgorY2FzZSAkb3MgaW4KKwktc3VuKm9zKikKKwkJIyBQcmV2
ZW50IGZvbGxvd2luZyBjbGF1c2UgZnJvbSBoYW5kbGluZyB0aGlzIGludmFsaWQgaW5wdXQuCisJ
CTs7CisJLWRlYyogfCAtbWlwcyogfCAtc2VxdWVudCogfCAtZW5jb3JlKiB8IC1wYzUzMiogfCAt
c2dpKiB8IC1zb255KiB8IFwKKwktYXR0KiB8IC03MzAwKiB8IC0zMzAwKiB8IC1kZWx0YSogfCAt
bW90b3JvbGEqIHwgLXN1blsyMzRdKiB8IFwKKwktdW5pY29tKiB8IC1pYm0qIHwgLW5leHQgfCAt
aHAgfCAtaXNpKiB8IC1hcG9sbG8gfCAtYWx0b3MqIHwgXAorCS1jb252ZXJnZW50KiB8IC1uY3Iq
IHwgLW5ld3MgfCAtMzIqIHwgLTM2MDAqIHwgLTMxMDAqIHwgLWhpdGFjaGkqIHxcCisJLWNbMTIz
XSogfCAtY29udmV4KiB8IC1zdW4gfCAtY3JkcyB8IC1vbXJvbiogfCAtZGcgfCAtdWx0cmEgfCAt
dHRpKiB8IFwKKwktaGFycmlzIHwgLWRvbHBoaW4gfCAtaGlnaGxldmVsIHwgLWdvdWxkIHwgLWNi
bSB8IC1ucyB8IC1tYXNzY29tcCB8IFwKKwktYXBwbGUgfCAtYXhpcyB8IC1rbnV0aCB8IC1jcmF5
IHwgLW1pY3JvYmxhemUpCisJCW9zPQorCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWJsdWVn
ZW5lKikKKwkJb3M9LWNuaworCQk7OworCS1zaW0gfCAtY2lzY28gfCAtb2tpIHwgLXdlYyB8IC13
aW5ib25kKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7OworCS1zY291dCkKKwkJOzsK
Kwktd3JzKQorCQlvcz0tdnh3b3JrcworCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWNob3J1
c29zKikKKwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktY2hvcnVz
cmRiKQorCQlvcz0tY2hvcnVzcmRiCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktaGl1eCop
CisJCW9zPS1oaXV4d2UyCisJCTs7CisJLXNjbzYpCisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFj
aGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281KQor
CQlvcz0tc2NvMy4ydjUKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0u
Ki84Ni1wYy8nYAorCQk7OworCS1zY280KQorCQlvcz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGlu
ZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQt
OV0qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJh
c2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwkt
c2NvMy4ydls0LTldKikKKwkJIyBEb24ndCBmb3JnZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBv
ciBuZXdlci4KKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1w
Yy8nYAorCQk7OworCS1zY281djYqKQorCQkjIERvbid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlz
IDMuMnY0IG9yIG5ld2VyLgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2
LS4qLzg2LXBjLydgCisJCTs7CisJLXNjbyopCisJCW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNo
aW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXVkayopCisJ
CWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsK
KwktaXNjKQorCQlvcz0taXNjMi4yCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktY2xpeCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBl
ci1pbnRlcmdyYXBoCisJCTs7CisJLWlzYyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBz
ZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktbHlueCopCisJCW9zPS1seW54b3MKKwkJ
OzsKKwktcHR4KikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84
Ni1zZXF1ZW50LydgCisJCTs7CisJLXdpbmRvd3NudCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAt
ZSAncy93aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsKKwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7
CisJLW1pbnQgfCAtbWludFswLTldKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9z
PS1taW50CisJCTs7Citlc2FjCisKKyMgRGVjb2RlIGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNP
TVBBTlkgY29tYmluYXRpb25zLgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXpl
IHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aG91dCBjb21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBv
bWl0dGVkIGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUgc3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkx
NzUwYSB8IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFscGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFl
djU2IHwgYWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2
NGV2WzQtOF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhhNjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjdd
IFwKKwl8IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFybSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBh
cm12WzIzNDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2ciB8IGF2cjMyIFwKKyAgICAgICAgfCBiZTMy
IHwgYmU2NCBcCisJfCBiZmluIFwKKwl8IGM0eCB8IGNsaXBwZXIgXAorCXwgZDEwdiB8IGQzMHYg
fCBkbHggfCBkc3AxNnh4IFwKKwl8IGVwaXBoYW55IFwKKwl8IGZpZG8gfCBmcjMwIHwgZnJ2IFwK
Kwl8IGg4MzAwIHwgaDg1MDAgfCBocHBhIHwgaHBwYTEuWzAxXSB8IGhwcGEyLjAgfCBocHBhMi4w
W253XSB8IGhwcGE2NCBcCisJfCBoZXhhZ29uIFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlh
NjQgXAorCXwgaXAyayB8IGlxMjAwMCBcCisJfCBsZTMyIHwgbGU2NCBcCisJfCBsbTMyIFwKKwl8
IG0zMmMgfCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsgXAorCXwgbWF4cSB8
IG1iIHwgbWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwgbWlwcyB8IG1pcHNi
ZSB8IG1pcHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAorCXwgbWlwczY0IHwg
bWlwczY0ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwgXAorCXwgbWlwczY0
b3Jpb24gfCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlwczY0cjU5MDBlbCBc
CisJfCBtaXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAwIHwgbWlwczY0dnI0
MTAwZWwgXAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAorCXwgbWlwczY0dnI1
MDAwIHwgbWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlwczY0dnI1OTAwZWwg
XAorCXwgbWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMycjIgfCBtaXBzaXNh
MzJyMmVsIFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1pcHNpc2E2NHIyIHwg
bWlwc2lzYTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRzYjFlbCBcCisJfCBt
aXBzaXNhNjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4MzkgfCBtaXBzdHgz
OWVsIFwKKwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8IG10IFwKKwl8IG1z
cDQzMCBcCisJfCBuZHMzMiB8IG5kczMybGUgfCBuZHMzMmJlIFwKKwl8IG5pb3MgfCBuaW9zMiBc
CisJfCBuczE2ayB8IG5zMzJrIFwKKwl8IG9wZW44IFwKKwl8IG9yMzIgXAorCXwgcGRwMTAgfCBw
ZHAxMSB8IHBqIHwgcGpsIFwKKwl8IHBvd2VycGMgfCBwb3dlcnBjNjQgfCBwb3dlcnBjNjRsZSB8
IHBvd2VycGNsZSBcCisJfCBweXJhbWlkIFwKKwl8IHJsNzggfCByeCBcCisJfCBzY29yZSBcCisJ
fCBzaCB8IHNoWzEyMzRdIHwgc2hbMjRdYSB8IHNoWzI0XWFlYiB8IHNoWzIzXWUgfCBzaFszNF1l
YiB8IHNoZWIgfCBzaGJlIHwgc2hsZSB8IHNoWzEyMzRdbGUgfCBzaDNlbGUgXAorCXwgc2g2NCB8
IHNoNjRsZSBcCisJfCBzcGFyYyB8IHNwYXJjNjQgfCBzcGFyYzY0YiB8IHNwYXJjNjR2IHwgc3Bh
cmM4NnggfCBzcGFyY2xldCB8IHNwYXJjbGl0ZSBcCisJfCBzcGFyY3Y4IHwgc3BhcmN2OSB8IHNw
YXJjdjliIHwgc3BhcmN2OXYgXAorCXwgc3B1IFwKKwl8IHRhaG9lIHwgdGljNHggfCB0aWM1NHgg
fCB0aWM1NXggfCB0aWM2eCB8IHRpYzgwIHwgdHJvbiBcCisJfCB1Ymljb20zMiBcCisJfCB2ODUw
IHwgdjg1MGUgfCB2ODUwZTEgfCB2ODUwZTIgfCB2ODUwZXMgfCB2ODUwZTJ2MyBcCisJfCB3ZTMy
ayBcCisJfCB4ODYgfCB4YzE2eCB8IHhzdG9ybXkxNiB8IHh0ZW5zYSBcCisJfCB6OGsgfCB6ODAp
CisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93bgorCQk7OworCWM1NHgpCisJ
CWJhc2ljX21hY2hpbmU9dGljNTR4LXVua25vd24KKwkJOzsKKwljNTV4KQorCQliYXNpY19tYWNo
aW5lPXRpYzU1eC11bmtub3duCisJCTs7CisJYzZ4KQorCQliYXNpY19tYWNoaW5lPXRpYzZ4LXVu
a25vd24KKwkJOzsKKwltNjgxMSB8IG02OGhjMTEgfCBtNjgxMiB8IG02OGhjMTIgfCBwaWNvY2hp
cCkKKwkJIyBNb3Rvcm9sYSA2OEhDMTEvMTIuCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hp
bmUtdW5rbm93bgorCQlvcz0tbm9uZQorCQk7OworCW04ODExMCB8IG02ODBbMTIzNDZdMCB8IG02
ODM/MiB8IG02ODM2MCB8IG01MjAwIHwgdjcwIHwgdzY1IHwgejhrKQorCQk7OworCW1zMSkKKwkJ
YmFzaWNfbWFjaGluZT1tdC11bmtub3duCisJCTs7CisKKwlzdHJvbmdhcm0gfCB0aHVtYiB8IHhz
Y2FsZSkKKwkJYmFzaWNfbWFjaGluZT1hcm0tdW5rbm93bgorCQk7OworCisJeHNjYWxlZWIpCisJ
CWJhc2ljX21hY2hpbmU9YXJtZWItdW5rbm93bgorCQk7OworCisJeHNjYWxlZWwpCisJCWJhc2lj
X21hY2hpbmU9YXJtZWwtdW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhh
biBgdW5rbm93bicKKwkjIGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJl
LCBhbmQKKwkjICgyKSB0aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5p
bmcgdXNlcnMuCisJaSo4NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hp
bmUtcGMKKwkgIDs7CisJIyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29y
ZC4KKwkqLSotKikKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5l
IFxgJGJhc2ljX21hY2hpbmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7Owor
CSMgUmVjb2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgw
LSogXAorCXwgYTI5ay0qIFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1
Ni0qIHwgYWxwaGFldjZbNzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8
IGFscGhhNjRldjU2LSogfCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8
IGFscGhhNjRwY2E1WzY3XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxl
LSogfCBhcm1lYi0qIHwgYXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmUzMi0q
IHwgYmU2NC0qIFwKKwl8IGJmaW4tKiB8IGJzMjAwMC0qIFwKKwl8IGNbMTIzXSogfCBjMzAtKiB8
IFtjanRdOTAtKiB8IGM0eC0qIFwKKwl8IGNsaXBwZXItKiB8IGNyYXludi0qIHwgY3lkcmEtKiBc
CisJfCBkMTB2LSogfCBkMzB2LSogfCBkbHgtKiBcCisJfCBlbHhzaS0qIFwKKwl8IGYzMFswMV0t
KiB8IGY3MDAtKiB8IGZpZG8tKiB8IGZyMzAtKiB8IGZydi0qIHwgZng4MC0qIFwKKwl8IGg4MzAw
LSogfCBoODUwMC0qIFwKKwl8IGhwcGEtKiB8IGhwcGExLlswMV0tKiB8IGhwcGEyLjAtKiB8IGhw
cGEyLjBbbnddLSogfCBocHBhNjQtKiBcCisJfCBoZXhhZ29uLSogXAorCXwgaSo4Ni0qIHwgaTg2
MC0qIHwgaTk2MC0qIHwgaWE2NC0qIFwKKwl8IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxlMzIt
KiB8IGxlNjQtKiBcCisJfCBsbTMyLSogXAorCXwgbTMyYy0qIHwgbTMyci0qIHwgbTMycmxlLSog
XAorCXwgbTY4MDAwLSogfCBtNjgwWzAxMjM0Nl0wLSogfCBtNjgzNjAtKiB8IG02ODM/Mi0qIHwg
bTY4ay0qIFwKKwl8IG04ODExMC0qIHwgbTg4ay0qIHwgbWF4cS0qIHwgbWNvcmUtKiB8IG1ldGFn
LSogfCBtaWNyb2JsYXplLSogXAorCXwgbWlwcy0qIHwgbWlwc2JlLSogfCBtaXBzZWItKiB8IG1p
cHNlbC0qIHwgbWlwc2xlLSogXAorCXwgbWlwczE2LSogXAorCXwgbWlwczY0LSogfCBtaXBzNjRl
bC0qIFwKKwl8IG1pcHM2NG9jdGVvbi0qIHwgbWlwczY0b2N0ZW9uZWwtKiBcCisJfCBtaXBzNjRv
cmlvbi0qIHwgbWlwczY0b3Jpb25lbC0qIFwKKwl8IG1pcHM2NHI1OTAwLSogfCBtaXBzNjRyNTkw
MGVsLSogXAorCXwgbWlwczY0dnItKiB8IG1pcHM2NHZyZWwtKiBcCisJfCBtaXBzNjR2cjQxMDAt
KiB8IG1pcHM2NHZyNDEwMGVsLSogXAorCXwgbWlwczY0dnI0MzAwLSogfCBtaXBzNjR2cjQzMDBl
bC0qIFwKKwl8IG1pcHM2NHZyNTAwMC0qIHwgbWlwczY0dnI1MDAwZWwtKiBcCisJfCBtaXBzNjR2
cjU5MDAtKiB8IG1pcHM2NHZyNTkwMGVsLSogXAorCXwgbWlwc2lzYTMyLSogfCBtaXBzaXNhMzJl
bC0qIFwKKwl8IG1pcHNpc2EzMnIyLSogfCBtaXBzaXNhMzJyMmVsLSogXAorCXwgbWlwc2lzYTY0
LSogfCBtaXBzaXNhNjRlbC0qIFwKKwl8IG1pcHNpc2E2NHIyLSogfCBtaXBzaXNhNjRyMmVsLSog
XAorCXwgbWlwc2lzYTY0c2IxLSogfCBtaXBzaXNhNjRzYjFlbC0qIFwKKwl8IG1pcHNpc2E2NHNy
NzFrLSogfCBtaXBzaXNhNjRzcjcxa2VsLSogXAorCXwgbWlwc3R4MzktKiB8IG1pcHN0eDM5ZWwt
KiBcCisJfCBtbWl4LSogXAorCXwgbXQtKiBcCisJfCBtc3A0MzAtKiBcCisJfCBuZHMzMi0qIHwg
bmRzMzJsZS0qIHwgbmRzMzJiZS0qIFwKKwl8IG5pb3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0q
IHwgbnAxLSogfCBuczE2ay0qIHwgbnMzMmstKiBcCisJfCBvcGVuOC0qIFwKKwl8IG9yaW9uLSog
XAorCXwgcGRwMTAtKiB8IHBkcDExLSogfCBwai0qIHwgcGpsLSogfCBwbi0qIHwgcG93ZXItKiBc
CisJfCBwb3dlcnBjLSogfCBwb3dlcnBjNjQtKiB8IHBvd2VycGM2NGxlLSogfCBwb3dlcnBjbGUt
KiBcCisJfCBweXJhbWlkLSogXAorCXwgcmw3OC0qIHwgcm9tcC0qIHwgcnM2MDAwLSogfCByeC0q
IFwKKwl8IHNoLSogfCBzaFsxMjM0XS0qIHwgc2hbMjRdYS0qIHwgc2hbMjRdYWViLSogfCBzaFsy
M11lLSogfCBzaFszNF1lYi0qIHwgc2hlYi0qIHwgc2hiZS0qIFwKKwl8IHNobGUtKiB8IHNoWzEy
MzRdbGUtKiB8IHNoM2VsZS0qIHwgc2g2NC0qIHwgc2g2NGxlLSogXAorCXwgc3BhcmMtKiB8IHNw
YXJjNjQtKiB8IHNwYXJjNjRiLSogfCBzcGFyYzY0di0qIHwgc3BhcmM4NngtKiB8IHNwYXJjbGV0
LSogXAorCXwgc3BhcmNsaXRlLSogXAorCXwgc3BhcmN2OC0qIHwgc3BhcmN2OS0qIHwgc3BhcmN2
OWItKiB8IHNwYXJjdjl2LSogfCBzdjEtKiB8IHN4Py0qIFwKKwl8IHRhaG9lLSogXAorCXwgdGlj
MzAtKiB8IHRpYzR4LSogfCB0aWM1NHgtKiB8IHRpYzU1eC0qIHwgdGljNngtKiB8IHRpYzgwLSog
XAorCXwgdGlsZSotKiBcCisJfCB0cm9uLSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSog
fCB2ODUwZS0qIHwgdjg1MGUxLSogfCB2ODUwZXMtKiB8IHY4NTBlMi0qIHwgdjg1MGUydjMtKiBc
CisJfCB2YXgtKiBcCisJfCB3ZTMyay0qIFwKKwl8IHg4Ni0qIHwgeDg2XzY0LSogfCB4YzE2eC0q
IHwgeHBzMTAwLSogXAorCXwgeHN0b3JteTE2LSogfCB4dGVuc2EqLSogXAorCXwgeW1wLSogXAor
CXwgejhrLSogfCB6ODAtKikKKwkJOzsKKwkjIFJlY29nbml6ZSB0aGUgYmFzaWMgQ1BVIHR5cGVz
IHdpdGhvdXQgY29tcGFueSBuYW1lLCB3aXRoIGdsb2IgbWF0Y2guCisJeHRlbnNhKikKKwkJYmFz
aWNfbWFjaGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJIyBSZWNvZ25pemUgdGhl
IHZhcmlvdXMgbWFjaGluZSBuYW1lcyBhbmQgYWxpYXNlcyB3aGljaCBzdGFuZAorCSMgZm9yIGEg
Q1BVIHR5cGUgYW5kIGEgY29tcGFueSBhbmQgc29tZXRpbWVzIGV2ZW4gYW4gT1MuCisJMzg2YnNk
KQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tYnNkCisJCTs7CisJM2IxIHwg
NzMwMCB8IDczMDAtYXR0IHwgYXR0LTczMDAgfCBwYzczMDAgfCBzYWZhcmkgfCB1bml4cGMpCisJ
CWJhc2ljX21hY2hpbmU9bTY4MDAwLWF0dAorCQk7OworCTNiKikKKwkJYmFzaWNfbWFjaGluZT13
ZTMyay1hdHQKKwkJOzsKKwlhMjlraGlmKQorCQliYXNpY19tYWNoaW5lPWEyOWstYW1kCisJCW9z
PS11ZGkKKwkJOzsKKwlhYmFjdXMpCisJCWJhc2ljX21hY2hpbmU9YWJhY3VzLXVua25vd24KKwkJ
OzsKKwlhZG9iZTY4aykKKwkJYmFzaWNfbWFjaGluZT1tNjgwMTAtYWRvYmUKKwkJb3M9LXNjb3V0
CisJCTs7CisJYWxsaWFudCB8IGZ4ODApCisJCWJhc2ljX21hY2hpbmU9Zng4MC1hbGxpYW50CisJ
CTs7CisJYWx0b3MgfCBhbHRvczMwNjgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hbHRvcworCQk7
OworCWFtMjlrKQorCQliYXNpY19tYWNoaW5lPWEyOWstbm9uZQorCQlvcz0tYnNkCisJCTs7CisJ
YW1kNjQpCisJCWJhc2ljX21hY2hpbmU9eDg2XzY0LXBjCisJCTs7CisJYW1kNjQtKikKKwkJYmFz
aWNfbWFjaGluZT14ODZfNjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJOzsKKwlhbWRhaGwpCisJCWJhc2ljX21hY2hpbmU9NTgwLWFtZGFobAorCQlvcz0tc3lz
dgorCQk7OworCWFtaWdhIHwgYW1pZ2EtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXVua25vd24K
KwkJOzsKKwlhbWlnYW9zIHwgYW1pZ2Fkb3MpCisJCWJhc2ljX21hY2hpbmU9bTY4ay11bmtub3du
CisJCW9zPS1hbWlnYW9zCisJCTs7CisJYW1pZ2F1bml4IHwgYW1peCkKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLXVua25vd24KKwkJb3M9LXN5c3Y0CisJCTs7CisJYXBvbGxvNjgpCisJCWJhc2ljX21h
Y2hpbmU9bTY4ay1hcG9sbG8KKwkJb3M9LXN5c3YKKwkJOzsKKwlhcG9sbG82OGJzZCkKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLWFwb2xsbworCQlvcz0tYnNkCisJCTs7CisJYXJvcykKKwkJYmFzaWNf
bWFjaGluZT1pMzg2LXBjCisJCW9zPS1hcm9zCisJCTs7CisJYXV4KQorCQliYXNpY19tYWNoaW5l
PW02OGstYXBwbGUKKwkJb3M9LWF1eAorCQk7OworCWJhbGFuY2UpCisJCWJhc2ljX21hY2hpbmU9
bnMzMmstc2VxdWVudAorCQlvcz0tZHluaXgKKwkJOzsKKwlibGFja2ZpbikKKwkJYmFzaWNfbWFj
aGluZT1iZmluLXVua25vd24KKwkJb3M9LWxpbnV4CisJCTs7CisJYmxhY2tmaW4tKikKKwkJYmFz
aWNfbWFjaGluZT1iZmluLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydg
CisJCW9zPS1saW51eAorCQk7OworCWJsdWVnZW5lKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBj
LWlibQorCQlvcz0tY25rCisJCTs7CisJYzU0eC0qKQorCQliYXNpY19tYWNoaW5lPXRpYzU0eC1g
ZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM1NXgtKikK
KwkJYmFzaWNfbWFjaGluZT10aWM1NXgtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlte
LV0qLS8vJ2AKKwkJOzsKKwljNngtKikKKwkJYmFzaWNfbWFjaGluZT10aWM2eC1gZWNobyAkYmFz
aWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM5MCkKKwkJYmFzaWNfbWFj
aGluZT1jOTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY2VnY2MpCisJCWJhc2ljX21hY2hp
bmU9YXJtLXVua25vd24KKwkJb3M9LWNlZ2NjCisJCTs7CisJY29udmV4LWMxKQorCQliYXNpY19t
YWNoaW5lPWMxLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMyKQorCQliYXNpY19t
YWNoaW5lPWMyLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMzMikKKwkJYmFzaWNf
bWFjaGluZT1jMzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzM0KQorCQliYXNp
Y19tYWNoaW5lPWMzNC1jb252ZXgKKwkJb3M9LWJzZAorCQk7OworCWNvbnZleC1jMzgpCisJCWJh
c2ljX21hY2hpbmU9YzM4LWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY3JheSB8IGo5MCkKKwkJ
YmFzaWNfbWFjaGluZT1qOTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY3JheW52KQorCQli
YXNpY19tYWNoaW5lPWNyYXludi1jcmF5CisJCW9zPS11bmljb3NtcAorCQk7OworCWNyMTYgfCBj
cjE2LSopCisJCWJhc2ljX21hY2hpbmU9Y3IxNi11bmtub3duCisJCW9zPS1lbGYKKwkJOzsKKwlj
cmRzIHwgdW5vcykKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWNyZHMKKwkJOzsKKwljcmlzdjMyIHwg
Y3Jpc3YzMi0qIHwgZXRyYXhmcyopCisJCWJhc2ljX21hY2hpbmU9Y3Jpc3YzMi1heGlzCisJCTs7
CisJY3JpcyB8IGNyaXMtKiB8IGV0cmF4KikKKwkJYmFzaWNfbWFjaGluZT1jcmlzLWF4aXMKKwkJ
OzsKKwljcngpCisJCWJhc2ljX21hY2hpbmU9Y3J4LXVua25vd24KKwkJb3M9LWVsZgorCQk7Owor
CWRhMzAgfCBkYTMwLSopCisJCWJhc2ljX21hY2hpbmU9bTY4ay1kYTMwCisJCTs7CisJZGVjc3Rh
dGlvbiB8IGRlY3N0YXRpb24tMzEwMCB8IHBtYXggfCBwbWF4LSogfCBwbWluIHwgZGVjMzEwMCB8
IGRlY3N0YXRuKQorCQliYXNpY19tYWNoaW5lPW1pcHMtZGVjCisJCTs7CisJZGVjc3lzdGVtMTAq
IHwgZGVjMTAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlvcz0tdG9wczEwCisJCTs7
CisJZGVjc3lzdGVtMjAqIHwgZGVjMjAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlv
cz0tdG9wczIwCisJCTs7CisJZGVsdGEgfCAzMzAwIHwgbW90b3JvbGEtMzMwMCB8IG1vdG9yb2xh
LWRlbHRhIFwKKwkgICAgICB8IDMzMDAtbW90b3JvbGEgfCBkZWx0YS1tb3Rvcm9sYSkKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLW1vdG9yb2xhCisJCTs7CisJZGVsdGE4OCkKKwkJYmFzaWNfbWFjaGlu
ZT1tODhrLW1vdG9yb2xhCisJCW9zPS1zeXN2MworCQk7OworCWRpY29zKQorCQliYXNpY19tYWNo
aW5lPWk2ODYtcGMKKwkJb3M9LWRpY29zCisJCTs7CisJZGpncHApCisJCWJhc2ljX21hY2hpbmU9
aTU4Ni1wYworCQlvcz0tbXNkb3NkamdwcAorCQk7OworCWRweDIwIHwgZHB4MjAtKikKKwkJYmFz
aWNfbWFjaGluZT1yczYwMDAtYnVsbAorCQlvcz0tYm9zeAorCQk7OworCWRweDIqIHwgZHB4Miot
YnVsbCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWJ1bGwKKwkJb3M9LXN5c3YzCisJCTs7CisJZWJt
b24yOWspCisJCWJhc2ljX21hY2hpbmU9YTI5ay1hbWQKKwkJb3M9LWVibW9uCisJCTs7CisJZWx4
c2kpCisJCWJhc2ljX21hY2hpbmU9ZWx4c2ktZWx4c2kKKwkJb3M9LWJzZAorCQk7OworCWVuY29y
ZSB8IHVtYXggfCBtbWF4KQorCQliYXNpY19tYWNoaW5lPW5zMzJrLWVuY29yZQorCQk7OworCWVz
MTgwMCB8IE9TRTY4ayB8IG9zZTY4ayB8IG9zZSB8IE9TRSkKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LWVyaWNzc29uCisJCW9zPS1vc2UKKwkJOzsKKwlmeDI4MDApCisJCWJhc2ljX21hY2hpbmU9aTg2
MC1hbGxpYW50CisJCTs7CisJZ2VuaXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstbnMKKwkJOzsK
KwlnbWljcm8pCisJCWJhc2ljX21hY2hpbmU9dHJvbi1nbWljcm8KKwkJb3M9LXN5c3YKKwkJOzsK
KwlnbzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWdvMzIKKwkJOzsKKwloMzA1
MHIqIHwgaGl1eCopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRhY2hpCisJCW9zPS1oaXV4
d2UyCisJCTs7CisJaDgzMDBobXMpCisJCWJhc2ljX21hY2hpbmU9aDgzMDAtaGl0YWNoaQorCQlv
cz0taG1zCisJCTs7CisJaDgzMDB4cmF5KQorCQliYXNpY19tYWNoaW5lPWg4MzAwLWhpdGFjaGkK
KwkJb3M9LXhyYXkKKwkJOzsKKwloODUwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODUwMC1oaXRh
Y2hpCisJCW9zPS1obXMKKwkJOzsKKwloYXJyaXMpCisJCWJhc2ljX21hY2hpbmU9bTg4ay1oYXJy
aXMKKwkJb3M9LXN5c3YzCisJCTs7CisJaHAzMDAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhw
CisJCTs7CisJaHAzMDBic2QpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlvcz0tYnNkCisJ
CTs7CisJaHAzMDBocHV4KQorCQliYXNpY19tYWNoaW5lPW02OGstaHAKKwkJb3M9LWhwdXgKKwkJ
OzsKKwlocDNrOVswLTldWzAtOV0gfCBocDlbMC05XVswLTldKQorCQliYXNpY19tYWNoaW5lPWhw
cGExLjAtaHAKKwkJOzsKKwlocDlrMlswLTldWzAtOV0gfCBocDlrMzFbMC05XSkKKwkJYmFzaWNf
bWFjaGluZT1tNjgwMDAtaHAKKwkJOzsKKwlocDlrM1syLTldWzAtOV0pCisJCWJhc2ljX21hY2hp
bmU9bTY4ay1ocAorCQk7OworCWhwOWs2WzAtOV1bMC05XSB8IGhwNlswLTldWzAtOV0pCisJCWJh
c2ljX21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwOWs3WzAtNzldWzAtOV0gfCBocDdbMC03
OV1bMC05XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azc4WzAtOV0g
fCBocDc4WzAtOV0pCisJCSMgRklYTUU6IHJlYWxseSBocHBhMi4wLWhwCisJCWJhc2ljX21hY2hp
bmU9aHBwYTEuMS1ocAorCQk7OworCWhwOWs4WzY3XTEgfCBocDhbNjddMSB8IGhwOWs4MFsyNF0g
fCBocDgwWzI0XSB8IGhwOWs4Wzc4XTkgfCBocDhbNzhdOSB8IGhwOWs4OTMgfCBocDg5MykKKwkJ
IyBGSVhNRTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJ
CTs7CisJaHA5azhbMC05XVsxMzY3OV0gfCBocDhbMC05XVsxMzY3OV0pCisJCWJhc2ljX21hY2hp
bmU9aHBwYTEuMS1ocAorCQk7OworCWhwOWs4WzAtOV1bMC05XSB8IGhwOFswLTldWzAtOV0pCisJ
CWJhc2ljX21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwcGEtbmV4dCkKKwkJb3M9LW5leHRz
dGVwMworCQk7OworCWhwcGFvc2YpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0t
b3NmCisJCTs7CisJaHBwcm8pCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0tcHJv
ZWxmCisJCTs7CisJaTM3MC1pYm0qIHwgaWJtKikKKwkJYmFzaWNfbWFjaGluZT1pMzcwLWlibQor
CQk7OworIyBJJ20gbm90IHN1cmUgd2hhdCAiU3lzdjMyIiBtZWFucy4gIFNob3VsZCB0aGlzIGJl
IHN5c3YzLjI/CisJaSo4NnYzMikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAn
cy84Ni4qLzg2LXBjLydgCisJCW9zPS1zeXN2MzIKKwkJOzsKKwlpKjg2djQqKQorCQliYXNpY19t
YWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXN5c3Y0CisJ
CTs7CisJaSo4NnYpCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84
Ni1wYy8nYAorCQlvcz0tc3lzdgorCQk7OworCWkqODZzb2wyKQorCQliYXNpY19tYWNoaW5lPWBl
Y2hvICQxIHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXNvbGFyaXMyCisJCTs7CisJ
aTM4Nm1hY2gpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1tYWNoCisJCW9zPS1tYWNoCisJCTs7CisJ
aTM4Ni12c3RhIHwgdnN0YSkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJb3M9LXZz
dGEKKwkJOzsKKwlpcmlzIHwgaXJpczRkKQorCQliYXNpY19tYWNoaW5lPW1pcHMtc2dpCisJCWNh
c2UgJG9zIGluCisJCSAgICAtaXJpeCopCisJCQk7OworCQkgICAgKikKKwkJCW9zPS1pcml4NAor
CQkJOzsKKwkJZXNhYworCQk7OworCWlzaTY4IHwgaXNpKQorCQliYXNpY19tYWNoaW5lPW02OGst
aXNpCisJCW9zPS1zeXN2CisJCTs7CisJbTY4a25vbW11KQorCQliYXNpY19tYWNoaW5lPW02OGst
dW5rbm93bgorCQlvcz0tbGludXgKKwkJOzsKKwltNjhrbm9tbXUtKikKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9zPS1s
aW51eAorCQk7OworCW04OGstb21yb24qKQorCQliYXNpY19tYWNoaW5lPW04OGstb21yb24KKwkJ
OzsKKwltYWdudW0gfCBtMzIzMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLW1pcHMKKwkJb3M9LXN5
c3YKKwkJOzsKKwltZXJsaW4pCisJCWJhc2ljX21hY2hpbmU9bnMzMmstdXRlaworCQlvcz0tc3lz
dgorCQk7OworCW1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9bWljcm9ibGF6ZS14aWxpbngK
KwkJOzsKKwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LW1pbmd3MzIK
KwkJOzsKKwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJtLXVua25vd24KKwkJb3M9LW1p
bmd3MzJjZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtY29udmVy
Z2VudAorCQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlOVCB8ICpNaU5UWzAtOV0qKQor
CQliYXNpY19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQKKwkJOzsKKwltaXBzMyotKikK
KwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAtZSAncy9taXBzMy9t
aXBzNjQvJ2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2ljX21h
Y2hpbmUgfCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25vd24KKwkJOzsKKwltb25pdG9y
KQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJbW9ycGhv
cykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJb3M9LW1vcnBob3MKKwkJOzsK
Kwltc2RvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc2RvcworCQk7OworCW1z
MS0qKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkIC1lICdzL21z
MS0vbXQtLydgCisJCTs7CisJbXN5cykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1t
c3lzCisJCTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCW9zPS1tdnMKKwkJ
OzsKKwluYWNsKQorCQliYXNpY19tYWNoaW5lPWxlMzItdW5rbm93bgorCQlvcz0tbmFjbAorCQk7
OworCW5jcjMwMDApCisJCWJhc2ljX21hY2hpbmU9aTQ4Ni1uY3IKKwkJb3M9LXN5c3Y0CisJCTs7
CisJbmV0YnNkMzg2KQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tbmV0YnNk
CisJCTs7CisJbmV0d2luZGVyKQorCQliYXNpY19tYWNoaW5lPWFybXY0bC1yZWJlbAorCQlvcz0t
bGludXgKKwkJOzsKKwluZXdzIHwgbmV3czcwMCB8IG5ld3M4MDAgfCBuZXdzOTAwKQorCQliYXNp
Y19tYWNoaW5lPW02OGstc29ueQorCQlvcz0tbmV3c29zCisJCTs7CisJbmV3czEwMDApCisJCWJh
c2ljX21hY2hpbmU9bTY4MDMwLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5ld3MtMzYwMCB8
IHJpc2MtbmV3cykKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7
OworCW5lY3Y3MCkKKwkJYmFzaWNfbWFjaGluZT12NzAtbmVjCisJCW9zPS1zeXN2CisJCTs7CisJ
bmV4dCB8IG0qLW5leHQgKQorCQliYXNpY19tYWNoaW5lPW02OGstbmV4dAorCQljYXNlICRvcyBp
bgorCQkgICAgLW5leHRzdGVwKiApCisJCQk7OworCQkgICAgLW5zMiopCisJCSAgICAgIG9zPS1u
ZXh0c3RlcDIKKwkJCTs7CisJCSAgICAqKQorCQkgICAgICBvcz0tbmV4dHN0ZXAzCisJCQk7Owor
CQllc2FjCisJCTs7CisJbmgzMDAwKQorCQliYXNpY19tYWNoaW5lPW02OGstaGFycmlzCisJCW9z
PS1jeHV4CisJCTs7CisJbmhbNDVdMDAwKQorCQliYXNpY19tYWNoaW5lPW04OGstaGFycmlzCisJ
CW9zPS1jeHV4CisJCTs7CisJbmluZHk5NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAor
CQlvcz0tbmluZHkKKwkJOzsKKwltb245NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAor
CQlvcz0tbW9uOTYwCisJCTs7CisJbm9uc3RvcHV4KQorCQliYXNpY19tYWNoaW5lPW1pcHMtY29t
cGFxCisJCW9zPS1ub25zdG9wdXgKKwkJOzsKKwlucDEpCisJCWJhc2ljX21hY2hpbmU9bnAxLWdv
dWxkCisJCTs7CisJbmVvLXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uZW8tdGFuZGVtCisJCTs7
CisJbnNlLXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uc2UtdGFuZGVtCisJCTs7CisJbnNyLXRh
bmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uc3ItdGFuZGVtCisJCTs7CisJb3A1MG4tKiB8IG9wNjBj
LSopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJb3M9LXByb2VsZgorCQk7OworCW9w
ZW5yaXNjIHwgb3BlbnJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1vcjMyLXVua25vd24KKwkJOzsK
KwlvczQwMCkKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWlibQorCQlvcz0tb3M0MDAKKwkJOzsK
KwlPU0U2ODAwMCB8IG9zZTY4MDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1lcmljc3Nvbgor
CQlvcz0tb3NlCisJCTs7CisJb3M2OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ub25lCisJCW9z
PS1vczY4aworCQk7OworCXBhLWhpdGFjaGkpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRh
Y2hpCisJCW9zPS1oaXV4d2UyCisJCTs7CisJcGFyYWdvbikKKwkJYmFzaWNfbWFjaGluZT1pODYw
LWludGVsCisJCW9zPS1vc2YKKwkJOzsKKwlwYXJpc2MpCisJCWJhc2ljX21hY2hpbmU9aHBwYS11
bmtub3duCisJCW9zPS1saW51eAorCQk7OworCXBhcmlzYy0qKQorCQliYXNpY19tYWNoaW5lPWhw
cGEtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4
CisJCTs7CisJcGJkKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXR0aQorCQk7OworCXBiYikKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLXR0aQorCQk7OworCXBjNTMyIHwgcGM1MzItKikKKwkJYmFzaWNf
bWFjaGluZT1uczMyay1wYzUzMgorCQk7OworCXBjOTgpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1w
YworCQk7OworCXBjOTgtKikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LWBlY2hvICRiYXNpY19tYWNo
aW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcGVudGl1bSB8IHA1IHwgazUgfCBrNiB8
IG5leGdlbiB8IHZpYWMzKQorCQliYXNpY19tYWNoaW5lPWk1ODYtcGMKKwkJOzsKKwlwZW50aXVt
cHJvIHwgcDYgfCA2eDg2IHwgYXRobG9uIHwgYXRobG9uXyopCisJCWJhc2ljX21hY2hpbmU9aTY4
Ni1wYworCQk7OworCXBlbnRpdW1paSB8IHBlbnRpdW0yIHwgcGVudGl1bWlpaSB8IHBlbnRpdW0z
KQorCQliYXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlwZW50aXVtNCkKKwkJYmFzaWNfbWFj
aGluZT1pNzg2LXBjCisJCTs7CisJcGVudGl1bS0qIHwgcDUtKiB8IGs1LSogfCBrNi0qIHwgbmV4
Z2VuLSogfCB2aWFjMy0qKQorCQliYXNpY19tYWNoaW5lPWk1ODYtYGVjaG8gJGJhc2ljX21hY2hp
bmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtcHJvLSogfCBwNi0qIHwgNng4
Ni0qIHwgYXRobG9uLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAkYmFzaWNfbWFjaGlu
ZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW1paS0qIHwgcGVudGl1bTItKiB8
IHBlbnRpdW1paWktKiB8IHBlbnRpdW0zLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAk
YmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW00LSopCisJ
CWJhc2ljX21hY2hpbmU9aTc4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSot
Ly8nYAorCQk7OworCXBuKQorCQliYXNpY19tYWNoaW5lPXBuLWdvdWxkCisJCTs7CisJcG93ZXIp
CWJhc2ljX21hY2hpbmU9cG93ZXItaWJtCisJCTs7CisJcHBjIHwgcHBjYmUpCWJhc2ljX21hY2hp
bmU9cG93ZXJwYy11bmtub3duCisJCTs7CisJcHBjLSogfCBwcGNiZS0qKQorCQliYXNpY19tYWNo
aW5lPXBvd2VycGMtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJ
OzsKKwlwcGNsZSB8IHBvd2VycGNsaXR0bGUgfCBwcGMtbGUgfCBwb3dlcnBjLWxpdHRsZSkKKwkJ
YmFzaWNfbWFjaGluZT1wb3dlcnBjbGUtdW5rbm93bgorCQk7OworCXBwY2xlLSogfCBwb3dlcnBj
bGl0dGxlLSopCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLWBlY2hvICRiYXNpY19tYWNoaW5l
IHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcHBjNjQpCWJhc2ljX21hY2hpbmU9cG93ZXJw
YzY0LXVua25vd24KKwkJOzsKKwlwcGM2NC0qKSBiYXNpY19tYWNoaW5lPXBvd2VycGM2NC1gZWNo
byAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0bGUgfCBw
b3dlcnBjNjRsaXR0bGUgfCBwcGM2NC1sZSB8IHBvd2VycGM2NC1saXR0bGUpCisJCWJhc2ljX21h
Y2hpbmU9cG93ZXJwYzY0bGUtdW5rbm93bgorCQk7OworCXBwYzY0bGUtKiB8IHBvd2VycGM2NGxp
dHRsZS0qKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLWBlY2hvICRiYXNpY19tYWNoaW5l
IHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcHMyKQorCQliYXNpY19tYWNoaW5lPWkzODYt
aWJtCisJCTs7CisJcHczMikKKwkJYmFzaWNfbWFjaGluZT1pNTg2LXVua25vd24KKwkJb3M9LXB3
MzIKKwkJOzsKKwlyZG9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LXJkb3MKKwkJ
OzsKKwlyb202OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1yb202OGsKKwkJb3M9LWNvZmYKKwkJ
OzsKKwlybVs0Nl0wMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNpZW1lbnMKKwkJOzsKKwlydHBj
IHwgcnRwYy0qKQorCQliYXNpY19tYWNoaW5lPXJvbXAtaWJtCisJCTs7CisJczM5MCB8IHMzOTAt
KikKKwkJYmFzaWNfbWFjaGluZT1zMzkwLWlibQorCQk7OworCXMzOTB4IHwgczM5MHgtKikKKwkJ
YmFzaWNfbWFjaGluZT1zMzkweC1pYm0KKwkJOzsKKwlzYTI5MjAwKQorCQliYXNpY19tYWNoaW5l
PWEyOWstYW1kCisJCW9zPS11ZGkKKwkJOzsKKwlzYjEpCisJCWJhc2ljX21hY2hpbmU9bWlwc2lz
YTY0c2IxLXVua25vd24KKwkJOzsKKwlzYjFlbCkKKwkJYmFzaWNfbWFjaGluZT1taXBzaXNhNjRz
YjFlbC11bmtub3duCisJCTs7CisJc2RlKQorCQliYXNpY19tYWNoaW5lPW1pcHNpc2EzMi1zZGUK
KwkJb3M9LWVsZgorCQk7OworCXNlaSkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNlaQorCQlvcz0t
c2VpdXgKKwkJOzsKKwlzZXF1ZW50KQorCQliYXNpY19tYWNoaW5lPWkzODYtc2VxdWVudAorCQk7
OworCXNoKQorCQliYXNpY19tYWNoaW5lPXNoLWhpdGFjaGkKKwkJb3M9LWhtcworCQk7OworCXNo
NWVsKQorCQliYXNpY19tYWNoaW5lPXNoNWxlLXVua25vd24KKwkJOzsKKwlzaDY0KQorCQliYXNp
Y19tYWNoaW5lPXNoNjQtdW5rbm93bgorCQk7OworCXNwYXJjbGl0ZS13cnMgfCBzaW1zby13cnMp
CisJCWJhc2ljX21hY2hpbmU9c3BhcmNsaXRlLXdycworCQlvcz0tdnh3b3JrcworCQk7OworCXNw
czcpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1idWxsCisJCW9zPS1zeXN2MgorCQk7OworCXNwdXIp
CisJCWJhc2ljX21hY2hpbmU9c3B1ci11bmtub3duCisJCTs7CisJc3QyMDAwKQorCQliYXNpY19t
YWNoaW5lPW02OGstdGFuZGVtCisJCTs7CisJc3RyYXR1cykKKwkJYmFzaWNfbWFjaGluZT1pODYw
LXN0cmF0dXMKKwkJb3M9LXN5c3Y0CisJCTs7CisJc3Ryb25nYXJtLSogfCB0aHVtYi0qKQorCQli
YXNpY19tYWNoaW5lPWFybS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8n
YAorCQk7OworCXN1bjIpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJv
czMpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3Vu
Mm9zNCkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlz
dW4zb3MzKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlz
dW4zb3M0KQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlz
dW40b3MzKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJ
c3VuNG9zNCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7Owor
CXN1bjRzb2wyKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJ
OzsKKwlzdW4zIHwgc3VuMy0qKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCTs7CisJc3Vu
NCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwg
cm9hZHJ1bm5lcikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFz
aWNfbWFjaGluZT1zdjEtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJh
c2ljX21hY2hpbmU9aTM4Ni1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCXQzZSkKKwkJYmFz
aWNfbWFjaGluZT1hbHBoYWV2NS1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJh
c2ljX21hY2hpbmU9dDkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworCXRpbGUqKQorCQliYXNp
Y19tYWNoaW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9LWxpbnV4LWdudQorCQk7Owor
CXR4MzkpCisJCWJhc2ljX21hY2hpbmU9bWlwc3R4MzktdW5rbm93bgorCQk7OworCXR4MzllbCkK
KwkJYmFzaWNfbWFjaGluZT1taXBzdHgzOWVsLXVua25vd24KKwkJOzsKKwl0b2FkMSkKKwkJYmFz
aWNfbWFjaGluZT1wZHAxMC14a2wKKwkJb3M9LXRvcHMyMAorCQk7OworCXRvd2VyIHwgdG93ZXIt
MzIpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1uY3IKKwkJOzsKKwl0cGYpCisJCWJhc2ljX21hY2hp
bmU9czM5MHgtaWJtCisJCW9zPS10cGYKKwkJOzsKKwl1ZGkyOWspCisJCWJhc2ljX21hY2hpbmU9
YTI5ay1hbWQKKwkJb3M9LXVkaQorCQk7OworCXVsdHJhMykKKwkJYmFzaWNfbWFjaGluZT1hMjlr
LW55dQorCQlvcz0tc3ltMQorCQk7OworCXY4MTAgfCBuZWN2ODEwKQorCQliYXNpY19tYWNoaW5l
PXY4MTAtbmVjCisJCW9zPS1ub25lCisJCTs7CisJdmF4dikKKwkJYmFzaWNfbWFjaGluZT12YXgt
ZGVjCisJCW9zPS1zeXN2CisJCTs7CisJdm1zKQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJ
b3M9LXZtcworCQk7OworCXZwcCp8dnh8dngtKikKKwkJYmFzaWNfbWFjaGluZT1mMzAxLWZ1aml0
c3UKKwkJOzsKKwl2eHdvcmtzOTYwKQorCQliYXNpY19tYWNoaW5lPWk5NjAtd3JzCisJCW9zPS12
eHdvcmtzCisJCTs7CisJdnh3b3JrczY4KQorCQliYXNpY19tYWNoaW5lPW02OGstd3JzCisJCW9z
PS12eHdvcmtzCisJCTs7CisJdnh3b3JrczI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLXdycwor
CQlvcz0tdnh3b3JrcworCQk7OworCXc2NSopCisJCWJhc2ljX21hY2hpbmU9dzY1LXdkYworCQlv
cz0tbm9uZQorCQk7OworCXc4OWstKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLXdpbmJvbmQK
KwkJb3M9LXByb2VsZgorCQk7OworCXhib3gpCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1wYworCQlv
cz0tbWluZ3czMgorCQk7OworCXhwcyB8IHhwczEwMCkKKwkJYmFzaWNfbWFjaGluZT14cHMxMDAt
aG9uZXl3ZWxsCisJCTs7CisJeHNjYWxlLSogfCB4c2NhbGVlW2JsXS0qKQorCQliYXNpY19tYWNo
aW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL154c2NhbGUvYXJtLydgCisJCTs7CisJ
eW1wKQorCQliYXNpY19tYWNoaW5lPXltcC1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl6OGst
Ki1jb2ZmKQorCQliYXNpY19tYWNoaW5lPXo4ay11bmtub3duCisJCW9zPS1zaW0KKwkJOzsKKwl6
ODAtKi1jb2ZmKQorCQliYXNpY19tYWNoaW5lPXo4MC11bmtub3duCisJCW9zPS1zaW0KKwkJOzsK
Kwlub25lKQorCQliYXNpY19tYWNoaW5lPW5vbmUtbm9uZQorCQlvcz0tbm9uZQorCQk7OworCisj
IEhlcmUgd2UgaGFuZGxlIHRoZSBkZWZhdWx0IG1hbnVmYWN0dXJlciBvZiBjZXJ0YWluIENQVSB0
eXBlcy4gIEl0IGlzIGluCisjIHNvbWUgY2FzZXMgdGhlIG9ubHkgbWFudWZhY3R1cmVyLCBpbiBv
dGhlcnMsIGl0IGlzIHRoZSBtb3N0IHBvcHVsYXIuCisJdzg5aykKKwkJYmFzaWNfbWFjaGluZT1o
cHBhMS4xLXdpbmJvbmQKKwkJOzsKKwlvcDUwbikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLW9r
aQorCQk7OworCW9wNjBjKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtb2tpCisJCTs7CisJcm9t
cCkKKwkJYmFzaWNfbWFjaGluZT1yb21wLWlibQorCQk7OworCW1taXgpCisJCWJhc2ljX21hY2hp
bmU9bW1peC1rbnV0aAorCQk7OworCXJzNjAwMCkKKwkJYmFzaWNfbWFjaGluZT1yczYwMDAtaWJt
CisJCTs7CisJdmF4KQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJOzsKKwlwZHAxMCkKKwkJ
IyB0aGVyZSBhcmUgbWFueSBjbG9uZXMsIHNvIERFQyBpcyBub3QgYSBzYWZlIGJldAorCQliYXNp
Y19tYWNoaW5lPXBkcDEwLXVua25vd24KKwkJOzsKKwlwZHAxMSkKKwkJYmFzaWNfbWFjaGluZT1w
ZHAxMS1kZWMKKwkJOzsKKwl3ZTMyaykKKwkJYmFzaWNfbWFjaGluZT13ZTMyay1hdHQKKwkJOzsK
KwlzaFsxMjM0XSB8IHNoWzI0XWEgfCBzaFsyNF1hZWIgfCBzaFszNF1lYiB8IHNoWzEyMzRdbGUg
fCBzaFsyM11lbGUpCisJCWJhc2ljX21hY2hpbmU9c2gtdW5rbm93bgorCQk7OworCXNwYXJjIHwg
c3BhcmN2OCB8IHNwYXJjdjkgfCBzcGFyY3Y5YiB8IHNwYXJjdjl2KQorCQliYXNpY19tYWNoaW5l
PXNwYXJjLXN1bgorCQk7OworCWN5ZHJhKQorCQliYXNpY19tYWNoaW5lPWN5ZHJhLWN5ZHJvbWUK
KwkJOzsKKwlvcmlvbikKKwkJYmFzaWNfbWFjaGluZT1vcmlvbi1oaWdobGV2ZWwKKwkJOzsKKwlv
cmlvbjEwNSkKKwkJYmFzaWNfbWFjaGluZT1jbGlwcGVyLWhpZ2hsZXZlbAorCQk7OworCW1hYyB8
IG1wdyB8IG1hYy1tcHcpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQk7OworCXBtYWMg
fCBwbWFjLW1wdykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWFwcGxlCisJCTs7CisJKi11bmtu
b3duKQorCQkjIE1ha2Ugc3VyZSB0byBtYXRjaCBhbiBhbHJlYWR5LWNhbm9uaWNhbGl6ZWQgbWFj
aGluZSBuYW1lLgorCQk7OworCSopCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFc
JzogbWFjaGluZSBcYCRiYXNpY19tYWNoaW5lXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0
IDEKKwkJOzsKK2VzYWMKKworIyBIZXJlIHdlIGNhbm9uaWNhbGl6ZSBjZXJ0YWluIGFsaWFzZXMg
Zm9yIG1hbnVmYWN0dXJlcnMuCitjYXNlICRiYXNpY19tYWNoaW5lIGluCisJKi1kaWdpdGFsKikK
KwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9kaWdpdGFsLiov
ZGVjLydgCisJCTs7CisJKi1jb21tb2RvcmUqKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNp
Y19tYWNoaW5lIHwgc2VkICdzL2NvbW1vZG9yZS4qL2NibS8nYAorCQk7OworCSopCisJCTs7Citl
c2FjCisKKyMgRGVjb2RlIG1hbnVmYWN0dXJlci1zcGVjaWZpYyBhbGlhc2VzIGZvciBjZXJ0YWlu
IG9wZXJhdGluZyBzeXN0ZW1zLgorCitpZiBbIHgiJG9zIiAhPSB4IiIgXQordGhlbgorY2FzZSAk
b3MgaW4KKwkjIEZpcnN0IG1hdGNoIHNvbWUgc3lzdGVtIHR5cGUgYWxpYXNlcworCSMgdGhhdCBt
aWdodCBnZXQgY29uZnVzZWQgd2l0aCB2YWxpZCBzeXN0ZW0gdHlwZXMuCisJIyAtc29sYXJpcyog
aXMgYSBiYXNpYyBzeXN0ZW0gdHlwZSwgd2l0aCB0aGlzIG9uZSBleGNlcHRpb24uCisJLWF1cm9y
YXV4KQorCQlvcz0tYXVyb3JhdXgKKwkJOzsKKwktc29sYXJpczEgfCAtc29sYXJpczEuKikKKwkJ
b3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHNvbGFyaXMxfHN1bm9zNHwnYAorCQk7OworCS1zb2xh
cmlzKQorCQlvcz0tc29sYXJpczIKKwkJOzsKKwktc3ZyNCopCisJCW9zPS1zeXN2NAorCQk7Owor
CS11bml4d2FyZSopCisJCW9zPS1zeXN2NC4ydXcKKwkJOzsKKwktZ251L2xpbnV4KikKKwkJb3M9
YGVjaG8gJG9zIHwgc2VkIC1lICdzfGdudS9saW51eHxsaW51eC1nbnV8J2AKKwkJOzsKKwkjIEZp
cnN0IGFjY2VwdCB0aGUgYmFzaWMgc3lzdGVtIHR5cGVzLgorCSMgVGhlIHBvcnRhYmxlIHN5c3Rl
bXMgY29tZXMgZmlyc3QuCisJIyBFYWNoIGFsdGVybmF0aXZlIE1VU1QgRU5EIElOIEEgKiwgdG8g
bWF0Y2ggYSB2ZXJzaW9uIG51bWJlci4KKwkjIC1zeXN2KiBpcyBub3QgaGVyZSBiZWNhdXNlIGl0
IGNvbWVzIGxhdGVyLCBhZnRlciBzeXN2cjQuCisJLWdudSogfCAtYnNkKiB8IC1tYWNoKiB8IC1t
aW5peCogfCAtZ2VuaXgqIHwgLXVsdHJpeCogfCAtaXJpeCogXAorCSAgICAgIHwgLSp2bXMqIHwg
LXNjbyogfCAtZXNpeCogfCAtaXNjKiB8IC1haXgqIHwgLWNuayogfCAtc3Vub3MgfCAtc3Vub3Nb
MzRdKlwKKwkgICAgICB8IC1ocHV4KiB8IC11bm9zKiB8IC1vc2YqIHwgLWx1bmEqIHwgLWRndXgq
IHwgLWF1cm9yYXV4KiB8IC1zb2xhcmlzKiBcCisJICAgICAgfCAtc3ltKiB8IC1rb3BlbnNvbGFy
aXMqIFwKKwkgICAgICB8IC1hbWlnYW9zKiB8IC1hbWlnYWRvcyogfCAtbXNkb3MqIHwgLW5ld3Nv
cyogfCAtdW5pY29zKiB8IC1hb2YqIFwKKwkgICAgICB8IC1hb3MqIHwgLWFyb3MqIFwKKwkgICAg
ICB8IC1uaW5keSogfCAtdnhzaW0qIHwgLXZ4d29ya3MqIHwgLWVibW9uKiB8IC1obXMqIHwgLW12
cyogXAorCSAgICAgIHwgLWNsaXgqIHwgLXJpc2NvcyogfCAtdW5pcGx1cyogfCAtaXJpcyogfCAt
cnR1KiB8IC14ZW5peCogXAorCSAgICAgIHwgLWhpdXgqIHwgLTM4NmJzZCogfCAta25ldGJzZCog
fCAtbWlyYnNkKiB8IC1uZXRic2QqIFwKKwkgICAgICB8IC1vcGVuYnNkKiB8IC1zb2xpZGJzZCog
XAorCSAgICAgIHwgLWVra29ic2QqIHwgLWtmcmVlYnNkKiB8IC1mcmVlYnNkKiB8IC1yaXNjaXgq
IHwgLWx5bnhvcyogXAorCSAgICAgIHwgLWJvc3gqIHwgLW5leHRzdGVwKiB8IC1jeHV4KiB8IC1h
b3V0KiB8IC1lbGYqIHwgLW9hYmkqIFwKKwkgICAgICB8IC1wdHgqIHwgLWNvZmYqIHwgLWVjb2Zm
KiB8IC13aW5udCogfCAtZG9tYWluKiB8IC12c3RhKiBcCisJICAgICAgfCAtdWRpKiB8IC1lYWJp
KiB8IC1saXRlcyogfCAtaWVlZSogfCAtZ28zMiogfCAtYXV4KiBcCisJICAgICAgfCAtY2hvcnVz
b3MqIHwgLWNob3J1c3JkYiogfCAtY2VnY2MqIFwKKwkgICAgICB8IC1jeWd3aW4qIHwgLW1zeXMq
IHwgLXBlKiB8IC1wc29zKiB8IC1tb3NzKiB8IC1wcm9lbGYqIHwgLXJ0ZW1zKiBcCisJICAgICAg
fCAtbWluZ3czMiogfCAtbGludXgtZ251KiB8IC1saW51eC1hbmRyb2lkKiBcCisJICAgICAgfCAt
bGludXgtbmV3bGliKiB8IC1saW51eC11Y2xpYmMqIFwKKwkgICAgICB8IC11eHB2KiB8IC1iZW9z
KiB8IC1tcGVpeCogfCAtdWRrKiBcCisJICAgICAgfCAtaW50ZXJpeCogfCAtdXdpbiogfCAtbWtz
KiB8IC1yaGFwc29keSogfCAtZGFyd2luKiB8IC1vcGVuZWQqIFwKKwkgICAgICB8IC1vcGVuc3Rl
cCogfCAtb3NraXQqIHwgLWNvbml4KiB8IC1wdzMyKiB8IC1ub25zdG9wdXgqIFwKKwkgICAgICB8
IC1zdG9ybS1jaGFvcyogfCAtdG9wczEwKiB8IC10ZW5leCogfCAtdG9wczIwKiB8IC1pdHMqIFwK
KwkgICAgICB8IC1vczIqIHwgLXZvcyogfCAtcGFsbW9zKiB8IC11Y2xpbnV4KiB8IC1udWNsZXVz
KiBcCisJICAgICAgfCAtbW9ycGhvcyogfCAtc3VwZXJ1eCogfCAtcnRtayogfCAtcnRtay1ub3Zh
KiB8IC13aW5kaXNzKiBcCisJICAgICAgfCAtcG93ZXJtYXgqIHwgLWRuaXgqIHwgLW54NiB8IC1u
eDcgfCAtc2VpKiB8IC1kcmFnb25mbHkqIFwKKwkgICAgICB8IC1za3lvcyogfCAtaGFpa3UqIHwg
LXJkb3MqIHwgLXRvcHBlcnMqIHwgLWRyb3BzKiB8IC1lcyopCisJIyBSZW1lbWJlciwgZWFjaCBh
bHRlcm5hdGl2ZSBNVVNUIEVORCBJTiAqLCB0byBtYXRjaCBhIHZlcnNpb24gbnVtYmVyLgorCQk7
OworCS1xbngqKQorCQljYXNlICRiYXNpY19tYWNoaW5lIGluCisJCSAgICB4ODYtKiB8IGkqODYt
KikKKwkJCTs7CisJCSAgICAqKQorCQkJb3M9LW50byRvcworCQkJOzsKKwkJZXNhYworCQk7Owor
CS1udG8tcW54KikKKwkJOzsKKwktbnRvKikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfG50
b3xudG8tcW54fCdgCisJCTs7CisJLXNpbSB8IC1lczE4MDAqIHwgLWhtcyogfCAteHJheSB8IC1v
czY4ayogfCAtbm9uZSogfCAtdjg4ciogXAorCSAgICAgIHwgLXdpbmRvd3MqIHwgLW9zeCB8IC1h
YnVnIHwgLW5ldHdhcmUqIHwgLW9zOSogfCAtYmVvcyogfCAtaGFpa3UqIFwKKwkgICAgICB8IC1t
YWNvcyogfCAtbXB3KiB8IC1tYWdpYyogfCAtbW1peHdhcmUqIHwgLW1vbjk2MCogfCAtbG5ld3Mq
KQorCQk7OworCS1tYWMqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bWFjfG1hY29zfCdg
CisJCTs7CisJLWxpbnV4LWRpZXRsaWJjKQorCQlvcz0tbGludXgtZGlldGxpYmMKKwkJOzsKKwkt
bGludXgqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bGludXh8bGludXgtZ251fCdgCisJ
CTs7CisJLXN1bm9zNSopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzdW5vczV8c29sYXJp
czJ8J2AKKwkJOzsKKwktc3Vub3M2KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHN1bm9z
Nnxzb2xhcmlzM3wnYAorCQk7OworCS1vcGVuZWQqKQorCQlvcz0tb3BlbmVkaXRpb24KKwkJOzsK
Kwktb3M0MDAqKQorCQlvcz0tb3M0MDAKKwkJOzsKKwktd2luY2UqKQorCQlvcz0td2luY2UKKwkJ
OzsKKwktb3Nmcm9zZSopCisJCW9zPS1vc2Zyb3NlCisJCTs7CisJLW9zZiopCisJCW9zPS1vc2YK
KwkJOzsKKwktdXRlayopCisJCW9zPS1ic2QKKwkJOzsKKwktZHluaXgqKQorCQlvcz0tYnNkCisJ
CTs7CisJLWFjaXMqKQorCQlvcz0tYW9zCisJCTs7CisJLWF0aGVvcyopCisJCW9zPS1hdGhlb3MK
KwkJOzsKKwktc3lsbGFibGUqKQorCQlvcz0tc3lsbGFibGUKKwkJOzsKKwktMzg2YnNkKQorCQlv
cz0tYnNkCisJCTs7CisJLWN0aXgqIHwgLXV0cyopCisJCW9zPS1zeXN2CisJCTs7CisJLW5vdmEq
KQorCQlvcz0tcnRtay1ub3ZhCisJCTs7CisJLW5zMiApCisJCW9zPS1uZXh0c3RlcDIKKwkJOzsK
KwktbnNrKikKKwkJb3M9LW5zaworCQk7OworCSMgUHJlc2VydmUgdGhlIHZlcnNpb24gbnVtYmVy
IG9mIHNpbml4NS4KKwktc2luaXg1LiopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzaW5p
eHxzeXN2fCdgCisJCTs7CisJLXNpbml4KikKKwkJb3M9LXN5c3Y0CisJCTs7CisJLXRwZiopCisJ
CW9zPS10cGYKKwkJOzsKKwktdHJpdG9uKikKKwkJb3M9LXN5c3YzCisJCTs7CisJLW9zcyopCisJ
CW9zPS1zeXN2MworCQk7OworCS1zdnI0KQorCQlvcz0tc3lzdjQKKwkJOzsKKwktc3ZyMykKKwkJ
b3M9LXN5c3YzCisJCTs7CisJLXN5c3ZyNCkKKwkJb3M9LXN5c3Y0CisJCTs7CisJIyBUaGlzIG11
c3QgY29tZSBhZnRlciAtc3lzdnI0LgorCS1zeXN2KikKKwkJOzsKKwktb3NlKikKKwkJb3M9LW9z
ZQorCQk7OworCS1lczE4MDAqKQorCQlvcz0tb3NlCisJCTs7CisJLXhlbml4KQorCQlvcz0teGVu
aXgKKwkJOzsKKwktKm1pbnQgfCAtbWludFswLTldKiB8IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQor
CQlvcz0tbWludAorCQk7OworCS1hcm9zKikKKwkJb3M9LWFyb3MKKwkJOzsKKwkta2FvcyopCisJ
CW9zPS1rYW9zCisJCTs7CisJLXp2bW9lKQorCQlvcz0tenZtb2UKKwkJOzsKKwktZGljb3MqKQor
CQlvcz0tZGljb3MKKwkJOzsKKwktbmFjbCopCisJCTs7CisJLW5vbmUpCisJCTs7CisJKikKKwkJ
IyBHZXQgcmlkIG9mIHRoZSBgLScgYXQgdGhlIGJlZ2lubmluZyBvZiAkb3MuCisJCW9zPWBlY2hv
ICRvcyB8IHNlZCAncy9bXi1dKi0vLydgCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxg
JDFcJzogc3lzdGVtIFxgJG9zXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJOzsK
K2VzYWMKK2Vsc2UKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBvcGVyYXRpbmcgc3lz
dGVtcyB0aGF0IGNvbWUgd2l0aCB2YXJpb3VzIG1hY2hpbmVzLgorIyBUaGUgdmFsdWUgc2hvdWxk
IGJlIHdoYXQgdGhlIHZlbmRvciBjdXJyZW50bHkgc2hpcHMgb3V0IHRoZSBkb29yIHdpdGggdGhl
aXIKKyMgbWFjaGluZSBvciBwdXQgYW5vdGhlciB3YXksIHRoZSBtb3N0IHBvcHVsYXIgb3MgcHJv
dmlkZWQgd2l0aCB0aGUgbWFjaGluZS4KKworIyBOb3RlIHRoYXQgaWYgeW91J3JlIGdvaW5nIHRv
IHRyeSB0byBtYXRjaCAiLU1BTlVGQUNUVVJFUiIgaGVyZSAoc2F5LAorIyAiLXN1biIpLCB0aGVu
IHlvdSBoYXZlIHRvIHRlbGwgdGhlIGNhc2Ugc3RhdGVtZW50IHVwIHRvd2FyZHMgdGhlIHRvcAor
IyB0aGF0IE1BTlVGQUNUVVJFUiBpc24ndCBhbiBvcGVyYXRpbmcgc3lzdGVtLiAgT3RoZXJ3aXNl
LCBjb2RlIGFib3ZlCisjIHdpbGwgc2lnbmFsIGFuIGVycm9yIHNheWluZyB0aGF0IE1BTlVGQUNU
VVJFUiBpc24ndCBhbiBvcGVyYXRpbmcKKyMgc3lzdGVtLCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IHRv
IHRoaXMgcG9pbnQuCisKK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwlzY29yZS0qKQorCQlvcz0t
ZWxmCisJCTs7CisJc3B1LSopCisJCW9zPS1lbGYKKwkJOzsKKwkqLWFjb3JuKQorCQlvcz0tcmlz
Y2l4MS4yCisJCTs7CisJYXJtKi1yZWJlbCkKKwkJb3M9LWxpbnV4CisJCTs7CisJYXJtKi1zZW1p
KQorCQlvcz0tYW91dAorCQk7OworCWM0eC0qIHwgdGljNHgtKikKKwkJb3M9LWNvZmYKKwkJOzsK
Kwl0aWM1NHgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM1NXgtKikKKwkJb3M9LWNvZmYKKwkJ
OzsKKwl0aWM2eC0qKQorCQlvcz0tY29mZgorCQk7OworCSMgVGhpcyBtdXN0IGNvbWUgYmVmb3Jl
IHRoZSAqLWRlYyBlbnRyeS4KKwlwZHAxMC0qKQorCQlvcz0tdG9wczIwCisJCTs7CisJcGRwMTEt
KikKKwkJb3M9LW5vbmUKKwkJOzsKKwkqLWRlYyB8IHZheC0qKQorCQlvcz0tdWx0cml4NC4yCisJ
CTs7CisJbTY4Ki1hcG9sbG8pCisJCW9zPS1kb21haW4KKwkJOzsKKwlpMzg2LXN1bikKKwkJb3M9
LXN1bm9zNC4wLjIKKwkJOzsKKwltNjgwMDAtc3VuKQorCQlvcz0tc3Vub3MzCisJCSMgVGhpcyBh
bHNvIGV4aXN0cyBpbiB0aGUgY29uZmlndXJlIHByb2dyYW0sIGJ1dCB3YXMgbm90IHRoZQorCQkj
IGRlZmF1bHQuCisJCSMgb3M9LXN1bm9zNAorCQk7OworCW02OCotY2lzY28pCisJCW9zPS1hb3V0
CisJCTs7CisJbWVwLSopCisJCW9zPS1lbGYKKwkJOzsKKwltaXBzKi1jaXNjbykKKwkJb3M9LWVs
ZgorCQk7OworCW1pcHMqLSopCisJCW9zPS1lbGYKKwkJOzsKKwlvcjMyLSopCisJCW9zPS1jb2Zm
CisJCTs7CisJKi10dGkpCSMgbXVzdCBiZSBiZWZvcmUgc3BhcmMgZW50cnkgb3Igd2UgZ2V0IHRo
ZSB3cm9uZyBvcy4KKwkJb3M9LXN5c3YzCisJCTs7CisJc3BhcmMtKiB8ICotc3VuKQorCQlvcz0t
c3Vub3M0LjEuMQorCQk7OworCSotYmUpCisJCW9zPS1iZW9zCisJCTs7CisJKi1oYWlrdSkKKwkJ
b3M9LWhhaWt1CisJCTs7CisJKi1pYm0pCisJCW9zPS1haXgKKwkJOzsKKwkqLWtudXRoKQorCQlv
cz0tbW1peHdhcmUKKwkJOzsKKwkqLXdlYykKKwkJb3M9LXByb2VsZgorCQk7OworCSotd2luYm9u
ZCkKKwkJb3M9LXByb2VsZgorCQk7OworCSotb2tpKQorCQlvcz0tcHJvZWxmCisJCTs7CisJKi1o
cCkKKwkJb3M9LWhwdXgKKwkJOzsKKwkqLWhpdGFjaGkpCisJCW9zPS1oaXV4CisJCTs7CisJaTg2
MC0qIHwgKi1hdHQgfCAqLW5jciB8ICotYWx0b3MgfCAqLW1vdG9yb2xhIHwgKi1jb252ZXJnZW50
KQorCQlvcz0tc3lzdgorCQk7OworCSotY2JtKQorCQlvcz0tYW1pZ2FvcworCQk7OworCSotZGcp
CisJCW9zPS1kZ3V4CisJCTs7CisJKi1kb2xwaGluKQorCQlvcz0tc3lzdjMKKwkJOzsKKwltNjhr
LWNjdXIpCisJCW9zPS1ydHUKKwkJOzsKKwltODhrLW9tcm9uKikKKwkJb3M9LWx1bmEKKwkJOzsK
KwkqLW5leHQgKQorCQlvcz0tbmV4dHN0ZXAKKwkJOzsKKwkqLXNlcXVlbnQpCisJCW9zPS1wdHgK
KwkJOzsKKwkqLWNyZHMpCisJCW9zPS11bm9zCisJCTs7CisJKi1ucykKKwkJb3M9LWdlbml4CisJ
CTs7CisJaTM3MC0qKQorCQlvcz0tbXZzCisJCTs7CisJKi1uZXh0KQorCQlvcz0tbmV4dHN0ZXAz
CisJCTs7CisJKi1nb3VsZCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWhpZ2hsZXZlbCkKKwkJb3M9
LWJzZAorCQk7OworCSotZW5jb3JlKQorCQlvcz0tYnNkCisJCTs7CisJKi1zZ2kpCisJCW9zPS1p
cml4CisJCTs7CisJKi1zaWVtZW5zKQorCQlvcz0tc3lzdjQKKwkJOzsKKwkqLW1hc3Njb21wKQor
CQlvcz0tcnR1CisJCTs7CisJZjMwWzAxXS1mdWppdHN1IHwgZjcwMC1mdWppdHN1KQorCQlvcz0t
dXhwdgorCQk7OworCSotcm9tNjhrKQorCQlvcz0tY29mZgorCQk7OworCSotKmJ1ZykKKwkJb3M9
LWNvZmYKKwkJOzsKKwkqLWFwcGxlKQorCQlvcz0tbWFjb3MKKwkJOzsKKwkqLWF0YXJpKikKKwkJ
b3M9LW1pbnQKKwkJOzsKKwkqKQorCQlvcz0tbm9uZQorCQk7OworZXNhYworZmkKKworIyBIZXJl
IHdlIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB3ZSBrbm93IHRoZSBvcywgYW5kIHRoZSBDUFUgdHlw
ZSwgYnV0IG5vdCB0aGUKKyMgbWFudWZhY3R1cmVyLiAgV2UgcGljayB0aGUgbG9naWNhbCBtYW51
ZmFjdHVyZXIuCit2ZW5kb3I9dW5rbm93bgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSotdW5r
bm93bikKKwkJY2FzZSAkb3MgaW4KKwkJCS1yaXNjaXgqKQorCQkJCXZlbmRvcj1hY29ybgorCQkJ
CTs7CisJCQktc3Vub3MqKQorCQkJCXZlbmRvcj1zdW4KKwkJCQk7OworCQkJLWNuayp8LWFpeCop
CisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktYmVvcyopCisJCQkJdmVuZG9yPWJlCisJCQkJ
OzsKKwkJCS1ocHV4KikKKwkJCQl2ZW5kb3I9aHAKKwkJCQk7OworCQkJLW1wZWl4KikKKwkJCQl2
ZW5kb3I9aHAKKwkJCQk7OworCQkJLWhpdXgqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsK
KwkJCS11bm9zKikKKwkJCQl2ZW5kb3I9Y3JkcworCQkJCTs7CisJCQktZGd1eCopCisJCQkJdmVu
ZG9yPWRnCisJCQkJOzsKKwkJCS1sdW5hKikKKwkJCQl2ZW5kb3I9b21yb24KKwkJCQk7OworCQkJ
LWdlbml4KikKKwkJCQl2ZW5kb3I9bnMKKwkJCQk7OworCQkJLW12cyogfCAtb3BlbmVkKikKKwkJ
CQl2ZW5kb3I9aWJtCisJCQkJOzsKKwkJCS1vczQwMCopCisJCQkJdmVuZG9yPWlibQorCQkJCTs7
CisJCQktcHR4KikKKwkJCQl2ZW5kb3I9c2VxdWVudAorCQkJCTs7CisJCQktdHBmKikKKwkJCQl2
ZW5kb3I9aWJtCisJCQkJOzsKKwkJCS12eHNpbSogfCAtdnh3b3JrcyogfCAtd2luZGlzcyopCisJ
CQkJdmVuZG9yPXdycworCQkJCTs7CisJCQktYXV4KikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7
OworCQkJLWhtcyopCisJCQkJdmVuZG9yPWhpdGFjaGkKKwkJCQk7OworCQkJLW1wdyogfCAtbWFj
b3MqKQorCQkJCXZlbmRvcj1hcHBsZQorCQkJCTs7CisJCQktKm1pbnQgfCAtbWludFswLTldKiB8
IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQorCQkJCXZlbmRvcj1hdGFyaQorCQkJCTs7CisJCQktdm9z
KikKKwkJCQl2ZW5kb3I9c3RyYXR1cworCQkJCTs7CisJCWVzYWMKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAicy91bmtub3duLyR2ZW5kb3IvImAKKwkJOzsKK2Vz
YWMKKworZWNobyAkYmFzaWNfbWFjaGluZSRvcworZXhpdAorCisjIExvY2FsIHZhcmlhYmxlczoK
KyMgZXZhbDogKGFkZC1ob29rICd3cml0ZS1maWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1l
LXN0YW1wLXN0YXJ0OiAidGltZXN0YW1wPSciCisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUw
Mm0tJTAyZCIKKyMgdGltZS1zdGFtcC1lbmQ6ICInIgorIyBFbmQ6CmRpZmYgLXIgZTI3MjJiMjRk
YzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlndXJlCVdlZCBKYW4gMTEg
MDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwMjA0IEBACisjISAvYmluL3NoCisjIEd1
ZXNzIHZhbHVlcyBmb3Igc3lzdGVtLWRlcGVuZGVudCB2YXJpYWJsZXMgYW5kIGNyZWF0ZSBNYWtl
ZmlsZXMuCisjIEdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OCBmb3IgWGVuIEh5cGVydmlz
b3IgNC4yLgorIworIyBSZXBvcnQgYnVncyB0byA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20+LgorIworIworIyBDb3B5cmlnaHQgKEMpIDE5OTIsIDE5OTMsIDE5OTQsIDE5OTUsIDE5OTYs
IDE5OTgsIDE5OTksIDIwMDAsIDIwMDEsCisjIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYs
IDIwMDcsIDIwMDgsIDIwMDksIDIwMTAgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMu
CisjCisjCisjIFRoaXMgY29uZmlndXJlIHNjcmlwdCBpcyBmcmVlIHNvZnR3YXJlOyB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uCisjIGdpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNv
cHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4KKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMj
CisjIyBNNHNoIEluaXRpYWxpemF0aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMK
KworIyBCZSBtb3JlIEJvdXJuZSBjb21wYXRpYmxlCitEVUFMQ0FTRT0xOyBleHBvcnQgRFVBTENB
U0UgIyBmb3IgTUtTIHNoCitpZiB0ZXN0IC1uICIke1pTSF9WRVJTSU9OK3NldH0iICYmIChlbXVs
YXRlIHNoKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9
OgorICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uICR7MSsi
JEAifSwgd2hpY2gKKyAgIyBpcyBjb250cmFyeSB0byBvdXIgdXNhZ2UuICBEaXNhYmxlIHRoaXMg
ZmVhdHVyZS4KKyAgYWxpYXMgLWcgJyR7MSsiJEAifSc9JyIkQCInCisgIHNldG9wdCBOT19HTE9C
X1NVQlNUCitlbHNlCisgIGNhc2UgYChzZXQgLW8pIDI+L2Rldi9udWxsYCBpbiAjKAorICAqcG9z
aXgqKSA6CisgICAgc2V0IC1vIHBvc2l4IDs7ICMoCisgICopIDoKKyAgICAgOzsKK2VzYWMKK2Zp
CisKKworYXNfbmw9JworJworZXhwb3J0IGFzX25sCisjIFByaW50aW5nIGEgbG9uZyBzdHJpbmcg
Y3Jhc2hlcyBTb2xhcmlzIDcgL3Vzci9iaW4vcHJpbnRmLgorYXNfZWNobz0nXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXCcKK2FzX2VjaG89JGFzX2VjaG8kYXNf
ZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobworYXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFz
X2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8KKyMgUHJlZmVyIGEga3NoIHNoZWxsIGJ1aWx0
aW4gb3ZlciBhbiBleHRlcm5hbCBwcmludGYgcHJvZ3JhbSBvbiBTb2xhcmlzLAorIyBidXQgd2l0
aG91dCB3YXN0aW5nIGZvcmtzIGZvciBiYXNoIG9yIHpzaC4KK2lmIHRlc3QgLXogIiRCQVNIX1ZF
UlNJT04kWlNIX1ZFUlNJT04iIFwKKyAgICAmJiAodGVzdCAiWGBwcmludCAtciAtLSAkYXNfZWNo
b2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50IC1y
IC0tJworICBhc19lY2hvX249J3ByaW50IC1ybiAtLScKK2VsaWYgKHRlc3QgIlhgcHJpbnRmICVz
ICRhc19lY2hvYCIgPSAiWCRhc19lY2hvIikgMj4vZGV2L251bGw7IHRoZW4KKyAgYXNfZWNobz0n
cHJpbnRmICVzXG4nCisgIGFzX2VjaG9fbj0ncHJpbnRmICVzJworZWxzZQorICBpZiB0ZXN0ICJY
YCgvdXNyL3VjYi9lY2hvIC1uIC1uICRhc19lY2hvKSAyPi9kZXYvbnVsbGAiID0gIlgtbiAkYXNf
ZWNobyI7IHRoZW4KKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgL3Vzci91Y2IvZWNobyAtbiAiJDEk
YXNfbmwiJworICAgIGFzX2VjaG9fbj0nL3Vzci91Y2IvZWNobyAtbicKKyAgZWxzZQorICAgIGFz
X2VjaG9fYm9keT0nZXZhbCBleHByICJYJDEiIDogIlhcXCguKlxcKSInCisgICAgYXNfZWNob19u
X2JvZHk9J2V2YWwKKyAgICAgIGFyZz0kMTsKKyAgICAgIGNhc2UgJGFyZyBpbiAjKAorICAgICAg
KiIkYXNfbmwiKikKKwlleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpJGFzX25sIjsKKwlhcmc9YGV4
cHIgIlgkYXJnIiA6ICIuKiRhc19ubFxcKC4qXFwpImA7OworICAgICAgZXNhYzsKKyAgICAgIGV4
cHIgIlgkYXJnIiA6ICJYXFwoLipcXCkiIHwgdHIgLWQgIiRhc19ubCIKKyAgICAnCisgICAgZXhw
b3J0IGFzX2VjaG9fbl9ib2R5CisgICAgYXNfZWNob19uPSdzaCAtYyAkYXNfZWNob19uX2JvZHkg
YXNfZWNobycKKyAgZmkKKyAgZXhwb3J0IGFzX2VjaG9fYm9keQorICBhc19lY2hvPSdzaCAtYyAk
YXNfZWNob19ib2R5IGFzX2VjaG8nCitmaQorCisjIFRoZSB1c2VyIGlzIGFsd2F5cyByaWdodC4K
K2lmIHRlc3QgIiR7UEFUSF9TRVBBUkFUT1Irc2V0fSIgIT0gc2V0OyB0aGVuCisgIFBBVEhfU0VQ
QVJBVE9SPToKKyAgKFBBVEg9Jy9iaW47L2Jpbic7IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rl
di9udWxsIDI+JjEgJiYgeworICAgIChQQVRIPScvYmluOi9iaW4nOyBGUEFUSD0kUEFUSDsgc2gg
LWMgOikgPi9kZXYvbnVsbCAyPiYxIHx8CisgICAgICBQQVRIX1NFUEFSQVRPUj0nOycKKyAgfQor
ZmkKKworCisjIElGUworIyBXZSBuZWVkIHNwYWNlLCB0YWIgYW5kIG5ldyBsaW5lLCBpbiBwcmVj
aXNlbHkgdGhhdCBvcmRlci4gIFF1b3RpbmcgaXMKKyMgdGhlcmUgdG8gcHJldmVudCBlZGl0b3Jz
IGZyb20gY29tcGxhaW5pbmcgYWJvdXQgc3BhY2UtdGFiLgorIyAoSWYgX0FTX1BBVEhfV0FMSyB3
ZXJlIGNhbGxlZCB3aXRoIElGUyB1bnNldCwgaXQgd291bGQgZGlzYWJsZSB3b3JkCisjIHNwbGl0
dGluZyBieSBzZXR0aW5nIElGUyB0byBlbXB0eSB2YWx1ZS4pCitJRlM9IiAiIgkkYXNfbmwiCisK
KyMgRmluZCB3aG8gd2UgYXJlLiAgTG9vayBpbiB0aGUgcGF0aCBpZiB3ZSBjb250YWluIG5vIGRp
cmVjdG9yeSBzZXBhcmF0b3IuCithc19teXNlbGY9CitjYXNlICQwIGluICMoKAorICAqW1xcL10q
ICkgYXNfbXlzZWxmPSQwIDs7CisgICopIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICB0ZXN0IC1yICIkYXNfZGlyLyQwIiAmJiBh
c19teXNlbGY9JGFzX2Rpci8kMCAmJiBicmVhaworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgICAgOzsKK2VzYWMKKyMgV2UgZGlkIG5vdCBmaW5kIG91cnNlbHZlcywgbW9zdCBwcm9iYWJs
eSB3ZSB3ZXJlIHJ1biBhcyBgc2ggQ09NTUFORCcKKyMgaW4gd2hpY2ggY2FzZSB3ZSBhcmUgbm90
IHRvIGJlIGZvdW5kIGluIHRoZSBwYXRoLgoraWYgdGVzdCAieCRhc19teXNlbGYiID0geDsgdGhl
bgorICBhc19teXNlbGY9JDAKK2ZpCitpZiB0ZXN0ICEgLWYgIiRhc19teXNlbGYiOyB0aGVuCisg
ICRhc19lY2hvICIkYXNfbXlzZWxmOiBlcnJvcjogY2Fubm90IGZpbmQgbXlzZWxmOyByZXJ1biB3
aXRoIGFuIGFic29sdXRlIGZpbGUgbmFtZSIgPiYyCisgIGV4aXQgMQorZmkKKworIyBVbnNldCB2
YXJpYWJsZXMgdGhhdCB3ZSBkbyBub3QgbmVlZCBhbmQgd2hpY2ggY2F1c2UgYnVncyAoZS5nLiBp
bgorIyBwcmUtMy4wIFVXSU4ga3NoKS4gIEJ1dCBkbyBub3QgY2F1c2UgYnVncyBpbiBiYXNoIDIu
MDE7IHRoZSAifHwgZXhpdCAxIgorIyBzdXBwcmVzc2VzIGFueSAiU2VnbWVudGF0aW9uIGZhdWx0
IiBtZXNzYWdlIHRoZXJlLiAgJygoJyBjb3VsZAorIyB0cmlnZ2VyIGEgYnVnIGluIHBka3NoIDUu
Mi4xNC4KK2ZvciBhc192YXIgaW4gQkFTSF9FTlYgRU5WIE1BSUwgTUFJTFBBVEgKK2RvIGV2YWwg
dGVzdCB4XCR7JGFzX3ZhcitzZXR9ID0geHNldCBcCisgICYmICggKHVuc2V0ICRhc192YXIpIHx8
IGV4aXQgMSkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0ICRhc192YXIgfHwgOgorZG9uZQorUFMx
PSckICcKK1BTMj0nPiAnCitQUzQ9JysgJworCisjIE5MUyBudWlzYW5jZXMuCitMQ19BTEw9Qwor
ZXhwb3J0IExDX0FMTAorTEFOR1VBR0U9QworZXhwb3J0IExBTkdVQUdFCisKKyMgQ0RQQVRILgor
KHVuc2V0IENEUEFUSCkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IENEUEFUSAorCitpZiB0ZXN0
ICJ4JENPTkZJR19TSEVMTCIgPSB4OyB0aGVuCisgIGFzX2JvdXJuZV9jb21wYXRpYmxlPSJpZiB0
ZXN0IC1uIFwiXCR7WlNIX1ZFUlNJT04rc2V0fVwiICYmIChlbXVsYXRlIHNoKSA+L2Rldi9udWxs
IDI+JjE7IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAjIFByZS00LjIgdmVy
c2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uIFwkezErXCJcJEBcIn0sIHdoaWNoCisg
ICMgaXMgY29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFs
aWFzIC1nICdcJHsxK1wiXCRAXCJ9Jz0nXCJcJEBcIicKKyAgc2V0b3B0IE5PX0dMT0JfU1VCU1QK
K2Vsc2UKKyAgY2FzZSBcYChzZXQgLW8pIDI+L2Rldi9udWxsXGAgaW4gIygKKyAgKnBvc2l4Kikg
OgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorIgor
ICBhc19yZXF1aXJlZD0iYXNfZm5fcmV0dXJuICgpIHsgKGV4aXQgXCQxKTsgfQorYXNfZm5fc3Vj
Y2VzcyAoKSB7IGFzX2ZuX3JldHVybiAwOyB9Cithc19mbl9mYWlsdXJlICgpIHsgYXNfZm5fcmV0
dXJuIDE7IH0KK2FzX2ZuX3JldF9zdWNjZXNzICgpIHsgcmV0dXJuIDA7IH0KK2FzX2ZuX3JldF9m
YWlsdXJlICgpIHsgcmV0dXJuIDE7IH0KKworZXhpdGNvZGU9MAorYXNfZm5fc3VjY2VzcyB8fCB7
IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fc3VjY2VzcyBmYWlsZWQuOyB9Cithc19mbl9mYWlsdXJl
ICYmIHsgZXhpdGNvZGU9MTsgZWNobyBhc19mbl9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2FzX2Zu
X3JldF9zdWNjZXNzIHx8IHsgZXhpdGNvZGU9MTsgZWNobyBhc19mbl9yZXRfc3VjY2VzcyBmYWls
ZWQuOyB9Cithc19mbl9yZXRfZmFpbHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fcmV0
X2ZhaWx1cmUgc3VjY2VlZGVkLjsgfQoraWYgKCBzZXQgeDsgYXNfZm5fcmV0X3N1Y2Nlc3MgeSAm
JiB0ZXN0IHggPSBcIlwkMVwiICk7IHRoZW4gOgorCitlbHNlCisgIGV4aXRjb2RlPTE7IGVjaG8g
cG9zaXRpb25hbCBwYXJhbWV0ZXJzIHdlcmUgbm90IHNhdmVkLgorZmkKK3Rlc3QgeFwkZXhpdGNv
ZGUgPSB4MCB8fCBleGl0IDEiCisgIGFzX3N1Z2dlc3RlZD0iICBhc19saW5lbm9fMT0iO2FzX3N1
Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCIg
YXNfbGluZW5vXzFhPVwkTElORU5PCisgIGFzX2xpbmVub18yPSI7YXNfc3VnZ2VzdGVkPSRhc19z
dWdnZXN0ZWQkTElORU5PO2FzX3N1Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkIiBhc19saW5lbm9fMmE9
XCRMSU5FTk8KKyAgZXZhbCAndGVzdCBcInhcJGFzX2xpbmVub18xJ1wkYXNfcnVuJ1wiICE9IFwi
eFwkYXNfbGluZW5vXzInXCRhc19ydW4nXCIgJiYKKyAgdGVzdCBcInhcYGV4cHIgXCRhc19saW5l
bm9fMSdcJGFzX3J1bicgKyAxXGBcIiA9IFwieFwkYXNfbGluZW5vXzInXCRhc19ydW4nXCInIHx8
IGV4aXQgMQordGVzdCBcJCgoIDEgKyAxICkpID0gMiB8fCBleGl0IDEiCisgIGlmIChldmFsICIk
YXNfcmVxdWlyZWQiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGFzX2hhdmVfcmVxdWlyZWQ9eWVz
CitlbHNlCisgIGFzX2hhdmVfcmVxdWlyZWQ9bm8KK2ZpCisgIGlmIHRlc3QgeCRhc19oYXZlX3Jl
cXVpcmVkID0geHllcyAmJiAoZXZhbCAiJGFzX3N1Z2dlc3RlZCIpIDI+L2Rldi9udWxsOyB0aGVu
IDoKKworZWxzZQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCithc19m
b3VuZD1mYWxzZQorZm9yIGFzX2RpciBpbiAvYmluJFBBVEhfU0VQQVJBVE9SL3Vzci9iaW4kUEFU
SF9TRVBBUkFUT1IkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNf
ZGlyIiAmJiBhc19kaXI9LgorICBhc19mb3VuZD06CisgIGNhc2UgJGFzX2RpciBpbiAjKAorCSAv
KikKKwkgICBmb3IgYXNfYmFzZSBpbiBzaCBiYXNoIGtzaCBzaDU7IGRvCisJICAgICAjIFRyeSBv
bmx5IHNoZWxscyB0aGF0IGV4aXN0LCB0byBzYXZlIHNldmVyYWwgZm9ya3MuCisJICAgICBhc19z
aGVsbD0kYXNfZGlyLyRhc19iYXNlCisJICAgICBpZiB7IHRlc3QgLWYgIiRhc19zaGVsbCIgfHwg
dGVzdCAtZiAiJGFzX3NoZWxsLmV4ZSI7IH0gJiYKKwkJICAgIHsgJGFzX2VjaG8gIiRhc19ib3Vy
bmVfY29tcGF0aWJsZSIiJGFzX3JlcXVpcmVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9IDI+
L2Rldi9udWxsOyB0aGVuIDoKKyAgQ09ORklHX1NIRUxMPSRhc19zaGVsbCBhc19oYXZlX3JlcXVp
cmVkPXllcworCQkgICBpZiB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUiIiRhc19z
dWdnZXN0ZWQiIHwgYXNfcnVuPWEgIiRhc19zaGVsbCI7IH0gMj4vZGV2L251bGw7IHRoZW4gOgor
ICBicmVhayAyCitmaQorZmkKKwkgICBkb25lOzsKKyAgICAgICBlc2FjCisgIGFzX2ZvdW5kPWZh
bHNlCitkb25lCiskYXNfZm91bmQgfHwgeyBpZiB7IHRlc3QgLWYgIiRTSEVMTCIgfHwgdGVzdCAt
ZiAiJFNIRUxMLmV4ZSI7IH0gJiYKKwkgICAgICB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBh
dGlibGUiIiRhc19yZXF1aXJlZCIgfCBhc19ydW49YSAiJFNIRUxMIjsgfSAyPi9kZXYvbnVsbDsg
dGhlbiA6CisgIENPTkZJR19TSEVMTD0kU0hFTEwgYXNfaGF2ZV9yZXF1aXJlZD15ZXMKK2ZpOyB9
CitJRlM9JGFzX3NhdmVfSUZTCisKKworICAgICAgaWYgdGVzdCAieCRDT05GSUdfU0hFTEwiICE9
IHg7IHRoZW4gOgorICAjIFdlIGNhbm5vdCB5ZXQgYXNzdW1lIGEgZGVjZW50IHNoZWxsLCBzbyB3
ZSBoYXZlIHRvIHByb3ZpZGUgYQorCSMgbmV1dHJhbGl6YXRpb24gdmFsdWUgZm9yIHNoZWxscyB3
aXRob3V0IHVuc2V0OyBhbmQgdGhpcyBhbHNvCisJIyB3b3JrcyBhcm91bmQgc2hlbGxzIHRoYXQg
Y2Fubm90IHVuc2V0IG5vbmV4aXN0ZW50IHZhcmlhYmxlcy4KKwkjIFByZXNlcnZlIC12IGFuZCAt
eCB0byB0aGUgcmVwbGFjZW1lbnQgc2hlbGwuCisJQkFTSF9FTlY9L2Rldi9udWxsCisJRU5WPS9k
ZXYvbnVsbAorCSh1bnNldCBCQVNIX0VOVikgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IEJBU0hf
RU5WIEVOVgorCWV4cG9ydCBDT05GSUdfU0hFTEwKKwljYXNlICQtIGluICMgKCgoKAorCSAgKnYq
eCogfCAqeCp2KiApIGFzX29wdHM9LXZ4IDs7CisJICAqdiogKSBhc19vcHRzPS12IDs7CisJICAq
eCogKSBhc19vcHRzPS14IDs7CisJICAqICkgYXNfb3B0cz0gOzsKKwllc2FjCisJZXhlYyAiJENP
TkZJR19TSEVMTCIgJGFzX29wdHMgIiRhc19teXNlbGYiICR7MSsiJEAifQorZmkKKworICAgIGlm
IHRlc3QgeCRhc19oYXZlX3JlcXVpcmVkID0geG5vOyB0aGVuIDoKKyAgJGFzX2VjaG8gIiQwOiBU
aGlzIHNjcmlwdCByZXF1aXJlcyBhIHNoZWxsIG1vcmUgbW9kZXJuIHRoYW4gYWxsIgorICAkYXNf
ZWNobyAiJDA6IHRoZSBzaGVsbHMgdGhhdCBJIGZvdW5kIG9uIHlvdXIgc3lzdGVtLiIKKyAgaWYg
dGVzdCB4JHtaU0hfVkVSU0lPTitzZXR9ID0geHNldCA7IHRoZW4KKyAgICAkYXNfZWNobyAiJDA6
IEluIHBhcnRpY3VsYXIsIHpzaCAkWlNIX1ZFUlNJT04gaGFzIGJ1Z3MgYW5kIHNob3VsZCIKKyAg
ICAkYXNfZWNobyAiJDA6IGJlIHVwZ3JhZGVkIHRvIHpzaCA0LjMuNCBvciBsYXRlci4iCisgIGVs
c2UKKyAgICAkYXNfZWNobyAiJDA6IFBsZWFzZSB0ZWxsIGJ1Zy1hdXRvY29uZkBnbnUub3JnIGFu
ZAorJDA6IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIGFib3V0IHlvdXIgc3lzdGVtLAor
JDA6IGluY2x1ZGluZyBhbnkgZXJyb3IgcG9zc2libHkgb3V0cHV0IGJlZm9yZSB0aGlzCiskMDog
bWVzc2FnZS4gVGhlbiBpbnN0YWxsIGEgbW9kZXJuIHNoZWxsLCBvciBtYW51YWxseSBydW4KKyQw
OiB0aGUgc2NyaXB0IHVuZGVyIHN1Y2ggYSBzaGVsbCBpZiB5b3UgZG8gaGF2ZSBvbmUuIgorICBm
aQorICBleGl0IDEKK2ZpCitmaQorZmkKK1NIRUxMPSR7Q09ORklHX1NIRUxMLS9iaW4vc2h9Citl
eHBvcnQgU0hFTEwKKyMgVW5zZXQgbW9yZSB2YXJpYWJsZXMga25vd24gdG8gaW50ZXJmZXJlIHdp
dGggYmVoYXZpb3Igb2YgY29tbW9uIHRvb2xzLgorQ0xJQ09MT1JfRk9SQ0U9IEdSRVBfT1BUSU9O
Uz0KK3Vuc2V0IENMSUNPTE9SX0ZPUkNFIEdSRVBfT1BUSU9OUworCisjIyAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0gIyMKKyMjIE00c2ggU2hlbGwgRnVuY3Rpb25zLiAjIworIyMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tICMjCisjIGFzX2ZuX3Vuc2V0IFZBUgorIyAtLS0tLS0tLS0tLS0tLS0KKyMgUG9y
dGFibHkgdW5zZXQgVkFSLgorYXNfZm5fdW5zZXQgKCkKK3sKKyAgeyBldmFsICQxPTsgdW5zZXQg
JDE7fQorfQorYXNfdW5zZXQ9YXNfZm5fdW5zZXQKKworIyBhc19mbl9zZXRfc3RhdHVzIFNUQVRV
UworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBTZXQgJD8gdG8gU1RBVFVTLCB3aXRob3V0
IGZvcmtpbmcuCithc19mbl9zZXRfc3RhdHVzICgpCit7CisgIHJldHVybiAkMQorfSAjIGFzX2Zu
X3NldF9zdGF0dXMKKworIyBhc19mbl9leGl0IFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLQor
IyBFeGl0IHRoZSBzaGVsbCB3aXRoIFNUQVRVUywgZXZlbiBpbiBhICJ0cmFwIDAiIG9yICJzZXQg
LWUiIGNvbnRleHQuCithc19mbl9leGl0ICgpCit7CisgIHNldCArZQorICBhc19mbl9zZXRfc3Rh
dHVzICQxCisgIGV4aXQgJDEKK30gIyBhc19mbl9leGl0CisKKyMgYXNfZm5fbWtkaXJfcAorIyAt
LS0tLS0tLS0tLS0tCisjIENyZWF0ZSAiJGFzX2RpciIgYXMgYSBkaXJlY3RvcnksIGluY2x1ZGlu
ZyBwYXJlbnRzIGlmIG5lY2Vzc2FyeS4KK2FzX2ZuX21rZGlyX3AgKCkKK3sKKworICBjYXNlICRh
c19kaXIgaW4gIygKKyAgLSopIGFzX2Rpcj0uLyRhc19kaXI7OworICBlc2FjCisgIHRlc3QgLWQg
IiRhc19kaXIiIHx8IGV2YWwgJGFzX21rZGlyX3AgfHwgeworICAgIGFzX2RpcnM9CisgICAgd2hp
bGUgOjsgZG8KKyAgICAgIGNhc2UgJGFzX2RpciBpbiAjKAorICAgICAgKlwnKikgYXNfcWRpcj1g
JGFzX2VjaG8gIiRhc19kaXIiIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgIycoCisgICAg
ICAqKSBhc19xZGlyPSRhc19kaXI7OworICAgICAgZXNhYworICAgICAgYXNfZGlycz0iJyRhc19x
ZGlyJyAkYXNfZGlycyIKKyAgICAgIGFzX2Rpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19kaXIiIHx8
CiskYXNfZXhwciBYIiRhc19kaXIiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBc
CisJIFgiJGFzX2RpciIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgv
L1wpJCcgXHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAor
JGFzX2VjaG8gWCIkYXNfZGlyIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14v
XSpcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4q
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMv
L1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBx
CisJICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgICAgIHRlc3QgLWQgIiRhc19kaXIiICYmIGJyZWFr
CisgICAgZG9uZQorICAgIHRlc3QgLXogIiRhc19kaXJzIiB8fCBldmFsICJta2RpciAkYXNfZGly
cyIKKyAgfSB8fCB0ZXN0IC1kICIkYXNfZGlyIiB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNy
ZWF0ZSBkaXJlY3RvcnkgJGFzX2RpciIKKworCit9ICMgYXNfZm5fbWtkaXJfcAorIyBhc19mbl9h
cHBlbmQgVkFSIFZBTFVFCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgQXBwZW5kIHRoZSB0
ZXh0IGluIFZBTFVFIHRvIHRoZSBlbmQgb2YgdGhlIGRlZmluaXRpb24gY29udGFpbmVkIGluIFZB
Ui4gVGFrZQorIyBhZHZhbnRhZ2Ugb2YgYW55IHNoZWxsIG9wdGltaXphdGlvbnMgdGhhdCBhbGxv
dyBhbW9ydGl6ZWQgbGluZWFyIGdyb3d0aCBvdmVyCisjIHJlcGVhdGVkIGFwcGVuZHMsIGluc3Rl
YWQgb2YgdGhlIHR5cGljYWwgcXVhZHJhdGljIGdyb3d0aCBwcmVzZW50IGluIG5haXZlCisjIGlt
cGxlbWVudGF0aW9ucy4KK2lmIChldmFsICJhc192YXI9MTsgYXNfdmFyKz0yOyB0ZXN0IHhcJGFz
X3ZhciA9IHgxMiIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXBwZW5kICgp
CisgIHsKKyAgICBldmFsICQxKz1cJDIKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXBwZW5kICgpCisg
IHsKKyAgICBldmFsICQxPVwkJDFcJDIKKyAgfQorZmkgIyBhc19mbl9hcHBlbmQKKworIyBhc19m
bl9hcml0aCBBUkcuLi4KKyMgLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBlcmZvcm0gYXJpdGhtZXRp
YyBldmFsdWF0aW9uIG9uIHRoZSBBUkdzLCBhbmQgc3RvcmUgdGhlIHJlc3VsdCBpbiB0aGUKKyMg
Z2xvYmFsICRhc192YWwuIFRha2UgYWR2YW50YWdlIG9mIHNoZWxscyB0aGF0IGNhbiBhdm9pZCBm
b3Jrcy4gVGhlIGFyZ3VtZW50cworIyBtdXN0IGJlIHBvcnRhYmxlIGFjcm9zcyAkKCgpKSBhbmQg
ZXhwci4KK2lmIChldmFsICJ0ZXN0IFwkKCggMSArIDEgKSkgPSAyIikgMj4vZGV2L251bGw7IHRo
ZW4gOgorICBldmFsICdhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPSQoKCAkKiApKQor
ICB9JworZWxzZQorICBhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPWBleHByICIkQCIg
fHwgdGVzdCAkPyAtZXEgMWAKKyAgfQorZmkgIyBhc19mbl9hcml0aAorCisKKyMgYXNfZm5fZXJy
b3IgU1RBVFVTIEVSUk9SIFtMSU5FTk8gTE9HX0ZEXQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCisjIE91dHB1dCAiYGJhc2VuYW1lICQwYDogZXJyb3I6IEVSUk9S
IiB0byBzdGRlcnIuIElmIExJTkVOTyBhbmQgTE9HX0ZEIGFyZQorIyBwcm92aWRlZCwgYWxzbyBv
dXRwdXQgdGhlIGVycm9yIHRvIExPR19GRCwgcmVmZXJlbmNpbmcgTElORU5PLiBUaGVuIGV4aXQg
dGhlCisjIHNjcmlwdCB3aXRoIFNUQVRVUywgdXNpbmcgMSBpZiB0aGF0IHdhcyAwLgorYXNfZm5f
ZXJyb3IgKCkKK3sKKyAgYXNfc3RhdHVzPSQxOyB0ZXN0ICRhc19zdGF0dXMgLWVxIDAgJiYgYXNf
c3RhdHVzPTEKKyAgaWYgdGVzdCAiJDQiOyB0aGVuCisgICAgYXNfbGluZW5vPSR7YXNfbGluZW5v
LSIkMyJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiAkMiIgPiYk
NAorICBmaQorICAkYXNfZWNobyAiJGFzX21lOiBlcnJvcjogJDIiID4mMgorICBhc19mbl9leGl0
ICRhc19zdGF0dXMKK30gIyBhc19mbl9lcnJvcgorCitpZiBleHByIGEgOiAnXChhXCknID4vZGV2
L251bGwgMj4mMSAmJgorICAgdGVzdCAiWGBleHByIDAwMDAxIDogJy4qXCguLi5cKSdgIiA9IFgw
MDE7IHRoZW4KKyAgYXNfZXhwcj1leHByCitlbHNlCisgIGFzX2V4cHI9ZmFsc2UKK2ZpCisKK2lm
IChiYXNlbmFtZSAtLSAvKSA+L2Rldi9udWxsIDI+JjEgJiYgdGVzdCAiWGBiYXNlbmFtZSAtLSAv
IDI+JjFgIiA9ICJYLyI7IHRoZW4KKyAgYXNfYmFzZW5hbWU9YmFzZW5hbWUKK2Vsc2UKKyAgYXNf
YmFzZW5hbWU9ZmFsc2UKK2ZpCisKK2lmIChhc19kaXI9YGRpcm5hbWUgLS0gL2AgJiYgdGVzdCAi
WCRhc19kaXIiID0gWC8pID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBhc19kaXJuYW1lPWRpcm5h
bWUKK2Vsc2UKKyAgYXNfZGlybmFtZT1mYWxzZQorZmkKKworYXNfbWU9YCRhc19iYXNlbmFtZSAt
LSAiJDAiIHx8CiskYXNfZXhwciBYLyIkMCIgOiAnLiovXChbXi9dW14vXSpcKS8qJCcgXHwgXAor
CSBYIiQwIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiQwIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2
L251bGwgfHwKKyRhc19lY2hvIFgvIiQwIiB8CisgICAgc2VkICcvXi4qXC9cKFteL11bXi9dKlwp
XC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cL1wpJC97CisJ
ICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cKS4qL3sKKwkgICAgcy8vXDEv
CisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorCisjIEF2b2lkIGRlcGVuZGluZyB1cG9u
IENoYXJhY3RlciBSYW5nZXMuCithc19jcl9sZXR0ZXJzPSdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2
d3h5eicKK2FzX2NyX0xFVFRFUlM9J0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJworYXNfY3Jf
TGV0dGVycz0kYXNfY3JfbGV0dGVycyRhc19jcl9MRVRURVJTCithc19jcl9kaWdpdHM9JzAxMjM0
NTY3ODknCithc19jcl9hbG51bT0kYXNfY3JfTGV0dGVycyRhc19jcl9kaWdpdHMKKworCisgIGFz
X2xpbmVub18xPSRMSU5FTk8gYXNfbGluZW5vXzFhPSRMSU5FTk8KKyAgYXNfbGluZW5vXzI9JExJ
TkVOTyBhc19saW5lbm9fMmE9JExJTkVOTworICBldmFsICd0ZXN0ICJ4JGFzX2xpbmVub18xJyRh
c19ydW4nIiAhPSAieCRhc19saW5lbm9fMickYXNfcnVuJyIgJiYKKyAgdGVzdCAieGBleHByICRh
c19saW5lbm9fMSckYXNfcnVuJyArIDFgIiA9ICJ4JGFzX2xpbmVub18yJyRhc19ydW4nIicgfHwg
eworICAjIEJsYW1lIExlZSBFLiBNY01haG9uICgxOTMxLTE5ODkpIGZvciBzZWQncyBzeW50YXgu
ICA6LSkKKyAgc2VkIC1uICcKKyAgICBwCisgICAgL1skXUxJTkVOTy89CisgICcgPCRhc19teXNl
bGYgfAorICAgIHNlZCAnCisgICAgICBzL1skXUxJTkVOTy4qLyYtLworICAgICAgdCBsaW5lbm8K
KyAgICAgIGIKKyAgICAgIDpsaW5lbm8KKyAgICAgIE4KKyAgICAgIDpsb29wCisgICAgICBzL1sk
XUxJTkVOT1woW14nJGFzX2NyX2FsbnVtJ19dLipcblwpXCguKlwpL1wyXDFcMi8KKyAgICAgIHQg
bG9vcAorICAgICAgcy8tXG4uKi8vCisgICAgJyA+JGFzX21lLmxpbmVubyAmJgorICBjaG1vZCAr
eCAiJGFzX21lLmxpbmVubyIgfHwKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjYW5u
b3QgY3JlYXRlICRhc19tZS5saW5lbm87IHJlcnVuIHdpdGggYSBQT1NJWCBzaGVsbCIgPiYyOyBh
c19mbl9leGl0IDE7IH0KKworICAjIERvbid0IHRyeSB0byBleGVjIGFzIGl0IGNoYW5nZXMgJFsw
XSwgY2F1c2luZyBhbGwgc29ydCBvZiBwcm9ibGVtcworICAjICh0aGUgZGlybmFtZSBvZiAkWzBd
IGlzIG5vdCB0aGUgcGxhY2Ugd2hlcmUgd2UgbWlnaHQgZmluZCB0aGUKKyAgIyBvcmlnaW5hbCBh
bmQgc28gb24uICBBdXRvY29uZiBpcyBlc3BlY2lhbGx5IHNlbnNpdGl2ZSB0byB0aGlzKS4KKyAg
LiAiLi8kYXNfbWUubGluZW5vIgorICAjIEV4aXQgc3RhdHVzIGlzIHRoYXQgb2YgdGhlIGxhc3Qg
Y29tbWFuZC4KKyAgZXhpdAorfQorCitFQ0hPX0M9IEVDSE9fTj0gRUNIT19UPQorY2FzZSBgZWNo
byAtbiB4YCBpbiAjKCgoKCgKKy1uKikKKyAgY2FzZSBgZWNobyAneHlcYydgIGluCisgICpjKikg
RUNIT19UPScJJzs7CSMgRUNIT19UIGlzIHNpbmdsZSB0YWIgY2hhcmFjdGVyLgorICB4eSkgIEVD
SE9fQz0nXGMnOzsKKyAgKikgICBlY2hvIGBlY2hvIGtzaDg4IGJ1ZyBvbiBBSVggNi4xYCA+IC9k
ZXYvbnVsbAorICAgICAgIEVDSE9fVD0nCSc7OworICBlc2FjOzsKKyopCisgIEVDSE9fTj0nLW4n
OzsKK2VzYWMKKworcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmZpbGUKK2lmIHRlc3Qg
LWQgY29uZiQkLmRpcjsgdGhlbgorICBybSAtZiBjb25mJCQuZGlyL2NvbmYkJC5maWxlCitlbHNl
CisgIHJtIC1mIGNvbmYkJC5kaXIKKyAgbWtkaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAorZmkK
K2lmIChlY2hvID5jb25mJCQuZmlsZSkgMj4vZGV2L251bGw7IHRoZW4KKyAgaWYgbG4gLXMgY29u
ZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz0nbG4gLXMnCisg
ICAgIyAuLi4gYnV0IHRoZXJlIGFyZSB0d28gZ290Y2hhczoKKyAgICAjIDEpIE9uIE1TWVMsIGJv
dGggYGxuIC1zIGZpbGUgZGlyJyBhbmQgYGxuIGZpbGUgZGlyJyBmYWlsLgorICAgICMgMikgREpH
UFAgPCAyLjA0IGhhcyBubyBzeW1saW5rczsgYGxuIC1zJyBjcmVhdGVzIGEgd3JhcHBlciBleGVj
dXRhYmxlLgorICAgICMgSW4gYm90aCBjYXNlcywgd2UgaGF2ZSB0byBkZWZhdWx0IHRvIGBjcCAt
cCcuCisgICAgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQkLmRpciAyPi9kZXYvbnVsbCAmJiB0ZXN0
ICEgLWYgY29uZiQkLmV4ZSB8fAorICAgICAgYXNfbG5fcz0nY3AgLXAnCisgIGVsaWYgbG4gY29u
ZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz1sbgorICBlbHNl
CisgICAgYXNfbG5fcz0nY3AgLXAnCisgIGZpCitlbHNlCisgIGFzX2xuX3M9J2NwIC1wJworZmkK
K3JtIC1mIGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5kaXIvY29uZiQkLmZpbGUgY29uZiQkLmZp
bGUKK3JtZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwKKworaWYgbWtkaXIgLXAgLiAyPi9kZXYv
bnVsbDsgdGhlbgorICBhc19ta2Rpcl9wPSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRl
c3QgLWQgLi8tcCAmJiBybWRpciAuLy1wCisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRl
c3QgLXggLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxz
ZQorICBpZiBscyAtZEwgLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlv
bj1MCisgIGVsc2UKKyAgICBhc19sc19MX29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAg
ICBldmFsIHNoIC1jICdcJycKKyAgICAgIGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQg
IiQxLy4iOworICAgICAgZWxzZQorCWNhc2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwll
c2FjOworCWNhc2UgYGxzIC1sZCckYXNfbHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGlu
ICMoKAorCT8/P1tzeF0qKTo7OyopZmFsc2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2Zp
Cithc19leGVjdXRhYmxlX3A9JGFzX3Rlc3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBh
IHN0cmluZyBvbnRvIGEgdmFsaWQgQ1BQIG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSok
YXNfY3JfbGV0dGVycyVQJGFzX2NyX0xFVFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgor
CisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUg
bmFtZS4KK2FzX3RyX3NoPSJldmFsIHNlZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8l
ZyciCisKKwordGVzdCAtbiAiJERKRElSIiB8fCBleGVjIDc8JjAgPC9kZXYvbnVsbAorZXhlYyA2
PiYxCisKKyMgTmFtZSBvZiB0aGUgaG9zdC4KKyMgaG9zdG5hbWUgb24gc29tZSBzeXN0ZW1zIChT
VlIzLjIsIG9sZCBHTlUvTGludXgpIHJldHVybnMgYSBib2d1cyBleGl0IHN0YXR1cywKKyMgc28g
dW5hbWUgZ2V0cyBydW4gdG9vLgorYWNfaG9zdG5hbWU9YChob3N0bmFtZSB8fCB1bmFtZSAtbikg
Mj4vZGV2L251bGwgfCBzZWQgMXFgCisKKyMKKyMgSW5pdGlhbGl6YXRpb25zLgorIworYWNfZGVm
YXVsdF9wcmVmaXg9L3Vzci9sb2NhbAorYWNfY2xlYW5fZmlsZXM9CithY19jb25maWdfbGlib2Jq
X2Rpcj0uCitMSUJPQkpTPQorY3Jvc3NfY29tcGlsaW5nPW5vCitzdWJkaXJzPQorTUZMQUdTPQor
TUFLRUZMQUdTPQorCisjIElkZW50aXR5IG9mIHRoaXMgcGFja2FnZS4KK1BBQ0tBR0VfTkFNRT0n
WGVuIEh5cGVydmlzb3InCitQQUNLQUdFX1RBUk5BTUU9J3hlbi1oeXBlcnZpc29yJworUEFDS0FH
RV9WRVJTSU9OPSc0LjInCitQQUNLQUdFX1NUUklORz0nWGVuIEh5cGVydmlzb3IgNC4yJworUEFD
S0FHRV9CVUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tJworUEFDS0FHRV9V
Ukw9JycKKworYWNfdW5pcXVlX2ZpbGU9ImxpYnhsL2xpYnhsLmMiCithY19kZWZhdWx0X3ByZWZp
eD0vdXNyCisjIEZhY3RvcmluZyBkZWZhdWx0IGhlYWRlcnMgZm9yIG1vc3QgdGVzdHMuCithY19p
bmNsdWRlc19kZWZhdWx0PSJcCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpZmRlZiBIQVZFX1NZU19U
WVBFU19ICisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TWVNf
U1RBVF9ICisjIGluY2x1ZGUgPHN5cy9zdGF0Lmg+CisjZW5kaWYKKyNpZmRlZiBTVERDX0hFQURF
UlMKKyMgaW5jbHVkZSA8c3RkbGliLmg+CisjIGluY2x1ZGUgPHN0ZGRlZi5oPgorI2Vsc2UKKyMg
aWZkZWYgSEFWRV9TVERMSUJfSAorIyAgaW5jbHVkZSA8c3RkbGliLmg+CisjIGVuZGlmCisjZW5k
aWYKKyNpZmRlZiBIQVZFX1NUUklOR19ICisjIGlmICFkZWZpbmVkIFNURENfSEVBREVSUyAmJiBk
ZWZpbmVkIEhBVkVfTUVNT1JZX0gKKyMgIGluY2x1ZGUgPG1lbW9yeS5oPgorIyBlbmRpZgorIyBp
bmNsdWRlIDxzdHJpbmcuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RSSU5HU19ICisjIGluY2x1
ZGUgPHN0cmluZ3MuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfSU5UVFlQRVNfSAorIyBpbmNsdWRl
IDxpbnR0eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TVERJTlRfSAorIyBpbmNsdWRlIDxz
dGRpbnQuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3Rk
Lmg+CisjZW5kaWYiCisKK2FjX2hlYWRlcl9saXN0PQorYWNfZnVuY19saXN0PQorYWNfc3Vic3Rf
dmFycz0nTFRMSUJPQkpTCitQT1dfTElCCitMSUJPQkpTCitBTExPQ0EKK2xpYmljb252CitsaWJn
Y3J5cHQKK2xpYmV4dDJmcworc3lzdGVtX2FpbworTElCX1BBVEgKK1ZOQ09ORklHCitIT1RQTFVH
CitVREVWSU5GTworVURFVkFETQorUFlUSE9OUEFUSAorT0NBTUxCVUlMRAorT0NBTUxET0MKK09D
QU1MTUtMSUIKK09DQU1MTUtUT1AKK09DQU1MREVQCitPQ0FNTAorT0NBTUxPUFRET1RPUFQKK09D
QU1MQ0RPVE9QVAorT0NBTUxCRVNUCitPQ0FNTE9QVAorT0NBTUxMSUIKK09DQU1MVkVSU0lPTgor
T0NBTUxDCitJTlNUQUxMX0RBVEEKK0lOU1RBTExfU0NSSVBUCitJTlNUQUxMX1BST0dSQU0KK1NF
VF9NQUtFCitMTl9TCitTRUQKK1hHRVRURVhUCitCQVNICitYTUwKK0NVUkwKK0ZMRVgKK0JJU09O
CitJUAorQlJDVEwKK1BFUkwKK1BZVEhPTgorQVBQRU5EX0xJQgorQVBQRU5EX0lOQ0xVREVTCitQ
UkVQRU5EX0xJQgorUFJFUEVORF9JTkNMVURFUworZGVidWcKK2xvbW91bnQKK21pbml0ZXJtCitv
Y2FtbHRvb2xzCitweXRob250b29scworeGFwaQordnRwbQorbW9uaXRvcnMKK2dpdGh0dHAKK3hz
bQoraG9zdF9vcworaG9zdF92ZW5kb3IKK2hvc3RfY3B1Citob3N0CitidWlsZF9vcworYnVpbGRf
dmVuZG9yCitidWlsZF9jcHUKK2J1aWxkCitFR1JFUAorR1JFUAorQ1BQCitPQkpFWFQKK0VYRUVY
VAorYWNfY3RfQ0MKK0NQUEZMQUdTCitMREZMQUdTCitDRkxBR1MKK0NDCit0YXJnZXRfYWxpYXMK
K2hvc3RfYWxpYXMKK2J1aWxkX2FsaWFzCitMSUJTCitFQ0hPX1QKK0VDSE9fTgorRUNIT19DCitE
RUZTCittYW5kaXIKK2xvY2FsZWRpcgorbGliZGlyCitwc2RpcgorcGRmZGlyCitkdmlkaXIKK2h0
bWxkaXIKK2luZm9kaXIKK2RvY2Rpcgorb2xkaW5jbHVkZWRpcgoraW5jbHVkZWRpcgorbG9jYWxz
dGF0ZWRpcgorc2hhcmVkc3RhdGVkaXIKK3N5c2NvbmZkaXIKK2RhdGFkaXIKK2RhdGFyb290ZGly
CitsaWJleGVjZGlyCitzYmluZGlyCitiaW5kaXIKK3Byb2dyYW1fdHJhbnNmb3JtX25hbWUKK3By
ZWZpeAorZXhlY19wcmVmaXgKK1BBQ0tBR0VfVVJMCitQQUNLQUdFX0JVR1JFUE9SVAorUEFDS0FH
RV9TVFJJTkcKK1BBQ0tBR0VfVkVSU0lPTgorUEFDS0FHRV9UQVJOQU1FCitQQUNLQUdFX05BTUUK
K1BBVEhfU0VQQVJBVE9SCitTSEVMTCcKK2FjX3N1YnN0X2ZpbGVzPScnCithY191c2VyX29wdHM9
JworZW5hYmxlX29wdGlvbl9jaGVja2luZworZW5hYmxlX3hzbQorZW5hYmxlX2dpdGh0dHAKK2Vu
YWJsZV9tb25pdG9ycworZW5hYmxlX3Z0cG0KK2VuYWJsZV94YXBpCitlbmFibGVfcHl0aG9udG9v
bHMKK2VuYWJsZV9vY2FtbHRvb2xzCitlbmFibGVfbWluaXRlcm0KK2VuYWJsZV9sb21vdW50Citl
bmFibGVfZGVidWcKKycKKyAgICAgIGFjX3ByZWNpb3VzX3ZhcnM9J2J1aWxkX2FsaWFzCitob3N0
X2FsaWFzCit0YXJnZXRfYWxpYXMKK0NDCitDRkxBR1MKK0xERkxBR1MKK0xJQlMKK0NQUEZMQUdT
CitDUFAKK1BSRVBFTkRfSU5DTFVERVMKK1BSRVBFTkRfTElCCitBUFBFTkRfSU5DTFVERVMKK0FQ
UEVORF9MSUIKK1BZVEhPTgorUEVSTAorQlJDVEwKK0lQCitCSVNPTgorRkxFWAorQ1VSTAorWE1M
CitCQVNICitYR0VUVEVYVCcKKworCisjIEluaXRpYWxpemUgc29tZSB2YXJpYWJsZXMgc2V0IGJ5
IG9wdGlvbnMuCithY19pbml0X2hlbHA9CithY19pbml0X3ZlcnNpb249ZmFsc2UKK2FjX3VucmVj
b2duaXplZF9vcHRzPQorYWNfdW5yZWNvZ25pemVkX3NlcD0KKyMgVGhlIHZhcmlhYmxlcyBoYXZl
IHRoZSBzYW1lIG5hbWVzIGFzIHRoZSBvcHRpb25zLCB3aXRoCisjIGRhc2hlcyBjaGFuZ2VkIHRv
IHVuZGVybGluZXMuCitjYWNoZV9maWxlPS9kZXYvbnVsbAorZXhlY19wcmVmaXg9Tk9ORQorbm9f
Y3JlYXRlPQorbm9fcmVjdXJzaW9uPQorcHJlZml4PU5PTkUKK3Byb2dyYW1fcHJlZml4PU5PTkUK
K3Byb2dyYW1fc3VmZml4PU5PTkUKK3Byb2dyYW1fdHJhbnNmb3JtX25hbWU9cyx4LHgsCitzaWxl
bnQ9CitzaXRlPQorc3JjZGlyPQordmVyYm9zZT0KK3hfaW5jbHVkZXM9Tk9ORQoreF9saWJyYXJp
ZXM9Tk9ORQorCisjIEluc3RhbGxhdGlvbiBkaXJlY3Rvcnkgb3B0aW9ucy4KKyMgVGhlc2UgYXJl
IGxlZnQgdW5leHBhbmRlZCBzbyB1c2VycyBjYW4gIm1ha2UgaW5zdGFsbCBleGVjX3ByZWZpeD0v
Zm9vIgorIyBhbmQgYWxsIHRoZSB2YXJpYWJsZXMgdGhhdCBhcmUgc3VwcG9zZWQgdG8gYmUgYmFz
ZWQgb24gZXhlY19wcmVmaXgKKyMgYnkgZGVmYXVsdCB3aWxsIGFjdHVhbGx5IGNoYW5nZS4KKyMg
VXNlIGJyYWNlcyBpbnN0ZWFkIG9mIHBhcmVucyBiZWNhdXNlIHNoLCBwZXJsLCBldGMuIGFsc28g
YWNjZXB0IHRoZW0uCisjIChUaGUgbGlzdCBmb2xsb3dzIHRoZSBzYW1lIG9yZGVyIGFzIHRoZSBH
TlUgQ29kaW5nIFN0YW5kYXJkcy4pCitiaW5kaXI9JyR7ZXhlY19wcmVmaXh9L2JpbicKK3NiaW5k
aXI9JyR7ZXhlY19wcmVmaXh9L3NiaW4nCitsaWJleGVjZGlyPScke2V4ZWNfcHJlZml4fS9saWJl
eGVjJworZGF0YXJvb3RkaXI9JyR7cHJlZml4fS9zaGFyZScKK2RhdGFkaXI9JyR7ZGF0YXJvb3Rk
aXJ9Jworc3lzY29uZmRpcj0nJHtwcmVmaXh9L2V0YycKK3NoYXJlZHN0YXRlZGlyPScke3ByZWZp
eH0vY29tJworbG9jYWxzdGF0ZWRpcj0nJHtwcmVmaXh9L3ZhcicKK2luY2x1ZGVkaXI9JyR7cHJl
Zml4fS9pbmNsdWRlJworb2xkaW5jbHVkZWRpcj0nL3Vzci9pbmNsdWRlJworZG9jZGlyPScke2Rh
dGFyb290ZGlyfS9kb2MvJHtQQUNLQUdFX1RBUk5BTUV9JworaW5mb2Rpcj0nJHtkYXRhcm9vdGRp
cn0vaW5mbycKK2h0bWxkaXI9JyR7ZG9jZGlyfScKK2R2aWRpcj0nJHtkb2NkaXJ9JworcGRmZGly
PScke2RvY2Rpcn0nCitwc2Rpcj0nJHtkb2NkaXJ9JworbGliZGlyPScke2V4ZWNfcHJlZml4fS9s
aWInCitsb2NhbGVkaXI9JyR7ZGF0YXJvb3RkaXJ9L2xvY2FsZScKK21hbmRpcj0nJHtkYXRhcm9v
dGRpcn0vbWFuJworCithY19wcmV2PQorYWNfZGFzaGRhc2g9Citmb3IgYWNfb3B0aW9uCitkbwor
ICAjIElmIHRoZSBwcmV2aW91cyBvcHRpb24gbmVlZHMgYW4gYXJndW1lbnQsIGFzc2lnbiBpdC4K
KyAgaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgICAgZXZhbCAkYWNfcHJldj1cJGFjX29w
dGlvbgorICAgIGFjX3ByZXY9CisgICAgY29udGludWUKKyAgZmkKKworICBjYXNlICRhY19vcHRp
b24gaW4KKyAgKj0/KikgYWNfb3B0YXJnPWBleHByICJYJGFjX29wdGlvbiIgOiAnW149XSo9XCgu
KlwpJ2AgOzsKKyAgKj0pICAgYWNfb3B0YXJnPSA7OworICAqKSAgICBhY19vcHRhcmc9eWVzIDs7
CisgIGVzYWMKKworICAjIEFjY2VwdCB0aGUgaW1wb3J0YW50IEN5Z251cyBjb25maWd1cmUgb3B0
aW9ucywgc28gd2UgY2FuIGRpYWdub3NlIHR5cG9zLgorCisgIGNhc2UgJGFjX2Rhc2hkYXNoJGFj
X29wdGlvbiBpbgorICAtLSkKKyAgICBhY19kYXNoZGFzaD15ZXMgOzsKKworICAtYmluZGlyIHwg
LS1iaW5kaXIgfCAtLWJpbmRpIHwgLS1iaW5kIHwgLS1iaW4gfCAtLWJpKQorICAgIGFjX3ByZXY9
YmluZGlyIDs7CisgIC1iaW5kaXI9KiB8IC0tYmluZGlyPSogfCAtLWJpbmRpPSogfCAtLWJpbmQ9
KiB8IC0tYmluPSogfCAtLWJpPSopCisgICAgYmluZGlyPSRhY19vcHRhcmcgOzsKKworICAtYnVp
bGQgfCAtLWJ1aWxkIHwgLS1idWlsIHwgLS1idWkgfCAtLWJ1KQorICAgIGFjX3ByZXY9YnVpbGRf
YWxpYXMgOzsKKyAgLWJ1aWxkPSogfCAtLWJ1aWxkPSogfCAtLWJ1aWw9KiB8IC0tYnVpPSogfCAt
LWJ1PSopCisgICAgYnVpbGRfYWxpYXM9JGFjX29wdGFyZyA7OworCisgIC1jYWNoZS1maWxlIHwg
LS1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWwgfCAtLWNhY2hlLWZpIFwKKyAgfCAtLWNhY2hlLWYg
fCAtLWNhY2hlLSB8IC0tY2FjaGUgfCAtLWNhY2ggfCAtLWNhYyB8IC0tY2EgfCAtLWMpCisgICAg
YWNfcHJldj1jYWNoZV9maWxlIDs7CisgIC1jYWNoZS1maWxlPSogfCAtLWNhY2hlLWZpbGU9KiB8
IC0tY2FjaGUtZmlsPSogfCAtLWNhY2hlLWZpPSogXAorICB8IC0tY2FjaGUtZj0qIHwgLS1jYWNo
ZS09KiB8IC0tY2FjaGU9KiB8IC0tY2FjaD0qIHwgLS1jYWM9KiB8IC0tY2E9KiB8IC0tYz0qKQor
ICAgIGNhY2hlX2ZpbGU9JGFjX29wdGFyZyA7OworCisgIC0tY29uZmlnLWNhY2hlIHwgLUMpCisg
ICAgY2FjaGVfZmlsZT1jb25maWcuY2FjaGUgOzsKKworICAtZGF0YWRpciB8IC0tZGF0YWRpciB8
IC0tZGF0YWRpIHwgLS1kYXRhZCkKKyAgICBhY19wcmV2PWRhdGFkaXIgOzsKKyAgLWRhdGFkaXI9
KiB8IC0tZGF0YWRpcj0qIHwgLS1kYXRhZGk9KiB8IC0tZGF0YWQ9KikKKyAgICBkYXRhZGlyPSRh
Y19vcHRhcmcgOzsKKworICAtZGF0YXJvb3RkaXIgfCAtLWRhdGFyb290ZGlyIHwgLS1kYXRhcm9v
dGRpIHwgLS1kYXRhcm9vdGQgfCAtLWRhdGFyb290IFwKKyAgfCAtLWRhdGFyb28gfCAtLWRhdGFy
byB8IC0tZGF0YXIpCisgICAgYWNfcHJldj1kYXRhcm9vdGRpciA7OworICAtZGF0YXJvb3RkaXI9
KiB8IC0tZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaT0qIHwgLS1kYXRhcm9vdGQ9KiBcCisg
IHwgLS1kYXRhcm9vdD0qIHwgLS1kYXRhcm9vPSogfCAtLWRhdGFybz0qIHwgLS1kYXRhcj0qKQor
ICAgIGRhdGFyb290ZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGlzYWJsZS0qIHwgLS1kaXNhYmxl
LSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19vcHRpb24iIDogJ3gtKmRpc2FibGUtXCgu
KlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFi
bGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51
bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUg
bmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAg
YWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAor
ICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQi
CisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVk
X29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZGlzYWJsZS0kYWNfdXNlcm9wdF9vcmlnIgorCSBh
Y191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVzYWMKKyAgICBldmFsIGVuYWJsZV8kYWNf
dXNlcm9wdD1ubyA7OworCisgIC1kb2NkaXIgfCAtLWRvY2RpciB8IC0tZG9jZGkgfCAtLWRvYyB8
IC0tZG8pCisgICAgYWNfcHJldj1kb2NkaXIgOzsKKyAgLWRvY2Rpcj0qIHwgLS1kb2NkaXI9KiB8
IC0tZG9jZGk9KiB8IC0tZG9jPSogfCAtLWRvPSopCisgICAgZG9jZGlyPSRhY19vcHRhcmcgOzsK
KworICAtZHZpZGlyIHwgLS1kdmlkaXIgfCAtLWR2aWRpIHwgLS1kdmlkIHwgLS1kdmkgfCAtLWR2
KQorICAgIGFjX3ByZXY9ZHZpZGlyIDs7CisgIC1kdmlkaXI9KiB8IC0tZHZpZGlyPSogfCAtLWR2
aWRpPSogfCAtLWR2aWQ9KiB8IC0tZHZpPSogfCAtLWR2PSopCisgICAgZHZpZGlyPSRhY19vcHRh
cmcgOzsKKworICAtZW5hYmxlLSogfCAtLWVuYWJsZS0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIg
IngkYWNfb3B0aW9uIiA6ICd4LSplbmFibGUtXChbXj1dKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1l
cyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRh
Y191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAg
IGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUgbmFtZTogJGFjX3VzZXJvcHQiCisgICAg
YWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRh
Y191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBp
bgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3Vu
cmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3Nl
cC0tZW5hYmxlLSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7
CisgICAgZXNhYworICAgIGV2YWwgZW5hYmxlXyRhY191c2Vyb3B0PVwkYWNfb3B0YXJnIDs7CisK
KyAgLWV4ZWMtcHJlZml4IHwgLS1leGVjX3ByZWZpeCB8IC0tZXhlYy1wcmVmaXggfCAtLWV4ZWMt
cHJlZmkgXAorICB8IC0tZXhlYy1wcmVmIHwgLS1leGVjLXByZSB8IC0tZXhlYy1wciB8IC0tZXhl
Yy1wIHwgLS1leGVjLSBcCisgIHwgLS1leGVjIHwgLS1leGUgfCAtLWV4KQorICAgIGFjX3ByZXY9
ZXhlY19wcmVmaXggOzsKKyAgLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWNfcHJlZml4PSogfCAtLWV4
ZWMtcHJlZml4PSogfCAtLWV4ZWMtcHJlZmk9KiBcCisgIHwgLS1leGVjLXByZWY9KiB8IC0tZXhl
Yy1wcmU9KiB8IC0tZXhlYy1wcj0qIHwgLS1leGVjLXA9KiB8IC0tZXhlYy09KiBcCisgIHwgLS1l
eGVjPSogfCAtLWV4ZT0qIHwgLS1leD0qKQorICAgIGV4ZWNfcHJlZml4PSRhY19vcHRhcmcgOzsK
KworICAtZ2FzIHwgLS1nYXMgfCAtLWdhIHwgLS1nKQorICAgICMgT2Jzb2xldGU7IHVzZSAtLXdp
dGgtZ2FzLgorICAgIHdpdGhfZ2FzPXllcyA7OworCisgIC1oZWxwIHwgLS1oZWxwIHwgLS1oZWwg
fCAtLWhlIHwgLWgpCisgICAgYWNfaW5pdF9oZWxwPWxvbmcgOzsKKyAgLWhlbHA9ciogfCAtLWhl
bHA9ciogfCAtLWhlbD1yKiB8IC0taGU9ciogfCAtaHIqKQorICAgIGFjX2luaXRfaGVscD1yZWN1
cnNpdmUgOzsKKyAgLWhlbHA9cyogfCAtLWhlbHA9cyogfCAtLWhlbD1zKiB8IC0taGU9cyogfCAt
aHMqKQorICAgIGFjX2luaXRfaGVscD1zaG9ydCA7OworCisgIC1ob3N0IHwgLS1ob3N0IHwgLS1o
b3MgfCAtLWhvKQorICAgIGFjX3ByZXY9aG9zdF9hbGlhcyA7OworICAtaG9zdD0qIHwgLS1ob3N0
PSogfCAtLWhvcz0qIHwgLS1obz0qKQorICAgIGhvc3RfYWxpYXM9JGFjX29wdGFyZyA7OworCisg
IC1odG1sZGlyIHwgLS1odG1sZGlyIHwgLS1odG1sZGkgfCAtLWh0bWxkIHwgLS1odG1sIHwgLS1o
dG0gfCAtLWh0KQorICAgIGFjX3ByZXY9aHRtbGRpciA7OworICAtaHRtbGRpcj0qIHwgLS1odG1s
ZGlyPSogfCAtLWh0bWxkaT0qIHwgLS1odG1sZD0qIHwgLS1odG1sPSogfCAtLWh0bT0qIFwKKyAg
fCAtLWh0PSopCisgICAgaHRtbGRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWluY2x1ZGVkaXIgfCAt
LWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaSB8IC0taW5jbHVkZWQgfCAtLWluY2x1ZGUgXAorICB8
IC0taW5jbHVkIHwgLS1pbmNsdSB8IC0taW5jbCB8IC0taW5jKQorICAgIGFjX3ByZXY9aW5jbHVk
ZWRpciA7OworICAtaW5jbHVkZWRpcj0qIHwgLS1pbmNsdWRlZGlyPSogfCAtLWluY2x1ZGVkaT0q
IHwgLS1pbmNsdWRlZD0qIHwgLS1pbmNsdWRlPSogXAorICB8IC0taW5jbHVkPSogfCAtLWluY2x1
PSogfCAtLWluY2w9KiB8IC0taW5jPSopCisgICAgaW5jbHVkZWRpcj0kYWNfb3B0YXJnIDs7CisK
KyAgLWluZm9kaXIgfCAtLWluZm9kaXIgfCAtLWluZm9kaSB8IC0taW5mb2QgfCAtLWluZm8gfCAt
LWluZikKKyAgICBhY19wcmV2PWluZm9kaXIgOzsKKyAgLWluZm9kaXI9KiB8IC0taW5mb2Rpcj0q
IHwgLS1pbmZvZGk9KiB8IC0taW5mb2Q9KiB8IC0taW5mbz0qIHwgLS1pbmY9KikKKyAgICBpbmZv
ZGlyPSRhY19vcHRhcmcgOzsKKworICAtbGliZGlyIHwgLS1saWJkaXIgfCAtLWxpYmRpIHwgLS1s
aWJkKQorICAgIGFjX3ByZXY9bGliZGlyIDs7CisgIC1saWJkaXI9KiB8IC0tbGliZGlyPSogfCAt
LWxpYmRpPSogfCAtLWxpYmQ9KikKKyAgICBsaWJkaXI9JGFjX29wdGFyZyA7OworCisgIC1saWJl
eGVjZGlyIHwgLS1saWJleGVjZGlyIHwgLS1saWJleGVjZGkgfCAtLWxpYmV4ZWNkIHwgLS1saWJl
eGVjIFwKKyAgfCAtLWxpYmV4ZSB8IC0tbGliZXggfCAtLWxpYmUpCisgICAgYWNfcHJldj1saWJl
eGVjZGlyIDs7CisgIC1saWJleGVjZGlyPSogfCAtLWxpYmV4ZWNkaXI9KiB8IC0tbGliZXhlY2Rp
PSogfCAtLWxpYmV4ZWNkPSogfCAtLWxpYmV4ZWM9KiBcCisgIHwgLS1saWJleGU9KiB8IC0tbGli
ZXg9KiB8IC0tbGliZT0qKQorICAgIGxpYmV4ZWNkaXI9JGFjX29wdGFyZyA7OworCisgIC1sb2Nh
bGVkaXIgfCAtLWxvY2FsZWRpciB8IC0tbG9jYWxlZGkgfCAtLWxvY2FsZWQgfCAtLWxvY2FsZSkK
KyAgICBhY19wcmV2PWxvY2FsZWRpciA7OworICAtbG9jYWxlZGlyPSogfCAtLWxvY2FsZWRpcj0q
IHwgLS1sb2NhbGVkaT0qIHwgLS1sb2NhbGVkPSogfCAtLWxvY2FsZT0qKQorICAgIGxvY2FsZWRp
cj0kYWNfb3B0YXJnIDs7CisKKyAgLWxvY2Fsc3RhdGVkaXIgfCAtLWxvY2Fsc3RhdGVkaXIgfCAt
LWxvY2Fsc3RhdGVkaSB8IC0tbG9jYWxzdGF0ZWQgXAorICB8IC0tbG9jYWxzdGF0ZSB8IC0tbG9j
YWxzdGF0IHwgLS1sb2NhbHN0YSB8IC0tbG9jYWxzdCB8IC0tbG9jYWxzKQorICAgIGFjX3ByZXY9
bG9jYWxzdGF0ZWRpciA7OworICAtbG9jYWxzdGF0ZWRpcj0qIHwgLS1sb2NhbHN0YXRlZGlyPSog
fCAtLWxvY2Fsc3RhdGVkaT0qIHwgLS1sb2NhbHN0YXRlZD0qIFwKKyAgfCAtLWxvY2Fsc3RhdGU9
KiB8IC0tbG9jYWxzdGF0PSogfCAtLWxvY2Fsc3RhPSogfCAtLWxvY2Fsc3Q9KiB8IC0tbG9jYWxz
PSopCisgICAgbG9jYWxzdGF0ZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLW1hbmRpciB8IC0tbWFu
ZGlyIHwgLS1tYW5kaSB8IC0tbWFuZCB8IC0tbWFuIHwgLS1tYSB8IC0tbSkKKyAgICBhY19wcmV2
PW1hbmRpciA7OworICAtbWFuZGlyPSogfCAtLW1hbmRpcj0qIHwgLS1tYW5kaT0qIHwgLS1tYW5k
PSogfCAtLW1hbj0qIHwgLS1tYT0qIHwgLS1tPSopCisgICAgbWFuZGlyPSRhY19vcHRhcmcgOzsK
KworICAtbmZwIHwgLS1uZnAgfCAtLW5mKQorICAgICMgT2Jzb2xldGU7IHVzZSAtLXdpdGhvdXQt
ZnAuCisgICAgd2l0aF9mcD1ubyA7OworCisgIC1uby1jcmVhdGUgfCAtLW5vLWNyZWF0ZSB8IC0t
bm8tY3JlYXQgfCAtLW5vLWNyZWEgfCAtLW5vLWNyZSBcCisgIHwgLS1uby1jciB8IC0tbm8tYyB8
IC1uKQorICAgIG5vX2NyZWF0ZT15ZXMgOzsKKworICAtbm8tcmVjdXJzaW9uIHwgLS1uby1yZWN1
cnNpb24gfCAtLW5vLXJlY3Vyc2lvIHwgLS1uby1yZWN1cnNpIFwKKyAgfCAtLW5vLXJlY3VycyB8
IC0tbm8tcmVjdXIgfCAtLW5vLXJlY3UgfCAtLW5vLXJlYyB8IC0tbm8tcmUgfCAtLW5vLXIpCisg
ICAgbm9fcmVjdXJzaW9uPXllcyA7OworCisgIC1vbGRpbmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRl
ZGlyIHwgLS1vbGRpbmNsdWRlZGkgfCAtLW9sZGluY2x1ZGVkIFwKKyAgfCAtLW9sZGluY2x1ZGUg
fCAtLW9sZGluY2x1ZCB8IC0tb2xkaW5jbHUgfCAtLW9sZGluY2wgfCAtLW9sZGluYyBcCisgIHwg
LS1vbGRpbiB8IC0tb2xkaSB8IC0tb2xkIHwgLS1vbCB8IC0tbykKKyAgICBhY19wcmV2PW9sZGlu
Y2x1ZGVkaXIgOzsKKyAgLW9sZGluY2x1ZGVkaXI9KiB8IC0tb2xkaW5jbHVkZWRpcj0qIHwgLS1v
bGRpbmNsdWRlZGk9KiB8IC0tb2xkaW5jbHVkZWQ9KiBcCisgIHwgLS1vbGRpbmNsdWRlPSogfCAt
LW9sZGluY2x1ZD0qIHwgLS1vbGRpbmNsdT0qIHwgLS1vbGRpbmNsPSogfCAtLW9sZGluYz0qIFwK
KyAgfCAtLW9sZGluPSogfCAtLW9sZGk9KiB8IC0tb2xkPSogfCAtLW9sPSogfCAtLW89KikKKyAg
ICBvbGRpbmNsdWRlZGlyPSRhY19vcHRhcmcgOzsKKworICAtcHJlZml4IHwgLS1wcmVmaXggfCAt
LXByZWZpIHwgLS1wcmVmIHwgLS1wcmUgfCAtLXByIHwgLS1wKQorICAgIGFjX3ByZXY9cHJlZml4
IDs7CisgIC1wcmVmaXg9KiB8IC0tcHJlZml4PSogfCAtLXByZWZpPSogfCAtLXByZWY9KiB8IC0t
cHJlPSogfCAtLXByPSogfCAtLXA9KikKKyAgICBwcmVmaXg9JGFjX29wdGFyZyA7OworCisgIC1w
cm9ncmFtLXByZWZpeCB8IC0tcHJvZ3JhbS1wcmVmaXggfCAtLXByb2dyYW0tcHJlZmkgfCAtLXBy
b2dyYW0tcHJlZiBcCisgIHwgLS1wcm9ncmFtLXByZSB8IC0tcHJvZ3JhbS1wciB8IC0tcHJvZ3Jh
bS1wKQorICAgIGFjX3ByZXY9cHJvZ3JhbV9wcmVmaXggOzsKKyAgLXByb2dyYW0tcHJlZml4PSog
fCAtLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZmk9KiBcCisgIHwgLS1wcm9ncmFt
LXByZWY9KiB8IC0tcHJvZ3JhbS1wcmU9KiB8IC0tcHJvZ3JhbS1wcj0qIHwgLS1wcm9ncmFtLXA9
KikKKyAgICBwcm9ncmFtX3ByZWZpeD0kYWNfb3B0YXJnIDs7CisKKyAgLXByb2dyYW0tc3VmZml4
IHwgLS1wcm9ncmFtLXN1ZmZpeCB8IC0tcHJvZ3JhbS1zdWZmaSB8IC0tcHJvZ3JhbS1zdWZmIFwK
KyAgfCAtLXByb2dyYW0tc3VmIHwgLS1wcm9ncmFtLXN1IHwgLS1wcm9ncmFtLXMpCisgICAgYWNf
cHJldj1wcm9ncmFtX3N1ZmZpeCA7OworICAtcHJvZ3JhbS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1z
dWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaT0qIFwKKyAgfCAtLXByb2dyYW0tc3VmZj0qIHwgLS1w
cm9ncmFtLXN1Zj0qIHwgLS1wcm9ncmFtLXN1PSogfCAtLXByb2dyYW0tcz0qKQorICAgIHByb2dy
YW1fc3VmZml4PSRhY19vcHRhcmcgOzsKKworICAtcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSB8IC0t
cHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYW0gfCAt
LXByb2dyYW0tdHJhbnNmb3JtLW5hIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW4gfCAtLXBy
b2dyYW0tdHJhbnNmb3JtLSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybSB8IC0tcHJvZ3JhbS10
cmFuc2ZvciBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm8gfCAtLXByb2dyYW0tdHJhbnNmIFwKKyAg
fCAtLXByb2dyYW0tdHJhbnMgfCAtLXByb2dyYW0tdHJhbiBcCisgIHwgLS1wcm9nci10cmEgfCAt
LXByb2dyYW0tdHIgfCAtLXByb2dyYW0tdCkKKyAgICBhY19wcmV2PXByb2dyYW1fdHJhbnNmb3Jt
X25hbWUgOzsKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5hbWU9KiB8IC0tcHJvZ3JhbS10cmFuc2Zv
cm0tbmFtZT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hbT0qIHwgLS1wcm9ncmFtLXRy
YW5zZm9ybS1uYT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW49KiB8IC0tcHJvZ3JhbS10
cmFuc2Zvcm0tPSogXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm09KiB8IC0tcHJvZ3JhbS10cmFu
c2Zvcj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmbz0qIHwgLS1wcm9ncmFtLXRyYW5zZj0qIFwK
KyAgfCAtLXByb2dyYW0tdHJhbnM9KiB8IC0tcHJvZ3JhbS10cmFuPSogXAorICB8IC0tcHJvZ3It
dHJhPSogfCAtLXByb2dyYW0tdHI9KiB8IC0tcHJvZ3JhbS10PSopCisgICAgcHJvZ3JhbV90cmFu
c2Zvcm1fbmFtZT0kYWNfb3B0YXJnIDs7CisKKyAgLXBkZmRpciB8IC0tcGRmZGlyIHwgLS1wZGZk
aSB8IC0tcGRmZCB8IC0tcGRmIHwgLS1wZCkKKyAgICBhY19wcmV2PXBkZmRpciA7OworICAtcGRm
ZGlyPSogfCAtLXBkZmRpcj0qIHwgLS1wZGZkaT0qIHwgLS1wZGZkPSogfCAtLXBkZj0qIHwgLS1w
ZD0qKQorICAgIHBkZmRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXBzZGlyIHwgLS1wc2RpciB8IC0t
cHNkaSB8IC0tcHNkIHwgLS1wcykKKyAgICBhY19wcmV2PXBzZGlyIDs7CisgIC1wc2Rpcj0qIHwg
LS1wc2Rpcj0qIHwgLS1wc2RpPSogfCAtLXBzZD0qIHwgLS1wcz0qKQorICAgIHBzZGlyPSRhY19v
cHRhcmcgOzsKKworICAtcSB8IC1xdWlldCB8IC0tcXVpZXQgfCAtLXF1aWUgfCAtLXF1aSB8IC0t
cXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2lsZW4gfCAtLXNpbGUgfCAt
LXNpbCkKKyAgICBzaWxlbnQ9eWVzIDs7CisKKyAgLXNiaW5kaXIgfCAtLXNiaW5kaXIgfCAtLXNi
aW5kaSB8IC0tc2JpbmQgfCAtLXNiaW4gfCAtLXNiaSB8IC0tc2IpCisgICAgYWNfcHJldj1zYmlu
ZGlyIDs7CisgIC1zYmluZGlyPSogfCAtLXNiaW5kaXI9KiB8IC0tc2JpbmRpPSogfCAtLXNiaW5k
PSogfCAtLXNiaW49KiBcCisgIHwgLS1zYmk9KiB8IC0tc2I9KikKKyAgICBzYmluZGlyPSRhY19v
cHRhcmcgOzsKKworICAtc2hhcmVkc3RhdGVkaXIgfCAtLXNoYXJlZHN0YXRlZGlyIHwgLS1zaGFy
ZWRzdGF0ZWRpIFwKKyAgfCAtLXNoYXJlZHN0YXRlZCB8IC0tc2hhcmVkc3RhdGUgfCAtLXNoYXJl
ZHN0YXQgfCAtLXNoYXJlZHN0YSBcCisgIHwgLS1zaGFyZWRzdCB8IC0tc2hhcmVkcyB8IC0tc2hh
cmVkIHwgLS1zaGFyZSB8IC0tc2hhciBcCisgIHwgLS1zaGEgfCAtLXNoKQorICAgIGFjX3ByZXY9
c2hhcmVkc3RhdGVkaXIgOzsKKyAgLXNoYXJlZHN0YXRlZGlyPSogfCAtLXNoYXJlZHN0YXRlZGly
PSogfCAtLXNoYXJlZHN0YXRlZGk9KiBcCisgIHwgLS1zaGFyZWRzdGF0ZWQ9KiB8IC0tc2hhcmVk
c3RhdGU9KiB8IC0tc2hhcmVkc3RhdD0qIHwgLS1zaGFyZWRzdGE9KiBcCisgIHwgLS1zaGFyZWRz
dD0qIHwgLS1zaGFyZWRzPSogfCAtLXNoYXJlZD0qIHwgLS1zaGFyZT0qIHwgLS1zaGFyPSogXAor
ICB8IC0tc2hhPSogfCAtLXNoPSopCisgICAgc2hhcmVkc3RhdGVkaXI9JGFjX29wdGFyZyA7Owor
CisgIC1zaXRlIHwgLS1zaXRlIHwgLS1zaXQpCisgICAgYWNfcHJldj1zaXRlIDs7CisgIC1zaXRl
PSogfCAtLXNpdGU9KiB8IC0tc2l0PSopCisgICAgc2l0ZT0kYWNfb3B0YXJnIDs7CisKKyAgLXNy
Y2RpciB8IC0tc3JjZGlyIHwgLS1zcmNkaSB8IC0tc3JjZCB8IC0tc3JjIHwgLS1zcikKKyAgICBh
Y19wcmV2PXNyY2RpciA7OworICAtc3JjZGlyPSogfCAtLXNyY2Rpcj0qIHwgLS1zcmNkaT0qIHwg
LS1zcmNkPSogfCAtLXNyYz0qIHwgLS1zcj0qKQorICAgIHNyY2Rpcj0kYWNfb3B0YXJnIDs7CisK
KyAgLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaSB8IC0tc3lzY29uZmQg
fCAtLXN5c2NvbmYgXAorICB8IC0tc3lzY29uIHwgLS1zeXNjbyB8IC0tc3lzYyB8IC0tc3lzIHwg
LS1zeSkKKyAgICBhY19wcmV2PXN5c2NvbmZkaXIgOzsKKyAgLXN5c2NvbmZkaXI9KiB8IC0tc3lz
Y29uZmRpcj0qIHwgLS1zeXNjb25mZGk9KiB8IC0tc3lzY29uZmQ9KiB8IC0tc3lzY29uZj0qIFwK
KyAgfCAtLXN5c2Nvbj0qIHwgLS1zeXNjbz0qIHwgLS1zeXNjPSogfCAtLXN5cz0qIHwgLS1zeT0q
KQorICAgIHN5c2NvbmZkaXI9JGFjX29wdGFyZyA7OworCisgIC10YXJnZXQgfCAtLXRhcmdldCB8
IC0tdGFyZ2UgfCAtLXRhcmcgfCAtLXRhciB8IC0tdGEgfCAtLXQpCisgICAgYWNfcHJldj10YXJn
ZXRfYWxpYXMgOzsKKyAgLXRhcmdldD0qIHwgLS10YXJnZXQ9KiB8IC0tdGFyZ2U9KiB8IC0tdGFy
Zz0qIHwgLS10YXI9KiB8IC0tdGE9KiB8IC0tdD0qKQorICAgIHRhcmdldF9hbGlhcz0kYWNfb3B0
YXJnIDs7CisKKyAgLXYgfCAtdmVyYm9zZSB8IC0tdmVyYm9zZSB8IC0tdmVyYm9zIHwgLS12ZXJi
byB8IC0tdmVyYikKKyAgICB2ZXJib3NlPXllcyA7OworCisgIC12ZXJzaW9uIHwgLS12ZXJzaW9u
IHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwgLVYpCisgICAgYWNfaW5pdF92ZXJzaW9u
PTogOzsKKworICAtd2l0aC0qIHwgLS13aXRoLSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRh
Y19vcHRpb24iIDogJ3gtKndpdGgtXChbXj1dKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0
IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vy
b3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2Zu
X2Vycm9yICQ/ICJpbnZhbGlkIHBhY2thZ2UgbmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNl
cm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vy
b3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAg
ICAgKiIKKyJ3aXRoXyRhY191c2Vyb3B0IgorIiopIDs7CisgICAgICAqKSBhY191bnJlY29nbml6
ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFjX3VucmVjb2duaXplZF9zZXAtLXdpdGgt
JGFjX3VzZXJvcHRfb3JpZyIKKwkgYWNfdW5yZWNvZ25pemVkX3NlcD0nLCAnOzsKKyAgICBlc2Fj
CisgICAgZXZhbCB3aXRoXyRhY191c2Vyb3B0PVwkYWNfb3B0YXJnIDs7CisKKyAgLXdpdGhvdXQt
KiB8IC0td2l0aG91dC0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4
LSp3aXRob3V0LVwoLipcKSdgCisgICAgIyBSZWplY3QgbmFtZXMgdGhhdCBhcmUgbm90IHZhbGlk
IHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNfdXNlcm9wdCIgOiAiLipbXi0r
Ll8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52
YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNf
dXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3Mv
Wy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4KKyAgICAgICoiCisid2l0aF8k
YWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNfdW5yZWNvZ25pemVkX29wdHM9IiRhY191
bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRfc2VwLS13aXRob3V0LSRhY191c2Vyb3B0
X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAgZXNhYworICAgIGV2YWwg
d2l0aF8kYWNfdXNlcm9wdD1ubyA7OworCisgIC0teCkKKyAgICAjIE9ic29sZXRlOyB1c2UgLS13
aXRoLXguCisgICAgd2l0aF94PXllcyA7OworCisgIC14LWluY2x1ZGVzIHwgLS14LWluY2x1ZGVz
IHwgLS14LWluY2x1ZGUgfCAtLXgtaW5jbHVkIHwgLS14LWluY2x1IFwKKyAgfCAtLXgtaW5jbCB8
IC0teC1pbmMgfCAtLXgtaW4gfCAtLXgtaSkKKyAgICBhY19wcmV2PXhfaW5jbHVkZXMgOzsKKyAg
LXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlcz0qIHwgLS14LWluY2x1ZGU9KiB8IC0teC1pbmNs
dWQ9KiB8IC0teC1pbmNsdT0qIFwKKyAgfCAtLXgtaW5jbD0qIHwgLS14LWluYz0qIHwgLS14LWlu
PSogfCAtLXgtaT0qKQorICAgIHhfaW5jbHVkZXM9JGFjX29wdGFyZyA7OworCisgIC14LWxpYnJh
cmllcyB8IC0teC1saWJyYXJpZXMgfCAtLXgtbGlicmFyaWUgfCAtLXgtbGlicmFyaSBcCisgIHwg
LS14LWxpYnJhciB8IC0teC1saWJyYSB8IC0teC1saWJyIHwgLS14LWxpYiB8IC0teC1saSB8IC0t
eC1sKQorICAgIGFjX3ByZXY9eF9saWJyYXJpZXMgOzsKKyAgLXgtbGlicmFyaWVzPSogfCAtLXgt
bGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWU9KiB8IC0teC1saWJyYXJpPSogXAorICB8IC0teC1s
aWJyYXI9KiB8IC0teC1saWJyYT0qIHwgLS14LWxpYnI9KiB8IC0teC1saWI9KiB8IC0teC1saT0q
IHwgLS14LWw9KikKKyAgICB4X2xpYnJhcmllcz0kYWNfb3B0YXJnIDs7CisKKyAgLSopIGFzX2Zu
X2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uOiBcYCRhY19vcHRpb24nCitUcnkgXGAkMCAt
LWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uIgorICAgIDs7CisKKyAgKj0qKQorICAgIGFjX2Vu
dnZhcj1gZXhwciAieCRhY19vcHRpb24iIDogJ3hcKFtePV0qXCk9J2AKKyAgICAjIFJlamVjdCBu
YW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgY2FzZSAk
YWNfZW52dmFyIGluICMoCisgICAgICAnJyB8IFswLTldKiB8ICpbIV8kYXNfY3JfYWxudW1dKiAp
CisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YXJpYWJsZSBuYW1lOiBcYCRhY19lbnZ2
YXInIiA7OworICAgIGVzYWMKKyAgICBldmFsICRhY19lbnZ2YXI9XCRhY19vcHRhcmcKKyAgICBl
eHBvcnQgJGFjX2VudnZhciA7OworCisgICopCisgICAgIyBGSVhNRTogc2hvdWxkIGJlIHJlbW92
ZWQgaW4gYXV0b2NvbmYgMy4wLgorICAgICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHlvdSBz
aG91bGQgdXNlIC0tYnVpbGQsIC0taG9zdCwgLS10YXJnZXQiID4mMgorICAgIGV4cHIgIngkYWNf
b3B0aW9uIiA6ICIuKlteLS5fJGFzX2NyX2FsbnVtXSIgPi9kZXYvbnVsbCAmJgorICAgICAgJGFz
X2VjaG8gIiRhc19tZTogV0FSTklORzogaW52YWxpZCBob3N0IHR5cGU6ICRhY19vcHRpb24iID4m
MgorICAgIDogIiR7YnVpbGRfYWxpYXM9JGFjX29wdGlvbn0gJHtob3N0X2FsaWFzPSRhY19vcHRp
b259ICR7dGFyZ2V0X2FsaWFzPSRhY19vcHRpb259IgorICAgIDs7CisKKyAgZXNhYworZG9uZQor
CitpZiB0ZXN0IC1uICIkYWNfcHJldiI7IHRoZW4KKyAgYWNfb3B0aW9uPS0tYGVjaG8gJGFjX3By
ZXYgfCBzZWQgJ3MvXy8tL2cnYAorICBhc19mbl9lcnJvciAkPyAibWlzc2luZyBhcmd1bWVudCB0
byAkYWNfb3B0aW9uIgorZmkKKworaWYgdGVzdCAtbiAiJGFjX3VucmVjb2duaXplZF9vcHRzIjsg
dGhlbgorICBjYXNlICRlbmFibGVfb3B0aW9uX2NoZWNraW5nIGluCisgICAgbm8pIDs7CisgICAg
ZmF0YWwpIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2du
aXplZF9vcHRzIiA7OworICAgICopICAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1bnJl
Y29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXplZF9vcHRzIiA+JjIgOzsKKyAgZXNhYwor
ZmkKKworIyBDaGVjayBhbGwgZGlyZWN0b3J5IGFyZ3VtZW50cyBmb3IgY29uc2lzdGVuY3kuCitm
b3IgYWNfdmFyIGluCWV4ZWNfcHJlZml4IHByZWZpeCBiaW5kaXIgc2JpbmRpciBsaWJleGVjZGly
IGRhdGFyb290ZGlyIFwKKwkJZGF0YWRpciBzeXNjb25mZGlyIHNoYXJlZHN0YXRlZGlyIGxvY2Fs
c3RhdGVkaXIgaW5jbHVkZWRpciBcCisJCW9sZGluY2x1ZGVkaXIgZG9jZGlyIGluZm9kaXIgaHRt
bGRpciBkdmlkaXIgcGRmZGlyIHBzZGlyIFwKKwkJbGliZGlyIGxvY2FsZWRpciBtYW5kaXIKK2Rv
CisgIGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAjIFJlbW92ZSB0cmFpbGluZyBzbGFzaGVzLgor
ICBjYXNlICRhY192YWwgaW4KKyAgICAqLyApCisgICAgICBhY192YWw9YGV4cHIgIlgkYWNfdmFs
IiA6ICdYXCguKlteL11cKScgXHwgIlgkYWNfdmFsIiA6ICdYXCguKlwpJ2AKKyAgICAgIGV2YWwg
JGFjX3Zhcj1cJGFjX3ZhbDs7CisgIGVzYWMKKyAgIyBCZSBzdXJlIHRvIGhhdmUgYWJzb2x1dGUg
ZGlyZWN0b3J5IG5hbWVzLgorICBjYXNlICRhY192YWwgaW4KKyAgICBbXFwvJF0qIHwgPzpbXFwv
XSogKSAgY29udGludWU7OworICAgIE5PTkUgfCAnJyApIGNhc2UgJGFjX3ZhciBpbiAqcHJlZml4
ICkgY29udGludWU7OyBlc2FjOzsKKyAgZXNhYworICBhc19mbl9lcnJvciAkPyAiZXhwZWN0ZWQg
YW4gYWJzb2x1dGUgZGlyZWN0b3J5IG5hbWUgZm9yIC0tJGFjX3ZhcjogJGFjX3ZhbCIKK2RvbmUK
KworIyBUaGVyZSBtaWdodCBiZSBwZW9wbGUgd2hvIGRlcGVuZCBvbiB0aGUgb2xkIGJyb2tlbiBi
ZWhhdmlvcjogYCRob3N0JworIyB1c2VkIHRvIGhvbGQgdGhlIGFyZ3VtZW50IG9mIC0taG9zdCBl
dGMuCisjIEZJWE1FOiBUbyByZW1vdmUgc29tZSBkYXkuCitidWlsZD0kYnVpbGRfYWxpYXMKK2hv
c3Q9JGhvc3RfYWxpYXMKK3RhcmdldD0kdGFyZ2V0X2FsaWFzCisKKyMgRklYTUU6IFRvIHJlbW92
ZSBzb21lIGRheS4KK2lmIHRlc3QgIngkaG9zdF9hbGlhcyIgIT0geDsgdGhlbgorICBpZiB0ZXN0
ICJ4JGJ1aWxkX2FsaWFzIiA9IHg7IHRoZW4KKyAgICBjcm9zc19jb21waWxpbmc9bWF5YmUKKyAg
ICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBpZiB5b3Ugd2FudGVkIHRvIHNldCB0aGUgLS1i
dWlsZCB0eXBlLCBkb24ndCB1c2UgLS1ob3N0LgorICAgIElmIGEgY3Jvc3MgY29tcGlsZXIgaXMg
ZGV0ZWN0ZWQgdGhlbiBjcm9zcyBjb21waWxlIG1vZGUgd2lsbCBiZSB1c2VkIiA+JjIKKyAgZWxp
ZiB0ZXN0ICJ4JGJ1aWxkX2FsaWFzIiAhPSAieCRob3N0X2FsaWFzIjsgdGhlbgorICAgIGNyb3Nz
X2NvbXBpbGluZz15ZXMKKyAgZmkKK2ZpCisKK2FjX3Rvb2xfcHJlZml4PQordGVzdCAtbiAiJGhv
c3RfYWxpYXMiICYmIGFjX3Rvb2xfcHJlZml4PSRob3N0X2FsaWFzLQorCit0ZXN0ICIkc2lsZW50
IiA9IHllcyAmJiBleGVjIDY+L2Rldi9udWxsCisKKworYWNfcHdkPWBwd2RgICYmIHRlc3QgLW4g
IiRhY19wd2QiICYmCithY19sc19kaT1gbHMgLWRpIC5gICYmCithY19wd2RfbHNfZGk9YGNkICIk
YWNfcHdkIiAmJiBscyAtZGkgLmAgfHwKKyAgYXNfZm5fZXJyb3IgJD8gIndvcmtpbmcgZGlyZWN0
b3J5IGNhbm5vdCBiZSBkZXRlcm1pbmVkIgordGVzdCAiWCRhY19sc19kaSIgPSAiWCRhY19wd2Rf
bHNfZGkiIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJwd2QgZG9lcyBub3QgcmVwb3J0IG5hbWUgb2Yg
d29ya2luZyBkaXJlY3RvcnkiCisKKworIyBGaW5kIHRoZSBzb3VyY2UgZmlsZXMsIGlmIGxvY2F0
aW9uIHdhcyBub3Qgc3BlY2lmaWVkLgoraWYgdGVzdCAteiAiJHNyY2RpciI7IHRoZW4KKyAgYWNf
c3JjZGlyX2RlZmF1bHRlZD15ZXMKKyAgIyBUcnkgdGhlIGRpcmVjdG9yeSBjb250YWluaW5nIHRo
aXMgc2NyaXB0LCB0aGVuIHRoZSBwYXJlbnQgZGlyZWN0b3J5LgorICBhY19jb25mZGlyPWAkYXNf
ZGlybmFtZSAtLSAiJGFzX215c2VsZiIgfHwKKyRhc19leHByIFgiJGFzX215c2VsZiIgOiAnWFwo
LipbXi9dXCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkgWCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wp
W14vXScgXHwgXAorCSBYIiRhc19teXNlbGYiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFzX215
c2VsZiIgOiAnWFwoL1wpJyBcfCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhc19teXNl
bGYiIHwKKyAgICBzZWQgJy9eWFwoLipbXi9dXClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBz
Ly9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8K
KwkgICAgcQorCSAgfQorCSAgL15YXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkg
IH0KKwkgIC9eWFwoXC9cKS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiov
Li87IHEnYAorICBzcmNkaXI9JGFjX2NvbmZkaXIKKyAgaWYgdGVzdCAhIC1yICIkc3JjZGlyLyRh
Y191bmlxdWVfZmlsZSI7IHRoZW4KKyAgICBzcmNkaXI9Li4KKyAgZmkKK2Vsc2UKKyAgYWNfc3Jj
ZGlyX2RlZmF1bHRlZD1ubworZmkKK2lmIHRlc3QgISAtciAiJHNyY2Rpci8kYWNfdW5pcXVlX2Zp
bGUiOyB0aGVuCisgIHRlc3QgIiRhY19zcmNkaXJfZGVmYXVsdGVkIiA9IHllcyAmJiBzcmNkaXI9
IiRhY19jb25mZGlyIG9yIC4uIgorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgc291cmNl
cyAoJGFjX3VuaXF1ZV9maWxlKSBpbiAkc3JjZGlyIgorZmkKK2FjX21zZz0ic291cmNlcyBhcmUg
aW4gJHNyY2RpciwgYnV0IFxgY2QgJHNyY2RpcicgZG9lcyBub3Qgd29yayIKK2FjX2Fic19jb25m
ZGlyPWAoCisJY2QgIiRzcmNkaXIiICYmIHRlc3QgLXIgIi4vJGFjX3VuaXF1ZV9maWxlIiB8fCBh
c19mbl9lcnJvciAkPyAiJGFjX21zZyIKKwlwd2QpYAorIyBXaGVuIGJ1aWxkaW5nIGluIHBsYWNl
LCBzZXQgc3JjZGlyPS4KK2lmIHRlc3QgIiRhY19hYnNfY29uZmRpciIgPSAiJGFjX3B3ZCI7IHRo
ZW4KKyAgc3JjZGlyPS4KK2ZpCisjIFJlbW92ZSB1bm5lY2Vzc2FyeSB0cmFpbGluZyBzbGFzaGVz
IGZyb20gc3JjZGlyLgorIyBEb3VibGUgc2xhc2hlcyBpbiBmaWxlIG5hbWVzIGluIG9iamVjdCBm
aWxlIGRlYnVnZ2luZyBpbmZvCisjIG1lc3MgdXAgTS14IGdkYiBpbiBFbWFjcy4KK2Nhc2UgJHNy
Y2RpciBpbgorKi8pIHNyY2Rpcj1gZXhwciAiWCRzcmNkaXIiIDogJ1hcKC4qW14vXVwpJyBcfCAi
WCRzcmNkaXIiIDogJ1hcKC4qXCknYDs7Citlc2FjCitmb3IgYWNfdmFyIGluICRhY19wcmVjaW91
c192YXJzOyBkbworICBldmFsIGFjX2Vudl8ke2FjX3Zhcn1fc2V0PVwkeyR7YWNfdmFyfStzZXR9
CisgIGV2YWwgYWNfZW52XyR7YWNfdmFyfV92YWx1ZT1cJCR7YWNfdmFyfQorICBldmFsIGFjX2N2
X2Vudl8ke2FjX3Zhcn1fc2V0PVwkeyR7YWNfdmFyfStzZXR9CisgIGV2YWwgYWNfY3ZfZW52XyR7
YWNfdmFyfV92YWx1ZT1cJCR7YWNfdmFyfQorZG9uZQorCisjCisjIFJlcG9ydCB0aGUgLS1oZWxw
IG1lc3NhZ2UuCisjCitpZiB0ZXN0ICIkYWNfaW5pdF9oZWxwIiA9ICJsb25nIjsgdGhlbgorICAj
IE9taXQgc29tZSBpbnRlcm5hbCBvciBvYnNvbGV0ZSBvcHRpb25zIHRvIG1ha2UgdGhlIGxpc3Qg
bGVzcyBpbXBvc2luZy4KKyAgIyBUaGlzIG1lc3NhZ2UgaXMgdG9vIGxvbmcgdG8gYmUgYSBzdHJp
bmcgaW4gdGhlIEEvVVggMy4xIHNoLgorICBjYXQgPDxfQUNFT0YKK1xgY29uZmlndXJlJyBjb25m
aWd1cmVzIFhlbiBIeXBlcnZpc29yIDQuMiB0byBhZGFwdCB0byBtYW55IGtpbmRzIG9mIHN5c3Rl
bXMuCisKK1VzYWdlOiAkMCBbT1BUSU9OXS4uLiBbVkFSPVZBTFVFXS4uLgorCitUbyBhc3NpZ24g
ZW52aXJvbm1lbnQgdmFyaWFibGVzIChlLmcuLCBDQywgQ0ZMQUdTLi4uKSwgc3BlY2lmeSB0aGVt
IGFzCitWQVI9VkFMVUUuICBTZWUgYmVsb3cgZm9yIGRlc2NyaXB0aW9ucyBvZiBzb21lIG9mIHRo
ZSB1c2VmdWwgdmFyaWFibGVzLgorCitEZWZhdWx0cyBmb3IgdGhlIG9wdGlvbnMgYXJlIHNwZWNp
ZmllZCBpbiBicmFja2V0cy4KKworQ29uZmlndXJhdGlvbjoKKyAgLWgsIC0taGVscCAgICAgICAg
ICAgICAgZGlzcGxheSB0aGlzIGhlbHAgYW5kIGV4aXQKKyAgICAgIC0taGVscD1zaG9ydCAgICAg
ICAgZGlzcGxheSBvcHRpb25zIHNwZWNpZmljIHRvIHRoaXMgcGFja2FnZQorICAgICAgLS1oZWxw
PXJlY3Vyc2l2ZSAgICBkaXNwbGF5IHRoZSBzaG9ydCBoZWxwIG9mIGFsbCB0aGUgaW5jbHVkZWQg
cGFja2FnZXMKKyAgLVYsIC0tdmVyc2lvbiAgICAgICAgICAgZGlzcGxheSB2ZXJzaW9uIGluZm9y
bWF0aW9uIGFuZCBleGl0CisgIC1xLCAtLXF1aWV0LCAtLXNpbGVudCAgIGRvIG5vdCBwcmludCBc
YGNoZWNraW5nIC4uLicgbWVzc2FnZXMKKyAgICAgIC0tY2FjaGUtZmlsZT1GSUxFICAgY2FjaGUg
dGVzdCByZXN1bHRzIGluIEZJTEUgW2Rpc2FibGVkXQorICAtQywgLS1jb25maWctY2FjaGUgICAg
ICBhbGlhcyBmb3IgXGAtLWNhY2hlLWZpbGU9Y29uZmlnLmNhY2hlJworICAtbiwgLS1uby1jcmVh
dGUgICAgICAgICBkbyBub3QgY3JlYXRlIG91dHB1dCBmaWxlcworICAgICAgLS1zcmNkaXI9RElS
ICAgICAgICBmaW5kIHRoZSBzb3VyY2VzIGluIERJUiBbY29uZmlndXJlIGRpciBvciBcYC4uJ10K
KworSW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVzOgorICAtLXByZWZpeD1QUkVGSVggICAgICAgICBp
bnN0YWxsIGFyY2hpdGVjdHVyZS1pbmRlcGVuZGVudCBmaWxlcyBpbiBQUkVGSVgKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgWyRhY19kZWZhdWx0X3ByZWZpeF0KKyAgLS1leGVjLXByZWZpeD1F
UFJFRklYICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtZGVwZW5kZW50IGZpbGVzIGluIEVQUkVGSVgK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgW1BSRUZJWF0KKworQnkgZGVmYXVsdCwgXGBtYWtl
IGluc3RhbGwnIHdpbGwgaW5zdGFsbCBhbGwgdGhlIGZpbGVzIGluCitcYCRhY19kZWZhdWx0X3By
ZWZpeC9iaW4nLCBcYCRhY19kZWZhdWx0X3ByZWZpeC9saWInIGV0Yy4gIFlvdSBjYW4gc3BlY2lm
eQorYW4gaW5zdGFsbGF0aW9uIHByZWZpeCBvdGhlciB0aGFuIFxgJGFjX2RlZmF1bHRfcHJlZml4
JyB1c2luZyBcYC0tcHJlZml4JywKK2ZvciBpbnN0YW5jZSBcYC0tcHJlZml4PVwkSE9NRScuCisK
K0ZvciBiZXR0ZXIgY29udHJvbCwgdXNlIHRoZSBvcHRpb25zIGJlbG93LgorCitGaW5lIHR1bmlu
ZyBvZiB0aGUgaW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVzOgorICAtLWJpbmRpcj1ESVIgICAgICAg
ICAgICB1c2VyIGV4ZWN1dGFibGVzIFtFUFJFRklYL2Jpbl0KKyAgLS1zYmluZGlyPURJUiAgICAg
ICAgICAgc3lzdGVtIGFkbWluIGV4ZWN1dGFibGVzIFtFUFJFRklYL3NiaW5dCisgIC0tbGliZXhl
Y2Rpcj1ESVIgICAgICAgIHByb2dyYW0gZXhlY3V0YWJsZXMgW0VQUkVGSVgvbGliZXhlY10KKyAg
LS1zeXNjb25mZGlyPURJUiAgICAgICAgcmVhZC1vbmx5IHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BS
RUZJWC9ldGNdCisgIC0tc2hhcmVkc3RhdGVkaXI9RElSICAgIG1vZGlmaWFibGUgYXJjaGl0ZWN0
dXJlLWluZGVwZW5kZW50IGRhdGEgW1BSRUZJWC9jb21dCisgIC0tbG9jYWxzdGF0ZWRpcj1ESVIg
ICAgIG1vZGlmaWFibGUgc2luZ2xlLW1hY2hpbmUgZGF0YSBbUFJFRklYL3Zhcl0KKyAgLS1saWJk
aXI9RElSICAgICAgICAgICAgb2JqZWN0IGNvZGUgbGlicmFyaWVzIFtFUFJFRklYL2xpYl0KKyAg
LS1pbmNsdWRlZGlyPURJUiAgICAgICAgQyBoZWFkZXIgZmlsZXMgW1BSRUZJWC9pbmNsdWRlXQor
ICAtLW9sZGluY2x1ZGVkaXI9RElSICAgICBDIGhlYWRlciBmaWxlcyBmb3Igbm9uLWdjYyBbL3Vz
ci9pbmNsdWRlXQorICAtLWRhdGFyb290ZGlyPURJUiAgICAgICByZWFkLW9ubHkgYXJjaC4taW5k
ZXBlbmRlbnQgZGF0YSByb290IFtQUkVGSVgvc2hhcmVdCisgIC0tZGF0YWRpcj1ESVIgICAgICAg
ICAgIHJlYWQtb25seSBhcmNoaXRlY3R1cmUtaW5kZXBlbmRlbnQgZGF0YSBbREFUQVJPT1RESVJd
CisgIC0taW5mb2Rpcj1ESVIgICAgICAgICAgIGluZm8gZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RE
SVIvaW5mb10KKyAgLS1sb2NhbGVkaXI9RElSICAgICAgICAgbG9jYWxlLWRlcGVuZGVudCBkYXRh
IFtEQVRBUk9PVERJUi9sb2NhbGVdCisgIC0tbWFuZGlyPURJUiAgICAgICAgICAgIG1hbiBkb2N1
bWVudGF0aW9uIFtEQVRBUk9PVERJUi9tYW5dCisgIC0tZG9jZGlyPURJUiAgICAgICAgICAgIGRv
Y3VtZW50YXRpb24gcm9vdCBbREFUQVJPT1RESVIvZG9jL3hlbi1oeXBlcnZpc29yXQorICAtLWh0
bWxkaXI9RElSICAgICAgICAgICBodG1sIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1kdmlk
aXI9RElSICAgICAgICAgICAgZHZpIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wZGZkaXI9
RElSICAgICAgICAgICAgcGRmIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wc2Rpcj1ESVIg
ICAgICAgICAgICAgcHMgZG9jdW1lbnRhdGlvbiBbRE9DRElSXQorX0FDRU9GCisKKyAgY2F0IDw8
XF9BQ0VPRgorCitTeXN0ZW0gdHlwZXM6CisgIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBm
b3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCisgIC0taG9zdD1IT1NUICAgICAgIGNyb3Nz
LWNvbXBpbGUgdG8gYnVpbGQgcHJvZ3JhbXMgdG8gcnVuIG9uIEhPU1QgW0JVSUxEXQorX0FDRU9G
CitmaQorCitpZiB0ZXN0IC1uICIkYWNfaW5pdF9oZWxwIjsgdGhlbgorICBjYXNlICRhY19pbml0
X2hlbHAgaW4KKyAgICAgc2hvcnQgfCByZWN1cnNpdmUgKSBlY2hvICJDb25maWd1cmF0aW9uIG9m
IFhlbiBIeXBlcnZpc29yIDQuMjoiOzsKKyAgIGVzYWMKKyAgY2F0IDw8XF9BQ0VPRgorCitPcHRp
b25hbCBGZWF0dXJlczoKKyAgLS1kaXNhYmxlLW9wdGlvbi1jaGVja2luZyAgaWdub3JlIHVucmVj
b2duaXplZCAtLWVuYWJsZS8tLXdpdGggb3B0aW9ucworICAtLWRpc2FibGUtRkVBVFVSRSAgICAg
ICBkbyBub3QgaW5jbHVkZSBGRUFUVVJFIChzYW1lIGFzIC0tZW5hYmxlLUZFQVRVUkU9bm8pCisg
IC0tZW5hYmxlLUZFQVRVUkVbPUFSR10gIGluY2x1ZGUgRkVBVFVSRSBbQVJHPXllc10KKyAgLS1l
bmFibGUteHNtICAgICAgICAgICAgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1
bHQsIEZsYXNrKQorICAtLWVuYWJsZS1naXRodHRwICAgICAgICBEb3dubG9hZCBHSVQgcmVwb3Np
dG9yaWVzIHZpYSBIVFRQCisgIC0tZGlzYWJsZS1tb25pdG9ycyAgICAgIERpc2FibGUgeGVuc3Rh
dCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHMKKyAgLS1lbmFibGUtdnRwbSAgICAgICAgICAg
RW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9ybSBNb2R1bGUKKyAgLS1lbmFibGUteGFwaSAg
ICAgICAgICAgRW5hYmxlIFhlbiBBUEkgQmluZGluZ3MKKyAgLS1kaXNhYmxlLXB5dGhvbnRvb2xz
ICAgRGlzYWJsZSBQeXRob24gdG9vbHMKKyAgLS1kaXNhYmxlLW9jYW1sdG9vbHMgICAgRGlzYWJs
ZSBPY2FtbCB0b29scworICAtLWVuYWJsZS1taW5pdGVybSAgICAgICBFbmFibGUgbWluaXRlcm0K
KyAgLS1lbmFibGUtbG9tb3VudCAgICAgICAgRW5hYmxlIGxvbW91bnQKKyAgLS1kaXNhYmxlLWRl
YnVnICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzCisKK1NvbWUg
aW5mbHVlbnRpYWwgZW52aXJvbm1lbnQgdmFyaWFibGVzOgorICBDQyAgICAgICAgICBDIGNvbXBp
bGVyIGNvbW1hbmQKKyAgQ0ZMQUdTICAgICAgQyBjb21waWxlciBmbGFncworICBMREZMQUdTICAg
ICBsaW5rZXIgZmxhZ3MsIGUuZy4gLUw8bGliIGRpcj4gaWYgeW91IGhhdmUgbGlicmFyaWVzIGlu
IGEKKyAgICAgICAgICAgICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgorICBMSUJT
ICAgICAgICBsaWJyYXJpZXMgdG8gcGFzcyB0byB0aGUgbGlua2VyLCBlLmcuIC1sPGxpYnJhcnk+
CisgIENQUEZMQUdTICAgIChPYmplY3RpdmUpIEMvQysrIHByZXByb2Nlc3NvciBmbGFncywgZS5n
LiAtSTxpbmNsdWRlIGRpcj4gaWYKKyAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBh
IG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+CisgIENQUCAgICAgICAgIEMgcHJl
cHJvY2Vzc29yCisgIFBSRVBFTkRfSU5DTFVERVMKKyAgICAgICAgICAgICAgTGlzdCBvZiBpbmNs
dWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCisgIFBSRVBFTkRf
TElCIExpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAod2l0aG91
dCAtTCkKKyAgQVBQRU5EX0lOQ0xVREVTCisgICAgICAgICAgICAgIExpc3Qgb2YgaW5jbHVkZSBm
b2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCisgIEFQUEVORF9MSUIgIExp
c3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFwcGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKQor
ICBQWVRIT04gICAgICBQYXRoIHRvIHRoZSBQeXRob24gcGFyc2VyCisgIFBFUkwgICAgICAgIFBh
dGggdG8gUGVybCBwYXJzZXIKKyAgQlJDVEwgICAgICAgUGF0aCB0byBicmN0bCB0b29sCisgIElQ
ICAgICAgICAgIFBhdGggdG8gaXAgdG9vbAorICBCSVNPTiAgICAgICBQYXRoIHRvIEJpc29uIHBh
cnNlciBnZW5lcmF0b3IKKyAgRkxFWCAgICAgICAgUGF0aCB0byBGbGV4IGxleGljYWwgYW5hbHlz
ZXIgZ2VuZXJhdG9yCisgIENVUkwgICAgICAgIFBhdGggdG8gY3VybC1jb25maWcgdG9vbAorICBY
TUwgICAgICAgICBQYXRoIHRvIHhtbDItY29uZmlnIHRvb2wKKyAgQkFTSCAgICAgICAgUGF0aCB0
byBiYXNoIHNoZWxsCisgIFhHRVRURVhUICAgIFBhdGggdG8geGdldHR0ZXh0IHRvb2wKKworVXNl
IHRoZXNlIHZhcmlhYmxlcyB0byBvdmVycmlkZSB0aGUgY2hvaWNlcyBtYWRlIGJ5IGBjb25maWd1
cmUnIG9yIHRvIGhlbHAKK2l0IHRvIGZpbmQgbGlicmFyaWVzIGFuZCBwcm9ncmFtcyB3aXRoIG5v
bnN0YW5kYXJkIG5hbWVzL2xvY2F0aW9ucy4KKworUmVwb3J0IGJ1Z3MgdG8gPHhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tPi4KK19BQ0VPRgorYWNfc3RhdHVzPSQ/CitmaQorCitpZiB0ZXN0
ICIkYWNfaW5pdF9oZWxwIiA9ICJyZWN1cnNpdmUiOyB0aGVuCisgICMgSWYgdGhlcmUgYXJlIHN1
YmRpcnMsIHJlcG9ydCB0aGVpciBzcGVjaWZpYyAtLWhlbHAuCisgIGZvciBhY19kaXIgaW4gOiAk
YWNfc3ViZGlyc19hbGw7IGRvIHRlc3QgIngkYWNfZGlyIiA9IHg6ICYmIGNvbnRpbnVlCisgICAg
dGVzdCAtZCAiJGFjX2RpciIgfHwKKyAgICAgIHsgY2QgIiRzcmNkaXIiICYmIGFjX3B3ZD1gcHdk
YCAmJiBzcmNkaXI9LiAmJiB0ZXN0IC1kICIkYWNfZGlyIjsgfSB8fAorICAgICAgY29udGludWUK
KyAgICBhY19idWlsZGRpcj0uCisKK2Nhc2UgIiRhY19kaXIiIGluCisuKSBhY19kaXJfc3VmZml4
PSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZpeD0gOzsKKyopCisgIGFj
X2Rpcl9zdWZmaXg9L2AkYXNfZWNobyAiJGFjX2RpciIgfCBzZWQgJ3N8XlwuW1xcL118fCdgCisg
ICMgQSAiLi4iIGZvciBlYWNoIGRpcmVjdG9yeSBpbiAkYWNfZGlyX3N1ZmZpeC4KKyAgYWNfdG9w
X2J1aWxkZGlyX3N1Yj1gJGFzX2VjaG8gIiRhY19kaXJfc3VmZml4IiB8IHNlZCAnc3wvW15cXC9d
KnwvLi58ZztzfC98fCdgCisgIGNhc2UgJGFjX3RvcF9idWlsZGRpcl9zdWIgaW4KKyAgIiIpIGFj
X3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4PSA7OworICAqKSAgYWNfdG9w
X2J1aWxkX3ByZWZpeD0kYWNfdG9wX2J1aWxkZGlyX3N1Yi8gOzsKKyAgZXNhYyA7OworZXNhYwor
YWNfYWJzX3RvcF9idWlsZGRpcj0kYWNfcHdkCithY19hYnNfYnVpbGRkaXI9JGFjX3B3ZCRhY19k
aXJfc3VmZml4CisjIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5OgorYWNfdG9wX2J1aWxkZGly
PSRhY190b3BfYnVpbGRfcHJlZml4CisKK2Nhc2UgJHNyY2RpciBpbgorICAuKSAgIyBXZSBhcmUg
YnVpbGRpbmcgaW4gcGxhY2UuCisgICAgYWNfc3JjZGlyPS4KKyAgICBhY190b3Bfc3JjZGlyPSRh
Y190b3BfYnVpbGRkaXJfc3ViCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9JGFjX3B3ZCA7OworICBb
XFwvXSogfCA/OltcXC9dKiApICAjIEFic29sdXRlIG5hbWUuCisgICAgYWNfc3JjZGlyPSRzcmNk
aXIkYWNfZGlyX3N1ZmZpeDsKKyAgICBhY190b3Bfc3JjZGlyPSRzcmNkaXIKKyAgICBhY19hYnNf
dG9wX3NyY2Rpcj0kc3JjZGlyIDs7CisgICopICMgUmVsYXRpdmUgbmFtZS4KKyAgICBhY19zcmNk
aXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyJGFjX2Rpcl9zdWZmaXgKKyAgICBhY190b3Bf
c3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpcgorICAgIGFjX2Fic190b3Bfc3JjZGly
PSRhY19wd2QvJHNyY2RpciA7OworZXNhYworYWNfYWJzX3NyY2Rpcj0kYWNfYWJzX3RvcF9zcmNk
aXIkYWNfZGlyX3N1ZmZpeAorCisgICAgY2QgIiRhY19kaXIiIHx8IHsgYWNfc3RhdHVzPSQ/OyBj
b250aW51ZTsgfQorICAgICMgQ2hlY2sgZm9yIGd1ZXN0ZWQgY29uZmlndXJlLgorICAgIGlmIHRl
c3QgLWYgIiRhY19zcmNkaXIvY29uZmlndXJlLmdudSI7IHRoZW4KKyAgICAgIGVjaG8gJiYKKyAg
ICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUuZ251IiAtLWhlbHA9cmVjdXJzaXZlCisg
ICAgZWxpZiB0ZXN0IC1mICIkYWNfc3JjZGlyL2NvbmZpZ3VyZSI7IHRoZW4KKyAgICAgIGVjaG8g
JiYKKyAgICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUiIC0taGVscD1yZWN1cnNpdmUK
KyAgICBlbHNlCisgICAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBubyBjb25maWd1cmF0
aW9uIGluZm9ybWF0aW9uIGlzIGluICRhY19kaXIiID4mMgorICAgIGZpIHx8IGFjX3N0YXR1cz0k
PworICAgIGNkICIkYWNfcHdkIiB8fCB7IGFjX3N0YXR1cz0kPzsgYnJlYWs7IH0KKyAgZG9uZQor
ZmkKKwordGVzdCAtbiAiJGFjX2luaXRfaGVscCIgJiYgZXhpdCAkYWNfc3RhdHVzCitpZiAkYWNf
aW5pdF92ZXJzaW9uOyB0aGVuCisgIGNhdCA8PFxfQUNFT0YKK1hlbiBIeXBlcnZpc29yIGNvbmZp
Z3VyZSA0LjIKK2dlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OAorCitDb3B5cmlnaHQgKEMp
IDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCitUaGlzIGNvbmZpZ3VyZSBzY3Jp
cHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbgorZ2l2ZXMg
dW5saW1pdGVkIHBlcm1pc3Npb24gdG8gY29weSwgZGlzdHJpYnV0ZSBhbmQgbW9kaWZ5IGl0Lgor
X0FDRU9GCisgIGV4aXQKK2ZpCisKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMg
QXV0b2NvbmYgaW5pdGlhbGl6YXRpb24uICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
IyMKKworIyBhY19mbl9jX3RyeV9jb21waWxlIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorIyBUcnkgdG8gY29tcGlsZSBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdo
ZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19mbl9jX3RyeV9jb21waWxlICgpCit7CisgIGFzX2xp
bmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRh
c19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29uZnRlc3QuJGFjX29iamV4dAorICBpZiB7IHsgYWNf
dHJ5PSIkYWNfY29tcGlsZSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAq
XFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owor
ZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAk
YWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAi
JGFjX2NvbXBpbGUiKSAyPmNvbmZ0ZXN0LmVycgorICBhY19zdGF0dXM9JD8KKyAgaWYgdGVzdCAt
cyBjb25mdGVzdC5lcnI7IHRoZW4KKyAgICBncmVwIC12ICdeICorJyBjb25mdGVzdC5lcnIgPmNv
bmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1CisgICAgbXYgLWYgY29uZnRlc3Qu
ZXIxIGNvbmZ0ZXN0LmVycgorICBmaQorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfSAm
JiB7CisJIHRlc3QgLXogIiRhY19jX3dlcnJvcl9mbGFnIiB8fAorCSB0ZXN0ICEgLXMgY29uZnRl
c3QuZXJyCisgICAgICAgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LiRhY19vYmpleHQ7IHRoZW4gOgor
ICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3
YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworCWFjX3JldHZh
bD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1
bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCisKK30gIyBhY19m
bl9jX3RyeV9jb21waWxlCisKKyMgYWNfZm5fY190cnlfY3BwIExJTkVOTworIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCisjIFRyeSB0byBwcmVwcm9jZXNzIGNvbmZ0ZXN0LiRhY19leHQsIGFuZCBy
ZXR1cm4gd2hldGhlciB0aGlzIHN1Y2NlZWRlZC4KK2FjX2ZuX2NfdHJ5X2NwcCAoKQoreworICBh
c19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFj
az0kYXNfbGluZW5vX3N0YWNrCisgIGlmIHsgeyBhY190cnk9IiRhY19jcHAgY29uZnRlc3QuJGFj
X2V4dCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlf
ZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBh
Y190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9c
IiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NwcCBjb25m
dGVzdC4kYWNfZXh0IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3Qg
LXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5j
b25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0
LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0g
PiBjb25mdGVzdC5pICYmIHsKKwkgdGVzdCAteiAiJGFjX2NfcHJlcHJvY193YXJuX2ZsYWckYWNf
Y193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAgIH07IHRo
ZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJv
Z3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworICAg
IGFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0
YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCisK
K30gIyBhY19mbl9jX3RyeV9jcHAKKworIyBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsIExJ
TkVOTyBIRUFERVIgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhlciBIRUFERVIgZXhpc3Rz
LCBnaXZpbmcgYSB3YXJuaW5nIGlmIGl0IGNhbm5vdCBiZSBjb21waWxlZCB1c2luZworIyB0aGUg
aW5jbHVkZSBmaWxlcyBpbiBJTkNMVURFUyBhbmQgc2V0dGluZyB0aGUgY2FjaGUgdmFyaWFibGUg
VkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAoKQorewor
ICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19z
dGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
MiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KK2lmIGV2YWwg
XCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZmkK
K2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsg
fQorZWxzZQorICAjIElzIHRoZSBoZWFkZXIgY29tcGlsYWJsZT8KK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIgdXNhYmlsaXR5IiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nICQyIHVzYWJpbGl0eS4uLiAiID4mNjsgfQorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJDQK
KyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19oZWFkZXJfY29tcGlsZXI9eWVzCitlbHNlCisgIGFjX2hlYWRlcl9jb21w
aWxlcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
Y29uZnRlc3QuJGFjX2V4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19oZWFkZXJfY29tcGlsZXIiID4mNQorJGFzX2VjaG8gIiRhY19oZWFkZXJf
Y29tcGlsZXIiID4mNjsgfQorCisjIElzIHRoZSBoZWFkZXIgcHJlc2VudD8KK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIgcHJlc2VuY2UiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgJDIgcHJlc2VuY2UuLi4gIiA+JjY7IH0KK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2hlYWRlcl9wcmVwcm9jPXllcworZWxzZQorICBhY19oZWFkZXJfcHJlcHJvYz1u
bworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfaGVhZGVy
X3ByZXByb2MiID4mNQorJGFzX2VjaG8gIiRhY19oZWFkZXJfcHJlcHJvYyIgPiY2OyB9CisKKyMg
U28/ICBXaGF0IGFib3V0IHRoaXMgaGVhZGVyPworY2FzZSAkYWNfaGVhZGVyX2NvbXBpbGVyOiRh
Y19oZWFkZXJfcHJlcHJvYzokYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAjKCgKKyAgeWVzOm5v
OiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiAkMjogYWNjZXB0ZWQgYnkgdGhlIGNvbXBpbGVyLCByZWplY3RlZCBieSB0aGUgcHJlcHJvY2Vz
c29yISIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogYWNjZXB0ZWQgYnkgdGhl
IGNvbXBpbGVyLCByZWplY3RlZCBieSB0aGUgcHJlcHJvY2Vzc29yISIgPiYyO30KKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBwcm9jZWVk
aW5nIHdpdGggdGhlIGNvbXBpbGVyJ3MgcmVzdWx0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6ICQyOiBwcm9jZWVkaW5nIHdpdGggdGhlIGNvbXBpbGVyJ3MgcmVzdWx0IiA+JjI7fQor
ICAgIDs7CisgIG5vOnllczoqICkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3QgYmUgY29tcGlsZWQiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHByZXNlbnQgYnV0IGNhbm5vdCBiZSBj
b21waWxlZCIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IFdBUk5JTkc6ICQyOiAgICAgY2hlY2sgZm9yIG1pc3NpbmcgcHJlcmVxdWlzaXRlIGhlYWRl
cnM/IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiAgICAgY2hlY2sgZm9yIG1p
c3NpbmcgcHJlcmVxdWlzaXRlIGhlYWRlcnM/IiA+JjI7fQorICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6IHNlZSB0aGUgQXV0b2NvbmYgZG9j
dW1lbnRhdGlvbiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogc2VlIHRoZSBB
dXRvY29uZiBkb2N1bWVudGF0aW9uIiA+JjI7fQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6ICAgICBzZWN0aW9uIFwiUHJlc2VudCBCdXQg
Q2Fubm90IEJlIENvbXBpbGVkXCIiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6
ICAgICBzZWN0aW9uIFwiUHJlc2VudCBCdXQgQ2Fubm90IEJlIENvbXBpbGVkXCIiID4mMjt9Cisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjog
cHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIg
PiYyO30KKyggJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tICMjCisjIyBSZXBvcnQgdGhpcyB0byB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbSAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
IyMiCisgICAgICkgfCBzZWQgInMvXi8kYXNfbWU6IFdBUk5JTkc6ICAgICAvIiA+JjIKKyAgICA7
OworZXNhYworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0K
K2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBldmFsICIkMz1cJGFjX2hlYWRlcl9jb21waWxlciIKK2ZpCitldmFsIGFj
X3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KK2ZpCisg
IGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xp
bmVubworCit9ICMgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbAorCisjIGFjX2ZuX2NfdHJ5
X3J1biBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gbGluayBjb25m
dGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuIEFzc3VtZXMK
KyMgdGhhdCBleGVjdXRhYmxlcyAqY2FuKiBiZSBydW4uCithY19mbl9jX3RyeV9ydW4gKCkKK3sK
KyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9f
c3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2Ug
IigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry
eTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0i
XCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hv
ICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0
YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfSAmJiB7IGFjX3RyeT0nLi9j
b25mdGVzdCRhY19leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAq
XGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNf
dHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAg
KGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfTsgfTsgdGhlbiA6CisgIGFjX3JldHZhbD0wCitlbHNlCisgICRhc19lY2hv
ICIkYXNfbWU6IHByb2dyYW0gZXhpdGVkIHdpdGggc3RhdHVzICRhY19zdGF0dXMiID4mNQorICAg
ICAgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQorc2VkICdzL14v
fCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCisgICAgICAgYWNfcmV0dmFsPSRhY19zdGF0dXMK
K2ZpCisgIHJtIC1yZiBjb25mdGVzdC5kU1lNIGNvbmZ0ZXN0X2lwYThfY29uZnRlc3Qub28KKyAg
ZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQgYXNfbGlu
ZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMgYWNfZm5fY190cnlfcnVu
CisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSBMSU5FTk8gSEVBREVSIFZBUiBJTkNM
VURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4aXN0cyBhbmQgY2FuIGJlIGNvbXBpbGVk
IHVzaW5nIHRoZSBpbmNsdWRlIGZpbGVzIGluCisjIElOQ0xVREVTLCBzZXR0aW5nIHRoZSBjYWNo
ZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCithY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxl
ICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf
bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJDQKKyNpbmNs
dWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
OgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgorZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK2V2
YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQor
ICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19s
aW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUKKworIyBhY19mbl9jX3Ry
eV9saW5rIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gbGluayBj
b25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19m
bl9jX3RyeV9saW5rICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5l
bm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdCRhY19leGVleHQKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2xp
bmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2Vj
aG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNf
dHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIi
CiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj5j
b25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0
aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBj
YXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIK
KyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFj
X3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeworCSB0ZXN0IC16ICIk
YWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAgIH0g
JiYgdGVzdCAtcyBjb25mdGVzdCRhY19leGVleHQgJiYgeworCSB0ZXN0ICIkY3Jvc3NfY29tcGls
aW5nIiA9IHllcyB8fAorCSAkYXNfdGVzdF94IGNvbmZ0ZXN0JGFjX2V4ZWV4dAorICAgICAgIH07
IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQg
cHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKwor
CWFjX3JldHZhbD0xCitmaQorICAjIERlbGV0ZSB0aGUgSVBBL0lQTyAoSW50ZXIgUHJvY2VkdXJh
bCBBbmFseXNpcy9PcHRpbWl6YXRpb24pIGluZm9ybWF0aW9uCisgICMgY3JlYXRlZCBieSB0aGUg
UEdJIGNvbXBpbGVyIChjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vKSwgYXMgaXQgd291bGQKKyAg
IyBpbnRlcmZlcmUgd2l0aCB0aGUgbmV4dCBsaW5rIGNvbW1hbmQ7IGFsc28gZGVsZXRlIGEgZGly
ZWN0b3J5IHRoYXQgaXMKKyAgIyBsZWZ0IGJlaGluZCBieSBBcHBsZSdzIGNvbXBpbGVyLiAgV2Ug
ZG8gdGhpcyBiZWZvcmUgZXhlY3V0aW5nIHRoZSBhY3Rpb25zLgorICBybSAtcmYgY29uZnRlc3Qu
ZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsg
JHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworICBhc19mbl9zZXRfc3RhdHVz
ICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5X2xpbmsKKworIyBhY19mbl9jX2NoZWNrX3R5
cGUgTElORU5PIFRZUEUgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhlciBUWVBFIGV4aXN0cyBhZnRlciBoYXZp
bmcgaW5jbHVkZWQgSU5DTFVERVMsIHNldHRpbmcgY2FjaGUKKyMgdmFyaWFibGUgVkFSIGFjY29y
ZGluZ2x5LgorYWNfZm5fY19jaGVja190eXBlICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVu
by0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFs
IFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgZXZhbCAiJDM9bm8iCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0CitpbnQKK21haW4gKCkKK3sKK2lm
IChzaXplb2YgKCQyKSkKKwkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
JDQKK2ludAorbWFpbiAoKQoreworaWYgKHNpemVvZiAoKCQyKSkpCisJICAgIHJldHVybiAwOwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgZXZhbCAiJDM9eWVzIgorZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAor
ZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4m
NjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNl
dCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfdHlwZQorCisjIGFjX2ZuX2NfY2hlY2tf
ZnVuYyBMSU5FTk8gRlVOQyBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3RzLCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJs
ZSBWQVIgYWNjb3JkaW5nbHkKK2FjX2ZuX2NfY2hlY2tfZnVuYyAoKQoreworICBhc19saW5lbm89
JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGlu
ZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4uLiAiID4mNjsg
fQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIERlZmluZSAkMiB0byBhbiBpbm5vY3VvdXMg
dmFyaWFudCwgaW4gY2FzZSA8bGltaXRzLmg+IGRlY2xhcmVzICQyLgorICAgRm9yIGV4YW1wbGUs
IEhQLVVYIDExaSA8bGltaXRzLmg+IGRlY2xhcmVzIGdldHRpbWVvZmRheS4gICovCisjZGVmaW5l
ICQyIGlubm9jdW91c18kMgorCisvKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFj
cm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCisgICAgd2hpY2ggY2FuIGNvbmZsaWN0
IHdpdGggY2hhciAkMiAoKTsgYmVsb3cuCisgICAgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2Vy
dC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAgIDxsaW1pdHMuaD4gZXhpc3Rz
IGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4gICovCisKKyNpZmRlZiBfX1NURENfXwor
IyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlm
CisKKyN1bmRlZiAkMgorCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0
byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo
ZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQg
cHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0
ZXJuICJDIgorI2VuZGlmCitjaGFyICQyICgpOworLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5l
cyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cworICAgIHRvIGFsd2F5cyBm
YWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkCisgICAg
c29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlh
cy4gICovCisjaWYgZGVmaW5lZCBfX3N0dWJfJDIgfHwgZGVmaW5lZCBfX3N0dWJfX18kMgorY2hv
a2UgbWUKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAkMiAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgorZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkMworCSAgICAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Cisk
YXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19s
aW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNfZm5fY19jaGVja19mdW5j
CisKKyMgYWNfZm5fY19maW5kX2ludFhfdCBMSU5FTk8gQklUUyBWQVIKKyMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgRmluZHMgYSBzaWduZWQgaW50ZWdlciB0eXBlIHdp
dGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIKKyMgYWNjb3JkaW5nbHku
CithY19mbl9jX2ZpbmRfaW50WF90ICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEi
fSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW50JDJf
dCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW50JDJfdC4uLiAiID4mNjsgfQoraWYg
ZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAtIG5ldmVy
IGNoZWNrIGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKKyAgICAgIyB0aGFuIGhh
bGYgb2YgdGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KKyAgICAgZm9yIGFjX3R5cGUgaW4gaW50
JDJfdCAnaW50JyAnbG9uZyBpbnQnIFwKKwkgJ2xvbmcgbG9uZyBpbnQnICdzaG9ydCBpbnQnICdz
aWduZWQgY2hhcic7IGRvCisgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQK
KwkgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7CitzdGF0aWMg
aW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAx
IDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAor
LyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKwkgICAgICAgIGVu
dW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7CitzdGF0aWMgaW50IHRlc3Rf
YXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwgTikg
LSAxKSAqIDIgKyAxKQorCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwg
TikgLSAxKSAqIDIgKyAyKSldOwordGVzdF9hcnJheSBbMF0gPSAwCisKKyAgOworICByZXR1cm4g
MDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgor
CitlbHNlCisgIGNhc2UgJGFjX3R5cGUgaW4gIygKKyAgaW50JDJfdCkgOgorICAgIGV2YWwgIiQz
PXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsg
dGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFjX3Jlcz1c
JCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNf
bGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQgYXNfbGluZW5vCisKK30g
IyBhY19mbl9jX2ZpbmRfaW50WF90CisKKyMgYWNfZm5fY19jaGVja19tZW1iZXIgTElORU5PIEFH
R1IgTUVNQkVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyaWVzIHRvIGZpbmQgaWYgdGhlIGZpZWxkIE1FTUJF
UiBleGlzdHMgaW4gdHlwZSBBR0dSLCBhZnRlciBpbmNsdWRpbmcKKyMgSU5DTFVERVMsIHNldHRp
bmcgY2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19tZW1iZXIg
KCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19s
aW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMi4kMyIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJDIuJDMuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDQrOn0gZmFsc2U7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNQor
aW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChhY19hZ2dyLiQzKQorcmV0
dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBp
bGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDQ9eWVzIgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CiskNQoraW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChzaXplb2YgYWNf
YWdnci4kMykKK3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwgIiQ0PXllcyIKK2Vsc2UK
KyAgZXZhbCAiJDQ9bm8iCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkNAor
CSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVu
b19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNf
Zm5fY19jaGVja19tZW1iZXIKKworIyBhY19mbl9jX2ZpbmRfdWludFhfdCBMSU5FTk8gQklUUyBW
QVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEZpbmRzIGFuIHVu
c2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRoIEJJVFMsIHNldHRpbmcgY2FjaGUgdmFyaWFi
bGUgVkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19maW5kX3VpbnRYX3QgKCkKK3sKKyAgYXNf
bGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9
JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
dWludCQyX3QuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIkMz1ubyIKKyAgICAgIyBP
cmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxs
eSBzbWFsbGVyCisgICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGgu
CisgICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90ICd1bnNpZ25lZCBpbnQnICd1bnNpZ25lZCBs
b25nIGludCcgXAorCSAndW5zaWduZWQgbG9uZyBsb25nIGludCcgJ3Vuc2lnbmVkIHNob3J0IGlu
dCcgJ3Vuc2lnbmVkIGNoYXInOyBkbworICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19k
ZWZhdWx0CitpbnQKK21haW4gKCkKK3sKK3N0YXRpYyBpbnQgdGVzdF9hcnJheSBbMSAtIDIgKiAh
KCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8gMiAtIDEpID09IDMpXTsK
K3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2FzZSAkYWNfdHlwZSBpbiAj
KAorICB1aW50JDJfdCkgOgorICAgIGV2YWwgIiQzPXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2
YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3Qg
XCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRv
bmUKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVz
IiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0g
dW5zZXQgYXNfbGluZW5vCisKK30gIyBhY19mbl9jX2ZpbmRfdWludFhfdAorY2F0ID5jb25maWcu
bG9nIDw8X0FDRU9GCitUaGlzIGZpbGUgY29udGFpbnMgYW55IG1lc3NhZ2VzIHByb2R1Y2VkIGJ5
IGNvbXBpbGVycyB3aGlsZQorcnVubmluZyBjb25maWd1cmUsIHRvIGFpZCBkZWJ1Z2dpbmcgaWYg
Y29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KKworSXQgd2FzIGNyZWF0ZWQgYnkgWGVuIEh5cGVy
dmlzb3IgJGFzX21lIDQuMiwgd2hpY2ggd2FzCitnZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIu
NjguICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICAkICQwICRACisKK19BQ0VPRgor
ZXhlYyA1Pj5jb25maWcubG9nCit7CitjYXQgPDxfQVNVTkFNRQorIyMgLS0tLS0tLS0tICMjCisj
IyBQbGF0Zm9ybS4gIyMKKyMjIC0tLS0tLS0tLSAjIworCitob3N0bmFtZSA9IGAoaG9zdG5hbWUg
fHwgdW5hbWUgLW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAordW5hbWUgLW0gPSBgKHVuYW1lIC1t
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtciA9IGAodW5hbWUgLXIpIDI+
L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1zID0gYCh1bmFtZSAtcykgMj4vZGV2
L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXYgPSBgKHVuYW1lIC12KSAyPi9kZXYvbnVs
bCB8fCBlY2hvIHVua25vd25gCisKKy91c3IvYmluL3VuYW1lIC1wID0gYCgvdXNyL2Jpbi91bmFt
ZSAtcCkgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAorL2Jpbi91bmFtZSAtWCAgICAgPSBg
KC9iaW4vdW5hbWUgLVgpIDI+L2Rldi9udWxsICAgICB8fCBlY2hvIHVua25vd25gCisKKy9iaW4v
YXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkgMj4vZGV2L251bGwgICAgICAgICAgICAg
IHx8IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL2FyY2ggLWsgICAgICAgPSBgKC91c3IvYmluL2Fy
Y2ggLWspIDI+L2Rldi9udWxsICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy91c3IvY29udmV4L2dl
dHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dldHN5c2luZm8pIDI+L2Rldi9udWxsIHx8IGVjaG8g
dW5rbm93bmAKKy91c3IvYmluL2hvc3RpbmZvICAgICAgPSBgKC91c3IvYmluL2hvc3RpbmZvKSAy
Pi9kZXYvbnVsbCAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vbWFjaGluZSAgICAgICAgICAg
PSBgKC9iaW4vbWFjaGluZSkgMj4vZGV2L251bGwgICAgICAgICAgIHx8IGVjaG8gdW5rbm93bmAK
Ky91c3IvYmluL29zbGV2ZWwgICAgICAgPSBgKC91c3IvYmluL29zbGV2ZWwpIDI+L2Rldi9udWxs
ICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vdW5pdmVyc2UgICAgICAgICAgPSBgKC9iaW4v
dW5pdmVyc2UpIDI+L2Rldi9udWxsICAgICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKworX0FTVU5B
TUUKKworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBp
biAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgorICAgICRhc19lY2hvICJQQVRIOiAkYXNfZGlyIgorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK30gPiY1CisKK2NhdCA+JjUgPDxfQUNFT0YKKworCisjIyAtLS0tLS0tLS0tLSAj
IworIyMgQ29yZSB0ZXN0cy4gIyMKKyMjIC0tLS0tLS0tLS0tICMjCisKK19BQ0VPRgorCisKKyMg
S2VlcCBhIHRyYWNlIG9mIHRoZSBjb21tYW5kIGxpbmUuCisjIFN0cmlwIG91dCAtLW5vLWNyZWF0
ZSBhbmQgLS1uby1yZWN1cnNpb24gc28gdGhleSBkbyBub3QgcGlsZSB1cC4KKyMgU3RyaXAgb3V0
IC0tc2lsZW50IGJlY2F1c2Ugd2UgZG9uJ3Qgd2FudCB0byByZWNvcmQgaXQgZm9yIGZ1dHVyZSBy
dW5zLgorIyBBbHNvIHF1b3RlIGFueSBhcmdzIGNvbnRhaW5pbmcgc2hlbGwgbWV0YS1jaGFyYWN0
ZXJzLgorIyBNYWtlIHR3byBwYXNzZXMgdG8gYWxsb3cgZm9yIHByb3BlciBkdXBsaWNhdGUtYXJn
dW1lbnQgc3VwcHJlc3Npb24uCithY19jb25maWd1cmVfYXJncz0KK2FjX2NvbmZpZ3VyZV9hcmdz
MD0KK2FjX2NvbmZpZ3VyZV9hcmdzMT0KK2FjX211c3Rfa2VlcF9uZXh0PWZhbHNlCitmb3IgYWNf
cGFzcyBpbiAxIDIKK2RvCisgIGZvciBhY19hcmcKKyAgZG8KKyAgICBjYXNlICRhY19hcmcgaW4K
KyAgICAtbm8tY3JlYXRlIHwgLS1uby1jKiB8IC1uIHwgLW5vLXJlY3Vyc2lvbiB8IC0tbm8tciop
IGNvbnRpbnVlIDs7CisgICAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwgLS1xdWllIHwgLS1xdWkg
fCAtLXF1IHwgLS1xIFwKKyAgICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2lsZW4gfCAtLXNp
bGUgfCAtLXNpbCkKKyAgICAgIGNvbnRpbnVlIDs7CisgICAgKlwnKikKKyAgICAgIGFjX2FyZz1g
JGFzX2VjaG8gIiRhY19hcmciIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgIDs7CisgICAgZXNh
YworICAgIGNhc2UgJGFjX3Bhc3MgaW4KKyAgICAxKSBhc19mbl9hcHBlbmQgYWNfY29uZmlndXJl
X2FyZ3MwICIgJyRhY19hcmcnIiA7OworICAgIDIpCisgICAgICBhc19mbl9hcHBlbmQgYWNfY29u
ZmlndXJlX2FyZ3MxICIgJyRhY19hcmcnIgorICAgICAgaWYgdGVzdCAkYWNfbXVzdF9rZWVwX25l
eHQgPSB0cnVlOyB0aGVuCisJYWNfbXVzdF9rZWVwX25leHQ9ZmFsc2UgIyBHb3QgdmFsdWUsIGJh
Y2sgdG8gbm9ybWFsLgorICAgICAgZWxzZQorCWNhc2UgJGFjX2FyZyBpbgorCSAgKj0qIHwgLS1j
b25maWctY2FjaGUgfCAtQyB8IC1kaXNhYmxlLSogfCAtLWRpc2FibGUtKiBcCisJICB8IC1lbmFi
bGUtKiB8IC0tZW5hYmxlLSogfCAtZ2FzIHwgLS1nKiB8IC1uZnAgfCAtLW5mKiBcCisJICB8IC1x
IHwgLXF1aWV0IHwgLS1xKiB8IC1zaWxlbnQgfCAtLXNpbCogfCAtdiB8IC12ZXJiKiBcCisJICB8
IC13aXRoLSogfCAtLXdpdGgtKiB8IC13aXRob3V0LSogfCAtLXdpdGhvdXQtKiB8IC0teCkKKwkg
ICAgY2FzZSAiJGFjX2NvbmZpZ3VyZV9hcmdzMCAiIGluCisJICAgICAgIiRhY19jb25maWd1cmVf
YXJnczEiKiIgJyRhY19hcmcnICIqICkgY29udGludWUgOzsKKwkgICAgZXNhYworCSAgICA7Owor
CSAgLSogKSBhY19tdXN0X2tlZXBfbmV4dD10cnVlIDs7CisJZXNhYworICAgICAgZmkKKyAgICAg
IGFzX2ZuX2FwcGVuZCBhY19jb25maWd1cmVfYXJncyAiICckYWNfYXJnJyIKKyAgICAgIDs7Cisg
ICAgZXNhYworICBkb25lCitkb25lCit7IGFjX2NvbmZpZ3VyZV9hcmdzMD07IHVuc2V0IGFjX2Nv
bmZpZ3VyZV9hcmdzMDt9Cit7IGFjX2NvbmZpZ3VyZV9hcmdzMT07IHVuc2V0IGFjX2NvbmZpZ3Vy
ZV9hcmdzMTt9CisKKyMgV2hlbiBpbnRlcnJ1cHRlZCBvciBleGl0J2QsIGNsZWFudXAgdGVtcG9y
YXJ5IGZpbGVzLCBhbmQgY29tcGxldGUKKyMgY29uZmlnLmxvZy4gIFdlIHJlbW92ZSBjb21tZW50
cyBiZWNhdXNlIGFueXdheSB0aGUgcXVvdGVzIGluIHRoZXJlCisjIHdvdWxkIGNhdXNlIHByb2Js
ZW1zIG9yIGxvb2sgdWdseS4KKyMgV0FSTklORzogVXNlICdcJycgdG8gcmVwcmVzZW50IGFuIGFw
b3N0cm9waGUgd2l0aGluIHRoZSB0cmFwLgorIyBXQVJOSU5HOiBEbyBub3Qgc3RhcnQgdGhlIHRy
YXAgY29kZSB3aXRoIGEgbmV3bGluZSwgZHVlIHRvIGEgRnJlZUJTRCA0LjAgYnVnLgordHJhcCAn
ZXhpdF9zdGF0dXM9JD8KKyAgIyBTYXZlIGludG8gY29uZmlnLmxvZyBzb21lIGluZm9ybWF0aW9u
IHRoYXQgbWlnaHQgaGVscCBpbiBkZWJ1Z2dpbmcuCisgIHsKKyAgICBlY2hvCisKKyAgICAkYXNf
ZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgQ2FjaGUgdmFyaWFibGVzLiAjIworIyMg
LS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisgICAgIyBUaGUgZm9sbG93aW5nIHdheSBv
ZiB3cml0aW5nIHRoZSBjYWNoZSBtaXNoYW5kbGVzIG5ld2xpbmVzIGluIHZhbHVlcywKKygKKyAg
Zm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAtbiAnXCcncy9eXChbYS16QS1aX11bYS16
QS1aMC05X10qXCk9LiovXDEvcCdcJydgOyBkbworICAgIGV2YWwgYWNfdmFsPVwkJGFjX3Zhcgor
ICAgIGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSopCisgICAgICBjYXNlICRhY192
YXIgaW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGlu
ZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFy
IGNvbnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVzYWMKKyAgICAgIGNhc2UgJGFj
X3ZhciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAjKAorICAgICAgQkFTSF9BUkdW
IHwgQkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAgICAgICopIHsgZXZhbCAkYWNf
dmFyPTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7CisgICAgZXNhYworICBkb25l
CisgIChzZXQpIDI+JjEgfAorICAgIGNhc2UgJGFzX25sYChhY19zcGFjZT0nXCcnICdcJyc7IHNl
dCkgMj4mMWAgaW4gIygKKyAgICAqJHthc19ubH1hY19zcGFjZT1cICopCisgICAgICBzZWQgLW4g
XAorCSJzLydcJycvJ1wnJ1xcXFwnXCcnJ1wnJy9nOworCSAgcy9eXFwoW18kYXNfY3JfYWxudW1d
Kl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwpL1xcMT0nXCcnXFwyJ1wnJy9wIgorICAg
ICAgOzsgIygKKyAgICAqKQorICAgICAgc2VkIC1uICIvXltfJGFzX2NyX2FsbnVtXSpfY3ZfW18k
YXNfY3JfYWxudW1dKj0vcCIKKyAgICAgIDs7CisgICAgZXNhYyB8CisgICAgc29ydAorKQorICAg
IGVjaG8KKworICAgICRhc19lY2hvICIjIyAtLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgT3V0cHV0
IHZhcmlhYmxlcy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tICMjIgorICAgIGVjaG8KKyAgICBm
b3IgYWNfdmFyIGluICRhY19zdWJzdF92YXJzCisgICAgZG8KKyAgICAgIGV2YWwgYWNfdmFsPVwk
JGFjX3ZhcgorICAgICAgY2FzZSAkYWNfdmFsIGluCisgICAgICAqXCdcJycqKSBhY192YWw9YCRh
c19lY2hvICIkYWNfdmFsIiB8IHNlZCAicy8nXCcnLydcJydcXFxcXFxcXCdcJycnXCcnL2ciYDs7
CisgICAgICBlc2FjCisgICAgICAkYXNfZWNobyAiJGFjX3Zhcj0nXCcnJGFjX3ZhbCdcJyciCisg
ICAgZG9uZSB8IHNvcnQKKyAgICBlY2hvCisKKyAgICBpZiB0ZXN0IC1uICIkYWNfc3Vic3RfZmls
ZXMiOyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMg
RmlsZSBzdWJzdGl0dXRpb25zLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICAg
IGVjaG8KKyAgICAgIGZvciBhY192YXIgaW4gJGFjX3N1YnN0X2ZpbGVzCisgICAgICBkbworCWV2
YWwgYWNfdmFsPVwkJGFjX3ZhcgorCWNhc2UgJGFjX3ZhbCBpbgorCSpcJ1wnJyopIGFjX3ZhbD1g
JGFzX2VjaG8gIiRhY192YWwiIHwgc2VkICJzLydcJycvJ1wnJ1xcXFxcXFxcJ1wnJydcJycvZyJg
OzsKKwllc2FjCisJJGFzX2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwnXCcnIgorICAgICAgZG9u
ZSB8IHNvcnQKKyAgICAgIGVjaG8KKyAgICBmaQorCisgICAgaWYgdGVzdCAtcyBjb25mZGVmcy5o
OyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0gIyMKKyMjIGNvbmZkZWZzLmgu
ICMjCisjIyAtLS0tLS0tLS0tLSAjIyIKKyAgICAgIGVjaG8KKyAgICAgIGNhdCBjb25mZGVmcy5o
CisgICAgICBlY2hvCisgICAgZmkKKyAgICB0ZXN0ICIkYWNfc2lnbmFsIiAhPSAwICYmCisgICAg
ICAkYXNfZWNobyAiJGFzX21lOiBjYXVnaHQgc2lnbmFsICRhY19zaWduYWwiCisgICAgJGFzX2Vj
aG8gIiRhc19tZTogZXhpdCAkZXhpdF9zdGF0dXMiCisgIH0gPiY1CisgIHJtIC1mIGNvcmUgKi5j
b3JlIGNvcmUuY29uZnRlc3QuKiAmJgorICAgIHJtIC1mIC1yIGNvbmZ0ZXN0KiBjb25mZGVmcyog
Y29uZiQkKiAkYWNfY2xlYW5fZmlsZXMgJiYKKyAgICBleGl0ICRleGl0X3N0YXR1cworJyAwCitm
b3IgYWNfc2lnbmFsIGluIDEgMiAxMyAxNTsgZG8KKyAgdHJhcCAnYWNfc2lnbmFsPSckYWNfc2ln
bmFsJzsgYXNfZm5fZXhpdCAxJyAkYWNfc2lnbmFsCitkb25lCithY19zaWduYWw9MAorCisjIGNv
bmZkZWZzLmggYXZvaWRzIE9TIGNvbW1hbmQgbGluZSBsZW5ndGggbGltaXRzIHRoYXQgREVGUyBj
YW4gZXhjZWVkLgorcm0gLWYgLXIgY29uZnRlc3QqIGNvbmZkZWZzLmgKKworJGFzX2VjaG8gIi8q
IGNvbmZkZWZzLmggKi8iID4gY29uZmRlZnMuaAorCisjIFByZWRlZmluZWQgcHJlcHJvY2Vzc29y
IHZhcmlhYmxlcy4KKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdF
X05BTUUgIiRQQUNLQUdFX05BTUUiCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
RgorI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgIiRQQUNLQUdFX1RBUk5BTUUiCitfQUNFT0YKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04gIiRQQUNL
QUdFX1ZFUlNJT04iCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBQQUNLQUdFX1NUUklORyAiJFBBQ0tBR0VfU1RSSU5HIgorX0FDRU9GCisKK2NhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9CVUdSRVBPUlQgIiRQQUNLQUdFX0JVR1JF
UE9SVCIKK19BQ0VPRgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIFBBQ0tB
R0VfVVJMICIkUEFDS0FHRV9VUkwiCitfQUNFT0YKKworCisjIExldCB0aGUgc2l0ZSBmaWxlIHNl
bGVjdCBhbiBhbHRlcm5hdGUgY2FjaGUgZmlsZSBpZiBpdCB3YW50cyB0by4KKyMgUHJlZmVyIGFu
IGV4cGxpY2l0bHkgc2VsZWN0ZWQgZmlsZSB0byBhdXRvbWF0aWNhbGx5IHNlbGVjdGVkIG9uZXMu
CithY19zaXRlX2ZpbGUxPU5PTkUKK2FjX3NpdGVfZmlsZTI9Tk9ORQoraWYgdGVzdCAtbiAiJENP
TkZJR19TSVRFIjsgdGhlbgorICAjIFdlIGRvIG5vdCB3YW50IGEgUEFUSCBzZWFyY2ggZm9yIGNv
bmZpZy5zaXRlLgorICBjYXNlICRDT05GSUdfU0lURSBpbiAjKCgKKyAgICAtKikgIGFjX3NpdGVf
ZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICAgICovKikgYWNfc2l0ZV9maWxlMT0kQ09ORklHX1NJ
VEU7OworICAgICopICAgYWNfc2l0ZV9maWxlMT0uLyRDT05GSUdfU0lURTs7CisgIGVzYWMKK2Vs
aWYgdGVzdCAieCRwcmVmaXgiICE9IHhOT05FOyB0aGVuCisgIGFjX3NpdGVfZmlsZTE9JHByZWZp
eC9zaGFyZS9jb25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUyPSRwcmVmaXgvZXRjL2NvbmZpZy5z
aXRlCitlbHNlCisgIGFjX3NpdGVfZmlsZTE9JGFjX2RlZmF1bHRfcHJlZml4L3NoYXJlL2NvbmZp
Zy5zaXRlCisgIGFjX3NpdGVfZmlsZTI9JGFjX2RlZmF1bHRfcHJlZml4L2V0Yy9jb25maWcuc2l0
ZQorZmkKK2ZvciBhY19zaXRlX2ZpbGUgaW4gIiRhY19zaXRlX2ZpbGUxIiAiJGFjX3NpdGVfZmls
ZTIiCitkbworICB0ZXN0ICJ4JGFjX3NpdGVfZmlsZSIgPSB4Tk9ORSAmJiBjb250aW51ZQorICBp
ZiB0ZXN0IC9kZXYvbnVsbCAhPSAiJGFjX3NpdGVfZmlsZSIgJiYgdGVzdCAtciAiJGFjX3NpdGVf
ZmlsZSI7IHRoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGxvYWRpbmcgc2l0ZSBzY3JpcHQgJGFjX3NpdGVfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUiID4mNjt9CisgICAgc2VkICdzL14v
fCAvJyAiJGFjX3NpdGVfZmlsZSIgPiY1CisgICAgLiAiJGFjX3NpdGVfZmlsZSIgXAorICAgICAg
fHwgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mMjt9Cithc19mbl9lcnJvciAkPyAiZmFpbGVkIHRvIGxvYWQgc2l0ZSBzY3JpcHQgJGFjX3Np
dGVfZmlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7
IH0KKyAgZmkKK2RvbmUKKworaWYgdGVzdCAtciAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICMgU29t
ZSB2ZXJzaW9ucyBvZiBiYXNoIHdpbGwgZmFpbCB0byBzb3VyY2UgL2Rldi9udWxsIChzcGVjaWFs
IGZpbGVzCisgICMgYWN0dWFsbHkpLCBzbyB3ZSBhdm9pZCBkb2luZyB0aGF0LiAgREpHUFAgZW11
bGF0ZXMgaXQgYXMgYSByZWd1bGFyIGZpbGUuCisgIGlmIHRlc3QgL2Rldi9udWxsICE9ICIkY2Fj
aGVfZmlsZSIgJiYgdGVzdCAtZiAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBsb2FkaW5nIGNhY2hlICRjYWNoZV9maWxlIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGxvYWRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9Cisg
ICAgY2FzZSAkY2FjaGVfZmlsZSBpbgorICAgICAgW1xcL10qIHwgPzpbXFwvXSogKSAuICIkY2Fj
aGVfZmlsZSI7OworICAgICAgKikgICAgICAgICAgICAgICAgICAgICAgLiAiLi8kY2FjaGVfZmls
ZSI7OworICAgIGVzYWMKKyAgZmkKK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY1CiskYXNfZWNobyAi
JGFzX21lOiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAgPiRjYWNoZV9maWxl
CitmaQorCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvdGltZS5oIgorYXNfZm5f
YXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCithc19mbl9hcHBlbmQgYWNfZnVuY19s
aXN0ICIgYWxhcm0iCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzdGRsaWIuaCIKK2Fz
X2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgorIyBDaGVjayB0aGF0IHRo
ZSBwcmVjaW91cyB2YXJpYWJsZXMgc2F2ZWQgaW4gdGhlIGNhY2hlIGhhdmUga2VwdCB0aGUgc2Ft
ZQorIyB2YWx1ZS4KK2FjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQorZm9yIGFjX3ZhciBpbiAkYWNf
cHJlY2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19vbGRfc2V0PVwkYWNfY3ZfZW52XyR7YWNfdmFy
fV9zZXQKKyAgZXZhbCBhY19uZXdfc2V0PVwkYWNfZW52XyR7YWNfdmFyfV9zZXQKKyAgZXZhbCBh
Y19vbGRfdmFsPVwkYWNfY3ZfZW52XyR7YWNfdmFyfV92YWx1ZQorICBldmFsIGFjX25ld192YWw9
XCRhY19lbnZfJHthY192YXJ9X3ZhbHVlCisgIGNhc2UgJGFjX29sZF9zZXQsJGFjX25ld19zZXQg
aW4KKyAgICBzZXQsKQorICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgc2V0IHRvIFxgJGFjX29sZF92YWwnIGluIHRoZSBw
cmV2aW91cyBydW4iID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IFxgJGFjX3Zhcicgd2Fz
IHNldCB0byBcYCRhY19vbGRfdmFsJyBpbiB0aGUgcHJldmlvdXMgcnVuIiA+JjI7fQorICAgICAg
YWNfY2FjaGVfY29ycnVwdGVkPTogOzsKKyAgICAsc2V0KQorICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgbm90IHNldCBp
biB0aGUgcHJldmlvdXMgcnVuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBcYCRhY192
YXInIHdhcyBub3Qgc2V0IGluIHRoZSBwcmV2aW91cyBydW4iID4mMjt9CisgICAgICBhY19jYWNo
ZV9jb3JydXB0ZWQ9OiA7OworICAgICwpOzsKKyAgICAqKQorICAgICAgaWYgdGVzdCAieCRhY19v
bGRfdmFsIiAhPSAieCRhY19uZXdfdmFsIjsgdGhlbgorCSMgZGlmZmVyZW5jZXMgaW4gd2hpdGVz
cGFjZSBkbyBub3QgbGVhZCB0byBmYWlsdXJlLgorCWFjX29sZF92YWxfdz1gZWNobyB4ICRhY19v
bGRfdmFsYAorCWFjX25ld192YWxfdz1gZWNobyB4ICRhY19uZXdfdmFsYAorCWlmIHRlc3QgIiRh
Y19vbGRfdmFsX3ciICE9ICIkYWNfbmV3X3ZhbF93IjsgdGhlbgorCSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFyJyBoYXMgY2hhbmdlZCBz
aW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogXGAk
YWNfdmFyJyBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiYyO30KKwkgIGFj
X2NhY2hlX2NvcnJ1cHRlZD06CisJZWxzZQorCSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiB3YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gXGAk
YWNfdmFyJyBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiB3
YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gXGAkYWNfdmFyJyBzaW5jZSB0
aGUgcHJldmlvdXMgcnVuOiIgPiYyO30KKwkgIGV2YWwgJGFjX3Zhcj1cJGFjX29sZF92YWwKKwlm
aQorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogICBmb3JtZXIgdmFs
dWU6ICBcYCRhY19vbGRfdmFsJyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAgIGZvcm1lciB2YWx1
ZTogIFxgJGFjX29sZF92YWwnIiA+JjI7fQorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogICBjdXJyZW50IHZhbHVlOiBcYCRhY19uZXdfdmFsJyIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiAgIGN1cnJlbnQgdmFsdWU6IFxgJGFjX25ld192YWwnIiA+JjI7fQorICAgICAg
Zmk7OworICBlc2FjCisgICMgUGFzcyBwcmVjaW91cyB2YXJpYWJsZXMgdG8gY29uZmlnLnN0YXR1
cy4KKyAgaWYgdGVzdCAiJGFjX25ld19zZXQiID0gc2V0OyB0aGVuCisgICAgY2FzZSAkYWNfbmV3
X3ZhbCBpbgorICAgICpcJyopIGFjX2FyZz0kYWNfdmFyPWAkYXNfZWNobyAiJGFjX25ld192YWwi
IHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgIDs7CisgICAgKikgYWNfYXJnPSRhY192YXI9JGFj
X25ld192YWwgOzsKKyAgICBlc2FjCisgICAgY2FzZSAiICRhY19jb25maWd1cmVfYXJncyAiIGlu
CisgICAgICAqIiAnJGFjX2FyZycgIiopIDs7ICMgQXZvaWQgZHVwcy4gIFVzZSBvZiBxdW90ZXMg
ZW5zdXJlcyBhY2N1cmFjeS4KKyAgICAgICopIGFzX2ZuX2FwcGVuZCBhY19jb25maWd1cmVfYXJn
cyAiICckYWNfYXJnJyIgOzsKKyAgICBlc2FjCisgIGZpCitkb25lCitpZiAkYWNfY2FjaGVfY29y
cnVwdGVkOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiYyO30KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBlcnJvcjogY2hhbmdlcyBpbiB0aGUgZW52aXJvbm1lbnQgY2FuIGNvbXByb21pc2UgdGhl
IGJ1aWxkIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjaGFuZ2VzIGluIHRoZSBlbnZp
cm9ubWVudCBjYW4gY29tcHJvbWlzZSB0aGUgYnVpbGQiID4mMjt9CisgIGFzX2ZuX2Vycm9yICQ/
ICJydW4gXGBtYWtlIGRpc3RjbGVhbicgYW5kL29yIFxgcm0gJGNhY2hlX2ZpbGUnIGFuZCBzdGFy
dCBvdmVyIiAiJExJTkVOTyIgNQorZmkKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBN
YWluIGJvZHkgb2Ygc2NyaXB0LiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKworYWNf
ZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFH
UyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRl
c3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQg
JExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKKwor
YWNfY29uZmlnX2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIC4uL2NvbmZpZy9Ub29scy5tayIKKwor
YWNfY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVhZGVycyBjb25maWcuaCIKKworCithY19h
dXhfZGlyPQorZm9yIGFjX2RpciBpbiAuICIkc3JjZGlyIi8uOyBkbworICBpZiB0ZXN0IC1mICIk
YWNfZGlyL2luc3RhbGwtc2giOyB0aGVuCisgICAgYWNfYXV4X2Rpcj0kYWNfZGlyCisgICAgYWNf
aW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvaW5zdGFsbC1zaCAtYyIKKyAgICBicmVhaworICBlbGlm
IHRlc3QgLWYgIiRhY19kaXIvaW5zdGFsbC5zaCI7IHRoZW4KKyAgICBhY19hdXhfZGlyPSRhY19k
aXIKKyAgICBhY19pbnN0YWxsX3NoPSIkYWNfYXV4X2Rpci9pbnN0YWxsLnNoIC1jIgorICAgIGJy
ZWFrCisgIGVsaWYgdGVzdCAtZiAiJGFjX2Rpci9zaHRvb2wiOyB0aGVuCisgICAgYWNfYXV4X2Rp
cj0kYWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvc2h0b29sIGluc3RhbGwg
LWMiCisgICAgYnJlYWsKKyAgZmkKK2RvbmUKK2lmIHRlc3QgLXogIiRhY19hdXhfZGlyIjsgdGhl
bgorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgaW5zdGFsbC1zaCwgaW5zdGFsbC5zaCwg
b3Igc2h0b29sIGluIC4gXCIkc3JjZGlyXCIvLiIgIiRMSU5FTk8iIDUKK2ZpCisKKyMgVGhlc2Ug
dGhyZWUgdmFyaWFibGVzIGFyZSB1bmRvY3VtZW50ZWQgYW5kIHVuc3VwcG9ydGVkLAorIyBhbmQg
YXJlIGludGVuZGVkIHRvIGJlIHdpdGhkcmF3biBpbiBhIGZ1dHVyZSBBdXRvY29uZiByZWxlYXNl
LgorIyBUaGV5IGNhbiBjYXVzZSBzZXJpb3VzIHByb2JsZW1zIGlmIGEgYnVpbGRlcidzIHNvdXJj
ZSB0cmVlIGlzIGluIGEgZGlyZWN0b3J5CisjIHdob3NlIGZ1bGwgbmFtZSBjb250YWlucyB1bnVz
dWFsIGNoYXJhY3RlcnMuCithY19jb25maWdfZ3Vlc3M9IiRTSEVMTCAkYWNfYXV4X2Rpci9jb25m
aWcuZ3Vlc3MiICAjIFBsZWFzZSBkb24ndCB1c2UgdGhpcyB2YXIuCithY19jb25maWdfc3ViPSIk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgICMgUGxlYXNlIGRvbid0IHVzZSB0aGlzIHZh
ci4KK2FjX2NvbmZpZ3VyZT0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZ3VyZSIgICMgUGxlYXNl
IGRvbid0IHVzZSB0aGlzIHZhci4KKworCisKKyMgQ2hlY2sgaWYgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5pbmcKKworaWYgdGVz
dCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIjsgdGhlbiA6CisKKyAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IFNldHRp
bmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCity
ZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitBUFBFTkRf
SU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiBTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMs
IENQUEZMQUdTIG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xV
REVTLCBQUkVQRU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3Rl
YWQgd2hlbiBwb3NzaWJsZS4iID4mMjt9CisKK2ZpCisKK2FjX2V4dD1jCithY19jcHA9JyRDUFAg
JENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0
LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdT
ICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBp
bGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK2lmIHRlc3QgLW4gIiRhY190b29sX3ByZWZp
eCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4
fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9
IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2Mi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19D
QyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBn
Y2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X0NDKzp9IGZhbHNlOyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFj
X2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0ND
CitpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19j
dF9DQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0
ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAk
Y3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5J
Tkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYy
O30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIENDPSRhY19jdF9DQworICBmaQor
ZWxzZQorICBDQz0iJGFjX2N2X3Byb2dfQ0MiCitmaQorCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVu
CisgICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAgICMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1j
YzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVu
CisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4m
NQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQor
ZmkKKworCisgIGZpCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCitlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KK2FzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGlmIHRlc3QgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgorICAgICAgIGFjX3By
b2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29udGludWUKKyAgICAgZmkKKyAgICBhY19jdl9wcm9n
X0NDPSJjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitk
b25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworaWYgdGVzdCAkYWNfcHJvZ19yZWplY3Rl
ZCA9IHllczsgdGhlbgorICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBhdGgsIHNvIG1ha2Ug
c3VyZSB3ZSBuZXZlciB1c2UgaXQuCisgIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQworICBzaGlm
dAorICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KKyAgICAjIFdlIGNob3NlIGEgZGlmZmVyZW50IGNv
bXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KKyAgICAjIEhvd2V2ZXIsIGl0IGhhcyB0aGUgc2Ft
ZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCisgICAgIyBmaXJzdCBpZiB3
ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVsbCBmaWxlIG5hbWUuCisg
ICAgc2hpZnQKKyAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193b3JkJHsxKycgJ30kQCIK
KyAgZmkKK2ZpCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
Q0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNsLmV4ZQorICBkbworICAg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY190b29s
X3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZpeCRhY19wcm9nIgor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0
IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgdGVzdCAtbiAiJENDIiAmJiBicmVhaworICBk
b25lCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MKKyAgZm9yIGFj
X3Byb2cgaW4gY2wuZXhlCitkbworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRhY19w
cm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAk
YWNfcHJvZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1u
ICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNf
cHJvZyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9DQz0kYWNfY3ZfcHJv
Z19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2Zp
CisKKworICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCitkb25lCisKKyAgaWYgdGVzdCAi
eCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3Nz
X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cith
Y190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBDQz0kYWNfY3RfQ0MKKyAgZmkKK2ZpCisK
K2ZpCisKKwordGVzdCAteiAiJENDIiAmJiB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6
IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRh
YmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQQVRICitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9y
ZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorCisjIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBh
Ym91dCB0aGUgY29tcGlsZXIuCiskYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgQyBjb21waWxlciB2ZXJzaW9uIiA+JjUKK3NldCBYICRhY19jb21waWxl
CithY19jb21waWxlcj0kMgorZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJz
aW9uOyBkbworICB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCitjYXNl
ICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190
cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNo
byAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9u
ID4mNSIpIDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBpZiB0ZXN0IC1zIGNvbmZ0
ZXN0LmVycjsgdGhlbgorICAgIHNlZCAnMTBhXAorLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBk
ZWxldGVkIC4uLgorICAgICAgICAgMTBxJyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQorICAg
IGNhdCBjb25mdGVzdC5lcjEgPiY1CisgIGZpCisgIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVz
dC5lcnIKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFj
X3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KK2RvbmUKKworY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCithY19j
bGVhbl9maWxlc19zYXZlPSRhY19jbGVhbl9maWxlcworYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVh
bl9maWxlcyBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGIub3V0IgorIyBUcnkgdG8gY3JlYXRlIGFu
IGV4ZWN1dGFibGUgd2l0aG91dCAtbyBmaXJzdCwgZGlzcmVnYXJkIGEub3V0LgorIyBJdCB3aWxs
IGhlbHAgdXMgZGlhZ25vc2UgYnJva2VuIGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGlu
dHVpdGlvbgorIyBvZiBleGVleHQuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsgfQor
YWNfbGlua19kZWZhdWx0PWAkYXNfZWNobyAiJGFjX2xpbmsiIHwgc2VkICdzLyAtbyAqY29uZnRl
c3RbXiBdKi8vJ2AKKworIyBUaGUgcG9zc2libGUgb3V0cHV0IGZpbGVzOgorYWNfZmlsZXM9ImEu
b3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBhLmV4ZSBhX291dC5leGUgYi5vdXQgY29uZnRlc3Qu
KiIKKworYWNfcm1maWxlcz0KK2ZvciBhY19maWxlIGluICRhY19maWxlcworZG8KKyAgY2FzZSAk
YWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRi
IHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8
ICoub2JqICkgOzsKKyAgICAqICkgYWNfcm1maWxlcz0iJGFjX3JtZmlsZXMgJGFjX2ZpbGUiOzsK
KyAgZXNhYworZG9uZQorcm0gLWYgJGFjX3JtZmlsZXMKKworaWYgeyB7IGFjX3RyeT0iJGFjX2xp
bmtfZGVmYXVsdCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBh
Y190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYwor
ZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5
X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xp
bmtfZGVmYXVsdCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0
dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBBdXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3Zf
ZXhlZXh0IHZhcmlhYmxlIHRvIGBubycuCisjIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBubycsIG90
aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQgdG8gYEVYRUVYVCA9IG5vJworIyBpbiBhIE1ha2VmaWxl
LiAgV2Ugc2hvdWxkIG5vdCBvdmVycmlkZSBhY19jdl9leGVleHQgaWYgaXQgd2FzIGNhY2hlZCwK
KyMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9yIGNvbXBp
bGVycyB1bmtub3duIHRvCisjIEF1dG9jb25mLgorZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzICcn
CitkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAgY2FzZSAkYWNfZmlsZSBp
bgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lN
IHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkK
Kwk7OworICAgIFthYl0ub3V0ICkKKwkjIFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUs
IGJ1dCBleGVleHQ9JycgaXMgbW9zdAorCSMgY2VydGFpbmx5IHJpZ2h0LgorCWJyZWFrOzsKKyAg
ICAqLiogKQorCWlmIHRlc3QgIiR7YWNfY3ZfZXhlZXh0K3NldH0iID0gc2V0ICYmIHRlc3QgIiRh
Y19jdl9leGVleHQiICE9IG5vOworCXRoZW4gOjsgZWxzZQorCSAgIGFjX2N2X2V4ZWV4dD1gZXhw
ciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAorCWZpCisJIyBXZSBzZXQgYWNfY3ZfZXhl
ZXh0IGhlcmUgYmVjYXVzZSB0aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMgbm90CisJIyBzYWZlOiBj
cm9zcyBjb21waWxlcnMgbWF5IG5vdCBhZGQgdGhlIHN1ZmZpeCBpZiBnaXZlbiBhbiBgLW8nCisJ
IyBhcmd1bWVudCwgc28gd2UgbWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVh
ZHkuCisJIyBFdmVuIGlmIHRoaXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6IGl0IGhhcyB0aGUgYWR2
YW50YWdlIG9mCisJIyBhY3R1YWxseSB3b3JraW5nLgorCWJyZWFrOzsKKyAgICAqICkKKwlicmVh
azs7CisgIGVzYWMKK2RvbmUKK3Rlc3QgIiRhY19jdl9leGVleHQiID0gbm8gJiYgYWNfY3ZfZXhl
ZXh0PQorCitlbHNlCisgIGFjX2ZpbGU9JycKK2ZpCitpZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRo
ZW4gOgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBw
cm9ncmFtIHdhczoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCit7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFj
X3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KK2FzX2ZuX2Vycm9yIDc3ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJsZXMK
K1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMi
ID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBm
aWxlIG5hbWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVs
dCBvdXRwdXQgZmlsZSBuYW1lLi4uICIgPiY2OyB9Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhY19maWxl
IiA+JjY7IH0KK2FjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0CisKK3JtIC1mIC1yIGEub3V0IGEub3V0
LmRTWU0gYS5leGUgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGIub3V0CithY19jbGVhbl9maWxlcz0k
YWNfY2xlYW5fZmlsZXNfc2F2ZQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMuLi4gIiA+JjY7IH0KK2lmIHsgeyBh
Y190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpc
XCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citl
c2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRh
Y190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIk
YWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMg
PSAwOyB9OyB0aGVuIDoKKyAgIyBJZiBib3RoIGBjb25mdGVzdC5leGUnIGFuZCBgY29uZnRlc3Qn
IGFyZSBgcHJlc2VudCcgKHdlbGwsIG9ic2VydmFibGUpCisjIGNhdGNoIGBjb25mdGVzdC5leGUn
LiAgRm9yIGluc3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3QnIHdpbGwKKyMgd29yayBw
cm9wZXJseSAoaS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScpLCB3aGlsZSBpdCB3b24ndCB3
aXRoCisjIGBybScuCitmb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUgY29uZnRlc3QgY29uZnRl
c3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2Zp
bGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICou
eFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9i
aiApIDs7CisgICAgKi4qICkgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpc
KFwuLipcKSdgCisJICBicmVhazs7CisgICAgKiApIGJyZWFrOzsKKyAgZXNhYworZG9uZQorZWxz
ZQorICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGlu
IFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2Qn
OiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0
YWJsZXM6IGNhbm5vdCBjb21waWxlIGFuZCBsaW5rCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9y
ZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorZmkKK3JtIC1mIGNvbmZ0ZXN0IGNvbmZ0ZXN0JGFj
X2N2X2V4ZWV4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9leGVleHQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9leGVleHQiID4mNjsgfQor
CitybSAtZiBjb25mdGVzdC4kYWNfZXh0CitFWEVFWFQ9JGFjX2N2X2V4ZWV4dAorYWNfZXhlZXh0
PSRFWEVFWFQKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgpCit7
CitGSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5vdXQiLCAidyIpOworIHJldHVybiBmZXJyb3Ig
KGYpIHx8IGZjbG9zZSAoZikgIT0gMDsKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCith
Y19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGNvbmZ0ZXN0Lm91dCIKKyMgQ2hlY2sgdGhh
dCB0aGUgY29tcGlsZXIgcHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwg
ZWl0aGVyCisjIHRoZSBjb21waWxlciBpcyBicm9rZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIg
d2UgYXJlIGNyb3NzIGNvbXBpbGluZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVy
IHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiRjcm9zc19jb21w
aWxpbmciICE9IHllczsgdGhlbgorICB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2UgIigoJGFj
X3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cisg
ICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNf
dHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0YXR1cz0k
PworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorICBpZiB7IGFjX3RyeT0nLi9jb25m
dGVzdCRhY19jdl9leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAq
XGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNf
dHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAg
KGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfTsgfTsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGluZz1ubworICBlbHNlCisg
ICAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSBtYXliZTsgdGhlbgorCWNyb3NzX2NvbXBp
bGluZz15ZXMKKyAgICBlbHNlCisJeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJv
cjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biBDIGNv
bXBpbGVkIHByb2dyYW1zLgorSWYgeW91IG1lYW50IHRvIGNyb3NzIGNvbXBpbGUsIHVzZSBcYC0t
aG9zdCcuCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsg
fQorICAgIGZpCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRjcm9zc19jb21waWxpbmciID4mNQorJGFzX2VjaG8gIiRjcm9zc19jb21w
aWxpbmciID4mNjsgfQorCitybSAtZiBjb25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4
ZWV4dCBjb25mdGVzdC5vdXQKK2FjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZm
aXggb2Ygb2JqZWN0IGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXgg
b2Ygb2JqZWN0IGZpbGVzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X29iamV4dCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorcm0gLWYg
Y29uZnRlc3QubyBjb25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgorY2Fz
ZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNf
dHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hv
PSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2Vj
aG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUKKyAg
YWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwk
PyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAg
Zm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8KKyAg
dGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRhY19maWxlIGluCisgICAg
Ki4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJi
IHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAgICAqKSBhY19jdl9vYmpl
eHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAgICBicmVhazs7CisgIGVz
YWMKK2RvbmUKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIg
PiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKK3sgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJy
b3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBjb21w
aWxlCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQor
ZmkKK3JtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb2Jq
ZXh0IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KK09CSkVYVD0kYWNfY3Zf
b2JqZXh0CithY19vYmpleHQ9JE9CSkVYVAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGls
ZXIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdO
VSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfY29tcGlsZXJfZ251Kzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCitpbnQKK21haW4gKCkKK3sKKyNpZm5kZWYgX19HTlVDX18KKyAgICAgICBjaG9rZSBt
ZQorI2VuZGlmCisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlf
Y29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jb21waWxlcl9nbnU9eWVzCitlbHNlCisg
IGFjX2NvbXBpbGVyX2dudT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorYWNfY3ZfY19jb21waWxlcl9nbnU9JGFjX2Nv
bXBpbGVyX2dudQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Nf
Y29tcGlsZXJfZ251IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhl
bgorICBHQ0M9eWVzCitlbHNlCisgIEdDQz0KK2ZpCithY190ZXN0X0NGTEFHUz0ke0NGTEFHUytz
ZXR9CithY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWciID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZy4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX2NjX2crOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9JGFjX2Nfd2Vycm9yX2ZsYWcKKyAg
IGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCisgICBhY19jdl9wcm9nX2NjX2c9bm8KKyAgIENGTEFHUz0i
LWciCisgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl
bmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19nPXllcworZWxzZQorICBDRkxBR1M9IiIKKyAgICAgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2Nfd2Vycm9y
X2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZworCSBDRkxBR1M9Ii1nIgorCSBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19nPXll
cworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl
c3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgYWNfY193ZXJyb3JfZmxhZz0kYWNfc2F2
ZV9jX3dlcnJvcl9mbGFnCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQorJGFzX2VjaG8gIiRhY19jdl9wcm9n
X2NjX2ciID4mNjsgfQoraWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9IHNldDsgdGhlbgorICBD
RkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCitlbGlmIHRlc3QgJGFjX2N2X3Byb2dfY2NfZyA9IHllczsg
dGhlbgorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENGTEFHUz0iLWcgLU8yIgor
ICBlbHNlCisgICAgQ0ZMQUdTPSItZyIKKyAgZmkKK2Vsc2UKKyAgaWYgdGVzdCAiJEdDQyIgPSB5
ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1PMiIKKyAgZWxzZQorICAgIENGTEFHUz0KKyAgZmkKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
Q0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X3By
b2dfY2NfYzg5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgYWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3NhdmVfQ0M9JENDCitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzeXMv
dHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyogTW9zdCBvZiB0aGUgZm9sbG93aW5n
IHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYuc2guICAqLworc3RydWN0
IGJ1ZiB7IGludCB4OyB9OworRklMRSAqICgqcmNzb3BlbikgKHN0cnVjdCBidWYgKiwgc3RydWN0
IHN0YXQgKiwgaW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBpKQorICAgICBjaGFyICoqcDsKKyAg
ICAgaW50IGk7Cit7CisgIHJldHVybiBwW2ldOworfQorc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAo
KmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQoreworICBjaGFyICpzOworICB2YV9s
aXN0IHY7CisgIHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAocCwgdmFfYXJnICh2LGludCkpOwor
ICB2YV9lbmQgKHYpOworICByZXR1cm4gczsKK30KKworLyogT1NGIDQuMCBDb21wYXEgY2MgaXMg
c29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMKKyAgIGZ1bmN0aW9u
IHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hhcmFjdGVyIGNvbnN0
YW50cy4KKyAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5mb3J0dW5hdGVseSwgaW5z
dGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gnLiAgVGhlIGZvbGxvd2luZyBpbmR1
Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAorICAgcHJvcGVyIEFOU0kg
bW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMgb3V0IHRydWUsIGZvciBh
bgorICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5IHRvIHdyaXRlICdceDAw
Jz09MCB0byBnZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICov
CitpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFdOworCisvKiBJQk0gQyA2
IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3Jv
IHBhcmFtZXRlcnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0ZXIgY29uc3RhbnRzLiAg
Ki8KKyNkZWZpbmUgRk9PKHgpICd4JworaW50IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/
IDEgOiAtMV07CisKK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOworc3RydWN0IHMxIHtpbnQg
KCpmKSAoaW50IGEpO307CitzdHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUgYSk7fTsKK2ludCBw
YWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0
YXQgKiwgaW50KSwgaW50LCBpbnQpOworaW50IGFyZ2M7CitjaGFyICoqYXJndjsKK2ludAorbWFp
biAoKQoreworcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2
LCAxKSAhPSBhcmd2WzFdOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitmb3IgYWNfYXJn
IGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBcCisJLUFlICItQWEg
LURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKK2RvCisgIENDPSIkYWNfc2F2
ZV9DQyAkYWNfYXJnIgorICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19hcmcKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0CisgIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4
bm8iICYmIGJyZWFrCitkb25lCitybSAtZiBjb25mdGVzdC4kYWNfZXh0CitDQz0kYWNfc2F2ZV9D
QworCitmaQorIyBBQ19DQUNIRV9WQUwKK2Nhc2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCisg
IHgpCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vbmUgbmVlZGVkIiA+JjUKKyRhc19lY2hvICJub25lIG5lZWRlZCIgPiY2OyB9IDs7CisgIHhu
bykKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
dW5zdXBwb3J0ZWQiID4mNQorJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKKyAgKikK
KyAgICBDQz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKKyRh
c19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7OworZXNhYworaWYgdGVzdCAieCRh
Y19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0aGVuIDoKKworZmkKKworYWNfZXh0PWMKK2FjX2Nw
cD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1Mg
Y29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0
ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1Jwor
YWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKK2FjX2V4dD1jCithY19j
cHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdT
IGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScK
K2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9j
ZXNzb3IiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9j
ZXNzb3IuLi4gIiA+JjY7IH0KKyMgT24gU3Vucywgc29tZXRpbWVzICRDUFAgbmFtZXMgYSBkaXJl
Y3RvcnkuCitpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIkQ1BQIjsgdGhlbgorICBDUFA9
CitmaQoraWYgdGVzdCAteiAiJENQUCI7IHRoZW4KKyAgaWYgJHthY19jdl9wcm9nX0NQUCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAj
IERvdWJsZSBxdW90ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhwYW5kZWQKKyAgICBmb3Ig
Q1BQIGluICIkQ0MgLUUiICIkQ0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIgIi9saWIvY3BwIgorICAg
IGRvCisgICAgICBhY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxh
ZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdj
Yywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIg
d29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBp
cyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5k
aW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJv
dWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5
bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
ZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFz
c2VydC5oPgorI2VuZGlmCisJCSAgICAgU3ludGF4IGVycm9yCitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgICMgQnJva2VuOiBmYWlscyBvbiB2
YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitmaQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0Lmkg
Y29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hl
Y2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2FuIGJlIGRldGVjdGVkIGFuZCBo
b3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlzdGVudC5oPgorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAgIyBCcm9rZW46IHN1Y2Nlc3Mg
b24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMgUGFzc2VzIGJvdGggdGVzdHMu
CithY19wcmVwcm9jX29rPToKK2JyZWFrCitmaQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuJGFjX2V4dAorCitkb25lCisjIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BS
RVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KK3JtIC1mIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKK2lmICRhY19wcmVwcm9jX29rOyB0aGVu
IDoKKyAgYnJlYWsKK2ZpCisKKyAgICBkb25lCisgICAgYWNfY3ZfcHJvZ19DUFA9JENQUAorCitm
aQorICBDUFA9JGFjX2N2X3Byb2dfQ1BQCitlbHNlCisgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENQUCIg
PiY1CiskYXNfZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNf
Y19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUg
dGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJl
c2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2Vy
dC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3Rz
IGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUg
cnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVz
dCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2Uu
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNl
bHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlmCisJCSAgICAgU3ludGF4IGVycm9yCitf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgICMg
QnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitmaQorcm0gLWYgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNh
bmUgY2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2Fu
IGJlIGRldGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlz
dGVudC5oPgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
IyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMg
UGFzc2VzIGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFrCitmaQorcm0gLWYgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCitkb25lCisjIEJlY2F1c2Ug
b2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBl
ZC4KK3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKK2lmICRh
Y19wcmVwcm9jX29rOyB0aGVuIDoKKworZWxzZQorICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIk
YXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJDIHBy
ZXByb2Nlc3NvciBcIiRDUFBcIiBmYWlscyBzYW5pdHkgY2hlY2sKK1NlZSBcYGNvbmZpZy5sb2cn
IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9CitmaQorCithY19leHQ9YworYWNfY3Bw
PSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBj
b25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQg
JENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCith
Y19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMg
bG9uZyBsaW5lcyBhbmQgLWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdyZXAgdGhh
dCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhf
R1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgorICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UK
KyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBS
T0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9y
IGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
cHJvZyBpbiBncmVwIGdncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9HUkVQPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9HUkVQIiAmJiAkYXNf
dGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFj
X3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZvciBH
TlUgJGFjX3BhdGhfR1JFUAorY2FzZSBgIiRhY19wYXRoX0dSRVAiIC0tdmVyc2lvbiAyPiYxYCBp
bgorKkdOVSopCisgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQ
X2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJj
b25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25m
dGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0
LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgorICAgICRhc19lY2hvICdH
UkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX0dSRVAiIC1lICdHUkVQJCcgLWUg
Jy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2
L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9k
ZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBh
Y19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9HUkVQ
X21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAg
bG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRo
X0dSRVAiCisgICAgICBhY19wYXRoX0dSRVBfbWF4PSRhY19jb3VudAorICAgIGZpCisgICAgIyAx
MCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRlc3Qg
JGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNv
bmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNhYworCisgICAgICAkYWNf
cGF0aF9HUkVQX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZT
PSRhc19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9HUkVQIjsgdGhlbgorICAg
IGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBB
VEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQorZWxzZQor
ICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKKwor
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBl
Z3JlcCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcGF0aF9FR1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGlmIGVjaG8gYSB8ICRHUkVQIC1FICcoYXxiKScgPi9kZXYvbnVs
bCAyPiYxCisgICB0aGVuIGFjX2N2X3BhdGhfRUdSRVA9IiRHUkVQIC1FIgorICAgZWxzZQorICAg
ICBpZiB0ZXN0IC16ICIkRUdSRVAiOyB0aGVuCisgIGFjX3BhdGhfRUdSRVBfZm91bmQ9ZmFsc2UK
KyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBS
T0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9y
IGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
cHJvZyBpbiBlZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfRUdSRVA9IiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiCisgICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0VHUkVQIiAmJiAkYXNfdGVz
dF94ICIkYWNfcGF0aF9FR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdOVSBhY19w
YXRoX0VHUkVQIGFuZCBzZWxlY3QgaXQgaWYgaXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdO
VSAkYWNfcGF0aF9FR1JFUAorY2FzZSBgIiRhY19wYXRoX0VHUkVQIiAtLXZlcnNpb24gMj4mMWAg
aW4KKypHTlUqKQorICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIgYWNfcGF0aF9F
R1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5
ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAi
Y29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25m
dGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNo
byAnRUdSRVAnID4+ICJjb25mdGVzdC5ubCIKKyAgICAiJGFjX3BhdGhfRUdSRVAiICdFR1JFUCQn
IDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAg
ICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJy
ZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisg
ICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9FR1JFUF9tYXgtMH07IHRoZW4KKyAg
ICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0
dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiCisgICAgICBh
Y19wYXRoX0VHUkVQX21heD0kYWNfY291bnQKKyAgICBmaQorICAgICMgMTAqKDJeMTApIGNoYXJz
IGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0ZXN0ICRhY19jb3VudCAtZ3Qg
MTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5pbiBjb25mdGVzdC50bXAgY29u
ZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAgJGFjX3BhdGhfRUdSRVBfZm91
bmQgJiYgYnJlYWsgMworICAgIGRvbmUKKyAgZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisgIGlmIHRlc3QgLXogIiRhY19jdl9wYXRoX0VHUkVQIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9y
ICQ/ICJubyBhY2NlcHRhYmxlIGVncmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQ
QVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKK2Vsc2UKKyAgYWNfY3ZfcGF0
aF9FR1JFUD0kRUdSRVAKK2ZpCisKKyAgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0VHUkVQIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfcGF0aF9FR1JFUCIgPiY2OyB9CisgRUdSRVA9IiRhY19jdl9wYXRoX0VHUkVQIgor
CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IEFOU0kgQyBoZWFkZXIgZmlsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEFOU0kg
QyBoZWFkZXIgZmlsZXMuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVhZGVyX3N0ZGMrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8
c3RyaW5nLmg+CisjaW5jbHVkZSA8ZmxvYXQuaD4KKworaW50CittYWluICgpCit7CisKKyAgOwor
ICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3RkYz15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0
ZGM9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4K
KyAgIyBTdW5PUyA0Lnggc3RyaW5nLmggZG9lcyBub3QgZGVjbGFyZSBtZW0qLCBjb250cmFyeSB0
byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RyaW5nLmg+CisKK19BQ0VPRgoraWYg
KGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAorICAkRUdSRVAgIm1lbWNo
ciIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1u
bworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3Rk
YyA9IHllczsgdGhlbgorICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2VzIG5vdCBkZWNsYXJlIGZy
ZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRsaWIuaD4K
KworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Cisg
ICRFR1JFUCAiZnJlZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKworZWxzZQorICBhY19jdl9o
ZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQorCitpZiB0ZXN0ICRhY19j
dl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4vY2MgaW4gSXJpeC00LjAuNSBnZXRz
IG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2kuCisgIGlmIHRlc3QgIiRj
cm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgorZWxzZQorICBjYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisj
aW5jbHVkZSA8Y3R5cGUuaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpZiAoKCcgJyAmIDB4MEZG
KSA9PSAweDAyMCkKKyMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6
JykKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAnQScgKyAoKGMpIC0gJ2EnKSA6
IChjKSkKKyNlbHNlCisjIGRlZmluZSBJU0xPV0VSKGMpIFwKKwkJICAgKCgnYScgPD0gKGMpICYm
IChjKSA8PSAnaScpIFwKKwkJICAgICB8fCAoJ2onIDw9IChjKSAmJiAoYykgPD0gJ3InKSBcCisJ
CSAgICAgfHwgKCdzJyA8PSAoYykgJiYgKGMpIDw9ICd6JykpCisjIGRlZmluZSBUT1VQUEVSKGMp
IChJU0xPV0VSKGMpID8gKChjKSB8IDB4NDApIDogKGMpKQorI2VuZGlmCisKKyNkZWZpbmUgWE9S
KGUsIGYpICgoKGUpICYmICEoZikpIHx8ICghKGUpICYmIChmKSkpCitpbnQKK21haW4gKCkKK3sK
KyAgaW50IGk7CisgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKKyAgICBpZiAoWE9SIChpc2xv
d2VyIChpKSwgSVNMT1dFUiAoaSkpCisJfHwgdG91cHBlciAoaSkgIT0gVE9VUFBFUiAoaSkpCisg
ICAgICByZXR1cm4gMjsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitmaQor
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorZmkKKworZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7
IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAor
CitmaQorCisjIE9uIElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5cGVzLmggYXJlIGNvbmZs
aWN0aW5nLgorZm9yIGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5o
IHN0cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBcCisJCSAgaW50dHlwZXMuaCBzdGRpbnQuaCB1
bmlzdGQuaAorZG8gOgorICBhc19hY19IZWFkZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFj
X2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxlICIkTElO
RU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdAor
IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgor
ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNf
aGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKKworCisgIGFj
X2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJtaW5peC9jb25maWcuaCIgImFj
X2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giID0geHllczsgdGhlbiA6CisgIE1JTklY
PXllcworZWxzZQorICBNSU5JWD0KK2ZpCisKKworICBpZiB0ZXN0ICIkTUlOSVgiID0geWVzOyB0
aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisK
KworJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+Y29uZmRlZnMuaAorCisK
KyRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZkZWZzLmgKKworICBmaQorCisKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVy
IGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkZWZpbmUgX19FWFRFTlNJT05TX18uLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18rOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKyMJICBkZWZpbmUgX19FWFRFTlNJT05TX18gMQorCSAgJGFjX2luY2x1ZGVzX2RlZmF1bHQK
K2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfc2FmZV90b19kZWZpbmVf
X19leHRlbnNpb25zX189eWVzCitlbHNlCisgIGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5z
aW9uc19fPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fIiA+JjY7IH0K
KyAgdGVzdCAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18gPSB5ZXMgJiYKKyAg
ICAkYXNfZWNobyAiI2RlZmluZSBfX0VYVEVOU0lPTlNfXyAxIiA+PmNvbmZkZWZzLmgKKworICAk
YXNfZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKKworICAkYXNfZWNo
byAiI2RlZmluZSBfR05VX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKKworICAkYXNfZWNobyAiI2Rl
ZmluZSBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFzX2Vj
aG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKworIyBNYWtlIHN1
cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgorJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuc3Vi
IiBzdW40ID4vZGV2L251bGwgMj4mMSB8fAorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biAk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgIiRMSU5FTk8iIDUKKworeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZSIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZS4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9idWlsZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGFjX2J1aWxkX2FsaWFzPSRidWlsZF9hbGlhcwordGVzdCAieCRhY19i
dWlsZF9hbGlhcyIgPSB4ICYmCisgIGFjX2J1aWxkX2FsaWFzPWAkU0hFTEwgIiRhY19hdXhfZGly
L2NvbmZpZy5ndWVzcyJgCit0ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9IHggJiYKKyAgYXNfZm5f
ZXJyb3IgJD8gImNhbm5vdCBndWVzcyBidWlsZCB0eXBlOyB5b3UgbXVzdCBzcGVjaWZ5IG9uZSIg
IiRMSU5FTk8iIDUKK2FjX2N2X2J1aWxkPWAkU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIi
ICRhY19idWlsZF9hbGlhc2AgfHwKKyAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rp
ci9jb25maWcuc3ViICRhY19idWlsZF9hbGlhcyBmYWlsZWQiICIkTElORU5PIiA1CisKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2J1
aWxkIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfYnVpbGQiID4mNjsgfQorY2FzZSAkYWNfY3ZfYnVp
bGQgaW4KKyotKi0qKSA7OworKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fu
b25pY2FsIGJ1aWxkIiAiJExJTkVOTyIgNTs7Citlc2FjCitidWlsZD0kYWNfY3ZfYnVpbGQKK2Fj
X3NhdmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4ICRhY19jdl9idWlsZAorc2hpZnQKK2J1aWxk
X2NwdT0kMQorYnVpbGRfdmVuZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBm
aXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAorIyBleGNlcHQgd2l0
aCBvbGQgc2hlbGxzOgorYnVpbGRfb3M9JCoKK0lGUz0kYWNfc2F2ZV9JRlMKK2Nhc2UgJGJ1aWxk
X29zIGluICpcICopIGJ1aWxkX29zPWBlY2hvICIkYnVpbGRfb3MiIHwgc2VkICdzLyAvLS9nJ2A7
OyBlc2FjCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBob3N0IHN5c3RlbSB0eXBlIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvc3Qgc3lz
dGVtIHR5cGUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaG9zdCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIngkaG9zdF9hbGlh
cyIgPSB4OyB0aGVuCisgIGFjX2N2X2hvc3Q9JGFjX2N2X2J1aWxkCitlbHNlCisgIGFjX2N2X2hv
c3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhvc3RfYWxpYXNgIHx8CisgICAg
YXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViICRob3N0X2FsaWFz
IGZhaWxlZCIgIiRMSU5FTk8iIDUKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hvc3QiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9ob3N0IiA+JjY7IH0KK2Nhc2UgJGFjX2N2X2hvc3QgaW4KKyotKi0qKSA7OworKikgYXNfZm5f
ZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGhvc3QiICIkTElORU5PIiA1OzsK
K2VzYWMKK2hvc3Q9JGFjX2N2X2hvc3QKK2FjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4
ICRhY19jdl9ob3N0CitzaGlmdAoraG9zdF9jcHU9JDEKK2hvc3RfdmVuZG9yPSQyCitzaGlmdDsg
c2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8g
Y3JlYXRlICQqLAorIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgoraG9zdF9vcz0kKgorSUZTPSRh
Y19zYXZlX0lGUworY2FzZSAkaG9zdF9vcyBpbiAqXCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9v
cyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKworCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKKwor
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisK
KworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhzbSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV94c20rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV94c207
CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieHllcyI7IHRoZW4gOgorCisgICAg
YXhfY3ZfeHNtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieG5vIjsgdGhlbiA6
CisKKyAgICBheF9jdl94c209Im4iCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfeHNtOyB0aGVuIDoK
KworICAgIGF4X2N2X3hzbT0ibiIKKworZmkKK3hzbT0kYXhfY3ZfeHNtCisKKyMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2dpdGh0
dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9naXRodHRwOworZmkK
KworCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBh
eF9jdl9naXRodHRwPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0gInhubyI7
IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9n
aXRodHRwOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9Im4iCisKK2ZpCitnaXRodHRwPSRh
eF9jdl9naXRodHRwCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVu
YWJsZXZhbD0kZW5hYmxlX21vbml0b3JzOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9tb25p
dG9ycyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ibiIKKworZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbW9u
aXRvcnM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4gOgorCisgICAg
YXhfY3ZfbW9uaXRvcnM9InkiCisKK2ZpCittb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKKworIyBD
aGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVf
dnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07CitmaQor
CisKK2lmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2
X3Z0cG09InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieG5vIjsgdGhlbiA6CisK
KyAgICBheF9jdl92dHBtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgor
CisgICAgYXhfY3ZfdnRwbT0ibiIKKworZmkKK3Z0cG09JGF4X2N2X3Z0cG0KKworIyBDaGVjayB3
aGV0aGVyIC0tZW5hYmxlLXhhcGkgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfeGFwaStz
ZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hhcGk7CitmaQorCisKK2lm
IHRlc3QgIngkZW5hYmxlX3hhcGkiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X3hhcGk9
InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBh
eF9jdl94YXBpPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hhcGk7IHRoZW4gOgorCisgICAg
YXhfY3ZfeGFwaT0ibiIKKworZmkKK3hhcGk9JGF4X2N2X3hhcGkKKworIyBDaGVjayB3aGV0aGVy
IC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3B5dGhv
bnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcHl0aG9udG9v
bHM7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVu
IDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3B5
dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9weXRob250b29scz0ieSIK
KworZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250b29sczsgdGhlbiA6CisKKyAgICBheF9jdl9w
eXRob250b29scz0ieSIKKworZmkKK3B5dGhvbnRvb2xzPSRheF9jdl9weXRob250b29scworCisj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfb2NhbWx0b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngk
ZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9v
bHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6CisKKyAgICBh
eF9jdl9vY2FtbHRvb2xzPSJ5IgorCitmaQorb2NhbWx0b29scz0kYXhfY3Zfb2NhbWx0b29scwor
CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgoraWYgdGVzdCAi
JHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJs
ZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMi
OyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxl
X21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJuIgorCitl
bGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJt
PSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKyMgQ2hlY2sgd2hldGhlciAt
LWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OworZmkKKworCitp
ZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9s
b21vdW50PSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInhubyI7IHRoZW4g
OgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9sb21vdW50
OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9Im4iCisKK2ZpCitsb21vdW50PSRheF9jdl9s
b21vdW50CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9kZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX2RlYnVnOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhl
biA6CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIg
PSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAk
YXhfY3ZfZGVidWc7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2ZpCitkZWJ1Zz0k
YXhfY3ZfZGVidWcKKworCisKKworCisKKworZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVT
CitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2Rv
bmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1Mr
PSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQ
UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdT
ICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZM
QUdTICRBUFBFTkRfTERGTEFHUyIKKworCisKKworCisKKworCisKKworCisKKyMgQ2hlY2tzIGZv
ciBwcm9ncmFtcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0cHV0IiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1NFRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAgICAgICBhY19zY3JpcHQ9cy9hYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi
YmJiYmJiYmIvCisgICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7IGRvCisgICAgICAgYWNf
c2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKKyAgICAgZG9uZQorICAgICBlY2hv
ICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0ZXN0LnNlZAorICAgICB7
IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9CisgICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0
aGVuCisgIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2Vy
J3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfU0VEPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9TRUQiICYmICRhc190
ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdOVSBhY19w
YXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUg
JGFjX3BhdGhfU0VECitjYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNpb24gMj4mMWAgaW4KKypH
TlUqKQorICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19wYXRoX1NFRF9mb3VuZD06
OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3Qu
aW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4i
ID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKKyAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNobyAnJyA+PiAiY29u
ZnRlc3QubmwiCisgICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Quc2VkIDwgImNvbmZ0ZXN0
Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25m
dGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAk
YWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCisgICAgICAjIEJlc3Qgb25l
IHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUKKyAgICAg
IGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCisgICAgICBhY19wYXRoX1NFRF9tYXg9JGFj
X2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3Jl
IHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCisgIGRvbmUK
KyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91
dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9u
ZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2
X3BhdGhfU0VEIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIHNlZCBj
b3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2
X3BhdGhfU0VEPSRTRUQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
cGF0aF9TRUQiID4mNjsgfQorIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgorICBybSAtZiBjb25mdGVz
dC5zZWQKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSck
Q0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSck
Q0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0
ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVy
X2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNf
d29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFj
X2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNl
Cithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRh
c19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisK
KworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MK
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7
Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNlCisgIENDPSIkYWNfY3ZfcHJvZ19D
QyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgICAgICAgICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9v
bF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3By
b2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgZmkKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGNjOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKKyAg
YWNfcHJvZ19yZWplY3RlZD1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAi
L3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAgICAgICBj
b250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91
bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAg
c2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhl
bgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25l
LgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24g
d2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNl
bmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2df
Q0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQorZmkKK2ZpCitmaQorQ0M9JGFj
X2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
Zm9yIGFjX3Byb2cgaW4gY2wuZXhlCisgIGRvCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9w
cm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19DQz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNf
ZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
KyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitpZiB0ZXN0IC16ICIkQ0Mi
OyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKK2RvCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRlc3QgLW4gIiRhY19jdF9D
QyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAg
ICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0ZXN0IC16ICIkQ0MiICYm
IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9
CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVy
IHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNf
b3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRh
Y19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8
ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRh
Y190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQor
ICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAg
YWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcx
MGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEn
IGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAg
ZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19jb21waWxlcl9nbnUrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKK2ludAorbWFpbiAoKQoreworI2lmbmRlZiBfX0dOVUNfXworICAgICAgIGNob2tlIG1lCisj
ZW5kaWYKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2NvbXBpbGVyX2dudT15ZXMKK2Vsc2UKKyAgYWNf
Y29tcGlsZXJfZ251PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGls
ZXJfZ251CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19jb21w
aWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCisg
IEdDQz15ZXMKK2Vsc2UKKyAgR0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0K
K2FjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3Byb2dfY2NfZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNf
Y193ZXJyb3JfZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIK
KyAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9wcm9nX2NjX2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitp
bnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9j
X3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY193ZXJyb3JfZmxh
Zz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
aW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nf
d2Vycm9yX2ZsYWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2Nf
ZyIgPiY2OyB9CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCisgIENGTEFH
Uz0kYWNfc2F2ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVu
CisgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItZyAtTzIiCisgIGVs
c2UKKyAgICBDRkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsg
dGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPQorICBmaQorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBv
cHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19j
Y19jODkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
bmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBl
cy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVz
dHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVm
IHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3Rh
dCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBp
bnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykg
KGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3Qg
djsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZh
X2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21l
IHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJv
dG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRz
LgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFk
IGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMg
YW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2Rl
LiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisg
ICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0w
IHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2lu
dCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisKKy8qIElCTSBDIDYgZm9y
IEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFy
YW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwor
I2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6
IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYp
IChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJu
YW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAq
LCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2OworaW50CittYWluICgp
Cit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4g
JycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9I
UFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAgQ0M9IiRhY19zYXZlX0ND
ICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIg
JiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0NDPSRhY19zYXZlX0NDCisK
K2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KKyAgeCkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9u
ZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKKyAgeG5vKQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1
cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OworICAqKQorICAg
IENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitpZiB0ZXN0ICJ4JGFjX2N2
X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9CitMTl9T
PSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8g
InllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2VjaG8gIm5vLCB1c2luZyAk
TE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAi
ID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2Vk
ICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgXCR7YWNfY3ZfcHJvZ19t
YWtlXyR7YWNfbWFrZX1fc2V0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAv
YmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUlJScKK19BQ0VPRgorIyBH
TlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3
b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4v
ZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUlKikKKyAgICBldmFsIGFjX2N2X3Byb2df
bWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQorICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtl
XyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1mIGNvbmZ0ZXN0Lm1ha2UKK2ZpCitpZiBl
dmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1
CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CitlbHNlCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAi
bm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCitmaQorCisjIEZpbmQg
YSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJvZ3JhbSAoZmFzdGVyKSwK
KyMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBCdXQgYXZvaWQgdGhlIGJy
b2tlbiBvcgorIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6CisjIFN5c1YgL2V0Yy9pbnN0YWxsLCAv
dXNyL3NiaW4vaW5zdGFsbAorIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxsCisjIElSSVggL3NiaW4v
aW5zdGFsbAorIyBBSVggL2Jpbi9pbnN0YWxsCisjIEFtaWdhT1MgL0MvaW5zdGFsbCwgd2hpY2gg
aW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKKyMgQUlYIDQgL3Vzci9iaW4vaW5z
dGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBmbGFnCisjIEFGUyAvdXNy
L2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4aXN0ZW50IGFyZ3MKKyMg
U1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2UgdGhlIG5vbmV4aXN0ZW50
IGdyb3VwICJzdGFmZiIKKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21w
bGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYworIyAuL2luc3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJv
bmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2guCisjIFJlamVjdCBpbnN0
YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUgZmlsZXMuCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21w
YXRpYmxlIGluc3RhbGwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGEgQlNELWNvbXBh
dGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQoraWYgdGVzdCAteiAiJElOU1RBTEwiOyB0aGVuCitp
ZiAke2FjX2N2X3BhdGhfaW5zdGFsbCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0
IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KK2Nhc2UgJGFzX2Rpci8gaW4gIygo
CisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNy
L2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCisgID86W1xcL11vczJbXFwv
XWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11JTlNUQUxMW1xcL10qIHwgXAorICAvdXNy
L3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIg
b3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9uJ3QgdXNlIGluc3RhbGxic2QgZnJvbSBP
U0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9vdAorICAgICMgYnkgZGVmYXVsdC4KKyAg
ICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0IGluc3RhbGw7IGRvCisgICAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKwlpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVuCisJICBpZiB0ZXN0ICRhY19wcm9nID0g
aW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4
dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4g
aW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KKwkgICAgOgorCSAgZWxpZiB0ZXN0ICRh
Y19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgcHJvZ3JhbS1zcGVjaWZp
YyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgorCSAgICA6CisJ
ICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRp
cgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQorCSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0
LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkgICAgaWYgIiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0
LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0
LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAmJgorCSAg
ICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0LnR3bworCSAgICB0aGVuCisJICAgICAg
YWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgorCSAg
ICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkKKyAgICAgIGRvbmUKKyAgICBkb25lCisg
ICAgOzsKK2VzYWMKKworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK3JtIC1yZiBjb25mdGVz
dC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCitmaQorICBpZiB0ZXN0ICIke2FjX2N2
X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgorICAgIElOU1RBTEw9JGFjX2N2X3BhdGhf
aW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hl
bGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMgdmFsdWUgZm9yIElOU1RBTEwgd2l0aGlu
IGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKKyAgICAjIGJyZWFrIG90aGVy
IHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0IGRpcmVjdG9yeSBpcworICAgICMgcmVt
b3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUgbmFtZS4KKyAgICBJTlNUQUxMPSRh
Y19pbnN0YWxsX3NoCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIkSU5TVEFMTCIgPiY2OyB9
CisKKyMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFuZGxlcyBicmFjZXMgaW4g
JHt2YXItdmFsfS4KKyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBicmFjZSBlbmRzIHRoZSB2
YXJpYWJsZSBzdWJzdGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNU
QUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX1NDUklQVCIgJiYg
SU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX0RBVEEiICYm
IElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfUEVSTCs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFBF
UkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfUEVSTD0iJFBFUkwiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQor
ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitQRVJMPSRhY19jdl9wYXRoX1BFUkwKK2lmIHRlc3QgLW4g
IiRQRVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke1BFUkx9IiA9PSB4Im5vIgor
dGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBwZXJsLCBwbGVhc2UgaW5z
dGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
YnJjdGwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
IGJyY3RsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9CUkNUTCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJSQ1RMIGlu
CisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JSQ1RMPSIkQlJDVEwiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBh
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRI
CitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9w
YXRoX0JSQ1RMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JSQ1RMIiAmJiBhY19jdl9wYXRoX0JSQ1RM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCUkNUTD0kYWNfY3ZfcGF0aF9CUkNUTAoraWYgdGVzdCAt
biAiJEJSQ1RMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJEJSQ1RMIiA+JjUKKyRhc19lY2hvICIkQlJDVEwiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7QlJDVEx9IiA9PSB4
Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBicmN0bCwgcGxl
YXNlIGluc3RhbGwgYnJjdGwiICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJpcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgaXA7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0lQKzp9IGZhbHNlOyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkSVAgaW4KKyAg
W1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSVA9IiRJUCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfSVA9IiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfSVAiICYmIGFjX2N2X3BhdGhfSVA9Im5vIgorICA7OworZXNhYwor
ZmkKK0lQPSRhY19jdl9wYXRoX0lQCitpZiB0ZXN0IC1uICIkSVAiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSVAiID4mNQorJGFzX2Vj
aG8gIiRJUCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitp
ZiB0ZXN0IHgiJHtJUH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGlwLCBwbGVhc2UgaW5zdGFsbCBpcCIgIiRMSU5FTk8iIDUKK2ZpCisjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Bh
dGhfQklTT04rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0
aF9CSVNPTj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg
cGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CSVNP
TiIgJiYgYWNfY3ZfcGF0aF9CSVNPTj0ibm8iCisgIDs7Citlc2FjCitmaQorQklTT049JGFjX2N2
X3BhdGhfQklTT04KK2lmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1CiskYXNfZWNobyAi
JEJJU09OIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lm
IHRlc3QgeCIke0JJU09OfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5h
YmxlIHRvIGZpbmQgYmlzb24sIHBsZWFzZSBpbnN0YWxsIGJpc29uIiAiJExJTkVOTyIgNQorZmkK
KyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgZmxleDsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfRkxFWCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJEZMRVggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2
X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfRkxF
WCIgJiYgYWNfY3ZfcGF0aF9GTEVYPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitGTEVYPSRhY19jdl9w
YXRoX0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQorJGFzX2VjaG8gIiRGTEVY
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3Qg
eCIke0ZMRVh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8g
ZmluZCBmbGV4LCBwbGVhc2UgaW5zdGFsbCBmbGV4IiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3Qg
IngkeGFwaSIgPSAieHkiOyB0aGVuIDoKKworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9DVVJM
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9DVVJMPSIk
Q1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7
CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9w
YXRoX0NVUkw9Im5vIgorICA7OworZXNhYworZmkKK0NVUkw9JGFjX2N2X3BhdGhfQ1VSTAoraWYg
dGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENVUkwiID4mNjsgfQorZWxz
ZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7Q1VSTH0iID09
IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29u
ZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9wYXRoX1hNTCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhNTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitYTUw9JGFjX2N2
X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1CiskYXNfZWNobyAiJFhNTCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElORU5PIiA1Citm
aQorCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRoZW4gOgorCisgICAgICAj
IGNoZWNraW5nIGZvciBvY2FtbGMKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxj
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfT0NBTUxD
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiRPQ0FNTEMi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09D
QU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+
JjUKKyRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEMiOyB0aGVuCisg
IGFjX2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2Nh
bWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBv
Y2FtbGM7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQys6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSIkYWNf
Y3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxDPSJvY2FtbGMiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNf
Y3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEMiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTEMiID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMK
KyAgZmkKK2Vsc2UKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMiCitmaQorCisKKyAgaWYg
dGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZFUlNJT049YCRPQ0FNTEMg
LXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKKyAgICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZlcnNpb24g
aXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxW
RVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAorICAgICBp
ZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMg
LXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRg
CisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY1
CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7
IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQorJGFzX2VjaG8g
Ik9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQorCisKKworCisgICAgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJv
Z19PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FN
TE9QVD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKK2lmIHRlc3Qg
LW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1MT1BU
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN
TE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BU
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFQ9Im9jYW1sb3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09D
QU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4
JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0ibm8iCisgIGVsc2UKKyAg
ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxPUFQ9JGFj
X2N0X09DQU1MT1BUCisgIGZpCitlbHNlCisgIE9DQU1MT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9Q
VCIKK2ZpCisKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9
ICJubyI7IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdB
Uk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0
ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAk
T0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJ
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZl
cnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsgfQor
CSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZp
CisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgaWYgdGVzdCAtbiAi
JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0OyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9U
T1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0i
JHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRP
Q0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDRE9UT1BU
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MQ0RP
VE9QVD0kT0NBTUxDRE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxj
Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWxjLm9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9U
T1BUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5v
cHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NBTUxDRE9UT1BUPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RP
VE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTENE
T1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgorICAgIE9DQU1MQ0RPVE9QVD0i
bm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisg
ICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKKyAgZmkKK2Vsc2UKKyAgT0NBTUxD
RE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCitmaQorCisgICAgIGlmIHRlc3QgIiRP
Q0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12
IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRU
TVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9CisJZWxzZQor
CSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRo
ZW4KKwlpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE9Q
VERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQu
b3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MT1BURE9UT1BUPSRhY19j
dl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NB
TUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BURE9UT1BUPSRPQ0FN
TE9QVERPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Lm9wdCIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxv
cHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9Im9j
YW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE9Q
VERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPSB4OyB0aGVu
CisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xf
d2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERP
VE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQiCitmaQorCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJ
ICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1M
VkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0
IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgIGVsc2UKKwkgICAgICBPQ0FNTE9Q
VD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAgICBmaQorCisKKyAgZmkK
KworCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgaWYgdGVzdCAtbiAiJGFj
X3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MIjsgdGhl
bgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAt
biAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MPSIkYWNfY3Rf
T0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTD0ib2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NB
TUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KK2Vsc2UKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
KyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUwiID0g
eDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGlu
ZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dh
cm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwKKyAgZmkKK2Vsc2UKKyAg
T0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgorZmkKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
ZGVwCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9j
YW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERFUCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4g
IiRPQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxkZXAiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NB
TUxERVA9JGFjX2N2X3Byb2dfT0NBTUxERVAKK2lmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERFUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERF
UCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCisgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MREVQCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxE
RVAiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7
IHRoZW4KKyAgICBPQ0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxp
bmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93
YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCisgIGZpCitl
bHNlCisgIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKK2ZpCisKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0
b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2df
T0NBTUxNS1RPUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxN
S1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNo
byAiJE9DQU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2Zp
CisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCisgIGFj
X2N0X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJvY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE1LVE9QKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0X09DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9w
IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAg
ZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MTUtUT1A9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MTUtUT1AiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJubyIKKyAgZWxzZQorICAg
IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv
b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LVE9QPSRh
Y19jdF9PQ0FNTE1LVE9QCisgIGZpCitlbHNlCisgIE9DQU1MTUtUT1A9IiRhY19jdl9wcm9nX09D
QU1MTUtUT1AiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta2xpYgorICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWI7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MTUtMSUIrOn0gZmFsc2U7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxN
S0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVf
SUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitP
Q0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRPQ0FNTE1LTElC
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxta2xpYjsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQis6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9P
Q0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
KyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkK
K2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2Vj
aG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS0xJQiIgPSB4OyB0aGVuCisgICAg
T0NBTUxNS0xJQj0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rv
b2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVz
IDs7Citlc2FjCisgICAgT0NBTUxNS0xJQj0kYWNfY3RfT0NBTUxNS0xJQgorICBmaQorZWxzZQor
ICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIgorZmkKKworCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv
b2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERP
Qys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJE9D
QU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NB
TUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
K2ZpCitmaQorT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lmIHRlc3QgLW4gIiRPQ0FN
TERPQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRPQ0FNTERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxET0M9JE9DQU1MRE9DCisgICMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRo
ZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09DQU1MRE9DIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9j
YW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MRE9DPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERPQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09D
QU1MRE9DIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERPQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxET0M9JGFjX2N0X09DQU1M
RE9DCisgIGZpCitlbHNlCisgIE9DQU1MRE9DPSIkYWNfY3ZfcHJvZ19PQ0FNTERPQyIKK2ZpCisK
KworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X3Byb2dfT0NBTUxCVUlMRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgorICBh
Y19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1vY2Ft
bGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MQlVJTEQ9JGFjX2N2
X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIg
PiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQlVJTEQi
OyB0aGVuCisgIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKKyAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTEJVSUxEKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVu
CisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09DQU1MQlVJTEQiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxE
PSJvY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1M
QlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1M
QlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEJVSUxEPSJubyIK
KyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3ll
czopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBP
Q0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisgIE9DQU1MQlVJTEQ9IiRh
Y19jdl9wcm9nX09DQU1MQlVJTEQiCitmaQorCisKKyAgICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICAgICAgaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eHllcyI7IHRoZW4gOgorCisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMg
ZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVOTyIgNQorZmkKKyAgICAg
ICAgb2NhbWx0b29scz0ibiIKKworZmkKKworZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgYmFzaDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfQkFTSCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJBU0ggaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkFTSD0iJEJBU0giICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRo
X0JBU0g9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkFTSCIgJiYgYWNfY3ZfcGF0aF9CQVNIPSJubyIK
KyAgOzsKK2VzYWMKK2ZpCitCQVNIPSRhY19jdl9wYXRoX0JBU0gKK2lmIHRlc3QgLW4gIiRCQVNI
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJEJBU0giID4mNQorJGFzX2VjaG8gIiRCQVNIIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JBU0h9IiA9PSB4Im5vIgordGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBwbGVhc2UgaW5zdGFsbCBi
YXNoIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhl
biA6CisKKyAgICBpZiBlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CisKKyAg
ICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhP
TlBBVEhgCisKK2VsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgorICBQWVRIT049InB5dGhv
biIKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3Qg
YW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9QWVRI
T05QQVRIKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUFlUSE9OUEFUSD0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgor
ICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAoraWYgdGVz
dCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVz
dCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1
CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBv
cnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAoraWYgdGVz
dCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFg
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgICAgYXNfZm5fZXJyb3IgJD8gIiRweXRob25f
dmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgMi4zIiAiJExJ
TkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorICAgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB4
bWwuZG9tLm1pbmlkb20iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB4bWwu
ZG9tLm1pbmlkb20uLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5p
ZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1v
ZHVsZSIgIiRMSU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBweXRob24gZGV2ZWwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiBkZXZl
bC4uLiAiID4mNjsgfQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3MucGF0aCwgc3lzCitmb3Ig
cCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZp
bGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisnID4gL2Rldi9udWxsIDI+
JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiUHl0aG9uIGRldmVsIHBhY2thZ2Ugbm90IGZvdW5kIiAi
JExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorCitmaQor
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9wYXRoX1hHRVRURVhUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkWEdFVFRFWFQgaW4KKyAgW1xcL10qIHwgPzpb
XFwvXSopCisgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfWEdFVFRF
WFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9
Im5vIgorICA7OworZXNhYworZmkKK1hHRVRURVhUPSRhY19jdl9wYXRoX1hHRVRURVhUCitpZiB0
ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQorJGFzX2VjaG8gIiRYR0VUVEVYVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYR0VUVEVYVH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIgIiRMSU5FTk8iIDUKK2Zp
CitpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmFkbSIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgdWRldmFkbTsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3BhdGhfVURFVkFETSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJFVERVZBRE0gaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFj
X2N2X3BhdGhfVURFVkFETT0iJFVERVZBRE0iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZBRE09IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFj
X2N2X3BhdGhfVURFVkFETSIgJiYgYWNfY3ZfcGF0aF9VREVWQURNPSJubyIKKyAgOzsKK2VzYWMK
K2ZpCitVREVWQURNPSRhY19jdl9wYXRoX1VERVZBRE0KK2lmIHRlc3QgLW4gIiRVREVWQURNIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFVERVZBRE0iID4mNQorJGFzX2VjaG8gIiRVREVWQURNIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19l
Y2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJu
byIKKyAgICB0aGVuCisgICAgICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmlu
Zm8iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHVk
ZXZpbmZvOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9VREVWSU5GTys6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFVERVZJ
TkZPIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1VERVZJTkZPPSIkVURF
VklORk8iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7
OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNf
ZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
KyAgICBhY19jdl9wYXRoX1VERVZJTkZPPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1VERVZJTkZPIiAm
JiBhY19jdl9wYXRoX1VERVZJTkZPPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitVREVWSU5GTz0kYWNf
Y3ZfcGF0aF9VREVWSU5GTworaWYgdGVzdCAtbiAiJFVERVZJTkZPIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFVERVZJTkZPIiA+JjUK
KyRhc19lY2hvICIkVURFVklORk8iID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30iID09IHgibm8iCisgICAg
ICAgIHRoZW4KKyAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB1ZGV2
YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2IiAiJExJTkVOTyIgNQorICAgICAg
ICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0n
YAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAg
dGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImhvdHBsdWciLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGhvdHBsdWc7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0hPVFBMVUcrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRIT1RQTFVHIGluCisgIFtc
XC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0hPVFBMVUc9IiRIT1RQTFVHIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9IT1RQTFVHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0hPVFBMVUciICYmIGFjX2N2X3BhdGhfSE9U
UExVRz0ibm8iCisgIDs7Citlc2FjCitmaQorSE9UUExVRz0kYWNfY3ZfcGF0aF9IT1RQTFVHCitp
ZiB0ZXN0IC1uICIkSE9UUExVRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRIT1RQTFVHIiA+JjUKKyRhc19lY2hvICIkSE9UUExVRyIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgICAgIGlm
IHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBh
c19mbl9lcnJvciAkPyAidWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3Ig
bGF0ZXIiICIkTElORU5PIiA1CisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgInZuY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB2bmNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfVk5DT05GSUcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBjYXNlICRWTkNPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJFZOQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9WTkNPTkZJRyIgJiYgYWNfY3ZfcGF0aF9WTkNPTkZJRz0ibm8iCisg
IDs7Citlc2FjCitmaQorVk5DT05GSUc9JGFjX2N2X3BhdGhfVk5DT05GSUcKK2lmIHRlc3QgLW4g
IiRWTkNPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRWTkNPTkZJRyIgPiY1CiskYXNfZWNobyAiJFZOQ09ORklHIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtW
TkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBhc19mbl9lcnJvciAkPyAiTm90
IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmQiICIkTElORU5PIiA1CisgICAg
ZmkKK2ZpCisKK2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0aGVuCisgICAg
YWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1aWQvdXVpZC5oIiAiYWNf
Y3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4
JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorICBhc19m
bl9lcnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJTkVOTyIgNQorZmkKKwor
CitlbHNlCisgICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1aWQu
aCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3Qg
IngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorICBhc19mbl9l
cnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJTkVOTyIgNQorZmkKKworCitm
aQorCisKKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitpZiB0ZXN0IC1kICIkcHJlZml4L2xpYjY0Ijsg
dGhlbiA6CisKKyAgICBMSUJfUEFUSD0ibGliNjQiCisKK2Vsc2UKKworICAgIExJQl9QQVRIPSJs
aWIiCisKK2ZpCisKKworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9saWJfYWlvX2lvX3NldHVwKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UworTElCUz0iLWxhaW8gICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0ND
IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1
c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNp
ZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGlvX3NldHVwICgpOwor
aW50CittYWluICgpCit7CityZXR1cm4gaW9fc2V0dXAgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zf
bGliX2Fpb19pb19zZXR1cD15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD1ubwor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2
ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2Fp
b19pb19zZXR1cCIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0g
eHllczsgdGhlbiA6CisgIHN5c3RlbV9haW89InkiCitlbHNlCisgIHN5c3RlbV9haW89Im4iCitm
aQorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIE1ENSBpbiAtbGNyeXB0byIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGlu
IC1sY3J5cHRvLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9jcnlwdG9fTUQ1Kzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxjcnlwdG8gICRMSUJTIgorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv
ci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlm
CitjaGFyIE1ENSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIE1ENSAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9saWJfY3J5cHRvX01ENT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2NyeXB0b19N
RDU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
KyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tf
bGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9s
aWJfY3J5cHRvX01ENSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9
IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
TElCQ1JZUFRPIDEKK19BQ0VPRgorCisgIExJQlM9Ii1sY3J5cHRvICRMSUJTIgorCitlbHNlCisg
IGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJjcnlwdG8iICIkTElORU5PIiA1Citm
aQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfZXh0
MmZzX2V4dDJmc19vcGVuMis6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sZXh0
MmZzICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1
c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBleHQyZnNfb3BlbjIgKCk7CitpbnQKK21h
aW4gKCkKK3sKK3JldHVybiBleHQyZnNfb3BlbjIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9Citf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGli
X2V4dDJmc19leHQyZnNfb3BlbjI9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZz
X29wZW4yPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4mNjsgfQoraWYgdGVzdCAieCRh
Y19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPSB4eWVzOyB0aGVuIDoKKyAgbGliZXh0MmZz
PSJ5IgorZWxzZQorICBsaWJleHQyZnM9Im4iCitmaQorCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4g
LWxnY3J5cHQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZm
ZXIgaW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2djcnlwdF9nY3J5X21k
X2hhc2hfYnVmZmVyKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxnY3J5cHQg
ICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3Rv
dHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1h
dGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJn
dW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1
cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CitpbnQK
K21haW4gKCkKK3sKK3JldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgpOworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj15ZXMKK2Vsc2UKKyAgYWNfY3Zf
bGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlciIgPSB4eWVzOyB0aGVuIDoKKyAgbGliZ2NyeXB0PSJ5IgorZWxzZQor
ICBsaWJnY3J5cHQ9Im4iCitmaQorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHB0aHJlYWRfY3JlYXRlIGluIC1scHRocmVhZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZF9jcmVhdGUgaW4gLWxwdGhyZWFkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlKzp9IGZhbHNlOyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGli
X3NhdmVfTElCUz0kTElCUworTElCUz0iLWxwdGhyZWFkICAkTElCUyIKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciBwdGhyZWFkX2NyZWF0ZSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHB0aHJlYWRf
Y3JlYXRlICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRl
PXllcworZWxzZQorICBhY19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZT1ubworZmkKK3Jt
IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xp
Yl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3B0
aHJlYWRfcHRocmVhZF9jcmVhdGUiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKyAgYXNfZm5fZXJy
b3IgJD8gIkNvdWxkIG5vdCBmaW5kIGxpYnB0aHJlYWQiICIkTElORU5PIiA1CitmaQorCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbG9ja19n
ZXR0aW1lIGluIC1scnQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsb2NrX2dldHRp
bWUgaW4gLWxydC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSs6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1scnQgICRMSUJTIgorY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl
cnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw
ZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2Vu
ZGlmCitjaGFyIGNsb2NrX2dldHRpbWUgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBjbG9j
a19nZXR0aW1lICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lPXll
cworZWxzZQorICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZT1ubworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJf
cnRfY2xvY2tfZ2V0dGltZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0
aW1lIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID0geHll
czsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJS
VCAxCitfQUNFT0YKKworICBMSUJTPSItbHJ0ICRMSUJTIgorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1s
dXVpZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcis6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sdXVpZCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92
ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAg
VXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0ND
CisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg
YXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIg
dXVpZF9jbGVhciAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHV1aWRfY2xlYXIgKCk7Cisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3Zf
bGliX3V1aWRfdXVpZF9jbGVhcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0
CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+
JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY2OyB9CitpZiB0ZXN0
ICJ4JGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJVVUlEIDEKK19BQ0VPRgorCisgIExJ
QlM9Ii1sdXVpZCAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZp
bmQgbGlidXVpZCIgIiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciB5YWpsX2FsbG9jIGluIC1seWFqbC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9saWJfeWFqbF95YWpsX2FsbG9jKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UworTElCUz0iLWx5YWpsICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdD
QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNh
dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4g
YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisj
aWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciB5YWpsX2FsbG9jICgp
OworaW50CittYWluICgpCit7CityZXR1cm4geWFqbF9hbGxvYyAoKTsKKyAgOworICByZXR1cm4g
MDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcworZWxzZQorICBhY19jdl9saWJfeWFqbF95YWps
X2FsbG9jPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQorJGFzX2VjaG8g
IiRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGli
X3lhamxfeWFqbF9hbGxvYyIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2RlZmluZSBIQVZFX0xJQllBSkwgMQorX0FDRU9GCisKKyAgTElCUz0iLWx5YWpsICRM
SUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB5YWpsIiAiJExJ
TkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBkZWZsYXRlQ29weSBpbiAtbHouLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3pfZGVm
bGF0ZUNvcHkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHogICRMSUJTIgor
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBh
dm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSBy
ZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJv
dG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJu
ICJDIgorI2VuZGlmCitjaGFyIGRlZmxhdGVDb3B5ICgpOworaW50CittYWluICgpCit7CityZXR1
cm4gZGVmbGF0ZUNvcHkgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHk9
eWVzCitlbHNlCisgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5vCitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl96
X2RlZmxhdGVDb3B5IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4m
NjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPSB4eWVzOyB0aGVuIDoK
KyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX0xJQlogMQorX0FDRU9G
CisKKyAgTElCUz0iLWx6ICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBu
b3QgZmluZCB6bGliIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252IiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYuLi4g
IiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4rOn0gZmFsc2U7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJf
c2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGljb252ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyog
T3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisg
ICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBH
Q0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGls
bCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hh
ciBsaWJpY29udl9vcGVuICgpOworaW50CittYWluICgpCit7CityZXR1cm4gbGliaWNvbnZfb3Bl
biAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj15ZXMKK2Vs
c2UKKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2lj
b252X2xpYmljb252X29wZW4iID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfaWNvbnZfbGliaWNv
bnZfb3BlbiIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVu
IiA9IHh5ZXM7IHRoZW4gOgorICBsaWJpY29udj0ieSIKK2Vsc2UKKyAgbGliaWNvbnY9Im4iCitm
aQorCisKKworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5o
IGNoZWNrKQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK2FjX2ZuX2NfY2hlY2tfdHlwZSAi
JExJTkVOTyIgInNpemVfdCIgImFjX2N2X3R5cGVfc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc2l6ZV90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNl
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgc2l6ZV90IHVuc2lnbmVkIGlu
dAorX0FDRU9GCisKK2ZpCisKKyMgVGhlIFVsdHJpeCA0LjIgbWlwcyBidWlsdGluIGFsbG9jYSBk
ZWNsYXJlZCBieSBhbGxvY2EuaCBvbmx5IHdvcmtzCisjIGZvciBjb25zdGFudCBhcmd1bWVudHMu
ICBVc2VsZXNzIQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3Igd29ya2luZyBhbGxvY2EuaCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
d29ya2luZyBhbGxvY2EuaC4uLiAiID4mNjsgfQoraWYgJHthY19jdl93b3JraW5nX2FsbG9jYV9o
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworI2luY2x1ZGUgPGFsbG9jYS5oPgoraW50CittYWluICgpCit7CitjaGFyICpw
ID0gKGNoYXIgKikgYWxsb2NhICgyICogc2l6ZW9mIChpbnQpKTsKKwkJCSAgaWYgKHApIHJldHVy
biAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3dvcmtpbmdfYWxsb2NhX2g9eWVzCitlbHNlCisgIGFj
X2N2X3dvcmtpbmdfYWxsb2NhX2g9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3Zfd29ya2luZ19hbGxvY2FfaCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3dvcmtpbmdfYWxs
b2NhX2giID4mNjsgfQoraWYgdGVzdCAkYWNfY3Zfd29ya2luZ19hbGxvY2FfaCA9IHllczsgdGhl
bgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX0FMTE9DQV9IIDEiID4+Y29uZmRlZnMuaAorCitm
aQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBhbGxvY2EiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGFsbG9jYS4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9mdW5jX2FsbG9jYV93b3Jrcys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZmRlZiBfX0dOVUNf
XworIyBkZWZpbmUgYWxsb2NhIF9fYnVpbHRpbl9hbGxvY2EKKyNlbHNlCisjIGlmZGVmIF9NU0Nf
VkVSCisjICBpbmNsdWRlIDxtYWxsb2MuaD4KKyMgIGRlZmluZSBhbGxvY2EgX2FsbG9jYQorIyBl
bHNlCisjICBpZmRlZiBIQVZFX0FMTE9DQV9ICisjICAgaW5jbHVkZSA8YWxsb2NhLmg+CisjICBl
bHNlCisjICAgaWZkZWYgX0FJWAorICNwcmFnbWEgYWxsb2NhCisjICAgZWxzZQorIyAgICBpZm5k
ZWYgYWxsb2NhIC8qIHByZWRlZmluZWQgYnkgSFAgY2MgK09saWJjYWxscyAqLwordm9pZCAqYWxs
b2NhIChzaXplX3QpOworIyAgICBlbmRpZgorIyAgIGVuZGlmCisjICBlbmRpZgorIyBlbmRpZgor
I2VuZGlmCisKK2ludAorbWFpbiAoKQoreworY2hhciAqcCA9IChjaGFyICopIGFsbG9jYSAoMSk7
CisJCQkJICAgIGlmIChwKSByZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX2FsbG9j
YV93b3Jrcz15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3M9bm8KK2ZpCitybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRh
Y19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MiID4mNQorJGFz
X2VjaG8gIiRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY2OyB9CisKK2lmIHRlc3QgJGFjX2N2
X2Z1bmNfYWxsb2NhX3dvcmtzID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVf
QUxMT0NBIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgICMgVGhlIFNWUjMgbGliUFcgYW5kIFNW
UjQgbGlidWNiIGJvdGggY29udGFpbiBpbmNvbXBhdGlibGUgZnVuY3Rpb25zCisjIHRoYXQgY2F1
c2UgdHJvdWJsZS4gIFNvbWUgdmVyc2lvbnMgZG8gbm90IGV2ZW4gY29udGFpbiBhbGxvY2Egb3IK
KyMgY29udGFpbiBhIGJ1Z2d5IHZlcnNpb24uICBJZiB5b3Ugc3RpbGwgd2FudCB0byB1c2UgdGhl
aXIgYWxsb2NhLAorIyB1c2UgYXIgdG8gZXh0cmFjdCBhbGxvY2EubyBmcm9tIHRoZW0gaW5zdGVh
ZCBvZiBjb21waWxpbmcgYWxsb2NhLmMuCisKK0FMTE9DQT1cJHtMSUJPQkpESVJ9YWxsb2NhLiRh
Y19vYmpleHQKKworJGFzX2VjaG8gIiNkZWZpbmUgQ19BTExPQ0EgMSIgPj5jb25mZGVmcy5oCisK
KworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0
aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgd2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X29zX2NyYXkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBDUkFZICYmICEgZGVmaW5lZCBD
UkFZMgord2ViZWNyYXkKKyNlbHNlCit3ZW5vdGJlY3JheQorI2VuZGlmCisKK19BQ0VPRgoraWYg
KGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAorICAkRUdSRVAgIndlYmVj
cmF5IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBhY19jdl9vc19jcmF5PXllcworZWxzZQor
ICBhY19jdl9vc19jcmF5PW5vCitmaQorcm0gLWYgY29uZnRlc3QqCisKK2ZpCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29zX2NyYXkiID4m
NQorJGFzX2VjaG8gIiRhY19jdl9vc19jcmF5IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X29zX2Ny
YXkgPSB5ZXM7IHRoZW4KKyAgZm9yIGFjX2Z1bmMgaW4gX2dldGI2NyBHRVRCNjcgZ2V0YjY3OyBk
bworICAgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3Ry
X3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFy
IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIENSQVlfU1RBQ0tTRUdfRU5EICRhY19m
dW5jCitfQUNFT0YKKworICAgIGJyZWFrCitmaQorCisgIGRvbmUKK2ZpCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZv
ciBDIGFsbG9jYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBzdGFjayBkaXJlY3Rpb24gZm9y
IEMgYWxsb2NhLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9jX3N0YWNrX2RpcmVj
dGlvbj0wCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK2Zp
bmRfc3RhY2tfZGlyZWN0aW9uICgpCit7CisgIHN0YXRpYyBjaGFyICphZGRyID0gMDsKKyAgYXV0
byBjaGFyIGR1bW15OworICBpZiAoYWRkciA9PSAwKQorICAgIHsKKyAgICAgIGFkZHIgPSAmZHVt
bXk7CisgICAgICByZXR1cm4gZmluZF9zdGFja19kaXJlY3Rpb24gKCk7CisgICAgfQorICBlbHNl
CisgICAgcmV0dXJuICgmZHVtbXkgPiBhZGRyKSA/IDEgOiAtMTsKK30KKworaW50CittYWluICgp
Cit7CisgIHJldHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKSA8IDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9jX3N0YWNrX2RpcmVj
dGlvbj0xCitlbHNlCisgIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPS0xCitmaQorcm0gLWYgY29y
ZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVl
eHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4
dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfY19zdGFja19kaXJlY3Rpb24iID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX3N0
YWNrX2RpcmVjdGlvbiIgPiY2OyB9CitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IFNUQUNLX0RJUkVDVElPTiAkYWNfY3ZfY19zdGFja19kaXJlY3Rpb24KK19BQ0VPRgorCisKK2Zp
CisKK2ZvciBhY19oZWFkZXIgaW4gIFwKKyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250
bC5oIGludHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAg
ICAgICBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJp
bmcuaCBcCisgICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmgg
c3lzL21vdW50Lmggc3lzL3BhcmFtLmggXAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBz
eXMvc3RhdHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAg
ICAgICB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKworZG8gOgorICBhc19hY19IZWFk
ZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19I
ZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNf
SGVhZGVyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCitfQUNF
T0YKKworZmkKKworZG9uZQorCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywg
YW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5
OSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMg
dG8gQzk5Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hlYWRlcl9zdGRib29sX2grOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKyNpbmNsdWRlIDxzdGRib29sLmg+CisjaWZuZGVmIGJvb2wKKyAiZXJyb3I6IGJvb2wgaXMg
bm90IGRlZmluZWQiCisjZW5kaWYKKyNpZm5kZWYgZmFsc2UKKyAiZXJyb3I6IGZhbHNlIGlzIG5v
dCBkZWZpbmVkIgorI2VuZGlmCisjaWYgZmFsc2UKKyAiZXJyb3I6IGZhbHNlIGlzIG5vdCAwIgor
I2VuZGlmCisjaWZuZGVmIHRydWUKKyAiZXJyb3I6IHRydWUgaXMgbm90IGRlZmluZWQiCisjZW5k
aWYKKyNpZiB0cnVlICE9IDEKKyAiZXJyb3I6IHRydWUgaXMgbm90IDEiCisjZW5kaWYKKyNpZm5k
ZWYgX19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQKKyAiZXJyb3I6IF9fYm9vbF90cnVlX2Zh
bHNlX2FyZV9kZWZpbmVkIGlzIG5vdCBkZWZpbmVkIgorI2VuZGlmCisKKwlzdHJ1Y3QgcyB7IF9C
b29sIHM6IDE7IF9Cb29sIHQ7IH0gczsKKworCWNoYXIgYVt0cnVlID09IDEgPyAxIDogLTFdOwor
CWNoYXIgYltmYWxzZSA9PSAwID8gMSA6IC0xXTsKKwljaGFyIGNbX19ib29sX3RydWVfZmFsc2Vf
YXJlX2RlZmluZWQgPT0gMSA/IDEgOiAtMV07CisJY2hhciBkWyhib29sKSAwLjUgPT0gdHJ1ZSA/
IDEgOiAtMV07CisJLyogU2VlIGJvZHkgb2YgbWFpbiBwcm9ncmFtIGZvciAnZScuICAqLworCWNo
YXIgZlsoX0Jvb2wpIDAuMCA9PSBmYWxzZSA/IDEgOiAtMV07CisJY2hhciBnW3RydWVdOworCWNo
YXIgaFtzaXplb2YgKF9Cb29sKV07CisJY2hhciBpW3NpemVvZiBzLnRdOworCWVudW0geyBqID0g
ZmFsc2UsIGsgPSB0cnVlLCBsID0gZmFsc2UgKiB0cnVlLCBtID0gdHJ1ZSAqIDI1NiB9OworCS8q
IFRoZSBmb2xsb3dpbmcgZmFpbHMgZm9yCisJICAgSFAgYUMrKy9BTlNJIEMgQjM5MTBCIEEuMDUu
NTUgW0RlYyAwNCAyMDAzXS4gKi8KKwlfQm9vbCBuW21dOworCWNoYXIgb1tzaXplb2YgbiA9PSBt
ICogc2l6ZW9mIG5bMF0gPyAxIDogLTFdOworCWNoYXIgcFstMSAtIChfQm9vbCkgMCA8IDAgJiYg
LTEgLSAoYm9vbCkgMCA8IDAgPyAxIDogLTFdOworCS8qIENhdGNoIGEgYnVnIGluIGFuIEhQLVVY
IEMgY29tcGlsZXIuICBTZWUKKwkgICBodHRwOi8vZ2NjLmdudS5vcmcvbWwvZ2NjLXBhdGNoZXMv
MjAwMy0xMi9tc2cwMjMwMy5odG1sCisJICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9o
dG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMS9tc2cwMDE2MS5odG1sCisJICovCisJX0Jvb2wgcSA9
IHRydWU7CisJX0Jvb2wgKnBxID0gJnE7CisKK2ludAorbWFpbiAoKQoreworCisJYm9vbCBlID0g
JnM7CisJKnBxIHw9IHE7CisJKnBxIHw9ICEgcTsKKwkvKiBSZWZlciB0byBldmVyeSBkZWNsYXJl
ZCB2YWx1ZSwgdG8gYXZvaWQgY29tcGlsZXIgb3B0aW1pemF0aW9ucy4gICovCisJcmV0dXJuICgh
YSArICFiICsgIWMgKyAhZCArICFlICsgIWYgKyAhZyArICFoICsgIWkgKyAhIWogKyAhayArICEh
bAorCQkrICFtICsgIW4gKyAhbyArICFwICsgIXEgKyAhcHEpOworCisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaD15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0ZGJvb2xf
aD1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29u
ZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2hlYWRlcl9zdGRib29sX2giID4mNjsgfQorYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAi
X0Jvb2wiICJhY19jdl90eXBlX19Cb29sIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X3R5cGVfX0Jvb2wiID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9fQk9PTCAxCitfQUNFT0YKKworCitmaQorCitpZiB0ZXN0
ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5l
IEhBVkVfU1REQk9PTF9IIDEiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMvdHlwZXMu
aCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4g
IiA+JjY7IH0KK2lmICR7YWNfY3ZfdHlwZV91aWRfdCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzeXMv
dHlwZXMuaD4KKworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0Iikg
Mj4mNSB8CisgICRFR1JFUCAidWlkX3QiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisgIGFjX2N2
X3R5cGVfdWlkX3Q9eWVzCitlbHNlCisgIGFjX2N2X3R5cGVfdWlkX3Q9bm8KK2ZpCitybSAtZiBj
b25mdGVzdCoKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3R5cGVfdWlk
X3QiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfdHlwZV91aWRfdCA9IG5vOyB0aGVuCisKKyRhc19l
Y2hvICIjZGVmaW5lIHVpZF90IGludCIgPj5jb25mZGVmcy5oCisKKworJGFzX2VjaG8gIiNkZWZp
bmUgZ2lkX3QgaW50IiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW5saW5lIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19pbmxpbmUrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19j
dl9jX2lubGluZT1ubworZm9yIGFjX2t3IGluIGlubGluZSBfX2lubGluZV9fIF9faW5saW5lOyBk
bworICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisjaWZuZGVmIF9fY3BsdXNwbHVzCit0eXBlZGVmIGludCBmb29fdDsK
K3N0YXRpYyAkYWNfa3cgZm9vX3Qgc3RhdGljX2ZvbyAoKSB7cmV0dXJuIDA7IH0KKyRhY19rdyBm
b29fdCBmb28gKCkge3JldHVybiAwOyB9CisjZW5kaWYKKworX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2NfaW5saW5lPSRhY19rdworZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj
X2V4dAorICB0ZXN0ICIkYWNfY3ZfY19pbmxpbmUiICE9IG5vICYmIGJyZWFrCitkb25lCisKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2NfaW5saW5lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19pbmxpbmUiID4mNjsgfQorCitjYXNl
ICRhY19jdl9jX2lubGluZSBpbgorICBpbmxpbmUgfCB5ZXMpIDs7CisgICopCisgICAgY2FzZSAk
YWNfY3ZfY19pbmxpbmUgaW4KKyAgICAgIG5vKSBhY192YWw9OzsKKyAgICAgICopIGFjX3ZhbD0k
YWNfY3ZfY19pbmxpbmU7OworICAgIGVzYWMKKyAgICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjaWZuZGVmIF9fY3BsdXNwbHVzCisjZGVmaW5lIGlubGluZSAkYWNfdmFsCisjZW5kaWYKK19B
Q0VPRgorICAgIDs7Citlc2FjCisKK2FjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICIxNiIg
ImFjX2N2X2NfaW50MTZfdCIKK2Nhc2UgJGFjX2N2X2NfaW50MTZfdCBpbiAjKAorICBub3x5ZXMp
IDs7ICMoCisgICopCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgaW50MTZf
dCAkYWNfY3ZfY19pbnQxNl90CitfQUNFT0YKKzs7Citlc2FjCisKK2FjX2ZuX2NfZmluZF9pbnRY
X3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKK2Nhc2UgJGFjX2N2X2NfaW50MzJf
dCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKKyNkZWZpbmUgaW50MzJfdCAkYWNfY3ZfY19pbnQzMl90CitfQUNFT0YKKzs7Citlc2FjCisK
K2FjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICI2NCIgImFjX2N2X2NfaW50NjRfdCIKK2Nh
c2UgJGFjX2N2X2NfaW50NjRfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKK2NhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgaW50NjRfdCAkYWNfY3ZfY19pbnQ2NF90Citf
QUNFT0YKKzs7Citlc2FjCisKK2FjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICI4IiAiYWNf
Y3ZfY19pbnQ4X3QiCitjYXNlICRhY19jdl9jX2ludDhfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMo
CisgICopCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgaW50OF90ICRhY19j
dl9jX2ludDhfdAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F
Tk8iICJtb2RlX3QiICJhY19jdl90eXBlX21vZGVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igor
aWYgdGVzdCAieCRhY19jdl90eXBlX21vZGVfdCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIG1vZGVfdCBpbnQKK19BQ0VPRgorCitm
aQorCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2X3R5cGVfb2Zm
X3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZfdCIg
PSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVm
aW5lIG9mZl90IGxvbmcgaW50CitfQUNFT0YKKworZmkKKworYWNfZm5fY19jaGVja190eXBlICIk
TElORU5PIiAicGlkX3QiICJhY19jdl90eXBlX3BpZF90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQi
CitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcGlkX3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBwaWRfdCBpbnQKK19BQ0VPRgorCitm
aQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBDL0MrKyByZXN0cmljdCBrZXl3b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBD
L0MrKyByZXN0cmljdCBrZXl3b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfcmVzdHJpY3Qr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBh
Y19jdl9jX3Jlc3RyaWN0PW5vCisgICAjIFRoZSBvcmRlciBoZXJlIGNhdGVycyB0byB0aGUgZmFj
dCB0aGF0IEMrKyBkb2VzIG5vdCByZXF1aXJlIHJlc3RyaWN0LgorICAgZm9yIGFjX2t3IGluIF9f
cmVzdHJpY3QgX19yZXN0cmljdF9fIF9SZXN0cmljdCByZXN0cmljdDsgZG8KKyAgICAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwordHlwZWRlZiBpbnQgKiBpbnRfcHRyOworCWludCBmb28gKGludF9wdHIgJGFjX2t3IGlw
KSB7CisJcmV0dXJuIGlwWzBdOworICAgICAgIH0KK2ludAorbWFpbiAoKQoreworaW50IHNbMV07
CisJaW50ICogJGFjX2t3IHQgPSBzOworCXRbMF0gPSAwOworCXJldHVybiBmb28odCkKKyAgOwor
ICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9jX3Jlc3RyaWN0PSRhY19rdworZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgICB0ZXN0ICIk
YWNfY3ZfY19yZXN0cmljdCIgIT0gbm8gJiYgYnJlYWsKKyAgIGRvbmUKKworZmkKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19yZXN0cmlj
dCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2NfcmVzdHJpY3QiID4mNjsgfQorCisgY2FzZSAkYWNf
Y3ZfY19yZXN0cmljdCBpbgorICAgcmVzdHJpY3QpIDs7CisgICBubykgJGFzX2VjaG8gIiNkZWZp
bmUgcmVzdHJpY3QgLyoqLyIgPj5jb25mZGVmcy5oCisgOzsKKyAgICopICBjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIHJlc3RyaWN0ICRhY19jdl9jX3Jlc3RyaWN0CitfQUNFT0YK
KyA7OworIGVzYWMKKworYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic2l6ZV90IiAiYWNf
Y3ZfdHlwZV9zaXplX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3Zf
dHlwZV9zaXplX3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSBzaXplX3QgdW5zaWduZWQgaW50CitfQUNFT0YKKworZmkKKworYWNf
Zm5fY19jaGVja190eXBlICIkTElORU5PIiAic3NpemVfdCIgImFjX2N2X3R5cGVfc3NpemVfdCIg
IiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3NzaXplX3QiID0g
eHllczsgdGhlbiA6CisKK2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBzc2l6ZV90IGludAorX0FDRU9GCisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElO
RU5PIiAic3RydWN0IHN0YXQiICJzdF9ibGtzaXplIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0
X3N0X2Jsa3NpemUiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfbWVt
YmVyX3N0cnVjdF9zdGF0X3N0X2Jsa3NpemUiID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFIDEKK19B
Q0VPRgorCisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0
YXQiICJzdF9ibG9ja3MiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tzIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9z
dF9ibG9ja3MiID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MgMQorX0FDRU9GCisKKworJGFzX2VjaG8g
IiNkZWZpbmUgSEFWRV9TVF9CTE9DS1MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgY2FzZSAi
ICRMSUJPQkpTICIgaW4KKyAgKiIgZmlsZWJsb2Nrcy4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikg
TElCT0JKUz0iJExJQk9CSlMgZmlsZWJsb2Nrcy4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKK2Zp
CisKKworYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X3Jk
ZXYiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfcmRldiIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgoraWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfcmRldiIgPSB4eWVz
OyB0aGVuIDoKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NUUlVD
VF9TVEFUX1NUX1JERVYgMQorX0FDRU9GCisKKworZmkKKworYWNfZm5fY19maW5kX3VpbnRYX3Qg
IiRMSU5FTk8iICIxNiIgImFjX2N2X2NfdWludDE2X3QiCitjYXNlICRhY19jdl9jX3VpbnQxNl90
IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKworCitjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCisjZGVmaW5lIHVpbnQxNl90ICRhY19jdl9jX3VpbnQxNl90CitfQUNFT0YKKzs7CisgIGVz
YWMKKworYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2NfdWludDMy
X3QiCitjYXNlICRhY19jdl9jX3VpbnQzMl90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikK
KworJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQzMl9UIDEiID4+Y29uZmRlZnMuaAorCisKK2NhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgdWludDMyX3QgJGFjX2N2X2NfdWludDMyX3QK
K19BQ0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjY0
IiAiYWNfY3ZfY191aW50NjRfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDY0X3QgaW4gIygKKyAgbm98
eWVzKSA7OyAjKAorICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBfVUlOVDY0X1QgMSIgPj5jb25m
ZGVmcy5oCisKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1aW50NjRfdCAk
YWNfY3ZfY191aW50NjRfdAorX0FDRU9GCis7OworICBlc2FjCisKK2FjX2ZuX2NfZmluZF91aW50
WF90ICIkTElORU5PIiAiOCIgImFjX2N2X2NfdWludDhfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDhf
dCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKKyRhc19lY2hvICIjZGVmaW5lIF9VSU5U
OF9UIDEiID4+Y29uZmRlZnMuaAorCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZp
bmUgdWludDhfdCAkYWNfY3ZfY191aW50OF90CitfQUNFT0YKKzs7CisgIGVzYWMKKworYWNfZm5f
Y19jaGVja190eXBlICIkTElORU5PIiAicHRyZGlmZl90IiAiYWNfY3ZfdHlwZV9wdHJkaWZmX3Qi
ICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9wdHJkaWZmX3Qi
ID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFW
RV9QVFJESUZGX1QgMQorX0FDRU9GCisKKworZmkKKworCisjIENoZWNrcyBmb3IgbGlicmFyeSBm
dW5jdGlvbnMuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBlcnJvcl9hdF9saW5lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBlcnJv
cl9hdF9saW5lLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9lcnJvcl9hdF9saW5lKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworI2luY2x1ZGUgPGVycm9yLmg+CitpbnQKK21haW4gKCkKK3sKK2Vycm9yX2F0X2xpbmUg
KDAsIDAsICIiLCAwLCAiYW4gZXJyb3Igb2NjdXJyZWQiKTsKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9s
aWJfZXJyb3JfYXRfbGluZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9bm8K
K2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9CitpZiB0ZXN0
ICRhY19jdl9saWJfZXJyb3JfYXRfbGluZSA9IG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JKUyAi
IGluCisgICoiIGVycm9yLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JK
UyBlcnJvci4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKK2ZpCisKK2ZvciBhY19oZWFkZXIgaW4g
dmZvcmsuaAorZG8gOgorICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAi
dmZvcmsuaCIgImFjX2N2X2hlYWRlcl92Zm9ya19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitp
ZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl92Zm9ya19oIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfVkZPUktfSCAxCitfQUNFT0YKKworZmkK
KworZG9uZQorCitmb3IgYWNfZnVuYyBpbiBmb3JrIHZmb3JrCitkbyA6CisgIGFzX2FjX3Zhcj1g
JGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVj
a19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwi
eFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAx
CitfQUNFT0YKKworZmkKK2RvbmUKKworaWYgdGVzdCAieCRhY19jdl9mdW5jX2ZvcmsiID0geHll
czsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciB3b3JraW5nIGZvcmsiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtp
bmcgZm9yay4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX2Zvcmtfd29ya3MrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIk
Y3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1j
cm9zcworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50CittYWlu
ICgpCit7CisKKwkgIC8qIEJ5IFJ1ZWRpZ2VyIEt1aGxtYW5uLiAqLworCSAgcmV0dXJuIGZvcmsg
KCkgPCAwOworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCitlbHNlCisg
IGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29u
ZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNf
Zm9ya193b3JrcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9
CisKK2Vsc2UKKyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPSRhY19jdl9mdW5jX2ZvcmsKK2ZpCitp
ZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KKyAgY2FzZSAk
aG9zdCBpbgorICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3BwKikKKyAgICAgICMgT3Zl
cnJpZGUsIGFzIHRoZXNlIHN5c3RlbXMgaGF2ZSBvbmx5IGEgZHVtbXkgZm9yaygpIHN0dWIKKyAg
ICAgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1ubworICAgICAgOzsKKyAgICAqKQorICAgICAgYWNf
Y3ZfZnVuY19mb3JrX3dvcmtzPXllcworICAgICAgOzsKKyAgZXNhYworICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19m
b3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVz
c2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorYWNfY3ZfZnVuY192
Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yaworaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3Jr
IiA9IHh5ZXM7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3Igd29ya2luZyB2Zm9yayIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm
b3Igd29ya2luZyB2Zm9yay4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX3Zmb3JrX3dvcmtz
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzPWNyb3NzCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIFRoYW5rcyB0byBQYXVsIEVn
Z2VydCBmb3IgdGhpcyB0ZXN0LiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisjaW5jbHVkZSA8
c3lzL3dhaXQuaD4KKyNpZmRlZiBIQVZFX1ZGT1JLX0gKKyMgaW5jbHVkZSA8dmZvcmsuaD4KKyNl
bmRpZgorLyogT24gc29tZSBzcGFyYyBzeXN0ZW1zLCBjaGFuZ2VzIGJ5IHRoZSBjaGlsZCB0byBs
b2NhbCBhbmQgaW5jb21pbmcKKyAgIGFyZ3VtZW50IHJlZ2lzdGVycyBhcmUgcHJvcGFnYXRlZCBi
YWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGlsZXIKKyAgIGlzIHRvbGQgYWJvdXQgdGhpcyB3
aXRoICNpbmNsdWRlIDx2Zm9yay5oPiwgYnV0IHNvbWUgY29tcGlsZXJzCisgICAoZS5nLiBnY2Mg
LU8pIGRvbid0IGdyb2sgPHZmb3JrLmg+LiAgVGVzdCBmb3IgdGhpcyBieSB1c2luZyBhCisgICBz
dGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVzcyBpcyBwdXQgaW50byBhIHJlZ2lzdGVyIHRoYXQg
aXMKKyAgIGNsb2JiZXJlZCBieSB0aGUgdmZvcmsuICAqLworc3RhdGljIHZvaWQKKyNpZmRlZiBf
X2NwbHVzcGx1cworc3BhcmNfYWRkcmVzc190ZXN0IChpbnQgYXJnKQorIyBlbHNlCitzcGFyY19h
ZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsKKyNlbmRpZgoreworICBzdGF0aWMgcGlkX3QgY2hp
bGQ7CisgIGlmICghY2hpbGQpIHsKKyAgICBjaGlsZCA9IHZmb3JrICgpOworICAgIGlmIChjaGls
ZCA8IDApIHsKKyAgICAgIHBlcnJvciAoInZmb3JrIik7CisgICAgICBfZXhpdCgyKTsKKyAgICB9
CisgICAgaWYgKCFjaGlsZCkgeworICAgICAgYXJnID0gZ2V0cGlkKCk7CisgICAgICB3cml0ZSgt
MSwgIiIsIDApOworICAgICAgX2V4aXQgKGFyZyk7CisgICAgfQorICB9Cit9CisKK2ludAorbWFp
biAoKQoreworICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7CisgIHBpZF90IGNoaWxkOworCisg
IHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7CisKKyAgY2hpbGQgPSB2Zm9yayAoKTsKKworICBpZiAo
Y2hpbGQgPT0gMCkgeworICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0ZXN0IGZvciBzcGFyYyB2Zm9y
ayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKKyAgICAgICB0ZXN0IHVzZXMgbG90cyBvZiBsb2Nh
bCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1hbnkgbG9jYWwKKyAgICAgICB2YXJpYWJsZXMgYXMg
bWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBpbmNsdWRpbmcgY29tcGlsZXIKKyAgICAgICB0ZW1w
b3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9yIGdjYyAxLjQwLjMgb24gYSBTb2xhcmlz
CisgICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3ZSB1c2UgOCB0byBiZSBzYWZlLiAgQSBidWdneSBj
b21waWxlciBzaG91bGQKKyAgICAgICByZXVzZSB0aGUgcmVnaXN0ZXIgb2YgcGFyZW50IGZvciBv
bmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywKKyAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRo
YXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJlIHVzZWQgYW55IG1vcmUKKyAgICAgICBpbiB0aGlz
IHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhlIGxvY2FsIHZhcmlhYmxlIHdpbGwgdGh1cworICAg
ICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFyZW50IHByb2Nlc3MuICAqLworICAgIHBpZF90Cisg
ICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0cGlkKCksIHAyID0gZ2V0cGlkKCksIHAzID0gZ2V0
cGlkKCksCisgICAgICBwNCA9IGdldHBpZCgpLCBwNSA9IGdldHBpZCgpLCBwNiA9IGdldHBpZCgp
LCBwNyA9IGdldHBpZCgpOworICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3
IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1pZ2h0CisgICAgICAgdXNlIHRoZSBzYW1lIGhhcmR3
YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2NhbCB2YXJpYWJsZXMuICAqLworICAgIGlmIChwICE9
IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8fCBwICE9IHA0CisJfHwgcCAhPSBwNSB8fCBwICE9
IHA2IHx8IHAgIT0gcDcpCisgICAgICBfZXhpdCgxKTsKKworICAgIC8qIE9uIHNvbWUgc3lzdGVt
cyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50CisgICAgICAg
ZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3JzLiAgSWYgdGhlIGNoaWxkIGNsb3NlcyBhIGRlc2Ny
aXB0b3IKKyAgICAgICBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMsIHRoaXMgbXVuZ2VzIHRoZSBw
YXJlbnQncyBkZXNjcmlwdG9yCisgICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRoaXMgYnkgY2xv
c2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KKyAgICBfZXhpdChjbG9zZShmaWxlbm8oc3Rk
b3V0KSkgIT0gMCk7CisgIH0gZWxzZSB7CisgICAgaW50IHN0YXR1czsKKyAgICBzdHJ1Y3Qgc3Rh
dCBzdDsKKworICAgIHdoaWxlICh3YWl0KCZzdGF0dXMpICE9IGNoaWxkKQorICAgICAgOworICAg
IHJldHVybiAoCisJIC8qIFdhcyB0aGVyZSBzb21lIHByb2JsZW0gd2l0aCB2Zm9ya2luZz8gICov
CisJIGNoaWxkIDwgMAorCisJIC8qIERpZCB0aGUgY2hpbGQgZmFpbD8gIChUaGlzIHNob3VsZG4n
dCBoYXBwZW4uKSAgKi8KKwkgfHwgc3RhdHVzCisKKwkgLyogRGlkIHRoZSB2Zm9yay9jb21waWxl
ciBidWcgb2NjdXI/ICAqLworCSB8fCBwYXJlbnQgIT0gZ2V0cGlkKCkKKworCSAvKiBEaWQgdGhl
IGZpbGUgZGVzY3JpcHRvciBidWcgb2NjdXI/ICAqLworCSB8fCBmc3RhdChmaWxlbm8oc3Rkb3V0
KSwgJnN0KSAhPSAwCisJICk7CisgIH0KK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9eWVzCitlbHNlCisgIGFj
X2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0
ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY2OyB9
CisKK2ZpOworaWYgdGVzdCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geGNyb3NzOyB0aGVu
CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1bmNfdmZvcmsKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY192Zm9ya193b3Jr
cyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorCitpZiB0
ZXN0ICJ4JGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID0geHllczsgdGhlbgorCiskYXNfZWNobyAi
I2RlZmluZSBIQVZFX1dPUktJTkdfVkZPUksgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKworJGFz
X2VjaG8gIiNkZWZpbmUgdmZvcmsgZm9yayIgPj5jb25mZGVmcy5oCisKK2ZpCitpZiB0ZXN0ICJ4
JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5l
IEhBVkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBfTEFSR0VGSUxFX1NPVVJD
RSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBfTEFSR0VGSUxFX1NPVVJDRSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgd2hpbGUgOjsgZG8KKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8KKyAgICAgI2lu
Y2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK2ludCAoKmZwKSAoRklMRSAqLCBvZmZf
dCwgaW50KSA9IGZzZWVrbzsKKyAgICAgcmV0dXJuIGZzZWVrbyAoc3RkaW4sIDAsIDApICYmIGZw
IChzdGRpbiwgMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9
bm87IGJyZWFrCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAxCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+IC8q
IGZvciBvZmZfdCAqLworICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAoKQorewor
aW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOworICAgICByZXR1cm4gZnNl
ZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT0xOyBicmVhaworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0CisgIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPXVua25vd24KKyAgYnJlYWsK
K2RvbmUKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfc3lz
X2xhcmdlZmlsZV9zb3VyY2UiID4mNjsgfQorY2FzZSAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3Vy
Y2UgaW4gIygKKyAgbm8gfCB1bmtub3duKSA7OworICAqKQorY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3Vy
Y2UKK19BQ0VPRgorOzsKK2VzYWMKK3JtIC1yZiBjb25mdGVzdCoKKworIyBXZSB1c2VkIHRvIHRy
eSBkZWZpbmluZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5kIGEgYnVnCisj
IGluIGdsaWJjIDIuMS4zLCBidXQgdGhhdCBicmVha3MgdG9vIG1hbnkgb3RoZXIgdGhpbmdzLgor
IyBJZiB5b3Ugd2FudCBmc2Vla28gYW5kIGZ0ZWxsbyB3aXRoIGdsaWJjLCB1cGdyYWRlIHRvIGEg
Zml4ZWQgZ2xpYmMuCitpZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSAhPSB1bmtu
b3duOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+Y29uZmRlZnMu
aAorCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMgdHJhaWxpbmcgc2xhc2giID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFuZGxlcyB0cmFp
bGluZyBzbGFzaC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNl
c19zbGFzaGVkX3N5bWxpbmsrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQorZWNobyA+
Y29uZnRlc3QuZmlsZQoraWYgdGVzdCAiJGFzX2xuX3MiID0gImxuIC1zIiAmJiBsbiAtcyBjb25m
dGVzdC5maWxlIGNvbmZ0ZXN0LnN5bTsgdGhlbgorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5n
IiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRf
c3ltbGluaz1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50
CittYWluICgpCit7CitzdHJ1Y3Qgc3RhdCBzYnVmOworICAgICAvKiBMaW51eCB3aWxsIGRlcmVm
ZXJlbmNlIHRoZSBzeW1saW5rIGFuZCBmYWlsLCBhcyByZXF1aXJlZCBieSBQT1NJWC4KKwlUaGF0
IGlzIGJldHRlciBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBtZWFucyB3ZSB3aWxsIG5vdAorCWhhdmUg
dG8gY29tcGlsZSBhbmQgdXNlIHRoZSBsc3RhdCB3cmFwcGVyLiAgKi8KKyAgICAgcmV0dXJuIGxz
dGF0ICgiY29uZnRlc3Quc3ltLyIsICZzYnVmKSA9PSAwOworICA7CisgIHJldHVybiAwOworfQor
X0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcworZWxzZQorICBhY19jdl9m
dW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KK2ZpCitybSAtZiBjb3Jl
ICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0
CitmaQorCitlbHNlCisgICMgSWYgdGhlIGBsbiAtcycgY29tbWFuZCBmYWlsZWQsIHRoZW4gd2Ug
cHJvYmFibHkgZG9uJ3QgZXZlbgorICAjIGhhdmUgYW4gbHN0YXQgZnVuY3Rpb24uCisgIGFjX2N2
X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubworZmkKK3JtIC1mIGNv
bmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3Ns
YXNoZWRfc3ltbGluayIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVu
Y2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9CisKK3Rlc3QgJGFjX2N2X2Z1bmNfbHN0YXRfZGVy
ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgorCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LIDEKK19BQ0VPRgor
CisKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1s
aW5rIiA9IHhubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBsc3RhdC4kYWNf
b2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgbHN0YXQuJGFjX29iamV4dCIK
KyA7OworZXNhYworCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmggZGVmaW5lcyBtYWtlZGV2IiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmggZGVmaW5lcyBtYWtlZGV2Li4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2Kzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgoraW50CittYWluICgpCit7CityZXR1cm4gbWFrZWRl
digwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGlu
ayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj15
ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXY9bm8KK2ZpCitybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRh
Y19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRl
diIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjY7
IH0KKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYgPSBubzsgdGhl
bgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN5cy9ta2Rldi5oIiAi
YWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIgPSB4eWVzOyB0aGVuIDoKKworJGFzX2VjaG8g
IiNkZWZpbmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworCisgIGlm
IHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCA9IG5vOyB0aGVuCisgICAgYWNfZm5fY19j
aGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN5cy9zeXNtYWNyb3MuaCIgImFjX2N2X2hl
YWRlcl9zeXNfc3lzbWFjcm9zX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngk
YWNfY3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgPSB4eWVzOyB0aGVuIDoKKworJGFzX2VjaG8g
IiNkZWZpbmUgTUFKT1JfSU5fU1lTTUFDUk9TIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKyAg
ZmkKK2ZpCisKK2ZvciBhY19oZWFkZXIgaW4gc3RkbGliLmgKK2RvIDoKKyAgYWNfZm5fY19jaGVj
a19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxp
Yl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRs
aWJfaCIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBIQVZFX1NURExJQl9IIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGli
bGUgbWFsbG9jIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRp
YmxlIG1hbGxvYy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBp
ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbWFs
bG9jXzBfbm9ubnVsbD1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBTVERDX0hF
QURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorI2Vs
c2UKK2NoYXIgKm1hbGxvYyAoKTsKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAh
IG1hbGxvYyAoMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5
X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9eWVz
CitlbHNlCisgIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1ubworZmkKK3JtIC1mIGNvcmUg
Ki5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0
IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQK
K2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1
bmNfbWFsbG9jXzBfbm9ubnVsbCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX21hbGxvY18w
X25vbm51bGwgPSB5ZXM7IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAx
IiA+PmNvbmZkZWZzLmgKKworZWxzZQorICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAw
IiA+PmNvbmZkZWZzLmgKKworICAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbWFsbG9jLiRh
Y19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBtYWxsb2MuJGFjX29iamV4
dCIKKyA7OworZXNhYworCisKKyRhc19lY2hvICIjZGVmaW5lIG1hbGxvYyBycGxfbWFsbG9jIiA+
PmNvbmZkZWZzLmgKKworZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJl
IGluY2x1ZGVkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBz
eXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hl
YWRlcl90aW1lKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5
cy90aW1lLmg+CisjaW5jbHVkZSA8dGltZS5oPgorCitpbnQKK21haW4gKCkKK3sKK2lmICgoc3Ry
dWN0IHRtICopIDApCityZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfdGlt
ZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3RpbWU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl90
aW1lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQoraWYgdGVzdCAk
YWNfY3ZfaGVhZGVyX3RpbWUgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgVElNRV9X
SVRIX1NZU19USU1FIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKworCisgIGZvciBhY19oZWFk
ZXIgaW4gJGFjX2hlYWRlcl9saXN0CitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFj
X2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVy
X2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNs
dWRlc19kZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgi
eWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19l
Y2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCisKK2Rv
bmUKKworCisKKworCisKKworCisgIGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKK2RvIDoK
KyAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hg
CithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitp
ZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8
ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorZG9uZQorCisKKworCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1l
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIG1rdGltZS4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGlu
ZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCitlbHNlCisg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKy8qIFRlc3QgcHJvZ3JhbSBmcm9tIFBhdWwgRWdnZXJ0IGFuZCBUb255IExl
bmVpcy4gICovCisjaWZkZWYgVElNRV9XSVRIX1NZU19USU1FCisjIGluY2x1ZGUgPHN5cy90aW1l
Lmg+CisjIGluY2x1ZGUgPHRpbWUuaD4KKyNlbHNlCisjIGlmZGVmIEhBVkVfU1lTX1RJTUVfSAor
IyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4KKyMgZWxzZQorIyAgaW5jbHVkZSA8dGltZS5oPgorIyBl
bmRpZgorI2VuZGlmCisKKyNpbmNsdWRlIDxsaW1pdHMuaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4K
KworI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3RkLmg+CisjZW5kaWYKKwor
I2lmbmRlZiBIQVZFX0FMQVJNCisjIGRlZmluZSBhbGFybShYKSAvKiBlbXB0eSAqLworI2VuZGlm
CisKKy8qIFdvcmsgYXJvdW5kIHJlZGVmaW5pdGlvbiB0byBycGxfcHV0ZW52IGJ5IG90aGVyIGNv
bmZpZyB0ZXN0cy4gICovCisjdW5kZWYgcHV0ZW52CisKK3N0YXRpYyB0aW1lX3QgdGltZV90X21h
eDsKK3N0YXRpYyB0aW1lX3QgdGltZV90X21pbjsKKworLyogVmFsdWVzIHdlJ2xsIHVzZSB0byBz
ZXQgdGhlIFRaIGVudmlyb25tZW50IHZhcmlhYmxlLiAgKi8KK3N0YXRpYyBjb25zdCBjaGFyICp0
el9zdHJpbmdzW10gPSB7CisgIChjb25zdCBjaGFyICopIDAsICJUWj1HTVQwIiwgIlRaPUpTVC05
IiwKKyAgIlRaPUVTVCszRURUKzIsTTEwLjEuMC8wMDowMDowMCxNMi4zLjAvMDA6MDA6MDAiCit9
OworI2RlZmluZSBOX1NUUklOR1MgKHNpemVvZiAodHpfc3RyaW5ncykgLyBzaXplb2YgKHR6X3N0
cmluZ3NbMF0pKQorCisvKiBSZXR1cm4gMCBpZiBta3RpbWUgZmFpbHMgdG8gY29udmVydCBhIGRh
dGUgaW4gdGhlIHNwcmluZy1mb3J3YXJkIGdhcC4KKyAgIEJhc2VkIG9uIGEgcHJvYmxlbSByZXBv
cnQgZnJvbSBBbmRyZWFzIEphZWdlci4gICovCitzdGF0aWMgaW50CitzcHJpbmdfZm9yd2FyZF9n
YXAgKCkKK3sKKyAgLyogZ2xpYmMgKHVwIHRvIGFib3V0IDE5OTgtMTAtMDcpIGZhaWxlZCB0aGlz
IHRlc3QuICovCisgIHN0cnVjdCB0bSB0bTsKKworICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBPU0lY
LjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIKKyAgICAgaW5zdGVh
ZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVnIGV2
ZW4KKyAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhlIE9sc29uIGV4dGVuc2lv
biwgb3IgZG9uJ3QgaGF2ZSB0aGUKKyAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFsbGVk
LiAgKi8KKyAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7CisK
KyAgdG0udG1feWVhciA9IDk4OworICB0bS50bV9tb24gPSAzOworICB0bS50bV9tZGF5ID0gNTsK
KyAgdG0udG1faG91ciA9IDI7CisgIHRtLnRtX21pbiA9IDA7CisgIHRtLnRtX3NlYyA9IDA7Cisg
IHRtLnRtX2lzZHN0ID0gLTE7CisgIHJldHVybiBta3RpbWUgKCZ0bSkgIT0gKHRpbWVfdCkgLTE7
Cit9CisKK3N0YXRpYyBpbnQKK21rdGltZV90ZXN0MSAodGltZV90IG5vdykKK3sKKyAgc3RydWN0
IHRtICpsdDsKKyAgcmV0dXJuICEgKGx0ID0gbG9jYWx0aW1lICgmbm93KSkgfHwgbWt0aW1lIChs
dCkgPT0gbm93OworfQorCitzdGF0aWMgaW50Citta3RpbWVfdGVzdCAodGltZV90IG5vdykKK3sK
KyAgcmV0dXJuIChta3RpbWVfdGVzdDEgKG5vdykKKwkgICYmIG1rdGltZV90ZXN0MSAoKHRpbWVf
dCkgKHRpbWVfdF9tYXggLSBub3cpKQorCSAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAodGlt
ZV90X21pbiArIG5vdykpKTsKK30KKworc3RhdGljIGludAoraXJpeF82XzRfYnVnICgpCit7Cisg
IC8qIEJhc2VkIG9uIGNvZGUgZnJvbSBBcmllbCBGYWlnb24uICAqLworICBzdHJ1Y3QgdG0gdG07
CisgIHRtLnRtX3llYXIgPSA5NjsKKyAgdG0udG1fbW9uID0gMzsKKyAgdG0udG1fbWRheSA9IDA7
CisgIHRtLnRtX2hvdXIgPSAwOworICB0bS50bV9taW4gPSAwOworICB0bS50bV9zZWMgPSAwOwor
ICB0bS50bV9pc2RzdCA9IC0xOworICBta3RpbWUgKCZ0bSk7CisgIHJldHVybiB0bS50bV9tb24g
PT0gMiAmJiB0bS50bV9tZGF5ID09IDMxOworfQorCitzdGF0aWMgaW50CitiaWd0aW1lX3Rlc3Qg
KGludCBqKQoreworICBzdHJ1Y3QgdG0gdG07CisgIHRpbWVfdCBub3c7CisgIHRtLnRtX3llYXIg
PSB0bS50bV9tb24gPSB0bS50bV9tZGF5ID0gdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRtLnRt
X3NlYyA9IGo7CisgIG5vdyA9IG1rdGltZSAoJnRtKTsKKyAgaWYgKG5vdyAhPSAodGltZV90KSAt
MSkKKyAgICB7CisgICAgICBzdHJ1Y3QgdG0gKmx0ID0gbG9jYWx0aW1lICgmbm93KTsKKyAgICAg
IGlmICghIChsdAorCSAgICAgJiYgbHQtPnRtX3llYXIgPT0gdG0udG1feWVhcgorCSAgICAgJiYg
bHQtPnRtX21vbiA9PSB0bS50bV9tb24KKwkgICAgICYmIGx0LT50bV9tZGF5ID09IHRtLnRtX21k
YXkKKwkgICAgICYmIGx0LT50bV9ob3VyID09IHRtLnRtX2hvdXIKKwkgICAgICYmIGx0LT50bV9t
aW4gPT0gdG0udG1fbWluCisJICAgICAmJiBsdC0+dG1fc2VjID09IHRtLnRtX3NlYworCSAgICAg
JiYgbHQtPnRtX3lkYXkgPT0gdG0udG1feWRheQorCSAgICAgJiYgbHQtPnRtX3dkYXkgPT0gdG0u
dG1fd2RheQorCSAgICAgJiYgKChsdC0+dG1faXNkc3QgPCAwID8gLTEgOiAwIDwgbHQtPnRtX2lz
ZHN0KQorCQkgID09ICh0bS50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCB0bS50bV9pc2RzdCkpKSkK
KwlyZXR1cm4gMDsKKyAgICB9CisgIHJldHVybiAxOworfQorCitzdGF0aWMgaW50Cit5ZWFyXzIw
NTBfdGVzdCAoKQoreworICAvKiBUaGUgY29ycmVjdCBhbnN3ZXIgZm9yIDIwNTAtMDItMDEgMDA6
MDA6MDAgaW4gUGFjaWZpYyB0aW1lLAorICAgICBpZ25vcmluZyBsZWFwIHNlY29uZHMuICAqLwor
ICB1bnNpZ25lZCBsb25nIGludCBhbnN3ZXIgPSAyNTI3MzE1MjAwVUw7CisKKyAgc3RydWN0IHRt
IHRtOworICB0aW1lX3QgdDsKKyAgdG0udG1feWVhciA9IDIwNTAgLSAxOTAwOworICB0bS50bV9t
b24gPSAyIC0gMTsKKyAgdG0udG1fbWRheSA9IDE7CisgIHRtLnRtX2hvdXIgPSB0bS50bV9taW4g
PSB0bS50bV9zZWMgPSAwOworICB0bS50bV9pc2RzdCA9IC0xOworCisgIC8qIFVzZSB0aGUgcG9y
dGFibGUgUE9TSVguMSBzcGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIgor
ICAgICBpbnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0ZWN0
IHRoZSBidWcgZXZlbgorICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xz
b24gZXh0ZW5zaW9uLCBvciBkb24ndCBoYXZlIHRoZQorICAgICBmdWxsIHpvbmVpbmZvIHRhYmxl
cyBpbnN0YWxsZWQuICAqLworICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0x
MC41LjAiKTsKKworICB0ID0gbWt0aW1lICgmdG0pOworCisgIC8qIENoZWNrIHRoYXQgdGhlIHJl
c3VsdCBpcyBlaXRoZXIgYSBmYWlsdXJlLCBvciBjbG9zZSBlbm91Z2gKKyAgICAgdG8gdGhlIGNv
cnJlY3QgYW5zd2VyIHRoYXQgd2UgY2FuIGFzc3VtZSB0aGUgZGlzY3JlcGFuY3kgaXMKKyAgICAg
ZHVlIHRvIGxlYXAgc2Vjb25kcy4gICovCisgIHJldHVybiAodCA9PSAodGltZV90KSAtMQorCSAg
fHwgKDAgPCB0ICYmIGFuc3dlciAtIDEyMCA8PSB0ICYmIHQgPD0gYW5zd2VyICsgMTIwKSk7Cit9
CisKK2ludAorbWFpbiAoKQoreworICB0aW1lX3QgdCwgZGVsdGE7CisgIGludCBpLCBqOworCisg
IC8qIFRoaXMgdGVzdCBtYWtlcyBzb21lIGJ1Z2d5IG1rdGltZSBpbXBsZW1lbnRhdGlvbnMgbG9v
cC4KKyAgICAgR2l2ZSB1cCBhZnRlciA2MCBzZWNvbmRzOyBhIG1rdGltZSBzbG93ZXIgdGhhbiB0
aGF0CisgICAgIGlzbid0IHdvcnRoIHVzaW5nIGFueXdheS4gICovCisgIGFsYXJtICg2MCk7CisK
KyAgZm9yICg7OykKKyAgICB7CisgICAgICB0ID0gKHRpbWVfdF9tYXggPDwgMSkgKyAxOworICAg
ICAgaWYgKHQgPD0gdGltZV90X21heCkKKwlicmVhazsKKyAgICAgIHRpbWVfdF9tYXggPSB0Owor
ICAgIH0KKyAgdGltZV90X21pbiA9IC0gKCh0aW1lX3QpIH4gKHRpbWVfdCkgMCA9PSAodGltZV90
KSAtMSkgLSB0aW1lX3RfbWF4OworCisgIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyogYSBz
dWl0YWJsZSBwcmltZSBudW1iZXIgKi8KKyAgZm9yIChpID0gMDsgaSA8IE5fU1RSSU5HUzsgaSsr
KQorICAgIHsKKyAgICAgIGlmICh0el9zdHJpbmdzW2ldKQorCXB1dGVudiAoKGNoYXIqKSB0el9z
dHJpbmdzW2ldKTsKKworICAgICAgZm9yICh0ID0gMDsgdCA8PSB0aW1lX3RfbWF4IC0gZGVsdGE7
IHQgKz0gZGVsdGEpCisJaWYgKCEgbWt0aW1lX3Rlc3QgKHQpKQorCSAgcmV0dXJuIDE7CisgICAg
ICBpZiAoISAobWt0aW1lX3Rlc3QgKCh0aW1lX3QpIDEpCisJICAgICAmJiBta3RpbWVfdGVzdCAo
KHRpbWVfdCkgKDYwICogNjApKQorCSAgICAgJiYgbWt0aW1lX3Rlc3QgKCh0aW1lX3QpICg2MCAq
IDYwICogMjQpKSkpCisJcmV0dXJuIDE7CisKKyAgICAgIGZvciAoaiA9IDE7IDsgaiA8PD0gMSkK
KwlpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQorCSAgcmV0dXJuIDE7CisJZWxzZSBpZiAoSU5UX01B
WCAvIDIgPCBqKQorCSAgYnJlYWs7CisgICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKElOVF9NQVgp
KQorCXJldHVybiAxOworICAgIH0KKyAgcmV0dXJuICEgKGlyaXhfNl80X2J1ZyAoKSAmJiBzcHJp
bmdfZm9yd2FyZF9nYXAgKCkgJiYgeWVhcl8yMDUwX3Rlc3QgKCkpOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY193b3JraW5nX21r
dGltZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubworZmkKK3JtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfd29ya2lu
Z19ta3RpbWUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBta3RpbWUu
JGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIG1rdGltZS4kYWNfb2Jq
ZXh0IgorIDs7Citlc2FjCisKK2ZpCisKKworCisKKworCitmb3IgYWNfZnVuYyBpbiBnZXRwYWdl
c2l6ZQorZG8gOgorICBhY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6ZSIg
ImFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNp
emUiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUg
SEFWRV9HRVRQQUdFU0laRSAxCitfQUNFT0YKKworZmkKK2RvbmUKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBtbWFwIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0g
eWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD1ubworZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAorLyogbWFsbG9jIG1pZ2h0IGhhdmUgYmVl
biByZW5hbWVkIGFzIHJwbF9tYWxsb2MuICovCisjdW5kZWYgbWFsbG9jCisKKy8qIFRoYW5rcyB0
byBNaWtlIEhhZXJ0ZWwgYW5kIEppbSBBdmVyYSBmb3IgdGhpcyB0ZXN0LgorICAgSGVyZSBpcyBh
IG1hdHJpeCBvZiBtbWFwIHBvc3NpYmlsaXRpZXM6CisJbW1hcCBwcml2YXRlIG5vdCBmaXhlZAor
CW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgY3VycmVudGx5IHVubWFwcGVkCisJbW1h
cCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJlYWR5IG1hcHBlZAorCW1tYXAgc2hhcmVk
IG5vdCBmaXhlZAorCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5t
YXBwZWQKKwltbWFwIHNoYXJlZCBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKKyAg
IEZvciBwcml2YXRlIG1hcHBpbmdzLCB3ZSBzaG91bGQgdmVyaWZ5IHRoYXQgY2hhbmdlcyBjYW5u
b3QgYmUgcmVhZCgpCisgICBiYWNrIGZyb20gdGhlIGZpbGUsIG5vciBtbWFwJ3MgYmFjayBmcm9t
IHRoZSBmaWxlIGF0IGEgZGlmZmVyZW50CisgICBhZGRyZXNzLiAgKFRoZXJlIGhhdmUgYmVlbiBz
eXN0ZW1zIHdoZXJlIHByaXZhdGUgd2FzIG5vdCBjb3JyZWN0bHkKKyAgIGltcGxlbWVudGVkIGxp
a2UgdGhlIGluZmFtb3VzIGkzODYgc3ZyNC4wLCBhbmQgc3lzdGVtcyB3aGVyZSB0aGUKKyAgIFZN
IHBhZ2UgY2FjaGUgd2FzIG5vdCBjb2hlcmVudCB3aXRoIHRoZSBmaWxlIHN5c3RlbSBidWZmZXIg
Y2FjaGUKKyAgIGxpa2UgZWFybHkgdmVyc2lvbnMgb2YgRnJlZUJTRCBhbmQgcG9zc2libHkgY29u
dGVtcG9yYXJ5IE5ldEJTRC4pCisgICBGb3Igc2hhcmVkIG1hcHBpbmdzLCB3ZSBzaG91bGQgY29u
dmVyc2VseSB2ZXJpZnkgdGhhdCBjaGFuZ2VzIGdldAorICAgcHJvcGFnYXRlZCBiYWNrIHRvIGFs
bCB0aGUgcGxhY2VzIHRoZXkncmUgc3VwcG9zZWQgdG8gYmUuCisKKyAgIEdyZXAgd2FudHMgcHJp
dmF0ZSBmaXhlZCBhbHJlYWR5IG1hcHBlZC4KKyAgIFRoZSBtYWluIHRoaW5ncyBncmVwIG5lZWRz
IHRvIGtub3cgYWJvdXQgbW1hcCBhcmU6CisgICAqIGRvZXMgaXQgZXhpc3QgYW5kIGlzIGl0IHNh
ZmUgdG8gd3JpdGUgaW50byB0aGUgbW1hcCdkIGFyZWEKKyAgICogaG93IHRvIHVzZSBpdCAoQlNE
IHZhcmlhbnRzKSAgKi8KKworI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5jbHVkZSA8c3lzL21tYW4u
aD4KKworI2lmICFkZWZpbmVkIFNURENfSEVBREVSUyAmJiAhZGVmaW5lZCBIQVZFX1NURExJQl9I
CitjaGFyICptYWxsb2MgKCk7CisjZW5kaWYKKworLyogVGhpcyBtZXNzIHdhcyBjb3BpZWQgZnJv
bSB0aGUgR05VIGdldHBhZ2VzaXplLmguICAqLworI2lmbmRlZiBIQVZFX0dFVFBBR0VTSVpFCisj
IGlmZGVmIF9TQ19QQUdFU0laRQorIyAgZGVmaW5lIGdldHBhZ2VzaXplKCkgc3lzY29uZihfU0Nf
UEFHRVNJWkUpCisjIGVsc2UgLyogbm8gX1NDX1BBR0VTSVpFICovCisjICBpZmRlZiBIQVZFX1NZ
U19QQVJBTV9ICisjICAgaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjICAgaWZkZWYgRVhFQ19QQUdF
U0laRQorIyAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBFWEVDX1BBR0VTSVpFCisjICAgZWxzZSAv
KiBubyBFWEVDX1BBR0VTSVpFICovCisjICAgIGlmZGVmIE5CUEcKKyMgICAgIGRlZmluZSBnZXRw
YWdlc2l6ZSgpIE5CUEcgKiBDTFNJWkUKKyMgICAgIGlmbmRlZiBDTFNJWkUKKyMgICAgICBkZWZp
bmUgQ0xTSVpFIDEKKyMgICAgIGVuZGlmIC8qIG5vIENMU0laRSAqLworIyAgICBlbHNlIC8qIG5v
IE5CUEcgKi8KKyMgICAgIGlmZGVmIE5CUEMKKyMgICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBO
QlBDCisjICAgICBlbHNlIC8qIG5vIE5CUEMgKi8KKyMgICAgICBpZmRlZiBQQUdFU0laRQorIyAg
ICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBQQUdFU0laRQorIyAgICAgIGVuZGlmIC8qIFBBR0VT
SVpFICovCisjICAgICBlbmRpZiAvKiBubyBOQlBDICovCisjICAgIGVuZGlmIC8qIG5vIE5CUEcg
Ki8KKyMgICBlbmRpZiAvKiBubyBFWEVDX1BBR0VTSVpFICovCisjICBlbHNlIC8qIG5vIEhBVkVf
U1lTX1BBUkFNX0ggKi8KKyMgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSA4MTkyCS8qIHB1bnQgdG90
YWxseSAqLworIyAgZW5kaWYgLyogbm8gSEFWRV9TWVNfUEFSQU1fSCAqLworIyBlbmRpZiAvKiBu
byBfU0NfUEFHRVNJWkUgKi8KKworI2VuZGlmIC8qIG5vIEhBVkVfR0VUUEFHRVNJWkUgKi8KKwor
aW50CittYWluICgpCit7CisgIGNoYXIgKmRhdGEsICpkYXRhMiwgKmRhdGEzOworICBjb25zdCBj
aGFyICpjZGF0YTI7CisgIGludCBpLCBwYWdlc2l6ZTsKKyAgaW50IGZkLCBmZDI7CisKKyAgcGFn
ZXNpemUgPSBnZXRwYWdlc2l6ZSAoKTsKKworICAvKiBGaXJzdCwgbWFrZSBhIGZpbGUgd2l0aCBz
b21lIGtub3duIGdhcmJhZ2UgaW4gaXQuICovCisgIGRhdGEgPSAoY2hhciAqKSBtYWxsb2MgKHBh
Z2VzaXplKTsKKyAgaWYgKCFkYXRhKQorICAgIHJldHVybiAxOworICBmb3IgKGkgPSAwOyBpIDwg
cGFnZXNpemU7ICsraSkKKyAgICAqKGRhdGEgKyBpKSA9IHJhbmQgKCk7CisgIHVtYXNrICgwKTsK
KyAgZmQgPSBjcmVhdCAoImNvbmZ0ZXN0Lm1tYXAiLCAwNjAwKTsKKyAgaWYgKGZkIDwgMCkKKyAg
ICByZXR1cm4gMjsKKyAgaWYgKHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2VzaXpl
KQorICAgIHJldHVybiAzOworICBjbG9zZSAoZmQpOworCisgIC8qIE5leHQsIGNoZWNrIHRoYXQg
dGhlIHRhaWwgb2YgYSBwYWdlIGlzIHplcm8tZmlsbGVkLiAgRmlsZSBtdXN0IGhhdmUKKyAgICAg
bm9uLXplcm8gbGVuZ3RoLCBvdGhlcndpc2Ugd2UgcmlzayBTSUdCVVMgZm9yIGVudGlyZSBwYWdl
LiAgKi8KKyAgZmQyID0gb3BlbiAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQgfCBP
X1RSVU5DLCAwNjAwKTsKKyAgaWYgKGZkMiA8IDApCisgICAgcmV0dXJuIDQ7CisgIGNkYXRhMiA9
ICIiOworICBpZiAod3JpdGUgKGZkMiwgY2RhdGEyLCAxKSAhPSAxKQorICAgIHJldHVybiA1Owor
ICBkYXRhMiA9IChjaGFyICopIG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dS
SVRFLCBNQVBfU0hBUkVELCBmZDIsIDBMKTsKKyAgaWYgKGRhdGEyID09IE1BUF9GQUlMRUQpCisg
ICAgcmV0dXJuIDY7CisgIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgIGlmICgq
KGRhdGEyICsgaSkpCisgICAgICByZXR1cm4gNzsKKyAgY2xvc2UgKGZkMik7CisgIGlmIChtdW5t
YXAgKGRhdGEyLCBwYWdlc2l6ZSkpCisgICAgcmV0dXJuIDg7CisKKyAgLyogTmV4dCwgdHJ5IHRv
IG1tYXAgdGhlIGZpbGUgYXQgYSBmaXhlZCBhZGRyZXNzIHdoaWNoIGFscmVhZHkgaGFzCisgICAg
IHNvbWV0aGluZyBlbHNlIGFsbG9jYXRlZCBhdCBpdC4gIElmIHdlIGNhbiwgYWxzbyBtYWtlIHN1
cmUgdGhhdAorICAgICB3ZSBzZWUgdGhlIHNhbWUgZ2FyYmFnZS4gICovCisgIGZkID0gb3BlbiAo
ImNvbmZ0ZXN0Lm1tYXAiLCBPX1JEV1IpOworICBpZiAoZmQgPCAwKQorICAgIHJldHVybiA5Owor
ICBpZiAoZGF0YTIgIT0gbW1hcCAoZGF0YTIsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dS
SVRFLAorCQkgICAgIE1BUF9QUklWQVRFIHwgTUFQX0ZJWEVELCBmZCwgMEwpKQorICAgIHJldHVy
biAxMDsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAgaWYgKCooZGF0YSAr
IGkpICE9ICooZGF0YTIgKyBpKSkKKyAgICAgIHJldHVybiAxMTsKKworICAvKiBGaW5hbGx5LCBt
YWtlIHN1cmUgdGhhdCBjaGFuZ2VzIHRvIHRoZSBtYXBwZWQgYXJlYSBkbyBub3QKKyAgICAgcGVy
Y29sYXRlIGJhY2sgdG8gdGhlIGZpbGUgYXMgc2VlbiBieSByZWFkKCkuICAoVGhpcyBpcyBhIGJ1
ZyBvbgorICAgICBzb21lIHZhcmlhbnRzIG9mIGkzODYgc3ZyNC4wLikgICovCisgIGZvciAoaSA9
IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgICooZGF0YTIgKyBpKSA9ICooZGF0YTIgKyBpKSAr
IDE7CisgIGRhdGEzID0gKGNoYXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7CisgIGlmICghZGF0YTMp
CisgICAgcmV0dXJuIDEyOworICBpZiAocmVhZCAoZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0gcGFn
ZXNpemUpCisgICAgcmV0dXJuIDEzOworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkK
KyAgICBpZiAoKihkYXRhICsgaSkgIT0gKihkYXRhMyArIGkpKQorICAgICAgcmV0dXJuIDE0Owor
ICBjbG9zZSAoZmQpOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVu
ICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9eWVzCitl
bHNlCisgIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9bm8KK2ZpCitybSAtZiBjb3JlICou
Y29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBc
CisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Citm
aQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVu
Y19tbWFwX2ZpeGVkX21hcHBlZCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX21tYXBfZml4
ZWRfbWFwcGVkID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfTU1BUCAxIiA+
PmNvbmZkZWZzLmgKKworZmkKK3JtIC1mIGNvbmZ0ZXN0Lm1tYXAgY29uZnRlc3QudHh0CisKK2Zv
ciBhY19oZWFkZXIgaW4gc3RkbGliLmgKK2RvIDoKKyAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9u
Z3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiAiJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgPSB4eWVz
OyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NURExJ
Ql9IIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgcmVhbGxvYyIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSByZWFsbG9j
Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIk
Y3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25v
bm51bGw9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmIGRlZmluZWQgU1REQ19IRUFERVJTIHx8
IGRlZmluZWQgSEFWRV9TVERMSUJfSAorIyBpbmNsdWRlIDxzdGRsaWIuaD4KKyNlbHNlCitjaGFy
ICpyZWFsbG9jICgpOworI2VuZGlmCisKK2ludAorbWFpbiAoKQoreworcmV0dXJuICEgcmVhbGxv
YyAoMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPXllcwor
ZWxzZQorICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCitmaQorcm0gLWYgY29yZSAq
LmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQg
XAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAor
ZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1
bmNfcmVhbGxvY18wX25vbm51bGwiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19yZWFsbG9j
XzBfbm9ubnVsbCA9IHllczsgdGhlbiA6CisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfUkVBTExP
QyAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQorICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX1JFQUxM
T0MgMCIgPj5jb25mZGVmcy5oCisKKyAgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIHJlYWxs
b2MuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIHJlYWxsb2MuJGFj
X29iamV4dCIKKyA7OworZXNhYworCisKKyRhc19lY2hvICIjZGVmaW5lIHJlYWxsb2MgcnBsX3Jl
YWxsb2MiID4+Y29uZmRlZnMuaAorCitmaQorCisKKyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4iID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3Rybmxlbi4uLiAiID4mNjsgfQoraWYgJHthY19j
dl9mdW5jX3N0cm5sZW5fd29ya2luZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKKyAgIyBHdWVzcyBubyBvbiBBSVggc3lzdGVtcywgeWVzIG90aGVyd2lzZS4KKwkJY2Fz
ZSAiJGhvc3Rfb3MiIGluCisJCSAgYWl4KikgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9bm87
OworCQkgICopICAgIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllczs7CisJCWVzYWMKK2Vs
c2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2ludAorbWFpbiAoKQorewor
CisjZGVmaW5lIFMgImZvb2JhciIKKyNkZWZpbmUgU19MRU4gKHNpemVvZiBTIC0gMSkKKworICAv
KiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYnVnZ3k6IHRoYXQgb2YgQUlYIDQuMyB3
b3VsZAorICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMuICAqLworCisgIGludCBpOworICBm
b3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCisgICAgeworICAgICAgaW50IGV4cGVjdGVk
ID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsKKyAgICAgIGlmIChzdHJubGVuIChTLCBpKSAhPSBl
eHBlY3RlZCkKKwlyZXR1cm4gMTsKKyAgICB9CisgIHJldHVybiAwOworCisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19zdHJubGVu
X3dvcmtpbmc9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5v
dXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29u
ZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu
ZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nIiA+JjY7IH0KK3Rl
c3QgJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nID0gbm8gJiYgY2FzZSAiICRMSUJPQkpTICIg
aW4KKyAgKiIgc3Rybmxlbi4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9C
SlMgc3Rybmxlbi4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKKworeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBzdHJ0b2QiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9kLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X2Z1bmNfc3RydG9kKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g
OgorICBhY19jdl9mdW5jX3N0cnRvZD1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKyRhY19pbmNs
dWRlc19kZWZhdWx0CisjaWZuZGVmIHN0cnRvZAorZG91YmxlIHN0cnRvZCAoKTsKKyNlbmRpZgor
aW50CittYWluKCkKK3sKKyAgeworICAgIC8qIFNvbWUgdmVyc2lvbnMgb2YgTGludXggc3RydG9k
IG1pcy1wYXJzZSBzdHJpbmdzIHdpdGggbGVhZGluZyAnKycuICAqLworICAgIGNoYXIgKnN0cmlu
ZyA9ICIgKzY5IjsKKyAgICBjaGFyICp0ZXJtOworICAgIGRvdWJsZSB2YWx1ZTsKKyAgICB2YWx1
ZSA9IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7CisgICAgaWYgKHZhbHVlICE9IDY5IHx8IHRlcm0g
IT0gKHN0cmluZyArIDQpKQorICAgICAgcmV0dXJuIDE7CisgIH0KKworICB7CisgICAgLyogVW5k
ZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5zIHRoZSB3cm9uZyB2YWx1ZSBmb3IgdGhlCisg
ICAgICAgdGVybWluYXRpbmcgY2hhcmFjdGVyIHVuZGVyIHNvbWUgY29uZGl0aW9ucy4gICovCisg
ICAgY2hhciAqc3RyaW5nID0gIk5hTiI7CisgICAgY2hhciAqdGVybTsKKyAgICBzdHJ0b2QgKHN0
cmluZywgJnRlcm0pOworICAgIGlmICh0ZXJtICE9IHN0cmluZyAmJiAqKHRlcm0gLSAxKSA9PSAw
KQorICAgICAgcmV0dXJuIDE7CisgIH0KKyAgcmV0dXJuIDA7Cit9CisKK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfc3RydG9kPXllcwor
ZWxzZQorICBhY19jdl9mdW5jX3N0cnRvZD1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUu
Y29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1
bmNfc3RydG9kIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNjsgfQoraWYg
dGVzdCAkYWNfY3ZfZnVuY19zdHJ0b2QgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBp
bgorICAqIiBzdHJ0b2QuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpT
IHN0cnRvZC4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJ
TkVOTyIgInBvdyIgImFjX2N2X2Z1bmNfcG93IgoraWYgdGVzdCAieCRhY19jdl9mdW5jX3BvdyIg
PSB4eWVzOyB0aGVuIDoKKworZmkKKworaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBubzsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBwb3cgaW4gLWxtIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBwb3cgaW4gLWxtLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9tX3Bvdys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKK0xJQlM9Ii1sbSAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0Mg
aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVz
ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFu
ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lm
ZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgcG93ICgpOworaW50Citt
YWluICgpCit7CityZXR1cm4gcG93ICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9tX3Bvdz15
ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX21fcG93PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0
LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9tX3BvdyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2xpYl9tX3BvdyIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9tX3BvdyIgPSB4eWVzOyB0aGVuIDoKKyAgUE9XX0xJQj0tbG0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJy
YXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mNQorJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRlZmluaXRpb24gb2YgcG93
IiA+JjI7fQorZmkKKworZmkKKworZmkKKworZm9yIGFjX2Z1bmMgaW4gIFwKKyAgICAgICAgICAg
ICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3luYyBmdHJ1
bmNhdGUgXAorICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhvc3RuYW1l
IGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAgaW5ldF9udG9hIGlz
YXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKKyAgICAgICAg
ICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2Vs
ZWN0IHNldGVudiBcCisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3RyY2hyIHN0
cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAgICAgIHN0cnBicmsg
c3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0IFwKKyAg
ICAgICAgICAgICAgICB1bmFtZSBcCisKK2RvIDoKKyAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNf
Y3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5F
Tk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3Zh
ciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZp
bmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitm
aQorZG9uZQorCisKK2NhdCA+Y29uZmNhY2hlIDw8XF9BQ0VPRgorIyBUaGlzIGZpbGUgaXMgYSBz
aGVsbCBzY3JpcHQgdGhhdCBjYWNoZXMgdGhlIHJlc3VsdHMgb2YgY29uZmlndXJlCisjIHRlc3Rz
IHJ1biBvbiB0aGlzIHN5c3RlbSBzbyB0aGV5IGNhbiBiZSBzaGFyZWQgYmV0d2VlbiBjb25maWd1
cmUKKyMgc2NyaXB0cyBhbmQgY29uZmlndXJlIHJ1bnMsIHNlZSBjb25maWd1cmUncyBvcHRpb24g
LS1jb25maWctY2FjaGUuCisjIEl0IGlzIG5vdCB1c2VmdWwgb24gb3RoZXIgc3lzdGVtcy4gIElm
IGl0IGNvbnRhaW5zIHJlc3VsdHMgeW91IGRvbid0CisjIHdhbnQgdG8ga2VlcCwgeW91IG1heSBy
ZW1vdmUgb3IgZWRpdCBpdC4KKyMKKyMgY29uZmlnLnN0YXR1cyBvbmx5IHBheXMgYXR0ZW50aW9u
IHRvIHRoZSBjYWNoZSBmaWxlIGlmIHlvdSBnaXZlIGl0CisjIHRoZSAtLXJlY2hlY2sgb3B0aW9u
IHRvIHJlcnVuIGNvbmZpZ3VyZS4KKyMKKyMgYGFjX2N2X2Vudl9mb28nIHZhcmlhYmxlcyAoc2V0
IG9yIHVuc2V0KSB3aWxsIGJlIG92ZXJyaWRkZW4gd2hlbgorIyBsb2FkaW5nIHRoaXMgZmlsZSwg
b3RoZXIgKnVuc2V0KiBgYWNfY3ZfZm9vJyB3aWxsIGJlIGFzc2lnbmVkIHRoZQorIyBmb2xsb3dp
bmcgdmFsdWVzLgorCitfQUNFT0YKKworIyBUaGUgZm9sbG93aW5nIHdheSBvZiB3cml0aW5nIHRo
ZSBjYWNoZSBtaXNoYW5kbGVzIG5ld2xpbmVzIGluIHZhbHVlcywKKyMgYnV0IHdlIGtub3cgb2Yg
bm8gd29ya2Fyb3VuZCB0aGF0IGlzIHNpbXBsZSwgcG9ydGFibGUsIGFuZCBlZmZpY2llbnQuCisj
IFNvLCB3ZSBraWxsIHZhcmlhYmxlcyBjb250YWluaW5nIG5ld2xpbmVzLgorIyBVbHRyaXggc2gg
c2V0IHdyaXRlcyB0byBzdGRlcnIgYW5kIGNhbid0IGJlIHJlZGlyZWN0ZWQgZGlyZWN0bHksCisj
IGFuZCBzZXRzIHRoZSBoaWdoIGJpdCBpbiB0aGUgY2FjaGUgZmlsZSB1bmxlc3Mgd2UgYXNzaWdu
IHRvIHRoZSB2YXJzLgorKAorICBmb3IgYWNfdmFyIGluIGAoc2V0KSAyPiYxIHwgc2VkIC1uICdz
L15cKFthLXpBLVpfXVthLXpBLVowLTlfXSpcKT0uKi9cMS9wJ2A7IGRvCisgICAgZXZhbCBhY192
YWw9XCQkYWNfdmFyCisgICAgY2FzZSAkYWNfdmFsIGluICMoCisgICAgKiR7YXNfbmx9KikKKyAg
ICAgIGNhc2UgJGFjX3ZhciBpbiAjKAorICAgICAgKl9jdl8qKSB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IGNhY2hlIHZhcmlhYmxlICRhY192YXIgY29u
dGFpbnMgYSBuZXdsaW5lIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IGNhY2hlIHZh
cmlhYmxlICRhY192YXIgY29udGFpbnMgYSBuZXdsaW5lIiA+JjI7fSA7OworICAgICAgZXNhYwor
ICAgICAgY2FzZSAkYWNfdmFyIGluICMoCisgICAgICBfIHwgSUZTIHwgYXNfbmwpIDs7ICMoCisg
ICAgICBCQVNIX0FSR1YgfCBCQVNIX1NPVVJDRSkgZXZhbCAkYWNfdmFyPSA7OyAjKAorICAgICAg
KikgeyBldmFsICRhY192YXI9OyB1bnNldCAkYWNfdmFyO30gOzsKKyAgICAgIGVzYWMgOzsKKyAg
ICBlc2FjCisgIGRvbmUKKworICAoc2V0KSAyPiYxIHwKKyAgICBjYXNlICRhc19ubGAoYWNfc3Bh
Y2U9JyAnOyBzZXQpIDI+JjFgIGluICMoCisgICAgKiR7YXNfbmx9YWNfc3BhY2U9XCAqKQorICAg
ICAgIyBgc2V0JyBkb2VzIG5vdCBxdW90ZSBjb3JyZWN0bHksIHNvIGFkZCBxdW90ZXM6IGRvdWJs
ZS1xdW90ZQorICAgICAgIyBzdWJzdGl0dXRpb24gdHVybnMgXFxcXCBpbnRvIFxcLCBhbmQgc2Vk
IHR1cm5zIFxcIGludG8gXC4KKyAgICAgIHNlZCAtbiBcCisJInMvJy8nXFxcXCcnL2c7CisJICBz
L15cXChbXyRhc19jcl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSpcXCk9XFwoLipcXCkvXFwx
PSdcXDInL3AiCisgICAgICA7OyAjKAorICAgICopCisgICAgICAjIGBzZXQnIHF1b3RlcyBjb3Jy
ZWN0bHkgYXMgcmVxdWlyZWQgYnkgUE9TSVgsIHNvIGRvIG5vdCBhZGQgcXVvdGVzLgorICAgICAg
c2VkIC1uICIvXltfJGFzX2NyX2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKj0vcCIKKyAgICAg
IDs7CisgICAgZXNhYyB8CisgICAgc29ydAorKSB8CisgIHNlZCAnCisgICAgIC9eYWNfY3ZfZW52
Xy9iIGVuZAorICAgICB0IGNsZWFyCisgICAgIDpjbGVhcgorICAgICBzL15cKFtePV0qXCk9XCgu
Klt7fV0uKlwpJC90ZXN0ICIke1wxK3NldH0iID0gc2V0IHx8ICYvCisgICAgIHQgZW5kCisgICAg
IHMvXlwoW149XSpcKT1cKC4qXCkkL1wxPSR7XDE9XDJ9LworICAgICA6ZW5kJyA+PmNvbmZjYWNo
ZQoraWYgZGlmZiAiJGNhY2hlX2ZpbGUiIGNvbmZjYWNoZSA+L2Rldi9udWxsIDI+JjE7IHRoZW4g
OjsgZWxzZQorICBpZiB0ZXN0IC13ICIkY2FjaGVfZmlsZSI7IHRoZW4KKyAgICBpZiB0ZXN0ICJ4
JGNhY2hlX2ZpbGUiICE9ICJ4L2Rldi9udWxsIjsgdGhlbgorICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiB1cGRhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY1
CiskYXNfZWNobyAiJGFzX21lOiB1cGRhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAg
ICAgIGlmIHRlc3QgISAtZiAiJGNhY2hlX2ZpbGUiIHx8IHRlc3QgLWggIiRjYWNoZV9maWxlIjsg
dGhlbgorCWNhdCBjb25mY2FjaGUgPiIkY2FjaGVfZmlsZSIKKyAgICAgIGVsc2UKKyAgICAgICAg
Y2FzZSAkY2FjaGVfZmlsZSBpbiAjKAorICAgICAgICAqLyogfCA/OiopCisJICBtdiAtZiBjb25m
Y2FjaGUgIiRjYWNoZV9maWxlIiQkICYmCisJICBtdiAtZiAiJGNhY2hlX2ZpbGUiJCQgIiRjYWNo
ZV9maWxlIiA7OyAjKAorICAgICAgICAqKQorCSAgbXYgLWYgY29uZmNhY2hlICIkY2FjaGVfZmls
ZSIgOzsKKwllc2FjCisgICAgICBmaQorICAgIGZpCisgIGVsc2UKKyAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IG5vdCB1cGRhdGluZyB1bndyaXRhYmxlIGNhY2hl
ICRjYWNoZV9maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IG5vdCB1cGRhdGluZyB1bndyaXRh
YmxlIGNhY2hlICRjYWNoZV9maWxlIiA+JjY7fQorICBmaQorZmkKK3JtIC1mIGNvbmZjYWNoZQor
Cit0ZXN0ICJ4JHByZWZpeCIgPSB4Tk9ORSAmJiBwcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4Cisj
IExldCBtYWtlIGV4cGFuZCBleGVjX3ByZWZpeC4KK3Rlc3QgIngkZXhlY19wcmVmaXgiID0geE5P
TkUgJiYgZXhlY19wcmVmaXg9JyR7cHJlZml4fScKKworREVGUz0tREhBVkVfQ09ORklHX0gKKwor
YWNfbGlib2Jqcz0KK2FjX2x0bGlib2Jqcz0KK1U9Citmb3IgYWNfaSBpbiA6ICRMSUJPQkpTOyBk
byB0ZXN0ICJ4JGFjX2kiID0geDogJiYgY29udGludWUKKyAgIyAxLiBSZW1vdmUgdGhlIGV4dGVu
c2lvbiwgYW5kICRVIGlmIGFscmVhZHkgaW5zdGFsbGVkLgorICBhY19zY3JpcHQ9J3MvXCRVXC4v
Li87cy9cLm8kLy87cy9cLm9iaiQvLycKKyAgYWNfaT1gJGFzX2VjaG8gIiRhY19pIiB8IHNlZCAi
JGFjX3NjcmlwdCJgCisgICMgMi4gUHJlcGVuZCBMSUJPQkpESVIuICBXaGVuIHVzZWQgd2l0aCBh
dXRvbWFrZT49MS4xMCBMSUJPQkpESVIKKyAgIyAgICB3aWxsIGJlIHNldCB0byB0aGUgZGlyZWN0
b3J5IHdoZXJlIExJQk9CSlMgb2JqZWN0cyBhcmUgYnVpbHQuCisgIGFzX2ZuX2FwcGVuZCBhY19s
aWJvYmpzICIgXCR7TElCT0JKRElSfSRhY19pXCRVLiRhY19vYmpleHQiCisgIGFzX2ZuX2FwcGVu
ZCBhY19sdGxpYm9ianMgIiBcJHtMSUJPQkpESVJ9JGFjX2kiJyRVLmxvJworZG9uZQorTElCT0JK
Uz0kYWNfbGlib2JqcworCitMVExJQk9CSlM9JGFjX2x0bGlib2JqcworCisKKworOiAiJHtDT05G
SUdfU1RBVFVTPS4vY29uZmlnLnN0YXR1c30iCithY193cml0ZV9mYWlsPTAKK2FjX2NsZWFuX2Zp
bGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCithY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVz
ICRDT05GSUdfU1RBVFVTIgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBjcmVhdGlu
ZyAkQ09ORklHX1NUQVRVUyIgPiY2O30KK2FzX3dyaXRlX2ZhaWw9MAorY2F0ID4kQ09ORklHX1NU
QVRVUyA8PF9BU0VPRiB8fCBhc193cml0ZV9mYWlsPTEKKyMhICRTSEVMTAorIyBHZW5lcmF0ZWQg
YnkgJGFzX21lLgorIyBSdW4gdGhpcyBmaWxlIHRvIHJlY3JlYXRlIHRoZSBjdXJyZW50IGNvbmZp
Z3VyYXRpb24uCisjIENvbXBpbGVyIG91dHB1dCBwcm9kdWNlZCBieSBjb25maWd1cmUsIHVzZWZ1
bCBmb3IgZGVidWdnaW5nCisjIGNvbmZpZ3VyZSwgaXMgaW4gY29uZmlnLmxvZyBpZiBpdCBleGlz
dHMuCisKK2RlYnVnPWZhbHNlCithY19jc19yZWNoZWNrPWZhbHNlCithY19jc19zaWxlbnQ9ZmFs
c2UKKworU0hFTEw9XCR7Q09ORklHX1NIRUxMLSRTSEVMTH0KK2V4cG9ydCBTSEVMTAorX0FTRU9G
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQVNFT0YgfHwgYXNfd3JpdGVfZmFpbD0xCisjIyAt
LS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTTRzaCBJbml0aWFsaXphdGlvbi4gIyMKKyMjIC0t
LS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMgQmUgbW9yZSBCb3VybmUgY29tcGF0aWJsZQorRFVB
TENBU0U9MTsgZXhwb3J0IERVQUxDQVNFICMgZm9yIE1LUyBzaAoraWYgdGVzdCAtbiAiJHtaU0hf
VkVSU0lPTitzZXR9IiAmJiAoZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAg
ZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3
b3JkIHNwbGl0dGluZyBvbiAkezErIiRAIn0sIHdoaWNoCisgICMgaXMgY29udHJhcnkgdG8gb3Vy
IHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1nICckezErIiRAIn0nPSci
JEAiJworICBzZXRvcHQgTk9fR0xPQl9TVUJTVAorZWxzZQorICBjYXNlIGAoc2V0IC1vKSAyPi9k
ZXYvbnVsbGAgaW4gIygKKyAgKnBvc2l4KikgOgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAq
KSA6CisgICAgIDs7Citlc2FjCitmaQorCisKK2FzX25sPScKKycKK2V4cG9ydCBhc19ubAorIyBQ
cmludGluZyBhIGxvbmcgc3RyaW5nIGNyYXNoZXMgU29sYXJpcyA3IC91c3IvYmluL3ByaW50Zi4K
K2FzX2VjaG89J1xcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFwn
Cithc19lY2hvPSRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8KK2FzX2Vj
aG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCisjIFBy
ZWZlciBhIGtzaCBzaGVsbCBidWlsdGluIG92ZXIgYW4gZXh0ZXJuYWwgcHJpbnRmIHByb2dyYW0g
b24gU29sYXJpcywKKyMgYnV0IHdpdGhvdXQgd2FzdGluZyBmb3JrcyBmb3IgYmFzaCBvciB6c2gu
CitpZiB0ZXN0IC16ICIkQkFTSF9WRVJTSU9OJFpTSF9WRVJTSU9OIiBcCisgICAgJiYgKHRlc3Qg
IlhgcHJpbnQgLXIgLS0gJGFzX2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9kZXYvbnVsbDsgdGhl
bgorICBhc19lY2hvPSdwcmludCAtciAtLScKKyAgYXNfZWNob19uPSdwcmludCAtcm4gLS0nCitl
bGlmICh0ZXN0ICJYYHByaW50ZiAlcyAkYXNfZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9u
dWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50ZiAlc1xuJworICBhc19lY2hvX249J3ByaW50ZiAl
cycKK2Vsc2UKKyAgaWYgdGVzdCAiWGAoL3Vzci91Y2IvZWNobyAtbiAtbiAkYXNfZWNobykgMj4v
ZGV2L251bGxgIiA9ICJYLW4gJGFzX2VjaG8iOyB0aGVuCisgICAgYXNfZWNob19ib2R5PSdldmFs
IC91c3IvdWNiL2VjaG8gLW4gIiQxJGFzX25sIicKKyAgICBhc19lY2hvX249Jy91c3IvdWNiL2Vj
aG8gLW4nCisgIGVsc2UKKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgZXhwciAiWCQxIiA6ICJYXFwo
LipcXCkiJworICAgIGFzX2VjaG9fbl9ib2R5PSdldmFsCisgICAgICBhcmc9JDE7CisgICAgICBj
YXNlICRhcmcgaW4gIygKKyAgICAgICoiJGFzX25sIiopCisJZXhwciAiWCRhcmciIDogIlhcXCgu
KlxcKSRhc19ubCI7CisJYXJnPWBleHByICJYJGFyZyIgOiAiLiokYXNfbmxcXCguKlxcKSJgOzsK
KyAgICAgIGVzYWM7CisgICAgICBleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpIiB8IHRyIC1kICIk
YXNfbmwiCisgICAgJworICAgIGV4cG9ydCBhc19lY2hvX25fYm9keQorICAgIGFzX2VjaG9fbj0n
c2ggLWMgJGFzX2VjaG9fbl9ib2R5IGFzX2VjaG8nCisgIGZpCisgIGV4cG9ydCBhc19lY2hvX2Jv
ZHkKKyAgYXNfZWNobz0nc2ggLWMgJGFzX2VjaG9fYm9keSBhc19lY2hvJworZmkKKworIyBUaGUg
dXNlciBpcyBhbHdheXMgcmlnaHQuCitpZiB0ZXN0ICIke1BBVEhfU0VQQVJBVE9SK3NldH0iICE9
IHNldDsgdGhlbgorICBQQVRIX1NFUEFSQVRPUj06CisgIChQQVRIPScvYmluOy9iaW4nOyBGUEFU
SD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVsbCAyPiYxICYmIHsKKyAgICAoUEFUSD0nL2Jpbjov
YmluJzsgRlBBVEg9JFBBVEg7IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSB8fAorICAgICAgUEFU
SF9TRVBBUkFUT1I9JzsnCisgIH0KK2ZpCisKKworIyBJRlMKKyMgV2UgbmVlZCBzcGFjZSwgdGFi
IGFuZCBuZXcgbGluZSwgaW4gcHJlY2lzZWx5IHRoYXQgb3JkZXIuICBRdW90aW5nIGlzCisjIHRo
ZXJlIHRvIHByZXZlbnQgZWRpdG9ycyBmcm9tIGNvbXBsYWluaW5nIGFib3V0IHNwYWNlLXRhYi4K
KyMgKElmIF9BU19QQVRIX1dBTEsgd2VyZSBjYWxsZWQgd2l0aCBJRlMgdW5zZXQsIGl0IHdvdWxk
IGRpc2FibGUgd29yZAorIyBzcGxpdHRpbmcgYnkgc2V0dGluZyBJRlMgdG8gZW1wdHkgdmFsdWUu
KQorSUZTPSIgIiIJJGFzX25sIgorCisjIEZpbmQgd2hvIHdlIGFyZS4gIExvb2sgaW4gdGhlIHBh
dGggaWYgd2UgY29udGFpbiBubyBkaXJlY3Rvcnkgc2VwYXJhdG9yLgorYXNfbXlzZWxmPQorY2Fz
ZSAkMCBpbiAjKCgKKyAgKltcXC9dKiApIGFzX215c2VsZj0kMCA7OworICAqKSBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgdGVz
dCAtciAiJGFzX2Rpci8kMCIgJiYgYXNfbXlzZWxmPSRhc19kaXIvJDAgJiYgYnJlYWsKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgICAgIDs7Citlc2FjCisjIFdlIGRpZCBub3QgZmluZCBv
dXJzZWx2ZXMsIG1vc3QgcHJvYmFibHkgd2Ugd2VyZSBydW4gYXMgYHNoIENPTU1BTkQnCisjIGlu
IHdoaWNoIGNhc2Ugd2UgYXJlIG5vdCB0byBiZSBmb3VuZCBpbiB0aGUgcGF0aC4KK2lmIHRlc3Qg
IngkYXNfbXlzZWxmIiA9IHg7IHRoZW4KKyAgYXNfbXlzZWxmPSQwCitmaQoraWYgdGVzdCAhIC1m
ICIkYXNfbXlzZWxmIjsgdGhlbgorICAkYXNfZWNobyAiJGFzX215c2VsZjogZXJyb3I6IGNhbm5v
dCBmaW5kIG15c2VsZjsgcmVydW4gd2l0aCBhbiBhYnNvbHV0ZSBmaWxlIG5hbWUiID4mMgorICBl
eGl0IDEKK2ZpCisKKyMgVW5zZXQgdmFyaWFibGVzIHRoYXQgd2UgZG8gbm90IG5lZWQgYW5kIHdo
aWNoIGNhdXNlIGJ1Z3MgKGUuZy4gaW4KKyMgcHJlLTMuMCBVV0lOIGtzaCkuICBCdXQgZG8gbm90
IGNhdXNlIGJ1Z3MgaW4gYmFzaCAyLjAxOyB0aGUgInx8IGV4aXQgMSIKKyMgc3VwcHJlc3NlcyBh
bnkgIlNlZ21lbnRhdGlvbiBmYXVsdCIgbWVzc2FnZSB0aGVyZS4gICcoKCcgY291bGQKKyMgdHJp
Z2dlciBhIGJ1ZyBpbiBwZGtzaCA1LjIuMTQuCitmb3IgYXNfdmFyIGluIEJBU0hfRU5WIEVOViBN
QUlMIE1BSUxQQVRICitkbyBldmFsIHRlc3QgeFwkeyRhc192YXIrc2V0fSA9IHhzZXQgXAorICAm
JiAoICh1bnNldCAkYXNfdmFyKSB8fCBleGl0IDEpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCAk
YXNfdmFyIHx8IDoKK2RvbmUKK1BTMT0nJCAnCitQUzI9Jz4gJworUFM0PScrICcKKworIyBOTFMg
bnVpc2FuY2VzLgorTENfQUxMPUMKK2V4cG9ydCBMQ19BTEwKK0xBTkdVQUdFPUMKK2V4cG9ydCBM
QU5HVUFHRQorCisjIENEUEFUSC4KKyh1bnNldCBDRFBBVEgpID4vZGV2L251bGwgMj4mMSAmJiB1
bnNldCBDRFBBVEgKKworCisjIGFzX2ZuX2Vycm9yIFNUQVRVUyBFUlJPUiBbTElORU5PIExPR19G
RF0KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBPdXRwdXQg
ImBiYXNlbmFtZSAkMGA6IGVycm9yOiBFUlJPUiIgdG8gc3RkZXJyLiBJZiBMSU5FTk8gYW5kIExP
R19GRCBhcmUKKyMgcHJvdmlkZWQsIGFsc28gb3V0cHV0IHRoZSBlcnJvciB0byBMT0dfRkQsIHJl
ZmVyZW5jaW5nIExJTkVOTy4gVGhlbiBleGl0IHRoZQorIyBzY3JpcHQgd2l0aCBTVEFUVVMsIHVz
aW5nIDEgaWYgdGhhdCB3YXMgMC4KK2FzX2ZuX2Vycm9yICgpCit7CisgIGFzX3N0YXR1cz0kMTsg
dGVzdCAkYXNfc3RhdHVzIC1lcSAwICYmIGFzX3N0YXR1cz0xCisgIGlmIHRlc3QgIiQ0IjsgdGhl
bgorICAgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDMifSBhc19saW5lbm9fc3RhY2s9YXNfbGlu
ZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBlcnJvcjogJDIiID4mJDQKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZTog
ZXJyb3I6ICQyIiA+JjIKKyAgYXNfZm5fZXhpdCAkYXNfc3RhdHVzCit9ICMgYXNfZm5fZXJyb3IK
KworCisjIGFzX2ZuX3NldF9zdGF0dXMgU1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CisjIFNldCAkPyB0byBTVEFUVVMsIHdpdGhvdXQgZm9ya2luZy4KK2FzX2ZuX3NldF9zdGF0dXMg
KCkKK3sKKyAgcmV0dXJuICQxCit9ICMgYXNfZm5fc2V0X3N0YXR1cworCisjIGFzX2ZuX2V4aXQg
U1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tCisjIEV4aXQgdGhlIHNoZWxsIHdpdGggU1RBVFVT
LCBldmVuIGluIGEgInRyYXAgMCIgb3IgInNldCAtZSIgY29udGV4dC4KK2FzX2ZuX2V4aXQgKCkK
K3sKKyAgc2V0ICtlCisgIGFzX2ZuX3NldF9zdGF0dXMgJDEKKyAgZXhpdCAkMQorfSAjIGFzX2Zu
X2V4aXQKKworIyBhc19mbl91bnNldCBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tCisjIFBvcnRhYmx5
IHVuc2V0IFZBUi4KK2FzX2ZuX3Vuc2V0ICgpCit7CisgIHsgZXZhbCAkMT07IHVuc2V0ICQxO30K
K30KK2FzX3Vuc2V0PWFzX2ZuX3Vuc2V0CisjIGFzX2ZuX2FwcGVuZCBWQVIgVkFMVUUKKyMgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQorIyBBcHBlbmQgdGhlIHRleHQgaW4gVkFMVUUgdG8gdGhlIGVu
ZCBvZiB0aGUgZGVmaW5pdGlvbiBjb250YWluZWQgaW4gVkFSLiBUYWtlCisjIGFkdmFudGFnZSBv
ZiBhbnkgc2hlbGwgb3B0aW1pemF0aW9ucyB0aGF0IGFsbG93IGFtb3J0aXplZCBsaW5lYXIgZ3Jv
d3RoIG92ZXIKKyMgcmVwZWF0ZWQgYXBwZW5kcywgaW5zdGVhZCBvZiB0aGUgdHlwaWNhbCBxdWFk
cmF0aWMgZ3Jvd3RoIHByZXNlbnQgaW4gbmFpdmUKKyMgaW1wbGVtZW50YXRpb25zLgoraWYgKGV2
YWwgImFzX3Zhcj0xOyBhc192YXIrPTI7IHRlc3QgeFwkYXNfdmFyID0geDEyIikgMj4vZGV2L251
bGw7IHRoZW4gOgorICBldmFsICdhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDErPVwk
MgorICB9JworZWxzZQorICBhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDE9XCQkMVwk
MgorICB9CitmaSAjIGFzX2ZuX2FwcGVuZAorCisjIGFzX2ZuX2FyaXRoIEFSRy4uLgorIyAtLS0t
LS0tLS0tLS0tLS0tLS0KKyMgUGVyZm9ybSBhcml0aG1ldGljIGV2YWx1YXRpb24gb24gdGhlIEFS
R3MsIGFuZCBzdG9yZSB0aGUgcmVzdWx0IGluIHRoZQorIyBnbG9iYWwgJGFzX3ZhbC4gVGFrZSBh
ZHZhbnRhZ2Ugb2Ygc2hlbGxzIHRoYXQgY2FuIGF2b2lkIGZvcmtzLiBUaGUgYXJndW1lbnRzCisj
IG11c3QgYmUgcG9ydGFibGUgYWNyb3NzICQoKCkpIGFuZCBleHByLgoraWYgKGV2YWwgInRlc3Qg
XCQoKCAxICsgMSApKSA9IDIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2Fy
aXRoICgpCisgIHsKKyAgICBhc192YWw9JCgoICQqICkpCisgIH0nCitlbHNlCisgIGFzX2ZuX2Fy
aXRoICgpCisgIHsKKyAgICBhc192YWw9YGV4cHIgIiRAIiB8fCB0ZXN0ICQ/IC1lcSAxYAorICB9
CitmaSAjIGFzX2ZuX2FyaXRoCisKKworaWYgZXhwciBhIDogJ1woYVwpJyA+L2Rldi9udWxsIDI+
JjEgJiYKKyAgIHRlc3QgIlhgZXhwciAwMDAwMSA6ICcuKlwoLi4uXCknYCIgPSBYMDAxOyB0aGVu
CisgIGFzX2V4cHI9ZXhwcgorZWxzZQorICBhc19leHByPWZhbHNlCitmaQorCitpZiAoYmFzZW5h
bWUgLS0gLykgPi9kZXYvbnVsbCAyPiYxICYmIHRlc3QgIlhgYmFzZW5hbWUgLS0gLyAyPiYxYCIg
PSAiWC8iOyB0aGVuCisgIGFzX2Jhc2VuYW1lPWJhc2VuYW1lCitlbHNlCisgIGFzX2Jhc2VuYW1l
PWZhbHNlCitmaQorCitpZiAoYXNfZGlyPWBkaXJuYW1lIC0tIC9gICYmIHRlc3QgIlgkYXNfZGly
IiA9IFgvKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfZGlybmFtZT1kaXJuYW1lCitlbHNl
CisgIGFzX2Rpcm5hbWU9ZmFsc2UKK2ZpCisKK2FzX21lPWAkYXNfYmFzZW5hbWUgLS0gIiQwIiB8
fAorJGFzX2V4cHIgWC8iJDAiIDogJy4qL1woW14vXVteL10qXCkvKiQnIFx8IFwKKwkgWCIkMCIg
OiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoL1wpJyBcfCAuIDI+L2Rldi9udWxsIHx8
CiskYXNfZWNobyBYLyIkMCIgfAorICAgIHNlZCAnL14uKlwvXChbXi9dW14vXSpcKVwvKiQvewor
CSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXC9cKSQveworCSAgICBzLy9c
MS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBx
CisJICB9CisJICBzLy4qLy4vOyBxJ2AKKworIyBBdm9pZCBkZXBlbmRpbmcgdXBvbiBDaGFyYWN0
ZXIgUmFuZ2VzLgorYXNfY3JfbGV0dGVycz0nYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonCith
c19jcl9MRVRURVJTPSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicKK2FzX2NyX0xldHRlcnM9
JGFzX2NyX2xldHRlcnMkYXNfY3JfTEVUVEVSUworYXNfY3JfZGlnaXRzPScwMTIzNDU2Nzg5Jwor
YXNfY3JfYWxudW09JGFzX2NyX0xldHRlcnMkYXNfY3JfZGlnaXRzCisKK0VDSE9fQz0gRUNIT19O
PSBFQ0hPX1Q9CitjYXNlIGBlY2hvIC1uIHhgIGluICMoKCgoKAorLW4qKQorICBjYXNlIGBlY2hv
ICd4eVxjJ2AgaW4KKyAgKmMqKSBFQ0hPX1Q9JwknOzsJIyBFQ0hPX1QgaXMgc2luZ2xlIHRhYiBj
aGFyYWN0ZXIuCisgIHh5KSAgRUNIT19DPSdcYyc7OworICAqKSAgIGVjaG8gYGVjaG8ga3NoODgg
YnVnIG9uIEFJWCA2LjFgID4gL2Rldi9udWxsCisgICAgICAgRUNIT19UPScJJzs7CisgIGVzYWM7
OworKikKKyAgRUNIT19OPSctbic7OworZXNhYworCitybSAtZiBjb25mJCQgY29uZiQkLmV4ZSBj
b25mJCQuZmlsZQoraWYgdGVzdCAtZCBjb25mJCQuZGlyOyB0aGVuCisgIHJtIC1mIGNvbmYkJC5k
aXIvY29uZiQkLmZpbGUKK2Vsc2UKKyAgcm0gLWYgY29uZiQkLmRpcgorICBta2RpciBjb25mJCQu
ZGlyIDI+L2Rldi9udWxsCitmaQoraWYgKGVjaG8gPmNvbmYkJC5maWxlKSAyPi9kZXYvbnVsbDsg
dGhlbgorICBpZiBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4KKyAg
ICBhc19sbl9zPSdsbiAtcycKKyAgICAjIC4uLiBidXQgdGhlcmUgYXJlIHR3byBnb3RjaGFzOgor
ICAgICMgMSkgT24gTVNZUywgYm90aCBgbG4gLXMgZmlsZSBkaXInIGFuZCBgbG4gZmlsZSBkaXIn
IGZhaWwuCisgICAgIyAyKSBESkdQUCA8IDIuMDQgaGFzIG5vIHN5bWxpbmtzOyBgbG4gLXMnIGNy
ZWF0ZXMgYSB3cmFwcGVyIGV4ZWN1dGFibGUuCisgICAgIyBJbiBib3RoIGNhc2VzLCB3ZSBoYXZl
IHRvIGRlZmF1bHQgdG8gYGNwIC1wJy4KKyAgICBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQuZGly
IDI+L2Rldi9udWxsICYmIHRlc3QgISAtZiBjb25mJCQuZXhlIHx8CisgICAgICBhc19sbl9zPSdj
cCAtcCcKKyAgZWxpZiBsbiBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4KKyAg
ICBhc19sbl9zPWxuCisgIGVsc2UKKyAgICBhc19sbl9zPSdjcCAtcCcKKyAgZmkKK2Vsc2UKKyAg
YXNfbG5fcz0nY3AgLXAnCitmaQorcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmRpci9j
b25mJCQuZmlsZSBjb25mJCQuZmlsZQorcm1kaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAorCisK
KyMgYXNfZm5fbWtkaXJfcAorIyAtLS0tLS0tLS0tLS0tCisjIENyZWF0ZSAiJGFzX2RpciIgYXMg
YSBkaXJlY3RvcnksIGluY2x1ZGluZyBwYXJlbnRzIGlmIG5lY2Vzc2FyeS4KK2FzX2ZuX21rZGly
X3AgKCkKK3sKKworICBjYXNlICRhc19kaXIgaW4gIygKKyAgLSopIGFzX2Rpcj0uLyRhc19kaXI7
OworICBlc2FjCisgIHRlc3QgLWQgIiRhc19kaXIiIHx8IGV2YWwgJGFzX21rZGlyX3AgfHwgewor
ICAgIGFzX2RpcnM9CisgICAgd2hpbGUgOjsgZG8KKyAgICAgIGNhc2UgJGFzX2RpciBpbiAjKAor
ICAgICAgKlwnKikgYXNfcWRpcj1gJGFzX2VjaG8gIiRhc19kaXIiIHwgc2VkICJzLycvJ1xcXFxc
XFxcJycvZyJgOzsgIycoCisgICAgICAqKSBhc19xZGlyPSRhc19kaXI7OworICAgICAgZXNhYwor
ICAgICAgYXNfZGlycz0iJyRhc19xZGlyJyAkYXNfZGlycyIKKyAgICAgIGFzX2Rpcj1gJGFzX2Rp
cm5hbWUgLS0gIiRhc19kaXIiIHx8CiskYXNfZXhwciBYIiRhc19kaXIiIDogJ1hcKC4qW14vXVwp
Ly8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX2RpciIgOiAnWFwoLy9cKVteL10nIFx8IFwK
KwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC9cKScg
XHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYXNfZGlyIiB8CisgICAgc2VkICcvXlhc
KC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0K
KwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9e
WFwoXC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97
CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgICAgIHRlc3Qg
LWQgIiRhc19kaXIiICYmIGJyZWFrCisgICAgZG9uZQorICAgIHRlc3QgLXogIiRhc19kaXJzIiB8
fCBldmFsICJta2RpciAkYXNfZGlycyIKKyAgfSB8fCB0ZXN0IC1kICIkYXNfZGlyIiB8fCBhc19m
bl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBkaXJlY3RvcnkgJGFzX2RpciIKKworCit9ICMgYXNf
Zm5fbWtkaXJfcAoraWYgbWtkaXIgLXAgLiAyPi9kZXYvbnVsbDsgdGhlbgorICBhc19ta2Rpcl9w
PSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRlc3QgLWQgLi8tcCAmJiBybWRpciAuLy1w
CisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRlc3QgLXggLyA+L2Rldi9udWxsIDI+JjE7
IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxzZQorICBpZiBscyAtZEwgLyA+L2Rldi9u
dWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlvbj1MCisgIGVsc2UKKyAgICBhc19sc19M
X29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAgICBldmFsIHNoIC1jICdcJycKKyAgICAg
IGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQgIiQxLy4iOworICAgICAgZWxzZQorCWNh
c2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwllc2FjOworCWNhc2UgYGxzIC1sZCckYXNf
bHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGluICMoKAorCT8/P1tzeF0qKTo7OyopZmFs
c2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2ZpCithc19leGVjdXRhYmxlX3A9JGFzX3Rl
c3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgQ1BQ
IG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSokYXNfY3JfbGV0dGVycyVQJGFzX2NyX0xF
VFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisjIFNlZCBleHByZXNzaW9uIHRvIG1h
cCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUgbmFtZS4KK2FzX3RyX3NoPSJldmFsIHNl
ZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisKKworZXhlYyA2PiYxCisjIyAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTWFpbiBib2R5IG9mICRD
T05GSUdfU1RBVFVTIHNjcmlwdC4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tICMjCitfQVNFT0YKK3Rlc3QgJGFzX3dyaXRlX2ZhaWwgPSAwICYmIGNobW9kICt4ICRD
T05GSUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8
PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIFNhdmUgdGhlIGxvZyBtZXNzYWdlLCB0byBr
ZWVwICQwIGFuZCBzbyBvbiBtZWFuaW5nZnVsLCBhbmQgdG8KKyMgcmVwb3J0IGFjdHVhbCBpbnB1
dCB2YWx1ZXMgb2YgQ09ORklHX0ZJTEVTIGV0Yy4gaW5zdGVhZCBvZiB0aGVpcgorIyB2YWx1ZXMg
YWZ0ZXIgb3B0aW9ucyBoYW5kbGluZy4KK2FjX2xvZz0iCitUaGlzIGZpbGUgd2FzIGV4dGVuZGVk
IGJ5IFhlbiBIeXBlcnZpc29yICRhc19tZSA0LjIsIHdoaWNoIHdhcworZ2VuZXJhdGVkIGJ5IEdO
VSBBdXRvY29uZiAyLjY4LiAgSW52b2NhdGlvbiBjb21tYW5kIGxpbmUgd2FzCisKKyAgQ09ORklH
X0ZJTEVTICAgID0gJENPTkZJR19GSUxFUworICBDT05GSUdfSEVBREVSUyAgPSAkQ09ORklHX0hF
QURFUlMKKyAgQ09ORklHX0xJTktTICAgID0gJENPTkZJR19MSU5LUworICBDT05GSUdfQ09NTUFO
RFMgPSAkQ09ORklHX0NPTU1BTkRTCisgICQgJDAgJEAKKworb24gYChob3N0bmFtZSB8fCB1bmFt
ZSAtbikgMj4vZGV2L251bGwgfCBzZWQgMXFgCisiCisKK19BQ0VPRgorCitjYXNlICRhY19jb25m
aWdfZmlsZXMgaW4gKiIKKyIqKSBzZXQgeCAkYWNfY29uZmlnX2ZpbGVzOyBzaGlmdDsgYWNfY29u
ZmlnX2ZpbGVzPSQqOzsKK2VzYWMKKworY2FzZSAkYWNfY29uZmlnX2hlYWRlcnMgaW4gKiIKKyIq
KSBzZXQgeCAkYWNfY29uZmlnX2hlYWRlcnM7IHNoaWZ0OyBhY19jb25maWdfaGVhZGVycz0kKjs7
Citlc2FjCisKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFp
bD0xCisjIEZpbGVzIHRoYXQgY29uZmlnLnN0YXR1cyB3YXMgbWFkZSBmb3IuCitjb25maWdfZmls
ZXM9IiRhY19jb25maWdfZmlsZXMiCitjb25maWdfaGVhZGVycz0iJGFjX2NvbmZpZ19oZWFkZXJz
IgorCitfQUNFT0YKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRl
X2ZhaWw9MQorYWNfY3NfdXNhZ2U9IlwKK1xgJGFzX21lJyBpbnN0YW50aWF0ZXMgZmlsZXMgYW5k
IG90aGVyIGNvbmZpZ3VyYXRpb24gYWN0aW9ucworZnJvbSB0ZW1wbGF0ZXMgYWNjb3JkaW5nIHRv
IHRoZSBjdXJyZW50IGNvbmZpZ3VyYXRpb24uICBVbmxlc3MgdGhlIGZpbGVzCithbmQgYWN0aW9u
cyBhcmUgc3BlY2lmaWVkIGFzIFRBR3MsIGFsbCBhcmUgaW5zdGFudGlhdGVkIGJ5IGRlZmF1bHQu
CisKK1VzYWdlOiAkMCBbT1BUSU9OXS4uLiBbVEFHXS4uLgorCisgIC1oLCAtLWhlbHAgICAgICAg
cHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQKKyAgLVYsIC0tdmVyc2lvbiAgICBwcmludCB2ZXJz
aW9uIG51bWJlciBhbmQgY29uZmlndXJhdGlvbiBzZXR0aW5ncywgdGhlbiBleGl0CisgICAgICAt
LWNvbmZpZyAgICAgcHJpbnQgY29uZmlndXJhdGlvbiwgdGhlbiBleGl0CisgIC1xLCAtLXF1aWV0
LCAtLXNpbGVudAorICAgICAgICAgICAgICAgICAgIGRvIG5vdCBwcmludCBwcm9ncmVzcyBtZXNz
YWdlcworICAtZCwgLS1kZWJ1ZyAgICAgIGRvbid0IHJlbW92ZSB0ZW1wb3JhcnkgZmlsZXMKKyAg
ICAgIC0tcmVjaGVjayAgICB1cGRhdGUgJGFzX21lIGJ5IHJlY29uZmlndXJpbmcgaW4gdGhlIHNh
bWUgY29uZGl0aW9ucworICAgICAgLS1maWxlPUZJTEVbOlRFTVBMQVRFXQorICAgICAgICAgICAg
ICAgICAgIGluc3RhbnRpYXRlIHRoZSBjb25maWd1cmF0aW9uIGZpbGUgRklMRQorICAgICAgLS1o
ZWFkZXI9RklMRVs6VEVNUExBVEVdCisgICAgICAgICAgICAgICAgICAgaW5zdGFudGlhdGUgdGhl
IGNvbmZpZ3VyYXRpb24gaGVhZGVyIEZJTEUKKworQ29uZmlndXJhdGlvbiBmaWxlczoKKyRjb25m
aWdfZmlsZXMKKworQ29uZmlndXJhdGlvbiBoZWFkZXJzOgorJGNvbmZpZ19oZWFkZXJzCisKK1Jl
cG9ydCBidWdzIHRvIDx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbT4uIgorCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorYWNfY3Nf
Y29uZmlnPSJgJGFzX2VjaG8gIiRhY19jb25maWd1cmVfYXJncyIgfCBzZWQgJ3MvXiAvLzsgcy9b
XFwiIlxgXCRdL1xcXFwmL2cnYCIKK2FjX2NzX3ZlcnNpb249IlxcCitYZW4gSHlwZXJ2aXNvciBj
b25maWcuc3RhdHVzIDQuMgorY29uZmlndXJlZCBieSAkMCwgZ2VuZXJhdGVkIGJ5IEdOVSBBdXRv
Y29uZiAyLjY4LAorICB3aXRoIG9wdGlvbnMgXFwiXCRhY19jc19jb25maWdcXCIKKworQ29weXJp
Z2h0IChDKSAyMDEwIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgorVGhpcyBjb25maWcu
c3RhdHVzIHNjcmlwdCBpcyBmcmVlIHNvZnR3YXJlOyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uCitnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBjb3B5LCBkaXN0cmlidXRlIGFuZCBt
b2RpZnkgaXQuIgorCithY19wd2Q9JyRhY19wd2QnCitzcmNkaXI9JyRzcmNkaXInCitJTlNUQUxM
PSckSU5TVEFMTCcKK3Rlc3QgLW4gIlwkQVdLIiB8fCBBV0s9YXdrCitfQUNFT0YKKworY2F0ID4+
JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBUaGUgZGVmYXVs
dCBsaXN0cyBhcHBseSBpZiB0aGUgdXNlciBkb2VzIG5vdCBzcGVjaWZ5IGFueSBmaWxlLgorYWNf
bmVlZF9kZWZhdWx0cz06Cit3aGlsZSB0ZXN0ICQjICE9IDAKK2RvCisgIGNhc2UgJDEgaW4KKyAg
LS0qPT8qKQorICAgIGFjX29wdGlvbj1gZXhwciAiWCQxIiA6ICdYXChbXj1dKlwpPSdgCisgICAg
YWNfb3B0YXJnPWBleHByICJYJDEiIDogJ1hbXj1dKj1cKC4qXCknYAorICAgIGFjX3NoaWZ0PToK
KyAgICA7OworICAtLSo9KQorICAgIGFjX29wdGlvbj1gZXhwciAiWCQxIiA6ICdYXChbXj1dKlwp
PSdgCisgICAgYWNfb3B0YXJnPQorICAgIGFjX3NoaWZ0PToKKyAgICA7OworICAqKQorICAgIGFj
X29wdGlvbj0kMQorICAgIGFjX29wdGFyZz0kMgorICAgIGFjX3NoaWZ0PXNoaWZ0CisgICAgOzsK
KyAgZXNhYworCisgIGNhc2UgJGFjX29wdGlvbiBpbgorICAjIEhhbmRsaW5nIG9mIHRoZSBvcHRp
b25zLgorICAtcmVjaGVjayB8IC0tcmVjaGVjayB8IC0tcmVjaGVjIHwgLS1yZWNoZSB8IC0tcmVj
aCB8IC0tcmVjIHwgLS1yZSB8IC0tcikKKyAgICBhY19jc19yZWNoZWNrPTogOzsKKyAgLS12ZXJz
aW9uIHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwgLS12ZXIgfCAtLXZlIHwgLS12IHwg
LVYgKQorICAgICRhc19lY2hvICIkYWNfY3NfdmVyc2lvbiI7IGV4aXQgOzsKKyAgLS1jb25maWcg
fCAtLWNvbmZpIHwgLS1jb25mIHwgLS1jb24gfCAtLWNvIHwgLS1jICkKKyAgICAkYXNfZWNobyAi
JGFjX2NzX2NvbmZpZyI7IGV4aXQgOzsKKyAgLS1kZWJ1ZyB8IC0tZGVidSB8IC0tZGViIHwgLS1k
ZSB8IC0tZCB8IC1kICkKKyAgICBkZWJ1Zz06IDs7CisgIC0tZmlsZSB8IC0tZmlsIHwgLS1maSB8
IC0tZiApCisgICAgJGFjX3NoaWZ0CisgICAgY2FzZSAkYWNfb3B0YXJnIGluCisgICAgKlwnKikg
YWNfb3B0YXJnPWAkYXNfZWNobyAiJGFjX29wdGFyZyIgfCBzZWQgInMvJy8nXFxcXFxcXFwnJy9n
ImAgOzsKKyAgICAnJykgYXNfZm5fZXJyb3IgJD8gIm1pc3NpbmcgZmlsZSBhcmd1bWVudCIgOzsK
KyAgICBlc2FjCisgICAgYXNfZm5fYXBwZW5kIENPTkZJR19GSUxFUyAiICckYWNfb3B0YXJnJyIK
KyAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlOzsKKyAgLS1oZWFkZXIgfCAtLWhlYWRlIHwgLS1o
ZWFkIHwgLS1oZWEgKQorICAgICRhY19zaGlmdAorICAgIGNhc2UgJGFjX29wdGFyZyBpbgorICAg
ICpcJyopIGFjX29wdGFyZz1gJGFzX2VjaG8gIiRhY19vcHRhcmciIHwgc2VkICJzLycvJ1xcXFxc
XFxcJycvZyJgIDs7CisgICAgZXNhYworICAgIGFzX2ZuX2FwcGVuZCBDT05GSUdfSEVBREVSUyAi
ICckYWNfb3B0YXJnJyIKKyAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlOzsKKyAgLS1oZSB8IC0t
aCkKKyAgICAjIENvbmZsaWN0IGJldHdlZW4gLS1oZWxwIGFuZCAtLWhlYWRlcgorICAgIGFzX2Zu
X2Vycm9yICQ/ICJhbWJpZ3VvdXMgb3B0aW9uOiBcYCQxJworVHJ5IFxgJDAgLS1oZWxwJyBmb3Ig
bW9yZSBpbmZvcm1hdGlvbi4iOzsKKyAgLS1oZWxwIHwgLS1oZWwgfCAtaCApCisgICAgJGFzX2Vj
aG8gIiRhY19jc191c2FnZSI7IGV4aXQgOzsKKyAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwgLS1x
dWllIHwgLS1xdWkgfCAtLXF1IHwgLS1xIFwKKyAgfCAtc2lsZW50IHwgLS1zaWxlbnQgfCAtLXNp
bGVuIHwgLS1zaWxlIHwgLS1zaWwgfCAtLXNpIHwgLS1zKQorICAgIGFjX2NzX3NpbGVudD06IDs7
CisKKyAgIyBUaGlzIGlzIGFuIGVycm9yLgorICAtKikgYXNfZm5fZXJyb3IgJD8gInVucmVjb2du
aXplZCBvcHRpb246IFxgJDEnCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9u
LiIgOzsKKworICAqKSBhc19mbl9hcHBlbmQgYWNfY29uZmlnX3RhcmdldHMgIiAkMSIKKyAgICAg
YWNfbmVlZF9kZWZhdWx0cz1mYWxzZSA7OworCisgIGVzYWMKKyAgc2hpZnQKK2RvbmUKKworYWNf
Y29uZmlndXJlX2V4dHJhX2FyZ3M9CisKK2lmICRhY19jc19zaWxlbnQ7IHRoZW4KKyAgZXhlYyA2
Pi9kZXYvbnVsbAorICBhY19jb25maWd1cmVfZXh0cmFfYXJncz0iJGFjX2NvbmZpZ3VyZV9leHRy
YV9hcmdzIC0tc2lsZW50IgorZmkKKworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9B
Q0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2lmIFwkYWNfY3NfcmVjaGVjazsgdGhlbgorICBzZXQg
WCAnJFNIRUxMJyAnJDAnICRhY19jb25maWd1cmVfYXJncyBcJGFjX2NvbmZpZ3VyZV9leHRyYV9h
cmdzIC0tbm8tY3JlYXRlIC0tbm8tcmVjdXJzaW9uCisgIHNoaWZ0CisgIFwkYXNfZWNobyAicnVu
bmluZyBDT05GSUdfU0hFTEw9JFNIRUxMIFwkKiIgPiY2CisgIENPTkZJR19TSEVMTD0nJFNIRUxM
JworICBleHBvcnQgQ09ORklHX1NIRUxMCisgIGV4ZWMgIlwkQCIKK2ZpCisKK19BQ0VPRgorY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorZXhlYyA1Pj5j
b25maWcubG9nCit7CisgIGVjaG8KKyAgc2VkICdoO3MvLi8tL2c7cy9eLi4uLyMjIC87cy8uLi4k
LyAjIy87cDt4O3A7eCcgPDxfQVNCT1gKKyMjIFJ1bm5pbmcgJGFzX21lLiAjIworX0FTQk9YCisg
ICRhc19lY2hvICIkYWNfbG9nIgorfSA+JjUKKworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRV
UyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NU
QVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisKKyMgSGFuZGxpbmcgb2YgYXJndW1l
bnRzLgorZm9yIGFjX2NvbmZpZ190YXJnZXQgaW4gJGFjX2NvbmZpZ190YXJnZXRzCitkbworICBj
YXNlICRhY19jb25maWdfdGFyZ2V0IGluCisgICAgIi4uL2NvbmZpZy9Ub29scy5tayIpIENPTkZJ
R19GSUxFUz0iJENPTkZJR19GSUxFUyAuLi9jb25maWcvVG9vbHMubWsiIDs7CisgICAgImNvbmZp
Zy5oIikgQ09ORklHX0hFQURFUlM9IiRDT05GSUdfSEVBREVSUyBjb25maWcuaCIgOzsKKworICAq
KSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBhcmd1bWVudDogXGAkYWNfY29uZmlnX3RhcmdldCci
ICIkTElORU5PIiA1OzsKKyAgZXNhYworZG9uZQorCisKKyMgSWYgdGhlIHVzZXIgZGlkIG5vdCB1
c2UgdGhlIGFyZ3VtZW50cyB0byBzcGVjaWZ5IHRoZSBpdGVtcyB0byBpbnN0YW50aWF0ZSwKKyMg
dGhlbiB0aGUgZW52dmFyIGludGVyZmFjZSBpcyB1c2VkLiAgU2V0IG9ubHkgdGhvc2UgdGhhdCBh
cmUgbm90LgorIyBXZSB1c2UgdGhlIGxvbmcgZm9ybSBmb3IgdGhlIGRlZmF1bHQgYXNzaWdubWVu
dCBiZWNhdXNlIG9mIGFuIGV4dHJlbWVseQorIyBiaXphcnJlIGJ1ZyBvbiBTdW5PUyA0LjEuMy4K
K2lmICRhY19uZWVkX2RlZmF1bHRzOyB0aGVuCisgIHRlc3QgIiR7Q09ORklHX0ZJTEVTK3NldH0i
ID0gc2V0IHx8IENPTkZJR19GSUxFUz0kY29uZmlnX2ZpbGVzCisgIHRlc3QgIiR7Q09ORklHX0hF
QURFUlMrc2V0fSIgPSBzZXQgfHwgQ09ORklHX0hFQURFUlM9JGNvbmZpZ19oZWFkZXJzCitmaQor
CisjIEhhdmUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGZvciBjb252ZW5pZW5jZS4gIE1ha2UgaXQg
aW4gdGhlIGJ1aWxkIHRyZWUKKyMgc2ltcGx5IGJlY2F1c2UgdGhlcmUgaXMgbm8gcmVhc29uIGFn
YWluc3QgaGF2aW5nIGl0IGhlcmUsIGFuZCBpbiBhZGRpdGlvbiwKKyMgY3JlYXRpbmcgYW5kIG1v
dmluZyBmaWxlcyBmcm9tIC90bXAgY2FuIHNvbWV0aW1lcyBjYXVzZSBwcm9ibGVtcy4KKyMgSG9v
ayBmb3IgaXRzIHJlbW92YWwgdW5sZXNzIGRlYnVnZ2luZy4KKyMgTm90ZSB0aGF0IHRoZXJlIGlz
IGEgc21hbGwgd2luZG93IGluIHdoaWNoIHRoZSBkaXJlY3Rvcnkgd2lsbCBub3QgYmUgY2xlYW5l
ZDoKKyMgYWZ0ZXIgaXRzIGNyZWF0aW9uIGJ1dCBiZWZvcmUgaXRzIG5hbWUgaGFzIGJlZW4gYXNz
aWduZWQgdG8gYCR0bXAnLgorJGRlYnVnIHx8Cit7CisgIHRtcD0gYWNfdG1wPQorICB0cmFwICdl
eGl0X3N0YXR1cz0kPworICA6ICIke2FjX3RtcDo9JHRtcH0iCisgIHsgdGVzdCAhIC1kICIkYWNf
dG1wIiB8fCBybSAtZnIgIiRhY190bXAiOyB9ICYmIGV4aXQgJGV4aXRfc3RhdHVzCisnIDAKKyAg
dHJhcCAnYXNfZm5fZXhpdCAxJyAxIDIgMTMgMTUKK30KKyMgQ3JlYXRlIGEgKHNlY3VyZSkgdG1w
IGRpcmVjdG9yeSBmb3IgdG1wIGZpbGVzLgorCit7CisgIHRtcD1gKHVtYXNrIDA3NyAmJiBta3Rl
bXAgLWQgIi4vY29uZlhYWFhYWCIpIDI+L2Rldi9udWxsYCAmJgorICB0ZXN0IC1kICIkdG1wIgor
fSAgfHwKK3sKKyAgdG1wPS4vY29uZiQkLSRSQU5ET00KKyAgKHVtYXNrIDA3NyAmJiBta2RpciAi
JHRtcCIpCit9IHx8IGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGRp
cmVjdG9yeSBpbiAuIiAiJExJTkVOTyIgNQorYWNfdG1wPSR0bXAKKworIyBTZXQgdXAgdGhlIHNj
cmlwdHMgZm9yIENPTkZJR19GSUxFUyBzZWN0aW9uLgorIyBObyBuZWVkIHRvIGdlbmVyYXRlIHRo
ZW0gaWYgdGhlcmUgYXJlIG5vIENPTkZJR19GSUxFUy4KKyMgVGhpcyBoYXBwZW5zIGZvciBpbnN0
YW5jZSB3aXRoIGAuL2NvbmZpZy5zdGF0dXMgY29uZmlnLmgnLgoraWYgdGVzdCAtbiAiJENPTkZJ
R19GSUxFUyI7IHRoZW4KKworCithY19jcj1gZWNobyBYIHwgdHIgWCAnXDAxNSdgCisjIE9uIGN5
Z3dpbiwgYmFzaCBjYW4gZWF0IFxyIGluc2lkZSBgYCBpZiB0aGUgdXNlciByZXF1ZXN0ZWQgaWdu
Y3IuCisjIEJ1dCB3ZSBrbm93IG9mIG5vIG90aGVyIHNoZWxsIHdoZXJlIGFjX2NyIHdvdWxkIGJl
IGVtcHR5IGF0IHRoaXMKKyMgcG9pbnQsIHNvIHdlIGNhbiB1c2UgYSBiYXNoaXNtIGFzIGEgZmFs
bGJhY2suCitpZiB0ZXN0ICJ4JGFjX2NyIiA9IHg7IHRoZW4KKyAgZXZhbCBhY19jcj1cJFwnXFxy
XCcKK2ZpCithY19jc19hd2tfY3I9YCRBV0sgJ0JFR0lOIHsgcHJpbnQgImFccmIiIH0nIDwvZGV2
L251bGwgMj4vZGV2L251bGxgCitpZiB0ZXN0ICIkYWNfY3NfYXdrX2NyIiA9ICJhJHthY19jcn1i
IjsgdGhlbgorICBhY19jc19hd2tfY3I9J1xccicKK2Vsc2UKKyAgYWNfY3NfYXdrX2NyPSRhY19j
cgorZmkKKworZWNobyAnQkVHSU4geycgPiIkYWNfdG1wL3N1YnMxLmF3ayIgJiYKK19BQ0VPRgor
CisKK3sKKyAgZWNobyAiY2F0ID5jb25mJCRzdWJzLmF3ayA8PF9BQ0VPRiIgJiYKKyAgZWNobyAi
JGFjX3N1YnN0X3ZhcnMiIHwgc2VkICdzLy4qLyYhJCYkYWNfZGVsaW0vJyAmJgorICBlY2hvICJf
QUNFT0YiCit9ID5jb25mJCRzdWJzLnNoIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qg
bWFrZSAkQ09ORklHX1NUQVRVUyIgIiRMSU5FTk8iIDUKK2FjX2RlbGltX251bT1gZWNobyAiJGFj
X3N1YnN0X3ZhcnMiIHwgZ3JlcCAtYyAnXidgCithY19kZWxpbT0nJSFfISMgJworZm9yIGFjX2xh
c3RfdHJ5IGluIGZhbHNlIGZhbHNlIGZhbHNlIGZhbHNlIGZhbHNlIDo7IGRvCisgIC4gLi9jb25m
JCRzdWJzLnNoIHx8CisgICAgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05GSUdf
U1RBVFVTIiAiJExJTkVOTyIgNQorCisgIGFjX2RlbGltX249YHNlZCAtbiAicy8uKiRhY19kZWxp
bVwkL1gvcCIgY29uZiQkc3Vicy5hd2sgfCBncmVwIC1jIFhgCisgIGlmIHRlc3QgJGFjX2RlbGlt
X24gPSAkYWNfZGVsaW1fbnVtOyB0aGVuCisgICAgYnJlYWsKKyAgZWxpZiAkYWNfbGFzdF90cnk7
IHRoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IG1ha2UgJENPTkZJR19TVEFUVVMi
ICIkTElORU5PIiA1CisgIGVsc2UKKyAgICBhY19kZWxpbT0iJGFjX2RlbGltISRhY19kZWxpbSBf
JGFjX2RlbGltISEgIgorICBmaQorZG9uZQorcm0gLWYgY29uZiQkc3Vicy5zaAorCitjYXQgPj4k
Q09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2NhdCA+PiJcJGFjX3Rt
cC9zdWJzMS5hd2siIDw8XFxfQUNBV0sgJiYKK19BQ0VPRgorc2VkIC1uICcKK2gKK3MvXi9TWyIv
OyBzLyEuKi8iXT0vCitwCitnCitzL15bXiFdKiEvLworOnJlcGwKK3QgcmVwbAorcy8nIiRhY19k
ZWxpbSInJC8vCit0IGRlbGltCis6bmwKK2gKK3MvXCguXHsxNDhcfVwpLi4qL1wxLwordCBtb3Jl
MQorcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvXFxuIlxcLworcAorbgorYiByZXBsCis6bW9y
ZTEKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kLyJcXC8KK3AKK2cKK3MvLlx7MTQ4XH0vLwor
dCBubAorOmRlbGltCitoCitzL1woLlx7MTQ4XH1cKS4uKi9cMS8KK3QgbW9yZTIKK3MvWyJcXF0v
XFwmL2c7IHMvXi8iLzsgcy8kLyIvCitwCitiCis6bW9yZTIKK3MvWyJcXF0vXFwmL2c7IHMvXi8i
Lzsgcy8kLyJcXC8KK3AKK2cKK3MvLlx7MTQ4XH0vLwordCBkZWxpbQorJyA8Y29uZiQkc3Vicy5h
d2sgfCBzZWQgJworL15bXiIiXS97CisgIE4KKyAgcy9cbi8vCit9CisnID4+JENPTkZJR19TVEFU
VVMgfHwgYWNfd3JpdGVfZmFpbD0xCitybSAtZiBjb25mJCRzdWJzLmF3aworY2F0ID4+JENPTkZJ
R19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitfQUNBV0sKK2NhdCA+PiJcJGFj
X3RtcC9zdWJzMS5hd2siIDw8X0FDQVdLICYmCisgIGZvciAoa2V5IGluIFMpIFNfaXNfc2V0W2tl
eV0gPSAxCisgIEZTID0gIgciCisKK30KK3sKKyAgbGluZSA9ICQgMAorICBuZmllbGRzID0gc3Bs
aXQobGluZSwgZmllbGQsICJAIikKKyAgc3Vic3RlZCA9IDAKKyAgbGVuID0gbGVuZ3RoKGZpZWxk
WzFdKQorICBmb3IgKGkgPSAyOyBpIDwgbmZpZWxkczsgaSsrKSB7CisgICAga2V5ID0gZmllbGRb
aV0KKyAgICBrZXlsZW4gPSBsZW5ndGgoa2V5KQorICAgIGlmIChTX2lzX3NldFtrZXldKSB7Cisg
ICAgICB2YWx1ZSA9IFNba2V5XQorICAgICAgbGluZSA9IHN1YnN0cihsaW5lLCAxLCBsZW4pICIi
IHZhbHVlICIiIHN1YnN0cihsaW5lLCBsZW4gKyBrZXlsZW4gKyAzKQorICAgICAgbGVuICs9IGxl
bmd0aCh2YWx1ZSkgKyBsZW5ndGgoZmllbGRbKytpXSkKKyAgICAgIHN1YnN0ZWQgPSAxCisgICAg
fSBlbHNlCisgICAgICBsZW4gKz0gMSArIGtleWxlbgorICB9CisKKyAgcHJpbnQgbGluZQorfQor
CitfQUNBV0sKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dy
aXRlX2ZhaWw9MQoraWYgc2VkICJzLyRhY19jci8vIiA8IC9kZXYvbnVsbCA+IC9kZXYvbnVsbCAy
PiYxOyB0aGVuCisgIHNlZCAicy8kYWNfY3JcJC8vOyBzLyRhY19jci8kYWNfY3NfYXdrX2NyL2ci
CitlbHNlCisgIGNhdAorZmkgPCAiJGFjX3RtcC9zdWJzMS5hd2siID4gIiRhY190bXAvc3Vicy5h
d2siIFwKKyAgfHwgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBzZXR1cCBjb25maWcgZmlsZXMg
bWFjaGluZXJ5IiAiJExJTkVOTyIgNQorX0FDRU9GCisKKyMgVlBBVEggbWF5IGNhdXNlIHRyb3Vi
bGUgd2l0aCBzb21lIG1ha2VzLCBzbyB3ZSByZW1vdmUgc29sZSAkKHNyY2RpciksCisjICR7c3Jj
ZGlyfSBhbmQgQHNyY2RpckAgZW50cmllcyBmcm9tIFZQQVRIIGlmIHNyY2RpciBpcyAiLiIsIHN0
cmlwIGxlYWRpbmcgYW5kCisjIHRyYWlsaW5nIGNvbG9ucyBhbmQgdGhlbiByZW1vdmUgdGhlIHdo
b2xlIGxpbmUgaWYgVlBBVEggYmVjb21lcyBlbXB0eQorIyAoYWN0dWFsbHkgd2UgbGVhdmUgYW4g
ZW1wdHkgbGluZSB0byBwcmVzZXJ2ZSBsaW5lIG51bWJlcnMpLgoraWYgdGVzdCAieCRzcmNkaXIi
ID0geC47IHRoZW4KKyAgYWNfdnBzdWI9Jy9eWwkgXSpWUEFUSFsJIF0qPVsJIF0qL3sKK2gKK3Mv
Ly8KK3MvXi86Lworcy9bCSBdKiQvOi8KK3MvOlwkKHNyY2Rpcik6LzovZworcy86XCR7c3JjZGly
fTovOi9nCitzLzpAc3JjZGlyQDovOi9nCitzL146Ki8vCitzLzoqJC8vCit4CitzL1woPVsJIF0q
XCkuKi9cMS8KK0cKK3MvXG4vLworcy9eW149XSo9WwkgXSokLy8KK30nCitmaQorCitjYXQgPj4k
Q09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitmaSAjIHRlc3QgLW4g
IiRDT05GSUdfRklMRVMiCisKKyMgU2V0IHVwIHRoZSBzY3JpcHRzIGZvciBDT05GSUdfSEVBREVS
UyBzZWN0aW9uLgorIyBObyBuZWVkIHRvIGdlbmVyYXRlIHRoZW0gaWYgdGhlcmUgYXJlIG5vIENP
TkZJR19IRUFERVJTLgorIyBUaGlzIGhhcHBlbnMgZm9yIGluc3RhbmNlIHdpdGggYC4vY29uZmln
LnN0YXR1cyBNYWtlZmlsZScuCitpZiB0ZXN0IC1uICIkQ09ORklHX0hFQURFUlMiOyB0aGVuCitj
YXQgPiIkYWNfdG1wL2RlZmluZXMuYXdrIiA8PFxfQUNBV0sgfHwKK0JFR0lOIHsKK19BQ0VPRgor
CisjIFRyYW5zZm9ybSBjb25mZGVmcy5oIGludG8gYW4gYXdrIHNjcmlwdCBgZGVmaW5lcy5hd2sn
LCBlbWJlZGRlZCBhcworIyBoZXJlLWRvY3VtZW50IGluIGNvbmZpZy5zdGF0dXMsIHRoYXQgc3Vi
c3RpdHV0ZXMgdGhlIHByb3BlciB2YWx1ZXMgaW50bworIyBjb25maWcuaC5pbiB0byBwcm9kdWNl
IGNvbmZpZy5oLgorCisjIENyZWF0ZSBhIGRlbGltaXRlciBzdHJpbmcgdGhhdCBkb2VzIG5vdCBl
eGlzdCBpbiBjb25mZGVmcy5oLCB0byBlYXNlCisjIGhhbmRsaW5nIG9mIGxvbmcgbGluZXMuCith
Y19kZWxpbT0nJSFfISMgJworZm9yIGFjX2xhc3RfdHJ5IGluIGZhbHNlIGZhbHNlIDo7IGRvCisg
IGFjX3R0PWBzZWQgLW4gIi8kYWNfZGVsaW0vcCIgY29uZmRlZnMuaGAKKyAgaWYgdGVzdCAteiAi
JGFjX3R0IjsgdGhlbgorICAgIGJyZWFrCisgIGVsaWYgJGFjX2xhc3RfdHJ5OyB0aGVuCisgICAg
YXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05GSUdfSEVBREVSUyIgIiRMSU5FTk8i
IDUKKyAgZWxzZQorICAgIGFjX2RlbGltPSIkYWNfZGVsaW0hJGFjX2RlbGltIF8kYWNfZGVsaW0h
ISAiCisgIGZpCitkb25lCisKKyMgRm9yIHRoZSBhd2sgc2NyaXB0LCBEIGlzIGFuIGFycmF5IG9m
IG1hY3JvIHZhbHVlcyBrZXllZCBieSBuYW1lLAorIyBsaWtld2lzZSBQIGNvbnRhaW5zIG1hY3Jv
IHBhcmFtZXRlcnMgaWYgYW55LiAgUHJlc2VydmUgYmFja3NsYXNoCisjIG5ld2xpbmUgc2VxdWVu
Y2VzLgorCithY193b3JkX3JlPVtfJGFzX2NyX0xldHRlcnNdW18kYXNfY3JfYWxudW1dKgorc2Vk
IC1uICcKK3MvLlx7MTQ4XH0vJiciJGFjX2RlbGltIicvZwordCByc2V0Cis6cnNldAorcy9eWwkg
XSojWwkgXSpkZWZpbmVbCSBdWwkgXSovIC8KK3QgZGVmCitkCis6ZGVmCitzL1xcJC8vCit0IGJz
bmwKK3MvWyJcXF0vXFwmL2cKK3MvXiBcKCciJGFjX3dvcmRfcmUiJ1wpXCgoW14oKV0qKVwpWwkg
XSpcKC4qXCkvUFsiXDEiXT0iXDIiXAorRFsiXDEiXT0iIFwzIi9wCitzL14gXCgnIiRhY193b3Jk
X3JlIidcKVsJIF0qXCguKlwpL0RbIlwxIl09IiBcMiIvcAorZAorOmJzbmwKK3MvWyJcXF0vXFwm
L2cKK3MvXiBcKCciJGFjX3dvcmRfcmUiJ1wpXCgoW14oKV0qKVwpWwkgXSpcKC4qXCkvUFsiXDEi
XT0iXDIiXAorRFsiXDEiXT0iIFwzXFxcXFxcbiJcXC9wCit0IGNvbnQKK3MvXiBcKCciJGFjX3dv
cmRfcmUiJ1wpWwkgXSpcKC4qXCkvRFsiXDEiXT0iIFwyXFxcXFxcbiJcXC9wCit0IGNvbnQKK2QK
Kzpjb250CituCitzLy5cezE0OFx9LyYnIiRhY19kZWxpbSInL2cKK3QgY2xlYXIKKzpjbGVhcgor
cy9cXCQvLwordCBic25sYworcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvIi9wCitkCis6YnNu
bGMKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kL1xcXFxcXG4iXFwvcAorYiBjb250CisnIDxj
b25mZGVmcy5oIHwgc2VkICcKK3MvJyIkYWNfZGVsaW0iJy8iXFxcCisiL2cnID4+JENPTkZJR19T
VEFUVVMgfHwgYWNfd3JpdGVfZmFpbD0xCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9G
IHx8IGFjX3dyaXRlX2ZhaWw9MQorICBmb3IgKGtleSBpbiBEKSBEX2lzX3NldFtrZXldID0gMQor
ICBGUyA9ICIHIgorfQorL15bXHQgXSojW1x0IF0qKGRlZmluZXx1bmRlZilbXHQgXSskYWNfd29y
ZF9yZShbXHQgKF18XCQpLyB7CisgIGxpbmUgPSBcJCAwCisgIHNwbGl0KGxpbmUsIGFyZywgIiAi
KQorICBpZiAoYXJnWzFdID09ICIjIikgeworICAgIGRlZnVuZGVmID0gYXJnWzJdCisgICAgbWFj
MSA9IGFyZ1szXQorICB9IGVsc2UgeworICAgIGRlZnVuZGVmID0gc3Vic3RyKGFyZ1sxXSwgMikK
KyAgICBtYWMxID0gYXJnWzJdCisgIH0KKyAgc3BsaXQobWFjMSwgbWFjMiwgIigiKSAjKQorICBt
YWNybyA9IG1hYzJbMV0KKyAgcHJlZml4ID0gc3Vic3RyKGxpbmUsIDEsIGluZGV4KGxpbmUsIGRl
ZnVuZGVmKSAtIDEpCisgIGlmIChEX2lzX3NldFttYWNyb10pIHsKKyAgICAjIFByZXNlcnZlIHRo
ZSB3aGl0ZSBzcGFjZSBzdXJyb3VuZGluZyB0aGUgIiMiLgorICAgIHByaW50IHByZWZpeCAiZGVm
aW5lIiwgbWFjcm8gUFttYWNyb10gRFttYWNyb10KKyAgICBuZXh0CisgIH0gZWxzZSB7CisgICAg
IyBSZXBsYWNlICN1bmRlZiB3aXRoIGNvbW1lbnRzLiAgVGhpcyBpcyBuZWNlc3NhcnksIGZvciBl
eGFtcGxlLAorICAgICMgaW4gdGhlIGNhc2Ugb2YgX1BPU0lYX1NPVVJDRSwgd2hpY2ggaXMgcHJl
ZGVmaW5lZCBhbmQgcmVxdWlyZWQKKyAgICAjIG9uIHNvbWUgc3lzdGVtcyB3aGVyZSBjb25maWd1
cmUgd2lsbCBub3QgZGVjaWRlIHRvIGRlZmluZSBpdC4KKyAgICBpZiAoZGVmdW5kZWYgPT0gInVu
ZGVmIikgeworICAgICAgcHJpbnQgIi8qIiwgcHJlZml4IGRlZnVuZGVmLCBtYWNybywgIiovIgor
ICAgICAgbmV4dAorICAgIH0KKyAgfQorfQoreyBwcmludCB9CitfQUNBV0sKK19BQ0VPRgorY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorICBhc19mbl9l
cnJvciAkPyAiY291bGQgbm90IHNldHVwIGNvbmZpZyBoZWFkZXJzIG1hY2hpbmVyeSIgIiRMSU5F
Tk8iIDUKK2ZpICMgdGVzdCAtbiAiJENPTkZJR19IRUFERVJTIgorCisKK2V2YWwgc2V0IFggIiAg
OkYgJENPTkZJR19GSUxFUyAgOkggJENPTkZJR19IRUFERVJTICAgICIKK3NoaWZ0Citmb3IgYWNf
dGFnCitkbworICBjYXNlICRhY190YWcgaW4KKyAgOltGSExDXSkgYWNfbW9kZT0kYWNfdGFnOyBj
b250aW51ZTs7CisgIGVzYWMKKyAgY2FzZSAkYWNfbW9kZSRhY190YWcgaW4KKyAgOltGSExdKjoq
KTs7CisgIDpMKiB8IDpDKjoqKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB0YWcgXGAkYWNfdGFn
JyIgIiRMSU5FTk8iIDU7OworICA6W0ZIXS0pIGFjX3RhZz0tOi07OworICA6W0ZIXSopIGFjX3Rh
Zz0kYWNfdGFnOiRhY190YWcuaW47OworICBlc2FjCisgIGFjX3NhdmVfSUZTPSRJRlMKKyAgSUZT
PToKKyAgc2V0IHggJGFjX3RhZworICBJRlM9JGFjX3NhdmVfSUZTCisgIHNoaWZ0CisgIGFjX2Zp
bGU9JDEKKyAgc2hpZnQKKworICBjYXNlICRhY19tb2RlIGluCisgIDpMKSBhY19zb3VyY2U9JDE7
OworICA6W0ZIXSkKKyAgICBhY19maWxlX2lucHV0cz0KKyAgICBmb3IgYWNfZgorICAgIGRvCisg
ICAgICBjYXNlICRhY19mIGluCisgICAgICAtKSBhY19mPSIkYWNfdG1wL3N0ZGluIjs7CisgICAg
ICAqKSAjIExvb2sgZm9yIHRoZSBmaWxlIGZpcnN0IGluIHRoZSBidWlsZCB0cmVlLCB0aGVuIGlu
IHRoZSBzb3VyY2UgdHJlZQorCSAjIChpZiB0aGUgcGF0aCBpcyBub3QgYWJzb2x1dGUpLiAgVGhl
IGFic29sdXRlIHBhdGggY2Fubm90IGJlIERPUy1zdHlsZSwKKwkgIyBiZWNhdXNlICRhY19mIGNh
bm5vdCBjb250YWluIGA6Jy4KKwkgdGVzdCAtZiAiJGFjX2YiIHx8CisJICAgY2FzZSAkYWNfZiBp
bgorCSAgIFtcXC8kXSopIGZhbHNlOzsKKwkgICAqKSB0ZXN0IC1mICIkc3JjZGlyLyRhY19mIiAm
JiBhY19mPSIkc3JjZGlyLyRhY19mIjs7CisJICAgZXNhYyB8fAorCSAgIGFzX2ZuX2Vycm9yIDEg
ImNhbm5vdCBmaW5kIGlucHV0IGZpbGU6IFxgJGFjX2YnIiAiJExJTkVOTyIgNTs7CisgICAgICBl
c2FjCisgICAgICBjYXNlICRhY19mIGluICpcJyopIGFjX2Y9YCRhc19lY2hvICIkYWNfZiIgfCBz
ZWQgInMvJy8nXFxcXFxcXFwnJy9nImA7OyBlc2FjCisgICAgICBhc19mbl9hcHBlbmQgYWNfZmls
ZV9pbnB1dHMgIiAnJGFjX2YnIgorICAgIGRvbmUKKworICAgICMgTGV0J3Mgc3RpbGwgcHJldGVu
ZCBpdCBpcyBgY29uZmlndXJlJyB3aGljaCBpbnN0YW50aWF0ZXMgKGkuZS4sIGRvbid0CisgICAg
IyB1c2UgJGFzX21lKSwgcGVvcGxlIHdvdWxkIGJlIHN1cnByaXNlZCB0byByZWFkOgorICAgICMg
ICAgLyogY29uZmlnLmguICBHZW5lcmF0ZWQgYnkgY29uZmlnLnN0YXR1cy4gICovCisgICAgY29u
ZmlndXJlX2lucHV0PSdHZW5lcmF0ZWQgZnJvbSAnYAorCSAgJGFzX2VjaG8gIiQqIiB8IHNlZCAn
c3xeW146XSovfHw7c3w6W146XSovfCwgfGcnCisJYCcgYnkgY29uZmlndXJlLicKKyAgICBpZiB0
ZXN0IHgiJGFjX2ZpbGUiICE9IHgtOyB0aGVuCisgICAgICBjb25maWd1cmVfaW5wdXQ9IiRhY19m
aWxlLiAgJGNvbmZpZ3VyZV9pbnB1dCIKKyAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY3JlYXRpbmcgJGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTog
Y3JlYXRpbmcgJGFjX2ZpbGUiID4mNjt9CisgICAgZmkKKyAgICAjIE5ldXRyYWxpemUgc3BlY2lh
bCBjaGFyYWN0ZXJzIGludGVycHJldGVkIGJ5IHNlZCBpbiByZXBsYWNlbWVudCBzdHJpbmdzLgor
ICAgIGNhc2UgJGNvbmZpZ3VyZV9pbnB1dCBpbiAjKAorICAgICpcJiogfCAqXHwqIHwgKlxcKiAp
CisgICAgICAgYWNfc2VkX2NvbmZfaW5wdXQ9YCRhc19lY2hvICIkY29uZmlndXJlX2lucHV0IiB8
CisgICAgICAgc2VkICdzL1tcXFxcJnxdL1xcXFwmL2cnYDs7ICMoCisgICAgKikgYWNfc2VkX2Nv
bmZfaW5wdXQ9JGNvbmZpZ3VyZV9pbnB1dDs7CisgICAgZXNhYworCisgICAgY2FzZSAkYWNfdGFn
IGluCisgICAgKjotOiogfCAqOi0pIGNhdCA+IiRhY190bXAvc3RkaW4iIFwKKyAgICAgIHx8IGFz
X2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNSA7Owor
ICAgIGVzYWMKKyAgICA7OworICBlc2FjCisKKyAgYWNfZGlyPWAkYXNfZGlybmFtZSAtLSAiJGFj
X2ZpbGUiIHx8CiskYXNfZXhwciBYIiRhY19maWxlIiA6ICdYXCguKlteL11cKS8vKlteL11bXi9d
Ki8qJCcgXHwgXAorCSBYIiRhY19maWxlIiA6ICdYXCgvL1wpW14vXScgXHwgXAorCSBYIiRhY19m
aWxlIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRhY19maWxlIiA6ICdYXCgvXCknIFx8IC4gMj4v
ZGV2L251bGwgfHwKKyRhc19lY2hvIFgiJGFjX2ZpbGUiIHwKKyAgICBzZWQgJy9eWFwoLipbXi9d
XClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15Y
XChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wv
XCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cKS4qL3sKKwkgICAg
cy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICBhc19kaXI9IiRhY19kaXIi
OyBhc19mbl9ta2Rpcl9wCisgIGFjX2J1aWxkZGlyPS4KKworY2FzZSAiJGFjX2RpciIgaW4KKy4p
IGFjX2Rpcl9zdWZmaXg9IGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4
PSA7OworKikKKyAgYWNfZGlyX3N1ZmZpeD0vYCRhc19lY2hvICIkYWNfZGlyIiB8IHNlZCAnc3xe
XC5bXFwvXXx8J2AKKyAgIyBBICIuLiIgZm9yIGVhY2ggZGlyZWN0b3J5IGluICRhY19kaXJfc3Vm
Zml4LgorICBhY190b3BfYnVpbGRkaXJfc3ViPWAkYXNfZWNobyAiJGFjX2Rpcl9zdWZmaXgiIHwg
c2VkICdzfC9bXlxcL10qfC8uLnxnO3N8L3x8J2AKKyAgY2FzZSAkYWNfdG9wX2J1aWxkZGlyX3N1
YiBpbgorICAiIikgYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7
CisgICopICBhY190b3BfYnVpbGRfcHJlZml4PSRhY190b3BfYnVpbGRkaXJfc3ViLyA7OworICBl
c2FjIDs7Citlc2FjCithY19hYnNfdG9wX2J1aWxkZGlyPSRhY19wd2QKK2FjX2Fic19idWlsZGRp
cj0kYWNfcHdkJGFjX2Rpcl9zdWZmaXgKKyMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk6Cith
Y190b3BfYnVpbGRkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgKKworY2FzZSAkc3JjZGlyIGluCisg
IC4pICAjIFdlIGFyZSBidWlsZGluZyBpbiBwbGFjZS4KKyAgICBhY19zcmNkaXI9LgorICAgIGFj
X3RvcF9zcmNkaXI9JGFjX3RvcF9idWlsZGRpcl9zdWIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0k
YWNfcHdkIDs7CisgIFtcXC9dKiB8ID86W1xcL10qICkgICMgQWJzb2x1dGUgbmFtZS4KKyAgICBh
Y19zcmNkaXI9JHNyY2RpciRhY19kaXJfc3VmZml4OworICAgIGFjX3RvcF9zcmNkaXI9JHNyY2Rp
cgorICAgIGFjX2Fic190b3Bfc3JjZGlyPSRzcmNkaXIgOzsKKyAgKikgIyBSZWxhdGl2ZSBuYW1l
LgorICAgIGFjX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIkYWNfZGlyX3N1ZmZp
eAorICAgIGFjX3RvcF9zcmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyCisgICAgYWNf
YWJzX3RvcF9zcmNkaXI9JGFjX3B3ZC8kc3JjZGlyIDs7Citlc2FjCithY19hYnNfc3JjZGlyPSRh
Y19hYnNfdG9wX3NyY2RpciRhY19kaXJfc3VmZml4CisKKworICBjYXNlICRhY19tb2RlIGluCisg
IDpGKQorICAjCisgICMgQ09ORklHX0ZJTEUKKyAgIworCisgIGNhc2UgJElOU1RBTEwgaW4KKyAg
W1xcLyRdKiB8ID86W1xcL10qICkgYWNfSU5TVEFMTD0kSU5TVEFMTCA7OworICAqKSBhY19JTlNU
QUxMPSRhY190b3BfYnVpbGRfcHJlZml4JElOU1RBTEwgOzsKKyAgZXNhYworX0FDRU9GCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyMgSWYgdGhl
IHRlbXBsYXRlIGRvZXMgbm90IGtub3cgYWJvdXQgZGF0YXJvb3RkaXIsIGV4cGFuZCBpdC4KKyMg
RklYTUU6IFRoaXMgaGFjayBzaG91bGQgYmUgcmVtb3ZlZCBhIGZldyB5ZWFycyBhZnRlciAyLjYw
LgorYWNfZGF0YXJvb3RkaXJfaGFjaz07IGFjX2RhdGFyb290ZGlyX3NlZW49CithY19zZWRfZGF0
YXJvb3Q9JworL2RhdGFyb290ZGlyLyB7CisgIHAKKyAgcQorfQorL0BkYXRhZGlyQC9wCisvQGRv
Y2RpckAvcAorL0BpbmZvZGlyQC9wCisvQGxvY2FsZWRpckAvcAorL0BtYW5kaXJAL3AnCitjYXNl
IGBldmFsICJzZWQgLW4gXCJcJGFjX3NlZF9kYXRhcm9vdFwiICRhY19maWxlX2lucHV0cyJgIGlu
CisqZGF0YXJvb3RkaXIqKSBhY19kYXRhcm9vdGRpcl9zZWVuPXllczs7CisqQGRhdGFkaXJAKnwq
QGRvY2RpckAqfCpAaW5mb2RpckAqfCpAbG9jYWxlZGlyQCp8KkBtYW5kaXJAKikKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkYWNfZmlsZV9pbnB1
dHMgc2VlbXMgdG8gaWdub3JlIHRoZSAtLWRhdGFyb290ZGlyIHNldHRpbmciID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogV0FSTklORzogJGFjX2ZpbGVfaW5wdXRzIHNlZW1zIHRvIGlnbm9yZSB0aGUg
LS1kYXRhcm9vdGRpciBzZXR0aW5nIiA+JjI7fQorX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRV
UyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyAgYWNfZGF0YXJvb3RkaXJfaGFjaz0nCisg
IHMmQGRhdGFkaXJAJiRkYXRhZGlyJmcKKyAgcyZAZG9jZGlyQCYkZG9jZGlyJmcKKyAgcyZAaW5m
b2RpckAmJGluZm9kaXImZworICBzJkBsb2NhbGVkaXJAJiRsb2NhbGVkaXImZworICBzJkBtYW5k
aXJAJiRtYW5kaXImZworICBzJlxcXCR7ZGF0YXJvb3RkaXJ9JiRkYXRhcm9vdGRpciZnJyA7Owor
ZXNhYworX0FDRU9GCisKKyMgTmV1dHJhbGl6ZSBWUEFUSCB3aGVuIGAkc3JjZGlyJyA9IGAuJy4K
KyMgU2hlbGwgY29kZSBpbiBjb25maWd1cmUuYWMgbWlnaHQgc2V0IGV4dHJhc3ViLgorIyBGSVhN
RTogZG8gd2UgcmVhbGx5IHdhbnQgdG8gbWFpbnRhaW4gdGhpcyBmZWF0dXJlPworY2F0ID4+JENP
TkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCithY19zZWRfZXh0cmE9IiRh
Y192cHN1YgorJGV4dHJhc3ViCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VP
RiB8fCBhY193cml0ZV9mYWlsPTEKKzp0CisvQFthLXpBLVpfXVthLXpBLVpfMC05XSpALyFiCitz
fEBjb25maWd1cmVfaW5wdXRAfCRhY19zZWRfY29uZl9pbnB1dHw7dCB0CitzJkB0b3BfYnVpbGRk
aXJAJiRhY190b3BfYnVpbGRkaXJfc3ViJjt0IHQKK3MmQHRvcF9idWlsZF9wcmVmaXhAJiRhY190
b3BfYnVpbGRfcHJlZml4Jjt0IHQKK3MmQHNyY2RpckAmJGFjX3NyY2RpciY7dCB0CitzJkBhYnNf
c3JjZGlyQCYkYWNfYWJzX3NyY2RpciY7dCB0CitzJkB0b3Bfc3JjZGlyQCYkYWNfdG9wX3NyY2Rp
ciY7dCB0CitzJkBhYnNfdG9wX3NyY2RpckAmJGFjX2Fic190b3Bfc3JjZGlyJjt0IHQKK3MmQGJ1
aWxkZGlyQCYkYWNfYnVpbGRkaXImO3QgdAorcyZAYWJzX2J1aWxkZGlyQCYkYWNfYWJzX2J1aWxk
ZGlyJjt0IHQKK3MmQGFic190b3BfYnVpbGRkaXJAJiRhY19hYnNfdG9wX2J1aWxkZGlyJjt0IHQK
K3MmQElOU1RBTExAJiRhY19JTlNUQUxMJjt0IHQKKyRhY19kYXRhcm9vdGRpcl9oYWNrCisiCitl
dmFsIHNlZCBcIlwkYWNfc2VkX2V4dHJhXCIgIiRhY19maWxlX2lucHV0cyIgfCAkQVdLIC1mICIk
YWNfdG1wL3N1YnMuYXdrIiBcCisgID4kYWNfdG1wL291dCB8fCBhc19mbl9lcnJvciAkPyAiY291
bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUKKwordGVzdCAteiAiJGFjX2RhdGFy
b290ZGlyX2hhY2skYWNfZGF0YXJvb3RkaXJfc2VlbiIgJiYKKyAgeyBhY19vdXQ9YHNlZCAtbiAn
L1wke2RhdGFyb290ZGlyfS9wJyAiJGFjX3RtcC9vdXQiYDsgdGVzdCAtbiAiJGFjX291dCI7IH0g
JiYKKyAgeyBhY19vdXQ9YHNlZCAtbiAnL15bCSBdKmRhdGFyb290ZGlyWwkgXSo6Kj0vcCcgXAor
ICAgICAgIiRhY190bXAvb3V0ImA7IHRlc3QgLXogIiRhY19vdXQiOyB9ICYmCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJGFjX2ZpbGUgY29udGFp
bnMgYSByZWZlcmVuY2UgdG8gdGhlIHZhcmlhYmxlIFxgZGF0YXJvb3RkaXInCit3aGljaCBzZWVt
cyB0byBiZSB1bmRlZmluZWQuICBQbGVhc2UgbWFrZSBzdXJlIGl0IGlzIGRlZmluZWQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJGFjX2ZpbGUgY29udGFpbnMgYSByZWZlcmVuY2Ug
dG8gdGhlIHZhcmlhYmxlIFxgZGF0YXJvb3RkaXInCit3aGljaCBzZWVtcyB0byBiZSB1bmRlZmlu
ZWQuICBQbGVhc2UgbWFrZSBzdXJlIGl0IGlzIGRlZmluZWQiID4mMjt9CisKKyAgcm0gLWYgIiRh
Y190bXAvc3RkaW4iCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgLSkgY2F0ICIkYWNfdG1wL291dCIg
JiYgcm0gLWYgIiRhY190bXAvb3V0Ijs7CisgICopIHJtIC1mICIkYWNfZmlsZSIgJiYgbXYgIiRh
Y190bXAvb3V0IiAiJGFjX2ZpbGUiOzsKKyAgZXNhYyBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJj
b3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorIDs7CisgIDpIKQorICAjCisg
ICMgQ09ORklHX0hFQURFUgorICAjCisgIGlmIHRlc3QgeCIkYWNfZmlsZSIgIT0geC07IHRoZW4K
KyAgICB7CisgICAgICAkYXNfZWNobyAiLyogJGNvbmZpZ3VyZV9pbnB1dCAgKi8iIFwKKyAgICAg
ICYmIGV2YWwgJyRBV0sgLWYgIiRhY190bXAvZGVmaW5lcy5hd2siJyAiJGFjX2ZpbGVfaW5wdXRz
IgorICAgIH0gPiIkYWNfdG1wL2NvbmZpZy5oIiBcCisgICAgICB8fCBhc19mbl9lcnJvciAkPyAi
Y291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUKKyAgICBpZiBkaWZmICIkYWNf
ZmlsZSIgIiRhY190bXAvY29uZmlnLmgiID4vZGV2L251bGwgMj4mMTsgdGhlbgorICAgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfZmlsZSBpcyB1bmNoYW5n
ZWQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogJGFjX2ZpbGUgaXMgdW5jaGFuZ2VkIiA+JjY7fQor
ICAgIGVsc2UKKyAgICAgIHJtIC1mICIkYWNfZmlsZSIKKyAgICAgIG12ICIkYWNfdG1wL2NvbmZp
Zy5oIiAiJGFjX2ZpbGUiIFwKKwl8fCBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IGNyZWF0ZSAk
YWNfZmlsZSIgIiRMSU5FTk8iIDUKKyAgICBmaQorICBlbHNlCisgICAgJGFzX2VjaG8gIi8qICRj
b25maWd1cmVfaW5wdXQgICovIiBcCisgICAgICAmJiBldmFsICckQVdLIC1mICIkYWNfdG1wL2Rl
ZmluZXMuYXdrIicgIiRhY19maWxlX2lucHV0cyIgXAorICAgICAgfHwgYXNfZm5fZXJyb3IgJD8g
ImNvdWxkIG5vdCBjcmVhdGUgLSIgIiRMSU5FTk8iIDUKKyAgZmkKKyA7OworCisKKyAgZXNhYwor
Citkb25lICMgZm9yIGFjX3RhZworCisKK2FzX2ZuX2V4aXQgMAorX0FDRU9GCithY19jbGVhbl9m
aWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQorCit0ZXN0ICRhY193cml0ZV9mYWlsID0gMCB8fAor
ICBhc19mbl9lcnJvciAkPyAid3JpdGUgZmFpbHVyZSBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIg
IiRMSU5FTk8iIDUKKworCisjIGNvbmZpZ3VyZSBpcyB3cml0aW5nIHRvIGNvbmZpZy5sb2csIGFu
ZCB0aGVuIGNhbGxzIGNvbmZpZy5zdGF0dXMuCisjIGNvbmZpZy5zdGF0dXMgZG9lcyBpdHMgb3du
IHJlZGlyZWN0aW9uLCBhcHBlbmRpbmcgdG8gY29uZmlnLmxvZy4KKyMgVW5mb3J0dW5hdGVseSwg
b24gRE9TIHRoaXMgZmFpbHMsIGFzIGNvbmZpZy5sb2cgaXMgc3RpbGwga2VwdCBvcGVuCisjIGJ5
IGNvbmZpZ3VyZSwgc28gY29uZmlnLnN0YXR1cyB3b24ndCBiZSBhYmxlIHRvIHdyaXRlIHRvIGl0
OyBpdHMKKyMgb3V0cHV0IGlzIHNpbXBseSBkaXNjYXJkZWQuICBTbyB3ZSBleGVjIHRoZSBGRCB0
byAvZGV2L251bGwsCisjIGVmZmVjdGl2ZWx5IGNsb3NpbmcgY29uZmlnLmxvZywgc28gaXQgY2Fu
IGJlIHByb3Blcmx5IChyZSlvcGVuZWQgYW5kCisjIGFwcGVuZGVkIHRvIGJ5IGNvbmZpZy5zdGF0
dXMuICBXaGVuIGNvbWluZyBiYWNrIHRvIGNvbmZpZ3VyZSwgd2UKKyMgbmVlZCB0byBtYWtlIHRo
ZSBGRCBhdmFpbGFibGUgYWdhaW4uCitpZiB0ZXN0ICIkbm9fY3JlYXRlIiAhPSB5ZXM7IHRoZW4K
KyAgYWNfY3Nfc3VjY2Vzcz06CisgIGFjX2NvbmZpZ19zdGF0dXNfYXJncz0KKyAgdGVzdCAiJHNp
bGVudCIgPSB5ZXMgJiYKKyAgICBhY19jb25maWdfc3RhdHVzX2FyZ3M9IiRhY19jb25maWdfc3Rh
dHVzX2FyZ3MgLS1xdWlldCIKKyAgZXhlYyA1Pi9kZXYvbnVsbAorICAkU0hFTEwgJENPTkZJR19T
VEFUVVMgJGFjX2NvbmZpZ19zdGF0dXNfYXJncyB8fCBhY19jc19zdWNjZXNzPWZhbHNlCisgIGV4
ZWMgNT4+Y29uZmlnLmxvZworICAjIFVzZSB8fCwgbm90ICYmLCB0byBhdm9pZCBleGl0aW5nIGZy
b20gdGhlIGlmIHdpdGggJD8gPSAxLCB3aGljaAorICAjIHdvdWxkIG1ha2UgY29uZmlndXJlIGZh
aWwgaWYgdGhpcyBpcyB0aGUgbGFzdCBpbnN0cnVjdGlvbi4KKyAgJGFjX2NzX3N1Y2Nlc3MgfHwg
YXNfZm5fZXhpdCAxCitmaQoraWYgdGVzdCAtbiAiJGFjX3VucmVjb2duaXplZF9vcHRzIiAmJiB0
ZXN0ICIkZW5hYmxlX29wdGlvbl9jaGVja2luZyIgIT0gbm87IHRoZW4KKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1bnJlY29nbml6ZWQgb3B0aW9u
czogJGFjX3VucmVjb2duaXplZF9vcHRzIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IHVucmVjb2duaXplZCBvcHRpb25zOiAkYWNfdW5yZWNvZ25pemVkX29wdHMiID4mMjt9CitmaQor
CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jb25maWd1cmUuYWMK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMv
Y29uZmlndXJlLmFjCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDE5
MSBAQAorIyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSot
IEF1dG9jb25mIC0qLQorIyBQcm9jZXNzIHRoaXMgZmlsZSB3aXRoIGF1dG9jb25mIHRvIHByb2R1
Y2UgYSBjb25maWd1cmUgc2NyaXB0LgorCitBQ19QUkVSRVEoWzIuNjddKQorQUNfSU5JVChbWGVu
IEh5cGVydmlzb3JdLCBtNF9lc3lzY21kKFsuLi92ZXJzaW9uLnNoIC4uL3hlbi9NYWtlZmlsZV0p
LAorICAgIFt4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbV0pCitBQ19DT05GSUdfU1JDRElS
KFtsaWJ4bC9saWJ4bC5jXSkKK0FDX0NPTkZJR19GSUxFUyhbLi4vY29uZmlnL1Rvb2xzLm1rXSkK
K0FDX0NPTkZJR19IRUFERVJTKFtjb25maWcuaF0pCitBQ19QUkVGSVhfREVGQVVMVChbL3Vzcl0p
CitBQ19DT05GSUdfQVVYX0RJUihbLl0pCisKKyMgQ2hlY2sgaWYgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5pbmcKKworQVNfSUYo
W3Rlc3QgLW4gIiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQUCJdLCBbCisgICAg
QUNfTVNHX1dBUk4oCitbU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdTLCBMSUJTLCBDUFBGTEFH
UyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVORF9JTkNMVURFUywgUFJF
UEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBpbnN0ZWFkIHdoZW4g
cG9zc2libGUuXSkKK10pCisKK0FDX1VTRV9TWVNURU1fRVhURU5TSU9OUworQUNfQ0FOT05JQ0FM
X0hPU1QKKworIyBNNCBNYWNybyBpbmNsdWRlcworbTRfaW5jbHVkZShbbTQvZW5hYmxlX2ZlYXR1
cmUubTRdKQorbTRfaW5jbHVkZShbbTQvZGlzYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUo
W200L3BhdGhfb3JfZmFpbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25feG1sLm00XSkKK200
X2luY2x1ZGUoW200L3B5dGhvbl92ZXJzaW9uLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl9k
ZXZlbC5tNF0pCittNF9pbmNsdWRlKFttNC91ZGV2Lm00XSkKK200X2luY2x1ZGUoW200L29jYW1s
Lm00XSkKK200X2luY2x1ZGUoW200L2RlZmF1bHRfbGliLm00XSkKK200X2luY2x1ZGUoW200L3Nl
dF9jZmxhZ3NfbGRmbGFncy5tNF0pCittNF9pbmNsdWRlKFttNC91dWlkLm00XSkKKworIyBFbmFi
bGUvZGlzYWJsZSBvcHRpb25zCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCisgICAg
W0VuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzayldKQorQVhfQVJH
X0VOQUJMRV9BTkRfRVhQT1JUKFtnaXRodHRwXSwgW0Rvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMg
dmlhIEhUVFBdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbbW9uaXRvcnNdLAorICAgIFtE
aXNhYmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzXSkKK0FYX0FSR19FTkFC
TEVfQU5EX0VYUE9SVChbdnRwbV0sIFtFbmFibGUgVmlydHVhbCBUcnVzdGVkIFBsYXRmb3JtIE1v
ZHVsZV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hhcGldLCBbRW5hYmxlIFhlbiBBUEkg
QmluZGluZ3NdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbcHl0aG9udG9vbHNdLCBbRGlz
YWJsZSBQeXRob24gdG9vbHNdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbb2NhbWx0b29s
c10sIFtEaXNhYmxlIE9jYW1sIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbWlu
aXRlcm1dLCBbRW5hYmxlIG1pbml0ZXJtXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbG9t
b3VudF0sIFtFbmFibGUgbG9tb3VudF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtkZWJ1
Z10sIFtEaXNhYmxlIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQgdG9vbHNdKQorCitBQ19BUkdfVkFS
KFtQUkVQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJl
cGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW1BSRVBFTkRfTElCXSwK
KyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRo
b3V0IC1MKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGlu
Y2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdf
VkFSKFtBUFBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gYXBwZW5k
IHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKKworQVhfU0VUX0ZMQUdTCisKK0FDX0FSR19WQVIo
W1BZVEhPTl0sIFtQYXRoIHRvIHRoZSBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxd
LCBbUGF0aCB0byBQZXJsIHBhcnNlcl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJy
Y3RsIHRvb2xdKQorQUNfQVJHX1ZBUihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19W
QVIoW0JJU09OXSwgW1BhdGggdG8gQmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFS
KFtGTEVYXSwgW1BhdGggdG8gRmxleCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19B
UkdfVkFSKFtDVVJMXSwgW1BhdGggdG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtY
TUxdLCBbUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0
aCB0byBiYXNoIHNoZWxsXSkKK0FDX0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0
ZXh0IHRvb2xdKQorCisjIENoZWNrcyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJP
R19DQworQUNfUFJPR19MTl9TCitBQ19QUk9HX01BS0VfU0VUCitBQ19QUk9HX0lOU1RBTEwKK0FY
X1BBVEhfUFJPR19PUl9GQUlMKFtQRVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwo
W0JSQ1RMXSwgW2JyY3RsXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9Q
QVRIX1BST0dfT1JfRkFJTChbQklTT05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwo
W0ZMRVhdLCBbZmxleF0pCitBU19JRihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhf
UEFUSF9QUk9HX09SX0ZBSUwoW0NVUkxdLCBbY3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJP
R19PUl9GQUlMKFtYTUxdLCBbeG1sMi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1s
dG9vbHMiID0gInh5Il0sIFsKKyAgICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngk
T0NBTUxDIiA9ICJ4bm8iXSwgWworICAgICAgICBBU19JRihbdGVzdCAieCRlbmFibGVfb2NhbWx0
b29scyIgPSAieHllcyJdLCBbCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoW09jYW1sIHRvb2xz
IGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmluZCBPY2FtbF0pXSkKKyAgICAgICAgb2NhbWx0b29s
cz0ibiIKKyAgICBdKQorXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCQVNIXSwgW2Jhc2hdKQor
QVNfSUYoW3Rlc3QgIngkcHl0aG9udG9vbHMiID0gInh5Il0sIFsKKyAgICBBU19JRihbZWNobyAi
JFBZVEhPTiIgfCBncmVwIC1xICJeLyJdLCBbCisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgor
ICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorICAgIF0sW3Rlc3QgLXogIiRQ
WVRIT04iXSwgW1BZVEhPTj0icHl0aG9uIl0sCisgICAgW0FDX01TR19FUlJPUihbUFlUSE9OIHNw
ZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoXSldKQorICAgIEFYX1BBVEhfUFJP
R19PUl9GQUlMKFtQWVRIT05QQVRIXSwgWyRQWVRIT05dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9W
RVJTSU9OKFsyXSwgWzNdKQorICAgIEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNL
X1BZVEhPTl9ERVZFTCgpCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hn
ZXR0ZXh0XSkKK0FYX0NIRUNLX1VERVYoWzU5XSkKK0FYX0NIRUNLX1VVSUQKKworIyBDaGVjayBs
aWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRfTElCCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCitB
Q19DSEVDS19MSUIoW2Fpb10sIFtpb19zZXR1cF0sIFtzeXN0ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1f
YWlvPSJuIl0pCitBQ19TVUJTVChzeXN0ZW1fYWlvKQorQUNfQ0hFQ0tfTElCKFtjcnlwdG9dLCBb
TUQ1XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYmNyeXB0b10pXSkKK0FD
X0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4dDJmc19vcGVuMl0sIFtsaWJleHQyZnM9InkiXSwgW2xp
YmV4dDJmcz0ibiJdKQorQUNfU1VCU1QobGliZXh0MmZzKQorQUNfQ0hFQ0tfTElCKFtnY3J5cHRd
LCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJd
KQorQUNfU1VCU1QobGliZ2NyeXB0KQorQUNfQ0hFQ0tfTElCKFtwdGhyZWFkXSwgW3B0aHJlYWRf
Y3JlYXRlXSwgW10gLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnB0aHJl
YWRdKV0pCitBQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2NrX2dldHRpbWVdKQorQUNfQ0hFQ0tfTElC
KFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3Qg
ZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwK
KyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5YWpsXSldKQorQUNfQ0hFQ0tfTElC
KFt6XSwgW2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHps
aWJdKV0pCitBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmljb252X29wZW5dLCBbbGliaWNvbnY9
InkiXSwgW2xpYmljb252PSJuIl0pCitBQ19TVUJTVChsaWJpY29udikKKworIyBBdXRvc2NhbiBz
dHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNrKQorIyBDaGVja3MgZm9y
IGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNfQUxMT0NBCitBQ19DSEVDS19IRUFERVJTKFsgXAorICAg
ICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGlt
aXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0
ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJp
bmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisg
ICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNs
b2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJz
aW9uLmggXAorICAgICAgICAgICAgICAgIF0pCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3Ry
dWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KK0FDX0hFQURFUl9TVERCT09M
CitBQ19UWVBFX1VJRF9UCitBQ19DX0lOTElORQorQUNfVFlQRV9JTlQxNl9UCitBQ19UWVBFX0lO
VDMyX1QKK0FDX1RZUEVfSU5UNjRfVAorQUNfVFlQRV9JTlQ4X1QKK0FDX1RZUEVfTU9ERV9UCitB
Q19UWVBFX09GRl9UCitBQ19UWVBFX1BJRF9UCitBQ19DX1JFU1RSSUNUCitBQ19UWVBFX1NJWkVf
VAorQUNfVFlQRV9TU0laRV9UCitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9ibGtz
aXplXSkKK0FDX1NUUlVDVF9TVF9CTE9DS1MKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0
LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5UMTZfVAorQUNfVFlQRV9VSU5UMzJfVAorQUNfVFlQRV9V
SU5UNjRfVAorQUNfVFlQRV9VSU5UOF9UCitBQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKKwor
IyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgorQUNfRlVOQ19FUlJPUl9BVF9MSU5FCitB
Q19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNFRUtPCitBQ19GVU5DX0xTVEFUX0ZPTExPV1NfU0xBU0hF
RF9TWU1MSU5LCitBQ19IRUFERVJfTUFKT1IKK0FDX0ZVTkNfTUFMTE9DCitBQ19GVU5DX01LVElN
RQorQUNfRlVOQ19NTUFQCitBQ19GVU5DX1JFQUxMT0MKK0FDX0ZVTkNfU1RSTkxFTgorQUNfRlVO
Q19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhp
dCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisgICAgICAg
ICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0
dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVf
ciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAgICAgICAgICAgICAgIG1rZmlmbyBt
dW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKKyAg
ICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJkdXAgc3Ry
ZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBz
dHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAorICAgICAgICAgICAgICAgIHVu
YW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIGUyNzIyYjI0
ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUKLS0t
IGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJVGh1IEphbiAyNiAxNzo0MzozMSAy
MDEyICswMDAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCVdlZCBKYW4g
MTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMjEsNyArMjEsNiBAQCB4Z19hbGwuYTogJChYR19P
QkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMgLW8gJEAgJF4KIAogeGVu
LWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVjayAKIAkkKE1BS0UpIC1DIC4uLy4u
Ly4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4uYyBNYWtlZmlsZSAkKFhHX0hEUlMp
CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9pbnN0YWxsLnNoCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2lu
c3RhbGwuc2gJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMSBAQAor
Li4vaW5zdGFsbC5zaApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciBlMjcyMmIy
NGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUKLS0tIGEvdG9v
bHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAx
MDAKQEAgLTIsNyArMiwxMSBAQCBYRU5fUk9PVCA9ICQoQ1VSRElSKS8uLi8uLgogaW5jbHVkZSAk
KFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNl
cmZzIGlzbzk2NjAgZmF0IHpmcyB4ZnMKLVNVQkRJUlMteSArPSAkKHNoZWxsIGVudiBDQz0iJChD
QykiIC4vY2hlY2stbGliZXh0MmZzKQoraWZlcSAoJChDT05GSUdfRVhUMkZTKSwgeSkKKyAgICBT
VUJESVJTLXkgKz0gZXh0MmZzLWxpYgorZWxzZQorICAgIFNVQkRJUlMteSArPSBleHQyZnMKK2Vu
ZGlmCiAKIC5QSE9OWTogYWxsIGNsZWFuIGluc3RhbGwKIGFsbCBjbGVhbiBpbnN0YWxsOiAlOiBz
dWJkaXJzLSUKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2xpYmZz
aW1hZ2UvY2hlY2stbGliZXh0MmZzCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0
MmZzCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMSArMCwwIEBACi0jIS9iaW4vc2gKLQotY2F0
ID5leHQyLXRlc3QuYyA8PEVPRgotI2luY2x1ZGUgPGV4dDJmcy9leHQyZnMuaD4KLQotaW50IG1h
aW4oKQotewotCWV4dDJmc19vcGVuMjsKLX0KLUVPRgotCi0ke0NDLWdjY30gLW8gZXh0Mi10ZXN0
IGV4dDItdGVzdC5jIC1sZXh0MmZzID4vZGV2L251bGwgMj4mMQotaWYgWyAkPyA9IDAgXTsgdGhl
bgotCWVjaG8gZXh0MmZzLWxpYgotZWxzZQotCWVjaG8gZXh0MmZzCi1maQotCi1ybSAtZiBleHQy
LXRlc3QgZXh0Mi10ZXN0LmMKLQotZXhpdCAwCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3
MGU1MzlhMSB0b29scy9saWJ4ZW4vTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGVuL01ha2VmaWxl
CVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgYi90b29scy9saWJ4ZW4vTWFrZWZp
bGUJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0yMiwxMiArMjIsMTIgQEAgTUFK
T1IgPSAxLjAKIE1JTk9SID0gMAogCiBDRkxBR1MgKz0gLUlpbmNsdWRlICAgICAgICAgICAgICAg
ICAgICAgXAotICAgICAgICAgICQoc2hlbGwgeG1sMi1jb25maWcgLS1jZmxhZ3MpIFwKLSAgICAg
ICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAk
KFhNTDJfQ09ORklHKSAtLWNmbGFncykgXAorICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJ
RykgLS1jZmxhZ3MpIFwKICAgICAgICAgICAtZlBJQwogCi1MREZMQUdTICs9ICQoc2hlbGwgeG1s
Mi1jb25maWcgLS1saWJzKSBcCi0gICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1saWJz
KQorTERGTEFHUyArPSAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tbGlicykgXAorICAgICAgICAg
ICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tbGlicykKIAogTElCWEVOQVBJX0hEUlMgPSAkKHdp
bGRjYXJkIGluY2x1ZGUveGVuL2FwaS8qLmgpIGluY2x1ZGUveGVuL2FwaS94ZW5fYWxsLmgKIExJ
QlhFTkFQSV9PQkpTID0gJChwYXRzdWJzdCAlLmMsICUubywgJCh3aWxkY2FyZCBzcmMvKi5jKSkK
ZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL200L2RlZmF1bHRfbGli
Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL200L2RlZmF1bHRfbGliLm00CVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAt
MCwwICsxLDggQEAKK0FDX0RFRlVOKFtBWF9ERUZBVUxUX0xJQl0sCitbQVNfSUYoW3Rlc3QgLWQg
IiRwcmVmaXgvbGliNjQiXSwgWworICAgIExJQl9QQVRIPSJsaWI2NCIKK10sWworICAgIExJQl9Q
QVRIPSJsaWIiCitdKQorQUNfU1VCU1QoTElCX1BBVEgpXSkKKwpkaWZmIC1yIGUyNzIyYjI0ZGMw
OSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvbTQvZGlzYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2Rpc2FibGVf
ZmVhdHVyZS5tNAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMyBA
QAorQUNfREVGVU4oW0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUo
WyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhbLS1kaXNhYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lG
KFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0
ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVz
dCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdKQorJDE9JGF4X2N2XyQxCitB
Q19TVUJTVCgkMSldKQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMv
bTQvZW5hYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQJV2VkIEphbiAxMSAwNjow
NzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRU5BQkxF
X0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhb
LS1lbmFibGUtJDFdLCBbJDJdKSkKKworQVNfSUYoW3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4eWVz
Il0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0s
IFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0IC16ICRheF9jdl8kMV0sIFsKKyAgICBheF9j
dl8kMT0ibiIKK10pCiskMT0kYXhfY3ZfJDEKK0FDX1NVQlNUKCQxKV0pCmRpZmYgLXIgZTI3MjJi
MjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC9vY2FtbC5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9vY2FtbC5tNAlXZWQg
SmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyNDEgQEAKK2RubCBhdXRvY29u
ZiBtYWNyb3MgZm9yIE9DYW1sCitkbmwgZnJvbSBodHRwOi8vZm9yZ2Uub2NhbWxjb3JlLm9yZy8K
K2RubAorZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgUmljaGFyZCBXLk0uIEpvbmVzCitkbmwg
Q29weXJpZ2h0IMKpIDIwMDkgICAgICBTdGVmYW5vIFphY2NoaXJvbGkKK2RubCBDb3B5cmlnaHQg
wqkgMjAwMC0yMDA1IE9saXZpZXIgQW5kcmlldQorZG5sIENvcHlyaWdodCDCqSAyMDAwLTIwMDUg
SmVhbi1DaHJpc3RvcGhlIEZpbGxpw6J0cmUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEdl
b3JnZXMgTWFyaWFubworZG5sCitkbmwgRm9yIGRvY3VtZW50YXRpb24sIHBsZWFzZSByZWFkIHRo
ZSBvY2FtbC5tNCBtYW4gcGFnZS4KKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxdLAorW2RubAor
ICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxDXSxbb2NhbWxj
XSxbbm9dKQorCisgIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxW
RVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8
cCdgCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTl0p
CisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAgaWYgdGVzdCAiJE9DQU1M
TElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYv
bnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAorICAgICBlbHNlCisg
ICAgICAgIEFDX01TR19SRVNVTFQoW09DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5n
IGl0Ll0pCisgICAgIGZpCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIGxpYnJhcnkgcGF0aCBp
cyAkT0NBTUxMSUJdKQorCisgICAgIEFDX1NVQlNUKFtPQ0FNTFZFUlNJT05dKQorICAgICBBQ19T
VUJTVChbT0NBTUxMSUJdKQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIEFD
X0NIRUNLX1RPT0woW09DQU1MT1BUXSxbb2NhbWxvcHRdLFtub10pCisgICAgIE9DQU1MQkVTVD1i
eXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCisJQUNfTVNHX1dBUk4o
W0Nhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5Ll0pCisgICAg
IGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9u
KiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJT
SU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j
YW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLl0pCisJICAgIE9DQU1MT1BUPW5vCisJZWxzZQorCSAg
ICBPQ0FNTEJFU1Q9b3B0CisJZmkKKyAgICAgZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxCRVNU
XSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0CisgICAgIEFDX0NIRUNLX1RPT0wo
W09DQU1MQ0RPVE9QVF0sW29jYW1sYy5vcHRdLFtub10pCisgICAgIGlmIHRlc3QgIiRPQ0FNTENE
T1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12IHwgc2Vk
IC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJT
SU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNp
b25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLl0pCisJZWxzZQor
CSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRo
ZW4KKwlBQ19DSEVDS19UT09MKFtPQ0FNTE9QVERPVE9QVF0sW29jYW1sb3B0Lm9wdF0sW25vXSkK
KwlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9O
PWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxc
MXxwJyBgCisJICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRo
ZW4KKwkgICAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9j
YW1sb3B0Lm9wdCBkaXNjYXJkZWQuXSkKKwkgICBlbHNlCisJICAgICAgT0NBTUxPUFQ9JE9DQU1M
T1BURE9UT1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAgZmkKKworICAgICBBQ19TVUJTVChb
T0NBTUxPUFRdKQorICBmaQorCisgIEFDX1NVQlNUKFtPQ0FNTENdKQorCisgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sIHRvcGxldmVsCisgIEFDX0NIRUNLX1RPT0woW09DQU1MXSxbb2NhbWxdLFtub10p
CisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxERVBd
LFtvY2FtbGRlcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIEFDX0NI
RUNLX1RPT0woW09DQU1MTUtUT1BdLFtvY2FtbG1rdG9wXSxbbm9dKQorCisgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sbWtsaWIKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxNS0xJQl0sW29jYW1sbWtsaWJd
LFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgQUNfQ0hFQ0tfVE9PTChbT0NB
TUxET0NdLFtvY2FtbGRvY10sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisg
IEFDX0NIRUNLX1RPT0woW09DQU1MQlVJTERdLFtvY2FtbGJ1aWxkXSxbbm9dKQorXSkKKworCitB
Q19ERUZVTihbQUNfUFJPR19PQ0FNTExFWF0sCitbZG5sCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
bGV4CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYXSxbb2NhbWxsZXhdLFtub10pCisgIGlmIHRl
c3QgIiRPQ0FNTExFWCIgIT0gIm5vIjsgdGhlbgorICAgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVY
RE9UT1BUXSxbb2NhbWxsZXgub3B0XSxbbm9dKQorICAgIGlmIHRlc3QgIiRPQ0FNTExFWERPVE9Q
VCIgIT0gIm5vIjsgdGhlbgorCU9DQU1MTEVYPSRPQ0FNTExFWERPVE9QVAorICAgIGZpCisgIGZp
CisgIEFDX1NVQlNUKFtPQ0FNTExFWF0pCitdKQorCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTFlB
Q0NdLAorW2RubAorICBBQ19DSEVDS19UT09MKFtPQ0FNTFlBQ0NdLFtvY2FtbHlhY2NdLFtub10p
CisgIEFDX1NVQlNUKFtPQ0FNTFlBQ0NdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19DQU1M
UDRdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKworICAjIGNoZWNr
aW5nIGZvciBjYW1scDQKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0XSxbY2FtbHA0XSxbbm9dKQor
ICBpZiB0ZXN0ICIkQ0FNTFA0IiAhPSAibm8iOyB0aGVuCisgICAgIFRNUFZFUlNJT049YCRDQU1M
UDQgLXYgMj4mMXwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiAqXCguKlwpJHxcMXxwJ2AKKyAgICAg
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwlBQ19NU0df
UkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjXSkKKyAgICAgICAgQ0FNTFA0PW5v
CisgICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtDQU1MUDRdKQorCisgICMgY2hlY2tpbmcgZm9y
IGNvbXBhbmlvbiB0b29scworICBBQ19DSEVDS19UT09MKFtDQU1MUDRCT09UXSxbY2FtbHA0Ym9v
dF0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T10sW2NhbWxwNG9dLFtub10pCisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNE9GXSxbY2FtbHA0b2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0wo
W0NBTUxQNE9PRl0sW2NhbWxwNG9vZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T1JG
XSxbY2FtbHA0b3JmXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRQUk9GXSxbY2FtbHA0
cHJvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Ul0sW2NhbWxwNHJdLFtub10pCisg
IEFDX0NIRUNLX1RPT0woW0NBTUxQNFJGXSxbY2FtbHA0cmZdLFtub10pCisgIEFDX1NVQlNUKFtD
QU1MUDRCT09UXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9dKQorICBBQ19TVUJTVChbQ0FNTFA0T0Zd
KQorICBBQ19TVUJTVChbQ0FNTFA0T09GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9SRl0pCisgIEFD
X1NVQlNUKFtDQU1MUDRQUk9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJdKQorICBBQ19TVUJTVChb
Q0FNTFA0UkZdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19GSU5ETElCXSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxm
aW5kCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRklORF0sW29jYW1sZmluZF0sW25vXSkKKyAgQUNf
U1VCU1QoW09DQU1MRklORF0pCitdKQorCisKK2RubCBUaGFua3MgdG8gSmltIE1leWVyaW5nIGZv
ciB3b3JraW5nIHRoaXMgbmV4dCBiaXQgb3V0IGZvciB1cy4KK2RubCBYWFggV2Ugc2hvdWxkIGRl
ZmluZSBBU19UUl9TSCBpZiBpdCdzIG5vdCBkZWZpbmVkIGFscmVhZHkKK2RubCAoZWcuIGZvciBv
bGQgYXV0b2NvbmYpLgorQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1BLR10sCitbZG5sCisgIEFD
X1JFUVVJUkUoW0FDX1BST0dfRklORExJQl0pZG5sCisKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3Ig
T0NhbWwgZmluZGxpYiBwYWNrYWdlICQxXSkKKworICB1bnNldCBmb3VuZAorICB1bnNldCBwa2cK
KyAgZm91bmQ9bm8KKyAgZm9yIHBrZyBpbiAkMSAkMiA7IGRvCisgICAgaWYgJE9DQU1MRklORCBx
dWVyeSAkcGtnID4vZGV2L251bGwgMj4vZGV2L251bGw7IHRoZW4KKyAgICAgIEFDX01TR19SRVNV
TFQoW2ZvdW5kXSkKKyAgICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT0kcGtnCisgICAgICBm
b3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAgZG9uZQorICBpZiB0ZXN0ICIkZm91bmQi
ID0gIm5vIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQorICAgIEFTX1RS
X1NIKFtPQ0FNTF9QS0dfJDFdKT1ubworICBmaQorCisgIEFDX1NVQlNUKEFTX1RSX1NIKFtPQ0FN
TF9QS0dfJDFdKSkKK10pCisKKworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX01PRFVMRV0sCitb
ZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIG1vZHVsZSAkMl0pCisKKyAgY2F0ID4g
Y29uZnRlc3QubWwgPDxFT0YKK29wZW4gJDMKK0VPRgorICB1bnNldCBmb3VuZAorICBmb3IgJDEg
aW4gJCQxICQ0IDsgZG8KKyAgICBpZiAkT0NBTUxDIC1jIC1JICIkJDEiIGNvbmZ0ZXN0Lm1sID4m
NSAyPiY1IDsgdGhlbgorICAgICAgZm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRv
bmUKKworICBpZiB0ZXN0ICIkZm91bmQiIDsgdGhlbgorICAgIEFDX01TR19SRVNVTFQoWyQkMV0p
CisgIGVsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQorICAgICQxPW5vCisgIGZp
CisgIEFDX1NVQlNUKFskMV0pCitdKQorCisKK2RubCBYWFggQ3Jvc3MtY29tcGlsaW5nCitBQ19E
RUZVTihbQUNfQ0hFQ0tfT0NBTUxfV09SRF9TSVpFXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNf
UFJPR19PQ0FNTF0pZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGNvbXBpbGVyIHdv
cmQgc2l6ZV0pCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCisgIHByaW50X2VuZGxpbmUgKHN0
cmluZ19vZl9pbnQgU3lzLndvcmRfc2l6ZSkKKyAgRU9GCisgIE9DQU1MX1dPUkRfU0laRT1gJE9D
QU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFskT0NBTUxfV09SRF9TSVpFXSkKKyAg
QUNfU1VCU1QoW09DQU1MX1dPUkRfU0laRV0pCitdKQorCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NB
TUxfT1NfVFlQRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBB
Q19NU0dfQ0hFQ0tJTkcoW09DYW1sIFN5cy5vc190eXBlXSkKKworICBjYXQgPiBjb25mdGVzdC5t
bCA8PEVPRgorICBwcmludF9zdHJpbmcoU3lzLm9zX3R5cGUpOzsKK0VPRgorCisgIE9DQU1MX09T
X1RZUEU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX09TX1RZ
UEVdKQorICBBQ19TVUJTVChbT0NBTUxfT1NfVFlQRV0pCitdKQpkaWZmIC1yIGUyNzIyYjI0ZGMw
OSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvbTQvcGF0aF9vcl9mYWlsLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3BhdGhfb3JfZmFp
bC5tNAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSw2IEBACitBQ19E
RUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FDX1BBVEhfUFJPRyhbJDFdLCBbJDJdLCBb
bm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAKK3RoZW4KKyAgICBBQ19NU0dfRVJST1Io
W1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFsbCAkMl0pCitmaV0pCmRpZmYgLXIgZTI3
MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC9weXRob25fZGV2ZWwubTQKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcHl0
aG9uX2RldmVsLm00CVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDE4
IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3MucGF0aCwgc3lz
Citmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcv
TWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisnID4gL2Rldi9u
dWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBBQ19NU0dfUkVTVUxU
KFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFja2FnZSBub3QgZm91bmRd
KQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgZTI3MjJiMjRk
YzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC9weXRob25fdmVyc2lvbi5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25f
dmVyc2lvbi5tNAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMiBA
QAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7
IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikpJ2AKK2lmIHRlc3QgIiQ/
IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYAorICAg
IEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisgICAgICAgIFskcHl0aG9u
X3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzICQxLiQyXSkK
K2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIGUyNzIyYjI0ZGMw
OSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvbTQvcHl0aG9uX3htbC5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25feG1sLm00
CVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwIEBACitBQ19ERUZV
TihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIHht
bC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20ubWluaWRvbSdgCitp
ZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFD
X01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1vZHVsZV0pCitlbHNl
CisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIg
ODM3NTcwZTUzOWExIHRvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5tNAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9zZXRfY2ZsYWdz
X2xkZmxhZ3MubTQJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMjAg
QEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNM
VURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZs
YWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWci
Citkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURFUworZG8KKyAgICBBUFBFTkRfQ0ZM
QUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkQVBQRU5EX0xJQgorZG8KKyAg
ICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitDRkxBR1M9IiRQUkVQRU5EX0NG
TEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFHUz0iJFBSRVBFTkRfTERGTEFHUyAk
TERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1
NzBlNTM5YTEgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00CVdlZCBKYW4gMTEgMDY6MDc6MDUg
MjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfVURFVl0sCitb
aWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4KKyAgICBBQ19QQVRIX1BS
T0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVzdCB4IiR7VURFVkFETX0i
ID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtVREVWSU5GT10sIFt1
ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJTkZPfSIgPT0geCJubyIK
KyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAorICAgICAgICAgICAgICAg
IFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2
XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5GT30gLVYgfCBhd2sgJ3tw
cmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7VURFVkFETX0gaW5mbyAt
ViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVzdCAke3VkZXZ2ZXJ9IC1s
dCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQTFVHXSwgW2hvdHBsdWdd
LCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0geCJubyIKKyAgICAgICAg
dGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRvbyBvbGQsIHVwZ3JhZGUg
dG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICBB
Q19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgi
JHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBBQ19NU0dfRVJST1IoW05v
dCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkKKyAgICBmaQorZmkKK10p
CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC91dWlkLm00Ci0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200
L3V1aWQubTQJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTAgQEAK
K0FDX0RFRlVOKFtBWF9DSEVDS19VVUlEXSwKK1tpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGlu
dXgtZ251IgordGhlbgorICAgIEFDX0NIRUNLX0hFQURFUihbdXVpZC91dWlkLmhdLCwKKwkgICAg
W0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzXSldKQorZWxzZQorICAgIEFD
X0NIRUNLX0hFQURFUihbdXVpZC5oXSwsCisJICAgIFtBQ19NU0dfRVJST1IoW2Nhbm5vdCBmaW5k
IHV1aWQgaGVhZGVyc10pXSkKK2ZpCitdKQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBl
NTM5YTEgdmVyc2lvbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi92ZXJzaW9uLnNoCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAt
MCwwICsxLDUgQEAKKyMhL2Jpbi9zaAorCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9O
IiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBY
RU5fU1VCVkVSU0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAi
JWQuJWQiICRNQUpPUiAkTUlOT1IK

--===============6253512272991086591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6253512272991086591==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21: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.xensource.com>)
	id 1RtQiI-0005Qi-E0; Fri, 03 Feb 2012 21:30:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RtJhE-00040p-VB
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 14:01:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328277653!13593206!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17219 invoked from network); 3 Feb 2012 14:00:54 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 14:00:54 -0000
Received: by wibhm2 with SMTP id hm2so7299690wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 06:00:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to;
	bh=YdoNxvwop33RfHl88IqibVkkd06gLqSc7Pm4Zz12t80=;
	b=AUj4ec+97GyucYoQk5NGMrfQ+BbA1fYInEAYTsaolfVSpVCEELFzwv3WqEZpCFNSH1
	4ze9JNH9cqYpLzRgdyo6g0A+aWbqJyM+gRPPWSfLGccx++xk2ErZuVGcsjndoUw4vf3d
	hK7TdJn+ahSOM30lciU/GS4MNMMzD5Le4v3yU=
Received: by 10.180.14.129 with SMTP id p1mr11724249wic.16.1328277653791;
	Fri, 03 Feb 2012 06:00:53 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id eq5sm17697948wib.2.2012.02.03.06.00.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 03 Feb 2012 06:00:50 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============6253512272991086591=="
MIME-Version: 1.0
X-Mercurial-Node: 837570e539a114f47d8a98b7a281481a81ac856f
Message-Id: <837570e539a114f47d8a.1326258829@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 11 Jan 2012 06:13:49 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 03 Feb 2012 21:30:32 +0000
Subject: [Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6253512272991086591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is still not used anywhere, and is automatically created by
autoheader, altough this migh change when we start to include this
file.

Just a first release, and since it's my first autoconf script I guess
there will be many things to polish here... Please review and comment.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |      6 +
 Config.mk                         |     30 -
 Makefile                          |      2 -
 README                            |      4 +
 autogen.sh                        |      9 +
 config/Tools.mk.in                |     50 +
 configure                         |      2 +
 tools/Makefile                    |      3 +-
 tools/Rules.mk                    |      7 +-
 tools/blktap/drivers/Makefile     |      2 +-
 tools/blktap/drivers/check_gcrypt |     14 -
 tools/check/Makefile              |     26 -
 tools/check/README                |     20 -
 tools/check/check_brctl           |     13 -
 tools/check/check_crypto_lib      |     11 -
 tools/check/check_curl            |     13 -
 tools/check/check_iproute         |     15 -
 tools/check/check_libaio_devel    |     11 -
 tools/check/check_libaio_lib      |      9 -
 tools/check/check_openssl_devel   |      6 -
 tools/check/check_python          |     13 -
 tools/check/check_python_devel    |     17 -
 tools/check/check_python_xml      |     12 -
 tools/check/check_udev            |     22 -
 tools/check/check_uuid_devel      |      7 -
 tools/check/check_x11_devel       |      9 -
 tools/check/check_xgettext        |      6 -
 tools/check/check_xml2            |     14 -
 tools/check/check_yajl_devel      |      8 -
 tools/check/check_yajl_lib        |      6 -
 tools/check/check_zlib_devel      |      6 -
 tools/check/check_zlib_lib        |     12 -
 tools/check/chk                   |     63 -
 tools/check/funcs.sh              |    106 -
 tools/config.guess                |   1522 +++++
 tools/config.h.in                 |    468 +
 tools/config.sub                  |   1771 ++++++
 tools/configure                   |  10204 ++++++++++++++++++++++++++++++++++++
 tools/configure.ac                |    191 +
 tools/debugger/gdbsx/xg/Makefile  |      1 -
 tools/install.sh                  |      1 +
 tools/libfsimage/Makefile         |      6 +-
 tools/libfsimage/check-libext2fs  |     21 -
 tools/libxen/Makefile             |      8 +-
 tools/m4/default_lib.m4           |      8 +
 tools/m4/disable_feature.m4       |     13 +
 tools/m4/enable_feature.m4        |     13 +
 tools/m4/ocaml.m4                 |    241 +
 tools/m4/path_or_fail.m4          |      6 +
 tools/m4/python_devel.m4          |     18 +
 tools/m4/python_version.m4        |     12 +
 tools/m4/python_xml.m4            |     10 +
 tools/m4/set_cflags_ldflags.m4    |     20 +
 tools/m4/udev.m4                  |     32 +
 tools/m4/uuid.m4                  |     10 +
 version.sh                        |      5 +
 56 files changed, 14633 insertions(+), 502 deletions(-)



--===============6253512272991086591==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MjU4NDI1IC0zNjAwCiMgTm9kZSBJRCA4Mzc1NzBlNTM5
YTExNGY0N2Q4YTk4YjdhMjgxNDgxYTgxYWM4NTZmCiMgUGFyZW50ICBlMjcyMmIyNGRjMDk2MmRl
MzcyMTUzMjBiMDVkMWJiN2M0YzQyODY0CmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdoZXJl
LCBhbmQgaXMgYXV0b21hdGljYWxseSBjcmVhdGVkIGJ5CmF1dG9oZWFkZXIsIGFsdG91Z2ggdGhp
cyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvIGluY2x1ZGUgdGhpcwpmaWxlLgoKSnVzdCBh
IGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJ
IGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjM6CgogKiBDb3BpZWQgY29uZmln
Lmd1ZXNzIGFuZCBjb25maWcuc3ViIGZyb20gYXV0b21ha2UgMS4xMS4KCiAqIEFkZGVkIGEgdGVz
dCB0byBjaGVjayBmb3IgdXVpZC5oIG9uIEJTRCBhbmQgdXVpZC91dWlkLmggb24gTGludXguCgpD
aGFuZ2VzIHNpbmNlIHYyOgoKICogQ2hhbmdlZCBvcmRlciBvZiBjb25maWcvVG9vbHMubWsgaW5j
bHVkZS4KCiAqIEFkZGVkICItZSIgdG8gYXV0b2dlbi5zaCBzaGViYW5nLgoKICogQWRkZWQgbmVj
ZXNzYXJ5IGZpbGVzIChjb25maWcuKikgYW5kIG91dHB1dCBmcm9tIEF1dG9oZWFkZXIgYW5kCiAg
IEF1dG9jb25mLgoKICogUmVtb3ZlZCBBdXRvY29uZiBmcm9tIGJ1aWxkIGRlcGVuZGVuY2llcyBh
bmQgdXBkYXRlZCBSRUFETUUuCgpDaGFuZ2VzIHNpbmNlIHYxOgoKICogTW92ZWQgYXV0b2NvbmYg
c3R1ZmYgaW5zaWRlIHRvb2xzIGZvbGRlci4KCiAqIEFkZCBNYWtlZmlsZSBydWxlcyBmb3IgY2xl
YW5pbmcuCgogKiBSZW1vdmVkIEF1dG9tYWtlIGRlcGVuZGVuY3kuCgogKiBDcmVhdGUgYXV0b2dl
bi5zaCB0byBhdXRvbWF0aWNhbGx5IGNyZWF0ZSBjb25maWd1cmUgc2NyaXB0IHdoZW4KICAgYnVp
bGRpbmcgZnJvbSBzb3VyY2UgcmVwb3NpdG9yeS4KCiAqIENhY2hlZCB2YWx1ZXMgb2Ygb3B0aW9u
cyBwYXNzZWQgZnJvbSBjb21tYW5kIGxpbmUuCgogKiBBZGQgbmVjZXNzYXJ5IGlnbm9yZXMgdG8g
LmhnaWdub3JlLgoKICogQWRkZWQgQXV0b2NvbmYgdG8gdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVz
LgoKICogQ2hhbmdlZCBoeXBlbiB0byB1bmRlcnNjb3JlIGluIFhNTDIgYW5kIENVUkwgdmFyaWFi
bGUgbmFtZXMuCgogKiBBZGRlZCBzY3JpcHQgdG8gZ2V0IHZlcnNpb24gZnJvbSB4ZW4vTWFrZWZp
bGUuCgogKiBTZXQgT2NhbWwgdG9vbHMgdG8gb3B0aW9uYWwuCgogKiBBZGRlZCBwcm9jZWRlbmNl
IG9mIG00L29jYW1sLm00LgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5w
YXVAZW50ZWwudXBjLmVkdT4KCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSAu
aGdpZ25vcmUKLS0tIGEvLmhnaWdub3JlCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAor
KysgYi8uaGdpZ25vcmUJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0zMTIsNiAr
MzEyLDEyIEBACiBedG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2Nh
bWwvbGlicy94bC94ZW5saWdodFwubWxpJAogXnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3Rv
cmVkJAorXnRvb2xzL2F1dG9tNHRlXC5jYWNoZSQKK150b29scy9jb25maWdcLmgkCitedG9vbHMv
Y29uZmlnXC5sb2ckCitedG9vbHMvY29uZmlnXC5zdGF0dXMkCitedG9vbHMvY29uZmlnXC5jYWNo
ZSQKK15jb25maWcvVG9vbHNcLm1rJAogXnhlbi9cLmJhbm5lci4qJAogXnhlbi9CTE9HJAogXnhl
bi9TeXN0ZW0ubWFwJApkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgQ29uZmln
Lm1rCi0tLSBhL0NvbmZpZy5tawlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIGIv
Q29uZmlnLm1rCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtNzAsOSArNzAsNiBA
QCBFWFRSQV9JTkNMVURFUyArPSAkKEVYVFJBX1BSRUZJWCkvaW5jbHVkCiBFWFRSQV9MSUIgKz0g
JChFWFRSQV9QUkVGSVgpLyQoTElCTEVBRkRJUikKIGVuZGlmCiAKLUJJU09OCT89IGJpc29uCi1G
TEVYCT89IGZsZXgKLQogUFlUSE9OICAgICAgPz0gcHl0aG9uCiBQWVRIT05fUFJFRklYX0FSRyA/
PSAtLXByZWZpeD0iJChQUkVGSVgpIgogIyBUaGUgYWJvdmUgcmVxdWlyZXMgdGhhdCBQUkVGSVgg
Y29udGFpbnMgKm5vIHNwYWNlcyouIFRoaXMgdmFyaWFibGUgaXMgaGVyZQpAQCAtMTc1LDkgKzE3
Miw2IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9M
REZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZM
QUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tf
TElCID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lO
Q0xVREVTID0gJChFWFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9J
TkNMVURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXBy
b3RlY3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyAr
PSAtZm5vLWV4Y2VwdGlvbnMKIApAQCAtMTg2LDE2ICsxODAsNiBAQCBDT05GSUdfTElCSUNPTlYg
ICA6PSAkKHNoZWxsIGV4cG9ydCBPUz0iCiAgICAgICAgICAgICAgICAgICAgICAgIC4gJChYRU5f
Uk9PVCkvdG9vbHMvY2hlY2svZnVuY3Muc2g7IFwKICAgICAgICAgICAgICAgICAgICAgICAgaGFz
X2xpYiBsaWJpY29udi5zbyAmJiBlY2hvICd5JyB8fCBlY2hvICduJykKIAotIyBFbmFibGUgWFNN
IHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1G
TEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxFKQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0b3Jp
ZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHByb3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBm
YXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0j
IG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCBy
ZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9I
VFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4KLUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVT
X1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhl
IGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2VyZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9u
CiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmlnaW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVk
IGFzIGEgY29tbWVudApAQCAtMjI4LDE3ICsyMTIsMyBAQCBRRU1VX1RBRyA/PSBiYjM2ZDYzMmU0
Y2FiZjQ3ODgyYWRmZjA3YTQ1CiAKICMgU2hvcnQgYW5zd2VyIC0tIGRvIG5vdCBlbmFibGUgdGhp
cyB1bmxlc3MgeW91IGtub3cgd2hhdCB5b3UgYXJlCiAjIGRvaW5nIGFuZCBhcmUgcHJlcGFyZWQg
Zm9yIHNvbWUgcGFpbi4KLQotIyBPcHRpb25hbCBjb21wb25lbnRzCi1YRU5TVEFUX1hFTlRPUCAg
ICAgPz0geQotVlRQTV9UT09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQSV9CSU5ESU5HUyA/PSBu
Ci1QWVRIT05fVE9PTFMgICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAgICAgID89IHkKLUNPTkZJ
R19NSU5JVEVSTSAgICA/PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0gbgotQ09ORklHX1NZU1RF
TV9MSUJBSU8gPz0geQotCi1pZmVxICgkKE9DQU1MX1RPT0xTKSx5KQotT0NBTUxfVE9PTFMgOj0g
JChzaGVsbCBvY2FtbG9wdCAtdiA+IC9kZXYvbnVsbCAyPiYxICYmIGVjaG8gInkiIHx8IGVjaG8g
Im4iKQotZW5kaWYKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIE1ha2VmaWxl
Ci0tLSBhL01ha2VmaWxlCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgYi9NYWtl
ZmlsZQlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTQwLDExICs0MCw5IEBAIGRp
c3Q6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0OiBkaXN0LXhlbiBkaXN0LWtlcm5l
bHMgZGlzdC10b29scyBkaXN0LXN0dWJkb20gZGlzdC1kb2NzIGRpc3QtbWlzYwogCiBkaXN0LW1p
c2M6Ci0JJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawogCSQoSU5TVEFMTF9EQVRBKSAu
L0NPUFlJTkcgJChESVNURElSKQogCSQoSU5TVEFMTF9EQVRBKSAuL1JFQURNRSAkKERJU1RESVIp
CiAJJChJTlNUQUxMX1BST0cpIC4vaW5zdGFsbC5zaCAkKERJU1RESVIpCi0JJChJTlNUQUxMX1BS
T0cpIHRvb2xzL2NoZWNrL2NoayB0b29scy9jaGVjay9jaGVja18qIHRvb2xzL2NoZWNrL2Z1bmNz
LnNoICQoRElTVERJUikvY2hlY2sKIGRpc3QtJTogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwK
IGRpc3QtJTogaW5zdGFsbC0lCiAJQDogIyBkbyBub3RoaW5nCmRpZmYgLXIgZTI3MjJiMjRkYzA5
IC1yIDgzNzU3MGU1MzlhMSBSRUFETUUKLS0tIGEvUkVBRE1FCVRodSBKYW4gMjYgMTc6NDM6MzEg
MjAxMiArMDAwMAorKysgYi9SRUFETUUJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBA
IC04OSw5ICs4OSwxMyBAQCAyLiBjZCB0byB4ZW4tdW5zdGFibGUgKG9yIHdoYXRldmVyIHlvdSBz
CiAzLiBGb3IgdGhlIHZlcnkgZmlyc3QgYnVpbGQsIG9yIGlmIHlvdSB3YW50IHRvIGRlc3Ryb3kg
YnVpbGQgdHJlZXMsCiAgICBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgc3RlcHM6CiAKKyAgICAjIC4v
Y29uZmlndXJlCiAgICAgIyBtYWtlIHdvcmxkCiAgICAgIyBtYWtlIGluc3RhbGwKIAorICAgSWYg
eW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29uZmlndXJlIC0taGVscCB0byBzZWUgdGhlIGxpc3Qg
b2YKKyAgIG9wdGlvbnMgYXZhaWxhYmxlIG9wdGlvbnMgd2hlbiBidWlsZGluZyBhbmQgaW5zdGFs
bGluZyBYZW4uCisKICAgIFRoaXMgd2lsbCBjcmVhdGUgYW5kIGluc3RhbGwgb250byB0aGUgbG9j
YWwgbWFjaGluZS4gSXQgd2lsbCBidWlsZAogICAgdGhlIHhlbiBiaW5hcnkgKHhlbi5neiksIHRo
ZSB0b29scyBhbmQgdGhlIGRvY3VtZW50YXRpb24uCiAKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIg
ODM3NTcwZTUzOWExIGF1dG9nZW4uc2gKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIvYXV0b2dlbi5zaAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAx
MDAKQEAgLTAsMCArMSw5IEBACisjIS9iaW4vc2ggLWUKK3JtIC1yZiBjb25maWd1cmUKK2NkIHRv
b2xzCithdXRvaGVhZGVyCithdXRvY29uZgorY2QgLi4KK2VjaG8gIiMhL2Jpbi9zaCAtZSIgPj4g
Y29uZmlndXJlCitlY2hvICJjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSBcJEAiID4+IGNvbmZpZ3Vy
ZQorY2htb2QgK3ggY29uZmlndXJlCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1Mzlh
MSBjb25maWcvVG9vbHMubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvY29uZmlnL1Rvb2xzLm1rLmluCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAx
MiArMDEwMApAQCAtMCwwICsxLDUwIEBACisjIFByZWZpeCBhbmQgaW5zdGFsbCBmb2xkZXIKK1BS
RUZJWCAgICAgICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJfeDg2XzY0ICAgOj0gQExJ
Ql9QQVRIQAorCisjIEEgZGVidWcgYnVpbGQgb2YgdG9vbHM/CitkZWJ1ZyAgICAgICAgICAgICAg
IDo9IEBkZWJ1Z0AKKworIyBUb29scyBwYXRoCitCSVNPTiAgICAgICAgICAgICAgIDo9IEBCSVNP
TkAKK0ZMRVggICAgICAgICAgICAgICAgOj0gQEZMRVhACitQWVRIT04gICAgICAgICAgICAgIDo9
IEBQWVRIT05ACitQWVRIT05fUEFUSCAgICAgICAgIDo9IEBQWVRIT05QQVRIQAorUEVSTCAgICAg
ICAgICAgICAgICA6PSBAUEVSTEAKK0JSQ1RMICAgICAgICAgICAgICAgOj0gQEJSQ1RMQAorSVAg
ICAgICAgICAgICAgICAgICA6PSBASVBACitDVVJMX0NPTkZJRyAgICAgICAgIDo9IEBDVVJMQAor
WE1MMl9DT05GSUcgICAgICAgICA6PSBAWE1MQAorQkFTSCAgICAgICAgICAgICAgICA6PSBAQkFT
SEAKK1hHRVRUVEVYVCAgICAgICAgICAgOj0gQFhHRVRURVhUQAorCisjIEV4dHJhIGZvbGRlciBm
b3IgbGlicy9pbmNsdWRlcworUFJFUEVORF9JTkNMVURFUyAgICA6PSBAUFJFUEVORF9JTkNMVURF
U0AKK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElCQAorQVBQRU5EX0lOQ0xVREVT
ICAgICA6PSBAQVBQRU5EX0lOQ0xVREVTQAorQVBQRU5EX0xJQiAgICAgICAgICA6PSBAQVBQRU5E
X0xJQkAKKworIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2sp
LgorWFNNX0VOQUJMRSAgICAgICAgICA6PSBAeHNtQAorRkxBU0tfRU5BQkxFICAgICAgICA6PSBA
eHNtQAorCisjIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3du
IHByb3RvY29sPworIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3
aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCisjIG1heSBibG9jayBpdCkuIFdlIG1ha2Ug
aXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25sb2FkcworIyBm
YWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVu
dC4KK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBACisKKyMgT3B0aW9uYWwgY29tcG9u
ZW50cworWEVOU1RBVF9YRU5UT1AgICAgICA6PSBAbW9uaXRvcnNACitWVFBNX1RPT0xTICAgICAg
ICAgIDo9IEB2dHBtQAorTElCWEVOQVBJX0JJTkRJTkdTICA6PSBAeGFwaUAKK1BZVEhPTl9UT09M
UyAgICAgICAgOj0gQHB5dGhvbnRvb2xzQAorT0NBTUxfVE9PTFMgICAgICAgICA6PSBAb2NhbWx0
b29sc0AKK0NPTkZJR19NSU5JVEVSTSAgICAgOj0gQG1pbml0ZXJtQAorQ09ORklHX0xPTU9VTlQg
ICAgICA6PSBAbG9tb3VudEAKKworI1N5c3RlbSBvcHRpb25zCitDT05GSUdfU1lTVEVNX0xJQkFJ
Tzo9IEBzeXN0ZW1fYWlvQAorQ09ORklHX0xJQklDT05WICAgICA6PSBAbGliaWNvbnZACitDT05G
SUdfR0NSWVBUICAgICAgIDo9IEBsaWJnY3J5cHRACitDT05GSUdfRVhUMkZTICAgICAgIDo9IEBs
aWJleHQyZnNACmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSBjb25maWd1cmUK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvY29uZmln
dXJlCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDIgQEAKKyMhL2Jp
bi9zaCAtZQorY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgJEAKZGlmZiAtciBlMjcyMmIyNGRjMDkg
LXIgODM3NTcwZTUzOWExIHRvb2xzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL01ha2VmaWxlCVRodSBK
YW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgYi90b29scy9NYWtlZmlsZQlXZWQgSmFuIDEx
IDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTYsNyArNiw2IEBAIFNVQkRJUlMtbGliYWlvIDo9IGxp
YmFpbwogZW5kaWYKIAogU1VCRElSUy15IDo9Ci1TVUJESVJTLXkgKz0gY2hlY2sKIFNVQkRJUlMt
eSArPSBpbmNsdWRlCiBTVUJESVJTLXkgKz0gbGlieGMKIFNVQkRJUlMteSArPSBmbGFzawpAQCAt
NzgsNiArNzcsOCBAQCBjbGVhbjogc3ViZGlycy1jbGVhbgogZGlzdGNsZWFuOiBzdWJkaXJzLWRp
c3RjbGVhbgogCXJtIC1yZiBxZW11LXhlbi10cmFkaXRpb25hbC1kaXIgcWVtdS14ZW4tdHJhZGl0
aW9uYWwtZGlyLXJlbW90ZQogCXJtIC1yZiBxZW11LXhlbi1kaXIgcWVtdS14ZW4tZGlyLXJlbW90
ZQorCXJtIC1yZiAuLi9jb25maWcvVG9vbHMubWsgY29uZmlnLmggY29uZmlnLmxvZyBjb25maWcu
c3RhdHVzIFwKKwkJY29uZmlnLmNhY2hlIGF1dG9tNHRlLmNhY2hlCiAKIGlmbmVxICgkKFhFTl9D
T01QSUxFX0FSQ0gpLCQoWEVOX1RBUkdFVF9BUkNIKSkKIElPRU1VX0NPTkZJR1VSRV9DUk9TUyA/
PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXApkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1
NzBlNTM5YTEgdG9vbHMvUnVsZXMubWsKLS0tIGEvdG9vbHMvUnVsZXMubWsJVGh1IEphbiAyNiAx
Nzo0MzozMSAyMDEyICswMDAwCisrKyBiL3Rvb2xzL1J1bGVzLm1rCVdlZCBKYW4gMTEgMDY6MDc6
MDUgMjAxMiArMDEwMApAQCAtNCw2ICs0LDcgQEAKIGFsbDoKIAogaW5jbHVkZSAkKFhFTl9ST09U
KS9Db25maWcubWsKK2luY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1rCiAKIGV4cG9y
dCBfSU5TVEFMTCA6PSAkKElOU1RBTEwpCiBJTlNUQUxMID0gJChYRU5fUk9PVCkvdG9vbHMvY3Jv
c3MtaW5zdGFsbApAQCAtODAsOCArODEsNiBAQCBjaGVjay0kKENPTkZJR19YODYpID0gJChjYWxs
IGNjLXZlci1jaGVjCiAgICAgICAgICAgICAgICAgICAgICAgICAiWGVuIHJlcXVpcmVzIGF0IGxl
YXN0IGdjYy0zLjQiKQogJChldmFsICQoY2hlY2steSkpCiAKLV9QWVRIT05fUEFUSCA6PSAkKHNo
ZWxsIHdoaWNoICQoUFlUSE9OKSkKLVBZVEhPTl9QQVRIID89ICQoX1BZVEhPTl9QQVRIKQogSU5T
VEFMTF9QWVRIT05fUFJPRyA9IFwKIAkkKFhFTl9ST09UKS90b29scy9weXRob24vaW5zdGFsbC13
cmFwICIkKFBZVEhPTl9QQVRIKSIgJChJTlNUQUxMX1BST0cpCiAKQEAgLTEwOSwzICsxMDgsNyBA
QCBzdWJkaXItYWxsLSUgc3ViZGlyLWNsZWFuLSUgc3ViZGlyLWluc3RhCiAKIHN1YmRpci1kaXN0
Y2xlYW4tJTogLnBob255CiAJJChNQUtFKSAtQyAkKiBjbGVhbgorCiskKFhFTl9ST09UKS9jb25m
aWcvVG9vbHMubWs6CisJQGVjaG8gIllvdSBoYXZlIHRvIHJ1biAuL2NvbmZpZ3VyZSBiZWZvcmUg
YnVpbGRpbmcgb3IgaW5zdGFsbGluZyB0aGUgdG9vbHMiCisJQGV4aXQgMQpkaWZmIC1yIGUyNzIy
YjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUKLS0t
IGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEy
ICswMDAwCisrKyBiL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVdlZCBKYW4gMTEgMDY6
MDc6MDUgMjAxMiArMDEwMApAQCAtMTMsNyArMTMsNyBAQCBDRkxBR1MgICArPSAkKENGTEFHU19s
aWJ4ZW5zdG9yZSkKIENGTEFHUyAgICs9IC1JICQoTUVNU0hSX0RJUikKIENGTEFHUyAgICs9IC1E
X0dOVV9TT1VSQ0UKIAotaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0ICQoQ0MpKSx5ZXMp
CitpZmVxICgkQ09ORklHX0dDUllQVCx5KQogQ0ZMQUdTICs9IC1EVVNFX0dDUllQVAogQ1JZUFRf
TElCIDo9IC1sZ2NyeXB0CiBlbHNlCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1Mzlh
MSB0b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQKLS0tIGEvdG9vbHMvYmxrdGFwL2Ry
aXZlcnMvY2hlY2tfZ2NyeXB0CVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCArMCwwIEBACi0j
IS9iaW4vc2gKLQotY2F0ID4gLmdjcnlwdC5jIDw8IEVPRgotI2luY2x1ZGUgPGdjcnlwdC5oPgot
aW50IG1haW4odm9pZCkgeyByZXR1cm4gMDsgfQotRU9GCi0KLWlmICQxIC1vIC5nY3J5cHQgLmdj
cnlwdC5jIC1sZ2NyeXB0IDI+L2Rldi9udWxsIDsgdGhlbgotICBlY2hvICJ5ZXMiCi1lbHNlCi0g
IGVjaG8gIm5vIgotZmkKLQotcm0gLWYgLmdjcnlwdCoKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIg
ODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2NoZWNrL01ha2Vm
aWxlCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyNiArMCwwIEBACi1YRU5fUk9PVCA9ICQoQ1VS
RElSKS8uLi8uLgotaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawotCi0jIEV4cG9y
dCB0aGUgbmVjZXNzYXJ5IGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgdGhlIHRlc3RzCi1leHBv
cnQgUFlUSE9OCi1leHBvcnQgTElCWEVOQVBJX0JJTkRJTkdTCi1leHBvcnQgQ0hFQ0tfSU5DTFVE
RVMKLWV4cG9ydCBDSEVDS19MSUIKLWV4cG9ydCBDT05GSUdfU1lTVEVNX0xJQkFJTwotCi0uUEhP
Tlk6IGFsbCBpbnN0YWxsCi1hbGwgaW5zdGFsbDogY2hlY2stYnVpbGQKLQotIyBDaGVjayB0aGlz
IG1hY2hpbmUgaXMgT0sgZm9yIGJ1aWxkaW5nIG9uLgotLlBIT05ZOiBjaGVjay1idWlsZAotY2hl
Y2stYnVpbGQ6Ci0JLi9jaGsgYnVpbGQKLQotIyBDaGVjayB0aGlzIG1hY2hpbmUgaXMgT0sgZm9y
IGluc3RhbGxpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWluc3RhbGwKLWNoZWNrLWluc3RhbGw6Ci0J
Li9jaGsgaW5zdGFsbAotCi0uUEhPTlk6IGNsZWFuCi1jbGVhbjoKLQkuL2NoayBjbGVhbgpkaWZm
IC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svUkVBRE1FCi0tLSBh
L3Rvb2xzL2NoZWNrL1JFQURNRQlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjAgKzAsMCBAQAot
Q2hlY2tzIGZvciB0aGUgc3VpdGFiaWxpdHkgb2YgYSBtYWNoaW5lIGZvciBYZW4gYnVpbGQgb3Ig
aW5zdGFsbC4KLVRvIGNoZWNrIGZvciBidWlsZCBzdWl0YWJpbGl0eSB1c2UKLQotICAgICAgICAu
L2NoayBidWlsZAotCi1UbyBjaGVjayBmb3IgaW5zdGFsbCBzdWl0YWJpbGl0eSB1c2UKLQotICAg
ICAgICAuL2NoayBpbnN0YWxsCi0KLVRoZSBjaGsgc2NyaXB0IHdpbGwgcnVuIGNoZWNrcyBpbiB0
aGlzIGRpcmVjdG9yeSBhbmQgcHJpbnQKLXRoZSBvbmVzIHRoYXQgZmFpbGVkLiBJdCBwcmludHMg
bm90aGluZyBpZiBjaGVja3Mgc3VjY2VlZC4KLVRoZSBjaGsgc2NyaXB0IGV4aXRzIHdpdGggMCBv
biBzdWNjZXNzIGFuZCAxIG9uIGZhaWx1cmUuCi0KLVRoZSBjaGsgc2NyaXB0IHJ1bnMgZXhlY3V0
YWJsZSBmaWxlcyBpbiB0aGlzIGRpcmVjdG9yeSB3aG9zZQotbmFtZXMgYmVnaW4gd2l0aCAnY2hl
Y2tfJy4gRmlsZXMgY29udGFpbmluZyBDSEVDSy1CVUlMRAotYXJlIHJ1biBmb3IgdGhlIGJ1aWxk
IGNoZWNrLCBhbmQgZmlsZXMgY29udGFpbmluZyBDSEVDSy1JTlNUQUxMCi1hcmUgcnVuIGZvciB0
aGUgaW5zdGFsbCBjaGVjay4KLQotRGV0YWlsZWQgb3V0cHV0IGZyb20gdGhlIGNoZWNrIHNjcmlw
dHMgaXMgaW4gLmNoa2J1aWxkIGZvciBidWlsZAotYW5kIC5jaGtpbnN0YWxsIGZvciBpbnN0YWxs
LgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3
NTcwZTUzOWExIHRvb2xzL2NoZWNrL2NoZWNrX2JyY3RsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X2JyY3RsCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0
QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgYnJjb25maWcgOzsKLUxpbnV4KQotCWhhc19vcl9m
YWlsIGJyY3RsIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2FjCmRpZmYgLXIgZTI3
MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja19jcnlwdG9fbGliCi0t
LSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4g
Li9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRCU0R8T3BlbkJTRCkKLQlleGl0
IDAgOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJjcnlwdG8uc28gfHwgZmFpbCAibWlzc2luZyBsaWJj
cnlwdG8uc28iCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVj
ay9jaGVja19jdXJsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2N1cmwJVGh1IEphbiAyNiAxNzo0
MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNU
QUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICIkTElCWEVOQVBJX0JJTkRJTkdTIiAhPSAieSIg
XTsgdGhlbgotCWVjaG8gLW4gInVudXNlZCwgIgotCWV4aXQgMAotZmkKLQotaGFzX29yX2ZhaWwg
Y3VybC1jb25maWcKLWN1cmxfbGlicz1gY3VybC1jb25maWcgLS1saWJzYCB8fCBmYWlsICJjdXJs
LWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICRjdXJsX2xpYnMgfHwgZmFpbCAiZGVw
ZW5kZW5jeSBsaWJyYXJpZXMgZm9yIGN1cmwgYXJlIG1pc3NpbmciCmRpZmYgLXIgZTI3MjJiMjRk
YzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja19pcHJvdXRlCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX2lwcm91dGUJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE1ICswLDAgQEAK
LSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1QQVRIPS9zYmlu
OiRQQVRICi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9m
YWlsIGlmY29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBpcCA7OwotKikKLQlmYWlsICJ1
bmtub3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEg
dG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2xp
YmFpb19kZXZlbAlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19TWVNURU1f
TElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaWYgISBoYXNfaGVhZGVy
IGxpYmFpby5oIDsgdGhlbgotICAgIGZhaWwgImNhbid0IGZpbmQgbGliYWlvIGhlYWRlcnMsIGlu
c3RhbGwgbGliYWlvIGRldmVsIHBhY2thZ2Ugb3Igc2V0IENPTkZJR19TWVNURU1fTElCQUlPPW4i
Ci1maQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svY2hl
Y2tfbGliYWlvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9fbGliCVRodSBKYW4g
MjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVD
Sy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19TWVNURU1fTElCQUlP
fSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaGFzX2xpYiBsaWJhaW8uc28gfHwg
ZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8iCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1
MzlhMSB0b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX29wZW5zc2xfZGV2ZWwJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIG9wZW5z
c2wvbWQ1LmggfHwgZmFpbCAibWlzc2luZyBvcGVuc3NsIGhlYWRlcnMiCmRpZmYgLXIgZTI3MjJi
MjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja19weXRob24KLS0tIGEvdG9v
bHMvY2hlY2svY2hlY2tfcHl0aG9uCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gK
LQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLQotJHtQ
WVRIT059IC1jICcKLWltcG9ydCBzeXMKLXN5cy5leGl0KHN5cy52ZXJzaW9uX2luZm9bMF0gPCAy
IG9yIHN5cy52ZXJzaW9uX2luZm9bMV0gPCAzKQotJyB8fCBmYWlsICJuZWVkIHB5dGhvbiB2ZXJz
aW9uID49IDIuMyIKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2No
ZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja19weXRob25fZGV2
ZWwJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE3ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAg
UFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0ke1BZVEhPTn0gLWMg
JwotaW1wb3J0IG9zLnBhdGgsIHN5cwotZm9yIHAgaW4gc3lzLnBhdGg6Ci0JaWYgb3MucGF0aC5l
eGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6Ci0JCXN5cy5leGl0KDApCi1zeXMuZXhpdCgx
KQotJyB8fCBmYWlsICJjYW4ndCBmaW5kIHB5dGhvbiBkZXZlbCBmaWxlcyIKZGlmZiAtciBlMjcy
MmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94bWwKLS0t
IGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0K
LWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3Jf
ZmFpbCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJyAy
Pi9kZXYvbnVsbCB8fCBcCi1mYWlsICJjYW4ndCBpbXBvcnQgeG1sLmRvbS5taW5pZG9tIgpkaWZm
IC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svY2hlY2tfdWRldgot
LS0gYS90b29scy9jaGVjay9jaGVja191ZGV2CVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAw
MAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMiAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2Fz
ZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgdm5jb25maWcK
LQk7OwotTGludXgpCi0JaGFzIC9zYmluL3VkZXZhZG0gJiYgXAotCQl1ZGV2dmVyPWAvc2Jpbi91
ZGV2YWRtIGluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbIC16ICIkdWRldnZlciIgXSAm
JiBoYXNfb3JfZmFpbCB1ZGV2aW5mbyAmJiBcCi0JCXVkZXZ2ZXI9YHVkZXZpbmZvIC1WIHwgYXdr
ICd7cHJpbnQgJE5GfSdgCi0JWyAiJHVkZXZ2ZXIiIC1nZSA1OSBdIDI+L2Rldi9udWxsIHx8IFwK
LQkJaGFzIGhvdHBsdWcgfHwgXAotCQlmYWlsICJ1ZGV2IGlzIHRvbyBvbGQsIHVwZ3JhZGUgdG8g
dmVyc2lvbiA1OSBvciBsYXRlciIKLQk7OwotKikKLQlmYWlsICJ1bmtub3duIE9TIgotCTs7Ci1l
c2FjCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVj
a191dWlkX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwJVGh1IEphbiAy
NiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4g
Li9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHV1aWQuaCB8fCBcCi1oYXNfaGVhZGVyIHV1aWQvdXVp
ZC5oIHx8IGZhaWwgIm1pc3NpbmcgdXVpZCBoZWFkZXJzIChwYWNrYWdlIHV1aWQtZGV2KSIKZGlm
ZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL2NoZWNrX3gxMV9k
ZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwJVGh1IEphbiAyNiAxNzo0Mzoz
MSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5z
aAotCi1oYXNfaGVhZGVyIFgxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDEx
UjYvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAotaGFzX2hlYWRlciAvdXNyL1gxMVI3L2lu
Y2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLXdhcm5pbmcgImNhbid0IGZpbmQgWDExIGhlYWRl
cnMiCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVj
a194Z2V0dGV4dAotLS0gYS90b29scy9jaGVjay9jaGVja194Z2V0dGV4dAlUaHUgSmFuIDI2IDE3
OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1
bmNzLnNoCi0KLWhhc19vcl9mYWlsIHhnZXR0ZXh0CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgz
NzU3MGU1MzlhMSB0b29scy9jaGVjay9jaGVja194bWwyCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3htbDIJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBD
SEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICEgIiRMSUJY
RU5BUElfQklORElOR1MiID0gInkiIF0KLXRoZW4KLSAgICBlY2hvIC1uICJ1bnVzZWQsICIKLSAg
ICBleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIHhtbDItY29uZmlnCi14bWwyX2xpYnM9YHhtbDIt
Y29uZmlnIC0tbGlic2AgfHwgZmFpbCAieG1sMi1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3Rf
bGluayAkeG1sMl9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciB4bWwyIGFy
ZSBtaXNzaW5nIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hl
Y2svY2hlY2tfeWFqbF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja195YWpsX2RldmVsCVRo
dSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMApAQCAtMSw4ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlM
RAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB5YWpsL3lhamxfcGFyc2UuaCB8fCBmYWls
ICJjYW4ndCBmaW5kIHlhamwveWFqbF9wYXJzZS5oIgotaGFzX2hlYWRlciB5YWpsL3lhamxfZ2Vu
LmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfZ2VuLmgiCi1oYXNfbGliIGxpYnlhamwu
c28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJ5YWpsLnNvIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAt
ciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfeWFqbF9saWIJVGh1IEphbiAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWhh
c19saWIgbGlieWFqbC5zby4xIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5zby4xIHZlcnNp
b24gMSIKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NoZWNrL2No
ZWNrX3psaWJfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9kZXZlbAlUaHUgSmFu
IDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQot
LiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgemxpYi5oIHx8IGZhaWwgImNhbid0IGZpbmQgemxp
YiBoZWFkZXJzIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY2hl
Y2svY2hlY2tfemxpYl9saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9saWIJVGh1IEph
biAyNiAxNzo0MzozMSAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBD
SEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRC
U0R8T3BlbkJTRCkKLQlleGl0IDAKLQk7OwotZXNhYwotCi1oYXNfbGliIGxpYnouc28gfHwgZmFp
bCAiY2FuJ3QgZmluZCB6bGliIgpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEg
dG9vbHMvY2hlY2svY2hrCi0tLSBhL3Rvb2xzL2NoZWNrL2NoawlUaHUgSmFuIDI2IDE3OjQzOjMx
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsNjMgKzAsMCBAQAotIyEvYmluL3NoCi0KLWZ1bmNfdXNhZ2UgKCkKLXsKLSAgICBlY2hv
ICJVc2FnZToiCi0gICAgZWNobyAiCSQwIFtidWlsZHxpbnN0YWxsfGNsZWFuXSIKLSAgICBlY2hv
Ci0gICAgZWNobyAiQ2hlY2sgc3VpdGFiaWxpdHkgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLiIK
LSAgICBlY2hvICJFeGl0IHdpdGggMCBpZiBPSywgMSBpZiBub3QuIgotICAgIGVjaG8KLSAgICBl
Y2hvICJDYWxsaW5nIHdpdGggJ2NsZWFuJyByZW1vdmVzIGdlbmVyYXRlZCBmaWxlcy4iCi0gICAg
ZXhpdCAxCi19Ci0KLVBBVEg9JFBBVEg6L3NiaW46L3Vzci9zYmluCi1PUz1gdW5hbWUgLXNgCi1l
eHBvcnQgUEFUSCBPUwotCi1pZiBbICIkT1MiID0gIlN1bk9TIiBdOyB0aGVuCi0JZXhpdCAwCi1m
aQotCi1jYXNlICQxIGluCi0gICAgYnVpbGQpCi0gICAgICAgIGNoZWNrPSJDSEVDSy1CVUlMRCIK
LSAgICAgICAgOzsKLSAgICBpbnN0YWxsKQotICAgICAgICBjaGVjaz0iQ0hFQ0stSU5TVEFMTCIK
LSAgICAgICAgOzsKLSAgICBjbGVhbikKLSAgICAgICAgZXhpdCAwCi0gICAgICAgIDs7Ci0gICAg
KikKLSAgICAgICAgZnVuY191c2FnZQotICAgICAgICA7OwotZXNhYwotCi1mYWlsZWQ9MAotCi1l
Y2hvICJYZW4gJHtjaGVja30gIiBgZGF0ZWAKLWZvciBmIGluIGNoZWNrXyogOyBkbwotICAgIGNh
c2UgJGYgaW4KLSAgICAgICAgKn4pCi0gICAgICAgICAgICBjb250aW51ZQotICAgICAgICAgICAg
OzsKLSAgICAgICAgKikKLSAgICAgICAgICAgIDs7Ci0gICAgZXNhYwotICAgIGlmICEgWyAteCAk
ZiBdIDsgdGhlbgotICAgICAgICBjb250aW51ZQotICAgIGZpCi0gICAgaWYgISBncmVwIC1GcSAi
JGNoZWNrIiAkZiA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAgIGVjaG8gLW4g
IkNoZWNraW5nICRmOiAiCi0gICAgaWYgLi8kZiAyPiYxIDsgdGhlbgotICAgICAgICBlY2hvIE9L
Ci0gICAgZWxzZQotICAgICAgICBmYWlsZWQ9MQotICAgIGZpCi1kb25lCi0KLWV4aXQgJHtmYWls
ZWR9CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jaGVjay9mdW5j
cy5zaAotLS0gYS90b29scy9jaGVjay9mdW5jcy5zaAlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTA2ICswLDAgQEAKLSMgaGFzIGlzIHRoZSBzYW1lIGFzIHdoaWNoLCBleGNlcHQgaXQgaGFuZGxl
cyBjcm9zcyBlbnZpcm9ubWVudHMKLWhhcygpIHsKLQlpZiBbIC16ICIkQ1JPU1NfQ09NUElMRSIg
XTsgdGhlbgotCQljb21tYW5kIHdoaWNoICIkQCIKLQkJcmV0dXJuICQ/Ci0JZmkKLQotCWNoZWNr
X3N5c19yb290IHx8IHJldHVybiAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQgcG9sbHV0aW9u
IG9mIGNhbGxlcidzIElGUwotCSgKLQlJRlM9OgotCWZvciBwIGluICRQQVRIOyBkbwotCQlpZiBb
IC14ICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiIF07IHRoZW4KLQkJCWVjaG8gIiRDUk9TU19TWVNf
Uk9PVC8kcC8kMSIKLQkJCXJldHVybiAwCi0JCWZpCi0JZG9uZQotCXJldHVybiAxCi0JKQotfQot
Ci1oYXNfb3JfZmFpbCgpIHsKLQloYXMgIiQxIiA+L2Rldi9udWxsIHx8IGZhaWwgImNhbid0IGZp
bmQgJDEiCi19Ci0KLWhhc19oZWFkZXIoKSB7Ci0JY2hlY2tfc3lzX3Jvb3QgfHwgcmV0dXJuIDEK
LQotCWNhc2UgJDEgaW4KLQkJLyopIDs7Ci0JCSopCi0JCWlmIFsgLXIgIiRDUk9TU19TWVNfUk9P
VC91c3IvaW5jbHVkZS8kMSIgXTsgdGhlbgotCQkJcmV0dXJuIDAKLQkJZmkKLQkJZm9yIHBhdGgg
aW4gJHtDSEVDS19JTkNMVURFU307IGRvCi0JCQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JPT1Qke3Bh
dGh9LyQxIiBdOyB0aGVuCi0JCQkJcmV0dXJuIDAKLQkJCWZpCi0JCWRvbmUKLQkJOzsKLQllc2Fj
Ci0KLQlyZXR1cm4gMQotfQotCi1oYXNfbGliKCkgewotCWNoZWNrX3N5c19yb290IHx8IHJldHVy
biAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQgcG9sbHV0aW9uIG9mIGNhbGxlcidzIGVudmly
b25tZW50Ci0JKAotCVBBVEg9L3NiaW46JFBBVEggICAgICAgICMgZm9yIGxkY29uZmlnCi0JTElC
UkFSSUVTPSIkQ0hFQ0tfTElCIC91c3IvbGliIgotCi0JIyBUaGlzIHJlbGF0aXZlbHkgY29tbW9u
IGluIGEgc3lzLXJvb3Q7IGxpYnMgYXJlIGluc3RhbGxlZCBidXQKLQkjIGxkY29uZmlnIGhhc24n
dCBydW4gdGhlcmUsIHNvIGxkY29uZmlnIC1wIHdvbid0IHdvcmsuCi0JaWYgWyAiJE9TIiA9IExp
bnV4IC1hICEgLWYgIiRDUk9TU19TWVNfUk9PVC9ldGMvbGQuc28uY2FjaGUiIF07IHRoZW4KLQkg
ICAgZWNobyAiUGxlYXNlIHJ1biBsZGNvbmZpZyAtciBcIiRDUk9TU19TWVNfUk9PVFwiIHRvIGdl
bmVyYXRlIGxkLnNvLmNhY2hlIgotCSAgICAjIGZhbGwgdGhyb3VnaDsgbGRjb25maWcgdGVzdCBi
ZWxvdyBzaG91bGQgZmFpbAotCWZpCi0JaWYgWyAiJHtPU30iID0gIkxpbnV4IiBdOyB0aGVuCi0J
CWxkY29uZmlnIC1wICR7Q1JPU1NfU1lTX1JPT1QrLXIgIiRDUk9TU19TWVNfUk9PVCJ9IHwgZ3Jl
cCAtRnEgIiQxIgotCQlyZXR1cm4gJD8KLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJOZXRCU0QiIF07
IHRoZW4KLQkJbHMgLTEgJHtMSUJSQVJJRVN9IHwgZ3JlcCAtRnEgIiQxIgotCQlyZXR1cm4gJD8K
LQlmaQotCXJldHVybiAxCi0JKQotfQotCi10ZXN0X2xpbmsoKSB7Ci0JIyBzdWJzaGVsbCB0byB0
cmFwIHJlbW92YWwgb2YgdG1wZmlsZQotCSgKLQl1bnNldCB0bXBmaWxlCi0JdHJhcCAncm0gLWYg
IiR0bXBmaWxlIjsgZXhpdCcgMCAxIDIgMTUKLQl0bXBmaWxlPWBta3RlbXBgIHx8IHJldHVybiAx
Ci0JbGQgIiRAIiAtbyAiJHRtcGZpbGUiID4vZGV2L251bGwgMj4mMQotCXJldHVybiAkPwotCSkK
LX0KLQotIyB0aGlzIGZ1bmN0aW9uIGlzIHVzZWQgY29tbW9ubHkgYWJvdmUKLWNoZWNrX3N5c19y
b290KCkgewotCVsgLXogIiRDUk9TU19DT01QSUxFIiBdICYmIHJldHVybiAwCi0JaWYgWyAteiAi
JENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gInBsZWFzZSBzZXQgQ1JPU1NfU1lTX1JP
T1QgaW4gdGhlIGVudmlyb25tZW50IgotCQlyZXR1cm4gMQotCWZpCi0JaWYgWyAhIC1kICIkQ1JP
U1NfU1lTX1JPT1QiIF07IHRoZW4KLQkJZWNobyAibm8gc3lzLXJvb3QgZm91bmQgYXQgJENST1NT
X1NZU19ST09UIgotCQlyZXR1cm4gMQotCWZpCi19Ci0KLXdhcm5pbmcoKSB7Ci0JZWNobwotCWVj
aG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLX0KLQotZmFpbCgpIHsK
LQllY2hvCi0JZWNobyAiICoqKiBgYmFzZW5hbWUgIiQwImAgRkFJTEVEJHsqKzogJCp9IgotCWV4
aXQgMQotfQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY29uZmln
Lmd1ZXNzCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL2NvbmZpZy5ndWVzcwlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAs
MCArMSwxNTIyIEBACisjISAvYmluL3NoCisjIEF0dGVtcHQgdG8gZ3Vlc3MgYSBjYW5vbmljYWwg
c3lzdGVtIG5hbWUuCisjICAgQ29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAx
OTk2LCAxOTk3LCAxOTk4LCAxOTk5LAorIyAgIDIwMDAsIDIwMDEsIDIwMDIsIDIwMDMsIDIwMDQs
IDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDksIDIwMTAsCisjICAgMjAxMSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24sIEluYy4KKwordGltZXN0YW1wPScyMDExLTExLTExJworCisjIFRoaXMg
ZmlsZSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5IGl0CisjIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgYXMgcHVibGlzaGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhl
ciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxh
dGVyIHZlcnNpb24uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9w
ZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp
dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSBy
ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25n
IHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisj
IEZvdW5kYXRpb24sIEluYy4sIDUxIEZyYW5rbGluIFN0cmVldCAtIEZpZnRoIEZsb29yLCBCb3N0
b24sIE1BCisjIDAyMTEwLTEzMDEsIFVTQS4KKyMKKyMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0
byB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGlmIHlvdQorIyBkaXN0cmlidXRlIHRo
aXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSB0aGF0IGNvbnRhaW5zIGEKKyMgY29uZmlndXJh
dGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5k
ZXIKKyMgdGhlIHNhbWUgZGlzdHJpYnV0aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJl
c3Qgb2YgdGhhdCBwcm9ncmFtLgorCisKKyMgT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3Ro
bmVyLiAgUGxlYXNlIHNlbmQgcGF0Y2hlcyAoY29udGV4dAorIyBkaWZmIGZvcm1hdCkgdG8gPGNv
bmZpZy1wYXRjaGVzQGdudS5vcmc+IGFuZCBpbmNsdWRlIGEgQ2hhbmdlTG9nCisjIGVudHJ5Lgor
IworIyBUaGlzIHNjcmlwdCBhdHRlbXB0cyB0byBndWVzcyBhIGNhbm9uaWNhbCBzeXN0ZW0gbmFt
ZSBzaW1pbGFyIHRvCisjIGNvbmZpZy5zdWIuICBJZiBpdCBzdWNjZWVkcywgaXQgcHJpbnRzIHRo
ZSBzeXN0ZW0gbmFtZSBvbiBzdGRvdXQsIGFuZAorIyBleGl0cyB3aXRoIDAuICBPdGhlcndpc2Us
IGl0IGV4aXRzIHdpdGggMS4KKyMKKyMgWW91IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9m
IHRoaXMgc2NyaXB0IGZyb206CisjIGh0dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIv
P3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47Zj1jb25maWcuZ3Vlc3M7aGI9SEVBRAorCittZT1g
ZWNobyAiJDAiIHwgc2VkIC1lICdzLC4qLywsJ2AKKwordXNhZ2U9IlwKK1VzYWdlOiAkMCBbT1BU
SU9OXQorCitPdXRwdXQgdGhlIGNvbmZpZ3VyYXRpb24gbmFtZSBvZiB0aGUgc3lzdGVtIFxgJG1l
JyBpcyBydW4gb24uCisKK09wZXJhdGlvbiBtb2RlczoKKyAgLWgsIC0taGVscCAgICAgICAgIHBy
aW50IHRoaXMgaGVscCwgdGhlbiBleGl0CisgIC10LCAtLXRpbWUtc3RhbXAgICBwcmludCBkYXRl
IG9mIGxhc3QgbW9kaWZpY2F0aW9uLCB0aGVuIGV4aXQKKyAgLXYsIC0tdmVyc2lvbiAgICAgIHBy
aW50IHZlcnNpb24gbnVtYmVyLCB0aGVuIGV4aXQKKworUmVwb3J0IGJ1Z3MgYW5kIHBhdGNoZXMg
dG8gPGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+LiIKKwordmVyc2lvbj0iXAorR05VIGNvbmZpZy5n
dWVzcyAoJHRpbWVzdGFtcCkKKworT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3RobmVyLgor
Q29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAx
OTk5LCAyMDAwLAorMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAw
OCwgMjAwOSwgMjAxMCwgMjAxMSBGcmVlCitTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1Ro
aXMgaXMgZnJlZSBzb2Z0d2FyZTsgc2VlIHRoZSBzb3VyY2UgZm9yIGNvcHlpbmcgY29uZGl0aW9u
cy4gIFRoZXJlIGlzIE5PCit3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBv
ciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iCisKK2hlbHA9IgorVHJ5IFxgJG1l
IC0taGVscCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIgorCisjIFBhcnNlIGNvbW1hbmQgbGluZQor
d2hpbGUgdGVzdCAkIyAtZ3QgMCA7IGRvCisgIGNhc2UgJDEgaW4KKyAgICAtLXRpbWUtc3RhbXAg
fCAtLXRpbWUqIHwgLXQgKQorICAgICAgIGVjaG8gIiR0aW1lc3RhbXAiIDsgZXhpdCA7OworICAg
IC0tdmVyc2lvbiB8IC12ICkKKyAgICAgICBlY2hvICIkdmVyc2lvbiIgOyBleGl0IDs7CisgICAg
LS1oZWxwIHwgLS1oKiB8IC1oICkKKyAgICAgICBlY2hvICIkdXNhZ2UiOyBleGl0IDs7CisgICAg
LS0gKSAgICAgIyBTdG9wIG9wdGlvbiBwcm9jZXNzaW5nCisgICAgICAgc2hpZnQ7IGJyZWFrIDs7
CisgICAgLSApCSMgVXNlIHN0ZGluIGFzIGlucHV0LgorICAgICAgIGJyZWFrIDs7CisgICAgLSog
KQorICAgICAgIGVjaG8gIiRtZTogaW52YWxpZCBvcHRpb24gJDEkaGVscCIgPiYyCisgICAgICAg
ZXhpdCAxIDs7CisgICAgKiApCisgICAgICAgYnJlYWsgOzsKKyAgZXNhYworZG9uZQorCitpZiB0
ZXN0ICQjICE9IDA7IHRoZW4KKyAgZWNobyAiJG1lOiB0b28gbWFueSBhcmd1bWVudHMkaGVscCIg
PiYyCisgIGV4aXQgMQorZmkKKwordHJhcCAnZXhpdCAxJyAxIDIgMTUKKworIyBDQ19GT1JfQlVJ
TEQgLS0gY29tcGlsZXIgdXNlZCBieSB0aGlzIHNjcmlwdC4gTm90ZSB0aGF0IHRoZSB1c2Ugb2Yg
YQorIyBjb21waWxlciB0byBhaWQgaW4gc3lzdGVtIGRldGVjdGlvbiBpcyBkaXNjb3VyYWdlZCBh
cyBpdCByZXF1aXJlcworIyB0ZW1wb3JhcnkgZmlsZXMgdG8gYmUgY3JlYXRlZCBhbmQsIGFzIHlv
dSBjYW4gc2VlIGJlbG93LCBpdCBpcyBhCisjIGhlYWRhY2hlIHRvIGRlYWwgd2l0aCBpbiBhIHBv
cnRhYmxlIGZhc2hpb24uCisKKyMgSGlzdG9yaWNhbGx5LCBgQ0NfRk9SX0JVSUxEJyB1c2VkIHRv
IGJlIG5hbWVkIGBIT1NUX0NDJy4gV2Ugc3RpbGwKKyMgdXNlIGBIT1NUX0NDJyBpZiBkZWZpbmVk
LCBidXQgaXQgaXMgZGVwcmVjYXRlZC4KKworIyBQb3J0YWJsZSB0bXAgZGlyZWN0b3J5IGNyZWF0
aW9uIGluc3BpcmVkIGJ5IHRoZSBBdXRvY29uZiB0ZWFtLgorCitzZXRfY2NfZm9yX2J1aWxkPScK
K3RyYXAgImV4aXRjb2RlPVwkPzsgKHJtIC1mIFwkdG1wZmlsZXMgMj4vZGV2L251bGw7IHJtZGly
IFwkdG1wIDI+L2Rldi9udWxsKSAmJiBleGl0IFwkZXhpdGNvZGUiIDAgOwordHJhcCAicm0gLWYg
XCR0bXBmaWxlcyAyPi9kZXYvbnVsbDsgcm1kaXIgXCR0bXAgMj4vZGV2L251bGw7IGV4aXQgMSIg
MSAyIDEzIDE1IDsKKzogJHtUTVBESVI9L3RtcH0gOworIHsgdG1wPWAodW1hc2sgMDc3ICYmIG1r
dGVtcCAtZCAiJFRNUERJUi9jZ1hYWFhYWCIpIDI+L2Rldi9udWxsYCAmJiB0ZXN0IC1uICIkdG1w
IiAmJiB0ZXN0IC1kICIkdG1wIiA7IH0gfHwKKyB7IHRlc3QgLW4gIiRSQU5ET00iICYmIHRtcD0k
VE1QRElSL2NnJCQtJFJBTkRPTSAmJiAodW1hc2sgMDc3ICYmIG1rZGlyICR0bXApIDsgfSB8fAor
IHsgdG1wPSRUTVBESVIvY2ctJCQgJiYgKHVtYXNrIDA3NyAmJiBta2RpciAkdG1wKSAmJiBlY2hv
ICJXYXJuaW5nOiBjcmVhdGluZyBpbnNlY3VyZSB0ZW1wIGRpcmVjdG9yeSIgPiYyIDsgfSB8fAor
IHsgZWNobyAiJG1lOiBjYW5ub3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGRpcmVjdG9yeSBpbiAkVE1Q
RElSIiA+JjIgOyBleGl0IDEgOyB9IDsKK2R1bW15PSR0bXAvZHVtbXkgOwordG1wZmlsZXM9IiRk
dW1teS5jICRkdW1teS5vICRkdW1teS5yZWwgJGR1bW15IiA7CitjYXNlICRDQ19GT1JfQlVJTEQs
JEhPU1RfQ0MsJENDIGluCisgLCwpICAgIGVjaG8gImludCB4OyIgPiAkZHVtbXkuYyA7CisJZm9y
IGMgaW4gY2MgZ2NjIGM4OSBjOTkgOyBkbworCSAgaWYgKCRjIC1jIC1vICRkdW1teS5vICRkdW1t
eS5jKSA+L2Rldi9udWxsIDI+JjEgOyB0aGVuCisJICAgICBDQ19GT1JfQlVJTEQ9IiRjIjsgYnJl
YWsgOworCSAgZmkgOworCWRvbmUgOworCWlmIHRlc3QgeCIkQ0NfRk9SX0JVSUxEIiA9IHggOyB0
aGVuCisJICBDQ19GT1JfQlVJTEQ9bm9fY29tcGlsZXJfZm91bmQgOworCWZpCisJOzsKKyAsLCop
ICAgQ0NfRk9SX0JVSUxEPSRDQyA7OworICwqLCopICBDQ19GT1JfQlVJTEQ9JEhPU1RfQ0MgOzsK
K2VzYWMgOyBzZXRfY2NfZm9yX2J1aWxkPSA7JworCisjIFRoaXMgaXMgbmVlZGVkIHRvIGZpbmQg
dW5hbWUgb24gYSBQeXJhbWlkIE9TeCB3aGVuIHJ1biBpbiB0aGUgQlNEIHVuaXZlcnNlLgorIyAo
Z2hhemlAbm9jLnJ1dGdlcnMuZWR1IDE5OTQtMDgtMjQpCitpZiAodGVzdCAtZiAvLmF0dGJpbi91
bmFtZSkgPi9kZXYvbnVsbCAyPiYxIDsgdGhlbgorCVBBVEg9JFBBVEg6Ly5hdHRiaW4gOyBleHBv
cnQgUEFUSAorZmkKKworVU5BTUVfTUFDSElORT1gKHVuYW1lIC1tKSAyPi9kZXYvbnVsbGAgfHwg
VU5BTUVfTUFDSElORT11bmtub3duCitVTkFNRV9SRUxFQVNFPWAodW5hbWUgLXIpIDI+L2Rldi9u
dWxsYCB8fCBVTkFNRV9SRUxFQVNFPXVua25vd24KK1VOQU1FX1NZU1RFTT1gKHVuYW1lIC1zKSAy
Pi9kZXYvbnVsbGAgIHx8IFVOQU1FX1NZU1RFTT11bmtub3duCitVTkFNRV9WRVJTSU9OPWAodW5h
bWUgLXYpIDI+L2Rldi9udWxsYCB8fCBVTkFNRV9WRVJTSU9OPXVua25vd24KKworIyBOb3RlOiBv
cmRlciBpcyBzaWduaWZpY2FudCAtIHRoZSBjYXNlIGJyYW5jaGVzIGFyZSBub3QgZXhjbHVzaXZl
LgorCitjYXNlICIke1VOQU1FX01BQ0hJTkV9OiR7VU5BTUVfU1lTVEVNfToke1VOQU1FX1JFTEVB
U0V9OiR7VU5BTUVfVkVSU0lPTn0iIGluCisgICAgKjpOZXRCU0Q6KjoqKQorCSMgTmV0QlNEIChu
YnNkKSB0YXJnZXRzIHNob3VsZCAod2hlcmUgYXBwbGljYWJsZSkgbWF0Y2ggb25lIG9yCisJIyBt
b3JlIG9mIHRoZSB0dXBwbGVzOiAqLSotbmV0YnNkZWxmKiwgKi0qLW5ldGJzZGFvdXQqLAorCSMg
Ki0qLW5ldGJzZGVjb2ZmKiBhbmQgKi0qLW5ldGJzZCouICBGb3IgdGFyZ2V0cyB0aGF0IHJlY2Vu
dGx5CisJIyBzd2l0Y2hlZCB0byBFTEYsICotKi1uZXRic2QqIHdvdWxkIHNlbGVjdCB0aGUgb2xk
CisJIyBvYmplY3QgZmlsZSBmb3JtYXQuICBUaGlzIHByb3ZpZGVzIGJvdGggZm9yd2FyZAorCSMg
Y29tcGF0aWJpbGl0eSBhbmQgYSBjb25zaXN0ZW50IG1lY2hhbmlzbSBmb3Igc2VsZWN0aW5nIHRo
ZQorCSMgb2JqZWN0IGZpbGUgZm9ybWF0LgorCSMKKwkjIE5vdGU6IE5ldEJTRCBkb2Vzbid0IHBh
cnRpY3VsYXJseSBjYXJlIGFib3V0IHRoZSB2ZW5kb3IKKwkjIHBvcnRpb24gb2YgdGhlIG5hbWUu
ICBXZSBhbHdheXMgc2V0IGl0IHRvICJ1bmtub3duIi4KKwlzeXNjdGw9InN5c2N0bCAtbiBody5t
YWNoaW5lX2FyY2giCisJVU5BTUVfTUFDSElORV9BUkNIPWAoL3NiaW4vJHN5c2N0bCAyPi9kZXYv
bnVsbCB8fCBcCisJICAgIC91c3Ivc2Jpbi8kc3lzY3RsIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5r
bm93bilgCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FX0FSQ0h9IiBpbgorCSAgICBhcm1lYikgbWFj
aGluZT1hcm1lYi11bmtub3duIDs7CisJICAgIGFybSopIG1hY2hpbmU9YXJtLXVua25vd24gOzsK
KwkgICAgc2gzZWwpIG1hY2hpbmU9c2hsLXVua25vd24gOzsKKwkgICAgc2gzZWIpIG1hY2hpbmU9
c2gtdW5rbm93biA7OworCSAgICBzaDVlbCkgbWFjaGluZT1zaDVsZS11bmtub3duIDs7CisJICAg
ICopIG1hY2hpbmU9JHtVTkFNRV9NQUNISU5FX0FSQ0h9LXVua25vd24gOzsKKwllc2FjCisJIyBU
aGUgT3BlcmF0aW5nIFN5c3RlbSBpbmNsdWRpbmcgb2JqZWN0IGZvcm1hdCwgaWYgaXQgaGFzIHN3
aXRjaGVkCisJIyB0byBFTEYgcmVjZW50bHksIG9yIHdpbGwgaW4gdGhlIGZ1dHVyZS4KKwljYXNl
ICIke1VOQU1FX01BQ0hJTkVfQVJDSH0iIGluCisJICAgIGFybSp8aTM4NnxtNjhrfG5zMzJrfHNo
Myp8c3BhcmN8dmF4KQorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCWlmIGVjaG8gX19FTEZf
XyB8ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCBcCisJCQl8IGdyZXAgLXEgX19FTEZf
XworCQl0aGVuCisJCSAgICAjIE9uY2UgYWxsIHV0aWxpdGllcyBjYW4gYmUgRUNPRkYgKG5ldGJz
ZGVjb2ZmKSBvciBhLm91dCAobmV0YnNkYW91dCkuCisJCSAgICAjIFJldHVybiBuZXRic2QgZm9y
IGVpdGhlci4gIEZJWD8KKwkJICAgIG9zPW5ldGJzZAorCQllbHNlCisJCSAgICBvcz1uZXRic2Rl
bGYKKwkJZmkKKwkJOzsKKwkgICAgKikKKwkJb3M9bmV0YnNkCisJCTs7CisJZXNhYworCSMgVGhl
IE9TIHJlbGVhc2UKKwkjIERlYmlhbiBHTlUvTmV0QlNEIG1hY2hpbmVzIGhhdmUgYSBkaWZmZXJl
bnQgdXNlcmxhbmQsIGFuZAorCSMgdGh1cywgbmVlZCBhIGRpc3RpbmN0IHRyaXBsZXQuIEhvd2V2
ZXIsIHRoZXkgZG8gbm90IG5lZWQKKwkjIGtlcm5lbCB2ZXJzaW9uIGluZm9ybWF0aW9uLCBzbyBp
dCBjYW4gYmUgcmVwbGFjZWQgd2l0aCBhCisJIyBzdWl0YWJsZSB0YWcsIGluIHRoZSBzdHlsZSBv
ZiBsaW51eC1nbnUuCisJY2FzZSAiJHtVTkFNRV9WRVJTSU9OfSIgaW4KKwkgICAgRGViaWFuKikK
KwkJcmVsZWFzZT0nLWdudScKKwkJOzsKKwkgICAgKikKKwkJcmVsZWFzZT1gZWNobyAke1VOQU1F
X1JFTEVBU0V9fHNlZCAtZSAncy9bLV9dLiovXC4vJ2AKKwkJOzsKKwllc2FjCisJIyBTaW5jZSBD
UFVfVFlQRS1NQU5VRkFDVFVSRVItS0VSTkVMLU9QRVJBVElOR19TWVNURU06CisJIyBjb250YWlu
cyByZWR1bmRhbnQgaW5mb3JtYXRpb24sIHRoZSBzaG9ydGVyIGZvcm06CisJIyBDUFVfVFlQRS1N
QU5VRkFDVFVSRVItT1BFUkFUSU5HX1NZU1RFTSBpcyB1c2VkLgorCWVjaG8gIiR7bWFjaGluZX0t
JHtvc30ke3JlbGVhc2V9IgorCWV4aXQgOzsKKyAgICAqOk9wZW5CU0Q6KjoqKQorCVVOQU1FX01B
Q0hJTkVfQVJDSD1gYXJjaCB8IHNlZCAncy9PcGVuQlNELi8vJ2AKKwllY2hvICR7VU5BTUVfTUFD
SElORV9BUkNIfS11bmtub3duLW9wZW5ic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAg
ICo6ZWtrb0JTRDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tZWtrb2JzZCR7
VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpTb2xpZEJTRDoqOiopCisJZWNobyAke1VO
QU1FX01BQ0hJTkV9LXVua25vd24tc29saWRic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7Owor
ICAgIG1hY3BwYzpNaXJCU0Q6KjoqKQorCWVjaG8gcG93ZXJwYy11bmtub3duLW1pcmJzZCR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpNaXJCU0Q6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLW1pcmJzZCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgYWxw
aGE6T1NGMToqOiopCisJY2FzZSAkVU5BTUVfUkVMRUFTRSBpbgorCSo0LjApCisJCVVOQU1FX1JF
TEVBU0U9YC91c3Ivc2Jpbi9zaXplciAtdiB8IGF3ayAne3ByaW50ICQzfSdgCisJCTs7CisJKjUu
KikKKwkJVU5BTUVfUkVMRUFTRT1gL3Vzci9zYmluL3NpemVyIC12IHwgYXdrICd7cHJpbnQgJDR9
J2AKKwkJOzsKKwllc2FjCisJIyBBY2NvcmRpbmcgdG8gQ29tcGFxLCAvdXNyL3NiaW4vcHNyaW5m
byBoYXMgYmVlbiBhdmFpbGFibGUgb24KKwkjIE9TRi8xIGFuZCBUcnU2NCBzeXN0ZW1zIHByb2R1
Y2VkIHNpbmNlIDE5OTUuICBJIGhvcGUgdGhhdAorCSMgY292ZXJzIG1vc3Qgc3lzdGVtcyBydW5u
aW5nIHRvZGF5LiAgVGhpcyBjb2RlIHBpcGVzIHRoZSBDUFUKKwkjIHR5cGVzIHRocm91Z2ggaGVh
ZCAtbiAxLCBzbyB3ZSBvbmx5IGRldGVjdCB0aGUgdHlwZSBvZiBDUFUgMC4KKwlBTFBIQV9DUFVf
VFlQRT1gL3Vzci9zYmluL3BzcmluZm8gLXYgfCBzZWQgLW4gLWUgJ3MvXiAgVGhlIGFscGhhIFwo
LipcKSBwcm9jZXNzb3IuKiQvXDEvcCcgfCBoZWFkIC1uIDFgCisJY2FzZSAiJEFMUEhBX0NQVV9U
WVBFIiBpbgorCSAgICAiRVY0ICgyMTA2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsK
KwkgICAgIkVWNC41ICgyMTA2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAg
IkxDQTQgKDIxMDY2LzIxMDY4KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhIiA7OworCSAgICAi
RVY1ICgyMTE2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NSIgOzsKKwkgICAgIkVWNS42
ICgyMTE2NEEpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjU2IiA7OworCSAgICAiRVY1LjYg
KDIxMTY0UEMpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFwY2E1NiIgOzsKKwkgICAgIkVWNS43
ICgyMTE2NFBDKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhcGNhNTciIDs7CisJICAgICJFVjYg
KDIxMjY0KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2IiA7OworCSAgICAiRVY2LjcgKDIx
MjY0QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjciIDs7CisJICAgICJFVjYuOENCICgy
MTI2NEMpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY4IiA7OworCSAgICAiRVY2LjhBTCAo
MjEyNjRCKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OCIgOzsKKwkgICAgIkVWNi44Q1gg
KDIxMjY0RCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjgiIDs7CisJICAgICJFVjYuOUEg
KDIxMjY0L0VWNjlBKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OSIgOzsKKwkgICAgIkVW
NyAoMjEzNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjciIDs7CisJICAgICJFVjcuOSAo
MjEzNjRBKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY3OSIgOzsKKwllc2FjCisJIyBBIFBu
Lm4gdmVyc2lvbiBpcyBhIHBhdGNoZWQgdmVyc2lvbi4KKwkjIEEgVm4ubiB2ZXJzaW9uIGlzIGEg
cmVsZWFzZWQgdmVyc2lvbi4KKwkjIEEgVG4ubiB2ZXJzaW9uIGlzIGEgcmVsZWFzZWQgZmllbGQg
dGVzdCB2ZXJzaW9uLgorCSMgQSBYbi5uIHZlcnNpb24gaXMgYW4gdW5yZWxlYXNlZCBleHBlcmlt
ZW50YWwgYmFzZWxldmVsLgorCSMgMS4yIHVzZXMgIjEuMiIgZm9yIHVuYW1lIC1yLgorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1kZWMtb3NmYGVjaG8gJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAn
cy9eW1BWVFhdLy8nIHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hp
amtsbW5vcHFyc3R1dnd4eXonYAorCSMgUmVzZXQgRVhJVCB0cmFwIGJlZm9yZSBleGl0aW5nIHRv
IGF2b2lkIHNwdXJpb3VzIG5vbi16ZXJvIGV4aXQgY29kZS4KKwlleGl0Y29kZT0kPworCXRyYXAg
JycgMAorCWV4aXQgJGV4aXRjb2RlIDs7CisgICAgQWxwaGFcICo6V2luZG93c19OVCo6KikKKwkj
IEhvdyBkbyB3ZSBrbm93IGl0J3MgSW50ZXJpeCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyBQT1NJ
WCBzdWJzeXN0ZW0/CisJIyBTaG91bGQgd2UgY2hhbmdlIFVOQU1FX01BQ0hJTkUgYmFzZWQgb24g
dGhlIG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFkCisJIyBvZiB0aGUgc3BlY2lmaWMgQWxwaGEgbW9k
ZWw/CisJZWNobyBhbHBoYS1wYy1pbnRlcml4CisJZXhpdCA7OworICAgIDIxMDY0OldpbmRvd3Nf
TlQ6NTA6MykKKwllY2hvIGFscGhhLWRlYy13aW5udDMuNQorCWV4aXQgOzsKKyAgICBBbWlnYSo6
VU5JWF9TeXN0ZW1fVjo0LjA6KikKKwllY2hvIG02OGstdW5rbm93bi1zeXN2NAorCWV4aXQgOzsK
KyAgICAqOltBYV1taWdhW09vXVtTc106KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtu
b3duLWFtaWdhb3MKKwlleGl0IDs7CisgICAgKjpbTW1db3JwaFtPb11bU3NdOio6KikKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1tb3JwaG9zCisJZXhpdCA7OworICAgICo6T1MvMzkw
Oio6KikKKwllY2hvIGkzNzAtaWJtLW9wZW5lZGl0aW9uCisJZXhpdCA7OworICAgICo6ei9WTToq
OiopCisJZWNobyBzMzkwLWlibS16dm1vZQorCWV4aXQgOzsKKyAgICAqOk9TNDAwOio6KikKKwll
Y2hvIHBvd2VycGMtaWJtLW9zNDAwCisJZXhpdCA7OworICAgIGFybTpSSVNDKjoxLlswMTJdKjoq
fGFybTpyaXNjaXg6MS5bMDEyXSo6KikKKwllY2hvIGFybS1hY29ybi1yaXNjaXgke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIGFybTpyaXNjb3M6KjoqfGFybTpSSVNDT1M6KjoqKQorCWVj
aG8gYXJtLXVua25vd24tcmlzY29zCisJZXhpdCA7OworICAgIFNSMj8wMTpISS1VWC9NUFA6Kjoq
IHwgU1I4MDAwOkhJLVVYL01QUDoqOiopCisJZWNobyBocHBhMS4xLWhpdGFjaGktaGl1eG1wcAor
CWV4aXQgOzsKKyAgICBQeXJhbWlkKjpPU3gqOio6KiB8IE1JUyo6T1N4KjoqOiogfCBNSVMqOlNN
UF9EQy1PU3gqOio6KikKKwkjIGFrZWVAd3BkaXMwMy53cGFmYi5hZi5taWwgKEVhcmxlIEYuIEFr
ZSkgY29udHJpYnV0ZWQgTUlTIGFuZCBOSUxFLgorCWlmIHRlc3QgImAoL2Jpbi91bml2ZXJzZSkg
Mj4vZGV2L251bGxgIiA9IGF0dCA7IHRoZW4KKwkJZWNobyBweXJhbWlkLXB5cmFtaWQtc3lzdjMK
KwllbHNlCisJCWVjaG8gcHlyYW1pZC1weXJhbWlkLWJzZAorCWZpCisJZXhpdCA7OworICAgIE5J
TEUqOio6KjpkY29zeCkKKwllY2hvIHB5cmFtaWQtcHlyYW1pZC1zdnI0CisJZXhpdCA7OworICAg
IERSUz82MDAwOnVuaXg6NC4wOjYqKQorCWVjaG8gc3BhcmMtaWNsLW54NgorCWV4aXQgOzsKKyAg
ICBEUlM/NjAwMDpVTklYX1NWOjQuMio6NyogfCBEUlM/NjAwMDppc2lzOjQuMio6NyopCisJY2Fz
ZSBgL3Vzci9iaW4vdW5hbWUgLXBgIGluCisJICAgIHNwYXJjKSBlY2hvIHNwYXJjLWljbC1ueDc7
IGV4aXQgOzsKKwllc2FjIDs7CisgICAgczM5MHg6U3VuT1M6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1pYm0tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5d
Ki8vJ2AKKwlleGl0IDs7CisgICAgc3VuNEg6U3VuT1M6NS4qOiopCisJZWNobyBzcGFyYy1oYWwt
c29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0
IDs7CisgICAgc3VuNCo6U3VuT1M6NS4qOiogfCB0YWRwb2xlKjpTdW5PUzo1Lio6KikKKwllY2hv
IHNwYXJjLXN1bi1zb2xhcmlzMmBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0q
Ly8nYAorCWV4aXQgOzsKKyAgICBpODZwYzpBdXJvcmFVWDo1Lio6KiB8IGk4NnhlbjpBdXJvcmFV
WDo1Lio6KikKKwllY2hvIGkzODYtcGMtYXVyb3JhdXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGk4NnBjOlN1bk9TOjUuKjoqIHwgaTg2eGVuOlN1bk9TOjUuKjoqKQorCWV2YWwgJHNl
dF9jY19mb3JfYnVpbGQKKwlTVU5fQVJDSD0iaTM4NiIKKwkjIElmIHRoZXJlIGlzIGEgY29tcGls
ZXIsIHNlZSBpZiBpdCBpcyBjb25maWd1cmVkIGZvciA2NC1iaXQgb2JqZWN0cy4KKwkjIE5vdGUg
dGhhdCB0aGUgU3VuIGNjIGRvZXMgbm90IHR1cm4gX19MUDY0X18gaW50byAxIGxpa2UgZ2NjIGRv
ZXMuCisJIyBUaGlzIHRlc3Qgd29ya3MgZm9yIGJvdGggY29tcGlsZXJzLgorCWlmIFsgIiRDQ19G
T1JfQlVJTEQiICE9ICdub19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCSAgICBpZiAoZWNobyAn
I2lmZGVmIF9fYW1kNjQnOyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicpIHwgXAor
CQkoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwgXAorCQlncmVwIElT
XzY0QklUX0FSQ0ggPi9kZXYvbnVsbAorCSAgICB0aGVuCisJCVNVTl9BUkNIPSJ4ODZfNjQiCisJ
ICAgIGZpCisJZmkKKwllY2hvICR7U1VOX0FSQ0h9LXBjLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9S
RUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjYq
OiopCisJIyBBY2NvcmRpbmcgdG8gY29uZmlnLnN1YiwgdGhpcyBpcyB0aGUgcHJvcGVyIHdheSB0
byBjYW5vbmljYWxpemUKKwkjIFN1bk9TNi4gIEhhcmQgdG8gZ3Vlc3MgZXhhY3RseSB3aGF0IFN1
bk9TNiB3aWxsIGJlIGxpa2UsIGJ1dAorCSMgaXQncyBsaWtlbHkgdG8gYmUgbW9yZSBsaWtlIFNv
bGFyaXMgdGhhbiBTdW5PUzQuCisJZWNobyBzcGFyYy1zdW4tc29sYXJpczNgZWNobyAke1VOQU1F
X1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgc3VuNCo6U3VuT1M6
KjoqKQorCWNhc2UgImAvdXNyL2Jpbi9hcmNoIC1rYCIgaW4KKwkgICAgU2VyaWVzKnxTNCopCisJ
CVVOQU1FX1JFTEVBU0U9YHVuYW1lIC12YAorCQk7OworCWVzYWMKKwkjIEphcGFuZXNlIExhbmd1
YWdlIHZlcnNpb25zIGhhdmUgYSB2ZXJzaW9uIG51bWJlciBsaWtlIGA0LjEuMy1KTCcuCisJZWNo
byBzcGFyYy1zdW4tc3Vub3NgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vJ2AK
KwlleGl0IDs7CisgICAgc3VuMyo6U3VuT1M6KjoqKQorCWVjaG8gbTY4ay1zdW4tc3Vub3Mke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHN1bio6Kjo0LjJCU0Q6KikKKwlVTkFNRV9SRUxF
QVNFPWAoc2VkIDFxIC9ldGMvbW90ZCB8IGF3ayAne3ByaW50IHN1YnN0cigkNSwxLDMpfScpIDI+
L2Rldi9udWxsYAorCXRlc3QgIngke1VOQU1FX1JFTEVBU0V9IiA9ICJ4IiAmJiBVTkFNRV9SRUxF
QVNFPTMKKwljYXNlICJgL2Jpbi9hcmNoYCIgaW4KKwkgICAgc3VuMykKKwkJZWNobyBtNjhrLXN1
bi1zdW5vcyR7VU5BTUVfUkVMRUFTRX0KKwkJOzsKKwkgICAgc3VuNCkKKwkJZWNobyBzcGFyYy1z
dW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJCTs7CisJZXNhYworCWV4aXQgOzsKKyAgICBhdXNo
cDpTdW5PUzoqOiopCisJZWNobyBzcGFyYy1hdXNwZXgtc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgICMgVGhlIHNpdHVhdGlvbiBmb3IgTWlOVCBpcyBhIGxpdHRsZSBjb25mdXNp
bmcuICBUaGUgbWFjaGluZSBuYW1lCisgICAgIyBjYW4gYmUgdmlydHVhbGx5IGV2ZXJ5dGhpbmcg
KGV2ZXJ5dGhpbmcgd2hpY2ggaXMgbm90CisgICAgIyAiYXRhcmlzdCIgb3IgImF0YXJpc3RlIiBh
dCBsZWFzdCBzaG91bGQgaGF2ZSBhIHByb2Nlc3NvcgorICAgICMgPiBtNjgwMDApLiAgVGhlIHN5
c3RlbSBuYW1lIHJhbmdlcyBmcm9tICJNaU5UIiBvdmVyICJGcmVlTWlOVCIKKyAgICAjIHRvIHRo
ZSBsb3dlcmNhc2UgdmVyc2lvbiAibWludCIgKG9yICJmcmVlbWludCIpLiAgRmluYWxseQorICAg
ICMgdGhlIHN5c3RlbSBuYW1lICJUT1MiIGRlbm90ZXMgYSBzeXN0ZW0gd2hpY2ggaXMgYWN0dWFs
bHkgbm90CisgICAgIyBNaU5ULiAgQnV0IE1pTlQgaXMgZG93bndhcmQgY29tcGF0aWJsZSB0byBU
T1MsIHNvIHRoaXMgc2hvdWxkCisgICAgIyBiZSBubyBwcm9ibGVtLgorICAgIGF0YXJpc3RbZV06
Kk1pTlQ6KjoqIHwgYXRhcmlzdFtlXToqbWludDoqOiogfCBhdGFyaXN0W2VdOipUT1M6KjoqKQor
CWVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBhdGFy
aSo6Kk1pTlQ6KjoqIHwgYXRhcmkqOiptaW50Oio6KiB8IGF0YXJpc3RbZV06KlRPUzoqOiopCisJ
ZWNobyBtNjhrLWF0YXJpLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICpmYWxj
b24qOipNaU5UOio6KiB8ICpmYWxjb24qOiptaW50Oio6KiB8ICpmYWxjb24qOipUT1M6KjoqKQor
CWVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBtaWxh
bio6Kk1pTlQ6KjoqIHwgbWlsYW4qOiptaW50Oio6KiB8ICptaWxhbio6KlRPUzoqOiopCisJZWNo
byBtNjhrLW1pbGFuLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIGhhZGVzKjoq
TWlOVDoqOiogfCBoYWRlcyo6Km1pbnQ6KjoqIHwgKmhhZGVzKjoqVE9TOio6KikKKwllY2hvIG02
OGstaGFkZXMtbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjoqTWlOVDoqOiog
fCAqOiptaW50Oio6KiB8ICo6KlRPUzoqOiopCisJZWNobyBtNjhrLXVua25vd24tbWludCR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgbTY4azptYWNodGVuOio6KikKKwllY2hvIG02OGst
YXBwbGUtbWFjaHRlbiR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgcG93ZXJwYzptYWNo
dGVuOio6KikKKwllY2hvIHBvd2VycGMtYXBwbGUtbWFjaHRlbiR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgUklTQyo6TWFjaDoqOiopCisJZWNobyBtaXBzLWRlYy1tYWNoX2JzZDQuMwor
CWV4aXQgOzsKKyAgICBSSVNDKjpVTFRSSVg6KjoqKQorCWVjaG8gbWlwcy1kZWMtdWx0cml4JHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBWQVgqOlVMVFJJWCo6KjoqKQorCWVjaG8gdmF4
LWRlYy11bHRyaXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIDIwMjA6Q0xJWDoqOiog
fCAyNDMwOkNMSVg6KjoqKQorCWVjaG8gY2xpcHBlci1pbnRlcmdyYXBoLWNsaXgke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIG1pcHM6KjoqOlVNSVBTIHwgbWlwczoqOio6UklTQ29zKQor
CWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYwor
I2lmZGVmIF9fY3BsdXNwbHVzCisjaW5jbHVkZSA8c3RkaW8uaD4gIC8qIGZvciBwcmludGYoKSBw
cm90b3R5cGUgKi8KKwlpbnQgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkgeworI2Vsc2UK
KwlpbnQgbWFpbiAoYXJnYywgYXJndikgaW50IGFyZ2M7IGNoYXIgKmFyZ3ZbXTsgeworI2VuZGlm
CisJI2lmIGRlZmluZWQgKGhvc3RfbWlwcykgJiYgZGVmaW5lZCAoTUlQU0VCKQorCSNpZiBkZWZp
bmVkIChTWVNUWVBFX1NZU1YpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzeXN2XG4i
LCBhcmd2WzFdKTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfU1ZS
NCkKKwkgIHByaW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc3N2cjRcbiIsIGFyZ3ZbMV0pOyBleGl0
ICgwKTsKKwkjZW5kaWYKKwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9CU0Q0MykgfHwgZGVmaW5lZChT
WVNUWVBFX0JTRCkKKwkgIHByaW50ZiAoIm1pcHMtbWlwcy1yaXNjb3Mlc2JzZFxuIiwgYXJndlsx
XSk7IGV4aXQgKDApOworCSNlbmRpZgorCSNlbmRpZgorCSAgZXhpdCAoLTEpOworCX0KK0VPRgor
CSRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmCisJICBkdW1teWFyZz1gZWNobyAi
JHtVTkFNRV9SRUxFQVNFfSIgfCBzZWQgLW4gJ3MvXChbMC05XSpcKS4qL1wxL3AnYCAmJgorCSAg
U1lTVEVNX05BTUU9YCRkdW1teSAkZHVtbXlhcmdgICYmCisJICAgIHsgZWNobyAiJFNZU1RFTV9O
QU1FIjsgZXhpdDsgfQorCWVjaG8gbWlwcy1taXBzLXJpc2NvcyR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgTW90b3JvbGE6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93ZXJwYy1tb3Rv
cm9sYS1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBNb3Rvcm9sYToqOjQuMzpQTDgtKikKKwllY2hv
IHBvd2VycGMtaGFycmlzLXBvd2VybWF4CisJZXhpdCA7OworICAgIE5pZ2h0X0hhd2s6KjoqOlBv
d2VyTUFYX09TIHwgU3luZXJneTpQb3dlck1BWF9PUzoqOiopCisJZWNobyBwb3dlcnBjLWhhcnJp
cy1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBOaWdodF9IYXdrOlBvd2VyX1VOSVg6KjoqKQorCWVj
aG8gcG93ZXJwYy1oYXJyaXMtcG93ZXJ1bml4CisJZXhpdCA7OworICAgIG04OGs6Q1gvVVg6Nyo6
KikKKwllY2hvIG04OGstaGFycmlzLWN4dXg3CisJZXhpdCA7OworICAgIG04OGs6Kjo0KjpSNCop
CisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3Y0CisJZXhpdCA7OworICAgIG04OGs6KjozKjpSMyop
CisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIEFWaWlPTjpkZ3V4Oio6
KikKKwkjIERHL1VYIHJldHVybnMgQVZpaU9OIGZvciBhbGwgYXJjaGl0ZWN0dXJlcworCVVOQU1F
X1BST0NFU1NPUj1gL3Vzci9iaW4vdW5hbWUgLXBgCisJaWYgWyAkVU5BTUVfUFJPQ0VTU09SID0g
bWM4ODEwMCBdIHx8IFsgJFVOQU1FX1BST0NFU1NPUiA9IG1jODgxMTAgXQorCXRoZW4KKwkgICAg
aWYgWyAke1RBUkdFVF9CSU5BUllfSU5URVJGQUNFfXggPSBtODhrZGd1eGVsZnggXSB8fCBcCisJ
ICAgICAgIFsgJHtUQVJHRVRfQklOQVJZX0lOVEVSRkFDRX14ID0geCBdCisJICAgIHRoZW4KKwkJ
ZWNobyBtODhrLWRnLWRndXgke1VOQU1FX1JFTEVBU0V9CisJICAgIGVsc2UKKwkJZWNobyBtODhr
LWRnLWRndXhiY3Mke1VOQU1FX1JFTEVBU0V9CisJICAgIGZpCisJZWxzZQorCSAgICBlY2hvIGk1
ODYtZGctZGd1eCR7VU5BTUVfUkVMRUFTRX0KKwlmaQorCWV4aXQgOzsKKyAgICBNODgqOkRvbHBo
aW5PUzoqOiopCSMgRG9scGhpbk9TIChTVlIzKQorCWVjaG8gbTg4ay1kb2xwaGluLXN5c3YzCisJ
ZXhpdCA7OworICAgIE04OCo6KjpSMyo6KikKKwkjIERlbHRhIDg4ayBzeXN0ZW0gcnVubmluZyBT
VlIzCisJZWNobyBtODhrLW1vdG9yb2xhLXN5c3YzCisJZXhpdCA7OworICAgIFhEODgqOio6Kjoq
KSAjIFRla3Ryb25peCBYRDg4IHN5c3RlbSBydW5uaW5nIFVUZWtWIChTVlIzKQorCWVjaG8gbTg4
ay10ZWt0cm9uaXgtc3lzdjMKKwlleGl0IDs7CisgICAgVGVrNDNbMC05XVswLTldOlVUZWs6Kjoq
KSAjIFRla3Ryb25peCA0MzAwIHN5c3RlbSBydW5uaW5nIFVUZWsgKEJTRCkKKwllY2hvIG02OGst
dGVrdHJvbml4LWJzZAorCWV4aXQgOzsKKyAgICAqOklSSVgqOio6KikKKwllY2hvIG1pcHMtc2dp
LWlyaXhgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy8tL18vZydgCisJZXhpdCA7Owor
ICAgID8/Pz8/Pz8/OkFJWD86WzEyXS4xOjIpICAgIyBBSVggMi4yLjEgb3IgQUlYIDIuMS4xIGlz
IFJUL1BDIEFJWC4KKwllY2hvIHJvbXAtaWJtLWFpeCAgICAgIyB1bmFtZSAtbSBnaXZlcyBhbiA4
IGhleC1jb2RlIENQVSBpZAorCWV4aXQgOzsgICAgICAgICAgICAgICAjIE5vdGUgdGhhdDogZWNo
byAiJ2B1bmFtZSAtc2AnIiBnaXZlcyAnQUlYICcKKyAgICBpKjg2OkFJWDoqOiopCisJZWNobyBp
Mzg2LWlibS1haXgKKwlleGl0IDs7CisgICAgaWE2NDpBSVg6KjoqKQorCWlmIFsgLXggL3Vzci9i
aW4vb3NsZXZlbCBdIDsgdGhlbgorCQlJQk1fUkVWPWAvdXNyL2Jpbi9vc2xldmVsYAorCWVsc2UK
KwkJSUJNX1JFVj0ke1VOQU1FX1ZFUlNJT059LiR7VU5BTUVfUkVMRUFTRX0KKwlmaQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1pYm0tYWl4JHtJQk1fUkVWfQorCWV4aXQgOzsKKyAgICAqOkFJWDoy
OjMpCisJaWYgZ3JlcCBib3MzMjUgL3Vzci9pbmNsdWRlL3N0ZGlvLmggPi9kZXYvbnVsbCAyPiYx
OyB0aGVuCisJCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJc2VkICdzL14JCS8vJyA8PCBFT0Yg
PiRkdW1teS5jCisJCSNpbmNsdWRlIDxzeXMvc3lzdGVtY2ZnLmg+CisKKwkJbWFpbigpCisJCQl7
CisJCQlpZiAoIV9fcG93ZXJfcGMoKSkKKwkJCQlleGl0KDEpOworCQkJcHV0cygicG93ZXJwYy1p
Ym0tYWl4My4yLjUiKTsKKwkJCWV4aXQoMCk7CisJCQl9CitFT0YKKwkJaWYgJENDX0ZPUl9CVUlM
RCAtbyAkZHVtbXkgJGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRkdW1teWAKKwkJdGhlbgorCQkJ
ZWNobyAiJFNZU1RFTV9OQU1FIgorCQllbHNlCisJCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yLjUK
KwkJZmkKKwllbGlmIGdyZXAgYm9zMzI0IC91c3IvaW5jbHVkZS9zdGRpby5oID4vZGV2L251bGwg
Mj4mMTsgdGhlbgorCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yLjQKKwllbHNlCisJCWVjaG8gcnM2
MDAwLWlibS1haXgzLjIKKwlmaQorCWV4aXQgOzsKKyAgICAqOkFJWDoqOls0NTY3XSkKKwlJQk1f
Q1BVX0lEPWAvdXNyL3NiaW4vbHNkZXYgLUMgLWMgcHJvY2Vzc29yIC1TIGF2YWlsYWJsZSB8IHNl
ZCAxcSB8IGF3ayAneyBwcmludCAkMSB9J2AKKwlpZiAvdXNyL3NiaW4vbHNhdHRyIC1FbCAke0lC
TV9DUFVfSUR9IHwgZ3JlcCAnIFBPV0VSJyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKwkJSUJNX0FS
Q0g9cnM2MDAwCisJZWxzZQorCQlJQk1fQVJDSD1wb3dlcnBjCisJZmkKKwlpZiBbIC14IC91c3Iv
YmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1gL3Vzci9iaW4vb3NsZXZlbGAKKwllbHNl
CisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VOQU1FX1JFTEVBU0V9CisJZmkKKwllY2hv
ICR7SUJNX0FSQ0h9LWlibS1haXgke0lCTV9SRVZ9CisJZXhpdCA7OworICAgICo6QUlYOio6KikK
KwllY2hvIHJzNjAwMC1pYm0tYWl4CisJZXhpdCA7OworICAgIGlibXJ0OjQuNEJTRDoqfHJvbXAt
aWJtOkJTRDoqKQorCWVjaG8gcm9tcC1pYm0tYnNkNC40CisJZXhpdCA7OworICAgIGlibXJ0OipC
U0Q6Knxyb21wLWlibTpCU0Q6KikgICAgICAgICAgICAjIGNvdmVycyBSVC9QQyBCU0QgYW5kCisJ
ZWNobyByb21wLWlibS1ic2Qke1VOQU1FX1JFTEVBU0V9ICAgIyA0LjMgd2l0aCB1bmFtZSBhZGRl
ZCB0bworCWV4aXQgOzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgcmVwb3J0OiByb21w
LWlibSBCU0QgNC4zCisgICAgKjpCT1NYOio6KikKKwllY2hvIHJzNjAwMC1idWxsLWJvc3gKKwll
eGl0IDs7CisgICAgRFBYLzI/MDA6Qi5PLlMuOio6KikKKwllY2hvIG02OGstYnVsbC1zeXN2Mwor
CWV4aXQgOzsKKyAgICA5MDAwL1szNF0/Pzo0LjNic2Q6MS4qOiopCisJZWNobyBtNjhrLWhwLWJz
ZAorCWV4aXQgOzsKKyAgICBocDMwMDo0LjRCU0Q6KjoqIHwgOTAwMC9bMzRdPz86NC4zYnNkOjIu
KjoqKQorCWVjaG8gbTY4ay1ocC1ic2Q0LjQKKwlleGl0IDs7CisgICAgOTAwMC9bMzQ2NzhdPz86
SFAtVVg6KjoqKQorCUhQVVhfUkVWPWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1te
Ll0qLlswQl0qLy8nYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORX0iIGluCisJICAgIDkwMDAvMzE/
ICkgICAgICAgICAgICBIUF9BUkNIPW02ODAwMCA7OworCSAgICA5MDAwL1szNF0/PyApICAgICAg
ICAgSFBfQVJDSD1tNjhrIDs7CisJICAgIDkwMDAvWzY3OF1bMC05XVswLTldKQorCQlpZiBbIC14
IC91c3IvYmluL2dldGNvbmYgXTsgdGhlbgorCQkgICAgc2NfY3B1X3ZlcnNpb249YC91c3IvYmlu
L2dldGNvbmYgU0NfQ1BVX1ZFUlNJT04gMj4vZGV2L251bGxgCisJCSAgICBzY19rZXJuZWxfYml0
cz1gL3Vzci9iaW4vZ2V0Y29uZiBTQ19LRVJORUxfQklUUyAyPi9kZXYvbnVsbGAKKwkJICAgIGNh
c2UgIiR7c2NfY3B1X3ZlcnNpb259IiBpbgorCQkgICAgICA1MjMpIEhQX0FSQ0g9ImhwcGExLjAi
IDs7ICMgQ1BVX1BBX1JJU0MxXzAKKwkJICAgICAgNTI4KSBIUF9BUkNIPSJocHBhMS4xIiA7OyAj
IENQVV9QQV9SSVNDMV8xCisJCSAgICAgIDUzMikgICAgICAgICAgICAgICAgICAgICAgIyBDUFVf
UEFfUklTQzJfMAorCQkJY2FzZSAiJHtzY19rZXJuZWxfYml0c30iIGluCisJCQkgIDMyKSBIUF9B
UkNIPSJocHBhMi4wbiIgOzsKKwkJCSAgNjQpIEhQX0FSQ0g9ImhwcGEyLjB3IiA7OworCQkJICAn
JykgSFBfQVJDSD0iaHBwYTIuMCIgOzsgICAjIEhQLVVYIDEwLjIwCisJCQllc2FjIDs7CisJCSAg
ICBlc2FjCisJCWZpCisJCWlmIFsgIiR7SFBfQVJDSH0iID0gIiIgXTsgdGhlbgorCQkgICAgZXZh
bCAkc2V0X2NjX2Zvcl9idWlsZAorCQkgICAgc2VkICdzL14JCS8vJyA8PCBFT0YgPiRkdW1teS5j
CisKKwkJI2RlZmluZSBfSFBVWF9TT1VSQ0UKKwkJI2luY2x1ZGUgPHN0ZGxpYi5oPgorCQkjaW5j
bHVkZSA8dW5pc3RkLmg+CisKKwkJaW50IG1haW4gKCkKKwkJeworCQkjaWYgZGVmaW5lZChfU0Nf
S0VSTkVMX0JJVFMpCisJCSAgICBsb25nIGJpdHMgPSBzeXNjb25mKF9TQ19LRVJORUxfQklUUyk7
CisJCSNlbmRpZgorCQkgICAgbG9uZyBjcHUgID0gc3lzY29uZiAoX1NDX0NQVV9WRVJTSU9OKTsK
KworCQkgICAgc3dpdGNoIChjcHUpCisJCQl7CisJCQljYXNlIENQVV9QQV9SSVNDMV8wOiBwdXRz
ICgiaHBwYTEuMCIpOyBicmVhazsKKwkJCWNhc2UgQ1BVX1BBX1JJU0MxXzE6IHB1dHMgKCJocHBh
MS4xIik7IGJyZWFrOworCQkJY2FzZSBDUFVfUEFfUklTQzJfMDoKKwkJI2lmIGRlZmluZWQoX1ND
X0tFUk5FTF9CSVRTKQorCQkJICAgIHN3aXRjaCAoYml0cykKKwkJCQl7CisJCQkJY2FzZSA2NDog
cHV0cyAoImhwcGEyLjB3Iik7IGJyZWFrOworCQkJCWNhc2UgMzI6IHB1dHMgKCJocHBhMi4wbiIp
OyBicmVhazsKKwkJCQlkZWZhdWx0OiBwdXRzICgiaHBwYTIuMCIpOyBicmVhazsKKwkJCQl9IGJy
ZWFrOworCQkjZWxzZSAgLyogIWRlZmluZWQoX1NDX0tFUk5FTF9CSVRTKSAqLworCQkJICAgIHB1
dHMgKCJocHBhMi4wIik7IGJyZWFrOworCQkjZW5kaWYKKwkJCWRlZmF1bHQ6IHB1dHMgKCJocHBh
MS4wIik7IGJyZWFrOworCQkJfQorCQkgICAgZXhpdCAoMCk7CisJCX0KK0VPRgorCQkgICAgKEND
T1BUUz0gJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgMj4vZGV2L251bGwpICYmIEhQ
X0FSQ0g9YCRkdW1teWAKKwkJICAgIHRlc3QgLXogIiRIUF9BUkNIIiAmJiBIUF9BUkNIPWhwcGEK
KwkJZmkgOzsKKwllc2FjCisJaWYgWyAke0hQX0FSQ0h9ID0gImhwcGEyLjB3IiBdCisJdGhlbgor
CSAgICBldmFsICRzZXRfY2NfZm9yX2J1aWxkCisKKwkgICAgIyBocHBhMi4wdy1ocC1ocHV4KiBo
YXMgYSA2NC1iaXQga2VybmVsIGFuZCBhIGNvbXBpbGVyIGdlbmVyYXRpbmcKKwkgICAgIyAzMi1i
aXQgY29kZS4gIGhwcGE2NC1ocC1ocHV4KiBoYXMgdGhlIHNhbWUga2VybmVsIGFuZCBhIGNvbXBp
bGVyCisJICAgICMgZ2VuZXJhdGluZyA2NC1iaXQgY29kZS4gIEdOVSBhbmQgSFAgdXNlIGRpZmZl
cmVudCBub21lbmNsYXR1cmU6CisJICAgICMKKwkgICAgIyAkIENDX0ZPUl9CVUlMRD1jYyAuL2Nv
bmZpZy5ndWVzcworCSAgICAjID0+IGhwcGEyLjB3LWhwLWhwdXgxMS4yMworCSAgICAjICQgQ0Nf
Rk9SX0JVSUxEPSJjYyArREEyLjB3IiAuL2NvbmZpZy5ndWVzcworCSAgICAjID0+IGhwcGE2NC1o
cC1ocHV4MTEuMjMKKworCSAgICBpZiBlY2hvIF9fTFA2NF9fIHwgKENDT1BUUz0gJENDX0ZPUl9C
VUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8CisJCWdyZXAgLXEgX19MUDY0X18KKwkgICAgdGhlbgor
CQlIUF9BUkNIPSJocHBhMi4wdyIKKwkgICAgZWxzZQorCQlIUF9BUkNIPSJocHBhNjQiCisJICAg
IGZpCisJZmkKKwllY2hvICR7SFBfQVJDSH0taHAtaHB1eCR7SFBVWF9SRVZ9CisJZXhpdCA7Owor
ICAgIGlhNjQ6SFAtVVg6KjoqKQorCUhQVVhfUkVWPWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2Vk
IC1lICdzL1teLl0qLlswQl0qLy8nYAorCWVjaG8gaWE2NC1ocC1ocHV4JHtIUFVYX1JFVn0KKwll
eGl0IDs7CisgICAgMzA1MCo6SEktVVg6KjoqKQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlz
ZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworCSNpbmNsdWRlIDx1bmlzdGQuaD4KKwlpbnQK
KwltYWluICgpCisJeworCSAgbG9uZyBjcHUgPSBzeXNjb25mIChfU0NfQ1BVX1ZFUlNJT04pOwor
CSAgLyogVGhlIG9yZGVyIG1hdHRlcnMsIGJlY2F1c2UgQ1BVX0lTX0hQX01DNjhLIGVycm9uZW91
c2x5IHJldHVybnMKKwkgICAgIHRydWUgZm9yIENQVV9QQV9SSVNDMV8wLiAgQ1BVX0lTX1BBX1JJ
U0MgcmV0dXJucyBjb3JyZWN0CisJICAgICByZXN1bHRzLCBob3dldmVyLiAgKi8KKwkgIGlmIChD
UFVfSVNfUEFfUklTQyAoY3B1KSkKKwkgICAgeworCSAgICAgIHN3aXRjaCAoY3B1KQorCQl7CisJ
CSAgY2FzZSBDUFVfUEFfUklTQzFfMDogcHV0cyAoImhwcGExLjAtaGl0YWNoaS1oaXV4d2UyIik7
IGJyZWFrOworCQkgIGNhc2UgQ1BVX1BBX1JJU0MxXzE6IHB1dHMgKCJocHBhMS4xLWhpdGFjaGkt
aGl1eHdlMiIpOyBicmVhazsKKwkJICBjYXNlIENQVV9QQV9SSVNDMl8wOiBwdXRzICgiaHBwYTIu
MC1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJCSAgZGVmYXVsdDogcHV0cyAoImhwcGEtaGl0
YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQl9CisJICAgIH0KKwkgIGVsc2UgaWYgKENQVV9JU19I
UF9NQzY4SyAoY3B1KSkKKwkgICAgcHV0cyAoIm02OGstaGl0YWNoaS1oaXV4d2UyIik7CisJICBl
bHNlIHB1dHMgKCJ1bmtub3duLWhpdGFjaGktaGl1eHdlMiIpOworCSAgZXhpdCAoMCk7CisJfQor
RU9GCisJJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRk
dW1teWAgJiYKKwkJeyBlY2hvICIkU1lTVEVNX05BTUUiOyBleGl0OyB9CisJZWNobyB1bmtub3du
LWhpdGFjaGktaGl1eHdlMgorCWV4aXQgOzsKKyAgICA5MDAwLzc/Pzo0LjNic2Q6KjoqIHwgOTAw
MC84P1s3OV06NC4zYnNkOio6KiApCisJZWNobyBocHBhMS4xLWhwLWJzZAorCWV4aXQgOzsKKyAg
ICA5MDAwLzg/Pzo0LjNic2Q6KjoqKQorCWVjaG8gaHBwYTEuMC1ocC1ic2QKKwlleGl0IDs7Cisg
ICAgKjk/Pyo6TVBFL2lYOio6KiB8ICozMDAwKjpNUEUvaVg6KjoqKQorCWVjaG8gaHBwYTEuMC1o
cC1tcGVpeAorCWV4aXQgOzsKKyAgICBocDc/PzpPU0YxOio6KiB8IGhwOD9bNzldOk9TRjE6Kjoq
ICkKKwllY2hvIGhwcGExLjEtaHAtb3NmCisJZXhpdCA7OworICAgIGhwOD8/Ok9TRjE6KjoqKQor
CWVjaG8gaHBwYTEuMC1ocC1vc2YKKwlleGl0IDs7CisgICAgaSo4NjpPU0YxOio6KikKKwlpZiBb
IC14IC91c3Ivc2Jpbi9zeXN2ZXJzaW9uIF0gOyB0aGVuCisJICAgIGVjaG8gJHtVTkFNRV9NQUNI
SU5FfS11bmtub3duLW9zZjFtaworCWVsc2UKKwkgICAgZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tb3NmMQorCWZpCisJZXhpdCA7OworICAgIHBhcmlzYyo6TGl0ZXMqOio6KikKKwllY2hv
IGhwcGExLjEtaHAtbGl0ZXMKKwlleGl0IDs7CisgICAgQzEqOkNvbnZleE9TOio6KiB8IGNvbnZl
eDpDb252ZXhPUzpDMSo6KikKKwllY2hvIGMxLWNvbnZleC1ic2QKKwlleGl0IDs7CisgICAgQzIq
OkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMio6KikKKwlpZiBnZXRzeXNpbmZvIC1m
IHNjYWxhcl9hY2MKKwl0aGVuIGVjaG8gYzMyLWNvbnZleC1ic2QKKwllbHNlIGVjaG8gYzItY29u
dmV4LWJzZAorCWZpCisJZXhpdCA7OworICAgIEMzNCo6Q29udmV4T1M6KjoqIHwgY29udmV4OkNv
bnZleE9TOkMzNCo6KikKKwllY2hvIGMzNC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIEMzOCo6
Q29udmV4T1M6KjoqIHwgY29udmV4OkNvbnZleE9TOkMzOCo6KikKKwllY2hvIGMzOC1jb252ZXgt
YnNkCisJZXhpdCA7OworICAgIEM0KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzQq
OiopCisJZWNobyBjNC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIENSQVkqWS1NUDoqOio6KikK
KwllY2hvIHltcC1jcmF5LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5d
KiQvLlgvJworCWV4aXQgOzsKKyAgICBDUkFZKltBLVpdOTA6KjoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSBcCisJfCBzZWQgLWUgJ3MvQ1JB
WS4qXChbQS1aXTkwXCkvXDEvJyBcCisJICAgICAgLWUgeS9BQkNERUZHSElKS0xNTk9QUVJTVFVW
V1hZWi9hYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ei8gXAorCSAgICAgIC1lICdzL1wuW14uXSok
Ly5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpUUzoqOio6KikKKwllY2hvIHQ5MC1jcmF5LXVuaWNv
cyR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5dKiQvLlgvJworCWV4aXQgOzsKKyAg
ICBDUkFZKlQzRToqOio6KikKKwllY2hvIGFscGhhZXY1LWNyYXktdW5pY29zbWske1VOQU1FX1JF
TEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpTVjE6
KjoqOiopCisJZWNobyBzdjEtY3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdz
L1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgKjpVTklDT1MvbXA6KjoqKQorCWVjaG8gY3Jh
eW52LWNyYXktdW5pY29zbXAke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5Y
LycKKwlleGl0IDs7CisgICAgRjMwWzAxXTpVTklYX1N5c3RlbV9WOio6KiB8IEY3MDA6VU5JWF9T
eXN0ZW1fVjoqOiopCisJRlVKSVRTVV9QUk9DPWB1bmFtZSAtbSB8IHRyICdBQkNERUZHSElKS0xN
Tk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6J2AKKwlGVUpJVFNVX1NZ
Uz1gdW5hbWUgLXAgfCB0ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVonICdhYmNkZWZnaGlq
a2xtbm9wcXJzdHV2d3h5eicgfCBzZWQgLWUgJ3MvXC8vLydgCisJRlVKSVRTVV9SRUw9YGVjaG8g
JHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy8gL18vJ2AKKwllY2hvICIke0ZVSklUU1VfUFJP
Q30tZnVqaXRzdS0ke0ZVSklUU1VfU1lTfSR7RlVKSVRTVV9SRUx9IgorCWV4aXQgOzsKKyAgICA1
MDAwOlVOSVhfU3lzdGVtX1Y6NC4qOiopCisJRlVKSVRTVV9TWVM9YHVuYW1lIC1wIHwgdHIgJ0FC
Q0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHwg
c2VkIC1lICdzL1wvLy8nYAorCUZVSklUU1VfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCB0
ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVonICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5
eicgfCBzZWQgLWUgJ3MvIC9fLydgCisJZWNobyAic3BhcmMtZnVqaXRzdS0ke0ZVSklUU1VfU1lT
fSR7RlVKSVRTVV9SRUx9IgorCWV4aXQgOzsKKyAgICBpKjg2OkJTRC8zODY6KjoqIHwgaSo4NjpC
U0QvT1M6KjoqIHwgKjpBc2NlbmRcIEVtYmVkZGVkL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tcGMtYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgc3BhcmMqOkJTRC9P
UzoqOiopCisJZWNobyBzcGFyYy11bmtub3duLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgICo6QlNEL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1ic2Rp
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOkZyZWVCU0Q6KjoqKQorCVVOQU1FX1BS
T0NFU1NPUj1gL3Vzci9iaW4vdW5hbWUgLXBgCisJY2FzZSAke1VOQU1FX1BST0NFU1NPUn0gaW4K
KwkgICAgYW1kNjQpCisJCWVjaG8geDg2XzY0LXVua25vd24tZnJlZWJzZGBlY2hvICR7VU5BTUVf
UkVMRUFTRX18c2VkIC1lICdzL1stKF0uKi8vJ2AgOzsKKwkgICAgKikKKwkJZWNobyAke1VOQU1F
X1BST0NFU1NPUn0tdW5rbm93bi1mcmVlYnNkYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvWy0oXS4qLy8nYCA7OworCWVzYWMKKwlleGl0IDs7CisgICAgaSo6Q1lHV0lOKjoqKQorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS1wYy1jeWd3aW4KKwlleGl0IDs7CisgICAgKjpNSU5HVyo6KikK
KwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbWluZ3czMgorCWV4aXQgOzsKKyAgICBpKjpNU1lT
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1tc3lzCisJZXhpdCA7OworICAgIGkqOndp
bmRvd3MzMio6KikKKwkjIHVuYW1lIC1tIGluY2x1ZGVzICItcGMiIG9uIHRoaXMgc3lzdGVtLgor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1taW5ndzMyCisJZXhpdCA7OworICAgIGkqOlBXKjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1wdzMyCisJZXhpdCA7OworICAgICo6SW50ZXJpeCo6
KikKKwljYXNlICR7VU5BTUVfTUFDSElORX0gaW4KKwkgICAgeDg2KQorCQllY2hvIGk1ODYtcGMt
aW50ZXJpeCR7VU5BTUVfUkVMRUFTRX0KKwkJZXhpdCA7OworCSAgICBhdXRoZW50aWNhbWQgfCBn
ZW51aW5laW50ZWwgfCBFTTY0VCkKKwkJZWNobyB4ODZfNjQtdW5rbm93bi1pbnRlcml4JHtVTkFN
RV9SRUxFQVNFfQorCQlleGl0IDs7CisJICAgIElBNjQpCisJCWVjaG8gaWE2NC11bmtub3duLWlu
dGVyaXgke1VOQU1FX1JFTEVBU0V9CisJCWV4aXQgOzsKKwllc2FjIDs7CisgICAgWzM0NV04NjpX
aW5kb3dzXzk1OiogfCBbMzQ1XTg2OldpbmRvd3NfOTg6KiB8IFszNDVdODY6V2luZG93c19OVDoq
KQorCWVjaG8gaSR7VU5BTUVfTUFDSElORX0tcGMtbWtzCisJZXhpdCA7OworICAgIDg2NjQ6V2lu
ZG93c19OVDoqKQorCWVjaG8geDg2XzY0LXBjLW1rcworCWV4aXQgOzsKKyAgICBpKjpXaW5kb3dz
X05UKjoqIHwgUGVudGl1bSo6V2luZG93c19OVCo6KikKKwkjIEhvdyBkbyB3ZSBrbm93IGl0J3Mg
SW50ZXJpeCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyBQT1NJWCBzdWJzeXN0ZW0/CisJIyBJdCBh
bHNvIGNvbmZsaWN0cyB3aXRoIHByZS0yLjAgdmVyc2lvbnMgb2YgQVQmVCBVV0lOLiBTaG91bGQg
d2UKKwkjIFVOQU1FX01BQ0hJTkUgYmFzZWQgb24gdGhlIG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFk
IG9mIGkzODY/CisJZWNobyBpNTg2LXBjLWludGVyaXgKKwlleGl0IDs7CisgICAgaSo6VVdJTio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtdXdpbgorCWV4aXQgOzsKKyAgICBhbWQ2NDpD
WUdXSU4qOio6KiB8IHg4Nl82NDpDWUdXSU4qOio6KikKKwllY2hvIHg4Nl82NC11bmtub3duLWN5
Z3dpbgorCWV4aXQgOzsKKyAgICBwKjpDWUdXSU4qOiopCisJZWNobyBwb3dlcnBjbGUtdW5rbm93
bi1jeWd3aW4KKwlleGl0IDs7CisgICAgcHJlcCo6U3VuT1M6NS4qOiopCisJZWNobyBwb3dlcnBj
bGUtdW5rbm93bi1zb2xhcmlzMmBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0q
Ly8nYAorCWV4aXQgOzsKKyAgICAqOkdOVToqOiopCisJIyB0aGUgR05VIHN5c3RlbQorCWVjaG8g
YGVjaG8gJHtVTkFNRV9NQUNISU5FfXxzZWQgLWUgJ3MsWy0vXS4qJCwsJ2AtdW5rbm93bi1nbnVg
ZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncywvLiokLCwnYAorCWV4aXQgOzsKKyAgICAq
OkdOVS8qOio6KikKKwkjIG90aGVyIHN5c3RlbXMgd2l0aCBHTlUgbGliYyBhbmQgdXNlcmxhbmQK
KwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1gZWNobyAke1VOQU1FX1NZU1RFTX0gfCBz
ZWQgJ3MsXlteL10qLywsJyB8IHRyICdbQS1aXScgJ1thLXpdJ2BgZWNobyAke1VOQU1FX1JFTEVB
U0V9fHNlZCAtZSAncy9bLShdLiovLydgLWdudQorCWV4aXQgOzsKKyAgICBpKjg2Ok1pbml4Oio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbWluaXgKKwlleGl0IDs7CisgICAgYWxwaGE6
TGludXg6KjoqKQorCWNhc2UgYHNlZCAtbiAnL15jcHUgbW9kZWwvcy9eLio6IFwoLipcKS9cMS9w
JyA8IC9wcm9jL2NwdWluZm9gIGluCisJICBFVjUpICAgVU5BTUVfTUFDSElORT1hbHBoYWV2NSA7
OworCSAgRVY1NikgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjU2IDs7CisJICBQQ0E1NikgVU5BTUVf
TUFDSElORT1hbHBoYXBjYTU2IDs7CisJICBQQ0E1NykgVU5BTUVfTUFDSElORT1hbHBoYXBjYTU2
IDs7CisJICBFVjYpICAgVU5BTUVfTUFDSElORT1hbHBoYWV2NiA7OworCSAgRVY2NykgIFVOQU1F
X01BQ0hJTkU9YWxwaGFldjY3IDs7CisJICBFVjY4KikgVU5BTUVfTUFDSElORT1hbHBoYWV2Njgg
OzsKKwllc2FjCisJb2JqZHVtcCAtLXByaXZhdGUtaGVhZGVycyAvYmluL3NoIHwgZ3JlcCAtcSBs
ZC5zby4xCisJaWYgdGVzdCAiJD8iID0gMCA7IHRoZW4gTElCQz0ibGliYzEiIDsgZWxzZSBMSUJD
PSIiIDsgZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUke0xJQkN9
CisJZXhpdCA7OworICAgIGFybSo6TGludXg6KjoqKQorCWV2YWwgJHNldF9jY19mb3JfYnVpbGQK
KwlpZiBlY2hvIF9fQVJNX0VBQklfXyB8ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCBc
CisJICAgIHwgZ3JlcCAtcSBfX0FSTV9FQUJJX18KKwl0aGVuCisJICAgIGVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWVsc2UKKwkgICAgaWYgZWNobyBfX0FSTV9QQ1Nf
VkZQIHwgJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsIFwKKwkJfCBncmVwIC1xIF9fQVJN
X1BDU19WRlAKKwkgICAgdGhlbgorCQllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51
eC1nbnVlYWJpCisJICAgIGVsc2UKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGlu
dXgtZ251ZWFiaWhmCisJICAgIGZpCisJZmkKKwlleGl0IDs7CisgICAgYXZyMzIqOkxpbnV4Oio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7Cisg
ICAgY3JpczpMaW51eDoqOiopCisJZWNobyBjcmlzLWF4aXMtbGludXgtZ251CisJZXhpdCA7Owor
ICAgIGNyaXN2MzI6TGludXg6KjoqKQorCWVjaG8gY3Jpc3YzMi1heGlzLWxpbnV4LWdudQorCWV4
aXQgOzsKKyAgICBmcnY6TGludXg6KjoqKQorCWVjaG8gZnJ2LXVua25vd24tbGludXgtZ251CisJ
ZXhpdCA7OworICAgIGhleGFnb246TGludXg6KjoqKQorCWVjaG8gaGV4YWdvbi11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBpKjg2OkxpbnV4Oio6KikKKwlMSUJDPWdudQorCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworCSNpZmRl
ZiBfX2RpZXRsaWJjX18KKwlMSUJDPWRpZXRsaWJjCisJI2VuZGlmCitFT0YKKwlldmFsIGAkQ0Nf
Rk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxsIHwgZ3JlcCAnXkxJQkMnYAorCWVjaG8g
IiR7VU5BTUVfTUFDSElORX0tcGMtbGludXgtJHtMSUJDfSIKKwlleGl0IDs7CisgICAgaWE2NDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhp
dCA7OworICAgIG0zMnIqOkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgbTY4KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIG1pcHM6TGludXg6Kjoq
IHwgbWlwczY0OkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14J
Ly8nIDw8IEVPRiA+JGR1bW15LmMKKwkjdW5kZWYgQ1BVCisJI3VuZGVmICR7VU5BTUVfTUFDSElO
RX0KKwkjdW5kZWYgJHtVTkFNRV9NQUNISU5FfWVsCisJI2lmIGRlZmluZWQoX19NSVBTRUxfXykg
fHwgZGVmaW5lZChfX01JUFNFTCkgfHwgZGVmaW5lZChfTUlQU0VMKSB8fCBkZWZpbmVkKE1JUFNF
TCkKKwlDUFU9JHtVTkFNRV9NQUNISU5FfWVsCisJI2Vsc2UKKwkjaWYgZGVmaW5lZChfX01JUFNF
Ql9fKSB8fCBkZWZpbmVkKF9fTUlQU0VCKSB8fCBkZWZpbmVkKF9NSVBTRUIpIHx8IGRlZmluZWQo
TUlQU0VCKQorCUNQVT0ke1VOQU1FX01BQ0hJTkV9CisJI2Vsc2UKKwlDUFU9CisJI2VuZGlmCisJ
I2VuZGlmCitFT0YKKwlldmFsIGAkQ0NfRk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxs
IHwgZ3JlcCAnXkNQVSdgCisJdGVzdCB4IiR7Q1BVfSIgIT0geCAmJiB7IGVjaG8gIiR7Q1BVfS11
bmtub3duLWxpbnV4LWdudSI7IGV4aXQ7IH0KKwk7OworICAgIG9yMzI6TGludXg6KjoqKQorCWVj
aG8gb3IzMi11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYWRyZTpMaW51eDoqOiop
CisJZWNobyBzcGFyYy11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYXJpc2M2NDpM
aW51eDoqOiogfCBocHBhNjQ6TGludXg6KjoqKQorCWVjaG8gaHBwYTY0LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHBhcmlzYzpMaW51eDoqOiogfCBocHBhOkxpbnV4Oio6KikKKwkj
IExvb2sgZm9yIENQVSBsZXZlbAorCWNhc2UgYGdyZXAgJ15jcHVbXmEtel0qOicgL3Byb2MvY3B1
aW5mbyAyPi9kZXYvbnVsbCB8IGN1dCAtZCcgJyAtZjJgIGluCisJICBQQTcqKSBlY2hvIGhwcGEx
LjEtdW5rbm93bi1saW51eC1nbnUgOzsKKwkgIFBBOCopIGVjaG8gaHBwYTIuMC11bmtub3duLWxp
bnV4LWdudSA7OworCSAgKikgICAgZWNobyBocHBhLXVua25vd24tbGludXgtZ251IDs7CisJZXNh
YworCWV4aXQgOzsKKyAgICBwcGM2NDpMaW51eDoqOiopCisJZWNobyBwb3dlcnBjNjQtdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgcHBjOkxpbnV4Oio6KikKKwllY2hvIHBvd2VycGMt
dW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgczM5MDpMaW51eDoqOiogfCBzMzkweDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LWlibS1saW51eAorCWV4aXQgOzsKKyAg
ICBzaDY0KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHNoKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9
LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHNwYXJjOkxpbnV4Oio6KiB8IHNwYXJj
NjQ6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQor
CWV4aXQgOzsKKyAgICB0aWxlKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHZheDpMaW51eDoqOiopCisJZWNobyAke1VO
QU1FX01BQ0hJTkV9LWRlYy1saW51eC1nbnUKKwlleGl0IDs7CisgICAgeDg2XzY0OkxpbnV4Oio6
KikKKwllY2hvIHg4Nl82NC11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB4dGVuc2Eq
OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwll
eGl0IDs7CisgICAgaSo4NjpEWU5JWC9wdHg6NCo6KikKKwkjIHB0eCA0LjAgZG9lcyB1bmFtZSAt
cyBjb3JyZWN0bHksIHdpdGggRFlOSVgvcHR4IGluIHRoZXJlLgorCSMgZWFybGllciB2ZXJzaW9u
cyBhcmUgbWVzc2VkIHVwIGFuZCBwdXQgdGhlIG5vZGVuYW1lIGluIGJvdGgKKwkjIHN5c25hbWUg
YW5kIG5vZGVuYW1lLgorCWVjaG8gaTM4Ni1zZXF1ZW50LXN5c3Y0CisJZXhpdCA7OworICAgIGkq
ODY6VU5JWF9TVjo0LjJNUDoyLiopCisJIyBVbml4d2FyZSBpcyBhbiBvZmZzaG9vdCBvZiBTVlI0
LCBidXQgaXQgaGFzIGl0cyBvd24gdmVyc2lvbgorCSMgbnVtYmVyIHNlcmllcyBzdGFydGluZyB3
aXRoIDIuLi4KKwkjIEkgYW0gbm90IHBvc2l0aXZlIHRoYXQgb3RoZXIgU1ZSNCBzeXN0ZW1zIHdv
bid0IG1hdGNoIHRoaXMsCisJIyBJIGp1c3QgaGF2ZSB0byBob3BlLiAgLS0gcm1zLgorCSMgVXNl
IHN5c3Y0LjJ1dy4uLiBzbyB0aGF0IHN5c3Y0KiBtYXRjaGVzIGl0LgorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1wYy1zeXN2NC4ydXcke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6
T1MvMjoqOiopCisJIyBJZiB3ZSB3ZXJlIGFibGUgdG8gZmluZCBgdW5hbWUnLCB0aGVuIEVNWCBV
bml4IGNvbXBhdGliaWxpdHkKKwkjIGlzIHByb2JhYmx5IGluc3RhbGxlZC4KKwllY2hvICR7VU5B
TUVfTUFDSElORX0tcGMtb3MyLWVteAorCWV4aXQgOzsKKyAgICBpKjg2OlhUUy0zMDA6KjpTVE9Q
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXN0b3AKKwlleGl0IDs7CisgICAgaSo4
NjphdGhlb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWF0aGVvcworCWV4
aXQgOzsKKyAgICBpKjg2OnN5bGxhYmxlOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMt
c3lsbGFibGUKKwlleGl0IDs7CisgICAgaSo4NjpMeW54T1M6Mi4qOiogfCBpKjg2Okx5bnhPUzoz
LlswMV0qOiogfCBpKjg2Okx5bnhPUzo0LlswMl0qOiopCisJZWNobyBpMzg2LXVua25vd24tbHlu
eG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBpKjg2OipET1M6KjoqKQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1wYy1tc2Rvc2RqZ3BwCisJZXhpdCA7OworICAgIGkqODY6Kjo0Lio6
KiB8IGkqODY6U1lTVEVNX1Y6NC4qOiopCisJVU5BTUVfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFT
RX0gfCBzZWQgJ3MvXC9NUCQvLydgCisJaWYgZ3JlcCBOb3ZlbGwgL3Vzci9pbmNsdWRlL2xpbmsu
aCA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11
bml2ZWwtc3lzdiR7VU5BTUVfUkVMfQorCWVsc2UKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBj
LXN5c3Yke1VOQU1FX1JFTH0KKwlmaQorCWV4aXQgOzsKKyAgICBpKjg2Oio6NTpbNjc4XSopCisJ
IyBVbml4V2FyZSA3LngsIE9wZW5VTklYIGFuZCBPcGVuU2VydmVyIDYuCisJY2FzZSBgL2Jpbi91
bmFtZSAtWCB8IGdyZXAgIl5NYWNoaW5lImAgaW4KKwkgICAgKjQ4NiopCSAgICAgVU5BTUVfTUFD
SElORT1pNDg2IDs7CisJICAgICpQZW50aXVtKQkgICAgIFVOQU1FX01BQ0hJTkU9aTU4NiA7Owor
CSAgICAqUGVudCp8KkNlbGVyb24pIFVOQU1FX01BQ0hJTkU9aTY4NiA7OworCWVzYWMKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zeXN2JHtVTkFNRV9SRUxFQVNFfSR7VU5BTUVfU1lT
VEVNfSR7VU5BTUVfVkVSU0lPTn0KKwlleGl0IDs7CisgICAgaSo4NjoqOjMuMjoqKQorCWlmIHRl
c3QgLWYgL3Vzci9vcHRpb25zL2NiLm5hbWU7IHRoZW4KKwkJVU5BTUVfUkVMPWBzZWQgLW4gJ3Mv
LipWZXJzaW9uIC8vcCcgPC91c3Ivb3B0aW9ucy9jYi5uYW1lYAorCQllY2hvICR7VU5BTUVfTUFD
SElORX0tcGMtaXNjJFVOQU1FX1JFTAorCWVsaWYgL2Jpbi91bmFtZSAtWCAyPi9kZXYvbnVsbCA+
L2Rldi9udWxsIDsgdGhlbgorCQlVTkFNRV9SRUw9YCgvYmluL3VuYW1lIC1YfGdyZXAgUmVsZWFz
ZXxzZWQgLWUgJ3MvLio9IC8vJylgCisJCSgvYmluL3VuYW1lIC1YfGdyZXAgaTgwNDg2ID4vZGV2
L251bGwpICYmIFVOQU1FX01BQ0hJTkU9aTQ4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFj
aGluZS4qUGVudGl1bScgPi9kZXYvbnVsbCkgXAorCQkJJiYgVU5BTUVfTUFDSElORT1pNTg2CisJ
CSgvYmluL3VuYW1lIC1YfGdyZXAgJ15NYWNoaW5lLipQZW50ICpJSScgPi9kZXYvbnVsbCkgXAor
CQkJJiYgVU5BTUVfTUFDSElORT1pNjg2CisJCSgvYmluL3VuYW1lIC1YfGdyZXAgJ15NYWNoaW5l
LipQZW50aXVtIFBybycgPi9kZXYvbnVsbCkgXAorCQkJJiYgVU5BTUVfTUFDSElORT1pNjg2CisJ
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1zY28kVU5BTUVfUkVMCisJZWxzZQorCQllY2hvICR7
VU5BTUVfTUFDSElORX0tcGMtc3lzdjMyCisJZmkKKwlleGl0IDs7CisgICAgcGM6KjoqOiopCisJ
IyBMZWZ0IGhlcmUgZm9yIGNvbXBhdGliaWxpdHk6CisJIyB1bmFtZSAtbSBwcmludHMgZm9yIERK
R1BQIGFsd2F5cyAncGMnLCBidXQgaXQgcHJpbnRzIG5vdGhpbmcgYWJvdXQKKwkjIHRoZSBwcm9j
ZXNzb3IsIHNvIHdlIHBsYXkgc2FmZSBieSBhc3N1bWluZyBpNTg2LgorCSMgTm90ZTogd2hhdGV2
ZXIgdGhpcyBpcywgaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB3aGF0IGNvbmZpZy5zdWIKKwkjIHBy
aW50cyBmb3IgdGhlICJkamdwcCIgaG9zdCwgb3IgZWxzZSBHREIgY29uZmlndXJ5IHdpbGwgZGVj
aWRlIHRoYXQKKwkjIHRoaXMgaXMgYSBjcm9zcy1idWlsZC4KKwllY2hvIGk1ODYtcGMtbXNkb3Nk
amdwcAorCWV4aXQgOzsKKyAgICBJbnRlbDpNYWNoOjMqOiopCisJZWNobyBpMzg2LXBjLW1hY2gz
CisJZXhpdCA7OworICAgIHBhcmFnb246KjoqOiopCisJZWNobyBpODYwLWludGVsLW9zZjEKKwll
eGl0IDs7CisgICAgaTg2MDoqOjQuKjoqKSAjIGk4NjAtU1ZSNAorCWlmIGdyZXAgU3RhcmRlbnQg
L3Vzci9pbmNsdWRlL3N5cy91YWRtaW4uaCA+L2Rldi9udWxsIDI+JjEgOyB0aGVuCisJICBlY2hv
IGk4NjAtc3RhcmRlbnQtc3lzdiR7VU5BTUVfUkVMRUFTRX0gIyBTdGFyZGVudCBWaXN0cmEgaTg2
MC1TVlI0CisJZWxzZSAjIEFkZCBvdGhlciBpODYwLVNWUjQgdmVuZG9ycyBiZWxvdyBhcyB0aGV5
IGFyZSBkaXNjb3ZlcmVkLgorCSAgZWNobyBpODYwLXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFT
RX0gICMgVW5rbm93biBpODYwLVNWUjQKKwlmaQorCWV4aXQgOzsKKyAgICBtaW5pKjpDVElYOlNZ
Uyo1OiopCisJIyAibWluaWZyYW1lIgorCWVjaG8gbTY4MDEwLWNvbnZlcmdlbnQtc3lzdgorCWV4
aXQgOzsKKyAgICBtYzY4azpVTklYOlNZU1RFTTU6My41MW0pCisJZWNobyBtNjhrLWNvbnZlcmdl
bnQtc3lzdgorCWV4aXQgOzsKKyAgICBNNjgwPzA6RC1OSVg6NS4zOiopCisJZWNobyBtNjhrLWRp
YWItZG5peAorCWV4aXQgOzsKKyAgICBNNjgqOio6UjNWWzU2NzhdKjoqKQorCXRlc3QgLXIgL3N5
c1Y2OCAmJiB7IGVjaG8gJ202OGstbW90b3JvbGEtc3lzdic7IGV4aXQ7IH0gOzsKKyAgICAzWzM0
NV0/PzoqOjQuMDozLjAgfCAzWzM0XT8/QToqOjQuMDozLjAgfCAzWzM0XT8/LCo6Kjo0LjA6My4w
IHwgM1szNF0/Py8qOio6NC4wOjMuMCB8IDQ0MDA6Kjo0LjA6My4wIHwgNDg1MDoqOjQuMDozLjAg
fCBTS0E0MDoqOjQuMDozLjAgfCBTRFMyOio6NC4wOjMuMCB8IFNIRzI6Kjo0LjA6My4wIHwgUzc1
MDEqOio6NC4wOjMuMCkKKwlPU19SRUw9JycKKwl0ZXN0IC1yIC9ldGMvLnJlbGlkIFwKKwkmJiBP
U19SRUw9LmBzZWQgLW4gJ3MvW14gXSogW14gXSogXChbMC05XVswLTldXCkuKi9cMS9wJyA8IC9l
dGMvLnJlbGlkYAorCS9iaW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCBncmVwIDg2ID4vZGV2L251
bGwgXAorCSAgJiYgeyBlY2hvIGk0ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkv
YmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIGVudGl1bSA+L2Rldi9udWxsIFwK
KwkgICYmIHsgZWNobyBpNTg2LW5jci1zeXN2NC4zJHtPU19SRUx9OyBleGl0OyB9IDs7CisgICAg
M1szNF0/PzoqOjQuMDoqIHwgM1szNF0/PywqOio6NC4wOiopCisJL2Jpbi91bmFtZSAtcCAyPi9k
ZXYvbnVsbCB8IGdyZXAgODYgPi9kZXYvbnVsbCBcCisJICAmJiB7IGVjaG8gaTQ4Ni1uY3Itc3lz
djQ7IGV4aXQ7IH0gOzsKKyAgICBOQ1IqOio6NC4yOiogfCBNUFJBUyo6Kjo0LjI6KikKKwlPU19S
RUw9Jy4zJworCXRlc3QgLXIgL2V0Yy8ucmVsaWQgXAorCSAgICAmJiBPU19SRUw9LmBzZWQgLW4g
J3MvW14gXSogW14gXSogXChbMC05XVswLTldXCkuKi9cMS9wJyA8IC9ldGMvLnJlbGlkYAorCS9i
aW4vdW5hbWUgLXAgMj4vZGV2L251bGwgfCBncmVwIDg2ID4vZGV2L251bGwgXAorCSAgICAmJiB7
IGVjaG8gaTQ4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAg
Mj4vZGV2L251bGwgfCAvYmluL2dyZXAgZW50aXVtID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVj
aG8gaTU4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAgMj4v
ZGV2L251bGwgfCAvYmluL2dyZXAgcHRlcm9uID4vZGV2L251bGwgXAorCSAgICAmJiB7IGVjaG8g
aTU4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfSA7OworICAgIG02OCo6THlueE9TOjIu
KjoqIHwgbTY4KjpMeW54T1M6My4wKjoqKQorCWVjaG8gbTY4ay11bmtub3duLWx5bnhvcyR7VU5B
TUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgbWM2ODAzMDpVTklYX1N5c3RlbV9WOjQuKjoqKQor
CWVjaG8gbTY4ay1hdGFyaS1zeXN2NAorCWV4aXQgOzsKKyAgICBUU1VOQU1JOkx5bnhPUzoyLio6
KikKKwllY2hvIHNwYXJjLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsK
KyAgICByczYwMDA6THlueE9TOjIuKjoqKQorCWVjaG8gcnM2MDAwLXVua25vd24tbHlueG9zJHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBQb3dlclBDOkx5bnhPUzoyLio6KiB8IFBvd2Vy
UEM6THlueE9TOjMuWzAxXSo6KiB8IFBvd2VyUEM6THlueE9TOjQuWzAyXSo6KikKKwllY2hvIHBv
d2VycGMtdW5rbm93bi1seW54b3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFNNW0JF
XVM6VU5JWF9TVjoqOiopCisJZWNobyBtaXBzLWRkZS1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICBSTSo6UmVsaWFudFVOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAor
CWV4aXQgOzsKKyAgICBSTSo6U0lOSVgtKjoqOiopCisJZWNobyBtaXBzLXNuaS1zeXN2NAorCWV4
aXQgOzsKKyAgICAqOlNJTklYLSo6KjoqKQorCWlmIHVuYW1lIC1wIDI+L2Rldi9udWxsID4vZGV2
L251bGwgOyB0aGVuCisJCVVOQU1FX01BQ0hJTkU9YCh1bmFtZSAtcCkgMj4vZGV2L251bGxgCisJ
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1zbmktc3lzdjQKKwllbHNlCisJCWVjaG8gbnMzMmstc25p
LXN5c3YKKwlmaQorCWV4aXQgOzsKKyAgICBQRU5USVVNOio6NC4wKjoqKQkjIFVuaXN5cyBgQ2xl
YXJQYXRoIEhNUCBJWCA0MDAwJyBTVlI0L01QIGVmZm9ydAorCQkJIyBzYXlzIDxSaWNoYXJkLk0u
QmFydGVsQGNjTWFpbC5DZW5zdXMuR09WPgorCWVjaG8gaTU4Ni11bmlzeXMtc3lzdjQKKwlleGl0
IDs7CisgICAgKjpVTklYX1N5c3RlbV9WOjQqOkZUWCopCisJIyBGcm9tIEdlcmFsZCBIZXdlcyA8
aGV3ZXNAb3Blbm1hcmtldC5jb20+LgorCSMgSG93IGFib3V0IGRpZmZlcmVudGlhdGluZyBiZXR3
ZWVuIHN0cmF0dXMgYXJjaGl0ZWN0dXJlcz8gLWRqbQorCWVjaG8gaHBwYTEuMS1zdHJhdHVzLXN5
c3Y0CisJZXhpdCA7OworICAgICo6KjoqOkZUWCopCisJIyBGcm9tIHNlYW5mQHN3ZGMuc3RyYXR1
cy5jb20uCisJZWNobyBpODYwLXN0cmF0dXMtc3lzdjQKKwlleGl0IDs7CisgICAgaSo4NjpWT1M6
KjoqKQorCSMgRnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS1zdHJhdHVzLXZvcworCWV4aXQgOzsKKyAgICAqOlZPUzoqOiopCisJIyBGcm9tIFBhdWwu
R3JlZW5Ac3RyYXR1cy5jb20uCisJZWNobyBocHBhMS4xLXN0cmF0dXMtdm9zCisJZXhpdCA7Owor
ICAgIG1jNjgqOkEvVVg6KjoqKQorCWVjaG8gbTY4ay1hcHBsZS1hdXgke1VOQU1FX1JFTEVBU0V9
CisJZXhpdCA7OworICAgIG5ld3MqOk5FV1MtT1M6Nio6KikKKwllY2hvIG1pcHMtc29ueS1uZXdz
b3M2CisJZXhpdCA7OworICAgIFJbMzRdMDAwOipTeXN0ZW1fVio6KjoqIHwgUjQwMDA6VU5JWF9T
WVNWOio6KiB8IFIqMDAwOlVOSVhfU1Y6KjoqKQorCWlmIFsgLWQgL3Vzci9uZWMgXTsgdGhlbgor
CQllY2hvIG1pcHMtbmVjLXN5c3Yke1VOQU1FX1JFTEVBU0V9CisJZWxzZQorCQllY2hvIG1pcHMt
dW5rbm93bi1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWZpCisJZXhpdCA7OworICAgIEJlQm94OkJl
T1M6KjoqKQkjIEJlT1MgcnVubmluZyBvbiBoYXJkd2FyZSBtYWRlIGJ5IEJlLCBQUEMgb25seS4K
KwllY2hvIHBvd2VycGMtYmUtYmVvcworCWV4aXQgOzsKKyAgICBCZU1hYzpCZU9TOio6KikJIyBC
ZU9TIHJ1bm5pbmcgb24gTWFjIG9yIE1hYyBjbG9uZSwgUFBDIG9ubHkuCisJZWNobyBwb3dlcnBj
LWFwcGxlLWJlb3MKKwlleGl0IDs7CisgICAgQmVQQzpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcg
b24gSW50ZWwgUEMgY29tcGF0aWJsZS4KKwllY2hvIGk1ODYtcGMtYmVvcworCWV4aXQgOzsKKyAg
ICBCZVBDOkhhaWt1Oio6KikJIyBIYWlrdSBydW5uaW5nIG9uIEludGVsIFBDIGNvbXBhdGlibGUu
CisJZWNobyBpNTg2LXBjLWhhaWt1CisJZXhpdCA7OworICAgIFNYLTQ6U1VQRVItVVg6KjoqKQor
CWVjaG8gc3g0LW5lYy1zdXBlcnV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC01
OlNVUEVSLVVYOio6KikKKwllY2hvIHN4NS1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgU1gtNjpTVVBFUi1VWDoqOiopCisJZWNobyBzeDYtbmVjLXN1cGVydXgke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFNYLTc6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g3
LW5lYy1zdXBlcnV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC04OlNVUEVSLVVY
Oio6KikKKwllY2hvIHN4OC1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7Cisg
ICAgU1gtOFI6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g4ci1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgUG93ZXIqOlJoYXBzb2R5Oio6KikKKwllY2hvIHBvd2VycGMt
YXBwbGUtcmhhcHNvZHkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6UmhhcHNvZHk6
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1hcHBsZS1yaGFwc29keSR7VU5BTUVfUkVMRUFT
RX0KKwlleGl0IDs7CisgICAgKjpEYXJ3aW46KjoqKQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUg
LXBgIHx8IFVOQU1FX1BST0NFU1NPUj11bmtub3duCisJY2FzZSAkVU5BTUVfUFJPQ0VTU09SIGlu
CisJICAgIGkzODYpCisJCWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJaWYgWyAiJENDX0ZPUl9C
VUlMRCIgIT0gJ25vX2NvbXBpbGVyX2ZvdW5kJyBdOyB0aGVuCisJCSAgaWYgKGVjaG8gJyNpZmRl
ZiBfX0xQNjRfXyc7IGVjaG8gSVNfNjRCSVRfQVJDSDsgZWNobyAnI2VuZGlmJykgfCBcCisJCSAg
ICAgIChDQ09QVFM9ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCkgfCBcCisJCSAgICAg
IGdyZXAgSVNfNjRCSVRfQVJDSCA+L2Rldi9udWxsCisJCSAgdGhlbgorCQkgICAgICBVTkFNRV9Q
Uk9DRVNTT1I9Ing4Nl82NCIKKwkJICBmaQorCQlmaSA7OworCSAgICB1bmtub3duKSBVTkFNRV9Q
Uk9DRVNTT1I9cG93ZXJwYyA7OworCWVzYWMKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS1hcHBs
ZS1kYXJ3aW4ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6cHJvY250byo6KjoqIHwg
KjpRTlg6WzAxMjM0NTY3ODldKjoqKQorCVVOQU1FX1BST0NFU1NPUj1gdW5hbWUgLXBgCisJaWYg
dGVzdCAiJFVOQU1FX1BST0NFU1NPUiIgPSAieDg2IjsgdGhlbgorCQlVTkFNRV9QUk9DRVNTT1I9
aTM4NgorCQlVTkFNRV9NQUNISU5FPXBjCisJZmkKKwllY2hvICR7VU5BTUVfUFJPQ0VTU09SfS0k
e1VOQU1FX01BQ0hJTkV9LW50by1xbngke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6
UU5YOio6NCopCisJZWNobyBpMzg2LXBjLXFueAorCWV4aXQgOzsKKyAgICBORU8tPzpOT05TVE9Q
X0tFUk5FTDoqOiopCisJZWNobyBuZW8tdGFuZGVtLW5zayR7VU5BTUVfUkVMRUFTRX0KKwlleGl0
IDs7CisgICAgTlNFLT86Tk9OU1RPUF9LRVJORUw6KjoqKQorCWVjaG8gbnNlLXRhbmRlbS1uc2sk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIE5TUi0/Ok5PTlNUT1BfS0VSTkVMOio6KikK
KwllY2hvIG5zci10YW5kZW0tbnNrJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOk5v
blN0b3AtVVg6KjoqKQorCWVjaG8gbWlwcy1jb21wYXEtbm9uc3RvcHV4CisJZXhpdCA7OworICAg
IEJTMjAwMDpQT1NJWCo6KjoqKQorCWVjaG8gYnMyMDAwLXNpZW1lbnMtc3lzdgorCWV4aXQgOzsK
KyAgICBEUy8qOlVOSVhfU3lzdGVtX1Y6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS0ke1VO
QU1FX1NZU1RFTX0tJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlBsYW45Oio6KikK
KwkjICJ1bmFtZSAtbSIgaXMgbm90IGNvbnNpc3RlbnQsIHNvIHVzZSAkY3B1dHlwZSBpbnN0ZWFk
LiAzODYKKwkjIGlzIGNvbnZlcnRlZCB0byBpMzg2IGZvciBjb25zaXN0ZW5jeSB3aXRoIG90aGVy
IHg4NgorCSMgb3BlcmF0aW5nIHN5c3RlbXMuCisJaWYgdGVzdCAiJGNwdXR5cGUiID0gIjM4NiI7
IHRoZW4KKwkgICAgVU5BTUVfTUFDSElORT1pMzg2CisJZWxzZQorCSAgICBVTkFNRV9NQUNISU5F
PSIkY3B1dHlwZSIKKwlmaQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXBsYW45CisJ
ZXhpdCA7OworICAgICo6VE9QUy0xMDoqOiopCisJZWNobyBwZHAxMC11bmtub3duLXRvcHMxMAor
CWV4aXQgOzsKKyAgICAqOlRFTkVYOio6KikKKwllY2hvIHBkcDEwLXVua25vd24tdGVuZXgKKwll
eGl0IDs7CisgICAgS1MxMDpUT1BTLTIwOio6KiB8IEtMMTA6VE9QUy0yMDoqOiogfCBUWVBFNDpU
T1BTLTIwOio6KikKKwllY2hvIHBkcDEwLWRlYy10b3BzMjAKKwlleGl0IDs7CisgICAgWEtMLTE6
VE9QUy0yMDoqOiogfCBUWVBFNTpUT1BTLTIwOio6KikKKwllY2hvIHBkcDEwLXhrbC10b3BzMjAK
KwlleGl0IDs7CisgICAgKjpUT1BTLTIwOio6KikKKwllY2hvIHBkcDEwLXVua25vd24tdG9wczIw
CisJZXhpdCA7OworICAgICo6SVRTOio6KikKKwllY2hvIHBkcDEwLXVua25vd24taXRzCisJZXhp
dCA7OworICAgIFNFSToqOio6U0VJVVgpCisJZWNobyBtaXBzLXNlaS1zZWl1eCR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgKjpEcmFnb25GbHk6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS11bmtub3duLWRyYWdvbmZseWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1st
KF0uKi8vJ2AKKwlleGl0IDs7CisgICAgKjoqVk1TOio6KikKKwlVTkFNRV9NQUNISU5FPWAodW5h
bWUgLXApIDI+L2Rldi9udWxsYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORX0iIGluCisJICAgIEEq
KSBlY2hvIGFscGhhLWRlYy12bXMgOyBleGl0IDs7CisJICAgIEkqKSBlY2hvIGlhNjQtZGVjLXZt
cyA7IGV4aXQgOzsKKwkgICAgViopIGVjaG8gdmF4LWRlYy12bXMgOyBleGl0IDs7CisJZXNhYyA7
OworICAgICo6WEVOSVg6KjpTeXNWKQorCWVjaG8gaTM4Ni1wYy14ZW5peAorCWV4aXQgOzsKKyAg
ICBpKjg2OnNreW9zOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc2t5b3NgZWNobyAk
e1VOQU1FX1JFTEVBU0V9YCB8IHNlZCAtZSAncy8gLiokLy8nCisJZXhpdCA7OworICAgIGkqODY6
cmRvczoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXJkb3MKKwlleGl0IDs7CisgICAg
aSo4NjpBUk9TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtYXJvcworCWV4aXQgOzsK
K2VzYWMKKworI2VjaG8gJyhObyB1bmFtZSBjb21tYW5kIG9yIHVuYW1lIG91dHB1dCBub3QgcmVj
b2duaXplZC4pJyAxPiYyCisjZWNobyAiJHtVTkFNRV9NQUNISU5FfToke1VOQU1FX1NZU1RFTX06
JHtVTkFNRV9SRUxFQVNFfToke1VOQU1FX1ZFUlNJT059IiAxPiYyCisKK2V2YWwgJHNldF9jY19m
b3JfYnVpbGQKK2NhdCA+JGR1bW15LmMgPDxFT0YKKyNpZmRlZiBfU0VRVUVOVF8KKyMgaW5jbHVk
ZSA8c3lzL3R5cGVzLmg+CisjIGluY2x1ZGUgPHN5cy91dHNuYW1lLmg+CisjZW5kaWYKK21haW4g
KCkKK3sKKyNpZiBkZWZpbmVkIChzb255KQorI2lmIGRlZmluZWQgKE1JUFNFQikKKyAgLyogQkZE
IHdhbnRzICJic2QiIGluc3RlYWQgb2YgIm5ld3NvcyIuICBQZXJoYXBzIEJGRCBzaG91bGQgYmUg
Y2hhbmdlZCwKKyAgICAgSSBkb24ndCBrbm93Li4uLiAgKi8KKyAgcHJpbnRmICgibWlwcy1zb255
LWJzZFxuIik7IGV4aXQgKDApOworI2Vsc2UKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyAgcHJp
bnRmICgibTY4ay1zb255LW5ld3NvcyVzXG4iLAorI2lmZGVmIE5FV1NPUzQKKwkiNCIKKyNlbHNl
CisJIiIKKyNlbmRpZgorCSk7IGV4aXQgKDApOworI2VuZGlmCisjZW5kaWYKKworI2lmIGRlZmlu
ZWQgKF9fYXJtKSAmJiBkZWZpbmVkIChfX2Fjb3JuKSAmJiBkZWZpbmVkIChfX3VuaXgpCisgIHBy
aW50ZiAoImFybS1hY29ybi1yaXNjaXhcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVm
aW5lZCAoaHAzMDApICYmICFkZWZpbmVkIChocHV4KQorICBwcmludGYgKCJtNjhrLWhwLWJzZFxu
Iik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBkZWZpbmVkIChOZVhUKQorI2lmICFkZWZpbmVk
IChfX0FSQ0hJVEVDVFVSRV9fKQorI2RlZmluZSBfX0FSQ0hJVEVDVFVSRV9fICJtNjhrIgorI2Vu
ZGlmCisgIGludCB2ZXJzaW9uOworICB2ZXJzaW9uPWAoaG9zdGluZm8gfCBzZWQgLW4gJ3MvLipO
ZVhUIE1hY2ggXChbMC05XSpcKS4qL1wxL3AnKSAyPi9kZXYvbnVsbGA7CisgIGlmICh2ZXJzaW9u
IDwgNCkKKyAgICBwcmludGYgKCIlcy1uZXh0LW5leHRzdGVwJWRcbiIsIF9fQVJDSElURUNUVVJF
X18sIHZlcnNpb24pOworICBlbHNlCisgICAgcHJpbnRmICgiJXMtbmV4dC1vcGVuc3RlcCVkXG4i
LCBfX0FSQ0hJVEVDVFVSRV9fLCB2ZXJzaW9uKTsKKyAgZXhpdCAoMCk7CisjZW5kaWYKKworI2lm
IGRlZmluZWQgKE1VTFRJTUFYKSB8fCBkZWZpbmVkIChuMTYpCisjaWYgZGVmaW5lZCAoVU1BWFYp
CisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1zeXN2XG4iKTsgZXhpdCAoMCk7CisjZWxzZQorI2lm
IGRlZmluZWQgKENNVSkKKyAgcHJpbnRmICgibnMzMmstZW5jb3JlLW1hY2hcbiIpOyBleGl0ICgw
KTsKKyNlbHNlCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1ic2RcbiIpOyBleGl0ICgwKTsKKyNl
bmRpZgorI2VuZGlmCisjZW5kaWYKKworI2lmIGRlZmluZWQgKF9fMzg2QlNEX18pCisgIHByaW50
ZiAoImkzODYtcGMtYnNkXG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKworI2lmIGRlZmluZWQgKHNl
cXVlbnQpCisjaWYgZGVmaW5lZCAoaTM4NikKKyAgcHJpbnRmICgiaTM4Ni1zZXF1ZW50LWR5bml4
XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNpZiBkZWZpbmVkIChuczMyMDAwKQorICBwcmludGYg
KCJuczMyay1zZXF1ZW50LWR5bml4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNlbmRpZgorCisj
aWYgZGVmaW5lZCAoX1NFUVVFTlRfKQorICAgIHN0cnVjdCB1dHNuYW1lIHVuOworCisgICAgdW5h
bWUoJnVuKTsKKworICAgIGlmIChzdHJuY21wKHVuLnZlcnNpb24sICJWMiIsIDIpID09IDApIHsK
KwlwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4MlxuIik7IGV4aXQgKDApOworICAgIH0KKyAgICBp
ZiAoc3RybmNtcCh1bi52ZXJzaW9uLCAiVjEiLCAyKSA9PSAwKSB7IC8qIFhYWCBpcyBWMSBjb3Jy
ZWN0PyAqLworCXByaW50ZiAoImkzODYtc2VxdWVudC1wdHgxXG4iKTsgZXhpdCAoMCk7CisgICAg
fQorICAgIHByaW50ZiAoImkzODYtc2VxdWVudC1wdHhcbiIpOyBleGl0ICgwKTsKKworI2VuZGlm
CisKKyNpZiBkZWZpbmVkICh2YXgpCisjIGlmICFkZWZpbmVkICh1bHRyaXgpCisjICBpbmNsdWRl
IDxzeXMvcGFyYW0uaD4KKyMgIGlmIGRlZmluZWQgKEJTRCkKKyMgICBpZiBCU0QgPT0gNDMKKyAg
ICAgIHByaW50ZiAoInZheC1kZWMtYnNkNC4zXG4iKTsgZXhpdCAoMCk7CisjICAgZWxzZQorIyAg
ICBpZiBCU0QgPT0gMTk5MDA2CisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZDQuM3Jlbm9cbiIp
OyBleGl0ICgwKTsKKyMgICAgZWxzZQorICAgICAgcHJpbnRmICgidmF4LWRlYy1ic2RcbiIpOyBl
eGl0ICgwKTsKKyMgICAgZW5kaWYKKyMgICBlbmRpZgorIyAgZWxzZQorICAgIHByaW50ZiAoInZh
eC1kZWMtYnNkXG4iKTsgZXhpdCAoMCk7CisjICBlbmRpZgorIyBlbHNlCisgICAgcHJpbnRmICgi
dmF4LWRlYy11bHRyaXhcbiIpOyBleGl0ICgwKTsKKyMgZW5kaWYKKyNlbmRpZgorCisjaWYgZGVm
aW5lZCAoYWxsaWFudCkgJiYgZGVmaW5lZCAoaTg2MCkKKyAgcHJpbnRmICgiaTg2MC1hbGxpYW50
LWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyAgZXhpdCAoMSk7Cit9CitFT0YKKworJEND
X0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgMj4vZGV2L251bGwgJiYgU1lTVEVNX05BTUU9
YCRkdW1teWAgJiYKKwl7IGVjaG8gIiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKworIyBBcG9sbG9z
IHB1dCB0aGUgc3lzdGVtIHR5cGUgaW4gdGhlIGVudmlyb25tZW50LgorCit0ZXN0IC1kIC91c3Iv
YXBvbGxvICYmIHsgZWNobyAke0lTUH0tYXBvbGxvLSR7U1lTVFlQRX07IGV4aXQ7IH0KKworIyBD
b252ZXggdmVyc2lvbnMgdGhhdCBwcmVkYXRlIHVuYW1lIGNhbiB1c2UgZ2V0c3lzaW5mbygxKQor
CitpZiBbIC14IC91c3IvY29udmV4L2dldHN5c2luZm8gXQordGhlbgorICAgIGNhc2UgYGdldHN5
c2luZm8gLWYgY3B1X3R5cGVgIGluCisgICAgYzEqKQorCWVjaG8gYzEtY29udmV4LWJzZAorCWV4
aXQgOzsKKyAgICBjMiopCisJaWYgZ2V0c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhlbiBlY2hv
IGMzMi1jb252ZXgtYnNkCisJZWxzZSBlY2hvIGMyLWNvbnZleC1ic2QKKwlmaQorCWV4aXQgOzsK
KyAgICBjMzQqKQorCWVjaG8gYzM0LWNvbnZleC1ic2QKKwlleGl0IDs7CisgICAgYzM4KikKKwll
Y2hvIGMzOC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGM0KikKKwllY2hvIGM0LWNvbnZleC1i
c2QKKwlleGl0IDs7CisgICAgZXNhYworZmkKKworY2F0ID4mMiA8PEVPRgorJDA6IHVuYWJsZSB0
byBndWVzcyBzeXN0ZW0gdHlwZQorCitUaGlzIHNjcmlwdCwgbGFzdCBtb2RpZmllZCAkdGltZXN0
YW1wLCBoYXMgZmFpbGVkIHRvIHJlY29nbml6ZQordGhlIG9wZXJhdGluZyBzeXN0ZW0geW91IGFy
ZSB1c2luZy4gSXQgaXMgYWR2aXNlZCB0aGF0IHlvdQorZG93bmxvYWQgdGhlIG1vc3QgdXAgdG8g
ZGF0ZSB2ZXJzaW9uIG9mIHRoZSBjb25maWcgc2NyaXB0cyBmcm9tCisKKyAgaHR0cDovL2dpdC5z
YXZhbm5haC5nbnUub3JnL2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZp
Zy5ndWVzcztoYj1IRUFECithbmQKKyAgaHR0cDovL2dpdC5zYXZhbm5haC5nbnUub3JnL2dpdHdl
Yi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZpZy5zdWI7aGI9SEVBRAorCitJZiB0
aGUgdmVyc2lvbiB5b3UgcnVuICgkMCkgaXMgYWxyZWFkeSB1cCB0byBkYXRlLCBwbGVhc2UKK3Nl
bmQgdGhlIGZvbGxvd2luZyBkYXRhIGFuZCBhbnkgaW5mb3JtYXRpb24geW91IHRoaW5rIG1pZ2h0
IGJlCitwZXJ0aW5lbnQgdG8gPGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+IGluIG9yZGVyIHRvIHBy
b3ZpZGUgdGhlIG5lZWRlZAoraW5mb3JtYXRpb24gdG8gaGFuZGxlIHlvdXIgc3lzdGVtLgorCitj
b25maWcuZ3Vlc3MgdGltZXN0YW1wID0gJHRpbWVzdGFtcAorCit1bmFtZSAtbSA9IGAodW5hbWUg
LW0pIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1yID0gYCh1bmFtZSAtcikg
Mj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXMgPSBgKHVuYW1lIC1zKSAyPi9k
ZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtdiA9IGAodW5hbWUgLXYpIDI+L2Rldi9u
dWxsIHx8IGVjaG8gdW5rbm93bmAKKworL3Vzci9iaW4vdW5hbWUgLXAgPSBgKC91c3IvYmluL3Vu
YW1lIC1wKSAyPi9kZXYvbnVsbGAKKy9iaW4vdW5hbWUgLVggICAgID0gYCgvYmluL3VuYW1lIC1Y
KSAyPi9kZXYvbnVsbGAKKworaG9zdGluZm8gICAgICAgICAgICAgICA9IGAoaG9zdGluZm8pIDI+
L2Rldi9udWxsYAorL2Jpbi91bml2ZXJzZSAgICAgICAgICA9IGAoL2Jpbi91bml2ZXJzZSkgMj4v
ZGV2L251bGxgCisvdXNyL2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jpbi9hcmNoIC1rKSAy
Pi9kZXYvbnVsbGAKKy9iaW4vYXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkgMj4vZGV2
L251bGxgCisvdXNyL2Jpbi9vc2xldmVsICAgICAgID0gYCgvdXNyL2Jpbi9vc2xldmVsKSAyPi9k
ZXYvbnVsbGAKKy91c3IvY29udmV4L2dldHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dldHN5c2lu
Zm8pIDI+L2Rldi9udWxsYAorCitVTkFNRV9NQUNISU5FID0gJHtVTkFNRV9NQUNISU5FfQorVU5B
TUVfUkVMRUFTRSA9ICR7VU5BTUVfUkVMRUFTRX0KK1VOQU1FX1NZU1RFTSAgPSAke1VOQU1FX1NZ
U1RFTX0KK1VOQU1FX1ZFUlNJT04gPSAke1VOQU1FX1ZFUlNJT059CitFT0YKKworZXhpdCAxCisK
KyMgTG9jYWwgdmFyaWFibGVzOgorIyBldmFsOiAoYWRkLWhvb2sgJ3dyaXRlLWZpbGUtaG9va3Mg
J3RpbWUtc3RhbXApCisjIHRpbWUtc3RhbXAtc3RhcnQ6ICJ0aW1lc3RhbXA9JyIKKyMgdGltZS1z
dGFtcC1mb3JtYXQ6ICIlOnktJTAybS0lMDJkIgorIyB0aW1lLXN0YW1wLWVuZDogIiciCisjIEVu
ZDoKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2NvbmZpZy5oLmlu
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L2NvbmZpZy5oLmluCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDQ2
OCBAQAorLyogY29uZmlnLmguaW4uICBHZW5lcmF0ZWQgZnJvbSBjb25maWd1cmUuYWMgYnkgYXV0
b2hlYWRlci4gICovCisKKy8qIERlZmluZSB0byBvbmUgb2YgYF9nZXRiNjcnLCBgR0VUQjY3Jywg
YGdldGI2NycgZm9yIENyYXktMiBhbmQgQ3JheS1ZTVAKKyAgIHN5c3RlbXMuIFRoaXMgZnVuY3Rp
b24gaXMgcmVxdWlyZWQgZm9yIGBhbGxvY2EuYycgc3VwcG9ydCBvbiB0aG9zZSBzeXN0ZW1zLgor
ICAgKi8KKyN1bmRlZiBDUkFZX1NUQUNLU0VHX0VORAorCisvKiBEZWZpbmUgdG8gMSBpZiB1c2lu
ZyBgYWxsb2NhLmMnLiAqLworI3VuZGVmIENfQUxMT0NBCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgYWxhcm0nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQUxBUk0KKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgYGFsbG9jYScsIGFzIGEgZnVuY3Rpb24gb3IgbWFjcm8u
ICovCisjdW5kZWYgSEFWRV9BTExPQ0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgPGFs
bG9jYS5oPiBhbmQgaXQgc2hvdWxkIGJlIHVzZWQgKG5vdCBvbiBVbHRyaXgpLgorICAgKi8KKyN1
bmRlZiBIQVZFX0FMTE9DQV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8YXJw
YS9pbmV0Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfQVJQQV9JTkVUX0gKKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBhdGV4aXQnIGZ1bmN0aW9uLiAqLworI3VuZGVm
IEhBVkVfQVRFWElUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgYnplcm8nIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQlpFUk8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIGBjbG9ja19nZXR0aW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0NMT0NLX0dF
VFRJTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBkdXAyJyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX0RVUDIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxm
Y250bC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0ZDTlRMX0gKKworLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmZGF0YXN5bmMnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfRkRBVEFTWU5DCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZm9yaycgZnVu
Y3Rpb24uICovCisjdW5kZWYgSEFWRV9GT1JLCisKKy8qIERlZmluZSB0byAxIGlmIGZzZWVrbyAo
YW5kIHByZXN1bWFibHkgZnRlbGxvKSBleGlzdHMgYW5kIGlzIGRlY2xhcmVkLiAqLworI3VuZGVm
IEhBVkVfRlNFRUtPCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZnRydW5jYXRl
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0ZUUlVOQ0FURQorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYGdldGN3ZCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRDV0QK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRob3N0YnluYW1lJyBmdW5jdGlv
bi4gKi8KKyN1bmRlZiBIQVZFX0dFVEhPU1RCWU5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBnZXRob3N0bmFtZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRIT1NU
TkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldHBhZ2VzaXplJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVFBBR0VTSVpFCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgZ2V0dGltZW9mZGF5JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVFRJ
TUVPRkRBWQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGluZXRfbnRvYScgZnVu
Y3Rpb24uICovCisjdW5kZWYgSEFWRV9JTkVUX05UT0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0lOVFRZ
UEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBpc2FzY2lpJyBmdW5jdGlv
bi4gKi8KKyN1bmRlZiBIQVZFX0lTQVNDSUkKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBjcnlwdG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KKyN1bmRlZiBIQVZFX0xJQkNSWVBU
TworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpYmludGwuaD4gaGVhZGVyIGZp
bGUuICovCisjdW5kZWYgSEFWRV9MSUJJTlRMX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIGBydCcgbGlicmFyeSAoLWxydCkuICovCisjdW5kZWYgSEFWRV9MSUJSVAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHV1aWQnIGxpYnJhcnkgKC1sdXVpZCkuICovCisj
dW5kZWYgSEFWRV9MSUJVVUlECisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgeWFq
bCcgbGlicmFyeSAoLWx5YWpsKS4gKi8KKyN1bmRlZiBIQVZFX0xJQllBSkwKKworLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIGB6JyBsaWJyYXJ5ICgtbHopLiAqLworI3VuZGVmIEhBVkVf
TElCWgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpbWl0cy5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0xJTUlUU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgbG9jYWx0aW1lX3InIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTE9DQUxUSU1F
X1IKKworLyogRGVmaW5lIHRvIDEgaWYgeW91ciBzeXN0ZW0gaGFzIGEgR05VIGxpYmMgY29tcGF0
aWJsZSBgbWFsbG9jJyBmdW5jdGlvbiwgYW5kCisgICB0byAwIG90aGVyd2lzZS4gKi8KKyN1bmRl
ZiBIQVZFX01BTExPQworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG1hbGxvYy5o
PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01BTExPQ19ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgbWVtY2hyJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01FTUNI
UgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbW1vdmUnIGZ1bmN0aW9uLiAq
LworI3VuZGVmIEhBVkVfTUVNTU9WRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
PG1lbW9yeS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01FTU9SWV9ICisKKy8qIERl
ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtc2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBI
QVZFX01FTVNFVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1rZGlyJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRElSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZl
IHRoZSBgbWtmaWZvJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRklGTworCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3UgaGF2ZSBhIHdvcmtpbmcgYG1tYXAnIHN5c3RlbSBjYWxsLiAqLworI3Vu
ZGVmIEhBVkVfTU1BUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG11bm1hcCcg
ZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NVU5NQVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxuZXRkYi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX05FVERCX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxuZXRpbmV0L2luLmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfTkVUSU5FVF9JTl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgcGF0aGNvbmYnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUEFUSENPTkYK
KworLyogRGVmaW5lIHRvIDEgaWYgdGhlIHN5c3RlbSBoYXMgdGhlIHR5cGUgYHB0cmRpZmZfdCcu
ICovCisjdW5kZWYgSEFWRV9QVFJESUZGX1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91ciBzeXN0
ZW0gaGFzIGEgR05VIGxpYmMgY29tcGF0aWJsZSBgcmVhbGxvYycgZnVuY3Rpb24sCisgICBhbmQg
dG8gMCBvdGhlcndpc2UuICovCisjdW5kZWYgSEFWRV9SRUFMTE9DCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgcmVhbHBhdGgnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUkVB
TFBBVEgKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGByZWdjb21wJyBmdW5jdGlv
bi4gKi8KKyN1bmRlZiBIQVZFX1JFR0NPTVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBybWRpcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9STURJUgorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHNlbGVjdCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9T
RUxFQ1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzZXRlbnYnIGZ1bmN0aW9u
LiAqLworI3VuZGVmIEhBVkVfU0VURU5WCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgc29ja2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NPQ0tFVAorCisvKiBEZWZpbmUg
dG8gMSBpZiBzdGRib29sLmggY29uZm9ybXMgdG8gQzk5LiAqLworI3VuZGVmIEhBVkVfU1REQk9P
TF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkZGVmLmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfU1REREVGX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzdGRpbnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERJTlRfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGxpYi5oPiBoZWFkZXIgZmlsZS4g
Ki8KKyN1bmRlZiBIQVZFX1NURExJQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgc3RyY2FzZWNtcCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJDQVNFQ01QCisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyY2hyJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1NUUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmNzcG4n
IGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ1NQTgorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgYHN0cmR1cCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJEVVAKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJlcnJvcicgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9TVFJFUlJPUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0
cmluZ3MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVFJJTkdTX0gKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdHJpbmcuaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9TVFJJTkdfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cm5k
dXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSTkRVUAorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYHN0cnBicmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSUEJS
SworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnJjaHInIGZ1bmN0aW9uLiAq
LworI3VuZGVmIEhBVkVfU1RSUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHN0cnNwbicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJTUE4KKworLyogRGVmaW5lIHRv
IDEgaWYgeW91IGhhdmUgdGhlIGBzdHJzdHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RS
U1RSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RydG9sJyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX1NUUlRPTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHN0cnRvdWwnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSVE9VTAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnRvdWxsJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X1NUUlRPVUxMCisKKy8qIERlZmluZSB0byAxIGlmIGBzdF9ibGtzaXplJyBpcyBhIG1lbWJlciBv
ZiBgc3RydWN0IHN0YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxLU0laRQor
CisvKiBEZWZpbmUgdG8gMSBpZiBgc3RfYmxvY2tzJyBpcyBhIG1lbWJlciBvZiBgc3RydWN0IHN0
YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTCisKKy8qIERlZmluZSB0
byAxIGlmIGBzdF9yZGV2JyBpcyBhIG1lbWJlciBvZiBgc3RydWN0IHN0YXQnLiAqLworI3VuZGVm
IEhBVkVfU1RSVUNUX1NUQVRfU1RfUkRFVgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3VyIGBzdHJ1
Y3Qgc3RhdCcgaGFzIGBzdF9ibG9ja3MnLiBEZXByZWNhdGVkLCB1c2UKKyAgIGBIQVZFX1NUUlVD
VF9TVEFUX1NUX0JMT0NLUycgaW5zdGVhZC4gKi8KKyN1bmRlZiBIQVZFX1NUX0JMT0NLUworCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5c2xvZy5oPiBoZWFkZXIgZmlsZS4gKi8K
KyN1bmRlZiBIQVZFX1NZU0xPR19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8
c3lzL2ZpbGUuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfRklMRV9ICisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL2lvY3RsLmg+IGhlYWRlciBmaWxlLiAq
LworI3VuZGVmIEhBVkVfU1lTX0lPQ1RMX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDxzeXMvbW91bnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfTU9VTlRf
SAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9wYXJhbS5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19QQVJBTV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSA8c3lzL3NvY2tldC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZ
U19TT0NLRVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0dmZz
Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1NUQVRWRlNfSAorCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0Lmg+IGhlYWRlciBmaWxlLiAqLworI3Vu
ZGVmIEhBVkVfU1lTX1NUQVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5
cy90aW1lLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1RJTUVfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy90eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8K
KyN1bmRlZiBIQVZFX1NZU19UWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSA8dGVybWlvcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1RFUk1JT1NfSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHR6c2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1RaU0VUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgdW5hbWUnIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVU5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDx1bmlzdGQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9VTklTVERfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHZmb3JrJyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX1ZGT1JLCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8dmZvcmsu
aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9WRk9SS19ICisKKy8qIERlZmluZSB0byAx
IGlmIGBmb3JrJyB3b3Jrcy4gKi8KKyN1bmRlZiBIQVZFX1dPUktJTkdfRk9SSworCisvKiBEZWZp
bmUgdG8gMSBpZiBgdmZvcmsnIHdvcmtzLiAqLworI3VuZGVmIEhBVkVfV09SS0lOR19WRk9SSwor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAorCisvKiBEZWZp
bmUgdG8gMSBpZiB0aGUgc3lzdGVtIGhhcyB0aGUgdHlwZSBgX0Jvb2wnLiAqLworI3VuZGVmIEhB
VkVfX0JPT0wKKworLyogRGVmaW5lIHRvIDEgaWYgYGxzdGF0JyBkZXJlZmVyZW5jZXMgYSBzeW1s
aW5rIHNwZWNpZmllZCB3aXRoIGEgdHJhaWxpbmcKKyAgIHNsYXNoLiAqLworI3VuZGVmIExTVEFU
X0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCisKKy8qIERlZmluZSB0byAxIGlmIGBtYWpvcicsIGBt
aW5vcicsIGFuZCBgbWFrZWRldicgYXJlIGRlY2xhcmVkIGluIDxta2Rldi5oPi4KKyAgICovCisj
dW5kZWYgTUFKT1JfSU5fTUtERVYKKworLyogRGVmaW5lIHRvIDEgaWYgYG1ham9yJywgYG1pbm9y
JywgYW5kIGBtYWtlZGV2JyBhcmUgZGVjbGFyZWQgaW4KKyAgIDxzeXNtYWNyb3MuaD4uICovCisj
dW5kZWYgTUFKT1JfSU5fU1lTTUFDUk9TCisKKy8qIERlZmluZSB0byB0aGUgYWRkcmVzcyB3aGVy
ZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLworI3VuZGVm
IFBBQ0tBR0VfQlVHUkVQT1JUCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1lIG9mIHRoaXMg
cGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX05BTUUKKworLyogRGVmaW5lIHRvIHRoZSBmdWxs
IG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfU1RS
SU5HCisKKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBzaG9ydCBuYW1lIG9mIHRoaXMgcGFj
a2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1RBUk5BTUUKKworLyogRGVmaW5lIHRvIHRoZSBob21l
IHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1VSTAorCisvKiBEZWZp
bmUgdG8gdGhlIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tBR0VfVkVS
U0lPTgorCisvKiBJZiB1c2luZyB0aGUgQyBpbXBsZW1lbnRhdGlvbiBvZiBhbGxvY2EsIGRlZmlu
ZSBpZiB5b3Uga25vdyB0aGUKKyAgIGRpcmVjdGlvbiBvZiBzdGFjayBncm93dGggZm9yIHlvdXIg
c3lzdGVtOyBvdGhlcndpc2UgaXQgd2lsbCBiZQorICAgYXV0b21hdGljYWxseSBkZWR1Y2VkIGF0
IHJ1bnRpbWUuCisJU1RBQ0tfRElSRUNUSU9OID4gMCA9PiBncm93cyB0b3dhcmQgaGlnaGVyIGFk
ZHJlc3NlcworCVNUQUNLX0RJUkVDVElPTiA8IDAgPT4gZ3Jvd3MgdG93YXJkIGxvd2VyIGFkZHJl
c3NlcworCVNUQUNLX0RJUkVDVElPTiA9IDAgPT4gZGlyZWN0aW9uIG9mIGdyb3d0aCB1bmtub3du
ICovCisjdW5kZWYgU1RBQ0tfRElSRUNUSU9OCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZl
IHRoZSBBTlNJIEMgaGVhZGVyIGZpbGVzLiAqLworI3VuZGVmIFNURENfSEVBREVSUworCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgY2FuIHNhZmVseSBpbmNsdWRlIGJvdGggPHN5cy90aW1lLmg+IGFu
ZCA8dGltZS5oPi4gKi8KKyN1bmRlZiBUSU1FX1dJVEhfU1lTX1RJTUUKKworLyogRW5hYmxlIGV4
dGVuc2lvbnMgb24gQUlYIDMsIEludGVyaXguICAqLworI2lmbmRlZiBfQUxMX1NPVVJDRQorIyB1
bmRlZiBfQUxMX1NPVVJDRQorI2VuZGlmCisvKiBFbmFibGUgR05VIGV4dGVuc2lvbnMgb24gc3lz
dGVtcyB0aGF0IGhhdmUgdGhlbS4gICovCisjaWZuZGVmIF9HTlVfU09VUkNFCisjIHVuZGVmIF9H
TlVfU09VUkNFCisjZW5kaWYKKy8qIEVuYWJsZSB0aHJlYWRpbmcgZXh0ZW5zaW9ucyBvbiBTb2xh
cmlzLiAgKi8KKyNpZm5kZWYgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTCisjIHVuZGVmIF9QT1NJ
WF9QVEhSRUFEX1NFTUFOVElDUworI2VuZGlmCisvKiBFbmFibGUgZXh0ZW5zaW9ucyBvbiBIUCBO
b25TdG9wLiAgKi8KKyNpZm5kZWYgX1RBTkRFTV9TT1VSQ0UKKyMgdW5kZWYgX1RBTkRFTV9TT1VS
Q0UKKyNlbmRpZgorLyogRW5hYmxlIGdlbmVyYWwgZXh0ZW5zaW9ucyBvbiBTb2xhcmlzLiAgKi8K
KyNpZm5kZWYgX19FWFRFTlNJT05TX18KKyMgdW5kZWYgX19FWFRFTlNJT05TX18KKyNlbmRpZgor
CisKKy8qIERlZmluZSB0byAxIHRvIG1ha2UgZnNlZWtvIHZpc2libGUgb24gc29tZSBob3N0cyAo
ZS5nLiBnbGliYyAyLjIpLiAqLworI3VuZGVmIF9MQVJHRUZJTEVfU09VUkNFCisKKy8qIERlZmlu
ZSB0byAxIGlmIG9uIE1JTklYLiAqLworI3VuZGVmIF9NSU5JWAorCisvKiBEZWZpbmUgdG8gMiBp
ZiB0aGUgc3lzdGVtIGRvZXMgbm90IHByb3ZpZGUgUE9TSVguMSBmZWF0dXJlcyBleGNlcHQgd2l0
aAorICAgdGhpcyBkZWZpbmVkLiAqLworI3VuZGVmIF9QT1NJWF8xX1NPVVJDRQorCisvKiBEZWZp
bmUgdG8gMSBpZiB5b3UgbmVlZCB0byBpbiBvcmRlciBmb3IgYHN0YXQnIGFuZCBvdGhlciB0aGlu
Z3MgdG8gd29yay4gKi8KKyN1bmRlZiBfUE9TSVhfU09VUkNFCisKKy8qIERlZmluZSBmb3IgU29s
YXJpcyAyLjUuMSBzbyB0aGUgdWludDMyX3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisg
ICA8cHRocmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVk
ZWYgd2VyZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50
YXggZXJyb3IuICovCisjdW5kZWYgX1VJTlQzMl9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAy
LjUuMSBzbyB0aGUgdWludDY0X3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisgICA8cHRo
cmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVkZWYgd2Vy
ZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50YXggZXJy
b3IuICovCisjdW5kZWYgX1VJTlQ2NF9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAyLjUuMSBz
byB0aGUgdWludDhfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+
LCBvciA8c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93
ZWQsIHRoZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8K
KyN1bmRlZiBfVUlOVDhfVAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBk
b2Vzbid0IGRlZmluZS4gKi8KKyN1bmRlZiBnaWRfdAorCisvKiBEZWZpbmUgdG8gYF9faW5saW5l
X18nIG9yIGBfX2lubGluZScgaWYgdGhhdCdzIHdoYXQgdGhlIEMgY29tcGlsZXIKKyAgIGNhbGxz
IGl0LCBvciB0byBub3RoaW5nIGlmICdpbmxpbmUnIGlzIG5vdCBzdXBwb3J0ZWQgdW5kZXIgYW55
IG5hbWUuICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cworI3VuZGVmIGlubGluZQorI2VuZGlmCisK
Ky8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGgg
ZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFy
ZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIGludDE2X3QKKworLyogRGVm
aW5lIHRvIHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5
IDMyIGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1
ZGVzIGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MzJfdAorCisvKiBEZWZpbmUgdG8g
dGhlIHR5cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkgNjQgYml0
cyBpZgorICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8g
bm90IGRlZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQ2NF90CisKKy8qIERlZmluZSB0byB0aGUgdHlw
ZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMgaWYgc3Vj
aAorICAgYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5vdCBkZWZp
bmUgaXQuICovCisjdW5kZWYgaW50OF90CisKKy8qIERlZmluZSB0byBycGxfbWFsbG9jIGlmIHRo
ZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiBtYWxsb2MK
KworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVmaW5lLiAq
LworI3VuZGVmIG1vZGVfdAorCisvKiBEZWZpbmUgdG8gYGxvbmcgaW50JyBpZiA8c3lzL3R5cGVz
Lmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBvZmZfdAorCisvKiBEZWZpbmUgdG8gYGlu
dCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgcGlkX3QKKwor
LyogRGVmaW5lIHRvIHJwbF9yZWFsbG9jIGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91
bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiByZWFsbG9jCisKKy8qIERlZmluZSB0byB0aGUgZXF1aXZh
bGVudCBvZiB0aGUgQzk5ICdyZXN0cmljdCcga2V5d29yZCwgb3IgdG8KKyAgIG5vdGhpbmcgaWYg
dGhpcyBpcyBub3Qgc3VwcG9ydGVkLiAgRG8gbm90IGRlZmluZSBpZiByZXN0cmljdCBpcworICAg
c3VwcG9ydGVkIGRpcmVjdGx5LiAgKi8KKyN1bmRlZiByZXN0cmljdAorLyogV29yayBhcm91bmQg
YSBidWcgaW4gU3VuIEMrKzogaXQgZG9lcyBub3Qgc3VwcG9ydCBfUmVzdHJpY3Qgb3IKKyAgIF9f
cmVzdHJpY3RfXywgZXZlbiB0aG91Z2ggdGhlIGNvcnJlc3BvbmRpbmcgU3VuIEMgY29tcGlsZXIg
ZW5kcyB1cCB3aXRoCisgICAiI2RlZmluZSByZXN0cmljdCBfUmVzdHJpY3QiIG9yICIjZGVmaW5l
IHJlc3RyaWN0IF9fcmVzdHJpY3RfXyIgaW4gdGhlCisgICBwcmV2aW91cyBsaW5lLiAgUGVyaGFw
cyBzb21lIGZ1dHVyZSB2ZXJzaW9uIG9mIFN1biBDKysgd2lsbCB3b3JrIHdpdGgKKyAgIHJlc3Ry
aWN0OyBpZiBzbywgaG9wZWZ1bGx5IGl0IGRlZmluZXMgX19SRVNUUklDVCBsaWtlIFN1biBDIGRv
ZXMuICAqLworI2lmIGRlZmluZWQgX19TVU5QUk9fQ0MgJiYgIWRlZmluZWQgX19SRVNUUklDVAor
IyBkZWZpbmUgX1Jlc3RyaWN0CisjIGRlZmluZSBfX3Jlc3RyaWN0X18KKyNlbmRpZgorCisvKiBE
ZWZpbmUgdG8gYHVuc2lnbmVkIGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUu
ICovCisjdW5kZWYgc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+
IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBzc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50
JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5lLiAqLworI3VuZGVmIHVpZF90CisKKy8q
IERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGgg
ZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFy
ZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQxNl90CisKKy8qIERl
ZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhh
Y3RseSAzMiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBp
bmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQzMl90CisKKy8qIERlZmlu
ZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3Rs
eSA2NCBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNs
dWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQ2NF90CisKKy8qIERlZmluZSB0
byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4
IGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVz
IGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDhfdAorCisvKiBEZWZpbmUgYXMgYGZv
cmsnIGlmIGB2Zm9yaycgZG9lcyBub3Qgd29yay4gKi8KKyN1bmRlZiB2Zm9yawpkaWZmIC1yIGUy
NzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvY29uZmlnLnN1YgotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuc3ViCVdl
ZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDE3NzEgQEAKKyMhIC9iaW4v
c2gKKyMgQ29uZmlndXJhdGlvbiB2YWxpZGF0aW9uIHN1YnJvdXRpbmUgc2NyaXB0LgorIyAgIENv
cHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5
OSwKKyMgICAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAy
MDA4LCAyMDA5LCAyMDEwLAorIyAgIDIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMu
CisKK3RpbWVzdGFtcD0nMjAxMS0xMS0xMScKKworIyBUaGlzIGZpbGUgaXMgKGluIHByaW5jaXBs
ZSkgY29tbW9uIHRvIEFMTCBHTlUgc29mdHdhcmUuCisjIFRoZSBwcmVzZW5jZSBvZiBhIG1hY2hp
bmUgaW4gdGhpcyBmaWxlIHN1Z2dlc3RzIHRoYXQgU09NRSBHTlUgc29mdHdhcmUKKyMgY2FuIGhh
bmRsZSB0aGF0IG1hY2hpbmUuICBJdCBkb2VzIG5vdCBpbXBseSBBTEwgR05VIHNvZnR3YXJlIGNh
bi4KKyMKKyMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIg
b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1
dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisjIGJ1dCBXSVRIT1VUIEFO
WSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNI
QU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUK
KyMgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91
IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UKKyMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZy
ZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3RyZWV0IC0gRmlm
dGggRmxvb3IsIEJvc3RvbiwgTUEKKyMgMDIxMTAtMTMwMSwgVVNBLgorIworIyBBcyBhIHNwZWNp
YWwgZXhjZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91Cisj
IGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMg
YQorIyBjb25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkg
aW5jbHVkZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3Ug
dXNlIGZvciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKworIyBQbGVhc2Ugc2VuZCBwYXRj
aGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4gIFN1Ym1pdCBhIGNvbnRleHQKKyMgZGlm
ZiBhbmQgYSBwcm9wZXJseSBmb3JtYXR0ZWQgR05VIENoYW5nZUxvZyBlbnRyeS4KKyMKKyMgQ29u
ZmlndXJhdGlvbiBzdWJyb3V0aW5lIHRvIHZhbGlkYXRlIGFuZCBjYW5vbmljYWxpemUgYSBjb25m
aWd1cmF0aW9uIHR5cGUuCisjIFN1cHBseSB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24gdHlw
ZSBhcyBhbiBhcmd1bWVudC4KKyMgSWYgaXQgaXMgaW52YWxpZCwgd2UgcHJpbnQgYW4gZXJyb3Ig
bWVzc2FnZSBvbiBzdGRlcnIgYW5kIGV4aXQgd2l0aCBjb2RlIDEuCisjIE90aGVyd2lzZSwgd2Ug
cHJpbnQgdGhlIGNhbm9uaWNhbCBjb25maWcgdHlwZSBvbiBzdGRvdXQgYW5kIHN1Y2NlZWQuCisK
KyMgWW91IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgc2NyaXB0IGZyb206Cisj
IGh0dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2Jf
cGxhaW47Zj1jb25maWcuc3ViO2hiPUhFQUQKKworIyBUaGlzIGZpbGUgaXMgc3VwcG9zZWQgdG8g
YmUgdGhlIHNhbWUgZm9yIGFsbCBHTlUgcGFja2FnZXMKKyMgYW5kIHJlY29nbml6ZSBhbGwgdGhl
IENQVSB0eXBlcywgc3lzdGVtIHR5cGVzIGFuZCBhbGlhc2VzCisjIHRoYXQgYXJlIG1lYW5pbmdm
dWwgd2l0aCAqYW55KiBHTlUgc29mdHdhcmUuCisjIEVhY2ggcGFja2FnZSBpcyByZXNwb25zaWJs
ZSBmb3IgcmVwb3J0aW5nIHdoaWNoIHZhbGlkIGNvbmZpZ3VyYXRpb25zCisjIGl0IGRvZXMgbm90
IHN1cHBvcnQuICBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaAorIyBhIGZh
aWx1cmUgdG8gc3VwcG9ydCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZnJvbSBhIG1lYW5pbmdsZXNz
CisjIGNvbmZpZ3VyYXRpb24uCisKKyMgVGhlIGdvYWwgb2YgdGhpcyBmaWxlIGlzIHRvIG1hcCBh
bGwgdGhlIHZhcmlvdXMgdmFyaWF0aW9ucyBvZiBhIGdpdmVuCisjIG1hY2hpbmUgc3BlY2lmaWNh
dGlvbiBpbnRvIGEgc2luZ2xlIHNwZWNpZmljYXRpb24gaW4gdGhlIGZvcm06CisjCUNQVV9UWVBF
LU1BTlVGQUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNCisjIG9yIGluIHNvbWUgY2FzZXMsIHRoZSBu
ZXdlciBmb3VyLXBhcnQgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVS
QVRJTkdfU1lTVEVNCisjIEl0IGlzIHdyb25nIHRvIGVjaG8gYW55IG90aGVyIHR5cGUgb2Ygc3Bl
Y2lmaWNhdGlvbi4KKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdl
PSJcCitVc2FnZTogJDAgW09QVElPTl0gQ1BVLU1GUi1PUFNZUworICAgICAgICQwIFtPUFRJT05d
IEFMSUFTCisKK0Nhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gbmFtZS4KKworT3BlcmF0aW9u
IG1vZGVzOgorICAtaCwgLS1oZWxwICAgICAgICAgcHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQK
KyAgLXQsIC0tdGltZS1zdGFtcCAgIHByaW50IGRhdGUgb2YgbGFzdCBtb2RpZmljYXRpb24sIHRo
ZW4gZXhpdAorICAtdiwgLS12ZXJzaW9uICAgICAgcHJpbnQgdmVyc2lvbiBudW1iZXIsIHRoZW4g
ZXhpdAorCitSZXBvcnQgYnVncyBhbmQgcGF0Y2hlcyB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9y
Zz4uIgorCit2ZXJzaW9uPSJcCitHTlUgY29uZmlnLnN1YiAoJHRpbWVzdGFtcCkKKworQ29weXJp
Z2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LCAy
MDAwLAorMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCwgMjAw
OSwgMjAxMCwgMjAxMSBGcmVlCitTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1RoaXMgaXMg
ZnJlZSBzb2Z0d2FyZTsgc2VlIHRoZSBzb3VyY2UgZm9yIGNvcHlpbmcgY29uZGl0aW9ucy4gIFRo
ZXJlIGlzIE5PCit3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iCisKK2hlbHA9IgorVHJ5IFxgJG1lIC0taGVs
cCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIgorCisjIFBhcnNlIGNvbW1hbmQgbGluZQord2hpbGUg
dGVzdCAkIyAtZ3QgMCA7IGRvCisgIGNhc2UgJDEgaW4KKyAgICAtLXRpbWUtc3RhbXAgfCAtLXRp
bWUqIHwgLXQgKQorICAgICAgIGVjaG8gIiR0aW1lc3RhbXAiIDsgZXhpdCA7OworICAgIC0tdmVy
c2lvbiB8IC12ICkKKyAgICAgICBlY2hvICIkdmVyc2lvbiIgOyBleGl0IDs7CisgICAgLS1oZWxw
IHwgLS1oKiB8IC1oICkKKyAgICAgICBlY2hvICIkdXNhZ2UiOyBleGl0IDs7CisgICAgLS0gKSAg
ICAgIyBTdG9wIG9wdGlvbiBwcm9jZXNzaW5nCisgICAgICAgc2hpZnQ7IGJyZWFrIDs7CisgICAg
LSApCSMgVXNlIHN0ZGluIGFzIGlucHV0LgorICAgICAgIGJyZWFrIDs7CisgICAgLSogKQorICAg
ICAgIGVjaG8gIiRtZTogaW52YWxpZCBvcHRpb24gJDEkaGVscCIKKyAgICAgICBleGl0IDEgOzsK
KworICAgICpsb2NhbCopCisgICAgICAgIyBGaXJzdCBwYXNzIHRocm91Z2ggYW55IGxvY2FsIG1h
Y2hpbmUgdHlwZXMuCisgICAgICAgZWNobyAkMQorICAgICAgIGV4aXQgOzsKKworICAgICogKQor
ICAgICAgIGJyZWFrIDs7CisgIGVzYWMKK2RvbmUKKworY2FzZSAkIyBpbgorIDApIGVjaG8gIiRt
ZTogbWlzc2luZyBhcmd1bWVudCRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworIDEpIDs7CisgKikg
ZWNobyAiJG1lOiB0b28gbWFueSBhcmd1bWVudHMkaGVscCIgPiYyCisgICAgZXhpdCAxOzsKK2Vz
YWMKKworIyBTZXBhcmF0ZSB3aGF0IHRoZSB1c2VyIGdhdmUgaW50byBDUFUtQ09NUEFOWSBhbmQg
T1Mgb3IgS0VSTkVMLU9TIChpZiBhbnkpLgorIyBIZXJlIHdlIG11c3QgcmVjb2duaXplIGFsbCB0
aGUgdmFsaWQgS0VSTkVMLU9TIGNvbWJpbmF0aW9ucy4KK21heWJlX29zPWBlY2hvICQxIHwgc2Vk
ICdzL15cKC4qXCktXChbXi1dKi1bXi1dKlwpJC9cMi8nYAorY2FzZSAkbWF5YmVfb3MgaW4KKyAg
bnRvLXFueCogfCBsaW51eC1nbnUqIHwgbGludXgtYW5kcm9pZCogfCBsaW51eC1kaWV0bGliYyB8
IGxpbnV4LW5ld2xpYiogfCBcCisgIGxpbnV4LXVjbGliYyogfCB1Y2xpbnV4LXVjbGliYyogfCB1
Y2xpbnV4LWdudSogfCBrZnJlZWJzZCotZ251KiB8IFwKKyAga25ldGJzZCotZ251KiB8IG5ldGJz
ZCotZ251KiB8IFwKKyAga29wZW5zb2xhcmlzKi1nbnUqIHwgXAorICBzdG9ybS1jaGFvcyogfCBv
czItZW14KiB8IHJ0bWstbm92YSopCisgICAgb3M9LSRtYXliZV9vcworICAgIGJhc2ljX21hY2hp
bmU9YGVjaG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0qXCkkL1wxLydgCisgICAg
OzsKKyAgKikKKyAgICBiYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzLy1bXi1dKiQvLydg
CisgICAgaWYgWyAkYmFzaWNfbWFjaGluZSAhPSAkMSBdCisgICAgdGhlbiBvcz1gZWNobyAkMSB8
IHNlZCAncy8uKi0vLS8nYAorICAgIGVsc2Ugb3M9OyBmaQorICAgIDs7Citlc2FjCisKKyMjIyBM
ZXQncyByZWNvZ25pemUgY29tbW9uIG1hY2hpbmVzIGFzIG5vdCBiZWluZyBvcGVyYXRpbmcgc3lz
dGVtcyBzbworIyMjIHRoYXQgdGhpbmdzIGxpa2UgY29uZmlnLnN1YiBkZWNzdGF0aW9uLTMxMDAg
d29yay4gIFdlIGFsc28KKyMjIyByZWNvZ25pemUgc29tZSBtYW51ZmFjdHVyZXJzIGFzIG5vdCBi
ZWluZyBvcGVyYXRpbmcgc3lzdGVtcywgc28gd2UKKyMjIyBjYW4gcHJvdmlkZSBkZWZhdWx0IG9w
ZXJhdGluZyBzeXN0ZW1zIGJlbG93LgorY2FzZSAkb3MgaW4KKwktc3VuKm9zKikKKwkJIyBQcmV2
ZW50IGZvbGxvd2luZyBjbGF1c2UgZnJvbSBoYW5kbGluZyB0aGlzIGludmFsaWQgaW5wdXQuCisJ
CTs7CisJLWRlYyogfCAtbWlwcyogfCAtc2VxdWVudCogfCAtZW5jb3JlKiB8IC1wYzUzMiogfCAt
c2dpKiB8IC1zb255KiB8IFwKKwktYXR0KiB8IC03MzAwKiB8IC0zMzAwKiB8IC1kZWx0YSogfCAt
bW90b3JvbGEqIHwgLXN1blsyMzRdKiB8IFwKKwktdW5pY29tKiB8IC1pYm0qIHwgLW5leHQgfCAt
aHAgfCAtaXNpKiB8IC1hcG9sbG8gfCAtYWx0b3MqIHwgXAorCS1jb252ZXJnZW50KiB8IC1uY3Iq
IHwgLW5ld3MgfCAtMzIqIHwgLTM2MDAqIHwgLTMxMDAqIHwgLWhpdGFjaGkqIHxcCisJLWNbMTIz
XSogfCAtY29udmV4KiB8IC1zdW4gfCAtY3JkcyB8IC1vbXJvbiogfCAtZGcgfCAtdWx0cmEgfCAt
dHRpKiB8IFwKKwktaGFycmlzIHwgLWRvbHBoaW4gfCAtaGlnaGxldmVsIHwgLWdvdWxkIHwgLWNi
bSB8IC1ucyB8IC1tYXNzY29tcCB8IFwKKwktYXBwbGUgfCAtYXhpcyB8IC1rbnV0aCB8IC1jcmF5
IHwgLW1pY3JvYmxhemUpCisJCW9zPQorCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWJsdWVn
ZW5lKikKKwkJb3M9LWNuaworCQk7OworCS1zaW0gfCAtY2lzY28gfCAtb2tpIHwgLXdlYyB8IC13
aW5ib25kKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7OworCS1zY291dCkKKwkJOzsK
Kwktd3JzKQorCQlvcz0tdnh3b3JrcworCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWNob3J1
c29zKikKKwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktY2hvcnVz
cmRiKQorCQlvcz0tY2hvcnVzcmRiCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktaGl1eCop
CisJCW9zPS1oaXV4d2UyCisJCTs7CisJLXNjbzYpCisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFj
aGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281KQor
CQlvcz0tc2NvMy4ydjUKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0u
Ki84Ni1wYy8nYAorCQk7OworCS1zY280KQorCQlvcz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGlu
ZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQt
OV0qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJh
c2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwkt
c2NvMy4ydls0LTldKikKKwkJIyBEb24ndCBmb3JnZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBv
ciBuZXdlci4KKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1w
Yy8nYAorCQk7OworCS1zY281djYqKQorCQkjIERvbid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlz
IDMuMnY0IG9yIG5ld2VyLgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2
LS4qLzg2LXBjLydgCisJCTs7CisJLXNjbyopCisJCW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNo
aW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXVkayopCisJ
CWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsK
KwktaXNjKQorCQlvcz0taXNjMi4yCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktY2xpeCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBl
ci1pbnRlcmdyYXBoCisJCTs7CisJLWlzYyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBz
ZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktbHlueCopCisJCW9zPS1seW54b3MKKwkJ
OzsKKwktcHR4KikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84
Ni1zZXF1ZW50LydgCisJCTs7CisJLXdpbmRvd3NudCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAt
ZSAncy93aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsKKwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7
CisJLW1pbnQgfCAtbWludFswLTldKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9z
PS1taW50CisJCTs7Citlc2FjCisKKyMgRGVjb2RlIGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNP
TVBBTlkgY29tYmluYXRpb25zLgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXpl
IHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aG91dCBjb21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBv
bWl0dGVkIGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUgc3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkx
NzUwYSB8IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFscGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFl
djU2IHwgYWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2
NGV2WzQtOF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhhNjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjdd
IFwKKwl8IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFybSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBh
cm12WzIzNDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2ciB8IGF2cjMyIFwKKyAgICAgICAgfCBiZTMy
IHwgYmU2NCBcCisJfCBiZmluIFwKKwl8IGM0eCB8IGNsaXBwZXIgXAorCXwgZDEwdiB8IGQzMHYg
fCBkbHggfCBkc3AxNnh4IFwKKwl8IGVwaXBoYW55IFwKKwl8IGZpZG8gfCBmcjMwIHwgZnJ2IFwK
Kwl8IGg4MzAwIHwgaDg1MDAgfCBocHBhIHwgaHBwYTEuWzAxXSB8IGhwcGEyLjAgfCBocHBhMi4w
W253XSB8IGhwcGE2NCBcCisJfCBoZXhhZ29uIFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlh
NjQgXAorCXwgaXAyayB8IGlxMjAwMCBcCisJfCBsZTMyIHwgbGU2NCBcCisJfCBsbTMyIFwKKwl8
IG0zMmMgfCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsgXAorCXwgbWF4cSB8
IG1iIHwgbWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwgbWlwcyB8IG1pcHNi
ZSB8IG1pcHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAorCXwgbWlwczY0IHwg
bWlwczY0ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwgXAorCXwgbWlwczY0
b3Jpb24gfCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlwczY0cjU5MDBlbCBc
CisJfCBtaXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAwIHwgbWlwczY0dnI0
MTAwZWwgXAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAorCXwgbWlwczY0dnI1
MDAwIHwgbWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlwczY0dnI1OTAwZWwg
XAorCXwgbWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMycjIgfCBtaXBzaXNh
MzJyMmVsIFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1pcHNpc2E2NHIyIHwg
bWlwc2lzYTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRzYjFlbCBcCisJfCBt
aXBzaXNhNjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4MzkgfCBtaXBzdHgz
OWVsIFwKKwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8IG10IFwKKwl8IG1z
cDQzMCBcCisJfCBuZHMzMiB8IG5kczMybGUgfCBuZHMzMmJlIFwKKwl8IG5pb3MgfCBuaW9zMiBc
CisJfCBuczE2ayB8IG5zMzJrIFwKKwl8IG9wZW44IFwKKwl8IG9yMzIgXAorCXwgcGRwMTAgfCBw
ZHAxMSB8IHBqIHwgcGpsIFwKKwl8IHBvd2VycGMgfCBwb3dlcnBjNjQgfCBwb3dlcnBjNjRsZSB8
IHBvd2VycGNsZSBcCisJfCBweXJhbWlkIFwKKwl8IHJsNzggfCByeCBcCisJfCBzY29yZSBcCisJ
fCBzaCB8IHNoWzEyMzRdIHwgc2hbMjRdYSB8IHNoWzI0XWFlYiB8IHNoWzIzXWUgfCBzaFszNF1l
YiB8IHNoZWIgfCBzaGJlIHwgc2hsZSB8IHNoWzEyMzRdbGUgfCBzaDNlbGUgXAorCXwgc2g2NCB8
IHNoNjRsZSBcCisJfCBzcGFyYyB8IHNwYXJjNjQgfCBzcGFyYzY0YiB8IHNwYXJjNjR2IHwgc3Bh
cmM4NnggfCBzcGFyY2xldCB8IHNwYXJjbGl0ZSBcCisJfCBzcGFyY3Y4IHwgc3BhcmN2OSB8IHNw
YXJjdjliIHwgc3BhcmN2OXYgXAorCXwgc3B1IFwKKwl8IHRhaG9lIHwgdGljNHggfCB0aWM1NHgg
fCB0aWM1NXggfCB0aWM2eCB8IHRpYzgwIHwgdHJvbiBcCisJfCB1Ymljb20zMiBcCisJfCB2ODUw
IHwgdjg1MGUgfCB2ODUwZTEgfCB2ODUwZTIgfCB2ODUwZXMgfCB2ODUwZTJ2MyBcCisJfCB3ZTMy
ayBcCisJfCB4ODYgfCB4YzE2eCB8IHhzdG9ybXkxNiB8IHh0ZW5zYSBcCisJfCB6OGsgfCB6ODAp
CisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93bgorCQk7OworCWM1NHgpCisJ
CWJhc2ljX21hY2hpbmU9dGljNTR4LXVua25vd24KKwkJOzsKKwljNTV4KQorCQliYXNpY19tYWNo
aW5lPXRpYzU1eC11bmtub3duCisJCTs7CisJYzZ4KQorCQliYXNpY19tYWNoaW5lPXRpYzZ4LXVu
a25vd24KKwkJOzsKKwltNjgxMSB8IG02OGhjMTEgfCBtNjgxMiB8IG02OGhjMTIgfCBwaWNvY2hp
cCkKKwkJIyBNb3Rvcm9sYSA2OEhDMTEvMTIuCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hp
bmUtdW5rbm93bgorCQlvcz0tbm9uZQorCQk7OworCW04ODExMCB8IG02ODBbMTIzNDZdMCB8IG02
ODM/MiB8IG02ODM2MCB8IG01MjAwIHwgdjcwIHwgdzY1IHwgejhrKQorCQk7OworCW1zMSkKKwkJ
YmFzaWNfbWFjaGluZT1tdC11bmtub3duCisJCTs7CisKKwlzdHJvbmdhcm0gfCB0aHVtYiB8IHhz
Y2FsZSkKKwkJYmFzaWNfbWFjaGluZT1hcm0tdW5rbm93bgorCQk7OworCisJeHNjYWxlZWIpCisJ
CWJhc2ljX21hY2hpbmU9YXJtZWItdW5rbm93bgorCQk7OworCisJeHNjYWxlZWwpCisJCWJhc2lj
X21hY2hpbmU9YXJtZWwtdW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhh
biBgdW5rbm93bicKKwkjIGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJl
LCBhbmQKKwkjICgyKSB0aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5p
bmcgdXNlcnMuCisJaSo4NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hp
bmUtcGMKKwkgIDs7CisJIyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29y
ZC4KKwkqLSotKikKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5l
IFxgJGJhc2ljX21hY2hpbmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7Owor
CSMgUmVjb2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgw
LSogXAorCXwgYTI5ay0qIFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1
Ni0qIHwgYWxwaGFldjZbNzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8
IGFscGhhNjRldjU2LSogfCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8
IGFscGhhNjRwY2E1WzY3XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxl
LSogfCBhcm1lYi0qIHwgYXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmUzMi0q
IHwgYmU2NC0qIFwKKwl8IGJmaW4tKiB8IGJzMjAwMC0qIFwKKwl8IGNbMTIzXSogfCBjMzAtKiB8
IFtjanRdOTAtKiB8IGM0eC0qIFwKKwl8IGNsaXBwZXItKiB8IGNyYXludi0qIHwgY3lkcmEtKiBc
CisJfCBkMTB2LSogfCBkMzB2LSogfCBkbHgtKiBcCisJfCBlbHhzaS0qIFwKKwl8IGYzMFswMV0t
KiB8IGY3MDAtKiB8IGZpZG8tKiB8IGZyMzAtKiB8IGZydi0qIHwgZng4MC0qIFwKKwl8IGg4MzAw
LSogfCBoODUwMC0qIFwKKwl8IGhwcGEtKiB8IGhwcGExLlswMV0tKiB8IGhwcGEyLjAtKiB8IGhw
cGEyLjBbbnddLSogfCBocHBhNjQtKiBcCisJfCBoZXhhZ29uLSogXAorCXwgaSo4Ni0qIHwgaTg2
MC0qIHwgaTk2MC0qIHwgaWE2NC0qIFwKKwl8IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxlMzIt
KiB8IGxlNjQtKiBcCisJfCBsbTMyLSogXAorCXwgbTMyYy0qIHwgbTMyci0qIHwgbTMycmxlLSog
XAorCXwgbTY4MDAwLSogfCBtNjgwWzAxMjM0Nl0wLSogfCBtNjgzNjAtKiB8IG02ODM/Mi0qIHwg
bTY4ay0qIFwKKwl8IG04ODExMC0qIHwgbTg4ay0qIHwgbWF4cS0qIHwgbWNvcmUtKiB8IG1ldGFn
LSogfCBtaWNyb2JsYXplLSogXAorCXwgbWlwcy0qIHwgbWlwc2JlLSogfCBtaXBzZWItKiB8IG1p
cHNlbC0qIHwgbWlwc2xlLSogXAorCXwgbWlwczE2LSogXAorCXwgbWlwczY0LSogfCBtaXBzNjRl
bC0qIFwKKwl8IG1pcHM2NG9jdGVvbi0qIHwgbWlwczY0b2N0ZW9uZWwtKiBcCisJfCBtaXBzNjRv
cmlvbi0qIHwgbWlwczY0b3Jpb25lbC0qIFwKKwl8IG1pcHM2NHI1OTAwLSogfCBtaXBzNjRyNTkw
MGVsLSogXAorCXwgbWlwczY0dnItKiB8IG1pcHM2NHZyZWwtKiBcCisJfCBtaXBzNjR2cjQxMDAt
KiB8IG1pcHM2NHZyNDEwMGVsLSogXAorCXwgbWlwczY0dnI0MzAwLSogfCBtaXBzNjR2cjQzMDBl
bC0qIFwKKwl8IG1pcHM2NHZyNTAwMC0qIHwgbWlwczY0dnI1MDAwZWwtKiBcCisJfCBtaXBzNjR2
cjU5MDAtKiB8IG1pcHM2NHZyNTkwMGVsLSogXAorCXwgbWlwc2lzYTMyLSogfCBtaXBzaXNhMzJl
bC0qIFwKKwl8IG1pcHNpc2EzMnIyLSogfCBtaXBzaXNhMzJyMmVsLSogXAorCXwgbWlwc2lzYTY0
LSogfCBtaXBzaXNhNjRlbC0qIFwKKwl8IG1pcHNpc2E2NHIyLSogfCBtaXBzaXNhNjRyMmVsLSog
XAorCXwgbWlwc2lzYTY0c2IxLSogfCBtaXBzaXNhNjRzYjFlbC0qIFwKKwl8IG1pcHNpc2E2NHNy
NzFrLSogfCBtaXBzaXNhNjRzcjcxa2VsLSogXAorCXwgbWlwc3R4MzktKiB8IG1pcHN0eDM5ZWwt
KiBcCisJfCBtbWl4LSogXAorCXwgbXQtKiBcCisJfCBtc3A0MzAtKiBcCisJfCBuZHMzMi0qIHwg
bmRzMzJsZS0qIHwgbmRzMzJiZS0qIFwKKwl8IG5pb3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0q
IHwgbnAxLSogfCBuczE2ay0qIHwgbnMzMmstKiBcCisJfCBvcGVuOC0qIFwKKwl8IG9yaW9uLSog
XAorCXwgcGRwMTAtKiB8IHBkcDExLSogfCBwai0qIHwgcGpsLSogfCBwbi0qIHwgcG93ZXItKiBc
CisJfCBwb3dlcnBjLSogfCBwb3dlcnBjNjQtKiB8IHBvd2VycGM2NGxlLSogfCBwb3dlcnBjbGUt
KiBcCisJfCBweXJhbWlkLSogXAorCXwgcmw3OC0qIHwgcm9tcC0qIHwgcnM2MDAwLSogfCByeC0q
IFwKKwl8IHNoLSogfCBzaFsxMjM0XS0qIHwgc2hbMjRdYS0qIHwgc2hbMjRdYWViLSogfCBzaFsy
M11lLSogfCBzaFszNF1lYi0qIHwgc2hlYi0qIHwgc2hiZS0qIFwKKwl8IHNobGUtKiB8IHNoWzEy
MzRdbGUtKiB8IHNoM2VsZS0qIHwgc2g2NC0qIHwgc2g2NGxlLSogXAorCXwgc3BhcmMtKiB8IHNw
YXJjNjQtKiB8IHNwYXJjNjRiLSogfCBzcGFyYzY0di0qIHwgc3BhcmM4NngtKiB8IHNwYXJjbGV0
LSogXAorCXwgc3BhcmNsaXRlLSogXAorCXwgc3BhcmN2OC0qIHwgc3BhcmN2OS0qIHwgc3BhcmN2
OWItKiB8IHNwYXJjdjl2LSogfCBzdjEtKiB8IHN4Py0qIFwKKwl8IHRhaG9lLSogXAorCXwgdGlj
MzAtKiB8IHRpYzR4LSogfCB0aWM1NHgtKiB8IHRpYzU1eC0qIHwgdGljNngtKiB8IHRpYzgwLSog
XAorCXwgdGlsZSotKiBcCisJfCB0cm9uLSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSog
fCB2ODUwZS0qIHwgdjg1MGUxLSogfCB2ODUwZXMtKiB8IHY4NTBlMi0qIHwgdjg1MGUydjMtKiBc
CisJfCB2YXgtKiBcCisJfCB3ZTMyay0qIFwKKwl8IHg4Ni0qIHwgeDg2XzY0LSogfCB4YzE2eC0q
IHwgeHBzMTAwLSogXAorCXwgeHN0b3JteTE2LSogfCB4dGVuc2EqLSogXAorCXwgeW1wLSogXAor
CXwgejhrLSogfCB6ODAtKikKKwkJOzsKKwkjIFJlY29nbml6ZSB0aGUgYmFzaWMgQ1BVIHR5cGVz
IHdpdGhvdXQgY29tcGFueSBuYW1lLCB3aXRoIGdsb2IgbWF0Y2guCisJeHRlbnNhKikKKwkJYmFz
aWNfbWFjaGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJIyBSZWNvZ25pemUgdGhl
IHZhcmlvdXMgbWFjaGluZSBuYW1lcyBhbmQgYWxpYXNlcyB3aGljaCBzdGFuZAorCSMgZm9yIGEg
Q1BVIHR5cGUgYW5kIGEgY29tcGFueSBhbmQgc29tZXRpbWVzIGV2ZW4gYW4gT1MuCisJMzg2YnNk
KQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tYnNkCisJCTs7CisJM2IxIHwg
NzMwMCB8IDczMDAtYXR0IHwgYXR0LTczMDAgfCBwYzczMDAgfCBzYWZhcmkgfCB1bml4cGMpCisJ
CWJhc2ljX21hY2hpbmU9bTY4MDAwLWF0dAorCQk7OworCTNiKikKKwkJYmFzaWNfbWFjaGluZT13
ZTMyay1hdHQKKwkJOzsKKwlhMjlraGlmKQorCQliYXNpY19tYWNoaW5lPWEyOWstYW1kCisJCW9z
PS11ZGkKKwkJOzsKKwlhYmFjdXMpCisJCWJhc2ljX21hY2hpbmU9YWJhY3VzLXVua25vd24KKwkJ
OzsKKwlhZG9iZTY4aykKKwkJYmFzaWNfbWFjaGluZT1tNjgwMTAtYWRvYmUKKwkJb3M9LXNjb3V0
CisJCTs7CisJYWxsaWFudCB8IGZ4ODApCisJCWJhc2ljX21hY2hpbmU9Zng4MC1hbGxpYW50CisJ
CTs7CisJYWx0b3MgfCBhbHRvczMwNjgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hbHRvcworCQk7
OworCWFtMjlrKQorCQliYXNpY19tYWNoaW5lPWEyOWstbm9uZQorCQlvcz0tYnNkCisJCTs7CisJ
YW1kNjQpCisJCWJhc2ljX21hY2hpbmU9eDg2XzY0LXBjCisJCTs7CisJYW1kNjQtKikKKwkJYmFz
aWNfbWFjaGluZT14ODZfNjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJOzsKKwlhbWRhaGwpCisJCWJhc2ljX21hY2hpbmU9NTgwLWFtZGFobAorCQlvcz0tc3lz
dgorCQk7OworCWFtaWdhIHwgYW1pZ2EtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXVua25vd24K
KwkJOzsKKwlhbWlnYW9zIHwgYW1pZ2Fkb3MpCisJCWJhc2ljX21hY2hpbmU9bTY4ay11bmtub3du
CisJCW9zPS1hbWlnYW9zCisJCTs7CisJYW1pZ2F1bml4IHwgYW1peCkKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLXVua25vd24KKwkJb3M9LXN5c3Y0CisJCTs7CisJYXBvbGxvNjgpCisJCWJhc2ljX21h
Y2hpbmU9bTY4ay1hcG9sbG8KKwkJb3M9LXN5c3YKKwkJOzsKKwlhcG9sbG82OGJzZCkKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLWFwb2xsbworCQlvcz0tYnNkCisJCTs7CisJYXJvcykKKwkJYmFzaWNf
bWFjaGluZT1pMzg2LXBjCisJCW9zPS1hcm9zCisJCTs7CisJYXV4KQorCQliYXNpY19tYWNoaW5l
PW02OGstYXBwbGUKKwkJb3M9LWF1eAorCQk7OworCWJhbGFuY2UpCisJCWJhc2ljX21hY2hpbmU9
bnMzMmstc2VxdWVudAorCQlvcz0tZHluaXgKKwkJOzsKKwlibGFja2ZpbikKKwkJYmFzaWNfbWFj
aGluZT1iZmluLXVua25vd24KKwkJb3M9LWxpbnV4CisJCTs7CisJYmxhY2tmaW4tKikKKwkJYmFz
aWNfbWFjaGluZT1iZmluLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydg
CisJCW9zPS1saW51eAorCQk7OworCWJsdWVnZW5lKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBj
LWlibQorCQlvcz0tY25rCisJCTs7CisJYzU0eC0qKQorCQliYXNpY19tYWNoaW5lPXRpYzU0eC1g
ZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM1NXgtKikK
KwkJYmFzaWNfbWFjaGluZT10aWM1NXgtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlte
LV0qLS8vJ2AKKwkJOzsKKwljNngtKikKKwkJYmFzaWNfbWFjaGluZT10aWM2eC1gZWNobyAkYmFz
aWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM5MCkKKwkJYmFzaWNfbWFj
aGluZT1jOTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY2VnY2MpCisJCWJhc2ljX21hY2hp
bmU9YXJtLXVua25vd24KKwkJb3M9LWNlZ2NjCisJCTs7CisJY29udmV4LWMxKQorCQliYXNpY19t
YWNoaW5lPWMxLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMyKQorCQliYXNpY19t
YWNoaW5lPWMyLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMzMikKKwkJYmFzaWNf
bWFjaGluZT1jMzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzM0KQorCQliYXNp
Y19tYWNoaW5lPWMzNC1jb252ZXgKKwkJb3M9LWJzZAorCQk7OworCWNvbnZleC1jMzgpCisJCWJh
c2ljX21hY2hpbmU9YzM4LWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY3JheSB8IGo5MCkKKwkJ
YmFzaWNfbWFjaGluZT1qOTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY3JheW52KQorCQli
YXNpY19tYWNoaW5lPWNyYXludi1jcmF5CisJCW9zPS11bmljb3NtcAorCQk7OworCWNyMTYgfCBj
cjE2LSopCisJCWJhc2ljX21hY2hpbmU9Y3IxNi11bmtub3duCisJCW9zPS1lbGYKKwkJOzsKKwlj
cmRzIHwgdW5vcykKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWNyZHMKKwkJOzsKKwljcmlzdjMyIHwg
Y3Jpc3YzMi0qIHwgZXRyYXhmcyopCisJCWJhc2ljX21hY2hpbmU9Y3Jpc3YzMi1heGlzCisJCTs7
CisJY3JpcyB8IGNyaXMtKiB8IGV0cmF4KikKKwkJYmFzaWNfbWFjaGluZT1jcmlzLWF4aXMKKwkJ
OzsKKwljcngpCisJCWJhc2ljX21hY2hpbmU9Y3J4LXVua25vd24KKwkJb3M9LWVsZgorCQk7Owor
CWRhMzAgfCBkYTMwLSopCisJCWJhc2ljX21hY2hpbmU9bTY4ay1kYTMwCisJCTs7CisJZGVjc3Rh
dGlvbiB8IGRlY3N0YXRpb24tMzEwMCB8IHBtYXggfCBwbWF4LSogfCBwbWluIHwgZGVjMzEwMCB8
IGRlY3N0YXRuKQorCQliYXNpY19tYWNoaW5lPW1pcHMtZGVjCisJCTs7CisJZGVjc3lzdGVtMTAq
IHwgZGVjMTAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlvcz0tdG9wczEwCisJCTs7
CisJZGVjc3lzdGVtMjAqIHwgZGVjMjAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlv
cz0tdG9wczIwCisJCTs7CisJZGVsdGEgfCAzMzAwIHwgbW90b3JvbGEtMzMwMCB8IG1vdG9yb2xh
LWRlbHRhIFwKKwkgICAgICB8IDMzMDAtbW90b3JvbGEgfCBkZWx0YS1tb3Rvcm9sYSkKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLW1vdG9yb2xhCisJCTs7CisJZGVsdGE4OCkKKwkJYmFzaWNfbWFjaGlu
ZT1tODhrLW1vdG9yb2xhCisJCW9zPS1zeXN2MworCQk7OworCWRpY29zKQorCQliYXNpY19tYWNo
aW5lPWk2ODYtcGMKKwkJb3M9LWRpY29zCisJCTs7CisJZGpncHApCisJCWJhc2ljX21hY2hpbmU9
aTU4Ni1wYworCQlvcz0tbXNkb3NkamdwcAorCQk7OworCWRweDIwIHwgZHB4MjAtKikKKwkJYmFz
aWNfbWFjaGluZT1yczYwMDAtYnVsbAorCQlvcz0tYm9zeAorCQk7OworCWRweDIqIHwgZHB4Miot
YnVsbCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWJ1bGwKKwkJb3M9LXN5c3YzCisJCTs7CisJZWJt
b24yOWspCisJCWJhc2ljX21hY2hpbmU9YTI5ay1hbWQKKwkJb3M9LWVibW9uCisJCTs7CisJZWx4
c2kpCisJCWJhc2ljX21hY2hpbmU9ZWx4c2ktZWx4c2kKKwkJb3M9LWJzZAorCQk7OworCWVuY29y
ZSB8IHVtYXggfCBtbWF4KQorCQliYXNpY19tYWNoaW5lPW5zMzJrLWVuY29yZQorCQk7OworCWVz
MTgwMCB8IE9TRTY4ayB8IG9zZTY4ayB8IG9zZSB8IE9TRSkKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LWVyaWNzc29uCisJCW9zPS1vc2UKKwkJOzsKKwlmeDI4MDApCisJCWJhc2ljX21hY2hpbmU9aTg2
MC1hbGxpYW50CisJCTs7CisJZ2VuaXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstbnMKKwkJOzsK
KwlnbWljcm8pCisJCWJhc2ljX21hY2hpbmU9dHJvbi1nbWljcm8KKwkJb3M9LXN5c3YKKwkJOzsK
KwlnbzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWdvMzIKKwkJOzsKKwloMzA1
MHIqIHwgaGl1eCopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRhY2hpCisJCW9zPS1oaXV4
d2UyCisJCTs7CisJaDgzMDBobXMpCisJCWJhc2ljX21hY2hpbmU9aDgzMDAtaGl0YWNoaQorCQlv
cz0taG1zCisJCTs7CisJaDgzMDB4cmF5KQorCQliYXNpY19tYWNoaW5lPWg4MzAwLWhpdGFjaGkK
KwkJb3M9LXhyYXkKKwkJOzsKKwloODUwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODUwMC1oaXRh
Y2hpCisJCW9zPS1obXMKKwkJOzsKKwloYXJyaXMpCisJCWJhc2ljX21hY2hpbmU9bTg4ay1oYXJy
aXMKKwkJb3M9LXN5c3YzCisJCTs7CisJaHAzMDAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhw
CisJCTs7CisJaHAzMDBic2QpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlvcz0tYnNkCisJ
CTs7CisJaHAzMDBocHV4KQorCQliYXNpY19tYWNoaW5lPW02OGstaHAKKwkJb3M9LWhwdXgKKwkJ
OzsKKwlocDNrOVswLTldWzAtOV0gfCBocDlbMC05XVswLTldKQorCQliYXNpY19tYWNoaW5lPWhw
cGExLjAtaHAKKwkJOzsKKwlocDlrMlswLTldWzAtOV0gfCBocDlrMzFbMC05XSkKKwkJYmFzaWNf
bWFjaGluZT1tNjgwMDAtaHAKKwkJOzsKKwlocDlrM1syLTldWzAtOV0pCisJCWJhc2ljX21hY2hp
bmU9bTY4ay1ocAorCQk7OworCWhwOWs2WzAtOV1bMC05XSB8IGhwNlswLTldWzAtOV0pCisJCWJh
c2ljX21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwOWs3WzAtNzldWzAtOV0gfCBocDdbMC03
OV1bMC05XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azc4WzAtOV0g
fCBocDc4WzAtOV0pCisJCSMgRklYTUU6IHJlYWxseSBocHBhMi4wLWhwCisJCWJhc2ljX21hY2hp
bmU9aHBwYTEuMS1ocAorCQk7OworCWhwOWs4WzY3XTEgfCBocDhbNjddMSB8IGhwOWs4MFsyNF0g
fCBocDgwWzI0XSB8IGhwOWs4Wzc4XTkgfCBocDhbNzhdOSB8IGhwOWs4OTMgfCBocDg5MykKKwkJ
IyBGSVhNRTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJ
CTs7CisJaHA5azhbMC05XVsxMzY3OV0gfCBocDhbMC05XVsxMzY3OV0pCisJCWJhc2ljX21hY2hp
bmU9aHBwYTEuMS1ocAorCQk7OworCWhwOWs4WzAtOV1bMC05XSB8IGhwOFswLTldWzAtOV0pCisJ
CWJhc2ljX21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwcGEtbmV4dCkKKwkJb3M9LW5leHRz
dGVwMworCQk7OworCWhwcGFvc2YpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0t
b3NmCisJCTs7CisJaHBwcm8pCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0tcHJv
ZWxmCisJCTs7CisJaTM3MC1pYm0qIHwgaWJtKikKKwkJYmFzaWNfbWFjaGluZT1pMzcwLWlibQor
CQk7OworIyBJJ20gbm90IHN1cmUgd2hhdCAiU3lzdjMyIiBtZWFucy4gIFNob3VsZCB0aGlzIGJl
IHN5c3YzLjI/CisJaSo4NnYzMikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAn
cy84Ni4qLzg2LXBjLydgCisJCW9zPS1zeXN2MzIKKwkJOzsKKwlpKjg2djQqKQorCQliYXNpY19t
YWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXN5c3Y0CisJ
CTs7CisJaSo4NnYpCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84
Ni1wYy8nYAorCQlvcz0tc3lzdgorCQk7OworCWkqODZzb2wyKQorCQliYXNpY19tYWNoaW5lPWBl
Y2hvICQxIHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXNvbGFyaXMyCisJCTs7CisJ
aTM4Nm1hY2gpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1tYWNoCisJCW9zPS1tYWNoCisJCTs7CisJ
aTM4Ni12c3RhIHwgdnN0YSkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJb3M9LXZz
dGEKKwkJOzsKKwlpcmlzIHwgaXJpczRkKQorCQliYXNpY19tYWNoaW5lPW1pcHMtc2dpCisJCWNh
c2UgJG9zIGluCisJCSAgICAtaXJpeCopCisJCQk7OworCQkgICAgKikKKwkJCW9zPS1pcml4NAor
CQkJOzsKKwkJZXNhYworCQk7OworCWlzaTY4IHwgaXNpKQorCQliYXNpY19tYWNoaW5lPW02OGst
aXNpCisJCW9zPS1zeXN2CisJCTs7CisJbTY4a25vbW11KQorCQliYXNpY19tYWNoaW5lPW02OGst
dW5rbm93bgorCQlvcz0tbGludXgKKwkJOzsKKwltNjhrbm9tbXUtKikKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9zPS1s
aW51eAorCQk7OworCW04OGstb21yb24qKQorCQliYXNpY19tYWNoaW5lPW04OGstb21yb24KKwkJ
OzsKKwltYWdudW0gfCBtMzIzMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLW1pcHMKKwkJb3M9LXN5
c3YKKwkJOzsKKwltZXJsaW4pCisJCWJhc2ljX21hY2hpbmU9bnMzMmstdXRlaworCQlvcz0tc3lz
dgorCQk7OworCW1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9bWljcm9ibGF6ZS14aWxpbngK
KwkJOzsKKwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LW1pbmd3MzIK
KwkJOzsKKwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJtLXVua25vd24KKwkJb3M9LW1p
bmd3MzJjZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtY29udmVy
Z2VudAorCQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlOVCB8ICpNaU5UWzAtOV0qKQor
CQliYXNpY19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQKKwkJOzsKKwltaXBzMyotKikK
KwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAtZSAncy9taXBzMy9t
aXBzNjQvJ2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2ljX21h
Y2hpbmUgfCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25vd24KKwkJOzsKKwltb25pdG9y
KQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJbW9ycGhv
cykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJb3M9LW1vcnBob3MKKwkJOzsK
Kwltc2RvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc2RvcworCQk7OworCW1z
MS0qKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkIC1lICdzL21z
MS0vbXQtLydgCisJCTs7CisJbXN5cykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1t
c3lzCisJCTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCW9zPS1tdnMKKwkJ
OzsKKwluYWNsKQorCQliYXNpY19tYWNoaW5lPWxlMzItdW5rbm93bgorCQlvcz0tbmFjbAorCQk7
OworCW5jcjMwMDApCisJCWJhc2ljX21hY2hpbmU9aTQ4Ni1uY3IKKwkJb3M9LXN5c3Y0CisJCTs7
CisJbmV0YnNkMzg2KQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tbmV0YnNk
CisJCTs7CisJbmV0d2luZGVyKQorCQliYXNpY19tYWNoaW5lPWFybXY0bC1yZWJlbAorCQlvcz0t
bGludXgKKwkJOzsKKwluZXdzIHwgbmV3czcwMCB8IG5ld3M4MDAgfCBuZXdzOTAwKQorCQliYXNp
Y19tYWNoaW5lPW02OGstc29ueQorCQlvcz0tbmV3c29zCisJCTs7CisJbmV3czEwMDApCisJCWJh
c2ljX21hY2hpbmU9bTY4MDMwLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5ld3MtMzYwMCB8
IHJpc2MtbmV3cykKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7
OworCW5lY3Y3MCkKKwkJYmFzaWNfbWFjaGluZT12NzAtbmVjCisJCW9zPS1zeXN2CisJCTs7CisJ
bmV4dCB8IG0qLW5leHQgKQorCQliYXNpY19tYWNoaW5lPW02OGstbmV4dAorCQljYXNlICRvcyBp
bgorCQkgICAgLW5leHRzdGVwKiApCisJCQk7OworCQkgICAgLW5zMiopCisJCSAgICAgIG9zPS1u
ZXh0c3RlcDIKKwkJCTs7CisJCSAgICAqKQorCQkgICAgICBvcz0tbmV4dHN0ZXAzCisJCQk7Owor
CQllc2FjCisJCTs7CisJbmgzMDAwKQorCQliYXNpY19tYWNoaW5lPW02OGstaGFycmlzCisJCW9z
PS1jeHV4CisJCTs7CisJbmhbNDVdMDAwKQorCQliYXNpY19tYWNoaW5lPW04OGstaGFycmlzCisJ
CW9zPS1jeHV4CisJCTs7CisJbmluZHk5NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAor
CQlvcz0tbmluZHkKKwkJOzsKKwltb245NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAor
CQlvcz0tbW9uOTYwCisJCTs7CisJbm9uc3RvcHV4KQorCQliYXNpY19tYWNoaW5lPW1pcHMtY29t
cGFxCisJCW9zPS1ub25zdG9wdXgKKwkJOzsKKwlucDEpCisJCWJhc2ljX21hY2hpbmU9bnAxLWdv
dWxkCisJCTs7CisJbmVvLXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uZW8tdGFuZGVtCisJCTs7
CisJbnNlLXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uc2UtdGFuZGVtCisJCTs7CisJbnNyLXRh
bmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uc3ItdGFuZGVtCisJCTs7CisJb3A1MG4tKiB8IG9wNjBj
LSopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJb3M9LXByb2VsZgorCQk7OworCW9w
ZW5yaXNjIHwgb3BlbnJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1vcjMyLXVua25vd24KKwkJOzsK
KwlvczQwMCkKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWlibQorCQlvcz0tb3M0MDAKKwkJOzsK
KwlPU0U2ODAwMCB8IG9zZTY4MDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1lcmljc3Nvbgor
CQlvcz0tb3NlCisJCTs7CisJb3M2OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ub25lCisJCW9z
PS1vczY4aworCQk7OworCXBhLWhpdGFjaGkpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRh
Y2hpCisJCW9zPS1oaXV4d2UyCisJCTs7CisJcGFyYWdvbikKKwkJYmFzaWNfbWFjaGluZT1pODYw
LWludGVsCisJCW9zPS1vc2YKKwkJOzsKKwlwYXJpc2MpCisJCWJhc2ljX21hY2hpbmU9aHBwYS11
bmtub3duCisJCW9zPS1saW51eAorCQk7OworCXBhcmlzYy0qKQorCQliYXNpY19tYWNoaW5lPWhw
cGEtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4
CisJCTs7CisJcGJkKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXR0aQorCQk7OworCXBiYikKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLXR0aQorCQk7OworCXBjNTMyIHwgcGM1MzItKikKKwkJYmFzaWNf
bWFjaGluZT1uczMyay1wYzUzMgorCQk7OworCXBjOTgpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1w
YworCQk7OworCXBjOTgtKikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LWBlY2hvICRiYXNpY19tYWNo
aW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcGVudGl1bSB8IHA1IHwgazUgfCBrNiB8
IG5leGdlbiB8IHZpYWMzKQorCQliYXNpY19tYWNoaW5lPWk1ODYtcGMKKwkJOzsKKwlwZW50aXVt
cHJvIHwgcDYgfCA2eDg2IHwgYXRobG9uIHwgYXRobG9uXyopCisJCWJhc2ljX21hY2hpbmU9aTY4
Ni1wYworCQk7OworCXBlbnRpdW1paSB8IHBlbnRpdW0yIHwgcGVudGl1bWlpaSB8IHBlbnRpdW0z
KQorCQliYXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlwZW50aXVtNCkKKwkJYmFzaWNfbWFj
aGluZT1pNzg2LXBjCisJCTs7CisJcGVudGl1bS0qIHwgcDUtKiB8IGs1LSogfCBrNi0qIHwgbmV4
Z2VuLSogfCB2aWFjMy0qKQorCQliYXNpY19tYWNoaW5lPWk1ODYtYGVjaG8gJGJhc2ljX21hY2hp
bmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtcHJvLSogfCBwNi0qIHwgNng4
Ni0qIHwgYXRobG9uLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAkYmFzaWNfbWFjaGlu
ZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW1paS0qIHwgcGVudGl1bTItKiB8
IHBlbnRpdW1paWktKiB8IHBlbnRpdW0zLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAk
YmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW00LSopCisJ
CWJhc2ljX21hY2hpbmU9aTc4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSot
Ly8nYAorCQk7OworCXBuKQorCQliYXNpY19tYWNoaW5lPXBuLWdvdWxkCisJCTs7CisJcG93ZXIp
CWJhc2ljX21hY2hpbmU9cG93ZXItaWJtCisJCTs7CisJcHBjIHwgcHBjYmUpCWJhc2ljX21hY2hp
bmU9cG93ZXJwYy11bmtub3duCisJCTs7CisJcHBjLSogfCBwcGNiZS0qKQorCQliYXNpY19tYWNo
aW5lPXBvd2VycGMtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJ
OzsKKwlwcGNsZSB8IHBvd2VycGNsaXR0bGUgfCBwcGMtbGUgfCBwb3dlcnBjLWxpdHRsZSkKKwkJ
YmFzaWNfbWFjaGluZT1wb3dlcnBjbGUtdW5rbm93bgorCQk7OworCXBwY2xlLSogfCBwb3dlcnBj
bGl0dGxlLSopCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLWBlY2hvICRiYXNpY19tYWNoaW5l
IHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcHBjNjQpCWJhc2ljX21hY2hpbmU9cG93ZXJw
YzY0LXVua25vd24KKwkJOzsKKwlwcGM2NC0qKSBiYXNpY19tYWNoaW5lPXBvd2VycGM2NC1gZWNo
byAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0bGUgfCBw
b3dlcnBjNjRsaXR0bGUgfCBwcGM2NC1sZSB8IHBvd2VycGM2NC1saXR0bGUpCisJCWJhc2ljX21h
Y2hpbmU9cG93ZXJwYzY0bGUtdW5rbm93bgorCQk7OworCXBwYzY0bGUtKiB8IHBvd2VycGM2NGxp
dHRsZS0qKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLWBlY2hvICRiYXNpY19tYWNoaW5l
IHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcHMyKQorCQliYXNpY19tYWNoaW5lPWkzODYt
aWJtCisJCTs7CisJcHczMikKKwkJYmFzaWNfbWFjaGluZT1pNTg2LXVua25vd24KKwkJb3M9LXB3
MzIKKwkJOzsKKwlyZG9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LXJkb3MKKwkJ
OzsKKwlyb202OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1yb202OGsKKwkJb3M9LWNvZmYKKwkJ
OzsKKwlybVs0Nl0wMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNpZW1lbnMKKwkJOzsKKwlydHBj
IHwgcnRwYy0qKQorCQliYXNpY19tYWNoaW5lPXJvbXAtaWJtCisJCTs7CisJczM5MCB8IHMzOTAt
KikKKwkJYmFzaWNfbWFjaGluZT1zMzkwLWlibQorCQk7OworCXMzOTB4IHwgczM5MHgtKikKKwkJ
YmFzaWNfbWFjaGluZT1zMzkweC1pYm0KKwkJOzsKKwlzYTI5MjAwKQorCQliYXNpY19tYWNoaW5l
PWEyOWstYW1kCisJCW9zPS11ZGkKKwkJOzsKKwlzYjEpCisJCWJhc2ljX21hY2hpbmU9bWlwc2lz
YTY0c2IxLXVua25vd24KKwkJOzsKKwlzYjFlbCkKKwkJYmFzaWNfbWFjaGluZT1taXBzaXNhNjRz
YjFlbC11bmtub3duCisJCTs7CisJc2RlKQorCQliYXNpY19tYWNoaW5lPW1pcHNpc2EzMi1zZGUK
KwkJb3M9LWVsZgorCQk7OworCXNlaSkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNlaQorCQlvcz0t
c2VpdXgKKwkJOzsKKwlzZXF1ZW50KQorCQliYXNpY19tYWNoaW5lPWkzODYtc2VxdWVudAorCQk7
OworCXNoKQorCQliYXNpY19tYWNoaW5lPXNoLWhpdGFjaGkKKwkJb3M9LWhtcworCQk7OworCXNo
NWVsKQorCQliYXNpY19tYWNoaW5lPXNoNWxlLXVua25vd24KKwkJOzsKKwlzaDY0KQorCQliYXNp
Y19tYWNoaW5lPXNoNjQtdW5rbm93bgorCQk7OworCXNwYXJjbGl0ZS13cnMgfCBzaW1zby13cnMp
CisJCWJhc2ljX21hY2hpbmU9c3BhcmNsaXRlLXdycworCQlvcz0tdnh3b3JrcworCQk7OworCXNw
czcpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1idWxsCisJCW9zPS1zeXN2MgorCQk7OworCXNwdXIp
CisJCWJhc2ljX21hY2hpbmU9c3B1ci11bmtub3duCisJCTs7CisJc3QyMDAwKQorCQliYXNpY19t
YWNoaW5lPW02OGstdGFuZGVtCisJCTs7CisJc3RyYXR1cykKKwkJYmFzaWNfbWFjaGluZT1pODYw
LXN0cmF0dXMKKwkJb3M9LXN5c3Y0CisJCTs7CisJc3Ryb25nYXJtLSogfCB0aHVtYi0qKQorCQli
YXNpY19tYWNoaW5lPWFybS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8n
YAorCQk7OworCXN1bjIpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJv
czMpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3Vu
Mm9zNCkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlz
dW4zb3MzKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlz
dW4zb3M0KQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlz
dW40b3MzKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJ
c3VuNG9zNCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7Owor
CXN1bjRzb2wyKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJ
OzsKKwlzdW4zIHwgc3VuMy0qKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCTs7CisJc3Vu
NCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwg
cm9hZHJ1bm5lcikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFz
aWNfbWFjaGluZT1zdjEtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJh
c2ljX21hY2hpbmU9aTM4Ni1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCXQzZSkKKwkJYmFz
aWNfbWFjaGluZT1hbHBoYWV2NS1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJh
c2ljX21hY2hpbmU9dDkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworCXRpbGUqKQorCQliYXNp
Y19tYWNoaW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9LWxpbnV4LWdudQorCQk7Owor
CXR4MzkpCisJCWJhc2ljX21hY2hpbmU9bWlwc3R4MzktdW5rbm93bgorCQk7OworCXR4MzllbCkK
KwkJYmFzaWNfbWFjaGluZT1taXBzdHgzOWVsLXVua25vd24KKwkJOzsKKwl0b2FkMSkKKwkJYmFz
aWNfbWFjaGluZT1wZHAxMC14a2wKKwkJb3M9LXRvcHMyMAorCQk7OworCXRvd2VyIHwgdG93ZXIt
MzIpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1uY3IKKwkJOzsKKwl0cGYpCisJCWJhc2ljX21hY2hp
bmU9czM5MHgtaWJtCisJCW9zPS10cGYKKwkJOzsKKwl1ZGkyOWspCisJCWJhc2ljX21hY2hpbmU9
YTI5ay1hbWQKKwkJb3M9LXVkaQorCQk7OworCXVsdHJhMykKKwkJYmFzaWNfbWFjaGluZT1hMjlr
LW55dQorCQlvcz0tc3ltMQorCQk7OworCXY4MTAgfCBuZWN2ODEwKQorCQliYXNpY19tYWNoaW5l
PXY4MTAtbmVjCisJCW9zPS1ub25lCisJCTs7CisJdmF4dikKKwkJYmFzaWNfbWFjaGluZT12YXgt
ZGVjCisJCW9zPS1zeXN2CisJCTs7CisJdm1zKQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJ
b3M9LXZtcworCQk7OworCXZwcCp8dnh8dngtKikKKwkJYmFzaWNfbWFjaGluZT1mMzAxLWZ1aml0
c3UKKwkJOzsKKwl2eHdvcmtzOTYwKQorCQliYXNpY19tYWNoaW5lPWk5NjAtd3JzCisJCW9zPS12
eHdvcmtzCisJCTs7CisJdnh3b3JrczY4KQorCQliYXNpY19tYWNoaW5lPW02OGstd3JzCisJCW9z
PS12eHdvcmtzCisJCTs7CisJdnh3b3JrczI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLXdycwor
CQlvcz0tdnh3b3JrcworCQk7OworCXc2NSopCisJCWJhc2ljX21hY2hpbmU9dzY1LXdkYworCQlv
cz0tbm9uZQorCQk7OworCXc4OWstKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLXdpbmJvbmQK
KwkJb3M9LXByb2VsZgorCQk7OworCXhib3gpCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1wYworCQlv
cz0tbWluZ3czMgorCQk7OworCXhwcyB8IHhwczEwMCkKKwkJYmFzaWNfbWFjaGluZT14cHMxMDAt
aG9uZXl3ZWxsCisJCTs7CisJeHNjYWxlLSogfCB4c2NhbGVlW2JsXS0qKQorCQliYXNpY19tYWNo
aW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL154c2NhbGUvYXJtLydgCisJCTs7CisJ
eW1wKQorCQliYXNpY19tYWNoaW5lPXltcC1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl6OGst
Ki1jb2ZmKQorCQliYXNpY19tYWNoaW5lPXo4ay11bmtub3duCisJCW9zPS1zaW0KKwkJOzsKKwl6
ODAtKi1jb2ZmKQorCQliYXNpY19tYWNoaW5lPXo4MC11bmtub3duCisJCW9zPS1zaW0KKwkJOzsK
Kwlub25lKQorCQliYXNpY19tYWNoaW5lPW5vbmUtbm9uZQorCQlvcz0tbm9uZQorCQk7OworCisj
IEhlcmUgd2UgaGFuZGxlIHRoZSBkZWZhdWx0IG1hbnVmYWN0dXJlciBvZiBjZXJ0YWluIENQVSB0
eXBlcy4gIEl0IGlzIGluCisjIHNvbWUgY2FzZXMgdGhlIG9ubHkgbWFudWZhY3R1cmVyLCBpbiBv
dGhlcnMsIGl0IGlzIHRoZSBtb3N0IHBvcHVsYXIuCisJdzg5aykKKwkJYmFzaWNfbWFjaGluZT1o
cHBhMS4xLXdpbmJvbmQKKwkJOzsKKwlvcDUwbikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLW9r
aQorCQk7OworCW9wNjBjKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtb2tpCisJCTs7CisJcm9t
cCkKKwkJYmFzaWNfbWFjaGluZT1yb21wLWlibQorCQk7OworCW1taXgpCisJCWJhc2ljX21hY2hp
bmU9bW1peC1rbnV0aAorCQk7OworCXJzNjAwMCkKKwkJYmFzaWNfbWFjaGluZT1yczYwMDAtaWJt
CisJCTs7CisJdmF4KQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJOzsKKwlwZHAxMCkKKwkJ
IyB0aGVyZSBhcmUgbWFueSBjbG9uZXMsIHNvIERFQyBpcyBub3QgYSBzYWZlIGJldAorCQliYXNp
Y19tYWNoaW5lPXBkcDEwLXVua25vd24KKwkJOzsKKwlwZHAxMSkKKwkJYmFzaWNfbWFjaGluZT1w
ZHAxMS1kZWMKKwkJOzsKKwl3ZTMyaykKKwkJYmFzaWNfbWFjaGluZT13ZTMyay1hdHQKKwkJOzsK
KwlzaFsxMjM0XSB8IHNoWzI0XWEgfCBzaFsyNF1hZWIgfCBzaFszNF1lYiB8IHNoWzEyMzRdbGUg
fCBzaFsyM11lbGUpCisJCWJhc2ljX21hY2hpbmU9c2gtdW5rbm93bgorCQk7OworCXNwYXJjIHwg
c3BhcmN2OCB8IHNwYXJjdjkgfCBzcGFyY3Y5YiB8IHNwYXJjdjl2KQorCQliYXNpY19tYWNoaW5l
PXNwYXJjLXN1bgorCQk7OworCWN5ZHJhKQorCQliYXNpY19tYWNoaW5lPWN5ZHJhLWN5ZHJvbWUK
KwkJOzsKKwlvcmlvbikKKwkJYmFzaWNfbWFjaGluZT1vcmlvbi1oaWdobGV2ZWwKKwkJOzsKKwlv
cmlvbjEwNSkKKwkJYmFzaWNfbWFjaGluZT1jbGlwcGVyLWhpZ2hsZXZlbAorCQk7OworCW1hYyB8
IG1wdyB8IG1hYy1tcHcpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQk7OworCXBtYWMg
fCBwbWFjLW1wdykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWFwcGxlCisJCTs7CisJKi11bmtu
b3duKQorCQkjIE1ha2Ugc3VyZSB0byBtYXRjaCBhbiBhbHJlYWR5LWNhbm9uaWNhbGl6ZWQgbWFj
aGluZSBuYW1lLgorCQk7OworCSopCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFc
JzogbWFjaGluZSBcYCRiYXNpY19tYWNoaW5lXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0
IDEKKwkJOzsKK2VzYWMKKworIyBIZXJlIHdlIGNhbm9uaWNhbGl6ZSBjZXJ0YWluIGFsaWFzZXMg
Zm9yIG1hbnVmYWN0dXJlcnMuCitjYXNlICRiYXNpY19tYWNoaW5lIGluCisJKi1kaWdpdGFsKikK
KwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9kaWdpdGFsLiov
ZGVjLydgCisJCTs7CisJKi1jb21tb2RvcmUqKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNp
Y19tYWNoaW5lIHwgc2VkICdzL2NvbW1vZG9yZS4qL2NibS8nYAorCQk7OworCSopCisJCTs7Citl
c2FjCisKKyMgRGVjb2RlIG1hbnVmYWN0dXJlci1zcGVjaWZpYyBhbGlhc2VzIGZvciBjZXJ0YWlu
IG9wZXJhdGluZyBzeXN0ZW1zLgorCitpZiBbIHgiJG9zIiAhPSB4IiIgXQordGhlbgorY2FzZSAk
b3MgaW4KKwkjIEZpcnN0IG1hdGNoIHNvbWUgc3lzdGVtIHR5cGUgYWxpYXNlcworCSMgdGhhdCBt
aWdodCBnZXQgY29uZnVzZWQgd2l0aCB2YWxpZCBzeXN0ZW0gdHlwZXMuCisJIyAtc29sYXJpcyog
aXMgYSBiYXNpYyBzeXN0ZW0gdHlwZSwgd2l0aCB0aGlzIG9uZSBleGNlcHRpb24uCisJLWF1cm9y
YXV4KQorCQlvcz0tYXVyb3JhdXgKKwkJOzsKKwktc29sYXJpczEgfCAtc29sYXJpczEuKikKKwkJ
b3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHNvbGFyaXMxfHN1bm9zNHwnYAorCQk7OworCS1zb2xh
cmlzKQorCQlvcz0tc29sYXJpczIKKwkJOzsKKwktc3ZyNCopCisJCW9zPS1zeXN2NAorCQk7Owor
CS11bml4d2FyZSopCisJCW9zPS1zeXN2NC4ydXcKKwkJOzsKKwktZ251L2xpbnV4KikKKwkJb3M9
YGVjaG8gJG9zIHwgc2VkIC1lICdzfGdudS9saW51eHxsaW51eC1nbnV8J2AKKwkJOzsKKwkjIEZp
cnN0IGFjY2VwdCB0aGUgYmFzaWMgc3lzdGVtIHR5cGVzLgorCSMgVGhlIHBvcnRhYmxlIHN5c3Rl
bXMgY29tZXMgZmlyc3QuCisJIyBFYWNoIGFsdGVybmF0aXZlIE1VU1QgRU5EIElOIEEgKiwgdG8g
bWF0Y2ggYSB2ZXJzaW9uIG51bWJlci4KKwkjIC1zeXN2KiBpcyBub3QgaGVyZSBiZWNhdXNlIGl0
IGNvbWVzIGxhdGVyLCBhZnRlciBzeXN2cjQuCisJLWdudSogfCAtYnNkKiB8IC1tYWNoKiB8IC1t
aW5peCogfCAtZ2VuaXgqIHwgLXVsdHJpeCogfCAtaXJpeCogXAorCSAgICAgIHwgLSp2bXMqIHwg
LXNjbyogfCAtZXNpeCogfCAtaXNjKiB8IC1haXgqIHwgLWNuayogfCAtc3Vub3MgfCAtc3Vub3Nb
MzRdKlwKKwkgICAgICB8IC1ocHV4KiB8IC11bm9zKiB8IC1vc2YqIHwgLWx1bmEqIHwgLWRndXgq
IHwgLWF1cm9yYXV4KiB8IC1zb2xhcmlzKiBcCisJICAgICAgfCAtc3ltKiB8IC1rb3BlbnNvbGFy
aXMqIFwKKwkgICAgICB8IC1hbWlnYW9zKiB8IC1hbWlnYWRvcyogfCAtbXNkb3MqIHwgLW5ld3Nv
cyogfCAtdW5pY29zKiB8IC1hb2YqIFwKKwkgICAgICB8IC1hb3MqIHwgLWFyb3MqIFwKKwkgICAg
ICB8IC1uaW5keSogfCAtdnhzaW0qIHwgLXZ4d29ya3MqIHwgLWVibW9uKiB8IC1obXMqIHwgLW12
cyogXAorCSAgICAgIHwgLWNsaXgqIHwgLXJpc2NvcyogfCAtdW5pcGx1cyogfCAtaXJpcyogfCAt
cnR1KiB8IC14ZW5peCogXAorCSAgICAgIHwgLWhpdXgqIHwgLTM4NmJzZCogfCAta25ldGJzZCog
fCAtbWlyYnNkKiB8IC1uZXRic2QqIFwKKwkgICAgICB8IC1vcGVuYnNkKiB8IC1zb2xpZGJzZCog
XAorCSAgICAgIHwgLWVra29ic2QqIHwgLWtmcmVlYnNkKiB8IC1mcmVlYnNkKiB8IC1yaXNjaXgq
IHwgLWx5bnhvcyogXAorCSAgICAgIHwgLWJvc3gqIHwgLW5leHRzdGVwKiB8IC1jeHV4KiB8IC1h
b3V0KiB8IC1lbGYqIHwgLW9hYmkqIFwKKwkgICAgICB8IC1wdHgqIHwgLWNvZmYqIHwgLWVjb2Zm
KiB8IC13aW5udCogfCAtZG9tYWluKiB8IC12c3RhKiBcCisJICAgICAgfCAtdWRpKiB8IC1lYWJp
KiB8IC1saXRlcyogfCAtaWVlZSogfCAtZ28zMiogfCAtYXV4KiBcCisJICAgICAgfCAtY2hvcnVz
b3MqIHwgLWNob3J1c3JkYiogfCAtY2VnY2MqIFwKKwkgICAgICB8IC1jeWd3aW4qIHwgLW1zeXMq
IHwgLXBlKiB8IC1wc29zKiB8IC1tb3NzKiB8IC1wcm9lbGYqIHwgLXJ0ZW1zKiBcCisJICAgICAg
fCAtbWluZ3czMiogfCAtbGludXgtZ251KiB8IC1saW51eC1hbmRyb2lkKiBcCisJICAgICAgfCAt
bGludXgtbmV3bGliKiB8IC1saW51eC11Y2xpYmMqIFwKKwkgICAgICB8IC11eHB2KiB8IC1iZW9z
KiB8IC1tcGVpeCogfCAtdWRrKiBcCisJICAgICAgfCAtaW50ZXJpeCogfCAtdXdpbiogfCAtbWtz
KiB8IC1yaGFwc29keSogfCAtZGFyd2luKiB8IC1vcGVuZWQqIFwKKwkgICAgICB8IC1vcGVuc3Rl
cCogfCAtb3NraXQqIHwgLWNvbml4KiB8IC1wdzMyKiB8IC1ub25zdG9wdXgqIFwKKwkgICAgICB8
IC1zdG9ybS1jaGFvcyogfCAtdG9wczEwKiB8IC10ZW5leCogfCAtdG9wczIwKiB8IC1pdHMqIFwK
KwkgICAgICB8IC1vczIqIHwgLXZvcyogfCAtcGFsbW9zKiB8IC11Y2xpbnV4KiB8IC1udWNsZXVz
KiBcCisJICAgICAgfCAtbW9ycGhvcyogfCAtc3VwZXJ1eCogfCAtcnRtayogfCAtcnRtay1ub3Zh
KiB8IC13aW5kaXNzKiBcCisJICAgICAgfCAtcG93ZXJtYXgqIHwgLWRuaXgqIHwgLW54NiB8IC1u
eDcgfCAtc2VpKiB8IC1kcmFnb25mbHkqIFwKKwkgICAgICB8IC1za3lvcyogfCAtaGFpa3UqIHwg
LXJkb3MqIHwgLXRvcHBlcnMqIHwgLWRyb3BzKiB8IC1lcyopCisJIyBSZW1lbWJlciwgZWFjaCBh
bHRlcm5hdGl2ZSBNVVNUIEVORCBJTiAqLCB0byBtYXRjaCBhIHZlcnNpb24gbnVtYmVyLgorCQk7
OworCS1xbngqKQorCQljYXNlICRiYXNpY19tYWNoaW5lIGluCisJCSAgICB4ODYtKiB8IGkqODYt
KikKKwkJCTs7CisJCSAgICAqKQorCQkJb3M9LW50byRvcworCQkJOzsKKwkJZXNhYworCQk7Owor
CS1udG8tcW54KikKKwkJOzsKKwktbnRvKikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfG50
b3xudG8tcW54fCdgCisJCTs7CisJLXNpbSB8IC1lczE4MDAqIHwgLWhtcyogfCAteHJheSB8IC1v
czY4ayogfCAtbm9uZSogfCAtdjg4ciogXAorCSAgICAgIHwgLXdpbmRvd3MqIHwgLW9zeCB8IC1h
YnVnIHwgLW5ldHdhcmUqIHwgLW9zOSogfCAtYmVvcyogfCAtaGFpa3UqIFwKKwkgICAgICB8IC1t
YWNvcyogfCAtbXB3KiB8IC1tYWdpYyogfCAtbW1peHdhcmUqIHwgLW1vbjk2MCogfCAtbG5ld3Mq
KQorCQk7OworCS1tYWMqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bWFjfG1hY29zfCdg
CisJCTs7CisJLWxpbnV4LWRpZXRsaWJjKQorCQlvcz0tbGludXgtZGlldGxpYmMKKwkJOzsKKwkt
bGludXgqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bGludXh8bGludXgtZ251fCdgCisJ
CTs7CisJLXN1bm9zNSopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzdW5vczV8c29sYXJp
czJ8J2AKKwkJOzsKKwktc3Vub3M2KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHN1bm9z
Nnxzb2xhcmlzM3wnYAorCQk7OworCS1vcGVuZWQqKQorCQlvcz0tb3BlbmVkaXRpb24KKwkJOzsK
Kwktb3M0MDAqKQorCQlvcz0tb3M0MDAKKwkJOzsKKwktd2luY2UqKQorCQlvcz0td2luY2UKKwkJ
OzsKKwktb3Nmcm9zZSopCisJCW9zPS1vc2Zyb3NlCisJCTs7CisJLW9zZiopCisJCW9zPS1vc2YK
KwkJOzsKKwktdXRlayopCisJCW9zPS1ic2QKKwkJOzsKKwktZHluaXgqKQorCQlvcz0tYnNkCisJ
CTs7CisJLWFjaXMqKQorCQlvcz0tYW9zCisJCTs7CisJLWF0aGVvcyopCisJCW9zPS1hdGhlb3MK
KwkJOzsKKwktc3lsbGFibGUqKQorCQlvcz0tc3lsbGFibGUKKwkJOzsKKwktMzg2YnNkKQorCQlv
cz0tYnNkCisJCTs7CisJLWN0aXgqIHwgLXV0cyopCisJCW9zPS1zeXN2CisJCTs7CisJLW5vdmEq
KQorCQlvcz0tcnRtay1ub3ZhCisJCTs7CisJLW5zMiApCisJCW9zPS1uZXh0c3RlcDIKKwkJOzsK
KwktbnNrKikKKwkJb3M9LW5zaworCQk7OworCSMgUHJlc2VydmUgdGhlIHZlcnNpb24gbnVtYmVy
IG9mIHNpbml4NS4KKwktc2luaXg1LiopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzaW5p
eHxzeXN2fCdgCisJCTs7CisJLXNpbml4KikKKwkJb3M9LXN5c3Y0CisJCTs7CisJLXRwZiopCisJ
CW9zPS10cGYKKwkJOzsKKwktdHJpdG9uKikKKwkJb3M9LXN5c3YzCisJCTs7CisJLW9zcyopCisJ
CW9zPS1zeXN2MworCQk7OworCS1zdnI0KQorCQlvcz0tc3lzdjQKKwkJOzsKKwktc3ZyMykKKwkJ
b3M9LXN5c3YzCisJCTs7CisJLXN5c3ZyNCkKKwkJb3M9LXN5c3Y0CisJCTs7CisJIyBUaGlzIG11
c3QgY29tZSBhZnRlciAtc3lzdnI0LgorCS1zeXN2KikKKwkJOzsKKwktb3NlKikKKwkJb3M9LW9z
ZQorCQk7OworCS1lczE4MDAqKQorCQlvcz0tb3NlCisJCTs7CisJLXhlbml4KQorCQlvcz0teGVu
aXgKKwkJOzsKKwktKm1pbnQgfCAtbWludFswLTldKiB8IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQor
CQlvcz0tbWludAorCQk7OworCS1hcm9zKikKKwkJb3M9LWFyb3MKKwkJOzsKKwkta2FvcyopCisJ
CW9zPS1rYW9zCisJCTs7CisJLXp2bW9lKQorCQlvcz0tenZtb2UKKwkJOzsKKwktZGljb3MqKQor
CQlvcz0tZGljb3MKKwkJOzsKKwktbmFjbCopCisJCTs7CisJLW5vbmUpCisJCTs7CisJKikKKwkJ
IyBHZXQgcmlkIG9mIHRoZSBgLScgYXQgdGhlIGJlZ2lubmluZyBvZiAkb3MuCisJCW9zPWBlY2hv
ICRvcyB8IHNlZCAncy9bXi1dKi0vLydgCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxg
JDFcJzogc3lzdGVtIFxgJG9zXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJOzsK
K2VzYWMKK2Vsc2UKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBvcGVyYXRpbmcgc3lz
dGVtcyB0aGF0IGNvbWUgd2l0aCB2YXJpb3VzIG1hY2hpbmVzLgorIyBUaGUgdmFsdWUgc2hvdWxk
IGJlIHdoYXQgdGhlIHZlbmRvciBjdXJyZW50bHkgc2hpcHMgb3V0IHRoZSBkb29yIHdpdGggdGhl
aXIKKyMgbWFjaGluZSBvciBwdXQgYW5vdGhlciB3YXksIHRoZSBtb3N0IHBvcHVsYXIgb3MgcHJv
dmlkZWQgd2l0aCB0aGUgbWFjaGluZS4KKworIyBOb3RlIHRoYXQgaWYgeW91J3JlIGdvaW5nIHRv
IHRyeSB0byBtYXRjaCAiLU1BTlVGQUNUVVJFUiIgaGVyZSAoc2F5LAorIyAiLXN1biIpLCB0aGVu
IHlvdSBoYXZlIHRvIHRlbGwgdGhlIGNhc2Ugc3RhdGVtZW50IHVwIHRvd2FyZHMgdGhlIHRvcAor
IyB0aGF0IE1BTlVGQUNUVVJFUiBpc24ndCBhbiBvcGVyYXRpbmcgc3lzdGVtLiAgT3RoZXJ3aXNl
LCBjb2RlIGFib3ZlCisjIHdpbGwgc2lnbmFsIGFuIGVycm9yIHNheWluZyB0aGF0IE1BTlVGQUNU
VVJFUiBpc24ndCBhbiBvcGVyYXRpbmcKKyMgc3lzdGVtLCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IHRv
IHRoaXMgcG9pbnQuCisKK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwlzY29yZS0qKQorCQlvcz0t
ZWxmCisJCTs7CisJc3B1LSopCisJCW9zPS1lbGYKKwkJOzsKKwkqLWFjb3JuKQorCQlvcz0tcmlz
Y2l4MS4yCisJCTs7CisJYXJtKi1yZWJlbCkKKwkJb3M9LWxpbnV4CisJCTs7CisJYXJtKi1zZW1p
KQorCQlvcz0tYW91dAorCQk7OworCWM0eC0qIHwgdGljNHgtKikKKwkJb3M9LWNvZmYKKwkJOzsK
Kwl0aWM1NHgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM1NXgtKikKKwkJb3M9LWNvZmYKKwkJ
OzsKKwl0aWM2eC0qKQorCQlvcz0tY29mZgorCQk7OworCSMgVGhpcyBtdXN0IGNvbWUgYmVmb3Jl
IHRoZSAqLWRlYyBlbnRyeS4KKwlwZHAxMC0qKQorCQlvcz0tdG9wczIwCisJCTs7CisJcGRwMTEt
KikKKwkJb3M9LW5vbmUKKwkJOzsKKwkqLWRlYyB8IHZheC0qKQorCQlvcz0tdWx0cml4NC4yCisJ
CTs7CisJbTY4Ki1hcG9sbG8pCisJCW9zPS1kb21haW4KKwkJOzsKKwlpMzg2LXN1bikKKwkJb3M9
LXN1bm9zNC4wLjIKKwkJOzsKKwltNjgwMDAtc3VuKQorCQlvcz0tc3Vub3MzCisJCSMgVGhpcyBh
bHNvIGV4aXN0cyBpbiB0aGUgY29uZmlndXJlIHByb2dyYW0sIGJ1dCB3YXMgbm90IHRoZQorCQkj
IGRlZmF1bHQuCisJCSMgb3M9LXN1bm9zNAorCQk7OworCW02OCotY2lzY28pCisJCW9zPS1hb3V0
CisJCTs7CisJbWVwLSopCisJCW9zPS1lbGYKKwkJOzsKKwltaXBzKi1jaXNjbykKKwkJb3M9LWVs
ZgorCQk7OworCW1pcHMqLSopCisJCW9zPS1lbGYKKwkJOzsKKwlvcjMyLSopCisJCW9zPS1jb2Zm
CisJCTs7CisJKi10dGkpCSMgbXVzdCBiZSBiZWZvcmUgc3BhcmMgZW50cnkgb3Igd2UgZ2V0IHRo
ZSB3cm9uZyBvcy4KKwkJb3M9LXN5c3YzCisJCTs7CisJc3BhcmMtKiB8ICotc3VuKQorCQlvcz0t
c3Vub3M0LjEuMQorCQk7OworCSotYmUpCisJCW9zPS1iZW9zCisJCTs7CisJKi1oYWlrdSkKKwkJ
b3M9LWhhaWt1CisJCTs7CisJKi1pYm0pCisJCW9zPS1haXgKKwkJOzsKKwkqLWtudXRoKQorCQlv
cz0tbW1peHdhcmUKKwkJOzsKKwkqLXdlYykKKwkJb3M9LXByb2VsZgorCQk7OworCSotd2luYm9u
ZCkKKwkJb3M9LXByb2VsZgorCQk7OworCSotb2tpKQorCQlvcz0tcHJvZWxmCisJCTs7CisJKi1o
cCkKKwkJb3M9LWhwdXgKKwkJOzsKKwkqLWhpdGFjaGkpCisJCW9zPS1oaXV4CisJCTs7CisJaTg2
MC0qIHwgKi1hdHQgfCAqLW5jciB8ICotYWx0b3MgfCAqLW1vdG9yb2xhIHwgKi1jb252ZXJnZW50
KQorCQlvcz0tc3lzdgorCQk7OworCSotY2JtKQorCQlvcz0tYW1pZ2FvcworCQk7OworCSotZGcp
CisJCW9zPS1kZ3V4CisJCTs7CisJKi1kb2xwaGluKQorCQlvcz0tc3lzdjMKKwkJOzsKKwltNjhr
LWNjdXIpCisJCW9zPS1ydHUKKwkJOzsKKwltODhrLW9tcm9uKikKKwkJb3M9LWx1bmEKKwkJOzsK
KwkqLW5leHQgKQorCQlvcz0tbmV4dHN0ZXAKKwkJOzsKKwkqLXNlcXVlbnQpCisJCW9zPS1wdHgK
KwkJOzsKKwkqLWNyZHMpCisJCW9zPS11bm9zCisJCTs7CisJKi1ucykKKwkJb3M9LWdlbml4CisJ
CTs7CisJaTM3MC0qKQorCQlvcz0tbXZzCisJCTs7CisJKi1uZXh0KQorCQlvcz0tbmV4dHN0ZXAz
CisJCTs7CisJKi1nb3VsZCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWhpZ2hsZXZlbCkKKwkJb3M9
LWJzZAorCQk7OworCSotZW5jb3JlKQorCQlvcz0tYnNkCisJCTs7CisJKi1zZ2kpCisJCW9zPS1p
cml4CisJCTs7CisJKi1zaWVtZW5zKQorCQlvcz0tc3lzdjQKKwkJOzsKKwkqLW1hc3Njb21wKQor
CQlvcz0tcnR1CisJCTs7CisJZjMwWzAxXS1mdWppdHN1IHwgZjcwMC1mdWppdHN1KQorCQlvcz0t
dXhwdgorCQk7OworCSotcm9tNjhrKQorCQlvcz0tY29mZgorCQk7OworCSotKmJ1ZykKKwkJb3M9
LWNvZmYKKwkJOzsKKwkqLWFwcGxlKQorCQlvcz0tbWFjb3MKKwkJOzsKKwkqLWF0YXJpKikKKwkJ
b3M9LW1pbnQKKwkJOzsKKwkqKQorCQlvcz0tbm9uZQorCQk7OworZXNhYworZmkKKworIyBIZXJl
IHdlIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB3ZSBrbm93IHRoZSBvcywgYW5kIHRoZSBDUFUgdHlw
ZSwgYnV0IG5vdCB0aGUKKyMgbWFudWZhY3R1cmVyLiAgV2UgcGljayB0aGUgbG9naWNhbCBtYW51
ZmFjdHVyZXIuCit2ZW5kb3I9dW5rbm93bgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSotdW5r
bm93bikKKwkJY2FzZSAkb3MgaW4KKwkJCS1yaXNjaXgqKQorCQkJCXZlbmRvcj1hY29ybgorCQkJ
CTs7CisJCQktc3Vub3MqKQorCQkJCXZlbmRvcj1zdW4KKwkJCQk7OworCQkJLWNuayp8LWFpeCop
CisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktYmVvcyopCisJCQkJdmVuZG9yPWJlCisJCQkJ
OzsKKwkJCS1ocHV4KikKKwkJCQl2ZW5kb3I9aHAKKwkJCQk7OworCQkJLW1wZWl4KikKKwkJCQl2
ZW5kb3I9aHAKKwkJCQk7OworCQkJLWhpdXgqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsK
KwkJCS11bm9zKikKKwkJCQl2ZW5kb3I9Y3JkcworCQkJCTs7CisJCQktZGd1eCopCisJCQkJdmVu
ZG9yPWRnCisJCQkJOzsKKwkJCS1sdW5hKikKKwkJCQl2ZW5kb3I9b21yb24KKwkJCQk7OworCQkJ
LWdlbml4KikKKwkJCQl2ZW5kb3I9bnMKKwkJCQk7OworCQkJLW12cyogfCAtb3BlbmVkKikKKwkJ
CQl2ZW5kb3I9aWJtCisJCQkJOzsKKwkJCS1vczQwMCopCisJCQkJdmVuZG9yPWlibQorCQkJCTs7
CisJCQktcHR4KikKKwkJCQl2ZW5kb3I9c2VxdWVudAorCQkJCTs7CisJCQktdHBmKikKKwkJCQl2
ZW5kb3I9aWJtCisJCQkJOzsKKwkJCS12eHNpbSogfCAtdnh3b3JrcyogfCAtd2luZGlzcyopCisJ
CQkJdmVuZG9yPXdycworCQkJCTs7CisJCQktYXV4KikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7
OworCQkJLWhtcyopCisJCQkJdmVuZG9yPWhpdGFjaGkKKwkJCQk7OworCQkJLW1wdyogfCAtbWFj
b3MqKQorCQkJCXZlbmRvcj1hcHBsZQorCQkJCTs7CisJCQktKm1pbnQgfCAtbWludFswLTldKiB8
IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQorCQkJCXZlbmRvcj1hdGFyaQorCQkJCTs7CisJCQktdm9z
KikKKwkJCQl2ZW5kb3I9c3RyYXR1cworCQkJCTs7CisJCWVzYWMKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAicy91bmtub3duLyR2ZW5kb3IvImAKKwkJOzsKK2Vz
YWMKKworZWNobyAkYmFzaWNfbWFjaGluZSRvcworZXhpdAorCisjIExvY2FsIHZhcmlhYmxlczoK
KyMgZXZhbDogKGFkZC1ob29rICd3cml0ZS1maWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1l
LXN0YW1wLXN0YXJ0OiAidGltZXN0YW1wPSciCisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUw
Mm0tJTAyZCIKKyMgdGltZS1zdGFtcC1lbmQ6ICInIgorIyBFbmQ6CmRpZmYgLXIgZTI3MjJiMjRk
YzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlndXJlCVdlZCBKYW4gMTEg
MDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwMjA0IEBACisjISAvYmluL3NoCisjIEd1
ZXNzIHZhbHVlcyBmb3Igc3lzdGVtLWRlcGVuZGVudCB2YXJpYWJsZXMgYW5kIGNyZWF0ZSBNYWtl
ZmlsZXMuCisjIEdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OCBmb3IgWGVuIEh5cGVydmlz
b3IgNC4yLgorIworIyBSZXBvcnQgYnVncyB0byA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20+LgorIworIworIyBDb3B5cmlnaHQgKEMpIDE5OTIsIDE5OTMsIDE5OTQsIDE5OTUsIDE5OTYs
IDE5OTgsIDE5OTksIDIwMDAsIDIwMDEsCisjIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYs
IDIwMDcsIDIwMDgsIDIwMDksIDIwMTAgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMu
CisjCisjCisjIFRoaXMgY29uZmlndXJlIHNjcmlwdCBpcyBmcmVlIHNvZnR3YXJlOyB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uCisjIGdpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNv
cHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4KKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMj
CisjIyBNNHNoIEluaXRpYWxpemF0aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMK
KworIyBCZSBtb3JlIEJvdXJuZSBjb21wYXRpYmxlCitEVUFMQ0FTRT0xOyBleHBvcnQgRFVBTENB
U0UgIyBmb3IgTUtTIHNoCitpZiB0ZXN0IC1uICIke1pTSF9WRVJTSU9OK3NldH0iICYmIChlbXVs
YXRlIHNoKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9
OgorICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uICR7MSsi
JEAifSwgd2hpY2gKKyAgIyBpcyBjb250cmFyeSB0byBvdXIgdXNhZ2UuICBEaXNhYmxlIHRoaXMg
ZmVhdHVyZS4KKyAgYWxpYXMgLWcgJyR7MSsiJEAifSc9JyIkQCInCisgIHNldG9wdCBOT19HTE9C
X1NVQlNUCitlbHNlCisgIGNhc2UgYChzZXQgLW8pIDI+L2Rldi9udWxsYCBpbiAjKAorICAqcG9z
aXgqKSA6CisgICAgc2V0IC1vIHBvc2l4IDs7ICMoCisgICopIDoKKyAgICAgOzsKK2VzYWMKK2Zp
CisKKworYXNfbmw9JworJworZXhwb3J0IGFzX25sCisjIFByaW50aW5nIGEgbG9uZyBzdHJpbmcg
Y3Jhc2hlcyBTb2xhcmlzIDcgL3Vzci9iaW4vcHJpbnRmLgorYXNfZWNobz0nXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXCcKK2FzX2VjaG89JGFzX2VjaG8kYXNf
ZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobworYXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFz
X2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8KKyMgUHJlZmVyIGEga3NoIHNoZWxsIGJ1aWx0
aW4gb3ZlciBhbiBleHRlcm5hbCBwcmludGYgcHJvZ3JhbSBvbiBTb2xhcmlzLAorIyBidXQgd2l0
aG91dCB3YXN0aW5nIGZvcmtzIGZvciBiYXNoIG9yIHpzaC4KK2lmIHRlc3QgLXogIiRCQVNIX1ZF
UlNJT04kWlNIX1ZFUlNJT04iIFwKKyAgICAmJiAodGVzdCAiWGBwcmludCAtciAtLSAkYXNfZWNo
b2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50IC1y
IC0tJworICBhc19lY2hvX249J3ByaW50IC1ybiAtLScKK2VsaWYgKHRlc3QgIlhgcHJpbnRmICVz
ICRhc19lY2hvYCIgPSAiWCRhc19lY2hvIikgMj4vZGV2L251bGw7IHRoZW4KKyAgYXNfZWNobz0n
cHJpbnRmICVzXG4nCisgIGFzX2VjaG9fbj0ncHJpbnRmICVzJworZWxzZQorICBpZiB0ZXN0ICJY
YCgvdXNyL3VjYi9lY2hvIC1uIC1uICRhc19lY2hvKSAyPi9kZXYvbnVsbGAiID0gIlgtbiAkYXNf
ZWNobyI7IHRoZW4KKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgL3Vzci91Y2IvZWNobyAtbiAiJDEk
YXNfbmwiJworICAgIGFzX2VjaG9fbj0nL3Vzci91Y2IvZWNobyAtbicKKyAgZWxzZQorICAgIGFz
X2VjaG9fYm9keT0nZXZhbCBleHByICJYJDEiIDogIlhcXCguKlxcKSInCisgICAgYXNfZWNob19u
X2JvZHk9J2V2YWwKKyAgICAgIGFyZz0kMTsKKyAgICAgIGNhc2UgJGFyZyBpbiAjKAorICAgICAg
KiIkYXNfbmwiKikKKwlleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpJGFzX25sIjsKKwlhcmc9YGV4
cHIgIlgkYXJnIiA6ICIuKiRhc19ubFxcKC4qXFwpImA7OworICAgICAgZXNhYzsKKyAgICAgIGV4
cHIgIlgkYXJnIiA6ICJYXFwoLipcXCkiIHwgdHIgLWQgIiRhc19ubCIKKyAgICAnCisgICAgZXhw
b3J0IGFzX2VjaG9fbl9ib2R5CisgICAgYXNfZWNob19uPSdzaCAtYyAkYXNfZWNob19uX2JvZHkg
YXNfZWNobycKKyAgZmkKKyAgZXhwb3J0IGFzX2VjaG9fYm9keQorICBhc19lY2hvPSdzaCAtYyAk
YXNfZWNob19ib2R5IGFzX2VjaG8nCitmaQorCisjIFRoZSB1c2VyIGlzIGFsd2F5cyByaWdodC4K
K2lmIHRlc3QgIiR7UEFUSF9TRVBBUkFUT1Irc2V0fSIgIT0gc2V0OyB0aGVuCisgIFBBVEhfU0VQ
QVJBVE9SPToKKyAgKFBBVEg9Jy9iaW47L2Jpbic7IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rl
di9udWxsIDI+JjEgJiYgeworICAgIChQQVRIPScvYmluOi9iaW4nOyBGUEFUSD0kUEFUSDsgc2gg
LWMgOikgPi9kZXYvbnVsbCAyPiYxIHx8CisgICAgICBQQVRIX1NFUEFSQVRPUj0nOycKKyAgfQor
ZmkKKworCisjIElGUworIyBXZSBuZWVkIHNwYWNlLCB0YWIgYW5kIG5ldyBsaW5lLCBpbiBwcmVj
aXNlbHkgdGhhdCBvcmRlci4gIFF1b3RpbmcgaXMKKyMgdGhlcmUgdG8gcHJldmVudCBlZGl0b3Jz
IGZyb20gY29tcGxhaW5pbmcgYWJvdXQgc3BhY2UtdGFiLgorIyAoSWYgX0FTX1BBVEhfV0FMSyB3
ZXJlIGNhbGxlZCB3aXRoIElGUyB1bnNldCwgaXQgd291bGQgZGlzYWJsZSB3b3JkCisjIHNwbGl0
dGluZyBieSBzZXR0aW5nIElGUyB0byBlbXB0eSB2YWx1ZS4pCitJRlM9IiAiIgkkYXNfbmwiCisK
KyMgRmluZCB3aG8gd2UgYXJlLiAgTG9vayBpbiB0aGUgcGF0aCBpZiB3ZSBjb250YWluIG5vIGRp
cmVjdG9yeSBzZXBhcmF0b3IuCithc19teXNlbGY9CitjYXNlICQwIGluICMoKAorICAqW1xcL10q
ICkgYXNfbXlzZWxmPSQwIDs7CisgICopIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICB0ZXN0IC1yICIkYXNfZGlyLyQwIiAmJiBh
c19teXNlbGY9JGFzX2Rpci8kMCAmJiBicmVhaworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgICAgOzsKK2VzYWMKKyMgV2UgZGlkIG5vdCBmaW5kIG91cnNlbHZlcywgbW9zdCBwcm9iYWJs
eSB3ZSB3ZXJlIHJ1biBhcyBgc2ggQ09NTUFORCcKKyMgaW4gd2hpY2ggY2FzZSB3ZSBhcmUgbm90
IHRvIGJlIGZvdW5kIGluIHRoZSBwYXRoLgoraWYgdGVzdCAieCRhc19teXNlbGYiID0geDsgdGhl
bgorICBhc19teXNlbGY9JDAKK2ZpCitpZiB0ZXN0ICEgLWYgIiRhc19teXNlbGYiOyB0aGVuCisg
ICRhc19lY2hvICIkYXNfbXlzZWxmOiBlcnJvcjogY2Fubm90IGZpbmQgbXlzZWxmOyByZXJ1biB3
aXRoIGFuIGFic29sdXRlIGZpbGUgbmFtZSIgPiYyCisgIGV4aXQgMQorZmkKKworIyBVbnNldCB2
YXJpYWJsZXMgdGhhdCB3ZSBkbyBub3QgbmVlZCBhbmQgd2hpY2ggY2F1c2UgYnVncyAoZS5nLiBp
bgorIyBwcmUtMy4wIFVXSU4ga3NoKS4gIEJ1dCBkbyBub3QgY2F1c2UgYnVncyBpbiBiYXNoIDIu
MDE7IHRoZSAifHwgZXhpdCAxIgorIyBzdXBwcmVzc2VzIGFueSAiU2VnbWVudGF0aW9uIGZhdWx0
IiBtZXNzYWdlIHRoZXJlLiAgJygoJyBjb3VsZAorIyB0cmlnZ2VyIGEgYnVnIGluIHBka3NoIDUu
Mi4xNC4KK2ZvciBhc192YXIgaW4gQkFTSF9FTlYgRU5WIE1BSUwgTUFJTFBBVEgKK2RvIGV2YWwg
dGVzdCB4XCR7JGFzX3ZhcitzZXR9ID0geHNldCBcCisgICYmICggKHVuc2V0ICRhc192YXIpIHx8
IGV4aXQgMSkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0ICRhc192YXIgfHwgOgorZG9uZQorUFMx
PSckICcKK1BTMj0nPiAnCitQUzQ9JysgJworCisjIE5MUyBudWlzYW5jZXMuCitMQ19BTEw9Qwor
ZXhwb3J0IExDX0FMTAorTEFOR1VBR0U9QworZXhwb3J0IExBTkdVQUdFCisKKyMgQ0RQQVRILgor
KHVuc2V0IENEUEFUSCkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IENEUEFUSAorCitpZiB0ZXN0
ICJ4JENPTkZJR19TSEVMTCIgPSB4OyB0aGVuCisgIGFzX2JvdXJuZV9jb21wYXRpYmxlPSJpZiB0
ZXN0IC1uIFwiXCR7WlNIX1ZFUlNJT04rc2V0fVwiICYmIChlbXVsYXRlIHNoKSA+L2Rldi9udWxs
IDI+JjE7IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAjIFByZS00LjIgdmVy
c2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uIFwkezErXCJcJEBcIn0sIHdoaWNoCisg
ICMgaXMgY29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFs
aWFzIC1nICdcJHsxK1wiXCRAXCJ9Jz0nXCJcJEBcIicKKyAgc2V0b3B0IE5PX0dMT0JfU1VCU1QK
K2Vsc2UKKyAgY2FzZSBcYChzZXQgLW8pIDI+L2Rldi9udWxsXGAgaW4gIygKKyAgKnBvc2l4Kikg
OgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorIgor
ICBhc19yZXF1aXJlZD0iYXNfZm5fcmV0dXJuICgpIHsgKGV4aXQgXCQxKTsgfQorYXNfZm5fc3Vj
Y2VzcyAoKSB7IGFzX2ZuX3JldHVybiAwOyB9Cithc19mbl9mYWlsdXJlICgpIHsgYXNfZm5fcmV0
dXJuIDE7IH0KK2FzX2ZuX3JldF9zdWNjZXNzICgpIHsgcmV0dXJuIDA7IH0KK2FzX2ZuX3JldF9m
YWlsdXJlICgpIHsgcmV0dXJuIDE7IH0KKworZXhpdGNvZGU9MAorYXNfZm5fc3VjY2VzcyB8fCB7
IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fc3VjY2VzcyBmYWlsZWQuOyB9Cithc19mbl9mYWlsdXJl
ICYmIHsgZXhpdGNvZGU9MTsgZWNobyBhc19mbl9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2FzX2Zu
X3JldF9zdWNjZXNzIHx8IHsgZXhpdGNvZGU9MTsgZWNobyBhc19mbl9yZXRfc3VjY2VzcyBmYWls
ZWQuOyB9Cithc19mbl9yZXRfZmFpbHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fcmV0
X2ZhaWx1cmUgc3VjY2VlZGVkLjsgfQoraWYgKCBzZXQgeDsgYXNfZm5fcmV0X3N1Y2Nlc3MgeSAm
JiB0ZXN0IHggPSBcIlwkMVwiICk7IHRoZW4gOgorCitlbHNlCisgIGV4aXRjb2RlPTE7IGVjaG8g
cG9zaXRpb25hbCBwYXJhbWV0ZXJzIHdlcmUgbm90IHNhdmVkLgorZmkKK3Rlc3QgeFwkZXhpdGNv
ZGUgPSB4MCB8fCBleGl0IDEiCisgIGFzX3N1Z2dlc3RlZD0iICBhc19saW5lbm9fMT0iO2FzX3N1
Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCIg
YXNfbGluZW5vXzFhPVwkTElORU5PCisgIGFzX2xpbmVub18yPSI7YXNfc3VnZ2VzdGVkPSRhc19z
dWdnZXN0ZWQkTElORU5PO2FzX3N1Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkIiBhc19saW5lbm9fMmE9
XCRMSU5FTk8KKyAgZXZhbCAndGVzdCBcInhcJGFzX2xpbmVub18xJ1wkYXNfcnVuJ1wiICE9IFwi
eFwkYXNfbGluZW5vXzInXCRhc19ydW4nXCIgJiYKKyAgdGVzdCBcInhcYGV4cHIgXCRhc19saW5l
bm9fMSdcJGFzX3J1bicgKyAxXGBcIiA9IFwieFwkYXNfbGluZW5vXzInXCRhc19ydW4nXCInIHx8
IGV4aXQgMQordGVzdCBcJCgoIDEgKyAxICkpID0gMiB8fCBleGl0IDEiCisgIGlmIChldmFsICIk
YXNfcmVxdWlyZWQiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGFzX2hhdmVfcmVxdWlyZWQ9eWVz
CitlbHNlCisgIGFzX2hhdmVfcmVxdWlyZWQ9bm8KK2ZpCisgIGlmIHRlc3QgeCRhc19oYXZlX3Jl
cXVpcmVkID0geHllcyAmJiAoZXZhbCAiJGFzX3N1Z2dlc3RlZCIpIDI+L2Rldi9udWxsOyB0aGVu
IDoKKworZWxzZQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCithc19m
b3VuZD1mYWxzZQorZm9yIGFzX2RpciBpbiAvYmluJFBBVEhfU0VQQVJBVE9SL3Vzci9iaW4kUEFU
SF9TRVBBUkFUT1IkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNf
ZGlyIiAmJiBhc19kaXI9LgorICBhc19mb3VuZD06CisgIGNhc2UgJGFzX2RpciBpbiAjKAorCSAv
KikKKwkgICBmb3IgYXNfYmFzZSBpbiBzaCBiYXNoIGtzaCBzaDU7IGRvCisJICAgICAjIFRyeSBv
bmx5IHNoZWxscyB0aGF0IGV4aXN0LCB0byBzYXZlIHNldmVyYWwgZm9ya3MuCisJICAgICBhc19z
aGVsbD0kYXNfZGlyLyRhc19iYXNlCisJICAgICBpZiB7IHRlc3QgLWYgIiRhc19zaGVsbCIgfHwg
dGVzdCAtZiAiJGFzX3NoZWxsLmV4ZSI7IH0gJiYKKwkJICAgIHsgJGFzX2VjaG8gIiRhc19ib3Vy
bmVfY29tcGF0aWJsZSIiJGFzX3JlcXVpcmVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9IDI+
L2Rldi9udWxsOyB0aGVuIDoKKyAgQ09ORklHX1NIRUxMPSRhc19zaGVsbCBhc19oYXZlX3JlcXVp
cmVkPXllcworCQkgICBpZiB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUiIiRhc19z
dWdnZXN0ZWQiIHwgYXNfcnVuPWEgIiRhc19zaGVsbCI7IH0gMj4vZGV2L251bGw7IHRoZW4gOgor
ICBicmVhayAyCitmaQorZmkKKwkgICBkb25lOzsKKyAgICAgICBlc2FjCisgIGFzX2ZvdW5kPWZh
bHNlCitkb25lCiskYXNfZm91bmQgfHwgeyBpZiB7IHRlc3QgLWYgIiRTSEVMTCIgfHwgdGVzdCAt
ZiAiJFNIRUxMLmV4ZSI7IH0gJiYKKwkgICAgICB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBh
dGlibGUiIiRhc19yZXF1aXJlZCIgfCBhc19ydW49YSAiJFNIRUxMIjsgfSAyPi9kZXYvbnVsbDsg
dGhlbiA6CisgIENPTkZJR19TSEVMTD0kU0hFTEwgYXNfaGF2ZV9yZXF1aXJlZD15ZXMKK2ZpOyB9
CitJRlM9JGFzX3NhdmVfSUZTCisKKworICAgICAgaWYgdGVzdCAieCRDT05GSUdfU0hFTEwiICE9
IHg7IHRoZW4gOgorICAjIFdlIGNhbm5vdCB5ZXQgYXNzdW1lIGEgZGVjZW50IHNoZWxsLCBzbyB3
ZSBoYXZlIHRvIHByb3ZpZGUgYQorCSMgbmV1dHJhbGl6YXRpb24gdmFsdWUgZm9yIHNoZWxscyB3
aXRob3V0IHVuc2V0OyBhbmQgdGhpcyBhbHNvCisJIyB3b3JrcyBhcm91bmQgc2hlbGxzIHRoYXQg
Y2Fubm90IHVuc2V0IG5vbmV4aXN0ZW50IHZhcmlhYmxlcy4KKwkjIFByZXNlcnZlIC12IGFuZCAt
eCB0byB0aGUgcmVwbGFjZW1lbnQgc2hlbGwuCisJQkFTSF9FTlY9L2Rldi9udWxsCisJRU5WPS9k
ZXYvbnVsbAorCSh1bnNldCBCQVNIX0VOVikgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IEJBU0hf
RU5WIEVOVgorCWV4cG9ydCBDT05GSUdfU0hFTEwKKwljYXNlICQtIGluICMgKCgoKAorCSAgKnYq
eCogfCAqeCp2KiApIGFzX29wdHM9LXZ4IDs7CisJICAqdiogKSBhc19vcHRzPS12IDs7CisJICAq
eCogKSBhc19vcHRzPS14IDs7CisJICAqICkgYXNfb3B0cz0gOzsKKwllc2FjCisJZXhlYyAiJENP
TkZJR19TSEVMTCIgJGFzX29wdHMgIiRhc19teXNlbGYiICR7MSsiJEAifQorZmkKKworICAgIGlm
IHRlc3QgeCRhc19oYXZlX3JlcXVpcmVkID0geG5vOyB0aGVuIDoKKyAgJGFzX2VjaG8gIiQwOiBU
aGlzIHNjcmlwdCByZXF1aXJlcyBhIHNoZWxsIG1vcmUgbW9kZXJuIHRoYW4gYWxsIgorICAkYXNf
ZWNobyAiJDA6IHRoZSBzaGVsbHMgdGhhdCBJIGZvdW5kIG9uIHlvdXIgc3lzdGVtLiIKKyAgaWYg
dGVzdCB4JHtaU0hfVkVSU0lPTitzZXR9ID0geHNldCA7IHRoZW4KKyAgICAkYXNfZWNobyAiJDA6
IEluIHBhcnRpY3VsYXIsIHpzaCAkWlNIX1ZFUlNJT04gaGFzIGJ1Z3MgYW5kIHNob3VsZCIKKyAg
ICAkYXNfZWNobyAiJDA6IGJlIHVwZ3JhZGVkIHRvIHpzaCA0LjMuNCBvciBsYXRlci4iCisgIGVs
c2UKKyAgICAkYXNfZWNobyAiJDA6IFBsZWFzZSB0ZWxsIGJ1Zy1hdXRvY29uZkBnbnUub3JnIGFu
ZAorJDA6IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIGFib3V0IHlvdXIgc3lzdGVtLAor
JDA6IGluY2x1ZGluZyBhbnkgZXJyb3IgcG9zc2libHkgb3V0cHV0IGJlZm9yZSB0aGlzCiskMDog
bWVzc2FnZS4gVGhlbiBpbnN0YWxsIGEgbW9kZXJuIHNoZWxsLCBvciBtYW51YWxseSBydW4KKyQw
OiB0aGUgc2NyaXB0IHVuZGVyIHN1Y2ggYSBzaGVsbCBpZiB5b3UgZG8gaGF2ZSBvbmUuIgorICBm
aQorICBleGl0IDEKK2ZpCitmaQorZmkKK1NIRUxMPSR7Q09ORklHX1NIRUxMLS9iaW4vc2h9Citl
eHBvcnQgU0hFTEwKKyMgVW5zZXQgbW9yZSB2YXJpYWJsZXMga25vd24gdG8gaW50ZXJmZXJlIHdp
dGggYmVoYXZpb3Igb2YgY29tbW9uIHRvb2xzLgorQ0xJQ09MT1JfRk9SQ0U9IEdSRVBfT1BUSU9O
Uz0KK3Vuc2V0IENMSUNPTE9SX0ZPUkNFIEdSRVBfT1BUSU9OUworCisjIyAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0gIyMKKyMjIE00c2ggU2hlbGwgRnVuY3Rpb25zLiAjIworIyMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tICMjCisjIGFzX2ZuX3Vuc2V0IFZBUgorIyAtLS0tLS0tLS0tLS0tLS0KKyMgUG9y
dGFibHkgdW5zZXQgVkFSLgorYXNfZm5fdW5zZXQgKCkKK3sKKyAgeyBldmFsICQxPTsgdW5zZXQg
JDE7fQorfQorYXNfdW5zZXQ9YXNfZm5fdW5zZXQKKworIyBhc19mbl9zZXRfc3RhdHVzIFNUQVRV
UworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBTZXQgJD8gdG8gU1RBVFVTLCB3aXRob3V0
IGZvcmtpbmcuCithc19mbl9zZXRfc3RhdHVzICgpCit7CisgIHJldHVybiAkMQorfSAjIGFzX2Zu
X3NldF9zdGF0dXMKKworIyBhc19mbl9leGl0IFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLQor
IyBFeGl0IHRoZSBzaGVsbCB3aXRoIFNUQVRVUywgZXZlbiBpbiBhICJ0cmFwIDAiIG9yICJzZXQg
LWUiIGNvbnRleHQuCithc19mbl9leGl0ICgpCit7CisgIHNldCArZQorICBhc19mbl9zZXRfc3Rh
dHVzICQxCisgIGV4aXQgJDEKK30gIyBhc19mbl9leGl0CisKKyMgYXNfZm5fbWtkaXJfcAorIyAt
LS0tLS0tLS0tLS0tCisjIENyZWF0ZSAiJGFzX2RpciIgYXMgYSBkaXJlY3RvcnksIGluY2x1ZGlu
ZyBwYXJlbnRzIGlmIG5lY2Vzc2FyeS4KK2FzX2ZuX21rZGlyX3AgKCkKK3sKKworICBjYXNlICRh
c19kaXIgaW4gIygKKyAgLSopIGFzX2Rpcj0uLyRhc19kaXI7OworICBlc2FjCisgIHRlc3QgLWQg
IiRhc19kaXIiIHx8IGV2YWwgJGFzX21rZGlyX3AgfHwgeworICAgIGFzX2RpcnM9CisgICAgd2hp
bGUgOjsgZG8KKyAgICAgIGNhc2UgJGFzX2RpciBpbiAjKAorICAgICAgKlwnKikgYXNfcWRpcj1g
JGFzX2VjaG8gIiRhc19kaXIiIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgIycoCisgICAg
ICAqKSBhc19xZGlyPSRhc19kaXI7OworICAgICAgZXNhYworICAgICAgYXNfZGlycz0iJyRhc19x
ZGlyJyAkYXNfZGlycyIKKyAgICAgIGFzX2Rpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19kaXIiIHx8
CiskYXNfZXhwciBYIiRhc19kaXIiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBc
CisJIFgiJGFzX2RpciIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgv
L1wpJCcgXHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAor
JGFzX2VjaG8gWCIkYXNfZGlyIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14v
XSpcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4q
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMv
L1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBx
CisJICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgICAgIHRlc3QgLWQgIiRhc19kaXIiICYmIGJyZWFr
CisgICAgZG9uZQorICAgIHRlc3QgLXogIiRhc19kaXJzIiB8fCBldmFsICJta2RpciAkYXNfZGly
cyIKKyAgfSB8fCB0ZXN0IC1kICIkYXNfZGlyIiB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNy
ZWF0ZSBkaXJlY3RvcnkgJGFzX2RpciIKKworCit9ICMgYXNfZm5fbWtkaXJfcAorIyBhc19mbl9h
cHBlbmQgVkFSIFZBTFVFCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgQXBwZW5kIHRoZSB0
ZXh0IGluIFZBTFVFIHRvIHRoZSBlbmQgb2YgdGhlIGRlZmluaXRpb24gY29udGFpbmVkIGluIFZB
Ui4gVGFrZQorIyBhZHZhbnRhZ2Ugb2YgYW55IHNoZWxsIG9wdGltaXphdGlvbnMgdGhhdCBhbGxv
dyBhbW9ydGl6ZWQgbGluZWFyIGdyb3d0aCBvdmVyCisjIHJlcGVhdGVkIGFwcGVuZHMsIGluc3Rl
YWQgb2YgdGhlIHR5cGljYWwgcXVhZHJhdGljIGdyb3d0aCBwcmVzZW50IGluIG5haXZlCisjIGlt
cGxlbWVudGF0aW9ucy4KK2lmIChldmFsICJhc192YXI9MTsgYXNfdmFyKz0yOyB0ZXN0IHhcJGFz
X3ZhciA9IHgxMiIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXBwZW5kICgp
CisgIHsKKyAgICBldmFsICQxKz1cJDIKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXBwZW5kICgpCisg
IHsKKyAgICBldmFsICQxPVwkJDFcJDIKKyAgfQorZmkgIyBhc19mbl9hcHBlbmQKKworIyBhc19m
bl9hcml0aCBBUkcuLi4KKyMgLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBlcmZvcm0gYXJpdGhtZXRp
YyBldmFsdWF0aW9uIG9uIHRoZSBBUkdzLCBhbmQgc3RvcmUgdGhlIHJlc3VsdCBpbiB0aGUKKyMg
Z2xvYmFsICRhc192YWwuIFRha2UgYWR2YW50YWdlIG9mIHNoZWxscyB0aGF0IGNhbiBhdm9pZCBm
b3Jrcy4gVGhlIGFyZ3VtZW50cworIyBtdXN0IGJlIHBvcnRhYmxlIGFjcm9zcyAkKCgpKSBhbmQg
ZXhwci4KK2lmIChldmFsICJ0ZXN0IFwkKCggMSArIDEgKSkgPSAyIikgMj4vZGV2L251bGw7IHRo
ZW4gOgorICBldmFsICdhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPSQoKCAkKiApKQor
ICB9JworZWxzZQorICBhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPWBleHByICIkQCIg
fHwgdGVzdCAkPyAtZXEgMWAKKyAgfQorZmkgIyBhc19mbl9hcml0aAorCisKKyMgYXNfZm5fZXJy
b3IgU1RBVFVTIEVSUk9SIFtMSU5FTk8gTE9HX0ZEXQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCisjIE91dHB1dCAiYGJhc2VuYW1lICQwYDogZXJyb3I6IEVSUk9S
IiB0byBzdGRlcnIuIElmIExJTkVOTyBhbmQgTE9HX0ZEIGFyZQorIyBwcm92aWRlZCwgYWxzbyBv
dXRwdXQgdGhlIGVycm9yIHRvIExPR19GRCwgcmVmZXJlbmNpbmcgTElORU5PLiBUaGVuIGV4aXQg
dGhlCisjIHNjcmlwdCB3aXRoIFNUQVRVUywgdXNpbmcgMSBpZiB0aGF0IHdhcyAwLgorYXNfZm5f
ZXJyb3IgKCkKK3sKKyAgYXNfc3RhdHVzPSQxOyB0ZXN0ICRhc19zdGF0dXMgLWVxIDAgJiYgYXNf
c3RhdHVzPTEKKyAgaWYgdGVzdCAiJDQiOyB0aGVuCisgICAgYXNfbGluZW5vPSR7YXNfbGluZW5v
LSIkMyJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjawor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiAkMiIgPiYk
NAorICBmaQorICAkYXNfZWNobyAiJGFzX21lOiBlcnJvcjogJDIiID4mMgorICBhc19mbl9leGl0
ICRhc19zdGF0dXMKK30gIyBhc19mbl9lcnJvcgorCitpZiBleHByIGEgOiAnXChhXCknID4vZGV2
L251bGwgMj4mMSAmJgorICAgdGVzdCAiWGBleHByIDAwMDAxIDogJy4qXCguLi5cKSdgIiA9IFgw
MDE7IHRoZW4KKyAgYXNfZXhwcj1leHByCitlbHNlCisgIGFzX2V4cHI9ZmFsc2UKK2ZpCisKK2lm
IChiYXNlbmFtZSAtLSAvKSA+L2Rldi9udWxsIDI+JjEgJiYgdGVzdCAiWGBiYXNlbmFtZSAtLSAv
IDI+JjFgIiA9ICJYLyI7IHRoZW4KKyAgYXNfYmFzZW5hbWU9YmFzZW5hbWUKK2Vsc2UKKyAgYXNf
YmFzZW5hbWU9ZmFsc2UKK2ZpCisKK2lmIChhc19kaXI9YGRpcm5hbWUgLS0gL2AgJiYgdGVzdCAi
WCRhc19kaXIiID0gWC8pID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBhc19kaXJuYW1lPWRpcm5h
bWUKK2Vsc2UKKyAgYXNfZGlybmFtZT1mYWxzZQorZmkKKworYXNfbWU9YCRhc19iYXNlbmFtZSAt
LSAiJDAiIHx8CiskYXNfZXhwciBYLyIkMCIgOiAnLiovXChbXi9dW14vXSpcKS8qJCcgXHwgXAor
CSBYIiQwIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiQwIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2
L251bGwgfHwKKyRhc19lY2hvIFgvIiQwIiB8CisgICAgc2VkICcvXi4qXC9cKFteL11bXi9dKlwp
XC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cL1wpJC97CisJ
ICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cKS4qL3sKKwkgICAgcy8vXDEv
CisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorCisjIEF2b2lkIGRlcGVuZGluZyB1cG9u
IENoYXJhY3RlciBSYW5nZXMuCithc19jcl9sZXR0ZXJzPSdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2
d3h5eicKK2FzX2NyX0xFVFRFUlM9J0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJworYXNfY3Jf
TGV0dGVycz0kYXNfY3JfbGV0dGVycyRhc19jcl9MRVRURVJTCithc19jcl9kaWdpdHM9JzAxMjM0
NTY3ODknCithc19jcl9hbG51bT0kYXNfY3JfTGV0dGVycyRhc19jcl9kaWdpdHMKKworCisgIGFz
X2xpbmVub18xPSRMSU5FTk8gYXNfbGluZW5vXzFhPSRMSU5FTk8KKyAgYXNfbGluZW5vXzI9JExJ
TkVOTyBhc19saW5lbm9fMmE9JExJTkVOTworICBldmFsICd0ZXN0ICJ4JGFzX2xpbmVub18xJyRh
c19ydW4nIiAhPSAieCRhc19saW5lbm9fMickYXNfcnVuJyIgJiYKKyAgdGVzdCAieGBleHByICRh
c19saW5lbm9fMSckYXNfcnVuJyArIDFgIiA9ICJ4JGFzX2xpbmVub18yJyRhc19ydW4nIicgfHwg
eworICAjIEJsYW1lIExlZSBFLiBNY01haG9uICgxOTMxLTE5ODkpIGZvciBzZWQncyBzeW50YXgu
ICA6LSkKKyAgc2VkIC1uICcKKyAgICBwCisgICAgL1skXUxJTkVOTy89CisgICcgPCRhc19teXNl
bGYgfAorICAgIHNlZCAnCisgICAgICBzL1skXUxJTkVOTy4qLyYtLworICAgICAgdCBsaW5lbm8K
KyAgICAgIGIKKyAgICAgIDpsaW5lbm8KKyAgICAgIE4KKyAgICAgIDpsb29wCisgICAgICBzL1sk
XUxJTkVOT1woW14nJGFzX2NyX2FsbnVtJ19dLipcblwpXCguKlwpL1wyXDFcMi8KKyAgICAgIHQg
bG9vcAorICAgICAgcy8tXG4uKi8vCisgICAgJyA+JGFzX21lLmxpbmVubyAmJgorICBjaG1vZCAr
eCAiJGFzX21lLmxpbmVubyIgfHwKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjYW5u
b3QgY3JlYXRlICRhc19tZS5saW5lbm87IHJlcnVuIHdpdGggYSBQT1NJWCBzaGVsbCIgPiYyOyBh
c19mbl9leGl0IDE7IH0KKworICAjIERvbid0IHRyeSB0byBleGVjIGFzIGl0IGNoYW5nZXMgJFsw
XSwgY2F1c2luZyBhbGwgc29ydCBvZiBwcm9ibGVtcworICAjICh0aGUgZGlybmFtZSBvZiAkWzBd
IGlzIG5vdCB0aGUgcGxhY2Ugd2hlcmUgd2UgbWlnaHQgZmluZCB0aGUKKyAgIyBvcmlnaW5hbCBh
bmQgc28gb24uICBBdXRvY29uZiBpcyBlc3BlY2lhbGx5IHNlbnNpdGl2ZSB0byB0aGlzKS4KKyAg
LiAiLi8kYXNfbWUubGluZW5vIgorICAjIEV4aXQgc3RhdHVzIGlzIHRoYXQgb2YgdGhlIGxhc3Qg
Y29tbWFuZC4KKyAgZXhpdAorfQorCitFQ0hPX0M9IEVDSE9fTj0gRUNIT19UPQorY2FzZSBgZWNo
byAtbiB4YCBpbiAjKCgoKCgKKy1uKikKKyAgY2FzZSBgZWNobyAneHlcYydgIGluCisgICpjKikg
RUNIT19UPScJJzs7CSMgRUNIT19UIGlzIHNpbmdsZSB0YWIgY2hhcmFjdGVyLgorICB4eSkgIEVD
SE9fQz0nXGMnOzsKKyAgKikgICBlY2hvIGBlY2hvIGtzaDg4IGJ1ZyBvbiBBSVggNi4xYCA+IC9k
ZXYvbnVsbAorICAgICAgIEVDSE9fVD0nCSc7OworICBlc2FjOzsKKyopCisgIEVDSE9fTj0nLW4n
OzsKK2VzYWMKKworcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmZpbGUKK2lmIHRlc3Qg
LWQgY29uZiQkLmRpcjsgdGhlbgorICBybSAtZiBjb25mJCQuZGlyL2NvbmYkJC5maWxlCitlbHNl
CisgIHJtIC1mIGNvbmYkJC5kaXIKKyAgbWtkaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAorZmkK
K2lmIChlY2hvID5jb25mJCQuZmlsZSkgMj4vZGV2L251bGw7IHRoZW4KKyAgaWYgbG4gLXMgY29u
ZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz0nbG4gLXMnCisg
ICAgIyAuLi4gYnV0IHRoZXJlIGFyZSB0d28gZ290Y2hhczoKKyAgICAjIDEpIE9uIE1TWVMsIGJv
dGggYGxuIC1zIGZpbGUgZGlyJyBhbmQgYGxuIGZpbGUgZGlyJyBmYWlsLgorICAgICMgMikgREpH
UFAgPCAyLjA0IGhhcyBubyBzeW1saW5rczsgYGxuIC1zJyBjcmVhdGVzIGEgd3JhcHBlciBleGVj
dXRhYmxlLgorICAgICMgSW4gYm90aCBjYXNlcywgd2UgaGF2ZSB0byBkZWZhdWx0IHRvIGBjcCAt
cCcuCisgICAgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQkLmRpciAyPi9kZXYvbnVsbCAmJiB0ZXN0
ICEgLWYgY29uZiQkLmV4ZSB8fAorICAgICAgYXNfbG5fcz0nY3AgLXAnCisgIGVsaWYgbG4gY29u
ZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz1sbgorICBlbHNl
CisgICAgYXNfbG5fcz0nY3AgLXAnCisgIGZpCitlbHNlCisgIGFzX2xuX3M9J2NwIC1wJworZmkK
K3JtIC1mIGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5kaXIvY29uZiQkLmZpbGUgY29uZiQkLmZp
bGUKK3JtZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwKKworaWYgbWtkaXIgLXAgLiAyPi9kZXYv
bnVsbDsgdGhlbgorICBhc19ta2Rpcl9wPSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRl
c3QgLWQgLi8tcCAmJiBybWRpciAuLy1wCisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRl
c3QgLXggLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxz
ZQorICBpZiBscyAtZEwgLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlv
bj1MCisgIGVsc2UKKyAgICBhc19sc19MX29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAg
ICBldmFsIHNoIC1jICdcJycKKyAgICAgIGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQg
IiQxLy4iOworICAgICAgZWxzZQorCWNhc2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwll
c2FjOworCWNhc2UgYGxzIC1sZCckYXNfbHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGlu
ICMoKAorCT8/P1tzeF0qKTo7OyopZmFsc2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2Zp
Cithc19leGVjdXRhYmxlX3A9JGFzX3Rlc3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBh
IHN0cmluZyBvbnRvIGEgdmFsaWQgQ1BQIG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSok
YXNfY3JfbGV0dGVycyVQJGFzX2NyX0xFVFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgor
CisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUg
bmFtZS4KK2FzX3RyX3NoPSJldmFsIHNlZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8l
ZyciCisKKwordGVzdCAtbiAiJERKRElSIiB8fCBleGVjIDc8JjAgPC9kZXYvbnVsbAorZXhlYyA2
PiYxCisKKyMgTmFtZSBvZiB0aGUgaG9zdC4KKyMgaG9zdG5hbWUgb24gc29tZSBzeXN0ZW1zIChT
VlIzLjIsIG9sZCBHTlUvTGludXgpIHJldHVybnMgYSBib2d1cyBleGl0IHN0YXR1cywKKyMgc28g
dW5hbWUgZ2V0cyBydW4gdG9vLgorYWNfaG9zdG5hbWU9YChob3N0bmFtZSB8fCB1bmFtZSAtbikg
Mj4vZGV2L251bGwgfCBzZWQgMXFgCisKKyMKKyMgSW5pdGlhbGl6YXRpb25zLgorIworYWNfZGVm
YXVsdF9wcmVmaXg9L3Vzci9sb2NhbAorYWNfY2xlYW5fZmlsZXM9CithY19jb25maWdfbGlib2Jq
X2Rpcj0uCitMSUJPQkpTPQorY3Jvc3NfY29tcGlsaW5nPW5vCitzdWJkaXJzPQorTUZMQUdTPQor
TUFLRUZMQUdTPQorCisjIElkZW50aXR5IG9mIHRoaXMgcGFja2FnZS4KK1BBQ0tBR0VfTkFNRT0n
WGVuIEh5cGVydmlzb3InCitQQUNLQUdFX1RBUk5BTUU9J3hlbi1oeXBlcnZpc29yJworUEFDS0FH
RV9WRVJTSU9OPSc0LjInCitQQUNLQUdFX1NUUklORz0nWGVuIEh5cGVydmlzb3IgNC4yJworUEFD
S0FHRV9CVUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tJworUEFDS0FHRV9V
Ukw9JycKKworYWNfdW5pcXVlX2ZpbGU9ImxpYnhsL2xpYnhsLmMiCithY19kZWZhdWx0X3ByZWZp
eD0vdXNyCisjIEZhY3RvcmluZyBkZWZhdWx0IGhlYWRlcnMgZm9yIG1vc3QgdGVzdHMuCithY19p
bmNsdWRlc19kZWZhdWx0PSJcCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpZmRlZiBIQVZFX1NZU19U
WVBFU19ICisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TWVNf
U1RBVF9ICisjIGluY2x1ZGUgPHN5cy9zdGF0Lmg+CisjZW5kaWYKKyNpZmRlZiBTVERDX0hFQURF
UlMKKyMgaW5jbHVkZSA8c3RkbGliLmg+CisjIGluY2x1ZGUgPHN0ZGRlZi5oPgorI2Vsc2UKKyMg
aWZkZWYgSEFWRV9TVERMSUJfSAorIyAgaW5jbHVkZSA8c3RkbGliLmg+CisjIGVuZGlmCisjZW5k
aWYKKyNpZmRlZiBIQVZFX1NUUklOR19ICisjIGlmICFkZWZpbmVkIFNURENfSEVBREVSUyAmJiBk
ZWZpbmVkIEhBVkVfTUVNT1JZX0gKKyMgIGluY2x1ZGUgPG1lbW9yeS5oPgorIyBlbmRpZgorIyBp
bmNsdWRlIDxzdHJpbmcuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RSSU5HU19ICisjIGluY2x1
ZGUgPHN0cmluZ3MuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfSU5UVFlQRVNfSAorIyBpbmNsdWRl
IDxpbnR0eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TVERJTlRfSAorIyBpbmNsdWRlIDxz
dGRpbnQuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3Rk
Lmg+CisjZW5kaWYiCisKK2FjX2hlYWRlcl9saXN0PQorYWNfZnVuY19saXN0PQorYWNfc3Vic3Rf
dmFycz0nTFRMSUJPQkpTCitQT1dfTElCCitMSUJPQkpTCitBTExPQ0EKK2xpYmljb252CitsaWJn
Y3J5cHQKK2xpYmV4dDJmcworc3lzdGVtX2FpbworTElCX1BBVEgKK1ZOQ09ORklHCitIT1RQTFVH
CitVREVWSU5GTworVURFVkFETQorUFlUSE9OUEFUSAorT0NBTUxCVUlMRAorT0NBTUxET0MKK09D
QU1MTUtMSUIKK09DQU1MTUtUT1AKK09DQU1MREVQCitPQ0FNTAorT0NBTUxPUFRET1RPUFQKK09D
QU1MQ0RPVE9QVAorT0NBTUxCRVNUCitPQ0FNTE9QVAorT0NBTUxMSUIKK09DQU1MVkVSU0lPTgor
T0NBTUxDCitJTlNUQUxMX0RBVEEKK0lOU1RBTExfU0NSSVBUCitJTlNUQUxMX1BST0dSQU0KK1NF
VF9NQUtFCitMTl9TCitTRUQKK1hHRVRURVhUCitCQVNICitYTUwKK0NVUkwKK0ZMRVgKK0JJU09O
CitJUAorQlJDVEwKK1BFUkwKK1BZVEhPTgorQVBQRU5EX0xJQgorQVBQRU5EX0lOQ0xVREVTCitQ
UkVQRU5EX0xJQgorUFJFUEVORF9JTkNMVURFUworZGVidWcKK2xvbW91bnQKK21pbml0ZXJtCitv
Y2FtbHRvb2xzCitweXRob250b29scworeGFwaQordnRwbQorbW9uaXRvcnMKK2dpdGh0dHAKK3hz
bQoraG9zdF9vcworaG9zdF92ZW5kb3IKK2hvc3RfY3B1Citob3N0CitidWlsZF9vcworYnVpbGRf
dmVuZG9yCitidWlsZF9jcHUKK2J1aWxkCitFR1JFUAorR1JFUAorQ1BQCitPQkpFWFQKK0VYRUVY
VAorYWNfY3RfQ0MKK0NQUEZMQUdTCitMREZMQUdTCitDRkxBR1MKK0NDCit0YXJnZXRfYWxpYXMK
K2hvc3RfYWxpYXMKK2J1aWxkX2FsaWFzCitMSUJTCitFQ0hPX1QKK0VDSE9fTgorRUNIT19DCitE
RUZTCittYW5kaXIKK2xvY2FsZWRpcgorbGliZGlyCitwc2RpcgorcGRmZGlyCitkdmlkaXIKK2h0
bWxkaXIKK2luZm9kaXIKK2RvY2Rpcgorb2xkaW5jbHVkZWRpcgoraW5jbHVkZWRpcgorbG9jYWxz
dGF0ZWRpcgorc2hhcmVkc3RhdGVkaXIKK3N5c2NvbmZkaXIKK2RhdGFkaXIKK2RhdGFyb290ZGly
CitsaWJleGVjZGlyCitzYmluZGlyCitiaW5kaXIKK3Byb2dyYW1fdHJhbnNmb3JtX25hbWUKK3By
ZWZpeAorZXhlY19wcmVmaXgKK1BBQ0tBR0VfVVJMCitQQUNLQUdFX0JVR1JFUE9SVAorUEFDS0FH
RV9TVFJJTkcKK1BBQ0tBR0VfVkVSU0lPTgorUEFDS0FHRV9UQVJOQU1FCitQQUNLQUdFX05BTUUK
K1BBVEhfU0VQQVJBVE9SCitTSEVMTCcKK2FjX3N1YnN0X2ZpbGVzPScnCithY191c2VyX29wdHM9
JworZW5hYmxlX29wdGlvbl9jaGVja2luZworZW5hYmxlX3hzbQorZW5hYmxlX2dpdGh0dHAKK2Vu
YWJsZV9tb25pdG9ycworZW5hYmxlX3Z0cG0KK2VuYWJsZV94YXBpCitlbmFibGVfcHl0aG9udG9v
bHMKK2VuYWJsZV9vY2FtbHRvb2xzCitlbmFibGVfbWluaXRlcm0KK2VuYWJsZV9sb21vdW50Citl
bmFibGVfZGVidWcKKycKKyAgICAgIGFjX3ByZWNpb3VzX3ZhcnM9J2J1aWxkX2FsaWFzCitob3N0
X2FsaWFzCit0YXJnZXRfYWxpYXMKK0NDCitDRkxBR1MKK0xERkxBR1MKK0xJQlMKK0NQUEZMQUdT
CitDUFAKK1BSRVBFTkRfSU5DTFVERVMKK1BSRVBFTkRfTElCCitBUFBFTkRfSU5DTFVERVMKK0FQ
UEVORF9MSUIKK1BZVEhPTgorUEVSTAorQlJDVEwKK0lQCitCSVNPTgorRkxFWAorQ1VSTAorWE1M
CitCQVNICitYR0VUVEVYVCcKKworCisjIEluaXRpYWxpemUgc29tZSB2YXJpYWJsZXMgc2V0IGJ5
IG9wdGlvbnMuCithY19pbml0X2hlbHA9CithY19pbml0X3ZlcnNpb249ZmFsc2UKK2FjX3VucmVj
b2duaXplZF9vcHRzPQorYWNfdW5yZWNvZ25pemVkX3NlcD0KKyMgVGhlIHZhcmlhYmxlcyBoYXZl
IHRoZSBzYW1lIG5hbWVzIGFzIHRoZSBvcHRpb25zLCB3aXRoCisjIGRhc2hlcyBjaGFuZ2VkIHRv
IHVuZGVybGluZXMuCitjYWNoZV9maWxlPS9kZXYvbnVsbAorZXhlY19wcmVmaXg9Tk9ORQorbm9f
Y3JlYXRlPQorbm9fcmVjdXJzaW9uPQorcHJlZml4PU5PTkUKK3Byb2dyYW1fcHJlZml4PU5PTkUK
K3Byb2dyYW1fc3VmZml4PU5PTkUKK3Byb2dyYW1fdHJhbnNmb3JtX25hbWU9cyx4LHgsCitzaWxl
bnQ9CitzaXRlPQorc3JjZGlyPQordmVyYm9zZT0KK3hfaW5jbHVkZXM9Tk9ORQoreF9saWJyYXJp
ZXM9Tk9ORQorCisjIEluc3RhbGxhdGlvbiBkaXJlY3Rvcnkgb3B0aW9ucy4KKyMgVGhlc2UgYXJl
IGxlZnQgdW5leHBhbmRlZCBzbyB1c2VycyBjYW4gIm1ha2UgaW5zdGFsbCBleGVjX3ByZWZpeD0v
Zm9vIgorIyBhbmQgYWxsIHRoZSB2YXJpYWJsZXMgdGhhdCBhcmUgc3VwcG9zZWQgdG8gYmUgYmFz
ZWQgb24gZXhlY19wcmVmaXgKKyMgYnkgZGVmYXVsdCB3aWxsIGFjdHVhbGx5IGNoYW5nZS4KKyMg
VXNlIGJyYWNlcyBpbnN0ZWFkIG9mIHBhcmVucyBiZWNhdXNlIHNoLCBwZXJsLCBldGMuIGFsc28g
YWNjZXB0IHRoZW0uCisjIChUaGUgbGlzdCBmb2xsb3dzIHRoZSBzYW1lIG9yZGVyIGFzIHRoZSBH
TlUgQ29kaW5nIFN0YW5kYXJkcy4pCitiaW5kaXI9JyR7ZXhlY19wcmVmaXh9L2JpbicKK3NiaW5k
aXI9JyR7ZXhlY19wcmVmaXh9L3NiaW4nCitsaWJleGVjZGlyPScke2V4ZWNfcHJlZml4fS9saWJl
eGVjJworZGF0YXJvb3RkaXI9JyR7cHJlZml4fS9zaGFyZScKK2RhdGFkaXI9JyR7ZGF0YXJvb3Rk
aXJ9Jworc3lzY29uZmRpcj0nJHtwcmVmaXh9L2V0YycKK3NoYXJlZHN0YXRlZGlyPScke3ByZWZp
eH0vY29tJworbG9jYWxzdGF0ZWRpcj0nJHtwcmVmaXh9L3ZhcicKK2luY2x1ZGVkaXI9JyR7cHJl
Zml4fS9pbmNsdWRlJworb2xkaW5jbHVkZWRpcj0nL3Vzci9pbmNsdWRlJworZG9jZGlyPScke2Rh
dGFyb290ZGlyfS9kb2MvJHtQQUNLQUdFX1RBUk5BTUV9JworaW5mb2Rpcj0nJHtkYXRhcm9vdGRp
cn0vaW5mbycKK2h0bWxkaXI9JyR7ZG9jZGlyfScKK2R2aWRpcj0nJHtkb2NkaXJ9JworcGRmZGly
PScke2RvY2Rpcn0nCitwc2Rpcj0nJHtkb2NkaXJ9JworbGliZGlyPScke2V4ZWNfcHJlZml4fS9s
aWInCitsb2NhbGVkaXI9JyR7ZGF0YXJvb3RkaXJ9L2xvY2FsZScKK21hbmRpcj0nJHtkYXRhcm9v
dGRpcn0vbWFuJworCithY19wcmV2PQorYWNfZGFzaGRhc2g9Citmb3IgYWNfb3B0aW9uCitkbwor
ICAjIElmIHRoZSBwcmV2aW91cyBvcHRpb24gbmVlZHMgYW4gYXJndW1lbnQsIGFzc2lnbiBpdC4K
KyAgaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgICAgZXZhbCAkYWNfcHJldj1cJGFjX29w
dGlvbgorICAgIGFjX3ByZXY9CisgICAgY29udGludWUKKyAgZmkKKworICBjYXNlICRhY19vcHRp
b24gaW4KKyAgKj0/KikgYWNfb3B0YXJnPWBleHByICJYJGFjX29wdGlvbiIgOiAnW149XSo9XCgu
KlwpJ2AgOzsKKyAgKj0pICAgYWNfb3B0YXJnPSA7OworICAqKSAgICBhY19vcHRhcmc9eWVzIDs7
CisgIGVzYWMKKworICAjIEFjY2VwdCB0aGUgaW1wb3J0YW50IEN5Z251cyBjb25maWd1cmUgb3B0
aW9ucywgc28gd2UgY2FuIGRpYWdub3NlIHR5cG9zLgorCisgIGNhc2UgJGFjX2Rhc2hkYXNoJGFj
X29wdGlvbiBpbgorICAtLSkKKyAgICBhY19kYXNoZGFzaD15ZXMgOzsKKworICAtYmluZGlyIHwg
LS1iaW5kaXIgfCAtLWJpbmRpIHwgLS1iaW5kIHwgLS1iaW4gfCAtLWJpKQorICAgIGFjX3ByZXY9
YmluZGlyIDs7CisgIC1iaW5kaXI9KiB8IC0tYmluZGlyPSogfCAtLWJpbmRpPSogfCAtLWJpbmQ9
KiB8IC0tYmluPSogfCAtLWJpPSopCisgICAgYmluZGlyPSRhY19vcHRhcmcgOzsKKworICAtYnVp
bGQgfCAtLWJ1aWxkIHwgLS1idWlsIHwgLS1idWkgfCAtLWJ1KQorICAgIGFjX3ByZXY9YnVpbGRf
YWxpYXMgOzsKKyAgLWJ1aWxkPSogfCAtLWJ1aWxkPSogfCAtLWJ1aWw9KiB8IC0tYnVpPSogfCAt
LWJ1PSopCisgICAgYnVpbGRfYWxpYXM9JGFjX29wdGFyZyA7OworCisgIC1jYWNoZS1maWxlIHwg
LS1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWwgfCAtLWNhY2hlLWZpIFwKKyAgfCAtLWNhY2hlLWYg
fCAtLWNhY2hlLSB8IC0tY2FjaGUgfCAtLWNhY2ggfCAtLWNhYyB8IC0tY2EgfCAtLWMpCisgICAg
YWNfcHJldj1jYWNoZV9maWxlIDs7CisgIC1jYWNoZS1maWxlPSogfCAtLWNhY2hlLWZpbGU9KiB8
IC0tY2FjaGUtZmlsPSogfCAtLWNhY2hlLWZpPSogXAorICB8IC0tY2FjaGUtZj0qIHwgLS1jYWNo
ZS09KiB8IC0tY2FjaGU9KiB8IC0tY2FjaD0qIHwgLS1jYWM9KiB8IC0tY2E9KiB8IC0tYz0qKQor
ICAgIGNhY2hlX2ZpbGU9JGFjX29wdGFyZyA7OworCisgIC0tY29uZmlnLWNhY2hlIHwgLUMpCisg
ICAgY2FjaGVfZmlsZT1jb25maWcuY2FjaGUgOzsKKworICAtZGF0YWRpciB8IC0tZGF0YWRpciB8
IC0tZGF0YWRpIHwgLS1kYXRhZCkKKyAgICBhY19wcmV2PWRhdGFkaXIgOzsKKyAgLWRhdGFkaXI9
KiB8IC0tZGF0YWRpcj0qIHwgLS1kYXRhZGk9KiB8IC0tZGF0YWQ9KikKKyAgICBkYXRhZGlyPSRh
Y19vcHRhcmcgOzsKKworICAtZGF0YXJvb3RkaXIgfCAtLWRhdGFyb290ZGlyIHwgLS1kYXRhcm9v
dGRpIHwgLS1kYXRhcm9vdGQgfCAtLWRhdGFyb290IFwKKyAgfCAtLWRhdGFyb28gfCAtLWRhdGFy
byB8IC0tZGF0YXIpCisgICAgYWNfcHJldj1kYXRhcm9vdGRpciA7OworICAtZGF0YXJvb3RkaXI9
KiB8IC0tZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaT0qIHwgLS1kYXRhcm9vdGQ9KiBcCisg
IHwgLS1kYXRhcm9vdD0qIHwgLS1kYXRhcm9vPSogfCAtLWRhdGFybz0qIHwgLS1kYXRhcj0qKQor
ICAgIGRhdGFyb290ZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGlzYWJsZS0qIHwgLS1kaXNhYmxl
LSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19vcHRpb24iIDogJ3gtKmRpc2FibGUtXCgu
KlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFi
bGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51
bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUg
bmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAg
YWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAor
ICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQi
CisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVk
X29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZGlzYWJsZS0kYWNfdXNlcm9wdF9vcmlnIgorCSBh
Y191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVzYWMKKyAgICBldmFsIGVuYWJsZV8kYWNf
dXNlcm9wdD1ubyA7OworCisgIC1kb2NkaXIgfCAtLWRvY2RpciB8IC0tZG9jZGkgfCAtLWRvYyB8
IC0tZG8pCisgICAgYWNfcHJldj1kb2NkaXIgOzsKKyAgLWRvY2Rpcj0qIHwgLS1kb2NkaXI9KiB8
IC0tZG9jZGk9KiB8IC0tZG9jPSogfCAtLWRvPSopCisgICAgZG9jZGlyPSRhY19vcHRhcmcgOzsK
KworICAtZHZpZGlyIHwgLS1kdmlkaXIgfCAtLWR2aWRpIHwgLS1kdmlkIHwgLS1kdmkgfCAtLWR2
KQorICAgIGFjX3ByZXY9ZHZpZGlyIDs7CisgIC1kdmlkaXI9KiB8IC0tZHZpZGlyPSogfCAtLWR2
aWRpPSogfCAtLWR2aWQ9KiB8IC0tZHZpPSogfCAtLWR2PSopCisgICAgZHZpZGlyPSRhY19vcHRh
cmcgOzsKKworICAtZW5hYmxlLSogfCAtLWVuYWJsZS0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIg
IngkYWNfb3B0aW9uIiA6ICd4LSplbmFibGUtXChbXj1dKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1l
cyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRh
Y191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAg
IGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUgbmFtZTogJGFjX3VzZXJvcHQiCisgICAg
YWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRh
Y191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBp
bgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3Vu
cmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3Nl
cC0tZW5hYmxlLSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7
CisgICAgZXNhYworICAgIGV2YWwgZW5hYmxlXyRhY191c2Vyb3B0PVwkYWNfb3B0YXJnIDs7CisK
KyAgLWV4ZWMtcHJlZml4IHwgLS1leGVjX3ByZWZpeCB8IC0tZXhlYy1wcmVmaXggfCAtLWV4ZWMt
cHJlZmkgXAorICB8IC0tZXhlYy1wcmVmIHwgLS1leGVjLXByZSB8IC0tZXhlYy1wciB8IC0tZXhl
Yy1wIHwgLS1leGVjLSBcCisgIHwgLS1leGVjIHwgLS1leGUgfCAtLWV4KQorICAgIGFjX3ByZXY9
ZXhlY19wcmVmaXggOzsKKyAgLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWNfcHJlZml4PSogfCAtLWV4
ZWMtcHJlZml4PSogfCAtLWV4ZWMtcHJlZmk9KiBcCisgIHwgLS1leGVjLXByZWY9KiB8IC0tZXhl
Yy1wcmU9KiB8IC0tZXhlYy1wcj0qIHwgLS1leGVjLXA9KiB8IC0tZXhlYy09KiBcCisgIHwgLS1l
eGVjPSogfCAtLWV4ZT0qIHwgLS1leD0qKQorICAgIGV4ZWNfcHJlZml4PSRhY19vcHRhcmcgOzsK
KworICAtZ2FzIHwgLS1nYXMgfCAtLWdhIHwgLS1nKQorICAgICMgT2Jzb2xldGU7IHVzZSAtLXdp
dGgtZ2FzLgorICAgIHdpdGhfZ2FzPXllcyA7OworCisgIC1oZWxwIHwgLS1oZWxwIHwgLS1oZWwg
fCAtLWhlIHwgLWgpCisgICAgYWNfaW5pdF9oZWxwPWxvbmcgOzsKKyAgLWhlbHA9ciogfCAtLWhl
bHA9ciogfCAtLWhlbD1yKiB8IC0taGU9ciogfCAtaHIqKQorICAgIGFjX2luaXRfaGVscD1yZWN1
cnNpdmUgOzsKKyAgLWhlbHA9cyogfCAtLWhlbHA9cyogfCAtLWhlbD1zKiB8IC0taGU9cyogfCAt
aHMqKQorICAgIGFjX2luaXRfaGVscD1zaG9ydCA7OworCisgIC1ob3N0IHwgLS1ob3N0IHwgLS1o
b3MgfCAtLWhvKQorICAgIGFjX3ByZXY9aG9zdF9hbGlhcyA7OworICAtaG9zdD0qIHwgLS1ob3N0
PSogfCAtLWhvcz0qIHwgLS1obz0qKQorICAgIGhvc3RfYWxpYXM9JGFjX29wdGFyZyA7OworCisg
IC1odG1sZGlyIHwgLS1odG1sZGlyIHwgLS1odG1sZGkgfCAtLWh0bWxkIHwgLS1odG1sIHwgLS1o
dG0gfCAtLWh0KQorICAgIGFjX3ByZXY9aHRtbGRpciA7OworICAtaHRtbGRpcj0qIHwgLS1odG1s
ZGlyPSogfCAtLWh0bWxkaT0qIHwgLS1odG1sZD0qIHwgLS1odG1sPSogfCAtLWh0bT0qIFwKKyAg
fCAtLWh0PSopCisgICAgaHRtbGRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWluY2x1ZGVkaXIgfCAt
LWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaSB8IC0taW5jbHVkZWQgfCAtLWluY2x1ZGUgXAorICB8
IC0taW5jbHVkIHwgLS1pbmNsdSB8IC0taW5jbCB8IC0taW5jKQorICAgIGFjX3ByZXY9aW5jbHVk
ZWRpciA7OworICAtaW5jbHVkZWRpcj0qIHwgLS1pbmNsdWRlZGlyPSogfCAtLWluY2x1ZGVkaT0q
IHwgLS1pbmNsdWRlZD0qIHwgLS1pbmNsdWRlPSogXAorICB8IC0taW5jbHVkPSogfCAtLWluY2x1
PSogfCAtLWluY2w9KiB8IC0taW5jPSopCisgICAgaW5jbHVkZWRpcj0kYWNfb3B0YXJnIDs7CisK
KyAgLWluZm9kaXIgfCAtLWluZm9kaXIgfCAtLWluZm9kaSB8IC0taW5mb2QgfCAtLWluZm8gfCAt
LWluZikKKyAgICBhY19wcmV2PWluZm9kaXIgOzsKKyAgLWluZm9kaXI9KiB8IC0taW5mb2Rpcj0q
IHwgLS1pbmZvZGk9KiB8IC0taW5mb2Q9KiB8IC0taW5mbz0qIHwgLS1pbmY9KikKKyAgICBpbmZv
ZGlyPSRhY19vcHRhcmcgOzsKKworICAtbGliZGlyIHwgLS1saWJkaXIgfCAtLWxpYmRpIHwgLS1s
aWJkKQorICAgIGFjX3ByZXY9bGliZGlyIDs7CisgIC1saWJkaXI9KiB8IC0tbGliZGlyPSogfCAt
LWxpYmRpPSogfCAtLWxpYmQ9KikKKyAgICBsaWJkaXI9JGFjX29wdGFyZyA7OworCisgIC1saWJl
eGVjZGlyIHwgLS1saWJleGVjZGlyIHwgLS1saWJleGVjZGkgfCAtLWxpYmV4ZWNkIHwgLS1saWJl
eGVjIFwKKyAgfCAtLWxpYmV4ZSB8IC0tbGliZXggfCAtLWxpYmUpCisgICAgYWNfcHJldj1saWJl
eGVjZGlyIDs7CisgIC1saWJleGVjZGlyPSogfCAtLWxpYmV4ZWNkaXI9KiB8IC0tbGliZXhlY2Rp
PSogfCAtLWxpYmV4ZWNkPSogfCAtLWxpYmV4ZWM9KiBcCisgIHwgLS1saWJleGU9KiB8IC0tbGli
ZXg9KiB8IC0tbGliZT0qKQorICAgIGxpYmV4ZWNkaXI9JGFjX29wdGFyZyA7OworCisgIC1sb2Nh
bGVkaXIgfCAtLWxvY2FsZWRpciB8IC0tbG9jYWxlZGkgfCAtLWxvY2FsZWQgfCAtLWxvY2FsZSkK
KyAgICBhY19wcmV2PWxvY2FsZWRpciA7OworICAtbG9jYWxlZGlyPSogfCAtLWxvY2FsZWRpcj0q
IHwgLS1sb2NhbGVkaT0qIHwgLS1sb2NhbGVkPSogfCAtLWxvY2FsZT0qKQorICAgIGxvY2FsZWRp
cj0kYWNfb3B0YXJnIDs7CisKKyAgLWxvY2Fsc3RhdGVkaXIgfCAtLWxvY2Fsc3RhdGVkaXIgfCAt
LWxvY2Fsc3RhdGVkaSB8IC0tbG9jYWxzdGF0ZWQgXAorICB8IC0tbG9jYWxzdGF0ZSB8IC0tbG9j
YWxzdGF0IHwgLS1sb2NhbHN0YSB8IC0tbG9jYWxzdCB8IC0tbG9jYWxzKQorICAgIGFjX3ByZXY9
bG9jYWxzdGF0ZWRpciA7OworICAtbG9jYWxzdGF0ZWRpcj0qIHwgLS1sb2NhbHN0YXRlZGlyPSog
fCAtLWxvY2Fsc3RhdGVkaT0qIHwgLS1sb2NhbHN0YXRlZD0qIFwKKyAgfCAtLWxvY2Fsc3RhdGU9
KiB8IC0tbG9jYWxzdGF0PSogfCAtLWxvY2Fsc3RhPSogfCAtLWxvY2Fsc3Q9KiB8IC0tbG9jYWxz
PSopCisgICAgbG9jYWxzdGF0ZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLW1hbmRpciB8IC0tbWFu
ZGlyIHwgLS1tYW5kaSB8IC0tbWFuZCB8IC0tbWFuIHwgLS1tYSB8IC0tbSkKKyAgICBhY19wcmV2
PW1hbmRpciA7OworICAtbWFuZGlyPSogfCAtLW1hbmRpcj0qIHwgLS1tYW5kaT0qIHwgLS1tYW5k
PSogfCAtLW1hbj0qIHwgLS1tYT0qIHwgLS1tPSopCisgICAgbWFuZGlyPSRhY19vcHRhcmcgOzsK
KworICAtbmZwIHwgLS1uZnAgfCAtLW5mKQorICAgICMgT2Jzb2xldGU7IHVzZSAtLXdpdGhvdXQt
ZnAuCisgICAgd2l0aF9mcD1ubyA7OworCisgIC1uby1jcmVhdGUgfCAtLW5vLWNyZWF0ZSB8IC0t
bm8tY3JlYXQgfCAtLW5vLWNyZWEgfCAtLW5vLWNyZSBcCisgIHwgLS1uby1jciB8IC0tbm8tYyB8
IC1uKQorICAgIG5vX2NyZWF0ZT15ZXMgOzsKKworICAtbm8tcmVjdXJzaW9uIHwgLS1uby1yZWN1
cnNpb24gfCAtLW5vLXJlY3Vyc2lvIHwgLS1uby1yZWN1cnNpIFwKKyAgfCAtLW5vLXJlY3VycyB8
IC0tbm8tcmVjdXIgfCAtLW5vLXJlY3UgfCAtLW5vLXJlYyB8IC0tbm8tcmUgfCAtLW5vLXIpCisg
ICAgbm9fcmVjdXJzaW9uPXllcyA7OworCisgIC1vbGRpbmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRl
ZGlyIHwgLS1vbGRpbmNsdWRlZGkgfCAtLW9sZGluY2x1ZGVkIFwKKyAgfCAtLW9sZGluY2x1ZGUg
fCAtLW9sZGluY2x1ZCB8IC0tb2xkaW5jbHUgfCAtLW9sZGluY2wgfCAtLW9sZGluYyBcCisgIHwg
LS1vbGRpbiB8IC0tb2xkaSB8IC0tb2xkIHwgLS1vbCB8IC0tbykKKyAgICBhY19wcmV2PW9sZGlu
Y2x1ZGVkaXIgOzsKKyAgLW9sZGluY2x1ZGVkaXI9KiB8IC0tb2xkaW5jbHVkZWRpcj0qIHwgLS1v
bGRpbmNsdWRlZGk9KiB8IC0tb2xkaW5jbHVkZWQ9KiBcCisgIHwgLS1vbGRpbmNsdWRlPSogfCAt
LW9sZGluY2x1ZD0qIHwgLS1vbGRpbmNsdT0qIHwgLS1vbGRpbmNsPSogfCAtLW9sZGluYz0qIFwK
KyAgfCAtLW9sZGluPSogfCAtLW9sZGk9KiB8IC0tb2xkPSogfCAtLW9sPSogfCAtLW89KikKKyAg
ICBvbGRpbmNsdWRlZGlyPSRhY19vcHRhcmcgOzsKKworICAtcHJlZml4IHwgLS1wcmVmaXggfCAt
LXByZWZpIHwgLS1wcmVmIHwgLS1wcmUgfCAtLXByIHwgLS1wKQorICAgIGFjX3ByZXY9cHJlZml4
IDs7CisgIC1wcmVmaXg9KiB8IC0tcHJlZml4PSogfCAtLXByZWZpPSogfCAtLXByZWY9KiB8IC0t
cHJlPSogfCAtLXByPSogfCAtLXA9KikKKyAgICBwcmVmaXg9JGFjX29wdGFyZyA7OworCisgIC1w
cm9ncmFtLXByZWZpeCB8IC0tcHJvZ3JhbS1wcmVmaXggfCAtLXByb2dyYW0tcHJlZmkgfCAtLXBy
b2dyYW0tcHJlZiBcCisgIHwgLS1wcm9ncmFtLXByZSB8IC0tcHJvZ3JhbS1wciB8IC0tcHJvZ3Jh
bS1wKQorICAgIGFjX3ByZXY9cHJvZ3JhbV9wcmVmaXggOzsKKyAgLXByb2dyYW0tcHJlZml4PSog
fCAtLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZmk9KiBcCisgIHwgLS1wcm9ncmFt
LXByZWY9KiB8IC0tcHJvZ3JhbS1wcmU9KiB8IC0tcHJvZ3JhbS1wcj0qIHwgLS1wcm9ncmFtLXA9
KikKKyAgICBwcm9ncmFtX3ByZWZpeD0kYWNfb3B0YXJnIDs7CisKKyAgLXByb2dyYW0tc3VmZml4
IHwgLS1wcm9ncmFtLXN1ZmZpeCB8IC0tcHJvZ3JhbS1zdWZmaSB8IC0tcHJvZ3JhbS1zdWZmIFwK
KyAgfCAtLXByb2dyYW0tc3VmIHwgLS1wcm9ncmFtLXN1IHwgLS1wcm9ncmFtLXMpCisgICAgYWNf
cHJldj1wcm9ncmFtX3N1ZmZpeCA7OworICAtcHJvZ3JhbS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1z
dWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaT0qIFwKKyAgfCAtLXByb2dyYW0tc3VmZj0qIHwgLS1w
cm9ncmFtLXN1Zj0qIHwgLS1wcm9ncmFtLXN1PSogfCAtLXByb2dyYW0tcz0qKQorICAgIHByb2dy
YW1fc3VmZml4PSRhY19vcHRhcmcgOzsKKworICAtcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSB8IC0t
cHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYW0gfCAt
LXByb2dyYW0tdHJhbnNmb3JtLW5hIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW4gfCAtLXBy
b2dyYW0tdHJhbnNmb3JtLSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybSB8IC0tcHJvZ3JhbS10
cmFuc2ZvciBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm8gfCAtLXByb2dyYW0tdHJhbnNmIFwKKyAg
fCAtLXByb2dyYW0tdHJhbnMgfCAtLXByb2dyYW0tdHJhbiBcCisgIHwgLS1wcm9nci10cmEgfCAt
LXByb2dyYW0tdHIgfCAtLXByb2dyYW0tdCkKKyAgICBhY19wcmV2PXByb2dyYW1fdHJhbnNmb3Jt
X25hbWUgOzsKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5hbWU9KiB8IC0tcHJvZ3JhbS10cmFuc2Zv
cm0tbmFtZT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hbT0qIHwgLS1wcm9ncmFtLXRy
YW5zZm9ybS1uYT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtLW49KiB8IC0tcHJvZ3JhbS10
cmFuc2Zvcm0tPSogXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm09KiB8IC0tcHJvZ3JhbS10cmFu
c2Zvcj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmbz0qIHwgLS1wcm9ncmFtLXRyYW5zZj0qIFwK
KyAgfCAtLXByb2dyYW0tdHJhbnM9KiB8IC0tcHJvZ3JhbS10cmFuPSogXAorICB8IC0tcHJvZ3It
dHJhPSogfCAtLXByb2dyYW0tdHI9KiB8IC0tcHJvZ3JhbS10PSopCisgICAgcHJvZ3JhbV90cmFu
c2Zvcm1fbmFtZT0kYWNfb3B0YXJnIDs7CisKKyAgLXBkZmRpciB8IC0tcGRmZGlyIHwgLS1wZGZk
aSB8IC0tcGRmZCB8IC0tcGRmIHwgLS1wZCkKKyAgICBhY19wcmV2PXBkZmRpciA7OworICAtcGRm
ZGlyPSogfCAtLXBkZmRpcj0qIHwgLS1wZGZkaT0qIHwgLS1wZGZkPSogfCAtLXBkZj0qIHwgLS1w
ZD0qKQorICAgIHBkZmRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXBzZGlyIHwgLS1wc2RpciB8IC0t
cHNkaSB8IC0tcHNkIHwgLS1wcykKKyAgICBhY19wcmV2PXBzZGlyIDs7CisgIC1wc2Rpcj0qIHwg
LS1wc2Rpcj0qIHwgLS1wc2RpPSogfCAtLXBzZD0qIHwgLS1wcz0qKQorICAgIHBzZGlyPSRhY19v
cHRhcmcgOzsKKworICAtcSB8IC1xdWlldCB8IC0tcXVpZXQgfCAtLXF1aWUgfCAtLXF1aSB8IC0t
cXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2lsZW4gfCAtLXNpbGUgfCAt
LXNpbCkKKyAgICBzaWxlbnQ9eWVzIDs7CisKKyAgLXNiaW5kaXIgfCAtLXNiaW5kaXIgfCAtLXNi
aW5kaSB8IC0tc2JpbmQgfCAtLXNiaW4gfCAtLXNiaSB8IC0tc2IpCisgICAgYWNfcHJldj1zYmlu
ZGlyIDs7CisgIC1zYmluZGlyPSogfCAtLXNiaW5kaXI9KiB8IC0tc2JpbmRpPSogfCAtLXNiaW5k
PSogfCAtLXNiaW49KiBcCisgIHwgLS1zYmk9KiB8IC0tc2I9KikKKyAgICBzYmluZGlyPSRhY19v
cHRhcmcgOzsKKworICAtc2hhcmVkc3RhdGVkaXIgfCAtLXNoYXJlZHN0YXRlZGlyIHwgLS1zaGFy
ZWRzdGF0ZWRpIFwKKyAgfCAtLXNoYXJlZHN0YXRlZCB8IC0tc2hhcmVkc3RhdGUgfCAtLXNoYXJl
ZHN0YXQgfCAtLXNoYXJlZHN0YSBcCisgIHwgLS1zaGFyZWRzdCB8IC0tc2hhcmVkcyB8IC0tc2hh
cmVkIHwgLS1zaGFyZSB8IC0tc2hhciBcCisgIHwgLS1zaGEgfCAtLXNoKQorICAgIGFjX3ByZXY9
c2hhcmVkc3RhdGVkaXIgOzsKKyAgLXNoYXJlZHN0YXRlZGlyPSogfCAtLXNoYXJlZHN0YXRlZGly
PSogfCAtLXNoYXJlZHN0YXRlZGk9KiBcCisgIHwgLS1zaGFyZWRzdGF0ZWQ9KiB8IC0tc2hhcmVk
c3RhdGU9KiB8IC0tc2hhcmVkc3RhdD0qIHwgLS1zaGFyZWRzdGE9KiBcCisgIHwgLS1zaGFyZWRz
dD0qIHwgLS1zaGFyZWRzPSogfCAtLXNoYXJlZD0qIHwgLS1zaGFyZT0qIHwgLS1zaGFyPSogXAor
ICB8IC0tc2hhPSogfCAtLXNoPSopCisgICAgc2hhcmVkc3RhdGVkaXI9JGFjX29wdGFyZyA7Owor
CisgIC1zaXRlIHwgLS1zaXRlIHwgLS1zaXQpCisgICAgYWNfcHJldj1zaXRlIDs7CisgIC1zaXRl
PSogfCAtLXNpdGU9KiB8IC0tc2l0PSopCisgICAgc2l0ZT0kYWNfb3B0YXJnIDs7CisKKyAgLXNy
Y2RpciB8IC0tc3JjZGlyIHwgLS1zcmNkaSB8IC0tc3JjZCB8IC0tc3JjIHwgLS1zcikKKyAgICBh
Y19wcmV2PXNyY2RpciA7OworICAtc3JjZGlyPSogfCAtLXNyY2Rpcj0qIHwgLS1zcmNkaT0qIHwg
LS1zcmNkPSogfCAtLXNyYz0qIHwgLS1zcj0qKQorICAgIHNyY2Rpcj0kYWNfb3B0YXJnIDs7CisK
KyAgLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaSB8IC0tc3lzY29uZmQg
fCAtLXN5c2NvbmYgXAorICB8IC0tc3lzY29uIHwgLS1zeXNjbyB8IC0tc3lzYyB8IC0tc3lzIHwg
LS1zeSkKKyAgICBhY19wcmV2PXN5c2NvbmZkaXIgOzsKKyAgLXN5c2NvbmZkaXI9KiB8IC0tc3lz
Y29uZmRpcj0qIHwgLS1zeXNjb25mZGk9KiB8IC0tc3lzY29uZmQ9KiB8IC0tc3lzY29uZj0qIFwK
KyAgfCAtLXN5c2Nvbj0qIHwgLS1zeXNjbz0qIHwgLS1zeXNjPSogfCAtLXN5cz0qIHwgLS1zeT0q
KQorICAgIHN5c2NvbmZkaXI9JGFjX29wdGFyZyA7OworCisgIC10YXJnZXQgfCAtLXRhcmdldCB8
IC0tdGFyZ2UgfCAtLXRhcmcgfCAtLXRhciB8IC0tdGEgfCAtLXQpCisgICAgYWNfcHJldj10YXJn
ZXRfYWxpYXMgOzsKKyAgLXRhcmdldD0qIHwgLS10YXJnZXQ9KiB8IC0tdGFyZ2U9KiB8IC0tdGFy
Zz0qIHwgLS10YXI9KiB8IC0tdGE9KiB8IC0tdD0qKQorICAgIHRhcmdldF9hbGlhcz0kYWNfb3B0
YXJnIDs7CisKKyAgLXYgfCAtdmVyYm9zZSB8IC0tdmVyYm9zZSB8IC0tdmVyYm9zIHwgLS12ZXJi
byB8IC0tdmVyYikKKyAgICB2ZXJib3NlPXllcyA7OworCisgIC12ZXJzaW9uIHwgLS12ZXJzaW9u
IHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwgLVYpCisgICAgYWNfaW5pdF92ZXJzaW9u
PTogOzsKKworICAtd2l0aC0qIHwgLS13aXRoLSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRh
Y19vcHRpb24iIDogJ3gtKndpdGgtXChbXj1dKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0
IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vy
b3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2Zu
X2Vycm9yICQ/ICJpbnZhbGlkIHBhY2thZ2UgbmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNl
cm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vy
b3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAg
ICAgKiIKKyJ3aXRoXyRhY191c2Vyb3B0IgorIiopIDs7CisgICAgICAqKSBhY191bnJlY29nbml6
ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFjX3VucmVjb2duaXplZF9zZXAtLXdpdGgt
JGFjX3VzZXJvcHRfb3JpZyIKKwkgYWNfdW5yZWNvZ25pemVkX3NlcD0nLCAnOzsKKyAgICBlc2Fj
CisgICAgZXZhbCB3aXRoXyRhY191c2Vyb3B0PVwkYWNfb3B0YXJnIDs7CisKKyAgLXdpdGhvdXQt
KiB8IC0td2l0aG91dC0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4
LSp3aXRob3V0LVwoLipcKSdgCisgICAgIyBSZWplY3QgbmFtZXMgdGhhdCBhcmUgbm90IHZhbGlk
IHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNfdXNlcm9wdCIgOiAiLipbXi0r
Ll8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52
YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNf
dXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3Mv
Wy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4KKyAgICAgICoiCisid2l0aF8k
YWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNfdW5yZWNvZ25pemVkX29wdHM9IiRhY191
bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRfc2VwLS13aXRob3V0LSRhY191c2Vyb3B0
X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAgZXNhYworICAgIGV2YWwg
d2l0aF8kYWNfdXNlcm9wdD1ubyA7OworCisgIC0teCkKKyAgICAjIE9ic29sZXRlOyB1c2UgLS13
aXRoLXguCisgICAgd2l0aF94PXllcyA7OworCisgIC14LWluY2x1ZGVzIHwgLS14LWluY2x1ZGVz
IHwgLS14LWluY2x1ZGUgfCAtLXgtaW5jbHVkIHwgLS14LWluY2x1IFwKKyAgfCAtLXgtaW5jbCB8
IC0teC1pbmMgfCAtLXgtaW4gfCAtLXgtaSkKKyAgICBhY19wcmV2PXhfaW5jbHVkZXMgOzsKKyAg
LXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlcz0qIHwgLS14LWluY2x1ZGU9KiB8IC0teC1pbmNs
dWQ9KiB8IC0teC1pbmNsdT0qIFwKKyAgfCAtLXgtaW5jbD0qIHwgLS14LWluYz0qIHwgLS14LWlu
PSogfCAtLXgtaT0qKQorICAgIHhfaW5jbHVkZXM9JGFjX29wdGFyZyA7OworCisgIC14LWxpYnJh
cmllcyB8IC0teC1saWJyYXJpZXMgfCAtLXgtbGlicmFyaWUgfCAtLXgtbGlicmFyaSBcCisgIHwg
LS14LWxpYnJhciB8IC0teC1saWJyYSB8IC0teC1saWJyIHwgLS14LWxpYiB8IC0teC1saSB8IC0t
eC1sKQorICAgIGFjX3ByZXY9eF9saWJyYXJpZXMgOzsKKyAgLXgtbGlicmFyaWVzPSogfCAtLXgt
bGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWU9KiB8IC0teC1saWJyYXJpPSogXAorICB8IC0teC1s
aWJyYXI9KiB8IC0teC1saWJyYT0qIHwgLS14LWxpYnI9KiB8IC0teC1saWI9KiB8IC0teC1saT0q
IHwgLS14LWw9KikKKyAgICB4X2xpYnJhcmllcz0kYWNfb3B0YXJnIDs7CisKKyAgLSopIGFzX2Zu
X2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uOiBcYCRhY19vcHRpb24nCitUcnkgXGAkMCAt
LWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uIgorICAgIDs7CisKKyAgKj0qKQorICAgIGFjX2Vu
dnZhcj1gZXhwciAieCRhY19vcHRpb24iIDogJ3hcKFtePV0qXCk9J2AKKyAgICAjIFJlamVjdCBu
YW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgY2FzZSAk
YWNfZW52dmFyIGluICMoCisgICAgICAnJyB8IFswLTldKiB8ICpbIV8kYXNfY3JfYWxudW1dKiAp
CisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YXJpYWJsZSBuYW1lOiBcYCRhY19lbnZ2
YXInIiA7OworICAgIGVzYWMKKyAgICBldmFsICRhY19lbnZ2YXI9XCRhY19vcHRhcmcKKyAgICBl
eHBvcnQgJGFjX2VudnZhciA7OworCisgICopCisgICAgIyBGSVhNRTogc2hvdWxkIGJlIHJlbW92
ZWQgaW4gYXV0b2NvbmYgMy4wLgorICAgICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHlvdSBz
aG91bGQgdXNlIC0tYnVpbGQsIC0taG9zdCwgLS10YXJnZXQiID4mMgorICAgIGV4cHIgIngkYWNf
b3B0aW9uIiA6ICIuKlteLS5fJGFzX2NyX2FsbnVtXSIgPi9kZXYvbnVsbCAmJgorICAgICAgJGFz
X2VjaG8gIiRhc19tZTogV0FSTklORzogaW52YWxpZCBob3N0IHR5cGU6ICRhY19vcHRpb24iID4m
MgorICAgIDogIiR7YnVpbGRfYWxpYXM9JGFjX29wdGlvbn0gJHtob3N0X2FsaWFzPSRhY19vcHRp
b259ICR7dGFyZ2V0X2FsaWFzPSRhY19vcHRpb259IgorICAgIDs7CisKKyAgZXNhYworZG9uZQor
CitpZiB0ZXN0IC1uICIkYWNfcHJldiI7IHRoZW4KKyAgYWNfb3B0aW9uPS0tYGVjaG8gJGFjX3By
ZXYgfCBzZWQgJ3MvXy8tL2cnYAorICBhc19mbl9lcnJvciAkPyAibWlzc2luZyBhcmd1bWVudCB0
byAkYWNfb3B0aW9uIgorZmkKKworaWYgdGVzdCAtbiAiJGFjX3VucmVjb2duaXplZF9vcHRzIjsg
dGhlbgorICBjYXNlICRlbmFibGVfb3B0aW9uX2NoZWNraW5nIGluCisgICAgbm8pIDs7CisgICAg
ZmF0YWwpIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2du
aXplZF9vcHRzIiA7OworICAgICopICAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1bnJl
Y29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXplZF9vcHRzIiA+JjIgOzsKKyAgZXNhYwor
ZmkKKworIyBDaGVjayBhbGwgZGlyZWN0b3J5IGFyZ3VtZW50cyBmb3IgY29uc2lzdGVuY3kuCitm
b3IgYWNfdmFyIGluCWV4ZWNfcHJlZml4IHByZWZpeCBiaW5kaXIgc2JpbmRpciBsaWJleGVjZGly
IGRhdGFyb290ZGlyIFwKKwkJZGF0YWRpciBzeXNjb25mZGlyIHNoYXJlZHN0YXRlZGlyIGxvY2Fs
c3RhdGVkaXIgaW5jbHVkZWRpciBcCisJCW9sZGluY2x1ZGVkaXIgZG9jZGlyIGluZm9kaXIgaHRt
bGRpciBkdmlkaXIgcGRmZGlyIHBzZGlyIFwKKwkJbGliZGlyIGxvY2FsZWRpciBtYW5kaXIKK2Rv
CisgIGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAjIFJlbW92ZSB0cmFpbGluZyBzbGFzaGVzLgor
ICBjYXNlICRhY192YWwgaW4KKyAgICAqLyApCisgICAgICBhY192YWw9YGV4cHIgIlgkYWNfdmFs
IiA6ICdYXCguKlteL11cKScgXHwgIlgkYWNfdmFsIiA6ICdYXCguKlwpJ2AKKyAgICAgIGV2YWwg
JGFjX3Zhcj1cJGFjX3ZhbDs7CisgIGVzYWMKKyAgIyBCZSBzdXJlIHRvIGhhdmUgYWJzb2x1dGUg
ZGlyZWN0b3J5IG5hbWVzLgorICBjYXNlICRhY192YWwgaW4KKyAgICBbXFwvJF0qIHwgPzpbXFwv
XSogKSAgY29udGludWU7OworICAgIE5PTkUgfCAnJyApIGNhc2UgJGFjX3ZhciBpbiAqcHJlZml4
ICkgY29udGludWU7OyBlc2FjOzsKKyAgZXNhYworICBhc19mbl9lcnJvciAkPyAiZXhwZWN0ZWQg
YW4gYWJzb2x1dGUgZGlyZWN0b3J5IG5hbWUgZm9yIC0tJGFjX3ZhcjogJGFjX3ZhbCIKK2RvbmUK
KworIyBUaGVyZSBtaWdodCBiZSBwZW9wbGUgd2hvIGRlcGVuZCBvbiB0aGUgb2xkIGJyb2tlbiBi
ZWhhdmlvcjogYCRob3N0JworIyB1c2VkIHRvIGhvbGQgdGhlIGFyZ3VtZW50IG9mIC0taG9zdCBl
dGMuCisjIEZJWE1FOiBUbyByZW1vdmUgc29tZSBkYXkuCitidWlsZD0kYnVpbGRfYWxpYXMKK2hv
c3Q9JGhvc3RfYWxpYXMKK3RhcmdldD0kdGFyZ2V0X2FsaWFzCisKKyMgRklYTUU6IFRvIHJlbW92
ZSBzb21lIGRheS4KK2lmIHRlc3QgIngkaG9zdF9hbGlhcyIgIT0geDsgdGhlbgorICBpZiB0ZXN0
ICJ4JGJ1aWxkX2FsaWFzIiA9IHg7IHRoZW4KKyAgICBjcm9zc19jb21waWxpbmc9bWF5YmUKKyAg
ICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBpZiB5b3Ugd2FudGVkIHRvIHNldCB0aGUgLS1i
dWlsZCB0eXBlLCBkb24ndCB1c2UgLS1ob3N0LgorICAgIElmIGEgY3Jvc3MgY29tcGlsZXIgaXMg
ZGV0ZWN0ZWQgdGhlbiBjcm9zcyBjb21waWxlIG1vZGUgd2lsbCBiZSB1c2VkIiA+JjIKKyAgZWxp
ZiB0ZXN0ICJ4JGJ1aWxkX2FsaWFzIiAhPSAieCRob3N0X2FsaWFzIjsgdGhlbgorICAgIGNyb3Nz
X2NvbXBpbGluZz15ZXMKKyAgZmkKK2ZpCisKK2FjX3Rvb2xfcHJlZml4PQordGVzdCAtbiAiJGhv
c3RfYWxpYXMiICYmIGFjX3Rvb2xfcHJlZml4PSRob3N0X2FsaWFzLQorCit0ZXN0ICIkc2lsZW50
IiA9IHllcyAmJiBleGVjIDY+L2Rldi9udWxsCisKKworYWNfcHdkPWBwd2RgICYmIHRlc3QgLW4g
IiRhY19wd2QiICYmCithY19sc19kaT1gbHMgLWRpIC5gICYmCithY19wd2RfbHNfZGk9YGNkICIk
YWNfcHdkIiAmJiBscyAtZGkgLmAgfHwKKyAgYXNfZm5fZXJyb3IgJD8gIndvcmtpbmcgZGlyZWN0
b3J5IGNhbm5vdCBiZSBkZXRlcm1pbmVkIgordGVzdCAiWCRhY19sc19kaSIgPSAiWCRhY19wd2Rf
bHNfZGkiIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJwd2QgZG9lcyBub3QgcmVwb3J0IG5hbWUgb2Yg
d29ya2luZyBkaXJlY3RvcnkiCisKKworIyBGaW5kIHRoZSBzb3VyY2UgZmlsZXMsIGlmIGxvY2F0
aW9uIHdhcyBub3Qgc3BlY2lmaWVkLgoraWYgdGVzdCAteiAiJHNyY2RpciI7IHRoZW4KKyAgYWNf
c3JjZGlyX2RlZmF1bHRlZD15ZXMKKyAgIyBUcnkgdGhlIGRpcmVjdG9yeSBjb250YWluaW5nIHRo
aXMgc2NyaXB0LCB0aGVuIHRoZSBwYXJlbnQgZGlyZWN0b3J5LgorICBhY19jb25mZGlyPWAkYXNf
ZGlybmFtZSAtLSAiJGFzX215c2VsZiIgfHwKKyRhc19leHByIFgiJGFzX215c2VsZiIgOiAnWFwo
LipbXi9dXCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkgWCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wp
W14vXScgXHwgXAorCSBYIiRhc19teXNlbGYiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFzX215
c2VsZiIgOiAnWFwoL1wpJyBcfCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhc19teXNl
bGYiIHwKKyAgICBzZWQgJy9eWFwoLipbXi9dXClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBz
Ly9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8K
KwkgICAgcQorCSAgfQorCSAgL15YXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkg
IH0KKwkgIC9eWFwoXC9cKS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiov
Li87IHEnYAorICBzcmNkaXI9JGFjX2NvbmZkaXIKKyAgaWYgdGVzdCAhIC1yICIkc3JjZGlyLyRh
Y191bmlxdWVfZmlsZSI7IHRoZW4KKyAgICBzcmNkaXI9Li4KKyAgZmkKK2Vsc2UKKyAgYWNfc3Jj
ZGlyX2RlZmF1bHRlZD1ubworZmkKK2lmIHRlc3QgISAtciAiJHNyY2Rpci8kYWNfdW5pcXVlX2Zp
bGUiOyB0aGVuCisgIHRlc3QgIiRhY19zcmNkaXJfZGVmYXVsdGVkIiA9IHllcyAmJiBzcmNkaXI9
IiRhY19jb25mZGlyIG9yIC4uIgorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgc291cmNl
cyAoJGFjX3VuaXF1ZV9maWxlKSBpbiAkc3JjZGlyIgorZmkKK2FjX21zZz0ic291cmNlcyBhcmUg
aW4gJHNyY2RpciwgYnV0IFxgY2QgJHNyY2RpcicgZG9lcyBub3Qgd29yayIKK2FjX2Fic19jb25m
ZGlyPWAoCisJY2QgIiRzcmNkaXIiICYmIHRlc3QgLXIgIi4vJGFjX3VuaXF1ZV9maWxlIiB8fCBh
c19mbl9lcnJvciAkPyAiJGFjX21zZyIKKwlwd2QpYAorIyBXaGVuIGJ1aWxkaW5nIGluIHBsYWNl
LCBzZXQgc3JjZGlyPS4KK2lmIHRlc3QgIiRhY19hYnNfY29uZmRpciIgPSAiJGFjX3B3ZCI7IHRo
ZW4KKyAgc3JjZGlyPS4KK2ZpCisjIFJlbW92ZSB1bm5lY2Vzc2FyeSB0cmFpbGluZyBzbGFzaGVz
IGZyb20gc3JjZGlyLgorIyBEb3VibGUgc2xhc2hlcyBpbiBmaWxlIG5hbWVzIGluIG9iamVjdCBm
aWxlIGRlYnVnZ2luZyBpbmZvCisjIG1lc3MgdXAgTS14IGdkYiBpbiBFbWFjcy4KK2Nhc2UgJHNy
Y2RpciBpbgorKi8pIHNyY2Rpcj1gZXhwciAiWCRzcmNkaXIiIDogJ1hcKC4qW14vXVwpJyBcfCAi
WCRzcmNkaXIiIDogJ1hcKC4qXCknYDs7Citlc2FjCitmb3IgYWNfdmFyIGluICRhY19wcmVjaW91
c192YXJzOyBkbworICBldmFsIGFjX2Vudl8ke2FjX3Zhcn1fc2V0PVwkeyR7YWNfdmFyfStzZXR9
CisgIGV2YWwgYWNfZW52XyR7YWNfdmFyfV92YWx1ZT1cJCR7YWNfdmFyfQorICBldmFsIGFjX2N2
X2Vudl8ke2FjX3Zhcn1fc2V0PVwkeyR7YWNfdmFyfStzZXR9CisgIGV2YWwgYWNfY3ZfZW52XyR7
YWNfdmFyfV92YWx1ZT1cJCR7YWNfdmFyfQorZG9uZQorCisjCisjIFJlcG9ydCB0aGUgLS1oZWxw
IG1lc3NhZ2UuCisjCitpZiB0ZXN0ICIkYWNfaW5pdF9oZWxwIiA9ICJsb25nIjsgdGhlbgorICAj
IE9taXQgc29tZSBpbnRlcm5hbCBvciBvYnNvbGV0ZSBvcHRpb25zIHRvIG1ha2UgdGhlIGxpc3Qg
bGVzcyBpbXBvc2luZy4KKyAgIyBUaGlzIG1lc3NhZ2UgaXMgdG9vIGxvbmcgdG8gYmUgYSBzdHJp
bmcgaW4gdGhlIEEvVVggMy4xIHNoLgorICBjYXQgPDxfQUNFT0YKK1xgY29uZmlndXJlJyBjb25m
aWd1cmVzIFhlbiBIeXBlcnZpc29yIDQuMiB0byBhZGFwdCB0byBtYW55IGtpbmRzIG9mIHN5c3Rl
bXMuCisKK1VzYWdlOiAkMCBbT1BUSU9OXS4uLiBbVkFSPVZBTFVFXS4uLgorCitUbyBhc3NpZ24g
ZW52aXJvbm1lbnQgdmFyaWFibGVzIChlLmcuLCBDQywgQ0ZMQUdTLi4uKSwgc3BlY2lmeSB0aGVt
IGFzCitWQVI9VkFMVUUuICBTZWUgYmVsb3cgZm9yIGRlc2NyaXB0aW9ucyBvZiBzb21lIG9mIHRo
ZSB1c2VmdWwgdmFyaWFibGVzLgorCitEZWZhdWx0cyBmb3IgdGhlIG9wdGlvbnMgYXJlIHNwZWNp
ZmllZCBpbiBicmFja2V0cy4KKworQ29uZmlndXJhdGlvbjoKKyAgLWgsIC0taGVscCAgICAgICAg
ICAgICAgZGlzcGxheSB0aGlzIGhlbHAgYW5kIGV4aXQKKyAgICAgIC0taGVscD1zaG9ydCAgICAg
ICAgZGlzcGxheSBvcHRpb25zIHNwZWNpZmljIHRvIHRoaXMgcGFja2FnZQorICAgICAgLS1oZWxw
PXJlY3Vyc2l2ZSAgICBkaXNwbGF5IHRoZSBzaG9ydCBoZWxwIG9mIGFsbCB0aGUgaW5jbHVkZWQg
cGFja2FnZXMKKyAgLVYsIC0tdmVyc2lvbiAgICAgICAgICAgZGlzcGxheSB2ZXJzaW9uIGluZm9y
bWF0aW9uIGFuZCBleGl0CisgIC1xLCAtLXF1aWV0LCAtLXNpbGVudCAgIGRvIG5vdCBwcmludCBc
YGNoZWNraW5nIC4uLicgbWVzc2FnZXMKKyAgICAgIC0tY2FjaGUtZmlsZT1GSUxFICAgY2FjaGUg
dGVzdCByZXN1bHRzIGluIEZJTEUgW2Rpc2FibGVkXQorICAtQywgLS1jb25maWctY2FjaGUgICAg
ICBhbGlhcyBmb3IgXGAtLWNhY2hlLWZpbGU9Y29uZmlnLmNhY2hlJworICAtbiwgLS1uby1jcmVh
dGUgICAgICAgICBkbyBub3QgY3JlYXRlIG91dHB1dCBmaWxlcworICAgICAgLS1zcmNkaXI9RElS
ICAgICAgICBmaW5kIHRoZSBzb3VyY2VzIGluIERJUiBbY29uZmlndXJlIGRpciBvciBcYC4uJ10K
KworSW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVzOgorICAtLXByZWZpeD1QUkVGSVggICAgICAgICBp
bnN0YWxsIGFyY2hpdGVjdHVyZS1pbmRlcGVuZGVudCBmaWxlcyBpbiBQUkVGSVgKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgWyRhY19kZWZhdWx0X3ByZWZpeF0KKyAgLS1leGVjLXByZWZpeD1F
UFJFRklYICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtZGVwZW5kZW50IGZpbGVzIGluIEVQUkVGSVgK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgW1BSRUZJWF0KKworQnkgZGVmYXVsdCwgXGBtYWtl
IGluc3RhbGwnIHdpbGwgaW5zdGFsbCBhbGwgdGhlIGZpbGVzIGluCitcYCRhY19kZWZhdWx0X3By
ZWZpeC9iaW4nLCBcYCRhY19kZWZhdWx0X3ByZWZpeC9saWInIGV0Yy4gIFlvdSBjYW4gc3BlY2lm
eQorYW4gaW5zdGFsbGF0aW9uIHByZWZpeCBvdGhlciB0aGFuIFxgJGFjX2RlZmF1bHRfcHJlZml4
JyB1c2luZyBcYC0tcHJlZml4JywKK2ZvciBpbnN0YW5jZSBcYC0tcHJlZml4PVwkSE9NRScuCisK
K0ZvciBiZXR0ZXIgY29udHJvbCwgdXNlIHRoZSBvcHRpb25zIGJlbG93LgorCitGaW5lIHR1bmlu
ZyBvZiB0aGUgaW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVzOgorICAtLWJpbmRpcj1ESVIgICAgICAg
ICAgICB1c2VyIGV4ZWN1dGFibGVzIFtFUFJFRklYL2Jpbl0KKyAgLS1zYmluZGlyPURJUiAgICAg
ICAgICAgc3lzdGVtIGFkbWluIGV4ZWN1dGFibGVzIFtFUFJFRklYL3NiaW5dCisgIC0tbGliZXhl
Y2Rpcj1ESVIgICAgICAgIHByb2dyYW0gZXhlY3V0YWJsZXMgW0VQUkVGSVgvbGliZXhlY10KKyAg
LS1zeXNjb25mZGlyPURJUiAgICAgICAgcmVhZC1vbmx5IHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BS
RUZJWC9ldGNdCisgIC0tc2hhcmVkc3RhdGVkaXI9RElSICAgIG1vZGlmaWFibGUgYXJjaGl0ZWN0
dXJlLWluZGVwZW5kZW50IGRhdGEgW1BSRUZJWC9jb21dCisgIC0tbG9jYWxzdGF0ZWRpcj1ESVIg
ICAgIG1vZGlmaWFibGUgc2luZ2xlLW1hY2hpbmUgZGF0YSBbUFJFRklYL3Zhcl0KKyAgLS1saWJk
aXI9RElSICAgICAgICAgICAgb2JqZWN0IGNvZGUgbGlicmFyaWVzIFtFUFJFRklYL2xpYl0KKyAg
LS1pbmNsdWRlZGlyPURJUiAgICAgICAgQyBoZWFkZXIgZmlsZXMgW1BSRUZJWC9pbmNsdWRlXQor
ICAtLW9sZGluY2x1ZGVkaXI9RElSICAgICBDIGhlYWRlciBmaWxlcyBmb3Igbm9uLWdjYyBbL3Vz
ci9pbmNsdWRlXQorICAtLWRhdGFyb290ZGlyPURJUiAgICAgICByZWFkLW9ubHkgYXJjaC4taW5k
ZXBlbmRlbnQgZGF0YSByb290IFtQUkVGSVgvc2hhcmVdCisgIC0tZGF0YWRpcj1ESVIgICAgICAg
ICAgIHJlYWQtb25seSBhcmNoaXRlY3R1cmUtaW5kZXBlbmRlbnQgZGF0YSBbREFUQVJPT1RESVJd
CisgIC0taW5mb2Rpcj1ESVIgICAgICAgICAgIGluZm8gZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RE
SVIvaW5mb10KKyAgLS1sb2NhbGVkaXI9RElSICAgICAgICAgbG9jYWxlLWRlcGVuZGVudCBkYXRh
IFtEQVRBUk9PVERJUi9sb2NhbGVdCisgIC0tbWFuZGlyPURJUiAgICAgICAgICAgIG1hbiBkb2N1
bWVudGF0aW9uIFtEQVRBUk9PVERJUi9tYW5dCisgIC0tZG9jZGlyPURJUiAgICAgICAgICAgIGRv
Y3VtZW50YXRpb24gcm9vdCBbREFUQVJPT1RESVIvZG9jL3hlbi1oeXBlcnZpc29yXQorICAtLWh0
bWxkaXI9RElSICAgICAgICAgICBodG1sIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1kdmlk
aXI9RElSICAgICAgICAgICAgZHZpIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wZGZkaXI9
RElSICAgICAgICAgICAgcGRmIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KKyAgLS1wc2Rpcj1ESVIg
ICAgICAgICAgICAgcHMgZG9jdW1lbnRhdGlvbiBbRE9DRElSXQorX0FDRU9GCisKKyAgY2F0IDw8
XF9BQ0VPRgorCitTeXN0ZW0gdHlwZXM6CisgIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBm
b3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCisgIC0taG9zdD1IT1NUICAgICAgIGNyb3Nz
LWNvbXBpbGUgdG8gYnVpbGQgcHJvZ3JhbXMgdG8gcnVuIG9uIEhPU1QgW0JVSUxEXQorX0FDRU9G
CitmaQorCitpZiB0ZXN0IC1uICIkYWNfaW5pdF9oZWxwIjsgdGhlbgorICBjYXNlICRhY19pbml0
X2hlbHAgaW4KKyAgICAgc2hvcnQgfCByZWN1cnNpdmUgKSBlY2hvICJDb25maWd1cmF0aW9uIG9m
IFhlbiBIeXBlcnZpc29yIDQuMjoiOzsKKyAgIGVzYWMKKyAgY2F0IDw8XF9BQ0VPRgorCitPcHRp
b25hbCBGZWF0dXJlczoKKyAgLS1kaXNhYmxlLW9wdGlvbi1jaGVja2luZyAgaWdub3JlIHVucmVj
b2duaXplZCAtLWVuYWJsZS8tLXdpdGggb3B0aW9ucworICAtLWRpc2FibGUtRkVBVFVSRSAgICAg
ICBkbyBub3QgaW5jbHVkZSBGRUFUVVJFIChzYW1lIGFzIC0tZW5hYmxlLUZFQVRVUkU9bm8pCisg
IC0tZW5hYmxlLUZFQVRVUkVbPUFSR10gIGluY2x1ZGUgRkVBVFVSRSBbQVJHPXllc10KKyAgLS1l
bmFibGUteHNtICAgICAgICAgICAgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1
bHQsIEZsYXNrKQorICAtLWVuYWJsZS1naXRodHRwICAgICAgICBEb3dubG9hZCBHSVQgcmVwb3Np
dG9yaWVzIHZpYSBIVFRQCisgIC0tZGlzYWJsZS1tb25pdG9ycyAgICAgIERpc2FibGUgeGVuc3Rh
dCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHMKKyAgLS1lbmFibGUtdnRwbSAgICAgICAgICAg
RW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9ybSBNb2R1bGUKKyAgLS1lbmFibGUteGFwaSAg
ICAgICAgICAgRW5hYmxlIFhlbiBBUEkgQmluZGluZ3MKKyAgLS1kaXNhYmxlLXB5dGhvbnRvb2xz
ICAgRGlzYWJsZSBQeXRob24gdG9vbHMKKyAgLS1kaXNhYmxlLW9jYW1sdG9vbHMgICAgRGlzYWJs
ZSBPY2FtbCB0b29scworICAtLWVuYWJsZS1taW5pdGVybSAgICAgICBFbmFibGUgbWluaXRlcm0K
KyAgLS1lbmFibGUtbG9tb3VudCAgICAgICAgRW5hYmxlIGxvbW91bnQKKyAgLS1kaXNhYmxlLWRl
YnVnICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzCisKK1NvbWUg
aW5mbHVlbnRpYWwgZW52aXJvbm1lbnQgdmFyaWFibGVzOgorICBDQyAgICAgICAgICBDIGNvbXBp
bGVyIGNvbW1hbmQKKyAgQ0ZMQUdTICAgICAgQyBjb21waWxlciBmbGFncworICBMREZMQUdTICAg
ICBsaW5rZXIgZmxhZ3MsIGUuZy4gLUw8bGliIGRpcj4gaWYgeW91IGhhdmUgbGlicmFyaWVzIGlu
IGEKKyAgICAgICAgICAgICAgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxsaWIgZGlyPgorICBMSUJT
ICAgICAgICBsaWJyYXJpZXMgdG8gcGFzcyB0byB0aGUgbGlua2VyLCBlLmcuIC1sPGxpYnJhcnk+
CisgIENQUEZMQUdTICAgIChPYmplY3RpdmUpIEMvQysrIHByZXByb2Nlc3NvciBmbGFncywgZS5n
LiAtSTxpbmNsdWRlIGRpcj4gaWYKKyAgICAgICAgICAgICAgeW91IGhhdmUgaGVhZGVycyBpbiBh
IG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBkaXI+CisgIENQUCAgICAgICAgIEMgcHJl
cHJvY2Vzc29yCisgIFBSRVBFTkRfSU5DTFVERVMKKyAgICAgICAgICAgICAgTGlzdCBvZiBpbmNs
dWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCisgIFBSRVBFTkRf
TElCIExpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAod2l0aG91
dCAtTCkKKyAgQVBQRU5EX0lOQ0xVREVTCisgICAgICAgICAgICAgIExpc3Qgb2YgaW5jbHVkZSBm
b2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpCisgIEFQUEVORF9MSUIgIExp
c3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFwcGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKQor
ICBQWVRIT04gICAgICBQYXRoIHRvIHRoZSBQeXRob24gcGFyc2VyCisgIFBFUkwgICAgICAgIFBh
dGggdG8gUGVybCBwYXJzZXIKKyAgQlJDVEwgICAgICAgUGF0aCB0byBicmN0bCB0b29sCisgIElQ
ICAgICAgICAgIFBhdGggdG8gaXAgdG9vbAorICBCSVNPTiAgICAgICBQYXRoIHRvIEJpc29uIHBh
cnNlciBnZW5lcmF0b3IKKyAgRkxFWCAgICAgICAgUGF0aCB0byBGbGV4IGxleGljYWwgYW5hbHlz
ZXIgZ2VuZXJhdG9yCisgIENVUkwgICAgICAgIFBhdGggdG8gY3VybC1jb25maWcgdG9vbAorICBY
TUwgICAgICAgICBQYXRoIHRvIHhtbDItY29uZmlnIHRvb2wKKyAgQkFTSCAgICAgICAgUGF0aCB0
byBiYXNoIHNoZWxsCisgIFhHRVRURVhUICAgIFBhdGggdG8geGdldHR0ZXh0IHRvb2wKKworVXNl
IHRoZXNlIHZhcmlhYmxlcyB0byBvdmVycmlkZSB0aGUgY2hvaWNlcyBtYWRlIGJ5IGBjb25maWd1
cmUnIG9yIHRvIGhlbHAKK2l0IHRvIGZpbmQgbGlicmFyaWVzIGFuZCBwcm9ncmFtcyB3aXRoIG5v
bnN0YW5kYXJkIG5hbWVzL2xvY2F0aW9ucy4KKworUmVwb3J0IGJ1Z3MgdG8gPHhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tPi4KK19BQ0VPRgorYWNfc3RhdHVzPSQ/CitmaQorCitpZiB0ZXN0
ICIkYWNfaW5pdF9oZWxwIiA9ICJyZWN1cnNpdmUiOyB0aGVuCisgICMgSWYgdGhlcmUgYXJlIHN1
YmRpcnMsIHJlcG9ydCB0aGVpciBzcGVjaWZpYyAtLWhlbHAuCisgIGZvciBhY19kaXIgaW4gOiAk
YWNfc3ViZGlyc19hbGw7IGRvIHRlc3QgIngkYWNfZGlyIiA9IHg6ICYmIGNvbnRpbnVlCisgICAg
dGVzdCAtZCAiJGFjX2RpciIgfHwKKyAgICAgIHsgY2QgIiRzcmNkaXIiICYmIGFjX3B3ZD1gcHdk
YCAmJiBzcmNkaXI9LiAmJiB0ZXN0IC1kICIkYWNfZGlyIjsgfSB8fAorICAgICAgY29udGludWUK
KyAgICBhY19idWlsZGRpcj0uCisKK2Nhc2UgIiRhY19kaXIiIGluCisuKSBhY19kaXJfc3VmZml4
PSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZpeD0gOzsKKyopCisgIGFj
X2Rpcl9zdWZmaXg9L2AkYXNfZWNobyAiJGFjX2RpciIgfCBzZWQgJ3N8XlwuW1xcL118fCdgCisg
ICMgQSAiLi4iIGZvciBlYWNoIGRpcmVjdG9yeSBpbiAkYWNfZGlyX3N1ZmZpeC4KKyAgYWNfdG9w
X2J1aWxkZGlyX3N1Yj1gJGFzX2VjaG8gIiRhY19kaXJfc3VmZml4IiB8IHNlZCAnc3wvW15cXC9d
KnwvLi58ZztzfC98fCdgCisgIGNhc2UgJGFjX3RvcF9idWlsZGRpcl9zdWIgaW4KKyAgIiIpIGFj
X3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4PSA7OworICAqKSAgYWNfdG9w
X2J1aWxkX3ByZWZpeD0kYWNfdG9wX2J1aWxkZGlyX3N1Yi8gOzsKKyAgZXNhYyA7OworZXNhYwor
YWNfYWJzX3RvcF9idWlsZGRpcj0kYWNfcHdkCithY19hYnNfYnVpbGRkaXI9JGFjX3B3ZCRhY19k
aXJfc3VmZml4CisjIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5OgorYWNfdG9wX2J1aWxkZGly
PSRhY190b3BfYnVpbGRfcHJlZml4CisKK2Nhc2UgJHNyY2RpciBpbgorICAuKSAgIyBXZSBhcmUg
YnVpbGRpbmcgaW4gcGxhY2UuCisgICAgYWNfc3JjZGlyPS4KKyAgICBhY190b3Bfc3JjZGlyPSRh
Y190b3BfYnVpbGRkaXJfc3ViCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9JGFjX3B3ZCA7OworICBb
XFwvXSogfCA/OltcXC9dKiApICAjIEFic29sdXRlIG5hbWUuCisgICAgYWNfc3JjZGlyPSRzcmNk
aXIkYWNfZGlyX3N1ZmZpeDsKKyAgICBhY190b3Bfc3JjZGlyPSRzcmNkaXIKKyAgICBhY19hYnNf
dG9wX3NyY2Rpcj0kc3JjZGlyIDs7CisgICopICMgUmVsYXRpdmUgbmFtZS4KKyAgICBhY19zcmNk
aXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyJGFjX2Rpcl9zdWZmaXgKKyAgICBhY190b3Bf
c3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpcgorICAgIGFjX2Fic190b3Bfc3JjZGly
PSRhY19wd2QvJHNyY2RpciA7OworZXNhYworYWNfYWJzX3NyY2Rpcj0kYWNfYWJzX3RvcF9zcmNk
aXIkYWNfZGlyX3N1ZmZpeAorCisgICAgY2QgIiRhY19kaXIiIHx8IHsgYWNfc3RhdHVzPSQ/OyBj
b250aW51ZTsgfQorICAgICMgQ2hlY2sgZm9yIGd1ZXN0ZWQgY29uZmlndXJlLgorICAgIGlmIHRl
c3QgLWYgIiRhY19zcmNkaXIvY29uZmlndXJlLmdudSI7IHRoZW4KKyAgICAgIGVjaG8gJiYKKyAg
ICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUuZ251IiAtLWhlbHA9cmVjdXJzaXZlCisg
ICAgZWxpZiB0ZXN0IC1mICIkYWNfc3JjZGlyL2NvbmZpZ3VyZSI7IHRoZW4KKyAgICAgIGVjaG8g
JiYKKyAgICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUiIC0taGVscD1yZWN1cnNpdmUK
KyAgICBlbHNlCisgICAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBubyBjb25maWd1cmF0
aW9uIGluZm9ybWF0aW9uIGlzIGluICRhY19kaXIiID4mMgorICAgIGZpIHx8IGFjX3N0YXR1cz0k
PworICAgIGNkICIkYWNfcHdkIiB8fCB7IGFjX3N0YXR1cz0kPzsgYnJlYWs7IH0KKyAgZG9uZQor
ZmkKKwordGVzdCAtbiAiJGFjX2luaXRfaGVscCIgJiYgZXhpdCAkYWNfc3RhdHVzCitpZiAkYWNf
aW5pdF92ZXJzaW9uOyB0aGVuCisgIGNhdCA8PFxfQUNFT0YKK1hlbiBIeXBlcnZpc29yIGNvbmZp
Z3VyZSA0LjIKK2dlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OAorCitDb3B5cmlnaHQgKEMp
IDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCitUaGlzIGNvbmZpZ3VyZSBzY3Jp
cHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbgorZ2l2ZXMg
dW5saW1pdGVkIHBlcm1pc3Npb24gdG8gY29weSwgZGlzdHJpYnV0ZSBhbmQgbW9kaWZ5IGl0Lgor
X0FDRU9GCisgIGV4aXQKK2ZpCisKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMg
QXV0b2NvbmYgaW5pdGlhbGl6YXRpb24uICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
IyMKKworIyBhY19mbl9jX3RyeV9jb21waWxlIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQorIyBUcnkgdG8gY29tcGlsZSBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdo
ZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19mbl9jX3RyeV9jb21waWxlICgpCit7CisgIGFzX2xp
bmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRh
c19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29uZnRlc3QuJGFjX29iamV4dAorICBpZiB7IHsgYWNf
dHJ5PSIkYWNfY29tcGlsZSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAq
XFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owor
ZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAk
YWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAi
JGFjX2NvbXBpbGUiKSAyPmNvbmZ0ZXN0LmVycgorICBhY19zdGF0dXM9JD8KKyAgaWYgdGVzdCAt
cyBjb25mdGVzdC5lcnI7IHRoZW4KKyAgICBncmVwIC12ICdeICorJyBjb25mdGVzdC5lcnIgPmNv
bmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1CisgICAgbXYgLWYgY29uZnRlc3Qu
ZXIxIGNvbmZ0ZXN0LmVycgorICBmaQorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfSAm
JiB7CisJIHRlc3QgLXogIiRhY19jX3dlcnJvcl9mbGFnIiB8fAorCSB0ZXN0ICEgLXMgY29uZnRl
c3QuZXJyCisgICAgICAgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LiRhY19vYmpleHQ7IHRoZW4gOgor
ICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3
YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworCWFjX3JldHZh
bD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1
bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCisKK30gIyBhY19m
bl9jX3RyeV9jb21waWxlCisKKyMgYWNfZm5fY190cnlfY3BwIExJTkVOTworIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCisjIFRyeSB0byBwcmVwcm9jZXNzIGNvbmZ0ZXN0LiRhY19leHQsIGFuZCBy
ZXR1cm4gd2hldGhlciB0aGlzIHN1Y2NlZWRlZC4KK2FjX2ZuX2NfdHJ5X2NwcCAoKQoreworICBh
c19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFj
az0kYXNfbGluZW5vX3N0YWNrCisgIGlmIHsgeyBhY190cnk9IiRhY19jcHAgY29uZnRlc3QuJGFj
X2V4dCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlf
ZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBh
Y190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9c
IiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NwcCBjb25m
dGVzdC4kYWNfZXh0IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3Qg
LXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5j
b25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0
LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0g
PiBjb25mdGVzdC5pICYmIHsKKwkgdGVzdCAteiAiJGFjX2NfcHJlcHJvY193YXJuX2ZsYWckYWNf
Y193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAgIH07IHRo
ZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJv
Z3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworICAg
IGFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0
YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCisK
K30gIyBhY19mbl9jX3RyeV9jcHAKKworIyBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsIExJ
TkVOTyBIRUFERVIgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhlciBIRUFERVIgZXhpc3Rz
LCBnaXZpbmcgYSB3YXJuaW5nIGlmIGl0IGNhbm5vdCBiZSBjb21waWxlZCB1c2luZworIyB0aGUg
aW5jbHVkZSBmaWxlcyBpbiBJTkNMVURFUyBhbmQgc2V0dGluZyB0aGUgY2FjaGUgdmFyaWFibGUg
VkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAoKQorewor
ICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19z
dGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
MiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0KK2lmIGV2YWwg
XCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZmkK
K2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsg
fQorZWxzZQorICAjIElzIHRoZSBoZWFkZXIgY29tcGlsYWJsZT8KK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIgdXNhYmlsaXR5IiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nICQyIHVzYWJpbGl0eS4uLiAiID4mNjsgfQorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJDQK
KyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19oZWFkZXJfY29tcGlsZXI9eWVzCitlbHNlCisgIGFjX2hlYWRlcl9jb21w
aWxlcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg
Y29uZnRlc3QuJGFjX2V4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19oZWFkZXJfY29tcGlsZXIiID4mNQorJGFzX2VjaG8gIiRhY19oZWFkZXJf
Y29tcGlsZXIiID4mNjsgfQorCisjIElzIHRoZSBoZWFkZXIgcHJlc2VudD8KK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIgcHJlc2VuY2UiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgJDIgcHJlc2VuY2UuLi4gIiA+JjY7IH0KK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhl
biA6CisgIGFjX2hlYWRlcl9wcmVwcm9jPXllcworZWxzZQorICBhY19oZWFkZXJfcHJlcHJvYz1u
bworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfaGVhZGVy
X3ByZXByb2MiID4mNQorJGFzX2VjaG8gIiRhY19oZWFkZXJfcHJlcHJvYyIgPiY2OyB9CisKKyMg
U28/ICBXaGF0IGFib3V0IHRoaXMgaGVhZGVyPworY2FzZSAkYWNfaGVhZGVyX2NvbXBpbGVyOiRh
Y19oZWFkZXJfcHJlcHJvYzokYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAjKCgKKyAgeWVzOm5v
OiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiAkMjogYWNjZXB0ZWQgYnkgdGhlIGNvbXBpbGVyLCByZWplY3RlZCBieSB0aGUgcHJlcHJvY2Vz
c29yISIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogYWNjZXB0ZWQgYnkgdGhl
IGNvbXBpbGVyLCByZWplY3RlZCBieSB0aGUgcHJlcHJvY2Vzc29yISIgPiYyO30KKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBwcm9jZWVk
aW5nIHdpdGggdGhlIGNvbXBpbGVyJ3MgcmVzdWx0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6ICQyOiBwcm9jZWVkaW5nIHdpdGggdGhlIGNvbXBpbGVyJ3MgcmVzdWx0IiA+JjI7fQor
ICAgIDs7CisgIG5vOnllczoqICkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3QgYmUgY29tcGlsZWQiID4m
NQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHByZXNlbnQgYnV0IGNhbm5vdCBiZSBj
b21waWxlZCIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IFdBUk5JTkc6ICQyOiAgICAgY2hlY2sgZm9yIG1pc3NpbmcgcHJlcmVxdWlzaXRlIGhlYWRl
cnM/IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiAgICAgY2hlY2sgZm9yIG1p
c3NpbmcgcHJlcmVxdWlzaXRlIGhlYWRlcnM/IiA+JjI7fQorICAgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6IHNlZSB0aGUgQXV0b2NvbmYgZG9j
dW1lbnRhdGlvbiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogc2VlIHRoZSBB
dXRvY29uZiBkb2N1bWVudGF0aW9uIiA+JjI7fQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6ICAgICBzZWN0aW9uIFwiUHJlc2VudCBCdXQg
Q2Fubm90IEJlIENvbXBpbGVkXCIiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6
ICAgICBzZWN0aW9uIFwiUHJlc2VudCBCdXQgQ2Fubm90IEJlIENvbXBpbGVkXCIiID4mMjt9Cisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjog
cHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIg
PiYyO30KKyggJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tICMjCisjIyBSZXBvcnQgdGhpcyB0byB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbSAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
IyMiCisgICAgICkgfCBzZWQgInMvXi8kYXNfbWU6IFdBUk5JTkc6ICAgICAvIiA+JjIKKyAgICA7
OworZXNhYworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+JjY7IH0K
K2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBldmFsICIkMz1cJGFjX2hlYWRlcl9jb21waWxlciIKK2ZpCitldmFsIGFj
X3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KK2ZpCisg
IGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xp
bmVubworCit9ICMgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbAorCisjIGFjX2ZuX2NfdHJ5
X3J1biBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gbGluayBjb25m
dGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuIEFzc3VtZXMK
KyMgdGhhdCBleGVjdXRhYmxlcyAqY2FuKiBiZSBydW4uCithY19mbl9jX3RyeV9ydW4gKCkKK3sK
KyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9f
c3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2Ug
IigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry
eTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0i
XCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hv
ICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0
YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk
YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfSAmJiB7IGFjX3RyeT0nLi9j
b25mdGVzdCRhY19leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAq
XGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNf
dHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAg
KGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfTsgfTsgdGhlbiA6CisgIGFjX3JldHZhbD0wCitlbHNlCisgICRhc19lY2hv
ICIkYXNfbWU6IHByb2dyYW0gZXhpdGVkIHdpdGggc3RhdHVzICRhY19zdGF0dXMiID4mNQorICAg
ICAgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQorc2VkICdzL14v
fCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCisgICAgICAgYWNfcmV0dmFsPSRhY19zdGF0dXMK
K2ZpCisgIHJtIC1yZiBjb25mdGVzdC5kU1lNIGNvbmZ0ZXN0X2lwYThfY29uZnRlc3Qub28KKyAg
ZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQgYXNfbGlu
ZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMgYWNfZm5fY190cnlfcnVu
CisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSBMSU5FTk8gSEVBREVSIFZBUiBJTkNM
VURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4aXN0cyBhbmQgY2FuIGJlIGNvbXBpbGVk
IHVzaW5nIHRoZSBpbmNsdWRlIGZpbGVzIGluCisjIElOQ0xVREVTLCBzZXR0aW5nIHRoZSBjYWNo
ZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCithY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxl
ICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf
bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJDQKKyNpbmNs
dWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
OgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgorZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK2V2
YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQor
ICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19s
aW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUKKworIyBhY19mbl9jX3Ry
eV9saW5rIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gbGluayBj
b25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19m
bl9jX3RyeV9saW5rICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5l
bm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdCRhY19leGVleHQKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2xp
bmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2Vj
aG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNf
dHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIi
CiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj5j
b25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0
aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBj
YXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIK
KyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFj
X3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeworCSB0ZXN0IC16ICIk
YWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVycgorICAgICAgIH0g
JiYgdGVzdCAtcyBjb25mdGVzdCRhY19leGVleHQgJiYgeworCSB0ZXN0ICIkY3Jvc3NfY29tcGls
aW5nIiA9IHllcyB8fAorCSAkYXNfdGVzdF94IGNvbmZ0ZXN0JGFjX2V4ZWV4dAorICAgICAgIH07
IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQg
cHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKwor
CWFjX3JldHZhbD0xCitmaQorICAjIERlbGV0ZSB0aGUgSVBBL0lQTyAoSW50ZXIgUHJvY2VkdXJh
bCBBbmFseXNpcy9PcHRpbWl6YXRpb24pIGluZm9ybWF0aW9uCisgICMgY3JlYXRlZCBieSB0aGUg
UEdJIGNvbXBpbGVyIChjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vKSwgYXMgaXQgd291bGQKKyAg
IyBpbnRlcmZlcmUgd2l0aCB0aGUgbmV4dCBsaW5rIGNvbW1hbmQ7IGFsc28gZGVsZXRlIGEgZGly
ZWN0b3J5IHRoYXQgaXMKKyAgIyBsZWZ0IGJlaGluZCBieSBBcHBsZSdzIGNvbXBpbGVyLiAgV2Ug
ZG8gdGhpcyBiZWZvcmUgZXhlY3V0aW5nIHRoZSBhY3Rpb25zLgorICBybSAtcmYgY29uZnRlc3Qu
ZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsg
JHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworICBhc19mbl9zZXRfc3RhdHVz
ICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5X2xpbmsKKworIyBhY19mbl9jX2NoZWNrX3R5
cGUgTElORU5PIFRZUEUgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhlciBUWVBFIGV4aXN0cyBhZnRlciBoYXZp
bmcgaW5jbHVkZWQgSU5DTFVERVMsIHNldHRpbmcgY2FjaGUKKyMgdmFyaWFibGUgVkFSIGFjY29y
ZGluZ2x5LgorYWNfZm5fY19jaGVja190eXBlICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVu
by0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFs
IFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgZXZhbCAiJDM9bm8iCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0CitpbnQKK21haW4gKCkKK3sKK2lm
IChzaXplb2YgKCQyKSkKKwkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
JDQKK2ludAorbWFpbiAoKQoreworaWYgKHNpemVvZiAoKCQyKSkpCisJICAgIHJldHVybiAwOwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgZXZhbCAiJDM9eWVzIgorZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1m
IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAor
ZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4m
NjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNl
dCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfdHlwZQorCisjIGFjX2ZuX2NfY2hlY2tf
ZnVuYyBMSU5FTk8gRlVOQyBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3RzLCBzZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJs
ZSBWQVIgYWNjb3JkaW5nbHkKK2FjX2ZuX2NfY2hlY2tfZnVuYyAoKQoreworICBhc19saW5lbm89
JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGlu
ZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4uLiAiID4mNjsg
fQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIERlZmluZSAkMiB0byBhbiBpbm5vY3VvdXMg
dmFyaWFudCwgaW4gY2FzZSA8bGltaXRzLmg+IGRlY2xhcmVzICQyLgorICAgRm9yIGV4YW1wbGUs
IEhQLVVYIDExaSA8bGltaXRzLmg+IGRlY2xhcmVzIGdldHRpbWVvZmRheS4gICovCisjZGVmaW5l
ICQyIGlubm9jdW91c18kMgorCisvKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFj
cm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCisgICAgd2hpY2ggY2FuIGNvbmZsaWN0
IHdpdGggY2hhciAkMiAoKTsgYmVsb3cuCisgICAgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2Vy
dC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAgIDxsaW1pdHMuaD4gZXhpc3Rz
IGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4gICovCisKKyNpZmRlZiBfX1NURENfXwor
IyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlm
CisKKyN1bmRlZiAkMgorCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0
byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo
ZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQg
cHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0
ZXJuICJDIgorI2VuZGlmCitjaGFyICQyICgpOworLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5l
cyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cworICAgIHRvIGFsd2F5cyBm
YWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkCisgICAg
c29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlh
cy4gICovCisjaWYgZGVmaW5lZCBfX3N0dWJfJDIgfHwgZGVmaW5lZCBfX3N0dWJfX18kMgorY2hv
a2UgbWUKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAkMiAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgorZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkMworCSAgICAgICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Cisk
YXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19s
aW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNfZm5fY19jaGVja19mdW5j
CisKKyMgYWNfZm5fY19maW5kX2ludFhfdCBMSU5FTk8gQklUUyBWQVIKKyMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgRmluZHMgYSBzaWduZWQgaW50ZWdlciB0eXBlIHdp
dGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIKKyMgYWNjb3JkaW5nbHku
CithY19mbl9jX2ZpbmRfaW50WF90ICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEi
fSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW50JDJf
dCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW50JDJfdC4uLiAiID4mNjsgfQoraWYg
ZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAtIG5ldmVy
IGNoZWNrIGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKKyAgICAgIyB0aGFuIGhh
bGYgb2YgdGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KKyAgICAgZm9yIGFjX3R5cGUgaW4gaW50
JDJfdCAnaW50JyAnbG9uZyBpbnQnIFwKKwkgJ2xvbmcgbG9uZyBpbnQnICdzaG9ydCBpbnQnICdz
aWduZWQgY2hhcic7IGRvCisgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQK
KwkgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7CitzdGF0aWMg
aW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAx
IDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAor
LyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKwkgICAgICAgIGVu
dW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7CitzdGF0aWMgaW50IHRlc3Rf
YXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwgTikg
LSAxKSAqIDIgKyAxKQorCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUpIDEgPDwgTikgPDwg
TikgLSAxKSAqIDIgKyAyKSldOwordGVzdF9hcnJheSBbMF0gPSAwCisKKyAgOworICByZXR1cm4g
MDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgor
CitlbHNlCisgIGNhc2UgJGFjX3R5cGUgaW4gIygKKyAgaW50JDJfdCkgOgorICAgIGV2YWwgIiQz
PXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsg
dGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFjX3Jlcz1c
JCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNf
bGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQgYXNfbGluZW5vCisKK30g
IyBhY19mbl9jX2ZpbmRfaW50WF90CisKKyMgYWNfZm5fY19jaGVja19tZW1iZXIgTElORU5PIEFH
R1IgTUVNQkVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyaWVzIHRvIGZpbmQgaWYgdGhlIGZpZWxkIE1FTUJF
UiBleGlzdHMgaW4gdHlwZSBBR0dSLCBhZnRlciBpbmNsdWRpbmcKKyMgSU5DTFVERVMsIHNldHRp
bmcgY2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19tZW1iZXIg
KCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19s
aW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMi4kMyIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJDIuJDMuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDQrOn0gZmFsc2U7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAt
IDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNQor
aW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChhY19hZ2dyLiQzKQorcmV0
dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBp
bGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDQ9eWVzIgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CiskNQoraW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChzaXplb2YgYWNf
YWdnci4kMykKK3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwgIiQ0PXllcyIKK2Vsc2UK
KyAgZXZhbCAiJDQ9bm8iCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkNAor
CSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVu
b19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNf
Zm5fY19jaGVja19tZW1iZXIKKworIyBhY19mbl9jX2ZpbmRfdWludFhfdCBMSU5FTk8gQklUUyBW
QVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEZpbmRzIGFuIHVu
c2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRoIEJJVFMsIHNldHRpbmcgY2FjaGUgdmFyaWFi
bGUgVkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19maW5kX3VpbnRYX3QgKCkKK3sKKyAgYXNf
bGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9
JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
dWludCQyX3QuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIkMz1ubyIKKyAgICAgIyBP
cmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxs
eSBzbWFsbGVyCisgICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGgu
CisgICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90ICd1bnNpZ25lZCBpbnQnICd1bnNpZ25lZCBs
b25nIGludCcgXAorCSAndW5zaWduZWQgbG9uZyBsb25nIGludCcgJ3Vuc2lnbmVkIHNob3J0IGlu
dCcgJ3Vuc2lnbmVkIGNoYXInOyBkbworICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19k
ZWZhdWx0CitpbnQKK21haW4gKCkKK3sKK3N0YXRpYyBpbnQgdGVzdF9hcnJheSBbMSAtIDIgKiAh
KCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8gMiAtIDEpID09IDMpXTsK
K3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2FzZSAkYWNfdHlwZSBpbiAj
KAorICB1aW50JDJfdCkgOgorICAgIGV2YWwgIiQzPXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2
YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3Qg
XCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRv
bmUKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVz
IiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0g
dW5zZXQgYXNfbGluZW5vCisKK30gIyBhY19mbl9jX2ZpbmRfdWludFhfdAorY2F0ID5jb25maWcu
bG9nIDw8X0FDRU9GCitUaGlzIGZpbGUgY29udGFpbnMgYW55IG1lc3NhZ2VzIHByb2R1Y2VkIGJ5
IGNvbXBpbGVycyB3aGlsZQorcnVubmluZyBjb25maWd1cmUsIHRvIGFpZCBkZWJ1Z2dpbmcgaWYg
Y29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KKworSXQgd2FzIGNyZWF0ZWQgYnkgWGVuIEh5cGVy
dmlzb3IgJGFzX21lIDQuMiwgd2hpY2ggd2FzCitnZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIu
NjguICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICAkICQwICRACisKK19BQ0VPRgor
ZXhlYyA1Pj5jb25maWcubG9nCit7CitjYXQgPDxfQVNVTkFNRQorIyMgLS0tLS0tLS0tICMjCisj
IyBQbGF0Zm9ybS4gIyMKKyMjIC0tLS0tLS0tLSAjIworCitob3N0bmFtZSA9IGAoaG9zdG5hbWUg
fHwgdW5hbWUgLW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAordW5hbWUgLW0gPSBgKHVuYW1lIC1t
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtciA9IGAodW5hbWUgLXIpIDI+
L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1zID0gYCh1bmFtZSAtcykgMj4vZGV2
L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXYgPSBgKHVuYW1lIC12KSAyPi9kZXYvbnVs
bCB8fCBlY2hvIHVua25vd25gCisKKy91c3IvYmluL3VuYW1lIC1wID0gYCgvdXNyL2Jpbi91bmFt
ZSAtcCkgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAorL2Jpbi91bmFtZSAtWCAgICAgPSBg
KC9iaW4vdW5hbWUgLVgpIDI+L2Rldi9udWxsICAgICB8fCBlY2hvIHVua25vd25gCisKKy9iaW4v
YXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkgMj4vZGV2L251bGwgICAgICAgICAgICAg
IHx8IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL2FyY2ggLWsgICAgICAgPSBgKC91c3IvYmluL2Fy
Y2ggLWspIDI+L2Rldi9udWxsICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy91c3IvY29udmV4L2dl
dHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dldHN5c2luZm8pIDI+L2Rldi9udWxsIHx8IGVjaG8g
dW5rbm93bmAKKy91c3IvYmluL2hvc3RpbmZvICAgICAgPSBgKC91c3IvYmluL2hvc3RpbmZvKSAy
Pi9kZXYvbnVsbCAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vbWFjaGluZSAgICAgICAgICAg
PSBgKC9iaW4vbWFjaGluZSkgMj4vZGV2L251bGwgICAgICAgICAgIHx8IGVjaG8gdW5rbm93bmAK
Ky91c3IvYmluL29zbGV2ZWwgICAgICAgPSBgKC91c3IvYmluL29zbGV2ZWwpIDI+L2Rldi9udWxs
ICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vdW5pdmVyc2UgICAgICAgICAgPSBgKC9iaW4v
dW5pdmVyc2UpIDI+L2Rldi9udWxsICAgICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKworX0FTVU5B
TUUKKworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBp
biAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgorICAgICRhc19lY2hvICJQQVRIOiAkYXNfZGlyIgorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK30gPiY1CisKK2NhdCA+JjUgPDxfQUNFT0YKKworCisjIyAtLS0tLS0tLS0tLSAj
IworIyMgQ29yZSB0ZXN0cy4gIyMKKyMjIC0tLS0tLS0tLS0tICMjCisKK19BQ0VPRgorCisKKyMg
S2VlcCBhIHRyYWNlIG9mIHRoZSBjb21tYW5kIGxpbmUuCisjIFN0cmlwIG91dCAtLW5vLWNyZWF0
ZSBhbmQgLS1uby1yZWN1cnNpb24gc28gdGhleSBkbyBub3QgcGlsZSB1cC4KKyMgU3RyaXAgb3V0
IC0tc2lsZW50IGJlY2F1c2Ugd2UgZG9uJ3Qgd2FudCB0byByZWNvcmQgaXQgZm9yIGZ1dHVyZSBy
dW5zLgorIyBBbHNvIHF1b3RlIGFueSBhcmdzIGNvbnRhaW5pbmcgc2hlbGwgbWV0YS1jaGFyYWN0
ZXJzLgorIyBNYWtlIHR3byBwYXNzZXMgdG8gYWxsb3cgZm9yIHByb3BlciBkdXBsaWNhdGUtYXJn
dW1lbnQgc3VwcHJlc3Npb24uCithY19jb25maWd1cmVfYXJncz0KK2FjX2NvbmZpZ3VyZV9hcmdz
MD0KK2FjX2NvbmZpZ3VyZV9hcmdzMT0KK2FjX211c3Rfa2VlcF9uZXh0PWZhbHNlCitmb3IgYWNf
cGFzcyBpbiAxIDIKK2RvCisgIGZvciBhY19hcmcKKyAgZG8KKyAgICBjYXNlICRhY19hcmcgaW4K
KyAgICAtbm8tY3JlYXRlIHwgLS1uby1jKiB8IC1uIHwgLW5vLXJlY3Vyc2lvbiB8IC0tbm8tciop
IGNvbnRpbnVlIDs7CisgICAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwgLS1xdWllIHwgLS1xdWkg
fCAtLXF1IHwgLS1xIFwKKyAgICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8IC0tc2lsZW4gfCAtLXNp
bGUgfCAtLXNpbCkKKyAgICAgIGNvbnRpbnVlIDs7CisgICAgKlwnKikKKyAgICAgIGFjX2FyZz1g
JGFzX2VjaG8gIiRhY19hcmciIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgIDs7CisgICAgZXNh
YworICAgIGNhc2UgJGFjX3Bhc3MgaW4KKyAgICAxKSBhc19mbl9hcHBlbmQgYWNfY29uZmlndXJl
X2FyZ3MwICIgJyRhY19hcmcnIiA7OworICAgIDIpCisgICAgICBhc19mbl9hcHBlbmQgYWNfY29u
ZmlndXJlX2FyZ3MxICIgJyRhY19hcmcnIgorICAgICAgaWYgdGVzdCAkYWNfbXVzdF9rZWVwX25l
eHQgPSB0cnVlOyB0aGVuCisJYWNfbXVzdF9rZWVwX25leHQ9ZmFsc2UgIyBHb3QgdmFsdWUsIGJh
Y2sgdG8gbm9ybWFsLgorICAgICAgZWxzZQorCWNhc2UgJGFjX2FyZyBpbgorCSAgKj0qIHwgLS1j
b25maWctY2FjaGUgfCAtQyB8IC1kaXNhYmxlLSogfCAtLWRpc2FibGUtKiBcCisJICB8IC1lbmFi
bGUtKiB8IC0tZW5hYmxlLSogfCAtZ2FzIHwgLS1nKiB8IC1uZnAgfCAtLW5mKiBcCisJICB8IC1x
IHwgLXF1aWV0IHwgLS1xKiB8IC1zaWxlbnQgfCAtLXNpbCogfCAtdiB8IC12ZXJiKiBcCisJICB8
IC13aXRoLSogfCAtLXdpdGgtKiB8IC13aXRob3V0LSogfCAtLXdpdGhvdXQtKiB8IC0teCkKKwkg
ICAgY2FzZSAiJGFjX2NvbmZpZ3VyZV9hcmdzMCAiIGluCisJICAgICAgIiRhY19jb25maWd1cmVf
YXJnczEiKiIgJyRhY19hcmcnICIqICkgY29udGludWUgOzsKKwkgICAgZXNhYworCSAgICA7Owor
CSAgLSogKSBhY19tdXN0X2tlZXBfbmV4dD10cnVlIDs7CisJZXNhYworICAgICAgZmkKKyAgICAg
IGFzX2ZuX2FwcGVuZCBhY19jb25maWd1cmVfYXJncyAiICckYWNfYXJnJyIKKyAgICAgIDs7Cisg
ICAgZXNhYworICBkb25lCitkb25lCit7IGFjX2NvbmZpZ3VyZV9hcmdzMD07IHVuc2V0IGFjX2Nv
bmZpZ3VyZV9hcmdzMDt9Cit7IGFjX2NvbmZpZ3VyZV9hcmdzMT07IHVuc2V0IGFjX2NvbmZpZ3Vy
ZV9hcmdzMTt9CisKKyMgV2hlbiBpbnRlcnJ1cHRlZCBvciBleGl0J2QsIGNsZWFudXAgdGVtcG9y
YXJ5IGZpbGVzLCBhbmQgY29tcGxldGUKKyMgY29uZmlnLmxvZy4gIFdlIHJlbW92ZSBjb21tZW50
cyBiZWNhdXNlIGFueXdheSB0aGUgcXVvdGVzIGluIHRoZXJlCisjIHdvdWxkIGNhdXNlIHByb2Js
ZW1zIG9yIGxvb2sgdWdseS4KKyMgV0FSTklORzogVXNlICdcJycgdG8gcmVwcmVzZW50IGFuIGFw
b3N0cm9waGUgd2l0aGluIHRoZSB0cmFwLgorIyBXQVJOSU5HOiBEbyBub3Qgc3RhcnQgdGhlIHRy
YXAgY29kZSB3aXRoIGEgbmV3bGluZSwgZHVlIHRvIGEgRnJlZUJTRCA0LjAgYnVnLgordHJhcCAn
ZXhpdF9zdGF0dXM9JD8KKyAgIyBTYXZlIGludG8gY29uZmlnLmxvZyBzb21lIGluZm9ybWF0aW9u
IHRoYXQgbWlnaHQgaGVscCBpbiBkZWJ1Z2dpbmcuCisgIHsKKyAgICBlY2hvCisKKyAgICAkYXNf
ZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgQ2FjaGUgdmFyaWFibGVzLiAjIworIyMg
LS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisgICAgIyBUaGUgZm9sbG93aW5nIHdheSBv
ZiB3cml0aW5nIHRoZSBjYWNoZSBtaXNoYW5kbGVzIG5ld2xpbmVzIGluIHZhbHVlcywKKygKKyAg
Zm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAtbiAnXCcncy9eXChbYS16QS1aX11bYS16
QS1aMC05X10qXCk9LiovXDEvcCdcJydgOyBkbworICAgIGV2YWwgYWNfdmFsPVwkJGFjX3Zhcgor
ICAgIGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSopCisgICAgICBjYXNlICRhY192
YXIgaW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGlu
ZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFy
IGNvbnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVzYWMKKyAgICAgIGNhc2UgJGFj
X3ZhciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAjKAorICAgICAgQkFTSF9BUkdW
IHwgQkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAgICAgICopIHsgZXZhbCAkYWNf
dmFyPTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7CisgICAgZXNhYworICBkb25l
CisgIChzZXQpIDI+JjEgfAorICAgIGNhc2UgJGFzX25sYChhY19zcGFjZT0nXCcnICdcJyc7IHNl
dCkgMj4mMWAgaW4gIygKKyAgICAqJHthc19ubH1hY19zcGFjZT1cICopCisgICAgICBzZWQgLW4g
XAorCSJzLydcJycvJ1wnJ1xcXFwnXCcnJ1wnJy9nOworCSAgcy9eXFwoW18kYXNfY3JfYWxudW1d
Kl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwpL1xcMT0nXCcnXFwyJ1wnJy9wIgorICAg
ICAgOzsgIygKKyAgICAqKQorICAgICAgc2VkIC1uICIvXltfJGFzX2NyX2FsbnVtXSpfY3ZfW18k
YXNfY3JfYWxudW1dKj0vcCIKKyAgICAgIDs7CisgICAgZXNhYyB8CisgICAgc29ydAorKQorICAg
IGVjaG8KKworICAgICRhc19lY2hvICIjIyAtLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgT3V0cHV0
IHZhcmlhYmxlcy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tICMjIgorICAgIGVjaG8KKyAgICBm
b3IgYWNfdmFyIGluICRhY19zdWJzdF92YXJzCisgICAgZG8KKyAgICAgIGV2YWwgYWNfdmFsPVwk
JGFjX3ZhcgorICAgICAgY2FzZSAkYWNfdmFsIGluCisgICAgICAqXCdcJycqKSBhY192YWw9YCRh
c19lY2hvICIkYWNfdmFsIiB8IHNlZCAicy8nXCcnLydcJydcXFxcXFxcXCdcJycnXCcnL2ciYDs7
CisgICAgICBlc2FjCisgICAgICAkYXNfZWNobyAiJGFjX3Zhcj0nXCcnJGFjX3ZhbCdcJyciCisg
ICAgZG9uZSB8IHNvcnQKKyAgICBlY2hvCisKKyAgICBpZiB0ZXN0IC1uICIkYWNfc3Vic3RfZmls
ZXMiOyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMg
RmlsZSBzdWJzdGl0dXRpb25zLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICAg
IGVjaG8KKyAgICAgIGZvciBhY192YXIgaW4gJGFjX3N1YnN0X2ZpbGVzCisgICAgICBkbworCWV2
YWwgYWNfdmFsPVwkJGFjX3ZhcgorCWNhc2UgJGFjX3ZhbCBpbgorCSpcJ1wnJyopIGFjX3ZhbD1g
JGFzX2VjaG8gIiRhY192YWwiIHwgc2VkICJzLydcJycvJ1wnJ1xcXFxcXFxcJ1wnJydcJycvZyJg
OzsKKwllc2FjCisJJGFzX2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwnXCcnIgorICAgICAgZG9u
ZSB8IHNvcnQKKyAgICAgIGVjaG8KKyAgICBmaQorCisgICAgaWYgdGVzdCAtcyBjb25mZGVmcy5o
OyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0gIyMKKyMjIGNvbmZkZWZzLmgu
ICMjCisjIyAtLS0tLS0tLS0tLSAjIyIKKyAgICAgIGVjaG8KKyAgICAgIGNhdCBjb25mZGVmcy5o
CisgICAgICBlY2hvCisgICAgZmkKKyAgICB0ZXN0ICIkYWNfc2lnbmFsIiAhPSAwICYmCisgICAg
ICAkYXNfZWNobyAiJGFzX21lOiBjYXVnaHQgc2lnbmFsICRhY19zaWduYWwiCisgICAgJGFzX2Vj
aG8gIiRhc19tZTogZXhpdCAkZXhpdF9zdGF0dXMiCisgIH0gPiY1CisgIHJtIC1mIGNvcmUgKi5j
b3JlIGNvcmUuY29uZnRlc3QuKiAmJgorICAgIHJtIC1mIC1yIGNvbmZ0ZXN0KiBjb25mZGVmcyog
Y29uZiQkKiAkYWNfY2xlYW5fZmlsZXMgJiYKKyAgICBleGl0ICRleGl0X3N0YXR1cworJyAwCitm
b3IgYWNfc2lnbmFsIGluIDEgMiAxMyAxNTsgZG8KKyAgdHJhcCAnYWNfc2lnbmFsPSckYWNfc2ln
bmFsJzsgYXNfZm5fZXhpdCAxJyAkYWNfc2lnbmFsCitkb25lCithY19zaWduYWw9MAorCisjIGNv
bmZkZWZzLmggYXZvaWRzIE9TIGNvbW1hbmQgbGluZSBsZW5ndGggbGltaXRzIHRoYXQgREVGUyBj
YW4gZXhjZWVkLgorcm0gLWYgLXIgY29uZnRlc3QqIGNvbmZkZWZzLmgKKworJGFzX2VjaG8gIi8q
IGNvbmZkZWZzLmggKi8iID4gY29uZmRlZnMuaAorCisjIFByZWRlZmluZWQgcHJlcHJvY2Vzc29y
IHZhcmlhYmxlcy4KKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdF
X05BTUUgIiRQQUNLQUdFX05BTUUiCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
RgorI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgIiRQQUNLQUdFX1RBUk5BTUUiCitfQUNFT0YKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04gIiRQQUNL
QUdFX1ZFUlNJT04iCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBQQUNLQUdFX1NUUklORyAiJFBBQ0tBR0VfU1RSSU5HIgorX0FDRU9GCisKK2NhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9CVUdSRVBPUlQgIiRQQUNLQUdFX0JVR1JF
UE9SVCIKK19BQ0VPRgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIFBBQ0tB
R0VfVVJMICIkUEFDS0FHRV9VUkwiCitfQUNFT0YKKworCisjIExldCB0aGUgc2l0ZSBmaWxlIHNl
bGVjdCBhbiBhbHRlcm5hdGUgY2FjaGUgZmlsZSBpZiBpdCB3YW50cyB0by4KKyMgUHJlZmVyIGFu
IGV4cGxpY2l0bHkgc2VsZWN0ZWQgZmlsZSB0byBhdXRvbWF0aWNhbGx5IHNlbGVjdGVkIG9uZXMu
CithY19zaXRlX2ZpbGUxPU5PTkUKK2FjX3NpdGVfZmlsZTI9Tk9ORQoraWYgdGVzdCAtbiAiJENP
TkZJR19TSVRFIjsgdGhlbgorICAjIFdlIGRvIG5vdCB3YW50IGEgUEFUSCBzZWFyY2ggZm9yIGNv
bmZpZy5zaXRlLgorICBjYXNlICRDT05GSUdfU0lURSBpbiAjKCgKKyAgICAtKikgIGFjX3NpdGVf
ZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICAgICovKikgYWNfc2l0ZV9maWxlMT0kQ09ORklHX1NJ
VEU7OworICAgICopICAgYWNfc2l0ZV9maWxlMT0uLyRDT05GSUdfU0lURTs7CisgIGVzYWMKK2Vs
aWYgdGVzdCAieCRwcmVmaXgiICE9IHhOT05FOyB0aGVuCisgIGFjX3NpdGVfZmlsZTE9JHByZWZp
eC9zaGFyZS9jb25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUyPSRwcmVmaXgvZXRjL2NvbmZpZy5z
aXRlCitlbHNlCisgIGFjX3NpdGVfZmlsZTE9JGFjX2RlZmF1bHRfcHJlZml4L3NoYXJlL2NvbmZp
Zy5zaXRlCisgIGFjX3NpdGVfZmlsZTI9JGFjX2RlZmF1bHRfcHJlZml4L2V0Yy9jb25maWcuc2l0
ZQorZmkKK2ZvciBhY19zaXRlX2ZpbGUgaW4gIiRhY19zaXRlX2ZpbGUxIiAiJGFjX3NpdGVfZmls
ZTIiCitkbworICB0ZXN0ICJ4JGFjX3NpdGVfZmlsZSIgPSB4Tk9ORSAmJiBjb250aW51ZQorICBp
ZiB0ZXN0IC9kZXYvbnVsbCAhPSAiJGFjX3NpdGVfZmlsZSIgJiYgdGVzdCAtciAiJGFjX3NpdGVf
ZmlsZSI7IHRoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGxvYWRpbmcgc2l0ZSBzY3JpcHQgJGFjX3NpdGVfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUiID4mNjt9CisgICAgc2VkICdzL14v
fCAvJyAiJGFjX3NpdGVfZmlsZSIgPiY1CisgICAgLiAiJGFjX3NpdGVfZmlsZSIgXAorICAgICAg
fHwgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mMjt9Cithc19mbl9lcnJvciAkPyAiZmFpbGVkIHRvIGxvYWQgc2l0ZSBzY3JpcHQgJGFjX3Np
dGVfZmlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7
IH0KKyAgZmkKK2RvbmUKKworaWYgdGVzdCAtciAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICMgU29t
ZSB2ZXJzaW9ucyBvZiBiYXNoIHdpbGwgZmFpbCB0byBzb3VyY2UgL2Rldi9udWxsIChzcGVjaWFs
IGZpbGVzCisgICMgYWN0dWFsbHkpLCBzbyB3ZSBhdm9pZCBkb2luZyB0aGF0LiAgREpHUFAgZW11
bGF0ZXMgaXQgYXMgYSByZWd1bGFyIGZpbGUuCisgIGlmIHRlc3QgL2Rldi9udWxsICE9ICIkY2Fj
aGVfZmlsZSIgJiYgdGVzdCAtZiAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBsb2FkaW5nIGNhY2hlICRjYWNoZV9maWxlIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGxvYWRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9Cisg
ICAgY2FzZSAkY2FjaGVfZmlsZSBpbgorICAgICAgW1xcL10qIHwgPzpbXFwvXSogKSAuICIkY2Fj
aGVfZmlsZSI7OworICAgICAgKikgICAgICAgICAgICAgICAgICAgICAgLiAiLi8kY2FjaGVfZmls
ZSI7OworICAgIGVzYWMKKyAgZmkKK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY1CiskYXNfZWNobyAi
JGFzX21lOiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAgPiRjYWNoZV9maWxl
CitmaQorCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvdGltZS5oIgorYXNfZm5f
YXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCithc19mbl9hcHBlbmQgYWNfZnVuY19s
aXN0ICIgYWxhcm0iCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzdGRsaWIuaCIKK2Fz
X2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgorIyBDaGVjayB0aGF0IHRo
ZSBwcmVjaW91cyB2YXJpYWJsZXMgc2F2ZWQgaW4gdGhlIGNhY2hlIGhhdmUga2VwdCB0aGUgc2Ft
ZQorIyB2YWx1ZS4KK2FjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQorZm9yIGFjX3ZhciBpbiAkYWNf
cHJlY2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19vbGRfc2V0PVwkYWNfY3ZfZW52XyR7YWNfdmFy
fV9zZXQKKyAgZXZhbCBhY19uZXdfc2V0PVwkYWNfZW52XyR7YWNfdmFyfV9zZXQKKyAgZXZhbCBh
Y19vbGRfdmFsPVwkYWNfY3ZfZW52XyR7YWNfdmFyfV92YWx1ZQorICBldmFsIGFjX25ld192YWw9
XCRhY19lbnZfJHthY192YXJ9X3ZhbHVlCisgIGNhc2UgJGFjX29sZF9zZXQsJGFjX25ld19zZXQg
aW4KKyAgICBzZXQsKQorICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgc2V0IHRvIFxgJGFjX29sZF92YWwnIGluIHRoZSBw
cmV2aW91cyBydW4iID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IFxgJGFjX3Zhcicgd2Fz
IHNldCB0byBcYCRhY19vbGRfdmFsJyBpbiB0aGUgcHJldmlvdXMgcnVuIiA+JjI7fQorICAgICAg
YWNfY2FjaGVfY29ycnVwdGVkPTogOzsKKyAgICAsc2V0KQorICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgbm90IHNldCBp
biB0aGUgcHJldmlvdXMgcnVuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBcYCRhY192
YXInIHdhcyBub3Qgc2V0IGluIHRoZSBwcmV2aW91cyBydW4iID4mMjt9CisgICAgICBhY19jYWNo
ZV9jb3JydXB0ZWQ9OiA7OworICAgICwpOzsKKyAgICAqKQorICAgICAgaWYgdGVzdCAieCRhY19v
bGRfdmFsIiAhPSAieCRhY19uZXdfdmFsIjsgdGhlbgorCSMgZGlmZmVyZW5jZXMgaW4gd2hpdGVz
cGFjZSBkbyBub3QgbGVhZCB0byBmYWlsdXJlLgorCWFjX29sZF92YWxfdz1gZWNobyB4ICRhY19v
bGRfdmFsYAorCWFjX25ld192YWxfdz1gZWNobyB4ICRhY19uZXdfdmFsYAorCWlmIHRlc3QgIiRh
Y19vbGRfdmFsX3ciICE9ICIkYWNfbmV3X3ZhbF93IjsgdGhlbgorCSAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFyJyBoYXMgY2hhbmdlZCBz
aW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogXGAk
YWNfdmFyJyBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiYyO30KKwkgIGFj
X2NhY2hlX2NvcnJ1cHRlZD06CisJZWxzZQorCSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiB3YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gXGAk
YWNfdmFyJyBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiB3
YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gXGAkYWNfdmFyJyBzaW5jZSB0
aGUgcHJldmlvdXMgcnVuOiIgPiYyO30KKwkgIGV2YWwgJGFjX3Zhcj1cJGFjX29sZF92YWwKKwlm
aQorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogICBmb3JtZXIgdmFs
dWU6ICBcYCRhY19vbGRfdmFsJyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAgIGZvcm1lciB2YWx1
ZTogIFxgJGFjX29sZF92YWwnIiA+JjI7fQorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogICBjdXJyZW50IHZhbHVlOiBcYCRhY19uZXdfdmFsJyIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiAgIGN1cnJlbnQgdmFsdWU6IFxgJGFjX25ld192YWwnIiA+JjI7fQorICAgICAg
Zmk7OworICBlc2FjCisgICMgUGFzcyBwcmVjaW91cyB2YXJpYWJsZXMgdG8gY29uZmlnLnN0YXR1
cy4KKyAgaWYgdGVzdCAiJGFjX25ld19zZXQiID0gc2V0OyB0aGVuCisgICAgY2FzZSAkYWNfbmV3
X3ZhbCBpbgorICAgICpcJyopIGFjX2FyZz0kYWNfdmFyPWAkYXNfZWNobyAiJGFjX25ld192YWwi
IHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgIDs7CisgICAgKikgYWNfYXJnPSRhY192YXI9JGFj
X25ld192YWwgOzsKKyAgICBlc2FjCisgICAgY2FzZSAiICRhY19jb25maWd1cmVfYXJncyAiIGlu
CisgICAgICAqIiAnJGFjX2FyZycgIiopIDs7ICMgQXZvaWQgZHVwcy4gIFVzZSBvZiBxdW90ZXMg
ZW5zdXJlcyBhY2N1cmFjeS4KKyAgICAgICopIGFzX2ZuX2FwcGVuZCBhY19jb25maWd1cmVfYXJn
cyAiICckYWNfYXJnJyIgOzsKKyAgICBlc2FjCisgIGZpCitkb25lCitpZiAkYWNfY2FjaGVfY29y
cnVwdGVkOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiYyO30KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBlcnJvcjogY2hhbmdlcyBpbiB0aGUgZW52aXJvbm1lbnQgY2FuIGNvbXByb21pc2UgdGhl
IGJ1aWxkIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjaGFuZ2VzIGluIHRoZSBlbnZp
cm9ubWVudCBjYW4gY29tcHJvbWlzZSB0aGUgYnVpbGQiID4mMjt9CisgIGFzX2ZuX2Vycm9yICQ/
ICJydW4gXGBtYWtlIGRpc3RjbGVhbicgYW5kL29yIFxgcm0gJGNhY2hlX2ZpbGUnIGFuZCBzdGFy
dCBvdmVyIiAiJExJTkVOTyIgNQorZmkKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBN
YWluIGJvZHkgb2Ygc2NyaXB0LiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKworYWNf
ZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFH
UyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRl
c3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQg
JExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKKwor
YWNfY29uZmlnX2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIC4uL2NvbmZpZy9Ub29scy5tayIKKwor
YWNfY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVhZGVycyBjb25maWcuaCIKKworCithY19h
dXhfZGlyPQorZm9yIGFjX2RpciBpbiAuICIkc3JjZGlyIi8uOyBkbworICBpZiB0ZXN0IC1mICIk
YWNfZGlyL2luc3RhbGwtc2giOyB0aGVuCisgICAgYWNfYXV4X2Rpcj0kYWNfZGlyCisgICAgYWNf
aW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvaW5zdGFsbC1zaCAtYyIKKyAgICBicmVhaworICBlbGlm
IHRlc3QgLWYgIiRhY19kaXIvaW5zdGFsbC5zaCI7IHRoZW4KKyAgICBhY19hdXhfZGlyPSRhY19k
aXIKKyAgICBhY19pbnN0YWxsX3NoPSIkYWNfYXV4X2Rpci9pbnN0YWxsLnNoIC1jIgorICAgIGJy
ZWFrCisgIGVsaWYgdGVzdCAtZiAiJGFjX2Rpci9zaHRvb2wiOyB0aGVuCisgICAgYWNfYXV4X2Rp
cj0kYWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvc2h0b29sIGluc3RhbGwg
LWMiCisgICAgYnJlYWsKKyAgZmkKK2RvbmUKK2lmIHRlc3QgLXogIiRhY19hdXhfZGlyIjsgdGhl
bgorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgaW5zdGFsbC1zaCwgaW5zdGFsbC5zaCwg
b3Igc2h0b29sIGluIC4gXCIkc3JjZGlyXCIvLiIgIiRMSU5FTk8iIDUKK2ZpCisKKyMgVGhlc2Ug
dGhyZWUgdmFyaWFibGVzIGFyZSB1bmRvY3VtZW50ZWQgYW5kIHVuc3VwcG9ydGVkLAorIyBhbmQg
YXJlIGludGVuZGVkIHRvIGJlIHdpdGhkcmF3biBpbiBhIGZ1dHVyZSBBdXRvY29uZiByZWxlYXNl
LgorIyBUaGV5IGNhbiBjYXVzZSBzZXJpb3VzIHByb2JsZW1zIGlmIGEgYnVpbGRlcidzIHNvdXJj
ZSB0cmVlIGlzIGluIGEgZGlyZWN0b3J5CisjIHdob3NlIGZ1bGwgbmFtZSBjb250YWlucyB1bnVz
dWFsIGNoYXJhY3RlcnMuCithY19jb25maWdfZ3Vlc3M9IiRTSEVMTCAkYWNfYXV4X2Rpci9jb25m
aWcuZ3Vlc3MiICAjIFBsZWFzZSBkb24ndCB1c2UgdGhpcyB2YXIuCithY19jb25maWdfc3ViPSIk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgICMgUGxlYXNlIGRvbid0IHVzZSB0aGlzIHZh
ci4KK2FjX2NvbmZpZ3VyZT0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZ3VyZSIgICMgUGxlYXNl
IGRvbid0IHVzZSB0aGlzIHZhci4KKworCisKKyMgQ2hlY2sgaWYgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5pbmcKKworaWYgdGVz
dCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIjsgdGhlbiA6CisKKyAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IFNldHRp
bmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCity
ZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitBUFBFTkRf
SU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiBTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMs
IENQUEZMQUdTIG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xV
REVTLCBQUkVQRU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3Rl
YWQgd2hlbiBwb3NzaWJsZS4iID4mMjt9CisKK2ZpCisKK2FjX2V4dD1jCithY19jcHA9JyRDUFAg
JENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0
LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdT
ICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBp
bGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK2lmIHRlc3QgLW4gIiRhY190b29sX3ByZWZp
eCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4
fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
JHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9
IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF
UEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0
ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAk
YWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1nY2Mi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRl
c3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19D
QyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBn
Y2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X0NDKzp9IGZhbHNlOyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFj
X2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ
QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG
UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp
biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0ND
CitpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19j
dF9DQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0
ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAk
Y3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5J
Tkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYy
O30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIENDPSRhY19jdF9DQworICBmaQor
ZWxzZQorICBDQz0iJGFjX2N2X3Byb2dfQ0MiCitmaQorCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVu
CisgICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAgICMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1j
YzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193
b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVu
CisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4m
NQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQor
ZmkKKworCisgIGZpCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCitlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9bm8KK2FzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGlmIHRlc3QgIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhlbgorICAgICAgIGFjX3By
b2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29udGludWUKKyAgICAgZmkKKyAgICBhY19jdl9wcm9n
X0NDPSJjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitk
b25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworaWYgdGVzdCAkYWNfcHJvZ19yZWplY3Rl
ZCA9IHllczsgdGhlbgorICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhlIHBhdGgsIHNvIG1ha2Ug
c3VyZSB3ZSBuZXZlciB1c2UgaXQuCisgIHNldCBkdW1teSAkYWNfY3ZfcHJvZ19DQworICBzaGlm
dAorICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KKyAgICAjIFdlIGNob3NlIGEgZGlmZmVyZW50IGNv
bXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KKyAgICAjIEhvd2V2ZXIsIGl0IGhhcyB0aGUgc2Ft
ZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCisgICAgIyBmaXJzdCBpZiB3
ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVsbCBmaWxlIG5hbWUuCisg
ICAgc2hpZnQKKyAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193b3JkJHsxKycgJ30kQCIK
KyAgZmkKK2ZpCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
Q0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNsLmV4ZQorICBkbworICAg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciLCBz
byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY190b29s
X3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZpeCRhY19wcm9nIgor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0
IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgdGVzdCAtbiAiJENDIiAmJiBicmVhaworICBk
b25lCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MKKyAgZm9yIGFj
X3Byb2cgaW4gY2wuZXhlCitkbworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRhY19w
cm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAk
YWNfcHJvZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1u
ICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNf
cHJvZyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9DQz0kYWNfY3ZfcHJv
Z19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2Zp
CisKKworICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCitkb25lCisKKyAgaWYgdGVzdCAi
eCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3Nz
X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1
c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cith
Y190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBDQz0kYWNfY3RfQ0MKKyAgZmkKK2ZpCisK
K2ZpCisKKwordGVzdCAteiAiJENDIiAmJiB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6
IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRh
YmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQQVRICitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9y
ZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorCisjIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBh
Ym91dCB0aGUgY29tcGlsZXIuCiskYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgQyBjb21waWxlciB2ZXJzaW9uIiA+JjUKK3NldCBYICRhY19jb21waWxl
CithY19jb21waWxlcj0kMgorZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJz
aW9uOyBkbworICB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCitjYXNl
ICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190
cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89
IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNo
byAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9u
ID4mNSIpIDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBpZiB0ZXN0IC1zIGNvbmZ0
ZXN0LmVycjsgdGhlbgorICAgIHNlZCAnMTBhXAorLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBk
ZWxldGVkIC4uLgorICAgICAgICAgMTBxJyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQorICAg
IGNhdCBjb25mdGVzdC5lcjEgPiY1CisgIGZpCisgIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVz
dC5lcnIKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFj
X3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KK2RvbmUKKworY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCithY19j
bGVhbl9maWxlc19zYXZlPSRhY19jbGVhbl9maWxlcworYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVh
bl9maWxlcyBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGIub3V0IgorIyBUcnkgdG8gY3JlYXRlIGFu
IGV4ZWN1dGFibGUgd2l0aG91dCAtbyBmaXJzdCwgZGlzcmVnYXJkIGEub3V0LgorIyBJdCB3aWxs
IGhlbHAgdXMgZGlhZ25vc2UgYnJva2VuIGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGlu
dHVpdGlvbgorIyBvZiBleGVleHQuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsgfQor
YWNfbGlua19kZWZhdWx0PWAkYXNfZWNobyAiJGFjX2xpbmsiIHwgc2VkICdzLyAtbyAqY29uZnRl
c3RbXiBdKi8vJ2AKKworIyBUaGUgcG9zc2libGUgb3V0cHV0IGZpbGVzOgorYWNfZmlsZXM9ImEu
b3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBhLmV4ZSBhX291dC5leGUgYi5vdXQgY29uZnRlc3Qu
KiIKKworYWNfcm1maWxlcz0KK2ZvciBhY19maWxlIGluICRhY19maWxlcworZG8KKyAgY2FzZSAk
YWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRi
IHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8
ICoub2JqICkgOzsKKyAgICAqICkgYWNfcm1maWxlcz0iJGFjX3JtZmlsZXMgJGFjX2ZpbGUiOzsK
KyAgZXNhYworZG9uZQorcm0gLWYgJGFjX3JtZmlsZXMKKworaWYgeyB7IGFjX3RyeT0iJGFjX2xp
bmtfZGVmYXVsdCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBh
Y190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYwor
ZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5
X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xp
bmtfZGVmYXVsdCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0
dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBBdXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3Zf
ZXhlZXh0IHZhcmlhYmxlIHRvIGBubycuCisjIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBubycsIG90
aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQgdG8gYEVYRUVYVCA9IG5vJworIyBpbiBhIE1ha2VmaWxl
LiAgV2Ugc2hvdWxkIG5vdCBvdmVycmlkZSBhY19jdl9leGVleHQgaWYgaXQgd2FzIGNhY2hlZCwK
KyMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9yIGNvbXBp
bGVycyB1bmtub3duIHRvCisjIEF1dG9jb25mLgorZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzICcn
CitkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAgY2FzZSAkYWNfZmlsZSBp
bgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lN
IHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkK
Kwk7OworICAgIFthYl0ub3V0ICkKKwkjIFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUs
IGJ1dCBleGVleHQ9JycgaXMgbW9zdAorCSMgY2VydGFpbmx5IHJpZ2h0LgorCWJyZWFrOzsKKyAg
ICAqLiogKQorCWlmIHRlc3QgIiR7YWNfY3ZfZXhlZXh0K3NldH0iID0gc2V0ICYmIHRlc3QgIiRh
Y19jdl9leGVleHQiICE9IG5vOworCXRoZW4gOjsgZWxzZQorCSAgIGFjX2N2X2V4ZWV4dD1gZXhw
ciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAorCWZpCisJIyBXZSBzZXQgYWNfY3ZfZXhl
ZXh0IGhlcmUgYmVjYXVzZSB0aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMgbm90CisJIyBzYWZlOiBj
cm9zcyBjb21waWxlcnMgbWF5IG5vdCBhZGQgdGhlIHN1ZmZpeCBpZiBnaXZlbiBhbiBgLW8nCisJ
IyBhcmd1bWVudCwgc28gd2UgbWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVh
ZHkuCisJIyBFdmVuIGlmIHRoaXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6IGl0IGhhcyB0aGUgYWR2
YW50YWdlIG9mCisJIyBhY3R1YWxseSB3b3JraW5nLgorCWJyZWFrOzsKKyAgICAqICkKKwlicmVh
azs7CisgIGVzYWMKK2RvbmUKK3Rlc3QgIiRhY19jdl9leGVleHQiID0gbm8gJiYgYWNfY3ZfZXhl
ZXh0PQorCitlbHNlCisgIGFjX2ZpbGU9JycKK2ZpCitpZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRo
ZW4gOgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBw
cm9ncmFtIHdhczoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCit7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFj
X3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYy
O30KK2FzX2ZuX2Vycm9yIDc3ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJsZXMK
K1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMi
ID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBm
aWxlIG5hbWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVs
dCBvdXRwdXQgZmlsZSBuYW1lLi4uICIgPiY2OyB9Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhY19maWxl
IiA+JjY7IH0KK2FjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0CisKK3JtIC1mIC1yIGEub3V0IGEub3V0
LmRTWU0gYS5leGUgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGIub3V0CithY19jbGVhbl9maWxlcz0k
YWNfY2xlYW5fZmlsZXNfc2F2ZQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMuLi4gIiA+JjY7IH0KK2lmIHsgeyBh
Y190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpc
XCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citl
c2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRh
Y190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIk
YWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMg
PSAwOyB9OyB0aGVuIDoKKyAgIyBJZiBib3RoIGBjb25mdGVzdC5leGUnIGFuZCBgY29uZnRlc3Qn
IGFyZSBgcHJlc2VudCcgKHdlbGwsIG9ic2VydmFibGUpCisjIGNhdGNoIGBjb25mdGVzdC5leGUn
LiAgRm9yIGluc3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3QnIHdpbGwKKyMgd29yayBw
cm9wZXJseSAoaS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScpLCB3aGlsZSBpdCB3b24ndCB3
aXRoCisjIGBybScuCitmb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUgY29uZnRlc3QgY29uZnRl
c3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2Zp
bGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICou
eFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9i
aiApIDs7CisgICAgKi4qICkgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpc
KFwuLipcKSdgCisJICBicmVhazs7CisgICAgKiApIGJyZWFrOzsKKyAgZXNhYworZG9uZQorZWxz
ZQorICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGlu
IFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2Qn
OiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0
YWJsZXM6IGNhbm5vdCBjb21waWxlIGFuZCBsaW5rCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9y
ZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorZmkKK3JtIC1mIGNvbmZ0ZXN0IGNvbmZ0ZXN0JGFj
X2N2X2V4ZWV4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9leGVleHQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9leGVleHQiID4mNjsgfQor
CitybSAtZiBjb25mdGVzdC4kYWNfZXh0CitFWEVFWFQ9JGFjX2N2X2V4ZWV4dAorYWNfZXhlZXh0
PSRFWEVFWFQKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgpCit7
CitGSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5vdXQiLCAidyIpOworIHJldHVybiBmZXJyb3Ig
KGYpIHx8IGZjbG9zZSAoZikgIT0gMDsKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCith
Y19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGNvbmZ0ZXN0Lm91dCIKKyMgQ2hlY2sgdGhh
dCB0aGUgY29tcGlsZXIgcHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2FuIHJ1bi4gIElmIG5vdCwg
ZWl0aGVyCisjIHRoZSBjb21waWxlciBpcyBicm9rZW4sIG9yIHdlIGNyb3NzIGNvbXBpbGUuCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIg
d2UgYXJlIGNyb3NzIGNvbXBpbGluZyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVy
IHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiRjcm9zc19jb21w
aWxpbmciICE9IHllczsgdGhlbgorICB7IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2UgIigoJGFj
X3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7Cisg
ICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNf
dHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0YXR1cz0k
PworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorICBpZiB7IGFjX3RyeT0nLi9jb25m
dGVzdCRhY19jdl9leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAq
XGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNf
dHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAg
KGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfTsgfTsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGluZz1ubworICBlbHNlCisg
ICAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSBtYXliZTsgdGhlbgorCWNyb3NzX2NvbXBp
bGluZz15ZXMKKyAgICBlbHNlCisJeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJv
cjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biBDIGNv
bXBpbGVkIHByb2dyYW1zLgorSWYgeW91IG1lYW50IHRvIGNyb3NzIGNvbXBpbGUsIHVzZSBcYC0t
aG9zdCcuCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsg
fQorICAgIGZpCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRjcm9zc19jb21waWxpbmciID4mNQorJGFzX2VjaG8gIiRjcm9zc19jb21w
aWxpbmciID4mNjsgfQorCitybSAtZiBjb25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4
ZWV4dCBjb25mdGVzdC5vdXQKK2FjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZm
aXggb2Ygb2JqZWN0IGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXgg
b2Ygb2JqZWN0IGZpbGVzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X29iamV4dCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorcm0gLWYg
Y29uZnRlc3QubyBjb25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgorY2Fz
ZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNf
dHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hv
PSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2Vj
aG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUKKyAg
YWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwk
PyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAg
Zm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8KKyAg
dGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRhY19maWxlIGluCisgICAg
Ki4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJi
IHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAgICAqKSBhY19jdl9vYmpl
eHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAgICBicmVhazs7CisgIGVz
YWMKK2RvbmUKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIg
PiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKK3sgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJy
b3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBjb21w
aWxlCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQor
ZmkKK3JtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb2Jq
ZXh0IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0KK09CSkVYVD0kYWNfY3Zf
b2JqZXh0CithY19vYmpleHQ9JE9CSkVYVAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGls
ZXIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdO
VSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfY29tcGlsZXJfZ251Kzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCitpbnQKK21haW4gKCkKK3sKKyNpZm5kZWYgX19HTlVDX18KKyAgICAgICBjaG9rZSBt
ZQorI2VuZGlmCisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlf
Y29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jb21waWxlcl9nbnU9eWVzCitlbHNlCisg
IGFjX2NvbXBpbGVyX2dudT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorYWNfY3ZfY19jb21waWxlcl9nbnU9JGFjX2Nv
bXBpbGVyX2dudQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Nf
Y29tcGlsZXJfZ251IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2NvbXBpbGVyX2dudSA9IHllczsgdGhl
bgorICBHQ0M9eWVzCitlbHNlCisgIEdDQz0KK2ZpCithY190ZXN0X0NGTEFHUz0ke0NGTEFHUytz
ZXR9CithY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWciID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZy4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX2NjX2crOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9JGFjX2Nfd2Vycm9yX2ZsYWcKKyAg
IGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCisgICBhY19jdl9wcm9nX2NjX2c9bm8KKyAgIENGTEFHUz0i
LWciCisgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl
bmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19nPXllcworZWxzZQorICBDRkxBR1M9IiIKKyAgICAgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2Nfd2Vycm9y
X2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZworCSBDRkxBR1M9Ii1nIgorCSBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19nPXll
cworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl
c3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgYWNfY193ZXJyb3JfZmxhZz0kYWNfc2F2
ZV9jX3dlcnJvcl9mbGFnCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQorJGFzX2VjaG8gIiRhY19jdl9wcm9n
X2NjX2ciID4mNjsgfQoraWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9IHNldDsgdGhlbgorICBD
RkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCitlbGlmIHRlc3QgJGFjX2N2X3Byb2dfY2NfZyA9IHllczsg
dGhlbgorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENGTEFHUz0iLWcgLU8yIgor
ICBlbHNlCisgICAgQ0ZMQUdTPSItZyIKKyAgZmkKK2Vsc2UKKyAgaWYgdGVzdCAiJEdDQyIgPSB5
ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1PMiIKKyAgZWxzZQorICAgIENGTEFHUz0KKyAgZmkKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
Q0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X3By
b2dfY2NfYzg5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgYWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3NhdmVfQ0M9JENDCitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzeXMv
dHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyogTW9zdCBvZiB0aGUgZm9sbG93aW5n
IHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYuc2guICAqLworc3RydWN0
IGJ1ZiB7IGludCB4OyB9OworRklMRSAqICgqcmNzb3BlbikgKHN0cnVjdCBidWYgKiwgc3RydWN0
IHN0YXQgKiwgaW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBpKQorICAgICBjaGFyICoqcDsKKyAg
ICAgaW50IGk7Cit7CisgIHJldHVybiBwW2ldOworfQorc3RhdGljIGNoYXIgKmYgKGNoYXIgKiAo
KmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQoreworICBjaGFyICpzOworICB2YV9s
aXN0IHY7CisgIHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAocCwgdmFfYXJnICh2LGludCkpOwor
ICB2YV9lbmQgKHYpOworICByZXR1cm4gczsKK30KKworLyogT1NGIDQuMCBDb21wYXEgY2MgaXMg
c29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBoYXMKKyAgIGZ1bmN0aW9u
IHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXggY2hhcmFjdGVyIGNvbnN0
YW50cy4KKyAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5mb3J0dW5hdGVseSwgaW5z
dGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gnLiAgVGhlIGZvbGxvd2luZyBpbmR1
Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAorICAgcHJvcGVyIEFOU0kg
bW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMgb3V0IHRydWUsIGZvciBh
bgorICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5IHRvIHdyaXRlICdceDAw
Jz09MCB0byBnZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1ZSBvbmx5IHdpdGggLXN0ZC4gICov
CitpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFdOworCisvKiBJQk0gQyA2
IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0IHJlcGxhY2VzIG1hY3Jv
IHBhcmFtZXRlcnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0ZXIgY29uc3RhbnRzLiAg
Ki8KKyNkZWZpbmUgRk9PKHgpICd4JworaW50IHhsYzZfY2NfYXJyYXlbRk9PKGEpID09ICd4JyA/
IDEgOiAtMV07CisKK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOworc3RydWN0IHMxIHtpbnQg
KCpmKSAoaW50IGEpO307CitzdHJ1Y3QgczIge2ludCAoKmYpIChkb3VibGUgYSk7fTsKK2ludCBw
YWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBidWYgKiwgc3RydWN0IHN0
YXQgKiwgaW50KSwgaW50LCBpbnQpOworaW50IGFyZ2M7CitjaGFyICoqYXJndjsKK2ludAorbWFp
biAoKQoreworcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0gIHx8ICBmIChlLCBhcmd2
LCAxKSAhPSBhcmd2WzFdOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitmb3IgYWNfYXJn
IGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0ZCBcCisJLUFlICItQWEg
LURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKK2RvCisgIENDPSIkYWNfc2F2
ZV9DQyAkYWNfYXJnIgorICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19hcmcKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy
ciBjb25mdGVzdC4kYWNfb2JqZXh0CisgIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4
bm8iICYmIGJyZWFrCitkb25lCitybSAtZiBjb25mdGVzdC4kYWNfZXh0CitDQz0kYWNfc2F2ZV9D
QworCitmaQorIyBBQ19DQUNIRV9WQUwKK2Nhc2UgIngkYWNfY3ZfcHJvZ19jY19jODkiIGluCisg
IHgpCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vbmUgbmVlZGVkIiA+JjUKKyRhc19lY2hvICJub25lIG5lZWRlZCIgPiY2OyB9IDs7CisgIHhu
bykKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
dW5zdXBwb3J0ZWQiID4mNQorJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+JjY7IH0gOzsKKyAgKikK
KyAgICBDQz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjUKKyRh
c19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7OworZXNhYworaWYgdGVzdCAieCRh
Y19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0aGVuIDoKKworZmkKKworYWNfZXh0PWMKK2FjX2Nw
cD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1Mg
Y29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0
ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1Jwor
YWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKK2FjX2V4dD1jCithY19j
cHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdT
IGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScK
K2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9j
ZXNzb3IiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9j
ZXNzb3IuLi4gIiA+JjY7IH0KKyMgT24gU3Vucywgc29tZXRpbWVzICRDUFAgbmFtZXMgYSBkaXJl
Y3RvcnkuCitpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIkQ1BQIjsgdGhlbgorICBDUFA9
CitmaQoraWYgdGVzdCAteiAiJENQUCI7IHRoZW4KKyAgaWYgJHthY19jdl9wcm9nX0NQUCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAj
IERvdWJsZSBxdW90ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhwYW5kZWQKKyAgICBmb3Ig
Q1BQIGluICIkQ0MgLUUiICIkQ0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIgIi9saWIvY3BwIgorICAg
IGRvCisgICAgICBhY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxh
ZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdj
Yywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIg
d29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBp
cyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5k
aW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJv
dWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5
bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
ZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFz
c2VydC5oPgorI2VuZGlmCisJCSAgICAgU3ludGF4IGVycm9yCitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgICMgQnJva2VuOiBmYWlscyBvbiB2
YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitmaQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0Lmkg
Y29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hl
Y2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2FuIGJlIGRldGVjdGVkIGFuZCBo
b3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVu
ZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlzdGVudC5oPgorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAgIyBCcm9rZW46IHN1Y2Nlc3Mg
b24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMgUGFzc2VzIGJvdGggdGVzdHMu
CithY19wcmVwcm9jX29rPToKK2JyZWFrCitmaQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuJGFjX2V4dAorCitkb25lCisjIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BS
RVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KK3JtIC1mIGNvbmZ0ZXN0
LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKK2lmICRhY19wcmVwcm9jX29rOyB0aGVu
IDoKKyAgYnJlYWsKK2ZpCisKKyAgICBkb25lCisgICAgYWNfY3ZfcHJvZ19DUFA9JENQUAorCitm
aQorICBDUFA9JGFjX2N2X3Byb2dfQ1BQCitlbHNlCisgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENQUCIg
PiY1CiskYXNfZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNf
Y19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUg
dGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJl
c2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2Vy
dC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3Rz
IGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUg
cnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVz
dCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2Uu
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNl
bHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlmCisJCSAgICAgU3ludGF4IGVycm9yCitf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgICMg
QnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitmaQorcm0gLWYgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNh
bmUgY2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2Fu
IGJlIGRldGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlz
dGVudC5oPgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
IyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMg
UGFzc2VzIGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFrCitmaQorcm0gLWYgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCitkb25lCisjIEJlY2F1c2Ug
b2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBl
ZC4KK3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKK2lmICRh
Y19wcmVwcm9jX29rOyB0aGVuIDoKKworZWxzZQorICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIk
YXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJDIHBy
ZXByb2Nlc3NvciBcIiRDUFBcIiBmYWlscyBzYW5pdHkgY2hlY2sKK1NlZSBcYGNvbmZpZy5sb2cn
IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9CitmaQorCithY19leHQ9YworYWNfY3Bw
PSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBj
b25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQg
JENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCith
Y19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMg
bG9uZyBsaW5lcyBhbmQgLWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdyZXAgdGhh
dCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhf
R1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgorICBhY19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UK
KyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBS
T0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9y
IGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
cHJvZyBpbiBncmVwIGdncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9HUkVQPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9HUkVQIiAmJiAkYXNf
dGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBjb250aW51ZQorIyBDaGVjayBmb3IgR05VIGFj
X3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZvciBH
TlUgJGFjX3BhdGhfR1JFUAorY2FzZSBgIiRhY19wYXRoX0dSRVAiIC0tdmVyc2lvbiAyPiYxYCBp
bgorKkdOVSopCisgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQ
X2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJj
b25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25m
dGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0
LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgorICAgICRhc19lY2hvICdH
UkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX0dSRVAiIC1lICdHUkVQJCcgLWUg
Jy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2
L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9k
ZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBh
Y19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9HUkVQ
X21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAg
bG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRo
X0dSRVAiCisgICAgICBhY19wYXRoX0dSRVBfbWF4PSRhY19jb3VudAorICAgIGZpCisgICAgIyAx
MCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRlc3Qg
JGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNv
bmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNhYworCisgICAgICAkYWNf
cGF0aF9HUkVQX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZT
PSRhc19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9HUkVQIjsgdGhlbgorICAg
IGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBB
VEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQorZWxzZQor
ICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1CiskYXNfZWNo
byAiJGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKKwor
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBl
Z3JlcCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcGF0aF9FR1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGlmIGVjaG8gYSB8ICRHUkVQIC1FICcoYXxiKScgPi9kZXYvbnVs
bCAyPiYxCisgICB0aGVuIGFjX2N2X3BhdGhfRUdSRVA9IiRHUkVQIC1FIgorICAgZWxzZQorICAg
ICBpZiB0ZXN0IC16ICIkRUdSRVAiOyB0aGVuCisgIGFjX3BhdGhfRUdSRVBfZm91bmQ9ZmFsc2UK
KyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBS
T0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9y
IGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4KK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
cHJvZyBpbiBlZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfRUdSRVA9IiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiCisgICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0VHUkVQIiAmJiAkYXNfdGVz
dF94ICIkYWNfcGF0aF9FR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdOVSBhY19w
YXRoX0VHUkVQIGFuZCBzZWxlY3QgaXQgaWYgaXQgaXMgZm91bmQuCisgICMgQ2hlY2sgZm9yIEdO
VSAkYWNfcGF0aF9FR1JFUAorY2FzZSBgIiRhY19wYXRoX0VHUkVQIiAtLXZlcnNpb24gMj4mMWAg
aW4KKypHTlUqKQorICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIgYWNfcGF0aF9F
R1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5
ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAi
Y29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25m
dGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNo
byAnRUdSRVAnID4+ICJjb25mdGVzdC5ubCIKKyAgICAiJGFjX3BhdGhfRUdSRVAiICdFR1JFUCQn
IDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAg
ICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJy
ZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisg
ICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9FR1JFUF9tYXgtMH07IHRoZW4KKyAg
ICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxvb2tpbmcgZm9yIGEgYmV0
dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiCisgICAgICBh
Y19wYXRoX0VHUkVQX21heD0kYWNfY291bnQKKyAgICBmaQorICAgICMgMTAqKDJeMTApIGNoYXJz
IGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0ZXN0ICRhY19jb3VudCAtZ3Qg
MTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5pbiBjb25mdGVzdC50bXAgY29u
ZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAgJGFjX3BhdGhfRUdSRVBfZm91
bmQgJiYgYnJlYWsgMworICAgIGRvbmUKKyAgZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisgIGlmIHRlc3QgLXogIiRhY19jdl9wYXRoX0VHUkVQIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9y
ICQ/ICJubyBhY2NlcHRhYmxlIGVncmVwIGNvdWxkIGJlIGZvdW5kIGluICRQQVRIJFBBVEhfU0VQ
QVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKK2Vsc2UKKyAgYWNfY3ZfcGF0
aF9FR1JFUD0kRUdSRVAKK2ZpCisKKyAgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0VHUkVQIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfcGF0aF9FR1JFUCIgPiY2OyB9CisgRUdSRVA9IiRhY19jdl9wYXRoX0VHUkVQIgor
CisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
IEFOU0kgQyBoZWFkZXIgZmlsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEFOU0kg
QyBoZWFkZXIgZmlsZXMuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVhZGVyX3N0ZGMrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8
c3RyaW5nLmg+CisjaW5jbHVkZSA8ZmxvYXQuaD4KKworaW50CittYWluICgpCit7CisKKyAgOwor
ICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3RkYz15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0
ZGM9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4K
KyAgIyBTdW5PUyA0Lnggc3RyaW5nLmggZG9lcyBub3QgZGVjbGFyZSBtZW0qLCBjb250cmFyeSB0
byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RyaW5nLmg+CisKK19BQ0VPRgoraWYg
KGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAorICAkRUdSRVAgIm1lbWNo
ciIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1u
bworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3Rk
YyA9IHllczsgdGhlbgorICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2VzIG5vdCBkZWNsYXJlIGZy
ZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRsaWIuaD4K
KworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Cisg
ICRFR1JFUCAiZnJlZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKworZWxzZQorICBhY19jdl9o
ZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQorCitpZiB0ZXN0ICRhY19j
dl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4vY2MgaW4gSXJpeC00LjAuNSBnZXRz
IG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2kuCisgIGlmIHRlc3QgIiRj
cm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgorZWxzZQorICBjYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisj
aW5jbHVkZSA8Y3R5cGUuaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpZiAoKCcgJyAmIDB4MEZG
KSA9PSAweDAyMCkKKyMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6
JykKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAnQScgKyAoKGMpIC0gJ2EnKSA6
IChjKSkKKyNlbHNlCisjIGRlZmluZSBJU0xPV0VSKGMpIFwKKwkJICAgKCgnYScgPD0gKGMpICYm
IChjKSA8PSAnaScpIFwKKwkJICAgICB8fCAoJ2onIDw9IChjKSAmJiAoYykgPD0gJ3InKSBcCisJ
CSAgICAgfHwgKCdzJyA8PSAoYykgJiYgKGMpIDw9ICd6JykpCisjIGRlZmluZSBUT1VQUEVSKGMp
IChJU0xPV0VSKGMpID8gKChjKSB8IDB4NDApIDogKGMpKQorI2VuZGlmCisKKyNkZWZpbmUgWE9S
KGUsIGYpICgoKGUpICYmICEoZikpIHx8ICghKGUpICYmIChmKSkpCitpbnQKK21haW4gKCkKK3sK
KyAgaW50IGk7CisgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKKyAgICBpZiAoWE9SIChpc2xv
d2VyIChpKSwgSVNMT1dFUiAoaSkpCisJfHwgdG91cHBlciAoaSkgIT0gVE9VUFBFUiAoaSkpCisg
ICAgICByZXR1cm4gMjsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRjPW5vCitmaQor
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorZmkKKworZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7
IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEiID4+Y29uZmRlZnMuaAor
CitmaQorCisjIE9uIElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5cGVzLmggYXJlIGNvbmZs
aWN0aW5nLgorZm9yIGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5o
IHN0cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBcCisJCSAgaW50dHlwZXMuaCBzdGRpbnQuaCB1
bmlzdGQuaAorZG8gOgorICBhc19hY19IZWFkZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFj
X2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxlICIkTElO
RU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdAor
IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgor
ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNf
aGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKKworCisgIGFj
X2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJtaW5peC9jb25maWcuaCIgImFj
X2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giID0geHllczsgdGhlbiA6CisgIE1JTklY
PXllcworZWxzZQorICBNSU5JWD0KK2ZpCisKKworICBpZiB0ZXN0ICIkTUlOSVgiID0geWVzOyB0
aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisK
KworJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+Y29uZmRlZnMuaAorCisK
KyRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZkZWZzLmgKKworICBmaQorCisKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVy
IGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkZWZpbmUgX19FWFRFTlNJT05TX18uLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18rOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKyMJICBkZWZpbmUgX19FWFRFTlNJT05TX18gMQorCSAgJGFjX2luY2x1ZGVzX2RlZmF1bHQK
K2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfc2FmZV90b19kZWZpbmVf
X19leHRlbnNpb25zX189eWVzCitlbHNlCisgIGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5z
aW9uc19fPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fIiA+JjY7IH0K
KyAgdGVzdCAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18gPSB5ZXMgJiYKKyAg
ICAkYXNfZWNobyAiI2RlZmluZSBfX0VYVEVOU0lPTlNfXyAxIiA+PmNvbmZkZWZzLmgKKworICAk
YXNfZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKKworICAkYXNfZWNo
byAiI2RlZmluZSBfR05VX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKKworICAkYXNfZWNobyAiI2Rl
ZmluZSBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFzX2Vj
aG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKworIyBNYWtlIHN1
cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgorJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuc3Vi
IiBzdW40ID4vZGV2L251bGwgMj4mMSB8fAorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IHJ1biAk
U0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgIiRMSU5FTk8iIDUKKworeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZSIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZS4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9idWlsZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGFjX2J1aWxkX2FsaWFzPSRidWlsZF9hbGlhcwordGVzdCAieCRhY19i
dWlsZF9hbGlhcyIgPSB4ICYmCisgIGFjX2J1aWxkX2FsaWFzPWAkU0hFTEwgIiRhY19hdXhfZGly
L2NvbmZpZy5ndWVzcyJgCit0ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9IHggJiYKKyAgYXNfZm5f
ZXJyb3IgJD8gImNhbm5vdCBndWVzcyBidWlsZCB0eXBlOyB5b3UgbXVzdCBzcGVjaWZ5IG9uZSIg
IiRMSU5FTk8iIDUKK2FjX2N2X2J1aWxkPWAkU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIi
ICRhY19idWlsZF9hbGlhc2AgfHwKKyAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rp
ci9jb25maWcuc3ViICRhY19idWlsZF9hbGlhcyBmYWlsZWQiICIkTElORU5PIiA1CisKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2J1
aWxkIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfYnVpbGQiID4mNjsgfQorY2FzZSAkYWNfY3ZfYnVp
bGQgaW4KKyotKi0qKSA7OworKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fu
b25pY2FsIGJ1aWxkIiAiJExJTkVOTyIgNTs7Citlc2FjCitidWlsZD0kYWNfY3ZfYnVpbGQKK2Fj
X3NhdmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4ICRhY19jdl9idWlsZAorc2hpZnQKK2J1aWxk
X2NwdT0kMQorYnVpbGRfdmVuZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBm
aXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAorIyBleGNlcHQgd2l0
aCBvbGQgc2hlbGxzOgorYnVpbGRfb3M9JCoKK0lGUz0kYWNfc2F2ZV9JRlMKK2Nhc2UgJGJ1aWxk
X29zIGluICpcICopIGJ1aWxkX29zPWBlY2hvICIkYnVpbGRfb3MiIHwgc2VkICdzLyAvLS9nJ2A7
OyBlc2FjCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBob3N0IHN5c3RlbSB0eXBlIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvc3Qgc3lz
dGVtIHR5cGUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaG9zdCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIngkaG9zdF9hbGlh
cyIgPSB4OyB0aGVuCisgIGFjX2N2X2hvc3Q9JGFjX2N2X2J1aWxkCitlbHNlCisgIGFjX2N2X2hv
c3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhvc3RfYWxpYXNgIHx8CisgICAg
YXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViICRob3N0X2FsaWFz
IGZhaWxlZCIgIiRMSU5FTk8iIDUKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hvc3QiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9ob3N0IiA+JjY7IH0KK2Nhc2UgJGFjX2N2X2hvc3QgaW4KKyotKi0qKSA7OworKikgYXNfZm5f
ZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGhvc3QiICIkTElORU5PIiA1OzsK
K2VzYWMKK2hvc3Q9JGFjX2N2X2hvc3QKK2FjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4
ICRhY19jdl9ob3N0CitzaGlmdAoraG9zdF9jcHU9JDEKK2hvc3RfdmVuZG9yPSQyCitzaGlmdDsg
c2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8g
Y3JlYXRlICQqLAorIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgoraG9zdF9vcz0kKgorSUZTPSRh
Y19zYXZlX0lGUworY2FzZSAkaG9zdF9vcyBpbiAqXCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9v
cyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKworCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKKwor
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisK
KworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhzbSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV94c20rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV94c207
CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieHllcyI7IHRoZW4gOgorCisgICAg
YXhfY3ZfeHNtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieG5vIjsgdGhlbiA6
CisKKyAgICBheF9jdl94c209Im4iCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfeHNtOyB0aGVuIDoK
KworICAgIGF4X2N2X3hzbT0ibiIKKworZmkKK3hzbT0kYXhfY3ZfeHNtCisKKyMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2dpdGh0
dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9naXRodHRwOworZmkK
KworCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBh
eF9jdl9naXRodHRwPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0gInhubyI7
IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9n
aXRodHRwOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9Im4iCisKK2ZpCitnaXRodHRwPSRh
eF9jdl9naXRodHRwCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVu
YWJsZXZhbD0kZW5hYmxlX21vbml0b3JzOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9tb25p
dG9ycyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ibiIKKworZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbW9u
aXRvcnM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4gOgorCisgICAg
YXhfY3ZfbW9uaXRvcnM9InkiCisKK2ZpCittb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKKworIyBD
aGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVf
dnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07CitmaQor
CisKK2lmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2
X3Z0cG09InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieG5vIjsgdGhlbiA6CisK
KyAgICBheF9jdl92dHBtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgor
CisgICAgYXhfY3ZfdnRwbT0ibiIKKworZmkKK3Z0cG09JGF4X2N2X3Z0cG0KKworIyBDaGVjayB3
aGV0aGVyIC0tZW5hYmxlLXhhcGkgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfeGFwaStz
ZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hhcGk7CitmaQorCisKK2lm
IHRlc3QgIngkZW5hYmxlX3hhcGkiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X3hhcGk9
InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBh
eF9jdl94YXBpPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hhcGk7IHRoZW4gOgorCisgICAg
YXhfY3ZfeGFwaT0ibiIKKworZmkKK3hhcGk9JGF4X2N2X3hhcGkKKworIyBDaGVjayB3aGV0aGVy
IC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3B5dGhv
bnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcHl0aG9udG9v
bHM7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVu
IDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3B5
dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9weXRob250b29scz0ieSIK
KworZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250b29sczsgdGhlbiA6CisKKyAgICBheF9jdl9w
eXRob250b29scz0ieSIKKworZmkKK3B5dGhvbnRvb2xzPSRheF9jdl9weXRob250b29scworCisj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfb2NhbWx0b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngk
ZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9v
bHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6CisKKyAgICBh
eF9jdl9vY2FtbHRvb2xzPSJ5IgorCitmaQorb2NhbWx0b29scz0kYXhfY3Zfb2NhbWx0b29scwor
CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgoraWYgdGVzdCAi
JHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJs
ZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMi
OyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxl
X21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJuIgorCitl
bGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJt
PSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKyMgQ2hlY2sgd2hldGhlciAt
LWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OworZmkKKworCitp
ZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9s
b21vdW50PSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInhubyI7IHRoZW4g
OgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9sb21vdW50
OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9Im4iCisKK2ZpCitsb21vdW50PSRheF9jdl9s
b21vdW50CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9kZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX2RlYnVnOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhl
biA6CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIg
PSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAk
YXhfY3ZfZGVidWc7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2ZpCitkZWJ1Zz0k
YXhfY3ZfZGVidWcKKworCisKKworCisKKworZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVT
CitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2Rv
bmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1Mr
PSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQ
UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdT
ICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZM
QUdTICRBUFBFTkRfTERGTEFHUyIKKworCisKKworCisKKworCisKKworCisKKyMgQ2hlY2tzIGZv
ciBwcm9ncmFtcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0cHV0IiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1NFRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAgICAgICBhY19zY3JpcHQ9cy9hYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi
YmJiYmJiYmIvCisgICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7IGRvCisgICAgICAgYWNf
c2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKKyAgICAgZG9uZQorICAgICBlY2hv
ICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0ZXN0LnNlZAorICAgICB7
IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9CisgICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0
aGVuCisgIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2Vy
J3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfU0VEPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9TRUQiICYmICRhc190
ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdOVSBhY19w
YXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUg
JGFjX3BhdGhfU0VECitjYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNpb24gMj4mMWAgaW4KKypH
TlUqKQorICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19wYXRoX1NFRF9mb3VuZD06
OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3Qu
aW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4i
ID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKKyAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNobyAnJyA+PiAiY29u
ZnRlc3QubmwiCisgICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Quc2VkIDwgImNvbmZ0ZXN0
Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25m
dGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAk
YWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCisgICAgICAjIEJlc3Qgb25l
IHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUKKyAgICAg
IGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCisgICAgICBhY19wYXRoX1NFRF9tYXg9JGFj
X2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3Jl
IHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCisgIGRvbmUK
KyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91
dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9u
ZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2
X3BhdGhfU0VEIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIHNlZCBj
b3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2
X3BhdGhfU0VEPSRTRUQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
cGF0aF9TRUQiID4mNjsgfQorIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgorICBybSAtZiBjb25mdGVz
dC5zZWQKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSck
Q0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSck
Q0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0
ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVy
X2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNf
d29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFj
X2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNl
Cithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRh
c19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisK
KworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MK
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7
Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNlCisgIENDPSIkYWNfY3ZfcHJvZ19D
QyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgICAgICAgICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9v
bF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3By
b2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgZmkKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGNjOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKKyAg
YWNfcHJvZ19yZWplY3RlZD1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAi
L3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAgICAgICBj
b250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91
bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAg
c2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhl
bgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25l
LgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24g
d2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNl
bmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2df
Q0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQorZmkKK2ZpCitmaQorQ0M9JGFj
X2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
Zm9yIGFjX3Byb2cgaW4gY2wuZXhlCisgIGRvCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9w
cm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19DQz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNf
ZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
KyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitpZiB0ZXN0IC16ICIkQ0Mi
OyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKK2RvCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRlc3QgLW4gIiRhY19jdF9D
QyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAg
ICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0ZXN0IC16ICIkQ0MiICYm
IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9
CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVy
IHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNf
b3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRh
Y19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8
ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRh
Y190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQor
ICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAg
YWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcx
MGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEn
IGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAg
ZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19jb21waWxlcl9nbnUrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKK2ludAorbWFpbiAoKQoreworI2lmbmRlZiBfX0dOVUNfXworICAgICAgIGNob2tlIG1lCisj
ZW5kaWYKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2NvbXBpbGVyX2dudT15ZXMKK2Vsc2UKKyAgYWNf
Y29tcGlsZXJfZ251PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGls
ZXJfZ251CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19jb21w
aWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCisg
IEdDQz15ZXMKK2Vsc2UKKyAgR0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0K
K2FjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3Byb2dfY2NfZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNf
Y193ZXJyb3JfZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIK
KyAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9wcm9nX2NjX2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitp
bnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9j
X3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY193ZXJyb3JfZmxh
Zz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
aW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nf
d2Vycm9yX2ZsYWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2Nf
ZyIgPiY2OyB9CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCisgIENGTEFH
Uz0kYWNfc2F2ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVu
CisgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItZyAtTzIiCisgIGVs
c2UKKyAgICBDRkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsg
dGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPQorICBmaQorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBv
cHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19j
Y19jODkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
bmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBl
cy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVz
dHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVm
IHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3Rh
dCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBp
bnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykg
KGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3Qg
djsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZh
X2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21l
IHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJv
dG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRz
LgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFk
IGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMg
YW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2Rl
LiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisg
ICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0w
IHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2lu
dCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisKKy8qIElCTSBDIDYgZm9y
IEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFy
YW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwor
I2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6
IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYp
IChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJu
YW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAq
LCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2OworaW50CittYWluICgp
Cit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4g
JycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9I
UFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAgQ0M9IiRhY19zYXZlX0ND
ICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIg
JiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0NDPSRhY19zYXZlX0NDCisK
K2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KKyAgeCkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9u
ZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKKyAgeG5vKQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1
cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OworICAqKQorICAg
IENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitpZiB0ZXN0ICJ4JGFjX2N2
X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9CitMTl9T
PSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8g
InllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2VjaG8gIm5vLCB1c2luZyAk
TE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAi
ID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2Vk
ICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgXCR7YWNfY3ZfcHJvZ19t
YWtlXyR7YWNfbWFrZX1fc2V0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAv
YmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUlJScKK19BQ0VPRgorIyBH
TlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3
b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4v
ZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUlKikKKyAgICBldmFsIGFjX2N2X3Byb2df
bWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQorICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtl
XyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1mIGNvbmZ0ZXN0Lm1ha2UKK2ZpCitpZiBl
dmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1
CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CitlbHNlCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAi
bm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCitmaQorCisjIEZpbmQg
YSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJvZ3JhbSAoZmFzdGVyKSwK
KyMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBCdXQgYXZvaWQgdGhlIGJy
b2tlbiBvcgorIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6CisjIFN5c1YgL2V0Yy9pbnN0YWxsLCAv
dXNyL3NiaW4vaW5zdGFsbAorIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxsCisjIElSSVggL3NiaW4v
aW5zdGFsbAorIyBBSVggL2Jpbi9pbnN0YWxsCisjIEFtaWdhT1MgL0MvaW5zdGFsbCwgd2hpY2gg
aW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKKyMgQUlYIDQgL3Vzci9iaW4vaW5z
dGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBmbGFnCisjIEFGUyAvdXNy
L2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4aXN0ZW50IGFyZ3MKKyMg
U1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2UgdGhlIG5vbmV4aXN0ZW50
IGdyb3VwICJzdGFmZiIKKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21w
bGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYworIyAuL2luc3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJv
bmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2guCisjIFJlamVjdCBpbnN0
YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUgZmlsZXMuCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21w
YXRpYmxlIGluc3RhbGwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGEgQlNELWNvbXBh
dGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQoraWYgdGVzdCAteiAiJElOU1RBTEwiOyB0aGVuCitp
ZiAke2FjX2N2X3BhdGhfaW5zdGFsbCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0
IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KK2Nhc2UgJGFzX2Rpci8gaW4gIygo
CisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNy
L2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCisgID86W1xcL11vczJbXFwv
XWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11JTlNUQUxMW1xcL10qIHwgXAorICAvdXNy
L3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIg
b3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9uJ3QgdXNlIGluc3RhbGxic2QgZnJvbSBP
U0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9vdAorICAgICMgYnkgZGVmYXVsdC4KKyAg
ICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0IGluc3RhbGw7IGRvCisgICAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKwlpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVuCisJICBpZiB0ZXN0ICRhY19wcm9nID0g
aW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4
dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4g
aW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KKwkgICAgOgorCSAgZWxpZiB0ZXN0ICRh
Y19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgcHJvZ3JhbS1zcGVjaWZp
YyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgorCSAgICA6CisJ
ICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRp
cgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQorCSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0
LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkgICAgaWYgIiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0
LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0
LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAmJgorCSAg
ICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0LnR3bworCSAgICB0aGVuCisJICAgICAg
YWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgorCSAg
ICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkKKyAgICAgIGRvbmUKKyAgICBkb25lCisg
ICAgOzsKK2VzYWMKKworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK3JtIC1yZiBjb25mdGVz
dC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCitmaQorICBpZiB0ZXN0ICIke2FjX2N2
X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgorICAgIElOU1RBTEw9JGFjX2N2X3BhdGhf
aW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hl
bGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMgdmFsdWUgZm9yIElOU1RBTEwgd2l0aGlu
IGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKKyAgICAjIGJyZWFrIG90aGVy
IHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0IGRpcmVjdG9yeSBpcworICAgICMgcmVt
b3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUgbmFtZS4KKyAgICBJTlNUQUxMPSRh
Y19pbnN0YWxsX3NoCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIkSU5TVEFMTCIgPiY2OyB9
CisKKyMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFuZGxlcyBicmFjZXMgaW4g
JHt2YXItdmFsfS4KKyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBicmFjZSBlbmRzIHRoZSB2
YXJpYWJsZSBzdWJzdGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNU
QUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX1NDUklQVCIgJiYg
SU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX0RBVEEiICYm
IElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfUEVSTCs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFBF
UkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfUEVSTD0iJFBFUkwiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQor
ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitQRVJMPSRhY19jdl9wYXRoX1BFUkwKK2lmIHRlc3QgLW4g
IiRQRVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke1BFUkx9IiA9PSB4Im5vIgor
dGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBwZXJsLCBwbGVhc2UgaW5z
dGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
YnJjdGwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
IGJyY3RsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9CUkNUTCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJSQ1RMIGlu
CisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JSQ1RMPSIkQlJDVEwiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBh
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRI
CitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9w
YXRoX0JSQ1RMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JSQ1RMIiAmJiBhY19jdl9wYXRoX0JSQ1RM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCUkNUTD0kYWNfY3ZfcGF0aF9CUkNUTAoraWYgdGVzdCAt
biAiJEJSQ1RMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJEJSQ1RMIiA+JjUKKyRhc19lY2hvICIkQlJDVEwiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7QlJDVEx9IiA9PSB4
Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBicmN0bCwgcGxl
YXNlIGluc3RhbGwgYnJjdGwiICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJpcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgaXA7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0lQKzp9IGZhbHNlOyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkSVAgaW4KKyAg
W1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSVA9IiRJUCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfSVA9IiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfSVAiICYmIGFjX2N2X3BhdGhfSVA9Im5vIgorICA7OworZXNhYwor
ZmkKK0lQPSRhY19jdl9wYXRoX0lQCitpZiB0ZXN0IC1uICIkSVAiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSVAiID4mNQorJGFzX2Vj
aG8gIiRJUCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitp
ZiB0ZXN0IHgiJHtJUH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGlwLCBwbGVhc2UgaW5zdGFsbCBpcCIgIiRMSU5FTk8iIDUKK2ZpCisjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Bh
dGhfQklTT04rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0
aF9CSVNPTj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg
cGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CSVNP
TiIgJiYgYWNfY3ZfcGF0aF9CSVNPTj0ibm8iCisgIDs7Citlc2FjCitmaQorQklTT049JGFjX2N2
X3BhdGhfQklTT04KK2lmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1CiskYXNfZWNobyAi
JEJJU09OIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lm
IHRlc3QgeCIke0JJU09OfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5h
YmxlIHRvIGZpbmQgYmlzb24sIHBsZWFzZSBpbnN0YWxsIGJpc29uIiAiJExJTkVOTyIgNQorZmkK
KyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgZmxleDsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfRkxFWCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJEZMRVggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2
X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfRkxF
WCIgJiYgYWNfY3ZfcGF0aF9GTEVYPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitGTEVYPSRhY19jdl9w
YXRoX0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQorJGFzX2VjaG8gIiRGTEVY
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3Qg
eCIke0ZMRVh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8g
ZmluZCBmbGV4LCBwbGVhc2UgaW5zdGFsbCBmbGV4IiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3Qg
IngkeGFwaSIgPSAieHkiOyB0aGVuIDoKKworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9DVVJM
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9DVVJMPSIk
Q1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7
CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9w
YXRoX0NVUkw9Im5vIgorICA7OworZXNhYworZmkKK0NVUkw9JGFjX2N2X3BhdGhfQ1VSTAoraWYg
dGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENVUkwiID4mNjsgfQorZWxz
ZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7Q1VSTH0iID09
IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29u
ZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9wYXRoX1hNTCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhNTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitYTUw9JGFjX2N2
X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1CiskYXNfZWNobyAiJFhNTCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElORU5PIiA1Citm
aQorCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRoZW4gOgorCisgICAgICAj
IGNoZWNraW5nIGZvciBvY2FtbGMKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxj
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfT0NBTUxD
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiRPQ0FNTEMi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09D
QU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+
JjUKKyRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEMiOyB0aGVuCisg
IGFjX2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2Nh
bWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBv
Y2FtbGM7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQys6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSIkYWNf
Y3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxDPSJvY2FtbGMiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNf
Y3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEMiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTEMiID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMK
KyAgZmkKK2Vsc2UKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMiCitmaQorCisKKyAgaWYg
dGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZFUlNJT049YCRPQ0FNTEMg
LXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKKyAgICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZlcnNpb24g
aXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxW
RVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAorICAgICBp
ZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMg
LXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRg
CisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY1
CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7
IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQorJGFzX2VjaG8g
Ik9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQorCisKKworCisgICAgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJv
Z19PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FN
TE9QVD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKK2lmIHRlc3Qg
LW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1MT1BU
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN
TE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BU
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFQ9Im9jYW1sb3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09D
QU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4
JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0ibm8iCisgIGVsc2UKKyAg
ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxPUFQ9JGFj
X2N0X09DQU1MT1BUCisgIGZpCitlbHNlCisgIE9DQU1MT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9Q
VCIKK2ZpCisKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9
ICJubyI7IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdB
Uk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0
ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAk
T0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJ
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZl
cnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsgfQor
CSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZp
CisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgaWYgdGVzdCAtbiAi
JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0OyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9U
T1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0i
JHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRP
Q0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDRE9UT1BU
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MQ0RP
VE9QVD0kT0NBTUxDRE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxj
Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWxjLm9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9U
T1BUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5v
cHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NBTUxDRE9UT1BUPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RP
VE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTENE
T1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgorICAgIE9DQU1MQ0RPVE9QVD0i
bm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisg
ICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKKyAgZmkKK2Vsc2UKKyAgT0NBTUxD
RE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCitmaQorCisgICAgIGlmIHRlc3QgIiRP
Q0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12
IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRU
TVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9CisJZWxzZQor
CSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRo
ZW4KKwlpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE9Q
VERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQu
b3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MT1BURE9UT1BUPSRhY19j
dl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NB
TUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BURE9UT1BUPSRPQ0FN
TE9QVERPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Lm9wdCIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxv
cHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9Im9j
YW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE9Q
VERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPSB4OyB0aGVu
CisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xf
d2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERP
VE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQiCitmaQorCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJ
ICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1M
VkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0
IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgIGVsc2UKKwkgICAgICBPQ0FNTE9Q
VD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAgICBmaQorCisKKyAgZmkK
KworCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgaWYgdGVzdCAtbiAiJGFj
X3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MIjsgdGhl
bgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAt
biAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MPSIkYWNfY3Rf
T0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTD0ib2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NB
TUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KK2Vsc2UKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
KyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUwiID0g
eDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGlu
ZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dh
cm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwKKyAgZmkKK2Vsc2UKKyAg
T0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgorZmkKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
ZGVwCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9j
YW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERFUCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4g
IiRPQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxkZXAiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NB
TUxERVA9JGFjX2N2X3Byb2dfT0NBTUxERVAKK2lmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERFUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERF
UCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCisgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MREVQCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxE
RVAiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7
IHRoZW4KKyAgICBPQ0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxp
bmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93
YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCisgIGZpCitl
bHNlCisgIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKK2ZpCisKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0
b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2df
T0NBTUxNS1RPUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxN
S1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNo
byAiJE9DQU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2Zp
CisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCisgIGFj
X2N0X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJvY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE1LVE9QKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0X09DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9w
IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAg
ZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MTUtUT1A9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MTUtUT1AiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJubyIKKyAgZWxzZQorICAg
IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv
b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LVE9QPSRh
Y19jdF9PQ0FNTE1LVE9QCisgIGZpCitlbHNlCisgIE9DQU1MTUtUT1A9IiRhY19jdl9wcm9nX09D
QU1MTUtUT1AiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta2xpYgorICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWI7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MTUtMSUIrOn0gZmFsc2U7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxN
S0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVf
SUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitP
Q0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRPQ0FNTE1LTElC
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxta2xpYjsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQis6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9P
Q0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
KyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkK
K2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2Vj
aG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS0xJQiIgPSB4OyB0aGVuCisgICAg
T0NBTUxNS0xJQj0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rv
b2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVz
IDs7Citlc2FjCisgICAgT0NBTUxNS0xJQj0kYWNfY3RfT0NBTUxNS0xJQgorICBmaQorZWxzZQor
ICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIgorZmkKKworCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv
b2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERP
Qys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJE9D
QU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NB
TUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
K2ZpCitmaQorT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lmIHRlc3QgLW4gIiRPQ0FN
TERPQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRPQ0FNTERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxET0M9JE9DQU1MRE9DCisgICMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRo
ZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09DQU1MRE9DIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9j
YW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MRE9DPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERPQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09D
QU1MRE9DIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERPQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxET0M9JGFjX2N0X09DQU1M
RE9DCisgIGZpCitlbHNlCisgIE9DQU1MRE9DPSIkYWNfY3ZfcHJvZ19PQ0FNTERPQyIKK2ZpCisK
KworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X3Byb2dfT0NBTUxCVUlMRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgorICBh
Y19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1vY2Ft
bGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MQlVJTEQ9JGFjX2N2
X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIg
PiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQlVJTEQi
OyB0aGVuCisgIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKKyAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTEJVSUxEKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVu
CisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09DQU1MQlVJTEQiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxE
PSJvY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1M
QlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1M
QlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEJVSUxEPSJubyIK
KyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3ll
czopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBP
Q0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisgIE9DQU1MQlVJTEQ9IiRh
Y19jdl9wcm9nX09DQU1MQlVJTEQiCitmaQorCisKKyAgICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICAgICAgaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eHllcyI7IHRoZW4gOgorCisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMg
ZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVOTyIgNQorZmkKKyAgICAg
ICAgb2NhbWx0b29scz0ibiIKKworZmkKKworZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgYmFzaDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfQkFTSCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJBU0ggaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkFTSD0iJEJBU0giICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRo
X0JBU0g9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkFTSCIgJiYgYWNfY3ZfcGF0aF9CQVNIPSJubyIK
KyAgOzsKK2VzYWMKK2ZpCitCQVNIPSRhY19jdl9wYXRoX0JBU0gKK2lmIHRlc3QgLW4gIiRCQVNI
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJEJBU0giID4mNQorJGFzX2VjaG8gIiRCQVNIIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JBU0h9IiA9PSB4Im5vIgordGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBwbGVhc2UgaW5zdGFsbCBi
YXNoIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhl
biA6CisKKyAgICBpZiBlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CisKKyAg
ICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhP
TlBBVEhgCisKK2VsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgorICBQWVRIT049InB5dGhv
biIKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3Qg
YW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9QWVRI
T05QQVRIKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUFlUSE9OUEFUSD0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgor
ICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAoraWYgdGVz
dCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVz
dCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1
CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBv
cnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAoraWYgdGVz
dCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFg
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgICAgYXNfZm5fZXJyb3IgJD8gIiRweXRob25f
dmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgMi4zIiAiJExJ
TkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorICAgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB4
bWwuZG9tLm1pbmlkb20iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB4bWwu
ZG9tLm1pbmlkb20uLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5p
ZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1v
ZHVsZSIgIiRMSU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBweXRob24gZGV2ZWwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiBkZXZl
bC4uLiAiID4mNjsgfQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3MucGF0aCwgc3lzCitmb3Ig
cCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZp
bGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisnID4gL2Rldi9udWxsIDI+
JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiUHl0aG9uIGRldmVsIHBhY2thZ2Ugbm90IGZvdW5kIiAi
JExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorCitmaQor
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9wYXRoX1hHRVRURVhUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkWEdFVFRFWFQgaW4KKyAgW1xcL10qIHwgPzpb
XFwvXSopCisgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfWEdFVFRF
WFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9
Im5vIgorICA7OworZXNhYworZmkKK1hHRVRURVhUPSRhY19jdl9wYXRoX1hHRVRURVhUCitpZiB0
ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQorJGFzX2VjaG8gIiRYR0VUVEVYVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYR0VUVEVYVH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIgIiRMSU5FTk8iIDUKK2Zp
CitpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmFkbSIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgdWRldmFkbTsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3BhdGhfVURFVkFETSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJFVERVZBRE0gaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFj
X2N2X3BhdGhfVURFVkFETT0iJFVERVZBRE0iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZBRE09IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFj
X2N2X3BhdGhfVURFVkFETSIgJiYgYWNfY3ZfcGF0aF9VREVWQURNPSJubyIKKyAgOzsKK2VzYWMK
K2ZpCitVREVWQURNPSRhY19jdl9wYXRoX1VERVZBRE0KK2lmIHRlc3QgLW4gIiRVREVWQURNIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFVERVZBRE0iID4mNQorJGFzX2VjaG8gIiRVREVWQURNIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19l
Y2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJu
byIKKyAgICB0aGVuCisgICAgICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmlu
Zm8iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHVk
ZXZpbmZvOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9VREVWSU5GTys6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFVERVZJ
TkZPIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1VERVZJTkZPPSIkVURF
VklORk8iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7
OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNf
ZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
KyAgICBhY19jdl9wYXRoX1VERVZJTkZPPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1VERVZJTkZPIiAm
JiBhY19jdl9wYXRoX1VERVZJTkZPPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitVREVWSU5GTz0kYWNf
Y3ZfcGF0aF9VREVWSU5GTworaWYgdGVzdCAtbiAiJFVERVZJTkZPIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFVERVZJTkZPIiA+JjUK
KyRhc19lY2hvICIkVURFVklORk8iID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30iID09IHgibm8iCisgICAg
ICAgIHRoZW4KKyAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB1ZGV2
YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2IiAiJExJTkVOTyIgNQorICAgICAg
ICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0n
YAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAg
dGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImhvdHBsdWciLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGhvdHBsdWc7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0hPVFBMVUcrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRIT1RQTFVHIGluCisgIFtc
XC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0hPVFBMVUc9IiRIT1RQTFVHIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9IT1RQTFVHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0hPVFBMVUciICYmIGFjX2N2X3BhdGhfSE9U
UExVRz0ibm8iCisgIDs7Citlc2FjCitmaQorSE9UUExVRz0kYWNfY3ZfcGF0aF9IT1RQTFVHCitp
ZiB0ZXN0IC1uICIkSE9UUExVRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRIT1RQTFVHIiA+JjUKKyRhc19lY2hvICIkSE9UUExVRyIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgICAgIGlm
IHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBh
c19mbl9lcnJvciAkPyAidWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3Ig
bGF0ZXIiICIkTElORU5PIiA1CisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgInZuY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB2bmNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfVk5DT05GSUcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBjYXNlICRWTkNPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJFZOQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9WTkNPTkZJRyIgJiYgYWNfY3ZfcGF0aF9WTkNPTkZJRz0ibm8iCisg
IDs7Citlc2FjCitmaQorVk5DT05GSUc9JGFjX2N2X3BhdGhfVk5DT05GSUcKK2lmIHRlc3QgLW4g
IiRWTkNPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRWTkNPTkZJRyIgPiY1CiskYXNfZWNobyAiJFZOQ09ORklHIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtW
TkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBhc19mbl9lcnJvciAkPyAiTm90
IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmQiICIkTElORU5PIiA1CisgICAg
ZmkKK2ZpCisKK2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0aGVuCisgICAg
YWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1aWQvdXVpZC5oIiAiYWNf
Y3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4
JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorICBhc19m
bl9lcnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJTkVOTyIgNQorZmkKKwor
CitlbHNlCisgICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1aWQu
aCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3Qg
IngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorICBhc19mbl9l
cnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJTkVOTyIgNQorZmkKKworCitm
aQorCisKKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitpZiB0ZXN0IC1kICIkcHJlZml4L2xpYjY0Ijsg
dGhlbiA6CisKKyAgICBMSUJfUEFUSD0ibGliNjQiCisKK2Vsc2UKKworICAgIExJQl9QQVRIPSJs
aWIiCisKK2ZpCisKKworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpby4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9saWJfYWlvX2lvX3NldHVwKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UworTElCUz0iLWxhaW8gICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0ND
IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1
c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBh
bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNp
ZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGlvX3NldHVwICgpOwor
aW50CittYWluICgpCit7CityZXR1cm4gaW9fc2V0dXAgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zf
bGliX2Fpb19pb19zZXR1cD15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD1ubwor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2
ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2Fp
b19pb19zZXR1cCIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID0g
eHllczsgdGhlbiA6CisgIHN5c3RlbV9haW89InkiCitlbHNlCisgIHN5c3RlbV9haW89Im4iCitm
aQorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yIE1ENSBpbiAtbGNyeXB0byIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGlu
IC1sY3J5cHRvLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9jcnlwdG9fTUQ1Kzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxjcnlwdG8gICRMSUJTIgorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv
ci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlm
CitjaGFyIE1ENSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIE1ENSAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9saWJfY3J5cHRvX01ENT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2NyeXB0b19N
RDU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK
KyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tf
bGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9s
aWJfY3J5cHRvX01ENSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA9
IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
TElCQ1JZUFRPIDEKK19BQ0VPRgorCisgIExJQlM9Ii1sY3J5cHRvICRMSUJTIgorCitlbHNlCisg
IGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJjcnlwdG8iICIkTElORU5PIiA1Citm
aQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfZXh0
MmZzX2V4dDJmc19vcGVuMis6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sZXh0
MmZzICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1
c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBleHQyZnNfb3BlbjIgKCk7CitpbnQKK21h
aW4gKCkKK3sKK3JldHVybiBleHQyZnNfb3BlbjIgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9Citf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGli
X2V4dDJmc19leHQyZnNfb3BlbjI9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZz
X29wZW4yPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4mNjsgfQoraWYgdGVzdCAieCRh
Y19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPSB4eWVzOyB0aGVuIDoKKyAgbGliZXh0MmZz
PSJ5IgorZWxzZQorICBsaWJleHQyZnM9Im4iCitmaQorCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4g
LWxnY3J5cHQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZm
ZXIgaW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2djcnlwdF9nY3J5X21k
X2hhc2hfYnVmZmVyKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxnY3J5cHQg
ICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3Rv
dHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1h
dGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJn
dW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1
cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CitpbnQK
K21haW4gKCkKK3sKK3JldHVybiBnY3J5X21kX2hhc2hfYnVmZmVyICgpOworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj15ZXMKK2Vsc2UKKyAgYWNfY3Zf
bGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0
ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9nY3J5cHRf
Z2NyeV9tZF9oYXNoX2J1ZmZlciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlciIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlciIgPSB4eWVzOyB0aGVuIDoKKyAgbGliZ2NyeXB0PSJ5IgorZWxzZQor
ICBsaWJnY3J5cHQ9Im4iCitmaQorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHB0aHJlYWRfY3JlYXRlIGluIC1scHRocmVhZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgcHRocmVhZF9jcmVhdGUgaW4gLWxwdGhyZWFkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlKzp9IGZhbHNlOyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGli
X3NhdmVfTElCUz0kTElCUworTElCUz0iLWxwdGhyZWFkICAkTElCUyIKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciBwdGhyZWFkX2NyZWF0ZSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHB0aHJlYWRf
Y3JlYXRlICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRl
PXllcworZWxzZQorICBhY19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZT1ubworZmkKK3Jt
IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xp
Yl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3B0
aHJlYWRfcHRocmVhZF9jcmVhdGUiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKyAgYXNfZm5fZXJy
b3IgJD8gIkNvdWxkIG5vdCBmaW5kIGxpYnB0aHJlYWQiICIkTElORU5PIiA1CitmaQorCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbG9ja19n
ZXR0aW1lIGluIC1scnQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsb2NrX2dldHRp
bWUgaW4gLWxydC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSs6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFj
X2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1scnQgICRMSUJTIgorY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl
cnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw
ZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2Vu
ZGlmCitjaGFyIGNsb2NrX2dldHRpbWUgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBjbG9j
a19nZXR0aW1lICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lPXll
cworZWxzZQorICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZT1ubworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJf
cnRfY2xvY2tfZ2V0dGltZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0
aW1lIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWUiID0geHll
czsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJS
VCAxCitfQUNFT0YKKworICBMSUJTPSItbHJ0ICRMSUJTIgorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1s
dXVpZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgdXVpZF9jbGVhciBpbiAtbHV1aWQu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcis6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9z
YXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sdXVpZCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8
X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92
ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAg
VXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0ND
CisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg
YXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIg
dXVpZF9jbGVhciAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHV1aWRfY2xlYXIgKCk7Cisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i
OyB0aGVuIDoKKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3Zf
bGliX3V1aWRfdXVpZF9jbGVhcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0
CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+
JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPiY2OyB9CitpZiB0ZXN0
ICJ4JGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJVVUlEIDEKK19BQ0VPRgorCisgIExJ
QlM9Ii1sdXVpZCAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZp
bmQgbGlidXVpZCIgIiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciB5YWpsX2FsbG9jIGluIC1seWFqbC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9saWJfeWFqbF95YWpsX2FsbG9jKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElC
UworTElCUz0iLWx5YWpsICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdD
QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNh
dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4g
YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisj
aWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciB5YWpsX2FsbG9jICgp
OworaW50CittYWluICgpCit7CityZXR1cm4geWFqbF9hbGxvYyAoKTsKKyAgOworICByZXR1cm4g
MDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcworZWxzZQorICBhY19jdl9saWJfeWFqbF95YWps
X2FsbG9jPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQorJGFzX2VjaG8g
IiRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGli
X3lhamxfeWFqbF9hbGxvYyIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2RlZmluZSBIQVZFX0xJQllBSkwgMQorX0FDRU9GCisKKyAgTElCUz0iLWx5YWpsICRM
SUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCB5YWpsIiAiJExJ
TkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBkZWZsYXRlQ29weSBpbiAtbHouLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3pfZGVm
bGF0ZUNvcHkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHogICRMSUJTIgor
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBh
dm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSBy
ZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJv
dG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJu
ICJDIgorI2VuZGlmCitjaGFyIGRlZmxhdGVDb3B5ICgpOworaW50CittYWluICgpCit7CityZXR1
cm4gZGVmbGF0ZUNvcHkgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHk9
eWVzCitlbHNlCisgIGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5PW5vCitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl96
X2RlZmxhdGVDb3B5IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4m
NjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfel9kZWZsYXRlQ29weSIgPSB4eWVzOyB0aGVuIDoK
KyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX0xJQlogMQorX0FDRU9G
CisKKyAgTElCUz0iLWx6ICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBu
b3QgZmluZCB6bGliIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252IiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYuLi4g
IiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4rOn0gZmFsc2U7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJf
c2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGljb252ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyog
T3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisg
ICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBH
Q0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGls
bCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hh
ciBsaWJpY29udl9vcGVuICgpOworaW50CittYWluICgpCit7CityZXR1cm4gbGliaWNvbnZfb3Bl
biAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj15ZXMKK2Vs
c2UKKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2lj
b252X2xpYmljb252X29wZW4iID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfaWNvbnZfbGliaWNv
bnZfb3BlbiIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVu
IiA9IHh5ZXM7IHRoZW4gOgorICBsaWJpY29udj0ieSIKK2Vsc2UKKyAgbGliaWNvbnY9Im4iCitm
aQorCisKKworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5o
IGNoZWNrKQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK2FjX2ZuX2NfY2hlY2tfdHlwZSAi
JExJTkVOTyIgInNpemVfdCIgImFjX2N2X3R5cGVfc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc2l6ZV90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNl
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgc2l6ZV90IHVuc2lnbmVkIGlu
dAorX0FDRU9GCisKK2ZpCisKKyMgVGhlIFVsdHJpeCA0LjIgbWlwcyBidWlsdGluIGFsbG9jYSBk
ZWNsYXJlZCBieSBhbGxvY2EuaCBvbmx5IHdvcmtzCisjIGZvciBjb25zdGFudCBhcmd1bWVudHMu
ICBVc2VsZXNzIQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3Igd29ya2luZyBhbGxvY2EuaCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
d29ya2luZyBhbGxvY2EuaC4uLiAiID4mNjsgfQoraWYgJHthY19jdl93b3JraW5nX2FsbG9jYV9o
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworI2luY2x1ZGUgPGFsbG9jYS5oPgoraW50CittYWluICgpCit7CitjaGFyICpw
ID0gKGNoYXIgKikgYWxsb2NhICgyICogc2l6ZW9mIChpbnQpKTsKKwkJCSAgaWYgKHApIHJldHVy
biAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3dvcmtpbmdfYWxsb2NhX2g9eWVzCitlbHNlCisgIGFj
X2N2X3dvcmtpbmdfYWxsb2NhX2g9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4
dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3Zfd29ya2luZ19hbGxvY2FfaCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3dvcmtpbmdfYWxs
b2NhX2giID4mNjsgfQoraWYgdGVzdCAkYWNfY3Zfd29ya2luZ19hbGxvY2FfaCA9IHllczsgdGhl
bgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX0FMTE9DQV9IIDEiID4+Y29uZmRlZnMuaAorCitm
aQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBhbGxvY2EiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGFsbG9jYS4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9mdW5jX2FsbG9jYV93b3Jrcys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZmRlZiBfX0dOVUNf
XworIyBkZWZpbmUgYWxsb2NhIF9fYnVpbHRpbl9hbGxvY2EKKyNlbHNlCisjIGlmZGVmIF9NU0Nf
VkVSCisjICBpbmNsdWRlIDxtYWxsb2MuaD4KKyMgIGRlZmluZSBhbGxvY2EgX2FsbG9jYQorIyBl
bHNlCisjICBpZmRlZiBIQVZFX0FMTE9DQV9ICisjICAgaW5jbHVkZSA8YWxsb2NhLmg+CisjICBl
bHNlCisjICAgaWZkZWYgX0FJWAorICNwcmFnbWEgYWxsb2NhCisjICAgZWxzZQorIyAgICBpZm5k
ZWYgYWxsb2NhIC8qIHByZWRlZmluZWQgYnkgSFAgY2MgK09saWJjYWxscyAqLwordm9pZCAqYWxs
b2NhIChzaXplX3QpOworIyAgICBlbmRpZgorIyAgIGVuZGlmCisjICBlbmRpZgorIyBlbmRpZgor
I2VuZGlmCisKK2ludAorbWFpbiAoKQoreworY2hhciAqcCA9IChjaGFyICopIGFsbG9jYSAoMSk7
CisJCQkJICAgIGlmIChwKSByZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX2FsbG9j
YV93b3Jrcz15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3M9bm8KK2ZpCitybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRh
Y19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MiID4mNQorJGFz
X2VjaG8gIiRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY2OyB9CisKK2lmIHRlc3QgJGFjX2N2
X2Z1bmNfYWxsb2NhX3dvcmtzID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVf
QUxMT0NBIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgICMgVGhlIFNWUjMgbGliUFcgYW5kIFNW
UjQgbGlidWNiIGJvdGggY29udGFpbiBpbmNvbXBhdGlibGUgZnVuY3Rpb25zCisjIHRoYXQgY2F1
c2UgdHJvdWJsZS4gIFNvbWUgdmVyc2lvbnMgZG8gbm90IGV2ZW4gY29udGFpbiBhbGxvY2Egb3IK
KyMgY29udGFpbiBhIGJ1Z2d5IHZlcnNpb24uICBJZiB5b3Ugc3RpbGwgd2FudCB0byB1c2UgdGhl
aXIgYWxsb2NhLAorIyB1c2UgYXIgdG8gZXh0cmFjdCBhbGxvY2EubyBmcm9tIHRoZW0gaW5zdGVh
ZCBvZiBjb21waWxpbmcgYWxsb2NhLmMuCisKK0FMTE9DQT1cJHtMSUJPQkpESVJ9YWxsb2NhLiRh
Y19vYmpleHQKKworJGFzX2VjaG8gIiNkZWZpbmUgQ19BTExPQ0EgMSIgPj5jb25mZGVmcy5oCisK
KworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0
aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgd2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X29zX2NyYXkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBDUkFZICYmICEgZGVmaW5lZCBD
UkFZMgord2ViZWNyYXkKKyNlbHNlCit3ZW5vdGJlY3JheQorI2VuZGlmCisKK19BQ0VPRgoraWYg
KGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAorICAkRUdSRVAgIndlYmVj
cmF5IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBhY19jdl9vc19jcmF5PXllcworZWxzZQor
ICBhY19jdl9vc19jcmF5PW5vCitmaQorcm0gLWYgY29uZnRlc3QqCisKK2ZpCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29zX2NyYXkiID4m
NQorJGFzX2VjaG8gIiRhY19jdl9vc19jcmF5IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X29zX2Ny
YXkgPSB5ZXM7IHRoZW4KKyAgZm9yIGFjX2Z1bmMgaW4gX2dldGI2NyBHRVRCNjcgZ2V0YjY3OyBk
bworICAgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3Ry
X3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFy
IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIENSQVlfU1RBQ0tTRUdfRU5EICRhY19m
dW5jCitfQUNFT0YKKworICAgIGJyZWFrCitmaQorCisgIGRvbmUKK2ZpCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZv
ciBDIGFsbG9jYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBzdGFjayBkaXJlY3Rpb24gZm9y
IEMgYWxsb2NhLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9jX3N0YWNrX2RpcmVj
dGlvbj0wCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK2Zp
bmRfc3RhY2tfZGlyZWN0aW9uICgpCit7CisgIHN0YXRpYyBjaGFyICphZGRyID0gMDsKKyAgYXV0
byBjaGFyIGR1bW15OworICBpZiAoYWRkciA9PSAwKQorICAgIHsKKyAgICAgIGFkZHIgPSAmZHVt
bXk7CisgICAgICByZXR1cm4gZmluZF9zdGFja19kaXJlY3Rpb24gKCk7CisgICAgfQorICBlbHNl
CisgICAgcmV0dXJuICgmZHVtbXkgPiBhZGRyKSA/IDEgOiAtMTsKK30KKworaW50CittYWluICgp
Cit7CisgIHJldHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKSA8IDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9jX3N0YWNrX2RpcmVj
dGlvbj0xCitlbHNlCisgIGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uPS0xCitmaQorcm0gLWYgY29y
ZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVl
eHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4
dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfY19zdGFja19kaXJlY3Rpb24iID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX3N0
YWNrX2RpcmVjdGlvbiIgPiY2OyB9CitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IFNUQUNLX0RJUkVDVElPTiAkYWNfY3ZfY19zdGFja19kaXJlY3Rpb24KK19BQ0VPRgorCisKK2Zp
CisKK2ZvciBhY19oZWFkZXIgaW4gIFwKKyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250
bC5oIGludHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAg
ICAgICBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJp
bmcuaCBcCisgICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmgg
c3lzL21vdW50Lmggc3lzL3BhcmFtLmggXAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBz
eXMvc3RhdHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAg
ICAgICB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKworZG8gOgorICBhc19hY19IZWFk
ZXI9YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19I
ZWFkZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNf
SGVhZGVyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCitfQUNF
T0YKKworZmkKKworZG9uZQorCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywg
YW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5
OSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMg
dG8gQzk5Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hlYWRlcl9zdGRib29sX2grOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKyNpbmNsdWRlIDxzdGRib29sLmg+CisjaWZuZGVmIGJvb2wKKyAiZXJyb3I6IGJvb2wgaXMg
bm90IGRlZmluZWQiCisjZW5kaWYKKyNpZm5kZWYgZmFsc2UKKyAiZXJyb3I6IGZhbHNlIGlzIG5v
dCBkZWZpbmVkIgorI2VuZGlmCisjaWYgZmFsc2UKKyAiZXJyb3I6IGZhbHNlIGlzIG5vdCAwIgor
I2VuZGlmCisjaWZuZGVmIHRydWUKKyAiZXJyb3I6IHRydWUgaXMgbm90IGRlZmluZWQiCisjZW5k
aWYKKyNpZiB0cnVlICE9IDEKKyAiZXJyb3I6IHRydWUgaXMgbm90IDEiCisjZW5kaWYKKyNpZm5k
ZWYgX19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQKKyAiZXJyb3I6IF9fYm9vbF90cnVlX2Zh
bHNlX2FyZV9kZWZpbmVkIGlzIG5vdCBkZWZpbmVkIgorI2VuZGlmCisKKwlzdHJ1Y3QgcyB7IF9C
b29sIHM6IDE7IF9Cb29sIHQ7IH0gczsKKworCWNoYXIgYVt0cnVlID09IDEgPyAxIDogLTFdOwor
CWNoYXIgYltmYWxzZSA9PSAwID8gMSA6IC0xXTsKKwljaGFyIGNbX19ib29sX3RydWVfZmFsc2Vf
YXJlX2RlZmluZWQgPT0gMSA/IDEgOiAtMV07CisJY2hhciBkWyhib29sKSAwLjUgPT0gdHJ1ZSA/
IDEgOiAtMV07CisJLyogU2VlIGJvZHkgb2YgbWFpbiBwcm9ncmFtIGZvciAnZScuICAqLworCWNo
YXIgZlsoX0Jvb2wpIDAuMCA9PSBmYWxzZSA/IDEgOiAtMV07CisJY2hhciBnW3RydWVdOworCWNo
YXIgaFtzaXplb2YgKF9Cb29sKV07CisJY2hhciBpW3NpemVvZiBzLnRdOworCWVudW0geyBqID0g
ZmFsc2UsIGsgPSB0cnVlLCBsID0gZmFsc2UgKiB0cnVlLCBtID0gdHJ1ZSAqIDI1NiB9OworCS8q
IFRoZSBmb2xsb3dpbmcgZmFpbHMgZm9yCisJICAgSFAgYUMrKy9BTlNJIEMgQjM5MTBCIEEuMDUu
NTUgW0RlYyAwNCAyMDAzXS4gKi8KKwlfQm9vbCBuW21dOworCWNoYXIgb1tzaXplb2YgbiA9PSBt
ICogc2l6ZW9mIG5bMF0gPyAxIDogLTFdOworCWNoYXIgcFstMSAtIChfQm9vbCkgMCA8IDAgJiYg
LTEgLSAoYm9vbCkgMCA8IDAgPyAxIDogLTFdOworCS8qIENhdGNoIGEgYnVnIGluIGFuIEhQLVVY
IEMgY29tcGlsZXIuICBTZWUKKwkgICBodHRwOi8vZ2NjLmdudS5vcmcvbWwvZ2NjLXBhdGNoZXMv
MjAwMy0xMi9tc2cwMjMwMy5odG1sCisJICAgaHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9o
dG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMS9tc2cwMDE2MS5odG1sCisJICovCisJX0Jvb2wgcSA9
IHRydWU7CisJX0Jvb2wgKnBxID0gJnE7CisKK2ludAorbWFpbiAoKQoreworCisJYm9vbCBlID0g
JnM7CisJKnBxIHw9IHE7CisJKnBxIHw9ICEgcTsKKwkvKiBSZWZlciB0byBldmVyeSBkZWNsYXJl
ZCB2YWx1ZSwgdG8gYXZvaWQgY29tcGlsZXIgb3B0aW1pemF0aW9ucy4gICovCisJcmV0dXJuICgh
YSArICFiICsgIWMgKyAhZCArICFlICsgIWYgKyAhZyArICFoICsgIWkgKyAhIWogKyAhayArICEh
bAorCQkrICFtICsgIW4gKyAhbyArICFwICsgIXEgKyAhcHEpOworCisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaD15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0ZGJvb2xf
aD1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29u
ZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2hlYWRlcl9zdGRib29sX2giID4mNjsgfQorYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAi
X0Jvb2wiICJhY19jdl90eXBlX19Cb29sIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X3R5cGVfX0Jvb2wiID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9fQk9PTCAxCitfQUNFT0YKKworCitmaQorCitpZiB0ZXN0
ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5l
IEhBVkVfU1REQk9PTF9IIDEiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMvdHlwZXMu
aCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4g
IiA+JjY7IH0KK2lmICR7YWNfY3ZfdHlwZV91aWRfdCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzeXMv
dHlwZXMuaD4KKworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0Iikg
Mj4mNSB8CisgICRFR1JFUCAidWlkX3QiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisgIGFjX2N2
X3R5cGVfdWlkX3Q9eWVzCitlbHNlCisgIGFjX2N2X3R5cGVfdWlkX3Q9bm8KK2ZpCitybSAtZiBj
b25mdGVzdCoKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfdHlwZV91aWRfdCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3R5cGVfdWlk
X3QiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfdHlwZV91aWRfdCA9IG5vOyB0aGVuCisKKyRhc19l
Y2hvICIjZGVmaW5lIHVpZF90IGludCIgPj5jb25mZGVmcy5oCisKKworJGFzX2VjaG8gIiNkZWZp
bmUgZ2lkX3QgaW50IiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW5saW5lIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciBpbmxpbmUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19pbmxpbmUrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19j
dl9jX2lubGluZT1ubworZm9yIGFjX2t3IGluIGlubGluZSBfX2lubGluZV9fIF9faW5saW5lOyBk
bworICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisjaWZuZGVmIF9fY3BsdXNwbHVzCit0eXBlZGVmIGludCBmb29fdDsK
K3N0YXRpYyAkYWNfa3cgZm9vX3Qgc3RhdGljX2ZvbyAoKSB7cmV0dXJuIDA7IH0KKyRhY19rdyBm
b29fdCBmb28gKCkge3JldHVybiAwOyB9CisjZW5kaWYKKworX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2NfaW5saW5lPSRhY19rdworZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj
X2V4dAorICB0ZXN0ICIkYWNfY3ZfY19pbmxpbmUiICE9IG5vICYmIGJyZWFrCitkb25lCisKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2NfaW5saW5lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19pbmxpbmUiID4mNjsgfQorCitjYXNl
ICRhY19jdl9jX2lubGluZSBpbgorICBpbmxpbmUgfCB5ZXMpIDs7CisgICopCisgICAgY2FzZSAk
YWNfY3ZfY19pbmxpbmUgaW4KKyAgICAgIG5vKSBhY192YWw9OzsKKyAgICAgICopIGFjX3ZhbD0k
YWNfY3ZfY19pbmxpbmU7OworICAgIGVzYWMKKyAgICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjaWZuZGVmIF9fY3BsdXNwbHVzCisjZGVmaW5lIGlubGluZSAkYWNfdmFsCisjZW5kaWYKK19B
Q0VPRgorICAgIDs7Citlc2FjCisKK2FjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICIxNiIg
ImFjX2N2X2NfaW50MTZfdCIKK2Nhc2UgJGFjX2N2X2NfaW50MTZfdCBpbiAjKAorICBub3x5ZXMp
IDs7ICMoCisgICopCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgaW50MTZf
dCAkYWNfY3ZfY19pbnQxNl90CitfQUNFT0YKKzs7Citlc2FjCisKK2FjX2ZuX2NfZmluZF9pbnRY
X3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2NfaW50MzJfdCIKK2Nhc2UgJGFjX2N2X2NfaW50MzJf
dCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKKyNkZWZpbmUgaW50MzJfdCAkYWNfY3ZfY19pbnQzMl90CitfQUNFT0YKKzs7Citlc2FjCisK
K2FjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICI2NCIgImFjX2N2X2NfaW50NjRfdCIKK2Nh
c2UgJGFjX2N2X2NfaW50NjRfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKK2NhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgaW50NjRfdCAkYWNfY3ZfY19pbnQ2NF90Citf
QUNFT0YKKzs7Citlc2FjCisKK2FjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICI4IiAiYWNf
Y3ZfY19pbnQ4X3QiCitjYXNlICRhY19jdl9jX2ludDhfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMo
CisgICopCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgaW50OF90ICRhY19j
dl9jX2ludDhfdAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F
Tk8iICJtb2RlX3QiICJhY19jdl90eXBlX21vZGVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igor
aWYgdGVzdCAieCRhY19jdl90eXBlX21vZGVfdCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIG1vZGVfdCBpbnQKK19BQ0VPRgorCitm
aQorCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJvZmZfdCIgImFjX2N2X3R5cGVfb2Zm
X3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9vZmZfdCIg
PSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVm
aW5lIG9mZl90IGxvbmcgaW50CitfQUNFT0YKKworZmkKKworYWNfZm5fY19jaGVja190eXBlICIk
TElORU5PIiAicGlkX3QiICJhY19jdl90eXBlX3BpZF90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQi
CitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcGlkX3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBwaWRfdCBpbnQKK19BQ0VPRgorCitm
aQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBDL0MrKyByZXN0cmljdCBrZXl3b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBD
L0MrKyByZXN0cmljdCBrZXl3b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfcmVzdHJpY3Qr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBh
Y19jdl9jX3Jlc3RyaWN0PW5vCisgICAjIFRoZSBvcmRlciBoZXJlIGNhdGVycyB0byB0aGUgZmFj
dCB0aGF0IEMrKyBkb2VzIG5vdCByZXF1aXJlIHJlc3RyaWN0LgorICAgZm9yIGFjX2t3IGluIF9f
cmVzdHJpY3QgX19yZXN0cmljdF9fIF9SZXN0cmljdCByZXN0cmljdDsgZG8KKyAgICAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLwordHlwZWRlZiBpbnQgKiBpbnRfcHRyOworCWludCBmb28gKGludF9wdHIgJGFjX2t3IGlw
KSB7CisJcmV0dXJuIGlwWzBdOworICAgICAgIH0KK2ludAorbWFpbiAoKQoreworaW50IHNbMV07
CisJaW50ICogJGFjX2t3IHQgPSBzOworCXRbMF0gPSAwOworCXJldHVybiBmb28odCkKKyAgOwor
ICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9jX3Jlc3RyaWN0PSRhY19rdworZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgICB0ZXN0ICIk
YWNfY3ZfY19yZXN0cmljdCIgIT0gbm8gJiYgYnJlYWsKKyAgIGRvbmUKKworZmkKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19yZXN0cmlj
dCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2NfcmVzdHJpY3QiID4mNjsgfQorCisgY2FzZSAkYWNf
Y3ZfY19yZXN0cmljdCBpbgorICAgcmVzdHJpY3QpIDs7CisgICBubykgJGFzX2VjaG8gIiNkZWZp
bmUgcmVzdHJpY3QgLyoqLyIgPj5jb25mZGVmcy5oCisgOzsKKyAgICopICBjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIHJlc3RyaWN0ICRhY19jdl9jX3Jlc3RyaWN0CitfQUNFT0YK
KyA7OworIGVzYWMKKworYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic2l6ZV90IiAiYWNf
Y3ZfdHlwZV9zaXplX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3Zf
dHlwZV9zaXplX3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSBzaXplX3QgdW5zaWduZWQgaW50CitfQUNFT0YKKworZmkKKworYWNf
Zm5fY19jaGVja190eXBlICIkTElORU5PIiAic3NpemVfdCIgImFjX2N2X3R5cGVfc3NpemVfdCIg
IiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3NzaXplX3QiID0g
eHllczsgdGhlbiA6CisKK2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBzc2l6ZV90IGludAorX0FDRU9GCisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElO
RU5PIiAic3RydWN0IHN0YXQiICJzdF9ibGtzaXplIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0
X3N0X2Jsa3NpemUiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfbWVt
YmVyX3N0cnVjdF9zdGF0X3N0X2Jsa3NpemUiID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZk
ZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTEtTSVpFIDEKK19B
Q0VPRgorCisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0
YXQiICJzdF9ibG9ja3MiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxvY2tzIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9z
dF9ibG9ja3MiID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgSEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MgMQorX0FDRU9GCisKKworJGFzX2VjaG8g
IiNkZWZpbmUgSEFWRV9TVF9CTE9DS1MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgY2FzZSAi
ICRMSUJPQkpTICIgaW4KKyAgKiIgZmlsZWJsb2Nrcy4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikg
TElCT0JKUz0iJExJQk9CSlMgZmlsZWJsb2Nrcy4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKK2Zp
CisKKworYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X3Jk
ZXYiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfcmRldiIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgoraWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfcmRldiIgPSB4eWVz
OyB0aGVuIDoKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NUUlVD
VF9TVEFUX1NUX1JERVYgMQorX0FDRU9GCisKKworZmkKKworYWNfZm5fY19maW5kX3VpbnRYX3Qg
IiRMSU5FTk8iICIxNiIgImFjX2N2X2NfdWludDE2X3QiCitjYXNlICRhY19jdl9jX3VpbnQxNl90
IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKworCitjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCisjZGVmaW5lIHVpbnQxNl90ICRhY19jdl9jX3VpbnQxNl90CitfQUNFT0YKKzs7CisgIGVz
YWMKKworYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2NfdWludDMy
X3QiCitjYXNlICRhY19jdl9jX3VpbnQzMl90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikK
KworJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQzMl9UIDEiID4+Y29uZmRlZnMuaAorCisKK2NhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgdWludDMyX3QgJGFjX2N2X2NfdWludDMyX3QK
K19BQ0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjY0
IiAiYWNfY3ZfY191aW50NjRfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDY0X3QgaW4gIygKKyAgbm98
eWVzKSA7OyAjKAorICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBfVUlOVDY0X1QgMSIgPj5jb25m
ZGVmcy5oCisKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1aW50NjRfdCAk
YWNfY3ZfY191aW50NjRfdAorX0FDRU9GCis7OworICBlc2FjCisKK2FjX2ZuX2NfZmluZF91aW50
WF90ICIkTElORU5PIiAiOCIgImFjX2N2X2NfdWludDhfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDhf
dCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKKyRhc19lY2hvICIjZGVmaW5lIF9VSU5U
OF9UIDEiID4+Y29uZmRlZnMuaAorCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZp
bmUgdWludDhfdCAkYWNfY3ZfY191aW50OF90CitfQUNFT0YKKzs7CisgIGVzYWMKKworYWNfZm5f
Y19jaGVja190eXBlICIkTElORU5PIiAicHRyZGlmZl90IiAiYWNfY3ZfdHlwZV9wdHJkaWZmX3Qi
ICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9wdHJkaWZmX3Qi
ID0geHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFW
RV9QVFJESUZGX1QgMQorX0FDRU9GCisKKworZmkKKworCisjIENoZWNrcyBmb3IgbGlicmFyeSBm
dW5jdGlvbnMuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBlcnJvcl9hdF9saW5lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBlcnJv
cl9hdF9saW5lLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9lcnJvcl9hdF9saW5lKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworI2luY2x1ZGUgPGVycm9yLmg+CitpbnQKK21haW4gKCkKK3sKK2Vycm9yX2F0X2xpbmUg
KDAsIDAsICIiLCAwLCAiYW4gZXJyb3Igb2NjdXJyZWQiKTsKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9s
aWJfZXJyb3JfYXRfbGluZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmU9bm8K
K2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBj
b25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUi
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfZXJyb3JfYXRfbGluZSIgPiY2OyB9CitpZiB0ZXN0
ICRhY19jdl9saWJfZXJyb3JfYXRfbGluZSA9IG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JKUyAi
IGluCisgICoiIGVycm9yLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JK
UyBlcnJvci4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKK2ZpCisKK2ZvciBhY19oZWFkZXIgaW4g
dmZvcmsuaAorZG8gOgorICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAi
dmZvcmsuaCIgImFjX2N2X2hlYWRlcl92Zm9ya19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitp
ZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl92Zm9ya19oIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfVkZPUktfSCAxCitfQUNFT0YKKworZmkK
KworZG9uZQorCitmb3IgYWNfZnVuYyBpbiBmb3JrIHZmb3JrCitkbyA6CisgIGFzX2FjX3Zhcj1g
JGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVj
a19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwi
eFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAx
CitfQUNFT0YKKworZmkKK2RvbmUKKworaWYgdGVzdCAieCRhY19jdl9mdW5jX2ZvcmsiID0geHll
czsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciB3b3JraW5nIGZvcmsiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtp
bmcgZm9yay4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX2Zvcmtfd29ya3MrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIk
Y3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1j
cm9zcworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50CittYWlu
ICgpCit7CisKKwkgIC8qIEJ5IFJ1ZWRpZ2VyIEt1aGxtYW5uLiAqLworCSAgcmV0dXJuIGZvcmsg
KCkgPCAwOworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCitlbHNlCisg
IGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29u
ZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3Qu
JGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNf
Zm9ya193b3JrcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPiY2OyB9
CisKK2Vsc2UKKyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPSRhY19jdl9mdW5jX2ZvcmsKK2ZpCitp
ZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KKyAgY2FzZSAk
aG9zdCBpbgorICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3BwKikKKyAgICAgICMgT3Zl
cnJpZGUsIGFzIHRoZXNlIHN5c3RlbXMgaGF2ZSBvbmx5IGEgZHVtbXkgZm9yaygpIHN0dWIKKyAg
ICAgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1ubworICAgICAgOzsKKyAgICAqKQorICAgICAgYWNf
Y3ZfZnVuY19mb3JrX3dvcmtzPXllcworICAgICAgOzsKKyAgZXNhYworICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19m
b3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVz
c2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorYWNfY3ZfZnVuY192
Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yaworaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3Jr
IiA9IHh5ZXM7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3Igd29ya2luZyB2Zm9yayIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm
b3Igd29ya2luZyB2Zm9yay4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX3Zmb3JrX3dvcmtz
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzPWNyb3NzCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIFRoYW5rcyB0byBQYXVsIEVn
Z2VydCBmb3IgdGhpcyB0ZXN0LiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisjaW5jbHVkZSA8
c3lzL3dhaXQuaD4KKyNpZmRlZiBIQVZFX1ZGT1JLX0gKKyMgaW5jbHVkZSA8dmZvcmsuaD4KKyNl
bmRpZgorLyogT24gc29tZSBzcGFyYyBzeXN0ZW1zLCBjaGFuZ2VzIGJ5IHRoZSBjaGlsZCB0byBs
b2NhbCBhbmQgaW5jb21pbmcKKyAgIGFyZ3VtZW50IHJlZ2lzdGVycyBhcmUgcHJvcGFnYXRlZCBi
YWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGlsZXIKKyAgIGlzIHRvbGQgYWJvdXQgdGhpcyB3
aXRoICNpbmNsdWRlIDx2Zm9yay5oPiwgYnV0IHNvbWUgY29tcGlsZXJzCisgICAoZS5nLiBnY2Mg
LU8pIGRvbid0IGdyb2sgPHZmb3JrLmg+LiAgVGVzdCBmb3IgdGhpcyBieSB1c2luZyBhCisgICBz
dGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVzcyBpcyBwdXQgaW50byBhIHJlZ2lzdGVyIHRoYXQg
aXMKKyAgIGNsb2JiZXJlZCBieSB0aGUgdmZvcmsuICAqLworc3RhdGljIHZvaWQKKyNpZmRlZiBf
X2NwbHVzcGx1cworc3BhcmNfYWRkcmVzc190ZXN0IChpbnQgYXJnKQorIyBlbHNlCitzcGFyY19h
ZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsKKyNlbmRpZgoreworICBzdGF0aWMgcGlkX3QgY2hp
bGQ7CisgIGlmICghY2hpbGQpIHsKKyAgICBjaGlsZCA9IHZmb3JrICgpOworICAgIGlmIChjaGls
ZCA8IDApIHsKKyAgICAgIHBlcnJvciAoInZmb3JrIik7CisgICAgICBfZXhpdCgyKTsKKyAgICB9
CisgICAgaWYgKCFjaGlsZCkgeworICAgICAgYXJnID0gZ2V0cGlkKCk7CisgICAgICB3cml0ZSgt
MSwgIiIsIDApOworICAgICAgX2V4aXQgKGFyZyk7CisgICAgfQorICB9Cit9CisKK2ludAorbWFp
biAoKQoreworICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7CisgIHBpZF90IGNoaWxkOworCisg
IHNwYXJjX2FkZHJlc3NfdGVzdCAoMCk7CisKKyAgY2hpbGQgPSB2Zm9yayAoKTsKKworICBpZiAo
Y2hpbGQgPT0gMCkgeworICAgIC8qIEhlcmUgaXMgYW5vdGhlciB0ZXN0IGZvciBzcGFyYyB2Zm9y
ayByZWdpc3RlciBwcm9ibGVtcy4gIFRoaXMKKyAgICAgICB0ZXN0IHVzZXMgbG90cyBvZiBsb2Nh
bCB2YXJpYWJsZXMsIGF0IGxlYXN0IGFzIG1hbnkgbG9jYWwKKyAgICAgICB2YXJpYWJsZXMgYXMg
bWFpbiBoYXMgYWxsb2NhdGVkIHNvIGZhciBpbmNsdWRpbmcgY29tcGlsZXIKKyAgICAgICB0ZW1w
b3Jhcmllcy4gIDQgbG9jYWxzIGFyZSBlbm91Z2ggZm9yIGdjYyAxLjQwLjMgb24gYSBTb2xhcmlz
CisgICAgICAgNC4xLjMgc3BhcmMsIGJ1dCB3ZSB1c2UgOCB0byBiZSBzYWZlLiAgQSBidWdneSBj
b21waWxlciBzaG91bGQKKyAgICAgICByZXVzZSB0aGUgcmVnaXN0ZXIgb2YgcGFyZW50IGZvciBv
bmUgb2YgdGhlIGxvY2FsIHZhcmlhYmxlcywKKyAgICAgICBzaW5jZSBpdCB3aWxsIHRoaW5rIHRo
YXQgcGFyZW50IGNhbid0IHBvc3NpYmx5IGJlIHVzZWQgYW55IG1vcmUKKyAgICAgICBpbiB0aGlz
IHJvdXRpbmUuICBBc3NpZ25pbmcgdG8gdGhlIGxvY2FsIHZhcmlhYmxlIHdpbGwgdGh1cworICAg
ICAgIG11bmdlIHBhcmVudCBpbiB0aGUgcGFyZW50IHByb2Nlc3MuICAqLworICAgIHBpZF90Cisg
ICAgICBwID0gZ2V0cGlkKCksIHAxID0gZ2V0cGlkKCksIHAyID0gZ2V0cGlkKCksIHAzID0gZ2V0
cGlkKCksCisgICAgICBwNCA9IGdldHBpZCgpLCBwNSA9IGdldHBpZCgpLCBwNiA9IGdldHBpZCgp
LCBwNyA9IGdldHBpZCgpOworICAgIC8qIENvbnZpbmNlIHRoZSBjb21waWxlciB0aGF0IHAuLnA3
IGFyZSBsaXZlOyBvdGhlcndpc2UsIGl0IG1pZ2h0CisgICAgICAgdXNlIHRoZSBzYW1lIGhhcmR3
YXJlIHJlZ2lzdGVyIGZvciBhbGwgOCBsb2NhbCB2YXJpYWJsZXMuICAqLworICAgIGlmIChwICE9
IHAxIHx8IHAgIT0gcDIgfHwgcCAhPSBwMyB8fCBwICE9IHA0CisJfHwgcCAhPSBwNSB8fCBwICE9
IHA2IHx8IHAgIT0gcDcpCisgICAgICBfZXhpdCgxKTsKKworICAgIC8qIE9uIHNvbWUgc3lzdGVt
cyAoZS5nLiBJUklYIDMuMyksIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50CisgICAgICAg
ZnJvbSBjaGlsZCBmaWxlIGRlc2NyaXB0b3JzLiAgSWYgdGhlIGNoaWxkIGNsb3NlcyBhIGRlc2Ny
aXB0b3IKKyAgICAgICBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMsIHRoaXMgbXVuZ2VzIHRoZSBw
YXJlbnQncyBkZXNjcmlwdG9yCisgICAgICAgYXMgd2VsbC4gIFRlc3QgZm9yIHRoaXMgYnkgY2xv
c2luZyBzdGRvdXQgaW4gdGhlIGNoaWxkLiAgKi8KKyAgICBfZXhpdChjbG9zZShmaWxlbm8oc3Rk
b3V0KSkgIT0gMCk7CisgIH0gZWxzZSB7CisgICAgaW50IHN0YXR1czsKKyAgICBzdHJ1Y3Qgc3Rh
dCBzdDsKKworICAgIHdoaWxlICh3YWl0KCZzdGF0dXMpICE9IGNoaWxkKQorICAgICAgOworICAg
IHJldHVybiAoCisJIC8qIFdhcyB0aGVyZSBzb21lIHByb2JsZW0gd2l0aCB2Zm9ya2luZz8gICov
CisJIGNoaWxkIDwgMAorCisJIC8qIERpZCB0aGUgY2hpbGQgZmFpbD8gIChUaGlzIHNob3VsZG4n
dCBoYXBwZW4uKSAgKi8KKwkgfHwgc3RhdHVzCisKKwkgLyogRGlkIHRoZSB2Zm9yay9jb21waWxl
ciBidWcgb2NjdXI/ICAqLworCSB8fCBwYXJlbnQgIT0gZ2V0cGlkKCkKKworCSAvKiBEaWQgdGhl
IGZpbGUgZGVzY3JpcHRvciBidWcgb2NjdXI/ICAqLworCSB8fCBmc3RhdChmaWxlbm8oc3Rkb3V0
KSwgJnN0KSAhPSAwCisJICk7CisgIH0KK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9eWVzCitlbHNlCisgIGFj
X2N2X2Z1bmNfdmZvcmtfd29ya3M9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0
ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3Zm
b3JrX3dvcmtzIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPiY2OyB9
CisKK2ZpOworaWYgdGVzdCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geGNyb3NzOyB0aGVu
CisgIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1bmNfdmZvcmsKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY192Zm9ya193b3Jr
cyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9CitmaQorCitpZiB0
ZXN0ICJ4JGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID0geHllczsgdGhlbgorCiskYXNfZWNobyAi
I2RlZmluZSBIQVZFX1dPUktJTkdfVkZPUksgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKworJGFz
X2VjaG8gIiNkZWZpbmUgdmZvcmsgZm9yayIgPj5jb25mZGVmcy5oCisKK2ZpCitpZiB0ZXN0ICJ4
JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5l
IEhBVkVfV09SS0lOR19GT1JLIDEiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBfTEFSR0VGSUxFX1NPVVJD
RSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBfTEFSR0VGSUxFX1NPVVJDRSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgd2hpbGUgOjsgZG8KKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8KKyAgICAgI2lu
Y2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkKK3sKK2ludCAoKmZwKSAoRklMRSAqLCBvZmZf
dCwgaW50KSA9IGZzZWVrbzsKKyAgICAgcmV0dXJuIGZzZWVrbyAoc3RkaW4sIDAsIDApICYmIGZw
IChzdGRpbiwgMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9
bm87IGJyZWFrCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAxCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+IC8q
IGZvciBvZmZfdCAqLworICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAoKQorewor
aW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOworICAgICByZXR1cm4gZnNl
ZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT0xOyBicmVhaworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz
dC4kYWNfZXh0CisgIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPXVua25vd24KKyAgYnJlYWsK
K2RvbmUKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfc3lz
X2xhcmdlZmlsZV9zb3VyY2UiID4mNjsgfQorY2FzZSAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3Vy
Y2UgaW4gIygKKyAgbm8gfCB1bmtub3duKSA7OworICAqKQorY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3Vy
Y2UKK19BQ0VPRgorOzsKK2VzYWMKK3JtIC1yZiBjb25mdGVzdCoKKworIyBXZSB1c2VkIHRvIHRy
eSBkZWZpbmluZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5kIGEgYnVnCisj
IGluIGdsaWJjIDIuMS4zLCBidXQgdGhhdCBicmVha3MgdG9vIG1hbnkgb3RoZXIgdGhpbmdzLgor
IyBJZiB5b3Ugd2FudCBmc2Vla28gYW5kIGZ0ZWxsbyB3aXRoIGdsaWJjLCB1cGdyYWRlIHRvIGEg
Zml4ZWQgZ2xpYmMuCitpZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSAhPSB1bmtu
b3duOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+Y29uZmRlZnMu
aAorCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMgdHJhaWxpbmcgc2xhc2giID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFuZGxlcyB0cmFp
bGluZyBzbGFzaC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNl
c19zbGFzaGVkX3N5bWxpbmsrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBybSAtZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQorZWNobyA+
Y29uZnRlc3QuZmlsZQoraWYgdGVzdCAiJGFzX2xuX3MiID0gImxuIC1zIiAmJiBsbiAtcyBjb25m
dGVzdC5maWxlIGNvbmZ0ZXN0LnN5bTsgdGhlbgorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5n
IiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRf
c3ltbGluaz1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50
CittYWluICgpCit7CitzdHJ1Y3Qgc3RhdCBzYnVmOworICAgICAvKiBMaW51eCB3aWxsIGRlcmVm
ZXJlbmNlIHRoZSBzeW1saW5rIGFuZCBmYWlsLCBhcyByZXF1aXJlZCBieSBQT1NJWC4KKwlUaGF0
IGlzIGJldHRlciBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBtZWFucyB3ZSB3aWxsIG5vdAorCWhhdmUg
dG8gY29tcGlsZSBhbmQgdXNlIHRoZSBsc3RhdCB3cmFwcGVyLiAgKi8KKyAgICAgcmV0dXJuIGxz
dGF0ICgiY29uZnRlc3Quc3ltLyIsICZzYnVmKSA9PSAwOworICA7CisgIHJldHVybiAwOworfQor
X0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcworZWxzZQorICBhY19jdl9m
dW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KK2ZpCitybSAtZiBjb3Jl
ICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4
dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0
CitmaQorCitlbHNlCisgICMgSWYgdGhlIGBsbiAtcycgY29tbWFuZCBmYWlsZWQsIHRoZW4gd2Ug
cHJvYmFibHkgZG9uJ3QgZXZlbgorICAjIGhhdmUgYW4gbHN0YXQgZnVuY3Rpb24uCisgIGFjX2N2
X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubworZmkKK3JtIC1mIGNv
bmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3Ns
YXNoZWRfc3ltbGluayIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVu
Y2VzX3NsYXNoZWRfc3ltbGluayIgPiY2OyB9CisKK3Rlc3QgJGFjX2N2X2Z1bmNfbHN0YXRfZGVy
ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluayA9IHllcyAmJgorCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LIDEKK19BQ0VPRgor
CisKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1s
aW5rIiA9IHhubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBsc3RhdC4kYWNf
b2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgbHN0YXQuJGFjX29iamV4dCIK
KyA7OworZXNhYworCitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmggZGVmaW5lcyBtYWtlZGV2IiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgc3lzL3R5cGVzLmggZGVmaW5lcyBtYWtlZGV2Li4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2Kzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgoraW50CittYWluICgpCit7CityZXR1cm4gbWFrZWRl
digwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGlu
ayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj15
ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXY9bm8KK2ZpCitybSAt
ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRh
Y19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRl
diIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjY7
IH0KKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYgPSBubzsgdGhl
bgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN5cy9ta2Rldi5oIiAi
YWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIgPSB4eWVzOyB0aGVuIDoKKworJGFzX2VjaG8g
IiNkZWZpbmUgTUFKT1JfSU5fTUtERVYgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworCisgIGlm
IHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCA9IG5vOyB0aGVuCisgICAgYWNfZm5fY19j
aGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN5cy9zeXNtYWNyb3MuaCIgImFjX2N2X2hl
YWRlcl9zeXNfc3lzbWFjcm9zX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngk
YWNfY3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgPSB4eWVzOyB0aGVuIDoKKworJGFzX2VjaG8g
IiNkZWZpbmUgTUFKT1JfSU5fU1lTTUFDUk9TIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKyAg
ZmkKK2ZpCisKK2ZvciBhY19oZWFkZXIgaW4gc3RkbGliLmgKK2RvIDoKKyAgYWNfZm5fY19jaGVj
a19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxp
Yl9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRs
aWJfaCIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBIQVZFX1NURExJQl9IIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGli
bGUgbWFsbG9jIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRp
YmxlIG1hbGxvYy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBp
ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbWFs
bG9jXzBfbm9ubnVsbD1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBTVERDX0hF
QURFUlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorI2Vs
c2UKK2NoYXIgKm1hbGxvYyAoKTsKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAh
IG1hbGxvYyAoMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5
X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9eWVz
CitlbHNlCisgIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbD1ubworZmkKK3JtIC1mIGNvcmUg
Ki5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0
IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQK
K2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1
bmNfbWFsbG9jXzBfbm9ubnVsbCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX21hbGxvY18w
X25vbm51bGwgPSB5ZXM7IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAx
IiA+PmNvbmZkZWZzLmgKKworZWxzZQorICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX01BTExPQyAw
IiA+PmNvbmZkZWZzLmgKKworICAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbWFsbG9jLiRh
Y19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBtYWxsb2MuJGFjX29iamV4
dCIKKyA7OworZXNhYworCisKKyRhc19lY2hvICIjZGVmaW5lIG1hbGxvYyBycGxfbWFsbG9jIiA+
PmNvbmZkZWZzLmgKKworZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJl
IGluY2x1ZGVkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGltZS5oIGFuZCBz
eXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hl
YWRlcl90aW1lKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5
cy90aW1lLmg+CisjaW5jbHVkZSA8dGltZS5oPgorCitpbnQKK21haW4gKCkKK3sKK2lmICgoc3Ry
dWN0IHRtICopIDApCityZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfdGlt
ZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3RpbWU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl90
aW1lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3RpbWUiID4mNjsgfQoraWYgdGVzdCAk
YWNfY3ZfaGVhZGVyX3RpbWUgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgVElNRV9X
SVRIX1NZU19USU1FIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKworCisgIGZvciBhY19oZWFk
ZXIgaW4gJGFjX2hlYWRlcl9saXN0CitkbyA6CisgIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFj
X2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfaGVhZGVy
X2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNs
dWRlc19kZWZhdWx0CisiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgi
eWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19l
Y2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCisKK2Rv
bmUKKworCisKKworCisKKworCisgIGZvciBhY19mdW5jIGluICRhY19mdW5jX2xpc3QKK2RvIDoK
KyAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hg
CithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitp
ZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+
PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8
ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorZG9uZQorCisKKworCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1l
IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIG1rdGltZS4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGlu
ZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCitlbHNlCisg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKy8qIFRlc3QgcHJvZ3JhbSBmcm9tIFBhdWwgRWdnZXJ0IGFuZCBUb255IExl
bmVpcy4gICovCisjaWZkZWYgVElNRV9XSVRIX1NZU19USU1FCisjIGluY2x1ZGUgPHN5cy90aW1l
Lmg+CisjIGluY2x1ZGUgPHRpbWUuaD4KKyNlbHNlCisjIGlmZGVmIEhBVkVfU1lTX1RJTUVfSAor
IyAgaW5jbHVkZSA8c3lzL3RpbWUuaD4KKyMgZWxzZQorIyAgaW5jbHVkZSA8dGltZS5oPgorIyBl
bmRpZgorI2VuZGlmCisKKyNpbmNsdWRlIDxsaW1pdHMuaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4K
KworI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3RkLmg+CisjZW5kaWYKKwor
I2lmbmRlZiBIQVZFX0FMQVJNCisjIGRlZmluZSBhbGFybShYKSAvKiBlbXB0eSAqLworI2VuZGlm
CisKKy8qIFdvcmsgYXJvdW5kIHJlZGVmaW5pdGlvbiB0byBycGxfcHV0ZW52IGJ5IG90aGVyIGNv
bmZpZyB0ZXN0cy4gICovCisjdW5kZWYgcHV0ZW52CisKK3N0YXRpYyB0aW1lX3QgdGltZV90X21h
eDsKK3N0YXRpYyB0aW1lX3QgdGltZV90X21pbjsKKworLyogVmFsdWVzIHdlJ2xsIHVzZSB0byBz
ZXQgdGhlIFRaIGVudmlyb25tZW50IHZhcmlhYmxlLiAgKi8KK3N0YXRpYyBjb25zdCBjaGFyICp0
el9zdHJpbmdzW10gPSB7CisgIChjb25zdCBjaGFyICopIDAsICJUWj1HTVQwIiwgIlRaPUpTVC05
IiwKKyAgIlRaPUVTVCszRURUKzIsTTEwLjEuMC8wMDowMDowMCxNMi4zLjAvMDA6MDA6MDAiCit9
OworI2RlZmluZSBOX1NUUklOR1MgKHNpemVvZiAodHpfc3RyaW5ncykgLyBzaXplb2YgKHR6X3N0
cmluZ3NbMF0pKQorCisvKiBSZXR1cm4gMCBpZiBta3RpbWUgZmFpbHMgdG8gY29udmVydCBhIGRh
dGUgaW4gdGhlIHNwcmluZy1mb3J3YXJkIGdhcC4KKyAgIEJhc2VkIG9uIGEgcHJvYmxlbSByZXBv
cnQgZnJvbSBBbmRyZWFzIEphZWdlci4gICovCitzdGF0aWMgaW50CitzcHJpbmdfZm9yd2FyZF9n
YXAgKCkKK3sKKyAgLyogZ2xpYmMgKHVwIHRvIGFib3V0IDE5OTgtMTAtMDcpIGZhaWxlZCB0aGlz
IHRlc3QuICovCisgIHN0cnVjdCB0bSB0bTsKKworICAvKiBVc2UgdGhlIHBvcnRhYmxlIFBPU0lY
LjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIKKyAgICAgaW5zdGVh
ZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRldGVjdCB0aGUgYnVnIGV2
ZW4KKyAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhlIE9sc29uIGV4dGVuc2lv
biwgb3IgZG9uJ3QgaGF2ZSB0aGUKKyAgICAgZnVsbCB6b25laW5mbyB0YWJsZXMgaW5zdGFsbGVk
LiAgKi8KKyAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIik7CisK
KyAgdG0udG1feWVhciA9IDk4OworICB0bS50bV9tb24gPSAzOworICB0bS50bV9tZGF5ID0gNTsK
KyAgdG0udG1faG91ciA9IDI7CisgIHRtLnRtX21pbiA9IDA7CisgIHRtLnRtX3NlYyA9IDA7Cisg
IHRtLnRtX2lzZHN0ID0gLTE7CisgIHJldHVybiBta3RpbWUgKCZ0bSkgIT0gKHRpbWVfdCkgLTE7
Cit9CisKK3N0YXRpYyBpbnQKK21rdGltZV90ZXN0MSAodGltZV90IG5vdykKK3sKKyAgc3RydWN0
IHRtICpsdDsKKyAgcmV0dXJuICEgKGx0ID0gbG9jYWx0aW1lICgmbm93KSkgfHwgbWt0aW1lIChs
dCkgPT0gbm93OworfQorCitzdGF0aWMgaW50Citta3RpbWVfdGVzdCAodGltZV90IG5vdykKK3sK
KyAgcmV0dXJuIChta3RpbWVfdGVzdDEgKG5vdykKKwkgICYmIG1rdGltZV90ZXN0MSAoKHRpbWVf
dCkgKHRpbWVfdF9tYXggLSBub3cpKQorCSAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAodGlt
ZV90X21pbiArIG5vdykpKTsKK30KKworc3RhdGljIGludAoraXJpeF82XzRfYnVnICgpCit7Cisg
IC8qIEJhc2VkIG9uIGNvZGUgZnJvbSBBcmllbCBGYWlnb24uICAqLworICBzdHJ1Y3QgdG0gdG07
CisgIHRtLnRtX3llYXIgPSA5NjsKKyAgdG0udG1fbW9uID0gMzsKKyAgdG0udG1fbWRheSA9IDA7
CisgIHRtLnRtX2hvdXIgPSAwOworICB0bS50bV9taW4gPSAwOworICB0bS50bV9zZWMgPSAwOwor
ICB0bS50bV9pc2RzdCA9IC0xOworICBta3RpbWUgKCZ0bSk7CisgIHJldHVybiB0bS50bV9tb24g
PT0gMiAmJiB0bS50bV9tZGF5ID09IDMxOworfQorCitzdGF0aWMgaW50CitiaWd0aW1lX3Rlc3Qg
KGludCBqKQoreworICBzdHJ1Y3QgdG0gdG07CisgIHRpbWVfdCBub3c7CisgIHRtLnRtX3llYXIg
PSB0bS50bV9tb24gPSB0bS50bV9tZGF5ID0gdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRtLnRt
X3NlYyA9IGo7CisgIG5vdyA9IG1rdGltZSAoJnRtKTsKKyAgaWYgKG5vdyAhPSAodGltZV90KSAt
MSkKKyAgICB7CisgICAgICBzdHJ1Y3QgdG0gKmx0ID0gbG9jYWx0aW1lICgmbm93KTsKKyAgICAg
IGlmICghIChsdAorCSAgICAgJiYgbHQtPnRtX3llYXIgPT0gdG0udG1feWVhcgorCSAgICAgJiYg
bHQtPnRtX21vbiA9PSB0bS50bV9tb24KKwkgICAgICYmIGx0LT50bV9tZGF5ID09IHRtLnRtX21k
YXkKKwkgICAgICYmIGx0LT50bV9ob3VyID09IHRtLnRtX2hvdXIKKwkgICAgICYmIGx0LT50bV9t
aW4gPT0gdG0udG1fbWluCisJICAgICAmJiBsdC0+dG1fc2VjID09IHRtLnRtX3NlYworCSAgICAg
JiYgbHQtPnRtX3lkYXkgPT0gdG0udG1feWRheQorCSAgICAgJiYgbHQtPnRtX3dkYXkgPT0gdG0u
dG1fd2RheQorCSAgICAgJiYgKChsdC0+dG1faXNkc3QgPCAwID8gLTEgOiAwIDwgbHQtPnRtX2lz
ZHN0KQorCQkgID09ICh0bS50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCB0bS50bV9pc2RzdCkpKSkK
KwlyZXR1cm4gMDsKKyAgICB9CisgIHJldHVybiAxOworfQorCitzdGF0aWMgaW50Cit5ZWFyXzIw
NTBfdGVzdCAoKQoreworICAvKiBUaGUgY29ycmVjdCBhbnN3ZXIgZm9yIDIwNTAtMDItMDEgMDA6
MDA6MDAgaW4gUGFjaWZpYyB0aW1lLAorICAgICBpZ25vcmluZyBsZWFwIHNlY29uZHMuICAqLwor
ICB1bnNpZ25lZCBsb25nIGludCBhbnN3ZXIgPSAyNTI3MzE1MjAwVUw7CisKKyAgc3RydWN0IHRt
IHRtOworICB0aW1lX3QgdDsKKyAgdG0udG1feWVhciA9IDIwNTAgLSAxOTAwOworICB0bS50bV9t
b24gPSAyIC0gMTsKKyAgdG0udG1fbWRheSA9IDE7CisgIHRtLnRtX2hvdXIgPSB0bS50bV9taW4g
PSB0bS50bV9zZWMgPSAwOworICB0bS50bV9pc2RzdCA9IC0xOworCisgIC8qIFVzZSB0aGUgcG9y
dGFibGUgUE9TSVguMSBzcGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIgor
ICAgICBpbnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0ZWN0
IHRoZSBidWcgZXZlbgorICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xz
b24gZXh0ZW5zaW9uLCBvciBkb24ndCBoYXZlIHRoZQorICAgICBmdWxsIHpvbmVpbmZvIHRhYmxl
cyBpbnN0YWxsZWQuICAqLworICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0x
MC41LjAiKTsKKworICB0ID0gbWt0aW1lICgmdG0pOworCisgIC8qIENoZWNrIHRoYXQgdGhlIHJl
c3VsdCBpcyBlaXRoZXIgYSBmYWlsdXJlLCBvciBjbG9zZSBlbm91Z2gKKyAgICAgdG8gdGhlIGNv
cnJlY3QgYW5zd2VyIHRoYXQgd2UgY2FuIGFzc3VtZSB0aGUgZGlzY3JlcGFuY3kgaXMKKyAgICAg
ZHVlIHRvIGxlYXAgc2Vjb25kcy4gICovCisgIHJldHVybiAodCA9PSAodGltZV90KSAtMQorCSAg
fHwgKDAgPCB0ICYmIGFuc3dlciAtIDEyMCA8PSB0ICYmIHQgPD0gYW5zd2VyICsgMTIwKSk7Cit9
CisKK2ludAorbWFpbiAoKQoreworICB0aW1lX3QgdCwgZGVsdGE7CisgIGludCBpLCBqOworCisg
IC8qIFRoaXMgdGVzdCBtYWtlcyBzb21lIGJ1Z2d5IG1rdGltZSBpbXBsZW1lbnRhdGlvbnMgbG9v
cC4KKyAgICAgR2l2ZSB1cCBhZnRlciA2MCBzZWNvbmRzOyBhIG1rdGltZSBzbG93ZXIgdGhhbiB0
aGF0CisgICAgIGlzbid0IHdvcnRoIHVzaW5nIGFueXdheS4gICovCisgIGFsYXJtICg2MCk7CisK
KyAgZm9yICg7OykKKyAgICB7CisgICAgICB0ID0gKHRpbWVfdF9tYXggPDwgMSkgKyAxOworICAg
ICAgaWYgKHQgPD0gdGltZV90X21heCkKKwlicmVhazsKKyAgICAgIHRpbWVfdF9tYXggPSB0Owor
ICAgIH0KKyAgdGltZV90X21pbiA9IC0gKCh0aW1lX3QpIH4gKHRpbWVfdCkgMCA9PSAodGltZV90
KSAtMSkgLSB0aW1lX3RfbWF4OworCisgIGRlbHRhID0gdGltZV90X21heCAvIDk5NzsgLyogYSBz
dWl0YWJsZSBwcmltZSBudW1iZXIgKi8KKyAgZm9yIChpID0gMDsgaSA8IE5fU1RSSU5HUzsgaSsr
KQorICAgIHsKKyAgICAgIGlmICh0el9zdHJpbmdzW2ldKQorCXB1dGVudiAoKGNoYXIqKSB0el9z
dHJpbmdzW2ldKTsKKworICAgICAgZm9yICh0ID0gMDsgdCA8PSB0aW1lX3RfbWF4IC0gZGVsdGE7
IHQgKz0gZGVsdGEpCisJaWYgKCEgbWt0aW1lX3Rlc3QgKHQpKQorCSAgcmV0dXJuIDE7CisgICAg
ICBpZiAoISAobWt0aW1lX3Rlc3QgKCh0aW1lX3QpIDEpCisJICAgICAmJiBta3RpbWVfdGVzdCAo
KHRpbWVfdCkgKDYwICogNjApKQorCSAgICAgJiYgbWt0aW1lX3Rlc3QgKCh0aW1lX3QpICg2MCAq
IDYwICogMjQpKSkpCisJcmV0dXJuIDE7CisKKyAgICAgIGZvciAoaiA9IDE7IDsgaiA8PD0gMSkK
KwlpZiAoISBiaWd0aW1lX3Rlc3QgKGopKQorCSAgcmV0dXJuIDE7CisJZWxzZSBpZiAoSU5UX01B
WCAvIDIgPCBqKQorCSAgYnJlYWs7CisgICAgICBpZiAoISBiaWd0aW1lX3Rlc3QgKElOVF9NQVgp
KQorCXJldHVybiAxOworICAgIH0KKyAgcmV0dXJuICEgKGlyaXhfNl80X2J1ZyAoKSAmJiBzcHJp
bmdfZm9yd2FyZF9nYXAgKCkgJiYgeWVhcl8yMDUwX3Rlc3QgKCkpOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY193b3JraW5nX21r
dGltZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubworZmkKK3JtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfd29ya2lu
Z19ta3RpbWUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBta3RpbWUu
JGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIG1rdGltZS4kYWNfb2Jq
ZXh0IgorIDs7Citlc2FjCisKK2ZpCisKKworCisKKworCitmb3IgYWNfZnVuYyBpbiBnZXRwYWdl
c2l6ZQorZG8gOgorICBhY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJnZXRwYWdlc2l6ZSIg
ImFjX2N2X2Z1bmNfZ2V0cGFnZXNpemUiCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZ2V0cGFnZXNp
emUiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUg
SEFWRV9HRVRQQUdFU0laRSAxCitfQUNFT0YKKworZmkKK2RvbmUKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBtbWFwIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0g
eWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD1ubworZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAorLyogbWFsbG9jIG1pZ2h0IGhhdmUgYmVl
biByZW5hbWVkIGFzIHJwbF9tYWxsb2MuICovCisjdW5kZWYgbWFsbG9jCisKKy8qIFRoYW5rcyB0
byBNaWtlIEhhZXJ0ZWwgYW5kIEppbSBBdmVyYSBmb3IgdGhpcyB0ZXN0LgorICAgSGVyZSBpcyBh
IG1hdHJpeCBvZiBtbWFwIHBvc3NpYmlsaXRpZXM6CisJbW1hcCBwcml2YXRlIG5vdCBmaXhlZAor
CW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgY3VycmVudGx5IHVubWFwcGVkCisJbW1h
cCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJlYWR5IG1hcHBlZAorCW1tYXAgc2hhcmVk
IG5vdCBmaXhlZAorCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5t
YXBwZWQKKwltbWFwIHNoYXJlZCBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKKyAg
IEZvciBwcml2YXRlIG1hcHBpbmdzLCB3ZSBzaG91bGQgdmVyaWZ5IHRoYXQgY2hhbmdlcyBjYW5u
b3QgYmUgcmVhZCgpCisgICBiYWNrIGZyb20gdGhlIGZpbGUsIG5vciBtbWFwJ3MgYmFjayBmcm9t
IHRoZSBmaWxlIGF0IGEgZGlmZmVyZW50CisgICBhZGRyZXNzLiAgKFRoZXJlIGhhdmUgYmVlbiBz
eXN0ZW1zIHdoZXJlIHByaXZhdGUgd2FzIG5vdCBjb3JyZWN0bHkKKyAgIGltcGxlbWVudGVkIGxp
a2UgdGhlIGluZmFtb3VzIGkzODYgc3ZyNC4wLCBhbmQgc3lzdGVtcyB3aGVyZSB0aGUKKyAgIFZN
IHBhZ2UgY2FjaGUgd2FzIG5vdCBjb2hlcmVudCB3aXRoIHRoZSBmaWxlIHN5c3RlbSBidWZmZXIg
Y2FjaGUKKyAgIGxpa2UgZWFybHkgdmVyc2lvbnMgb2YgRnJlZUJTRCBhbmQgcG9zc2libHkgY29u
dGVtcG9yYXJ5IE5ldEJTRC4pCisgICBGb3Igc2hhcmVkIG1hcHBpbmdzLCB3ZSBzaG91bGQgY29u
dmVyc2VseSB2ZXJpZnkgdGhhdCBjaGFuZ2VzIGdldAorICAgcHJvcGFnYXRlZCBiYWNrIHRvIGFs
bCB0aGUgcGxhY2VzIHRoZXkncmUgc3VwcG9zZWQgdG8gYmUuCisKKyAgIEdyZXAgd2FudHMgcHJp
dmF0ZSBmaXhlZCBhbHJlYWR5IG1hcHBlZC4KKyAgIFRoZSBtYWluIHRoaW5ncyBncmVwIG5lZWRz
IHRvIGtub3cgYWJvdXQgbW1hcCBhcmU6CisgICAqIGRvZXMgaXQgZXhpc3QgYW5kIGlzIGl0IHNh
ZmUgdG8gd3JpdGUgaW50byB0aGUgbW1hcCdkIGFyZWEKKyAgICogaG93IHRvIHVzZSBpdCAoQlNE
IHZhcmlhbnRzKSAgKi8KKworI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5jbHVkZSA8c3lzL21tYW4u
aD4KKworI2lmICFkZWZpbmVkIFNURENfSEVBREVSUyAmJiAhZGVmaW5lZCBIQVZFX1NURExJQl9I
CitjaGFyICptYWxsb2MgKCk7CisjZW5kaWYKKworLyogVGhpcyBtZXNzIHdhcyBjb3BpZWQgZnJv
bSB0aGUgR05VIGdldHBhZ2VzaXplLmguICAqLworI2lmbmRlZiBIQVZFX0dFVFBBR0VTSVpFCisj
IGlmZGVmIF9TQ19QQUdFU0laRQorIyAgZGVmaW5lIGdldHBhZ2VzaXplKCkgc3lzY29uZihfU0Nf
UEFHRVNJWkUpCisjIGVsc2UgLyogbm8gX1NDX1BBR0VTSVpFICovCisjICBpZmRlZiBIQVZFX1NZ
U19QQVJBTV9ICisjICAgaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjICAgaWZkZWYgRVhFQ19QQUdF
U0laRQorIyAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBFWEVDX1BBR0VTSVpFCisjICAgZWxzZSAv
KiBubyBFWEVDX1BBR0VTSVpFICovCisjICAgIGlmZGVmIE5CUEcKKyMgICAgIGRlZmluZSBnZXRw
YWdlc2l6ZSgpIE5CUEcgKiBDTFNJWkUKKyMgICAgIGlmbmRlZiBDTFNJWkUKKyMgICAgICBkZWZp
bmUgQ0xTSVpFIDEKKyMgICAgIGVuZGlmIC8qIG5vIENMU0laRSAqLworIyAgICBlbHNlIC8qIG5v
IE5CUEcgKi8KKyMgICAgIGlmZGVmIE5CUEMKKyMgICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBO
QlBDCisjICAgICBlbHNlIC8qIG5vIE5CUEMgKi8KKyMgICAgICBpZmRlZiBQQUdFU0laRQorIyAg
ICAgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBQQUdFU0laRQorIyAgICAgIGVuZGlmIC8qIFBBR0VT
SVpFICovCisjICAgICBlbmRpZiAvKiBubyBOQlBDICovCisjICAgIGVuZGlmIC8qIG5vIE5CUEcg
Ki8KKyMgICBlbmRpZiAvKiBubyBFWEVDX1BBR0VTSVpFICovCisjICBlbHNlIC8qIG5vIEhBVkVf
U1lTX1BBUkFNX0ggKi8KKyMgICBkZWZpbmUgZ2V0cGFnZXNpemUoKSA4MTkyCS8qIHB1bnQgdG90
YWxseSAqLworIyAgZW5kaWYgLyogbm8gSEFWRV9TWVNfUEFSQU1fSCAqLworIyBlbmRpZiAvKiBu
byBfU0NfUEFHRVNJWkUgKi8KKworI2VuZGlmIC8qIG5vIEhBVkVfR0VUUEFHRVNJWkUgKi8KKwor
aW50CittYWluICgpCit7CisgIGNoYXIgKmRhdGEsICpkYXRhMiwgKmRhdGEzOworICBjb25zdCBj
aGFyICpjZGF0YTI7CisgIGludCBpLCBwYWdlc2l6ZTsKKyAgaW50IGZkLCBmZDI7CisKKyAgcGFn
ZXNpemUgPSBnZXRwYWdlc2l6ZSAoKTsKKworICAvKiBGaXJzdCwgbWFrZSBhIGZpbGUgd2l0aCBz
b21lIGtub3duIGdhcmJhZ2UgaW4gaXQuICovCisgIGRhdGEgPSAoY2hhciAqKSBtYWxsb2MgKHBh
Z2VzaXplKTsKKyAgaWYgKCFkYXRhKQorICAgIHJldHVybiAxOworICBmb3IgKGkgPSAwOyBpIDwg
cGFnZXNpemU7ICsraSkKKyAgICAqKGRhdGEgKyBpKSA9IHJhbmQgKCk7CisgIHVtYXNrICgwKTsK
KyAgZmQgPSBjcmVhdCAoImNvbmZ0ZXN0Lm1tYXAiLCAwNjAwKTsKKyAgaWYgKGZkIDwgMCkKKyAg
ICByZXR1cm4gMjsKKyAgaWYgKHdyaXRlIChmZCwgZGF0YSwgcGFnZXNpemUpICE9IHBhZ2VzaXpl
KQorICAgIHJldHVybiAzOworICBjbG9zZSAoZmQpOworCisgIC8qIE5leHQsIGNoZWNrIHRoYXQg
dGhlIHRhaWwgb2YgYSBwYWdlIGlzIHplcm8tZmlsbGVkLiAgRmlsZSBtdXN0IGhhdmUKKyAgICAg
bm9uLXplcm8gbGVuZ3RoLCBvdGhlcndpc2Ugd2UgcmlzayBTSUdCVVMgZm9yIGVudGlyZSBwYWdl
LiAgKi8KKyAgZmQyID0gb3BlbiAoImNvbmZ0ZXN0LnR4dCIsIE9fUkRXUiB8IE9fQ1JFQVQgfCBP
X1RSVU5DLCAwNjAwKTsKKyAgaWYgKGZkMiA8IDApCisgICAgcmV0dXJuIDQ7CisgIGNkYXRhMiA9
ICIiOworICBpZiAod3JpdGUgKGZkMiwgY2RhdGEyLCAxKSAhPSAxKQorICAgIHJldHVybiA1Owor
ICBkYXRhMiA9IChjaGFyICopIG1tYXAgKDAsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dS
SVRFLCBNQVBfU0hBUkVELCBmZDIsIDBMKTsKKyAgaWYgKGRhdGEyID09IE1BUF9GQUlMRUQpCisg
ICAgcmV0dXJuIDY7CisgIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgIGlmICgq
KGRhdGEyICsgaSkpCisgICAgICByZXR1cm4gNzsKKyAgY2xvc2UgKGZkMik7CisgIGlmIChtdW5t
YXAgKGRhdGEyLCBwYWdlc2l6ZSkpCisgICAgcmV0dXJuIDg7CisKKyAgLyogTmV4dCwgdHJ5IHRv
IG1tYXAgdGhlIGZpbGUgYXQgYSBmaXhlZCBhZGRyZXNzIHdoaWNoIGFscmVhZHkgaGFzCisgICAg
IHNvbWV0aGluZyBlbHNlIGFsbG9jYXRlZCBhdCBpdC4gIElmIHdlIGNhbiwgYWxzbyBtYWtlIHN1
cmUgdGhhdAorICAgICB3ZSBzZWUgdGhlIHNhbWUgZ2FyYmFnZS4gICovCisgIGZkID0gb3BlbiAo
ImNvbmZ0ZXN0Lm1tYXAiLCBPX1JEV1IpOworICBpZiAoZmQgPCAwKQorICAgIHJldHVybiA5Owor
ICBpZiAoZGF0YTIgIT0gbW1hcCAoZGF0YTIsIHBhZ2VzaXplLCBQUk9UX1JFQUQgfCBQUk9UX1dS
SVRFLAorCQkgICAgIE1BUF9QUklWQVRFIHwgTUFQX0ZJWEVELCBmZCwgMEwpKQorICAgIHJldHVy
biAxMDsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAgaWYgKCooZGF0YSAr
IGkpICE9ICooZGF0YTIgKyBpKSkKKyAgICAgIHJldHVybiAxMTsKKworICAvKiBGaW5hbGx5LCBt
YWtlIHN1cmUgdGhhdCBjaGFuZ2VzIHRvIHRoZSBtYXBwZWQgYXJlYSBkbyBub3QKKyAgICAgcGVy
Y29sYXRlIGJhY2sgdG8gdGhlIGZpbGUgYXMgc2VlbiBieSByZWFkKCkuICAoVGhpcyBpcyBhIGJ1
ZyBvbgorICAgICBzb21lIHZhcmlhbnRzIG9mIGkzODYgc3ZyNC4wLikgICovCisgIGZvciAoaSA9
IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgICooZGF0YTIgKyBpKSA9ICooZGF0YTIgKyBpKSAr
IDE7CisgIGRhdGEzID0gKGNoYXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7CisgIGlmICghZGF0YTMp
CisgICAgcmV0dXJuIDEyOworICBpZiAocmVhZCAoZmQsIGRhdGEzLCBwYWdlc2l6ZSkgIT0gcGFn
ZXNpemUpCisgICAgcmV0dXJuIDEzOworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkK
KyAgICBpZiAoKihkYXRhICsgaSkgIT0gKihkYXRhMyArIGkpKQorICAgICAgcmV0dXJuIDE0Owor
ICBjbG9zZSAoZmQpOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVu
ICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9eWVzCitl
bHNlCisgIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9bm8KK2ZpCitybSAtZiBjb3JlICou
Y29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBc
CisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0Citm
aQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVu
Y19tbWFwX2ZpeGVkX21hcHBlZCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX21tYXBfZml4
ZWRfbWFwcGVkID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfTU1BUCAxIiA+
PmNvbmZkZWZzLmgKKworZmkKK3JtIC1mIGNvbmZ0ZXN0Lm1tYXAgY29uZnRlc3QudHh0CisKK2Zv
ciBhY19oZWFkZXIgaW4gc3RkbGliLmgKK2RvIDoKKyAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9u
Z3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiAiJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgPSB4eWVz
OyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NURExJ
Ql9IIDEKK19BQ0VPRgorCitmaQorCitkb25lCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgcmVhbGxvYyIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSByZWFsbG9j
Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIk
Y3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25v
bm51bGw9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmIGRlZmluZWQgU1REQ19IRUFERVJTIHx8
IGRlZmluZWQgSEFWRV9TVERMSUJfSAorIyBpbmNsdWRlIDxzdGRsaWIuaD4KKyNlbHNlCitjaGFy
ICpyZWFsbG9jICgpOworI2VuZGlmCisKK2ludAorbWFpbiAoKQoreworcmV0dXJuICEgcmVhbGxv
YyAoMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPXllcwor
ZWxzZQorICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCitmaQorcm0gLWYgY29yZSAq
LmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQg
XAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAor
ZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1
bmNfcmVhbGxvY18wX25vbm51bGwiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19yZWFsbG9j
XzBfbm9ubnVsbCA9IHllczsgdGhlbiA6CisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfUkVBTExP
QyAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQorICAkYXNfZWNobyAiI2RlZmluZSBIQVZFX1JFQUxM
T0MgMCIgPj5jb25mZGVmcy5oCisKKyAgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIHJlYWxs
b2MuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIHJlYWxsb2MuJGFj
X29iamV4dCIKKyA7OworZXNhYworCisKKyRhc19lY2hvICIjZGVmaW5lIHJlYWxsb2MgcnBsX3Jl
YWxsb2MiID4+Y29uZmRlZnMuaAorCitmaQorCisKKyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4iID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3Rybmxlbi4uLiAiID4mNjsgfQoraWYgJHthY19j
dl9mdW5jX3N0cm5sZW5fd29ya2luZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKKyAgIyBHdWVzcyBubyBvbiBBSVggc3lzdGVtcywgeWVzIG90aGVyd2lzZS4KKwkJY2Fz
ZSAiJGhvc3Rfb3MiIGluCisJCSAgYWl4KikgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9bm87
OworCQkgICopICAgIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllczs7CisJCWVzYWMKK2Vs
c2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2ludAorbWFpbiAoKQorewor
CisjZGVmaW5lIFMgImZvb2JhciIKKyNkZWZpbmUgU19MRU4gKHNpemVvZiBTIC0gMSkKKworICAv
KiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYnVnZ3k6IHRoYXQgb2YgQUlYIDQuMyB3
b3VsZAorICAgICBnaXZlIHN0cm5sZW4gKFMsIDEpID09IDMuICAqLworCisgIGludCBpOworICBm
b3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyArK2kpCisgICAgeworICAgICAgaW50IGV4cGVjdGVk
ID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsKKyAgICAgIGlmIChzdHJubGVuIChTLCBpKSAhPSBl
eHBlY3RlZCkKKwlyZXR1cm4gMTsKKyAgICB9CisgIHJldHVybiAwOworCisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19zdHJubGVu
X3dvcmtpbmc9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5v
dXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29u
ZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu
ZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nIiA+JjY7IH0KK3Rl
c3QgJGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nID0gbm8gJiYgY2FzZSAiICRMSUJPQkpTICIg
aW4KKyAgKiIgc3Rybmxlbi4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9C
SlMgc3Rybmxlbi4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKKworeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBzdHJ0b2QiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9kLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X2Z1bmNfc3RydG9kKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g
OgorICBhY19jdl9mdW5jX3N0cnRvZD1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKyRhY19pbmNs
dWRlc19kZWZhdWx0CisjaWZuZGVmIHN0cnRvZAorZG91YmxlIHN0cnRvZCAoKTsKKyNlbmRpZgor
aW50CittYWluKCkKK3sKKyAgeworICAgIC8qIFNvbWUgdmVyc2lvbnMgb2YgTGludXggc3RydG9k
IG1pcy1wYXJzZSBzdHJpbmdzIHdpdGggbGVhZGluZyAnKycuICAqLworICAgIGNoYXIgKnN0cmlu
ZyA9ICIgKzY5IjsKKyAgICBjaGFyICp0ZXJtOworICAgIGRvdWJsZSB2YWx1ZTsKKyAgICB2YWx1
ZSA9IHN0cnRvZCAoc3RyaW5nLCAmdGVybSk7CisgICAgaWYgKHZhbHVlICE9IDY5IHx8IHRlcm0g
IT0gKHN0cmluZyArIDQpKQorICAgICAgcmV0dXJuIDE7CisgIH0KKworICB7CisgICAgLyogVW5k
ZXIgU29sYXJpcyAyLjQsIHN0cnRvZCByZXR1cm5zIHRoZSB3cm9uZyB2YWx1ZSBmb3IgdGhlCisg
ICAgICAgdGVybWluYXRpbmcgY2hhcmFjdGVyIHVuZGVyIHNvbWUgY29uZGl0aW9ucy4gICovCisg
ICAgY2hhciAqc3RyaW5nID0gIk5hTiI7CisgICAgY2hhciAqdGVybTsKKyAgICBzdHJ0b2QgKHN0
cmluZywgJnRlcm0pOworICAgIGlmICh0ZXJtICE9IHN0cmluZyAmJiAqKHRlcm0gLSAxKSA9PSAw
KQorICAgICAgcmV0dXJuIDE7CisgIH0KKyAgcmV0dXJuIDA7Cit9CisKK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfc3RydG9kPXllcwor
ZWxzZQorICBhY19jdl9mdW5jX3N0cnRvZD1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUu
Y29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1
bmNfc3RydG9kIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNjsgfQoraWYg
dGVzdCAkYWNfY3ZfZnVuY19zdHJ0b2QgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9CSlMgIiBp
bgorICAqIiBzdHJ0b2QuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpT
IHN0cnRvZC4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJ
TkVOTyIgInBvdyIgImFjX2N2X2Z1bmNfcG93IgoraWYgdGVzdCAieCRhY19jdl9mdW5jX3BvdyIg
PSB4eWVzOyB0aGVuIDoKKworZmkKKworaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBubzsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBwb3cgaW4gLWxtIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBwb3cgaW4gLWxtLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9tX3Bvdys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJ
QlMKK0xJQlM9Ii1sbSAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0Mg
aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVz
ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFu
ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lm
ZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgcG93ICgpOworaW50Citt
YWluICgpCit7CityZXR1cm4gcG93ICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9tX3Bvdz15
ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX21fcG93PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0
LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9tX3BvdyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2xpYl9tX3BvdyIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9tX3BvdyIgPSB4eWVzOyB0aGVuIDoKKyAgUE9XX0xJQj0tbG0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJy
YXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mNQorJGFzX2VjaG8gIiRhc19tZTog
V0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRlZmluaXRpb24gb2YgcG93
IiA+JjI7fQorZmkKKworZmkKKworZmkKKworZm9yIGFjX2Z1bmMgaW4gIFwKKyAgICAgICAgICAg
ICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3luYyBmdHJ1
bmNhdGUgXAorICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhvc3RuYW1l
IGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAgaW5ldF9udG9hIGlz
YXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKKyAgICAgICAg
ICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2Vs
ZWN0IHNldGVudiBcCisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3RyY2hyIHN0
cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAgICAgIHN0cnBicmsg
c3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0IFwKKyAg
ICAgICAgICAgICAgICB1bmFtZSBcCisKK2RvIDoKKyAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNf
Y3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5F
Tk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3Zh
ciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZp
bmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitm
aQorZG9uZQorCisKK2NhdCA+Y29uZmNhY2hlIDw8XF9BQ0VPRgorIyBUaGlzIGZpbGUgaXMgYSBz
aGVsbCBzY3JpcHQgdGhhdCBjYWNoZXMgdGhlIHJlc3VsdHMgb2YgY29uZmlndXJlCisjIHRlc3Rz
IHJ1biBvbiB0aGlzIHN5c3RlbSBzbyB0aGV5IGNhbiBiZSBzaGFyZWQgYmV0d2VlbiBjb25maWd1
cmUKKyMgc2NyaXB0cyBhbmQgY29uZmlndXJlIHJ1bnMsIHNlZSBjb25maWd1cmUncyBvcHRpb24g
LS1jb25maWctY2FjaGUuCisjIEl0IGlzIG5vdCB1c2VmdWwgb24gb3RoZXIgc3lzdGVtcy4gIElm
IGl0IGNvbnRhaW5zIHJlc3VsdHMgeW91IGRvbid0CisjIHdhbnQgdG8ga2VlcCwgeW91IG1heSBy
ZW1vdmUgb3IgZWRpdCBpdC4KKyMKKyMgY29uZmlnLnN0YXR1cyBvbmx5IHBheXMgYXR0ZW50aW9u
IHRvIHRoZSBjYWNoZSBmaWxlIGlmIHlvdSBnaXZlIGl0CisjIHRoZSAtLXJlY2hlY2sgb3B0aW9u
IHRvIHJlcnVuIGNvbmZpZ3VyZS4KKyMKKyMgYGFjX2N2X2Vudl9mb28nIHZhcmlhYmxlcyAoc2V0
IG9yIHVuc2V0KSB3aWxsIGJlIG92ZXJyaWRkZW4gd2hlbgorIyBsb2FkaW5nIHRoaXMgZmlsZSwg
b3RoZXIgKnVuc2V0KiBgYWNfY3ZfZm9vJyB3aWxsIGJlIGFzc2lnbmVkIHRoZQorIyBmb2xsb3dp
bmcgdmFsdWVzLgorCitfQUNFT0YKKworIyBUaGUgZm9sbG93aW5nIHdheSBvZiB3cml0aW5nIHRo
ZSBjYWNoZSBtaXNoYW5kbGVzIG5ld2xpbmVzIGluIHZhbHVlcywKKyMgYnV0IHdlIGtub3cgb2Yg
bm8gd29ya2Fyb3VuZCB0aGF0IGlzIHNpbXBsZSwgcG9ydGFibGUsIGFuZCBlZmZpY2llbnQuCisj
IFNvLCB3ZSBraWxsIHZhcmlhYmxlcyBjb250YWluaW5nIG5ld2xpbmVzLgorIyBVbHRyaXggc2gg
c2V0IHdyaXRlcyB0byBzdGRlcnIgYW5kIGNhbid0IGJlIHJlZGlyZWN0ZWQgZGlyZWN0bHksCisj
IGFuZCBzZXRzIHRoZSBoaWdoIGJpdCBpbiB0aGUgY2FjaGUgZmlsZSB1bmxlc3Mgd2UgYXNzaWdu
IHRvIHRoZSB2YXJzLgorKAorICBmb3IgYWNfdmFyIGluIGAoc2V0KSAyPiYxIHwgc2VkIC1uICdz
L15cKFthLXpBLVpfXVthLXpBLVowLTlfXSpcKT0uKi9cMS9wJ2A7IGRvCisgICAgZXZhbCBhY192
YWw9XCQkYWNfdmFyCisgICAgY2FzZSAkYWNfdmFsIGluICMoCisgICAgKiR7YXNfbmx9KikKKyAg
ICAgIGNhc2UgJGFjX3ZhciBpbiAjKAorICAgICAgKl9jdl8qKSB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IGNhY2hlIHZhcmlhYmxlICRhY192YXIgY29u
dGFpbnMgYSBuZXdsaW5lIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IGNhY2hlIHZh
cmlhYmxlICRhY192YXIgY29udGFpbnMgYSBuZXdsaW5lIiA+JjI7fSA7OworICAgICAgZXNhYwor
ICAgICAgY2FzZSAkYWNfdmFyIGluICMoCisgICAgICBfIHwgSUZTIHwgYXNfbmwpIDs7ICMoCisg
ICAgICBCQVNIX0FSR1YgfCBCQVNIX1NPVVJDRSkgZXZhbCAkYWNfdmFyPSA7OyAjKAorICAgICAg
KikgeyBldmFsICRhY192YXI9OyB1bnNldCAkYWNfdmFyO30gOzsKKyAgICAgIGVzYWMgOzsKKyAg
ICBlc2FjCisgIGRvbmUKKworICAoc2V0KSAyPiYxIHwKKyAgICBjYXNlICRhc19ubGAoYWNfc3Bh
Y2U9JyAnOyBzZXQpIDI+JjFgIGluICMoCisgICAgKiR7YXNfbmx9YWNfc3BhY2U9XCAqKQorICAg
ICAgIyBgc2V0JyBkb2VzIG5vdCBxdW90ZSBjb3JyZWN0bHksIHNvIGFkZCBxdW90ZXM6IGRvdWJs
ZS1xdW90ZQorICAgICAgIyBzdWJzdGl0dXRpb24gdHVybnMgXFxcXCBpbnRvIFxcLCBhbmQgc2Vk
IHR1cm5zIFxcIGludG8gXC4KKyAgICAgIHNlZCAtbiBcCisJInMvJy8nXFxcXCcnL2c7CisJICBz
L15cXChbXyRhc19jcl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSpcXCk9XFwoLipcXCkvXFwx
PSdcXDInL3AiCisgICAgICA7OyAjKAorICAgICopCisgICAgICAjIGBzZXQnIHF1b3RlcyBjb3Jy
ZWN0bHkgYXMgcmVxdWlyZWQgYnkgUE9TSVgsIHNvIGRvIG5vdCBhZGQgcXVvdGVzLgorICAgICAg
c2VkIC1uICIvXltfJGFzX2NyX2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKj0vcCIKKyAgICAg
IDs7CisgICAgZXNhYyB8CisgICAgc29ydAorKSB8CisgIHNlZCAnCisgICAgIC9eYWNfY3ZfZW52
Xy9iIGVuZAorICAgICB0IGNsZWFyCisgICAgIDpjbGVhcgorICAgICBzL15cKFtePV0qXCk9XCgu
Klt7fV0uKlwpJC90ZXN0ICIke1wxK3NldH0iID0gc2V0IHx8ICYvCisgICAgIHQgZW5kCisgICAg
IHMvXlwoW149XSpcKT1cKC4qXCkkL1wxPSR7XDE9XDJ9LworICAgICA6ZW5kJyA+PmNvbmZjYWNo
ZQoraWYgZGlmZiAiJGNhY2hlX2ZpbGUiIGNvbmZjYWNoZSA+L2Rldi9udWxsIDI+JjE7IHRoZW4g
OjsgZWxzZQorICBpZiB0ZXN0IC13ICIkY2FjaGVfZmlsZSI7IHRoZW4KKyAgICBpZiB0ZXN0ICJ4
JGNhY2hlX2ZpbGUiICE9ICJ4L2Rldi9udWxsIjsgdGhlbgorICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiB1cGRhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY1
CiskYXNfZWNobyAiJGFzX21lOiB1cGRhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAg
ICAgIGlmIHRlc3QgISAtZiAiJGNhY2hlX2ZpbGUiIHx8IHRlc3QgLWggIiRjYWNoZV9maWxlIjsg
dGhlbgorCWNhdCBjb25mY2FjaGUgPiIkY2FjaGVfZmlsZSIKKyAgICAgIGVsc2UKKyAgICAgICAg
Y2FzZSAkY2FjaGVfZmlsZSBpbiAjKAorICAgICAgICAqLyogfCA/OiopCisJICBtdiAtZiBjb25m
Y2FjaGUgIiRjYWNoZV9maWxlIiQkICYmCisJICBtdiAtZiAiJGNhY2hlX2ZpbGUiJCQgIiRjYWNo
ZV9maWxlIiA7OyAjKAorICAgICAgICAqKQorCSAgbXYgLWYgY29uZmNhY2hlICIkY2FjaGVfZmls
ZSIgOzsKKwllc2FjCisgICAgICBmaQorICAgIGZpCisgIGVsc2UKKyAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IG5vdCB1cGRhdGluZyB1bndyaXRhYmxlIGNhY2hl
ICRjYWNoZV9maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IG5vdCB1cGRhdGluZyB1bndyaXRh
YmxlIGNhY2hlICRjYWNoZV9maWxlIiA+JjY7fQorICBmaQorZmkKK3JtIC1mIGNvbmZjYWNoZQor
Cit0ZXN0ICJ4JHByZWZpeCIgPSB4Tk9ORSAmJiBwcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4Cisj
IExldCBtYWtlIGV4cGFuZCBleGVjX3ByZWZpeC4KK3Rlc3QgIngkZXhlY19wcmVmaXgiID0geE5P
TkUgJiYgZXhlY19wcmVmaXg9JyR7cHJlZml4fScKKworREVGUz0tREhBVkVfQ09ORklHX0gKKwor
YWNfbGlib2Jqcz0KK2FjX2x0bGlib2Jqcz0KK1U9Citmb3IgYWNfaSBpbiA6ICRMSUJPQkpTOyBk
byB0ZXN0ICJ4JGFjX2kiID0geDogJiYgY29udGludWUKKyAgIyAxLiBSZW1vdmUgdGhlIGV4dGVu
c2lvbiwgYW5kICRVIGlmIGFscmVhZHkgaW5zdGFsbGVkLgorICBhY19zY3JpcHQ9J3MvXCRVXC4v
Li87cy9cLm8kLy87cy9cLm9iaiQvLycKKyAgYWNfaT1gJGFzX2VjaG8gIiRhY19pIiB8IHNlZCAi
JGFjX3NjcmlwdCJgCisgICMgMi4gUHJlcGVuZCBMSUJPQkpESVIuICBXaGVuIHVzZWQgd2l0aCBh
dXRvbWFrZT49MS4xMCBMSUJPQkpESVIKKyAgIyAgICB3aWxsIGJlIHNldCB0byB0aGUgZGlyZWN0
b3J5IHdoZXJlIExJQk9CSlMgb2JqZWN0cyBhcmUgYnVpbHQuCisgIGFzX2ZuX2FwcGVuZCBhY19s
aWJvYmpzICIgXCR7TElCT0JKRElSfSRhY19pXCRVLiRhY19vYmpleHQiCisgIGFzX2ZuX2FwcGVu
ZCBhY19sdGxpYm9ianMgIiBcJHtMSUJPQkpESVJ9JGFjX2kiJyRVLmxvJworZG9uZQorTElCT0JK
Uz0kYWNfbGlib2JqcworCitMVExJQk9CSlM9JGFjX2x0bGlib2JqcworCisKKworOiAiJHtDT05G
SUdfU1RBVFVTPS4vY29uZmlnLnN0YXR1c30iCithY193cml0ZV9mYWlsPTAKK2FjX2NsZWFuX2Zp
bGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCithY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVz
ICRDT05GSUdfU1RBVFVTIgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBjcmVhdGlu
ZyAkQ09ORklHX1NUQVRVUyIgPiY2O30KK2FzX3dyaXRlX2ZhaWw9MAorY2F0ID4kQ09ORklHX1NU
QVRVUyA8PF9BU0VPRiB8fCBhc193cml0ZV9mYWlsPTEKKyMhICRTSEVMTAorIyBHZW5lcmF0ZWQg
YnkgJGFzX21lLgorIyBSdW4gdGhpcyBmaWxlIHRvIHJlY3JlYXRlIHRoZSBjdXJyZW50IGNvbmZp
Z3VyYXRpb24uCisjIENvbXBpbGVyIG91dHB1dCBwcm9kdWNlZCBieSBjb25maWd1cmUsIHVzZWZ1
bCBmb3IgZGVidWdnaW5nCisjIGNvbmZpZ3VyZSwgaXMgaW4gY29uZmlnLmxvZyBpZiBpdCBleGlz
dHMuCisKK2RlYnVnPWZhbHNlCithY19jc19yZWNoZWNrPWZhbHNlCithY19jc19zaWxlbnQ9ZmFs
c2UKKworU0hFTEw9XCR7Q09ORklHX1NIRUxMLSRTSEVMTH0KK2V4cG9ydCBTSEVMTAorX0FTRU9G
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQVNFT0YgfHwgYXNfd3JpdGVfZmFpbD0xCisjIyAt
LS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTTRzaCBJbml0aWFsaXphdGlvbi4gIyMKKyMjIC0t
LS0tLS0tLS0tLS0tLS0tLS0tICMjCisKKyMgQmUgbW9yZSBCb3VybmUgY29tcGF0aWJsZQorRFVB
TENBU0U9MTsgZXhwb3J0IERVQUxDQVNFICMgZm9yIE1LUyBzaAoraWYgdGVzdCAtbiAiJHtaU0hf
VkVSU0lPTitzZXR9IiAmJiAoZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAg
ZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3
b3JkIHNwbGl0dGluZyBvbiAkezErIiRAIn0sIHdoaWNoCisgICMgaXMgY29udHJhcnkgdG8gb3Vy
IHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1nICckezErIiRAIn0nPSci
JEAiJworICBzZXRvcHQgTk9fR0xPQl9TVUJTVAorZWxzZQorICBjYXNlIGAoc2V0IC1vKSAyPi9k
ZXYvbnVsbGAgaW4gIygKKyAgKnBvc2l4KikgOgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAq
KSA6CisgICAgIDs7Citlc2FjCitmaQorCisKK2FzX25sPScKKycKK2V4cG9ydCBhc19ubAorIyBQ
cmludGluZyBhIGxvbmcgc3RyaW5nIGNyYXNoZXMgU29sYXJpcyA3IC91c3IvYmluL3ByaW50Zi4K
K2FzX2VjaG89J1xcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFwn
Cithc19lY2hvPSRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8KK2FzX2Vj
aG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCisjIFBy
ZWZlciBhIGtzaCBzaGVsbCBidWlsdGluIG92ZXIgYW4gZXh0ZXJuYWwgcHJpbnRmIHByb2dyYW0g
b24gU29sYXJpcywKKyMgYnV0IHdpdGhvdXQgd2FzdGluZyBmb3JrcyBmb3IgYmFzaCBvciB6c2gu
CitpZiB0ZXN0IC16ICIkQkFTSF9WRVJTSU9OJFpTSF9WRVJTSU9OIiBcCisgICAgJiYgKHRlc3Qg
IlhgcHJpbnQgLXIgLS0gJGFzX2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9kZXYvbnVsbDsgdGhl
bgorICBhc19lY2hvPSdwcmludCAtciAtLScKKyAgYXNfZWNob19uPSdwcmludCAtcm4gLS0nCitl
bGlmICh0ZXN0ICJYYHByaW50ZiAlcyAkYXNfZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9u
dWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50ZiAlc1xuJworICBhc19lY2hvX249J3ByaW50ZiAl
cycKK2Vsc2UKKyAgaWYgdGVzdCAiWGAoL3Vzci91Y2IvZWNobyAtbiAtbiAkYXNfZWNobykgMj4v
ZGV2L251bGxgIiA9ICJYLW4gJGFzX2VjaG8iOyB0aGVuCisgICAgYXNfZWNob19ib2R5PSdldmFs
IC91c3IvdWNiL2VjaG8gLW4gIiQxJGFzX25sIicKKyAgICBhc19lY2hvX249Jy91c3IvdWNiL2Vj
aG8gLW4nCisgIGVsc2UKKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgZXhwciAiWCQxIiA6ICJYXFwo
LipcXCkiJworICAgIGFzX2VjaG9fbl9ib2R5PSdldmFsCisgICAgICBhcmc9JDE7CisgICAgICBj
YXNlICRhcmcgaW4gIygKKyAgICAgICoiJGFzX25sIiopCisJZXhwciAiWCRhcmciIDogIlhcXCgu
KlxcKSRhc19ubCI7CisJYXJnPWBleHByICJYJGFyZyIgOiAiLiokYXNfbmxcXCguKlxcKSJgOzsK
KyAgICAgIGVzYWM7CisgICAgICBleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpIiB8IHRyIC1kICIk
YXNfbmwiCisgICAgJworICAgIGV4cG9ydCBhc19lY2hvX25fYm9keQorICAgIGFzX2VjaG9fbj0n
c2ggLWMgJGFzX2VjaG9fbl9ib2R5IGFzX2VjaG8nCisgIGZpCisgIGV4cG9ydCBhc19lY2hvX2Jv
ZHkKKyAgYXNfZWNobz0nc2ggLWMgJGFzX2VjaG9fYm9keSBhc19lY2hvJworZmkKKworIyBUaGUg
dXNlciBpcyBhbHdheXMgcmlnaHQuCitpZiB0ZXN0ICIke1BBVEhfU0VQQVJBVE9SK3NldH0iICE9
IHNldDsgdGhlbgorICBQQVRIX1NFUEFSQVRPUj06CisgIChQQVRIPScvYmluOy9iaW4nOyBGUEFU
SD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVsbCAyPiYxICYmIHsKKyAgICAoUEFUSD0nL2Jpbjov
YmluJzsgRlBBVEg9JFBBVEg7IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSB8fAorICAgICAgUEFU
SF9TRVBBUkFUT1I9JzsnCisgIH0KK2ZpCisKKworIyBJRlMKKyMgV2UgbmVlZCBzcGFjZSwgdGFi
IGFuZCBuZXcgbGluZSwgaW4gcHJlY2lzZWx5IHRoYXQgb3JkZXIuICBRdW90aW5nIGlzCisjIHRo
ZXJlIHRvIHByZXZlbnQgZWRpdG9ycyBmcm9tIGNvbXBsYWluaW5nIGFib3V0IHNwYWNlLXRhYi4K
KyMgKElmIF9BU19QQVRIX1dBTEsgd2VyZSBjYWxsZWQgd2l0aCBJRlMgdW5zZXQsIGl0IHdvdWxk
IGRpc2FibGUgd29yZAorIyBzcGxpdHRpbmcgYnkgc2V0dGluZyBJRlMgdG8gZW1wdHkgdmFsdWUu
KQorSUZTPSIgIiIJJGFzX25sIgorCisjIEZpbmQgd2hvIHdlIGFyZS4gIExvb2sgaW4gdGhlIHBh
dGggaWYgd2UgY29udGFpbiBubyBkaXJlY3Rvcnkgc2VwYXJhdG9yLgorYXNfbXlzZWxmPQorY2Fz
ZSAkMCBpbiAjKCgKKyAgKltcXC9dKiApIGFzX215c2VsZj0kMCA7OworICAqKSBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgdGVz
dCAtciAiJGFzX2Rpci8kMCIgJiYgYXNfbXlzZWxmPSRhc19kaXIvJDAgJiYgYnJlYWsKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgICAgIDs7Citlc2FjCisjIFdlIGRpZCBub3QgZmluZCBv
dXJzZWx2ZXMsIG1vc3QgcHJvYmFibHkgd2Ugd2VyZSBydW4gYXMgYHNoIENPTU1BTkQnCisjIGlu
IHdoaWNoIGNhc2Ugd2UgYXJlIG5vdCB0byBiZSBmb3VuZCBpbiB0aGUgcGF0aC4KK2lmIHRlc3Qg
IngkYXNfbXlzZWxmIiA9IHg7IHRoZW4KKyAgYXNfbXlzZWxmPSQwCitmaQoraWYgdGVzdCAhIC1m
ICIkYXNfbXlzZWxmIjsgdGhlbgorICAkYXNfZWNobyAiJGFzX215c2VsZjogZXJyb3I6IGNhbm5v
dCBmaW5kIG15c2VsZjsgcmVydW4gd2l0aCBhbiBhYnNvbHV0ZSBmaWxlIG5hbWUiID4mMgorICBl
eGl0IDEKK2ZpCisKKyMgVW5zZXQgdmFyaWFibGVzIHRoYXQgd2UgZG8gbm90IG5lZWQgYW5kIHdo
aWNoIGNhdXNlIGJ1Z3MgKGUuZy4gaW4KKyMgcHJlLTMuMCBVV0lOIGtzaCkuICBCdXQgZG8gbm90
IGNhdXNlIGJ1Z3MgaW4gYmFzaCAyLjAxOyB0aGUgInx8IGV4aXQgMSIKKyMgc3VwcHJlc3NlcyBh
bnkgIlNlZ21lbnRhdGlvbiBmYXVsdCIgbWVzc2FnZSB0aGVyZS4gICcoKCcgY291bGQKKyMgdHJp
Z2dlciBhIGJ1ZyBpbiBwZGtzaCA1LjIuMTQuCitmb3IgYXNfdmFyIGluIEJBU0hfRU5WIEVOViBN
QUlMIE1BSUxQQVRICitkbyBldmFsIHRlc3QgeFwkeyRhc192YXIrc2V0fSA9IHhzZXQgXAorICAm
JiAoICh1bnNldCAkYXNfdmFyKSB8fCBleGl0IDEpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCAk
YXNfdmFyIHx8IDoKK2RvbmUKK1BTMT0nJCAnCitQUzI9Jz4gJworUFM0PScrICcKKworIyBOTFMg
bnVpc2FuY2VzLgorTENfQUxMPUMKK2V4cG9ydCBMQ19BTEwKK0xBTkdVQUdFPUMKK2V4cG9ydCBM
QU5HVUFHRQorCisjIENEUEFUSC4KKyh1bnNldCBDRFBBVEgpID4vZGV2L251bGwgMj4mMSAmJiB1
bnNldCBDRFBBVEgKKworCisjIGFzX2ZuX2Vycm9yIFNUQVRVUyBFUlJPUiBbTElORU5PIExPR19G
RF0KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBPdXRwdXQg
ImBiYXNlbmFtZSAkMGA6IGVycm9yOiBFUlJPUiIgdG8gc3RkZXJyLiBJZiBMSU5FTk8gYW5kIExP
R19GRCBhcmUKKyMgcHJvdmlkZWQsIGFsc28gb3V0cHV0IHRoZSBlcnJvciB0byBMT0dfRkQsIHJl
ZmVyZW5jaW5nIExJTkVOTy4gVGhlbiBleGl0IHRoZQorIyBzY3JpcHQgd2l0aCBTVEFUVVMsIHVz
aW5nIDEgaWYgdGhhdCB3YXMgMC4KK2FzX2ZuX2Vycm9yICgpCit7CisgIGFzX3N0YXR1cz0kMTsg
dGVzdCAkYXNfc3RhdHVzIC1lcSAwICYmIGFzX3N0YXR1cz0xCisgIGlmIHRlc3QgIiQ0IjsgdGhl
bgorICAgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDMifSBhc19saW5lbm9fc3RhY2s9YXNfbGlu
ZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBlcnJvcjogJDIiID4mJDQKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZTog
ZXJyb3I6ICQyIiA+JjIKKyAgYXNfZm5fZXhpdCAkYXNfc3RhdHVzCit9ICMgYXNfZm5fZXJyb3IK
KworCisjIGFzX2ZuX3NldF9zdGF0dXMgU1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CisjIFNldCAkPyB0byBTVEFUVVMsIHdpdGhvdXQgZm9ya2luZy4KK2FzX2ZuX3NldF9zdGF0dXMg
KCkKK3sKKyAgcmV0dXJuICQxCit9ICMgYXNfZm5fc2V0X3N0YXR1cworCisjIGFzX2ZuX2V4aXQg
U1RBVFVTCisjIC0tLS0tLS0tLS0tLS0tLS0tCisjIEV4aXQgdGhlIHNoZWxsIHdpdGggU1RBVFVT
LCBldmVuIGluIGEgInRyYXAgMCIgb3IgInNldCAtZSIgY29udGV4dC4KK2FzX2ZuX2V4aXQgKCkK
K3sKKyAgc2V0ICtlCisgIGFzX2ZuX3NldF9zdGF0dXMgJDEKKyAgZXhpdCAkMQorfSAjIGFzX2Zu
X2V4aXQKKworIyBhc19mbl91bnNldCBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tCisjIFBvcnRhYmx5
IHVuc2V0IFZBUi4KK2FzX2ZuX3Vuc2V0ICgpCit7CisgIHsgZXZhbCAkMT07IHVuc2V0ICQxO30K
K30KK2FzX3Vuc2V0PWFzX2ZuX3Vuc2V0CisjIGFzX2ZuX2FwcGVuZCBWQVIgVkFMVUUKKyMgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQorIyBBcHBlbmQgdGhlIHRleHQgaW4gVkFMVUUgdG8gdGhlIGVu
ZCBvZiB0aGUgZGVmaW5pdGlvbiBjb250YWluZWQgaW4gVkFSLiBUYWtlCisjIGFkdmFudGFnZSBv
ZiBhbnkgc2hlbGwgb3B0aW1pemF0aW9ucyB0aGF0IGFsbG93IGFtb3J0aXplZCBsaW5lYXIgZ3Jv
d3RoIG92ZXIKKyMgcmVwZWF0ZWQgYXBwZW5kcywgaW5zdGVhZCBvZiB0aGUgdHlwaWNhbCBxdWFk
cmF0aWMgZ3Jvd3RoIHByZXNlbnQgaW4gbmFpdmUKKyMgaW1wbGVtZW50YXRpb25zLgoraWYgKGV2
YWwgImFzX3Zhcj0xOyBhc192YXIrPTI7IHRlc3QgeFwkYXNfdmFyID0geDEyIikgMj4vZGV2L251
bGw7IHRoZW4gOgorICBldmFsICdhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDErPVwk
MgorICB9JworZWxzZQorICBhc19mbl9hcHBlbmQgKCkKKyAgeworICAgIGV2YWwgJDE9XCQkMVwk
MgorICB9CitmaSAjIGFzX2ZuX2FwcGVuZAorCisjIGFzX2ZuX2FyaXRoIEFSRy4uLgorIyAtLS0t
LS0tLS0tLS0tLS0tLS0KKyMgUGVyZm9ybSBhcml0aG1ldGljIGV2YWx1YXRpb24gb24gdGhlIEFS
R3MsIGFuZCBzdG9yZSB0aGUgcmVzdWx0IGluIHRoZQorIyBnbG9iYWwgJGFzX3ZhbC4gVGFrZSBh
ZHZhbnRhZ2Ugb2Ygc2hlbGxzIHRoYXQgY2FuIGF2b2lkIGZvcmtzLiBUaGUgYXJndW1lbnRzCisj
IG11c3QgYmUgcG9ydGFibGUgYWNyb3NzICQoKCkpIGFuZCBleHByLgoraWYgKGV2YWwgInRlc3Qg
XCQoKCAxICsgMSApKSA9IDIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2Fy
aXRoICgpCisgIHsKKyAgICBhc192YWw9JCgoICQqICkpCisgIH0nCitlbHNlCisgIGFzX2ZuX2Fy
aXRoICgpCisgIHsKKyAgICBhc192YWw9YGV4cHIgIiRAIiB8fCB0ZXN0ICQ/IC1lcSAxYAorICB9
CitmaSAjIGFzX2ZuX2FyaXRoCisKKworaWYgZXhwciBhIDogJ1woYVwpJyA+L2Rldi9udWxsIDI+
JjEgJiYKKyAgIHRlc3QgIlhgZXhwciAwMDAwMSA6ICcuKlwoLi4uXCknYCIgPSBYMDAxOyB0aGVu
CisgIGFzX2V4cHI9ZXhwcgorZWxzZQorICBhc19leHByPWZhbHNlCitmaQorCitpZiAoYmFzZW5h
bWUgLS0gLykgPi9kZXYvbnVsbCAyPiYxICYmIHRlc3QgIlhgYmFzZW5hbWUgLS0gLyAyPiYxYCIg
PSAiWC8iOyB0aGVuCisgIGFzX2Jhc2VuYW1lPWJhc2VuYW1lCitlbHNlCisgIGFzX2Jhc2VuYW1l
PWZhbHNlCitmaQorCitpZiAoYXNfZGlyPWBkaXJuYW1lIC0tIC9gICYmIHRlc3QgIlgkYXNfZGly
IiA9IFgvKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfZGlybmFtZT1kaXJuYW1lCitlbHNl
CisgIGFzX2Rpcm5hbWU9ZmFsc2UKK2ZpCisKK2FzX21lPWAkYXNfYmFzZW5hbWUgLS0gIiQwIiB8
fAorJGFzX2V4cHIgWC8iJDAiIDogJy4qL1woW14vXVteL10qXCkvKiQnIFx8IFwKKwkgWCIkMCIg
OiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoL1wpJyBcfCAuIDI+L2Rldi9udWxsIHx8
CiskYXNfZWNobyBYLyIkMCIgfAorICAgIHNlZCAnL14uKlwvXChbXi9dW14vXSpcKVwvKiQvewor
CSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXC9cKSQveworCSAgICBzLy9c
MS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBx
CisJICB9CisJICBzLy4qLy4vOyBxJ2AKKworIyBBdm9pZCBkZXBlbmRpbmcgdXBvbiBDaGFyYWN0
ZXIgUmFuZ2VzLgorYXNfY3JfbGV0dGVycz0nYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonCith
c19jcl9MRVRURVJTPSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicKK2FzX2NyX0xldHRlcnM9
JGFzX2NyX2xldHRlcnMkYXNfY3JfTEVUVEVSUworYXNfY3JfZGlnaXRzPScwMTIzNDU2Nzg5Jwor
YXNfY3JfYWxudW09JGFzX2NyX0xldHRlcnMkYXNfY3JfZGlnaXRzCisKK0VDSE9fQz0gRUNIT19O
PSBFQ0hPX1Q9CitjYXNlIGBlY2hvIC1uIHhgIGluICMoKCgoKAorLW4qKQorICBjYXNlIGBlY2hv
ICd4eVxjJ2AgaW4KKyAgKmMqKSBFQ0hPX1Q9JwknOzsJIyBFQ0hPX1QgaXMgc2luZ2xlIHRhYiBj
aGFyYWN0ZXIuCisgIHh5KSAgRUNIT19DPSdcYyc7OworICAqKSAgIGVjaG8gYGVjaG8ga3NoODgg
YnVnIG9uIEFJWCA2LjFgID4gL2Rldi9udWxsCisgICAgICAgRUNIT19UPScJJzs7CisgIGVzYWM7
OworKikKKyAgRUNIT19OPSctbic7OworZXNhYworCitybSAtZiBjb25mJCQgY29uZiQkLmV4ZSBj
b25mJCQuZmlsZQoraWYgdGVzdCAtZCBjb25mJCQuZGlyOyB0aGVuCisgIHJtIC1mIGNvbmYkJC5k
aXIvY29uZiQkLmZpbGUKK2Vsc2UKKyAgcm0gLWYgY29uZiQkLmRpcgorICBta2RpciBjb25mJCQu
ZGlyIDI+L2Rldi9udWxsCitmaQoraWYgKGVjaG8gPmNvbmYkJC5maWxlKSAyPi9kZXYvbnVsbDsg
dGhlbgorICBpZiBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4KKyAg
ICBhc19sbl9zPSdsbiAtcycKKyAgICAjIC4uLiBidXQgdGhlcmUgYXJlIHR3byBnb3RjaGFzOgor
ICAgICMgMSkgT24gTVNZUywgYm90aCBgbG4gLXMgZmlsZSBkaXInIGFuZCBgbG4gZmlsZSBkaXIn
IGZhaWwuCisgICAgIyAyKSBESkdQUCA8IDIuMDQgaGFzIG5vIHN5bWxpbmtzOyBgbG4gLXMnIGNy
ZWF0ZXMgYSB3cmFwcGVyIGV4ZWN1dGFibGUuCisgICAgIyBJbiBib3RoIGNhc2VzLCB3ZSBoYXZl
IHRvIGRlZmF1bHQgdG8gYGNwIC1wJy4KKyAgICBsbiAtcyBjb25mJCQuZmlsZSBjb25mJCQuZGly
IDI+L2Rldi9udWxsICYmIHRlc3QgISAtZiBjb25mJCQuZXhlIHx8CisgICAgICBhc19sbl9zPSdj
cCAtcCcKKyAgZWxpZiBsbiBjb25mJCQuZmlsZSBjb25mJCQgMj4vZGV2L251bGw7IHRoZW4KKyAg
ICBhc19sbl9zPWxuCisgIGVsc2UKKyAgICBhc19sbl9zPSdjcCAtcCcKKyAgZmkKK2Vsc2UKKyAg
YXNfbG5fcz0nY3AgLXAnCitmaQorcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmRpci9j
b25mJCQuZmlsZSBjb25mJCQuZmlsZQorcm1kaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAorCisK
KyMgYXNfZm5fbWtkaXJfcAorIyAtLS0tLS0tLS0tLS0tCisjIENyZWF0ZSAiJGFzX2RpciIgYXMg
YSBkaXJlY3RvcnksIGluY2x1ZGluZyBwYXJlbnRzIGlmIG5lY2Vzc2FyeS4KK2FzX2ZuX21rZGly
X3AgKCkKK3sKKworICBjYXNlICRhc19kaXIgaW4gIygKKyAgLSopIGFzX2Rpcj0uLyRhc19kaXI7
OworICBlc2FjCisgIHRlc3QgLWQgIiRhc19kaXIiIHx8IGV2YWwgJGFzX21rZGlyX3AgfHwgewor
ICAgIGFzX2RpcnM9CisgICAgd2hpbGUgOjsgZG8KKyAgICAgIGNhc2UgJGFzX2RpciBpbiAjKAor
ICAgICAgKlwnKikgYXNfcWRpcj1gJGFzX2VjaG8gIiRhc19kaXIiIHwgc2VkICJzLycvJ1xcXFxc
XFxcJycvZyJgOzsgIycoCisgICAgICAqKSBhc19xZGlyPSRhc19kaXI7OworICAgICAgZXNhYwor
ICAgICAgYXNfZGlycz0iJyRhc19xZGlyJyAkYXNfZGlycyIKKyAgICAgIGFzX2Rpcj1gJGFzX2Rp
cm5hbWUgLS0gIiRhc19kaXIiIHx8CiskYXNfZXhwciBYIiRhc19kaXIiIDogJ1hcKC4qW14vXVwp
Ly8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX2RpciIgOiAnWFwoLy9cKVteL10nIFx8IFwK
KwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC9cKScg
XHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYXNfZGlyIiB8CisgICAgc2VkICcvXlhc
KC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0K
KwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9e
WFwoXC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97
CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgICAgIHRlc3Qg
LWQgIiRhc19kaXIiICYmIGJyZWFrCisgICAgZG9uZQorICAgIHRlc3QgLXogIiRhc19kaXJzIiB8
fCBldmFsICJta2RpciAkYXNfZGlycyIKKyAgfSB8fCB0ZXN0IC1kICIkYXNfZGlyIiB8fCBhc19m
bl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBkaXJlY3RvcnkgJGFzX2RpciIKKworCit9ICMgYXNf
Zm5fbWtkaXJfcAoraWYgbWtkaXIgLXAgLiAyPi9kZXYvbnVsbDsgdGhlbgorICBhc19ta2Rpcl9w
PSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRlc3QgLWQgLi8tcCAmJiBybWRpciAuLy1w
CisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRlc3QgLXggLyA+L2Rldi9udWxsIDI+JjE7
IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxzZQorICBpZiBscyAtZEwgLyA+L2Rldi9u
dWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlvbj1MCisgIGVsc2UKKyAgICBhc19sc19M
X29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAgICBldmFsIHNoIC1jICdcJycKKyAgICAg
IGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQgIiQxLy4iOworICAgICAgZWxzZQorCWNh
c2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwllc2FjOworCWNhc2UgYGxzIC1sZCckYXNf
bHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGluICMoKAorCT8/P1tzeF0qKTo7OyopZmFs
c2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2ZpCithc19leGVjdXRhYmxlX3A9JGFzX3Rl
c3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgQ1BQ
IG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSokYXNfY3JfbGV0dGVycyVQJGFzX2NyX0xF
VFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisjIFNlZCBleHByZXNzaW9uIHRvIG1h
cCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUgbmFtZS4KK2FzX3RyX3NoPSJldmFsIHNl
ZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisKKworZXhlYyA2PiYxCisjIyAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgTWFpbiBib2R5IG9mICRD
T05GSUdfU1RBVFVTIHNjcmlwdC4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tICMjCitfQVNFT0YKK3Rlc3QgJGFzX3dyaXRlX2ZhaWwgPSAwICYmIGNobW9kICt4ICRD
T05GSUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8
PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIFNhdmUgdGhlIGxvZyBtZXNzYWdlLCB0byBr
ZWVwICQwIGFuZCBzbyBvbiBtZWFuaW5nZnVsLCBhbmQgdG8KKyMgcmVwb3J0IGFjdHVhbCBpbnB1
dCB2YWx1ZXMgb2YgQ09ORklHX0ZJTEVTIGV0Yy4gaW5zdGVhZCBvZiB0aGVpcgorIyB2YWx1ZXMg
YWZ0ZXIgb3B0aW9ucyBoYW5kbGluZy4KK2FjX2xvZz0iCitUaGlzIGZpbGUgd2FzIGV4dGVuZGVk
IGJ5IFhlbiBIeXBlcnZpc29yICRhc19tZSA0LjIsIHdoaWNoIHdhcworZ2VuZXJhdGVkIGJ5IEdO
VSBBdXRvY29uZiAyLjY4LiAgSW52b2NhdGlvbiBjb21tYW5kIGxpbmUgd2FzCisKKyAgQ09ORklH
X0ZJTEVTICAgID0gJENPTkZJR19GSUxFUworICBDT05GSUdfSEVBREVSUyAgPSAkQ09ORklHX0hF
QURFUlMKKyAgQ09ORklHX0xJTktTICAgID0gJENPTkZJR19MSU5LUworICBDT05GSUdfQ09NTUFO
RFMgPSAkQ09ORklHX0NPTU1BTkRTCisgICQgJDAgJEAKKworb24gYChob3N0bmFtZSB8fCB1bmFt
ZSAtbikgMj4vZGV2L251bGwgfCBzZWQgMXFgCisiCisKK19BQ0VPRgorCitjYXNlICRhY19jb25m
aWdfZmlsZXMgaW4gKiIKKyIqKSBzZXQgeCAkYWNfY29uZmlnX2ZpbGVzOyBzaGlmdDsgYWNfY29u
ZmlnX2ZpbGVzPSQqOzsKK2VzYWMKKworY2FzZSAkYWNfY29uZmlnX2hlYWRlcnMgaW4gKiIKKyIq
KSBzZXQgeCAkYWNfY29uZmlnX2hlYWRlcnM7IHNoaWZ0OyBhY19jb25maWdfaGVhZGVycz0kKjs7
Citlc2FjCisKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFp
bD0xCisjIEZpbGVzIHRoYXQgY29uZmlnLnN0YXR1cyB3YXMgbWFkZSBmb3IuCitjb25maWdfZmls
ZXM9IiRhY19jb25maWdfZmlsZXMiCitjb25maWdfaGVhZGVycz0iJGFjX2NvbmZpZ19oZWFkZXJz
IgorCitfQUNFT0YKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRl
X2ZhaWw9MQorYWNfY3NfdXNhZ2U9IlwKK1xgJGFzX21lJyBpbnN0YW50aWF0ZXMgZmlsZXMgYW5k
IG90aGVyIGNvbmZpZ3VyYXRpb24gYWN0aW9ucworZnJvbSB0ZW1wbGF0ZXMgYWNjb3JkaW5nIHRv
IHRoZSBjdXJyZW50IGNvbmZpZ3VyYXRpb24uICBVbmxlc3MgdGhlIGZpbGVzCithbmQgYWN0aW9u
cyBhcmUgc3BlY2lmaWVkIGFzIFRBR3MsIGFsbCBhcmUgaW5zdGFudGlhdGVkIGJ5IGRlZmF1bHQu
CisKK1VzYWdlOiAkMCBbT1BUSU9OXS4uLiBbVEFHXS4uLgorCisgIC1oLCAtLWhlbHAgICAgICAg
cHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQKKyAgLVYsIC0tdmVyc2lvbiAgICBwcmludCB2ZXJz
aW9uIG51bWJlciBhbmQgY29uZmlndXJhdGlvbiBzZXR0aW5ncywgdGhlbiBleGl0CisgICAgICAt
LWNvbmZpZyAgICAgcHJpbnQgY29uZmlndXJhdGlvbiwgdGhlbiBleGl0CisgIC1xLCAtLXF1aWV0
LCAtLXNpbGVudAorICAgICAgICAgICAgICAgICAgIGRvIG5vdCBwcmludCBwcm9ncmVzcyBtZXNz
YWdlcworICAtZCwgLS1kZWJ1ZyAgICAgIGRvbid0IHJlbW92ZSB0ZW1wb3JhcnkgZmlsZXMKKyAg
ICAgIC0tcmVjaGVjayAgICB1cGRhdGUgJGFzX21lIGJ5IHJlY29uZmlndXJpbmcgaW4gdGhlIHNh
bWUgY29uZGl0aW9ucworICAgICAgLS1maWxlPUZJTEVbOlRFTVBMQVRFXQorICAgICAgICAgICAg
ICAgICAgIGluc3RhbnRpYXRlIHRoZSBjb25maWd1cmF0aW9uIGZpbGUgRklMRQorICAgICAgLS1o
ZWFkZXI9RklMRVs6VEVNUExBVEVdCisgICAgICAgICAgICAgICAgICAgaW5zdGFudGlhdGUgdGhl
IGNvbmZpZ3VyYXRpb24gaGVhZGVyIEZJTEUKKworQ29uZmlndXJhdGlvbiBmaWxlczoKKyRjb25m
aWdfZmlsZXMKKworQ29uZmlndXJhdGlvbiBoZWFkZXJzOgorJGNvbmZpZ19oZWFkZXJzCisKK1Jl
cG9ydCBidWdzIHRvIDx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbT4uIgorCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorYWNfY3Nf
Y29uZmlnPSJgJGFzX2VjaG8gIiRhY19jb25maWd1cmVfYXJncyIgfCBzZWQgJ3MvXiAvLzsgcy9b
XFwiIlxgXCRdL1xcXFwmL2cnYCIKK2FjX2NzX3ZlcnNpb249IlxcCitYZW4gSHlwZXJ2aXNvciBj
b25maWcuc3RhdHVzIDQuMgorY29uZmlndXJlZCBieSAkMCwgZ2VuZXJhdGVkIGJ5IEdOVSBBdXRv
Y29uZiAyLjY4LAorICB3aXRoIG9wdGlvbnMgXFwiXCRhY19jc19jb25maWdcXCIKKworQ29weXJp
Z2h0IChDKSAyMDEwIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgorVGhpcyBjb25maWcu
c3RhdHVzIHNjcmlwdCBpcyBmcmVlIHNvZnR3YXJlOyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uCitnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBjb3B5LCBkaXN0cmlidXRlIGFuZCBt
b2RpZnkgaXQuIgorCithY19wd2Q9JyRhY19wd2QnCitzcmNkaXI9JyRzcmNkaXInCitJTlNUQUxM
PSckSU5TVEFMTCcKK3Rlc3QgLW4gIlwkQVdLIiB8fCBBV0s9YXdrCitfQUNFT0YKKworY2F0ID4+
JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBUaGUgZGVmYXVs
dCBsaXN0cyBhcHBseSBpZiB0aGUgdXNlciBkb2VzIG5vdCBzcGVjaWZ5IGFueSBmaWxlLgorYWNf
bmVlZF9kZWZhdWx0cz06Cit3aGlsZSB0ZXN0ICQjICE9IDAKK2RvCisgIGNhc2UgJDEgaW4KKyAg
LS0qPT8qKQorICAgIGFjX29wdGlvbj1gZXhwciAiWCQxIiA6ICdYXChbXj1dKlwpPSdgCisgICAg
YWNfb3B0YXJnPWBleHByICJYJDEiIDogJ1hbXj1dKj1cKC4qXCknYAorICAgIGFjX3NoaWZ0PToK
KyAgICA7OworICAtLSo9KQorICAgIGFjX29wdGlvbj1gZXhwciAiWCQxIiA6ICdYXChbXj1dKlwp
PSdgCisgICAgYWNfb3B0YXJnPQorICAgIGFjX3NoaWZ0PToKKyAgICA7OworICAqKQorICAgIGFj
X29wdGlvbj0kMQorICAgIGFjX29wdGFyZz0kMgorICAgIGFjX3NoaWZ0PXNoaWZ0CisgICAgOzsK
KyAgZXNhYworCisgIGNhc2UgJGFjX29wdGlvbiBpbgorICAjIEhhbmRsaW5nIG9mIHRoZSBvcHRp
b25zLgorICAtcmVjaGVjayB8IC0tcmVjaGVjayB8IC0tcmVjaGVjIHwgLS1yZWNoZSB8IC0tcmVj
aCB8IC0tcmVjIHwgLS1yZSB8IC0tcikKKyAgICBhY19jc19yZWNoZWNrPTogOzsKKyAgLS12ZXJz
aW9uIHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwgLS12ZXIgfCAtLXZlIHwgLS12IHwg
LVYgKQorICAgICRhc19lY2hvICIkYWNfY3NfdmVyc2lvbiI7IGV4aXQgOzsKKyAgLS1jb25maWcg
fCAtLWNvbmZpIHwgLS1jb25mIHwgLS1jb24gfCAtLWNvIHwgLS1jICkKKyAgICAkYXNfZWNobyAi
JGFjX2NzX2NvbmZpZyI7IGV4aXQgOzsKKyAgLS1kZWJ1ZyB8IC0tZGVidSB8IC0tZGViIHwgLS1k
ZSB8IC0tZCB8IC1kICkKKyAgICBkZWJ1Zz06IDs7CisgIC0tZmlsZSB8IC0tZmlsIHwgLS1maSB8
IC0tZiApCisgICAgJGFjX3NoaWZ0CisgICAgY2FzZSAkYWNfb3B0YXJnIGluCisgICAgKlwnKikg
YWNfb3B0YXJnPWAkYXNfZWNobyAiJGFjX29wdGFyZyIgfCBzZWQgInMvJy8nXFxcXFxcXFwnJy9n
ImAgOzsKKyAgICAnJykgYXNfZm5fZXJyb3IgJD8gIm1pc3NpbmcgZmlsZSBhcmd1bWVudCIgOzsK
KyAgICBlc2FjCisgICAgYXNfZm5fYXBwZW5kIENPTkZJR19GSUxFUyAiICckYWNfb3B0YXJnJyIK
KyAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlOzsKKyAgLS1oZWFkZXIgfCAtLWhlYWRlIHwgLS1o
ZWFkIHwgLS1oZWEgKQorICAgICRhY19zaGlmdAorICAgIGNhc2UgJGFjX29wdGFyZyBpbgorICAg
ICpcJyopIGFjX29wdGFyZz1gJGFzX2VjaG8gIiRhY19vcHRhcmciIHwgc2VkICJzLycvJ1xcXFxc
XFxcJycvZyJgIDs7CisgICAgZXNhYworICAgIGFzX2ZuX2FwcGVuZCBDT05GSUdfSEVBREVSUyAi
ICckYWNfb3B0YXJnJyIKKyAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlOzsKKyAgLS1oZSB8IC0t
aCkKKyAgICAjIENvbmZsaWN0IGJldHdlZW4gLS1oZWxwIGFuZCAtLWhlYWRlcgorICAgIGFzX2Zu
X2Vycm9yICQ/ICJhbWJpZ3VvdXMgb3B0aW9uOiBcYCQxJworVHJ5IFxgJDAgLS1oZWxwJyBmb3Ig
bW9yZSBpbmZvcm1hdGlvbi4iOzsKKyAgLS1oZWxwIHwgLS1oZWwgfCAtaCApCisgICAgJGFzX2Vj
aG8gIiRhY19jc191c2FnZSI7IGV4aXQgOzsKKyAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwgLS1x
dWllIHwgLS1xdWkgfCAtLXF1IHwgLS1xIFwKKyAgfCAtc2lsZW50IHwgLS1zaWxlbnQgfCAtLXNp
bGVuIHwgLS1zaWxlIHwgLS1zaWwgfCAtLXNpIHwgLS1zKQorICAgIGFjX2NzX3NpbGVudD06IDs7
CisKKyAgIyBUaGlzIGlzIGFuIGVycm9yLgorICAtKikgYXNfZm5fZXJyb3IgJD8gInVucmVjb2du
aXplZCBvcHRpb246IFxgJDEnCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9u
LiIgOzsKKworICAqKSBhc19mbl9hcHBlbmQgYWNfY29uZmlnX3RhcmdldHMgIiAkMSIKKyAgICAg
YWNfbmVlZF9kZWZhdWx0cz1mYWxzZSA7OworCisgIGVzYWMKKyAgc2hpZnQKK2RvbmUKKworYWNf
Y29uZmlndXJlX2V4dHJhX2FyZ3M9CisKK2lmICRhY19jc19zaWxlbnQ7IHRoZW4KKyAgZXhlYyA2
Pi9kZXYvbnVsbAorICBhY19jb25maWd1cmVfZXh0cmFfYXJncz0iJGFjX2NvbmZpZ3VyZV9leHRy
YV9hcmdzIC0tc2lsZW50IgorZmkKKworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9B
Q0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2lmIFwkYWNfY3NfcmVjaGVjazsgdGhlbgorICBzZXQg
WCAnJFNIRUxMJyAnJDAnICRhY19jb25maWd1cmVfYXJncyBcJGFjX2NvbmZpZ3VyZV9leHRyYV9h
cmdzIC0tbm8tY3JlYXRlIC0tbm8tcmVjdXJzaW9uCisgIHNoaWZ0CisgIFwkYXNfZWNobyAicnVu
bmluZyBDT05GSUdfU0hFTEw9JFNIRUxMIFwkKiIgPiY2CisgIENPTkZJR19TSEVMTD0nJFNIRUxM
JworICBleHBvcnQgQ09ORklHX1NIRUxMCisgIGV4ZWMgIlwkQCIKK2ZpCisKK19BQ0VPRgorY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorZXhlYyA1Pj5j
b25maWcubG9nCit7CisgIGVjaG8KKyAgc2VkICdoO3MvLi8tL2c7cy9eLi4uLyMjIC87cy8uLi4k
LyAjIy87cDt4O3A7eCcgPDxfQVNCT1gKKyMjIFJ1bm5pbmcgJGFzX21lLiAjIworX0FTQk9YCisg
ICRhc19lY2hvICIkYWNfbG9nIgorfSA+JjUKKworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRV
UyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NU
QVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisKKyMgSGFuZGxpbmcgb2YgYXJndW1l
bnRzLgorZm9yIGFjX2NvbmZpZ190YXJnZXQgaW4gJGFjX2NvbmZpZ190YXJnZXRzCitkbworICBj
YXNlICRhY19jb25maWdfdGFyZ2V0IGluCisgICAgIi4uL2NvbmZpZy9Ub29scy5tayIpIENPTkZJ
R19GSUxFUz0iJENPTkZJR19GSUxFUyAuLi9jb25maWcvVG9vbHMubWsiIDs7CisgICAgImNvbmZp
Zy5oIikgQ09ORklHX0hFQURFUlM9IiRDT05GSUdfSEVBREVSUyBjb25maWcuaCIgOzsKKworICAq
KSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBhcmd1bWVudDogXGAkYWNfY29uZmlnX3RhcmdldCci
ICIkTElORU5PIiA1OzsKKyAgZXNhYworZG9uZQorCisKKyMgSWYgdGhlIHVzZXIgZGlkIG5vdCB1
c2UgdGhlIGFyZ3VtZW50cyB0byBzcGVjaWZ5IHRoZSBpdGVtcyB0byBpbnN0YW50aWF0ZSwKKyMg
dGhlbiB0aGUgZW52dmFyIGludGVyZmFjZSBpcyB1c2VkLiAgU2V0IG9ubHkgdGhvc2UgdGhhdCBh
cmUgbm90LgorIyBXZSB1c2UgdGhlIGxvbmcgZm9ybSBmb3IgdGhlIGRlZmF1bHQgYXNzaWdubWVu
dCBiZWNhdXNlIG9mIGFuIGV4dHJlbWVseQorIyBiaXphcnJlIGJ1ZyBvbiBTdW5PUyA0LjEuMy4K
K2lmICRhY19uZWVkX2RlZmF1bHRzOyB0aGVuCisgIHRlc3QgIiR7Q09ORklHX0ZJTEVTK3NldH0i
ID0gc2V0IHx8IENPTkZJR19GSUxFUz0kY29uZmlnX2ZpbGVzCisgIHRlc3QgIiR7Q09ORklHX0hF
QURFUlMrc2V0fSIgPSBzZXQgfHwgQ09ORklHX0hFQURFUlM9JGNvbmZpZ19oZWFkZXJzCitmaQor
CisjIEhhdmUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGZvciBjb252ZW5pZW5jZS4gIE1ha2UgaXQg
aW4gdGhlIGJ1aWxkIHRyZWUKKyMgc2ltcGx5IGJlY2F1c2UgdGhlcmUgaXMgbm8gcmVhc29uIGFn
YWluc3QgaGF2aW5nIGl0IGhlcmUsIGFuZCBpbiBhZGRpdGlvbiwKKyMgY3JlYXRpbmcgYW5kIG1v
dmluZyBmaWxlcyBmcm9tIC90bXAgY2FuIHNvbWV0aW1lcyBjYXVzZSBwcm9ibGVtcy4KKyMgSG9v
ayBmb3IgaXRzIHJlbW92YWwgdW5sZXNzIGRlYnVnZ2luZy4KKyMgTm90ZSB0aGF0IHRoZXJlIGlz
IGEgc21hbGwgd2luZG93IGluIHdoaWNoIHRoZSBkaXJlY3Rvcnkgd2lsbCBub3QgYmUgY2xlYW5l
ZDoKKyMgYWZ0ZXIgaXRzIGNyZWF0aW9uIGJ1dCBiZWZvcmUgaXRzIG5hbWUgaGFzIGJlZW4gYXNz
aWduZWQgdG8gYCR0bXAnLgorJGRlYnVnIHx8Cit7CisgIHRtcD0gYWNfdG1wPQorICB0cmFwICdl
eGl0X3N0YXR1cz0kPworICA6ICIke2FjX3RtcDo9JHRtcH0iCisgIHsgdGVzdCAhIC1kICIkYWNf
dG1wIiB8fCBybSAtZnIgIiRhY190bXAiOyB9ICYmIGV4aXQgJGV4aXRfc3RhdHVzCisnIDAKKyAg
dHJhcCAnYXNfZm5fZXhpdCAxJyAxIDIgMTMgMTUKK30KKyMgQ3JlYXRlIGEgKHNlY3VyZSkgdG1w
IGRpcmVjdG9yeSBmb3IgdG1wIGZpbGVzLgorCit7CisgIHRtcD1gKHVtYXNrIDA3NyAmJiBta3Rl
bXAgLWQgIi4vY29uZlhYWFhYWCIpIDI+L2Rldi9udWxsYCAmJgorICB0ZXN0IC1kICIkdG1wIgor
fSAgfHwKK3sKKyAgdG1wPS4vY29uZiQkLSRSQU5ET00KKyAgKHVtYXNrIDA3NyAmJiBta2RpciAi
JHRtcCIpCit9IHx8IGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGRp
cmVjdG9yeSBpbiAuIiAiJExJTkVOTyIgNQorYWNfdG1wPSR0bXAKKworIyBTZXQgdXAgdGhlIHNj
cmlwdHMgZm9yIENPTkZJR19GSUxFUyBzZWN0aW9uLgorIyBObyBuZWVkIHRvIGdlbmVyYXRlIHRo
ZW0gaWYgdGhlcmUgYXJlIG5vIENPTkZJR19GSUxFUy4KKyMgVGhpcyBoYXBwZW5zIGZvciBpbnN0
YW5jZSB3aXRoIGAuL2NvbmZpZy5zdGF0dXMgY29uZmlnLmgnLgoraWYgdGVzdCAtbiAiJENPTkZJ
R19GSUxFUyI7IHRoZW4KKworCithY19jcj1gZWNobyBYIHwgdHIgWCAnXDAxNSdgCisjIE9uIGN5
Z3dpbiwgYmFzaCBjYW4gZWF0IFxyIGluc2lkZSBgYCBpZiB0aGUgdXNlciByZXF1ZXN0ZWQgaWdu
Y3IuCisjIEJ1dCB3ZSBrbm93IG9mIG5vIG90aGVyIHNoZWxsIHdoZXJlIGFjX2NyIHdvdWxkIGJl
IGVtcHR5IGF0IHRoaXMKKyMgcG9pbnQsIHNvIHdlIGNhbiB1c2UgYSBiYXNoaXNtIGFzIGEgZmFs
bGJhY2suCitpZiB0ZXN0ICJ4JGFjX2NyIiA9IHg7IHRoZW4KKyAgZXZhbCBhY19jcj1cJFwnXFxy
XCcKK2ZpCithY19jc19hd2tfY3I9YCRBV0sgJ0JFR0lOIHsgcHJpbnQgImFccmIiIH0nIDwvZGV2
L251bGwgMj4vZGV2L251bGxgCitpZiB0ZXN0ICIkYWNfY3NfYXdrX2NyIiA9ICJhJHthY19jcn1i
IjsgdGhlbgorICBhY19jc19hd2tfY3I9J1xccicKK2Vsc2UKKyAgYWNfY3NfYXdrX2NyPSRhY19j
cgorZmkKKworZWNobyAnQkVHSU4geycgPiIkYWNfdG1wL3N1YnMxLmF3ayIgJiYKK19BQ0VPRgor
CisKK3sKKyAgZWNobyAiY2F0ID5jb25mJCRzdWJzLmF3ayA8PF9BQ0VPRiIgJiYKKyAgZWNobyAi
JGFjX3N1YnN0X3ZhcnMiIHwgc2VkICdzLy4qLyYhJCYkYWNfZGVsaW0vJyAmJgorICBlY2hvICJf
QUNFT0YiCit9ID5jb25mJCRzdWJzLnNoIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qg
bWFrZSAkQ09ORklHX1NUQVRVUyIgIiRMSU5FTk8iIDUKK2FjX2RlbGltX251bT1gZWNobyAiJGFj
X3N1YnN0X3ZhcnMiIHwgZ3JlcCAtYyAnXidgCithY19kZWxpbT0nJSFfISMgJworZm9yIGFjX2xh
c3RfdHJ5IGluIGZhbHNlIGZhbHNlIGZhbHNlIGZhbHNlIGZhbHNlIDo7IGRvCisgIC4gLi9jb25m
JCRzdWJzLnNoIHx8CisgICAgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05GSUdf
U1RBVFVTIiAiJExJTkVOTyIgNQorCisgIGFjX2RlbGltX249YHNlZCAtbiAicy8uKiRhY19kZWxp
bVwkL1gvcCIgY29uZiQkc3Vicy5hd2sgfCBncmVwIC1jIFhgCisgIGlmIHRlc3QgJGFjX2RlbGlt
X24gPSAkYWNfZGVsaW1fbnVtOyB0aGVuCisgICAgYnJlYWsKKyAgZWxpZiAkYWNfbGFzdF90cnk7
IHRoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IG1ha2UgJENPTkZJR19TVEFUVVMi
ICIkTElORU5PIiA1CisgIGVsc2UKKyAgICBhY19kZWxpbT0iJGFjX2RlbGltISRhY19kZWxpbSBf
JGFjX2RlbGltISEgIgorICBmaQorZG9uZQorcm0gLWYgY29uZiQkc3Vicy5zaAorCitjYXQgPj4k
Q09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2NhdCA+PiJcJGFjX3Rt
cC9zdWJzMS5hd2siIDw8XFxfQUNBV0sgJiYKK19BQ0VPRgorc2VkIC1uICcKK2gKK3MvXi9TWyIv
OyBzLyEuKi8iXT0vCitwCitnCitzL15bXiFdKiEvLworOnJlcGwKK3QgcmVwbAorcy8nIiRhY19k
ZWxpbSInJC8vCit0IGRlbGltCis6bmwKK2gKK3MvXCguXHsxNDhcfVwpLi4qL1wxLwordCBtb3Jl
MQorcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvXFxuIlxcLworcAorbgorYiByZXBsCis6bW9y
ZTEKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kLyJcXC8KK3AKK2cKK3MvLlx7MTQ4XH0vLwor
dCBubAorOmRlbGltCitoCitzL1woLlx7MTQ4XH1cKS4uKi9cMS8KK3QgbW9yZTIKK3MvWyJcXF0v
XFwmL2c7IHMvXi8iLzsgcy8kLyIvCitwCitiCis6bW9yZTIKK3MvWyJcXF0vXFwmL2c7IHMvXi8i
Lzsgcy8kLyJcXC8KK3AKK2cKK3MvLlx7MTQ4XH0vLwordCBkZWxpbQorJyA8Y29uZiQkc3Vicy5h
d2sgfCBzZWQgJworL15bXiIiXS97CisgIE4KKyAgcy9cbi8vCit9CisnID4+JENPTkZJR19TVEFU
VVMgfHwgYWNfd3JpdGVfZmFpbD0xCitybSAtZiBjb25mJCRzdWJzLmF3aworY2F0ID4+JENPTkZJ
R19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitfQUNBV0sKK2NhdCA+PiJcJGFj
X3RtcC9zdWJzMS5hd2siIDw8X0FDQVdLICYmCisgIGZvciAoa2V5IGluIFMpIFNfaXNfc2V0W2tl
eV0gPSAxCisgIEZTID0gIgciCisKK30KK3sKKyAgbGluZSA9ICQgMAorICBuZmllbGRzID0gc3Bs
aXQobGluZSwgZmllbGQsICJAIikKKyAgc3Vic3RlZCA9IDAKKyAgbGVuID0gbGVuZ3RoKGZpZWxk
WzFdKQorICBmb3IgKGkgPSAyOyBpIDwgbmZpZWxkczsgaSsrKSB7CisgICAga2V5ID0gZmllbGRb
aV0KKyAgICBrZXlsZW4gPSBsZW5ndGgoa2V5KQorICAgIGlmIChTX2lzX3NldFtrZXldKSB7Cisg
ICAgICB2YWx1ZSA9IFNba2V5XQorICAgICAgbGluZSA9IHN1YnN0cihsaW5lLCAxLCBsZW4pICIi
IHZhbHVlICIiIHN1YnN0cihsaW5lLCBsZW4gKyBrZXlsZW4gKyAzKQorICAgICAgbGVuICs9IGxl
bmd0aCh2YWx1ZSkgKyBsZW5ndGgoZmllbGRbKytpXSkKKyAgICAgIHN1YnN0ZWQgPSAxCisgICAg
fSBlbHNlCisgICAgICBsZW4gKz0gMSArIGtleWxlbgorICB9CisKKyAgcHJpbnQgbGluZQorfQor
CitfQUNBV0sKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dy
aXRlX2ZhaWw9MQoraWYgc2VkICJzLyRhY19jci8vIiA8IC9kZXYvbnVsbCA+IC9kZXYvbnVsbCAy
PiYxOyB0aGVuCisgIHNlZCAicy8kYWNfY3JcJC8vOyBzLyRhY19jci8kYWNfY3NfYXdrX2NyL2ci
CitlbHNlCisgIGNhdAorZmkgPCAiJGFjX3RtcC9zdWJzMS5hd2siID4gIiRhY190bXAvc3Vicy5h
d2siIFwKKyAgfHwgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBzZXR1cCBjb25maWcgZmlsZXMg
bWFjaGluZXJ5IiAiJExJTkVOTyIgNQorX0FDRU9GCisKKyMgVlBBVEggbWF5IGNhdXNlIHRyb3Vi
bGUgd2l0aCBzb21lIG1ha2VzLCBzbyB3ZSByZW1vdmUgc29sZSAkKHNyY2RpciksCisjICR7c3Jj
ZGlyfSBhbmQgQHNyY2RpckAgZW50cmllcyBmcm9tIFZQQVRIIGlmIHNyY2RpciBpcyAiLiIsIHN0
cmlwIGxlYWRpbmcgYW5kCisjIHRyYWlsaW5nIGNvbG9ucyBhbmQgdGhlbiByZW1vdmUgdGhlIHdo
b2xlIGxpbmUgaWYgVlBBVEggYmVjb21lcyBlbXB0eQorIyAoYWN0dWFsbHkgd2UgbGVhdmUgYW4g
ZW1wdHkgbGluZSB0byBwcmVzZXJ2ZSBsaW5lIG51bWJlcnMpLgoraWYgdGVzdCAieCRzcmNkaXIi
ID0geC47IHRoZW4KKyAgYWNfdnBzdWI9Jy9eWwkgXSpWUEFUSFsJIF0qPVsJIF0qL3sKK2gKK3Mv
Ly8KK3MvXi86Lworcy9bCSBdKiQvOi8KK3MvOlwkKHNyY2Rpcik6LzovZworcy86XCR7c3JjZGly
fTovOi9nCitzLzpAc3JjZGlyQDovOi9nCitzL146Ki8vCitzLzoqJC8vCit4CitzL1woPVsJIF0q
XCkuKi9cMS8KK0cKK3MvXG4vLworcy9eW149XSo9WwkgXSokLy8KK30nCitmaQorCitjYXQgPj4k
Q09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitmaSAjIHRlc3QgLW4g
IiRDT05GSUdfRklMRVMiCisKKyMgU2V0IHVwIHRoZSBzY3JpcHRzIGZvciBDT05GSUdfSEVBREVS
UyBzZWN0aW9uLgorIyBObyBuZWVkIHRvIGdlbmVyYXRlIHRoZW0gaWYgdGhlcmUgYXJlIG5vIENP
TkZJR19IRUFERVJTLgorIyBUaGlzIGhhcHBlbnMgZm9yIGluc3RhbmNlIHdpdGggYC4vY29uZmln
LnN0YXR1cyBNYWtlZmlsZScuCitpZiB0ZXN0IC1uICIkQ09ORklHX0hFQURFUlMiOyB0aGVuCitj
YXQgPiIkYWNfdG1wL2RlZmluZXMuYXdrIiA8PFxfQUNBV0sgfHwKK0JFR0lOIHsKK19BQ0VPRgor
CisjIFRyYW5zZm9ybSBjb25mZGVmcy5oIGludG8gYW4gYXdrIHNjcmlwdCBgZGVmaW5lcy5hd2sn
LCBlbWJlZGRlZCBhcworIyBoZXJlLWRvY3VtZW50IGluIGNvbmZpZy5zdGF0dXMsIHRoYXQgc3Vi
c3RpdHV0ZXMgdGhlIHByb3BlciB2YWx1ZXMgaW50bworIyBjb25maWcuaC5pbiB0byBwcm9kdWNl
IGNvbmZpZy5oLgorCisjIENyZWF0ZSBhIGRlbGltaXRlciBzdHJpbmcgdGhhdCBkb2VzIG5vdCBl
eGlzdCBpbiBjb25mZGVmcy5oLCB0byBlYXNlCisjIGhhbmRsaW5nIG9mIGxvbmcgbGluZXMuCith
Y19kZWxpbT0nJSFfISMgJworZm9yIGFjX2xhc3RfdHJ5IGluIGZhbHNlIGZhbHNlIDo7IGRvCisg
IGFjX3R0PWBzZWQgLW4gIi8kYWNfZGVsaW0vcCIgY29uZmRlZnMuaGAKKyAgaWYgdGVzdCAteiAi
JGFjX3R0IjsgdGhlbgorICAgIGJyZWFrCisgIGVsaWYgJGFjX2xhc3RfdHJ5OyB0aGVuCisgICAg
YXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05GSUdfSEVBREVSUyIgIiRMSU5FTk8i
IDUKKyAgZWxzZQorICAgIGFjX2RlbGltPSIkYWNfZGVsaW0hJGFjX2RlbGltIF8kYWNfZGVsaW0h
ISAiCisgIGZpCitkb25lCisKKyMgRm9yIHRoZSBhd2sgc2NyaXB0LCBEIGlzIGFuIGFycmF5IG9m
IG1hY3JvIHZhbHVlcyBrZXllZCBieSBuYW1lLAorIyBsaWtld2lzZSBQIGNvbnRhaW5zIG1hY3Jv
IHBhcmFtZXRlcnMgaWYgYW55LiAgUHJlc2VydmUgYmFja3NsYXNoCisjIG5ld2xpbmUgc2VxdWVu
Y2VzLgorCithY193b3JkX3JlPVtfJGFzX2NyX0xldHRlcnNdW18kYXNfY3JfYWxudW1dKgorc2Vk
IC1uICcKK3MvLlx7MTQ4XH0vJiciJGFjX2RlbGltIicvZwordCByc2V0Cis6cnNldAorcy9eWwkg
XSojWwkgXSpkZWZpbmVbCSBdWwkgXSovIC8KK3QgZGVmCitkCis6ZGVmCitzL1xcJC8vCit0IGJz
bmwKK3MvWyJcXF0vXFwmL2cKK3MvXiBcKCciJGFjX3dvcmRfcmUiJ1wpXCgoW14oKV0qKVwpWwkg
XSpcKC4qXCkvUFsiXDEiXT0iXDIiXAorRFsiXDEiXT0iIFwzIi9wCitzL14gXCgnIiRhY193b3Jk
X3JlIidcKVsJIF0qXCguKlwpL0RbIlwxIl09IiBcMiIvcAorZAorOmJzbmwKK3MvWyJcXF0vXFwm
L2cKK3MvXiBcKCciJGFjX3dvcmRfcmUiJ1wpXCgoW14oKV0qKVwpWwkgXSpcKC4qXCkvUFsiXDEi
XT0iXDIiXAorRFsiXDEiXT0iIFwzXFxcXFxcbiJcXC9wCit0IGNvbnQKK3MvXiBcKCciJGFjX3dv
cmRfcmUiJ1wpWwkgXSpcKC4qXCkvRFsiXDEiXT0iIFwyXFxcXFxcbiJcXC9wCit0IGNvbnQKK2QK
Kzpjb250CituCitzLy5cezE0OFx9LyYnIiRhY19kZWxpbSInL2cKK3QgY2xlYXIKKzpjbGVhcgor
cy9cXCQvLwordCBic25sYworcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvIi9wCitkCis6YnNu
bGMKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kL1xcXFxcXG4iXFwvcAorYiBjb250CisnIDxj
b25mZGVmcy5oIHwgc2VkICcKK3MvJyIkYWNfZGVsaW0iJy8iXFxcCisiL2cnID4+JENPTkZJR19T
VEFUVVMgfHwgYWNfd3JpdGVfZmFpbD0xCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9G
IHx8IGFjX3dyaXRlX2ZhaWw9MQorICBmb3IgKGtleSBpbiBEKSBEX2lzX3NldFtrZXldID0gMQor
ICBGUyA9ICIHIgorfQorL15bXHQgXSojW1x0IF0qKGRlZmluZXx1bmRlZilbXHQgXSskYWNfd29y
ZF9yZShbXHQgKF18XCQpLyB7CisgIGxpbmUgPSBcJCAwCisgIHNwbGl0KGxpbmUsIGFyZywgIiAi
KQorICBpZiAoYXJnWzFdID09ICIjIikgeworICAgIGRlZnVuZGVmID0gYXJnWzJdCisgICAgbWFj
MSA9IGFyZ1szXQorICB9IGVsc2UgeworICAgIGRlZnVuZGVmID0gc3Vic3RyKGFyZ1sxXSwgMikK
KyAgICBtYWMxID0gYXJnWzJdCisgIH0KKyAgc3BsaXQobWFjMSwgbWFjMiwgIigiKSAjKQorICBt
YWNybyA9IG1hYzJbMV0KKyAgcHJlZml4ID0gc3Vic3RyKGxpbmUsIDEsIGluZGV4KGxpbmUsIGRl
ZnVuZGVmKSAtIDEpCisgIGlmIChEX2lzX3NldFttYWNyb10pIHsKKyAgICAjIFByZXNlcnZlIHRo
ZSB3aGl0ZSBzcGFjZSBzdXJyb3VuZGluZyB0aGUgIiMiLgorICAgIHByaW50IHByZWZpeCAiZGVm
aW5lIiwgbWFjcm8gUFttYWNyb10gRFttYWNyb10KKyAgICBuZXh0CisgIH0gZWxzZSB7CisgICAg
IyBSZXBsYWNlICN1bmRlZiB3aXRoIGNvbW1lbnRzLiAgVGhpcyBpcyBuZWNlc3NhcnksIGZvciBl
eGFtcGxlLAorICAgICMgaW4gdGhlIGNhc2Ugb2YgX1BPU0lYX1NPVVJDRSwgd2hpY2ggaXMgcHJl
ZGVmaW5lZCBhbmQgcmVxdWlyZWQKKyAgICAjIG9uIHNvbWUgc3lzdGVtcyB3aGVyZSBjb25maWd1
cmUgd2lsbCBub3QgZGVjaWRlIHRvIGRlZmluZSBpdC4KKyAgICBpZiAoZGVmdW5kZWYgPT0gInVu
ZGVmIikgeworICAgICAgcHJpbnQgIi8qIiwgcHJlZml4IGRlZnVuZGVmLCBtYWNybywgIiovIgor
ICAgICAgbmV4dAorICAgIH0KKyAgfQorfQoreyBwcmludCB9CitfQUNBV0sKK19BQ0VPRgorY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorICBhc19mbl9l
cnJvciAkPyAiY291bGQgbm90IHNldHVwIGNvbmZpZyBoZWFkZXJzIG1hY2hpbmVyeSIgIiRMSU5F
Tk8iIDUKK2ZpICMgdGVzdCAtbiAiJENPTkZJR19IRUFERVJTIgorCisKK2V2YWwgc2V0IFggIiAg
OkYgJENPTkZJR19GSUxFUyAgOkggJENPTkZJR19IRUFERVJTICAgICIKK3NoaWZ0Citmb3IgYWNf
dGFnCitkbworICBjYXNlICRhY190YWcgaW4KKyAgOltGSExDXSkgYWNfbW9kZT0kYWNfdGFnOyBj
b250aW51ZTs7CisgIGVzYWMKKyAgY2FzZSAkYWNfbW9kZSRhY190YWcgaW4KKyAgOltGSExdKjoq
KTs7CisgIDpMKiB8IDpDKjoqKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB0YWcgXGAkYWNfdGFn
JyIgIiRMSU5FTk8iIDU7OworICA6W0ZIXS0pIGFjX3RhZz0tOi07OworICA6W0ZIXSopIGFjX3Rh
Zz0kYWNfdGFnOiRhY190YWcuaW47OworICBlc2FjCisgIGFjX3NhdmVfSUZTPSRJRlMKKyAgSUZT
PToKKyAgc2V0IHggJGFjX3RhZworICBJRlM9JGFjX3NhdmVfSUZTCisgIHNoaWZ0CisgIGFjX2Zp
bGU9JDEKKyAgc2hpZnQKKworICBjYXNlICRhY19tb2RlIGluCisgIDpMKSBhY19zb3VyY2U9JDE7
OworICA6W0ZIXSkKKyAgICBhY19maWxlX2lucHV0cz0KKyAgICBmb3IgYWNfZgorICAgIGRvCisg
ICAgICBjYXNlICRhY19mIGluCisgICAgICAtKSBhY19mPSIkYWNfdG1wL3N0ZGluIjs7CisgICAg
ICAqKSAjIExvb2sgZm9yIHRoZSBmaWxlIGZpcnN0IGluIHRoZSBidWlsZCB0cmVlLCB0aGVuIGlu
IHRoZSBzb3VyY2UgdHJlZQorCSAjIChpZiB0aGUgcGF0aCBpcyBub3QgYWJzb2x1dGUpLiAgVGhl
IGFic29sdXRlIHBhdGggY2Fubm90IGJlIERPUy1zdHlsZSwKKwkgIyBiZWNhdXNlICRhY19mIGNh
bm5vdCBjb250YWluIGA6Jy4KKwkgdGVzdCAtZiAiJGFjX2YiIHx8CisJICAgY2FzZSAkYWNfZiBp
bgorCSAgIFtcXC8kXSopIGZhbHNlOzsKKwkgICAqKSB0ZXN0IC1mICIkc3JjZGlyLyRhY19mIiAm
JiBhY19mPSIkc3JjZGlyLyRhY19mIjs7CisJICAgZXNhYyB8fAorCSAgIGFzX2ZuX2Vycm9yIDEg
ImNhbm5vdCBmaW5kIGlucHV0IGZpbGU6IFxgJGFjX2YnIiAiJExJTkVOTyIgNTs7CisgICAgICBl
c2FjCisgICAgICBjYXNlICRhY19mIGluICpcJyopIGFjX2Y9YCRhc19lY2hvICIkYWNfZiIgfCBz
ZWQgInMvJy8nXFxcXFxcXFwnJy9nImA7OyBlc2FjCisgICAgICBhc19mbl9hcHBlbmQgYWNfZmls
ZV9pbnB1dHMgIiAnJGFjX2YnIgorICAgIGRvbmUKKworICAgICMgTGV0J3Mgc3RpbGwgcHJldGVu
ZCBpdCBpcyBgY29uZmlndXJlJyB3aGljaCBpbnN0YW50aWF0ZXMgKGkuZS4sIGRvbid0CisgICAg
IyB1c2UgJGFzX21lKSwgcGVvcGxlIHdvdWxkIGJlIHN1cnByaXNlZCB0byByZWFkOgorICAgICMg
ICAgLyogY29uZmlnLmguICBHZW5lcmF0ZWQgYnkgY29uZmlnLnN0YXR1cy4gICovCisgICAgY29u
ZmlndXJlX2lucHV0PSdHZW5lcmF0ZWQgZnJvbSAnYAorCSAgJGFzX2VjaG8gIiQqIiB8IHNlZCAn
c3xeW146XSovfHw7c3w6W146XSovfCwgfGcnCisJYCcgYnkgY29uZmlndXJlLicKKyAgICBpZiB0
ZXN0IHgiJGFjX2ZpbGUiICE9IHgtOyB0aGVuCisgICAgICBjb25maWd1cmVfaW5wdXQ9IiRhY19m
aWxlLiAgJGNvbmZpZ3VyZV9pbnB1dCIKKyAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY3JlYXRpbmcgJGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTog
Y3JlYXRpbmcgJGFjX2ZpbGUiID4mNjt9CisgICAgZmkKKyAgICAjIE5ldXRyYWxpemUgc3BlY2lh
bCBjaGFyYWN0ZXJzIGludGVycHJldGVkIGJ5IHNlZCBpbiByZXBsYWNlbWVudCBzdHJpbmdzLgor
ICAgIGNhc2UgJGNvbmZpZ3VyZV9pbnB1dCBpbiAjKAorICAgICpcJiogfCAqXHwqIHwgKlxcKiAp
CisgICAgICAgYWNfc2VkX2NvbmZfaW5wdXQ9YCRhc19lY2hvICIkY29uZmlndXJlX2lucHV0IiB8
CisgICAgICAgc2VkICdzL1tcXFxcJnxdL1xcXFwmL2cnYDs7ICMoCisgICAgKikgYWNfc2VkX2Nv
bmZfaW5wdXQ9JGNvbmZpZ3VyZV9pbnB1dDs7CisgICAgZXNhYworCisgICAgY2FzZSAkYWNfdGFn
IGluCisgICAgKjotOiogfCAqOi0pIGNhdCA+IiRhY190bXAvc3RkaW4iIFwKKyAgICAgIHx8IGFz
X2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNSA7Owor
ICAgIGVzYWMKKyAgICA7OworICBlc2FjCisKKyAgYWNfZGlyPWAkYXNfZGlybmFtZSAtLSAiJGFj
X2ZpbGUiIHx8CiskYXNfZXhwciBYIiRhY19maWxlIiA6ICdYXCguKlteL11cKS8vKlteL11bXi9d
Ki8qJCcgXHwgXAorCSBYIiRhY19maWxlIiA6ICdYXCgvL1wpW14vXScgXHwgXAorCSBYIiRhY19m
aWxlIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRhY19maWxlIiA6ICdYXCgvXCknIFx8IC4gMj4v
ZGV2L251bGwgfHwKKyRhc19lY2hvIFgiJGFjX2ZpbGUiIHwKKyAgICBzZWQgJy9eWFwoLipbXi9d
XClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15Y
XChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wv
XCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cKS4qL3sKKwkgICAg
cy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICBhc19kaXI9IiRhY19kaXIi
OyBhc19mbl9ta2Rpcl9wCisgIGFjX2J1aWxkZGlyPS4KKworY2FzZSAiJGFjX2RpciIgaW4KKy4p
IGFjX2Rpcl9zdWZmaXg9IGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4
PSA7OworKikKKyAgYWNfZGlyX3N1ZmZpeD0vYCRhc19lY2hvICIkYWNfZGlyIiB8IHNlZCAnc3xe
XC5bXFwvXXx8J2AKKyAgIyBBICIuLiIgZm9yIGVhY2ggZGlyZWN0b3J5IGluICRhY19kaXJfc3Vm
Zml4LgorICBhY190b3BfYnVpbGRkaXJfc3ViPWAkYXNfZWNobyAiJGFjX2Rpcl9zdWZmaXgiIHwg
c2VkICdzfC9bXlxcL10qfC8uLnxnO3N8L3x8J2AKKyAgY2FzZSAkYWNfdG9wX2J1aWxkZGlyX3N1
YiBpbgorICAiIikgYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7
CisgICopICBhY190b3BfYnVpbGRfcHJlZml4PSRhY190b3BfYnVpbGRkaXJfc3ViLyA7OworICBl
c2FjIDs7Citlc2FjCithY19hYnNfdG9wX2J1aWxkZGlyPSRhY19wd2QKK2FjX2Fic19idWlsZGRp
cj0kYWNfcHdkJGFjX2Rpcl9zdWZmaXgKKyMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk6Cith
Y190b3BfYnVpbGRkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgKKworY2FzZSAkc3JjZGlyIGluCisg
IC4pICAjIFdlIGFyZSBidWlsZGluZyBpbiBwbGFjZS4KKyAgICBhY19zcmNkaXI9LgorICAgIGFj
X3RvcF9zcmNkaXI9JGFjX3RvcF9idWlsZGRpcl9zdWIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0k
YWNfcHdkIDs7CisgIFtcXC9dKiB8ID86W1xcL10qICkgICMgQWJzb2x1dGUgbmFtZS4KKyAgICBh
Y19zcmNkaXI9JHNyY2RpciRhY19kaXJfc3VmZml4OworICAgIGFjX3RvcF9zcmNkaXI9JHNyY2Rp
cgorICAgIGFjX2Fic190b3Bfc3JjZGlyPSRzcmNkaXIgOzsKKyAgKikgIyBSZWxhdGl2ZSBuYW1l
LgorICAgIGFjX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIkYWNfZGlyX3N1ZmZp
eAorICAgIGFjX3RvcF9zcmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyCisgICAgYWNf
YWJzX3RvcF9zcmNkaXI9JGFjX3B3ZC8kc3JjZGlyIDs7Citlc2FjCithY19hYnNfc3JjZGlyPSRh
Y19hYnNfdG9wX3NyY2RpciRhY19kaXJfc3VmZml4CisKKworICBjYXNlICRhY19tb2RlIGluCisg
IDpGKQorICAjCisgICMgQ09ORklHX0ZJTEUKKyAgIworCisgIGNhc2UgJElOU1RBTEwgaW4KKyAg
W1xcLyRdKiB8ID86W1xcL10qICkgYWNfSU5TVEFMTD0kSU5TVEFMTCA7OworICAqKSBhY19JTlNU
QUxMPSRhY190b3BfYnVpbGRfcHJlZml4JElOU1RBTEwgOzsKKyAgZXNhYworX0FDRU9GCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyMgSWYgdGhl
IHRlbXBsYXRlIGRvZXMgbm90IGtub3cgYWJvdXQgZGF0YXJvb3RkaXIsIGV4cGFuZCBpdC4KKyMg
RklYTUU6IFRoaXMgaGFjayBzaG91bGQgYmUgcmVtb3ZlZCBhIGZldyB5ZWFycyBhZnRlciAyLjYw
LgorYWNfZGF0YXJvb3RkaXJfaGFjaz07IGFjX2RhdGFyb290ZGlyX3NlZW49CithY19zZWRfZGF0
YXJvb3Q9JworL2RhdGFyb290ZGlyLyB7CisgIHAKKyAgcQorfQorL0BkYXRhZGlyQC9wCisvQGRv
Y2RpckAvcAorL0BpbmZvZGlyQC9wCisvQGxvY2FsZWRpckAvcAorL0BtYW5kaXJAL3AnCitjYXNl
IGBldmFsICJzZWQgLW4gXCJcJGFjX3NlZF9kYXRhcm9vdFwiICRhY19maWxlX2lucHV0cyJgIGlu
CisqZGF0YXJvb3RkaXIqKSBhY19kYXRhcm9vdGRpcl9zZWVuPXllczs7CisqQGRhdGFkaXJAKnwq
QGRvY2RpckAqfCpAaW5mb2RpckAqfCpAbG9jYWxlZGlyQCp8KkBtYW5kaXJAKikKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkYWNfZmlsZV9pbnB1
dHMgc2VlbXMgdG8gaWdub3JlIHRoZSAtLWRhdGFyb290ZGlyIHNldHRpbmciID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogV0FSTklORzogJGFjX2ZpbGVfaW5wdXRzIHNlZW1zIHRvIGlnbm9yZSB0aGUg
LS1kYXRhcm9vdGRpciBzZXR0aW5nIiA+JjI7fQorX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRV
UyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyAgYWNfZGF0YXJvb3RkaXJfaGFjaz0nCisg
IHMmQGRhdGFkaXJAJiRkYXRhZGlyJmcKKyAgcyZAZG9jZGlyQCYkZG9jZGlyJmcKKyAgcyZAaW5m
b2RpckAmJGluZm9kaXImZworICBzJkBsb2NhbGVkaXJAJiRsb2NhbGVkaXImZworICBzJkBtYW5k
aXJAJiRtYW5kaXImZworICBzJlxcXCR7ZGF0YXJvb3RkaXJ9JiRkYXRhcm9vdGRpciZnJyA7Owor
ZXNhYworX0FDRU9GCisKKyMgTmV1dHJhbGl6ZSBWUEFUSCB3aGVuIGAkc3JjZGlyJyA9IGAuJy4K
KyMgU2hlbGwgY29kZSBpbiBjb25maWd1cmUuYWMgbWlnaHQgc2V0IGV4dHJhc3ViLgorIyBGSVhN
RTogZG8gd2UgcmVhbGx5IHdhbnQgdG8gbWFpbnRhaW4gdGhpcyBmZWF0dXJlPworY2F0ID4+JENP
TkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCithY19zZWRfZXh0cmE9IiRh
Y192cHN1YgorJGV4dHJhc3ViCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VP
RiB8fCBhY193cml0ZV9mYWlsPTEKKzp0CisvQFthLXpBLVpfXVthLXpBLVpfMC05XSpALyFiCitz
fEBjb25maWd1cmVfaW5wdXRAfCRhY19zZWRfY29uZl9pbnB1dHw7dCB0CitzJkB0b3BfYnVpbGRk
aXJAJiRhY190b3BfYnVpbGRkaXJfc3ViJjt0IHQKK3MmQHRvcF9idWlsZF9wcmVmaXhAJiRhY190
b3BfYnVpbGRfcHJlZml4Jjt0IHQKK3MmQHNyY2RpckAmJGFjX3NyY2RpciY7dCB0CitzJkBhYnNf
c3JjZGlyQCYkYWNfYWJzX3NyY2RpciY7dCB0CitzJkB0b3Bfc3JjZGlyQCYkYWNfdG9wX3NyY2Rp
ciY7dCB0CitzJkBhYnNfdG9wX3NyY2RpckAmJGFjX2Fic190b3Bfc3JjZGlyJjt0IHQKK3MmQGJ1
aWxkZGlyQCYkYWNfYnVpbGRkaXImO3QgdAorcyZAYWJzX2J1aWxkZGlyQCYkYWNfYWJzX2J1aWxk
ZGlyJjt0IHQKK3MmQGFic190b3BfYnVpbGRkaXJAJiRhY19hYnNfdG9wX2J1aWxkZGlyJjt0IHQK
K3MmQElOU1RBTExAJiRhY19JTlNUQUxMJjt0IHQKKyRhY19kYXRhcm9vdGRpcl9oYWNrCisiCitl
dmFsIHNlZCBcIlwkYWNfc2VkX2V4dHJhXCIgIiRhY19maWxlX2lucHV0cyIgfCAkQVdLIC1mICIk
YWNfdG1wL3N1YnMuYXdrIiBcCisgID4kYWNfdG1wL291dCB8fCBhc19mbl9lcnJvciAkPyAiY291
bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUKKwordGVzdCAteiAiJGFjX2RhdGFy
b290ZGlyX2hhY2skYWNfZGF0YXJvb3RkaXJfc2VlbiIgJiYKKyAgeyBhY19vdXQ9YHNlZCAtbiAn
L1wke2RhdGFyb290ZGlyfS9wJyAiJGFjX3RtcC9vdXQiYDsgdGVzdCAtbiAiJGFjX291dCI7IH0g
JiYKKyAgeyBhY19vdXQ9YHNlZCAtbiAnL15bCSBdKmRhdGFyb290ZGlyWwkgXSo6Kj0vcCcgXAor
ICAgICAgIiRhY190bXAvb3V0ImA7IHRlc3QgLXogIiRhY19vdXQiOyB9ICYmCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJGFjX2ZpbGUgY29udGFp
bnMgYSByZWZlcmVuY2UgdG8gdGhlIHZhcmlhYmxlIFxgZGF0YXJvb3RkaXInCit3aGljaCBzZWVt
cyB0byBiZSB1bmRlZmluZWQuICBQbGVhc2UgbWFrZSBzdXJlIGl0IGlzIGRlZmluZWQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJGFjX2ZpbGUgY29udGFpbnMgYSByZWZlcmVuY2Ug
dG8gdGhlIHZhcmlhYmxlIFxgZGF0YXJvb3RkaXInCit3aGljaCBzZWVtcyB0byBiZSB1bmRlZmlu
ZWQuICBQbGVhc2UgbWFrZSBzdXJlIGl0IGlzIGRlZmluZWQiID4mMjt9CisKKyAgcm0gLWYgIiRh
Y190bXAvc3RkaW4iCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgLSkgY2F0ICIkYWNfdG1wL291dCIg
JiYgcm0gLWYgIiRhY190bXAvb3V0Ijs7CisgICopIHJtIC1mICIkYWNfZmlsZSIgJiYgbXYgIiRh
Y190bXAvb3V0IiAiJGFjX2ZpbGUiOzsKKyAgZXNhYyBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJj
b3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorIDs7CisgIDpIKQorICAjCisg
ICMgQ09ORklHX0hFQURFUgorICAjCisgIGlmIHRlc3QgeCIkYWNfZmlsZSIgIT0geC07IHRoZW4K
KyAgICB7CisgICAgICAkYXNfZWNobyAiLyogJGNvbmZpZ3VyZV9pbnB1dCAgKi8iIFwKKyAgICAg
ICYmIGV2YWwgJyRBV0sgLWYgIiRhY190bXAvZGVmaW5lcy5hd2siJyAiJGFjX2ZpbGVfaW5wdXRz
IgorICAgIH0gPiIkYWNfdG1wL2NvbmZpZy5oIiBcCisgICAgICB8fCBhc19mbl9lcnJvciAkPyAi
Y291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUKKyAgICBpZiBkaWZmICIkYWNf
ZmlsZSIgIiRhY190bXAvY29uZmlnLmgiID4vZGV2L251bGwgMj4mMTsgdGhlbgorICAgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfZmlsZSBpcyB1bmNoYW5n
ZWQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogJGFjX2ZpbGUgaXMgdW5jaGFuZ2VkIiA+JjY7fQor
ICAgIGVsc2UKKyAgICAgIHJtIC1mICIkYWNfZmlsZSIKKyAgICAgIG12ICIkYWNfdG1wL2NvbmZp
Zy5oIiAiJGFjX2ZpbGUiIFwKKwl8fCBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IGNyZWF0ZSAk
YWNfZmlsZSIgIiRMSU5FTk8iIDUKKyAgICBmaQorICBlbHNlCisgICAgJGFzX2VjaG8gIi8qICRj
b25maWd1cmVfaW5wdXQgICovIiBcCisgICAgICAmJiBldmFsICckQVdLIC1mICIkYWNfdG1wL2Rl
ZmluZXMuYXdrIicgIiRhY19maWxlX2lucHV0cyIgXAorICAgICAgfHwgYXNfZm5fZXJyb3IgJD8g
ImNvdWxkIG5vdCBjcmVhdGUgLSIgIiRMSU5FTk8iIDUKKyAgZmkKKyA7OworCisKKyAgZXNhYwor
Citkb25lICMgZm9yIGFjX3RhZworCisKK2FzX2ZuX2V4aXQgMAorX0FDRU9GCithY19jbGVhbl9m
aWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQorCit0ZXN0ICRhY193cml0ZV9mYWlsID0gMCB8fAor
ICBhc19mbl9lcnJvciAkPyAid3JpdGUgZmFpbHVyZSBjcmVhdGluZyAkQ09ORklHX1NUQVRVUyIg
IiRMSU5FTk8iIDUKKworCisjIGNvbmZpZ3VyZSBpcyB3cml0aW5nIHRvIGNvbmZpZy5sb2csIGFu
ZCB0aGVuIGNhbGxzIGNvbmZpZy5zdGF0dXMuCisjIGNvbmZpZy5zdGF0dXMgZG9lcyBpdHMgb3du
IHJlZGlyZWN0aW9uLCBhcHBlbmRpbmcgdG8gY29uZmlnLmxvZy4KKyMgVW5mb3J0dW5hdGVseSwg
b24gRE9TIHRoaXMgZmFpbHMsIGFzIGNvbmZpZy5sb2cgaXMgc3RpbGwga2VwdCBvcGVuCisjIGJ5
IGNvbmZpZ3VyZSwgc28gY29uZmlnLnN0YXR1cyB3b24ndCBiZSBhYmxlIHRvIHdyaXRlIHRvIGl0
OyBpdHMKKyMgb3V0cHV0IGlzIHNpbXBseSBkaXNjYXJkZWQuICBTbyB3ZSBleGVjIHRoZSBGRCB0
byAvZGV2L251bGwsCisjIGVmZmVjdGl2ZWx5IGNsb3NpbmcgY29uZmlnLmxvZywgc28gaXQgY2Fu
IGJlIHByb3Blcmx5IChyZSlvcGVuZWQgYW5kCisjIGFwcGVuZGVkIHRvIGJ5IGNvbmZpZy5zdGF0
dXMuICBXaGVuIGNvbWluZyBiYWNrIHRvIGNvbmZpZ3VyZSwgd2UKKyMgbmVlZCB0byBtYWtlIHRo
ZSBGRCBhdmFpbGFibGUgYWdhaW4uCitpZiB0ZXN0ICIkbm9fY3JlYXRlIiAhPSB5ZXM7IHRoZW4K
KyAgYWNfY3Nfc3VjY2Vzcz06CisgIGFjX2NvbmZpZ19zdGF0dXNfYXJncz0KKyAgdGVzdCAiJHNp
bGVudCIgPSB5ZXMgJiYKKyAgICBhY19jb25maWdfc3RhdHVzX2FyZ3M9IiRhY19jb25maWdfc3Rh
dHVzX2FyZ3MgLS1xdWlldCIKKyAgZXhlYyA1Pi9kZXYvbnVsbAorICAkU0hFTEwgJENPTkZJR19T
VEFUVVMgJGFjX2NvbmZpZ19zdGF0dXNfYXJncyB8fCBhY19jc19zdWNjZXNzPWZhbHNlCisgIGV4
ZWMgNT4+Y29uZmlnLmxvZworICAjIFVzZSB8fCwgbm90ICYmLCB0byBhdm9pZCBleGl0aW5nIGZy
b20gdGhlIGlmIHdpdGggJD8gPSAxLCB3aGljaAorICAjIHdvdWxkIG1ha2UgY29uZmlndXJlIGZh
aWwgaWYgdGhpcyBpcyB0aGUgbGFzdCBpbnN0cnVjdGlvbi4KKyAgJGFjX2NzX3N1Y2Nlc3MgfHwg
YXNfZm5fZXhpdCAxCitmaQoraWYgdGVzdCAtbiAiJGFjX3VucmVjb2duaXplZF9vcHRzIiAmJiB0
ZXN0ICIkZW5hYmxlX29wdGlvbl9jaGVja2luZyIgIT0gbm87IHRoZW4KKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1bnJlY29nbml6ZWQgb3B0aW9u
czogJGFjX3VucmVjb2duaXplZF9vcHRzIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
IHVucmVjb2duaXplZCBvcHRpb25zOiAkYWNfdW5yZWNvZ25pemVkX29wdHMiID4mMjt9CitmaQor
CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9jb25maWd1cmUuYWMK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMv
Y29uZmlndXJlLmFjCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDE5
MSBAQAorIyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSot
IEF1dG9jb25mIC0qLQorIyBQcm9jZXNzIHRoaXMgZmlsZSB3aXRoIGF1dG9jb25mIHRvIHByb2R1
Y2UgYSBjb25maWd1cmUgc2NyaXB0LgorCitBQ19QUkVSRVEoWzIuNjddKQorQUNfSU5JVChbWGVu
IEh5cGVydmlzb3JdLCBtNF9lc3lzY21kKFsuLi92ZXJzaW9uLnNoIC4uL3hlbi9NYWtlZmlsZV0p
LAorICAgIFt4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbV0pCitBQ19DT05GSUdfU1JDRElS
KFtsaWJ4bC9saWJ4bC5jXSkKK0FDX0NPTkZJR19GSUxFUyhbLi4vY29uZmlnL1Rvb2xzLm1rXSkK
K0FDX0NPTkZJR19IRUFERVJTKFtjb25maWcuaF0pCitBQ19QUkVGSVhfREVGQVVMVChbL3Vzcl0p
CitBQ19DT05GSUdfQVVYX0RJUihbLl0pCisKKyMgQ2hlY2sgaWYgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5pbmcKKworQVNfSUYo
W3Rlc3QgLW4gIiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQUCJdLCBbCisgICAg
QUNfTVNHX1dBUk4oCitbU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdTLCBMSUJTLCBDUFBGTEFH
UyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVORF9JTkNMVURFUywgUFJF
UEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBpbnN0ZWFkIHdoZW4g
cG9zc2libGUuXSkKK10pCisKK0FDX1VTRV9TWVNURU1fRVhURU5TSU9OUworQUNfQ0FOT05JQ0FM
X0hPU1QKKworIyBNNCBNYWNybyBpbmNsdWRlcworbTRfaW5jbHVkZShbbTQvZW5hYmxlX2ZlYXR1
cmUubTRdKQorbTRfaW5jbHVkZShbbTQvZGlzYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUo
W200L3BhdGhfb3JfZmFpbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25feG1sLm00XSkKK200
X2luY2x1ZGUoW200L3B5dGhvbl92ZXJzaW9uLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl9k
ZXZlbC5tNF0pCittNF9pbmNsdWRlKFttNC91ZGV2Lm00XSkKK200X2luY2x1ZGUoW200L29jYW1s
Lm00XSkKK200X2luY2x1ZGUoW200L2RlZmF1bHRfbGliLm00XSkKK200X2luY2x1ZGUoW200L3Nl
dF9jZmxhZ3NfbGRmbGFncy5tNF0pCittNF9pbmNsdWRlKFttNC91dWlkLm00XSkKKworIyBFbmFi
bGUvZGlzYWJsZSBvcHRpb25zCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCisgICAg
W0VuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzayldKQorQVhfQVJH
X0VOQUJMRV9BTkRfRVhQT1JUKFtnaXRodHRwXSwgW0Rvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMg
dmlhIEhUVFBdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbbW9uaXRvcnNdLAorICAgIFtE
aXNhYmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzXSkKK0FYX0FSR19FTkFC
TEVfQU5EX0VYUE9SVChbdnRwbV0sIFtFbmFibGUgVmlydHVhbCBUcnVzdGVkIFBsYXRmb3JtIE1v
ZHVsZV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hhcGldLCBbRW5hYmxlIFhlbiBBUEkg
QmluZGluZ3NdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbcHl0aG9udG9vbHNdLCBbRGlz
YWJsZSBQeXRob24gdG9vbHNdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbb2NhbWx0b29s
c10sIFtEaXNhYmxlIE9jYW1sIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbWlu
aXRlcm1dLCBbRW5hYmxlIG1pbml0ZXJtXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbG9t
b3VudF0sIFtFbmFibGUgbG9tb3VudF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtkZWJ1
Z10sIFtEaXNhYmxlIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQgdG9vbHNdKQorCitBQ19BUkdfVkFS
KFtQUkVQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJl
cGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW1BSRVBFTkRfTElCXSwK
KyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRo
b3V0IC1MKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGlu
Y2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdf
VkFSKFtBUFBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gYXBwZW5k
IHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKKworQVhfU0VUX0ZMQUdTCisKK0FDX0FSR19WQVIo
W1BZVEhPTl0sIFtQYXRoIHRvIHRoZSBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxd
LCBbUGF0aCB0byBQZXJsIHBhcnNlcl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJy
Y3RsIHRvb2xdKQorQUNfQVJHX1ZBUihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19W
QVIoW0JJU09OXSwgW1BhdGggdG8gQmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFS
KFtGTEVYXSwgW1BhdGggdG8gRmxleCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19B
UkdfVkFSKFtDVVJMXSwgW1BhdGggdG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtY
TUxdLCBbUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0
aCB0byBiYXNoIHNoZWxsXSkKK0FDX0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0
ZXh0IHRvb2xdKQorCisjIENoZWNrcyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJP
R19DQworQUNfUFJPR19MTl9TCitBQ19QUk9HX01BS0VfU0VUCitBQ19QUk9HX0lOU1RBTEwKK0FY
X1BBVEhfUFJPR19PUl9GQUlMKFtQRVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwo
W0JSQ1RMXSwgW2JyY3RsXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9Q
QVRIX1BST0dfT1JfRkFJTChbQklTT05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwo
W0ZMRVhdLCBbZmxleF0pCitBU19JRihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhf
UEFUSF9QUk9HX09SX0ZBSUwoW0NVUkxdLCBbY3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJP
R19PUl9GQUlMKFtYTUxdLCBbeG1sMi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1s
dG9vbHMiID0gInh5Il0sIFsKKyAgICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngk
T0NBTUxDIiA9ICJ4bm8iXSwgWworICAgICAgICBBU19JRihbdGVzdCAieCRlbmFibGVfb2NhbWx0
b29scyIgPSAieHllcyJdLCBbCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoW09jYW1sIHRvb2xz
IGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmluZCBPY2FtbF0pXSkKKyAgICAgICAgb2NhbWx0b29s
cz0ibiIKKyAgICBdKQorXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCQVNIXSwgW2Jhc2hdKQor
QVNfSUYoW3Rlc3QgIngkcHl0aG9udG9vbHMiID0gInh5Il0sIFsKKyAgICBBU19JRihbZWNobyAi
JFBZVEhPTiIgfCBncmVwIC1xICJeLyJdLCBbCisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgor
ICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorICAgIF0sW3Rlc3QgLXogIiRQ
WVRIT04iXSwgW1BZVEhPTj0icHl0aG9uIl0sCisgICAgW0FDX01TR19FUlJPUihbUFlUSE9OIHNw
ZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoXSldKQorICAgIEFYX1BBVEhfUFJP
R19PUl9GQUlMKFtQWVRIT05QQVRIXSwgWyRQWVRIT05dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9W
RVJTSU9OKFsyXSwgWzNdKQorICAgIEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNL
X1BZVEhPTl9ERVZFTCgpCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hn
ZXR0ZXh0XSkKK0FYX0NIRUNLX1VERVYoWzU5XSkKK0FYX0NIRUNLX1VVSUQKKworIyBDaGVjayBs
aWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRfTElCCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCitB
Q19DSEVDS19MSUIoW2Fpb10sIFtpb19zZXR1cF0sIFtzeXN0ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1f
YWlvPSJuIl0pCitBQ19TVUJTVChzeXN0ZW1fYWlvKQorQUNfQ0hFQ0tfTElCKFtjcnlwdG9dLCBb
TUQ1XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYmNyeXB0b10pXSkKK0FD
X0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4dDJmc19vcGVuMl0sIFtsaWJleHQyZnM9InkiXSwgW2xp
YmV4dDJmcz0ibiJdKQorQUNfU1VCU1QobGliZXh0MmZzKQorQUNfQ0hFQ0tfTElCKFtnY3J5cHRd
LCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJd
KQorQUNfU1VCU1QobGliZ2NyeXB0KQorQUNfQ0hFQ0tfTElCKFtwdGhyZWFkXSwgW3B0aHJlYWRf
Y3JlYXRlXSwgW10gLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnB0aHJl
YWRdKV0pCitBQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2NrX2dldHRpbWVdKQorQUNfQ0hFQ0tfTElC
KFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3Qg
ZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwK
KyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5YWpsXSldKQorQUNfQ0hFQ0tfTElC
KFt6XSwgW2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHps
aWJdKV0pCitBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmljb252X29wZW5dLCBbbGliaWNvbnY9
InkiXSwgW2xpYmljb252PSJuIl0pCitBQ19TVUJTVChsaWJpY29udikKKworIyBBdXRvc2NhbiBz
dHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNrKQorIyBDaGVja3MgZm9y
IGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNfQUxMT0NBCitBQ19DSEVDS19IRUFERVJTKFsgXAorICAg
ICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGlt
aXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0
ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJp
bmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisg
ICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNs
b2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJz
aW9uLmggXAorICAgICAgICAgICAgICAgIF0pCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3Ry
dWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KK0FDX0hFQURFUl9TVERCT09M
CitBQ19UWVBFX1VJRF9UCitBQ19DX0lOTElORQorQUNfVFlQRV9JTlQxNl9UCitBQ19UWVBFX0lO
VDMyX1QKK0FDX1RZUEVfSU5UNjRfVAorQUNfVFlQRV9JTlQ4X1QKK0FDX1RZUEVfTU9ERV9UCitB
Q19UWVBFX09GRl9UCitBQ19UWVBFX1BJRF9UCitBQ19DX1JFU1RSSUNUCitBQ19UWVBFX1NJWkVf
VAorQUNfVFlQRV9TU0laRV9UCitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9ibGtz
aXplXSkKK0FDX1NUUlVDVF9TVF9CTE9DS1MKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0
LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5UMTZfVAorQUNfVFlQRV9VSU5UMzJfVAorQUNfVFlQRV9V
SU5UNjRfVAorQUNfVFlQRV9VSU5UOF9UCitBQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKKwor
IyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgorQUNfRlVOQ19FUlJPUl9BVF9MSU5FCitB
Q19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNFRUtPCitBQ19GVU5DX0xTVEFUX0ZPTExPV1NfU0xBU0hF
RF9TWU1MSU5LCitBQ19IRUFERVJfTUFKT1IKK0FDX0ZVTkNfTUFMTE9DCitBQ19GVU5DX01LVElN
RQorQUNfRlVOQ19NTUFQCitBQ19GVU5DX1JFQUxMT0MKK0FDX0ZVTkNfU1RSTkxFTgorQUNfRlVO
Q19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhp
dCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisgICAgICAg
ICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0
dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVf
ciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAgICAgICAgICAgICAgIG1rZmlmbyBt
dW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKKyAg
ICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJkdXAgc3Ry
ZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBz
dHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAorICAgICAgICAgICAgICAgIHVu
YW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIGUyNzIyYjI0
ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUKLS0t
IGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJVGh1IEphbiAyNiAxNzo0MzozMSAy
MDEyICswMDAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCVdlZCBKYW4g
MTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMjEsNyArMjEsNiBAQCB4Z19hbGwuYTogJChYR19P
QkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMgLW8gJEAgJF4KIAogeGVu
LWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVjayAKIAkkKE1BS0UpIC1DIC4uLy4u
Ly4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4uYyBNYWtlZmlsZSAkKFhHX0hEUlMp
CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9pbnN0YWxsLnNoCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2lu
c3RhbGwuc2gJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMSBAQAor
Li4vaW5zdGFsbC5zaApcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciBlMjcyMmIy
NGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUKLS0tIGEvdG9v
bHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAx
MDAKQEAgLTIsNyArMiwxMSBAQCBYRU5fUk9PVCA9ICQoQ1VSRElSKS8uLi8uLgogaW5jbHVkZSAk
KFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNl
cmZzIGlzbzk2NjAgZmF0IHpmcyB4ZnMKLVNVQkRJUlMteSArPSAkKHNoZWxsIGVudiBDQz0iJChD
QykiIC4vY2hlY2stbGliZXh0MmZzKQoraWZlcSAoJChDT05GSUdfRVhUMkZTKSwgeSkKKyAgICBT
VUJESVJTLXkgKz0gZXh0MmZzLWxpYgorZWxzZQorICAgIFNVQkRJUlMteSArPSBleHQyZnMKK2Vu
ZGlmCiAKIC5QSE9OWTogYWxsIGNsZWFuIGluc3RhbGwKIGFsbCBjbGVhbiBpbnN0YWxsOiAlOiBz
dWJkaXJzLSUKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL2xpYmZz
aW1hZ2UvY2hlY2stbGliZXh0MmZzCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0
MmZzCVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMSArMCwwIEBACi0jIS9iaW4vc2gKLQotY2F0
ID5leHQyLXRlc3QuYyA8PEVPRgotI2luY2x1ZGUgPGV4dDJmcy9leHQyZnMuaD4KLQotaW50IG1h
aW4oKQotewotCWV4dDJmc19vcGVuMjsKLX0KLUVPRgotCi0ke0NDLWdjY30gLW8gZXh0Mi10ZXN0
IGV4dDItdGVzdC5jIC1sZXh0MmZzID4vZGV2L251bGwgMj4mMQotaWYgWyAkPyA9IDAgXTsgdGhl
bgotCWVjaG8gZXh0MmZzLWxpYgotZWxzZQotCWVjaG8gZXh0MmZzCi1maQotCi1ybSAtZiBleHQy
LXRlc3QgZXh0Mi10ZXN0LmMKLQotZXhpdCAwCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3
MGU1MzlhMSB0b29scy9saWJ4ZW4vTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGVuL01ha2VmaWxl
CVRodSBKYW4gMjYgMTc6NDM6MzEgMjAxMiArMDAwMAorKysgYi90b29scy9saWJ4ZW4vTWFrZWZp
bGUJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0yMiwxMiArMjIsMTIgQEAgTUFK
T1IgPSAxLjAKIE1JTk9SID0gMAogCiBDRkxBR1MgKz0gLUlpbmNsdWRlICAgICAgICAgICAgICAg
ICAgICAgXAotICAgICAgICAgICQoc2hlbGwgeG1sMi1jb25maWcgLS1jZmxhZ3MpIFwKLSAgICAg
ICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAk
KFhNTDJfQ09ORklHKSAtLWNmbGFncykgXAorICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJ
RykgLS1jZmxhZ3MpIFwKICAgICAgICAgICAtZlBJQwogCi1MREZMQUdTICs9ICQoc2hlbGwgeG1s
Mi1jb25maWcgLS1saWJzKSBcCi0gICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1saWJz
KQorTERGTEFHUyArPSAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tbGlicykgXAorICAgICAgICAg
ICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tbGlicykKIAogTElCWEVOQVBJX0hEUlMgPSAkKHdp
bGRjYXJkIGluY2x1ZGUveGVuL2FwaS8qLmgpIGluY2x1ZGUveGVuL2FwaS94ZW5fYWxsLmgKIExJ
QlhFTkFQSV9PQkpTID0gJChwYXRzdWJzdCAlLmMsICUubywgJCh3aWxkY2FyZCBzcmMvKi5jKSkK
ZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIgODM3NTcwZTUzOWExIHRvb2xzL200L2RlZmF1bHRfbGli
Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL200L2RlZmF1bHRfbGliLm00CVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAt
MCwwICsxLDggQEAKK0FDX0RFRlVOKFtBWF9ERUZBVUxUX0xJQl0sCitbQVNfSUYoW3Rlc3QgLWQg
IiRwcmVmaXgvbGliNjQiXSwgWworICAgIExJQl9QQVRIPSJsaWI2NCIKK10sWworICAgIExJQl9Q
QVRIPSJsaWIiCitdKQorQUNfU1VCU1QoTElCX1BBVEgpXSkKKwpkaWZmIC1yIGUyNzIyYjI0ZGMw
OSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvbTQvZGlzYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2Rpc2FibGVf
ZmVhdHVyZS5tNAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMyBA
QAorQUNfREVGVU4oW0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUo
WyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhbLS1kaXNhYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lG
KFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0
ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVz
dCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdKQorJDE9JGF4X2N2XyQxCitB
Q19TVUJTVCgkMSldKQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMv
bTQvZW5hYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQJV2VkIEphbiAxMSAwNjow
NzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRU5BQkxF
X0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhb
LS1lbmFibGUtJDFdLCBbJDJdKSkKKworQVNfSUYoW3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4eWVz
Il0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0s
IFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0IC16ICRheF9jdl8kMV0sIFsKKyAgICBheF9j
dl8kMT0ibiIKK10pCiskMT0kYXhfY3ZfJDEKK0FDX1NVQlNUKCQxKV0pCmRpZmYgLXIgZTI3MjJi
MjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC9vY2FtbC5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9vY2FtbC5tNAlXZWQg
SmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyNDEgQEAKK2RubCBhdXRvY29u
ZiBtYWNyb3MgZm9yIE9DYW1sCitkbmwgZnJvbSBodHRwOi8vZm9yZ2Uub2NhbWxjb3JlLm9yZy8K
K2RubAorZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgUmljaGFyZCBXLk0uIEpvbmVzCitkbmwg
Q29weXJpZ2h0IMKpIDIwMDkgICAgICBTdGVmYW5vIFphY2NoaXJvbGkKK2RubCBDb3B5cmlnaHQg
wqkgMjAwMC0yMDA1IE9saXZpZXIgQW5kcmlldQorZG5sIENvcHlyaWdodCDCqSAyMDAwLTIwMDUg
SmVhbi1DaHJpc3RvcGhlIEZpbGxpw6J0cmUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEdl
b3JnZXMgTWFyaWFubworZG5sCitkbmwgRm9yIGRvY3VtZW50YXRpb24sIHBsZWFzZSByZWFkIHRo
ZSBvY2FtbC5tNCBtYW4gcGFnZS4KKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxdLAorW2RubAor
ICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxDXSxbb2NhbWxj
XSxbbm9dKQorCisgIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxW
RVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8
cCdgCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTl0p
CisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAgaWYgdGVzdCAiJE9DQU1M
TElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYv
bnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAorICAgICBlbHNlCisg
ICAgICAgIEFDX01TR19SRVNVTFQoW09DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5n
IGl0Ll0pCisgICAgIGZpCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIGxpYnJhcnkgcGF0aCBp
cyAkT0NBTUxMSUJdKQorCisgICAgIEFDX1NVQlNUKFtPQ0FNTFZFUlNJT05dKQorICAgICBBQ19T
VUJTVChbT0NBTUxMSUJdKQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIEFD
X0NIRUNLX1RPT0woW09DQU1MT1BUXSxbb2NhbWxvcHRdLFtub10pCisgICAgIE9DQU1MQkVTVD1i
eXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCisJQUNfTVNHX1dBUk4o
W0Nhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5Ll0pCisgICAg
IGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9u
KiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJT
SU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j
YW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLl0pCisJICAgIE9DQU1MT1BUPW5vCisJZWxzZQorCSAg
ICBPQ0FNTEJFU1Q9b3B0CisJZmkKKyAgICAgZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxCRVNU
XSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0CisgICAgIEFDX0NIRUNLX1RPT0wo
W09DQU1MQ0RPVE9QVF0sW29jYW1sYy5vcHRdLFtub10pCisgICAgIGlmIHRlc3QgIiRPQ0FNTENE
T1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12IHwgc2Vk
IC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJT
SU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNp
b25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLl0pCisJZWxzZQor
CSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRo
ZW4KKwlBQ19DSEVDS19UT09MKFtPQ0FNTE9QVERPVE9QVF0sW29jYW1sb3B0Lm9wdF0sW25vXSkK
KwlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9O
PWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxc
MXxwJyBgCisJICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRo
ZW4KKwkgICAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9j
YW1sb3B0Lm9wdCBkaXNjYXJkZWQuXSkKKwkgICBlbHNlCisJICAgICAgT0NBTUxPUFQ9JE9DQU1M
T1BURE9UT1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAgZmkKKworICAgICBBQ19TVUJTVChb
T0NBTUxPUFRdKQorICBmaQorCisgIEFDX1NVQlNUKFtPQ0FNTENdKQorCisgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sIHRvcGxldmVsCisgIEFDX0NIRUNLX1RPT0woW09DQU1MXSxbb2NhbWxdLFtub10p
CisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxERVBd
LFtvY2FtbGRlcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIEFDX0NI
RUNLX1RPT0woW09DQU1MTUtUT1BdLFtvY2FtbG1rdG9wXSxbbm9dKQorCisgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sbWtsaWIKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxNS0xJQl0sW29jYW1sbWtsaWJd
LFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MKKyAgQUNfQ0hFQ0tfVE9PTChbT0NB
TUxET0NdLFtvY2FtbGRvY10sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisg
IEFDX0NIRUNLX1RPT0woW09DQU1MQlVJTERdLFtvY2FtbGJ1aWxkXSxbbm9dKQorXSkKKworCitB
Q19ERUZVTihbQUNfUFJPR19PQ0FNTExFWF0sCitbZG5sCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
bGV4CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYXSxbb2NhbWxsZXhdLFtub10pCisgIGlmIHRl
c3QgIiRPQ0FNTExFWCIgIT0gIm5vIjsgdGhlbgorICAgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVY
RE9UT1BUXSxbb2NhbWxsZXgub3B0XSxbbm9dKQorICAgIGlmIHRlc3QgIiRPQ0FNTExFWERPVE9Q
VCIgIT0gIm5vIjsgdGhlbgorCU9DQU1MTEVYPSRPQ0FNTExFWERPVE9QVAorICAgIGZpCisgIGZp
CisgIEFDX1NVQlNUKFtPQ0FNTExFWF0pCitdKQorCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTFlB
Q0NdLAorW2RubAorICBBQ19DSEVDS19UT09MKFtPQ0FNTFlBQ0NdLFtvY2FtbHlhY2NdLFtub10p
CisgIEFDX1NVQlNUKFtPQ0FNTFlBQ0NdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19DQU1M
UDRdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKworICAjIGNoZWNr
aW5nIGZvciBjYW1scDQKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0XSxbY2FtbHA0XSxbbm9dKQor
ICBpZiB0ZXN0ICIkQ0FNTFA0IiAhPSAibm8iOyB0aGVuCisgICAgIFRNUFZFUlNJT049YCRDQU1M
UDQgLXYgMj4mMXwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiAqXCguKlwpJHxcMXxwJ2AKKyAgICAg
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwlBQ19NU0df
UkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjXSkKKyAgICAgICAgQ0FNTFA0PW5v
CisgICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtDQU1MUDRdKQorCisgICMgY2hlY2tpbmcgZm9y
IGNvbXBhbmlvbiB0b29scworICBBQ19DSEVDS19UT09MKFtDQU1MUDRCT09UXSxbY2FtbHA0Ym9v
dF0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T10sW2NhbWxwNG9dLFtub10pCisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNE9GXSxbY2FtbHA0b2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0wo
W0NBTUxQNE9PRl0sW2NhbWxwNG9vZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T1JG
XSxbY2FtbHA0b3JmXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRQUk9GXSxbY2FtbHA0
cHJvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Ul0sW2NhbWxwNHJdLFtub10pCisg
IEFDX0NIRUNLX1RPT0woW0NBTUxQNFJGXSxbY2FtbHA0cmZdLFtub10pCisgIEFDX1NVQlNUKFtD
QU1MUDRCT09UXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9dKQorICBBQ19TVUJTVChbQ0FNTFA0T0Zd
KQorICBBQ19TVUJTVChbQ0FNTFA0T09GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9SRl0pCisgIEFD
X1NVQlNUKFtDQU1MUDRQUk9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJdKQorICBBQ19TVUJTVChb
Q0FNTFA0UkZdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19GSU5ETElCXSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxm
aW5kCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRklORF0sW29jYW1sZmluZF0sW25vXSkKKyAgQUNf
U1VCU1QoW09DQU1MRklORF0pCitdKQorCisKK2RubCBUaGFua3MgdG8gSmltIE1leWVyaW5nIGZv
ciB3b3JraW5nIHRoaXMgbmV4dCBiaXQgb3V0IGZvciB1cy4KK2RubCBYWFggV2Ugc2hvdWxkIGRl
ZmluZSBBU19UUl9TSCBpZiBpdCdzIG5vdCBkZWZpbmVkIGFscmVhZHkKK2RubCAoZWcuIGZvciBv
bGQgYXV0b2NvbmYpLgorQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1BLR10sCitbZG5sCisgIEFD
X1JFUVVJUkUoW0FDX1BST0dfRklORExJQl0pZG5sCisKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3Ig
T0NhbWwgZmluZGxpYiBwYWNrYWdlICQxXSkKKworICB1bnNldCBmb3VuZAorICB1bnNldCBwa2cK
KyAgZm91bmQ9bm8KKyAgZm9yIHBrZyBpbiAkMSAkMiA7IGRvCisgICAgaWYgJE9DQU1MRklORCBx
dWVyeSAkcGtnID4vZGV2L251bGwgMj4vZGV2L251bGw7IHRoZW4KKyAgICAgIEFDX01TR19SRVNV
TFQoW2ZvdW5kXSkKKyAgICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT0kcGtnCisgICAgICBm
b3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAgZG9uZQorICBpZiB0ZXN0ICIkZm91bmQi
ID0gIm5vIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQorICAgIEFTX1RS
X1NIKFtPQ0FNTF9QS0dfJDFdKT1ubworICBmaQorCisgIEFDX1NVQlNUKEFTX1RSX1NIKFtPQ0FN
TF9QS0dfJDFdKSkKK10pCisKKworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX01PRFVMRV0sCitb
ZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIG1vZHVsZSAkMl0pCisKKyAgY2F0ID4g
Y29uZnRlc3QubWwgPDxFT0YKK29wZW4gJDMKK0VPRgorICB1bnNldCBmb3VuZAorICBmb3IgJDEg
aW4gJCQxICQ0IDsgZG8KKyAgICBpZiAkT0NBTUxDIC1jIC1JICIkJDEiIGNvbmZ0ZXN0Lm1sID4m
NSAyPiY1IDsgdGhlbgorICAgICAgZm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRv
bmUKKworICBpZiB0ZXN0ICIkZm91bmQiIDsgdGhlbgorICAgIEFDX01TR19SRVNVTFQoWyQkMV0p
CisgIGVsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQorICAgICQxPW5vCisgIGZp
CisgIEFDX1NVQlNUKFskMV0pCitdKQorCisKK2RubCBYWFggQ3Jvc3MtY29tcGlsaW5nCitBQ19E
RUZVTihbQUNfQ0hFQ0tfT0NBTUxfV09SRF9TSVpFXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNf
UFJPR19PQ0FNTF0pZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGNvbXBpbGVyIHdv
cmQgc2l6ZV0pCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCisgIHByaW50X2VuZGxpbmUgKHN0
cmluZ19vZl9pbnQgU3lzLndvcmRfc2l6ZSkKKyAgRU9GCisgIE9DQU1MX1dPUkRfU0laRT1gJE9D
QU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFskT0NBTUxfV09SRF9TSVpFXSkKKyAg
QUNfU1VCU1QoW09DQU1MX1dPUkRfU0laRV0pCitdKQorCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NB
TUxfT1NfVFlQRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBB
Q19NU0dfQ0hFQ0tJTkcoW09DYW1sIFN5cy5vc190eXBlXSkKKworICBjYXQgPiBjb25mdGVzdC5t
bCA8PEVPRgorICBwcmludF9zdHJpbmcoU3lzLm9zX3R5cGUpOzsKK0VPRgorCisgIE9DQU1MX09T
X1RZUEU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX09TX1RZ
UEVdKQorICBBQ19TVUJTVChbT0NBTUxfT1NfVFlQRV0pCitdKQpkaWZmIC1yIGUyNzIyYjI0ZGMw
OSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvbTQvcGF0aF9vcl9mYWlsLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3BhdGhfb3JfZmFp
bC5tNAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSw2IEBACitBQ19E
RUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FDX1BBVEhfUFJPRyhbJDFdLCBbJDJdLCBb
bm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAKK3RoZW4KKyAgICBBQ19NU0dfRVJST1Io
W1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFsbCAkMl0pCitmaV0pCmRpZmYgLXIgZTI3
MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC9weXRob25fZGV2ZWwubTQKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcHl0
aG9uX2RldmVsLm00CVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDE4
IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3MucGF0aCwgc3lz
Citmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcv
TWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisnID4gL2Rldi9u
dWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBBQ19NU0dfUkVTVUxU
KFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFja2FnZSBub3QgZm91bmRd
KQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgZTI3MjJiMjRk
YzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC9weXRob25fdmVyc2lvbi5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25f
dmVyc2lvbi5tNAlXZWQgSmFuIDExIDA2OjA3OjA1IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMiBA
QAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7
IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikpJ2AKK2lmIHRlc3QgIiQ/
IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYAorICAg
IEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisgICAgICAgIFskcHl0aG9u
X3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzICQxLiQyXSkK
K2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIGUyNzIyYjI0ZGMw
OSAtciA4Mzc1NzBlNTM5YTEgdG9vbHMvbTQvcHl0aG9uX3htbC5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25feG1sLm00
CVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwIEBACitBQ19ERUZV
TihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIHht
bC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20ubWluaWRvbSdgCitp
ZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFD
X01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1vZHVsZV0pCitlbHNl
CisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBlMjcyMmIyNGRjMDkgLXIg
ODM3NTcwZTUzOWExIHRvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5tNAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9zZXRfY2ZsYWdz
X2xkZmxhZ3MubTQJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMjAg
QEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNM
VURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZs
YWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWci
Citkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURFUworZG8KKyAgICBBUFBFTkRfQ0ZM
QUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkQVBQRU5EX0xJQgorZG8KKyAg
ICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitDRkxBR1M9IiRQUkVQRU5EX0NG
TEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFHUz0iJFBSRVBFTkRfTERGTEFHUyAk
TERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1
NzBlNTM5YTEgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00CVdlZCBKYW4gMTEgMDY6MDc6MDUg
MjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfVURFVl0sCitb
aWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4KKyAgICBBQ19QQVRIX1BS
T0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVzdCB4IiR7VURFVkFETX0i
ID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtVREVWSU5GT10sIFt1
ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJTkZPfSIgPT0geCJubyIK
KyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAorICAgICAgICAgICAgICAg
IFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2
XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5GT30gLVYgfCBhd2sgJ3tw
cmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7VURFVkFETX0gaW5mbyAt
ViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVzdCAke3VkZXZ2ZXJ9IC1s
dCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQTFVHXSwgW2hvdHBsdWdd
LCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0geCJubyIKKyAgICAgICAg
dGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRvbyBvbGQsIHVwZ3JhZGUg
dG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICBB
Q19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgi
JHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBBQ19NU0dfRVJST1IoW05v
dCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkKKyAgICBmaQorZmkKK10p
CmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIDgzNzU3MGU1MzlhMSB0b29scy9tNC91dWlkLm00Ci0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200
L3V1aWQubTQJV2VkIEphbiAxMSAwNjowNzowNSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTAgQEAK
K0FDX0RFRlVOKFtBWF9DSEVDS19VVUlEXSwKK1tpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGlu
dXgtZ251IgordGhlbgorICAgIEFDX0NIRUNLX0hFQURFUihbdXVpZC91dWlkLmhdLCwKKwkgICAg
W0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzXSldKQorZWxzZQorICAgIEFD
X0NIRUNLX0hFQURFUihbdXVpZC5oXSwsCisJICAgIFtBQ19NU0dfRVJST1IoW2Nhbm5vdCBmaW5k
IHV1aWQgaGVhZGVyc10pXSkKK2ZpCitdKQpkaWZmIC1yIGUyNzIyYjI0ZGMwOSAtciA4Mzc1NzBl
NTM5YTEgdmVyc2lvbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi92ZXJzaW9uLnNoCVdlZCBKYW4gMTEgMDY6MDc6MDUgMjAxMiArMDEwMApAQCAt
MCwwICsxLDUgQEAKKyMhL2Jpbi9zaAorCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9O
IiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBY
RU5fU1VCVkVSU0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAi
JWQuJWQiICRNQUpPUiAkTUlOT1IK

--===============6253512272991086591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6253512272991086591==--


From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:42:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21: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.xensource.com>)
	id 1RtQsy-0005uG-W2; Fri, 03 Feb 2012 21:41:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <w1z2g3@gmail.com>) id 1RtQsw-0005u9-Sg
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 21:41:35 +0000
X-Env-Sender: w1z2g3@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328305286!7715054!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=2.0 required=7.0 tests=FROM_HAS_MIXED_NUMS,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24756 invoked from network); 3 Feb 2012 21:41:28 -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;
	3 Feb 2012 21:41:28 -0000
Received: by iaeh11 with SMTP id h11so22451618iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 13:41:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=DDRLKq7gXPM2HdGnz24wReNDlco73nfUUbMYq1KQxb8=;
	b=Xj/hCGUa4+MQvwf37CwXb4RVG2ZcfnO7rwEVKqb7BJWkWpQyqR48rwpw8bBJFwpQca
	ybT5z01RlRKf7xRKdxCUilW2UuVIOFNSeKk3LH8TKbUkTR1v7xnQckBf7vOQWdsxYLzn
	Yo4kl5/KbkMRh+9c5m1U19MQ7YSwLVMO57I8U=
MIME-Version: 1.0
Received: by 10.42.144.69 with SMTP id a5mr8330432icv.45.1328305285598; Fri,
	03 Feb 2012 13:41:25 -0800 (PST)
Received: by 10.231.169.213 with HTTP; Fri, 3 Feb 2012 13:41:25 -0800 (PST)
In-Reply-To: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
References: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
Date: Fri, 3 Feb 2012 16:41:25 -0500
Message-ID: <CAAarEA+7jcovDmn-++4-FRdUhrkp_J5pma6Bxt6dZWYR9akasw@mail.gmail.com>
From: Zhigang Wang <w1z2g3@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

U29ycnkgdG8gc2VuZCBkdXBsaWNhdGUgcGF0Y2hlcy4gVGhlIGZpcnN0IG1haWwgdG9vayBhIGZl
dyBob3VycyB0bwpzaG93IHVwIGluIHRoaXMgbWFpbGluZyBsaXN0LiBTbyBJIHRob3VnaHQgaXQg
ZGlkbid0IHdvcmsuIFdpbGwgd2FpdApsb25nZXIgbmV4dCB0aW1lIC4uLgoKWmhpZ2FuZwoKT24g
RnJpLCBGZWIgMywgMjAxMiBhdCAxOjM5IFBNLCBaaGlnYW5nIFdhbmcgPHpoaWdhbmcueC53YW5n
QG9yYWNsZS5jb20+IHdyb3RlOgo+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4gIyBVc2VyIFpoaWdh
bmcgV2FuZyA8emhpZ2FuZy54LndhbmdAb3JhY2xlLmNvbT4KPiAjIERhdGUgMTMyODI5NDM1MSAx
ODAwMAo+ICMgTm9kZSBJRCA5YWUzYjJiN2I0OTRhYjhmYmM1NGFhOTIzMTAxZGM0ODEzMmM2YzZl
Cj4gIyBQYXJlbnQgwqBlMjcyMmIyNGRjMDk2MmRlMzcyMTUzMjBiMDVkMWJiN2M0YzQyODY0Cj4g
bGlieGw6IGZpeCBib290bG9hZGVyIGFyZ3Mgc2V0dGluZwo+Cj4gU2lnbmVkLW9mZi1ieTogWmhp
Z2FuZyBXYW5nIDx6aGlnYW5nLngud2FuZ0BvcmFjbGUuY29tPgo+Cj4gZGlmZiAtciBlMjcyMmIy
NGRjMDkgLXIgOWFlM2IyYjdiNDk0IHRvb2xzL2xpYnhsL2xpYnhsX2Jvb3Rsb2FkZXIuYwo+IC0t
LSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2Jvb3Rsb2FkZXIuYyDCoCDCoFRodSBKYW4gMjYgMTc6NDM6
MzEgMjAxMiArMDAwMAo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2Jvb3Rsb2FkZXIuYyDCoCDC
oEZyaSBGZWIgMDMgMTM6Mzk6MTEgMjAxMiAtMDUwMAo+IEBAIC00OSw5ICs0OSwxMSBAQCBzdGF0
aWMgY2hhciAqKm1ha2VfYm9vdGxvYWRlcl9hcmdzKGxpYnhsCj4gwqAgwqAgZmxleGFycmF5X3Nl
dChhcmdzLCBucisrLCBsaWJ4bF9fc3ByaW50ZihnYywgIi0tb3V0cHV0LWRpcmVjdG9yeT0lcyIs
ICIvdmFyL3J1bi9saWJ4bC8iKSk7Cj4KPiDCoCDCoCBpZiAoaW5mby0+dS5wdi5ib290bG9hZGVy
X2FyZ3MpIHsKPiAtIMKgIMKgIMKgIMKgY2hhciAqcCA9IGluZm8tPnUucHYuYm9vdGxvYWRlcl9h
cmdzWzBdOwo+IC0gwqAgwqAgwqAgwqB3aGlsZSAoKihwKyspKQo+IC0gwqAgwqAgwqAgwqAgwqAg
wqBmbGV4YXJyYXlfc2V0KGFyZ3MsIG5yKyssIHApOwo+ICsgwqAgwqAgwqAgwqBjaGFyICoqcCA9
IGluZm8tPnUucHYuYm9vdGxvYWRlcl9hcmdzOwo+ICsgwqAgwqAgwqAgwqB3aGlsZSAoKnApIHsK
PiArIMKgIMKgIMKgIMKgIMKgIMKgZmxleGFycmF5X3NldChhcmdzLCBucisrLCAqcCk7Cj4gKyDC
oCDCoCDCoCDCoCDCoCDCoHArKzsKPiArIMKgIMKgIMKgIMKgfQo+IMKgIMKgIH0KPgo+IMKgIMKg
IGZsZXhhcnJheV9zZXQoYXJncywgbnIrKywgZGlzayk7Cj4KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29t
L3hlbi1kZXZlbAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:42:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21: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.xensource.com>)
	id 1RtQsy-0005uG-W2; Fri, 03 Feb 2012 21:41:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <w1z2g3@gmail.com>) id 1RtQsw-0005u9-Sg
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 21:41:35 +0000
X-Env-Sender: w1z2g3@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328305286!7715054!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=2.0 required=7.0 tests=FROM_HAS_MIXED_NUMS,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24756 invoked from network); 3 Feb 2012 21:41:28 -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;
	3 Feb 2012 21:41:28 -0000
Received: by iaeh11 with SMTP id h11so22451618iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 03 Feb 2012 13:41:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=DDRLKq7gXPM2HdGnz24wReNDlco73nfUUbMYq1KQxb8=;
	b=Xj/hCGUa4+MQvwf37CwXb4RVG2ZcfnO7rwEVKqb7BJWkWpQyqR48rwpw8bBJFwpQca
	ybT5z01RlRKf7xRKdxCUilW2UuVIOFNSeKk3LH8TKbUkTR1v7xnQckBf7vOQWdsxYLzn
	Yo4kl5/KbkMRh+9c5m1U19MQ7YSwLVMO57I8U=
MIME-Version: 1.0
Received: by 10.42.144.69 with SMTP id a5mr8330432icv.45.1328305285598; Fri,
	03 Feb 2012 13:41:25 -0800 (PST)
Received: by 10.231.169.213 with HTTP; Fri, 3 Feb 2012 13:41:25 -0800 (PST)
In-Reply-To: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
References: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
Date: Fri, 3 Feb 2012 16:41:25 -0500
Message-ID: <CAAarEA+7jcovDmn-++4-FRdUhrkp_J5pma6Bxt6dZWYR9akasw@mail.gmail.com>
From: Zhigang Wang <w1z2g3@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

U29ycnkgdG8gc2VuZCBkdXBsaWNhdGUgcGF0Y2hlcy4gVGhlIGZpcnN0IG1haWwgdG9vayBhIGZl
dyBob3VycyB0bwpzaG93IHVwIGluIHRoaXMgbWFpbGluZyBsaXN0LiBTbyBJIHRob3VnaHQgaXQg
ZGlkbid0IHdvcmsuIFdpbGwgd2FpdApsb25nZXIgbmV4dCB0aW1lIC4uLgoKWmhpZ2FuZwoKT24g
RnJpLCBGZWIgMywgMjAxMiBhdCAxOjM5IFBNLCBaaGlnYW5nIFdhbmcgPHpoaWdhbmcueC53YW5n
QG9yYWNsZS5jb20+IHdyb3RlOgo+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4gIyBVc2VyIFpoaWdh
bmcgV2FuZyA8emhpZ2FuZy54LndhbmdAb3JhY2xlLmNvbT4KPiAjIERhdGUgMTMyODI5NDM1MSAx
ODAwMAo+ICMgTm9kZSBJRCA5YWUzYjJiN2I0OTRhYjhmYmM1NGFhOTIzMTAxZGM0ODEzMmM2YzZl
Cj4gIyBQYXJlbnQgwqBlMjcyMmIyNGRjMDk2MmRlMzcyMTUzMjBiMDVkMWJiN2M0YzQyODY0Cj4g
bGlieGw6IGZpeCBib290bG9hZGVyIGFyZ3Mgc2V0dGluZwo+Cj4gU2lnbmVkLW9mZi1ieTogWmhp
Z2FuZyBXYW5nIDx6aGlnYW5nLngud2FuZ0BvcmFjbGUuY29tPgo+Cj4gZGlmZiAtciBlMjcyMmIy
NGRjMDkgLXIgOWFlM2IyYjdiNDk0IHRvb2xzL2xpYnhsL2xpYnhsX2Jvb3Rsb2FkZXIuYwo+IC0t
LSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2Jvb3Rsb2FkZXIuYyDCoCDCoFRodSBKYW4gMjYgMTc6NDM6
MzEgMjAxMiArMDAwMAo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2Jvb3Rsb2FkZXIuYyDCoCDC
oEZyaSBGZWIgMDMgMTM6Mzk6MTEgMjAxMiAtMDUwMAo+IEBAIC00OSw5ICs0OSwxMSBAQCBzdGF0
aWMgY2hhciAqKm1ha2VfYm9vdGxvYWRlcl9hcmdzKGxpYnhsCj4gwqAgwqAgZmxleGFycmF5X3Nl
dChhcmdzLCBucisrLCBsaWJ4bF9fc3ByaW50ZihnYywgIi0tb3V0cHV0LWRpcmVjdG9yeT0lcyIs
ICIvdmFyL3J1bi9saWJ4bC8iKSk7Cj4KPiDCoCDCoCBpZiAoaW5mby0+dS5wdi5ib290bG9hZGVy
X2FyZ3MpIHsKPiAtIMKgIMKgIMKgIMKgY2hhciAqcCA9IGluZm8tPnUucHYuYm9vdGxvYWRlcl9h
cmdzWzBdOwo+IC0gwqAgwqAgwqAgwqB3aGlsZSAoKihwKyspKQo+IC0gwqAgwqAgwqAgwqAgwqAg
wqBmbGV4YXJyYXlfc2V0KGFyZ3MsIG5yKyssIHApOwo+ICsgwqAgwqAgwqAgwqBjaGFyICoqcCA9
IGluZm8tPnUucHYuYm9vdGxvYWRlcl9hcmdzOwo+ICsgwqAgwqAgwqAgwqB3aGlsZSAoKnApIHsK
PiArIMKgIMKgIMKgIMKgIMKgIMKgZmxleGFycmF5X3NldChhcmdzLCBucisrLCAqcCk7Cj4gKyDC
oCDCoCDCoCDCoCDCoCDCoHArKzsKPiArIMKgIMKgIMKgIMKgfQo+IMKgIMKgIH0KPgo+IMKgIMKg
IGZsZXhhcnJheV9zZXQoYXJncywgbnIrKywgZGlzayk7Cj4KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBY
ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29t
L3hlbi1kZXZlbAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:56:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtR7Z-0006sa-Bd; Fri, 03 Feb 2012 21:56:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtR7W-0006lK-Vb
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 21:56:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328306192!13361758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21479 invoked from network); 3 Feb 2012 21:56:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 21:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,353,1325462400"; d="scan'208";a="10488236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 21:56:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 21:56:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtR7Q-000209-Dy;
	Fri, 03 Feb 2012 21:56:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtR7Q-00065M-9I;
	Fri, 03 Feb 2012 21:56:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11864-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 21:56:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11864: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11864 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11864/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3432abcf9380
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.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>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=3432abcf9380
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3432abcf9380
+ branch=xen-unstable
+ revision=3432abcf9380
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3432abcf9380 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 98 changesets with 335 changes to 136 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 21:56:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 21:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtR7Z-0006sa-Bd; Fri, 03 Feb 2012 21:56:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtR7W-0006lK-Vb
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 21:56:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328306192!13361758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21479 invoked from network); 3 Feb 2012 21:56:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2012 21:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,353,1325462400"; d="scan'208";a="10488236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 21:56:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 21:56:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtR7Q-000209-Dy;
	Fri, 03 Feb 2012 21:56:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtR7Q-00065M-9I;
	Fri, 03 Feb 2012 21:56:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11864-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 21:56:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11864: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11864 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11864/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3432abcf9380
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.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>
  Jim Fehlig <jfehlig@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.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-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=3432abcf9380
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3432abcf9380
+ branch=xen-unstable
+ revision=3432abcf9380
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3432abcf9380 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 98 changesets with 335 changes to 136 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 22:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 22:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtRld-0001eG-Gr; Fri, 03 Feb 2012 22:38:05 +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 1RtRlb-0001eB-ST
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 22:38:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328308630!51348183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4941 invoked from network); 3 Feb 2012 22:37:10 -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;
	3 Feb 2012 22:37:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,354,1325462400"; d="scan'208";a="10488531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 22:37:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 22:37:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtRlW-0002DX-UM;
	Fri, 03 Feb 2012 22:37:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtRlW-0002rD-Rs;
	Fri, 03 Feb 2012 22:37:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11865-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 22:37:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11865: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11865 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11865/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 03 22:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 03 Feb 2012 22:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtRld-0001eG-Gr; Fri, 03 Feb 2012 22:38:05 +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 1RtRlb-0001eB-ST
	for xen-devel@lists.xensource.com; Fri, 03 Feb 2012 22:38:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328308630!51348183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzM0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4941 invoked from network); 3 Feb 2012 22:37:10 -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;
	3 Feb 2012 22:37:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,354,1325462400"; d="scan'208";a="10488531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2012 22:37:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 3 Feb 2012 22:37:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtRlW-0002DX-UM;
	Fri, 03 Feb 2012 22:37:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtRlW-0002rD-Rs;
	Fri, 03 Feb 2012 22:37:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11865-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 3 Feb 2012 22:37:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11865: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11865 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11865/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 02:11:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 02: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.xensource.com>)
	id 1RtV57-00011a-TC; Sat, 04 Feb 2012 02:10: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 1RtV55-00011S-Ro
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 02:10:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328321371!52857438!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19195 invoked from network); 4 Feb 2012 02:09:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 02:09:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10494464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 02:10:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 02:10:19 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtV50-0003KZ-N6;
	Sat, 04 Feb 2012 02:10:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtV50-0003JG-DF;
	Sat, 04 Feb 2012 02:10:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11867-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 02:10:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11867: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11867 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11867/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 11859

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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 in 11859 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 02:11:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 02: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.xensource.com>)
	id 1RtV57-00011a-TC; Sat, 04 Feb 2012 02:10: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 1RtV55-00011S-Ro
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 02:10:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328321371!52857438!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19195 invoked from network); 4 Feb 2012 02:09:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 02:09:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10494464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 02:10:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 02:10:19 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtV50-0003KZ-N6;
	Sat, 04 Feb 2012 02:10:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtV50-0003JG-DF;
	Sat, 04 Feb 2012 02:10:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11867-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 02:10:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11867: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11867 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11867/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 11859

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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 in 11859 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-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-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-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 02:44:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 02:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtVbF-0001o2-NB; Sat, 04 Feb 2012 02:43:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RtVbD-0001nm-Om
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 02:43:35 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328323407!3976557!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDE5NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 4 Feb 2012 02:43:27 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-5.tower-21.messagelabs.com with SMTP;
	4 Feb 2012 02:43:27 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYU00FKCKWDXW@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 04 Feb 2012 10:43:25 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYU00CRFKWDEB@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 04 Feb 2012 10:43:25 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGU96956; Sat,
	04 Feb 2012 10:43:25 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138)
	by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 04 Feb 2012 10:42:59 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Sat, 04 Feb 2012 10:43:05 +0800
Date: Sat, 04 Feb 2012 02:43:05 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)"
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel][PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: Aczi5rbju5wci6fJTby+CY/eEgQg7g==
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: A+nR C1Lu C4y6 DetJ D/b1 EJ1S ETYU EUnl Eqwa GWw2 G097 HW2V
	HvVK IYTB J6sh KzyW; 1;
	eABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {D88B4A34-1973-4EE4-8EE6-B02CDD41FE5C};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sat,
	04 Feb 2012 02:43:03 GMT;
	WwBYAGUAbgAtAGQAZQB2AGUAbABdAFsAUABBAFQAQwBIAF0AIABnAHIAYQBuAHQAIAB0AGEAYgBsAGUAIABtAGEAcAAgAGUAcgByAG8AcgAgAGkAbgAgAF8AXwBnAG4AdAB0AGEAYgBfAG0AYQBwAF8AZwByAGEAbgB0AF8AcgBlAGYA
x-cr-puzzleid: {D88B4A34-1973-4EE4-8EE6-B02CDD41FE5C}
X-CFilter-Loop: Reflected
Cc: Wang Liang <hzwangliang.wang@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
	hanweidong <hanweidong@huawei.com>
Subject: [Xen-devel] [PATCH] grant table map error in __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

   In file grant_table.c function __gnttab_map_grant_ref, if __get_paged_frame failed, the effect of _set_status  previously called should be rollback, so the flag GTF_reading and _GTF_writing will be recovered. 
  

Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang Wang<hzwangliang.wang@huawei.com>

diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
--- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13 2012 +0800
+++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02 2012 +0800
@@ -566,7 +566,7 @@
             gfn = sha1 ? sha1->frame : sha2->full_page.frame;
             rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd);
             if ( rc != GNTST_okay )
-                goto unlock_out;
+                goto unlock_out_clear;
             act->gfn = gfn;
             act->domid = ld->domain_id;
             act->frame = frame;
@@ -721,7 +721,8 @@
     if ( op->flags & GNTMAP_host_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
-
+ 
+ unlock_out_clear:
     if ( !(op->flags & GNTMAP_readonly) &&
          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         gnttab_clear_flag(_GTF_writing, status);




--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)
Content-type: application/octet-stream; name=grant_table.diff
Content-transfer-encoding: base64
Content-disposition: attachment; filename=grant_table.diff; size=926;
 creation-date="Sat, 04 Feb 2012 02:37:58 GMT";
 modification-date="Sat, 04 Feb 2012 10:40:02 GMT"
Content-description: grant_table.diff

ZGlmZiAtciBjYmVkOTFlMWM4NzggeGVuLTQuMS4yL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwot
LS0gYS94ZW4tNC4xLjIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCVNhdCBGZWIgMDQgMTg6MzY6
MTMgMjAxMiArMDgwMAorKysgYi94ZW4tNC4xLjIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCVNh
dCBGZWIgMDQgMTg6NDA6MDIgMjAxMiArMDgwMApAQCAtNTY2LDcgKzU2Niw3IEBACiAgICAgICAg
ICAgICBnZm4gPSBzaGExID8gc2hhMS0+ZnJhbWUgOiBzaGEyLT5mdWxsX3BhZ2UuZnJhbWU7CiAg
ICAgICAgICAgICByYyA9IF9fZ2V0X3BhZ2VkX2ZyYW1lKGdmbiwgJmZyYW1lLCAhIShvcC0+Zmxh
Z3MgJiBHTlRNQVBfcmVhZG9ubHkpLCByZCk7CiAgICAgICAgICAgICBpZiAoIHJjICE9IEdOVFNU
X29rYXkgKQotICAgICAgICAgICAgICAgIGdvdG8gdW5sb2NrX291dDsKKyAgICAgICAgICAgICAg
ICBnb3RvIHVubG9ja19vdXRfY2xlYXI7CiAgICAgICAgICAgICBhY3QtPmdmbiA9IGdmbjsKICAg
ICAgICAgICAgIGFjdC0+ZG9taWQgPSBsZC0+ZG9tYWluX2lkOwogICAgICAgICAgICAgYWN0LT5m
cmFtZSA9IGZyYW1lOwpAQCAtNzIxLDcgKzcyMSw4IEBACiAgICAgaWYgKCBvcC0+ZmxhZ3MgJiBH
TlRNQVBfaG9zdF9tYXAgKQogICAgICAgICBhY3QtPnBpbiAtPSAob3AtPmZsYWdzICYgR05UTUFQ
X3JlYWRvbmx5KSA/CiAgICAgICAgICAgICBHTlRQSU5faHN0cl9pbmMgOiBHTlRQSU5faHN0d19p
bmM7Ci0KKyAKKyB1bmxvY2tfb3V0X2NsZWFyOgogICAgIGlmICggIShvcC0+ZmxhZ3MgJiBHTlRN
QVBfcmVhZG9ubHkpICYmCiAgICAgICAgICAhKGFjdC0+cGluICYgKEdOVFBJTl9oc3R3X21hc2t8
R05UUElOX2RldndfbWFzaykpICkKICAgICAgICAgZ250dGFiX2NsZWFyX2ZsYWcoX0dURl93cml0
aW5nLCBzdGF0dXMpOwo=

--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)--


From xen-devel-bounces@lists.xensource.com Sat Feb 04 02:44:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 02:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtVbF-0001o2-NB; Sat, 04 Feb 2012 02:43:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RtVbD-0001nm-Om
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 02:43:35 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328323407!3976557!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDE5NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 4 Feb 2012 02:43:27 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-5.tower-21.messagelabs.com with SMTP;
	4 Feb 2012 02:43:27 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYU00FKCKWDXW@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 04 Feb 2012 10:43:25 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYU00CRFKWDEB@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 04 Feb 2012 10:43:25 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGU96956; Sat,
	04 Feb 2012 10:43:25 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138)
	by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 04 Feb 2012 10:42:59 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Sat, 04 Feb 2012 10:43:05 +0800
Date: Sat, 04 Feb 2012 02:43:05 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)"
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel][PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: Aczi5rbju5wci6fJTby+CY/eEgQg7g==
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: A+nR C1Lu C4y6 DetJ D/b1 EJ1S ETYU EUnl Eqwa GWw2 G097 HW2V
	HvVK IYTB J6sh KzyW; 1;
	eABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {D88B4A34-1973-4EE4-8EE6-B02CDD41FE5C};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sat,
	04 Feb 2012 02:43:03 GMT;
	WwBYAGUAbgAtAGQAZQB2AGUAbABdAFsAUABBAFQAQwBIAF0AIABnAHIAYQBuAHQAIAB0AGEAYgBsAGUAIABtAGEAcAAgAGUAcgByAG8AcgAgAGkAbgAgAF8AXwBnAG4AdAB0AGEAYgBfAG0AYQBwAF8AZwByAGEAbgB0AF8AcgBlAGYA
x-cr-puzzleid: {D88B4A34-1973-4EE4-8EE6-B02CDD41FE5C}
X-CFilter-Loop: Reflected
Cc: Wang Liang <hzwangliang.wang@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
	hanweidong <hanweidong@huawei.com>
Subject: [Xen-devel] [PATCH] grant table map error in __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

   In file grant_table.c function __gnttab_map_grant_ref, if __get_paged_frame failed, the effect of _set_status  previously called should be rollback, so the flag GTF_reading and _GTF_writing will be recovered. 
  

Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang Wang<hzwangliang.wang@huawei.com>

diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
--- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13 2012 +0800
+++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02 2012 +0800
@@ -566,7 +566,7 @@
             gfn = sha1 ? sha1->frame : sha2->full_page.frame;
             rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd);
             if ( rc != GNTST_okay )
-                goto unlock_out;
+                goto unlock_out_clear;
             act->gfn = gfn;
             act->domid = ld->domain_id;
             act->frame = frame;
@@ -721,7 +721,8 @@
     if ( op->flags & GNTMAP_host_map )
         act->pin -= (op->flags & GNTMAP_readonly) ?
             GNTPIN_hstr_inc : GNTPIN_hstw_inc;
-
+ 
+ unlock_out_clear:
     if ( !(op->flags & GNTMAP_readonly) &&
          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
         gnttab_clear_flag(_GTF_writing, status);




--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)
Content-type: application/octet-stream; name=grant_table.diff
Content-transfer-encoding: base64
Content-disposition: attachment; filename=grant_table.diff; size=926;
 creation-date="Sat, 04 Feb 2012 02:37:58 GMT";
 modification-date="Sat, 04 Feb 2012 10:40:02 GMT"
Content-description: grant_table.diff

ZGlmZiAtciBjYmVkOTFlMWM4NzggeGVuLTQuMS4yL3hlbi9jb21tb24vZ3JhbnRfdGFibGUuYwot
LS0gYS94ZW4tNC4xLjIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCVNhdCBGZWIgMDQgMTg6MzY6
MTMgMjAxMiArMDgwMAorKysgYi94ZW4tNC4xLjIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5jCVNh
dCBGZWIgMDQgMTg6NDA6MDIgMjAxMiArMDgwMApAQCAtNTY2LDcgKzU2Niw3IEBACiAgICAgICAg
ICAgICBnZm4gPSBzaGExID8gc2hhMS0+ZnJhbWUgOiBzaGEyLT5mdWxsX3BhZ2UuZnJhbWU7CiAg
ICAgICAgICAgICByYyA9IF9fZ2V0X3BhZ2VkX2ZyYW1lKGdmbiwgJmZyYW1lLCAhIShvcC0+Zmxh
Z3MgJiBHTlRNQVBfcmVhZG9ubHkpLCByZCk7CiAgICAgICAgICAgICBpZiAoIHJjICE9IEdOVFNU
X29rYXkgKQotICAgICAgICAgICAgICAgIGdvdG8gdW5sb2NrX291dDsKKyAgICAgICAgICAgICAg
ICBnb3RvIHVubG9ja19vdXRfY2xlYXI7CiAgICAgICAgICAgICBhY3QtPmdmbiA9IGdmbjsKICAg
ICAgICAgICAgIGFjdC0+ZG9taWQgPSBsZC0+ZG9tYWluX2lkOwogICAgICAgICAgICAgYWN0LT5m
cmFtZSA9IGZyYW1lOwpAQCAtNzIxLDcgKzcyMSw4IEBACiAgICAgaWYgKCBvcC0+ZmxhZ3MgJiBH
TlRNQVBfaG9zdF9tYXAgKQogICAgICAgICBhY3QtPnBpbiAtPSAob3AtPmZsYWdzICYgR05UTUFQ
X3JlYWRvbmx5KSA/CiAgICAgICAgICAgICBHTlRQSU5faHN0cl9pbmMgOiBHTlRQSU5faHN0d19p
bmM7Ci0KKyAKKyB1bmxvY2tfb3V0X2NsZWFyOgogICAgIGlmICggIShvcC0+ZmxhZ3MgJiBHTlRN
QVBfcmVhZG9ubHkpICYmCiAgICAgICAgICAhKGFjdC0+cGluICYgKEdOVFBJTl9oc3R3X21hc2t8
R05UUElOX2RldndfbWFzaykpICkKICAgICAgICAgZ250dGFiX2NsZWFyX2ZsYWcoX0dURl93cml0
aW5nLCBzdGF0dXMpOwo=

--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Boundary_(ID_O6Y+s6uo8eoO3AQxSPEdIA)--


From xen-devel-bounces@lists.xensource.com Sat Feb 04 02:59:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 02:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtVq2-0002Zj-T6; Sat, 04 Feb 2012 02:58:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RtVq1-0002Ze-Et
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 02:58:53 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328324282!51358504!1
X-Originating-IP: [216.33.127.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10478 invoked from network); 4 Feb 2012 02:58:02 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-10.tower-27.messagelabs.com with SMTP;
	4 Feb 2012 02:58:02 -0000
Received: from imp09 ([10.20.200.9]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120204025851.QFKI5374.mta21.charter.net@imp09>
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 21:58:51 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id Veyr1i00F46xN4z05eyrna; Fri, 03 Feb 2012 21:58:51 -0500
X-Authority-Analysis: v=1.1 cv=psWcb5N98119OaOi9bjyg15qVElTHlpKZyP+LUQnThs=
	c=1 sm=1 a=nCKSWOfrIsMA:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=IkcTkHD0fZMA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=UpmPveSpo5X33LiD3VkA:9 a=rdtJ8oydgfmSr0h_v5UA:7 a=QEXdDO2ut3YA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id B12B1203D9
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 03:22:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wdRibl6qwkBW for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:22:10 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id C86EA20341
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:22:10 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Date: Fri, 3 Feb 2012 21:57:03 -0500
Message-ID: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-language: en-us
Thread-index: Aczi579OK1UDwMlhT4elwuxcGpKIsg==
Subject: [Xen-devel] xen-unstable stubdom build error version(3432abcf9380)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cGFyZW50OiAyNDY5MTozNDMyYWJjZjkzODAgdGlwCiBGaXggeDg2XzMyIGJ1aWxkCmJyYW5jaDog
ZGVmYXVsdApjb21taXQ6IDQgbW9kaWZpZWQsIDE0MzkgdW5rbm93bgp1cGRhdGU6IChjdXJyZW50
KQoKL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2NrLXZiZC5jOiBJbiBmdW5jdGlv
biDDonFlbXVfYWlvX3dhaXTDojoKL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2Nr
LXZiZC5jOjE0NzoyMDogZXJyb3I6IG1hY3JvICJyZW1vdmVfd2FpdGVyIiByZXF1aXJlcyAyIGFy
Z3VtZW50cywgYnV0IG9ubHkgMSBnaXZlbgovdXNyL3NyYy94ZW4tNC4yL3N0dWJkb20vaW9lbXUv
YmxvY2stdmJkLmM6MTQ3OjU6IGVycm9yOiDDonJlbW92ZV93YWl0ZXLDoiB1bmRlY2xhcmVkIChm
aXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikKL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11
L2Jsb2NrLXZiZC5jOjE0Nzo1OiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBpcyBy
ZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24gaXQgYXBwZWFycyBpbgptYWtlWzNd
OiAqKiogW2Jsb2NrLXZiZC5vXSBFcnJvciAxCgpTbyBJIGNoZWNrZWQgc29tZSBzaW1wbGUgc3R1
ZmYgb3V0IGFuZCBmb3VuZCB0aGlzOgpleHRyYXMvbWluaS1vcy9mYmZyb250LmM6NTcyOiAgICBy
ZW1vdmVfd2FpdGVyKHcsIGZiZnJvbnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy9saWIvc3lzLmM6
MjM3OiAgICAgICAgICAgIHJlbW92ZV93YWl0ZXIodywgY29uc29sZV9xdWV1ZSk7CmV4dHJhcy9t
aW5pLW9zL2xpYi9zeXMuYzo4MTc6ICAgIHJlbW92ZV93YWl0ZXIobmV0ZnJvbnRfdywgbmV0ZnJv
bnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy9saWIvc3lzLmM6ODE4OiAgICByZW1vdmVfd2FpdGVy
KGV2ZW50X3csIGV2ZW50X3F1ZXVlKTsKZXh0cmFzL21pbmktb3MvbGliL3N5cy5jOjgxOTogICAg
cmVtb3ZlX3dhaXRlcihibGtmcm9udF93LCBibGtmcm9udF9xdWV1ZSk7CmV4dHJhcy9taW5pLW9z
L2xpYi9zeXMuYzo4MjA6ICAgIHJlbW92ZV93YWl0ZXIoeGVuYnVzX3dhdGNoX3csIHhlbmJ1c193
YXRjaF9xdWV1ZSk7CmV4dHJhcy9taW5pLW9zL2xpYi9zeXMuYzo4MjE6ICAgIHJlbW92ZV93YWl0
ZXIoa2JkZnJvbnRfdywga2JkZnJvbnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy9saWIvc3lzLmM6
ODIyOiAgICByZW1vdmVfd2FpdGVyKGNvbnNvbGVfdywgY29uc29sZV9xdWV1ZSk7CmV4dHJhcy9t
aW5pLW9zL2Jsa2Zyb250LmM6MzI2OiAgcmVtb3ZlX3dhaXRlcih3LCBibGtmcm9udF9xdWV1ZSk7
CmV4dHJhcy9taW5pLW9zL2Jsa2Zyb250LmM6NDE3OiAgICByZW1vdmVfd2FpdGVyKHcsIGJsa2Zy
b250X3F1ZXVlKTsKZXh0cmFzL21pbmktb3MvYmxrZnJvbnQuYzo0NzM6ICAgIHJlbW92ZV93YWl0
ZXIodywgYmxrZnJvbnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy94ZW5idXMveGVuYnVzLmM6ODg6
ICAgIHJlbW92ZV93YWl0ZXIodywgeGVuYnVzX3dhdGNoX3F1ZXVlKTsKZXh0cmFzL21pbmktb3Mv
eGVuYnVzL3hlbmJ1cy5jOjQ0NDogICAgcmVtb3ZlX3dhaXRlcih3LCByZXFfaW5mb1tpZF0ud2Fp
dHEpOwpleHRyYXMvbWluaS1vcy9pbmNsdWRlL3dhaXQuaDo2MDojZGVmaW5lIHJlbW92ZV93YWl0
ZXIodywgd3EpIGRvIHsgIFwKc3R1YmRvbS9pb2VtdS9ibG9jay12YmQuYzoxNDc6ICAgIHJlbW92
ZV93YWl0ZXIodyk7CnRvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci1yZW1vdGUvYmxvY2st
dmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwp0b29scy9pb2VtdS1yZW1vdGUvYmxvY2st
dmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwp0b29scy9xZW11LXhlbi10cmFkaXRpb25h
bC1kaXIvYmxvY2stdmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwp0b29scy9pb2VtdS1k
aXIvYmxvY2stdmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwoKSXQgYXBwZWFycyB0byBt
ZSB0aGF0IHBvc3NpYmx5IEkgbmVlZCB0byBlaXRoZXIgYWRkIGEgcXVldWUgbGlrZSB0aGUgYWJv
dmUgc3lzLmMgY2FsbHMsIG9yIGRlZmluZSBhIG5ldyBtYWNybyB0aGF0IGRvZXMgbm90IG5lZWQg
YSBxdWV1ZT8KTWlrZQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Sat Feb 04 02:59:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 02:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtVq2-0002Zj-T6; Sat, 04 Feb 2012 02:58:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RtVq1-0002Ze-Et
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 02:58:53 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328324282!51358504!1
X-Originating-IP: [216.33.127.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10478 invoked from network); 4 Feb 2012 02:58:02 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-10.tower-27.messagelabs.com with SMTP;
	4 Feb 2012 02:58:02 -0000
Received: from imp09 ([10.20.200.9]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120204025851.QFKI5374.mta21.charter.net@imp09>
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 21:58:51 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id Veyr1i00F46xN4z05eyrna; Fri, 03 Feb 2012 21:58:51 -0500
X-Authority-Analysis: v=1.1 cv=psWcb5N98119OaOi9bjyg15qVElTHlpKZyP+LUQnThs=
	c=1 sm=1 a=nCKSWOfrIsMA:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=IkcTkHD0fZMA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=UpmPveSpo5X33LiD3VkA:9 a=rdtJ8oydgfmSr0h_v5UA:7 a=QEXdDO2ut3YA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id B12B1203D9
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 03:22:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wdRibl6qwkBW for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:22:10 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id C86EA20341
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:22:10 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Date: Fri, 3 Feb 2012 21:57:03 -0500
Message-ID: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-language: en-us
Thread-index: Aczi579OK1UDwMlhT4elwuxcGpKIsg==
Subject: [Xen-devel] xen-unstable stubdom build error version(3432abcf9380)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

cGFyZW50OiAyNDY5MTozNDMyYWJjZjkzODAgdGlwCiBGaXggeDg2XzMyIGJ1aWxkCmJyYW5jaDog
ZGVmYXVsdApjb21taXQ6IDQgbW9kaWZpZWQsIDE0MzkgdW5rbm93bgp1cGRhdGU6IChjdXJyZW50
KQoKL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2NrLXZiZC5jOiBJbiBmdW5jdGlv
biDDonFlbXVfYWlvX3dhaXTDojoKL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2Nr
LXZiZC5jOjE0NzoyMDogZXJyb3I6IG1hY3JvICJyZW1vdmVfd2FpdGVyIiByZXF1aXJlcyAyIGFy
Z3VtZW50cywgYnV0IG9ubHkgMSBnaXZlbgovdXNyL3NyYy94ZW4tNC4yL3N0dWJkb20vaW9lbXUv
YmxvY2stdmJkLmM6MTQ3OjU6IGVycm9yOiDDonJlbW92ZV93YWl0ZXLDoiB1bmRlY2xhcmVkIChm
aXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikKL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11
L2Jsb2NrLXZiZC5jOjE0Nzo1OiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBpcyBy
ZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24gaXQgYXBwZWFycyBpbgptYWtlWzNd
OiAqKiogW2Jsb2NrLXZiZC5vXSBFcnJvciAxCgpTbyBJIGNoZWNrZWQgc29tZSBzaW1wbGUgc3R1
ZmYgb3V0IGFuZCBmb3VuZCB0aGlzOgpleHRyYXMvbWluaS1vcy9mYmZyb250LmM6NTcyOiAgICBy
ZW1vdmVfd2FpdGVyKHcsIGZiZnJvbnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy9saWIvc3lzLmM6
MjM3OiAgICAgICAgICAgIHJlbW92ZV93YWl0ZXIodywgY29uc29sZV9xdWV1ZSk7CmV4dHJhcy9t
aW5pLW9zL2xpYi9zeXMuYzo4MTc6ICAgIHJlbW92ZV93YWl0ZXIobmV0ZnJvbnRfdywgbmV0ZnJv
bnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy9saWIvc3lzLmM6ODE4OiAgICByZW1vdmVfd2FpdGVy
KGV2ZW50X3csIGV2ZW50X3F1ZXVlKTsKZXh0cmFzL21pbmktb3MvbGliL3N5cy5jOjgxOTogICAg
cmVtb3ZlX3dhaXRlcihibGtmcm9udF93LCBibGtmcm9udF9xdWV1ZSk7CmV4dHJhcy9taW5pLW9z
L2xpYi9zeXMuYzo4MjA6ICAgIHJlbW92ZV93YWl0ZXIoeGVuYnVzX3dhdGNoX3csIHhlbmJ1c193
YXRjaF9xdWV1ZSk7CmV4dHJhcy9taW5pLW9zL2xpYi9zeXMuYzo4MjE6ICAgIHJlbW92ZV93YWl0
ZXIoa2JkZnJvbnRfdywga2JkZnJvbnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy9saWIvc3lzLmM6
ODIyOiAgICByZW1vdmVfd2FpdGVyKGNvbnNvbGVfdywgY29uc29sZV9xdWV1ZSk7CmV4dHJhcy9t
aW5pLW9zL2Jsa2Zyb250LmM6MzI2OiAgcmVtb3ZlX3dhaXRlcih3LCBibGtmcm9udF9xdWV1ZSk7
CmV4dHJhcy9taW5pLW9zL2Jsa2Zyb250LmM6NDE3OiAgICByZW1vdmVfd2FpdGVyKHcsIGJsa2Zy
b250X3F1ZXVlKTsKZXh0cmFzL21pbmktb3MvYmxrZnJvbnQuYzo0NzM6ICAgIHJlbW92ZV93YWl0
ZXIodywgYmxrZnJvbnRfcXVldWUpOwpleHRyYXMvbWluaS1vcy94ZW5idXMveGVuYnVzLmM6ODg6
ICAgIHJlbW92ZV93YWl0ZXIodywgeGVuYnVzX3dhdGNoX3F1ZXVlKTsKZXh0cmFzL21pbmktb3Mv
eGVuYnVzL3hlbmJ1cy5jOjQ0NDogICAgcmVtb3ZlX3dhaXRlcih3LCByZXFfaW5mb1tpZF0ud2Fp
dHEpOwpleHRyYXMvbWluaS1vcy9pbmNsdWRlL3dhaXQuaDo2MDojZGVmaW5lIHJlbW92ZV93YWl0
ZXIodywgd3EpIGRvIHsgIFwKc3R1YmRvbS9pb2VtdS9ibG9jay12YmQuYzoxNDc6ICAgIHJlbW92
ZV93YWl0ZXIodyk7CnRvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci1yZW1vdGUvYmxvY2st
dmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwp0b29scy9pb2VtdS1yZW1vdGUvYmxvY2st
dmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwp0b29scy9xZW11LXhlbi10cmFkaXRpb25h
bC1kaXIvYmxvY2stdmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwp0b29scy9pb2VtdS1k
aXIvYmxvY2stdmJkLmM6MTQ3OiAgICByZW1vdmVfd2FpdGVyKHcpOwoKSXQgYXBwZWFycyB0byBt
ZSB0aGF0IHBvc3NpYmx5IEkgbmVlZCB0byBlaXRoZXIgYWRkIGEgcXVldWUgbGlrZSB0aGUgYWJv
dmUgc3lzLmMgY2FsbHMsIG9yIGRlZmluZSBhIG5ldyBtYWNybyB0aGF0IGRvZXMgbm90IG5lZWQg
YSBxdWV1ZT8KTWlrZQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Sat Feb 04 03:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 03:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtWLR-0003IU-87; Sat, 04 Feb 2012 03:31:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RtWLP-0003IC-QJ
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 03:31:20 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328326273!3978806!1
X-Originating-IP: [216.33.127.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14820 invoked from network); 4 Feb 2012 03:31:13 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-5.tower-21.messagelabs.com with SMTP;
	4 Feb 2012 03:31:13 -0000
Received: from imp10 ([10.20.200.15]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120204033113.QPMT5374.mta21.charter.net@imp10>
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 22:31:13 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp10 with smtp.charter.net
	id VfXC1i00N46xN4z05fXCGJ; Fri, 03 Feb 2012 22:31:13 -0500
X-Authority-Analysis: v=1.1 cv=JYQIUidRAECiNa+jsiaNMIhYElg3H2WoMKCJIGO75f4=
	c=1 sm=1 a=nfQgejgS_b0A:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=IkcTkHD0fZMA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=SEF7xSSsAAAA:8 a=n-dvuEYv7QX0C56wdakA:9 a=glx4xqaxW70NG6D_6tYA:7
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 5D959203DC
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 03:55:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 9eTzPWPsH-nw for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:54:32 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 78E1B20341
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:54:32 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
References: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
In-Reply-To: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
Date: Fri, 3 Feb 2012 22:29:25 -0500
Message-ID: <000b01cce2ed$34bbef40$9e33cdc0$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-language: en-us
Thread-index: AQD9Hq/IDaPV/qpFbVjg3w4CpU8TgJfLnJjQ
Subject: Re: [Xen-devel] xen-unstable stubdom build error
	version(3432abcf9380)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Cgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogeGVuLWRldmVsLWJvdW5jZXNA
bGlzdHMueGVuc291cmNlLmNvbSBbbWFpbHRvOnhlbi1kZXZlbC0KPiBib3VuY2VzQGxpc3RzLnhl
bnNvdXJjZS5jb21dIE9uIEJlaGFsZiBPZiBNaWNoYWVsIEEuIENvbGxpbnMKPiBTZW50OiBGcmlk
YXksIEZlYnJ1YXJ5IDAzLCAyMDEyIDk6NTcgUE0KPiBUbzogeGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KPiBTdWJqZWN0OiBbWGVuLWRldmVsXSB4ZW4tdW5zdGFibGUgc3R1YmRvbSBidWls
ZCBlcnJvcgo+IHZlcnNpb24oMzQzMmFiY2Y5MzgwKQo+IAo+IHBhcmVudDogMjQ2OTE6MzQzMmFi
Y2Y5MzgwIHRpcAo+ICBGaXggeDg2XzMyIGJ1aWxkCj4gYnJhbmNoOiBkZWZhdWx0Cj4gY29tbWl0
OiA0IG1vZGlmaWVkLCAxNDM5IHVua25vd24KPiB1cGRhdGU6IChjdXJyZW50KQo+IAo+IC91c3Iv
c3JjL3hlbi00LjIvc3R1YmRvbS9pb2VtdS9ibG9jay12YmQuYzogSW4gZnVuY3Rpb24KPiDDonFl
bXVfYWlvX3dhaXTDojoKPiAvdXNyL3NyYy94ZW4tNC4yL3N0dWJkb20vaW9lbXUvYmxvY2stdmJk
LmM6MTQ3OjIwOiBlcnJvcjogbWFjcm8KPiAicmVtb3ZlX3dhaXRlciIgcmVxdWlyZXMgMiBhcmd1
bWVudHMsIGJ1dCBvbmx5IDEgZ2l2ZW4KPiAvdXNyL3NyYy94ZW4tNC4yL3N0dWJkb20vaW9lbXUv
YmxvY2stdmJkLmM6MTQ3OjU6IGVycm9yOgo+IMOicmVtb3ZlX3dhaXRlcsOiIHVuZGVjbGFyZWQg
KGZpcnN0IHVzZSBpbiB0aGlzIGZ1bmN0aW9uKQo+IC91c3Ivc3JjL3hlbi00LjIvc3R1YmRvbS9p
b2VtdS9ibG9jay12YmQuYzoxNDc6NTogbm90ZTogZWFjaCB1bmRlY2xhcmVkCj4gaWRlbnRpZmll
ciBpcyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24gaXQgYXBwZWFycyBpbgo+
IG1ha2VbM106ICoqKiBbYmxvY2stdmJkLm9dIEVycm9yIDEKPiAKCkkgd2VudCBhaGVhZCBhbmQg
Y2xvbmVkIGludG8gYSBuZXcgZGlyZWN0b3J5IGFuZCBhbGwgaXMgcmlnaHQgd2l0aCB0aGUgd29y
bGQgYWdhaW4uCk1pa2UKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Feb 04 03:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 03:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtWLR-0003IU-87; Sat, 04 Feb 2012 03:31:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RtWLP-0003IC-QJ
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 03:31:20 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328326273!3978806!1
X-Originating-IP: [216.33.127.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14820 invoked from network); 4 Feb 2012 03:31:13 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-5.tower-21.messagelabs.com with SMTP;
	4 Feb 2012 03:31:13 -0000
Received: from imp10 ([10.20.200.15]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120204033113.QPMT5374.mta21.charter.net@imp10>
	for <xen-devel@lists.xensource.com>; Fri, 3 Feb 2012 22:31:13 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp10 with smtp.charter.net
	id VfXC1i00N46xN4z05fXCGJ; Fri, 03 Feb 2012 22:31:13 -0500
X-Authority-Analysis: v=1.1 cv=JYQIUidRAECiNa+jsiaNMIhYElg3H2WoMKCJIGO75f4=
	c=1 sm=1 a=nfQgejgS_b0A:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=IkcTkHD0fZMA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=SEF7xSSsAAAA:8 a=n-dvuEYv7QX0C56wdakA:9 a=glx4xqaxW70NG6D_6tYA:7
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 5D959203DC
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 03:55:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 9eTzPWPsH-nw for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:54:32 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 78E1B20341
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 22:54:32 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
References: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
In-Reply-To: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
Date: Fri, 3 Feb 2012 22:29:25 -0500
Message-ID: <000b01cce2ed$34bbef40$9e33cdc0$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-language: en-us
Thread-index: AQD9Hq/IDaPV/qpFbVjg3w4CpU8TgJfLnJjQ
Subject: Re: [Xen-devel] xen-unstable stubdom build error
	version(3432abcf9380)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Cgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogeGVuLWRldmVsLWJvdW5jZXNA
bGlzdHMueGVuc291cmNlLmNvbSBbbWFpbHRvOnhlbi1kZXZlbC0KPiBib3VuY2VzQGxpc3RzLnhl
bnNvdXJjZS5jb21dIE9uIEJlaGFsZiBPZiBNaWNoYWVsIEEuIENvbGxpbnMKPiBTZW50OiBGcmlk
YXksIEZlYnJ1YXJ5IDAzLCAyMDEyIDk6NTcgUE0KPiBUbzogeGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KPiBTdWJqZWN0OiBbWGVuLWRldmVsXSB4ZW4tdW5zdGFibGUgc3R1YmRvbSBidWls
ZCBlcnJvcgo+IHZlcnNpb24oMzQzMmFiY2Y5MzgwKQo+IAo+IHBhcmVudDogMjQ2OTE6MzQzMmFi
Y2Y5MzgwIHRpcAo+ICBGaXggeDg2XzMyIGJ1aWxkCj4gYnJhbmNoOiBkZWZhdWx0Cj4gY29tbWl0
OiA0IG1vZGlmaWVkLCAxNDM5IHVua25vd24KPiB1cGRhdGU6IChjdXJyZW50KQo+IAo+IC91c3Iv
c3JjL3hlbi00LjIvc3R1YmRvbS9pb2VtdS9ibG9jay12YmQuYzogSW4gZnVuY3Rpb24KPiDDonFl
bXVfYWlvX3dhaXTDojoKPiAvdXNyL3NyYy94ZW4tNC4yL3N0dWJkb20vaW9lbXUvYmxvY2stdmJk
LmM6MTQ3OjIwOiBlcnJvcjogbWFjcm8KPiAicmVtb3ZlX3dhaXRlciIgcmVxdWlyZXMgMiBhcmd1
bWVudHMsIGJ1dCBvbmx5IDEgZ2l2ZW4KPiAvdXNyL3NyYy94ZW4tNC4yL3N0dWJkb20vaW9lbXUv
YmxvY2stdmJkLmM6MTQ3OjU6IGVycm9yOgo+IMOicmVtb3ZlX3dhaXRlcsOiIHVuZGVjbGFyZWQg
KGZpcnN0IHVzZSBpbiB0aGlzIGZ1bmN0aW9uKQo+IC91c3Ivc3JjL3hlbi00LjIvc3R1YmRvbS9p
b2VtdS9ibG9jay12YmQuYzoxNDc6NTogbm90ZTogZWFjaCB1bmRlY2xhcmVkCj4gaWRlbnRpZmll
ciBpcyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24gaXQgYXBwZWFycyBpbgo+
IG1ha2VbM106ICoqKiBbYmxvY2stdmJkLm9dIEVycm9yIDEKPiAKCkkgd2VudCBhaGVhZCBhbmQg
Y2xvbmVkIGludG8gYSBuZXcgZGlyZWN0b3J5IGFuZCBhbGwgaXMgcmlnaHQgd2l0aCB0aGUgd29y
bGQgYWdhaW4uCk1pa2UKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Feb 04 03:53:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 03: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.xensource.com>)
	id 1RtWgE-0003vG-6q; Sat, 04 Feb 2012 03:52:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtWgC-0003v8-T0
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 03:52:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328327562!15258584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28910 invoked from network); 4 Feb 2012 03:52: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;
	4 Feb 2012 03:52:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10494834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 03:52:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 03:52:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtWg5-0003rd-Cm;
	Sat, 04 Feb 2012 03:52:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtWg4-0003W2-S8;
	Sat, 04 Feb 2012 03:52:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11868-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 03:52:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11868: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11868 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11868/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11864

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11864

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  3432abcf9380
baseline version:
 xen                  3432abcf9380

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 03:53:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 03: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.xensource.com>)
	id 1RtWgE-0003vG-6q; Sat, 04 Feb 2012 03:52:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtWgC-0003v8-T0
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 03:52:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328327562!15258584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28910 invoked from network); 4 Feb 2012 03:52: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;
	4 Feb 2012 03:52:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10494834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 03:52:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 03:52:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtWg5-0003rd-Cm;
	Sat, 04 Feb 2012 03:52:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtWg4-0003W2-S8;
	Sat, 04 Feb 2012 03:52:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11868-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 03:52:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11868: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11868 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11868/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11864

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11864

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  3432abcf9380
baseline version:
 xen                  3432abcf9380

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 04:59:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 04: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.xensource.com>)
	id 1RtXi8-0004mh-JL; Sat, 04 Feb 2012 04:58:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RtXi6-0004mZ-KS
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 04:58:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328331522!11748977!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxOTkyNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12915 invoked from network); 4 Feb 2012 04:58:43 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.83) by server-14.tower-174.messagelabs.com with SMTP;
	4 Feb 2012 04:58:43 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 357175EC072
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 20:58:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sLP9DREOXqsfQuwnO4vo1s+krox212ZykbKs43EGz/D0
	/a4Kh8fMhTHu4i+6VKeOBDX4N7O3iuYblMYQeb0EcWkiaGntmhTeR293emM4Whx9
	QaW+QYn/R0gOJwJLR+Mn5tea4S5ZvX5KzdAA+jd3vi/7jBQh+C0z/W5iPsyZc6c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=j9fGxRBlehrMikok+1aQ78jlvuI=; b=ZYQq3nI02XU
	8rM2AvQuRHjFEa6kH+0zbMSSdtAczxmxtySV36x9c17RFI+5fMBLu9G+0GoVHxzw
	oMsMbXnupufk5Xs4T56P8LrTdmaAvpDi63a4bAHmc+rLLpSXggoCY7OMmT/LB0n0
	hYYejVA3xh1q7OycFUsFizoMF2Xxya/0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id A45C55EC014
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 20:58:41 -0800 (PST)
Received: from 108.161.115.149 (proxying for 108.161.115.149)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 3 Feb 2012 20:58:42 -0800
Message-ID: <2d60b95d3d325ca3e492bb2504bf2cca.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2630.1328327569.1471.xen-devel@lists.xensource.com>
References: <mailman.2630.1328327569.1471.xen-devel@lists.xensource.com>
Date: Fri, 3 Feb 2012 20:58:42 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Sat, 04 Feb 2012 02:43:05 +0000
> From: Liuyongan <liuyongan@huawei.com>
> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Cc: Wang Liang <hzwangliang.wang@huawei.com>,	Zhanghaoyu
> 	<haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
> 	hanweidong <hanweidong@huawei.com>
> Subject: [Xen-devel] [PATCH] grant table map error in
> 	__gnttab_map_grant_ref
> Message-ID:
> 	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>    In file grant_table.c function __gnttab_map_grant_ref, if
> __get_paged_frame failed, the effect of _set_status  previously called
> should be rollback, so the flag GTF_reading and _GTF_writing will be
> recovered.
>
>
> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
> Wang<hzwangliang.wang@huawei.com>

Hi,
great fix! Would you mind submitting the same fix to the unstable tree?

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13 2012 +0800
> +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02 2012 +0800
> @@ -566,7 +566,7 @@
>              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
>              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
> GNTMAP_readonly), rd);
>              if ( rc != GNTST_okay )
> -                goto unlock_out;
> +                goto unlock_out_clear;
>              act->gfn = gfn;
>              act->domid = ld->domain_id;
>              act->frame = frame;
> @@ -721,7 +721,8 @@
>      if ( op->flags & GNTMAP_host_map )
>          act->pin -= (op->flags & GNTMAP_readonly) ?
>              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> -
> +
> + unlock_out_clear:
>      if ( !(op->flags & GNTMAP_readonly) &&
>           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>          gnttab_clear_flag(_GTF_writing, status);
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: grant_table.diff
> Type: application/octet-stream
> Size: 926 bytes
> Desc: grant_table.diff
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120204/686972ee/attachment.obj>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 3 Feb 2012 21:57:03 -0500
> From: "Michael A. Collins" <mike.a.collins@ark-net.org>
> To: <xen-devel@lists.xensource.com>
> Subject: [Xen-devel] xen-unstable stubdom build error
> 	version(3432abcf9380)
> Message-ID: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
> Content-Type: text/plain;	charset="utf-8"
>
> parent: 24691:3432abcf9380 tip
>  Fix x86_32 build
> branch: default
> commit: 4 modified, 1439 unknown
> update: (current)
>
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c: In function ?qemu_aio_wait?:
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:20: error: macro
> "remove_waiter" requires 2 arguments, but only 1 given
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: error: ?remove_waiter?
> undeclared (first use in this function)
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: note: each undeclared
> identifier is reported only once for each function it appears in
> make[3]: *** [block-vbd.o] Error 1
>
> So I checked some simple stuff out and found this:
> extras/mini-os/fbfront.c:572:    remove_waiter(w, fbfront_queue);
> extras/mini-os/lib/sys.c:237:            remove_waiter(w, console_queue);
> extras/mini-os/lib/sys.c:817:    remove_waiter(netfront_w,
> netfront_queue);
> extras/mini-os/lib/sys.c:818:    remove_waiter(event_w, event_queue);
> extras/mini-os/lib/sys.c:819:    remove_waiter(blkfront_w,
> blkfront_queue);
> extras/mini-os/lib/sys.c:820:    remove_waiter(xenbus_watch_w,
> xenbus_watch_queue);
> extras/mini-os/lib/sys.c:821:    remove_waiter(kbdfront_w,
> kbdfront_queue);
> extras/mini-os/lib/sys.c:822:    remove_waiter(console_w, console_queue);
> extras/mini-os/blkfront.c:326:  remove_waiter(w, blkfront_queue);
> extras/mini-os/blkfront.c:417:    remove_waiter(w, blkfront_queue);
> extras/mini-os/blkfront.c:473:    remove_waiter(w, blkfront_queue);
> extras/mini-os/xenbus/xenbus.c:88:    remove_waiter(w,
> xenbus_watch_queue);
> extras/mini-os/xenbus/xenbus.c:444:    remove_waiter(w,
> req_info[id].waitq);
> extras/mini-os/include/wait.h:60:#define remove_waiter(w, wq) do {  \
> stubdom/ioemu/block-vbd.c:147:    remove_waiter(w);
> tools/qemu-xen-traditional-dir-remote/block-vbd.c:147:
> remove_waiter(w);
> tools/ioemu-remote/block-vbd.c:147:    remove_waiter(w);
> tools/qemu-xen-traditional-dir/block-vbd.c:147:    remove_waiter(w);
> tools/ioemu-dir/block-vbd.c:147:    remove_waiter(w);
>
> It appears to me that possibly I need to either add a queue like the above
> sys.c calls, or define a new macro that does not need a queue?
> Mike
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 3 Feb 2012 22:29:25 -0500
> From: "Michael A. Collins" <mike.a.collins@ark-net.org>
> To: <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] xen-unstable stubdom build error
> 	version(3432abcf9380)
> Message-ID: <000b01cce2ed$34bbef40$9e33cdc0$@ark-net.org>
> Content-Type: text/plain;	charset="utf-8"
>
>
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Michael A. Collins
>> Sent: Friday, February 03, 2012 9:57 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] xen-unstable stubdom build error
>> version(3432abcf9380)
>>
>> parent: 24691:3432abcf9380 tip
>>  Fix x86_32 build
>> branch: default
>> commit: 4 modified, 1439 unknown
>> update: (current)
>>
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c: In function
>> ?qemu_aio_wait?:
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:20: error: macro
>> "remove_waiter" requires 2 arguments, but only 1 given
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: error:
>> ?remove_waiter? undeclared (first use in this function)
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: note: each undeclared
>> identifier is reported only once for each function it appears in
>> make[3]: *** [block-vbd.o] Error 1
>>
>
> I went ahead and cloned into a new directory and all is right with the
> world again.
> Mike
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 4 Feb 2012 03:52:40 +0000
> From: xen.org <ian.jackson@eu.citrix.com>
> To: <xen-devel@lists.xensource.com>
> Cc: ian.jackson@eu.citrix.com
> Subject: [Xen-devel] [xen-unstable test] 11868: tolerable FAIL
> Message-ID: <osstest-11868-mainreport@xen.org>
> Content-Type: text/plain
>
> flight 11868 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11868/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in
> 11864
>
> Regressions which are regarded as allowable (not blocking):
>  test-i386-i386-win           14 guest-start.2                fail   like
> 11864
>
> Tests which did not succeed, but are not blocking:
>  test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never
> pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never
> pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never
> pass
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
> pass
>  test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never
> pass
>  test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never
> pass
>  test-amd64-i386-rhel6hvm-amd 11 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-i386-win          16 leak-check/check             fail   never
> pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
> pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never
> pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never
> pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never
> pass
>  test-i386-i386-xl-winxpsp3   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:
>  xen                  3432abcf9380
> baseline version:
>  xen                  3432abcf9380
>
> jobs:
>  build-amd64                                                  pass
>  build-i386                                                   pass
>  build-amd64-oldkern                                          pass
>  build-i386-oldkern                                           pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          pass
>  test-amd64-i386-xl                                           pass
>  test-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 fail
>  test-amd64-i386-qemuu-rhel6hvm-amd                           fail
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail
>  test-amd64-amd64-xl-win7-amd64                               fail
>  test-amd64-i386-xl-win7-amd64                                fail
>  test-amd64-i386-xl-credit2                                   pass
>  test-amd64-amd64-xl-pcipt-intel                              fail
>  test-amd64-i386-rhel6hvm-intel                               fail
>  test-amd64-i386-qemuu-rhel6hvm-intel                         fail
>  test-amd64-i386-xl-multivcpu                                 pass
>  test-amd64-amd64-pair                                        pass
>  test-amd64-i386-pair                                         pass
>  test-i386-i386-pair                                          pass
>  test-amd64-amd64-xl-sedf-pin                                 fail
>  test-amd64-amd64-pv                                          pass
>  test-amd64-i386-pv                                           pass
>  test-i386-i386-pv                                            pass
>  test-amd64-amd64-xl-sedf                                     pass
>  test-amd64-i386-win-vcpus1                                   fail
>  test-amd64-i386-xl-win-vcpus1                                fail
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail
>  test-amd64-amd64-win                                         fail
>  test-amd64-i386-win                                          fail
>  test-i386-i386-win                                           fail
>  test-amd64-amd64-xl-win                                      fail
>  test-i386-i386-xl-win                                        fail
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail
>  test-i386-i386-xl-qemuu-winxpsp3                             fail
>  test-amd64-i386-xend-winxpsp3                                fail
>  test-amd64-amd64-xl-winxpsp3                                 fail
>  test-i386-i386-xl-winxpsp3                                   fail
>
>
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
>
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>
>
> Published tested tree is already up to date.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 84, Issue 82
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 04:59:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 04: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.xensource.com>)
	id 1RtXi8-0004mh-JL; Sat, 04 Feb 2012 04:58:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RtXi6-0004mZ-KS
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 04:58:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328331522!11748977!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxOTkyNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12915 invoked from network); 4 Feb 2012 04:58:43 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.83) by server-14.tower-174.messagelabs.com with SMTP;
	4 Feb 2012 04:58:43 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 357175EC072
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 20:58:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sLP9DREOXqsfQuwnO4vo1s+krox212ZykbKs43EGz/D0
	/a4Kh8fMhTHu4i+6VKeOBDX4N7O3iuYblMYQeb0EcWkiaGntmhTeR293emM4Whx9
	QaW+QYn/R0gOJwJLR+Mn5tea4S5ZvX5KzdAA+jd3vi/7jBQh+C0z/W5iPsyZc6c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=j9fGxRBlehrMikok+1aQ78jlvuI=; b=ZYQq3nI02XU
	8rM2AvQuRHjFEa6kH+0zbMSSdtAczxmxtySV36x9c17RFI+5fMBLu9G+0GoVHxzw
	oMsMbXnupufk5Xs4T56P8LrTdmaAvpDi63a4bAHmc+rLLpSXggoCY7OMmT/LB0n0
	hYYejVA3xh1q7OycFUsFizoMF2Xxya/0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id A45C55EC014
	for <xen-devel@lists.xensource.com>;
	Fri,  3 Feb 2012 20:58:41 -0800 (PST)
Received: from 108.161.115.149 (proxying for 108.161.115.149)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 3 Feb 2012 20:58:42 -0800
Message-ID: <2d60b95d3d325ca3e492bb2504bf2cca.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.2630.1328327569.1471.xen-devel@lists.xensource.com>
References: <mailman.2630.1328327569.1471.xen-devel@lists.xensource.com>
Date: Fri, 3 Feb 2012 20:58:42 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Sat, 04 Feb 2012 02:43:05 +0000
> From: Liuyongan <liuyongan@huawei.com>
> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Cc: Wang Liang <hzwangliang.wang@huawei.com>,	Zhanghaoyu
> 	<haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
> 	hanweidong <hanweidong@huawei.com>
> Subject: [Xen-devel] [PATCH] grant table map error in
> 	__gnttab_map_grant_ref
> Message-ID:
> 	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>    In file grant_table.c function __gnttab_map_grant_ref, if
> __get_paged_frame failed, the effect of _set_status  previously called
> should be rollback, so the flag GTF_reading and _GTF_writing will be
> recovered.
>
>
> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
> Wang<hzwangliang.wang@huawei.com>

Hi,
great fix! Would you mind submitting the same fix to the unstable tree?

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13 2012 +0800
> +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02 2012 +0800
> @@ -566,7 +566,7 @@
>              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
>              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
> GNTMAP_readonly), rd);
>              if ( rc != GNTST_okay )
> -                goto unlock_out;
> +                goto unlock_out_clear;
>              act->gfn = gfn;
>              act->domid = ld->domain_id;
>              act->frame = frame;
> @@ -721,7 +721,8 @@
>      if ( op->flags & GNTMAP_host_map )
>          act->pin -= (op->flags & GNTMAP_readonly) ?
>              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> -
> +
> + unlock_out_clear:
>      if ( !(op->flags & GNTMAP_readonly) &&
>           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>          gnttab_clear_flag(_GTF_writing, status);
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: grant_table.diff
> Type: application/octet-stream
> Size: 926 bytes
> Desc: grant_table.diff
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120204/686972ee/attachment.obj>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 3 Feb 2012 21:57:03 -0500
> From: "Michael A. Collins" <mike.a.collins@ark-net.org>
> To: <xen-devel@lists.xensource.com>
> Subject: [Xen-devel] xen-unstable stubdom build error
> 	version(3432abcf9380)
> Message-ID: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
> Content-Type: text/plain;	charset="utf-8"
>
> parent: 24691:3432abcf9380 tip
>  Fix x86_32 build
> branch: default
> commit: 4 modified, 1439 unknown
> update: (current)
>
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c: In function ?qemu_aio_wait?:
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:20: error: macro
> "remove_waiter" requires 2 arguments, but only 1 given
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: error: ?remove_waiter?
> undeclared (first use in this function)
> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: note: each undeclared
> identifier is reported only once for each function it appears in
> make[3]: *** [block-vbd.o] Error 1
>
> So I checked some simple stuff out and found this:
> extras/mini-os/fbfront.c:572:    remove_waiter(w, fbfront_queue);
> extras/mini-os/lib/sys.c:237:            remove_waiter(w, console_queue);
> extras/mini-os/lib/sys.c:817:    remove_waiter(netfront_w,
> netfront_queue);
> extras/mini-os/lib/sys.c:818:    remove_waiter(event_w, event_queue);
> extras/mini-os/lib/sys.c:819:    remove_waiter(blkfront_w,
> blkfront_queue);
> extras/mini-os/lib/sys.c:820:    remove_waiter(xenbus_watch_w,
> xenbus_watch_queue);
> extras/mini-os/lib/sys.c:821:    remove_waiter(kbdfront_w,
> kbdfront_queue);
> extras/mini-os/lib/sys.c:822:    remove_waiter(console_w, console_queue);
> extras/mini-os/blkfront.c:326:  remove_waiter(w, blkfront_queue);
> extras/mini-os/blkfront.c:417:    remove_waiter(w, blkfront_queue);
> extras/mini-os/blkfront.c:473:    remove_waiter(w, blkfront_queue);
> extras/mini-os/xenbus/xenbus.c:88:    remove_waiter(w,
> xenbus_watch_queue);
> extras/mini-os/xenbus/xenbus.c:444:    remove_waiter(w,
> req_info[id].waitq);
> extras/mini-os/include/wait.h:60:#define remove_waiter(w, wq) do {  \
> stubdom/ioemu/block-vbd.c:147:    remove_waiter(w);
> tools/qemu-xen-traditional-dir-remote/block-vbd.c:147:
> remove_waiter(w);
> tools/ioemu-remote/block-vbd.c:147:    remove_waiter(w);
> tools/qemu-xen-traditional-dir/block-vbd.c:147:    remove_waiter(w);
> tools/ioemu-dir/block-vbd.c:147:    remove_waiter(w);
>
> It appears to me that possibly I need to either add a queue like the above
> sys.c calls, or define a new macro that does not need a queue?
> Mike
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 3 Feb 2012 22:29:25 -0500
> From: "Michael A. Collins" <mike.a.collins@ark-net.org>
> To: <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] xen-unstable stubdom build error
> 	version(3432abcf9380)
> Message-ID: <000b01cce2ed$34bbef40$9e33cdc0$@ark-net.org>
> Content-Type: text/plain;	charset="utf-8"
>
>
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Michael A. Collins
>> Sent: Friday, February 03, 2012 9:57 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] xen-unstable stubdom build error
>> version(3432abcf9380)
>>
>> parent: 24691:3432abcf9380 tip
>>  Fix x86_32 build
>> branch: default
>> commit: 4 modified, 1439 unknown
>> update: (current)
>>
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c: In function
>> ?qemu_aio_wait?:
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:20: error: macro
>> "remove_waiter" requires 2 arguments, but only 1 given
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: error:
>> ?remove_waiter? undeclared (first use in this function)
>> /usr/src/xen-4.2/stubdom/ioemu/block-vbd.c:147:5: note: each undeclared
>> identifier is reported only once for each function it appears in
>> make[3]: *** [block-vbd.o] Error 1
>>
>
> I went ahead and cloned into a new directory and all is right with the
> world again.
> Mike
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 4 Feb 2012 03:52:40 +0000
> From: xen.org <ian.jackson@eu.citrix.com>
> To: <xen-devel@lists.xensource.com>
> Cc: ian.jackson@eu.citrix.com
> Subject: [Xen-devel] [xen-unstable test] 11868: tolerable FAIL
> Message-ID: <osstest-11868-mainreport@xen.org>
> Content-Type: text/plain
>
> flight 11868 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11868/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in
> 11864
>
> Regressions which are regarded as allowable (not blocking):
>  test-i386-i386-win           14 guest-start.2                fail   like
> 11864
>
> Tests which did not succeed, but are not blocking:
>  test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never
> pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never
> pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never
> pass
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
> pass
>  test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never
> pass
>  test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never
> pass
>  test-amd64-i386-rhel6hvm-amd 11 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-i386-win          16 leak-check/check             fail   never
> pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
> pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never
> pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never
> pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never
> pass
>  test-i386-i386-xl-winxpsp3   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:
>  xen                  3432abcf9380
> baseline version:
>  xen                  3432abcf9380
>
> jobs:
>  build-amd64                                                  pass
>  build-i386                                                   pass
>  build-amd64-oldkern                                          pass
>  build-i386-oldkern                                           pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          pass
>  test-amd64-i386-xl                                           pass
>  test-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 fail
>  test-amd64-i386-qemuu-rhel6hvm-amd                           fail
>  test-amd64-amd64-xl-qemuu-win7-amd64                         fail
>  test-amd64-amd64-xl-win7-amd64                               fail
>  test-amd64-i386-xl-win7-amd64                                fail
>  test-amd64-i386-xl-credit2                                   pass
>  test-amd64-amd64-xl-pcipt-intel                              fail
>  test-amd64-i386-rhel6hvm-intel                               fail
>  test-amd64-i386-qemuu-rhel6hvm-intel                         fail
>  test-amd64-i386-xl-multivcpu                                 pass
>  test-amd64-amd64-pair                                        pass
>  test-amd64-i386-pair                                         pass
>  test-i386-i386-pair                                          pass
>  test-amd64-amd64-xl-sedf-pin                                 fail
>  test-amd64-amd64-pv                                          pass
>  test-amd64-i386-pv                                           pass
>  test-i386-i386-pv                                            pass
>  test-amd64-amd64-xl-sedf                                     pass
>  test-amd64-i386-win-vcpus1                                   fail
>  test-amd64-i386-xl-win-vcpus1                                fail
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail
>  test-amd64-amd64-win                                         fail
>  test-amd64-i386-win                                          fail
>  test-i386-i386-win                                           fail
>  test-amd64-amd64-xl-win                                      fail
>  test-i386-i386-xl-win                                        fail
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail
>  test-i386-i386-xl-qemuu-winxpsp3                             fail
>  test-amd64-i386-xend-winxpsp3                                fail
>  test-amd64-amd64-xl-winxpsp3                                 fail
>  test-i386-i386-xl-winxpsp3                                   fail
>
>
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
>
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>
>
> Published tested tree is already up to date.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 84, Issue 82
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 05:34:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 05:34:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtYGF-0005gu-5w; Sat, 04 Feb 2012 05:34:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtYGE-0005gl-C8
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 05:34:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328333640!12885629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8444 invoked from network); 4 Feb 2012 05:34:00 -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;
	4 Feb 2012 05:34:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10495650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 05:33:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 05:33:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtYG6-0004Oi-A4;
	Sat, 04 Feb 2012 05:33:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtYG6-0004Jb-49;
	Sat, 04 Feb 2012 05:33:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11869-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 05:33:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11869: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11869 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11869/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 05:34:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 05:34:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtYGF-0005gu-5w; Sat, 04 Feb 2012 05:34:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtYGE-0005gl-C8
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 05:34:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328333640!12885629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8444 invoked from network); 4 Feb 2012 05:34:00 -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;
	4 Feb 2012 05:34:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10495650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 05:33:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 05:33:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtYG6-0004Oi-A4;
	Sat, 04 Feb 2012 05:33:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtYG6-0004Jb-49;
	Sat, 04 Feb 2012 05:33:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11869-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 05:33:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11869: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11869 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11869/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 06:19:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 06: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.xensource.com>)
	id 1RtYxr-0006ZS-Ro; Sat, 04 Feb 2012 06:19:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtYxq-0006ZN-Sk
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 06:19:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328336343!11375714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26285 invoked from network); 4 Feb 2012 06:19:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 06:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325480400"; d="scan'208";a="180410013"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 01:19:02 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Sat, 4 Feb 2012
	01:19:02 -0500
Message-ID: <1328336341.3610.2.camel@cthulhu.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Date: Sat, 4 Feb 2012 07:19:01 +0100
In-Reply-To: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
References: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable stubdom build error
 version(3432abcf9380)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAyLTAzIGF0IDIxOjU3IC0wNTAwLCBNaWNoYWVsIEEuIENvbGxpbnMgd3Jv
dGU6Cj4gcGFyZW50OiAyNDY5MTozNDMyYWJjZjkzODAgdGlwCj4gIEZpeCB4ODZfMzIgYnVpbGQK
PiBicmFuY2g6IGRlZmF1bHQKPiBjb21taXQ6IDQgbW9kaWZpZWQsIDE0MzkgdW5rbm93bgo+IHVw
ZGF0ZTogKGN1cnJlbnQpCj4gCj4gL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2Nr
LXZiZC5jOiBJbiBmdW5jdGlvbiDDonFlbXVfYWlvX3dhaXTDojoKPiAvdXNyL3NyYy94ZW4tNC4y
L3N0dWJkb20vaW9lbXUvYmxvY2stdmJkLmM6MTQ3OjIwOiBlcnJvcjogbWFjcm8gInJlbW92ZV93
YWl0ZXIiIHJlcXVpcmVzIDIgYXJndW1lbnRzLCBidXQgb25seSAxIGdpdmVuCj4gL3Vzci9zcmMv
eGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2NrLXZiZC5jOjE0Nzo1OiBlcnJvcjogw6JyZW1vdmVf
d2FpdGVyw6IgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCj4gL3Vzci9z
cmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2NrLXZiZC5jOjE0Nzo1OiBub3RlOiBlYWNoIHVu
ZGVjbGFyZWQgaWRlbnRpZmllciBpcyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rp
b24gaXQgYXBwZWFycyBpbgo+IG1ha2VbM106ICoqKiBbYmxvY2stdmJkLm9dIEVycm9yIDEKPiAK
PiBbLi4uXQo+IEl0IGFwcGVhcnMgdG8gbWUgdGhhdCBwb3NzaWJseSBJIG5lZWQgdG8gZWl0aGVy
IGFkZCBhIHF1ZXVlIGxpa2UgdGhlCj4gYWJvdmUgc3lzLmMgY2FsbHMsIG9yIGRlZmluZSBhIG5l
dyBtYWNybyB0aGF0IGRvZXMgbm90IG5lZWQgYSBxdWV1ZT8KCllvdSBuZWVkZWQgdG8gdXBkYXRl
IHlvdXIgcWVtdSB0cmVlIHdpdGg6CgkkIG1ha2UgdG9vbHMvcWVtdS14ZW4tdHJhZGl0aW9uYWwt
ZGlyLWZvcmNlLXVwZGF0ZQpXZSBkb24ndCBkbyB0aGlzIGF1dG9tYXRpY2FsbHkgYmVjYXVzZSB3
ZSBhcmUgd2FyeSBvZiBibG93aW5nIGF3YXkKcGVvcGxlcyBsb2NhbCBjaGFuZ2VzLgoKT2YgY291
cnNlIGNsb25pbmcgYSBuZXcgdHJlZSB3aWxsIGhhdmUgaGFkIHRoZSBzYW1lIGVmZmVjdC4KCklh
bi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Feb 04 06:19:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 06: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.xensource.com>)
	id 1RtYxr-0006ZS-Ro; Sat, 04 Feb 2012 06:19:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtYxq-0006ZN-Sk
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 06:19:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328336343!11375714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26285 invoked from network); 4 Feb 2012 06:19:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 06:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325480400"; d="scan'208";a="180410013"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 01:19:02 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Sat, 4 Feb 2012
	01:19:02 -0500
Message-ID: <1328336341.3610.2.camel@cthulhu.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Date: Sat, 4 Feb 2012 07:19:01 +0100
In-Reply-To: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
References: <000601cce2e8$af745ab0$0e5d1010$@ark-net.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable stubdom build error
 version(3432abcf9380)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAyLTAzIGF0IDIxOjU3IC0wNTAwLCBNaWNoYWVsIEEuIENvbGxpbnMgd3Jv
dGU6Cj4gcGFyZW50OiAyNDY5MTozNDMyYWJjZjkzODAgdGlwCj4gIEZpeCB4ODZfMzIgYnVpbGQK
PiBicmFuY2g6IGRlZmF1bHQKPiBjb21taXQ6IDQgbW9kaWZpZWQsIDE0MzkgdW5rbm93bgo+IHVw
ZGF0ZTogKGN1cnJlbnQpCj4gCj4gL3Vzci9zcmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2Nr
LXZiZC5jOiBJbiBmdW5jdGlvbiDDonFlbXVfYWlvX3dhaXTDojoKPiAvdXNyL3NyYy94ZW4tNC4y
L3N0dWJkb20vaW9lbXUvYmxvY2stdmJkLmM6MTQ3OjIwOiBlcnJvcjogbWFjcm8gInJlbW92ZV93
YWl0ZXIiIHJlcXVpcmVzIDIgYXJndW1lbnRzLCBidXQgb25seSAxIGdpdmVuCj4gL3Vzci9zcmMv
eGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2NrLXZiZC5jOjE0Nzo1OiBlcnJvcjogw6JyZW1vdmVf
d2FpdGVyw6IgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCj4gL3Vzci9z
cmMveGVuLTQuMi9zdHViZG9tL2lvZW11L2Jsb2NrLXZiZC5jOjE0Nzo1OiBub3RlOiBlYWNoIHVu
ZGVjbGFyZWQgaWRlbnRpZmllciBpcyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rp
b24gaXQgYXBwZWFycyBpbgo+IG1ha2VbM106ICoqKiBbYmxvY2stdmJkLm9dIEVycm9yIDEKPiAK
PiBbLi4uXQo+IEl0IGFwcGVhcnMgdG8gbWUgdGhhdCBwb3NzaWJseSBJIG5lZWQgdG8gZWl0aGVy
IGFkZCBhIHF1ZXVlIGxpa2UgdGhlCj4gYWJvdmUgc3lzLmMgY2FsbHMsIG9yIGRlZmluZSBhIG5l
dyBtYWNybyB0aGF0IGRvZXMgbm90IG5lZWQgYSBxdWV1ZT8KCllvdSBuZWVkZWQgdG8gdXBkYXRl
IHlvdXIgcWVtdSB0cmVlIHdpdGg6CgkkIG1ha2UgdG9vbHMvcWVtdS14ZW4tdHJhZGl0aW9uYWwt
ZGlyLWZvcmNlLXVwZGF0ZQpXZSBkb24ndCBkbyB0aGlzIGF1dG9tYXRpY2FsbHkgYmVjYXVzZSB3
ZSBhcmUgd2FyeSBvZiBibG93aW5nIGF3YXkKcGVvcGxlcyBsb2NhbCBjaGFuZ2VzLgoKT2YgY291
cnNlIGNsb25pbmcgYSBuZXcgdHJlZSB3aWxsIGhhdmUgaGFkIHRoZSBzYW1lIGVmZmVjdC4KCklh
bi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Feb 04 08:10:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 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.xensource.com>)
	id 1RtahK-0008M4-C5; Sat, 04 Feb 2012 08:10:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtahJ-0008Lw-Cd
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 08:10:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328343007!4492010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7128 invoked from network); 4 Feb 2012 08:10:07 -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;
	4 Feb 2012 08:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10496633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 08:10:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 08:10:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtahC-0005Fm-8A;
	Sat, 04 Feb 2012 08:10:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtahB-0004Pm-U9;
	Sat, 04 Feb 2012 08:10:06 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11870-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 08:10:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11870: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11870 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11870/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 11867
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 11867 pass in 11870

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 08:10:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 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.xensource.com>)
	id 1RtahK-0008M4-C5; Sat, 04 Feb 2012 08:10:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtahJ-0008Lw-Cd
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 08:10:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328343007!4492010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7128 invoked from network); 4 Feb 2012 08:10:07 -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;
	4 Feb 2012 08:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10496633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 08:10:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 08:10:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtahC-0005Fm-8A;
	Sat, 04 Feb 2012 08:10:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtahB-0004Pm-U9;
	Sat, 04 Feb 2012 08:10:06 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11870-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 08:10:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11870: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11870 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11870/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 11867
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 11867 pass in 11870

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 08:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 08: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.xensource.com>)
	id 1RtbRP-0000hV-Eb; Sat, 04 Feb 2012 08:57:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtbRN-0000hN-LL
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 08:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328345862!12833011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA3NzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4009 invoked from network); 4 Feb 2012 08:57: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;
	4 Feb 2012 08:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325480400"; d="scan'208";a="21635153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 03:57:41 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Sat, 4 Feb 2012
	03:57:41 -0500
Message-ID: <1328345860.3610.6.camel@cthulhu.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Sat, 4 Feb 2012 09:57:40 +0100
In-Reply-To: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
References: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 13:39 -0500, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1328294351 18000
> # Node ID 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> libxl: fix bootloader args setting

This looks correct but please could you expand your commit message to
explain what the actual issue you are fixing is e.g. such that someone
reading through the logs in the future can tell that this is a fix they
might want for the issue they are seeing

Ian.

> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> 
> diff -r e2722b24dc09 -r 9ae3b2b7b494 tools/libxl/libxl_bootloader.c
> --- a/tools/libxl/libxl_bootloader.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_bootloader.c	Fri Feb 03 13:39:11 2012 -0500
> @@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
>      flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
>  
>      if (info->u.pv.bootloader_args) {
> -        char *p = info->u.pv.bootloader_args[0];
> -        while (*(p++))
> -            flexarray_set(args, nr++, p);
> +        char **p = info->u.pv.bootloader_args;
> +        while (*p) {
> +            flexarray_set(args, nr++, *p);
> +            p++;
> +        }
>      }
>  
>      flexarray_set(args, nr++, disk);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 08:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 08: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.xensource.com>)
	id 1RtbRP-0000hV-Eb; Sat, 04 Feb 2012 08:57:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RtbRN-0000hN-LL
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 08:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328345862!12833011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA3NzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4009 invoked from network); 4 Feb 2012 08:57: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;
	4 Feb 2012 08:57:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325480400"; d="scan'208";a="21635153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 03:57:41 -0500
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Sat, 4 Feb 2012
	03:57:41 -0500
Message-ID: <1328345860.3610.6.camel@cthulhu.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Sat, 4 Feb 2012 09:57:40 +0100
In-Reply-To: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
References: <9ae3b2b7b494ab8fbc54.1328294398@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 13:39 -0500, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1328294351 18000
> # Node ID 9ae3b2b7b494ab8fbc54aa923101dc48132c6c6e
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> libxl: fix bootloader args setting

This looks correct but please could you expand your commit message to
explain what the actual issue you are fixing is e.g. such that someone
reading through the logs in the future can tell that this is a fix they
might want for the issue they are seeing

Ian.

> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> 
> diff -r e2722b24dc09 -r 9ae3b2b7b494 tools/libxl/libxl_bootloader.c
> --- a/tools/libxl/libxl_bootloader.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_bootloader.c	Fri Feb 03 13:39:11 2012 -0500
> @@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
>      flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
>  
>      if (info->u.pv.bootloader_args) {
> -        char *p = info->u.pv.bootloader_args[0];
> -        while (*(p++))
> -            flexarray_set(args, nr++, p);
> +        char **p = info->u.pv.bootloader_args;
> +        while (*p) {
> +            flexarray_set(args, nr++, *p);
> +            p++;
> +        }
>      }
>  
>      flexarray_set(args, nr++, disk);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 11:18:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 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.xensource.com>)
	id 1Rtdcu-0002Xg-NG; Sat, 04 Feb 2012 11:17:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rtdct-0002Xa-Sx
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 11:17:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328354265!11974602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13847 invoked from network); 4 Feb 2012 11:17:45 -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;
	4 Feb 2012 11:17:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10497422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 11:17:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 11:17:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rtdcm-0006Eo-Tx;
	Sat, 04 Feb 2012 11:17:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rtdcm-0001B1-P3;
	Sat, 04 Feb 2012 11:17:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11871-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 11:17:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11871: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11871 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11871/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11868

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  3432abcf9380
baseline version:
 xen                  3432abcf9380

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 11:18:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 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.xensource.com>)
	id 1Rtdcu-0002Xg-NG; Sat, 04 Feb 2012 11:17:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rtdct-0002Xa-Sx
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 11:17:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328354265!11974602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13847 invoked from network); 4 Feb 2012 11:17:45 -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;
	4 Feb 2012 11:17:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10497422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 11:17:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 11:17:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rtdcm-0006Eo-Tx;
	Sat, 04 Feb 2012 11:17:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rtdcm-0001B1-P3;
	Sat, 04 Feb 2012 11:17:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11871-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 11:17:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11871: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11871 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11871/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11868

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   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:
 xen                  3432abcf9380
baseline version:
 xen                  3432abcf9380

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 12:09:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 12:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RteQZ-0003aA-K1; Sat, 04 Feb 2012 12:09: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 1RteQZ-0003Zw-1h
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 12:09:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328357302!58771952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26542 invoked from network); 4 Feb 2012 12:08:22 -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;
	4 Feb 2012 12:08:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10497655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 12:08:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 12:08:33 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtePw-0006Wb-MR;
	Sat, 04 Feb 2012 12:08:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtePw-0001GZ-DH;
	Sat, 04 Feb 2012 12:08:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11872-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 12:08:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11872: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11872 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11872/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 12:09:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 12:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RteQZ-0003aA-K1; Sat, 04 Feb 2012 12:09: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 1RteQZ-0003Zw-1h
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 12:09:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328357302!58771952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26542 invoked from network); 4 Feb 2012 12:08:22 -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;
	4 Feb 2012 12:08:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,355,1325462400"; d="scan'208";a="10497655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 12:08:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 12:08:33 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtePw-0006Wb-MR;
	Sat, 04 Feb 2012 12:08:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtePw-0001GZ-DH;
	Sat, 04 Feb 2012 12:08:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11872-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 12:08:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11872: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11872 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11872/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 12:36:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 12: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.xensource.com>)
	id 1RteqL-0004A7-2g; Sat, 04 Feb 2012 12:35:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RteqK-0004A1-4P
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 12:35:48 +0000
Received: from [193.109.254.147:17667] by server-3.bemta-14.messagelabs.com id
	DA/D6-04696-3262D2F4; Sat, 04 Feb 2012 12:35:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328358895!51378937!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12313 invoked from network); 4 Feb 2012 12:34:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 12:34:56 -0000
Received: by iaeh11 with SMTP id h11so28336656iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 04:35:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=93diVGlBltaXn7Vy/qdX+NSgz69bvM5JGv3k7Uc2yUs=;
	b=l0rLlXEj3rffE4+AyIHRt2ptwV44YorQVLzKXW+MH+XAHrYsOAZiB1JglUQYz0OV2E
	l/8N8Ku3ZbjhP2LaaOTtFKs46pNMGY79PtI0eMsB/sBanecurFpm12bPd9B9iP7SZGtf
	7vXXfiYiHQMoJSpCg4sluzAjOg66Dy7H6DGuw=
MIME-Version: 1.0
Received: by 10.50.15.231 with SMTP id a7mr12969725igd.20.1328358945137; Sat,
	04 Feb 2012 04:35:45 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Sat, 4 Feb 2012 04:35:45 -0800 (PST)
In-Reply-To: <4F2BF78C0200007800070F50@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
	<4F2BA4230200007800070AE0@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
	<4F2BF78C0200007800070F50@nat28.tlf.novell.com>
Date: Sat, 4 Feb 2012 12:35:45 +0000
X-Google-Sender-Auth: G1ot-jk2FEETR6ALLbaTQlEPqAk
Message-ID: <CAFLBxZYZvR=w+kAcYA3Po=kpqVos9+8o4zNKBoW93=uchF9XaQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jinsong Liu <jinsong.liu@intel.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 3, 2012 at 2:04 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> I just think the patch may be too complicated for a minor issue.
>
> Is a guest crash minor? After all there is no guarantee that the
> accesses to these MSRs are exception handler protected in a

In fact, I can tell you for a fact that newer versions of Windows do
*not* handle the exception properly, and will crash if an MCE that
worked before now generates an exception (for example, after
live-migrating to a host with fewer MCEs).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 12:36:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 12: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.xensource.com>)
	id 1RteqL-0004A7-2g; Sat, 04 Feb 2012 12:35:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RteqK-0004A1-4P
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 12:35:48 +0000
Received: from [193.109.254.147:17667] by server-3.bemta-14.messagelabs.com id
	DA/D6-04696-3262D2F4; Sat, 04 Feb 2012 12:35:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328358895!51378937!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12313 invoked from network); 4 Feb 2012 12:34:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 12:34:56 -0000
Received: by iaeh11 with SMTP id h11so28336656iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 04:35:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=93diVGlBltaXn7Vy/qdX+NSgz69bvM5JGv3k7Uc2yUs=;
	b=l0rLlXEj3rffE4+AyIHRt2ptwV44YorQVLzKXW+MH+XAHrYsOAZiB1JglUQYz0OV2E
	l/8N8Ku3ZbjhP2LaaOTtFKs46pNMGY79PtI0eMsB/sBanecurFpm12bPd9B9iP7SZGtf
	7vXXfiYiHQMoJSpCg4sluzAjOg66Dy7H6DGuw=
MIME-Version: 1.0
Received: by 10.50.15.231 with SMTP id a7mr12969725igd.20.1328358945137; Sat,
	04 Feb 2012 04:35:45 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Sat, 4 Feb 2012 04:35:45 -0800 (PST)
In-Reply-To: <4F2BF78C0200007800070F50@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC8292335078030@SHSMSX101.ccr.corp.intel.com>
	<4F2BA4230200007800070AE0@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350786E8@SHSMSX101.ccr.corp.intel.com>
	<4F2BF78C0200007800070F50@nat28.tlf.novell.com>
Date: Sat, 4 Feb 2012 12:35:45 +0000
X-Google-Sender-Auth: G1ot-jk2FEETR6ALLbaTQlEPqAk
Message-ID: <CAFLBxZYZvR=w+kAcYA3Po=kpqVos9+8o4zNKBoW93=uchF9XaQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jinsong Liu <jinsong.liu@intel.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Haitao Shan <haitao.shan@intel.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 3, 2012 at 2:04 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> I just think the patch may be too complicated for a minor issue.
>
> Is a guest crash minor? After all there is no guarantee that the
> accesses to these MSRs are exception handler protected in a

In fact, I can tell you for a fact that newer versions of Windows do
*not* handle the exception properly, and will crash if an MCE that
worked before now generates an exception (for example, after
live-migrating to a host with fewer MCEs).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 13:39:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 13: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.xensource.com>)
	id 1Rtfoq-0005RR-K1; Sat, 04 Feb 2012 13:38:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rtfop-0005RM-4G
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 13:38:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328362692!10079449!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjgwNzM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjgwNzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6396 invoked from network); 4 Feb 2012 13:38:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 4 Feb 2012 13:38:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328362692; l=714;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Yp1ylfMu8FRIkjLctPE1l7bVGWk=;
	b=jjdXRq1iUD0Z9mmkPSusHiMriLdUDflGxoOyd8QlWre563KfIV8PWhdmkYa4HhTH/8t
	kLl+IwhCojgPMGMY1jL3oT3AB3PUERTvPFut5U3suBoYGoABv/K+C5ckU5SP9jybdCS7+
	BP0WpX3u+Q+j7xmmYX4NgCK0TX1PFuGgglw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjYQEZzPfA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-105-250.pools.arcor-ip.net [88.65.105.250])
	by post.strato.de (mrclete mo49) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y04c0fo14B8Qfc
	for <xen-devel@lists.xensource.com>;
	Sat, 4 Feb 2012 14:37:51 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 26B8D18634
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 14:37:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: fc90237a814f52a8836b5f667fa9e1eadcaa0394
Message-Id: <fc90237a814f52a8836b.1328362672@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sat, 04 Feb 2012 14:37:52 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxl: remove shebang from
	bash_completion helper
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328362602 -3600
# Node ID fc90237a814f52a8836b5f667fa9e1eadcaa0394
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
tools/libxl: remove shebang from bash_completion helper

Fix rpmlint warning:

xen-tools.x86_64: W: sourced-script-with-shebang /etc/bash_completion.d/xl.sh /bin/bash
This text file contains a shebang, but is meant to be sourced, not executed.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3432abcf9380 -r fc90237a814f tools/libxl/bash-completion
--- a/tools/libxl/bash-completion
+++ b/tools/libxl/bash-completion
@@ -1,4 +1,3 @@
-#!/bin/bash
 # Copy this file to /etc/bash_completion.d/xl.sh
 
 _xl()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 13:39:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 13: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.xensource.com>)
	id 1Rtfoq-0005RR-K1; Sat, 04 Feb 2012 13:38:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rtfop-0005RM-4G
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 13:38:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328362692!10079449!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjgwNzM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjgwNzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6396 invoked from network); 4 Feb 2012 13:38:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 4 Feb 2012 13:38:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328362692; l=714;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Yp1ylfMu8FRIkjLctPE1l7bVGWk=;
	b=jjdXRq1iUD0Z9mmkPSusHiMriLdUDflGxoOyd8QlWre563KfIV8PWhdmkYa4HhTH/8t
	kLl+IwhCojgPMGMY1jL3oT3AB3PUERTvPFut5U3suBoYGoABv/K+C5ckU5SP9jybdCS7+
	BP0WpX3u+Q+j7xmmYX4NgCK0TX1PFuGgglw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjYQEZzPfA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-105-250.pools.arcor-ip.net [88.65.105.250])
	by post.strato.de (mrclete mo49) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y04c0fo14B8Qfc
	for <xen-devel@lists.xensource.com>;
	Sat, 4 Feb 2012 14:37:51 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 26B8D18634
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 14:37:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: fc90237a814f52a8836b5f667fa9e1eadcaa0394
Message-Id: <fc90237a814f52a8836b.1328362672@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sat, 04 Feb 2012 14:37:52 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxl: remove shebang from
	bash_completion helper
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328362602 -3600
# Node ID fc90237a814f52a8836b5f667fa9e1eadcaa0394
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
tools/libxl: remove shebang from bash_completion helper

Fix rpmlint warning:

xen-tools.x86_64: W: sourced-script-with-shebang /etc/bash_completion.d/xl.sh /bin/bash
This text file contains a shebang, but is meant to be sourced, not executed.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3432abcf9380 -r fc90237a814f tools/libxl/bash-completion
--- a/tools/libxl/bash-completion
+++ b/tools/libxl/bash-completion
@@ -1,4 +1,3 @@
-#!/bin/bash
 # Copy this file to /etc/bash_completion.d/xl.sh
 
 _xl()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 14:40:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 14:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtglt-0006JQ-B3; Sat, 04 Feb 2012 14:39:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rtglr-0006JL-RJ
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 14:39:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328366353!12555419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24605 invoked from network); 4 Feb 2012 14:39:13 -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;
	4 Feb 2012 14:39:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,356,1325462400"; d="scan'208";a="10498203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 14:39:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 14:39:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rtglk-0007MU-Jf;
	Sat, 04 Feb 2012 14:39:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rtglk-0008Fj-7a;
	Sat, 04 Feb 2012 14:39:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11873-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 14:39:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11873: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11873 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11873/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 14:40:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 14:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtglt-0006JQ-B3; Sat, 04 Feb 2012 14:39:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rtglr-0006JL-RJ
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 14:39:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328366353!12555419!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24605 invoked from network); 4 Feb 2012 14:39:13 -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;
	4 Feb 2012 14:39:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,356,1325462400"; d="scan'208";a="10498203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 14:39:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 14:39:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rtglk-0007MU-Jf;
	Sat, 04 Feb 2012 14:39:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rtglk-0008Fj-7a;
	Sat, 04 Feb 2012 14:39:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11873-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 14:39:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11873: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11873 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11873/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 16:31:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 16:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtiVb-0008Dy-QI; Sat, 04 Feb 2012 16:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RtiVZ-0008Dt-NC
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 16:30:37 +0000
Received: from [193.109.254.147:22216] by server-8.bemta-14.messagelabs.com id
	B7/80-04706-C2D5D2F4; Sat, 04 Feb 2012 16:30:36 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328372985!51391874!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMxNTMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25762 invoked from network); 4 Feb 2012 16:29:46 -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 Feb 2012 16:29:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q14GUPG4010451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 4 Feb 2012 16:30: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
	q14GUNj7011035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 4 Feb 2012 16:30:24 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
	q14GUMt3017534; Sat, 4 Feb 2012 10:30:23 -0600
MIME-Version: 1.0
Message-ID: <e999c6a1-a6e6-4c07-b216-fc3524247855@default>
Date: Sat, 4 Feb 2012 08:30:23 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
	<1328258364.13189.47.camel@dagon.hellion.org.uk>
In-Reply-To: <1328258364.13189.47.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F2D5D22.0061,ss=1,re=0.000,fgs=0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > 2) Building blktap2 complains about a missing "uuid/uuid.h".  I
> >    did install the uuid and uuid-devel packages and there IS
> >    a /usr/include/uuid.h but no /usr/include/uuid/uuid.h.  I found
> >    I also needed to install libuuid-devel (which didn't get
> >    checked in advance apparently, just uuid-devel and uuid I think).
> 
> tools/check/check_uuid_devel looks for both "uuid.h" and "uuid/uuid.h",
> in that order but at least some headers (e.g. libxl_uuid.h, blktap's
> ones etc) use:
> 	#if __linux__
> 	#include <uuid/uuid.h>
> 	#elif __BSD__
> 	#include <uuid.h>
> 
> It seems that on EL you can end up with uuid.h but not uuid/uuid.h which
> confuses the check into succeeding where it shouldn't.
> 
> Please can you confirm that on EL6 uuid-devel
> includes /usr/include/uuid.h and libuuid-devel
> includes /usr/include/uuid/uuid.h

Confirmed.

> > 3) Missing texinfo package stops the build before it successfully
> >    completes.  Can this be check'ed in advance?
> 
> Please can you post this log so we can find where the texinfo
> requirement comes from?
> 
> Normally for these things we would patch them to only build the docs if
> the required tool is present.

I can't get a log on that machine anymore but will try to
remember to post one next time I install on a fresh machine.
IIRC from the distant past, the failure is harmless as
the docs build is the last thing that happens.  But maybe
the check script could indicate its absence along with an
advisory message about how to easily turn off the docs build?
(Just an idea so that newbies -- and oldies-but-newbies like
myself -- don't get alarmed at a failed make.)

Last, I forgot one more build problem that is almost certainly
recent.  libxl_json.c failed to build, lacking a definition
for yajl_gen_no_buf.  I commented out that case in the switch
statement in libxl_json.c and the build succeeded.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 16:31:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 16:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RtiVb-0008Dy-QI; Sat, 04 Feb 2012 16:30:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RtiVZ-0008Dt-NC
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 16:30:37 +0000
Received: from [193.109.254.147:22216] by server-8.bemta-14.messagelabs.com id
	B7/80-04706-C2D5D2F4; Sat, 04 Feb 2012 16:30:36 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328372985!51391874!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMxNTMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25762 invoked from network); 4 Feb 2012 16:29:46 -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 Feb 2012 16:29:46 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q14GUPG4010451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 4 Feb 2012 16:30: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
	q14GUNj7011035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 4 Feb 2012 16:30:24 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
	q14GUMt3017534; Sat, 4 Feb 2012 10:30:23 -0600
MIME-Version: 1.0
Message-ID: <e999c6a1-a6e6-4c07-b216-fc3524247855@default>
Date: Sat, 4 Feb 2012 08:30:23 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <04d87c5a-468c-4e88-a3c6-061bbf214cf6@default>
	<1328258364.13189.47.camel@dagon.hellion.org.uk>
In-Reply-To: <1328258364.13189.47.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F2D5D22.0061,ss=1,re=0.000,fgs=0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Build problems with latest xen-unstable.hg
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > 2) Building blktap2 complains about a missing "uuid/uuid.h".  I
> >    did install the uuid and uuid-devel packages and there IS
> >    a /usr/include/uuid.h but no /usr/include/uuid/uuid.h.  I found
> >    I also needed to install libuuid-devel (which didn't get
> >    checked in advance apparently, just uuid-devel and uuid I think).
> 
> tools/check/check_uuid_devel looks for both "uuid.h" and "uuid/uuid.h",
> in that order but at least some headers (e.g. libxl_uuid.h, blktap's
> ones etc) use:
> 	#if __linux__
> 	#include <uuid/uuid.h>
> 	#elif __BSD__
> 	#include <uuid.h>
> 
> It seems that on EL you can end up with uuid.h but not uuid/uuid.h which
> confuses the check into succeeding where it shouldn't.
> 
> Please can you confirm that on EL6 uuid-devel
> includes /usr/include/uuid.h and libuuid-devel
> includes /usr/include/uuid/uuid.h

Confirmed.

> > 3) Missing texinfo package stops the build before it successfully
> >    completes.  Can this be check'ed in advance?
> 
> Please can you post this log so we can find where the texinfo
> requirement comes from?
> 
> Normally for these things we would patch them to only build the docs if
> the required tool is present.

I can't get a log on that machine anymore but will try to
remember to post one next time I install on a fresh machine.
IIRC from the distant past, the failure is harmless as
the docs build is the last thing that happens.  But maybe
the check script could indicate its absence along with an
advisory message about how to easily turn off the docs build?
(Just an idea so that newbies -- and oldies-but-newbies like
myself -- don't get alarmed at a failed make.)

Last, I forgot one more build problem that is almost certainly
recent.  libxl_json.c failed to build, lacking a definition
for yajl_gen_no_buf.  I commented out that case in the switch
statement in libxl_json.c and the build succeeded.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 16:43:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 16:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtih5-0008Py-9c; Sat, 04 Feb 2012 16:42:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1Rtih3-0008Pt-Gs
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 16:42:29 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328373740!5455029!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMxNTMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2871 invoked from network); 4 Feb 2012 16:42:22 -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; 4 Feb 2012 16:42:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q14GgI4X018296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 4 Feb 2012 16:42:18 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
	q14GgGab022549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 4 Feb 2012 16:42:16 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
	q14GgEmR028239; Sat, 4 Feb 2012 10:42:14 -0600
MIME-Version: 1.0
Message-ID: <d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
Date: Sat, 4 Feb 2012 08:42:15 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Wilk <konrad.wilk@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
In-Reply-To: <4F2C06A00200007800071071@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F2D5FEB.0033,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: [PATCH] xen/tmem: cleanup
> 
> Use 'bool' for boolean variables. Do proper section placement.
> Eliminate an unnecessary export.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> -int tmem_enabled __read_mostly;
> -EXPORT_SYMBOL(tmem_enabled);
> +bool __read_mostly tmem_enabled = false;

tmem_enabled is used in xen/drivers/xen-selfballoon.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 16:43:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 16:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtih5-0008Py-9c; Sat, 04 Feb 2012 16:42:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1Rtih3-0008Pt-Gs
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 16:42:29 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328373740!5455029!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMxNTMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2871 invoked from network); 4 Feb 2012 16:42:22 -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; 4 Feb 2012 16:42:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q14GgI4X018296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 4 Feb 2012 16:42:18 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
	q14GgGab022549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 4 Feb 2012 16:42:16 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
	q14GgEmR028239; Sat, 4 Feb 2012 10:42:14 -0600
MIME-Version: 1.0
Message-ID: <d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
Date: Sat, 4 Feb 2012 08:42:15 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Wilk <konrad.wilk@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
In-Reply-To: <4F2C06A00200007800071071@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F2D5FEB.0033,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: [PATCH] xen/tmem: cleanup
> 
> Use 'bool' for boolean variables. Do proper section placement.
> Eliminate an unnecessary export.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> -int tmem_enabled __read_mostly;
> -EXPORT_SYMBOL(tmem_enabled);
> +bool __read_mostly tmem_enabled = false;

tmem_enabled is used in xen/drivers/xen-selfballoon.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 16:58:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 16: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.xensource.com>)
	id 1RtiwQ-0000Ra-Ru; Sat, 04 Feb 2012 16:58:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtiwO-0000RV-GB
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 16:58:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328374694!13185110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12214 invoked from network); 4 Feb 2012 16:58:14 -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;
	4 Feb 2012 16:58:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,357,1325462400"; d="scan'208";a="10498958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 16:58:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 16:58:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtiwH-00085U-Ln;
	Sat, 04 Feb 2012 16:58:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtiwH-00047Z-C6;
	Sat, 04 Feb 2012 16:58:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11874-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 16:58:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11874: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11874 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11874/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10  fail baseline untested

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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                                 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=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 16:58:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 16: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.xensource.com>)
	id 1RtiwQ-0000Ra-Ru; Sat, 04 Feb 2012 16:58:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RtiwO-0000RV-GB
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 16:58:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328374694!13185110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12214 invoked from network); 4 Feb 2012 16:58:14 -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;
	4 Feb 2012 16:58:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,357,1325462400"; d="scan'208";a="10498958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 16:58:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 16:58:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RtiwH-00085U-Ln;
	Sat, 04 Feb 2012 16:58:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RtiwH-00047Z-C6;
	Sat, 04 Feb 2012 16:58:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11874-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 16:58:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11874: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11874 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11874/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10  fail baseline untested

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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                                 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=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/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
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push git://xenbits.xen.org/staging/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 86a8d63bc11431509506b95c1481e1a023302cbc
Merge: 102dd91... d194ba1...
Author: Justin M. Forbes <jforbes@redhat.com>
Date:   Wed Feb 1 11:25:23 2012 -0600

    Merge branch 's390-1.0' of git://repo.or.cz/qemu/agraf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 19:15:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 19:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtl41-000279-7p; Sat, 04 Feb 2012 19:14:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rtl40-000274-4H
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 19:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328382853!11981991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18136 invoked from network); 4 Feb 2012 19:14:13 -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;
	4 Feb 2012 19:14:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,358,1325462400"; d="scan'208";a="10499880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 19:14:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 19:14:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rtl3o-0000MT-Dx;
	Sat, 04 Feb 2012 19:14:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rtl3o-0006Eb-6F;
	Sat, 04 Feb 2012 19:14:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11875-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 19:14:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11875: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11875 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11875/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 19:15:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 19:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtl41-000279-7p; Sat, 04 Feb 2012 19:14:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rtl40-000274-4H
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 19:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328382853!11981991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18136 invoked from network); 4 Feb 2012 19:14:13 -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;
	4 Feb 2012 19:14:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,358,1325462400"; d="scan'208";a="10499880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2012 19:14:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 4 Feb 2012 19:14:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rtl3o-0000MT-Dx;
	Sat, 04 Feb 2012 19:14:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rtl3o-0006Eb-6F;
	Sat, 04 Feb 2012 19:14:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11875-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 4 Feb 2012 19:14:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11875: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11875 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11875/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ . ap-common
++ : 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/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:xen/next-2.6.32
fatal: The remote end hung up unexpectedly
------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 23:32:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 23:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtp4f-0005dv-If; Sat, 04 Feb 2012 23:31:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1Rtp4c-0005dn-KE
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 23:31:14 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328398266!13589514!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32299 invoked from network); 4 Feb 2012 23:31:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 23:31:08 -0000
Received: by damc16 with SMTP id c16so27302796dam.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 15:31:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=xmSsgGanPp+eyNrqvMLn+nlE3X20PQWUUvHNb70oHak=;
	b=CYlz5jOdwV7B3fe0BH4rA1IrR0L8K+nWfO4PUIHi4Sg/uuJ6hpvErwVxBB3bB8dxOm
	La6NSCytVE8ufsKh/L4EmLDo9r0PXpXvTLHxi5pvJthFVdIE+AWvYee+3NVpSi/8vk+1
	+siZF7SEPCODr+G9IZr6FqCYkKh/jYUoxAm10=
MIME-Version: 1.0
Received: by 10.68.75.79 with SMTP id a15mr32123754pbw.62.1328398264069; Sat,
	04 Feb 2012 15:31:04 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Sat, 4 Feb 2012 15:31:04 -0800 (PST)
In-Reply-To: <CACc2k3dn=z9n+KWpMsj8w3x3bZ3aAQ9QWZyACamfGznuYZr-qg@mail.gmail.com>
References: <CACc2k3dWzZ=8b9qm6qeeaUsRoTZQfCT=JH0jFJeQnvQLT7nymA@mail.gmail.com>
	<CAEwRVpP7tw5gfG_F4vvueQ7+z8jdnfMNAf0ZB6ag-BxqyxsBNA@mail.gmail.com>
	<CACc2k3dKLHTzZY697sR3K0RKWRMk8aQW_tsc82St89tYo=FcKQ@mail.gmail.com>
	<CAEwRVpOvbAMCCOHSz+=pFTF6txLn+kjQrK=wwFiEj2cfJTRexA@mail.gmail.com>
	<CACc2k3dn=z9n+KWpMsj8w3x3bZ3aAQ9QWZyACamfGznuYZr-qg@mail.gmail.com>
Date: Sun, 5 Feb 2012 07:31:04 +0800
Message-ID: <CAEwRVpPD0i7n6sPmsL5CCmwJjGrx6PcdpvLXp1hZgZ2bYY27sg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: David Gonzalez <dgonzalezh@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] XEN 4.1.2+Centos 6.2+Kernel 3.X
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 5, 2012 at 6:54 AM, David Gonzalez <dgonzalezh@gmail.com> wrote:
>
>
> On Sat, Feb 4, 2012 at 5:01 PM, Teck Choon Giam <giamteckchoon@gmail.com>
> wrote:
>>
>> On Sun, Feb 5, 2012 at 5:35 AM, David Gonzalez <dgonzalezh@gmail.com>
>> wrote:
>> > Yo, Teck, nice name heh,
>>
>> Grrr... My Surname is Giam and Name is Teck Choon :p
>>
>> >
>> > On Sat, Feb 4, 2012 at 2:16 PM, Teck Choon Giam
>> > <giamteckchoon@gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Feb 4, 2012 at 1:25 PM, David Gonzalez <dgonzalezh@gmail.com>
>> >> wrote:
>> >> > Hey hope this opne is a "make senser".
>> >> >
>> >> > Has anyone tried the "Subject line" combo?, I've compiled a dozen
>> >> > src.rpm
>> >> > kern el 3.0 and 3.1 packages with no luck to try native upstream Do=
m0
>> >> > kernel
>> >>
>> >> > support with no success, just a kernel oops and constant reboots.
>> >>
>> >> I have compiled 3.0, 3.1 and 3.2 kernels for dom0 and domU for my
>> >> own=A0patched kernels (add iscsitarget as module into it as example).
>> >> Tested with xen-4.1.3-rc1-pre.
>> >>
>> > Ok, I'm guessing that mus me one of my many mistakes when doing this, I
>> > haven't added the rite modules.
>> >
>> >>
>> >> >
>> >> > I followed Fedora's wiki on building a custom kernel, even used
>> >> > F16's=A0>
>> >> > .config which also was a no-no. I'd like to try F16 which comes with
>> >> > 3.0=A0>
>> >> > out-of-the-box, but I've already set up my CentOS 6.2 pretty nicely
>> >> > to
>> >> > just=A0"mkfs.ext3" on it, so if anyone has some _updated_ info (3rd
>> >> > quarter
>> >> > 2011 or=A02012) that I can refer to, please advise.
>> >>
>> >> Although I don't use CentOS 6. =A0I use Scientific Linux 6 instead.
>> >> Don't use Fedora kernel .config as there are many debug options
>> >> enabled if I remember correctly. =A0Even I use RHEL6 .config for
>> >> 2.6.32.x pvops kernel for Jeremy's xen git tree will encounter
>> >> problems. =A0In short, you can use one of those .config then use make
>> >> menuconfig to disable power, cgroup, debug etc. options and start
>> >> from=A0there as this is how I did.
>> >>
>> > Hmm, I tried that with rpmbuild -bb kernel.spec and as described on F16
>> > wiki, and disabled many many options and the kernel compiled aok and t=
he
>> > installed fine but never booted, it kept rebooting.
>>
>> Just a question... is your xen installed from source or from rpm package?
>
>
> It's from myoung Fedora repos it's rpm package, altho I built 4.1.2 myself
> but it's not installed from those but froma repo.
>>
>>
>> >
>> > I'll try your suggestions and hope that it helps.
>>
>> If that doesn't, you can use mine instead of burning your time to make
>> it work ;) =A0Anyway, I think it is a good experience to make it work
>> from self compile and there are many things to learn from this
>> experience.
>
>
> Huh, self-compiled, I've done that a hundred times, but it's always a no-=
no,
> i'v compiled 2.6.32 to 2.6.40 also 3.0.x to 3.1.x =A0and no luck either, =
I've
> got a devel machine runiing also CentOS 6.0 with 4 cores and 2048MB uin R=
AM
> so itr takes not tyoo long but it's frustrating to reboot and get nothing.
>
> I'd like to try yours, do you happen to have a repo or some place to get
> your rpms?.

The guide is at http://choon.net/forum/read.php?16,672307

Thanks.

Kindest regards,
Giam Teck Choon


>>
>>
>> >
>> > Thank you very much.
>>
>> Thanks.
>
>
> Again.
> --
> David Gonzalez H.
> Bogota: +(57-1)289-1168
> Medellin: +(57-1)247-0985
> Cel: +(57)315-838-8326
> DGHVoIP - OPEN SOURCE TELEPHONY SOLUTIONS
> http://www.dghvoip.com/
> Proud Linux User #294661

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 23:32:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 23:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtp4f-0005dv-If; Sat, 04 Feb 2012 23:31:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1Rtp4c-0005dn-KE
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 23:31:14 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328398266!13589514!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32299 invoked from network); 4 Feb 2012 23:31:08 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 23:31:08 -0000
Received: by damc16 with SMTP id c16so27302796dam.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 15:31:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=xmSsgGanPp+eyNrqvMLn+nlE3X20PQWUUvHNb70oHak=;
	b=CYlz5jOdwV7B3fe0BH4rA1IrR0L8K+nWfO4PUIHi4Sg/uuJ6hpvErwVxBB3bB8dxOm
	La6NSCytVE8ufsKh/L4EmLDo9r0PXpXvTLHxi5pvJthFVdIE+AWvYee+3NVpSi/8vk+1
	+siZF7SEPCODr+G9IZr6FqCYkKh/jYUoxAm10=
MIME-Version: 1.0
Received: by 10.68.75.79 with SMTP id a15mr32123754pbw.62.1328398264069; Sat,
	04 Feb 2012 15:31:04 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Sat, 4 Feb 2012 15:31:04 -0800 (PST)
In-Reply-To: <CACc2k3dn=z9n+KWpMsj8w3x3bZ3aAQ9QWZyACamfGznuYZr-qg@mail.gmail.com>
References: <CACc2k3dWzZ=8b9qm6qeeaUsRoTZQfCT=JH0jFJeQnvQLT7nymA@mail.gmail.com>
	<CAEwRVpP7tw5gfG_F4vvueQ7+z8jdnfMNAf0ZB6ag-BxqyxsBNA@mail.gmail.com>
	<CACc2k3dKLHTzZY697sR3K0RKWRMk8aQW_tsc82St89tYo=FcKQ@mail.gmail.com>
	<CAEwRVpOvbAMCCOHSz+=pFTF6txLn+kjQrK=wwFiEj2cfJTRexA@mail.gmail.com>
	<CACc2k3dn=z9n+KWpMsj8w3x3bZ3aAQ9QWZyACamfGznuYZr-qg@mail.gmail.com>
Date: Sun, 5 Feb 2012 07:31:04 +0800
Message-ID: <CAEwRVpPD0i7n6sPmsL5CCmwJjGrx6PcdpvLXp1hZgZ2bYY27sg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: David Gonzalez <dgonzalezh@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] XEN 4.1.2+Centos 6.2+Kernel 3.X
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 5, 2012 at 6:54 AM, David Gonzalez <dgonzalezh@gmail.com> wrote:
>
>
> On Sat, Feb 4, 2012 at 5:01 PM, Teck Choon Giam <giamteckchoon@gmail.com>
> wrote:
>>
>> On Sun, Feb 5, 2012 at 5:35 AM, David Gonzalez <dgonzalezh@gmail.com>
>> wrote:
>> > Yo, Teck, nice name heh,
>>
>> Grrr... My Surname is Giam and Name is Teck Choon :p
>>
>> >
>> > On Sat, Feb 4, 2012 at 2:16 PM, Teck Choon Giam
>> > <giamteckchoon@gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Feb 4, 2012 at 1:25 PM, David Gonzalez <dgonzalezh@gmail.com>
>> >> wrote:
>> >> > Hey hope this opne is a "make senser".
>> >> >
>> >> > Has anyone tried the "Subject line" combo?, I've compiled a dozen
>> >> > src.rpm
>> >> > kern el 3.0 and 3.1 packages with no luck to try native upstream Do=
m0
>> >> > kernel
>> >>
>> >> > support with no success, just a kernel oops and constant reboots.
>> >>
>> >> I have compiled 3.0, 3.1 and 3.2 kernels for dom0 and domU for my
>> >> own=A0patched kernels (add iscsitarget as module into it as example).
>> >> Tested with xen-4.1.3-rc1-pre.
>> >>
>> > Ok, I'm guessing that mus me one of my many mistakes when doing this, I
>> > haven't added the rite modules.
>> >
>> >>
>> >> >
>> >> > I followed Fedora's wiki on building a custom kernel, even used
>> >> > F16's=A0>
>> >> > .config which also was a no-no. I'd like to try F16 which comes with
>> >> > 3.0=A0>
>> >> > out-of-the-box, but I've already set up my CentOS 6.2 pretty nicely
>> >> > to
>> >> > just=A0"mkfs.ext3" on it, so if anyone has some _updated_ info (3rd
>> >> > quarter
>> >> > 2011 or=A02012) that I can refer to, please advise.
>> >>
>> >> Although I don't use CentOS 6. =A0I use Scientific Linux 6 instead.
>> >> Don't use Fedora kernel .config as there are many debug options
>> >> enabled if I remember correctly. =A0Even I use RHEL6 .config for
>> >> 2.6.32.x pvops kernel for Jeremy's xen git tree will encounter
>> >> problems. =A0In short, you can use one of those .config then use make
>> >> menuconfig to disable power, cgroup, debug etc. options and start
>> >> from=A0there as this is how I did.
>> >>
>> > Hmm, I tried that with rpmbuild -bb kernel.spec and as described on F16
>> > wiki, and disabled many many options and the kernel compiled aok and t=
he
>> > installed fine but never booted, it kept rebooting.
>>
>> Just a question... is your xen installed from source or from rpm package?
>
>
> It's from myoung Fedora repos it's rpm package, altho I built 4.1.2 myself
> but it's not installed from those but froma repo.
>>
>>
>> >
>> > I'll try your suggestions and hope that it helps.
>>
>> If that doesn't, you can use mine instead of burning your time to make
>> it work ;) =A0Anyway, I think it is a good experience to make it work
>> from self compile and there are many things to learn from this
>> experience.
>
>
> Huh, self-compiled, I've done that a hundred times, but it's always a no-=
no,
> i'v compiled 2.6.32 to 2.6.40 also 3.0.x to 3.1.x =A0and no luck either, =
I've
> got a devel machine runiing also CentOS 6.0 with 4 cores and 2048MB uin R=
AM
> so itr takes not tyoo long but it's frustrating to reboot and get nothing.
>
> I'd like to try yours, do you happen to have a repo or some place to get
> your rpms?.

The guide is at http://choon.net/forum/read.php?16,672307

Thanks.

Kindest regards,
Giam Teck Choon


>>
>>
>> >
>> > Thank you very much.
>>
>> Thanks.
>
>
> Again.
> --
> David Gonzalez H.
> Bogota: +(57-1)289-1168
> Medellin: +(57-1)247-0985
> Cel: +(57)315-838-8326
> DGHVoIP - OPEN SOURCE TELEPHONY SOLUTIONS
> http://www.dghvoip.com/
> Proud Linux User #294661

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 23:45:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 23: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.xensource.com>)
	id 1RtpHt-0005qC-ST; Sat, 04 Feb 2012 23:44:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RtpHs-0005q7-6b
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 23:44:56 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328399087!11849659!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11769 invoked from network); 4 Feb 2012 23:44:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 23:44:49 -0000
Received: by pbds6 with SMTP id s6so30627470pbd.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 15:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type:content-transfer-encoding;
	bh=5Pn+8IUMPpKguuNe9kFx24D5kN1d3n0ITGHquavm5Wc=;
	b=QnVF09FfjjB+gpHBnYyDCMhG0XHyaCxJAHmDTT2+VIb9fndEIPAd1qMjt51Dn9as51
	pQU0xXrBrD/NDXwBthIJcp5iCaHCpupgF3dNwtRPjzqIbm4EBEKDwoY+yMLf1RQWVzWC
	pRtR/spJYXovYmsTr2zucBmq+65isneG6RdUA=
MIME-Version: 1.0
Received: by 10.68.204.7 with SMTP id ku7mr19701193pbc.45.1328399086431; Sat,
	04 Feb 2012 15:44:46 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Sat, 4 Feb 2012 15:44:46 -0800 (PST)
In-Reply-To: <CAEwRVpPD0i7n6sPmsL5CCmwJjGrx6PcdpvLXp1hZgZ2bYY27sg@mail.gmail.com>
References: <CACc2k3dWzZ=8b9qm6qeeaUsRoTZQfCT=JH0jFJeQnvQLT7nymA@mail.gmail.com>
	<CAEwRVpP7tw5gfG_F4vvueQ7+z8jdnfMNAf0ZB6ag-BxqyxsBNA@mail.gmail.com>
	<CACc2k3dKLHTzZY697sR3K0RKWRMk8aQW_tsc82St89tYo=FcKQ@mail.gmail.com>
	<CAEwRVpOvbAMCCOHSz+=pFTF6txLn+kjQrK=wwFiEj2cfJTRexA@mail.gmail.com>
	<CACc2k3dn=z9n+KWpMsj8w3x3bZ3aAQ9QWZyACamfGznuYZr-qg@mail.gmail.com>
	<CAEwRVpPD0i7n6sPmsL5CCmwJjGrx6PcdpvLXp1hZgZ2bYY27sg@mail.gmail.com>
Date: Sun, 5 Feb 2012 07:44:46 +0800
Message-ID: <CAEwRVpOhhVAc2VPfseyp7F8qBHRBWrhFbB1qQoLV=EyfqJOHaw@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] XEN 4.1.2+Centos 6.2+Kernel 3.X
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for this top posting and Cc the wrong list.  This should goes to
xen-users not xen-devel.  Many sorry :(


On Sun, Feb 5, 2012 at 7:31 AM, Teck Choon Giam <giamteckchoon@gmail.com> w=
rote:
> On Sun, Feb 5, 2012 at 6:54 AM, David Gonzalez <dgonzalezh@gmail.com> wro=
te:
>>
>>
>> On Sat, Feb 4, 2012 at 5:01 PM, Teck Choon Giam <giamteckchoon@gmail.com>
>> wrote:
>>>
>>> On Sun, Feb 5, 2012 at 5:35 AM, David Gonzalez <dgonzalezh@gmail.com>
>>> wrote:
>>> > Yo, Teck, nice name heh,
>>>
>>> Grrr... My Surname is Giam and Name is Teck Choon :p
>>>
>>> >
>>> > On Sat, Feb 4, 2012 at 2:16 PM, Teck Choon Giam
>>> > <giamteckchoon@gmail.com>
>>> > wrote:
>>> >>
>>> >> On Sat, Feb 4, 2012 at 1:25 PM, David Gonzalez <dgonzalezh@gmail.com>
>>> >> wrote:
>>> >> > Hey hope this opne is a "make senser".
>>> >> >
>>> >> > Has anyone tried the "Subject line" combo?, I've compiled a dozen
>>> >> > src.rpm
>>> >> > kern el 3.0 and 3.1 packages with no luck to try native upstream D=
om0
>>> >> > kernel
>>> >>
>>> >> > support with no success, just a kernel oops and constant reboots.
>>> >>
>>> >> I have compiled 3.0, 3.1 and 3.2 kernels for dom0 and domU for my
>>> >> own=A0patched kernels (add iscsitarget as module into it as example).
>>> >> Tested with xen-4.1.3-rc1-pre.
>>> >>
>>> > Ok, I'm guessing that mus me one of my many mistakes when doing this,=
 I
>>> > haven't added the rite modules.
>>> >
>>> >>
>>> >> >
>>> >> > I followed Fedora's wiki on building a custom kernel, even used
>>> >> > F16's=A0>
>>> >> > .config which also was a no-no. I'd like to try F16 which comes wi=
th
>>> >> > 3.0=A0>
>>> >> > out-of-the-box, but I've already set up my CentOS 6.2 pretty nicely
>>> >> > to
>>> >> > just=A0"mkfs.ext3" on it, so if anyone has some _updated_ info (3rd
>>> >> > quarter
>>> >> > 2011 or=A02012) that I can refer to, please advise.
>>> >>
>>> >> Although I don't use CentOS 6. =A0I use Scientific Linux 6 instead.
>>> >> Don't use Fedora kernel .config as there are many debug options
>>> >> enabled if I remember correctly. =A0Even I use RHEL6 .config for
>>> >> 2.6.32.x pvops kernel for Jeremy's xen git tree will encounter
>>> >> problems. =A0In short, you can use one of those .config then use make
>>> >> menuconfig to disable power, cgroup, debug etc. options and start
>>> >> from=A0there as this is how I did.
>>> >>
>>> > Hmm, I tried that with rpmbuild -bb kernel.spec and as described on F=
16
>>> > wiki, and disabled many many options and the kernel compiled aok and =
the
>>> > installed fine but never booted, it kept rebooting.
>>>
>>> Just a question... is your xen installed from source or from rpm packag=
e?
>>
>>
>> It's from myoung Fedora repos it's rpm package, altho I built 4.1.2 myse=
lf
>> but it's not installed from those but froma repo.
>>>
>>>
>>> >
>>> > I'll try your suggestions and hope that it helps.
>>>
>>> If that doesn't, you can use mine instead of burning your time to make
>>> it work ;) =A0Anyway, I think it is a good experience to make it work
>>> from self compile and there are many things to learn from this
>>> experience.
>>
>>
>> Huh, self-compiled, I've done that a hundred times, but it's always a no=
-no,
>> i'v compiled 2.6.32 to 2.6.40 also 3.0.x to 3.1.x =A0and no luck either,=
 I've
>> got a devel machine runiing also CentOS 6.0 with 4 cores and 2048MB uin =
RAM
>> so itr takes not tyoo long but it's frustrating to reboot and get nothin=
g.
>>
>> I'd like to try yours, do you happen to have a repo or some place to get
>> your rpms?.
>
> The guide is at http://choon.net/forum/read.php?16,672307
>
> Thanks.
>
> Kindest regards,
> Giam Teck Choon
>
>
>>>
>>>
>>> >
>>> > Thank you very much.
>>>
>>> Thanks.
>>
>>
>> Again.
>> --
>> David Gonzalez H.
>> Bogota: +(57-1)289-1168
>> Medellin: +(57-1)247-0985
>> Cel: +(57)315-838-8326
>> DGHVoIP - OPEN SOURCE TELEPHONY SOLUTIONS
>> http://www.dghvoip.com/
>> Proud Linux User #294661

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 23:45:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 23: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.xensource.com>)
	id 1RtpHt-0005qC-ST; Sat, 04 Feb 2012 23:44:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RtpHs-0005q7-6b
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 23:44:56 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328399087!11849659!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11769 invoked from network); 4 Feb 2012 23:44:49 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 23:44:49 -0000
Received: by pbds6 with SMTP id s6so30627470pbd.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 15:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type:content-transfer-encoding;
	bh=5Pn+8IUMPpKguuNe9kFx24D5kN1d3n0ITGHquavm5Wc=;
	b=QnVF09FfjjB+gpHBnYyDCMhG0XHyaCxJAHmDTT2+VIb9fndEIPAd1qMjt51Dn9as51
	pQU0xXrBrD/NDXwBthIJcp5iCaHCpupgF3dNwtRPjzqIbm4EBEKDwoY+yMLf1RQWVzWC
	pRtR/spJYXovYmsTr2zucBmq+65isneG6RdUA=
MIME-Version: 1.0
Received: by 10.68.204.7 with SMTP id ku7mr19701193pbc.45.1328399086431; Sat,
	04 Feb 2012 15:44:46 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Sat, 4 Feb 2012 15:44:46 -0800 (PST)
In-Reply-To: <CAEwRVpPD0i7n6sPmsL5CCmwJjGrx6PcdpvLXp1hZgZ2bYY27sg@mail.gmail.com>
References: <CACc2k3dWzZ=8b9qm6qeeaUsRoTZQfCT=JH0jFJeQnvQLT7nymA@mail.gmail.com>
	<CAEwRVpP7tw5gfG_F4vvueQ7+z8jdnfMNAf0ZB6ag-BxqyxsBNA@mail.gmail.com>
	<CACc2k3dKLHTzZY697sR3K0RKWRMk8aQW_tsc82St89tYo=FcKQ@mail.gmail.com>
	<CAEwRVpOvbAMCCOHSz+=pFTF6txLn+kjQrK=wwFiEj2cfJTRexA@mail.gmail.com>
	<CACc2k3dn=z9n+KWpMsj8w3x3bZ3aAQ9QWZyACamfGznuYZr-qg@mail.gmail.com>
	<CAEwRVpPD0i7n6sPmsL5CCmwJjGrx6PcdpvLXp1hZgZ2bYY27sg@mail.gmail.com>
Date: Sun, 5 Feb 2012 07:44:46 +0800
Message-ID: <CAEwRVpOhhVAc2VPfseyp7F8qBHRBWrhFbB1qQoLV=EyfqJOHaw@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] XEN 4.1.2+Centos 6.2+Kernel 3.X
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for this top posting and Cc the wrong list.  This should goes to
xen-users not xen-devel.  Many sorry :(


On Sun, Feb 5, 2012 at 7:31 AM, Teck Choon Giam <giamteckchoon@gmail.com> w=
rote:
> On Sun, Feb 5, 2012 at 6:54 AM, David Gonzalez <dgonzalezh@gmail.com> wro=
te:
>>
>>
>> On Sat, Feb 4, 2012 at 5:01 PM, Teck Choon Giam <giamteckchoon@gmail.com>
>> wrote:
>>>
>>> On Sun, Feb 5, 2012 at 5:35 AM, David Gonzalez <dgonzalezh@gmail.com>
>>> wrote:
>>> > Yo, Teck, nice name heh,
>>>
>>> Grrr... My Surname is Giam and Name is Teck Choon :p
>>>
>>> >
>>> > On Sat, Feb 4, 2012 at 2:16 PM, Teck Choon Giam
>>> > <giamteckchoon@gmail.com>
>>> > wrote:
>>> >>
>>> >> On Sat, Feb 4, 2012 at 1:25 PM, David Gonzalez <dgonzalezh@gmail.com>
>>> >> wrote:
>>> >> > Hey hope this opne is a "make senser".
>>> >> >
>>> >> > Has anyone tried the "Subject line" combo?, I've compiled a dozen
>>> >> > src.rpm
>>> >> > kern el 3.0 and 3.1 packages with no luck to try native upstream D=
om0
>>> >> > kernel
>>> >>
>>> >> > support with no success, just a kernel oops and constant reboots.
>>> >>
>>> >> I have compiled 3.0, 3.1 and 3.2 kernels for dom0 and domU for my
>>> >> own=A0patched kernels (add iscsitarget as module into it as example).
>>> >> Tested with xen-4.1.3-rc1-pre.
>>> >>
>>> > Ok, I'm guessing that mus me one of my many mistakes when doing this,=
 I
>>> > haven't added the rite modules.
>>> >
>>> >>
>>> >> >
>>> >> > I followed Fedora's wiki on building a custom kernel, even used
>>> >> > F16's=A0>
>>> >> > .config which also was a no-no. I'd like to try F16 which comes wi=
th
>>> >> > 3.0=A0>
>>> >> > out-of-the-box, but I've already set up my CentOS 6.2 pretty nicely
>>> >> > to
>>> >> > just=A0"mkfs.ext3" on it, so if anyone has some _updated_ info (3rd
>>> >> > quarter
>>> >> > 2011 or=A02012) that I can refer to, please advise.
>>> >>
>>> >> Although I don't use CentOS 6. =A0I use Scientific Linux 6 instead.
>>> >> Don't use Fedora kernel .config as there are many debug options
>>> >> enabled if I remember correctly. =A0Even I use RHEL6 .config for
>>> >> 2.6.32.x pvops kernel for Jeremy's xen git tree will encounter
>>> >> problems. =A0In short, you can use one of those .config then use make
>>> >> menuconfig to disable power, cgroup, debug etc. options and start
>>> >> from=A0there as this is how I did.
>>> >>
>>> > Hmm, I tried that with rpmbuild -bb kernel.spec and as described on F=
16
>>> > wiki, and disabled many many options and the kernel compiled aok and =
the
>>> > installed fine but never booted, it kept rebooting.
>>>
>>> Just a question... is your xen installed from source or from rpm packag=
e?
>>
>>
>> It's from myoung Fedora repos it's rpm package, altho I built 4.1.2 myse=
lf
>> but it's not installed from those but froma repo.
>>>
>>>
>>> >
>>> > I'll try your suggestions and hope that it helps.
>>>
>>> If that doesn't, you can use mine instead of burning your time to make
>>> it work ;) =A0Anyway, I think it is a good experience to make it work
>>> from self compile and there are many things to learn from this
>>> experience.
>>
>>
>> Huh, self-compiled, I've done that a hundred times, but it's always a no=
-no,
>> i'v compiled 2.6.32 to 2.6.40 also 3.0.x to 3.1.x =A0and no luck either,=
 I've
>> got a devel machine runiing also CentOS 6.0 with 4 cores and 2048MB uin =
RAM
>> so itr takes not tyoo long but it's frustrating to reboot and get nothin=
g.
>>
>> I'd like to try yours, do you happen to have a repo or some place to get
>> your rpms?.
>
> The guide is at http://choon.net/forum/read.php?16,672307
>
> Thanks.
>
> Kindest regards,
> Giam Teck Choon
>
>
>>>
>>>
>>> >
>>> > Thank you very much.
>>>
>>> Thanks.
>>
>>
>> Again.
>> --
>> David Gonzalez H.
>> Bogota: +(57-1)289-1168
>> Medellin: +(57-1)247-0985
>> Cel: +(57)315-838-8326
>> DGHVoIP - OPEN SOURCE TELEPHONY SOLUTIONS
>> http://www.dghvoip.com/
>> Proud Linux User #294661

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 23:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 23: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.xensource.com>)
	id 1RtpVi-0006H6-Cx; Sat, 04 Feb 2012 23:59:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RtpVg-0006Gy-UU
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 23:59:13 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328399946!13510647!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19199 invoked from network); 4 Feb 2012 23:59:06 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 23:59:06 -0000
Received: by wibhm2 with SMTP id hm2so11056497wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 15:59:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=2jmbU6hUsWy2KKBYkDwfCcRhMaZtsXZWoChXSW+nbSc=;
	b=Q5Uon+uT90yVX+iJbNUslluq2S0sV0KlgG1JmUQff93NB3I9XinvYHyPtYfd/bwe5O
	WBkHyBKhzkvr1ZCWz4N4Zmk9pqLkzFLB4i2juDP67vxdRlUc4fmRVBIAMu7l71RhyHzG
	xxsntRhZRmR1NDewBXz7a45IpLnwgVhP30I1M=
Received: by 10.180.101.101 with SMTP id ff5mr5067449wib.14.1328399946270;
	Sat, 04 Feb 2012 15:59:06 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id y6sm3523563wix.10.2012.02.04.15.59.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 04 Feb 2012 15:59:05 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: seabios@seabios.org
Date: Sun,  5 Feb 2012 00:46:58 +0000
Message-Id: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: kevin@koconnor.net, xen-devel@lists.xensource.com,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH] Automatically select 0xe9 as default debug port
	if configured for Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

As per Ian comment on previous commit 7123d9834d58287d43514d7799ed1a7b34eea243

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 src/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index cf0bff0..cee0005 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -361,6 +361,7 @@ menu "Debugging"
     config DEBUG_IO_PORT
         depends on DEBUG_IO
         hex "Debug IO port address"
+        default 0x00e9 if XEN
         default 0x0402
         help
             Bochs uses the 0x0402 address by default, whereas Xen
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 04 23:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 04 Feb 2012 23: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.xensource.com>)
	id 1RtpVi-0006H6-Cx; Sat, 04 Feb 2012 23:59:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RtpVg-0006Gy-UU
	for xen-devel@lists.xensource.com; Sat, 04 Feb 2012 23:59:13 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328399946!13510647!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19199 invoked from network); 4 Feb 2012 23:59:06 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2012 23:59:06 -0000
Received: by wibhm2 with SMTP id hm2so11056497wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 15:59:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=2jmbU6hUsWy2KKBYkDwfCcRhMaZtsXZWoChXSW+nbSc=;
	b=Q5Uon+uT90yVX+iJbNUslluq2S0sV0KlgG1JmUQff93NB3I9XinvYHyPtYfd/bwe5O
	WBkHyBKhzkvr1ZCWz4N4Zmk9pqLkzFLB4i2juDP67vxdRlUc4fmRVBIAMu7l71RhyHzG
	xxsntRhZRmR1NDewBXz7a45IpLnwgVhP30I1M=
Received: by 10.180.101.101 with SMTP id ff5mr5067449wib.14.1328399946270;
	Sat, 04 Feb 2012 15:59:06 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id y6sm3523563wix.10.2012.02.04.15.59.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 04 Feb 2012 15:59:05 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: seabios@seabios.org
Date: Sun,  5 Feb 2012 00:46:58 +0000
Message-Id: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: kevin@koconnor.net, xen-devel@lists.xensource.com,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH] Automatically select 0xe9 as default debug port
	if configured for Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

As per Ian comment on previous commit 7123d9834d58287d43514d7799ed1a7b34eea243

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 src/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index cf0bff0..cee0005 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -361,6 +361,7 @@ menu "Debugging"
     config DEBUG_IO_PORT
         depends on DEBUG_IO
         hex "Debug IO port address"
+        default 0x00e9 if XEN
         default 0x0402
         help
             Bochs uses the 0x0402 address by default, whereas Xen
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 01:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 01: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.xensource.com>)
	id 1RtrLp-0003ea-BG; Sun, 05 Feb 2012 01:57:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RtrLn-0003eV-V1
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 01:57:08 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328407021!13992746!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29871 invoked from network); 5 Feb 2012 01:57:01 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 01:57:01 -0000
Received: by qcsp15 with SMTP id p15so22183282qcs.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 17:57:00 -0800 (PST)
Received: by 10.229.76.26 with SMTP id a26mr4886041qck.126.1328407020761;
	Sat, 04 Feb 2012 17:57:00 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id r10sm23656128qaz.7.2012.02.04.17.56.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 04 Feb 2012 17:56:59 -0800 (PST)
Date: Sat, 4 Feb 2012 20:56:57 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <20120205015657.GA25327@morn.localdomain>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: seabios@seabios.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Automatically select 0xe9 as default debug
 port if configured for Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 05, 2012 at 12:46:58AM +0000, Julian Pidancet wrote:
> As per Ian comment on previous commit 7123d9834d58287d43514d7799ed1a7b34eea243
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
> ---
>  src/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/src/Kconfig b/src/Kconfig
> index cf0bff0..cee0005 100644
> --- a/src/Kconfig
> +++ b/src/Kconfig
> @@ -361,6 +361,7 @@ menu "Debugging"
>      config DEBUG_IO_PORT
>          depends on DEBUG_IO
>          hex "Debug IO port address"
> +        default 0x00e9 if XEN
>          default 0x0402
>          help
>              Bochs uses the 0x0402 address by default, whereas Xen

Setting of default values doesn't work well when done this way.  To
test, run "make menuconfig" select a build without xen, and run make.
You'll see out/autoconf.h has DEBUG_IO_PORT=0x402.  Then run "make
menuconfig" select xen, and run make.  You'll still see
DEBUG_IO_PORT=0x402.

You can look at VGA_VID in vgasrc/Kconfig for one possible solution to
the above.

-Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 01:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 01: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.xensource.com>)
	id 1RtrLp-0003ea-BG; Sun, 05 Feb 2012 01:57:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RtrLn-0003eV-V1
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 01:57:08 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328407021!13992746!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29871 invoked from network); 5 Feb 2012 01:57:01 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 01:57:01 -0000
Received: by qcsp15 with SMTP id p15so22183282qcs.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 17:57:00 -0800 (PST)
Received: by 10.229.76.26 with SMTP id a26mr4886041qck.126.1328407020761;
	Sat, 04 Feb 2012 17:57:00 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id r10sm23656128qaz.7.2012.02.04.17.56.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 04 Feb 2012 17:56:59 -0800 (PST)
Date: Sat, 4 Feb 2012 20:56:57 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <20120205015657.GA25327@morn.localdomain>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: seabios@seabios.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Automatically select 0xe9 as default debug
 port if configured for Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 05, 2012 at 12:46:58AM +0000, Julian Pidancet wrote:
> As per Ian comment on previous commit 7123d9834d58287d43514d7799ed1a7b34eea243
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
> ---
>  src/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/src/Kconfig b/src/Kconfig
> index cf0bff0..cee0005 100644
> --- a/src/Kconfig
> +++ b/src/Kconfig
> @@ -361,6 +361,7 @@ menu "Debugging"
>      config DEBUG_IO_PORT
>          depends on DEBUG_IO
>          hex "Debug IO port address"
> +        default 0x00e9 if XEN
>          default 0x0402
>          help
>              Bochs uses the 0x0402 address by default, whereas Xen

Setting of default values doesn't work well when done this way.  To
test, run "make menuconfig" select a build without xen, and run make.
You'll see out/autoconf.h has DEBUG_IO_PORT=0x402.  Then run "make
menuconfig" select xen, and run make.  You'll still see
DEBUG_IO_PORT=0x402.

You can look at VGA_VID in vgasrc/Kconfig for one possible solution to
the above.

-Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 03:20:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 03:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtsdd-00051a-NW; Sun, 05 Feb 2012 03:19:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1Rtsdc-00051V-2c
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 03:19:36 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328411969!11823683!1
X-Originating-IP: [216.33.127.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31365 invoked from network); 5 Feb 2012 03:19:29 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-14.tower-174.messagelabs.com with SMTP;
	5 Feb 2012 03:19:29 -0000
Received: from imp11 ([10.20.200.11]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120205031928.EQHL5374.mta21.charter.net@imp11>
	for <xen-devel@lists.xensource.com>; Sat, 4 Feb 2012 22:19:28 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id W3KU1i00G46xN4z053KUS2; Sat, 04 Feb 2012 22:19:28 -0500
X-Authority-Analysis: v=1.1 cv=rvNqJbVGdbt4egs52VbhtoJZG7AoPDG9H2iogr/sNfs=
	c=1 sm=1 a=0bCt-fb661UA:10 a=leqA6zRhknoA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=ZGi81NxxBDtmzvY_W9kA:9
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 468E5203D9
	for <xen-devel@lists.xensource.com>;
	Sun,  5 Feb 2012 03:43:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id xZwHRKshxceC for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 22:42:50 -0500 (EST)
Received: from 192.168.1.12 (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id 5ED9120341
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 22:42:50 -0500 (EST)
MIME-Version: 1.0
Date: Sat, 04 Feb 2012 22:38:23 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <20120205015657.GA25327@morn.localdomain>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
Message-ID: <4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Subject: [Xen-devel] HVM Driver Domain for GPU API remoting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I recently read about Xen3D and the whole idea of API remoting for 
graphics is new to me, so that's the level I'm coming from.  My question 
is as follows:
I understand that graphics passthrough only works for HVM DomUs, with 
that being said most of the driver domains I read about for networking 
are paravirtualized with a passed through NIC.  Is there any work being 
done to introduce the concept of a HVM-based Driver Domain, so that one 
can pass a GPU through?  If so, would it not be faster to remote the API 
through to the Driver Domain hosting the GPU with a Xenbus form of 
communication?  My concern, other than the fact that I don't understand 
a thing about how Xenbus and other drivers work, is that there wouldn't 
be the throughput needed to provide any better support than is currently 
handled by the virtual framebuffer.  I know that that kind of 
communication handles all block-level and network traffic, but the 
amount of data required to drive a GPU would be much more.  Am I barking 
up the wrong tree, or is this a project that would benefit the 
community?

Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 03:20:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 03:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rtsdd-00051a-NW; Sun, 05 Feb 2012 03:19:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1Rtsdc-00051V-2c
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 03:19:36 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328411969!11823683!1
X-Originating-IP: [216.33.127.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31365 invoked from network); 5 Feb 2012 03:19:29 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-14.tower-174.messagelabs.com with SMTP;
	5 Feb 2012 03:19:29 -0000
Received: from imp11 ([10.20.200.11]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120205031928.EQHL5374.mta21.charter.net@imp11>
	for <xen-devel@lists.xensource.com>; Sat, 4 Feb 2012 22:19:28 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id W3KU1i00G46xN4z053KUS2; Sat, 04 Feb 2012 22:19:28 -0500
X-Authority-Analysis: v=1.1 cv=rvNqJbVGdbt4egs52VbhtoJZG7AoPDG9H2iogr/sNfs=
	c=1 sm=1 a=0bCt-fb661UA:10 a=leqA6zRhknoA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=ZGi81NxxBDtmzvY_W9kA:9
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 468E5203D9
	for <xen-devel@lists.xensource.com>;
	Sun,  5 Feb 2012 03:43:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id xZwHRKshxceC for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 22:42:50 -0500 (EST)
Received: from 192.168.1.12 (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id 5ED9120341
	for <xen-devel@lists.xensource.com>;
	Sat,  4 Feb 2012 22:42:50 -0500 (EST)
MIME-Version: 1.0
Date: Sat, 04 Feb 2012 22:38:23 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <20120205015657.GA25327@morn.localdomain>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
Message-ID: <4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Subject: [Xen-devel] HVM Driver Domain for GPU API remoting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I recently read about Xen3D and the whole idea of API remoting for 
graphics is new to me, so that's the level I'm coming from.  My question 
is as follows:
I understand that graphics passthrough only works for HVM DomUs, with 
that being said most of the driver domains I read about for networking 
are paravirtualized with a passed through NIC.  Is there any work being 
done to introduce the concept of a HVM-based Driver Domain, so that one 
can pass a GPU through?  If so, would it not be faster to remote the API 
through to the Driver Domain hosting the GPU with a Xenbus form of 
communication?  My concern, other than the fact that I don't understand 
a thing about how Xenbus and other drivers work, is that there wouldn't 
be the throughput needed to provide any better support than is currently 
handled by the virtual framebuffer.  I know that that kind of 
communication handles all block-level and network traffic, but the 
amount of data required to drive a GPU would be much more.  Am I barking 
up the wrong tree, or is this a project that would benefit the 
community?

Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 04:03:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 04: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.xensource.com>)
	id 1RttJj-0005YM-8N; Sun, 05 Feb 2012 04:03:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RttJi-0005YD-2I
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 04:03:06 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328414579!13663601!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12505 invoked from network); 5 Feb 2012 04:02:59 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 04:02:59 -0000
Received: by werb14 with SMTP id b14so11474452wer.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 20:02:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=oIZ+zlF1m/d1IhJ1wwDDJqshtVftETi6a8bn8UyW6Ig=;
	b=QtuXUdwtHfCynh9iOPYEV223JL2fcODCBQl2FWFoj9K8fCTE2h9aqxrTmM8mxDwWCT
	u7oOwjU0hRqyAONtLnlTRLCzGk4ukfLhpnO0x2D5TwcZGuapzXDFC2KdUITQQo9LFJS/
	Nh5aREulq8cc0fXKLZ74ThJu0KtjJKnpDg1NM=
Received: by 10.216.137.165 with SMTP id y37mr5165125wei.10.1328414579677;
	Sat, 04 Feb 2012 20:02:59 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id ep3sm15415679wib.10.2012.02.04.20.02.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 04 Feb 2012 20:02:59 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: seabios@seabios.org
Date: Sun,  5 Feb 2012 04:51:06 +0000
Message-Id: <7f3ce6824f2e05447621fddc1d50eeceb676f365.1328417416.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: kevin@koconnor.net, xen-devel@lists.xensource.com,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2] Xen: Use VGA Hooks to make VGA passthrough
	work on certain devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The Intel gfx VGA option ROM on certain platforms requires the 155f50 BIOS
function to be implemented (even if it does nothing), to work properly.

v2: Ignore the case where Option ROMs are pre-deployed.
    Make vgahook_setup independent of wether the CB* variables are set.
    VGA hooks can be enabled on non-coreboot and non-Xen configurations.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 src/Kconfig    |    1 -
 src/coreboot.c |    2 +-
 src/vgahooks.c |   22 +++++++++++++++++++++-
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index cf0bff0..250663a 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -283,7 +283,6 @@ menu "BIOS interfaces"
             Support S3 resume handler.
 
     config VGAHOOKS
-        depends on COREBOOT
         bool "Hardware specific VGA helpers"
         default y
         help
diff --git a/src/coreboot.c b/src/coreboot.c
index ee9dd8b..e328c15 100644
--- a/src/coreboot.c
+++ b/src/coreboot.c
@@ -117,7 +117,7 @@ find_cb_subtable(struct cb_header *cbh, u32 tag)
 }
 
 static struct cb_memory *CBMemTable;
-const char *CBvendor, *CBpart;
+const char *CBvendor = "", *CBpart = "";
 
 // Populate max ram and e820 map info by scanning for a coreboot table.
 static void
diff --git a/src/vgahooks.c b/src/vgahooks.c
index a8f667c..20a2e2e 100644
--- a/src/vgahooks.c
+++ b/src/vgahooks.c
@@ -186,11 +186,20 @@ intel_155f40(struct bregs *regs)
 }
 
 static void
+intel_155f50(struct bregs *regs)
+{
+    /* Mandatory hook on some Dell laptops */
+    regs->ax = 0x005f;
+    set_success(regs);
+}
+
+static void
 intel_155f(struct bregs *regs)
 {
     switch (regs->al) {
     case 0x35: intel_155f35(regs); break;
     case 0x40: intel_155f40(regs); break;
+    case 0x50: intel_155f50(regs); break;
     default:   handle_155fXX(regs); break;
     }
 }
@@ -206,6 +215,15 @@ intel_155f(struct bregs *regs)
 #define BOOT_DISPLAY_LCD2       (1 << 7)
 
 static void
+intel_setup(struct pci_device *pci)
+{
+    VGAHookHandlerType = VH_INTEL;
+
+    IntelDisplayType = BOOT_DISPLAY_DEFAULT;
+    IntelDisplayId = 3;
+}
+
+static void
 roda_setup(struct pci_device *pci)
 {
     VGAHookHandlerType = VH_INTEL;
@@ -254,7 +272,7 @@ handle_155f(struct bregs *regs)
 void
 vgahook_setup(struct pci_device *pci)
 {
-    if (!CONFIG_VGAHOOKS || !CBvendor || !CBpart)
+    if (!CONFIG_VGAHOOKS)
         return;
 
     if (strcmp(CBvendor, "KONTRON") == 0 && strcmp(CBpart, "986LCD-M") == 0)
@@ -265,4 +283,6 @@ vgahook_setup(struct pci_device *pci)
         roda_setup(pci);
     else if (pci->vendor == PCI_VENDOR_ID_VIA)
         via_setup(pci);
+    else if (pci->vendor == PCI_VENDOR_ID_INTEL)
+        intel_setup(pci);
 }
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 04:03:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 04: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.xensource.com>)
	id 1RttJj-0005YM-8N; Sun, 05 Feb 2012 04:03:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RttJi-0005YD-2I
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 04:03:06 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328414579!13663601!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12505 invoked from network); 5 Feb 2012 04:02:59 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 04:02:59 -0000
Received: by werb14 with SMTP id b14so11474452wer.30
	for <xen-devel@lists.xensource.com>;
	Sat, 04 Feb 2012 20:02:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=oIZ+zlF1m/d1IhJ1wwDDJqshtVftETi6a8bn8UyW6Ig=;
	b=QtuXUdwtHfCynh9iOPYEV223JL2fcODCBQl2FWFoj9K8fCTE2h9aqxrTmM8mxDwWCT
	u7oOwjU0hRqyAONtLnlTRLCzGk4ukfLhpnO0x2D5TwcZGuapzXDFC2KdUITQQo9LFJS/
	Nh5aREulq8cc0fXKLZ74ThJu0KtjJKnpDg1NM=
Received: by 10.216.137.165 with SMTP id y37mr5165125wei.10.1328414579677;
	Sat, 04 Feb 2012 20:02:59 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id ep3sm15415679wib.10.2012.02.04.20.02.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 04 Feb 2012 20:02:59 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: seabios@seabios.org
Date: Sun,  5 Feb 2012 04:51:06 +0000
Message-Id: <7f3ce6824f2e05447621fddc1d50eeceb676f365.1328417416.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: kevin@koconnor.net, xen-devel@lists.xensource.com,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2] Xen: Use VGA Hooks to make VGA passthrough
	work on certain devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The Intel gfx VGA option ROM on certain platforms requires the 155f50 BIOS
function to be implemented (even if it does nothing), to work properly.

v2: Ignore the case where Option ROMs are pre-deployed.
    Make vgahook_setup independent of wether the CB* variables are set.
    VGA hooks can be enabled on non-coreboot and non-Xen configurations.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 src/Kconfig    |    1 -
 src/coreboot.c |    2 +-
 src/vgahooks.c |   22 +++++++++++++++++++++-
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index cf0bff0..250663a 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -283,7 +283,6 @@ menu "BIOS interfaces"
             Support S3 resume handler.
 
     config VGAHOOKS
-        depends on COREBOOT
         bool "Hardware specific VGA helpers"
         default y
         help
diff --git a/src/coreboot.c b/src/coreboot.c
index ee9dd8b..e328c15 100644
--- a/src/coreboot.c
+++ b/src/coreboot.c
@@ -117,7 +117,7 @@ find_cb_subtable(struct cb_header *cbh, u32 tag)
 }
 
 static struct cb_memory *CBMemTable;
-const char *CBvendor, *CBpart;
+const char *CBvendor = "", *CBpart = "";
 
 // Populate max ram and e820 map info by scanning for a coreboot table.
 static void
diff --git a/src/vgahooks.c b/src/vgahooks.c
index a8f667c..20a2e2e 100644
--- a/src/vgahooks.c
+++ b/src/vgahooks.c
@@ -186,11 +186,20 @@ intel_155f40(struct bregs *regs)
 }
 
 static void
+intel_155f50(struct bregs *regs)
+{
+    /* Mandatory hook on some Dell laptops */
+    regs->ax = 0x005f;
+    set_success(regs);
+}
+
+static void
 intel_155f(struct bregs *regs)
 {
     switch (regs->al) {
     case 0x35: intel_155f35(regs); break;
     case 0x40: intel_155f40(regs); break;
+    case 0x50: intel_155f50(regs); break;
     default:   handle_155fXX(regs); break;
     }
 }
@@ -206,6 +215,15 @@ intel_155f(struct bregs *regs)
 #define BOOT_DISPLAY_LCD2       (1 << 7)
 
 static void
+intel_setup(struct pci_device *pci)
+{
+    VGAHookHandlerType = VH_INTEL;
+
+    IntelDisplayType = BOOT_DISPLAY_DEFAULT;
+    IntelDisplayId = 3;
+}
+
+static void
 roda_setup(struct pci_device *pci)
 {
     VGAHookHandlerType = VH_INTEL;
@@ -254,7 +272,7 @@ handle_155f(struct bregs *regs)
 void
 vgahook_setup(struct pci_device *pci)
 {
-    if (!CONFIG_VGAHOOKS || !CBvendor || !CBpart)
+    if (!CONFIG_VGAHOOKS)
         return;
 
     if (strcmp(CBvendor, "KONTRON") == 0 && strcmp(CBpart, "986LCD-M") == 0)
@@ -265,4 +283,6 @@ vgahook_setup(struct pci_device *pci)
         roda_setup(pci);
     else if (pci->vendor == PCI_VENDOR_ID_VIA)
         via_setup(pci);
+    else if (pci->vendor == PCI_VENDOR_ID_INTEL)
+        intel_setup(pci);
 }
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 15:31:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 15:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ru43C-0005Tv-I3; Sun, 05 Feb 2012 15:30:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Ru43A-0005To-OZ
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 15:30:45 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328455838!13227540!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20428 invoked from network); 5 Feb 2012 15:30:38 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 15:30:38 -0000
Received: by werb14 with SMTP id b14so12725503wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 05 Feb 2012 07:30:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=Ifq8pHNmbB1l7hmw783yasYEGgggXCey6dGMPPAeflk=;
	b=mYtO2jVQdzGUbkZev0OPWVg1S6dK8olBWRp3lZQ+N7a1EGQnVrHA8cGK/w0rjrtkZ8
	Gg4jSJgxEzDB1Jn4PbQPouutNwdXBA2EeCmSrpcdWk4on6nj0xzy+VxVfpzzx66xmDg+
	+OOypB5Eomu/ofw8NKqmpQdvCQBbByam+pA+A=
Received: by 10.216.131.67 with SMTP id l45mr5645769wei.21.1328455837851;
	Sun, 05 Feb 2012 07:30:37 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id m8sm37380125wia.11.2012.02.05.07.30.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 05 Feb 2012 07:30:37 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sun,  5 Feb 2012 16:18:49 +0000
Message-Id: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When booting HVMs with SeaBIOS, the BIOS itself takes care of extracting
option ROMs from the PCI devices. These ROMs are usually provided with by
the device model (qemu).
Thus, hvmloader should not require any longer the rombios, stdvga,
cirrusvga or etherboot ROMs to be present.

Also, the 32bitbios_support.c file is specific to rombios and should not
be built when building hvmloader with seabios.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile    |   37 ++++++++++++++++++++++++---------
 tools/firmware/hvmloader/hvmloader.c |   13 ++++++++++-
 2 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 41a4369..a8e0f97 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o
 OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
@@ -37,25 +37,41 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
-ROMBIOS_DIR := ../rombios
+ROMBIOS_DIR ?= ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += rombios.o
+OBJS += rombios.o 32bitbios_support.o 
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
 
-SEABIOS_DIR := ../seabios-dir
+SEABIOS_DIR ?= ../seabios-dir
 ifneq ($(SEABIOS_DIR),)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
 SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
 endif
 
-STDVGA_ROM    := ../vgabios/VGABIOS-lgpl-latest.bin
+STDVGA_DIR ?= ../vgabios/
+ifneq ($(STDVGA_DIR),)
+STDVGA_ROM    := $(STDVGA_DIR)/VGABIOS-lgpl-latest.bin
+CFLAGS += -DENABLE_STDVGA
+endif
+
+CIRRUSVGA_DIR ?= ../vgabios/
+ifneq ($(CIRRUSVGA_DIR),)
 ifeq ($(CIRRUSVGA_DEBUG),y)
-CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
+CIRRUSVGA_ROM := $(CIRRUSVGA_DIR)/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
-CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
+CIRRUSVGA_ROM := $(CIRRUSVGA_DIR)/VGABIOS-lgpl-latest.cirrus.bin
+endif
+CFLAGS += -DENABLE_CIRRUSVGA
+endif
+
+ETHERBOOT_DIR ?= ../etherboot/ipxe
+ETHERBOOT_NIC := rtl8139
+ifneq ($(ETHERBOOT_DIR),)
+CFLAGS += -DENABLE_ETHERBOOT
+ETHERBOOT_ROM := $(ETHERBOOT_DIR)/src/bin/$(ETHERBOOT_NIC).rom
 endif
 
 .PHONY: all
@@ -70,7 +86,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
+roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROM)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
@@ -95,10 +111,11 @@ ifneq ($(CIRRUSVGA_ROM),)
 	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
 	echo "#endif" >> $@.new
 endif
-
+ifneq ($(ETHERBOOT_ROM),)
 	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-	cat ../etherboot/eb-roms.h >> $@.new
+	sh ./mkhex etherboot $(ETHERBOOT_ROM) >> $@.new
 	echo "#endif" >> $@.new
+endif
 
 	mv $@.new $@
 
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f120ffe..659a382 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -236,6 +236,7 @@ static int scan_option_rom(
     return round_option_rom(rom->rom_size * 512 + 1);
 }
 
+#ifdef ENABLE_ETHERBOOT
 /*
  * Scan the PCI bus for the first NIC supported by etherboot, and copy
  * the corresponding rom data to *copy_rom_dest. Returns the length of the
@@ -264,6 +265,7 @@ static int scan_etherboot_nic(unsigned int option_rom_end,
 
     return rom_size;
 }
+#endif
 
 /*
  * Scan the PCI bus for the devices that have an option ROM, and copy
@@ -475,16 +477,20 @@ int main(void)
         switch ( virtual_vga )
         {
         case VGA_cirrus:
+#ifdef ENABLE_CIRRUSVGA
             printf("Loading Cirrus VGABIOS ...\n");
             memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
                    vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
             vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
+#endif
             break;
         case VGA_std:
+#ifdef ENABLE_STDVGA
             printf("Loading Standard VGABIOS ...\n");
             memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
                    vgabios_stdvga, sizeof(vgabios_stdvga));
             vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
+#endif
             break;
         case VGA_pt:
             printf("Loading VGABIOS of passthroughed gfx ...\n");
@@ -496,13 +502,16 @@ int main(void)
             break;
         }
 
-        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
+        option_rom_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
+#ifdef ENABLE_ETHERBOOT
+        etherboot_phys_addr = option_rom_phys_addr;
         if ( etherboot_phys_addr < bios->optionrom_start )
             etherboot_phys_addr = bios->optionrom_start;
         etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
                                           etherboot_phys_addr);
 
-        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
+        option_rom_phys_addr += etherboot_sz;
+#endif
         option_rom_sz = pci_load_option_roms(bios->optionrom_end,
                                              option_rom_phys_addr);
     }
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 15:31:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 15:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ru43C-0005Tv-I3; Sun, 05 Feb 2012 15:30:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Ru43A-0005To-OZ
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 15:30:45 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328455838!13227540!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20428 invoked from network); 5 Feb 2012 15:30:38 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 15:30:38 -0000
Received: by werb14 with SMTP id b14so12725503wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 05 Feb 2012 07:30:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=Ifq8pHNmbB1l7hmw783yasYEGgggXCey6dGMPPAeflk=;
	b=mYtO2jVQdzGUbkZev0OPWVg1S6dK8olBWRp3lZQ+N7a1EGQnVrHA8cGK/w0rjrtkZ8
	Gg4jSJgxEzDB1Jn4PbQPouutNwdXBA2EeCmSrpcdWk4on6nj0xzy+VxVfpzzx66xmDg+
	+OOypB5Eomu/ofw8NKqmpQdvCQBbByam+pA+A=
Received: by 10.216.131.67 with SMTP id l45mr5645769wei.21.1328455837851;
	Sun, 05 Feb 2012 07:30:37 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id m8sm37380125wia.11.2012.02.05.07.30.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 05 Feb 2012 07:30:37 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sun,  5 Feb 2012 16:18:49 +0000
Message-Id: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When booting HVMs with SeaBIOS, the BIOS itself takes care of extracting
option ROMs from the PCI devices. These ROMs are usually provided with by
the device model (qemu).
Thus, hvmloader should not require any longer the rombios, stdvga,
cirrusvga or etherboot ROMs to be present.

Also, the 32bitbios_support.c file is specific to rombios and should not
be built when building hvmloader with seabios.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile    |   37 ++++++++++++++++++++++++---------
 tools/firmware/hvmloader/hvmloader.c |   13 ++++++++++-
 2 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 41a4369..a8e0f97 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o
 OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
@@ -37,25 +37,41 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
-ROMBIOS_DIR := ../rombios
+ROMBIOS_DIR ?= ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += rombios.o
+OBJS += rombios.o 32bitbios_support.o 
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
 
-SEABIOS_DIR := ../seabios-dir
+SEABIOS_DIR ?= ../seabios-dir
 ifneq ($(SEABIOS_DIR),)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
 SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
 endif
 
-STDVGA_ROM    := ../vgabios/VGABIOS-lgpl-latest.bin
+STDVGA_DIR ?= ../vgabios/
+ifneq ($(STDVGA_DIR),)
+STDVGA_ROM    := $(STDVGA_DIR)/VGABIOS-lgpl-latest.bin
+CFLAGS += -DENABLE_STDVGA
+endif
+
+CIRRUSVGA_DIR ?= ../vgabios/
+ifneq ($(CIRRUSVGA_DIR),)
 ifeq ($(CIRRUSVGA_DEBUG),y)
-CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
+CIRRUSVGA_ROM := $(CIRRUSVGA_DIR)/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
-CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
+CIRRUSVGA_ROM := $(CIRRUSVGA_DIR)/VGABIOS-lgpl-latest.cirrus.bin
+endif
+CFLAGS += -DENABLE_CIRRUSVGA
+endif
+
+ETHERBOOT_DIR ?= ../etherboot/ipxe
+ETHERBOOT_NIC := rtl8139
+ifneq ($(ETHERBOOT_DIR),)
+CFLAGS += -DENABLE_ETHERBOOT
+ETHERBOOT_ROM := $(ETHERBOOT_DIR)/src/bin/$(ETHERBOOT_NIC).rom
 endif
 
 .PHONY: all
@@ -70,7 +86,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
+roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROM)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
@@ -95,10 +111,11 @@ ifneq ($(CIRRUSVGA_ROM),)
 	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
 	echo "#endif" >> $@.new
 endif
-
+ifneq ($(ETHERBOOT_ROM),)
 	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-	cat ../etherboot/eb-roms.h >> $@.new
+	sh ./mkhex etherboot $(ETHERBOOT_ROM) >> $@.new
 	echo "#endif" >> $@.new
+endif
 
 	mv $@.new $@
 
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f120ffe..659a382 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -236,6 +236,7 @@ static int scan_option_rom(
     return round_option_rom(rom->rom_size * 512 + 1);
 }
 
+#ifdef ENABLE_ETHERBOOT
 /*
  * Scan the PCI bus for the first NIC supported by etherboot, and copy
  * the corresponding rom data to *copy_rom_dest. Returns the length of the
@@ -264,6 +265,7 @@ static int scan_etherboot_nic(unsigned int option_rom_end,
 
     return rom_size;
 }
+#endif
 
 /*
  * Scan the PCI bus for the devices that have an option ROM, and copy
@@ -475,16 +477,20 @@ int main(void)
         switch ( virtual_vga )
         {
         case VGA_cirrus:
+#ifdef ENABLE_CIRRUSVGA
             printf("Loading Cirrus VGABIOS ...\n");
             memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
                    vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
             vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
+#endif
             break;
         case VGA_std:
+#ifdef ENABLE_STDVGA
             printf("Loading Standard VGABIOS ...\n");
             memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
                    vgabios_stdvga, sizeof(vgabios_stdvga));
             vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
+#endif
             break;
         case VGA_pt:
             printf("Loading VGABIOS of passthroughed gfx ...\n");
@@ -496,13 +502,16 @@ int main(void)
             break;
         }
 
-        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
+        option_rom_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
+#ifdef ENABLE_ETHERBOOT
+        etherboot_phys_addr = option_rom_phys_addr;
         if ( etherboot_phys_addr < bios->optionrom_start )
             etherboot_phys_addr = bios->optionrom_start;
         etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
                                           etherboot_phys_addr);
 
-        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
+        option_rom_phys_addr += etherboot_sz;
+#endif
         option_rom_sz = pci_load_option_roms(bios->optionrom_end,
                                              option_rom_phys_addr);
     }
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 19:45:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 19:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ru80d-0008Nn-Uf; Sun, 05 Feb 2012 19:44:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Ru80c-0008Ni-E4
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 19:44:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328471055!11507364!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ1NDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28168 invoked from network); 5 Feb 2012 19:44:15 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2012 19:44: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 248881F1C;
	Sun,  5 Feb 2012 21:44:13 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6CA7020058; Sun,  5 Feb 2012 21:44:13 +0200 (EET)
Date: Sun, 5 Feb 2012 21:44:13 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120205194413.GR12984@reaktio.net>
References: <20120203180952.GP12984@reaktio.net>
	<20120203185527.GA9290@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120203185527.GA9290@phenom.dumpdata.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
	Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 01:55:27PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > IIRC there was some discussion earlier about these messages in Xen's dm=
esg:
> > =

> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > =

> > At least on my systems there's continuous flood of those messages, so t=
hey will fill up the
> > Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuab=
le information, just those messages.
> =

> Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
> which is the intel_ips driver doing.
> =


Yeah, it's always the same..

> > =

> > I seem to be getting those messages even when there's only dom0 running.
> > Is the plan to drop those messages? What's causing them? =

> =

> Looks to be the intel-ips. If you rename it does the issue disappear?

I just did "rmmod intel_ips" and the flood stopped.. =



Btw on baremetal I get this in dmesg:

[  745.033645] CPU1: Core temperature above threshold, cpu clock throttled =
(total events =3D 1)
[  745.033652] CPU3: Core temperature above threshold, cpu clock throttled =
(total events =3D 1)
[  745.034676] CPU1: Core temperature/speed normal
[  745.034678] CPU3: Core temperature/speed normal
[  849.678508] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9682, l=
imit 9000
[  899.614074] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9896, l=
imit 9000
[  899.722881] [Hardware Error]: Machine check events logged
[ 1172.675987] CPU3: Core temperature above threshold, cpu clock throttled =
(total events =3D 78)
[ 1172.675990] CPU1: Core temperature above threshold, cpu clock throttled =
(total events =3D 78)
[ 1172.677038] CPU1: Core temperature/speed normal
[ 1172.677042] CPU3: Core temperature/speed normal
[ 1174.260050] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9676, l=
imit 9000
[ 1199.339634] [Hardware Error]: Machine check events logged


-- Pasi


> > =

> > hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cg=
i?id=3D470035,
> > they're related to dom0 kernel acpi-cpufreq ?
> > =

> > Also it seems there was discussion about the subject on 2011/08:
> > http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg005=
61.html
> > =

> > =

> > Xen hypervisor 4.1.2.
> > dom0 Linux kernel 3.2.2.
> > =

> > =

> > Thanks,
> > =

> > -- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 19:45:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 19:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ru80d-0008Nn-Uf; Sun, 05 Feb 2012 19:44:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Ru80c-0008Ni-E4
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 19:44:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328471055!11507364!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ1NDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28168 invoked from network); 5 Feb 2012 19:44:15 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2012 19:44: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 248881F1C;
	Sun,  5 Feb 2012 21:44:13 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6CA7020058; Sun,  5 Feb 2012 21:44:13 +0200 (EET)
Date: Sun, 5 Feb 2012 21:44:13 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120205194413.GR12984@reaktio.net>
References: <20120203180952.GP12984@reaktio.net>
	<20120203185527.GA9290@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120203185527.GA9290@phenom.dumpdata.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
	Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 01:55:27PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > IIRC there was some discussion earlier about these messages in Xen's dm=
esg:
> > =

> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x00=
00000000c800c8 to 0x0000000080c880c8.
> > =

> > At least on my systems there's continuous flood of those messages, so t=
hey will fill up the
> > Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuab=
le information, just those messages.
> =

> Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
> which is the intel_ips driver doing.
> =


Yeah, it's always the same..

> > =

> > I seem to be getting those messages even when there's only dom0 running.
> > Is the plan to drop those messages? What's causing them? =

> =

> Looks to be the intel-ips. If you rename it does the issue disappear?

I just did "rmmod intel_ips" and the flood stopped.. =



Btw on baremetal I get this in dmesg:

[  745.033645] CPU1: Core temperature above threshold, cpu clock throttled =
(total events =3D 1)
[  745.033652] CPU3: Core temperature above threshold, cpu clock throttled =
(total events =3D 1)
[  745.034676] CPU1: Core temperature/speed normal
[  745.034678] CPU3: Core temperature/speed normal
[  849.678508] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9682, l=
imit 9000
[  899.614074] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9896, l=
imit 9000
[  899.722881] [Hardware Error]: Machine check events logged
[ 1172.675987] CPU3: Core temperature above threshold, cpu clock throttled =
(total events =3D 78)
[ 1172.675990] CPU1: Core temperature above threshold, cpu clock throttled =
(total events =3D 78)
[ 1172.677038] CPU1: Core temperature/speed normal
[ 1172.677042] CPU3: Core temperature/speed normal
[ 1174.260050] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9676, l=
imit 9000
[ 1199.339634] [Hardware Error]: Machine check events logged


-- Pasi


> > =

> > hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cg=
i?id=3D470035,
> > they're related to dom0 kernel acpi-cpufreq ?
> > =

> > Also it seems there was discussion about the subject on 2011/08:
> > http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg005=
61.html
> > =

> > =

> > Xen hypervisor 4.1.2.
> > dom0 Linux kernel 3.2.2.
> > =

> > =

> > Thanks,
> > =

> > -- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 19:57:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 19: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.xensource.com>)
	id 1Ru8D3-0000Jc-82; Sun, 05 Feb 2012 19:57:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen.list@daevel.fr>) id 1Ru8D2-0000JU-8f
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 19:57:12 +0000
X-Env-Sender: xen.list@daevel.fr
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328471825!4119046!1
X-Originating-IP: [178.32.94.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 5 Feb 2012 19:57:05 -0000
Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222)
	by server-5.tower-21.messagelabs.com with SMTP;
	5 Feb 2012 19:57:05 -0000
Received: from luuna.daevel.fr ([82.67.37.138] helo=[192.168.1.50])
	by licorne.daevel.fr with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1Ru8Cs-0000RK-Qh
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 20:57:03 +0100
Message-ID: <4F2EDF0E.2090707@daevel.fr>
Date: Sun, 05 Feb 2012 20:57:02 +0100
From: "Olivier B." <xen.list@daevel.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20120124 Icedove/9.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4F22F403.2030104@daevel.fr>
	<20120201162758.GB23047@andromeda.dapyr.net>
In-Reply-To: <20120201162758.GB23047@andromeda.dapyr.net>
Subject: Re: [Xen-devel] [Solved] Linux 3.2.2 & btrfs, on a DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/2012 17:27, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 07:59:15PM +0100, Olivier B. wrote:
>> Hi,
>>
>> I switch one of my DomU to a 3.2.2 linux kernel (renamed in 2.6.42.2, for
>> compatibility with some software), and I have some problem with btrfs.
>
> Hm, That looks like the spinlock bug:
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html
>
> Try applying that (or wait until 3.2.3 comes out) and see if that
> makes a differnce.
>
> Thanks!

Hi,

right, the Dom0 network card use the bnx2 driver on all the affected DomU, and with the 3.2.3 kernel there is no more problem. Good job !

Thanks for your time,

Olivier


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 19:57:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 19: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.xensource.com>)
	id 1Ru8D3-0000Jc-82; Sun, 05 Feb 2012 19:57:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen.list@daevel.fr>) id 1Ru8D2-0000JU-8f
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 19:57:12 +0000
X-Env-Sender: xen.list@daevel.fr
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328471825!4119046!1
X-Originating-IP: [178.32.94.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 5 Feb 2012 19:57:05 -0000
Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222)
	by server-5.tower-21.messagelabs.com with SMTP;
	5 Feb 2012 19:57:05 -0000
Received: from luuna.daevel.fr ([82.67.37.138] helo=[192.168.1.50])
	by licorne.daevel.fr with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1Ru8Cs-0000RK-Qh
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 20:57:03 +0100
Message-ID: <4F2EDF0E.2090707@daevel.fr>
Date: Sun, 05 Feb 2012 20:57:02 +0100
From: "Olivier B." <xen.list@daevel.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20120124 Icedove/9.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4F22F403.2030104@daevel.fr>
	<20120201162758.GB23047@andromeda.dapyr.net>
In-Reply-To: <20120201162758.GB23047@andromeda.dapyr.net>
Subject: Re: [Xen-devel] [Solved] Linux 3.2.2 & btrfs, on a DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/2012 17:27, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 07:59:15PM +0100, Olivier B. wrote:
>> Hi,
>>
>> I switch one of my DomU to a 3.2.2 linux kernel (renamed in 2.6.42.2, for
>> compatibility with some software), and I have some problem with btrfs.
>
> Hm, That looks like the spinlock bug:
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html
>
> Try applying that (or wait until 3.2.3 comes out) and see if that
> makes a differnce.
>
> Thanks!

Hi,

right, the Dom0 network card use the bnx2 driver on all the affected DomU, and with the 3.2.3 kernel there is no more problem. Good job !

Thanks for your time,

Olivier


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 19:59:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 19: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.xensource.com>)
	id 1Ru8EN-0000NF-NK; Sun, 05 Feb 2012 19:58:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ru8EM-0000N1-8u
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 19:58:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328471907!10180269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU3OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12386 invoked from network); 5 Feb 2012 19:58:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 19:58:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,366,1325462400"; d="scan'208";a="10505113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2012 19:58:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 5 Feb 2012 19:58:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ru8EF-0008IJ-7n;
	Sun, 05 Feb 2012 19:58:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ru8EE-0005EA-QS;
	Sun, 05 Feb 2012 19:58:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11890-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 5 Feb 2012 19:58:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11890: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11890 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11890/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv            9 guest-start             fail baseline untested
 test-amd64-i386-xl           16 guest-start.2           fail baseline untested

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
Counting objects: 52   
Counting objects: 64, done.
Compressing objects:   7% (1/14)   
Compressing objects:  14% (2/14)   
Compressing objects:  21% (3/14)   
Compressing objects:  28% (4/14)   
Compressing objects:  35% (5/14)   
Compressing objects:  42% (6/14)   
Compressing objects:  50% (7/14)   
Compressing objects:  57% (8/14)   
Compressing objects:  64% (9/14)   
Compressing objects:  71% (10/14)   
Compressing objects:  78% (11/14)   
Compressing objects:  85% (12/14)   
Compressing objects:  92% (13/14)   
Compressing objects: 100% (14/14)   
Compressing objects: 100% (14/14), done.
Writing objects:   2% (1/49)   
Writing objects:   4% (2/49)   
Writing objects:   6% (3/49)   
Writing objects:   8% (4/49)   
Writing objects:  10% (5/49)   
Writing objects:  12% (6/49)   
Writing objects:  14% (7/49)   
Writing objects:  16% (8/49)   
Writing objects:  18% (9/49)   
Writing objects:  20% (10/49)   
Writing objects:  22% (11/49)   
Writing objects:  24% (12/49)   
Writing objects:  26% (13/49)   
Writing objects:  28% (14/49)   
Writing objects:  30% (15/49)   
Writing objects:  32% (16/49)   
Writing objects:  34% (17/49)   
Writing objects:  36% (18/49)   
Writing objects:  38% (19/49)   
Writing objects:  40% (20/49)   
Writing objects:  42% (21/49)   
Writing objects:  46% (23/49)   
Writing objects:  48% (24/49)   
Writing objects:  51% (25/49)   
Writing objects:  53% (26/49)   
Writing objects:  55% (27/49)   
Writing objects:  57% (28/49)   
Writing objects:  59% (29/49)   
Writing objects:  61% (30/49)   
Writing objects:  63% (31/49)   
Writing objects:  65% (32/49)   
Writing objects:  67% (33/49)   
Writing objects:  69% (34/49)   
Writing objects:  71% (35/49)   
Writing objects:  73% (36/49)   
Writing objects:  75% (37/49)   
Writing objects:  77% (38/49)   
Writing objects:  79% (39/49)   
Writing objects:  81% (40/49)   
Writing objects:  83% (41/49)   
Writing objects:  85% (42/49)   
Writing objects:  87% (43/49)   
Writing objects:  89% (44/49)   
Writing objects:  91% (45/49)   
Writing objects:  93% (46/49)   
Writing objects:  95% (47/49)   
Writing objects:  97% (48/49)   
Writing objects: 100% (49/49)   
Writing objects: 100% (49/49), 9.77 KiB, done.
Total 49 (delta 37), reused 47 (delta 35)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   85a4ca7..86a8d63  86a8d63bc11431509506b95c1481e1a023302cbc -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 19:59:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 19: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.xensource.com>)
	id 1Ru8EN-0000NF-NK; Sun, 05 Feb 2012 19:58:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ru8EM-0000N1-8u
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 19:58:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328471907!10180269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU3OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12386 invoked from network); 5 Feb 2012 19:58:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2012 19:58:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,366,1325462400"; d="scan'208";a="10505113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2012 19:58:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 5 Feb 2012 19:58:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ru8EF-0008IJ-7n;
	Sun, 05 Feb 2012 19:58:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ru8EE-0005EA-QS;
	Sun, 05 Feb 2012 19:58:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11890-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 5 Feb 2012 19:58:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11890: tolerable FAIL -
	PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11890 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11890/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv            9 guest-start             fail baseline untested
 test-amd64-i386-xl           16 guest-start.2           fail baseline untested

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 qemuu                86a8d63bc11431509506b95c1481e1a023302cbc
baseline version:
 qemuu                85a4ca797dbe25f27df0a66aa4df1cab63245cd3

------------------------------------------------------------
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                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 86a8d63bc11431509506b95c1481e1a023302cbc
+ branch=qemu-upstream-unstable
+ revision=86a8d63bc11431509506b95c1481e1a023302cbc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.qemu-upstream-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git push xen@xenbits.xensource.com:git/qemu-upstream-unstable.git 86a8d63bc11431509506b95c1481e1a023302cbc:master
Counting objects: 52   
Counting objects: 64, done.
Compressing objects:   7% (1/14)   
Compressing objects:  14% (2/14)   
Compressing objects:  21% (3/14)   
Compressing objects:  28% (4/14)   
Compressing objects:  35% (5/14)   
Compressing objects:  42% (6/14)   
Compressing objects:  50% (7/14)   
Compressing objects:  57% (8/14)   
Compressing objects:  64% (9/14)   
Compressing objects:  71% (10/14)   
Compressing objects:  78% (11/14)   
Compressing objects:  85% (12/14)   
Compressing objects:  92% (13/14)   
Compressing objects: 100% (14/14)   
Compressing objects: 100% (14/14), done.
Writing objects:   2% (1/49)   
Writing objects:   4% (2/49)   
Writing objects:   6% (3/49)   
Writing objects:   8% (4/49)   
Writing objects:  10% (5/49)   
Writing objects:  12% (6/49)   
Writing objects:  14% (7/49)   
Writing objects:  16% (8/49)   
Writing objects:  18% (9/49)   
Writing objects:  20% (10/49)   
Writing objects:  22% (11/49)   
Writing objects:  24% (12/49)   
Writing objects:  26% (13/49)   
Writing objects:  28% (14/49)   
Writing objects:  30% (15/49)   
Writing objects:  32% (16/49)   
Writing objects:  34% (17/49)   
Writing objects:  36% (18/49)   
Writing objects:  38% (19/49)   
Writing objects:  40% (20/49)   
Writing objects:  42% (21/49)   
Writing objects:  46% (23/49)   
Writing objects:  48% (24/49)   
Writing objects:  51% (25/49)   
Writing objects:  53% (26/49)   
Writing objects:  55% (27/49)   
Writing objects:  57% (28/49)   
Writing objects:  59% (29/49)   
Writing objects:  61% (30/49)   
Writing objects:  63% (31/49)   
Writing objects:  65% (32/49)   
Writing objects:  67% (33/49)   
Writing objects:  69% (34/49)   
Writing objects:  71% (35/49)   
Writing objects:  73% (36/49)   
Writing objects:  75% (37/49)   
Writing objects:  77% (38/49)   
Writing objects:  79% (39/49)   
Writing objects:  81% (40/49)   
Writing objects:  83% (41/49)   
Writing objects:  85% (42/49)   
Writing objects:  87% (43/49)   
Writing objects:  89% (44/49)   
Writing objects:  91% (45/49)   
Writing objects:  93% (46/49)   
Writing objects:  95% (47/49)   
Writing objects:  97% (48/49)   
Writing objects: 100% (49/49)   
Writing objects: 100% (49/49), 9.77 KiB, done.
Total 49 (delta 37), reused 47 (delta 35)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   85a4ca7..86a8d63  86a8d63bc11431509506b95c1481e1a023302cbc -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 22:37:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 22: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.xensource.com>)
	id 1RuAhJ-0002Lx-MK; Sun, 05 Feb 2012 22:36:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuAhH-0002Ls-Rj
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 22:36:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328481388!3662526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU4Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14091 invoked from network); 5 Feb 2012 22:36:29 -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;
	5 Feb 2012 22:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,366,1325462400"; d="scan'208";a="10506040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2012 22:36:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 5 Feb 2012 22:36:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RuAh9-0000gK-DI;
	Sun, 05 Feb 2012 22:36:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RuAh9-0001XV-7T;
	Sun, 05 Feb 2012 22:36:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11891-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 5 Feb 2012 22:36:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11891: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11891 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11891/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.linux
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:master
Counting objects: 1   
Counting objects: 310, done.
Compressing objects:   3% (1/30)   
Compressing objects:   6% (2/30)   
Compressing objects:  10% (3/30)   
Compressing objects:  13% (4/30)   
Compressing objects:  16% (5/30)   
Compressing objects:  20% (6/30)   
Compressing objects:  23% (7/30)   
Compressing objects:  26% (8/30)   
Compressing objects:  30% (9/30)   
Compressing objects:  33% (10/30)   
Compressing objects:  36% (11/30)   
Compressing objects:  40% (12/30)   
Compressing objects:  43% (13/30)   
Compressing objects:  46% (14/30)   
Compressing objects:  50% (15/30)   
Compressing objects:  53% (16/30)   
Compressing objects:  56% (17/30)   
Compressing objects:  60% (18/30)   
Compressing objects:  63% (19/30)   
Compressing objects:  66% (20/30)   
Compressing objects:  70% (21/30)   
Compressing objects:  73% (22/30)   
Compressing objects:  76% (23/30)   
Compressing objects:  80% (24/30)   
Compressing objects:  83% (25/30)   
Compressing objects:  86% (26/30)   
Compressing objects:  90% (27/30)   
Compressing objects:  93% (28/30)   
Compressing objects:  96% (29/30)   
Compressing objects: 100% (30/30)   
Compressing objects: 100% (30/30), done.
Writing objects:   0% (1/202)   
Writing objects:   1% (3/202)   
Writing objects:   2% (5/202)   
Writing objects:   3% (7/202)   
Writing objects:   4% (9/202)   
Writing objects:   5% (11/202)   
Writing objects:   6% (13/202)   
Writing objects:   7% (15/202)   
Writing objects:   8% (17/202)   
Writing objects:   9% (19/202)   
Writing objects:  10% (21/202)   
Writing objects:  11% (23/202)   
Writing objects:  12% (25/202)   
Writing objects:  13% (27/202)   
Writing objects:  14% (29/202)   
Writing objects:  15% (31/202)   
Writing objects:  16% (33/202)   
Writing objects:  17% (35/202)   
Writing objects:  18% (37/202)   
Writing objects:  19% (39/202)   
Writing objects:  20% (41/202)   
Writing objects:  21% (43/202)   
Writing objects:  22% (45/202)   
Writing objects:  23% (47/202)   
Writing objects:  24% (49/202)   
Writing objects:  25% (51/202)   
Writing objects:  26% (53/202)   
Writing objects:  27% (55/202)   
Writing objects:  28% (57/202)   
Writing objects:  29% (59/202)   
Writing objects:  30% (61/202)   
Writing objects:  31% (63/202)   
Writing objects:  32% (65/202)   
Writing objects:  33% (67/202)   
Writing objects:  34% (69/202)   
Writing objects:  35% (71/202)   
Writing objects:  36% (73/202)   
Writing objects:  37% (75/202)   
Writing objects:  38% (77/202)   
Writing objects:  39% (79/202)   
Writing objects:  40% (81/202)   
Writing objects:  41% (83/202)   
Writing objects:  42% (85/202)   
Writing objects:  43% (87/202)   
Writing objects:  44% (89/202)   
Writing objects:  45% (91/202)   
Writing objects:  46% (93/202)   
Writing objects:  47% (95/202)   
Writing objects:  48% (97/202)   
Writing objects:  49% (99/202)   
Writing objects:  50% (101/202)   
Writing objects:  51% (104/202)   
Writing objects:  52% (106/202)   
Writing objects:  53% (108/202)   
Writing objects:  54% (110/202)   
Writing objects:  55% (112/202)   
Writing objects:  56% (114/202)   
Writing objects:  57% (116/202)   
Writing objects:  58% (118/202)   
Writing objects:  59% (120/202)   
Writing objects:  60% (122/202)   
Writing objects:  61% (124/202)   
Writing objects:  62% (126/202)   
Writing objects:  63% (128/202)   
Writing objects:  64% (130/202)   
Writing objects:  65% (132/202)   
Writing objects:  66% (134/202)   
Writing objects:  67% (136/202)   
Writing objects:  68% (138/202)   
Writing objects:  69% (140/202)   
Writing objects:  70% (142/202)   
Writing objects:  71% (144/202)   
Writing objects:  72% (146/202)   
Writing objects:  73% (148/202)   
Writing objects:  74% (150/202)   
Writing objects:  75% (152/202)   
Writing objects:  76% (154/202)   
Writing objects:  77% (156/202)   
Writing objects:  78% (158/202)   
Writing objects:  79% (160/202)   
Writing objects:  80% (162/202)   
Writing objects:  81% (164/202)   
Writing objects:  82% (166/202)   
Writing objects:  83% (168/202)   
Writing objects:  84% (170/202)   
Writing objects:  85% (172/202)   
Writing objects:  86% (174/202)   
Writing objects:  87% (176/202)   
Writing objects:  88% (178/202)   
Writing objects:  89% (180/202)   
Writing objects:  90% (182/202)   
Writing objects:  91% (184/202)   
Writing objects:  92% (186/202)   
Writing objects:  93% (188/202)   
Writing objects:  94% (190/202)   
Writing objects:  95% (192/202)   
Writing objects:  96% (194/202)   
Writing objects:  97% (196/202)   
Writing objects:  98% (198/202)   
Writing objects:  99% (200/202)   
Writing objects: 100% (202/202)   
Writing objects: 100% (202/202), 31.25 KiB, done.
Total 202 (delta 171), reused 202 (delta 171)
To xen@xenbits.xensource.com:git/linux-pvops
   8664c69..1aaf53e  1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 05 22:37:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 05 Feb 2012 22: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.xensource.com>)
	id 1RuAhJ-0002Lx-MK; Sun, 05 Feb 2012 22:36:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuAhH-0002Ls-Rj
	for xen-devel@lists.xensource.com; Sun, 05 Feb 2012 22:36:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328481388!3662526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU4Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14091 invoked from network); 5 Feb 2012 22:36:29 -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;
	5 Feb 2012 22:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,366,1325462400"; d="scan'208";a="10506040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2012 22:36:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 5 Feb 2012 22:36:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RuAh9-0000gK-DI;
	Sun, 05 Feb 2012 22:36:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RuAh9-0001XV-7T;
	Sun, 05 Feb 2012 22:36:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11891-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 5 Feb 2012 22:36:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11891: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11891 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11891/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-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

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ branch=linux
+ revision=1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.linux
+ case "$branch" in
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad:master
Counting objects: 1   
Counting objects: 310, done.
Compressing objects:   3% (1/30)   
Compressing objects:   6% (2/30)   
Compressing objects:  10% (3/30)   
Compressing objects:  13% (4/30)   
Compressing objects:  16% (5/30)   
Compressing objects:  20% (6/30)   
Compressing objects:  23% (7/30)   
Compressing objects:  26% (8/30)   
Compressing objects:  30% (9/30)   
Compressing objects:  33% (10/30)   
Compressing objects:  36% (11/30)   
Compressing objects:  40% (12/30)   
Compressing objects:  43% (13/30)   
Compressing objects:  46% (14/30)   
Compressing objects:  50% (15/30)   
Compressing objects:  53% (16/30)   
Compressing objects:  56% (17/30)   
Compressing objects:  60% (18/30)   
Compressing objects:  63% (19/30)   
Compressing objects:  66% (20/30)   
Compressing objects:  70% (21/30)   
Compressing objects:  73% (22/30)   
Compressing objects:  76% (23/30)   
Compressing objects:  80% (24/30)   
Compressing objects:  83% (25/30)   
Compressing objects:  86% (26/30)   
Compressing objects:  90% (27/30)   
Compressing objects:  93% (28/30)   
Compressing objects:  96% (29/30)   
Compressing objects: 100% (30/30)   
Compressing objects: 100% (30/30), done.
Writing objects:   0% (1/202)   
Writing objects:   1% (3/202)   
Writing objects:   2% (5/202)   
Writing objects:   3% (7/202)   
Writing objects:   4% (9/202)   
Writing objects:   5% (11/202)   
Writing objects:   6% (13/202)   
Writing objects:   7% (15/202)   
Writing objects:   8% (17/202)   
Writing objects:   9% (19/202)   
Writing objects:  10% (21/202)   
Writing objects:  11% (23/202)   
Writing objects:  12% (25/202)   
Writing objects:  13% (27/202)   
Writing objects:  14% (29/202)   
Writing objects:  15% (31/202)   
Writing objects:  16% (33/202)   
Writing objects:  17% (35/202)   
Writing objects:  18% (37/202)   
Writing objects:  19% (39/202)   
Writing objects:  20% (41/202)   
Writing objects:  21% (43/202)   
Writing objects:  22% (45/202)   
Writing objects:  23% (47/202)   
Writing objects:  24% (49/202)   
Writing objects:  25% (51/202)   
Writing objects:  26% (53/202)   
Writing objects:  27% (55/202)   
Writing objects:  28% (57/202)   
Writing objects:  29% (59/202)   
Writing objects:  30% (61/202)   
Writing objects:  31% (63/202)   
Writing objects:  32% (65/202)   
Writing objects:  33% (67/202)   
Writing objects:  34% (69/202)   
Writing objects:  35% (71/202)   
Writing objects:  36% (73/202)   
Writing objects:  37% (75/202)   
Writing objects:  38% (77/202)   
Writing objects:  39% (79/202)   
Writing objects:  40% (81/202)   
Writing objects:  41% (83/202)   
Writing objects:  42% (85/202)   
Writing objects:  43% (87/202)   
Writing objects:  44% (89/202)   
Writing objects:  45% (91/202)   
Writing objects:  46% (93/202)   
Writing objects:  47% (95/202)   
Writing objects:  48% (97/202)   
Writing objects:  49% (99/202)   
Writing objects:  50% (101/202)   
Writing objects:  51% (104/202)   
Writing objects:  52% (106/202)   
Writing objects:  53% (108/202)   
Writing objects:  54% (110/202)   
Writing objects:  55% (112/202)   
Writing objects:  56% (114/202)   
Writing objects:  57% (116/202)   
Writing objects:  58% (118/202)   
Writing objects:  59% (120/202)   
Writing objects:  60% (122/202)   
Writing objects:  61% (124/202)   
Writing objects:  62% (126/202)   
Writing objects:  63% (128/202)   
Writing objects:  64% (130/202)   
Writing objects:  65% (132/202)   
Writing objects:  66% (134/202)   
Writing objects:  67% (136/202)   
Writing objects:  68% (138/202)   
Writing objects:  69% (140/202)   
Writing objects:  70% (142/202)   
Writing objects:  71% (144/202)   
Writing objects:  72% (146/202)   
Writing objects:  73% (148/202)   
Writing objects:  74% (150/202)   
Writing objects:  75% (152/202)   
Writing objects:  76% (154/202)   
Writing objects:  77% (156/202)   
Writing objects:  78% (158/202)   
Writing objects:  79% (160/202)   
Writing objects:  80% (162/202)   
Writing objects:  81% (164/202)   
Writing objects:  82% (166/202)   
Writing objects:  83% (168/202)   
Writing objects:  84% (170/202)   
Writing objects:  85% (172/202)   
Writing objects:  86% (174/202)   
Writing objects:  87% (176/202)   
Writing objects:  88% (178/202)   
Writing objects:  89% (180/202)   
Writing objects:  90% (182/202)   
Writing objects:  91% (184/202)   
Writing objects:  92% (186/202)   
Writing objects:  93% (188/202)   
Writing objects:  94% (190/202)   
Writing objects:  95% (192/202)   
Writing objects:  96% (194/202)   
Writing objects:  97% (196/202)   
Writing objects:  98% (198/202)   
Writing objects:  99% (200/202)   
Writing objects: 100% (202/202)   
Writing objects: 100% (202/202), 31.25 KiB, done.
Total 202 (delta 171), reused 202 (delta 171)
To xen@xenbits.xensource.com:git/linux-pvops
   8664c69..1aaf53e  1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuJWH-0005vb-UU; Mon, 06 Feb 2012 08:01:49 +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 1RuJWF-0005vW-Pj
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:01:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328515175!51494393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU4Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22041 invoked from network); 6 Feb 2012 07:59:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 07:59:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,369,1325462400"; d="scan'208";a="10508727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 08:01:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 6 Feb 2012 08:01:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RuJWE-0003ja-Ak;
	Mon, 06 Feb 2012 08:01:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RuJWE-0002G2-48;
	Mon, 06 Feb 2012 08:01:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11892-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 6 Feb 2012 08:01:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11892: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11892 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11892/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install            fail pass in 11871

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 11868
 test-i386-i386-win           14 guest-start.2                fail   like 11871

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   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 in 11871 never pass

version targeted for testing:
 xen                  3432abcf9380
baseline version:
 xen                  3432abcf9380

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuJWH-0005vb-UU; Mon, 06 Feb 2012 08:01:49 +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 1RuJWF-0005vW-Pj
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:01:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328515175!51494393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU4Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22041 invoked from network); 6 Feb 2012 07:59:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 07:59:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,369,1325462400"; d="scan'208";a="10508727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 08:01:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 6 Feb 2012 08:01:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RuJWE-0003ja-Ak;
	Mon, 06 Feb 2012 08:01:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RuJWE-0002G2-48;
	Mon, 06 Feb 2012 08:01:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11892-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 6 Feb 2012 08:01:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11892: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11892 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11892/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install            fail pass in 11871

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 11868
 test-i386-i386-win           14 guest-start.2                fail   like 11871

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   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 in 11871 never pass

version targeted for testing:
 xen                  3432abcf9380
baseline version:
 xen                  3432abcf9380

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:13:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuJgn-00065F-2v; Mon, 06 Feb 2012 08:12: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 1RuJgm-00065A-2B
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:12:40 +0000
Received: from [85.158.143.35:46675] by server-2.bemta-4.messagelabs.com id
	9C/6F-28657-77B8F2F4; Mon, 06 Feb 2012 08:12:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328515958!2124059!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13190 invoked from network); 6 Feb 2012 08:12:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 08:12:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 08:12:38 +0000
Message-Id: <4F2F998202000078000714CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 08:12:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
In-Reply-To: <d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: [PATCH] xen/tmem: cleanup
>> 
>> Use 'bool' for boolean variables. Do proper section placement.
>> Eliminate an unnecessary export.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
>> 
>> -int tmem_enabled __read_mostly;
>> -EXPORT_SYMBOL(tmem_enabled);
>> +bool __read_mostly tmem_enabled = false;
> 
> tmem_enabled is used in xen/drivers/xen-selfballoon.c

Which can't be built as a module, and hence the symbol doesn't need
exporting. This patch (of course, I'm tempted to say) survived build
testing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:13:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuJgn-00065F-2v; Mon, 06 Feb 2012 08:12: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 1RuJgm-00065A-2B
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:12:40 +0000
Received: from [85.158.143.35:46675] by server-2.bemta-4.messagelabs.com id
	9C/6F-28657-77B8F2F4; Mon, 06 Feb 2012 08:12:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328515958!2124059!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13190 invoked from network); 6 Feb 2012 08:12:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 08:12:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 08:12:38 +0000
Message-Id: <4F2F998202000078000714CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 08:12:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
In-Reply-To: <d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: [PATCH] xen/tmem: cleanup
>> 
>> Use 'bool' for boolean variables. Do proper section placement.
>> Eliminate an unnecessary export.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
>> 
>> -int tmem_enabled __read_mostly;
>> -EXPORT_SYMBOL(tmem_enabled);
>> +bool __read_mostly tmem_enabled = false;
> 
> tmem_enabled is used in xen/drivers/xen-selfballoon.c

Which can't be built as a module, and hence the symbol doesn't need
exporting. This patch (of course, I'm tempted to say) survived build
testing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:32:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08: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.xensource.com>)
	id 1RuJzh-0006S2-SF; Mon, 06 Feb 2012 08:32:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RuJzg-0006Ru-LK
	for Xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:32:12 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328517077!53014841!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14498 invoked from network); 6 Feb 2012 08:31:17 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 08:31:17 -0000
Received: by lagp5 with SMTP id p5so4700420lag.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 00:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=LtoSNFrCGTnFESMzrr73+QbrtFbQ/KFWKngdvxs0sjo=;
	b=ZOLZwQ55j4ooimbo9xCdmzP/rL1TCV5vVb6tmt15665bFXlsjcsUOrR3xFAcjriWBP
	Zb4VdOGSpH/TfScIc8lHgFtj3a605SCTn/5jdsDxdSfJ3asmqJLHdiJYVVbDnyZJBLq1
	molpbMIzQdmYl2wjXmEmJVOOOVSMG3GLZAE9o=
MIME-Version: 1.0
Received: by 10.152.148.230 with SMTP id tv6mr8839937lab.12.1328517126004;
	Mon, 06 Feb 2012 00:32:06 -0800 (PST)
Received: by 10.112.62.173 with HTTP; Mon, 6 Feb 2012 00:32:05 -0800 (PST)
Date: Mon, 6 Feb 2012 16:32:05 +0800
Message-ID: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] Does HVM domain support
	xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I see in pcifront_init, if domain is not PV domain, pcifront_init just
returns error. So seems HVM domain does not support
xen-pcifront/xen-pciback mechanism? If it is true, why? I think
technically there's nothing that can block to support pcifront/pciback
in HVM, and for performance reason, there will be benefits if HVM
supports PV PCI operation.

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:32:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08: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.xensource.com>)
	id 1RuJzh-0006S2-SF; Mon, 06 Feb 2012 08:32:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RuJzg-0006Ru-LK
	for Xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:32:12 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328517077!53014841!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14498 invoked from network); 6 Feb 2012 08:31:17 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 08:31:17 -0000
Received: by lagp5 with SMTP id p5so4700420lag.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 00:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=LtoSNFrCGTnFESMzrr73+QbrtFbQ/KFWKngdvxs0sjo=;
	b=ZOLZwQ55j4ooimbo9xCdmzP/rL1TCV5vVb6tmt15665bFXlsjcsUOrR3xFAcjriWBP
	Zb4VdOGSpH/TfScIc8lHgFtj3a605SCTn/5jdsDxdSfJ3asmqJLHdiJYVVbDnyZJBLq1
	molpbMIzQdmYl2wjXmEmJVOOOVSMG3GLZAE9o=
MIME-Version: 1.0
Received: by 10.152.148.230 with SMTP id tv6mr8839937lab.12.1328517126004;
	Mon, 06 Feb 2012 00:32:06 -0800 (PST)
Received: by 10.112.62.173 with HTTP; Mon, 6 Feb 2012 00:32:05 -0800 (PST)
Date: Mon, 6 Feb 2012 16:32:05 +0800
Message-ID: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] Does HVM domain support
	xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I see in pcifront_init, if domain is not PV domain, pcifront_init just
returns error. So seems HVM domain does not support
xen-pcifront/xen-pciback mechanism? If it is true, why? I think
technically there's nothing that can block to support pcifront/pciback
in HVM, and for performance reason, there will be benefits if HVM
supports PV PCI operation.

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:43:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuKAF-0006bt-0i; Mon, 06 Feb 2012 08:43:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RuKAD-0006bo-8P
	for Xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:43:05 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328517778!13859379!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjU4Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8655 invoked from network); 6 Feb 2012 08:42:58 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-182.messagelabs.com with SMTP;
	6 Feb 2012 08:42:58 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 06 Feb 2012 00:42:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,217";a="121289561"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga002.fm.intel.com with ESMTP; 06 Feb 2012 00:42:29 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 6 Feb 2012 16:41:48 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 6 Feb 2012 16:41:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Mon, 6 Feb 2012 16:41:46 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Update VT-d Maintainer
Thread-Index: AczkqygZtzTiVQNuQO64khKnpI4WVw==
Date: Mon, 6 Feb 2012 08:41:45 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440617EF@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="_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] Update VT-d Maintainer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: multipart/alternative;
	boundary="_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_"

--_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Xiantao Zhang <xiantao.zhang@intel.com>
# Date 1328120871 -28800
# Node ID f581467a8aac2a4d7b3e73cc73fcfb070bd4db4c
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
IOMMU: Update the maintainer list of VT-d
Signed-off-by: Xiantao Zhang<xiantao.zhang@intel.com>

diff -r e2722b24dc09 -r f581467a8aac MAINTAINERS
--- a/MAINTAINERS  Thu Jan 26 17:43:31 2012 +0000
+++ b/MAINTAINERS  Thu Feb 02 02:27:51 2012 +0800
@@ -138,7 +138,7 @@
F: xen/include/asm-x86/tboot.h
 INTEL(R) VT FOR DIRECTED I/O (VT-D)
-M:   Allen Kay <allen.m.kay@intel.com>
+M:   Xiantao Zhang <xiantao.zhang@intel.com>
S: Supported
F: xen/drivers/passthrough/vtd/



--_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
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:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># HG changeset patch<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># User Xiantao Zhang &lt;xiantao.zhang@intel.com&gt;<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># Date 1328120871 -28800<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># Node ID f581467a8aac2a4d7b3e73cc73fcfb070bd4db4c<o:p></=
o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># Parent&nbsp; e2722b24dc0962de37215320b05d1bb7c4c42864<o=
:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">IOMMU: Update the maintainer list of VT-d<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">Signed-off-by: Xiantao Zhang&lt;xiantao.zhang@intel.com&g=
t;<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">diff -r e2722b24dc09 -r f581467a8aac MAINTAINERS<o:p></o:=
p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">--- a/MAINTAINERS&nbsp; Thu Jan 26 17:43:31 2012 &#43;000=
0<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">&#43;&#43;&#43; b/MAINTAINERS&nbsp; Thu Feb 02 02:27:51 2=
012 &#43;0800<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">@@ -138,7 &#43;138,7 @@<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">F: xen/include/asm-x86/tboot.h<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">&nbsp;INTEL(R) VT FOR DIRECTED I/O (VT-D)<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">-M:&nbsp;&nbsp; Allen Kay &lt;allen.m.kay@intel.com&gt;<o=
:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">&#43;M:&nbsp;&nbsp; Xiantao Zhang &lt;xiantao.zhang@intel=
.com&gt;<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">S: Supported<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">F: xen/drivers/passthrough/vtd/<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_--

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="update-vt-d-maintainer.patch"
Content-Description: update-vt-d-maintainer.patch
Content-Disposition: attachment; filename="update-vt-d-maintainer.patch";
	size=661; creation-date="Mon, 06 Feb 2012 08:39:45 GMT";
	modification-date="Mon, 06 Feb 2012 08:39:45 GMT"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFhpYW50YW8gWmhhbmcgPHhpYW50YW8uemhhbmdA
aW50ZWwuY29tPgojIERhdGUgMTMyODEyMDg3MSAtMjg4MDAKIyBOb2RlIElEIGY1ODE0NjdhOGFh
YzJhNGQ3YjNlNzNjYzczZmNmYjA3MGJkNGRiNGMKIyBQYXJlbnQgIGUyNzIyYjI0ZGMwOTYyZGUz
NzIxNTMyMGIwNWQxYmI3YzRjNDI4NjQKSU9NTVU6IFVwZGF0ZSB0aGUgbWFpbnRhaW5lciBsaXN0
IG9mIFZULWQKU2lnbmVkLW9mZi1ieTogWGlhbnRhbyBaaGFuZzx4aWFudGFvLnpoYW5nQGludGVs
LmNvbT4KCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIGY1ODE0NjdhOGFhYyBNQUlOVEFJTkVSUwot
LS0gYS9NQUlOVEFJTkVSUwlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIGIvTUFJ
TlRBSU5FUlMJVGh1IEZlYiAwMiAwMjoyNzo1MSAyMDEyICswODAwCkBAIC0xMzgsNyArMTM4LDcg
QEAKIEY6CXhlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAogCiBJTlRFTChSKSBWVCBGT1IgRElS
RUNURUQgSS9PIChWVC1EKQotTToJQWxsZW4gS2F5IDxhbGxlbi5tLmtheUBpbnRlbC5jb20+CitN
OglYaWFudGFvIFpoYW5nIDx4aWFudGFvLnpoYW5nQGludGVsLmNvbT4KIFM6CVN1cHBvcnRlZAog
RjoJeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkLwogCg==

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 08:43:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 08:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuKAF-0006bt-0i; Mon, 06 Feb 2012 08:43:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RuKAD-0006bo-8P
	for Xen-devel@lists.xensource.com; Mon, 06 Feb 2012 08:43:05 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328517778!13859379!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjU4Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8655 invoked from network); 6 Feb 2012 08:42:58 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-182.messagelabs.com with SMTP;
	6 Feb 2012 08:42:58 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 06 Feb 2012 00:42:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,217";a="121289561"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga002.fm.intel.com with ESMTP; 06 Feb 2012 00:42:29 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 6 Feb 2012 16:41:48 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Mon, 6 Feb 2012 16:41:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Mon, 6 Feb 2012 16:41:46 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Update VT-d Maintainer
Thread-Index: AczkqygZtzTiVQNuQO64khKnpI4WVw==
Date: Mon, 6 Feb 2012 08:41:45 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440617EF@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="_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] Update VT-d Maintainer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: multipart/alternative;
	boundary="_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_"

--_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

# HG changeset patch
# User Xiantao Zhang <xiantao.zhang@intel.com>
# Date 1328120871 -28800
# Node ID f581467a8aac2a4d7b3e73cc73fcfb070bd4db4c
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
IOMMU: Update the maintainer list of VT-d
Signed-off-by: Xiantao Zhang<xiantao.zhang@intel.com>

diff -r e2722b24dc09 -r f581467a8aac MAINTAINERS
--- a/MAINTAINERS  Thu Jan 26 17:43:31 2012 +0000
+++ b/MAINTAINERS  Thu Feb 02 02:27:51 2012 +0800
@@ -138,7 +138,7 @@
F: xen/include/asm-x86/tboot.h
 INTEL(R) VT FOR DIRECTED I/O (VT-D)
-M:   Allen Kay <allen.m.kay@intel.com>
+M:   Xiantao Zhang <xiantao.zhang@intel.com>
S: Supported
F: xen/drivers/passthrough/vtd/



--_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
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:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># HG changeset patch<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># User Xiantao Zhang &lt;xiantao.zhang@intel.com&gt;<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># Date 1328120871 -28800<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># Node ID f581467a8aac2a4d7b3e73cc73fcfb070bd4db4c<o:p></=
o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"># Parent&nbsp; e2722b24dc0962de37215320b05d1bb7c4c42864<o=
:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">IOMMU: Update the maintainer list of VT-d<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">Signed-off-by: Xiantao Zhang&lt;xiantao.zhang@intel.com&g=
t;<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">diff -r e2722b24dc09 -r f581467a8aac MAINTAINERS<o:p></o:=
p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">--- a/MAINTAINERS&nbsp; Thu Jan 26 17:43:31 2012 &#43;000=
0<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">&#43;&#43;&#43; b/MAINTAINERS&nbsp; Thu Feb 02 02:27:51 2=
012 &#43;0800<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">@@ -138,7 &#43;138,7 @@<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">F: xen/include/asm-x86/tboot.h<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">&nbsp;INTEL(R) VT FOR DIRECTED I/O (VT-D)<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">-M:&nbsp;&nbsp; Allen Kay &lt;allen.m.kay@intel.com&gt;<o=
:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">&#43;M:&nbsp;&nbsp; Xiantao Zhang &lt;xiantao.zhang@intel=
.com&gt;<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">S: Supported<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;">F: xen/drivers/passthrough/vtd/<o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p></o:p></span></p>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left;text-autospa=
ce:none"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_--

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="update-vt-d-maintainer.patch"
Content-Description: update-vt-d-maintainer.patch
Content-Disposition: attachment; filename="update-vt-d-maintainer.patch";
	size=661; creation-date="Mon, 06 Feb 2012 08:39:45 GMT";
	modification-date="Mon, 06 Feb 2012 08:39:45 GMT"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFhpYW50YW8gWmhhbmcgPHhpYW50YW8uemhhbmdA
aW50ZWwuY29tPgojIERhdGUgMTMyODEyMDg3MSAtMjg4MDAKIyBOb2RlIElEIGY1ODE0NjdhOGFh
YzJhNGQ3YjNlNzNjYzczZmNmYjA3MGJkNGRiNGMKIyBQYXJlbnQgIGUyNzIyYjI0ZGMwOTYyZGUz
NzIxNTMyMGIwNWQxYmI3YzRjNDI4NjQKSU9NTVU6IFVwZGF0ZSB0aGUgbWFpbnRhaW5lciBsaXN0
IG9mIFZULWQKU2lnbmVkLW9mZi1ieTogWGlhbnRhbyBaaGFuZzx4aWFudGFvLnpoYW5nQGludGVs
LmNvbT4KCmRpZmYgLXIgZTI3MjJiMjRkYzA5IC1yIGY1ODE0NjdhOGFhYyBNQUlOVEFJTkVSUwot
LS0gYS9NQUlOVEFJTkVSUwlUaHUgSmFuIDI2IDE3OjQzOjMxIDIwMTIgKzAwMDAKKysrIGIvTUFJ
TlRBSU5FUlMJVGh1IEZlYiAwMiAwMjoyNzo1MSAyMDEyICswODAwCkBAIC0xMzgsNyArMTM4LDcg
QEAKIEY6CXhlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAogCiBJTlRFTChSKSBWVCBGT1IgRElS
RUNURUQgSS9PIChWVC1EKQotTToJQWxsZW4gS2F5IDxhbGxlbi5tLmtheUBpbnRlbC5jb20+CitN
OglYaWFudGFvIFpoYW5nIDx4aWFudGFvLnpoYW5nQGludGVsLmNvbT4KIFM6CVN1cHBvcnRlZAog
RjoJeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkLwogCg==

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_004_B6C2EB9186482D47BD0C5A9A483456440617EFSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 09:04:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 09:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuKU4-00073w-2f; Mon, 06 Feb 2012 09:03:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuKU2-00073r-Vt
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 09:03:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328518981!58599382!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 6 Feb 2012 09:03:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 09:03:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 09:03:30 +0000
Message-Id: <4F2FA56D02000078000714EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 09:03:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liuyongan" <liuyongan@huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

   >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
> In file grant_table.c function __gnttab_map_grant_ref, if __get_paged_frame 
> failed, the effect of _set_status  previously called should be rollback, so 
> the flag GTF_reading and _GTF_writing will be recovered. 

Not knowing too much about these, but isn't __acquire_grant_for_copy()
in need of a similar adjustment?

Further, aren't the status flags cumulative (and hence isn't it wrong to
simply clear flags without considering their original state)? (I realize
that this is not a new issue introduced with the proposed patch, but
certainly with more ways of getting that code path run through, it
becomes more important for it to be correct.)

Jan

> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang 
> Wang<hzwangliang.wang@huawei.com>
> 
> diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13 2012 +0800
> +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02 2012 +0800
> @@ -566,7 +566,7 @@
>              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
>              rc = __get_paged_frame(gfn, &frame, !!(op->flags & 
> GNTMAP_readonly), rd);
>              if ( rc != GNTST_okay )
> -                goto unlock_out;
> +                goto unlock_out_clear;
>              act->gfn = gfn;
>              act->domid = ld->domain_id;
>              act->frame = frame;
> @@ -721,7 +721,8 @@
>      if ( op->flags & GNTMAP_host_map )
>          act->pin -= (op->flags & GNTMAP_readonly) ?
>              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> -
> + 
> + unlock_out_clear:
>      if ( !(op->flags & GNTMAP_readonly) &&
>           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>          gnttab_clear_flag(_GTF_writing, status);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 09:04:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 09:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuKU4-00073w-2f; Mon, 06 Feb 2012 09:03:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuKU2-00073r-Vt
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 09:03:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328518981!58599382!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 6 Feb 2012 09:03:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 09:03:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 09:03:30 +0000
Message-Id: <4F2FA56D02000078000714EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 09:03:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liuyongan" <liuyongan@huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

   >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
> In file grant_table.c function __gnttab_map_grant_ref, if __get_paged_frame 
> failed, the effect of _set_status  previously called should be rollback, so 
> the flag GTF_reading and _GTF_writing will be recovered. 

Not knowing too much about these, but isn't __acquire_grant_for_copy()
in need of a similar adjustment?

Further, aren't the status flags cumulative (and hence isn't it wrong to
simply clear flags without considering their original state)? (I realize
that this is not a new issue introduced with the proposed patch, but
certainly with more ways of getting that code path run through, it
becomes more important for it to be correct.)

Jan

> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang 
> Wang<hzwangliang.wang@huawei.com>
> 
> diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13 2012 +0800
> +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02 2012 +0800
> @@ -566,7 +566,7 @@
>              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
>              rc = __get_paged_frame(gfn, &frame, !!(op->flags & 
> GNTMAP_readonly), rd);
>              if ( rc != GNTST_okay )
> -                goto unlock_out;
> +                goto unlock_out_clear;
>              act->gfn = gfn;
>              act->domid = ld->domain_id;
>              act->frame = frame;
> @@ -721,7 +721,8 @@
>      if ( op->flags & GNTMAP_host_map )
>          act->pin -= (op->flags & GNTMAP_readonly) ?
>              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> -
> + 
> + unlock_out_clear:
>      if ( !(op->flags & GNTMAP_readonly) &&
>           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>          gnttab_clear_flag(_GTF_writing, status);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 11:41:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 11:41:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuMwG-00005t-8W; Mon, 06 Feb 2012 11:40:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RuMwE-00005l-AO
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 11:40:50 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328528433!10137853!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDM5Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24268 invoked from network); 6 Feb 2012 11:40:34 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-7.tower-21.messagelabs.com with SMTP;
	6 Feb 2012 11:40:34 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY00EQ7Z14SU@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:39:04 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY00AIFZ11H3@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:39:04 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW26161; Mon,
	06 Feb 2012 19:39:03 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 19:38:26 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Mon, 06 Feb 2012 19:38:45 +0800
Date: Mon, 06 Feb 2012 11:38:44 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F2FA56D02000078000714EF@nat28.tlf.novell.com>
X-Originating-IP: [10.166.82.189]
To: Jan Beulich <JBeulich@suse.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: AQHM5K5cuI98LdezHEiIL1QuiGFaEZYvu20w
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, February 06, 2012 5:03 PM
> To: Liuyongan
> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
> Cavilla; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] grant table map error in
> __gnttab_map_grant_ref
> 
>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
> > In file grant_table.c function __gnttab_map_grant_ref, if
> __get_paged_frame
> > failed, the effect of _set_status  previously called should be
> rollback, so
> > the flag GTF_reading and _GTF_writing will be recovered.
> 
> Not knowing too much about these, but isn't __acquire_grant_for_copy()
> in need of a similar adjustment?
  Well, I need to check it further.
> 
> Further, aren't the status flags cumulative (and hence isn't it wrong
> to
> simply clear flags without considering their original state)? 
  When undo_out branch is executed, the flag set by _set_status function
  will be rolled back by:
       if ( !(op->flags & GNTMAP_readonly) &&
         !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
        gnttab_clear_flag(_GTF_writing, status);

       if ( !act->pin )
        gnttab_clear_flag(_GTF_reading, status);
  so action added by this patch should be correct. 

  And anyway, the  reading and writing flag should be recovered when mapping 
  grant reference failed, so the up layer(eg. Netback driver) can decide 
  freely whether retry mapping or fail directly.

> (I realize
> that this is not a new issue introduced with the proposed patch, but
> certainly with more ways of getting that code path run through, it
> becomes more important for it to be correct.)
> 
> Jan
> 
> > Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
> > Wang<hzwangliang.wang@huawei.com>
> >
> > diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> > --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13
> 2012 +0800
> > +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02
> 2012 +0800
> > @@ -566,7 +566,7 @@
> >              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
> >              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
> > GNTMAP_readonly), rd);
> >              if ( rc != GNTST_okay )
> > -                goto unlock_out;
> > +                goto unlock_out_clear;
> >              act->gfn = gfn;
> >              act->domid = ld->domain_id;
> >              act->frame = frame;
> > @@ -721,7 +721,8 @@
> >      if ( op->flags & GNTMAP_host_map )
> >          act->pin -= (op->flags & GNTMAP_readonly) ?
> >              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> > -
> > +
> > + unlock_out_clear:
> >      if ( !(op->flags & GNTMAP_readonly) &&
> >           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> >          gnttab_clear_flag(_GTF_writing, status);
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 11:41:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 11:41:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuMwG-00005t-8W; Mon, 06 Feb 2012 11:40:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RuMwE-00005l-AO
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 11:40:50 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328528433!10137853!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDM5Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24268 invoked from network); 6 Feb 2012 11:40:34 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-7.tower-21.messagelabs.com with SMTP;
	6 Feb 2012 11:40:34 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY00EQ7Z14SU@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:39:04 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY00AIFZ11H3@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:39:04 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW26161; Mon,
	06 Feb 2012 19:39:03 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 19:38:26 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Mon, 06 Feb 2012 19:38:45 +0800
Date: Mon, 06 Feb 2012 11:38:44 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F2FA56D02000078000714EF@nat28.tlf.novell.com>
X-Originating-IP: [10.166.82.189]
To: Jan Beulich <JBeulich@suse.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: AQHM5K5cuI98LdezHEiIL1QuiGFaEZYvu20w
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, February 06, 2012 5:03 PM
> To: Liuyongan
> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
> Cavilla; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] grant table map error in
> __gnttab_map_grant_ref
> 
>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
> > In file grant_table.c function __gnttab_map_grant_ref, if
> __get_paged_frame
> > failed, the effect of _set_status  previously called should be
> rollback, so
> > the flag GTF_reading and _GTF_writing will be recovered.
> 
> Not knowing too much about these, but isn't __acquire_grant_for_copy()
> in need of a similar adjustment?
  Well, I need to check it further.
> 
> Further, aren't the status flags cumulative (and hence isn't it wrong
> to
> simply clear flags without considering their original state)? 
  When undo_out branch is executed, the flag set by _set_status function
  will be rolled back by:
       if ( !(op->flags & GNTMAP_readonly) &&
         !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
        gnttab_clear_flag(_GTF_writing, status);

       if ( !act->pin )
        gnttab_clear_flag(_GTF_reading, status);
  so action added by this patch should be correct. 

  And anyway, the  reading and writing flag should be recovered when mapping 
  grant reference failed, so the up layer(eg. Netback driver) can decide 
  freely whether retry mapping or fail directly.

> (I realize
> that this is not a new issue introduced with the proposed patch, but
> certainly with more ways of getting that code path run through, it
> becomes more important for it to be correct.)
> 
> Jan
> 
> > Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
> > Wang<hzwangliang.wang@huawei.com>
> >
> > diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> > --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13
> 2012 +0800
> > +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02
> 2012 +0800
> > @@ -566,7 +566,7 @@
> >              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
> >              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
> > GNTMAP_readonly), rd);
> >              if ( rc != GNTST_okay )
> > -                goto unlock_out;
> > +                goto unlock_out_clear;
> >              act->gfn = gfn;
> >              act->domid = ld->domain_id;
> >              act->frame = frame;
> > @@ -721,7 +721,8 @@
> >      if ( op->flags & GNTMAP_host_map )
> >          act->pin -= (op->flags & GNTMAP_readonly) ?
> >              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> > -
> > +
> > + unlock_out_clear:
> >      if ( !(op->flags & GNTMAP_readonly) &&
> >           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> >          gnttab_clear_flag(_GTF_writing, status);
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 11:49:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 11: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.xensource.com>)
	id 1RuN42-0000SB-EE; Mon, 06 Feb 2012 11:48:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RuN41-0000S3-9E
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 11:48:53 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328528923!12023290!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29284 invoked from network); 6 Feb 2012 11:48:44 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-16.tower-216.messagelabs.com with SMTP;
	6 Feb 2012 11:48:44 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY00ETRZGNK2@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:48:23 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY002R8ZGJKS@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:48:23 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW26920; Mon,
	06 Feb 2012 19:48:23 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 19:47:54 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by SZXEML414-HUB.china.huawei.com ([10.82.67.153])
	with mapi id 14.01.0323.003; Mon, 06 Feb 2012 19:48:49 +0800
Date: Mon, 06 Feb 2012 11:48:01 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD170@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] xend memory leakage
Thread-index: AczkxSxSilcdUZIRQUmNeWFtmXGJ9g==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: AONz AeiS BGku C2zT Daf4 D0g7 D1kI Ebee EsZc E/xN Fdt+ F6tz
	GtmD HE/t HvIC IVKM; 1;
	eABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {DECC3C50-BFB9-45AC-8794-96EB6D582615};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon,
	06 Feb 2012 11:47:59 GMT;
	WwB4AGUAbgAtAGQAZQB2AGUAbABdACAAeABlAG4AZAAgAG0AZQBtAG8AcgB5ACAAbABlAGEAawBhAGcAZQA=
x-cr-puzzleid: {DECC3C50-BFB9-45AC-8794-96EB6D582615}
X-CFilter-Loop: Reflected
Cc: WangYunyi <yunyi.wang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>
Subject: [Xen-devel] [xen-devel] xend memory leakage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When I repeated restarting VM or define and undefined VM during my recently test, memory leakage of xend is detected. Our elementary conclusion is that the python memory management mechanism causes this problem, but I do not know how to further locate the exact lines. Can anybody here give me any suggestions?  Thx.

Yong an Liu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 11:49:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 11: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.xensource.com>)
	id 1RuN42-0000SB-EE; Mon, 06 Feb 2012 11:48:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RuN41-0000S3-9E
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 11:48:53 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328528923!12023290!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29284 invoked from network); 6 Feb 2012 11:48:44 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-16.tower-216.messagelabs.com with SMTP;
	6 Feb 2012 11:48:44 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY00ETRZGNK2@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:48:23 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYY002R8ZGJKS@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:48:23 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW26920; Mon,
	06 Feb 2012 19:48:23 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 19:47:54 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by SZXEML414-HUB.china.huawei.com ([10.82.67.153])
	with mapi id 14.01.0323.003; Mon, 06 Feb 2012 19:48:49 +0800
Date: Mon, 06 Feb 2012 11:48:01 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD170@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] xend memory leakage
Thread-index: AczkxSxSilcdUZIRQUmNeWFtmXGJ9g==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: AONz AeiS BGku C2zT Daf4 D0g7 D1kI Ebee EsZc E/xN Fdt+ F6tz
	GtmD HE/t HvIC IVKM; 1;
	eABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {DECC3C50-BFB9-45AC-8794-96EB6D582615};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon,
	06 Feb 2012 11:47:59 GMT;
	WwB4AGUAbgAtAGQAZQB2AGUAbABdACAAeABlAG4AZAAgAG0AZQBtAG8AcgB5ACAAbABlAGEAawBhAGcAZQA=
x-cr-puzzleid: {DECC3C50-BFB9-45AC-8794-96EB6D582615}
X-CFilter-Loop: Reflected
Cc: WangYunyi <yunyi.wang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>
Subject: [Xen-devel] [xen-devel] xend memory leakage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When I repeated restarting VM or define and undefined VM during my recently test, memory leakage of xend is detected. Our elementary conclusion is that the python memory management mechanism causes this problem, but I do not know how to further locate the exact lines. Can anybody here give me any suggestions?  Thx.

Yong an Liu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 12:10:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 12: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.xensource.com>)
	id 1RuNOl-0000p9-7n; Mon, 06 Feb 2012 12:10:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RuNOj-0000p1-3T
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 12:10:17 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328530210!10143597!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31519 invoked from network); 6 Feb 2012 12:10:10 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 12:10:10 -0000
Received: by lagp5 with SMTP id p5so4905906lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 04:10:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=e9CyqvvPvqUGvriMHt5FieGEMdNskWwx4Suj40p9Sb8=;
	b=Mece5Prmaqqnq05j0MBL/WSDC5eWbPCGj2iPD5oHig9G36fg0KwRvc5/S5Eu3xqPrL
	pvtdsCovQB0vwGYivbw7gAiB3ueUE915zUR+7tn0LrUdlx0gHCfYYb3Ns1RnOLS8XyHc
	zt0pjScQyTmrPQKYH4f4VldLrL5Z1uK5KyAlE=
Received: by 10.112.32.1 with SMTP id e1mr4831790lbi.3.1328530210120; Mon, 06
	Feb 2012 04:10:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Mon, 6 Feb 2012 04:09:55 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Mon, 6 Feb 2012 16:09:55 +0400
X-Google-Sender-Auth: bjV_zB4lDK1gNOquikmsbNQWfmI
Message-ID: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello. I'm try to run domU kernel from backports.debian.org under 32
bit guest (686-pae), but after sometime i get error in dmesg:

http://cdn.selfip.ru/hang.png

in guest loaded only xen-netfront.ko module.

What does it mean?

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 12:10:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 12: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.xensource.com>)
	id 1RuNOl-0000p9-7n; Mon, 06 Feb 2012 12:10:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RuNOj-0000p1-3T
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 12:10:17 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328530210!10143597!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31519 invoked from network); 6 Feb 2012 12:10:10 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 12:10:10 -0000
Received: by lagp5 with SMTP id p5so4905906lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 04:10:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=e9CyqvvPvqUGvriMHt5FieGEMdNskWwx4Suj40p9Sb8=;
	b=Mece5Prmaqqnq05j0MBL/WSDC5eWbPCGj2iPD5oHig9G36fg0KwRvc5/S5Eu3xqPrL
	pvtdsCovQB0vwGYivbw7gAiB3ueUE915zUR+7tn0LrUdlx0gHCfYYb3Ns1RnOLS8XyHc
	zt0pjScQyTmrPQKYH4f4VldLrL5Z1uK5KyAlE=
Received: by 10.112.32.1 with SMTP id e1mr4831790lbi.3.1328530210120; Mon, 06
	Feb 2012 04:10:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Mon, 6 Feb 2012 04:09:55 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Mon, 6 Feb 2012 16:09:55 +0400
X-Google-Sender-Auth: bjV_zB4lDK1gNOquikmsbNQWfmI
Message-ID: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello. I'm try to run domU kernel from backports.debian.org under 32
bit guest (686-pae), but after sometime i get error in dmesg:

http://cdn.selfip.ru/hang.png

in guest loaded only xen-netfront.ko module.

What does it mean?

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 12:23:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 12: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.xensource.com>)
	id 1RuNbK-0001B1-J7; Mon, 06 Feb 2012 12:23:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RuNbJ-0001Aw-6T
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 12:23:17 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328530989!4704933!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDM5Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24010 invoked from network); 6 Feb 2012 12:23:10 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-4.tower-21.messagelabs.com with SMTP;
	6 Feb 2012 12:23:10 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYZ00ERD0Z1SU@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 20:21:01 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYZ00KMR0YM0T@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 20:21:01 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW29570; Mon,
	06 Feb 2012 20:21:00 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32)
	by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 20:20:23 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Mon, 06 Feb 2012 20:20:41 +0800
Date: Mon, 06 Feb 2012 12:20:41 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD1B4@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: Aczkyb0yzqfKia/mQ3iKawQLJbmxcw==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Cc: Zhanghaoyu <haoyu.zhang@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, Jan Beulich <JBeulich@suse.com>,
	hanweidong <hanweidong@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> Date: Sat, 04 Feb 2012 02:43:05 +0000
>> From: Liuyongan <liuyongan@huawei.com>
>> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>> Cc: Wang Liang <hzwangliang.wang@huawei.com>,	Zhanghaoyu
>>	<haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
>>	hanweidong <hanweidong@huawei.com>
>> Subject: [Xen-devel] [PATCH] grant table map error in
>>	__gnttab_map_grant_ref
>> Message-ID:
>>	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>>   In file grant_table.c function __gnttab_map_grant_ref, if
>> __get_paged_frame failed, the effect of _set_status  previously called
>> should be rollback, so the flag GTF_reading and _GTF_writing will be
>> recovered.
>> 
>> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
>> Wang<hzwangliang.wang@huawei.com>
>
> Hi,
> great fix! Would you mind submitting the same fix to the unstable tree?

  Feel free to use this patch.
> 
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 
   Well, I donot understand why contents" Message: 3, Message: 4, Message: 5" appear in your initial mail, Any special meaning?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 12:23:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 12: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.xensource.com>)
	id 1RuNbK-0001B1-J7; Mon, 06 Feb 2012 12:23:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RuNbJ-0001Aw-6T
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 12:23:17 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328530989!4704933!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDM5Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24010 invoked from network); 6 Feb 2012 12:23:10 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-4.tower-21.messagelabs.com with SMTP;
	6 Feb 2012 12:23:10 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYZ00ERD0Z1SU@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 20:21:01 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LYZ00KMR0YM0T@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 06 Feb 2012 20:21:01 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW29570; Mon,
	06 Feb 2012 20:21:00 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32)
	by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 06 Feb 2012 20:20:23 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Mon, 06 Feb 2012 20:20:41 +0800
Date: Mon, 06 Feb 2012 12:20:41 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD1B4@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: Aczkyb0yzqfKia/mQ3iKawQLJbmxcw==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Cc: Zhanghaoyu <haoyu.zhang@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, Jan Beulich <JBeulich@suse.com>,
	hanweidong <hanweidong@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> Date: Sat, 04 Feb 2012 02:43:05 +0000
>> From: Liuyongan <liuyongan@huawei.com>
>> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>> Cc: Wang Liang <hzwangliang.wang@huawei.com>,	Zhanghaoyu
>>	<haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
>>	hanweidong <hanweidong@huawei.com>
>> Subject: [Xen-devel] [PATCH] grant table map error in
>>	__gnttab_map_grant_ref
>> Message-ID:
>>	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>>   In file grant_table.c function __gnttab_map_grant_ref, if
>> __get_paged_frame failed, the effect of _set_status  previously called
>> should be rollback, so the flag GTF_reading and _GTF_writing will be
>> recovered.
>> 
>> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
>> Wang<hzwangliang.wang@huawei.com>
>
> Hi,
> great fix! Would you mind submitting the same fix to the unstable tree?

  Feel free to use this patch.
> 
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 
   Well, I donot understand why contents" Message: 3, Message: 4, Message: 5" appear in your initial mail, Any special meaning?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 12:25:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 12: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.xensource.com>)
	id 1RuNd8-0001Ew-4b; Mon, 06 Feb 2012 12:25:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RuNd6-0001Ec-Ol
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 12:25:08 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328531101!12147074!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16148 invoked from network); 6 Feb 2012 12:25:02 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.12)
	by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Feb 2012 12:25:02 -0000
Received: from mail137-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 12:25:01 +0000
Received: from mail137-tx2 (localhost [127.0.0.1])	by
	mail137-tx2-R.bigfish.com (Postfix) with ESMTP id E10144000E3;
	Mon,  6 Feb 2012 12:25:00 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2
	(MessageSwitch) id 1328531097969502_20124;
	Mon,  6 Feb 2012 12:24:57 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.235])	by
	mail137-tx2.bigfish.com (Postfix) with ESMTP id DD45222022E;
	Mon,  6 Feb 2012 12:24:57 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 12:24:57 +0000
X-WSS-ID: 0LYZ15I-01-4H1-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 2B0A11028029;	Mon,  6 Feb 2012 06:24:54 -0600 (CST)
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, 6 Feb 2012 06:24:59 -0600
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.289.1;
	Mon, 6 Feb 2012 06:24:54 -0600
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, 6 Feb 2012
	07:24:53 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B0EE249C2B0; Mon,  6 Feb 2012
	12:24:52 +0000 (GMT)
Message-ID: <4F2FC7AD.5080300@amd.com>
Date: Mon, 6 Feb 2012 13:29:33 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
	<4F2C1ADC0200007800071232@nat28.tlf.novell.com>
In-Reply-To: <4F2C1ADC0200007800071232@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] amd iommu: Fix a return value of
	guest_iommu_set_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/2012 05:35 PM, Jan Beulich wrote:
>>>> On 03.02.12 at 16:29, Wei Wang<wei.wang2@amd.com>  wrote:
>> # HG changeset patch
>> # User Wei Wang<wei.wang2@amd.com>
>> # Date 1328282938 -3600
>> # Node ID 58a2281581a4c4171ca52549b3e8062b9733ec2b
>> # Parent  3432abcf9380d3840ca38439a304f74a37d155fc
>> amd iommu: Fix a return value of guest_iommu_set_base()
>> Remove a unnecessary check in guest_iommu_destroy()
>>
>> Signed-off-by: Wei Wang<wei.wang2@amd.com>
>>
>> diff -r 3432abcf9380 -r 58a2281581a4 xen/drivers/passthrough/amd/iommu_guest.c
>> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
>> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 03 16:28:58 2012
>> +0100
>> @@ -806,7 +806,7 @@ int guest_iommu_set_base(struct domain *
>>       struct guest_iommu *iommu = domain_iommu(d);
>>
>>       if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>> -        return 0;
>> +        return -EACCES;
>
> But as indicated before, all three checks above are redundant with
> the one check below. Hence I suggested to remove the checks above,
> and if you wish put an ASSERT() past the !iommu check below.

OK,then I remove them all. I will send a new thread for the patch.
Thanks,
Wei

> Jan
>
>>
>>       if ( !iommu )
>>           return -EACCES;
>> @@ -896,9 +896,6 @@ void guest_iommu_destroy(struct domain *
>>   {
>>       struct guest_iommu *iommu;
>>
>> -    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>> -        return;
>> -
>>       iommu = domain_iommu(d);
>>       if ( !iommu )
>>           return;
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 12:25:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 12: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.xensource.com>)
	id 1RuNd8-0001Ew-4b; Mon, 06 Feb 2012 12:25:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RuNd6-0001Ec-Ol
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 12:25:08 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328531101!12147074!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16148 invoked from network); 6 Feb 2012 12:25:02 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.12)
	by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Feb 2012 12:25:02 -0000
Received: from mail137-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 12:25:01 +0000
Received: from mail137-tx2 (localhost [127.0.0.1])	by
	mail137-tx2-R.bigfish.com (Postfix) with ESMTP id E10144000E3;
	Mon,  6 Feb 2012 12:25:00 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2
	(MessageSwitch) id 1328531097969502_20124;
	Mon,  6 Feb 2012 12:24:57 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.235])	by
	mail137-tx2.bigfish.com (Postfix) with ESMTP id DD45222022E;
	Mon,  6 Feb 2012 12:24:57 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 12:24:57 +0000
X-WSS-ID: 0LYZ15I-01-4H1-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 2B0A11028029;	Mon,  6 Feb 2012 06:24:54 -0600 (CST)
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, 6 Feb 2012 06:24:59 -0600
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.289.1;
	Mon, 6 Feb 2012 06:24:54 -0600
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, 6 Feb 2012
	07:24:53 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B0EE249C2B0; Mon,  6 Feb 2012
	12:24:52 +0000 (GMT)
Message-ID: <4F2FC7AD.5080300@amd.com>
Date: Mon, 6 Feb 2012 13:29:33 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <58a2281581a4c4171ca5.1328282951@gran.amd.com>
	<4F2C1ADC0200007800071232@nat28.tlf.novell.com>
In-Reply-To: <4F2C1ADC0200007800071232@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] amd iommu: Fix a return value of
	guest_iommu_set_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/03/2012 05:35 PM, Jan Beulich wrote:
>>>> On 03.02.12 at 16:29, Wei Wang<wei.wang2@amd.com>  wrote:
>> # HG changeset patch
>> # User Wei Wang<wei.wang2@amd.com>
>> # Date 1328282938 -3600
>> # Node ID 58a2281581a4c4171ca52549b3e8062b9733ec2b
>> # Parent  3432abcf9380d3840ca38439a304f74a37d155fc
>> amd iommu: Fix a return value of guest_iommu_set_base()
>> Remove a unnecessary check in guest_iommu_destroy()
>>
>> Signed-off-by: Wei Wang<wei.wang2@amd.com>
>>
>> diff -r 3432abcf9380 -r 58a2281581a4 xen/drivers/passthrough/amd/iommu_guest.c
>> --- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
>> +++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 03 16:28:58 2012
>> +0100
>> @@ -806,7 +806,7 @@ int guest_iommu_set_base(struct domain *
>>       struct guest_iommu *iommu = domain_iommu(d);
>>
>>       if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>> -        return 0;
>> +        return -EACCES;
>
> But as indicated before, all three checks above are redundant with
> the one check below. Hence I suggested to remove the checks above,
> and if you wish put an ASSERT() past the !iommu check below.

OK,then I remove them all. I will send a new thread for the patch.
Thanks,
Wei

> Jan
>
>>
>>       if ( !iommu )
>>           return -EACCES;
>> @@ -896,9 +896,6 @@ void guest_iommu_destroy(struct domain *
>>   {
>>       struct guest_iommu *iommu;
>>
>> -    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
>> -        return;
>> -
>>       iommu = domain_iommu(d);
>>       if ( !iommu )
>>           return;
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 14:33:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 14: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.xensource.com>)
	id 1RuPcd-0003Gk-8A; Mon, 06 Feb 2012 14:32:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RuPcb-0003Gd-LG
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 14:32:45 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328538757!13131059!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2549 invoked from network); 6 Feb 2012 14:32:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2012 14:32:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RuPcR-0007qF-F6
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 06:32:35 -0800
Date: Mon, 6 Feb 2012 06:32:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328538755451-5460198.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I tried to use cdrom in domU linux pv (Linux Mint 11 based on Natty).
With '/mnt/vm/iso/test.iso,raw,xvdb,ro,cdrom', Mint sees it as internal disk
(not cdrom) and only administrators can mount it.
I tried also '/dev/scd0,raw,xvdb,ro,cdrom' does the same thing.
Is possible use cdrom on linux domU pv full working where also normal user
can mount it without terminal?
Did I something wrong, or are there still bugs in this regard?

Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24593:e2722b24dc09

DomU xl file configuration:
-------------------------
name='MINT11PV'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/MINT11PV.disk1.xm,raw,xvda1,rw',
'/mnt/vm/iso/test.iso,raw,xvdb,ro,cdrom']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader = '/usr/bin/pygrub'
-------------------------

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5460198.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 14:33:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 14: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.xensource.com>)
	id 1RuPcd-0003Gk-8A; Mon, 06 Feb 2012 14:32:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RuPcb-0003Gd-LG
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 14:32:45 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328538757!13131059!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2549 invoked from network); 6 Feb 2012 14:32:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2012 14:32:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RuPcR-0007qF-F6
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 06:32:35 -0800
Date: Mon, 6 Feb 2012 06:32:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328538755451-5460198.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I tried to use cdrom in domU linux pv (Linux Mint 11 based on Natty).
With '/mnt/vm/iso/test.iso,raw,xvdb,ro,cdrom', Mint sees it as internal disk
(not cdrom) and only administrators can mount it.
I tried also '/dev/scd0,raw,xvdb,ro,cdrom' does the same thing.
Is possible use cdrom on linux domU pv full working where also normal user
can mount it without terminal?
Did I something wrong, or are there still bugs in this regard?

Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24593:e2722b24dc09

DomU xl file configuration:
-------------------------
name='MINT11PV'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/MINT11PV.disk1.xm,raw,xvda1,rw',
'/mnt/vm/iso/test.iso,raw,xvdb,ro,cdrom']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader = '/usr/bin/pygrub'
-------------------------

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5460198.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 14:41:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 14: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.xensource.com>)
	id 1RuPkE-0003Pj-6p; Mon, 06 Feb 2012 14:40:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RuPkC-0003PZ-DV
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 14:40:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328539229!6475144!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32316 invoked from network); 6 Feb 2012 14:40:30 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 14:40:30 -0000
Received: by qcsp15 with SMTP id p15so31982731qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 06:40:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=p3Jgbs5qyXhoQglFkK4Zh8lka8CdiuoIUzk1BF88cMs=;
	b=Q6PKAtJTPmX1FoQe/YbGWHXZjZliiogHCnmk2+ZYHHBzj1Iz3At9TCtVx8F8VyesYi
	Ecdk2KwKLs20vjHFVdHlAPiM8iua/RnH1puOASeaGJ1e1AlnEakwE5/CagTjjadT/4lY
	fWHhMMUbyYad+w7r0m/gLpTMom7GbjBqkTxFQ=
Received: by 10.229.135.83 with SMTP id m19mr1761980qct.43.1328539226081;
	Mon, 06 Feb 2012 06:40:26 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id g9sm34029598qad.16.2012.02.06.06.40.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 06 Feb 2012 06:40:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 67d41a95b5a77b91b16acfe6f4540aa487b57f5d
Message-Id: <67d41a95b5a77b91b16a.1328539209@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 06 Feb 2012 15:40:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] pygrub: extlinux parsing correctness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328539206 -3600
# Node ID 67d41a95b5a77b91b16acfe6f4540aa487b57f5d
# Parent  9e2f11af4f13e24b1bc4daab2067417d1874f4a9
pygrub: extlinux parsing correctness

The "in" operator should be used instead of the find method, since
we are only interested in knowing whether the line contains "initrd=",
but we don't care about it's position. Also fixes an error that
happens when initrd= it's at the start of the line, since find returns
0 and is evaluated as False.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9e2f11af4f13 -r 67d41a95b5a7 tools/pygrub/src/ExtLinuxConf.py
--- a/tools/pygrub/src/ExtLinuxConf.py	Mon Feb 06 12:29:59 2012 +0100
+++ b/tools/pygrub/src/ExtLinuxConf.py	Mon Feb 06 15:40:06 2012 +0100
@@ -60,7 +60,7 @@ class ExtLinuxImage(object):
 
                 # Bypass regular self.commands handling
                 com = None
-            elif arg.find("initrd="):
+            elif "initrd=" in arg:
                 # find initrd image in append line
                 args = arg.strip().split(" ")
                 for a in args:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 14:41:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 14: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.xensource.com>)
	id 1RuPkE-0003Pj-6p; Mon, 06 Feb 2012 14:40:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RuPkC-0003PZ-DV
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 14:40:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328539229!6475144!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32316 invoked from network); 6 Feb 2012 14:40:30 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 14:40:30 -0000
Received: by qcsp15 with SMTP id p15so31982731qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 06:40:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=p3Jgbs5qyXhoQglFkK4Zh8lka8CdiuoIUzk1BF88cMs=;
	b=Q6PKAtJTPmX1FoQe/YbGWHXZjZliiogHCnmk2+ZYHHBzj1Iz3At9TCtVx8F8VyesYi
	Ecdk2KwKLs20vjHFVdHlAPiM8iua/RnH1puOASeaGJ1e1AlnEakwE5/CagTjjadT/4lY
	fWHhMMUbyYad+w7r0m/gLpTMom7GbjBqkTxFQ=
Received: by 10.229.135.83 with SMTP id m19mr1761980qct.43.1328539226081;
	Mon, 06 Feb 2012 06:40:26 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id g9sm34029598qad.16.2012.02.06.06.40.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 06 Feb 2012 06:40:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 67d41a95b5a77b91b16acfe6f4540aa487b57f5d
Message-Id: <67d41a95b5a77b91b16a.1328539209@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 06 Feb 2012 15:40:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] pygrub: extlinux parsing correctness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1328539206 -3600
# Node ID 67d41a95b5a77b91b16acfe6f4540aa487b57f5d
# Parent  9e2f11af4f13e24b1bc4daab2067417d1874f4a9
pygrub: extlinux parsing correctness

The "in" operator should be used instead of the find method, since
we are only interested in knowing whether the line contains "initrd=",
but we don't care about it's position. Also fixes an error that
happens when initrd= it's at the start of the line, since find returns
0 and is evaluated as False.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9e2f11af4f13 -r 67d41a95b5a7 tools/pygrub/src/ExtLinuxConf.py
--- a/tools/pygrub/src/ExtLinuxConf.py	Mon Feb 06 12:29:59 2012 +0100
+++ b/tools/pygrub/src/ExtLinuxConf.py	Mon Feb 06 15:40:06 2012 +0100
@@ -60,7 +60,7 @@ class ExtLinuxImage(object):
 
                 # Bypass regular self.commands handling
                 com = None
-            elif arg.find("initrd="):
+            elif "initrd=" in arg:
                 # find initrd image in append line
                 args = arg.strip().split(" ")
                 for a in args:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 15:46:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 15:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuQl7-00045j-3e; Mon, 06 Feb 2012 15:45:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RuQl5-00045A-Bf
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:45:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328543126!10677789!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODM2NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6412 invoked from network); 6 Feb 2012 15:45:27 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-12.tower-21.messagelabs.com with SMTP;
	6 Feb 2012 15:45:27 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id A2F0571408A;
	Mon,  6 Feb 2012 07:45:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=vZ+U/JoRi18eS3wwPof3QyAqRBaVaxFuedes/aJbLspk
	ZCDMbR3lOrUDY+eLEpKz1nDPGB8lZ42NnZJTDALjoIGWTiG/534VnkF8QjGFotdT
	GavhcKxlgjZ97MFfAJLm+fsr28HAq/n0WOuic1H//EmsmDqRF8rwTsob9+JQM8g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=0MAYgthqjz3fj0zJuIxvXPRYRz8=; b=nyG0M9+J
	Rmtqoo7IVBZPwMOhwl8ib1/xZbT5IjJumwHniIT/Bj7cJpCsvrmPxZHADOKVUPvK
	ZgyaTAjybCIsb4u/tDyetbq7D+pI/UdPTyt8vSwbQc9JmG92SDjgbNNs214aQ91R
	XGdrqUlYAZyPQ2/44Wpl8RRjqqQ40x9KivI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 3B69B714085; 
	Mon,  6 Feb 2012 07:45:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 6 Feb 2012 07:45:24 -0800
Message-ID: <3ca8a54d58bb0237b941f1d5d3ad21c0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD1B4@szxeml534-mbx.china.huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD1B4@szxeml534-mbx.china.huawei.com>
Date: Mon, 6 Feb 2012 07:45:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Liuyongan" <liuyongan@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Zhanghaoyu <haoyu.zhang@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, Jan Beulich <jbeulich@suse.com>,
	hanweidong <hanweidong@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> Date: Sat, 04 Feb 2012 02:43:05 +0000
>>> From: Liuyongan <liuyongan@huawei.com>
>>> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>>> Cc: Wang Liang <hzwangliang.wang@huawei.com>,	Zhanghaoyu
>>>	<haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
>>>	hanweidong <hanweidong@huawei.com>
>>> Subject: [Xen-devel] [PATCH] grant table map error in
>>>	__gnttab_map_grant_ref
>>> Message-ID:
>>>	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
>>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>>   In file grant_table.c function __gnttab_map_grant_ref, if
>>> __get_paged_frame failed, the effect of _set_status  previously called
>>> should be rollback, so the flag GTF_reading and _GTF_writing will be
>>> recovered.
>>>
>>> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
>>> Wang<hzwangliang.wang@huawei.com>
>>
>> Hi,
>> great fix! Would you mind submitting the same fix to the unstable tree?
>
>   Feel free to use this patch.

I certainly will :) But my request is whether you'd be able to rebase it
to the unstable tree, as it seems based on 4.1.1.

>>
>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
>    Well, I donot understand why contents" Message: 3, Message: 4, Message:
> 5" appear in your initial mail, Any special meaning?

None at all, just me being a bit lame
Thanks
Andres

>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 15:46:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 15:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuQl7-00045j-3e; Mon, 06 Feb 2012 15:45:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RuQl5-00045A-Bf
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:45:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328543126!10677789!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODM2NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6412 invoked from network); 6 Feb 2012 15:45:27 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-12.tower-21.messagelabs.com with SMTP;
	6 Feb 2012 15:45:27 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id A2F0571408A;
	Mon,  6 Feb 2012 07:45:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=vZ+U/JoRi18eS3wwPof3QyAqRBaVaxFuedes/aJbLspk
	ZCDMbR3lOrUDY+eLEpKz1nDPGB8lZ42NnZJTDALjoIGWTiG/534VnkF8QjGFotdT
	GavhcKxlgjZ97MFfAJLm+fsr28HAq/n0WOuic1H//EmsmDqRF8rwTsob9+JQM8g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=0MAYgthqjz3fj0zJuIxvXPRYRz8=; b=nyG0M9+J
	Rmtqoo7IVBZPwMOhwl8ib1/xZbT5IjJumwHniIT/Bj7cJpCsvrmPxZHADOKVUPvK
	ZgyaTAjybCIsb4u/tDyetbq7D+pI/UdPTyt8vSwbQc9JmG92SDjgbNNs214aQ91R
	XGdrqUlYAZyPQ2/44Wpl8RRjqqQ40x9KivI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 3B69B714085; 
	Mon,  6 Feb 2012 07:45:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 6 Feb 2012 07:45:24 -0800
Message-ID: <3ca8a54d58bb0237b941f1d5d3ad21c0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD1B4@szxeml534-mbx.china.huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD1B4@szxeml534-mbx.china.huawei.com>
Date: Mon, 6 Feb 2012 07:45:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Liuyongan" <liuyongan@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Zhanghaoyu <haoyu.zhang@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, Jan Beulich <jbeulich@suse.com>,
	hanweidong <hanweidong@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> Date: Sat, 04 Feb 2012 02:43:05 +0000
>>> From: Liuyongan <liuyongan@huawei.com>
>>> To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>>> Cc: Wang Liang <hzwangliang.wang@huawei.com>,	Zhanghaoyu
>>>	<haoyu.zhang@huawei.com>, Qianhuibin <qianhuibin@huawei.com>,
>>>	hanweidong <hanweidong@huawei.com>
>>> Subject: [Xen-devel] [PATCH] grant table map error in
>>>	__gnttab_map_grant_ref
>>> Message-ID:
>>>	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
>>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>>   In file grant_table.c function __gnttab_map_grant_ref, if
>>> __get_paged_frame failed, the effect of _set_status  previously called
>>> should be rollback, so the flag GTF_reading and _GTF_writing will be
>>> recovered.
>>>
>>> Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
>>> Wang<hzwangliang.wang@huawei.com>
>>
>> Hi,
>> great fix! Would you mind submitting the same fix to the unstable tree?
>
>   Feel free to use this patch.

I certainly will :) But my request is whether you'd be able to rebase it
to the unstable tree, as it seems based on 4.1.1.

>>
>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
>    Well, I donot understand why contents" Message: 3, Message: 4, Message:
> 5" appear in your initial mail, Any special meaning?

None at all, just me being a bit lame
Thanks
Andres

>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 15:56:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 15: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.xensource.com>)
	id 1RuQv4-0004fG-9k; Mon, 06 Feb 2012 15:55:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RuQv3-0004f9-6Z
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:55:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328543744!13922267!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5ODAw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5ODAw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14919 invoked from network); 6 Feb 2012 15:55:45 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-182.messagelabs.com with SMTP;
	6 Feb 2012 15:55:45 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id D6C014B007C;
	Mon,  6 Feb 2012 07:55:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YO9pSH5yj95NjcMmsrNB6gdJhXYmUdKB9olzjXsu1cw7
	nLYIaHQj7SyPgl/kUsX01dDnQ2O1/ki7U2dAKh0/sZ2by+zLe7LzNTCZ5Y4OK3Q+
	HRTNM4pPdGBgIDTk7KEhuZ8lK6BVVRFiQpkg7IuWJJ0c6KetY3IE6lLVNd5IKZo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=tsVd9UjzXT4kVBK982IWXF+8+6A=; b=fYM0tpgi
	m8E+zBcbecyAJ4NCsC6eYzspjh85Ak/BkKaW5XvorSIRYjAv3ONG6W11JJPfUzSY
	YZEuFYmZa1ey0O1x2pgeeHcXJHNIMOFGwKbOwuF+BG67vYyDSeSNcPWdRAqSkvwI
	+ZioIxRTemfBpuZ+cHtFEL8ObhNUrnLPVRM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 077DB4B006D; 
	Mon,  6 Feb 2012 07:55:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 6 Feb 2012 07:55:43 -0800
Message-ID: <1389361a301b9952337ecd82e841e46e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328112859.17444.94.camel@zakaz.uk.xensource.com>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
	<1328089685.17444.15.camel@zakaz.uk.xensource.com>
	<8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
	<1328112859.17444.94.camel@zakaz.uk.xensource.com>
Date: Mon, 6 Feb 2012 07:55:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 15:58 +0000, Andres Lagar-Cavilla wrote:
>> > On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
>> >> Config.mk            |   1 +
>> >>  tools/Makefile       |   1 +
>> >>  tools/tests/Makefile |  20 ++++++++++++++++++++
>> >>  3 files changed, 22 insertions(+), 0 deletions(-)
>> >>
>> >>
>> >> Build tests as part of the tools build.
>> >>
>> >> It is enabled with CONFIG_TESTS in Config.mk
>> >>
>> >> Currently disabled build of tests/regressions and tests/xen-access
>> (in
>> >> 32 bit
>> >> mode) as they fail.
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >
>> > Ack on the idea but the actual implementation fails for me:
>> >
>> > make[1]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools'
>> > make -C tests install
>> > make[2]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
>> > make[3]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
>> > make -C mce-test install
>> > make[4]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
>> > make[4]: *** No rule to make target `install'.  Stop.
>> >
>> > Grep seems to suggest that most of the tools/tests dirs are missing an
>> > install target, mce-test just happens to be first.
>> >
>> > I'm not sure if it makes sense to install any of these test things?
>> > Depending on the answer we could either hobble the install target in
>> > tools/tests/Makefile or add an install target to
>> tools/tests/*/Makefile
>> > which is a nop or an actual install target as appropriate.
>>
>> Vote is to hobble install target. Refresh of patch pasted below (also
>> added distclean).
>> Thanks!
>> Andres
>>
>> # HG changeset patch
>> # Parent efc0802acb87aec9a4d578e741e209bef8c6fe52
>> Tools: build tests
>>
>> Build tests as part of the tools build.
>>
>> It is enabled with CONFIG_TESTS in Config.mk
>>
>> Currently disabled build of tests/regressions and tests/xen-access (in
>> 32
>> bit mode) as they fail.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Bump? Ping?
Thanks,
Andres

>
>>
>> diff -r efc0802acb87 Config.mk
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -238,6 +238,7 @@ OCAML_TOOLS        ?= y
>>  CONFIG_MINITERM    ?= n
>>  CONFIG_LOMOUNT     ?= n
>>  CONFIG_SYSTEM_LIBAIO ?= y
>> +CONFIG_TESTS       ?= y
>>
>>  ifeq ($(OCAML_TOOLS),y)
>>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo
>> "n")
>> diff -r efc0802acb87 tools/Makefile
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -45,6 +45,7 @@ SUBDIRS-y += remus
>>  SUBDIRS-$(CONFIG_X86) += xenpaging
>>  SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
>>  SUBDIRS-$(CONFIG_X86) += debugger/kdd
>> +SUBDIRS-$(CONFIG_TESTS) += tests
>>
>>  # These don't cross-compile
>>  ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
>> diff -r efc0802acb87 tools/tests/Makefile
>> --- /dev/null
>> +++ b/tools/tests/Makefile
>> @@ -0,0 +1,21 @@
>> +XEN_ROOT = $(CURDIR)/../..
>> +include $(XEN_ROOT)/tools/Rules.mk
>> +
>> +CFLAGS  += $(CFLAGS_libxenctrl)
>> +LDLIBS += $(LDLIBS_libxenctrl)
>> +
>> +SUBDIRS-y :=
>> +SUBDIRS-y += mce-test
>> +SUBDIRS-y += mem-sharing
>> +ifeq ($(XEN_TARGET_ARCH),__fixme__)
>> +SUBDIRS-y += regression
>> +endif
>> +SUBDIRS-y += x86_emulator
>> +ifneq ($(XEN_TARGET_ARCH),x86_32)
>> +SUBDIRS-y += xen-access
>> +endif
>> +
>> +.PHONY: all clean install distclean
>> +all clean distclean: %: subdirs-%
>> +
>> +install:
>>
>>
>>
>> >
>> > Ian.
>> >
>> >
>> >
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 15:56:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 15: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.xensource.com>)
	id 1RuQv4-0004fG-9k; Mon, 06 Feb 2012 15:55:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RuQv3-0004f9-6Z
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:55:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328543744!13922267!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5ODAw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5ODAw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14919 invoked from network); 6 Feb 2012 15:55:45 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-182.messagelabs.com with SMTP;
	6 Feb 2012 15:55:45 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id D6C014B007C;
	Mon,  6 Feb 2012 07:55:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YO9pSH5yj95NjcMmsrNB6gdJhXYmUdKB9olzjXsu1cw7
	nLYIaHQj7SyPgl/kUsX01dDnQ2O1/ki7U2dAKh0/sZ2by+zLe7LzNTCZ5Y4OK3Q+
	HRTNM4pPdGBgIDTk7KEhuZ8lK6BVVRFiQpkg7IuWJJ0c6KetY3IE6lLVNd5IKZo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=tsVd9UjzXT4kVBK982IWXF+8+6A=; b=fYM0tpgi
	m8E+zBcbecyAJ4NCsC6eYzspjh85Ak/BkKaW5XvorSIRYjAv3ONG6W11JJPfUzSY
	YZEuFYmZa1ey0O1x2pgeeHcXJHNIMOFGwKbOwuF+BG67vYyDSeSNcPWdRAqSkvwI
	+ZioIxRTemfBpuZ+cHtFEL8ObhNUrnLPVRM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 077DB4B006D; 
	Mon,  6 Feb 2012 07:55:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 6 Feb 2012 07:55:43 -0800
Message-ID: <1389361a301b9952337ecd82e841e46e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1328112859.17444.94.camel@zakaz.uk.xensource.com>
References: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
	<1328089685.17444.15.camel@zakaz.uk.xensource.com>
	<8f12808d225caa899ed5bca14916f2ad.squirrel@webmail.lagarcavilla.org>
	<1328112859.17444.94.camel@zakaz.uk.xensource.com>
Date: Mon, 6 Feb 2012 07:55:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, 2012-02-01 at 15:58 +0000, Andres Lagar-Cavilla wrote:
>> > On Fri, 2012-01-27 at 21:21 +0000, Andres Lagar-Cavilla wrote:
>> >> Config.mk            |   1 +
>> >>  tools/Makefile       |   1 +
>> >>  tools/tests/Makefile |  20 ++++++++++++++++++++
>> >>  3 files changed, 22 insertions(+), 0 deletions(-)
>> >>
>> >>
>> >> Build tests as part of the tools build.
>> >>
>> >> It is enabled with CONFIG_TESTS in Config.mk
>> >>
>> >> Currently disabled build of tests/regressions and tests/xen-access
>> (in
>> >> 32 bit
>> >> mode) as they fail.
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> >
>> > Ack on the idea but the actual implementation fails for me:
>> >
>> > make[1]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools'
>> > make -C tests install
>> > make[2]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
>> > make[3]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests'
>> > make -C mce-test install
>> > make[4]: Entering directory
>> > `/local/scratch/ianc/devel/xen-unstable.hg/tools/tests/mce-test'
>> > make[4]: *** No rule to make target `install'.  Stop.
>> >
>> > Grep seems to suggest that most of the tools/tests dirs are missing an
>> > install target, mce-test just happens to be first.
>> >
>> > I'm not sure if it makes sense to install any of these test things?
>> > Depending on the answer we could either hobble the install target in
>> > tools/tests/Makefile or add an install target to
>> tools/tests/*/Makefile
>> > which is a nop or an actual install target as appropriate.
>>
>> Vote is to hobble install target. Refresh of patch pasted below (also
>> added distclean).
>> Thanks!
>> Andres
>>
>> # HG changeset patch
>> # Parent efc0802acb87aec9a4d578e741e209bef8c6fe52
>> Tools: build tests
>>
>> Build tests as part of the tools build.
>>
>> It is enabled with CONFIG_TESTS in Config.mk
>>
>> Currently disabled build of tests/regressions and tests/xen-access (in
>> 32
>> bit mode) as they fail.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Bump? Ping?
Thanks,
Andres

>
>>
>> diff -r efc0802acb87 Config.mk
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -238,6 +238,7 @@ OCAML_TOOLS        ?= y
>>  CONFIG_MINITERM    ?= n
>>  CONFIG_LOMOUNT     ?= n
>>  CONFIG_SYSTEM_LIBAIO ?= y
>> +CONFIG_TESTS       ?= y
>>
>>  ifeq ($(OCAML_TOOLS),y)
>>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo
>> "n")
>> diff -r efc0802acb87 tools/Makefile
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -45,6 +45,7 @@ SUBDIRS-y += remus
>>  SUBDIRS-$(CONFIG_X86) += xenpaging
>>  SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
>>  SUBDIRS-$(CONFIG_X86) += debugger/kdd
>> +SUBDIRS-$(CONFIG_TESTS) += tests
>>
>>  # These don't cross-compile
>>  ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
>> diff -r efc0802acb87 tools/tests/Makefile
>> --- /dev/null
>> +++ b/tools/tests/Makefile
>> @@ -0,0 +1,21 @@
>> +XEN_ROOT = $(CURDIR)/../..
>> +include $(XEN_ROOT)/tools/Rules.mk
>> +
>> +CFLAGS  += $(CFLAGS_libxenctrl)
>> +LDLIBS += $(LDLIBS_libxenctrl)
>> +
>> +SUBDIRS-y :=
>> +SUBDIRS-y += mce-test
>> +SUBDIRS-y += mem-sharing
>> +ifeq ($(XEN_TARGET_ARCH),__fixme__)
>> +SUBDIRS-y += regression
>> +endif
>> +SUBDIRS-y += x86_emulator
>> +ifneq ($(XEN_TARGET_ARCH),x86_32)
>> +SUBDIRS-y += xen-access
>> +endif
>> +
>> +.PHONY: all clean install distclean
>> +all clean distclean: %: subdirs-%
>> +
>> +install:
>>
>>
>>
>> >
>> > Ian.
>> >
>> >
>> >
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:30:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRRw-0005yi-IF; Mon, 06 Feb 2012 16:29:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRRv-0005yd-O4
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:29:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328545784!10192851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29435 invoked from network); 6 Feb 2012 16:29:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:29:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:31:52 +0000
Message-Id: <4F300E050200007800071664@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:29:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part123C7FE5.1__="
Cc: Jun Nakajima <jun.nakajima@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
 specific MSR handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part123C7FE5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is model 0x3a (decimal 58) as per the most recent SDM.

In vPMU code, also add a forgotten earlier model.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -106,6 +106,8 @@ static void do_get_hw_residencies(void *
=20
     switch ( c->x86_model )
     {
+    /* Ivy bridge */
+    case 0x3A:
     /* Sandy bridge */
     case 0x2A:
     case 0x2D:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1751,6 +1751,8 @@ static const struct lbr_info *last_branc
         case 37: case 44: case 47:
         /* Sandy Bridge */
         case 42: case 45:
+        /* Ivy Bridge */
+        case 58:
             return nh_lbr;
             break;
         /* Atom */
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
         case 26:
         case 29:
         case 42:
+        case 45:
         case 46:
         case 47:
+        case 58:
             vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;
             return 0;
         }




--=__Part123C7FE5.1__=
Content-Type: text/plain; name="IvyBridge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="IvyBridge.patch"

x86: add Ivy Bridge model numbers to model specific MSR handling=0A=0AThis =
is model 0x3a (decimal 58) as per the most recent SDM.=0A=0AIn vPMU code, =
also add a forgotten earlier model.=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@@ -106,6 +106,8 @@ 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--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch=
/x86/hvm/vmx/vmx.c=0A@@ -1751,6 +1751,8 @@ static const struct lbr_info =
*last_branc=0A         case 37: case 44: case 47:=0A         /* Sandy =
Bridge */=0A         case 42: case 45:=0A+        /* Ivy Bridge */=0A+     =
   case 58:=0A             return nh_lbr;=0A             break;=0A         =
/* Atom */=0A--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A+++ b/xen/arch/x86/h=
vm/vmx/vpmu_core2.c=0A@@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct =
vcpu *v)=0A         case 26:=0A         case 29:=0A         case 42:=0A+   =
     case 45:=0A         case 46:=0A         case 47:=0A+        case =
58:=0A             vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;=0A             =
return 0;=0A         }=0A
--=__Part123C7FE5.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part123C7FE5.1__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:30:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:30:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRRw-0005yi-IF; Mon, 06 Feb 2012 16:29:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRRv-0005yd-O4
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:29:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328545784!10192851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29435 invoked from network); 6 Feb 2012 16:29:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:29:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:31:52 +0000
Message-Id: <4F300E050200007800071664@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:29:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part123C7FE5.1__="
Cc: Jun Nakajima <jun.nakajima@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>
Subject: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
 specific MSR handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part123C7FE5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is model 0x3a (decimal 58) as per the most recent SDM.

In vPMU code, also add a forgotten earlier model.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -106,6 +106,8 @@ static void do_get_hw_residencies(void *
=20
     switch ( c->x86_model )
     {
+    /* Ivy bridge */
+    case 0x3A:
     /* Sandy bridge */
     case 0x2A:
     case 0x2D:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1751,6 +1751,8 @@ static const struct lbr_info *last_branc
         case 37: case 44: case 47:
         /* Sandy Bridge */
         case 42: case 45:
+        /* Ivy Bridge */
+        case 58:
             return nh_lbr;
             break;
         /* Atom */
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
         case 26:
         case 29:
         case 42:
+        case 45:
         case 46:
         case 47:
+        case 58:
             vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;
             return 0;
         }




--=__Part123C7FE5.1__=
Content-Type: text/plain; name="IvyBridge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="IvyBridge.patch"

x86: add Ivy Bridge model numbers to model specific MSR handling=0A=0AThis =
is model 0x3a (decimal 58) as per the most recent SDM.=0A=0AIn vPMU code, =
also add a forgotten earlier model.=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@@ -106,6 +106,8 @@ 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--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch=
/x86/hvm/vmx/vmx.c=0A@@ -1751,6 +1751,8 @@ static const struct lbr_info =
*last_branc=0A         case 37: case 44: case 47:=0A         /* Sandy =
Bridge */=0A         case 42: case 45:=0A+        /* Ivy Bridge */=0A+     =
   case 58:=0A             return nh_lbr;=0A             break;=0A         =
/* Atom */=0A--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A+++ b/xen/arch/x86/h=
vm/vmx/vpmu_core2.c=0A@@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct =
vcpu *v)=0A         case 26:=0A         case 29:=0A         case 42:=0A+   =
     case 45:=0A         case 46:=0A         case 47:=0A+        case =
58:=0A             vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;=0A             =
return 0;=0A         }=0A
--=__Part123C7FE5.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part123C7FE5.1__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:31:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRTI-00061j-2L; Mon, 06 Feb 2012 16:31:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRTG-00061T-IM
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:31:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328545867!3794793!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 6 Feb 2012 16:31:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:31:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:33:15 +0000
Message-Id: <4F300E580200007800071668@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:31:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4F613D58.0__="
Subject: [Xen-devel] [PATCH] ia64: fix build (next instance)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4F613D58.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

A number of build problems crept in once again. Fix them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -683,7 +683,7 @@ long do_memory_op(unsigned long cmd, XEN
         mfn =3D get_gfn_untyped(d, xrfp.gpfn);
=20
         if ( mfn_valid(mfn) )
-            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
         else
             rc =3D -ENOENT;
=20
--- a/xen/include/asm-ia64/linux-xen/asm/irq.h
+++ b/xen/include/asm-ia64/linux-xen/asm/irq.h
@@ -72,7 +72,7 @@ extern int request_irq_vector(unsigned i
 #define irq_complete_move(x) do {} \
     while(!x)
=20
-#define domain_pirq_to_irq(d, irq) domain_irq_to_vector(d, irq)
+#define domain_pirq_to_irq(d, irq) (irq) /* domain_irq_to_vector(d, irq) =
*/
=20
 #define hvm_domain_use_pirq(d, info) 0
 #endif
--- a/xen/include/asm-ia64/linux-xen/asm/processor.h
+++ b/xen/include/asm-ia64/linux-xen/asm/processor.h
@@ -17,7 +17,12 @@
=20
 #include <asm/intrinsics.h>
 #include <asm/kregs.h>
+#if !defined(XEN)
 #include <asm/ptrace.h>
+#elif !defined(__ASSEMBLY__)
+struct cpu_user_regs;
+#define pt_regs cpu_user_regs
+#endif
 #include <asm/ustack.h>
=20
 /* Our arch specific arch_init_sched_domain is in arch/ia64/kernel/domain.=
c */
@@ -783,4 +788,8 @@ ia64_get_cpl(unsigned long psr)
=20
 #endif /* !__ASSEMBLY__ */
=20
+#ifdef XEN
+#include <asm/ptrace.h>
+#endif
+
 #endif /* _ASM_IA64_PROCESSOR_H */
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,7 +8,6 @@
 #define __XEN_LIST_H__
=20
 #include <xen/lib.h>
-#include <xen/prefetch.h>
 #include <asm/system.h>
=20
 /* These are non-NULL pointers that will result in page faults
@@ -40,6 +39,9 @@ struct list_head {
 #define LIST_HEAD_READ_MOSTLY(name) \
     struct list_head __read_mostly name =3D LIST_HEAD_INIT(name)
=20
+/* Do not move this ahead of the struct list_head definition! */
+#include <xen/prefetch.h>
+
 static inline void INIT_LIST_HEAD(struct list_head *list)
 {
     list->next =3D list;
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -106,6 +106,7 @@ struct xsm_operations {
     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 *d, struct page_info *page);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
=20
     int (*console_io) (struct domain *d, int cmd);
=20
@@ -174,7 +175,6 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f,=20
                                                             l1_pgentry_t =
pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
-    int (*remove_from_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);
@@ -460,6 +460,11 @@ static inline int xsm_memory_pin_page(st
     return xsm_call(memory_pin_page(d, page));
 }
=20
+static inline int xsm_remove_from_physmap(struct domain *d1, struct =
domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
     return xsm_call(console_io(d, cmd));
@@ -764,11 +769,6 @@ static inline int xsm_add_to_physmap(str
     return xsm_call(add_to_physmap(d1, d2));
 }
=20
-static inline int xsm_remove_from_physmap(struct domain *d1, struct =
domain *d2)
-{
-    return xsm_call(remove_from_physmap(d1, d2));
-}
-
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));




--=__Part4F613D58.0__=
Content-Type: text/plain; name="ia64-build.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-build.patch"

ia64: fix build (next instance)=0A=0AA number of build problems crept in =
once again. Fix them.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -683,7 =
+683,7 @@ long do_memory_op(unsigned long cmd, XEN=0A         mfn =3D =
get_gfn_untyped(d, xrfp.gpfn);=0A =0A         if ( mfn_valid(mfn) )=0A-    =
        guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);=0A+   =
         guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);=0A         =
else=0A             rc =3D -ENOENT;=0A =0A--- a/xen/include/asm-ia64/linux-=
xen/asm/irq.h=0A+++ b/xen/include/asm-ia64/linux-xen/asm/irq.h=0A@@ -72,7 =
+72,7 @@ extern int request_irq_vector(unsigned i=0A #define irq_complete_m=
ove(x) do {} \=0A     while(!x)=0A =0A-#define domain_pirq_to_irq(d, irq) =
domain_irq_to_vector(d, irq)=0A+#define domain_pirq_to_irq(d, irq) (irq) =
/* domain_irq_to_vector(d, irq) */=0A =0A #define hvm_domain_use_pirq(d, =
info) 0=0A #endif=0A--- a/xen/include/asm-ia64/linux-xen/asm/processor.h=0A=
+++ b/xen/include/asm-ia64/linux-xen/asm/processor.h=0A@@ -17,7 +17,12 =
@@=0A =0A #include <asm/intrinsics.h>=0A #include <asm/kregs.h>=0A+#if =
!defined(XEN)=0A #include <asm/ptrace.h>=0A+#elif !defined(__ASSEMBLY__)=0A=
+struct cpu_user_regs;=0A+#define pt_regs cpu_user_regs=0A+#endif=0A =
#include <asm/ustack.h>=0A =0A /* Our arch specific arch_init_sched_domain =
is in arch/ia64/kernel/domain.c */=0A@@ -783,4 +788,8 @@ ia64_get_cpl(unsig=
ned long psr)=0A =0A #endif /* !__ASSEMBLY__ */=0A =0A+#ifdef XEN=0A+#inclu=
de <asm/ptrace.h>=0A+#endif=0A+=0A #endif /* _ASM_IA64_PROCESSOR_H =
*/=0A--- a/xen/include/xen/list.h=0A+++ b/xen/include/xen/list.h=0A@@ -8,7 =
+8,6 @@=0A #define __XEN_LIST_H__=0A =0A #include <xen/lib.h>=0A-#include =
<xen/prefetch.h>=0A #include <asm/system.h>=0A =0A /* These are non-NULL =
pointers that will result in page faults=0A@@ -40,6 +39,9 @@ struct =
list_head {=0A #define LIST_HEAD_READ_MOSTLY(name) \=0A     struct =
list_head __read_mostly name =3D LIST_HEAD_INIT(name)=0A =0A+/* Do not =
move this ahead of the struct list_head definition! */=0A+#include =
<xen/prefetch.h>=0A+=0A static inline void INIT_LIST_HEAD(struct list_head =
*list)=0A {=0A     list->next =3D list;=0A--- a/xen/include/xsm/xsm.h=0A+++=
 b/xen/include/xsm/xsm.h=0A@@ -106,6 +106,7 @@ struct xsm_operations {=0A  =
   int (*memory_adjust_reservation) (struct domain *d1, struct domain =
*d2);=0A     int (*memory_stat_reservation) (struct domain *d1, struct =
domain *d2);=0A     int (*memory_pin_page) (struct domain *d, struct =
page_info *page);=0A+    int (*remove_from_physmap) (struct domain *d1, =
struct domain *d2);=0A =0A     int (*console_io) (struct domain *d, int =
cmd);=0A =0A@@ -174,7 +175,6 @@ struct xsm_operations {=0A     int =
(*update_va_mapping) (struct domain *d, struct domain *f, =0A              =
                                               l1_pgentry_t pte);=0A     =
int (*add_to_physmap) (struct domain *d1, struct domain *d2);=0A-    int =
(*remove_from_physmap) (struct domain *d1, struct domain *d2);=0A     int =
(*sendtrigger) (struct domain *d);=0A     int (*bind_pt_irq) (struct =
domain *d, struct xen_domctl_bind_pt_irq *bind);=0A     int (*unbind_pt_irq=
) (struct domain *d);=0A@@ -460,6 +460,11 @@ static inline int xsm_memory_p=
in_page(st=0A     return xsm_call(memory_pin_page(d, page));=0A }=0A =
=0A+static inline int xsm_remove_from_physmap(struct domain *d1, struct =
domain *d2)=0A+{=0A+    return xsm_call(remove_from_physmap(d1, d2));=0A+}=
=0A+=0A static inline int xsm_console_io (struct domain *d, int cmd)=0A =
{=0A     return xsm_call(console_io(d, cmd));=0A@@ -764,11 +769,6 @@ =
static inline int xsm_add_to_physmap(str=0A     return xsm_call(add_to_phys=
map(d1, d2));=0A }=0A =0A-static inline int xsm_remove_from_physmap(struct =
domain *d1, struct domain *d2)=0A-{=0A-    return xsm_call(remove_from_phys=
map(d1, d2));=0A-}=0A-=0A static inline int xsm_sendtrigger(struct domain =
*d)=0A {=0A     return xsm_call(sendtrigger(d));=0A
--=__Part4F613D58.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part4F613D58.0__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:31:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRTI-00061j-2L; Mon, 06 Feb 2012 16:31:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRTG-00061T-IM
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:31:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328545867!3794793!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 6 Feb 2012 16:31:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:31:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:33:15 +0000
Message-Id: <4F300E580200007800071668@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:31:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4F613D58.0__="
Subject: [Xen-devel] [PATCH] ia64: fix build (next instance)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part4F613D58.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

A number of build problems crept in once again. Fix them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -683,7 +683,7 @@ long do_memory_op(unsigned long cmd, XEN
         mfn =3D get_gfn_untyped(d, xrfp.gpfn);
=20
         if ( mfn_valid(mfn) )
-            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
         else
             rc =3D -ENOENT;
=20
--- a/xen/include/asm-ia64/linux-xen/asm/irq.h
+++ b/xen/include/asm-ia64/linux-xen/asm/irq.h
@@ -72,7 +72,7 @@ extern int request_irq_vector(unsigned i
 #define irq_complete_move(x) do {} \
     while(!x)
=20
-#define domain_pirq_to_irq(d, irq) domain_irq_to_vector(d, irq)
+#define domain_pirq_to_irq(d, irq) (irq) /* domain_irq_to_vector(d, irq) =
*/
=20
 #define hvm_domain_use_pirq(d, info) 0
 #endif
--- a/xen/include/asm-ia64/linux-xen/asm/processor.h
+++ b/xen/include/asm-ia64/linux-xen/asm/processor.h
@@ -17,7 +17,12 @@
=20
 #include <asm/intrinsics.h>
 #include <asm/kregs.h>
+#if !defined(XEN)
 #include <asm/ptrace.h>
+#elif !defined(__ASSEMBLY__)
+struct cpu_user_regs;
+#define pt_regs cpu_user_regs
+#endif
 #include <asm/ustack.h>
=20
 /* Our arch specific arch_init_sched_domain is in arch/ia64/kernel/domain.=
c */
@@ -783,4 +788,8 @@ ia64_get_cpl(unsigned long psr)
=20
 #endif /* !__ASSEMBLY__ */
=20
+#ifdef XEN
+#include <asm/ptrace.h>
+#endif
+
 #endif /* _ASM_IA64_PROCESSOR_H */
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -8,7 +8,6 @@
 #define __XEN_LIST_H__
=20
 #include <xen/lib.h>
-#include <xen/prefetch.h>
 #include <asm/system.h>
=20
 /* These are non-NULL pointers that will result in page faults
@@ -40,6 +39,9 @@ struct list_head {
 #define LIST_HEAD_READ_MOSTLY(name) \
     struct list_head __read_mostly name =3D LIST_HEAD_INIT(name)
=20
+/* Do not move this ahead of the struct list_head definition! */
+#include <xen/prefetch.h>
+
 static inline void INIT_LIST_HEAD(struct list_head *list)
 {
     list->next =3D list;
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -106,6 +106,7 @@ struct xsm_operations {
     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 *d, struct page_info *page);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
=20
     int (*console_io) (struct domain *d, int cmd);
=20
@@ -174,7 +175,6 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f,=20
                                                             l1_pgentry_t =
pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
-    int (*remove_from_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);
@@ -460,6 +460,11 @@ static inline int xsm_memory_pin_page(st
     return xsm_call(memory_pin_page(d, page));
 }
=20
+static inline int xsm_remove_from_physmap(struct domain *d1, struct =
domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
     return xsm_call(console_io(d, cmd));
@@ -764,11 +769,6 @@ static inline int xsm_add_to_physmap(str
     return xsm_call(add_to_physmap(d1, d2));
 }
=20
-static inline int xsm_remove_from_physmap(struct domain *d1, struct =
domain *d2)
-{
-    return xsm_call(remove_from_physmap(d1, d2));
-}
-
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));




--=__Part4F613D58.0__=
Content-Type: text/plain; name="ia64-build.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-build.patch"

ia64: fix build (next instance)=0A=0AA number of build problems crept in =
once again. Fix them.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -683,7 =
+683,7 @@ long do_memory_op(unsigned long cmd, XEN=0A         mfn =3D =
get_gfn_untyped(d, xrfp.gpfn);=0A =0A         if ( mfn_valid(mfn) )=0A-    =
        guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);=0A+   =
         guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);=0A         =
else=0A             rc =3D -ENOENT;=0A =0A--- a/xen/include/asm-ia64/linux-=
xen/asm/irq.h=0A+++ b/xen/include/asm-ia64/linux-xen/asm/irq.h=0A@@ -72,7 =
+72,7 @@ extern int request_irq_vector(unsigned i=0A #define irq_complete_m=
ove(x) do {} \=0A     while(!x)=0A =0A-#define domain_pirq_to_irq(d, irq) =
domain_irq_to_vector(d, irq)=0A+#define domain_pirq_to_irq(d, irq) (irq) =
/* domain_irq_to_vector(d, irq) */=0A =0A #define hvm_domain_use_pirq(d, =
info) 0=0A #endif=0A--- a/xen/include/asm-ia64/linux-xen/asm/processor.h=0A=
+++ b/xen/include/asm-ia64/linux-xen/asm/processor.h=0A@@ -17,7 +17,12 =
@@=0A =0A #include <asm/intrinsics.h>=0A #include <asm/kregs.h>=0A+#if =
!defined(XEN)=0A #include <asm/ptrace.h>=0A+#elif !defined(__ASSEMBLY__)=0A=
+struct cpu_user_regs;=0A+#define pt_regs cpu_user_regs=0A+#endif=0A =
#include <asm/ustack.h>=0A =0A /* Our arch specific arch_init_sched_domain =
is in arch/ia64/kernel/domain.c */=0A@@ -783,4 +788,8 @@ ia64_get_cpl(unsig=
ned long psr)=0A =0A #endif /* !__ASSEMBLY__ */=0A =0A+#ifdef XEN=0A+#inclu=
de <asm/ptrace.h>=0A+#endif=0A+=0A #endif /* _ASM_IA64_PROCESSOR_H =
*/=0A--- a/xen/include/xen/list.h=0A+++ b/xen/include/xen/list.h=0A@@ -8,7 =
+8,6 @@=0A #define __XEN_LIST_H__=0A =0A #include <xen/lib.h>=0A-#include =
<xen/prefetch.h>=0A #include <asm/system.h>=0A =0A /* These are non-NULL =
pointers that will result in page faults=0A@@ -40,6 +39,9 @@ struct =
list_head {=0A #define LIST_HEAD_READ_MOSTLY(name) \=0A     struct =
list_head __read_mostly name =3D LIST_HEAD_INIT(name)=0A =0A+/* Do not =
move this ahead of the struct list_head definition! */=0A+#include =
<xen/prefetch.h>=0A+=0A static inline void INIT_LIST_HEAD(struct list_head =
*list)=0A {=0A     list->next =3D list;=0A--- a/xen/include/xsm/xsm.h=0A+++=
 b/xen/include/xsm/xsm.h=0A@@ -106,6 +106,7 @@ struct xsm_operations {=0A  =
   int (*memory_adjust_reservation) (struct domain *d1, struct domain =
*d2);=0A     int (*memory_stat_reservation) (struct domain *d1, struct =
domain *d2);=0A     int (*memory_pin_page) (struct domain *d, struct =
page_info *page);=0A+    int (*remove_from_physmap) (struct domain *d1, =
struct domain *d2);=0A =0A     int (*console_io) (struct domain *d, int =
cmd);=0A =0A@@ -174,7 +175,6 @@ struct xsm_operations {=0A     int =
(*update_va_mapping) (struct domain *d, struct domain *f, =0A              =
                                               l1_pgentry_t pte);=0A     =
int (*add_to_physmap) (struct domain *d1, struct domain *d2);=0A-    int =
(*remove_from_physmap) (struct domain *d1, struct domain *d2);=0A     int =
(*sendtrigger) (struct domain *d);=0A     int (*bind_pt_irq) (struct =
domain *d, struct xen_domctl_bind_pt_irq *bind);=0A     int (*unbind_pt_irq=
) (struct domain *d);=0A@@ -460,6 +460,11 @@ static inline int xsm_memory_p=
in_page(st=0A     return xsm_call(memory_pin_page(d, page));=0A }=0A =
=0A+static inline int xsm_remove_from_physmap(struct domain *d1, struct =
domain *d2)=0A+{=0A+    return xsm_call(remove_from_physmap(d1, d2));=0A+}=
=0A+=0A static inline int xsm_console_io (struct domain *d, int cmd)=0A =
{=0A     return xsm_call(console_io(d, cmd));=0A@@ -764,11 +769,6 @@ =
static inline int xsm_add_to_physmap(str=0A     return xsm_call(add_to_phys=
map(d1, d2));=0A }=0A =0A-static inline int xsm_remove_from_physmap(struct =
domain *d1, struct domain *d2)=0A-{=0A-    return xsm_call(remove_from_phys=
map(d1, d2));=0A-}=0A-=0A static inline int xsm_sendtrigger(struct domain =
*d)=0A {=0A     return xsm_call(sendtrigger(d));=0A
--=__Part4F613D58.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part4F613D58.0__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 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.xensource.com>)
	id 1RuRXN-0006Em-U0; Mon, 06 Feb 2012 16:35:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRXM-0006EP-LD
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:35:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328546120!10277274!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1484 invoked from network); 6 Feb 2012 16:35:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:35:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:37:28 +0000
Message-Id: <4F300F55020000780007167D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:35:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part436D3155.0__="
Subject: [Xen-devel] [PATCH] x86/paging: use clear_guest() for zero-filling
 guest buffers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part436D3155.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While static arrays of all zeros may be tolerable (but are simply
inefficient now that we have the necessary infrastructure), using on-
stack arrays for this purpose (particularly when their size doesn't
have an upper limit enforced) is calling for eventual problems (even
if the code can be reached via administrative interfaces only).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -21,11 +21,11 @@
  */
=20
 #include <xen/init.h>
+#include <xen/guest_access.h>
 #include <asm/paging.h>
 #include <asm/shadow.h>
 #include <asm/p2m.h>
 #include <asm/hap.h>
-#include <asm/guest_access.h>
 #include <asm/hvm/nestedhvm.h>
 #include <xen/numa.h>
 #include <xsm/xsm.h>
@@ -383,26 +383,30 @@ int paging_log_dirty_op(struct domain *d
                   (pages < sc->pages) && (i2 < LOGDIRTY_NODE_ENTRIES);
                   i2++ )
             {
-                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
                 unsigned int bytes =3D PAGE_SIZE;
                 l1 =3D ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : zeroes);
+                      map_domain_page(mfn_x(l2[i2])) : NULL);
                 if ( unlikely(((sc->pages - pages + 7) >> 3) < bytes) )
                     bytes =3D (unsigned int)((sc->pages - pages + 7) >> =
3);
                 if ( likely(peek) )
                 {
-                    if ( copy_to_guest_offset(sc->dirty_bitmap, pages >> =
3,
-                                              (uint8_t *)l1, bytes) !=3D =
0 )
+                    if ( (l1 ? copy_to_guest_offset(sc->dirty_bitmap,
+                                                    pages >> 3, (uint8_t =
*)l1,
+                                                    bytes)
+                             : clear_guest_offset(sc->dirty_bitmap,
+                                                  pages >> 3, bytes)) =
!=3D 0 )
                     {
                         rv =3D -EFAULT;
                         goto out;
                     }
                 }
-                if ( clean && l1 !=3D zeroes )
-                    clear_page(l1);
                 pages +=3D bytes << 3;
-                if ( l1 !=3D zeroes )
+                if ( l1 )
+                {
+                    if ( clean )
+                        clear_page(l1);
                     unmap_domain_page(l1);
+                }
             }
             if ( l2 )
                 unmap_domain_page(l2);
@@ -462,12 +466,9 @@ int paging_log_dirty_range(struct domain
=20
     if ( !d->arch.paging.log_dirty.fault_count &&
          !d->arch.paging.log_dirty.dirty_count ) {
-        int size =3D (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
-        unsigned long zeroes[size];
-        memset(zeroes, 0x00, size * BYTES_PER_LONG);
-        rv =3D 0;
-        if ( copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,
-                                  size * BYTES_PER_LONG) !=3D 0 )
+        unsigned int size =3D BITS_TO_LONGS(nr);
+
+        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) !=3D 0 )
             rv =3D -EFAULT;
         goto out;
     }
@@ -495,11 +496,10 @@ int paging_log_dirty_range(struct domain
                   (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
                   i2++ )
             {
-                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
                 unsigned int bytes =3D PAGE_SIZE;
                 uint8_t *s;
                 l1 =3D ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : zeroes);
+                      map_domain_page(mfn_x(l2[i2])) : NULL);
=20
                 s =3D ((uint8_t*)l1) + (b1 >> 3);
                 bytes -=3D b1 >> 3;
@@ -507,9 +507,18 @@ int paging_log_dirty_range(struct domain
                 if ( likely(((nr - pages + 7) >> 3) < bytes) )
                     bytes =3D (unsigned int)((nr - pages + 7) >> 3);
=20
+                if ( !l1 )
+                {
+                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
+                                            bytes) !=3D 0 )
+                    {
+                        rv =3D -EFAULT;
+                        goto out;
+                    }
+                }
                 /* begin_pfn is not 32K aligned, hence we have to bit
                  * shift the bitmap */
-                if ( b1 & 0x7 )
+                else if ( b1 & 0x7 )
                 {
                     int i, j;
                     uint32_t *l =3D (uint32_t*) s;
@@ -553,11 +562,12 @@ int paging_log_dirty_range(struct domain
                     }
                 }
=20
-                if ( l1 !=3D zeroes )
-                    clear_page(l1);
                 pages +=3D bytes << 3;
-                if ( l1 !=3D zeroes )
+                if ( l1 )
+                {
+                    clear_page(l1);
                     unmap_domain_page(l1);
+                }
                 b1 =3D b1 & 0x7;
             }
             b2 =3D 0;



--=__Part436D3155.0__=
Content-Type: text/plain; name="x86-paging-use-clear_guest.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-paging-use-clear_guest.patch"

x86/paging: use clear_guest() for zero-filling guest buffers=0A=0AWhile =
static arrays of all zeros may be tolerable (but are simply=0Ainefficient =
now that we have the necessary infrastructure), using on-=0Astack arrays =
for this purpose (particularly when their size doesn't=0Ahave an upper =
limit enforced) is calling for eventual problems (even=0Aif the code can =
be reached via administrative interfaces only).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mm/paging.c=0A+++ =
b/xen/arch/x86/mm/paging.c=0A@@ -21,11 +21,11 @@=0A  */=0A =0A #include =
<xen/init.h>=0A+#include <xen/guest_access.h>=0A #include <asm/paging.h>=0A=
 #include <asm/shadow.h>=0A #include <asm/p2m.h>=0A #include <asm/hap.h>=0A=
-#include <asm/guest_access.h>=0A #include <asm/hvm/nestedhvm.h>=0A =
#include <xen/numa.h>=0A #include <xsm/xsm.h>=0A@@ -383,26 +383,30 @@ int =
paging_log_dirty_op(struct domain *d=0A                   (pages < =
sc->pages) && (i2 < LOGDIRTY_NODE_ENTRIES);=0A                   i2++ )=0A =
            {=0A-                static unsigned long zeroes[PAGE_SIZE/BYTE=
S_PER_LONG];=0A                 unsigned int bytes =3D PAGE_SIZE;=0A       =
          l1 =3D ((l2 && mfn_valid(l2[i2])) ?=0A-                      =
map_domain_page(mfn_x(l2[i2])) : zeroes);=0A+                      =
map_domain_page(mfn_x(l2[i2])) : NULL);=0A                 if ( unlikely(((=
sc->pages - pages + 7) >> 3) < bytes) )=0A                     bytes =3D =
(unsigned int)((sc->pages - pages + 7) >> 3);=0A                 if ( =
likely(peek) )=0A                 {=0A-                    if ( copy_to_gue=
st_offset(sc->dirty_bitmap, pages >> 3,=0A-                                =
              (uint8_t *)l1, bytes) !=3D 0 )=0A+                    if ( =
(l1 ? copy_to_guest_offset(sc->dirty_bitmap,=0A+                           =
                         pages >> 3, (uint8_t *)l1,=0A+                    =
                                bytes)=0A+                             : =
clear_guest_offset(sc->dirty_bitmap,=0A+                                   =
               pages >> 3, bytes)) !=3D 0 )=0A                     {=0A    =
                     rv =3D -EFAULT;=0A                         goto =
out;=0A                     }=0A                 }=0A-                if ( =
clean && l1 !=3D zeroes )=0A-                    clear_page(l1);=0A        =
         pages +=3D bytes << 3;=0A-                if ( l1 !=3D zeroes =
)=0A+                if ( l1 )=0A+                {=0A+                    =
if ( clean )=0A+                        clear_page(l1);=0A                 =
    unmap_domain_page(l1);=0A+                }=0A             }=0A        =
     if ( l2 )=0A                 unmap_domain_page(l2);=0A@@ -462,12 =
+466,9 @@ int paging_log_dirty_range(struct domain=0A =0A     if ( =
!d->arch.paging.log_dirty.fault_count &&=0A          !d->arch.paging.log_di=
rty.dirty_count ) {=0A-        int size =3D (nr + BITS_PER_LONG - 1) / =
BITS_PER_LONG;=0A-        unsigned long zeroes[size];=0A-        memset(zer=
oes, 0x00, size * BYTES_PER_LONG);=0A-        rv =3D 0;=0A-        if ( =
copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,=0A-              =
                    size * BYTES_PER_LONG) !=3D 0 )=0A+        unsigned =
int size =3D BITS_TO_LONGS(nr);=0A+=0A+        if ( clear_guest(dirty_bitma=
p, size * BYTES_PER_LONG) !=3D 0 )=0A             rv =3D -EFAULT;=0A       =
  goto out;=0A     }=0A@@ -495,11 +496,10 @@ int paging_log_dirty_range(str=
uct domain=0A                   (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES=
);=0A                   i2++ )=0A             {=0A-                static =
unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];=0A                 =
unsigned int bytes =3D PAGE_SIZE;=0A                 uint8_t *s;=0A        =
         l1 =3D ((l2 && mfn_valid(l2[i2])) ?=0A-                      =
map_domain_page(mfn_x(l2[i2])) : zeroes);=0A+                      =
map_domain_page(mfn_x(l2[i2])) : NULL);=0A =0A                 s =3D =
((uint8_t*)l1) + (b1 >> 3);=0A                 bytes -=3D b1 >> 3;=0A@@ =
-507,9 +507,18 @@ int paging_log_dirty_range(struct domain=0A              =
   if ( likely(((nr - pages + 7) >> 3) < bytes) )=0A                     =
bytes =3D (unsigned int)((nr - pages + 7) >> 3);=0A =0A+                if =
( !l1 )=0A+                {=0A+                    if ( clear_guest_offset=
(dirty_bitmap, pages >> 3,=0A+                                            =
bytes) !=3D 0 )=0A+                    {=0A+                        rv =3D =
-EFAULT;=0A+                        goto out;=0A+                    }=0A+ =
               }=0A                 /* begin_pfn is not 32K aligned, hence =
we have to bit=0A                  * shift the bitmap */=0A-               =
 if ( b1 & 0x7 )=0A+                else if ( b1 & 0x7 )=0A                =
 {=0A                     int i, j;=0A                     uint32_t *l =3D =
(uint32_t*) s;=0A@@ -553,11 +562,12 @@ int paging_log_dirty_range(struct =
domain=0A                     }=0A                 }=0A =0A-               =
 if ( l1 !=3D zeroes )=0A-                    clear_page(l1);=0A           =
      pages +=3D bytes << 3;=0A-                if ( l1 !=3D zeroes )=0A+  =
              if ( l1 )=0A+                {=0A+                    =
clear_page(l1);=0A                     unmap_domain_page(l1);=0A+          =
      }=0A                 b1 =3D b1 & 0x7;=0A             }=0A            =
 b2 =3D 0;=0A
--=__Part436D3155.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part436D3155.0__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 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.xensource.com>)
	id 1RuRXN-0006Em-U0; Mon, 06 Feb 2012 16:35:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRXM-0006EP-LD
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:35:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328546120!10277274!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1484 invoked from network); 6 Feb 2012 16:35:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:35:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:37:28 +0000
Message-Id: <4F300F55020000780007167D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:35:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part436D3155.0__="
Subject: [Xen-devel] [PATCH] x86/paging: use clear_guest() for zero-filling
 guest buffers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part436D3155.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While static arrays of all zeros may be tolerable (but are simply
inefficient now that we have the necessary infrastructure), using on-
stack arrays for this purpose (particularly when their size doesn't
have an upper limit enforced) is calling for eventual problems (even
if the code can be reached via administrative interfaces only).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -21,11 +21,11 @@
  */
=20
 #include <xen/init.h>
+#include <xen/guest_access.h>
 #include <asm/paging.h>
 #include <asm/shadow.h>
 #include <asm/p2m.h>
 #include <asm/hap.h>
-#include <asm/guest_access.h>
 #include <asm/hvm/nestedhvm.h>
 #include <xen/numa.h>
 #include <xsm/xsm.h>
@@ -383,26 +383,30 @@ int paging_log_dirty_op(struct domain *d
                   (pages < sc->pages) && (i2 < LOGDIRTY_NODE_ENTRIES);
                   i2++ )
             {
-                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
                 unsigned int bytes =3D PAGE_SIZE;
                 l1 =3D ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : zeroes);
+                      map_domain_page(mfn_x(l2[i2])) : NULL);
                 if ( unlikely(((sc->pages - pages + 7) >> 3) < bytes) )
                     bytes =3D (unsigned int)((sc->pages - pages + 7) >> =
3);
                 if ( likely(peek) )
                 {
-                    if ( copy_to_guest_offset(sc->dirty_bitmap, pages >> =
3,
-                                              (uint8_t *)l1, bytes) !=3D =
0 )
+                    if ( (l1 ? copy_to_guest_offset(sc->dirty_bitmap,
+                                                    pages >> 3, (uint8_t =
*)l1,
+                                                    bytes)
+                             : clear_guest_offset(sc->dirty_bitmap,
+                                                  pages >> 3, bytes)) =
!=3D 0 )
                     {
                         rv =3D -EFAULT;
                         goto out;
                     }
                 }
-                if ( clean && l1 !=3D zeroes )
-                    clear_page(l1);
                 pages +=3D bytes << 3;
-                if ( l1 !=3D zeroes )
+                if ( l1 )
+                {
+                    if ( clean )
+                        clear_page(l1);
                     unmap_domain_page(l1);
+                }
             }
             if ( l2 )
                 unmap_domain_page(l2);
@@ -462,12 +466,9 @@ int paging_log_dirty_range(struct domain
=20
     if ( !d->arch.paging.log_dirty.fault_count &&
          !d->arch.paging.log_dirty.dirty_count ) {
-        int size =3D (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
-        unsigned long zeroes[size];
-        memset(zeroes, 0x00, size * BYTES_PER_LONG);
-        rv =3D 0;
-        if ( copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,
-                                  size * BYTES_PER_LONG) !=3D 0 )
+        unsigned int size =3D BITS_TO_LONGS(nr);
+
+        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) !=3D 0 )
             rv =3D -EFAULT;
         goto out;
     }
@@ -495,11 +496,10 @@ int paging_log_dirty_range(struct domain
                   (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
                   i2++ )
             {
-                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
                 unsigned int bytes =3D PAGE_SIZE;
                 uint8_t *s;
                 l1 =3D ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : zeroes);
+                      map_domain_page(mfn_x(l2[i2])) : NULL);
=20
                 s =3D ((uint8_t*)l1) + (b1 >> 3);
                 bytes -=3D b1 >> 3;
@@ -507,9 +507,18 @@ int paging_log_dirty_range(struct domain
                 if ( likely(((nr - pages + 7) >> 3) < bytes) )
                     bytes =3D (unsigned int)((nr - pages + 7) >> 3);
=20
+                if ( !l1 )
+                {
+                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
+                                            bytes) !=3D 0 )
+                    {
+                        rv =3D -EFAULT;
+                        goto out;
+                    }
+                }
                 /* begin_pfn is not 32K aligned, hence we have to bit
                  * shift the bitmap */
-                if ( b1 & 0x7 )
+                else if ( b1 & 0x7 )
                 {
                     int i, j;
                     uint32_t *l =3D (uint32_t*) s;
@@ -553,11 +562,12 @@ int paging_log_dirty_range(struct domain
                     }
                 }
=20
-                if ( l1 !=3D zeroes )
-                    clear_page(l1);
                 pages +=3D bytes << 3;
-                if ( l1 !=3D zeroes )
+                if ( l1 )
+                {
+                    clear_page(l1);
                     unmap_domain_page(l1);
+                }
                 b1 =3D b1 & 0x7;
             }
             b2 =3D 0;



--=__Part436D3155.0__=
Content-Type: text/plain; name="x86-paging-use-clear_guest.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-paging-use-clear_guest.patch"

x86/paging: use clear_guest() for zero-filling guest buffers=0A=0AWhile =
static arrays of all zeros may be tolerable (but are simply=0Ainefficient =
now that we have the necessary infrastructure), using on-=0Astack arrays =
for this purpose (particularly when their size doesn't=0Ahave an upper =
limit enforced) is calling for eventual problems (even=0Aif the code can =
be reached via administrative interfaces only).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mm/paging.c=0A+++ =
b/xen/arch/x86/mm/paging.c=0A@@ -21,11 +21,11 @@=0A  */=0A =0A #include =
<xen/init.h>=0A+#include <xen/guest_access.h>=0A #include <asm/paging.h>=0A=
 #include <asm/shadow.h>=0A #include <asm/p2m.h>=0A #include <asm/hap.h>=0A=
-#include <asm/guest_access.h>=0A #include <asm/hvm/nestedhvm.h>=0A =
#include <xen/numa.h>=0A #include <xsm/xsm.h>=0A@@ -383,26 +383,30 @@ int =
paging_log_dirty_op(struct domain *d=0A                   (pages < =
sc->pages) && (i2 < LOGDIRTY_NODE_ENTRIES);=0A                   i2++ )=0A =
            {=0A-                static unsigned long zeroes[PAGE_SIZE/BYTE=
S_PER_LONG];=0A                 unsigned int bytes =3D PAGE_SIZE;=0A       =
          l1 =3D ((l2 && mfn_valid(l2[i2])) ?=0A-                      =
map_domain_page(mfn_x(l2[i2])) : zeroes);=0A+                      =
map_domain_page(mfn_x(l2[i2])) : NULL);=0A                 if ( unlikely(((=
sc->pages - pages + 7) >> 3) < bytes) )=0A                     bytes =3D =
(unsigned int)((sc->pages - pages + 7) >> 3);=0A                 if ( =
likely(peek) )=0A                 {=0A-                    if ( copy_to_gue=
st_offset(sc->dirty_bitmap, pages >> 3,=0A-                                =
              (uint8_t *)l1, bytes) !=3D 0 )=0A+                    if ( =
(l1 ? copy_to_guest_offset(sc->dirty_bitmap,=0A+                           =
                         pages >> 3, (uint8_t *)l1,=0A+                    =
                                bytes)=0A+                             : =
clear_guest_offset(sc->dirty_bitmap,=0A+                                   =
               pages >> 3, bytes)) !=3D 0 )=0A                     {=0A    =
                     rv =3D -EFAULT;=0A                         goto =
out;=0A                     }=0A                 }=0A-                if ( =
clean && l1 !=3D zeroes )=0A-                    clear_page(l1);=0A        =
         pages +=3D bytes << 3;=0A-                if ( l1 !=3D zeroes =
)=0A+                if ( l1 )=0A+                {=0A+                    =
if ( clean )=0A+                        clear_page(l1);=0A                 =
    unmap_domain_page(l1);=0A+                }=0A             }=0A        =
     if ( l2 )=0A                 unmap_domain_page(l2);=0A@@ -462,12 =
+466,9 @@ int paging_log_dirty_range(struct domain=0A =0A     if ( =
!d->arch.paging.log_dirty.fault_count &&=0A          !d->arch.paging.log_di=
rty.dirty_count ) {=0A-        int size =3D (nr + BITS_PER_LONG - 1) / =
BITS_PER_LONG;=0A-        unsigned long zeroes[size];=0A-        memset(zer=
oes, 0x00, size * BYTES_PER_LONG);=0A-        rv =3D 0;=0A-        if ( =
copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,=0A-              =
                    size * BYTES_PER_LONG) !=3D 0 )=0A+        unsigned =
int size =3D BITS_TO_LONGS(nr);=0A+=0A+        if ( clear_guest(dirty_bitma=
p, size * BYTES_PER_LONG) !=3D 0 )=0A             rv =3D -EFAULT;=0A       =
  goto out;=0A     }=0A@@ -495,11 +496,10 @@ int paging_log_dirty_range(str=
uct domain=0A                   (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES=
);=0A                   i2++ )=0A             {=0A-                static =
unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];=0A                 =
unsigned int bytes =3D PAGE_SIZE;=0A                 uint8_t *s;=0A        =
         l1 =3D ((l2 && mfn_valid(l2[i2])) ?=0A-                      =
map_domain_page(mfn_x(l2[i2])) : zeroes);=0A+                      =
map_domain_page(mfn_x(l2[i2])) : NULL);=0A =0A                 s =3D =
((uint8_t*)l1) + (b1 >> 3);=0A                 bytes -=3D b1 >> 3;=0A@@ =
-507,9 +507,18 @@ int paging_log_dirty_range(struct domain=0A              =
   if ( likely(((nr - pages + 7) >> 3) < bytes) )=0A                     =
bytes =3D (unsigned int)((nr - pages + 7) >> 3);=0A =0A+                if =
( !l1 )=0A+                {=0A+                    if ( clear_guest_offset=
(dirty_bitmap, pages >> 3,=0A+                                            =
bytes) !=3D 0 )=0A+                    {=0A+                        rv =3D =
-EFAULT;=0A+                        goto out;=0A+                    }=0A+ =
               }=0A                 /* begin_pfn is not 32K aligned, hence =
we have to bit=0A                  * shift the bitmap */=0A-               =
 if ( b1 & 0x7 )=0A+                else if ( b1 & 0x7 )=0A                =
 {=0A                     int i, j;=0A                     uint32_t *l =3D =
(uint32_t*) s;=0A@@ -553,11 +562,12 @@ int paging_log_dirty_range(struct =
domain=0A                     }=0A                 }=0A =0A-               =
 if ( l1 !=3D zeroes )=0A-                    clear_page(l1);=0A           =
      pages +=3D bytes << 3;=0A-                if ( l1 !=3D zeroes )=0A+  =
              if ( l1 )=0A+                {=0A+                    =
clear_page(l1);=0A                     unmap_domain_page(l1);=0A+          =
      }=0A                 b1 =3D b1 & 0x7;=0A             }=0A            =
 b2 =3D 0;=0A
--=__Part436D3155.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part436D3155.0__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRYY-0006JV-DK; Mon, 06 Feb 2012 16:36:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RuRYW-0006Iu-AY
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:36:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328546192!3795701!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25013 invoked from network); 6 Feb 2012 16:36:34 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 16:36:34 -0000
Received: by ggnu1 with SMTP id u1so54447219ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 08:36:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SczfyTCw7zLVFraKL2adHAv68RvvQ+Lrmp7wrlEPhrw=;
	b=KWtHjx8Owl+RqKGmDCnC+gfSzi8ez+/duPm+9/8fN6cncxwMcfWHDwDR2zrbdhdJia
	sUfyBvQ4NYZxO+O1GsIiSLzewF/lez+V/in6t4DN2l6NEqsmShNVA3ARih9eb/8rlDto
	wMEnbZrzmynJF1ooMnz+GQmAlz6vk4BXLiZbo=
Received: by 10.50.171.40 with SMTP id ar8mr21737695igc.26.1328546191328;
	Mon, 06 Feb 2012 08:36:31 -0800 (PST)
Received: from [206.12.33.122] (dhcp-206-12-33-122.ubcvisitor.wifi.ubc.ca.
	[206.12.33.122])
	by mx.google.com with ESMTPS id 5sm27391082ibe.8.2012.02.06.08.36.06
	(version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 08:36:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 06 Feb 2012 08:35:57 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB55416D.2A7AB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ia64: fix build (next instance)
Thread-Index: Aczk7WbNXe812fua3E+WMIy3mv62LQ==
In-Reply-To: <4F300E580200007800071668@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ia64: fix build (next instance)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/02/2012 16:31, "Jan Beulich" <JBeulich@suse.com> wrote:

> A number of build problems crept in once again. Fix them.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -683,7 +683,7 @@ long do_memory_op(unsigned long cmd, XEN
>          mfn = get_gfn_untyped(d, xrfp.gpfn);
>  
>          if ( mfn_valid(mfn) )
> -            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
>          else
>              rc = -ENOENT;
>  
> --- a/xen/include/asm-ia64/linux-xen/asm/irq.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/irq.h
> @@ -72,7 +72,7 @@ extern int request_irq_vector(unsigned i
>  #define irq_complete_move(x) do {} \
>      while(!x)
>  
> -#define domain_pirq_to_irq(d, irq) domain_irq_to_vector(d, irq)
> +#define domain_pirq_to_irq(d, irq) (irq) /* domain_irq_to_vector(d, irq) */
>  
>  #define hvm_domain_use_pirq(d, info) 0
>  #endif
> --- a/xen/include/asm-ia64/linux-xen/asm/processor.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/processor.h
> @@ -17,7 +17,12 @@
>  
>  #include <asm/intrinsics.h>
>  #include <asm/kregs.h>
> +#if !defined(XEN)
>  #include <asm/ptrace.h>
> +#elif !defined(__ASSEMBLY__)
> +struct cpu_user_regs;
> +#define pt_regs cpu_user_regs
> +#endif
>  #include <asm/ustack.h>
>  
>  /* Our arch specific arch_init_sched_domain is in arch/ia64/kernel/domain.c
> */
> @@ -783,4 +788,8 @@ ia64_get_cpl(unsigned long psr)
>  
>  #endif /* !__ASSEMBLY__ */
>  
> +#ifdef XEN
> +#include <asm/ptrace.h>
> +#endif
> +
>  #endif /* _ASM_IA64_PROCESSOR_H */
> --- a/xen/include/xen/list.h
> +++ b/xen/include/xen/list.h
> @@ -8,7 +8,6 @@
>  #define __XEN_LIST_H__
>  
>  #include <xen/lib.h>
> -#include <xen/prefetch.h>
>  #include <asm/system.h>
>  
>  /* These are non-NULL pointers that will result in page faults
> @@ -40,6 +39,9 @@ struct list_head {
>  #define LIST_HEAD_READ_MOSTLY(name) \
>      struct list_head __read_mostly name = LIST_HEAD_INIT(name)
>  
> +/* Do not move this ahead of the struct list_head definition! */
> +#include <xen/prefetch.h>
> +
>  static inline void INIT_LIST_HEAD(struct list_head *list)
>  {
>      list->next = list;
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -106,6 +106,7 @@ struct xsm_operations {
>      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 *d, struct page_info *page);
> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>  
>      int (*console_io) (struct domain *d, int cmd);
>  
> @@ -174,7 +175,6 @@ struct xsm_operations {
>      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 (*remove_from_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);
> @@ -460,6 +460,11 @@ static inline int xsm_memory_pin_page(st
>      return xsm_call(memory_pin_page(d, page));
>  }
>  
> +static inline int xsm_remove_from_physmap(struct domain *d1, struct domain
> *d2)
> +{
> +    return xsm_call(remove_from_physmap(d1, d2));
> +}
> +
>  static inline int xsm_console_io (struct domain *d, int cmd)
>  {
>      return xsm_call(console_io(d, cmd));
> @@ -764,11 +769,6 @@ static inline int xsm_add_to_physmap(str
>      return xsm_call(add_to_physmap(d1, d2));
>  }
>  
> -static inline int xsm_remove_from_physmap(struct domain *d1, struct domain
> *d2)
> -{
> -    return xsm_call(remove_from_physmap(d1, d2));
> -}
> -
>  static inline int xsm_sendtrigger(struct domain *d)
>  {
>      return xsm_call(sendtrigger(d));
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRYY-0006JV-DK; Mon, 06 Feb 2012 16:36:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RuRYW-0006Iu-AY
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:36:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328546192!3795701!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25013 invoked from network); 6 Feb 2012 16:36:34 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 16:36:34 -0000
Received: by ggnu1 with SMTP id u1so54447219ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 08:36:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SczfyTCw7zLVFraKL2adHAv68RvvQ+Lrmp7wrlEPhrw=;
	b=KWtHjx8Owl+RqKGmDCnC+gfSzi8ez+/duPm+9/8fN6cncxwMcfWHDwDR2zrbdhdJia
	sUfyBvQ4NYZxO+O1GsIiSLzewF/lez+V/in6t4DN2l6NEqsmShNVA3ARih9eb/8rlDto
	wMEnbZrzmynJF1ooMnz+GQmAlz6vk4BXLiZbo=
Received: by 10.50.171.40 with SMTP id ar8mr21737695igc.26.1328546191328;
	Mon, 06 Feb 2012 08:36:31 -0800 (PST)
Received: from [206.12.33.122] (dhcp-206-12-33-122.ubcvisitor.wifi.ubc.ca.
	[206.12.33.122])
	by mx.google.com with ESMTPS id 5sm27391082ibe.8.2012.02.06.08.36.06
	(version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 08:36:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 06 Feb 2012 08:35:57 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB55416D.2A7AB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ia64: fix build (next instance)
Thread-Index: Aczk7WbNXe812fua3E+WMIy3mv62LQ==
In-Reply-To: <4F300E580200007800071668@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ia64: fix build (next instance)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/02/2012 16:31, "Jan Beulich" <JBeulich@suse.com> wrote:

> A number of build problems crept in once again. Fix them.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -683,7 +683,7 @@ long do_memory_op(unsigned long cmd, XEN
>          mfn = get_gfn_untyped(d, xrfp.gpfn);
>  
>          if ( mfn_valid(mfn) )
> -            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
>          else
>              rc = -ENOENT;
>  
> --- a/xen/include/asm-ia64/linux-xen/asm/irq.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/irq.h
> @@ -72,7 +72,7 @@ extern int request_irq_vector(unsigned i
>  #define irq_complete_move(x) do {} \
>      while(!x)
>  
> -#define domain_pirq_to_irq(d, irq) domain_irq_to_vector(d, irq)
> +#define domain_pirq_to_irq(d, irq) (irq) /* domain_irq_to_vector(d, irq) */
>  
>  #define hvm_domain_use_pirq(d, info) 0
>  #endif
> --- a/xen/include/asm-ia64/linux-xen/asm/processor.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/processor.h
> @@ -17,7 +17,12 @@
>  
>  #include <asm/intrinsics.h>
>  #include <asm/kregs.h>
> +#if !defined(XEN)
>  #include <asm/ptrace.h>
> +#elif !defined(__ASSEMBLY__)
> +struct cpu_user_regs;
> +#define pt_regs cpu_user_regs
> +#endif
>  #include <asm/ustack.h>
>  
>  /* Our arch specific arch_init_sched_domain is in arch/ia64/kernel/domain.c
> */
> @@ -783,4 +788,8 @@ ia64_get_cpl(unsigned long psr)
>  
>  #endif /* !__ASSEMBLY__ */
>  
> +#ifdef XEN
> +#include <asm/ptrace.h>
> +#endif
> +
>  #endif /* _ASM_IA64_PROCESSOR_H */
> --- a/xen/include/xen/list.h
> +++ b/xen/include/xen/list.h
> @@ -8,7 +8,6 @@
>  #define __XEN_LIST_H__
>  
>  #include <xen/lib.h>
> -#include <xen/prefetch.h>
>  #include <asm/system.h>
>  
>  /* These are non-NULL pointers that will result in page faults
> @@ -40,6 +39,9 @@ struct list_head {
>  #define LIST_HEAD_READ_MOSTLY(name) \
>      struct list_head __read_mostly name = LIST_HEAD_INIT(name)
>  
> +/* Do not move this ahead of the struct list_head definition! */
> +#include <xen/prefetch.h>
> +
>  static inline void INIT_LIST_HEAD(struct list_head *list)
>  {
>      list->next = list;
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -106,6 +106,7 @@ struct xsm_operations {
>      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 *d, struct page_info *page);
> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>  
>      int (*console_io) (struct domain *d, int cmd);
>  
> @@ -174,7 +175,6 @@ struct xsm_operations {
>      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 (*remove_from_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);
> @@ -460,6 +460,11 @@ static inline int xsm_memory_pin_page(st
>      return xsm_call(memory_pin_page(d, page));
>  }
>  
> +static inline int xsm_remove_from_physmap(struct domain *d1, struct domain
> *d2)
> +{
> +    return xsm_call(remove_from_physmap(d1, d2));
> +}
> +
>  static inline int xsm_console_io (struct domain *d, int cmd)
>  {
>      return xsm_call(console_io(d, cmd));
> @@ -764,11 +769,6 @@ static inline int xsm_add_to_physmap(str
>      return xsm_call(add_to_physmap(d1, d2));
>  }
>  
> -static inline int xsm_remove_from_physmap(struct domain *d1, struct domain
> *d2)
> -{
> -    return xsm_call(remove_from_physmap(d1, d2));
> -}
> -
>  static inline int xsm_sendtrigger(struct domain *d)
>  {
>      return xsm_call(sendtrigger(d));
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:37:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16: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.xensource.com>)
	id 1RuRYc-0006KW-VV; Mon, 06 Feb 2012 16:36:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RuRYb-0006JE-Or
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:36:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328546192!3795701!2
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25343 invoked from network); 6 Feb 2012 16:36:39 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 16:36:39 -0000
Received: by mail-gx0-f171.google.com with SMTP id u1so54447219ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 08:36:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=yrnIWO+2jyQ3nv0HkeI1Ks1P8wenIfI63D1qz7kQqkI=;
	b=WdCNYgrmAHKALojmC28/tkH0NFtzYzR4OxLaUFo7NCqhrwqlXoAqyeiUIt9SOTdUFI
	GD8kRpDcPEA06k1RRLgAScpFMae1GQLU7brAhyIWQW4QSfldHc+b2+z220zhcklQdQWk
	RERn7dDERJOb1kMQlnH8hNbmFnx3MG2lvTPj4=
Received: by 10.50.89.196 with SMTP id bq4mr21757033igb.26.1328546199232;
	Mon, 06 Feb 2012 08:36:39 -0800 (PST)
Received: from [206.12.33.122] (dhcp-206-12-33-122.ubcvisitor.wifi.ubc.ca.
	[206.12.33.122])
	by mx.google.com with ESMTPS id 5sm27391082ibe.8.2012.02.06.08.36.32
	(version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 08:36:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 06 Feb 2012 08:36:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB554182.2A7AC%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
	specific MSR handling
Thread-Index: Aczk7XNRnh1pBOBCPkWtCbHKLcnvfQ==
In-Reply-To: <4F300E050200007800071664@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
 specific MSR handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/02/2012 16:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> This is model 0x3a (decimal 58) as per the most recent SDM.
> 
> In vPMU code, also add a forgotten earlier model.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Fine by me with an appropriate Ack from Intel.

 K.

> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -106,6 +106,8 @@ static void do_get_hw_residencies(void *
>  
>      switch ( c->x86_model )
>      {
> +    /* Ivy bridge */
> +    case 0x3A:
>      /* Sandy bridge */
>      case 0x2A:
>      case 0x2D:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1751,6 +1751,8 @@ static const struct lbr_info *last_branc
>          case 37: case 44: case 47:
>          /* Sandy Bridge */
>          case 42: case 45:
> +        /* Ivy Bridge */
> +        case 58:
>              return nh_lbr;
>              break;
>          /* Atom */
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
>          case 26:
>          case 29:
>          case 42:
> +        case 45:
>          case 46:
>          case 47:
> +        case 58:
>              vpmu->arch_vpmu_ops = &core2_vpmu_ops;
>              return 0;
>          }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:37:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16: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.xensource.com>)
	id 1RuRYc-0006KW-VV; Mon, 06 Feb 2012 16:36:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RuRYb-0006JE-Or
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:36:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328546192!3795701!2
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25343 invoked from network); 6 Feb 2012 16:36:39 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 16:36:39 -0000
Received: by mail-gx0-f171.google.com with SMTP id u1so54447219ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 08:36:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=yrnIWO+2jyQ3nv0HkeI1Ks1P8wenIfI63D1qz7kQqkI=;
	b=WdCNYgrmAHKALojmC28/tkH0NFtzYzR4OxLaUFo7NCqhrwqlXoAqyeiUIt9SOTdUFI
	GD8kRpDcPEA06k1RRLgAScpFMae1GQLU7brAhyIWQW4QSfldHc+b2+z220zhcklQdQWk
	RERn7dDERJOb1kMQlnH8hNbmFnx3MG2lvTPj4=
Received: by 10.50.89.196 with SMTP id bq4mr21757033igb.26.1328546199232;
	Mon, 06 Feb 2012 08:36:39 -0800 (PST)
Received: from [206.12.33.122] (dhcp-206-12-33-122.ubcvisitor.wifi.ubc.ca.
	[206.12.33.122])
	by mx.google.com with ESMTPS id 5sm27391082ibe.8.2012.02.06.08.36.32
	(version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 08:36:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 06 Feb 2012 08:36:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB554182.2A7AC%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
	specific MSR handling
Thread-Index: Aczk7XNRnh1pBOBCPkWtCbHKLcnvfQ==
In-Reply-To: <4F300E050200007800071664@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
 specific MSR handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/02/2012 16:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> This is model 0x3a (decimal 58) as per the most recent SDM.
> 
> In vPMU code, also add a forgotten earlier model.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Fine by me with an appropriate Ack from Intel.

 K.

> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -106,6 +106,8 @@ static void do_get_hw_residencies(void *
>  
>      switch ( c->x86_model )
>      {
> +    /* Ivy bridge */
> +    case 0x3A:
>      /* Sandy bridge */
>      case 0x2A:
>      case 0x2D:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1751,6 +1751,8 @@ static const struct lbr_info *last_branc
>          case 37: case 44: case 47:
>          /* Sandy Bridge */
>          case 42: case 45:
> +        /* Ivy Bridge */
> +        case 58:
>              return nh_lbr;
>              break;
>          /* Atom */
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
>          case 26:
>          case 29:
>          case 42:
> +        case 45:
>          case 46:
>          case 47:
> +        case 58:
>              vpmu->arch_vpmu_ops = &core2_vpmu_ops;
>              return 0;
>          }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:37:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRZQ-0006SO-EH; Mon, 06 Feb 2012 16:37:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RuRZO-0006RM-Jz
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:37:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328546244!12218613!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18116 invoked from network); 6 Feb 2012 16:37:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2012 16:37:26 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16GbLWm016862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 16:37:22 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
	q16GbI31000629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 16:37:19 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
	q16GbGCu012572; Mon, 6 Feb 2012 10:37:16 -0600
MIME-Version: 1.0
Message-ID: <e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
Date: Mon, 6 Feb 2012 08:37:17 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
In-Reply-To: <4F2F998202000078000714CD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F3001C2.00CE,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, February 06, 2012 1:13 AM
> To: Dan Magenheimer
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] xen/tmem: cleanup
> 
> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Subject: [PATCH] xen/tmem: cleanup
> >>
> >> Use 'bool' for boolean variables. Do proper section placement.
> >> Eliminate an unnecessary export.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> >>
> >> -int tmem_enabled __read_mostly;
> >> -EXPORT_SYMBOL(tmem_enabled);
> >> +bool __read_mostly tmem_enabled = false;
> >
> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
> 
> Which can't be built as a module, and hence the symbol doesn't need
> exporting. This patch (of course, I'm tempted to say) survived build
> testing.

Yes, correct.  BUT... I think only the reason xen-selfballoon.c
can't be built as a module is because the MM variable vm_committed_as
(or an access function) is not exported.  Ideally xen-selfballoon.c
probably should be a module but putting a core MM change in
the critical path of a Xen-only-related enhancement seemed
a recipe for sure failure.

Konrad, if you (1) disagree entirely, or (2) want to remove the
tmem_enabled EXPORT_SYMBOL now and add it back later if/when
the core MM change happens, I'll leave that up to you.

If (2), the MM change should be added to the minor-tmem-related-
changes-that-need-to-be-eventually-upstreamed list ;-)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:37:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRZQ-0006SO-EH; Mon, 06 Feb 2012 16:37:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RuRZO-0006RM-Jz
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:37:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328546244!12218613!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18116 invoked from network); 6 Feb 2012 16:37:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2012 16:37:26 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16GbLWm016862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 16:37:22 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
	q16GbI31000629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 16:37:19 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
	q16GbGCu012572; Mon, 6 Feb 2012 10:37:16 -0600
MIME-Version: 1.0
Message-ID: <e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
Date: Mon, 6 Feb 2012 08:37:17 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
In-Reply-To: <4F2F998202000078000714CD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F3001C2.00CE,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, February 06, 2012 1:13 AM
> To: Dan Magenheimer
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] xen/tmem: cleanup
> 
> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Subject: [PATCH] xen/tmem: cleanup
> >>
> >> Use 'bool' for boolean variables. Do proper section placement.
> >> Eliminate an unnecessary export.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> >>
> >> -int tmem_enabled __read_mostly;
> >> -EXPORT_SYMBOL(tmem_enabled);
> >> +bool __read_mostly tmem_enabled = false;
> >
> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
> 
> Which can't be built as a module, and hence the symbol doesn't need
> exporting. This patch (of course, I'm tempted to say) survived build
> testing.

Yes, correct.  BUT... I think only the reason xen-selfballoon.c
can't be built as a module is because the MM variable vm_committed_as
(or an access function) is not exported.  Ideally xen-selfballoon.c
probably should be a module but putting a core MM change in
the critical path of a Xen-only-related enhancement seemed
a recipe for sure failure.

Konrad, if you (1) disagree entirely, or (2) want to remove the
tmem_enabled EXPORT_SYMBOL now and add it back later if/when
the core MM change happens, I'll leave that up to you.

If (2), the MM change should be added to the minor-tmem-related-
changes-that-need-to-be-eventually-upstreamed list ;-)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:46:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRhd-0006tb-GF; Mon, 06 Feb 2012 16:46:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRhb-0006tW-NL
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:46:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328546756!3797195!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19105 invoked from network); 6 Feb 2012 16:45:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:45:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:45:56 +0000
Message-Id: <4F3011D102000078000716A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:45:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liuyongan" <liuyongan@huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 12:38, Liuyongan <liuyongan@huawei.com> wrote:

>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, February 06, 2012 5:03 PM
>> To: Liuyongan
>> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
>> Cavilla; xen-devel@lists.xensource.com 
>> Subject: Re: [Xen-devel] [PATCH] grant table map error in
>> __gnttab_map_grant_ref
>> 
>>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
>> > In file grant_table.c function __gnttab_map_grant_ref, if
>> __get_paged_frame
>> > failed, the effect of _set_status  previously called should be
>> rollback, so
>> > the flag GTF_reading and _GTF_writing will be recovered.
>> 
>> Not knowing too much about these, but isn't __acquire_grant_for_copy()
>> in need of a similar adjustment?
>   Well, I need to check it further.
>> 
>> Further, aren't the status flags cumulative (and hence isn't it wrong
>> to
>> simply clear flags without considering their original state)? 
>   When undo_out branch is executed, the flag set by _set_status function
>   will be rolled back by:
>        if ( !(op->flags & GNTMAP_readonly) &&
>          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>         gnttab_clear_flag(_GTF_writing, status);
> 
>        if ( !act->pin )
>         gnttab_clear_flag(_GTF_reading, status);
>   so action added by this patch should be correct. 

But this is not a roll-back, here the flags get simply cleared (whereas
"roll-back" to me means the restoration of their previous value).

>   And anyway, the  reading and writing flag should be recovered when mapping 
>   grant reference failed, so the up layer(eg. Netback driver) can decide 
>   freely whether retry mapping or fail directly.

Those flags, afaiu, are managed by Xen, so the layer issuing the
mapping operation shouldn't be concerned.

Jan

>> (I realize
>> that this is not a new issue introduced with the proposed patch, but
>> certainly with more ways of getting that code path run through, it
>> becomes more important for it to be correct.)
>> 
>> Jan
>> 
>> > Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
>> > Wang<hzwangliang.wang@huawei.com>
>> >
>> > diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
>> > --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13
>> 2012 +0800
>> > +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02
>> 2012 +0800
>> > @@ -566,7 +566,7 @@
>> >              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
>> >              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
>> > GNTMAP_readonly), rd);
>> >              if ( rc != GNTST_okay )
>> > -                goto unlock_out;
>> > +                goto unlock_out_clear;
>> >              act->gfn = gfn;
>> >              act->domid = ld->domain_id;
>> >              act->frame = frame;
>> > @@ -721,7 +721,8 @@
>> >      if ( op->flags & GNTMAP_host_map )
>> >          act->pin -= (op->flags & GNTMAP_readonly) ?
>> >              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
>> > -
>> > +
>> > + unlock_out_clear:
>> >      if ( !(op->flags & GNTMAP_readonly) &&
>> >           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>> >          gnttab_clear_flag(_GTF_writing, status);
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:46:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRhd-0006tb-GF; Mon, 06 Feb 2012 16:46:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRhb-0006tW-NL
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:46:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328546756!3797195!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19105 invoked from network); 6 Feb 2012 16:45:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:45:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:45:56 +0000
Message-Id: <4F3011D102000078000716A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:45:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liuyongan" <liuyongan@huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 12:38, Liuyongan <liuyongan@huawei.com> wrote:

>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, February 06, 2012 5:03 PM
>> To: Liuyongan
>> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
>> Cavilla; xen-devel@lists.xensource.com 
>> Subject: Re: [Xen-devel] [PATCH] grant table map error in
>> __gnttab_map_grant_ref
>> 
>>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
>> > In file grant_table.c function __gnttab_map_grant_ref, if
>> __get_paged_frame
>> > failed, the effect of _set_status  previously called should be
>> rollback, so
>> > the flag GTF_reading and _GTF_writing will be recovered.
>> 
>> Not knowing too much about these, but isn't __acquire_grant_for_copy()
>> in need of a similar adjustment?
>   Well, I need to check it further.
>> 
>> Further, aren't the status flags cumulative (and hence isn't it wrong
>> to
>> simply clear flags without considering their original state)? 
>   When undo_out branch is executed, the flag set by _set_status function
>   will be rolled back by:
>        if ( !(op->flags & GNTMAP_readonly) &&
>          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>         gnttab_clear_flag(_GTF_writing, status);
> 
>        if ( !act->pin )
>         gnttab_clear_flag(_GTF_reading, status);
>   so action added by this patch should be correct. 

But this is not a roll-back, here the flags get simply cleared (whereas
"roll-back" to me means the restoration of their previous value).

>   And anyway, the  reading and writing flag should be recovered when mapping 
>   grant reference failed, so the up layer(eg. Netback driver) can decide 
>   freely whether retry mapping or fail directly.

Those flags, afaiu, are managed by Xen, so the layer issuing the
mapping operation shouldn't be concerned.

Jan

>> (I realize
>> that this is not a new issue introduced with the proposed patch, but
>> certainly with more ways of getting that code path run through, it
>> becomes more important for it to be correct.)
>> 
>> Jan
>> 
>> > Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
>> > Wang<hzwangliang.wang@huawei.com>
>> >
>> > diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
>> > --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13
>> 2012 +0800
>> > +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02
>> 2012 +0800
>> > @@ -566,7 +566,7 @@
>> >              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
>> >              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
>> > GNTMAP_readonly), rd);
>> >              if ( rc != GNTST_okay )
>> > -                goto unlock_out;
>> > +                goto unlock_out_clear;
>> >              act->gfn = gfn;
>> >              act->domid = ld->domain_id;
>> >              act->frame = frame;
>> > @@ -721,7 +721,8 @@
>> >      if ( op->flags & GNTMAP_host_map )
>> >          act->pin -= (op->flags & GNTMAP_readonly) ?
>> >              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
>> > -
>> > +
>> > + unlock_out_clear:
>> >      if ( !(op->flags & GNTMAP_readonly) &&
>> >           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>> >          gnttab_clear_flag(_GTF_writing, status);
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:50:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16: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.xensource.com>)
	id 1RuRlH-00073f-4t; Mon, 06 Feb 2012 16:49: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 1RuRlG-00073X-B2
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:49:50 +0000
Received: from [85.158.143.35:3509] by server-1.bemta-4.messagelabs.com id
	B0/5D-29738-DA4003F4; Mon, 06 Feb 2012 16:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328546988!2220135!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7062 invoked from network); 6 Feb 2012 16:49:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:49:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:49:48 +0000
Message-Id: <4F3012B602000078000716AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:49:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
In-Reply-To: <e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, February 06, 2012 1:13 AM
>> To: Dan Magenheimer
>> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk; 
> linux-kernel@vger.kernel.org 
>> Subject: RE: [PATCH] xen/tmem: cleanup
>> 
>> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> Subject: [PATCH] xen/tmem: cleanup
>> >>
>> >> Use 'bool' for boolean variables. Do proper section placement.
>> >> Eliminate an unnecessary export.
>> >>
>> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
>> >>
>> >> -int tmem_enabled __read_mostly;
>> >> -EXPORT_SYMBOL(tmem_enabled);
>> >> +bool __read_mostly tmem_enabled = false;
>> >
>> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
>> 
>> Which can't be built as a module, and hence the symbol doesn't need
>> exporting. This patch (of course, I'm tempted to say) survived build
>> testing.
> 
> Yes, correct.  BUT... I think only the reason xen-selfballoon.c
> can't be built as a module is because the MM variable vm_committed_as
> (or an access function) is not exported.  Ideally xen-selfballoon.c
> probably should be a module but putting a core MM change in
> the critical path of a Xen-only-related enhancement seemed
> a recipe for sure failure.

No, this isn't the main reason (as you say further down, this could
easily be adjusted for) afaict. The main reason is that
register_xen_selfballooning() is being called from non-modular
code (xen-balloon.c), which could be made a module too, but in
turn has at least one reference that wouldn't be nice to become
an export (balloon_set_new_target()).

Jan

> Konrad, if you (1) disagree entirely, or (2) want to remove the
> tmem_enabled EXPORT_SYMBOL now and add it back later if/when
> the core MM change happens, I'll leave that up to you.
> 
> If (2), the MM change should be added to the minor-tmem-related-
> changes-that-need-to-be-eventually-upstreamed list ;-)
> 
> Dan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:50:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16: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.xensource.com>)
	id 1RuRlH-00073f-4t; Mon, 06 Feb 2012 16:49: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 1RuRlG-00073X-B2
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:49:50 +0000
Received: from [85.158.143.35:3509] by server-1.bemta-4.messagelabs.com id
	B0/5D-29738-DA4003F4; Mon, 06 Feb 2012 16:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328546988!2220135!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7062 invoked from network); 6 Feb 2012 16:49:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:49:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:49:48 +0000
Message-Id: <4F3012B602000078000716AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:49:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
In-Reply-To: <e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, February 06, 2012 1:13 AM
>> To: Dan Magenheimer
>> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk; 
> linux-kernel@vger.kernel.org 
>> Subject: RE: [PATCH] xen/tmem: cleanup
>> 
>> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> Subject: [PATCH] xen/tmem: cleanup
>> >>
>> >> Use 'bool' for boolean variables. Do proper section placement.
>> >> Eliminate an unnecessary export.
>> >>
>> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
>> >>
>> >> -int tmem_enabled __read_mostly;
>> >> -EXPORT_SYMBOL(tmem_enabled);
>> >> +bool __read_mostly tmem_enabled = false;
>> >
>> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
>> 
>> Which can't be built as a module, and hence the symbol doesn't need
>> exporting. This patch (of course, I'm tempted to say) survived build
>> testing.
> 
> Yes, correct.  BUT... I think only the reason xen-selfballoon.c
> can't be built as a module is because the MM variable vm_committed_as
> (or an access function) is not exported.  Ideally xen-selfballoon.c
> probably should be a module but putting a core MM change in
> the critical path of a Xen-only-related enhancement seemed
> a recipe for sure failure.

No, this isn't the main reason (as you say further down, this could
easily be adjusted for) afaict. The main reason is that
register_xen_selfballooning() is being called from non-modular
code (xen-balloon.c), which could be made a module too, but in
turn has at least one reference that wouldn't be nice to become
an export (balloon_set_new_target()).

Jan

> Konrad, if you (1) disagree entirely, or (2) want to remove the
> tmem_enabled EXPORT_SYMBOL now and add it back later if/when
> the core MM change happens, I'll leave that up to you.
> 
> If (2), the MM change should be added to the minor-tmem-related-
> changes-that-need-to-be-eventually-upstreamed list ;-)
> 
> Dan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:52:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRnj-0007BV-OI; Mon, 06 Feb 2012 16:52:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRni-0007BD-0m
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:52:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328547135!2384999!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26369 invoked from network); 6 Feb 2012 16:52:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:52:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:52:15 +0000
Message-Id: <4F30134C02000078000716AE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:52:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

How is the supposedly strait clone on xenbits related to the "real" tree?
It doesn't seem to be tracking it, so I'm sort of confused whether I
could in fact use the upstream tree in favor of the made up mirror.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 16:52:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 16:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuRnj-0007BV-OI; Mon, 06 Feb 2012 16:52:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuRni-0007BD-0m
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 16:52:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328547135!2384999!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26369 invoked from network); 6 Feb 2012 16:52:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 16:52:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 16:52:15 +0000
Message-Id: <4F30134C02000078000716AE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 16:52:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

How is the supposedly strait clone on xenbits related to the "real" tree?
It doesn't seem to be tracking it, so I'm sort of confused whether I
could in fact use the upstream tree in favor of the made up mirror.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:05:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:05:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuS0N-0007k9-Sn; Mon, 06 Feb 2012 17:05:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuS0M-0007jp-SP
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:05:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328547918!10317140!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMyNDUy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23146 invoked from network); 6 Feb 2012 17:05:20 -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; 6 Feb 2012 17:05: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 q16H5ETf012598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:05:16 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
	q16H598X011479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:05:13 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
	q16H58S2009555; Mon, 6 Feb 2012 11:05:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 09:05:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 278B640435; Mon,  6 Feb 2012 12:02:24 -0500 (EST)
Date: Mon, 6 Feb 2012 12:02:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120206170224.GD23240@phenom.dumpdata.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3012B602000078000716AB@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F30084D.0068,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 04:49:42PM +0000, Jan Beulich wrote:
> >>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Monday, February 06, 2012 1:13 AM
> >> To: Dan Magenheimer
> >> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk; 
> > linux-kernel@vger.kernel.org 
> >> Subject: RE: [PATCH] xen/tmem: cleanup
> >> 
> >> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> Subject: [PATCH] xen/tmem: cleanup
> >> >>
> >> >> Use 'bool' for boolean variables. Do proper section placement.
> >> >> Eliminate an unnecessary export.
> >> >>
> >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> >> >>
> >> >> -int tmem_enabled __read_mostly;
> >> >> -EXPORT_SYMBOL(tmem_enabled);
> >> >> +bool __read_mostly tmem_enabled = false;
> >> >
> >> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
> >> 
> >> Which can't be built as a module, and hence the symbol doesn't need
> >> exporting. This patch (of course, I'm tempted to say) survived build
> >> testing.
> > 
> > Yes, correct.  BUT... I think only the reason xen-selfballoon.c
> > can't be built as a module is because the MM variable vm_committed_as
> > (or an access function) is not exported.  Ideally xen-selfballoon.c
> > probably should be a module but putting a core MM change in
> > the critical path of a Xen-only-related enhancement seemed
> > a recipe for sure failure.
> 
> No, this isn't the main reason (as you say further down, this could
> easily be adjusted for) afaict. The main reason is that
> register_xen_selfballooning() is being called from non-modular
> code (xen-balloon.c), which could be made a module too, but in
> turn has at least one reference that wouldn't be nice to become
> an export (balloon_set_new_target()).

It would be nice if all of it could become modules. That way HVM
device driver domains could load the whole thing without having much
built-in code in the kernel.

Is it possible to do that?
> 
> Jan
> 
> > Konrad, if you (1) disagree entirely, or (2) want to remove the
> > tmem_enabled EXPORT_SYMBOL now and add it back later if/when
> > the core MM change happens, I'll leave that up to you.
> > 
> > If (2), the MM change should be added to the minor-tmem-related-
> > changes-that-need-to-be-eventually-upstreamed list ;-)
> > 
> > Dan
> 
> 
> 
> --
> 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:05:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:05:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuS0N-0007k9-Sn; Mon, 06 Feb 2012 17:05:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuS0M-0007jp-SP
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:05:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328547918!10317140!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMyNDUy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23146 invoked from network); 6 Feb 2012 17:05:20 -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; 6 Feb 2012 17:05: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 q16H5ETf012598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:05:16 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
	q16H598X011479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:05:13 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
	q16H58S2009555; Mon, 6 Feb 2012 11:05:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 09:05:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 278B640435; Mon,  6 Feb 2012 12:02:24 -0500 (EST)
Date: Mon, 6 Feb 2012 12:02:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120206170224.GD23240@phenom.dumpdata.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3012B602000078000716AB@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F30084D.0068,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 04:49:42PM +0000, Jan Beulich wrote:
> >>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Monday, February 06, 2012 1:13 AM
> >> To: Dan Magenheimer
> >> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk; 
> > linux-kernel@vger.kernel.org 
> >> Subject: RE: [PATCH] xen/tmem: cleanup
> >> 
> >> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> Subject: [PATCH] xen/tmem: cleanup
> >> >>
> >> >> Use 'bool' for boolean variables. Do proper section placement.
> >> >> Eliminate an unnecessary export.
> >> >>
> >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> >> >>
> >> >> -int tmem_enabled __read_mostly;
> >> >> -EXPORT_SYMBOL(tmem_enabled);
> >> >> +bool __read_mostly tmem_enabled = false;
> >> >
> >> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
> >> 
> >> Which can't be built as a module, and hence the symbol doesn't need
> >> exporting. This patch (of course, I'm tempted to say) survived build
> >> testing.
> > 
> > Yes, correct.  BUT... I think only the reason xen-selfballoon.c
> > can't be built as a module is because the MM variable vm_committed_as
> > (or an access function) is not exported.  Ideally xen-selfballoon.c
> > probably should be a module but putting a core MM change in
> > the critical path of a Xen-only-related enhancement seemed
> > a recipe for sure failure.
> 
> No, this isn't the main reason (as you say further down, this could
> easily be adjusted for) afaict. The main reason is that
> register_xen_selfballooning() is being called from non-modular
> code (xen-balloon.c), which could be made a module too, but in
> turn has at least one reference that wouldn't be nice to become
> an export (balloon_set_new_target()).

It would be nice if all of it could become modules. That way HVM
device driver domains could load the whole thing without having much
built-in code in the kernel.

Is it possible to do that?
> 
> Jan
> 
> > Konrad, if you (1) disagree entirely, or (2) want to remove the
> > tmem_enabled EXPORT_SYMBOL now and add it back later if/when
> > the core MM change happens, I'll leave that up to you.
> > 
> > If (2), the MM change should be added to the minor-tmem-related-
> > changes-that-need-to-be-eventually-upstreamed list ;-)
> > 
> > Dan
> 
> 
> 
> --
> 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:07:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuS1z-0007pk-CC; Mon, 06 Feb 2012 17:07:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuS1y-0007pR-3k
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328547998!64699242!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12215 invoked from network); 6 Feb 2012 17:06: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 17:06:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 17:06:59 +0000
Message-Id: <4F3016BE02000078000716C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 17:06:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
to unsigned long * - how is that not a problem in the context of the
goal that said c/s set, in particular for v2 of the interface? (Given that
this is being implemented as arch-specific routine - so far for reasons
that escape me - this should be simple to fix by using inline assembly
rather than clear_bit().)

Further I just spotted one instance where the or of two bit positions
gets passed to this function - that's quite definitely a bug I would say.

And, quite the opposite, __fixup_status_for_pin() ands out the
negation of bit positions rather than masks... (Which also raises
the question whether it really would need to be clear_bit() above
instead of the cheaper __clear_bit().)

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:07:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuS1z-0007pk-CC; Mon, 06 Feb 2012 17:07:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuS1y-0007pR-3k
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328547998!64699242!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12215 invoked from network); 6 Feb 2012 17:06: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 17:06:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 06 Feb 2012 17:06:59 +0000
Message-Id: <4F3016BE02000078000716C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 06 Feb 2012 17:06:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
to unsigned long * - how is that not a problem in the context of the
goal that said c/s set, in particular for v2 of the interface? (Given that
this is being implemented as arch-specific routine - so far for reasons
that escape me - this should be simple to fix by using inline assembly
rather than clear_bit().)

Further I just spotted one instance where the or of two bit positions
gets passed to this function - that's quite definitely a bug I would say.

And, quite the opposite, __fixup_status_for_pin() ands out the
negation of bit positions rather than masks... (Which also raises
the question whether it really would need to be clear_bit() above
instead of the cheaper __clear_bit().)

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17: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.xensource.com>)
	id 1RuSH1-0008MM-12; Mon, 06 Feb 2012 17:22:39 +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 1RuSGz-0008MH-1i
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:22:37 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328548922!58692209!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28098 invoked from network); 6 Feb 2012 17:22:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2012 17:22:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16HMSgU019584
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:22:29 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
	q16HMRGd013319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:22:28 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
	q16HMQWf023662; Mon, 6 Feb 2012 11:22:26 -0600
MIME-Version: 1.0
Message-ID: <69f22464-d460-450c-a81b-77bda8cc7568@default>
Date: Mon, 6 Feb 2012 09:22:26 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
In-Reply-To: <20120206170224.GD23240@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F300C55.00C4,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk
> Subject: Re: [PATCH] xen/tmem: cleanup
> 
> On Mon, Feb 06, 2012 at 04:49:42PM +0000, Jan Beulich wrote:
> > >>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> Sent: Monday, February 06, 2012 1:13 AM
> > >> To: Dan Magenheimer
> > >> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk;
> > > linux-kernel@vger.kernel.org
> > >> Subject: RE: [PATCH] xen/tmem: cleanup
> > >>
> > >> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > >> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> >> Subject: [PATCH] xen/tmem: cleanup
> > >> >>
> > >> >> Use 'bool' for boolean variables. Do proper section placement.
> > >> >> Eliminate an unnecessary export.
> > >> >>
> > >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > >> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> > >> >>
> > >> >> -int tmem_enabled __read_mostly;
> > >> >> -EXPORT_SYMBOL(tmem_enabled);
> > >> >> +bool __read_mostly tmem_enabled = false;
> > >> >
> > >> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
> > >>
> > >> Which can't be built as a module, and hence the symbol doesn't need
> > >> exporting. This patch (of course, I'm tempted to say) survived build
> > >> testing.
> > >
> > > Yes, correct.  BUT... I think only the reason xen-selfballoon.c
> > > can't be built as a module is because the MM variable vm_committed_as
> > > (or an access function) is not exported.  Ideally xen-selfballoon.c
> > > probably should be a module but putting a core MM change in
> > > the critical path of a Xen-only-related enhancement seemed
> > > a recipe for sure failure.
> >
> > No, this isn't the main reason (as you say further down, this could
> > easily be adjusted for) afaict. The main reason is that
> > register_xen_selfballooning() is being called from non-modular
> > code (xen-balloon.c), which could be made a module too, but in
> > turn has at least one reference that wouldn't be nice to become
> > an export (balloon_set_new_target()).

Jan, you're right, I had forgotten about that "chained" dependency.
Thanks and FWIW, on the entire original patch:

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
 
> It would be nice if all of it could become modules. That way HVM
> device driver domains could load the whole thing without having much
> built-in code in the kernel.
> 
> Is it possible to do that?

Konrad, my module expertise is very low, so I will leave that
to Jan or someone else to answer or look into.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17: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.xensource.com>)
	id 1RuSH1-0008MM-12; Mon, 06 Feb 2012 17:22:39 +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 1RuSGz-0008MH-1i
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:22:37 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328548922!58692209!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28098 invoked from network); 6 Feb 2012 17:22:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2012 17:22:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16HMSgU019584
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:22:29 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
	q16HMRGd013319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:22:28 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
	q16HMQWf023662; Mon, 6 Feb 2012 11:22:26 -0600
MIME-Version: 1.0
Message-ID: <69f22464-d460-450c-a81b-77bda8cc7568@default>
Date: Mon, 6 Feb 2012 09:22:26 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
In-Reply-To: <20120206170224.GD23240@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F300C55.00C4,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Konrad Rzeszutek Wilk
> Subject: Re: [PATCH] xen/tmem: cleanup
> 
> On Mon, Feb 06, 2012 at 04:49:42PM +0000, Jan Beulich wrote:
> > >>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> Sent: Monday, February 06, 2012 1:13 AM
> > >> To: Dan Magenheimer
> > >> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Konrad Wilk;
> > > linux-kernel@vger.kernel.org
> > >> Subject: RE: [PATCH] xen/tmem: cleanup
> > >>
> > >> >>> On 04.02.12 at 17:42, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > >> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> >> Subject: [PATCH] xen/tmem: cleanup
> > >> >>
> > >> >> Use 'bool' for boolean variables. Do proper section placement.
> > >> >> Eliminate an unnecessary export.
> > >> >>
> > >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > >> >> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
> > >> >>
> > >> >> -int tmem_enabled __read_mostly;
> > >> >> -EXPORT_SYMBOL(tmem_enabled);
> > >> >> +bool __read_mostly tmem_enabled = false;
> > >> >
> > >> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
> > >>
> > >> Which can't be built as a module, and hence the symbol doesn't need
> > >> exporting. This patch (of course, I'm tempted to say) survived build
> > >> testing.
> > >
> > > Yes, correct.  BUT... I think only the reason xen-selfballoon.c
> > > can't be built as a module is because the MM variable vm_committed_as
> > > (or an access function) is not exported.  Ideally xen-selfballoon.c
> > > probably should be a module but putting a core MM change in
> > > the critical path of a Xen-only-related enhancement seemed
> > > a recipe for sure failure.
> >
> > No, this isn't the main reason (as you say further down, this could
> > easily be adjusted for) afaict. The main reason is that
> > register_xen_selfballooning() is being called from non-modular
> > code (xen-balloon.c), which could be made a module too, but in
> > turn has at least one reference that wouldn't be nice to become
> > an export (balloon_set_new_target()).

Jan, you're right, I had forgotten about that "chained" dependency.
Thanks and FWIW, on the entire original patch:

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
 
> It would be nice if all of it could become modules. That way HVM
> device driver domains could load the whole thing without having much
> built-in code in the kernel.
> 
> Is it possible to do that?

Konrad, my module expertise is very low, so I will leave that
to Jan or someone else to answer or look into.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:24:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 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.xensource.com>)
	id 1RuSIu-0008S7-IB; Mon, 06 Feb 2012 17:24:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuSIs-0008Rs-Sb
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:24:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328549067!10285351!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29510 invoked from network); 6 Feb 2012 17:24:28 -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; 6 Feb 2012 17:24:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16HOOJj021980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:24: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
	q16HONNF016717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:24:24 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
	q16HONM3017290; Mon, 6 Feb 2012 11:24:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 09:24:23 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 18CA640469; Mon,  6 Feb 2012 12:21:39 -0500 (EST)
Date: Mon, 6 Feb 2012 12:21:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120206172139.GA26583@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
	<1328289625.7388.38.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328289625.7388.38.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F300CC9.00D0,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 05:20:25PM +0000, Wei Liu wrote:
> On Fri, 2012-02-03 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> > > 
> > 
> > So this does the job but with this patch you introduce a compile bisection
> > bug, which is a not good. The way around is that in this patch you also
> > introduce temporary scaffolding so that the drivers can build. Something
> > as simple as an function that calls the new version, but has the right
> > arguments. Then the next patch (the one that actually does change
> > the backends, will back that wrapper out).
> > 
> 
> How about squashing these two patches. The changes in backends are
> trivial.


One thing I forgot to mention is that since the backends touch different
subsystems maintainers tree - you will need to get Acks from all of them
on a single patch. That should not be an technical issue - except that some
maintainers can take longer to respond - so your whole patchset might
be delayed by that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:24:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 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.xensource.com>)
	id 1RuSIu-0008S7-IB; Mon, 06 Feb 2012 17:24:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuSIs-0008Rs-Sb
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:24:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328549067!10285351!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29510 invoked from network); 6 Feb 2012 17:24:28 -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; 6 Feb 2012 17:24:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16HOOJj021980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:24: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
	q16HONNF016717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:24:24 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
	q16HONM3017290; Mon, 6 Feb 2012 11:24:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 09:24:23 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 18CA640469; Mon,  6 Feb 2012 12:21:39 -0500 (EST)
Date: Mon, 6 Feb 2012 12:21:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120206172139.GA26583@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
	<1328289625.7388.38.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328289625.7388.38.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F300CC9.00D0,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 05:20:25PM +0000, Wei Liu wrote:
> On Fri, 2012-02-03 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:18PM +0000, Wei Liu wrote:
> > > 
> > 
> > So this does the job but with this patch you introduce a compile bisection
> > bug, which is a not good. The way around is that in this patch you also
> > introduce temporary scaffolding so that the drivers can build. Something
> > as simple as an function that calls the new version, but has the right
> > arguments. Then the next patch (the one that actually does change
> > the backends, will back that wrapper out).
> > 
> 
> How about squashing these two patches. The changes in backends are
> trivial.


One thing I forgot to mention is that since the backends touch different
subsystems maintainers tree - you will need to get Acks from all of them
on a single patch. That should not be an technical issue - except that some
maintainers can take longer to respond - so your whole patchset might
be delayed by that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:30:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17: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.xensource.com>)
	id 1RuSOh-0000J0-Cf; Mon, 06 Feb 2012 17:30:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RuSOg-0000Ip-7d
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:30:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328549428!13848215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16668 invoked from network); 6 Feb 2012 17:30:28 -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 Feb 2012 17:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,372,1325462400"; d="scan'208";a="10525758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 17:30:28 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Feb 2012
	17:30:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120206172139.GA26583@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
	<1328289625.7388.38.camel@leeds.uk.xensource.com>
	<20120206172139.GA26583@phenom.dumpdata.com>
Date: Mon, 6 Feb 2012 17:30:57 +0000
Message-ID: <1328549457.17324.20.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 17:21 +0000, Konrad Rzeszutek Wilk wrote:
> One thing I forgot to mention is that since the backends touch different
> subsystems maintainers tree - you will need to get Acks from all of them
> on a single patch. That should not be an technical issue - except that some
> maintainers can take longer to respond - so your whole patchset might
> be delayed by that.

Sure, that's not a big problem.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:30:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17: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.xensource.com>)
	id 1RuSOh-0000J0-Cf; Mon, 06 Feb 2012 17:30:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RuSOg-0000Ip-7d
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:30:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328549428!13848215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzU5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16668 invoked from network); 6 Feb 2012 17:30:28 -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 Feb 2012 17:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,372,1325462400"; d="scan'208";a="10525758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 17:30:28 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Feb 2012
	17:30:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120206172139.GA26583@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-9-git-send-email-wei.liu2@citrix.com>
	<20120203165516.GA20005@phenom.dumpdata.com>
	<1328289625.7388.38.camel@leeds.uk.xensource.com>
	<20120206172139.GA26583@phenom.dumpdata.com>
Date: Mon, 6 Feb 2012 17:30:57 +0000
Message-ID: <1328549457.17324.20.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 08/13] xenbus_client: extend
 interface to support mapping / unmapping of multi page ring.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 17:21 +0000, Konrad Rzeszutek Wilk wrote:
> One thing I forgot to mention is that since the backends touch different
> subsystems maintainers tree - you will need to get Acks from all of them
> on a single patch. That should not be an technical issue - except that some
> maintainers can take longer to respond - so your whole patchset might
> be delayed by that.

Sure, that's not a big problem.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:36:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSUR-0000Tm-6E; Mon, 06 Feb 2012 17:36:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RuSUP-0000TZ-AJ
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:36:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328549781!12168277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjExNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15641 invoked from network); 6 Feb 2012 17:36:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 17:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,372,1325480400"; d="scan'208";a="21676452"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 12:36:20 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Feb 2012
	12:36:20 -0500
Message-ID: <4F300F93.3020404@citrix.com>
Date: Mon, 6 Feb 2012 17:36:19 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
	<20120203211836.GD78380@ocelot.phlegethon.org>
In-Reply-To: <20120203211836.GD78380@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial
 page tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 03/02/12 21:18, Tim Deegan wrote:
> At 19:15 +0000 on 03 Feb (1328296512), David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Add a 1:1 mapping for the device tree blob in the initial page tables.
>> This will allow the DTB to be parsed for memory information prior to
>> setting up the real page tables.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  xen/arch/arm/head.S |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
>> index 9951f37..8385481 100644
>> --- a/xen/arch/arm/head.S
>> +++ b/xen/arch/arm/head.S
>> @@ -202,6 +202,11 @@ hyp:
>>  	add   r4, r4, #8
>>  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>>  #endif
>> +	mov   r3, #0x0
>> +	orr   r2, r8, #0xe00
>> +	orr   r2, r2, #0x07d
>> +	mov   r4, r8, lsr #18        /* Slot for (r8 == atag_paddr) */
>> +	strd  r2, r3, [r1, r4]       /* Map DTB there */
> 
> It might be better to map the DTB at a fixed VA (say, the next
> second-level slot up from the fixmap one) so we don't have to worry
> about the DTB's PA clashing with Xen's VAs.

That was already used in setup_pagetables() to relocate Xen but since
the two uses don't overlap they can share the same slot.  Not 100% sure
on the TLB flush after updating the L2 PTE -- it makes it work but is it
sufficient/optimal?

8<-------
arm: map device tree blob in initial page tables

Add a mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

It is mapped into the first L2 slot after the fixmap.  When this slot
is reused in setup_pagetables(), flush the TLB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/head.S          |    7 +++++++
 xen/arch/arm/mm.c            |    5 +++--
 xen/include/asm-arm/config.h |    6 ++++++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 3c1f624..f1a81b3 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -201,6 +201,13 @@ hyp:
         add   r4, r4, #8
         strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #endif
+        mov   r3, #0x0
+        lsr   r2, r8, #21
+        lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+        orr   r2, r2, #0xf00
+        orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+        add   r4, r4, #8
+        strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */

         PRINT("- Turning on paging -\r\n")

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..0599102 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -161,10 +161,11 @@ void __init setup_pagetables(unsigned long
boot_phys_offset)

     xen_paddr = XEN_PADDR;

-    /* Map the destination in the empty L2 above the fixmap */
-    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    /* Map the destination in the boot misc area. */
+    dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
     write_pte(xen_second + second_table_offset(dest_va), pte);
+    flush_xen_data_tlb();

     /* Calculate virt-to-phys offset for the new location */
     phys_offset = xen_paddr - (unsigned long) _start;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 12285dd..8546a50 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -52,15 +52,21 @@
  *  0  -   2M   Unmapped
  *  2M -   4M   Xen text, data, bss
  *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *  6M  -  8M   Early boot misc (see below)
  *
  * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  *
  *  1G -   2G   Xenheap: always-mapped memory
  *  2G -   4G   Domheap: on-demand-mapped
+ *
+ * The early boot misc area is used:
+ *   - in head.S for the DTB for device_tree_early_init().
+ *   - 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

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:36:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSUR-0000Tm-6E; Mon, 06 Feb 2012 17:36:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RuSUP-0000TZ-AJ
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:36:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328549781!12168277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjExNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15641 invoked from network); 6 Feb 2012 17:36:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2012 17:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,372,1325480400"; d="scan'208";a="21676452"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 12:36:20 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Feb 2012
	12:36:20 -0500
Message-ID: <4F300F93.3020404@citrix.com>
Date: Mon, 6 Feb 2012 17:36:19 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
	<20120203211836.GD78380@ocelot.phlegethon.org>
In-Reply-To: <20120203211836.GD78380@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial
 page tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 03/02/12 21:18, Tim Deegan wrote:
> At 19:15 +0000 on 03 Feb (1328296512), David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Add a 1:1 mapping for the device tree blob in the initial page tables.
>> This will allow the DTB to be parsed for memory information prior to
>> setting up the real page tables.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>>  xen/arch/arm/head.S |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
>> index 9951f37..8385481 100644
>> --- a/xen/arch/arm/head.S
>> +++ b/xen/arch/arm/head.S
>> @@ -202,6 +202,11 @@ hyp:
>>  	add   r4, r4, #8
>>  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>>  #endif
>> +	mov   r3, #0x0
>> +	orr   r2, r8, #0xe00
>> +	orr   r2, r2, #0x07d
>> +	mov   r4, r8, lsr #18        /* Slot for (r8 == atag_paddr) */
>> +	strd  r2, r3, [r1, r4]       /* Map DTB there */
> 
> It might be better to map the DTB at a fixed VA (say, the next
> second-level slot up from the fixmap one) so we don't have to worry
> about the DTB's PA clashing with Xen's VAs.

That was already used in setup_pagetables() to relocate Xen but since
the two uses don't overlap they can share the same slot.  Not 100% sure
on the TLB flush after updating the L2 PTE -- it makes it work but is it
sufficient/optimal?

8<-------
arm: map device tree blob in initial page tables

Add a mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

It is mapped into the first L2 slot after the fixmap.  When this slot
is reused in setup_pagetables(), flush the TLB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/head.S          |    7 +++++++
 xen/arch/arm/mm.c            |    5 +++--
 xen/include/asm-arm/config.h |    6 ++++++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 3c1f624..f1a81b3 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -201,6 +201,13 @@ hyp:
         add   r4, r4, #8
         strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #endif
+        mov   r3, #0x0
+        lsr   r2, r8, #21
+        lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+        orr   r2, r2, #0xf00
+        orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+        add   r4, r4, #8
+        strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */

         PRINT("- Turning on paging -\r\n")

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..0599102 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -161,10 +161,11 @@ void __init setup_pagetables(unsigned long
boot_phys_offset)

     xen_paddr = XEN_PADDR;

-    /* Map the destination in the empty L2 above the fixmap */
-    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    /* Map the destination in the boot misc area. */
+    dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
     write_pte(xen_second + second_table_offset(dest_va), pte);
+    flush_xen_data_tlb();

     /* Calculate virt-to-phys offset for the new location */
     phys_offset = xen_paddr - (unsigned long) _start;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 12285dd..8546a50 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -52,15 +52,21 @@
  *  0  -   2M   Unmapped
  *  2M -   4M   Xen text, data, bss
  *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *  6M  -  8M   Early boot misc (see below)
  *
  * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  *
  *  1G -   2G   Xenheap: always-mapped memory
  *  2G -   4G   Domheap: on-demand-mapped
+ *
+ * The early boot misc area is used:
+ *   - in head.S for the DTB for device_tree_early_init().
+ *   - 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

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:40:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17: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.xensource.com>)
	id 1RuSYH-0000bw-Sh; Mon, 06 Feb 2012 17:40:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RuSYG-0000bc-Nn
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:40:29 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328550019!10320457!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8670 invoked from network); 6 Feb 2012 17:40:21 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.14)
	by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Feb 2012 17:40:21 -0000
Received: from mail166-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 17:40:19 +0000
Received: from mail166-tx2 (localhost [127.0.0.1])	by
	mail166-tx2-R.bigfish.com (Postfix) with ESMTP id 1F6A2340342;
	Mon,  6 Feb 2012 17:40:19 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail166-tx2 (localhost.localdomain [127.0.0.1]) by mail166-tx2
	(MessageSwitch) id 1328550011802451_4957;
	Mon,  6 Feb 2012 17:40:11 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.247])	by
	mail166-tx2.bigfish.com (Postfix) with ESMTP id B34663C0047;
	Mon,  6 Feb 2012 17:40:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 17:40:07 +0000
X-WSS-ID: 0LYZFQT-01-CWD-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 222781028037;	Mon,  6 Feb 2012 11:40:04 -0600 (CST)
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, 6 Feb 2012 11:40:09 -0600
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.289.1;
	Mon, 6 Feb 2012 11:40:04 -0600
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, 6 Feb 2012
	12:40:03 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 336CE49C65D; Mon,  6 Feb 2012
	17:40:02 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 26E092D202B; Mon,
	6 Feb 2012 18:40:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
Message-ID: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 6 Feb 2012 18:39:25 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1328549858 -3600
# Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r 3cf8ffd0ab88 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Feb 06 18:37:38 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Mon Feb 06 18:37:38 2012 +0100
@@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+static DEFINE_SPINLOCK(osvw_lock);
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    spin_lock(&osvw_lock);
+
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+
+    spin_unlock(&osvw_lock);   
+}
+
+void svm_host_osvw_init()
+{
+    spin_lock(&osvw_lock);
+
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length = osvw_status = 0;
+
+    spin_unlock(&osvw_lock);
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Mon Feb 06 18:37:38 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+        ret = microcode_ops->start_update();
+        if ( ret != 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Mon Feb 06 18:37:38 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -71,6 +72,7 @@ struct mpbhdr {
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
 
+/* See comment in start_update() for cases when this routine fails */
 static int collect_cpu_info(int cpu, struct cpu_signature *csig)
 {
     struct cpuinfo_x86 *c = &cpu_data[cpu];
@@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } 
+    else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +406,28 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    /*
+     * We assume here that svm_host_osvw_init() will be called on each cpu (from
+     * cpu_request_microcode()). 
+     *
+     * Note that if collect_cpu_info() returns an error then
+     * cpu_request_microcode() will not invoked thus leaving OSVW bits not
+     * updated. Currently though collect_cpu_info() will not fail on processors
+     * supporting OSVW so we will not deal with this possibility.
+     */
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Mon Feb 06 18:37:38 2012 +0100
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /* 
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/common/domctl.c
--- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/common/domctl.c	Mon Feb 06 18:37:38 2012 +0100
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
+        /* 
+         * Certain operations (e.g. CPU microcode updates) modify data which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                goto maxvcpu_out_novcpulock;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = 0;
 
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
+
+    maxvcpu_out_novcpulock:
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Mon Feb 06 18:37:38 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Mon Feb 06 18:37:38 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Mon Feb 06 18:37:38 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/xen/domain.h
--- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/xen/domain.h	Mon Feb 06 18:37:38 2012 +0100
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
 
 void arch_vcpu_reset(struct vcpu *v);
 
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:40:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17: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.xensource.com>)
	id 1RuSYH-0000bw-Sh; Mon, 06 Feb 2012 17:40:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RuSYG-0000bc-Nn
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:40:29 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328550019!10320457!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8670 invoked from network); 6 Feb 2012 17:40:21 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.14)
	by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Feb 2012 17:40:21 -0000
Received: from mail166-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 17:40:19 +0000
Received: from mail166-tx2 (localhost [127.0.0.1])	by
	mail166-tx2-R.bigfish.com (Postfix) with ESMTP id 1F6A2340342;
	Mon,  6 Feb 2012 17:40:19 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail166-tx2 (localhost.localdomain [127.0.0.1]) by mail166-tx2
	(MessageSwitch) id 1328550011802451_4957;
	Mon,  6 Feb 2012 17:40:11 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.247])	by
	mail166-tx2.bigfish.com (Postfix) with ESMTP id B34663C0047;
	Mon,  6 Feb 2012 17:40:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 17:40:07 +0000
X-WSS-ID: 0LYZFQT-01-CWD-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 222781028037;	Mon,  6 Feb 2012 11:40:04 -0600 (CST)
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, 6 Feb 2012 11:40:09 -0600
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.289.1;
	Mon, 6 Feb 2012 11:40:04 -0600
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, 6 Feb 2012
	12:40:03 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 336CE49C65D; Mon,  6 Feb 2012
	17:40:02 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 26E092D202B; Mon,
	6 Feb 2012 18:40:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
Message-ID: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 6 Feb 2012 18:39:25 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1328549858 -3600
# Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r 3cf8ffd0ab88 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Feb 06 18:37:38 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Mon Feb 06 18:37:38 2012 +0100
@@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+static DEFINE_SPINLOCK(osvw_lock);
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    spin_lock(&osvw_lock);
+
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+
+    spin_unlock(&osvw_lock);   
+}
+
+void svm_host_osvw_init()
+{
+    spin_lock(&osvw_lock);
+
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length = osvw_status = 0;
+
+    spin_unlock(&osvw_lock);
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Mon Feb 06 18:37:38 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+        ret = microcode_ops->start_update();
+        if ( ret != 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Mon Feb 06 18:37:38 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -71,6 +72,7 @@ struct mpbhdr {
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
 
+/* See comment in start_update() for cases when this routine fails */
 static int collect_cpu_info(int cpu, struct cpu_signature *csig)
 {
     struct cpuinfo_x86 *c = &cpu_data[cpu];
@@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } 
+    else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +406,28 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    /*
+     * We assume here that svm_host_osvw_init() will be called on each cpu (from
+     * cpu_request_microcode()). 
+     *
+     * Note that if collect_cpu_info() returns an error then
+     * cpu_request_microcode() will not invoked thus leaving OSVW bits not
+     * updated. Currently though collect_cpu_info() will not fail on processors
+     * supporting OSVW so we will not deal with this possibility.
+     */
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Mon Feb 06 18:37:38 2012 +0100
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /* 
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/common/domctl.c
--- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/common/domctl.c	Mon Feb 06 18:37:38 2012 +0100
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
+        /* 
+         * Certain operations (e.g. CPU microcode updates) modify data which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                goto maxvcpu_out_novcpulock;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = 0;
 
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
+
+    maxvcpu_out_novcpulock:
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Mon Feb 06 18:37:38 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Mon Feb 06 18:37:38 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Mon Feb 06 18:37:38 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {
diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/xen/domain.h
--- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/xen/domain.h	Mon Feb 06 18:37:38 2012 +0100
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
 
 void arch_vcpu_reset(struct vcpu *v);
 
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSiH-0000zF-Ow; Mon, 06 Feb 2012 17:50:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuSiF-0000z3-GH
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:50:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328550636!11665161!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 953 invoked from network); 6 Feb 2012 17:50:40 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2012 17:50:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16HoWLs024034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:50:33 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
	q16HoVi3003727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:50:31 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
	q16HoUjQ029530; Mon, 6 Feb 2012 11:50:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 09:50:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D4E2A40435; Mon,  6 Feb 2012 12:47:45 -0500 (EST)
Date: Mon, 6 Feb 2012 12:47:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <20120206174745.GA14324@phenom.dumpdata.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F3012E9.008E,ss=1,re=-2.300,fgs=0
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1328549858 -3600
> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> x86/AMD: Add support for AMD's OSVW feature in guests.
> 
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> going to idle in order to avoid getting stuck in a non-C0 state. This is not

What about fixing the Linux guest to actually not do this? I presume you
have encountered this with HVM guests - would it be possible to use

set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ??


> necessary: HLT and IO instructions are intercepted and therefore there is no
> reason for erratum 400 workaround in the guest.
> 
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 tools/libxc/xc_cpuid_x86.c
> --- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +                    bitmaskof(X86_FEATURE_OSVW) |
>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/hvm/svm/svm.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
>  
>  static bool_t amd_erratum383_found __read_mostly;
>  
> +/* OSVW bits */
> +static uint64_t osvw_length, osvw_status;
> +static DEFINE_SPINLOCK(osvw_lock);
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
>      reset_stack_and_jump(svm_asm_do_resume);
>  }
>  
> +static void svm_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return;
> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
> +    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 298
> +     * is present (because we really don't know).
> +     */
> +    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
> +        vcpu->arch.hvm_svm.osvw.status |= 1;
> +}
> +
> +void svm_host_osvw_reset()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
> +    osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);   
> +}
> +
> +void svm_host_osvw_init()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    /* 
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
> +    {
> +        uint64_t len, status;
> +         
> +        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
> +            len = status = 0;
> +
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +    }
> +    else
> +        osvw_length = osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);
> +}
> +
>  static int svm_domain_initialise(struct domain *d)
>  {
>      return 0;
> @@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
>      }
>  
>      vpmu_initialise(v);
> +
> +    svm_guest_osvw_init(v);
> +
>      return 0;
>  }
>  
> @@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct 
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
> +{
> +    uint eax, ebx, ecx, edx;
> +     
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
> +        return -1;
> +
> +    if ( read )
> +    {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.hvm_svm.osvw.length;
> +        else
> +            *val = v->arch.hvm_svm.osvw.status;
> +    } 
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> @@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
>      }
>  #endif
>  
> +    /* Initialize OSVW bits to be used by guests */
> +    svm_host_osvw_init();
> +
>      return 0;
>  }
>  
> @@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
>      if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
>          return NULL;
>  
> +    svm_host_osvw_reset();
> +
>      if ( svm_cpu_up() )
>      {
>          printk("SVM: failed to initialise.\n");
> @@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
>          vpmu_do_rdmsr(msr, msr_content);
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, msr_content, 1);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_rdmsr(v, msr, msr_content);
>          if ( ret < 0 )
> @@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
>           */
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, &msr_content, 0);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_wrmsr(v, msr, msr_content);
>          if ( ret < 0 )
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode.c
> --- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +        ret = microcode_ops->start_update();
> +        if ( ret != 0 )
> +        {
> +            xfree(info);
> +            return ret;
> +        }
> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode_amd.c
> --- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode_amd.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -25,6 +25,7 @@
>  #include <asm/msr.h>
>  #include <asm/processor.h>
>  #include <asm/microcode.h>
> +#include <asm/hvm/svm/svm.h>
>  
>  struct equiv_cpu_entry {
>      uint32_t installed_cpu;
> @@ -71,6 +72,7 @@ struct mpbhdr {
>  /* serialize access to the physical write */
>  static DEFINE_SPINLOCK(microcode_update_lock);
>  
> +/* See comment in start_update() for cases when this routine fails */
>  static int collect_cpu_info(int cpu, struct cpu_signature *csig)
>  {
>      struct cpuinfo_x86 *c = &cpu_data[cpu];
> @@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! Wrong "
>                 "microcode patch file magic\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_amd = xmalloc(struct microcode_amd);
> @@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! "
>                 "Can not allocate memory for microcode patch\n");
> -        return -ENOMEM;
> +        error = -ENOMEM;
> +        goto out;
>      }
>  
>      error = install_equiv_cpu_table(mc_amd, buf, &offset);
> @@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
>      {
>          xfree(mc_amd);
>          printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_old = uci->mc.mc_amd;
> @@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    } 
> +    else 
> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> @@ -395,11 +406,28 @@ err1:
>      return -ENOMEM;
>  }
>  
> +static int start_update(void) 
> +{
> +    /*
> +     * We assume here that svm_host_osvw_init() will be called on each cpu (from
> +     * cpu_request_microcode()). 
> +     *
> +     * Note that if collect_cpu_info() returns an error then
> +     * cpu_request_microcode() will not invoked thus leaving OSVW bits not
> +     * updated. Currently though collect_cpu_info() will not fail on processors
> +     * supporting OSVW so we will not deal with this possibility.
> +     */
> +    svm_host_osvw_reset();
> +
> +    return 0;
> +}
> +
>  static const struct microcode_ops microcode_amd_ops = {
>      .microcode_resume_match           = microcode_resume_match,
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
> +    .start_update                     = start_update,
>  };
>  
>  static __init int microcode_init_amd(void)
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/platform_hypercall.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        /* 
> +         * alloc_vpcu() will access data which is modified during
> +         * microcode update
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        spin_unlock(&vcpu_alloc_lock);
>      }
>      break;
>  
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/common/domctl.c
> --- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/common/domctl.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -29,6 +29,7 @@
>  #include <xsm/xsm.h>
>  
>  static DEFINE_SPINLOCK(domctl_lock);
> +DEFINE_SPINLOCK(vcpu_alloc_lock);
>  
>  int cpumask_to_xenctl_cpumap(
>      struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> @@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /* 
> +         * Certain operations (e.g. CPU microcode updates) modify data which is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                goto maxvcpu_out_novcpulock;
> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> @@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          ret = 0;
>  
>      maxvcpu_out:
> +        spin_unlock(&vcpu_alloc_lock);
> +
> +    maxvcpu_out_novcpulock:
>          domain_unpause(d);
>          rcu_unlock_domain(d);
>      }
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/svm.h
> --- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/svm.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
>                                    ~TSC_RATIO_RSVD_BITS )
>  #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
>  
> +extern void svm_host_osvw_reset(void);
> +extern void svm_host_osvw_init(void);
> +
>  #endif /* __ASM_X86_HVM_SVM_H__ */
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/vmcb.h
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -516,6 +516,12 @@ struct arch_svm_struct {
>      
>      /* AMD lightweight profiling MSR */
>      uint64_t guest_lwp_cfg;
> +
> +    /* OSVW MSRs */
> +    struct {
> +        u64 length;
> +        u64 status;
> +    } osvw;
>  };
>  
>  struct vmcb_struct *alloc_vmcb(void);
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/microcode.h
> --- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/microcode.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -11,6 +11,7 @@ struct microcode_ops {
>      int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
>      int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
>      int (*apply_microcode)(int cpu);
> +    int (*start_update)(void);
>  };
>  
>  struct cpu_signature {
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/xen/domain.h
> --- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/xen/domain.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
>  
>  void arch_vcpu_reset(struct vcpu *v);
>  
> +extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSiH-0000zF-Ow; Mon, 06 Feb 2012 17:50:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuSiF-0000z3-GH
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:50:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328550636!11665161!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 953 invoked from network); 6 Feb 2012 17:50:40 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2012 17:50:40 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16HoWLs024034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 17:50:33 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
	q16HoVi3003727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 17:50:31 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
	q16HoUjQ029530; Mon, 6 Feb 2012 11:50:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 09:50:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D4E2A40435; Mon,  6 Feb 2012 12:47:45 -0500 (EST)
Date: Mon, 6 Feb 2012 12:47:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <20120206174745.GA14324@phenom.dumpdata.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F3012E9.008E,ss=1,re=-2.300,fgs=0
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1328549858 -3600
> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> x86/AMD: Add support for AMD's OSVW feature in guests.
> 
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> going to idle in order to avoid getting stuck in a non-C0 state. This is not

What about fixing the Linux guest to actually not do this? I presume you
have encountered this with HVM guests - would it be possible to use

set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ??


> necessary: HLT and IO instructions are intercepted and therefore there is no
> reason for erratum 400 workaround in the guest.
> 
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 tools/libxc/xc_cpuid_x86.c
> --- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +                    bitmaskof(X86_FEATURE_OSVW) |
>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/hvm/svm/svm.c
> --- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/hvm/svm/svm.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
>  
>  static bool_t amd_erratum383_found __read_mostly;
>  
> +/* OSVW bits */
> +static uint64_t osvw_length, osvw_status;
> +static DEFINE_SPINLOCK(osvw_lock);
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
>      reset_stack_and_jump(svm_asm_do_resume);
>  }
>  
> +static void svm_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return;
> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
> +    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 298
> +     * is present (because we really don't know).
> +     */
> +    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
> +        vcpu->arch.hvm_svm.osvw.status |= 1;
> +}
> +
> +void svm_host_osvw_reset()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
> +    osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);   
> +}
> +
> +void svm_host_osvw_init()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    /* 
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
> +    {
> +        uint64_t len, status;
> +         
> +        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
> +            len = status = 0;
> +
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +    }
> +    else
> +        osvw_length = osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);
> +}
> +
>  static int svm_domain_initialise(struct domain *d)
>  {
>      return 0;
> @@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
>      }
>  
>      vpmu_initialise(v);
> +
> +    svm_guest_osvw_init(v);
> +
>      return 0;
>  }
>  
> @@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct 
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
> +{
> +    uint eax, ebx, ecx, edx;
> +     
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
> +        return -1;
> +
> +    if ( read )
> +    {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.hvm_svm.osvw.length;
> +        else
> +            *val = v->arch.hvm_svm.osvw.status;
> +    } 
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> @@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
>      }
>  #endif
>  
> +    /* Initialize OSVW bits to be used by guests */
> +    svm_host_osvw_init();
> +
>      return 0;
>  }
>  
> @@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
>      if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
>          return NULL;
>  
> +    svm_host_osvw_reset();
> +
>      if ( svm_cpu_up() )
>      {
>          printk("SVM: failed to initialise.\n");
> @@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
>          vpmu_do_rdmsr(msr, msr_content);
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, msr_content, 1);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_rdmsr(v, msr, msr_content);
>          if ( ret < 0 )
> @@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
>           */
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, &msr_content, 0);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_wrmsr(v, msr, msr_content);
>          if ( ret < 0 )
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode.c
> --- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +        ret = microcode_ops->start_update();
> +        if ( ret != 0 )
> +        {
> +            xfree(info);
> +            return ret;
> +        }
> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/microcode_amd.c
> --- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode_amd.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -25,6 +25,7 @@
>  #include <asm/msr.h>
>  #include <asm/processor.h>
>  #include <asm/microcode.h>
> +#include <asm/hvm/svm/svm.h>
>  
>  struct equiv_cpu_entry {
>      uint32_t installed_cpu;
> @@ -71,6 +72,7 @@ struct mpbhdr {
>  /* serialize access to the physical write */
>  static DEFINE_SPINLOCK(microcode_update_lock);
>  
> +/* See comment in start_update() for cases when this routine fails */
>  static int collect_cpu_info(int cpu, struct cpu_signature *csig)
>  {
>      struct cpuinfo_x86 *c = &cpu_data[cpu];
> @@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! Wrong "
>                 "microcode patch file magic\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_amd = xmalloc(struct microcode_amd);
> @@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! "
>                 "Can not allocate memory for microcode patch\n");
> -        return -ENOMEM;
> +        error = -ENOMEM;
> +        goto out;
>      }
>  
>      error = install_equiv_cpu_table(mc_amd, buf, &offset);
> @@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
>      {
>          xfree(mc_amd);
>          printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_old = uci->mc.mc_amd;
> @@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    } 
> +    else 
> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> @@ -395,11 +406,28 @@ err1:
>      return -ENOMEM;
>  }
>  
> +static int start_update(void) 
> +{
> +    /*
> +     * We assume here that svm_host_osvw_init() will be called on each cpu (from
> +     * cpu_request_microcode()). 
> +     *
> +     * Note that if collect_cpu_info() returns an error then
> +     * cpu_request_microcode() will not invoked thus leaving OSVW bits not
> +     * updated. Currently though collect_cpu_info() will not fail on processors
> +     * supporting OSVW so we will not deal with this possibility.
> +     */
> +    svm_host_osvw_reset();
> +
> +    return 0;
> +}
> +
>  static const struct microcode_ops microcode_amd_ops = {
>      .microcode_resume_match           = microcode_resume_match,
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
> +    .start_update                     = start_update,
>  };
>  
>  static __init int microcode_init_amd(void)
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/platform_hypercall.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        /* 
> +         * alloc_vpcu() will access data which is modified during
> +         * microcode update
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        spin_unlock(&vcpu_alloc_lock);
>      }
>      break;
>  
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/common/domctl.c
> --- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/common/domctl.c	Mon Feb 06 18:37:38 2012 +0100
> @@ -29,6 +29,7 @@
>  #include <xsm/xsm.h>
>  
>  static DEFINE_SPINLOCK(domctl_lock);
> +DEFINE_SPINLOCK(vcpu_alloc_lock);
>  
>  int cpumask_to_xenctl_cpumap(
>      struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> @@ -502,6 +503,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /* 
> +         * Certain operations (e.g. CPU microcode updates) modify data which is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                goto maxvcpu_out_novcpulock;
> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> @@ -551,6 +564,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          ret = 0;
>  
>      maxvcpu_out:
> +        spin_unlock(&vcpu_alloc_lock);
> +
> +    maxvcpu_out_novcpulock:
>          domain_unpause(d);
>          rcu_unlock_domain(d);
>      }
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/svm.h
> --- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/svm.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
>                                    ~TSC_RATIO_RSVD_BITS )
>  #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
>  
> +extern void svm_host_osvw_reset(void);
> +extern void svm_host_osvw_init(void);
> +
>  #endif /* __ASM_X86_HVM_SVM_H__ */
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/hvm/svm/vmcb.h
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -516,6 +516,12 @@ struct arch_svm_struct {
>      
>      /* AMD lightweight profiling MSR */
>      uint64_t guest_lwp_cfg;
> +
> +    /* OSVW MSRs */
> +    struct {
> +        u64 length;
> +        u64 status;
> +    } osvw;
>  };
>  
>  struct vmcb_struct *alloc_vmcb(void);
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/asm-x86/microcode.h
> --- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/microcode.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -11,6 +11,7 @@ struct microcode_ops {
>      int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
>      int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
>      int (*apply_microcode)(int cpu);
> +    int (*start_update)(void);
>  };
>  
>  struct cpu_signature {
> diff -r e2722b24dc09 -r 3cf8ffd0ab88 xen/include/xen/domain.h
> --- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/xen/domain.h	Mon Feb 06 18:37:38 2012 +0100
> @@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
>  
>  void arch_vcpu_reset(struct vcpu *v);
>  
> +extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:58:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSpJ-0001A4-Nw; Mon, 06 Feb 2012 17:58:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RuSpI-00019y-Tn
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:58:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328551078!13380799!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDIyOTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22576 invoked from network); 6 Feb 2012 17:57:58 -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; 6 Feb 2012 17:57:58 -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 CAE912C24;
	Mon,  6 Feb 2012 19:57:55 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 71F4B20058; Mon,  6 Feb 2012 19:57:55 +0200 (EET)
Date: Mon, 6 Feb 2012 19:57:55 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120206175755.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
	<20120106153714.GA21220@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120106153714.GA21220@andromeda.dapyr.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Wei Huang <wei.huang2@amd.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 11:37:14AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> > On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
> > >On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> > >>>>Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > >>>>must haves e.g. in the paging/sharing spaces?
> > >>>>
> > >>>- What's the status of Nested Hardware Virtualization?
> > >>>I remember some email saying Intel vmx-on-vmx has some performance 
> > >>>issues,
> > >>>and amd svm-on-svm works better..
> > >>>
> > >>>
> > >>>- Also there's a bunch of VGA passthru related patches,
> > >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> > >>>but I still haven't had time for that :(
> > >>Since there were quite a lot of interest on this subject, should we
> > >>document it in a separate wiki for working combinations (like
> > >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> > >>
> > >I actually once started writing down that kind of stuff:
> > >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> > >
> > >Feel free to contribute :)
> > >
> > >There's also:
> > >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> > Thanks for sharing. I will contribute my findings as needed. BTW, do you 
> > need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 
> 
> Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> guest and it works nicely.. the first time. After I shut down the guest
> it just never works again :-(
> 

Hmm.. I wonder if this would work:

cd /sys/bus/pci/devices/0000:01:05.0
sudo sh -c "echo 1 > rom"
sudo sh -c "cat rom > ~/bios.rom"


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 17:58:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 17:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSpJ-0001A4-Nw; Mon, 06 Feb 2012 17:58:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RuSpI-00019y-Tn
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 17:58:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328551078!13380799!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDIyOTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22576 invoked from network); 6 Feb 2012 17:57:58 -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; 6 Feb 2012 17:57:58 -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 CAE912C24;
	Mon,  6 Feb 2012 19:57:55 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 71F4B20058; Mon,  6 Feb 2012 19:57:55 +0200 (EET)
Date: Mon, 6 Feb 2012 19:57:55 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120206175755.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
	<20120106153714.GA21220@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120106153714.GA21220@andromeda.dapyr.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Wei Huang <wei.huang2@amd.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 11:37:14AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> > On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
> > >On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> > >>>>Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > >>>>must haves e.g. in the paging/sharing spaces?
> > >>>>
> > >>>- What's the status of Nested Hardware Virtualization?
> > >>>I remember some email saying Intel vmx-on-vmx has some performance 
> > >>>issues,
> > >>>and amd svm-on-svm works better..
> > >>>
> > >>>
> > >>>- Also there's a bunch of VGA passthru related patches,
> > >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> > >>>but I still haven't had time for that :(
> > >>Since there were quite a lot of interest on this subject, should we
> > >>document it in a separate wiki for working combinations (like
> > >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> > >>
> > >I actually once started writing down that kind of stuff:
> > >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> > >
> > >Feel free to contribute :)
> > >
> > >There's also:
> > >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> > Thanks for sharing. I will contribute my findings as needed. BTW, do you 
> > need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 
> 
> Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> guest and it works nicely.. the first time. After I shut down the guest
> it just never works again :-(
> 

Hmm.. I wonder if this would work:

cd /sys/bus/pci/devices/0000:01:05.0
sudo sh -c "echo 1 > rom"
sudo sh -c "cat rom > ~/bios.rom"


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 18:01:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 18:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSsH-0001Jb-B3; Mon, 06 Feb 2012 18:01:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuSsG-0001JS-0H
	for Xen-devel@lists.xensource.com; Mon, 06 Feb 2012 18:01:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328551260!14175208!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMyNDUy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3421 invoked from network); 6 Feb 2012 18:01:01 -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; 6 Feb 2012 18:01:01 -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 q16I0vAC014580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 18:00: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
	q16I0uDu024257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 18:00:57 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
	q16I0u7x012988; Mon, 6 Feb 2012 12:00:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 10:00:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D3AB40435; Mon,  6 Feb 2012 12:58:12 -0500 (EST)
Date: Mon, 6 Feb 2012 12:58:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Message-ID: <20120206175812.GB14439@phenom.dumpdata.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F30155B.007A,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
 xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
> Hi,
> 
> I see in pcifront_init, if domain is not PV domain, pcifront_init just
> returns error. So seems HVM domain does not support
> xen-pcifront/xen-pciback mechanism? If it is true, why? I think

Yup. B/c the only thing that the PV PCI protocol does is enable
PCI configuration emulation. And if you boot an HVM guest - QEMU does
that already.

> technically there's nothing that can block to support pcifront/pciback
> in HVM, and for performance reason, there will be benefits if HVM
> supports PV PCI operation.

Nope. The PCI operations are just for writting configuration deta in the
PCI space. Whcih is done mostly when a driver starts/stops and no more.

The performance is with interrupts and how to inject them in a guest - and
in there the PV is much faster than HVM due to the emulation layer complexity.
However, work by Stefano on making that path shorter has made the interrupt
injection much much faster.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 18:01:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 18:01:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuSsH-0001Jb-B3; Mon, 06 Feb 2012 18:01:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuSsG-0001JS-0H
	for Xen-devel@lists.xensource.com; Mon, 06 Feb 2012 18:01:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328551260!14175208!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMyNDUy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3421 invoked from network); 6 Feb 2012 18:01:01 -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; 6 Feb 2012 18:01:01 -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 q16I0vAC014580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 18:00: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
	q16I0uDu024257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 18:00:57 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
	q16I0u7x012988; Mon, 6 Feb 2012 12:00:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 10:00:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D3AB40435; Mon,  6 Feb 2012 12:58:12 -0500 (EST)
Date: Mon, 6 Feb 2012 12:58:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Message-ID: <20120206175812.GB14439@phenom.dumpdata.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F30155B.007A,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
 xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
> Hi,
> 
> I see in pcifront_init, if domain is not PV domain, pcifront_init just
> returns error. So seems HVM domain does not support
> xen-pcifront/xen-pciback mechanism? If it is true, why? I think

Yup. B/c the only thing that the PV PCI protocol does is enable
PCI configuration emulation. And if you boot an HVM guest - QEMU does
that already.

> technically there's nothing that can block to support pcifront/pciback
> in HVM, and for performance reason, there will be benefits if HVM
> supports PV PCI operation.

Nope. The PCI operations are just for writting configuration deta in the
PCI space. Whcih is done mostly when a driver starts/stops and no more.

The performance is with interrupts and how to inject them in a guest - and
in there the PV is much faster than HVM due to the emulation layer complexity.
However, work by Stefano on making that path shorter has made the interrupt
injection much much faster.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 18:10:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 18:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuT1F-0001X4-Cf; Mon, 06 Feb 2012 18:10: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 1RuT1D-0001Wz-My
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 18:10:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328551773!61739787!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23778 invoked from network); 6 Feb 2012 18:09:35 -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; 6 Feb 2012 18:09:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16IAJCV018455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 18:10: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
	q16IAIHQ012495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 18:10:18 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
	q16IAIsN012460; Mon, 6 Feb 2012 12:10:18 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 10:10:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CA28740435; Mon,  6 Feb 2012 13:07:33 -0500 (EST)
Date: Mon, 6 Feb 2012 13:07:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120206180733.GA25234@phenom.dumpdata.com>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F30178C.0112,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 04:09:55PM +0400, Vasiliy Tolstov wrote:
> Hello. I'm try to run domU kernel from backports.debian.org under 32
> bit guest (686-pae), but after sometime i get error in dmesg:
> 
> http://cdn.selfip.ru/hang.png
> 
> in guest loaded only xen-netfront.ko module.
> 
> What does it mean?

It means it is stuck waiting for a change.
What is your Xen/dom0? IT could be that it is missing some patch?
Did you try the xen-unstable and Linux v3.2?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 18:10:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 18:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuT1F-0001X4-Cf; Mon, 06 Feb 2012 18:10: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 1RuT1D-0001Wz-My
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 18:10:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328551773!61739787!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23778 invoked from network); 6 Feb 2012 18:09:35 -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; 6 Feb 2012 18:09:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16IAJCV018455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 18:10: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
	q16IAIHQ012495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 18:10:18 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
	q16IAIsN012460; Mon, 6 Feb 2012 12:10:18 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 10:10:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CA28740435; Mon,  6 Feb 2012 13:07:33 -0500 (EST)
Date: Mon, 6 Feb 2012 13:07:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120206180733.GA25234@phenom.dumpdata.com>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F30178C.0112,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 04:09:55PM +0400, Vasiliy Tolstov wrote:
> Hello. I'm try to run domU kernel from backports.debian.org under 32
> bit guest (686-pae), but after sometime i get error in dmesg:
> 
> http://cdn.selfip.ru/hang.png
> 
> in guest loaded only xen-netfront.ko module.
> 
> What does it mean?

It means it is stuck waiting for a change.
What is your Xen/dom0? IT could be that it is missing some patch?
Did you try the xen-unstable and Linux v3.2?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 18:45:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 18:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuTYP-0001w6-N8; Mon, 06 Feb 2012 18:44:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RuTYN-0001w1-Ah
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 18:44:39 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328553872!15542645!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30264 invoked from network); 6 Feb 2012 18:44:33 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Feb 2012 18:44:33 -0000
Received: from mail60-ch1-R.bigfish.com (10.43.68.235) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 18:44:32 +0000
Received: from mail60-ch1 (localhost [127.0.0.1])	by mail60-ch1-R.bigfish.com
	(Postfix) with ESMTP id 83FBB3C04AB;
	Mon,  6 Feb 2012 18:44:31 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1444M1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail60-ch1 (localhost.localdomain [127.0.0.1]) by mail60-ch1
	(MessageSwitch) id 1328553870290309_1320;
	Mon,  6 Feb 2012 18:44:30 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.229])	by mail60-ch1.bigfish.com (Postfix) with ESMTP id
	423294C0046;	Mon,  6 Feb 2012 18:44:30 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 18:44:30 +0000
X-WSS-ID: 0LYZIQ4-01-H9R-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 24A0F102802E;	Mon,  6 Feb 2012 12:44:28 -0600 (CST)
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;
	Mon, 6 Feb 2012 12:44:33 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Feb 2012
	12:44:28 -0600
Message-ID: <4F301F8B.5010306@amd.com>
Date: Mon, 6 Feb 2012 13:44:27 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
In-Reply-To: <20120206174745.GA14324@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # Date 1328549858 -3600
>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>>
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
>
> What about fixing the Linux guest to actually not do this? I presume you
> have encountered this with HVM guests - would it be possible to use
>
> set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ??


Changing Linux won't help guests running Linux prior to the change so we 
still need this patch. And with the patch guest's pm_idle will be set to 
default_idle anyway (because cpu_has_amd_erratum(amd_erratum_400) will 
return 0).


-boris

>
>
>> necessary: HLT and IO instructions are intercepted and therefore there is no
>> reason for erratum 400 workaround in the guest.
>>
>> This patch allows us to present a guest with certain errata as fixed,
>> regardless of the state of actual hardware.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 18:45:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 18:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuTYP-0001w6-N8; Mon, 06 Feb 2012 18:44:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RuTYN-0001w1-Ah
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 18:44:39 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328553872!15542645!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30264 invoked from network); 6 Feb 2012 18:44:33 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Feb 2012 18:44:33 -0000
Received: from mail60-ch1-R.bigfish.com (10.43.68.235) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 18:44:32 +0000
Received: from mail60-ch1 (localhost [127.0.0.1])	by mail60-ch1-R.bigfish.com
	(Postfix) with ESMTP id 83FBB3C04AB;
	Mon,  6 Feb 2012 18:44:31 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1444M1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail60-ch1 (localhost.localdomain [127.0.0.1]) by mail60-ch1
	(MessageSwitch) id 1328553870290309_1320;
	Mon,  6 Feb 2012 18:44:30 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.229])	by mail60-ch1.bigfish.com (Postfix) with ESMTP id
	423294C0046;	Mon,  6 Feb 2012 18:44:30 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server id
	14.1.225.23; Mon, 6 Feb 2012 18:44:30 +0000
X-WSS-ID: 0LYZIQ4-01-H9R-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 24A0F102802E;	Mon,  6 Feb 2012 12:44:28 -0600 (CST)
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;
	Mon, 6 Feb 2012 12:44:33 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Feb 2012
	12:44:28 -0600
Message-ID: <4F301F8B.5010306@amd.com>
Date: Mon, 6 Feb 2012 13:44:27 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
In-Reply-To: <20120206174745.GA14324@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # Date 1328549858 -3600
>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>>
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
>
> What about fixing the Linux guest to actually not do this? I presume you
> have encountered this with HVM guests - would it be possible to use
>
> set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ??


Changing Linux won't help guests running Linux prior to the change so we 
still need this patch. And with the patch guest's pm_idle will be set to 
default_idle anyway (because cpu_has_amd_erratum(amd_erratum_400) will 
return 0).


-boris

>
>
>> necessary: HLT and IO instructions are intercepted and therefore there is no
>> reason for erratum 400 workaround in the guest.
>>
>> This patch allows us to present a guest with certain errata as fixed,
>> regardless of the state of actual hardware.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 19:06:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 19:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuTsm-0002LS-7n; Mon, 06 Feb 2012 19:05:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RuTsj-0002LN-NW
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:05:41 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328555110!58702541!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12209 invoked from network); 6 Feb 2012 19:05:10 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-13.tower-27.messagelabs.com with SMTP;
	6 Feb 2012 19:05:10 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q16J5dRh014278
	for <xen-devel@lists.xensource.com>;
	Mon, 6 Feb 2012 14:05:39 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q16J5deJ004408;
	Mon, 6 Feb 2012 14:05:39 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020614053828902 ; Mon, 06 Feb 2012 14:05:38 -0500
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Mon, 6 Feb 2012 14:05:39 -0500
To: xen-devel@lists.xensource.com
Message-Id: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen Developers,

FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set but not used warning for variable 'message' in function init_kbdfront. (Looks like another one just like it, in function init_fbfront, from the same file.) My source won't compile with these warnings. I could not find a patch for this in xen-4.1-testing.hg Xenbits.

It looks like a conditional printk got left out after the label 'abort_transaction'. I don't understand fbfront.c well enough to suggest a patch. Its low priority for me, because I am going to stick some plausible code in there for now.

Sincerely,

John
----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 19:06:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 19:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuTsm-0002LS-7n; Mon, 06 Feb 2012 19:05:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RuTsj-0002LN-NW
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 19:05:41 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328555110!58702541!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12209 invoked from network); 6 Feb 2012 19:05:10 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-13.tower-27.messagelabs.com with SMTP;
	6 Feb 2012 19:05:10 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q16J5dRh014278
	for <xen-devel@lists.xensource.com>;
	Mon, 6 Feb 2012 14:05:39 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q16J5deJ004408;
	Mon, 6 Feb 2012 14:05:39 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020614053828902 ; Mon, 06 Feb 2012 14:05:38 -0500
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Mon, 6 Feb 2012 14:05:39 -0500
To: xen-devel@lists.xensource.com
Message-Id: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen Developers,

FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set but not used warning for variable 'message' in function init_kbdfront. (Looks like another one just like it, in function init_fbfront, from the same file.) My source won't compile with these warnings. I could not find a patch for this in xen-4.1-testing.hg Xenbits.

It looks like a conditional printk got left out after the label 'abort_transaction'. I don't understand fbfront.c well enough to suggest a patch. Its low priority for me, because I am going to stick some plausible code in there for now.

Sincerely,

John
----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 22:38:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 22: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.xensource.com>)
	id 1RuXBc-0004Z9-4Z; Mon, 06 Feb 2012 22:37:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuXBa-0004Z4-45
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 22:37:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328567835!12227962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzgwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11851 invoked from network); 6 Feb 2012 22:37:15 -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;
	6 Feb 2012 22:37:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,373,1325462400"; d="scan'208";a="10530639"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 22:37:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 6 Feb 2012 22:37:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RuXBR-0000ik-Se;
	Mon, 06 Feb 2012 22:37:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RuXBR-000462-7D;
	Mon, 06 Feb 2012 22:37:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11893-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 6 Feb 2012 22:37:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11893: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11893 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11893/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11892

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  158f9c38d95c
baseline version:
 xen                  3432abcf9380

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=158f9c38d95c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 158f9c38d95c
+ branch=xen-unstable
+ revision=158f9c38d95c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 158f9c38d95c 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 5 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 22:38:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 22: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.xensource.com>)
	id 1RuXBc-0004Z9-4Z; Mon, 06 Feb 2012 22:37:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuXBa-0004Z4-45
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 22:37:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328567835!12227962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzgwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11851 invoked from network); 6 Feb 2012 22:37:15 -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;
	6 Feb 2012 22:37:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,373,1325462400"; d="scan'208";a="10530639"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2012 22:37:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 6 Feb 2012 22:37:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RuXBR-0000ik-Se;
	Mon, 06 Feb 2012 22:37:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RuXBR-000462-7D;
	Mon, 06 Feb 2012 22:37:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11893-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 6 Feb 2012 22:37:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11893: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11893 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11893/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11892

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  158f9c38d95c
baseline version:
 xen                  3432abcf9380

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=158f9c38d95c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 158f9c38d95c
+ branch=xen-unstable
+ revision=158f9c38d95c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 158f9c38d95c 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 5 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 23:11:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 23: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.xensource.com>)
	id 1RuXiO-00050E-A7; Mon, 06 Feb 2012 23:11:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuXiM-000509-Ig
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 23:11:14 +0000
Received: from [193.109.254.147:48486] by server-5.bemta-14.messagelabs.com id
	23/70-05697-11E503F4; Mon, 06 Feb 2012 23:11:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328569821!51630233!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM0MDMz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29085 invoked from network); 6 Feb 2012 23:10:23 -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; 6 Feb 2012 23:10:23 -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 q16NB7mR028340
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 23:11:09 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
	q16NB6wp014418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 23:11:06 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q16NB5EL031969; Mon, 6 Feb 2012 17:11:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 15:11:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D24D040435; Mon,  6 Feb 2012 18:08:20 -0500 (EST)
Date: Mon, 6 Feb 2012 18:08:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <20120206230820.GA8636@phenom.dumpdata.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
	<4F301F8B.5010306@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F301F8B.5010306@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F305E0D.0115,ss=1,re=0.000,fgs=0
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 01:44:27PM -0500, Boris Ostrovsky wrote:
> On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote:
> >On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
> >># HG changeset patch
> >># User Boris Ostrovsky<boris.ostrovsky@amd.com>
> >># Date 1328549858 -3600
> >># Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> >># Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> >>x86/AMD: Add support for AMD's OSVW feature in guests.
> >>
> >>In some cases guests should not provide workarounds for errata even when the
> >>physical processor is affected. For example, because of erratum 400 on family
> >>10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> >>going to idle in order to avoid getting stuck in a non-C0 state. This is not
> >
> >What about fixing the Linux guest to actually not do this? I presume you
> >have encountered this with HVM guests - would it be possible to use
> >
> >set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ??
> 
> 
> Changing Linux won't help guests running Linux prior to the change
> so we still need this patch. And with the patch guest's pm_idle will

Well, it can go on the stable tree.

> be set to default_idle anyway (because
> cpu_has_amd_erratum(amd_erratum_400) will return 0).

Right, but that won't be called anymore to set the pm_idle b/c pm_idle is set
to default_idle.


> 
> 
> -boris
> 
> >
> >
> >>necessary: HLT and IO instructions are intercepted and therefore there is no
> >>reason for erratum 400 workaround in the guest.
> >>
> >>This patch allows us to present a guest with certain errata as fixed,
> >>regardless of the state of actual hardware.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 06 23:11:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 06 Feb 2012 23: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.xensource.com>)
	id 1RuXiO-00050E-A7; Mon, 06 Feb 2012 23:11:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuXiM-000509-Ig
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 23:11:14 +0000
Received: from [193.109.254.147:48486] by server-5.bemta-14.messagelabs.com id
	23/70-05697-11E503F4; Mon, 06 Feb 2012 23:11:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328569821!51630233!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM0MDMz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29085 invoked from network); 6 Feb 2012 23:10:23 -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; 6 Feb 2012 23:10:23 -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 q16NB7mR028340
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 6 Feb 2012 23:11:09 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
	q16NB6wp014418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 6 Feb 2012 23:11:06 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q16NB5EL031969; Mon, 6 Feb 2012 17:11:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 15:11:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D24D040435; Mon,  6 Feb 2012 18:08:20 -0500 (EST)
Date: Mon, 6 Feb 2012 18:08:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <20120206230820.GA8636@phenom.dumpdata.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
	<4F301F8B.5010306@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F301F8B.5010306@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F305E0D.0115,ss=1,re=0.000,fgs=0
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 01:44:27PM -0500, Boris Ostrovsky wrote:
> On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote:
> >On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
> >># HG changeset patch
> >># User Boris Ostrovsky<boris.ostrovsky@amd.com>
> >># Date 1328549858 -3600
> >># Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> >># Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> >>x86/AMD: Add support for AMD's OSVW feature in guests.
> >>
> >>In some cases guests should not provide workarounds for errata even when the
> >>physical processor is affected. For example, because of erratum 400 on family
> >>10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> >>going to idle in order to avoid getting stuck in a non-C0 state. This is not
> >
> >What about fixing the Linux guest to actually not do this? I presume you
> >have encountered this with HVM guests - would it be possible to use
> >
> >set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 'xen_hvm_guest_init' ??
> 
> 
> Changing Linux won't help guests running Linux prior to the change
> so we still need this patch. And with the patch guest's pm_idle will

Well, it can go on the stable tree.

> be set to default_idle anyway (because
> cpu_has_amd_erratum(amd_erratum_400) will return 0).

Right, but that won't be called anymore to set the pm_idle b/c pm_idle is set
to default_idle.


> 
> 
> -boris
> 
> >
> >
> >>necessary: HLT and IO instructions are intercepted and therefore there is no
> >>reason for erratum 400 workaround in the guest.
> >>
> >>This patch allows us to present a guest with certain errata as fixed,
> >>regardless of the state of actual hardware.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 00:22:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 00:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuYp9-0006sg-C3; Tue, 07 Feb 2012 00:22:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RuYp8-0006sb-4g
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 00:22:18 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328574090!59025728!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 7 Feb 2012 00:21:31 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 00:21:31 -0000
Received: by qcsp15 with SMTP id p15so33262302qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 16:22:13 -0800 (PST)
Received: by 10.229.76.76 with SMTP id b12mr7910601qck.81.1328574132950;
	Mon, 06 Feb 2012 16:22:12 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id o8sm24097153qan.11.2012.02.06.16.22.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 06 Feb 2012 16:22:12 -0800 (PST)
Date: Mon, 6 Feb 2012 19:22:10 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <20120207002210.GB24133@morn.localdomain>
References: <7f3ce6824f2e05447621fddc1d50eeceb676f365.1328417416.git.julian.pidancet@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7f3ce6824f2e05447621fddc1d50eeceb676f365.1328417416.git.julian.pidancet@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: seabios@seabios.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] Xen: Use VGA Hooks to make VGA
 passthrough work on certain devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 05, 2012 at 04:51:06AM +0000, Julian Pidancet wrote:
> The Intel gfx VGA option ROM on certain platforms requires the 155f50 BIOS
> function to be implemented (even if it does nothing), to work properly.
> 
> v2: Ignore the case where Option ROMs are pre-deployed.
>     Make vgahook_setup independent of wether the CB* variables are set.
>     VGA hooks can be enabled on non-coreboot and non-Xen configurations.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Thanks - I've applied this patch.

-Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 00:22:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 00:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuYp9-0006sg-C3; Tue, 07 Feb 2012 00:22:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RuYp8-0006sb-4g
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 00:22:18 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328574090!59025728!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 7 Feb 2012 00:21:31 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 00:21:31 -0000
Received: by qcsp15 with SMTP id p15so33262302qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 16:22:13 -0800 (PST)
Received: by 10.229.76.76 with SMTP id b12mr7910601qck.81.1328574132950;
	Mon, 06 Feb 2012 16:22:12 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id o8sm24097153qan.11.2012.02.06.16.22.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 06 Feb 2012 16:22:12 -0800 (PST)
Date: Mon, 6 Feb 2012 19:22:10 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <20120207002210.GB24133@morn.localdomain>
References: <7f3ce6824f2e05447621fddc1d50eeceb676f365.1328417416.git.julian.pidancet@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7f3ce6824f2e05447621fddc1d50eeceb676f365.1328417416.git.julian.pidancet@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: seabios@seabios.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] Xen: Use VGA Hooks to make VGA
 passthrough work on certain devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 05, 2012 at 04:51:06AM +0000, Julian Pidancet wrote:
> The Intel gfx VGA option ROM on certain platforms requires the 155f50 BIOS
> function to be implemented (even if it does nothing), to work properly.
> 
> v2: Ignore the case where Option ROMs are pre-deployed.
>     Make vgahook_setup independent of wether the CB* variables are set.
>     VGA hooks can be enabled on non-coreboot and non-Xen configurations.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Thanks - I've applied this patch.

-Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 02:27:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 02:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruam3-0003bw-D0; Tue, 07 Feb 2012 02:27:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Ruam2-0003bn-HE
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 02:27:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328581627!4806826!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNTY1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15112 invoked from network); 7 Feb 2012 02:27:08 -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; 7 Feb 2012 02:27:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q172R0ob004058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 02:27:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q172QwIc006497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 02:26:59 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q172QwfD004463; Mon, 6 Feb 2012 20:26:58 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 18:26:57 -0800
Date: Mon, 6 Feb 2012 18:26:54 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>, Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120206182654.5b5d3f2d@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F308BF5.003A,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Hi all,

I am figuring io access for hybrid guests, dom0 and domU. I see that there
are two ways: PV -> emulate_privileged_op(), or hvm handles via 
handle_mmio()/handle_pio(). I am not familiar with either one, and would
help me lot if anybody expert in that can suggest which way 
hybrid should go, both dom0 and domU. Any suggestions would help. If
there are any docs on this, that would be great too.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 02:27:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 02:27:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruam3-0003bw-D0; Tue, 07 Feb 2012 02:27:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1Ruam2-0003bn-HE
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 02:27:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328581627!4806826!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNTY1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15112 invoked from network); 7 Feb 2012 02:27:08 -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; 7 Feb 2012 02:27:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q172R0ob004058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 02:27:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q172QwIc006497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 02:26:59 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q172QwfD004463; Mon, 6 Feb 2012 20:26:58 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 18:26:57 -0800
Date: Mon, 6 Feb 2012 18:26:54 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>, Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120206182654.5b5d3f2d@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F308BF5.003A,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Hi all,

I am figuring io access for hybrid guests, dom0 and domU. I see that there
are two ways: PV -> emulate_privileged_op(), or hvm handles via 
handle_mmio()/handle_pio(). I am not familiar with either one, and would
help me lot if anybody expert in that can suggest which way 
hybrid should go, both dom0 and domU. Any suggestions would help. If
there are any docs on this, that would be great too.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 03:42:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 03: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.xensource.com>)
	id 1Rubw9-0004F3-2h; Tue, 07 Feb 2012 03:41:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rubw7-0004Ey-Pj
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 03:41:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328586096!10334443!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18816 invoked from network); 7 Feb 2012 03:41:37 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 03:41:37 -0000
Received: by iaeh11 with SMTP id h11so55938251iae.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 19:41:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SflEZfH3W1Opy7UMJUNiTj8RtDModHtkqTOuJXi3aUQ=;
	b=qjX5U8fbuM1v41hyXc83ezfGwJ0cFh+AXYhrxkMjiplxgTxYsYCf+sc1VrWaEH49l0
	LFqqZqE3hq2r9FUHcS8xQslbugS4nn3qpiPRyidbR+iRV4oKm3D4oCoVG4AwoZCXtWCL
	mXo6D4pVT5cVP6L2wB1rrnmKVP6uKHsHqCzrI=
Received: by 10.50.202.97 with SMTP id kh1mr24505392igc.19.1328586096274;
	Mon, 06 Feb 2012 19:41:36 -0800 (PST)
Received: from [101.1.150.12] ([96.49.152.177])
	by mx.google.com with ESMTPS id x18sm30730724ibi.2.2012.02.06.19.41.31
	(version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 19:41:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 06 Feb 2012 19:41:23 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <CB55DD63.2A883%keir.xen@gmail.com>
Thread-Topic: [help]: handling IO instructions for hybrid
Thread-Index: AczlSlyN8Jm9iU2wtkeYSfIDxSFbhQ==
In-Reply-To: <20120206182654.5b5d3f2d@mantra.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 02:26, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> 
> Hi all,
> 
> I am figuring io access for hybrid guests, dom0 and domU. I see that there
> are two ways: PV -> emulate_privileged_op(), or hvm handles via
> handle_mmio()/handle_pio(). I am not familiar with either one, and would
> help me lot if anybody expert in that can suggest which way
> hybrid should go, both dom0 and domU. Any suggestions would help. If
> there are any docs on this, that would be great too.

Probably the PV route, for dom0 and domU. Really most things you want to do,
the PV route is going to be the right way (unless you are PVHVM'ing certain
things, e.g., like using EPT assistance for pagetable handling).

 -- Keir

> thanks,
> Mukesh
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 03:42:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 03: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.xensource.com>)
	id 1Rubw9-0004F3-2h; Tue, 07 Feb 2012 03:41:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rubw7-0004Ey-Pj
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 03:41:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328586096!10334443!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18816 invoked from network); 7 Feb 2012 03:41:37 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 03:41:37 -0000
Received: by iaeh11 with SMTP id h11so55938251iae.30
	for <Xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 19:41:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SflEZfH3W1Opy7UMJUNiTj8RtDModHtkqTOuJXi3aUQ=;
	b=qjX5U8fbuM1v41hyXc83ezfGwJ0cFh+AXYhrxkMjiplxgTxYsYCf+sc1VrWaEH49l0
	LFqqZqE3hq2r9FUHcS8xQslbugS4nn3qpiPRyidbR+iRV4oKm3D4oCoVG4AwoZCXtWCL
	mXo6D4pVT5cVP6L2wB1rrnmKVP6uKHsHqCzrI=
Received: by 10.50.202.97 with SMTP id kh1mr24505392igc.19.1328586096274;
	Mon, 06 Feb 2012 19:41:36 -0800 (PST)
Received: from [101.1.150.12] ([96.49.152.177])
	by mx.google.com with ESMTPS id x18sm30730724ibi.2.2012.02.06.19.41.31
	(version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 19:41:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 06 Feb 2012 19:41:23 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <CB55DD63.2A883%keir.xen@gmail.com>
Thread-Topic: [help]: handling IO instructions for hybrid
Thread-Index: AczlSlyN8Jm9iU2wtkeYSfIDxSFbhQ==
In-Reply-To: <20120206182654.5b5d3f2d@mantra.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 02:26, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> 
> Hi all,
> 
> I am figuring io access for hybrid guests, dom0 and domU. I see that there
> are two ways: PV -> emulate_privileged_op(), or hvm handles via
> handle_mmio()/handle_pio(). I am not familiar with either one, and would
> help me lot if anybody expert in that can suggest which way
> hybrid should go, both dom0 and domU. Any suggestions would help. If
> there are any docs on this, that would be great too.

Probably the PV route, for dom0 and domU. Really most things you want to do,
the PV route is going to be the right way (unless you are PVHVM'ing certain
things, e.g., like using EPT assistance for pagetable handling).

 -- Keir

> thanks,
> Mukesh
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 03:54:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 03:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruc89-0004ZP-BI; Tue, 07 Feb 2012 03:54:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Ruc87-0004ZK-6H
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 03:54:07 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328586838!10417927!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDQ2MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 7 Feb 2012 03:53:59 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-15.tower-174.messagelabs.com with SMTP;
	7 Feb 2012 03:53:59 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ0001B985XBG@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:53:57 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ000FVO85WV4@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:53:57 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW74959; Tue,
	07 Feb 2012 11:53:55 +0800
Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154)
	by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 11:53:17 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml415-hub.china.huawei.com ([10.82.67.154])
	with mapi id 14.01.0323.003; Tue, 07 Feb 2012 11:54:01 +0800
Date: Tue, 07 Feb 2012 03:53:38 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F3011D102000078000716A0@nat28.tlf.novell.com>
X-Originating-IP: [10.166.82.189]
To: Jan Beulich <JBeulich@suse.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD2D1@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: AQHM5K5cuI98LdezHEiIL1QuiGFaEZYvu20w///SroCAAT9xMA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: BGwb BP97 CTPs D9dk EfLC HlWd I/Vh JcSt K/y3 Mo4l NouR OmHq
	PD8H Pcww WL57 W1JR; 3;
	YQBuAGQAcgBlAHMAQABsAGEAZwBhAHIAYwBhAHYAaQBsAGwAYQAuAG8AcgBnADsAagBiAGUAdQBsAGkAYwBoAEAAcwB1AHMAZQAuAGMAbwBtADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {7D0539CC-6696-44AF-8FB6-6976AA1D2707};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue,
	07 Feb 2012 03:53:33 GMT;
	UgBFADoAIABbAFgAZQBuAC0AZABlAHYAZQBsAF0AIABbAFAAQQBUAEMASABdACAAZwByAGEAbgB0ACAAdABhAGIAbABlACAAbQBhAHAAIABlAHIAcgBvAHIAIABpAG4AIABfAF8AZwBuAHQAdABhAGIAXwBtAGEAcABfAGcAcgBhAG4AdABfAHIAZQBmAA==
x-cr-puzzleid: {7D0539CC-6696-44AF-8FB6-6976AA1D2707}
X-CFilter-Loop: Reflected
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
	<4F3011D102000078000716A0@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, February 07, 2012 12:46 AM
> To: Liuyongan
> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
> Cavilla; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] grant table map error in
> __gnttab_map_grant_ref
> 
> >>> On 06.02.12 at 12:38, Liuyongan <liuyongan@huawei.com> wrote:
> 
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Monday, February 06, 2012 5:03 PM
> >> To: Liuyongan
> >> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
> >> Cavilla; xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] [PATCH] grant table map error in
> >> __gnttab_map_grant_ref
> >>
> >>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
> >> > In file grant_table.c function __gnttab_map_grant_ref, if
> >> __get_paged_frame
> >> > failed, the effect of _set_status  previously called should be
> >> rollback, so
> >> > the flag GTF_reading and _GTF_writing will be recovered.
> >>
> >> Not knowing too much about these, but isn't
> __acquire_grant_for_copy()
> >> in need of a similar adjustment?
> >   Well, I need to check it further.

   The caller of __acquire_grant_for_copy() will make sure similar rollback
by calling __release_grant_for_copy().

> >>
> >> Further, aren't the status flags cumulative (and hence isn't it
> wrong
> >> to
> >> simply clear flags without considering their original state)?
> >   When undo_out branch is executed, the flag set by _set_status
> function
> >   will be rolled back by:
> >        if ( !(op->flags & GNTMAP_readonly) &&
> >          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> >         gnttab_clear_flag(_GTF_writing, status);
> >
> >        if ( !act->pin )
> >         gnttab_clear_flag(_GTF_reading, status);
> >   so action added by this patch should be correct.
> 
> But this is not a roll-back, here the flags get simply cleared (whereas
> "roll-back" to me means the restoration of their previous value).

  According to my analysis, flag will be cleared only if it is set previously 
in _set_status() of this function.
> 
> >   And anyway, the  reading and writing flag should be recovered when
> mapping
> >   grant reference failed, so the up layer(eg. Netback driver) can
> decide
> >   freely whether retry mapping or fail directly.
> 
> Those flags, afaiu, are managed by Xen, so the layer issuing the
> mapping operation shouldn't be concerned.
> 
> Jan
> 
> >> (I realize
> >> that this is not a new issue introduced with the proposed patch, but
> >> certainly with more ways of getting that code path run through, it
> >> becomes more important for it to be correct.)
> >>
> >> Jan
> >>
> >> > Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
> >> > Wang<hzwangliang.wang@huawei.com>
> >> >
> >> > diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> >> > --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13
> >> 2012 +0800
> >> > +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02
> >> 2012 +0800
> >> > @@ -566,7 +566,7 @@
> >> >              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
> >> >              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
> >> > GNTMAP_readonly), rd);
> >> >              if ( rc != GNTST_okay )
> >> > -                goto unlock_out;
> >> > +                goto unlock_out_clear;
> >> >              act->gfn = gfn;
> >> >              act->domid = ld->domain_id;
> >> >              act->frame = frame;
> >> > @@ -721,7 +721,8 @@
> >> >      if ( op->flags & GNTMAP_host_map )
> >> >          act->pin -= (op->flags & GNTMAP_readonly) ?
> >> >              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> >> > -
> >> > +
> >> > + unlock_out_clear:
> >> >      if ( !(op->flags & GNTMAP_readonly) &&
> >> >           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> >> >          gnttab_clear_flag(_GTF_writing, status);
> >>
> >>
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 03:54:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 03:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruc89-0004ZP-BI; Tue, 07 Feb 2012 03:54:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Ruc87-0004ZK-6H
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 03:54:07 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328586838!10417927!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMDQ2MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 7 Feb 2012 03:53:59 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-15.tower-174.messagelabs.com with SMTP;
	7 Feb 2012 03:53:59 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ0001B985XBG@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:53:57 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ000FVO85WV4@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:53:57 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW74959; Tue,
	07 Feb 2012 11:53:55 +0800
Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154)
	by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 11:53:17 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.38])
	by szxeml415-hub.china.huawei.com ([10.82.67.154])
	with mapi id 14.01.0323.003; Tue, 07 Feb 2012 11:54:01 +0800
Date: Tue, 07 Feb 2012 03:53:38 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F3011D102000078000716A0@nat28.tlf.novell.com>
X-Originating-IP: [10.166.82.189]
To: Jan Beulich <JBeulich@suse.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD2D1@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
Thread-index: AQHM5K5cuI98LdezHEiIL1QuiGFaEZYvu20w///SroCAAT9xMA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: BGwb BP97 CTPs D9dk EfLC HlWd I/Vh JcSt K/y3 Mo4l NouR OmHq
	PD8H Pcww WL57 W1JR; 3;
	YQBuAGQAcgBlAHMAQABsAGEAZwBhAHIAYwBhAHYAaQBsAGwAYQAuAG8AcgBnADsAagBiAGUAdQBsAGkAYwBoAEAAcwB1AHMAZQAuAGMAbwBtADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {7D0539CC-6696-44AF-8FB6-6976AA1D2707};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue,
	07 Feb 2012 03:53:33 GMT;
	UgBFADoAIABbAFgAZQBuAC0AZABlAHYAZQBsAF0AIABbAFAAQQBUAEMASABdACAAZwByAGEAbgB0ACAAdABhAGIAbABlACAAbQBhAHAAIABlAHIAcgBvAHIAIABpAG4AIABfAF8AZwBuAHQAdABhAGIAXwBtAGEAcABfAGcAcgBhAG4AdABfAHIAZQBmAA==
x-cr-puzzleid: {7D0539CC-6696-44AF-8FB6-6976AA1D2707}
X-CFilter-Loop: Reflected
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
	<4F3011D102000078000716A0@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
	__gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, February 07, 2012 12:46 AM
> To: Liuyongan
> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
> Cavilla; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] grant table map error in
> __gnttab_map_grant_ref
> 
> >>> On 06.02.12 at 12:38, Liuyongan <liuyongan@huawei.com> wrote:
> 
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Monday, February 06, 2012 5:03 PM
> >> To: Liuyongan
> >> Cc: hanweidong; Zhanghaoyu; Wang Liang; Qianhuibin; Andres Lagar-
> >> Cavilla; xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] [PATCH] grant table map error in
> >> __gnttab_map_grant_ref
> >>
> >>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
> >> > In file grant_table.c function __gnttab_map_grant_ref, if
> >> __get_paged_frame
> >> > failed, the effect of _set_status  previously called should be
> >> rollback, so
> >> > the flag GTF_reading and _GTF_writing will be recovered.
> >>
> >> Not knowing too much about these, but isn't
> __acquire_grant_for_copy()
> >> in need of a similar adjustment?
> >   Well, I need to check it further.

   The caller of __acquire_grant_for_copy() will make sure similar rollback
by calling __release_grant_for_copy().

> >>
> >> Further, aren't the status flags cumulative (and hence isn't it
> wrong
> >> to
> >> simply clear flags without considering their original state)?
> >   When undo_out branch is executed, the flag set by _set_status
> function
> >   will be rolled back by:
> >        if ( !(op->flags & GNTMAP_readonly) &&
> >          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> >         gnttab_clear_flag(_GTF_writing, status);
> >
> >        if ( !act->pin )
> >         gnttab_clear_flag(_GTF_reading, status);
> >   so action added by this patch should be correct.
> 
> But this is not a roll-back, here the flags get simply cleared (whereas
> "roll-back" to me means the restoration of their previous value).

  According to my analysis, flag will be cleared only if it is set previously 
in _set_status() of this function.
> 
> >   And anyway, the  reading and writing flag should be recovered when
> mapping
> >   grant reference failed, so the up layer(eg. Netback driver) can
> decide
> >   freely whether retry mapping or fail directly.
> 
> Those flags, afaiu, are managed by Xen, so the layer issuing the
> mapping operation shouldn't be concerned.
> 
> Jan
> 
> >> (I realize
> >> that this is not a new issue introduced with the proposed patch, but
> >> certainly with more ways of getting that code path run through, it
> >> becomes more important for it to be correct.)
> >>
> >> Jan
> >>
> >> > Signed-off-by: Haoyu Zhang<haoyu.zhang@huawei.com>; Liang
> >> > Wang<hzwangliang.wang@huawei.com>
> >> >
> >> > diff -r cbed91e1c878 xen-4.1.2/xen/common/grant_table.c
> >> > --- a/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:36:13
> >> 2012 +0800
> >> > +++ b/xen-4.1.2/xen/common/grant_table.c	Sat Feb 04 18:40:02
> >> 2012 +0800
> >> > @@ -566,7 +566,7 @@
> >> >              gfn = sha1 ? sha1->frame : sha2->full_page.frame;
> >> >              rc = __get_paged_frame(gfn, &frame, !!(op->flags &
> >> > GNTMAP_readonly), rd);
> >> >              if ( rc != GNTST_okay )
> >> > -                goto unlock_out;
> >> > +                goto unlock_out_clear;
> >> >              act->gfn = gfn;
> >> >              act->domid = ld->domain_id;
> >> >              act->frame = frame;
> >> > @@ -721,7 +721,8 @@
> >> >      if ( op->flags & GNTMAP_host_map )
> >> >          act->pin -= (op->flags & GNTMAP_readonly) ?
> >> >              GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> >> > -
> >> > +
> >> > + unlock_out_clear:
> >> >      if ( !(op->flags & GNTMAP_readonly) &&
> >> >           !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> >> >          gnttab_clear_flag(_GTF_writing, status);
> >>
> >>
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 04:35:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 04:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuclH-0005eD-JE; Tue, 07 Feb 2012 04:34:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuclG-0005db-OO
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 04:34:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328589268!13345463!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzgwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9811 invoked from network); 7 Feb 2012 04:34:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 04:34:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,374,1325462400"; d="scan'208";a="10532692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 04:34:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 04:34:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ruckl-0002tc-9p;
	Tue, 07 Feb 2012 04:34:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ruckk-0005a8-Sz;
	Tue, 07 Feb 2012 04:34:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11894-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 7 Feb 2012 04:34:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11894: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11894 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11894/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11893

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3574f4d67843
baseline version:
 xen                  158f9c38d95c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haoyu Zhang <haoyu.zhang@huawei.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liang Wang <hzwangliang.wang@huawei.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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3574f4d67843
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3574f4d67843
+ branch=xen-unstable
+ revision=3574f4d67843
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3574f4d67843 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 33 changes to 29 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 04:35:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 04:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuclH-0005eD-JE; Tue, 07 Feb 2012 04:34:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuclG-0005db-OO
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 04:34:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328589268!13345463!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NzgwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9811 invoked from network); 7 Feb 2012 04:34:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 04:34:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,374,1325462400"; d="scan'208";a="10532692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 04:34:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 04:34:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ruckl-0002tc-9p;
	Tue, 07 Feb 2012 04:34:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ruckk-0005a8-Sz;
	Tue, 07 Feb 2012 04:34:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11894-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 7 Feb 2012 04:34:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11894: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11894 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11894/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11893

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3574f4d67843
baseline version:
 xen                  158f9c38d95c

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Haoyu Zhang <haoyu.zhang@huawei.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liang Wang <hzwangliang.wang@huawei.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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3574f4d67843
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3574f4d67843
+ branch=xen-unstable
+ revision=3574f4d67843
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3574f4d67843 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 33 changes to 29 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 07:03:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 07: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.xensource.com>)
	id 1Ruf4y-0007jI-8s; Tue, 07 Feb 2012 07:03:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ruf4v-0007jB-Bz
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 07:03:02 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328598171!12262588!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25565 invoked from network); 7 Feb 2012 07:02:53 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 07:02:53 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1772m6R027281
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 23:02:49 -0800
Received: by bkcjg15 with SMTP id jg15so190956bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 23:02:47 -0800 (PST)
Received: by 10.204.141.14 with SMTP id k14mr9585040bku.67.1328598167298; Mon,
	06 Feb 2012 23:02:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 6 Feb 2012 23:02:07 -0800 (PST)
In-Reply-To: <98a4f01033786a2fc15b.1328189208@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<98a4f01033786a2fc15b.1328189208@debian.localdomain>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 6 Feb 2012 23:02:07 -0800
Message-ID: <CAP8mzPPqi5zSt_c+SAXOLUjL+DdmyZr7rE8cgfM_08CM3FgJiw@mail.gmail.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 29 RFC] libxl: add hotplug script
 calls for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2085329147652009821=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2085329147652009821==
Content-Type: multipart/alternative; boundary=001517593670cfa32604b85a5de1

--001517593670cfa32604b85a5de1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 2, 2012 at 5:26 AM, Roger Pau Monne <roger.pau@entel.upc.edu>wrote:

> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1328177591 -3600
> # Node ID 98a4f01033786a2fc15b4130897c35f64a676e40
> # Parent  6c2690921fba580dd7dd836da3be484dee049be0
> libxl: add hotplug script calls for Linux
>
> This patchs adds the necessary logic to call hotplug scripts directly
> from libxl. Linux hotplug scritps read most parameters from the caller
> environment (since udev set this parameters automatically). In this
> implementation we fake udev parameters, so no changes are needed to
> the scripts itself.
>
> Currently, the following scripts are called:
>
>  * block: used when disk backend is PHY.
>
>  * blktap: used when disk backend is TAP.
>
>
Sorry if this is a bit dense, but you have been through the code
already ;)
Is there an option to call other scripts other than block/blktap ?
For e.g., if I were to add a backend type DRBD/FOOBAR,
and wish to call script "block-<drbd|foobar>, how do you suggest I
proceed ?
  Start my way from defining new disk backend types and just add
hotplug handlers for these block-* devices and finally expose them as
phy devices to libxl ?

shriram


>  * vif-*: used when adding a network interface and can be manually set
>   by the user.
>
> udev rules descrive more device types, currently the following scripts
> are NOT executed from libxl because I wasn't able to find any support
> for this device types in libxl:
>
>  * vtpm
>
>  * vif2
>
>  * vscsi
>
>  * vif-setup with devices of type tap*
>
> This patch just adds the necessary code, but hotplug scripts are NOT
> called from libxl yet, following patches will disable udev rules and
> use this calls instead.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r 6c2690921fba -r 98a4f0103378 tools/libxl/libxl_linux.c
> --- a/tools/libxl/libxl_linux.c Thu Feb 02 11:10:24 2012 +0100
> +++ b/tools/libxl/libxl_linux.c Thu Feb 02 11:13:11 2012 +0100
> @@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod
>     return 1;
>  }
>
> +/* Hotplug scripts helpers */
> +#if 0
> +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *be_path = libxl__device_backend_path(gc, dev);
> +    flexarray_t *f_env;
> +    int nr = 0;
> +
> +    f_env = flexarray_make(11, 1);
> +    if (!f_env) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "unable to create environment array");
> +        return NULL;
> +    }
> +
> +    flexarray_set(f_env, nr++, "script");
> +    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
> +                               libxl__sprintf(gc, "%s/%s",
> +                                              be_path,
> +                                              "script")));
> +    flexarray_set(f_env, nr++, "XENBUS_TYPE");
> +    flexarray_set(f_env, nr++, (char *)
> +                  libxl__device_kind_to_string(dev->backend_kind));
> +    flexarray_set(f_env, nr++, "XENBUS_PATH");
> +    flexarray_set(f_env, nr++,
> +                  libxl__sprintf(gc, "backend/%s/%u/%d",
> +                  libxl__device_kind_to_string(dev->backend_kind),
> +                  dev->domid, dev->devid));
> +    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
> +    flexarray_set(f_env, nr++, "backend");
> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
> +        flexarray_set(f_env, nr++, "vif");
> +        flexarray_set(f_env, nr++,
> +                      libxl__sprintf(gc, "%s%u.%d",
> +                      libxl__device_kind_to_string(dev->backend_kind),
> +                      dev->domid, dev->devid));
> +    }
> +    flexarray_set(f_env, nr++, NULL);
> +
> +    return (char **) flexarray_contents(f_env);
> +}
> +
>  /* Hotplug scripts caller functions */
>
> +static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
> +                       libxl__hotplug_action action)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *be_path = libxl__device_backend_path(gc, dev);
> +    char *script, *what;
> +    char **args, **env;
> +    int status, nr = 0;
> +    int rc = -1;
> +    flexarray_t *f_args;
> +
> +    script = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path,
> "script"));
> +    if (!script) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
> +                                          be_path);
> +        return -1;
> +    }
> +
> +    env = get_hotplug_env(gc, dev);
> +    if (!env)
> +        return -1;
> +
> +    f_args = flexarray_make(4, 1);
> +    if (!f_args) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments
> array");
> +        return -1;
> +    }
> +
> +    flexarray_set(f_args, nr++, script);
> +    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
> +    flexarray_set(f_args, nr++, "type_if=vif");
> +    flexarray_set(f_args, nr++, NULL);
> +
> +    args = (char **) flexarray_contents(f_args);
> +    what = libxl__sprintf(gc, "%s %s", args[0],
> +                          action == CONNECT ? "connect" : "disconnect");
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +               "Calling hotplug script: %s %s %s",
> +               args[0], args[1], args[2]);
> +    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
> +    if (status) {
> +        rc = -1;
> +        goto out;
> +    }
> +    rc = 0;
> +
> +out:
> +    free(env);
> +    free(args);
> +    return rc;
> +}
> +
> +static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
> +                       libxl__hotplug_action action)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *be_path = libxl__device_backend_path(gc, dev);
> +    char *script, *what;
> +    char **args, **env;
> +    int status, nr = 0;
> +    int rc = -1;
> +    flexarray_t *f_args;
> +
> +    script = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path,
> "script"));
> +    if (!script) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
> +                                          be_path);
> +        return -1;
> +    }
> +
> +    env = get_hotplug_env(gc, dev);
> +    if (!env)
> +        return -1;
> +
> +    f_args = flexarray_make(3, 1);
> +    if (!f_args) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments
> array");
> +        return -1;
> +    }
> +
> +    flexarray_set(f_args, nr++, script);
> +    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
> +    flexarray_set(f_args, nr++, NULL);
> +
> +    args = (char **) flexarray_contents(f_args);
> +    what = libxl__sprintf(gc, "%s %s", args[0],
> +                          action == CONNECT ? "connect" : "disconnect");
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +               "Calling hotplug script: %s %s",
> +               args[0], args[1]);
> +    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
> +    if (status) {
> +        rc = -1;
> +        goto out;
> +    }
> +    rc = 0;
> +
> +out:
> +    free(env);
> +    free(args);
> +    return rc;
> +}
> +#endif /* 0 */
>  int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
>                           libxl__hotplug_action action)
>  {
> -    return 0;
> +    int rc = 0;
> +#if 0
> +    switch (dev->backend_kind) {
> +    case LIBXL__DEVICE_KIND_VIF:
> +        rc = libxl__hotplug_nic(gc, dev, action);
> +        break;
> +    case LIBXL__DEVICE_KIND_VBD:
> +        rc = libxl__hotplug_disk(gc, dev, action);
> +        break;
> +    default:
> +        rc = 0;
> +        break;
> +    }
> +#endif /* 0 */
> +    return rc;
>  }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--001517593670cfa32604b85a5de1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Feb 2, 2012 at 5:26 AM, Roger Pau Monne =
<span dir=3D"ltr">&lt;<a href=3D"mailto:roger.pau@entel.upc.edu">roger.pau@=
entel.upc.edu</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">

# HG changeset patch<br>
# User Roger Pau Monne &lt;<a href=3D"mailto:roger.pau@entel.upc.edu">roger=
.pau@entel.upc.edu</a>&gt;<br>
# Date 1328177591 -3600<br>
# Node ID 98a4f01033786a2fc15b4130897c35f64a676e40<br>
# Parent =A06c2690921fba580dd7dd836da3be484dee049be0<br>
libxl: add hotplug script calls for Linux<br>
<br>
This patchs adds the necessary logic to call hotplug scripts directly<br>
from libxl. Linux hotplug scritps read most parameters from the caller<br>
environment (since udev set this parameters automatically). In this<br>
implementation we fake udev parameters, so no changes are needed to<br>
the scripts itself.<br>
<br>
Currently, the following scripts are called:<br>
<br>
=A0* block: used when disk backend is PHY.<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt =
0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=A0* blktap: used when disk backend is TAP.<br>
<br></blockquote><div><br>Sorry if this is a bit dense, but you have been t=
hrough the code<br>already ;)<br>Is there an option to call other scripts o=
ther than
block/blktap ?<br>For e.g., if I were to add a backend type DRBD/FOOBAR,<br=
>and wish to call script &quot;block-&lt;drbd|foobar&gt;, how do you sugges=
t I<br>proceed ?<br>=A0 Start my way from defining new disk backend types a=
nd just add<br>

hotplug handlers for these block-* devices and finally expose them as<br>ph=
y devices to libxl ?<br><br>shriram<br>=A0
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=A0* vif-*: used when adding a network interface and can be manually set<br=
>
 =A0 by the user.<br>
<br>
udev rules descrive more device types, currently the following scripts<br>
are NOT executed from libxl because I wasn&#39;t able to find any support<b=
r>
for this device types in libxl:<br>
<br>
=A0* vtpm<br>
<br>
=A0* vif2<br>
<br>
=A0* vscsi<br>
<br>
=A0* vif-setup with devices of type tap*<br>
<br>
This patch just adds the necessary code, but hotplug scripts are NOT<br>
called from libxl yet, following patches will disable udev rules and<br>
use this calls instead.<br>
<br>
Signed-off-by: Roger Pau Monne &lt;<a href=3D"mailto:roger.pau@entel.upc.ed=
u">roger.pau@entel.upc.edu</a>&gt;<br>
<br>
diff -r 6c2690921fba -r 98a4f0103378 tools/libxl/libxl_linux.c<br>
--- a/tools/libxl/libxl_linux.c Thu Feb 02 11:10:24 2012 +0100<br>
+++ b/tools/libxl/libxl_linux.c Thu Feb 02 11:13:11 2012 +0100<br>
@@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod<br>
 =A0 =A0 return 1;<br>
=A0}<br>
<br>
+/* Hotplug scripts helpers */<br>
+#if 0<br>
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)<br>
+{<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
+ =A0 =A0char *be_path =3D libxl__device_backend_path(gc, dev);<br>
+ =A0 =A0flexarray_t *f_env;<br>
+ =A0 =A0int nr =3D 0;<br>
+<br>
+ =A0 =A0f_env =3D flexarray_make(11, 1);<br>
+ =A0 =A0if (!f_env) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;unable to create environment ar=
ray&quot;);<br>
+ =A0 =A0 =A0 =A0return NULL;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;script&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__sprint=
f(gc, &quot;%s/%s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0be_path,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0&quot;script&quot;)));<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;XENBUS_TYPE&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++, (char *)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__device_kind_to_string(dev-&gt;b=
ackend_kind));<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;XENBUS_PATH&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc, &quot;backend/%s/%u=
/%d&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__device_kind_to_string(dev-&gt;b=
ackend_kind),<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev-&gt;domid, dev-&gt;devid));<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;XENBUS_BASE_PATH&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;backend&quot;);<br>
+ =A0 =A0if (dev-&gt;backend_kind =3D=3D LIBXL__DEVICE_KIND_VIF) {<br>
+ =A0 =A0 =A0 =A0flexarray_set(f_env, nr++, &quot;vif&quot;);<br>
+ =A0 =A0 =A0 =A0flexarray_set(f_env, nr++,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc, &quot;%s%u.=
%d&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__device_kind_to_string(d=
ev-&gt;backend_kind),<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev-&gt;domid, dev-&gt;devid))=
;<br>
+ =A0 =A0}<br>
+ =A0 =A0flexarray_set(f_env, nr++, NULL);<br>
+<br>
+ =A0 =A0return (char **) flexarray_contents(f_env);<br>
+}<br>
+<br>
=A0/* Hotplug scripts caller functions */<br>
<br>
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__hotplug_action action)=
<br>
+{<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
+ =A0 =A0char *be_path =3D libxl__device_backend_path(gc, dev);<br>
+ =A0 =A0char *script, *what;<br>
+ =A0 =A0char **args, **env;<br>
+ =A0 =A0int status, nr =3D 0;<br>
+ =A0 =A0int rc =3D -1;<br>
+ =A0 =A0flexarray_t *f_args;<br>
+<br>
+ =A0 =A0script =3D libxl__xs_read(gc, XBT_NULL,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc,=
 &quot;%s/%s&quot;, be_path, &quot;script&quot;));<br>
+ =A0 =A0if (!script) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to read scr=
ipt from %s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0be_path);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0env =3D get_hotplug_env(gc, dev);<br>
+ =A0 =A0if (!env)<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0f_args =3D flexarray_make(4, 1);<br>
+ =A0 =A0if (!f_args) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to create a=
rguments array&quot;);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0flexarray_set(f_args, nr++, script);<br>
+ =A0 =A0flexarray_set(f_args, nr++, action =3D=3D CONNECT ? &quot;online&q=
uot; : &quot;offline&quot;);<br>
+ =A0 =A0flexarray_set(f_args, nr++, &quot;type_if=3Dvif&quot;);<br>
+ =A0 =A0flexarray_set(f_args, nr++, NULL);<br>
+<br>
+ =A0 =A0args =3D (char **) flexarray_contents(f_args);<br>
+ =A0 =A0what =3D libxl__sprintf(gc, &quot;%s %s&quot;, args[0],<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0action =3D=3D CONNECT =
? &quot;connect&quot; : &quot;disconnect&quot;);<br>
+ =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;Calling hotplug script: %s %s %s&quot;,=
<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 args[0], args[1], args[2]);<br>
+ =A0 =A0status =3D libxl__forkexec(gc, -1, -1, -1, args[0], args, env, wha=
t);<br>
+ =A0 =A0if (status) {<br>
+ =A0 =A0 =A0 =A0rc =3D -1;<br>
+ =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0}<br>
+ =A0 =A0rc =3D 0;<br>
+<br>
+out:<br>
+ =A0 =A0free(env);<br>
+ =A0 =A0free(args);<br>
+ =A0 =A0return rc;<br>
+}<br>
+<br>
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__hotplug_action action)=
<br>
+{<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
+ =A0 =A0char *be_path =3D libxl__device_backend_path(gc, dev);<br>
+ =A0 =A0char *script, *what;<br>
+ =A0 =A0char **args, **env;<br>
+ =A0 =A0int status, nr =3D 0;<br>
+ =A0 =A0int rc =3D -1;<br>
+ =A0 =A0flexarray_t *f_args;<br>
+<br>
+ =A0 =A0script =3D libxl__xs_read(gc, XBT_NULL,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc,=
 &quot;%s/%s&quot;, be_path, &quot;script&quot;));<br>
+ =A0 =A0if (!script) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to read scr=
ipt from %s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0be_path);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0env =3D get_hotplug_env(gc, dev);<br>
+ =A0 =A0if (!env)<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0f_args =3D flexarray_make(3, 1);<br>
+ =A0 =A0if (!f_args) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to create a=
rguments array&quot;);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0flexarray_set(f_args, nr++, script);<br>
+ =A0 =A0flexarray_set(f_args, nr++, action =3D=3D CONNECT ? &quot;add&quot=
; : &quot;remove&quot;);<br>
+ =A0 =A0flexarray_set(f_args, nr++, NULL);<br>
+<br>
+ =A0 =A0args =3D (char **) flexarray_contents(f_args);<br>
+ =A0 =A0what =3D libxl__sprintf(gc, &quot;%s %s&quot;, args[0],<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0action =3D=3D CONNECT =
? &quot;connect&quot; : &quot;disconnect&quot;);<br>
+ =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;Calling hotplug script: %s %s&quot;,<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 args[0], args[1]);<br>
+ =A0 =A0status =3D libxl__forkexec(gc, -1, -1, -1, args[0], args, env, wha=
t);<br>
+ =A0 =A0if (status) {<br>
+ =A0 =A0 =A0 =A0rc =3D -1;<br>
+ =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0}<br>
+ =A0 =A0rc =3D 0;<br>
+<br>
+out:<br>
+ =A0 =A0free(env);<br>
+ =A0 =A0free(args);<br>
+ =A0 =A0return rc;<br>
+}<br>
+#endif /* 0 */<br>
=A0int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__hotplug_action =
action)<br>
=A0{<br>
- =A0 =A0return 0;<br>
+ =A0 =A0int rc =3D 0;<br>
+#if 0<br>
+ =A0 =A0switch (dev-&gt;backend_kind) {<br>
+ =A0 =A0case LIBXL__DEVICE_KIND_VIF:<br>
+ =A0 =A0 =A0 =A0rc =3D libxl__hotplug_nic(gc, dev, action);<br>
+ =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0case LIBXL__DEVICE_KIND_VBD:<br>
+ =A0 =A0 =A0 =A0rc =3D libxl__hotplug_disk(gc, dev, action);<br>
+ =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0default:<br>
+ =A0 =A0 =A0 =A0rc =3D 0;<br>
+ =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0}<br>
+#endif /* 0 */<br>
+ =A0 =A0return rc;<br>
=A0}<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--001517593670cfa32604b85a5de1--


--===============2085329147652009821==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2085329147652009821==--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 07:03:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 07: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.xensource.com>)
	id 1Ruf4y-0007jI-8s; Tue, 07 Feb 2012 07:03:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ruf4v-0007jB-Bz
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 07:03:02 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328598171!12262588!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25565 invoked from network); 7 Feb 2012 07:02:53 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 07:02:53 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1772m6R027281
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 23:02:49 -0800
Received: by bkcjg15 with SMTP id jg15so190956bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 23:02:47 -0800 (PST)
Received: by 10.204.141.14 with SMTP id k14mr9585040bku.67.1328598167298; Mon,
	06 Feb 2012 23:02:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 6 Feb 2012 23:02:07 -0800 (PST)
In-Reply-To: <98a4f01033786a2fc15b.1328189208@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<98a4f01033786a2fc15b.1328189208@debian.localdomain>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 6 Feb 2012 23:02:07 -0800
Message-ID: <CAP8mzPPqi5zSt_c+SAXOLUjL+DdmyZr7rE8cgfM_08CM3FgJiw@mail.gmail.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 29 RFC] libxl: add hotplug script
 calls for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2085329147652009821=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2085329147652009821==
Content-Type: multipart/alternative; boundary=001517593670cfa32604b85a5de1

--001517593670cfa32604b85a5de1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 2, 2012 at 5:26 AM, Roger Pau Monne <roger.pau@entel.upc.edu>wrote:

> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1328177591 -3600
> # Node ID 98a4f01033786a2fc15b4130897c35f64a676e40
> # Parent  6c2690921fba580dd7dd836da3be484dee049be0
> libxl: add hotplug script calls for Linux
>
> This patchs adds the necessary logic to call hotplug scripts directly
> from libxl. Linux hotplug scritps read most parameters from the caller
> environment (since udev set this parameters automatically). In this
> implementation we fake udev parameters, so no changes are needed to
> the scripts itself.
>
> Currently, the following scripts are called:
>
>  * block: used when disk backend is PHY.
>
>  * blktap: used when disk backend is TAP.
>
>
Sorry if this is a bit dense, but you have been through the code
already ;)
Is there an option to call other scripts other than block/blktap ?
For e.g., if I were to add a backend type DRBD/FOOBAR,
and wish to call script "block-<drbd|foobar>, how do you suggest I
proceed ?
  Start my way from defining new disk backend types and just add
hotplug handlers for these block-* devices and finally expose them as
phy devices to libxl ?

shriram


>  * vif-*: used when adding a network interface and can be manually set
>   by the user.
>
> udev rules descrive more device types, currently the following scripts
> are NOT executed from libxl because I wasn't able to find any support
> for this device types in libxl:
>
>  * vtpm
>
>  * vif2
>
>  * vscsi
>
>  * vif-setup with devices of type tap*
>
> This patch just adds the necessary code, but hotplug scripts are NOT
> called from libxl yet, following patches will disable udev rules and
> use this calls instead.
>
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
>
> diff -r 6c2690921fba -r 98a4f0103378 tools/libxl/libxl_linux.c
> --- a/tools/libxl/libxl_linux.c Thu Feb 02 11:10:24 2012 +0100
> +++ b/tools/libxl/libxl_linux.c Thu Feb 02 11:13:11 2012 +0100
> @@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod
>     return 1;
>  }
>
> +/* Hotplug scripts helpers */
> +#if 0
> +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *be_path = libxl__device_backend_path(gc, dev);
> +    flexarray_t *f_env;
> +    int nr = 0;
> +
> +    f_env = flexarray_make(11, 1);
> +    if (!f_env) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "unable to create environment array");
> +        return NULL;
> +    }
> +
> +    flexarray_set(f_env, nr++, "script");
> +    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
> +                               libxl__sprintf(gc, "%s/%s",
> +                                              be_path,
> +                                              "script")));
> +    flexarray_set(f_env, nr++, "XENBUS_TYPE");
> +    flexarray_set(f_env, nr++, (char *)
> +                  libxl__device_kind_to_string(dev->backend_kind));
> +    flexarray_set(f_env, nr++, "XENBUS_PATH");
> +    flexarray_set(f_env, nr++,
> +                  libxl__sprintf(gc, "backend/%s/%u/%d",
> +                  libxl__device_kind_to_string(dev->backend_kind),
> +                  dev->domid, dev->devid));
> +    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
> +    flexarray_set(f_env, nr++, "backend");
> +    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
> +        flexarray_set(f_env, nr++, "vif");
> +        flexarray_set(f_env, nr++,
> +                      libxl__sprintf(gc, "%s%u.%d",
> +                      libxl__device_kind_to_string(dev->backend_kind),
> +                      dev->domid, dev->devid));
> +    }
> +    flexarray_set(f_env, nr++, NULL);
> +
> +    return (char **) flexarray_contents(f_env);
> +}
> +
>  /* Hotplug scripts caller functions */
>
> +static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
> +                       libxl__hotplug_action action)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *be_path = libxl__device_backend_path(gc, dev);
> +    char *script, *what;
> +    char **args, **env;
> +    int status, nr = 0;
> +    int rc = -1;
> +    flexarray_t *f_args;
> +
> +    script = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path,
> "script"));
> +    if (!script) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
> +                                          be_path);
> +        return -1;
> +    }
> +
> +    env = get_hotplug_env(gc, dev);
> +    if (!env)
> +        return -1;
> +
> +    f_args = flexarray_make(4, 1);
> +    if (!f_args) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments
> array");
> +        return -1;
> +    }
> +
> +    flexarray_set(f_args, nr++, script);
> +    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
> +    flexarray_set(f_args, nr++, "type_if=vif");
> +    flexarray_set(f_args, nr++, NULL);
> +
> +    args = (char **) flexarray_contents(f_args);
> +    what = libxl__sprintf(gc, "%s %s", args[0],
> +                          action == CONNECT ? "connect" : "disconnect");
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +               "Calling hotplug script: %s %s %s",
> +               args[0], args[1], args[2]);
> +    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
> +    if (status) {
> +        rc = -1;
> +        goto out;
> +    }
> +    rc = 0;
> +
> +out:
> +    free(env);
> +    free(args);
> +    return rc;
> +}
> +
> +static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
> +                       libxl__hotplug_action action)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    char *be_path = libxl__device_backend_path(gc, dev);
> +    char *script, *what;
> +    char **args, **env;
> +    int status, nr = 0;
> +    int rc = -1;
> +    flexarray_t *f_args;
> +
> +    script = libxl__xs_read(gc, XBT_NULL,
> +                            libxl__sprintf(gc, "%s/%s", be_path,
> "script"));
> +    if (!script) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
> +                                          be_path);
> +        return -1;
> +    }
> +
> +    env = get_hotplug_env(gc, dev);
> +    if (!env)
> +        return -1;
> +
> +    f_args = flexarray_make(3, 1);
> +    if (!f_args) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments
> array");
> +        return -1;
> +    }
> +
> +    flexarray_set(f_args, nr++, script);
> +    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
> +    flexarray_set(f_args, nr++, NULL);
> +
> +    args = (char **) flexarray_contents(f_args);
> +    what = libxl__sprintf(gc, "%s %s", args[0],
> +                          action == CONNECT ? "connect" : "disconnect");
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +               "Calling hotplug script: %s %s",
> +               args[0], args[1]);
> +    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
> +    if (status) {
> +        rc = -1;
> +        goto out;
> +    }
> +    rc = 0;
> +
> +out:
> +    free(env);
> +    free(args);
> +    return rc;
> +}
> +#endif /* 0 */
>  int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
>                           libxl__hotplug_action action)
>  {
> -    return 0;
> +    int rc = 0;
> +#if 0
> +    switch (dev->backend_kind) {
> +    case LIBXL__DEVICE_KIND_VIF:
> +        rc = libxl__hotplug_nic(gc, dev, action);
> +        break;
> +    case LIBXL__DEVICE_KIND_VBD:
> +        rc = libxl__hotplug_disk(gc, dev, action);
> +        break;
> +    default:
> +        rc = 0;
> +        break;
> +    }
> +#endif /* 0 */
> +    return rc;
>  }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--001517593670cfa32604b85a5de1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Feb 2, 2012 at 5:26 AM, Roger Pau Monne =
<span dir=3D"ltr">&lt;<a href=3D"mailto:roger.pau@entel.upc.edu">roger.pau@=
entel.upc.edu</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">

# HG changeset patch<br>
# User Roger Pau Monne &lt;<a href=3D"mailto:roger.pau@entel.upc.edu">roger=
.pau@entel.upc.edu</a>&gt;<br>
# Date 1328177591 -3600<br>
# Node ID 98a4f01033786a2fc15b4130897c35f64a676e40<br>
# Parent =A06c2690921fba580dd7dd836da3be484dee049be0<br>
libxl: add hotplug script calls for Linux<br>
<br>
This patchs adds the necessary logic to call hotplug scripts directly<br>
from libxl. Linux hotplug scritps read most parameters from the caller<br>
environment (since udev set this parameters automatically). In this<br>
implementation we fake udev parameters, so no changes are needed to<br>
the scripts itself.<br>
<br>
Currently, the following scripts are called:<br>
<br>
=A0* block: used when disk backend is PHY.<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt =
0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=A0* blktap: used when disk backend is TAP.<br>
<br></blockquote><div><br>Sorry if this is a bit dense, but you have been t=
hrough the code<br>already ;)<br>Is there an option to call other scripts o=
ther than
block/blktap ?<br>For e.g., if I were to add a backend type DRBD/FOOBAR,<br=
>and wish to call script &quot;block-&lt;drbd|foobar&gt;, how do you sugges=
t I<br>proceed ?<br>=A0 Start my way from defining new disk backend types a=
nd just add<br>

hotplug handlers for these block-* devices and finally expose them as<br>ph=
y devices to libxl ?<br><br>shriram<br>=A0
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=A0* vif-*: used when adding a network interface and can be manually set<br=
>
 =A0 by the user.<br>
<br>
udev rules descrive more device types, currently the following scripts<br>
are NOT executed from libxl because I wasn&#39;t able to find any support<b=
r>
for this device types in libxl:<br>
<br>
=A0* vtpm<br>
<br>
=A0* vif2<br>
<br>
=A0* vscsi<br>
<br>
=A0* vif-setup with devices of type tap*<br>
<br>
This patch just adds the necessary code, but hotplug scripts are NOT<br>
called from libxl yet, following patches will disable udev rules and<br>
use this calls instead.<br>
<br>
Signed-off-by: Roger Pau Monne &lt;<a href=3D"mailto:roger.pau@entel.upc.ed=
u">roger.pau@entel.upc.edu</a>&gt;<br>
<br>
diff -r 6c2690921fba -r 98a4f0103378 tools/libxl/libxl_linux.c<br>
--- a/tools/libxl/libxl_linux.c Thu Feb 02 11:10:24 2012 +0100<br>
+++ b/tools/libxl/libxl_linux.c Thu Feb 02 11:13:11 2012 +0100<br>
@@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod<br>
 =A0 =A0 return 1;<br>
=A0}<br>
<br>
+/* Hotplug scripts helpers */<br>
+#if 0<br>
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)<br>
+{<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
+ =A0 =A0char *be_path =3D libxl__device_backend_path(gc, dev);<br>
+ =A0 =A0flexarray_t *f_env;<br>
+ =A0 =A0int nr =3D 0;<br>
+<br>
+ =A0 =A0f_env =3D flexarray_make(11, 1);<br>
+ =A0 =A0if (!f_env) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;unable to create environment ar=
ray&quot;);<br>
+ =A0 =A0 =A0 =A0return NULL;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;script&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__sprint=
f(gc, &quot;%s/%s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0be_path,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0&quot;script&quot;)));<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;XENBUS_TYPE&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++, (char *)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__device_kind_to_string(dev-&gt;b=
ackend_kind));<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;XENBUS_PATH&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc, &quot;backend/%s/%u=
/%d&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__device_kind_to_string(dev-&gt;b=
ackend_kind),<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev-&gt;domid, dev-&gt;devid));<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;XENBUS_BASE_PATH&quot;);<br>
+ =A0 =A0flexarray_set(f_env, nr++, &quot;backend&quot;);<br>
+ =A0 =A0if (dev-&gt;backend_kind =3D=3D LIBXL__DEVICE_KIND_VIF) {<br>
+ =A0 =A0 =A0 =A0flexarray_set(f_env, nr++, &quot;vif&quot;);<br>
+ =A0 =A0 =A0 =A0flexarray_set(f_env, nr++,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc, &quot;%s%u.=
%d&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__device_kind_to_string(d=
ev-&gt;backend_kind),<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev-&gt;domid, dev-&gt;devid))=
;<br>
+ =A0 =A0}<br>
+ =A0 =A0flexarray_set(f_env, nr++, NULL);<br>
+<br>
+ =A0 =A0return (char **) flexarray_contents(f_env);<br>
+}<br>
+<br>
=A0/* Hotplug scripts caller functions */<br>
<br>
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__hotplug_action action)=
<br>
+{<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
+ =A0 =A0char *be_path =3D libxl__device_backend_path(gc, dev);<br>
+ =A0 =A0char *script, *what;<br>
+ =A0 =A0char **args, **env;<br>
+ =A0 =A0int status, nr =3D 0;<br>
+ =A0 =A0int rc =3D -1;<br>
+ =A0 =A0flexarray_t *f_args;<br>
+<br>
+ =A0 =A0script =3D libxl__xs_read(gc, XBT_NULL,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc,=
 &quot;%s/%s&quot;, be_path, &quot;script&quot;));<br>
+ =A0 =A0if (!script) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to read scr=
ipt from %s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0be_path);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0env =3D get_hotplug_env(gc, dev);<br>
+ =A0 =A0if (!env)<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0f_args =3D flexarray_make(4, 1);<br>
+ =A0 =A0if (!f_args) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to create a=
rguments array&quot;);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0flexarray_set(f_args, nr++, script);<br>
+ =A0 =A0flexarray_set(f_args, nr++, action =3D=3D CONNECT ? &quot;online&q=
uot; : &quot;offline&quot;);<br>
+ =A0 =A0flexarray_set(f_args, nr++, &quot;type_if=3Dvif&quot;);<br>
+ =A0 =A0flexarray_set(f_args, nr++, NULL);<br>
+<br>
+ =A0 =A0args =3D (char **) flexarray_contents(f_args);<br>
+ =A0 =A0what =3D libxl__sprintf(gc, &quot;%s %s&quot;, args[0],<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0action =3D=3D CONNECT =
? &quot;connect&quot; : &quot;disconnect&quot;);<br>
+ =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;Calling hotplug script: %s %s %s&quot;,=
<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 args[0], args[1], args[2]);<br>
+ =A0 =A0status =3D libxl__forkexec(gc, -1, -1, -1, args[0], args, env, wha=
t);<br>
+ =A0 =A0if (status) {<br>
+ =A0 =A0 =A0 =A0rc =3D -1;<br>
+ =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0}<br>
+ =A0 =A0rc =3D 0;<br>
+<br>
+out:<br>
+ =A0 =A0free(env);<br>
+ =A0 =A0free(args);<br>
+ =A0 =A0return rc;<br>
+}<br>
+<br>
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__hotplug_action action)=
<br>
+{<br>
+ =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
+ =A0 =A0char *be_path =3D libxl__device_backend_path(gc, dev);<br>
+ =A0 =A0char *script, *what;<br>
+ =A0 =A0char **args, **env;<br>
+ =A0 =A0int status, nr =3D 0;<br>
+ =A0 =A0int rc =3D -1;<br>
+ =A0 =A0flexarray_t *f_args;<br>
+<br>
+ =A0 =A0script =3D libxl__xs_read(gc, XBT_NULL,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sprintf(gc,=
 &quot;%s/%s&quot;, be_path, &quot;script&quot;));<br>
+ =A0 =A0if (!script) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to read scr=
ipt from %s&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0be_path);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0env =3D get_hotplug_env(gc, dev);<br>
+ =A0 =A0if (!env)<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0f_args =3D flexarray_make(3, 1);<br>
+ =A0 =A0if (!f_args) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;unable to create a=
rguments array&quot;);<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0}<br>
+<br>
+ =A0 =A0flexarray_set(f_args, nr++, script);<br>
+ =A0 =A0flexarray_set(f_args, nr++, action =3D=3D CONNECT ? &quot;add&quot=
; : &quot;remove&quot;);<br>
+ =A0 =A0flexarray_set(f_args, nr++, NULL);<br>
+<br>
+ =A0 =A0args =3D (char **) flexarray_contents(f_args);<br>
+ =A0 =A0what =3D libxl__sprintf(gc, &quot;%s %s&quot;, args[0],<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0action =3D=3D CONNECT =
? &quot;connect&quot; : &quot;disconnect&quot;);<br>
+ =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;Calling hotplug script: %s %s&quot;,<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 args[0], args[1]);<br>
+ =A0 =A0status =3D libxl__forkexec(gc, -1, -1, -1, args[0], args, env, wha=
t);<br>
+ =A0 =A0if (status) {<br>
+ =A0 =A0 =A0 =A0rc =3D -1;<br>
+ =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0}<br>
+ =A0 =A0rc =3D 0;<br>
+<br>
+out:<br>
+ =A0 =A0free(env);<br>
+ =A0 =A0free(args);<br>
+ =A0 =A0return rc;<br>
+}<br>
+#endif /* 0 */<br>
=A0int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl__hotplug_action =
action)<br>
=A0{<br>
- =A0 =A0return 0;<br>
+ =A0 =A0int rc =3D 0;<br>
+#if 0<br>
+ =A0 =A0switch (dev-&gt;backend_kind) {<br>
+ =A0 =A0case LIBXL__DEVICE_KIND_VIF:<br>
+ =A0 =A0 =A0 =A0rc =3D libxl__hotplug_nic(gc, dev, action);<br>
+ =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0case LIBXL__DEVICE_KIND_VBD:<br>
+ =A0 =A0 =A0 =A0rc =3D libxl__hotplug_disk(gc, dev, action);<br>
+ =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0default:<br>
+ =A0 =A0 =A0 =A0rc =3D 0;<br>
+ =A0 =A0 =A0 =A0break;<br>
+ =A0 =A0}<br>
+#endif /* 0 */<br>
+ =A0 =A0return rc;<br>
=A0}<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--001517593670cfa32604b85a5de1--


--===============2085329147652009821==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2085329147652009821==--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 07:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 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.xensource.com>)
	id 1RufqS-0008ME-FV; Tue, 07 Feb 2012 07:52:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RufqQ-0008M9-Rg
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 07:52:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328601120!13362308!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19174 invoked from network); 7 Feb 2012 07:52:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 07:52:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 07:51:58 +0000
Message-Id: <4F30E62B02000078000717EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 07:51:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
In-Reply-To: <20120206170224.GD23240@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Dan Magenheimer <dan.magenheimer@oracle.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 18:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 06, 2012 at 04:49:42PM +0000, Jan Beulich wrote:
>> >>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
>> >> 
>> >> Which can't be built as a module, and hence the symbol doesn't need
>> >> exporting. This patch (of course, I'm tempted to say) survived build
>> >> testing.
>> > 
>> > Yes, correct.  BUT... I think only the reason xen-selfballoon.c
>> > can't be built as a module is because the MM variable vm_committed_as
>> > (or an access function) is not exported.  Ideally xen-selfballoon.c
>> > probably should be a module but putting a core MM change in
>> > the critical path of a Xen-only-related enhancement seemed
>> > a recipe for sure failure.
>> 
>> No, this isn't the main reason (as you say further down, this could
>> easily be adjusted for) afaict. The main reason is that
>> register_xen_selfballooning() is being called from non-modular
>> code (xen-balloon.c), which could be made a module too, but in
>> turn has at least one reference that wouldn't be nice to become
>> an export (balloon_set_new_target()).
> 
> It would be nice if all of it could become modules. That way HVM
> device driver domains could load the whole thing without having much
> built-in code in the kernel.
> 
> Is it possible to do that?

As outlined above, it is possible, but I'm not certain it is a good idea
to have balloon_set_new_target() exported. If you think that's
acceptable, I can certainly put together a patch doing that (on top
of the one here, and probably not immediately).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 07:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 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.xensource.com>)
	id 1RufqS-0008ME-FV; Tue, 07 Feb 2012 07:52:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RufqQ-0008M9-Rg
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 07:52:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328601120!13362308!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19174 invoked from network); 7 Feb 2012 07:52:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 07:52:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 07:51:58 +0000
Message-Id: <4F30E62B02000078000717EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 07:51:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
In-Reply-To: <20120206170224.GD23240@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Dan Magenheimer <dan.magenheimer@oracle.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 18:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 06, 2012 at 04:49:42PM +0000, Jan Beulich wrote:
>> >>> On 06.02.12 at 17:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> > tmem_enabled is used in xen/drivers/xen-selfballoon.c
>> >> 
>> >> Which can't be built as a module, and hence the symbol doesn't need
>> >> exporting. This patch (of course, I'm tempted to say) survived build
>> >> testing.
>> > 
>> > Yes, correct.  BUT... I think only the reason xen-selfballoon.c
>> > can't be built as a module is because the MM variable vm_committed_as
>> > (or an access function) is not exported.  Ideally xen-selfballoon.c
>> > probably should be a module but putting a core MM change in
>> > the critical path of a Xen-only-related enhancement seemed
>> > a recipe for sure failure.
>> 
>> No, this isn't the main reason (as you say further down, this could
>> easily be adjusted for) afaict. The main reason is that
>> register_xen_selfballooning() is being called from non-modular
>> code (xen-balloon.c), which could be made a module too, but in
>> turn has at least one reference that wouldn't be nice to become
>> an export (balloon_set_new_target()).
> 
> It would be nice if all of it could become modules. That way HVM
> device driver domains could load the whole thing without having much
> built-in code in the kernel.
> 
> Is it possible to do that?

As outlined above, it is possible, but I'm not certain it is a good idea
to have balloon_set_new_target() exported. If you think that's
acceptable, I can certainly put together a patch doing that (on top
of the one here, and probably not immediately).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 08:28:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 08: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.xensource.com>)
	id 1RugPO-0000kh-1O; Tue, 07 Feb 2012 08:28:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RugPL-0000kZ-SX
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:28:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328603158!51657758!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11181 invoked from network); 7 Feb 2012 08:25:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 08:25:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 08:28:10 +0000
Message-Id: <4F30EE610200007800071801@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 08:26:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
In-Reply-To: <20120206174745.GA14324@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 18:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1328549858 -3600
>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>> 
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on 
> family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> 
> What about fixing the Linux guest to actually not do this? I presume you
> have encountered this with HVM guests - would it be possible to use
> 
> set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 
> 'xen_hvm_guest_init' ??

Are you saying this would work even with CONFIG_XEN not set
(which I doubt, but is a valid case to consider)?

Also, this sort of adjustment is exactly what is being done better
in the hypervisor, as it'll address the problem at hand for all guests,
no matter what kernel (version or kind) they run.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 08:28:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 08: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.xensource.com>)
	id 1RugPO-0000kh-1O; Tue, 07 Feb 2012 08:28:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RugPL-0000kZ-SX
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:28:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328603158!51657758!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11181 invoked from network); 7 Feb 2012 08:25:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 08:25:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 08:28:10 +0000
Message-Id: <4F30EE610200007800071801@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 08:26:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
In-Reply-To: <20120206174745.GA14324@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 18:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1328549858 -3600
>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>> 
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on 
> family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> 
> What about fixing the Linux guest to actually not do this? I presume you
> have encountered this with HVM guests - would it be possible to use
> 
> set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 
> 'xen_hvm_guest_init' ??

Are you saying this would work even with CONFIG_XEN not set
(which I doubt, but is a valid case to consider)?

Also, this sort of adjustment is exactly what is being done better
in the hypervisor, as it'll address the problem at hand for all guests,
no matter what kernel (version or kind) they run.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 08:37:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 08: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.xensource.com>)
	id 1RugXg-0000uN-12; Tue, 07 Feb 2012 08:36:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RugXe-0000uE-Px
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:36:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328603800!13992926!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31399 invoked from network); 7 Feb 2012 08:36:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 08:36:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 08:36:40 +0000
Message-Id: <4F30F0A30200007800071820@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 08:36:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liuyongan" <liuyongan@huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
	<4F3011D102000078000716A0@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD2D1@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD2D1@szxeml534-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 04:53, Liuyongan <liuyongan@huawei.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 06.02.12 at 12:38, Liuyongan <liuyongan@huawei.com> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
>> >> > In file grant_table.c function __gnttab_map_grant_ref, if
>> >> __get_paged_frame
>> >> > failed, the effect of _set_status  previously called should be
>> >> rollback, so
>> >> > the flag GTF_reading and _GTF_writing will be recovered.
>> >>
>> >> Not knowing too much about these, but isn't
>> __acquire_grant_for_copy()
>> >> in need of a similar adjustment?
>> >   Well, I need to check it further.
> 
>    The caller of __acquire_grant_for_copy() will make sure similar rollback
> by calling __release_grant_for_copy().

Ah, okay. Thanks for clarifying that.

>> >> Further, aren't the status flags cumulative (and hence isn't it
>> wrong
>> >> to
>> >> simply clear flags without considering their original state)?
>> >   When undo_out branch is executed, the flag set by _set_status
>> function
>> >   will be rolled back by:
>> >        if ( !(op->flags & GNTMAP_readonly) &&
>> >          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>> >         gnttab_clear_flag(_GTF_writing, status);
>> >
>> >        if ( !act->pin )
>> >         gnttab_clear_flag(_GTF_reading, status);
>> >   so action added by this patch should be correct.
>> 
>> But this is not a roll-back, here the flags get simply cleared (whereas
>> "roll-back" to me means the restoration of their previous value).
> 
>   According to my analysis, flag will be cleared only if it is set 
> previously 
> in _set_status() of this function.

But still without regard to the previous value these flags had, while
it is my current understanding that these flags provide information
on the kind of uses (note the plural) that a particular grant is in (not
sure what confusion would arise if these flags don't reflect the
actual state, but if the flags getting out of sync was benign, they
could as well be removed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 08:37:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 08: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.xensource.com>)
	id 1RugXg-0000uN-12; Tue, 07 Feb 2012 08:36:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RugXe-0000uE-Px
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:36:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328603800!13992926!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31399 invoked from network); 7 Feb 2012 08:36:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 08:36:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 08:36:40 +0000
Message-Id: <4F30F0A30200007800071820@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 08:36:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liuyongan" <liuyongan@huawei.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFCDA6@szxeml534-mbx.china.huawei.com>
	<4F2FA56D02000078000714EF@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD15D@szxeml534-mbx.china.huawei.com>
	<4F3011D102000078000716A0@nat28.tlf.novell.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD2D1@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A191CEFD2D1@szxeml534-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Qianhuibin <qianhuibin@huawei.com>, hanweidong <hanweidong@huawei.com>,
	Zhanghaoyu <haoyu.zhang@huawei.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Wang Liang <hzwangliang.wang@huawei.com>
Subject: Re: [Xen-devel] [PATCH] grant table map error in
 __gnttab_map_grant_ref
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 04:53, Liuyongan <liuyongan@huawei.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 06.02.12 at 12:38, Liuyongan <liuyongan@huawei.com> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>    >>> On 04.02.12 at 03:43, Liuyongan <liuyongan@huawei.com> wrote:
>> >> > In file grant_table.c function __gnttab_map_grant_ref, if
>> >> __get_paged_frame
>> >> > failed, the effect of _set_status  previously called should be
>> >> rollback, so
>> >> > the flag GTF_reading and _GTF_writing will be recovered.
>> >>
>> >> Not knowing too much about these, but isn't
>> __acquire_grant_for_copy()
>> >> in need of a similar adjustment?
>> >   Well, I need to check it further.
> 
>    The caller of __acquire_grant_for_copy() will make sure similar rollback
> by calling __release_grant_for_copy().

Ah, okay. Thanks for clarifying that.

>> >> Further, aren't the status flags cumulative (and hence isn't it
>> wrong
>> >> to
>> >> simply clear flags without considering their original state)?
>> >   When undo_out branch is executed, the flag set by _set_status
>> function
>> >   will be rolled back by:
>> >        if ( !(op->flags & GNTMAP_readonly) &&
>> >          !(act->pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
>> >         gnttab_clear_flag(_GTF_writing, status);
>> >
>> >        if ( !act->pin )
>> >         gnttab_clear_flag(_GTF_reading, status);
>> >   so action added by this patch should be correct.
>> 
>> But this is not a roll-back, here the flags get simply cleared (whereas
>> "roll-back" to me means the restoration of their previous value).
> 
>   According to my analysis, flag will be cleared only if it is set 
> previously 
> in _set_status() of this function.

But still without regard to the previous value these flags had, while
it is my current understanding that these flags provide information
on the kind of uses (note the plural) that a particular grant is in (not
sure what confusion would arise if these flags don't reflect the
actual state, but if the flags getting out of sync was benign, they
could as well be removed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 08:54:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 08: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.xensource.com>)
	id 1Rugnu-0001FC-Im; Tue, 07 Feb 2012 08:53: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 1Rugns-0001F7-Ut
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:53:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328604762!53177771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12125 invoked from network); 7 Feb 2012 08:52:42 -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;
	7 Feb 2012 08:52:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,376,1325462400"; d="scan'208";a="10538764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 08:53:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 08:53:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rugnr-0004np-0E;
	Tue, 07 Feb 2012 08:53:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rugnq-0007wi-Mi;
	Tue, 07 Feb 2012 08:53:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11895-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 7 Feb 2012 08:53:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11895: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11895 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11895/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 11894

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11894

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3574f4d67843
baseline version:
 xen                  3574f4d67843

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 08:54:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 08: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.xensource.com>)
	id 1Rugnu-0001FC-Im; Tue, 07 Feb 2012 08:53: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 1Rugns-0001F7-Ut
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:53:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328604762!53177771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12125 invoked from network); 7 Feb 2012 08:52:42 -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;
	7 Feb 2012 08:52:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,376,1325462400"; d="scan'208";a="10538764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 08:53:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 08:53:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rugnr-0004np-0E;
	Tue, 07 Feb 2012 08:53:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rugnq-0007wi-Mi;
	Tue, 07 Feb 2012 08:53:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11895-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 7 Feb 2012 08:53:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11895: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11895 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11895/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 11894

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11894

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3574f4d67843
baseline version:
 xen                  3574f4d67843

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 09:05:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 09:05:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rugz5-0001RX-Sj; Tue, 07 Feb 2012 09:05:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rugz3-0001RS-Uy
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 09:05:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328605499!5777463!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16631 invoked from network); 7 Feb 2012 09:04:59 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 09:04:59 -0000
Received: by wgbdr13 with SMTP id dr13so6318215wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 01:04:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=4jVsQPx3ZfObU82+ibL3Nbql2nbIcsrlZoSc7joJkxk=;
	b=GId6TVoSxyZhEMk0frgMwz38vQAAP7KEUe5Ult8Ol5dUAORmARL6w5z+3Gq+LlJ+bT
	f6YGN+EvdeXDpRWRKrtR8UvCsVBqs1VoXk/hmrVcV559CjivMMFxbV8wklxGOE76P4lk
	W7iUKwCVmrw2cNSv1K9VwSNfOkQ3mvGFpweWA=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr30896269wiy.1.1328605499193; Tue,
	07 Feb 2012 01:04:59 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 7 Feb 2012 01:04:59 -0800 (PST)
In-Reply-To: <CAP8mzPPqi5zSt_c+SAXOLUjL+DdmyZr7rE8cgfM_08CM3FgJiw@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<98a4f01033786a2fc15b.1328189208@debian.localdomain>
	<CAP8mzPPqi5zSt_c+SAXOLUjL+DdmyZr7rE8cgfM_08CM3FgJiw@mail.gmail.com>
Date: Tue, 7 Feb 2012 10:04:59 +0100
X-Google-Sender-Auth: 4_dsRaacMdfjOS-N9aG-ls2lNcY
Message-ID: <CAPLaKK50F8EWRcty-oVn4j5mo1BVGLr1Ue9ySVTFXPu4HR2vBw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: rshriram@cs.ubc.ca
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 29 RFC] libxl: add hotplug script
 calls for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzcgU2hyaXJhbSBSYWphZ29wYWxhbiA8cnNocmlyYW1AY3MudWJjLmNhPjoKPiBPbiBU
aHUsIEZlYiAyLCAyMDEyIGF0IDU6MjYgQU0sIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+Cj4gd3JvdGU6Cj4+Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNl
ciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMy
ODE3NzU5MSAtMzYwMAo+PiAjIE5vZGUgSUQgOThhNGYwMTAzMzc4NmEyZmMxNWI0MTMwODk3YzM1
ZjY0YTY3NmU0MAo+PiAjIFBhcmVudCDCoDZjMjY5MDkyMWZiYTU4MGRkN2RkODM2ZGEzYmU0ODRk
ZWUwNDliZTAKPj4gbGlieGw6IGFkZCBob3RwbHVnIHNjcmlwdCBjYWxscyBmb3IgTGludXgKPj4K
Pj4gVGhpcyBwYXRjaHMgYWRkcyB0aGUgbmVjZXNzYXJ5IGxvZ2ljIHRvIGNhbGwgaG90cGx1ZyBz
Y3JpcHRzIGRpcmVjdGx5Cj4+IGZyb20gbGlieGwuIExpbnV4IGhvdHBsdWcgc2NyaXRwcyByZWFk
IG1vc3QgcGFyYW1ldGVycyBmcm9tIHRoZSBjYWxsZXIKPj4gZW52aXJvbm1lbnQgKHNpbmNlIHVk
ZXYgc2V0IHRoaXMgcGFyYW1ldGVycyBhdXRvbWF0aWNhbGx5KS4gSW4gdGhpcwo+PiBpbXBsZW1l
bnRhdGlvbiB3ZSBmYWtlIHVkZXYgcGFyYW1ldGVycywgc28gbm8gY2hhbmdlcyBhcmUgbmVlZGVk
IHRvCj4+IHRoZSBzY3JpcHRzIGl0c2VsZi4KPj4KPj4gQ3VycmVudGx5LCB0aGUgZm9sbG93aW5n
IHNjcmlwdHMgYXJlIGNhbGxlZDoKPj4KPj4gwqAqIGJsb2NrOiB1c2VkIHdoZW4gZGlzayBiYWNr
ZW5kIGlzIFBIWS4KPj4KPj4gwqAqIGJsa3RhcDogdXNlZCB3aGVuIGRpc2sgYmFja2VuZCBpcyBU
QVAuCj4+Cj4KPiBTb3JyeSBpZiB0aGlzIGlzIGEgYml0IGRlbnNlLCBidXQgeW91IGhhdmUgYmVl
biB0aHJvdWdoIHRoZSBjb2RlCj4gYWxyZWFkeSA7KQo+IElzIHRoZXJlIGFuIG9wdGlvbiB0byBj
YWxsIG90aGVyIHNjcmlwdHMgb3RoZXIgdGhhbiBibG9jay9ibGt0YXAgPwoKbGlieGwgaGFzIHNv
bWUgcHJlbGltaW5hcnkgc3VwcG9ydCBmb3Igc2V0dGluZyBjdXN0b20gaG90cGx1ZyBzY3JpcHRz
CmZvciBoYXJkIGRyaXZlcyBpbiBjb25maWd1cmF0aW9uIGZpbGVzIChqdXN0IGxpa2UgeW91IGRv
IGZvciBuaWMKaW50ZXJmYWNlcyksIHRoaXMgaXMgY3VycmVudGx5IGRpc2FibGVkIGJ1dCBjb3Vs
ZCBiZSBlbmFibGVkIGluIGZ1dHVyZQpyZWxlYXNlcy4KCj4gRm9yIGUuZy4sIGlmIEkgd2VyZSB0
byBhZGQgYSBiYWNrZW5kIHR5cGUgRFJCRC9GT09CQVIsCj4gYW5kIHdpc2ggdG8gY2FsbCBzY3Jp
cHQgImJsb2NrLTxkcmJkfGZvb2Jhcj4sIGhvdyBkbyB5b3Ugc3VnZ2VzdCBJCj4gcHJvY2VlZCA/
CgpXZWxsLCBJIHNlZSBzZXZlcmFsIGFwcHJvYWNoZXMgaGVyZSwgcmlnaHQgbm93IHdlIGNhbGwg
TGludXggaG90cGx1ZwpzY3JpcHRzIGFkZGluZyB0aGUgbmVjZXNzYXJ5IGVudiB2YXJpYWJsZXMs
IHNpbmNlIHVkZXYgdXNlZCB0byBzZXQKdGhvc2UgdmFyaWFibGVzIGF1dG9tYXRpY2FsbHksIGFu
ZCB3ZSB3aWxsIGNvbnRpbnVlIHRvIGRvIGl0IHRoYXQgd2F5CnVudGlsIHhlbmQgaXMgcmVtb3Zl
ZC4gSSB0aGluayBpdCdzIG1vc3Qgc3VpdGFibGUgdG8gcGFzcyB0aG9zZQpwYXJhbWV0ZXJzIGFz
IGFyZ3VtZW50cyB0byB0aGUgc2NyaXB0LCBidXQgdGhpcyBhcyBJIHNhaWQgYmVmb3JlIGlzIGEK
bG9uZyB0ZXJtIGdvYWwuCgo+IMKgIFN0YXJ0IG15IHdheSBmcm9tIGRlZmluaW5nIG5ldyBkaXNr
IGJhY2tlbmQgdHlwZXMgYW5kIGp1c3QgYWRkCj4gaG90cGx1ZyBoYW5kbGVycyBmb3IgdGhlc2Ug
YmxvY2stKiBkZXZpY2VzIGFuZCBmaW5hbGx5IGV4cG9zZSB0aGVtIGFzCj4gcGh5IGRldmljZXMg
dG8gbGlieGwgPwoKVGhhdCdzIHJlYWxseSB1cCB0byB5b3UsIGJ1dCBpZiB5b3Ugd2FudCB0byBw
YXNzIHRoZW0gYXMgUEhZIGRldmljZXMsCnlvdSBzaG91bGQgbW9kaWZ5IHRoZSBsaWJ4bF9fdHJ5
X3BoeV9iYWNrZW5kIGZ1bmN0aW9uIGluc2lkZQpsaWJ4bF9saW51eC5jIGFuZCBsaWJ4bF9uZXRi
c2QuYy4gSWYgeW91IHdhbnQgdGhpcyBjaGFuZ2VzIHRvIGJlIGFkZGVkCnRvIHVwc3RyZWFtIGl0
IG1pZ2h0IGJlIGJlc3QgdG8gZGVmaW5lIHlvdXIgb3duIGJhY2tlbmQgdHlwZSwKb3ZlcmxvYWRp
bmcgdGhlIFBIWSB0eXBlIGl0J3Mgbm90IGNsZWFyZXIsIGFuZCBQSFkgc2hvdWxkIG9ubHkgYmUg
dXNlZApmb3IgcGh5c2ljYWwgcGFydGl0aW9ucyAoYWdhaW4sIHNpbmNlIEkgZG9uJ3Qga25vdyB5
b3VyIHNwZWNpZmljCmltcGxlbWVudGF0aW9uLCBJIGNhbm5vdCBiZSBzdXJlIG9mIHRoZSBtb3N0
IHN1aXRhYmxlIHdheSB0byB0YWNrbGUKdGhpcyBwcm9ibGVtKS4KCj4KPiBzaHJpcmFtCj4KPj4K
Pj4gwqAqIHZpZi0qOiB1c2VkIHdoZW4gYWRkaW5nIGEgbmV0d29yayBpbnRlcmZhY2UgYW5kIGNh
biBiZSBtYW51YWxseSBzZXQKPj4gwqAgYnkgdGhlIHVzZXIuCj4+Cj4+IHVkZXYgcnVsZXMgZGVz
Y3JpdmUgbW9yZSBkZXZpY2UgdHlwZXMsIGN1cnJlbnRseSB0aGUgZm9sbG93aW5nIHNjcmlwdHMK
Pj4gYXJlIE5PVCBleGVjdXRlZCBmcm9tIGxpYnhsIGJlY2F1c2UgSSB3YXNuJ3QgYWJsZSB0byBm
aW5kIGFueSBzdXBwb3J0Cj4+IGZvciB0aGlzIGRldmljZSB0eXBlcyBpbiBsaWJ4bDoKPj4KPj4g
wqAqIHZ0cG0KPj4KPj4gwqAqIHZpZjIKPj4KPj4gwqAqIHZzY3NpCj4+Cj4+IMKgKiB2aWYtc2V0
dXAgd2l0aCBkZXZpY2VzIG9mIHR5cGUgdGFwKgo+Pgo+PiBUaGlzIHBhdGNoIGp1c3QgYWRkcyB0
aGUgbmVjZXNzYXJ5IGNvZGUsIGJ1dCBob3RwbHVnIHNjcmlwdHMgYXJlIE5PVAo+PiBjYWxsZWQg
ZnJvbSBsaWJ4bCB5ZXQsIGZvbGxvd2luZyBwYXRjaGVzIHdpbGwgZGlzYWJsZSB1ZGV2IHJ1bGVz
IGFuZAo+PiB1c2UgdGhpcyBjYWxscyBpbnN0ZWFkLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dl
ciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pgo+PiBkaWZmIC1yIDZjMjY5
MDkyMWZiYSAtciA5OGE0ZjAxMDMzNzggdG9vbHMvbGlieGwvbGlieGxfbGludXguYwo+PiAtLS0g
YS90b29scy9saWJ4bC9saWJ4bF9saW51eC5jIFRodSBGZWIgMDIgMTE6MTA6MjQgMjAxMiArMDEw
MAo+PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9saW51eC5jIFRodSBGZWIgMDIgMTE6MTM6MTEg
MjAxMiArMDEwMAo+PiBAQCAtMjYsMTAgKzI2LDE3MiBAQCBpbnQgbGlieGxfX3RyeV9waHlfYmFj
a2VuZChtb2RlX3Qgc3RfbW9kCj4+IMKgIMKgIHJldHVybiAxOwo+PiDCoH0KPj4KPj4gKy8qIEhv
dHBsdWcgc2NyaXB0cyBoZWxwZXJzICovCj4+ICsjaWYgMAo+PiArc3RhdGljIGNoYXIgKipnZXRf
aG90cGx1Z19lbnYobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAqZGV2KQo+PiArewo+PiAr
IMKgIMKgbGlieGxfY3R4ICpjdHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+PiArIMKgIMKgY2hh
ciAqYmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfYmFja2VuZF9wYXRoKGdjLCBkZXYpOwo+PiArIMKg
IMKgZmxleGFycmF5X3QgKmZfZW52Owo+PiArIMKgIMKgaW50IG5yID0gMDsKPj4gKwo+PiArIMKg
IMKgZl9lbnYgPSBmbGV4YXJyYXlfbWFrZSgxMSwgMSk7Cj4+ICsgwqAgwqBpZiAoIWZfZW52KSB7
Cj4+ICsgwqAgwqAgwqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAidW5hYmxlIHRvIGNyZWF0ZSBlbnZpcm9ubWVudCBh
cnJheSIpOwo+PiArIMKgIMKgIMKgIMKgcmV0dXJuIE5VTEw7Cj4+ICsgwqAgwqB9Cj4+ICsKPj4g
KyDCoCDCoGZsZXhhcnJheV9zZXQoZl9lbnYsIG5yKyssICJzY3JpcHQiKTsKPj4gKyDCoCDCoGZs
ZXhhcnJheV9zZXQoZl9lbnYsIG5yKyssIGxpYnhsX194c19yZWFkKGdjLCBYQlRfTlVMTCwKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaWJ4bF9fc3By
aW50ZihnYywgIiVzLyVzIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJlX3BhdGgsCj4+ICsgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAic2NyaXB0IikpKTsKPj4gKyDCoCDCoGZsZXhhcnJheV9zZXQoZl9lbnYsIG5yKyssICJYRU5C
VVNfVFlQRSIpOwo+PiArIMKgIMKgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgKGNoYXIgKikK
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19kZXZpY2Vfa2luZF90b19zdHJp
bmcoZGV2LT5iYWNrZW5kX2tpbmQpKTsKPj4gKyDCoCDCoGZsZXhhcnJheV9zZXQoZl9lbnYsIG5y
KyssICJYRU5CVVNfUEFUSCIpOwo+PiArIMKgIMKgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywK
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19zcHJpbnRmKGdjLCAiYmFja2Vu
ZC8lcy8ldS8lZCIsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWJ4bF9fZGV2aWNl
X2tpbmRfdG9fc3RyaW5nKGRldi0+YmFja2VuZF9raW5kKSwKPj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoGRldi0+ZG9taWQsIGRldi0+ZGV2aWQpKTsKPj4gKyDCoCDCoGZsZXhhcnJheV9z
ZXQoZl9lbnYsIG5yKyssICJYRU5CVVNfQkFTRV9QQVRIIik7Cj4+ICsgwqAgwqBmbGV4YXJyYXlf
c2V0KGZfZW52LCBucisrLCAiYmFja2VuZCIpOwo+PiArIMKgIMKgaWYgKGRldi0+YmFja2VuZF9r
aW5kID09IExJQlhMX19ERVZJQ0VfS0lORF9WSUYpIHsKPj4gKyDCoCDCoCDCoCDCoGZsZXhhcnJh
eV9zZXQoZl9lbnYsIG5yKyssICJ2aWYiKTsKPj4gKyDCoCDCoCDCoCDCoGZsZXhhcnJheV9zZXQo
Zl9lbnYsIG5yKyssCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWJ4bF9f
c3ByaW50ZihnYywgIiVzJXUuJWQiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgbGlieGxfX2RldmljZV9raW5kX3RvX3N0cmluZyhkZXYtPmJhY2tlbmRfa2luZCksCj4+ICsg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXYtPmRvbWlkLCBkZXYtPmRldmlkKSk7
Cj4+ICsgwqAgwqB9Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfZW52LCBucisrLCBOVUxMKTsK
Pj4gKwo+PiArIMKgIMKgcmV0dXJuIChjaGFyICoqKSBmbGV4YXJyYXlfY29udGVudHMoZl9lbnYp
Owo+PiArfQo+PiArCj4+IMKgLyogSG90cGx1ZyBzY3JpcHRzIGNhbGxlciBmdW5jdGlvbnMgKi8K
Pj4KPj4gK3N0YXRpYyBpbnQgbGlieGxfX2hvdHBsdWdfbmljKGxpYnhsX19nYyAqZ2MsIGxpYnhs
X19kZXZpY2UgKmRldiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaWJ4
bF9faG90cGx1Z19hY3Rpb24gYWN0aW9uKQo+PiArewo+PiArIMKgIMKgbGlieGxfY3R4ICpjdHgg
PSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+PiArIMKgIMKgY2hhciAqYmVfcGF0aCA9IGxpYnhsX19k
ZXZpY2VfYmFja2VuZF9wYXRoKGdjLCBkZXYpOwo+PiArIMKgIMKgY2hhciAqc2NyaXB0LCAqd2hh
dDsKPj4gKyDCoCDCoGNoYXIgKiphcmdzLCAqKmVudjsKPj4gKyDCoCDCoGludCBzdGF0dXMsIG5y
ID0gMDsKPj4gKyDCoCDCoGludCByYyA9IC0xOwo+PiArIMKgIMKgZmxleGFycmF5X3QgKmZfYXJn
czsKPj4gKwo+PiArIMKgIMKgc2NyaXB0ID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxMLAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlieGxfX3Nwcmlu
dGYoZ2MsICIlcy8lcyIsIGJlX3BhdGgsCj4+ICJzY3JpcHQiKSk7Cj4+ICsgwqAgwqBpZiAoIXNj
cmlwdCkgewo+PiArIMKgIMKgIMKgIMKgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1Is
ICJ1bmFibGUgdG8gcmVhZCBzY3JpcHQgZnJvbQo+PiAlcyIsCj4+ICsgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZV9wYXRoKTsK
Pj4gKyDCoCDCoCDCoCDCoHJldHVybiAtMTsKPj4gKyDCoCDCoH0KPj4gKwo+PiArIMKgIMKgZW52
ID0gZ2V0X2hvdHBsdWdfZW52KGdjLCBkZXYpOwo+PiArIMKgIMKgaWYgKCFlbnYpCj4+ICsgwqAg
wqAgwqAgwqByZXR1cm4gLTE7Cj4+ICsKPj4gKyDCoCDCoGZfYXJncyA9IGZsZXhhcnJheV9tYWtl
KDQsIDEpOwo+PiArIMKgIMKgaWYgKCFmX2FyZ3MpIHsKPj4gKyDCoCDCoCDCoCDCoExJQlhMX19M
T0coY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGNyZWF0ZSBhcmd1bWVudHMKPj4g
YXJyYXkiKTsKPj4gKyDCoCDCoCDCoCDCoHJldHVybiAtMTsKPj4gKyDCoCDCoH0KPj4gKwo+PiAr
IMKgIMKgZmxleGFycmF5X3NldChmX2FyZ3MsIG5yKyssIHNjcmlwdCk7Cj4+ICsgwqAgwqBmbGV4
YXJyYXlfc2V0KGZfYXJncywgbnIrKywgYWN0aW9uID09IENPTk5FQ1QgPyAib25saW5lIiA6Cj4+
ICJvZmZsaW5lIik7Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfYXJncywgbnIrKywgInR5cGVf
aWY9dmlmIik7Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfYXJncywgbnIrKywgTlVMTCk7Cj4+
ICsKPj4gKyDCoCDCoGFyZ3MgPSAoY2hhciAqKikgZmxleGFycmF5X2NvbnRlbnRzKGZfYXJncyk7
Cj4+ICsgwqAgwqB3aGF0ID0gbGlieGxfX3NwcmludGYoZ2MsICIlcyAlcyIsIGFyZ3NbMF0sCj4+
ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhY3Rpb24gPT0gQ09OTkVD
VCA/ICJjb25uZWN0IiA6ICJkaXNjb25uZWN0Iik7Cj4+ICsgwqAgwqBMSUJYTF9fTE9HKGN0eCwg
TElCWExfX0xPR19ERUJVRywKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCAiQ2FsbGluZyBob3Rw
bHVnIHNjcmlwdDogJXMgJXMgJXMiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZ3NbMF0s
IGFyZ3NbMV0sIGFyZ3NbMl0pOwo+PiArIMKgIMKgc3RhdHVzID0gbGlieGxfX2ZvcmtleGVjKGdj
LCAtMSwgLTEsIC0xLCBhcmdzWzBdLCBhcmdzLCBlbnYsIHdoYXQpOwo+PiArIMKgIMKgaWYgKHN0
YXR1cykgewo+PiArIMKgIMKgIMKgIMKgcmMgPSAtMTsKPj4gKyDCoCDCoCDCoCDCoGdvdG8gb3V0
Owo+PiArIMKgIMKgfQo+PiArIMKgIMKgcmMgPSAwOwo+PiArCj4+ICtvdXQ6Cj4+ICsgwqAgwqBm
cmVlKGVudik7Cj4+ICsgwqAgwqBmcmVlKGFyZ3MpOwo+PiArIMKgIMKgcmV0dXJuIHJjOwo+PiAr
fQo+PiArCj4+ICtzdGF0aWMgaW50IGxpYnhsX19ob3RwbHVnX2Rpc2sobGlieGxfX2djICpnYywg
bGlieGxfX2RldmljZSAqZGV2LAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IGxpYnhsX19ob3RwbHVnX2FjdGlvbiBhY3Rpb24pCj4+ICt7Cj4+ICsgwqAgwqBsaWJ4bF9jdHgg
KmN0eCA9IGxpYnhsX19nY19vd25lcihnYyk7Cj4+ICsgwqAgwqBjaGFyICpiZV9wYXRoID0gbGli
eGxfX2RldmljZV9iYWNrZW5kX3BhdGgoZ2MsIGRldik7Cj4+ICsgwqAgwqBjaGFyICpzY3JpcHQs
ICp3aGF0Owo+PiArIMKgIMKgY2hhciAqKmFyZ3MsICoqZW52Owo+PiArIMKgIMKgaW50IHN0YXR1
cywgbnIgPSAwOwo+PiArIMKgIMKgaW50IHJjID0gLTE7Cj4+ICsgwqAgwqBmbGV4YXJyYXlfdCAq
Zl9hcmdzOwo+PiArCj4+ICsgwqAgwqBzY3JpcHQgPSBsaWJ4bF9feHNfcmVhZChnYywgWEJUX05V
TEwsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWJ4bF9f
c3ByaW50ZihnYywgIiVzLyVzIiwgYmVfcGF0aCwKPj4gInNjcmlwdCIpKTsKPj4gKyDCoCDCoGlm
ICghc2NyaXB0KSB7Cj4+ICsgwqAgwqAgwqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19F
UlJPUiwgInVuYWJsZSB0byByZWFkIHNjcmlwdCBmcm9tCj4+ICVzIiwKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJlX3Bh
dGgpOwo+PiArIMKgIMKgIMKgIMKgcmV0dXJuIC0xOwo+PiArIMKgIMKgfQo+PiArCj4+ICsgwqAg
wqBlbnYgPSBnZXRfaG90cGx1Z19lbnYoZ2MsIGRldik7Cj4+ICsgwqAgwqBpZiAoIWVudikKPj4g
KyDCoCDCoCDCoCDCoHJldHVybiAtMTsKPj4gKwo+PiArIMKgIMKgZl9hcmdzID0gZmxleGFycmF5
X21ha2UoMywgMSk7Cj4+ICsgwqAgwqBpZiAoIWZfYXJncykgewo+PiArIMKgIMKgIMKgIMKgTElC
WExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gY3JlYXRlIGFyZ3VtZW50
cwo+PiBhcnJheSIpOwo+PiArIMKgIMKgIMKgIMKgcmV0dXJuIC0xOwo+PiArIMKgIMKgfQo+PiAr
Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfYXJncywgbnIrKywgc2NyaXB0KTsKPj4gKyDCoCDC
oGZsZXhhcnJheV9zZXQoZl9hcmdzLCBucisrLCBhY3Rpb24gPT0gQ09OTkVDVCA/ICJhZGQiIDog
InJlbW92ZSIpOwo+PiArIMKgIMKgZmxleGFycmF5X3NldChmX2FyZ3MsIG5yKyssIE5VTEwpOwo+
PiArCj4+ICsgwqAgwqBhcmdzID0gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhmX2FyZ3Mp
Owo+PiArIMKgIMKgd2hhdCA9IGxpYnhsX19zcHJpbnRmKGdjLCAiJXMgJXMiLCBhcmdzWzBdLAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWN0aW9uID09IENPTk5F
Q1QgPyAiY29ubmVjdCIgOiAiZGlzY29ubmVjdCIpOwo+PiArIMKgIMKgTElCWExfX0xPRyhjdHgs
IExJQlhMX19MT0dfREVCVUcsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgIkNhbGxpbmcgaG90
cGx1ZyBzY3JpcHQ6ICVzICVzIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcmdzWzBdLCBh
cmdzWzFdKTsKPj4gKyDCoCDCoHN0YXR1cyA9IGxpYnhsX19mb3JrZXhlYyhnYywgLTEsIC0xLCAt
MSwgYXJnc1swXSwgYXJncywgZW52LCB3aGF0KTsKPj4gKyDCoCDCoGlmIChzdGF0dXMpIHsKPj4g
KyDCoCDCoCDCoCDCoHJjID0gLTE7Cj4+ICsgwqAgwqAgwqAgwqBnb3RvIG91dDsKPj4gKyDCoCDC
oH0KPj4gKyDCoCDCoHJjID0gMDsKPj4gKwo+PiArb3V0Ogo+PiArIMKgIMKgZnJlZShlbnYpOwo+
PiArIMKgIMKgZnJlZShhcmdzKTsKPj4gKyDCoCDCoHJldHVybiByYzsKPj4gK30KPj4gKyNlbmRp
ZiAvKiAwICovCj4+IMKgaW50IGxpYnhsX19kZXZpY2VfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBs
aWJ4bF9fZGV2aWNlICpkZXYsCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGxpYnhsX19ob3RwbHVnX2FjdGlvbiBhY3Rpb24pCj4+IMKgewo+PiAtIMKgIMKgcmV0dXJu
IDA7Cj4+ICsgwqAgwqBpbnQgcmMgPSAwOwo+PiArI2lmIDAKPj4gKyDCoCDCoHN3aXRjaCAoZGV2
LT5iYWNrZW5kX2tpbmQpIHsKPj4gKyDCoCDCoGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZJRjoK
Pj4gKyDCoCDCoCDCoCDCoHJjID0gbGlieGxfX2hvdHBsdWdfbmljKGdjLCBkZXYsIGFjdGlvbik7
Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoGNhc2UgTElCWExfX0RFVklDRV9LSU5E
X1ZCRDoKPj4gKyDCoCDCoCDCoCDCoHJjID0gbGlieGxfX2hvdHBsdWdfZGlzayhnYywgZGV2LCBh
Y3Rpb24pOwo+PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqBkZWZhdWx0Ogo+PiArIMKg
IMKgIMKgIMKgcmMgPSAwOwo+PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqB9Cj4+ICsj
ZW5kaWYgLyogMCAqLwo+PiArIMKgIMKgcmV0dXJuIHJjOwo+PiDCoH0KPj4KPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 07 09:05:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 09:05:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rugz5-0001RX-Sj; Tue, 07 Feb 2012 09:05:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rugz3-0001RS-Uy
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 09:05:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328605499!5777463!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16631 invoked from network); 7 Feb 2012 09:04:59 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 09:04:59 -0000
Received: by wgbdr13 with SMTP id dr13so6318215wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 01:04:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=4jVsQPx3ZfObU82+ibL3Nbql2nbIcsrlZoSc7joJkxk=;
	b=GId6TVoSxyZhEMk0frgMwz38vQAAP7KEUe5Ult8Ol5dUAORmARL6w5z+3Gq+LlJ+bT
	f6YGN+EvdeXDpRWRKrtR8UvCsVBqs1VoXk/hmrVcV559CjivMMFxbV8wklxGOE76P4lk
	W7iUKwCVmrw2cNSv1K9VwSNfOkQ3mvGFpweWA=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr30896269wiy.1.1328605499193; Tue,
	07 Feb 2012 01:04:59 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 7 Feb 2012 01:04:59 -0800 (PST)
In-Reply-To: <CAP8mzPPqi5zSt_c+SAXOLUjL+DdmyZr7rE8cgfM_08CM3FgJiw@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<98a4f01033786a2fc15b.1328189208@debian.localdomain>
	<CAP8mzPPqi5zSt_c+SAXOLUjL+DdmyZr7rE8cgfM_08CM3FgJiw@mail.gmail.com>
Date: Tue, 7 Feb 2012 10:04:59 +0100
X-Google-Sender-Auth: 4_dsRaacMdfjOS-N9aG-ls2lNcY
Message-ID: <CAPLaKK50F8EWRcty-oVn4j5mo1BVGLr1Ue9ySVTFXPu4HR2vBw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: rshriram@cs.ubc.ca
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 29 RFC] libxl: add hotplug script
 calls for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzcgU2hyaXJhbSBSYWphZ29wYWxhbiA8cnNocmlyYW1AY3MudWJjLmNhPjoKPiBPbiBU
aHUsIEZlYiAyLCAyMDEyIGF0IDU6MjYgQU0sIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+Cj4gd3JvdGU6Cj4+Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNl
ciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMy
ODE3NzU5MSAtMzYwMAo+PiAjIE5vZGUgSUQgOThhNGYwMTAzMzc4NmEyZmMxNWI0MTMwODk3YzM1
ZjY0YTY3NmU0MAo+PiAjIFBhcmVudCDCoDZjMjY5MDkyMWZiYTU4MGRkN2RkODM2ZGEzYmU0ODRk
ZWUwNDliZTAKPj4gbGlieGw6IGFkZCBob3RwbHVnIHNjcmlwdCBjYWxscyBmb3IgTGludXgKPj4K
Pj4gVGhpcyBwYXRjaHMgYWRkcyB0aGUgbmVjZXNzYXJ5IGxvZ2ljIHRvIGNhbGwgaG90cGx1ZyBz
Y3JpcHRzIGRpcmVjdGx5Cj4+IGZyb20gbGlieGwuIExpbnV4IGhvdHBsdWcgc2NyaXRwcyByZWFk
IG1vc3QgcGFyYW1ldGVycyBmcm9tIHRoZSBjYWxsZXIKPj4gZW52aXJvbm1lbnQgKHNpbmNlIHVk
ZXYgc2V0IHRoaXMgcGFyYW1ldGVycyBhdXRvbWF0aWNhbGx5KS4gSW4gdGhpcwo+PiBpbXBsZW1l
bnRhdGlvbiB3ZSBmYWtlIHVkZXYgcGFyYW1ldGVycywgc28gbm8gY2hhbmdlcyBhcmUgbmVlZGVk
IHRvCj4+IHRoZSBzY3JpcHRzIGl0c2VsZi4KPj4KPj4gQ3VycmVudGx5LCB0aGUgZm9sbG93aW5n
IHNjcmlwdHMgYXJlIGNhbGxlZDoKPj4KPj4gwqAqIGJsb2NrOiB1c2VkIHdoZW4gZGlzayBiYWNr
ZW5kIGlzIFBIWS4KPj4KPj4gwqAqIGJsa3RhcDogdXNlZCB3aGVuIGRpc2sgYmFja2VuZCBpcyBU
QVAuCj4+Cj4KPiBTb3JyeSBpZiB0aGlzIGlzIGEgYml0IGRlbnNlLCBidXQgeW91IGhhdmUgYmVl
biB0aHJvdWdoIHRoZSBjb2RlCj4gYWxyZWFkeSA7KQo+IElzIHRoZXJlIGFuIG9wdGlvbiB0byBj
YWxsIG90aGVyIHNjcmlwdHMgb3RoZXIgdGhhbiBibG9jay9ibGt0YXAgPwoKbGlieGwgaGFzIHNv
bWUgcHJlbGltaW5hcnkgc3VwcG9ydCBmb3Igc2V0dGluZyBjdXN0b20gaG90cGx1ZyBzY3JpcHRz
CmZvciBoYXJkIGRyaXZlcyBpbiBjb25maWd1cmF0aW9uIGZpbGVzIChqdXN0IGxpa2UgeW91IGRv
IGZvciBuaWMKaW50ZXJmYWNlcyksIHRoaXMgaXMgY3VycmVudGx5IGRpc2FibGVkIGJ1dCBjb3Vs
ZCBiZSBlbmFibGVkIGluIGZ1dHVyZQpyZWxlYXNlcy4KCj4gRm9yIGUuZy4sIGlmIEkgd2VyZSB0
byBhZGQgYSBiYWNrZW5kIHR5cGUgRFJCRC9GT09CQVIsCj4gYW5kIHdpc2ggdG8gY2FsbCBzY3Jp
cHQgImJsb2NrLTxkcmJkfGZvb2Jhcj4sIGhvdyBkbyB5b3Ugc3VnZ2VzdCBJCj4gcHJvY2VlZCA/
CgpXZWxsLCBJIHNlZSBzZXZlcmFsIGFwcHJvYWNoZXMgaGVyZSwgcmlnaHQgbm93IHdlIGNhbGwg
TGludXggaG90cGx1ZwpzY3JpcHRzIGFkZGluZyB0aGUgbmVjZXNzYXJ5IGVudiB2YXJpYWJsZXMs
IHNpbmNlIHVkZXYgdXNlZCB0byBzZXQKdGhvc2UgdmFyaWFibGVzIGF1dG9tYXRpY2FsbHksIGFu
ZCB3ZSB3aWxsIGNvbnRpbnVlIHRvIGRvIGl0IHRoYXQgd2F5CnVudGlsIHhlbmQgaXMgcmVtb3Zl
ZC4gSSB0aGluayBpdCdzIG1vc3Qgc3VpdGFibGUgdG8gcGFzcyB0aG9zZQpwYXJhbWV0ZXJzIGFz
IGFyZ3VtZW50cyB0byB0aGUgc2NyaXB0LCBidXQgdGhpcyBhcyBJIHNhaWQgYmVmb3JlIGlzIGEK
bG9uZyB0ZXJtIGdvYWwuCgo+IMKgIFN0YXJ0IG15IHdheSBmcm9tIGRlZmluaW5nIG5ldyBkaXNr
IGJhY2tlbmQgdHlwZXMgYW5kIGp1c3QgYWRkCj4gaG90cGx1ZyBoYW5kbGVycyBmb3IgdGhlc2Ug
YmxvY2stKiBkZXZpY2VzIGFuZCBmaW5hbGx5IGV4cG9zZSB0aGVtIGFzCj4gcGh5IGRldmljZXMg
dG8gbGlieGwgPwoKVGhhdCdzIHJlYWxseSB1cCB0byB5b3UsIGJ1dCBpZiB5b3Ugd2FudCB0byBw
YXNzIHRoZW0gYXMgUEhZIGRldmljZXMsCnlvdSBzaG91bGQgbW9kaWZ5IHRoZSBsaWJ4bF9fdHJ5
X3BoeV9iYWNrZW5kIGZ1bmN0aW9uIGluc2lkZQpsaWJ4bF9saW51eC5jIGFuZCBsaWJ4bF9uZXRi
c2QuYy4gSWYgeW91IHdhbnQgdGhpcyBjaGFuZ2VzIHRvIGJlIGFkZGVkCnRvIHVwc3RyZWFtIGl0
IG1pZ2h0IGJlIGJlc3QgdG8gZGVmaW5lIHlvdXIgb3duIGJhY2tlbmQgdHlwZSwKb3ZlcmxvYWRp
bmcgdGhlIFBIWSB0eXBlIGl0J3Mgbm90IGNsZWFyZXIsIGFuZCBQSFkgc2hvdWxkIG9ubHkgYmUg
dXNlZApmb3IgcGh5c2ljYWwgcGFydGl0aW9ucyAoYWdhaW4sIHNpbmNlIEkgZG9uJ3Qga25vdyB5
b3VyIHNwZWNpZmljCmltcGxlbWVudGF0aW9uLCBJIGNhbm5vdCBiZSBzdXJlIG9mIHRoZSBtb3N0
IHN1aXRhYmxlIHdheSB0byB0YWNrbGUKdGhpcyBwcm9ibGVtKS4KCj4KPiBzaHJpcmFtCj4KPj4K
Pj4gwqAqIHZpZi0qOiB1c2VkIHdoZW4gYWRkaW5nIGEgbmV0d29yayBpbnRlcmZhY2UgYW5kIGNh
biBiZSBtYW51YWxseSBzZXQKPj4gwqAgYnkgdGhlIHVzZXIuCj4+Cj4+IHVkZXYgcnVsZXMgZGVz
Y3JpdmUgbW9yZSBkZXZpY2UgdHlwZXMsIGN1cnJlbnRseSB0aGUgZm9sbG93aW5nIHNjcmlwdHMK
Pj4gYXJlIE5PVCBleGVjdXRlZCBmcm9tIGxpYnhsIGJlY2F1c2UgSSB3YXNuJ3QgYWJsZSB0byBm
aW5kIGFueSBzdXBwb3J0Cj4+IGZvciB0aGlzIGRldmljZSB0eXBlcyBpbiBsaWJ4bDoKPj4KPj4g
wqAqIHZ0cG0KPj4KPj4gwqAqIHZpZjIKPj4KPj4gwqAqIHZzY3NpCj4+Cj4+IMKgKiB2aWYtc2V0
dXAgd2l0aCBkZXZpY2VzIG9mIHR5cGUgdGFwKgo+Pgo+PiBUaGlzIHBhdGNoIGp1c3QgYWRkcyB0
aGUgbmVjZXNzYXJ5IGNvZGUsIGJ1dCBob3RwbHVnIHNjcmlwdHMgYXJlIE5PVAo+PiBjYWxsZWQg
ZnJvbSBsaWJ4bCB5ZXQsIGZvbGxvd2luZyBwYXRjaGVzIHdpbGwgZGlzYWJsZSB1ZGV2IHJ1bGVz
IGFuZAo+PiB1c2UgdGhpcyBjYWxscyBpbnN0ZWFkLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dl
ciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pgo+PiBkaWZmIC1yIDZjMjY5
MDkyMWZiYSAtciA5OGE0ZjAxMDMzNzggdG9vbHMvbGlieGwvbGlieGxfbGludXguYwo+PiAtLS0g
YS90b29scy9saWJ4bC9saWJ4bF9saW51eC5jIFRodSBGZWIgMDIgMTE6MTA6MjQgMjAxMiArMDEw
MAo+PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9saW51eC5jIFRodSBGZWIgMDIgMTE6MTM6MTEg
MjAxMiArMDEwMAo+PiBAQCAtMjYsMTAgKzI2LDE3MiBAQCBpbnQgbGlieGxfX3RyeV9waHlfYmFj
a2VuZChtb2RlX3Qgc3RfbW9kCj4+IMKgIMKgIHJldHVybiAxOwo+PiDCoH0KPj4KPj4gKy8qIEhv
dHBsdWcgc2NyaXB0cyBoZWxwZXJzICovCj4+ICsjaWYgMAo+PiArc3RhdGljIGNoYXIgKipnZXRf
aG90cGx1Z19lbnYobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAqZGV2KQo+PiArewo+PiAr
IMKgIMKgbGlieGxfY3R4ICpjdHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+PiArIMKgIMKgY2hh
ciAqYmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfYmFja2VuZF9wYXRoKGdjLCBkZXYpOwo+PiArIMKg
IMKgZmxleGFycmF5X3QgKmZfZW52Owo+PiArIMKgIMKgaW50IG5yID0gMDsKPj4gKwo+PiArIMKg
IMKgZl9lbnYgPSBmbGV4YXJyYXlfbWFrZSgxMSwgMSk7Cj4+ICsgwqAgwqBpZiAoIWZfZW52KSB7
Cj4+ICsgwqAgwqAgwqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAidW5hYmxlIHRvIGNyZWF0ZSBlbnZpcm9ubWVudCBh
cnJheSIpOwo+PiArIMKgIMKgIMKgIMKgcmV0dXJuIE5VTEw7Cj4+ICsgwqAgwqB9Cj4+ICsKPj4g
KyDCoCDCoGZsZXhhcnJheV9zZXQoZl9lbnYsIG5yKyssICJzY3JpcHQiKTsKPj4gKyDCoCDCoGZs
ZXhhcnJheV9zZXQoZl9lbnYsIG5yKyssIGxpYnhsX194c19yZWFkKGdjLCBYQlRfTlVMTCwKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaWJ4bF9fc3By
aW50ZihnYywgIiVzLyVzIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJlX3BhdGgsCj4+ICsgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAic2NyaXB0IikpKTsKPj4gKyDCoCDCoGZsZXhhcnJheV9zZXQoZl9lbnYsIG5yKyssICJYRU5C
VVNfVFlQRSIpOwo+PiArIMKgIMKgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywgKGNoYXIgKikK
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19kZXZpY2Vfa2luZF90b19zdHJp
bmcoZGV2LT5iYWNrZW5kX2tpbmQpKTsKPj4gKyDCoCDCoGZsZXhhcnJheV9zZXQoZl9lbnYsIG5y
KyssICJYRU5CVVNfUEFUSCIpOwo+PiArIMKgIMKgZmxleGFycmF5X3NldChmX2VudiwgbnIrKywK
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19zcHJpbnRmKGdjLCAiYmFja2Vu
ZC8lcy8ldS8lZCIsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWJ4bF9fZGV2aWNl
X2tpbmRfdG9fc3RyaW5nKGRldi0+YmFja2VuZF9raW5kKSwKPj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoGRldi0+ZG9taWQsIGRldi0+ZGV2aWQpKTsKPj4gKyDCoCDCoGZsZXhhcnJheV9z
ZXQoZl9lbnYsIG5yKyssICJYRU5CVVNfQkFTRV9QQVRIIik7Cj4+ICsgwqAgwqBmbGV4YXJyYXlf
c2V0KGZfZW52LCBucisrLCAiYmFja2VuZCIpOwo+PiArIMKgIMKgaWYgKGRldi0+YmFja2VuZF9r
aW5kID09IExJQlhMX19ERVZJQ0VfS0lORF9WSUYpIHsKPj4gKyDCoCDCoCDCoCDCoGZsZXhhcnJh
eV9zZXQoZl9lbnYsIG5yKyssICJ2aWYiKTsKPj4gKyDCoCDCoCDCoCDCoGZsZXhhcnJheV9zZXQo
Zl9lbnYsIG5yKyssCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWJ4bF9f
c3ByaW50ZihnYywgIiVzJXUuJWQiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgbGlieGxfX2RldmljZV9raW5kX3RvX3N0cmluZyhkZXYtPmJhY2tlbmRfa2luZCksCj4+ICsg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXYtPmRvbWlkLCBkZXYtPmRldmlkKSk7
Cj4+ICsgwqAgwqB9Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfZW52LCBucisrLCBOVUxMKTsK
Pj4gKwo+PiArIMKgIMKgcmV0dXJuIChjaGFyICoqKSBmbGV4YXJyYXlfY29udGVudHMoZl9lbnYp
Owo+PiArfQo+PiArCj4+IMKgLyogSG90cGx1ZyBzY3JpcHRzIGNhbGxlciBmdW5jdGlvbnMgKi8K
Pj4KPj4gK3N0YXRpYyBpbnQgbGlieGxfX2hvdHBsdWdfbmljKGxpYnhsX19nYyAqZ2MsIGxpYnhs
X19kZXZpY2UgKmRldiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaWJ4
bF9faG90cGx1Z19hY3Rpb24gYWN0aW9uKQo+PiArewo+PiArIMKgIMKgbGlieGxfY3R4ICpjdHgg
PSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwo+PiArIMKgIMKgY2hhciAqYmVfcGF0aCA9IGxpYnhsX19k
ZXZpY2VfYmFja2VuZF9wYXRoKGdjLCBkZXYpOwo+PiArIMKgIMKgY2hhciAqc2NyaXB0LCAqd2hh
dDsKPj4gKyDCoCDCoGNoYXIgKiphcmdzLCAqKmVudjsKPj4gKyDCoCDCoGludCBzdGF0dXMsIG5y
ID0gMDsKPj4gKyDCoCDCoGludCByYyA9IC0xOwo+PiArIMKgIMKgZmxleGFycmF5X3QgKmZfYXJn
czsKPj4gKwo+PiArIMKgIMKgc2NyaXB0ID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxMLAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlieGxfX3Nwcmlu
dGYoZ2MsICIlcy8lcyIsIGJlX3BhdGgsCj4+ICJzY3JpcHQiKSk7Cj4+ICsgwqAgwqBpZiAoIXNj
cmlwdCkgewo+PiArIMKgIMKgIMKgIMKgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1Is
ICJ1bmFibGUgdG8gcmVhZCBzY3JpcHQgZnJvbQo+PiAlcyIsCj4+ICsgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZV9wYXRoKTsK
Pj4gKyDCoCDCoCDCoCDCoHJldHVybiAtMTsKPj4gKyDCoCDCoH0KPj4gKwo+PiArIMKgIMKgZW52
ID0gZ2V0X2hvdHBsdWdfZW52KGdjLCBkZXYpOwo+PiArIMKgIMKgaWYgKCFlbnYpCj4+ICsgwqAg
wqAgwqAgwqByZXR1cm4gLTE7Cj4+ICsKPj4gKyDCoCDCoGZfYXJncyA9IGZsZXhhcnJheV9tYWtl
KDQsIDEpOwo+PiArIMKgIMKgaWYgKCFmX2FyZ3MpIHsKPj4gKyDCoCDCoCDCoCDCoExJQlhMX19M
T0coY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAidW5hYmxlIHRvIGNyZWF0ZSBhcmd1bWVudHMKPj4g
YXJyYXkiKTsKPj4gKyDCoCDCoCDCoCDCoHJldHVybiAtMTsKPj4gKyDCoCDCoH0KPj4gKwo+PiAr
IMKgIMKgZmxleGFycmF5X3NldChmX2FyZ3MsIG5yKyssIHNjcmlwdCk7Cj4+ICsgwqAgwqBmbGV4
YXJyYXlfc2V0KGZfYXJncywgbnIrKywgYWN0aW9uID09IENPTk5FQ1QgPyAib25saW5lIiA6Cj4+
ICJvZmZsaW5lIik7Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfYXJncywgbnIrKywgInR5cGVf
aWY9dmlmIik7Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfYXJncywgbnIrKywgTlVMTCk7Cj4+
ICsKPj4gKyDCoCDCoGFyZ3MgPSAoY2hhciAqKikgZmxleGFycmF5X2NvbnRlbnRzKGZfYXJncyk7
Cj4+ICsgwqAgwqB3aGF0ID0gbGlieGxfX3NwcmludGYoZ2MsICIlcyAlcyIsIGFyZ3NbMF0sCj4+
ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhY3Rpb24gPT0gQ09OTkVD
VCA/ICJjb25uZWN0IiA6ICJkaXNjb25uZWN0Iik7Cj4+ICsgwqAgwqBMSUJYTF9fTE9HKGN0eCwg
TElCWExfX0xPR19ERUJVRywKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCAiQ2FsbGluZyBob3Rw
bHVnIHNjcmlwdDogJXMgJXMgJXMiLAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZ3NbMF0s
IGFyZ3NbMV0sIGFyZ3NbMl0pOwo+PiArIMKgIMKgc3RhdHVzID0gbGlieGxfX2ZvcmtleGVjKGdj
LCAtMSwgLTEsIC0xLCBhcmdzWzBdLCBhcmdzLCBlbnYsIHdoYXQpOwo+PiArIMKgIMKgaWYgKHN0
YXR1cykgewo+PiArIMKgIMKgIMKgIMKgcmMgPSAtMTsKPj4gKyDCoCDCoCDCoCDCoGdvdG8gb3V0
Owo+PiArIMKgIMKgfQo+PiArIMKgIMKgcmMgPSAwOwo+PiArCj4+ICtvdXQ6Cj4+ICsgwqAgwqBm
cmVlKGVudik7Cj4+ICsgwqAgwqBmcmVlKGFyZ3MpOwo+PiArIMKgIMKgcmV0dXJuIHJjOwo+PiAr
fQo+PiArCj4+ICtzdGF0aWMgaW50IGxpYnhsX19ob3RwbHVnX2Rpc2sobGlieGxfX2djICpnYywg
bGlieGxfX2RldmljZSAqZGV2LAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IGxpYnhsX19ob3RwbHVnX2FjdGlvbiBhY3Rpb24pCj4+ICt7Cj4+ICsgwqAgwqBsaWJ4bF9jdHgg
KmN0eCA9IGxpYnhsX19nY19vd25lcihnYyk7Cj4+ICsgwqAgwqBjaGFyICpiZV9wYXRoID0gbGli
eGxfX2RldmljZV9iYWNrZW5kX3BhdGgoZ2MsIGRldik7Cj4+ICsgwqAgwqBjaGFyICpzY3JpcHQs
ICp3aGF0Owo+PiArIMKgIMKgY2hhciAqKmFyZ3MsICoqZW52Owo+PiArIMKgIMKgaW50IHN0YXR1
cywgbnIgPSAwOwo+PiArIMKgIMKgaW50IHJjID0gLTE7Cj4+ICsgwqAgwqBmbGV4YXJyYXlfdCAq
Zl9hcmdzOwo+PiArCj4+ICsgwqAgwqBzY3JpcHQgPSBsaWJ4bF9feHNfcmVhZChnYywgWEJUX05V
TEwsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWJ4bF9f
c3ByaW50ZihnYywgIiVzLyVzIiwgYmVfcGF0aCwKPj4gInNjcmlwdCIpKTsKPj4gKyDCoCDCoGlm
ICghc2NyaXB0KSB7Cj4+ICsgwqAgwqAgwqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19F
UlJPUiwgInVuYWJsZSB0byByZWFkIHNjcmlwdCBmcm9tCj4+ICVzIiwKPj4gKyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJlX3Bh
dGgpOwo+PiArIMKgIMKgIMKgIMKgcmV0dXJuIC0xOwo+PiArIMKgIMKgfQo+PiArCj4+ICsgwqAg
wqBlbnYgPSBnZXRfaG90cGx1Z19lbnYoZ2MsIGRldik7Cj4+ICsgwqAgwqBpZiAoIWVudikKPj4g
KyDCoCDCoCDCoCDCoHJldHVybiAtMTsKPj4gKwo+PiArIMKgIMKgZl9hcmdzID0gZmxleGFycmF5
X21ha2UoMywgMSk7Cj4+ICsgwqAgwqBpZiAoIWZfYXJncykgewo+PiArIMKgIMKgIMKgIMKgTElC
WExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8gY3JlYXRlIGFyZ3VtZW50
cwo+PiBhcnJheSIpOwo+PiArIMKgIMKgIMKgIMKgcmV0dXJuIC0xOwo+PiArIMKgIMKgfQo+PiAr
Cj4+ICsgwqAgwqBmbGV4YXJyYXlfc2V0KGZfYXJncywgbnIrKywgc2NyaXB0KTsKPj4gKyDCoCDC
oGZsZXhhcnJheV9zZXQoZl9hcmdzLCBucisrLCBhY3Rpb24gPT0gQ09OTkVDVCA/ICJhZGQiIDog
InJlbW92ZSIpOwo+PiArIMKgIMKgZmxleGFycmF5X3NldChmX2FyZ3MsIG5yKyssIE5VTEwpOwo+
PiArCj4+ICsgwqAgwqBhcmdzID0gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhmX2FyZ3Mp
Owo+PiArIMKgIMKgd2hhdCA9IGxpYnhsX19zcHJpbnRmKGdjLCAiJXMgJXMiLCBhcmdzWzBdLAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWN0aW9uID09IENPTk5F
Q1QgPyAiY29ubmVjdCIgOiAiZGlzY29ubmVjdCIpOwo+PiArIMKgIMKgTElCWExfX0xPRyhjdHgs
IExJQlhMX19MT0dfREVCVUcsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgIkNhbGxpbmcgaG90
cGx1ZyBzY3JpcHQ6ICVzICVzIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcmdzWzBdLCBh
cmdzWzFdKTsKPj4gKyDCoCDCoHN0YXR1cyA9IGxpYnhsX19mb3JrZXhlYyhnYywgLTEsIC0xLCAt
MSwgYXJnc1swXSwgYXJncywgZW52LCB3aGF0KTsKPj4gKyDCoCDCoGlmIChzdGF0dXMpIHsKPj4g
KyDCoCDCoCDCoCDCoHJjID0gLTE7Cj4+ICsgwqAgwqAgwqAgwqBnb3RvIG91dDsKPj4gKyDCoCDC
oH0KPj4gKyDCoCDCoHJjID0gMDsKPj4gKwo+PiArb3V0Ogo+PiArIMKgIMKgZnJlZShlbnYpOwo+
PiArIMKgIMKgZnJlZShhcmdzKTsKPj4gKyDCoCDCoHJldHVybiByYzsKPj4gK30KPj4gKyNlbmRp
ZiAvKiAwICovCj4+IMKgaW50IGxpYnhsX19kZXZpY2VfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBs
aWJ4bF9fZGV2aWNlICpkZXYsCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGxpYnhsX19ob3RwbHVnX2FjdGlvbiBhY3Rpb24pCj4+IMKgewo+PiAtIMKgIMKgcmV0dXJu
IDA7Cj4+ICsgwqAgwqBpbnQgcmMgPSAwOwo+PiArI2lmIDAKPj4gKyDCoCDCoHN3aXRjaCAoZGV2
LT5iYWNrZW5kX2tpbmQpIHsKPj4gKyDCoCDCoGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZJRjoK
Pj4gKyDCoCDCoCDCoCDCoHJjID0gbGlieGxfX2hvdHBsdWdfbmljKGdjLCBkZXYsIGFjdGlvbik7
Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoGNhc2UgTElCWExfX0RFVklDRV9LSU5E
X1ZCRDoKPj4gKyDCoCDCoCDCoCDCoHJjID0gbGlieGxfX2hvdHBsdWdfZGlzayhnYywgZGV2LCBh
Y3Rpb24pOwo+PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqBkZWZhdWx0Ogo+PiArIMKg
IMKgIMKgIMKgcmMgPSAwOwo+PiArIMKgIMKgIMKgIMKgYnJlYWs7Cj4+ICsgwqAgwqB9Cj4+ICsj
ZW5kaWYgLyogMCAqLwo+PiArIMKgIMKgcmV0dXJuIHJjOwo+PiDCoH0KPj4KPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 07 09:13:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 09: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.xensource.com>)
	id 1Ruh6t-0001dM-1Y; Tue, 07 Feb 2012 09:13:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Ruh6r-0001dC-FJ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 09:13:09 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328605982!10395834!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2871 invoked from network); 7 Feb 2012 09:13:03 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-7.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 09:13:03 -0000
Received: from mail66-ch1-R.bigfish.com (10.43.68.248) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 09:13:01 +0000
Received: from mail66-ch1 (localhost [127.0.0.1])	by mail66-ch1-R.bigfish.com
	(Postfix) with ESMTP id 260A7320098;
	Tue,  7 Feb 2012 09:13:01 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1444M1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail66-ch1 (localhost.localdomain [127.0.0.1]) by mail66-ch1
	(MessageSwitch) id 1328605979238620_10021;
	Tue,  7 Feb 2012 09:12:59 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.237])	by mail66-ch1.bigfish.com (Postfix) with ESMTP id
	2CA9138020B;	Tue,  7 Feb 2012 09:12:59 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 09:12:59 +0000
X-WSS-ID: 0LZ0MXL-02-1Q8-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 2F51EFCC004;	Tue,  7 Feb 2012 03:12:56 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 7 Feb 2012 03:13:04 -0600
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.289.1;
	Tue, 7 Feb 2012 03:12:56 -0600
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, 7 Feb 2012
	04:12:56 -0500
Message-ID: <4F30EB15.9000308@amd.com>
Date: Tue, 7 Feb 2012 10:12:53 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
	<4F301F8B.5010306@amd.com>
In-Reply-To: <4F301F8B.5010306@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/06/12 19:44, Boris Ostrovsky wrote:
> On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote:
>> On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> # Date 1328549858 -3600
>>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>>> # Parent e2722b24dc0962de37215320b05d1bb7c4c42864
>>> x86/AMD: Add support for AMD's OSVW feature in guests.
>>>
>>> In some cases guests should not provide workarounds for errata even
>>> when the
>>> physical processor is affected. For example, because of erratum 400
>>> on family
>>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT)
>>> before
>>> going to idle in order to avoid getting stuck in a non-C0 state. This
>>> is not
>>
>> What about fixing the Linux guest to actually not do this? I presume you
>> have encountered this with HVM guests - would it be possible to use
>>
>> set_pm_idle_to_default(default_idle) in the HVM bootup path, say in
>> 'xen_hvm_guest_init' ??
>
>
> Changing Linux won't help guests running Linux prior to the change so we
> still need this patch. And with the patch guest's pm_idle will be set to
> default_idle anyway (because cpu_has_amd_erratum(amd_erratum_400) will
> return 0).

Right. Also fixing Linux won't help non-Linux guests, too.

Christoph


>
>
> -boris
>
>>
>>
>>> necessary: HLT and IO instructions are intercepted and therefore
>>> there is no
>>> reason for erratum 400 workaround in the guest.
>>>
>>> This patch allows us to present a guest with certain errata as fixed,
>>> regardless of the state of actual hardware.
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 09:13:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 09: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.xensource.com>)
	id 1Ruh6t-0001dM-1Y; Tue, 07 Feb 2012 09:13:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Ruh6r-0001dC-FJ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 09:13:09 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328605982!10395834!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2871 invoked from network); 7 Feb 2012 09:13:03 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-7.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 09:13:03 -0000
Received: from mail66-ch1-R.bigfish.com (10.43.68.248) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 09:13:01 +0000
Received: from mail66-ch1 (localhost [127.0.0.1])	by mail66-ch1-R.bigfish.com
	(Postfix) with ESMTP id 260A7320098;
	Tue,  7 Feb 2012 09:13:01 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI1444M1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail66-ch1 (localhost.localdomain [127.0.0.1]) by mail66-ch1
	(MessageSwitch) id 1328605979238620_10021;
	Tue,  7 Feb 2012 09:12:59 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.237])	by mail66-ch1.bigfish.com (Postfix) with ESMTP id
	2CA9138020B;	Tue,  7 Feb 2012 09:12:59 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 09:12:59 +0000
X-WSS-ID: 0LZ0MXL-02-1Q8-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 2F51EFCC004;	Tue,  7 Feb 2012 03:12:56 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 7 Feb 2012 03:13:04 -0600
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.289.1;
	Tue, 7 Feb 2012 03:12:56 -0600
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, 7 Feb 2012
	04:12:56 -0500
Message-ID: <4F30EB15.9000308@amd.com>
Date: Tue, 7 Feb 2012 10:12:53 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
	<4F301F8B.5010306@amd.com>
In-Reply-To: <4F301F8B.5010306@amd.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/06/12 19:44, Boris Ostrovsky wrote:
> On 02/06/12 12:47, Konrad Rzeszutek Wilk wrote:
>> On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> # Date 1328549858 -3600
>>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>>> # Parent e2722b24dc0962de37215320b05d1bb7c4c42864
>>> x86/AMD: Add support for AMD's OSVW feature in guests.
>>>
>>> In some cases guests should not provide workarounds for errata even
>>> when the
>>> physical processor is affected. For example, because of erratum 400
>>> on family
>>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT)
>>> before
>>> going to idle in order to avoid getting stuck in a non-C0 state. This
>>> is not
>>
>> What about fixing the Linux guest to actually not do this? I presume you
>> have encountered this with HVM guests - would it be possible to use
>>
>> set_pm_idle_to_default(default_idle) in the HVM bootup path, say in
>> 'xen_hvm_guest_init' ??
>
>
> Changing Linux won't help guests running Linux prior to the change so we
> still need this patch. And with the patch guest's pm_idle will be set to
> default_idle anyway (because cpu_has_amd_erratum(amd_erratum_400) will
> return 0).

Right. Also fixing Linux won't help non-Linux guests, too.

Christoph


>
>
> -boris
>
>>
>>
>>> necessary: HLT and IO instructions are intercepted and therefore
>>> there is no
>>> reason for erratum 400 workaround in the guest.
>>>
>>> This patch allows us to present a guest with certain errata as fixed,
>>> regardless of the state of actual hardware.
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 09:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 09:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuhLp-000205-WD; Tue, 07 Feb 2012 09:28:38 +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 1RuhLo-000200-DP
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 09:28:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328606885!58769021!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31988 invoked from network); 7 Feb 2012 09:28:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 09:28:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RuhLl-000D5Y-50; Tue, 07 Feb 2012 09:28:33 +0000
Date: Tue, 7 Feb 2012 09:28:32 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120207092832.GB49952@ocelot.phlegethon.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
	<20120203211836.GD78380@ocelot.phlegethon.org>
	<4F300F93.3020404@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F300F93.3020404@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial
	page tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 17:36 +0000 on 06 Feb (1328549779), David Vrabel wrote:
> That was already used in setup_pagetables() to relocate Xen but since
> the two uses don't overlap they can share the same slot.  Not 100% sure
> on the TLB flush after updating the L2 PTE -- it makes it work but is it
> sufficient/optimal?

Hrmn.  Yes, I think that's sufficient.  You should be able to use
flush_xen_data_tlb_va() to just flush that one entry, AFAICS.

> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -201,6 +201,13 @@ hyp:
>          add   r4, r4, #8
>          strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>  #endif
> +        mov   r3, #0x0
> +        lsr   r2, r8, #21
> +        lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
> +        orr   r2, r2, #0xf00
> +        orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
> +        add   r4, r4, #8
> +        strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */

That's good, but you should move the previous "add r4, r4, #8" out of
the #ifdef. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 09:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 09:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuhLp-000205-WD; Tue, 07 Feb 2012 09:28:38 +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 1RuhLo-000200-DP
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 09:28:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328606885!58769021!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31988 invoked from network); 7 Feb 2012 09:28:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 09:28:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RuhLl-000D5Y-50; Tue, 07 Feb 2012 09:28:33 +0000
Date: Tue, 7 Feb 2012 09:28:32 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120207092832.GB49952@ocelot.phlegethon.org>
References: <1328296515-25876-1-git-send-email-david.vrabel@citrix.com>
	<1328296515-25876-5-git-send-email-david.vrabel@citrix.com>
	<20120203211836.GD78380@ocelot.phlegethon.org>
	<4F300F93.3020404@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F300F93.3020404@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/7] arm: map device tree blob in initial
	page tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 17:36 +0000 on 06 Feb (1328549779), David Vrabel wrote:
> That was already used in setup_pagetables() to relocate Xen but since
> the two uses don't overlap they can share the same slot.  Not 100% sure
> on the TLB flush after updating the L2 PTE -- it makes it work but is it
> sufficient/optimal?

Hrmn.  Yes, I think that's sufficient.  You should be able to use
flush_xen_data_tlb_va() to just flush that one entry, AFAICS.

> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -201,6 +201,13 @@ hyp:
>          add   r4, r4, #8
>          strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>  #endif
> +        mov   r3, #0x0
> +        lsr   r2, r8, #21
> +        lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
> +        orr   r2, r2, #0xf00
> +        orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
> +        add   r4, r4, #8
> +        strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */

That's good, but you should move the previous "add r4, r4, #8" out of
the #ifdef. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:24:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10: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.xensource.com>)
	id 1RuiCw-0002oq-Ri; Tue, 07 Feb 2012 10:23:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RuiCu-0002ol-KZ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:23:29 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328610201!10463964!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4719 invoked from network); 7 Feb 2012 10:23:22 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 10:23:22 -0000
Received: by lagp5 with SMTP id p5so6475188lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 02:23:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=WnvCnPPxmLbCRKxQxdnNHDDDEdVONWJkiqwJ+uWdTaM=;
	b=LxGc2CKIZmgMba4RrMh8U4GSThDizS+cv2Pc5DK0ZmFe9Et5rIfYpN9ST8GEIWuTC+
	fno9yhY6vxE6gvG3ymOjdGx9pC60UFR4ouN+xTHGt5Df7L/j6aQI+E1cky+32jhDHA/i
	2pb0kb6Hk3ZaIHnEAaEaR0aHw/7hP/QkgfOQs=
Received: by 10.112.28.169 with SMTP id c9mr6009459lbh.42.1328610201162; Tue,
	07 Feb 2012 02:23:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Tue, 7 Feb 2012 02:23:05 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <4F30E62B02000078000717EB@nat28.tlf.novell.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
	<4F30E62B02000078000717EB@nat28.tlf.novell.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 7 Feb 2012 14:23:05 +0400
X-Google-Sender-Auth: Ef884wPbZwgvk8CRL36eaEiAne4
Message-ID: <CACaajQt0MDNAN51g6AuYZn7ApwvuVgn+=GdyPNDJYVh95ecD0g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/7 Jan Beulich <JBeulich@suse.com>:

>
> As outlined above, it is possible, but I'm not certain it is a good idea
> to have balloon_set_new_target() exported. If you think that's
> acceptable, I can certainly put together a patch doing that (on top
> of the one here, and probably not immediately).
>
> Jan

Exporting balloon_set_new_target can be grate feature to do own
modules for balloon memory inside xen guest, becouse some times we
need more realtime control from dom0 for memory growing speed inside
guest.


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:24:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10: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.xensource.com>)
	id 1RuiCw-0002oq-Ri; Tue, 07 Feb 2012 10:23:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RuiCu-0002ol-KZ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:23:29 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328610201!10463964!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4719 invoked from network); 7 Feb 2012 10:23:22 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 10:23:22 -0000
Received: by lagp5 with SMTP id p5so6475188lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 02:23:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=WnvCnPPxmLbCRKxQxdnNHDDDEdVONWJkiqwJ+uWdTaM=;
	b=LxGc2CKIZmgMba4RrMh8U4GSThDizS+cv2Pc5DK0ZmFe9Et5rIfYpN9ST8GEIWuTC+
	fno9yhY6vxE6gvG3ymOjdGx9pC60UFR4ouN+xTHGt5Df7L/j6aQI+E1cky+32jhDHA/i
	2pb0kb6Hk3ZaIHnEAaEaR0aHw/7hP/QkgfOQs=
Received: by 10.112.28.169 with SMTP id c9mr6009459lbh.42.1328610201162; Tue,
	07 Feb 2012 02:23:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Tue, 7 Feb 2012 02:23:05 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <4F30E62B02000078000717EB@nat28.tlf.novell.com>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
	<4F30E62B02000078000717EB@nat28.tlf.novell.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 7 Feb 2012 14:23:05 +0400
X-Google-Sender-Auth: Ef884wPbZwgvk8CRL36eaEiAne4
Message-ID: <CACaajQt0MDNAN51g6AuYZn7ApwvuVgn+=GdyPNDJYVh95ecD0g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/7 Jan Beulich <JBeulich@suse.com>:

>
> As outlined above, it is possible, but I'm not certain it is a good idea
> to have balloon_set_new_target() exported. If you think that's
> acceptable, I can certainly put together a patch doing that (on top
> of the one here, and probably not immediately).
>
> Jan

Exporting balloon_set_new_target can be grate feature to do own
modules for balloon memory inside xen guest, becouse some times we
need more realtime control from dom0 for memory growing speed inside
guest.


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:35:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuiO4-0002z3-20; Tue, 07 Feb 2012 10:35:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuiO2-0002yy-J6
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:34:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328610872!64786861!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17843 invoked from network); 7 Feb 2012 10:34:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 10:34:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 10:34:53 +0000
Message-Id: <4F310C5B0200007800071870@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 10:34:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F3016BE02000078000716C7@nat28.tlf.novell.com>
In-Reply-To: <4F3016BE02000078000716C7@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 18:06, "Jan Beulich" <JBeulich@suse.com> wrote:
> Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
> larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
> to unsigned long * - how is that not a problem in the context of the
> goal that said c/s set, in particular for v2 of the interface? (Given that
> this is being implemented as arch-specific routine - so far for reasons
> that escape me - this should be simple to fix by using inline assembly
> rather than clear_bit().)
> 
> Further I just spotted one instance where the or of two bit positions
> gets passed to this function - that's quite definitely a bug I would say.
> 
> And, quite the opposite, __fixup_status_for_pin() ands out the
> negation of bit positions rather than masks... (Which also raises
> the question whether it really would need to be clear_bit() above
> instead of the cheaper __clear_bit().)

Below the tentative fix for all of the above problems. In the light
of the comment at the top of x86's bitops.h I'm awaiting our gcc
experts' response regarding the safety of using "+m" here.

Jan

--- 2012-02-06.orig/xen/common/grant_table.c
+++ 2012-02-06/xen/common/grant_table.c
@@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
              (id != domid) ||
              (!readonly && (flags & GTF_readonly)) )
         {
-            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
+            gnttab_clear_flag(_GTF_writing, status);
+            gnttab_clear_flag(_GTF_reading, status);
             PIN_FAIL(done, GNTST_general_error,
                      "Unstable flags (%x) or dom (%d). (expected dom %d) "
                      "(r/w: %d)\n",
@@ -1715,14 +1716,14 @@ __release_grant_for_copy(
    under the domain's grant table lock. */
 /* Only safe on transitive grants.  Even then, note that we don't
    attempt to drop any pin on the referent grant. */
-static void __fixup_status_for_pin(struct active_grant_entry *act,
+static void __fixup_status_for_pin(const struct active_grant_entry *act,
                                    uint16_t *status)
 {
     if ( !(act->pin & GNTPIN_hstw_mask) )
-        *status &= ~_GTF_writing;
+        *status &= ~GTF_writing;
 
     if ( !(act->pin & GNTPIN_hstr_mask) )
-        *status &= ~_GTF_reading;
+        *status &= ~GTF_reading;
 }
 
 /* Grab a frame number from a grant entry and update the flags and pin
--- 2012-02-06.orig/xen/include/asm-ia64/grant_table.h
+++ 2012-02-06/xen/include/asm-ia64/grant_table.h
@@ -5,6 +5,8 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
 
+#include <asm/intrinsics.h>
+
 #define INITIAL_NR_GRANT_FRAMES 1
 
 // for grant map/unmap
@@ -82,9 +84,15 @@ int guest_physmap_add_page(struct domain
 
 #define gnttab_mark_dirty(d, f) ((void)f)
 
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t *st)
 {
-	clear_bit(nr, addr);
+	uint16_t mask = ~(1 << nr), old;
+	CMPXCHG_BUGCHECK_DECL
+
+	do {
+		CMPXCHG_BUGCHECK(st);
+		old = *st;
+	} while (cmpxchg_rel(st, old, old & mask) != old);
 }
 
 #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
--- 2012-02-06.orig/xen/include/asm-x86/grant_table.h
+++ 2012-02-06/xen/include/asm-x86/grant_table.h
@@ -48,9 +48,11 @@ int replace_grant_host_mapping(
 
 #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
 
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, uint16_t *addr)
 {
-    clear_bit(nr, (unsigned long *)addr);
+    asm volatile ("lock btrw %1,%0"
+                  : "+m" (*addr)
+                  : "Ir" (nr));
 }
 
 /* Foreign mappings of HHVM-guest pages do not modify the type count. */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:35:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuiO4-0002z3-20; Tue, 07 Feb 2012 10:35:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RuiO2-0002yy-J6
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:34:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328610872!64786861!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17843 invoked from network); 7 Feb 2012 10:34:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 10:34:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 10:34:53 +0000
Message-Id: <4F310C5B0200007800071870@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 10:34:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F3016BE02000078000716C7@nat28.tlf.novell.com>
In-Reply-To: <4F3016BE02000078000716C7@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 18:06, "Jan Beulich" <JBeulich@suse.com> wrote:
> Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
> larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
> to unsigned long * - how is that not a problem in the context of the
> goal that said c/s set, in particular for v2 of the interface? (Given that
> this is being implemented as arch-specific routine - so far for reasons
> that escape me - this should be simple to fix by using inline assembly
> rather than clear_bit().)
> 
> Further I just spotted one instance where the or of two bit positions
> gets passed to this function - that's quite definitely a bug I would say.
> 
> And, quite the opposite, __fixup_status_for_pin() ands out the
> negation of bit positions rather than masks... (Which also raises
> the question whether it really would need to be clear_bit() above
> instead of the cheaper __clear_bit().)

Below the tentative fix for all of the above problems. In the light
of the comment at the top of x86's bitops.h I'm awaiting our gcc
experts' response regarding the safety of using "+m" here.

Jan

--- 2012-02-06.orig/xen/common/grant_table.c
+++ 2012-02-06/xen/common/grant_table.c
@@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
              (id != domid) ||
              (!readonly && (flags & GTF_readonly)) )
         {
-            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
+            gnttab_clear_flag(_GTF_writing, status);
+            gnttab_clear_flag(_GTF_reading, status);
             PIN_FAIL(done, GNTST_general_error,
                      "Unstable flags (%x) or dom (%d). (expected dom %d) "
                      "(r/w: %d)\n",
@@ -1715,14 +1716,14 @@ __release_grant_for_copy(
    under the domain's grant table lock. */
 /* Only safe on transitive grants.  Even then, note that we don't
    attempt to drop any pin on the referent grant. */
-static void __fixup_status_for_pin(struct active_grant_entry *act,
+static void __fixup_status_for_pin(const struct active_grant_entry *act,
                                    uint16_t *status)
 {
     if ( !(act->pin & GNTPIN_hstw_mask) )
-        *status &= ~_GTF_writing;
+        *status &= ~GTF_writing;
 
     if ( !(act->pin & GNTPIN_hstr_mask) )
-        *status &= ~_GTF_reading;
+        *status &= ~GTF_reading;
 }
 
 /* Grab a frame number from a grant entry and update the flags and pin
--- 2012-02-06.orig/xen/include/asm-ia64/grant_table.h
+++ 2012-02-06/xen/include/asm-ia64/grant_table.h
@@ -5,6 +5,8 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
 
+#include <asm/intrinsics.h>
+
 #define INITIAL_NR_GRANT_FRAMES 1
 
 // for grant map/unmap
@@ -82,9 +84,15 @@ int guest_physmap_add_page(struct domain
 
 #define gnttab_mark_dirty(d, f) ((void)f)
 
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t *st)
 {
-	clear_bit(nr, addr);
+	uint16_t mask = ~(1 << nr), old;
+	CMPXCHG_BUGCHECK_DECL
+
+	do {
+		CMPXCHG_BUGCHECK(st);
+		old = *st;
+	} while (cmpxchg_rel(st, old, old & mask) != old);
 }
 
 #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
--- 2012-02-06.orig/xen/include/asm-x86/grant_table.h
+++ 2012-02-06/xen/include/asm-x86/grant_table.h
@@ -48,9 +48,11 @@ int replace_grant_host_mapping(
 
 #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
 
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, uint16_t *addr)
 {
-    clear_bit(nr, (unsigned long *)addr);
+    asm volatile ("lock btrw %1,%0"
+                  : "+m" (*addr)
+                  : "Ir" (nr));
 }
 
 /* Foreign mappings of HHVM-guest pages do not modify the type count. */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:40:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10: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.xensource.com>)
	id 1RuiSk-000373-Oj; Tue, 07 Feb 2012 10:39:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RuiSj-00036r-Qf
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:39:50 +0000
Received: from [85.158.139.83:41527] by server-7.bemta-5.messagelabs.com id
	A2/5B-08209-27FF03F4; Tue, 07 Feb 2012 10:39:46 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328611185!14017467!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17476 invoked from network); 7 Feb 2012 10:39:46 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 10:39:46 -0000
Received: by lbjn8 with SMTP id n8so2482967lbj.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 02:39:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=OtFQKrXyRov5fV308e0jAyuHpJ/MmZa0oSP+c4R+JF8=;
	b=WXts1i10vBRcpSyKSQhodB4xU3eTkt3tMKRBYu0SCdG/C75R4F7vP7e08V+E86960B
	mrSkWfK8+Srwlya7gzunIlX2WTTSqxVTYcqj7khFYq65E2Ng1+3nbhKEPmj0nGkXMGsu
	+XKAGkFZdck828EqSIGQI2f5VatbyLlH2FIdc=
Received: by 10.112.32.1 with SMTP id e1mr6244943lbi.3.1328611185275; Tue, 07
	Feb 2012 02:39:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Tue, 7 Feb 2012 02:39:30 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20120206180733.GA25234@phenom.dumpdata.com>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
	<20120206180733.GA25234@phenom.dumpdata.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 7 Feb 2012 14:39:30 +0400
X-Google-Sender-Auth: fgA87RrFC3fLKQ2rViMvtRCZIzo
Message-ID: <CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/6 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> On Mon, Feb 06, 2012 at 04:09:55PM +0400, Vasiliy Tolstov wrote:
>> Hello. I'm try to run domU kernel from backports.debian.org under 32
>> bit guest (686-pae), but after sometime i get error in dmesg:
>>
>> http://cdn.selfip.ru/hang.png
>>
>> in guest loaded only xen-netfront.ko module.
>>
>> What does it mean?
>
> It means it is stuck waiting for a change.
> What is your Xen/dom0? IT could be that it is missing some patch?
> Did you try the xen-unstable and Linux v3.2?
>

I have SLES kernel-xen-2.6.32.36-0.5.2 and xen-4.0.1_21326_06-0.4.1,
i'm not try latest xen versions.
SLES does not provide kernels for 3.x and not provide xen versions > 4.0.xx =(

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:40:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10: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.xensource.com>)
	id 1RuiSk-000373-Oj; Tue, 07 Feb 2012 10:39:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RuiSj-00036r-Qf
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:39:50 +0000
Received: from [85.158.139.83:41527] by server-7.bemta-5.messagelabs.com id
	A2/5B-08209-27FF03F4; Tue, 07 Feb 2012 10:39:46 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328611185!14017467!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17476 invoked from network); 7 Feb 2012 10:39:46 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 10:39:46 -0000
Received: by lbjn8 with SMTP id n8so2482967lbj.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 02:39:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=OtFQKrXyRov5fV308e0jAyuHpJ/MmZa0oSP+c4R+JF8=;
	b=WXts1i10vBRcpSyKSQhodB4xU3eTkt3tMKRBYu0SCdG/C75R4F7vP7e08V+E86960B
	mrSkWfK8+Srwlya7gzunIlX2WTTSqxVTYcqj7khFYq65E2Ng1+3nbhKEPmj0nGkXMGsu
	+XKAGkFZdck828EqSIGQI2f5VatbyLlH2FIdc=
Received: by 10.112.32.1 with SMTP id e1mr6244943lbi.3.1328611185275; Tue, 07
	Feb 2012 02:39:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Tue, 7 Feb 2012 02:39:30 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20120206180733.GA25234@phenom.dumpdata.com>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
	<20120206180733.GA25234@phenom.dumpdata.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 7 Feb 2012 14:39:30 +0400
X-Google-Sender-Auth: fgA87RrFC3fLKQ2rViMvtRCZIzo
Message-ID: <CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/6 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> On Mon, Feb 06, 2012 at 04:09:55PM +0400, Vasiliy Tolstov wrote:
>> Hello. I'm try to run domU kernel from backports.debian.org under 32
>> bit guest (686-pae), but after sometime i get error in dmesg:
>>
>> http://cdn.selfip.ru/hang.png
>>
>> in guest loaded only xen-netfront.ko module.
>>
>> What does it mean?
>
> It means it is stuck waiting for a change.
> What is your Xen/dom0? IT could be that it is missing some patch?
> Did you try the xen-unstable and Linux v3.2?
>

I have SLES kernel-xen-2.6.32.36-0.5.2 and xen-4.0.1_21326_06-0.4.1,
i'm not try latest xen versions.
SLES does not provide kernels for 3.x and not provide xen versions > 4.0.xx =(

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:45:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuiXt-0003Hh-HD; Tue, 07 Feb 2012 10:45: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 1RuiXs-0003Ha-5s
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:45:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328611456!51699915!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTY1MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTY1MTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10255 invoked from network); 7 Feb 2012 10:44:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Feb 2012 10:44:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328611506; l=1259;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=bghiN6jXQDOkPMXeYGy8jnXNkeg=;
	b=AyoHa6Zi8SvhiB7cYsGnAgd1E0u7KJu2RJRdf8HztfoMW6VZ6uSonPVxrVKZEYhZgzb
	RUUd51q4koHNV9Td7nZgLAdBHroGL/sU+h4SXRITt6UqEsm9/6pAz42VXJVefcgCV7aNT
	65WSPNHLq0YVsFKmdk/RkSWoWJzHNKETnuU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7qEl7I
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-100.pools.arcor-ip.net [84.57.81.100])
	by smtp.strato.de (klopstock mo27) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k0094ao179kNgY ;
	Tue, 7 Feb 2012 11:44:41 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1A90518637; Tue,  7 Feb 2012 11:44:46 +0100 (CET)
Date: Tue, 7 Feb 2012 11:44:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120207104446.GA31244@aepfle.de>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] tools/flask: remove libflask
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, Daniel De Graaf wrote:

> This library has been deprecated since July 2010; remove the in-tree
> users and library.

> -	ln -sf libflask.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libflask.so

> +++ b/tools/python/setup.py
> @@ -48,7 +48,7 @@ flask = Extension("flask",
>                 include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
>                                        "../flask/libflask/include" ],
>                 library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
> -               libraries          = [ "xenctrl", "flask" ],
> +               libraries          = [ "xenctrl" ],
>                 depends            = [ PATH_LIBXC + "/libxenctrl.so",
>                                        XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
>                 sources            = [ "xen/lowlevel/flask/flask.c" ])


For some reason this changeset does not cause buildfailures in automated
testing. My xen-unstable rpm packages fail to build in SLES11, but not in
openSuSE for some reason.

Is there a chance that libflask.so is built after this python thing runs?
In other words: Is there a makefile dependency missing?

Olaf

...
building 'flask' extension
error: ../../tools/flask/libflask/libflask.so: No such file or directory
make[3]: *** [install] Error 1
make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.24701/non-dbg/tools/python'
make[2]: *** [subdir-install-python] Error 2
...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:45:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:45:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuiXt-0003Hh-HD; Tue, 07 Feb 2012 10:45: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 1RuiXs-0003Ha-5s
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:45:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328611456!51699915!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTY1MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTY1MTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10255 invoked from network); 7 Feb 2012 10:44:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 7 Feb 2012 10:44:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328611506; l=1259;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=bghiN6jXQDOkPMXeYGy8jnXNkeg=;
	b=AyoHa6Zi8SvhiB7cYsGnAgd1E0u7KJu2RJRdf8HztfoMW6VZ6uSonPVxrVKZEYhZgzb
	RUUd51q4koHNV9Td7nZgLAdBHroGL/sU+h4SXRITt6UqEsm9/6pAz42VXJVefcgCV7aNT
	65WSPNHLq0YVsFKmdk/RkSWoWJzHNKETnuU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7qEl7I
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-100.pools.arcor-ip.net [84.57.81.100])
	by smtp.strato.de (klopstock mo27) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k0094ao179kNgY ;
	Tue, 7 Feb 2012 11:44:41 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1A90518637; Tue,  7 Feb 2012 11:44:46 +0100 (CET)
Date: Tue, 7 Feb 2012 11:44:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120207104446.GA31244@aepfle.de>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] tools/flask: remove libflask
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, Daniel De Graaf wrote:

> This library has been deprecated since July 2010; remove the in-tree
> users and library.

> -	ln -sf libflask.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libflask.so

> +++ b/tools/python/setup.py
> @@ -48,7 +48,7 @@ flask = Extension("flask",
>                 include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
>                                        "../flask/libflask/include" ],
>                 library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
> -               libraries          = [ "xenctrl", "flask" ],
> +               libraries          = [ "xenctrl" ],
>                 depends            = [ PATH_LIBXC + "/libxenctrl.so",
>                                        XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
>                 sources            = [ "xen/lowlevel/flask/flask.c" ])


For some reason this changeset does not cause buildfailures in automated
testing. My xen-unstable rpm packages fail to build in SLES11, but not in
openSuSE for some reason.

Is there a chance that libflask.so is built after this python thing runs?
In other words: Is there a makefile dependency missing?

Olaf

...
building 'flask' extension
error: ../../tools/flask/libflask/libflask.so: No such file or directory
make[3]: *** [install] Error 1
make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.24701/non-dbg/tools/python'
make[2]: *** [subdir-install-python] Error 2
...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:50:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruicy-0003VM-9e; Tue, 07 Feb 2012 10:50:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Ruicw-0003VG-O4
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:50:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328611816!12117913!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjI4NTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjI4NTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 7 Feb 2012 10:50:16 -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; 7 Feb 2012 10:50:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328611815; l=462;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=j1K/aBUzQpfhcUshEOVtzYiydu0=;
	b=mKjoCJRjR9QegAOhlJfPqFgSfQlz8Fl/UD1fdYa+HTViQoxn+LEGqZXPELYJSS4Tnl0
	bv9RXMf7LIUEeznZUq0GLDPnakGb74IVi+hik78oHrX3Z0i7kvwl/WeJnc54a2yOqzAjx
	G6iq0hrRrgLgq46uz0Ym4gHOzNHUZcvAl7o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7qEl7I
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-100.pools.arcor-ip.net [84.57.81.100])
	by smtp.strato.de (jimi mo50) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02506o17Akb81 ;
	Tue, 7 Feb 2012 11:49:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 41C0E18637; Tue,  7 Feb 2012 11:49:58 +0100 (CET)
Date: Tue, 7 Feb 2012 11:49:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120207104958.GA31333@aepfle.de>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
	<20120206180733.GA25234@phenom.dumpdata.com>
	<CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, Vasiliy Tolstov wrote:

> I have SLES kernel-xen-2.6.32.36-0.5.2 and xen-4.0.1_21326_06-0.4.1,
> i'm not try latest xen versions.
> SLES does not provide kernels for 3.x and not provide xen versions > 4.0.xx =(

The SP1 update channel has a 4.0.2 based xen package since some time,
also a newer kernel.
I guess to debug this hang further some host logs are needed (xend.log,
qemu-domU.log, etc.), and also the domU config file.

Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:50:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruicy-0003VM-9e; Tue, 07 Feb 2012 10:50:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Ruicw-0003VG-O4
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:50:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328611816!12117913!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjI4NTM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjI4NTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4375 invoked from network); 7 Feb 2012 10:50:16 -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; 7 Feb 2012 10:50:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328611815; l=462;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=j1K/aBUzQpfhcUshEOVtzYiydu0=;
	b=mKjoCJRjR9QegAOhlJfPqFgSfQlz8Fl/UD1fdYa+HTViQoxn+LEGqZXPELYJSS4Tnl0
	bv9RXMf7LIUEeznZUq0GLDPnakGb74IVi+hik78oHrX3Z0i7kvwl/WeJnc54a2yOqzAjx
	G6iq0hrRrgLgq46uz0Ym4gHOzNHUZcvAl7o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7qEl7I
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-100.pools.arcor-ip.net [84.57.81.100])
	by smtp.strato.de (jimi mo50) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02506o17Akb81 ;
	Tue, 7 Feb 2012 11:49:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 41C0E18637; Tue,  7 Feb 2012 11:49:58 +0100 (CET)
Date: Tue, 7 Feb 2012 11:49:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120207104958.GA31333@aepfle.de>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
	<20120206180733.GA25234@phenom.dumpdata.com>
	<CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, Vasiliy Tolstov wrote:

> I have SLES kernel-xen-2.6.32.36-0.5.2 and xen-4.0.1_21326_06-0.4.1,
> i'm not try latest xen versions.
> SLES does not provide kernels for 3.x and not provide xen versions > 4.0.xx =(

The SP1 update channel has a 4.0.2 based xen package since some time,
also a newer kernel.
I guess to debug this hang further some host logs are needed (xend.log,
qemu-domU.log, etc.), and also the domU config file.

Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:54:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruige-0003dX-Ui; Tue, 07 Feb 2012 10:54:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1Ruigd-0003dL-6E
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:54:11 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328612006!59086645!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13214 invoked from network); 7 Feb 2012 10:53:26 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 10:53:26 -0000
Received: by lagp5 with SMTP id p5so6516709lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 02:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=MqFF66R9cLh8Nq7C8zRaWFpdyoQ+8j7LWVIfD5O2UH4=;
	b=L93w+YZMTkTgdyBuv2yIhBdop7CZZSZnK4Slfts3/E3+O2LobK8wbJaCGJ1q8YfwVA
	L8AHpqgzphaPqAyZ5695l5WqTKkfoEiP4nPZrKAR7Dq/q4TlbsDUXP9Ovaa/J5bjTxBL
	0DJX8JaL/K4ki1B0NU1aulNXcOlVw4RhBeJ90=
Received: by 10.152.112.41 with SMTP id in9mr12032007lab.27.1328612049199;
	Tue, 07 Feb 2012 02:54:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Tue, 7 Feb 2012 02:53:53 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20120207104958.GA31333@aepfle.de>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
	<20120206180733.GA25234@phenom.dumpdata.com>
	<CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
	<20120207104958.GA31333@aepfle.de>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 7 Feb 2012 14:53:53 +0400
X-Google-Sender-Auth: zY2elUlZ7Za_cCFdw1U7XnAMlZM
Message-ID: <CACaajQvcOVzdzQgHKKSamLMLF-+c+Ph7mNg1O2bkyj44qbGwFA@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/7 Olaf Hering <olaf@aepfle.de>:
> On Tue, Feb 07, Vasiliy Tolstov wrote:
>
>> I have SLES kernel-xen-2.6.32.36-0.5.2 and xen-4.0.1_21326_06-0.4.1,
>> i'm not try latest xen versions.
>> SLES does not provide kernels for 3.x and not provide xen versions > 4.0.xx =(
>
> The SP1 update channel has a 4.0.2 based xen package since some time,
> also a newer kernel.
> I guess to debug this hang further some host logs are needed (xend.log,
> qemu-domU.log, etc.), and also the domU config file.
>
> Olaf
>
>

Ok. I'm try to get this error again and send all info on current
kernel versions and try to install latest,
as i see latest in SP1 in :
vmlinuz-2.6.32.54-0.3-xen
initrd-2.6.32.54-0.3-xen
xen-4.0.2_21511_04-0.5.10.gz
-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 10:54:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 10:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruige-0003dX-Ui; Tue, 07 Feb 2012 10:54:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1Ruigd-0003dL-6E
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 10:54:11 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328612006!59086645!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13214 invoked from network); 7 Feb 2012 10:53:26 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 10:53:26 -0000
Received: by lagp5 with SMTP id p5so6516709lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 02:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=MqFF66R9cLh8Nq7C8zRaWFpdyoQ+8j7LWVIfD5O2UH4=;
	b=L93w+YZMTkTgdyBuv2yIhBdop7CZZSZnK4Slfts3/E3+O2LobK8wbJaCGJ1q8YfwVA
	L8AHpqgzphaPqAyZ5695l5WqTKkfoEiP4nPZrKAR7Dq/q4TlbsDUXP9Ovaa/J5bjTxBL
	0DJX8JaL/K4ki1B0NU1aulNXcOlVw4RhBeJ90=
Received: by 10.152.112.41 with SMTP id in9mr12032007lab.27.1328612049199;
	Tue, 07 Feb 2012 02:54:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.24.133 with HTTP; Tue, 7 Feb 2012 02:53:53 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20120207104958.GA31333@aepfle.de>
References: <CACaajQu4sSC6U_C19SXd_z8gjE9QQW50SLDg7y+SMx0cebcnhg@mail.gmail.com>
	<20120206180733.GA25234@phenom.dumpdata.com>
	<CACaajQvWdCVcijGv=8UuVNOMp-cHMwZV3-aWg-edT=76JebhJw@mail.gmail.com>
	<20120207104958.GA31333@aepfle.de>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 7 Feb 2012 14:53:53 +0400
X-Google-Sender-Auth: zY2elUlZ7Za_cCFdw1U7XnAMlZM
Message-ID: <CACaajQvcOVzdzQgHKKSamLMLF-+c+Ph7mNg1O2bkyj44qbGwFA@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] hung task timeout when tries to shutdown guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/7 Olaf Hering <olaf@aepfle.de>:
> On Tue, Feb 07, Vasiliy Tolstov wrote:
>
>> I have SLES kernel-xen-2.6.32.36-0.5.2 and xen-4.0.1_21326_06-0.4.1,
>> i'm not try latest xen versions.
>> SLES does not provide kernels for 3.x and not provide xen versions > 4.0.xx =(
>
> The SP1 update channel has a 4.0.2 based xen package since some time,
> also a newer kernel.
> I guess to debug this hang further some host logs are needed (xend.log,
> qemu-domU.log, etc.), and also the domU config file.
>
> Olaf
>
>

Ok. I'm try to get this error again and send all info on current
kernel versions and try to install latest,
as i see latest in SP1 in :
vmlinuz-2.6.32.54-0.3-xen
initrd-2.6.32.54-0.3-xen
xen-4.0.2_21511_04-0.5.10.gz
-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 11:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 11:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RujX8-0004Tm-CP; Tue, 07 Feb 2012 11:48:26 +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 1RujX6-0004Th-TQ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:48:25 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328615166!51698974!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21355 invoked from network); 7 Feb 2012 11:46:07 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.144)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 11:46:07 -0000
Received: from mail101-db3-R.bigfish.com (10.3.81.232) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 11:48:18 +0000
Received: from mail101-db3 (localhost [127.0.0.1])	by
	mail101-db3-R.bigfish.com (Postfix) with ESMTP id D063C4A03F0;
	Tue,  7 Feb 2012 11:48:17 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3
	(MessageSwitch) id 1328615295825911_26400;
	Tue,  7 Feb 2012 11:48:15 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.253])	by
	mail101-db3.bigfish.com (Postfix) with ESMTP id C241D100049;
	Tue,  7 Feb 2012 11:48:15 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 11:48:15 +0000
X-WSS-ID: 0LZ0U4C-01-4O8-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 20DD7102803A;	Tue,  7 Feb 2012 05:48:12 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 7 Feb 2012 05:48:20 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 7 Feb 2012 05:48:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 7 Feb 2012
	06:48:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C9BEE49C1FF; Tue,  7 Feb 2012
	11:48:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id B18365940FF; Tue,  7 Feb 2012
	12:48:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: cbd3c18e8ffe86bf7378303068e23b52795e5d94
Message-ID: <cbd3c18e8ffe86bf7378.1328615503@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 7 Feb 2012 12:51:43 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] amd iommu: Remove redundant checks from iommu
 emulation code path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328609973 -3600
# Node ID cbd3c18e8ffe86bf7378303068e23b52795e5d94
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
amd iommu: Remove redundant checks from iommu emulation code path
signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3432abcf9380 -r cbd3c18e8ffe xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Tue Feb 07 11:19:33 2012 +0100
@@ -805,9 +805,6 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return 0;
-
     if ( !iommu )
         return -EACCES;
 
@@ -896,9 +893,6 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return;
-
     iommu = domain_iommu(d);
     if ( !iommu )
         return;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 11:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 11:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RujX8-0004Tm-CP; Tue, 07 Feb 2012 11:48:26 +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 1RujX6-0004Th-TQ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:48:25 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328615166!51698974!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21355 invoked from network); 7 Feb 2012 11:46:07 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.144)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 11:46:07 -0000
Received: from mail101-db3-R.bigfish.com (10.3.81.232) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 11:48:18 +0000
Received: from mail101-db3 (localhost [127.0.0.1])	by
	mail101-db3-R.bigfish.com (Postfix) with ESMTP id D063C4A03F0;
	Tue,  7 Feb 2012 11:48:17 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3
	(MessageSwitch) id 1328615295825911_26400;
	Tue,  7 Feb 2012 11:48:15 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.253])	by
	mail101-db3.bigfish.com (Postfix) with ESMTP id C241D100049;
	Tue,  7 Feb 2012 11:48:15 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 11:48:15 +0000
X-WSS-ID: 0LZ0U4C-01-4O8-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 20DD7102803A;	Tue,  7 Feb 2012 05:48:12 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 7 Feb 2012 05:48:20 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 7 Feb 2012 05:48:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 7 Feb 2012
	06:48:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C9BEE49C1FF; Tue,  7 Feb 2012
	11:48:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id B18365940FF; Tue,  7 Feb 2012
	12:48:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: cbd3c18e8ffe86bf7378303068e23b52795e5d94
Message-ID: <cbd3c18e8ffe86bf7378.1328615503@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 7 Feb 2012 12:51:43 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>, <Ian.Jackson@eu.citrix.com>,
	<Ian.Campbell@citrix.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] amd iommu: Remove redundant checks from iommu
 emulation code path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328609973 -3600
# Node ID cbd3c18e8ffe86bf7378303068e23b52795e5d94
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
amd iommu: Remove redundant checks from iommu emulation code path
signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3432abcf9380 -r cbd3c18e8ffe xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 02 15:47:26 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Tue Feb 07 11:19:33 2012 +0100
@@ -805,9 +805,6 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
-    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return 0;
-
     if ( !iommu )
         return -EACCES;
 
@@ -896,9 +893,6 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
-        return;
-
     iommu = domain_iommu(d);
     if ( !iommu )
         return;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 11:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 11:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruja3-0004ZR-0B; Tue, 07 Feb 2012 11:51:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ruja1-0004ZK-47
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:51:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328615460!51878186!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6091 invoked from network); 7 Feb 2012 11:51:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 11:51:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 11:51:23 +0000
Message-Id: <4F311E470200007800071896@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 11:51:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,<keir@xen.org>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
In-Reply-To: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part210F5227.1__="
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part210F5227.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 06.02.12 at 18:39, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1328549858 -3600
> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> x86/AMD: Add support for AMD's OSVW feature in guests.
>=20
> In some cases guests should not provide workarounds for errata even when =
the
> physical processor is affected. For example, because of erratum 400 =
on=20
> family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) =
before
> going to idle in order to avoid getting stuck in a non-C0 state. This is =
not
> necessary: HLT and IO instructions are intercepted and therefore there =
is no
> reason for erratum 400 workaround in the guest.
>=20
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.
>=20
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>

In the form below/attached (integration with boot time microcode
loading fixed and trailing white space removed)

Acked-by: Jan Beulich <jbeulich@suse.com>

-- Jan

In some cases guests should not provide workarounds for errata even when =
the
physical processor is affected. For example, because of erratum 400 on =
family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is =
not
necessary: HLT and IO instructions are intercepted and therefore there is =
no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
=20
 static bool_t amd_erratum383_found __read_mostly;
=20
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+static DEFINE_SPINLOCK(osvw_lock);
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len)
 {
     struct vcpu *curr =3D current;
@@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
=20
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length =3D (osvw_length >=3D 3) ? osvw_length =
: 3;
+    vcpu->arch.hvm_svm.osvw.status =3D osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest =
that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need =
to
+     * be conservative here and therefore we tell the guest that erratum =
298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length =3D=3D 0 && boot_cpu_data.x86 =3D=3D 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |=3D 1;
+}
+
+void svm_host_osvw_reset()
+{
+    spin_lock(&osvw_lock);
+
+    osvw_length =3D 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status =3D 0;
+
+    spin_unlock(&osvw_lock);
+}
+
+void svm_host_osvw_init()
+{
+    spin_lock(&osvw_lock);
+
+    /*
+     * Get OSVW bits. If bits are not the same on different processors =
then
+     * choose the worst case (i.e. if erratum is present on one processor =
and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len =3D status =3D 0;
+
+        if (len < osvw_length)
+            osvw_length =3D len;
+
+        osvw_status |=3D status;
+        osvw_status &=3D (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length =3D osvw_status =3D 0;
+
+    spin_unlock(&osvw_lock);
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
     }
=20
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
=20
@@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct=20
     }
 }
=20
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, =
bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr =3D=3D MSR_AMD_OSVW_ID_LENGTH)
+            *val =3D v->arch.hvm_svm.osvw.length;
+        else
+            *val =3D v->arch.hvm_svm.osvw.status;
+    }
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
     }
 #endif
=20
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
=20
@@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
=20
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
=20
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret =3D svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret =3D nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
=20
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret =3D svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret =3D nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error =3D 0;
     info->cpu =3D cpumask_first(&cpu_online_map);
=20
+    if ( microcode_ops->start_update )
+    {
+        ret =3D microcode_ops->start_update();
+        if ( ret !=3D 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, =
info);
 }
=20
@@ -240,6 +250,12 @@ static int __init microcode_init(void)
     if ( !data )
         return -ENOMEM;
=20
+    if ( microcode_ops->start_update && microcode_ops->start_update() =
!=3D 0 )
+    {
+        ucode_mod_map(NULL);
+        return 0;
+    }
+
     softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned =
long)data);
=20
     for_each_online_cpu ( cpu )
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
=20
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -71,6 +72,7 @@ struct mpbhdr {
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
=20
+/* See comment in start_update() for cases when this routine fails */
 static int collect_cpu_info(int cpu, struct cpu_signature *csig)
 {
     struct cpuinfo_x86 *c =3D &cpu_data[cpu];
@@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error =3D -EINVAL;
+        goto out;
     }
=20
     mc_amd =3D xmalloc(struct microcode_amd);
@@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error =3D -ENOMEM;
+        goto out;
     }
=20
     error =3D install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table =
failed\n");
-        return -EINVAL;
+        error =3D -EINVAL;
+        goto out;
     }
=20
     mc_old =3D uci->mc.mc_amd;
@@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error =3D=3D 1)
+    if ( error =3D=3D 1 )
     {
         xfree(mc_old);
-        return 0;
+        error =3D 0;
+    }
+    else
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd =3D mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd =3D mc_old;
+
+  out:
+    svm_host_osvw_init();
=20
     return error;
 }
@@ -395,11 +406,28 @@ err1:
     return -ENOMEM;
 }
=20
+static int start_update(void)
+{
+    /*
+     * We assume here that svm_host_osvw_init() will be called on each =
cpu (from
+     * cpu_request_microcode()).
+     *
+     * Note that if collect_cpu_info() returns an error then
+     * cpu_request_microcode() will not invoked thus leaving OSVW bits =
not
+     * updated. Currently though collect_cpu_info() will not fail on =
processors
+     * supporting OSVW so we will not deal with this possibility.
+     */
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops =3D {
     .microcode_resume_match           =3D microcode_resume_match,
     .cpu_request_microcode            =3D cpu_request_microcode,
     .collect_cpu_info                 =3D collect_cpu_info,
     .apply_microcode                  =3D apply_microcode,
+    .start_update                     =3D start_update,
 };
=20
 static __init int microcode_init_amd(void)
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
=20
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /*
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =3D hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret =3D microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
=20
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
=20
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
=20
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -506,6 +507,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. =
*/
         domain_pause(d);
=20
+        /*
+         * Certain operations (e.g. CPU microcode updates) modify data =
which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =3D  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                goto maxvcpu_out_novcpulock;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret =3D -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] !=3D NULL) )
@@ -555,6 +568,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret =3D 0;
=20
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
+
+    maxvcpu_out_novcpulock:
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, =
cpu_khz)
=20
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -516,6 +516,12 @@ struct arch_svm_struct {
    =20
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
=20
 struct vmcb_struct *alloc_vmcb(void);
--- a/xen/include/asm-x86/microcode.h
+++ b/xen/include/asm-x86/microcode.h
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
=20
 struct cpu_signature {
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
=20
 void arch_vcpu_reset(struct vcpu *v);
=20
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
=20



--=__Part210F5227.1__=
Content-Type: application/octet-stream; name="AMD-OSVW-guest"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="AMD-OSVW-guest"

eDg2L0FNRDogQWRkIHN1cHBvcnQgZm9yIEFNRCdzIE9TVlcgZmVhdHVyZSBpbiBndWVzdHMuCgpJ
biBzb21lIGNhc2VzIGd1ZXN0cyBzaG91bGQgbm90IHByb3ZpZGUgd29ya2Fyb3VuZHMgZm9yIGVy
cmF0YSBldmVuIHdoZW4gdGhlCnBoeXNpY2FsIHByb2Nlc3NvciBpcyBhZmZlY3RlZC4gRm9yIGV4
YW1wbGUsIGJlY2F1c2Ugb2YgZXJyYXR1bSA0MDAgb24gZmFtaWx5CjEwaCBwcm9jZXNzb3JzIGEg
TGludXggZ3Vlc3Qgd2lsbCByZWFkIGFuIE1TUiAocmVzdWx0aW5nIGluIFZNRVhJVCkgYmVmb3Jl
CmdvaW5nIHRvIGlkbGUgaW4gb3JkZXIgdG8gYXZvaWQgZ2V0dGluZyBzdHVjayBpbiBhIG5vbi1D
MCBzdGF0ZS4gVGhpcyBpcyBub3QKbmVjZXNzYXJ5OiBITFQgYW5kIElPIGluc3RydWN0aW9ucyBh
cmUgaW50ZXJjZXB0ZWQgYW5kIHRoZXJlZm9yZSB0aGVyZSBpcyBubwpyZWFzb24gZm9yIGVycmF0
dW0gNDAwIHdvcmthcm91bmQgaW4gdGhlIGd1ZXN0LgoKVGhpcyBwYXRjaCBhbGxvd3MgdXMgdG8g
cHJlc2VudCBhIGd1ZXN0IHdpdGggY2VydGFpbiBlcnJhdGEgYXMgZml4ZWQsCnJlZ2FyZGxlc3Mg
b2YgdGhlIHN0YXRlIG9mIGFjdHVhbCBoYXJkd2FyZS4KClNpZ25lZC1vZmYtYnk6IEJvcmlzIE9z
dHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CkFja2VkLWJ5OiBDaHJpc3RvcGggRWdn
ZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVs
aWNoQHN1c2UuY29tPgoKLS0tIGEvdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMKKysrIGIvdG9v
bHMvbGlieGMveGNfY3B1aWRfeDg2LmMKQEAgLTEwOCw2ICsxMDgsNyBAQCBzdGF0aWMgdm9pZCBh
bWRfeGNfY3B1aWRfcG9saWN5KAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZF
QVRVUkVfU1NFNEEpIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJF
X01JU0FMSUdOU1NFKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVS
RV8zRE5PV1BSRUZFVENIKSB8CisgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVB
VFVSRV9PU1ZXKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9Y
T1ApIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZNQTQpIHwK
ICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX1RCTSkgfAotLS0gYS94
ZW4vYXJjaC94ODYvaHZtL3N2bS9zdm0uYworKysgYi94ZW4vYXJjaC94ODYvaHZtL3N2bS9zdm0u
YwpAQCAtODMsNiArODMsMTAgQEAgc3RhdGljIERFRklORV9QRVJfQ1BVX1JFQURfTU9TVExZKHZv
aWQgKgogCiBzdGF0aWMgYm9vbF90IGFtZF9lcnJhdHVtMzgzX2ZvdW5kIF9fcmVhZF9tb3N0bHk7
CiAKKy8qIE9TVlcgYml0cyAqLworc3RhdGljIHVpbnQ2NF90IG9zdndfbGVuZ3RoLCBvc3Z3X3N0
YXR1czsKK3N0YXRpYyBERUZJTkVfU1BJTkxPQ0sob3N2d19sb2NrKTsKKwogdm9pZCBfX3VwZGF0
ZV9ndWVzdF9laXAoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MsIHVuc2lnbmVkIGludCBpbnN0
X2xlbikKIHsKICAgICBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJlbnQ7CkBAIC05MDIsNiArOTA2
LDY5IEBAIHN0YXRpYyB2b2lkIHN2bV9kb19yZXN1bWUoc3RydWN0IHZjcHUgKnYKICAgICByZXNl
dF9zdGFja19hbmRfanVtcChzdm1fYXNtX2RvX3Jlc3VtZSk7CiB9CiAKK3N0YXRpYyB2b2lkIHN2
bV9ndWVzdF9vc3Z3X2luaXQoc3RydWN0IHZjcHUgKnZjcHUpCit7CisgICAgaWYgKCBib290X2Nw
dV9kYXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9BTUQgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKgorICAgICAqIEd1ZXN0cyBzaG91bGQgc2VlIGVycmF0YSA0MDAgYW5kIDQxNSBhcyBm
aXhlZCAoYXNzdW1pbmcgdGhhdAorICAgICAqIEhMVCBhbmQgSU8gaW5zdHJ1Y3Rpb25zIGFyZSBp
bnRlcmNlcHRlZCkuCisgICAgICovCisgICAgdmNwdS0+YXJjaC5odm1fc3ZtLm9zdncubGVuZ3Ro
ID0gKG9zdndfbGVuZ3RoID49IDMpID8gb3N2d19sZW5ndGggOiAzOworICAgIHZjcHUtPmFyY2gu
aHZtX3N2bS5vc3Z3LnN0YXR1cyA9IG9zdndfc3RhdHVzICYgfig2VUxMKTsKKworICAgIC8qCisg
ICAgICogQnkgaW5jcmVhc2luZyBWQ1BVJ3Mgb3N2dy5sZW5ndGggdG8gMyB3ZSBhcmUgdGVsbGlu
ZyB0aGUgZ3Vlc3QgdGhhdAorICAgICAqIGFsbCBvc3Z3LnN0YXR1cyBiaXRzIGluc2lkZSB0aGF0
IGxlbmd0aCwgaW5jbHVkaW5nIGJpdCAwICh3aGljaCBpcworICAgICAqIHJlc2VydmVkIGZvciBl
cnJhdHVtIDI5OCksIGFyZSB2YWxpZC4gSG93ZXZlciwgaWYgaG9zdCBwcm9jZXNzb3IncworICAg
ICAqIG9zdndfbGVuIGlzIDAgdGhlbiBvc3Z3X3N0YXR1c1swXSBjYXJyaWVzIG5vIGluZm9ybWF0
aW9uLiBXZSBuZWVkIHRvCisgICAgICogYmUgY29uc2VydmF0aXZlIGhlcmUgYW5kIHRoZXJlZm9y
ZSB3ZSB0ZWxsIHRoZSBndWVzdCB0aGF0IGVycmF0dW0gMjk4CisgICAgICogaXMgcHJlc2VudCAo
YmVjYXVzZSB3ZSByZWFsbHkgZG9uJ3Qga25vdykuCisgICAgICovCisgICAgaWYgKCBvc3Z3X2xl
bmd0aCA9PSAwICYmIGJvb3RfY3B1X2RhdGEueDg2ID09IDB4MTAgKQorICAgICAgICB2Y3B1LT5h
cmNoLmh2bV9zdm0ub3N2dy5zdGF0dXMgfD0gMTsKK30KKwordm9pZCBzdm1faG9zdF9vc3Z3X3Jl
c2V0KCkKK3sKKyAgICBzcGluX2xvY2soJm9zdndfbG9jayk7CisKKyAgICBvc3Z3X2xlbmd0aCA9
IDY0OyAvKiBPbmUgcmVnaXN0ZXIgKE1TUkMwMDFfMDE0MSkgd29ydGggb2YgZXJyYXRhICovCisg
ICAgb3N2d19zdGF0dXMgPSAwOworCisgICAgc3Bpbl91bmxvY2soJm9zdndfbG9jayk7Cit9CisK
K3ZvaWQgc3ZtX2hvc3Rfb3N2d19pbml0KCkKK3sKKyAgICBzcGluX2xvY2soJm9zdndfbG9jayk7
CisKKyAgICAvKgorICAgICAqIEdldCBPU1ZXIGJpdHMuIElmIGJpdHMgYXJlIG5vdCB0aGUgc2Ft
ZSBvbiBkaWZmZXJlbnQgcHJvY2Vzc29ycyB0aGVuCisgICAgICogY2hvb3NlIHRoZSB3b3JzdCBj
YXNlIChpLmUuIGlmIGVycmF0dW0gaXMgcHJlc2VudCBvbiBvbmUgcHJvY2Vzc29yIGFuZAorICAg
ICAqIG5vdCBvbiBhbm90aGVyIGFzc3VtZSB0aGF0IHRoZSBlcnJhdHVtIGlzIHByZXNlbnQgZXZl
cnl3aGVyZSkuCisgICAgICovCisgICAgaWYgKCB0ZXN0X2JpdChYODZfRkVBVFVSRV9PU1ZXLCAm
Ym9vdF9jcHVfZGF0YS54ODZfY2FwYWJpbGl0eSkgKQorICAgIHsKKyAgICAgICAgdWludDY0X3Qg
bGVuLCBzdGF0dXM7CisKKyAgICAgICAgaWYgKCByZG1zcl9zYWZlKE1TUl9BTURfT1NWV19JRF9M
RU5HVEgsIGxlbikgfHwKKyAgICAgICAgICAgICByZG1zcl9zYWZlKE1TUl9BTURfT1NWV19TVEFU
VVMsIHN0YXR1cykgKQorICAgICAgICAgICAgbGVuID0gc3RhdHVzID0gMDsKKworICAgICAgICBp
ZiAobGVuIDwgb3N2d19sZW5ndGgpCisgICAgICAgICAgICBvc3Z3X2xlbmd0aCA9IGxlbjsKKwor
ICAgICAgICBvc3Z3X3N0YXR1cyB8PSBzdGF0dXM7CisgICAgICAgIG9zdndfc3RhdHVzICY9ICgx
VUxMIDw8IG9zdndfbGVuZ3RoKSAtIDE7CisgICAgfQorICAgIGVsc2UKKyAgICAgICAgb3N2d19s
ZW5ndGggPSBvc3Z3X3N0YXR1cyA9IDA7CisKKyAgICBzcGluX3VubG9jaygmb3N2d19sb2NrKTsK
K30KKwogc3RhdGljIGludCBzdm1fZG9tYWluX2luaXRpYWxpc2Uoc3RydWN0IGRvbWFpbiAqZCkK
IHsKICAgICByZXR1cm4gMDsKQEAgLTkzMCw2ICs5OTcsOSBAQCBzdGF0aWMgaW50IHN2bV92Y3B1
X2luaXRpYWxpc2Uoc3RydWN0IHZjCiAgICAgfQogCiAgICAgdnBtdV9pbml0aWFsaXNlKHYpOwor
CisgICAgc3ZtX2d1ZXN0X29zdndfaW5pdCh2KTsKKwogICAgIHJldHVybiAwOwogfQogCkBAIC0x
MDQ0LDYgKzExMTQsMjcgQEAgc3RhdGljIHZvaWQgc3ZtX2luaXRfZXJyYXR1bV8zODMoc3RydWN0
IAogICAgIH0KIH0KIAorc3RhdGljIGludCBzdm1faGFuZGxlX29zdncoc3RydWN0IHZjcHUgKnYs
IHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCwgYm9vbF90IHJlYWQpCit7CisgICAgdWludCBl
YXgsIGVieCwgZWN4LCBlZHg7CisKKyAgICAvKiBHdWVzdCBPU1ZXIHN1cHBvcnQgKi8KKyAgICBo
dm1fY3B1aWQoMHg4MDAwMDAwMSwgJmVheCwgJmVieCwgJmVjeCwgJmVkeCk7CisgICAgaWYgKCAh
dGVzdF9iaXQoKFg4Nl9GRUFUVVJFX09TVlcgJiAzMSksICZlY3gpICkKKyAgICAgICAgcmV0dXJu
IC0xOworCisgICAgaWYgKCByZWFkICkKKyAgICB7CisgICAgICAgIGlmIChtc3IgPT0gTVNSX0FN
RF9PU1ZXX0lEX0xFTkdUSCkKKyAgICAgICAgICAgICp2YWwgPSB2LT5hcmNoLmh2bV9zdm0ub3N2
dy5sZW5ndGg7CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgICp2YWwgPSB2LT5hcmNoLmh2bV9z
dm0ub3N2dy5zdGF0dXM7CisgICAgfQorICAgIC8qIFdyaXRlcyBhcmUgaWdub3JlZCAqLworCisg
ICAgcmV0dXJuIDA7Cit9CisKIHN0YXRpYyBpbnQgc3ZtX2NwdV91cCh2b2lkKQogewogICAgIHVp
bnQ2NF90IG1zcl9jb250ZW50OwpAQCAtMTA5NCw2ICsxMTg1LDkgQEAgc3RhdGljIGludCBzdm1f
Y3B1X3VwKHZvaWQpCiAgICAgfQogI2VuZGlmCiAKKyAgICAvKiBJbml0aWFsaXplIE9TVlcgYml0
cyB0byBiZSB1c2VkIGJ5IGd1ZXN0cyAqLworICAgIHN2bV9ob3N0X29zdndfaW5pdCgpOworCiAg
ICAgcmV0dXJuIDA7CiB9CiAKQEAgLTExMDQsNiArMTE5OCw4IEBAIHN0cnVjdCBodm1fZnVuY3Rp
b25fdGFibGUgKiBfX2luaXQgc3RhcnQKICAgICBpZiAoICF0ZXN0X2JpdChYODZfRkVBVFVSRV9T
Vk0sICZib290X2NwdV9kYXRhLng4Nl9jYXBhYmlsaXR5KSApCiAgICAgICAgIHJldHVybiBOVUxM
OwogCisgICAgc3ZtX2hvc3Rfb3N2d19yZXNldCgpOworCiAgICAgaWYgKCBzdm1fY3B1X3VwKCkg
KQogICAgIHsKICAgICAgICAgcHJpbnRrKCJTVk06IGZhaWxlZCB0byBpbml0aWFsaXNlLlxuIik7
CkBAIC0xMzg4LDYgKzE0ODQsMTMgQEAgc3RhdGljIGludCBzdm1fbXNyX3JlYWRfaW50ZXJjZXB0
KHVuc2lnbgogICAgICAgICB2cG11X2RvX3JkbXNyKG1zciwgbXNyX2NvbnRlbnQpOwogICAgICAg
ICBicmVhazsKIAorICAgIGNhc2UgTVNSX0FNRF9PU1ZXX0lEX0xFTkdUSDoKKyAgICBjYXNlIE1T
Ul9BTURfT1NWV19TVEFUVVM6CisgICAgICAgIHJldCA9IHN2bV9oYW5kbGVfb3N2dyh2LCBtc3Is
IG1zcl9jb250ZW50LCAxKTsKKyAgICAgICAgaWYgKCByZXQgPCAwICkKKyAgICAgICAgICAgIGdv
dG8gZ3BmOworICAgICAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9IG5z
dm1fcmRtc3IodiwgbXNyLCBtc3JfY29udGVudCk7CiAgICAgICAgIGlmICggcmV0IDwgMCApCkBA
IC0xNTEyLDYgKzE2MTUsMTMgQEAgc3RhdGljIGludCBzdm1fbXNyX3dyaXRlX2ludGVyY2VwdCh1
bnNpZwogICAgICAgICAgKi8KICAgICAgICAgYnJlYWs7CiAKKyAgICBjYXNlIE1TUl9BTURfT1NW
V19JRF9MRU5HVEg6CisgICAgY2FzZSBNU1JfQU1EX09TVldfU1RBVFVTOgorICAgICAgICByZXQg
PSBzdm1faGFuZGxlX29zdncodiwgbXNyLCAmbXNyX2NvbnRlbnQsIDApOworICAgICAgICBpZiAo
IHJldCA8IDAgKQorICAgICAgICAgICAgZ290byBncGY7CisgICAgICAgIGJyZWFrOworCiAgICAg
ZGVmYXVsdDoKICAgICAgICAgcmV0ID0gbnN2bV93cm1zcih2LCBtc3IsIG1zcl9jb250ZW50KTsK
ICAgICAgICAgaWYgKCByZXQgPCAwICkKLS0tIGEveGVuL2FyY2gveDg2L21pY3JvY29kZS5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9taWNyb2NvZGUuYwpAQCAtMjE4LDYgKzIxOCwxNiBAQCBpbnQgbWlj
cm9jb2RlX3VwZGF0ZShYRU5fR1VFU1RfSEFORExFKGNvCiAgICAgaW5mby0+ZXJyb3IgPSAwOwog
ICAgIGluZm8tPmNwdSA9IGNwdW1hc2tfZmlyc3QoJmNwdV9vbmxpbmVfbWFwKTsKIAorICAgIGlm
ICggbWljcm9jb2RlX29wcy0+c3RhcnRfdXBkYXRlICkKKyAgICB7CisgICAgICAgIHJldCA9IG1p
Y3JvY29kZV9vcHMtPnN0YXJ0X3VwZGF0ZSgpOworICAgICAgICBpZiAoIHJldCAhPSAwICkKKyAg
ICAgICAgeworICAgICAgICAgICAgeGZyZWUoaW5mbyk7CisgICAgICAgICAgICByZXR1cm4gcmV0
OworICAgICAgICB9CisgICAgfQorCiAgICAgcmV0dXJuIGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9j
cHUoaW5mby0+Y3B1LCBkb19taWNyb2NvZGVfdXBkYXRlLCBpbmZvKTsKIH0KIApAQCAtMjQwLDYg
KzI1MCwxMiBAQCBzdGF0aWMgaW50IF9faW5pdCBtaWNyb2NvZGVfaW5pdCh2b2lkKQogICAgIGlm
ICggIWRhdGEgKQogICAgICAgICByZXR1cm4gLUVOT01FTTsKIAorICAgIGlmICggbWljcm9jb2Rl
X29wcy0+c3RhcnRfdXBkYXRlICYmIG1pY3JvY29kZV9vcHMtPnN0YXJ0X3VwZGF0ZSgpICE9IDAg
KQorICAgIHsKKyAgICAgICAgdWNvZGVfbW9kX21hcChOVUxMKTsKKyAgICAgICAgcmV0dXJuIDA7
CisgICAgfQorCiAgICAgc29mdGlycV90YXNrbGV0X2luaXQoJnRhc2tsZXQsIF9kb19taWNyb2Nv
ZGVfdXBkYXRlLCAodW5zaWduZWQgbG9uZylkYXRhKTsKIAogICAgIGZvcl9lYWNoX29ubGluZV9j
cHUgKCBjcHUgKQotLS0gYS94ZW4vYXJjaC94ODYvbWljcm9jb2RlX2FtZC5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9taWNyb2NvZGVfYW1kLmMKQEAgLTI1LDYgKzI1LDcgQEAKICNpbmNsdWRlIDxhc20v
bXNyLmg+CiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPGFzbS9taWNyb2Nv
ZGUuaD4KKyNpbmNsdWRlIDxhc20vaHZtL3N2bS9zdm0uaD4KIAogc3RydWN0IGVxdWl2X2NwdV9l
bnRyeSB7CiAgICAgdWludDMyX3QgaW5zdGFsbGVkX2NwdTsKQEAgLTcxLDYgKzcyLDcgQEAgc3Ry
dWN0IG1wYmhkciB7CiAvKiBzZXJpYWxpemUgYWNjZXNzIHRvIHRoZSBwaHlzaWNhbCB3cml0ZSAq
Lwogc3RhdGljIERFRklORV9TUElOTE9DSyhtaWNyb2NvZGVfdXBkYXRlX2xvY2spOwogCisvKiBT
ZWUgY29tbWVudCBpbiBzdGFydF91cGRhdGUoKSBmb3IgY2FzZXMgd2hlbiB0aGlzIHJvdXRpbmUg
ZmFpbHMgKi8KIHN0YXRpYyBpbnQgY29sbGVjdF9jcHVfaW5mbyhpbnQgY3B1LCBzdHJ1Y3QgY3B1
X3NpZ25hdHVyZSAqY3NpZykKIHsKICAgICBzdHJ1Y3QgY3B1aW5mb194ODYgKmMgPSAmY3B1X2Rh
dGFbY3B1XTsKQEAgLTI4Nyw3ICsyODksOCBAQCBzdGF0aWMgaW50IGNwdV9yZXF1ZXN0X21pY3Jv
Y29kZShpbnQgY3B1CiAgICAgewogICAgICAgICBwcmludGsoS0VSTl9FUlIgIm1pY3JvY29kZTog
ZXJyb3IhIFdyb25nICIKICAgICAgICAgICAgICAgICJtaWNyb2NvZGUgcGF0Y2ggZmlsZSBtYWdp
Y1xuIik7Ci0gICAgICAgIHJldHVybiAtRUlOVkFMOworICAgICAgICBlcnJvciA9IC1FSU5WQUw7
CisgICAgICAgIGdvdG8gb3V0OwogICAgIH0KIAogICAgIG1jX2FtZCA9IHhtYWxsb2Moc3RydWN0
IG1pY3JvY29kZV9hbWQpOwpAQCAtMjk1LDcgKzI5OCw4IEBAIHN0YXRpYyBpbnQgY3B1X3JlcXVl
c3RfbWljcm9jb2RlKGludCBjcHUKICAgICB7CiAgICAgICAgIHByaW50ayhLRVJOX0VSUiAibWlj
cm9jb2RlOiBlcnJvciEgIgogICAgICAgICAgICAgICAgIkNhbiBub3QgYWxsb2NhdGUgbWVtb3J5
IGZvciBtaWNyb2NvZGUgcGF0Y2hcbiIpOwotICAgICAgICByZXR1cm4gLUVOT01FTTsKKyAgICAg
ICAgZXJyb3IgPSAtRU5PTUVNOworICAgICAgICBnb3RvIG91dDsKICAgICB9CiAKICAgICBlcnJv
ciA9IGluc3RhbGxfZXF1aXZfY3B1X3RhYmxlKG1jX2FtZCwgYnVmLCAmb2Zmc2V0KTsKQEAgLTMw
Myw3ICszMDcsOCBAQCBzdGF0aWMgaW50IGNwdV9yZXF1ZXN0X21pY3JvY29kZShpbnQgY3B1CiAg
ICAgewogICAgICAgICB4ZnJlZShtY19hbWQpOwogICAgICAgICBwcmludGsoS0VSTl9FUlIgIm1p
Y3JvY29kZTogaW5zdGFsbGluZyBlcXVpdmFsZW50IGNwdSB0YWJsZSBmYWlsZWRcbiIpOwotICAg
ICAgICByZXR1cm4gLUVJTlZBTDsKKyAgICAgICAgZXJyb3IgPSAtRUlOVkFMOworICAgICAgICBn
b3RvIG91dDsKICAgICB9CiAKICAgICBtY19vbGQgPSB1Y2ktPm1jLm1jX2FtZDsKQEAgLTMzNywx
MyArMzQyLDE5IEBAIHN0YXRpYyBpbnQgY3B1X3JlcXVlc3RfbWljcm9jb2RlKGludCBjcHUKICAg
ICAvKiBPbiBzdWNjZXNzIGtlZXAgdGhlIG1pY3JvY29kZSBwYXRjaCBmb3IKICAgICAgKiByZS1h
cHBseSBvbiByZXN1bWUuCiAgICAgICovCi0gICAgaWYgKGVycm9yID09IDEpCisgICAgaWYgKCBl
cnJvciA9PSAxICkKICAgICB7CiAgICAgICAgIHhmcmVlKG1jX29sZCk7Ci0gICAgICAgIHJldHVy
biAwOworICAgICAgICBlcnJvciA9IDA7CisgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAg
IHhmcmVlKG1jX2FtZCk7CisgICAgICAgIHVjaS0+bWMubWNfYW1kID0gbWNfb2xkOwogICAgIH0K
LSAgICB4ZnJlZShtY19hbWQpOwotICAgIHVjaS0+bWMubWNfYW1kID0gbWNfb2xkOworCisgIG91
dDoKKyAgICBzdm1faG9zdF9vc3Z3X2luaXQoKTsKIAogICAgIHJldHVybiBlcnJvcjsKIH0KQEAg
LTM5NSwxMSArNDA2LDI4IEBAIGVycjE6CiAgICAgcmV0dXJuIC1FTk9NRU07CiB9CiAKK3N0YXRp
YyBpbnQgc3RhcnRfdXBkYXRlKHZvaWQpCit7CisgICAgLyoKKyAgICAgKiBXZSBhc3N1bWUgaGVy
ZSB0aGF0IHN2bV9ob3N0X29zdndfaW5pdCgpIHdpbGwgYmUgY2FsbGVkIG9uIGVhY2ggY3B1IChm
cm9tCisgICAgICogY3B1X3JlcXVlc3RfbWljcm9jb2RlKCkpLgorICAgICAqCisgICAgICogTm90
ZSB0aGF0IGlmIGNvbGxlY3RfY3B1X2luZm8oKSByZXR1cm5zIGFuIGVycm9yIHRoZW4KKyAgICAg
KiBjcHVfcmVxdWVzdF9taWNyb2NvZGUoKSB3aWxsIG5vdCBpbnZva2VkIHRodXMgbGVhdmluZyBP
U1ZXIGJpdHMgbm90CisgICAgICogdXBkYXRlZC4gQ3VycmVudGx5IHRob3VnaCBjb2xsZWN0X2Nw
dV9pbmZvKCkgd2lsbCBub3QgZmFpbCBvbiBwcm9jZXNzb3JzCisgICAgICogc3VwcG9ydGluZyBP
U1ZXIHNvIHdlIHdpbGwgbm90IGRlYWwgd2l0aCB0aGlzIHBvc3NpYmlsaXR5LgorICAgICAqLwor
ICAgIHN2bV9ob3N0X29zdndfcmVzZXQoKTsKKworICAgIHJldHVybiAwOworfQorCiBzdGF0aWMg
Y29uc3Qgc3RydWN0IG1pY3JvY29kZV9vcHMgbWljcm9jb2RlX2FtZF9vcHMgPSB7CiAgICAgLm1p
Y3JvY29kZV9yZXN1bWVfbWF0Y2ggICAgICAgICAgID0gbWljcm9jb2RlX3Jlc3VtZV9tYXRjaCwK
ICAgICAuY3B1X3JlcXVlc3RfbWljcm9jb2RlICAgICAgICAgICAgPSBjcHVfcmVxdWVzdF9taWNy
b2NvZGUsCiAgICAgLmNvbGxlY3RfY3B1X2luZm8gICAgICAgICAgICAgICAgID0gY29sbGVjdF9j
cHVfaW5mbywKICAgICAuYXBwbHlfbWljcm9jb2RlICAgICAgICAgICAgICAgICAgPSBhcHBseV9t
aWNyb2NvZGUsCisgICAgLnN0YXJ0X3VwZGF0ZSAgICAgICAgICAgICAgICAgICAgID0gc3RhcnRf
dXBkYXRlLAogfTsKIAogc3RhdGljIF9faW5pdCBpbnQgbWljcm9jb2RlX2luaXRfYW1kKHZvaWQp
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9oeXBlcmNhbGwuYworKysgYi94ZW4vYXJjaC94
ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMKQEAgLTE2Niw3ICsxNjYsMjEgQEAgcmV0X3QgZG9fcGxh
dGZvcm1fb3AoWEVOX0dVRVNUX0hBTkRMRSh4ZQogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAg
ICAgZ3Vlc3RfZnJvbV9jb21wYXRfaGFuZGxlKGRhdGEsIG9wLT51Lm1pY3JvY29kZS5kYXRhKTsK
KworICAgICAgICAvKgorICAgICAgICAgKiBhbGxvY192cGN1KCkgd2lsbCBhY2Nlc3MgZGF0YSB3
aGljaCBpcyBtb2RpZmllZCBkdXJpbmcKKyAgICAgICAgICogbWljcm9jb2RlIHVwZGF0ZQorICAg
ICAgICAgKi8KKyAgICAgICAgd2hpbGUgKCAhc3Bpbl90cnlsb2NrKCZ2Y3B1X2FsbG9jX2xvY2sp
ICkKKyAgICAgICAgICAgIGlmICggaHlwZXJjYWxsX3ByZWVtcHRfY2hlY2soKSApCisgICAgICAg
ICAgICB7CisgICAgICAgICAgICAgICAgcmV0ID0gaHlwZXJjYWxsX2NyZWF0ZV9jb250aW51YXRp
b24oCisgICAgICAgICAgICAgICAgICAgIF9fSFlQRVJWSVNPUl9wbGF0Zm9ybV9vcCwgImgiLCB1
X3hlbnBmX29wKTsKKyAgICAgICAgICAgICAgICBnb3RvIG91dDsKKyAgICAgICAgICAgIH0KKwog
ICAgICAgICByZXQgPSBtaWNyb2NvZGVfdXBkYXRlKGRhdGEsIG9wLT51Lm1pY3JvY29kZS5sZW5n
dGgpOworICAgICAgICBzcGluX3VubG9jaygmdmNwdV9hbGxvY19sb2NrKTsKICAgICB9CiAgICAg
YnJlYWs7CiAKLS0tIGEveGVuL2NvbW1vbi9kb21jdGwuYworKysgYi94ZW4vY29tbW9uL2RvbWN0
bC5jCkBAIC0yOSw2ICsyOSw3IEBACiAjaW5jbHVkZSA8eHNtL3hzbS5oPgogCiBzdGF0aWMgREVG
SU5FX1NQSU5MT0NLKGRvbWN0bF9sb2NrKTsKK0RFRklORV9TUElOTE9DSyh2Y3B1X2FsbG9jX2xv
Y2spOwogCiBpbnQgY3B1bWFza190b194ZW5jdGxfY3B1bWFwKAogICAgIHN0cnVjdCB4ZW5jdGxf
Y3B1bWFwICp4ZW5jdGxfY3B1bWFwLCBjb25zdCBjcHVtYXNrX3QgKmNwdW1hc2spCkBAIC01MDYs
NiArNTA3LDE4IEBAIGxvbmcgZG9fZG9tY3RsKFhFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWMKICAg
ICAgICAgLyogTmVlZGVkLCBmb3IgZXhhbXBsZSwgdG8gZW5zdXJlIHdyaXRhYmxlIHAudC4gc3Rh
dGUgaXMgc3luY2VkLiAqLwogICAgICAgICBkb21haW5fcGF1c2UoZCk7CiAKKyAgICAgICAgLyoK
KyAgICAgICAgICogQ2VydGFpbiBvcGVyYXRpb25zIChlLmcuIENQVSBtaWNyb2NvZGUgdXBkYXRl
cykgbW9kaWZ5IGRhdGEgd2hpY2ggaXMKKyAgICAgICAgICogdXNlZCBkdXJpbmcgVkNQVSBhbGxv
Y2F0aW9uL2luaXRpYWxpemF0aW9uCisgICAgICAgICAqLworICAgICAgICB3aGlsZSAoICFzcGlu
X3RyeWxvY2soJnZjcHVfYWxsb2NfbG9jaykgKQorICAgICAgICAgICAgaWYgKCBoeXBlcmNhbGxf
cHJlZW1wdF9jaGVjaygpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICByZXQgPSAg
aHlwZXJjYWxsX2NyZWF0ZV9jb250aW51YXRpb24oCisgICAgICAgICAgICAgICAgICAgIF9fSFlQ
RVJWSVNPUl9kb21jdGwsICJoIiwgdV9kb21jdGwpOworICAgICAgICAgICAgICAgIGdvdG8gbWF4
dmNwdV9vdXRfbm92Y3B1bG9jazsKKyAgICAgICAgICAgIH0KKwogICAgICAgICAvKiBXZSBjYW5u
b3QgcmVkdWNlIG1heGltdW0gVkNQVXMuICovCiAgICAgICAgIHJldCA9IC1FSU5WQUw7CiAgICAg
ICAgIGlmICggKG1heCA8IGQtPm1heF92Y3B1cykgJiYgKGQtPnZjcHVbbWF4XSAhPSBOVUxMKSAp
CkBAIC01NTUsNiArNTY4LDkgQEAgbG9uZyBkb19kb21jdGwoWEVOX0dVRVNUX0hBTkRMRSh4ZW5f
ZG9tYwogICAgICAgICByZXQgPSAwOwogCiAgICAgbWF4dmNwdV9vdXQ6CisgICAgICAgIHNwaW5f
dW5sb2NrKCZ2Y3B1X2FsbG9jX2xvY2spOworCisgICAgbWF4dmNwdV9vdXRfbm92Y3B1bG9jazoK
ICAgICAgICAgZG9tYWluX3VucGF1c2UoZCk7CiAgICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQp
OwogICAgIH0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL3N2bS5oCisrKyBiL3hl
bi9pbmNsdWRlL2FzbS14ODYvaHZtL3N2bS9zdm0uaApAQCAtOTgsNCArOTgsNyBAQCBleHRlcm4g
dTMyIHN2bV9mZWF0dXJlX2ZsYWdzOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IH5UU0NfUkFUSU9fUlNWRF9CSVRTICkKICNkZWZpbmUgdmNwdV90c2NfcmF0aW8odikgICAgICAg
VFNDX1JBVElPKCh2KS0+ZG9tYWluLT5hcmNoLnRzY19raHosIGNwdV9raHopCiAKK2V4dGVybiB2
b2lkIHN2bV9ob3N0X29zdndfcmVzZXQodm9pZCk7CitleHRlcm4gdm9pZCBzdm1faG9zdF9vc3Z3
X2luaXQodm9pZCk7CisKICNlbmRpZiAvKiBfX0FTTV9YODZfSFZNX1NWTV9IX18gKi8KLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL3ZtY2IuaAorKysgYi94ZW4vaW5jbHVkZS9hc20t
eDg2L2h2bS9zdm0vdm1jYi5oCkBAIC01MTYsNiArNTE2LDEyIEBAIHN0cnVjdCBhcmNoX3N2bV9z
dHJ1Y3QgewogICAgIAogICAgIC8qIEFNRCBsaWdodHdlaWdodCBwcm9maWxpbmcgTVNSICovCiAg
ICAgdWludDY0X3QgZ3Vlc3RfbHdwX2NmZzsKKworICAgIC8qIE9TVlcgTVNScyAqLworICAgIHN0
cnVjdCB7CisgICAgICAgIHU2NCBsZW5ndGg7CisgICAgICAgIHU2NCBzdGF0dXM7CisgICAgfSBv
c3Z3OwogfTsKIAogc3RydWN0IHZtY2Jfc3RydWN0ICphbGxvY192bWNiKHZvaWQpOwotLS0gYS94
ZW4vaW5jbHVkZS9hc20teDg2L21pY3JvY29kZS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWljcm9jb2RlLmgKQEAgLTExLDYgKzExLDcgQEAgc3RydWN0IG1pY3JvY29kZV9vcHMgewogICAg
IGludCAoKmNwdV9yZXF1ZXN0X21pY3JvY29kZSkoaW50IGNwdSwgY29uc3Qgdm9pZCAqYnVmLCBz
aXplX3Qgc2l6ZSk7CiAgICAgaW50ICgqY29sbGVjdF9jcHVfaW5mbykoaW50IGNwdSwgc3RydWN0
IGNwdV9zaWduYXR1cmUgKmNzaWcpOwogICAgIGludCAoKmFwcGx5X21pY3JvY29kZSkoaW50IGNw
dSk7CisgICAgaW50ICgqc3RhcnRfdXBkYXRlKSh2b2lkKTsKIH07CiAKIHN0cnVjdCBjcHVfc2ln
bmF0dXJlIHsKLS0tIGEveGVuL2luY2x1ZGUveGVuL2RvbWFpbi5oCisrKyBiL3hlbi9pbmNsdWRl
L3hlbi9kb21haW4uaApAQCAtNjksNiArNjksNyBAQCB2b2lkIGFyY2hfZHVtcF9kb21haW5faW5m
byhzdHJ1Y3QgZG9tYWluCiAKIHZvaWQgYXJjaF92Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KTsK
IAorZXh0ZXJuIHNwaW5sb2NrX3QgdmNwdV9hbGxvY19sb2NrOwogYm9vbF90IGRvbWN0bF9sb2Nr
X2FjcXVpcmUodm9pZCk7CiB2b2lkIGRvbWN0bF9sb2NrX3JlbGVhc2Uodm9pZCk7CiAK

--=__Part210F5227.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part210F5227.1__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 11:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 11:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruja3-0004ZR-0B; Tue, 07 Feb 2012 11:51:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ruja1-0004ZK-47
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 11:51:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328615460!51878186!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6091 invoked from network); 7 Feb 2012 11:51:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2012 11:51:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 07 Feb 2012 11:51:23 +0000
Message-Id: <4F311E470200007800071896@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 07 Feb 2012 11:51:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,<keir@xen.org>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
In-Reply-To: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part210F5227.1__="
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part210F5227.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 06.02.12 at 18:39, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1328549858 -3600
> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> x86/AMD: Add support for AMD's OSVW feature in guests.
>=20
> In some cases guests should not provide workarounds for errata even when =
the
> physical processor is affected. For example, because of erratum 400 =
on=20
> family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) =
before
> going to idle in order to avoid getting stuck in a non-C0 state. This is =
not
> necessary: HLT and IO instructions are intercepted and therefore there =
is no
> reason for erratum 400 workaround in the guest.
>=20
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.
>=20
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>

In the form below/attached (integration with boot time microcode
loading fixed and trailing white space removed)

Acked-by: Jan Beulich <jbeulich@suse.com>

-- Jan

In some cases guests should not provide workarounds for errata even when =
the
physical processor is affected. For example, because of erratum 400 on =
family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is =
not
necessary: HLT and IO instructions are intercepted and therefore there is =
no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
=20
 static bool_t amd_erratum383_found __read_mostly;
=20
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+static DEFINE_SPINLOCK(osvw_lock);
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len)
 {
     struct vcpu *curr =3D current;
@@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
=20
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length =3D (osvw_length >=3D 3) ? osvw_length =
: 3;
+    vcpu->arch.hvm_svm.osvw.status =3D osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest =
that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need =
to
+     * be conservative here and therefore we tell the guest that erratum =
298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length =3D=3D 0 && boot_cpu_data.x86 =3D=3D 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |=3D 1;
+}
+
+void svm_host_osvw_reset()
+{
+    spin_lock(&osvw_lock);
+
+    osvw_length =3D 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status =3D 0;
+
+    spin_unlock(&osvw_lock);
+}
+
+void svm_host_osvw_init()
+{
+    spin_lock(&osvw_lock);
+
+    /*
+     * Get OSVW bits. If bits are not the same on different processors =
then
+     * choose the worst case (i.e. if erratum is present on one processor =
and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len =3D status =3D 0;
+
+        if (len < osvw_length)
+            osvw_length =3D len;
+
+        osvw_status |=3D status;
+        osvw_status &=3D (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length =3D osvw_status =3D 0;
+
+    spin_unlock(&osvw_lock);
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
     }
=20
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
=20
@@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct=20
     }
 }
=20
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, =
bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr =3D=3D MSR_AMD_OSVW_ID_LENGTH)
+            *val =3D v->arch.hvm_svm.osvw.length;
+        else
+            *val =3D v->arch.hvm_svm.osvw.status;
+    }
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
     }
 #endif
=20
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
=20
@@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
=20
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
=20
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret =3D svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret =3D nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
=20
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret =3D svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret =3D nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error =3D 0;
     info->cpu =3D cpumask_first(&cpu_online_map);
=20
+    if ( microcode_ops->start_update )
+    {
+        ret =3D microcode_ops->start_update();
+        if ( ret !=3D 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, =
info);
 }
=20
@@ -240,6 +250,12 @@ static int __init microcode_init(void)
     if ( !data )
         return -ENOMEM;
=20
+    if ( microcode_ops->start_update && microcode_ops->start_update() =
!=3D 0 )
+    {
+        ucode_mod_map(NULL);
+        return 0;
+    }
+
     softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned =
long)data);
=20
     for_each_online_cpu ( cpu )
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
=20
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -71,6 +72,7 @@ struct mpbhdr {
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
=20
+/* See comment in start_update() for cases when this routine fails */
 static int collect_cpu_info(int cpu, struct cpu_signature *csig)
 {
     struct cpuinfo_x86 *c =3D &cpu_data[cpu];
@@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error =3D -EINVAL;
+        goto out;
     }
=20
     mc_amd =3D xmalloc(struct microcode_amd);
@@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error =3D -ENOMEM;
+        goto out;
     }
=20
     error =3D install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table =
failed\n");
-        return -EINVAL;
+        error =3D -EINVAL;
+        goto out;
     }
=20
     mc_old =3D uci->mc.mc_amd;
@@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error =3D=3D 1)
+    if ( error =3D=3D 1 )
     {
         xfree(mc_old);
-        return 0;
+        error =3D 0;
+    }
+    else
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd =3D mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd =3D mc_old;
+
+  out:
+    svm_host_osvw_init();
=20
     return error;
 }
@@ -395,11 +406,28 @@ err1:
     return -ENOMEM;
 }
=20
+static int start_update(void)
+{
+    /*
+     * We assume here that svm_host_osvw_init() will be called on each =
cpu (from
+     * cpu_request_microcode()).
+     *
+     * Note that if collect_cpu_info() returns an error then
+     * cpu_request_microcode() will not invoked thus leaving OSVW bits =
not
+     * updated. Currently though collect_cpu_info() will not fail on =
processors
+     * supporting OSVW so we will not deal with this possibility.
+     */
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops =3D {
     .microcode_resume_match           =3D microcode_resume_match,
     .cpu_request_microcode            =3D cpu_request_microcode,
     .collect_cpu_info                 =3D collect_cpu_info,
     .apply_microcode                  =3D apply_microcode,
+    .start_update                     =3D start_update,
 };
=20
 static __init int microcode_init_amd(void)
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
=20
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /*
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =3D hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret =3D microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
=20
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
=20
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
=20
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -506,6 +507,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. =
*/
         domain_pause(d);
=20
+        /*
+         * Certain operations (e.g. CPU microcode updates) modify data =
which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =3D  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                goto maxvcpu_out_novcpulock;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret =3D -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] !=3D NULL) )
@@ -555,6 +568,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret =3D 0;
=20
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
+
+    maxvcpu_out_novcpulock:
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, =
cpu_khz)
=20
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -516,6 +516,12 @@ struct arch_svm_struct {
    =20
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
=20
 struct vmcb_struct *alloc_vmcb(void);
--- a/xen/include/asm-x86/microcode.h
+++ b/xen/include/asm-x86/microcode.h
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
=20
 struct cpu_signature {
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
=20
 void arch_vcpu_reset(struct vcpu *v);
=20
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
=20



--=__Part210F5227.1__=
Content-Type: application/octet-stream; name="AMD-OSVW-guest"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="AMD-OSVW-guest"

eDg2L0FNRDogQWRkIHN1cHBvcnQgZm9yIEFNRCdzIE9TVlcgZmVhdHVyZSBpbiBndWVzdHMuCgpJ
biBzb21lIGNhc2VzIGd1ZXN0cyBzaG91bGQgbm90IHByb3ZpZGUgd29ya2Fyb3VuZHMgZm9yIGVy
cmF0YSBldmVuIHdoZW4gdGhlCnBoeXNpY2FsIHByb2Nlc3NvciBpcyBhZmZlY3RlZC4gRm9yIGV4
YW1wbGUsIGJlY2F1c2Ugb2YgZXJyYXR1bSA0MDAgb24gZmFtaWx5CjEwaCBwcm9jZXNzb3JzIGEg
TGludXggZ3Vlc3Qgd2lsbCByZWFkIGFuIE1TUiAocmVzdWx0aW5nIGluIFZNRVhJVCkgYmVmb3Jl
CmdvaW5nIHRvIGlkbGUgaW4gb3JkZXIgdG8gYXZvaWQgZ2V0dGluZyBzdHVjayBpbiBhIG5vbi1D
MCBzdGF0ZS4gVGhpcyBpcyBub3QKbmVjZXNzYXJ5OiBITFQgYW5kIElPIGluc3RydWN0aW9ucyBh
cmUgaW50ZXJjZXB0ZWQgYW5kIHRoZXJlZm9yZSB0aGVyZSBpcyBubwpyZWFzb24gZm9yIGVycmF0
dW0gNDAwIHdvcmthcm91bmQgaW4gdGhlIGd1ZXN0LgoKVGhpcyBwYXRjaCBhbGxvd3MgdXMgdG8g
cHJlc2VudCBhIGd1ZXN0IHdpdGggY2VydGFpbiBlcnJhdGEgYXMgZml4ZWQsCnJlZ2FyZGxlc3Mg
b2YgdGhlIHN0YXRlIG9mIGFjdHVhbCBoYXJkd2FyZS4KClNpZ25lZC1vZmYtYnk6IEJvcmlzIE9z
dHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CkFja2VkLWJ5OiBDaHJpc3RvcGggRWdn
ZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPgpBY2tlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVs
aWNoQHN1c2UuY29tPgoKLS0tIGEvdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMKKysrIGIvdG9v
bHMvbGlieGMveGNfY3B1aWRfeDg2LmMKQEAgLTEwOCw2ICsxMDgsNyBAQCBzdGF0aWMgdm9pZCBh
bWRfeGNfY3B1aWRfcG9saWN5KAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZF
QVRVUkVfU1NFNEEpIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJF
X01JU0FMSUdOU1NFKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVS
RV8zRE5PV1BSRUZFVENIKSB8CisgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVB
VFVSRV9PU1ZXKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9Y
T1ApIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZNQTQpIHwK
ICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX1RCTSkgfAotLS0gYS94
ZW4vYXJjaC94ODYvaHZtL3N2bS9zdm0uYworKysgYi94ZW4vYXJjaC94ODYvaHZtL3N2bS9zdm0u
YwpAQCAtODMsNiArODMsMTAgQEAgc3RhdGljIERFRklORV9QRVJfQ1BVX1JFQURfTU9TVExZKHZv
aWQgKgogCiBzdGF0aWMgYm9vbF90IGFtZF9lcnJhdHVtMzgzX2ZvdW5kIF9fcmVhZF9tb3N0bHk7
CiAKKy8qIE9TVlcgYml0cyAqLworc3RhdGljIHVpbnQ2NF90IG9zdndfbGVuZ3RoLCBvc3Z3X3N0
YXR1czsKK3N0YXRpYyBERUZJTkVfU1BJTkxPQ0sob3N2d19sb2NrKTsKKwogdm9pZCBfX3VwZGF0
ZV9ndWVzdF9laXAoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MsIHVuc2lnbmVkIGludCBpbnN0
X2xlbikKIHsKICAgICBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJlbnQ7CkBAIC05MDIsNiArOTA2
LDY5IEBAIHN0YXRpYyB2b2lkIHN2bV9kb19yZXN1bWUoc3RydWN0IHZjcHUgKnYKICAgICByZXNl
dF9zdGFja19hbmRfanVtcChzdm1fYXNtX2RvX3Jlc3VtZSk7CiB9CiAKK3N0YXRpYyB2b2lkIHN2
bV9ndWVzdF9vc3Z3X2luaXQoc3RydWN0IHZjcHUgKnZjcHUpCit7CisgICAgaWYgKCBib290X2Nw
dV9kYXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9BTUQgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKgorICAgICAqIEd1ZXN0cyBzaG91bGQgc2VlIGVycmF0YSA0MDAgYW5kIDQxNSBhcyBm
aXhlZCAoYXNzdW1pbmcgdGhhdAorICAgICAqIEhMVCBhbmQgSU8gaW5zdHJ1Y3Rpb25zIGFyZSBp
bnRlcmNlcHRlZCkuCisgICAgICovCisgICAgdmNwdS0+YXJjaC5odm1fc3ZtLm9zdncubGVuZ3Ro
ID0gKG9zdndfbGVuZ3RoID49IDMpID8gb3N2d19sZW5ndGggOiAzOworICAgIHZjcHUtPmFyY2gu
aHZtX3N2bS5vc3Z3LnN0YXR1cyA9IG9zdndfc3RhdHVzICYgfig2VUxMKTsKKworICAgIC8qCisg
ICAgICogQnkgaW5jcmVhc2luZyBWQ1BVJ3Mgb3N2dy5sZW5ndGggdG8gMyB3ZSBhcmUgdGVsbGlu
ZyB0aGUgZ3Vlc3QgdGhhdAorICAgICAqIGFsbCBvc3Z3LnN0YXR1cyBiaXRzIGluc2lkZSB0aGF0
IGxlbmd0aCwgaW5jbHVkaW5nIGJpdCAwICh3aGljaCBpcworICAgICAqIHJlc2VydmVkIGZvciBl
cnJhdHVtIDI5OCksIGFyZSB2YWxpZC4gSG93ZXZlciwgaWYgaG9zdCBwcm9jZXNzb3IncworICAg
ICAqIG9zdndfbGVuIGlzIDAgdGhlbiBvc3Z3X3N0YXR1c1swXSBjYXJyaWVzIG5vIGluZm9ybWF0
aW9uLiBXZSBuZWVkIHRvCisgICAgICogYmUgY29uc2VydmF0aXZlIGhlcmUgYW5kIHRoZXJlZm9y
ZSB3ZSB0ZWxsIHRoZSBndWVzdCB0aGF0IGVycmF0dW0gMjk4CisgICAgICogaXMgcHJlc2VudCAo
YmVjYXVzZSB3ZSByZWFsbHkgZG9uJ3Qga25vdykuCisgICAgICovCisgICAgaWYgKCBvc3Z3X2xl
bmd0aCA9PSAwICYmIGJvb3RfY3B1X2RhdGEueDg2ID09IDB4MTAgKQorICAgICAgICB2Y3B1LT5h
cmNoLmh2bV9zdm0ub3N2dy5zdGF0dXMgfD0gMTsKK30KKwordm9pZCBzdm1faG9zdF9vc3Z3X3Jl
c2V0KCkKK3sKKyAgICBzcGluX2xvY2soJm9zdndfbG9jayk7CisKKyAgICBvc3Z3X2xlbmd0aCA9
IDY0OyAvKiBPbmUgcmVnaXN0ZXIgKE1TUkMwMDFfMDE0MSkgd29ydGggb2YgZXJyYXRhICovCisg
ICAgb3N2d19zdGF0dXMgPSAwOworCisgICAgc3Bpbl91bmxvY2soJm9zdndfbG9jayk7Cit9CisK
K3ZvaWQgc3ZtX2hvc3Rfb3N2d19pbml0KCkKK3sKKyAgICBzcGluX2xvY2soJm9zdndfbG9jayk7
CisKKyAgICAvKgorICAgICAqIEdldCBPU1ZXIGJpdHMuIElmIGJpdHMgYXJlIG5vdCB0aGUgc2Ft
ZSBvbiBkaWZmZXJlbnQgcHJvY2Vzc29ycyB0aGVuCisgICAgICogY2hvb3NlIHRoZSB3b3JzdCBj
YXNlIChpLmUuIGlmIGVycmF0dW0gaXMgcHJlc2VudCBvbiBvbmUgcHJvY2Vzc29yIGFuZAorICAg
ICAqIG5vdCBvbiBhbm90aGVyIGFzc3VtZSB0aGF0IHRoZSBlcnJhdHVtIGlzIHByZXNlbnQgZXZl
cnl3aGVyZSkuCisgICAgICovCisgICAgaWYgKCB0ZXN0X2JpdChYODZfRkVBVFVSRV9PU1ZXLCAm
Ym9vdF9jcHVfZGF0YS54ODZfY2FwYWJpbGl0eSkgKQorICAgIHsKKyAgICAgICAgdWludDY0X3Qg
bGVuLCBzdGF0dXM7CisKKyAgICAgICAgaWYgKCByZG1zcl9zYWZlKE1TUl9BTURfT1NWV19JRF9M
RU5HVEgsIGxlbikgfHwKKyAgICAgICAgICAgICByZG1zcl9zYWZlKE1TUl9BTURfT1NWV19TVEFU
VVMsIHN0YXR1cykgKQorICAgICAgICAgICAgbGVuID0gc3RhdHVzID0gMDsKKworICAgICAgICBp
ZiAobGVuIDwgb3N2d19sZW5ndGgpCisgICAgICAgICAgICBvc3Z3X2xlbmd0aCA9IGxlbjsKKwor
ICAgICAgICBvc3Z3X3N0YXR1cyB8PSBzdGF0dXM7CisgICAgICAgIG9zdndfc3RhdHVzICY9ICgx
VUxMIDw8IG9zdndfbGVuZ3RoKSAtIDE7CisgICAgfQorICAgIGVsc2UKKyAgICAgICAgb3N2d19s
ZW5ndGggPSBvc3Z3X3N0YXR1cyA9IDA7CisKKyAgICBzcGluX3VubG9jaygmb3N2d19sb2NrKTsK
K30KKwogc3RhdGljIGludCBzdm1fZG9tYWluX2luaXRpYWxpc2Uoc3RydWN0IGRvbWFpbiAqZCkK
IHsKICAgICByZXR1cm4gMDsKQEAgLTkzMCw2ICs5OTcsOSBAQCBzdGF0aWMgaW50IHN2bV92Y3B1
X2luaXRpYWxpc2Uoc3RydWN0IHZjCiAgICAgfQogCiAgICAgdnBtdV9pbml0aWFsaXNlKHYpOwor
CisgICAgc3ZtX2d1ZXN0X29zdndfaW5pdCh2KTsKKwogICAgIHJldHVybiAwOwogfQogCkBAIC0x
MDQ0LDYgKzExMTQsMjcgQEAgc3RhdGljIHZvaWQgc3ZtX2luaXRfZXJyYXR1bV8zODMoc3RydWN0
IAogICAgIH0KIH0KIAorc3RhdGljIGludCBzdm1faGFuZGxlX29zdncoc3RydWN0IHZjcHUgKnYs
IHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCwgYm9vbF90IHJlYWQpCit7CisgICAgdWludCBl
YXgsIGVieCwgZWN4LCBlZHg7CisKKyAgICAvKiBHdWVzdCBPU1ZXIHN1cHBvcnQgKi8KKyAgICBo
dm1fY3B1aWQoMHg4MDAwMDAwMSwgJmVheCwgJmVieCwgJmVjeCwgJmVkeCk7CisgICAgaWYgKCAh
dGVzdF9iaXQoKFg4Nl9GRUFUVVJFX09TVlcgJiAzMSksICZlY3gpICkKKyAgICAgICAgcmV0dXJu
IC0xOworCisgICAgaWYgKCByZWFkICkKKyAgICB7CisgICAgICAgIGlmIChtc3IgPT0gTVNSX0FN
RF9PU1ZXX0lEX0xFTkdUSCkKKyAgICAgICAgICAgICp2YWwgPSB2LT5hcmNoLmh2bV9zdm0ub3N2
dy5sZW5ndGg7CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgICp2YWwgPSB2LT5hcmNoLmh2bV9z
dm0ub3N2dy5zdGF0dXM7CisgICAgfQorICAgIC8qIFdyaXRlcyBhcmUgaWdub3JlZCAqLworCisg
ICAgcmV0dXJuIDA7Cit9CisKIHN0YXRpYyBpbnQgc3ZtX2NwdV91cCh2b2lkKQogewogICAgIHVp
bnQ2NF90IG1zcl9jb250ZW50OwpAQCAtMTA5NCw2ICsxMTg1LDkgQEAgc3RhdGljIGludCBzdm1f
Y3B1X3VwKHZvaWQpCiAgICAgfQogI2VuZGlmCiAKKyAgICAvKiBJbml0aWFsaXplIE9TVlcgYml0
cyB0byBiZSB1c2VkIGJ5IGd1ZXN0cyAqLworICAgIHN2bV9ob3N0X29zdndfaW5pdCgpOworCiAg
ICAgcmV0dXJuIDA7CiB9CiAKQEAgLTExMDQsNiArMTE5OCw4IEBAIHN0cnVjdCBodm1fZnVuY3Rp
b25fdGFibGUgKiBfX2luaXQgc3RhcnQKICAgICBpZiAoICF0ZXN0X2JpdChYODZfRkVBVFVSRV9T
Vk0sICZib290X2NwdV9kYXRhLng4Nl9jYXBhYmlsaXR5KSApCiAgICAgICAgIHJldHVybiBOVUxM
OwogCisgICAgc3ZtX2hvc3Rfb3N2d19yZXNldCgpOworCiAgICAgaWYgKCBzdm1fY3B1X3VwKCkg
KQogICAgIHsKICAgICAgICAgcHJpbnRrKCJTVk06IGZhaWxlZCB0byBpbml0aWFsaXNlLlxuIik7
CkBAIC0xMzg4LDYgKzE0ODQsMTMgQEAgc3RhdGljIGludCBzdm1fbXNyX3JlYWRfaW50ZXJjZXB0
KHVuc2lnbgogICAgICAgICB2cG11X2RvX3JkbXNyKG1zciwgbXNyX2NvbnRlbnQpOwogICAgICAg
ICBicmVhazsKIAorICAgIGNhc2UgTVNSX0FNRF9PU1ZXX0lEX0xFTkdUSDoKKyAgICBjYXNlIE1T
Ul9BTURfT1NWV19TVEFUVVM6CisgICAgICAgIHJldCA9IHN2bV9oYW5kbGVfb3N2dyh2LCBtc3Is
IG1zcl9jb250ZW50LCAxKTsKKyAgICAgICAgaWYgKCByZXQgPCAwICkKKyAgICAgICAgICAgIGdv
dG8gZ3BmOworICAgICAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9IG5z
dm1fcmRtc3IodiwgbXNyLCBtc3JfY29udGVudCk7CiAgICAgICAgIGlmICggcmV0IDwgMCApCkBA
IC0xNTEyLDYgKzE2MTUsMTMgQEAgc3RhdGljIGludCBzdm1fbXNyX3dyaXRlX2ludGVyY2VwdCh1
bnNpZwogICAgICAgICAgKi8KICAgICAgICAgYnJlYWs7CiAKKyAgICBjYXNlIE1TUl9BTURfT1NW
V19JRF9MRU5HVEg6CisgICAgY2FzZSBNU1JfQU1EX09TVldfU1RBVFVTOgorICAgICAgICByZXQg
PSBzdm1faGFuZGxlX29zdncodiwgbXNyLCAmbXNyX2NvbnRlbnQsIDApOworICAgICAgICBpZiAo
IHJldCA8IDAgKQorICAgICAgICAgICAgZ290byBncGY7CisgICAgICAgIGJyZWFrOworCiAgICAg
ZGVmYXVsdDoKICAgICAgICAgcmV0ID0gbnN2bV93cm1zcih2LCBtc3IsIG1zcl9jb250ZW50KTsK
ICAgICAgICAgaWYgKCByZXQgPCAwICkKLS0tIGEveGVuL2FyY2gveDg2L21pY3JvY29kZS5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9taWNyb2NvZGUuYwpAQCAtMjE4LDYgKzIxOCwxNiBAQCBpbnQgbWlj
cm9jb2RlX3VwZGF0ZShYRU5fR1VFU1RfSEFORExFKGNvCiAgICAgaW5mby0+ZXJyb3IgPSAwOwog
ICAgIGluZm8tPmNwdSA9IGNwdW1hc2tfZmlyc3QoJmNwdV9vbmxpbmVfbWFwKTsKIAorICAgIGlm
ICggbWljcm9jb2RlX29wcy0+c3RhcnRfdXBkYXRlICkKKyAgICB7CisgICAgICAgIHJldCA9IG1p
Y3JvY29kZV9vcHMtPnN0YXJ0X3VwZGF0ZSgpOworICAgICAgICBpZiAoIHJldCAhPSAwICkKKyAg
ICAgICAgeworICAgICAgICAgICAgeGZyZWUoaW5mbyk7CisgICAgICAgICAgICByZXR1cm4gcmV0
OworICAgICAgICB9CisgICAgfQorCiAgICAgcmV0dXJuIGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9j
cHUoaW5mby0+Y3B1LCBkb19taWNyb2NvZGVfdXBkYXRlLCBpbmZvKTsKIH0KIApAQCAtMjQwLDYg
KzI1MCwxMiBAQCBzdGF0aWMgaW50IF9faW5pdCBtaWNyb2NvZGVfaW5pdCh2b2lkKQogICAgIGlm
ICggIWRhdGEgKQogICAgICAgICByZXR1cm4gLUVOT01FTTsKIAorICAgIGlmICggbWljcm9jb2Rl
X29wcy0+c3RhcnRfdXBkYXRlICYmIG1pY3JvY29kZV9vcHMtPnN0YXJ0X3VwZGF0ZSgpICE9IDAg
KQorICAgIHsKKyAgICAgICAgdWNvZGVfbW9kX21hcChOVUxMKTsKKyAgICAgICAgcmV0dXJuIDA7
CisgICAgfQorCiAgICAgc29mdGlycV90YXNrbGV0X2luaXQoJnRhc2tsZXQsIF9kb19taWNyb2Nv
ZGVfdXBkYXRlLCAodW5zaWduZWQgbG9uZylkYXRhKTsKIAogICAgIGZvcl9lYWNoX29ubGluZV9j
cHUgKCBjcHUgKQotLS0gYS94ZW4vYXJjaC94ODYvbWljcm9jb2RlX2FtZC5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9taWNyb2NvZGVfYW1kLmMKQEAgLTI1LDYgKzI1LDcgQEAKICNpbmNsdWRlIDxhc20v
bXNyLmg+CiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPGFzbS9taWNyb2Nv
ZGUuaD4KKyNpbmNsdWRlIDxhc20vaHZtL3N2bS9zdm0uaD4KIAogc3RydWN0IGVxdWl2X2NwdV9l
bnRyeSB7CiAgICAgdWludDMyX3QgaW5zdGFsbGVkX2NwdTsKQEAgLTcxLDYgKzcyLDcgQEAgc3Ry
dWN0IG1wYmhkciB7CiAvKiBzZXJpYWxpemUgYWNjZXNzIHRvIHRoZSBwaHlzaWNhbCB3cml0ZSAq
Lwogc3RhdGljIERFRklORV9TUElOTE9DSyhtaWNyb2NvZGVfdXBkYXRlX2xvY2spOwogCisvKiBT
ZWUgY29tbWVudCBpbiBzdGFydF91cGRhdGUoKSBmb3IgY2FzZXMgd2hlbiB0aGlzIHJvdXRpbmUg
ZmFpbHMgKi8KIHN0YXRpYyBpbnQgY29sbGVjdF9jcHVfaW5mbyhpbnQgY3B1LCBzdHJ1Y3QgY3B1
X3NpZ25hdHVyZSAqY3NpZykKIHsKICAgICBzdHJ1Y3QgY3B1aW5mb194ODYgKmMgPSAmY3B1X2Rh
dGFbY3B1XTsKQEAgLTI4Nyw3ICsyODksOCBAQCBzdGF0aWMgaW50IGNwdV9yZXF1ZXN0X21pY3Jv
Y29kZShpbnQgY3B1CiAgICAgewogICAgICAgICBwcmludGsoS0VSTl9FUlIgIm1pY3JvY29kZTog
ZXJyb3IhIFdyb25nICIKICAgICAgICAgICAgICAgICJtaWNyb2NvZGUgcGF0Y2ggZmlsZSBtYWdp
Y1xuIik7Ci0gICAgICAgIHJldHVybiAtRUlOVkFMOworICAgICAgICBlcnJvciA9IC1FSU5WQUw7
CisgICAgICAgIGdvdG8gb3V0OwogICAgIH0KIAogICAgIG1jX2FtZCA9IHhtYWxsb2Moc3RydWN0
IG1pY3JvY29kZV9hbWQpOwpAQCAtMjk1LDcgKzI5OCw4IEBAIHN0YXRpYyBpbnQgY3B1X3JlcXVl
c3RfbWljcm9jb2RlKGludCBjcHUKICAgICB7CiAgICAgICAgIHByaW50ayhLRVJOX0VSUiAibWlj
cm9jb2RlOiBlcnJvciEgIgogICAgICAgICAgICAgICAgIkNhbiBub3QgYWxsb2NhdGUgbWVtb3J5
IGZvciBtaWNyb2NvZGUgcGF0Y2hcbiIpOwotICAgICAgICByZXR1cm4gLUVOT01FTTsKKyAgICAg
ICAgZXJyb3IgPSAtRU5PTUVNOworICAgICAgICBnb3RvIG91dDsKICAgICB9CiAKICAgICBlcnJv
ciA9IGluc3RhbGxfZXF1aXZfY3B1X3RhYmxlKG1jX2FtZCwgYnVmLCAmb2Zmc2V0KTsKQEAgLTMw
Myw3ICszMDcsOCBAQCBzdGF0aWMgaW50IGNwdV9yZXF1ZXN0X21pY3JvY29kZShpbnQgY3B1CiAg
ICAgewogICAgICAgICB4ZnJlZShtY19hbWQpOwogICAgICAgICBwcmludGsoS0VSTl9FUlIgIm1p
Y3JvY29kZTogaW5zdGFsbGluZyBlcXVpdmFsZW50IGNwdSB0YWJsZSBmYWlsZWRcbiIpOwotICAg
ICAgICByZXR1cm4gLUVJTlZBTDsKKyAgICAgICAgZXJyb3IgPSAtRUlOVkFMOworICAgICAgICBn
b3RvIG91dDsKICAgICB9CiAKICAgICBtY19vbGQgPSB1Y2ktPm1jLm1jX2FtZDsKQEAgLTMzNywx
MyArMzQyLDE5IEBAIHN0YXRpYyBpbnQgY3B1X3JlcXVlc3RfbWljcm9jb2RlKGludCBjcHUKICAg
ICAvKiBPbiBzdWNjZXNzIGtlZXAgdGhlIG1pY3JvY29kZSBwYXRjaCBmb3IKICAgICAgKiByZS1h
cHBseSBvbiByZXN1bWUuCiAgICAgICovCi0gICAgaWYgKGVycm9yID09IDEpCisgICAgaWYgKCBl
cnJvciA9PSAxICkKICAgICB7CiAgICAgICAgIHhmcmVlKG1jX29sZCk7Ci0gICAgICAgIHJldHVy
biAwOworICAgICAgICBlcnJvciA9IDA7CisgICAgfQorICAgIGVsc2UKKyAgICB7CisgICAgICAg
IHhmcmVlKG1jX2FtZCk7CisgICAgICAgIHVjaS0+bWMubWNfYW1kID0gbWNfb2xkOwogICAgIH0K
LSAgICB4ZnJlZShtY19hbWQpOwotICAgIHVjaS0+bWMubWNfYW1kID0gbWNfb2xkOworCisgIG91
dDoKKyAgICBzdm1faG9zdF9vc3Z3X2luaXQoKTsKIAogICAgIHJldHVybiBlcnJvcjsKIH0KQEAg
LTM5NSwxMSArNDA2LDI4IEBAIGVycjE6CiAgICAgcmV0dXJuIC1FTk9NRU07CiB9CiAKK3N0YXRp
YyBpbnQgc3RhcnRfdXBkYXRlKHZvaWQpCit7CisgICAgLyoKKyAgICAgKiBXZSBhc3N1bWUgaGVy
ZSB0aGF0IHN2bV9ob3N0X29zdndfaW5pdCgpIHdpbGwgYmUgY2FsbGVkIG9uIGVhY2ggY3B1IChm
cm9tCisgICAgICogY3B1X3JlcXVlc3RfbWljcm9jb2RlKCkpLgorICAgICAqCisgICAgICogTm90
ZSB0aGF0IGlmIGNvbGxlY3RfY3B1X2luZm8oKSByZXR1cm5zIGFuIGVycm9yIHRoZW4KKyAgICAg
KiBjcHVfcmVxdWVzdF9taWNyb2NvZGUoKSB3aWxsIG5vdCBpbnZva2VkIHRodXMgbGVhdmluZyBP
U1ZXIGJpdHMgbm90CisgICAgICogdXBkYXRlZC4gQ3VycmVudGx5IHRob3VnaCBjb2xsZWN0X2Nw
dV9pbmZvKCkgd2lsbCBub3QgZmFpbCBvbiBwcm9jZXNzb3JzCisgICAgICogc3VwcG9ydGluZyBP
U1ZXIHNvIHdlIHdpbGwgbm90IGRlYWwgd2l0aCB0aGlzIHBvc3NpYmlsaXR5LgorICAgICAqLwor
ICAgIHN2bV9ob3N0X29zdndfcmVzZXQoKTsKKworICAgIHJldHVybiAwOworfQorCiBzdGF0aWMg
Y29uc3Qgc3RydWN0IG1pY3JvY29kZV9vcHMgbWljcm9jb2RlX2FtZF9vcHMgPSB7CiAgICAgLm1p
Y3JvY29kZV9yZXN1bWVfbWF0Y2ggICAgICAgICAgID0gbWljcm9jb2RlX3Jlc3VtZV9tYXRjaCwK
ICAgICAuY3B1X3JlcXVlc3RfbWljcm9jb2RlICAgICAgICAgICAgPSBjcHVfcmVxdWVzdF9taWNy
b2NvZGUsCiAgICAgLmNvbGxlY3RfY3B1X2luZm8gICAgICAgICAgICAgICAgID0gY29sbGVjdF9j
cHVfaW5mbywKICAgICAuYXBwbHlfbWljcm9jb2RlICAgICAgICAgICAgICAgICAgPSBhcHBseV9t
aWNyb2NvZGUsCisgICAgLnN0YXJ0X3VwZGF0ZSAgICAgICAgICAgICAgICAgICAgID0gc3RhcnRf
dXBkYXRlLAogfTsKIAogc3RhdGljIF9faW5pdCBpbnQgbWljcm9jb2RlX2luaXRfYW1kKHZvaWQp
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9oeXBlcmNhbGwuYworKysgYi94ZW4vYXJjaC94
ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMKQEAgLTE2Niw3ICsxNjYsMjEgQEAgcmV0X3QgZG9fcGxh
dGZvcm1fb3AoWEVOX0dVRVNUX0hBTkRMRSh4ZQogICAgICAgICAgICAgYnJlYWs7CiAKICAgICAg
ICAgZ3Vlc3RfZnJvbV9jb21wYXRfaGFuZGxlKGRhdGEsIG9wLT51Lm1pY3JvY29kZS5kYXRhKTsK
KworICAgICAgICAvKgorICAgICAgICAgKiBhbGxvY192cGN1KCkgd2lsbCBhY2Nlc3MgZGF0YSB3
aGljaCBpcyBtb2RpZmllZCBkdXJpbmcKKyAgICAgICAgICogbWljcm9jb2RlIHVwZGF0ZQorICAg
ICAgICAgKi8KKyAgICAgICAgd2hpbGUgKCAhc3Bpbl90cnlsb2NrKCZ2Y3B1X2FsbG9jX2xvY2sp
ICkKKyAgICAgICAgICAgIGlmICggaHlwZXJjYWxsX3ByZWVtcHRfY2hlY2soKSApCisgICAgICAg
ICAgICB7CisgICAgICAgICAgICAgICAgcmV0ID0gaHlwZXJjYWxsX2NyZWF0ZV9jb250aW51YXRp
b24oCisgICAgICAgICAgICAgICAgICAgIF9fSFlQRVJWSVNPUl9wbGF0Zm9ybV9vcCwgImgiLCB1
X3hlbnBmX29wKTsKKyAgICAgICAgICAgICAgICBnb3RvIG91dDsKKyAgICAgICAgICAgIH0KKwog
ICAgICAgICByZXQgPSBtaWNyb2NvZGVfdXBkYXRlKGRhdGEsIG9wLT51Lm1pY3JvY29kZS5sZW5n
dGgpOworICAgICAgICBzcGluX3VubG9jaygmdmNwdV9hbGxvY19sb2NrKTsKICAgICB9CiAgICAg
YnJlYWs7CiAKLS0tIGEveGVuL2NvbW1vbi9kb21jdGwuYworKysgYi94ZW4vY29tbW9uL2RvbWN0
bC5jCkBAIC0yOSw2ICsyOSw3IEBACiAjaW5jbHVkZSA8eHNtL3hzbS5oPgogCiBzdGF0aWMgREVG
SU5FX1NQSU5MT0NLKGRvbWN0bF9sb2NrKTsKK0RFRklORV9TUElOTE9DSyh2Y3B1X2FsbG9jX2xv
Y2spOwogCiBpbnQgY3B1bWFza190b194ZW5jdGxfY3B1bWFwKAogICAgIHN0cnVjdCB4ZW5jdGxf
Y3B1bWFwICp4ZW5jdGxfY3B1bWFwLCBjb25zdCBjcHVtYXNrX3QgKmNwdW1hc2spCkBAIC01MDYs
NiArNTA3LDE4IEBAIGxvbmcgZG9fZG9tY3RsKFhFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWMKICAg
ICAgICAgLyogTmVlZGVkLCBmb3IgZXhhbXBsZSwgdG8gZW5zdXJlIHdyaXRhYmxlIHAudC4gc3Rh
dGUgaXMgc3luY2VkLiAqLwogICAgICAgICBkb21haW5fcGF1c2UoZCk7CiAKKyAgICAgICAgLyoK
KyAgICAgICAgICogQ2VydGFpbiBvcGVyYXRpb25zIChlLmcuIENQVSBtaWNyb2NvZGUgdXBkYXRl
cykgbW9kaWZ5IGRhdGEgd2hpY2ggaXMKKyAgICAgICAgICogdXNlZCBkdXJpbmcgVkNQVSBhbGxv
Y2F0aW9uL2luaXRpYWxpemF0aW9uCisgICAgICAgICAqLworICAgICAgICB3aGlsZSAoICFzcGlu
X3RyeWxvY2soJnZjcHVfYWxsb2NfbG9jaykgKQorICAgICAgICAgICAgaWYgKCBoeXBlcmNhbGxf
cHJlZW1wdF9jaGVjaygpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICByZXQgPSAg
aHlwZXJjYWxsX2NyZWF0ZV9jb250aW51YXRpb24oCisgICAgICAgICAgICAgICAgICAgIF9fSFlQ
RVJWSVNPUl9kb21jdGwsICJoIiwgdV9kb21jdGwpOworICAgICAgICAgICAgICAgIGdvdG8gbWF4
dmNwdV9vdXRfbm92Y3B1bG9jazsKKyAgICAgICAgICAgIH0KKwogICAgICAgICAvKiBXZSBjYW5u
b3QgcmVkdWNlIG1heGltdW0gVkNQVXMuICovCiAgICAgICAgIHJldCA9IC1FSU5WQUw7CiAgICAg
ICAgIGlmICggKG1heCA8IGQtPm1heF92Y3B1cykgJiYgKGQtPnZjcHVbbWF4XSAhPSBOVUxMKSAp
CkBAIC01NTUsNiArNTY4LDkgQEAgbG9uZyBkb19kb21jdGwoWEVOX0dVRVNUX0hBTkRMRSh4ZW5f
ZG9tYwogICAgICAgICByZXQgPSAwOwogCiAgICAgbWF4dmNwdV9vdXQ6CisgICAgICAgIHNwaW5f
dW5sb2NrKCZ2Y3B1X2FsbG9jX2xvY2spOworCisgICAgbWF4dmNwdV9vdXRfbm92Y3B1bG9jazoK
ICAgICAgICAgZG9tYWluX3VucGF1c2UoZCk7CiAgICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQp
OwogICAgIH0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL3N2bS5oCisrKyBiL3hl
bi9pbmNsdWRlL2FzbS14ODYvaHZtL3N2bS9zdm0uaApAQCAtOTgsNCArOTgsNyBAQCBleHRlcm4g
dTMyIHN2bV9mZWF0dXJlX2ZsYWdzOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IH5UU0NfUkFUSU9fUlNWRF9CSVRTICkKICNkZWZpbmUgdmNwdV90c2NfcmF0aW8odikgICAgICAg
VFNDX1JBVElPKCh2KS0+ZG9tYWluLT5hcmNoLnRzY19raHosIGNwdV9raHopCiAKK2V4dGVybiB2
b2lkIHN2bV9ob3N0X29zdndfcmVzZXQodm9pZCk7CitleHRlcm4gdm9pZCBzdm1faG9zdF9vc3Z3
X2luaXQodm9pZCk7CisKICNlbmRpZiAvKiBfX0FTTV9YODZfSFZNX1NWTV9IX18gKi8KLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL3ZtY2IuaAorKysgYi94ZW4vaW5jbHVkZS9hc20t
eDg2L2h2bS9zdm0vdm1jYi5oCkBAIC01MTYsNiArNTE2LDEyIEBAIHN0cnVjdCBhcmNoX3N2bV9z
dHJ1Y3QgewogICAgIAogICAgIC8qIEFNRCBsaWdodHdlaWdodCBwcm9maWxpbmcgTVNSICovCiAg
ICAgdWludDY0X3QgZ3Vlc3RfbHdwX2NmZzsKKworICAgIC8qIE9TVlcgTVNScyAqLworICAgIHN0
cnVjdCB7CisgICAgICAgIHU2NCBsZW5ndGg7CisgICAgICAgIHU2NCBzdGF0dXM7CisgICAgfSBv
c3Z3OwogfTsKIAogc3RydWN0IHZtY2Jfc3RydWN0ICphbGxvY192bWNiKHZvaWQpOwotLS0gYS94
ZW4vaW5jbHVkZS9hc20teDg2L21pY3JvY29kZS5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYv
bWljcm9jb2RlLmgKQEAgLTExLDYgKzExLDcgQEAgc3RydWN0IG1pY3JvY29kZV9vcHMgewogICAg
IGludCAoKmNwdV9yZXF1ZXN0X21pY3JvY29kZSkoaW50IGNwdSwgY29uc3Qgdm9pZCAqYnVmLCBz
aXplX3Qgc2l6ZSk7CiAgICAgaW50ICgqY29sbGVjdF9jcHVfaW5mbykoaW50IGNwdSwgc3RydWN0
IGNwdV9zaWduYXR1cmUgKmNzaWcpOwogICAgIGludCAoKmFwcGx5X21pY3JvY29kZSkoaW50IGNw
dSk7CisgICAgaW50ICgqc3RhcnRfdXBkYXRlKSh2b2lkKTsKIH07CiAKIHN0cnVjdCBjcHVfc2ln
bmF0dXJlIHsKLS0tIGEveGVuL2luY2x1ZGUveGVuL2RvbWFpbi5oCisrKyBiL3hlbi9pbmNsdWRl
L3hlbi9kb21haW4uaApAQCAtNjksNiArNjksNyBAQCB2b2lkIGFyY2hfZHVtcF9kb21haW5faW5m
byhzdHJ1Y3QgZG9tYWluCiAKIHZvaWQgYXJjaF92Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KTsK
IAorZXh0ZXJuIHNwaW5sb2NrX3QgdmNwdV9hbGxvY19sb2NrOwogYm9vbF90IGRvbWN0bF9sb2Nr
X2FjcXVpcmUodm9pZCk7CiB2b2lkIGRvbWN0bF9sb2NrX3JlbGVhc2Uodm9pZCk7CiAK

--=__Part210F5227.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part210F5227.1__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:11:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 13: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.xensource.com>)
	id 1Rukp2-0006It-7t; Tue, 07 Feb 2012 13:11: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 1Rukp0-0006Il-Qa
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:10:59 +0000
Received: from [85.158.139.83:53160] by server-9.bemta-5.messagelabs.com id
	57/FA-23757-2E2213F4; Tue, 07 Feb 2012 13:10:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328620255!14046079!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31352 invoked from network); 7 Feb 2012 13:10:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 13:10:57 -0000
Received: by iaeh11 with SMTP id h11so59486190iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 05:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VC3WiF7nLXtls0/j9SKeWn6dxz19BJaICKMfrwAWppg=;
	b=tOlC0r8oQZBn4zJMgNuJZO3ZMKR9UhGNbFzZU66bOO6q/x4GliASvcmmv7u8VJOVVe
	A+IbYLxG+kZsskRktaNxF0ykgF2eFPXoetkl7WBWG8VVo5QCY72wxGs30JwKmZBBV8jD
	DksVi7P3O7YF7rD+JwEqoEPoRMYQdLNsu34s8=
Received: by 10.50.222.132 with SMTP id qm4mr16050425igc.21.1328620255363;
	Tue, 07 Feb 2012 05:10:55 -0800 (PST)
Received: from [101.1.150.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id r18sm33467514ibh.4.2012.02.07.05.10.52
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:10:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 05:10:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB5662D8.2A8BB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, RFC] Re:  x86: gnttab_clear_flag() abusing
	clear_bit()
Thread-Index: Aczlmeh6OWkCQNAUR0+TMe7UKhPCWw==
In-Reply-To: <4F310C5B0200007800071870@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 10:34, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.02.12 at 18:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>> Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
>> larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
>> to unsigned long * - how is that not a problem in the context of the
>> goal that said c/s set, in particular for v2 of the interface? (Given that
>> this is being implemented as arch-specific routine - so far for reasons
>> that escape me - this should be simple to fix by using inline assembly
>> rather than clear_bit().)
>> 
>> Further I just spotted one instance where the or of two bit positions
>> gets passed to this function - that's quite definitely a bug I would say.
>> 
>> And, quite the opposite, __fixup_status_for_pin() ands out the
>> negation of bit positions rather than masks... (Which also raises
>> the question whether it really would need to be clear_bit() above
>> instead of the cheaper __clear_bit().)
> 
> Below the tentative fix for all of the above problems. In the light
> of the comment at the top of x86's bitops.h I'm awaiting our gcc
> experts' response regarding the safety of using "+m" here.

Looks fine to me, in principle. I would add a comment to the x86
gnttab_clear_flag() explaining why we have to open code something that looks
a lot like clear_bit().

 -- Keir

> Jan
> 
> --- 2012-02-06.orig/xen/common/grant_table.c
> +++ 2012-02-06/xen/common/grant_table.c
> @@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
>               (id != domid) ||
>               (!readonly && (flags & GTF_readonly)) )
>          {
> -            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
> +            gnttab_clear_flag(_GTF_writing, status);
> +            gnttab_clear_flag(_GTF_reading, status);
>              PIN_FAIL(done, GNTST_general_error,
>                       "Unstable flags (%x) or dom (%d). (expected dom %d) "
>                       "(r/w: %d)\n",
> @@ -1715,14 +1716,14 @@ __release_grant_for_copy(
>     under the domain's grant table lock. */
>  /* Only safe on transitive grants.  Even then, note that we don't
>     attempt to drop any pin on the referent grant. */
> -static void __fixup_status_for_pin(struct active_grant_entry *act,
> +static void __fixup_status_for_pin(const struct active_grant_entry *act,
>                                     uint16_t *status)
>  {
>      if ( !(act->pin & GNTPIN_hstw_mask) )
> -        *status &= ~_GTF_writing;
> +        *status &= ~GTF_writing;
>  
>      if ( !(act->pin & GNTPIN_hstr_mask) )
> -        *status &= ~_GTF_reading;
> +        *status &= ~GTF_reading;
>  }
>  
>  /* Grab a frame number from a grant entry and update the flags and pin
> --- 2012-02-06.orig/xen/include/asm-ia64/grant_table.h
> +++ 2012-02-06/xen/include/asm-ia64/grant_table.h
> @@ -5,6 +5,8 @@
>  #ifndef __ASM_GRANT_TABLE_H__
>  #define __ASM_GRANT_TABLE_H__
>  
> +#include <asm/intrinsics.h>
> +
>  #define INITIAL_NR_GRANT_FRAMES 1
>  
>  // for grant map/unmap
> @@ -82,9 +84,15 @@ int guest_physmap_add_page(struct domain
>  
>  #define gnttab_mark_dirty(d, f) ((void)f)
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t *st)
>  {
> - clear_bit(nr, addr);
> + uint16_t mask = ~(1 << nr), old;
> + CMPXCHG_BUGCHECK_DECL
> +
> + do {
> +  CMPXCHG_BUGCHECK(st);
> +  old = *st;
> + } while (cmpxchg_rel(st, old, old & mask) != old);
>  }
>  
>  #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
> --- 2012-02-06.orig/xen/include/asm-x86/grant_table.h
> +++ 2012-02-06/xen/include/asm-x86/grant_table.h
> @@ -48,9 +48,11 @@ int replace_grant_host_mapping(
>  
>  #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, uint16_t *addr)
>  {
> -    clear_bit(nr, (unsigned long *)addr);
> +    asm volatile ("lock btrw %1,%0"
> +                  : "+m" (*addr)
> +                  : "Ir" (nr));
>  }
>  
>  /* Foreign mappings of HHVM-guest pages do not modify the type count. */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:11:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 13: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.xensource.com>)
	id 1Rukp2-0006It-7t; Tue, 07 Feb 2012 13:11: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 1Rukp0-0006Il-Qa
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:10:59 +0000
Received: from [85.158.139.83:53160] by server-9.bemta-5.messagelabs.com id
	57/FA-23757-2E2213F4; Tue, 07 Feb 2012 13:10:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328620255!14046079!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31352 invoked from network); 7 Feb 2012 13:10:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 13:10:57 -0000
Received: by iaeh11 with SMTP id h11so59486190iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 05:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VC3WiF7nLXtls0/j9SKeWn6dxz19BJaICKMfrwAWppg=;
	b=tOlC0r8oQZBn4zJMgNuJZO3ZMKR9UhGNbFzZU66bOO6q/x4GliASvcmmv7u8VJOVVe
	A+IbYLxG+kZsskRktaNxF0ykgF2eFPXoetkl7WBWG8VVo5QCY72wxGs30JwKmZBBV8jD
	DksVi7P3O7YF7rD+JwEqoEPoRMYQdLNsu34s8=
Received: by 10.50.222.132 with SMTP id qm4mr16050425igc.21.1328620255363;
	Tue, 07 Feb 2012 05:10:55 -0800 (PST)
Received: from [101.1.150.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id r18sm33467514ibh.4.2012.02.07.05.10.52
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:10:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 05:10:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB5662D8.2A8BB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, RFC] Re:  x86: gnttab_clear_flag() abusing
	clear_bit()
Thread-Index: Aczlmeh6OWkCQNAUR0+TMe7UKhPCWw==
In-Reply-To: <4F310C5B0200007800071870@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 10:34, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.02.12 at 18:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>> Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
>> larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
>> to unsigned long * - how is that not a problem in the context of the
>> goal that said c/s set, in particular for v2 of the interface? (Given that
>> this is being implemented as arch-specific routine - so far for reasons
>> that escape me - this should be simple to fix by using inline assembly
>> rather than clear_bit().)
>> 
>> Further I just spotted one instance where the or of two bit positions
>> gets passed to this function - that's quite definitely a bug I would say.
>> 
>> And, quite the opposite, __fixup_status_for_pin() ands out the
>> negation of bit positions rather than masks... (Which also raises
>> the question whether it really would need to be clear_bit() above
>> instead of the cheaper __clear_bit().)
> 
> Below the tentative fix for all of the above problems. In the light
> of the comment at the top of x86's bitops.h I'm awaiting our gcc
> experts' response regarding the safety of using "+m" here.

Looks fine to me, in principle. I would add a comment to the x86
gnttab_clear_flag() explaining why we have to open code something that looks
a lot like clear_bit().

 -- Keir

> Jan
> 
> --- 2012-02-06.orig/xen/common/grant_table.c
> +++ 2012-02-06/xen/common/grant_table.c
> @@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
>               (id != domid) ||
>               (!readonly && (flags & GTF_readonly)) )
>          {
> -            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
> +            gnttab_clear_flag(_GTF_writing, status);
> +            gnttab_clear_flag(_GTF_reading, status);
>              PIN_FAIL(done, GNTST_general_error,
>                       "Unstable flags (%x) or dom (%d). (expected dom %d) "
>                       "(r/w: %d)\n",
> @@ -1715,14 +1716,14 @@ __release_grant_for_copy(
>     under the domain's grant table lock. */
>  /* Only safe on transitive grants.  Even then, note that we don't
>     attempt to drop any pin on the referent grant. */
> -static void __fixup_status_for_pin(struct active_grant_entry *act,
> +static void __fixup_status_for_pin(const struct active_grant_entry *act,
>                                     uint16_t *status)
>  {
>      if ( !(act->pin & GNTPIN_hstw_mask) )
> -        *status &= ~_GTF_writing;
> +        *status &= ~GTF_writing;
>  
>      if ( !(act->pin & GNTPIN_hstr_mask) )
> -        *status &= ~_GTF_reading;
> +        *status &= ~GTF_reading;
>  }
>  
>  /* Grab a frame number from a grant entry and update the flags and pin
> --- 2012-02-06.orig/xen/include/asm-ia64/grant_table.h
> +++ 2012-02-06/xen/include/asm-ia64/grant_table.h
> @@ -5,6 +5,8 @@
>  #ifndef __ASM_GRANT_TABLE_H__
>  #define __ASM_GRANT_TABLE_H__
>  
> +#include <asm/intrinsics.h>
> +
>  #define INITIAL_NR_GRANT_FRAMES 1
>  
>  // for grant map/unmap
> @@ -82,9 +84,15 @@ int guest_physmap_add_page(struct domain
>  
>  #define gnttab_mark_dirty(d, f) ((void)f)
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t *st)
>  {
> - clear_bit(nr, addr);
> + uint16_t mask = ~(1 << nr), old;
> + CMPXCHG_BUGCHECK_DECL
> +
> + do {
> +  CMPXCHG_BUGCHECK(st);
> +  old = *st;
> + } while (cmpxchg_rel(st, old, old & mask) != old);
>  }
>  
>  #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
> --- 2012-02-06.orig/xen/include/asm-x86/grant_table.h
> +++ 2012-02-06/xen/include/asm-x86/grant_table.h
> @@ -48,9 +48,11 @@ int replace_grant_host_mapping(
>  
>  #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, uint16_t *addr)
>  {
> -    clear_bit(nr, (unsigned long *)addr);
> +    asm volatile ("lock btrw %1,%0"
> +                  : "+m" (*addr)
> +                  : "Ir" (nr));
>  }
>  
>  /* Foreign mappings of HHVM-guest pages do not modify the type count. */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:16:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 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.xensource.com>)
	id 1RuktW-0006Rr-Un; Tue, 07 Feb 2012 13:15: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 1RuktV-0006Rm-Lx
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:15:38 +0000
Received: from [85.158.139.83:20011] by server-6.bemta-5.messagelabs.com id
	A7/AE-04784-8F3213F4; Tue, 07 Feb 2012 13:15:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328620534!14020684!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8738 invoked from network); 7 Feb 2012 13:15:35 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 13:15:35 -0000
Received: by iaeh11 with SMTP id h11so59509991iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 05:15:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=sh6Tr4KxEr6nzF1SvjtIpoL4upxjbUjvCqY2T41iW8U=;
	b=wK8KVmyyYOE39Si3fCPIBzuu+w13+0BbTxdOmgPweI6ebgKlNvzr6YbyE7+C/WchmD
	Ng2jPBxGvrdRkI0WIaihKbD4Q22UDMJoUk/ou3Rhx8IvstDzvDJmWtCHmg45/caFRZG6
	V1knVyiTaQO0xW/wSawXV6DCkZnzO0KE8zviI=
Received: by 10.42.168.197 with SMTP id x5mr21734034icy.6.1328620533996;
	Tue, 07 Feb 2012 05:15:33 -0800 (PST)
Received: from [101.1.150.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id ng9sm25040603igc.3.2012.02.07.05.15.31
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:15:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 05:15:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <CB5663F0.2A8BC%keir.xen@gmail.com>
Thread-Topic: [PATCH v5] x86/AMD: Add support for AMD's OSVW feature in guests
Thread-Index: Aczlmo9fXzP/5c5nwUGb55TSP+Meow==
In-Reply-To: <4F311E470200007800071896@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 11:51, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.02.12 at 18:39, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1328549858 -3600
>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>> 
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on
>> family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
>> necessary: HLT and IO instructions are intercepted and therefore there is no
>> reason for erratum 400 workaround in the guest.
>> 
>> This patch allows us to present a guest with certain errata as fixed,
>> regardless of the state of actual hardware.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> In the form below/attached (integration with boot time microcode
> loading fixed and trailing white space removed)
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

There's one vpcu typo in a comment. Also the trylock while loops would
preferably have braces. Apart from that...

Acked-by: Keir Fraser <keir@xen.org>

> -- Jan
> 
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> necessary: HLT and IO instructions are intercepted and therefore there is no
> reason for erratum 400 workaround in the guest.
> 
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +                    bitmaskof(X86_FEATURE_OSVW) |
>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
>  
>  static bool_t amd_erratum383_found __read_mostly;
>  
> +/* OSVW bits */
> +static uint64_t osvw_length, osvw_status;
> +static DEFINE_SPINLOCK(osvw_lock);
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
>      reset_stack_and_jump(svm_asm_do_resume);
>  }
>  
> +static void svm_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return;
> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
> +    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 298
> +     * is present (because we really don't know).
> +     */
> +    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
> +        vcpu->arch.hvm_svm.osvw.status |= 1;
> +}
> +
> +void svm_host_osvw_reset()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
> +    osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);
> +}
> +
> +void svm_host_osvw_init()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    /*
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
> +    {
> +        uint64_t len, status;
> +
> +        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
> +            len = status = 0;
> +
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +    }
> +    else
> +        osvw_length = osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);
> +}
> +
>  static int svm_domain_initialise(struct domain *d)
>  {
>      return 0;
> @@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
>      }
>  
>      vpmu_initialise(v);
> +
> +    svm_guest_osvw_init(v);
> +
>      return 0;
>  }
>  
> @@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val,
> bool_t read)
> +{
> +    uint eax, ebx, ecx, edx;
> +
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
> +        return -1;
> +
> +    if ( read )
> +    {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.hvm_svm.osvw.length;
> +        else
> +            *val = v->arch.hvm_svm.osvw.status;
> +    }
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> @@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
>      }
>  #endif
>  
> +    /* Initialize OSVW bits to be used by guests */
> +    svm_host_osvw_init();
> +
>      return 0;
>  }
>  
> @@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
>      if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
>          return NULL;
>  
> +    svm_host_osvw_reset();
> +
>      if ( svm_cpu_up() )
>      {
>          printk("SVM: failed to initialise.\n");
> @@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
>          vpmu_do_rdmsr(msr, msr_content);
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, msr_content, 1);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_rdmsr(v, msr, msr_content);
>          if ( ret < 0 )
> @@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
>           */
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, &msr_content, 0);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_wrmsr(v, msr, msr_content);
>          if ( ret < 0 )
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +        ret = microcode_ops->start_update();
> +        if ( ret != 0 )
> +        {
> +            xfree(info);
> +            return ret;
> +        }
> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> @@ -240,6 +250,12 @@ static int __init microcode_init(void)
>      if ( !data )
>          return -ENOMEM;
>  
> +    if ( microcode_ops->start_update && microcode_ops->start_update() != 0 )
> +    {
> +        ucode_mod_map(NULL);
> +        return 0;
> +    }
> +
>      softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned
> long)data);
>  
>      for_each_online_cpu ( cpu )
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -25,6 +25,7 @@
>  #include <asm/msr.h>
>  #include <asm/processor.h>
>  #include <asm/microcode.h>
> +#include <asm/hvm/svm/svm.h>
>  
>  struct equiv_cpu_entry {
>      uint32_t installed_cpu;
> @@ -71,6 +72,7 @@ struct mpbhdr {
>  /* serialize access to the physical write */
>  static DEFINE_SPINLOCK(microcode_update_lock);
>  
> +/* See comment in start_update() for cases when this routine fails */
>  static int collect_cpu_info(int cpu, struct cpu_signature *csig)
>  {
>      struct cpuinfo_x86 *c = &cpu_data[cpu];
> @@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! Wrong "
>                 "microcode patch file magic\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_amd = xmalloc(struct microcode_amd);
> @@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! "
>                 "Can not allocate memory for microcode patch\n");
> -        return -ENOMEM;
> +        error = -ENOMEM;
> +        goto out;
>      }
>  
>      error = install_equiv_cpu_table(mc_amd, buf, &offset);
> @@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
>      {
>          xfree(mc_amd);
>          printk(KERN_ERR "microcode: installing equivalent cpu table
> failed\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_old = uci->mc.mc_amd;
> @@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    }
> +    else
> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> @@ -395,11 +406,28 @@ err1:
>      return -ENOMEM;
>  }
>  
> +static int start_update(void)
> +{
> +    /*
> +     * We assume here that svm_host_osvw_init() will be called on each cpu
> (from
> +     * cpu_request_microcode()).
> +     *
> +     * Note that if collect_cpu_info() returns an error then
> +     * cpu_request_microcode() will not invoked thus leaving OSVW bits not
> +     * updated. Currently though collect_cpu_info() will not fail on
> processors
> +     * supporting OSVW so we will not deal with this possibility.
> +     */
> +    svm_host_osvw_reset();
> +
> +    return 0;
> +}
> +
>  static const struct microcode_ops microcode_amd_ops = {
>      .microcode_resume_match           = microcode_resume_match,
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
> +    .start_update                     = start_update,
>  };
>  
>  static __init int microcode_init_amd(void)
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        /*
> +         * alloc_vpcu() will access data which is modified during
> +         * microcode update
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        spin_unlock(&vcpu_alloc_lock);
>      }
>      break;
>  
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -29,6 +29,7 @@
>  #include <xsm/xsm.h>
>  
>  static DEFINE_SPINLOCK(domctl_lock);
> +DEFINE_SPINLOCK(vcpu_alloc_lock);
>  
>  int cpumask_to_xenctl_cpumap(
>      struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> @@ -506,6 +507,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /*
> +         * Certain operations (e.g. CPU microcode updates) modify data which
> is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                goto maxvcpu_out_novcpulock;
> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> @@ -555,6 +568,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          ret = 0;
>  
>      maxvcpu_out:
> +        spin_unlock(&vcpu_alloc_lock);
> +
> +    maxvcpu_out_novcpulock:
>          domain_unpause(d);
>          rcu_unlock_domain(d);
>      }
> --- a/xen/include/asm-x86/hvm/svm/svm.h
> +++ b/xen/include/asm-x86/hvm/svm/svm.h
> @@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
>                                    ~TSC_RATIO_RSVD_BITS )
>  #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
>  
> +extern void svm_host_osvw_reset(void);
> +extern void svm_host_osvw_init(void);
> +
>  #endif /* __ASM_X86_HVM_SVM_H__ */
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -516,6 +516,12 @@ struct arch_svm_struct {
>      
>      /* AMD lightweight profiling MSR */
>      uint64_t guest_lwp_cfg;
> +
> +    /* OSVW MSRs */
> +    struct {
> +        u64 length;
> +        u64 status;
> +    } osvw;
>  };
>  
>  struct vmcb_struct *alloc_vmcb(void);
> --- a/xen/include/asm-x86/microcode.h
> +++ b/xen/include/asm-x86/microcode.h
> @@ -11,6 +11,7 @@ struct microcode_ops {
>      int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
>      int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
>      int (*apply_microcode)(int cpu);
> +    int (*start_update)(void);
>  };
>  
>  struct cpu_signature {
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
>  
>  void arch_vcpu_reset(struct vcpu *v);
>  
> +extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:16:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 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.xensource.com>)
	id 1RuktW-0006Rr-Un; Tue, 07 Feb 2012 13:15: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 1RuktV-0006Rm-Lx
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:15:38 +0000
Received: from [85.158.139.83:20011] by server-6.bemta-5.messagelabs.com id
	A7/AE-04784-8F3213F4; Tue, 07 Feb 2012 13:15:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328620534!14020684!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8738 invoked from network); 7 Feb 2012 13:15:35 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 13:15:35 -0000
Received: by iaeh11 with SMTP id h11so59509991iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 05:15:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=sh6Tr4KxEr6nzF1SvjtIpoL4upxjbUjvCqY2T41iW8U=;
	b=wK8KVmyyYOE39Si3fCPIBzuu+w13+0BbTxdOmgPweI6ebgKlNvzr6YbyE7+C/WchmD
	Ng2jPBxGvrdRkI0WIaihKbD4Q22UDMJoUk/ou3Rhx8IvstDzvDJmWtCHmg45/caFRZG6
	V1knVyiTaQO0xW/wSawXV6DCkZnzO0KE8zviI=
Received: by 10.42.168.197 with SMTP id x5mr21734034icy.6.1328620533996;
	Tue, 07 Feb 2012 05:15:33 -0800 (PST)
Received: from [101.1.150.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id ng9sm25040603igc.3.2012.02.07.05.15.31
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:15:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 05:15:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <CB5663F0.2A8BC%keir.xen@gmail.com>
Thread-Topic: [PATCH v5] x86/AMD: Add support for AMD's OSVW feature in guests
Thread-Index: Aczlmo9fXzP/5c5nwUGb55TSP+Meow==
In-Reply-To: <4F311E470200007800071896@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
	feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 11:51, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.02.12 at 18:39, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
>> # Date 1328549858 -3600
>> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
>> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
>> x86/AMD: Add support for AMD's OSVW feature in guests.
>> 
>> In some cases guests should not provide workarounds for errata even when the
>> physical processor is affected. For example, because of erratum 400 on
>> family
>> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
>> going to idle in order to avoid getting stuck in a non-C0 state. This is not
>> necessary: HLT and IO instructions are intercepted and therefore there is no
>> reason for erratum 400 workaround in the guest.
>> 
>> This patch allows us to present a guest with certain errata as fixed,
>> regardless of the state of actual hardware.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> In the form below/attached (integration with boot time microcode
> loading fixed and trailing white space removed)
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

There's one vpcu typo in a comment. Also the trylock while loops would
preferably have braces. Apart from that...

Acked-by: Keir Fraser <keir@xen.org>

> -- Jan
> 
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on family
> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> necessary: HLT and IO instructions are intercepted and therefore there is no
> reason for erratum 400 workaround in the guest.
> 
> This patch allows us to present a guest with certain errata as fixed,
> regardless of the state of actual hardware.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +                    bitmaskof(X86_FEATURE_OSVW) |
>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -83,6 +83,10 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
>  
>  static bool_t amd_erratum383_found __read_mostly;
>  
> +/* OSVW bits */
> +static uint64_t osvw_length, osvw_status;
> +static DEFINE_SPINLOCK(osvw_lock);
> +
>  void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
>  {
>      struct vcpu *curr = current;
> @@ -902,6 +906,69 @@ static void svm_do_resume(struct vcpu *v
>      reset_stack_and_jump(svm_asm_do_resume);
>  }
>  
> +static void svm_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> +        return;
> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
> +    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 298
> +     * is present (because we really don't know).
> +     */
> +    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
> +        vcpu->arch.hvm_svm.osvw.status |= 1;
> +}
> +
> +void svm_host_osvw_reset()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
> +    osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);
> +}
> +
> +void svm_host_osvw_init()
> +{
> +    spin_lock(&osvw_lock);
> +
> +    /*
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
> +    {
> +        uint64_t len, status;
> +
> +        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
> +            len = status = 0;
> +
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +    }
> +    else
> +        osvw_length = osvw_status = 0;
> +
> +    spin_unlock(&osvw_lock);
> +}
> +
>  static int svm_domain_initialise(struct domain *d)
>  {
>      return 0;
> @@ -930,6 +997,9 @@ static int svm_vcpu_initialise(struct vc
>      }
>  
>      vpmu_initialise(v);
> +
> +    svm_guest_osvw_init(v);
> +
>      return 0;
>  }
>  
> @@ -1044,6 +1114,27 @@ static void svm_init_erratum_383(struct
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val,
> bool_t read)
> +{
> +    uint eax, ebx, ecx, edx;
> +
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
> +        return -1;
> +
> +    if ( read )
> +    {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.hvm_svm.osvw.length;
> +        else
> +            *val = v->arch.hvm_svm.osvw.status;
> +    }
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> @@ -1094,6 +1185,9 @@ static int svm_cpu_up(void)
>      }
>  #endif
>  
> +    /* Initialize OSVW bits to be used by guests */
> +    svm_host_osvw_init();
> +
>      return 0;
>  }
>  
> @@ -1104,6 +1198,8 @@ struct hvm_function_table * __init start
>      if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
>          return NULL;
>  
> +    svm_host_osvw_reset();
> +
>      if ( svm_cpu_up() )
>      {
>          printk("SVM: failed to initialise.\n");
> @@ -1388,6 +1484,13 @@ static int svm_msr_read_intercept(unsign
>          vpmu_do_rdmsr(msr, msr_content);
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, msr_content, 1);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_rdmsr(v, msr, msr_content);
>          if ( ret < 0 )
> @@ -1512,6 +1615,13 @@ static int svm_msr_write_intercept(unsig
>           */
>          break;
>  
> +    case MSR_AMD_OSVW_ID_LENGTH:
> +    case MSR_AMD_OSVW_STATUS:
> +        ret = svm_handle_osvw(v, msr, &msr_content, 0);
> +        if ( ret < 0 )
> +            goto gpf;
> +        break;
> +
>      default:
>          ret = nsvm_wrmsr(v, msr, msr_content);
>          if ( ret < 0 )
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +        ret = microcode_ops->start_update();
> +        if ( ret != 0 )
> +        {
> +            xfree(info);
> +            return ret;
> +        }
> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> @@ -240,6 +250,12 @@ static int __init microcode_init(void)
>      if ( !data )
>          return -ENOMEM;
>  
> +    if ( microcode_ops->start_update && microcode_ops->start_update() != 0 )
> +    {
> +        ucode_mod_map(NULL);
> +        return 0;
> +    }
> +
>      softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned
> long)data);
>  
>      for_each_online_cpu ( cpu )
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -25,6 +25,7 @@
>  #include <asm/msr.h>
>  #include <asm/processor.h>
>  #include <asm/microcode.h>
> +#include <asm/hvm/svm/svm.h>
>  
>  struct equiv_cpu_entry {
>      uint32_t installed_cpu;
> @@ -71,6 +72,7 @@ struct mpbhdr {
>  /* serialize access to the physical write */
>  static DEFINE_SPINLOCK(microcode_update_lock);
>  
> +/* See comment in start_update() for cases when this routine fails */
>  static int collect_cpu_info(int cpu, struct cpu_signature *csig)
>  {
>      struct cpuinfo_x86 *c = &cpu_data[cpu];
> @@ -287,7 +289,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! Wrong "
>                 "microcode patch file magic\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_amd = xmalloc(struct microcode_amd);
> @@ -295,7 +298,8 @@ static int cpu_request_microcode(int cpu
>      {
>          printk(KERN_ERR "microcode: error! "
>                 "Can not allocate memory for microcode patch\n");
> -        return -ENOMEM;
> +        error = -ENOMEM;
> +        goto out;
>      }
>  
>      error = install_equiv_cpu_table(mc_amd, buf, &offset);
> @@ -303,7 +307,8 @@ static int cpu_request_microcode(int cpu
>      {
>          xfree(mc_amd);
>          printk(KERN_ERR "microcode: installing equivalent cpu table
> failed\n");
> -        return -EINVAL;
> +        error = -EINVAL;
> +        goto out;
>      }
>  
>      mc_old = uci->mc.mc_amd;
> @@ -337,13 +342,19 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    }
> +    else
> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> @@ -395,11 +406,28 @@ err1:
>      return -ENOMEM;
>  }
>  
> +static int start_update(void)
> +{
> +    /*
> +     * We assume here that svm_host_osvw_init() will be called on each cpu
> (from
> +     * cpu_request_microcode()).
> +     *
> +     * Note that if collect_cpu_info() returns an error then
> +     * cpu_request_microcode() will not invoked thus leaving OSVW bits not
> +     * updated. Currently though collect_cpu_info() will not fail on
> processors
> +     * supporting OSVW so we will not deal with this possibility.
> +     */
> +    svm_host_osvw_reset();
> +
> +    return 0;
> +}
> +
>  static const struct microcode_ops microcode_amd_ops = {
>      .microcode_resume_match           = microcode_resume_match,
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
> +    .start_update                     = start_update,
>  };
>  
>  static __init int microcode_init_amd(void)
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        /*
> +         * alloc_vpcu() will access data which is modified during
> +         * microcode update
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        spin_unlock(&vcpu_alloc_lock);
>      }
>      break;
>  
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -29,6 +29,7 @@
>  #include <xsm/xsm.h>
>  
>  static DEFINE_SPINLOCK(domctl_lock);
> +DEFINE_SPINLOCK(vcpu_alloc_lock);
>  
>  int cpumask_to_xenctl_cpumap(
>      struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> @@ -506,6 +507,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          /* Needed, for example, to ensure writable p.t. state is synced. */
>          domain_pause(d);
>  
> +        /*
> +         * Certain operations (e.g. CPU microcode updates) modify data which
> is
> +         * used during VCPU allocation/initialization
> +         */
> +        while ( !spin_trylock(&vcpu_alloc_lock) )
> +            if ( hypercall_preempt_check() )
> +            {
> +                ret =  hypercall_create_continuation(
> +                    __HYPERVISOR_domctl, "h", u_domctl);
> +                goto maxvcpu_out_novcpulock;
> +            }
> +
>          /* We cannot reduce maximum VCPUs. */
>          ret = -EINVAL;
>          if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> @@ -555,6 +568,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          ret = 0;
>  
>      maxvcpu_out:
> +        spin_unlock(&vcpu_alloc_lock);
> +
> +    maxvcpu_out_novcpulock:
>          domain_unpause(d);
>          rcu_unlock_domain(d);
>      }
> --- a/xen/include/asm-x86/hvm/svm/svm.h
> +++ b/xen/include/asm-x86/hvm/svm/svm.h
> @@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
>                                    ~TSC_RATIO_RSVD_BITS )
>  #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
>  
> +extern void svm_host_osvw_reset(void);
> +extern void svm_host_osvw_init(void);
> +
>  #endif /* __ASM_X86_HVM_SVM_H__ */
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -516,6 +516,12 @@ struct arch_svm_struct {
>      
>      /* AMD lightweight profiling MSR */
>      uint64_t guest_lwp_cfg;
> +
> +    /* OSVW MSRs */
> +    struct {
> +        u64 length;
> +        u64 status;
> +    } osvw;
>  };
>  
>  struct vmcb_struct *alloc_vmcb(void);
> --- a/xen/include/asm-x86/microcode.h
> +++ b/xen/include/asm-x86/microcode.h
> @@ -11,6 +11,7 @@ struct microcode_ops {
>      int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
>      int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
>      int (*apply_microcode)(int cpu);
> +    int (*start_update)(void);
>  };
>  
>  struct cpu_signature {
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
>  
>  void arch_vcpu_reset(struct vcpu *v);
>  
> +extern spinlock_t vcpu_alloc_lock;
>  bool_t domctl_lock_acquire(void);
>  void domctl_lock_release(void);
>  
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 13:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RulCg-00075b-K3; Tue, 07 Feb 2012 13:35:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RulCf-00075V-V2
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:35:26 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328621718!13277658!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13510 invoked from network); 7 Feb 2012 13:35:19 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	VA3EHSOBE003.bigfish.com) (216.32.180.30)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 13:35:19 -0000
Received: from mail96-va3-R.bigfish.com (10.7.14.249) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 13:35:17 +0000
Received: from mail96-va3 (localhost [127.0.0.1])	by mail96-va3-R.bigfish.com
	(Postfix) with ESMTP id 16D163400D1;
	Tue,  7 Feb 2012 13:35:17 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI936eK98bK1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail96-va3 (localhost.localdomain [127.0.0.1]) by mail96-va3
	(MessageSwitch) id 1328621714824512_7647;
	Tue,  7 Feb 2012 13:35:14 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.250])	by
	mail96-va3.bigfish.com (Postfix) with ESMTP id BC9F32C025B;
	Tue,  7 Feb 2012 13:35:14 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 13:35:14 +0000
X-WSS-ID: 0LZ0Z2P-01-5JJ-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 2FE301028299;	Tue,  7 Feb 2012 07:35:13 -0600 (CST)
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;
	Tue, 7 Feb 2012 07:35:21 -0600
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.289.1;
	Tue, 7 Feb 2012 07:35:15 -0600
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, 7 Feb 2012
	08:35:12 -0500
Message-ID: <4F31288F.5060904@amd.com>
Date: Tue, 7 Feb 2012 14:35:11 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	<seabios@seabios.org>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Adding seabios ML.

On 01/26/12 16:06, Ian Campbell wrote:
 > On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
 >> On 01/26/12 15:51, Ian Campbell wrote:
 >>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
 >>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
 >>>>      Building ld scripts (version "1.6.3.1-20120126_152501")
 >>>> env: python: No such file or directory
 >>>> gmake[6]: *** [out/romlayout16.lds] Error 127
 >>>>
 >>>>
 >>>> The python scripts must be invoked with $(PYTHON) as done
 >>>> throughout the build system.
 >>>
 >>> SeaBIOS uses:
 >>> $ rgrep -i python tools/firmware/seabios-dir
 >>> tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install 
python-serial
 >>> tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
 >>>
 >>> Does this not work? Should python be on your $PATH?
 >>
 >> It is. But the python binary on NetBSD's pkgsrc
 >> is called python<version>  to allow concurrent installations of 
different
 >> python versions.
 >> So I can have: python2.5, python2.6, python2.7, python3.1, etc.
 >
 > There is no current "python" referring to the default version?
 >
 > I think this is something you will need to work out with the SeaBIOS
 > upstream.
 >
 > Ian.
 >
 >>
 >> Christoph
 >>
 >>>
 >>> Since SeaBIOS is third party code we are not so much at liberty to make
 >>> the same sorts of policy decisions as we would for our own code.
 >>>
 >>> You could perhaps attempt to work around this by invoking the recursive
 >>> make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
 >>> whatever the appropriate runes are.
 >>>
 >>> Or you could try posting a patch to SeaBIOS-devel, I don't know what
 >>> their thinking on this sort of thing is.

I see.

What python version does SeaBIOS require?
I have python 2.5 installed.

I manually created a python symlink to that version and then I get this 
failure:

gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
   Building ld scripts (version "1.6.3.1-20120127_151243")
Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
16bit size:           46336
32bit segmented size: 2005
32bit flat size:      14699
32bit flat init size: 53888
Traceback (most recent call last):
   File "./tools/layoutrom.py", line 579, in <module>
     main()
   File "./tools/layoutrom.py", line 576, in main
     writeLinkerScripts(sections, entrysym, genreloc, out16, out32seg, 
out32flag)
   File "./tools/layoutrom.py", line 257, in writeLinkerScripts
     + COMMONTRAILER
TypeError: int argument required
gmake[6]: *** [out/romlayout16.lds] Error 1


Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 13:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RulCg-00075b-K3; Tue, 07 Feb 2012 13:35:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RulCf-00075V-V2
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:35:26 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328621718!13277658!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13510 invoked from network); 7 Feb 2012 13:35:19 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	VA3EHSOBE003.bigfish.com) (216.32.180.30)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 13:35:19 -0000
Received: from mail96-va3-R.bigfish.com (10.7.14.249) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 13:35:17 +0000
Received: from mail96-va3 (localhost [127.0.0.1])	by mail96-va3-R.bigfish.com
	(Postfix) with ESMTP id 16D163400D1;
	Tue,  7 Feb 2012 13:35:17 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI936eK98bK1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail96-va3 (localhost.localdomain [127.0.0.1]) by mail96-va3
	(MessageSwitch) id 1328621714824512_7647;
	Tue,  7 Feb 2012 13:35:14 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.250])	by
	mail96-va3.bigfish.com (Postfix) with ESMTP id BC9F32C025B;
	Tue,  7 Feb 2012 13:35:14 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Tue, 7 Feb 2012 13:35:14 +0000
X-WSS-ID: 0LZ0Z2P-01-5JJ-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 2FE301028299;	Tue,  7 Feb 2012 07:35:13 -0600 (CST)
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;
	Tue, 7 Feb 2012 07:35:21 -0600
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.289.1;
	Tue, 7 Feb 2012 07:35:15 -0600
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, 7 Feb 2012
	08:35:12 -0500
Message-ID: <4F31288F.5060904@amd.com>
Date: Tue, 7 Feb 2012 14:35:11 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	<seabios@seabios.org>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Adding seabios ML.

On 01/26/12 16:06, Ian Campbell wrote:
 > On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
 >> On 01/26/12 15:51, Ian Campbell wrote:
 >>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
 >>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
 >>>>      Building ld scripts (version "1.6.3.1-20120126_152501")
 >>>> env: python: No such file or directory
 >>>> gmake[6]: *** [out/romlayout16.lds] Error 127
 >>>>
 >>>>
 >>>> The python scripts must be invoked with $(PYTHON) as done
 >>>> throughout the build system.
 >>>
 >>> SeaBIOS uses:
 >>> $ rgrep -i python tools/firmware/seabios-dir
 >>> tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
 >>> tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install 
python-serial
 >>> tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
 >>>
 >>> Does this not work? Should python be on your $PATH?
 >>
 >> It is. But the python binary on NetBSD's pkgsrc
 >> is called python<version>  to allow concurrent installations of 
different
 >> python versions.
 >> So I can have: python2.5, python2.6, python2.7, python3.1, etc.
 >
 > There is no current "python" referring to the default version?
 >
 > I think this is something you will need to work out with the SeaBIOS
 > upstream.
 >
 > Ian.
 >
 >>
 >> Christoph
 >>
 >>>
 >>> Since SeaBIOS is third party code we are not so much at liberty to make
 >>> the same sorts of policy decisions as we would for our own code.
 >>>
 >>> You could perhaps attempt to work around this by invoking the recursive
 >>> make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
 >>> whatever the appropriate runes are.
 >>>
 >>> Or you could try posting a patch to SeaBIOS-devel, I don't know what
 >>> their thinking on this sort of thing is.

I see.

What python version does SeaBIOS require?
I have python 2.5 installed.

I manually created a python symlink to that version and then I get this 
failure:

gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
   Building ld scripts (version "1.6.3.1-20120127_151243")
Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
16bit size:           46336
32bit segmented size: 2005
32bit flat size:      14699
32bit flat init size: 53888
Traceback (most recent call last):
   File "./tools/layoutrom.py", line 579, in <module>
     main()
   File "./tools/layoutrom.py", line 576, in main
     writeLinkerScripts(sections, entrysym, genreloc, out16, out32seg, 
out32flag)
   File "./tools/layoutrom.py", line 257, in writeLinkerScripts
     + COMMONTRAILER
TypeError: int argument required
gmake[6]: *** [out/romlayout16.lds] Error 1


Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:37:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 13:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RulEE-0007Cp-So; Tue, 07 Feb 2012 13:37:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RulED-0007CT-3S
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:37:01 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328621753!60084581!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10070 invoked from network); 7 Feb 2012 13:35:54 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 13:35:54 -0000
Received: by iaeh11 with SMTP id h11so59615843iae.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 05:36:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=bPiVrD5x+IlpNYjgsBq9Sc3aOOuQKEpUhyZNbXkZjzo=;
	b=tvQ9JCyBtUqWEuS87jAETLQ9LxYibNor0GvmzOpJ2mNuDHcf7XTTMjTvNVbv1NhvHC
	mQZTwjGDy4KhWBiwTJt55XW3czvlRm31N+FiVawl/BptDgz/PK8B5VF8O3S2NaONg1jR
	kuVB3xS1C2/KHY96CuCn61dIpMi0xXFYEsxco=
Received: by 10.42.144.2 with SMTP id z2mr21133034icu.18.1328621815348;
	Tue, 07 Feb 2012 05:36:55 -0800 (PST)
Received: from [192.168.1.100] ([125.39.68.38])
	by mx.google.com with ESMTPS id or2sm21110113igc.5.2012.02.07.05.36.52
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:36:54 -0800 (PST)
Message-ID: <4F3128DF.20208@gmail.com>
Date: Tue, 07 Feb 2012 21:36:31 +0800
From: cody <mail.kai.huang@gmail.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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
In-Reply-To: <20120206175812.GB14439@phenom.dumpdata.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
	xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
>    
>> Hi,
>>
>> I see in pcifront_init, if domain is not PV domain, pcifront_init just
>> returns error. So seems HVM domain does not support
>> xen-pcifront/xen-pciback mechanism? If it is true, why? I think
>>      
> Yup. B/c the only thing that the PV PCI protocol does is enable
> PCI configuration emulation. And if you boot an HVM guest - QEMU does
> that already.
>
>    
I heard qemu does not support PCIE simulation, and Xen does not provides 
MMIO mechanism but only legacy IO port mechanism to guest for 
configuration space access. Is this true?

If using IO port mechanism, we can only access first 256B of 
configuration space, but if using PV PCI protocol, we will not have such 
limitation. I think this is an advantage of PCI PV protocol. Of course 
if Xen provides MMIO mechanism to guest for configuration space, it will 
not have this limitation too.

>> technically there's nothing that can block to support pcifront/pciback
>> in HVM, and for performance reason, there will be benefits if HVM
>> supports PV PCI operation.
>>      
> Nope. The PCI operations are just for writting configuration deta in the
> PCI space. Whcih is done mostly when a driver starts/stops and no more.
>
> The performance is with interrupts and how to inject them in a guest - and
> in there the PV is much faster than HVM due to the emulation layer complexity.
> However, work by Stefano on making that path shorter has made the interrupt
> injection much much faster.
>    
I think PV PCI protocol can be used for other purpose in the future, 
such as PF/VF communication. In this case it will be better if HVM 
domain can support PV PCI protocol.

-cody


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 13:37:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 13:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RulEE-0007Cp-So; Tue, 07 Feb 2012 13:37:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RulED-0007CT-3S
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 13:37:01 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328621753!60084581!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10070 invoked from network); 7 Feb 2012 13:35:54 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 13:35:54 -0000
Received: by iaeh11 with SMTP id h11so59615843iae.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 05:36:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=bPiVrD5x+IlpNYjgsBq9Sc3aOOuQKEpUhyZNbXkZjzo=;
	b=tvQ9JCyBtUqWEuS87jAETLQ9LxYibNor0GvmzOpJ2mNuDHcf7XTTMjTvNVbv1NhvHC
	mQZTwjGDy4KhWBiwTJt55XW3czvlRm31N+FiVawl/BptDgz/PK8B5VF8O3S2NaONg1jR
	kuVB3xS1C2/KHY96CuCn61dIpMi0xXFYEsxco=
Received: by 10.42.144.2 with SMTP id z2mr21133034icu.18.1328621815348;
	Tue, 07 Feb 2012 05:36:55 -0800 (PST)
Received: from [192.168.1.100] ([125.39.68.38])
	by mx.google.com with ESMTPS id or2sm21110113igc.5.2012.02.07.05.36.52
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:36:54 -0800 (PST)
Message-ID: <4F3128DF.20208@gmail.com>
Date: Tue, 07 Feb 2012 21:36:31 +0800
From: cody <mail.kai.huang@gmail.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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
In-Reply-To: <20120206175812.GB14439@phenom.dumpdata.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
	xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
>    
>> Hi,
>>
>> I see in pcifront_init, if domain is not PV domain, pcifront_init just
>> returns error. So seems HVM domain does not support
>> xen-pcifront/xen-pciback mechanism? If it is true, why? I think
>>      
> Yup. B/c the only thing that the PV PCI protocol does is enable
> PCI configuration emulation. And if you boot an HVM guest - QEMU does
> that already.
>
>    
I heard qemu does not support PCIE simulation, and Xen does not provides 
MMIO mechanism but only legacy IO port mechanism to guest for 
configuration space access. Is this true?

If using IO port mechanism, we can only access first 256B of 
configuration space, but if using PV PCI protocol, we will not have such 
limitation. I think this is an advantage of PCI PV protocol. Of course 
if Xen provides MMIO mechanism to guest for configuration space, it will 
not have this limitation too.

>> technically there's nothing that can block to support pcifront/pciback
>> in HVM, and for performance reason, there will be benefits if HVM
>> supports PV PCI operation.
>>      
> Nope. The PCI operations are just for writting configuration deta in the
> PCI space. Whcih is done mostly when a driver starts/stops and no more.
>
> The performance is with interrupts and how to inject them in a guest - and
> in there the PV is much faster than HVM due to the emulation layer complexity.
> However, work by Stefano on making that path shorter has made the interrupt
> injection much much faster.
>    
I think PV PCI protocol can be used for other purpose in the future, 
such as PF/VF communication. In this case it will be better if HVM 
domain can support PV PCI protocol.

-cody


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 16:09:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 16: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.xensource.com>)
	id 1Runax-0000QL-Sz; Tue, 07 Feb 2012 16:08:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Runax-0000QG-3p
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 16:08:39 +0000
Received: from [85.158.139.83:22952] by server-12.bemta-5.messagelabs.com id
	5E/EA-30830-68C413F4; Tue, 07 Feb 2012 16:08:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328630916!14052376!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32305 invoked from network); 7 Feb 2012 16:08:37 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Feb 2012 16:08:37 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Runat-0008DB-TB
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:08:35 -0800
Date: Tue, 7 Feb 2012 08:08:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328630915898-5463631.post@n5.nabble.com>
In-Reply-To: <1328538755451-5460198.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I updated xen to changeset 24701:3574f4d67843 and also tried with xl
cd-insert and it failed with this error:

xl cd-insert MINT12PV xvdb raw:/dev/scd0
libxl: error: libxl.c:1579:libxl_cdrom_insert: Virtual device not found

I used wrong parameters or is there a bug?

Thanks for any reply.


--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5463631.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 16:09:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 16: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.xensource.com>)
	id 1Runax-0000QL-Sz; Tue, 07 Feb 2012 16:08:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Runax-0000QG-3p
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 16:08:39 +0000
Received: from [85.158.139.83:22952] by server-12.bemta-5.messagelabs.com id
	5E/EA-30830-68C413F4; Tue, 07 Feb 2012 16:08:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328630916!14052376!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32305 invoked from network); 7 Feb 2012 16:08:37 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Feb 2012 16:08:37 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Runat-0008DB-TB
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 08:08:35 -0800
Date: Tue, 7 Feb 2012 08:08:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328630915898-5463631.post@n5.nabble.com>
In-Reply-To: <1328538755451-5460198.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I updated xen to changeset 24701:3574f4d67843 and also tried with xl
cd-insert and it failed with this error:

xl cd-insert MINT12PV xvdb raw:/dev/scd0
libxl: error: libxl.c:1579:libxl_cdrom_insert: Virtual device not found

I used wrong parameters or is there a bug?

Thanks for any reply.


--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5463631.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 16:11:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 16: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.xensource.com>)
	id 1Rundc-0000Uu-FI; Tue, 07 Feb 2012 16:11:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1Rundb-0000Uo-7p
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 16:11:23 +0000
Received: from [85.158.139.83:41180] by server-12.bemta-5.messagelabs.com id
	0C/13-30830-A2D413F4; Tue, 07 Feb 2012 16:11:22 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328631080!14085023!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22424 invoked from network); 7 Feb 2012 16:11:21 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 16:11:21 -0000
Received: by yenm7 with SMTP id m7so14147744yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 08:11:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=a0VmRw6R3zFnaRy9jCGQ7n2dTgbgfVWrOoXSB/CCLv4=;
	b=sY6NbeuCUHS3ftypcHm5GRjGJxnyhPVT53qJoneNJKNTXfumMjFjt+TfSYFkrSvaWe
	9TNsD39OyZC0Hc3zvB9x14/ObO5h7EVOBclZLdp/Ghgi5ztfaJE8VP36jq2xlC8417l9
	ODg1JSXtp4VcvRjeorNUkdAieG/RJcIJ2oDaY=
Received: by 10.182.216.101 with SMTP id op5mr21482104obc.54.1328631080233;
	Tue, 07 Feb 2012 08:11:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.4.231 with HTTP; Tue, 7 Feb 2012 08:11:00 -0800 (PST)
In-Reply-To: <20120205015657.GA25327@morn.localdomain>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Tue, 7 Feb 2012 16:11:00 +0000
X-Google-Sender-Auth: R6PCnvQxcYpOtz4VFcIsUQuOlN8
Message-ID: <CAKZ=5EVwwodFZS-heLpSjEJiM3mcQ3cvLv2Uej5H-m3sqe8ZGw@mail.gmail.com>
To: "Kevin O'Connor" <kevin@koconnor.net>
Cc: seabios@seabios.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Automatically select 0xe9 as default debug
 port if configured for Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU3VuLCBGZWIgNSwgMjAxMiBhdCAxOjU2IEFNLCBLZXZpbiBPJ0Nvbm5vciA8a2V2aW5Aa29j
b25ub3IubmV0PiB3cm90ZToKPiBPbiBTdW4sIEZlYiAwNSwgMjAxMiBhdCAxMjo0Njo1OEFNICsw
MDAwLCBKdWxpYW4gUGlkYW5jZXQgd3JvdGU6Cj4+IEFzIHBlciBJYW4gY29tbWVudCBvbiBwcmV2
aW91cyBjb21taXQgNzEyM2Q5ODM0ZDU4Mjg3ZDQzNTE0ZDc3OTllZDFhN2IzNGVlYTI0Mwo+Pgo+
PiBTaWduZWQtb2ZmLWJ5OiBKdWxpYW4gUGlkYW5jZXQgPGp1bGlhbi5waWRhbmNldEBnbWFpbC5j
b20+Cj4+IC0tLQo+PiDCoHNyYy9LY29uZmlnIHwgwqAgwqAxICsKPj4gwqAxIGZpbGVzIGNoYW5n
ZWQsIDEgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL3Ny
Yy9LY29uZmlnIGIvc3JjL0tjb25maWcKPj4gaW5kZXggY2YwYmZmMC4uY2VlMDAwNSAxMDA2NDQK
Pj4gLS0tIGEvc3JjL0tjb25maWcKPj4gKysrIGIvc3JjL0tjb25maWcKPj4gQEAgLTM2MSw2ICsz
NjEsNyBAQCBtZW51ICJEZWJ1Z2dpbmciCj4+IMKgIMKgIMKgY29uZmlnIERFQlVHX0lPX1BPUlQK
Pj4gwqAgwqAgwqAgwqAgwqBkZXBlbmRzIG9uIERFQlVHX0lPCj4+IMKgIMKgIMKgIMKgIMKgaGV4
ICJEZWJ1ZyBJTyBwb3J0IGFkZHJlc3MiCj4+ICsgwqAgwqAgwqAgwqBkZWZhdWx0IDB4MDBlOSBp
ZiBYRU4KPj4gwqAgwqAgwqAgwqAgwqBkZWZhdWx0IDB4MDQwMgo+PiDCoCDCoCDCoCDCoCDCoGhl
bHAKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqBCb2NocyB1c2VzIHRoZSAweDA0MDIgYWRkcmVzcyBi
eSBkZWZhdWx0LCB3aGVyZWFzIFhlbgo+Cj4gU2V0dGluZyBvZiBkZWZhdWx0IHZhbHVlcyBkb2Vz
bid0IHdvcmsgd2VsbCB3aGVuIGRvbmUgdGhpcyB3YXkuIMKgVG8KPiB0ZXN0LCBydW4gIm1ha2Ug
bWVudWNvbmZpZyIgc2VsZWN0IGEgYnVpbGQgd2l0aG91dCB4ZW4sIGFuZCBydW4gbWFrZS4KPiBZ
b3UnbGwgc2VlIG91dC9hdXRvY29uZi5oIGhhcyBERUJVR19JT19QT1JUPTB4NDAyLiDCoFRoZW4g
cnVuICJtYWtlCj4gbWVudWNvbmZpZyIgc2VsZWN0IHhlbiwgYW5kIHJ1biBtYWtlLiDCoFlvdSds
bCBzdGlsbCBzZWUKPiBERUJVR19JT19QT1JUPTB4NDAyLgo+Cj4gWW91IGNhbiBsb29rIGF0IFZH
QV9WSUQgaW4gdmdhc3JjL0tjb25maWcgZm9yIG9uZSBwb3NzaWJsZSBzb2x1dGlvbiB0bwo+IHRo
ZSBhYm92ZS4KPgo+IC1LZXZpbgoKSSB0cmllZCB0byB1c2UgdGhlIHNhbWUgdGVjaG5pcXVlIGFz
IHlvdSB1c2VkIGluIHZnYXNyYy9LY29uZmlnOgoKICAgIGNvbmZpZyBERUJVR19JTwogICAgICAg
IGRlcGVuZHMgb24gIUNPUkVCT09UICYmIERFQlVHX0xFVkVMICE9IDAKICAgICAgICBib29sICJT
cGVjaWFsIElPIHBvcnQgZGVidWdnaW5nIgogICAgICAgIGRlZmF1bHQgeQogICAgICAgIGhlbHAK
ICAgICAgICAgICAgU29tZSBlbXVsYXRvcnMgb3IgaHlwZXJ2aXNvcnMgcHJvdmlkZSB3aXRoIGEg
d2F5IHRvIG91dHB1dCBkZWJ1ZwogICAgICAgICAgICBpbmZvcm1hdGlvbiBieSBvdXRwdXRpbmcg
c3RyaW5ncyBpbiBhIHNwZWNpYWwgcG9ydCBwcmVzZW50IGluIHRoZQogICAgICAgICAgICBJTyBz
cGFjZS4KCiAgICBjaG9pY2UKICAgICAgICBkZXBlbmRzIG9uIERFQlVHX0lPCiAgICAgICAgcHJv
bXB0ICJEZWJ1ZyBJTyBwb3J0IGFkZHJlc3MiCiAgICAgICAgZGVmYXVsdCBERUJVR19JT19QT1JU
X1hFTiBpZiBYRU4KICAgICAgICBkZWZhdWx0IERFQlVHX0lPX1BPUlRfQk9DSFMKCiAgICAgICAg
Y29uZmlnIERFQlVHX0lPX1BPUlRfQk9DSFMKICAgICAgICAgICAgYm9vbCAiMHg0MDIgKEJvY2hz
KSIKICAgICAgICBjb25maWcgREVCVUdfSU9fUE9SVF9YRU4KICAgICAgICAgICAgYm9vbCAiMHhl
OSAoWGVuKSIKICAgICAgICBjb25maWcgREVCVUdfSU9fUE9SVF9DVVNUT00KICAgICAgICAgICAg
Ym9vbCAiQ3VzdG9tIgogICAgZW5kY2hvaWNlCgogICAgY29uZmlnIERFQlVHX0lPX1BPUlQKICAg
ICAgICBoZXgKICAgICAgICBwcm9tcHQgIkRlYnVnIElPIHBvcnQgYWRkcmVzcyIgaWYgREVCVUdf
SU9fUE9SVF9DVVNUT00KICAgICAgICBkZWZhdWx0IDB4MDQwMiBpZiBERUJVR19JT19QT1JUX0JP
Q0hTCiAgICAgICAgZGVmYXVsdCAweDAwZTkgaWYgREVCVUdfSU9fUE9SVF9YRU4KICAgICAgICBk
ZWZhdWx0IDB4MDAwMAogICAgICAgIGhlbHAKICAgICAgICAgICAgQm9jaHMgdXNlcyB0aGUgMHgw
NDAyIGFkZHJlc3MgYnkgZGVmYXVsdCwgd2hlcmVhcyBYZW4KICAgICAgICAgICAgbWFrZXMgdGhl
IDB4ZTkgSU8gYWRkcmVzcyBhdmFpbGFibGUgZm9yIGd1ZXN0cyB1c2UuCgoKVW5mb3J0dW5hdGVs
eSwgaXQgc3RpbGwgc2VlbSBzdWJqZWN0IHRvIHRoZSBzYW1lIGlzc3VlLiBJcyB0aGVyZQphbnl0
aGluZyBJIGFtIG1pc3NpbmcgaGVyZSA/CgotLSAKSnVsaWFuCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 07 16:11:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 16: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.xensource.com>)
	id 1Rundc-0000Uu-FI; Tue, 07 Feb 2012 16:11:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1Rundb-0000Uo-7p
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 16:11:23 +0000
Received: from [85.158.139.83:41180] by server-12.bemta-5.messagelabs.com id
	0C/13-30830-A2D413F4; Tue, 07 Feb 2012 16:11:22 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328631080!14085023!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22424 invoked from network); 7 Feb 2012 16:11:21 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 16:11:21 -0000
Received: by yenm7 with SMTP id m7so14147744yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 08:11:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=a0VmRw6R3zFnaRy9jCGQ7n2dTgbgfVWrOoXSB/CCLv4=;
	b=sY6NbeuCUHS3ftypcHm5GRjGJxnyhPVT53qJoneNJKNTXfumMjFjt+TfSYFkrSvaWe
	9TNsD39OyZC0Hc3zvB9x14/ObO5h7EVOBclZLdp/Ghgi5ztfaJE8VP36jq2xlC8417l9
	ODg1JSXtp4VcvRjeorNUkdAieG/RJcIJ2oDaY=
Received: by 10.182.216.101 with SMTP id op5mr21482104obc.54.1328631080233;
	Tue, 07 Feb 2012 08:11:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.4.231 with HTTP; Tue, 7 Feb 2012 08:11:00 -0800 (PST)
In-Reply-To: <20120205015657.GA25327@morn.localdomain>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Tue, 7 Feb 2012 16:11:00 +0000
X-Google-Sender-Auth: R6PCnvQxcYpOtz4VFcIsUQuOlN8
Message-ID: <CAKZ=5EVwwodFZS-heLpSjEJiM3mcQ3cvLv2Uej5H-m3sqe8ZGw@mail.gmail.com>
To: "Kevin O'Connor" <kevin@koconnor.net>
Cc: seabios@seabios.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Automatically select 0xe9 as default debug
 port if configured for Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU3VuLCBGZWIgNSwgMjAxMiBhdCAxOjU2IEFNLCBLZXZpbiBPJ0Nvbm5vciA8a2V2aW5Aa29j
b25ub3IubmV0PiB3cm90ZToKPiBPbiBTdW4sIEZlYiAwNSwgMjAxMiBhdCAxMjo0Njo1OEFNICsw
MDAwLCBKdWxpYW4gUGlkYW5jZXQgd3JvdGU6Cj4+IEFzIHBlciBJYW4gY29tbWVudCBvbiBwcmV2
aW91cyBjb21taXQgNzEyM2Q5ODM0ZDU4Mjg3ZDQzNTE0ZDc3OTllZDFhN2IzNGVlYTI0Mwo+Pgo+
PiBTaWduZWQtb2ZmLWJ5OiBKdWxpYW4gUGlkYW5jZXQgPGp1bGlhbi5waWRhbmNldEBnbWFpbC5j
b20+Cj4+IC0tLQo+PiDCoHNyYy9LY29uZmlnIHwgwqAgwqAxICsKPj4gwqAxIGZpbGVzIGNoYW5n
ZWQsIDEgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL3Ny
Yy9LY29uZmlnIGIvc3JjL0tjb25maWcKPj4gaW5kZXggY2YwYmZmMC4uY2VlMDAwNSAxMDA2NDQK
Pj4gLS0tIGEvc3JjL0tjb25maWcKPj4gKysrIGIvc3JjL0tjb25maWcKPj4gQEAgLTM2MSw2ICsz
NjEsNyBAQCBtZW51ICJEZWJ1Z2dpbmciCj4+IMKgIMKgIMKgY29uZmlnIERFQlVHX0lPX1BPUlQK
Pj4gwqAgwqAgwqAgwqAgwqBkZXBlbmRzIG9uIERFQlVHX0lPCj4+IMKgIMKgIMKgIMKgIMKgaGV4
ICJEZWJ1ZyBJTyBwb3J0IGFkZHJlc3MiCj4+ICsgwqAgwqAgwqAgwqBkZWZhdWx0IDB4MDBlOSBp
ZiBYRU4KPj4gwqAgwqAgwqAgwqAgwqBkZWZhdWx0IDB4MDQwMgo+PiDCoCDCoCDCoCDCoCDCoGhl
bHAKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqBCb2NocyB1c2VzIHRoZSAweDA0MDIgYWRkcmVzcyBi
eSBkZWZhdWx0LCB3aGVyZWFzIFhlbgo+Cj4gU2V0dGluZyBvZiBkZWZhdWx0IHZhbHVlcyBkb2Vz
bid0IHdvcmsgd2VsbCB3aGVuIGRvbmUgdGhpcyB3YXkuIMKgVG8KPiB0ZXN0LCBydW4gIm1ha2Ug
bWVudWNvbmZpZyIgc2VsZWN0IGEgYnVpbGQgd2l0aG91dCB4ZW4sIGFuZCBydW4gbWFrZS4KPiBZ
b3UnbGwgc2VlIG91dC9hdXRvY29uZi5oIGhhcyBERUJVR19JT19QT1JUPTB4NDAyLiDCoFRoZW4g
cnVuICJtYWtlCj4gbWVudWNvbmZpZyIgc2VsZWN0IHhlbiwgYW5kIHJ1biBtYWtlLiDCoFlvdSds
bCBzdGlsbCBzZWUKPiBERUJVR19JT19QT1JUPTB4NDAyLgo+Cj4gWW91IGNhbiBsb29rIGF0IFZH
QV9WSUQgaW4gdmdhc3JjL0tjb25maWcgZm9yIG9uZSBwb3NzaWJsZSBzb2x1dGlvbiB0bwo+IHRo
ZSBhYm92ZS4KPgo+IC1LZXZpbgoKSSB0cmllZCB0byB1c2UgdGhlIHNhbWUgdGVjaG5pcXVlIGFz
IHlvdSB1c2VkIGluIHZnYXNyYy9LY29uZmlnOgoKICAgIGNvbmZpZyBERUJVR19JTwogICAgICAg
IGRlcGVuZHMgb24gIUNPUkVCT09UICYmIERFQlVHX0xFVkVMICE9IDAKICAgICAgICBib29sICJT
cGVjaWFsIElPIHBvcnQgZGVidWdnaW5nIgogICAgICAgIGRlZmF1bHQgeQogICAgICAgIGhlbHAK
ICAgICAgICAgICAgU29tZSBlbXVsYXRvcnMgb3IgaHlwZXJ2aXNvcnMgcHJvdmlkZSB3aXRoIGEg
d2F5IHRvIG91dHB1dCBkZWJ1ZwogICAgICAgICAgICBpbmZvcm1hdGlvbiBieSBvdXRwdXRpbmcg
c3RyaW5ncyBpbiBhIHNwZWNpYWwgcG9ydCBwcmVzZW50IGluIHRoZQogICAgICAgICAgICBJTyBz
cGFjZS4KCiAgICBjaG9pY2UKICAgICAgICBkZXBlbmRzIG9uIERFQlVHX0lPCiAgICAgICAgcHJv
bXB0ICJEZWJ1ZyBJTyBwb3J0IGFkZHJlc3MiCiAgICAgICAgZGVmYXVsdCBERUJVR19JT19QT1JU
X1hFTiBpZiBYRU4KICAgICAgICBkZWZhdWx0IERFQlVHX0lPX1BPUlRfQk9DSFMKCiAgICAgICAg
Y29uZmlnIERFQlVHX0lPX1BPUlRfQk9DSFMKICAgICAgICAgICAgYm9vbCAiMHg0MDIgKEJvY2hz
KSIKICAgICAgICBjb25maWcgREVCVUdfSU9fUE9SVF9YRU4KICAgICAgICAgICAgYm9vbCAiMHhl
OSAoWGVuKSIKICAgICAgICBjb25maWcgREVCVUdfSU9fUE9SVF9DVVNUT00KICAgICAgICAgICAg
Ym9vbCAiQ3VzdG9tIgogICAgZW5kY2hvaWNlCgogICAgY29uZmlnIERFQlVHX0lPX1BPUlQKICAg
ICAgICBoZXgKICAgICAgICBwcm9tcHQgIkRlYnVnIElPIHBvcnQgYWRkcmVzcyIgaWYgREVCVUdf
SU9fUE9SVF9DVVNUT00KICAgICAgICBkZWZhdWx0IDB4MDQwMiBpZiBERUJVR19JT19QT1JUX0JP
Q0hTCiAgICAgICAgZGVmYXVsdCAweDAwZTkgaWYgREVCVUdfSU9fUE9SVF9YRU4KICAgICAgICBk
ZWZhdWx0IDB4MDAwMAogICAgICAgIGhlbHAKICAgICAgICAgICAgQm9jaHMgdXNlcyB0aGUgMHgw
NDAyIGFkZHJlc3MgYnkgZGVmYXVsdCwgd2hlcmVhcyBYZW4KICAgICAgICAgICAgbWFrZXMgdGhl
IDB4ZTkgSU8gYWRkcmVzcyBhdmFpbGFibGUgZm9yIGd1ZXN0cyB1c2UuCgoKVW5mb3J0dW5hdGVs
eSwgaXQgc3RpbGwgc2VlbSBzdWJqZWN0IHRvIHRoZSBzYW1lIGlzc3VlLiBJcyB0aGVyZQphbnl0
aGluZyBJIGFtIG1pc3NpbmcgaGVyZSA/CgotLSAKSnVsaWFuCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 07 16:55:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 16:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuoJo-0000xe-07; Tue, 07 Feb 2012 16:55:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuoJm-0000xZ-2y
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 16:54:58 +0000
Received: from [85.158.139.83:38384] by server-11.bemta-5.messagelabs.com id
	02/30-13907-167513F4; Tue, 07 Feb 2012 16:54:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328633696!14079741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15319 invoked from network); 7 Feb 2012 16:54:57 -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;
	7 Feb 2012 16:54:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="10550930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 16:54:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 16:54:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuoFd-00089y-AU; Tue, 07 Feb 2012 16:50:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuoFd-0000Lb-9R;
	Tue, 07 Feb 2012 16:50:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.22113.279050.476505@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 16:50:41 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
In-Reply-To: <4F2A20FF.90607@ts.fujitsu.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
	<4F2A20FF.90607@ts.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott <segfaultreloaded@gmail.com>,
	Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Juergen Gross writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> On 02/01/2012 03:48 PM, Ian Campbell wrote:
> > xl: Drop -l option to xl cpupool-list
...
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> 
> Acked-by: juergen.gross@ts.fujitsu.com

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 16:55:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 16:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuoJo-0000xe-07; Tue, 07 Feb 2012 16:55:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuoJm-0000xZ-2y
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 16:54:58 +0000
Received: from [85.158.139.83:38384] by server-11.bemta-5.messagelabs.com id
	02/30-13907-167513F4; Tue, 07 Feb 2012 16:54:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328633696!14079741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15319 invoked from network); 7 Feb 2012 16:54:57 -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;
	7 Feb 2012 16:54:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="10550930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 16:54:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 16:54:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuoFd-00089y-AU; Tue, 07 Feb 2012 16:50:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuoFd-0000Lb-9R;
	Tue, 07 Feb 2012 16:50:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.22113.279050.476505@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 16:50:41 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
In-Reply-To: <4F2A20FF.90607@ts.fujitsu.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
	<4F2A20FF.90607@ts.fujitsu.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott <segfaultreloaded@gmail.com>,
	Andre Przywara <andre.przywara@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Juergen Gross writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> On 02/01/2012 03:48 PM, Ian Campbell wrote:
> > xl: Drop -l option to xl cpupool-list
...
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> 
> Acked-by: juergen.gross@ts.fujitsu.com

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:02:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuoQp-00018I-UP; Tue, 07 Feb 2012 17:02:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuoQo-000187-AQ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:02:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328634128!10496901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25056 invoked from network); 7 Feb 2012 17:02:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 17:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="10551101"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:02:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:02:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuoQh-0008Ji-0i; Tue, 07 Feb 2012 17:02:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuoQg-0000W3-W0;
	Tue, 07 Feb 2012 17:02:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.22798.818354.263868@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:02:06 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328116894.17444.99.camel@zakaz.uk.xensource.com>
References: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
	<20265.27561.907043.477902@mariner.uk.xensource.com>
	<1328116894.17444.99.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [GIT PULL] libxl API updates backlog"):
> xl: use json output by default

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:02:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuoQp-00018I-UP; Tue, 07 Feb 2012 17:02:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuoQo-000187-AQ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:02:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328634128!10496901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25056 invoked from network); 7 Feb 2012 17:02:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 17:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="10551101"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:02:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:02:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuoQh-0008Ji-0i; Tue, 07 Feb 2012 17:02:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuoQg-0000W3-W0;
	Tue, 07 Feb 2012 17:02:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.22798.818354.263868@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:02:06 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328116894.17444.99.camel@zakaz.uk.xensource.com>
References: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
	<20265.27561.907043.477902@mariner.uk.xensource.com>
	<1328116894.17444.99.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [GIT PULL] libxl API updates backlog"):
> xl: use json output by default

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:05:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:05:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuoTM-0001EI-G8; Tue, 07 Feb 2012 17:04:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RuoTK-0001Dz-UG
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:04:51 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328634283!12384386!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30963 invoked from network); 7 Feb 2012 17:04:44 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Feb 2012 17:04:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:Content-Type:MIME-Version:Message-ID:To:From:Date;
	bh=yfvqGmW4bu5ZuUegka+kSR1eV3YQqccvWFV4Io50lT8=; 
	b=2Ww2HTdVt7v2o5AI9BrNcloAwkrRDOsJssMg1SbP+pndMg5rFt8xlLT2kPQR/59UXsPH6RkcnM3GhyigEZZb2dzAPev0eiGeM+H86Op2RZ7Ln7diWfMsRyiAmIc+/Noh;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RuoTD-000344-68
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:04:43 +0000
Date: Tue, 7 Feb 2012 17:04:43 +0000
From: Andy Smith <andy@strugglers.net>
To: Xen-devel <Xen-devel@lists.xensource.com>
Message-ID: <20120207170443.GN32046@bitfolk.com>
MIME-Version: 1.0
Content-Disposition: inline
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Tue,
	07 Feb 2012 17:04:43 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	admin.kwak.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I spoke briefly to Ians C and J about this at FOSDEM and they
suggested I send an email about it.

Behaviour through at least Xen 3.3 to 4.0 on domU restart (i.e.,
when root inside domU does "restart" or "shutdown -r") is to restart
the domU without re-reading the domU config file. As a result, domU
will start up again with only the RAM, block devices, network
routes, etc. that it had when it was last started.

A common sequence of events here is:

- User submits support ticket asking for an extra block device, a
  block of IP addresses routed to them, etc.

- We give them that without shutting their domU down, because there
  is no need to shut it down. We tell them, "next time you need to
  reboot, please take care to actually shut it down and boot it
  again instead, otherwise you'll lose what we just gave you."

- Later -- often much later -- when they need to reboot for some
  reason, the above comment has gone completely out of their heads
  and they reboot.

- domU comes back without the disk, route, whatever they got used to
  having, and completely breaks things for them.

- More support tickets and disruption because of a reboot that
  didn't go as they expected.

No amount of documentation or teaching seems to help as this is
unintuitive behaviour compared to what normally happens when an
admin on bare metal does a reboot.

We're actually on the verge of forcing a shut down just to avoid
this misunderstanding, without any technical requirement for one.
Either that or some horrible script that watches logs for domain
startup and then checks they have all the things they are meant to
have.

As far as I am aware I can set on_restart to something other than
"restart" but there is currently no option that makes it re-read the
config file and restart.

I understand this will never be fixed in xend/xm, but would it be
possible to have xl re-read the domU's config when the domU
restarts?

Thanks,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:05:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:05:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuoTM-0001EI-G8; Tue, 07 Feb 2012 17:04:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RuoTK-0001Dz-UG
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:04:51 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328634283!12384386!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30963 invoked from network); 7 Feb 2012 17:04:44 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Feb 2012 17:04:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:Content-Type:MIME-Version:Message-ID:To:From:Date;
	bh=yfvqGmW4bu5ZuUegka+kSR1eV3YQqccvWFV4Io50lT8=; 
	b=2Ww2HTdVt7v2o5AI9BrNcloAwkrRDOsJssMg1SbP+pndMg5rFt8xlLT2kPQR/59UXsPH6RkcnM3GhyigEZZb2dzAPev0eiGeM+H86Op2RZ7Ln7diWfMsRyiAmIc+/Noh;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1RuoTD-000344-68
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:04:43 +0000
Date: Tue, 7 Feb 2012 17:04:43 +0000
From: Andy Smith <andy@strugglers.net>
To: Xen-devel <Xen-devel@lists.xensource.com>
Message-ID: <20120207170443.GN32046@bitfolk.com>
MIME-Version: 1.0
Content-Disposition: inline
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Tue,
	07 Feb 2012 17:04:43 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	admin.kwak.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I spoke briefly to Ians C and J about this at FOSDEM and they
suggested I send an email about it.

Behaviour through at least Xen 3.3 to 4.0 on domU restart (i.e.,
when root inside domU does "restart" or "shutdown -r") is to restart
the domU without re-reading the domU config file. As a result, domU
will start up again with only the RAM, block devices, network
routes, etc. that it had when it was last started.

A common sequence of events here is:

- User submits support ticket asking for an extra block device, a
  block of IP addresses routed to them, etc.

- We give them that without shutting their domU down, because there
  is no need to shut it down. We tell them, "next time you need to
  reboot, please take care to actually shut it down and boot it
  again instead, otherwise you'll lose what we just gave you."

- Later -- often much later -- when they need to reboot for some
  reason, the above comment has gone completely out of their heads
  and they reboot.

- domU comes back without the disk, route, whatever they got used to
  having, and completely breaks things for them.

- More support tickets and disruption because of a reboot that
  didn't go as they expected.

No amount of documentation or teaching seems to help as this is
unintuitive behaviour compared to what normally happens when an
admin on bare metal does a reboot.

We're actually on the verge of forcing a shut down just to avoid
this misunderstanding, without any technical requirement for one.
Either that or some horrible script that watches logs for domain
startup and then checks they have all the things they are meant to
have.

As far as I am aware I can set on_restart to something other than
"restart" but there is currently no option that makes it re-read the
config file and restart.

I understand this will never be fixed in xend/xm, but would it be
possible to have xl re-read the domU's config when the domU
restarts?

Thanks,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:09:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RuoX2-0001Ng-4d; Tue, 07 Feb 2012 17:08:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuoX0-0001NK-G1
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:08:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328634510!9640757!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1OTg3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16316 invoked from network); 7 Feb 2012 17:08:32 -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; 7 Feb 2012 17:08: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 q17H8OdU024970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 17:08:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q17H8M9i018650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 17:08: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
	q17H8LRq008797; Tue, 7 Feb 2012 11:08:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 07 Feb 2012 09:08:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 036CE4045F; Tue,  7 Feb 2012 12:05:36 -0500 (EST)
Date: Tue, 7 Feb 2012 12:05:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120207170535.GC4375@phenom.dumpdata.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
	<4F30EE610200007800071801@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F30EE610200007800071801@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F315A8B.0025,ss=1,re=0.000,fgs=0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 08:26:57AM +0000, Jan Beulich wrote:
> >>> On 06.02.12 at 18:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
> >> # HG changeset patch
> >> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> >> # Date 1328549858 -3600
> >> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> >> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> >> x86/AMD: Add support for AMD's OSVW feature in guests.
> >> 
> >> In some cases guests should not provide workarounds for errata even when the
> >> physical processor is affected. For example, because of erratum 400 on 
> > family
> >> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> >> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> > 
> > What about fixing the Linux guest to actually not do this? I presume you
> > have encountered this with HVM guests - would it be possible to use
> > 
> > set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 
> > 'xen_hvm_guest_init' ??
> 
> Are you saying this would work even with CONFIG_XEN not set
> (which I doubt, but is a valid case to consider)?

Ugh. Not in that case.

> 
> Also, this sort of adjustment is exactly what is being done better
> in the hypervisor, as it'll address the problem at hand for all guests,
> no matter what kernel (version or kind) they run.

Right. I concur that it should also be done in the hypervisor. But earlier
versions of the hypervisor are not getting this patch. So fixing it in
the kernel could cover some issues if one is using Xen 4.0 for example.

Hm, it seems that I actually neglected to say that and made it sound
like it should be either in the hypervisor or in the kernel. I meant both.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:09:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RuoX2-0001Ng-4d; Tue, 07 Feb 2012 17:08:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RuoX0-0001NK-G1
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:08:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328634510!9640757!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1OTg3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16316 invoked from network); 7 Feb 2012 17:08:32 -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; 7 Feb 2012 17:08: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 q17H8OdU024970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 17:08:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q17H8M9i018650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 17:08: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
	q17H8LRq008797; Tue, 7 Feb 2012 11:08:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 07 Feb 2012 09:08:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 036CE4045F; Tue,  7 Feb 2012 12:05:36 -0500 (EST)
Date: Tue, 7 Feb 2012 12:05:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120207170535.GC4375@phenom.dumpdata.com>
References: <3cf8ffd0ab883dd09f94.1328549965@wotan.osrc.amd.com>
	<20120206174745.GA14324@phenom.dumpdata.com>
	<4F30EE610200007800071801@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F30EE610200007800071801@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F315A8B.0025,ss=1,re=0.000,fgs=0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH v5] x86/AMD: Add support for AMD's OSVW
 feature in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 08:26:57AM +0000, Jan Beulich wrote:
> >>> On 06.02.12 at 18:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Mon, Feb 06, 2012 at 06:39:25PM +0100, Boris Ostrovsky wrote:
> >> # HG changeset patch
> >> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> >> # Date 1328549858 -3600
> >> # Node ID 3cf8ffd0ab883dd09f943f4d8fb50f5cc1f04cd5
> >> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> >> x86/AMD: Add support for AMD's OSVW feature in guests.
> >> 
> >> In some cases guests should not provide workarounds for errata even when the
> >> physical processor is affected. For example, because of erratum 400 on 
> > family
> >> 10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
> >> going to idle in order to avoid getting stuck in a non-C0 state. This is not
> > 
> > What about fixing the Linux guest to actually not do this? I presume you
> > have encountered this with HVM guests - would it be possible to use
> > 
> > set_pm_idle_to_default(default_idle) in the HVM bootup path, say in 
> > 'xen_hvm_guest_init' ??
> 
> Are you saying this would work even with CONFIG_XEN not set
> (which I doubt, but is a valid case to consider)?

Ugh. Not in that case.

> 
> Also, this sort of adjustment is exactly what is being done better
> in the hypervisor, as it'll address the problem at hand for all guests,
> no matter what kernel (version or kind) they run.

Right. I concur that it should also be done in the hypervisor. But earlier
versions of the hypervisor are not getting this patch. So fixing it in
the kernel could cover some issues if one is using Xen 4.0 for example.

Hm, it seems that I actually neglected to say that and made it sound
like it should be either in the hypervisor or in the kernel. I meant both.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruog1-0001hC-Ah; Tue, 07 Feb 2012 17:17:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Ruofz-0001h7-OA
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:17:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328635067!13798013!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNzQ5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9435 invoked from network); 7 Feb 2012 17:17:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 17:17:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q17HHjKd030250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 17:17: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
	q17HHgYr029697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 17:17:45 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
	q17HHglh025603; Tue, 7 Feb 2012 11:17:42 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 07 Feb 2012 09:17:42 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B15764045F; Tue,  7 Feb 2012 12:14:56 -0500 (EST)
Date: Tue, 7 Feb 2012 12:14:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: cody <mail.kai.huang@gmail.com>
Message-ID: <20120207171456.GD4375@phenom.dumpdata.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
	<4F3128DF.20208@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3128DF.20208@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020208.4F315CBA.00E4,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
 xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 09:36:31PM +0800, cody wrote:
> On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
> >On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
> >>Hi,
> >>
> >>I see in pcifront_init, if domain is not PV domain, pcifront_init just
> >>returns error. So seems HVM domain does not support
> >>xen-pcifront/xen-pciback mechanism? If it is true, why? I think
> >Yup. B/c the only thing that the PV PCI protocol does is enable
> >PCI configuration emulation. And if you boot an HVM guest - QEMU does
> >that already.
> >
> I heard qemu does not support PCIE simulation, and Xen does not
> provides MMIO mechanism but only legacy IO port mechanism to guest
> for configuration space access. Is this true?

The upstream version has a X58 north bridge implementation to support this.
(ioh3420.c).

In regards to MMIO mechanism are you talking about MSI-X and such? Then
the answer is it does. QEMU traps when a guest tries to write MSI vectors
in the BAR space and translates those to appropiate xen calls to setup
vectors for the guest.

> 
> If using IO port mechanism, we can only access first 256B of
> configuration space, but if using PV PCI protocol, we will not have
> such limitation. I think this is an advantage of PCI PV protocol. Of
> course if Xen provides MMIO mechanism to guest for configuration
> space, it will not have this limitation too.

What do you mean by MMIO mechanism? Setup of MSI-x vectors?
> 
> >>technically there's nothing that can block to support pcifront/pciback
> >>in HVM, and for performance reason, there will be benefits if HVM
> >>supports PV PCI operation.
> >Nope. The PCI operations are just for writting configuration deta in the
> >PCI space. Whcih is done mostly when a driver starts/stops and no more.
> >
> >The performance is with interrupts and how to inject them in a guest - and
> >in there the PV is much faster than HVM due to the emulation layer complexity.
> >However, work by Stefano on making that path shorter has made the interrupt
> >injection much much faster.
> I think PV PCI protocol can be used for other purpose in the future,
> such as PF/VF communication. In this case it will be better if HVM
> domain can support PV PCI protocol.

What is 'PF/VF' communication? Is it just the negoting in the guest of
parameters for the PF to inject in the VF? That seems a huge security risk.

Or is it some other esoteric PCI configuration options that are not 
available in the VF's BARs?

> 
> -cody
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:18:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruog1-0001hC-Ah; Tue, 07 Feb 2012 17:17:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Ruofz-0001h7-OA
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:17:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328635067!13798013!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNzQ5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9435 invoked from network); 7 Feb 2012 17:17:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 17:17:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q17HHjKd030250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 17:17: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
	q17HHgYr029697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 17:17:45 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
	q17HHglh025603; Tue, 7 Feb 2012 11:17:42 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 07 Feb 2012 09:17:42 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B15764045F; Tue,  7 Feb 2012 12:14:56 -0500 (EST)
Date: Tue, 7 Feb 2012 12:14:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: cody <mail.kai.huang@gmail.com>
Message-ID: <20120207171456.GD4375@phenom.dumpdata.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
	<4F3128DF.20208@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3128DF.20208@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020208.4F315CBA.00E4,ss=1,re=0.000,fgs=0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
 xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 09:36:31PM +0800, cody wrote:
> On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
> >On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
> >>Hi,
> >>
> >>I see in pcifront_init, if domain is not PV domain, pcifront_init just
> >>returns error. So seems HVM domain does not support
> >>xen-pcifront/xen-pciback mechanism? If it is true, why? I think
> >Yup. B/c the only thing that the PV PCI protocol does is enable
> >PCI configuration emulation. And if you boot an HVM guest - QEMU does
> >that already.
> >
> I heard qemu does not support PCIE simulation, and Xen does not
> provides MMIO mechanism but only legacy IO port mechanism to guest
> for configuration space access. Is this true?

The upstream version has a X58 north bridge implementation to support this.
(ioh3420.c).

In regards to MMIO mechanism are you talking about MSI-X and such? Then
the answer is it does. QEMU traps when a guest tries to write MSI vectors
in the BAR space and translates those to appropiate xen calls to setup
vectors for the guest.

> 
> If using IO port mechanism, we can only access first 256B of
> configuration space, but if using PV PCI protocol, we will not have
> such limitation. I think this is an advantage of PCI PV protocol. Of
> course if Xen provides MMIO mechanism to guest for configuration
> space, it will not have this limitation too.

What do you mean by MMIO mechanism? Setup of MSI-x vectors?
> 
> >>technically there's nothing that can block to support pcifront/pciback
> >>in HVM, and for performance reason, there will be benefits if HVM
> >>supports PV PCI operation.
> >Nope. The PCI operations are just for writting configuration deta in the
> >PCI space. Whcih is done mostly when a driver starts/stops and no more.
> >
> >The performance is with interrupts and how to inject them in a guest - and
> >in there the PV is much faster than HVM due to the emulation layer complexity.
> >However, work by Stefano on making that path shorter has made the interrupt
> >injection much much faster.
> I think PV PCI protocol can be used for other purpose in the future,
> such as PF/VF communication. In this case it will be better if HVM
> domain can support PV PCI protocol.

What is 'PF/VF' communication? Is it just the negoting in the guest of
parameters for the PF to inject in the VF? That seems a huge security risk.

Or is it some other esoteric PCI configuration options that are not 
available in the VF's BARs?

> 
> -cody
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:22:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruojg-0001pD-8V; Tue, 07 Feb 2012 17:21:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruojf-0001p5-97
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:21:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328635297!12328373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22829 invoked from network); 7 Feb 2012 17:21:37 -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;
	7 Feb 2012 17:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:21:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:21:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuojY-0008Qv-M1; Tue, 07 Feb 2012 17:21:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuojY-0000Ze-L0;
	Tue, 07 Feb 2012 17:21:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.23966.351543.794136@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:21:34 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <67d41a95b5a77b91b16a.1328539209@debian.localdomain>
References: <67d41a95b5a77b91b16a.1328539209@debian.localdomain>
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] pygrub: extlinux parsing correctness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH] pygrub: extlinux parsing correctness"):
> pygrub: extlinux parsing correctness
> 
> The "in" operator should be used instead of the find method, since
> we are only interested in knowing whether the line contains "initrd=",
> but we don't care about it's position. Also fixes an error that
> happens when initrd= it's at the start of the line, since find returns
> 0 and is evaluated as False.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:22:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruojg-0001pD-8V; Tue, 07 Feb 2012 17:21:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruojf-0001p5-97
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:21:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328635297!12328373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22829 invoked from network); 7 Feb 2012 17:21:37 -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;
	7 Feb 2012 17:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:21:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:21:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuojY-0008Qv-M1; Tue, 07 Feb 2012 17:21:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuojY-0000Ze-L0;
	Tue, 07 Feb 2012 17:21:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.23966.351543.794136@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:21:34 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <67d41a95b5a77b91b16a.1328539209@debian.localdomain>
References: <67d41a95b5a77b91b16a.1328539209@debian.localdomain>
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] pygrub: extlinux parsing correctness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH] pygrub: extlinux parsing correctness"):
> pygrub: extlinux parsing correctness
> 
> The "in" operator should be used instead of the find method, since
> we are only interested in knowing whether the line contains "initrd=",
> but we don't care about it's position. Also fixes an error that
> happens when initrd= it's at the start of the line, since find returns
> 0 and is evaluated as False.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:24:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1Ruolh-0001x2-Sn; Tue, 07 Feb 2012 17:23:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruolg-0001wv-1S
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:23:48 +0000
Received: from [85.158.139.83:44886] by server-7.bemta-5.messagelabs.com id
	1B/8E-01252-32E513F4; Tue, 07 Feb 2012 17:23:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328635426!6668203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19948 invoked from network); 7 Feb 2012 17:23:46 -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;
	7 Feb 2012 17:23:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:23:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:23:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruold-0008Rk-Gm; Tue, 07 Feb 2012 17:23:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruold-0000a6-Fn;
	Tue, 07 Feb 2012 17:23:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.24097.477195.904462@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:23:45 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F30134C02000078000716AE@nat28.tlf.novell.com>
References: <4F30134C02000078000716AE@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> How is the supposedly strait clone on xenbits related to the "real" tree?
> It doesn't seem to be tracking it, so I'm sort of confused whether I
> could in fact use the upstream tree in favor of the made up mirror.

AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
but rather one with various other patches needed for Xen.  But Stefano
will be able to comment for sure.

It's certainly not automatically mirrored from anywhere.  It is (now)
updated only by a test push gate from the corresponding staging tree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:24:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1Ruolh-0001x2-Sn; Tue, 07 Feb 2012 17:23:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruolg-0001wv-1S
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:23:48 +0000
Received: from [85.158.139.83:44886] by server-7.bemta-5.messagelabs.com id
	1B/8E-01252-32E513F4; Tue, 07 Feb 2012 17:23:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328635426!6668203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19948 invoked from network); 7 Feb 2012 17:23:46 -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;
	7 Feb 2012 17:23:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:23:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:23:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruold-0008Rk-Gm; Tue, 07 Feb 2012 17:23:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruold-0000a6-Fn;
	Tue, 07 Feb 2012 17:23:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.24097.477195.904462@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:23:45 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F30134C02000078000716AE@nat28.tlf.novell.com>
References: <4F30134C02000078000716AE@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> How is the supposedly strait clone on xenbits related to the "real" tree?
> It doesn't seem to be tracking it, so I'm sort of confused whether I
> could in fact use the upstream tree in favor of the made up mirror.

AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
but rather one with various other patches needed for Xen.  But Stefano
will be able to comment for sure.

It's certainly not automatically mirrored from anywhere.  It is (now)
updated only by a test push gate from the corresponding staging tree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:25:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruomt-00022I-Bx; Tue, 07 Feb 2012 17:25:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruomr-00021Z-B0
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:25:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328635098!12215884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31266 invoked from network); 7 Feb 2012 17:18:18 -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;
	7 Feb 2012 17:18:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="10551430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:18:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:18:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuogL-0008Ps-D7; Tue, 07 Feb 2012 17:18:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuogL-0000Z3-CM;
	Tue, 07 Feb 2012 17:18:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.23769.366753.478651@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:18:17 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <fc90237a814f52a8836b.1328362672@probook.site>
References: <fc90237a814f52a8836b.1328362672@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxl: remove shebang
	from	bash_completion helper
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libxl: remove shebang from bash_completion helper"):
> tools/libxl: remove shebang from bash_completion helper

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:25:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruomt-00022I-Bx; Tue, 07 Feb 2012 17:25:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruomr-00021Z-B0
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:25:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328635098!12215884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31266 invoked from network); 7 Feb 2012 17:18:18 -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;
	7 Feb 2012 17:18:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="10551430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:18:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:18:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuogL-0008Ps-D7; Tue, 07 Feb 2012 17:18:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuogL-0000Z3-CM;
	Tue, 07 Feb 2012 17:18:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.23769.366753.478651@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:18:17 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <fc90237a814f52a8836b.1328362672@probook.site>
References: <fc90237a814f52a8836b.1328362672@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxl: remove shebang
	from	bash_completion helper
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] tools/libxl: remove shebang from bash_completion helper"):
> tools/libxl: remove shebang from bash_completion helper

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:31:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RuosZ-0002Jr-5t; Tue, 07 Feb 2012 17:30:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuosY-0002Jk-Ib
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:30:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328635848!12336262!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29976 invoked from network); 7 Feb 2012 17:30:48 -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;
	7 Feb 2012 17:30:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:30:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:30:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuosS-0008US-4b; Tue, 07 Feb 2012 17:30:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuosS-0000ad-3d;
	Tue, 07 Feb 2012 17:30:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.24520.100024.694018@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:30:48 +0000
To: Andy Smith <andy@strugglers.net>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120207170443.GN32046@bitfolk.com>
References: <20120207170443.GN32046@bitfolk.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andy Smith writes ("[Xen-devel] Re-reading domain configs on domain restart"):
> I understand this will never be fixed in xend/xm, but would it be
> possible to have xl re-read the domU's config when the domU
> restarts?

Yes, this would certainly be possible.  Straightforward, even.
There are two questions we need to answer first:

Firstly, how should this be requested ?  I think a command-line option
to xl would do the trick.

Secondly, should we change the default behaviour ?  I'd be inclined
towards "yes" as the current arrangement is really rather perverse,
but I'm open to opinions.

In the longer term, in the spirit of xl, it might be a good idea to
give the user the option of running a hook script when the domain
dies/reboots/etc.  This would simplify a number of things.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:31:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RuosZ-0002Jr-5t; Tue, 07 Feb 2012 17:30:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RuosY-0002Jk-Ib
	for Xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:30:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328635848!12336262!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29976 invoked from network); 7 Feb 2012 17:30:48 -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;
	7 Feb 2012 17:30:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:30:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:30:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuosS-0008US-4b; Tue, 07 Feb 2012 17:30:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuosS-0000ad-3d;
	Tue, 07 Feb 2012 17:30:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.24520.100024.694018@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:30:48 +0000
To: Andy Smith <andy@strugglers.net>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120207170443.GN32046@bitfolk.com>
References: <20120207170443.GN32046@bitfolk.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andy Smith writes ("[Xen-devel] Re-reading domain configs on domain restart"):
> I understand this will never be fixed in xend/xm, but would it be
> possible to have xl re-read the domU's config when the domU
> restarts?

Yes, this would certainly be possible.  Straightforward, even.
There are two questions we need to answer first:

Firstly, how should this be requested ?  I think a command-line option
to xl would do the trick.

Secondly, should we change the default behaviour ?  I'd be inclined
towards "yes" as the current arrangement is really rather perverse,
but I'm open to opinions.

In the longer term, in the spirit of xl, it might be a good idea to
give the user the option of running a hook script when the domain
dies/reboots/etc.  This would simplify a number of things.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:34:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RuovJ-0002Q8-QC; Tue, 07 Feb 2012 17:33:45 +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 1RuovI-0002Q3-FK
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:33:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328635953!62969152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5400 invoked from network); 7 Feb 2012 17:32: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;
	7 Feb 2012 17:32:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:33:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:33:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuovH-0008Vi-3i; Tue, 07 Feb 2012 17:33:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuovH-0000bE-2G;
	Tue, 07 Feb 2012 17:33:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.24695.56347.32673@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:33:43 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("[Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> +/*
> + * Xen-defined major numbers for virtual block devices.
> + */

Isn't this the same thing as is in
  docs/misc/vbd-interface.txt
only expressed differently ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:34:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RuovJ-0002Q8-QC; Tue, 07 Feb 2012 17:33:45 +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 1RuovI-0002Q3-FK
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:33:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328635953!62969152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5400 invoked from network); 7 Feb 2012 17:32: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;
	7 Feb 2012 17:32:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:33:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:33:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RuovH-0008Vi-3i; Tue, 07 Feb 2012 17:33:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RuovH-0000bE-2G;
	Tue, 07 Feb 2012 17:33:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.24695.56347.32673@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:33:43 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("[Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> +/*
> + * Xen-defined major numbers for virtual block devices.
> + */

Isn't this the same thing as is in
  docs/misc/vbd-interface.txt
only expressed differently ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:51:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:51:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RupCP-0002ob-Es; Tue, 07 Feb 2012 17:51:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RupCN-0002oW-HF
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:51:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328637076!15705236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30363 invoked from network); 7 Feb 2012 17:51:16 -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;
	7 Feb 2012 17:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17: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.213.0; Tue, 7 Feb 2012 17:51:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RupCF-0000Dm-JA; Tue, 07 Feb 2012 17:51:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RupCF-0000bv-I5;
	Tue, 07 Feb 2012 17:51:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.25747.542056.575794@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:51:15 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
>   o Document the XenBus nodes used in this protocol

Awesome.  But I don't think all of these are really supposed to be
part of the guest interface, so you should probably mention which ones
are.

For example,

> + * params
> + *      Values:         string

this is not intended for use by guests and they should not look at it.

> + * virtual-device
> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)

This should be a reference to docs/misc/vbd-interface.txt.  But isn't
this also encoded in the device path in xenstore ?

I'm not qualified to comment on the state machine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:51:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17:51:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RupCP-0002ob-Es; Tue, 07 Feb 2012 17:51:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RupCN-0002oW-HF
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:51:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328637076!15705236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30363 invoked from network); 7 Feb 2012 17:51:16 -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;
	7 Feb 2012 17:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17: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.213.0; Tue, 7 Feb 2012 17:51:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RupCF-0000Dm-JA; Tue, 07 Feb 2012 17:51:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RupCF-0000bv-I5;
	Tue, 07 Feb 2012 17:51:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.25747.542056.575794@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:51:15 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
>   o Document the XenBus nodes used in this protocol

Awesome.  But I don't think all of these are really supposed to be
part of the guest interface, so you should probably mention which ones
are.

For example,

> + * params
> + *      Values:         string

this is not intended for use by guests and they should not look at it.

> + * virtual-device
> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)

This should be a reference to docs/misc/vbd-interface.txt.  But isn't
this also encoded in the device path in xenstore ?

I'm not qualified to comment on the state machine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:59:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RupJc-0002yE-CL; Tue, 07 Feb 2012 17:58:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RupJa-0002y6-2u
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:58:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328637523!9646969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5422 invoked from network); 7 Feb 2012 17:58:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 17:58:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:58:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:58:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RupJT-0000H3-Db; Tue, 07 Feb 2012 17:58:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RupJT-0000cd-CZ;
	Tue, 07 Feb 2012 17:58:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.26195.225152.245536@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:58:43 +0000
To: <xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <osstest-11890-mainreport@xen.org>
References: <osstest-11890-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [qemu-upstream-unstable test] 11890: tolerable FAIL
	-	PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[Xen-devel] [qemu-upstream-unstable test] 11890: tolerable FAIL - PUSHED"):
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail never pass

I added some tests where the qemu version is set to "qemu-xen".  They
currently all fail with this error message:

xl: libxl_dm.c:366: libxl__build_device_model_args_new: Assertion `!"missing code for supplying vnc password to qemu"' failed.

I think this is a pretty important feature so I don't think I should
work around it in my test system.

Adding this so that the tests work is not critical for the general
development of Xen, as pushes will carry on regardless, but to get the
best value out of the push gate (eg, to stop pushes of xen-unstable
which break when used with qemu upstream) it would be nice to fix
this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 17:59:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 17: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.xensource.com>)
	id 1RupJc-0002yE-CL; Tue, 07 Feb 2012 17:58:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RupJa-0002y6-2u
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 17:58:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328637523!9646969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5422 invoked from network); 7 Feb 2012 17:58:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 17:58:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10551993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 17:58:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 17:58:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RupJT-0000H3-Db; Tue, 07 Feb 2012 17:58:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RupJT-0000cd-CZ;
	Tue, 07 Feb 2012 17:58:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.26195.225152.245536@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 17:58:43 +0000
To: <xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <osstest-11890-mainreport@xen.org>
References: <osstest-11890-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [qemu-upstream-unstable test] 11890: tolerable FAIL
	-	PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[Xen-devel] [qemu-upstream-unstable test] 11890: tolerable FAIL - PUSHED"):
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail never pass

I added some tests where the qemu version is set to "qemu-xen".  They
currently all fail with this error message:

xl: libxl_dm.c:366: libxl__build_device_model_args_new: Assertion `!"missing code for supplying vnc password to qemu"' failed.

I think this is a pretty important feature so I don't think I should
work around it in my test system.

Adding this so that the tests work is not critical for the general
development of Xen, as pushes will carry on regardless, but to get the
best value out of the push gate (eg, to stop pushes of xen-unstable
which break when used with qemu upstream) it would be nice to fix
this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:09:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18: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.xensource.com>)
	id 1RupTz-0003C7-HW; Tue, 07 Feb 2012 18:09:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RupTy-0003C2-9S
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:09:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328638168!13328546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27141 invoked from network); 7 Feb 2012 18:09:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 18:09:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18:09:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 18:09:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RupTk-0000LJ-F5; Tue, 07 Feb 2012 18:09:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RupTk-0000dc-Dz;
	Tue, 07 Feb 2012 18:09:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.26832.420390.514554@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:09:20 +0000
To: Andrew Cooper <andrew.cooper3@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F2AB092.7020003@citrix.com>
References: <osstest-11807-mainreport@xen.org>
	<20266.33471.444202.819846@mariner.uk.xensource.com>
	<4F2AB092.7020003@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Wang <wei.wang2@amd.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL"):
> This patch ought to help narrow down the problem.

Thanks.  Keir, does this look reasonable to you ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:09:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18: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.xensource.com>)
	id 1RupTz-0003C7-HW; Tue, 07 Feb 2012 18:09:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RupTy-0003C2-9S
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:09:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328638168!13328546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27141 invoked from network); 7 Feb 2012 18:09:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 18:09:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18:09:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 18:09:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RupTk-0000LJ-F5; Tue, 07 Feb 2012 18:09:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RupTk-0000dc-Dz;
	Tue, 07 Feb 2012 18:09:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.26832.420390.514554@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:09:20 +0000
To: Andrew Cooper <andrew.cooper3@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F2AB092.7020003@citrix.com>
References: <osstest-11807-mainreport@xen.org>
	<20266.33471.444202.819846@mariner.uk.xensource.com>
	<4F2AB092.7020003@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Wang <wei.wang2@amd.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL"):
> This patch ought to help narrow down the problem.

Thanks.  Keir, does this look reasonable to you ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:24:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18: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.xensource.com>)
	id 1Ruphg-0003TL-UB; Tue, 07 Feb 2012 18:23:44 +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 1Ruphf-0003TG-He
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:23:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328638982!51477829!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25348 invoked from network); 7 Feb 2012 18:23:04 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 18:23:04 -0000
Received: by iaeh11 with SMTP id h11so60880412iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 10:23:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=U6bdSn94XYoxch3QbA+pV6jpUd+rOr++/NoJOO0JmbE=;
	b=aW/XN1jfGOVhZkwtz34+tSY+3mb6UEd4+Zv4Y+cD3kyQps/3SgNk45QfQEigwZdQEi
	MJC7+yjgybp28K7JrPrtTywFXjH3pcZ6LX53OAWvdkXbwlUtPhkhCJD9Rhizxq7eZy6c
	QfEMSptDQ2UU2bgv2wUSc6fpGgD1erwdb3wns=
Received: by 10.42.189.135 with SMTP id de7mr22654093icb.54.1328639020609;
	Tue, 07 Feb 2012 10:23:40 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id r18sm34908678ibh.4.2012.02.07.10.23.36
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 10:23:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 10:23:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB56AC1E.2A8F4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
Thread-Index: AczlxZUeo1iyljS8pUa05EXOh3vY/g==
In-Reply-To: <20273.26832.420390.514554@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 11807: regressions
> - FAIL"):
>> This patch ought to help narrow down the problem.
> 
> Thanks.  Keir, does this look reasonable to you ?

Ah, yes it did. Please apply it.

Acked-by: Keir Fraser <keir@xen.org>

> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:24:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18: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.xensource.com>)
	id 1Ruphg-0003TL-UB; Tue, 07 Feb 2012 18:23:44 +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 1Ruphf-0003TG-He
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:23:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328638982!51477829!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25348 invoked from network); 7 Feb 2012 18:23:04 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 18:23:04 -0000
Received: by iaeh11 with SMTP id h11so60880412iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 10:23:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=U6bdSn94XYoxch3QbA+pV6jpUd+rOr++/NoJOO0JmbE=;
	b=aW/XN1jfGOVhZkwtz34+tSY+3mb6UEd4+Zv4Y+cD3kyQps/3SgNk45QfQEigwZdQEi
	MJC7+yjgybp28K7JrPrtTywFXjH3pcZ6LX53OAWvdkXbwlUtPhkhCJD9Rhizxq7eZy6c
	QfEMSptDQ2UU2bgv2wUSc6fpGgD1erwdb3wns=
Received: by 10.42.189.135 with SMTP id de7mr22654093icb.54.1328639020609;
	Tue, 07 Feb 2012 10:23:40 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id r18sm34908678ibh.4.2012.02.07.10.23.36
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 10:23:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 10:23:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB56AC1E.2A8F4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
Thread-Index: AczlxZUeo1iyljS8pUa05EXOh3vY/g==
In-Reply-To: <20273.26832.420390.514554@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 11807: regressions
> - FAIL"):
>> This patch ought to help narrow down the problem.
> 
> Thanks.  Keir, does this look reasonable to you ?

Ah, yes it did. Please apply it.

Acked-by: Keir Fraser <keir@xen.org>

> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:45:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18: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.xensource.com>)
	id 1Ruq1z-0003gX-3E; Tue, 07 Feb 2012 18:44:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruq1x-0003gS-3S
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:44:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328640274!12376699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26352 invoked from network); 7 Feb 2012 18:44: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;
	7 Feb 2012 18:44:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18:44:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 18:44:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruq1p-0000c1-MH; Tue, 07 Feb 2012 18:44:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruq1p-0003iM-LN;
	Tue, 07 Feb 2012 18:44:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.28945.649721.232601@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:44:33 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB56AC1E.2A8F4%keir.xen@gmail.com>
References: <20273.26832.420390.514554@mariner.uk.xensource.com>
	<CB56AC1E.2A8F4%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Wang <wei.wang2@amd.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser writes ("Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL"):
> On 07/02/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > Thanks.  Keir, does this look reasonable to you ?
> 
> Ah, yes it did. Please apply it.
> 
> Acked-by: Keir Fraser <keir@xen.org>

Thanks, done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:45:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18: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.xensource.com>)
	id 1Ruq1z-0003gX-3E; Tue, 07 Feb 2012 18:44:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruq1x-0003gS-3S
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:44:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328640274!12376699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26352 invoked from network); 7 Feb 2012 18:44: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;
	7 Feb 2012 18:44:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18:44:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 18:44:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruq1p-0000c1-MH; Tue, 07 Feb 2012 18:44:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruq1p-0003iM-LN;
	Tue, 07 Feb 2012 18:44:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.28945.649721.232601@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:44:33 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB56AC1E.2A8F4%keir.xen@gmail.com>
References: <20273.26832.420390.514554@mariner.uk.xensource.com>
	<CB56AC1E.2A8F4%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Wang <wei.wang2@amd.com>, Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser writes ("Re: [Xen-devel] [xen-unstable test] 11807: regressions - FAIL"):
> On 07/02/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > Thanks.  Keir, does this look reasonable to you ?
> 
> Ah, yes it did. Please apply it.
> 
> Acked-by: Keir Fraser <keir@xen.org>

Thanks, done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruq4I-0003my-Ki; Tue, 07 Feb 2012 18:47:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruq4H-0003mg-IZ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:47:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328640418!3994740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30794 invoked from network); 7 Feb 2012 18:46:59 -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 Feb 2012 18:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18: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.213.0; Tue, 7 Feb 2012 18:46:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruq4A-0000d1-3p; Tue, 07 Feb 2012 18:46:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruq4A-00044h-2P;
	Tue, 07 Feb 2012 18:46:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.29090.62622.864842@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:46:58 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328112898.17444.96.camel@zakaz.uk.xensource.com>
References: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
	<1328112898.17444.96.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path"):
> On Mon, 2012-01-30 at 19:07 +0000, Santosh Jodh wrote:
> > Replace malloc with alloc in hot paths for improved performance.
> 
> This is a hot path in something like a userspace PV backend which is
> frequently mapping guest domain pages, or something like that?
> 
> > Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruq4I-0003my-Ki; Tue, 07 Feb 2012 18:47:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ruq4H-0003mg-IZ
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:47:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328640418!3994740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30794 invoked from network); 7 Feb 2012 18:46:59 -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 Feb 2012 18:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18: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.213.0; Tue, 7 Feb 2012 18:46:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruq4A-0000d1-3p; Tue, 07 Feb 2012 18:46:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruq4A-00044h-2P;
	Tue, 07 Feb 2012 18:46:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.29090.62622.864842@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:46:58 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328112898.17444.96.camel@zakaz.uk.xensource.com>
References: <4952090d35e0cf5deb86.1327950455@REDBLD-XS.ad.xensource.com>
	<1328112898.17444.96.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] perf: Replace malloc with alloca in hot path"):
> On Mon, 2012-01-30 at 19:07 +0000, Santosh Jodh wrote:
> > Replace malloc with alloc in hot paths for improved performance.
> 
> This is a hot path in something like a userspace PV backend which is
> frequently mapping guest domain pages, or something like that?
> 
> > Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:48:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruq5j-0003tU-4d; Tue, 07 Feb 2012 18:48: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 1Ruq5h-0003tJ-H4
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:48:33 +0000
Received: from [85.158.139.83:58601] by server-10.bemta-5.messagelabs.com id
	C9/06-26909-002713F4; Tue, 07 Feb 2012 18:48:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328640512!14102872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2428 invoked from network); 7 Feb 2012 18:48:32 -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;
	7 Feb 2012 18:48:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552546"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18:48:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 18:48:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruq5f-0000de-Nj; Tue, 07 Feb 2012 18:48:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruq5f-000455-Mo;
	Tue, 07 Feb 2012 18:48:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.29183.676730.626806@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:48:31 +0000
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20273.22113.279050.476505@mariner.uk.xensource.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
	<4F2A20FF.90607@ts.fujitsu.com>
	<20273.22113.279050.476505@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott <segfaultreloaded@gmail.com>,
	Andre Przywara <andre.przywara@amd.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> Juergen Gross writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> > On 02/01/2012 03:48 PM, Ian Campbell wrote:
> > > xl: Drop -l option to xl cpupool-list
> ...
> > > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > 
> > Acked-by: juergen.gross@ts.fujitsu.com
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

For the avoidance of doubt, I have applied this to xen-unstable, not
4.1.  I don't think it will cause anything to go wrong in -unstable
but as a rule we should let patches sit there for a bit before
backporting them.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 18:48:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 18:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruq5j-0003tU-4d; Tue, 07 Feb 2012 18:48: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 1Ruq5h-0003tJ-H4
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 18:48:33 +0000
Received: from [85.158.139.83:58601] by server-10.bemta-5.messagelabs.com id
	C9/06-26909-002713F4; Tue, 07 Feb 2012 18:48:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328640512!14102872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2428 invoked from network); 7 Feb 2012 18:48:32 -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;
	7 Feb 2012 18:48:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="10552546"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 18:48:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 18:48:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ruq5f-0000de-Nj; Tue, 07 Feb 2012 18:48:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ruq5f-000455-Mo;
	Tue, 07 Feb 2012 18:48:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20273.29183.676730.626806@mariner.uk.xensource.com>
Date: Tue, 7 Feb 2012 18:48:31 +0000
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20273.22113.279050.476505@mariner.uk.xensource.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
	<4F2A20FF.90607@ts.fujitsu.com>
	<20273.22113.279050.476505@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott <segfaultreloaded@gmail.com>,
	Andre Przywara <andre.przywara@amd.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> Juergen Gross writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> > On 02/01/2012 03:48 PM, Ian Campbell wrote:
> > > xl: Drop -l option to xl cpupool-list
> ...
> > > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > 
> > Acked-by: juergen.gross@ts.fujitsu.com
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

For the avoidance of doubt, I have applied this to xen-unstable, not
4.1.  I don't think it will cause anything to go wrong in -unstable
but as a rule we should let patches sit there for a bit before
backporting them.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 19:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 19:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuqiT-0004kY-Dg; Tue, 07 Feb 2012 19:28:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RuqiR-0004kM-E1
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 19:28:35 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328642908!4955397!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gMTA2Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3971 invoked from network); 7 Feb 2012 19:28:29 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 19:28:29 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6EF46217BA
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:28:28 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Tue, 07 Feb 2012 14:28:28 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=mesmtp; bh=2Akha3po209Noeo37SYn1PWLhsQ=; b=
	pw4lOhnldeQ4C3HTJKDSI7kYt/DMh+alqbVP5te5+tTwmdsOOHbjOoJWIx2Fwguo
	RFrnU8B5ucFyBgmTao9ZZzg2CKvoblzA5zCyyJQGmi4v/ZCPXHbcdVio/CzHu8iE
	asqS8dZGATFPEY/NTN0W/vgS9RzcsUaXxsEsgVzLLz8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=smtpout; bh=2Akha3po209Noeo37SYn1PWLhsQ
	=; b=CjWyh9qN3tLWaWryWTFWHapubOGf+DI5Vki9Ydruk8YsZKoI3Ev5/f0EdD2
	shLlQZNYaIJiIxX/Jq6JvaPRzRRwG+SdSGXRmJQI7WNwwbxETtki38oMGhY94PJZ
	Aw+PV6GMjxD/din1plVj2To0tPUVKtR9iAsIniRC1eebhSqI=
X-Sasl-enc: wiJn4cKd1kAGus8xANvN7sjx8INlAlm79SUXNAKdzd1X 1328642908
Received: from [10.137.2.12] (afim241.neoplus.adsl.tpnet.pl [95.49.220.241])
	by mail.messagingengine.com (Postfix) with ESMTPSA id E16614824D6
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:28:27 -0500 (EST)
Message-ID: <4F317B58.4010405@invisiblethingslab.com>
Date: Tue, 07 Feb 2012 20:28:24 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.5
Subject: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8365711197090301361=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8365711197090301361==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigB900CCE34C743414951A3351"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB900CCE34C743414951A3351
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is there a convenient way to setup the IP address for the _stubdom_ (to
connect to the vnc server running there) from within the corresponding
HVM config file on Xen 4.1? Or should one use dhcpd?

Thanks,
joanna.

ps. Sorry for posting this to xen-devel, instead of xen-users -- next
time I will subscribe to the latter, I promise ;)


--------------enigB900CCE34C743414951A3351
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPMXtYAAoJEDaIqHeRBUM0SkgIAKzzkQM5EEuYp8Drvj6PCgJk
CJtK8G8M5mFTEufui0ttO7+FCWhwfQlRa9IwnKtLVkpBPOO2zLG2AZQsKyOpZxfv
A8qjAsklj1Rkt/eobokT+S8W+RMDsfUM4GARtd2MYGaatAg++vE34oMjLoDsvJJx
Pian5giblUbm+ilQ7CS9RRfCbEPUFBmqyNWUwR+/O/07JxLqc0Hpy+4rTMhBsA03
3PjSBstXv55uMGEeLvHIlL+mfk4leIRJ9mnZ1pXi/DkcDd3Lo5bpBiuAdOjqykWw
Q4XGyYC1ymsl1xQaJni6U9ODRORWVHOaBi+vvL7aqieSUIQIbd7ZN0OEDYu3ONo=
=5r20
-----END PGP SIGNATURE-----

--------------enigB900CCE34C743414951A3351--


--===============8365711197090301361==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8365711197090301361==--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 19:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 19:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuqiT-0004kY-Dg; Tue, 07 Feb 2012 19:28:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RuqiR-0004kM-E1
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 19:28:35 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328642908!4955397!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gMTA2Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3971 invoked from network); 7 Feb 2012 19:28:29 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 19:28:29 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6EF46217BA
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:28:28 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Tue, 07 Feb 2012 14:28:28 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=mesmtp; bh=2Akha3po209Noeo37SYn1PWLhsQ=; b=
	pw4lOhnldeQ4C3HTJKDSI7kYt/DMh+alqbVP5te5+tTwmdsOOHbjOoJWIx2Fwguo
	RFrnU8B5ucFyBgmTao9ZZzg2CKvoblzA5zCyyJQGmi4v/ZCPXHbcdVio/CzHu8iE
	asqS8dZGATFPEY/NTN0W/vgS9RzcsUaXxsEsgVzLLz8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=smtpout; bh=2Akha3po209Noeo37SYn1PWLhsQ
	=; b=CjWyh9qN3tLWaWryWTFWHapubOGf+DI5Vki9Ydruk8YsZKoI3Ev5/f0EdD2
	shLlQZNYaIJiIxX/Jq6JvaPRzRRwG+SdSGXRmJQI7WNwwbxETtki38oMGhY94PJZ
	Aw+PV6GMjxD/din1plVj2To0tPUVKtR9iAsIniRC1eebhSqI=
X-Sasl-enc: wiJn4cKd1kAGus8xANvN7sjx8INlAlm79SUXNAKdzd1X 1328642908
Received: from [10.137.2.12] (afim241.neoplus.adsl.tpnet.pl [95.49.220.241])
	by mail.messagingengine.com (Postfix) with ESMTPSA id E16614824D6
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:28:27 -0500 (EST)
Message-ID: <4F317B58.4010405@invisiblethingslab.com>
Date: Tue, 07 Feb 2012 20:28:24 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.5
Subject: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8365711197090301361=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8365711197090301361==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigB900CCE34C743414951A3351"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB900CCE34C743414951A3351
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is there a convenient way to setup the IP address for the _stubdom_ (to
connect to the vnc server running there) from within the corresponding
HVM config file on Xen 4.1? Or should one use dhcpd?

Thanks,
joanna.

ps. Sorry for posting this to xen-devel, instead of xen-users -- next
time I will subscribe to the latter, I promise ;)


--------------enigB900CCE34C743414951A3351
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPMXtYAAoJEDaIqHeRBUM0SkgIAKzzkQM5EEuYp8Drvj6PCgJk
CJtK8G8M5mFTEufui0ttO7+FCWhwfQlRa9IwnKtLVkpBPOO2zLG2AZQsKyOpZxfv
A8qjAsklj1Rkt/eobokT+S8W+RMDsfUM4GARtd2MYGaatAg++vE34oMjLoDsvJJx
Pian5giblUbm+ilQ7CS9RRfCbEPUFBmqyNWUwR+/O/07JxLqc0Hpy+4rTMhBsA03
3PjSBstXv55uMGEeLvHIlL+mfk4leIRJ9mnZ1pXi/DkcDd3Lo5bpBiuAdOjqykWw
Q4XGyYC1ymsl1xQaJni6U9ODRORWVHOaBi+vvL7aqieSUIQIbd7ZN0OEDYu3ONo=
=5r20
-----END PGP SIGNATURE-----

--------------enigB900CCE34C743414951A3351--


--===============8365711197090301361==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8365711197090301361==--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 19:55:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 19: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.xensource.com>)
	id 1Rur7j-00054X-Mp; Tue, 07 Feb 2012 19:54: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 1Rur7h-00054S-6O
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 19:54:41 +0000
Received: from [85.158.139.83:36273] by server-4.bemta-5.messagelabs.com id
	B3/A5-28576-081813F4; Tue, 07 Feb 2012 19:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328644479!13259358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17622 invoked from network); 7 Feb 2012 19:54:39 -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;
	7 Feb 2012 19:54:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,379,1325462400"; d="scan'208";a="10553132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 19:54:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 19:54:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rur7e-00013A-VF;
	Tue, 07 Feb 2012 19:54:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rur7e-0007bW-QF;
	Tue, 07 Feb 2012 19:54:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11896-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 7 Feb 2012 19:54:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11896: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11896 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11896/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 11895
 test-i386-i386-win           14 guest-start.2                fail   like 11895

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  eae25241d571
baseline version:
 xen                  3574f4d67843

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony Liguori <aliguori@us.ibm.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Haoyu Zhang <haoyu.zhang@huawei.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liang Wang <hzwangliang.wang@huawei.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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=eae25241d571
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 eae25241d571
+ branch=xen-unstable
+ revision=eae25241d571
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r eae25241d571 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 10 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 19:55:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 19: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.xensource.com>)
	id 1Rur7j-00054X-Mp; Tue, 07 Feb 2012 19:54: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 1Rur7h-00054S-6O
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 19:54:41 +0000
Received: from [85.158.139.83:36273] by server-4.bemta-5.messagelabs.com id
	B3/A5-28576-081813F4; Tue, 07 Feb 2012 19:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328644479!13259358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODAwMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17622 invoked from network); 7 Feb 2012 19:54:39 -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;
	7 Feb 2012 19:54:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,379,1325462400"; d="scan'208";a="10553132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2012 19:54:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 7 Feb 2012 19:54:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rur7e-00013A-VF;
	Tue, 07 Feb 2012 19:54:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rur7e-0007bW-QF;
	Tue, 07 Feb 2012 19:54:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11896-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 7 Feb 2012 19:54:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11896: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11896 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11896/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 11895
 test-i386-i386-win           14 guest-start.2                fail   like 11895

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  eae25241d571
baseline version:
 xen                  3574f4d67843

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anthony Liguori <aliguori@us.ibm.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Haoyu Zhang <haoyu.zhang@huawei.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liang Wang <hzwangliang.wang@huawei.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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=eae25241d571
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 eae25241d571
+ branch=xen-unstable
+ revision=eae25241d571
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r eae25241d571 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 10 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 19:58:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 19:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RurB8-0005Cb-Gz; Tue, 07 Feb 2012 19:58:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RurB7-0005CR-3j
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 19:58:13 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328644685!8227600!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gMTA2Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7523 invoked from network); 7 Feb 2012 19:58:06 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 19:58:06 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BB52621171
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:58:05 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute4.internal (MEProxy); Tue, 07 Feb 2012 14:58:05 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=mesmtp; bh=OOWEC
	bR/iYB58wVL2iWh2UoKvWc=; b=q2o4A0wOdKz82dW3/+cLL7oOfIJks+GX3Z29L
	QDcOsWWWZFF2IAoym/OSAt6EIoo+XAXushZ1OjyMoiM4FIFVosR0tTNvs1nYcJMj
	iy0SRod6B639xoBXhwYcAm6+sqyV380MZRQ59IzNPrZ3gpFIMRK+gd0eP+Em3cZs
	8G3Q4Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=smtpout; bh=OOWE
	CbR/iYB58wVL2iWh2UoKvWc=; b=hQGJlvTZ9eIivctYQsFkSnwGylx1zt3GLkFR
	91YxxJVFg1moWnFwaBOAea+F6QrFyMpTby/LqufXpTe+w4Xosm3bvPjk5ucIjU6c
	f5z3IUVQeQuTrF8u6ivgyHbQxpqZsWj8s0jf7NoYILL72g1AsEK/3Yjz/oPPc3Mo
	ZwWe4SQ=
X-Sasl-enc: ND1Ob7TguCR8Kw29z2UIZys767JJey3ukRHPOeed1ntO 1328644685
Received: from [10.137.2.12] (afim241.neoplus.adsl.tpnet.pl [95.49.220.241])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 40E5048249C
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:58:05 -0500 (EST)
Message-ID: <4F318249.4050509@invisiblethingslab.com>
Date: Tue, 07 Feb 2012 20:58:01 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F317B58.4010405@invisiblethingslab.com>
In-Reply-To: <4F317B58.4010405@invisiblethingslab.com>
X-Enigmail-Version: 1.3.5
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6449250245852917874=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6449250245852917874==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig3E5ED85E5AB4E91C9C7AA0FE"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3E5ED85E5AB4E91C9C7AA0FE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/07/12 20:28, Joanna Rutkowska wrote:
> Is there a convenient way to setup the IP address for the _stubdom_
> (to connect to the vnc server running there) from within the
> corresponding HVM config file on Xen 4.1? Or should one use dhcpd?
>=20
=2E..in which case, wouldn't there be a race between the time lwip
obtains the dhcp packet, and the time when qemu is trying to do bind()
for its vncserver?

joanna.


--------------enig3E5ED85E5AB4E91C9C7AA0FE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPMYJKAAoJEDaIqHeRBUM04UEIAM1ahIchZOo0cPjf6QFFevZS
8+svH6vV/WZ3RjUhlVRjQRcBb7woA25vCcrDOQCGvH+bKZcUxNCHbJ5f/+GXA1ZO
R+/pAHqXMlLbhayr5xN6dIza2ePdGPSimZvdIQTtAnkuBp0yYSY3tyedmu1u4mvf
cWuhF/8NKSc8Nnoa50RMIQWNTAkxJABHiRpm1YtPbXgpHucpMDmHuVOCYv79iuTo
01k3km4igAl8IOPEq7Bl8eaaq83Wie0zs4W6rIFsW0Wc/7bJyJHCkgBtu8ovaIX/
+Wt/S10Ms9Jb/DzWD5+rH1dE/Ia9Z00FR2jo8JoRTVt7yhGMZFmY9Xp8DQLifSA=
=8WdJ
-----END PGP SIGNATURE-----

--------------enig3E5ED85E5AB4E91C9C7AA0FE--


--===============6449250245852917874==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6449250245852917874==--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 19:58:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 19:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RurB8-0005Cb-Gz; Tue, 07 Feb 2012 19:58:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RurB7-0005CR-3j
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 19:58:13 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328644685!8227600!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gMTA2Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7523 invoked from network); 7 Feb 2012 19:58:06 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2012 19:58:06 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BB52621171
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:58:05 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute4.internal (MEProxy); Tue, 07 Feb 2012 14:58:05 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=mesmtp; bh=OOWEC
	bR/iYB58wVL2iWh2UoKvWc=; b=q2o4A0wOdKz82dW3/+cLL7oOfIJks+GX3Z29L
	QDcOsWWWZFF2IAoym/OSAt6EIoo+XAXushZ1OjyMoiM4FIFVosR0tTNvs1nYcJMj
	iy0SRod6B639xoBXhwYcAm6+sqyV380MZRQ59IzNPrZ3gpFIMRK+gd0eP+Em3cZs
	8G3Q4Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:references:in-reply-to:content-type; s=smtpout; bh=OOWE
	CbR/iYB58wVL2iWh2UoKvWc=; b=hQGJlvTZ9eIivctYQsFkSnwGylx1zt3GLkFR
	91YxxJVFg1moWnFwaBOAea+F6QrFyMpTby/LqufXpTe+w4Xosm3bvPjk5ucIjU6c
	f5z3IUVQeQuTrF8u6ivgyHbQxpqZsWj8s0jf7NoYILL72g1AsEK/3Yjz/oPPc3Mo
	ZwWe4SQ=
X-Sasl-enc: ND1Ob7TguCR8Kw29z2UIZys767JJey3ukRHPOeed1ntO 1328644685
Received: from [10.137.2.12] (afim241.neoplus.adsl.tpnet.pl [95.49.220.241])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 40E5048249C
	for <xen-devel@lists.xensource.com>;
	Tue,  7 Feb 2012 14:58:05 -0500 (EST)
Message-ID: <4F318249.4050509@invisiblethingslab.com>
Date: Tue, 07 Feb 2012 20:58:01 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F317B58.4010405@invisiblethingslab.com>
In-Reply-To: <4F317B58.4010405@invisiblethingslab.com>
X-Enigmail-Version: 1.3.5
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6449250245852917874=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6449250245852917874==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig3E5ED85E5AB4E91C9C7AA0FE"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3E5ED85E5AB4E91C9C7AA0FE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/07/12 20:28, Joanna Rutkowska wrote:
> Is there a convenient way to setup the IP address for the _stubdom_
> (to connect to the vnc server running there) from within the
> corresponding HVM config file on Xen 4.1? Or should one use dhcpd?
>=20
=2E..in which case, wouldn't there be a race between the time lwip
obtains the dhcp packet, and the time when qemu is trying to do bind()
for its vncserver?

joanna.


--------------enig3E5ED85E5AB4E91C9C7AA0FE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPMYJKAAoJEDaIqHeRBUM04UEIAM1ahIchZOo0cPjf6QFFevZS
8+svH6vV/WZ3RjUhlVRjQRcBb7woA25vCcrDOQCGvH+bKZcUxNCHbJ5f/+GXA1ZO
R+/pAHqXMlLbhayr5xN6dIza2ePdGPSimZvdIQTtAnkuBp0yYSY3tyedmu1u4mvf
cWuhF/8NKSc8Nnoa50RMIQWNTAkxJABHiRpm1YtPbXgpHucpMDmHuVOCYv79iuTo
01k3km4igAl8IOPEq7Bl8eaaq83Wie0zs4W6rIFsW0Wc/7bJyJHCkgBtu8ovaIX/
+Wt/S10Ms9Jb/DzWD5+rH1dE/Ia9Z00FR2jo8JoRTVt7yhGMZFmY9Xp8DQLifSA=
=8WdJ
-----END PGP SIGNATURE-----

--------------enig3E5ED85E5AB4E91C9C7AA0FE--


--===============6449250245852917874==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6449250245852917874==--


From xen-devel-bounces@lists.xensource.com Tue Feb 07 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RurSF-0005WO-DU; Tue, 07 Feb 2012 20:15:55 +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 1RurSD-0005WJ-KS
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 20:15:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328645704!59179257!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1OTg3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20272 invoked from network); 7 Feb 2012 20:15:06 -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; 7 Feb 2012 20:15:06 -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 q17KFIDo030172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 20:15: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
	q17KFHEY011504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 20:15:18 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
	q17KFGuh029706; Tue, 7 Feb 2012 14:15:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 07 Feb 2012 12:15:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 20D814045F; Tue,  7 Feb 2012 15:12:31 -0500 (EST)
Date: Tue, 7 Feb 2012 15:12:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: george.dunlap@citrix.com, xen-devel@lists.xensource.com
Message-ID: <20120207201231.GA23813@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]
X-CT-RefId: str=0001.0A090207.4F318671.0025,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, andrew.thomas@oracle.com
Subject: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey George,

I was wondering if you could explain in simple terms how the scheduler would
handle per-physical CPU when there are say 16 guests (each guest is using
one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would
the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so
on; or would it be more random? (I assume that both guest and dom0 would do
a hypercall yield too).

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 20:16:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 20:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RurSF-0005WO-DU; Tue, 07 Feb 2012 20:15:55 +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 1RurSD-0005WJ-KS
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 20:15:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328645704!59179257!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1OTg3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20272 invoked from network); 7 Feb 2012 20:15:06 -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; 7 Feb 2012 20:15:06 -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 q17KFIDo030172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 7 Feb 2012 20:15: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
	q17KFHEY011504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2012 20:15:18 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
	q17KFGuh029706; Tue, 7 Feb 2012 14:15:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 07 Feb 2012 12:15:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 20D814045F; Tue,  7 Feb 2012 15:12:31 -0500 (EST)
Date: Tue, 7 Feb 2012 15:12:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: george.dunlap@citrix.com, xen-devel@lists.xensource.com
Message-ID: <20120207201231.GA23813@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]
X-CT-RefId: str=0001.0A090207.4F318671.0025,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, andrew.thomas@oracle.com
Subject: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey George,

I was wondering if you could explain in simple terms how the scheduler would
handle per-physical CPU when there are say 16 guests (each guest is using
one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would
the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so
on; or would it be more random? (I assume that both guest and dom0 would do
a hypercall yield too).

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 21:45:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 21: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.xensource.com>)
	id 1Rusqe-0007rf-C0; Tue, 07 Feb 2012 21:45:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1Rusqd-0007rX-I2
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 21:45:11 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328651103!12410568!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4264 invoked from network); 7 Feb 2012 21:45:05 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 21:45:05 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AQHM4niQ51rPtYUJJEqCxx/dVT5i6pYyc/CA
Date: Tue, 7 Feb 2012 21:45:02 +0000
Message-ID: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
	<4F2BF0750200007800070EB4@nat28.tlf.novell.com>
In-Reply-To: <4F2BF0750200007800070EB4@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <B48FD5394F1A5441973C71593C4BD804@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 6:34 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> xen/include/public/io/blkif.h |  106 ++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 103 insertions(+), 3 deletions(-)
>> 
>> 
>> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>>      Drivers must be updated to, at minimum, use
>>      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>>      with this header file.
> 
> NAK. No backwards incompatible changes allowed in public headers.

Sorry for the slow reply on this.  I've been experimenting with ways to keep legacy
source compatibility.  After trying lots of things, testing the impact on an existing blkfront
and blkback implementation, I think the best two options are:

 1. Version the header file and require consumers to declare the interface version
     they are using.  If the version isn't declared, the default, legacy, "version 1.0" will
     be in effect.

     Positives:   No change in or constant naming conventions.  Data structures and
                         constants for new features are properly hidden from legacy implementations.                 
     Negatives: Messy #ifdefs

 2. Create a new constant BLKIF_MAX_SEGS_PER_REQUEST, have the two other
     new constants (for header and segment block counts) use this convention, and
     leave BLKIF_MAX_SEGMENTS_PER_REQUEST alone (but marked DEPRECATED).

     Positives:   No #ifdefs.  Shorter names for these constants.
     Negatives: Changes the existing constant naming convention for updated
                         drivers.  Leaves BLKIF_MAX_SEGMENTS_PER_REQUEST, a constant
                         that should no longer be used, visible.

Do you have a preference or a suggested alternative?

Thanks,
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 21:45:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 21: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.xensource.com>)
	id 1Rusqe-0007rf-C0; Tue, 07 Feb 2012 21:45:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1Rusqd-0007rX-I2
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 21:45:11 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328651103!12410568!1
X-Originating-IP: [207.225.98.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4264 invoked from network); 7 Feb 2012 21:45:05 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(207.225.98.6)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Feb 2012 21:45:05 -0000
From: Justin Gibbs <justing@spectralogic.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AQHM4niQ51rPtYUJJEqCxx/dVT5i6pYyc/CA
Date: Tue, 7 Feb 2012 21:45:02 +0000
Message-ID: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
	<4F2BF0750200007800070EB4@nat28.tlf.novell.com>
In-Reply-To: <4F2BF0750200007800070EB4@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.254.1]
Content-ID: <B48FD5394F1A5441973C71593C4BD804@spectralogic.com>
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 6:34 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> xen/include/public/io/blkif.h |  106 ++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 103 insertions(+), 3 deletions(-)
>> 
>> 
>> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>>      Drivers must be updated to, at minimum, use
>>      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>>      with this header file.
> 
> NAK. No backwards incompatible changes allowed in public headers.

Sorry for the slow reply on this.  I've been experimenting with ways to keep legacy
source compatibility.  After trying lots of things, testing the impact on an existing blkfront
and blkback implementation, I think the best two options are:

 1. Version the header file and require consumers to declare the interface version
     they are using.  If the version isn't declared, the default, legacy, "version 1.0" will
     be in effect.

     Positives:   No change in or constant naming conventions.  Data structures and
                         constants for new features are properly hidden from legacy implementations.                 
     Negatives: Messy #ifdefs

 2. Create a new constant BLKIF_MAX_SEGS_PER_REQUEST, have the two other
     new constants (for header and segment block counts) use this convention, and
     leave BLKIF_MAX_SEGMENTS_PER_REQUEST alone (but marked DEPRECATED).

     Positives:   No #ifdefs.  Shorter names for these constants.
     Negatives: Changes the existing constant naming convention for updated
                         drivers.  Leaves BLKIF_MAX_SEGMENTS_PER_REQUEST, a constant
                         that should no longer be used, visible.

Do you have a preference or a suggested alternative?

Thanks,
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 21:50:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 21: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.xensource.com>)
	id 1Rusus-0007zu-2W; Tue, 07 Feb 2012 21:49:34 +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 1Rusup-0007zo-Vx
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 21:49:32 +0000
Received: from [85.158.139.83:36338] by server-2.bemta-5.messagelabs.com id
	A5/E7-20725-B6C913F4; Tue, 07 Feb 2012 21:49:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328651369!14059468!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1777 invoked from network); 7 Feb 2012 21:49:30 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 21:49:30 -0000
Received: by iaeh11 with SMTP id h11so61907156iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 13:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=dZg+qot5d7CgSl9vKgsUmKLGulAx0kNtpKxjzDzCyQM=;
	b=XDz58DCWdaa1Gv8z4dtogzT7mJ7lc2BucQq/aHybRl7G6HwNj90JXUJ2S5xctEYcP0
	HB345F/Tk0+1s2UuUESJDqfJ+qPwSHIAO3OfwfBHDKvb3IJqF/pKjool+XOtZ65+2tGD
	njP2TimQUcmLhvDc3+fLE8GUI5W/YBVe72yiM=
Received: by 10.42.150.200 with SMTP id b8mr23755198icw.43.1328651368887;
	Tue, 07 Feb 2012 13:49:28 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id np10sm22054746igc.0.2012.02.07.13.49.25
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 13:49:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 13:49:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Justin Gibbs <justing@spectralogic.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB56DC5E.2A92B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AQHM4niQ51rPtYUJJEqCxx/dVT5i6pYyc/CA//+Lzck=
In-Reply-To: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:

>> NAK. No backwards incompatible changes allowed in public headers.
> 
> Sorry for the slow reply on this.  I've been experimenting with ways to keep
> legacy
> source compatibility.  After trying lots of things, testing the impact on an
> existing blkfront
> and blkback implementation, I think the best two options are:
> 
>  1. Version the header file and require consumers to declare the interface
> version
>      they are using.  If the version isn't declared, the default, legacy,
> "version 1.0" will
>      be in effect.
> 
>      Positives:   No change in or constant naming conventions.  Data
> structures and
>                          constants for new features are properly hidden from
> legacy implementations.
>      Negatives: Messy #ifdefs

We already have this. See use of
__XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
headers.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 07 21:50:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 07 Feb 2012 21: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.xensource.com>)
	id 1Rusus-0007zu-2W; Tue, 07 Feb 2012 21:49:34 +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 1Rusup-0007zo-Vx
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 21:49:32 +0000
Received: from [85.158.139.83:36338] by server-2.bemta-5.messagelabs.com id
	A5/E7-20725-B6C913F4; Tue, 07 Feb 2012 21:49:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328651369!14059468!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1777 invoked from network); 7 Feb 2012 21:49:30 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 21:49:30 -0000
Received: by iaeh11 with SMTP id h11so61907156iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 13:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=dZg+qot5d7CgSl9vKgsUmKLGulAx0kNtpKxjzDzCyQM=;
	b=XDz58DCWdaa1Gv8z4dtogzT7mJ7lc2BucQq/aHybRl7G6HwNj90JXUJ2S5xctEYcP0
	HB345F/Tk0+1s2UuUESJDqfJ+qPwSHIAO3OfwfBHDKvb3IJqF/pKjool+XOtZ65+2tGD
	njP2TimQUcmLhvDc3+fLE8GUI5W/YBVe72yiM=
Received: by 10.42.150.200 with SMTP id b8mr23755198icw.43.1328651368887;
	Tue, 07 Feb 2012 13:49:28 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id np10sm22054746igc.0.2012.02.07.13.49.25
	(version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 13:49:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 07 Feb 2012 13:49:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Justin Gibbs <justing@spectralogic.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB56DC5E.2A92B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AQHM4niQ51rPtYUJJEqCxx/dVT5i6pYyc/CA//+Lzck=
In-Reply-To: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:

>> NAK. No backwards incompatible changes allowed in public headers.
> 
> Sorry for the slow reply on this.  I've been experimenting with ways to keep
> legacy
> source compatibility.  After trying lots of things, testing the impact on an
> existing blkfront
> and blkback implementation, I think the best two options are:
> 
>  1. Version the header file and require consumers to declare the interface
> version
>      they are using.  If the version isn't declared, the default, legacy,
> "version 1.0" will
>      be in effect.
> 
>      Positives:   No change in or constant naming conventions.  Data
> structures and
>                          constants for new features are properly hidden from
> legacy implementations.
>      Negatives: Messy #ifdefs

We already have this. See use of
__XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
headers.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 01:19:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 01:19:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuwAt-000653-Ci; Wed, 08 Feb 2012 01:18:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RuwAs-00064s-IU
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 01:18:18 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328663891!8250739!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5376 invoked from network); 8 Feb 2012 01:18:12 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 01:18:12 -0000
Received: by qabg27 with SMTP id g27so517076qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 17:18:10 -0800 (PST)
Received: by 10.229.77.67 with SMTP id f3mr10420966qck.19.1328663890608;
	Tue, 07 Feb 2012 17:18:10 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id gd3sm968827qab.6.2012.02.07.17.18.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 07 Feb 2012 17:18:09 -0800 (PST)
Date: Tue, 7 Feb 2012 20:18:08 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120208011808.GA9541@morn.localdomain>
References: <4F31288F.5060904@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F31288F.5060904@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 02:35:11PM +0100, Christoph Egger wrote:
> 
> Adding seabios ML.
> 
> On 01/26/12 16:06, Ian Campbell wrote:
> > On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
> >> On 01/26/12 15:51, Ian Campbell wrote:
> >>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
> >>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
> >>>>      Building ld scripts (version "1.6.3.1-20120126_152501")
> >>>> env: python: No such file or directory
> >>>> gmake[6]: *** [out/romlayout16.lds] Error 127
> >>>>
> >>>>
> >>>> The python scripts must be invoked with $(PYTHON) as done
> >>>> throughout the build system.

We can change the seabios makefile to call these scripts with an
explicit $(PYTHON).  However, it's odd that there isn't a default
python on your system.

[...]
> What python version does SeaBIOS require?
> I have python 2.5 installed.

It should work with python 2.5 - there's nothing really special going
on in the script.

> I manually created a python symlink to that version and then I get
> this failure:
> 
> gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
>   Building ld scripts (version "1.6.3.1-20120127_151243")
> Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
> 16bit size:           46336
> 32bit segmented size: 2005
> 32bit flat size:      14699
> 32bit flat init size: 53888
> Traceback (most recent call last):
>   File "./tools/layoutrom.py", line 579, in <module>
>     main()
>   File "./tools/layoutrom.py", line 576, in main
>     writeLinkerScripts(sections, entrysym, genreloc, out16,
> out32seg, out32flag)
>   File "./tools/layoutrom.py", line 257, in writeLinkerScripts
>     + COMMONTRAILER
> TypeError: int argument required

That's quite odd.  This looks data related instead of python related.
Try running a "make clean" and then "make" in just the seabios
directory.  If you still see an issue, tar up the seabios "out/"
directory and mail it to me.

-Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 01:19:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 01:19:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuwAt-000653-Ci; Wed, 08 Feb 2012 01:18:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RuwAs-00064s-IU
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 01:18:18 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328663891!8250739!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5376 invoked from network); 8 Feb 2012 01:18:12 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 01:18:12 -0000
Received: by qabg27 with SMTP id g27so517076qab.9
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 17:18:10 -0800 (PST)
Received: by 10.229.77.67 with SMTP id f3mr10420966qck.19.1328663890608;
	Tue, 07 Feb 2012 17:18:10 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id gd3sm968827qab.6.2012.02.07.17.18.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 07 Feb 2012 17:18:09 -0800 (PST)
Date: Tue, 7 Feb 2012 20:18:08 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120208011808.GA9541@morn.localdomain>
References: <4F31288F.5060904@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F31288F.5060904@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 02:35:11PM +0100, Christoph Egger wrote:
> 
> Adding seabios ML.
> 
> On 01/26/12 16:06, Ian Campbell wrote:
> > On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
> >> On 01/26/12 15:51, Ian Campbell wrote:
> >>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
> >>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
> >>>>      Building ld scripts (version "1.6.3.1-20120126_152501")
> >>>> env: python: No such file or directory
> >>>> gmake[6]: *** [out/romlayout16.lds] Error 127
> >>>>
> >>>>
> >>>> The python scripts must be invoked with $(PYTHON) as done
> >>>> throughout the build system.

We can change the seabios makefile to call these scripts with an
explicit $(PYTHON).  However, it's odd that there isn't a default
python on your system.

[...]
> What python version does SeaBIOS require?
> I have python 2.5 installed.

It should work with python 2.5 - there's nothing really special going
on in the script.

> I manually created a python symlink to that version and then I get
> this failure:
> 
> gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
>   Building ld scripts (version "1.6.3.1-20120127_151243")
> Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
> 16bit size:           46336
> 32bit segmented size: 2005
> 32bit flat size:      14699
> 32bit flat init size: 53888
> Traceback (most recent call last):
>   File "./tools/layoutrom.py", line 579, in <module>
>     main()
>   File "./tools/layoutrom.py", line 576, in main
>     writeLinkerScripts(sections, entrysym, genreloc, out16,
> out32seg, out32flag)
>   File "./tools/layoutrom.py", line 257, in writeLinkerScripts
>     + COMMONTRAILER
> TypeError: int argument required

That's quite odd.  This looks data related instead of python related.
Try running a "make clean" and then "make" in just the seabios
directory.  If you still see an issue, tar up the seabios "out/"
directory and mail it to me.

-Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 01:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 01:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruwi7-0006MO-CM; Wed, 08 Feb 2012 01:52:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <enzinol@gmail.com>) id 1Ruwi5-0006MJ-Jc
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 01:52:37 +0000
Received: from [85.158.139.83:13202] by server-8.bemta-5.messagelabs.com id
	AB/E4-08951-465D13F4; Wed, 08 Feb 2012 01:52:36 +0000
X-Env-Sender: enzinol@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328665956!14075028!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13376 invoked from network); 8 Feb 2012 01:52:36 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 01:52:36 -0000
Received: by wgbdr13 with SMTP id dr13so38600wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 17:52:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=e1//RgRD+iN8TK6byGrW5/w+4sWy5zHXAAdYVmoPwEA=;
	b=IFydTLHzbw1ZVFxg4DNBm8CvtmyTtDL8ZyxaEF6XkhpyrhmogPkYg2/ZVEoem3cuV3
	SsN8T73wH4aq3Cx7oUUnYGYyEWDgXhozCLNcbigl7Zlyjj/XsShC31VvvlJhCUJU3nvj
	z5KzGq7XX/+GCx1KFswvsOSIVRIG4rfG7a0+I=
MIME-Version: 1.0
Received: by 10.180.24.202 with SMTP id w10mr37578482wif.9.1328665469082; Tue,
	07 Feb 2012 17:44:29 -0800 (PST)
Received: by 10.223.45.194 with HTTP; Tue, 7 Feb 2012 17:44:29 -0800 (PST)
Date: Tue, 7 Feb 2012 17:44:29 -0800
Message-ID: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
From: Enzo Lombardi <enzinol@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] applying ATI patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6232792146705501761=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6232792146705501761==
Content-Type: multipart/alternative; boundary=f46d041825984f5df304b86a0939

--f46d041825984f5df304b86a0939
Content-Type: text/plain; charset=ISO-8859-1

Greetings,
I am trying to apply this patch (
http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html
) to
the 4.1.2 release code.
If I download the code from the main page (
http://xen.org/products/xen_source.html ) I see the relevant files but when
I enlist through mercurials the files are not there.
Is the patch referring to deprecated/dead code?
Has anybody successfully applied the same patch in the 4.x branch?
-e

--f46d041825984f5df304b86a0939
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings,<div>I am trying to apply this patch (=A0<a href=3D"http://old-li=
st-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html">http://o=
ld-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html</a>=
=A0)=A0to the 4.1.2 release code.</div>
<div>If I download the code from the main page (=A0<a href=3D"http://xen.or=
g/products/xen_source.html">http://xen.org/products/xen_source.html</a> ) I=
 see the relevant files but when I enlist through mercurials the files are =
not there.</div>
<div>Is the patch referring to deprecated/dead code?</div><div>Has anybody=
=A0successfully=A0applied the same patch in the 4.x branch?</div><div>-e</d=
iv>

--f46d041825984f5df304b86a0939--


--===============6232792146705501761==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6232792146705501761==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 01:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 01:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ruwi7-0006MO-CM; Wed, 08 Feb 2012 01:52:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <enzinol@gmail.com>) id 1Ruwi5-0006MJ-Jc
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 01:52:37 +0000
Received: from [85.158.139.83:13202] by server-8.bemta-5.messagelabs.com id
	AB/E4-08951-465D13F4; Wed, 08 Feb 2012 01:52:36 +0000
X-Env-Sender: enzinol@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328665956!14075028!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13376 invoked from network); 8 Feb 2012 01:52:36 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 01:52:36 -0000
Received: by wgbdr13 with SMTP id dr13so38600wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 17:52:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=e1//RgRD+iN8TK6byGrW5/w+4sWy5zHXAAdYVmoPwEA=;
	b=IFydTLHzbw1ZVFxg4DNBm8CvtmyTtDL8ZyxaEF6XkhpyrhmogPkYg2/ZVEoem3cuV3
	SsN8T73wH4aq3Cx7oUUnYGYyEWDgXhozCLNcbigl7Zlyjj/XsShC31VvvlJhCUJU3nvj
	z5KzGq7XX/+GCx1KFswvsOSIVRIG4rfG7a0+I=
MIME-Version: 1.0
Received: by 10.180.24.202 with SMTP id w10mr37578482wif.9.1328665469082; Tue,
	07 Feb 2012 17:44:29 -0800 (PST)
Received: by 10.223.45.194 with HTTP; Tue, 7 Feb 2012 17:44:29 -0800 (PST)
Date: Tue, 7 Feb 2012 17:44:29 -0800
Message-ID: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
From: Enzo Lombardi <enzinol@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] applying ATI patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6232792146705501761=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6232792146705501761==
Content-Type: multipart/alternative; boundary=f46d041825984f5df304b86a0939

--f46d041825984f5df304b86a0939
Content-Type: text/plain; charset=ISO-8859-1

Greetings,
I am trying to apply this patch (
http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html
) to
the 4.1.2 release code.
If I download the code from the main page (
http://xen.org/products/xen_source.html ) I see the relevant files but when
I enlist through mercurials the files are not there.
Is the patch referring to deprecated/dead code?
Has anybody successfully applied the same patch in the 4.x branch?
-e

--f46d041825984f5df304b86a0939
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings,<div>I am trying to apply this patch (=A0<a href=3D"http://old-li=
st-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html">http://o=
ld-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html</a>=
=A0)=A0to the 4.1.2 release code.</div>
<div>If I download the code from the main page (=A0<a href=3D"http://xen.or=
g/products/xen_source.html">http://xen.org/products/xen_source.html</a> ) I=
 see the relevant files but when I enlist through mercurials the files are =
not there.</div>
<div>Is the patch referring to deprecated/dead code?</div><div>Has anybody=
=A0successfully=A0applied the same patch in the 4.x branch?</div><div>-e</d=
iv>

--f46d041825984f5df304b86a0939--


--===============6232792146705501761==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6232792146705501761==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 04:58:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 04:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuzbA-00089X-J7; Wed, 08 Feb 2012 04:57:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Ruzb8-00089R-Gg
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 04:57:38 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328677051!13373518!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14519 invoked from network); 8 Feb 2012 04:57:31 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 04:57:31 -0000
Received: by lbjn8 with SMTP id n8so149186lbj.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 20:57:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=hE0zURNkwkINI4Ql1Uo8q6w8dp6biF1BFuOOsjg/uAU=;
	b=f8pVjd7PHJa7LEo5UvJi8vOIzz0rv1GGNOe22aiIMn3ogLa3KDVY60CeSMW1qh2ote
	6sB+uJctl7uDWFGNoJI5g1thlymzldnp8cUYnvyZV3ovWu6qyuKn7hqWSUtXvEv3wNfE
	oVXjKTtDVQRT/Sl6TkTgawKSEgZOBnrnAxVQg=
MIME-Version: 1.0
Received: by 10.152.104.143 with SMTP id ge15mr14649030lab.26.1328677051085;
	Tue, 07 Feb 2012 20:57:31 -0800 (PST)
Received: by 10.112.62.173 with HTTP; Tue, 7 Feb 2012 20:57:31 -0800 (PST)
In-Reply-To: <20120207171456.GD4375@phenom.dumpdata.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
	<4F3128DF.20208@gmail.com>
	<20120207171456.GD4375@phenom.dumpdata.com>
Date: Wed, 8 Feb 2012 12:57:31 +0800
Message-ID: <CANqQZNH-wCiZk9D5sKEq0A2BqZehX=iUjUEGQfd+h+MOOp=+XQ@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
	xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 8, 2012 at 1:14 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Feb 07, 2012 at 09:36:31PM +0800, cody wrote:
>> On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
>> >On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
>> >>Hi,
>> >>
>> >>I see in pcifront_init, if domain is not PV domain, pcifront_init just
>> >>returns error. So seems HVM domain does not support
>> >>xen-pcifront/xen-pciback mechanism? If it is true, why? I think
>> >Yup. B/c the only thing that the PV PCI protocol does is enable
>> >PCI configuration emulation. And if you boot an HVM guest - QEMU does
>> >that already.
>> >
>> I heard qemu does not support PCIE simulation, and Xen does not
>> provides MMIO mechanism but only legacy IO port mechanism to guest
>> for configuration space access. Is this true?
>
> The upstream version has a X58 north bridge implementation to support this.
> (ioh3420.c).
>
> In regards to MMIO mechanism are you talking about MSI-X and such? Then
> the answer is it does. QEMU traps when a guest tries to write MSI vectors
> in the BAR space and translates those to appropiate xen calls to setup
> vectors for the guest.

MMIO mechanism means software can access PCI configuration space
through memory space, using normal mov instruction, like normal memory
access. I believe modern PCs all provide this mechanism. Basically
there'll be a physical memory address area reserved for PCI
configuration space, and base address will be reported in ACPI table.
If there's no such information in ACPI table, we need to use legacy IO
port mechanism.

I am not specifically talking about MSI-X. Accessing PCI configuration
space through IO port has limitation that we can only access first
256B of configuration space as it is designed for PCI bus. For PCIE
device, configuration space is extended to 4K, which means we cannot
access configuration space after 256B by using legacy IO port
mechanism. This is why PCIE device requires MMIO mechanism to access
it's configuration space. If PCIE device implements some capabilities,
such as MSI-X capability, after first 256B in it's configuration
space, we will never be able to enable MSI-X by using IO port
mechanism.

I am not familiar Xen and don't know if Xen has provides MMIO
mechanism to guest for PCI configuration space access (To provide it,
I think we need to report base address of configuration space in
guest's ACPI table, and mark pages of configuration space to be
non-accessible, as hypervisor needs to capture guest's configuration
space access).

-cody

>
>>
>> If using IO port mechanism, we can only access first 256B of
>> configuration space, but if using PV PCI protocol, we will not have
>> such limitation. I think this is an advantage of PCI PV protocol. Of
>> course if Xen provides MMIO mechanism to guest for configuration
>> space, it will not have this limitation too.
>
> What do you mean by MMIO mechanism? Setup of MSI-x vectors?

No. See above.

>>
>> >>technically there's nothing that can block to support pcifront/pciback
>> >>in HVM, and for performance reason, there will be benefits if HVM
>> >>supports PV PCI operation.
>> >Nope. The PCI operations are just for writting configuration deta in the
>> >PCI space. Whcih is done mostly when a driver starts/stops and no more.
>> >
>> >The performance is with interrupts and how to inject them in a guest - and
>> >in there the PV is much faster than HVM due to the emulation layer complexity.
>> >However, work by Stefano on making that path shorter has made the interrupt
>> >injection much much faster.
>> I think PV PCI protocol can be used for other purpose in the future,
>> such as PF/VF communication. In this case it will be better if HVM
>> domain can support PV PCI protocol.
>
> What is 'PF/VF' communication? Is it just the negoting in the guest of
> parameters for the PF to inject in the VF? That seems a huge security risk.
>
> Or is it some other esoteric PCI configuration options that are not
> available in the VF's BARs?
>

I think in real SRIOV card, there'll be some cases that VF needs to
get data (register, or memory data) from PF (or send data to) to work
correctly, not just configuration space data. It's highly card
specific and we cannot assume the dependencies between PF/VF for
specific card. I have no experience on specific SRIOV card driver
development, so I can't tell exactly what kinds of communication will
be needed, but it indeed exists -- Intel's SRIOV card has it's own
mailbox protocol for this, though it's communication is implemented in
SRIOV card hardware.

-cody

>>
>> -cody
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 04:58:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 04:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RuzbA-00089X-J7; Wed, 08 Feb 2012 04:57:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1Ruzb8-00089R-Gg
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 04:57:38 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328677051!13373518!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14519 invoked from network); 8 Feb 2012 04:57:31 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 04:57:31 -0000
Received: by lbjn8 with SMTP id n8so149186lbj.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 07 Feb 2012 20:57:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=hE0zURNkwkINI4Ql1Uo8q6w8dp6biF1BFuOOsjg/uAU=;
	b=f8pVjd7PHJa7LEo5UvJi8vOIzz0rv1GGNOe22aiIMn3ogLa3KDVY60CeSMW1qh2ote
	6sB+uJctl7uDWFGNoJI5g1thlymzldnp8cUYnvyZV3ovWu6qyuKn7hqWSUtXvEv3wNfE
	oVXjKTtDVQRT/Sl6TkTgawKSEgZOBnrnAxVQg=
MIME-Version: 1.0
Received: by 10.152.104.143 with SMTP id ge15mr14649030lab.26.1328677051085;
	Tue, 07 Feb 2012 20:57:31 -0800 (PST)
Received: by 10.112.62.173 with HTTP; Tue, 7 Feb 2012 20:57:31 -0800 (PST)
In-Reply-To: <20120207171456.GD4375@phenom.dumpdata.com>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
	<4F3128DF.20208@gmail.com>
	<20120207171456.GD4375@phenom.dumpdata.com>
Date: Wed, 8 Feb 2012 12:57:31 +0800
Message-ID: <CANqQZNH-wCiZk9D5sKEq0A2BqZehX=iUjUEGQfd+h+MOOp=+XQ@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] Does HVM domain support
	xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 8, 2012 at 1:14 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Feb 07, 2012 at 09:36:31PM +0800, cody wrote:
>> On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
>> >On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
>> >>Hi,
>> >>
>> >>I see in pcifront_init, if domain is not PV domain, pcifront_init just
>> >>returns error. So seems HVM domain does not support
>> >>xen-pcifront/xen-pciback mechanism? If it is true, why? I think
>> >Yup. B/c the only thing that the PV PCI protocol does is enable
>> >PCI configuration emulation. And if you boot an HVM guest - QEMU does
>> >that already.
>> >
>> I heard qemu does not support PCIE simulation, and Xen does not
>> provides MMIO mechanism but only legacy IO port mechanism to guest
>> for configuration space access. Is this true?
>
> The upstream version has a X58 north bridge implementation to support this.
> (ioh3420.c).
>
> In regards to MMIO mechanism are you talking about MSI-X and such? Then
> the answer is it does. QEMU traps when a guest tries to write MSI vectors
> in the BAR space and translates those to appropiate xen calls to setup
> vectors for the guest.

MMIO mechanism means software can access PCI configuration space
through memory space, using normal mov instruction, like normal memory
access. I believe modern PCs all provide this mechanism. Basically
there'll be a physical memory address area reserved for PCI
configuration space, and base address will be reported in ACPI table.
If there's no such information in ACPI table, we need to use legacy IO
port mechanism.

I am not specifically talking about MSI-X. Accessing PCI configuration
space through IO port has limitation that we can only access first
256B of configuration space as it is designed for PCI bus. For PCIE
device, configuration space is extended to 4K, which means we cannot
access configuration space after 256B by using legacy IO port
mechanism. This is why PCIE device requires MMIO mechanism to access
it's configuration space. If PCIE device implements some capabilities,
such as MSI-X capability, after first 256B in it's configuration
space, we will never be able to enable MSI-X by using IO port
mechanism.

I am not familiar Xen and don't know if Xen has provides MMIO
mechanism to guest for PCI configuration space access (To provide it,
I think we need to report base address of configuration space in
guest's ACPI table, and mark pages of configuration space to be
non-accessible, as hypervisor needs to capture guest's configuration
space access).

-cody

>
>>
>> If using IO port mechanism, we can only access first 256B of
>> configuration space, but if using PV PCI protocol, we will not have
>> such limitation. I think this is an advantage of PCI PV protocol. Of
>> course if Xen provides MMIO mechanism to guest for configuration
>> space, it will not have this limitation too.
>
> What do you mean by MMIO mechanism? Setup of MSI-x vectors?

No. See above.

>>
>> >>technically there's nothing that can block to support pcifront/pciback
>> >>in HVM, and for performance reason, there will be benefits if HVM
>> >>supports PV PCI operation.
>> >Nope. The PCI operations are just for writting configuration deta in the
>> >PCI space. Whcih is done mostly when a driver starts/stops and no more.
>> >
>> >The performance is with interrupts and how to inject them in a guest - and
>> >in there the PV is much faster than HVM due to the emulation layer complexity.
>> >However, work by Stefano on making that path shorter has made the interrupt
>> >injection much much faster.
>> I think PV PCI protocol can be used for other purpose in the future,
>> such as PF/VF communication. In this case it will be better if HVM
>> domain can support PV PCI protocol.
>
> What is 'PF/VF' communication? Is it just the negoting in the guest of
> parameters for the PF to inject in the VF? That seems a huge security risk.
>
> Or is it some other esoteric PCI configuration options that are not
> available in the VF's BARs?
>

I think in real SRIOV card, there'll be some cases that VF needs to
get data (register, or memory data) from PF (or send data to) to work
correctly, not just configuration space data. It's highly card
specific and we cannot assume the dependencies between PF/VF for
specific card. I have no experience on specific SRIOV card driver
development, so I can't tell exactly what kinds of communication will
be needed, but it indeed exists -- Intel's SRIOV card has it's own
mailbox protocol for this, though it's communication is implemented in
SRIOV card hardware.

-cody

>>
>> -cody
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:00:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv1VE-0000R2-CK; Wed, 08 Feb 2012 06:59:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rv1VC-0000Qx-8h
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 06:59:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328684371!12274749!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDM4MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3233 invoked from network); 8 Feb 2012 06:59:31 -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; 8 Feb 2012 06:59:31 -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 EDA441324;
	Wed,  8 Feb 2012 08:59:30 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id AD4AC20058; Wed,  8 Feb 2012 08:59:30 +0200 (EET)
Date: Wed, 8 Feb 2012 08:59:30 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Nathanael Rensen <nathanael@polymorpheus.com>
Message-ID: <20120208065930.GT12984@reaktio.net>
References: <20110103114133.GI2754@reaktio.net>
	<1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] pvusb drivers for pvops 2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> Hi Pasi,
> =


Hello,

(I added Konrad and xen-devel to CC list, hopefully that's ok..)

> It's been a very long time since we discussed PVUSB - I haven't given
> up, just been caught up with other things.
> =


Great! Really nice to hear from you again..

Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
extracted the xen patches, and started preparing to re-port the driver to p=
vops.
So now I don't have to finish that :)

> I've updated the PVUSB patch, done some refactoring and cleaned up the
> checkpatch warnings.
> The patch is targetted at linux-next, but it also applies cleanly to
> Konrad's linux-next branch:
> =

> http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.patch
> =

> I haven't done a lot of testing, but it does work for my basic test
> (USB TV-tuner). My next step is to get in contact with the USB
> maintainer and see what further changes are required in order to get
> this work upstreamed. In the meantime, the more testing and exposure
> the patch gets the better.
> =


I'm sure we can get people testing this patch. Many people have been asking
for USB passthru solution for Linux 3.x.


> Thanks,
> =


Thanks a lot!


-- Pasi

> Nathanael
> =

> On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> >>
> >> > I also noticed the frontend driver was producing a warning when
> >> > loading which is resolved by setting the module owner.
> >> >
> >> > I've placed an updated diff here:
> >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> >> >
> >>
> >> Great, thanks.
> >>
> >
> > Hello again,
> >
> > Nathanael: Did you have time to take a look at upstreaming xen pvusb dr=
ivers ?
> >
> > -- Pasi
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:00:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv1VE-0000R2-CK; Wed, 08 Feb 2012 06:59:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rv1VC-0000Qx-8h
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 06:59:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328684371!12274749!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDM4MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3233 invoked from network); 8 Feb 2012 06:59:31 -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; 8 Feb 2012 06:59:31 -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 EDA441324;
	Wed,  8 Feb 2012 08:59:30 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id AD4AC20058; Wed,  8 Feb 2012 08:59:30 +0200 (EET)
Date: Wed, 8 Feb 2012 08:59:30 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Nathanael Rensen <nathanael@polymorpheus.com>
Message-ID: <20120208065930.GT12984@reaktio.net>
References: <20110103114133.GI2754@reaktio.net>
	<1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] pvusb drivers for pvops 2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> Hi Pasi,
> =


Hello,

(I added Konrad and xen-devel to CC list, hopefully that's ok..)

> It's been a very long time since we discussed PVUSB - I haven't given
> up, just been caught up with other things.
> =


Great! Really nice to hear from you again..

Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
extracted the xen patches, and started preparing to re-port the driver to p=
vops.
So now I don't have to finish that :)

> I've updated the PVUSB patch, done some refactoring and cleaned up the
> checkpatch warnings.
> The patch is targetted at linux-next, but it also applies cleanly to
> Konrad's linux-next branch:
> =

> http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.patch
> =

> I haven't done a lot of testing, but it does work for my basic test
> (USB TV-tuner). My next step is to get in contact with the USB
> maintainer and see what further changes are required in order to get
> this work upstreamed. In the meantime, the more testing and exposure
> the patch gets the better.
> =


I'm sure we can get people testing this patch. Many people have been asking
for USB passthru solution for Linux 3.x.


> Thanks,
> =


Thanks a lot!


-- Pasi

> Nathanael
> =

> On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> >>
> >> > I also noticed the frontend driver was producing a warning when
> >> > loading which is resolved by setting the module owner.
> >> >
> >> > I've placed an updated diff here:
> >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> >> >
> >>
> >> Great, thanks.
> >>
> >
> > Hello again,
> >
> > Nathanael: Did you have time to take a look at upstreaming xen pvusb dr=
ivers ?
> >
> > -- Pasi
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:12:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv1gq-0000lW-EZ; Wed, 08 Feb 2012 07:11:40 +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 1Rv1go-0000lR-Qz
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:11:38 +0000
Received: from [85.158.139.83:36444] by server-7.bemta-5.messagelabs.com id
	3D/19-01252-920223F4; Wed, 08 Feb 2012 07:11:37 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328685096!14145123!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDM4MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2966 invoked from network); 8 Feb 2012 07:11:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:11: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 8BEA72C26;
	Wed,  8 Feb 2012 09:11:35 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6802320058; Wed,  8 Feb 2012 09:11:35 +0200 (EET)
Date: Wed, 8 Feb 2012 09:11:35 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Enzo Lombardi <enzinol@gmail.com>
Message-ID: <20120208071135.GU12984@reaktio.net>
References: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] applying ATI patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 05:44:29PM -0800, Enzo Lombardi wrote:
>    Greetings,
>    I am trying to apply this patch
>    ( [1]http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html ) to
>    the 4.1.2 release code.
>    If I download the code from the main page
>    ( [2]http://xen.org/products/xen_source.html ) I see the relevant files
>    but when I enlist through mercurials the files are not there.
>    Is the patch referring to deprecated/dead code?
>    Has anybody successfully applied the same patch in the 4.x branch?

If you're talking about qemu-dm files, you first need to build the source once,
so the qemu-xen tree gets fetched (and built) from internet.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:12:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv1gq-0000lW-EZ; Wed, 08 Feb 2012 07:11:40 +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 1Rv1go-0000lR-Qz
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:11:38 +0000
Received: from [85.158.139.83:36444] by server-7.bemta-5.messagelabs.com id
	3D/19-01252-920223F4; Wed, 08 Feb 2012 07:11:37 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328685096!14145123!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDM4MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2966 invoked from network); 8 Feb 2012 07:11:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:11: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 8BEA72C26;
	Wed,  8 Feb 2012 09:11:35 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6802320058; Wed,  8 Feb 2012 09:11:35 +0200 (EET)
Date: Wed, 8 Feb 2012 09:11:35 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Enzo Lombardi <enzinol@gmail.com>
Message-ID: <20120208071135.GU12984@reaktio.net>
References: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] applying ATI patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 05:44:29PM -0800, Enzo Lombardi wrote:
>    Greetings,
>    I am trying to apply this patch
>    ( [1]http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html ) to
>    the 4.1.2 release code.
>    If I download the code from the main page
>    ( [2]http://xen.org/products/xen_source.html ) I see the relevant files
>    but when I enlist through mercurials the files are not there.
>    Is the patch referring to deprecated/dead code?
>    Has anybody successfully applied the same patch in the 4.x branch?

If you're talking about qemu-dm files, you first need to build the source once,
so the qemu-xen tree gets fetched (and built) from internet.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:41:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:41:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv29D-0001Fk-Ut; Wed, 08 Feb 2012 07:41:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rv29B-0001Fd-Fr
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:40:57 +0000
Received: from [85.158.139.83:46853] by server-9.bemta-5.messagelabs.com id
	30/C1-23757-807223F4; Wed, 08 Feb 2012 07:40:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328686855!6730549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8923 invoked from network); 8 Feb 2012 07:40:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 07:40:55 +0000
Message-Id: <4F3235150200007800071A95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 07:40:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part27095715.1__="
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Ping: [PATCH] qemu-dm: fix unregister_iomem()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part27095715.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). It's unclear how the function can ever have
fulfilled its purpose: the value returned by iomem_index() is *not* an
index into mmio[].

Additionally, fix two problems:
- unregister_iomem() must not clear mmio[].start, otherwise
  cpu_register_physical_memory() won't be able to re-use the previous
  slot, thus causing a leak
- cpu_unregister_io_memory() must not check mmio[].size, otherwise it
  won't properly clean up entries (temporarily) squashed through
  unregister_iomem()

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>

--- a/i386-dm/exec-dm.c
+++ b/i386-dm/exec-dm.c
@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab
     int io_index =3D io_table_address >> IO_MEM_SHIFT;
=20
     for (i =3D 0; i < mmio_cnt; i++) {
-	if (mmio[i].size && mmio[i].io_index =3D=3D io_index) {
+	if (mmio[i].io_index =3D=3D io_index) {
 	   mmio[i].start =3D mmio[i].size =3D 0;
 	   break;
 	}
@@ -466,12 +466,16 @@ static int iomem_index(target_phys_addr_
=20
 void unregister_iomem(target_phys_addr_t start)
 {
-    int index =3D iomem_index(start);
-    if (index) {
+    unsigned int index;
+
+    for (index =3D 0; index < mmio_cnt; index++)
+        if (start =3D=3D mmio[index].start)
+            break;
+    if (index < mmio_cnt) {
         fprintf(logfile, "squash iomem [%lx, %lx).\n",
 		(unsigned long)(mmio[index].start),
                 (unsigned long)(mmio[index].start + mmio[index].size));
-        mmio[index].start =3D mmio[index].size =3D 0;
+        mmio[index].size =3D 0;
     }
 }
=20




--=__Part27095715.1__=
Content-Type: text/plain; name="qemu-MSI-X-fix-unregister_iomem.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-fix-unregister_iomem.patch"

qemu-dm: fix unregister_iomem()=0A=0AThis function (introduced quite a =
long time ago in=0Ae7911109f4321e9ba0cc56a253b653600aa46bea - "disable =
qemu PCI=0Adevices in HVM domains") appears to be completely broken, =
causing=0Athe regression reported in=0Ahttp://bugzilla.xensource.com/bugzil=
la/show_bug.cgi?id=3D1805 (due to=0Athe newly added caller of it in=0A56d77=
47a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up=0AMSI-X table =
handling"). It's unclear how the function can ever have=0Afulfilled its =
purpose: the value returned by iomem_index() is *not* an=0Aindex into =
mmio[].=0A=0AAdditionally, fix two problems:=0A- unregister_iomem() must =
not clear mmio[].start, otherwise=0A  cpu_register_physical_memory() won't =
be able to re-use the previous=0A  slot, thus causing a leak=0A- cpu_unregi=
ster_io_memory() must not check mmio[].size, otherwise it=0A  won't =
properly clean up entries (temporarily) squashed through=0A  unregister_iom=
em()=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: =
Stefano Stabellini <stefano.stabellini@eu.citrix.com>=0ATested-by: Yongjie =
Ren <yongjie.ren@intel.com>=0A=0A--- a/i386-dm/exec-dm.c=0A+++ b/i386-dm/ex=
ec-dm.c=0A@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab=0A  =
   int io_index =3D io_table_address >> IO_MEM_SHIFT;=0A =0A     for (i =
=3D 0; i < mmio_cnt; i++) {=0A-	if (mmio[i].size && mmio[i].io_index =
=3D=3D io_index) {=0A+	if (mmio[i].io_index =3D=3D io_index) {=0A 	   =
mmio[i].start =3D mmio[i].size =3D 0;=0A 	   break;=0A 	}=0A@@ =
-466,12 +466,16 @@ static int iomem_index(target_phys_addr_=0A =0A void =
unregister_iomem(target_phys_addr_t start)=0A {=0A-    int index =3D =
iomem_index(start);=0A-    if (index) {=0A+    unsigned int index;=0A+=0A+ =
   for (index =3D 0; index < mmio_cnt; index++)=0A+        if (start =
=3D=3D mmio[index].start)=0A+            break;=0A+    if (index < =
mmio_cnt) {=0A         fprintf(logfile, "squash iomem [%lx, %lx).\n",=0A 	=
	(unsigned long)(mmio[index].start),=0A                 (unsigned =
long)(mmio[index].start + mmio[index].size));=0A-        mmio[index].start =
=3D mmio[index].size =3D 0;=0A+        mmio[index].size =3D 0;=0A     }=0A =
}=0A =0A
--=__Part27095715.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part27095715.1__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:41:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:41:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv29D-0001Fk-Ut; Wed, 08 Feb 2012 07:41:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rv29B-0001Fd-Fr
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:40:57 +0000
Received: from [85.158.139.83:46853] by server-9.bemta-5.messagelabs.com id
	30/C1-23757-807223F4; Wed, 08 Feb 2012 07:40:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328686855!6730549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8923 invoked from network); 8 Feb 2012 07:40:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 07:40:55 +0000
Message-Id: <4F3235150200007800071A95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 07:40:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part27095715.1__="
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Ping: [PATCH] qemu-dm: fix unregister_iomem()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part27095715.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). It's unclear how the function can ever have
fulfilled its purpose: the value returned by iomem_index() is *not* an
index into mmio[].

Additionally, fix two problems:
- unregister_iomem() must not clear mmio[].start, otherwise
  cpu_register_physical_memory() won't be able to re-use the previous
  slot, thus causing a leak
- cpu_unregister_io_memory() must not check mmio[].size, otherwise it
  won't properly clean up entries (temporarily) squashed through
  unregister_iomem()

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Yongjie Ren <yongjie.ren@intel.com>

--- a/i386-dm/exec-dm.c
+++ b/i386-dm/exec-dm.c
@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab
     int io_index =3D io_table_address >> IO_MEM_SHIFT;
=20
     for (i =3D 0; i < mmio_cnt; i++) {
-	if (mmio[i].size && mmio[i].io_index =3D=3D io_index) {
+	if (mmio[i].io_index =3D=3D io_index) {
 	   mmio[i].start =3D mmio[i].size =3D 0;
 	   break;
 	}
@@ -466,12 +466,16 @@ static int iomem_index(target_phys_addr_
=20
 void unregister_iomem(target_phys_addr_t start)
 {
-    int index =3D iomem_index(start);
-    if (index) {
+    unsigned int index;
+
+    for (index =3D 0; index < mmio_cnt; index++)
+        if (start =3D=3D mmio[index].start)
+            break;
+    if (index < mmio_cnt) {
         fprintf(logfile, "squash iomem [%lx, %lx).\n",
 		(unsigned long)(mmio[index].start),
                 (unsigned long)(mmio[index].start + mmio[index].size));
-        mmio[index].start =3D mmio[index].size =3D 0;
+        mmio[index].size =3D 0;
     }
 }
=20




--=__Part27095715.1__=
Content-Type: text/plain; name="qemu-MSI-X-fix-unregister_iomem.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-fix-unregister_iomem.patch"

qemu-dm: fix unregister_iomem()=0A=0AThis function (introduced quite a =
long time ago in=0Ae7911109f4321e9ba0cc56a253b653600aa46bea - "disable =
qemu PCI=0Adevices in HVM domains") appears to be completely broken, =
causing=0Athe regression reported in=0Ahttp://bugzilla.xensource.com/bugzil=
la/show_bug.cgi?id=3D1805 (due to=0Athe newly added caller of it in=0A56d77=
47a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up=0AMSI-X table =
handling"). It's unclear how the function can ever have=0Afulfilled its =
purpose: the value returned by iomem_index() is *not* an=0Aindex into =
mmio[].=0A=0AAdditionally, fix two problems:=0A- unregister_iomem() must =
not clear mmio[].start, otherwise=0A  cpu_register_physical_memory() won't =
be able to re-use the previous=0A  slot, thus causing a leak=0A- cpu_unregi=
ster_io_memory() must not check mmio[].size, otherwise it=0A  won't =
properly clean up entries (temporarily) squashed through=0A  unregister_iom=
em()=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: =
Stefano Stabellini <stefano.stabellini@eu.citrix.com>=0ATested-by: Yongjie =
Ren <yongjie.ren@intel.com>=0A=0A--- a/i386-dm/exec-dm.c=0A+++ b/i386-dm/ex=
ec-dm.c=0A@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab=0A  =
   int io_index =3D io_table_address >> IO_MEM_SHIFT;=0A =0A     for (i =
=3D 0; i < mmio_cnt; i++) {=0A-	if (mmio[i].size && mmio[i].io_index =
=3D=3D io_index) {=0A+	if (mmio[i].io_index =3D=3D io_index) {=0A 	   =
mmio[i].start =3D mmio[i].size =3D 0;=0A 	   break;=0A 	}=0A@@ =
-466,12 +466,16 @@ static int iomem_index(target_phys_addr_=0A =0A void =
unregister_iomem(target_phys_addr_t start)=0A {=0A-    int index =3D =
iomem_index(start);=0A-    if (index) {=0A+    unsigned int index;=0A+=0A+ =
   for (index =3D 0; index < mmio_cnt; index++)=0A+        if (start =
=3D=3D mmio[index].start)=0A+            break;=0A+    if (index < =
mmio_cnt) {=0A         fprintf(logfile, "squash iomem [%lx, %lx).\n",=0A 	=
	(unsigned long)(mmio[index].start),=0A                 (unsigned =
long)(mmio[index].start + mmio[index].size));=0A-        mmio[index].start =
=3D mmio[index].size =3D 0;=0A+        mmio[index].size =3D 0;=0A     }=0A =
}=0A =0A
--=__Part27095715.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part27095715.1__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:48:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv2GD-0001TT-BN; Wed, 08 Feb 2012 07:48: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 1Rv2GB-0001TK-MN
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:48:11 +0000
Received: from [85.158.139.83:33291] by server-12.bemta-5.messagelabs.com id
	AF/07-30830-AB8223F4; Wed, 08 Feb 2012 07:48:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328687289!14100023!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15915 invoked from network); 8 Feb 2012 07:48:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:48:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 07:48:10 +0000
Message-Id: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 07:48:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
In-Reply-To: <CB56DC5E.2A92B%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
> 
>>> NAK. No backwards incompatible changes allowed in public headers.
>> 
>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>> legacy
>> source compatibility.  After trying lots of things, testing the impact on an
>> existing blkfront
>> and blkback implementation, I think the best two options are:
>> 
>>  1. Version the header file and require consumers to declare the interface
>> version
>>      they are using.  If the version isn't declared, the default, legacy,
>> "version 1.0" will
>>      be in effect.
>> 
>>      Positives:   No change in or constant naming conventions.  Data
>> structures and
>>                          constants for new features are properly hidden from
>> legacy implementations.
>>      Negatives: Messy #ifdefs
> 
> We already have this. See use of
> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
> headers.

Hmm, I would think these should specifically not be used in the
io/ subtree - those aren't definitions of the interface to Xen, but
ones shared between the respective backends and frontends.
Each interface is (apart from its relying on the ring definitions)
entirely self contained.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:48:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv2GD-0001TT-BN; Wed, 08 Feb 2012 07:48: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 1Rv2GB-0001TK-MN
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:48:11 +0000
Received: from [85.158.139.83:33291] by server-12.bemta-5.messagelabs.com id
	AF/07-30830-AB8223F4; Wed, 08 Feb 2012 07:48:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328687289!14100023!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15915 invoked from network); 8 Feb 2012 07:48:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:48:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 07:48:10 +0000
Message-Id: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 07:48:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
In-Reply-To: <CB56DC5E.2A92B%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
> 
>>> NAK. No backwards incompatible changes allowed in public headers.
>> 
>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>> legacy
>> source compatibility.  After trying lots of things, testing the impact on an
>> existing blkfront
>> and blkback implementation, I think the best two options are:
>> 
>>  1. Version the header file and require consumers to declare the interface
>> version
>>      they are using.  If the version isn't declared, the default, legacy,
>> "version 1.0" will
>>      be in effect.
>> 
>>      Positives:   No change in or constant naming conventions.  Data
>> structures and
>>                          constants for new features are properly hidden from
>> legacy implementations.
>>      Negatives: Messy #ifdefs
> 
> We already have this. See use of
> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
> headers.

Hmm, I would think these should specifically not be used in the
io/ subtree - those aren't definitions of the interface to Xen, but
ones shared between the respective backends and frontends.
Each interface is (apart from its relying on the ring definitions)
entirely self contained.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:50:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07: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.xensource.com>)
	id 1Rv2Hn-0001Xg-Uo; Wed, 08 Feb 2012 07:49: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 1Rv2Hl-0001XW-Rm
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:49:50 +0000
Received: from [85.158.139.83:50303] by server-12.bemta-5.messagelabs.com id
	BA/B9-30830-D19223F4; Wed, 08 Feb 2012 07:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328687388!6731494!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29289 invoked from network); 8 Feb 2012 07:49:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:49:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 07:49:48 +0000
Message-Id: <4F32372B0200007800071AA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 07:49:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
	<4F2BF0750200007800070EB4@nat28.tlf.novell.com>
	<7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
In-Reply-To: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 22:45, Justin Gibbs <justing@spectralogic.com> wrote:
> On Feb 3, 2012, at 6:34 AM, Jan Beulich wrote:
> 
>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>> xen/include/public/io/blkif.h |  106 
> ++++++++++++++++++++++++++++++++++++++++-
>>> 1 files changed, 103 insertions(+), 3 deletions(-)
>>> 
>>> 
>>> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>>>      Drivers must be updated to, at minimum, use
>>>      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>>>      with this header file.
>> 
>> NAK. No backwards incompatible changes allowed in public headers.
> 
> Sorry for the slow reply on this.  I've been experimenting with ways to keep 
> legacy
> source compatibility.  After trying lots of things, testing the impact on an 
> existing blkfront
> and blkback implementation, I think the best two options are:
> 
>  1. Version the header file and require consumers to declare the interface 
> version
>      they are using.  If the version isn't declared, the default, legacy, 
> "version 1.0" will
>      be in effect.
> 
>      Positives:   No change in or constant naming conventions.  Data 
> structures and
>                          constants for new features are properly hidden from 
> legacy implementations.                 
>      Negatives: Messy #ifdefs
> 
>  2. Create a new constant BLKIF_MAX_SEGS_PER_REQUEST, have the two other
>      new constants (for header and segment block counts) use this 
> convention, and
>      leave BLKIF_MAX_SEGMENTS_PER_REQUEST alone (but marked DEPRECATED).
> 
>      Positives:   No #ifdefs.  Shorter names for these constants.
>      Negatives: Changes the existing constant naming convention for updated
>                          drivers.  Leaves BLKIF_MAX_SEGMENTS_PER_REQUEST, a 
> constant
>                          that should no longer be used, visible.
> 
> Do you have a preference or a suggested alternative?

I would personally prefer 2.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 07:50:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 07: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.xensource.com>)
	id 1Rv2Hn-0001Xg-Uo; Wed, 08 Feb 2012 07:49: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 1Rv2Hl-0001XW-Rm
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:49:50 +0000
Received: from [85.158.139.83:50303] by server-12.bemta-5.messagelabs.com id
	BA/B9-30830-D19223F4; Wed, 08 Feb 2012 07:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328687388!6731494!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29289 invoked from network); 8 Feb 2012 07:49:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 07:49:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 07:49:48 +0000
Message-Id: <4F32372B0200007800071AA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 07:49:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<f5c2e866c661d5000fb2.1328246663@ns1.eng.sldomain.com>
	<4F2BF0750200007800070EB4@nat28.tlf.novell.com>
	<7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
In-Reply-To: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 22:45, Justin Gibbs <justing@spectralogic.com> wrote:
> On Feb 3, 2012, at 6:34 AM, Jan Beulich wrote:
> 
>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>> xen/include/public/io/blkif.h |  106 
> ++++++++++++++++++++++++++++++++++++++++-
>>> 1 files changed, 103 insertions(+), 3 deletions(-)
>>> 
>>> 
>>> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>>>      Drivers must be updated to, at minimum, use
>>>      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>>>      with this header file.
>> 
>> NAK. No backwards incompatible changes allowed in public headers.
> 
> Sorry for the slow reply on this.  I've been experimenting with ways to keep 
> legacy
> source compatibility.  After trying lots of things, testing the impact on an 
> existing blkfront
> and blkback implementation, I think the best two options are:
> 
>  1. Version the header file and require consumers to declare the interface 
> version
>      they are using.  If the version isn't declared, the default, legacy, 
> "version 1.0" will
>      be in effect.
> 
>      Positives:   No change in or constant naming conventions.  Data 
> structures and
>                          constants for new features are properly hidden from 
> legacy implementations.                 
>      Negatives: Messy #ifdefs
> 
>  2. Create a new constant BLKIF_MAX_SEGS_PER_REQUEST, have the two other
>      new constants (for header and segment block counts) use this 
> convention, and
>      leave BLKIF_MAX_SEGMENTS_PER_REQUEST alone (but marked DEPRECATED).
> 
>      Positives:   No #ifdefs.  Shorter names for these constants.
>      Negatives: Changes the existing constant naming convention for updated
>                          drivers.  Leaves BLKIF_MAX_SEGMENTS_PER_REQUEST, a 
> constant
>                          that should no longer be used, visible.
> 
> Do you have a preference or a suggested alternative?

I would personally prefer 2.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 09:27:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 09:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv3nw-0002zh-0b; Wed, 08 Feb 2012 09:27:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RuQbp-00042o-GQ
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:36:01 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328540765!12049949!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25714 invoked from network); 6 Feb 2012 15:06:06 -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; 6 Feb 2012 15:06:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16F63v6005389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:06: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
	q16F62qn014441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:06:03 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
	q16F61hC028604
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 09:06:01 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 07:06:01 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3b98813bea086f1892af8af1cc2acbae725ec2b9
Message-Id: <3b98813bea086f1892af.1328540813@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 06 Feb 2012 10:06:53 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F2FEC5C.005A,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 08 Feb 2012 09:27:07 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328540799 18000
# Node ID 3b98813bea086f1892af8af1cc2acbae725ec2b9
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
libxl: fix bootloader args setting

When bootloader_args = ['foo', 'bar'], then info->u.pv.bootloader_args =

    foo\0
    bar\0
    \0

Before this patch, 'p++' points to the next character of 'foo\0' and never
comes to 'bar\0' (because of the '\0' in 'foo\0'), so the args will be:

    args[0] = 'oo\0'
    args[1] = 'o\0'

After this patch, 'p++' points to the next string of pv.bootloader_args, so we
get the correct args:

    args[0] = 'foo\0'
    args[1] = 'bar\0'

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 09:27:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 09:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv3nw-0002zh-0b; Wed, 08 Feb 2012 09:27:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RuQbp-00042o-GQ
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:36:01 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1328540765!12049949!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzNDA2NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25714 invoked from network); 6 Feb 2012 15:06:06 -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; 6 Feb 2012 15:06:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q16F63v6005389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:06: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
	q16F62qn014441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:06:03 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
	q16F61hC028604
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 09:06:01 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 07:06:01 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3b98813bea086f1892af8af1cc2acbae725ec2b9
Message-Id: <3b98813bea086f1892af.1328540813@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 06 Feb 2012 10:06:53 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F2FEC5C.005A,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 08 Feb 2012 09:27:07 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] libxl: fix bootloader args setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328540799 18000
# Node ID 3b98813bea086f1892af8af1cc2acbae725ec2b9
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
libxl: fix bootloader args setting

When bootloader_args = ['foo', 'bar'], then info->u.pv.bootloader_args =

    foo\0
    bar\0
    \0

Before this patch, 'p++' points to the next character of 'foo\0' and never
comes to 'bar\0' (because of the '\0' in 'foo\0'), so the args will be:

    args[0] = 'oo\0'
    args[1] = 'o\0'

After this patch, 'p++' points to the next string of pv.bootloader_args, so we
get the correct args:

    args[0] = 'foo\0'
    args[1] = 'bar\0'

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 09:27:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 09: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.xensource.com>)
	id 1Rv3nv-0002za-LM; Wed, 08 Feb 2012 09:27:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RuQFn-0003pC-4H
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:13:15 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328541187!13692918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMyNDUy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1337 invoked from network); 6 Feb 2012 15:13:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 15:13:08 -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 q16FD4cP024151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:13:06 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
	q16FD3DQ012734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:13:04 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
	q16FD3Ok016851
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 09:13:03 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 07:13:03 -0800
MIME-Version: 1.0
X-Mercurial-Node: 72f1296a55a470426e1c3e5b8b2ba907ab6eb78c
Message-Id: <72f1296a55a470426e1c.1328541247@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 06 Feb 2012 10:14:07 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F2FEE02.0056,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 08 Feb 2012 09:27:07 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] [PATCH] libxl: fix bootloader args setting
	[with diff]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328541193 18000
# Node ID 72f1296a55a470426e1c3e5b8b2ba907ab6eb78c
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
libxl: fix bootloader args setting

When bootloader_args = ['foo', 'bar'], then info->u.pv.bootloader_args =

    foo\0
    bar\0
    \0

Before this patch, 'p++' points to the next character of 'foo\0' and never
comes to 'bar\0' (because of the '\0' in 'foo\0'), so the args will be:

    args[0] = 'oo\0'
    args[1] = 'o\0'

After this patch, 'p++' points to the next string of pv.bootloader_args, so we
get the correct args:

    args[0] = 'foo\0'
    args[1] = 'bar\0'

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 3432abcf9380 -r 72f1296a55a4 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 02 15:47:26 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Mon Feb 06 10:13:13 2012 -0500
@@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *p = info->u.pv.bootloader_args[0];
-        while (*(p++))
-            flexarray_set(args, nr++, p);
+        char **p = info->u.pv.bootloader_args;
+        while (*p) {
+            flexarray_set(args, nr++, *p);
+            p++;
+        }
     }
 
     flexarray_set(args, nr++, disk);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 09:27:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 09: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.xensource.com>)
	id 1Rv3nv-0002za-LM; Wed, 08 Feb 2012 09:27:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RuQFn-0003pC-4H
	for xen-devel@lists.xensource.com; Mon, 06 Feb 2012 15:13:15 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328541187!13692918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMyNDUy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1337 invoked from network); 6 Feb 2012 15:13:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2012 15:13:08 -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 q16FD4cP024151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:13:06 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
	q16FD3DQ012734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 15:13:04 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
	q16FD3Ok016851
	for <xen-devel@lists.xensource.com>; Mon, 6 Feb 2012 09:13:03 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 06 Feb 2012 07:13:03 -0800
MIME-Version: 1.0
X-Mercurial-Node: 72f1296a55a470426e1c3e5b8b2ba907ab6eb78c
Message-Id: <72f1296a55a470426e1c.1328541247@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 06 Feb 2012 10:14:07 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F2FEE02.0056,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 08 Feb 2012 09:27:07 +0000
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] [PATCH] libxl: fix bootloader args setting
	[with diff]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1328541193 18000
# Node ID 72f1296a55a470426e1c3e5b8b2ba907ab6eb78c
# Parent  3432abcf9380d3840ca38439a304f74a37d155fc
libxl: fix bootloader args setting

When bootloader_args = ['foo', 'bar'], then info->u.pv.bootloader_args =

    foo\0
    bar\0
    \0

Before this patch, 'p++' points to the next character of 'foo\0' and never
comes to 'bar\0' (because of the '\0' in 'foo\0'), so the args will be:

    args[0] = 'oo\0'
    args[1] = 'o\0'

After this patch, 'p++' points to the next string of pv.bootloader_args, so we
get the correct args:

    args[0] = 'foo\0'
    args[1] = 'bar\0'

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 3432abcf9380 -r 72f1296a55a4 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 02 15:47:26 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Mon Feb 06 10:13:13 2012 -0500
@@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *p = info->u.pv.bootloader_args[0];
-        while (*(p++))
-            flexarray_set(args, nr++, p);
+        char **p = info->u.pv.bootloader_args;
+        while (*p) {
+            flexarray_set(args, nr++, *p);
+            p++;
+        }
     }
 
     flexarray_set(args, nr++, disk);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 10:33:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 10: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.xensource.com>)
	id 1Rv4p4-0003vR-TP; Wed, 08 Feb 2012 10:32:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Rv4p3-0003vM-GA
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 10:32:21 +0000
Received: from [193.109.254.147:36599] by server-2.bemta-14.messagelabs.com id
	01/C8-05163-43F423F4; Wed, 08 Feb 2012 10:32:20 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328697089!51867324!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4497 invoked from network); 8 Feb 2012 10:31:29 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE004.bigfish.com) (213.199.154.207)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Feb 2012 10:31:29 -0000
Received: from mail65-am1-R.bigfish.com (10.3.201.228) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 8 Feb 2012 10:32:18 +0000
Received: from mail65-am1 (localhost [127.0.0.1])	by mail65-am1-R.bigfish.com
	(Postfix) with ESMTP id EF4DE2C01FD;
	Wed,  8 Feb 2012 10:32:17 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI936eK98bK1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1
	(MessageSwitch) id 1328697136401650_30921;
	Wed,  8 Feb 2012 10:32:16 +0000 (UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.239])	by
	mail65-am1.bigfish.com (Postfix) with ESMTP id 5431F240048;
	Wed,  8 Feb 2012 10:32:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id
	14.1.225.23; Wed, 8 Feb 2012 10:32:15 +0000
X-WSS-ID: 0LZ2L9P-02-7G7-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 22008C8121;	Wed,  8 Feb 2012 04:32:13 -0600 (CST)
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;
	Wed, 8 Feb 2012 04:32:25 -0600
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.289.1;
	Wed, 8 Feb 2012 04:32:14 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	05:32:12 -0500
Message-ID: <4F324F2A.9000308@amd.com>
Date: Wed, 8 Feb 2012 11:32:10 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Kevin O'Connor <kevin@koconnor.net>
References: <4F31288F.5060904@amd.com> <20120208011808.GA9541@morn.localdomain>
In-Reply-To: <20120208011808.GA9541@morn.localdomain>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/08/12 02:18, Kevin O'Connor wrote:
> On Tue, Feb 07, 2012 at 02:35:11PM +0100, Christoph Egger wrote:
>>
>> Adding seabios ML.
>>
>> On 01/26/12 16:06, Ian Campbell wrote:
>>> On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
>>>> On 01/26/12 15:51, Ian Campbell wrote:
>>>>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
>>>>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>>>>>>       Building ld scripts (version "1.6.3.1-20120126_152501")
>>>>>> env: python: No such file or directory
>>>>>> gmake[6]: *** [out/romlayout16.lds] Error 127
>>>>>>
>>>>>>
>>>>>> The python scripts must be invoked with $(PYTHON) as done
>>>>>> throughout the build system.
>
> We can change the seabios makefile to call these scripts with an
> explicit $(PYTHON).

Awesome!

> However, it's odd that there isn't a default python on your system.
>
> [...]
>> What python version does SeaBIOS require?
>> I have python 2.5 installed.
>
> It should work with python 2.5 - there's nothing really special going
> on in the script.
>
>> I manually created a python symlink to that version and then I get
>> this failure:
>>
>> gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
>>    Building ld scripts (version "1.6.3.1-20120127_151243")
>> Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
>> 16bit size:           46336
>> 32bit segmented size: 2005
>> 32bit flat size:      14699
>> 32bit flat init size: 53888
>> Traceback (most recent call last):
>>    File "./tools/layoutrom.py", line 579, in<module>
>>      main()
>>    File "./tools/layoutrom.py", line 576, in main
>>      writeLinkerScripts(sections, entrysym, genreloc, out16,
>> out32seg, out32flag)
>>    File "./tools/layoutrom.py", line 257, in writeLinkerScripts
>>      + COMMONTRAILER
>> TypeError: int argument required
>
> That's quite odd.  This looks data related instead of python related.
> Try running a "make clean" and then "make" in just the seabios
> directory.  If you still see an issue, tar up the seabios "out/"
> directory and mail it to me.

It failed the same way.
I sent you the tarball offlist due its size.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 10:33:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 10: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.xensource.com>)
	id 1Rv4p4-0003vR-TP; Wed, 08 Feb 2012 10:32:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Rv4p3-0003vM-GA
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 10:32:21 +0000
Received: from [193.109.254.147:36599] by server-2.bemta-14.messagelabs.com id
	01/C8-05163-43F423F4; Wed, 08 Feb 2012 10:32:20 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328697089!51867324!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4497 invoked from network); 8 Feb 2012 10:31:29 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE004.bigfish.com) (213.199.154.207)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Feb 2012 10:31:29 -0000
Received: from mail65-am1-R.bigfish.com (10.3.201.228) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 8 Feb 2012 10:32:18 +0000
Received: from mail65-am1 (localhost [127.0.0.1])	by mail65-am1-R.bigfish.com
	(Postfix) with ESMTP id EF4DE2C01FD;
	Wed,  8 Feb 2012 10:32:17 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI936eK98bK1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1
	(MessageSwitch) id 1328697136401650_30921;
	Wed,  8 Feb 2012 10:32:16 +0000 (UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.239])	by
	mail65-am1.bigfish.com (Postfix) with ESMTP id 5431F240048;
	Wed,  8 Feb 2012 10:32:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id
	14.1.225.23; Wed, 8 Feb 2012 10:32:15 +0000
X-WSS-ID: 0LZ2L9P-02-7G7-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 22008C8121;	Wed,  8 Feb 2012 04:32:13 -0600 (CST)
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;
	Wed, 8 Feb 2012 04:32:25 -0600
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.289.1;
	Wed, 8 Feb 2012 04:32:14 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	05:32:12 -0500
Message-ID: <4F324F2A.9000308@amd.com>
Date: Wed, 8 Feb 2012 11:32:10 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Kevin O'Connor <kevin@koconnor.net>
References: <4F31288F.5060904@amd.com> <20120208011808.GA9541@morn.localdomain>
In-Reply-To: <20120208011808.GA9541@morn.localdomain>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/08/12 02:18, Kevin O'Connor wrote:
> On Tue, Feb 07, 2012 at 02:35:11PM +0100, Christoph Egger wrote:
>>
>> Adding seabios ML.
>>
>> On 01/26/12 16:06, Ian Campbell wrote:
>>> On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
>>>> On 01/26/12 15:51, Ian Campbell wrote:
>>>>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
>>>>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>>>>>>       Building ld scripts (version "1.6.3.1-20120126_152501")
>>>>>> env: python: No such file or directory
>>>>>> gmake[6]: *** [out/romlayout16.lds] Error 127
>>>>>>
>>>>>>
>>>>>> The python scripts must be invoked with $(PYTHON) as done
>>>>>> throughout the build system.
>
> We can change the seabios makefile to call these scripts with an
> explicit $(PYTHON).

Awesome!

> However, it's odd that there isn't a default python on your system.
>
> [...]
>> What python version does SeaBIOS require?
>> I have python 2.5 installed.
>
> It should work with python 2.5 - there's nothing really special going
> on in the script.
>
>> I manually created a python symlink to that version and then I get
>> this failure:
>>
>> gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
>>    Building ld scripts (version "1.6.3.1-20120127_151243")
>> Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
>> 16bit size:           46336
>> 32bit segmented size: 2005
>> 32bit flat size:      14699
>> 32bit flat init size: 53888
>> Traceback (most recent call last):
>>    File "./tools/layoutrom.py", line 579, in<module>
>>      main()
>>    File "./tools/layoutrom.py", line 576, in main
>>      writeLinkerScripts(sections, entrysym, genreloc, out16,
>> out32seg, out32flag)
>>    File "./tools/layoutrom.py", line 257, in writeLinkerScripts
>>      + COMMONTRAILER
>> TypeError: int argument required
>
> That's quite odd.  This looks data related instead of python related.
> Try running a "make clean" and then "make" in just the seabios
> directory.  If you still see an issue, tar up the seabios "out/"
> directory and mail it to me.

It failed the same way.
I sent you the tarball offlist due its size.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 10:34:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 10:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv4qV-00040l-LR; Wed, 08 Feb 2012 10:33:51 +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 1Rv4qU-000406-6h; Wed, 08 Feb 2012 10:33:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328697175!61994829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14836 invoked from network); 8 Feb 2012 10:32:56 -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;
	8 Feb 2012 10:32:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10564969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 10:33:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 10:33:43 +0000
Date: Wed, 8 Feb 2012 10:36:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Frank, Chen" <chysun2000@163.com>
In-Reply-To: <615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
Message-ID: <alpine.DEB.2.00.1202081035210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1461947762-1328697424=:3196"
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"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] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1461947762-1328697424=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 6 Feb 2012, Frank, Chen wrote:
> Hi Xen-ARMs,
>  
> I applied this patch, "error: unknown type name 'xen_callback_t' is fixed.

Thanks for testing!


> But I still meet the problem. The problem is
> where to download the cross compiler "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and mcpu=cortex-a15.
>  
> Would someone give me one avaiable URL to download the right compiler? 

Which cross-compiler are you using at the moment?
If you are on Ubuntu, we just need to

apt-get install gcc-arm-linux-gnueabi

in order to get Linaro's cross-compiler.
--8323329-1461947762-1328697424=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1461947762-1328697424=:3196--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 10:34:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 10:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv4qV-00040l-LR; Wed, 08 Feb 2012 10:33:51 +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 1Rv4qU-000406-6h; Wed, 08 Feb 2012 10:33:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328697175!61994829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14836 invoked from network); 8 Feb 2012 10:32:56 -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;
	8 Feb 2012 10:32:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10564969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 10:33:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 10:33:43 +0000
Date: Wed, 8 Feb 2012 10:36:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Frank, Chen" <chysun2000@163.com>
In-Reply-To: <615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
Message-ID: <alpine.DEB.2.00.1202081035210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1461947762-1328697424=:3196"
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"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] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1461947762-1328697424=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 6 Feb 2012, Frank, Chen wrote:
> Hi Xen-ARMs,
>  
> I applied this patch, "error: unknown type name 'xen_callback_t' is fixed.

Thanks for testing!


> But I still meet the problem. The problem is
> where to download the cross compiler "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and mcpu=cortex-a15.
>  
> Would someone give me one avaiable URL to download the right compiler? 

Which cross-compiler are you using at the moment?
If you are on Ubuntu, we just need to

apt-get install gcc-arm-linux-gnueabi

in order to get Linaro's cross-compiler.
--8323329-1461947762-1328697424=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1461947762-1328697424=:3196--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GJ-0004QR-On; Wed, 08 Feb 2012 11:00:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GI-0004Pr-AL
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:30 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328698822!14454692!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13244 invoked from network); 8 Feb 2012 11:00:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	8 Feb 2012 11:00:23 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18B0MMI025254
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KOk017770; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id CE1AE41536; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:14 +0100
Message-Id: <1328698819-31269-2-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 1/6] suspend: add infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds some infrastructure to handle suspend and resume to
qemu.  First there are two functions to switch state and second there
is a suspend notifier:

 * qemu_system_suspend_request() is supposed to be called when the
   guest asks for being be suspended, for example via ACPI.

 * qemu_system_wakeup_request is supposed to be called on events which
   should wake up the guest.

 * qemu_register_suspend_notifier can be used to register a notifier
   which will be called when the guest is suspended.  Machine types
   and device models can hook in there to modify state if needed.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 sysemu.h |    3 +++
 vl.c     |   28 ++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/sysemu.h b/sysemu.h
index 9d5ce33..3b9d7f5 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -39,6 +39,9 @@ void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
 void qemu_system_reset_request(void);
+void qemu_system_suspend_request(void);
+void qemu_register_suspend_notifier(Notifier *notifier);
+void qemu_system_wakeup_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index 63dd725..822fd58 100644
--- a/vl.c
+++ b/vl.c
@@ -1283,6 +1283,9 @@ static int shutdown_requested, shutdown_signal = -1;
 static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
+static bool is_suspended;
+static NotifierList suspend_notifiers =
+    NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1398,6 +1401,31 @@ void qemu_system_reset_request(void)
     qemu_notify_event();
 }
 
+void qemu_system_suspend_request(void)
+{
+    if (is_suspended) {
+        return;
+    }
+    cpu_stop_current();
+    notifier_list_notify(&suspend_notifiers, NULL);
+    is_suspended = true;
+}
+
+void qemu_register_suspend_notifier(Notifier *notifier)
+{
+    notifier_list_add(&suspend_notifiers, notifier);
+}
+
+void qemu_system_wakeup_request(void)
+{
+    if (!is_suspended) {
+        return;
+    }
+    reset_requested = 1;
+    qemu_notify_event();
+    is_suspended = false;
+}
+
 void qemu_system_killed(int signal, pid_t pid)
 {
     shutdown_signal = signal;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GJ-0004QR-On; Wed, 08 Feb 2012 11:00:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GI-0004Pr-AL
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:30 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328698822!14454692!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13244 invoked from network); 8 Feb 2012 11:00:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	8 Feb 2012 11:00:23 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18B0MMI025254
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KOk017770; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id CE1AE41536; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:14 +0100
Message-Id: <1328698819-31269-2-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 1/6] suspend: add infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds some infrastructure to handle suspend and resume to
qemu.  First there are two functions to switch state and second there
is a suspend notifier:

 * qemu_system_suspend_request() is supposed to be called when the
   guest asks for being be suspended, for example via ACPI.

 * qemu_system_wakeup_request is supposed to be called on events which
   should wake up the guest.

 * qemu_register_suspend_notifier can be used to register a notifier
   which will be called when the guest is suspended.  Machine types
   and device models can hook in there to modify state if needed.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 sysemu.h |    3 +++
 vl.c     |   28 ++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/sysemu.h b/sysemu.h
index 9d5ce33..3b9d7f5 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -39,6 +39,9 @@ void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
 void qemu_system_reset_request(void);
+void qemu_system_suspend_request(void);
+void qemu_register_suspend_notifier(Notifier *notifier);
+void qemu_system_wakeup_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index 63dd725..822fd58 100644
--- a/vl.c
+++ b/vl.c
@@ -1283,6 +1283,9 @@ static int shutdown_requested, shutdown_signal = -1;
 static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
+static bool is_suspended;
+static NotifierList suspend_notifiers =
+    NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1398,6 +1401,31 @@ void qemu_system_reset_request(void)
     qemu_notify_event();
 }
 
+void qemu_system_suspend_request(void)
+{
+    if (is_suspended) {
+        return;
+    }
+    cpu_stop_current();
+    notifier_list_notify(&suspend_notifiers, NULL);
+    is_suspended = true;
+}
+
+void qemu_register_suspend_notifier(Notifier *notifier)
+{
+    notifier_list_add(&suspend_notifiers, notifier);
+}
+
+void qemu_system_wakeup_request(void)
+{
+    if (!is_suspended) {
+        return;
+    }
+    reset_requested = 1;
+    qemu_notify_event();
+    is_suspended = false;
+}
+
 void qemu_system_killed(int signal, pid_t pid)
 {
     shutdown_signal = signal;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GF-0004Px-0O; Wed, 08 Feb 2012 11:00:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GD-0004Ps-GK
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:25 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328698774!53373955!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18107 invoked from network); 8 Feb 2012 10:59:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	8 Feb 2012 10:59:34 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18B0MnQ005869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KDv017772; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 175AB41537; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:17 +0100
Message-Id: <1328698819-31269-5-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 4/6] suspend: make ps/2 devices wakeup the
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds wakeup support to ps/2 emulation.  Any key press on the
ps/2 keyboard will wakeup the guest.  Likewise any mouse button press
will wakeup the guest.  Mouse moves are ignored, so the guest will not
wakeup in case your mouse crosses the vnc window of a suspended guest by
accident.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/ps2.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/ps2.c b/hw/ps2.c
index 1d9057b..d1b2505 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -24,6 +24,7 @@
 #include "hw.h"
 #include "ps2.h"
 #include "console.h"
+#include "sysemu.h"
 
 /* debug PC keyboard */
 //#define DEBUG_KBD
@@ -154,6 +155,7 @@ static void ps2_put_keycode(void *opaque, int keycode)
 {
     PS2KbdState *s = opaque;
 
+    qemu_system_wakeup_request();
     /* XXX: add support for scancode set 1 */
     if (!s->translate && keycode < 0xe0 && s->scancode_set > 1) {
         if (keycode & 0x80) {
@@ -368,6 +370,10 @@ static void ps2_mouse_event(void *opaque,
 	return;
     s->mouse_buttons = buttons_state;
 
+    if (buttons_state) {
+        qemu_system_wakeup_request();
+    }
+
     if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
         (s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
         for(;;) {
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GF-0004Px-0O; Wed, 08 Feb 2012 11:00:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GD-0004Ps-GK
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:25 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328698774!53373955!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18107 invoked from network); 8 Feb 2012 10:59:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	8 Feb 2012 10:59:34 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18B0MnQ005869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KDv017772; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 175AB41537; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:17 +0100
Message-Id: <1328698819-31269-5-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 4/6] suspend: make ps/2 devices wakeup the
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds wakeup support to ps/2 emulation.  Any key press on the
ps/2 keyboard will wakeup the guest.  Likewise any mouse button press
will wakeup the guest.  Mouse moves are ignored, so the guest will not
wakeup in case your mouse crosses the vnc window of a suspended guest by
accident.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/ps2.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/ps2.c b/hw/ps2.c
index 1d9057b..d1b2505 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -24,6 +24,7 @@
 #include "hw.h"
 #include "ps2.h"
 #include "console.h"
+#include "sysemu.h"
 
 /* debug PC keyboard */
 //#define DEBUG_KBD
@@ -154,6 +155,7 @@ static void ps2_put_keycode(void *opaque, int keycode)
 {
     PS2KbdState *s = opaque;
 
+    qemu_system_wakeup_request();
     /* XXX: add support for scancode set 1 */
     if (!s->translate && keycode < 0xe0 && s->scancode_set > 1) {
         if (keycode & 0x80) {
@@ -368,6 +370,10 @@ static void ps2_mouse_event(void *opaque,
 	return;
     s->mouse_buttons = buttons_state;
 
+    if (buttons_state) {
+        qemu_system_wakeup_request();
+    }
+
     if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
         (s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
         for(;;) {
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GN-0004RK-UR; Wed, 08 Feb 2012 11:00:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GL-0004Q6-Nn
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328698826!12434439!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12524 invoked from network); 8 Feb 2012 11:00:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	8 Feb 2012 11:00:27 -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 q18B0PhR025266
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:25 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0Ovx020461; Wed, 8 Feb 2012 06:00:25 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 29E2541538; Wed,  8 Feb 2012 12:00:20 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:18 +0100
Message-Id: <1328698819-31269-6-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 5/6] suspend: make serial ports wakeup the
	guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the serial port.  It is off by default.  When
enabled any incoming character on the serial line will wake up the
guest.  Useful for guests which have a serial console configured.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/serial.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index 82917e2..108bb94 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -139,6 +139,7 @@ struct SerialState {
     int it_shift;
     int baudbase;
     int tsr_retry;
+    uint32_t wakeup;
 
     uint64_t last_xmit_ts;              /* Time when the last byte was successfully sent out of the tsr */
     SerialFIFO recv_fifo;
@@ -635,6 +636,10 @@ static int serial_can_receive1(void *opaque)
 static void serial_receive1(void *opaque, const uint8_t *buf, int size)
 {
     SerialState *s = opaque;
+
+    if (s->wakeup) {
+        qemu_system_wakeup_request();
+    }
     if(s->fcr & UART_FCR_FE) {
         int i;
         for (i = 0; i < size; i++) {
@@ -884,6 +889,7 @@ static Property serial_isa_properties[] = {
     DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
     DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
     DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
+    DEFINE_PROP_UINT32("wakeup", ISASerialState, state.wakeup, 0),
     DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GN-0004RK-UR; Wed, 08 Feb 2012 11:00:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GL-0004Q6-Nn
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328698826!12434439!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12524 invoked from network); 8 Feb 2012 11:00:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	8 Feb 2012 11:00:27 -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 q18B0PhR025266
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:25 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0Ovx020461; Wed, 8 Feb 2012 06:00:25 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 29E2541538; Wed,  8 Feb 2012 12:00:20 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:18 +0100
Message-Id: <1328698819-31269-6-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 5/6] suspend: make serial ports wakeup the
	guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the serial port.  It is off by default.  When
enabled any incoming character on the serial line will wake up the
guest.  Useful for guests which have a serial console configured.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/serial.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index 82917e2..108bb94 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -139,6 +139,7 @@ struct SerialState {
     int it_shift;
     int baudbase;
     int tsr_retry;
+    uint32_t wakeup;
 
     uint64_t last_xmit_ts;              /* Time when the last byte was successfully sent out of the tsr */
     SerialFIFO recv_fifo;
@@ -635,6 +636,10 @@ static int serial_can_receive1(void *opaque)
 static void serial_receive1(void *opaque, const uint8_t *buf, int size)
 {
     SerialState *s = opaque;
+
+    if (s->wakeup) {
+        qemu_system_wakeup_request();
+    }
     if(s->fcr & UART_FCR_FE) {
         int i;
         for (i = 0; i < size; i++) {
@@ -884,6 +889,7 @@ static Property serial_isa_properties[] = {
     DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
     DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
     DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
+    DEFINE_PROP_UINT32("wakeup", ISASerialState, state.wakeup, 0),
     DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GI-0004QE-Cy; Wed, 08 Feb 2012 11:00:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GG-0004Q7-UR
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:29 +0000
Received: from [85.158.139.83:15504] by server-7.bemta-5.messagelabs.com id
	84/3C-01252-CC5523F4; Wed, 08 Feb 2012 11:00:28 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328698826!14195369!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16175 invoked from network); 8 Feb 2012 11:00:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	8 Feb 2012 11:00:27 -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 q18B0QBt008770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:26 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0OVE020469; Wed, 8 Feb 2012 06:00:25 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 860BB41535; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:13 +0100
Message-Id: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 0/6] initial suspend support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series makes suspend support in qemu alot more useful.  Right
now the guest can put itself into s3, but qemu will wakeup the guest
instantly.  With this patch series applied the guest will stay suspended
instead and there are a few events which can kick the guest out of
suspend state:  A monitor command, ps/2 input, serial input, rtc.  Not
much yet, but it's a start with the low hanging fruits ;)

Changes in v3:
 * Rename monitor command to 'system_wakeup'.
 * Fix tyops in documentation.

Changes in v2:
 * Add a suspend notifier.
 * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of
   hackish cmos_s3 windup code (this touches xen-all.c,
   thus cc xen-devel).
 * Add rtc wakeup support.

Gerd Hoffmann (6):
  suspend: add infrastructure
  suspend: switch acpi s3 to new infrastructure.
  suspend: add system_wakeup monitor command
  suspend: make ps/2 devices wakeup the guest
  suspend: make serial ports wakeup the guest.
  suspend: make rtc alarm wakeup the guest.

 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   17 +++++++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/ps2.c         |    6 ++++++
 hw/serial.c      |    6 ++++++
 hw/vt82c686.c    |    1 -
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 sysemu.h         |    3 +++
 vl.c             |   28 ++++++++++++++++++++++++++++
 xen-all.c        |   11 ++++++-----
 20 files changed, 128 insertions(+), 41 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GI-0004QE-Cy; Wed, 08 Feb 2012 11:00:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GG-0004Q7-UR
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:29 +0000
Received: from [85.158.139.83:15504] by server-7.bemta-5.messagelabs.com id
	84/3C-01252-CC5523F4; Wed, 08 Feb 2012 11:00:28 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328698826!14195369!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16175 invoked from network); 8 Feb 2012 11:00:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	8 Feb 2012 11:00:27 -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 q18B0QBt008770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:26 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0OVE020469; Wed, 8 Feb 2012 06:00:25 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 860BB41535; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:13 +0100
Message-Id: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 0/6] initial suspend support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series makes suspend support in qemu alot more useful.  Right
now the guest can put itself into s3, but qemu will wakeup the guest
instantly.  With this patch series applied the guest will stay suspended
instead and there are a few events which can kick the guest out of
suspend state:  A monitor command, ps/2 input, serial input, rtc.  Not
much yet, but it's a start with the low hanging fruits ;)

Changes in v3:
 * Rename monitor command to 'system_wakeup'.
 * Fix tyops in documentation.

Changes in v2:
 * Add a suspend notifier.
 * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of
   hackish cmos_s3 windup code (this touches xen-all.c,
   thus cc xen-devel).
 * Add rtc wakeup support.

Gerd Hoffmann (6):
  suspend: add infrastructure
  suspend: switch acpi s3 to new infrastructure.
  suspend: add system_wakeup monitor command
  suspend: make ps/2 devices wakeup the guest
  suspend: make serial ports wakeup the guest.
  suspend: make rtc alarm wakeup the guest.

 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   17 +++++++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/ps2.c         |    6 ++++++
 hw/serial.c      |    6 ++++++
 hw/vt82c686.c    |    1 -
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 sysemu.h         |    3 +++
 vl.c             |   28 ++++++++++++++++++++++++++++
 xen-all.c        |   11 ++++++-----
 20 files changed, 128 insertions(+), 41 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GO-0004RT-B0; Wed, 08 Feb 2012 11:00:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GM-0004Qh-BF
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:34 +0000
Received: from [85.158.139.83:54447] by server-11.bemta-5.messagelabs.com id
	64/BB-13907-1D5523F4; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328698831!14195401!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17220 invoked from network); 8 Feb 2012 11:00:32 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	8 Feb 2012 11:00:32 -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 q18B0MAC025260
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KxA011726; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id F2DE64144E; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:16 +0100
Message-Id: <1328698819-31269-4-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 3/6] suspend: add system_wakeup monitor
	command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds the system_wakeup monitor command which will simply
wake up suspended guests.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 6 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 573b823..64b3656 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -352,6 +352,20 @@ Resume emulation.
 ETEXI
 
     {
+        .name       = "system_wakeup",
+        .args_type  = "",
+        .params     = "",
+        .help       = "wakeup guest from suspend",
+        .mhandler.cmd = hmp_system_wakeup,
+    },
+
+STEXI
+@item system_wakeup
+@findex system_wakeup
+Wakeup guest from suspend.
+ETEXI
+
+    {
         .name       = "gdbserver",
         .args_type  = "device:s?",
         .params     = "[device]",
diff --git a/hmp.c b/hmp.c
index 8ff8c94..3a54455 100644
--- a/hmp.c
+++ b/hmp.c
@@ -632,6 +632,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
     }
 }
 
+void hmp_system_wakeup(Monitor *mon, const QDict *qdict)
+{
+    qmp_system_wakeup(NULL);
+}
+
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
 {
     Error *errp = NULL;
diff --git a/hmp.h b/hmp.h
index 18eecbd..5409464 100644
--- a/hmp.h
+++ b/hmp.h
@@ -41,6 +41,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
 void hmp_memsave(Monitor *mon, const QDict *qdict);
 void hmp_pmemsave(Monitor *mon, const QDict *qdict);
 void hmp_cont(Monitor *mon, const QDict *qdict);
+void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
 void hmp_set_link(Monitor *mon, const QDict *qdict);
 void hmp_block_passwd(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index d02ee86..226c1da 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -999,6 +999,17 @@
 { 'command': 'cont' }
 
 ##
+# @system_wakeup:
+#
+# Wakeup guest from suspend
+#
+# Since:  1.1
+#
+# Returns:  nothing.
+##
+{ 'command': 'system_wakeup' }
+
+##
 # @inject-nmi:
 #
 # Injects an Non-Maskable Interrupt into all guest's VCPUs.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index b5e2ab8..f5081e2 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -212,6 +212,27 @@ Example:
 EQMP
 
     {
+        .name       = "system_wakeup",
+        .args_type  = "",
+        .mhandler.cmd_new = qmp_marshal_input_system_wakeup,
+    },
+
+SQMP
+system_wakeup
+-------------
+
+Wakeup guest from suspend.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "system_wakeup" }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "system_reset",
         .args_type  = "",
         .mhandler.cmd_new = qmp_marshal_input_system_reset,
diff --git a/qmp.c b/qmp.c
index 45052cc..9ff5ec3 100644
--- a/qmp.c
+++ b/qmp.c
@@ -164,6 +164,11 @@ void qmp_cont(Error **errp)
     vm_start();
 }
 
+void qmp_system_wakeup(Error **errp)
+{
+    qemu_system_wakeup_request();
+}
+
 ObjectPropertyInfoList *qmp_qom_list(const char *path, Error **errp)
 {
     Object *obj;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GO-0004RT-B0; Wed, 08 Feb 2012 11:00:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GM-0004Qh-BF
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:34 +0000
Received: from [85.158.139.83:54447] by server-11.bemta-5.messagelabs.com id
	64/BB-13907-1D5523F4; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328698831!14195401!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17220 invoked from network); 8 Feb 2012 11:00:32 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-182.messagelabs.com with SMTP;
	8 Feb 2012 11:00:32 -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 q18B0MAC025260
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KxA011726; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id F2DE64144E; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:16 +0100
Message-Id: <1328698819-31269-4-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 3/6] suspend: add system_wakeup monitor
	command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds the system_wakeup monitor command which will simply
wake up suspended guests.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 6 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 573b823..64b3656 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -352,6 +352,20 @@ Resume emulation.
 ETEXI
 
     {
+        .name       = "system_wakeup",
+        .args_type  = "",
+        .params     = "",
+        .help       = "wakeup guest from suspend",
+        .mhandler.cmd = hmp_system_wakeup,
+    },
+
+STEXI
+@item system_wakeup
+@findex system_wakeup
+Wakeup guest from suspend.
+ETEXI
+
+    {
         .name       = "gdbserver",
         .args_type  = "device:s?",
         .params     = "[device]",
diff --git a/hmp.c b/hmp.c
index 8ff8c94..3a54455 100644
--- a/hmp.c
+++ b/hmp.c
@@ -632,6 +632,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
     }
 }
 
+void hmp_system_wakeup(Monitor *mon, const QDict *qdict)
+{
+    qmp_system_wakeup(NULL);
+}
+
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
 {
     Error *errp = NULL;
diff --git a/hmp.h b/hmp.h
index 18eecbd..5409464 100644
--- a/hmp.h
+++ b/hmp.h
@@ -41,6 +41,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
 void hmp_memsave(Monitor *mon, const QDict *qdict);
 void hmp_pmemsave(Monitor *mon, const QDict *qdict);
 void hmp_cont(Monitor *mon, const QDict *qdict);
+void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
 void hmp_set_link(Monitor *mon, const QDict *qdict);
 void hmp_block_passwd(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index d02ee86..226c1da 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -999,6 +999,17 @@
 { 'command': 'cont' }
 
 ##
+# @system_wakeup:
+#
+# Wakeup guest from suspend
+#
+# Since:  1.1
+#
+# Returns:  nothing.
+##
+{ 'command': 'system_wakeup' }
+
+##
 # @inject-nmi:
 #
 # Injects an Non-Maskable Interrupt into all guest's VCPUs.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index b5e2ab8..f5081e2 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -212,6 +212,27 @@ Example:
 EQMP
 
     {
+        .name       = "system_wakeup",
+        .args_type  = "",
+        .mhandler.cmd_new = qmp_marshal_input_system_wakeup,
+    },
+
+SQMP
+system_wakeup
+-------------
+
+Wakeup guest from suspend.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "system_wakeup" }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "system_reset",
         .args_type  = "",
         .mhandler.cmd_new = qmp_marshal_input_system_reset,
diff --git a/qmp.c b/qmp.c
index 45052cc..9ff5ec3 100644
--- a/qmp.c
+++ b/qmp.c
@@ -164,6 +164,11 @@ void qmp_cont(Error **errp)
     vm_start();
 }
 
+void qmp_system_wakeup(Error **errp)
+{
+    qemu_system_wakeup_request();
+}
+
 ObjectPropertyInfoList *qmp_qom_list(const char *path, Error **errp)
 {
     Object *obj;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GN-0004R2-5W; Wed, 08 Feb 2012 11:00:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GL-0004Q4-2h
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328698825!14094513!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22389 invoked from network); 8 Feb 2012 11:00:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	8 Feb 2012 11:00:25 -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 q18B0OsU028711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:24 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KMK020373; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id AF977400B8; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:15 +0100
Message-Id: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new
	infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch switches pc s3 suspend over to the new infrastructure.
The cmos_s3 qemu_irq is killed, the new notifier is used instead.
The xen hack goes away with that too, the hypercall can simply be
done in a notifier function now.

This patch also makes the guest actually stay suspended instead
of leaving suspend instantly, so it is useful for more than just
testing whenever the suspend/resume cycle actually works.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   12 ++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/vt82c686.c    |    1 -
 xen-all.c        |   11 ++++++-----
 10 files changed, 23 insertions(+), 41 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 79b179b..67dcd43 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -330,11 +330,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
 }
 
 /* ACPI PM1aCNT */
-void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
-{
-    pm1_cnt->cmos_s3 = cmos_s3;
-}
-
 void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
 {
     pm1_cnt->cnt = val & ~(ACPI_BITMASK_SLEEP_ENABLE);
@@ -351,8 +346,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
                Pretend that resume was caused by power button */
             pm1a->sts |=
                 (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
-            qemu_system_reset_request();
-            qemu_irq_raise(pm1_cnt->cmos_s3);
+            qemu_system_suspend_request();
         default:
             break;
         }
@@ -373,9 +367,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
 void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
 {
     pm1_cnt->cnt = 0;
-    if (pm1_cnt->cmos_s3) {
-        qemu_irq_lower(pm1_cnt->cmos_s3);
-    }
 }
 
 /* ACPI GPE */
diff --git a/hw/acpi.h b/hw/acpi.h
index c141e65..e0c7dbe 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
 /* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
 struct ACPIPM1CNT {
     uint16_t cnt;
-
-    qemu_irq cmos_s3;
 };
 typedef struct ACPIPM1CNT ACPIPM1CNT;
 
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 21484ae..bc77dc5 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -376,7 +376,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
 }
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled)
 {
     PCIDevice *dev;
@@ -387,7 +387,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
 
     s = DO_UPCAST(PIIX4PMState, dev, dev);
     s->irq = sci_irq;
-    acpi_pm1_cnt_init(&s->pm1_cnt, cmos_s3);
     s->smi_irq = smi_irq;
     s->kvm_enabled = kvm_enabled;
 
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 4a43225..314ed52 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -102,6 +102,7 @@ typedef struct RTCState {
     QEMUTimer *second_timer2;
     Notifier clock_reset_notifier;
     LostTickPolicy lost_tick_policy;
+    Notifier suspend_notifier;
 } RTCState;
 
 static void rtc_set_time(RTCState *s);
@@ -596,6 +597,14 @@ static void rtc_notify_clock_reset(Notifier *notifier, void *data)
 #endif
 }
 
+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
+   BIOS will read it and start S3 resume at POST Entry */
+static void rtc_notify_suspend(Notifier *notifier, void *data)
+{
+    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
+    rtc_set_memory(&s->dev, 0xF, 0xFE);
+}
+
 static void rtc_reset(void *opaque)
 {
     RTCState *s = opaque;
@@ -676,6 +685,9 @@ static int rtc_initfn(ISADevice *dev)
     s->clock_reset_notifier.notify = rtc_notify_clock_reset;
     qemu_register_clock_reset_notifier(rtc_clock, &s->clock_reset_notifier);
 
+    s->suspend_notifier.notify = rtc_notify_suspend;
+    qemu_register_suspend_notifier(&s->suspend_notifier);
+
     s->next_second_time =
         qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index d232630..fe02c93 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
     pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
     usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
     smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
-                          isa_get_irq(NULL, 9), NULL, NULL, 0);
+                          isa_get_irq(NULL, 9), NULL, 0);
     /* TODO: Populate SPD eeprom data.  */
     smbus_eeprom_init(smbus, 8, NULL, 0);
     pit = pit_init(isa_bus, 0x40, 0);
diff --git a/hw/pc.c b/hw/pc.c
index 7f3aa65..7b93aee 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -915,17 +915,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
     return dev;
 }
 
-/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
-   BIOS will read it and start S3 resume at POST Entry */
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level)
-{
-    ISADevice *s = opaque;
-
-    if (level) {
-        rtc_set_memory(s, 0xF, 0xFE);
-    }
-}
-
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
 {
     CPUState *s = opaque;
diff --git a/hw/pc.h b/hw/pc.h
index c666ec9..571c915 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -128,7 +128,6 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
 extern int fd_bootchk;
 
 void pc_register_ferr_irq(qemu_irq irq);
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level);
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
 
 void pc_cpus_init(const char *cpu_model);
@@ -167,7 +166,7 @@ int acpi_table_add(const char *table_desc);
 /* acpi_piix.c */
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled);
 void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c06f1b5..918f5ac 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -139,7 +139,6 @@ static void pc_init1(MemoryRegion *system_memory,
     qemu_irq *cpu_irq;
     qemu_irq *gsi;
     qemu_irq *i8259;
-    qemu_irq *cmos_s3;
     qemu_irq *smi_irq;
     GSIState *gsi_state;
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
@@ -291,15 +290,10 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled && acpi_enabled) {
         i2c_bus *smbus;
 
-        if (!xen_enabled()) {
-            cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
-        } else {
-            cmos_s3 = qemu_allocate_irqs(xen_cmos_set_s3_resume, rtc_state, 1);
-        }
         smi_irq = qemu_allocate_irqs(pc_acpi_smi_interrupt, first_cpu, 1);
         /* TODO: Populate SPD eeprom data.  */
         smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
-                              gsi[9], *cmos_s3, *smi_irq,
+                              gsi[9], *smi_irq,
                               kvm_enabled());
         smbus_eeprom_init(smbus, 8, NULL, 0);
     }
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index aa0954f..8beb6c5 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -446,7 +446,6 @@ static int vt82c686b_pm_initfn(PCIDevice *dev)
     apm_init(&s->apm, NULL, s);
 
     acpi_pm_tmr_init(&s->tmr, pm_tmr_timer);
-    acpi_pm1_cnt_init(&s->pm1_cnt, NULL);
 
     pm_smbus_init(&s->dev.qdev, &s->smb);
 
diff --git a/xen-all.c b/xen-all.c
index fd39168..b0ed1ed 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -89,6 +89,7 @@ typedef struct XenIOState {
     const XenPhysmap *log_for_dirtybit;
 
     Notifier exit;
+    Notifier suspend;
 } XenIOState;
 
 /* Xen specific function for piix pci */
@@ -121,12 +122,9 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
-void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
+static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
-    pc_cmos_set_s3_resume(opaque, irq, level);
-    if (level) {
-        xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
-    }
+    xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
 }
 
 /* Xen Interrupt Controller */
@@ -936,6 +934,9 @@ int xen_hvm_init(void)
     state->exit.notify = xen_exit_notifier;
     qemu_add_exit_notifier(&state->exit);
 
+    state->suspend.notify = xen_suspend_notifier;
+    qemu_register_suspend_notifier(&state->suspend);
+
     xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
     DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
     state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GN-0004R2-5W; Wed, 08 Feb 2012 11:00:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GL-0004Q4-2h
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328698825!14094513!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22389 invoked from network); 8 Feb 2012 11:00:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	8 Feb 2012 11:00:25 -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 q18B0OsU028711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:24 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0KMK020373; Wed, 8 Feb 2012 06:00:21 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id AF977400B8; Wed,  8 Feb 2012 12:00:19 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:15 +0100
Message-Id: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new
	infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch switches pc s3 suspend over to the new infrastructure.
The cmos_s3 qemu_irq is killed, the new notifier is used instead.
The xen hack goes away with that too, the hypercall can simply be
done in a notifier function now.

This patch also makes the guest actually stay suspended instead
of leaving suspend instantly, so it is useful for more than just
testing whenever the suspend/resume cycle actually works.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   12 ++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/vt82c686.c    |    1 -
 xen-all.c        |   11 ++++++-----
 10 files changed, 23 insertions(+), 41 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 79b179b..67dcd43 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -330,11 +330,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
 }
 
 /* ACPI PM1aCNT */
-void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
-{
-    pm1_cnt->cmos_s3 = cmos_s3;
-}
-
 void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
 {
     pm1_cnt->cnt = val & ~(ACPI_BITMASK_SLEEP_ENABLE);
@@ -351,8 +346,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
                Pretend that resume was caused by power button */
             pm1a->sts |=
                 (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
-            qemu_system_reset_request();
-            qemu_irq_raise(pm1_cnt->cmos_s3);
+            qemu_system_suspend_request();
         default:
             break;
         }
@@ -373,9 +367,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
 void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
 {
     pm1_cnt->cnt = 0;
-    if (pm1_cnt->cmos_s3) {
-        qemu_irq_lower(pm1_cnt->cmos_s3);
-    }
 }
 
 /* ACPI GPE */
diff --git a/hw/acpi.h b/hw/acpi.h
index c141e65..e0c7dbe 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
 /* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
 struct ACPIPM1CNT {
     uint16_t cnt;
-
-    qemu_irq cmos_s3;
 };
 typedef struct ACPIPM1CNT ACPIPM1CNT;
 
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 21484ae..bc77dc5 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -376,7 +376,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
 }
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled)
 {
     PCIDevice *dev;
@@ -387,7 +387,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
 
     s = DO_UPCAST(PIIX4PMState, dev, dev);
     s->irq = sci_irq;
-    acpi_pm1_cnt_init(&s->pm1_cnt, cmos_s3);
     s->smi_irq = smi_irq;
     s->kvm_enabled = kvm_enabled;
 
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 4a43225..314ed52 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -102,6 +102,7 @@ typedef struct RTCState {
     QEMUTimer *second_timer2;
     Notifier clock_reset_notifier;
     LostTickPolicy lost_tick_policy;
+    Notifier suspend_notifier;
 } RTCState;
 
 static void rtc_set_time(RTCState *s);
@@ -596,6 +597,14 @@ static void rtc_notify_clock_reset(Notifier *notifier, void *data)
 #endif
 }
 
+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
+   BIOS will read it and start S3 resume at POST Entry */
+static void rtc_notify_suspend(Notifier *notifier, void *data)
+{
+    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
+    rtc_set_memory(&s->dev, 0xF, 0xFE);
+}
+
 static void rtc_reset(void *opaque)
 {
     RTCState *s = opaque;
@@ -676,6 +685,9 @@ static int rtc_initfn(ISADevice *dev)
     s->clock_reset_notifier.notify = rtc_notify_clock_reset;
     qemu_register_clock_reset_notifier(rtc_clock, &s->clock_reset_notifier);
 
+    s->suspend_notifier.notify = rtc_notify_suspend;
+    qemu_register_suspend_notifier(&s->suspend_notifier);
+
     s->next_second_time =
         qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index d232630..fe02c93 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
     pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
     usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
     smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
-                          isa_get_irq(NULL, 9), NULL, NULL, 0);
+                          isa_get_irq(NULL, 9), NULL, 0);
     /* TODO: Populate SPD eeprom data.  */
     smbus_eeprom_init(smbus, 8, NULL, 0);
     pit = pit_init(isa_bus, 0x40, 0);
diff --git a/hw/pc.c b/hw/pc.c
index 7f3aa65..7b93aee 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -915,17 +915,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
     return dev;
 }
 
-/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
-   BIOS will read it and start S3 resume at POST Entry */
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level)
-{
-    ISADevice *s = opaque;
-
-    if (level) {
-        rtc_set_memory(s, 0xF, 0xFE);
-    }
-}
-
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
 {
     CPUState *s = opaque;
diff --git a/hw/pc.h b/hw/pc.h
index c666ec9..571c915 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -128,7 +128,6 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
 extern int fd_bootchk;
 
 void pc_register_ferr_irq(qemu_irq irq);
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level);
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
 
 void pc_cpus_init(const char *cpu_model);
@@ -167,7 +166,7 @@ int acpi_table_add(const char *table_desc);
 /* acpi_piix.c */
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled);
 void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c06f1b5..918f5ac 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -139,7 +139,6 @@ static void pc_init1(MemoryRegion *system_memory,
     qemu_irq *cpu_irq;
     qemu_irq *gsi;
     qemu_irq *i8259;
-    qemu_irq *cmos_s3;
     qemu_irq *smi_irq;
     GSIState *gsi_state;
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
@@ -291,15 +290,10 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled && acpi_enabled) {
         i2c_bus *smbus;
 
-        if (!xen_enabled()) {
-            cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
-        } else {
-            cmos_s3 = qemu_allocate_irqs(xen_cmos_set_s3_resume, rtc_state, 1);
-        }
         smi_irq = qemu_allocate_irqs(pc_acpi_smi_interrupt, first_cpu, 1);
         /* TODO: Populate SPD eeprom data.  */
         smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
-                              gsi[9], *cmos_s3, *smi_irq,
+                              gsi[9], *smi_irq,
                               kvm_enabled());
         smbus_eeprom_init(smbus, 8, NULL, 0);
     }
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index aa0954f..8beb6c5 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -446,7 +446,6 @@ static int vt82c686b_pm_initfn(PCIDevice *dev)
     apm_init(&s->apm, NULL, s);
 
     acpi_pm_tmr_init(&s->tmr, pm_tmr_timer);
-    acpi_pm1_cnt_init(&s->pm1_cnt, NULL);
 
     pm_smbus_init(&s->dev.qdev, &s->smb);
 
diff --git a/xen-all.c b/xen-all.c
index fd39168..b0ed1ed 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -89,6 +89,7 @@ typedef struct XenIOState {
     const XenPhysmap *log_for_dirtybit;
 
     Notifier exit;
+    Notifier suspend;
 } XenIOState;
 
 /* Xen specific function for piix pci */
@@ -121,12 +122,9 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
-void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
+static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
-    pc_cmos_set_s3_resume(opaque, irq, level);
-    if (level) {
-        xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
-    }
+    xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
 }
 
 /* Xen Interrupt Controller */
@@ -936,6 +934,9 @@ int xen_hvm_init(void)
     state->exit.notify = xen_exit_notifier;
     qemu_add_exit_notifier(&state->exit);
 
+    state->suspend.notify = xen_suspend_notifier;
+    qemu_register_suspend_notifier(&state->suspend);
+
     xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
     DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
     state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GN-0004RC-HU; Wed, 08 Feb 2012 11:00:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GL-0004Q5-LD
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328698826!15797578!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8667 invoked from network); 8 Feb 2012 11:00:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	8 Feb 2012 11:00:27 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18B0QU0028719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:26 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0Oxm007192; Wed, 8 Feb 2012 06:00:25 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 3A66341539; Wed,  8 Feb 2012 12:00:20 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:19 +0100
Message-Id: <1328698819-31269-7-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 6/6] suspend: make rtc alarm wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the mc146818rtc.  It is on by default.
When enabled the rtc will wake up the guest when the alarm fires.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/mc146818rtc.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 314ed52..3b912c6 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -86,6 +86,7 @@ typedef struct RTCState {
     uint8_t cmos_index;
     struct tm current_tm;
     int32_t base_year;
+    uint32_t wakeup;
     qemu_irq irq;
     qemu_irq sqw_irq;
     int it_shift;
@@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
 
         s->cmos_data[RTC_REG_C] |= REG_C_AF;
         if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
+            if (s->wakeup) {
+                qemu_system_wakeup_request();
+            }
             qemu_irq_raise(s->irq);
             s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
         }
@@ -725,6 +729,7 @@ static Property mc146818rtc_properties[] = {
     DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
     DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
                                lost_tick_policy, LOST_TICK_DISCARD),
+    DEFINE_PROP_UINT32("wakeup",   RTCState, wakeup,    1),
     DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:00:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv5GN-0004RC-HU; Wed, 08 Feb 2012 11:00:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rv5GL-0004Q5-LD
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:00:33 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328698826!15797578!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE4NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8667 invoked from network); 8 Feb 2012 11:00:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	8 Feb 2012 11:00:27 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q18B0QU0028719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 06:00:26 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com
	[10.36.116.33])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q18B0Oxm007192; Wed, 8 Feb 2012 06:00:25 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 3A66341539; Wed,  8 Feb 2012 12:00:20 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 12:00:19 +0100
Message-Id: <1328698819-31269-7-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v3 6/6] suspend: make rtc alarm wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the mc146818rtc.  It is on by default.
When enabled the rtc will wake up the guest when the alarm fires.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/mc146818rtc.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 314ed52..3b912c6 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -86,6 +86,7 @@ typedef struct RTCState {
     uint8_t cmos_index;
     struct tm current_tm;
     int32_t base_year;
+    uint32_t wakeup;
     qemu_irq irq;
     qemu_irq sqw_irq;
     int it_shift;
@@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
 
         s->cmos_data[RTC_REG_C] |= REG_C_AF;
         if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
+            if (s->wakeup) {
+                qemu_system_wakeup_request();
+            }
             qemu_irq_raise(s->irq);
             s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
         }
@@ -725,6 +729,7 @@ static Property mc146818rtc_properties[] = {
     DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
     DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
                                lost_tick_policy, LOST_TICK_DISCARD),
+    DEFINE_PROP_UINT32("wakeup",   RTCState, wakeup,    1),
     DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:50:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv62T-0005av-KC; Wed, 08 Feb 2012 11:50:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rv62S-0005an-A3
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:50:16 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328701808!15807116!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27335 invoked from network); 8 Feb 2012 11:50:09 -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;
	8 Feb 2012 11:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325480400"; d="scan'208";a="21746414"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 06:50:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 06:50:07 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q18Bo4Se000801;	Wed, 8 Feb 2012 03:50:05 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 8 Feb 2012 11:49:58 +0000
Message-ID: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch provide the code to set the VNC password to QEMU upstream through
VNC. The password is still stored in xenstore but will not be used by QEMU
upstream.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_create.c   |    3 +++
 tools/libxl/libxl_dm.c       |   21 ++++++++++++---------
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_qmp.c      |   37 +++++++++++++++++++++++++++++++++++++
 4 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ebf2ed7..ae0d668 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -619,6 +619,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (dm_info->device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
+            if (dm_info->vncpasswd) {
+                libxl__qmp_vnc_password(gc, domid, dm_info->vncpasswd);
+            }
         }
         ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
         if (ret < 0) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..6f7d0d5 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -271,10 +271,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (info->vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
+        char *vncarg = NULL;
 
-        if (info->vncpasswd && info->vncpasswd[0]) {
-            assert(!"missing code for supplying vnc password to qemu");
-        }
         flexarray_append(dm_args, "-vnc");
 
         if (info->vncdisplay) {
@@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         }
 
         if (strchr(listen, ':') != NULL)
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s%s", listen,
-                        info->vncunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s", listen);
         else
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vncunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+        if (info->vncpasswd && info->vncpasswd[0]) {
+            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+        }
+        if (info->vncunused) {
+            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
+        }
+        flexarray_append(dm_args, vncarg);
     }
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -862,6 +863,8 @@ int libxl__create_device_model(libxl__gc *gc,
     }
 
     if (info->vncpasswd) {
+        /* This xenstore key will only be used by qemu-xen-traditionnal.
+         * The code to supply vncpasswd to qemu-xen is later. */
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..b33be99 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -592,6 +592,7 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password);
 /* 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 1777e44..274db19 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -879,6 +879,43 @@ out:
     return rc;
 }
 
+static int qmp_change(libxl__gc *gc, int domid,
+                      char *device, char *target, char *arg)
+{
+    libxl__qmp_handler *qmp = NULL;
+    flexarray_t *parameters = NULL;
+    libxl_key_value_list args = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    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;
+
+    rc = qmp_synchronous_send(qmp, "change", &args,
+                              NULL, NULL, qmp->timeout);
+
+    flexarray_free(parameters);
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password)
+{
+    if (!password)
+        return ERROR_FAIL;
+
+    return qmp_change(gc, domid, "vnc", "password", password);
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
-- 
tg: (6674c38..) qmp-vnc-password (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:50:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv62T-0005av-KC; Wed, 08 Feb 2012 11:50:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rv62S-0005an-A3
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:50:16 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328701808!15807116!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27335 invoked from network); 8 Feb 2012 11:50:09 -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;
	8 Feb 2012 11:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325480400"; d="scan'208";a="21746414"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 06:50:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 06:50:07 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q18Bo4Se000801;	Wed, 8 Feb 2012 03:50:05 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 8 Feb 2012 11:49:58 +0000
Message-ID: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch provide the code to set the VNC password to QEMU upstream through
VNC. The password is still stored in xenstore but will not be used by QEMU
upstream.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_create.c   |    3 +++
 tools/libxl/libxl_dm.c       |   21 ++++++++++++---------
 tools/libxl/libxl_internal.h |    1 +
 tools/libxl/libxl_qmp.c      |   37 +++++++++++++++++++++++++++++++++++++
 4 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ebf2ed7..ae0d668 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -619,6 +619,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         if (dm_info->device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
+            if (dm_info->vncpasswd) {
+                libxl__qmp_vnc_password(gc, domid, dm_info->vncpasswd);
+            }
         }
         ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
         if (ret < 0) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..6f7d0d5 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -271,10 +271,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (info->vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
+        char *vncarg = NULL;
 
-        if (info->vncpasswd && info->vncpasswd[0]) {
-            assert(!"missing code for supplying vnc password to qemu");
-        }
         flexarray_append(dm_args, "-vnc");
 
         if (info->vncdisplay) {
@@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         }
 
         if (strchr(listen, ':') != NULL)
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s%s", listen,
-                        info->vncunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s", listen);
         else
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vncunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+        if (info->vncpasswd && info->vncpasswd[0]) {
+            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+        }
+        if (info->vncunused) {
+            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
+        }
+        flexarray_append(dm_args, vncarg);
     }
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -862,6 +863,8 @@ int libxl__create_device_model(libxl__gc *gc,
     }
 
     if (info->vncpasswd) {
+        /* This xenstore key will only be used by qemu-xen-traditionnal.
+         * The code to supply vncpasswd to qemu-xen is later. */
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..b33be99 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -592,6 +592,7 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password);
 /* 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 1777e44..274db19 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -879,6 +879,43 @@ out:
     return rc;
 }
 
+static int qmp_change(libxl__gc *gc, int domid,
+                      char *device, char *target, char *arg)
+{
+    libxl__qmp_handler *qmp = NULL;
+    flexarray_t *parameters = NULL;
+    libxl_key_value_list args = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    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;
+
+    rc = qmp_synchronous_send(qmp, "change", &args,
+                              NULL, NULL, qmp->timeout);
+
+    flexarray_free(parameters);
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password)
+{
+    if (!password)
+        return ERROR_FAIL;
+
+    return qmp_change(gc, domid, "vnc", "password", password);
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
-- 
tg: (6674c38..) qmp-vnc-password (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:54:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv65w-0005ie-K0; Wed, 08 Feb 2012 11:53: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 1Rv65u-0005iL-U7
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:53:51 +0000
Received: from [85.158.143.35:9752] by server-2.bemta-4.messagelabs.com id
	90/8A-02822-E42623F4; Wed, 08 Feb 2012 11:53:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328702029!1950150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3582 invoked from network); 8 Feb 2012 11:53:49 -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;
	8 Feb 2012 11:53:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10569512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 11:53:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 11:53:48 +0000
Date: Wed, 8 Feb 2012 11:56:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20273.24097.477195.904462@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
References: <4F30134C02000078000716AE@nat28.tlf.novell.com>
	<20273.24097.477195.904462@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 7 Feb 2012, Ian Jackson wrote:
> Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> > How is the supposedly strait clone on xenbits related to the "real" tree?
> > It doesn't seem to be tracking it, so I'm sort of confused whether I
> > could in fact use the upstream tree in favor of the made up mirror.
> 
> AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> but rather one with various other patches needed for Xen.  But Stefano
> will be able to comment for sure.

Hi Jan,
qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
based on qemu-stable-1.0.git, it is going to have many more Xen specific
backports than the upstream stable tree.
In particular I am talking about the QEMU timers, save/restore and PCI
passthrough series.

- Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:54:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11: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.xensource.com>)
	id 1Rv65w-0005ie-K0; Wed, 08 Feb 2012 11:53: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 1Rv65u-0005iL-U7
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:53:51 +0000
Received: from [85.158.143.35:9752] by server-2.bemta-4.messagelabs.com id
	90/8A-02822-E42623F4; Wed, 08 Feb 2012 11:53:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328702029!1950150!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3582 invoked from network); 8 Feb 2012 11:53:49 -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;
	8 Feb 2012 11:53:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10569512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 11:53:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 11:53:48 +0000
Date: Wed, 8 Feb 2012 11:56:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20273.24097.477195.904462@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
References: <4F30134C02000078000716AE@nat28.tlf.novell.com>
	<20273.24097.477195.904462@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 7 Feb 2012, Ian Jackson wrote:
> Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> > How is the supposedly strait clone on xenbits related to the "real" tree?
> > It doesn't seem to be tracking it, so I'm sort of confused whether I
> > could in fact use the upstream tree in favor of the made up mirror.
> 
> AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> but rather one with various other patches needed for Xen.  But Stefano
> will be able to comment for sure.

Hi Jan,
qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
based on qemu-stable-1.0.git, it is going to have many more Xen specific
backports than the upstream stable tree.
In particular I am talking about the QEMU timers, save/restore and PCI
passthrough series.

- Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:54:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv65w-0005iW-8j; Wed, 08 Feb 2012 11:53:52 +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 1Rv65u-0005iK-Ai
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:53:50 +0000
Received: from [85.158.139.83:46716] by server-6.bemta-5.messagelabs.com id
	D6/F6-04784-D42623F4; Wed, 08 Feb 2012 11:53:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328702026!14204478!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12409 invoked from network); 8 Feb 2012 11:53:48 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 11:53:48 -0000
Received: by iaeh11 with SMTP id h11so3967599iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 03:53:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=nqYtkXU50rY5GMIf+o2fVY1UNlTaTLI84xW2BgoKmi4=;
	b=GxQiB6fUKZpO3bC1iruTnewYG63tk1KucA1Hmdd0JMmLwZDkcDsAephbkG1eX6vk/+
	t2xSWPWqM//Y9Uv3rFxVfNlt1KEjVDfXIoDK8tpxVVEld3w6vjK6891RHPh2j6yXNcI0
	qyXxllzg9d5Fe3DcvxfpRS7cvc7jKEKJ3M9s0=
MIME-Version: 1.0
Received: by 10.42.177.133 with SMTP id bi5mr30966679icb.40.1328702026415;
	Wed, 08 Feb 2012 03:53:46 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Wed, 8 Feb 2012 03:53:46 -0800 (PST)
In-Reply-To: <4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
	<4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
Date: Wed, 8 Feb 2012 11:53:46 +0000
X-Google-Sender-Auth: b43iuASRjgscNdzyJMNqIEWO85A
Message-ID: <CAFLBxZbF3YKN19JSi4_NpXG0H=pZ3RQm42YjnaXvX_NBbR4XYw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: mike.a.collins@ark-net.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] HVM Driver Domain for GPU API remoting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 5, 2012 at 3:38 AM, Michael A. Collins
<mike.a.collins@ark-net.org> wrote:
> I recently read about Xen3D and the whole idea of API remoting for graphi=
cs
> is new to me, so that's the level I'm coming from. =A0My question is as
> follows:

I'm not sure anyone here is currently working on API remoting.  It
sounds like you're perhaps suggesting making a new PV frontend/backend
protocol, similar to blockback/front, netback/front, pvscsi, pvusb,
and so on, which would do 3D graphics processing on behalf of guests.
Is that correct?

It sounds like it could be useful to me.  Are you volunteering to
develop such a protocol? :-)

> I understand that graphics passthrough only works for HVM DomUs, with that
> being said most of the driver domains I read about for networking are
> paravirtualized with a passed through NIC. =A0Is there any work being don=
e to
> introduce the concept of a HVM-based Driver Domain, so that one can pass a
> GPU through?

AIUI, there's no Xen limitation for an HVM guest to be a driver
domain; the main limitation is for the guest to have backend support
when running in HVM mode.  I'm told the work for this has already been
done, and should be available in Linux 3.3 when it comes out.  But I'm
sure you can find the patch series if you're interested.

> =A0If so, would it not be faster to remote the API through to the
> Driver Domain hosting the GPU with a Xenbus form of communication?

xenbus is not for transmitting bulk data, but configuration
parameters.  The standard method in Xen for transmitting bulk data is
to use xenbus to establish and tear down the communication channels
(shared rings and event channels); the shared rings are used to pass
requests, and the requests contain references to pages that the
frontend wants the backend to operate on directly (the PV equivalent
of DMA).  If you're interested in developing a protocol, it might be
worth looking at the existing protocols, like the network and block
protocols.

 -George

>  =A0My
> concern, other than the fact that I don't understand a thing about how
> Xenbus and other drivers work, is that there wouldn't be the throughput
> needed to provide any better support than is currently handled by the
> virtual framebuffer. =A0I know that that kind of communication handles all
> block-level and network traffic, but the amount of data required to drive=
 a
> GPU would be much more. =A0Am I barking up the wrong tree, or is this a
> project that would benefit the community?
>
> Mike
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 11:54:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 11:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv65w-0005iW-8j; Wed, 08 Feb 2012 11:53:52 +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 1Rv65u-0005iK-Ai
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 11:53:50 +0000
Received: from [85.158.139.83:46716] by server-6.bemta-5.messagelabs.com id
	D6/F6-04784-D42623F4; Wed, 08 Feb 2012 11:53:49 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328702026!14204478!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12409 invoked from network); 8 Feb 2012 11:53:48 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 11:53:48 -0000
Received: by iaeh11 with SMTP id h11so3967599iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 03:53:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=nqYtkXU50rY5GMIf+o2fVY1UNlTaTLI84xW2BgoKmi4=;
	b=GxQiB6fUKZpO3bC1iruTnewYG63tk1KucA1Hmdd0JMmLwZDkcDsAephbkG1eX6vk/+
	t2xSWPWqM//Y9Uv3rFxVfNlt1KEjVDfXIoDK8tpxVVEld3w6vjK6891RHPh2j6yXNcI0
	qyXxllzg9d5Fe3DcvxfpRS7cvc7jKEKJ3M9s0=
MIME-Version: 1.0
Received: by 10.42.177.133 with SMTP id bi5mr30966679icb.40.1328702026415;
	Wed, 08 Feb 2012 03:53:46 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Wed, 8 Feb 2012 03:53:46 -0800 (PST)
In-Reply-To: <4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
	<4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
Date: Wed, 8 Feb 2012 11:53:46 +0000
X-Google-Sender-Auth: b43iuASRjgscNdzyJMNqIEWO85A
Message-ID: <CAFLBxZbF3YKN19JSi4_NpXG0H=pZ3RQm42YjnaXvX_NBbR4XYw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: mike.a.collins@ark-net.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] HVM Driver Domain for GPU API remoting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 5, 2012 at 3:38 AM, Michael A. Collins
<mike.a.collins@ark-net.org> wrote:
> I recently read about Xen3D and the whole idea of API remoting for graphi=
cs
> is new to me, so that's the level I'm coming from. =A0My question is as
> follows:

I'm not sure anyone here is currently working on API remoting.  It
sounds like you're perhaps suggesting making a new PV frontend/backend
protocol, similar to blockback/front, netback/front, pvscsi, pvusb,
and so on, which would do 3D graphics processing on behalf of guests.
Is that correct?

It sounds like it could be useful to me.  Are you volunteering to
develop such a protocol? :-)

> I understand that graphics passthrough only works for HVM DomUs, with that
> being said most of the driver domains I read about for networking are
> paravirtualized with a passed through NIC. =A0Is there any work being don=
e to
> introduce the concept of a HVM-based Driver Domain, so that one can pass a
> GPU through?

AIUI, there's no Xen limitation for an HVM guest to be a driver
domain; the main limitation is for the guest to have backend support
when running in HVM mode.  I'm told the work for this has already been
done, and should be available in Linux 3.3 when it comes out.  But I'm
sure you can find the patch series if you're interested.

> =A0If so, would it not be faster to remote the API through to the
> Driver Domain hosting the GPU with a Xenbus form of communication?

xenbus is not for transmitting bulk data, but configuration
parameters.  The standard method in Xen for transmitting bulk data is
to use xenbus to establish and tear down the communication channels
(shared rings and event channels); the shared rings are used to pass
requests, and the requests contain references to pages that the
frontend wants the backend to operate on directly (the PV equivalent
of DMA).  If you're interested in developing a protocol, it might be
worth looking at the existing protocols, like the network and block
protocols.

 -George

>  =A0My
> concern, other than the fact that I don't understand a thing about how
> Xenbus and other drivers work, is that there wouldn't be the throughput
> needed to provide any better support than is currently handled by the
> virtual framebuffer. =A0I know that that kind of communication handles all
> block-level and network traffic, but the amount of data required to drive=
 a
> GPU would be much more. =A0Am I barking up the wrong tree, or is this a
> project that would benefit the community?
>
> Mike
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:19:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:19:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6U4-0006Ie-Nd; Wed, 08 Feb 2012 12:18:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rv6U3-0006IW-Ob
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:18:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328703519!15812158!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11198 invoked from network); 8 Feb 2012 12:18:41 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:18:41 -0000
Received: by iaeh11 with SMTP id h11so4078931iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 04:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=J1GmTzbZraUr9017duGRfURpSlbNQ+lfLPJIS304YxY=;
	b=gUtaLxQZfujcMLnuBWwRj6kCjXz0xKLEXM2piRf9Uf5uCMZYsT9vZZu5WDDvm/IT/v
	0i5PjhzVF3ftWkqMHKjoIpHupz4qg+/oS80Hkjhx1qyqKVFHUTPhrnfK9PiUs5+azjRE
	D6eCwH8TeCLdbNd1pYFt14eUZgL/dQ1vyIgMA=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr22474453igb.10.1328703519326;
	Wed, 08 Feb 2012 04:18:39 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Wed, 8 Feb 2012 04:18:39 -0800 (PST)
In-Reply-To: <20120207201231.GA23813@phenom.dumpdata.com>
References: <20120207201231.GA23813@phenom.dumpdata.com>
Date: Wed, 8 Feb 2012 12:18:39 +0000
X-Google-Sender-Auth: 6BaitUypW-lQMvZ6CTnLevN2ulc
Message-ID: <CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 7, 2012 at 8:12 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Hey George,
>
> I was wondering if you could explain in simple terms how the scheduler would
> handle per-physical CPU when there are say 16 guests (each guest is using
> one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would
> the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so
> on; or would it be more random? (I assume that both guest and dom0 would do
> a hypercall yield too).

The scheduling would be random.  As far as I know, none of the
schedulers (sedf, credit1, or credit2) treat domain 0 differently from
any other domain.  Even guests which are very busy end up blocking
quite a bit, so the total runtime ends up being fairly random anyway.
Also, the dom0 vcpus are not pinned unless you specify dom0_pin_vcpus
on the xen command-line; so by default they will migrate freely around
the various cores.

Does that answer your question?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:19:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:19:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6U4-0006Ie-Nd; Wed, 08 Feb 2012 12:18:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rv6U3-0006IW-Ob
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:18:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328703519!15812158!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11198 invoked from network); 8 Feb 2012 12:18:41 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:18:41 -0000
Received: by iaeh11 with SMTP id h11so4078931iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 04:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=J1GmTzbZraUr9017duGRfURpSlbNQ+lfLPJIS304YxY=;
	b=gUtaLxQZfujcMLnuBWwRj6kCjXz0xKLEXM2piRf9Uf5uCMZYsT9vZZu5WDDvm/IT/v
	0i5PjhzVF3ftWkqMHKjoIpHupz4qg+/oS80Hkjhx1qyqKVFHUTPhrnfK9PiUs5+azjRE
	D6eCwH8TeCLdbNd1pYFt14eUZgL/dQ1vyIgMA=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr22474453igb.10.1328703519326;
	Wed, 08 Feb 2012 04:18:39 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Wed, 8 Feb 2012 04:18:39 -0800 (PST)
In-Reply-To: <20120207201231.GA23813@phenom.dumpdata.com>
References: <20120207201231.GA23813@phenom.dumpdata.com>
Date: Wed, 8 Feb 2012 12:18:39 +0000
X-Google-Sender-Auth: 6BaitUypW-lQMvZ6CTnLevN2ulc
Message-ID: <CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 7, 2012 at 8:12 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Hey George,
>
> I was wondering if you could explain in simple terms how the scheduler would
> handle per-physical CPU when there are say 16 guests (each guest is using
> one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would
> the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so
> on; or would it be more random? (I assume that both guest and dom0 would do
> a hypercall yield too).

The scheduling would be random.  As far as I know, none of the
schedulers (sedf, credit1, or credit2) treat domain 0 differently from
any other domain.  Even guests which are very busy end up blocking
quite a bit, so the total runtime ends up being fairly random anyway.
Also, the dom0 vcpus are not pinned unless you specify dom0_pin_vcpus
on the xen command-line; so by default they will migrate freely around
the various cores.

Does that answer your question?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:32:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6hH-0006UV-2W; Wed, 08 Feb 2012 12:32:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rv6hF-0006UQ-6B
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:32:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328704338!14451949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26356 invoked from network); 8 Feb 2012 12:32: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;
	8 Feb 2012 12:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10571060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:32:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 12:32:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rv6h8-0007qR-18; Wed, 08 Feb 2012 12:32:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rv6h7-0003C6-W2;
	Wed, 08 Feb 2012 12:32:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.27473.980939.339753@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 12:32:17 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F3235150200007800071A95@nat28.tlf.novell.com>
References: <4F3235150200007800071A95@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] Ping: [PATCH] qemu-dm: fix unregister_iomem()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Ping: [PATCH] qemu-dm: fix unregister_iomem()"):
> This function (introduced quite a long time ago in
> e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
> devices in HVM domains") appears to be completely broken, causing
> the regression reported in
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
> the newly added caller of it in
> 56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
> MSI-X table handling"). It's unclear how the function can ever have
> fulfilled its purpose: the value returned by iomem_index() is *not* an
> index into mmio[].

Thanks; I applied this yesterday but AFAICT didn't send a committed-by
email, sorry.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:32:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6hH-0006UV-2W; Wed, 08 Feb 2012 12:32:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rv6hF-0006UQ-6B
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:32:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328704338!14451949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26356 invoked from network); 8 Feb 2012 12:32: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;
	8 Feb 2012 12:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10571060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:32:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 12:32:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rv6h8-0007qR-18; Wed, 08 Feb 2012 12:32:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rv6h7-0003C6-W2;
	Wed, 08 Feb 2012 12:32:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.27473.980939.339753@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 12:32:17 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F3235150200007800071A95@nat28.tlf.novell.com>
References: <4F3235150200007800071A95@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] Ping: [PATCH] qemu-dm: fix unregister_iomem()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Ping: [PATCH] qemu-dm: fix unregister_iomem()"):
> This function (introduced quite a long time ago in
> e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
> devices in HVM domains") appears to be completely broken, causing
> the regression reported in
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
> the newly added caller of it in
> 56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
> MSI-X table handling"). It's unclear how the function can ever have
> fulfilled its purpose: the value returned by iomem_index() is *not* an
> index into mmio[].

Thanks; I applied this yesterday but AFAICT didn't send a committed-by
email, sorry.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6z3-0006jL-Vd; Wed, 08 Feb 2012 12:50:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6z1-0006jD-NZ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:50:48 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328705441!14115442!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1OTI1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19444 invoked from network); 8 Feb 2012 12:50:41 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:50:41 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=a2MbAAaSUJ4AzeXVU9ENoTiIbjvKWDPuczlrpDvMCgKs09/RhLOq2NZd
	Ve1ce7jxRx0bxTOpyA2FfSHzZvcY4TSSn8TCnzBGmje6wuN1pAnZtd2hh
	zje/RriBJMXLdEkUiIlKU2icsyw3M4cpC+YYEcHYlQ/DY1xurKMQwg7Vy
	Snk3LrN19VrCyqZ1ZDaeGst4JbHSqEZZewjNgzATfXcw8YmbyunbIh8km
	Ri0GPLsyAd3L/v2UNZarDIPybvdLI;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705442; x=1360241442;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=8KKPRAIzJava+CvUInqMw3gpEETvcU1cZTNxo504MR8=;
	b=DvL7qIN9CdbHhL0pJtwsudz5FXcLvxTn4LIN7LEBfqbhX+Aj500Ie28y
	ZxYyGv5fEZWtpoEHz+pvM4tMh8sAFJOBNM/GTYwl7mXWnfPN7ZbbhyL5e
	DSsBlpQ7iGKuaQ7x+GgvqEmzHtz4Zctvds9uXOYfyr3xyF7S5xCVE8BrN
	gzVDTxN+tkogzcHLkssbkXWQc+cjW07L7c38aIsfXFjiSyK9CxkIdtQVh
	h6JfQljkyVGnW9NMPTenf11HhwLoq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="85766197"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:41 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128391219"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:40 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 9C64B95B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:50:39 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 08 Feb 2012 13:50:39 +0100
Message-ID: <63278928.LZUtmFPle3@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] vpmu: Some vpmu cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

these 3 patches do some cleanups in the vpmu stuff.

patch 1/3: The 'struct vpmu_struct' contains an item 'flags' used to contain
           state bits.
           Macros are introduced to set/reset/check the bits and clear the item.

patch 2/3: Remove some some unnecessary spaces at the end of lines.

patch 3/3: The define PASSIVE_DOMAIN_ALLOCATED is renamed to
           VPMU_PASSIVE_DOMAIN_ALLOCATED to follow the scheme that the defines
           starts with the VPMU_ in front.

Thanks.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6z3-0006jL-Vd; Wed, 08 Feb 2012 12:50:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6z1-0006jD-NZ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:50:48 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328705441!14115442!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1OTI1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19444 invoked from network); 8 Feb 2012 12:50:41 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:50:41 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=a2MbAAaSUJ4AzeXVU9ENoTiIbjvKWDPuczlrpDvMCgKs09/RhLOq2NZd
	Ve1ce7jxRx0bxTOpyA2FfSHzZvcY4TSSn8TCnzBGmje6wuN1pAnZtd2hh
	zje/RriBJMXLdEkUiIlKU2icsyw3M4cpC+YYEcHYlQ/DY1xurKMQwg7Vy
	Snk3LrN19VrCyqZ1ZDaeGst4JbHSqEZZewjNgzATfXcw8YmbyunbIh8km
	Ri0GPLsyAd3L/v2UNZarDIPybvdLI;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705442; x=1360241442;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=8KKPRAIzJava+CvUInqMw3gpEETvcU1cZTNxo504MR8=;
	b=DvL7qIN9CdbHhL0pJtwsudz5FXcLvxTn4LIN7LEBfqbhX+Aj500Ie28y
	ZxYyGv5fEZWtpoEHz+pvM4tMh8sAFJOBNM/GTYwl7mXWnfPN7ZbbhyL5e
	DSsBlpQ7iGKuaQ7x+GgvqEmzHtz4Zctvds9uXOYfyr3xyF7S5xCVE8BrN
	gzVDTxN+tkogzcHLkssbkXWQc+cjW07L7c38aIsfXFjiSyK9CxkIdtQVh
	h6JfQljkyVGnW9NMPTenf11HhwLoq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="85766197"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:41 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128391219"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:40 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 9C64B95B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:50:39 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 08 Feb 2012 13:50:39 +0100
Message-ID: <63278928.LZUtmFPle3@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] vpmu: Some vpmu cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

these 3 patches do some cleanups in the vpmu stuff.

patch 1/3: The 'struct vpmu_struct' contains an item 'flags' used to contain
           state bits.
           Macros are introduced to set/reset/check the bits and clear the item.

patch 2/3: Remove some some unnecessary spaces at the end of lines.

patch 3/3: The define PASSIVE_DOMAIN_ALLOCATED is renamed to
           VPMU_PASSIVE_DOMAIN_ALLOCATED to follow the scheme that the defines
           starts with the VPMU_ in front.

Thanks.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6zA-0006jh-CM; Wed, 08 Feb 2012 12:50:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6z8-0006jY-QI
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:50:55 +0000
Received: from [85.158.139.83:16077] by server-8.bemta-5.messagelabs.com id
	2E/8B-08951-DAF623F4; Wed, 08 Feb 2012 12:50:53 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328705453!14210988!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxOTgwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4397 invoked from network); 8 Feb 2012 12:50:53 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:50:53 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=L4a4jDKxr4DefeYRppo/5d/M77p6NQkK7KsTYZJaUqxLExG5oLY5jKEW
	swK3L/Bc0PBRLBnIFzKA7WQB76mRqM8FEGOlKP4m/dnbrLKYlrSwfBVjW
	kQNcnIDJwEe1DwR60PxZZV2TvIWULDcMT63kh1PcGBjyux9vF6F/Z7Xf+
	RYsvl7NbEzUtgaNyCeNsYYE7sYzHX/PrIIqs8pfGBJfOSgbhqQ/XX1sNA
	4Ka6PslCdWy+Y14hipxlzTeJ302l0;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705453; x=1360241453;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=GMDGHnPPS+NXLi466B/CxpHc9Uew1b5ThaQvgYgyQmk=;
	b=VcvZ5enr7DVwy1MoB14v8ZQ+tunvOkwfQ15//VI9KDCKiVxR6qQ48vk4
	8ebt/G2u/1Cn++TaIti+QGUkNMb0gqL0I+/7haOR6sht1Lrx+zrED1VDK
	qfp6yeElDYW/2augm1xR6n9bTPbF1++8zQIWMpbS7Ur1ZoZY7sl0xDv6F
	Xtm6LblqEGO6LkEJG5FnVX8tq5tJ8HSwUTcbRC2JBmOTlC8TNOzRFTmnD
	4n7n5/vEztUJOB/FA1m/RkWK3OHJ0;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="101195005"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:53 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128391245"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:52 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 90B7195B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:50:52 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 13:50:52 +0100
Message-ID: <1781213.7JQf0aGsKI@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] vpmu: Use macros to access struct
	vpmu_struct.flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 xen/arch/x86/hvm/svm/vpmu.c           |  30 +++++++++++++++---------------
 xen/arch/x86/hvm/vmx/vpmu_core2.c     |  32 ++++++++++++++++----------------
 xen/arch/x86/hvm/vpmu.c               |   4 ++--
 xen/arch/x86/oprofile/nmi_int.c       |   4 ++--
 xen/arch/x86/oprofile/op_model_ppro.c |  10 +++++-----
 xen/include/asm-x86/hvm/vpmu.h        |   6 ++++++
 6 files changed, 46 insertions(+), 40 deletions(-)

This patch introduces some macros realising the access to the item 'flags'
in the struct vpmu_struct (see xen/include/asm-x86/hvm/vpmu.h).
Only bits within 'flags' are set/reset/checked.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


diff -r eae25241d571 xen/arch/x86/hvm/svm/vpmu.c
--- a/xen/arch/x86/hvm/svm/vpmu.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vpmu.c	Wed Feb 08 11:41:48 2012 +0100
@@ -188,8 +188,8 @@ static void amd_vpmu_restore(struct vcpu
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt = vpmu->context;
 
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_RUNNING)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_RUNNING)) )
         return;
 
     context_restore(v);
@@ -214,8 +214,8 @@ static void amd_vpmu_save(struct vcpu *v
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct amd_vpmu_context *ctx = vpmu->context;
 
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_RUNNING)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_RUNNING)) )
         return;
 
     context_save(v);
@@ -261,20 +261,20 @@ static int amd_vpmu_do_wrmsr(unsigned in
 
     /* check if the first counter is enabled */
     if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
-        is_pmu_enabled(msr_content) && !(vpmu->flags & VPMU_RUNNING) )
+        is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
             return 1;
-        vpmu->flags |= VPMU_RUNNING;
+        vpmu_set(vpmu, VPMU_RUNNING);
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
     }
 
     /* stop saving & restore if guest stops first counter */
-    if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) && 
-        (is_pmu_enabled(msr_content) == 0) && (vpmu->flags & VPMU_RUNNING) )
+    if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+        (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-        vpmu->flags &= ~VPMU_RUNNING;
+        vpmu_reset(vpmu, VPMU_RUNNING);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
 
@@ -298,7 +298,7 @@ static void amd_vpmu_initialise(struct v
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
 
-    if ( vpmu->flags & VPMU_CONTEXT_ALLOCATED )
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
     if ( counters == NULL )
@@ -333,22 +333,22 @@ static void amd_vpmu_initialise(struct v
     }
 
     vpmu->context = (void *)ctxt;
-    vpmu->flags |= VPMU_CONTEXT_ALLOCATED;
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !(vpmu->flags & VPMU_CONTEXT_ALLOCATED) )
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
     xfree(vpmu->context);
-    vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
+    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
 
-    if ( vpmu->flags & VPMU_RUNNING )
+    if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
-        vpmu->flags &= ~VPMU_RUNNING;
+        vpmu_reset(vpmu, VPMU_RUNNING);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
 }
diff -r eae25241d571 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 08 11:41:48 2012 +0100
@@ -266,17 +266,17 @@ static void core2_vpmu_save(struct vcpu 
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_CONTEXT_LOADED)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)) )
         return;
 
     __core2_vpmu_save(v);
 
     /* Unset PMU MSR bitmap to trap lazy load. */
-    if ( !(vpmu->flags & VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
 
-    vpmu->flags &= ~VPMU_CONTEXT_LOADED;
+    vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
     return;
 }
 
@@ -303,11 +303,11 @@ static void core2_vpmu_load(struct vcpu 
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
     /* Only when PMU is counting, we load PMU context immediately. */
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_RUNNING)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_RUNNING)) )
         return;
     __core2_vpmu_load(v);
-    vpmu->flags |= VPMU_CONTEXT_LOADED;
+    vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 }
 
 static int core2_vpmu_alloc_resource(struct vcpu *v)
@@ -373,17 +373,17 @@ static int core2_vpmu_msr_common_check(u
     if ( !is_core2_vpmu_msr(msr_index, type, index) )
         return 0;
 
-    if ( unlikely(!(vpmu->flags & VPMU_CONTEXT_ALLOCATED)) &&
+    if ( unlikely(!vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED)) &&
 	 (vpmu->context != NULL ||
 	  !core2_vpmu_alloc_resource(current)) )
         return 0;
-    vpmu->flags |= VPMU_CONTEXT_ALLOCATED;
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 
     /* Do the lazy load staff. */
-    if ( !(vpmu->flags & VPMU_CONTEXT_LOADED) )
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
     {
         __core2_vpmu_load(current);
-        vpmu->flags |= VPMU_CONTEXT_LOADED;
+        vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         if ( cpu_has_vmx_msr_bitmap )
             core2_vpmu_set_msr_bitmap(current->arch.hvm_vmx.msr_bitmap);
     }
@@ -467,12 +467,12 @@ static int core2_vpmu_do_wrmsr(unsigned 
     for ( i = 0; i < core2_get_pmc_count(); i++ )
         pmu_enable |= core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i];
     if ( pmu_enable )
-        vpmu->flags |= VPMU_RUNNING;
+        vpmu_set(vpmu, VPMU_RUNNING);
     else
-        vpmu->flags &= ~VPMU_RUNNING;
+        vpmu_reset(vpmu, VPMU_RUNNING);
 
     /* Setup LVTPC in local apic */
-    if ( vpmu->flags & VPMU_RUNNING &&
+    if ( vpmu_is_set(vpmu, VPMU_RUNNING) &&
          is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
         apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
     else
@@ -588,14 +588,14 @@ static void core2_vpmu_destroy(struct vc
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
 
-    if ( !(vpmu->flags & VPMU_CONTEXT_ALLOCATED) )
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
     xfree(core2_vpmu_cxt->pmu_enable);
     xfree(vpmu->context);
     if ( cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
     release_pmu_ownship(PMU_OWNER_HVM);
-    vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
+    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
 }
 
 struct arch_vpmu_ops core2_vpmu_ops = {
diff -r eae25241d571 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Wed Feb 08 11:41:48 2012 +0100
@@ -86,7 +86,7 @@ void vpmu_initialise(struct vcpu *v)
     if ( !opt_vpmu_enabled )
         return;
 
-    if ( vpmu->flags & VPMU_CONTEXT_ALLOCATED )
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
 
     switch ( vendor )
@@ -110,7 +110,7 @@ void vpmu_initialise(struct vcpu *v)
 
     if ( vpmu->arch_vpmu_ops != NULL )
     {
-        vpmu->flags = 0;
+        vpmu_clear(vpmu);
         vpmu->context = NULL;
         vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
     }
diff -r eae25241d571 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 11:41:48 2012 +0100
@@ -47,7 +47,7 @@ static int passive_domain_msr_op_checks(
 	if ( !model->is_arch_pmu_msr(msr, typep, indexp) )
 		return 0;
 
-	if ( !(vpmu->flags & PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
 		if ( ! model->allocated_msr(current) )
 			return 0;
 	return 1;
@@ -78,7 +78,7 @@ int passive_domain_do_wrmsr(unsigned int
 void passive_domain_destroy(struct vcpu *v)
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
-	if ( vpmu->flags & PASSIVE_DOMAIN_ALLOCATED )
+	if ( vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
 		model->free_msr(v);
 }
 
diff -r eae25241d571 xen/arch/x86/oprofile/op_model_ppro.c
--- a/xen/arch/x86/oprofile/op_model_ppro.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 11:41:48 2012 +0100
@@ -143,7 +143,7 @@ static int ppro_check_ctrs(unsigned int 
 			xenoprof_log_event(current, regs, eip, mode, i);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
 			if ( is_passive(current->domain) && (mode != 2) && 
-				(vcpu_vpmu(current)->flags & PASSIVE_DOMAIN_ALLOCATED) ) 
+				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) ) 
 			{
 				if ( IS_ACTIVE(msrs_content[i].control) )
 				{
@@ -230,8 +230,8 @@ static int ppro_allocate_msr(struct vcpu
 	if ( !msr_content )
 		goto out;
 	vpmu->context = (void *)msr_content;
-	vpmu->flags = 0;
-	vpmu->flags |= PASSIVE_DOMAIN_ALLOCATED;
+	vpmu_clear(vpmu);
+	vpmu_set(vpmu, PASSIVE_DOMAIN_ALLOCATED);
 	return 1;
 out:
         gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile is "
@@ -244,10 +244,10 @@ static void ppro_free_msr(struct vcpu *v
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-	if ( !(vpmu->flags & PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
 		return;
 	xfree(vpmu->context);
-	vpmu->flags &= ~PASSIVE_DOMAIN_ALLOCATED;
+	vpmu_reset(vpmu, PASSIVE_DOMAIN_ALLOCATED);
 }
 
 static void ppro_load_msr(struct vcpu *v, int type, int index, u64 *msr_content)
diff -r eae25241d571 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 08 11:41:48 2012 +0100
@@ -69,6 +69,12 @@ struct vpmu_struct {
 #define VPMU_CONTEXT_LOADED                 0x2
 #define VPMU_RUNNING                        0x4
 #define PASSIVE_DOMAIN_ALLOCATED	    0x8
+
+#define vpmu_set(_vpmu, _x)    ((_vpmu)->flags |= (_x))
+#define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))
+#define vpmu_is_set(_vpmu, _x) ((_vpmu)->flags & (_x))
+#define vpmu_clear(_vpmu)      ((_vpmu)->flags = 0)
+
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 int vpmu_do_interrupt(struct cpu_user_regs *regs);


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6zA-0006jh-CM; Wed, 08 Feb 2012 12:50:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6z8-0006jY-QI
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:50:55 +0000
Received: from [85.158.139.83:16077] by server-8.bemta-5.messagelabs.com id
	2E/8B-08951-DAF623F4; Wed, 08 Feb 2012 12:50:53 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328705453!14210988!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxOTgwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4397 invoked from network); 8 Feb 2012 12:50:53 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:50:53 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=L4a4jDKxr4DefeYRppo/5d/M77p6NQkK7KsTYZJaUqxLExG5oLY5jKEW
	swK3L/Bc0PBRLBnIFzKA7WQB76mRqM8FEGOlKP4m/dnbrLKYlrSwfBVjW
	kQNcnIDJwEe1DwR60PxZZV2TvIWULDcMT63kh1PcGBjyux9vF6F/Z7Xf+
	RYsvl7NbEzUtgaNyCeNsYYE7sYzHX/PrIIqs8pfGBJfOSgbhqQ/XX1sNA
	4Ka6PslCdWy+Y14hipxlzTeJ302l0;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705453; x=1360241453;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=GMDGHnPPS+NXLi466B/CxpHc9Uew1b5ThaQvgYgyQmk=;
	b=VcvZ5enr7DVwy1MoB14v8ZQ+tunvOkwfQ15//VI9KDCKiVxR6qQ48vk4
	8ebt/G2u/1Cn++TaIti+QGUkNMb0gqL0I+/7haOR6sht1Lrx+zrED1VDK
	qfp6yeElDYW/2augm1xR6n9bTPbF1++8zQIWMpbS7Ur1ZoZY7sl0xDv6F
	Xtm6LblqEGO6LkEJG5FnVX8tq5tJ8HSwUTcbRC2JBmOTlC8TNOzRFTmnD
	4n7n5/vEztUJOB/FA1m/RkWK3OHJ0;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="101195005"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:53 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128391245"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 08 Feb 2012 13:50:52 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 90B7195B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:50:52 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 13:50:52 +0100
Message-ID: <1781213.7JQf0aGsKI@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] vpmu: Use macros to access struct
	vpmu_struct.flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 xen/arch/x86/hvm/svm/vpmu.c           |  30 +++++++++++++++---------------
 xen/arch/x86/hvm/vmx/vpmu_core2.c     |  32 ++++++++++++++++----------------
 xen/arch/x86/hvm/vpmu.c               |   4 ++--
 xen/arch/x86/oprofile/nmi_int.c       |   4 ++--
 xen/arch/x86/oprofile/op_model_ppro.c |  10 +++++-----
 xen/include/asm-x86/hvm/vpmu.h        |   6 ++++++
 6 files changed, 46 insertions(+), 40 deletions(-)

This patch introduces some macros realising the access to the item 'flags'
in the struct vpmu_struct (see xen/include/asm-x86/hvm/vpmu.h).
Only bits within 'flags' are set/reset/checked.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


diff -r eae25241d571 xen/arch/x86/hvm/svm/vpmu.c
--- a/xen/arch/x86/hvm/svm/vpmu.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vpmu.c	Wed Feb 08 11:41:48 2012 +0100
@@ -188,8 +188,8 @@ static void amd_vpmu_restore(struct vcpu
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt = vpmu->context;
 
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_RUNNING)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_RUNNING)) )
         return;
 
     context_restore(v);
@@ -214,8 +214,8 @@ static void amd_vpmu_save(struct vcpu *v
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct amd_vpmu_context *ctx = vpmu->context;
 
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_RUNNING)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_RUNNING)) )
         return;
 
     context_save(v);
@@ -261,20 +261,20 @@ static int amd_vpmu_do_wrmsr(unsigned in
 
     /* check if the first counter is enabled */
     if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
-        is_pmu_enabled(msr_content) && !(vpmu->flags & VPMU_RUNNING) )
+        is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
             return 1;
-        vpmu->flags |= VPMU_RUNNING;
+        vpmu_set(vpmu, VPMU_RUNNING);
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
     }
 
     /* stop saving & restore if guest stops first counter */
-    if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) && 
-        (is_pmu_enabled(msr_content) == 0) && (vpmu->flags & VPMU_RUNNING) )
+    if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+        (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
         apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-        vpmu->flags &= ~VPMU_RUNNING;
+        vpmu_reset(vpmu, VPMU_RUNNING);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
 
@@ -298,7 +298,7 @@ static void amd_vpmu_initialise(struct v
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
 
-    if ( vpmu->flags & VPMU_CONTEXT_ALLOCATED )
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
     if ( counters == NULL )
@@ -333,22 +333,22 @@ static void amd_vpmu_initialise(struct v
     }
 
     vpmu->context = (void *)ctxt;
-    vpmu->flags |= VPMU_CONTEXT_ALLOCATED;
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !(vpmu->flags & VPMU_CONTEXT_ALLOCATED) )
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
 
     xfree(vpmu->context);
-    vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
+    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
 
-    if ( vpmu->flags & VPMU_RUNNING )
+    if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
     {
-        vpmu->flags &= ~VPMU_RUNNING;
+        vpmu_reset(vpmu, VPMU_RUNNING);
         release_pmu_ownship(PMU_OWNER_HVM);
     }
 }
diff -r eae25241d571 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 08 11:41:48 2012 +0100
@@ -266,17 +266,17 @@ static void core2_vpmu_save(struct vcpu 
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_CONTEXT_LOADED)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)) )
         return;
 
     __core2_vpmu_save(v);
 
     /* Unset PMU MSR bitmap to trap lazy load. */
-    if ( !(vpmu->flags & VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
+    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
 
-    vpmu->flags &= ~VPMU_CONTEXT_LOADED;
+    vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
     return;
 }
 
@@ -303,11 +303,11 @@ static void core2_vpmu_load(struct vcpu 
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
     /* Only when PMU is counting, we load PMU context immediately. */
-    if ( !((vpmu->flags & VPMU_CONTEXT_ALLOCATED) &&
-           (vpmu->flags & VPMU_RUNNING)) )
+    if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) &&
+           vpmu_is_set(vpmu, VPMU_RUNNING)) )
         return;
     __core2_vpmu_load(v);
-    vpmu->flags |= VPMU_CONTEXT_LOADED;
+    vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 }
 
 static int core2_vpmu_alloc_resource(struct vcpu *v)
@@ -373,17 +373,17 @@ static int core2_vpmu_msr_common_check(u
     if ( !is_core2_vpmu_msr(msr_index, type, index) )
         return 0;
 
-    if ( unlikely(!(vpmu->flags & VPMU_CONTEXT_ALLOCATED)) &&
+    if ( unlikely(!vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED)) &&
 	 (vpmu->context != NULL ||
 	  !core2_vpmu_alloc_resource(current)) )
         return 0;
-    vpmu->flags |= VPMU_CONTEXT_ALLOCATED;
+    vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
 
     /* Do the lazy load staff. */
-    if ( !(vpmu->flags & VPMU_CONTEXT_LOADED) )
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
     {
         __core2_vpmu_load(current);
-        vpmu->flags |= VPMU_CONTEXT_LOADED;
+        vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
         if ( cpu_has_vmx_msr_bitmap )
             core2_vpmu_set_msr_bitmap(current->arch.hvm_vmx.msr_bitmap);
     }
@@ -467,12 +467,12 @@ static int core2_vpmu_do_wrmsr(unsigned 
     for ( i = 0; i < core2_get_pmc_count(); i++ )
         pmu_enable |= core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i];
     if ( pmu_enable )
-        vpmu->flags |= VPMU_RUNNING;
+        vpmu_set(vpmu, VPMU_RUNNING);
     else
-        vpmu->flags &= ~VPMU_RUNNING;
+        vpmu_reset(vpmu, VPMU_RUNNING);
 
     /* Setup LVTPC in local apic */
-    if ( vpmu->flags & VPMU_RUNNING &&
+    if ( vpmu_is_set(vpmu, VPMU_RUNNING) &&
          is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
         apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
     else
@@ -588,14 +588,14 @@ static void core2_vpmu_destroy(struct vc
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct core2_vpmu_context *core2_vpmu_cxt = vpmu->context;
 
-    if ( !(vpmu->flags & VPMU_CONTEXT_ALLOCATED) )
+    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         return;
     xfree(core2_vpmu_cxt->pmu_enable);
     xfree(vpmu->context);
     if ( cpu_has_vmx_msr_bitmap )
         core2_vpmu_unset_msr_bitmap(v->arch.hvm_vmx.msr_bitmap);
     release_pmu_ownship(PMU_OWNER_HVM);
-    vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
+    vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
 }
 
 struct arch_vpmu_ops core2_vpmu_ops = {
diff -r eae25241d571 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Wed Feb 08 11:41:48 2012 +0100
@@ -86,7 +86,7 @@ void vpmu_initialise(struct vcpu *v)
     if ( !opt_vpmu_enabled )
         return;
 
-    if ( vpmu->flags & VPMU_CONTEXT_ALLOCATED )
+    if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
 
     switch ( vendor )
@@ -110,7 +110,7 @@ void vpmu_initialise(struct vcpu *v)
 
     if ( vpmu->arch_vpmu_ops != NULL )
     {
-        vpmu->flags = 0;
+        vpmu_clear(vpmu);
         vpmu->context = NULL;
         vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
     }
diff -r eae25241d571 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 11:41:48 2012 +0100
@@ -47,7 +47,7 @@ static int passive_domain_msr_op_checks(
 	if ( !model->is_arch_pmu_msr(msr, typep, indexp) )
 		return 0;
 
-	if ( !(vpmu->flags & PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
 		if ( ! model->allocated_msr(current) )
 			return 0;
 	return 1;
@@ -78,7 +78,7 @@ int passive_domain_do_wrmsr(unsigned int
 void passive_domain_destroy(struct vcpu *v)
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
-	if ( vpmu->flags & PASSIVE_DOMAIN_ALLOCATED )
+	if ( vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
 		model->free_msr(v);
 }
 
diff -r eae25241d571 xen/arch/x86/oprofile/op_model_ppro.c
--- a/xen/arch/x86/oprofile/op_model_ppro.c	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 11:41:48 2012 +0100
@@ -143,7 +143,7 @@ static int ppro_check_ctrs(unsigned int 
 			xenoprof_log_event(current, regs, eip, mode, i);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
 			if ( is_passive(current->domain) && (mode != 2) && 
-				(vcpu_vpmu(current)->flags & PASSIVE_DOMAIN_ALLOCATED) ) 
+				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) ) 
 			{
 				if ( IS_ACTIVE(msrs_content[i].control) )
 				{
@@ -230,8 +230,8 @@ static int ppro_allocate_msr(struct vcpu
 	if ( !msr_content )
 		goto out;
 	vpmu->context = (void *)msr_content;
-	vpmu->flags = 0;
-	vpmu->flags |= PASSIVE_DOMAIN_ALLOCATED;
+	vpmu_clear(vpmu);
+	vpmu_set(vpmu, PASSIVE_DOMAIN_ALLOCATED);
 	return 1;
 out:
         gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile is "
@@ -244,10 +244,10 @@ static void ppro_free_msr(struct vcpu *v
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-	if ( !(vpmu->flags & PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
 		return;
 	xfree(vpmu->context);
-	vpmu->flags &= ~PASSIVE_DOMAIN_ALLOCATED;
+	vpmu_reset(vpmu, PASSIVE_DOMAIN_ALLOCATED);
 }
 
 static void ppro_load_msr(struct vcpu *v, int type, int index, u64 *msr_content)
diff -r eae25241d571 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Tue Feb 07 15:05:19 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 08 11:41:48 2012 +0100
@@ -69,6 +69,12 @@ struct vpmu_struct {
 #define VPMU_CONTEXT_LOADED                 0x2
 #define VPMU_RUNNING                        0x4
 #define PASSIVE_DOMAIN_ALLOCATED	    0x8
+
+#define vpmu_set(_vpmu, _x)    ((_vpmu)->flags |= (_x))
+#define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))
+#define vpmu_is_set(_vpmu, _x) ((_vpmu)->flags & (_x))
+#define vpmu_clear(_vpmu)      ((_vpmu)->flags = 0)
+
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 int vpmu_do_interrupt(struct cpu_user_regs *regs);


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12: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.xensource.com>)
	id 1Rv6zQ-0006lO-Qg; Wed, 08 Feb 2012 12:51:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6zP-0006ki-AW
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:51:11 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328705465!12307540!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1OTI1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19072 invoked from network); 8 Feb 2012 12:51:05 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:51:05 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=ux3l6PNT2ATkdTvT7EXjQF5vDb4sxuPRBx7ghHZVU2akkFMlMy1Q2IRl
	JNzFU7m3uhVcQubsdiPSmVFrT8+lZg2g1O0AH56/TbADlO14pEMixtukB
	FKpXP05g5R4Up/P3uZf76RR9pQiAHNgzd6ByIoS6H27LE9dhcK7yz7VTf
	AwFqmc+s2rhiSSRKzWamTWsRG6C6okDVuXnBInf4YKVhIGm9ufFTK/H5X
	P5QyVBGc8XiaoNAD5LSE0G2lS3Gig;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705465; x=1360241465;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=2XDsAsL0mMo/nzs4d19iZGY+tleU1C+NwASwgmjUSTc=;
	b=EIwoyW8ZJPs/fm5P7BOKPJalL2fqA0y5RQE9hYgKewFgYhu7tnnSrUQZ
	okdgCKr+uQdq30VnOIbmQ5bqArAu9B3j9W+6KSFrtOQlj5ynNw3/gLI8H
	E6axDuF4CDkz46vWcdcN6zCFMpzxJAIw8rWQ4iOj1chuB87hhOo059afy
	XptXeMC513NL8qXpjJgGc0ZERXq0aLyKTvy9nHYqFIkXb6TJ8osIvpGKW
	wFhMZvAKkthP7k9/bbHXpJn1LwlSk;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="85766247"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:05 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128701206"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:05 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id EA44595B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:51:04 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 13:51:04 +0100
Message-ID: <5343407.r6m1UrJMAt@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] vpmu: Remove unnecessary spaces at the end
	of lines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 xen/arch/x86/oprofile/nmi_int.c       |  40 +++++++++++++++++-----------------
 xen/arch/x86/oprofile/op_model_ppro.c |  28 ++++++++++++------------
 2 files changed, 34 insertions(+), 34 deletions(-)

This patch removes some unnecessary spaces at the end of lines.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


diff -r f7fce232f7dc xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 11:41:48 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:26:01 2012 +0100
@@ -24,10 +24,10 @@
 #include <asm/apic.h>
 #include <asm/regs.h>
 #include <asm/current.h>
- 
+
 #include "op_counter.h"
 #include "op_x86_model.h"
- 
+
 struct op_counter_config counter_config[OP_MAX_COUNTER];
 struct op_ibs_config ibs_config;
 
@@ -91,12 +91,12 @@ static int nmi_callback(struct cpu_user_
 	if ( ovf && is_active(current->domain) && !xen_mode )
 		send_guest_vcpu_virq(current, VIRQ_XENOPROF);
 
-	if ( ovf == 2 ) 
+	if ( ovf == 2 )
                 current->nmi_pending = 1;
 	return 1;
 }
- 
- 
+
+
 static void nmi_cpu_save_registers(struct op_msrs *msrs)
 {
 	unsigned int const nr_ctrs = model->num_counters;
@@ -108,7 +108,7 @@ static void nmi_cpu_save_registers(struc
 	for (i = 0; i < nr_ctrs; ++i) {
 		rdmsrl(counters[i].addr, counters[i].value);
 	}
- 
+
 	for (i = 0; i < nr_ctrls; ++i) {
 		rdmsrl(controls[i].addr, controls[i].value);
 	}
@@ -195,7 +195,7 @@ int nmi_reserve_counters(void)
 	 * of msrs are distinct for save and setup operations
 	 */
 	on_each_cpu(nmi_save_registers, NULL, 1);
- 	return 0;
+	return 0;
 }
 
 int nmi_enable_virq(void)
@@ -208,7 +208,7 @@ int nmi_enable_virq(void)
 void nmi_disable_virq(void)
 {
 	unset_nmi_callback();
-} 
+}
 
 
 static void nmi_restore_registers(struct op_msrs * msrs)
@@ -222,12 +222,12 @@ static void nmi_restore_registers(struct
 	for (i = 0; i < nr_ctrls; ++i) {
 		wrmsrl(controls[i].addr, controls[i].value);
 	}
- 
+
 	for (i = 0; i < nr_ctrs; ++i) {
 		wrmsrl(counters[i].addr, counters[i].value);
 	}
 }
- 
+
 
 static void nmi_cpu_shutdown(void * dummy)
 {
@@ -236,7 +236,7 @@ static void nmi_cpu_shutdown(void * dumm
 	nmi_restore_registers(msrs);
 }
 
- 
+
 void nmi_release_counters(void)
 {
 	on_each_cpu(nmi_cpu_shutdown, NULL, 1);
@@ -244,7 +244,7 @@ void nmi_release_counters(void)
 	free_msrs();
 }
 
- 
+
 static void nmi_cpu_start(void * dummy)
 {
 	int cpu = smp_processor_id();
@@ -253,15 +253,15 @@ static void nmi_cpu_start(void * dummy)
 	apic_write(APIC_LVTPC, APIC_DM_NMI);
 	model->start(msrs);
 }
- 
+
 
 int nmi_start(void)
 {
 	on_each_cpu(nmi_cpu_start, NULL, 1);
 	return 0;
 }
- 
- 
+
+
 static void nmi_cpu_stop(void * dummy)
 {
 	unsigned int v;
@@ -285,8 +285,8 @@ static void nmi_cpu_stop(void * dummy)
 	apic_write(APIC_LVTPC, saved_lvtpc[cpu]);
 	apic_write(APIC_LVTERR, v);
 }
- 
- 
+
+
 void nmi_stop(void)
 {
 	on_each_cpu(nmi_cpu_stop, NULL, 1);
@@ -294,7 +294,7 @@ void nmi_stop(void)
 
 
 static int __init p4_init(char ** cpu_type)
-{ 
+{
 	__u8 cpu_model = current_cpu_data.x86_model;
 
 	if ((cpu_model > 6) || (cpu_model == 5)) {
@@ -402,7 +402,7 @@ static int __init nmi_init(void)
 	__u8 vendor = current_cpu_data.x86_vendor;
 	__u8 family = current_cpu_data.x86;
 	__u8 _model = current_cpu_data.x86_model;
- 
+
 	if (!cpu_has_apic) {
 		printk("xenoprof: Initialization failed. No APIC\n");
 		return -ENODEV;
@@ -451,7 +451,7 @@ static int __init nmi_init(void)
                                 break;
 			}
 			break;
- 
+
 		case X86_VENDOR_INTEL:
 			switch (family) {
 				/* Pentium IV */
diff -r f7fce232f7dc xen/arch/x86/oprofile/op_model_ppro.c
--- a/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 11:41:48 2012 +0100
+++ b/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 12:26:01 2012 +0100
@@ -21,7 +21,7 @@
 #include <asm/current.h>
 #include <asm/hvm/vpmu.h>
 #include <asm/hvm/vmx/vpmu_core2.h>
- 
+
 #include "op_x86_model.h"
 #include "op_counter.h"
 
@@ -42,7 +42,7 @@ union cpuid10_eax {
 static int num_counters = 2;
 static int counter_width = 32;
 
-#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<(counter_width-1)))) 
+#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<(counter_width-1))))
 
 #define CTRL_READ(msr_content,msrs,c) do {rdmsrl((msrs->controls[(c)].addr), (msr_content));} while (0)
 #define CTRL_WRITE(msr_content,msrs,c) do {wrmsrl((msrs->controls[(c)].addr), (msr_content));} while (0)
@@ -54,11 +54,11 @@ static int counter_width = 32;
 #define CTRL_SET_KERN(val,k) (val |= ((k & 1ULL) << 17))
 #define CTRL_SET_UM(val, m) (val |= (m << 8))
 #define CTRL_SET_EVENT(val, e) (val |= e)
-#define IS_ACTIVE(val) (val & (1ULL << 22) )  
+#define IS_ACTIVE(val) (val & (1ULL << 22) )
 #define IS_ENABLE(val) (val & (1ULL << 20) )
 static unsigned long reset_value[OP_MAX_COUNTER];
 int ppro_has_global_ctrl = 0;
- 
+
 static void ppro_fill_in_addresses(struct op_msrs * const msrs)
 {
 	int i;
@@ -74,7 +74,7 @@ static void ppro_setup_ctrs(struct op_ms
 {
 	uint64_t msr_content;
 	int i;
-	
+
 	if (cpu_has_arch_perfmon) {
 		union cpuid10_eax eax;
 		eax.full = cpuid_eax(0xa);
@@ -98,7 +98,7 @@ static void ppro_setup_ctrs(struct op_ms
 		CTRL_CLEAR(msr_content);
 		CTRL_WRITE(msr_content, msrs, i);
 	}
-	
+
 	/* avoid a false detection of ctr overflows in NMI handler */
 	for (i = 0; i < num_counters; ++i)
 		wrmsrl(msrs->counters[i].addr, ~0x0ULL);
@@ -142,8 +142,8 @@ static int ppro_check_ctrs(unsigned int 
 		if (CTR_OVERFLOWED(val)) {
 			xenoprof_log_event(current, regs, eip, mode, i);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
-			if ( is_passive(current->domain) && (mode != 2) && 
-				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) ) 
+			if ( is_passive(current->domain) && (mode != 2) &&
+				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) )
 			{
 				if ( IS_ACTIVE(msrs_content[i].control) )
 				{
@@ -164,7 +164,7 @@ static int ppro_check_ctrs(unsigned int 
 	return ovf;
 }
 
- 
+
 static void ppro_start(struct op_msrs const * const msrs)
 {
 	uint64_t msr_content;
@@ -206,7 +206,7 @@ static int ppro_is_arch_pmu_msr(u64 msr_
 	if ( (msr_index >= MSR_IA32_PERFCTR0) &&
             (msr_index < (MSR_IA32_PERFCTR0 + num_counters)) )
 	{
-        	*type = MSR_TYPE_ARCH_COUNTER;
+		*type = MSR_TYPE_ARCH_COUNTER;
 		*index = msr_index - MSR_IA32_PERFCTR0;
 		return 1;
         }
@@ -237,7 +237,7 @@ out:
         gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile is "
                  "unavailable on domain %d vcpu %d.\n",
                  v->vcpu_id, v->domain->domain_id);
-        return 0;	
+        return 0;
 }
 
 static void ppro_free_msr(struct vcpu *v)
@@ -261,13 +261,13 @@ static void ppro_load_msr(struct vcpu *v
 	case MSR_TYPE_ARCH_CTRL:
 		*msr_content = msrs[index].control;
 		break;
-	}	
+	}
 }
 
 static void ppro_save_msr(struct vcpu *v, int type, int index, u64 msr_content)
 {
 	struct arch_msr_pair *msrs = vcpu_vpmu(v)->context;
-	
+
 	switch ( type )
 	{
 	case MSR_TYPE_ARCH_COUNTER:
@@ -276,7 +276,7 @@ static void ppro_save_msr(struct vcpu *v
 	case MSR_TYPE_ARCH_CTRL:
 		msrs[index].control = msr_content;
 		break;
-	}	
+	}
 }
 
 /*

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12: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.xensource.com>)
	id 1Rv6zQ-0006lO-Qg; Wed, 08 Feb 2012 12:51:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6zP-0006ki-AW
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:51:11 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328705465!12307540!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1OTI1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19072 invoked from network); 8 Feb 2012 12:51:05 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:51:05 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=ux3l6PNT2ATkdTvT7EXjQF5vDb4sxuPRBx7ghHZVU2akkFMlMy1Q2IRl
	JNzFU7m3uhVcQubsdiPSmVFrT8+lZg2g1O0AH56/TbADlO14pEMixtukB
	FKpXP05g5R4Up/P3uZf76RR9pQiAHNgzd6ByIoS6H27LE9dhcK7yz7VTf
	AwFqmc+s2rhiSSRKzWamTWsRG6C6okDVuXnBInf4YKVhIGm9ufFTK/H5X
	P5QyVBGc8XiaoNAD5LSE0G2lS3Gig;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705465; x=1360241465;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=2XDsAsL0mMo/nzs4d19iZGY+tleU1C+NwASwgmjUSTc=;
	b=EIwoyW8ZJPs/fm5P7BOKPJalL2fqA0y5RQE9hYgKewFgYhu7tnnSrUQZ
	okdgCKr+uQdq30VnOIbmQ5bqArAu9B3j9W+6KSFrtOQlj5ynNw3/gLI8H
	E6axDuF4CDkz46vWcdcN6zCFMpzxJAIw8rWQ4iOj1chuB87hhOo059afy
	XptXeMC513NL8qXpjJgGc0ZERXq0aLyKTvy9nHYqFIkXb6TJ8osIvpGKW
	wFhMZvAKkthP7k9/bbHXpJn1LwlSk;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="85766247"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:05 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128701206"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:05 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id EA44595B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:51:04 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 13:51:04 +0100
Message-ID: <5343407.r6m1UrJMAt@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] vpmu: Remove unnecessary spaces at the end
	of lines
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 xen/arch/x86/oprofile/nmi_int.c       |  40 +++++++++++++++++-----------------
 xen/arch/x86/oprofile/op_model_ppro.c |  28 ++++++++++++------------
 2 files changed, 34 insertions(+), 34 deletions(-)

This patch removes some unnecessary spaces at the end of lines.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


diff -r f7fce232f7dc xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 11:41:48 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:26:01 2012 +0100
@@ -24,10 +24,10 @@
 #include <asm/apic.h>
 #include <asm/regs.h>
 #include <asm/current.h>
- 
+
 #include "op_counter.h"
 #include "op_x86_model.h"
- 
+
 struct op_counter_config counter_config[OP_MAX_COUNTER];
 struct op_ibs_config ibs_config;
 
@@ -91,12 +91,12 @@ static int nmi_callback(struct cpu_user_
 	if ( ovf && is_active(current->domain) && !xen_mode )
 		send_guest_vcpu_virq(current, VIRQ_XENOPROF);
 
-	if ( ovf == 2 ) 
+	if ( ovf == 2 )
                 current->nmi_pending = 1;
 	return 1;
 }
- 
- 
+
+
 static void nmi_cpu_save_registers(struct op_msrs *msrs)
 {
 	unsigned int const nr_ctrs = model->num_counters;
@@ -108,7 +108,7 @@ static void nmi_cpu_save_registers(struc
 	for (i = 0; i < nr_ctrs; ++i) {
 		rdmsrl(counters[i].addr, counters[i].value);
 	}
- 
+
 	for (i = 0; i < nr_ctrls; ++i) {
 		rdmsrl(controls[i].addr, controls[i].value);
 	}
@@ -195,7 +195,7 @@ int nmi_reserve_counters(void)
 	 * of msrs are distinct for save and setup operations
 	 */
 	on_each_cpu(nmi_save_registers, NULL, 1);
- 	return 0;
+	return 0;
 }
 
 int nmi_enable_virq(void)
@@ -208,7 +208,7 @@ int nmi_enable_virq(void)
 void nmi_disable_virq(void)
 {
 	unset_nmi_callback();
-} 
+}
 
 
 static void nmi_restore_registers(struct op_msrs * msrs)
@@ -222,12 +222,12 @@ static void nmi_restore_registers(struct
 	for (i = 0; i < nr_ctrls; ++i) {
 		wrmsrl(controls[i].addr, controls[i].value);
 	}
- 
+
 	for (i = 0; i < nr_ctrs; ++i) {
 		wrmsrl(counters[i].addr, counters[i].value);
 	}
 }
- 
+
 
 static void nmi_cpu_shutdown(void * dummy)
 {
@@ -236,7 +236,7 @@ static void nmi_cpu_shutdown(void * dumm
 	nmi_restore_registers(msrs);
 }
 
- 
+
 void nmi_release_counters(void)
 {
 	on_each_cpu(nmi_cpu_shutdown, NULL, 1);
@@ -244,7 +244,7 @@ void nmi_release_counters(void)
 	free_msrs();
 }
 
- 
+
 static void nmi_cpu_start(void * dummy)
 {
 	int cpu = smp_processor_id();
@@ -253,15 +253,15 @@ static void nmi_cpu_start(void * dummy)
 	apic_write(APIC_LVTPC, APIC_DM_NMI);
 	model->start(msrs);
 }
- 
+
 
 int nmi_start(void)
 {
 	on_each_cpu(nmi_cpu_start, NULL, 1);
 	return 0;
 }
- 
- 
+
+
 static void nmi_cpu_stop(void * dummy)
 {
 	unsigned int v;
@@ -285,8 +285,8 @@ static void nmi_cpu_stop(void * dummy)
 	apic_write(APIC_LVTPC, saved_lvtpc[cpu]);
 	apic_write(APIC_LVTERR, v);
 }
- 
- 
+
+
 void nmi_stop(void)
 {
 	on_each_cpu(nmi_cpu_stop, NULL, 1);
@@ -294,7 +294,7 @@ void nmi_stop(void)
 
 
 static int __init p4_init(char ** cpu_type)
-{ 
+{
 	__u8 cpu_model = current_cpu_data.x86_model;
 
 	if ((cpu_model > 6) || (cpu_model == 5)) {
@@ -402,7 +402,7 @@ static int __init nmi_init(void)
 	__u8 vendor = current_cpu_data.x86_vendor;
 	__u8 family = current_cpu_data.x86;
 	__u8 _model = current_cpu_data.x86_model;
- 
+
 	if (!cpu_has_apic) {
 		printk("xenoprof: Initialization failed. No APIC\n");
 		return -ENODEV;
@@ -451,7 +451,7 @@ static int __init nmi_init(void)
                                 break;
 			}
 			break;
- 
+
 		case X86_VENDOR_INTEL:
 			switch (family) {
 				/* Pentium IV */
diff -r f7fce232f7dc xen/arch/x86/oprofile/op_model_ppro.c
--- a/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 11:41:48 2012 +0100
+++ b/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 12:26:01 2012 +0100
@@ -21,7 +21,7 @@
 #include <asm/current.h>
 #include <asm/hvm/vpmu.h>
 #include <asm/hvm/vmx/vpmu_core2.h>
- 
+
 #include "op_x86_model.h"
 #include "op_counter.h"
 
@@ -42,7 +42,7 @@ union cpuid10_eax {
 static int num_counters = 2;
 static int counter_width = 32;
 
-#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<(counter_width-1)))) 
+#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<(counter_width-1))))
 
 #define CTRL_READ(msr_content,msrs,c) do {rdmsrl((msrs->controls[(c)].addr), (msr_content));} while (0)
 #define CTRL_WRITE(msr_content,msrs,c) do {wrmsrl((msrs->controls[(c)].addr), (msr_content));} while (0)
@@ -54,11 +54,11 @@ static int counter_width = 32;
 #define CTRL_SET_KERN(val,k) (val |= ((k & 1ULL) << 17))
 #define CTRL_SET_UM(val, m) (val |= (m << 8))
 #define CTRL_SET_EVENT(val, e) (val |= e)
-#define IS_ACTIVE(val) (val & (1ULL << 22) )  
+#define IS_ACTIVE(val) (val & (1ULL << 22) )
 #define IS_ENABLE(val) (val & (1ULL << 20) )
 static unsigned long reset_value[OP_MAX_COUNTER];
 int ppro_has_global_ctrl = 0;
- 
+
 static void ppro_fill_in_addresses(struct op_msrs * const msrs)
 {
 	int i;
@@ -74,7 +74,7 @@ static void ppro_setup_ctrs(struct op_ms
 {
 	uint64_t msr_content;
 	int i;
-	
+
 	if (cpu_has_arch_perfmon) {
 		union cpuid10_eax eax;
 		eax.full = cpuid_eax(0xa);
@@ -98,7 +98,7 @@ static void ppro_setup_ctrs(struct op_ms
 		CTRL_CLEAR(msr_content);
 		CTRL_WRITE(msr_content, msrs, i);
 	}
-	
+
 	/* avoid a false detection of ctr overflows in NMI handler */
 	for (i = 0; i < num_counters; ++i)
 		wrmsrl(msrs->counters[i].addr, ~0x0ULL);
@@ -142,8 +142,8 @@ static int ppro_check_ctrs(unsigned int 
 		if (CTR_OVERFLOWED(val)) {
 			xenoprof_log_event(current, regs, eip, mode, i);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
-			if ( is_passive(current->domain) && (mode != 2) && 
-				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) ) 
+			if ( is_passive(current->domain) && (mode != 2) &&
+				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) )
 			{
 				if ( IS_ACTIVE(msrs_content[i].control) )
 				{
@@ -164,7 +164,7 @@ static int ppro_check_ctrs(unsigned int 
 	return ovf;
 }
 
- 
+
 static void ppro_start(struct op_msrs const * const msrs)
 {
 	uint64_t msr_content;
@@ -206,7 +206,7 @@ static int ppro_is_arch_pmu_msr(u64 msr_
 	if ( (msr_index >= MSR_IA32_PERFCTR0) &&
             (msr_index < (MSR_IA32_PERFCTR0 + num_counters)) )
 	{
-        	*type = MSR_TYPE_ARCH_COUNTER;
+		*type = MSR_TYPE_ARCH_COUNTER;
 		*index = msr_index - MSR_IA32_PERFCTR0;
 		return 1;
         }
@@ -237,7 +237,7 @@ out:
         gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile is "
                  "unavailable on domain %d vcpu %d.\n",
                  v->vcpu_id, v->domain->domain_id);
-        return 0;	
+        return 0;
 }
 
 static void ppro_free_msr(struct vcpu *v)
@@ -261,13 +261,13 @@ static void ppro_load_msr(struct vcpu *v
 	case MSR_TYPE_ARCH_CTRL:
 		*msr_content = msrs[index].control;
 		break;
-	}	
+	}
 }
 
 static void ppro_save_msr(struct vcpu *v, int type, int index, u64 msr_content)
 {
 	struct arch_msr_pair *msrs = vcpu_vpmu(v)->context;
-	
+
 	switch ( type )
 	{
 	case MSR_TYPE_ARCH_COUNTER:
@@ -276,7 +276,7 @@ static void ppro_save_msr(struct vcpu *v
 	case MSR_TYPE_ARCH_CTRL:
 		msrs[index].control = msr_content;
 		break;
-	}	
+	}
 }
 
 /*

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6zc-0006nx-Dl; Wed, 08 Feb 2012 12:51:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6za-0006md-4S
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:51:22 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328705475!13439853!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxOTgwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19234 invoked from network); 8 Feb 2012 12:51:15 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:51:15 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=PUopYl8PJdrs8L8gBmguiRx9kMYzZ6Z3VFErXOumcv/TUx2gl1C+cOZI
	akf+xKLJawFCjjUZuKV/AUhBrVDxb/FndHNhHvoreAJW7xfHff3MINxuq
	A4GpKS2AFrhazKs/wbgei0DBDESxZbFMax/95vCLkrop7JdUw5RcO3eVN
	WdoYwUaMAK83KchFXqm0UefHYSCj4CJaPr9HHyICuoMu8Hz+y+a0MdnEk
	pZnYZzeO4qCJ18iu1dJtzwAYq2uUq;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705476; x=1360241476;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=7omllD/9HQgHckkF9j1biMr+Zr5D0x4JNWFCOocp/X0=;
	b=Mv5+tmHbhWqs6Hqqc7tfMovOZ4L7LU9u6B5tvW5o+VaefnRchw6HWhKw
	Wo6DwzVF+uuV5WsbIt/zAxjLuM6IgD6gMNALYFKk6qAaOf1VlinfpDIt8
	NbhJLIguJSCKmmLCH1lbAoiRMDIN4qPirLEyF7gm/5CFPFx2O2F/Yewul
	o0Uf0jt/hE0836QwzeCpXwlRQlHwxxZsQxG6eolmSOFWCh8s3NMY81FyI
	b82wMfxWyEq+TZuAKwvmjbgWEDUvu;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="101195049"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:15 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128391266"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:15 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 5D593960F15
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:51:15 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 13:51:15 +0100
Message-ID: <32414691.Y9K5qhyXSN@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] vpmu: Rename PASSIVE_DOMAIN_ALLOCATED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/oprofile/nmi_int.c       |  4 ++--
 xen/arch/x86/oprofile/op_model_ppro.c |  9 +++++----
 xen/include/asm-x86/hvm/vpmu.h        |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

This patch renames the define PASSIVE_DOMAIN_ALLOCATED to follow the
same scheme of the other defines.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r 9c899074f7ed xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:26:01 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:28:47 2012 +0100
@@ -47,7 +47,7 @@ static int passive_domain_msr_op_checks(
 	if ( !model->is_arch_pmu_msr(msr, typep, indexp) )
 		return 0;
 
-	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 		if ( ! model->allocated_msr(current) )
 			return 0;
 	return 1;
@@ -78,7 +78,7 @@ int passive_domain_do_wrmsr(unsigned int
 void passive_domain_destroy(struct vcpu *v)
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
-	if ( vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
+	if ( vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 		model->free_msr(v);
 }
 
diff -r 9c899074f7ed xen/arch/x86/oprofile/op_model_ppro.c
--- a/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 12:26:01 2012 +0100
+++ b/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 12:28:47 2012 +0100
@@ -143,7 +143,8 @@ static int ppro_check_ctrs(unsigned int 
 			xenoprof_log_event(current, regs, eip, mode, i);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
 			if ( is_passive(current->domain) && (mode != 2) &&
-				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) )
+				vpmu_is_set(vcpu_vpmu(current),
+                                            VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 			{
 				if ( IS_ACTIVE(msrs_content[i].control) )
 				{
@@ -231,7 +232,7 @@ static int ppro_allocate_msr(struct vcpu
 		goto out;
 	vpmu->context = (void *)msr_content;
 	vpmu_clear(vpmu);
-	vpmu_set(vpmu, PASSIVE_DOMAIN_ALLOCATED);
+	vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
 	return 1;
 out:
         gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile is "
@@ -244,10 +245,10 @@ static void ppro_free_msr(struct vcpu *v
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 		return;
 	xfree(vpmu->context);
-	vpmu_reset(vpmu, PASSIVE_DOMAIN_ALLOCATED);
+	vpmu_reset(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
 }
 
 static void ppro_load_msr(struct vcpu *v, int type, int index, u64 *msr_content)
diff -r 9c899074f7ed xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 08 12:26:01 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 08 12:28:47 2012 +0100
@@ -68,7 +68,7 @@ struct vpmu_struct {
 #define VPMU_CONTEXT_ALLOCATED              0x1
 #define VPMU_CONTEXT_LOADED                 0x2
 #define VPMU_RUNNING                        0x4
-#define PASSIVE_DOMAIN_ALLOCATED	    0x8
+#define VPMU_PASSIVE_DOMAIN_ALLOCATED       0x8
 
 #define vpmu_set(_vpmu, _x)    ((_vpmu)->flags |= (_x))
 #define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 12:51:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 12:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv6zc-0006nx-Dl; Wed, 08 Feb 2012 12:51:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv6za-0006md-4S
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 12:51:22 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328705475!13439853!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxOTgwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19234 invoked from network); 8 Feb 2012 12:51:15 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 12:51:15 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=PUopYl8PJdrs8L8gBmguiRx9kMYzZ6Z3VFErXOumcv/TUx2gl1C+cOZI
	akf+xKLJawFCjjUZuKV/AUhBrVDxb/FndHNhHvoreAJW7xfHff3MINxuq
	A4GpKS2AFrhazKs/wbgei0DBDESxZbFMax/95vCLkrop7JdUw5RcO3eVN
	WdoYwUaMAK83KchFXqm0UefHYSCj4CJaPr9HHyICuoMu8Hz+y+a0MdnEk
	pZnYZzeO4qCJ18iu1dJtzwAYq2uUq;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328705476; x=1360241476;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=7omllD/9HQgHckkF9j1biMr+Zr5D0x4JNWFCOocp/X0=;
	b=Mv5+tmHbhWqs6Hqqc7tfMovOZ4L7LU9u6B5tvW5o+VaefnRchw6HWhKw
	Wo6DwzVF+uuV5WsbIt/zAxjLuM6IgD6gMNALYFKk6qAaOf1VlinfpDIt8
	NbhJLIguJSCKmmLCH1lbAoiRMDIN4qPirLEyF7gm/5CFPFx2O2F/Yewul
	o0Uf0jt/hE0836QwzeCpXwlRQlHwxxZsQxG6eolmSOFWCh8s3NMY81FyI
	b82wMfxWyEq+TZuAKwvmjbgWEDUvu;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="101195049"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:15 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128391266"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 08 Feb 2012 13:51:15 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 5D593960F15
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 13:51:15 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 13:51:15 +0100
Message-ID: <32414691.Y9K5qhyXSN@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] vpmu: Rename PASSIVE_DOMAIN_ALLOCATED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/oprofile/nmi_int.c       |  4 ++--
 xen/arch/x86/oprofile/op_model_ppro.c |  9 +++++----
 xen/include/asm-x86/hvm/vpmu.h        |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

This patch renames the define PASSIVE_DOMAIN_ALLOCATED to follow the
same scheme of the other defines.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r 9c899074f7ed xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:26:01 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:28:47 2012 +0100
@@ -47,7 +47,7 @@ static int passive_domain_msr_op_checks(
 	if ( !model->is_arch_pmu_msr(msr, typep, indexp) )
 		return 0;
 
-	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 		if ( ! model->allocated_msr(current) )
 			return 0;
 	return 1;
@@ -78,7 +78,7 @@ int passive_domain_do_wrmsr(unsigned int
 void passive_domain_destroy(struct vcpu *v)
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
-	if ( vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
+	if ( vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 		model->free_msr(v);
 }
 
diff -r 9c899074f7ed xen/arch/x86/oprofile/op_model_ppro.c
--- a/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 12:26:01 2012 +0100
+++ b/xen/arch/x86/oprofile/op_model_ppro.c	Wed Feb 08 12:28:47 2012 +0100
@@ -143,7 +143,8 @@ static int ppro_check_ctrs(unsigned int 
 			xenoprof_log_event(current, regs, eip, mode, i);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
 			if ( is_passive(current->domain) && (mode != 2) &&
-				vpmu_is_set(vcpu_vpmu(current), PASSIVE_DOMAIN_ALLOCATED) )
+				vpmu_is_set(vcpu_vpmu(current),
+                                            VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 			{
 				if ( IS_ACTIVE(msrs_content[i].control) )
 				{
@@ -231,7 +232,7 @@ static int ppro_allocate_msr(struct vcpu
 		goto out;
 	vpmu->context = (void *)msr_content;
 	vpmu_clear(vpmu);
-	vpmu_set(vpmu, PASSIVE_DOMAIN_ALLOCATED);
+	vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
 	return 1;
 out:
         gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile is "
@@ -244,10 +245,10 @@ static void ppro_free_msr(struct vcpu *v
 {
 	struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-	if ( !vpmu_is_set(vpmu, PASSIVE_DOMAIN_ALLOCATED) )
+	if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) )
 		return;
 	xfree(vpmu->context);
-	vpmu_reset(vpmu, PASSIVE_DOMAIN_ALLOCATED);
+	vpmu_reset(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
 }
 
 static void ppro_load_msr(struct vcpu *v, int type, int index, u64 *msr_content)
diff -r 9c899074f7ed xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 08 12:26:01 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 08 12:28:47 2012 +0100
@@ -68,7 +68,7 @@ struct vpmu_struct {
 #define VPMU_CONTEXT_ALLOCATED              0x1
 #define VPMU_CONTEXT_LOADED                 0x2
 #define VPMU_RUNNING                        0x4
-#define PASSIVE_DOMAIN_ALLOCATED	    0x8
+#define VPMU_PASSIVE_DOMAIN_ALLOCATED       0x8
 
 #define vpmu_set(_vpmu, _x)    ((_vpmu)->flags |= (_x))
 #define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:15:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7M7-0007W0-SX; Wed, 08 Feb 2012 13:14:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv7M6-0007Vp-R0
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:14:39 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328706872!9771152!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxOTgwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26929 invoked from network); 8 Feb 2012 13:14:32 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 13:14:32 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=HYqFLbDtsxhv8nIYswNd9zCJ5mwN8h80qT3aH2IWKnMrPQH1nVXgGfVH
	8ogeUwxPX3Su5xbGBbAJyrpDhcpAho/1u4tOPS1SVT8l+F91Cs7+RUrR+
	rUZ674AidalRsYyIMcnGTipXRJKFUDSfd0ypC3qGD4G+NZmWXe/VDozQ6
	JTLumjWHUXtGPYBlqJDkseGWQUvIp7BtQYkWJM5yA/ml8dWsESSPEpmBp
	UxDu+0fXYvQbKJBkjFSks8YtkIaIF;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328706873; x=1360242873;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=YtZDqvxkpaTJWE/cYg8KuysaMBO1g8peYmiSNOsH7uY=;
	b=OXhBuwii5G6gzHh5YbiPOw7PlhQX0jqOwI+sWOrC5G0E2/yluor5kcnr
	fhEImyT+q11KAVrYof0ZO+jUVUx9zgrmeNwuMnWiqAVFbagySxbLeJ4cE
	BMWBU6eqmSfbAy00jK/2g/EHULNdMb0e8rF3v/RCm6qYZm9kK1wngKI50
	DsX0VrWMwscOcqUEF0zLY0jNoNeZdPDhuqT2aZsncKLAMN63GFZXAp40A
	2ZToFPiM7GXiUKqLtMWg8mqLoeDLc;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="101198919"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2012 14:14:32 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128703245"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 08 Feb 2012 14:14:32 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id C635D95B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 14:14:31 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 14:14:31 +0100
Message-ID: <2192614.Ifr2rPImK0@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

while locking at the vpmu stuff I found the following stuff:

diff -r a55e0f9c7b4e xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:28:47 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 14:11:06 2012 +0100
@@ -305,7 +305,7 @@ static int __init p4_init(char ** cpu_ty
 	}
 
 #ifndef CONFIG_SMP
-	*cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
+	*cpu_type = "i386/p4";
 	model = &op_p4_spec;
 	return 1;
 #else


Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.
Thanks.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:15:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7M7-0007W0-SX; Wed, 08 Feb 2012 13:14:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rv7M6-0007Vp-R0
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:14:39 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328706872!9771152!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxOTgwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26929 invoked from network); 8 Feb 2012 13:14:32 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 13:14:32 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=HYqFLbDtsxhv8nIYswNd9zCJ5mwN8h80qT3aH2IWKnMrPQH1nVXgGfVH
	8ogeUwxPX3Su5xbGBbAJyrpDhcpAho/1u4tOPS1SVT8l+F91Cs7+RUrR+
	rUZ674AidalRsYyIMcnGTipXRJKFUDSfd0ypC3qGD4G+NZmWXe/VDozQ6
	JTLumjWHUXtGPYBlqJDkseGWQUvIp7BtQYkWJM5yA/ml8dWsESSPEpmBp
	UxDu+0fXYvQbKJBkjFSks8YtkIaIF;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328706873; x=1360242873;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=YtZDqvxkpaTJWE/cYg8KuysaMBO1g8peYmiSNOsH7uY=;
	b=OXhBuwii5G6gzHh5YbiPOw7PlhQX0jqOwI+sWOrC5G0E2/yluor5kcnr
	fhEImyT+q11KAVrYof0ZO+jUVUx9zgrmeNwuMnWiqAVFbagySxbLeJ4cE
	BMWBU6eqmSfbAy00jK/2g/EHULNdMb0e8rF3v/RCm6qYZm9kK1wngKI50
	DsX0VrWMwscOcqUEF0zLY0jNoNeZdPDhuqT2aZsncKLAMN63GFZXAp40A
	2ZToFPiM7GXiUKqLtMWg8mqLoeDLc;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="101198919"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2012 14:14:32 +0100
X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="128703245"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 08 Feb 2012 14:14:32 +0100
Received: from amur.localnet (unknown [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id C635D95B855
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 14:14:31 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 08 Feb 2012 14:14:31 +0100
Message-ID: <2192614.Ifr2rPImK0@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

while locking at the vpmu stuff I found the following stuff:

diff -r a55e0f9c7b4e xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 12:28:47 2012 +0100
+++ b/xen/arch/x86/oprofile/nmi_int.c	Wed Feb 08 14:11:06 2012 +0100
@@ -305,7 +305,7 @@ static int __init p4_init(char ** cpu_ty
 	}
 
 #ifndef CONFIG_SMP
-	*cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
+	*cpu_type = "i386/p4";
 	model = &op_p4_spec;
 	return 1;
 #else


Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.
Thanks.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:15:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7MX-0007XM-Ap; Wed, 08 Feb 2012 13:15: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 1Rv7MV-0007XD-Qu
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:15:03 +0000
Received: from [85.158.139.83:25723] by server-5.bemta-5.messagelabs.com id
	82/02-03847-655723F4; Wed, 08 Feb 2012 13:15:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328706902!14214668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 717 invoked from network); 8 Feb 2012 13:15:02 -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;
	8 Feb 2012 13:15:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10572996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 13:15:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	13:15:02 +0000
Message-ID: <1328706900.6133.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xenxen <xenxen@163.com>
Date: Wed, 8 Feb 2012 13:15:00 +0000
In-Reply-To: <1e54aa3d.1d7ff.1353e612660.Coremail.xenxen@163.com>
References: <1e54aa3d.1d7ff.1353e612660.Coremail.xenxen@163.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] questions about minios idd
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 14:04 +0000, xenxen wrote:
> Dear Xen.org
>  
> I want to ask questions about IDD(isolated driver domain).
>  
> 1. Can the minios inlcuded in the Xen sourcecode be used to be IDD
> domain?

Not in general no -- minios is something of a "PV only" guest and
contains no hard drivers and hence isn't terribly useful as a backend
domain.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:15:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:15:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7MX-0007XM-Ap; Wed, 08 Feb 2012 13:15: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 1Rv7MV-0007XD-Qu
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:15:03 +0000
Received: from [85.158.139.83:25723] by server-5.bemta-5.messagelabs.com id
	82/02-03847-655723F4; Wed, 08 Feb 2012 13:15:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328706902!14214668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 717 invoked from network); 8 Feb 2012 13:15:02 -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;
	8 Feb 2012 13:15:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10572996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 13:15:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	13:15:02 +0000
Message-ID: <1328706900.6133.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xenxen <xenxen@163.com>
Date: Wed, 8 Feb 2012 13:15:00 +0000
In-Reply-To: <1e54aa3d.1d7ff.1353e612660.Coremail.xenxen@163.com>
References: <1e54aa3d.1d7ff.1353e612660.Coremail.xenxen@163.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] questions about minios idd
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-02 at 14:04 +0000, xenxen wrote:
> Dear Xen.org
>  
> I want to ask questions about IDD(isolated driver domain).
>  
> 1. Can the minios inlcuded in the Xen sourcecode be used to be IDD
> domain?

Not in general no -- minios is something of a "PV only" guest and
contains no hard drivers and hence isn't terribly useful as a backend
domain.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:29:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7a9-00083x-NJ; Wed, 08 Feb 2012 13:29:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv7a8-00083s-CJ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:29:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328707741!14008091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10530 invoked from network); 8 Feb 2012 13:29:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 13:29:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10573780"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 13:29:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	13:29:01 +0000
Message-ID: <1328707739.6133.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 13:28:59 +0000
In-Reply-To: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-02-05 at 16:18 +0000, Julian Pidancet wrote:
> When booting HVMs with SeaBIOS, the BIOS itself takes care of extracting
> option ROMs from the PCI devices. These ROMs are usually provided with by
> the device model (qemu).
> Thus, hvmloader should not require any longer the rombios, stdvga,
> cirrusvga or etherboot ROMs to be present.
> 
> Also, the 32bitbios_support.c file is specific to rombios and should not
> be built when building hvmloader with seabios.

> [...]
> @@ -475,16 +477,20 @@ int main(void)
>         switch ( virtual_vga )
>          {
>          case VGA_cirrus:
> +#ifdef ENABLE_CIRRUSVGA

Just outside the context here is an "if ( bios->load_roms )" which
prevents the ROMs from being loaded if we are using SeaBIOS -- is that
not sufficient for your needs?

Currently hvmloader builds with support for both ROMBIOS and SeaBIOS and
selects the one to use based on a configuration key in xenstore (pushed
down by the toolstack depending on which qemu you are running). Have you
modified something elsewhere in order to build a SeaBIOS-only hvmloader?

Perhaps it would make sense for the ROMs to be keyed off whether or not
ROMBIOS is enabled rather than each keying off their own DIR var?

You seem to have mixed some other changes, specifically s/:=/?=/ in a
few places and also some sort of change wrt how eb-roms.h is generated
(including dropping the 8086100e ROM from the image, which must be
discussed).

These other changes should be submitted and rationalised separately.

Ian.


>              printf("Loading Cirrus VGABIOS ...\n");
>              memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
>                     vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
>              vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
> +#endif
>              break;
>          case VGA_std:
> +#ifdef ENABLE_STDVGA
>              printf("Loading Standard VGABIOS ...\n");
>              memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
>                     vgabios_stdvga, sizeof(vgabios_stdvga));
>              vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
> +#endif
>              break;
>          case VGA_pt:
>              printf("Loading VGABIOS of passthroughed gfx ...\n");
> @@ -496,13 +502,16 @@ int main(void)
>              break;
>          }
>  
> -        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> +        option_rom_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> +#ifdef ENABLE_ETHERBOOT
> +        etherboot_phys_addr = option_rom_phys_addr;
>          if ( etherboot_phys_addr < bios->optionrom_start )
>              etherboot_phys_addr = bios->optionrom_start;
>          etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
>                                            etherboot_phys_addr);
>  
> -        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> +        option_rom_phys_addr += etherboot_sz;
> +#endif
>          option_rom_sz = pci_load_option_roms(bios->optionrom_end,
>                                               option_rom_phys_addr);
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:29:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7a9-00083x-NJ; Wed, 08 Feb 2012 13:29:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv7a8-00083s-CJ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:29:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328707741!14008091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10530 invoked from network); 8 Feb 2012 13:29:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 13:29:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10573780"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 13:29:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	13:29:01 +0000
Message-ID: <1328707739.6133.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 13:28:59 +0000
In-Reply-To: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-02-05 at 16:18 +0000, Julian Pidancet wrote:
> When booting HVMs with SeaBIOS, the BIOS itself takes care of extracting
> option ROMs from the PCI devices. These ROMs are usually provided with by
> the device model (qemu).
> Thus, hvmloader should not require any longer the rombios, stdvga,
> cirrusvga or etherboot ROMs to be present.
> 
> Also, the 32bitbios_support.c file is specific to rombios and should not
> be built when building hvmloader with seabios.

> [...]
> @@ -475,16 +477,20 @@ int main(void)
>         switch ( virtual_vga )
>          {
>          case VGA_cirrus:
> +#ifdef ENABLE_CIRRUSVGA

Just outside the context here is an "if ( bios->load_roms )" which
prevents the ROMs from being loaded if we are using SeaBIOS -- is that
not sufficient for your needs?

Currently hvmloader builds with support for both ROMBIOS and SeaBIOS and
selects the one to use based on a configuration key in xenstore (pushed
down by the toolstack depending on which qemu you are running). Have you
modified something elsewhere in order to build a SeaBIOS-only hvmloader?

Perhaps it would make sense for the ROMs to be keyed off whether or not
ROMBIOS is enabled rather than each keying off their own DIR var?

You seem to have mixed some other changes, specifically s/:=/?=/ in a
few places and also some sort of change wrt how eb-roms.h is generated
(including dropping the 8086100e ROM from the image, which must be
discussed).

These other changes should be submitted and rationalised separately.

Ian.


>              printf("Loading Cirrus VGABIOS ...\n");
>              memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
>                     vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
>              vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
> +#endif
>              break;
>          case VGA_std:
> +#ifdef ENABLE_STDVGA
>              printf("Loading Standard VGABIOS ...\n");
>              memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
>                     vgabios_stdvga, sizeof(vgabios_stdvga));
>              vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
> +#endif
>              break;
>          case VGA_pt:
>              printf("Loading VGABIOS of passthroughed gfx ...\n");
> @@ -496,13 +502,16 @@ int main(void)
>              break;
>          }
>  
> -        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> +        option_rom_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> +#ifdef ENABLE_ETHERBOOT
> +        etherboot_phys_addr = option_rom_phys_addr;
>          if ( etherboot_phys_addr < bios->optionrom_start )
>              etherboot_phys_addr = bios->optionrom_start;
>          etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
>                                            etherboot_phys_addr);
>  
> -        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> +        option_rom_phys_addr += etherboot_sz;
> +#endif
>          option_rom_sz = pci_load_option_roms(bios->optionrom_end,
>                                               option_rom_phys_addr);
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:37:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7hi-0008DT-LS; Wed, 08 Feb 2012 13:36:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rv7hh-0008DO-MJ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:36:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328708211!12516626!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDM2ODY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDM2ODY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10022 invoked from network); 8 Feb 2012 13:36:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 13:36:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328708211; l=1875;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=bVHvVUvby1TkfrR0cVTRo2bWYZM=;
	b=O9cPungCLDPEjEEvP/Z2AwgDUbeArTRUE/dSrWeieBWru+h/irJlVhQJ9Qhquo6pld0
	lCLYtOHIJ0icO7kdSCYmBt8JOfeCdVq8Fqx6x47AjJl0ZLdPulMhI6qdloEihO+XrJa6H
	jyO/j0fdz5W20SLS77nNEUKXsrCZrMfsmTw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhy0HFhc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-089-095.pools.arcor-ip.net [88.65.89.95])
	by smtp.strato.de (cohen mo42) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J002aao18D4D2a ;
	Wed, 8 Feb 2012 14:36:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6D6B118637; Wed,  8 Feb 2012 14:36:45 +0100 (CET)
Date: Wed, 8 Feb 2012 14:36:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120208133645.GA2270@aepfle.de>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20120207104446.GA31244@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120207104446.GA31244@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] tools/flask: remove libflask
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, Olaf Hering wrote:

After poking at this some more, isnt the patch removing the libflask
directory? I think it should have removed also all references to that
directory. setup.py (or python 2.6) in SLES11 can not cope with it,
while python 2.7 in openSuSE seems to ignore the remove directory.

I will send a tested patch which removes the references to libflask.

Olaf

> On Fri, Feb 03, Daniel De Graaf wrote:
> 
> > This library has been deprecated since July 2010; remove the in-tree
> > users and library.
> 
> > -	ln -sf libflask.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libflask.so
> 
> > +++ b/tools/python/setup.py
> > @@ -48,7 +48,7 @@ flask = Extension("flask",
> >                 include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
> >                                        "../flask/libflask/include" ],
> >                 library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
> > -               libraries          = [ "xenctrl", "flask" ],
> > +               libraries          = [ "xenctrl" ],
> >                 depends            = [ PATH_LIBXC + "/libxenctrl.so",
> >                                        XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
> >                 sources            = [ "xen/lowlevel/flask/flask.c" ])
> 
> 
> For some reason this changeset does not cause buildfailures in automated
> testing. My xen-unstable rpm packages fail to build in SLES11, but not in
> openSuSE for some reason.
> 
> Is there a chance that libflask.so is built after this python thing runs?
> In other words: Is there a makefile dependency missing?
> 
> Olaf
> 
> ...
> building 'flask' extension
> error: ../../tools/flask/libflask/libflask.so: No such file or directory
> make[3]: *** [install] Error 1
> make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.24701/non-dbg/tools/python'
> make[2]: *** [subdir-install-python] Error 2
> ...
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:37:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7hi-0008DT-LS; Wed, 08 Feb 2012 13:36:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rv7hh-0008DO-MJ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:36:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328708211!12516626!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDM2ODY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDM2ODY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10022 invoked from network); 8 Feb 2012 13:36:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 13:36:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328708211; l=1875;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=bVHvVUvby1TkfrR0cVTRo2bWYZM=;
	b=O9cPungCLDPEjEEvP/Z2AwgDUbeArTRUE/dSrWeieBWru+h/irJlVhQJ9Qhquo6pld0
	lCLYtOHIJ0icO7kdSCYmBt8JOfeCdVq8Fqx6x47AjJl0ZLdPulMhI6qdloEihO+XrJa6H
	jyO/j0fdz5W20SLS77nNEUKXsrCZrMfsmTw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhy0HFhc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-089-095.pools.arcor-ip.net [88.65.89.95])
	by smtp.strato.de (cohen mo42) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J002aao18D4D2a ;
	Wed, 8 Feb 2012 14:36:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6D6B118637; Wed,  8 Feb 2012 14:36:45 +0100 (CET)
Date: Wed, 8 Feb 2012 14:36:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120208133645.GA2270@aepfle.de>
References: <1328281981-17399-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328281981-17399-2-git-send-email-dgdegra@tycho.nsa.gov>
	<20120207104446.GA31244@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120207104446.GA31244@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] tools/flask: remove libflask
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, Olaf Hering wrote:

After poking at this some more, isnt the patch removing the libflask
directory? I think it should have removed also all references to that
directory. setup.py (or python 2.6) in SLES11 can not cope with it,
while python 2.7 in openSuSE seems to ignore the remove directory.

I will send a tested patch which removes the references to libflask.

Olaf

> On Fri, Feb 03, Daniel De Graaf wrote:
> 
> > This library has been deprecated since July 2010; remove the in-tree
> > users and library.
> 
> > -	ln -sf libflask.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libflask.so
> 
> > +++ b/tools/python/setup.py
> > @@ -48,7 +48,7 @@ flask = Extension("flask",
> >                 include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
> >                                        "../flask/libflask/include" ],
> >                 library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
> > -               libraries          = [ "xenctrl", "flask" ],
> > +               libraries          = [ "xenctrl" ],
> >                 depends            = [ PATH_LIBXC + "/libxenctrl.so",
> >                                        XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
> >                 sources            = [ "xen/lowlevel/flask/flask.c" ])
> 
> 
> For some reason this changeset does not cause buildfailures in automated
> testing. My xen-unstable rpm packages fail to build in SLES11, but not in
> openSuSE for some reason.
> 
> Is there a chance that libflask.so is built after this python thing runs?
> In other words: Is there a makefile dependency missing?
> 
> Olaf
> 
> ...
> building 'flask' extension
> error: ../../tools/flask/libflask/libflask.so: No such file or directory
> make[3]: *** [install] Error 1
> make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.24701/non-dbg/tools/python'
> make[2]: *** [subdir-install-python] Error 2
> ...
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:41:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13: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.xensource.com>)
	id 1Rv7lT-0008K7-Bh; Wed, 08 Feb 2012 13:40:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rv7lR-0008Jh-Db
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:40:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328708443!12526620!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjE0NjE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjE0NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5258 invoked from network); 8 Feb 2012 13:40:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 13:40:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328708442; l=1379;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mMXwpxdDhCtq0pFFN/vz270TAvk=;
	b=O3aEoSc/MDSJ9nIWrLtOVjWtVCf12dO/9xC4At8XfSqdMrAyca/TSr0gxC1dpf63HiF
	pp15UObs2wgPszt5xPUrrVxiHibA8Fe6oxQd6LsAOQWSwKdpdohkLBFr9LKg1rARgnBY9
	FtrIwk0W4su6SiCIwINyYRZUhxX3E6v8ufo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhy0HFhc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-089-095.pools.arcor-ip.net [88.65.89.95])
	by smtp.strato.de (cohen mo29) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u00273o18COskS
	for <xen-devel@lists.xensource.com>;
	Wed, 8 Feb 2012 14:40:35 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 22BA718634
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 14:40:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b730f1f980bdc1edcebf7dbbbb5253ccafcd8c04
Message-Id: <b730f1f980bdc1edcebf.1328708440@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 08 Feb 2012 14:40:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] remove references to removed libflask from
	setup.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328707901 -3600
# Node ID b730f1f980bdc1edcebf7dbbbb5253ccafcd8c04
# Parent  3574f4d67843733ccaabab5f8ebb859c99d7314a
remove references to removed libflask from setup.py

Build in SLES11 SP1/2 fails after libflask removal.

> building 'flask' extension
> error: ../../tools/flask/libflask/libflask.so: No such file or directory
> make[3]: *** [install] Error 1
> make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.24701/non-dbg/tools/python'
> make[2]: *** [subdir-install-python] Error 2

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3574f4d67843 -r b730f1f980bd tools/python/setup.py
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -45,12 +45,10 @@ process = Extension("process",
 
 flask = Extension("flask",
                extra_compile_args = extra_compile_args,
-               include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
-                                      "../flask/libflask/include" ],
-               library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
+               include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask" ],
+               library_dirs       = [ PATH_LIBXC ],
                libraries          = [ "xenctrl" ],
-               depends            = [ PATH_LIBXC + "/libxenctrl.so",
-                                      XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
+               depends            = [ PATH_LIBXC + "/libxenctrl.so" ],
                sources            = [ "xen/lowlevel/flask/flask.c" ])
 
 ptsname = Extension("ptsname",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:41:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13: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.xensource.com>)
	id 1Rv7lT-0008K7-Bh; Wed, 08 Feb 2012 13:40:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rv7lR-0008Jh-Db
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:40:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328708443!12526620!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjE0NjE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjE0NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5258 invoked from network); 8 Feb 2012 13:40:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 13:40:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328708442; l=1379;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mMXwpxdDhCtq0pFFN/vz270TAvk=;
	b=O3aEoSc/MDSJ9nIWrLtOVjWtVCf12dO/9xC4At8XfSqdMrAyca/TSr0gxC1dpf63HiF
	pp15UObs2wgPszt5xPUrrVxiHibA8Fe6oxQd6LsAOQWSwKdpdohkLBFr9LKg1rARgnBY9
	FtrIwk0W4su6SiCIwINyYRZUhxX3E6v8ufo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhy0HFhc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-089-095.pools.arcor-ip.net [88.65.89.95])
	by smtp.strato.de (cohen mo29) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u00273o18COskS
	for <xen-devel@lists.xensource.com>;
	Wed, 8 Feb 2012 14:40:35 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 22BA718634
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 14:40:41 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b730f1f980bdc1edcebf7dbbbb5253ccafcd8c04
Message-Id: <b730f1f980bdc1edcebf.1328708440@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 08 Feb 2012 14:40:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] remove references to removed libflask from
	setup.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328707901 -3600
# Node ID b730f1f980bdc1edcebf7dbbbb5253ccafcd8c04
# Parent  3574f4d67843733ccaabab5f8ebb859c99d7314a
remove references to removed libflask from setup.py

Build in SLES11 SP1/2 fails after libflask removal.

> building 'flask' extension
> error: ../../tools/flask/libflask/libflask.so: No such file or directory
> make[3]: *** [install] Error 1
> make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.24701/non-dbg/tools/python'
> make[2]: *** [subdir-install-python] Error 2

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3574f4d67843 -r b730f1f980bd tools/python/setup.py
--- a/tools/python/setup.py
+++ b/tools/python/setup.py
@@ -45,12 +45,10 @@ process = Extension("process",
 
 flask = Extension("flask",
                extra_compile_args = extra_compile_args,
-               include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask",
-                                      "../flask/libflask/include" ],
-               library_dirs       = [ PATH_LIBXC, "../flask/libflask" ],
+               include_dirs       = [ PATH_XEN, PATH_LIBXC, "xen/lowlevel/flask" ],
+               library_dirs       = [ PATH_LIBXC ],
                libraries          = [ "xenctrl" ],
-               depends            = [ PATH_LIBXC + "/libxenctrl.so",
-                                      XEN_ROOT + "/tools/flask/libflask/libflask.so" ],
+               depends            = [ PATH_LIBXC + "/libxenctrl.so" ],
                sources            = [ "xen/lowlevel/flask/flask.c" ])
 
 ptsname = Extension("ptsname",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7pO-0008UV-3x; Wed, 08 Feb 2012 13:44:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv7pM-0008UH-VV
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:44:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328708686!14484377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11801 invoked from network); 8 Feb 2012 13:44:47 -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;
	8 Feb 2012 13:44:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10574557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 13: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.213.0; Wed, 8 Feb 2012
	13:44:46 +0000
Message-ID: <1328708684.6133.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 8 Feb 2012 13:44:44 +0000
In-Reply-To: <72f1296a55a470426e1c.1328541247@zhigang.us.oracle.com>
References: <72f1296a55a470426e1c.1328541247@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH] libxl: fix bootloader args setting
 [with diff]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 15:14 +0000, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1328541193 18000
> # Node ID 72f1296a55a470426e1c3e5b8b2ba907ab6eb78c
> # Parent  3432abcf9380d3840ca38439a304f74a37d155fc
> libxl: fix bootloader args setting
> 
> When bootloader_args = ['foo', 'bar'], then info->u.pv.bootloader_args =
> 
>     foo\0
>     bar\0
>     \0
> 
> Before this patch, 'p++' points to the next character of 'foo\0' and never
> comes to 'bar\0' (because of the '\0' in 'foo\0'), so the args will be:
> 
>     args[0] = 'oo\0'
>     args[1] = 'o\0'
> 
> After this patch, 'p++' points to the next string of pv.bootloader_args, so we
> get the correct args:
> 
>     args[0] = 'foo\0'
>     args[1] = 'bar\0'
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff -r 3432abcf9380 -r 72f1296a55a4 tools/libxl/libxl_bootloader.c
> --- a/tools/libxl/libxl_bootloader.c	Thu Feb 02 15:47:26 2012 +0000
> +++ b/tools/libxl/libxl_bootloader.c	Mon Feb 06 10:13:13 2012 -0500
> @@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
>      flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
>  
>      if (info->u.pv.bootloader_args) {
> -        char *p = info->u.pv.bootloader_args[0];
> -        while (*(p++))
> -            flexarray_set(args, nr++, p);
> +        char **p = info->u.pv.bootloader_args;
> +        while (*p) {
> +            flexarray_set(args, nr++, *p);
> +            p++;
> +        }
>      }
>  
>      flexarray_set(args, nr++, disk);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv7pO-0008UV-3x; Wed, 08 Feb 2012 13:44:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv7pM-0008UH-VV
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:44:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328708686!14484377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11801 invoked from network); 8 Feb 2012 13:44:47 -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;
	8 Feb 2012 13:44:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10574557"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 13: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.213.0; Wed, 8 Feb 2012
	13:44:46 +0000
Message-ID: <1328708684.6133.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Wed, 8 Feb 2012 13:44:44 +0000
In-Reply-To: <72f1296a55a470426e1c.1328541247@zhigang.us.oracle.com>
References: <72f1296a55a470426e1c.1328541247@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH] libxl: fix bootloader args setting
 [with diff]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 15:14 +0000, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1328541193 18000
> # Node ID 72f1296a55a470426e1c3e5b8b2ba907ab6eb78c
> # Parent  3432abcf9380d3840ca38439a304f74a37d155fc
> libxl: fix bootloader args setting
> 
> When bootloader_args = ['foo', 'bar'], then info->u.pv.bootloader_args =
> 
>     foo\0
>     bar\0
>     \0
> 
> Before this patch, 'p++' points to the next character of 'foo\0' and never
> comes to 'bar\0' (because of the '\0' in 'foo\0'), so the args will be:
> 
>     args[0] = 'oo\0'
>     args[1] = 'o\0'
> 
> After this patch, 'p++' points to the next string of pv.bootloader_args, so we
> get the correct args:
> 
>     args[0] = 'foo\0'
>     args[1] = 'bar\0'
> 
> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff -r 3432abcf9380 -r 72f1296a55a4 tools/libxl/libxl_bootloader.c
> --- a/tools/libxl/libxl_bootloader.c	Thu Feb 02 15:47:26 2012 +0000
> +++ b/tools/libxl/libxl_bootloader.c	Mon Feb 06 10:13:13 2012 -0500
> @@ -49,9 +49,11 @@ static char **make_bootloader_args(libxl
>      flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
>  
>      if (info->u.pv.bootloader_args) {
> -        char *p = info->u.pv.bootloader_args[0];
> -        while (*(p++))
> -            flexarray_set(args, nr++, p);
> +        char **p = info->u.pv.bootloader_args;
> +        while (*p) {
> +            flexarray_set(args, nr++, *p);
> +            p++;
> +        }
>      }
>  
>      flexarray_set(args, nr++, disk);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:58:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv81h-0000LQ-La; Wed, 08 Feb 2012 13:57:37 +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 1Rv81g-0000LL-B4
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:57:36 +0000
Received: from [85.158.139.83:48413] by server-12.bemta-5.messagelabs.com id
	57/57-30830-F4F723F4; Wed, 08 Feb 2012 13:57:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328709453!13626643!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15664 invoked from network); 8 Feb 2012 13:57:35 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 13:57:35 -0000
Received: by pbds6 with SMTP id s6so4883903pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 05:57:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rCaLolx9WEzmjvlN6ILq4M9OvA/lUIPhS5aoAWCa1NM=;
	b=LMsxEtmrnVEG46cqtYL2+rwL1tjjD6S83CmZAN6jZ3Ej731HrxH1mbC5cjaq5CKM9Y
	99t4FxQkkqUz+gCURp5nMAFy5ZLxmsT9g2JNnqCnZPN4gel95PCmmgB+R5Kgw8Qrsg72
	8KzFdfoBP3oecimyMhwta45XHV3yrZEcQwhFk=
Received: by 10.68.73.6 with SMTP id h6mr68447836pbv.116.1328709452868;
	Wed, 08 Feb 2012 05:57:32 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id b7sm688373pba.2.2012.02.08.05.57.30
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 05:57:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 05:57:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, <xen-devel@lists.xensource.com>
Message-ID: <CB57BF48.2A9B6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
Thread-Index: AczmaZfSFoZTVcyHe06fcXxBA93hNQ==
In-Reply-To: <2192614.Ifr2rPImK0@amur>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 13:14, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:

> Hi,
> 
> while locking at the vpmu stuff I found the following stuff:
> 
> diff -r a55e0f9c7b4e xen/arch/x86/oprofile/nmi_int.c
> --- a/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 12:28:47 2012 +0100
> +++ b/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 14:11:06 2012 +0100
> @@ -305,7 +305,7 @@ static int __init p4_init(char ** cpu_ty
> }
>  
>  #ifndef CONFIG_SMP
> - *cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
> + *cpu_type = "i386/p4";
> model = &op_p4_spec;
> return 1;
>  #else
> 
> 
> Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.

Correct. !CONFIG_SMP isn't configurable or supported.

 -- Keir

> Thanks.
> 
> Dietmar.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 13:58:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 13:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv81h-0000LQ-La; Wed, 08 Feb 2012 13:57:37 +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 1Rv81g-0000LL-B4
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 13:57:36 +0000
Received: from [85.158.139.83:48413] by server-12.bemta-5.messagelabs.com id
	57/57-30830-F4F723F4; Wed, 08 Feb 2012 13:57:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328709453!13626643!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15664 invoked from network); 8 Feb 2012 13:57:35 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 13:57:35 -0000
Received: by pbds6 with SMTP id s6so4883903pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 05:57:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rCaLolx9WEzmjvlN6ILq4M9OvA/lUIPhS5aoAWCa1NM=;
	b=LMsxEtmrnVEG46cqtYL2+rwL1tjjD6S83CmZAN6jZ3Ej731HrxH1mbC5cjaq5CKM9Y
	99t4FxQkkqUz+gCURp5nMAFy5ZLxmsT9g2JNnqCnZPN4gel95PCmmgB+R5Kgw8Qrsg72
	8KzFdfoBP3oecimyMhwta45XHV3yrZEcQwhFk=
Received: by 10.68.73.6 with SMTP id h6mr68447836pbv.116.1328709452868;
	Wed, 08 Feb 2012 05:57:32 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id b7sm688373pba.2.2012.02.08.05.57.30
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 05:57:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 05:57:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, <xen-devel@lists.xensource.com>
Message-ID: <CB57BF48.2A9B6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
Thread-Index: AczmaZfSFoZTVcyHe06fcXxBA93hNQ==
In-Reply-To: <2192614.Ifr2rPImK0@amur>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 13:14, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:

> Hi,
> 
> while locking at the vpmu stuff I found the following stuff:
> 
> diff -r a55e0f9c7b4e xen/arch/x86/oprofile/nmi_int.c
> --- a/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 12:28:47 2012 +0100
> +++ b/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 14:11:06 2012 +0100
> @@ -305,7 +305,7 @@ static int __init p4_init(char ** cpu_ty
> }
>  
>  #ifndef CONFIG_SMP
> - *cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
> + *cpu_type = "i386/p4";
> model = &op_p4_spec;
> return 1;
>  #else
> 
> 
> Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.

Correct. !CONFIG_SMP isn't configurable or supported.

 -- Keir

> Thanks.
> 
> Dietmar.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:01:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14: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.xensource.com>)
	id 1Rv84x-0000Vb-AX; Wed, 08 Feb 2012 14:00:59 +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 1Rv84w-0000VV-05
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:00:58 +0000
Received: from [85.158.139.83:16362] by server-8.bemta-5.messagelabs.com id
	EF/F6-08951-910823F4; Wed, 08 Feb 2012 14:00:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328709655!13627416!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4035 invoked from network); 8 Feb 2012 14:00:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:00:56 -0000
Received: by iaeh11 with SMTP id h11so4526253iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:00:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=hJ+NH628xAsN6VO0SD+DsSpGkM/XhoGAEK7aUH8fC+E=;
	b=mBlZMcffOxte7SAJvl9sOlUWL99nNUi2cQb8J/NDkE7fOH3Sjl076Oxv9+pvTSE3Ac
	Lsgw72nR1NyrRpp2L25KDdnghwXQeVMGwgJT9qAQH47rHkaSxDZhIOD87bQdndlRKQgn
	Zwg9B47q5AJhVwXqajoQKj/3TXrogLOxjESzo=
Received: by 10.50.196.167 with SMTP id in7mr3335763igc.9.1328709654989;
	Wed, 08 Feb 2012 06:00:54 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id mr24sm3062380ibb.1.2012.02.08.06.00.52
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:00:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 06:00:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Justin Gibbs <justing@spectralogic.com>
Message-ID: <CB57C010.2A9B8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: Aczmag8HENBqRW2HnEuvRtUilmuH3Q==
In-Reply-To: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 07:48, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>> 
>>>  1. Version the header file and require consumers to declare the interface
>>> version
>>>      they are using.  If the version isn't declared, the default, legacy,
>>> "version 1.0" will
>>>      be in effect.
>>> 
>>>      Positives:   No change in or constant naming conventions.  Data
>>> structures and
>>>                          constants for new features are properly hidden from
>>> legacy implementations.
>>>      Negatives: Messy #ifdefs
>> 
>> We already have this. See use of
>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>> headers.
> 
> Hmm, I would think these should specifically not be used in the
> io/ subtree - those aren't definitions of the interface to Xen, but
> ones shared between the respective backends and frontends.
> Each interface is (apart from its relying on the ring definitions)
> entirely self contained.

I guess I think of the whole header set under xen/include/public as one
unit, versioned by __XEN_INTERFACE_VERSION__. And that's how users are
generally syncing with our headers -- copy them in their entirety over the
top of the old ones.

I'm not over fussed which solution you agree on in this specific case
however.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:01:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14: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.xensource.com>)
	id 1Rv84x-0000Vb-AX; Wed, 08 Feb 2012 14:00:59 +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 1Rv84w-0000VV-05
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:00:58 +0000
Received: from [85.158.139.83:16362] by server-8.bemta-5.messagelabs.com id
	EF/F6-08951-910823F4; Wed, 08 Feb 2012 14:00:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328709655!13627416!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4035 invoked from network); 8 Feb 2012 14:00:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:00:56 -0000
Received: by iaeh11 with SMTP id h11so4526253iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:00:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=hJ+NH628xAsN6VO0SD+DsSpGkM/XhoGAEK7aUH8fC+E=;
	b=mBlZMcffOxte7SAJvl9sOlUWL99nNUi2cQb8J/NDkE7fOH3Sjl076Oxv9+pvTSE3Ac
	Lsgw72nR1NyrRpp2L25KDdnghwXQeVMGwgJT9qAQH47rHkaSxDZhIOD87bQdndlRKQgn
	Zwg9B47q5AJhVwXqajoQKj/3TXrogLOxjESzo=
Received: by 10.50.196.167 with SMTP id in7mr3335763igc.9.1328709654989;
	Wed, 08 Feb 2012 06:00:54 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id mr24sm3062380ibb.1.2012.02.08.06.00.52
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:00:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 06:00:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Justin Gibbs <justing@spectralogic.com>
Message-ID: <CB57C010.2A9B8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: Aczmag8HENBqRW2HnEuvRtUilmuH3Q==
In-Reply-To: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 07:48, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>> 
>>>  1. Version the header file and require consumers to declare the interface
>>> version
>>>      they are using.  If the version isn't declared, the default, legacy,
>>> "version 1.0" will
>>>      be in effect.
>>> 
>>>      Positives:   No change in or constant naming conventions.  Data
>>> structures and
>>>                          constants for new features are properly hidden from
>>> legacy implementations.
>>>      Negatives: Messy #ifdefs
>> 
>> We already have this. See use of
>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>> headers.
> 
> Hmm, I would think these should specifically not be used in the
> io/ subtree - those aren't definitions of the interface to Xen, but
> ones shared between the respective backends and frontends.
> Each interface is (apart from its relying on the ring definitions)
> entirely self contained.

I guess I think of the whole header set under xen/include/public as one
unit, versioned by __XEN_INTERFACE_VERSION__. And that's how users are
generally syncing with our headers -- copy them in their entirety over the
top of the old ones.

I'm not over fussed which solution you agree on in this specific case
however.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:05:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:05:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv895-0000f3-3B; Wed, 08 Feb 2012 14:05:15 +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 1Rv893-0000ev-4t
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:05:13 +0000
Received: from [85.158.139.83:52163] by server-6.bemta-5.messagelabs.com id
	98/5D-04784-811823F4; Wed, 08 Feb 2012 14:05:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328709910!13377686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26015 invoked from network); 8 Feb 2012 14:05:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:05:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325480400"; d="scan'208";a="21752402"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 09:05:10 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	09:05:09 -0500
Message-ID: <4F328114.60506@citrix.com>
Date: Wed, 8 Feb 2012 14:05:08 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CB57BF48.2A9B6%keir.xen@gmail.com>
In-Reply-To: <CB57BF48.2A9B6%keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/12 05:57, Keir Fraser wrote:
> On 08/02/2012 13:14, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>
>> Hi,
>>
>> while locking at the vpmu stuff I found the following stuff:
>>
>> diff -r a55e0f9c7b4e xen/arch/x86/oprofile/nmi_int.c
>> --- a/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 12:28:47 2012 +0100
>> +++ b/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 14:11:06 2012 +0100
>> @@ -305,7 +305,7 @@ static int __init p4_init(char ** cpu_ty
>> }
>>  
>>  #ifndef CONFIG_SMP
>> - *cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
>> + *cpu_type = "i386/p4";
>> model = &op_p4_spec;
>> return 1;
>>  #else
>>
>>
>> Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.
> Correct. !CONFIG_SMP isn't configurable or supported.
>
>  -- Keir

A naive test:

andrewcoop@andrewcoop:/local/xen-unstable.hg/xen$ rgrep "CONFIG_SMP" * |
wc -l
166

Seems there are quite a few bits to remove.  If noone has done so, when
I get round to gutting #ifdef __ia64__'s from the arch/x86 tree I shall
do the same with CONFIG_SMP.

~Andrew

>> Thanks.
>>
>> Dietmar.
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:05:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:05:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv895-0000f3-3B; Wed, 08 Feb 2012 14:05:15 +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 1Rv893-0000ev-4t
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:05:13 +0000
Received: from [85.158.139.83:52163] by server-6.bemta-5.messagelabs.com id
	98/5D-04784-811823F4; Wed, 08 Feb 2012 14:05:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328709910!13377686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26015 invoked from network); 8 Feb 2012 14:05:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:05:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325480400"; d="scan'208";a="21752402"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 09:05:10 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	09:05:09 -0500
Message-ID: <4F328114.60506@citrix.com>
Date: Wed, 8 Feb 2012 14:05:08 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CB57BF48.2A9B6%keir.xen@gmail.com>
In-Reply-To: <CB57BF48.2A9B6%keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/12 05:57, Keir Fraser wrote:
> On 08/02/2012 13:14, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
>
>> Hi,
>>
>> while locking at the vpmu stuff I found the following stuff:
>>
>> diff -r a55e0f9c7b4e xen/arch/x86/oprofile/nmi_int.c
>> --- a/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 12:28:47 2012 +0100
>> +++ b/xen/arch/x86/oprofile/nmi_int.c Wed Feb 08 14:11:06 2012 +0100
>> @@ -305,7 +305,7 @@ static int __init p4_init(char ** cpu_ty
>> }
>>  
>>  #ifndef CONFIG_SMP
>> - *cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
>> + *cpu_type = "i386/p4";
>> model = &op_p4_spec;
>> return 1;
>>  #else
>>
>>
>> Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.
> Correct. !CONFIG_SMP isn't configurable or supported.
>
>  -- Keir

A naive test:

andrewcoop@andrewcoop:/local/xen-unstable.hg/xen$ rgrep "CONFIG_SMP" * |
wc -l
166

Seems there are quite a few bits to remove.  If noone has done so, when
I get round to gutting #ifdef __ia64__'s from the arch/x86 tree I shall
do the same with CONFIG_SMP.

~Andrew

>> Thanks.
>>
>> Dietmar.
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:10:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14: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.xensource.com>)
	id 1Rv8DZ-0000pX-CL; Wed, 08 Feb 2012 14:09:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rv8DY-0000pN-6A
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:09:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328710184!10638004!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8526 invoked from network); 8 Feb 2012 14:09:46 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:09:46 -0000
Received: by iaeh11 with SMTP id h11so4560647iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=vH7f528ECDBMH2m5QvKFf34H9+nWux6P5vHHhwowleQ=;
	b=pTUrtHJuowHu8WtMHUrv6ccdvqM/wA+3h8tdjWUGuxXR43XkOisI19gLTIYsvcbdsg
	YSe2yEWmLZW4v2O1J97QonVMtJF46vzXoPoq+kbUU8JXl2HursKErkzoI1pAAxOJmQdZ
	BE98NPljxnMnp3VRwpbm6r2G+/KbXdW5Vigf0=
Received: by 10.50.104.164 with SMTP id gf4mr19701044igb.28.1328710184610;
	Wed, 08 Feb 2012 06:09:44 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id nq10sm84742igc.6.2012.02.08.06.09.40
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:09:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 06:09:34 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB57C21E.2A9BD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
Thread-Index: Aczma0iNcj/AH7Nrdku32ZcmA9m6qA==
In-Reply-To: <4F328114.60506@citrix.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 14:05, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>>> Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.
>> Correct. !CONFIG_SMP isn't configurable or supported.
>> 
>>  -- Keir
> 
> A naive test:
> 
> andrewcoop@andrewcoop:/local/xen-unstable.hg/xen$ rgrep "CONFIG_SMP" * |
> wc -l
> 166
> 
> Seems there are quite a few bits to remove.  If noone has done so, when
> I get round to gutting #ifdef __ia64__'s from the arch/x86 tree I shall
> do the same with CONFIG_SMP.

Yeah we never actually went and deleted the !CONFIG_SMP bits we inherited
from Linux. You can feel free to clean it up afaic.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:10:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14: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.xensource.com>)
	id 1Rv8DZ-0000pX-CL; Wed, 08 Feb 2012 14:09:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rv8DY-0000pN-6A
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:09:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328710184!10638004!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8526 invoked from network); 8 Feb 2012 14:09:46 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:09:46 -0000
Received: by iaeh11 with SMTP id h11so4560647iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=vH7f528ECDBMH2m5QvKFf34H9+nWux6P5vHHhwowleQ=;
	b=pTUrtHJuowHu8WtMHUrv6ccdvqM/wA+3h8tdjWUGuxXR43XkOisI19gLTIYsvcbdsg
	YSe2yEWmLZW4v2O1J97QonVMtJF46vzXoPoq+kbUU8JXl2HursKErkzoI1pAAxOJmQdZ
	BE98NPljxnMnp3VRwpbm6r2G+/KbXdW5Vigf0=
Received: by 10.50.104.164 with SMTP id gf4mr19701044igb.28.1328710184610;
	Wed, 08 Feb 2012 06:09:44 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id nq10sm84742igc.6.2012.02.08.06.09.40
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:09:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 06:09:34 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB57C21E.2A9BD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
Thread-Index: Aczma0iNcj/AH7Nrdku32ZcmA9m6qA==
In-Reply-To: <4F328114.60506@citrix.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] vpmu: Is CONFIG_SMP used anymore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 14:05, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>>> Is CONFIG_SMP always switched on? It seems nobody tested without CONFIG_SMP.
>> Correct. !CONFIG_SMP isn't configurable or supported.
>> 
>>  -- Keir
> 
> A naive test:
> 
> andrewcoop@andrewcoop:/local/xen-unstable.hg/xen$ rgrep "CONFIG_SMP" * |
> wc -l
> 166
> 
> Seems there are quite a few bits to remove.  If noone has done so, when
> I get round to gutting #ifdef __ia64__'s from the arch/x86 tree I shall
> do the same with CONFIG_SMP.

Yeah we never actually went and deleted the !CONFIG_SMP bits we inherited
from Linux. You can feel free to clean it up afaic.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8Iw-0000zL-4u; Wed, 08 Feb 2012 14:15:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8Iu-0000zF-Kl
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:15:24 +0000
Received: from [85.158.139.83:12134] by server-4.bemta-5.messagelabs.com id
	BF/97-28576-B73823F4; Wed, 08 Feb 2012 14:15:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328710522!14245894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27202 invoked from network); 8 Feb 2012 14:15:23 -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;
	8 Feb 2012 14:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10575403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 14:15:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	14:15:22 +0000
Message-ID: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Wed, 8 Feb 2012 14:15:20 +0000
In-Reply-To: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
> Xen Developers,
> 
> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
> but not used warning for variable 'message' in function init_kbdfront.
> (Looks like another one just like it, in function init_fbfront, from
> the same file.) My source won't compile with these warnings. I could
> not find a patch for this in xen-4.1-testing.hg Xenbits.

This new, enabled by default, compiler warning is very annoying, even
though it happens to be correct. Which distro has done it? (or maybe
it's just new enough gcc which is to blame).

> It looks like a conditional printk got left out after the label
> 'abort_transaction'. I don't understand fbfront.c well enough to
> suggest a patch. Its low priority for me, because I am going to stick
> some plausible code in there for now.

I think an unconditional printk including the %s and message is all
which is required here. If you've got some plausible code you may as
well post it.

Thanks,
Ian.

> 
> Sincerely,
> 
> John
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
> 
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8Iw-0000zL-4u; Wed, 08 Feb 2012 14:15:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8Iu-0000zF-Kl
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:15:24 +0000
Received: from [85.158.139.83:12134] by server-4.bemta-5.messagelabs.com id
	BF/97-28576-B73823F4; Wed, 08 Feb 2012 14:15:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328710522!14245894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27202 invoked from network); 8 Feb 2012 14:15:23 -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;
	8 Feb 2012 14:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10575403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 14:15:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	14:15:22 +0000
Message-ID: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Wed, 8 Feb 2012 14:15:20 +0000
In-Reply-To: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
> Xen Developers,
> 
> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
> but not used warning for variable 'message' in function init_kbdfront.
> (Looks like another one just like it, in function init_fbfront, from
> the same file.) My source won't compile with these warnings. I could
> not find a patch for this in xen-4.1-testing.hg Xenbits.

This new, enabled by default, compiler warning is very annoying, even
though it happens to be correct. Which distro has done it? (or maybe
it's just new enough gcc which is to blame).

> It looks like a conditional printk got left out after the label
> 'abort_transaction'. I don't understand fbfront.c well enough to
> suggest a patch. Its low priority for me, because I am going to stick
> some plausible code in there for now.

I think an unconditional printk including the %s and message is all
which is required here. If you've got some plausible code you may as
well post it.

Thanks,
Ian.

> 
> Sincerely,
> 
> John
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
> 
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8QD-0001F4-2S; Wed, 08 Feb 2012 14:22:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rv8QB-0001Ey-NU
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:22:55 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328710968!8310235!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16464 invoked from network); 8 Feb 2012 14:22:49 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 14:22:49 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 845AE207C;
	Wed,  8 Feb 2012 16:22:47 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 45C7120058; Wed,  8 Feb 2012 16:22:47 +0200 (EET)
Date: Wed, 8 Feb 2012 16:22:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120208142247.GW12984@reaktio.net>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:18:39PM +0000, George Dunlap wrote:
> On Tue, Feb 7, 2012 at 8:12 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Hey George,
> >
> > I was wondering if you could explain in simple terms how the scheduler would
> > handle per-physical CPU when there are say 16 guests (each guest is using
> > one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would
> > the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so
> > on; or would it be more random? (I assume that both guest and dom0 would do
> > a hypercall yield too).
> 
> The scheduling would be random.  As far as I know, none of the
> schedulers (sedf, credit1, or credit2) treat domain 0 differently from
> any other domain.  Even guests which are very busy end up blocking
> quite a bit, so the total runtime ends up being fairly random anyway.
> Also, the dom0 vcpus are not pinned unless you specify dom0_pin_vcpus
> on the xen command-line; so by default they will migrate freely around
> the various cores.
> 
> Does that answer your question?
> 

I don't know if it's relevant to this discussion but I tend to often
increase the credit scheduler weight of dom0 vcpus to guarantee smooth operation of dom0.

http://wiki.xen.org/wiki/Xen_Best_Practices

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8QD-0001F4-2S; Wed, 08 Feb 2012 14:22:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rv8QB-0001Ey-NU
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:22:55 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328710968!8310235!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16464 invoked from network); 8 Feb 2012 14:22:49 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 14:22:49 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 845AE207C;
	Wed,  8 Feb 2012 16:22:47 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 45C7120058; Wed,  8 Feb 2012 16:22:47 +0200 (EET)
Date: Wed, 8 Feb 2012 16:22:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120208142247.GW12984@reaktio.net>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:18:39PM +0000, George Dunlap wrote:
> On Tue, Feb 7, 2012 at 8:12 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Hey George,
> >
> > I was wondering if you could explain in simple terms how the scheduler would
> > handle per-physical CPU when there are say 16 guests (each guest is using
> > one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would
> > the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so
> > on; or would it be more random? (I assume that both guest and dom0 would do
> > a hypercall yield too).
> 
> The scheduling would be random.  As far as I know, none of the
> schedulers (sedf, credit1, or credit2) treat domain 0 differently from
> any other domain.  Even guests which are very busy end up blocking
> quite a bit, so the total runtime ends up being fairly random anyway.
> Also, the dom0 vcpus are not pinned unless you specify dom0_pin_vcpus
> on the xen command-line; so by default they will migrate freely around
> the various cores.
> 
> Does that answer your question?
> 

I don't know if it's relevant to this discussion but I tend to often
increase the credit scheduler weight of dom0 vcpus to guarantee smooth operation of dom0.

http://wiki.xen.org/wiki/Xen_Best_Practices

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:25:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14: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.xensource.com>)
	id 1Rv8Rx-0001JI-Il; Wed, 08 Feb 2012 14:24:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8Rw-0001J5-F0
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:24:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328711075!14010117!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16164 invoked from network); 8 Feb 2012 14:24:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325480400"; d="scan'208";a="21752982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 09:24:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 09:24:34 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q18EOWU8001718;	Wed, 8 Feb 2012 06:24:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: 264ae15cae53cbc4dc22ba8de88e0152efd7f57f
Message-ID: <264ae15cae53cbc4dc22.1328711071@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 8 Feb 2012 14:24:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Todd Deshane <todd.deshane@xen.org>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] stubdoms: update README to reference xl
	configuration syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328711023 0
# Node ID 264ae15cae53cbc4dc22ba8de88e0152efd7f57f
# Parent  285bbed90f36d3e7e01dcca72b1af93605f44b18
stubdoms: update README to reference xl configuration syntax

Remove reference to fsback -- it was removed some time ago.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 285bbed90f36 -r 264ae15cae53 stubdom/README
--- a/stubdom/README	Thu Feb 02 13:37:47 2012 +0000
+++ b/stubdom/README	Wed Feb 08 14:23:43 2012 +0000
@@ -10,6 +10,20 @@ Due to a race between the creation of th
 of video memory for the HVM domain, you need to avoid the need for ballooning,
 by using the hypervisor dom0_mem= option for instance.
 
+Using with XL
+-------------
+
+The enable IOEMU stub domains set the following in your domain
+config:
+
+    device_model_stubdomain_override = 1
+
+See xl.cfg(5) for more details of the xl domain configuration syntax
+and http://wiki.xen.org/wiki/Device_Model_Stub_Domains for more
+information on device model stub domains
+
+Using with XM/xend
+------------------
 
 There is a sample configuration set in xmexample.hvm-stubdom
 
@@ -18,19 +32,6 @@ In your HVM config "hvmconfig" use stubd
 device_model = 'stubdom-dm'
 
 
-To run
-======
-
-mkdir -p /exports/usr/share/xen/qemu
-ln -s /usr/share/xen/qemu/keymaps /exports/usr/share/xen/qemu
-mkdir -p /exports/var/lib
-ln -s /var/lib/xen /exports/var/lib
-/usr/sbin/fs-backend &
-
-xm create hvmconfig
-
-
-
                                    PV-GRUB
                                    =======
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:25:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14: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.xensource.com>)
	id 1Rv8Rx-0001JI-Il; Wed, 08 Feb 2012 14:24:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8Rw-0001J5-F0
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:24:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328711075!14010117!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16164 invoked from network); 8 Feb 2012 14:24:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325480400"; d="scan'208";a="21752982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 09:24:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 09:24:34 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q18EOWU8001718;	Wed, 8 Feb 2012 06:24:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: 264ae15cae53cbc4dc22ba8de88e0152efd7f57f
Message-ID: <264ae15cae53cbc4dc22.1328711071@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 8 Feb 2012 14:24:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Todd Deshane <todd.deshane@xen.org>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] stubdoms: update README to reference xl
	configuration syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328711023 0
# Node ID 264ae15cae53cbc4dc22ba8de88e0152efd7f57f
# Parent  285bbed90f36d3e7e01dcca72b1af93605f44b18
stubdoms: update README to reference xl configuration syntax

Remove reference to fsback -- it was removed some time ago.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 285bbed90f36 -r 264ae15cae53 stubdom/README
--- a/stubdom/README	Thu Feb 02 13:37:47 2012 +0000
+++ b/stubdom/README	Wed Feb 08 14:23:43 2012 +0000
@@ -10,6 +10,20 @@ Due to a race between the creation of th
 of video memory for the HVM domain, you need to avoid the need for ballooning,
 by using the hypervisor dom0_mem= option for instance.
 
+Using with XL
+-------------
+
+The enable IOEMU stub domains set the following in your domain
+config:
+
+    device_model_stubdomain_override = 1
+
+See xl.cfg(5) for more details of the xl domain configuration syntax
+and http://wiki.xen.org/wiki/Device_Model_Stub_Domains for more
+information on device model stub domains
+
+Using with XM/xend
+------------------
 
 There is a sample configuration set in xmexample.hvm-stubdom
 
@@ -18,19 +32,6 @@ In your HVM config "hvmconfig" use stubd
 device_model = 'stubdom-dm'
 
 
-To run
-======
-
-mkdir -p /exports/usr/share/xen/qemu
-ln -s /usr/share/xen/qemu/keymaps /exports/usr/share/xen/qemu
-mkdir -p /exports/var/lib
-ln -s /var/lib/xen /exports/var/lib
-/usr/sbin/fs-backend &
-
-xm create hvmconfig
-
-
-
                                    PV-GRUB
                                    =======
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8t6-0001dY-04; Wed, 08 Feb 2012 14:52:48 +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 1Rv8t3-0001dQ-TC
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:52:46 +0000
Received: from [85.158.139.83:7038] by server-12.bemta-5.messagelabs.com id
	B3/BA-30830-C3C823F4; Wed, 08 Feb 2012 14:52:44 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328712764!14204436!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16204 invoked from network); 8 Feb 2012 14:52:44 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:52:44 -0000
Received: by bkcjg15 with SMTP id jg15so973503bkc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:52:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=5bV/4eMT/iEWo3ohty5gVu2/lCv4G0AwDWowzEgeUI8=;
	b=hgxddl9Lz6CcSGc6GLpZK2dUnnd8rJ2W+A5VN+RnTz42n3CTRKcSO5f7pLE7hRwsL0
	Dy5GNMEk4cFHQQk4c+EDFK5Dxr8DD52DXdNVLd+LXScj0ADeLKmUesv4HOp4Q+6VwCmp
	quWFeV3agqPeiaWzwzbe8/JWcXXWbrGM3Me1Q=
Received: by 10.204.150.82 with SMTP id x18mr12819174bkv.51.1328712763693;
	Wed, 08 Feb 2012 06:52:43 -0800 (PST)
Received: from [172.16.26.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id ez5sm5167462bkc.15.2012.02.08.06.52.41
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:52:42 -0800 (PST)
Message-ID: <4F328C36.7080305@xen.org>
Date: Wed, 08 Feb 2012 14:52:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Hackathon in March: ideas for T-shirts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If anybody has ideas for T-shirts let me know
Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8t6-0001dY-04; Wed, 08 Feb 2012 14:52:48 +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 1Rv8t3-0001dQ-TC
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:52:46 +0000
Received: from [85.158.139.83:7038] by server-12.bemta-5.messagelabs.com id
	B3/BA-30830-C3C823F4; Wed, 08 Feb 2012 14:52:44 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328712764!14204436!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16204 invoked from network); 8 Feb 2012 14:52:44 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:52:44 -0000
Received: by bkcjg15 with SMTP id jg15so973503bkc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:52:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=5bV/4eMT/iEWo3ohty5gVu2/lCv4G0AwDWowzEgeUI8=;
	b=hgxddl9Lz6CcSGc6GLpZK2dUnnd8rJ2W+A5VN+RnTz42n3CTRKcSO5f7pLE7hRwsL0
	Dy5GNMEk4cFHQQk4c+EDFK5Dxr8DD52DXdNVLd+LXScj0ADeLKmUesv4HOp4Q+6VwCmp
	quWFeV3agqPeiaWzwzbe8/JWcXXWbrGM3Me1Q=
Received: by 10.204.150.82 with SMTP id x18mr12819174bkv.51.1328712763693;
	Wed, 08 Feb 2012 06:52:43 -0800 (PST)
Received: from [172.16.26.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id ez5sm5167462bkc.15.2012.02.08.06.52.41
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:52:42 -0800 (PST)
Message-ID: <4F328C36.7080305@xen.org>
Date: Wed, 08 Feb 2012 14:52:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Hackathon in March: ideas for T-shirts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If anybody has ideas for T-shirts let me know
Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:53:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8tj-0001g4-Dz; Wed, 08 Feb 2012 14:53:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8ti-0001fJ-7i
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:53:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328712800!8316569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30783 invoked from network); 8 Feb 2012 14:53:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:53:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10576481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 14:53:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	14:53:20 +0000
Message-ID: <1328712798.6133.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 8 Feb 2012 14:53:18 +0000
In-Reply-To: <1328538755451-5460198.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 14:32 +0000, Fantu wrote:
> I tried to use cdrom in domU linux pv (Linux Mint 11 based on Natty).
> With '/mnt/vm/iso/test.iso,raw,xvdb,ro,cdrom', Mint sees it as internal disk
> (not cdrom) and only administrators can mount it.
> I tried also '/dev/scd0,raw,xvdb,ro,cdrom' does the same thing.
> Is possible use cdrom on linux domU pv full working where also normal user
> can mount it without terminal?

It should be. Please can you provide the output of "xenstore-ls -fp"
when the guest is running with the device attached.

Also from within the guest can you run (as root):
	udevadm info --query=all --path /block/xvdb
and post the output.

> Did I something wrong, or are there still bugs in this regard?

The most recent bugs of this type were in udev and not Xen and caused it
to fail to correctly detect Xen CD-ROMs as such. If the above indicates
everything is OK on the Xen side then we can delve into that a little
deeper but in the meantime what version of udev are you running in the
guest?

> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24593:e2722b24dc09

What is the domU kernel version?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:53:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:53:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8tj-0001g4-Dz; Wed, 08 Feb 2012 14:53:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8ti-0001fJ-7i
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:53:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328712800!8316569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30783 invoked from network); 8 Feb 2012 14:53:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:53:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10576481"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 14:53:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	14:53:20 +0000
Message-ID: <1328712798.6133.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 8 Feb 2012 14:53:18 +0000
In-Reply-To: <1328538755451-5460198.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 14:32 +0000, Fantu wrote:
> I tried to use cdrom in domU linux pv (Linux Mint 11 based on Natty).
> With '/mnt/vm/iso/test.iso,raw,xvdb,ro,cdrom', Mint sees it as internal disk
> (not cdrom) and only administrators can mount it.
> I tried also '/dev/scd0,raw,xvdb,ro,cdrom' does the same thing.
> Is possible use cdrom on linux domU pv full working where also normal user
> can mount it without terminal?

It should be. Please can you provide the output of "xenstore-ls -fp"
when the guest is running with the device attached.

Also from within the guest can you run (as root):
	udevadm info --query=all --path /block/xvdb
and post the output.

> Did I something wrong, or are there still bugs in this regard?

The most recent bugs of this type were in udev and not Xen and caused it
to fail to correctly detect Xen CD-ROMs as such. If the above indicates
everything is OK on the Xen side then we can delve into that a little
deeper but in the meantime what version of udev are you running in the
guest?

> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24593:e2722b24dc09

What is the domU kernel version?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:54:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8uj-0001lm-25; Wed, 08 Feb 2012 14:54:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1Rv8uh-0001lE-BH
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:54:27 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328712859!12528631!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23419 invoked from network); 8 Feb 2012 14:54:20 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:54:20 -0000
Received: by obcuy19 with SMTP id uy19so3018359obc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:54:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=l87v5/U6zkqpFLOmucjt8R1hWMqWVmNDvMA1MhpnamU=;
	b=mwmG3glGPtg60bIqEbClKfSIJrVJ9b8o1f15qqUmhmTjubMoY31FxegcUB4Sh2nAPY
	6B5B2aCb3w59qqII2F2saJufrVBQ9murm6mqiGWUO3uEFgDFm6yP3JOWKAgxTuZQnhjR
	R3Hy6hq0okDZWTG80xwLtCR1ng8gE2AJGf0JI=
Received: by 10.182.38.7 with SMTP id c7mr25777676obk.44.1328712859187; Wed,
	08 Feb 2012 06:54:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.4.231 with HTTP; Wed, 8 Feb 2012 06:53:59 -0800 (PST)
In-Reply-To: <1328707739.6133.16.camel@zakaz.uk.xensource.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
	<1328707739.6133.16.camel@zakaz.uk.xensource.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 14:53:59 +0000
X-Google-Sender-Auth: OUEhf2VpP_Z2I_nXvGBKWS7F8V0
Message-ID: <CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxOjI4IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPiB3cm90ZToKPiBPbiBTdW4sIDIwMTItMDItMDUgYXQgMTY6MTggKzAwMDAs
IEp1bGlhbiBQaWRhbmNldCB3cm90ZToKPj4gV2hlbiBib290aW5nIEhWTXMgd2l0aCBTZWFCSU9T
LCB0aGUgQklPUyBpdHNlbGYgdGFrZXMgY2FyZSBvZiBleHRyYWN0aW5nCj4+IG9wdGlvbiBST01z
IGZyb20gdGhlIFBDSSBkZXZpY2VzLiBUaGVzZSBST01zIGFyZSB1c3VhbGx5IHByb3ZpZGVkIHdp
dGggYnkKPj4gdGhlIGRldmljZSBtb2RlbCAocWVtdSkuCj4+IFRodXMsIGh2bWxvYWRlciBzaG91
bGQgbm90IHJlcXVpcmUgYW55IGxvbmdlciB0aGUgcm9tYmlvcywgc3RkdmdhLAo+PiBjaXJydXN2
Z2Egb3IgZXRoZXJib290IFJPTXMgdG8gYmUgcHJlc2VudC4KPj4KPj4gQWxzbywgdGhlIDMyYml0
Ymlvc19zdXBwb3J0LmMgZmlsZSBpcyBzcGVjaWZpYyB0byByb21iaW9zIGFuZCBzaG91bGQgbm90
Cj4+IGJlIGJ1aWx0IHdoZW4gYnVpbGRpbmcgaHZtbG9hZGVyIHdpdGggc2VhYmlvcy4KPgo+PiBb
Li4uXQo+PiBAQCAtNDc1LDE2ICs0NzcsMjAgQEAgaW50IG1haW4odm9pZCkKPj4gwqAgwqAgwqAg
wqAgc3dpdGNoICggdmlydHVhbF92Z2EgKQo+PiDCoCDCoCDCoCDCoCDCoHsKPj4gwqAgwqAgwqAg
wqAgwqBjYXNlIFZHQV9jaXJydXM6Cj4+ICsjaWZkZWYgRU5BQkxFX0NJUlJVU1ZHQQo+Cj4gSnVz
dCBvdXRzaWRlIHRoZSBjb250ZXh0IGhlcmUgaXMgYW4gImlmICggYmlvcy0+bG9hZF9yb21zICki
IHdoaWNoCj4gcHJldmVudHMgdGhlIFJPTXMgZnJvbSBiZWluZyBsb2FkZWQgaWYgd2UgYXJlIHVz
aW5nIFNlYUJJT1MgLS0gaXMgdGhhdAo+IG5vdCBzdWZmaWNpZW50IGZvciB5b3VyIG5lZWRzPwo+
Cj4gQ3VycmVudGx5IGh2bWxvYWRlciBidWlsZHMgd2l0aCBzdXBwb3J0IGZvciBib3RoIFJPTUJJ
T1MgYW5kIFNlYUJJT1MgYW5kCj4gc2VsZWN0cyB0aGUgb25lIHRvIHVzZSBiYXNlZCBvbiBhIGNv
bmZpZ3VyYXRpb24ga2V5IGluIHhlbnN0b3JlIChwdXNoZWQKPiBkb3duIGJ5IHRoZSB0b29sc3Rh
Y2sgZGVwZW5kaW5nIG9uIHdoaWNoIHFlbXUgeW91IGFyZSBydW5uaW5nKS4gSGF2ZSB5b3UKPiBt
b2RpZmllZCBzb21ldGhpbmcgZWxzZXdoZXJlIGluIG9yZGVyIHRvIGJ1aWxkIGEgU2VhQklPUy1v
bmx5IGh2bWxvYWRlcj8KPgo+IFBlcmhhcHMgaXQgd291bGQgbWFrZSBzZW5zZSBmb3IgdGhlIFJP
TXMgdG8gYmUga2V5ZWQgb2ZmIHdoZXRoZXIgb3Igbm90Cj4gUk9NQklPUyBpcyBlbmFibGVkIHJh
dGhlciB0aGFuIGVhY2gga2V5aW5nIG9mZiB0aGVpciBvd24gRElSIHZhcj8KPgo+IFlvdSBzZWVt
IHRvIGhhdmUgbWl4ZWQgc29tZSBvdGhlciBjaGFuZ2VzLCBzcGVjaWZpY2FsbHkgcy86PS8/PS8g
aW4gYQo+IGZldyBwbGFjZXMgYW5kIGFsc28gc29tZSBzb3J0IG9mIGNoYW5nZSB3cnQgaG93IGVi
LXJvbXMuaCBpcyBnZW5lcmF0ZWQKPiAoaW5jbHVkaW5nIGRyb3BwaW5nIHRoZSA4MDg2MTAwZSBS
T00gZnJvbSB0aGUgaW1hZ2UsIHdoaWNoIG11c3QgYmUKPiBkaXNjdXNzZWQpLgo+Cj4gVGhlc2Ug
b3RoZXIgY2hhbmdlcyBzaG91bGQgYmUgc3VibWl0dGVkIGFuZCByYXRpb25hbGlzZWQgc2VwYXJh
dGVseS4KPgoKVGhlIHB1cnBvc2Ugb2YgdGhpcyBjaGFuZ2Ugd2FzIGluaXRpYWxseSB0byBhbGxv
dyB0aGUgdXNlciB0byBidWlsZApodm1sb2FkZXIgd2l0aCBTZWFCSU9TIG9ubHkgd2l0aG91dCBo
YXZpbmcgdG8gZGVwZW5kIG9uIHJvbWJpb3MsCnZnYWJpb3Mgb3IgaXB4ZS4gSSd2ZSBvbmx5IHRl
c3RlZCBteSBjaGFuZ2VzIGJ5IGNhbGxpbmcgbWFrZSBmcm9tIHRoZQpodm1sb2FkZXIvIGRpcmVj
dG9yeSBkaXJlY3RseS4gVGhlIFhlbiBidWlsZCBzeXN0ZW0gY291bGQgYWxzbyBub3QKaGF2ZSB0
byBkZXBlbmQgb24gYmNjIGZvciBleGFtcGxlLgoKSW4gYWRkaXRpb24gdG8gdGhlIHBhdGNoIEkg
c3VibWl0dGVkLCBJIHN1cHBvc2UgaXQgd291bGQgbWFrZSBzZW5zZSB0bwppbnRyb2R1Y2UgYSBn
bG9iYWwgY29uZmlndXJhdGlvbiBvcHRpb24gZm9yIHRoZSBNYWtlZmlsZSBpbiB0aGUKZmlybXdh
cmUvIGRpcmVjdG9yeSB0byBkZWNpZGUgd2V0aGVyIGl0IHNob3VsZCByZWN1cnNlIGluIHRoZSBy
b21iaW9zLAp2Z2FiaW9zLCBhbmQgZXRoZXJib290IGRpcmVjdG9yaWVzLgoKSSBjaGFuZ2VkIHNv
bWUgdmFyaWFibGUgYXNzaWduYXRpb25zIDo9IGJ5ID89IGJlY2F1c2UgSSB3YW50ZWQgdGhlCnVz
ZXIgb2YgdGhlIGJ1aWxkIHN5c3RlbSB0byBiZSBhYmxlIHRvIHNwZWNpZnkgYSBjdXN0b20gYnVp
bGQKZGlyZWN0b3J5IGZvciB0aGVzZSBST01zLgoKU2FtZSB0aGluZyBmb3IgdGhlIGV0aGVyYm9v
dCBST00sIEkgbWFkZSB0aGUgTWFrZWZpbGUgbm90IHVzZSBlYi1yb20uaAphbmQgcmVwbGFjZSBp
dCB3aXRoIGEgY2FsbCB0byBta2hleCBvbiB0aGUgYmluYXJ5IGZpbGUgZGlyZWN0bHksIHNvCnRo
ZSB1c2VyIGNhbiBjaG9vc2Ugd2hpY2ggUk9NIHRvIGluamVjdCBpbnRvIGh2bWxvYWRlciwgYW5k
IEkgZm91bmQgaXQKdG8gYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIE1h
a2VmaWxlLgoKLS0gCkp1bGlhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:54:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8uj-0001lm-25; Wed, 08 Feb 2012 14:54:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1Rv8uh-0001lE-BH
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:54:27 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328712859!12528631!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23419 invoked from network); 8 Feb 2012 14:54:20 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:54:20 -0000
Received: by obcuy19 with SMTP id uy19so3018359obc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 06:54:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=l87v5/U6zkqpFLOmucjt8R1hWMqWVmNDvMA1MhpnamU=;
	b=mwmG3glGPtg60bIqEbClKfSIJrVJ9b8o1f15qqUmhmTjubMoY31FxegcUB4Sh2nAPY
	6B5B2aCb3w59qqII2F2saJufrVBQ9murm6mqiGWUO3uEFgDFm6yP3JOWKAgxTuZQnhjR
	R3Hy6hq0okDZWTG80xwLtCR1ng8gE2AJGf0JI=
Received: by 10.182.38.7 with SMTP id c7mr25777676obk.44.1328712859187; Wed,
	08 Feb 2012 06:54:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.4.231 with HTTP; Wed, 8 Feb 2012 06:53:59 -0800 (PST)
In-Reply-To: <1328707739.6133.16.camel@zakaz.uk.xensource.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
	<1328707739.6133.16.camel@zakaz.uk.xensource.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 14:53:59 +0000
X-Google-Sender-Auth: OUEhf2VpP_Z2I_nXvGBKWS7F8V0
Message-ID: <CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxOjI4IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPiB3cm90ZToKPiBPbiBTdW4sIDIwMTItMDItMDUgYXQgMTY6MTggKzAwMDAs
IEp1bGlhbiBQaWRhbmNldCB3cm90ZToKPj4gV2hlbiBib290aW5nIEhWTXMgd2l0aCBTZWFCSU9T
LCB0aGUgQklPUyBpdHNlbGYgdGFrZXMgY2FyZSBvZiBleHRyYWN0aW5nCj4+IG9wdGlvbiBST01z
IGZyb20gdGhlIFBDSSBkZXZpY2VzLiBUaGVzZSBST01zIGFyZSB1c3VhbGx5IHByb3ZpZGVkIHdp
dGggYnkKPj4gdGhlIGRldmljZSBtb2RlbCAocWVtdSkuCj4+IFRodXMsIGh2bWxvYWRlciBzaG91
bGQgbm90IHJlcXVpcmUgYW55IGxvbmdlciB0aGUgcm9tYmlvcywgc3RkdmdhLAo+PiBjaXJydXN2
Z2Egb3IgZXRoZXJib290IFJPTXMgdG8gYmUgcHJlc2VudC4KPj4KPj4gQWxzbywgdGhlIDMyYml0
Ymlvc19zdXBwb3J0LmMgZmlsZSBpcyBzcGVjaWZpYyB0byByb21iaW9zIGFuZCBzaG91bGQgbm90
Cj4+IGJlIGJ1aWx0IHdoZW4gYnVpbGRpbmcgaHZtbG9hZGVyIHdpdGggc2VhYmlvcy4KPgo+PiBb
Li4uXQo+PiBAQCAtNDc1LDE2ICs0NzcsMjAgQEAgaW50IG1haW4odm9pZCkKPj4gwqAgwqAgwqAg
wqAgc3dpdGNoICggdmlydHVhbF92Z2EgKQo+PiDCoCDCoCDCoCDCoCDCoHsKPj4gwqAgwqAgwqAg
wqAgwqBjYXNlIFZHQV9jaXJydXM6Cj4+ICsjaWZkZWYgRU5BQkxFX0NJUlJVU1ZHQQo+Cj4gSnVz
dCBvdXRzaWRlIHRoZSBjb250ZXh0IGhlcmUgaXMgYW4gImlmICggYmlvcy0+bG9hZF9yb21zICki
IHdoaWNoCj4gcHJldmVudHMgdGhlIFJPTXMgZnJvbSBiZWluZyBsb2FkZWQgaWYgd2UgYXJlIHVz
aW5nIFNlYUJJT1MgLS0gaXMgdGhhdAo+IG5vdCBzdWZmaWNpZW50IGZvciB5b3VyIG5lZWRzPwo+
Cj4gQ3VycmVudGx5IGh2bWxvYWRlciBidWlsZHMgd2l0aCBzdXBwb3J0IGZvciBib3RoIFJPTUJJ
T1MgYW5kIFNlYUJJT1MgYW5kCj4gc2VsZWN0cyB0aGUgb25lIHRvIHVzZSBiYXNlZCBvbiBhIGNv
bmZpZ3VyYXRpb24ga2V5IGluIHhlbnN0b3JlIChwdXNoZWQKPiBkb3duIGJ5IHRoZSB0b29sc3Rh
Y2sgZGVwZW5kaW5nIG9uIHdoaWNoIHFlbXUgeW91IGFyZSBydW5uaW5nKS4gSGF2ZSB5b3UKPiBt
b2RpZmllZCBzb21ldGhpbmcgZWxzZXdoZXJlIGluIG9yZGVyIHRvIGJ1aWxkIGEgU2VhQklPUy1v
bmx5IGh2bWxvYWRlcj8KPgo+IFBlcmhhcHMgaXQgd291bGQgbWFrZSBzZW5zZSBmb3IgdGhlIFJP
TXMgdG8gYmUga2V5ZWQgb2ZmIHdoZXRoZXIgb3Igbm90Cj4gUk9NQklPUyBpcyBlbmFibGVkIHJh
dGhlciB0aGFuIGVhY2gga2V5aW5nIG9mZiB0aGVpciBvd24gRElSIHZhcj8KPgo+IFlvdSBzZWVt
IHRvIGhhdmUgbWl4ZWQgc29tZSBvdGhlciBjaGFuZ2VzLCBzcGVjaWZpY2FsbHkgcy86PS8/PS8g
aW4gYQo+IGZldyBwbGFjZXMgYW5kIGFsc28gc29tZSBzb3J0IG9mIGNoYW5nZSB3cnQgaG93IGVi
LXJvbXMuaCBpcyBnZW5lcmF0ZWQKPiAoaW5jbHVkaW5nIGRyb3BwaW5nIHRoZSA4MDg2MTAwZSBS
T00gZnJvbSB0aGUgaW1hZ2UsIHdoaWNoIG11c3QgYmUKPiBkaXNjdXNzZWQpLgo+Cj4gVGhlc2Ug
b3RoZXIgY2hhbmdlcyBzaG91bGQgYmUgc3VibWl0dGVkIGFuZCByYXRpb25hbGlzZWQgc2VwYXJh
dGVseS4KPgoKVGhlIHB1cnBvc2Ugb2YgdGhpcyBjaGFuZ2Ugd2FzIGluaXRpYWxseSB0byBhbGxv
dyB0aGUgdXNlciB0byBidWlsZApodm1sb2FkZXIgd2l0aCBTZWFCSU9TIG9ubHkgd2l0aG91dCBo
YXZpbmcgdG8gZGVwZW5kIG9uIHJvbWJpb3MsCnZnYWJpb3Mgb3IgaXB4ZS4gSSd2ZSBvbmx5IHRl
c3RlZCBteSBjaGFuZ2VzIGJ5IGNhbGxpbmcgbWFrZSBmcm9tIHRoZQpodm1sb2FkZXIvIGRpcmVj
dG9yeSBkaXJlY3RseS4gVGhlIFhlbiBidWlsZCBzeXN0ZW0gY291bGQgYWxzbyBub3QKaGF2ZSB0
byBkZXBlbmQgb24gYmNjIGZvciBleGFtcGxlLgoKSW4gYWRkaXRpb24gdG8gdGhlIHBhdGNoIEkg
c3VibWl0dGVkLCBJIHN1cHBvc2UgaXQgd291bGQgbWFrZSBzZW5zZSB0bwppbnRyb2R1Y2UgYSBn
bG9iYWwgY29uZmlndXJhdGlvbiBvcHRpb24gZm9yIHRoZSBNYWtlZmlsZSBpbiB0aGUKZmlybXdh
cmUvIGRpcmVjdG9yeSB0byBkZWNpZGUgd2V0aGVyIGl0IHNob3VsZCByZWN1cnNlIGluIHRoZSBy
b21iaW9zLAp2Z2FiaW9zLCBhbmQgZXRoZXJib290IGRpcmVjdG9yaWVzLgoKSSBjaGFuZ2VkIHNv
bWUgdmFyaWFibGUgYXNzaWduYXRpb25zIDo9IGJ5ID89IGJlY2F1c2UgSSB3YW50ZWQgdGhlCnVz
ZXIgb2YgdGhlIGJ1aWxkIHN5c3RlbSB0byBiZSBhYmxlIHRvIHNwZWNpZnkgYSBjdXN0b20gYnVp
bGQKZGlyZWN0b3J5IGZvciB0aGVzZSBST01zLgoKU2FtZSB0aGluZyBmb3IgdGhlIGV0aGVyYm9v
dCBST00sIEkgbWFkZSB0aGUgTWFrZWZpbGUgbm90IHVzZSBlYi1yb20uaAphbmQgcmVwbGFjZSBp
dCB3aXRoIGEgY2FsbCB0byBta2hleCBvbiB0aGUgYmluYXJ5IGZpbGUgZGlyZWN0bHksIHNvCnRo
ZSB1c2VyIGNhbiBjaG9vc2Ugd2hpY2ggUk9NIHRvIGluamVjdCBpbnRvIGh2bWxvYWRlciwgYW5k
IEkgZm91bmQgaXQKdG8gYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIE1h
a2VmaWxlLgoKLS0gCkp1bGlhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:56:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8wb-0001vh-IS; Wed, 08 Feb 2012 14:56:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8wZ-0001vH-Du
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:56:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328712977!2720125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14076 invoked from network); 8 Feb 2012 14:56:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:56:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10576579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 14:56:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	14:56:16 +0000
Message-ID: <1328712975.6133.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 8 Feb 2012 14:56:15 +0000
In-Reply-To: <1328630915898-5463631.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328630915898-5463631.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-07 at 16:08 +0000, Fantu wrote:
> I updated xen to changeset 24701:3574f4d67843 and also tried with xl
> cd-insert and it failed with this error:
> 
> xl cd-insert MINT12PV xvdb raw:/dev/scd0
> libxl: error: libxl.c:1579:libxl_cdrom_insert: Virtual device not found
> 
> I used wrong parameters or is there a bug?

cd-insert is an HVM guest command, it must refer to an existing emulated
CD-ROM device. Since you say you are using PV this can't exist.

The error message could probably be improved here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 14:56:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 14:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rv8wb-0001vh-IS; Wed, 08 Feb 2012 14:56:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rv8wZ-0001vH-Du
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:56:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328712977!2720125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14076 invoked from network); 8 Feb 2012 14:56:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 14:56:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="10576579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 14:56:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	14:56:16 +0000
Message-ID: <1328712975.6133.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 8 Feb 2012 14:56:15 +0000
In-Reply-To: <1328630915898-5463631.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328630915898-5463631.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-07 at 16:08 +0000, Fantu wrote:
> I updated xen to changeset 24701:3574f4d67843 and also tried with xl
> cd-insert and it failed with this error:
> 
> xl cd-insert MINT12PV xvdb raw:/dev/scd0
> libxl: error: libxl.c:1579:libxl_cdrom_insert: Virtual device not found
> 
> I used wrong parameters or is there a bug?

cd-insert is an HVM guest command, it must refer to an existing emulated
CD-ROM device. Since you say you are using PV this can't exist.

The error message could probably be improved here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:02:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv91w-0002G2-BL; Wed, 08 Feb 2012 15:01:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rv91v-0002Fv-Lc
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:01:55 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328713291!65015087!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13985 invoked from network); 8 Feb 2012 15:01:32 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-15.tower-27.messagelabs.com with SMTP;
	8 Feb 2012 15:01:32 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q18F1o7e016663;
	Wed, 8 Feb 2012 10:01:50 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q18F1fJM013097;
	Wed, 8 Feb 2012 10:01:41 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020810014131902 ; Wed, 08 Feb 2012 10:01:41 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
Date: Wed, 8 Feb 2012 10:01:41 -0500
Message-Id: <6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

Agreed; this warning is very annoying. The problem is in several files, like a design pattern issue. So far it has popped up in fbfront.c, blkfront.c, and netfront.c, but the code is nice clean code, so the problem is very regular. We are running Fedora 16 and Xen 4.1.2.

----

[mc@xenpro3 ~]$ gcc --version
gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

----

Here is an example of what I have been doing to get rid of the warning:

----
[mc@xenpro3 xenon]$ hg diff extras/mini-os/fbfront.c
diff -r 8cfe801d065d extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c	Mon Feb 06 08:37:59 2012 -0500
+++ b/extras/mini-os/fbfront.c	Wed Feb 08 09:52:06 2012 -0500
@@ -142,6 +142,9 @@
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    if (message) {
+	printk("Abort transaction %s", message);
+    }
     goto error;
 
 done:
@@ -503,6 +506,9 @@
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    if (message) {
+	printk("Abort transaction %s", message);
+    }
     goto error;
 
 
 done:
[mc@xenpro3 xenon]$
----

On Feb 8, 2012, at 9:15 AM, Ian Campbell wrote:

> On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
>> Xen Developers,
>> 
>> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
>> but not used warning for variable 'message' in function init_kbdfront.
>> (Looks like another one just like it, in function init_fbfront, from
>> the same file.) My source won't compile with these warnings. I could
>> not find a patch for this in xen-4.1-testing.hg Xenbits.
> 
> This new, enabled by default, compiler warning is very annoying, even
> though it happens to be correct. Which distro has done it? (or maybe
> it's just new enough gcc which is to blame).
> 
>> It looks like a conditional printk got left out after the label
>> 'abort_transaction'. I don't understand fbfront.c well enough to
>> suggest a patch. Its low priority for me, because I am going to stick
>> some plausible code in there for now.
> 
> I think an unconditional printk including the %s and message is all
> which is required here. If you've got some plausible code you may as
> well post it.
> 
> Thanks,
> Ian.
> 
>> 
>> Sincerely,
>> 
>> John
>> ----
>> What is the formal meaning of the one-line program
>> #include "/dev/tty"
>> 
>> J.P. McDermott			building 12
>> Code 5542			john.mcdermott@nrl.navy.mil
>> Naval Research Laboratory	voice: +1 202.404.8301
>> Washington, DC 20375, US	fax:   +1 202.404.7942
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:02:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv91w-0002G2-BL; Wed, 08 Feb 2012 15:01:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rv91v-0002Fv-Lc
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:01:55 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328713291!65015087!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13985 invoked from network); 8 Feb 2012 15:01:32 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-15.tower-27.messagelabs.com with SMTP;
	8 Feb 2012 15:01:32 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q18F1o7e016663;
	Wed, 8 Feb 2012 10:01:50 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q18F1fJM013097;
	Wed, 8 Feb 2012 10:01:41 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020810014131902 ; Wed, 08 Feb 2012 10:01:41 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
Date: Wed, 8 Feb 2012 10:01:41 -0500
Message-Id: <6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

Agreed; this warning is very annoying. The problem is in several files, like a design pattern issue. So far it has popped up in fbfront.c, blkfront.c, and netfront.c, but the code is nice clean code, so the problem is very regular. We are running Fedora 16 and Xen 4.1.2.

----

[mc@xenpro3 ~]$ gcc --version
gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

----

Here is an example of what I have been doing to get rid of the warning:

----
[mc@xenpro3 xenon]$ hg diff extras/mini-os/fbfront.c
diff -r 8cfe801d065d extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c	Mon Feb 06 08:37:59 2012 -0500
+++ b/extras/mini-os/fbfront.c	Wed Feb 08 09:52:06 2012 -0500
@@ -142,6 +142,9 @@
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    if (message) {
+	printk("Abort transaction %s", message);
+    }
     goto error;
 
 done:
@@ -503,6 +506,9 @@
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    if (message) {
+	printk("Abort transaction %s", message);
+    }
     goto error;
 
 
 done:
[mc@xenpro3 xenon]$
----

On Feb 8, 2012, at 9:15 AM, Ian Campbell wrote:

> On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
>> Xen Developers,
>> 
>> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
>> but not used warning for variable 'message' in function init_kbdfront.
>> (Looks like another one just like it, in function init_fbfront, from
>> the same file.) My source won't compile with these warnings. I could
>> not find a patch for this in xen-4.1-testing.hg Xenbits.
> 
> This new, enabled by default, compiler warning is very annoying, even
> though it happens to be correct. Which distro has done it? (or maybe
> it's just new enough gcc which is to blame).
> 
>> It looks like a conditional printk got left out after the label
>> 'abort_transaction'. I don't understand fbfront.c well enough to
>> suggest a patch. Its low priority for me, because I am going to stick
>> some plausible code in there for now.
> 
> I think an unconditional printk including the %s and message is all
> which is required here. If you've got some plausible code you may as
> well post it.
> 
> Thanks,
> Ian.
> 
>> 
>> Sincerely,
>> 
>> John
>> ----
>> What is the formal meaning of the one-line program
>> #include "/dev/tty"
>> 
>> J.P. McDermott			building 12
>> Code 5542			john.mcdermott@nrl.navy.mil
>> Naval Research Laboratory	voice: +1 202.404.8301
>> Washington, DC 20375, US	fax:   +1 202.404.7942
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:19:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv9Ij-0002WX-0i; Wed, 08 Feb 2012 15:19:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rv9Ii-0002WP-5I
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:19:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328714348!12517193!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17523 invoked from network); 8 Feb 2012 15:19:09 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 15:19:09 -0000
Received: by ghbf1 with SMTP id f1so9066600ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 07:19:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=ld3V6ZSOz9khtzqCO01WqyeHKqEuWJskkhliHrv4teI=;
	b=tFed+G9zndbFbXHh4KkJOdXfmvmLfj7dukJiMxe2+dCKIUA2r1vLo9jsdwTdDrG5ds
	7zXMdtXmn6XFT4MPoCaYED63lHXlXQI0Q5kMgPqevBwBZuvzvuK+38Q1J2Vue7dg+Vhh
	ugk2zNV0/JROIicFASBmmoq8pjJUg6w8D0oqY=
Received: by 10.50.179.8 with SMTP id dc8mr18234090igc.19.1328714348434;
	Wed, 08 Feb 2012 07:19:08 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id ch2sm2618607igb.4.2012.02.08.07.19.05
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 07:19:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 07:19:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	John McDermott CIV <john.mcdermott@nrl.navy.mil>
Message-ID: <CB57D267.2A9D3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Mini-os fbfront.c unused variable complaint
Thread-Index: AczmdP14UbYkbAWcKEmFRMf1Otwspw==
In-Reply-To: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 14:15, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
>> Xen Developers,
>> 
>> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
>> but not used warning for variable 'message' in function init_kbdfront.
>> (Looks like another one just like it, in function init_fbfront, from
>> the same file.) My source won't compile with these warnings. I could
>> not find a patch for this in xen-4.1-testing.hg Xenbits.
> 
> This new, enabled by default, compiler warning is very annoying, even
> though it happens to be correct. Which distro has done it? (or maybe
> it's just new enough gcc which is to blame).

We should be disablign this warning in Config.mk, where we add
-Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
$(call cc-option-add ...) because older gcc versions do not have this
warning.

 -- Keir

>> It looks like a conditional printk got left out after the label
>> 'abort_transaction'. I don't understand fbfront.c well enough to
>> suggest a patch. Its low priority for me, because I am going to stick
>> some plausible code in there for now.
> 
> I think an unconditional printk including the %s and message is all
> which is required here. If you've got some plausible code you may as
> well post it.
> 
> Thanks,
> Ian.
> 
>> 
>> Sincerely,
>> 
>> John
>> ----
>> What is the formal meaning of the one-line program
>> #include "/dev/tty"
>> 
>> J.P. McDermott   building 12
>> Code 5542   john.mcdermott@nrl.navy.mil
>> Naval Research Laboratory voice: +1 202.404.8301
>> Washington, DC 20375, US fax:   +1 202.404.7942
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:19:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv9Ij-0002WX-0i; Wed, 08 Feb 2012 15:19:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rv9Ii-0002WP-5I
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:19:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328714348!12517193!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17523 invoked from network); 8 Feb 2012 15:19:09 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 15:19:09 -0000
Received: by ghbf1 with SMTP id f1so9066600ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 07:19:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=ld3V6ZSOz9khtzqCO01WqyeHKqEuWJskkhliHrv4teI=;
	b=tFed+G9zndbFbXHh4KkJOdXfmvmLfj7dukJiMxe2+dCKIUA2r1vLo9jsdwTdDrG5ds
	7zXMdtXmn6XFT4MPoCaYED63lHXlXQI0Q5kMgPqevBwBZuvzvuK+38Q1J2Vue7dg+Vhh
	ugk2zNV0/JROIicFASBmmoq8pjJUg6w8D0oqY=
Received: by 10.50.179.8 with SMTP id dc8mr18234090igc.19.1328714348434;
	Wed, 08 Feb 2012 07:19:08 -0800 (PST)
Received: from [101.1.150.14] ([96.49.152.177])
	by mx.google.com with ESMTPS id ch2sm2618607igb.4.2012.02.08.07.19.05
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 07:19:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 07:19:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	John McDermott CIV <john.mcdermott@nrl.navy.mil>
Message-ID: <CB57D267.2A9D3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Mini-os fbfront.c unused variable complaint
Thread-Index: AczmdP14UbYkbAWcKEmFRMf1Otwspw==
In-Reply-To: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 14:15, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
>> Xen Developers,
>> 
>> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
>> but not used warning for variable 'message' in function init_kbdfront.
>> (Looks like another one just like it, in function init_fbfront, from
>> the same file.) My source won't compile with these warnings. I could
>> not find a patch for this in xen-4.1-testing.hg Xenbits.
> 
> This new, enabled by default, compiler warning is very annoying, even
> though it happens to be correct. Which distro has done it? (or maybe
> it's just new enough gcc which is to blame).

We should be disablign this warning in Config.mk, where we add
-Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
$(call cc-option-add ...) because older gcc versions do not have this
warning.

 -- Keir

>> It looks like a conditional printk got left out after the label
>> 'abort_transaction'. I don't understand fbfront.c well enough to
>> suggest a patch. Its low priority for me, because I am going to stick
>> some plausible code in there for now.
> 
> I think an unconditional printk including the %s and message is all
> which is required here. If you've got some plausible code you may as
> well post it.
> 
> Thanks,
> Ian.
> 
>> 
>> Sincerely,
>> 
>> John
>> ----
>> What is the formal meaning of the one-line program
>> #include "/dev/tty"
>> 
>> J.P. McDermott   building 12
>> Code 5542   john.mcdermott@nrl.navy.mil
>> Naval Research Laboratory voice: +1 202.404.8301
>> Washington, DC 20375, US fax:   +1 202.404.7942
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:31:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv9UX-0002hR-8m; Wed, 08 Feb 2012 15:31:29 +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 1Rv9UV-0002hM-MS
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:31:27 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328715042!59310988!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10027 invoked from network); 8 Feb 2012 15:30:43 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2012 15:30:43 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rv9US-0002OV-P8
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:31:24 -0800
Date: Wed, 8 Feb 2012 07:31:24 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328715084770-5466814.post@n5.nabble.com>
In-Reply-To: <1328712975.6133.49.camel@zakaz.uk.xensource.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328630915898-5463631.post@n5.nabble.com>
	<1328712975.6133.49.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply
And about cdrom full working on domU pv? (not see as internal disk)

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5466814.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:31:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv9UX-0002hR-8m; Wed, 08 Feb 2012 15:31:29 +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 1Rv9UV-0002hM-MS
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:31:27 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328715042!59310988!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10027 invoked from network); 8 Feb 2012 15:30:43 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2012 15:30:43 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rv9US-0002OV-P8
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 07:31:24 -0800
Date: Wed, 8 Feb 2012 07:31:24 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328715084770-5466814.post@n5.nabble.com>
In-Reply-To: <1328712975.6133.49.camel@zakaz.uk.xensource.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328630915898-5463631.post@n5.nabble.com>
	<1328712975.6133.49.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply
And about cdrom full working on domU pv? (not see as internal disk)

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5466814.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:59:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv9va-0002yA-OF; Wed, 08 Feb 2012 15:59:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglist@modernbiztonsag.org>) id 1Rv9vZ-0002y5-VM
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:59:26 +0000
X-Env-Sender: mailinglist@modernbiztonsag.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328716759!7396617!1
X-Originating-IP: [212.52.166.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6684 invoked from network); 8 Feb 2012 15:59:19 -0000
Received: from mail.modernbiztonsag.org (HELO mail.modernbiztonsag.org)
	(212.52.166.188)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 15:59:19 -0000
Received: from admin.modernbiztonsag.org (www.jails [10.0.0.4])
	by mail.modernbiztonsag.org (Postfix) with ESMTP id CF2D615A011
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 16:59:18 +0100 (CET)
Received: from 80.99.60.12 (proxying for 80.99.60.12)
	(SquirrelMail authenticated user mailinglist@modernbiztonsag.org)
	by admin.modernbiztonsag.org with HTTP;
	Wed, 8 Feb 2012 16:59:18 +0100
Message-ID: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
Date: Wed, 8 Feb 2012 16:59:18 +0100
From: mailinglist@modernbiztonsag.org
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary="----=_20120208165918_79727"
X-Priority: 3 (Normal)
Importance: Normal
Subject: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

------=_20120208165918_79727
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Dear List,

i'm experimenting with remus with the following setup.

dom0:
- Debian Squeeze
- Jeremy's 2.6.38.48 kernel
- xen 4.1.2 recompiled from sid
- DRBD for block device backend

domU
- Debian Squeeze

Remus is working fine unless i try to give more than 1 core to the domU.

Here's the error from remus when i'm trying to enable it for an SMP domU:

Traceback (most recent call last):
  File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
    run(cfg)
  File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
    dom = vm.VM(cfg.domid)
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in __init__
    self.loaddominfo()
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in loaddominfo
    self.dom = parsedominfo(self.dominfo)
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
parsedominfo
    return s2d(dominfo[1:])
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
    val = s2d(elem[1:])
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
    return s2d(elem)
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
    for k, v in val.iteritems():
AttributeError: 'int' object has no attribute 'iteritems'

I've attached the domU configuration file.

Please let me know if you need more info on this.

Best regards,
Mate
------=_20120208165918_79727
Content-Type: application/octet-stream; name="core-test"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="core-test"

a2VybmVsID0gIi9ib290L3ZtbGludXotMi42LjMyLjQ4LXJlbXVzIgpyYW1kaXNrID0gIi9ib290
L2luaXRyZC5pbWctMi42LjMyLjQ4LXJlbXVzIgojIG9wY2lvbmFsaXNhbiBtZWdhZGhhdGp1ayBh
IENQVSBzemFtaXQgKGFsYXBib2wgMS1ldCBrYXApCnZjcHVzID0gMgojIG9wY2lvbmFsaXNhbiBt
ZWdhZGhhdGp1aywgaG9neSBtZWx5aWsgZml6aWthaSBtYWdva2F0IGhhc3puYWxoYXRqYSAoYWxh
cGJvbCBkaW5hbWlrdXNhbiBvc3p0amEgc3pldCk7IGF6ZXJ0IDEtdG9sLCBtZXJ0IGEgMC4gY29y
ZS10IGEgZG9tMCBrYXBqYSBkZWRpa2FsdGFuCmNwdXMgPSAiMS0xNSIKbWVtb3J5ID0gMTAyNApu
YW1lID0gImNvcmUtdGVzdCIKdmlmID0gWyAnbWFjPTUyOjU0OmYwOjliOjY2OjY4LGJyaWRnZT1i
cjEnLCAnbWFjPTUyOjU0OmRiOmYzOmNkOmU3LGJyaWRnZT1icjAnIF0KZGlzayA9IFsnZHJiZDpj
b3JldGVzdCx4dmRhMSx3JywnZHJiZDpjb3JldGVzdF9zd2FwLHh2ZGEyLHcnXQpob3N0bmFtZSA9
ICJjb3JlLXRlc3QiCnJvb3QgPSAiL2Rldi94dmRhMSBybyIKZXh0cmEgPSAiNCIKCg==
------=_20120208165918_79727
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=_20120208165918_79727--




From xen-devel-bounces@lists.xensource.com Wed Feb 08 15:59:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 15: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.xensource.com>)
	id 1Rv9va-0002yA-OF; Wed, 08 Feb 2012 15:59:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglist@modernbiztonsag.org>) id 1Rv9vZ-0002y5-VM
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 15:59:26 +0000
X-Env-Sender: mailinglist@modernbiztonsag.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328716759!7396617!1
X-Originating-IP: [212.52.166.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6684 invoked from network); 8 Feb 2012 15:59:19 -0000
Received: from mail.modernbiztonsag.org (HELO mail.modernbiztonsag.org)
	(212.52.166.188)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 15:59:19 -0000
Received: from admin.modernbiztonsag.org (www.jails [10.0.0.4])
	by mail.modernbiztonsag.org (Postfix) with ESMTP id CF2D615A011
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 16:59:18 +0100 (CET)
Received: from 80.99.60.12 (proxying for 80.99.60.12)
	(SquirrelMail authenticated user mailinglist@modernbiztonsag.org)
	by admin.modernbiztonsag.org with HTTP;
	Wed, 8 Feb 2012 16:59:18 +0100
Message-ID: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
Date: Wed, 8 Feb 2012 16:59:18 +0100
From: mailinglist@modernbiztonsag.org
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary="----=_20120208165918_79727"
X-Priority: 3 (Normal)
Importance: Normal
Subject: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

------=_20120208165918_79727
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Dear List,

i'm experimenting with remus with the following setup.

dom0:
- Debian Squeeze
- Jeremy's 2.6.38.48 kernel
- xen 4.1.2 recompiled from sid
- DRBD for block device backend

domU
- Debian Squeeze

Remus is working fine unless i try to give more than 1 core to the domU.

Here's the error from remus when i'm trying to enable it for an SMP domU:

Traceback (most recent call last):
  File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
    run(cfg)
  File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
    dom = vm.VM(cfg.domid)
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in __init__
    self.loaddominfo()
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in loaddominfo
    self.dom = parsedominfo(self.dominfo)
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
parsedominfo
    return s2d(dominfo[1:])
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
    val = s2d(elem[1:])
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
    return s2d(elem)
  File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
    for k, v in val.iteritems():
AttributeError: 'int' object has no attribute 'iteritems'

I've attached the domU configuration file.

Please let me know if you need more info on this.

Best regards,
Mate
------=_20120208165918_79727
Content-Type: application/octet-stream; name="core-test"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="core-test"

a2VybmVsID0gIi9ib290L3ZtbGludXotMi42LjMyLjQ4LXJlbXVzIgpyYW1kaXNrID0gIi9ib290
L2luaXRyZC5pbWctMi42LjMyLjQ4LXJlbXVzIgojIG9wY2lvbmFsaXNhbiBtZWdhZGhhdGp1ayBh
IENQVSBzemFtaXQgKGFsYXBib2wgMS1ldCBrYXApCnZjcHVzID0gMgojIG9wY2lvbmFsaXNhbiBt
ZWdhZGhhdGp1aywgaG9neSBtZWx5aWsgZml6aWthaSBtYWdva2F0IGhhc3puYWxoYXRqYSAoYWxh
cGJvbCBkaW5hbWlrdXNhbiBvc3p0amEgc3pldCk7IGF6ZXJ0IDEtdG9sLCBtZXJ0IGEgMC4gY29y
ZS10IGEgZG9tMCBrYXBqYSBkZWRpa2FsdGFuCmNwdXMgPSAiMS0xNSIKbWVtb3J5ID0gMTAyNApu
YW1lID0gImNvcmUtdGVzdCIKdmlmID0gWyAnbWFjPTUyOjU0OmYwOjliOjY2OjY4LGJyaWRnZT1i
cjEnLCAnbWFjPTUyOjU0OmRiOmYzOmNkOmU3LGJyaWRnZT1icjAnIF0KZGlzayA9IFsnZHJiZDpj
b3JldGVzdCx4dmRhMSx3JywnZHJiZDpjb3JldGVzdF9zd2FwLHh2ZGEyLHcnXQpob3N0bmFtZSA9
ICJjb3JlLXRlc3QiCnJvb3QgPSAiL2Rldi94dmRhMSBybyIKZXh0cmEgPSAiNCIKCg==
------=_20120208165918_79727
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=_20120208165918_79727--




From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAAd-0003Xk-7n; Wed, 08 Feb 2012 16:14:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RvAAb-0003Xf-FC
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:14:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328717690!6042562!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2957 invoked from network); 8 Feb 2012 16:14:51 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:14:51 -0000
Received: by yenm7 with SMTP id m7so9631541yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 08:14:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=JgpprbYXP99dENNb/dFP/rdko8wS0n/Ffz60aMgl3Ik=;
	b=uslvHePNCT4K4K0GjFVfXIJ5JSXKZ7VSGk63N59lta+QX0KvgPikQjvsqgXTRadeLB
	MBo5HMyshANWWrRqVDCZk3XgdE2jfvyHrJRyC3H27gLeOuh8+tpP5KPGy7S+0fPzS4My
	RaxvhX8upJSZokiWEuPk7YXbTtiwy7hCoZzRo=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr24249852igb.10.1328717689753;
	Wed, 08 Feb 2012 08:14:49 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Wed, 8 Feb 2012 08:14:49 -0800 (PST)
In-Reply-To: <20120208142247.GW12984@reaktio.net>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
	<20120208142247.GW12984@reaktio.net>
Date: Wed, 8 Feb 2012 16:14:49 +0000
X-Google-Sender-Auth: DUS7Vstb3iClflGAWqNJMc2wkuQ
Message-ID: <CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 8, 2012 at 2:22 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> I don't know if it's relevant to this discussion but I tend to often
> increase the credit scheduler weight of dom0 vcpus to guarantee smooth op=
eration of dom0.

In fact, XenServer has a patch that will automatically adjust dom0's
weight based on the weight of other VMs running on the system, in an
attempt to make sure dom0 can get enough cpu time.

I haven't submitted it to the list, because I don't think it's really
appropriate for the open-source tree.  But I'll dig it out and post it
as an RFC; even if it's not ultimately accepted, it might not be bad
to have the patch floating around.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAAd-0003Xk-7n; Wed, 08 Feb 2012 16:14:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RvAAb-0003Xf-FC
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:14:57 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328717690!6042562!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2957 invoked from network); 8 Feb 2012 16:14:51 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:14:51 -0000
Received: by yenm7 with SMTP id m7so9631541yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 08:14:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=JgpprbYXP99dENNb/dFP/rdko8wS0n/Ffz60aMgl3Ik=;
	b=uslvHePNCT4K4K0GjFVfXIJ5JSXKZ7VSGk63N59lta+QX0KvgPikQjvsqgXTRadeLB
	MBo5HMyshANWWrRqVDCZk3XgdE2jfvyHrJRyC3H27gLeOuh8+tpP5KPGy7S+0fPzS4My
	RaxvhX8upJSZokiWEuPk7YXbTtiwy7hCoZzRo=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr24249852igb.10.1328717689753;
	Wed, 08 Feb 2012 08:14:49 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Wed, 8 Feb 2012 08:14:49 -0800 (PST)
In-Reply-To: <20120208142247.GW12984@reaktio.net>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
	<20120208142247.GW12984@reaktio.net>
Date: Wed, 8 Feb 2012 16:14:49 +0000
X-Google-Sender-Auth: DUS7Vstb3iClflGAWqNJMc2wkuQ
Message-ID: <CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 8, 2012 at 2:22 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> I don't know if it's relevant to this discussion but I tend to often
> increase the credit scheduler weight of dom0 vcpus to guarantee smooth op=
eration of dom0.

In fact, XenServer has a patch that will automatically adjust dom0's
weight based on the weight of other VMs running on the system, in an
attempt to make sure dom0 can get enough cpu time.

I haven't submitted it to the list, because I don't think it's really
appropriate for the open-source tree.  But I'll dig it out and post it
as an RFC; even if it's not ultimately accepted, it might not be bad
to have the patch floating around.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:20:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAFy-0003mK-LQ; Wed, 08 Feb 2012 16:20:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvAFx-0003m4-7h
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:20:29 +0000
Received: from [85.158.139.83:23091] by server-7.bemta-5.messagelabs.com id
	53/7C-01252-CC0A23F4; Wed, 08 Feb 2012 16:20:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328718021!13401383!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 8 Feb 2012 16:20:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 16:20:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 16:20:21 +0000
Message-Id: <4F32AED30200007800071BA3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 16:20:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
	<CB57C010.2A9B8%keir.xen@gmail.com>
In-Reply-To: <CB57C010.2A9B8%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Justin Gibbs <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 07:00, Keir Fraser <keir.xen@gmail.com> wrote:
> I guess I think of the whole header set under xen/include/public as one
> unit, versioned by __XEN_INTERFACE_VERSION__. And that's how users are
> generally syncing with our headers -- copy them in their entirety over the
> top of the old ones.

Minus the fact that copying them in their entirety isn't possible with what
is upstream in Linux, as they diverged in more than just white space.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:20:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:20:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAFy-0003mK-LQ; Wed, 08 Feb 2012 16:20:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvAFx-0003m4-7h
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:20:29 +0000
Received: from [85.158.139.83:23091] by server-7.bemta-5.messagelabs.com id
	53/7C-01252-CC0A23F4; Wed, 08 Feb 2012 16:20:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328718021!13401383!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 8 Feb 2012 16:20:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 16:20:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 08 Feb 2012 16:20:21 +0000
Message-Id: <4F32AED30200007800071BA3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 08 Feb 2012 16:20:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
	<CB57C010.2A9B8%keir.xen@gmail.com>
In-Reply-To: <CB57C010.2A9B8%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Justin Gibbs <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 07:00, Keir Fraser <keir.xen@gmail.com> wrote:
> I guess I think of the whole header set under xen/include/public as one
> unit, versioned by __XEN_INTERFACE_VERSION__. And that's how users are
> generally syncing with our headers -- copy them in their entirety over the
> top of the old ones.

Minus the fact that copying them in their entirety isn't possible with what
is upstream in Linux, as they diverged in more than just white space.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:32:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16: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.xensource.com>)
	id 1RvARH-0004EW-Hc; Wed, 08 Feb 2012 16:32:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvARE-0004EO-Tb
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:32:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328718681!59321456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29055 invoked from network); 8 Feb 2012 16:31:21 -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;
	8 Feb 2012 16:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:32:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:32:04 +0000
Message-ID: <1328718722.6133.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 8 Feb 2012 16:32:02 +0000
In-Reply-To: <20273.24520.100024.694018@mariner.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Andy, 

Good to meet you over the w.e.

On Tue, 2012-02-07 at 17:30 +0000, Ian Jackson wrote:
> Andy Smith writes ("[Xen-devel] Re-reading domain configs on domain restart"):
> > I understand this will never be fixed in xend/xm, but would it be
> > possible to have xl re-read the domU's config when the domU
> > restarts?
> 
> Yes, this would certainly be possible.  Straightforward, even.
> There are two questions we need to answer first:
> 
> Firstly, how should this be requested ?  I think a command-line option
> to xl would do the trick.

Where would you give it? Giving it to create might be unhelpful if you
only decide you need it when you come to reboot. Giving to reboot is
tricky since then you need that xl to communicate with the one actually
managing the reboots etc (we could deal with that though).

Another option would be to allow it as an option to the on_FOO=bar in
the configuration file. There's a bit of a combinatorial explosion going
on there though (coredump & X, rename & X etc) and it has the same
problem with being too late at reboot time to change your mind.

> Secondly, should we change the default behaviour ?  I'd be inclined
> towards "yes" as the current arrangement is really rather perverse,
> but I'm open to opinions.

I lean that way too, although if higher level tools using xl are e.g.
writing to a /tmp file which they delete after start up then might that
be an issue?

Eventually I'd like to see a libxl function which can reconstitute a
libxl_domain_config from a running domains, such that it is sufficient
to pass to libxl_domain_create to recreate that domain. That needn't
block this functionality though.

> In the longer term, in the spirit of xl, it might be a good idea to
> give the user the option of running a hook script when the domain
> dies/reboots/etc.  This would simplify a number of things.

Yes, hooks are a good idea.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:32:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16: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.xensource.com>)
	id 1RvARH-0004EW-Hc; Wed, 08 Feb 2012 16:32:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvARE-0004EO-Tb
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:32:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328718681!59321456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29055 invoked from network); 8 Feb 2012 16:31:21 -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;
	8 Feb 2012 16:31:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:32:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:32:04 +0000
Message-ID: <1328718722.6133.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 8 Feb 2012 16:32:02 +0000
In-Reply-To: <20273.24520.100024.694018@mariner.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Andy, 

Good to meet you over the w.e.

On Tue, 2012-02-07 at 17:30 +0000, Ian Jackson wrote:
> Andy Smith writes ("[Xen-devel] Re-reading domain configs on domain restart"):
> > I understand this will never be fixed in xend/xm, but would it be
> > possible to have xl re-read the domU's config when the domU
> > restarts?
> 
> Yes, this would certainly be possible.  Straightforward, even.
> There are two questions we need to answer first:
> 
> Firstly, how should this be requested ?  I think a command-line option
> to xl would do the trick.

Where would you give it? Giving it to create might be unhelpful if you
only decide you need it when you come to reboot. Giving to reboot is
tricky since then you need that xl to communicate with the one actually
managing the reboots etc (we could deal with that though).

Another option would be to allow it as an option to the on_FOO=bar in
the configuration file. There's a bit of a combinatorial explosion going
on there though (coredump & X, rename & X etc) and it has the same
problem with being too late at reboot time to change your mind.

> Secondly, should we change the default behaviour ?  I'd be inclined
> towards "yes" as the current arrangement is really rather perverse,
> but I'm open to opinions.

I lean that way too, although if higher level tools using xl are e.g.
writing to a /tmp file which they delete after start up then might that
be an issue?

Eventually I'd like to see a libxl function which can reconstitute a
libxl_domain_config from a running domains, such that it is sufficient
to pass to libxl_domain_create to recreate that domain. That needn't
block this functionality though.

> In the longer term, in the spirit of xl, it might be a good idea to
> give the user the option of running a hook script when the domain
> dies/reboots/etc.  This would simplify a number of things.

Yes, hooks are a good idea.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:36:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAV3-0004NP-2Q; Wed, 08 Feb 2012 16:36:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAV0-0004My-Pf
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:36:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328718956!10641485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24762 invoked from network); 8 Feb 2012 16:35:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:35:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:35:56 +0000
Message-ID: <1328718954.6133.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Date: Wed, 8 Feb 2012 16:35:54 +0000
In-Reply-To: <4F317B58.4010405@invisiblethingslab.com>
References: <4F317B58.4010405@invisiblethingslab.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:
> Is there a convenient way to setup the IP address for the _stubdom_ (to
> connect to the vnc server running there) from within the corresponding
> HVM config file on Xen 4.1? Or should one use dhcpd?

Currently the model with stubdomains is that the stub domain runs a PVFB
device against a backend in dom0 (actually, another qemu) which does the
vnc export etc so there is no networking to the stub dom.

I can see valid reasons why you would want to have the stubdom itself do
the vnc export and therefore have a network of its own but I don't think
the toolstack can express that right now. I think it was done in the
early days of stubdoms, but I suspect in some hacky way (or perhaps just
DHCP), and I don't know if that functionality has persisted to the
present day.

Patches would be welcome.

Ian.

> 
> Thanks,
> joanna.
> 
> ps. Sorry for posting this to xen-devel, instead of xen-users -- next
> time I will subscribe to the latter, I promise ;)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:36:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAV3-0004NP-2Q; Wed, 08 Feb 2012 16:36:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAV0-0004My-Pf
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:36:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328718956!10641485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24762 invoked from network); 8 Feb 2012 16:35:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:35:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:35:56 +0000
Message-ID: <1328718954.6133.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Date: Wed, 8 Feb 2012 16:35:54 +0000
In-Reply-To: <4F317B58.4010405@invisiblethingslab.com>
References: <4F317B58.4010405@invisiblethingslab.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:
> Is there a convenient way to setup the IP address for the _stubdom_ (to
> connect to the vnc server running there) from within the corresponding
> HVM config file on Xen 4.1? Or should one use dhcpd?

Currently the model with stubdomains is that the stub domain runs a PVFB
device against a backend in dom0 (actually, another qemu) which does the
vnc export etc so there is no networking to the stub dom.

I can see valid reasons why you would want to have the stubdom itself do
the vnc export and therefore have a network of its own but I don't think
the toolstack can express that right now. I think it was done in the
early days of stubdoms, but I suspect in some hacky way (or perhaps just
DHCP), and I don't know if that functionality has persisted to the
present day.

Patches would be welcome.

Ian.

> 
> Thanks,
> joanna.
> 
> ps. Sorry for posting this to xen-devel, instead of xen-users -- next
> time I will subscribe to the latter, I promise ;)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAV7-0004Np-PI; Wed, 08 Feb 2012 16:36:09 +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 1RvAV5-0004NI-06
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:36:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328718910!51929961!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7901 invoked from network); 8 Feb 2012 16:35:11 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:35:11 -0000
Received: by iaeh11 with SMTP id h11so160717iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 08:36:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=sQuRyZyhveON/KxBlgCSeKtBx1biKE/QyO5ODICzyOM=;
	b=pwdbQE6g8YHSiOkarWYYjJBwowK7eS9/r/e6XUig4a81ULHbmiia1sEmyx2SvKG5mJ
	gpgbRC541jVWchRo5YJ0trKU35WZuZcIS0y9NBmeMA6/ppEk4zFZw80+LPQQ5Ik/BSQ0
	7ojirDLu5CTtXq9mxm6y0zZwmXe8kNrvDAn1A=
Received: by 10.50.189.134 with SMTP id gi6mr24518893igc.18.1328718960803;
	Wed, 08 Feb 2012 08:36:00 -0800 (PST)
Received: from [206.12.39.140] ([206.12.39.140])
	by mx.google.com with ESMTPS id va6sm622291igc.4.2012.02.08.08.35.54
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 08:35:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 08:35:50 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB57E466.2AA79%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
Thread-Index: Aczmf7d0Hnfa8KYa/0SEQRPycT0vhw==
In-Reply-To: <1327077375-7623-7-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 16:35, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> - make the compilation of ns16550.c depend upon HAS_NS16550;
> 
> - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> 
> - make the compilation of pci depend upon HAS_PCI;
> 
> - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> 
> - make the compilation of kexec depend upon HAS_KEXEC.
> 
> 
> Changes in v2:
> 
> - introduce HAS_KEXEC and CONFIG_KEXEC kexec.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
>  xen/arch/ia64/Rules.mk        |    5 +++++
>  xen/arch/x86/Rules.mk         |    5 +++++
>  xen/common/Makefile           |    2 +-
>  xen/common/shutdown.c         |    4 ++++
>  xen/drivers/Makefile          |    6 +++---
>  xen/drivers/char/Makefile     |    2 +-
>  xen/drivers/char/console.c    |    4 ++++
>  xen/include/asm-ia64/config.h |    1 +
>  xen/include/asm-x86/config.h  |    1 +
>  9 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
> index bef11c3..054b4de 100644
> --- a/xen/arch/ia64/Rules.mk
> +++ b/xen/arch/ia64/Rules.mk
> @@ -4,6 +4,11 @@
>  ia64 := y
>  HAS_ACPI := y
>  HAS_VGA  := y
> +HAS_CPUFREQ := y
> +HAS_PCI := y
> +HAS_PASSTHROUGH := y
> +HAS_NS16550 := y
> +HAS_KEXEC := y
>  xenoprof := y
>  no_warns ?= n
>  vti_debug ?= n
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index 9fc6d42..65275af 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -3,6 +3,11 @@
>  
>  HAS_ACPI := y
>  HAS_VGA  := y
> +HAS_CPUFREQ := y
> +HAS_PCI := y
> +HAS_PASSTHROUGH := y
> +HAS_NS16550 := y
> +HAS_KEXEC := y
>  xenoprof := y
>  
>  #
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 1d85e65..9249845 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -8,7 +8,7 @@ obj-y += grant_table.o
>  obj-y += irq.o
>  obj-y += kernel.o
>  obj-y += keyhandler.o
> -obj-y += kexec.o
> +obj-$(HAS_KEXEC) += kexec.o
>  obj-y += lib.o
>  obj-y += memory.o
>  obj-y += multicall.o
> diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
> index e356e86..b18ef5d 100644
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -6,7 +6,9 @@
>  #include <xen/delay.h>
>  #include <xen/shutdown.h>
>  #include <xen/console.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <public/sched.h>
>  
> @@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
>      case SHUTDOWN_watchdog:
>      {
>          printk("Domain 0 shutdown: watchdog rebooting machine.\n");
> +#ifdef CONFIG_KEXEC
>          kexec_crash();
> +#endif
>          machine_restart(0);
>          break; /* not reached */
>      }
> diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
> index eb4fb61..7239375 100644
> --- a/xen/drivers/Makefile
> +++ b/xen/drivers/Makefile
> @@ -1,6 +1,6 @@
>  subdir-y += char
> -subdir-y += cpufreq
> -subdir-y += pci
> -subdir-y += passthrough
> +subdir-$(HAS_CPUFREQ) += cpufreq
> +subdir-$(HAS_PCI) += pci
> +subdir-$(HAS_PASSTHROUGH) += passthrough
>  subdir-$(HAS_ACPI) += acpi
>  subdir-$(HAS_VGA) += video
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index ded9a94..19250c8 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -1,3 +1,3 @@
>  obj-y += console.o
> -obj-y += ns16550.o
> +obj-$(HAS_NS16550) += ns16550.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 89cf4f8..19f021c 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -22,7 +22,9 @@
>  #include <xen/guest_access.h>
>  #include <xen/shutdown.h>
>  #include <xen/vga.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <asm/div64.h>
>  #include <xen/hypercall.h> /* for do_console_io */
> @@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
>  
>      debugger_trap_immediate();
>  
> +#ifdef CONFIG_KEXEC
>      kexec_crash();
> +#endif
>  
>      if ( opt_noreboot )
>      {
> diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
> index 0173487..6e9fc98 100644
> --- a/xen/include/asm-ia64/config.h
> +++ b/xen/include/asm-ia64/config.h
> @@ -20,6 +20,7 @@
>  #define CONFIG_EFI
>  #define CONFIG_EFI_PCDP
>  #define CONFIG_SERIAL_SGI_L1_CONSOLE
> +#define CONFIG_KEXEC 1
>  #define CONFIG_XENOPROF 1
>  
>  #define CONFIG_XEN_SMP
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 18d0a05..28f5e29 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -49,6 +49,7 @@
>  #define CONFIG_HOTPLUG_CPU 1
>  
>  #define CONFIG_XENOPROF 1
> +#define CONFIG_KEXEC 1
>  
>  #define HZ 100
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAV7-0004Np-PI; Wed, 08 Feb 2012 16:36:09 +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 1RvAV5-0004NI-06
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:36:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328718910!51929961!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7901 invoked from network); 8 Feb 2012 16:35:11 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:35:11 -0000
Received: by iaeh11 with SMTP id h11so160717iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 08:36:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=sQuRyZyhveON/KxBlgCSeKtBx1biKE/QyO5ODICzyOM=;
	b=pwdbQE6g8YHSiOkarWYYjJBwowK7eS9/r/e6XUig4a81ULHbmiia1sEmyx2SvKG5mJ
	gpgbRC541jVWchRo5YJ0trKU35WZuZcIS0y9NBmeMA6/ppEk4zFZw80+LPQQ5Ik/BSQ0
	7ojirDLu5CTtXq9mxm6y0zZwmXe8kNrvDAn1A=
Received: by 10.50.189.134 with SMTP id gi6mr24518893igc.18.1328718960803;
	Wed, 08 Feb 2012 08:36:00 -0800 (PST)
Received: from [206.12.39.140] ([206.12.39.140])
	by mx.google.com with ESMTPS id va6sm622291igc.4.2012.02.08.08.35.54
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 08:35:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 08:35:50 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB57E466.2AA79%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
Thread-Index: Aczmf7d0Hnfa8KYa/0SEQRPycT0vhw==
In-Reply-To: <1327077375-7623-7-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 16:35, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> - make the compilation of ns16550.c depend upon HAS_NS16550;
> 
> - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> 
> - make the compilation of pci depend upon HAS_PCI;
> 
> - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> 
> - make the compilation of kexec depend upon HAS_KEXEC.
> 
> 
> Changes in v2:
> 
> - introduce HAS_KEXEC and CONFIG_KEXEC kexec.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
>  xen/arch/ia64/Rules.mk        |    5 +++++
>  xen/arch/x86/Rules.mk         |    5 +++++
>  xen/common/Makefile           |    2 +-
>  xen/common/shutdown.c         |    4 ++++
>  xen/drivers/Makefile          |    6 +++---
>  xen/drivers/char/Makefile     |    2 +-
>  xen/drivers/char/console.c    |    4 ++++
>  xen/include/asm-ia64/config.h |    1 +
>  xen/include/asm-x86/config.h  |    1 +
>  9 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
> index bef11c3..054b4de 100644
> --- a/xen/arch/ia64/Rules.mk
> +++ b/xen/arch/ia64/Rules.mk
> @@ -4,6 +4,11 @@
>  ia64 := y
>  HAS_ACPI := y
>  HAS_VGA  := y
> +HAS_CPUFREQ := y
> +HAS_PCI := y
> +HAS_PASSTHROUGH := y
> +HAS_NS16550 := y
> +HAS_KEXEC := y
>  xenoprof := y
>  no_warns ?= n
>  vti_debug ?= n
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index 9fc6d42..65275af 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -3,6 +3,11 @@
>  
>  HAS_ACPI := y
>  HAS_VGA  := y
> +HAS_CPUFREQ := y
> +HAS_PCI := y
> +HAS_PASSTHROUGH := y
> +HAS_NS16550 := y
> +HAS_KEXEC := y
>  xenoprof := y
>  
>  #
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 1d85e65..9249845 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -8,7 +8,7 @@ obj-y += grant_table.o
>  obj-y += irq.o
>  obj-y += kernel.o
>  obj-y += keyhandler.o
> -obj-y += kexec.o
> +obj-$(HAS_KEXEC) += kexec.o
>  obj-y += lib.o
>  obj-y += memory.o
>  obj-y += multicall.o
> diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
> index e356e86..b18ef5d 100644
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -6,7 +6,9 @@
>  #include <xen/delay.h>
>  #include <xen/shutdown.h>
>  #include <xen/console.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <public/sched.h>
>  
> @@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
>      case SHUTDOWN_watchdog:
>      {
>          printk("Domain 0 shutdown: watchdog rebooting machine.\n");
> +#ifdef CONFIG_KEXEC
>          kexec_crash();
> +#endif
>          machine_restart(0);
>          break; /* not reached */
>      }
> diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
> index eb4fb61..7239375 100644
> --- a/xen/drivers/Makefile
> +++ b/xen/drivers/Makefile
> @@ -1,6 +1,6 @@
>  subdir-y += char
> -subdir-y += cpufreq
> -subdir-y += pci
> -subdir-y += passthrough
> +subdir-$(HAS_CPUFREQ) += cpufreq
> +subdir-$(HAS_PCI) += pci
> +subdir-$(HAS_PASSTHROUGH) += passthrough
>  subdir-$(HAS_ACPI) += acpi
>  subdir-$(HAS_VGA) += video
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index ded9a94..19250c8 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -1,3 +1,3 @@
>  obj-y += console.o
> -obj-y += ns16550.o
> +obj-$(HAS_NS16550) += ns16550.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 89cf4f8..19f021c 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -22,7 +22,9 @@
>  #include <xen/guest_access.h>
>  #include <xen/shutdown.h>
>  #include <xen/vga.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <asm/div64.h>
>  #include <xen/hypercall.h> /* for do_console_io */
> @@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
>  
>      debugger_trap_immediate();
>  
> +#ifdef CONFIG_KEXEC
>      kexec_crash();
> +#endif
>  
>      if ( opt_noreboot )
>      {
> diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
> index 0173487..6e9fc98 100644
> --- a/xen/include/asm-ia64/config.h
> +++ b/xen/include/asm-ia64/config.h
> @@ -20,6 +20,7 @@
>  #define CONFIG_EFI
>  #define CONFIG_EFI_PCDP
>  #define CONFIG_SERIAL_SGI_L1_CONSOLE
> +#define CONFIG_KEXEC 1
>  #define CONFIG_XENOPROF 1
>  
>  #define CONFIG_XEN_SMP
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 18d0a05..28f5e29 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -49,6 +49,7 @@
>  #define CONFIG_HOTPLUG_CPU 1
>  
>  #define CONFIG_XENOPROF 1
> +#define CONFIG_KEXEC 1
>  
>  #define HZ 100
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAVT-0004Qp-Vo; Wed, 08 Feb 2012 16:36:32 +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 1RvAVQ-0004Pd-U3
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:36:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328718932!53437788!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19324 invoked from network); 8 Feb 2012 16:35:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	8 Feb 2012 16:35:32 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75381368; Wed, 08 Feb 2012 17:36:21 +0100
Message-ID: <1328718979.4351.47.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 08 Feb 2012 17:36:19 +0100
In-Reply-To: <CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
	<20120208142247.GW12984@reaktio.net>
	<CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5237876551043119219=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5237876551043119219==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-jBrAgxUQwY//y6jU4HDx"


--=-jBrAgxUQwY//y6jU4HDx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-02-08 at 16:14 +0000, George Dunlap wrote:=20
> In fact, XenServer has a patch that will automatically adjust dom0's
> weight based on the weight of other VMs running on the system, in an
> attempt to make sure dom0 can get enough cpu time.
>=20
The only problem with approaches like this is what is "enough", and how
can we be sure that what's enough for someone is not too few and/or too
much for someone else. :-)

That being said (just my 2 cents)...

> I haven't submitted it to the list, because I don't think it's really
> appropriate for the open-source tree.  But I'll dig it out and post it
> as an RFC; even if it's not ultimately accepted, it might not be bad
> to have the patch floating around.
>=20
Yeah, it would be interesting to at least see it.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-jBrAgxUQwY//y6jU4HDx
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.11 (GNU/Linux)

iEYEABECAAYFAk8ypIQACgkQk4XaBE3IOsRC6ACgmnLkBtidN4oV2oqOByxKR5kl
LuQAn0lTjzMVTakDa+gq/Ag29yr1lwZS
=BWqd
-----END PGP SIGNATURE-----

--=-jBrAgxUQwY//y6jU4HDx--



--===============5237876551043119219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5237876551043119219==--



From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAVT-0004Qp-Vo; Wed, 08 Feb 2012 16:36:32 +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 1RvAVQ-0004Pd-U3
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:36:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328718932!53437788!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19324 invoked from network); 8 Feb 2012 16:35:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	8 Feb 2012 16:35:32 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75381368; Wed, 08 Feb 2012 17:36:21 +0100
Message-ID: <1328718979.4351.47.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 08 Feb 2012 17:36:19 +0100
In-Reply-To: <CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
	<20120208142247.GW12984@reaktio.net>
	<CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: kurt.hackel@oracle.com, xen-devel@lists.xensource.com,
	andrew.thomas@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5237876551043119219=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5237876551043119219==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-jBrAgxUQwY//y6jU4HDx"


--=-jBrAgxUQwY//y6jU4HDx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-02-08 at 16:14 +0000, George Dunlap wrote:=20
> In fact, XenServer has a patch that will automatically adjust dom0's
> weight based on the weight of other VMs running on the system, in an
> attempt to make sure dom0 can get enough cpu time.
>=20
The only problem with approaches like this is what is "enough", and how
can we be sure that what's enough for someone is not too few and/or too
much for someone else. :-)

That being said (just my 2 cents)...

> I haven't submitted it to the list, because I don't think it's really
> appropriate for the open-source tree.  But I'll dig it out and post it
> as an RFC; even if it's not ultimately accepted, it might not be bad
> to have the patch floating around.
>=20
Yeah, it would be interesting to at least see it.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-jBrAgxUQwY//y6jU4HDx
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.11 (GNU/Linux)

iEYEABECAAYFAk8ypIQACgkQk4XaBE3IOsRC6ACgmnLkBtidN4oV2oqOByxKR5kl
LuQAn0lTjzMVTakDa+gq/Ag29yr1lwZS
=BWqd
-----END PGP SIGNATURE-----

--=-jBrAgxUQwY//y6jU4HDx--



--===============5237876551043119219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5237876551043119219==--



From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:42:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:42:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAbN-0004qP-Gy; Wed, 08 Feb 2012 16:42:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvAbK-0004q5-W8
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:42:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328719346!13118288!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19454 invoked from network); 8 Feb 2012 16:42:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:42:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:42:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvAbC-0001K2-4O; Wed, 08 Feb 2012 16:42:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvAbC-0007Wh-3X;
	Wed, 08 Feb 2012 16:42:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.42482.96188.319229@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:42:26 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> libxl: introduce libxl hotplug public API functions
> 
> These functions mimic the name used by the local device functions,
> following the nomenclature:

I think these should be private functions.  Your new device daemon is,
I think, part of the implementation of libxl, not something that
another toolstack on top of libxl will reasonably want to replace.

This is a new departure for libxl, which doesn't currently have any
internal executables.

> The xenstore structure used by vbd disk entries:
> 
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/pdev_path
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/vdev
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/script
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/removable
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/readwrite
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/is_cdrom
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/state
> 
> and vif devices use the following:
> 
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> 
> This will allow us to pass the libxl_device_disk and libxl_device_nic
> struct from Dom0 to driver domain, and execute the necessary backends
> there.

Is this really the best encoding of this information in xenstore ?

If we're allowed to assume that the backendd is a libxl program too,
and of a reasonably similar version, perhaps we should have some kind
of idl-generated mapping from xenstore keys to struct members ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:42:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:42:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAbN-0004qP-Gy; Wed, 08 Feb 2012 16:42:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvAbK-0004q5-W8
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:42:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328719346!13118288!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19454 invoked from network); 8 Feb 2012 16:42:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:42:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:42:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvAbC-0001K2-4O; Wed, 08 Feb 2012 16:42:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvAbC-0007Wh-3X;
	Wed, 08 Feb 2012 16:42:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.42482.96188.319229@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:42:26 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> libxl: introduce libxl hotplug public API functions
> 
> These functions mimic the name used by the local device functions,
> following the nomenclature:

I think these should be private functions.  Your new device daemon is,
I think, part of the implementation of libxl, not something that
another toolstack on top of libxl will reasonably want to replace.

This is a new departure for libxl, which doesn't currently have any
internal executables.

> The xenstore structure used by vbd disk entries:
> 
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/pdev_path
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/vdev
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/script
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/removable
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/readwrite
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/is_cdrom
> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/state
> 
> and vif devices use the following:
> 
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> 
> This will allow us to pass the libxl_device_disk and libxl_device_nic
> struct from Dom0 to driver domain, and execute the necessary backends
> there.

Is this really the best encoding of this information in xenstore ?

If we're allowed to assume that the backendd is a libxl program too,
and of a reasonably similar version, perhaps we should have some kind
of idl-generated mapping from xenstore keys to struct members ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:43:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAbr-0004u9-HE; Wed, 08 Feb 2012 16:43:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvAbp-0004tX-SZ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:43:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328719379!12346703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28858 invoked from network); 8 Feb 2012 16:42:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:42:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16: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.213.0; Wed, 8 Feb 2012 16:42:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvAbj-0001KH-7l; Wed, 08 Feb 2012 16:42:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvAbj-0007XP-76;
	Wed, 08 Feb 2012 16:42:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.42515.207448.987386@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:42:59 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> 
> This will allow us to pass the libxl_device_disk and libxl_device_nic
> struct from Dom0 to driver domain, and execute the necessary backends
> there.

Also I think as you're inventing a new protocol we should have a
protocol document which, unless I've missed it, doesn't appear in your
series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:43:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAbr-0004u9-HE; Wed, 08 Feb 2012 16:43:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvAbp-0004tX-SZ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:43:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328719379!12346703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28858 invoked from network); 8 Feb 2012 16:42:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:42:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16: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.213.0; Wed, 8 Feb 2012 16:42:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvAbj-0001KH-7l; Wed, 08 Feb 2012 16:42:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvAbj-0007XP-76;
	Wed, 08 Feb 2012 16:42:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.42515.207448.987386@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:42:59 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> 
> This will allow us to pass the libxl_device_disk and libxl_device_nic
> struct from Dom0 to driver domain, and execute the necessary backends
> there.

Also I think as you're inventing a new protocol we should have a
protocol document which, unless I've missed it, doesn't appear in your
series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:43:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAbx-0004v8-62; Wed, 08 Feb 2012 16:43:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAbu-0004tw-LQ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:43:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328719379!12346703!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29126 invoked from network); 8 Feb 2012 16:43:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:43:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:43:04 +0000
Message-ID: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth@xen.org>
Date: Wed, 8 Feb 2012 16:43:03 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Security Response Problem Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Lars,

Please can we amend the Security Process [0] to add to the end of the
section "5. Advisory public release:" text like:

        Published advisories will be added to the Security
        Announcements[1] wiki page.

(with the link in the appropriate syntax/place)

The reason is that this document also serves as our checklist for things
to do when making a security announcement and this will serve to remind
us to update that page.

Thanks.

[0] http://www.xen.org/projects/security_vulnerability_process.html
[1] http://wiki.xen.org/wiki/Security_Announcements


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:43:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAbx-0004v8-62; Wed, 08 Feb 2012 16:43:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAbu-0004tw-LQ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:43:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328719379!12346703!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29126 invoked from network); 8 Feb 2012 16:43:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:43:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:43:04 +0000
Message-ID: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth@xen.org>
Date: Wed, 8 Feb 2012 16:43:03 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Security Response Problem Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Lars,

Please can we amend the Security Process [0] to add to the end of the
section "5. Advisory public release:" text like:

        Published advisories will be added to the Security
        Announcements[1] wiki page.

(with the link in the appropriate syntax/place)

The reason is that this document also serves as our checklist for things
to do when making a security announcement and this will serve to remind
us to update that page.

Thanks.

[0] http://www.xen.org/projects/security_vulnerability_process.html
[1] http://wiki.xen.org/wiki/Security_Announcements


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:44:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAck-00054H-D9; Wed, 08 Feb 2012 16:44:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvAch-000532-1Q
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:43:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328719433!13118535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29478 invoked from network); 8 Feb 2012 16:43: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;
	8 Feb 2012 16:43:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:43:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:43:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvAca-0001Ka-Jg; Wed, 08 Feb 2012 16:43:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvAca-0007Yf-Iv;
	Wed, 08 Feb 2012 16:43:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.42568.574200.992066@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:43:52 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2708343292be6facb6a2.1328189218@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<2708343292be6facb6a2.1328189218@debian.localdomain>
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 23 of 29 RFC] libxl:
	add	libxl__parse_nic_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 23 of 29 RFC] libxl: add libxl__parse_nic_hotplug_path"):
> libxl: add libxl__parse_nic_hotplug_path

This series has a lot of "add <some function>" but without adding any
callers.

Can I suggest it be restructured to try to avoid introducing too many
functions without callers unless it's necessary to stop other patches
becoming too large.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:44:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAck-00054H-D9; Wed, 08 Feb 2012 16:44:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvAch-000532-1Q
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:43:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328719433!13118535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29478 invoked from network); 8 Feb 2012 16:43: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;
	8 Feb 2012 16:43:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:43:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:43:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvAca-0001Ka-Jg; Wed, 08 Feb 2012 16:43:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvAca-0007Yf-Iv;
	Wed, 08 Feb 2012 16:43:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20274.42568.574200.992066@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:43:52 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2708343292be6facb6a2.1328189218@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<2708343292be6facb6a2.1328189218@debian.localdomain>
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 23 of 29 RFC] libxl:
	add	libxl__parse_nic_hotplug_path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 23 of 29 RFC] libxl: add libxl__parse_nic_hotplug_path"):
> libxl: add libxl__parse_nic_hotplug_path

This series has a lot of "add <some function>" but without adding any
callers.

Can I suggest it be restructured to try to avoid introducing too many
functions without callers unless it's necessary to stop other patches
becoming too large.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAet-0005JP-DL; Wed, 08 Feb 2012 16:46:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAer-0005Ic-3D
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:13 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328719567!14042168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31717 invoked from network); 8 Feb 2012 16:46:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:07 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:07 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 0 of 4] Prune outdated/impossible preprocessor
 symbols, and update VIOAPIC emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Patch 1 removes CONFIG_SMP
Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1
Patch 4 removes __ia64__ defines from the x86 arch tree

Patch 3 is related to patch 4 and changes the VIOAPIC to emulate
version 0x20 as a performance gain.  It preceeds Patch 4 so as to be
more clear about the functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAet-0005JP-DL; Wed, 08 Feb 2012 16:46:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAer-0005Ic-3D
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:13 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328719567!14042168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31717 invoked from network); 8 Feb 2012 16:46:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10579999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:07 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:07 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 0 of 4] Prune outdated/impossible preprocessor
 symbols, and update VIOAPIC emulation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Patch 1 removes CONFIG_SMP
Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1
Patch 4 removes __ia64__ defines from the x86 arch tree

Patch 3 is related to patch 4 and changes the VIOAPIC to emulate
version 0x20 as a performance gain.  It preceeds Patch 4 so as to be
more clear about the functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAf3-0005M0-L9; Wed, 08 Feb 2012 16:46:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAf1-0005Jq-Q9
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328719577!12489233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27679 invoked from network); 8 Feb 2012 16:46:17 -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;
	8 Feb 2012 16:46:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:17 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:17 +0000
MIME-Version: 1.0
X-Mercurial-Node: 101b0d7ebb00e1af8acfc6dc9817e9266e8c8a75
Message-ID: <101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CONFIG_SMP is always enabled and !CONFIG_SMP is not supported.  So
simply the code a little by removing all #ifdefs.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -145,9 +145,8 @@ void ack_bad_irq(unsigned int irq)
 
 void __init apic_intr_init(void)
 {
-#ifdef CONFIG_SMP
     smp_intr_init();
-#endif
+
     /* self generated IPI for local APIC timer */
     set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt);
 
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -370,7 +370,6 @@ static void __devinit init_amd(struct cp
 {
 	u32 l, h;
 
-#ifdef CONFIG_SMP
 	unsigned long long value;
 
 	/* Disable TLB flush filter by setting HWCR.FFDIS on K8
@@ -384,7 +383,6 @@ static void __devinit init_amd(struct cp
 		value |= 1 << 6;
 		wrmsrl(MSR_K7_HWCR, value);
 	}
-#endif
 
 	/*
 	 *	FIXME: We should handle the K5 here. Set up the write
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/cpu/mtrr/cyrix.c
--- a/xen/arch/x86/cpu/mtrr/cyrix.c
+++ b/xen/arch/x86/cpu/mtrr/cyrix.c
@@ -279,9 +279,7 @@ cyrix_arr_init(void)
 	struct set_mtrr_context ctxt;
 	unsigned char ccr[7];
 	int ccrc[7] = { 0, 0, 0, 0, 0, 0, 0 };
-#ifdef CONFIG_SMP
 	int i;
-#endif
 
 	/* flush cache and enable MAPEN */
 	set_mtrr_prepare_save(&ctxt);
@@ -334,14 +332,13 @@ cyrix_arr_init(void)
 		ccrc[5] = 1;
 		setCx86(CX86_CCR5, ccr[5]);
 	}
-#ifdef CONFIG_SMP
+
 	for (i = 0; i < 7; i++)
 		ccr_state[i] = ccr[i];
 	for (i = 0; i < 8; i++)
 		cyrix_get_arr(i,
 			      &arr_state[i].base, &arr_state[i].size,
 			      &arr_state[i].type);
-#endif
 
 	set_mtrr_done(&ctxt);	/* flush cache and disable MAPEN */
 
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/cpu/mtrr/main.c
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -142,8 +142,6 @@ struct set_mtrr_data {
  */
 int hold_mtrr_updates_on_aps;
 
-#ifdef CONFIG_SMP
-
 static void ipi_handler(void *info)
 /*  [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
     [RETURNS] Nothing.
@@ -175,8 +173,6 @@ static void ipi_handler(void *info)
 	local_irq_restore(flags);
 }
 
-#endif
-
 static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
 	return type1 == MTRR_TYPE_UNCACHABLE ||
 	       type2 == MTRR_TYPE_UNCACHABLE ||
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -513,7 +513,6 @@ static void clear_IO_APIC (void)
     }
 }
 
-#ifdef CONFIG_SMP
 static void
 set_ioapic_affinity_irq(struct irq_desc *desc, const cpumask_t *mask)
 {
@@ -550,7 +549,6 @@ set_ioapic_affinity_irq(struct irq_desc 
     spin_unlock_irqrestore(&ioapic_lock, flags);
 
 }
-#endif /* CONFIG_SMP */
 
 /*
  * Find the IRQ entry number of a certain pin.
@@ -630,7 +628,6 @@ static int pin_2_irq(int idx, int apic, 
  * we need to reprogram the ioredtbls to cater for the cpus which have come online
  * so mask in all cases should simply be TARGET_CPUS
  */
-#ifdef CONFIG_SMP
 void /*__init*/ setup_ioapic_dest(void)
 {
     int pin, ioapic, irq, irq_entry;
@@ -653,7 +650,6 @@ void /*__init*/ setup_ioapic_dest(void)
 
     }
 }
-#endif
 
 /*
  * EISA Edge/Level control register, ELCR
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -304,11 +304,6 @@ static int __init p4_init(char ** cpu_ty
 		return 0;
 	}
 
-#ifndef CONFIG_SMP
-	*cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
-	model = &op_p4_spec;
-	return 1;
-#else
 	switch (current_cpu_data.x86_num_siblings) {
 		case 1:
 			*cpu_type = "i386/p4";
@@ -320,7 +315,7 @@ static int __init p4_init(char ** cpu_ty
 			model = &op_p4_ht2_spec;
 			return 1;
 	}
-#endif
+
 	printk("Xenoprof ERROR: P4 HyperThreading detected with > 2 threads\n");
 
 	return 0;
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/oprofile/op_model_p4.c
--- a/xen/arch/x86/oprofile/op_model_p4.c
+++ b/xen/arch/x86/oprofile/op_model_p4.c
@@ -40,19 +40,13 @@ static unsigned int num_counters = NUM_C
    kernel boot-time. */
 static inline void setup_num_counters(void)
 {
-#ifdef CONFIG_SMP
 	if (boot_cpu_data.x86_num_siblings == 2) 	/* XXX */
 		num_counters = NUM_COUNTERS_HT2;
-#endif
 }
 
 static int inline addr_increment(void)
 {
-#ifdef CONFIG_SMP
 	return boot_cpu_data.x86_num_siblings == 2 ? 2 : 1;
-#else
-	return 1;
-#endif
 }
 
 
@@ -383,11 +377,8 @@ static const struct p4_event_binding p4_
    or "odd" part of all the divided resources. */
 static unsigned int get_stagger(void)
 {
-#ifdef CONFIG_SMP
 	int cpu = smp_processor_id();
 	return (cpu != cpumask_first(per_cpu(cpu_sibling_mask, cpu)));
-#endif	
-	return 0;
 }
 
 
@@ -709,7 +700,6 @@ static void p4_stop(struct op_msrs const
 }
 
 
-#ifdef CONFIG_SMP
 struct op_x86_model_spec const op_p4_ht2_spec = {
 	.num_counters = NUM_COUNTERS_HT2,
 	.num_controls = NUM_CONTROLS_HT2,
@@ -719,7 +709,7 @@ struct op_x86_model_spec const op_p4_ht2
 	.start = &p4_start,
 	.stop = &p4_stop
 };
-#endif
+
 
 struct op_x86_model_spec const op_p4_spec = {
 	.num_counters = NUM_COUNTERS_NON_HT,
diff -r eae25241d571 -r 101b0d7ebb00 xen/common/rcupdate.c
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -83,9 +83,7 @@ struct rcu_data {
     long            blimit;           /* Upper limit on a processed batch */
     int cpu;
     struct rcu_head barrier;
-#ifdef CONFIG_SMP
     long            last_rs_qlen;     /* qlen during the last resched */
-#endif
 };
 
 static DEFINE_PER_CPU(struct rcu_data, rcu_data);
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -21,7 +21,6 @@
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
-#define CONFIG_SMP 1
 #define CONFIG_X86_LOCAL_APIC 1
 #define CONFIG_X86_GOOD_APIC 1
 #define CONFIG_X86_IO_APIC 1
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -189,13 +189,8 @@ struct cpuinfo_x86 {
 
 extern struct cpuinfo_x86 boot_cpu_data;
 
-#ifdef CONFIG_SMP
 extern struct cpuinfo_x86 cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
-#else
-#define cpu_data (&boot_cpu_data)
-#define current_cpu_data boot_cpu_data
-#endif
 
 extern void set_cpuid_faulting(bool_t enable);
 
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/smp.h
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -17,7 +17,6 @@
 #endif
 
 #define BAD_APICID -1U
-#ifdef CONFIG_SMP
 #ifndef __ASSEMBLY__
 
 /*
@@ -65,11 +64,4 @@ void __stop_this_cpu(void);
 
 #endif /* !__ASSEMBLY__ */
 
-#else /* CONFIG_SMP */
-
-#define cpu_physical_id(cpu)		boot_cpu_physical_apicid
-
-#define NO_PROC_ID		0xFF		/* No processor magic marker */
-
 #endif
-#endif
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/system.h
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -154,15 +154,9 @@ static always_inline unsigned long __cmp
 #define rmb()           barrier()
 #define wmb()           barrier()
 
-#ifdef CONFIG_SMP
 #define smp_mb()        mb()
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
-#else
-#define smp_mb()        barrier()
-#define smp_rmb()       barrier()
-#define smp_wmb()       barrier()
-#endif
 
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAf3-0005M0-L9; Wed, 08 Feb 2012 16:46:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAf1-0005Jq-Q9
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328719577!12489233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27679 invoked from network); 8 Feb 2012 16:46:17 -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;
	8 Feb 2012 16:46:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:17 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:17 +0000
MIME-Version: 1.0
X-Mercurial-Node: 101b0d7ebb00e1af8acfc6dc9817e9266e8c8a75
Message-ID: <101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CONFIG_SMP is always enabled and !CONFIG_SMP is not supported.  So
simply the code a little by removing all #ifdefs.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -145,9 +145,8 @@ void ack_bad_irq(unsigned int irq)
 
 void __init apic_intr_init(void)
 {
-#ifdef CONFIG_SMP
     smp_intr_init();
-#endif
+
     /* self generated IPI for local APIC timer */
     set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt);
 
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -370,7 +370,6 @@ static void __devinit init_amd(struct cp
 {
 	u32 l, h;
 
-#ifdef CONFIG_SMP
 	unsigned long long value;
 
 	/* Disable TLB flush filter by setting HWCR.FFDIS on K8
@@ -384,7 +383,6 @@ static void __devinit init_amd(struct cp
 		value |= 1 << 6;
 		wrmsrl(MSR_K7_HWCR, value);
 	}
-#endif
 
 	/*
 	 *	FIXME: We should handle the K5 here. Set up the write
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/cpu/mtrr/cyrix.c
--- a/xen/arch/x86/cpu/mtrr/cyrix.c
+++ b/xen/arch/x86/cpu/mtrr/cyrix.c
@@ -279,9 +279,7 @@ cyrix_arr_init(void)
 	struct set_mtrr_context ctxt;
 	unsigned char ccr[7];
 	int ccrc[7] = { 0, 0, 0, 0, 0, 0, 0 };
-#ifdef CONFIG_SMP
 	int i;
-#endif
 
 	/* flush cache and enable MAPEN */
 	set_mtrr_prepare_save(&ctxt);
@@ -334,14 +332,13 @@ cyrix_arr_init(void)
 		ccrc[5] = 1;
 		setCx86(CX86_CCR5, ccr[5]);
 	}
-#ifdef CONFIG_SMP
+
 	for (i = 0; i < 7; i++)
 		ccr_state[i] = ccr[i];
 	for (i = 0; i < 8; i++)
 		cyrix_get_arr(i,
 			      &arr_state[i].base, &arr_state[i].size,
 			      &arr_state[i].type);
-#endif
 
 	set_mtrr_done(&ctxt);	/* flush cache and disable MAPEN */
 
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/cpu/mtrr/main.c
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -142,8 +142,6 @@ struct set_mtrr_data {
  */
 int hold_mtrr_updates_on_aps;
 
-#ifdef CONFIG_SMP
-
 static void ipi_handler(void *info)
 /*  [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
     [RETURNS] Nothing.
@@ -175,8 +173,6 @@ static void ipi_handler(void *info)
 	local_irq_restore(flags);
 }
 
-#endif
-
 static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
 	return type1 == MTRR_TYPE_UNCACHABLE ||
 	       type2 == MTRR_TYPE_UNCACHABLE ||
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -513,7 +513,6 @@ static void clear_IO_APIC (void)
     }
 }
 
-#ifdef CONFIG_SMP
 static void
 set_ioapic_affinity_irq(struct irq_desc *desc, const cpumask_t *mask)
 {
@@ -550,7 +549,6 @@ set_ioapic_affinity_irq(struct irq_desc 
     spin_unlock_irqrestore(&ioapic_lock, flags);
 
 }
-#endif /* CONFIG_SMP */
 
 /*
  * Find the IRQ entry number of a certain pin.
@@ -630,7 +628,6 @@ static int pin_2_irq(int idx, int apic, 
  * we need to reprogram the ioredtbls to cater for the cpus which have come online
  * so mask in all cases should simply be TARGET_CPUS
  */
-#ifdef CONFIG_SMP
 void /*__init*/ setup_ioapic_dest(void)
 {
     int pin, ioapic, irq, irq_entry;
@@ -653,7 +650,6 @@ void /*__init*/ setup_ioapic_dest(void)
 
     }
 }
-#endif
 
 /*
  * EISA Edge/Level control register, ELCR
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -304,11 +304,6 @@ static int __init p4_init(char ** cpu_ty
 		return 0;
 	}
 
-#ifndef CONFIG_SMP
-	*cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
-	model = &op_p4_spec;
-	return 1;
-#else
 	switch (current_cpu_data.x86_num_siblings) {
 		case 1:
 			*cpu_type = "i386/p4";
@@ -320,7 +315,7 @@ static int __init p4_init(char ** cpu_ty
 			model = &op_p4_ht2_spec;
 			return 1;
 	}
-#endif
+
 	printk("Xenoprof ERROR: P4 HyperThreading detected with > 2 threads\n");
 
 	return 0;
diff -r eae25241d571 -r 101b0d7ebb00 xen/arch/x86/oprofile/op_model_p4.c
--- a/xen/arch/x86/oprofile/op_model_p4.c
+++ b/xen/arch/x86/oprofile/op_model_p4.c
@@ -40,19 +40,13 @@ static unsigned int num_counters = NUM_C
    kernel boot-time. */
 static inline void setup_num_counters(void)
 {
-#ifdef CONFIG_SMP
 	if (boot_cpu_data.x86_num_siblings == 2) 	/* XXX */
 		num_counters = NUM_COUNTERS_HT2;
-#endif
 }
 
 static int inline addr_increment(void)
 {
-#ifdef CONFIG_SMP
 	return boot_cpu_data.x86_num_siblings == 2 ? 2 : 1;
-#else
-	return 1;
-#endif
 }
 
 
@@ -383,11 +377,8 @@ static const struct p4_event_binding p4_
    or "odd" part of all the divided resources. */
 static unsigned int get_stagger(void)
 {
-#ifdef CONFIG_SMP
 	int cpu = smp_processor_id();
 	return (cpu != cpumask_first(per_cpu(cpu_sibling_mask, cpu)));
-#endif	
-	return 0;
 }
 
 
@@ -709,7 +700,6 @@ static void p4_stop(struct op_msrs const
 }
 
 
-#ifdef CONFIG_SMP
 struct op_x86_model_spec const op_p4_ht2_spec = {
 	.num_counters = NUM_COUNTERS_HT2,
 	.num_controls = NUM_CONTROLS_HT2,
@@ -719,7 +709,7 @@ struct op_x86_model_spec const op_p4_ht2
 	.start = &p4_start,
 	.stop = &p4_stop
 };
-#endif
+
 
 struct op_x86_model_spec const op_p4_spec = {
 	.num_counters = NUM_COUNTERS_NON_HT,
diff -r eae25241d571 -r 101b0d7ebb00 xen/common/rcupdate.c
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -83,9 +83,7 @@ struct rcu_data {
     long            blimit;           /* Upper limit on a processed batch */
     int cpu;
     struct rcu_head barrier;
-#ifdef CONFIG_SMP
     long            last_rs_qlen;     /* qlen during the last resched */
-#endif
 };
 
 static DEFINE_PER_CPU(struct rcu_data, rcu_data);
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -21,7 +21,6 @@
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
-#define CONFIG_SMP 1
 #define CONFIG_X86_LOCAL_APIC 1
 #define CONFIG_X86_GOOD_APIC 1
 #define CONFIG_X86_IO_APIC 1
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -189,13 +189,8 @@ struct cpuinfo_x86 {
 
 extern struct cpuinfo_x86 boot_cpu_data;
 
-#ifdef CONFIG_SMP
 extern struct cpuinfo_x86 cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
-#else
-#define cpu_data (&boot_cpu_data)
-#define current_cpu_data boot_cpu_data
-#endif
 
 extern void set_cpuid_faulting(bool_t enable);
 
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/smp.h
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -17,7 +17,6 @@
 #endif
 
 #define BAD_APICID -1U
-#ifdef CONFIG_SMP
 #ifndef __ASSEMBLY__
 
 /*
@@ -65,11 +64,4 @@ void __stop_this_cpu(void);
 
 #endif /* !__ASSEMBLY__ */
 
-#else /* CONFIG_SMP */
-
-#define cpu_physical_id(cpu)		boot_cpu_physical_apicid
-
-#define NO_PROC_ID		0xFF		/* No processor magic marker */
-
 #endif
-#endif
diff -r eae25241d571 -r 101b0d7ebb00 xen/include/asm-x86/system.h
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -154,15 +154,9 @@ static always_inline unsigned long __cmp
 #define rmb()           barrier()
 #define wmb()           barrier()
 
-#ifdef CONFIG_SMP
 #define smp_mb()        mb()
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
-#else
-#define smp_mb()        barrier()
-#define smp_rmb()       barrier()
-#define smp_wmb()       barrier()
-#endif
 
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAfF-0005Pp-Ia; Wed, 08 Feb 2012 16:46:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAfC-0005Nv-JV
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328719588!10643316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5114 invoked from network); 8 Feb 2012 16:46:28 -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;
	8 Feb 2012 16:46:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:27 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:28 +0000
MIME-Version: 1.0
X-Mercurial-Node: 957b5ac44e32778242a9b432e3c4329e9333167d
Message-ID: <957b5ac44e32778242a9.1328719537@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Now CONFIG_SMP has been removed, there is no need to define
smp_{,r,w}mb()s which used to conditionally compiled to different
operations (even though those conditonally different operations still
ended up as simple barrier()s)

Therefore, remove smp_{,r,w}mb()s and just use regular {,r,w}mb()s

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -260,7 +260,7 @@ static void mwait_idle_with_hints(unsign
     s_time_t expires = per_cpu(timer_deadline, cpu);
 
     __monitor((void *)&mwait_wakeup(cpu), 0, 0);
-    smp_mb();
+    mb();
 
     /*
      * Timer deadline passing is the event on which we will be woken via
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/cpu/mtrr/main.c
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -248,7 +248,7 @@ static void set_mtrr(unsigned int reg, u
 
 	/* ok, reset count and toggle gate */
 	atomic_set(&data.count, nr_cpus);
-	smp_wmb();
+	wmb();
 	atomic_set(&data.gate,1);
 
 	/* do our MTRR business */
@@ -271,7 +271,7 @@ static void set_mtrr(unsigned int reg, u
 		cpu_relax();
 
 	atomic_set(&data.count, nr_cpus);
-	smp_wmb();
+	wmb();
 	atomic_set(&data.gate,0);
 
 	/*
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -207,7 +207,7 @@ static void dynamic_irq_cleanup(unsigned
     spin_unlock_irqrestore(&desc->lock, flags);
 
     /* Wait to make sure it's not being used on another CPU */
-    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
 
     if (action)
         xfree(action);
@@ -931,7 +931,7 @@ void __init release_irq(unsigned int irq
     spin_unlock_irqrestore(&desc->lock,flags);
 
     /* Wait to make sure it's not being used on another CPU */
-    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
 
     if (action && action->free_on_release)
         xfree(action);
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -544,7 +544,7 @@ void domain_shutdown(struct domain *d, u
 
     d->is_shutting_down = 1;
 
-    smp_mb(); /* set shutdown status /then/ check for per-cpu deferrals */
+    mb(); /* set shutdown status /then/ check for per-cpu deferrals */
 
     for_each_vcpu ( d, v )
     {
@@ -594,7 +594,7 @@ int vcpu_start_shutdown_deferral(struct 
         return 1;
 
     v->defer_shutdown = 1;
-    smp_mb(); /* set deferral status /then/ check for shutdown */
+    mb(); /* set deferral status /then/ check for shutdown */
     if ( unlikely(v->domain->is_shutting_down) )
         vcpu_check_shutdown(v);
 
@@ -604,7 +604,7 @@ int vcpu_start_shutdown_deferral(struct 
 void vcpu_end_shutdown_deferral(struct vcpu *v)
 {
     v->defer_shutdown = 0;
-    smp_mb(); /* clear deferral status /then/ check for shutdown */
+    mb(); /* clear deferral status /then/ check for shutdown */
     if ( unlikely(v->domain->is_shutting_down) )
         vcpu_check_shutdown(v);
 }
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/rcupdate.c
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -252,7 +252,7 @@ static void rcu_start_batch(struct rcu_c
          * next_pending == 0 must be visible in
          * __rcu_process_callbacks() before it can see new value of cur.
          */
-        smp_wmb();
+        wmb();
         rcp->cur++;
 
         cpumask_copy(&rcp->cpumask, &cpu_online_map);
@@ -340,7 +340,7 @@ static void __rcu_process_callbacks(stru
         /* see the comment and corresponding wmb() in
          * the rcu_start_batch()
          */
-        smp_rmb();
+        rmb();
 
         if (!rcp->next_pending) {
             /* and start it/schedule start if it's a new batch */
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -657,7 +657,7 @@ static long do_poll(struct sched_poll *s
 
 #ifndef CONFIG_X86 /* set_bit() implies mb() on x86 */
     /* Check for events /after/ setting flags: avoids wakeup waiting race. */
-    smp_mb();
+    mb();
 
     /*
      * Someone may have seen we are blocked but not that we are polling, or
@@ -1173,12 +1173,12 @@ static void schedule(void)
 void context_saved(struct vcpu *prev)
 {
     /* Clear running flag /after/ writing context to memory. */
-    smp_wmb();
+    wmb();
 
     prev->is_running = 0;
 
     /* Check for migration request /after/ clearing running flag. */
-    smp_mb();
+    mb();
 
     SCHED_OP(VCPU2OP(prev), context_saved, prev);
 
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/stop_machine.c
--- a/xen/common/stop_machine.c
+++ b/xen/common/stop_machine.c
@@ -59,7 +59,7 @@ static DEFINE_SPINLOCK(stopmachine_lock)
 static void stopmachine_set_state(enum stopmachine_state state)
 {
     atomic_set(&stopmachine_data.done, 0);
-    smp_wmb();
+    wmb();
     stopmachine_data.state = state;
 }
 
@@ -99,7 +99,7 @@ int stop_machine_run(int (*fn)(void *), 
     atomic_set(&stopmachine_data.done, 0);
     stopmachine_data.state = STOPMACHINE_START;
 
-    smp_wmb();
+    wmb();
 
     for_each_cpu ( i, &allbutself )
         tasklet_schedule_on_cpu(&per_cpu(stopmachine_tasklet, i), i);
@@ -134,7 +134,7 @@ static void stopmachine_action(unsigned 
 
     BUG_ON(cpu != smp_processor_id());
 
-    smp_mb();
+    mb();
 
     while ( state != STOPMACHINE_EXIT )
     {
@@ -157,7 +157,7 @@ static void stopmachine_action(unsigned 
             break;
         }
 
-        smp_mb();
+        mb();
         atomic_inc(&stopmachine_data.done);
     }
 
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/asm-x86/system.h
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -154,10 +154,6 @@ static always_inline unsigned long __cmp
 #define rmb()           barrier()
 #define wmb()           barrier()
 
-#define smp_mb()        mb()
-#define smp_rmb()       rmb()
-#define smp_wmb()       wmb()
-
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)
 
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/list.h
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -102,7 +102,7 @@ static inline void __list_add_rcu(struct
 {
     new->next = next;
     new->prev = prev;
-    smp_wmb();
+    wmb();
     next->prev = new;
     prev->next = new;
 }
@@ -244,7 +244,7 @@ static inline void list_replace_rcu(stru
 {
     new->next = old->next;
     new->prev = old->prev;
-    smp_wmb();
+    wmb();
     new->next->prev = new;
     new->prev->next = new;
     old->prev = LIST_POISON2;
@@ -712,7 +712,7 @@ static inline void hlist_replace_rcu(str
 
     new->next = next;
     new->pprev = old->pprev;
-    smp_wmb();
+    wmb();
     if (next)
         new->next->pprev = &new->next;
     *new->pprev = new;
@@ -754,7 +754,7 @@ static inline void hlist_add_head_rcu(st
     struct hlist_node *first = h->first;
     n->next = first;
     n->pprev = &h->first;
-    smp_wmb();
+    wmb();
     if (first)
         first->pprev = &n->next;
     h->first = n;
@@ -804,7 +804,7 @@ static inline void hlist_add_before_rcu(
 {
     n->pprev = next->pprev;
     n->next = next;
-    smp_wmb();
+    wmb();
     next->pprev = &n->next;
     *(n->pprev) = n;
 }
@@ -832,7 +832,7 @@ static inline void hlist_add_after_rcu(s
 {
     n->next = prev->next;
     n->pprev = &prev->next;
-    smp_wmb();
+    wmb();
     prev->next = n;
     if (n->next)
         n->next->pprev = &n->next;
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/rcupdate.h
--- a/xen/include/xen/rcupdate.h
+++ b/xen/include/xen/rcupdate.h
@@ -136,7 +136,7 @@ typedef struct _rcu_read_lock rcu_read_l
  * call documents which pointers will be dereferenced by RCU read-side
  * code.
  */
-#define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); })
+#define rcu_assign_pointer(p, v) ({ wmb(); (p) = (v); })
 
 void rcu_init(void);
 void rcu_check_callbacks(int cpu);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAfF-0005Pp-Ia; Wed, 08 Feb 2012 16:46:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAfC-0005Nv-JV
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328719588!10643316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5114 invoked from network); 8 Feb 2012 16:46:28 -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;
	8 Feb 2012 16:46:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:27 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:28 +0000
MIME-Version: 1.0
X-Mercurial-Node: 957b5ac44e32778242a9b432e3c4329e9333167d
Message-ID: <957b5ac44e32778242a9.1328719537@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Now CONFIG_SMP has been removed, there is no need to define
smp_{,r,w}mb()s which used to conditionally compiled to different
operations (even though those conditonally different operations still
ended up as simple barrier()s)

Therefore, remove smp_{,r,w}mb()s and just use regular {,r,w}mb()s

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -260,7 +260,7 @@ static void mwait_idle_with_hints(unsign
     s_time_t expires = per_cpu(timer_deadline, cpu);
 
     __monitor((void *)&mwait_wakeup(cpu), 0, 0);
-    smp_mb();
+    mb();
 
     /*
      * Timer deadline passing is the event on which we will be woken via
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/cpu/mtrr/main.c
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -248,7 +248,7 @@ static void set_mtrr(unsigned int reg, u
 
 	/* ok, reset count and toggle gate */
 	atomic_set(&data.count, nr_cpus);
-	smp_wmb();
+	wmb();
 	atomic_set(&data.gate,1);
 
 	/* do our MTRR business */
@@ -271,7 +271,7 @@ static void set_mtrr(unsigned int reg, u
 		cpu_relax();
 
 	atomic_set(&data.count, nr_cpus);
-	smp_wmb();
+	wmb();
 	atomic_set(&data.gate,0);
 
 	/*
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -207,7 +207,7 @@ static void dynamic_irq_cleanup(unsigned
     spin_unlock_irqrestore(&desc->lock, flags);
 
     /* Wait to make sure it's not being used on another CPU */
-    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
 
     if (action)
         xfree(action);
@@ -931,7 +931,7 @@ void __init release_irq(unsigned int irq
     spin_unlock_irqrestore(&desc->lock,flags);
 
     /* Wait to make sure it's not being used on another CPU */
-    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
+    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
 
     if (action && action->free_on_release)
         xfree(action);
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -544,7 +544,7 @@ void domain_shutdown(struct domain *d, u
 
     d->is_shutting_down = 1;
 
-    smp_mb(); /* set shutdown status /then/ check for per-cpu deferrals */
+    mb(); /* set shutdown status /then/ check for per-cpu deferrals */
 
     for_each_vcpu ( d, v )
     {
@@ -594,7 +594,7 @@ int vcpu_start_shutdown_deferral(struct 
         return 1;
 
     v->defer_shutdown = 1;
-    smp_mb(); /* set deferral status /then/ check for shutdown */
+    mb(); /* set deferral status /then/ check for shutdown */
     if ( unlikely(v->domain->is_shutting_down) )
         vcpu_check_shutdown(v);
 
@@ -604,7 +604,7 @@ int vcpu_start_shutdown_deferral(struct 
 void vcpu_end_shutdown_deferral(struct vcpu *v)
 {
     v->defer_shutdown = 0;
-    smp_mb(); /* clear deferral status /then/ check for shutdown */
+    mb(); /* clear deferral status /then/ check for shutdown */
     if ( unlikely(v->domain->is_shutting_down) )
         vcpu_check_shutdown(v);
 }
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/rcupdate.c
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -252,7 +252,7 @@ static void rcu_start_batch(struct rcu_c
          * next_pending == 0 must be visible in
          * __rcu_process_callbacks() before it can see new value of cur.
          */
-        smp_wmb();
+        wmb();
         rcp->cur++;
 
         cpumask_copy(&rcp->cpumask, &cpu_online_map);
@@ -340,7 +340,7 @@ static void __rcu_process_callbacks(stru
         /* see the comment and corresponding wmb() in
          * the rcu_start_batch()
          */
-        smp_rmb();
+        rmb();
 
         if (!rcp->next_pending) {
             /* and start it/schedule start if it's a new batch */
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -657,7 +657,7 @@ static long do_poll(struct sched_poll *s
 
 #ifndef CONFIG_X86 /* set_bit() implies mb() on x86 */
     /* Check for events /after/ setting flags: avoids wakeup waiting race. */
-    smp_mb();
+    mb();
 
     /*
      * Someone may have seen we are blocked but not that we are polling, or
@@ -1173,12 +1173,12 @@ static void schedule(void)
 void context_saved(struct vcpu *prev)
 {
     /* Clear running flag /after/ writing context to memory. */
-    smp_wmb();
+    wmb();
 
     prev->is_running = 0;
 
     /* Check for migration request /after/ clearing running flag. */
-    smp_mb();
+    mb();
 
     SCHED_OP(VCPU2OP(prev), context_saved, prev);
 
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/stop_machine.c
--- a/xen/common/stop_machine.c
+++ b/xen/common/stop_machine.c
@@ -59,7 +59,7 @@ static DEFINE_SPINLOCK(stopmachine_lock)
 static void stopmachine_set_state(enum stopmachine_state state)
 {
     atomic_set(&stopmachine_data.done, 0);
-    smp_wmb();
+    wmb();
     stopmachine_data.state = state;
 }
 
@@ -99,7 +99,7 @@ int stop_machine_run(int (*fn)(void *), 
     atomic_set(&stopmachine_data.done, 0);
     stopmachine_data.state = STOPMACHINE_START;
 
-    smp_wmb();
+    wmb();
 
     for_each_cpu ( i, &allbutself )
         tasklet_schedule_on_cpu(&per_cpu(stopmachine_tasklet, i), i);
@@ -134,7 +134,7 @@ static void stopmachine_action(unsigned 
 
     BUG_ON(cpu != smp_processor_id());
 
-    smp_mb();
+    mb();
 
     while ( state != STOPMACHINE_EXIT )
     {
@@ -157,7 +157,7 @@ static void stopmachine_action(unsigned 
             break;
         }
 
-        smp_mb();
+        mb();
         atomic_inc(&stopmachine_data.done);
     }
 
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/asm-x86/system.h
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -154,10 +154,6 @@ static always_inline unsigned long __cmp
 #define rmb()           barrier()
 #define wmb()           barrier()
 
-#define smp_mb()        mb()
-#define smp_rmb()       rmb()
-#define smp_wmb()       wmb()
-
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)
 
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/list.h
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -102,7 +102,7 @@ static inline void __list_add_rcu(struct
 {
     new->next = next;
     new->prev = prev;
-    smp_wmb();
+    wmb();
     next->prev = new;
     prev->next = new;
 }
@@ -244,7 +244,7 @@ static inline void list_replace_rcu(stru
 {
     new->next = old->next;
     new->prev = old->prev;
-    smp_wmb();
+    wmb();
     new->next->prev = new;
     new->prev->next = new;
     old->prev = LIST_POISON2;
@@ -712,7 +712,7 @@ static inline void hlist_replace_rcu(str
 
     new->next = next;
     new->pprev = old->pprev;
-    smp_wmb();
+    wmb();
     if (next)
         new->next->pprev = &new->next;
     *new->pprev = new;
@@ -754,7 +754,7 @@ static inline void hlist_add_head_rcu(st
     struct hlist_node *first = h->first;
     n->next = first;
     n->pprev = &h->first;
-    smp_wmb();
+    wmb();
     if (first)
         first->pprev = &n->next;
     h->first = n;
@@ -804,7 +804,7 @@ static inline void hlist_add_before_rcu(
 {
     n->pprev = next->pprev;
     n->next = next;
-    smp_wmb();
+    wmb();
     next->pprev = &n->next;
     *(n->pprev) = n;
 }
@@ -832,7 +832,7 @@ static inline void hlist_add_after_rcu(s
 {
     n->next = prev->next;
     n->pprev = &prev->next;
-    smp_wmb();
+    wmb();
     prev->next = n;
     if (n->next)
         n->next->pprev = &n->next;
diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/rcupdate.h
--- a/xen/include/xen/rcupdate.h
+++ b/xen/include/xen/rcupdate.h
@@ -136,7 +136,7 @@ typedef struct _rcu_read_lock rcu_read_l
  * call documents which pointers will be dereferenced by RCU read-side
  * code.
  */
-#define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); })
+#define rcu_assign_pointer(p, v) ({ wmb(); (p) = (v); })
 
 void rcu_init(void);
 void rcu_check_callbacks(int cpu);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAfO-0005Si-Gd; Wed, 08 Feb 2012 16:46:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAfM-0005QP-2c
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328719598!8333889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3424 invoked from network); 8 Feb 2012 16:46:38 -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;
	8 Feb 2012 16:46:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:37 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:38 +0000
MIME-Version: 1.0
X-Mercurial-Node: 79bc45a90933c6ecf226f50f3a7e820635b78135
Message-ID: <79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20 IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
directly using the VIOAPIC EOI register present in version 0x20,
rather than resorting to the legacy method of flipping the trigger
mode for the relevent RTE.

Currently, all required functionality is already present in the code,
except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 957b5ac44e32 -r 79bc45a90933 xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -227,11 +227,9 @@ static int vioapic_write(
         vioapic_write_indirect(vioapic, length, val);
         break;
 
-#if VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_EOI:
         vioapic_update_EOI(v->domain, val);
         break;
-#endif
 
     default:
         break;
diff -r 957b5ac44e32 -r 79bc45a90933 xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -31,7 +31,7 @@
 #include <public/hvm/save.h>
 
 #if !VIOAPIC_IS_IOSAPIC
-#define VIOAPIC_VERSION_ID 0x11 /* IOAPIC version */
+#define VIOAPIC_VERSION_ID 0x20 /* IOAPIC version */
 #else
 #define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
 #endif
@@ -45,7 +45,7 @@
 /* Direct registers. */
 #define VIOAPIC_REG_SELECT  0x00
 #define VIOAPIC_REG_WINDOW  0x10
-#define VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */
+#define VIOAPIC_REG_EOI     0x40
 
 /* Indirect registers. */
 #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAfO-0005Si-Gd; Wed, 08 Feb 2012 16:46:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvAfM-0005QP-2c
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328719598!8333889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3424 invoked from network); 8 Feb 2012 16:46:38 -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;
	8 Feb 2012 16:46:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:37 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:38 +0000
MIME-Version: 1.0
X-Mercurial-Node: 79bc45a90933c6ecf226f50f3a7e820635b78135
Message-ID: <79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:38 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20 IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
directly using the VIOAPIC EOI register present in version 0x20,
rather than resorting to the legacy method of flipping the trigger
mode for the relevent RTE.

Currently, all required functionality is already present in the code,
except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 957b5ac44e32 -r 79bc45a90933 xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -227,11 +227,9 @@ static int vioapic_write(
         vioapic_write_indirect(vioapic, length, val);
         break;
 
-#if VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_EOI:
         vioapic_update_EOI(v->domain, val);
         break;
-#endif
 
     default:
         break;
diff -r 957b5ac44e32 -r 79bc45a90933 xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -31,7 +31,7 @@
 #include <public/hvm/save.h>
 
 #if !VIOAPIC_IS_IOSAPIC
-#define VIOAPIC_VERSION_ID 0x11 /* IOAPIC version */
+#define VIOAPIC_VERSION_ID 0x20 /* IOAPIC version */
 #else
 #define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
 #endif
@@ -45,7 +45,7 @@
 /* Direct registers. */
 #define VIOAPIC_REG_SELECT  0x00
 #define VIOAPIC_REG_WINDOW  0x10
-#define VIOAPIC_REG_EOI     0x40 /* IA64 IOSAPIC only */
+#define VIOAPIC_REG_EOI     0x40
 
 /* Indirect registers. */
 #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 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.xensource.com>)
	id 1RvAfT-0005UX-LN; Wed, 08 Feb 2012 16:46:51 +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 1RvAfR-0005Tg-At
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328719585!52101629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1841 invoked from network); 8 Feb 2012 16:46:25 -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;
	8 Feb 2012 16:46:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:48 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:48 +0000
MIME-Version: 1.0
X-Mercurial-Node: d59767433c7f8913c198ca849048eba741d82e1c
Message-ID: <d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from the
	x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

__ia64__ really really should not be defined in the x86 arch subtree,
so remove it from xen/include/public/arch-x86/hvm/save.h

This in turn allows the removal of VIOAPIC_IS_IOSAPIC, as x86 does not
use streamlined {IO,L}APICs, allowing for the removal of more code
from the x86 tree.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 79bc45a90933 -r d59767433c7f xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -59,12 +59,10 @@ static unsigned long vioapic_read_indire
                   | (VIOAPIC_VERSION_ID & 0xff));
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
     case VIOAPIC_REG_ARB_ID:
         result = ((vioapic->id & 0xf) << 24);
         break;
-#endif
 
     default:
     {
@@ -179,14 +177,12 @@ static void vioapic_write_indirect(
         /* Writes are ignored. */
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
         vioapic->id = (val >> 24) & 0xf;
         break;
 
     case VIOAPIC_REG_ARB_ID:
         break;
-#endif
 
     default:
     {
diff -r 79bc45a90933 -r d59767433c7f xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -30,11 +30,7 @@
 #include <xen/smp.h>
 #include <public/hvm/save.h>
 
-#if !VIOAPIC_IS_IOSAPIC
 #define VIOAPIC_VERSION_ID 0x20 /* IOAPIC version */
-#else
-#define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
-#endif
 
 #define VIOAPIC_EDGE_TRIG  0
 #define VIOAPIC_LEVEL_TRIG 1
diff -r 79bc45a90933 -r d59767433c7f xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -344,12 +344,7 @@ DECLARE_HVM_SAVE_TYPE(PIC, 3, struct hvm
  * IO-APIC
  */
 
-#ifdef __ia64__
-#define VIOAPIC_IS_IOSAPIC 1
-#define VIOAPIC_NUM_PINS  24
-#else
 #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
-#endif
 
 struct hvm_hw_vioapic {
     uint64_t base_address;
@@ -368,13 +363,8 @@ struct hvm_hw_vioapic {
             uint8_t trig_mode:1;
             uint8_t mask:1;
             uint8_t reserve:7;
-#if !VIOAPIC_IS_IOSAPIC
             uint8_t reserved[4];
             uint8_t dest_id;
-#else
-            uint8_t reserved[3];
-            uint16_t dest_id;
-#endif
         } fields;
     } redirtbl[VIOAPIC_NUM_PINS];
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:46:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 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.xensource.com>)
	id 1RvAfT-0005UX-LN; Wed, 08 Feb 2012 16:46:51 +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 1RvAfR-0005Tg-At
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:46:49 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328719585!52101629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1841 invoked from network); 8 Feb 2012 16:46:25 -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;
	8 Feb 2012 16:46:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:46:48 +0000
Received: from andrewcoop.uk.xensource.com (10.80.2.18) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:46:48 +0000
MIME-Version: 1.0
X-Mercurial-Node: d59767433c7f8913c198ca849048eba741d82e1c
Message-ID: <d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.1
Date: Wed, 8 Feb 2012 16:45:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xensource.com
Cc: keir@xen.org, jbeulich@suse.com
Subject: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from the
	x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

__ia64__ really really should not be defined in the x86 arch subtree,
so remove it from xen/include/public/arch-x86/hvm/save.h

This in turn allows the removal of VIOAPIC_IS_IOSAPIC, as x86 does not
use streamlined {IO,L}APICs, allowing for the removal of more code
from the x86 tree.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 79bc45a90933 -r d59767433c7f xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -59,12 +59,10 @@ static unsigned long vioapic_read_indire
                   | (VIOAPIC_VERSION_ID & 0xff));
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
     case VIOAPIC_REG_ARB_ID:
         result = ((vioapic->id & 0xf) << 24);
         break;
-#endif
 
     default:
     {
@@ -179,14 +177,12 @@ static void vioapic_write_indirect(
         /* Writes are ignored. */
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
         vioapic->id = (val >> 24) & 0xf;
         break;
 
     case VIOAPIC_REG_ARB_ID:
         break;
-#endif
 
     default:
     {
diff -r 79bc45a90933 -r d59767433c7f xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -30,11 +30,7 @@
 #include <xen/smp.h>
 #include <public/hvm/save.h>
 
-#if !VIOAPIC_IS_IOSAPIC
 #define VIOAPIC_VERSION_ID 0x20 /* IOAPIC version */
-#else
-#define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
-#endif
 
 #define VIOAPIC_EDGE_TRIG  0
 #define VIOAPIC_LEVEL_TRIG 1
diff -r 79bc45a90933 -r d59767433c7f xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -344,12 +344,7 @@ DECLARE_HVM_SAVE_TYPE(PIC, 3, struct hvm
  * IO-APIC
  */
 
-#ifdef __ia64__
-#define VIOAPIC_IS_IOSAPIC 1
-#define VIOAPIC_NUM_PINS  24
-#else
 #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
-#endif
 
 struct hvm_hw_vioapic {
     uint64_t base_address;
@@ -368,13 +363,8 @@ struct hvm_hw_vioapic {
             uint8_t trig_mode:1;
             uint8_t mask:1;
             uint8_t reserve:7;
-#if !VIOAPIC_IS_IOSAPIC
             uint8_t reserved[4];
             uint8_t dest_id;
-#else
-            uint8_t reserved[3];
-            uint16_t dest_id;
-#endif
         } fields;
     } redirtbl[VIOAPIC_NUM_PINS];
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:47:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16: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.xensource.com>)
	id 1RvAfw-0005fS-BV; Wed, 08 Feb 2012 16:47:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAft-0005cs-TW
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:47:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328719631!14042347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2454 invoked from network); 8 Feb 2012 16:47:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:47:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:47:12 +0000
Message-ID: <1328719630.6133.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 8 Feb 2012 16:47:10 +0000
In-Reply-To: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 11:49 +0000, Anthony PERARD wrote:
> This patch provide the code to set the VNC password to QEMU upstream through
> VNC. The password is still stored in xenstore but will not be used by QEMU
> upstream.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> ---
>  tools/libxl/libxl_create.c   |    3 +++
>  tools/libxl/libxl_dm.c       |   21 ++++++++++++---------
>  tools/libxl/libxl_internal.h |    1 +
>  tools/libxl/libxl_qmp.c      |   37 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 53 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index ebf2ed7..ae0d668 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -619,6 +619,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          if (dm_info->device_model_version
>              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
>              libxl__qmp_initializations(ctx, domid);
> +            if (dm_info->vncpasswd) {
> +                libxl__qmp_vnc_password(gc, domid, dm_info->vncpasswd);

Is your tree up to date? I thought I'd removed dm_info ;-)

This seems like the sort of thing libxl__qmp_initializations ought to
handle. Perhaps we should pass the domain_config down and do it there?

> +            }
>          }
>          ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
>          if (ret < 0) {
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 97d91b4..6f7d0d5 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -271,10 +271,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (info->vnc) {
>          int display = 0;
>          const char *listen = "127.0.0.1";
> +        char *vncarg = NULL;
>  
> -        if (info->vncpasswd && info->vncpasswd[0]) {
> -            assert(!"missing code for supplying vnc password to qemu");
> -        }
>          flexarray_append(dm_args, "-vnc");
>  
>          if (info->vncdisplay) {
> @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>          }
>  
>          if (strchr(listen, ':') != NULL)
> -            flexarray_append(dm_args,
> -                    libxl__sprintf(gc, "%s%s", listen,
> -                        info->vncunused ? ",to=99" : ""));
> +            vncarg = libxl__sprintf(gc, "%s", listen);
>          else
> -            flexarray_append(dm_args,
> -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> -                        info->vncunused ? ",to=99" : ""));
> +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> +        if (info->vncpasswd && info->vncpasswd[0]) {
> +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> +        }
> +        if (info->vncunused) {
> +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);

Not new, but I've been meaning to ask: what is to=99 for here? It seems
a bit arbitrary and the default behaviour without it appears to be to
keep looking for an available port which sounds like what we want.

> +        }
> +        flexarray_append(dm_args, vncarg);
>      }
>      if (info->sdl) {
>          flexarray_append(dm_args, "-sdl");
> @@ -862,6 +863,8 @@ int libxl__create_device_model(libxl__gc *gc,
>      }
>  
>      if (info->vncpasswd) {
> +        /* This xenstore key will only be used by qemu-xen-traditionnal.
> +         * The code to supply vncpasswd to qemu-xen is later. */
>  retry_transaction:
>          /* Find uuid and the write the vnc password to xenstore for qemu. */
>          t = xs_transaction_start(ctx->xsh);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fa7fb16..b33be99 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -592,6 +592,7 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
>                                 libxl_device_pci *pcidev);
>  /* Save current QEMU state into fd. */
>  _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
> +_hidden int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password);
>  /* 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 1777e44..274db19 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -879,6 +879,43 @@ out:
>      return rc;
>  }
>  
> +static int qmp_change(libxl__gc *gc, int domid,
> +                      char *device, char *target, char *arg)
> +{
> +    libxl__qmp_handler *qmp = NULL;
> +    flexarray_t *parameters = NULL;
> +    libxl_key_value_list args = NULL;
> +    int rc = 0;
> +
> +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    if (!qmp)
> +        return ERROR_FAIL;
> +
> +    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;
> +
> +    rc = qmp_synchronous_send(qmp, "change", &args,
> +                              NULL, NULL, qmp->timeout);
> +
> +    flexarray_free(parameters);
> +    libxl__qmp_close(qmp);
> +    return rc;
> +}
> +
> +int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password)
> +{
> +    if (!password)
> +        return ERROR_FAIL;
> +
> +    return qmp_change(gc, domid, "vnc", "password", password);
> +}
> +
>  int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:47:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16: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.xensource.com>)
	id 1RvAfw-0005fS-BV; Wed, 08 Feb 2012 16:47:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAft-0005cs-TW
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:47:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328719631!14042347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2454 invoked from network); 8 Feb 2012 16:47:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 16:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:47:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:47:12 +0000
Message-ID: <1328719630.6133.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 8 Feb 2012 16:47:10 +0000
In-Reply-To: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 11:49 +0000, Anthony PERARD wrote:
> This patch provide the code to set the VNC password to QEMU upstream through
> VNC. The password is still stored in xenstore but will not be used by QEMU
> upstream.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> ---
>  tools/libxl/libxl_create.c   |    3 +++
>  tools/libxl/libxl_dm.c       |   21 ++++++++++++---------
>  tools/libxl/libxl_internal.h |    1 +
>  tools/libxl/libxl_qmp.c      |   37 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 53 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index ebf2ed7..ae0d668 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -619,6 +619,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>          if (dm_info->device_model_version
>              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
>              libxl__qmp_initializations(ctx, domid);
> +            if (dm_info->vncpasswd) {
> +                libxl__qmp_vnc_password(gc, domid, dm_info->vncpasswd);

Is your tree up to date? I thought I'd removed dm_info ;-)

This seems like the sort of thing libxl__qmp_initializations ought to
handle. Perhaps we should pass the domain_config down and do it there?

> +            }
>          }
>          ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
>          if (ret < 0) {
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 97d91b4..6f7d0d5 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -271,10 +271,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      if (info->vnc) {
>          int display = 0;
>          const char *listen = "127.0.0.1";
> +        char *vncarg = NULL;
>  
> -        if (info->vncpasswd && info->vncpasswd[0]) {
> -            assert(!"missing code for supplying vnc password to qemu");
> -        }
>          flexarray_append(dm_args, "-vnc");
>  
>          if (info->vncdisplay) {
> @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>          }
>  
>          if (strchr(listen, ':') != NULL)
> -            flexarray_append(dm_args,
> -                    libxl__sprintf(gc, "%s%s", listen,
> -                        info->vncunused ? ",to=99" : ""));
> +            vncarg = libxl__sprintf(gc, "%s", listen);
>          else
> -            flexarray_append(dm_args,
> -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> -                        info->vncunused ? ",to=99" : ""));
> +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> +        if (info->vncpasswd && info->vncpasswd[0]) {
> +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> +        }
> +        if (info->vncunused) {
> +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);

Not new, but I've been meaning to ask: what is to=99 for here? It seems
a bit arbitrary and the default behaviour without it appears to be to
keep looking for an available port which sounds like what we want.

> +        }
> +        flexarray_append(dm_args, vncarg);
>      }
>      if (info->sdl) {
>          flexarray_append(dm_args, "-sdl");
> @@ -862,6 +863,8 @@ int libxl__create_device_model(libxl__gc *gc,
>      }
>  
>      if (info->vncpasswd) {
> +        /* This xenstore key will only be used by qemu-xen-traditionnal.
> +         * The code to supply vncpasswd to qemu-xen is later. */
>  retry_transaction:
>          /* Find uuid and the write the vnc password to xenstore for qemu. */
>          t = xs_transaction_start(ctx->xsh);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fa7fb16..b33be99 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -592,6 +592,7 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
>                                 libxl_device_pci *pcidev);
>  /* Save current QEMU state into fd. */
>  _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
> +_hidden int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password);
>  /* 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 1777e44..274db19 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -879,6 +879,43 @@ out:
>      return rc;
>  }
>  
> +static int qmp_change(libxl__gc *gc, int domid,
> +                      char *device, char *target, char *arg)
> +{
> +    libxl__qmp_handler *qmp = NULL;
> +    flexarray_t *parameters = NULL;
> +    libxl_key_value_list args = NULL;
> +    int rc = 0;
> +
> +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    if (!qmp)
> +        return ERROR_FAIL;
> +
> +    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;
> +
> +    rc = qmp_synchronous_send(qmp, "change", &args,
> +                              NULL, NULL, qmp->timeout);
> +
> +    flexarray_free(parameters);
> +    libxl__qmp_close(qmp);
> +    return rc;
> +}
> +
> +int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password)
> +{
> +    if (!password)
> +        return ERROR_FAIL;
> +
> +    return qmp_change(gc, domid, "vnc", "password", password);
> +}
> +
>  int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:49:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAiN-0006EH-1n; Wed, 08 Feb 2012 16:49:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAiK-0006DA-7d
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:49:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328719782!7403668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14938 invoked from network); 8 Feb 2012 16:49:42 -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;
	8 Feb 2012 16:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:49:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:49:20 +0000
Message-ID: <1328719758.6133.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 8 Feb 2012 16:49:18 +0000
In-Reply-To: <alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
References: <4F30134C02000078000716AE@nat28.tlf.novell.com>
	<20273.24097.477195.904462@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 11:56 +0000, Stefano Stabellini wrote:
> On Tue, 7 Feb 2012, Ian Jackson wrote:
> > Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> > > How is the supposedly strait clone on xenbits related to the "real" tree?
> > > It doesn't seem to be tracking it, so I'm sort of confused whether I
> > > could in fact use the upstream tree in favor of the made up mirror.
> > 
> > AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> > but rather one with various other patches needed for Xen.  But Stefano
> > will be able to comment for sure.
> 
> Hi Jan,
> qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
> based on qemu-stable-1.0.git, it is going to have many more Xen specific
> backports than the upstream stable tree.

The default rule will be that such patches will be backports though,
right? e.g. backported patches must have already been committed to the
upstream dev branch, somewhat similar to the Linux kernel
stable_kernel_rules.txt?

Ian.

> In particular I am talking about the QEMU timers, save/restore and PCI
> passthrough series.
> 
> - Stefano
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:49:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAiN-0006EH-1n; Wed, 08 Feb 2012 16:49:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvAiK-0006DA-7d
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:49:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328719782!7403668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14938 invoked from network); 8 Feb 2012 16:49:42 -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;
	8 Feb 2012 16:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:49:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:49:20 +0000
Message-ID: <1328719758.6133.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 8 Feb 2012 16:49:18 +0000
In-Reply-To: <alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
References: <4F30134C02000078000716AE@nat28.tlf.novell.com>
	<20273.24097.477195.904462@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 11:56 +0000, Stefano Stabellini wrote:
> On Tue, 7 Feb 2012, Ian Jackson wrote:
> > Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> > > How is the supposedly strait clone on xenbits related to the "real" tree?
> > > It doesn't seem to be tracking it, so I'm sort of confused whether I
> > > could in fact use the upstream tree in favor of the made up mirror.
> > 
> > AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> > but rather one with various other patches needed for Xen.  But Stefano
> > will be able to comment for sure.
> 
> Hi Jan,
> qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
> based on qemu-stable-1.0.git, it is going to have many more Xen specific
> backports than the upstream stable tree.

The default rule will be that such patches will be backports though,
right? e.g. backported patches must have already been committed to the
upstream dev branch, somewhat similar to the Linux kernel
stable_kernel_rules.txt?

Ian.

> In particular I am talking about the QEMU timers, save/restore and PCI
> passthrough series.
> 
> - Stefano
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:52:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAkl-0006Y7-Ot; Wed, 08 Feb 2012 16:52:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvAkk-0006Xj-0Q
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:52:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328719932!13475961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23067 invoked from network); 8 Feb 2012 16:52:12 -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;
	8 Feb 2012 16:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:52:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:52:12 +0000
Date: Wed, 8 Feb 2012 16:55:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328719758.6133.74.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081654281.3196@kaball-desktop>
References: <4F30134C02000078000716AE@nat28.tlf.novell.com>
	<20273.24097.477195.904462@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
	<1328719758.6133.74.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-08 at 11:56 +0000, Stefano Stabellini wrote:
> > On Tue, 7 Feb 2012, Ian Jackson wrote:
> > > Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> > > > How is the supposedly strait clone on xenbits related to the "real" tree?
> > > > It doesn't seem to be tracking it, so I'm sort of confused whether I
> > > > could in fact use the upstream tree in favor of the made up mirror.
> > > 
> > > AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> > > but rather one with various other patches needed for Xen.  But Stefano
> > > will be able to comment for sure.
> > 
> > Hi Jan,
> > qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
> > based on qemu-stable-1.0.git, it is going to have many more Xen specific
> > backports than the upstream stable tree.
> 
> The default rule will be that such patches will be backports though,
> right? e.g. backported patches must have already been committed to the
> upstream dev branch, somewhat similar to the Linux kernel
> stable_kernel_rules.txt?
 
Yes, I meant backports of upstream commits.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:52:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAkl-0006Y7-Ot; Wed, 08 Feb 2012 16:52:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvAkk-0006Xj-0Q
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 16:52:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328719932!13475961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23067 invoked from network); 8 Feb 2012 16:52:12 -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;
	8 Feb 2012 16:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:52:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 16:52:12 +0000
Date: Wed, 8 Feb 2012 16:55:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328719758.6133.74.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081654281.3196@kaball-desktop>
References: <4F30134C02000078000716AE@nat28.tlf.novell.com>
	<20273.24097.477195.904462@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202081153490.3196@kaball-desktop>
	<1328719758.6133.74.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] relation between upstream qemu tree and
 qemu-upstream-unstable.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-08 at 11:56 +0000, Stefano Stabellini wrote:
> > On Tue, 7 Feb 2012, Ian Jackson wrote:
> > > Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and qemu-upstream-unstable.git"):
> > > > How is the supposedly strait clone on xenbits related to the "real" tree?
> > > > It doesn't seem to be tracking it, so I'm sort of confused whether I
> > > > could in fact use the upstream tree in favor of the made up mirror.
> > > 
> > > AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> > > but rather one with various other patches needed for Xen.  But Stefano
> > > will be able to comment for sure.
> > 
> > Hi Jan,
> > qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
> > based on qemu-stable-1.0.git, it is going to have many more Xen specific
> > backports than the upstream stable tree.
> 
> The default rule will be that such patches will be backports though,
> right? e.g. backported patches must have already been committed to the
> upstream dev branch, somewhat similar to the Linux kernel
> stable_kernel_rules.txt?
 
Yes, I meant backports of upstream commits.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAld-0006dm-TB; Wed, 08 Feb 2012 16:53: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 1RvAla-0006dJ-TJ; Wed, 08 Feb 2012 16:53:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328719870!63039051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23665 invoked from network); 8 Feb 2012 16:51: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;
	8 Feb 2012 16:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:53:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:53:10 +0000
Message-ID: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Frank, Chen" <chysun2000@163.com>
Date: Wed, 8 Feb 2012 16:53:08 +0000
In-Reply-To: <615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
References: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 01:00 +0000, Frank, Chen wrote:
> The problem is where to download the cross compiler
> "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and
> mcpu=cortex-a15.
>  
> Would someone give me one avaiable URL to download the right
> compiler? 

I use
http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 16:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvAld-0006dm-TB; Wed, 08 Feb 2012 16:53: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 1RvAla-0006dJ-TJ; Wed, 08 Feb 2012 16:53:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328719870!63039051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23665 invoked from network); 8 Feb 2012 16:51: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;
	8 Feb 2012 16:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 16:53:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	16:53:10 +0000
Message-ID: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Frank, Chen" <chysun2000@163.com>
Date: Wed, 8 Feb 2012 16:53:08 +0000
In-Reply-To: <615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
References: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-06 at 01:00 +0000, Frank, Chen wrote:
> The problem is where to download the cross compiler
> "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and
> mcpu=cortex-a15.
>  
> Would someone give me one avaiable URL to download the right
> compiler? 

I use
http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvAxT-0006zW-D2; Wed, 08 Feb 2012 17:05:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvAxR-0006zR-QP
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:05:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328720719!13960737!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16112 invoked from network); 8 Feb 2012 17:05:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 17:05:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvAxH-000OXH-Se; Wed, 08 Feb 2012 17:05:15 +0000
Date: Wed, 8 Feb 2012 17:05:15 +0000
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120208170515.GA71900@ocelot.phlegethon.org>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20
	IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote:
> Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
> directly using the VIOAPIC EOI register present in version 0x20,
> rather than resorting to the legacy method of flipping the trigger
> mode for the relevent RTE.
> 
> Currently, all required functionality is already present in the code,
> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

This probably ought to introduce a hvm save record to say which kind of
IOAPIC the VM was booted with, so that after a live migration the OS
doesn't get confused. :(

It seems unlikely that any OSes rely on the IOAPIC version (and the
behaviour of that register) being static after boot, but better safe
than sorry - there might be some confusion in resume from S3 or similar.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvAxT-0006zW-D2; Wed, 08 Feb 2012 17:05:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvAxR-0006zR-QP
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:05:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328720719!13960737!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16112 invoked from network); 8 Feb 2012 17:05:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 17:05:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvAxH-000OXH-Se; Wed, 08 Feb 2012 17:05:15 +0000
Date: Wed, 8 Feb 2012 17:05:15 +0000
From: Tim Deegan <tim@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120208170515.GA71900@ocelot.phlegethon.org>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, keir@xen.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20
	IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote:
> Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
> directly using the VIOAPIC EOI register present in version 0x20,
> rather than resorting to the legacy method of flipping the trigger
> mode for the relevent RTE.
> 
> Currently, all required functionality is already present in the code,
> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

This probably ought to introduce a hvm save record to say which kind of
IOAPIC the VM was booted with, so that after a live migration the OS
doesn't get confused. :(

It seems unlikely that any OSes rely on the IOAPIC version (and the
behaviour of that register) being static after boot, but better safe
than sorry - there might be some confusion in resume from S3 or similar.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:12:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:12:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvB4K-0007EE-FE; Wed, 08 Feb 2012 17:12:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RvB4J-0007E7-Kv
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:12:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328721144!13122490!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19998 invoked from network); 8 Feb 2012 17:12:25 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:12:25 -0000
Received: by ggnu1 with SMTP id u1so10359541ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 09:12:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=w+MLu/DGmfP6hZdiH5J9In2tZyM2Zli2zkyAQo2pHH0=;
	b=fAiOKHbLAZMQnES0d3O/ldcjqwkKi80khs8gilamd0ruog4gcjzaSpKUL/f3nhlTqe
	l/Z3P1TQ+AG4aem0XMjGZqAt8i64UlV4QPEGljtJJKmPeXfpOTQkTUsoXtkV+gKj6Wsc
	+wgTwB79y+C+WVRSqciW3TqtJXz0qI98TFaVQ=
Received: by 10.50.160.131 with SMTP id xk3mr35489039igb.19.1328721144056;
	Wed, 08 Feb 2012 09:12:24 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id k3sm782219igq.1.2012.02.08.09.12.21
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 09:12:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 09:12:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB57ECEF.2AAA2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20 IOAPIC
Thread-Index: AczmhM3R/ngFjWpOe0aAQckIinftzw==
In-Reply-To: <20120208170515.GA71900@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20
	IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 17:05, "Tim Deegan" <tim@xen.org> wrote:

> At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote:
>> Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
>> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
>> directly using the VIOAPIC EOI register present in version 0x20,
>> rather than resorting to the legacy method of flipping the trigger
>> mode for the relevent RTE.
>> 
>> Currently, all required functionality is already present in the code,
>> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.
>> 
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> This probably ought to introduce a hvm save record to say which kind of
> IOAPIC the VM was booted with, so that after a live migration the OS
> doesn't get confused. :(
> 
> It seems unlikely that any OSes rely on the IOAPIC version (and the
> behaviour of that register) being static after boot, but better safe
> than sorry - there might be some confusion in resume from S3 or similar.

Yes, so unless there is actually a demonstrable win from bumping the
version, we should just not bother, and cull the IS_IOSAPIC code sections.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:12:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:12:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvB4K-0007EE-FE; Wed, 08 Feb 2012 17:12:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RvB4J-0007E7-Kv
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:12:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328721144!13122490!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19998 invoked from network); 8 Feb 2012 17:12:25 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:12:25 -0000
Received: by ggnu1 with SMTP id u1so10359541ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 09:12:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=w+MLu/DGmfP6hZdiH5J9In2tZyM2Zli2zkyAQo2pHH0=;
	b=fAiOKHbLAZMQnES0d3O/ldcjqwkKi80khs8gilamd0ruog4gcjzaSpKUL/f3nhlTqe
	l/Z3P1TQ+AG4aem0XMjGZqAt8i64UlV4QPEGljtJJKmPeXfpOTQkTUsoXtkV+gKj6Wsc
	+wgTwB79y+C+WVRSqciW3TqtJXz0qI98TFaVQ=
Received: by 10.50.160.131 with SMTP id xk3mr35489039igb.19.1328721144056;
	Wed, 08 Feb 2012 09:12:24 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id k3sm782219igq.1.2012.02.08.09.12.21
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 09:12:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 09:12:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB57ECEF.2AAA2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20 IOAPIC
Thread-Index: AczmhM3R/ngFjWpOe0aAQckIinftzw==
In-Reply-To: <20120208170515.GA71900@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20
	IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 17:05, "Tim Deegan" <tim@xen.org> wrote:

> At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote:
>> Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
>> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
>> directly using the VIOAPIC EOI register present in version 0x20,
>> rather than resorting to the legacy method of flipping the trigger
>> mode for the relevent RTE.
>> 
>> Currently, all required functionality is already present in the code,
>> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.
>> 
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> This probably ought to introduce a hvm save record to say which kind of
> IOAPIC the VM was booted with, so that after a live migration the OS
> doesn't get confused. :(
> 
> It seems unlikely that any OSes rely on the IOAPIC version (and the
> behaviour of that register) being static after boot, but better safe
> than sorry - there might be some confusion in resume from S3 or similar.

Yes, so unless there is actually a demonstrable win from bumping the
version, we should just not bother, and cull the IS_IOSAPIC code sections.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:13:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvB5S-0007J0-Vk; Wed, 08 Feb 2012 17:13: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 1RvB5R-0007Io-PN
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:13:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328721169!53443625!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5651 invoked from network); 8 Feb 2012 17:12:51 -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;
	8 Feb 2012 17:12:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="21761239"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:13:19 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	12:13:18 -0500
Message-ID: <4F32AD2D.6010408@citrix.com>
Date: Wed, 8 Feb 2012 17:13:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
	<20120208170515.GA71900@ocelot.phlegethon.org>
In-Reply-To: <20120208170515.GA71900@ocelot.phlegethon.org>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20
	IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/12 17:05, Tim Deegan wrote:
> At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote:
>> Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
>> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
>> directly using the VIOAPIC EOI register present in version 0x20,
>> rather than resorting to the legacy method of flipping the trigger
>> mode for the relevent RTE.
>>
>> Currently, all required functionality is already present in the code,
>> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> This probably ought to introduce a hvm save record to say which kind of
> IOAPIC the VM was booted with, so that after a live migration the OS
> doesn't get confused. :(
>
> It seems unlikely that any OSes rely on the IOAPIC version (and the
> behaviour of that register) being static after boot, but better safe
> than sorry - there might be some confusion in resume from S3 or similar.
>
> Tim.

Hmm - That is a very good point and I had not considered the
possibility.  I withdraw this patch pending more thought.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:13:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvB5S-0007J0-Vk; Wed, 08 Feb 2012 17:13: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 1RvB5R-0007Io-PN
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:13:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328721169!53443625!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5651 invoked from network); 8 Feb 2012 17:12:51 -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;
	8 Feb 2012 17:12:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="21761239"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:13:19 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	12:13:18 -0500
Message-ID: <4F32AD2D.6010408@citrix.com>
Date: Wed, 8 Feb 2012 17:13:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<79bc45a90933c6ecf226.1328719538@andrewcoop.uk.xensource.com>
	<20120208170515.GA71900@ocelot.phlegethon.org>
In-Reply-To: <20120208170515.GA71900@ocelot.phlegethon.org>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20
	IOAPIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/12 17:05, Tim Deegan wrote:
> At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote:
>> Currently, hvm emulates a version 0x11 IOAPIC.  However, depending on
>> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by
>> directly using the VIOAPIC EOI register present in version 0x20,
>> rather than resorting to the legacy method of flipping the trigger
>> mode for the relevent RTE.
>>
>> Currently, all required functionality is already present in the code,
>> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> This probably ought to introduce a hvm save record to say which kind of
> IOAPIC the VM was booted with, so that after a live migration the OS
> doesn't get confused. :(
>
> It seems unlikely that any OSes rely on the IOAPIC version (and the
> behaviour of that register) being static after boot, but better safe
> than sorry - there might be some confusion in resume from S3 or similar.
>
> Tim.

Hmm - That is a very good point and I had not considered the
possibility.  I withdraw this patch pending more thought.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:16:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvB8P-0007Tb-K5; Wed, 08 Feb 2012 17:16:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1RvB8N-0007T2-MO
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:16:43 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328721396!8338278!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9195 invoked from network); 8 Feb 2012 17:16:37 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:16:37 -0000
Received: by bkcjg15 with SMTP id jg15so1245375bkc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 09:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=r+X5/qjEcPoSN4ZFf56o0pPbFdOIdTcO2017KpgNLdI=;
	b=fFPidDqzBFThCjD1R5M8ISe7dWGRsWoM8BhQ2LK7VaNWpwFfYBv7+XwbLhM3EZuwUy
	2weIs5+jcFR8GfSQXLw2YPoA1Z9alrk6614+H93CFjst8GnJfYwaJiNMzwSCo7zG8a6W
	oBtrsFyseHqSNGEdORNUPo92SyouRZxe5hHZ4=
Received: by 10.204.128.202 with SMTP id l10mr12572749bks.116.1328721396437;
	Wed, 08 Feb 2012 09:16:36 -0800 (PST)
Received: from [172.16.26.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id w15sm6386198bku.0.2012.02.08.09.16.34
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 09:16:35 -0800 (PST)
Message-ID: <4F32ADEE.6020006@xen.org>
Date: Wed, 08 Feb 2012 17:16:30 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security Response Problem Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No problem: will do it tomorrow

On 08/02/2012 16:43, Ian Campbell wrote:
> Hi Lars,
>
> Please can we amend the Security Process [0] to add to the end of the
> section "5. Advisory public release:" text like:
>
>          Published advisories will be added to the Security
>          Announcements[1] wiki page.
>
> (with the link in the appropriate syntax/place)
>
> The reason is that this document also serves as our checklist for things
> to do when making a security announcement and this will serve to remind
> us to update that page.
>
> Thanks.
>
> [0] http://www.xen.org/projects/security_vulnerability_process.html
> [1] http://wiki.xen.org/wiki/Security_Announcements
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:16:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvB8P-0007Tb-K5; Wed, 08 Feb 2012 17:16:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1RvB8N-0007T2-MO
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:16:43 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328721396!8338278!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9195 invoked from network); 8 Feb 2012 17:16:37 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:16:37 -0000
Received: by bkcjg15 with SMTP id jg15so1245375bkc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 09:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=r+X5/qjEcPoSN4ZFf56o0pPbFdOIdTcO2017KpgNLdI=;
	b=fFPidDqzBFThCjD1R5M8ISe7dWGRsWoM8BhQ2LK7VaNWpwFfYBv7+XwbLhM3EZuwUy
	2weIs5+jcFR8GfSQXLw2YPoA1Z9alrk6614+H93CFjst8GnJfYwaJiNMzwSCo7zG8a6W
	oBtrsFyseHqSNGEdORNUPo92SyouRZxe5hHZ4=
Received: by 10.204.128.202 with SMTP id l10mr12572749bks.116.1328721396437;
	Wed, 08 Feb 2012 09:16:36 -0800 (PST)
Received: from [172.16.26.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id w15sm6386198bku.0.2012.02.08.09.16.34
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 09:16:35 -0800 (PST)
Message-ID: <4F32ADEE.6020006@xen.org>
Date: Wed, 08 Feb 2012 17:16:30 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security Response Problem Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No problem: will do it tomorrow

On 08/02/2012 16:43, Ian Campbell wrote:
> Hi Lars,
>
> Please can we amend the Security Process [0] to add to the end of the
> section "5. Advisory public release:" text like:
>
>          Published advisories will be added to the Security
>          Announcements[1] wiki page.
>
> (with the link in the appropriate syntax/place)
>
> The reason is that this document also serves as our checklist for things
> to do when making a security announcement and this will serve to remind
> us to update that page.
>
> Thanks.
>
> [0] http://www.xen.org/projects/security_vulnerability_process.html
> [1] http://wiki.xen.org/wiki/Security_Announcements
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:17:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvB98-0007Z6-1s; Wed, 08 Feb 2012 17:17:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvB97-0007YQ-AT
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:17:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328721443!9814935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23464 invoked from network); 8 Feb 2012 17:17:23 -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;
	8 Feb 2012 17:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:17:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 17:17:23 +0000
Date: Wed, 8 Feb 2012 17:20:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jacobs Jordi <Jordi.Jacobs@howest.be>
In-Reply-To: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
Message-ID: <alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> Hi,
> 
> I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> 
> I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> one would be the best solution for Xen.
> 
> API remoting (gallium3D) (ex. Xen3D project)
> Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> 
> Can you guys give me your idea on the matter?
> Please also mention any existing projects you know that are related to this problem.

My personal opinion is that the simplest thing to do is OpenGL
remoting. Gallium remoting could also be OK but considering that many
cards don't have Gallium drivers we would probably end up doing two
conversions instead of one (DirectX->Gallium in the guest,
Gallium->OpenGL in dom0).
Mediated passthrough is very card specific so I am afraid you would end
up writing virtualization specific drivers for all the cards you want to
support. Not to mention that you might need to access some videocard
interfaces that on Nvidia are not discosed.

I believe that virtualbox already supports OpenGL remoting in a decent
way, so I would start from there, port what they have to Xen, and
improve it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:17:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvB98-0007Z6-1s; Wed, 08 Feb 2012 17:17:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvB97-0007YQ-AT
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:17:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328721443!9814935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23464 invoked from network); 8 Feb 2012 17:17:23 -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;
	8 Feb 2012 17:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10580885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:17:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 17:17:23 +0000
Date: Wed, 8 Feb 2012 17:20:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jacobs Jordi <Jordi.Jacobs@howest.be>
In-Reply-To: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
Message-ID: <alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> Hi,
> 
> I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> 
> I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> one would be the best solution for Xen.
> 
> API remoting (gallium3D) (ex. Xen3D project)
> Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> 
> Can you guys give me your idea on the matter?
> Please also mention any existing projects you know that are related to this problem.

My personal opinion is that the simplest thing to do is OpenGL
remoting. Gallium remoting could also be OK but considering that many
cards don't have Gallium drivers we would probably end up doing two
conversions instead of one (DirectX->Gallium in the guest,
Gallium->OpenGL in dom0).
Mediated passthrough is very card specific so I am afraid you would end
up writing virtualization specific drivers for all the cards you want to
support. Not to mention that you might need to access some videocard
interfaces that on Nvidia are not discosed.

I believe that virtualbox already supports OpenGL remoting in a decent
way, so I would start from there, port what they have to Xen, and
improve it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBED-0007vH-9B; Wed, 08 Feb 2012 17:22:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvBEB-0007uw-80
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:22:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328721753!12572305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7085 invoked from network); 8 Feb 2012 17:22:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:22:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="21761635"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:22:29 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	12:22:28 -0500
Message-ID: <4F32AF53.5070006@citrix.com>
Date: Wed, 8 Feb 2012 17:22:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
In-Reply-To: <101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------030705080408050104090800"
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------030705080408050104090800
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Version 2 attached - spelling mistake in the comment.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030705080408050104090800
Content-Type: text/x-patch; name="remove-CONFIG_SMP.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="remove-CONFIG_SMP.patch"

# HG changeset patch
# Parent eae25241d571ecad4d4b69ac89b0accc9e0fbf6c
CONFIG: remove CONFIG_SMP #ifdefs

CONFIG_SMP is always enabled and !CONFIG_SMP is not supported.  So
simplify the code a little by removing all #ifdefs.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r eae25241d571 xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -145,9 +145,8 @@ void ack_bad_irq(unsigned int irq)
 
 void __init apic_intr_init(void)
 {
-#ifdef CONFIG_SMP
     smp_intr_init();
-#endif
+
     /* self generated IPI for local APIC timer */
     set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt);
 
diff -r eae25241d571 xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -370,7 +370,6 @@ static void __devinit init_amd(struct cp
 {
 	u32 l, h;
 
-#ifdef CONFIG_SMP
 	unsigned long long value;
 
 	/* Disable TLB flush filter by setting HWCR.FFDIS on K8
@@ -384,7 +383,6 @@ static void __devinit init_amd(struct cp
 		value |= 1 << 6;
 		wrmsrl(MSR_K7_HWCR, value);
 	}
-#endif
 
 	/*
 	 *	FIXME: We should handle the K5 here. Set up the write
diff -r eae25241d571 xen/arch/x86/cpu/mtrr/cyrix.c
--- a/xen/arch/x86/cpu/mtrr/cyrix.c
+++ b/xen/arch/x86/cpu/mtrr/cyrix.c
@@ -279,9 +279,7 @@ cyrix_arr_init(void)
 	struct set_mtrr_context ctxt;
 	unsigned char ccr[7];
 	int ccrc[7] = { 0, 0, 0, 0, 0, 0, 0 };
-#ifdef CONFIG_SMP
 	int i;
-#endif
 
 	/* flush cache and enable MAPEN */
 	set_mtrr_prepare_save(&ctxt);
@@ -334,14 +332,13 @@ cyrix_arr_init(void)
 		ccrc[5] = 1;
 		setCx86(CX86_CCR5, ccr[5]);
 	}
-#ifdef CONFIG_SMP
+
 	for (i = 0; i < 7; i++)
 		ccr_state[i] = ccr[i];
 	for (i = 0; i < 8; i++)
 		cyrix_get_arr(i,
 			      &arr_state[i].base, &arr_state[i].size,
 			      &arr_state[i].type);
-#endif
 
 	set_mtrr_done(&ctxt);	/* flush cache and disable MAPEN */
 
diff -r eae25241d571 xen/arch/x86/cpu/mtrr/main.c
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -142,8 +142,6 @@ struct set_mtrr_data {
  */
 int hold_mtrr_updates_on_aps;
 
-#ifdef CONFIG_SMP
-
 static void ipi_handler(void *info)
 /*  [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
     [RETURNS] Nothing.
@@ -175,8 +173,6 @@ static void ipi_handler(void *info)
 	local_irq_restore(flags);
 }
 
-#endif
-
 static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
 	return type1 == MTRR_TYPE_UNCACHABLE ||
 	       type2 == MTRR_TYPE_UNCACHABLE ||
diff -r eae25241d571 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -513,7 +513,6 @@ static void clear_IO_APIC (void)
     }
 }
 
-#ifdef CONFIG_SMP
 static void
 set_ioapic_affinity_irq(struct irq_desc *desc, const cpumask_t *mask)
 {
@@ -550,7 +549,6 @@ set_ioapic_affinity_irq(struct irq_desc 
     spin_unlock_irqrestore(&ioapic_lock, flags);
 
 }
-#endif /* CONFIG_SMP */
 
 /*
  * Find the IRQ entry number of a certain pin.
@@ -630,7 +628,6 @@ static int pin_2_irq(int idx, int apic, 
  * we need to reprogram the ioredtbls to cater for the cpus which have come online
  * so mask in all cases should simply be TARGET_CPUS
  */
-#ifdef CONFIG_SMP
 void /*__init*/ setup_ioapic_dest(void)
 {
     int pin, ioapic, irq, irq_entry;
@@ -653,7 +650,6 @@ void /*__init*/ setup_ioapic_dest(void)
 
     }
 }
-#endif
 
 /*
  * EISA Edge/Level control register, ELCR
diff -r eae25241d571 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -304,11 +304,6 @@ static int __init p4_init(char ** cpu_ty
 		return 0;
 	}
 
-#ifndef CONFIG_SMP
-	*cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
-	model = &op_p4_spec;
-	return 1;
-#else
 	switch (current_cpu_data.x86_num_siblings) {
 		case 1:
 			*cpu_type = "i386/p4";
@@ -320,7 +315,7 @@ static int __init p4_init(char ** cpu_ty
 			model = &op_p4_ht2_spec;
 			return 1;
 	}
-#endif
+
 	printk("Xenoprof ERROR: P4 HyperThreading detected with > 2 threads\n");
 
 	return 0;
diff -r eae25241d571 xen/arch/x86/oprofile/op_model_p4.c
--- a/xen/arch/x86/oprofile/op_model_p4.c
+++ b/xen/arch/x86/oprofile/op_model_p4.c
@@ -40,19 +40,13 @@ static unsigned int num_counters = NUM_C
    kernel boot-time. */
 static inline void setup_num_counters(void)
 {
-#ifdef CONFIG_SMP
 	if (boot_cpu_data.x86_num_siblings == 2) 	/* XXX */
 		num_counters = NUM_COUNTERS_HT2;
-#endif
 }
 
 static int inline addr_increment(void)
 {
-#ifdef CONFIG_SMP
 	return boot_cpu_data.x86_num_siblings == 2 ? 2 : 1;
-#else
-	return 1;
-#endif
 }
 
 
@@ -383,11 +377,8 @@ static const struct p4_event_binding p4_
    or "odd" part of all the divided resources. */
 static unsigned int get_stagger(void)
 {
-#ifdef CONFIG_SMP
 	int cpu = smp_processor_id();
 	return (cpu != cpumask_first(per_cpu(cpu_sibling_mask, cpu)));
-#endif	
-	return 0;
 }
 
 
@@ -709,7 +700,6 @@ static void p4_stop(struct op_msrs const
 }
 
 
-#ifdef CONFIG_SMP
 struct op_x86_model_spec const op_p4_ht2_spec = {
 	.num_counters = NUM_COUNTERS_HT2,
 	.num_controls = NUM_CONTROLS_HT2,
@@ -719,7 +709,7 @@ struct op_x86_model_spec const op_p4_ht2
 	.start = &p4_start,
 	.stop = &p4_stop
 };
-#endif
+
 
 struct op_x86_model_spec const op_p4_spec = {
 	.num_counters = NUM_COUNTERS_NON_HT,
diff -r eae25241d571 xen/common/rcupdate.c
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -83,9 +83,7 @@ struct rcu_data {
     long            blimit;           /* Upper limit on a processed batch */
     int cpu;
     struct rcu_head barrier;
-#ifdef CONFIG_SMP
     long            last_rs_qlen;     /* qlen during the last resched */
-#endif
 };
 
 static DEFINE_PER_CPU(struct rcu_data, rcu_data);
diff -r eae25241d571 xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -21,7 +21,6 @@
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
-#define CONFIG_SMP 1
 #define CONFIG_X86_LOCAL_APIC 1
 #define CONFIG_X86_GOOD_APIC 1
 #define CONFIG_X86_IO_APIC 1
diff -r eae25241d571 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -189,13 +189,8 @@ struct cpuinfo_x86 {
 
 extern struct cpuinfo_x86 boot_cpu_data;
 
-#ifdef CONFIG_SMP
 extern struct cpuinfo_x86 cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
-#else
-#define cpu_data (&boot_cpu_data)
-#define current_cpu_data boot_cpu_data
-#endif
 
 extern void set_cpuid_faulting(bool_t enable);
 
diff -r eae25241d571 xen/include/asm-x86/smp.h
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -17,7 +17,6 @@
 #endif
 
 #define BAD_APICID -1U
-#ifdef CONFIG_SMP
 #ifndef __ASSEMBLY__
 
 /*
@@ -65,11 +64,4 @@ void __stop_this_cpu(void);
 
 #endif /* !__ASSEMBLY__ */
 
-#else /* CONFIG_SMP */
-
-#define cpu_physical_id(cpu)		boot_cpu_physical_apicid
-
-#define NO_PROC_ID		0xFF		/* No processor magic marker */
-
 #endif
-#endif
diff -r eae25241d571 xen/include/asm-x86/system.h
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -154,15 +154,9 @@ static always_inline unsigned long __cmp
 #define rmb()           barrier()
 #define wmb()           barrier()
 
-#ifdef CONFIG_SMP
 #define smp_mb()        mb()
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
-#else
-#define smp_mb()        barrier()
-#define smp_rmb()       barrier()
-#define smp_wmb()       barrier()
-#endif
 
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)

--------------030705080408050104090800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------030705080408050104090800--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBED-0007vH-9B; Wed, 08 Feb 2012 17:22:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvBEB-0007uw-80
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:22:43 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328721753!12572305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7085 invoked from network); 8 Feb 2012 17:22:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:22:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="21761635"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:22:29 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	12:22:28 -0500
Message-ID: <4F32AF53.5070006@citrix.com>
Date: Wed, 8 Feb 2012 17:22:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
In-Reply-To: <101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------030705080408050104090800"
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------030705080408050104090800
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Version 2 attached - spelling mistake in the comment.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030705080408050104090800
Content-Type: text/x-patch; name="remove-CONFIG_SMP.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="remove-CONFIG_SMP.patch"

# HG changeset patch
# Parent eae25241d571ecad4d4b69ac89b0accc9e0fbf6c
CONFIG: remove CONFIG_SMP #ifdefs

CONFIG_SMP is always enabled and !CONFIG_SMP is not supported.  So
simplify the code a little by removing all #ifdefs.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r eae25241d571 xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -145,9 +145,8 @@ void ack_bad_irq(unsigned int irq)
 
 void __init apic_intr_init(void)
 {
-#ifdef CONFIG_SMP
     smp_intr_init();
-#endif
+
     /* self generated IPI for local APIC timer */
     set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt);
 
diff -r eae25241d571 xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -370,7 +370,6 @@ static void __devinit init_amd(struct cp
 {
 	u32 l, h;
 
-#ifdef CONFIG_SMP
 	unsigned long long value;
 
 	/* Disable TLB flush filter by setting HWCR.FFDIS on K8
@@ -384,7 +383,6 @@ static void __devinit init_amd(struct cp
 		value |= 1 << 6;
 		wrmsrl(MSR_K7_HWCR, value);
 	}
-#endif
 
 	/*
 	 *	FIXME: We should handle the K5 here. Set up the write
diff -r eae25241d571 xen/arch/x86/cpu/mtrr/cyrix.c
--- a/xen/arch/x86/cpu/mtrr/cyrix.c
+++ b/xen/arch/x86/cpu/mtrr/cyrix.c
@@ -279,9 +279,7 @@ cyrix_arr_init(void)
 	struct set_mtrr_context ctxt;
 	unsigned char ccr[7];
 	int ccrc[7] = { 0, 0, 0, 0, 0, 0, 0 };
-#ifdef CONFIG_SMP
 	int i;
-#endif
 
 	/* flush cache and enable MAPEN */
 	set_mtrr_prepare_save(&ctxt);
@@ -334,14 +332,13 @@ cyrix_arr_init(void)
 		ccrc[5] = 1;
 		setCx86(CX86_CCR5, ccr[5]);
 	}
-#ifdef CONFIG_SMP
+
 	for (i = 0; i < 7; i++)
 		ccr_state[i] = ccr[i];
 	for (i = 0; i < 8; i++)
 		cyrix_get_arr(i,
 			      &arr_state[i].base, &arr_state[i].size,
 			      &arr_state[i].type);
-#endif
 
 	set_mtrr_done(&ctxt);	/* flush cache and disable MAPEN */
 
diff -r eae25241d571 xen/arch/x86/cpu/mtrr/main.c
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -142,8 +142,6 @@ struct set_mtrr_data {
  */
 int hold_mtrr_updates_on_aps;
 
-#ifdef CONFIG_SMP
-
 static void ipi_handler(void *info)
 /*  [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
     [RETURNS] Nothing.
@@ -175,8 +173,6 @@ static void ipi_handler(void *info)
 	local_irq_restore(flags);
 }
 
-#endif
-
 static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
 	return type1 == MTRR_TYPE_UNCACHABLE ||
 	       type2 == MTRR_TYPE_UNCACHABLE ||
diff -r eae25241d571 xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -513,7 +513,6 @@ static void clear_IO_APIC (void)
     }
 }
 
-#ifdef CONFIG_SMP
 static void
 set_ioapic_affinity_irq(struct irq_desc *desc, const cpumask_t *mask)
 {
@@ -550,7 +549,6 @@ set_ioapic_affinity_irq(struct irq_desc 
     spin_unlock_irqrestore(&ioapic_lock, flags);
 
 }
-#endif /* CONFIG_SMP */
 
 /*
  * Find the IRQ entry number of a certain pin.
@@ -630,7 +628,6 @@ static int pin_2_irq(int idx, int apic, 
  * we need to reprogram the ioredtbls to cater for the cpus which have come online
  * so mask in all cases should simply be TARGET_CPUS
  */
-#ifdef CONFIG_SMP
 void /*__init*/ setup_ioapic_dest(void)
 {
     int pin, ioapic, irq, irq_entry;
@@ -653,7 +650,6 @@ void /*__init*/ setup_ioapic_dest(void)
 
     }
 }
-#endif
 
 /*
  * EISA Edge/Level control register, ELCR
diff -r eae25241d571 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -304,11 +304,6 @@ static int __init p4_init(char ** cpu_ty
 		return 0;
 	}
 
-#ifndef CONFIG_SMP
-	*cpu_type = "i386/p4", XENOPROF_CPU_TYPE_SIZE);
-	model = &op_p4_spec;
-	return 1;
-#else
 	switch (current_cpu_data.x86_num_siblings) {
 		case 1:
 			*cpu_type = "i386/p4";
@@ -320,7 +315,7 @@ static int __init p4_init(char ** cpu_ty
 			model = &op_p4_ht2_spec;
 			return 1;
 	}
-#endif
+
 	printk("Xenoprof ERROR: P4 HyperThreading detected with > 2 threads\n");
 
 	return 0;
diff -r eae25241d571 xen/arch/x86/oprofile/op_model_p4.c
--- a/xen/arch/x86/oprofile/op_model_p4.c
+++ b/xen/arch/x86/oprofile/op_model_p4.c
@@ -40,19 +40,13 @@ static unsigned int num_counters = NUM_C
    kernel boot-time. */
 static inline void setup_num_counters(void)
 {
-#ifdef CONFIG_SMP
 	if (boot_cpu_data.x86_num_siblings == 2) 	/* XXX */
 		num_counters = NUM_COUNTERS_HT2;
-#endif
 }
 
 static int inline addr_increment(void)
 {
-#ifdef CONFIG_SMP
 	return boot_cpu_data.x86_num_siblings == 2 ? 2 : 1;
-#else
-	return 1;
-#endif
 }
 
 
@@ -383,11 +377,8 @@ static const struct p4_event_binding p4_
    or "odd" part of all the divided resources. */
 static unsigned int get_stagger(void)
 {
-#ifdef CONFIG_SMP
 	int cpu = smp_processor_id();
 	return (cpu != cpumask_first(per_cpu(cpu_sibling_mask, cpu)));
-#endif	
-	return 0;
 }
 
 
@@ -709,7 +700,6 @@ static void p4_stop(struct op_msrs const
 }
 
 
-#ifdef CONFIG_SMP
 struct op_x86_model_spec const op_p4_ht2_spec = {
 	.num_counters = NUM_COUNTERS_HT2,
 	.num_controls = NUM_CONTROLS_HT2,
@@ -719,7 +709,7 @@ struct op_x86_model_spec const op_p4_ht2
 	.start = &p4_start,
 	.stop = &p4_stop
 };
-#endif
+
 
 struct op_x86_model_spec const op_p4_spec = {
 	.num_counters = NUM_COUNTERS_NON_HT,
diff -r eae25241d571 xen/common/rcupdate.c
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -83,9 +83,7 @@ struct rcu_data {
     long            blimit;           /* Upper limit on a processed batch */
     int cpu;
     struct rcu_head barrier;
-#ifdef CONFIG_SMP
     long            last_rs_qlen;     /* qlen during the last resched */
-#endif
 };
 
 static DEFINE_PER_CPU(struct rcu_data, rcu_data);
diff -r eae25241d571 xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -21,7 +21,6 @@
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
-#define CONFIG_SMP 1
 #define CONFIG_X86_LOCAL_APIC 1
 #define CONFIG_X86_GOOD_APIC 1
 #define CONFIG_X86_IO_APIC 1
diff -r eae25241d571 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -189,13 +189,8 @@ struct cpuinfo_x86 {
 
 extern struct cpuinfo_x86 boot_cpu_data;
 
-#ifdef CONFIG_SMP
 extern struct cpuinfo_x86 cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
-#else
-#define cpu_data (&boot_cpu_data)
-#define current_cpu_data boot_cpu_data
-#endif
 
 extern void set_cpuid_faulting(bool_t enable);
 
diff -r eae25241d571 xen/include/asm-x86/smp.h
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -17,7 +17,6 @@
 #endif
 
 #define BAD_APICID -1U
-#ifdef CONFIG_SMP
 #ifndef __ASSEMBLY__
 
 /*
@@ -65,11 +64,4 @@ void __stop_this_cpu(void);
 
 #endif /* !__ASSEMBLY__ */
 
-#else /* CONFIG_SMP */
-
-#define cpu_physical_id(cpu)		boot_cpu_physical_apicid
-
-#define NO_PROC_ID		0xFF		/* No processor magic marker */
-
 #endif
-#endif
diff -r eae25241d571 xen/include/asm-x86/system.h
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -154,15 +154,9 @@ static always_inline unsigned long __cmp
 #define rmb()           barrier()
 #define wmb()           barrier()
 
-#ifdef CONFIG_SMP
 #define smp_mb()        mb()
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
-#else
-#define smp_mb()        barrier()
-#define smp_rmb()       barrier()
-#define smp_wmb()       barrier()
-#endif
 
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)

--------------030705080408050104090800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------030705080408050104090800--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBEB-0007vA-SX; Wed, 08 Feb 2012 17:22:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvBEA-0007v1-LM
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:22:42 +0000
Received: from [85.158.139.83:44065] by server-3.bemta-5.messagelabs.com id
	E0/8D-25605-16FA23F4; Wed, 08 Feb 2012 17:22:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328721761!14183519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30146 invoked from network); 8 Feb 2012 17:22:41 -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;
	8 Feb 2012 17:22:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:22:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 17:22:41 +0000
Date: Wed, 8 Feb 2012 17:25:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328718954.6133.64.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081725100.3196@kaball-desktop>
References: <4F317B58.4010405@invisiblethingslab.com>
	<1328718954.6133.64.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:
> > Is there a convenient way to setup the IP address for the _stubdom_ (to
> > connect to the vnc server running there) from within the corresponding
> > HVM config file on Xen 4.1? Or should one use dhcpd?
> 
> Currently the model with stubdomains is that the stub domain runs a PVFB
> device against a backend in dom0 (actually, another qemu) which does the
> vnc export etc so there is no networking to the stub dom.
> 
> I can see valid reasons why you would want to have the stubdom itself do
> the vnc export and therefore have a network of its own but I don't think
> the toolstack can express that right now. I think it was done in the
> early days of stubdoms, but I suspect in some hacky way (or perhaps just
> DHCP), and I don't know if that functionality has persisted to the
> present day.

I recall having removed that option a long time ago to simplify stubdom
configs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBEB-0007vA-SX; Wed, 08 Feb 2012 17:22:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvBEA-0007v1-LM
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:22:42 +0000
Received: from [85.158.139.83:44065] by server-3.bemta-5.messagelabs.com id
	E0/8D-25605-16FA23F4; Wed, 08 Feb 2012 17:22:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328721761!14183519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30146 invoked from network); 8 Feb 2012 17:22:41 -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;
	8 Feb 2012 17:22:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:22:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 17:22:41 +0000
Date: Wed, 8 Feb 2012 17:25:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328718954.6133.64.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081725100.3196@kaball-desktop>
References: <4F317B58.4010405@invisiblethingslab.com>
	<1328718954.6133.64.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:
> > Is there a convenient way to setup the IP address for the _stubdom_ (to
> > connect to the vnc server running there) from within the corresponding
> > HVM config file on Xen 4.1? Or should one use dhcpd?
> 
> Currently the model with stubdomains is that the stub domain runs a PVFB
> device against a backend in dom0 (actually, another qemu) which does the
> vnc export etc so there is no networking to the stub dom.
> 
> I can see valid reasons why you would want to have the stubdom itself do
> the vnc export and therefore have a network of its own but I don't think
> the toolstack can express that right now. I think it was done in the
> early days of stubdoms, but I suspect in some hacky way (or perhaps just
> DHCP), and I don't know if that functionality has persisted to the
> present day.

I recall having removed that option a long time ago to simplify stubdom
configs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:24:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBFk-00085G-PY; Wed, 08 Feb 2012 17:24:20 +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 1RvBFj-000859-OM
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:24:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328721801!55918399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25603 invoked from network); 8 Feb 2012 17:23:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:23:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="21761675"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:24:16 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	12:24:16 -0500
Message-ID: <4F32AFBF.7090201@citrix.com>
Date: Wed, 8 Feb 2012 17:24:15 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
In-Reply-To: <d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000606090804070302040309"
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the	x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000606090804070302040309
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Presented v2, refreshing the patch without emulating a version 0x20 IOAPIC

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000606090804070302040309
Content-Type: text/x-patch; name="remove-itanium-ifdefs-in-x86-tree.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="remove-itanium-ifdefs-in-x86-tree.patch"

# HG changeset patch
# Parent a8f3abaaf3102ab493957d33e17ce59447915401
CONFIG: remove #ifdef __ia64__ from the x86 arch tree

__ia64__ really really should not be defined in the x86 arch subtree,
so remove it from xen/include/public/arch-x86/hvm/save.h

This in turn allows the removal of VIOAPIC_IS_IOSAPIC, as x86 does not
use streamlined {IO,L}APICs, allowing for the removal of more code
from the x86 tree.

Changes since v1:
 *  Refresh patch following the decision not to try emulating a
    version 0x20 IOAPIC

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a8f3abaaf310 xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -59,12 +59,10 @@ static unsigned long vioapic_read_indire
                   | (VIOAPIC_VERSION_ID & 0xff));
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
     case VIOAPIC_REG_ARB_ID:
         result = ((vioapic->id & 0xf) << 24);
         break;
-#endif
 
     default:
     {
@@ -179,14 +177,12 @@ static void vioapic_write_indirect(
         /* Writes are ignored. */
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
         vioapic->id = (val >> 24) & 0xf;
         break;
 
     case VIOAPIC_REG_ARB_ID:
         break;
-#endif
 
     default:
     {
@@ -227,12 +223,6 @@ static int vioapic_write(
         vioapic_write_indirect(vioapic, length, val);
         break;
 
-#if VIOAPIC_IS_IOSAPIC
-    case VIOAPIC_REG_EOI:
-        vioapic_update_EOI(v->domain, val);
-        break;
-#endif
-
     default:
         break;
     }
diff -r a8f3abaaf310 xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -30,11 +30,7 @@
 #include <xen/smp.h>
 #include <public/hvm/save.h>
 
-#if !VIOAPIC_IS_IOSAPIC
 #define VIOAPIC_VERSION_ID 0x11 /* IOAPIC version */
-#else
-#define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
-#endif
 
 #define VIOAPIC_EDGE_TRIG  0
 #define VIOAPIC_LEVEL_TRIG 1
diff -r a8f3abaaf310 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -344,12 +344,7 @@ DECLARE_HVM_SAVE_TYPE(PIC, 3, struct hvm
  * IO-APIC
  */
 
-#ifdef __ia64__
-#define VIOAPIC_IS_IOSAPIC 1
-#define VIOAPIC_NUM_PINS  24
-#else
 #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
-#endif
 
 struct hvm_hw_vioapic {
     uint64_t base_address;
@@ -368,13 +363,8 @@ struct hvm_hw_vioapic {
             uint8_t trig_mode:1;
             uint8_t mask:1;
             uint8_t reserve:7;
-#if !VIOAPIC_IS_IOSAPIC
             uint8_t reserved[4];
             uint8_t dest_id;
-#else
-            uint8_t reserved[3];
-            uint16_t dest_id;
-#endif
         } fields;
     } redirtbl[VIOAPIC_NUM_PINS];
 };

--------------000606090804070302040309
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000606090804070302040309--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:24:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBFk-00085G-PY; Wed, 08 Feb 2012 17:24:20 +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 1RvBFj-000859-OM
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:24:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328721801!55918399!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25603 invoked from network); 8 Feb 2012 17:23:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:23:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="21761675"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 12:24:16 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	12:24:16 -0500
Message-ID: <4F32AFBF.7090201@citrix.com>
Date: Wed, 8 Feb 2012 17:24:15 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
In-Reply-To: <d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000606090804070302040309"
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the	x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000606090804070302040309
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Presented v2, refreshing the patch without emulating a version 0x20 IOAPIC

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------000606090804070302040309
Content-Type: text/x-patch; name="remove-itanium-ifdefs-in-x86-tree.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="remove-itanium-ifdefs-in-x86-tree.patch"

# HG changeset patch
# Parent a8f3abaaf3102ab493957d33e17ce59447915401
CONFIG: remove #ifdef __ia64__ from the x86 arch tree

__ia64__ really really should not be defined in the x86 arch subtree,
so remove it from xen/include/public/arch-x86/hvm/save.h

This in turn allows the removal of VIOAPIC_IS_IOSAPIC, as x86 does not
use streamlined {IO,L}APICs, allowing for the removal of more code
from the x86 tree.

Changes since v1:
 *  Refresh patch following the decision not to try emulating a
    version 0x20 IOAPIC

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a8f3abaaf310 xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -59,12 +59,10 @@ static unsigned long vioapic_read_indire
                   | (VIOAPIC_VERSION_ID & 0xff));
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
     case VIOAPIC_REG_ARB_ID:
         result = ((vioapic->id & 0xf) << 24);
         break;
-#endif
 
     default:
     {
@@ -179,14 +177,12 @@ static void vioapic_write_indirect(
         /* Writes are ignored. */
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
         vioapic->id = (val >> 24) & 0xf;
         break;
 
     case VIOAPIC_REG_ARB_ID:
         break;
-#endif
 
     default:
     {
@@ -227,12 +223,6 @@ static int vioapic_write(
         vioapic_write_indirect(vioapic, length, val);
         break;
 
-#if VIOAPIC_IS_IOSAPIC
-    case VIOAPIC_REG_EOI:
-        vioapic_update_EOI(v->domain, val);
-        break;
-#endif
-
     default:
         break;
     }
diff -r a8f3abaaf310 xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -30,11 +30,7 @@
 #include <xen/smp.h>
 #include <public/hvm/save.h>
 
-#if !VIOAPIC_IS_IOSAPIC
 #define VIOAPIC_VERSION_ID 0x11 /* IOAPIC version */
-#else
-#define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
-#endif
 
 #define VIOAPIC_EDGE_TRIG  0
 #define VIOAPIC_LEVEL_TRIG 1
diff -r a8f3abaaf310 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -344,12 +344,7 @@ DECLARE_HVM_SAVE_TYPE(PIC, 3, struct hvm
  * IO-APIC
  */
 
-#ifdef __ia64__
-#define VIOAPIC_IS_IOSAPIC 1
-#define VIOAPIC_NUM_PINS  24
-#else
 #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
-#endif
 
 struct hvm_hw_vioapic {
     uint64_t base_address;
@@ -368,13 +363,8 @@ struct hvm_hw_vioapic {
             uint8_t trig_mode:1;
             uint8_t mask:1;
             uint8_t reserve:7;
-#if !VIOAPIC_IS_IOSAPIC
             uint8_t reserved[4];
             uint8_t dest_id;
-#else
-            uint8_t reserved[3];
-            uint16_t dest_id;
-#endif
         } fields;
     } redirtbl[VIOAPIC_NUM_PINS];
 };

--------------000606090804070302040309
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000606090804070302040309--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:24:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBGC-00088n-CV; Wed, 08 Feb 2012 17:24:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvBGA-00087q-D9
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:24:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328721879!14039911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28831 invoked from network); 8 Feb 2012 17:24: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;
	8 Feb 2012 17:24:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:24:16 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 17:24:16 +0000
Date: Wed, 8 Feb 2012 17:24:10 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328719630.6133.72.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Campbell wrote:

> On Wed, 2012-02-08 at 11:49 +0000, Anthony PERARD wrote:
> > This patch provide the code to set the VNC password to QEMU upstream through
> > VNC. The password is still stored in xenstore but will not be used by QEMU
> > upstream.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >
> > ---
> >  tools/libxl/libxl_create.c   |    3 +++
> >  tools/libxl/libxl_dm.c       |   21 ++++++++++++---------
> >  tools/libxl/libxl_internal.h |    1 +
> >  tools/libxl/libxl_qmp.c      |   37 +++++++++++++++++++++++++++++++++++++
> >  4 files changed, 53 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index ebf2ed7..ae0d668 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -619,6 +619,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> >          if (dm_info->device_model_version
> >              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> >              libxl__qmp_initializations(ctx, domid);
> > +            if (dm_info->vncpasswd) {
> > +                libxl__qmp_vnc_password(gc, domid, dm_info->vncpasswd);
>
> Is your tree up to date? I thought I'd removed dm_info ;-)

:), I forgot that.

> This seems like the sort of thing libxl__qmp_initializations ought to
> handle. Perhaps we should pass the domain_config down and do it there?

Yes, I'll do that.

> > +            }
> >          }
> >          ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
> >          if (ret < 0) {
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 97d91b4..6f7d0d5 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -271,10 +271,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >      if (info->vnc) {
> >          int display = 0;
> >          const char *listen = "127.0.0.1";
> > +        char *vncarg = NULL;
> >
> > -        if (info->vncpasswd && info->vncpasswd[0]) {
> > -            assert(!"missing code for supplying vnc password to qemu");
> > -        }
> >          flexarray_append(dm_args, "-vnc");
> >
> >          if (info->vncdisplay) {
> > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >          }
> >
> >          if (strchr(listen, ':') != NULL)
> > -            flexarray_append(dm_args,
> > -                    libxl__sprintf(gc, "%s%s", listen,
> > -                        info->vncunused ? ",to=99" : ""));
> > +            vncarg = libxl__sprintf(gc, "%s", listen);
> >          else
> > -            flexarray_append(dm_args,
> > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > -                        info->vncunused ? ",to=99" : ""));
> > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > +        }
> > +        if (info->vncunused) {
> > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
>
> Not new, but I've been meaning to ask: what is to=99 for here? It seems
> a bit arbitrary and the default behaviour without it appears to be to
> keep looking for an available port which sounds like what we want.

QEMU will search for an open port until it reach the vnc display port 99
(5999 TCP port).

For the 99, I probably read this number somewhere. But after checking in
QEMU code, I do not see any limitation for this number. So we could
probably change this number for the port number max (-5900, default vnc
port).

> > +        flexarray_append(dm_args, vncarg);
> >      }
> >      if (info->sdl) {
> >          flexarray_append(dm_args, "-sdl");
> > @@ -862,6 +863,8 @@ int libxl__create_device_model(libxl__gc *gc,
> >      }
> >
> >      if (info->vncpasswd) {
> > +        /* This xenstore key will only be used by qemu-xen-traditionnal.
> > +         * The code to supply vncpasswd to qemu-xen is later. */
> >  retry_transaction:
> >          /* Find uuid and the write the vnc password to xenstore for qemu. */
> >          t = xs_transaction_start(ctx->xsh);
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index fa7fb16..b33be99 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -592,6 +592,7 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
> >                                 libxl_device_pci *pcidev);
> >  /* Save current QEMU state into fd. */
> >  _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
> > +_hidden int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password);
> >  /* 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 1777e44..274db19 100644
> > --- a/tools/libxl/libxl_qmp.c
> > +++ b/tools/libxl/libxl_qmp.c
> > @@ -879,6 +879,43 @@ out:
> >      return rc;
> >  }
> >
> > +static int qmp_change(libxl__gc *gc, int domid,
> > +                      char *device, char *target, char *arg)
> > +{
> > +    libxl__qmp_handler *qmp = NULL;
> > +    flexarray_t *parameters = NULL;
> > +    libxl_key_value_list args = NULL;
> > +    int rc = 0;
> > +
> > +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> > +    if (!qmp)
> > +        return ERROR_FAIL;
> > +
> > +    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;
> > +
> > +    rc = qmp_synchronous_send(qmp, "change", &args,
> > +                              NULL, NULL, qmp->timeout);
> > +
> > +    flexarray_free(parameters);
> > +    libxl__qmp_close(qmp);
> > +    return rc;
> > +}
> > +
> > +int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password)
> > +{
> > +    if (!password)
> > +        return ERROR_FAIL;
> > +
> > +    return qmp_change(gc, domid, "vnc", "password", password);
> > +}
> > +
> >  int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
> >  {
> >      libxl__qmp_handler *qmp = NULL;
>
>
>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:24:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBGC-00088n-CV; Wed, 08 Feb 2012 17:24:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvBGA-00087q-D9
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:24:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328721879!14039911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28831 invoked from network); 8 Feb 2012 17:24: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;
	8 Feb 2012 17:24:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:24:16 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 17:24:16 +0000
Date: Wed, 8 Feb 2012 17:24:10 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328719630.6133.72.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Campbell wrote:

> On Wed, 2012-02-08 at 11:49 +0000, Anthony PERARD wrote:
> > This patch provide the code to set the VNC password to QEMU upstream through
> > VNC. The password is still stored in xenstore but will not be used by QEMU
> > upstream.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> >
> > ---
> >  tools/libxl/libxl_create.c   |    3 +++
> >  tools/libxl/libxl_dm.c       |   21 ++++++++++++---------
> >  tools/libxl/libxl_internal.h |    1 +
> >  tools/libxl/libxl_qmp.c      |   37 +++++++++++++++++++++++++++++++++++++
> >  4 files changed, 53 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index ebf2ed7..ae0d668 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -619,6 +619,9 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> >          if (dm_info->device_model_version
> >              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> >              libxl__qmp_initializations(ctx, domid);
> > +            if (dm_info->vncpasswd) {
> > +                libxl__qmp_vnc_password(gc, domid, dm_info->vncpasswd);
>
> Is your tree up to date? I thought I'd removed dm_info ;-)

:), I forgot that.

> This seems like the sort of thing libxl__qmp_initializations ought to
> handle. Perhaps we should pass the domain_config down and do it there?

Yes, I'll do that.

> > +            }
> >          }
> >          ret = libxl__confirm_device_model_startup(gc, dm_info, dm_starting);
> >          if (ret < 0) {
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 97d91b4..6f7d0d5 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -271,10 +271,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >      if (info->vnc) {
> >          int display = 0;
> >          const char *listen = "127.0.0.1";
> > +        char *vncarg = NULL;
> >
> > -        if (info->vncpasswd && info->vncpasswd[0]) {
> > -            assert(!"missing code for supplying vnc password to qemu");
> > -        }
> >          flexarray_append(dm_args, "-vnc");
> >
> >          if (info->vncdisplay) {
> > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> >          }
> >
> >          if (strchr(listen, ':') != NULL)
> > -            flexarray_append(dm_args,
> > -                    libxl__sprintf(gc, "%s%s", listen,
> > -                        info->vncunused ? ",to=99" : ""));
> > +            vncarg = libxl__sprintf(gc, "%s", listen);
> >          else
> > -            flexarray_append(dm_args,
> > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > -                        info->vncunused ? ",to=99" : ""));
> > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > +        }
> > +        if (info->vncunused) {
> > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
>
> Not new, but I've been meaning to ask: what is to=99 for here? It seems
> a bit arbitrary and the default behaviour without it appears to be to
> keep looking for an available port which sounds like what we want.

QEMU will search for an open port until it reach the vnc display port 99
(5999 TCP port).

For the 99, I probably read this number somewhere. But after checking in
QEMU code, I do not see any limitation for this number. So we could
probably change this number for the port number max (-5900, default vnc
port).

> > +        flexarray_append(dm_args, vncarg);
> >      }
> >      if (info->sdl) {
> >          flexarray_append(dm_args, "-sdl");
> > @@ -862,6 +863,8 @@ int libxl__create_device_model(libxl__gc *gc,
> >      }
> >
> >      if (info->vncpasswd) {
> > +        /* This xenstore key will only be used by qemu-xen-traditionnal.
> > +         * The code to supply vncpasswd to qemu-xen is later. */
> >  retry_transaction:
> >          /* Find uuid and the write the vnc password to xenstore for qemu. */
> >          t = xs_transaction_start(ctx->xsh);
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index fa7fb16..b33be99 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -592,6 +592,7 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
> >                                 libxl_device_pci *pcidev);
> >  /* Save current QEMU state into fd. */
> >  _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
> > +_hidden int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password);
> >  /* 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 1777e44..274db19 100644
> > --- a/tools/libxl/libxl_qmp.c
> > +++ b/tools/libxl/libxl_qmp.c
> > @@ -879,6 +879,43 @@ out:
> >      return rc;
> >  }
> >
> > +static int qmp_change(libxl__gc *gc, int domid,
> > +                      char *device, char *target, char *arg)
> > +{
> > +    libxl__qmp_handler *qmp = NULL;
> > +    flexarray_t *parameters = NULL;
> > +    libxl_key_value_list args = NULL;
> > +    int rc = 0;
> > +
> > +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> > +    if (!qmp)
> > +        return ERROR_FAIL;
> > +
> > +    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;
> > +
> > +    rc = qmp_synchronous_send(qmp, "change", &args,
> > +                              NULL, NULL, qmp->timeout);
> > +
> > +    flexarray_free(parameters);
> > +    libxl__qmp_close(qmp);
> > +    return rc;
> > +}
> > +
> > +int libxl__qmp_vnc_password(libxl__gc *gc, int domid, char *password)
> > +{
> > +    if (!password)
> > +        return ERROR_FAIL;
> > +
> > +    return qmp_change(gc, domid, "vnc", "password", password);
> > +}
> > +
> >  int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
> >  {
> >      libxl__qmp_handler *qmp = NULL;
>
>
>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:26:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBHt-0008N1-T4; Wed, 08 Feb 2012 17:26:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvBHr-0008Mc-J8
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:26:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328721985!13487875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24866 invoked from network); 8 Feb 2012 17:26:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:26:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	17:26:25 +0000
Message-ID: <1328721983.6133.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 17:26:23 +0000
In-Reply-To: <CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
	<1328707739.6133.16.camel@zakaz.uk.xensource.com>
	<CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 14:53 +0000, Julian Pidancet wrote:
> On Wed, Feb 8, 2012 at 1:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2012-02-05 at 16:18 +0000, Julian Pidancet wrote:
> >> When booting HVMs with SeaBIOS, the BIOS itself takes care of extracting
> >> option ROMs from the PCI devices. These ROMs are usually provided with by
> >> the device model (qemu).
> >> Thus, hvmloader should not require any longer the rombios, stdvga,
> >> cirrusvga or etherboot ROMs to be present.
> >>
> >> Also, the 32bitbios_support.c file is specific to rombios and should not
> >> be built when building hvmloader with seabios.
> >
> >> [...]
> >> @@ -475,16 +477,20 @@ int main(void)
> >>         switch ( virtual_vga )
> >>          {
> >>          case VGA_cirrus:
> >> +#ifdef ENABLE_CIRRUSVGA
> >
> > Just outside the context here is an "if ( bios->load_roms )" which
> > prevents the ROMs from being loaded if we are using SeaBIOS -- is that
> > not sufficient for your needs?
> >
> > Currently hvmloader builds with support for both ROMBIOS and SeaBIOS and
> > selects the one to use based on a configuration key in xenstore (pushed
> > down by the toolstack depending on which qemu you are running). Have you
> > modified something elsewhere in order to build a SeaBIOS-only hvmloader?
> >
> > Perhaps it would make sense for the ROMs to be keyed off whether or not
> > ROMBIOS is enabled rather than each keying off their own DIR var?
> >
> > You seem to have mixed some other changes, specifically s/:=/?=/ in a
> > few places and also some sort of change wrt how eb-roms.h is generated
> > (including dropping the 8086100e ROM from the image, which must be
> > discussed).
> >
> > These other changes should be submitted and rationalised separately.
> >
> 
> The purpose of this change was initially to allow the user to build
> hvmloader with SeaBIOS only without having to depend on rombios,
> vgabios or ipxe. I've only tested my changes by calling make from the
> hvmloader/ directory directly. The Xen build system could also not
> have to depend on bcc for example.
> 
> In addition to the patch I submitted, I suppose it would make sense to
> introduce a global configuration option for the Makefile in the
> firmware/ directory to decide wether it should recurse in the rombios,
> vgabios, and etherboot directories.
> 
> I changed some variable assignations := by ?= because I wanted the
> user of the build system to be able to specify a custom build
> directory for these ROMs.

Seems fair enough, although I would still like to see separate issues
solved in separate patches.

> Same thing for the etherboot ROM, I made the Makefile not use eb-rom.h
> and replace it with a call to mkhex on the binary file directly, so
> the user can choose which ROM to inject into hvmloader, and I found it
> to be more consistent with the rest of the Makefile.

I don't think you have replaced like with like. Specifically you seem to
have omitted the 8086100e ROM -- look how eb-roms.h is built in
tools/firmware/etherboot using NICS = rtl8139 8086100e from the file
"Config" compared with your code which only uses ETHERBOOT_NIC :=
rtl8139.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:26:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBHt-0008N1-T4; Wed, 08 Feb 2012 17:26:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvBHr-0008Mc-J8
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:26:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328721985!13487875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24866 invoked from network); 8 Feb 2012 17:26:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:26:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 17:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 8 Feb 2012
	17:26:25 +0000
Message-ID: <1328721983.6133.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 17:26:23 +0000
In-Reply-To: <CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
	<1328707739.6133.16.camel@zakaz.uk.xensource.com>
	<CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 14:53 +0000, Julian Pidancet wrote:
> On Wed, Feb 8, 2012 at 1:28 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Sun, 2012-02-05 at 16:18 +0000, Julian Pidancet wrote:
> >> When booting HVMs with SeaBIOS, the BIOS itself takes care of extracting
> >> option ROMs from the PCI devices. These ROMs are usually provided with by
> >> the device model (qemu).
> >> Thus, hvmloader should not require any longer the rombios, stdvga,
> >> cirrusvga or etherboot ROMs to be present.
> >>
> >> Also, the 32bitbios_support.c file is specific to rombios and should not
> >> be built when building hvmloader with seabios.
> >
> >> [...]
> >> @@ -475,16 +477,20 @@ int main(void)
> >>         switch ( virtual_vga )
> >>          {
> >>          case VGA_cirrus:
> >> +#ifdef ENABLE_CIRRUSVGA
> >
> > Just outside the context here is an "if ( bios->load_roms )" which
> > prevents the ROMs from being loaded if we are using SeaBIOS -- is that
> > not sufficient for your needs?
> >
> > Currently hvmloader builds with support for both ROMBIOS and SeaBIOS and
> > selects the one to use based on a configuration key in xenstore (pushed
> > down by the toolstack depending on which qemu you are running). Have you
> > modified something elsewhere in order to build a SeaBIOS-only hvmloader?
> >
> > Perhaps it would make sense for the ROMs to be keyed off whether or not
> > ROMBIOS is enabled rather than each keying off their own DIR var?
> >
> > You seem to have mixed some other changes, specifically s/:=/?=/ in a
> > few places and also some sort of change wrt how eb-roms.h is generated
> > (including dropping the 8086100e ROM from the image, which must be
> > discussed).
> >
> > These other changes should be submitted and rationalised separately.
> >
> 
> The purpose of this change was initially to allow the user to build
> hvmloader with SeaBIOS only without having to depend on rombios,
> vgabios or ipxe. I've only tested my changes by calling make from the
> hvmloader/ directory directly. The Xen build system could also not
> have to depend on bcc for example.
> 
> In addition to the patch I submitted, I suppose it would make sense to
> introduce a global configuration option for the Makefile in the
> firmware/ directory to decide wether it should recurse in the rombios,
> vgabios, and etherboot directories.
> 
> I changed some variable assignations := by ?= because I wanted the
> user of the build system to be able to specify a custom build
> directory for these ROMs.

Seems fair enough, although I would still like to see separate issues
solved in separate patches.

> Same thing for the etherboot ROM, I made the Makefile not use eb-rom.h
> and replace it with a call to mkhex on the binary file directly, so
> the user can choose which ROM to inject into hvmloader, and I found it
> to be more consistent with the rest of the Makefile.

I don't think you have replaced like with like. Specifically you seem to
have omitted the 8086100e ROM -- look how eb-roms.h is built in
tools/firmware/etherboot using NICS = rtl8139 8086100e from the file
"Config" compared with your code which only uses ETHERBOOT_NIC :=
rtl8139.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBQP-0000Km-HK; Wed, 08 Feb 2012 17:35:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RvBQO-0000Kh-4Q
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:35:20 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328722493!65040237!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gMTUwNDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15199 invoked from network); 8 Feb 2012 17:34:53 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 17:34:53 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D32DB21447
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 12:35:14 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Wed, 08 Feb 2012 12:35:14 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=M1
	E+y1kxDKl7UFqGJfnsPXLvRLE=; b=jO7NPPpsAIlBPus5uCyIAErdvGukenBdx+
	2ZHdnwIL1IT6h4sHoJOV20rlY1YBKVpz0gve/BtYW1iPgbBxhX/pU+0LVJAVuf9l
	p3mIQVvS0TGgYPwF+cKQ0kiU76vBYFayJoGRoiQ2MdZPySAwVPE46EegaipesPU/
	/Al+gJhOE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=M1E+
	y1kxDKl7UFqGJfnsPXLvRLE=; b=AWa+PHnf7VLXw4gzV9hQ7K4ovBM4o3hsuhw/
	B1L2NE7QqC1YvM0K28sqalbPzHxScV/zuOCrNrskO9hkpXE044aWhsAiN5827OaE
	9uhg0ZWcavPuuqpjOtFYMz/4I1eGAviObtk0Q/xsN7wyiuwiHymxo9uIi3QICFN/
	TN5IzhI=
X-Sasl-enc: GDNv/h3ItOSaBTUauY608OoEXgxZD9EEyBrn5rp7UkOJ 1328722514
Received: from [10.137.2.12] (afqj78.neoplus.adsl.tpnet.pl [178.42.165.78])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 3BA8148247C;
	Wed,  8 Feb 2012 12:35:14 -0500 (EST)
Message-ID: <4F32B24E.6040801@invisiblethingslab.com>
Date: Wed, 08 Feb 2012 18:35:10 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F317B58.4010405@invisiblethingslab.com>
	<1328718954.6133.64.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328718954.6133.64.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4097639027212238284=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============4097639027212238284==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9EB8CFEC348C0ED4C06E11A7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9EB8CFEC348C0ED4C06E11A7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/08/12 17:35, Ian Campbell wrote:
> On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:
>> Is there a convenient way to setup the IP address for the _stubdom_ (t=
o
>> connect to the vnc server running there) from within the corresponding=

>> HVM config file on Xen 4.1? Or should one use dhcpd?
>=20
> Currently the model with stubdomains is that the stub domain runs a PVF=
B
> device against a backend in dom0 (actually, another qemu) which does th=
e
> vnc export etc so there is no networking to the stub dom.
>=20
> I can see valid reasons why you would want to have the stubdom itself d=
o
> the vnc export and therefore have a network of its own but I don't thin=
k
> the toolstack can express that right now. I think it was done in the
> early days of stubdoms, but I suspect in some hacky way (or perhaps jus=
t
> DHCP), and I don't know if that functionality has persisted to the
> present day.
>=20

Actually I just wanted to access VNC in the stubdom for some testing --
in the long term I don't think this is a desirable option, because: 1)
using VNC adds lots of overhead -- e.g. it's unable to do zero-copy
framebuffer virtualization in contrast to e.g. our Qubes GUI daemon, and
2) in order to keep it on a reasonably secure level, one would need to
have one more domain (a "vncviewer" domain) which would be connected to
the stubdom's vncserver (note that in Qubes we don't have networking in
Dom0 -- and we don't want to have it).

The pvfb solution will work just fine for me testing purposes for now
(but only for testing, as any solution that requires me to run qemu in
Dom0 is not satisfactory from the security point of view IMHO).

So, many thanks for pointing this out -- I was so convinced that a
stubdom runs its own vncserver, that I missed all those qemu processes
in my Dom0 ;)

Thanks!
joanna.


--------------enig9EB8CFEC348C0ED4C06E11A7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPMrJOAAoJEDaIqHeRBUM0+ksH/1YZiG680vsBszclsy1x8wa+
W/Ryj9374FQG7KspuhhSzqwk9X7cZN+zNujNwk2rKJIKjo8bpqNr2w5Bl+k4pSdJ
XuYuBB5eMmso52MtJA8ewqSxQlEVpQ6sDLXHaDL7FtI9o3b5xikIvAejnu8fYb/a
BjgNe7HQRQ5E6u0krEnzygDgBYtNGlgmWTPRZ5cJhyAa9jQYPs53YSMKGcSmiTc+
cectedYSKNBjx3FM5ZLNWIcuQGAdJZROlmON+KRCrfQLyhcqpNgtnNMB1HgY36ZZ
mIi0Wzag8T1MBrlZzdCw9VPIMCctaGYZPp+Bv9oi53Cao/NuE56BZDxjkG1gjvk=
=sBkN
-----END PGP SIGNATURE-----

--------------enig9EB8CFEC348C0ED4C06E11A7--


--===============4097639027212238284==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4097639027212238284==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBQP-0000Km-HK; Wed, 08 Feb 2012 17:35:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RvBQO-0000Kh-4Q
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:35:20 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328722493!65040237!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gMTUwNDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15199 invoked from network); 8 Feb 2012 17:34:53 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 17:34:53 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D32DB21447
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 12:35:14 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Wed, 08 Feb 2012 12:35:14 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=M1
	E+y1kxDKl7UFqGJfnsPXLvRLE=; b=jO7NPPpsAIlBPus5uCyIAErdvGukenBdx+
	2ZHdnwIL1IT6h4sHoJOV20rlY1YBKVpz0gve/BtYW1iPgbBxhX/pU+0LVJAVuf9l
	p3mIQVvS0TGgYPwF+cKQ0kiU76vBYFayJoGRoiQ2MdZPySAwVPE46EegaipesPU/
	/Al+gJhOE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=M1E+
	y1kxDKl7UFqGJfnsPXLvRLE=; b=AWa+PHnf7VLXw4gzV9hQ7K4ovBM4o3hsuhw/
	B1L2NE7QqC1YvM0K28sqalbPzHxScV/zuOCrNrskO9hkpXE044aWhsAiN5827OaE
	9uhg0ZWcavPuuqpjOtFYMz/4I1eGAviObtk0Q/xsN7wyiuwiHymxo9uIi3QICFN/
	TN5IzhI=
X-Sasl-enc: GDNv/h3ItOSaBTUauY608OoEXgxZD9EEyBrn5rp7UkOJ 1328722514
Received: from [10.137.2.12] (afqj78.neoplus.adsl.tpnet.pl [178.42.165.78])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 3BA8148247C;
	Wed,  8 Feb 2012 12:35:14 -0500 (EST)
Message-ID: <4F32B24E.6040801@invisiblethingslab.com>
Date: Wed, 08 Feb 2012 18:35:10 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F317B58.4010405@invisiblethingslab.com>
	<1328718954.6133.64.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328718954.6133.64.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Setting IP address for stubdom?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4097639027212238284=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============4097639027212238284==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9EB8CFEC348C0ED4C06E11A7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9EB8CFEC348C0ED4C06E11A7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/08/12 17:35, Ian Campbell wrote:
> On Tue, 2012-02-07 at 19:28 +0000, Joanna Rutkowska wrote:
>> Is there a convenient way to setup the IP address for the _stubdom_ (t=
o
>> connect to the vnc server running there) from within the corresponding=

>> HVM config file on Xen 4.1? Or should one use dhcpd?
>=20
> Currently the model with stubdomains is that the stub domain runs a PVF=
B
> device against a backend in dom0 (actually, another qemu) which does th=
e
> vnc export etc so there is no networking to the stub dom.
>=20
> I can see valid reasons why you would want to have the stubdom itself d=
o
> the vnc export and therefore have a network of its own but I don't thin=
k
> the toolstack can express that right now. I think it was done in the
> early days of stubdoms, but I suspect in some hacky way (or perhaps jus=
t
> DHCP), and I don't know if that functionality has persisted to the
> present day.
>=20

Actually I just wanted to access VNC in the stubdom for some testing --
in the long term I don't think this is a desirable option, because: 1)
using VNC adds lots of overhead -- e.g. it's unable to do zero-copy
framebuffer virtualization in contrast to e.g. our Qubes GUI daemon, and
2) in order to keep it on a reasonably secure level, one would need to
have one more domain (a "vncviewer" domain) which would be connected to
the stubdom's vncserver (note that in Qubes we don't have networking in
Dom0 -- and we don't want to have it).

The pvfb solution will work just fine for me testing purposes for now
(but only for testing, as any solution that requires me to run qemu in
Dom0 is not satisfactory from the security point of view IMHO).

So, many thanks for pointing this out -- I was so convinced that a
stubdom runs its own vncserver, that I missed all those qemu processes
in my Dom0 ;)

Thanks!
joanna.


--------------enig9EB8CFEC348C0ED4C06E11A7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPMrJOAAoJEDaIqHeRBUM0+ksH/1YZiG680vsBszclsy1x8wa+
W/Ryj9374FQG7KspuhhSzqwk9X7cZN+zNujNwk2rKJIKjo8bpqNr2w5Bl+k4pSdJ
XuYuBB5eMmso52MtJA8ewqSxQlEVpQ6sDLXHaDL7FtI9o3b5xikIvAejnu8fYb/a
BjgNe7HQRQ5E6u0krEnzygDgBYtNGlgmWTPRZ5cJhyAa9jQYPs53YSMKGcSmiTc+
cectedYSKNBjx3FM5ZLNWIcuQGAdJZROlmON+KRCrfQLyhcqpNgtnNMB1HgY36ZZ
mIi0Wzag8T1MBrlZzdCw9VPIMCctaGYZPp+Bv9oi53Cao/NuE56BZDxjkG1gjvk=
=sBkN
-----END PGP SIGNATURE-----

--------------enig9EB8CFEC348C0ED4C06E11A7--


--===============4097639027212238284==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4097639027212238284==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:42:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBWl-0000U7-EI; Wed, 08 Feb 2012 17:41:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvBWk-0000Tz-1U
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:41:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328722906!10709974!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5Njc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23069 invoked from network); 8 Feb 2012 17:41:47 -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; 8 Feb 2012 17:41:47 -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 q18HfYkJ029599
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 17:41:36 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
	q18HfXP3009624
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 8 Feb 2012 17:41:34 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
	q18HfXrF006029; Wed, 8 Feb 2012 11:41:33 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 09:41:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 92D1C402A9; Wed,  8 Feb 2012 12:38:45 -0500 (EST)
Date: Wed, 8 Feb 2012 12:38:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120208173845.GA6771@phenom.dumpdata.com>
References: <20110103114133.GI2754@reaktio.net>
	<1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
	<20120208065930.GT12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208065930.GT12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F32B3D1.002A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Nathanael Rensen <nathanael@polymorpheus.com>
Subject: Re: [Xen-devel] pvusb drivers for pvops 2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:59:30AM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> > Hi Pasi,
> > =

> =

> Hello,
> =

> (I added Konrad and xen-devel to CC list, hopefully that's ok..)
> =

> > It's been a very long time since we discussed PVUSB - I haven't given
> > up, just been caught up with other things.
> > =

> =

> Great! Really nice to hear from you again..
> =

> Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
> extracted the xen patches, and started preparing to re-port the driver to=
 pvops.
> So now I don't have to finish that :)
> =

> > I've updated the PVUSB patch, done some refactoring and cleaned up the
> > checkpatch warnings.
> > The patch is targetted at linux-next, but it also applies cleanly to
> > Konrad's linux-next branch:
> > =

> > http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.pat=
ch

Nice job (I took a brief look at it). I see you handled those m2p_override
nicely.
> > =

> > I haven't done a lot of testing, but it does work for my basic test
> > (USB TV-tuner). My next step is to get in contact with the USB
> > maintainer and see what further changes are required in order to get
> > this work upstreamed. In the meantime, the more testing and exposure
> > the patch gets the better.

OK. Well let me stick on my #testing branch which is a kitchensink of things
and play with a bit.

> > =

> =

> I'm sure we can get people testing this patch. Many people have been aski=
ng
> for USB passthru solution for Linux 3.x.
> =

> =

> > Thanks,
> > =

> =

> Thanks a lot!
> =

> =

> -- Pasi
> =

> > Nathanael
> > =

> > On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> > >>
> > >> > I also noticed the frontend driver was producing a warning when
> > >> > loading which is resolved by setting the module owner.
> > >> >
> > >> > I've placed an updated diff here:
> > >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > >> >
> > >>
> > >> Great, thanks.
> > >>
> > >
> > > Hello again,
> > >
> > > Nathanael: Did you have time to take a look at upstreaming xen pvusb =
drivers ?
> > >
> > > -- Pasi
> > >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:42:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBWl-0000U7-EI; Wed, 08 Feb 2012 17:41:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvBWk-0000Tz-1U
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:41:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328722906!10709974!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5Njc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23069 invoked from network); 8 Feb 2012 17:41:47 -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; 8 Feb 2012 17:41:47 -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 q18HfYkJ029599
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 17:41:36 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
	q18HfXP3009624
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 8 Feb 2012 17:41:34 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
	q18HfXrF006029; Wed, 8 Feb 2012 11:41:33 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 09:41:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 92D1C402A9; Wed,  8 Feb 2012 12:38:45 -0500 (EST)
Date: Wed, 8 Feb 2012 12:38:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120208173845.GA6771@phenom.dumpdata.com>
References: <20110103114133.GI2754@reaktio.net>
	<1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
	<20120208065930.GT12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208065930.GT12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F32B3D1.002A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Nathanael Rensen <nathanael@polymorpheus.com>
Subject: Re: [Xen-devel] pvusb drivers for pvops 2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:59:30AM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> > Hi Pasi,
> > =

> =

> Hello,
> =

> (I added Konrad and xen-devel to CC list, hopefully that's ok..)
> =

> > It's been a very long time since we discussed PVUSB - I haven't given
> > up, just been caught up with other things.
> > =

> =

> Great! Really nice to hear from you again..
> =

> Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
> extracted the xen patches, and started preparing to re-port the driver to=
 pvops.
> So now I don't have to finish that :)
> =

> > I've updated the PVUSB patch, done some refactoring and cleaned up the
> > checkpatch warnings.
> > The patch is targetted at linux-next, but it also applies cleanly to
> > Konrad's linux-next branch:
> > =

> > http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.pat=
ch

Nice job (I took a brief look at it). I see you handled those m2p_override
nicely.
> > =

> > I haven't done a lot of testing, but it does work for my basic test
> > (USB TV-tuner). My next step is to get in contact with the USB
> > maintainer and see what further changes are required in order to get
> > this work upstreamed. In the meantime, the more testing and exposure
> > the patch gets the better.

OK. Well let me stick on my #testing branch which is a kitchensink of things
and play with a bit.

> > =

> =

> I'm sure we can get people testing this patch. Many people have been aski=
ng
> for USB passthru solution for Linux 3.x.
> =

> =

> > Thanks,
> > =

> =

> Thanks a lot!
> =

> =

> -- Pasi
> =

> > Nathanael
> > =

> > On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> > >>
> > >> > I also noticed the frontend driver was producing a warning when
> > >> > loading which is resolved by setting the module owner.
> > >> >
> > >> > I've placed an updated diff here:
> > >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > >> >
> > >>
> > >> Great, thanks.
> > >>
> > >
> > > Hello again,
> > >
> > > Nathanael: Did you have time to take a look at upstreaming xen pvusb =
drivers ?
> > >
> > > -- Pasi
> > >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:44:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBZO-0000aB-17; Wed, 08 Feb 2012 17:44: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 1RvBZN-0000a6-85
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:44:37 +0000
Received: from [85.158.139.83:53664] by server-8.bemta-5.messagelabs.com id
	98/0E-08951-484B23F4; Wed, 08 Feb 2012 17:44:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328723074!6922920!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5Njc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17206 invoked from network); 8 Feb 2012 17:44:35 -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; 8 Feb 2012 17:44:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q18Hhnis031782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 17:43: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
	q18HhmIH013318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 8 Feb 2012 17:43:48 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
	q18Hhl06032315; Wed, 8 Feb 2012 11:43:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 09:43:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C33B3402A9; Wed,  8 Feb 2012 12:40:59 -0500 (EST)
Date: Wed, 8 Feb 2012 12:40:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>,
	james.harper@bendigoit.com.au
Message-ID: <20120208174059.GB6771@phenom.dumpdata.com>
References: <20110103114133.GI2754@reaktio.net>
	<1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
	<20120208065930.GT12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208065930.GT12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090207.4F32B457.0084,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Nathanael Rensen <nathanael@polymorpheus.com>
Subject: Re: [Xen-devel] pvusb drivers for pvops 2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:59:30AM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> > Hi Pasi,
> > =

> =

> Hello,
> =

> (I added Konrad and xen-devel to CC list, hopefully that's ok..)

And let me add James Harper here since he was doing some testing with
the Windows GPL PV USB driver as well


> =

> > It's been a very long time since we discussed PVUSB - I haven't given
> > up, just been caught up with other things.
> > =

> =

> Great! Really nice to hear from you again..
> =

> Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
> extracted the xen patches, and started preparing to re-port the driver to=
 pvops.
> So now I don't have to finish that :)
> =

> > I've updated the PVUSB patch, done some refactoring and cleaned up the
> > checkpatch warnings.
> > The patch is targetted at linux-next, but it also applies cleanly to
> > Konrad's linux-next branch:
> > =

> > http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.pat=
ch
> > =

> > I haven't done a lot of testing, but it does work for my basic test
> > (USB TV-tuner). My next step is to get in contact with the USB
> > maintainer and see what further changes are required in order to get
> > this work upstreamed. In the meantime, the more testing and exposure
> > the patch gets the better.
> > =

> =

> I'm sure we can get people testing this patch. Many people have been aski=
ng
> for USB passthru solution for Linux 3.x.
> =

> =

> > Thanks,
> > =

> =

> Thanks a lot!
> =

> =

> -- Pasi
> =

> > Nathanael
> > =

> > On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> > >>
> > >> > I also noticed the frontend driver was producing a warning when
> > >> > loading which is resolved by setting the module owner.
> > >> >
> > >> > I've placed an updated diff here:
> > >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > >> >
> > >>
> > >> Great, thanks.
> > >>
> > >
> > > Hello again,
> > >
> > > Nathanael: Did you have time to take a look at upstreaming xen pvusb =
drivers ?
> > >
> > > -- Pasi
> > >
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:44:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBZO-0000aB-17; Wed, 08 Feb 2012 17:44: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 1RvBZN-0000a6-85
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:44:37 +0000
Received: from [85.158.139.83:53664] by server-8.bemta-5.messagelabs.com id
	98/0E-08951-484B23F4; Wed, 08 Feb 2012 17:44:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328723074!6922920!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5Njc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17206 invoked from network); 8 Feb 2012 17:44:35 -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; 8 Feb 2012 17:44:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q18Hhnis031782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 8 Feb 2012 17:43: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
	q18HhmIH013318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 8 Feb 2012 17:43:48 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
	q18Hhl06032315; Wed, 8 Feb 2012 11:43:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 09:43:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C33B3402A9; Wed,  8 Feb 2012 12:40:59 -0500 (EST)
Date: Wed, 8 Feb 2012 12:40:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>,
	james.harper@bendigoit.com.au
Message-ID: <20120208174059.GB6771@phenom.dumpdata.com>
References: <20110103114133.GI2754@reaktio.net>
	<1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
	<20120208065930.GT12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208065930.GT12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090207.4F32B457.0084,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Nathanael Rensen <nathanael@polymorpheus.com>
Subject: Re: [Xen-devel] pvusb drivers for pvops 2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:59:30AM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> > Hi Pasi,
> > =

> =

> Hello,
> =

> (I added Konrad and xen-devel to CC list, hopefully that's ok..)

And let me add James Harper here since he was doing some testing with
the Windows GPL PV USB driver as well


> =

> > It's been a very long time since we discussed PVUSB - I haven't given
> > up, just been caught up with other things.
> > =

> =

> Great! Really nice to hear from you again..
> =

> Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
> extracted the xen patches, and started preparing to re-port the driver to=
 pvops.
> So now I don't have to finish that :)
> =

> > I've updated the PVUSB patch, done some refactoring and cleaned up the
> > checkpatch warnings.
> > The patch is targetted at linux-next, but it also applies cleanly to
> > Konrad's linux-next branch:
> > =

> > http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.pat=
ch
> > =

> > I haven't done a lot of testing, but it does work for my basic test
> > (USB TV-tuner). My next step is to get in contact with the USB
> > maintainer and see what further changes are required in order to get
> > this work upstreamed. In the meantime, the more testing and exposure
> > the patch gets the better.
> > =

> =

> I'm sure we can get people testing this patch. Many people have been aski=
ng
> for USB passthru solution for Linux 3.x.
> =

> =

> > Thanks,
> > =

> =

> Thanks a lot!
> =

> =

> -- Pasi
> =

> > Nathanael
> > =

> > On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> > >>
> > >> > I also noticed the frontend driver was producing a warning when
> > >> > loading which is resolved by setting the module owner.
> > >> >
> > >> > I've placed an updated diff here:
> > >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > >> >
> > >>
> > >> Great, thanks.
> > >>
> > >
> > > Hello again,
> > >
> > > Nathanael: Did you have time to take a look at upstreaming xen pvusb =
drivers ?
> > >
> > > -- Pasi
> > >
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:49:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBdt-0000qh-Vy; Wed, 08 Feb 2012 17:49:17 +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 1RvBds-0000qb-4b
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:49:16 +0000
Received: from [85.158.139.83:12905] by server-4.bemta-5.messagelabs.com id
	B2/FA-28576-B95B23F4; Wed, 08 Feb 2012 17:49:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328723354!13413411!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11154 invoked from network); 8 Feb 2012 17:49:14 -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; 8 Feb 2012 17:49: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 188B02250;
	Wed,  8 Feb 2012 19:49:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B88BD20056; Wed,  8 Feb 2012 19:49:12 +0200 (EET)
Date: Wed, 8 Feb 2012 19:49:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: mailinglist@modernbiztonsag.org
Message-ID: <20120208174912.GX12984@reaktio.net>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 04:59:18PM +0100, mailinglist@modernbiztonsag.org wrote:
> Dear List,
> 

Hello,

> i'm experimenting with remus with the following setup.
> 
> dom0:
> - Debian Squeeze
> - Jeremy's 2.6.38.48 kernel
> - xen 4.1.2 recompiled from sid
> - DRBD for block device backend
> 

Did you try xen-unstable? There are many Remus related fixes/enhancements in xen-unstable.

-- Pasi


> domU
> - Debian Squeeze
> 
> Remus is working fine unless i try to give more than 1 core to the domU.
> 
> Here's the error from remus when i'm trying to enable it for an SMP domU:
> 
> Traceback (most recent call last):
>   File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
>     run(cfg)
>   File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
>     dom = vm.VM(cfg.domid)
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in __init__
>     self.loaddominfo()
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in loaddominfo
>     self.dom = parsedominfo(self.dominfo)
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
> parsedominfo
>     return s2d(dominfo[1:])
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
>     val = s2d(elem[1:])
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
>     return s2d(elem)
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
>     for k, v in val.iteritems():
> AttributeError: 'int' object has no attribute 'iteritems'
> 
> I've attached the domU configuration file.
> 
> Please let me know if you need more info on this.
> 
> Best regards,
> Mate

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:49:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBdt-0000qh-Vy; Wed, 08 Feb 2012 17:49:17 +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 1RvBds-0000qb-4b
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:49:16 +0000
Received: from [85.158.139.83:12905] by server-4.bemta-5.messagelabs.com id
	B2/FA-28576-B95B23F4; Wed, 08 Feb 2012 17:49:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328723354!13413411!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11154 invoked from network); 8 Feb 2012 17:49:14 -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; 8 Feb 2012 17:49: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 188B02250;
	Wed,  8 Feb 2012 19:49:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B88BD20056; Wed,  8 Feb 2012 19:49:12 +0200 (EET)
Date: Wed, 8 Feb 2012 19:49:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: mailinglist@modernbiztonsag.org
Message-ID: <20120208174912.GX12984@reaktio.net>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 04:59:18PM +0100, mailinglist@modernbiztonsag.org wrote:
> Dear List,
> 

Hello,

> i'm experimenting with remus with the following setup.
> 
> dom0:
> - Debian Squeeze
> - Jeremy's 2.6.38.48 kernel
> - xen 4.1.2 recompiled from sid
> - DRBD for block device backend
> 

Did you try xen-unstable? There are many Remus related fixes/enhancements in xen-unstable.

-- Pasi


> domU
> - Debian Squeeze
> 
> Remus is working fine unless i try to give more than 1 core to the domU.
> 
> Here's the error from remus when i'm trying to enable it for an SMP domU:
> 
> Traceback (most recent call last):
>   File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
>     run(cfg)
>   File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
>     dom = vm.VM(cfg.domid)
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in __init__
>     self.loaddominfo()
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in loaddominfo
>     self.dom = parsedominfo(self.dominfo)
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
> parsedominfo
>     return s2d(dominfo[1:])
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
>     val = s2d(elem[1:])
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
>     return s2d(elem)
>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
>     for k, v in val.iteritems():
> AttributeError: 'int' object has no attribute 'iteritems'
> 
> I've attached the domU configuration file.
> 
> Please let me know if you need more info on this.
> 
> Best regards,
> Mate

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:54:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBiw-00010d-Rg; Wed, 08 Feb 2012 17:54:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1RvBiw-00010T-1G
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:54:30 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328723660!15868274!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7487 invoked from network); 8 Feb 2012 17:54:22 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:54:22 -0000
Received: by obcuy19 with SMTP id uy19so3440871obc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 09:54:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=nUFy9XJvZN6qaP9f+P3xgUvH984rnr4Ao9y4NQH2aRo=;
	b=Cp0yKmXjLQSjmbODqcikia15io+xwdUO+3yQupxBtBgWj2xmY++WVSwRgkNBs3Fwgl
	X0DVsZRlTEVJpyYwIvlxkDBPp9Th7UPbhMVrBZV4jVwA+sTIojzmQtvWBmHEK99R/3Cg
	+Q89Lc9D4TeILhxpKBS9eLLfn6xYA1umARgyw=
Received: by 10.182.216.101 with SMTP id op5mr26500501obc.54.1328723659466;
	Wed, 08 Feb 2012 09:54:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.4.231 with HTTP; Wed, 8 Feb 2012 09:53:59 -0800 (PST)
In-Reply-To: <1328721983.6133.86.camel@zakaz.uk.xensource.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
	<1328707739.6133.16.camel@zakaz.uk.xensource.com>
	<CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
	<1328721983.6133.86.camel@zakaz.uk.xensource.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 17:53:59 +0000
X-Google-Sender-Auth: 5k0iUbDUdHkTZyIi72DcAHm-zMc
Message-ID: <CAKZ=5EWq+hoWU98kOV0748o9XK=TJgtMFWns+TeX3qeCPAfbUw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgOCwgMjAxMiBhdCA1OjI2IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPiB3cm90ZToKPiBPbiBXZWQsIDIwMTItMDItMDggYXQgMTQ6NTMgKzAwMDAs
IEp1bGlhbiBQaWRhbmNldCB3cm90ZToKPj4gT24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxOjI4IFBN
LCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPj4gPiBPbiBT
dW4sIDIwMTItMDItMDUgYXQgMTY6MTggKzAwMDAsIEp1bGlhbiBQaWRhbmNldCB3cm90ZToKPj4g
Pj4gV2hlbiBib290aW5nIEhWTXMgd2l0aCBTZWFCSU9TLCB0aGUgQklPUyBpdHNlbGYgdGFrZXMg
Y2FyZSBvZiBleHRyYWN0aW5nCj4+ID4+IG9wdGlvbiBST01zIGZyb20gdGhlIFBDSSBkZXZpY2Vz
LiBUaGVzZSBST01zIGFyZSB1c3VhbGx5IHByb3ZpZGVkIHdpdGggYnkKPj4gPj4gdGhlIGRldmlj
ZSBtb2RlbCAocWVtdSkuCj4+ID4+IFRodXMsIGh2bWxvYWRlciBzaG91bGQgbm90IHJlcXVpcmUg
YW55IGxvbmdlciB0aGUgcm9tYmlvcywgc3RkdmdhLAo+PiA+PiBjaXJydXN2Z2Egb3IgZXRoZXJi
b290IFJPTXMgdG8gYmUgcHJlc2VudC4KPj4gPj4KPj4gPj4gQWxzbywgdGhlIDMyYml0Ymlvc19z
dXBwb3J0LmMgZmlsZSBpcyBzcGVjaWZpYyB0byByb21iaW9zIGFuZCBzaG91bGQgbm90Cj4+ID4+
IGJlIGJ1aWx0IHdoZW4gYnVpbGRpbmcgaHZtbG9hZGVyIHdpdGggc2VhYmlvcy4KPj4gPgo+PiA+
PiBbLi4uXQo+PiA+PiBAQCAtNDc1LDE2ICs0NzcsMjAgQEAgaW50IG1haW4odm9pZCkKPj4gPj4g
wqAgwqAgwqAgwqAgc3dpdGNoICggdmlydHVhbF92Z2EgKQo+PiA+PiDCoCDCoCDCoCDCoCDCoHsK
Pj4gPj4gwqAgwqAgwqAgwqAgwqBjYXNlIFZHQV9jaXJydXM6Cj4+ID4+ICsjaWZkZWYgRU5BQkxF
X0NJUlJVU1ZHQQo+PiA+Cj4+ID4gSnVzdCBvdXRzaWRlIHRoZSBjb250ZXh0IGhlcmUgaXMgYW4g
ImlmICggYmlvcy0+bG9hZF9yb21zICkiIHdoaWNoCj4+ID4gcHJldmVudHMgdGhlIFJPTXMgZnJv
bSBiZWluZyBsb2FkZWQgaWYgd2UgYXJlIHVzaW5nIFNlYUJJT1MgLS0gaXMgdGhhdAo+PiA+IG5v
dCBzdWZmaWNpZW50IGZvciB5b3VyIG5lZWRzPwo+PiA+Cj4+ID4gQ3VycmVudGx5IGh2bWxvYWRl
ciBidWlsZHMgd2l0aCBzdXBwb3J0IGZvciBib3RoIFJPTUJJT1MgYW5kIFNlYUJJT1MgYW5kCj4+
ID4gc2VsZWN0cyB0aGUgb25lIHRvIHVzZSBiYXNlZCBvbiBhIGNvbmZpZ3VyYXRpb24ga2V5IGlu
IHhlbnN0b3JlIChwdXNoZWQKPj4gPiBkb3duIGJ5IHRoZSB0b29sc3RhY2sgZGVwZW5kaW5nIG9u
IHdoaWNoIHFlbXUgeW91IGFyZSBydW5uaW5nKS4gSGF2ZSB5b3UKPj4gPiBtb2RpZmllZCBzb21l
dGhpbmcgZWxzZXdoZXJlIGluIG9yZGVyIHRvIGJ1aWxkIGEgU2VhQklPUy1vbmx5IGh2bWxvYWRl
cj8KPj4gPgo+PiA+IFBlcmhhcHMgaXQgd291bGQgbWFrZSBzZW5zZSBmb3IgdGhlIFJPTXMgdG8g
YmUga2V5ZWQgb2ZmIHdoZXRoZXIgb3Igbm90Cj4+ID4gUk9NQklPUyBpcyBlbmFibGVkIHJhdGhl
ciB0aGFuIGVhY2gga2V5aW5nIG9mZiB0aGVpciBvd24gRElSIHZhcj8KPj4gPgo+PiA+IFlvdSBz
ZWVtIHRvIGhhdmUgbWl4ZWQgc29tZSBvdGhlciBjaGFuZ2VzLCBzcGVjaWZpY2FsbHkgcy86PS8/
PS8gaW4gYQo+PiA+IGZldyBwbGFjZXMgYW5kIGFsc28gc29tZSBzb3J0IG9mIGNoYW5nZSB3cnQg
aG93IGViLXJvbXMuaCBpcyBnZW5lcmF0ZWQKPj4gPiAoaW5jbHVkaW5nIGRyb3BwaW5nIHRoZSA4
MDg2MTAwZSBST00gZnJvbSB0aGUgaW1hZ2UsIHdoaWNoIG11c3QgYmUKPj4gPiBkaXNjdXNzZWQp
Lgo+PiA+Cj4+ID4gVGhlc2Ugb3RoZXIgY2hhbmdlcyBzaG91bGQgYmUgc3VibWl0dGVkIGFuZCBy
YXRpb25hbGlzZWQgc2VwYXJhdGVseS4KPj4gPgo+Pgo+PiBUaGUgcHVycG9zZSBvZiB0aGlzIGNo
YW5nZSB3YXMgaW5pdGlhbGx5IHRvIGFsbG93IHRoZSB1c2VyIHRvIGJ1aWxkCj4+IGh2bWxvYWRl
ciB3aXRoIFNlYUJJT1Mgb25seSB3aXRob3V0IGhhdmluZyB0byBkZXBlbmQgb24gcm9tYmlvcywK
Pj4gdmdhYmlvcyBvciBpcHhlLiBJJ3ZlIG9ubHkgdGVzdGVkIG15IGNoYW5nZXMgYnkgY2FsbGlu
ZyBtYWtlIGZyb20gdGhlCj4+IGh2bWxvYWRlci8gZGlyZWN0b3J5IGRpcmVjdGx5LiBUaGUgWGVu
IGJ1aWxkIHN5c3RlbSBjb3VsZCBhbHNvIG5vdAo+PiBoYXZlIHRvIGRlcGVuZCBvbiBiY2MgZm9y
IGV4YW1wbGUuCj4+Cj4+IEluIGFkZGl0aW9uIHRvIHRoZSBwYXRjaCBJIHN1Ym1pdHRlZCwgSSBz
dXBwb3NlIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8KPj4gaW50cm9kdWNlIGEgZ2xvYmFsIGNvbmZp
Z3VyYXRpb24gb3B0aW9uIGZvciB0aGUgTWFrZWZpbGUgaW4gdGhlCj4+IGZpcm13YXJlLyBkaXJl
Y3RvcnkgdG8gZGVjaWRlIHdldGhlciBpdCBzaG91bGQgcmVjdXJzZSBpbiB0aGUgcm9tYmlvcywK
Pj4gdmdhYmlvcywgYW5kIGV0aGVyYm9vdCBkaXJlY3Rvcmllcy4KPj4KPj4gSSBjaGFuZ2VkIHNv
bWUgdmFyaWFibGUgYXNzaWduYXRpb25zIDo9IGJ5ID89IGJlY2F1c2UgSSB3YW50ZWQgdGhlCj4+
IHVzZXIgb2YgdGhlIGJ1aWxkIHN5c3RlbSB0byBiZSBhYmxlIHRvIHNwZWNpZnkgYSBjdXN0b20g
YnVpbGQKPj4gZGlyZWN0b3J5IGZvciB0aGVzZSBST01zLgo+Cj4gU2VlbXMgZmFpciBlbm91Z2gs
IGFsdGhvdWdoIEkgd291bGQgc3RpbGwgbGlrZSB0byBzZWUgc2VwYXJhdGUgaXNzdWVzCj4gc29s
dmVkIGluIHNlcGFyYXRlIHBhdGNoZXMuCj4KPj4gU2FtZSB0aGluZyBmb3IgdGhlIGV0aGVyYm9v
dCBST00sIEkgbWFkZSB0aGUgTWFrZWZpbGUgbm90IHVzZSBlYi1yb20uaAo+PiBhbmQgcmVwbGFj
ZSBpdCB3aXRoIGEgY2FsbCB0byBta2hleCBvbiB0aGUgYmluYXJ5IGZpbGUgZGlyZWN0bHksIHNv
Cj4+IHRoZSB1c2VyIGNhbiBjaG9vc2Ugd2hpY2ggUk9NIHRvIGluamVjdCBpbnRvIGh2bWxvYWRl
ciwgYW5kIEkgZm91bmQgaXQKPj4gdG8gYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qg
b2YgdGhlIE1ha2VmaWxlLgo+Cj4gSSBkb24ndCB0aGluayB5b3UgaGF2ZSByZXBsYWNlZCBsaWtl
IHdpdGggbGlrZS4gU3BlY2lmaWNhbGx5IHlvdSBzZWVtIHRvCj4gaGF2ZSBvbWl0dGVkIHRoZSA4
MDg2MTAwZSBST00gLS0gbG9vayBob3cgZWItcm9tcy5oIGlzIGJ1aWx0IGluCj4gdG9vbHMvZmly
bXdhcmUvZXRoZXJib290IHVzaW5nIE5JQ1MgPSBydGw4MTM5IDgwODYxMDBlIGZyb20gdGhlIGZp
bGUKPiAiQ29uZmlnIiBjb21wYXJlZCB3aXRoIHlvdXIgY29kZSB3aGljaCBvbmx5IHVzZXMgRVRI
RVJCT09UX05JQyA6PQo+IHJ0bDgxMzkuCj4KCllvdSBhcmUgcmlnaHQsIEkgd3JvbmdseSBhc3N1
bWVkIHRoYXQgZWItcm9tcy5oIG9ubHkgY29udGFpbmVkIG9uZSBST00uCgotLSAKSnVsaWFuCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:54:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17: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.xensource.com>)
	id 1RvBiw-00010d-Rg; Wed, 08 Feb 2012 17:54:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1RvBiw-00010T-1G
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:54:30 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328723660!15868274!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7487 invoked from network); 8 Feb 2012 17:54:22 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 17:54:22 -0000
Received: by obcuy19 with SMTP id uy19so3440871obc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 09:54:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=nUFy9XJvZN6qaP9f+P3xgUvH984rnr4Ao9y4NQH2aRo=;
	b=Cp0yKmXjLQSjmbODqcikia15io+xwdUO+3yQupxBtBgWj2xmY++WVSwRgkNBs3Fwgl
	X0DVsZRlTEVJpyYwIvlxkDBPp9Th7UPbhMVrBZV4jVwA+sTIojzmQtvWBmHEK99R/3Cg
	+Q89Lc9D4TeILhxpKBS9eLLfn6xYA1umARgyw=
Received: by 10.182.216.101 with SMTP id op5mr26500501obc.54.1328723659466;
	Wed, 08 Feb 2012 09:54:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.4.231 with HTTP; Wed, 8 Feb 2012 09:53:59 -0800 (PST)
In-Reply-To: <1328721983.6133.86.camel@zakaz.uk.xensource.com>
References: <e7b2b593a253a8c2d9cc20adad9919ae1b9c65e6.1328458624.git.julian.pidancet@gmail.com>
	<1328707739.6133.16.camel@zakaz.uk.xensource.com>
	<CAKZ=5EVhMPu=1g9yWeV0zOLYRZnxj=k+ftdvsCdBMdyFQ_BiJg@mail.gmail.com>
	<1328721983.6133.86.camel@zakaz.uk.xensource.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 8 Feb 2012 17:53:59 +0000
X-Google-Sender-Auth: 5k0iUbDUdHkTZyIi72DcAHm-zMc
Message-ID: <CAKZ=5EWq+hoWU98kOV0748o9XK=TJgtMFWns+TeX3qeCPAfbUw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] hvmloader: Make ROM dependencies
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgOCwgMjAxMiBhdCA1OjI2IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVs
bEBjaXRyaXguY29tPiB3cm90ZToKPiBPbiBXZWQsIDIwMTItMDItMDggYXQgMTQ6NTMgKzAwMDAs
IEp1bGlhbiBQaWRhbmNldCB3cm90ZToKPj4gT24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxOjI4IFBN
LCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPj4gPiBPbiBT
dW4sIDIwMTItMDItMDUgYXQgMTY6MTggKzAwMDAsIEp1bGlhbiBQaWRhbmNldCB3cm90ZToKPj4g
Pj4gV2hlbiBib290aW5nIEhWTXMgd2l0aCBTZWFCSU9TLCB0aGUgQklPUyBpdHNlbGYgdGFrZXMg
Y2FyZSBvZiBleHRyYWN0aW5nCj4+ID4+IG9wdGlvbiBST01zIGZyb20gdGhlIFBDSSBkZXZpY2Vz
LiBUaGVzZSBST01zIGFyZSB1c3VhbGx5IHByb3ZpZGVkIHdpdGggYnkKPj4gPj4gdGhlIGRldmlj
ZSBtb2RlbCAocWVtdSkuCj4+ID4+IFRodXMsIGh2bWxvYWRlciBzaG91bGQgbm90IHJlcXVpcmUg
YW55IGxvbmdlciB0aGUgcm9tYmlvcywgc3RkdmdhLAo+PiA+PiBjaXJydXN2Z2Egb3IgZXRoZXJi
b290IFJPTXMgdG8gYmUgcHJlc2VudC4KPj4gPj4KPj4gPj4gQWxzbywgdGhlIDMyYml0Ymlvc19z
dXBwb3J0LmMgZmlsZSBpcyBzcGVjaWZpYyB0byByb21iaW9zIGFuZCBzaG91bGQgbm90Cj4+ID4+
IGJlIGJ1aWx0IHdoZW4gYnVpbGRpbmcgaHZtbG9hZGVyIHdpdGggc2VhYmlvcy4KPj4gPgo+PiA+
PiBbLi4uXQo+PiA+PiBAQCAtNDc1LDE2ICs0NzcsMjAgQEAgaW50IG1haW4odm9pZCkKPj4gPj4g
wqAgwqAgwqAgwqAgc3dpdGNoICggdmlydHVhbF92Z2EgKQo+PiA+PiDCoCDCoCDCoCDCoCDCoHsK
Pj4gPj4gwqAgwqAgwqAgwqAgwqBjYXNlIFZHQV9jaXJydXM6Cj4+ID4+ICsjaWZkZWYgRU5BQkxF
X0NJUlJVU1ZHQQo+PiA+Cj4+ID4gSnVzdCBvdXRzaWRlIHRoZSBjb250ZXh0IGhlcmUgaXMgYW4g
ImlmICggYmlvcy0+bG9hZF9yb21zICkiIHdoaWNoCj4+ID4gcHJldmVudHMgdGhlIFJPTXMgZnJv
bSBiZWluZyBsb2FkZWQgaWYgd2UgYXJlIHVzaW5nIFNlYUJJT1MgLS0gaXMgdGhhdAo+PiA+IG5v
dCBzdWZmaWNpZW50IGZvciB5b3VyIG5lZWRzPwo+PiA+Cj4+ID4gQ3VycmVudGx5IGh2bWxvYWRl
ciBidWlsZHMgd2l0aCBzdXBwb3J0IGZvciBib3RoIFJPTUJJT1MgYW5kIFNlYUJJT1MgYW5kCj4+
ID4gc2VsZWN0cyB0aGUgb25lIHRvIHVzZSBiYXNlZCBvbiBhIGNvbmZpZ3VyYXRpb24ga2V5IGlu
IHhlbnN0b3JlIChwdXNoZWQKPj4gPiBkb3duIGJ5IHRoZSB0b29sc3RhY2sgZGVwZW5kaW5nIG9u
IHdoaWNoIHFlbXUgeW91IGFyZSBydW5uaW5nKS4gSGF2ZSB5b3UKPj4gPiBtb2RpZmllZCBzb21l
dGhpbmcgZWxzZXdoZXJlIGluIG9yZGVyIHRvIGJ1aWxkIGEgU2VhQklPUy1vbmx5IGh2bWxvYWRl
cj8KPj4gPgo+PiA+IFBlcmhhcHMgaXQgd291bGQgbWFrZSBzZW5zZSBmb3IgdGhlIFJPTXMgdG8g
YmUga2V5ZWQgb2ZmIHdoZXRoZXIgb3Igbm90Cj4+ID4gUk9NQklPUyBpcyBlbmFibGVkIHJhdGhl
ciB0aGFuIGVhY2gga2V5aW5nIG9mZiB0aGVpciBvd24gRElSIHZhcj8KPj4gPgo+PiA+IFlvdSBz
ZWVtIHRvIGhhdmUgbWl4ZWQgc29tZSBvdGhlciBjaGFuZ2VzLCBzcGVjaWZpY2FsbHkgcy86PS8/
PS8gaW4gYQo+PiA+IGZldyBwbGFjZXMgYW5kIGFsc28gc29tZSBzb3J0IG9mIGNoYW5nZSB3cnQg
aG93IGViLXJvbXMuaCBpcyBnZW5lcmF0ZWQKPj4gPiAoaW5jbHVkaW5nIGRyb3BwaW5nIHRoZSA4
MDg2MTAwZSBST00gZnJvbSB0aGUgaW1hZ2UsIHdoaWNoIG11c3QgYmUKPj4gPiBkaXNjdXNzZWQp
Lgo+PiA+Cj4+ID4gVGhlc2Ugb3RoZXIgY2hhbmdlcyBzaG91bGQgYmUgc3VibWl0dGVkIGFuZCBy
YXRpb25hbGlzZWQgc2VwYXJhdGVseS4KPj4gPgo+Pgo+PiBUaGUgcHVycG9zZSBvZiB0aGlzIGNo
YW5nZSB3YXMgaW5pdGlhbGx5IHRvIGFsbG93IHRoZSB1c2VyIHRvIGJ1aWxkCj4+IGh2bWxvYWRl
ciB3aXRoIFNlYUJJT1Mgb25seSB3aXRob3V0IGhhdmluZyB0byBkZXBlbmQgb24gcm9tYmlvcywK
Pj4gdmdhYmlvcyBvciBpcHhlLiBJJ3ZlIG9ubHkgdGVzdGVkIG15IGNoYW5nZXMgYnkgY2FsbGlu
ZyBtYWtlIGZyb20gdGhlCj4+IGh2bWxvYWRlci8gZGlyZWN0b3J5IGRpcmVjdGx5LiBUaGUgWGVu
IGJ1aWxkIHN5c3RlbSBjb3VsZCBhbHNvIG5vdAo+PiBoYXZlIHRvIGRlcGVuZCBvbiBiY2MgZm9y
IGV4YW1wbGUuCj4+Cj4+IEluIGFkZGl0aW9uIHRvIHRoZSBwYXRjaCBJIHN1Ym1pdHRlZCwgSSBz
dXBwb3NlIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8KPj4gaW50cm9kdWNlIGEgZ2xvYmFsIGNvbmZp
Z3VyYXRpb24gb3B0aW9uIGZvciB0aGUgTWFrZWZpbGUgaW4gdGhlCj4+IGZpcm13YXJlLyBkaXJl
Y3RvcnkgdG8gZGVjaWRlIHdldGhlciBpdCBzaG91bGQgcmVjdXJzZSBpbiB0aGUgcm9tYmlvcywK
Pj4gdmdhYmlvcywgYW5kIGV0aGVyYm9vdCBkaXJlY3Rvcmllcy4KPj4KPj4gSSBjaGFuZ2VkIHNv
bWUgdmFyaWFibGUgYXNzaWduYXRpb25zIDo9IGJ5ID89IGJlY2F1c2UgSSB3YW50ZWQgdGhlCj4+
IHVzZXIgb2YgdGhlIGJ1aWxkIHN5c3RlbSB0byBiZSBhYmxlIHRvIHNwZWNpZnkgYSBjdXN0b20g
YnVpbGQKPj4gZGlyZWN0b3J5IGZvciB0aGVzZSBST01zLgo+Cj4gU2VlbXMgZmFpciBlbm91Z2gs
IGFsdGhvdWdoIEkgd291bGQgc3RpbGwgbGlrZSB0byBzZWUgc2VwYXJhdGUgaXNzdWVzCj4gc29s
dmVkIGluIHNlcGFyYXRlIHBhdGNoZXMuCj4KPj4gU2FtZSB0aGluZyBmb3IgdGhlIGV0aGVyYm9v
dCBST00sIEkgbWFkZSB0aGUgTWFrZWZpbGUgbm90IHVzZSBlYi1yb20uaAo+PiBhbmQgcmVwbGFj
ZSBpdCB3aXRoIGEgY2FsbCB0byBta2hleCBvbiB0aGUgYmluYXJ5IGZpbGUgZGlyZWN0bHksIHNv
Cj4+IHRoZSB1c2VyIGNhbiBjaG9vc2Ugd2hpY2ggUk9NIHRvIGluamVjdCBpbnRvIGh2bWxvYWRl
ciwgYW5kIEkgZm91bmQgaXQKPj4gdG8gYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHJlc3Qg
b2YgdGhlIE1ha2VmaWxlLgo+Cj4gSSBkb24ndCB0aGluayB5b3UgaGF2ZSByZXBsYWNlZCBsaWtl
IHdpdGggbGlrZS4gU3BlY2lmaWNhbGx5IHlvdSBzZWVtIHRvCj4gaGF2ZSBvbWl0dGVkIHRoZSA4
MDg2MTAwZSBST00gLS0gbG9vayBob3cgZWItcm9tcy5oIGlzIGJ1aWx0IGluCj4gdG9vbHMvZmly
bXdhcmUvZXRoZXJib290IHVzaW5nIE5JQ1MgPSBydGw4MTM5IDgwODYxMDBlIGZyb20gdGhlIGZp
bGUKPiAiQ29uZmlnIiBjb21wYXJlZCB3aXRoIHlvdXIgY29kZSB3aGljaCBvbmx5IHVzZXMgRVRI
RVJCT09UX05JQyA6PQo+IHJ0bDgxMzkuCj4KCllvdSBhcmUgcmlnaHQsIEkgd3JvbmdseSBhc3N1
bWVkIHRoYXQgZWItcm9tcy5oIG9ubHkgY29udGFpbmVkIG9uZSBST00uCgotLSAKSnVsaWFuCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:57:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBlG-00016q-DF; Wed, 08 Feb 2012 17:56:54 +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 1RvBlF-00016b-F9
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:56:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328723769!51645226!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23574 invoked from network); 8 Feb 2012 17:56:09 -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; 8 Feb 2012 17:56:09 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 954861A4D;
	Wed,  8 Feb 2012 19:56:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5E2E820056; Wed,  8 Feb 2012 19:56:46 +0200 (EET)
Date: Wed, 8 Feb 2012 19:56:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120208175646.GY12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > Hi,
> > 
> > I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> > 
> > I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> > one would be the best solution for Xen.
> > 
> > API remoting (gallium3D) (ex. Xen3D project)
> > Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> > 
> > Can you guys give me your idea on the matter?
> > Please also mention any existing projects you know that are related to this problem.
> 
> My personal opinion is that the simplest thing to do is OpenGL
> remoting. Gallium remoting could also be OK but considering that many
> cards don't have Gallium drivers we would probably end up doing two
> conversions instead of one (DirectX->Gallium in the guest,
> Gallium->OpenGL in dom0).
> Mediated passthrough is very card specific so I am afraid you would end
> up writing virtualization specific drivers for all the cards you want to
> support. Not to mention that you might need to access some videocard
> interfaces that on Nvidia are not discosed.
> 
> I believe that virtualbox already supports OpenGL remoting in a decent
> way, so I would start from there, port what they have to Xen, and
> improve it.
> 

I wonder if SPICE already supports OpenGL stuff..
I think it's at least supposed to be able to support OpenGL.

(http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 17:57:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 17:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBlG-00016q-DF; Wed, 08 Feb 2012 17:56:54 +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 1RvBlF-00016b-F9
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 17:56:53 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328723769!51645226!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23574 invoked from network); 8 Feb 2012 17:56:09 -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; 8 Feb 2012 17:56:09 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 954861A4D;
	Wed,  8 Feb 2012 19:56:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5E2E820056; Wed,  8 Feb 2012 19:56:46 +0200 (EET)
Date: Wed, 8 Feb 2012 19:56:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120208175646.GY12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > Hi,
> > 
> > I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> > 
> > I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> > one would be the best solution for Xen.
> > 
> > API remoting (gallium3D) (ex. Xen3D project)
> > Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> > 
> > Can you guys give me your idea on the matter?
> > Please also mention any existing projects you know that are related to this problem.
> 
> My personal opinion is that the simplest thing to do is OpenGL
> remoting. Gallium remoting could also be OK but considering that many
> cards don't have Gallium drivers we would probably end up doing two
> conversions instead of one (DirectX->Gallium in the guest,
> Gallium->OpenGL in dom0).
> Mediated passthrough is very card specific so I am afraid you would end
> up writing virtualization specific drivers for all the cards you want to
> support. Not to mention that you might need to access some videocard
> interfaces that on Nvidia are not discosed.
> 
> I believe that virtualbox already supports OpenGL remoting in a decent
> way, so I would start from there, port what they have to Xen, and
> improve it.
> 

I wonder if SPICE already supports OpenGL stuff..
I think it's at least supposed to be able to support OpenGL.

(http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:01:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:01:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBpP-0001RU-4V; Wed, 08 Feb 2012 18:01:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RvBpN-0001RL-4c
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:01:09 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328724062!8390589!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12793 invoked from network); 8 Feb 2012 18:01:03 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 18:01:03 -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 624FC1AFC;
	Wed,  8 Feb 2012 20:01:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C64C220056; Wed,  8 Feb 2012 20:01:00 +0200 (EET)
Date: Wed, 8 Feb 2012 20:01:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120208180100.GZ12984@reaktio.net>
References: <1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
	<20120208065930.GT12984@reaktio.net>
	<20120208174059.GB6771@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208174059.GB6771@phenom.dumpdata.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: james.harper@bendigoit.com.au, xen-devel@lists.xensource.com,
	Nathanael Rensen <nathanael@polymorpheus.com>
Subject: Re: [Xen-devel] Xen pvusb drivers for upstream Linux 3.x kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:40:59PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 08, 2012 at 08:59:30AM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> > > Hi Pasi,
> > > =

> > =

> > Hello,
> > =

> > (I added Konrad and xen-devel to CC list, hopefully that's ok..)
> =

> And let me add James Harper here since he was doing some testing with
> the Windows GPL PV USB driver as well
> =


And let's modify the subject aswell :) =


-- Pasi

> =

> > =

> > > It's been a very long time since we discussed PVUSB - I haven't given
> > > up, just been caught up with other things.
> > > =

> > =

> > Great! Really nice to hear from you again..
> > =

> > Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
> > extracted the xen patches, and started preparing to re-port the driver =
to pvops.
> > So now I don't have to finish that :)
> > =

> > > I've updated the PVUSB patch, done some refactoring and cleaned up the
> > > checkpatch warnings.
> > > The patch is targetted at linux-next, but it also applies cleanly to
> > > Konrad's linux-next branch:
> > > =

> > > http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.p=
atch
> > > =

> > > I haven't done a lot of testing, but it does work for my basic test
> > > (USB TV-tuner). My next step is to get in contact with the USB
> > > maintainer and see what further changes are required in order to get
> > > this work upstreamed. In the meantime, the more testing and exposure
> > > the patch gets the better.
> > > =

> > =

> > I'm sure we can get people testing this patch. Many people have been as=
king
> > for USB passthru solution for Linux 3.x.
> > =

> > =

> > > Thanks,
> > > =

> > =

> > Thanks a lot!
> > =

> > =

> > -- Pasi
> > =

> > > Nathanael
> > > =

> > > On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > > > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > >>
> > > >> > I also noticed the frontend driver was producing a warning when
> > > >> > loading which is resolved by setting the module owner.
> > > >> >
> > > >> > I've placed an updated diff here:
> > > >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > > >> >
> > > >>
> > > >> Great, thanks.
> > > >>
> > > >
> > > > Hello again,
> > > >
> > > > Nathanael: Did you have time to take a look at upstreaming xen pvus=
b drivers ?
> > > >
> > > > -- Pasi
> > > >
> > =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:01:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:01:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBpP-0001RU-4V; Wed, 08 Feb 2012 18:01:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RvBpN-0001RL-4c
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:01:09 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328724062!8390589!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12793 invoked from network); 8 Feb 2012 18:01:03 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 18:01:03 -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 624FC1AFC;
	Wed,  8 Feb 2012 20:01:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C64C220056; Wed,  8 Feb 2012 20:01:00 +0200 (EET)
Date: Wed, 8 Feb 2012 20:01:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120208180100.GZ12984@reaktio.net>
References: <1294133619.3831.29.camel@zakaz.uk.xensource.com>
	<20110104095224.GR2754@reaktio.net>
	<AANLkTimE+AR8fYB5Fd0U-xi0g=_c7vU0Y_xWRReVDox+@mail.gmail.com>
	<20110106185553.GP2754@reaktio.net>
	<AANLkTinGVQXmgvgnBi809fvhG-3q=r9rW3-gawrm8M+z@mail.gmail.com>
	<20110107102819.GV2754@reaktio.net>
	<20110323144257.GR32595@reaktio.net>
	<CAHd5nyxU6OEqDeiwooxNt4q_U+AzATDA6b1Ax0xuQZJiuzbLuA@mail.gmail.com>
	<20120208065930.GT12984@reaktio.net>
	<20120208174059.GB6771@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208174059.GB6771@phenom.dumpdata.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: james.harper@bendigoit.com.au, xen-devel@lists.xensource.com,
	Nathanael Rensen <nathanael@polymorpheus.com>
Subject: Re: [Xen-devel] Xen pvusb drivers for upstream Linux 3.x kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:40:59PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 08, 2012 at 08:59:30AM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 08:56:22AM +0800, Nathanael Rensen wrote:
> > > Hi Pasi,
> > > =

> > =

> > Hello,
> > =

> > (I added Konrad and xen-devel to CC list, hopefully that's ok..)
> =

> And let me add James Harper here since he was doing some testing with
> the Windows GPL PV USB driver as well
> =


And let's modify the subject aswell :) =


-- Pasi

> =

> > =

> > > It's been a very long time since we discussed PVUSB - I haven't given
> > > up, just been caught up with other things.
> > > =

> > =

> > Great! Really nice to hear from you again..
> > =

> > Just last weekend I fetched the opensuse Linux 3.2 kernel-xen src.rpm,
> > extracted the xen patches, and started preparing to re-port the driver =
to pvops.
> > So now I don't have to finish that :)
> > =

> > > I've updated the PVUSB patch, done some refactoring and cleaned up the
> > > checkpatch warnings.
> > > The patch is targetted at linux-next, but it also applies cleanly to
> > > Konrad's linux-next branch:
> > > =

> > > http://members.iinet.net.au/~nathanael/0001-pvusb-driver.linux-next.p=
atch
> > > =

> > > I haven't done a lot of testing, but it does work for my basic test
> > > (USB TV-tuner). My next step is to get in contact with the USB
> > > maintainer and see what further changes are required in order to get
> > > this work upstreamed. In the meantime, the more testing and exposure
> > > the patch gets the better.
> > > =

> > =

> > I'm sure we can get people testing this patch. Many people have been as=
king
> > for USB passthru solution for Linux 3.x.
> > =

> > =

> > > Thanks,
> > > =

> > =

> > Thanks a lot!
> > =

> > =

> > -- Pasi
> > =

> > > Nathanael
> > > =

> > > On 23 March 2011 22:42, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > > > On Fri, Jan 07, 2011 at 12:28:19PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > >>
> > > >> > I also noticed the frontend driver was producing a warning when
> > > >> > loading which is resolved by setting the module owner.
> > > >> >
> > > >> > I've placed an updated diff here:
> > > >> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > > >> >
> > > >>
> > > >> Great, thanks.
> > > >>
> > > >
> > > > Hello again,
> > > >
> > > > Nathanael: Did you have time to take a look at upstreaming xen pvus=
b drivers ?
> > > >
> > > > -- Pasi
> > > >
> > =

> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:04:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:04:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBsl-0001aA-OX; Wed, 08 Feb 2012 18:04: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 1RvBsk-0001a0-Oj
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:04:38 +0000
Received: from [85.158.139.83:26335] by server-10.bemta-5.messagelabs.com id
	58/EC-26909-539B23F4; Wed, 08 Feb 2012 18:04:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328724277!14232967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18672 invoked from network); 8 Feb 2012 18:04:37 -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;
	8 Feb 2012 18:04:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 18:04:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 18:04:30 +0000
Date: Wed, 8 Feb 2012 18:07:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Kai Huang <mail.kai.huang@gmail.com>
In-Reply-To: <CANqQZNH-wCiZk9D5sKEq0A2BqZehX=iUjUEGQfd+h+MOOp=+XQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202081737120.3196@kaball-desktop>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
	<4F3128DF.20208@gmail.com>
	<20120207171456.GD4375@phenom.dumpdata.com>
	<CANqQZNH-wCiZk9D5sKEq0A2BqZehX=iUjUEGQfd+h+MOOp=+XQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [question] Does HVM domain support
 xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Kai Huang wrote:
> On Wed, Feb 8, 2012 at 1:14 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Feb 07, 2012 at 09:36:31PM +0800, cody wrote:
> >> On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
> >> >On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
> >> >>Hi,
> >> >>
> >> >>I see in pcifront_init, if domain is not PV domain, pcifront_init just
> >> >>returns error. So seems HVM domain does not support
> >> >>xen-pcifront/xen-pciback mechanism? If it is true, why? I think
> >> >Yup. B/c the only thing that the PV PCI protocol does is enable
> >> >PCI configuration emulation. And if you boot an HVM guest - QEMU does
> >> >that already.
> >> >
> >> I heard qemu does not support PCIE simulation, and Xen does not
> >> provides MMIO mechanism but only legacy IO port mechanism to guest
> >> for configuration space access. Is this true?
> >
> > The upstream version has a X58 north bridge implementation to support this.
> > (ioh3420.c).
> >
> > In regards to MMIO mechanism are you talking about MSI-X and such? Then
> > the answer is it does. QEMU traps when a guest tries to write MSI vectors
> > in the BAR space and translates those to appropiate xen calls to setup
> > vectors for the guest.
> 
> MMIO mechanism means software can access PCI configuration space
> through memory space, using normal mov instruction, like normal memory
> access. I believe modern PCs all provide this mechanism. Basically
> there'll be a physical memory address area reserved for PCI
> configuration space, and base address will be reported in ACPI table.
> If there's no such information in ACPI table, we need to use legacy IO
> port mechanism.
> 
> I am not specifically talking about MSI-X. Accessing PCI configuration
> space through IO port has limitation that we can only access first
> 256B of configuration space as it is designed for PCI bus. For PCIE
> device, configuration space is extended to 4K, which means we cannot
> access configuration space after 256B by using legacy IO port
> mechanism. This is why PCIE device requires MMIO mechanism to access
> it's configuration space. If PCIE device implements some capabilities,
> such as MSI-X capability, after first 256B in it's configuration
> space, we will never be able to enable MSI-X by using IO port
> mechanism.
> 
> I am not familiar Xen and don't know if Xen has provides MMIO
> mechanism to guest for PCI configuration space access (To provide it,
> I think we need to report base address of configuration space in
> guest's ACPI table, and mark pages of configuration space to be
> non-accessible, as hypervisor needs to capture guest's configuration
> space access).

We don't support PCI configuration via MMIO at the moment but it is
certainly possible to introduce it.

On the other hand having PV PCI work with HVM guests is technically
challenging because we would need to support the emulated PCI domain/bus
and the new PV PCI domain/bus created by pcifront at the same time.
For example xenbus initialization is done through the Xen platform-pci
driver.
Also, considering that we need to support the emulated passthrough code
for Windows guests anyway, I don't think that introducing any more
complexity or use cases in either the PV or emulated code paths is a
good idea.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:04:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:04:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBsl-0001aA-OX; Wed, 08 Feb 2012 18:04: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 1RvBsk-0001a0-Oj
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:04:38 +0000
Received: from [85.158.139.83:26335] by server-10.bemta-5.messagelabs.com id
	58/EC-26909-539B23F4; Wed, 08 Feb 2012 18:04:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328724277!14232967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18672 invoked from network); 8 Feb 2012 18:04:37 -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;
	8 Feb 2012 18:04:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10581965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 18:04:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 18:04:30 +0000
Date: Wed, 8 Feb 2012 18:07:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Kai Huang <mail.kai.huang@gmail.com>
In-Reply-To: <CANqQZNH-wCiZk9D5sKEq0A2BqZehX=iUjUEGQfd+h+MOOp=+XQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202081737120.3196@kaball-desktop>
References: <CANqQZNFLfAHGun2ySQzzxEOy5zkS6w6ZpTmyEz2xg72+qNfSXQ@mail.gmail.com>
	<20120206175812.GB14439@phenom.dumpdata.com>
	<4F3128DF.20208@gmail.com>
	<20120207171456.GD4375@phenom.dumpdata.com>
	<CANqQZNH-wCiZk9D5sKEq0A2BqZehX=iUjUEGQfd+h+MOOp=+XQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [question] Does HVM domain support
 xen-pcifront/xen-pciback?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Kai Huang wrote:
> On Wed, Feb 8, 2012 at 1:14 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Feb 07, 2012 at 09:36:31PM +0800, cody wrote:
> >> On 02/07/2012 01:58 AM, Konrad Rzeszutek Wilk wrote:
> >> >On Mon, Feb 06, 2012 at 04:32:05PM +0800, Kai Huang wrote:
> >> >>Hi,
> >> >>
> >> >>I see in pcifront_init, if domain is not PV domain, pcifront_init just
> >> >>returns error. So seems HVM domain does not support
> >> >>xen-pcifront/xen-pciback mechanism? If it is true, why? I think
> >> >Yup. B/c the only thing that the PV PCI protocol does is enable
> >> >PCI configuration emulation. And if you boot an HVM guest - QEMU does
> >> >that already.
> >> >
> >> I heard qemu does not support PCIE simulation, and Xen does not
> >> provides MMIO mechanism but only legacy IO port mechanism to guest
> >> for configuration space access. Is this true?
> >
> > The upstream version has a X58 north bridge implementation to support this.
> > (ioh3420.c).
> >
> > In regards to MMIO mechanism are you talking about MSI-X and such? Then
> > the answer is it does. QEMU traps when a guest tries to write MSI vectors
> > in the BAR space and translates those to appropiate xen calls to setup
> > vectors for the guest.
> 
> MMIO mechanism means software can access PCI configuration space
> through memory space, using normal mov instruction, like normal memory
> access. I believe modern PCs all provide this mechanism. Basically
> there'll be a physical memory address area reserved for PCI
> configuration space, and base address will be reported in ACPI table.
> If there's no such information in ACPI table, we need to use legacy IO
> port mechanism.
> 
> I am not specifically talking about MSI-X. Accessing PCI configuration
> space through IO port has limitation that we can only access first
> 256B of configuration space as it is designed for PCI bus. For PCIE
> device, configuration space is extended to 4K, which means we cannot
> access configuration space after 256B by using legacy IO port
> mechanism. This is why PCIE device requires MMIO mechanism to access
> it's configuration space. If PCIE device implements some capabilities,
> such as MSI-X capability, after first 256B in it's configuration
> space, we will never be able to enable MSI-X by using IO port
> mechanism.
> 
> I am not familiar Xen and don't know if Xen has provides MMIO
> mechanism to guest for PCI configuration space access (To provide it,
> I think we need to report base address of configuration space in
> guest's ACPI table, and mark pages of configuration space to be
> non-accessible, as hypervisor needs to capture guest's configuration
> space access).

We don't support PCI configuration via MMIO at the moment but it is
certainly possible to introduce it.

On the other hand having PV PCI work with HVM guests is technically
challenging because we would need to support the emulated PCI domain/bus
and the new PV PCI domain/bus created by pcifront at the same time.
For example xenbus initialization is done through the Xen platform-pci
driver.
Also, considering that we need to support the emulated passthrough code
for Windows guests anyway, I don't think that introducing any more
complexity or use cases in either the PV or emulated code paths is a
good idea.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBwt-0001le-HJ; Wed, 08 Feb 2012 18:08:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvBws-0001lR-1q
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:08:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328724527!12536788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6347 invoked from network); 8 Feb 2012 18:08:48 -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;
	8 Feb 2012 18:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10582037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 18:08:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 18:08:47 +0000
Date: Wed, 8 Feb 2012 18:11:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20120208175646.GY12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-706446417-1328724731=:3196"
Cc: Jacobs Jordi <Jordi.Jacobs@howest.be>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-706446417-1328724731=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Wed, 8 Feb 2012, Pasi Kärkkäinen wrote:
> On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > Hi,
> > > 
> > > I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> > > 
> > > I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> > > one would be the best solution for Xen.
> > > 
> > > API remoting (gallium3D) (ex. Xen3D project)
> > > Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> > > 
> > > Can you guys give me your idea on the matter?
> > > Please also mention any existing projects you know that are related to this problem.
> > 
> > My personal opinion is that the simplest thing to do is OpenGL
> > remoting. Gallium remoting could also be OK but considering that many
> > cards don't have Gallium drivers we would probably end up doing two
> > conversions instead of one (DirectX->Gallium in the guest,
> > Gallium->OpenGL in dom0).
> > Mediated passthrough is very card specific so I am afraid you would end
> > up writing virtualization specific drivers for all the cards you want to
> > support. Not to mention that you might need to access some videocard
> > interfaces that on Nvidia are not discosed.
> > 
> > I believe that virtualbox already supports OpenGL remoting in a decent
> > way, so I would start from there, port what they have to Xen, and
> > improve it.
> > 
> 
> I wonder if SPICE already supports OpenGL stuff..
> I think it's at least supposed to be able to support OpenGL.
> 
> (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html)
 
Not yet, but I think that they are working on it. Still very early days
though.
Also it would only work with HVM guests, while having a proper xen
frontend/backend OpenGL remoting driver pair would work for both.
--8323329-706446417-1328724731=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-706446417-1328724731=:3196--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvBwt-0001le-HJ; Wed, 08 Feb 2012 18:08:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvBws-0001lR-1q
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:08:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328724527!12536788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6347 invoked from network); 8 Feb 2012 18:08:48 -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;
	8 Feb 2012 18:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208";a="10582037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 18:08:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 18:08:47 +0000
Date: Wed, 8 Feb 2012 18:11:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20120208175646.GY12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-706446417-1328724731=:3196"
Cc: Jacobs Jordi <Jordi.Jacobs@howest.be>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-706446417-1328724731=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Wed, 8 Feb 2012, Pasi Kärkkäinen wrote:
> On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > Hi,
> > > 
> > > I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> > > 
> > > I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> > > one would be the best solution for Xen.
> > > 
> > > API remoting (gallium3D) (ex. Xen3D project)
> > > Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> > > 
> > > Can you guys give me your idea on the matter?
> > > Please also mention any existing projects you know that are related to this problem.
> > 
> > My personal opinion is that the simplest thing to do is OpenGL
> > remoting. Gallium remoting could also be OK but considering that many
> > cards don't have Gallium drivers we would probably end up doing two
> > conversions instead of one (DirectX->Gallium in the guest,
> > Gallium->OpenGL in dom0).
> > Mediated passthrough is very card specific so I am afraid you would end
> > up writing virtualization specific drivers for all the cards you want to
> > support. Not to mention that you might need to access some videocard
> > interfaces that on Nvidia are not discosed.
> > 
> > I believe that virtualbox already supports OpenGL remoting in a decent
> > way, so I would start from there, port what they have to Xen, and
> > improve it.
> > 
> 
> I wonder if SPICE already supports OpenGL stuff..
> I think it's at least supposed to be able to support OpenGL.
> 
> (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html)
 
Not yet, but I think that they are working on it. Still very early days
though.
Also it would only work with HVM guests, while having a proper xen
frontend/backend OpenGL remoting driver pair would work for both.
--8323329-706446417-1328724731=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-706446417-1328724731=:3196--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:19:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:19:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvC6b-00022S-32; Wed, 08 Feb 2012 18:18:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RvC6Z-00022H-Dz
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:18:55 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328725128!13432722!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11673 invoked from network); 8 Feb 2012 18:18:49 -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; 8 Feb 2012 18:18:49 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2627B1CD4;
	Wed,  8 Feb 2012 20:18:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D522320056; Wed,  8 Feb 2012 20:18:47 +0200 (EET)
Date: Wed, 8 Feb 2012 20:18:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120208181847.GA12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > Hi,
> > > > =

> > > > I am wondering how GPU sharing could/should be implemented for the =
Xen Hypervisor.
> > > > =

> > > > I have come across several papers that explain many possibilities o=
n GPU sharing for multiple VMs but I'm not sure wich
> > > > one would be the best solution for Xen.
> > > > =

> > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > Mediated passthrough (Multiplexing the GPU while maintaining the di=
fferent contexts.)
> > > > =

> > > > Can you guys give me your idea on the matter?
> > > > Please also mention any existing projects you know that are related=
 to this problem.
> > > =

> > > My personal opinion is that the simplest thing to do is OpenGL
> > > remoting. Gallium remoting could also be OK but considering that many
> > > cards don't have Gallium drivers we would probably end up doing two
> > > conversions instead of one (DirectX->Gallium in the guest,
> > > Gallium->OpenGL in dom0).
> > > Mediated passthrough is very card specific so I am afraid you would e=
nd
> > > up writing virtualization specific drivers for all the cards you want=
 to
> > > support. Not to mention that you might need to access some videocard
> > > interfaces that on Nvidia are not discosed.
> > > =

> > > I believe that virtualbox already supports OpenGL remoting in a decent
> > > way, so I would start from there, port what they have to Xen, and
> > > improve it.
> > > =

> > =

> > I wonder if SPICE already supports OpenGL stuff..
> > I think it's at least supposed to be able to support OpenGL.
> > =

> > (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018=
.html)
>  =

> Not yet, but I think that they are working on it. Still very early days
> though.
> Also it would only work with HVM guests, while having a proper xen
> frontend/backend OpenGL remoting driver pair would work for both.

Yep.

There's also: http://sourceforge.net/projects/vmgl/

"OpenGL apps running inside a VM use VMGL to obtain graphics hardware accel=
eration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-based=
 OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel GPUs.=
 "

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:19:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:19:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvC6b-00022S-32; Wed, 08 Feb 2012 18:18:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RvC6Z-00022H-Dz
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:18:55 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328725128!13432722!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11673 invoked from network); 8 Feb 2012 18:18:49 -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; 8 Feb 2012 18:18:49 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2627B1CD4;
	Wed,  8 Feb 2012 20:18:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D522320056; Wed,  8 Feb 2012 20:18:47 +0200 (EET)
Date: Wed, 8 Feb 2012 20:18:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120208181847.GA12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > Hi,
> > > > =

> > > > I am wondering how GPU sharing could/should be implemented for the =
Xen Hypervisor.
> > > > =

> > > > I have come across several papers that explain many possibilities o=
n GPU sharing for multiple VMs but I'm not sure wich
> > > > one would be the best solution for Xen.
> > > > =

> > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > Mediated passthrough (Multiplexing the GPU while maintaining the di=
fferent contexts.)
> > > > =

> > > > Can you guys give me your idea on the matter?
> > > > Please also mention any existing projects you know that are related=
 to this problem.
> > > =

> > > My personal opinion is that the simplest thing to do is OpenGL
> > > remoting. Gallium remoting could also be OK but considering that many
> > > cards don't have Gallium drivers we would probably end up doing two
> > > conversions instead of one (DirectX->Gallium in the guest,
> > > Gallium->OpenGL in dom0).
> > > Mediated passthrough is very card specific so I am afraid you would e=
nd
> > > up writing virtualization specific drivers for all the cards you want=
 to
> > > support. Not to mention that you might need to access some videocard
> > > interfaces that on Nvidia are not discosed.
> > > =

> > > I believe that virtualbox already supports OpenGL remoting in a decent
> > > way, so I would start from there, port what they have to Xen, and
> > > improve it.
> > > =

> > =

> > I wonder if SPICE already supports OpenGL stuff..
> > I think it's at least supposed to be able to support OpenGL.
> > =

> > (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018=
.html)
>  =

> Not yet, but I think that they are working on it. Still very early days
> though.
> Also it would only work with HVM guests, while having a proper xen
> frontend/backend OpenGL remoting driver pair would work for both.

Yep.

There's also: http://sourceforge.net/projects/vmgl/

"OpenGL apps running inside a VM use VMGL to obtain graphics hardware accel=
eration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-based=
 OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel GPUs.=
 "

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:22:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18: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.xensource.com>)
	id 1RvCAD-0002CT-Px; Wed, 08 Feb 2012 18:22:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RvCAC-0002Bw-Ro
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:22:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328725354!14174041!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21243 invoked from network); 8 Feb 2012 18:22:34 -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; 8 Feb 2012 18:22:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id B8C2D1D2B;
	Wed,  8 Feb 2012 20:22:33 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 91B7520056; Wed,  8 Feb 2012 20:22:33 +0200 (EET)
Date: Wed, 8 Feb 2012 20:22:33 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120208182233.GB12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208181847.GA12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > Hi,
> > > > > =

> > > > > I am wondering how GPU sharing could/should be implemented for th=
e Xen Hypervisor.
> > > > > =

> > > > > I have come across several papers that explain many possibilities=
 on GPU sharing for multiple VMs but I'm not sure wich
> > > > > one would be the best solution for Xen.
> > > > > =

> > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > Mediated passthrough (Multiplexing the GPU while maintaining the =
different contexts.)
> > > > > =

> > > > > Can you guys give me your idea on the matter?
> > > > > Please also mention any existing projects you know that are relat=
ed to this problem.
> > > > =

> > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > remoting. Gallium remoting could also be OK but considering that ma=
ny
> > > > cards don't have Gallium drivers we would probably end up doing two
> > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > Gallium->OpenGL in dom0).
> > > > Mediated passthrough is very card specific so I am afraid you would=
 end
> > > > up writing virtualization specific drivers for all the cards you wa=
nt to
> > > > support. Not to mention that you might need to access some videocard
> > > > interfaces that on Nvidia are not discosed.
> > > > =

> > > > I believe that virtualbox already supports OpenGL remoting in a dec=
ent
> > > > way, so I would start from there, port what they have to Xen, and
> > > > improve it.
> > > > =

> > > =

> > > I wonder if SPICE already supports OpenGL stuff..
> > > I think it's at least supposed to be able to support OpenGL.
> > > =

> > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/0060=
18.html)
> >  =

> > Not yet, but I think that they are working on it. Still very early days
> > though.
> > Also it would only work with HVM guests, while having a proper xen
> > frontend/backend OpenGL remoting driver pair would work for both.
> =

> Yep.
> =

> There's also: http://sourceforge.net/projects/vmgl/
> =

> "OpenGL apps running inside a VM use VMGL to obtain graphics hardware acc=
eleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-bas=
ed OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel GPU=
s. "
> =


And Chromium might have something related aswell:
http://chromium.sourceforge.net/doc/index.html


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:22:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18: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.xensource.com>)
	id 1RvCAD-0002CT-Px; Wed, 08 Feb 2012 18:22:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RvCAC-0002Bw-Ro
	for Xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:22:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328725354!14174041!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQ2MTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21243 invoked from network); 8 Feb 2012 18:22:34 -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; 8 Feb 2012 18:22:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id B8C2D1D2B;
	Wed,  8 Feb 2012 20:22:33 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 91B7520056; Wed,  8 Feb 2012 20:22:33 +0200 (EET)
Date: Wed, 8 Feb 2012 20:22:33 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120208182233.GB12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208181847.GA12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > Hi,
> > > > > =

> > > > > I am wondering how GPU sharing could/should be implemented for th=
e Xen Hypervisor.
> > > > > =

> > > > > I have come across several papers that explain many possibilities=
 on GPU sharing for multiple VMs but I'm not sure wich
> > > > > one would be the best solution for Xen.
> > > > > =

> > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > Mediated passthrough (Multiplexing the GPU while maintaining the =
different contexts.)
> > > > > =

> > > > > Can you guys give me your idea on the matter?
> > > > > Please also mention any existing projects you know that are relat=
ed to this problem.
> > > > =

> > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > remoting. Gallium remoting could also be OK but considering that ma=
ny
> > > > cards don't have Gallium drivers we would probably end up doing two
> > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > Gallium->OpenGL in dom0).
> > > > Mediated passthrough is very card specific so I am afraid you would=
 end
> > > > up writing virtualization specific drivers for all the cards you wa=
nt to
> > > > support. Not to mention that you might need to access some videocard
> > > > interfaces that on Nvidia are not discosed.
> > > > =

> > > > I believe that virtualbox already supports OpenGL remoting in a dec=
ent
> > > > way, so I would start from there, port what they have to Xen, and
> > > > improve it.
> > > > =

> > > =

> > > I wonder if SPICE already supports OpenGL stuff..
> > > I think it's at least supposed to be able to support OpenGL.
> > > =

> > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/0060=
18.html)
> >  =

> > Not yet, but I think that they are working on it. Still very early days
> > though.
> > Also it would only work with HVM guests, while having a proper xen
> > frontend/backend OpenGL remoting driver pair would work for both.
> =

> Yep.
> =

> There's also: http://sourceforge.net/projects/vmgl/
> =

> "OpenGL apps running inside a VM use VMGL to obtain graphics hardware acc=
eleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-bas=
ed OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel GPU=
s. "
> =


And Chromium might have something related aswell:
http://chromium.sourceforge.net/doc/index.html


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:55:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvCfe-0002az-IX; Wed, 08 Feb 2012 18:55:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvCfc-0002au-Lc
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:55:08 +0000
Received: from [85.158.139.83:11548] by server-1.bemta-5.messagelabs.com id
	BC/2D-04285-B05C23F4; Wed, 08 Feb 2012 18:55:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328727302!6929891!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31951 invoked from network); 8 Feb 2012 18:55:03 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 18:55:03 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q18Iswng029922
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 8 Feb 2012 10:55:00 -0800
Received: by bkcjg15 with SMTP id jg15so1379530bkc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 10:54:57 -0800 (PST)
Received: by 10.204.130.89 with SMTP id r25mr12489158bks.49.1328727297354;
	Wed, 08 Feb 2012 10:54:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Wed, 8 Feb 2012 10:54:17 -0800 (PST)
In-Reply-To: <20120208174912.GX12984@reaktio.net>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
	<20120208174912.GX12984@reaktio.net>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 8 Feb 2012 10:54:17 -0800
Message-ID: <CAP8mzPPPU5RkqFgB-ydzPP4VZSSooTJ63dUyzPcM+foJ3ONytA@mail.gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: mailinglist@modernbiztonsag.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6927435949339450352=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6927435949339450352==
Content-Type: multipart/alternative; boundary=0015174482668fed6804b8786eb8

--0015174482668fed6804b8786eb8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 8, 2012 at 9:49 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Wed, Feb 08, 2012 at 04:59:18PM +0100, mailinglist@modernbiztonsag.org=
wrote:
> > Dear List,
> >
>
> Hello,
>
> > i'm experimenting with remus with the following setup.
> >
> > dom0:
> > - Debian Squeeze
> > - Jeremy's 2.6.38.48 kernel
> > - xen 4.1.2 recompiled from sid
> > - DRBD for block device backend
> >
>
> Did you try xen-unstable? There are many Remus related fixes/enhancements
> in xen-unstable.
>
>
IIRC, all fixes were backported to xen-4.1-testing.


> -- Pasi
>
>
> > domU
> > - Debian Squeeze
> >
> > Remus is working fine unless i try to give more than 1 core to the domU=
.
> >
>


The problem arises from your domU config file:
cpus =3D "1-15"

The python parser is unable to parse the cpu spec in this format. I think
even
cpus =3D "^0" throws an error of similar sort.

One solution is to remove this line, boot the domU,
and do xm vcpu-pin command to restrict the physical cpus
on which you wish the domU to run.


shriram


>  > Here's the error from remus when i'm trying to enable it for an SMP
> domU:
> >
> > Traceback (most recent call last):
> >   File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
> >     run(cfg)
> >   File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
> >     dom =3D vm.VM(cfg.domid)
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in
> __init__
> >     self.loaddominfo()
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in
> loaddominfo
> >     self.dom =3D parsedominfo(self.dominfo)
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
> > parsedominfo
> >     return s2d(dominfo[1:])
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
> >     val =3D s2d(elem[1:])
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
> >     return s2d(elem)
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
> >     for k, v in val.iteritems():
> > AttributeError: 'int' object has no attribute 'iteritems'
> >
> > I've attached the domU configuration file.
> >
> > Please let me know if you need more info on this.
> >
> > Best regards,
> > Mate
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>

--0015174482668fed6804b8786eb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Feb 8, 2012 at 9:49 AM, Pasi K=E4rkk=E4i=
nen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Wed, Feb 08, 2012 at 04:59:18PM +0100, <a href=3D"mailto:mailinglist@mod=
ernbiztonsag.org">mailinglist@modernbiztonsag.org</a> wrote:<br>
&gt; Dear List,<br>
&gt;<br>
<br>
Hello,<br>
<div class=3D"im"><br>
&gt; i&#39;m experimenting with remus with the following setup.<br>
&gt;<br>
&gt; dom0:<br>
&gt; - Debian Squeeze<br>
&gt; - Jeremy&#39;s 2.6.38.48 kernel<br>
&gt; - xen 4.1.2 recompiled from sid<br>
&gt; - DRBD for block device backend<br>
&gt;<br>
<br>
</div>Did you try xen-unstable? There are many Remus related fixes/enhancem=
ents in xen-unstable.<br>
<br></blockquote><div><br>IIRC, all fixes were backported to xen-4.1-testin=
g.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0p=
t 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- Pasi<br>
<div><div class=3D"h5"><br>
<br>
&gt; domU<br>
&gt; - Debian Squeeze<br>
&gt;<br>
&gt; Remus is working fine unless i try to give more than 1 core to the dom=
U.<br>
&gt;<br></div></div></blockquote><div><br><br>The problem arises from your =
domU config file:<br>cpus =3D &quot;1-15&quot;<br><br>The python parser is =
unable to parse the cpu spec in this format. I think even<br>cpus =3D &quot=
;^0&quot; throws an error of similar sort.<br>

<br>One solution is to remove this line, boot the domU, <br>and do xm vcpu-=
pin command to restrict the physical cpus <br>on which you wish the domU to=
 run.<br><br><br>shriram<br>=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">

<div><div class=3D"h5">
&gt; Here&#39;s the error from remus when i&#39;m trying to enable it for a=
n SMP domU:<br>
&gt;<br>
&gt; Traceback (most recent call last):<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/remus&quot;, line 219, in &=
lt;module&gt;<br>
&gt; =A0 =A0 run(cfg)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/remus&quot;, line 109, in r=
un<br>
&gt; =A0 =A0 dom =3D vm.VM(cfg.domid)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 32, in __init__<br>
&gt; =A0 =A0 self.loaddominfo()<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 35, in loaddominfo<br>
&gt; =A0 =A0 self.dom =3D parsedominfo(self.dominfo)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 77, in<br>
&gt; parsedominfo<br>
&gt; =A0 =A0 return s2d(dominfo[1:])<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 61, in s2d<br>
&gt; =A0 =A0 val =3D s2d(elem[1:])<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 64, in s2d<br>
&gt; =A0 =A0 return s2d(elem)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 66, in s2d<br>
&gt; =A0 =A0 for k, v in val.iteritems():<br>
&gt; AttributeError: &#39;int&#39; object has no attribute &#39;iteritems&#=
39;<br>
&gt;<br>
&gt; I&#39;ve attached the domU configuration file.<br>
&gt;<br>
&gt; Please let me know if you need more info on this.<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Mate<br>
<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
<br>
</blockquote></div><br>

--0015174482668fed6804b8786eb8--


--===============6927435949339450352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6927435949339450352==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 18:55:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 18:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvCfe-0002az-IX; Wed, 08 Feb 2012 18:55:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvCfc-0002au-Lc
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:55:08 +0000
Received: from [85.158.139.83:11548] by server-1.bemta-5.messagelabs.com id
	BC/2D-04285-B05C23F4; Wed, 08 Feb 2012 18:55:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328727302!6929891!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31951 invoked from network); 8 Feb 2012 18:55:03 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2012 18:55:03 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q18Iswng029922
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 8 Feb 2012 10:55:00 -0800
Received: by bkcjg15 with SMTP id jg15so1379530bkc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 10:54:57 -0800 (PST)
Received: by 10.204.130.89 with SMTP id r25mr12489158bks.49.1328727297354;
	Wed, 08 Feb 2012 10:54:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Wed, 8 Feb 2012 10:54:17 -0800 (PST)
In-Reply-To: <20120208174912.GX12984@reaktio.net>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
	<20120208174912.GX12984@reaktio.net>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 8 Feb 2012 10:54:17 -0800
Message-ID: <CAP8mzPPPU5RkqFgB-ydzPP4VZSSooTJ63dUyzPcM+foJ3ONytA@mail.gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: mailinglist@modernbiztonsag.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6927435949339450352=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6927435949339450352==
Content-Type: multipart/alternative; boundary=0015174482668fed6804b8786eb8

--0015174482668fed6804b8786eb8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 8, 2012 at 9:49 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Wed, Feb 08, 2012 at 04:59:18PM +0100, mailinglist@modernbiztonsag.org=
wrote:
> > Dear List,
> >
>
> Hello,
>
> > i'm experimenting with remus with the following setup.
> >
> > dom0:
> > - Debian Squeeze
> > - Jeremy's 2.6.38.48 kernel
> > - xen 4.1.2 recompiled from sid
> > - DRBD for block device backend
> >
>
> Did you try xen-unstable? There are many Remus related fixes/enhancements
> in xen-unstable.
>
>
IIRC, all fixes were backported to xen-4.1-testing.


> -- Pasi
>
>
> > domU
> > - Debian Squeeze
> >
> > Remus is working fine unless i try to give more than 1 core to the domU=
.
> >
>


The problem arises from your domU config file:
cpus =3D "1-15"

The python parser is unable to parse the cpu spec in this format. I think
even
cpus =3D "^0" throws an error of similar sort.

One solution is to remove this line, boot the domU,
and do xm vcpu-pin command to restrict the physical cpus
on which you wish the domU to run.


shriram


>  > Here's the error from remus when i'm trying to enable it for an SMP
> domU:
> >
> > Traceback (most recent call last):
> >   File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
> >     run(cfg)
> >   File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
> >     dom =3D vm.VM(cfg.domid)
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in
> __init__
> >     self.loaddominfo()
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in
> loaddominfo
> >     self.dom =3D parsedominfo(self.dominfo)
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
> > parsedominfo
> >     return s2d(dominfo[1:])
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
> >     val =3D s2d(elem[1:])
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
> >     return s2d(elem)
> >   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
> >     for k, v in val.iteritems():
> > AttributeError: 'int' object has no attribute 'iteritems'
> >
> > I've attached the domU configuration file.
> >
> > Please let me know if you need more info on this.
> >
> > Best regards,
> > Mate
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>

--0015174482668fed6804b8786eb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Feb 8, 2012 at 9:49 AM, Pasi K=E4rkk=E4i=
nen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Wed, Feb 08, 2012 at 04:59:18PM +0100, <a href=3D"mailto:mailinglist@mod=
ernbiztonsag.org">mailinglist@modernbiztonsag.org</a> wrote:<br>
&gt; Dear List,<br>
&gt;<br>
<br>
Hello,<br>
<div class=3D"im"><br>
&gt; i&#39;m experimenting with remus with the following setup.<br>
&gt;<br>
&gt; dom0:<br>
&gt; - Debian Squeeze<br>
&gt; - Jeremy&#39;s 2.6.38.48 kernel<br>
&gt; - xen 4.1.2 recompiled from sid<br>
&gt; - DRBD for block device backend<br>
&gt;<br>
<br>
</div>Did you try xen-unstable? There are many Remus related fixes/enhancem=
ents in xen-unstable.<br>
<br></blockquote><div><br>IIRC, all fixes were backported to xen-4.1-testin=
g.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0p=
t 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- Pasi<br>
<div><div class=3D"h5"><br>
<br>
&gt; domU<br>
&gt; - Debian Squeeze<br>
&gt;<br>
&gt; Remus is working fine unless i try to give more than 1 core to the dom=
U.<br>
&gt;<br></div></div></blockquote><div><br><br>The problem arises from your =
domU config file:<br>cpus =3D &quot;1-15&quot;<br><br>The python parser is =
unable to parse the cpu spec in this format. I think even<br>cpus =3D &quot=
;^0&quot; throws an error of similar sort.<br>

<br>One solution is to remove this line, boot the domU, <br>and do xm vcpu-=
pin command to restrict the physical cpus <br>on which you wish the domU to=
 run.<br><br><br>shriram<br>=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">

<div><div class=3D"h5">
&gt; Here&#39;s the error from remus when i&#39;m trying to enable it for a=
n SMP domU:<br>
&gt;<br>
&gt; Traceback (most recent call last):<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/remus&quot;, line 219, in &=
lt;module&gt;<br>
&gt; =A0 =A0 run(cfg)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/remus&quot;, line 109, in r=
un<br>
&gt; =A0 =A0 dom =3D vm.VM(cfg.domid)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 32, in __init__<br>
&gt; =A0 =A0 self.loaddominfo()<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 35, in loaddominfo<br>
&gt; =A0 =A0 self.dom =3D parsedominfo(self.dominfo)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 77, in<br>
&gt; parsedominfo<br>
&gt; =A0 =A0 return s2d(dominfo[1:])<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 61, in s2d<br>
&gt; =A0 =A0 val =3D s2d(elem[1:])<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 64, in s2d<br>
&gt; =A0 =A0 return s2d(elem)<br>
&gt; =A0 File &quot;/usr/lib/xen-4.1/lib/python/xen/remus/vm.py&quot;, line=
 66, in s2d<br>
&gt; =A0 =A0 for k, v in val.iteritems():<br>
&gt; AttributeError: &#39;int&#39; object has no attribute &#39;iteritems&#=
39;<br>
&gt;<br>
&gt; I&#39;ve attached the domU configuration file.<br>
&gt;<br>
&gt; Please let me know if you need more info on this.<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Mate<br>
<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
<br>
</blockquote></div><br>

--0015174482668fed6804b8786eb8--


--===============6927435949339450352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6927435949339450352==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 19:22:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 19:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvD5T-0002y2-UM; Wed, 08 Feb 2012 19:21:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <enzinol@gmail.com>) id 1RvD5R-0002xT-T4
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 19:21:50 +0000
X-Env-Sender: enzinol@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328728903!10719292!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14632 invoked from network); 8 Feb 2012 19:21:43 -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;
	8 Feb 2012 19:21:43 -0000
Received: by werb14 with SMTP id b14so2647947wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 11:21:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=IlG9EUsmTnKZwrsniLOO+fdnI4KydFLNYEpZB9ZmOoc=;
	b=dSToKTYiOCvDDnbhmJYmbLKXGGGOHuBMBj+Wqc9mmDKRS310XZjkmdl/TITj+PqpoZ
	F0zhT3+OAi9kJzSPZwNmLLTJCs6pnCER07TeXCZDGFQN4SRELKpoDMwnqR9eeTWxoEoa
	AuNMDibZqLfVolHL9lyzT+YeeZ/Y4CRiJRLfA=
MIME-Version: 1.0
Received: by 10.180.93.132 with SMTP id cu4mr28260157wib.9.1328728903206; Wed,
	08 Feb 2012 11:21:43 -0800 (PST)
Received: by 10.223.45.194 with HTTP; Wed, 8 Feb 2012 11:21:43 -0800 (PST)
In-Reply-To: <20120208071135.GU12984@reaktio.net>
References: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
	<20120208071135.GU12984@reaktio.net>
Date: Wed, 8 Feb 2012 11:21:43 -0800
Message-ID: <CACi2erDY4d9OqvTBpFmUAyr_dG5-Fii6pnZeznE5p29-qUACwQ@mail.gmail.com>
From: Enzo Lombardi <enzinol@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] applying ATI patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0220708923394658117=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0220708923394658117==
Content-Type: multipart/alternative; boundary=f46d043c80b847460f04b878ce13

--f46d043c80b847460f04b878ce13
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you.
On a related topic: any idea on when/if these patches are going to make it
in the main release branch?
-e

On Tue, Feb 7, 2012 at 11:11 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Tue, Feb 07, 2012 at 05:44:29PM -0800, Enzo Lombardi wrote:
> >    Greetings,
> >    I am trying to apply this patch
> >    ( [1]
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284=
.html) to
> >    the 4.1.2 release code.
> >    If I download the code from the main page
> >    ( [2]http://xen.org/products/xen_source.html ) I see the relevant
> files
> >    but when I enlist through mercurials the files are not there.
> >    Is the patch referring to deprecated/dead code?
> >    Has anybody successfully applied the same patch in the 4.x branch?
>
> If you're talking about qemu-dm files, you first need to build the source
> once,
> so the qemu-xen tree gets fetched (and built) from internet.
>
> -- Pasi
>
>

--f46d043c80b847460f04b878ce13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you.<div>On a related topic: any idea on when/if these patches are go=
ing to make it in the main release branch?</div><div>-e<br><br><div class=
=3D"gmail_quote">On Tue, Feb 7, 2012 at 11:11 PM, Pasi K=E4rkk=E4inen <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Feb 07, 2012 at 05=
:44:29PM -0800, Enzo Lombardi wrote:<br>
&gt; =A0 =A0Greetings,<br>
&gt; =A0 =A0I am trying to apply this patch<br>
</div>&gt; =A0 =A0( [1]<a href=3D"http://old-list-archives.xen.org/archives=
/html/xen-devel/2010-10/msg00284.html" target=3D"_blank">http://old-list-ar=
chives.xen.org/archives/html/xen-devel/2010-10/msg00284.html</a> ) to<br>
<div class=3D"im">&gt; =A0 =A0the 4.1.2 release code.<br>
&gt; =A0 =A0If I download the code from the main page<br>
</div>&gt; =A0 =A0( [2]<a href=3D"http://xen.org/products/xen_source.html" =
target=3D"_blank">http://xen.org/products/xen_source.html</a> ) I see the r=
elevant files<br>
<div class=3D"im">&gt; =A0 =A0but when I enlist through mercurials the file=
s are not there.<br>
&gt; =A0 =A0Is the patch referring to deprecated/dead code?<br>
&gt; =A0 =A0Has anybody successfully applied the same patch in the 4.x bran=
ch?<br>
<br>
</div>If you&#39;re talking about qemu-dm files, you first need to build th=
e source once,<br>
so the qemu-xen tree gets fetched (and built) from internet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div>

--f46d043c80b847460f04b878ce13--


--===============0220708923394658117==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0220708923394658117==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 19:22:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 19:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvD5T-0002y2-UM; Wed, 08 Feb 2012 19:21:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <enzinol@gmail.com>) id 1RvD5R-0002xT-T4
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 19:21:50 +0000
X-Env-Sender: enzinol@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328728903!10719292!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14632 invoked from network); 8 Feb 2012 19:21:43 -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;
	8 Feb 2012 19:21:43 -0000
Received: by werb14 with SMTP id b14so2647947wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 11:21:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=IlG9EUsmTnKZwrsniLOO+fdnI4KydFLNYEpZB9ZmOoc=;
	b=dSToKTYiOCvDDnbhmJYmbLKXGGGOHuBMBj+Wqc9mmDKRS310XZjkmdl/TITj+PqpoZ
	F0zhT3+OAi9kJzSPZwNmLLTJCs6pnCER07TeXCZDGFQN4SRELKpoDMwnqR9eeTWxoEoa
	AuNMDibZqLfVolHL9lyzT+YeeZ/Y4CRiJRLfA=
MIME-Version: 1.0
Received: by 10.180.93.132 with SMTP id cu4mr28260157wib.9.1328728903206; Wed,
	08 Feb 2012 11:21:43 -0800 (PST)
Received: by 10.223.45.194 with HTTP; Wed, 8 Feb 2012 11:21:43 -0800 (PST)
In-Reply-To: <20120208071135.GU12984@reaktio.net>
References: <CACi2erCFRUV8cU1H8sNyU-YXomi5g9pGQTzXjL5Be_abEepzqA@mail.gmail.com>
	<20120208071135.GU12984@reaktio.net>
Date: Wed, 8 Feb 2012 11:21:43 -0800
Message-ID: <CACi2erDY4d9OqvTBpFmUAyr_dG5-Fii6pnZeznE5p29-qUACwQ@mail.gmail.com>
From: Enzo Lombardi <enzinol@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] applying ATI patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0220708923394658117=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0220708923394658117==
Content-Type: multipart/alternative; boundary=f46d043c80b847460f04b878ce13

--f46d043c80b847460f04b878ce13
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you.
On a related topic: any idea on when/if these patches are going to make it
in the main release branch?
-e

On Tue, Feb 7, 2012 at 11:11 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Tue, Feb 07, 2012 at 05:44:29PM -0800, Enzo Lombardi wrote:
> >    Greetings,
> >    I am trying to apply this patch
> >    ( [1]
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284=
.html) to
> >    the 4.1.2 release code.
> >    If I download the code from the main page
> >    ( [2]http://xen.org/products/xen_source.html ) I see the relevant
> files
> >    but when I enlist through mercurials the files are not there.
> >    Is the patch referring to deprecated/dead code?
> >    Has anybody successfully applied the same patch in the 4.x branch?
>
> If you're talking about qemu-dm files, you first need to build the source
> once,
> so the qemu-xen tree gets fetched (and built) from internet.
>
> -- Pasi
>
>

--f46d043c80b847460f04b878ce13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you.<div>On a related topic: any idea on when/if these patches are go=
ing to make it in the main release branch?</div><div>-e<br><br><div class=
=3D"gmail_quote">On Tue, Feb 7, 2012 at 11:11 PM, Pasi K=E4rkk=E4inen <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Feb 07, 2012 at 05=
:44:29PM -0800, Enzo Lombardi wrote:<br>
&gt; =A0 =A0Greetings,<br>
&gt; =A0 =A0I am trying to apply this patch<br>
</div>&gt; =A0 =A0( [1]<a href=3D"http://old-list-archives.xen.org/archives=
/html/xen-devel/2010-10/msg00284.html" target=3D"_blank">http://old-list-ar=
chives.xen.org/archives/html/xen-devel/2010-10/msg00284.html</a> ) to<br>
<div class=3D"im">&gt; =A0 =A0the 4.1.2 release code.<br>
&gt; =A0 =A0If I download the code from the main page<br>
</div>&gt; =A0 =A0( [2]<a href=3D"http://xen.org/products/xen_source.html" =
target=3D"_blank">http://xen.org/products/xen_source.html</a> ) I see the r=
elevant files<br>
<div class=3D"im">&gt; =A0 =A0but when I enlist through mercurials the file=
s are not there.<br>
&gt; =A0 =A0Is the patch referring to deprecated/dead code?<br>
&gt; =A0 =A0Has anybody successfully applied the same patch in the 4.x bran=
ch?<br>
<br>
</div>If you&#39;re talking about qemu-dm files, you first need to build th=
e source once,<br>
so the qemu-xen tree gets fetched (and built) from internet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div>

--f46d043c80b847460f04b878ce13--


--===============0220708923394658117==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0220708923394658117==--


From xen-devel-bounces@lists.xensource.com Wed Feb 08 19:35:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 19: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.xensource.com>)
	id 1RvDHu-0003O2-0M; Wed, 08 Feb 2012 19:34: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 1RvDHr-0003Nx-QI
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 19:34:40 +0000
Received: from [85.158.139.83:10797] by server-2.bemta-5.messagelabs.com id
	59/60-20725-E4EC23F4; Wed, 08 Feb 2012 19:34:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328729678!14213829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24773 invoked from network); 8 Feb 2012 19:34:38 -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;
	8 Feb 2012 19:34:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,385,1325462400"; d="scan'208";a="10582969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 19:34:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 19:34:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvDHF-000317-JJ;
	Wed, 08 Feb 2012 19:34:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvDHF-00056G-4Y;
	Wed, 08 Feb 2012 19:34:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11901-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 8 Feb 2012 19:34:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11901: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11901 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11901/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2      fail REGR. vs. 11896
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 11896
 test-i386-i386-win           14 guest-start.2                fail   like 11896

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  8ba7ae0b070b
baseline version:
 xen                  eae25241d571

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Santosh Jodh <santosh.jodh@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=8ba7ae0b070b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 8ba7ae0b070b
+ branch=xen-unstable
+ revision=8ba7ae0b070b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 8ba7ae0b070b 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 16 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 19:35:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 19: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.xensource.com>)
	id 1RvDHu-0003O2-0M; Wed, 08 Feb 2012 19:34: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 1RvDHr-0003Nx-QI
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 19:34:40 +0000
Received: from [85.158.139.83:10797] by server-2.bemta-5.messagelabs.com id
	59/60-20725-E4EC23F4; Wed, 08 Feb 2012 19:34:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328729678!14213829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24773 invoked from network); 8 Feb 2012 19:34:38 -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;
	8 Feb 2012 19:34:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,385,1325462400"; d="scan'208";a="10582969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2012 19:34:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 8 Feb 2012 19:34:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvDHF-000317-JJ;
	Wed, 08 Feb 2012 19:34:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvDHF-00056G-4Y;
	Wed, 08 Feb 2012 19:34:01 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11901-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 8 Feb 2012 19:34:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11901: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11901 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11901/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2      fail REGR. vs. 11896
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 11896
 test-i386-i386-win           14 guest-start.2                fail   like 11896

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  8ba7ae0b070b
baseline version:
 xen                  eae25241d571

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Santosh Jodh <santosh.jodh@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=8ba7ae0b070b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 8ba7ae0b070b
+ branch=xen-unstable
+ revision=8ba7ae0b070b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 8ba7ae0b070b 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 16 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 19:44:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 19:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvDRO-0003kc-T0; Wed, 08 Feb 2012 19:44:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kris@theendless.org>) id 1RvDRM-0003kN-34
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 19:44:29 +0000
X-Env-Sender: kris@theendless.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328730217!62083608!1
X-Originating-IP: [72.51.30.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6440 invoked from network); 8 Feb 2012 19:43:38 -0000
Received: from theendless.org (HELO mail.theendless.org) (72.51.30.5)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 19:43:38 -0000
Received: by mail.theendless.org (Postfix, from userid 102)
	id 5C58ADC8002; Wed,  8 Feb 2012 14:44:25 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on theendless.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE
	autolearn=no version=3.2.5
Received: from [192.168.20.23] (unknown [96.45.197.22])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by mail.theendless.org (Postfix) with ESMTP id 1995ADC8001
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 14:44:25 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theendless.org;
	s=02012012; t=1328730265;
	bh=gSoGuiYS2cNzns0jSiOFFWcG78mHGlECwjLnw+L7eiw=;
	h=From:Content-Type:Content-Transfer-Encoding:Subject:Date:
	Message-Id:To:Mime-Version;
	b=JF+zPekmniZsWSsR5KOa4+mqHMlRDvm354167wfyBbhK6LgzJUikdZzDCDCCcHmFQ
	WEm5kgjDMbgb8GdJlisvSDzIOHZx/wmcujGPwUHrsWjTiOE6fBELycunRcLcqRVpcP
	wRd99ZLdoqQixeMBy8zJkaCoLfjlYcXE1vCA/xu4=
From: Kris <kris@theendless.org>
Date: Wed, 8 Feb 2012 14:44:22 -0500
Message-Id: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: [Xen-devel] Question about xen network and strange happenings with
	migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I've been experiencing some issues with Xen-3.4.2-2.el5 (from gitco) on CentOS 5.4 when migrating nodes from one physical node to another. Each VM has 3 network interfaces (vifs).

When doing a live migration (xm migrate --live <params>) the network of the migrated VM seems to go in to a very odd state when it's done migrating. I've searched high and low for some documentation on what the state, evt-ch,tx-/rx-ring-ref fields mean with their particular integer values, but 1,-1,-1/-1 respectively seems to be indicative of something that has gone badly. A state of 4 seems to indicate that the interface is in a working state.

When doing a xm network-list VM on the node it is being migrated *to* - in this case all of them are broken, but sometimes it's just one or two interfaces are in this state.:
Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
0   0  <REDACTED>   0     1      -1    -1   /-1      /local/domain/0/backend/vif/2/0  
1   0  <REDACTED>    1     1      -1    -1   /-1      /local/domain/0/backend/vif/2/1  
2   0  <REDACTED>    2     1      -1    -1   /-1      /local/domain/0/backend/vif/2/2

The result is that the network interfaces with the output above do not work.

Is there anything I can do to perhaps debug this better? Is there any documentation I'm missing out that would explain this stuff? Any troubleshooting help is appreciated. I've looked at the xend logs and there doesn't seem to be anything indicative of why this is occurring.

Thanks,
Kris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 19:44:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 19:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvDRO-0003kc-T0; Wed, 08 Feb 2012 19:44:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kris@theendless.org>) id 1RvDRM-0003kN-34
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 19:44:29 +0000
X-Env-Sender: kris@theendless.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328730217!62083608!1
X-Originating-IP: [72.51.30.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6440 invoked from network); 8 Feb 2012 19:43:38 -0000
Received: from theendless.org (HELO mail.theendless.org) (72.51.30.5)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 19:43:38 -0000
Received: by mail.theendless.org (Postfix, from userid 102)
	id 5C58ADC8002; Wed,  8 Feb 2012 14:44:25 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on theendless.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE
	autolearn=no version=3.2.5
Received: from [192.168.20.23] (unknown [96.45.197.22])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by mail.theendless.org (Postfix) with ESMTP id 1995ADC8001
	for <xen-devel@lists.xensource.com>;
	Wed,  8 Feb 2012 14:44:25 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theendless.org;
	s=02012012; t=1328730265;
	bh=gSoGuiYS2cNzns0jSiOFFWcG78mHGlECwjLnw+L7eiw=;
	h=From:Content-Type:Content-Transfer-Encoding:Subject:Date:
	Message-Id:To:Mime-Version;
	b=JF+zPekmniZsWSsR5KOa4+mqHMlRDvm354167wfyBbhK6LgzJUikdZzDCDCCcHmFQ
	WEm5kgjDMbgb8GdJlisvSDzIOHZx/wmcujGPwUHrsWjTiOE6fBELycunRcLcqRVpcP
	wRd99ZLdoqQixeMBy8zJkaCoLfjlYcXE1vCA/xu4=
From: Kris <kris@theendless.org>
Date: Wed, 8 Feb 2012 14:44:22 -0500
Message-Id: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: [Xen-devel] Question about xen network and strange happenings with
	migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I've been experiencing some issues with Xen-3.4.2-2.el5 (from gitco) on CentOS 5.4 when migrating nodes from one physical node to another. Each VM has 3 network interfaces (vifs).

When doing a live migration (xm migrate --live <params>) the network of the migrated VM seems to go in to a very odd state when it's done migrating. I've searched high and low for some documentation on what the state, evt-ch,tx-/rx-ring-ref fields mean with their particular integer values, but 1,-1,-1/-1 respectively seems to be indicative of something that has gone badly. A state of 4 seems to indicate that the interface is in a working state.

When doing a xm network-list VM on the node it is being migrated *to* - in this case all of them are broken, but sometimes it's just one or two interfaces are in this state.:
Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
0   0  <REDACTED>   0     1      -1    -1   /-1      /local/domain/0/backend/vif/2/0  
1   0  <REDACTED>    1     1      -1    -1   /-1      /local/domain/0/backend/vif/2/1  
2   0  <REDACTED>    2     1      -1    -1   /-1      /local/domain/0/backend/vif/2/2

The result is that the network interfaces with the output above do not work.

Is there anything I can do to perhaps debug this better? Is there any documentation I'm missing out that would explain this stuff? Any troubleshooting help is appreciated. I've looked at the xend logs and there doesn't seem to be anything indicative of why this is occurring.

Thanks,
Kris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 20:03:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 20: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.xensource.com>)
	id 1RvDin-0004K0-Pw; Wed, 08 Feb 2012 20:02:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xisisu@gmail.com>) id 1RvDim-0004Jv-CQ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 20:02:28 +0000
X-Env-Sender: xisisu@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328731340!10545464!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27432 invoked from network); 8 Feb 2012 20:02:21 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 20:02:21 -0000
Received: by obcuy19 with SMTP id uy19so3721364obc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 12:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=E6QSYBrVmy77XsW5FYavINTDAmLyPKnl/9seTA9Phro=;
	b=FmCTl7xFY5wlCEQ0WN2aad/p7Yia7kT7lXEyic+G90wHfxAonyrJGtJMXMt1eNDOQQ
	0f1XiEiRXm/5o6MVpo+ia1nhIf8IfKCa6mgN5i9nKXjhzySeZ98VeC6Hmv6FIwvoZx7i
	JtPp+/QCL4nZ3DHC0dTDmBJSfqKABrctPygW0=
Received: by 10.182.11.41 with SMTP id n9mr27466560obb.24.1328731339994; Wed,
	08 Feb 2012 12:02:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.80.42 with HTTP; Wed, 8 Feb 2012 12:01:39 -0800 (PST)
From: Sisu Xi <xisisu@gmail.com>
Date: Wed, 8 Feb 2012 14:01:39 -0600
Message-ID: <CAPqOm-q4cdXG153ivKOSXJdfscKPX=-i51EawtD3BixAObGfVA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] How does Xen perform the rate control for guest domain?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, all:

Does anyone know how does the ``rate'' parameter works in Xen? I know
Xen previously use the ``netif'' data structure, and use the
``credit_bytes'' and ``remaining credits'' to do that. But I added
printk into thoese functions and they seems to be not called at all.
Does Xen change that?

I am using Xen 4.0.1.

Thanks in advance!

Sisu


-- 
Sisu Xi, PhD Candidate
Department of Computer Science and Engineering
Washington University in St. Louis
http://www.cse.wustl.edu/~xis/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 20:03:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 20: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.xensource.com>)
	id 1RvDin-0004K0-Pw; Wed, 08 Feb 2012 20:02:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xisisu@gmail.com>) id 1RvDim-0004Jv-CQ
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 20:02:28 +0000
X-Env-Sender: xisisu@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328731340!10545464!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27432 invoked from network); 8 Feb 2012 20:02:21 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 20:02:21 -0000
Received: by obcuy19 with SMTP id uy19so3721364obc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 12:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=E6QSYBrVmy77XsW5FYavINTDAmLyPKnl/9seTA9Phro=;
	b=FmCTl7xFY5wlCEQ0WN2aad/p7Yia7kT7lXEyic+G90wHfxAonyrJGtJMXMt1eNDOQQ
	0f1XiEiRXm/5o6MVpo+ia1nhIf8IfKCa6mgN5i9nKXjhzySeZ98VeC6Hmv6FIwvoZx7i
	JtPp+/QCL4nZ3DHC0dTDmBJSfqKABrctPygW0=
Received: by 10.182.11.41 with SMTP id n9mr27466560obb.24.1328731339994; Wed,
	08 Feb 2012 12:02:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.80.42 with HTTP; Wed, 8 Feb 2012 12:01:39 -0800 (PST)
From: Sisu Xi <xisisu@gmail.com>
Date: Wed, 8 Feb 2012 14:01:39 -0600
Message-ID: <CAPqOm-q4cdXG153ivKOSXJdfscKPX=-i51EawtD3BixAObGfVA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] How does Xen perform the rate control for guest domain?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, all:

Does anyone know how does the ``rate'' parameter works in Xen? I know
Xen previously use the ``netif'' data structure, and use the
``credit_bytes'' and ``remaining credits'' to do that. But I added
printk into thoese functions and they seems to be not called at all.
Does Xen change that?

I am using Xen 4.0.1.

Thanks in advance!

Sisu


-- 
Sisu Xi, PhD Candidate
Department of Computer Science and Engineering
Washington University in St. Louis
http://www.cse.wustl.edu/~xis/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 22:01:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 22:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvFZQ-0006iB-Q8; Wed, 08 Feb 2012 22:00:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvFZP-0006i5-E5
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 22:00:55 +0000
Received: from [85.158.139.83:19699] by server-11.bemta-5.messagelabs.com id
	27/63-13907-690F23F4; Wed, 08 Feb 2012 22:00:54 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328738452!14300649!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13881 invoked from network); 8 Feb 2012 22:00:53 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 22:00:53 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q18M0nKU049775
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 15:00:50 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F2C158C02000078000711D4@nat28.tlf.novell.com>
Date: Wed, 8 Feb 2012 15:00:51 -0700
Message-Id: <6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
	<4F2C158C02000078000711D4@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 15:00:51 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:

> > On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
> >
> > However, if this is the rule, both types of "max ring size" values
> > are "in effect" even if a back-end does not provide them both.  So
> > how do you resolve the conflict?  A fully interoperable front should
> > allocate the largest possible ring and advertise that size through
> > both mechanisms in a fully consistent manner. That's what I was
> > trying to indicate by writing the spec this way.
> 
> Hmm, I would think a fully compatible frontend should bail (revert to
> single page ring) on inconsistent max-ring-pages and
> max-ring-page-order, if both are provided by the backend. The limit
> for ring-pages should always be max-ring-pages, while the one for
> ring-page-order should always be max-ring-page-order. Any mixture
> is an error, unless both values are consistent with one another.
> 
> Jan

Mandating that a front-end publish inconsistent values to the
XenStore would be a mistake.  Having the front-end only publish the
set of nodes that are recognized by the back-end just adds code
complexity with no associated increase in functionality.  You
actually would lose the ability to tell that the driver supports
both schemes.

To clarify what I mean by that, consider the current state of
back-ends in the world.  They fall into 1 of 4 camps:

 1. No multi-page ring support
 2. "Citrix style" multi-page ring support.
 3. "Red Hat style" multi-page ring support.
 4. "Both styles" multi-page ring support.

In cases 1-3, one or both of the max-ring-page* nodes is not present.
Per the currently proposed spec, this means that these nodes have
their default values.  You seem to be advocating that the front-end
write the default values into its corresponding node.  For cases 2
and 3, this would lead to contradictory values in the XenStore (e.g.
ring-page-order=0 and ring-pages=4).  This will not confuse the
back-end, but could confuse a human.

For case 4, the back-end must publish both node types even though
the front-end may not look at both.  Since we can't avoid having
both nodes, it seems reasonable to allow a front-end to publish
them both too.  It also avoids the additional logic to test against
back-end node presence.

With all that said, I believe the spec should indicate that a
fully-interoperable implementation should publish both nodes with
values that match the allocated ring size.  The tolerance level for
a back-end publishing inconsistent nodes should be left to the
implementation.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 22:01:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 22:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvFZQ-0006iB-Q8; Wed, 08 Feb 2012 22:00:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvFZP-0006i5-E5
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 22:00:55 +0000
Received: from [85.158.139.83:19699] by server-11.bemta-5.messagelabs.com id
	27/63-13907-690F23F4; Wed, 08 Feb 2012 22:00:54 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328738452!14300649!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13881 invoked from network); 8 Feb 2012 22:00:53 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 22:00:53 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q18M0nKU049775
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 15:00:50 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F2C158C02000078000711D4@nat28.tlf.novell.com>
Date: Wed, 8 Feb 2012 15:00:51 -0700
Message-Id: <6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
	<4F2C158C02000078000711D4@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 15:00:51 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:

> > On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
> >
> > However, if this is the rule, both types of "max ring size" values
> > are "in effect" even if a back-end does not provide them both.  So
> > how do you resolve the conflict?  A fully interoperable front should
> > allocate the largest possible ring and advertise that size through
> > both mechanisms in a fully consistent manner. That's what I was
> > trying to indicate by writing the spec this way.
> 
> Hmm, I would think a fully compatible frontend should bail (revert to
> single page ring) on inconsistent max-ring-pages and
> max-ring-page-order, if both are provided by the backend. The limit
> for ring-pages should always be max-ring-pages, while the one for
> ring-page-order should always be max-ring-page-order. Any mixture
> is an error, unless both values are consistent with one another.
> 
> Jan

Mandating that a front-end publish inconsistent values to the
XenStore would be a mistake.  Having the front-end only publish the
set of nodes that are recognized by the back-end just adds code
complexity with no associated increase in functionality.  You
actually would lose the ability to tell that the driver supports
both schemes.

To clarify what I mean by that, consider the current state of
back-ends in the world.  They fall into 1 of 4 camps:

 1. No multi-page ring support
 2. "Citrix style" multi-page ring support.
 3. "Red Hat style" multi-page ring support.
 4. "Both styles" multi-page ring support.

In cases 1-3, one or both of the max-ring-page* nodes is not present.
Per the currently proposed spec, this means that these nodes have
their default values.  You seem to be advocating that the front-end
write the default values into its corresponding node.  For cases 2
and 3, this would lead to contradictory values in the XenStore (e.g.
ring-page-order=0 and ring-pages=4).  This will not confuse the
back-end, but could confuse a human.

For case 4, the back-end must publish both node types even though
the front-end may not look at both.  Since we can't avoid having
both nodes, it seems reasonable to allow a front-end to publish
them both too.  It also avoids the additional logic to test against
back-end node presence.

With all that said, I believe the spec should indicate that a
fully-interoperable implementation should publish both nodes with
values that match the allocated ring size.  The tolerance level for
a back-end publishing inconsistent nodes should be left to the
implementation.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 22:23:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 22: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.xensource.com>)
	id 1RvFut-0007YZ-DJ; Wed, 08 Feb 2012 22:23:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvFur-0007YU-Jv
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 22:23:05 +0000
Received: from [193.109.254.147:40515] by server-8.bemta-14.messagelabs.com id
	13/F0-04706-8C5F23F4; Wed, 08 Feb 2012 22:23:04 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328739732!51969962!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2824 invoked from network); 8 Feb 2012 22:22:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2012 22:22:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvFuo-0004ls-Ed
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:23:02 -0800
Date: Wed, 8 Feb 2012 14:23:02 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328739782447-5467907.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I see there is spice support in unstable, seem to be a very good vdi and we
want use it on server with xen but I not found documentation about in xen,
only about kvm.
Someone can tell me anything about it please?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5467907.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 22:23:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 22: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.xensource.com>)
	id 1RvFut-0007YZ-DJ; Wed, 08 Feb 2012 22:23:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvFur-0007YU-Jv
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 22:23:05 +0000
Received: from [193.109.254.147:40515] by server-8.bemta-14.messagelabs.com id
	13/F0-04706-8C5F23F4; Wed, 08 Feb 2012 22:23:04 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328739732!51969962!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2824 invoked from network); 8 Feb 2012 22:22:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2012 22:22:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvFuo-0004ls-Ed
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 14:23:02 -0800
Date: Wed, 8 Feb 2012 14:23:02 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328739782447-5467907.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I see there is spice support in unstable, seem to be a very good vdi and we
want use it on server with xen but I not found documentation about in xen,
only about kvm.
Someone can tell me anything about it please?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5467907.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 23:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 23: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.xensource.com>)
	id 1RvGgR-0007y5-HT; Wed, 08 Feb 2012 23:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvGgQ-0007xx-C2
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 23:12:14 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328742726!12583675!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11861 invoked from network); 8 Feb 2012 23:12:07 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 23:12:07 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q18NC02E050053
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 16:12:01 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20273.24695.56347.32673@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:12:04 -0700
Message-Id: <1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 16:12:01 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
	block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 7, 2012, at 10:33 AM, Ian Jackson wrote:

> Justin T. Gibbs writes ("[Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> > +/*
> > + * Xen-defined major numbers for virtual block devices.
> > + */
>
> Isn't this the same thing as is in
>  docs/misc/vbd-interface.txt
> only expressed differently ?

Ian.

I wasn't aware of this file.  After a brief look, it seems there is
information missing from both vbd-interface.txt and blkif.h.  Per
vbd-interface.txt, there is also an error in blkif.h.  The "virtual-device"
node must tolerate 32bit integers.

I'll fix the size specification for the "virtual-device" node, but how
should I reconcile blkif.h and vbd-interface.txt.  I hate information
duplication since one version is invariably stale.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 23:12:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 23: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.xensource.com>)
	id 1RvGgR-0007y5-HT; Wed, 08 Feb 2012 23:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvGgQ-0007xx-C2
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 23:12:14 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328742726!12583675!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11861 invoked from network); 8 Feb 2012 23:12:07 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 23:12:07 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q18NC02E050053
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 16:12:01 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20273.24695.56347.32673@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:12:04 -0700
Message-Id: <1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 16:12:01 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
	block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 7, 2012, at 10:33 AM, Ian Jackson wrote:

> Justin T. Gibbs writes ("[Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> > +/*
> > + * Xen-defined major numbers for virtual block devices.
> > + */
>
> Isn't this the same thing as is in
>  docs/misc/vbd-interface.txt
> only expressed differently ?

Ian.

I wasn't aware of this file.  After a brief look, it seems there is
information missing from both vbd-interface.txt and blkif.h.  Per
vbd-interface.txt, there is also an error in blkif.h.  The "virtual-device"
node must tolerate 32bit integers.

I'll fix the size specification for the "virtual-device" node, but how
should I reconcile blkif.h and vbd-interface.txt.  I hate information
duplication since one version is invariably stale.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 23:25:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 23:25:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvGsc-0008EQ-U5; Wed, 08 Feb 2012 23:24:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvGsb-0008EI-Ho
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 23:24:49 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328743481!12594329!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27127 invoked from network); 8 Feb 2012 23:24:42 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 23:24:42 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q18NOahH050104
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 16:24:37 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20273.25747.542056.575794@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:24:41 -0700
Message-Id: <0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
	<20273.25747.542056.575794@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 16:24:37 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
	documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:

> Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
>>  o Document the XenBus nodes used in this protocol
> 
> Awesome.  But I don't think all of these are really supposed to be
> part of the guest interface, so you should probably mention which ones
> are.
> 
> For example,
> 
>> + * params
>> + *      Values:         string
> 
> this is not intended for use by guests and they should not look at it.

Guests can export back-end devices.  Here at Spectra we do this all the
time. :-)

It would be hard to implement a blkback driver without this information.
The comment at the top of your email implies you're okay with it being
in this file, but that I should mark "local-end use only" nodes?

> 
>> + * virtual-device
>> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> 
> This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> this also encoded in the device path in xenstore ?

It would appear so.  Should this path naming convention be mandated by
this file?  Since "virtual-device" exists, it seems that front-ends should
read it, not parse the path, to determine this information.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 08 23:25:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 08 Feb 2012 23:25:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvGsc-0008EQ-U5; Wed, 08 Feb 2012 23:24:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvGsb-0008EI-Ho
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 23:24:49 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328743481!12594329!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27127 invoked from network); 8 Feb 2012 23:24:42 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2012 23:24:42 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q18NOahH050104
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 16:24:37 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20273.25747.542056.575794@mariner.uk.xensource.com>
Date: Wed, 8 Feb 2012 16:24:41 -0700
Message-Id: <0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
	<20273.25747.542056.575794@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 16:24:37 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
	documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:

> Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
>>  o Document the XenBus nodes used in this protocol
> 
> Awesome.  But I don't think all of these are really supposed to be
> part of the guest interface, so you should probably mention which ones
> are.
> 
> For example,
> 
>> + * params
>> + *      Values:         string
> 
> this is not intended for use by guests and they should not look at it.

Guests can export back-end devices.  Here at Spectra we do this all the
time. :-)

It would be hard to implement a blkback driver without this information.
The comment at the top of your email implies you're okay with it being
in this file, but that I should mark "local-end use only" nodes?

> 
>> + * virtual-device
>> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> 
> This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> this also encoded in the device path in xenstore ?

It would appear so.  Should this path naming convention be mandated by
this file?  Since "virtual-device" exists, it seems that front-ends should
read it, not parse the path, to determine this information.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 01:03:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 01:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvIPY-0004bp-0j; Thu, 09 Feb 2012 01:02:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1RvIPV-0004bk-Sq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 01:02:54 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328749320!51970299!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19369 invoked from network); 9 Feb 2012 01:02:02 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 01:02:02 -0000
Received: by iaeh11 with SMTP id h11so3184346iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 17:02:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=oaPS0fJ/lbFfIM+gZcgu+seGrRbVzsJQd1APSFkiKZg=;
	b=lTc3JEuZiFV9B7jOZFl2I+P2zhIz4vABKrZ8AQ8wHIrQ1RjQZ2dkX53lGd6fSHKzZg
	ru5oeEwc2U0ue7bBE1fquKNKL0QZexlpPJNhp128X6t2usyQGrEgbtNpVvjWWjekKkug
	85Gibdhq9SBAgPnyaPhnhfZtuEl0l5KK2E+28=
Received: by 10.50.202.67 with SMTP id kg3mr37769403igc.13.1328749371207; Wed,
	08 Feb 2012 17:02:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.6.18 with HTTP; Wed, 8 Feb 2012 17:02:31 -0800 (PST)
In-Reply-To: <1328739782447-5467907.post@n5.nabble.com>
References: <1328739782447-5467907.post@n5.nabble.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Wed, 8 Feb 2012 20:02:31 -0500
X-Google-Sender-Auth: dypYHC1rUktWpNNnFCFOq2VdyFY
Message-ID: <CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
To: Fantu <fantonifabio@tiscali.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 8, 2012 at 5:23 PM, Fantu <fantonifabio@tiscali.it> wrote:
> I see there is spice support in unstable, seem to be a very good vdi and we
> want use it on server with xen but I not found documentation about in xen,
> only about kvm.

usage here:

http://xen.markmail.org/search/?q=spice#query:spice%20list%3Acom.xensource.lists.xen-changelog+page:1+mid:gx7eglq7wdvfmtxc+state:results

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 01:03:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 01:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvIPY-0004bp-0j; Thu, 09 Feb 2012 01:02:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1RvIPV-0004bk-Sq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 01:02:54 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328749320!51970299!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19369 invoked from network); 9 Feb 2012 01:02:02 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 01:02:02 -0000
Received: by iaeh11 with SMTP id h11so3184346iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 17:02:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=oaPS0fJ/lbFfIM+gZcgu+seGrRbVzsJQd1APSFkiKZg=;
	b=lTc3JEuZiFV9B7jOZFl2I+P2zhIz4vABKrZ8AQ8wHIrQ1RjQZ2dkX53lGd6fSHKzZg
	ru5oeEwc2U0ue7bBE1fquKNKL0QZexlpPJNhp128X6t2usyQGrEgbtNpVvjWWjekKkug
	85Gibdhq9SBAgPnyaPhnhfZtuEl0l5KK2E+28=
Received: by 10.50.202.67 with SMTP id kg3mr37769403igc.13.1328749371207; Wed,
	08 Feb 2012 17:02:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.6.18 with HTTP; Wed, 8 Feb 2012 17:02:31 -0800 (PST)
In-Reply-To: <1328739782447-5467907.post@n5.nabble.com>
References: <1328739782447-5467907.post@n5.nabble.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Wed, 8 Feb 2012 20:02:31 -0500
X-Google-Sender-Auth: dypYHC1rUktWpNNnFCFOq2VdyFY
Message-ID: <CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
To: Fantu <fantonifabio@tiscali.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 8, 2012 at 5:23 PM, Fantu <fantonifabio@tiscali.it> wrote:
> I see there is spice support in unstable, seem to be a very good vdi and we
> want use it on server with xen but I not found documentation about in xen,
> only about kvm.

usage here:

http://xen.markmail.org/search/?q=spice#query:spice%20list%3Acom.xensource.lists.xen-changelog+page:1+mid:gx7eglq7wdvfmtxc+state:results

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 01:29:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 01:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvIoE-0004sY-7M; Thu, 09 Feb 2012 01:28:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RvIoD-0004sT-33
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 01:28:25 +0000
Received: from [85.158.139.83:12695] by server-1.bemta-5.messagelabs.com id
	3B/86-04285-831233F4; Thu, 09 Feb 2012 01:28:24 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328750901!14289463!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10330 invoked from network); 9 Feb 2012 01:28:22 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 01:28:22 -0000
Received: by qabg1 with SMTP id g1so19520901qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 17:28:21 -0800 (PST)
Received: by 10.229.137.20 with SMTP id u20mr2644465qct.64.1328750901242;
	Wed, 08 Feb 2012 17:28:21 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id fd1sm2438379qab.1.2012.02.08.17.28.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 08 Feb 2012 17:28:20 -0800 (PST)
Date: Wed, 8 Feb 2012 20:28:18 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120209012818.GA476@morn.localdomain>
References: <4F31288F.5060904@amd.com> <20120208011808.GA9541@morn.localdomain>
	<4F324F2A.9000308@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q"
Content-Disposition: inline
In-Reply-To: <4F324F2A.9000308@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Feb 08, 2012 at 11:32:10AM +0100, Christoph Egger wrote:
> On 02/08/12 02:18, Kevin O'Connor wrote:
> >We can change the seabios makefile to call these scripts with an
> >explicit $(PYTHON).
> 
> Awesome!

See the attached patch.

> >That's quite odd.  This looks data related instead of python related.
> >Try running a "make clean" and then "make" in just the seabios
> >directory.  If you still see an issue, tar up the seabios "out/"
> >directory and mail it to me.
> 
> It failed the same way.
> I sent you the tarball offlist due its size.

Looks like your version of gcc is defining sections with
.rodata.__PRETTY_FUNCTION__ - which is odd as that macro isn't used in
the code.  Does the second attached patch fix it for you?

-Kevin

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-Add-PYTHON-definition-to-Makefile.patch"

>From 97f1ffcfac4ca382b5008a7aabfc2c300131f978 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor <kevin@koconnor.net>
Date: Wed, 8 Feb 2012 20:21:29 -0500
Subject: [PATCH 1/2] Add PYTHON definition to Makefile.

Add PYTHON definition to Makefile so users can override it.  This
allows users to specify an exact python executable name to use during
the build.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
---
 Makefile |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 0343ce5..513e8f1 100644
--- a/Makefile
+++ b/Makefile
@@ -63,6 +63,7 @@ export KCONFIG_CONFIG     := $(CURDIR)/.config
 OBJCOPY=objcopy
 OBJDUMP=objdump
 STRIP=strip
+PYTHON=python
 
 # Default targets
 -include $(KCONFIG_CONFIG)
@@ -152,7 +153,7 @@ $(OUT)romlayout16.lds: $(OUT)ccode32flat.o $(OUT)code32seg.o $(OUT)code16.o tool
 	$(Q)$(OBJDUMP) -thr $(OUT)code32flat.o > $(OUT)code32flat.o.objdump
 	$(Q)$(OBJDUMP) -thr $(OUT)code32seg.o > $(OUT)code32seg.o.objdump
 	$(Q)$(OBJDUMP) -thr $(OUT)code16.o > $(OUT)code16.o.objdump
-	$(Q)./tools/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds
+	$(Q)$(PYTHON) ./tools/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds
 
 # These are actually built by tools/layoutrom.py above, but by pulling them
 # into an extra rule we prevent make -j from spawning layoutrom.py 4 times.
@@ -174,7 +175,7 @@ $(OUT)bios.bin.elf $(OUT)bios.bin: $(OUT)rom.o tools/checkrom.py
 	@echo "  Prepping $@"
 	$(Q)$(OBJDUMP) -thr $< > $<.objdump
 	$(Q)$(OBJCOPY) -O binary $< $(OUT)bios.bin.raw
-	$(Q)./tools/checkrom.py $<.objdump $(OUT)bios.bin.raw $(OUT)bios.bin
+	$(Q)$(PYTHON) ./tools/checkrom.py $<.objdump $(OUT)bios.bin.raw $(OUT)bios.bin
 	$(Q)$(STRIP) -R .comment $< -o $(OUT)bios.bin.elf
 
 
@@ -204,15 +205,15 @@ $(OUT)vgabios.bin.raw: $(OUT)vgarom.o
 
 $(OUT)vgabios.bin: $(OUT)vgabios.bin.raw tools/buildrom.py
 	@echo "  Finalizing rom $@"
-	$(Q)./tools/buildrom.py $< $@
+	$(Q)$(PYTHON) ./tools/buildrom.py $< $@
 
 ####### dsdt build rules
 src/%.hex: src/%.dsl ./tools/acpi_extract_preprocess.py ./tools/acpi_extract.py
 	@echo "Compiling DSDT"
 	$(Q)cpp -P $< > $(OUT)$*.dsl.i.orig
-	$(Q)./tools/acpi_extract_preprocess.py $(OUT)$*.dsl.i.orig > $(OUT)$*.dsl.i
+	$(Q)$(PYTHON) ./tools/acpi_extract_preprocess.py $(OUT)$*.dsl.i.orig > $(OUT)$*.dsl.i
 	$(Q)iasl -l -tc -p $(OUT)$* $(OUT)$*.dsl.i
-	$(Q)./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off
+	$(Q)$(PYTHON) ./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off
 	$(Q)cat $(OUT)$*.off > $@
 
 $(OUT)ccode32flat.o: src/acpi-dsdt.hex src/ssdt-proc.hex src/ssdt-pcihp.hex
-- 
1.7.6.5


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-Permit-.rodata.__PRETTY_FUNCTION__.-sections-in-roms.patch"

>From 805ede2bd35243a4298bc64bd81be6db7cf57f58 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor <kevin@koconnor.net>
Date: Wed, 8 Feb 2012 20:23:36 -0500
Subject: [PATCH 2/2] Permit .rodata.__PRETTY_FUNCTION__. sections in roms.

Some versions of gcc appear to define these sections even though they
aren't used in the code.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
---
 tools/layoutrom.py |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/layoutrom.py b/tools/layoutrom.py
index 45738a3..86e1f33 100755
--- a/tools/layoutrom.py
+++ b/tools/layoutrom.py
@@ -147,8 +147,10 @@ def getSectionsPrefix(sections, category, prefix):
 def doLayout(sections):
     # Determine 16bit positions
     textsections = getSectionsPrefix(sections, '16', '.text.')
-    rodatasections = (getSectionsPrefix(sections, '16', '.rodata.str1.1')
-                      + getSectionsPrefix(sections, '16', '.rodata.__func__.'))
+    rodatasections = (
+        getSectionsPrefix(sections, '16', '.rodata.str1.1')
+        + getSectionsPrefix(sections, '16', '.rodata.__func__.')
+        + getSectionsPrefix(sections, '16', '.rodata.__PRETTY_FUNCTION__.'))
     datasections = getSectionsPrefix(sections, '16', '.data16.')
     fixedsections = getSectionsPrefix(sections, '16', '.fixedaddr.')
 
@@ -159,8 +161,10 @@ def doLayout(sections):
 
     # Determine 32seg positions
     textsections = getSectionsPrefix(sections, '32seg', '.text.')
-    rodatasections = (getSectionsPrefix(sections, '32seg', '.rodata.str1.1')
-                      +getSectionsPrefix(sections, '32seg', '.rodata.__func__.'))
+    rodatasections = (
+        getSectionsPrefix(sections, '32seg', '.rodata.str1.1')
+        + getSectionsPrefix(sections, '32seg', '.rodata.__func__.')
+        + getSectionsPrefix(sections, '32seg', '.rodata.__PRETTY_FUNCTION__.'))
     datasections = getSectionsPrefix(sections, '32seg', '.data32seg.')
 
     code32seg_start = setSectionsStart(
-- 
1.7.6.5


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--ikeVEW9yuYc//A+q--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 01:29:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 01:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvIoE-0004sY-7M; Thu, 09 Feb 2012 01:28:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RvIoD-0004sT-33
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 01:28:25 +0000
Received: from [85.158.139.83:12695] by server-1.bemta-5.messagelabs.com id
	3B/86-04285-831233F4; Thu, 09 Feb 2012 01:28:24 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328750901!14289463!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10330 invoked from network); 9 Feb 2012 01:28:22 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 01:28:22 -0000
Received: by qabg1 with SMTP id g1so19520901qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 17:28:21 -0800 (PST)
Received: by 10.229.137.20 with SMTP id u20mr2644465qct.64.1328750901242;
	Wed, 08 Feb 2012 17:28:21 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id fd1sm2438379qab.1.2012.02.08.17.28.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 08 Feb 2012 17:28:20 -0800 (PST)
Date: Wed, 8 Feb 2012 20:28:18 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120209012818.GA476@morn.localdomain>
References: <4F31288F.5060904@amd.com> <20120208011808.GA9541@morn.localdomain>
	<4F324F2A.9000308@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q"
Content-Disposition: inline
In-Reply-To: <4F324F2A.9000308@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Feb 08, 2012 at 11:32:10AM +0100, Christoph Egger wrote:
> On 02/08/12 02:18, Kevin O'Connor wrote:
> >We can change the seabios makefile to call these scripts with an
> >explicit $(PYTHON).
> 
> Awesome!

See the attached patch.

> >That's quite odd.  This looks data related instead of python related.
> >Try running a "make clean" and then "make" in just the seabios
> >directory.  If you still see an issue, tar up the seabios "out/"
> >directory and mail it to me.
> 
> It failed the same way.
> I sent you the tarball offlist due its size.

Looks like your version of gcc is defining sections with
.rodata.__PRETTY_FUNCTION__ - which is odd as that macro isn't used in
the code.  Does the second attached patch fix it for you?

-Kevin

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-Add-PYTHON-definition-to-Makefile.patch"

>From 97f1ffcfac4ca382b5008a7aabfc2c300131f978 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor <kevin@koconnor.net>
Date: Wed, 8 Feb 2012 20:21:29 -0500
Subject: [PATCH 1/2] Add PYTHON definition to Makefile.

Add PYTHON definition to Makefile so users can override it.  This
allows users to specify an exact python executable name to use during
the build.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
---
 Makefile |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 0343ce5..513e8f1 100644
--- a/Makefile
+++ b/Makefile
@@ -63,6 +63,7 @@ export KCONFIG_CONFIG     := $(CURDIR)/.config
 OBJCOPY=objcopy
 OBJDUMP=objdump
 STRIP=strip
+PYTHON=python
 
 # Default targets
 -include $(KCONFIG_CONFIG)
@@ -152,7 +153,7 @@ $(OUT)romlayout16.lds: $(OUT)ccode32flat.o $(OUT)code32seg.o $(OUT)code16.o tool
 	$(Q)$(OBJDUMP) -thr $(OUT)code32flat.o > $(OUT)code32flat.o.objdump
 	$(Q)$(OBJDUMP) -thr $(OUT)code32seg.o > $(OUT)code32seg.o.objdump
 	$(Q)$(OBJDUMP) -thr $(OUT)code16.o > $(OUT)code16.o.objdump
-	$(Q)./tools/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds
+	$(Q)$(PYTHON) ./tools/layoutrom.py $(OUT)code16.o.objdump $(OUT)code32seg.o.objdump $(OUT)code32flat.o.objdump $(OUT)romlayout16.lds $(OUT)romlayout32seg.lds $(OUT)romlayout32flat.lds
 
 # These are actually built by tools/layoutrom.py above, but by pulling them
 # into an extra rule we prevent make -j from spawning layoutrom.py 4 times.
@@ -174,7 +175,7 @@ $(OUT)bios.bin.elf $(OUT)bios.bin: $(OUT)rom.o tools/checkrom.py
 	@echo "  Prepping $@"
 	$(Q)$(OBJDUMP) -thr $< > $<.objdump
 	$(Q)$(OBJCOPY) -O binary $< $(OUT)bios.bin.raw
-	$(Q)./tools/checkrom.py $<.objdump $(OUT)bios.bin.raw $(OUT)bios.bin
+	$(Q)$(PYTHON) ./tools/checkrom.py $<.objdump $(OUT)bios.bin.raw $(OUT)bios.bin
 	$(Q)$(STRIP) -R .comment $< -o $(OUT)bios.bin.elf
 
 
@@ -204,15 +205,15 @@ $(OUT)vgabios.bin.raw: $(OUT)vgarom.o
 
 $(OUT)vgabios.bin: $(OUT)vgabios.bin.raw tools/buildrom.py
 	@echo "  Finalizing rom $@"
-	$(Q)./tools/buildrom.py $< $@
+	$(Q)$(PYTHON) ./tools/buildrom.py $< $@
 
 ####### dsdt build rules
 src/%.hex: src/%.dsl ./tools/acpi_extract_preprocess.py ./tools/acpi_extract.py
 	@echo "Compiling DSDT"
 	$(Q)cpp -P $< > $(OUT)$*.dsl.i.orig
-	$(Q)./tools/acpi_extract_preprocess.py $(OUT)$*.dsl.i.orig > $(OUT)$*.dsl.i
+	$(Q)$(PYTHON) ./tools/acpi_extract_preprocess.py $(OUT)$*.dsl.i.orig > $(OUT)$*.dsl.i
 	$(Q)iasl -l -tc -p $(OUT)$* $(OUT)$*.dsl.i
-	$(Q)./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off
+	$(Q)$(PYTHON) ./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off
 	$(Q)cat $(OUT)$*.off > $@
 
 $(OUT)ccode32flat.o: src/acpi-dsdt.hex src/ssdt-proc.hex src/ssdt-pcihp.hex
-- 
1.7.6.5


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-Permit-.rodata.__PRETTY_FUNCTION__.-sections-in-roms.patch"

>From 805ede2bd35243a4298bc64bd81be6db7cf57f58 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor <kevin@koconnor.net>
Date: Wed, 8 Feb 2012 20:23:36 -0500
Subject: [PATCH 2/2] Permit .rodata.__PRETTY_FUNCTION__. sections in roms.

Some versions of gcc appear to define these sections even though they
aren't used in the code.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
---
 tools/layoutrom.py |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/layoutrom.py b/tools/layoutrom.py
index 45738a3..86e1f33 100755
--- a/tools/layoutrom.py
+++ b/tools/layoutrom.py
@@ -147,8 +147,10 @@ def getSectionsPrefix(sections, category, prefix):
 def doLayout(sections):
     # Determine 16bit positions
     textsections = getSectionsPrefix(sections, '16', '.text.')
-    rodatasections = (getSectionsPrefix(sections, '16', '.rodata.str1.1')
-                      + getSectionsPrefix(sections, '16', '.rodata.__func__.'))
+    rodatasections = (
+        getSectionsPrefix(sections, '16', '.rodata.str1.1')
+        + getSectionsPrefix(sections, '16', '.rodata.__func__.')
+        + getSectionsPrefix(sections, '16', '.rodata.__PRETTY_FUNCTION__.'))
     datasections = getSectionsPrefix(sections, '16', '.data16.')
     fixedsections = getSectionsPrefix(sections, '16', '.fixedaddr.')
 
@@ -159,8 +161,10 @@ def doLayout(sections):
 
     # Determine 32seg positions
     textsections = getSectionsPrefix(sections, '32seg', '.text.')
-    rodatasections = (getSectionsPrefix(sections, '32seg', '.rodata.str1.1')
-                      +getSectionsPrefix(sections, '32seg', '.rodata.__func__.'))
+    rodatasections = (
+        getSectionsPrefix(sections, '32seg', '.rodata.str1.1')
+        + getSectionsPrefix(sections, '32seg', '.rodata.__func__.')
+        + getSectionsPrefix(sections, '32seg', '.rodata.__PRETTY_FUNCTION__.'))
     datasections = getSectionsPrefix(sections, '32seg', '.data32seg.')
 
     code32seg_start = setSectionsStart(
-- 
1.7.6.5


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--ikeVEW9yuYc//A+q--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 02:18:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 02:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvJZq-0005Yn-CO; Thu, 09 Feb 2012 02:17:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RvJZo-0005Yg-Ax
	for Xen-devel@lists.xensource.com; Thu, 09 Feb 2012 02:17:36 +0000
Received: from [85.158.139.83:61621] by server-6.bemta-5.messagelabs.com id
	AD/7B-04784-FBC233F4; Thu, 09 Feb 2012 02:17:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328753853!14240856!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxMzM3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15581 invoked from network); 9 Feb 2012 02:17:34 -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; 9 Feb 2012 02:17:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q192HPEL015485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 02:17: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
	q192HOLb005132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 02:17:25 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q192HNK9008745; Wed, 8 Feb 2012 20:17:23 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 18:17:23 -0800
Date: Wed, 8 Feb 2012 18:17:20 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120208181720.377bb098@mantra.us.oracle.com>
In-Reply-To: <CB55DD63.2A883%keir.xen@gmail.com>
References: <20120206182654.5b5d3f2d@mantra.us.oracle.com>
	<CB55DD63.2A883%keir.xen@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F332CB7.00AE,ss=1,re=0.000,fgs=0
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] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 06 Feb 2012 19:41:23 +0000
Keir Fraser <keir.xen@gmail.com> wrote:

> On 07/02/2012 02:26, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
> > 
> > I am figuring io access for hybrid guests, dom0 and domU. I see
> > that there are two ways: PV -> emulate_privileged_op(), or hvm
> > handles via handle_mmio()/handle_pio(). I am not familiar with
> > either one, and would help me lot if anybody expert in that can
> > suggest which way hybrid should go, both dom0 and domU. Any
> > suggestions would help. If there are any docs on this, that would
> > be great too.
> 
> Probably the PV route, for dom0 and domU. Really most things you want
> to do, the PV route is going to be the right way (unless you are
> PVHVM'ing certain things, e.g., like using EPT assistance for
> pagetable handling).
> 
>  -- Keir

Thanks Keir. Just to confirm, the hybrid should continue to request
iopl of 1, right?

Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 02:18:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 02:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvJZq-0005Yn-CO; Thu, 09 Feb 2012 02:17:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RvJZo-0005Yg-Ax
	for Xen-devel@lists.xensource.com; Thu, 09 Feb 2012 02:17:36 +0000
Received: from [85.158.139.83:61621] by server-6.bemta-5.messagelabs.com id
	AD/7B-04784-FBC233F4; Thu, 09 Feb 2012 02:17:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328753853!14240856!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxMzM3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15581 invoked from network); 9 Feb 2012 02:17:34 -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; 9 Feb 2012 02:17:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q192HPEL015485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 02:17: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
	q192HOLb005132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 02:17:25 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q192HNK9008745; Wed, 8 Feb 2012 20:17:23 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 18:17:23 -0800
Date: Wed, 8 Feb 2012 18:17:20 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120208181720.377bb098@mantra.us.oracle.com>
In-Reply-To: <CB55DD63.2A883%keir.xen@gmail.com>
References: <20120206182654.5b5d3f2d@mantra.us.oracle.com>
	<CB55DD63.2A883%keir.xen@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F332CB7.00AE,ss=1,re=0.000,fgs=0
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] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 06 Feb 2012 19:41:23 +0000
Keir Fraser <keir.xen@gmail.com> wrote:

> On 07/02/2012 02:26, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
> > 
> > I am figuring io access for hybrid guests, dom0 and domU. I see
> > that there are two ways: PV -> emulate_privileged_op(), or hvm
> > handles via handle_mmio()/handle_pio(). I am not familiar with
> > either one, and would help me lot if anybody expert in that can
> > suggest which way hybrid should go, both dom0 and domU. Any
> > suggestions would help. If there are any docs on this, that would
> > be great too.
> 
> Probably the PV route, for dom0 and domU. Really most things you want
> to do, the PV route is going to be the right way (unless you are
> PVHVM'ing certain things, e.g., like using EPT assistance for
> pagetable handling).
> 
>  -- Keir

Thanks Keir. Just to confirm, the hybrid should continue to request
iopl of 1, right?

Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:19:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKXE-0006Oe-GV; Thu, 09 Feb 2012 03:19: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 1RvKXC-0006OZ-Rf
	for Xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:18:59 +0000
Received: from [85.158.139.83:28613] by server-5.bemta-5.messagelabs.com id
	0B/86-03847-22B333F4; Thu, 09 Feb 2012 03:18:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328757536!14305420!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16260 invoked from network); 9 Feb 2012 03:18:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 03:18:57 -0000
Received: by iaeh11 with SMTP id h11so4214087iae.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 19:18:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=uIpAg4RvIZtAFd0jriyEFlrbrtrU+ljfS2EKiPI/sQk=;
	b=ttSYMYXY/JEQ8rH9TW9MBMeLBDm7VTN8mG8jQc3l8H41ubJs/qigzy1AnabvpeAFuF
	FcPkLrvgQYaQ4oBc17eA69Btkc9huSFm0JviSNMMRXnuadMMSEDvNITFxh5z+QKvWP1C
	8imhVbCb6ULFP3XKdtruooKS/9zdrJj1mLyuw=
Received: by 10.42.46.76 with SMTP id j12mr5420icf.22.1328757535612;
	Wed, 08 Feb 2012 19:18:55 -0800 (PST)
Received: from [101.1.150.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id va6sm3109590igc.4.2012.02.08.19.18.51
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 19:18:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 19:18:45 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <CB587B15.2AB43%keir.xen@gmail.com>
Thread-Topic: [help]: handling IO instructions for hybrid
Thread-Index: Aczm2YfyOlytvRMzVU+ba2EP+w3/+w==
In-Reply-To: <20120208181720.377bb098@mantra.us.oracle.com>
Mime-version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 18:17, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> On Mon, 06 Feb 2012 19:41:23 +0000
> Keir Fraser <keir.xen@gmail.com> wrote:
> 
>> On 07/02/2012 02:26, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
>>> 
>>> I am figuring io access for hybrid guests, dom0 and domU. I see
>>> that there are two ways: PV -> emulate_privileged_op(), or hvm
>>> handles via handle_mmio()/handle_pio(). I am not familiar with
>>> either one, and would help me lot if anybody expert in that can
>>> suggest which way hybrid should go, both dom0 and domU. Any
>>> suggestions would help. If there are any docs on this, that would
>>> be great too.
>> 
>> Probably the PV route, for dom0 and domU. Really most things you want
>> to do, the PV route is going to be the right way (unless you are
>> PVHVM'ing certain things, e.g., like using EPT assistance for
>> pagetable handling).
>> 
>>  -- Keir
> 
> Thanks Keir. Just to confirm, the hybrid should continue to request
> iopl of 1, right?

I'm not sure it matters since the hybrid guest runs in ring 0 of non-root
context I believe? Since ring 1 is in that case unused, it doesn't matter
whether iopl is 0 or 1.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:19:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKXE-0006Oe-GV; Thu, 09 Feb 2012 03:19: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 1RvKXC-0006OZ-Rf
	for Xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:18:59 +0000
Received: from [85.158.139.83:28613] by server-5.bemta-5.messagelabs.com id
	0B/86-03847-22B333F4; Thu, 09 Feb 2012 03:18:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328757536!14305420!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16260 invoked from network); 9 Feb 2012 03:18:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 03:18:57 -0000
Received: by iaeh11 with SMTP id h11so4214087iae.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 19:18:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=uIpAg4RvIZtAFd0jriyEFlrbrtrU+ljfS2EKiPI/sQk=;
	b=ttSYMYXY/JEQ8rH9TW9MBMeLBDm7VTN8mG8jQc3l8H41ubJs/qigzy1AnabvpeAFuF
	FcPkLrvgQYaQ4oBc17eA69Btkc9huSFm0JviSNMMRXnuadMMSEDvNITFxh5z+QKvWP1C
	8imhVbCb6ULFP3XKdtruooKS/9zdrJj1mLyuw=
Received: by 10.42.46.76 with SMTP id j12mr5420icf.22.1328757535612;
	Wed, 08 Feb 2012 19:18:55 -0800 (PST)
Received: from [101.1.150.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id va6sm3109590igc.4.2012.02.08.19.18.51
	(version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 19:18:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 08 Feb 2012 19:18:45 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <CB587B15.2AB43%keir.xen@gmail.com>
Thread-Topic: [help]: handling IO instructions for hybrid
Thread-Index: Aczm2YfyOlytvRMzVU+ba2EP+w3/+w==
In-Reply-To: <20120208181720.377bb098@mantra.us.oracle.com>
Mime-version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [help]: handling IO instructions for hybrid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 18:17, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> On Mon, 06 Feb 2012 19:41:23 +0000
> Keir Fraser <keir.xen@gmail.com> wrote:
> 
>> On 07/02/2012 02:26, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
>>> 
>>> I am figuring io access for hybrid guests, dom0 and domU. I see
>>> that there are two ways: PV -> emulate_privileged_op(), or hvm
>>> handles via handle_mmio()/handle_pio(). I am not familiar with
>>> either one, and would help me lot if anybody expert in that can
>>> suggest which way hybrid should go, both dom0 and domU. Any
>>> suggestions would help. If there are any docs on this, that would
>>> be great too.
>> 
>> Probably the PV route, for dom0 and domU. Really most things you want
>> to do, the PV route is going to be the right way (unless you are
>> PVHVM'ing certain things, e.g., like using EPT assistance for
>> pagetable handling).
>> 
>>  -- Keir
> 
> Thanks Keir. Just to confirm, the hybrid should continue to request
> iopl of 1, right?

I'm not sure it matters since the hybrid guest runs in ring 0 of non-root
context I believe? Since ring 1 is in that case unused, it doesn't matter
whether iopl is 0 or 1.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:31:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03: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.xensource.com>)
	id 1RvKiP-0006ZY-PE; Thu, 09 Feb 2012 03:30:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKiN-0006ZT-R5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:30:32 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328758224!12065905!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12393 invoked from network); 9 Feb 2012 03:30:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 03:30:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193UMlc026432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:30:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q193UKPC020739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:30:21 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
	q193UKt0004293; Wed, 8 Feb 2012 21:30:20 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:30:19 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:30:50 +0800
Message-Id: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F333DCF.0117,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 0/5] xen: patches for supporting efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

The following patches introduce and implement efi support in dom0.
The efi memory is owned by Xen and efi run-time service can not be called 
directly in dom0, so a new efi driver is needed by Xen efi. 
These patches are based on v3.3.0-rc2+. 

Descriptions for these patches:

The efi public functions are changed to function pointers in efi_init_funcs 
struct. They act as efi generic functions as default. 
As a benefit from this change, we can register xen efi init func. 

In order to add xen efi video support, it is required to add xen-efi's 
new video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga 
and set the video type to VIDEO_TYPE_EFI to enable efi video mode. 

I have tested this patch on Dell Opti 790.

Xen efi boot support is added by Jan Beulich, more detail information can be 
gotten from the url: 
http://wiki.xen.org/xenwiki/XenParavirtOps, search "efi" in the page.

The example of config file for efi boot:
kernel=vmlinuz-3.3.0-rc2+ root=xx ro console=tty0
ramdisk=initramfs-3.3.0-rc2+.img
video=gfx-x.0 

The detailed test which i have done: 
First, Check efifb driver work well or not and check the kernel messesge ro
see the follow info:
[    0.576705] efifb: probing for efifb
[    0.577357] efifb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 3752k, total 65472k
[    0.577360] efifb: mode is 800x600x32, linelength=3200, pages=1
[    0.577362] efifb: scrolling: redraw
[    0.577364] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 

Second, Check efi systab and variable is work well or not. 
cat the information in /sys/firmware/efi to check the efi systab and variable 
is right or not. 
 
Third, Run Linux firmware testing tools which is downloaded from this Url.
http://linuxfirmwarekit.org/download.php 

Tang Liang (4):
      EFI: Provide registration for efi_init.. etc efi public function
      EFI:  add efi driver for Xen efi
      Xen efi: Add xen efi enabled detect
      Xen vga: add the xen efi video mode support


 arch/x86/platform/efi/Makefile   |    2 +-
 arch/x86/platform/efi/efi-xen.c  |  460 ++++++++++++++++++++++++++++++++++++++
 arch/x86/platform/efi/efi.c      |   63 +++++-
 arch/x86/xen/enlighten.c         |    3 +
 arch/x86/xen/vga.c               |    7 +
 include/linux/efi.h              |   14 +-
 include/xen/interface/platform.h |  122 ++++++++++
 include/xen/interface/xen.h      |    1 +
 8 files changed, 665 insertions(+), 7 deletions(-)

Thanks
Liang.
-- 
1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:31:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03: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.xensource.com>)
	id 1RvKiP-0006ZY-PE; Thu, 09 Feb 2012 03:30:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKiN-0006ZT-R5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:30:32 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328758224!12065905!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12393 invoked from network); 9 Feb 2012 03:30:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 03:30:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193UMlc026432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:30:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q193UKPC020739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:30:21 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
	q193UKt0004293; Wed, 8 Feb 2012 21:30:20 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:30:19 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:30:50 +0800
Message-Id: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F333DCF.0117,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 0/5] xen: patches for supporting efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

The following patches introduce and implement efi support in dom0.
The efi memory is owned by Xen and efi run-time service can not be called 
directly in dom0, so a new efi driver is needed by Xen efi. 
These patches are based on v3.3.0-rc2+. 

Descriptions for these patches:

The efi public functions are changed to function pointers in efi_init_funcs 
struct. They act as efi generic functions as default. 
As a benefit from this change, we can register xen efi init func. 

In order to add xen efi video support, it is required to add xen-efi's 
new video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga 
and set the video type to VIDEO_TYPE_EFI to enable efi video mode. 

I have tested this patch on Dell Opti 790.

Xen efi boot support is added by Jan Beulich, more detail information can be 
gotten from the url: 
http://wiki.xen.org/xenwiki/XenParavirtOps, search "efi" in the page.

The example of config file for efi boot:
kernel=vmlinuz-3.3.0-rc2+ root=xx ro console=tty0
ramdisk=initramfs-3.3.0-rc2+.img
video=gfx-x.0 

The detailed test which i have done: 
First, Check efifb driver work well or not and check the kernel messesge ro
see the follow info:
[    0.576705] efifb: probing for efifb
[    0.577357] efifb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 3752k, total 65472k
[    0.577360] efifb: mode is 800x600x32, linelength=3200, pages=1
[    0.577362] efifb: scrolling: redraw
[    0.577364] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 

Second, Check efi systab and variable is work well or not. 
cat the information in /sys/firmware/efi to check the efi systab and variable 
is right or not. 
 
Third, Run Linux firmware testing tools which is downloaded from this Url.
http://linuxfirmwarekit.org/download.php 

Tang Liang (4):
      EFI: Provide registration for efi_init.. etc efi public function
      EFI:  add efi driver for Xen efi
      Xen efi: Add xen efi enabled detect
      Xen vga: add the xen efi video mode support


 arch/x86/platform/efi/Makefile   |    2 +-
 arch/x86/platform/efi/efi-xen.c  |  460 ++++++++++++++++++++++++++++++++++++++
 arch/x86/platform/efi/efi.c      |   63 +++++-
 arch/x86/xen/enlighten.c         |    3 +
 arch/x86/xen/vga.c               |    7 +
 include/linux/efi.h              |   14 +-
 include/xen/interface/platform.h |  122 ++++++++++
 include/xen/interface/xen.h      |    1 +
 8 files changed, 665 insertions(+), 7 deletions(-)

Thanks
Liang.
-- 
1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:32:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03: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.xensource.com>)
	id 1RvKk6-0006dg-Er; Thu, 09 Feb 2012 03:32:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKk5-0006dL-C5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:32:17 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328758329!13526509!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25475 invoked from network); 9 Feb 2012 03:32:10 -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; 9 Feb 2012 03:32:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193W71U027964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:32:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q193W6FI022378
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:32:06 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
	q193W5ax023509; Wed, 8 Feb 2012 21:32:06 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:32:05 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:32:08 +0800
Message-Id: <1328758328-24156-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F333E38.0040,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 1/5] EFI: Provide registration for efi_init..
	etc efi public function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The efi public functions are changed to function pointer in efi_init_funcs
struct.
They act as efi generic functions as default.
As a benefit from this change, we can register xen efi init func.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/efi.c |   65 +++++++++++++++++++++++++++++++++++++++---
 include/linux/efi.h         |   12 +++++++-
 2 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 4cf9bd0..d567e29 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -50,6 +50,23 @@
 #define PFX 		"EFI: "
 
 int efi_enabled;
+
+static void efi_init_generic(void);
+
+static void efi_enter_virtual_mode_generic(void);
+static u32 efi_mem_type_generic(unsigned long phys_addr);
+static u64 efi_mem_attributes_generic(unsigned long phys_addr);
+
+struct efi_init_funcs efi_generic_funcs = {
+	.__efi_init		     = efi_init_generic,
+	.__efi_reserve_boot_services = efi_reserve_boot_services_generic,
+	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_generic,
+	.__efi_mem_type		     = efi_mem_type_generic,
+	.__efi_mem_attributes	     = efi_mem_attributes_generic
+};
+
+struct efi_init_funcs *efi_override_funcs =  &efi_generic_funcs;
+
 EXPORT_SYMBOL(efi_enabled);
 
 struct efi __read_mostly efi = {
@@ -376,7 +393,7 @@ static void __init print_efi_memmap(void)
 }
 #endif  /*  EFI_DEBUG  */
 
-void __init efi_reserve_boot_services(void)
+static void efi_reserve_boot_services_generic(void)
 {
 	void *p;
 
@@ -429,7 +446,7 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
-void __init efi_init(void)
+static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
 	efi_runtime_services_t *runtime;
@@ -618,7 +635,7 @@ static void __init runtime_code_page_mkexec(void)
  * This enables the runtime services to be called without having to
  * thunk back into physical mode for every invocation.
  */
-void __init efi_enter_virtual_mode(void)
+static void efi_enter_virtual_mode_generic(void)
 {
 	efi_memory_desc_t *md, *prev_md = NULL;
 	efi_status_t status;
@@ -752,7 +769,7 @@ void __init efi_enter_virtual_mode(void)
 /*
  * Convenience functions to obtain memory types and attributes
  */
-u32 efi_mem_type(unsigned long phys_addr)
+static u32 efi_mem_type_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -767,7 +784,7 @@ u32 efi_mem_type(unsigned long phys_addr)
 	return 0;
 }
 
-u64 efi_mem_attributes(unsigned long phys_addr)
+static u64 efi_mem_attributes_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -781,3 +798,41 @@ u64 efi_mem_attributes(unsigned long phys_addr)
 	}
 	return 0;
 }
+
+void efi_init_function_register(struct efi_init_funcs *funcs)
+{
+	efi_override_funcs = funcs;
+}
+
+void __init efi_init(void)
+{
+	if (efi_override_funcs->__efi_init)
+		efi_override_funcs->__efi_init();
+}
+
+void __init efi_reserve_boot_services(void)
+{
+	if (efi_override_funcs->__efi_reserve_boot_services)
+		efi_override_funcs->__efi_reserve_boot_services();
+}
+
+void __init efi_enter_virtual_mode(void)
+{
+	if (efi_override_funcs->__efi_enter_virtual_mode)
+		efi_override_funcs->__efi_enter_virtual_mode();
+}
+
+
+u32 efi_mem_type(unsigned long phys_addr)
+{
+	if (efi_override_funcs->__efi_mem_type)
+		return efi_override_funcs->__efi_mem_type(phys_addr);
+	return EFI_INVALID_TYPE;
+}
+
+u64 efi_mem_attributes(unsigned long phys_addr)
+{
+	if (efi_override_funcs->__efi_mem_attributes)
+		return efi_override_funcs->__efi_mem_attributes(phys_addr);
+	return EFI_INVALID_ATTRIBUTE;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 37c3007..62e0a1f 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -79,8 +79,9 @@ typedef	struct {
 #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
 #define EFI_PAL_CODE			13
 #define EFI_MAX_MEMORY_TYPE		14
-
+#define EFI_INVALID_TYPE		0xffffffff
 /* Attribute values: */
+#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid attribute*/
 #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
@@ -434,6 +435,14 @@ extern struct efi {
 	efi_set_virtual_address_map_t *set_virtual_address_map;
 } efi;
 
+struct efi_init_funcs {
+	void (*__efi_init)(void);
+	void (*__efi_reserve_boot_services)(void);
+	void (*__efi_enter_virtual_mode)(void);
+	u32 (*__efi_mem_type)(unsigned long phys_addr);
+	u64 (*__efi_mem_attributes)(unsigned long phys_addr);
+};
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
@@ -464,6 +473,7 @@ extern unsigned long efi_get_time(void);
 extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
+extern void efi_init_function_register(struct efi_init_funcs *funcs);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:32:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03: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.xensource.com>)
	id 1RvKk6-0006dg-Er; Thu, 09 Feb 2012 03:32:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKk5-0006dL-C5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:32:17 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328758329!13526509!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25475 invoked from network); 9 Feb 2012 03:32:10 -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; 9 Feb 2012 03:32:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193W71U027964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:32:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q193W6FI022378
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:32:06 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
	q193W5ax023509; Wed, 8 Feb 2012 21:32:06 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:32:05 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:32:08 +0800
Message-Id: <1328758328-24156-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F333E38.0040,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 1/5] EFI: Provide registration for efi_init..
	etc efi public function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The efi public functions are changed to function pointer in efi_init_funcs
struct.
They act as efi generic functions as default.
As a benefit from this change, we can register xen efi init func.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/efi.c |   65 +++++++++++++++++++++++++++++++++++++++---
 include/linux/efi.h         |   12 +++++++-
 2 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 4cf9bd0..d567e29 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -50,6 +50,23 @@
 #define PFX 		"EFI: "
 
 int efi_enabled;
+
+static void efi_init_generic(void);
+
+static void efi_enter_virtual_mode_generic(void);
+static u32 efi_mem_type_generic(unsigned long phys_addr);
+static u64 efi_mem_attributes_generic(unsigned long phys_addr);
+
+struct efi_init_funcs efi_generic_funcs = {
+	.__efi_init		     = efi_init_generic,
+	.__efi_reserve_boot_services = efi_reserve_boot_services_generic,
+	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_generic,
+	.__efi_mem_type		     = efi_mem_type_generic,
+	.__efi_mem_attributes	     = efi_mem_attributes_generic
+};
+
+struct efi_init_funcs *efi_override_funcs =  &efi_generic_funcs;
+
 EXPORT_SYMBOL(efi_enabled);
 
 struct efi __read_mostly efi = {
@@ -376,7 +393,7 @@ static void __init print_efi_memmap(void)
 }
 #endif  /*  EFI_DEBUG  */
 
-void __init efi_reserve_boot_services(void)
+static void efi_reserve_boot_services_generic(void)
 {
 	void *p;
 
@@ -429,7 +446,7 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
-void __init efi_init(void)
+static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
 	efi_runtime_services_t *runtime;
@@ -618,7 +635,7 @@ static void __init runtime_code_page_mkexec(void)
  * This enables the runtime services to be called without having to
  * thunk back into physical mode for every invocation.
  */
-void __init efi_enter_virtual_mode(void)
+static void efi_enter_virtual_mode_generic(void)
 {
 	efi_memory_desc_t *md, *prev_md = NULL;
 	efi_status_t status;
@@ -752,7 +769,7 @@ void __init efi_enter_virtual_mode(void)
 /*
  * Convenience functions to obtain memory types and attributes
  */
-u32 efi_mem_type(unsigned long phys_addr)
+static u32 efi_mem_type_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -767,7 +784,7 @@ u32 efi_mem_type(unsigned long phys_addr)
 	return 0;
 }
 
-u64 efi_mem_attributes(unsigned long phys_addr)
+static u64 efi_mem_attributes_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -781,3 +798,41 @@ u64 efi_mem_attributes(unsigned long phys_addr)
 	}
 	return 0;
 }
+
+void efi_init_function_register(struct efi_init_funcs *funcs)
+{
+	efi_override_funcs = funcs;
+}
+
+void __init efi_init(void)
+{
+	if (efi_override_funcs->__efi_init)
+		efi_override_funcs->__efi_init();
+}
+
+void __init efi_reserve_boot_services(void)
+{
+	if (efi_override_funcs->__efi_reserve_boot_services)
+		efi_override_funcs->__efi_reserve_boot_services();
+}
+
+void __init efi_enter_virtual_mode(void)
+{
+	if (efi_override_funcs->__efi_enter_virtual_mode)
+		efi_override_funcs->__efi_enter_virtual_mode();
+}
+
+
+u32 efi_mem_type(unsigned long phys_addr)
+{
+	if (efi_override_funcs->__efi_mem_type)
+		return efi_override_funcs->__efi_mem_type(phys_addr);
+	return EFI_INVALID_TYPE;
+}
+
+u64 efi_mem_attributes(unsigned long phys_addr)
+{
+	if (efi_override_funcs->__efi_mem_attributes)
+		return efi_override_funcs->__efi_mem_attributes(phys_addr);
+	return EFI_INVALID_ATTRIBUTE;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 37c3007..62e0a1f 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -79,8 +79,9 @@ typedef	struct {
 #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
 #define EFI_PAL_CODE			13
 #define EFI_MAX_MEMORY_TYPE		14
-
+#define EFI_INVALID_TYPE		0xffffffff
 /* Attribute values: */
+#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid attribute*/
 #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
@@ -434,6 +435,14 @@ extern struct efi {
 	efi_set_virtual_address_map_t *set_virtual_address_map;
 } efi;
 
+struct efi_init_funcs {
+	void (*__efi_init)(void);
+	void (*__efi_reserve_boot_services)(void);
+	void (*__efi_enter_virtual_mode)(void);
+	u32 (*__efi_mem_type)(unsigned long phys_addr);
+	u64 (*__efi_mem_attributes)(unsigned long phys_addr);
+};
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
@@ -464,6 +473,7 @@ extern unsigned long efi_get_time(void);
 extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
+extern void efi_init_function_register(struct efi_init_funcs *funcs);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:33:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKkZ-0006ff-3j; Thu, 09 Feb 2012 03:32:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKkX-0006fL-5O
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:32:45 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328758357!12597033!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxMzM3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 9 Feb 2012 03:32:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 03:32:38 -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 q193WYFb028696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:32:36 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q193WXS7019580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:32:34 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
	q193WXYf013178; Wed, 8 Feb 2012 21:32:33 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:32:33 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:32:52 +0800
Message-Id: <1328758372-24202-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F333E54.0045,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 2/5] EFI: seperate get efi table info code to
	single function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Seperate get efi table info code to generic function,
xen efi driver will call it too.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Suggested-by:: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/platform/efi/efi.c |   77 ++++++++++++++++++++++++-------------------
 include/linux/efi.h         |    2 +
 2 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index d567e29..d7b19ee 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -446,6 +446,47 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
+void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			struct efi *efi_t)
+{
+	int i;
+
+	printk(KERN_INFO);
+	for (i = 0; i < nr_tables; i++) {
+		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
+			efi_t->mps = config_tables[i].table;
+			printk(" MPS=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_20_TABLE_GUID)) {
+			efi_t->acpi20 = config_tables[i].table;
+			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_TABLE_GUID)) {
+			efi_t->acpi = config_tables[i].table;
+			printk(" ACPI=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					SMBIOS_TABLE_GUID)) {
+			efi_t->smbios = config_tables[i].table;
+			printk(" SMBIOS=0x%lx ", config_tables[i].table);
+#ifdef CONFIG_X86_UV
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UV_SYSTEM_TABLE_GUID)) {
+			efi_t->uv_systab = config_tables[i].table;
+			printk(" UVsystab=0x%lx ", config_tables[i].table);
+#endif
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					HCDP_TABLE_GUID)) {
+			efi_t->hcdp = config_tables[i].table;
+			printk(" HCDP=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UGA_IO_PROTOCOL_GUID)) {
+			efi_t->uga = config_tables[i].table;
+			printk(" UGA=0x%lx ", config_tables[i].table);
+		}
+	}
+	printk("\n");
+}
+
 static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
@@ -507,40 +548,8 @@ static void efi_init_generic(void)
 	if (config_tables == NULL)
 		printk(KERN_ERR "Could not map EFI Configuration Table!\n");
 
-	printk(KERN_INFO);
-	for (i = 0; i < efi.systab->nr_tables; i++) {
-		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
-			efi.mps = config_tables[i].table;
-			printk(" MPS=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_20_TABLE_GUID)) {
-			efi.acpi20 = config_tables[i].table;
-			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_TABLE_GUID)) {
-			efi.acpi = config_tables[i].table;
-			printk(" ACPI=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					SMBIOS_TABLE_GUID)) {
-			efi.smbios = config_tables[i].table;
-			printk(" SMBIOS=0x%lx ", config_tables[i].table);
-#ifdef CONFIG_X86_UV
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UV_SYSTEM_TABLE_GUID)) {
-			efi.uv_systab = config_tables[i].table;
-			printk(" UVsystab=0x%lx ", config_tables[i].table);
-#endif
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					HCDP_TABLE_GUID)) {
-			efi.hcdp = config_tables[i].table;
-			printk(" HCDP=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UGA_IO_PROTOCOL_GUID)) {
-			efi.uga = config_tables[i].table;
-			printk(" UGA=0x%lx ", config_tables[i].table);
-		}
-	}
-	printk("\n");
+	get_efi_table_info(config_tables, efi.systab->nr_tables, &efi);
+
 	early_iounmap(config_tables,
 			  efi.systab->nr_tables * sizeof(efi_config_table_t));
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 62e0a1f..633371c 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -474,6 +474,8 @@ extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
 extern void efi_init_function_register(struct efi_init_funcs *funcs);
+extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			       struct efi *efi_t);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:33:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKkZ-0006ff-3j; Thu, 09 Feb 2012 03:32:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKkX-0006fL-5O
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:32:45 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328758357!12597033!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxMzM3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30607 invoked from network); 9 Feb 2012 03:32:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 03:32:38 -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 q193WYFb028696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:32:36 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q193WXS7019580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:32:34 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
	q193WXYf013178; Wed, 8 Feb 2012 21:32:33 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:32:33 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:32:52 +0800
Message-Id: <1328758372-24202-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F333E54.0045,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 2/5] EFI: seperate get efi table info code to
	single function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Seperate get efi table info code to generic function,
xen efi driver will call it too.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Suggested-by:: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/platform/efi/efi.c |   77 ++++++++++++++++++++++++-------------------
 include/linux/efi.h         |    2 +
 2 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index d567e29..d7b19ee 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -446,6 +446,47 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
+void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			struct efi *efi_t)
+{
+	int i;
+
+	printk(KERN_INFO);
+	for (i = 0; i < nr_tables; i++) {
+		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
+			efi_t->mps = config_tables[i].table;
+			printk(" MPS=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_20_TABLE_GUID)) {
+			efi_t->acpi20 = config_tables[i].table;
+			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_TABLE_GUID)) {
+			efi_t->acpi = config_tables[i].table;
+			printk(" ACPI=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					SMBIOS_TABLE_GUID)) {
+			efi_t->smbios = config_tables[i].table;
+			printk(" SMBIOS=0x%lx ", config_tables[i].table);
+#ifdef CONFIG_X86_UV
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UV_SYSTEM_TABLE_GUID)) {
+			efi_t->uv_systab = config_tables[i].table;
+			printk(" UVsystab=0x%lx ", config_tables[i].table);
+#endif
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					HCDP_TABLE_GUID)) {
+			efi_t->hcdp = config_tables[i].table;
+			printk(" HCDP=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UGA_IO_PROTOCOL_GUID)) {
+			efi_t->uga = config_tables[i].table;
+			printk(" UGA=0x%lx ", config_tables[i].table);
+		}
+	}
+	printk("\n");
+}
+
 static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
@@ -507,40 +548,8 @@ static void efi_init_generic(void)
 	if (config_tables == NULL)
 		printk(KERN_ERR "Could not map EFI Configuration Table!\n");
 
-	printk(KERN_INFO);
-	for (i = 0; i < efi.systab->nr_tables; i++) {
-		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
-			efi.mps = config_tables[i].table;
-			printk(" MPS=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_20_TABLE_GUID)) {
-			efi.acpi20 = config_tables[i].table;
-			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_TABLE_GUID)) {
-			efi.acpi = config_tables[i].table;
-			printk(" ACPI=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					SMBIOS_TABLE_GUID)) {
-			efi.smbios = config_tables[i].table;
-			printk(" SMBIOS=0x%lx ", config_tables[i].table);
-#ifdef CONFIG_X86_UV
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UV_SYSTEM_TABLE_GUID)) {
-			efi.uv_systab = config_tables[i].table;
-			printk(" UVsystab=0x%lx ", config_tables[i].table);
-#endif
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					HCDP_TABLE_GUID)) {
-			efi.hcdp = config_tables[i].table;
-			printk(" HCDP=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UGA_IO_PROTOCOL_GUID)) {
-			efi.uga = config_tables[i].table;
-			printk(" UGA=0x%lx ", config_tables[i].table);
-		}
-	}
-	printk("\n");
+	get_efi_table_info(config_tables, efi.systab->nr_tables, &efi);
+
 	early_iounmap(config_tables,
 			  efi.systab->nr_tables * sizeof(efi_config_table_t));
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 62e0a1f..633371c 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -474,6 +474,8 @@ extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
 extern void efi_init_function_register(struct efi_init_funcs *funcs);
+extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			       struct efi *efi_t);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:33:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKkr-0006hZ-CD; Thu, 09 Feb 2012 03:33:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKko-0006ge-S0
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:33:03 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328758375!13526561!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxMzM3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26719 invoked from network); 9 Feb 2012 03:32:56 -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; 9 Feb 2012 03:32:56 -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 q193WqgY028838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:32: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
	q193WpwM023107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:32:52 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
	q193Wp2q005559; Wed, 8 Feb 2012 21:32:51 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:32:51 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:33:21 +0800
Message-Id: <1328758401-24258-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F333E66.009F,ss=1,re=-2.300,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The efi memory is owned by Xen and efi run-time service can not be called
directly,so a new efi driver is needed by Xen efi.
We call efi run-time service through the Xen in Xen efi driver.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/Makefile   |    3 +
 arch/x86/platform/efi/efi-xen.c  |  432 ++++++++++++++++++++++++++++++++++++++
 include/linux/efi.h              |    1 +
 include/xen/interface/platform.h |  122 +++++++++++
 4 files changed, 558 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/platform/efi/efi-xen.c

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 73b8be0..9577899 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1 +1,4 @@
 obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
+ifdef CONFIG_XEN
+obj-$(CONFIG_EFI)		+= efi-xen.o
+endif
diff --git a/arch/x86/platform/efi/efi-xen.c b/arch/x86/platform/efi/efi-xen.c
new file mode 100644
index 0000000..f4f6235
--- /dev/null
+++ b/arch/x86/platform/efi/efi-xen.c
@@ -0,0 +1,432 @@
+/*
+ * Common EFI (Extensible Firmware Interface) support functions
+ * Based on Extensible Firmware Interface Specification version 1.0
+ *
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
+ * Copyright (C) 1999-2002 Hewlett-Packard Co.
+ *	David Mosberger-Tang <davidm@hpl.hp.com>
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ * Copyright (C) 2005-2008 Intel Co.
+ *	Fenghua Yu <fenghua.yu@intel.com>
+ *	Bibo Mao <bibo.mao@intel.com>
+ *	Chandramouli Narayanan <mouli@linux.intel.com>
+ *	Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2011-2012 Oracle Co.
+ *	Liang Tang <liang.tang@oracle.com>
+ *
+ * Copied from efi_32.c to eliminate the duplicated code between EFI
+ * 32/64 support code. --ying 2007-10-26
+ *
+ * All EFI Runtime Services are not implemented yet as EFI only
+ * supports physical mode addressing on SoftSDV. This is to be fixed
+ * in a future version.  --drummond 1999-07-20
+ *
+ * Implemented EFI runtime services and virtual mode calls.  --davidm
+ *
+ * Goutham Rao: <goutham.rao@intel.com>
+ *	Skip non-WB memory and ignore empty memory ranges.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+#include <asm/setup.h>
+#include <asm/efi.h>
+#include <asm/time.h>
+#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
+#include <asm/x86_init.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define PFX		"EFI: "
+
+#define call (op.u.efi_runtime_call)
+#define DECLARE_CALL(what) \
+	struct xen_platform_op op; \
+	op.cmd = XENPF_efi_runtime_call; \
+	call.function = XEN_EFI_##what; \
+	call.misc = 0
+
+static void register_xen_efi_function(void);
+
+static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+{
+	int err;
+	DECLARE_CALL(get_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time));
+		memcpy(tm, &call.u.get_time.time, sizeof(*tm));
+	}
+
+	if (tc) {
+		tc->resolution = call.u.get_time.resolution;
+		tc->accuracy = call.u.get_time.accuracy;
+		tc->sets_to_zero = !!(call.misc &
+				      XEN_EFI_GET_TIME_SET_CLEARS_NS);
+	}
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_time(efi_time_t *tm)
+{
+	DECLARE_CALL(set_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time));
+	memcpy(&call.u.set_time, tm, sizeof(*tm));
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
+					    efi_bool_t *pending,
+					    efi_time_t *tm)
+{
+	int err;
+	DECLARE_CALL(get_wakeup_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time));
+		memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm));
+	}
+
+	if (enabled)
+		*enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED);
+
+	if (pending)
+		*pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING);
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+{
+	DECLARE_CALL(set_wakeup_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time));
+	if (enabled)
+		call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE;
+	if (tm)
+		memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm));
+	else
+		call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 *attr,
+					 unsigned long *data_size,
+					 void *data)
+{
+	int err;
+	DECLARE_CALL(get_variable);
+
+	set_xen_guest_handle(call.u.get_variable.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_variable.vendor_guid));
+	memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.get_variable.size = *data_size;
+	set_xen_guest_handle(call.u.get_variable.data, data);
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*data_size = call.u.get_variable.size;
+	*attr = call.misc; /* misc in struction is U32 variable*/
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+					      efi_char16_t *name,
+					      efi_guid_t *vendor)
+{
+	int err;
+	DECLARE_CALL(get_next_variable_name);
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+	call.u.get_next_variable_name.size = *name_size;
+	set_xen_guest_handle(call.u.get_next_variable_name.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_next_variable_name.vendor_guid));
+	memcpy(&call.u.get_next_variable_name.vendor_guid, vendor,
+	       sizeof(*vendor));
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*name_size = call.u.get_next_variable_name.size;
+	memcpy(vendor, &call.u.get_next_variable_name.vendor_guid,
+	       sizeof(*vendor));
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 attr,
+					 unsigned long data_size,
+					 void *data)
+{
+	DECLARE_CALL(set_variable);
+
+	set_xen_guest_handle(call.u.set_variable.name, name);
+	call.misc = attr;
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.set_variable.vendor_guid));
+	memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.set_variable.size = data_size;
+	set_xen_guest_handle(call.u.set_variable.data, data);
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_variable_info(u32 attr,
+						u64 *storage_space,
+						u64 *remaining_space,
+						u64 *max_variable_size)
+{
+	int err;
+	DECLARE_CALL(query_variable_info);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*storage_space = call.u.query_variable_info.max_store_size;
+	*remaining_space = call.u.query_variable_info.remain_store_size;
+	*max_variable_size = call.u.query_variable_info.max_size;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+{
+	int err;
+	DECLARE_CALL(get_next_high_monotonic_count);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*count = call.misc;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+					   unsigned long count,
+					   unsigned long sg_list)
+{
+	DECLARE_CALL(update_capsule);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.update_capsule.capsule_header_array,
+			     capsules);
+	call.u.update_capsule.capsule_count = count;
+	call.u.update_capsule.sg_list = sg_list;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+					       unsigned long count,
+					       u64 *max_size,
+					       int *reset_type)
+{
+	int err;
+	DECLARE_CALL(query_capsule_capabilities);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.query_capsule_capabilities.
+		capsule_header_array, capsules);
+	call.u.query_capsule_capabilities.capsule_count = count;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*max_size = call.u.query_capsule_capabilities.max_capsule_size;
+	*reset_type = call.u.query_capsule_capabilities.reset_type;
+
+	return call.status;
+}
+
+#undef DECLARE_CALL
+#undef call
+
+struct efi __read_mostly efi_xen = {
+	.mps                      = EFI_INVALID_TABLE_ADDR,
+	.acpi                     = EFI_INVALID_TABLE_ADDR,
+	.acpi20                   = EFI_INVALID_TABLE_ADDR,
+	.smbios                   = EFI_INVALID_TABLE_ADDR,
+	.sal_systab               = EFI_INVALID_TABLE_ADDR,
+	.boot_info                = EFI_INVALID_TABLE_ADDR,
+	.hcdp                     = EFI_INVALID_TABLE_ADDR,
+	.uga                      = EFI_INVALID_TABLE_ADDR,
+	.uv_systab                = EFI_INVALID_TABLE_ADDR,
+	.get_time                 = xen_efi_get_time,
+	.set_time                 = xen_efi_set_time,
+	.get_wakeup_time          = xen_efi_get_wakeup_time,
+	.set_wakeup_time          = xen_efi_set_wakeup_time,
+	.get_variable             = xen_efi_get_variable,
+	.get_next_variable        = xen_efi_get_next_variable,
+	.set_variable             = xen_efi_set_variable,
+	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+	.query_variable_info      = xen_efi_query_variable_info,
+	.update_capsule           = xen_efi_update_capsule,
+	.query_capsule_caps       = xen_efi_query_capsule_caps,
+};
+
+void __init xen_efi_probe(void)
+{
+	static struct xen_platform_op __initdata op = {
+		.cmd = XENPF_firmware_info,
+		.u.firmware_info = {
+			.type = XEN_FW_EFI_INFO,
+			.index = XEN_FW_EFI_CONFIG_TABLE
+		}
+	};
+
+	if (HYPERVISOR_dom0_op(&op) == 0) {
+		efi_enabled = 1;
+
+		register_xen_efi_function();
+	}
+}
+
+
+static void __init efi_init_xen(void)
+{
+	efi_config_table_t *config_tables;
+	efi_char16_t c16[100];
+	char vendor[ARRAY_SIZE(c16)] = "unknown";
+	int ret, i;
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	efi = efi_xen;
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+
+	/*
+	 * Show what we know for posterity
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+	info->vendor.bufsz = sizeof(c16);
+	set_xen_guest_handle(info->vendor.name, c16);
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret) {
+		for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i)
+			vendor[i] = c16[i];
+		vendor[i] = '\0';
+	} else
+		pr_err("Could not get the firmware vendor!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		pr_info("EFI v%u.%.02u by %s\n",
+		       info->version >> 16,
+		       info->version & 0xffff, vendor);
+	else
+		pr_err("Could not get EFI revision!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		efi.runtime_version = info->version;
+	else
+		pr_warn(PFX "Could not get runtime services revision.\n");
+
+	/*
+	 * Let's see what config tables the firmware passed to us.
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE;
+	if (HYPERVISOR_dom0_op(&op))
+		BUG();
+	config_tables = early_ioremap(
+		info->cfg.addr,
+		info->cfg.nent * sizeof(efi_config_table_t));
+	if (config_tables == NULL)
+		panic("Could not map EFI Configuration Table!\n");
+
+	get_efi_table_info(config_tables, info->cfg.nent, &efi);
+
+	early_iounmap(config_tables,
+		info->cfg.nent * sizeof(efi_config_table_t));
+
+	x86_platform.get_wallclock = efi_get_time;
+	x86_platform.set_wallclock = efi_set_rtc_mmss;
+}
+
+/*
+ * Convenience functions to obtain memory types and attributes
+ */
+static u32 efi_mem_type_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type;
+}
+
+static u64 efi_mem_attributes_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr;
+}
+
+static void efi_enter_virtual_mode_xen(void)  { };
+static void efi_reserve_boot_services_xen(void) { };
+
+struct efi_init_funcs xen_efi_funcs = {
+	.__efi_init		     = efi_init_xen,
+	.__efi_reserve_boot_services = efi_reserve_boot_services_xen,
+	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_xen,
+	.__efi_mem_type		     = efi_mem_type_xen,
+	.__efi_mem_attributes	     = efi_mem_attributes_xen
+};
+
+static void register_xen_efi_function(void)
+{
+	efi_init_function_register(&xen_efi_funcs);
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 633371c..3b26d50 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -476,6 +476,7 @@ extern struct efi_memory_map memmap;
 extern void efi_init_function_register(struct efi_init_funcs *funcs);
 extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
 			       struct efi *efi_t);
+extern void __init xen_efi_probe(void);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..77eb0fa 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -108,10 +108,112 @@ struct xenpf_platform_quirk {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
 
+#define XENPF_efi_runtime_call    49
+#define XEN_EFI_get_time                      1
+#define XEN_EFI_set_time                      2
+#define XEN_EFI_get_wakeup_time               3
+#define XEN_EFI_set_wakeup_time               4
+#define XEN_EFI_get_next_high_monotonic_count 5
+#define XEN_EFI_get_variable                  6
+#define XEN_EFI_set_variable                  7
+#define XEN_EFI_get_next_variable_name        8
+#define XEN_EFI_query_variable_info           9
+#define XEN_EFI_query_capsule_capabilities   10
+#define XEN_EFI_update_capsule               11
+
+struct xenpf_efi_runtime_call {
+	uint32_t function;
+    /*
+     * This field is generally used for per sub-function flags (defined
+     * below), except for the XEN_EFI_get_next_high_monotonic_count case,
+     * where it holds the single returned value.
+     */
+	uint32_t misc;
+	unsigned long status;
+	union {
+#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
+	struct {
+		struct xenpf_efi_time {
+			uint16_t year;
+			uint8_t month;
+			uint8_t day;
+			uint8_t hour;
+			uint8_t min;
+			uint8_t sec;
+			uint32_t ns;
+			int16_t tz;
+			uint8_t daylight;
+		} time;
+		uint32_t resolution;
+		uint32_t accuracy;
+	} get_time;
+
+	struct xenpf_efi_time set_time;
+
+#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001
+#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002
+	struct xenpf_efi_time get_wakeup_time;
+
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE      0x00000001
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002
+	struct xenpf_efi_time set_wakeup_time;
+
+#define XEN_EFI_VARIABLE_NON_VOLATILE       0x00000001
+#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
+#define XEN_EFI_VARIABLE_RUNTIME_ACCESS     0x00000004
+	struct {
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		unsigned long size;
+		GUEST_HANDLE(void) data;
+		struct xenpf_efi_guid {
+			uint32_t data1;
+			uint16_t data2;
+			uint16_t data3;
+			uint8_t data4[8];
+			} vendor_guid;
+		} get_variable, set_variable;
+
+	struct {
+		unsigned long size;
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		struct xenpf_efi_guid vendor_guid;
+		} get_next_variable_name;
+
+	struct {
+		uint32_t attr;
+		uint64_t max_store_size;
+		uint64_t remain_store_size;
+		uint64_t max_size;
+		} query_variable_info;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t max_capsule_size;
+		unsigned int reset_type;
+		} query_capsule_capabilities;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t sg_list; /* machine address */
+		} update_capsule;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call);
+
+#define  XEN_FW_EFI_VERSION        0
+#define  XEN_FW_EFI_CONFIG_TABLE   1
+#define  XEN_FW_EFI_VENDOR         2
+#define  XEN_FW_EFI_MEM_INFO       3
+#define  XEN_FW_EFI_RT_VERSION     4
+
 #define XENPF_firmware_info       50
 #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_EFI_INFO           4 /* from EFI */
+
 struct xenpf_firmware_info {
 	/* IN variables. */
 	uint32_t type;
@@ -142,6 +244,25 @@ struct xenpf_firmware_info {
 			/* must refer to 128-byte buffer */
 			GUEST_HANDLE(uchar) edid;
 		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		union xenpf_efi_info {
+			uint32_t version;
+			struct {
+				uint64_t addr;   /* EFI_CONFIGURATION_TABLE */
+				uint32_t nent;
+			} cfg;
+			struct {
+				uint32_t revision;
+				uint32_t bufsz;  /* input, in bytes */
+				GUEST_HANDLE(void) name;
+				/* UCS-2/UTF-16 string */
+				} vendor;
+			struct {
+				uint64_t addr;
+				uint64_t size;
+				uint64_t attr;
+				uint32_t type;
+				} mem;
+		} efi_info; /* XEN_FW_EFI_INFO */
 	} u;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
@@ -307,6 +428,7 @@ struct xen_platform_op {
 		struct xenpf_read_memtype      read_memtype;
 		struct xenpf_microcode_update  microcode;
 		struct xenpf_platform_quirk    platform_quirk;
+		struct xenpf_efi_runtime_call  efi_runtime_call;
 		struct xenpf_firmware_info     firmware_info;
 		struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
 		struct xenpf_change_freq       change_freq;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:33:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKkr-0006hZ-CD; Thu, 09 Feb 2012 03:33:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKko-0006ge-S0
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:33:03 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328758375!13526561!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxMzM3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26719 invoked from network); 9 Feb 2012 03:32:56 -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; 9 Feb 2012 03:32:56 -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 q193WqgY028838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:32: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
	q193WpwM023107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:32:52 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
	q193Wp2q005559; Wed, 8 Feb 2012 21:32:51 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:32:51 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:33:21 +0800
Message-Id: <1328758401-24258-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F333E66.009F,ss=1,re=-2.300,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The efi memory is owned by Xen and efi run-time service can not be called
directly,so a new efi driver is needed by Xen efi.
We call efi run-time service through the Xen in Xen efi driver.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/Makefile   |    3 +
 arch/x86/platform/efi/efi-xen.c  |  432 ++++++++++++++++++++++++++++++++++++++
 include/linux/efi.h              |    1 +
 include/xen/interface/platform.h |  122 +++++++++++
 4 files changed, 558 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/platform/efi/efi-xen.c

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 73b8be0..9577899 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1 +1,4 @@
 obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
+ifdef CONFIG_XEN
+obj-$(CONFIG_EFI)		+= efi-xen.o
+endif
diff --git a/arch/x86/platform/efi/efi-xen.c b/arch/x86/platform/efi/efi-xen.c
new file mode 100644
index 0000000..f4f6235
--- /dev/null
+++ b/arch/x86/platform/efi/efi-xen.c
@@ -0,0 +1,432 @@
+/*
+ * Common EFI (Extensible Firmware Interface) support functions
+ * Based on Extensible Firmware Interface Specification version 1.0
+ *
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
+ * Copyright (C) 1999-2002 Hewlett-Packard Co.
+ *	David Mosberger-Tang <davidm@hpl.hp.com>
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ * Copyright (C) 2005-2008 Intel Co.
+ *	Fenghua Yu <fenghua.yu@intel.com>
+ *	Bibo Mao <bibo.mao@intel.com>
+ *	Chandramouli Narayanan <mouli@linux.intel.com>
+ *	Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2011-2012 Oracle Co.
+ *	Liang Tang <liang.tang@oracle.com>
+ *
+ * Copied from efi_32.c to eliminate the duplicated code between EFI
+ * 32/64 support code. --ying 2007-10-26
+ *
+ * All EFI Runtime Services are not implemented yet as EFI only
+ * supports physical mode addressing on SoftSDV. This is to be fixed
+ * in a future version.  --drummond 1999-07-20
+ *
+ * Implemented EFI runtime services and virtual mode calls.  --davidm
+ *
+ * Goutham Rao: <goutham.rao@intel.com>
+ *	Skip non-WB memory and ignore empty memory ranges.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+#include <asm/setup.h>
+#include <asm/efi.h>
+#include <asm/time.h>
+#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
+#include <asm/x86_init.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define PFX		"EFI: "
+
+#define call (op.u.efi_runtime_call)
+#define DECLARE_CALL(what) \
+	struct xen_platform_op op; \
+	op.cmd = XENPF_efi_runtime_call; \
+	call.function = XEN_EFI_##what; \
+	call.misc = 0
+
+static void register_xen_efi_function(void);
+
+static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+{
+	int err;
+	DECLARE_CALL(get_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time));
+		memcpy(tm, &call.u.get_time.time, sizeof(*tm));
+	}
+
+	if (tc) {
+		tc->resolution = call.u.get_time.resolution;
+		tc->accuracy = call.u.get_time.accuracy;
+		tc->sets_to_zero = !!(call.misc &
+				      XEN_EFI_GET_TIME_SET_CLEARS_NS);
+	}
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_time(efi_time_t *tm)
+{
+	DECLARE_CALL(set_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time));
+	memcpy(&call.u.set_time, tm, sizeof(*tm));
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
+					    efi_bool_t *pending,
+					    efi_time_t *tm)
+{
+	int err;
+	DECLARE_CALL(get_wakeup_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time));
+		memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm));
+	}
+
+	if (enabled)
+		*enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED);
+
+	if (pending)
+		*pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING);
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+{
+	DECLARE_CALL(set_wakeup_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time));
+	if (enabled)
+		call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE;
+	if (tm)
+		memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm));
+	else
+		call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 *attr,
+					 unsigned long *data_size,
+					 void *data)
+{
+	int err;
+	DECLARE_CALL(get_variable);
+
+	set_xen_guest_handle(call.u.get_variable.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_variable.vendor_guid));
+	memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.get_variable.size = *data_size;
+	set_xen_guest_handle(call.u.get_variable.data, data);
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*data_size = call.u.get_variable.size;
+	*attr = call.misc; /* misc in struction is U32 variable*/
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+					      efi_char16_t *name,
+					      efi_guid_t *vendor)
+{
+	int err;
+	DECLARE_CALL(get_next_variable_name);
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+	call.u.get_next_variable_name.size = *name_size;
+	set_xen_guest_handle(call.u.get_next_variable_name.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_next_variable_name.vendor_guid));
+	memcpy(&call.u.get_next_variable_name.vendor_guid, vendor,
+	       sizeof(*vendor));
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*name_size = call.u.get_next_variable_name.size;
+	memcpy(vendor, &call.u.get_next_variable_name.vendor_guid,
+	       sizeof(*vendor));
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 attr,
+					 unsigned long data_size,
+					 void *data)
+{
+	DECLARE_CALL(set_variable);
+
+	set_xen_guest_handle(call.u.set_variable.name, name);
+	call.misc = attr;
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.set_variable.vendor_guid));
+	memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.set_variable.size = data_size;
+	set_xen_guest_handle(call.u.set_variable.data, data);
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_variable_info(u32 attr,
+						u64 *storage_space,
+						u64 *remaining_space,
+						u64 *max_variable_size)
+{
+	int err;
+	DECLARE_CALL(query_variable_info);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*storage_space = call.u.query_variable_info.max_store_size;
+	*remaining_space = call.u.query_variable_info.remain_store_size;
+	*max_variable_size = call.u.query_variable_info.max_size;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+{
+	int err;
+	DECLARE_CALL(get_next_high_monotonic_count);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*count = call.misc;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+					   unsigned long count,
+					   unsigned long sg_list)
+{
+	DECLARE_CALL(update_capsule);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.update_capsule.capsule_header_array,
+			     capsules);
+	call.u.update_capsule.capsule_count = count;
+	call.u.update_capsule.sg_list = sg_list;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+					       unsigned long count,
+					       u64 *max_size,
+					       int *reset_type)
+{
+	int err;
+	DECLARE_CALL(query_capsule_capabilities);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.query_capsule_capabilities.
+		capsule_header_array, capsules);
+	call.u.query_capsule_capabilities.capsule_count = count;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*max_size = call.u.query_capsule_capabilities.max_capsule_size;
+	*reset_type = call.u.query_capsule_capabilities.reset_type;
+
+	return call.status;
+}
+
+#undef DECLARE_CALL
+#undef call
+
+struct efi __read_mostly efi_xen = {
+	.mps                      = EFI_INVALID_TABLE_ADDR,
+	.acpi                     = EFI_INVALID_TABLE_ADDR,
+	.acpi20                   = EFI_INVALID_TABLE_ADDR,
+	.smbios                   = EFI_INVALID_TABLE_ADDR,
+	.sal_systab               = EFI_INVALID_TABLE_ADDR,
+	.boot_info                = EFI_INVALID_TABLE_ADDR,
+	.hcdp                     = EFI_INVALID_TABLE_ADDR,
+	.uga                      = EFI_INVALID_TABLE_ADDR,
+	.uv_systab                = EFI_INVALID_TABLE_ADDR,
+	.get_time                 = xen_efi_get_time,
+	.set_time                 = xen_efi_set_time,
+	.get_wakeup_time          = xen_efi_get_wakeup_time,
+	.set_wakeup_time          = xen_efi_set_wakeup_time,
+	.get_variable             = xen_efi_get_variable,
+	.get_next_variable        = xen_efi_get_next_variable,
+	.set_variable             = xen_efi_set_variable,
+	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+	.query_variable_info      = xen_efi_query_variable_info,
+	.update_capsule           = xen_efi_update_capsule,
+	.query_capsule_caps       = xen_efi_query_capsule_caps,
+};
+
+void __init xen_efi_probe(void)
+{
+	static struct xen_platform_op __initdata op = {
+		.cmd = XENPF_firmware_info,
+		.u.firmware_info = {
+			.type = XEN_FW_EFI_INFO,
+			.index = XEN_FW_EFI_CONFIG_TABLE
+		}
+	};
+
+	if (HYPERVISOR_dom0_op(&op) == 0) {
+		efi_enabled = 1;
+
+		register_xen_efi_function();
+	}
+}
+
+
+static void __init efi_init_xen(void)
+{
+	efi_config_table_t *config_tables;
+	efi_char16_t c16[100];
+	char vendor[ARRAY_SIZE(c16)] = "unknown";
+	int ret, i;
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	efi = efi_xen;
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+
+	/*
+	 * Show what we know for posterity
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+	info->vendor.bufsz = sizeof(c16);
+	set_xen_guest_handle(info->vendor.name, c16);
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret) {
+		for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i)
+			vendor[i] = c16[i];
+		vendor[i] = '\0';
+	} else
+		pr_err("Could not get the firmware vendor!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		pr_info("EFI v%u.%.02u by %s\n",
+		       info->version >> 16,
+		       info->version & 0xffff, vendor);
+	else
+		pr_err("Could not get EFI revision!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		efi.runtime_version = info->version;
+	else
+		pr_warn(PFX "Could not get runtime services revision.\n");
+
+	/*
+	 * Let's see what config tables the firmware passed to us.
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE;
+	if (HYPERVISOR_dom0_op(&op))
+		BUG();
+	config_tables = early_ioremap(
+		info->cfg.addr,
+		info->cfg.nent * sizeof(efi_config_table_t));
+	if (config_tables == NULL)
+		panic("Could not map EFI Configuration Table!\n");
+
+	get_efi_table_info(config_tables, info->cfg.nent, &efi);
+
+	early_iounmap(config_tables,
+		info->cfg.nent * sizeof(efi_config_table_t));
+
+	x86_platform.get_wallclock = efi_get_time;
+	x86_platform.set_wallclock = efi_set_rtc_mmss;
+}
+
+/*
+ * Convenience functions to obtain memory types and attributes
+ */
+static u32 efi_mem_type_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type;
+}
+
+static u64 efi_mem_attributes_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr;
+}
+
+static void efi_enter_virtual_mode_xen(void)  { };
+static void efi_reserve_boot_services_xen(void) { };
+
+struct efi_init_funcs xen_efi_funcs = {
+	.__efi_init		     = efi_init_xen,
+	.__efi_reserve_boot_services = efi_reserve_boot_services_xen,
+	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_xen,
+	.__efi_mem_type		     = efi_mem_type_xen,
+	.__efi_mem_attributes	     = efi_mem_attributes_xen
+};
+
+static void register_xen_efi_function(void)
+{
+	efi_init_function_register(&xen_efi_funcs);
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 633371c..3b26d50 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -476,6 +476,7 @@ extern struct efi_memory_map memmap;
 extern void efi_init_function_register(struct efi_init_funcs *funcs);
 extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
 			       struct efi *efi_t);
+extern void __init xen_efi_probe(void);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..77eb0fa 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -108,10 +108,112 @@ struct xenpf_platform_quirk {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
 
+#define XENPF_efi_runtime_call    49
+#define XEN_EFI_get_time                      1
+#define XEN_EFI_set_time                      2
+#define XEN_EFI_get_wakeup_time               3
+#define XEN_EFI_set_wakeup_time               4
+#define XEN_EFI_get_next_high_monotonic_count 5
+#define XEN_EFI_get_variable                  6
+#define XEN_EFI_set_variable                  7
+#define XEN_EFI_get_next_variable_name        8
+#define XEN_EFI_query_variable_info           9
+#define XEN_EFI_query_capsule_capabilities   10
+#define XEN_EFI_update_capsule               11
+
+struct xenpf_efi_runtime_call {
+	uint32_t function;
+    /*
+     * This field is generally used for per sub-function flags (defined
+     * below), except for the XEN_EFI_get_next_high_monotonic_count case,
+     * where it holds the single returned value.
+     */
+	uint32_t misc;
+	unsigned long status;
+	union {
+#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
+	struct {
+		struct xenpf_efi_time {
+			uint16_t year;
+			uint8_t month;
+			uint8_t day;
+			uint8_t hour;
+			uint8_t min;
+			uint8_t sec;
+			uint32_t ns;
+			int16_t tz;
+			uint8_t daylight;
+		} time;
+		uint32_t resolution;
+		uint32_t accuracy;
+	} get_time;
+
+	struct xenpf_efi_time set_time;
+
+#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001
+#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002
+	struct xenpf_efi_time get_wakeup_time;
+
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE      0x00000001
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002
+	struct xenpf_efi_time set_wakeup_time;
+
+#define XEN_EFI_VARIABLE_NON_VOLATILE       0x00000001
+#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
+#define XEN_EFI_VARIABLE_RUNTIME_ACCESS     0x00000004
+	struct {
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		unsigned long size;
+		GUEST_HANDLE(void) data;
+		struct xenpf_efi_guid {
+			uint32_t data1;
+			uint16_t data2;
+			uint16_t data3;
+			uint8_t data4[8];
+			} vendor_guid;
+		} get_variable, set_variable;
+
+	struct {
+		unsigned long size;
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		struct xenpf_efi_guid vendor_guid;
+		} get_next_variable_name;
+
+	struct {
+		uint32_t attr;
+		uint64_t max_store_size;
+		uint64_t remain_store_size;
+		uint64_t max_size;
+		} query_variable_info;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t max_capsule_size;
+		unsigned int reset_type;
+		} query_capsule_capabilities;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t sg_list; /* machine address */
+		} update_capsule;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call);
+
+#define  XEN_FW_EFI_VERSION        0
+#define  XEN_FW_EFI_CONFIG_TABLE   1
+#define  XEN_FW_EFI_VENDOR         2
+#define  XEN_FW_EFI_MEM_INFO       3
+#define  XEN_FW_EFI_RT_VERSION     4
+
 #define XENPF_firmware_info       50
 #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_EFI_INFO           4 /* from EFI */
+
 struct xenpf_firmware_info {
 	/* IN variables. */
 	uint32_t type;
@@ -142,6 +244,25 @@ struct xenpf_firmware_info {
 			/* must refer to 128-byte buffer */
 			GUEST_HANDLE(uchar) edid;
 		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		union xenpf_efi_info {
+			uint32_t version;
+			struct {
+				uint64_t addr;   /* EFI_CONFIGURATION_TABLE */
+				uint32_t nent;
+			} cfg;
+			struct {
+				uint32_t revision;
+				uint32_t bufsz;  /* input, in bytes */
+				GUEST_HANDLE(void) name;
+				/* UCS-2/UTF-16 string */
+				} vendor;
+			struct {
+				uint64_t addr;
+				uint64_t size;
+				uint64_t attr;
+				uint32_t type;
+				} mem;
+		} efi_info; /* XEN_FW_EFI_INFO */
 	} u;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
@@ -307,6 +428,7 @@ struct xen_platform_op {
 		struct xenpf_read_memtype      read_memtype;
 		struct xenpf_microcode_update  microcode;
 		struct xenpf_platform_quirk    platform_quirk;
+		struct xenpf_efi_runtime_call  efi_runtime_call;
 		struct xenpf_firmware_info     firmware_info;
 		struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
 		struct xenpf_change_freq       change_freq;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:33:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:33:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKlE-0006mJ-G0; Thu, 09 Feb 2012 03:33:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKlC-0006ln-Cv
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:33:26 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328758340!60337157!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20053 invoked from network); 9 Feb 2012 03:32:22 -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; 9 Feb 2012 03:32:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193XMtM029004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:33:23 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
	q193XLob011836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:33:22 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
	q193XL4N005800; Wed, 8 Feb 2012 21:33:21 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:33:21 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:33:51 +0800
Message-Id: <1328758431-24339-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F333E83.004D,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 5/5] Xen vga: add the xen efi video mode support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order to add xen efi video support, it is required to add xen-efi's new
video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga
and set the video type to VIDEO_TYPE_EFI to enable efi video mode.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/vga.c          |    7 +++++++
 include/xen/interface/xen.h |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/vga.c b/arch/x86/xen/vga.c
index 1cd7f4d..6722e37 100644
--- a/arch/x86/xen/vga.c
+++ b/arch/x86/xen/vga.c
@@ -35,6 +35,7 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 			info->u.text_mode_3.font_height;
 		break;
 
+	case XEN_VGATYPE_EFI_LFB:
 	case XEN_VGATYPE_VESA_LFB:
 		if (size < offsetof(struct dom0_vga_console_info,
 				    u.vesa_lfb.gbl_caps))
@@ -54,6 +55,12 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 		screen_info->blue_pos = info->u.vesa_lfb.blue_pos;
 		screen_info->rsvd_size = info->u.vesa_lfb.rsvd_size;
 		screen_info->rsvd_pos = info->u.vesa_lfb.rsvd_pos;
+
+		if (info->video_type == XEN_VGATYPE_EFI_LFB) {
+			screen_info->orig_video_isVGA = VIDEO_TYPE_EFI;
+			break;
+		}
+
 		if (size >= offsetof(struct dom0_vga_console_info,
 				     u.vesa_lfb.gbl_caps)
 		    + sizeof(info->u.vesa_lfb.gbl_caps))
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..c84ba71 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -454,6 +454,7 @@ struct dom0_vga_console_info {
 	uint8_t video_type;
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
 #define XEN_VGATYPE_VESA_LFB    0x23
+#define XEN_VGATYPE_EFI_LFB     0x70
 
 	union {
 		struct {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:33:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:33:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKlE-0006mJ-G0; Thu, 09 Feb 2012 03:33:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKlC-0006ln-Cv
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:33:26 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328758340!60337157!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20053 invoked from network); 9 Feb 2012 03:32:22 -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; 9 Feb 2012 03:32:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193XMtM029004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:33:23 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
	q193XLob011836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:33:22 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
	q193XL4N005800; Wed, 8 Feb 2012 21:33:21 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:33:21 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:33:51 +0800
Message-Id: <1328758431-24339-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F333E83.004D,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 5/5] Xen vga: add the xen efi video mode support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order to add xen efi video support, it is required to add xen-efi's new
video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga
and set the video type to VIDEO_TYPE_EFI to enable efi video mode.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/vga.c          |    7 +++++++
 include/xen/interface/xen.h |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/vga.c b/arch/x86/xen/vga.c
index 1cd7f4d..6722e37 100644
--- a/arch/x86/xen/vga.c
+++ b/arch/x86/xen/vga.c
@@ -35,6 +35,7 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 			info->u.text_mode_3.font_height;
 		break;
 
+	case XEN_VGATYPE_EFI_LFB:
 	case XEN_VGATYPE_VESA_LFB:
 		if (size < offsetof(struct dom0_vga_console_info,
 				    u.vesa_lfb.gbl_caps))
@@ -54,6 +55,12 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 		screen_info->blue_pos = info->u.vesa_lfb.blue_pos;
 		screen_info->rsvd_size = info->u.vesa_lfb.rsvd_size;
 		screen_info->rsvd_pos = info->u.vesa_lfb.rsvd_pos;
+
+		if (info->video_type == XEN_VGATYPE_EFI_LFB) {
+			screen_info->orig_video_isVGA = VIDEO_TYPE_EFI;
+			break;
+		}
+
 		if (size >= offsetof(struct dom0_vga_console_info,
 				     u.vesa_lfb.gbl_caps)
 		    + sizeof(info->u.vesa_lfb.gbl_caps))
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..c84ba71 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -454,6 +454,7 @@ struct dom0_vga_console_info {
 	uint8_t video_type;
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
 #define XEN_VGATYPE_VESA_LFB    0x23
+#define XEN_VGATYPE_EFI_LFB     0x70
 
 	union {
 		struct {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:34:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03: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.xensource.com>)
	id 1RvKkz-0006jD-1f; Thu, 09 Feb 2012 03:33:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKkx-0006il-IU
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:33:11 +0000
Received: from [85.158.139.83:51944] by server-9.bemta-5.messagelabs.com id
	63/43-23757-67E333F4; Thu, 09 Feb 2012 03:33:10 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328758388!14306233!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8439 invoked from network); 9 Feb 2012 03:33:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 03:33:10 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193X7SD028823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:33: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
	q193X6Ni011600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:33:07 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q193X6Ej013431; Wed, 8 Feb 2012 21:33:06 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:33:06 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:33:36 +0800
Message-Id: <1328758416-24305-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F333E74.0059,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 4/5] Xen efi: Add xen efi enabled detect
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We need to use hypercall to detect the xen efi enabled or not.
If xen efi enable is set,replace the efi public function to xen efi public
function and set efi_enabled to 1 in the function efi_probe;

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..92982c1 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/efi.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -1282,6 +1283,8 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_setup_runstate_info(0);
 
+	if (xen_initial_domain())
+		xen_efi_probe();
 	/* Start the world */
 #ifdef CONFIG_X86_32
 	i386_start_kernel();
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:34:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03: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.xensource.com>)
	id 1RvKkz-0006jD-1f; Thu, 09 Feb 2012 03:33:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvKkx-0006il-IU
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:33:11 +0000
Received: from [85.158.139.83:51944] by server-9.bemta-5.messagelabs.com id
	63/43-23757-67E333F4; Thu, 09 Feb 2012 03:33:10 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328758388!14306233!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MjcxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8439 invoked from network); 9 Feb 2012 03:33:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 03:33:10 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q193X7SD028823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:33: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
	q193X6Ni011600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 03:33:07 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q193X6Ej013431; Wed, 8 Feb 2012 21:33:06 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 08 Feb 2012 19:33:06 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Thu,  9 Feb 2012 11:33:36 +0800
Message-Id: <1328758416-24305-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F333E74.0059,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 4/5] Xen efi: Add xen efi enabled detect
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We need to use hypercall to detect the xen efi enabled or not.
If xen efi enable is set,replace the efi public function to xen efi public
function and set efi_enabled to 1 in the function efi_probe;

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..92982c1 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/efi.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -1282,6 +1283,8 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_setup_runstate_info(0);
 
+	if (xen_initial_domain())
+		xen_efi_probe();
 	/* Start the world */
 #ifdef CONFIG_X86_32
 	i386_start_kernel();
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:37:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKoN-0007Jr-5L; Thu, 09 Feb 2012 03:36:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RvKoL-0007Ij-Nu
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:36:41 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328758594!10751720!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNzU3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13963 invoked from network); 9 Feb 2012 03:36:35 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 03:36:35 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Feb 2012 19:36:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122868193"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga002.fm.intel.com with ESMTP; 08 Feb 2012 19:36:32 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 9 Feb 2012 11:36:27 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 9 Feb 2012 11:36:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Thu, 9 Feb 2012 11:36:23 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
	specific MSR handling
Thread-Index: AQHM5Oz9jtXe3UuUxEynBZimYzvSnpYvBNQAgATo3bA=
Date: Thu, 9 Feb 2012 03:36:20 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644067B71@SHSMSX101.ccr.corp.intel.com>
References: <4F300E050200007800071664@nat28.tlf.novell.com>
	<CB554182.2A7AC%keir.xen@gmail.com>
In-Reply-To: <CB554182.2A7AC%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
Cc: "Nakajima, Jun" <jun.nakajima@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
 specific MSR handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also Fine to Intel, Thanks!
    Acked-by: Xiantao Zhang<xiantao.zhang@intel.com> 
Xiantao
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Keir Fraser
> Sent: Monday, February 06, 2012 4:36 PM
> To: Jan Beulich; xen-devel@lists.xensource.com
> Cc: Dugger, Donald D; Nakajima, Jun
> Subject: Re: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to
> model specific MSR handling
> 
> On 06/02/2012 16:29, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> > This is model 0x3a (decimal 58) as per the most recent SDM.
> >
> > In vPMU code, also add a forgotten earlier model.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Fine by me with an appropriate Ack from Intel.
> 
>  K.
> 
> > --- a/xen/arch/x86/acpi/cpu_idle.c
> > +++ b/xen/arch/x86/acpi/cpu_idle.c
> > @@ -106,6 +106,8 @@ static void do_get_hw_residencies(void *
> >
> >      switch ( c->x86_model )
> >      {
> > +    /* Ivy bridge */
> > +    case 0x3A:
> >      /* Sandy bridge */
> >      case 0x2A:
> >      case 0x2D:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -1751,6 +1751,8 @@ static const struct lbr_info *last_branc
> >          case 37: case 44: case 47:
> >          /* Sandy Bridge */
> >          case 42: case 45:
> > +        /* Ivy Bridge */
> > +        case 58:
> >              return nh_lbr;
> >              break;
> >          /* Atom */
> > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> > @@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
> >          case 26:
> >          case 29:
> >          case 42:
> > +        case 45:
> >          case 46:
> >          case 47:
> > +        case 58:
> >              vpmu->arch_vpmu_ops = &core2_vpmu_ops;
> >              return 0;
> >          }
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:37:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvKoN-0007Jr-5L; Thu, 09 Feb 2012 03:36:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RvKoL-0007Ij-Nu
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:36:41 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328758594!10751720!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNzU3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13963 invoked from network); 9 Feb 2012 03:36:35 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 03:36:35 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Feb 2012 19:36:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122868193"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga002.fm.intel.com with ESMTP; 08 Feb 2012 19:36:32 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 9 Feb 2012 11:36:27 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 9 Feb 2012 11:36:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Thu, 9 Feb 2012 11:36:23 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
	specific MSR handling
Thread-Index: AQHM5Oz9jtXe3UuUxEynBZimYzvSnpYvBNQAgATo3bA=
Date: Thu, 9 Feb 2012 03:36:20 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644067B71@SHSMSX101.ccr.corp.intel.com>
References: <4F300E050200007800071664@nat28.tlf.novell.com>
	<CB554182.2A7AC%keir.xen@gmail.com>
In-Reply-To: <CB554182.2A7AC%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
Cc: "Nakajima, Jun" <jun.nakajima@intel.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to model
 specific MSR handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also Fine to Intel, Thanks!
    Acked-by: Xiantao Zhang<xiantao.zhang@intel.com> 
Xiantao
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Keir Fraser
> Sent: Monday, February 06, 2012 4:36 PM
> To: Jan Beulich; xen-devel@lists.xensource.com
> Cc: Dugger, Donald D; Nakajima, Jun
> Subject: Re: [Xen-devel] [PATCH] x86: add Ivy Bridge model numbers to
> model specific MSR handling
> 
> On 06/02/2012 16:29, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> > This is model 0x3a (decimal 58) as per the most recent SDM.
> >
> > In vPMU code, also add a forgotten earlier model.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Fine by me with an appropriate Ack from Intel.
> 
>  K.
> 
> > --- a/xen/arch/x86/acpi/cpu_idle.c
> > +++ b/xen/arch/x86/acpi/cpu_idle.c
> > @@ -106,6 +106,8 @@ static void do_get_hw_residencies(void *
> >
> >      switch ( c->x86_model )
> >      {
> > +    /* Ivy bridge */
> > +    case 0x3A:
> >      /* Sandy bridge */
> >      case 0x2A:
> >      case 0x2D:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -1751,6 +1751,8 @@ static const struct lbr_info *last_branc
> >          case 37: case 44: case 47:
> >          /* Sandy Bridge */
> >          case 42: case 45:
> > +        /* Ivy Bridge */
> > +        case 58:
> >              return nh_lbr;
> >              break;
> >          /* Atom */
> > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> > @@ -623,8 +623,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
> >          case 26:
> >          case 29:
> >          case 42:
> > +        case 45:
> >          case 46:
> >          case 47:
> > +        case 58:
> >              vpmu->arch_vpmu_ops = &core2_vpmu_ops;
> >              return 0;
> >          }
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvL1B-0007eQ-I7; Thu, 09 Feb 2012 03:49:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvL1A-0007eL-CP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:49:56 +0000
Received: from [85.158.139.83:5264] by server-1.bemta-5.messagelabs.com id
	78/89-04285-362433F4; Thu, 09 Feb 2012 03:49:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328759394!14321749!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTA2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11471 invoked from network); 9 Feb 2012 03:49:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-5.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 03:49:55 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 3DDA87EC072;
	Wed,  8 Feb 2012 19:49:54 -0800 (PST)
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=kQWWfeB+9o8wOMYGLy6DFM
	kjENPnwAXL1JyS5scK4umiDmBMKn5dHmIOgAnv1Vcpw8HGQNPVuRCWTonVrob/dh
	W8QbWH+3J+6dNl3aEaHJ1x7h+3vLhWqQgQyhMhq8mdSaSLoWePfKhz1neqQfwcou
	yWxmWQYi2i99bXn1plXCE=
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=M1c/4cGhaaeX
	yygbCuC8yQnOwNg=; b=UhIE4VVL+5uW25tA2oiBqTqSaYnsIaEjKbh297S+ca5+
	WmVHZN+3kK/rtk5hgLA2oq5Sw/AIpwCYNT4nwaOvQ4bqRPXRWCM7FCA0TeZgQ8FJ
	XUTfmhyGmt1kkzBZMPCVvoBIkIjtGiSkzuqXgcDY6J/UOnzWruVsQwAHJmDQxWI=
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 63A0D7EC064; 
	Wed,  8 Feb 2012 19:49:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5c798691888303d446b0805e2cafeeaf84936844
Message-Id: <5c798691888303d446b0.1328763218@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 08 Feb 2012 23:53:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32 bits
	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/tests/Makefile                |   2 --
 tools/tests/xen-access/xen-access.c |  12 +++++++-----
 2 files changed, 7 insertions(+), 7 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/Makefile
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -11,9 +11,7 @@ ifeq ($(XEN_TARGET_ARCH),__fixme__)
 SUBDIRS-y += regression
 endif
 SUBDIRS-y += x86_emulator
-ifneq ($(XEN_TARGET_ARCH),x86_32)
 SUBDIRS-y += xen-access
-endif
 
 .PHONY: all clean install distclean
 all clean distclean: %: subdirs-%
diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -600,13 +600,13 @@ int main(int argc, char *argv[])
             case MEM_EVENT_REASON_VIOLATION:
                 rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
 
-                printf("PAGE ACCESS: %c%c%c for GFN %lx (offset %06lx) gla %016lx (vcpu %d)\n",
+                printf("PAGE ACCESS: %c%c%c for GFN %llx (offset %06llx) gla %016llx (vcpu %d)\n",
                         req.access_r ? 'r' : '-',
                         req.access_w ? 'w' : '-',
                         req.access_x ? 'x' : '-',
-                        req.gfn,
-                        req.offset,
-                        req.gla,
+                        (unsigned long long) req.gfn,
+                        (unsigned long long) req.offset,
+                        (unsigned long long) req.gla,
                         req.vcpu_id);
 
                 if ( default_access != after_first_access )
@@ -617,7 +617,9 @@ int main(int argc, char *argv[])
                 rsp.p2mt = req.p2mt;
                 break;
             case MEM_EVENT_REASON_INT3:
-                printf("INT3: rip=%016lx, gfn=%lx (vcpu %d)\n", req.gla, req.gfn,
+                printf("INT3: rip=%016llx, gfn=%llx (vcpu %d)\n", 
+                        (unsigned long long) req.gla, 
+                        (unsigned long long) req.gfn,
                         req.vcpu_id);
 
                 /* Reinject */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 03:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 03:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvL1B-0007eQ-I7; Thu, 09 Feb 2012 03:49:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvL1A-0007eL-CP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 03:49:56 +0000
Received: from [85.158.139.83:5264] by server-1.bemta-5.messagelabs.com id
	78/89-04285-362433F4; Thu, 09 Feb 2012 03:49:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328759394!14321749!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNTA2Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11471 invoked from network); 9 Feb 2012 03:49:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-5.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 03:49:55 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 3DDA87EC072;
	Wed,  8 Feb 2012 19:49:54 -0800 (PST)
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=kQWWfeB+9o8wOMYGLy6DFM
	kjENPnwAXL1JyS5scK4umiDmBMKn5dHmIOgAnv1Vcpw8HGQNPVuRCWTonVrob/dh
	W8QbWH+3J+6dNl3aEaHJ1x7h+3vLhWqQgQyhMhq8mdSaSLoWePfKhz1neqQfwcou
	yWxmWQYi2i99bXn1plXCE=
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=M1c/4cGhaaeX
	yygbCuC8yQnOwNg=; b=UhIE4VVL+5uW25tA2oiBqTqSaYnsIaEjKbh297S+ca5+
	WmVHZN+3kK/rtk5hgLA2oq5Sw/AIpwCYNT4nwaOvQ4bqRPXRWCM7FCA0TeZgQ8FJ
	XUTfmhyGmt1kkzBZMPCVvoBIkIjtGiSkzuqXgcDY6J/UOnzWruVsQwAHJmDQxWI=
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 63A0D7EC064; 
	Wed,  8 Feb 2012 19:49:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5c798691888303d446b0805e2cafeeaf84936844
Message-Id: <5c798691888303d446b0.1328763218@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 08 Feb 2012 23:53:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32 bits
	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/tests/Makefile                |   2 --
 tools/tests/xen-access/xen-access.c |  12 +++++++-----
 2 files changed, 7 insertions(+), 7 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/Makefile
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -11,9 +11,7 @@ ifeq ($(XEN_TARGET_ARCH),__fixme__)
 SUBDIRS-y += regression
 endif
 SUBDIRS-y += x86_emulator
-ifneq ($(XEN_TARGET_ARCH),x86_32)
 SUBDIRS-y += xen-access
-endif
 
 .PHONY: all clean install distclean
 all clean distclean: %: subdirs-%
diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -600,13 +600,13 @@ int main(int argc, char *argv[])
             case MEM_EVENT_REASON_VIOLATION:
                 rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
 
-                printf("PAGE ACCESS: %c%c%c for GFN %lx (offset %06lx) gla %016lx (vcpu %d)\n",
+                printf("PAGE ACCESS: %c%c%c for GFN %llx (offset %06llx) gla %016llx (vcpu %d)\n",
                         req.access_r ? 'r' : '-',
                         req.access_w ? 'w' : '-',
                         req.access_x ? 'x' : '-',
-                        req.gfn,
-                        req.offset,
-                        req.gla,
+                        (unsigned long long) req.gfn,
+                        (unsigned long long) req.offset,
+                        (unsigned long long) req.gla,
                         req.vcpu_id);
 
                 if ( default_access != after_first_access )
@@ -617,7 +617,9 @@ int main(int argc, char *argv[])
                 rsp.p2mt = req.p2mt;
                 break;
             case MEM_EVENT_REASON_INT3:
-                printf("INT3: rip=%016lx, gfn=%lx (vcpu %d)\n", req.gla, req.gfn,
+                printf("INT3: rip=%016llx, gfn=%llx (vcpu %d)\n", 
+                        (unsigned long long) req.gla, 
+                        (unsigned long long) req.gfn,
                         req.vcpu_id);
 
                 /* Reinject */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqP-000896-QN; Thu, 09 Feb 2012 04:42:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqN-00088z-MY
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328762521!62114452!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY2MzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28095 invoked from network); 9 Feb 2012 04:42:02 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:02 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5C64D45807C;
	Wed,  8 Feb 2012 20:42:49 -0800 (PST)
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=c3PoyEIrTEl+pKfaaeM1Ej
	YZjI7+77Zi1apzBxbdquC8jrX3immAXDLZTXzWG6BkxRfY6rLmZAZDWZIzf6op1Z
	lD/Io4QMYJum7/8UCFws5pCrB7e3aVOnusEq4AccIMIZJx8BF3Hf6zkkms0XRmj7
	TY22PlGVRNorv2b522CtA=
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=w9M+dCUvus1g
	Xk1ENbvCNP/4BjY=; b=XuqQllInr3Jd+sEoYOPUqwY06BKZf8HoIHW5rGPmn2nC
	70YZgaykVKj78X2DtgXLN95uXrl5m7esHw8ErhPwKhcHQVtm42KR0Ph/OG85Dhbg
	q3Dp1svelJlO34G6xG4etYhVSO0N1Ww0f+k2mBNq3kBCl+WHNs4LSVxESFqstxI=
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 901B3458079; 
	Wed,  8 Feb 2012 20:42:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:45 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 7] Synchronized p2m lookups v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v1 posted Feb 2nd 2012
<Mostly Acked-by and comments>

- patch 1:
 + Clarified comments in header regarding shadow mode
 + Clarified error checking in hap_update_paging_modes
 + Updated comment about lockng discipline between p2m and page sharing

- patch 2:
 + Fixed one instance of gfn_unlock when it should have been p2m_unlock
 + Added Acked-by

- patch 4:
 + Added comments explaining new argument to p2m_mem_access_check
 + Added Acked-by

- patch 5:
 + Added Acked-by

- Added patch 6 to the series, previously posted separately as "x86/mm:
  Refactor possibly deadlocking get_gfn calls"
 + Simplified logic of get_two_gfns
 + Made get_two_gfns struct stack vars rather than dynamically allocated

- Added patch 7 to the series, previously posted separately as "x86/mm: When
  removing/adding a page from/to the physmap, keep in mind it could be shared"
 + Added a missing p2m unlock

Description from original post follows:

Up until now, p2m lookups (get_gfn*) in the x86 architecture were not
synchronized against concurrent updates. With the addition of sharing and
paging subsystems that can dynamically modify the p2m, the need for
synchronized lookups becomes more pressing.

Without synchronized lookups, we've encountered host crashes triggered by race
conditions, particularly when exercising the sharing subsystem.

In this patch series we make p2m lookups fully synchronized. We still use a
single per-domain p2m lock (profiling work tbd may or may not indicate the need
for fine-grained locking).

We only enforce locking of p2m queries for hap-assisted domains. These are the
domains (in the case of EPT) that can exercise the paging and sharing
subsystems and thus most in need of synchronized lookups.

While the code *should* work for domains relying on shadow paging, it has not
been tested, hence we do not enable this at the moment.

Finally, the locking discipline in the PoD subsystem has been updated, since
PoD relied on some assumptions about the way the p2m lock is used.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/hap/hap.c        |    8 ++
 xen/arch/x86/mm/mm-locks.h       |   40 ++++++++-----
 xen/arch/x86/mm/p2m.c            |   21 ++++++-
 xen/include/asm-x86/mm.h         |    6 +-
 xen/include/asm-x86/p2m.h        |   47 ++++++++++------
 xen/arch/x86/mm/mem_sharing.c    |    2 -
 xen/arch/x86/mm/mm-locks.h       |    4 +-
 xen/arch/x86/mm/p2m-ept.c        |   33 +----------
 xen/arch/x86/mm/p2m-pod.c        |   14 +++-
 xen/arch/x86/mm/p2m-pt.c         |   45 ++-------------
 xen/arch/x86/mm/p2m.c            |   62 +++++++++++----------
 xen/arch/x86/mm/mm-locks.h       |   10 +++
 xen/arch/x86/mm/p2m-pod.c        |  110 +++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m-pt.c         |    1 +
 xen/arch/x86/mm/p2m.c            |    8 ++-
 xen/include/asm-x86/p2m.h        |   27 ++------
 xen/arch/x86/hvm/emulate.c       |    2 +-
 xen/arch/x86/hvm/hvm.c           |   25 ++++++--
 xen/arch/x86/mm.c                |   10 +-
 xen/arch/x86/mm/guest_walk.c     |    2 +-
 xen/arch/x86/mm/hap/guest_walk.c |    6 +-
 xen/arch/x86/mm/mem_access.c     |   10 +++
 xen/arch/x86/mm/mem_event.c      |    5 +
 xen/arch/x86/mm/p2m.c            |   52 ++++++++++--------
 xen/common/grant_table.c         |    2 +-
 xen/common/memory.c              |    2 +-
 xen/include/asm-x86/mem_access.h |    1 +
 xen/include/asm-x86/mem_event.h  |    3 +
 xen/include/asm-x86/p2m.h        |   10 ++-
 xen/arch/x86/mm/p2m.c            |    4 +-
 xen/arch/x86/hvm/emulate.c       |   33 ++++------
 xen/arch/x86/mm/mem_sharing.c    |   24 +++----
 xen/include/asm-x86/p2m.h        |   60 +++++++++++++++++++++
 xen/arch/x86/mm/p2m.c            |   26 ++++++++-
 34 files changed, 427 insertions(+), 288 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqP-000896-QN; Thu, 09 Feb 2012 04:42:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqN-00088z-MY
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328762521!62114452!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY2MzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28095 invoked from network); 9 Feb 2012 04:42:02 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:02 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5C64D45807C;
	Wed,  8 Feb 2012 20:42:49 -0800 (PST)
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=c3PoyEIrTEl+pKfaaeM1Ej
	YZjI7+77Zi1apzBxbdquC8jrX3immAXDLZTXzWG6BkxRfY6rLmZAZDWZIzf6op1Z
	lD/Io4QMYJum7/8UCFws5pCrB7e3aVOnusEq4AccIMIZJx8BF3Hf6zkkms0XRmj7
	TY22PlGVRNorv2b522CtA=
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=w9M+dCUvus1g
	Xk1ENbvCNP/4BjY=; b=XuqQllInr3Jd+sEoYOPUqwY06BKZf8HoIHW5rGPmn2nC
	70YZgaykVKj78X2DtgXLN95uXrl5m7esHw8ErhPwKhcHQVtm42KR0Ph/OG85Dhbg
	q3Dp1svelJlO34G6xG4etYhVSO0N1Ww0f+k2mBNq3kBCl+WHNs4LSVxESFqstxI=
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 901B3458079; 
	Wed,  8 Feb 2012 20:42:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:45 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 7] Synchronized p2m lookups v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v1 posted Feb 2nd 2012
<Mostly Acked-by and comments>

- patch 1:
 + Clarified comments in header regarding shadow mode
 + Clarified error checking in hap_update_paging_modes
 + Updated comment about lockng discipline between p2m and page sharing

- patch 2:
 + Fixed one instance of gfn_unlock when it should have been p2m_unlock
 + Added Acked-by

- patch 4:
 + Added comments explaining new argument to p2m_mem_access_check
 + Added Acked-by

- patch 5:
 + Added Acked-by

- Added patch 6 to the series, previously posted separately as "x86/mm:
  Refactor possibly deadlocking get_gfn calls"
 + Simplified logic of get_two_gfns
 + Made get_two_gfns struct stack vars rather than dynamically allocated

- Added patch 7 to the series, previously posted separately as "x86/mm: When
  removing/adding a page from/to the physmap, keep in mind it could be shared"
 + Added a missing p2m unlock

Description from original post follows:

Up until now, p2m lookups (get_gfn*) in the x86 architecture were not
synchronized against concurrent updates. With the addition of sharing and
paging subsystems that can dynamically modify the p2m, the need for
synchronized lookups becomes more pressing.

Without synchronized lookups, we've encountered host crashes triggered by race
conditions, particularly when exercising the sharing subsystem.

In this patch series we make p2m lookups fully synchronized. We still use a
single per-domain p2m lock (profiling work tbd may or may not indicate the need
for fine-grained locking).

We only enforce locking of p2m queries for hap-assisted domains. These are the
domains (in the case of EPT) that can exercise the paging and sharing
subsystems and thus most in need of synchronized lookups.

While the code *should* work for domains relying on shadow paging, it has not
been tested, hence we do not enable this at the moment.

Finally, the locking discipline in the PoD subsystem has been updated, since
PoD relied on some assumptions about the way the p2m lock is used.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/hap/hap.c        |    8 ++
 xen/arch/x86/mm/mm-locks.h       |   40 ++++++++-----
 xen/arch/x86/mm/p2m.c            |   21 ++++++-
 xen/include/asm-x86/mm.h         |    6 +-
 xen/include/asm-x86/p2m.h        |   47 ++++++++++------
 xen/arch/x86/mm/mem_sharing.c    |    2 -
 xen/arch/x86/mm/mm-locks.h       |    4 +-
 xen/arch/x86/mm/p2m-ept.c        |   33 +----------
 xen/arch/x86/mm/p2m-pod.c        |   14 +++-
 xen/arch/x86/mm/p2m-pt.c         |   45 ++-------------
 xen/arch/x86/mm/p2m.c            |   62 +++++++++++----------
 xen/arch/x86/mm/mm-locks.h       |   10 +++
 xen/arch/x86/mm/p2m-pod.c        |  110 +++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m-pt.c         |    1 +
 xen/arch/x86/mm/p2m.c            |    8 ++-
 xen/include/asm-x86/p2m.h        |   27 ++------
 xen/arch/x86/hvm/emulate.c       |    2 +-
 xen/arch/x86/hvm/hvm.c           |   25 ++++++--
 xen/arch/x86/mm.c                |   10 +-
 xen/arch/x86/mm/guest_walk.c     |    2 +-
 xen/arch/x86/mm/hap/guest_walk.c |    6 +-
 xen/arch/x86/mm/mem_access.c     |   10 +++
 xen/arch/x86/mm/mem_event.c      |    5 +
 xen/arch/x86/mm/p2m.c            |   52 ++++++++++--------
 xen/common/grant_table.c         |    2 +-
 xen/common/memory.c              |    2 +-
 xen/include/asm-x86/mem_access.h |    1 +
 xen/include/asm-x86/mem_event.h  |    3 +
 xen/include/asm-x86/p2m.h        |   10 ++-
 xen/arch/x86/mm/p2m.c            |    4 +-
 xen/arch/x86/hvm/emulate.c       |   33 ++++------
 xen/arch/x86/mm/mem_sharing.c    |   24 +++----
 xen/include/asm-x86/p2m.h        |   60 +++++++++++++++++++++
 xen/arch/x86/mm/p2m.c            |   26 ++++++++-
 34 files changed, 427 insertions(+), 288 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqZ-0008BN-Ho; Thu, 09 Feb 2012 04:43:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqX-00089O-6J
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328762520!55965475!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2MzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5981 invoked from network); 9 Feb 2012 04:42:01 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-3.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:01 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5C22145807C;
	Wed,  8 Feb 2012 20:42:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oLH/YkZg0rSBY7REYQOp8rA9maLfAbhXu64RX4bWtmQN
	LMBQf8yQJH/h7wAW7t8u18W9Rg+XHKNHSIG3BbzeXJaXUVq8rAf1MttvVjM2FAn/
	MWBmuXfMgZyT02Logh16JZtnP2M+uXI9mJqzpfAi0F5ZbRZcFBjbxBz47HQlpxg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=CSfCy1nN9wlsHAdHUx3auXFo8V0=; b=nziGdyCXUXp
	SWJhNG7/Lt2zhZATzSwERd0zqCEt6436rIL9eGaNFBYyLoHp0tTu1YpJ2vgur+a5
	YbwHB7mr6itRvWgqti6GjPOZFkPb0zUgRa/Wn5Ci2ozGTbgxketp34/w3nMTxprQ
	JfNl7qbUuxpy0TvK0p/MG9dkOwZbzTdQ=
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 B4E93458079; 
	Wed,  8 Feb 2012 20:42:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7fe1bb9208df56d9654803cec6c765cee0a77354
Message-Id: <7fe1bb9208df56d96548.1328766351@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:51 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 7] x86/mm: Refactor possibly deadlocking
	get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c    |  33 ++++++++++-------------
 xen/arch/x86/mm/mem_sharing.c |  24 +++++++---------
 xen/include/asm-x86/p2m.h     |  60 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 32 deletions(-)


When calling get_gfn multiple times on different gfn's in the same function, we
can easily deadlock if p2m lookups are locked. Thus, refactor these calls to
enforce simple deadlock-avoidance rules:
 - Lowest-numbered domain first
 - Lowest-numbered gfn first

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>

diff -r 316d227dd526 -r 7fe1bb9208df xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    unsigned long saddr, daddr, bytes, sgfn, dgfn;
+    unsigned long saddr, daddr, bytes;
     paddr_t sgpa, dgpa;
     uint32_t pfec = PFEC_page_present;
-    p2m_type_t p2mt;
+    p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
+    struct two_gfns tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -693,26 +694,23 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    /* XXX In a fine-grained p2m locking scenario, we need to sort this
-     * get_gfn's, or else we might deadlock */
-    sgfn = sgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, sgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
+                 current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
+                 p2m_guest, &tg);
+
+    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
         rc = hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_gfn(current->domain, sgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
-    dgfn = dgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, dgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
     {
         rc = hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
@@ -730,8 +728,7 @@ static int hvmemul_rep_movs(
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -743,8 +740,7 @@ static int hvmemul_rep_movs(
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -757,8 +753,7 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_gfn(current->domain, sgfn);
-    put_gfn(current->domain, dgfn);
+    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 316d227dd526 -r 7fe1bb9208df xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -727,11 +727,11 @@ int mem_sharing_share_pages(struct domai
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    struct two_gfns tg;
 
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn(sd, sgfn, &smfn_type);
-    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+    get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                 cd, cgfn, &cmfn_type, NULL, &cmfn,
+                 p2m_query, &tg);
 
     /* This tricky business is to avoid two callers deadlocking if 
      * grabbing pages in opposite client/source order */
@@ -828,8 +828,7 @@ int mem_sharing_share_pages(struct domai
     ret = 0;
     
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
@@ -843,11 +842,11 @@ int mem_sharing_add_to_physmap(struct do
     struct gfn_info *gfn_info;
     struct p2m_domain *p2m = p2m_get_hostp2m(cd);
     p2m_access_t a;
-    
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn_query(sd, sgfn, &smfn_type);
-    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+    struct two_gfns tg;
+
+    get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                 cd, cgfn, &cmfn_type, &a, &cmfn,
+                 p2m_query, &tg);
 
     /* Get the source shared page, check and lock */
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
@@ -897,8 +896,7 @@ int mem_sharing_add_to_physmap(struct do
 err_unlock:
     mem_sharing_page_unlock(spage);
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
diff -r 316d227dd526 -r 7fe1bb9208df xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -378,6 +378,66 @@ static inline unsigned long mfn_to_gfn(s
         return mfn_x(mfn);
 }
 
+/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
+struct two_gfns {
+    struct domain  *first_domain;
+    unsigned long   first_gfn;
+    struct domain  *second_domain;
+    unsigned long   second_gfn;
+};
+
+#define assign_pointers(dest, source)                                        \
+do {                                                                         \
+    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
+    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
+    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
+} while(0)
+
+/* Returns mfn, type and access for potential caller consumption, but any
+ * of those can be NULL */
+static inline void get_two_gfns(struct domain *rd, unsigned long rgfn,
+        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain *ld, 
+        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
+        p2m_query_t q, struct two_gfns *rval)
+{
+    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
+    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
+    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
+
+    /* Sort by domain, if same domain by gfn */
+    if ( (rd->domain_id <= ld->domain_id) || ((rd == ld) && (rgfn <= lgfn)) )
+    {
+        rval->first_domain  = rd;
+        rval->first_gfn     = rgfn;
+        rval->second_domain = ld;
+        rval->second_gfn    = lgfn;
+        assign_pointers(first, r);
+        assign_pointers(second, l);
+    } else {
+        rval->first_domain  = ld;
+        rval->first_gfn     = lgfn;
+        rval->second_domain = rd;
+        rval->second_gfn    = rgfn;
+        assign_pointers(first, l);
+        assign_pointers(second, r);
+    }
+
+    /* Now do the gets */
+    *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
+                                      rval->first_gfn, first_t, first_a, q, NULL);
+    *second_mfn = get_gfn_type_access(p2m_get_hostp2m(rval->second_domain), 
+                                      rval->second_gfn, second_t, second_a, q, NULL);
+}
+
+static inline void put_two_gfns(struct two_gfns *arg)
+{
+    if ( !arg )
+        return;
+
+    put_gfn(arg->second_domain, arg->second_gfn);
+    put_gfn(arg->first_domain, arg->first_gfn);
+}
+
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqZ-0008BN-Ho; Thu, 09 Feb 2012 04:43:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqX-00089O-6J
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328762520!55965475!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2MzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5981 invoked from network); 9 Feb 2012 04:42:01 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-3.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:01 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5C22145807C;
	Wed,  8 Feb 2012 20:42:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oLH/YkZg0rSBY7REYQOp8rA9maLfAbhXu64RX4bWtmQN
	LMBQf8yQJH/h7wAW7t8u18W9Rg+XHKNHSIG3BbzeXJaXUVq8rAf1MttvVjM2FAn/
	MWBmuXfMgZyT02Logh16JZtnP2M+uXI9mJqzpfAi0F5ZbRZcFBjbxBz47HQlpxg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=CSfCy1nN9wlsHAdHUx3auXFo8V0=; b=nziGdyCXUXp
	SWJhNG7/Lt2zhZATzSwERd0zqCEt6436rIL9eGaNFBYyLoHp0tTu1YpJ2vgur+a5
	YbwHB7mr6itRvWgqti6GjPOZFkPb0zUgRa/Wn5Ci2ozGTbgxketp34/w3nMTxprQ
	JfNl7qbUuxpy0TvK0p/MG9dkOwZbzTdQ=
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 B4E93458079; 
	Wed,  8 Feb 2012 20:42:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7fe1bb9208df56d9654803cec6c765cee0a77354
Message-Id: <7fe1bb9208df56d96548.1328766351@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:51 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 7] x86/mm: Refactor possibly deadlocking
	get_gfn calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c    |  33 ++++++++++-------------
 xen/arch/x86/mm/mem_sharing.c |  24 +++++++---------
 xen/include/asm-x86/p2m.h     |  60 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 32 deletions(-)


When calling get_gfn multiple times on different gfn's in the same function, we
can easily deadlock if p2m lookups are locked. Thus, refactor these calls to
enforce simple deadlock-avoidance rules:
 - Lowest-numbered domain first
 - Lowest-numbered gfn first

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavila.org>

diff -r 316d227dd526 -r 7fe1bb9208df xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -660,12 +660,13 @@ static int hvmemul_rep_movs(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    unsigned long saddr, daddr, bytes, sgfn, dgfn;
+    unsigned long saddr, daddr, bytes;
     paddr_t sgpa, dgpa;
     uint32_t pfec = PFEC_page_present;
-    p2m_type_t p2mt;
+    p2m_type_t sp2mt, dp2mt;
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
+    struct two_gfns tg;
 
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
@@ -693,26 +694,23 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    /* XXX In a fine-grained p2m locking scenario, we need to sort this
-     * get_gfn's, or else we might deadlock */
-    sgfn = sgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, sgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
+                 current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
+                 p2m_guest, &tg);
+
+    if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
         rc = hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
-        put_gfn(current->domain, sgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
-    dgfn = dgpa >> PAGE_SHIFT;
-    (void)get_gfn(current->domain, dgfn, &p2mt);
-    if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
+    if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) )
     {
         rc = hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return rc;
     }
 
@@ -730,8 +728,7 @@ static int hvmemul_rep_movs(
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -743,8 +740,7 @@ static int hvmemul_rep_movs(
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
     {
-        put_gfn(current->domain, sgfn);
-        put_gfn(current->domain, dgfn);
+        put_two_gfns(&tg);
         return X86EMUL_UNHANDLEABLE;
     }
 
@@ -757,8 +753,7 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
-    put_gfn(current->domain, sgfn);
-    put_gfn(current->domain, dgfn);
+    put_two_gfns(&tg);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r 316d227dd526 -r 7fe1bb9208df xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -727,11 +727,11 @@ int mem_sharing_share_pages(struct domai
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    struct two_gfns tg;
 
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn(sd, sgfn, &smfn_type);
-    cmfn = get_gfn(cd, cgfn, &cmfn_type);
+    get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                 cd, cgfn, &cmfn_type, NULL, &cmfn,
+                 p2m_query, &tg);
 
     /* This tricky business is to avoid two callers deadlocking if 
      * grabbing pages in opposite client/source order */
@@ -828,8 +828,7 @@ int mem_sharing_share_pages(struct domai
     ret = 0;
     
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
@@ -843,11 +842,11 @@ int mem_sharing_add_to_physmap(struct do
     struct gfn_info *gfn_info;
     struct p2m_domain *p2m = p2m_get_hostp2m(cd);
     p2m_access_t a;
-    
-    /* XXX if sd == cd handle potential deadlock by ordering
-     * the get_ and put_gfn's */
-    smfn = get_gfn_query(sd, sgfn, &smfn_type);
-    cmfn = get_gfn_type_access(p2m, cgfn, &cmfn_type, &a, p2m_query, NULL);
+    struct two_gfns tg;
+
+    get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
+                 cd, cgfn, &cmfn_type, &a, &cmfn,
+                 p2m_query, &tg);
 
     /* Get the source shared page, check and lock */
     ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
@@ -897,8 +896,7 @@ int mem_sharing_add_to_physmap(struct do
 err_unlock:
     mem_sharing_page_unlock(spage);
 err_out:
-    put_gfn(cd, cgfn);
-    put_gfn(sd, sgfn);
+    put_two_gfns(&tg);
     return ret;
 }
 
diff -r 316d227dd526 -r 7fe1bb9208df xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -378,6 +378,66 @@ static inline unsigned long mfn_to_gfn(s
         return mfn_x(mfn);
 }
 
+/* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
+struct two_gfns {
+    struct domain  *first_domain;
+    unsigned long   first_gfn;
+    struct domain  *second_domain;
+    unsigned long   second_gfn;
+};
+
+#define assign_pointers(dest, source)                                        \
+do {                                                                         \
+    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
+    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
+    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
+} while(0)
+
+/* Returns mfn, type and access for potential caller consumption, but any
+ * of those can be NULL */
+static inline void get_two_gfns(struct domain *rd, unsigned long rgfn,
+        p2m_type_t *rt, p2m_access_t *ra, mfn_t *rmfn, struct domain *ld, 
+        unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
+        p2m_query_t q, struct two_gfns *rval)
+{
+    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
+    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
+    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
+
+    /* Sort by domain, if same domain by gfn */
+    if ( (rd->domain_id <= ld->domain_id) || ((rd == ld) && (rgfn <= lgfn)) )
+    {
+        rval->first_domain  = rd;
+        rval->first_gfn     = rgfn;
+        rval->second_domain = ld;
+        rval->second_gfn    = lgfn;
+        assign_pointers(first, r);
+        assign_pointers(second, l);
+    } else {
+        rval->first_domain  = ld;
+        rval->first_gfn     = lgfn;
+        rval->second_domain = rd;
+        rval->second_gfn    = rgfn;
+        assign_pointers(first, l);
+        assign_pointers(second, r);
+    }
+
+    /* Now do the gets */
+    *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
+                                      rval->first_gfn, first_t, first_a, q, NULL);
+    *second_mfn = get_gfn_type_access(p2m_get_hostp2m(rval->second_domain), 
+                                      rval->second_gfn, second_t, second_a, q, NULL);
+}
+
+static inline void put_two_gfns(struct two_gfns *arg)
+{
+    if ( !arg )
+        return;
+
+    put_gfn(arg->second_domain, arg->second_gfn);
+    put_gfn(arg->first_domain, arg->first_gfn);
+}
+
 /* Init the datastructures for later use by the p2m code */
 int p2m_init(struct domain *d);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqU-00089o-Ox; Thu, 09 Feb 2012 04:42:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqS-000895-Rn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328762501!62100675!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3682 invoked from network); 9 Feb 2012 04:41:41 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:41:41 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 760CE458085;
	Wed,  8 Feb 2012 20:42:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=uv05P1k4vY7WVTH96QI5L6ElZ8rF6foZh+mhyp6stdPl
	8iP3lMjqVlktYadr2HPKXMbzc7GQw7791zNgsZdeigefUAka3uzdbYW1VVNwgsgn
	yVo1caKWvG2CMS5ok2mNCaD8pXColxv2PfdfyfIufPR5QVCe4zILfxhFCM41Hro=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MWfqyZPINXBtigNtaNoXv4j4f/U=; b=Bu0A/avqTIj
	0mWRP30BkrOHUpJQOo2RGgO72Gmvx9sKNXEZlsth0ZX75Y0/53bqJJJHSkWIuOEP
	SaJOMsEhJHKyfZcnCJiQ+68JUFboQ98vwYYhK4x2prnPUd4yu896E5p26lZXisW/
	7GeTzTTk4ZWT757TEpmKu1+H6kQWKSuM=
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 A6544458079; 
	Wed,  8 Feb 2012 20:42:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 63cb81c2448e87f7c2871c192eb9ced992d822e9
Message-Id: <63cb81c2448e87f7c287.1328766347@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:47 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 7] Clean up locking now that p2m lockups
 are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |   2 -
 xen/arch/x86/mm/mm-locks.h    |   4 ++-
 xen/arch/x86/mm/p2m-ept.c     |  33 ++--------------------
 xen/arch/x86/mm/p2m-pod.c     |  14 ++++++---
 xen/arch/x86/mm/p2m-pt.c      |  45 +++++-------------------------
 xen/arch/x86/mm/p2m.c         |  62 ++++++++++++++++++++++--------------------
 6 files changed, 57 insertions(+), 103 deletions(-)


With p2m lookups fully synchronized, many routines need not
call p2m_lock any longer. Also, many routines can logically
assert holding the p2m for a specific gfn.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -877,9 +877,7 @@ int mem_sharing_add_to_physmap(struct do
         goto err_unlock;
     }
 
-    p2m_lock(p2m);
     ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
-    p2m_unlock(p2m);
 
     /* Tempted to turn this into an assert */
     if ( !ret )
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -165,9 +165,11 @@ declare_mm_lock(nestedp2m)
 
 declare_mm_lock(p2m)
 #define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
 #define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
 #define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
 
 /* Sharing per page lock
  *
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -46,31 +46,6 @@ static inline bool_t is_epte_valid(ept_e
     return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
 }
 
-/* Non-ept "lock-and-check" wrapper */
-static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      ept_entry_t *entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( entry->sa_p2mt != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_access_t access)
 {
     /* First apply type permissions */
@@ -551,8 +526,8 @@ static mfn_t ept_get_entry(struct p2m_do
             index = gfn_remainder >> ( i * EPT_TABLE_ORDER);
             ept_entry = table + index;
 
-            if ( !ept_pod_check_and_populate(p2m, gfn,
-                                             ept_entry, 9, q) )
+            if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                            PAGE_ORDER_2M, q) )
                 goto retry;
             else
                 goto out;
@@ -574,8 +549,8 @@ static mfn_t ept_get_entry(struct p2m_do
 
         ASSERT(i == 0);
         
-        if ( ept_pod_check_and_populate(p2m, gfn,
-                                        ept_entry, 0, q) )
+        if ( p2m_pod_demand_populate(p2m, gfn, 
+                                        PAGE_ORDER_4K, q) )
             goto out;
     }
 
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -521,7 +521,7 @@ p2m_pod_decrease_reservation(struct doma
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gpfn, order);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -615,7 +615,7 @@ out_entry_check:
     }
 
 out_unlock:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gpfn, order);
 
 out:
     return ret;
@@ -964,7 +964,7 @@ p2m_pod_demand_populate(struct p2m_domai
     mfn_t mfn;
     int i;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     /* This check is done with the p2m lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
@@ -972,6 +972,7 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( unlikely(d->is_dying) )
         goto out_fail;
 
+    
     /* Because PoD does not have cache list for 1GB pages, it has to remap
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
@@ -981,6 +982,9 @@ p2m_pod_demand_populate(struct p2m_domai
          * split 1GB into 512 2MB pages here. But We only do once here because
          * set_p2m_entry() should automatically shatter the 1GB page into 
          * 512 2MB pages. The rest of 511 calls are unnecessary.
+         *
+         * NOTE: In a fine-grained p2m locking scenario this operation
+         * may need to promote its locking from gfn->1g superpage
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
@@ -1104,7 +1108,7 @@ guest_physmap_mark_populate_on_demand(st
     if ( rc != 0 )
         return rc;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, order);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1138,7 +1142,7 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, order);
 
 out:
     return rc;
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -473,31 +473,6 @@ out:
 }
 
 
-/* Non-ept "lock-and-check" wrapper */
-static int p2m_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      l1_pgentry_t *p2m_entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 /* 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, 
@@ -540,8 +515,7 @@ pod_retry_l3:
             /* The read has succeeded, so we know that mapping exists */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) &l3e, PAGE_ORDER_1G, q) )
+                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__);
@@ -593,8 +567,8 @@ pod_retry_l2:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 p2m_entry, 9, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
 
                 /* Allocate failed. */
@@ -651,8 +625,8 @@ pod_retry_l1:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)p2m_entry, 0, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
 
                 /* Allocate failed. */
@@ -742,8 +716,7 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) l3e, PAGE_ORDER_1G, q) )
+                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
                     gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 }
@@ -781,8 +754,7 @@ pod_retry_l2:
         if ( p2m_flags_to_type(l2e_get_flags(*l2e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l2e, PAGE_ORDER_2M, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
             } else
                 *t = p2m_populate_on_demand;
@@ -815,8 +787,7 @@ pod_retry_l1:
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l1e, PAGE_ORDER_4K, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
                 *t = p2m_populate_on_demand;
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -161,7 +161,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     /* For now only perform locking on hap domains */
     if ( locked && (hap_enabled(p2m->domain)) )
         /* Grab the lock here, don't release until put_gfn */
-        p2m_lock(p2m);
+        gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
@@ -194,9 +194,9 @@ void __put_gfn(struct p2m_domain *p2m, u
         /* Nothing to do in this case */
         return;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 }
 
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
@@ -207,7 +207,7 @@ int set_p2m_entry(struct p2m_domain *p2m
     unsigned int order;
     int rc = 1;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     while ( todo )
     {
@@ -429,6 +429,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         return;
     }
 
+    ASSERT(gfn_locked_by_me(p2m, gfn));
     P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
     if ( mfn_valid(_mfn(mfn)) )
@@ -449,9 +450,9 @@ guest_physmap_remove_page(struct domain 
                           unsigned long mfn, unsigned int page_order)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, page_order);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, page_order);
 }
 
 int
@@ -590,13 +591,13 @@ p2m_type_t p2m_change_type(struct domain
 
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
     if ( pt == ot )
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return pt;
 }
@@ -645,7 +646,7 @@ set_mmio_p2m_entry(struct domain *d, uns
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     if ( p2m_is_grant(ot) )
     {
@@ -661,7 +662,7 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_mmio_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -681,7 +682,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
 
     /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
@@ -694,7 +695,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
 
 out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return rc;
 }
@@ -711,7 +712,7 @@ set_shared_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(p2m->domain) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     /* At the moment we only allow p2m change if gfn has already been made
      * sharable first */
@@ -723,7 +724,7 @@ set_shared_p2m_entry(struct domain *d, u
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_shared, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_shared_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -759,7 +760,7 @@ int p2m_mem_paging_nominate(struct domai
     mfn_t mfn;
     int ret = -EBUSY;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -789,7 +790,7 @@ int p2m_mem_paging_nominate(struct domai
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -821,7 +822,7 @@ int p2m_mem_paging_evict(struct domain *
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EBUSY;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     /* Get mfn */
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -865,7 +866,7 @@ int p2m_mem_paging_evict(struct domain *
     put_page(page);
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -950,7 +951,7 @@ void p2m_mem_paging_populate(struct doma
     req.type = MEM_EVENT_TYPE_PAGING;
 
     /* Fix p2m mapping */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
@@ -961,7 +962,7 @@ void p2m_mem_paging_populate(struct doma
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Pause domain if request came from guest and gfn has paging type */
     if ( p2m_is_paging(p2mt) && v->domain == d )
@@ -1012,7 +1013,7 @@ int p2m_mem_paging_prep(struct domain *d
              (!access_ok(user_ptr, PAGE_SIZE)) )
             return -EINVAL;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -1071,7 +1072,7 @@ int p2m_mem_paging_prep(struct domain *d
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -1106,7 +1107,7 @@ void p2m_mem_paging_resume(struct domain
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
-            p2m_lock(p2m);
+            gfn_lock(p2m, rsp.gfn, 0);
             mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
@@ -1117,7 +1118,7 @@ void p2m_mem_paging_resume(struct domain
                                 p2m_ram_rw, a);
                 set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
             }
-            p2m_unlock(p2m);
+            gfn_unlock(p2m, rsp.gfn, 0);
         }
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
@@ -1138,13 +1139,13 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_access_t p2ma;
     
     /* First, handle rx2rw conversion automatically */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
-        p2m_unlock(p2m);
+        gfn_unlock(p2m, gfn, 0);
         return 1;
     }
     else if ( p2ma == p2m_access_n2rwx )
@@ -1152,7 +1153,7 @@ bool_t p2m_mem_access_check(unsigned lon
         ASSERT(access_w || access_r || access_x);
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
     if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
@@ -1171,9 +1172,9 @@ bool_t p2m_mem_access_check(unsigned lon
             if ( p2ma != p2m_access_n2rwx )
             {
                 /* A listener is not required, so clear the access restrictions */
-                p2m_lock(p2m);
+                gfn_lock(p2m, gfn, 0);
                 p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-                p2m_unlock(p2m);
+                gfn_unlock(p2m, gfn, 0);
             }
             return 1;
         }
@@ -1304,7 +1305,10 @@ int p2m_get_mem_access(struct domain *d,
         return 0;
     }
 
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL);
+    gfn_unlock(p2m, gfn, 0);
+
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqU-00089o-Ox; Thu, 09 Feb 2012 04:42:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqS-000895-Rn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328762501!62100675!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3682 invoked from network); 9 Feb 2012 04:41:41 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:41:41 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 760CE458085;
	Wed,  8 Feb 2012 20:42:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=uv05P1k4vY7WVTH96QI5L6ElZ8rF6foZh+mhyp6stdPl
	8iP3lMjqVlktYadr2HPKXMbzc7GQw7791zNgsZdeigefUAka3uzdbYW1VVNwgsgn
	yVo1caKWvG2CMS5ok2mNCaD8pXColxv2PfdfyfIufPR5QVCe4zILfxhFCM41Hro=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MWfqyZPINXBtigNtaNoXv4j4f/U=; b=Bu0A/avqTIj
	0mWRP30BkrOHUpJQOo2RGgO72Gmvx9sKNXEZlsth0ZX75Y0/53bqJJJHSkWIuOEP
	SaJOMsEhJHKyfZcnCJiQ+68JUFboQ98vwYYhK4x2prnPUd4yu896E5p26lZXisW/
	7GeTzTTk4ZWT757TEpmKu1+H6kQWKSuM=
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 A6544458079; 
	Wed,  8 Feb 2012 20:42:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 63cb81c2448e87f7c2871c192eb9ced992d822e9
Message-Id: <63cb81c2448e87f7c287.1328766347@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:47 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 7] Clean up locking now that p2m lockups
 are fully synchronized
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |   2 -
 xen/arch/x86/mm/mm-locks.h    |   4 ++-
 xen/arch/x86/mm/p2m-ept.c     |  33 ++--------------------
 xen/arch/x86/mm/p2m-pod.c     |  14 ++++++---
 xen/arch/x86/mm/p2m-pt.c      |  45 +++++-------------------------
 xen/arch/x86/mm/p2m.c         |  62 ++++++++++++++++++++++--------------------
 6 files changed, 57 insertions(+), 103 deletions(-)


With p2m lookups fully synchronized, many routines need not
call p2m_lock any longer. Also, many routines can logically
assert holding the p2m for a specific gfn.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -877,9 +877,7 @@ int mem_sharing_add_to_physmap(struct do
         goto err_unlock;
     }
 
-    p2m_lock(p2m);
     ret = set_p2m_entry(p2m, cgfn, smfn, PAGE_ORDER_4K, p2m_ram_shared, a);
-    p2m_unlock(p2m);
 
     /* Tempted to turn this into an assert */
     if ( !ret )
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -165,9 +165,11 @@ declare_mm_lock(nestedp2m)
 
 declare_mm_lock(p2m)
 #define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define gfn_lock(p,g,o)       mm_lock_recursive(p2m, &(p)->lock)
 #define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define gfn_unlock(p,g,o)     mm_unlock(&(p)->lock)
 #define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock)
 
 /* Sharing per page lock
  *
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -46,31 +46,6 @@ static inline bool_t is_epte_valid(ept_e
     return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
 }
 
-/* Non-ept "lock-and-check" wrapper */
-static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      ept_entry_t *entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( entry->sa_p2mt != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 static void ept_p2m_type_to_flags(ept_entry_t *entry, p2m_type_t type, p2m_access_t access)
 {
     /* First apply type permissions */
@@ -551,8 +526,8 @@ static mfn_t ept_get_entry(struct p2m_do
             index = gfn_remainder >> ( i * EPT_TABLE_ORDER);
             ept_entry = table + index;
 
-            if ( !ept_pod_check_and_populate(p2m, gfn,
-                                             ept_entry, 9, q) )
+            if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                            PAGE_ORDER_2M, q) )
                 goto retry;
             else
                 goto out;
@@ -574,8 +549,8 @@ static mfn_t ept_get_entry(struct p2m_do
 
         ASSERT(i == 0);
         
-        if ( ept_pod_check_and_populate(p2m, gfn,
-                                        ept_entry, 0, q) )
+        if ( p2m_pod_demand_populate(p2m, gfn, 
+                                        PAGE_ORDER_4K, q) )
             goto out;
     }
 
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -521,7 +521,7 @@ p2m_pod_decrease_reservation(struct doma
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gpfn, order);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -615,7 +615,7 @@ out_entry_check:
     }
 
 out_unlock:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gpfn, order);
 
 out:
     return ret;
@@ -964,7 +964,7 @@ p2m_pod_demand_populate(struct p2m_domai
     mfn_t mfn;
     int i;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     /* This check is done with the p2m lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
@@ -972,6 +972,7 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( unlikely(d->is_dying) )
         goto out_fail;
 
+    
     /* Because PoD does not have cache list for 1GB pages, it has to remap
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
@@ -981,6 +982,9 @@ p2m_pod_demand_populate(struct p2m_domai
          * split 1GB into 512 2MB pages here. But We only do once here because
          * set_p2m_entry() should automatically shatter the 1GB page into 
          * 512 2MB pages. The rest of 511 calls are unnecessary.
+         *
+         * NOTE: In a fine-grained p2m locking scenario this operation
+         * may need to promote its locking from gfn->1g superpage
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
@@ -1104,7 +1108,7 @@ guest_physmap_mark_populate_on_demand(st
     if ( rc != 0 )
         return rc;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, order);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1138,7 +1142,7 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, order);
 
 out:
     return rc;
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -473,31 +473,6 @@ out:
 }
 
 
-/* Non-ept "lock-and-check" wrapper */
-static int p2m_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
-                                      l1_pgentry_t *p2m_entry, int order,
-                                      p2m_query_t q)
-{
-    int r;
-
-    /* This is called from the p2m lookups, which can happen with or 
-     * without the lock hed. */
-    p2m_lock_recursive(p2m);
-
-    /* Check to make sure this is still PoD */
-    if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
-    {
-        p2m_unlock(p2m);
-        return 0;
-    }
-
-    r = p2m_pod_demand_populate(p2m, gfn, order, q);
-
-    p2m_unlock(p2m);
-
-    return r;
-}
-
 /* 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, 
@@ -540,8 +515,7 @@ pod_retry_l3:
             /* The read has succeeded, so we know that mapping exists */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) &l3e, PAGE_ORDER_1G, q) )
+                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__);
@@ -593,8 +567,8 @@ pod_retry_l2:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 p2m_entry, 9, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
 
                 /* Allocate failed. */
@@ -651,8 +625,8 @@ pod_retry_l1:
              * exits at this point.  */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)p2m_entry, 0, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, 
+                                                PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
 
                 /* Allocate failed. */
@@ -742,8 +716,7 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                      (l1_pgentry_t *) l3e, PAGE_ORDER_1G, q) )
+                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
                     gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 }
@@ -781,8 +754,7 @@ pod_retry_l2:
         if ( p2m_flags_to_type(l2e_get_flags(*l2e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l2e, PAGE_ORDER_2M, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
             } else
                 *t = p2m_populate_on_demand;
@@ -815,8 +787,7 @@ pod_retry_l1:
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
-                if ( !p2m_pod_check_and_populate(p2m, gfn,
-                                                 (l1_pgentry_t *)l1e, PAGE_ORDER_4K, q) )
+                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
                 *t = p2m_populate_on_demand;
diff -r e29c2634afb1 -r 63cb81c2448e xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -161,7 +161,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     /* For now only perform locking on hap domains */
     if ( locked && (hap_enabled(p2m->domain)) )
         /* Grab the lock here, don't release until put_gfn */
-        p2m_lock(p2m);
+        gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
@@ -194,9 +194,9 @@ void __put_gfn(struct p2m_domain *p2m, u
         /* Nothing to do in this case */
         return;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 }
 
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
@@ -207,7 +207,7 @@ int set_p2m_entry(struct p2m_domain *p2m
     unsigned int order;
     int rc = 1;
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(gfn_locked_by_me(p2m, gfn));
 
     while ( todo )
     {
@@ -429,6 +429,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         return;
     }
 
+    ASSERT(gfn_locked_by_me(p2m, gfn));
     P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
     if ( mfn_valid(_mfn(mfn)) )
@@ -449,9 +450,9 @@ guest_physmap_remove_page(struct domain 
                           unsigned long mfn, unsigned int page_order)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, page_order);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, page_order);
 }
 
 int
@@ -590,13 +591,13 @@ p2m_type_t p2m_change_type(struct domain
 
     BUG_ON(p2m_is_grant(ot) || p2m_is_grant(nt));
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
     if ( pt == ot )
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
 
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return pt;
 }
@@ -645,7 +646,7 @@ set_mmio_p2m_entry(struct domain *d, uns
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     if ( p2m_is_grant(ot) )
     {
@@ -661,7 +662,7 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_mmio_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -681,7 +682,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(d) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
 
     /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
@@ -694,7 +695,7 @@ clear_mmio_p2m_entry(struct domain *d, u
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
 
 out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     return rc;
 }
@@ -711,7 +712,7 @@ set_shared_p2m_entry(struct domain *d, u
     if ( !paging_mode_translate(p2m->domain) )
         return 0;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
     /* At the moment we only allow p2m change if gfn has already been made
      * sharable first */
@@ -723,7 +724,7 @@ set_shared_p2m_entry(struct domain *d, u
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_shared, p2m->default_access);
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
             "set_shared_p2m_entry: set_p2m_entry failed! mfn=%08lx\n",
@@ -759,7 +760,7 @@ int p2m_mem_paging_nominate(struct domai
     mfn_t mfn;
     int ret = -EBUSY;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -789,7 +790,7 @@ int p2m_mem_paging_nominate(struct domai
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -821,7 +822,7 @@ int p2m_mem_paging_evict(struct domain *
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int ret = -EBUSY;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     /* Get mfn */
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -865,7 +866,7 @@ int p2m_mem_paging_evict(struct domain *
     put_page(page);
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -950,7 +951,7 @@ void p2m_mem_paging_populate(struct doma
     req.type = MEM_EVENT_TYPE_PAGING;
 
     /* Fix p2m mapping */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
@@ -961,7 +962,7 @@ void p2m_mem_paging_populate(struct doma
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Pause domain if request came from guest and gfn has paging type */
     if ( p2m_is_paging(p2mt) && v->domain == d )
@@ -1012,7 +1013,7 @@ int p2m_mem_paging_prep(struct domain *d
              (!access_ok(user_ptr, PAGE_SIZE)) )
             return -EINVAL;
 
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
@@ -1071,7 +1072,7 @@ int p2m_mem_paging_prep(struct domain *d
     ret = 0;
 
  out:
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
     return ret;
 }
 
@@ -1106,7 +1107,7 @@ void p2m_mem_paging_resume(struct domain
         /* Fix p2m entry if the page was not dropped */
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
-            p2m_lock(p2m);
+            gfn_lock(p2m, rsp.gfn, 0);
             mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
@@ -1117,7 +1118,7 @@ void p2m_mem_paging_resume(struct domain
                                 p2m_ram_rw, a);
                 set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
             }
-            p2m_unlock(p2m);
+            gfn_unlock(p2m, rsp.gfn, 0);
         }
         /* Unpause domain */
         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
@@ -1138,13 +1139,13 @@ bool_t p2m_mem_access_check(unsigned lon
     p2m_access_t p2ma;
     
     /* First, handle rx2rw conversion automatically */
-    p2m_lock(p2m);
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
-        p2m_unlock(p2m);
+        gfn_unlock(p2m, gfn, 0);
         return 1;
     }
     else if ( p2ma == p2m_access_n2rwx )
@@ -1152,7 +1153,7 @@ bool_t p2m_mem_access_check(unsigned lon
         ASSERT(access_w || access_r || access_x);
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
     }
-    p2m_unlock(p2m);
+    gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
     if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
@@ -1171,9 +1172,9 @@ bool_t p2m_mem_access_check(unsigned lon
             if ( p2ma != p2m_access_n2rwx )
             {
                 /* A listener is not required, so clear the access restrictions */
-                p2m_lock(p2m);
+                gfn_lock(p2m, gfn, 0);
                 p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-                p2m_unlock(p2m);
+                gfn_unlock(p2m, gfn, 0);
             }
             return 1;
         }
@@ -1304,7 +1305,10 @@ int p2m_get_mem_access(struct domain *d,
         return 0;
     }
 
+    gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL);
+    gfn_unlock(p2m, gfn, 0);
+
     if ( mfn_x(mfn) == INVALID_MFN )
         return -ESRCH;
     

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqU-00089Q-6Z; Thu, 09 Feb 2012 04:42:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqR-00089E-N9
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328762501!62100675!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 9 Feb 2012 04:41:43 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:41:43 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 9B8D3458081;
	Wed,  8 Feb 2012 20:42:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vnwQ3v+TA+Kr6shFKJ2SBFPu94904wi0pErOf9xN/q+d
	hlenT1c+LAZho3BXnqufqO1U0mNkwmMiO3NyPvSUUvAPtiY8/4TR7kIFUisWUjGv
	r9XDEtaNzoWo4tuOMi7VFt/OdPF60+P+qOHCjh8autECmjqmfIy1rHovHMV/Qpo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=zE1KETv3KnnzMMRNQ+wk0hJrfUc=; b=I7TfcKiazb/
	p7Z+NW8e2TPU1xQk9QbgJpUymJxD9W9sag8MgvkmNJJE45HMQQm0Ph8fOLIH/yLx
	DlaUbZ/QbLu+nAmrxF3axIeZ07174KQ9PSzxwhNN8h4VZF9w0LXlDdFEIG6LgM8m
	kNXwo6vz/GCtCN+F1ayVOqkxDWzsVkbI=
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 CB989458079; 
	Wed,  8 Feb 2012 20:42:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f2d967332acc349cfe319a55b2bbe06ea2777d17
Message-Id: <f2d967332acc349cfe31.1328766349@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:49 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 7] Re-order calls to put_gfn() around wait
 queue invocations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c       |   2 +-
 xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
 xen/arch/x86/mm.c                |  10 +++---
 xen/arch/x86/mm/guest_walk.c     |   2 +-
 xen/arch/x86/mm/hap/guest_walk.c |   6 +---
 xen/arch/x86/mm/mem_access.c     |  10 +++++++
 xen/arch/x86/mm/mem_event.c      |   5 +++
 xen/arch/x86/mm/p2m.c            |  52 ++++++++++++++++++++++-----------------
 xen/common/grant_table.c         |   2 +-
 xen/common/memory.c              |   2 +-
 xen/include/asm-x86/mem_access.h |   1 +
 xen/include/asm-x86/mem_event.h  |   3 ++
 xen/include/asm-x86/p2m.h        |  10 +++++--
 13 files changed, 83 insertions(+), 47 deletions(-)


Since we use wait queues to handle potential ring congestion cases,
code paths that try to generate a mem event while holding a gfn lock
would go to sleep in non-preemptible mode.

Most such code paths can be fixed by simply postponing event generation until
locks are released.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,8 +67,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(curr->domain, ram_gfn); 
         p2m_mem_paging_populate(curr->domain, ram_gfn);
-        put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -64,6 +64,7 @@
 #include <public/version.h>
 #include <public/memory.h>
 #include <asm/mem_event.h>
+#include <asm/mem_access.h>
 #include <public/mem_event.h>
 
 bool_t __read_mostly hvm_enabled;
@@ -363,8 +364,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gmfn);
         p2m_mem_paging_populate(d, gmfn);
-        put_gfn(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
@@ -1195,7 +1196,8 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc, fall_through = 0;
+    int rc, fall_through = 0, paged = 0;
+    mem_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1270,7 +1272,7 @@ int hvm_hap_nested_page_fault(unsigned l
         if ( violation )
         {
             if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
-                                        access_w, access_x) )
+                                        access_w, access_x, &req_ptr) )
             {
                 fall_through = 1;
             } else {
@@ -1297,7 +1299,7 @@ int hvm_hap_nested_page_fault(unsigned l
 #ifdef __x86_64__
     /* Check if the page has been paged out */
     if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
-        p2m_mem_paging_populate(v->domain, gfn);
+        paged = 1;
 
     /* Mem sharing: unshare the page and try again */
     if ( access_w && (p2mt == p2m_ram_shared) )
@@ -1343,6 +1345,13 @@ int hvm_hap_nested_page_fault(unsigned l
 
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
+    if ( paged )
+        p2m_mem_paging_populate(v->domain, gfn);
+    if ( req_ptr )
+    {
+        mem_access_send_req(v->domain, req_ptr);
+        xfree(req_ptr);
+    }
     return rc;
 }
 
@@ -1849,8 +1858,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gfn);
         p2m_mem_paging_populate(d, gfn);
-        put_gfn(d, gfn);
         return NULL;
     }
 
@@ -2325,8 +2334,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(curr->domain, gfn);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
@@ -3923,8 +3932,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
             }
@@ -4040,8 +4049,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
             }
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3536,8 +3536,8 @@ int do_mmu_update(
 
             if ( p2m_is_paged(p2mt) )
             {
+                put_gfn(pt_owner, gmfn);
                 p2m_mem_paging_populate(pg_owner, gmfn);
-                put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
@@ -3568,8 +3568,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
+                        put_gfn(pg_owner, l1egfn);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3617,8 +3617,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l2e_p2mt) )
                     {
+                        put_gfn(pg_owner, l2egfn);
                         p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3652,8 +3652,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l3e_p2mt) )
                     {
+                        put_gfn(pg_owner, l3egfn);
                         p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3687,8 +3687,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l4e_p2mt) )
                     {
+                        put_gfn(pg_owner, l4egfn);
                         p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
                     }
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,8 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
+        __put_gfn(p2m, gfn_x(gfn));
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-        __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,10 +64,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
-
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
+        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
@@ -101,10 +100,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -47,6 +47,16 @@ int mem_access_domctl(struct domain *d, 
     return rc;
 }
 
+int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+{
+    int rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
+        return rc;
+
+    mem_event_put_request(d, &d->mem_event->access, req);
+
+    return 0;
+} 
 
 /*
  * Local variables:
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -423,6 +423,11 @@ static int mem_event_wait_slot(struct me
     return rc;
 }
 
+bool_t mem_event_check_ring(struct mem_event_domain *med)
+{
+    return (med->ring_page != NULL);
+}
+
 /*
  * Determines whether or not the current vCPU belongs to the target domain,
  * and calls the appropriate wait function.  If it is a guest vCPU, then we
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1130,17 +1130,18 @@ void p2m_mem_paging_resume(struct domain
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x)
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
-    
+    mem_event_request_t *req;
+
     /* First, handle rx2rw conversion automatically */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
@@ -1159,7 +1160,7 @@ bool_t p2m_mem_access_check(unsigned lon
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
+    if ( !mem_event_check_ring(&d->mem_event->access) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
@@ -1183,29 +1184,34 @@ bool_t p2m_mem_access_check(unsigned lon
         }
     }
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_ACCESS;
-    req.reason = MEM_EVENT_REASON_VIOLATION;
+    *req_ptr = NULL;
+    req = xmalloc(mem_event_request_t);
+    if ( req )
+    {
+        *req_ptr = req;
+        memset(req, 0, sizeof(req));
+        req->type = MEM_EVENT_TYPE_ACCESS;
+        req->reason = MEM_EVENT_REASON_VIOLATION;
+
+        /* Pause the current VCPU */
+        if ( p2ma != p2m_access_n2rwx )
+            req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+
+        /* Send request to mem event */
+        req->gfn = gfn;
+        req->offset = gpa & ((1 << PAGE_SHIFT) - 1);
+        req->gla_valid = gla_valid;
+        req->gla = gla;
+        req->access_r = access_r;
+        req->access_w = access_w;
+        req->access_x = access_x;
+    
+        req->vcpu_id = v->vcpu_id;
+    }
 
     /* Pause the current VCPU */
     if ( p2ma != p2m_access_n2rwx )
-    {
         vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    } 
-
-    /* Send request to mem event */
-    req.gfn = gfn;
-    req.offset = gpa & ((1 << PAGE_SHIFT) - 1);
-    req.gla_valid = gla_valid;
-    req.gla = gla;
-    req.access_r = access_r;
-    req.access_w = access_w;
-    req.access_x = access_x;
-    
-    req.vcpu_id = v->vcpu_id;
-
-    mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU may be paused, return whether we promoted automatically */
     return (p2ma == p2m_access_n2rwx);
diff -r 5416a3b371f2 -r f2d967332acc xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -164,8 +164,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(rd, gfn);
             p2m_mem_paging_populate(rd, gfn);
-            put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
     } else {
diff -r 5416a3b371f2 -r f2d967332acc xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -166,8 +166,8 @@ int guest_remove_page(struct domain *d, 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
+        put_gfn(d, gmfn);
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
-        put_gfn(d, gmfn);
         return 1;
     }
 #else
diff -r 5416a3b371f2 -r f2d967332acc xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -23,6 +23,7 @@
 
 int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                       XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
 /*
diff -r 5416a3b371f2 -r f2d967332acc xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,6 +24,9 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
+/* Returns whether a ring has been set up */
+bool_t mem_event_check_ring(struct mem_event_domain *med);
+
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
  * available space. For success or -EBUSY, the vCPU may be left blocked
  * temporarily to ensure that the ring does not lose future events.  In
diff -r 5416a3b371f2 -r f2d967332acc xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -494,9 +494,12 @@ static inline void p2m_mem_paging_popula
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
  * the rw2rx conversion. Boolean return value indicates if access rights have 
- * been promoted with no underlying vcpu pause. */
+ * been promoted with no underlying vcpu pause. If the req_ptr has been populated, 
+ * then the caller must put the event in the ring (once having released get_gfn*
+ * locks -- caller must also xfree the request. */
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x);
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
 
@@ -513,7 +516,8 @@ int p2m_get_mem_access(struct domain *d,
 #else
 static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
-                                        bool_t access_w, bool_t access_x)
+                                        bool_t access_w, bool_t access_x,
+                                        mem_event_request_t **req_ptr)
 { return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqU-00089Q-6Z; Thu, 09 Feb 2012 04:42:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqR-00089E-N9
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328762501!62100675!2
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 9 Feb 2012 04:41:43 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:41:43 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 9B8D3458081;
	Wed,  8 Feb 2012 20:42:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vnwQ3v+TA+Kr6shFKJ2SBFPu94904wi0pErOf9xN/q+d
	hlenT1c+LAZho3BXnqufqO1U0mNkwmMiO3NyPvSUUvAPtiY8/4TR7kIFUisWUjGv
	r9XDEtaNzoWo4tuOMi7VFt/OdPF60+P+qOHCjh8autECmjqmfIy1rHovHMV/Qpo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=zE1KETv3KnnzMMRNQ+wk0hJrfUc=; b=I7TfcKiazb/
	p7Z+NW8e2TPU1xQk9QbgJpUymJxD9W9sag8MgvkmNJJE45HMQQm0Ph8fOLIH/yLx
	DlaUbZ/QbLu+nAmrxF3axIeZ07174KQ9PSzxwhNN8h4VZF9w0LXlDdFEIG6LgM8m
	kNXwo6vz/GCtCN+F1ayVOqkxDWzsVkbI=
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 CB989458079; 
	Wed,  8 Feb 2012 20:42:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f2d967332acc349cfe319a55b2bbe06ea2777d17
Message-Id: <f2d967332acc349cfe31.1328766349@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:49 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 7] Re-order calls to put_gfn() around wait
 queue invocations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c       |   2 +-
 xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
 xen/arch/x86/mm.c                |  10 +++---
 xen/arch/x86/mm/guest_walk.c     |   2 +-
 xen/arch/x86/mm/hap/guest_walk.c |   6 +---
 xen/arch/x86/mm/mem_access.c     |  10 +++++++
 xen/arch/x86/mm/mem_event.c      |   5 +++
 xen/arch/x86/mm/p2m.c            |  52 ++++++++++++++++++++++-----------------
 xen/common/grant_table.c         |   2 +-
 xen/common/memory.c              |   2 +-
 xen/include/asm-x86/mem_access.h |   1 +
 xen/include/asm-x86/mem_event.h  |   3 ++
 xen/include/asm-x86/p2m.h        |  10 +++++--
 13 files changed, 83 insertions(+), 47 deletions(-)


Since we use wait queues to handle potential ring congestion cases,
code paths that try to generate a mem event while holding a gfn lock
would go to sleep in non-preemptible mode.

Most such code paths can be fixed by simply postponing event generation until
locks are released.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -67,8 +67,8 @@ static int hvmemul_do_io(
     ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt);
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(curr->domain, ram_gfn); 
         p2m_mem_paging_populate(curr->domain, ram_gfn);
-        put_gfn(curr->domain, ram_gfn); 
         return X86EMUL_RETRY;
     }
     if ( p2m_is_shared(p2mt) )
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -64,6 +64,7 @@
 #include <public/version.h>
 #include <public/memory.h>
 #include <asm/mem_event.h>
+#include <asm/mem_access.h>
 #include <public/mem_event.h>
 
 bool_t __read_mostly hvm_enabled;
@@ -363,8 +364,8 @@ static int hvm_set_ioreq_page(
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gmfn);
         p2m_mem_paging_populate(d, gmfn);
-        put_gfn(d, gmfn);
         return -ENOENT;
     }
     if ( p2m_is_shared(p2mt) )
@@ -1195,7 +1196,8 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc, fall_through = 0;
+    int rc, fall_through = 0, paged = 0;
+    mem_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
      * If this succeeds, all is fine.
@@ -1270,7 +1272,7 @@ int hvm_hap_nested_page_fault(unsigned l
         if ( violation )
         {
             if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
-                                        access_w, access_x) )
+                                        access_w, access_x, &req_ptr) )
             {
                 fall_through = 1;
             } else {
@@ -1297,7 +1299,7 @@ int hvm_hap_nested_page_fault(unsigned l
 #ifdef __x86_64__
     /* Check if the page has been paged out */
     if ( p2m_is_paged(p2mt) || (p2mt == p2m_ram_paging_out) )
-        p2m_mem_paging_populate(v->domain, gfn);
+        paged = 1;
 
     /* Mem sharing: unshare the page and try again */
     if ( access_w && (p2mt == p2m_ram_shared) )
@@ -1343,6 +1345,13 @@ int hvm_hap_nested_page_fault(unsigned l
 
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
+    if ( paged )
+        p2m_mem_paging_populate(v->domain, gfn);
+    if ( req_ptr )
+    {
+        mem_access_send_req(v->domain, req_ptr);
+        xfree(req_ptr);
+    }
     return rc;
 }
 
@@ -1849,8 +1858,8 @@ static void *__hvm_map_guest_frame(unsig
     }
     if ( p2m_is_paging(p2mt) )
     {
+        put_gfn(d, gfn);
         p2m_mem_paging_populate(d, gfn);
-        put_gfn(d, gfn);
         return NULL;
     }
 
@@ -2325,8 +2334,8 @@ static enum hvm_copy_result __hvm_copy(
 
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(curr->domain, gfn);
             p2m_mem_paging_populate(curr->domain, gfn);
-            put_gfn(curr->domain, gfn);
             return HVMCOPY_gfn_paged_out;
         }
         if ( p2m_is_shared(p2mt) )
@@ -3923,8 +3932,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail3;
             }
@@ -4040,8 +4049,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
             mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
+                put_gfn(d, pfn);
                 p2m_mem_paging_populate(d, pfn);
-                put_gfn(d, pfn);
                 rc = -EINVAL;
                 goto param_fail4;
             }
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3536,8 +3536,8 @@ int do_mmu_update(
 
             if ( p2m_is_paged(p2mt) )
             {
+                put_gfn(pt_owner, gmfn);
                 p2m_mem_paging_populate(pg_owner, gmfn);
-                put_gfn(pt_owner, gmfn);
                 rc = -ENOENT;
                 break;
             }
@@ -3568,8 +3568,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l1e_p2mt) )
                     {
+                        put_gfn(pg_owner, l1egfn);
                         p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e));
-                        put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3617,8 +3617,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l2e_p2mt) )
                     {
+                        put_gfn(pg_owner, l2egfn);
                         p2m_mem_paging_populate(pg_owner, l2egfn);
-                        put_gfn(pg_owner, l2egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3652,8 +3652,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l3e_p2mt) )
                     {
+                        put_gfn(pg_owner, l3egfn);
                         p2m_mem_paging_populate(pg_owner, l3egfn);
-                        put_gfn(pg_owner, l3egfn);
                         rc = -ENOENT;
                         break;
                     }
@@ -3687,8 +3687,8 @@ int do_mmu_update(
 
                     if ( p2m_is_paged(l4e_p2mt) )
                     {
+                        put_gfn(pg_owner, l4egfn);
                         p2m_mem_paging_populate(pg_owner, l4egfn);
-                        put_gfn(pg_owner, l4egfn);
                         rc = -ENOENT;
                         break;
                     }
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -102,8 +102,8 @@ static inline void *map_domain_gfn(struc
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
+        __put_gfn(p2m, gfn_x(gfn));
         p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-        __put_gfn(p2m, gfn_x(gfn));
         *rc = _PAGE_PAGED;
         return NULL;
     }
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -64,10 +64,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
-
         pfec[0] = PFEC_page_paged;
         __put_gfn(p2m, top_gfn);
+        p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT);
         return INVALID_GFN;
     }
     if ( p2m_is_shared(p2mt) )
@@ -101,10 +100,9 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
-            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
-
             pfec[0] = PFEC_page_paged;
             __put_gfn(p2m, gfn_x(gfn));
+            p2m_mem_paging_populate(p2m->domain, gfn_x(gfn));
             return INVALID_GFN;
         }
         if ( p2m_is_shared(p2mt) )
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -47,6 +47,16 @@ int mem_access_domctl(struct domain *d, 
     return rc;
 }
 
+int mem_access_send_req(struct domain *d, mem_event_request_t *req)
+{
+    int rc = mem_event_claim_slot(d, &d->mem_event->access);
+    if ( rc < 0 )
+        return rc;
+
+    mem_event_put_request(d, &d->mem_event->access, req);
+
+    return 0;
+} 
 
 /*
  * Local variables:
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -423,6 +423,11 @@ static int mem_event_wait_slot(struct me
     return rc;
 }
 
+bool_t mem_event_check_ring(struct mem_event_domain *med)
+{
+    return (med->ring_page != NULL);
+}
+
 /*
  * Determines whether or not the current vCPU belongs to the target domain,
  * and calls the appropriate wait function.  If it is a guest vCPU, then we
diff -r 5416a3b371f2 -r f2d967332acc xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1130,17 +1130,18 @@ void p2m_mem_paging_resume(struct domain
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x)
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
-    
+    mem_event_request_t *req;
+
     /* First, handle rx2rw conversion automatically */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
@@ -1159,7 +1160,7 @@ bool_t p2m_mem_access_check(unsigned lon
     gfn_unlock(p2m, gfn, 0);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    if ( mem_event_claim_slot(d, &d->mem_event->access) == -ENOSYS )
+    if ( !mem_event_check_ring(&d->mem_event->access) || !req_ptr ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
@@ -1183,29 +1184,34 @@ bool_t p2m_mem_access_check(unsigned lon
         }
     }
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_ACCESS;
-    req.reason = MEM_EVENT_REASON_VIOLATION;
+    *req_ptr = NULL;
+    req = xmalloc(mem_event_request_t);
+    if ( req )
+    {
+        *req_ptr = req;
+        memset(req, 0, sizeof(req));
+        req->type = MEM_EVENT_TYPE_ACCESS;
+        req->reason = MEM_EVENT_REASON_VIOLATION;
+
+        /* Pause the current VCPU */
+        if ( p2ma != p2m_access_n2rwx )
+            req->flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+
+        /* Send request to mem event */
+        req->gfn = gfn;
+        req->offset = gpa & ((1 << PAGE_SHIFT) - 1);
+        req->gla_valid = gla_valid;
+        req->gla = gla;
+        req->access_r = access_r;
+        req->access_w = access_w;
+        req->access_x = access_x;
+    
+        req->vcpu_id = v->vcpu_id;
+    }
 
     /* Pause the current VCPU */
     if ( p2ma != p2m_access_n2rwx )
-    {
         vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    } 
-
-    /* Send request to mem event */
-    req.gfn = gfn;
-    req.offset = gpa & ((1 << PAGE_SHIFT) - 1);
-    req.gla_valid = gla_valid;
-    req.gla = gla;
-    req.access_r = access_r;
-    req.access_w = access_w;
-    req.access_x = access_x;
-    
-    req.vcpu_id = v->vcpu_id;
-
-    mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU may be paused, return whether we promoted automatically */
     return (p2ma == p2m_access_n2rwx);
diff -r 5416a3b371f2 -r f2d967332acc xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -164,8 +164,8 @@ static int __get_paged_frame(unsigned lo
         *frame = mfn_x(mfn);
         if ( p2m_is_paging(p2mt) )
         {
+            put_gfn(rd, gfn);
             p2m_mem_paging_populate(rd, gfn);
-            put_gfn(rd, gfn);
             rc = GNTST_eagain;
         }
     } else {
diff -r 5416a3b371f2 -r f2d967332acc xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -166,8 +166,8 @@ int guest_remove_page(struct domain *d, 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
+        put_gfn(d, gmfn);
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
-        put_gfn(d, gmfn);
         return 1;
     }
 #else
diff -r 5416a3b371f2 -r f2d967332acc xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -23,6 +23,7 @@
 
 int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                       XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
 /*
diff -r 5416a3b371f2 -r f2d967332acc xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,6 +24,9 @@
 #ifndef __MEM_EVENT_H__
 #define __MEM_EVENT_H__
 
+/* Returns whether a ring has been set up */
+bool_t mem_event_check_ring(struct mem_event_domain *med);
+
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
  * available space. For success or -EBUSY, the vCPU may be left blocked
  * temporarily to ensure that the ring does not lose future events.  In
diff -r 5416a3b371f2 -r f2d967332acc xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -494,9 +494,12 @@ static inline void p2m_mem_paging_popula
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
  * the rw2rx conversion. Boolean return value indicates if access rights have 
- * been promoted with no underlying vcpu pause. */
+ * been promoted with no underlying vcpu pause. If the req_ptr has been populated, 
+ * then the caller must put the event in the ring (once having released get_gfn*
+ * locks -- caller must also xfree the request. */
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
-                          bool_t access_r, bool_t access_w, bool_t access_x);
+                          bool_t access_r, bool_t access_w, bool_t access_x,
+                          mem_event_request_t **req_ptr);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
 
@@ -513,7 +516,8 @@ int p2m_get_mem_access(struct domain *d,
 #else
 static inline bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
-                                        bool_t access_w, bool_t access_x)
+                                        bool_t access_w, bool_t access_x,
+                                        mem_event_request_t **req_ptr)
 { return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqZ-0008B9-4O; Thu, 09 Feb 2012 04:43:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqX-00089F-7c
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328762573!12612986!2
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2MzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13448 invoked from network); 9 Feb 2012 04:42:54 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 04:42:54 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8658C458085;
	Wed,  8 Feb 2012 20:42:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Xo9YUmvczlQ6Z1qOYPElWYyv+yEXJx70EynyGVU6en7L
	OBMXSHxpMfKZsMERKwOQA/4A2d08Lpj+/Q7HyOnD2b+4WdXmfbPGljSkkRaKVWp8
	gYyF6uNT8W+EcQk0bA+U5yRUD/BRTvS3aw1OPQuH8cxQy01Da5W2GyjapKyKbcE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=J4NvSxEX/FMpR0M9Y8ZapZpIcL8=; b=YxKe2vcTBAW
	z8bj4kMlQm3fGkbIDPgWIY68oCVG50yPhrJLRKrg2BH71VW7xey120EWvAc1qUb1
	W4OsZbJMsLZ3qECNsPz1l8sGzb2lAsBHPS8vOC35sjv+PGKrhK7Z2HM1FgFtdmYc
	GWLcyRDdi2IsredfocFMvz/osniyhwKk=
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 CCDD2458079; 
	Wed,  8 Feb 2012 20:42:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 316d227dd52622b26b104751716f07d04b9f4337
Message-Id: <316d227dd52622b26b10.1328766350@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:50 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 7] x86/mm: Revert changeset
	24582:f6c33cfe7333
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


With synchronized p2m lookups this is no longer needed, and we can lock the p2m
up-front.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tjd-xen@phlegethon.org>

diff -r f2d967332acc -r 316d227dd526 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -361,6 +361,8 @@ void p2m_teardown(struct p2m_domain *p2m
     if (p2m == NULL)
         return;
 
+    p2m_lock(p2m);
+
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
@@ -374,8 +376,6 @@ void p2m_teardown(struct p2m_domain *p2m
     }
 #endif
 
-    p2m_lock(p2m);
-
     p2m->phys_table = pagetable_null();
 
     while ( (pg = page_list_remove_head(&p2m->pages)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqZ-0008B9-4O; Thu, 09 Feb 2012 04:43:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqX-00089F-7c
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328762573!12612986!2
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2MzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13448 invoked from network); 9 Feb 2012 04:42:54 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 04:42:54 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8658C458085;
	Wed,  8 Feb 2012 20:42:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Xo9YUmvczlQ6Z1qOYPElWYyv+yEXJx70EynyGVU6en7L
	OBMXSHxpMfKZsMERKwOQA/4A2d08Lpj+/Q7HyOnD2b+4WdXmfbPGljSkkRaKVWp8
	gYyF6uNT8W+EcQk0bA+U5yRUD/BRTvS3aw1OPQuH8cxQy01Da5W2GyjapKyKbcE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=J4NvSxEX/FMpR0M9Y8ZapZpIcL8=; b=YxKe2vcTBAW
	z8bj4kMlQm3fGkbIDPgWIY68oCVG50yPhrJLRKrg2BH71VW7xey120EWvAc1qUb1
	W4OsZbJMsLZ3qECNsPz1l8sGzb2lAsBHPS8vOC35sjv+PGKrhK7Z2HM1FgFtdmYc
	GWLcyRDdi2IsredfocFMvz/osniyhwKk=
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 CCDD2458079; 
	Wed,  8 Feb 2012 20:42:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 316d227dd52622b26b104751716f07d04b9f4337
Message-Id: <316d227dd52622b26b10.1328766350@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:50 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 7] x86/mm: Revert changeset
	24582:f6c33cfe7333
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


With synchronized p2m lookups this is no longer needed, and we can lock the p2m
up-front.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tjd-xen@phlegethon.org>

diff -r f2d967332acc -r 316d227dd526 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -361,6 +361,8 @@ void p2m_teardown(struct p2m_domain *p2m
     if (p2m == NULL)
         return;
 
+    p2m_lock(p2m);
+
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
@@ -374,8 +376,6 @@ void p2m_teardown(struct p2m_domain *p2m
     }
 #endif
 
-    p2m_lock(p2m);
-
     p2m->phys_table = pagetable_null();
 
     while ( (pg = page_list_remove_head(&p2m->pages)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqW-0008A1-5u; Thu, 09 Feb 2012 04:43:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqT-000894-N4
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328762541!59082643!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTgyMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15970 invoked from network); 9 Feb 2012 04:42:21 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-13.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:21 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 70BE8458081;
	Wed,  8 Feb 2012 20:42:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ADKSJg1v5nIqWE2S5IXNtTwcc5XYnMQTY9xO1k015ef0
	vscbLBkQarch7GECaoWefY5cnR37T6/+sVW7xxx80OGfyZpQlY0arT1MTr2N9tnm
	RLinysNOmdhcQ/94um/RufW4EGfyIZQarzf+jTeCRjdqW46SZyCJdBFJussCQWs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=xAv/Hb+smxgvHXoDiG2Maz014NE=; b=PxkC9yHi3k3
	7YJ5X4wxngB0E+WOd+Pf5sguS37OpSJQcaDimJPBxnUnSSFNESftfM8mNiFepabJ
	EUo8DXdwWXeAPPiNUhmGf7gkEM7rzUIbjOKUhl2/zuLTk6bwHYkfBZPXfp/chgA8
	W4kA+cRYszOuh2CKLEKYF39UgALLAjIg=
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 8B7BE458079; 
	Wed,  8 Feb 2012 20:42:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e29c2634afb1de9aee84e2fb976fc4636b918906
Message-Id: <e29c2634afb1de9aee84.1328766346@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 7] Make p2m lookups fully synchronized wrt
	modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c  |   8 +++++++
 xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
 xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
 xen/include/asm-x86/mm.h   |   6 ++--
 xen/include/asm-x86/p2m.h  |  47 ++++++++++++++++++++++++++++-----------------
 5 files changed, 84 insertions(+), 38 deletions(-)


We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.

The lock is always taken recursively, as there are many paths that
call get_gfn, and later, make another attempt at grabbing the p2m_lock.

The lock is not taken for shadow lookups. We believe there are no problems
remaining for synchronized p2m+shadow paging, but we are not enabling this
combination due to lack of testing. Unlocked shadow p2m access are tolerable as
long as shadows do not gain support for paging or sharing.

HAP (EPT) lookups and all modifications do take the lock.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1756949233a9 -r e29c2634afb1 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -786,7 +786,14 @@ hap_paging_get_mode(struct vcpu *v)
 static void hap_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
+    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
+    p2m_type_t t;
 
+    /* We hold onto the cr3 as it may be modified later, and
+     * we need to respect lock ordering. No need for 
+     * checks here as they are performed by vmx_load_pdptrs
+     * (the potential user of the cr3) */
+    (void)get_gfn(d, cr3_gfn, &t);
     paging_lock(d);
 
     v->arch.paging.mode = hap_paging_get_mode(v);
@@ -803,6 +810,7 @@ static void hap_update_paging_modes(stru
     hap_update_cr3(v, 0);
 
     paging_unlock(d);
+    put_gfn(d, cr3_gfn);
 }
 
 #if CONFIG_PAGING_LEVELS == 3
diff -r 1756949233a9 -r e29c2634afb1 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
+declare_mm_lock(nestedp2m)
+#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
+#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
+
+/* P2M lock (per-p2m-table)
+ * 
+ * This protects all queries and updates to the p2m table. 
+ *
+ * A note about ordering:
+ *   The order established here is enforced on all mutations of a p2m.
+ *   For lookups, the order established here is enforced only for hap
+ *   domains (1. shadow domains present a few nasty inversions; 
+ *            2. shadow domains do not support paging and sharing, 
+ *               the main sources of dynamic p2m mutations)
+ * 
+ * The lock is recursive as it is common for a code path to look up a gfn
+ * and later mutate it.
+ */
+
+declare_mm_lock(p2m)
+#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+
 /* Sharing per page lock
  *
  * This is an external lock, not represented by an mm_lock_t. The memory
@@ -167,21 +192,6 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
-declare_mm_lock(nestedp2m)
-#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
-#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
-
-/* P2M lock (per-p2m-table)
- * 
- * This protects all updates to the p2m table.  Updates are expected to
- * be safe against concurrent reads, which do *not* require the lock. */
-
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r 1756949233a9 -r e29c2634afb1 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -144,9 +144,9 @@ void p2m_change_entry_type_global(struct
     p2m_unlock(p2m);
 }
 
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order)
+                    unsigned int *page_order, bool_t locked)
 {
     mfn_t mfn;
 
@@ -158,6 +158,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
         return _mfn(gfn);
     }
 
+    /* For now only perform locking on hap domains */
+    if ( locked && (hap_enabled(p2m->domain)) )
+        /* Grab the lock here, don't release until put_gfn */
+        p2m_lock(p2m);
+
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
@@ -182,6 +187,18 @@ mfn_t get_gfn_type_access(struct p2m_dom
     return mfn;
 }
 
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
+{
+    if ( !p2m || !paging_mode_translate(p2m->domain) 
+              || !hap_enabled(p2m->domain) )
+        /* Nothing to do in this case */
+        return;
+
+    ASSERT(p2m_locked_by_me(p2m));
+
+    p2m_unlock(p2m);
+}
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 1756949233a9 -r e29c2634afb1 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -350,9 +350,9 @@ void clear_superpage_mark(struct page_in
  * of (gfn,domain) tupples to a list of gfn's that the shared page is currently 
  * backing. Nesting may happen when sharing (and locking) two pages -- deadlock 
  * is avoided by locking pages in increasing order.
- * Memory sharing may take the p2m_lock within a page_lock/unlock
- * critical section. We enforce ordering between page_lock and p2m_lock using an
- * mm-locks.h construct. 
+ * All memory sharing code paths take the p2m lock of the affected gfn before
+ * taking the lock for the underlying page. We enforce ordering between page_lock 
+ * and p2m_lock using an mm-locks.h construct. 
  *
  * These two users (pte serialization and memory sharing) do not collide, since
  * sharing is only supported for hvm guests, which do not perform pv pte updates.
diff -r 1756949233a9 -r e29c2634afb1 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -309,9 +309,14 @@ struct p2m_domain *p2m_get_p2m(struct vc
 
 #define p2m_get_pagetable(p2m)  ((p2m)->phys_table)
 
-/**** p2m query accessors. After calling any of the variants below, you
- * need to call put_gfn(domain, gfn). If you don't, you'll lock the
- * hypervisor. ****/
+/**** p2m query accessors. They lock p2m_lock, and thus serialize
+ * lookups wrt modifications. They _do not_ release the lock on exit.
+ * After calling any of the variants below, caller needs to use
+ * put_gfn. ****/
+
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+                    unsigned int *page_order, bool_t locked);
 
 /* Read a particular P2M table, mapping pages as we go.  Most callers
  * should _not_ call this directly; use the other get_gfn* functions
@@ -320,9 +325,8 @@ struct p2m_domain *p2m_get_p2m(struct vc
  * If the lookup succeeds, the return value is != INVALID_MFN and 
  * *page_order is filled in with the order of the superpage (if any) that
  * the entry was found in.  */
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
-                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order);
+#define get_gfn_type_access(p, g, t, a, q, o)   \
+        __get_gfn_type_access((p), (g), (t), (a), (q), (o), 1)
 
 /* General conversion function from gfn to mfn */
 static inline mfn_t get_gfn_type(struct domain *d,
@@ -353,21 +357,28 @@ static inline unsigned long get_gfn_unty
     return INVALID_MFN;
 }
 
-/* This is a noop for now. */
-static inline void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
-{
-}
+/* Will release the p2m_lock for this gfn entry. */
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
 #define put_gfn(d, gfn) __put_gfn(p2m_get_hostp2m((d)), (gfn))
 
-/* These are identical for now. The intent is to have the caller not worry 
- * about put_gfn. To only be used in printk's, crash situations, or to 
- * peek at a type. You're not holding the p2m entry exclsively after calling
- * this. */
-#define get_gfn_unlocked(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
-#define get_gfn_query_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_guest_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_guest)
-#define get_gfn_unshare_unlocked(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
+/* The intent of the "unlocked" accessor is to have the caller not worry about
+ * put_gfn. They apply to very specific situations: debug printk's, dumps 
+ * during a domain crash, or to peek at a p2m entry/type. Caller is not 
+ * holding the p2m entry exclusively during or after calling this. 
+ *
+ * Note that an unlocked accessor only makes sense for a "query" lookup.
+ * Any other type of query can cause a change in the p2m and may need to
+ * perform locking.
+ */
+static inline mfn_t get_gfn_query_unlocked(struct domain *d, 
+                                           unsigned long gfn, 
+                                           p2m_type_t *t)
+{
+    p2m_access_t a;
+    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 
+                                    p2m_query, NULL, 0);
+}
 
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqW-0008A1-5u; Thu, 09 Feb 2012 04:43:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqT-000894-N4
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:42:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328762541!59082643!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTgyMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15970 invoked from network); 9 Feb 2012 04:42:21 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-13.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:21 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 70BE8458081;
	Wed,  8 Feb 2012 20:42:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ADKSJg1v5nIqWE2S5IXNtTwcc5XYnMQTY9xO1k015ef0
	vscbLBkQarch7GECaoWefY5cnR37T6/+sVW7xxx80OGfyZpQlY0arT1MTr2N9tnm
	RLinysNOmdhcQ/94um/RufW4EGfyIZQarzf+jTeCRjdqW46SZyCJdBFJussCQWs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=xAv/Hb+smxgvHXoDiG2Maz014NE=; b=PxkC9yHi3k3
	7YJ5X4wxngB0E+WOd+Pf5sguS37OpSJQcaDimJPBxnUnSSFNESftfM8mNiFepabJ
	EUo8DXdwWXeAPPiNUhmGf7gkEM7rzUIbjOKUhl2/zuLTk6bwHYkfBZPXfp/chgA8
	W4kA+cRYszOuh2CKLEKYF39UgALLAjIg=
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 8B7BE458079; 
	Wed,  8 Feb 2012 20:42:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e29c2634afb1de9aee84e2fb976fc4636b918906
Message-Id: <e29c2634afb1de9aee84.1328766346@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 7] Make p2m lookups fully synchronized wrt
	modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c  |   8 +++++++
 xen/arch/x86/mm/mm-locks.h |  40 ++++++++++++++++++++++++--------------
 xen/arch/x86/mm/p2m.c      |  21 ++++++++++++++++++-
 xen/include/asm-x86/mm.h   |   6 ++--
 xen/include/asm-x86/p2m.h  |  47 ++++++++++++++++++++++++++++-----------------
 5 files changed, 84 insertions(+), 38 deletions(-)


We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.

The lock is always taken recursively, as there are many paths that
call get_gfn, and later, make another attempt at grabbing the p2m_lock.

The lock is not taken for shadow lookups. We believe there are no problems
remaining for synchronized p2m+shadow paging, but we are not enabling this
combination due to lack of testing. Unlocked shadow p2m access are tolerable as
long as shadows do not gain support for paging or sharing.

HAP (EPT) lookups and all modifications do take the lock.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1756949233a9 -r e29c2634afb1 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -786,7 +786,14 @@ hap_paging_get_mode(struct vcpu *v)
 static void hap_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
+    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
+    p2m_type_t t;
 
+    /* We hold onto the cr3 as it may be modified later, and
+     * we need to respect lock ordering. No need for 
+     * checks here as they are performed by vmx_load_pdptrs
+     * (the potential user of the cr3) */
+    (void)get_gfn(d, cr3_gfn, &t);
     paging_lock(d);
 
     v->arch.paging.mode = hap_paging_get_mode(v);
@@ -803,6 +810,7 @@ static void hap_update_paging_modes(stru
     hap_update_cr3(v, 0);
 
     paging_unlock(d);
+    put_gfn(d, cr3_gfn);
 }
 
 #if CONFIG_PAGING_LEVELS == 3
diff -r 1756949233a9 -r e29c2634afb1 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -144,6 +144,31 @@ static inline void mm_enforce_order_unlo
  *                                                                      *
  ************************************************************************/
 
+declare_mm_lock(nestedp2m)
+#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
+#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
+
+/* P2M lock (per-p2m-table)
+ * 
+ * This protects all queries and updates to the p2m table. 
+ *
+ * A note about ordering:
+ *   The order established here is enforced on all mutations of a p2m.
+ *   For lookups, the order established here is enforced only for hap
+ *   domains (1. shadow domains present a few nasty inversions; 
+ *            2. shadow domains do not support paging and sharing, 
+ *               the main sources of dynamic p2m mutations)
+ * 
+ * The lock is recursive as it is common for a code path to look up a gfn
+ * and later mutate it.
+ */
+
+declare_mm_lock(p2m)
+#define p2m_lock(p)           mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
+#define p2m_unlock(p)         mm_unlock(&(p)->lock)
+#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
+
 /* Sharing per page lock
  *
  * This is an external lock, not represented by an mm_lock_t. The memory
@@ -167,21 +192,6 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
-declare_mm_lock(nestedp2m)
-#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
-#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
-
-/* P2M lock (per-p2m-table)
- * 
- * This protects all updates to the p2m table.  Updates are expected to
- * be safe against concurrent reads, which do *not* require the lock. */
-
-declare_mm_lock(p2m)
-#define p2m_lock(p)           mm_lock(p2m, &(p)->lock)
-#define p2m_lock_recursive(p) mm_lock_recursive(p2m, &(p)->lock)
-#define p2m_unlock(p)         mm_unlock(&(p)->lock)
-#define p2m_locked_by_me(p)   mm_locked_by_me(&(p)->lock)
-
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r 1756949233a9 -r e29c2634afb1 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -144,9 +144,9 @@ void p2m_change_entry_type_global(struct
     p2m_unlock(p2m);
 }
 
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
                     p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order)
+                    unsigned int *page_order, bool_t locked)
 {
     mfn_t mfn;
 
@@ -158,6 +158,11 @@ mfn_t get_gfn_type_access(struct p2m_dom
         return _mfn(gfn);
     }
 
+    /* For now only perform locking on hap domains */
+    if ( locked && (hap_enabled(p2m->domain)) )
+        /* Grab the lock here, don't release until put_gfn */
+        p2m_lock(p2m);
+
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
@@ -182,6 +187,18 @@ mfn_t get_gfn_type_access(struct p2m_dom
     return mfn;
 }
 
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
+{
+    if ( !p2m || !paging_mode_translate(p2m->domain) 
+              || !hap_enabled(p2m->domain) )
+        /* Nothing to do in this case */
+        return;
+
+    ASSERT(p2m_locked_by_me(p2m));
+
+    p2m_unlock(p2m);
+}
+
 int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
diff -r 1756949233a9 -r e29c2634afb1 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -350,9 +350,9 @@ void clear_superpage_mark(struct page_in
  * of (gfn,domain) tupples to a list of gfn's that the shared page is currently 
  * backing. Nesting may happen when sharing (and locking) two pages -- deadlock 
  * is avoided by locking pages in increasing order.
- * Memory sharing may take the p2m_lock within a page_lock/unlock
- * critical section. We enforce ordering between page_lock and p2m_lock using an
- * mm-locks.h construct. 
+ * All memory sharing code paths take the p2m lock of the affected gfn before
+ * taking the lock for the underlying page. We enforce ordering between page_lock 
+ * and p2m_lock using an mm-locks.h construct. 
  *
  * These two users (pte serialization and memory sharing) do not collide, since
  * sharing is only supported for hvm guests, which do not perform pv pte updates.
diff -r 1756949233a9 -r e29c2634afb1 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -309,9 +309,14 @@ struct p2m_domain *p2m_get_p2m(struct vc
 
 #define p2m_get_pagetable(p2m)  ((p2m)->phys_table)
 
-/**** p2m query accessors. After calling any of the variants below, you
- * need to call put_gfn(domain, gfn). If you don't, you'll lock the
- * hypervisor. ****/
+/**** p2m query accessors. They lock p2m_lock, and thus serialize
+ * lookups wrt modifications. They _do not_ release the lock on exit.
+ * After calling any of the variants below, caller needs to use
+ * put_gfn. ****/
+
+mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
+                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+                    unsigned int *page_order, bool_t locked);
 
 /* Read a particular P2M table, mapping pages as we go.  Most callers
  * should _not_ call this directly; use the other get_gfn* functions
@@ -320,9 +325,8 @@ struct p2m_domain *p2m_get_p2m(struct vc
  * If the lookup succeeds, the return value is != INVALID_MFN and 
  * *page_order is filled in with the order of the superpage (if any) that
  * the entry was found in.  */
-mfn_t get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
-                    p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-                    unsigned int *page_order);
+#define get_gfn_type_access(p, g, t, a, q, o)   \
+        __get_gfn_type_access((p), (g), (t), (a), (q), (o), 1)
 
 /* General conversion function from gfn to mfn */
 static inline mfn_t get_gfn_type(struct domain *d,
@@ -353,21 +357,28 @@ static inline unsigned long get_gfn_unty
     return INVALID_MFN;
 }
 
-/* This is a noop for now. */
-static inline void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
-{
-}
+/* Will release the p2m_lock for this gfn entry. */
+void __put_gfn(struct p2m_domain *p2m, unsigned long gfn);
 
 #define put_gfn(d, gfn) __put_gfn(p2m_get_hostp2m((d)), (gfn))
 
-/* These are identical for now. The intent is to have the caller not worry 
- * about put_gfn. To only be used in printk's, crash situations, or to 
- * peek at a type. You're not holding the p2m entry exclsively after calling
- * this. */
-#define get_gfn_unlocked(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
-#define get_gfn_query_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_guest_unlocked(d, g, t)   get_gfn_type((d), (g), (t), p2m_guest)
-#define get_gfn_unshare_unlocked(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
+/* The intent of the "unlocked" accessor is to have the caller not worry about
+ * put_gfn. They apply to very specific situations: debug printk's, dumps 
+ * during a domain crash, or to peek at a p2m entry/type. Caller is not 
+ * holding the p2m entry exclusively during or after calling this. 
+ *
+ * Note that an unlocked accessor only makes sense for a "query" lookup.
+ * Any other type of query can cause a change in the p2m and may need to
+ * perform locking.
+ */
+static inline mfn_t get_gfn_query_unlocked(struct domain *d, 
+                                           unsigned long gfn, 
+                                           p2m_type_t *t)
+{
+    p2m_access_t a;
+    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 
+                                    p2m_query, NULL, 0);
+}
 
 /* General conversion function from mfn to gfn */
 static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqY-0008Aq-N4; Thu, 09 Feb 2012 04:43:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqW-00089D-9j
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328762573!12612986!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2MzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13416 invoked from network); 9 Feb 2012 04:42:53 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 04:42:53 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8CCBD45807C;
	Wed,  8 Feb 2012 20:42:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Ib+GQcDyGWLIrP41+SIzyWHseOgPzV3b4z9PNCnDa0Hj
	6w2Kx/6HvixX6Bd5Xv6y++8J2Di8d4OokYDswaNS11NeXr2G2G14KVjSS04d5/53
	lWyEpI9ze1uymjhrTTUz6AqGtzmRGQNJLejoLr1V+i2LTaUHNlEiKjxjXOAEfUQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PH2mbopPink/K5ZabLKSQT7GYpk=; b=mYbzjwqy+BD
	iE3heSM9KZXlD8lvDFnCu4NMDLPtakQgjQOwpwYRogh3rOJsnabNucNgD09Vb1Hx
	Ai9P4AjqMRd4c9dVb9jxC/iDKbiUsemq3ETmaFLlaHTdo3k+gmnVEzJaatCqYwSG
	fh5bUfvQZPOK0bgnAdDxfGhgKRvb0o7Y=
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 A5585458079; 
	Wed,  8 Feb 2012 20:42:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5416a3b371f2387dfcf2d9de4fd2c9c98696b429
Message-Id: <5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:48 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mm-locks.h |   10 ++++
 xen/arch/x86/mm/p2m-pod.c  |  110 ++++++++++++++++++++++++++------------------
 xen/arch/x86/mm/p2m-pt.c   |    1 +
 xen/arch/x86/mm/p2m.c      |    8 ++-
 xen/include/asm-x86/p2m.h  |   27 +++-------
 5 files changed, 91 insertions(+), 65 deletions(-)


The PoD layer has a complex locking discipline. It relies on the
p2m being globally locked, and it also relies on the page alloc
lock to protect some of its data structures. Replace this all by an
explicit pod lock: per p2m, order enforced.

Three consequences:
    - Critical sections in the pod code protected by the page alloc
      lock are now reduced to modifications of the domain page list.
    - When the p2m lock becomes fine-grained, there are no
      assumptions broken in the PoD layer.
    - The locking is easier to understand.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -194,6 +194,16 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
+/* PoD lock (per-p2m-table)
+ * 
+ * Protects private PoD data structs: entry and cache
+ * counts, page lists, sweep parameters. */
+
+declare_mm_lock(pod)
+#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
+#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
+
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -100,7 +100,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
     }
 #endif
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(pod_locked_by_me(p2m));
 
     /*
      * Pages from domain_alloc and returned by the balloon driver aren't
@@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         unmap_domain_page(b);
     }
 
+    /* First, take all pages off the domain list */
     lock_page_alloc(p2m);
-
-    /* First, take all pages off the domain list */
     for(i=0; i < 1 << order ; i++)
     {
         p = page + i;
         page_list_del(p, &d->page_list);
     }
 
+    /* Ensure that the PoD cache has never been emptied.  
+     * This may cause "zombie domains" since the page will never be freed. */
+    BUG_ON( d->arch.relmem != RELMEM_not_started );
+
+    unlock_page_alloc(p2m);
+
     /* Then add the first one to the appropriate populate-on-demand list */
     switch(order)
     {
@@ -138,25 +143,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         BUG();
     }
 
-    /* Ensure that the PoD cache has never been emptied.  
-     * This may cause "zombie domains" since the page will never be freed. */
-    BUG_ON( d->arch.relmem != RELMEM_not_started );
-
-    unlock_page_alloc(p2m);
-
     return 0;
 }
 
 /* Get a page of size order from the populate-on-demand cache.  Will break
  * down 2-meg pages into singleton pages automatically.  Returns null if
- * a superpage is requested and no superpages are available.  Must be called
- * with the d->page_lock held. */
+ * a superpage is requested and no superpages are available. */
 static struct page_info * p2m_pod_cache_get(struct p2m_domain *p2m,
                                             unsigned long order)
 {
     struct page_info *p = NULL;
     int i;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
     {
         return NULL;
@@ -185,7 +185,7 @@ static struct page_info * p2m_pod_cache_
     case PAGE_ORDER_2M:
         BUG_ON( page_list_empty(&p2m->pod.super) );
         p = page_list_remove_head(&p2m->pod.super);
-        p2m->pod.count -= 1 << order; /* Lock: page_alloc */
+        p2m->pod.count -= 1 << order;
         break;
     case PAGE_ORDER_4K:
         BUG_ON( page_list_empty(&p2m->pod.single) );
@@ -197,11 +197,13 @@ static struct page_info * p2m_pod_cache_
     }
 
     /* Put the pages back on the domain page_list */
+    lock_page_alloc(p2m);
     for ( i = 0 ; i < (1 << order); i++ )
     {
         BUG_ON(page_get_owner(p + i) != p2m->domain);
         page_list_add_tail(p + i, &p2m->domain->page_list);
     }
+    unlock_page_alloc(p2m);
 
     return p;
 }
@@ -213,6 +215,8 @@ p2m_pod_set_cache_target(struct p2m_doma
     struct domain *d = p2m->domain;
     int ret = 0;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     /* Increasing the target */
     while ( pod_target > p2m->pod.count )
     {
@@ -250,17 +254,13 @@ p2m_pod_set_cache_target(struct p2m_doma
     }
 
     /* Decreasing the target */
-    /* We hold the p2m lock here, so we don't need to worry about
+    /* We hold the pod lock here, so we don't need to worry about
      * cache disappearing under our feet. */
     while ( pod_target < p2m->pod.count )
     {
         struct page_info * page;
         int order, i;
 
-        /* Grab the lock before checking that pod.super is empty, or the last
-         * entries may disappear before we grab the lock. */
-        lock_page_alloc(p2m);
-
         if ( (p2m->pod.count - pod_target) > SUPERPAGE_PAGES
              && !page_list_empty(&p2m->pod.super) )
             order = PAGE_ORDER_2M;
@@ -271,8 +271,6 @@ p2m_pod_set_cache_target(struct p2m_doma
 
         ASSERT(page != NULL);
 
-        unlock_page_alloc(p2m);
-
         /* Then free them */
         for ( i = 0 ; i < (1 << order) ; i++ )
         {
@@ -348,7 +346,7 @@ p2m_pod_set_mem_target(struct domain *d,
     int ret = 0;
     unsigned long populated;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
 
     /* P == B: Nothing to do. */
     if ( p2m->pod.entry_count == 0 )
@@ -377,7 +375,7 @@ p2m_pod_set_mem_target(struct domain *d,
     ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
 
 out:
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
 
     return ret;
 }
@@ -390,7 +388,7 @@ p2m_pod_empty_cache(struct domain *d)
 
     /* After this barrier no new PoD activities can happen. */
     BUG_ON(!d->is_dying);
-    spin_barrier(&p2m->lock.lock);
+    spin_barrier(&p2m->pod.lock.lock);
 
     lock_page_alloc(p2m);
 
@@ -431,7 +429,7 @@ p2m_pod_offline_or_broken_hit(struct pag
     if ( !(d = page_get_owner(p)) || !(p2m = p2m_get_hostp2m(d)) )
         return 0;
 
-    lock_page_alloc(p2m);
+    pod_lock(p2m);
     bmfn = mfn_x(page_to_mfn(p));
     page_list_for_each_safe(q, tmp, &p2m->pod.super)
     {
@@ -462,12 +460,14 @@ p2m_pod_offline_or_broken_hit(struct pag
         }
     }
 
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 0;
 
 pod_hit:
+    lock_page_alloc(p2m);
     page_list_add_tail(p, &d->arch.relmem_list);
     unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 1;
 }
 
@@ -486,9 +486,9 @@ p2m_pod_offline_or_broken_replace(struct
     if ( unlikely(!p) )
         return;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
     p2m_pod_cache_add(p2m, p, PAGE_ORDER_4K);
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
     return;
 }
 
@@ -511,18 +511,18 @@ p2m_pod_decrease_reservation(struct doma
 
     int steal_for_cache = 0;
     int pod = 0, nonpod = 0, ram = 0;
-    
+
+    gfn_lock(p2m, gpfn, order);
+    pod_lock(p2m);    
 
     /* If we don't have any outstanding PoD entries, let things take their
      * course */
     if ( p2m->pod.entry_count == 0 )
-        goto out;
+        goto out_unlock;
 
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    gfn_lock(p2m, gpfn, order);
-
     if ( unlikely(d->is_dying) )
         goto out_unlock;
 
@@ -554,7 +554,7 @@ p2m_pod_decrease_reservation(struct doma
         /* All PoD: Mark the whole region invalid and tell caller
          * we're done. */
         set_p2m_entry(p2m, gpfn, _mfn(INVALID_MFN), order, p2m_invalid, p2m->default_access);
-        p2m->pod.entry_count-=(1<<order); /* Lock: p2m */
+        p2m->pod.entry_count-=(1<<order);
         BUG_ON(p2m->pod.entry_count < 0);
         ret = 1;
         goto out_entry_check;
@@ -578,7 +578,7 @@ p2m_pod_decrease_reservation(struct doma
         if ( t == p2m_populate_on_demand )
         {
             set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, p2m->default_access);
-            p2m->pod.entry_count--; /* Lock: p2m */
+            p2m->pod.entry_count--;
             BUG_ON(p2m->pod.entry_count < 0);
             pod--;
         }
@@ -615,9 +615,8 @@ out_entry_check:
     }
 
 out_unlock:
+    pod_unlock(p2m);
     gfn_unlock(p2m, gpfn, order);
-
-out:
     return ret;
 }
 
@@ -630,7 +629,8 @@ void p2m_pod_dump_data(struct domain *d)
 
 
 /* Search for all-zero superpages to be reclaimed as superpages for the
- * PoD cache. Must be called w/ p2m lock held, page_alloc lock not held. */
+ * PoD cache. Must be called w/ pod lock held, must lock the superpage
+ * in the p2m */
 static int
 p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn)
 {
@@ -642,6 +642,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     int max_ref = 1;
     struct domain *d = p2m->domain;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( !superpage_aligned(gfn) )
         goto out;
 
@@ -649,6 +651,10 @@ p2m_pod_zero_check_superpage(struct p2m_
     if ( paging_mode_shadow(d) )
         max_ref++;
 
+    /* NOTE: this is why we don't enforce deadlock constraints between p2m 
+     * and pod locks */
+    gfn_lock(p2m, gfn, SUPERPAGE_ORDER);
+
     /* Look up the mfns, checking to make sure they're the same mfn
      * and aligned, and mapping them. */
     for ( i=0; i<SUPERPAGE_PAGES; i++ )
@@ -761,6 +767,7 @@ out_reset:
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);
     
 out:
+    gfn_unlock(p2m, gfn, SUPERPAGE_ORDER);
     return ret;
 }
 
@@ -922,6 +929,10 @@ p2m_pod_emergency_sweep(struct p2m_domai
     limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
 
     /* FIXME: Figure out how to avoid superpages */
+    /* NOTE: Promote to globally locking the p2m. This will get complicated
+     * in a fine-grained scenario. If we lock each gfn individually we must be
+     * careful about spinlock recursion limits and POD_SWEEP_STRIDE. */
+    p2m_lock(p2m);
     for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
     {
         p2m_access_t a;
@@ -940,7 +951,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
         /* Stop if we're past our limit and we have found *something*.
          *
          * NB that this is a zero-sum game; we're increasing our cache size
-         * by re-increasing our 'debt'.  Since we hold the p2m lock,
+         * by re-increasing our 'debt'.  Since we hold the pod lock,
          * (entry_count - count) must remain the same. */
         if ( p2m->pod.count > 0 && i < limit )
             break;
@@ -949,6 +960,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
     if ( j )
         p2m_pod_zero_check(p2m, gfns, j);
 
+    p2m_unlock(p2m);
     p2m->pod.reclaim_single = i ? i - 1 : i;
 
 }
@@ -965,8 +977,9 @@ p2m_pod_demand_populate(struct p2m_domai
     int i;
 
     ASSERT(gfn_locked_by_me(p2m, gfn));
+    pod_lock(p2m);
 
-    /* This check is done with the p2m lock held.  This will make sure that
+    /* This check is done with the pod lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
      * won't start until we're done. */
     if ( unlikely(d->is_dying) )
@@ -977,6 +990,7 @@ p2m_pod_demand_populate(struct p2m_domai
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
     {
+        pod_unlock(p2m);
         gfn_aligned = (gfn >> order) << order;
         /* Note that we are supposed to call set_p2m_entry() 512 times to 
          * split 1GB into 512 2MB pages here. But We only do once here because
@@ -1000,11 +1014,15 @@ p2m_pod_demand_populate(struct p2m_domai
 
         /* If we're low, start a sweep */
         if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
+            /* Note that sweeps scan other ranges in the p2m. In an scenario
+             * in which p2m locks are fine-grained, this may result in deadlock.
+             * Using trylock on the gfn's as we sweep would avoid it. */
             p2m_pod_emergency_sweep_super(p2m);
 
         if ( page_list_empty(&p2m->pod.single) &&
              ( ( order == PAGE_ORDER_4K )
                || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
+            /* Same comment regarding deadlock applies */
             p2m_pod_emergency_sweep(p2m);
     }
 
@@ -1012,8 +1030,6 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( q == p2m_guest && gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    lock_page_alloc(p2m);
-
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 
@@ -1026,8 +1042,6 @@ p2m_pod_demand_populate(struct p2m_domai
 
     BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
 
-    unlock_page_alloc(p2m);
-
     gfn_aligned = (gfn >> order) << order;
 
     set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw, p2m->default_access);
@@ -1038,7 +1052,7 @@ p2m_pod_demand_populate(struct p2m_domai
         paging_mark_dirty(d, mfn_x(mfn) + i);
     }
     
-    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
+    p2m->pod.entry_count -= (1 << order);
     BUG_ON(p2m->pod.entry_count < 0);
 
     if ( tb_init_done )
@@ -1056,20 +1070,24 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    pod_unlock(p2m);
     return 0;
 out_of_memory:
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 " pod_entries %" PRIi32 "\n",
            __func__, d->tot_pages, p2m->pod.entry_count);
     domain_crash(d);
 out_fail:
+    pod_unlock(p2m);
     return -1;
 remap_and_retry:
     BUG_ON(order != PAGE_ORDER_2M);
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     /* Remap this 2-meg region in singleton chunks */
+    /* NOTE: In a p2m fine-grained lock scenario this might
+     * need promoting the gfn lock from gfn->2M superpage */
     gfn_aligned = (gfn>>order)<<order;
     for(i=0; i<(1<<order); i++)
         set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
@@ -1137,9 +1155,11 @@ guest_physmap_mark_populate_on_demand(st
         rc = -EINVAL;
     else
     {
-        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
+        pod_lock(p2m);
+        p2m->pod.entry_count += 1 << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
+        pod_unlock(p2m);
     }
 
     gfn_unlock(p2m, gfn, order);
diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain 
     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) );
diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
     mm_lock_init(&p2m->lock);
+    mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
     INIT_PAGE_LIST_HEAD(&p2m->pod.super);
@@ -568,8 +569,10 @@ guest_physmap_add_entry(struct domain *d
             rc = -EINVAL;
         else
         {
-            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
+            pod_lock(p2m);
+            p2m->pod.entry_count -= pod_count;
             BUG_ON(p2m->pod.entry_count < 0);
+            pod_unlock(p2m);
         }
     }
 
@@ -1350,6 +1353,7 @@ p2m_flush_table(struct p2m_domain *p2m)
     /* "Host" p2m tables can have shared entries &c that need a bit more 
      * care when discarding them */
     ASSERT(p2m_is_nestedp2m(p2m));
+    /* Nested p2m's do not do pod, hence the asserts (and no pod lock)*/
     ASSERT(page_list_empty(&p2m->pod.super));
     ASSERT(page_list_empty(&p2m->pod.single));
 
@@ -1507,6 +1511,7 @@ void audit_p2m(struct domain *d,
     P2M_PRINTK("p2m audit starts\n");
 
     p2m_lock(p2m);
+    pod_lock(p2m);
 
     if (p2m->audit_p2m)
         pmbad = p2m->audit_p2m(p2m);
@@ -1567,6 +1572,7 @@ void audit_p2m(struct domain *d,
     }
     spin_unlock(&d->page_alloc_lock);
 
+    pod_unlock(p2m);
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
diff -r 63cb81c2448e -r 5416a3b371f2 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -261,25 +261,12 @@ struct p2m_domain {
     unsigned long max_mapped_pfn;
 
     /* Populate-on-demand variables
-     * NB on locking.  {super,single,count} are
-     * covered by d->page_alloc_lock, since they're almost always used in
-     * conjunction with that functionality.  {entry_count} is covered by
-     * the domain p2m lock, since it's almost always used in conjunction
-     * with changing the p2m tables.
-     *
-     * At this point, both locks are held in two places.  In both,
-     * the order is [p2m,page_alloc]:
-     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
-     *   which grabs page_alloc
-     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
-     *   double-demand-populating of pages, the page_alloc lock to
-     *   protect moving stuff from the PoD cache to the domain page list.
-     *
-     * We enforce this lock ordering through a construct in mm-locks.h.
-     * This demands, however, that we store the previous lock-ordering
-     * level in effect before grabbing the page_alloc lock. The unlock
-     * level is stored in the arch section of the domain struct.
-     */
+     * All variables are protected with the pod lock. We cannot rely on
+     * the p2m lock if it's turned into a fine-grained lock.
+     * We only use the domain page_alloc lock for additions and 
+     * deletions to the domain's page list. Because we use it nested
+     * within the PoD lock, we enforce it's ordering (by remembering
+     * the unlock level in the arch_domain sub struct). */
     struct {
         struct page_list_head super,   /* List of superpages                */
                          single;       /* Non-super lists                   */
@@ -288,6 +275,8 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+        mm_lock_t        lock;         /* Locking of private pod structs,   *
+                                        * not relying on the p2m lock.      */
     } pod;
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqY-0008Aq-N4; Thu, 09 Feb 2012 04:43:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqW-00089D-9j
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328762573!12612986!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2MzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13416 invoked from network); 9 Feb 2012 04:42:53 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-11.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 04:42:53 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8CCBD45807C;
	Wed,  8 Feb 2012 20:42:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Ib+GQcDyGWLIrP41+SIzyWHseOgPzV3b4z9PNCnDa0Hj
	6w2Kx/6HvixX6Bd5Xv6y++8J2Di8d4OokYDswaNS11NeXr2G2G14KVjSS04d5/53
	lWyEpI9ze1uymjhrTTUz6AqGtzmRGQNJLejoLr1V+i2LTaUHNlEiKjxjXOAEfUQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PH2mbopPink/K5ZabLKSQT7GYpk=; b=mYbzjwqy+BD
	iE3heSM9KZXlD8lvDFnCu4NMDLPtakQgjQOwpwYRogh3rOJsnabNucNgD09Vb1Hx
	Ai9P4AjqMRd4c9dVb9jxC/iDKbiUsemq3ETmaFLlaHTdo3k+gmnVEzJaatCqYwSG
	fh5bUfvQZPOK0bgnAdDxfGhgKRvb0o7Y=
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 A5585458079; 
	Wed,  8 Feb 2012 20:42:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5416a3b371f2387dfcf2d9de4fd2c9c98696b429
Message-Id: <5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:48 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mm-locks.h |   10 ++++
 xen/arch/x86/mm/p2m-pod.c  |  110 ++++++++++++++++++++++++++------------------
 xen/arch/x86/mm/p2m-pt.c   |    1 +
 xen/arch/x86/mm/p2m.c      |    8 ++-
 xen/include/asm-x86/p2m.h  |   27 +++-------
 5 files changed, 91 insertions(+), 65 deletions(-)


The PoD layer has a complex locking discipline. It relies on the
p2m being globally locked, and it also relies on the page alloc
lock to protect some of its data structures. Replace this all by an
explicit pod lock: per p2m, order enforced.

Three consequences:
    - Critical sections in the pod code protected by the page alloc
      lock are now reduced to modifications of the domain page list.
    - When the p2m lock becomes fine-grained, there are no
      assumptions broken in the PoD layer.
    - The locking is easier to understand.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -194,6 +194,16 @@ declare_mm_order_constraint(per_page_sha
  * - setting the "cr3" field of any p2m table to a non-CR3_EADDR value. 
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
+/* PoD lock (per-p2m-table)
+ * 
+ * Protects private PoD data structs: entry and cache
+ * counts, page lists, sweep parameters. */
+
+declare_mm_lock(pod)
+#define pod_lock(p)           mm_lock(pod, &(p)->pod.lock)
+#define pod_unlock(p)         mm_unlock(&(p)->pod.lock)
+#define pod_locked_by_me(p)   mm_locked_by_me(&(p)->pod.lock)
+
 /* Page alloc lock (per-domain)
  *
  * This is an external lock, not represented by an mm_lock_t. However, 
diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -100,7 +100,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m
     }
 #endif
 
-    ASSERT(p2m_locked_by_me(p2m));
+    ASSERT(pod_locked_by_me(p2m));
 
     /*
      * Pages from domain_alloc and returned by the balloon driver aren't
@@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         unmap_domain_page(b);
     }
 
+    /* First, take all pages off the domain list */
     lock_page_alloc(p2m);
-
-    /* First, take all pages off the domain list */
     for(i=0; i < 1 << order ; i++)
     {
         p = page + i;
         page_list_del(p, &d->page_list);
     }
 
+    /* Ensure that the PoD cache has never been emptied.  
+     * This may cause "zombie domains" since the page will never be freed. */
+    BUG_ON( d->arch.relmem != RELMEM_not_started );
+
+    unlock_page_alloc(p2m);
+
     /* Then add the first one to the appropriate populate-on-demand list */
     switch(order)
     {
@@ -138,25 +143,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
         BUG();
     }
 
-    /* Ensure that the PoD cache has never been emptied.  
-     * This may cause "zombie domains" since the page will never be freed. */
-    BUG_ON( d->arch.relmem != RELMEM_not_started );
-
-    unlock_page_alloc(p2m);
-
     return 0;
 }
 
 /* Get a page of size order from the populate-on-demand cache.  Will break
  * down 2-meg pages into singleton pages automatically.  Returns null if
- * a superpage is requested and no superpages are available.  Must be called
- * with the d->page_lock held. */
+ * a superpage is requested and no superpages are available. */
 static struct page_info * p2m_pod_cache_get(struct p2m_domain *p2m,
                                             unsigned long order)
 {
     struct page_info *p = NULL;
     int i;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
     {
         return NULL;
@@ -185,7 +185,7 @@ static struct page_info * p2m_pod_cache_
     case PAGE_ORDER_2M:
         BUG_ON( page_list_empty(&p2m->pod.super) );
         p = page_list_remove_head(&p2m->pod.super);
-        p2m->pod.count -= 1 << order; /* Lock: page_alloc */
+        p2m->pod.count -= 1 << order;
         break;
     case PAGE_ORDER_4K:
         BUG_ON( page_list_empty(&p2m->pod.single) );
@@ -197,11 +197,13 @@ static struct page_info * p2m_pod_cache_
     }
 
     /* Put the pages back on the domain page_list */
+    lock_page_alloc(p2m);
     for ( i = 0 ; i < (1 << order); i++ )
     {
         BUG_ON(page_get_owner(p + i) != p2m->domain);
         page_list_add_tail(p + i, &p2m->domain->page_list);
     }
+    unlock_page_alloc(p2m);
 
     return p;
 }
@@ -213,6 +215,8 @@ p2m_pod_set_cache_target(struct p2m_doma
     struct domain *d = p2m->domain;
     int ret = 0;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     /* Increasing the target */
     while ( pod_target > p2m->pod.count )
     {
@@ -250,17 +254,13 @@ p2m_pod_set_cache_target(struct p2m_doma
     }
 
     /* Decreasing the target */
-    /* We hold the p2m lock here, so we don't need to worry about
+    /* We hold the pod lock here, so we don't need to worry about
      * cache disappearing under our feet. */
     while ( pod_target < p2m->pod.count )
     {
         struct page_info * page;
         int order, i;
 
-        /* Grab the lock before checking that pod.super is empty, or the last
-         * entries may disappear before we grab the lock. */
-        lock_page_alloc(p2m);
-
         if ( (p2m->pod.count - pod_target) > SUPERPAGE_PAGES
              && !page_list_empty(&p2m->pod.super) )
             order = PAGE_ORDER_2M;
@@ -271,8 +271,6 @@ p2m_pod_set_cache_target(struct p2m_doma
 
         ASSERT(page != NULL);
 
-        unlock_page_alloc(p2m);
-
         /* Then free them */
         for ( i = 0 ; i < (1 << order) ; i++ )
         {
@@ -348,7 +346,7 @@ p2m_pod_set_mem_target(struct domain *d,
     int ret = 0;
     unsigned long populated;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
 
     /* P == B: Nothing to do. */
     if ( p2m->pod.entry_count == 0 )
@@ -377,7 +375,7 @@ p2m_pod_set_mem_target(struct domain *d,
     ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
 
 out:
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
 
     return ret;
 }
@@ -390,7 +388,7 @@ p2m_pod_empty_cache(struct domain *d)
 
     /* After this barrier no new PoD activities can happen. */
     BUG_ON(!d->is_dying);
-    spin_barrier(&p2m->lock.lock);
+    spin_barrier(&p2m->pod.lock.lock);
 
     lock_page_alloc(p2m);
 
@@ -431,7 +429,7 @@ p2m_pod_offline_or_broken_hit(struct pag
     if ( !(d = page_get_owner(p)) || !(p2m = p2m_get_hostp2m(d)) )
         return 0;
 
-    lock_page_alloc(p2m);
+    pod_lock(p2m);
     bmfn = mfn_x(page_to_mfn(p));
     page_list_for_each_safe(q, tmp, &p2m->pod.super)
     {
@@ -462,12 +460,14 @@ p2m_pod_offline_or_broken_hit(struct pag
         }
     }
 
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 0;
 
 pod_hit:
+    lock_page_alloc(p2m);
     page_list_add_tail(p, &d->arch.relmem_list);
     unlock_page_alloc(p2m);
+    pod_unlock(p2m);
     return 1;
 }
 
@@ -486,9 +486,9 @@ p2m_pod_offline_or_broken_replace(struct
     if ( unlikely(!p) )
         return;
 
-    p2m_lock(p2m);
+    pod_lock(p2m);
     p2m_pod_cache_add(p2m, p, PAGE_ORDER_4K);
-    p2m_unlock(p2m);
+    pod_unlock(p2m);
     return;
 }
 
@@ -511,18 +511,18 @@ p2m_pod_decrease_reservation(struct doma
 
     int steal_for_cache = 0;
     int pod = 0, nonpod = 0, ram = 0;
-    
+
+    gfn_lock(p2m, gpfn, order);
+    pod_lock(p2m);    
 
     /* If we don't have any outstanding PoD entries, let things take their
      * course */
     if ( p2m->pod.entry_count == 0 )
-        goto out;
+        goto out_unlock;
 
     /* Figure out if we need to steal some freed memory for our cache */
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-    gfn_lock(p2m, gpfn, order);
-
     if ( unlikely(d->is_dying) )
         goto out_unlock;
 
@@ -554,7 +554,7 @@ p2m_pod_decrease_reservation(struct doma
         /* All PoD: Mark the whole region invalid and tell caller
          * we're done. */
         set_p2m_entry(p2m, gpfn, _mfn(INVALID_MFN), order, p2m_invalid, p2m->default_access);
-        p2m->pod.entry_count-=(1<<order); /* Lock: p2m */
+        p2m->pod.entry_count-=(1<<order);
         BUG_ON(p2m->pod.entry_count < 0);
         ret = 1;
         goto out_entry_check;
@@ -578,7 +578,7 @@ p2m_pod_decrease_reservation(struct doma
         if ( t == p2m_populate_on_demand )
         {
             set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, p2m->default_access);
-            p2m->pod.entry_count--; /* Lock: p2m */
+            p2m->pod.entry_count--;
             BUG_ON(p2m->pod.entry_count < 0);
             pod--;
         }
@@ -615,9 +615,8 @@ out_entry_check:
     }
 
 out_unlock:
+    pod_unlock(p2m);
     gfn_unlock(p2m, gpfn, order);
-
-out:
     return ret;
 }
 
@@ -630,7 +629,8 @@ void p2m_pod_dump_data(struct domain *d)
 
 
 /* Search for all-zero superpages to be reclaimed as superpages for the
- * PoD cache. Must be called w/ p2m lock held, page_alloc lock not held. */
+ * PoD cache. Must be called w/ pod lock held, must lock the superpage
+ * in the p2m */
 static int
 p2m_pod_zero_check_superpage(struct p2m_domain *p2m, unsigned long gfn)
 {
@@ -642,6 +642,8 @@ p2m_pod_zero_check_superpage(struct p2m_
     int max_ref = 1;
     struct domain *d = p2m->domain;
 
+    ASSERT(pod_locked_by_me(p2m));
+
     if ( !superpage_aligned(gfn) )
         goto out;
 
@@ -649,6 +651,10 @@ p2m_pod_zero_check_superpage(struct p2m_
     if ( paging_mode_shadow(d) )
         max_ref++;
 
+    /* NOTE: this is why we don't enforce deadlock constraints between p2m 
+     * and pod locks */
+    gfn_lock(p2m, gfn, SUPERPAGE_ORDER);
+
     /* Look up the mfns, checking to make sure they're the same mfn
      * and aligned, and mapping them. */
     for ( i=0; i<SUPERPAGE_PAGES; i++ )
@@ -761,6 +767,7 @@ out_reset:
         set_p2m_entry(p2m, gfn, mfn0, 9, type0, p2m->default_access);
     
 out:
+    gfn_unlock(p2m, gfn, SUPERPAGE_ORDER);
     return ret;
 }
 
@@ -922,6 +929,10 @@ p2m_pod_emergency_sweep(struct p2m_domai
     limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
 
     /* FIXME: Figure out how to avoid superpages */
+    /* NOTE: Promote to globally locking the p2m. This will get complicated
+     * in a fine-grained scenario. If we lock each gfn individually we must be
+     * careful about spinlock recursion limits and POD_SWEEP_STRIDE. */
+    p2m_lock(p2m);
     for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
     {
         p2m_access_t a;
@@ -940,7 +951,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
         /* Stop if we're past our limit and we have found *something*.
          *
          * NB that this is a zero-sum game; we're increasing our cache size
-         * by re-increasing our 'debt'.  Since we hold the p2m lock,
+         * by re-increasing our 'debt'.  Since we hold the pod lock,
          * (entry_count - count) must remain the same. */
         if ( p2m->pod.count > 0 && i < limit )
             break;
@@ -949,6 +960,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
     if ( j )
         p2m_pod_zero_check(p2m, gfns, j);
 
+    p2m_unlock(p2m);
     p2m->pod.reclaim_single = i ? i - 1 : i;
 
 }
@@ -965,8 +977,9 @@ p2m_pod_demand_populate(struct p2m_domai
     int i;
 
     ASSERT(gfn_locked_by_me(p2m, gfn));
+    pod_lock(p2m);
 
-    /* This check is done with the p2m lock held.  This will make sure that
+    /* This check is done with the pod lock held.  This will make sure that
      * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
      * won't start until we're done. */
     if ( unlikely(d->is_dying) )
@@ -977,6 +990,7 @@ p2m_pod_demand_populate(struct p2m_domai
      * 1GB region to 2MB chunks for a retry. */
     if ( order == PAGE_ORDER_1G )
     {
+        pod_unlock(p2m);
         gfn_aligned = (gfn >> order) << order;
         /* Note that we are supposed to call set_p2m_entry() 512 times to 
          * split 1GB into 512 2MB pages here. But We only do once here because
@@ -1000,11 +1014,15 @@ p2m_pod_demand_populate(struct p2m_domai
 
         /* If we're low, start a sweep */
         if ( order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) )
+            /* Note that sweeps scan other ranges in the p2m. In an scenario
+             * in which p2m locks are fine-grained, this may result in deadlock.
+             * Using trylock on the gfn's as we sweep would avoid it. */
             p2m_pod_emergency_sweep_super(p2m);
 
         if ( page_list_empty(&p2m->pod.single) &&
              ( ( order == PAGE_ORDER_4K )
                || (order == PAGE_ORDER_2M && page_list_empty(&p2m->pod.super) ) ) )
+            /* Same comment regarding deadlock applies */
             p2m_pod_emergency_sweep(p2m);
     }
 
@@ -1012,8 +1030,6 @@ p2m_pod_demand_populate(struct p2m_domai
     if ( q == p2m_guest && gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
-    lock_page_alloc(p2m);
-
     if ( p2m->pod.count == 0 )
         goto out_of_memory;
 
@@ -1026,8 +1042,6 @@ p2m_pod_demand_populate(struct p2m_domai
 
     BUG_ON((mfn_x(mfn) & ((1 << order)-1)) != 0);
 
-    unlock_page_alloc(p2m);
-
     gfn_aligned = (gfn >> order) << order;
 
     set_p2m_entry(p2m, gfn_aligned, mfn, order, p2m_ram_rw, p2m->default_access);
@@ -1038,7 +1052,7 @@ p2m_pod_demand_populate(struct p2m_domai
         paging_mark_dirty(d, mfn_x(mfn) + i);
     }
     
-    p2m->pod.entry_count -= (1 << order); /* Lock: p2m */
+    p2m->pod.entry_count -= (1 << order);
     BUG_ON(p2m->pod.entry_count < 0);
 
     if ( tb_init_done )
@@ -1056,20 +1070,24 @@ p2m_pod_demand_populate(struct p2m_domai
         __trace_var(TRC_MEM_POD_POPULATE, 0, sizeof(t), &t);
     }
 
+    pod_unlock(p2m);
     return 0;
 out_of_memory:
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     printk("%s: Out of populate-on-demand memory! tot_pages %" PRIu32 " pod_entries %" PRIi32 "\n",
            __func__, d->tot_pages, p2m->pod.entry_count);
     domain_crash(d);
 out_fail:
+    pod_unlock(p2m);
     return -1;
 remap_and_retry:
     BUG_ON(order != PAGE_ORDER_2M);
-    unlock_page_alloc(p2m);
+    pod_unlock(p2m);
 
     /* Remap this 2-meg region in singleton chunks */
+    /* NOTE: In a p2m fine-grained lock scenario this might
+     * need promoting the gfn lock from gfn->2M superpage */
     gfn_aligned = (gfn>>order)<<order;
     for(i=0; i<(1<<order); i++)
         set_p2m_entry(p2m, gfn_aligned+i, _mfn(0), PAGE_ORDER_4K,
@@ -1137,9 +1155,11 @@ guest_physmap_mark_populate_on_demand(st
         rc = -EINVAL;
     else
     {
-        p2m->pod.entry_count += 1 << order; /* Lock: p2m */
+        pod_lock(p2m);
+        p2m->pod.entry_count += 1 << order;
         p2m->pod.entry_count -= pod_count;
         BUG_ON(p2m->pod.entry_count < 0);
+        pod_unlock(p2m);
     }
 
     gfn_unlock(p2m, gfn, order);
diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -954,6 +954,7 @@ long p2m_pt_audit_p2m(struct p2m_domain 
     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) );
diff -r 63cb81c2448e -r 5416a3b371f2 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -72,6 +72,7 @@ boolean_param("hap_2mb", opt_hap_2mb);
 static void p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
     mm_lock_init(&p2m->lock);
+    mm_lock_init(&p2m->pod.lock);
     INIT_LIST_HEAD(&p2m->np2m_list);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
     INIT_PAGE_LIST_HEAD(&p2m->pod.super);
@@ -568,8 +569,10 @@ guest_physmap_add_entry(struct domain *d
             rc = -EINVAL;
         else
         {
-            p2m->pod.entry_count -= pod_count; /* Lock: p2m */
+            pod_lock(p2m);
+            p2m->pod.entry_count -= pod_count;
             BUG_ON(p2m->pod.entry_count < 0);
+            pod_unlock(p2m);
         }
     }
 
@@ -1350,6 +1353,7 @@ p2m_flush_table(struct p2m_domain *p2m)
     /* "Host" p2m tables can have shared entries &c that need a bit more 
      * care when discarding them */
     ASSERT(p2m_is_nestedp2m(p2m));
+    /* Nested p2m's do not do pod, hence the asserts (and no pod lock)*/
     ASSERT(page_list_empty(&p2m->pod.super));
     ASSERT(page_list_empty(&p2m->pod.single));
 
@@ -1507,6 +1511,7 @@ void audit_p2m(struct domain *d,
     P2M_PRINTK("p2m audit starts\n");
 
     p2m_lock(p2m);
+    pod_lock(p2m);
 
     if (p2m->audit_p2m)
         pmbad = p2m->audit_p2m(p2m);
@@ -1567,6 +1572,7 @@ void audit_p2m(struct domain *d,
     }
     spin_unlock(&d->page_alloc_lock);
 
+    pod_unlock(p2m);
     p2m_unlock(p2m);
  
     P2M_PRINTK("p2m audit complete\n");
diff -r 63cb81c2448e -r 5416a3b371f2 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -261,25 +261,12 @@ struct p2m_domain {
     unsigned long max_mapped_pfn;
 
     /* Populate-on-demand variables
-     * NB on locking.  {super,single,count} are
-     * covered by d->page_alloc_lock, since they're almost always used in
-     * conjunction with that functionality.  {entry_count} is covered by
-     * the domain p2m lock, since it's almost always used in conjunction
-     * with changing the p2m tables.
-     *
-     * At this point, both locks are held in two places.  In both,
-     * the order is [p2m,page_alloc]:
-     * + p2m_pod_decrease_reservation() calls p2m_pod_cache_add(),
-     *   which grabs page_alloc
-     * + p2m_pod_demand_populate() grabs both; the p2m lock to avoid
-     *   double-demand-populating of pages, the page_alloc lock to
-     *   protect moving stuff from the PoD cache to the domain page list.
-     *
-     * We enforce this lock ordering through a construct in mm-locks.h.
-     * This demands, however, that we store the previous lock-ordering
-     * level in effect before grabbing the page_alloc lock. The unlock
-     * level is stored in the arch section of the domain struct.
-     */
+     * All variables are protected with the pod lock. We cannot rely on
+     * the p2m lock if it's turned into a fine-grained lock.
+     * We only use the domain page_alloc lock for additions and 
+     * deletions to the domain's page list. Because we use it nested
+     * within the PoD lock, we enforce it's ordering (by remembering
+     * the unlock level in the arch_domain sub struct). */
     struct {
         struct page_list_head super,   /* List of superpages                */
                          single;       /* Non-super lists                   */
@@ -288,6 +275,8 @@ struct p2m_domain {
         unsigned         reclaim_super; /* Last gpfn of a scan */
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
+        mm_lock_t        lock;         /* Locking of private pod structs,   *
+                                        * not relying on the p2m lock.      */
     } pod;
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqb-0008CP-6N; Thu, 09 Feb 2012 04:43:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqZ-00089P-4s
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328762538!51685096!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY2MzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21351 invoked from network); 9 Feb 2012 04:42:18 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:18 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 2A919458081;
	Wed,  8 Feb 2012 20:42:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NbsCV3Fjl2xv9kVhlUaWAIyCK008ny/7qauGsch8OXTb
	OArksP83XIlez9g6AFJixXzcEMUH1GLG/uRHtQpCr3C29LjBqqftrFnhiieLbJLo
	ORyNySIWctPWJ8qTYEoKdcNSnXR5AaUvWwTHXsK4QEMa57hyUPS0RIr4QtSaF7o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=JlA9qTTvhmbKOWevqUhqjjwsX7Y=; b=NC9MV2mLE3F
	ykk64ucFsFtmlku7xoAr/C7KfnoGg7kJzJwYwhD9vq5+WKVuUpgLE3unus0crrWv
	8BGR/nlGeMoNY7wbH9oa+M2cT2EY8ng1XF5rOB6xLVCFDLqi7IRfP+BlRmL56Ngq
	3Fn5bkQ59WqxRY6Pgr+XZvsOEsEHSZSc=
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 8CD88458079; 
	Wed,  8 Feb 2012 20:42:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 667191f054c34b6c1e7290b3bd85100cc942f4ec
Message-Id: <667191f054c34b6c1e72.1328766352@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:52 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 7] x86/mm: When removing/adding a page
 from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletions(-)


When removing the m2p mapping it is unconditionally set to invalid, which
breaks sharing.

When adding to the physmap, if the previous holder of that entry is a shared
page, we unshare to default to normal case handling.

And, we cannot add a shared page directly to the physmap. Proper interfaces
must be employed, otherwise book-keeping goes awry.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7fe1bb9208df -r 667191f054c3 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -438,7 +438,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         for ( i = 0; i < (1UL << page_order); i++ )
         {
             mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
-            if ( !p2m_is_grant(t) )
+            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
         }
@@ -500,6 +500,22 @@ guest_physmap_add_entry(struct domain *d
     for ( i = 0; i < (1UL << page_order); i++ )
     {
         omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+#ifdef __x86_64__
+        if ( p2m_is_shared(ot) )
+        {
+            /* Do an unshare to cleanly take care of all corner 
+             * cases. */
+            int rc;
+            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
+            if ( rc )
+            {
+                p2m_unlock(p2m);
+                return rc;
+            }
+            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+            ASSERT(!p2m_is_shared(ot));
+        }
+#endif /* __x86_64__ */
         if ( p2m_is_grant(ot) )
         {
             /* Really shouldn't be unmapping grant maps this way */
@@ -528,6 +544,14 @@ guest_physmap_add_entry(struct domain *d
     /* Then, look for m->p mappings for this range and deal with them */
     for ( i = 0; i < (1UL << page_order); i++ )
     {
+        if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) == dom_cow )
+        {
+            /* This is no way to add a shared page to your physmap! */
+            gdprintk(XENLOG_ERR, "Adding shared mfn %lx directly to dom %hu "
+                        "physmap not allowed.\n", mfn+i, d->domain_id);
+            p2m_unlock(p2m);
+            return -EINVAL;
+        }
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:43:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLqb-0008CP-6N; Thu, 09 Feb 2012 04:43:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvLqZ-00089P-4s
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:43:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328762538!51685096!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTY2MzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21351 invoked from network); 9 Feb 2012 04:42:18 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:42:18 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 2A919458081;
	Wed,  8 Feb 2012 20:42:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NbsCV3Fjl2xv9kVhlUaWAIyCK008ny/7qauGsch8OXTb
	OArksP83XIlez9g6AFJixXzcEMUH1GLG/uRHtQpCr3C29LjBqqftrFnhiieLbJLo
	ORyNySIWctPWJ8qTYEoKdcNSnXR5AaUvWwTHXsK4QEMa57hyUPS0RIr4QtSaF7o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=JlA9qTTvhmbKOWevqUhqjjwsX7Y=; b=NC9MV2mLE3F
	ykk64ucFsFtmlku7xoAr/C7KfnoGg7kJzJwYwhD9vq5+WKVuUpgLE3unus0crrWv
	8BGR/nlGeMoNY7wbH9oa+M2cT2EY8ng1XF5rOB6xLVCFDLqi7IRfP+BlRmL56Ngq
	3Fn5bkQ59WqxRY6Pgr+XZvsOEsEHSZSc=
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 8CD88458079; 
	Wed,  8 Feb 2012 20:42:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 667191f054c34b6c1e7290b3bd85100cc942f4ec
Message-Id: <667191f054c34b6c1e72.1328766352@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 00:45:52 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca, keir.xen@gmail.com,
	tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 7] x86/mm: When removing/adding a page
 from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletions(-)


When removing the m2p mapping it is unconditionally set to invalid, which
breaks sharing.

When adding to the physmap, if the previous holder of that entry is a shared
page, we unshare to default to normal case handling.

And, we cannot add a shared page directly to the physmap. Proper interfaces
must be employed, otherwise book-keeping goes awry.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7fe1bb9208df -r 667191f054c3 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -438,7 +438,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
         for ( i = 0; i < (1UL << page_order); i++ )
         {
             mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
-            if ( !p2m_is_grant(t) )
+            if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
         }
@@ -500,6 +500,22 @@ guest_physmap_add_entry(struct domain *d
     for ( i = 0; i < (1UL << page_order); i++ )
     {
         omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+#ifdef __x86_64__
+        if ( p2m_is_shared(ot) )
+        {
+            /* Do an unshare to cleanly take care of all corner 
+             * cases. */
+            int rc;
+            rc = mem_sharing_unshare_page(p2m->domain, gfn + i, 0);
+            if ( rc )
+            {
+                p2m_unlock(p2m);
+                return rc;
+            }
+            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+            ASSERT(!p2m_is_shared(ot));
+        }
+#endif /* __x86_64__ */
         if ( p2m_is_grant(ot) )
         {
             /* Really shouldn't be unmapping grant maps this way */
@@ -528,6 +544,14 @@ guest_physmap_add_entry(struct domain *d
     /* Then, look for m->p mappings for this range and deal with them */
     for ( i = 0; i < (1UL << page_order); i++ )
     {
+        if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) == dom_cow )
+        {
+            /* This is no way to add a shared page to your physmap! */
+            gdprintk(XENLOG_ERR, "Adding shared mfn %lx directly to dom %hu "
+                        "physmap not allowed.\n", mfn+i, d->domain_id);
+            p2m_unlock(p2m);
+            return -EINVAL;
+        }
         if ( page_get_owner(mfn_to_page(_mfn(mfn + i))) != d )
             continue;
         ogfn = mfn_to_gfn(d, _mfn(mfn+i));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:48:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLva-0000px-4w; Thu, 09 Feb 2012 04:48:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RvLvY-0000pa-1e
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:48:12 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328762885!12601267!1
X-Originating-IP: [216.33.127.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15198 invoked from network); 9 Feb 2012 04:48:05 -0000
Received: from mta31.charter.net (HELO mta31.charter.net) (216.33.127.82)
	by server-4.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 04:48:05 -0000
Received: from imp11 ([10.20.200.11]) by mta31.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120209044804.OYVS4042.mta31.charter.net@imp11>;
	Wed, 8 Feb 2012 23:48:04 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id Xgo41i00546xN4z05go4cn; Wed, 08 Feb 2012 23:48:04 -0500
X-Authority-Analysis: v=1.1 cv=rvNqJbVGdbt4egs52VbhtoJZG7AoPDG9H2iogr/sNfs=
	c=1 sm=1 a=0bCt-fb661UA:10 a=QPD9uHFANWIA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=-g-7CrJqAAAA:8 a=bYkDtZIPTCGCmnD0Nk4A:9
	a=QEXdDO2ut3YA:10 a=oqYZzFIXC3IA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 142AA203D1;
	Thu,  9 Feb 2012 05:12:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vaMXAfJdglQ3; Thu,  9 Feb 2012 00:11:43 -0500 (EST)
Received: from 192.168.1.12 (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id 4736A20390;
	Thu,  9 Feb 2012 00:11:43 -0500 (EST)
MIME-Version: 1.0
Date: Thu, 09 Feb 2012 00:07:16 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <CAFLBxZbF3YKN19JSi4_NpXG0H=pZ3RQm42YjnaXvX_NBbR4XYw@mail.gmail.com>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
	<4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
	<CAFLBxZbF3YKN19JSi4_NpXG0H=pZ3RQm42YjnaXvX_NBbR4XYw@mail.gmail.com>
Message-ID: <a309ca33561da9854603ee5fea0ad83d@192.168.1.11>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] HVM Driver Domain for GPU API remoting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMDguMDIuMjAxMiAwNjo1MywgR2VvcmdlIER1bmxhcCB3cm90ZToKPiBPbiBTdW4sIEZlYiA1
LCAyMDEyIGF0IDM6MzggQU0sIE1pY2hhZWwgQS4gQ29sbGlucwo+IDxtaWtlLmEuY29sbGluc0Bh
cmstbmV0Lm9yZz4gd3JvdGU6Cj4+IEkgcmVjZW50bHkgcmVhZCBhYm91dCBYZW4zRCBhbmQgdGhl
IHdob2xlIGlkZWEgb2YgQVBJIHJlbW90aW5nIGZvciAKPj4gZ3JhcGhpY3MKPj4gaXMgbmV3IHRv
IG1lLCBzbyB0aGF0J3MgdGhlIGxldmVsIEknbSBjb21pbmcgZnJvbS4gwqBNeSBxdWVzdGlvbiBp
cyAKPj4gYXMKPj4gZm9sbG93czoKPgo+IEknbSBub3Qgc3VyZSBhbnlvbmUgaGVyZSBpcyBjdXJy
ZW50bHkgd29ya2luZyBvbiBBUEkgcmVtb3RpbmcuICBJdAo+IHNvdW5kcyBsaWtlIHlvdSdyZSBw
ZXJoYXBzIHN1Z2dlc3RpbmcgbWFraW5nIGEgbmV3IFBWIAo+IGZyb250ZW5kL2JhY2tlbmQKPiBw
cm90b2NvbCwgc2ltaWxhciB0byBibG9ja2JhY2svZnJvbnQsIG5ldGJhY2svZnJvbnQsIHB2c2Nz
aSwgcHZ1c2IsCj4gYW5kIHNvIG9uLCB3aGljaCB3b3VsZCBkbyAzRCBncmFwaGljcyBwcm9jZXNz
aW5nIG9uIGJlaGFsZiBvZiBndWVzdHMuCj4gSXMgdGhhdCBjb3JyZWN0Pwo+Cj4gSXQgc291bmRz
IGxpa2UgaXQgY291bGQgYmUgdXNlZnVsIHRvIG1lLiAgQXJlIHlvdSB2b2x1bnRlZXJpbmcgdG8K
PiBkZXZlbG9wIHN1Y2ggYSBwcm90b2NvbD8gOi0pCj4KClRoYXQgSSBhbS4gIEV4Y3VzZSBtZSB3
aGlsZSBJIGxvY2sgbXlzZWxmIGF3YXkgZm9yIGEgd2hpbGUgYW5kIHBvbmRlciAKd2hhdCBJJ3Zl
IGp1c3QgZ290dGVuIG15c2VsZiBpbnRvLgpNaWtlCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:48:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvLva-0000px-4w; Thu, 09 Feb 2012 04:48:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RvLvY-0000pa-1e
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:48:12 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328762885!12601267!1
X-Originating-IP: [216.33.127.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15198 invoked from network); 9 Feb 2012 04:48:05 -0000
Received: from mta31.charter.net (HELO mta31.charter.net) (216.33.127.82)
	by server-4.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 04:48:05 -0000
Received: from imp11 ([10.20.200.11]) by mta31.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120209044804.OYVS4042.mta31.charter.net@imp11>;
	Wed, 8 Feb 2012 23:48:04 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id Xgo41i00546xN4z05go4cn; Wed, 08 Feb 2012 23:48:04 -0500
X-Authority-Analysis: v=1.1 cv=rvNqJbVGdbt4egs52VbhtoJZG7AoPDG9H2iogr/sNfs=
	c=1 sm=1 a=0bCt-fb661UA:10 a=QPD9uHFANWIA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=-g-7CrJqAAAA:8 a=bYkDtZIPTCGCmnD0Nk4A:9
	a=QEXdDO2ut3YA:10 a=oqYZzFIXC3IA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 142AA203D1;
	Thu,  9 Feb 2012 05:12:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vaMXAfJdglQ3; Thu,  9 Feb 2012 00:11:43 -0500 (EST)
Received: from 192.168.1.12 (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id 4736A20390;
	Thu,  9 Feb 2012 00:11:43 -0500 (EST)
MIME-Version: 1.0
Date: Thu, 09 Feb 2012 00:07:16 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <CAFLBxZbF3YKN19JSi4_NpXG0H=pZ3RQm42YjnaXvX_NBbR4XYw@mail.gmail.com>
References: <f9aa907106f126e08751a1f4525e59108afc081c.1328402619.git.julian.pidancet@gmail.com>
	<20120205015657.GA25327@morn.localdomain>
	<4541410aaec534f2b0951b4fa32002a7@192.168.1.11>
	<CAFLBxZbF3YKN19JSi4_NpXG0H=pZ3RQm42YjnaXvX_NBbR4XYw@mail.gmail.com>
Message-ID: <a309ca33561da9854603ee5fea0ad83d@192.168.1.11>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] HVM Driver Domain for GPU API remoting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMDguMDIuMjAxMiAwNjo1MywgR2VvcmdlIER1bmxhcCB3cm90ZToKPiBPbiBTdW4sIEZlYiA1
LCAyMDEyIGF0IDM6MzggQU0sIE1pY2hhZWwgQS4gQ29sbGlucwo+IDxtaWtlLmEuY29sbGluc0Bh
cmstbmV0Lm9yZz4gd3JvdGU6Cj4+IEkgcmVjZW50bHkgcmVhZCBhYm91dCBYZW4zRCBhbmQgdGhl
IHdob2xlIGlkZWEgb2YgQVBJIHJlbW90aW5nIGZvciAKPj4gZ3JhcGhpY3MKPj4gaXMgbmV3IHRv
IG1lLCBzbyB0aGF0J3MgdGhlIGxldmVsIEknbSBjb21pbmcgZnJvbS4gwqBNeSBxdWVzdGlvbiBp
cyAKPj4gYXMKPj4gZm9sbG93czoKPgo+IEknbSBub3Qgc3VyZSBhbnlvbmUgaGVyZSBpcyBjdXJy
ZW50bHkgd29ya2luZyBvbiBBUEkgcmVtb3RpbmcuICBJdAo+IHNvdW5kcyBsaWtlIHlvdSdyZSBw
ZXJoYXBzIHN1Z2dlc3RpbmcgbWFraW5nIGEgbmV3IFBWIAo+IGZyb250ZW5kL2JhY2tlbmQKPiBw
cm90b2NvbCwgc2ltaWxhciB0byBibG9ja2JhY2svZnJvbnQsIG5ldGJhY2svZnJvbnQsIHB2c2Nz
aSwgcHZ1c2IsCj4gYW5kIHNvIG9uLCB3aGljaCB3b3VsZCBkbyAzRCBncmFwaGljcyBwcm9jZXNz
aW5nIG9uIGJlaGFsZiBvZiBndWVzdHMuCj4gSXMgdGhhdCBjb3JyZWN0Pwo+Cj4gSXQgc291bmRz
IGxpa2UgaXQgY291bGQgYmUgdXNlZnVsIHRvIG1lLiAgQXJlIHlvdSB2b2x1bnRlZXJpbmcgdG8K
PiBkZXZlbG9wIHN1Y2ggYSBwcm90b2NvbD8gOi0pCj4KClRoYXQgSSBhbS4gIEV4Y3VzZSBtZSB3
aGlsZSBJIGxvY2sgbXlzZWxmIGF3YXkgZm9yIGEgd2hpbGUgYW5kIHBvbmRlciAKd2hhdCBJJ3Zl
IGp1c3QgZ290dGVuIG15c2VsZiBpbnRvLgpNaWtlCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:57:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvM4i-0001A0-GG; Thu, 09 Feb 2012 04:57:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvM4g-00019v-Lq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:57:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328763435!65083192!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODE3OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27179 invoked from network); 9 Feb 2012 04:57:15 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-15.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:57:15 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id BC216300072;
	Wed,  8 Feb 2012 20:57:36 -0800 (PST)
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=ZBFZhS9yDg96jh9ErlTq4O
	qYL/eykVD2nv4Kcuv2a+RC8OHjoSar3dTTwWfkzC+8Jqhv4MkEwe2Jb6uFptpmdb
	XbkBXtiF5Mr+DpqKkEn2I9Qfaz9Tt4/nksWENbx04LPZLVN/ZU1OySX2YABfBQp9
	663YP/wEDL3HtgtlVozyY=
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=2QX9+SGqvjwu
	yJ6Hd13bb8A+kZw=; b=KlI2DqR+7qUmt36X++etW9lbURi2gV1Pk5IHpOWOQF4k
	YA4lfqhzW6jj995uBjTj9mLPWmUDBKlkQz7jiUNwCfHOCL0T+Ds3uS77HaMqWRbW
	DHbdj7ul7be/LUWc/R4NCTEkVnbOVTyya35xd6qbxz+2GcUWHKBUJOxwKTIHiVo=
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 3607B300061; 
	Wed,  8 Feb 2012 20:57:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f2efbfaa8d26e3b527b2cfdc3f9c962284063ec0
Message-Id: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:01:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
 shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  4 +++-
 xen/arch/x86/mm/p2m.c         |  6 ++++--
 2 files changed, 7 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -200,7 +200,9 @@ static struct page_info* mem_sharing_loo
             /* Count has to be at least two, because we're called
              * with the mfn locked (1) and this is supposed to be 
              * a shared page (1). */
-            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2); 
+            ASSERT((page->u.inuse.type_info & 
+                        (PGT_shared_page | PGT_count_mask)) >= 
+                            (PGT_shared_page | 2)); 
             ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
             return page;
         }
diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -745,8 +745,10 @@ set_shared_p2m_entry(struct domain *d, u
      * sharable first */
     ASSERT(p2m_is_shared(ot));
     ASSERT(mfn_valid(omfn));
-    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
-                    != PGT_shared_page) )
+    /* Set the m2p entry to invalid only if there are no further type
+     * refs to this page as shared */
+    if ( (mfn_to_page(omfn)->u.inuse.type_info & 
+            (PGT_shared_page | PGT_count_mask)) <= PGT_shared_page )
         set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:57:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvM4i-0001A0-GG; Thu, 09 Feb 2012 04:57:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvM4g-00019v-Lq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:57:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328763435!65083192!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODE3OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27179 invoked from network); 9 Feb 2012 04:57:15 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-15.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:57:15 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id BC216300072;
	Wed,  8 Feb 2012 20:57:36 -0800 (PST)
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=ZBFZhS9yDg96jh9ErlTq4O
	qYL/eykVD2nv4Kcuv2a+RC8OHjoSar3dTTwWfkzC+8Jqhv4MkEwe2Jb6uFptpmdb
	XbkBXtiF5Mr+DpqKkEn2I9Qfaz9Tt4/nksWENbx04LPZLVN/ZU1OySX2YABfBQp9
	663YP/wEDL3HtgtlVozyY=
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=2QX9+SGqvjwu
	yJ6Hd13bb8A+kZw=; b=KlI2DqR+7qUmt36X++etW9lbURi2gV1Pk5IHpOWOQF4k
	YA4lfqhzW6jj995uBjTj9mLPWmUDBKlkQz7jiUNwCfHOCL0T+Ds3uS77HaMqWRbW
	DHbdj7ul7be/LUWc/R4NCTEkVnbOVTyya35xd6qbxz+2GcUWHKBUJOxwKTIHiVo=
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 3607B300061; 
	Wed,  8 Feb 2012 20:57:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f2efbfaa8d26e3b527b2cfdc3f9c962284063ec0
Message-Id: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:01:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
 shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  4 +++-
 xen/arch/x86/mm/p2m.c         |  6 ++++--
 2 files changed, 7 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -200,7 +200,9 @@ static struct page_info* mem_sharing_loo
             /* Count has to be at least two, because we're called
              * with the mfn locked (1) and this is supposed to be 
              * a shared page (1). */
-            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2); 
+            ASSERT((page->u.inuse.type_info & 
+                        (PGT_shared_page | PGT_count_mask)) >= 
+                            (PGT_shared_page | 2)); 
             ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
             return page;
         }
diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -745,8 +745,10 @@ set_shared_p2m_entry(struct domain *d, u
      * sharable first */
     ASSERT(p2m_is_shared(ot));
     ASSERT(mfn_valid(omfn));
-    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
-                    != PGT_shared_page) )
+    /* Set the m2p entry to invalid only if there are no further type
+     * refs to this page as shared */
+    if ( (mfn_to_page(omfn)->u.inuse.type_info & 
+            (PGT_shared_page | PGT_count_mask)) <= PGT_shared_page )
         set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04: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.xensource.com>)
	id 1RvM4s-0001Ak-Rv; Thu, 09 Feb 2012 04:57:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvM4r-0001AX-F4
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:57:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328763419!62115254!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NjMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8150 invoked from network); 9 Feb 2012 04:57:00 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:57:00 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8C07260408C;
	Wed,  8 Feb 2012 20:57:47 -0800 (PST)
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=Z60Lh6axqAo2u6FM6WUn34
	slQY7hiCz2jMGUyUGZphpU1KY7hJihwr5AUIgEBRdxbHtrIlxBPabJ0Oc9ndt3hB
	g+tHKUmulCBPfCgUJv1kU7NTd7j7oK7Cw+ETo7wx8kBH9t5iD27/sYgaJ7Va/By2
	dN0XGtX6lBNOoX0gK71SQ=
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=s44zv31uY3DM
	dydvtj2p5uAG5IY=; b=Ivm2nvjgo83r5ZYttejuK0bZ/2ppHJVZgXC1PH0IESMd
	FSg5nQ2Y2o4JEHM6zq91MCspfcMY6ZeR3CqSe6QwFUAE3/L9SMpgCkl0UBFE5+9c
	2CjN7moCh1MeDm5SxA+WJmVnPhgo8LAPuLCzNrvePc0sbSNSf76HcDlBiKp57Is=
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 24B72604076; 
	Wed,  8 Feb 2012 20:57:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 616e45ef156f6b534055b000ba1fdc16e79a8b24
Message-Id: <616e45ef156f6b534055.1328767309@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:01:49 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: Fix more ballooning+paging and
	ballooning+sharing bugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |   7 +++++--
 xen/common/memory.c   |  17 ++++++++++++++++-
 2 files changed, 21 insertions(+), 3 deletions(-)


If the guest balloons away a page that has been nominated for paging but not yet
paged out, we fix:
 - Send EVICT_FAIL flag in the event to the pager
 - Do not leak the underlying page

If the page was shared, we were not:
 - properly refreshing the mfn to balloon after the unshare.
 - unlocking the p2m on the error exit case

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f2efbfaa8d26 -r 616e45ef156f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -927,11 +927,14 @@ void p2m_mem_paging_drop_page(struct dom
     req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
-
     /* Update stats unless the page hasn't yet been evicted */
     if ( p2mt != p2m_ram_paging_out )
         atomic_dec(&d->paged_pages);
+    else
+        /* Evict will fail now, tag this request for pager */
+        req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
diff -r f2efbfaa8d26 -r 616e45ef156f xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -167,6 +167,15 @@ int guest_remove_page(struct domain *d, 
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
         put_gfn(d, gmfn);
+        /* If the page hasn't yet been paged out, there is an
+         * actual page that needs to be released. */
+        if ( p2mt == p2m_ram_paging_out )
+        {
+            ASSERT(mfn_valid(mfn));
+            page = mfn_to_page(mfn);
+            if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
+                put_page(page);
+        }
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
         return 1;
     }
@@ -181,7 +190,6 @@ int guest_remove_page(struct domain *d, 
         return 0;
     }
             
-    page = mfn_to_page(mfn);
 #ifdef CONFIG_X86_64
     if ( p2m_is_shared(p2mt) )
     {
@@ -190,10 +198,17 @@ int guest_remove_page(struct domain *d, 
          * need to trigger proper cleanup. Once done, this is 
          * like any other page. */
         if ( mem_sharing_unshare_page(d, gmfn, 0) )
+        {
+            put_gfn(d, gmfn);
             return 0;
+        }
+        /* Maybe the mfn changed */
+        mfn = mfn_x(get_gfn_query_unlocked(d, gmfn, &p2mt));
+        ASSERT(!p2m_is_shared(p2mt));
     }
 #endif /* CONFIG_X86_64 */
 
+    page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
     {
         put_gfn(d, gmfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 04:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 04: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.xensource.com>)
	id 1RvM4s-0001Ak-Rv; Thu, 09 Feb 2012 04:57:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvM4r-0001AX-F4
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 04:57:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328763419!62115254!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NjMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8150 invoked from network); 9 Feb 2012 04:57:00 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 04:57:00 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 8C07260408C;
	Wed,  8 Feb 2012 20:57:47 -0800 (PST)
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=Z60Lh6axqAo2u6FM6WUn34
	slQY7hiCz2jMGUyUGZphpU1KY7hJihwr5AUIgEBRdxbHtrIlxBPabJ0Oc9ndt3hB
	g+tHKUmulCBPfCgUJv1kU7NTd7j7oK7Cw+ETo7wx8kBH9t5iD27/sYgaJ7Va/By2
	dN0XGtX6lBNOoX0gK71SQ=
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=s44zv31uY3DM
	dydvtj2p5uAG5IY=; b=Ivm2nvjgo83r5ZYttejuK0bZ/2ppHJVZgXC1PH0IESMd
	FSg5nQ2Y2o4JEHM6zq91MCspfcMY6ZeR3CqSe6QwFUAE3/L9SMpgCkl0UBFE5+9c
	2CjN7moCh1MeDm5SxA+WJmVnPhgo8LAPuLCzNrvePc0sbSNSf76HcDlBiKp57Is=
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 24B72604076; 
	Wed,  8 Feb 2012 20:57:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 616e45ef156f6b534055b000ba1fdc16e79a8b24
Message-Id: <616e45ef156f6b534055.1328767309@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:01:49 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: Fix more ballooning+paging and
	ballooning+sharing bugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |   7 +++++--
 xen/common/memory.c   |  17 ++++++++++++++++-
 2 files changed, 21 insertions(+), 3 deletions(-)


If the guest balloons away a page that has been nominated for paging but not yet
paged out, we fix:
 - Send EVICT_FAIL flag in the event to the pager
 - Do not leak the underlying page

If the page was shared, we were not:
 - properly refreshing the mfn to balloon after the unshare.
 - unlocking the p2m on the error exit case

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f2efbfaa8d26 -r 616e45ef156f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -927,11 +927,14 @@ void p2m_mem_paging_drop_page(struct dom
     req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
-
     /* Update stats unless the page hasn't yet been evicted */
     if ( p2mt != p2m_ram_paging_out )
         atomic_dec(&d->paged_pages);
+    else
+        /* Evict will fail now, tag this request for pager */
+        req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
diff -r f2efbfaa8d26 -r 616e45ef156f xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -167,6 +167,15 @@ int guest_remove_page(struct domain *d, 
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
         put_gfn(d, gmfn);
+        /* If the page hasn't yet been paged out, there is an
+         * actual page that needs to be released. */
+        if ( p2mt == p2m_ram_paging_out )
+        {
+            ASSERT(mfn_valid(mfn));
+            page = mfn_to_page(mfn);
+            if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
+                put_page(page);
+        }
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
         return 1;
     }
@@ -181,7 +190,6 @@ int guest_remove_page(struct domain *d, 
         return 0;
     }
             
-    page = mfn_to_page(mfn);
 #ifdef CONFIG_X86_64
     if ( p2m_is_shared(p2mt) )
     {
@@ -190,10 +198,17 @@ int guest_remove_page(struct domain *d, 
          * need to trigger proper cleanup. Once done, this is 
          * like any other page. */
         if ( mem_sharing_unshare_page(d, gmfn, 0) )
+        {
+            put_gfn(d, gmfn);
             return 0;
+        }
+        /* Maybe the mfn changed */
+        mfn = mfn_x(get_gfn_query_unlocked(d, gmfn, &p2mt));
+        ASSERT(!p2m_is_shared(p2mt));
     }
 #endif /* CONFIG_X86_64 */
 
+    page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
     {
         put_gfn(d, gmfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05: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.xensource.com>)
	id 1RvMCT-0001iO-Up; Thu, 09 Feb 2012 05:05:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCR-0001iH-OK
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328763889!62115547!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17202 invoked from network); 9 Feb 2012 05:04:50 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-9.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 05:04:50 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 55F107EC083;
	Wed,  8 Feb 2012 21:05:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=dQUkk82P4B1I/JrS9Uc1bF7k98gfXtFbPAavMOXWbOOx
	to3Jpg5JEDGIMhjSZlP2lMlrm88PhehPI3mcdHe4fQRvyBDdAH7new+wTku88M9w
	LogN/ufxoLLVANTgIQOXfwm5GCVYfRTz+8WEuZVNczj5NHK/Ml3W6pnFcxno0bE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=3ik0XZXyeb2M7kAJmUTbeCGqLtI=; b=eil33vRHf9U
	2nW5JIE+JxJAexgDl9KkoUIowzpH1m+QYx1mLcuRH8x8zUpMIjWHl0RrMggd7oQ7
	fnNCHpsykxkiFPyhwDk9zCPkF6YtU8ZUZTaRtcQkwIUWMZoW3VEXSODThtpLeztW
	xfDfsYoFO2vbsTp92+8hNV7T38HXVt+g=
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 7CBA47EC080; 
	Wed,  8 Feb 2012 21:05:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e187e3e400552b32f23eddbc3094051f320526a9
Message-Id: <e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 20 files changed, 421 insertions(+), 276 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>

diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -81,10 +81,10 @@ int xc_mem_paging_load(xc_interface *xch
     if ( mlock(buffer, XC_PAGE_SIZE) )
         return -1;
         
-    rc = xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                buffer, NULL, gfn);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     old_errno = errno;
     munlock(buffer, XC_PAGE_SIZE);
@@ -95,10 +95,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,86 +143,72 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 long xc_sharing_freed_pages(xc_interface *xch)
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,8 +1888,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 7bbe59cba812 -r e187e3e40055 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r 7bbe59cba812 -r e187e3e40055 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -34,9 +34,9 @@ static int usage(const char* prog)
     int rc = f; \
     if ( rc < 0 ) { \
         printf("error executing %s: %s\n", #f, \
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_S_HANDLE_INVALID) ? \
                 "problem with client handle" :\
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_C_HANDLE_INVALID) ? \
                 "problem with source handle" : strerror(errno)); \
         return rc; \
     } \
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -460,6 +461,54 @@ static void mem_access_notification(stru
     p2m_mem_access_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 )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -533,11 +582,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -572,14 +618,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -749,12 +749,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
         {
@@ -762,12 +762,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn);
         if ( spage == NULL )
         {
@@ -782,14 +782,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->sharing->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->sharing->handle != ch )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
@@ -851,7 +851,7 @@ int mem_sharing_add_to_physmap(struct do
                  p2m_query, &tg);
 
     /* Get the source shared page, check and lock */
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn);
     if ( spage == NULL )
         goto err_out;
@@ -865,7 +865,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1016,9 +1016,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1026,14 +1026,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1044,7 +1037,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1059,7 +1052,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1068,38 +1061,38 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1111,11 +1104,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1124,20 +1117,20 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1147,11 +1140,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1159,21 +1152,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(_mfn(mfn));
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1190,6 +1183,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -42,6 +42,8 @@ void mem_event_put_request(struct domain
 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 -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,43 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
-
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,63 +755,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-/* The following allows sharing of grant refs. This is useful
- * for sharing utilities sitting as "filters" in IO backends
- * (e.g. memshr + blktap(2)). The IO backend is only exposed 
- * to grant references, and this allows sharing of the grefs */
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
-
-#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
-    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
-    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
-    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
-
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        uint8_t enable;                   /* CONTROL */
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -305,6 +305,12 @@ struct xen_pod_target {
 };
 typedef struct xen_pod_target xen_pod_target_t;
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
 /*
  * Get the number of MFNs saved through memory sharing.
  * The call never fails. 
@@ -312,6 +318,87 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t     op;         /* XENMEM_*_op_* */
+    domid_t     domain;
+    
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_aligned_t    buffer;
+    /* Other OPs */
+    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t     op;     /* XENMEM_sharing_op_* */
+    domid_t     domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_aligned_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
+            uint64_aligned_t client_handle; /* IN: handle to the client page */
+            domid_t  client_domain; /* IN: the client domain id */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_aligned_t gfn;      /* IN: gfn to debug          */
+                uint64_aligned_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05: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.xensource.com>)
	id 1RvMCT-0001iO-Up; Thu, 09 Feb 2012 05:05:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCR-0001iH-OK
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328763889!62115547!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17202 invoked from network); 9 Feb 2012 05:04:50 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-9.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 05:04:50 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 55F107EC083;
	Wed,  8 Feb 2012 21:05:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=dQUkk82P4B1I/JrS9Uc1bF7k98gfXtFbPAavMOXWbOOx
	to3Jpg5JEDGIMhjSZlP2lMlrm88PhehPI3mcdHe4fQRvyBDdAH7new+wTku88M9w
	LogN/ufxoLLVANTgIQOXfwm5GCVYfRTz+8WEuZVNczj5NHK/Ml3W6pnFcxno0bE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=3ik0XZXyeb2M7kAJmUTbeCGqLtI=; b=eil33vRHf9U
	2nW5JIE+JxJAexgDl9KkoUIowzpH1m+QYx1mLcuRH8x8zUpMIjWHl0RrMggd7oQ7
	fnNCHpsykxkiFPyhwDk9zCPkF6YtU8ZUZTaRtcQkwIUWMZoW3VEXSODThtpLeztW
	xfDfsYoFO2vbsTp92+8hNV7T38HXVt+g=
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 7CBA47EC080; 
	Wed,  8 Feb 2012 21:05:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e187e3e400552b32f23eddbc3094051f320526a9
Message-Id: <e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 20 files changed, 421 insertions(+), 276 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>

diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -81,10 +81,10 @@ int xc_mem_paging_load(xc_interface *xch
     if ( mlock(buffer, XC_PAGE_SIZE) )
         return -1;
         
-    rc = xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                buffer, NULL, gfn);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     old_errno = errno;
     munlock(buffer, XC_PAGE_SIZE);
@@ -95,10 +95,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,86 +143,72 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 long xc_sharing_freed_pages(xc_interface *xch)
diff -r 7bbe59cba812 -r e187e3e40055 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,8 +1888,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 7bbe59cba812 -r e187e3e40055 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r 7bbe59cba812 -r e187e3e40055 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -34,9 +34,9 @@ static int usage(const char* prog)
     int rc = f; \
     if ( rc < 0 ) { \
         printf("error executing %s: %s\n", #f, \
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_S_HANDLE_INVALID) ? \
                 "problem with client handle" :\
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_C_HANDLE_INVALID) ? \
                 "problem with source handle" : strerror(errno)); \
         return rc; \
     } \
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -460,6 +461,54 @@ static void mem_access_notification(stru
     p2m_mem_access_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 )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -533,11 +582,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -572,14 +618,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -749,12 +749,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
         {
@@ -762,12 +762,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn);
         if ( spage == NULL )
         {
@@ -782,14 +782,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->sharing->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->sharing->handle != ch )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
@@ -851,7 +851,7 @@ int mem_sharing_add_to_physmap(struct do
                  p2m_query, &tg);
 
     /* Get the source shared page, check and lock */
-    ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn);
     if ( spage == NULL )
         goto err_out;
@@ -865,7 +865,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1016,9 +1016,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1026,14 +1026,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1044,7 +1037,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1059,7 +1052,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1068,38 +1061,38 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1111,11 +1104,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
@@ -1124,20 +1117,20 @@ int mem_sharing_domctl(struct domain *d,
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1147,11 +1140,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1159,21 +1152,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(_mfn(mfn));
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1190,6 +1183,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 7bbe59cba812 -r e187e3e40055 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 int mem_access_send_req(struct domain *d, mem_event_request_t *req);
 
 
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -42,6 +42,8 @@ void mem_event_put_request(struct domain
 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 -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,43 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
-
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,63 +755,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-/* The following allows sharing of grant refs. This is useful
- * for sharing utilities sitting as "filters" in IO backends
- * (e.g. memshr + blktap(2)). The IO backend is only exposed 
- * to grant references, and this allows sharing of the grefs */
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
-
-#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
-    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
-    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
-    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
-
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        uint8_t enable;                   /* CONTROL */
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r 7bbe59cba812 -r e187e3e40055 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -305,6 +305,12 @@ struct xen_pod_target {
 };
 typedef struct xen_pod_target xen_pod_target_t;
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
 /*
  * Get the number of MFNs saved through memory sharing.
  * The call never fails. 
@@ -312,6 +318,87 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t     op;         /* XENMEM_*_op_* */
+    domid_t     domain;
+    
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_aligned_t    buffer;
+    /* Other OPs */
+    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t     op;     /* XENMEM_sharing_op_* */
+    domid_t     domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_aligned_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
+            uint64_aligned_t client_handle; /* IN: handle to the client page */
+            domid_t  client_domain; /* IN: the client domain id */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_aligned_t gfn;      /* IN: gfn to debug          */
+                uint64_aligned_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvMCh-0001jt-H8; Thu, 09 Feb 2012 05:05:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCY-0001iI-45
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328763938!12614435!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20645 invoked from network); 9 Feb 2012 05:05:39 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 05:05:39 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 19E477EC080;
	Wed,  8 Feb 2012 21:05:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=VbvVfR6wY34q+7/2hPiGw9iHfoL6+4kGL/jpBQJx9lWz
	c2rwstFHVFV944DldZHbu5umFgYsw0/zWOFHWTG7F5yLOt0nR7HXmZU6j4D+YIsR
	obO+Y/9mXgwUajcJipb+p/ajNiQx10ShL1kiYDnUr4WNqvTPm25XamTi45pWxVk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=DJb/Vmszxq5vXANvJsmNt+wW0pI=; b=KVmqhy2PjOB
	nO+CXysAugWrk1lsZnyB33wboI989MWwtOnp2ehKkueqYNcukz5lB6ars0bUCd0l
	4UYKOHBKZz5ARgVuZUSYeRcHsR1IDvI5xYPmUVVzFhFEzXvTiYsnjhZiwRodH59Y
	89wT5jLWIxtDgYbuvRZeGNagfFG4HU18=
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 868577EC084; 
	Wed,  8 Feb 2012 21:05:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 26217ae46e4549f3893625b78f51ef28f9b6bb4f
Message-Id: <26217ae46e4549f38936.1328767707@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c              |  11 +++++++++++
 tools/libxc/xenctrl.h                |   1 +
 tools/tests/mem-sharing/memshrtool.c |  11 +++++++++++
 xen/arch/x86/mm/mem_sharing.c        |  13 ++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   3 +++
 xen/arch/x86/x86_64/mm.c             |   2 ++
 xen/include/asm-x86/mem_sharing.h    |   3 ++-
 xen/include/public/memory.h          |   1 +
 8 files changed, 37 insertions(+), 8 deletions(-)


Remove costly mem_sharting audits from the inline path, and instead make them
callable as a memop.

Have the audit function return the number of errors detected.

Update memshrtool to be able to trigger audits.

Set sharing audits as enabled by default.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>

diff -r e187e3e40055 -r 26217ae46e45 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,6 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_audit(xc_interface *xch)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_audit;
+
+    return do_memory_op(xch, XENMEM_sharing_op, &mso, sizeof(mso));
+}
+
 long xc_sharing_freed_pages(xc_interface *xch)
 {
     return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
diff -r e187e3e40055 -r 26217ae46e45 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1956,6 +1956,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
diff -r e187e3e40055 -r 26217ae46e45 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -27,6 +27,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
     return 1;
 }
 
@@ -160,6 +161,16 @@ int main(int argc, const char** argv)
         gfn = strtol(argv[3], NULL, 0);
         R(xc_memshr_debug_gfn(xch, domid, gfn));
     }
+    else if( !strcasecmp(cmd, "audit") )
+    {
+        int rc = xc_memshr_audit(xch);
+        if ( rc < 0 )
+        {
+            printf("error executing xc_memshr_audit: %s\n", strerror(errno));
+            return rc;
+        }
+        printf("Audit returned %d errors.\n", rc);
+    }
 
     return 0;
 }
diff -r e187e3e40055 -r 26217ae46e45 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -50,8 +50,6 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #if MEM_SHARING_AUDIT
 
-static void mem_sharing_audit(void);
-
 static struct list_head shr_audit_list;
 static spinlock_t shr_audit_lock;
 DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
@@ -81,7 +79,10 @@ static inline void audit_del_list(struct
 
 #else
 
-#define mem_sharing_audit() ((void)0)
+int mem_sharing_audit(void)
+{
+    return -ENOSYS;
+}
 
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
@@ -212,7 +213,7 @@ static struct page_info* mem_sharing_loo
 }
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
+int mem_sharing_audit(void)
 {
     int errors = 0;
     unsigned long count_expected;
@@ -338,6 +339,7 @@ static void mem_sharing_audit(void)
         errors++;
     }
 
+    return errors;
 }
 #endif
 
@@ -914,7 +916,6 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1178,8 +1179,6 @@ int mem_sharing_memop(struct domain *d, 
             break;
     }
 
-    mem_sharing_audit();
-
     return rc;
 }
 
diff -r e187e3e40055 -r 26217ae46e45 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -3,6 +3,7 @@
 #include <compat/memory.h>
 #include <compat/xen.h>
 #include <asm/mem_event.h>
+#include <asm/mem_sharing.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -228,6 +229,8 @@ int compat_arch_memory_op(int op, XEN_GU
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r e187e3e40055 -r 26217ae46e45 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1117,6 +1117,8 @@ long subarch_memory_op(int op, XEN_GUEST
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r e187e3e40055 -r 26217ae46e45 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -26,7 +26,7 @@
 #include <public/memory.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -61,6 +61,7 @@ int mem_sharing_memop(struct domain *d,
                        xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
 #else 
diff -r e187e3e40055 -r 26217ae46e45 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -349,6 +349,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op
 #define XENMEM_sharing_op_debug_mfn         5
 #define XENMEM_sharing_op_debug_gref        6
 #define XENMEM_sharing_op_add_physmap       7
+#define XENMEM_sharing_op_audit             8
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvMCh-0001jt-H8; Thu, 09 Feb 2012 05:05:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCY-0001iI-45
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:47 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328763938!12614435!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20645 invoked from network); 9 Feb 2012 05:05:39 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 05:05:39 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 19E477EC080;
	Wed,  8 Feb 2012 21:05:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=VbvVfR6wY34q+7/2hPiGw9iHfoL6+4kGL/jpBQJx9lWz
	c2rwstFHVFV944DldZHbu5umFgYsw0/zWOFHWTG7F5yLOt0nR7HXmZU6j4D+YIsR
	obO+Y/9mXgwUajcJipb+p/ajNiQx10ShL1kiYDnUr4WNqvTPm25XamTi45pWxVk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=DJb/Vmszxq5vXANvJsmNt+wW0pI=; b=KVmqhy2PjOB
	nO+CXysAugWrk1lsZnyB33wboI989MWwtOnp2ehKkueqYNcukz5lB6ars0bUCd0l
	4UYKOHBKZz5ARgVuZUSYeRcHsR1IDvI5xYPmUVVzFhFEzXvTiYsnjhZiwRodH59Y
	89wT5jLWIxtDgYbuvRZeGNagfFG4HU18=
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 868577EC084; 
	Wed,  8 Feb 2012 21:05:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 26217ae46e4549f3893625b78f51ef28f9b6bb4f
Message-Id: <26217ae46e4549f38936.1328767707@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c              |  11 +++++++++++
 tools/libxc/xenctrl.h                |   1 +
 tools/tests/mem-sharing/memshrtool.c |  11 +++++++++++
 xen/arch/x86/mm/mem_sharing.c        |  13 ++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   3 +++
 xen/arch/x86/x86_64/mm.c             |   2 ++
 xen/include/asm-x86/mem_sharing.h    |   3 ++-
 xen/include/public/memory.h          |   1 +
 8 files changed, 37 insertions(+), 8 deletions(-)


Remove costly mem_sharting audits from the inline path, and instead make them
callable as a memop.

Have the audit function return the number of errors detected.

Update memshrtool to be able to trigger audits.

Set sharing audits as enabled by default.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>

diff -r e187e3e40055 -r 26217ae46e45 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,6 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_audit(xc_interface *xch)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_audit;
+
+    return do_memory_op(xch, XENMEM_sharing_op, &mso, sizeof(mso));
+}
+
 long xc_sharing_freed_pages(xc_interface *xch)
 {
     return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
diff -r e187e3e40055 -r 26217ae46e45 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1956,6 +1956,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
diff -r e187e3e40055 -r 26217ae46e45 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -27,6 +27,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
     return 1;
 }
 
@@ -160,6 +161,16 @@ int main(int argc, const char** argv)
         gfn = strtol(argv[3], NULL, 0);
         R(xc_memshr_debug_gfn(xch, domid, gfn));
     }
+    else if( !strcasecmp(cmd, "audit") )
+    {
+        int rc = xc_memshr_audit(xch);
+        if ( rc < 0 )
+        {
+            printf("error executing xc_memshr_audit: %s\n", strerror(errno));
+            return rc;
+        }
+        printf("Audit returned %d errors.\n", rc);
+    }
 
     return 0;
 }
diff -r e187e3e40055 -r 26217ae46e45 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -50,8 +50,6 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #if MEM_SHARING_AUDIT
 
-static void mem_sharing_audit(void);
-
 static struct list_head shr_audit_list;
 static spinlock_t shr_audit_lock;
 DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
@@ -81,7 +79,10 @@ static inline void audit_del_list(struct
 
 #else
 
-#define mem_sharing_audit() ((void)0)
+int mem_sharing_audit(void)
+{
+    return -ENOSYS;
+}
 
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
@@ -212,7 +213,7 @@ static struct page_info* mem_sharing_loo
 }
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
+int mem_sharing_audit(void)
 {
     int errors = 0;
     unsigned long count_expected;
@@ -338,6 +339,7 @@ static void mem_sharing_audit(void)
         errors++;
     }
 
+    return errors;
 }
 #endif
 
@@ -914,7 +916,6 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1178,8 +1179,6 @@ int mem_sharing_memop(struct domain *d, 
             break;
     }
 
-    mem_sharing_audit();
-
     return rc;
 }
 
diff -r e187e3e40055 -r 26217ae46e45 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -3,6 +3,7 @@
 #include <compat/memory.h>
 #include <compat/xen.h>
 #include <asm/mem_event.h>
+#include <asm/mem_sharing.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -228,6 +229,8 @@ int compat_arch_memory_op(int op, XEN_GU
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r e187e3e40055 -r 26217ae46e45 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1117,6 +1117,8 @@ long subarch_memory_op(int op, XEN_GUEST
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r e187e3e40055 -r 26217ae46e45 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -26,7 +26,7 @@
 #include <public/memory.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -61,6 +61,7 @@ int mem_sharing_memop(struct domain *d,
                        xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
 #else 
diff -r e187e3e40055 -r 26217ae46e45 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -349,6 +349,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op
 #define XENMEM_sharing_op_debug_mfn         5
 #define XENMEM_sharing_op_debug_gref        6
 #define XENMEM_sharing_op_add_physmap       7
+#define XENMEM_sharing_op_audit             8
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05: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.xensource.com>)
	id 1RvMCc-0001j3-2b; Thu, 09 Feb 2012 05:05:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCV-0001iG-A6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328763936!11100353!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NjMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18680 invoked from network); 9 Feb 2012 05:05:37 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 05:05:37 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 52E4C7EC082;
	Wed,  8 Feb 2012 21:05:36 -0800 (PST)
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=ZEy8mS7gOfOxsmLWtbStI+
	UcaLuY8hA/TDB7ilT9K7yqcJhVV1AFXgjrqsn4DCj35rIs/8arj59SMm4XUUQwe+
	0o+WQl8zGuC43vGcFgDViQnxHBwQhygrPHqUEU6uNc7wyd+jyyPUCtFfuBOIFTle
	hH92xjWRB+6cXUYhnpyb8=
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=aHyqUIGu4ZTI
	sjEOdMU2AW3o/j4=; b=KuJjjyGh5h7KWKXp5KJ0FZwWWVkjMgIIt6c0ALTL1H6K
	0A1WUT3Anl1REYbHUW/WmpIKW6MT5xaLlzzHvxT9ycEJZsRCUY7ZwiU4AGA4HicA
	KJ+FkLPrVhs4eKSFZ3Zy2mROltG44hFToqXPAxjBnaGjD985+Vy7IzGUucdcDMw=
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 B61E27EC080; 
	Wed,  8 Feb 2012 21:05:35 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access interfaces
	v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

i(Was switch from domctl to memops)
Changes from v1 posted Feb 2nd 2012

- Patches 1 & 2 Acked-by Tim Deegan on the hypervisor side
- Added patch 3 to clean up the enable domctl interface, based on
  discussion with Ian Campbell

Description from original post follows:

Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

This is a backwards-incompatible ABI change. It's been floating on the list for
a couple weeks now, with no nacks thus far.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 tools/libxc/xc_memshr.c              |   11 ++
 tools/libxc/xenctrl.h                |    1 +
 tools/tests/mem-sharing/memshrtool.c |   11 ++
 xen/arch/x86/mm/mem_sharing.c        |   13 +-
 xen/arch/x86/x86_64/compat/mm.c      |    3 +
 xen/arch/x86/x86_64/mm.c             |    2 +
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 xen/include/public/memory.h          |    3 +-
 tools/libxc/xc_mem_access.c          |   10 +-
 tools/libxc/xc_mem_event.c           |   16 ++-
 tools/libxc/xc_mem_paging.c          |   10 +-
 tools/libxc/xenctrl.h                |    7 +-
 tools/tests/xen-access/xen-access.c  |   56 +---------
 tools/xenpaging/xenpaging.c          |   33 +----
 tools/xenpaging/xenpaging.h          |    2 +-
 xen/arch/x86/mm/mem_event.c          |   33 +-----
 xen/include/public/domctl.h          |    4 +-
 xen/include/public/mem_event.h       |    4 -
 xen/include/xen/sched.h              |    2 -
 39 files changed, 514 insertions(+), 407 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05: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.xensource.com>)
	id 1RvMCc-0001j3-2b; Thu, 09 Feb 2012 05:05:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCV-0001iG-A6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328763936!11100353!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NjMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18680 invoked from network); 9 Feb 2012 05:05:37 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 05:05:37 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 52E4C7EC082;
	Wed,  8 Feb 2012 21:05:36 -0800 (PST)
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=ZEy8mS7gOfOxsmLWtbStI+
	UcaLuY8hA/TDB7ilT9K7yqcJhVV1AFXgjrqsn4DCj35rIs/8arj59SMm4XUUQwe+
	0o+WQl8zGuC43vGcFgDViQnxHBwQhygrPHqUEU6uNc7wyd+jyyPUCtFfuBOIFTle
	hH92xjWRB+6cXUYhnpyb8=
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=aHyqUIGu4ZTI
	sjEOdMU2AW3o/j4=; b=KuJjjyGh5h7KWKXp5KJ0FZwWWVkjMgIIt6c0ALTL1H6K
	0A1WUT3Anl1REYbHUW/WmpIKW6MT5xaLlzzHvxT9ycEJZsRCUY7ZwiU4AGA4HicA
	KJ+FkLPrVhs4eKSFZ3Zy2mROltG44hFToqXPAxjBnaGjD985+Vy7IzGUucdcDMw=
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 B61E27EC080; 
	Wed,  8 Feb 2012 21:05:35 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access interfaces
	v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

i(Was switch from domctl to memops)
Changes from v1 posted Feb 2nd 2012

- Patches 1 & 2 Acked-by Tim Deegan on the hypervisor side
- Added patch 3 to clean up the enable domctl interface, based on
  discussion with Ian Campbell

Description from original post follows:

Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

This is a backwards-incompatible ABI change. It's been floating on the list for
a couple weeks now, with no nacks thus far.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |   99 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 tools/libxc/xc_memshr.c              |   11 ++
 tools/libxc/xenctrl.h                |    1 +
 tools/tests/mem-sharing/memshrtool.c |   11 ++
 xen/arch/x86/mm/mem_sharing.c        |   13 +-
 xen/arch/x86/x86_64/compat/mm.c      |    3 +
 xen/arch/x86/x86_64/mm.c             |    2 +
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 xen/include/public/memory.h          |    3 +-
 tools/libxc/xc_mem_access.c          |   10 +-
 tools/libxc/xc_mem_event.c           |   16 ++-
 tools/libxc/xc_mem_paging.c          |   10 +-
 tools/libxc/xenctrl.h                |    7 +-
 tools/tests/xen-access/xen-access.c  |   56 +---------
 tools/xenpaging/xenpaging.c          |   33 +----
 tools/xenpaging/xenpaging.h          |    2 +-
 xen/arch/x86/mm/mem_event.c          |   33 +-----
 xen/include/public/domctl.h          |    4 +-
 xen/include/public/mem_event.h       |    4 -
 xen/include/xen/sched.h              |    2 -
 39 files changed, 514 insertions(+), 407 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvMCk-0001kI-0B; Thu, 09 Feb 2012 05:05:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCZ-0001iN-5k
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328763939!12621468!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTgyMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25745 invoked from network); 9 Feb 2012 05:05:40 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 05:05:40 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 20ECA7EC084;
	Wed,  8 Feb 2012 21:05:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=GOK1qrjQXBzkv15HgW4g+zVsPzvKiXJXJTSp7ichQlxZ
	f4Jp9/Mc41H9nkhYXWpw/v3UsVIRj0zDkcj3cEFGwAa0PiizxAcATbza3RF0kfMw
	1/AhTjL9tB45pNi7xM4RCWivXVW4RNvivVGGl9adEBIhAc7z4w+UH0hlLg6ZRaA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=g6shxW4z9/IfQsp731CrHUvejEs=; b=YEH7jlGHZM3
	dd59+lf0/44+RKjz5t0WV9GsYZrhu3Qor9UizRO4h3eDFj8NGjS7zNJKWa31GQvE
	Jf624AX2WABo+B8nhLNCDalsruXnhUDBGgSqhYsBkS2j1Eg2eDzgZhckOnHU8LXl
	SVpuSSiq/mB2LhN3dnoguOyM00oDUR7c=
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 7F3F37EC082; 
	Wed,  8 Feb 2012 21:05:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6325dd552671f0a1ce3914095c0f03f6d3615cba
Message-Id: <6325dd552671f0a1ce39.1328767708@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] Tools: Sanitize mem_event/access/paging
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c         |  10 +++++-
 tools/libxc/xc_mem_event.c          |  16 +++++++---
 tools/libxc/xc_mem_paging.c         |  10 +++++-
 tools/libxc/xenctrl.h               |   7 ++-
 tools/tests/xen-access/xen-access.c |  56 +++++-------------------------------
 tools/xenpaging/xenpaging.c         |  33 ++++++---------------
 tools/xenpaging/xenpaging.h         |   2 +-
 xen/arch/x86/mm/mem_event.c         |  33 +-------------------
 xen/include/public/domctl.h         |   4 +-
 xen/include/public/mem_event.h      |   4 --
 xen/include/xen/sched.h             |   2 -
 11 files changed, 56 insertions(+), 121 deletions(-)


Don't use the superfluous shared page, return the event channel directly as
part of the domctl struct, instead.

Use hypercall buffers to manage the ring page.

In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
so please voice any concerns.

Known pending issues:
- pager could die and its ring page could be used by some other process, yet
  Xen retains the mapping to it.
- use a saner interface for the paging_load buffer.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,19 +24,25 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page, void *ring_page)
+                         unsigned int mode, uint32_t *port,
+                         xc_hypercall_buffer_t *ring_page)
 {
     DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BUFFER_ARGUMENT(ring_page);
+    int rc;
 
     domctl.cmd = XEN_DOMCTL_mem_event_op;
     domctl.domain = domain_id;
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
-
-    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
-    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
+    domctl.u.mem_event_op.ring_addr = (ring_page) ?
+        (unsigned long long) HYPERCALL_BUFFER_AS_ARG(ring_page) : 0;
     
-    return do_domctl(xch, &domctl);
+    errno = 0;
+    rc = do_domctl(xch, &domctl);
+    if ( !rc && port )
+        *port = domctl.u.mem_event_op.port;
+    return rc;
 }
 
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+        
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,13 +1888,14 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page, void *ring_page);
+                         unsigned int mode, uint32_t *port,
+                         xc_hypercall_buffer_t *ring_page);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
                            unsigned long gfn);
@@ -1906,7 +1907,7 @@ int xc_mem_paging_resume(xc_interface *x
                          unsigned long gfn);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
diff -r 26217ae46e45 -r 6325dd552671 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -98,7 +98,7 @@ typedef struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
     spinlock_t ring_lock;
 } mem_event_t;
@@ -167,36 +167,14 @@ int xc_wait_for_event_or_timeout(xc_inte
     return -errno;
 }
 
-static void *init_page(void)
-{
-    void *buffer;
-    int ret;
-
-    /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
-
-    /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
-
-    return buffer;
-
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
-}
-
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
     xenaccess_t *xenaccess;
     xc_interface *xch;
     int rc;
+    DECLARE_HYPERCALL_BUFFER(void, ring_page);
 
+    (void)ring_page;
     xch = xc_interface_open(NULL, NULL, 0);
     if ( !xch )
         goto err_iface;
@@ -214,16 +192,9 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Set domain id */
     xenaccess->mem_event.domain_id = domain_id;
 
-    /* Initialise shared page */
-    xenaccess->mem_event.shared_page = init_page();
-    if ( xenaccess->mem_event.shared_page == NULL )
-    {
-        ERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
-    xenaccess->mem_event.ring_page = init_page();
+    xenaccess->mem_event.ring_page = 
+        xc_hypercall_buffer_alloc_pages(xenaccess->xc_handle, ring_page, 1);
     if ( xenaccess->mem_event.ring_page == NULL )
     {
         ERROR("Error initialising ring page");
@@ -242,8 +213,8 @@ xenaccess_t *xenaccess_init(xc_interface
 
     /* Initialise Xen */
     rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id,
-                             xenaccess->mem_event.shared_page,
-                             xenaccess->mem_event.ring_page);
+                             &xenaccess->mem_event.evtchn_port,
+                             HYPERCALL_BUFFER(ring_page));
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -271,7 +242,7 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
                                     xenaccess->mem_event.domain_id,
-                                    xenaccess->mem_event.shared_page->port);
+                                    xenaccess->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         ERROR("Failed to bind event channel");
@@ -322,17 +293,8 @@ xenaccess_t *xenaccess_init(xc_interface
  err:
     if ( xenaccess )
     {
-        if ( xenaccess->mem_event.shared_page )
-        {
-            munlock(xenaccess->mem_event.shared_page, PAGE_SIZE);
-            free(xenaccess->mem_event.shared_page);
-        }
-
         if ( xenaccess->mem_event.ring_page )
-        {
-            munlock(xenaccess->mem_event.ring_page, PAGE_SIZE);
-            free(xenaccess->mem_event.ring_page);
-        }
+            xc_hypercall_buffer_free_pages(xch, ring_page, 1);
 
         free(xenaccess->platform_info);
         free(xenaccess->domain_info);
diff -r 26217ae46e45 -r 6325dd552671 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -285,6 +285,7 @@ static struct xenpaging *xenpaging_init(
     xentoollog_logger *dbg = NULL;
     char *p;
     int rc;
+    DECLARE_HYPERCALL_BUFFER(void, ring_page);
 
     /* Allocate memory */
     paging = calloc(1, sizeof(struct xenpaging));
@@ -341,16 +342,9 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    /* Initialise shared page */
-    paging->mem_event.shared_page = init_page();
-    if ( paging->mem_event.shared_page == NULL )
-    {
-        PERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
-    paging->mem_event.ring_page = init_page();
+    paging->mem_event.ring_page = 
+        xc_hypercall_buffer_alloc_pages(paging->xc_handle, ring_page, 1);
     if ( paging->mem_event.ring_page == NULL )
     {
         PERROR("Error initialising ring page");
@@ -365,8 +359,8 @@ static struct xenpaging *xenpaging_init(
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             paging->mem_event.shared_page,
-                             paging->mem_event.ring_page);
+                             &paging->mem_event.evtchn_port, 
+                             HYPERCALL_BUFFER(ring_page));
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -397,7 +391,7 @@ static struct xenpaging *xenpaging_init(
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(paging->mem_event.xce_handle,
                                     paging->mem_event.domain_id,
-                                    paging->mem_event.shared_page->port);
+                                    paging->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         PERROR("Failed to bind event channel");
@@ -452,19 +446,12 @@ static struct xenpaging *xenpaging_init(
     {
         if ( paging->xs_handle )
             xs_close(paging->xs_handle);
+
+        if ( paging->mem_event.ring_page )
+            xc_hypercall_buffer_free_pages(xch, ring_page, 1);
+
         if ( xch )
             xc_interface_close(xch);
-        if ( paging->mem_event.shared_page )
-        {
-            munlock(paging->mem_event.shared_page, PAGE_SIZE);
-            free(paging->mem_event.shared_page);
-        }
-
-        if ( paging->mem_event.ring_page )
-        {
-            munlock(paging->mem_event.ring_page, PAGE_SIZE);
-            free(paging->mem_event.ring_page);
-        }
 
         free(dom_path);
         free(watch_target_tot_pages);
diff -r 26217ae46e45 -r 6325dd552671 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -36,7 +36,7 @@ struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
 };
 
diff -r 26217ae46e45 -r 6325dd552671 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -50,12 +50,10 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
-    unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
+    unsigned long ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
     mfn_t ring_mfn;
-    mfn_t shared_mfn;
 
     /* Only one helper at a time. If the helper crashed,
      * the ring is in an undefined state and so is the guest.
@@ -66,10 +64,6 @@ static int mem_event_enable(
     /* Get MFN of ring page */
     guest_get_eff_l1e(v, ring_addr, &l1e);
     ring_gfn = l1e_get_pfn(l1e);
-    /* We're grabbing these two in an order that could deadlock
-     * dom0 if 1. it were an hvm 2. there were two concurrent
-     * enables 3. the two gfn's in each enable criss-crossed
-     * 2MB regions. Duly noted.... */
     ring_mfn = get_gfn(dom_mem_event, ring_gfn, &p2mt);
 
     if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) )
@@ -80,23 +74,9 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Get MFN of shared page */
-    guest_get_eff_l1e(v, shared_addr, &l1e);
-    shared_gfn = l1e_get_pfn(l1e);
-    shared_mfn = get_gfn(dom_mem_event, shared_gfn, &p2mt);
-
-    if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) )
-    {
-        put_gfn(dom_mem_event, ring_gfn);
-        put_gfn(dom_mem_event, shared_gfn);
-        return -EINVAL;
-    }
-
-    /* Map ring and shared pages */
+    /* Map ring page */
     med->ring_page = map_domain_page(mfn_x(ring_mfn));
-    med->shared_page = map_domain_page(mfn_x(shared_mfn));
     put_gfn(dom_mem_event, ring_gfn);
-    put_gfn(dom_mem_event, shared_gfn); 
 
     /* Set the number of currently blocked vCPUs to 0. */
     med->blocked = 0;
@@ -108,8 +88,7 @@ static int mem_event_enable(
     if ( rc < 0 )
         goto err;
 
-    ((mem_event_shared_page_t *)med->shared_page)->port = rc;
-    med->xen_port = rc;
+    med->xen_port = mec->port = rc;
 
     /* Prepare ring buffer */
     FRONT_RING_INIT(&med->front_ring,
@@ -125,9 +104,6 @@ static int mem_event_enable(
     return 0;
 
  err:
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
-
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -246,9 +222,6 @@ static int mem_event_disable(struct doma
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 
-        unmap_domain_page(med->shared_page);
-        med->shared_page = NULL;
-
         /* Unblock all vCPUs */
         for_each_vcpu ( d, v )
         {
diff -r 26217ae46e45 -r 6325dd552671 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -746,8 +746,8 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
-    uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
+    uint32_t port;              /* OUT: event channel for ring */
+    uint64_aligned_t ring_addr; /* IN:  Virtual address of ring page */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
diff -r 26217ae46e45 -r 6325dd552671 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -51,10 +51,6 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-typedef struct mem_event_shared_page {
-    uint32_t port;
-} mem_event_shared_page_t;
-
 typedef struct mem_event_st {
     uint16_t type;
     uint16_t flags;
diff -r 26217ae46e45 -r 6325dd552671 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -190,8 +190,6 @@ struct mem_event_domain
     /* The ring has 64 entries */
     unsigned char foreign_producers;
     unsigned char target_producers;
-    /* shared page */
-    mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 05:06:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 05:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvMCk-0001kI-0B; Thu, 09 Feb 2012 05:05:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvMCZ-0001iN-5k
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:05:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328763939!12621468!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTgyMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25745 invoked from network); 9 Feb 2012 05:05:40 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 05:05:40 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 20ECA7EC084;
	Wed,  8 Feb 2012 21:05:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=GOK1qrjQXBzkv15HgW4g+zVsPzvKiXJXJTSp7ichQlxZ
	f4Jp9/Mc41H9nkhYXWpw/v3UsVIRj0zDkcj3cEFGwAa0PiizxAcATbza3RF0kfMw
	1/AhTjL9tB45pNi7xM4RCWivXVW4RNvivVGGl9adEBIhAc7z4w+UH0hlLg6ZRaA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=g6shxW4z9/IfQsp731CrHUvejEs=; b=YEH7jlGHZM3
	dd59+lf0/44+RKjz5t0WV9GsYZrhu3Qor9UizRO4h3eDFj8NGjS7zNJKWa31GQvE
	Jf624AX2WABo+B8nhLNCDalsruXnhUDBGgSqhYsBkS2j1Eg2eDzgZhckOnHU8LXl
	SVpuSSiq/mB2LhN3dnoguOyM00oDUR7c=
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 7F3F37EC082; 
	Wed,  8 Feb 2012 21:05:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6325dd552671f0a1ce3914095c0f03f6d3615cba
Message-Id: <6325dd552671f0a1ce39.1328767708@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 09 Feb 2012 01:08:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] Tools: Sanitize mem_event/access/paging
	interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c         |  10 +++++-
 tools/libxc/xc_mem_event.c          |  16 +++++++---
 tools/libxc/xc_mem_paging.c         |  10 +++++-
 tools/libxc/xenctrl.h               |   7 ++-
 tools/tests/xen-access/xen-access.c |  56 +++++-------------------------------
 tools/xenpaging/xenpaging.c         |  33 ++++++---------------
 tools/xenpaging/xenpaging.h         |   2 +-
 xen/arch/x86/mm/mem_event.c         |  33 +-------------------
 xen/include/public/domctl.h         |   4 +-
 xen/include/public/mem_event.h      |   4 --
 xen/include/xen/sched.h             |   2 -
 11 files changed, 56 insertions(+), 121 deletions(-)


Don't use the superfluous shared page, return the event channel directly as
part of the domctl struct, instead.

Use hypercall buffers to manage the ring page.

In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
so please voice any concerns.

Known pending issues:
- pager could die and its ring page could be used by some other process, yet
  Xen retains the mapping to it.
- use a saner interface for the paging_load buffer.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,19 +24,25 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page, void *ring_page)
+                         unsigned int mode, uint32_t *port,
+                         xc_hypercall_buffer_t *ring_page)
 {
     DECLARE_DOMCTL;
+    DECLARE_HYPERCALL_BUFFER_ARGUMENT(ring_page);
+    int rc;
 
     domctl.cmd = XEN_DOMCTL_mem_event_op;
     domctl.domain = domain_id;
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
-
-    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
-    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
+    domctl.u.mem_event_op.ring_addr = (ring_page) ?
+        (unsigned long long) HYPERCALL_BUFFER_AS_ARG(ring_page) : 0;
     
-    return do_domctl(xch, &domctl);
+    errno = 0;
+    rc = do_domctl(xch, &domctl);
+    if ( !rc && port )
+        *port = domctl.u.mem_event_op.port;
+    return rc;
 }
 
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+        
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
diff -r 26217ae46e45 -r 6325dd552671 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,13 +1888,14 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page, void *ring_page);
+                         unsigned int mode, uint32_t *port,
+                         xc_hypercall_buffer_t *ring_page);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
                            unsigned long gfn);
@@ -1906,7 +1907,7 @@ int xc_mem_paging_resume(xc_interface *x
                          unsigned long gfn);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, xc_hypercall_buffer_t *ring_page);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
diff -r 26217ae46e45 -r 6325dd552671 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -98,7 +98,7 @@ typedef struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
     spinlock_t ring_lock;
 } mem_event_t;
@@ -167,36 +167,14 @@ int xc_wait_for_event_or_timeout(xc_inte
     return -errno;
 }
 
-static void *init_page(void)
-{
-    void *buffer;
-    int ret;
-
-    /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
-
-    /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
-
-    return buffer;
-
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
-}
-
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
     xenaccess_t *xenaccess;
     xc_interface *xch;
     int rc;
+    DECLARE_HYPERCALL_BUFFER(void, ring_page);
 
+    (void)ring_page;
     xch = xc_interface_open(NULL, NULL, 0);
     if ( !xch )
         goto err_iface;
@@ -214,16 +192,9 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Set domain id */
     xenaccess->mem_event.domain_id = domain_id;
 
-    /* Initialise shared page */
-    xenaccess->mem_event.shared_page = init_page();
-    if ( xenaccess->mem_event.shared_page == NULL )
-    {
-        ERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
-    xenaccess->mem_event.ring_page = init_page();
+    xenaccess->mem_event.ring_page = 
+        xc_hypercall_buffer_alloc_pages(xenaccess->xc_handle, ring_page, 1);
     if ( xenaccess->mem_event.ring_page == NULL )
     {
         ERROR("Error initialising ring page");
@@ -242,8 +213,8 @@ xenaccess_t *xenaccess_init(xc_interface
 
     /* Initialise Xen */
     rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id,
-                             xenaccess->mem_event.shared_page,
-                             xenaccess->mem_event.ring_page);
+                             &xenaccess->mem_event.evtchn_port,
+                             HYPERCALL_BUFFER(ring_page));
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -271,7 +242,7 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
                                     xenaccess->mem_event.domain_id,
-                                    xenaccess->mem_event.shared_page->port);
+                                    xenaccess->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         ERROR("Failed to bind event channel");
@@ -322,17 +293,8 @@ xenaccess_t *xenaccess_init(xc_interface
  err:
     if ( xenaccess )
     {
-        if ( xenaccess->mem_event.shared_page )
-        {
-            munlock(xenaccess->mem_event.shared_page, PAGE_SIZE);
-            free(xenaccess->mem_event.shared_page);
-        }
-
         if ( xenaccess->mem_event.ring_page )
-        {
-            munlock(xenaccess->mem_event.ring_page, PAGE_SIZE);
-            free(xenaccess->mem_event.ring_page);
-        }
+            xc_hypercall_buffer_free_pages(xch, ring_page, 1);
 
         free(xenaccess->platform_info);
         free(xenaccess->domain_info);
diff -r 26217ae46e45 -r 6325dd552671 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -285,6 +285,7 @@ static struct xenpaging *xenpaging_init(
     xentoollog_logger *dbg = NULL;
     char *p;
     int rc;
+    DECLARE_HYPERCALL_BUFFER(void, ring_page);
 
     /* Allocate memory */
     paging = calloc(1, sizeof(struct xenpaging));
@@ -341,16 +342,9 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    /* Initialise shared page */
-    paging->mem_event.shared_page = init_page();
-    if ( paging->mem_event.shared_page == NULL )
-    {
-        PERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
-    paging->mem_event.ring_page = init_page();
+    paging->mem_event.ring_page = 
+        xc_hypercall_buffer_alloc_pages(paging->xc_handle, ring_page, 1);
     if ( paging->mem_event.ring_page == NULL )
     {
         PERROR("Error initialising ring page");
@@ -365,8 +359,8 @@ static struct xenpaging *xenpaging_init(
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             paging->mem_event.shared_page,
-                             paging->mem_event.ring_page);
+                             &paging->mem_event.evtchn_port, 
+                             HYPERCALL_BUFFER(ring_page));
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -397,7 +391,7 @@ static struct xenpaging *xenpaging_init(
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(paging->mem_event.xce_handle,
                                     paging->mem_event.domain_id,
-                                    paging->mem_event.shared_page->port);
+                                    paging->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         PERROR("Failed to bind event channel");
@@ -452,19 +446,12 @@ static struct xenpaging *xenpaging_init(
     {
         if ( paging->xs_handle )
             xs_close(paging->xs_handle);
+
+        if ( paging->mem_event.ring_page )
+            xc_hypercall_buffer_free_pages(xch, ring_page, 1);
+
         if ( xch )
             xc_interface_close(xch);
-        if ( paging->mem_event.shared_page )
-        {
-            munlock(paging->mem_event.shared_page, PAGE_SIZE);
-            free(paging->mem_event.shared_page);
-        }
-
-        if ( paging->mem_event.ring_page )
-        {
-            munlock(paging->mem_event.ring_page, PAGE_SIZE);
-            free(paging->mem_event.ring_page);
-        }
 
         free(dom_path);
         free(watch_target_tot_pages);
diff -r 26217ae46e45 -r 6325dd552671 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -36,7 +36,7 @@ struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
 };
 
diff -r 26217ae46e45 -r 6325dd552671 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -50,12 +50,10 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
-    unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
+    unsigned long ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
     mfn_t ring_mfn;
-    mfn_t shared_mfn;
 
     /* Only one helper at a time. If the helper crashed,
      * the ring is in an undefined state and so is the guest.
@@ -66,10 +64,6 @@ static int mem_event_enable(
     /* Get MFN of ring page */
     guest_get_eff_l1e(v, ring_addr, &l1e);
     ring_gfn = l1e_get_pfn(l1e);
-    /* We're grabbing these two in an order that could deadlock
-     * dom0 if 1. it were an hvm 2. there were two concurrent
-     * enables 3. the two gfn's in each enable criss-crossed
-     * 2MB regions. Duly noted.... */
     ring_mfn = get_gfn(dom_mem_event, ring_gfn, &p2mt);
 
     if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) )
@@ -80,23 +74,9 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Get MFN of shared page */
-    guest_get_eff_l1e(v, shared_addr, &l1e);
-    shared_gfn = l1e_get_pfn(l1e);
-    shared_mfn = get_gfn(dom_mem_event, shared_gfn, &p2mt);
-
-    if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) )
-    {
-        put_gfn(dom_mem_event, ring_gfn);
-        put_gfn(dom_mem_event, shared_gfn);
-        return -EINVAL;
-    }
-
-    /* Map ring and shared pages */
+    /* Map ring page */
     med->ring_page = map_domain_page(mfn_x(ring_mfn));
-    med->shared_page = map_domain_page(mfn_x(shared_mfn));
     put_gfn(dom_mem_event, ring_gfn);
-    put_gfn(dom_mem_event, shared_gfn); 
 
     /* Set the number of currently blocked vCPUs to 0. */
     med->blocked = 0;
@@ -108,8 +88,7 @@ static int mem_event_enable(
     if ( rc < 0 )
         goto err;
 
-    ((mem_event_shared_page_t *)med->shared_page)->port = rc;
-    med->xen_port = rc;
+    med->xen_port = mec->port = rc;
 
     /* Prepare ring buffer */
     FRONT_RING_INIT(&med->front_ring,
@@ -125,9 +104,6 @@ static int mem_event_enable(
     return 0;
 
  err:
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
-
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -246,9 +222,6 @@ static int mem_event_disable(struct doma
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 
-        unmap_domain_page(med->shared_page);
-        med->shared_page = NULL;
-
         /* Unblock all vCPUs */
         for_each_vcpu ( d, v )
         {
diff -r 26217ae46e45 -r 6325dd552671 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -746,8 +746,8 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
-    uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
+    uint32_t port;              /* OUT: event channel for ring */
+    uint64_aligned_t ring_addr; /* IN:  Virtual address of ring page */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
diff -r 26217ae46e45 -r 6325dd552671 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -51,10 +51,6 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-typedef struct mem_event_shared_page {
-    uint32_t port;
-} mem_event_shared_page_t;
-
 typedef struct mem_event_st {
     uint16_t type;
     uint16_t flags;
diff -r 26217ae46e45 -r 6325dd552671 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -190,8 +190,6 @@ struct mem_event_domain
     /* The ring has 64 entries */
     unsigned char foreign_producers;
     unsigned char target_producers;
-    /* shared page */
-    mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 06:09:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 06:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvNBS-0002r4-4E; Thu, 09 Feb 2012 06: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 1RvNBQ-0002qz-FZ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 06:08:40 +0000
Received: from [85.158.139.83:13811] by server-7.bemta-5.messagelabs.com id
	88/FC-01252-7E2633F4; Thu, 09 Feb 2012 06:08:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328767718!14254683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13734 invoked from network); 9 Feb 2012 06: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;
	9 Feb 2012 06:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,388,1325462400"; d="scan'208";a="10588403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06: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.213.0; Thu, 9 Feb 2012 06:08:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvNBO-0006nf-FV;
	Thu, 09 Feb 2012 06:08:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvNBO-0000EL-1Y;
	Thu, 09 Feb 2012 06:08:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11902-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 06:08:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11902: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11902 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11902/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11901

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  8ba7ae0b070b
baseline version:
 xen                  8ba7ae0b070b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 06:09:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 06:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvNBS-0002r4-4E; Thu, 09 Feb 2012 06: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 1RvNBQ-0002qz-FZ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 06:08:40 +0000
Received: from [85.158.139.83:13811] by server-7.bemta-5.messagelabs.com id
	88/FC-01252-7E2633F4; Thu, 09 Feb 2012 06:08:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328767718!14254683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13734 invoked from network); 9 Feb 2012 06: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;
	9 Feb 2012 06:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,388,1325462400"; d="scan'208";a="10588403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06: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.213.0; Thu, 9 Feb 2012 06:08:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvNBO-0006nf-FV;
	Thu, 09 Feb 2012 06:08:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvNBO-0000EL-1Y;
	Thu, 09 Feb 2012 06:08:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11902-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 06:08:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11902: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11902 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11902/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11901

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  8ba7ae0b070b
baseline version:
 xen                  8ba7ae0b070b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 06:23:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 06:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvNOz-00038t-H1; Thu, 09 Feb 2012 06:22:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvNOy-00038o-Dg
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 06:22:40 +0000
Received: from [85.158.139.83:3660] by server-10.bemta-5.messagelabs.com id
	97/41-26909-F26633F4; Thu, 09 Feb 2012 06:22:39 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328768556!14314598!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20176 invoked from network); 9 Feb 2012 06:22:38 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 06:22:38 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q196MWPU051752
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 23:22:33 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
Date: Wed, 8 Feb 2012 23:22:42 -0700
Message-Id: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
	<4F3236C70200007800071AA1@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 23:22:33 -0700 (MST)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:

>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>> 
>>>> NAK. No backwards incompatible changes allowed in public headers.
>>> 
>>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>>> legacy
>>> source compatibility.  After trying lots of things, testing the impact on an
>>> existing blkfront
>>> and blkback implementation, I think the best two options are:
>>> 
>>> 1. Version the header file and require consumers to declare the interface
>>> version
>>>     they are using.  If the version isn't declared, the default, legacy,
>>> "version 1.0" will
>>>     be in effect.
>>> 
>>>     Positives:   No change in or constant naming conventions.  Data
>>> structures and
>>>                         constants for new features are properly hidden from
>>> legacy implementations.
>>>     Negatives: Messy #ifdefs
>> 
>> We already have this. See use of
>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>> headers.
> 
> Hmm, I would think these should specifically not be used in the
> io/ subtree - those aren't definitions of the interface to Xen, but
> ones shared between the respective backends and frontends.
> Each interface is (apart from its relying on the ring definitions)
> entirely self contained.
> 
> Jan


The versioning required allows a driver to declare, "I am compatible
with any source compatibility breaking changes up to version X of
the header file".  Declaring support for the latest version does
not require that a driver implement the new extensions.  Just one
constant needs to be renamed.  So I don't see this as really altering
the interface between front and backends (i.e. it is not a "blkif2")

If the xen-compat.h behavior is that you can safely import the
public headers so long as you do not bump __XEN_INTERFACE_VERSION__
until after you have audited and adjusted for the #ifdef guarded
changes in the header files, then that is exactly what is needed
in blkif.h.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 06:23:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 06:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvNOz-00038t-H1; Thu, 09 Feb 2012 06:22:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvNOy-00038o-Dg
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 06:22:40 +0000
Received: from [85.158.139.83:3660] by server-10.bemta-5.messagelabs.com id
	97/41-26909-F26633F4; Thu, 09 Feb 2012 06:22:39 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328768556!14314598!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20176 invoked from network); 9 Feb 2012 06:22:38 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 06:22:38 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q196MWPU051752
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 8 Feb 2012 23:22:33 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F3236C70200007800071AA1@nat28.tlf.novell.com>
Date: Wed, 8 Feb 2012 23:22:42 -0700
Message-Id: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
	<4F3236C70200007800071AA1@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Wed, 08 Feb 2012 23:22:33 -0700 (MST)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:

>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>> 
>>>> NAK. No backwards incompatible changes allowed in public headers.
>>> 
>>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>>> legacy
>>> source compatibility.  After trying lots of things, testing the impact on an
>>> existing blkfront
>>> and blkback implementation, I think the best two options are:
>>> 
>>> 1. Version the header file and require consumers to declare the interface
>>> version
>>>     they are using.  If the version isn't declared, the default, legacy,
>>> "version 1.0" will
>>>     be in effect.
>>> 
>>>     Positives:   No change in or constant naming conventions.  Data
>>> structures and
>>>                         constants for new features are properly hidden from
>>> legacy implementations.
>>>     Negatives: Messy #ifdefs
>> 
>> We already have this. See use of
>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>> headers.
> 
> Hmm, I would think these should specifically not be used in the
> io/ subtree - those aren't definitions of the interface to Xen, but
> ones shared between the respective backends and frontends.
> Each interface is (apart from its relying on the ring definitions)
> entirely self contained.
> 
> Jan


The versioning required allows a driver to declare, "I am compatible
with any source compatibility breaking changes up to version X of
the header file".  Declaring support for the latest version does
not require that a driver implement the new extensions.  Just one
constant needs to be renamed.  So I don't see this as really altering
the interface between front and backends (i.e. it is not a "blkif2")

If the xen-compat.h behavior is that you can safely import the
public headers so long as you do not bump __XEN_INTERFACE_VERSION__
until after you have audited and adjusted for the #ifdef guarded
changes in the header files, then that is exactly what is needed
in blkif.h.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 06:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 06: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.xensource.com>)
	id 1RvNUp-0003Hd-M6; Thu, 09 Feb 2012 06:28:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvNUn-0003HS-Se
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 06:28:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328768915!10705875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23304 invoked from network); 9 Feb 2012 06:28:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 06:28:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,388,1325462400"; d="scan'208";a="10588538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06:28:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	06:28:35 +0000
Message-ID: <1328768914.13189.70.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 06:28:34 +0000
In-Reply-To: <alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >          }
> > >
> > >          if (strchr(listen, ':') != NULL)
> > > -            flexarray_append(dm_args,
> > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > -                        info->vncunused ? ",to=99" : ""));
> > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > >          else
> > > -            flexarray_append(dm_args,
> > > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > > -                        info->vncunused ? ",to=99" : ""));
> > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > +        }
> > > +        if (info->vncunused) {
> > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> >
> > Not new, but I've been meaning to ask: what is to=99 for here? It seems
> > a bit arbitrary and the default behaviour without it appears to be to
> > keep looking for an available port which sounds like what we want.
> 
> QEMU will search for an open port until it reach the vnc display port 99
> (5999 TCP port).
> 
> For the 99, I probably read this number somewhere. But after checking in
> QEMU code, I do not see any limitation for this number. So we could
> probably change this number for the port number max (-5900, default vnc
> port).

Can we not just omit it altogether and let qemu do its default thing?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 06:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 06: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.xensource.com>)
	id 1RvNUp-0003Hd-M6; Thu, 09 Feb 2012 06:28:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvNUn-0003HS-Se
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 06:28:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328768915!10705875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23304 invoked from network); 9 Feb 2012 06:28:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 06:28:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,388,1325462400"; d="scan'208";a="10588538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06:28:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	06:28:35 +0000
Message-ID: <1328768914.13189.70.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 06:28:34 +0000
In-Reply-To: <alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >          }
> > >
> > >          if (strchr(listen, ':') != NULL)
> > > -            flexarray_append(dm_args,
> > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > -                        info->vncunused ? ",to=99" : ""));
> > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > >          else
> > > -            flexarray_append(dm_args,
> > > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > > -                        info->vncunused ? ",to=99" : ""));
> > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > +        }
> > > +        if (info->vncunused) {
> > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> >
> > Not new, but I've been meaning to ask: what is to=99 for here? It seems
> > a bit arbitrary and the default behaviour without it appears to be to
> > keep looking for an available port which sounds like what we want.
> 
> QEMU will search for an open port until it reach the vnc display port 99
> (5999 TCP port).
> 
> For the 99, I probably read this number somewhere. But after checking in
> QEMU code, I do not see any limitation for this number. So we could
> probably change this number for the port number max (-5900, default vnc
> port).

Can we not just omit it altogether and let qemu do its default thing?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 07:30:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 07:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvOST-0003vZ-Jp; Thu, 09 Feb 2012 07:30:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RvOSQ-0003vU-OJ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 07:30:19 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328772611!12562700!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2224 invoked from network); 9 Feb 2012 07:30:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 07:30:12 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75392511; Thu, 09 Feb 2012 08:30:11 +0100
Message-ID: <1328772608.4351.55.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Thu, 09 Feb 2012 08:30:08 +0100
In-Reply-To: <osstest-11901-mainreport@xen.org>
References: <osstest-11901-mainreport@xen.org>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 11901: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8134411733171835638=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8134411733171835638==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-PWl+rb6O89pJIpWgHHy1"


--=-PWl+rb6O89pJIpWgHHy1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-02-08 at 19:34 +0000, xen.org wrote:=20
> flight 11901 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11901/
>=20
> Failures :-/ but no regressions.
>=20
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2      fail REGR. vs.=
 11896
>
Mmm... Avoiding "all vcpus are guaranteed 75% of a *single* pcpu" in
SEDF made things better, as I haven't seen a boot failure since.

However, both this (pinned) and the other test case, sometimes report
this local migration issue. I wonder if there is something else,
unrelated to the previous problem, maybe specific to migration...

I can't look at it right away, but I'll try to schedule some time for
investigating. Any comments/ideas are welcome. :-)

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)



--=-PWl+rb6O89pJIpWgHHy1
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.11 (GNU/Linux)

iEYEABECAAYFAk8zdgAACgkQk4XaBE3IOsS9wwCfUIPjz5fFwD35AXlDwNf+WPuU
bRQAnjsSlXawJzxUelHkt9SJ6Ud6/93x
=NLTS
-----END PGP SIGNATURE-----

--=-PWl+rb6O89pJIpWgHHy1--



--===============8134411733171835638==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8134411733171835638==--



From xen-devel-bounces@lists.xensource.com Thu Feb 09 07:30:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 07:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvOST-0003vZ-Jp; Thu, 09 Feb 2012 07:30:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RvOSQ-0003vU-OJ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 07:30:19 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328772611!12562700!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2224 invoked from network); 9 Feb 2012 07:30:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 07:30:12 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75392511; Thu, 09 Feb 2012 08:30:11 +0100
Message-ID: <1328772608.4351.55.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Thu, 09 Feb 2012 08:30:08 +0100
In-Reply-To: <osstest-11901-mainreport@xen.org>
References: <osstest-11901-mainreport@xen.org>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 11901: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8134411733171835638=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8134411733171835638==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-PWl+rb6O89pJIpWgHHy1"


--=-PWl+rb6O89pJIpWgHHy1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-02-08 at 19:34 +0000, xen.org wrote:=20
> flight 11901 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11901/
>=20
> Failures :-/ but no regressions.
>=20
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2      fail REGR. vs.=
 11896
>
Mmm... Avoiding "all vcpus are guaranteed 75% of a *single* pcpu" in
SEDF made things better, as I haven't seen a boot failure since.

However, both this (pinned) and the other test case, sometimes report
this local migration issue. I wonder if there is something else,
unrelated to the previous problem, maybe specific to migration...

I can't look at it right away, but I'll try to schedule some time for
investigating. Any comments/ideas are welcome. :-)

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)



--=-PWl+rb6O89pJIpWgHHy1
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.11 (GNU/Linux)

iEYEABECAAYFAk8zdgAACgkQk4XaBE3IOsS9wwCfUIPjz5fFwD35AXlDwNf+WPuU
bRQAnjsSlXawJzxUelHkt9SJ6Ud6/93x
=NLTS
-----END PGP SIGNATURE-----

--=-PWl+rb6O89pJIpWgHHy1--



--===============8134411733171835638==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8134411733171835638==--



From xen-devel-bounces@lists.xensource.com Thu Feb 09 07:31:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 07: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.xensource.com>)
	id 1RvOTP-0003xv-BQ; Thu, 09 Feb 2012 07:31:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvOTM-0003xR-Co
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 07:31:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328772669!10736878!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzA1NTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzA1NTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 9 Feb 2012 07:31:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 07:31:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328772669; l=1638;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=w8ZtOwbDth/1l/d9sSzIqKxzBzg=;
	b=VGjonNEWwR72Tghbdfcg6X2vwMFBidJpd0dFqXZpsCyDf7R8hG6uE9ZwwrHmOlqFBpx
	7PnroOs/HYISWslMiVCvO8Fx2usoYU2JZxrRUjyMykX+RyP23YMp3s/4DyEcj7SI19sQa
	YynerEvttYCfdNbwKQC72bXIC50MOKO5wNA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (fruni mo58) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p056aeo195GHIC ;
	Thu, 9 Feb 2012 08:30:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 59F6418637; Thu,  9 Feb 2012 08:30:59 +0100 (CET)
Date: Thu, 9 Feb 2012 08:30:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120209073059.GA20712@aepfle.de>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 9 of 9] xl: use json output by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, Ian Campbell wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1327512175 0
> # Node ID 9e3be181b2b70f521defcd55ecbd9967cd206fb2
> # Parent  f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
> xl: use json output by default
> 
> Move the sxp producing code off into a separate file. It is supported
> for legacy reasons and needn't be updated other than the improve
> compatibility with xm.
> 
> libxl_domain_config is not currently generated by the IDL (adding the
> necessary support for Array types is on my to do list) so hand code
> the json generation function for now.
> 
> Since this rather directly exposes a libxl data structure it's not
> clear what sort of forward compatibility guarantees we can
> make. However it seems like it should be as stable as libxl's own API
> (which we are looking to stabilise)

This leads to build failures with libyajl2:

xl_cmdimpl.c: In function 'printf_info':
xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=unused-value]
xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this function)
xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only once for each function it appears in
xl_cmdimpl.c:306:5: error: too many arguments to function 'yajl_gen_alloc'
/usr/include/yajl/yajl_gen.h:118:23: note: declared here
xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf' from incompatible pointer type [-Werror]
/usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but argument is of type 'unsigned int *'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 07:31:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 07: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.xensource.com>)
	id 1RvOTP-0003xv-BQ; Thu, 09 Feb 2012 07:31:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvOTM-0003xR-Co
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 07:31:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328772669!10736878!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzA1NTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzA1NTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 9 Feb 2012 07:31:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 07:31:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328772669; l=1638;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=w8ZtOwbDth/1l/d9sSzIqKxzBzg=;
	b=VGjonNEWwR72Tghbdfcg6X2vwMFBidJpd0dFqXZpsCyDf7R8hG6uE9ZwwrHmOlqFBpx
	7PnroOs/HYISWslMiVCvO8Fx2usoYU2JZxrRUjyMykX+RyP23YMp3s/4DyEcj7SI19sQa
	YynerEvttYCfdNbwKQC72bXIC50MOKO5wNA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (fruni mo58) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p056aeo195GHIC ;
	Thu, 9 Feb 2012 08:30:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 59F6418637; Thu,  9 Feb 2012 08:30:59 +0100 (CET)
Date: Thu, 9 Feb 2012 08:30:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120209073059.GA20712@aepfle.de>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 9 of 9] xl: use json output by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, Ian Campbell wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1327512175 0
> # Node ID 9e3be181b2b70f521defcd55ecbd9967cd206fb2
> # Parent  f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
> xl: use json output by default
> 
> Move the sxp producing code off into a separate file. It is supported
> for legacy reasons and needn't be updated other than the improve
> compatibility with xm.
> 
> libxl_domain_config is not currently generated by the IDL (adding the
> necessary support for Array types is on my to do list) so hand code
> the json generation function for now.
> 
> Since this rather directly exposes a libxl data structure it's not
> clear what sort of forward compatibility guarantees we can
> make. However it seems like it should be as stable as libxl's own API
> (which we are looking to stabilise)

This leads to build failures with libyajl2:

xl_cmdimpl.c: In function 'printf_info':
xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=unused-value]
xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this function)
xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only once for each function it appears in
xl_cmdimpl.c:306:5: error: too many arguments to function 'yajl_gen_alloc'
/usr/include/yajl/yajl_gen.h:118:23: note: declared here
xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf' from incompatible pointer type [-Werror]
/usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but argument is of type 'unsigned int *'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 07:43:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 07:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvOec-0004GQ-BI; Thu, 09 Feb 2012 07:42:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvOea-0004GI-PG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 07:42:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328773365!12615897!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15365 invoked from network); 9 Feb 2012 07:42:46 -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; 9 Feb 2012 07:42:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvOeQ-00026u-Um; Thu, 09 Feb 2012 07:42:42 +0000
Date: Thu, 9 Feb 2012 07:42:42 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120209074242.GC71900@ocelot.phlegethon.org>
References: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
	shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:01 -0500 on 09 Feb (1328749297), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  4 +++-
>  xen/arch/x86/mm/p2m.c         |  6 ++++--
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

NACK, I'm afraid, especially the second one.  '<=' comparisons with a
number that's made up of a count ORed with a type don't make sense.
If you want to test both type and count, just test them separately.

Cheers,

Tim.

> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -200,7 +200,9 @@ static struct page_info* mem_sharing_loo
>              /* Count has to be at least two, because we're called
>               * with the mfn locked (1) and this is supposed to be 
>               * a shared page (1). */
> -            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2); 
> +            ASSERT((page->u.inuse.type_info & 
> +                        (PGT_shared_page | PGT_count_mask)) >= 
> +                            (PGT_shared_page | 2)); 
>              ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
>              return page;
>          }
> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -745,8 +745,10 @@ set_shared_p2m_entry(struct domain *d, u
>       * sharable first */
>      ASSERT(p2m_is_shared(ot));
>      ASSERT(mfn_valid(omfn));
> -    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
> -                    != PGT_shared_page) )
> +    /* Set the m2p entry to invalid only if there are no further type
> +     * refs to this page as shared */
> +    if ( (mfn_to_page(omfn)->u.inuse.type_info & 
> +            (PGT_shared_page | PGT_count_mask)) <= PGT_shared_page )
>          set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
>  
>      P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 07:43:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 07:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvOec-0004GQ-BI; Thu, 09 Feb 2012 07:42:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvOea-0004GI-PG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 07:42:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328773365!12615897!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15365 invoked from network); 9 Feb 2012 07:42:46 -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; 9 Feb 2012 07:42:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvOeQ-00026u-Um; Thu, 09 Feb 2012 07:42:42 +0000
Date: Thu, 9 Feb 2012 07:42:42 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120209074242.GC71900@ocelot.phlegethon.org>
References: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
	shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:01 -0500 on 09 Feb (1328749297), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  4 +++-
>  xen/arch/x86/mm/p2m.c         |  6 ++++--
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

NACK, I'm afraid, especially the second one.  '<=' comparisons with a
number that's made up of a count ORed with a type don't make sense.
If you want to test both type and count, just test them separately.

Cheers,

Tim.

> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -200,7 +200,9 @@ static struct page_info* mem_sharing_loo
>              /* Count has to be at least two, because we're called
>               * with the mfn locked (1) and this is supposed to be 
>               * a shared page (1). */
> -            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2); 
> +            ASSERT((page->u.inuse.type_info & 
> +                        (PGT_shared_page | PGT_count_mask)) >= 
> +                            (PGT_shared_page | 2)); 
>              ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
>              return page;
>          }
> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -745,8 +745,10 @@ set_shared_p2m_entry(struct domain *d, u
>       * sharable first */
>      ASSERT(p2m_is_shared(ot));
>      ASSERT(mfn_valid(omfn));
> -    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
> -                    != PGT_shared_page) )
> +    /* Set the m2p entry to invalid only if there are no further type
> +     * refs to this page as shared */
> +    if ( (mfn_to_page(omfn)->u.inuse.type_info & 
> +            (PGT_shared_page | PGT_count_mask)) <= PGT_shared_page )
>          set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
>  
>      P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:49:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvPfx-0005YL-2f; Thu, 09 Feb 2012 08:48:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPfw-0005YG-7C
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:48:20 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328777275!52174972!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 9 Feb 2012 08:47:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 08:47:55 -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 q198mHFV005523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:48:17 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198mHal028937; Thu, 9 Feb 2012 03:48:17 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 9E6EE133EEF; Thu,  9 Feb 2012 10:48:16 +0200 (IST)
Date: Thu, 9 Feb 2012 10:48:16 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209084816.GB18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-2-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
> This patch adds some infrastructure to handle suspend and resume to
> qemu.  First there are two functions to switch state and second there
> is a suspend notifier:
> 
>  * qemu_system_suspend_request() is supposed to be called when the
>    guest asks for being be suspended, for example via ACPI.
> 
>  * qemu_system_wakeup_request is supposed to be called on events which
>    should wake up the guest.
> 
qemu_system_wakeup_request() should get wakeup source as a parameter.
There are ways to report it to a guest.

>  * qemu_register_suspend_notifier can be used to register a notifier
>    which will be called when the guest is suspended.  Machine types
>    and device models can hook in there to modify state if needed.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  sysemu.h |    3 +++
>  vl.c     |   28 ++++++++++++++++++++++++++++
>  2 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/sysemu.h b/sysemu.h
> index 9d5ce33..3b9d7f5 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -39,6 +39,9 @@ void vm_stop(RunState state);
>  void vm_stop_force_state(RunState state);
>  
>  void qemu_system_reset_request(void);
> +void qemu_system_suspend_request(void);
> +void qemu_register_suspend_notifier(Notifier *notifier);
> +void qemu_system_wakeup_request(void);
>  void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
>  void qemu_system_debug_request(void);
> diff --git a/vl.c b/vl.c
> index 63dd725..822fd58 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1283,6 +1283,9 @@ static int shutdown_requested, shutdown_signal = -1;
>  static pid_t shutdown_pid;
>  static int powerdown_requested;
>  static int debug_requested;
> +static bool is_suspended;
> +static NotifierList suspend_notifiers =
> +    NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  
>  int qemu_shutdown_requested_get(void)
> @@ -1398,6 +1401,31 @@ void qemu_system_reset_request(void)
>      qemu_notify_event();
>  }
>  
> +void qemu_system_suspend_request(void)
> +{
> +    if (is_suspended) {
> +        return;
> +    }
> +    cpu_stop_current();
> +    notifier_list_notify(&suspend_notifiers, NULL);
> +    is_suspended = true;
> +}
> +
> +void qemu_register_suspend_notifier(Notifier *notifier)
> +{
> +    notifier_list_add(&suspend_notifiers, notifier);
> +}
> +
> +void qemu_system_wakeup_request(void)
> +{
> +    if (!is_suspended) {
> +        return;
> +    }
> +    reset_requested = 1;
> +    qemu_notify_event();
> +    is_suspended = false;
> +}
> +
>  void qemu_system_killed(int signal, pid_t pid)
>  {
>      shutdown_signal = signal;
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:49:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvPfx-0005YL-2f; Thu, 09 Feb 2012 08:48:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPfw-0005YG-7C
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:48:20 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328777275!52174972!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 9 Feb 2012 08:47:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 08:47:55 -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 q198mHFV005523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:48:17 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198mHal028937; Thu, 9 Feb 2012 03:48:17 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 9E6EE133EEF; Thu,  9 Feb 2012 10:48:16 +0200 (IST)
Date: Thu, 9 Feb 2012 10:48:16 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209084816.GB18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-2-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
> This patch adds some infrastructure to handle suspend and resume to
> qemu.  First there are two functions to switch state and second there
> is a suspend notifier:
> 
>  * qemu_system_suspend_request() is supposed to be called when the
>    guest asks for being be suspended, for example via ACPI.
> 
>  * qemu_system_wakeup_request is supposed to be called on events which
>    should wake up the guest.
> 
qemu_system_wakeup_request() should get wakeup source as a parameter.
There are ways to report it to a guest.

>  * qemu_register_suspend_notifier can be used to register a notifier
>    which will be called when the guest is suspended.  Machine types
>    and device models can hook in there to modify state if needed.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  sysemu.h |    3 +++
>  vl.c     |   28 ++++++++++++++++++++++++++++
>  2 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/sysemu.h b/sysemu.h
> index 9d5ce33..3b9d7f5 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -39,6 +39,9 @@ void vm_stop(RunState state);
>  void vm_stop_force_state(RunState state);
>  
>  void qemu_system_reset_request(void);
> +void qemu_system_suspend_request(void);
> +void qemu_register_suspend_notifier(Notifier *notifier);
> +void qemu_system_wakeup_request(void);
>  void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
>  void qemu_system_debug_request(void);
> diff --git a/vl.c b/vl.c
> index 63dd725..822fd58 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1283,6 +1283,9 @@ static int shutdown_requested, shutdown_signal = -1;
>  static pid_t shutdown_pid;
>  static int powerdown_requested;
>  static int debug_requested;
> +static bool is_suspended;
> +static NotifierList suspend_notifiers =
> +    NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  
>  int qemu_shutdown_requested_get(void)
> @@ -1398,6 +1401,31 @@ void qemu_system_reset_request(void)
>      qemu_notify_event();
>  }
>  
> +void qemu_system_suspend_request(void)
> +{
> +    if (is_suspended) {
> +        return;
> +    }
> +    cpu_stop_current();
> +    notifier_list_notify(&suspend_notifiers, NULL);
> +    is_suspended = true;
> +}
> +
> +void qemu_register_suspend_notifier(Notifier *notifier)
> +{
> +    notifier_list_add(&suspend_notifiers, notifier);
> +}
> +
> +void qemu_system_wakeup_request(void)
> +{
> +    if (!is_suspended) {
> +        return;
> +    }
> +    reset_requested = 1;
> +    qemu_notify_event();
> +    is_suspended = false;
> +}
> +
>  void qemu_system_killed(int signal, pid_t pid)
>  {
>      shutdown_signal = signal;
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:54:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPlL-0005hx-VQ; Thu, 09 Feb 2012 08:53:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPlJ-0005hl-Tn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:53:54 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328777626!12645505!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31956 invoked from network); 9 Feb 2012 08:53:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 08:53:46 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q198riOO017728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:53:45 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198rhH4004720; Thu, 9 Feb 2012 03:53:44 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 2D2EC133EEF; Thu,  9 Feb 2012 10:53:43 +0200 (IST)
Date: Thu, 9 Feb 2012 10:53:43 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209085343.GC18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:15PM +0100, Gerd Hoffmann wrote:
> This patch switches pc s3 suspend over to the new infrastructure.
> The cmos_s3 qemu_irq is killed, the new notifier is used instead.
> The xen hack goes away with that too, the hypercall can simply be
> done in a notifier function now.
> 
> This patch also makes the guest actually stay suspended instead
> of leaving suspend instantly, so it is useful for more than just
> testing whenever the suspend/resume cycle actually works.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/acpi.c        |   11 +----------
>  hw/acpi.h        |    2 --
>  hw/acpi_piix4.c  |    3 +--
>  hw/mc146818rtc.c |   12 ++++++++++++
>  hw/mips_malta.c  |    2 +-
>  hw/pc.c          |   11 -----------
>  hw/pc.h          |    3 +--
>  hw/pc_piix.c     |    8 +-------
>  hw/vt82c686.c    |    1 -
>  xen-all.c        |   11 ++++++-----
>  10 files changed, 23 insertions(+), 41 deletions(-)
> 
> diff --git a/hw/acpi.c b/hw/acpi.c
> index 79b179b..67dcd43 100644
> --- a/hw/acpi.c
> +++ b/hw/acpi.c
> @@ -330,11 +330,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
>  }
>  
>  /* ACPI PM1aCNT */
> -void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
> -{
> -    pm1_cnt->cmos_s3 = cmos_s3;
> -}
> -
>  void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
>  {
>      pm1_cnt->cnt = val & ~(ACPI_BITMASK_SLEEP_ENABLE);
> @@ -351,8 +346,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
>                 Pretend that resume was caused by power button */
>              pm1a->sts |=
>                  (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
Here we should report real reason for a wakeup (if it can be reported in
mp1sts that is).

> -            qemu_system_reset_request();
> -            qemu_irq_raise(pm1_cnt->cmos_s3);
> +            qemu_system_suspend_request();
>          default:
>              break;
>          }
> @@ -373,9 +367,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
>  void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
>  {
>      pm1_cnt->cnt = 0;
> -    if (pm1_cnt->cmos_s3) {
> -        qemu_irq_lower(pm1_cnt->cmos_s3);
> -    }
>  }
>  
>  /* ACPI GPE */
> diff --git a/hw/acpi.h b/hw/acpi.h
> index c141e65..e0c7dbe 100644
> --- a/hw/acpi.h
> +++ b/hw/acpi.h
> @@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
>  /* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
>  struct ACPIPM1CNT {
>      uint16_t cnt;
> -
> -    qemu_irq cmos_s3;
>  };
>  typedef struct ACPIPM1CNT ACPIPM1CNT;
>  
> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> index 21484ae..bc77dc5 100644
> --- a/hw/acpi_piix4.c
> +++ b/hw/acpi_piix4.c
> @@ -376,7 +376,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
>  }
>  
>  i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> -                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
> +                       qemu_irq sci_irq, qemu_irq smi_irq,
>                         int kvm_enabled)
>  {
>      PCIDevice *dev;
> @@ -387,7 +387,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
>  
>      s = DO_UPCAST(PIIX4PMState, dev, dev);
>      s->irq = sci_irq;
> -    acpi_pm1_cnt_init(&s->pm1_cnt, cmos_s3);
>      s->smi_irq = smi_irq;
>      s->kvm_enabled = kvm_enabled;
>  
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 4a43225..314ed52 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -102,6 +102,7 @@ typedef struct RTCState {
>      QEMUTimer *second_timer2;
>      Notifier clock_reset_notifier;
>      LostTickPolicy lost_tick_policy;
> +    Notifier suspend_notifier;
>  } RTCState;
>  
>  static void rtc_set_time(RTCState *s);
> @@ -596,6 +597,14 @@ static void rtc_notify_clock_reset(Notifier *notifier, void *data)
>  #endif
>  }
>  
> +/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> +   BIOS will read it and start S3 resume at POST Entry */
> +static void rtc_notify_suspend(Notifier *notifier, void *data)
> +{
> +    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
> +    rtc_set_memory(&s->dev, 0xF, 0xFE);
> +}
> +
>  static void rtc_reset(void *opaque)
>  {
>      RTCState *s = opaque;
> @@ -676,6 +685,9 @@ static int rtc_initfn(ISADevice *dev)
>      s->clock_reset_notifier.notify = rtc_notify_clock_reset;
>      qemu_register_clock_reset_notifier(rtc_clock, &s->clock_reset_notifier);
>  
> +    s->suspend_notifier.notify = rtc_notify_suspend;
> +    qemu_register_suspend_notifier(&s->suspend_notifier);
> +
>      s->next_second_time =
>          qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
>      qemu_mod_timer(s->second_timer2, s->next_second_time);
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index d232630..fe02c93 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
>      pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
>      usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
>      smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
> -                          isa_get_irq(NULL, 9), NULL, NULL, 0);
> +                          isa_get_irq(NULL, 9), NULL, 0);
>      /* TODO: Populate SPD eeprom data.  */
>      smbus_eeprom_init(smbus, 8, NULL, 0);
>      pit = pit_init(isa_bus, 0x40, 0);
> diff --git a/hw/pc.c b/hw/pc.c
> index 7f3aa65..7b93aee 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -915,17 +915,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>      return dev;
>  }
>  
> -/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> -   BIOS will read it and start S3 resume at POST Entry */
> -void pc_cmos_set_s3_resume(void *opaque, int irq, int level)
> -{
> -    ISADevice *s = opaque;
> -
> -    if (level) {
> -        rtc_set_memory(s, 0xF, 0xFE);
> -    }
> -}
> -
>  void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
>  {
>      CPUState *s = opaque;
> diff --git a/hw/pc.h b/hw/pc.h
> index c666ec9..571c915 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -128,7 +128,6 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
>  extern int fd_bootchk;
>  
>  void pc_register_ferr_irq(qemu_irq irq);
> -void pc_cmos_set_s3_resume(void *opaque, int irq, int level);
>  void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
>  
>  void pc_cpus_init(const char *cpu_model);
> @@ -167,7 +166,7 @@ int acpi_table_add(const char *table_desc);
>  /* acpi_piix.c */
>  
>  i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> -                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
> +                       qemu_irq sci_irq, qemu_irq smi_irq,
>                         int kvm_enabled);
>  void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index c06f1b5..918f5ac 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -139,7 +139,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      qemu_irq *cpu_irq;
>      qemu_irq *gsi;
>      qemu_irq *i8259;
> -    qemu_irq *cmos_s3;
>      qemu_irq *smi_irq;
>      GSIState *gsi_state;
>      DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> @@ -291,15 +290,10 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled && acpi_enabled) {
>          i2c_bus *smbus;
>  
> -        if (!xen_enabled()) {
> -            cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
> -        } else {
> -            cmos_s3 = qemu_allocate_irqs(xen_cmos_set_s3_resume, rtc_state, 1);
> -        }
>          smi_irq = qemu_allocate_irqs(pc_acpi_smi_interrupt, first_cpu, 1);
>          /* TODO: Populate SPD eeprom data.  */
>          smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
> -                              gsi[9], *cmos_s3, *smi_irq,
> +                              gsi[9], *smi_irq,
>                                kvm_enabled());
>          smbus_eeprom_init(smbus, 8, NULL, 0);
>      }
> diff --git a/hw/vt82c686.c b/hw/vt82c686.c
> index aa0954f..8beb6c5 100644
> --- a/hw/vt82c686.c
> +++ b/hw/vt82c686.c
> @@ -446,7 +446,6 @@ static int vt82c686b_pm_initfn(PCIDevice *dev)
>      apm_init(&s->apm, NULL, s);
>  
>      acpi_pm_tmr_init(&s->tmr, pm_tmr_timer);
> -    acpi_pm1_cnt_init(&s->pm1_cnt, NULL);
>  
>      pm_smbus_init(&s->dev.qdev, &s->smb);
>  
> diff --git a/xen-all.c b/xen-all.c
> index fd39168..b0ed1ed 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -89,6 +89,7 @@ typedef struct XenIOState {
>      const XenPhysmap *log_for_dirtybit;
>  
>      Notifier exit;
> +    Notifier suspend;
>  } XenIOState;
>  
>  /* Xen specific function for piix pci */
> @@ -121,12 +122,9 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
>      }
>  }
>  
> -void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
> +static void xen_suspend_notifier(Notifier *notifier, void *data)
>  {
> -    pc_cmos_set_s3_resume(opaque, irq, level);
> -    if (level) {
> -        xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
> -    }
> +    xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
>  }
>  
>  /* Xen Interrupt Controller */
> @@ -936,6 +934,9 @@ int xen_hvm_init(void)
>      state->exit.notify = xen_exit_notifier;
>      qemu_add_exit_notifier(&state->exit);
>  
> +    state->suspend.notify = xen_suspend_notifier;
> +    qemu_register_suspend_notifier(&state->suspend);
> +
>      xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
>      DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
>      state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:54:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPlL-0005hx-VQ; Thu, 09 Feb 2012 08:53:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPlJ-0005hl-Tn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:53:54 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328777626!12645505!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31956 invoked from network); 9 Feb 2012 08:53:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 08:53:46 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q198riOO017728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:53:45 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198rhH4004720; Thu, 9 Feb 2012 03:53:44 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 2D2EC133EEF; Thu,  9 Feb 2012 10:53:43 +0200 (IST)
Date: Thu, 9 Feb 2012 10:53:43 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209085343.GC18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:15PM +0100, Gerd Hoffmann wrote:
> This patch switches pc s3 suspend over to the new infrastructure.
> The cmos_s3 qemu_irq is killed, the new notifier is used instead.
> The xen hack goes away with that too, the hypercall can simply be
> done in a notifier function now.
> 
> This patch also makes the guest actually stay suspended instead
> of leaving suspend instantly, so it is useful for more than just
> testing whenever the suspend/resume cycle actually works.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/acpi.c        |   11 +----------
>  hw/acpi.h        |    2 --
>  hw/acpi_piix4.c  |    3 +--
>  hw/mc146818rtc.c |   12 ++++++++++++
>  hw/mips_malta.c  |    2 +-
>  hw/pc.c          |   11 -----------
>  hw/pc.h          |    3 +--
>  hw/pc_piix.c     |    8 +-------
>  hw/vt82c686.c    |    1 -
>  xen-all.c        |   11 ++++++-----
>  10 files changed, 23 insertions(+), 41 deletions(-)
> 
> diff --git a/hw/acpi.c b/hw/acpi.c
> index 79b179b..67dcd43 100644
> --- a/hw/acpi.c
> +++ b/hw/acpi.c
> @@ -330,11 +330,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
>  }
>  
>  /* ACPI PM1aCNT */
> -void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
> -{
> -    pm1_cnt->cmos_s3 = cmos_s3;
> -}
> -
>  void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
>  {
>      pm1_cnt->cnt = val & ~(ACPI_BITMASK_SLEEP_ENABLE);
> @@ -351,8 +346,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
>                 Pretend that resume was caused by power button */
>              pm1a->sts |=
>                  (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
Here we should report real reason for a wakeup (if it can be reported in
mp1sts that is).

> -            qemu_system_reset_request();
> -            qemu_irq_raise(pm1_cnt->cmos_s3);
> +            qemu_system_suspend_request();
>          default:
>              break;
>          }
> @@ -373,9 +367,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
>  void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
>  {
>      pm1_cnt->cnt = 0;
> -    if (pm1_cnt->cmos_s3) {
> -        qemu_irq_lower(pm1_cnt->cmos_s3);
> -    }
>  }
>  
>  /* ACPI GPE */
> diff --git a/hw/acpi.h b/hw/acpi.h
> index c141e65..e0c7dbe 100644
> --- a/hw/acpi.h
> +++ b/hw/acpi.h
> @@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
>  /* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
>  struct ACPIPM1CNT {
>      uint16_t cnt;
> -
> -    qemu_irq cmos_s3;
>  };
>  typedef struct ACPIPM1CNT ACPIPM1CNT;
>  
> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> index 21484ae..bc77dc5 100644
> --- a/hw/acpi_piix4.c
> +++ b/hw/acpi_piix4.c
> @@ -376,7 +376,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
>  }
>  
>  i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> -                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
> +                       qemu_irq sci_irq, qemu_irq smi_irq,
>                         int kvm_enabled)
>  {
>      PCIDevice *dev;
> @@ -387,7 +387,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
>  
>      s = DO_UPCAST(PIIX4PMState, dev, dev);
>      s->irq = sci_irq;
> -    acpi_pm1_cnt_init(&s->pm1_cnt, cmos_s3);
>      s->smi_irq = smi_irq;
>      s->kvm_enabled = kvm_enabled;
>  
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 4a43225..314ed52 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -102,6 +102,7 @@ typedef struct RTCState {
>      QEMUTimer *second_timer2;
>      Notifier clock_reset_notifier;
>      LostTickPolicy lost_tick_policy;
> +    Notifier suspend_notifier;
>  } RTCState;
>  
>  static void rtc_set_time(RTCState *s);
> @@ -596,6 +597,14 @@ static void rtc_notify_clock_reset(Notifier *notifier, void *data)
>  #endif
>  }
>  
> +/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> +   BIOS will read it and start S3 resume at POST Entry */
> +static void rtc_notify_suspend(Notifier *notifier, void *data)
> +{
> +    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
> +    rtc_set_memory(&s->dev, 0xF, 0xFE);
> +}
> +
>  static void rtc_reset(void *opaque)
>  {
>      RTCState *s = opaque;
> @@ -676,6 +685,9 @@ static int rtc_initfn(ISADevice *dev)
>      s->clock_reset_notifier.notify = rtc_notify_clock_reset;
>      qemu_register_clock_reset_notifier(rtc_clock, &s->clock_reset_notifier);
>  
> +    s->suspend_notifier.notify = rtc_notify_suspend;
> +    qemu_register_suspend_notifier(&s->suspend_notifier);
> +
>      s->next_second_time =
>          qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
>      qemu_mod_timer(s->second_timer2, s->next_second_time);
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index d232630..fe02c93 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
>      pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
>      usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
>      smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
> -                          isa_get_irq(NULL, 9), NULL, NULL, 0);
> +                          isa_get_irq(NULL, 9), NULL, 0);
>      /* TODO: Populate SPD eeprom data.  */
>      smbus_eeprom_init(smbus, 8, NULL, 0);
>      pit = pit_init(isa_bus, 0x40, 0);
> diff --git a/hw/pc.c b/hw/pc.c
> index 7f3aa65..7b93aee 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -915,17 +915,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
>      return dev;
>  }
>  
> -/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> -   BIOS will read it and start S3 resume at POST Entry */
> -void pc_cmos_set_s3_resume(void *opaque, int irq, int level)
> -{
> -    ISADevice *s = opaque;
> -
> -    if (level) {
> -        rtc_set_memory(s, 0xF, 0xFE);
> -    }
> -}
> -
>  void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
>  {
>      CPUState *s = opaque;
> diff --git a/hw/pc.h b/hw/pc.h
> index c666ec9..571c915 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -128,7 +128,6 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
>  extern int fd_bootchk;
>  
>  void pc_register_ferr_irq(qemu_irq irq);
> -void pc_cmos_set_s3_resume(void *opaque, int irq, int level);
>  void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
>  
>  void pc_cpus_init(const char *cpu_model);
> @@ -167,7 +166,7 @@ int acpi_table_add(const char *table_desc);
>  /* acpi_piix.c */
>  
>  i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
> -                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
> +                       qemu_irq sci_irq, qemu_irq smi_irq,
>                         int kvm_enabled);
>  void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index c06f1b5..918f5ac 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -139,7 +139,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      qemu_irq *cpu_irq;
>      qemu_irq *gsi;
>      qemu_irq *i8259;
> -    qemu_irq *cmos_s3;
>      qemu_irq *smi_irq;
>      GSIState *gsi_state;
>      DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> @@ -291,15 +290,10 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled && acpi_enabled) {
>          i2c_bus *smbus;
>  
> -        if (!xen_enabled()) {
> -            cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
> -        } else {
> -            cmos_s3 = qemu_allocate_irqs(xen_cmos_set_s3_resume, rtc_state, 1);
> -        }
>          smi_irq = qemu_allocate_irqs(pc_acpi_smi_interrupt, first_cpu, 1);
>          /* TODO: Populate SPD eeprom data.  */
>          smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
> -                              gsi[9], *cmos_s3, *smi_irq,
> +                              gsi[9], *smi_irq,
>                                kvm_enabled());
>          smbus_eeprom_init(smbus, 8, NULL, 0);
>      }
> diff --git a/hw/vt82c686.c b/hw/vt82c686.c
> index aa0954f..8beb6c5 100644
> --- a/hw/vt82c686.c
> +++ b/hw/vt82c686.c
> @@ -446,7 +446,6 @@ static int vt82c686b_pm_initfn(PCIDevice *dev)
>      apm_init(&s->apm, NULL, s);
>  
>      acpi_pm_tmr_init(&s->tmr, pm_tmr_timer);
> -    acpi_pm1_cnt_init(&s->pm1_cnt, NULL);
>  
>      pm_smbus_init(&s->dev.qdev, &s->smb);
>  
> diff --git a/xen-all.c b/xen-all.c
> index fd39168..b0ed1ed 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -89,6 +89,7 @@ typedef struct XenIOState {
>      const XenPhysmap *log_for_dirtybit;
>  
>      Notifier exit;
> +    Notifier suspend;
>  } XenIOState;
>  
>  /* Xen specific function for piix pci */
> @@ -121,12 +122,9 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
>      }
>  }
>  
> -void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
> +static void xen_suspend_notifier(Notifier *notifier, void *data)
>  {
> -    pc_cmos_set_s3_resume(opaque, irq, level);
> -    if (level) {
> -        xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
> -    }
> +    xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
>  }
>  
>  /* Xen Interrupt Controller */
> @@ -936,6 +934,9 @@ int xen_hvm_init(void)
>      state->exit.notify = xen_exit_notifier;
>      qemu_add_exit_notifier(&state->exit);
>  
> +    state->suspend.notify = xen_suspend_notifier;
> +    qemu_register_suspend_notifier(&state->suspend);
> +
>      xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
>      DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
>      state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:54:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08: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.xensource.com>)
	id 1RvPll-0005jI-Je; Thu, 09 Feb 2012 08:54:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RvPlk-0005jC-Ca
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:54:20 +0000
Received: from [85.158.139.83:51747] by server-10.bemta-5.messagelabs.com id
	99/F2-26909-BB9833F4; Thu, 09 Feb 2012 08:54:19 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328777657!14332973!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMTcxNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17846 invoked from network); 9 Feb 2012 08:54:18 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-3.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 08:54:18 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ4002NKBEGJI@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:54:16 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ40004CBDR7E@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:54:16 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGT04874; Thu,
	09 Feb 2012 16:54:15 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:54:09 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml409-hub.china.huawei.com (10.82.67.136) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:53:57 +0800
Date: Thu, 09 Feb 2012 16:53:54 +0800
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.9+10-e9264b45237d
X-Mercurial-Node: 9f4640e40d4f31563885427a5a8d9eae2e110514
X-CFilter-Loop: Reflected
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free
	port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8265311217137370442=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8265311217137370442==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1328777452 -28800
# Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
xenpaging:close domU's event channel and free port

Every domain (X86 64 bit)has 4096 event channels.In source code,
domU's event channel is allocated in mem_event_enable(),but just
unbind dom0's event channel in xenpaging_teardown().This bug will
result in that we can not use xenpaging after reopening it for 4096
times.We should free domU's event channel in mem_event_disable().so
that we can reuse the port.

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
@@ -241,7 +241,12 @@
             mem_event_ring_unlock(med);
             return -EBUSY;
         }
-
+        
+        if( med->shared_page!=NULL )
+        {
+            free_xen_event_channel(d->vcpu[0], (med->shared_page)->port);
+        }
+             
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 


--===============8265311217137370442==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8265311217137370442==--

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:54:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08: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.xensource.com>)
	id 1RvPll-0005jI-Je; Thu, 09 Feb 2012 08:54:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RvPlk-0005jC-Ca
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:54:20 +0000
Received: from [85.158.139.83:51747] by server-10.bemta-5.messagelabs.com id
	99/F2-26909-BB9833F4; Thu, 09 Feb 2012 08:54:19 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328777657!14332973!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMTcxNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17846 invoked from network); 9 Feb 2012 08:54:18 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-3.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 08:54:18 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ4002NKBEGJI@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:54:16 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ40004CBDR7E@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:54:16 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGT04874; Thu,
	09 Feb 2012 16:54:15 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:54:09 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml409-hub.china.huawei.com (10.82.67.136) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:53:57 +0800
Date: Thu, 09 Feb 2012 16:53:54 +0800
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.9+10-e9264b45237d
X-Mercurial-Node: 9f4640e40d4f31563885427a5a8d9eae2e110514
X-CFilter-Loop: Reflected
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free
	port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8265311217137370442=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8265311217137370442==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1328777452 -28800
# Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
xenpaging:close domU's event channel and free port

Every domain (X86 64 bit)has 4096 event channels.In source code,
domU's event channel is allocated in mem_event_enable(),but just
unbind dom0's event channel in xenpaging_teardown().This bug will
result in that we can not use xenpaging after reopening it for 4096
times.We should free domU's event channel in mem_event_disable().so
that we can reuse the port.

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
@@ -241,7 +241,12 @@
             mem_event_ring_unlock(med);
             return -EBUSY;
         }
-
+        
+        if( med->shared_page!=NULL )
+        {
+            free_xen_event_channel(d->vcpu[0], (med->shared_page)->port);
+        }
+             
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 


--===============8265311217137370442==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8265311217137370442==--

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:54:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08: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.xensource.com>)
	id 1RvPlu-0005kT-0S; Thu, 09 Feb 2012 08:54:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPls-0005jP-3k
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:54:28 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328777661!14122598!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5653 invoked from network); 9 Feb 2012 08:54:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 08:54:21 -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 q198sKtu031601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:54:20 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198sJMk030324; Thu, 9 Feb 2012 03:54:20 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 552D8133EEF; Thu,  9 Feb 2012 10:54:19 +0200 (IST)
Date: Thu, 9 Feb 2012 10:54:19 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209085419.GD18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-4-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-4-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 3/6] suspend: add
 system_wakeup monitor command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:16PM +0100, Gerd Hoffmann wrote:
> This patch adds the system_wakeup monitor command which will simply
> wake up suspended guests.
> 
We can report this one as power button wakeup.

> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hmp-commands.hx  |   14 ++++++++++++++
>  hmp.c            |    5 +++++
>  hmp.h            |    1 +
>  qapi-schema.json |   11 +++++++++++
>  qmp-commands.hx  |   21 +++++++++++++++++++++
>  qmp.c            |    5 +++++
>  6 files changed, 57 insertions(+), 0 deletions(-)
> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 573b823..64b3656 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -352,6 +352,20 @@ Resume emulation.
>  ETEXI
>  
>      {
> +        .name       = "system_wakeup",
> +        .args_type  = "",
> +        .params     = "",
> +        .help       = "wakeup guest from suspend",
> +        .mhandler.cmd = hmp_system_wakeup,
> +    },
> +
> +STEXI
> +@item system_wakeup
> +@findex system_wakeup
> +Wakeup guest from suspend.
> +ETEXI
> +
> +    {
>          .name       = "gdbserver",
>          .args_type  = "device:s?",
>          .params     = "[device]",
> diff --git a/hmp.c b/hmp.c
> index 8ff8c94..3a54455 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -632,6 +632,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
>      }
>  }
>  
> +void hmp_system_wakeup(Monitor *mon, const QDict *qdict)
> +{
> +    qmp_system_wakeup(NULL);
> +}
> +
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
>  {
>      Error *errp = NULL;
> diff --git a/hmp.h b/hmp.h
> index 18eecbd..5409464 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -41,6 +41,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
>  void hmp_memsave(Monitor *mon, const QDict *qdict);
>  void hmp_pmemsave(Monitor *mon, const QDict *qdict);
>  void hmp_cont(Monitor *mon, const QDict *qdict);
> +void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
>  void hmp_set_link(Monitor *mon, const QDict *qdict);
>  void hmp_block_passwd(Monitor *mon, const QDict *qdict);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index d02ee86..226c1da 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -999,6 +999,17 @@
>  { 'command': 'cont' }
>  
>  ##
> +# @system_wakeup:
> +#
> +# Wakeup guest from suspend
> +#
> +# Since:  1.1
> +#
> +# Returns:  nothing.
> +##
> +{ 'command': 'system_wakeup' }
> +
> +##
>  # @inject-nmi:
>  #
>  # Injects an Non-Maskable Interrupt into all guest's VCPUs.
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index b5e2ab8..f5081e2 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -212,6 +212,27 @@ Example:
>  EQMP
>  
>      {
> +        .name       = "system_wakeup",
> +        .args_type  = "",
> +        .mhandler.cmd_new = qmp_marshal_input_system_wakeup,
> +    },
> +
> +SQMP
> +system_wakeup
> +-------------
> +
> +Wakeup guest from suspend.
> +
> +Arguments: None.
> +
> +Example:
> +
> +-> { "execute": "system_wakeup" }
> +<- { "return": {} }
> +
> +EQMP
> +
> +    {
>          .name       = "system_reset",
>          .args_type  = "",
>          .mhandler.cmd_new = qmp_marshal_input_system_reset,
> diff --git a/qmp.c b/qmp.c
> index 45052cc..9ff5ec3 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -164,6 +164,11 @@ void qmp_cont(Error **errp)
>      vm_start();
>  }
>  
> +void qmp_system_wakeup(Error **errp)
> +{
> +    qemu_system_wakeup_request();
> +}
> +
>  ObjectPropertyInfoList *qmp_qom_list(const char *path, Error **errp)
>  {
>      Object *obj;
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:54:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08: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.xensource.com>)
	id 1RvPlu-0005kT-0S; Thu, 09 Feb 2012 08:54:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPls-0005jP-3k
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:54:28 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328777661!14122598!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5653 invoked from network); 9 Feb 2012 08:54:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 08:54:21 -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 q198sKtu031601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:54:20 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198sJMk030324; Thu, 9 Feb 2012 03:54:20 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 552D8133EEF; Thu,  9 Feb 2012 10:54:19 +0200 (IST)
Date: Thu, 9 Feb 2012 10:54:19 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209085419.GD18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-4-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-4-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 3/6] suspend: add
 system_wakeup monitor command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:16PM +0100, Gerd Hoffmann wrote:
> This patch adds the system_wakeup monitor command which will simply
> wake up suspended guests.
> 
We can report this one as power button wakeup.

> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hmp-commands.hx  |   14 ++++++++++++++
>  hmp.c            |    5 +++++
>  hmp.h            |    1 +
>  qapi-schema.json |   11 +++++++++++
>  qmp-commands.hx  |   21 +++++++++++++++++++++
>  qmp.c            |    5 +++++
>  6 files changed, 57 insertions(+), 0 deletions(-)
> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 573b823..64b3656 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -352,6 +352,20 @@ Resume emulation.
>  ETEXI
>  
>      {
> +        .name       = "system_wakeup",
> +        .args_type  = "",
> +        .params     = "",
> +        .help       = "wakeup guest from suspend",
> +        .mhandler.cmd = hmp_system_wakeup,
> +    },
> +
> +STEXI
> +@item system_wakeup
> +@findex system_wakeup
> +Wakeup guest from suspend.
> +ETEXI
> +
> +    {
>          .name       = "gdbserver",
>          .args_type  = "device:s?",
>          .params     = "[device]",
> diff --git a/hmp.c b/hmp.c
> index 8ff8c94..3a54455 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -632,6 +632,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
>      }
>  }
>  
> +void hmp_system_wakeup(Monitor *mon, const QDict *qdict)
> +{
> +    qmp_system_wakeup(NULL);
> +}
> +
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
>  {
>      Error *errp = NULL;
> diff --git a/hmp.h b/hmp.h
> index 18eecbd..5409464 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -41,6 +41,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
>  void hmp_memsave(Monitor *mon, const QDict *qdict);
>  void hmp_pmemsave(Monitor *mon, const QDict *qdict);
>  void hmp_cont(Monitor *mon, const QDict *qdict);
> +void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
>  void hmp_set_link(Monitor *mon, const QDict *qdict);
>  void hmp_block_passwd(Monitor *mon, const QDict *qdict);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index d02ee86..226c1da 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -999,6 +999,17 @@
>  { 'command': 'cont' }
>  
>  ##
> +# @system_wakeup:
> +#
> +# Wakeup guest from suspend
> +#
> +# Since:  1.1
> +#
> +# Returns:  nothing.
> +##
> +{ 'command': 'system_wakeup' }
> +
> +##
>  # @inject-nmi:
>  #
>  # Injects an Non-Maskable Interrupt into all guest's VCPUs.
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index b5e2ab8..f5081e2 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -212,6 +212,27 @@ Example:
>  EQMP
>  
>      {
> +        .name       = "system_wakeup",
> +        .args_type  = "",
> +        .mhandler.cmd_new = qmp_marshal_input_system_wakeup,
> +    },
> +
> +SQMP
> +system_wakeup
> +-------------
> +
> +Wakeup guest from suspend.
> +
> +Arguments: None.
> +
> +Example:
> +
> +-> { "execute": "system_wakeup" }
> +<- { "return": {} }
> +
> +EQMP
> +
> +    {
>          .name       = "system_reset",
>          .args_type  = "",
>          .mhandler.cmd_new = qmp_marshal_input_system_reset,
> diff --git a/qmp.c b/qmp.c
> index 45052cc..9ff5ec3 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -164,6 +164,11 @@ void qmp_cont(Error **errp)
>      vm_start();
>  }
>  
> +void qmp_system_wakeup(Error **errp)
> +{
> +    qemu_system_wakeup_request();
> +}
> +
>  ObjectPropertyInfoList *qmp_qom_list(const char *path, Error **errp)
>  {
>      Object *obj;
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:56:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08: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.xensource.com>)
	id 1RvPn5-0005wm-Lm; Thu, 09 Feb 2012 08:55: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 1RvPn3-0005wK-9S
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:55:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328777684!52006875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 9 Feb 2012 08:54:45 -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;
	9 Feb 2012 08:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:55:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	08:55:35 +0000
Message-ID: <1328777733.6133.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 08:55:33 +0000
In-Reply-To: <20120209073059.GA20712@aepfle.de>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
	<20120209073059.GA20712@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 9 of 9] xl: use json output by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 07:30 +0000, Olaf Hering wrote:
> On Wed, Jan 25, Ian Campbell wrote:
> 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1327512175 0
> > # Node ID 9e3be181b2b70f521defcd55ecbd9967cd206fb2
> > # Parent  f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
> > xl: use json output by default
> > 
> > Move the sxp producing code off into a separate file. It is supported
> > for legacy reasons and needn't be updated other than the improve
> > compatibility with xm.
> > 
> > libxl_domain_config is not currently generated by the IDL (adding the
> > necessary support for Array types is on my to do list) so hand code
> > the json generation function for now.
> > 
> > Since this rather directly exposes a libxl data structure it's not
> > clear what sort of forward compatibility guarantees we can
> > make. However it seems like it should be as stable as libxl's own API
> > (which we are looking to stabilise)
> 
> This leads to build failures with libyajl2:
> 
> xl_cmdimpl.c: In function 'printf_info':
> xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=unused-value]
> xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
> xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this function)
> xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only once for each function it appears in
> xl_cmdimpl.c:306:5: error: too many arguments to function 'yajl_gen_alloc'
> /usr/include/yajl/yajl_gen.h:118:23: note: declared here
> xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf' from incompatible pointer type [-Werror]
> /usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but argument is of type 'unsigned int *'

I suppose we ought to use the helpers defined in libxl_json.h to
abstract this away. Could you cook up a patch?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:56:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08: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.xensource.com>)
	id 1RvPn5-0005wm-Lm; Thu, 09 Feb 2012 08:55: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 1RvPn3-0005wK-9S
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:55:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328777684!52006875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 9 Feb 2012 08:54:45 -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;
	9 Feb 2012 08:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:55:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	08:55:35 +0000
Message-ID: <1328777733.6133.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 08:55:33 +0000
In-Reply-To: <20120209073059.GA20712@aepfle.de>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
	<20120209073059.GA20712@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 9 of 9] xl: use json output by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 07:30 +0000, Olaf Hering wrote:
> On Wed, Jan 25, Ian Campbell wrote:
> 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1327512175 0
> > # Node ID 9e3be181b2b70f521defcd55ecbd9967cd206fb2
> > # Parent  f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
> > xl: use json output by default
> > 
> > Move the sxp producing code off into a separate file. It is supported
> > for legacy reasons and needn't be updated other than the improve
> > compatibility with xm.
> > 
> > libxl_domain_config is not currently generated by the IDL (adding the
> > necessary support for Array types is on my to do list) so hand code
> > the json generation function for now.
> > 
> > Since this rather directly exposes a libxl data structure it's not
> > clear what sort of forward compatibility guarantees we can
> > make. However it seems like it should be as stable as libxl's own API
> > (which we are looking to stabilise)
> 
> This leads to build failures with libyajl2:
> 
> xl_cmdimpl.c: In function 'printf_info':
> xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=unused-value]
> xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
> xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this function)
> xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only once for each function it appears in
> xl_cmdimpl.c:306:5: error: too many arguments to function 'yajl_gen_alloc'
> /usr/include/yajl/yajl_gen.h:118:23: note: declared here
> xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf' from incompatible pointer type [-Werror]
> /usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but argument is of type 'unsigned int *'

I suppose we ought to use the helpers defined in libxl_json.h to
abstract this away. Could you cook up a patch?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:57:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPoS-00068p-8B; Thu, 09 Feb 2012 08:57:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPoQ-000683-UH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:57:07 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328777820!14123068!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16726 invoked from network); 9 Feb 2012 08:57:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 08:57:00 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q198uxN7032461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:56:59 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198ux7q029089; Thu, 9 Feb 2012 03:56:59 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id A794B133EEF; Thu,  9 Feb 2012 10:56:58 +0200 (IST)
Date: Thu, 9 Feb 2012 10:56:58 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209085658.GE18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-7-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-7-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm
 wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:19PM +0100, Gerd Hoffmann wrote:
> Add a 'wakeup' property to the mc146818rtc.  It is on by default.
> When enabled the rtc will wake up the guest when the alarm fires.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/mc146818rtc.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 314ed52..3b912c6 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -86,6 +86,7 @@ typedef struct RTCState {
>      uint8_t cmos_index;
>      struct tm current_tm;
>      int32_t base_year;
> +    uint32_t wakeup;
>      qemu_irq irq;
>      qemu_irq sqw_irq;
>      int it_shift;
> @@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
>  
>          s->cmos_data[RTC_REG_C] |= REG_C_AF;
>          if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
> +            if (s->wakeup) {
> +                qemu_system_wakeup_request();
> +            }
RTC should do wakeup only if RTC_EN bit is set pm1en.


>              qemu_irq_raise(s->irq);
>              s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
>          }
> @@ -725,6 +729,7 @@ static Property mc146818rtc_properties[] = {
>      DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
>      DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
>                                 lost_tick_policy, LOST_TICK_DISCARD),
> +    DEFINE_PROP_UINT32("wakeup",   RTCState, wakeup,    1),
>      DEFINE_PROP_END_OF_LIST(),
>  };
>  
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:57:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPoS-00068p-8B; Thu, 09 Feb 2012 08:57:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvPoQ-000683-UH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:57:07 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328777820!14123068!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE5NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16726 invoked from network); 9 Feb 2012 08:57:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 08:57:00 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q198uxN7032461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 03:56:59 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q198ux7q029089; Thu, 9 Feb 2012 03:56:59 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id A794B133EEF; Thu,  9 Feb 2012 10:56:58 +0200 (IST)
Date: Thu, 9 Feb 2012 10:56:58 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209085658.GE18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-7-git-send-email-kraxel@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328698819-31269-7-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm
 wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 12:00:19PM +0100, Gerd Hoffmann wrote:
> Add a 'wakeup' property to the mc146818rtc.  It is on by default.
> When enabled the rtc will wake up the guest when the alarm fires.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/mc146818rtc.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 314ed52..3b912c6 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -86,6 +86,7 @@ typedef struct RTCState {
>      uint8_t cmos_index;
>      struct tm current_tm;
>      int32_t base_year;
> +    uint32_t wakeup;
>      qemu_irq irq;
>      qemu_irq sqw_irq;
>      int it_shift;
> @@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
>  
>          s->cmos_data[RTC_REG_C] |= REG_C_AF;
>          if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
> +            if (s->wakeup) {
> +                qemu_system_wakeup_request();
> +            }
RTC should do wakeup only if RTC_EN bit is set pm1en.


>              qemu_irq_raise(s->irq);
>              s->cmos_data[RTC_REG_C] |= REG_C_IRQF;
>          }
> @@ -725,6 +729,7 @@ static Property mc146818rtc_properties[] = {
>      DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
>      DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
>                                 lost_tick_policy, LOST_TICK_DISCARD),
> +    DEFINE_PROP_UINT32("wakeup",   RTCState, wakeup,    1),
>      DEFINE_PROP_END_OF_LIST(),
>  };
>  
> -- 
> 1.7.1
> 
> 

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:57:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08:57:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPoU-00069O-L9; Thu, 09 Feb 2012 08:57:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvPoT-00068I-BT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:57:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328777823!12628158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31184 invoked from network); 9 Feb 2012 08:57:03 -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;
	9 Feb 2012 08:57:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:57:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	08:57:02 +0000
Message-ID: <1328777821.6133.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Todd Deshane <todd.deshane@xen.org>
Date: Thu, 9 Feb 2012 08:57:01 +0000
In-Reply-To: <CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 01:02 +0000, Todd Deshane wrote:
> On Wed, Feb 8, 2012 at 5:23 PM, Fantu <fantonifabio@tiscali.it> wrote:
> > I see there is spice support in unstable, seem to be a very good vdi and we
> > want use it on server with xen but I not found documentation about in xen,
> > only about kvm.
> 
> usage here:
> 
> http://xen.markmail.org/search/?q=spice#query:spice%20list%3Acom.xensource.lists.xen-changelog+page:1+mid:gx7eglq7wdvfmtxc+state:results
> 

The syntax is also documented in the xl.cfg(5) manpage which is
available online at
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#spice_graphics_support

I suspect it needs device_model_version="qemu-xen" (i.e. upstream qemu)
as well.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 08:57:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 08:57:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPoU-00069O-L9; Thu, 09 Feb 2012 08:57:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvPoT-00068I-BT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 08:57:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328777823!12628158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODQwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31184 invoked from network); 9 Feb 2012 08:57:03 -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;
	9 Feb 2012 08:57:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:57:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	08:57:02 +0000
Message-ID: <1328777821.6133.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Todd Deshane <todd.deshane@xen.org>
Date: Thu, 9 Feb 2012 08:57:01 +0000
In-Reply-To: <CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 01:02 +0000, Todd Deshane wrote:
> On Wed, Feb 8, 2012 at 5:23 PM, Fantu <fantonifabio@tiscali.it> wrote:
> > I see there is spice support in unstable, seem to be a very good vdi and we
> > want use it on server with xen but I not found documentation about in xen,
> > only about kvm.
> 
> usage here:
> 
> http://xen.markmail.org/search/?q=spice#query:spice%20list%3Acom.xensource.lists.xen-changelog+page:1+mid:gx7eglq7wdvfmtxc+state:results
> 

The syntax is also documented in the xl.cfg(5) manpage which is
available online at
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#spice_graphics_support

I suspect it needs device_model_version="qemu-xen" (i.e. upstream qemu)
as well.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:02:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:02:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPsy-0006iW-4M; Thu, 09 Feb 2012 09:01:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvPsx-0006i5-2U
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:01:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328778100!12640070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17240 invoked from network); 9 Feb 2012 09:01:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 09:01:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 09:03:18 +0000
Message-Id: <4F3399820200007800071D17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 09:01:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4F310C5B0200007800071870@nat28.tlf.novell.com>
	<CB5662D8.2A8BB%keir.xen@gmail.com>
In-Reply-To: <CB5662D8.2A8BB%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 06:10, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/02/2012 10:34, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 06.02.12 at 18:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
>>> larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
>>> to unsigned long * - how is that not a problem in the context of the
>>> goal that said c/s set, in particular for v2 of the interface? (Given that
>>> this is being implemented as arch-specific routine - so far for reasons
>>> that escape me - this should be simple to fix by using inline assembly
>>> rather than clear_bit().)
>>> 
>>> Further I just spotted one instance where the or of two bit positions
>>> gets passed to this function - that's quite definitely a bug I would say.
>>> 
>>> And, quite the opposite, __fixup_status_for_pin() ands out the
>>> negation of bit positions rather than masks... (Which also raises
>>> the question whether it really would need to be clear_bit() above
>>> instead of the cheaper __clear_bit().)
>> 
>> Below the tentative fix for all of the above problems. In the light
>> of the comment at the top of x86's bitops.h I'm awaiting our gcc
>> experts' response regarding the safety of using "+m" here.
> 
> Looks fine to me, in principle. I would add a comment to the x86
> gnttab_clear_flag() explaining why we have to open code something that looks
> a lot like clear_bit().

That one I already did, will submit soon (desiring clarification on the
below).

As to the "+m" constraint - I'm being told that "+m" (var) is equivalent
to "=m" (var) : "m" (var), no matter what the documentation says
regarding '+' (but they're also not seeing a need to adjust the docs
accordingly).

The question is whether we should go with the (documentation-wise
correct) form, or the shorter one (which they're unlikely to change
the meaning of, given in how many places "+m" is used in e.g. Linux).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:02:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:02:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPsy-0006iW-4M; Thu, 09 Feb 2012 09:01:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvPsx-0006i5-2U
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:01:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328778100!12640070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17240 invoked from network); 9 Feb 2012 09:01:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 09:01:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 09:03:18 +0000
Message-Id: <4F3399820200007800071D17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 09:01:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4F310C5B0200007800071870@nat28.tlf.novell.com>
	<CB5662D8.2A8BB%keir.xen@gmail.com>
In-Reply-To: <CB5662D8.2A8BB%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.02.12 at 06:10, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/02/2012 10:34, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 06.02.12 at 18:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> Back in c/s 17194:af33f2054f47 bitops got restricted to 4-bytes and
>>> larger operands only. gnttab_clear_flag() cheats in casting a uint16_t *
>>> to unsigned long * - how is that not a problem in the context of the
>>> goal that said c/s set, in particular for v2 of the interface? (Given that
>>> this is being implemented as arch-specific routine - so far for reasons
>>> that escape me - this should be simple to fix by using inline assembly
>>> rather than clear_bit().)
>>> 
>>> Further I just spotted one instance where the or of two bit positions
>>> gets passed to this function - that's quite definitely a bug I would say.
>>> 
>>> And, quite the opposite, __fixup_status_for_pin() ands out the
>>> negation of bit positions rather than masks... (Which also raises
>>> the question whether it really would need to be clear_bit() above
>>> instead of the cheaper __clear_bit().)
>> 
>> Below the tentative fix for all of the above problems. In the light
>> of the comment at the top of x86's bitops.h I'm awaiting our gcc
>> experts' response regarding the safety of using "+m" here.
> 
> Looks fine to me, in principle. I would add a comment to the x86
> gnttab_clear_flag() explaining why we have to open code something that looks
> a lot like clear_bit().

That one I already did, will submit soon (desiring clarification on the
below).

As to the "+m" constraint - I'm being told that "+m" (var) is equivalent
to "=m" (var) : "m" (var), no matter what the documentation says
regarding '+' (but they're also not seeing a need to adjust the docs
accordingly).

The question is whether we should go with the (documentation-wise
correct) form, or the shorter one (which they're unlikely to change
the meaning of, given in how many places "+m" is used in e.g. Linux).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvPtX-0006mp-Ij; Thu, 09 Feb 2012 09:02:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RvPtV-0006mA-UR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:02:22 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328778113!52177491!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNTguMjUxLjE1Mi42NiA9PiA1NDcw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8732 invoked from network); 9 Feb 2012 09:01:54 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-11.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 09:01:54 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ400FKEBNKU4@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:59:44 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ400EK0BLHJ8@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:59:44 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGZ37294; Thu,
	09 Feb 2012 16:59:44 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137)
	by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:59:02 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:59:24 +0800
Date: Thu, 09 Feb 2012 16:59:19 +0800
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.9+10-e9264b45237d
X-Mercurial-Node: 68eae0b487aef8349f168518f56264ce61afb0a1
X-CFilter-Loop: Reflected
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: [Xen-devel] [PATCH] xenpaging:add the dealing of
 MEM_EVENT_FLAG_EVICT_FAIL request in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1224695418168661668=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1224695418168661668==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1328777881 -28800
# Node ID 68eae0b487aef8349f168518f56264ce61afb0a1
# Parent  9f4640e40d4f31563885427a5a8d9eae2e110514
xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in
tools/xenpaging

If a page is nominated but not evicted,then dom0 accesses the page,it
will change the page's p2mt to be p2m_ram_paging_in,and the req.flags is
MEM_EVENT_FLAG_EVICT_FAIL;so it will fail in p2m_mem_paging_evict() because
of the p2mt;and paging->num_paged_out will not increase in this case;After
the paging process is terminated, the p2mt p2m_ram_paging_in still remains
in p2m table.Once domU accesses the nominated page,it will result in BSOD
or vm'stuck.
The patch adds the dealing of this request to resume the page before xenpaging
is ended.

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 9f4640e40d4f -r 68eae0b487ae tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Feb 09 16:50:52 2012 +0800
+++ b/tools/xenpaging/xenpaging.c	Thu Feb 09 16:58:01 2012 +0800
@@ -911,7 +911,7 @@
                         !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
 
                 /* Tell Xen to resume the vcpu */
-                if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+                if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
                 {
                     /* Prepare the response */
                     rsp.gfn = req.gfn;


--===============1224695418168661668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1224695418168661668==--

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvPtX-0006mp-Ij; Thu, 09 Feb 2012 09:02:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RvPtV-0006mA-UR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:02:22 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328778113!52177491!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNTguMjUxLjE1Mi42NiA9PiA1NDcw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8732 invoked from network); 9 Feb 2012 09:01:54 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-11.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 09:01:54 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ400FKEBNKU4@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:59:44 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZ400EK0BLHJ8@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:59:44 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGZ37294; Thu,
	09 Feb 2012 16:59:44 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137)
	by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:59:02 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 09 Feb 2012 16:59:24 +0800
Date: Thu, 09 Feb 2012 16:59:19 +0800
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.9+10-e9264b45237d
X-Mercurial-Node: 68eae0b487aef8349f168518f56264ce61afb0a1
X-CFilter-Loop: Reflected
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: [Xen-devel] [PATCH] xenpaging:add the dealing of
 MEM_EVENT_FLAG_EVICT_FAIL request in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1224695418168661668=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1224695418168661668==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1328777881 -28800
# Node ID 68eae0b487aef8349f168518f56264ce61afb0a1
# Parent  9f4640e40d4f31563885427a5a8d9eae2e110514
xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in
tools/xenpaging

If a page is nominated but not evicted,then dom0 accesses the page,it
will change the page's p2mt to be p2m_ram_paging_in,and the req.flags is
MEM_EVENT_FLAG_EVICT_FAIL;so it will fail in p2m_mem_paging_evict() because
of the p2mt;and paging->num_paged_out will not increase in this case;After
the paging process is terminated, the p2mt p2m_ram_paging_in still remains
in p2m table.Once domU accesses the nominated page,it will result in BSOD
or vm'stuck.
The patch adds the dealing of this request to resume the page before xenpaging
is ended.

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 9f4640e40d4f -r 68eae0b487ae tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Feb 09 16:50:52 2012 +0800
+++ b/tools/xenpaging/xenpaging.c	Thu Feb 09 16:58:01 2012 +0800
@@ -911,7 +911,7 @@
                         !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
 
                 /* Tell Xen to resume the vcpu */
-                if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+                if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
                 {
                     /* Prepare the response */
                     rsp.gfn = req.gfn;


--===============1224695418168661668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1224695418168661668==--

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:02:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPtr-0006qc-0R; Thu, 09 Feb 2012 09:02:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglist@modernbiztonsag.org>) id 1RvPtq-0006pJ-2p
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:02:42 +0000
X-Env-Sender: mailinglist@modernbiztonsag.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328778155!5193751!1
X-Originating-IP: [212.52.166.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3702 invoked from network); 9 Feb 2012 09:02:36 -0000
Received: from mail.modernbiztonsag.org (HELO mail.modernbiztonsag.org)
	(212.52.166.188)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 09:02:36 -0000
Received: from admin.modernbiztonsag.org (www.jails [10.0.0.4])
	by mail.modernbiztonsag.org (Postfix) with ESMTP id 6AB3A1593B4;
	Thu,  9 Feb 2012 10:02:34 +0100 (CET)
Received: from 80.99.60.12 (proxying for 80.99.60.12)
	(SquirrelMail authenticated user mailinglist@modernbiztonsag.org)
	by admin.modernbiztonsag.org with HTTP;
	Thu, 9 Feb 2012 10:02:34 +0100
Message-ID: <a14d74fa7ee7c544e1221c69466d3e28.squirrel@admin.modernbiztonsag.org>
In-Reply-To: <20120208174912.GX12984@reaktio.net>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
	<20120208174912.GX12984@reaktio.net>
Date: Thu, 9 Feb 2012 10:02:34 +0100
From: mailinglist@modernbiztonsag.org
To: =?utf-8?B?IlBhc2kgS8Okcmtrw6RpbmVuIg==?= <pasik@iki.fi>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>, mailinglist@modernbiztonsag.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Feb 08, 2012 at 04:59:18PM +0100, mailinglist@modernbiztonsag.org
> wrote:
>> Dear List,
>>
>
> Hello,
>
>> i'm experimenting with remus with the following setup.
>>
>> dom0:
>> - Debian Squeeze
>> - Jeremy's 2.6.38.48 kernel
>> - xen 4.1.2 recompiled from sid
>> - DRBD for block device backend
>>
>
Hello,

> Did you try xen-unstable? There are many Remus related fixes/enhancements
> in xen-unstable.
>

Nope, not yet, and i would avoid it if possible because we would like to
use this in a "production" environment. (Shriram's suggestion work though
so i'm onto testing with heavy load now.)

> -- Pasi

Best regards,
Mate

>
>
>> domU
>> - Debian Squeeze
>>
>> Remus is working fine unless i try to give more than 1 core to the domU.
>>
>> Here's the error from remus when i'm trying to enable it for an SMP
>> domU:
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
>>     run(cfg)
>>   File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
>>     dom = vm.VM(cfg.domid)
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in
>> __init__
>>     self.loaddominfo()
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in
>> loaddominfo
>>     self.dom = parsedominfo(self.dominfo)
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
>> parsedominfo
>>     return s2d(dominfo[1:])
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
>>     val = s2d(elem[1:])
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
>>     return s2d(elem)
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
>>     for k, v in val.iteritems():
>> AttributeError: 'int' object has no attribute 'iteritems'
>>
>> I've attached the domU configuration file.
>>
>> Please let me know if you need more info on this.
>>
>> Best regards,
>> Mate
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:02:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPtr-0006qc-0R; Thu, 09 Feb 2012 09:02:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglist@modernbiztonsag.org>) id 1RvPtq-0006pJ-2p
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:02:42 +0000
X-Env-Sender: mailinglist@modernbiztonsag.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328778155!5193751!1
X-Originating-IP: [212.52.166.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3702 invoked from network); 9 Feb 2012 09:02:36 -0000
Received: from mail.modernbiztonsag.org (HELO mail.modernbiztonsag.org)
	(212.52.166.188)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 09:02:36 -0000
Received: from admin.modernbiztonsag.org (www.jails [10.0.0.4])
	by mail.modernbiztonsag.org (Postfix) with ESMTP id 6AB3A1593B4;
	Thu,  9 Feb 2012 10:02:34 +0100 (CET)
Received: from 80.99.60.12 (proxying for 80.99.60.12)
	(SquirrelMail authenticated user mailinglist@modernbiztonsag.org)
	by admin.modernbiztonsag.org with HTTP;
	Thu, 9 Feb 2012 10:02:34 +0100
Message-ID: <a14d74fa7ee7c544e1221c69466d3e28.squirrel@admin.modernbiztonsag.org>
In-Reply-To: <20120208174912.GX12984@reaktio.net>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
	<20120208174912.GX12984@reaktio.net>
Date: Thu, 9 Feb 2012 10:02:34 +0100
From: mailinglist@modernbiztonsag.org
To: =?utf-8?B?IlBhc2kgS8Okcmtrw6RpbmVuIg==?= <pasik@iki.fi>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>, mailinglist@modernbiztonsag.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Feb 08, 2012 at 04:59:18PM +0100, mailinglist@modernbiztonsag.org
> wrote:
>> Dear List,
>>
>
> Hello,
>
>> i'm experimenting with remus with the following setup.
>>
>> dom0:
>> - Debian Squeeze
>> - Jeremy's 2.6.38.48 kernel
>> - xen 4.1.2 recompiled from sid
>> - DRBD for block device backend
>>
>
Hello,

> Did you try xen-unstable? There are many Remus related fixes/enhancements
> in xen-unstable.
>

Nope, not yet, and i would avoid it if possible because we would like to
use this in a "production" environment. (Shriram's suggestion work though
so i'm onto testing with heavy load now.)

> -- Pasi

Best regards,
Mate

>
>
>> domU
>> - Debian Squeeze
>>
>> Remus is working fine unless i try to give more than 1 core to the domU.
>>
>> Here's the error from remus when i'm trying to enable it for an SMP
>> domU:
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/xen-4.1/lib/python/remus", line 219, in <module>
>>     run(cfg)
>>   File "/usr/lib/xen-4.1/lib/python/remus", line 109, in run
>>     dom = vm.VM(cfg.domid)
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 32, in
>> __init__
>>     self.loaddominfo()
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 35, in
>> loaddominfo
>>     self.dom = parsedominfo(self.dominfo)
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 77, in
>> parsedominfo
>>     return s2d(dominfo[1:])
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 61, in s2d
>>     val = s2d(elem[1:])
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 64, in s2d
>>     return s2d(elem)
>>   File "/usr/lib/xen-4.1/lib/python/xen/remus/vm.py", line 66, in s2d
>>     for k, v in val.iteritems():
>> AttributeError: 'int' object has no attribute 'iteritems'
>>
>> I've attached the domU configuration file.
>>
>> Please let me know if you need more info on this.
>>
>> Best regards,
>> Mate
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:03:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPud-000700-FE; Thu, 09 Feb 2012 09:03:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglist@modernbiztonsag.org>) id 1RvPuc-0006zg-4h
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:03:30 +0000
X-Env-Sender: mailinglist@modernbiztonsag.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328778152!55991224!1
X-Originating-IP: [212.52.166.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31054 invoked from network); 9 Feb 2012 09:02:33 -0000
Received: from mail.modernbiztonsag.org (HELO mail.modernbiztonsag.org)
	(212.52.166.188)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 09:02:33 -0000
Received: from admin.modernbiztonsag.org (www.jails [10.0.0.4])
	by mail.modernbiztonsag.org (Postfix) with ESMTP id D8BC315A037;
	Thu,  9 Feb 2012 10:03:27 +0100 (CET)
Received: from 80.99.60.12 (proxying for 80.99.60.12)
	(SquirrelMail authenticated user mailinglist@modernbiztonsag.org)
	by admin.modernbiztonsag.org with HTTP;
	Thu, 9 Feb 2012 10:03:28 +0100
Message-ID: <941f4681de1bfab6cdb75cc7129cd518.squirrel@admin.modernbiztonsag.org>
In-Reply-To: <CAP8mzPPPU5RkqFgB-ydzPP4VZSSooTJ63dUyzPcM+foJ3ONytA@mail.gmail.com>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
	<20120208174912.GX12984@reaktio.net>
	<CAP8mzPPPU5RkqFgB-ydzPP4VZSSooTJ63dUyzPcM+foJ3ONytA@mail.gmail.com>
Date: Thu, 9 Feb 2012 10:03:28 +0100
From: mailinglist@modernbiztonsag.org
To: rshriram@cs.ubc.ca
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
Cc: mailinglist@modernbiztonsag.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PiBPbiBXZWQsIEZlYiA4LCAyMDEyIGF0IDk6NDkgQU0sIFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNp
a0Bpa2kuZmk+IHdyb3RlOgo+Cj4+IE9uIFdlZCwgRmViIDA4LCAyMDEyIGF0IDA0OjU5OjE4UE0g
KzAxMDAsCj4+IG1haWxpbmdsaXN0QG1vZGVybmJpenRvbnNhZy5vcmd3cm90ZToKPj4gPiBEZWFy
IExpc3QsCj4+ID4KPj4KPj4gSGVsbG8sCj4+Cj4+ID4gaSdtIGV4cGVyaW1lbnRpbmcgd2l0aCBy
ZW11cyB3aXRoIHRoZSBmb2xsb3dpbmcgc2V0dXAuCj4+ID4KPj4gPiBkb20wOgo+PiA+IC0gRGVi
aWFuIFNxdWVlemUKPj4gPiAtIEplcmVteSdzIDIuNi4zOC40OCBrZXJuZWwKPj4gPiAtIHhlbiA0
LjEuMiByZWNvbXBpbGVkIGZyb20gc2lkCj4+ID4gLSBEUkJEIGZvciBibG9jayBkZXZpY2UgYmFj
a2VuZAo+PiA+Cj4+Cj4+IERpZCB5b3UgdHJ5IHhlbi11bnN0YWJsZT8gVGhlcmUgYXJlIG1hbnkg
UmVtdXMgcmVsYXRlZAo+PiBmaXhlcy9lbmhhbmNlbWVudHMKPj4gaW4geGVuLXVuc3RhYmxlLgo+
Pgo+Pgo+IElJUkMsIGFsbCBmaXhlcyB3ZXJlIGJhY2twb3J0ZWQgdG8geGVuLTQuMS10ZXN0aW5n
Lgo+Cj4KPj4gLS0gUGFzaQo+Pgo+Pgo+PiA+IGRvbVUKPj4gPiAtIERlYmlhbiBTcXVlZXplCj4+
ID4KPj4gPiBSZW11cyBpcyB3b3JraW5nIGZpbmUgdW5sZXNzIGkgdHJ5IHRvIGdpdmUgbW9yZSB0
aGFuIDEgY29yZSB0byB0aGUKPj4gZG9tVS4KPj4gPgo+Pgo+CgpIZWxsbywKCj4KPiBUaGUgcHJv
YmxlbSBhcmlzZXMgZnJvbSB5b3VyIGRvbVUgY29uZmlnIGZpbGU6Cj4gY3B1cyA9ICIxLTE1Igo+
Cj4gVGhlIHB5dGhvbiBwYXJzZXIgaXMgdW5hYmxlIHRvIHBhcnNlIHRoZSBjcHUgc3BlYyBpbiB0
aGlzIGZvcm1hdC4gSSB0aGluawo+IGV2ZW4KPiBjcHVzID0gIl4wIiB0aHJvd3MgYW4gZXJyb3Ig
b2Ygc2ltaWxhciBzb3J0Lgo+Cj4gT25lIHNvbHV0aW9uIGlzIHRvIHJlbW92ZSB0aGlzIGxpbmUs
IGJvb3QgdGhlIGRvbVUsCj4gYW5kIGRvIHhtIHZjcHUtcGluIGNvbW1hbmQgdG8gcmVzdHJpY3Qg
dGhlIHBoeXNpY2FsIGNwdXMKPiBvbiB3aGljaCB5b3Ugd2lzaCB0aGUgZG9tVSB0byBydW4uCj4K
ClllcywgdGhhdCB3YXMgdGhlIHNvbHV0aW9uISBUaGFuayB5b3UgZm9yIHRoZSBxdWljayBhbnN3
ZXIhCgo+Cj4gc2hyaXJhbQoKQmVzdCByZWdhcmRzLApNYXRlCgo+Cj4KPj4gID4gSGVyZSdzIHRo
ZSBlcnJvciBmcm9tIHJlbXVzIHdoZW4gaSdtIHRyeWluZyB0byBlbmFibGUgaXQgZm9yIGFuIFNN
UAo+PiBkb21VOgo+PiA+Cj4+ID4gVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOgo+
PiA+ICAgRmlsZSAiL3Vzci9saWIveGVuLTQuMS9saWIvcHl0aG9uL3JlbXVzIiwgbGluZSAyMTks
IGluIDxtb2R1bGU+Cj4+ID4gICAgIHJ1bihjZmcpCj4+ID4gICBGaWxlICIvdXNyL2xpYi94ZW4t
NC4xL2xpYi9weXRob24vcmVtdXMiLCBsaW5lIDEwOSwgaW4gcnVuCj4+ID4gICAgIGRvbSA9IHZt
LlZNKGNmZy5kb21pZCkKPj4gPiAgIEZpbGUgIi91c3IvbGliL3hlbi00LjEvbGliL3B5dGhvbi94
ZW4vcmVtdXMvdm0ucHkiLCBsaW5lIDMyLCBpbgo+PiBfX2luaXRfXwo+PiA+ICAgICBzZWxmLmxv
YWRkb21pbmZvKCkKPj4gPiAgIEZpbGUgIi91c3IvbGliL3hlbi00LjEvbGliL3B5dGhvbi94ZW4v
cmVtdXMvdm0ucHkiLCBsaW5lIDM1LCBpbgo+PiBsb2FkZG9taW5mbwo+PiA+ICAgICBzZWxmLmRv
bSA9IHBhcnNlZG9taW5mbyhzZWxmLmRvbWluZm8pCj4+ID4gICBGaWxlICIvdXNyL2xpYi94ZW4t
NC4xL2xpYi9weXRob24veGVuL3JlbXVzL3ZtLnB5IiwgbGluZSA3NywgaW4KPj4gPiBwYXJzZWRv
bWluZm8KPj4gPiAgICAgcmV0dXJuIHMyZChkb21pbmZvWzE6XSkKPj4gPiAgIEZpbGUgIi91c3Iv
bGliL3hlbi00LjEvbGliL3B5dGhvbi94ZW4vcmVtdXMvdm0ucHkiLCBsaW5lIDYxLCBpbiBzMmQK
Pj4gPiAgICAgdmFsID0gczJkKGVsZW1bMTpdKQo+PiA+ICAgRmlsZSAiL3Vzci9saWIveGVuLTQu
MS9saWIvcHl0aG9uL3hlbi9yZW11cy92bS5weSIsIGxpbmUgNjQsIGluIHMyZAo+PiA+ICAgICBy
ZXR1cm4gczJkKGVsZW0pCj4+ID4gICBGaWxlICIvdXNyL2xpYi94ZW4tNC4xL2xpYi9weXRob24v
eGVuL3JlbXVzL3ZtLnB5IiwgbGluZSA2NiwgaW4gczJkCj4+ID4gICAgIGZvciBrLCB2IGluIHZh
bC5pdGVyaXRlbXMoKToKPj4gPiBBdHRyaWJ1dGVFcnJvcjogJ2ludCcgb2JqZWN0IGhhcyBubyBh
dHRyaWJ1dGUgJ2l0ZXJpdGVtcycKPj4gPgo+PiA+IEkndmUgYXR0YWNoZWQgdGhlIGRvbVUgY29u
ZmlndXJhdGlvbiBmaWxlLgo+PiA+Cj4+ID4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBuZWVk
IG1vcmUgaW5mbyBvbiB0aGlzLgo+PiA+Cj4+ID4gQmVzdCByZWdhcmRzLAo+PiA+IE1hdGUKPj4K
Pj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiA+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gPiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQo+PiA+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo+Pgo+Pgo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1h
aWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:03:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPud-000700-FE; Thu, 09 Feb 2012 09:03:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglist@modernbiztonsag.org>) id 1RvPuc-0006zg-4h
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:03:30 +0000
X-Env-Sender: mailinglist@modernbiztonsag.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328778152!55991224!1
X-Originating-IP: [212.52.166.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31054 invoked from network); 9 Feb 2012 09:02:33 -0000
Received: from mail.modernbiztonsag.org (HELO mail.modernbiztonsag.org)
	(212.52.166.188)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 09:02:33 -0000
Received: from admin.modernbiztonsag.org (www.jails [10.0.0.4])
	by mail.modernbiztonsag.org (Postfix) with ESMTP id D8BC315A037;
	Thu,  9 Feb 2012 10:03:27 +0100 (CET)
Received: from 80.99.60.12 (proxying for 80.99.60.12)
	(SquirrelMail authenticated user mailinglist@modernbiztonsag.org)
	by admin.modernbiztonsag.org with HTTP;
	Thu, 9 Feb 2012 10:03:28 +0100
Message-ID: <941f4681de1bfab6cdb75cc7129cd518.squirrel@admin.modernbiztonsag.org>
In-Reply-To: <CAP8mzPPPU5RkqFgB-ydzPP4VZSSooTJ63dUyzPcM+foJ3ONytA@mail.gmail.com>
References: <c52071c229ce804f1e84e43dd63bdbfe.squirrel@admin.modernbiztonsag.org>
	<20120208174912.GX12984@reaktio.net>
	<CAP8mzPPPU5RkqFgB-ydzPP4VZSSooTJ63dUyzPcM+foJ3ONytA@mail.gmail.com>
Date: Thu, 9 Feb 2012 10:03:28 +0100
From: mailinglist@modernbiztonsag.org
To: rshriram@cs.ubc.ca
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
Cc: mailinglist@modernbiztonsag.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] remus fail with SMP domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PiBPbiBXZWQsIEZlYiA4LCAyMDEyIGF0IDk6NDkgQU0sIFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNp
a0Bpa2kuZmk+IHdyb3RlOgo+Cj4+IE9uIFdlZCwgRmViIDA4LCAyMDEyIGF0IDA0OjU5OjE4UE0g
KzAxMDAsCj4+IG1haWxpbmdsaXN0QG1vZGVybmJpenRvbnNhZy5vcmd3cm90ZToKPj4gPiBEZWFy
IExpc3QsCj4+ID4KPj4KPj4gSGVsbG8sCj4+Cj4+ID4gaSdtIGV4cGVyaW1lbnRpbmcgd2l0aCBy
ZW11cyB3aXRoIHRoZSBmb2xsb3dpbmcgc2V0dXAuCj4+ID4KPj4gPiBkb20wOgo+PiA+IC0gRGVi
aWFuIFNxdWVlemUKPj4gPiAtIEplcmVteSdzIDIuNi4zOC40OCBrZXJuZWwKPj4gPiAtIHhlbiA0
LjEuMiByZWNvbXBpbGVkIGZyb20gc2lkCj4+ID4gLSBEUkJEIGZvciBibG9jayBkZXZpY2UgYmFj
a2VuZAo+PiA+Cj4+Cj4+IERpZCB5b3UgdHJ5IHhlbi11bnN0YWJsZT8gVGhlcmUgYXJlIG1hbnkg
UmVtdXMgcmVsYXRlZAo+PiBmaXhlcy9lbmhhbmNlbWVudHMKPj4gaW4geGVuLXVuc3RhYmxlLgo+
Pgo+Pgo+IElJUkMsIGFsbCBmaXhlcyB3ZXJlIGJhY2twb3J0ZWQgdG8geGVuLTQuMS10ZXN0aW5n
Lgo+Cj4KPj4gLS0gUGFzaQo+Pgo+Pgo+PiA+IGRvbVUKPj4gPiAtIERlYmlhbiBTcXVlZXplCj4+
ID4KPj4gPiBSZW11cyBpcyB3b3JraW5nIGZpbmUgdW5sZXNzIGkgdHJ5IHRvIGdpdmUgbW9yZSB0
aGFuIDEgY29yZSB0byB0aGUKPj4gZG9tVS4KPj4gPgo+Pgo+CgpIZWxsbywKCj4KPiBUaGUgcHJv
YmxlbSBhcmlzZXMgZnJvbSB5b3VyIGRvbVUgY29uZmlnIGZpbGU6Cj4gY3B1cyA9ICIxLTE1Igo+
Cj4gVGhlIHB5dGhvbiBwYXJzZXIgaXMgdW5hYmxlIHRvIHBhcnNlIHRoZSBjcHUgc3BlYyBpbiB0
aGlzIGZvcm1hdC4gSSB0aGluawo+IGV2ZW4KPiBjcHVzID0gIl4wIiB0aHJvd3MgYW4gZXJyb3Ig
b2Ygc2ltaWxhciBzb3J0Lgo+Cj4gT25lIHNvbHV0aW9uIGlzIHRvIHJlbW92ZSB0aGlzIGxpbmUs
IGJvb3QgdGhlIGRvbVUsCj4gYW5kIGRvIHhtIHZjcHUtcGluIGNvbW1hbmQgdG8gcmVzdHJpY3Qg
dGhlIHBoeXNpY2FsIGNwdXMKPiBvbiB3aGljaCB5b3Ugd2lzaCB0aGUgZG9tVSB0byBydW4uCj4K
ClllcywgdGhhdCB3YXMgdGhlIHNvbHV0aW9uISBUaGFuayB5b3UgZm9yIHRoZSBxdWljayBhbnN3
ZXIhCgo+Cj4gc2hyaXJhbQoKQmVzdCByZWdhcmRzLApNYXRlCgo+Cj4KPj4gID4gSGVyZSdzIHRo
ZSBlcnJvciBmcm9tIHJlbXVzIHdoZW4gaSdtIHRyeWluZyB0byBlbmFibGUgaXQgZm9yIGFuIFNN
UAo+PiBkb21VOgo+PiA+Cj4+ID4gVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOgo+
PiA+ICAgRmlsZSAiL3Vzci9saWIveGVuLTQuMS9saWIvcHl0aG9uL3JlbXVzIiwgbGluZSAyMTks
IGluIDxtb2R1bGU+Cj4+ID4gICAgIHJ1bihjZmcpCj4+ID4gICBGaWxlICIvdXNyL2xpYi94ZW4t
NC4xL2xpYi9weXRob24vcmVtdXMiLCBsaW5lIDEwOSwgaW4gcnVuCj4+ID4gICAgIGRvbSA9IHZt
LlZNKGNmZy5kb21pZCkKPj4gPiAgIEZpbGUgIi91c3IvbGliL3hlbi00LjEvbGliL3B5dGhvbi94
ZW4vcmVtdXMvdm0ucHkiLCBsaW5lIDMyLCBpbgo+PiBfX2luaXRfXwo+PiA+ICAgICBzZWxmLmxv
YWRkb21pbmZvKCkKPj4gPiAgIEZpbGUgIi91c3IvbGliL3hlbi00LjEvbGliL3B5dGhvbi94ZW4v
cmVtdXMvdm0ucHkiLCBsaW5lIDM1LCBpbgo+PiBsb2FkZG9taW5mbwo+PiA+ICAgICBzZWxmLmRv
bSA9IHBhcnNlZG9taW5mbyhzZWxmLmRvbWluZm8pCj4+ID4gICBGaWxlICIvdXNyL2xpYi94ZW4t
NC4xL2xpYi9weXRob24veGVuL3JlbXVzL3ZtLnB5IiwgbGluZSA3NywgaW4KPj4gPiBwYXJzZWRv
bWluZm8KPj4gPiAgICAgcmV0dXJuIHMyZChkb21pbmZvWzE6XSkKPj4gPiAgIEZpbGUgIi91c3Iv
bGliL3hlbi00LjEvbGliL3B5dGhvbi94ZW4vcmVtdXMvdm0ucHkiLCBsaW5lIDYxLCBpbiBzMmQK
Pj4gPiAgICAgdmFsID0gczJkKGVsZW1bMTpdKQo+PiA+ICAgRmlsZSAiL3Vzci9saWIveGVuLTQu
MS9saWIvcHl0aG9uL3hlbi9yZW11cy92bS5weSIsIGxpbmUgNjQsIGluIHMyZAo+PiA+ICAgICBy
ZXR1cm4gczJkKGVsZW0pCj4+ID4gICBGaWxlICIvdXNyL2xpYi94ZW4tNC4xL2xpYi9weXRob24v
eGVuL3JlbXVzL3ZtLnB5IiwgbGluZSA2NiwgaW4gczJkCj4+ID4gICAgIGZvciBrLCB2IGluIHZh
bC5pdGVyaXRlbXMoKToKPj4gPiBBdHRyaWJ1dGVFcnJvcjogJ2ludCcgb2JqZWN0IGhhcyBubyBh
dHRyaWJ1dGUgJ2l0ZXJpdGVtcycKPj4gPgo+PiA+IEkndmUgYXR0YWNoZWQgdGhlIGRvbVUgY29u
ZmlndXJhdGlvbiBmaWxlLgo+PiA+Cj4+ID4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBuZWVk
IG1vcmUgaW5mbyBvbiB0aGlzLgo+PiA+Cj4+ID4gQmVzdCByZWdhcmRzLAo+PiA+IE1hdGUKPj4K
Pj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiA+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gPiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQo+PiA+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo+Pgo+Pgo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1h
aWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:05:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPwK-0007L2-WF; Thu, 09 Feb 2012 09:05:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvPwJ-0007Ja-6s
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:05:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328778308!10782234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17913 invoked from network); 9 Feb 2012 09:05:09 -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;
	9 Feb 2012 09:05:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:05:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:05:08 +0000
Message-ID: <1328778306.6133.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 9 Feb 2012 09:05:06 +0000
In-Reply-To: <CB57D267.2A9D3%keir.xen@gmail.com>
References: <CB57D267.2A9D3%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 07:19 +0000, Keir Fraser wrote:
> On 08/02/2012 14:15, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
> >> Xen Developers,
> >> 
> >> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
> >> but not used warning for variable 'message' in function init_kbdfront.
> >> (Looks like another one just like it, in function init_fbfront, from
> >> the same file.) My source won't compile with these warnings. I could
> >> not find a patch for this in xen-4.1-testing.hg Xenbits.
> > 
> > This new, enabled by default, compiler warning is very annoying, even
> > though it happens to be correct. Which distro has done it? (or maybe
> > it's just new enough gcc which is to blame).
> 
> We should be disablign this warning in Config.mk, where we add
> -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
> same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
> $(call cc-option-add ...) because older gcc versions do not have this
> warning.

I imagine that would look like the following, John does this work for
you?

On the other hand although this compiler warning is annoying these
particular ones do seem to be real issues worth fixing, if only to
improve the error reporting.

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328778190 0
# Node ID 72db20f4f6389649680e13d8ad6d96b5ed9d576f
# Parent  7f2a3ca9d749c65336aca04617bb0a038445fb49
mini-os: Add -Wno-unused-but-set-variable when compiling mini-oss too.

Disabled for the main Xen build in 23368:0f670f5146c8 but mini-os has it's own
CFLAGS.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7f2a3ca9d749 -r 72db20f4f638 extras/mini-os/minios.mk
--- a/extras/mini-os/minios.mk	Thu Feb 09 09:03:10 2012 +0000
+++ b/extras/mini-os/minios.mk	Thu Feb 09 09:03:10 2012 +0000
@@ -9,6 +9,7 @@ debug = y
 DEF_CFLAGS += -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format -Wno-redundant-decls
 DEF_CFLAGS += $(call cc-option,$(CC),-fno-stack-protector,)
 DEF_CFLAGS += $(call cc-option,$(CC),-fgnu89-inline)
+DEF_CFLAGS += $(call cc-option,$(CC),-Wno-unused-but-set-variable)
 DEF_CFLAGS += -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline
 DEF_CPPFLAGS += -D__XEN_INTERFACE_VERSION__=$(XEN_INTERFACE_VERSION)
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:05:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvPwK-0007L2-WF; Thu, 09 Feb 2012 09:05:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvPwJ-0007Ja-6s
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:05:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328778308!10782234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17913 invoked from network); 9 Feb 2012 09:05:09 -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;
	9 Feb 2012 09:05:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:05:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:05:08 +0000
Message-ID: <1328778306.6133.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 9 Feb 2012 09:05:06 +0000
In-Reply-To: <CB57D267.2A9D3%keir.xen@gmail.com>
References: <CB57D267.2A9D3%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 07:19 +0000, Keir Fraser wrote:
> On 08/02/2012 14:15, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
> >> Xen Developers,
> >> 
> >> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
> >> but not used warning for variable 'message' in function init_kbdfront.
> >> (Looks like another one just like it, in function init_fbfront, from
> >> the same file.) My source won't compile with these warnings. I could
> >> not find a patch for this in xen-4.1-testing.hg Xenbits.
> > 
> > This new, enabled by default, compiler warning is very annoying, even
> > though it happens to be correct. Which distro has done it? (or maybe
> > it's just new enough gcc which is to blame).
> 
> We should be disablign this warning in Config.mk, where we add
> -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
> same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
> $(call cc-option-add ...) because older gcc versions do not have this
> warning.

I imagine that would look like the following, John does this work for
you?

On the other hand although this compiler warning is annoying these
particular ones do seem to be real issues worth fixing, if only to
improve the error reporting.

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328778190 0
# Node ID 72db20f4f6389649680e13d8ad6d96b5ed9d576f
# Parent  7f2a3ca9d749c65336aca04617bb0a038445fb49
mini-os: Add -Wno-unused-but-set-variable when compiling mini-oss too.

Disabled for the main Xen build in 23368:0f670f5146c8 but mini-os has it's own
CFLAGS.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7f2a3ca9d749 -r 72db20f4f638 extras/mini-os/minios.mk
--- a/extras/mini-os/minios.mk	Thu Feb 09 09:03:10 2012 +0000
+++ b/extras/mini-os/minios.mk	Thu Feb 09 09:03:10 2012 +0000
@@ -9,6 +9,7 @@ debug = y
 DEF_CFLAGS += -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format -Wno-redundant-decls
 DEF_CFLAGS += $(call cc-option,$(CC),-fno-stack-protector,)
 DEF_CFLAGS += $(call cc-option,$(CC),-fgnu89-inline)
+DEF_CFLAGS += $(call cc-option,$(CC),-Wno-unused-but-set-variable)
 DEF_CFLAGS += -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline
 DEF_CPPFLAGS += -D__XEN_INTERFACE_VERSION__=$(XEN_INTERFACE_VERSION)
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:10:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQ1P-0007nB-16; Thu, 09 Feb 2012 09:10: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 1RvQ1N-0007n6-C3
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:10:29 +0000
Received: from [85.158.139.83:6078] by server-4.bemta-5.messagelabs.com id
	92/DA-28576-48D833F4; Thu, 09 Feb 2012 09:10:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328778626!6996416!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21911 invoked from network); 9 Feb 2012 09:10:27 -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;
	9 Feb 2012 09:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:10:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:10:26 +0000
Message-ID: <1328778625.6133.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Thu, 9 Feb 2012 09:10:25 +0000
In-Reply-To: <6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 15:01 +0000, John McDermott CIV wrote:
> Ian,
> 
> Agreed; this warning is very annoying. The problem is in several
> files, like a design pattern issue. So far it has popped up in
> fbfront.c, blkfront.c, and netfront.c, but the code is nice clean
> code, so the problem is very regular. We are running Fedora 16 and Xen
> 4.1.2.
> 
> ----
> 
> [mc@xenpro3 ~]$ gcc --version
> gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1)
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> ----
> 
> Here is an example of what I have been doing to get rid of the warning:
> 
> ----
> [mc@xenpro3 xenon]$ hg diff extras/mini-os/fbfront.c
> diff -r 8cfe801d065d extras/mini-os/fbfront.c
> --- a/extras/mini-os/fbfront.c	Mon Feb 06 08:37:59 2012 -0500
> +++ b/extras/mini-os/fbfront.c	Wed Feb 08 09:52:06 2012 -0500
> @@ -142,6 +142,9 @@
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    if (message) {
> +	printk("Abort transaction %s", message);
> +    }

I'd be tempted to make these unconditional and then fixup any resultant
"variable message is used but not initialised" type warnings since I
expect we should always have a reason for getting to this particular
point so it would be a bug not to set message at that time.

Would you mind resending this with a Signed-off-by as per
http://wiki.xen.org/wiki/SubmittingXenPatches ? From what you say above
I guess you also have similar fixes to the other drivers, I think it
would be fine to bundle all those similar fixes into a single patch.

Thanks, 
Ian.
>      goto error;
>  
>  done:
> @@ -503,6 +506,9 @@
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    if (message) {
> +	printk("Abort transaction %s", message);
> +    }
>      goto error;
>  
> 
>  done:
> [mc@xenpro3 xenon]$
> ----
> 
> On Feb 8, 2012, at 9:15 AM, Ian Campbell wrote:
> 
> > On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
> >> Xen Developers,
> >> 
> >> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
> >> but not used warning for variable 'message' in function init_kbdfront.
> >> (Looks like another one just like it, in function init_fbfront, from
> >> the same file.) My source won't compile with these warnings. I could
> >> not find a patch for this in xen-4.1-testing.hg Xenbits.
> > 
> > This new, enabled by default, compiler warning is very annoying, even
> > though it happens to be correct. Which distro has done it? (or maybe
> > it's just new enough gcc which is to blame).
> > 
> >> It looks like a conditional printk got left out after the label
> >> 'abort_transaction'. I don't understand fbfront.c well enough to
> >> suggest a patch. Its low priority for me, because I am going to stick
> >> some plausible code in there for now.
> > 
> > I think an unconditional printk including the %s and message is all
> > which is required here. If you've got some plausible code you may as
> > well post it.
> > 
> > Thanks,
> > Ian.
> > 
> >> 
> >> Sincerely,
> >> 
> >> John
> >> ----
> >> What is the formal meaning of the one-line program
> >> #include "/dev/tty"
> >> 
> >> J.P. McDermott			building 12
> >> Code 5542			john.mcdermott@nrl.navy.mil
> >> Naval Research Laboratory	voice: +1 202.404.8301
> >> Washington, DC 20375, US	fax:   +1 202.404.7942
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> 
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
> 
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:10:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQ1P-0007nB-16; Thu, 09 Feb 2012 09:10: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 1RvQ1N-0007n6-C3
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:10:29 +0000
Received: from [85.158.139.83:6078] by server-4.bemta-5.messagelabs.com id
	92/DA-28576-48D833F4; Thu, 09 Feb 2012 09:10:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328778626!6996416!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21911 invoked from network); 9 Feb 2012 09:10:27 -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;
	9 Feb 2012 09:10:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:10:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:10:26 +0000
Message-ID: <1328778625.6133.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Thu, 9 Feb 2012 09:10:25 +0000
In-Reply-To: <6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 15:01 +0000, John McDermott CIV wrote:
> Ian,
> 
> Agreed; this warning is very annoying. The problem is in several
> files, like a design pattern issue. So far it has popped up in
> fbfront.c, blkfront.c, and netfront.c, but the code is nice clean
> code, so the problem is very regular. We are running Fedora 16 and Xen
> 4.1.2.
> 
> ----
> 
> [mc@xenpro3 ~]$ gcc --version
> gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1)
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> ----
> 
> Here is an example of what I have been doing to get rid of the warning:
> 
> ----
> [mc@xenpro3 xenon]$ hg diff extras/mini-os/fbfront.c
> diff -r 8cfe801d065d extras/mini-os/fbfront.c
> --- a/extras/mini-os/fbfront.c	Mon Feb 06 08:37:59 2012 -0500
> +++ b/extras/mini-os/fbfront.c	Wed Feb 08 09:52:06 2012 -0500
> @@ -142,6 +142,9 @@
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    if (message) {
> +	printk("Abort transaction %s", message);
> +    }

I'd be tempted to make these unconditional and then fixup any resultant
"variable message is used but not initialised" type warnings since I
expect we should always have a reason for getting to this particular
point so it would be a bug not to set message at that time.

Would you mind resending this with a Signed-off-by as per
http://wiki.xen.org/wiki/SubmittingXenPatches ? From what you say above
I guess you also have similar fixes to the other drivers, I think it
would be fine to bundle all those similar fixes into a single patch.

Thanks, 
Ian.
>      goto error;
>  
>  done:
> @@ -503,6 +506,9 @@
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    if (message) {
> +	printk("Abort transaction %s", message);
> +    }
>      goto error;
>  
> 
>  done:
> [mc@xenpro3 xenon]$
> ----
> 
> On Feb 8, 2012, at 9:15 AM, Ian Campbell wrote:
> 
> > On Mon, 2012-02-06 at 19:05 +0000, John McDermott CIV wrote:
> >> Xen Developers,
> >> 
> >> FWIW, in trying to compile mini-os on Xen 4.1.2, I get a variable set
> >> but not used warning for variable 'message' in function init_kbdfront.
> >> (Looks like another one just like it, in function init_fbfront, from
> >> the same file.) My source won't compile with these warnings. I could
> >> not find a patch for this in xen-4.1-testing.hg Xenbits.
> > 
> > This new, enabled by default, compiler warning is very annoying, even
> > though it happens to be correct. Which distro has done it? (or maybe
> > it's just new enough gcc which is to blame).
> > 
> >> It looks like a conditional printk got left out after the label
> >> 'abort_transaction'. I don't understand fbfront.c well enough to
> >> suggest a patch. Its low priority for me, because I am going to stick
> >> some plausible code in there for now.
> > 
> > I think an unconditional printk including the %s and message is all
> > which is required here. If you've got some plausible code you may as
> > well post it.
> > 
> > Thanks,
> > Ian.
> > 
> >> 
> >> Sincerely,
> >> 
> >> John
> >> ----
> >> What is the formal meaning of the one-line program
> >> #include "/dev/tty"
> >> 
> >> J.P. McDermott			building 12
> >> Code 5542			john.mcdermott@nrl.navy.mil
> >> Naval Research Laboratory	voice: +1 202.404.8301
> >> Washington, DC 20375, US	fax:   +1 202.404.7942
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> 
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
> 
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:13:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ40-0007uT-Jp; Thu, 09 Feb 2012 09:13: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 1RvQ3y-0007uL-Qc
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:13:11 +0000
Received: from [85.158.139.83:29395] by server-11.bemta-5.messagelabs.com id
	F4/94-13907-42E833F4; Thu, 09 Feb 2012 09:13:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328778787!14260109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18498 invoked from network); 9 Feb 2012 09:13:07 -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;
	9 Feb 2012 09:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:13:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:13:07 +0000
Message-ID: <1328778785.6133.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:13:05 +0000
In-Reply-To: <329b3c94c618addb1e80.1328251799@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<329b3c94c618addb1e80.1328251799@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V3] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:49 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 329b3c94c618addb1e802cebc7fe23b12b432398
> # Parent  636da26c40d37b84a93b6a6c3881b2fccc768aa2
> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 
> Implement QMP stop and resume functionality and split
> device model save into 3 parts:
>  suspend_dm(domid)
>  save_dm(domid, fd)
>  resume_dm(domid)
> 
> Integrate Device model suspend into suspend_common_callback
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -488,6 +488,54 @@ static int libxl__domain_suspend_common_
>      return rc ? 0 : 1;
>  }
>  
> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int ret = 0;
> +    const char *filename = libxl__device_model_savefile(gc, domid);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +                   "Saving device model state to %s", filename);
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        /* Save DM state into filename */
> +        ret = libxl__qmp_save(gc, domid, filename);
> +        if (ret)
> +            unlink(filename);
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return ret;
> +}
> +
> +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        libxl__qemu_traditional_cmd(gc, domid, "continue");
> +        libxl__wait_for_device_model(gc, domid, "running", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_resume(gc, domid))
> +            return ERROR_FAIL;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  static int libxl__domain_suspend_common_callback(void *data)
>  {
>      struct suspendinfo *si = data;
> @@ -517,7 +565,7 @@ static int libxl__domain_suspend_common_
>              return 0;
>          }
>          si->guest_responded = 1;
> -        return 1;
> +        goto guest_suspended;
>      }
>  
>      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
> @@ -595,7 +643,7 @@ static int libxl__domain_suspend_common_
>              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
>              if (shutdown_reason == SHUTDOWN_suspend) {
>                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
> -                return 1;
> +                goto guest_suspended;
>              }
>          }
>  
> @@ -604,6 +652,17 @@ static int libxl__domain_suspend_common_
>  
>      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
>      return 0;
> +
> + guest_suspended:
> +    if (si->hvm) {
> +        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
> +        if (ret) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "libxl__domain_suspend_device_model failed ret=%d", ret);
> +            return 0;
> +        }
> +    }
> +    return 1;
>  }
>  
>  static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> @@ -768,23 +827,6 @@ int libxl__domain_save_device_model(libx
>      struct stat st;
>      uint32_t qemu_state_len;
>  
> -    switch (libxl__device_model_version_running(gc, domid)) {
> -    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> -                   "Saving device model state to %s", filename);
> -        libxl__qemu_traditional_cmd(gc, domid, "save");
> -        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> -        break;
> -    }
> -    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -        ret = libxl__qmp_save(gc, domid, (char *)filename);
> -        if (ret)
> -            goto out;
> -        break;
> -    default:
> -        return ERROR_INVAL;
> -    }
> -
>      if (stat(filename, &st) < 0)
>      {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
> diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
> @@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
>                                           libxl_domain_type type,
>                                           int live, int debug);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
> +_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
> +_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
>  _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
>  
> @@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
>  _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
>  _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
>                                 libxl_device_pci *pcidev);
> +/* Suspend QEMU. */
> +_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
> +/* Resume QEMU. */
> +_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);
>  /* close and free the QMP handler */
> diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_qmp.c
> --- a/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -802,6 +802,38 @@ out:
>      return rc;
>  }
>  
> +int libxl__qmp_stop(libxl__gc *gc, int domid)
> +{
> +    libxl__qmp_handler *qmp = NULL;
> +    int rc = 0;
> +
> +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    if (!qmp)
> +        return ERROR_FAIL;
> +
> +    rc = qmp_synchronous_send(qmp, "stop", NULL,
> +                              NULL, NULL, qmp->timeout);
> +
> +    libxl__qmp_close(qmp);
> +    return rc;
> +}
> +
> +int libxl__qmp_resume(libxl__gc *gc, int domid)
> +{
> +    libxl__qmp_handler *qmp = NULL;
> +    int rc = 0;
> +
> +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    if (!qmp)
> +        return ERROR_FAIL;
> +
> +    rc = qmp_synchronous_send(qmp, "cont", NULL,
> +                              NULL, NULL, qmp->timeout);
> +
> +    libxl__qmp_close(qmp);
> +    return rc;
> +}
> +
>  int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:13:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ40-0007uT-Jp; Thu, 09 Feb 2012 09:13: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 1RvQ3y-0007uL-Qc
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:13:11 +0000
Received: from [85.158.139.83:29395] by server-11.bemta-5.messagelabs.com id
	F4/94-13907-42E833F4; Thu, 09 Feb 2012 09:13:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328778787!14260109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18498 invoked from network); 9 Feb 2012 09:13:07 -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;
	9 Feb 2012 09:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:13:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:13:07 +0000
Message-ID: <1328778785.6133.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:13:05 +0000
In-Reply-To: <329b3c94c618addb1e80.1328251799@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<329b3c94c618addb1e80.1328251799@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6 V3] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:49 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 329b3c94c618addb1e802cebc7fe23b12b432398
> # Parent  636da26c40d37b84a93b6a6c3881b2fccc768aa2
> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 
> Implement QMP stop and resume functionality and split
> device model save into 3 parts:
>  suspend_dm(domid)
>  save_dm(domid, fd)
>  resume_dm(domid)
> 
> Integrate Device model suspend into suspend_common_callback
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -488,6 +488,54 @@ static int libxl__domain_suspend_common_
>      return rc ? 0 : 1;
>  }
>  
> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int ret = 0;
> +    const char *filename = libxl__device_model_savefile(gc, domid);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +                   "Saving device model state to %s", filename);
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        /* Save DM state into filename */
> +        ret = libxl__qmp_save(gc, domid, filename);
> +        if (ret)
> +            unlink(filename);
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return ret;
> +}
> +
> +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        libxl__qemu_traditional_cmd(gc, domid, "continue");
> +        libxl__wait_for_device_model(gc, domid, "running", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_resume(gc, domid))
> +            return ERROR_FAIL;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  static int libxl__domain_suspend_common_callback(void *data)
>  {
>      struct suspendinfo *si = data;
> @@ -517,7 +565,7 @@ static int libxl__domain_suspend_common_
>              return 0;
>          }
>          si->guest_responded = 1;
> -        return 1;
> +        goto guest_suspended;
>      }
>  
>      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
> @@ -595,7 +643,7 @@ static int libxl__domain_suspend_common_
>              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
>              if (shutdown_reason == SHUTDOWN_suspend) {
>                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
> -                return 1;
> +                goto guest_suspended;
>              }
>          }
>  
> @@ -604,6 +652,17 @@ static int libxl__domain_suspend_common_
>  
>      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
>      return 0;
> +
> + guest_suspended:
> +    if (si->hvm) {
> +        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
> +        if (ret) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "libxl__domain_suspend_device_model failed ret=%d", ret);
> +            return 0;
> +        }
> +    }
> +    return 1;
>  }
>  
>  static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
> @@ -768,23 +827,6 @@ int libxl__domain_save_device_model(libx
>      struct stat st;
>      uint32_t qemu_state_len;
>  
> -    switch (libxl__device_model_version_running(gc, domid)) {
> -    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> -                   "Saving device model state to %s", filename);
> -        libxl__qemu_traditional_cmd(gc, domid, "save");
> -        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> -        break;
> -    }
> -    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -        ret = libxl__qmp_save(gc, domid, (char *)filename);
> -        if (ret)
> -            goto out;
> -        break;
> -    default:
> -        return ERROR_INVAL;
> -    }
> -
>      if (stat(filename, &st) < 0)
>      {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
> diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl_internal.h	Thu Feb 02 22:46:33 2012 -0800
> @@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
>                                           libxl_domain_type type,
>                                           int live, int debug);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
> +_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
> +_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
>  _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
>  
> @@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
>  _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
>  _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
>                                 libxl_device_pci *pcidev);
> +/* Suspend QEMU. */
> +_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
> +/* Resume QEMU. */
> +_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);
>  /* close and free the QMP handler */
> diff -r 636da26c40d3 -r 329b3c94c618 tools/libxl/libxl_qmp.c
> --- a/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl_qmp.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -802,6 +802,38 @@ out:
>      return rc;
>  }
>  
> +int libxl__qmp_stop(libxl__gc *gc, int domid)
> +{
> +    libxl__qmp_handler *qmp = NULL;
> +    int rc = 0;
> +
> +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    if (!qmp)
> +        return ERROR_FAIL;
> +
> +    rc = qmp_synchronous_send(qmp, "stop", NULL,
> +                              NULL, NULL, qmp->timeout);
> +
> +    libxl__qmp_close(qmp);
> +    return rc;
> +}
> +
> +int libxl__qmp_resume(libxl__gc *gc, int domid)
> +{
> +    libxl__qmp_handler *qmp = NULL;
> +    int rc = 0;
> +
> +    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    if (!qmp)
> +        return ERROR_FAIL;
> +
> +    rc = qmp_synchronous_send(qmp, "cont", NULL,
> +                              NULL, NULL, qmp->timeout);
> +
> +    libxl__qmp_close(qmp);
> +    return rc;
> +}
> +
>  int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:16:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ6a-00085U-5t; Thu, 09 Feb 2012 09:15:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvQ6Y-00085C-5y
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:15:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328778922!52180446!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8570 invoked from network); 9 Feb 2012 09:15:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 09:15:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 09:15:45 +0000
Message-Id: <4F339CCF0200007800071D40@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 09:15:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
	<4F2C158C02000078000711D4@nat28.tlf.novell.com>
	<6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
In-Reply-To: <6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 23:00, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:
> 
>> > On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
>> >
>> > However, if this is the rule, both types of "max ring size" values
>> > are "in effect" even if a back-end does not provide them both.  So
>> > how do you resolve the conflict?  A fully interoperable front should
>> > allocate the largest possible ring and advertise that size through
>> > both mechanisms in a fully consistent manner. That's what I was
>> > trying to indicate by writing the spec this way.
>> 
>> Hmm, I would think a fully compatible frontend should bail (revert to
>> single page ring) on inconsistent max-ring-pages and
>> max-ring-page-order, if both are provided by the backend. The limit
>> for ring-pages should always be max-ring-pages, while the one for
>> ring-page-order should always be max-ring-page-order. Any mixture
>> is an error, unless both values are consistent with one another.
>> 
>> Jan
> 
> Mandating that a front-end publish inconsistent values to the
> XenStore would be a mistake.  Having the front-end only publish the
> set of nodes that are recognized by the back-end just adds code
> complexity with no associated increase in functionality.  You
> actually would lose the ability to tell that the driver supports
> both schemes.
> 
> To clarify what I mean by that, consider the current state of
> back-ends in the world.  They fall into 1 of 4 camps:
> 
>  1. No multi-page ring support
>  2. "Citrix style" multi-page ring support.
>  3. "Red Hat style" multi-page ring support.
>  4. "Both styles" multi-page ring support.
> 
> In cases 1-3, one or both of the max-ring-page* nodes is not present.
> Per the currently proposed spec, this means that these nodes have
> their default values.  You seem to be advocating that the front-end
> write the default values into its corresponding node.  For cases 2
> and 3, this would lead to contradictory values in the XenStore (e.g.
> ring-page-order=0 and ring-pages=4).  This will not confuse the
> back-end, but could confuse a human.

No, that's not what I intended to propose. Instead, I'd see the
frontend write consistent values (and best always write both node
flavors) if at least one of the protocols is supported by the backend.

I'm only suggesting that the frontend should not use either multi-
page rings at all if it finds both backend node flavors present yet
having inconsistent values (i.e. absence of either [but not both]
values does *not* count as inconsistent, and hence a single absent
node not implicitly assuming its default value).

> For case 4, the back-end must publish both node types even though
> the front-end may not look at both.  Since we can't avoid having
> both nodes, it seems reasonable to allow a front-end to publish
> them both too.  It also avoids the additional logic to test against
> back-end node presence.
> 
> With all that said, I believe the spec should indicate that a
> fully-interoperable implementation should publish both nodes with
> values that match the allocated ring size.  The tolerance level for
> a back-end publishing inconsistent nodes should be left to the
> implementation.

For the moment I decided to only have the frontend handle both
flavors in our implementation. That way, not question about
inconsistent values published by the backend can arise.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:16:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ6a-00085U-5t; Thu, 09 Feb 2012 09:15:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvQ6Y-00085C-5y
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:15:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328778922!52180446!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8570 invoked from network); 9 Feb 2012 09:15:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 09:15:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 09:15:45 +0000
Message-Id: <4F339CCF0200007800071D40@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 09:15:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
	<4F2C158C02000078000711D4@nat28.tlf.novell.com>
	<6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
In-Reply-To: <6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 23:00, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:
> 
>> > On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
>> >
>> > However, if this is the rule, both types of "max ring size" values
>> > are "in effect" even if a back-end does not provide them both.  So
>> > how do you resolve the conflict?  A fully interoperable front should
>> > allocate the largest possible ring and advertise that size through
>> > both mechanisms in a fully consistent manner. That's what I was
>> > trying to indicate by writing the spec this way.
>> 
>> Hmm, I would think a fully compatible frontend should bail (revert to
>> single page ring) on inconsistent max-ring-pages and
>> max-ring-page-order, if both are provided by the backend. The limit
>> for ring-pages should always be max-ring-pages, while the one for
>> ring-page-order should always be max-ring-page-order. Any mixture
>> is an error, unless both values are consistent with one another.
>> 
>> Jan
> 
> Mandating that a front-end publish inconsistent values to the
> XenStore would be a mistake.  Having the front-end only publish the
> set of nodes that are recognized by the back-end just adds code
> complexity with no associated increase in functionality.  You
> actually would lose the ability to tell that the driver supports
> both schemes.
> 
> To clarify what I mean by that, consider the current state of
> back-ends in the world.  They fall into 1 of 4 camps:
> 
>  1. No multi-page ring support
>  2. "Citrix style" multi-page ring support.
>  3. "Red Hat style" multi-page ring support.
>  4. "Both styles" multi-page ring support.
> 
> In cases 1-3, one or both of the max-ring-page* nodes is not present.
> Per the currently proposed spec, this means that these nodes have
> their default values.  You seem to be advocating that the front-end
> write the default values into its corresponding node.  For cases 2
> and 3, this would lead to contradictory values in the XenStore (e.g.
> ring-page-order=0 and ring-pages=4).  This will not confuse the
> back-end, but could confuse a human.

No, that's not what I intended to propose. Instead, I'd see the
frontend write consistent values (and best always write both node
flavors) if at least one of the protocols is supported by the backend.

I'm only suggesting that the frontend should not use either multi-
page rings at all if it finds both backend node flavors present yet
having inconsistent values (i.e. absence of either [but not both]
values does *not* count as inconsistent, and hence a single absent
node not implicitly assuming its default value).

> For case 4, the back-end must publish both node types even though
> the front-end may not look at both.  Since we can't avoid having
> both nodes, it seems reasonable to allow a front-end to publish
> them both too.  It also avoids the additional logic to test against
> back-end node presence.
> 
> With all that said, I believe the spec should indicate that a
> fully-interoperable implementation should publish both nodes with
> values that match the allocated ring size.  The tolerance level for
> a back-end publishing inconsistent nodes should be left to the
> implementation.

For the moment I decided to only have the frontend handle both
flavors in our implementation. That way, not question about
inconsistent values published by the backend can arise.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:16:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ6u-00087n-Ip; Thu, 09 Feb 2012 09:16:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQ6t-00086z-5q
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:16:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328778964!11129431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12606 invoked from network); 9 Feb 2012 09:16:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 09:16:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:16:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:16:03 +0000
Message-ID: <1328778962.6133.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:16:02 +0000
In-Reply-To: <f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
> # Parent  329b3c94c618addb1e802cebc7fe23b12b432398
> libxl: support suspend_cancel in domain_resume
> 
> Add an extra parameter to libxl_domain_resume indicating
> if the caller wishes to use the SUSPEND_CANCEL style
> resume instead of the normal resume.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>      return rc;
>  }
>  
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
>  {
>      GC_INIT(ctx);
>      int rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> -                "non-cooperative hvm domain %u", domid);
> -        rc = ERROR_NI;
> -        goto out;
> -    }
> -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> +    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xc_domain_resume failed for domain %u",
>                          domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        rc = libxl__domain_resume_device_model(gc, domid);
> +        if (rc) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "failed to resume device model for domain %u:%d",
> +                       domid, rc);
> +            goto out;
> +        }
> +    }
> +
>      if (!xs_resume_domain(ctx->xsh, domid)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xs_resume_domain failed for domain %u",
> diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> @@ -268,7 +268,12 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                            uint32_t domid, int fd);
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> +
> +/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> + *   If this parameter is true, use co-operative resume. The guest
> + *   must support this.
> + */
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
>          if (common_domname) {
>              libxl_domain_rename(ctx, domid, away_domname, common_domname);
>          }
> -        rc = libxl_domain_resume(ctx, domid);
> +        rc = libxl_domain_resume(ctx, domid, 1);

Previously this code would have been equivalent to passing 0 not 1. It
may be ok to change this but it should be separate. However I'm a bit
dubious about changing it without adding some code to detect if the
guest supports it. (I know libxl_domain_resume is currently broken for
the non-cooperative suspend case but we shouldn't paper over that)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:16:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ6u-00087n-Ip; Thu, 09 Feb 2012 09:16:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQ6t-00086z-5q
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:16:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328778964!11129431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12606 invoked from network); 9 Feb 2012 09:16:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 09:16:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:16:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:16:03 +0000
Message-ID: <1328778962.6133.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:16:02 +0000
In-Reply-To: <f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
> # Parent  329b3c94c618addb1e802cebc7fe23b12b432398
> libxl: support suspend_cancel in domain_resume
> 
> Add an extra parameter to libxl_domain_resume indicating
> if the caller wishes to use the SUSPEND_CANCEL style
> resume instead of the normal resume.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>      return rc;
>  }
>  
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
>  {
>      GC_INIT(ctx);
>      int rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> -                "non-cooperative hvm domain %u", domid);
> -        rc = ERROR_NI;
> -        goto out;
> -    }
> -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> +    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xc_domain_resume failed for domain %u",
>                          domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        rc = libxl__domain_resume_device_model(gc, domid);
> +        if (rc) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "failed to resume device model for domain %u:%d",
> +                       domid, rc);
> +            goto out;
> +        }
> +    }
> +
>      if (!xs_resume_domain(ctx->xsh, domid)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xs_resume_domain failed for domain %u",
> diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> @@ -268,7 +268,12 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                            uint32_t domid, int fd);
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> +
> +/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> + *   If this parameter is true, use co-operative resume. The guest
> + *   must support this.
> + */
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
>          if (common_domname) {
>              libxl_domain_rename(ctx, domid, away_domname, common_domname);
>          }
> -        rc = libxl_domain_resume(ctx, domid);
> +        rc = libxl_domain_resume(ctx, domid, 1);

Previously this code would have been equivalent to passing 0 not 1. It
may be ok to change this but it should be separate. However I'm a bit
dubious about changing it without adding some code to detect if the
guest supports it. (I know libxl_domain_resume is currently broken for
the non-cooperative suspend case but we shouldn't paper over that)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:17:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ81-0008IH-1N; Thu, 09 Feb 2012 09:17: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 1RvQ7z-0008HT-OI
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:17:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328779011!65111941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3153 invoked from network); 9 Feb 2012 09:16:51 -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;
	9 Feb 2012 09:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:17:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:17:13 +0000
Message-ID: <1328779031.6133.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:17:11 +0000
In-Reply-To: <62c4fd2fe9bbc2c283e3.1328251801@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<62c4fd2fe9bbc2c283e3.1328251801@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6 V3] libxl: refactor migrate_domain
 and generalize migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 62c4fd2fe9bbc2c283e3998d852317a48e9f9770
> # Parent  f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
> libxl: refactor migrate_domain and generalize migrate_receive
> 
> Refactor some tasks like establishing the migration channel,
> initial migration protocol exchange into separate functions,
> to facilitate re-use, when remus support is introduced. Also,
> make migrate_receive generic (instead of resorting to stdin and
> stdout as the file descriptors for communication).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r f853c88f0230 -r 62c4fd2fe9bb tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
>      exit(0);
>  }
>  
> +static pid_t create_migration_child(const char *rune, int *send_fd,
> +                                        int *recv_fd)
> +{
> +    int sendpipe[2], recvpipe[2];
> +    pid_t child = -1;
> +
> +    if (!rune || !send_fd || !recv_fd)
> +        return -1;
> +
> +    MUST( libxl_pipe(ctx, sendpipe) );
> +    MUST( libxl_pipe(ctx, recvpipe) );
> +
> +    child = libxl_fork(ctx);
> +    if (child==-1) exit(1);
> +
> +    if (!child) {
> +        dup2(sendpipe[0], 0);
> +        dup2(recvpipe[1], 1);
> +        close(sendpipe[0]); close(sendpipe[1]);
> +        close(recvpipe[0]); close(recvpipe[1]);
> +        execlp("sh","sh","-c",rune,(char*)0);
> +        perror("failed to exec sh");
> +        exit(-1);
> +    }
> +
> +    close(sendpipe[0]);
> +    close(recvpipe[1]);
> +    *send_fd = sendpipe[1];
> +    *recv_fd = recvpipe[0];
> +
> +    /* if receiver dies, we get an error and can clean up
> +       rather than just dying */
> +    signal(SIGPIPE, SIG_IGN);
> +
> +    return child;
> +}
> +
>  static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
>                                       const char *what, const char *rune) {
>      char buf[msgsz];
> @@ -2616,53 +2653,17 @@ static void migration_child_report(pid_t
>      migration_child = 0;
>  }
>  
> -static void migrate_domain(const char *domain_spec, const char *rune,
> -                           const char *override_config_file)
> +static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
> +                                uint8_t *config_data, int config_len,
> +                                const char *rune)
>  {
> -    pid_t child = -1;
> -    int rc;
> -    int sendpipe[2], recvpipe[2];
> -    int send_fd, recv_fd;
> -    libxl_domain_suspend_info suspinfo;
> -    char *away_domname;
> -    char rc_buf;
> -    uint8_t *config_data;
> -    int config_len;
> -
> -    save_domain_core_begin(domain_spec, override_config_file,
> -                           &config_data, &config_len);
> -
> -    if (!config_len) {
> -        fprintf(stderr, "No config file stored for running domain and "
> -                "none supplied - cannot migrate.\n");
> +    int rc = 0;
> +
> +    if (send_fd < 0 || recv_fd < 0) {
> +        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
>          exit(1);
>      }
>  
> -    MUST( libxl_pipe(ctx, sendpipe) );
> -    MUST( libxl_pipe(ctx, recvpipe) );
> -
> -    child = libxl_fork(ctx);
> -    if (child==-1) exit(1);
> -
> -    if (!child) {
> -        dup2(sendpipe[0], 0);
> -        dup2(recvpipe[1], 1);
> -        close(sendpipe[0]); close(sendpipe[1]);
> -        close(recvpipe[0]); close(recvpipe[1]);
> -        execlp("sh","sh","-c",rune,(char*)0);
> -        perror("failed to exec sh");
> -        exit(-1);
> -    }
> -
> -    close(sendpipe[0]);
> -    close(recvpipe[1]);
> -    send_fd = sendpipe[1];
> -    recv_fd = recvpipe[0];
> -
> -    signal(SIGPIPE, SIG_IGN);
> -    /* if receiver dies, we get an error and can clean up
> -       rather than just dying */
> -
>      rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
>                                     sizeof(migrate_receiver_banner)-1,
>                                     "banner", rune);
> @@ -2675,6 +2676,34 @@ static void migrate_domain(const char *d
>      save_domain_core_writeconfig(send_fd, "migration stream",
>                                   config_data, config_len);
>  
> +}
> +
> +static void migrate_domain(const char *domain_spec, const char *rune,
> +                           const char *override_config_file)
> +{
> +    pid_t child = -1;
> +    int rc;
> +    int send_fd = -1, recv_fd = -1;
> +    libxl_domain_suspend_info suspinfo;
> +    char *away_domname;
> +    char rc_buf;
> +    uint8_t *config_data;
> +    int config_len;
> +
> +    save_domain_core_begin(domain_spec, override_config_file,
> +                           &config_data, &config_len);
> +
> +    if (!config_len) {
> +        fprintf(stderr, "No config file stored for running domain and "
> +                "none supplied - cannot migrate.\n");
> +        exit(1);
> +    }
> +
> +    child = create_migration_child(rune, &send_fd, &recv_fd);
> +
> +    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
> +                        rune);
> +
>      xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
>  
>      memset(&suspinfo, 0, sizeof(suspinfo));
> @@ -2798,7 +2827,8 @@ static void core_dump_domain(const char 
>      if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
>  }
>  
> -static void migrate_receive(int debug, int daemonize, int monitor)
> +static void migrate_receive(int debug, int daemonize, int monitor,
> +                            int send_fd, int recv_fd)
>  {
>      int rc, rc2;
>      char rc_buf;
> @@ -2810,7 +2840,7 @@ static void migrate_receive(int debug, i
>  
>      fprintf(stderr, "migration target: Ready to receive domain.\n");
>  
> -    CHK_ERRNO( libxl_write_exactly(ctx, 1,
> +    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
>                                     migrate_receiver_banner,
>                                     sizeof(migrate_receiver_banner)-1,
>                                     "migration ack stream",
> @@ -2822,7 +2852,7 @@ static void migrate_receive(int debug, i
>      dom_info.monitor = monitor;
>      dom_info.paused = 1;
>      dom_info.restore_file = "incoming migration stream";
> -    dom_info.migrate_fd = 0; /* stdin */
> +    dom_info.migrate_fd = recv_fd;
>      dom_info.migration_domname_r = &migration_domname;
>      dom_info.no_incr_generationid = 1;
>  
> @@ -2836,13 +2866,13 @@ static void migrate_receive(int debug, i
>      fprintf(stderr, "migration target: Transfer complete,"
>              " requesting permission to start domain.\n");
>  
> -    rc = libxl_write_exactly(ctx, 1,
> +    rc = libxl_write_exactly(ctx, send_fd,
>                               migrate_receiver_ready,
>                               sizeof(migrate_receiver_ready),
>                               "migration ack stream", "ready message");
>      if (rc) exit(-rc);
>  
> -    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
> +    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
>                                     sizeof(migrate_permission_to_go),
>                                     "GO message", 0);
>      if (rc) goto perhaps_destroy_notify_rc;
> @@ -2861,7 +2891,7 @@ static void migrate_receive(int debug, i
>      rc = 0;
>  
>   perhaps_destroy_notify_rc:
> -    rc2 = libxl_write_exactly(ctx, 1,
> +    rc2 = libxl_write_exactly(ctx, send_fd,
>                                migrate_report, sizeof(migrate_report),
>                                "migration ack stream",
>                                "success/failure report");
> @@ -2869,7 +2899,7 @@ static void migrate_receive(int debug, i
>  
>      rc_buf = -rc;
>      assert(!!rc_buf == !!rc);
> -    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
> +    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
>                                "migration ack stream",
>                                "success/failure code");
>      if (rc2) exit(-ERROR_BADFAIL);
> @@ -2887,7 +2917,7 @@ static void migrate_receive(int debug, i
>          fprintf(stderr, "migration target: Cleanup OK, granting sender"
>                  " permission to resume.\n");
>  
> -        rc2 = libxl_write_exactly(ctx, 1,
> +        rc2 = libxl_write_exactly(ctx, send_fd,
>                                    migrate_permission_to_go,
>                                    sizeof(migrate_permission_to_go),
>                                    "migration ack stream",
> @@ -2983,7 +3013,9 @@ int main_migrate_receive(int argc, char 
>          help("migrate-receive");
>          return 2;
>      }
> -    migrate_receive(debug, daemonize, monitor);
> +    migrate_receive(debug, daemonize, monitor,
> +                    STDOUT_FILENO, STDIN_FILENO);
> +
>      return 0;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:17:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQ81-0008IH-1N; Thu, 09 Feb 2012 09:17: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 1RvQ7z-0008HT-OI
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:17:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328779011!65111941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3153 invoked from network); 9 Feb 2012 09:16:51 -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;
	9 Feb 2012 09:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10590985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:17:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:17:13 +0000
Message-ID: <1328779031.6133.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:17:11 +0000
In-Reply-To: <62c4fd2fe9bbc2c283e3.1328251801@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<62c4fd2fe9bbc2c283e3.1328251801@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6 V3] libxl: refactor migrate_domain
 and generalize migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 62c4fd2fe9bbc2c283e3998d852317a48e9f9770
> # Parent  f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
> libxl: refactor migrate_domain and generalize migrate_receive
> 
> Refactor some tasks like establishing the migration channel,
> initial migration protocol exchange into separate functions,
> to facilitate re-use, when remus support is introduced. Also,
> make migrate_receive generic (instead of resorting to stdin and
> stdout as the file descriptors for communication).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r f853c88f0230 -r 62c4fd2fe9bb tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
>      exit(0);
>  }
>  
> +static pid_t create_migration_child(const char *rune, int *send_fd,
> +                                        int *recv_fd)
> +{
> +    int sendpipe[2], recvpipe[2];
> +    pid_t child = -1;
> +
> +    if (!rune || !send_fd || !recv_fd)
> +        return -1;
> +
> +    MUST( libxl_pipe(ctx, sendpipe) );
> +    MUST( libxl_pipe(ctx, recvpipe) );
> +
> +    child = libxl_fork(ctx);
> +    if (child==-1) exit(1);
> +
> +    if (!child) {
> +        dup2(sendpipe[0], 0);
> +        dup2(recvpipe[1], 1);
> +        close(sendpipe[0]); close(sendpipe[1]);
> +        close(recvpipe[0]); close(recvpipe[1]);
> +        execlp("sh","sh","-c",rune,(char*)0);
> +        perror("failed to exec sh");
> +        exit(-1);
> +    }
> +
> +    close(sendpipe[0]);
> +    close(recvpipe[1]);
> +    *send_fd = sendpipe[1];
> +    *recv_fd = recvpipe[0];
> +
> +    /* if receiver dies, we get an error and can clean up
> +       rather than just dying */
> +    signal(SIGPIPE, SIG_IGN);
> +
> +    return child;
> +}
> +
>  static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
>                                       const char *what, const char *rune) {
>      char buf[msgsz];
> @@ -2616,53 +2653,17 @@ static void migration_child_report(pid_t
>      migration_child = 0;
>  }
>  
> -static void migrate_domain(const char *domain_spec, const char *rune,
> -                           const char *override_config_file)
> +static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
> +                                uint8_t *config_data, int config_len,
> +                                const char *rune)
>  {
> -    pid_t child = -1;
> -    int rc;
> -    int sendpipe[2], recvpipe[2];
> -    int send_fd, recv_fd;
> -    libxl_domain_suspend_info suspinfo;
> -    char *away_domname;
> -    char rc_buf;
> -    uint8_t *config_data;
> -    int config_len;
> -
> -    save_domain_core_begin(domain_spec, override_config_file,
> -                           &config_data, &config_len);
> -
> -    if (!config_len) {
> -        fprintf(stderr, "No config file stored for running domain and "
> -                "none supplied - cannot migrate.\n");
> +    int rc = 0;
> +
> +    if (send_fd < 0 || recv_fd < 0) {
> +        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
>          exit(1);
>      }
>  
> -    MUST( libxl_pipe(ctx, sendpipe) );
> -    MUST( libxl_pipe(ctx, recvpipe) );
> -
> -    child = libxl_fork(ctx);
> -    if (child==-1) exit(1);
> -
> -    if (!child) {
> -        dup2(sendpipe[0], 0);
> -        dup2(recvpipe[1], 1);
> -        close(sendpipe[0]); close(sendpipe[1]);
> -        close(recvpipe[0]); close(recvpipe[1]);
> -        execlp("sh","sh","-c",rune,(char*)0);
> -        perror("failed to exec sh");
> -        exit(-1);
> -    }
> -
> -    close(sendpipe[0]);
> -    close(recvpipe[1]);
> -    send_fd = sendpipe[1];
> -    recv_fd = recvpipe[0];
> -
> -    signal(SIGPIPE, SIG_IGN);
> -    /* if receiver dies, we get an error and can clean up
> -       rather than just dying */
> -
>      rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
>                                     sizeof(migrate_receiver_banner)-1,
>                                     "banner", rune);
> @@ -2675,6 +2676,34 @@ static void migrate_domain(const char *d
>      save_domain_core_writeconfig(send_fd, "migration stream",
>                                   config_data, config_len);
>  
> +}
> +
> +static void migrate_domain(const char *domain_spec, const char *rune,
> +                           const char *override_config_file)
> +{
> +    pid_t child = -1;
> +    int rc;
> +    int send_fd = -1, recv_fd = -1;
> +    libxl_domain_suspend_info suspinfo;
> +    char *away_domname;
> +    char rc_buf;
> +    uint8_t *config_data;
> +    int config_len;
> +
> +    save_domain_core_begin(domain_spec, override_config_file,
> +                           &config_data, &config_len);
> +
> +    if (!config_len) {
> +        fprintf(stderr, "No config file stored for running domain and "
> +                "none supplied - cannot migrate.\n");
> +        exit(1);
> +    }
> +
> +    child = create_migration_child(rune, &send_fd, &recv_fd);
> +
> +    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
> +                        rune);
> +
>      xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
>  
>      memset(&suspinfo, 0, sizeof(suspinfo));
> @@ -2798,7 +2827,8 @@ static void core_dump_domain(const char 
>      if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
>  }
>  
> -static void migrate_receive(int debug, int daemonize, int monitor)
> +static void migrate_receive(int debug, int daemonize, int monitor,
> +                            int send_fd, int recv_fd)
>  {
>      int rc, rc2;
>      char rc_buf;
> @@ -2810,7 +2840,7 @@ static void migrate_receive(int debug, i
>  
>      fprintf(stderr, "migration target: Ready to receive domain.\n");
>  
> -    CHK_ERRNO( libxl_write_exactly(ctx, 1,
> +    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
>                                     migrate_receiver_banner,
>                                     sizeof(migrate_receiver_banner)-1,
>                                     "migration ack stream",
> @@ -2822,7 +2852,7 @@ static void migrate_receive(int debug, i
>      dom_info.monitor = monitor;
>      dom_info.paused = 1;
>      dom_info.restore_file = "incoming migration stream";
> -    dom_info.migrate_fd = 0; /* stdin */
> +    dom_info.migrate_fd = recv_fd;
>      dom_info.migration_domname_r = &migration_domname;
>      dom_info.no_incr_generationid = 1;
>  
> @@ -2836,13 +2866,13 @@ static void migrate_receive(int debug, i
>      fprintf(stderr, "migration target: Transfer complete,"
>              " requesting permission to start domain.\n");
>  
> -    rc = libxl_write_exactly(ctx, 1,
> +    rc = libxl_write_exactly(ctx, send_fd,
>                               migrate_receiver_ready,
>                               sizeof(migrate_receiver_ready),
>                               "migration ack stream", "ready message");
>      if (rc) exit(-rc);
>  
> -    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
> +    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
>                                     sizeof(migrate_permission_to_go),
>                                     "GO message", 0);
>      if (rc) goto perhaps_destroy_notify_rc;
> @@ -2861,7 +2891,7 @@ static void migrate_receive(int debug, i
>      rc = 0;
>  
>   perhaps_destroy_notify_rc:
> -    rc2 = libxl_write_exactly(ctx, 1,
> +    rc2 = libxl_write_exactly(ctx, send_fd,
>                                migrate_report, sizeof(migrate_report),
>                                "migration ack stream",
>                                "success/failure report");
> @@ -2869,7 +2899,7 @@ static void migrate_receive(int debug, i
>  
>      rc_buf = -rc;
>      assert(!!rc_buf == !!rc);
> -    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
> +    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
>                                "migration ack stream",
>                                "success/failure code");
>      if (rc2) exit(-ERROR_BADFAIL);
> @@ -2887,7 +2917,7 @@ static void migrate_receive(int debug, i
>          fprintf(stderr, "migration target: Cleanup OK, granting sender"
>                  " permission to resume.\n");
>  
> -        rc2 = libxl_write_exactly(ctx, 1,
> +        rc2 = libxl_write_exactly(ctx, send_fd,
>                                    migrate_permission_to_go,
>                                    sizeof(migrate_permission_to_go),
>                                    "migration ack stream",
> @@ -2983,7 +3013,9 @@ int main_migrate_receive(int argc, char 
>          help("migrate-receive");
>          return 2;
>      }
> -    migrate_receive(debug, daemonize, monitor);
> +    migrate_receive(debug, daemonize, monitor,
> +                    STDOUT_FILENO, STDIN_FILENO);
> +
>      return 0;
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:18:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQ98-0008Tm-OB; Thu, 09 Feb 2012 09:18:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQ96-0008T3-Nb
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:18:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328779102!8417319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19443 invoked from network); 9 Feb 2012 09:18: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;
	9 Feb 2012 09:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:18:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:18:22 +0000
Message-ID: <1328779100.6133.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:18:20 +0000
In-Reply-To: <c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6 V3] libxl: resume instead of unpause
	on xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID c7abecc14cceb18140335ebe20faad826282cd1f
> # Parent  62c4fd2fe9bbc2c283e3998d852317a48e9f9770
> libxl: resume instead of unpause on xl save -c
> 
> The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
> So call libxl_domain_resume instead of libxl_domain_unpause, when taking
> a checkpoint of the domain (using xl save -c).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Ideally we would confirm that the guest supported checkpointing before
even attempting a "save -c" but lets assume for now that the user has
confirmed by out-of-band means that this is the case.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 62c4fd2fe9bb -r c7abecc14cce tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
>      close(fd);
>  
>      if (checkpoint)
> -        libxl_domain_unpause(ctx, domid);
> +        libxl_domain_resume(ctx, domid, 1);
>      else
>          libxl_domain_destroy(ctx, domid);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:18:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQ98-0008Tm-OB; Thu, 09 Feb 2012 09:18:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQ96-0008T3-Nb
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:18:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328779102!8417319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19443 invoked from network); 9 Feb 2012 09:18: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;
	9 Feb 2012 09:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:18:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:18:22 +0000
Message-ID: <1328779100.6133.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:18:20 +0000
In-Reply-To: <c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6 V3] libxl: resume instead of unpause
	on xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID c7abecc14cceb18140335ebe20faad826282cd1f
> # Parent  62c4fd2fe9bbc2c283e3998d852317a48e9f9770
> libxl: resume instead of unpause on xl save -c
> 
> The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
> So call libxl_domain_resume instead of libxl_domain_unpause, when taking
> a checkpoint of the domain (using xl save -c).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Ideally we would confirm that the guest supported checkpointing before
even attempting a "save -c" but lets assume for now that the user has
confirmed by out-of-band means that this is the case.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 62c4fd2fe9bb -r c7abecc14cce tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
>      close(fd);
>  
>      if (checkpoint)
> -        libxl_domain_unpause(ctx, domid);
> +        libxl_domain_resume(ctx, domid, 1);
>      else
>          libxl_domain_destroy(ctx, domid);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:20:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQAk-0000Is-8m; Thu, 09 Feb 2012 09:20:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQAj-0000I6-Jj
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:20:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328779203!14584312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10137 invoked from network); 9 Feb 2012 09:20:03 -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;
	9 Feb 2012 09:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:20:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:20:03 +0000
Message-ID: <1328779201.6133.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:20:01 +0000
In-Reply-To: <1328778962.6133.111.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
	<1328778962.6133.111.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 09:16 +0000, Ian Campbell wrote:
> On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1328251593 28800
> > # Node ID f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
> > # Parent  329b3c94c618addb1e802cebc7fe23b12b432398
> > libxl: support suspend_cancel in domain_resume
> > 
> > Add an extra parameter to libxl_domain_resume indicating
> > if the caller wishes to use the SUSPEND_CANCEL style
> > resume instead of the normal resume.
> > 
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > 
> > diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> > +++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> > @@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
> >      return rc;
> >  }
> >  
> > -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> > +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
> >  {
> >      GC_INIT(ctx);
> >      int rc = 0;
> >  
> > -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> > -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> > -                "non-cooperative hvm domain %u", domid);
> > -        rc = ERROR_NI;
> > -        goto out;
> > -    }
> > -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> > +    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                          "xc_domain_resume failed for domain %u",
> >                          domid);
> >          rc = ERROR_FAIL;
> >          goto out;
> >      }
> > +
> > +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> > +        rc = libxl__domain_resume_device_model(gc, domid);
> > +        if (rc) {
> > +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                       "failed to resume device model for domain %u:%d",
> > +                       domid, rc);
> > +            goto out;
> > +        }
> > +    }
> > +
> >      if (!xs_resume_domain(ctx->xsh, domid)) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                          "xs_resume_domain failed for domain %u",
> > diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> > +++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> > @@ -268,7 +268,12 @@ int libxl_domain_create_restore(libxl_ct
> >  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> >  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> >                            uint32_t domid, int fd);
> > -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> > +
> > +/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> > + *   If this parameter is true, use co-operative resume. The guest
> > + *   must support this.
> > + */
> > +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
> >  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> > diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> > @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
> >          if (common_domname) {
> >              libxl_domain_rename(ctx, domid, away_domname, common_domname);
> >          }
> > -        rc = libxl_domain_resume(ctx, domid);
> > +        rc = libxl_domain_resume(ctx, domid, 1);
> 
> Previously this code would have been equivalent to passing 0 not 1. It
> may be ok to change this but it should be separate. However I'm a bit
> dubious about changing it without adding some code to detect if the
> guest supports it. (I know libxl_domain_resume is currently broken for
> the non-cooperative suspend case but we shouldn't paper over that)

BTW the rest of the patch looked fine. If those two 1s had been 0s I
would have: Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:20:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQAk-0000Is-8m; Thu, 09 Feb 2012 09:20:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQAj-0000I6-Jj
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:20:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328779203!14584312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10137 invoked from network); 9 Feb 2012 09:20:03 -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;
	9 Feb 2012 09:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:20:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:20:03 +0000
Message-ID: <1328779201.6133.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 09:20:01 +0000
In-Reply-To: <1328778962.6133.111.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
	<1328778962.6133.111.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 09:16 +0000, Ian Campbell wrote:
> On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1328251593 28800
> > # Node ID f853c88f0230a2e9d2e1006a9cd220c4cd27e74d
> > # Parent  329b3c94c618addb1e802cebc7fe23b12b432398
> > libxl: support suspend_cancel in domain_resume
> > 
> > Add an extra parameter to libxl_domain_resume indicating
> > if the caller wishes to use the SUSPEND_CANCEL style
> > resume instead of the normal resume.
> > 
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > 
> > diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> > +++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> > @@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
> >      return rc;
> >  }
> >  
> > -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> > +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
> >  {
> >      GC_INIT(ctx);
> >      int rc = 0;
> >  
> > -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> > -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> > -                "non-cooperative hvm domain %u", domid);
> > -        rc = ERROR_NI;
> > -        goto out;
> > -    }
> > -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> > +    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                          "xc_domain_resume failed for domain %u",
> >                          domid);
> >          rc = ERROR_FAIL;
> >          goto out;
> >      }
> > +
> > +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> > +        rc = libxl__domain_resume_device_model(gc, domid);
> > +        if (rc) {
> > +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                       "failed to resume device model for domain %u:%d",
> > +                       domid, rc);
> > +            goto out;
> > +        }
> > +    }
> > +
> >      if (!xs_resume_domain(ctx->xsh, domid)) {
> >          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >                          "xs_resume_domain failed for domain %u",
> > diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> > +++ b/tools/libxl/libxl.h	Thu Feb 02 22:46:33 2012 -0800
> > @@ -268,7 +268,12 @@ int libxl_domain_create_restore(libxl_ct
> >  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> >  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> >                            uint32_t domid, int fd);
> > -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> > +
> > +/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> > + *   If this parameter is true, use co-operative resume. The guest
> > + *   must support this.
> > + */
> > +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
> >  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> > diff -r 329b3c94c618 -r f853c88f0230 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 02 22:46:33 2012 -0800
> > @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
> >          if (common_domname) {
> >              libxl_domain_rename(ctx, domid, away_domname, common_domname);
> >          }
> > -        rc = libxl_domain_resume(ctx, domid);
> > +        rc = libxl_domain_resume(ctx, domid, 1);
> 
> Previously this code would have been equivalent to passing 0 not 1. It
> may be ok to change this but it should be separate. However I'm a bit
> dubious about changing it without adding some code to detect if the
> guest supports it. (I know libxl_domain_resume is currently broken for
> the non-cooperative suspend case but we shouldn't paper over that)

BTW the rest of the patch looked fine. If those two 1s had been 0s I
would have: Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:25:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQFp-0000cm-1h; Thu, 09 Feb 2012 09:25:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvQFo-0000ca-0j
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:25:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328779517!10613850!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19048 invoked from network); 9 Feb 2012 09:25:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 09:25:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 09:25:16 +0000
Message-Id: <4F339F0A0200007800071D46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 09:25:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
	<4F3236C70200007800071AA1@nat28.tlf.novell.com>
	<493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
In-Reply-To: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:
> 
>>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>>> 
>>>>> NAK. No backwards incompatible changes allowed in public headers.
>>>> 
>>>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>>>> legacy
>>>> source compatibility.  After trying lots of things, testing the impact on an
>>>> existing blkfront
>>>> and blkback implementation, I think the best two options are:
>>>> 
>>>> 1. Version the header file and require consumers to declare the interface
>>>> version
>>>>     they are using.  If the version isn't declared, the default, legacy,
>>>> "version 1.0" will
>>>>     be in effect.
>>>> 
>>>>     Positives:   No change in or constant naming conventions.  Data
>>>> structures and
>>>>                         constants for new features are properly hidden from
>>>> legacy implementations.
>>>>     Negatives: Messy #ifdefs
>>> 
>>> We already have this. See use of
>>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>>> headers.
>> 
>> Hmm, I would think these should specifically not be used in the
>> io/ subtree - those aren't definitions of the interface to Xen, but
>> ones shared between the respective backends and frontends.
>> Each interface is (apart from its relying on the ring definitions)
>> entirely self contained.
>> 
>> Jan
> 
> 
> The versioning required allows a driver to declare, "I am compatible
> with any source compatibility breaking changes up to version X of
> the header file".  Declaring support for the latest version does
> not require that a driver implement the new extensions.  Just one
> constant needs to be renamed.  So I don't see this as really altering
> the interface between front and backends (i.e. it is not a "blkif2")

Sure. But pulling in header updates should not require *any* other
source changes, so long as __XEN_INTERFACE_VERSION__ isn't
bumped.

My point about not using __XEN_INTERFACE_VERSION__ under io/
is that these declare protocols that the hypervisor is completely
unaware of, whereas the constant really is meant to control
compatibility with hypervisor changes. In particular is this or any
other change to the protocols under io/ entirely unrelated to the
particular hypervisor version (and hence its interface revision).

It's also unclear to me why simply giving new constants new names
(instead of changing the meaning of existing ones) is such a big
deal - the most strait forward solution doubtlessly is not having
any conditionals in that header, and simply add new things with
new, unambiguous names.

Jan

> If the xen-compat.h behavior is that you can safely import the
> public headers so long as you do not bump __XEN_INTERFACE_VERSION__
> until after you have audited and adjusted for the #ifdef guarded
> changes in the header files, then that is exactly what is needed
> in blkif.h.
> 
> --
> Justin




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:25:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQFp-0000cm-1h; Thu, 09 Feb 2012 09:25:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvQFo-0000ca-0j
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:25:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328779517!10613850!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19048 invoked from network); 9 Feb 2012 09:25:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 09:25:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 09:25:16 +0000
Message-Id: <4F339F0A0200007800071D46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 09:25:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
	<4F3236C70200007800071AA1@nat28.tlf.novell.com>
	<493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
In-Reply-To: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:
> 
>>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>>> 
>>>>> NAK. No backwards incompatible changes allowed in public headers.
>>>> 
>>>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>>>> legacy
>>>> source compatibility.  After trying lots of things, testing the impact on an
>>>> existing blkfront
>>>> and blkback implementation, I think the best two options are:
>>>> 
>>>> 1. Version the header file and require consumers to declare the interface
>>>> version
>>>>     they are using.  If the version isn't declared, the default, legacy,
>>>> "version 1.0" will
>>>>     be in effect.
>>>> 
>>>>     Positives:   No change in or constant naming conventions.  Data
>>>> structures and
>>>>                         constants for new features are properly hidden from
>>>> legacy implementations.
>>>>     Negatives: Messy #ifdefs
>>> 
>>> We already have this. See use of
>>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>>> headers.
>> 
>> Hmm, I would think these should specifically not be used in the
>> io/ subtree - those aren't definitions of the interface to Xen, but
>> ones shared between the respective backends and frontends.
>> Each interface is (apart from its relying on the ring definitions)
>> entirely self contained.
>> 
>> Jan
> 
> 
> The versioning required allows a driver to declare, "I am compatible
> with any source compatibility breaking changes up to version X of
> the header file".  Declaring support for the latest version does
> not require that a driver implement the new extensions.  Just one
> constant needs to be renamed.  So I don't see this as really altering
> the interface between front and backends (i.e. it is not a "blkif2")

Sure. But pulling in header updates should not require *any* other
source changes, so long as __XEN_INTERFACE_VERSION__ isn't
bumped.

My point about not using __XEN_INTERFACE_VERSION__ under io/
is that these declare protocols that the hypervisor is completely
unaware of, whereas the constant really is meant to control
compatibility with hypervisor changes. In particular is this or any
other change to the protocols under io/ entirely unrelated to the
particular hypervisor version (and hence its interface revision).

It's also unclear to me why simply giving new constants new names
(instead of changing the meaning of existing ones) is such a big
deal - the most strait forward solution doubtlessly is not having
any conditionals in that header, and simply add new things with
new, unambiguous names.

Jan

> If the xen-compat.h behavior is that you can safely import the
> public headers so long as you do not bump __XEN_INTERFACE_VERSION__
> until after you have audited and adjusted for the #ifdef guarded
> changes in the header files, then that is exactly what is needed
> in blkif.h.
> 
> --
> Justin




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:30:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQK9-0000mr-R5; Thu, 09 Feb 2012 09:29: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 1RvQK8-0000md-KC
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:29:52 +0000
Received: from [85.158.139.83:9750] by server-11.bemta-5.messagelabs.com id
	AB/61-13907-F02933F4; Thu, 09 Feb 2012 09:29:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328779789!14309346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8540 invoked from network); 9 Feb 2012 09:29:49 -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;
	9 Feb 2012 09:29:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:29:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:29:49 +0000
Message-ID: <1328779787.6133.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:29:47 +0000
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 05:24 +0000, Justin T. Gibbs wrote:
> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.  I assembled
> this information by reviewing xend, various versions of the Linux
> blkif drivers, fixing bugs in the FreeBSD blkfront driver, and
> writing and testing a blkback driver for FreeBSD.
> 
> Even with this experience, given this interface was previously only
> documented in source code, I'm sure there are mistakes or ommissions
> in what I've done here.  Corrections welcome.

Thanks very much for doing this Justin.

Ian.

> All but the last patch in the series is source compatible with
> existing drivers.  This final patch adds FreeBSD's extension to
> allow an I/O to span multiple ring entries.  The number of outstanding
> requests, and the max I/O size and number of segments per request,
> can all be negotiated.  Drivers offering this extension are backwards
> compatible with existing drivers, but the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has been changed to reflect the new
> limit of 255.  A global replacement of BLKIF_MAX_SEGMENTS_PER_REQUEST
> with BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK is all that's required to
> adjust drivers without the extension to this header change.
> 
> --
> Justin
> 
>  xen/include/public/io/blkif.h |    9 +-
>  xen/include/public/io/blkif.h |  305 ++++++++++++++++++++++++++++++++++-------
>  xen/include/public/io/blkif.h |   22 +++
>  xen/include/public/io/blkif.h |  101 +++++++++++-
>  xen/include/public/io/blkif.h |  106 ++++++++++++++-
>  5 files changed, 466 insertions(+), 77 deletions(-)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:30:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQK9-0000mr-R5; Thu, 09 Feb 2012 09:29: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 1RvQK8-0000md-KC
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:29:52 +0000
Received: from [85.158.139.83:9750] by server-11.bemta-5.messagelabs.com id
	AB/61-13907-F02933F4; Thu, 09 Feb 2012 09:29:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328779789!14309346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8540 invoked from network); 9 Feb 2012 09:29:49 -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;
	9 Feb 2012 09:29:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:29:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:29:49 +0000
Message-ID: <1328779787.6133.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:29:47 +0000
In-Reply-To: <patchbomb.1328246658@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 05:24 +0000, Justin T. Gibbs wrote:
> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.  I assembled
> this information by reviewing xend, various versions of the Linux
> blkif drivers, fixing bugs in the FreeBSD blkfront driver, and
> writing and testing a blkback driver for FreeBSD.
> 
> Even with this experience, given this interface was previously only
> documented in source code, I'm sure there are mistakes or ommissions
> in what I've done here.  Corrections welcome.

Thanks very much for doing this Justin.

Ian.

> All but the last patch in the series is source compatible with
> existing drivers.  This final patch adds FreeBSD's extension to
> allow an I/O to span multiple ring entries.  The number of outstanding
> requests, and the max I/O size and number of segments per request,
> can all be negotiated.  Drivers offering this extension are backwards
> compatible with existing drivers, but the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has been changed to reflect the new
> limit of 255.  A global replacement of BLKIF_MAX_SEGMENTS_PER_REQUEST
> with BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK is all that's required to
> adjust drivers without the extension to this header change.
> 
> --
> Justin
> 
>  xen/include/public/io/blkif.h |    9 +-
>  xen/include/public/io/blkif.h |  305 ++++++++++++++++++++++++++++++++++-------
>  xen/include/public/io/blkif.h |   22 +++
>  xen/include/public/io/blkif.h |  101 +++++++++++-
>  xen/include/public/io/blkif.h |  106 ++++++++++++++-
>  5 files changed, 466 insertions(+), 77 deletions(-)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQKz-0000ro-Aw; Thu, 09 Feb 2012 09:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQKx-0000rH-Co
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328779837!15946028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 9 Feb 2012 09:30:37 -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;
	9 Feb 2012 09:30:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:30:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:30:37 +0000
Message-ID: <1328779835.6133.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:30:35 +0000
In-Reply-To: <a56382286b6789e407f6.1328246659@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a56382286b6789e407f6.1328246659@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blkif.h: Miscelaneous style fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 05:24 +0000, Justin T. Gibbs wrote:
> xen/include/public/io/blkif.h |  9 ++++-----
>  1 files changed, 4 insertions(+), 5 deletions(-)
> 
> 
>   o Remove trailing whitespace.
>   o Remove a blank line so that a comment block is adjacent to the
>     code it documents.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQKz-0000ro-Aw; Thu, 09 Feb 2012 09:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQKx-0000rH-Co
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328779837!15946028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 9 Feb 2012 09:30:37 -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;
	9 Feb 2012 09:30:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591338"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:30:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:30:37 +0000
Message-ID: <1328779835.6133.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:30:35 +0000
In-Reply-To: <a56382286b6789e407f6.1328246659@ns1.eng.sldomain.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a56382286b6789e407f6.1328246659@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 5] blkif.h: Miscelaneous style fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 05:24 +0000, Justin T. Gibbs wrote:
> xen/include/public/io/blkif.h |  9 ++++-----
>  1 files changed, 4 insertions(+), 5 deletions(-)
> 
> 
>   o Remove trailing whitespace.
>   o Remove a blank line so that a comment block is adjacent to the
>     code it documents.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:37:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQR1-0001F5-Pc; Thu, 09 Feb 2012 09:36:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQR0-0001Ez-1W
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:36:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328780211!9901715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20006 invoked from network); 9 Feb 2012 09:36:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 09:36:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:36:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:36:51 +0000
Message-ID: <1328780209.6133.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:36:49 +0000
In-Reply-To: <0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
	<20273.25747.542056.575794@mariner.uk.xensource.com>
	<0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 23:24 +0000, Justin T. Gibbs wrote:
> On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:
> 
> > Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
> >>  o Document the XenBus nodes used in this protocol
> > 
> > Awesome.  But I don't think all of these are really supposed to be
> > part of the guest interface, so you should probably mention which ones
> > are.
> > 
> > For example,
> > 
> >> + * params
> >> + *      Values:         string
> > 
> > this is not intended for use by guests and they should not look at it.
> 
> Guests can export back-end devices.  Here at Spectra we do this all the
> time. :-)

I think Ian meant "guest" in the sense of "frontend", while a backend,
even one running in a driver domain, would  be considered some sort of
service domain rather than a "guest". IOW a "guest" is the purpose for
which you are virtualising, while other domains and just part of the
platform

I admit the terminology is not terribly well defined though.

> It would be hard to implement a blkback driver without this information.
> The comment at the top of your email implies you're okay with it being
> in this file, but that I should mark "local-end use only" nodes?

I think that makes sense, "back-end only" or perhaps some allusion to it
being part of the tools->blkback configuration might express it better?

> > 
> >> + * virtual-device
> >> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> > 
> > This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> > this also encoded in the device path in xenstore ?
> 
> It would appear so.  Should this path naming convention be mandated by
> this file?  Since "virtual-device" exists, it seems that front-ends should
> read it, not parse the path, to determine this information.

This seems sensible and matches the actual behaviour of, at least, the
Linux frontend.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:37:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQR1-0001F5-Pc; Thu, 09 Feb 2012 09:36:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQR0-0001Ez-1W
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:36:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328780211!9901715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20006 invoked from network); 9 Feb 2012 09:36:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 09:36:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:36:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:36:51 +0000
Message-ID: <1328780209.6133.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:36:49 +0000
In-Reply-To: <0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
	<20273.25747.542056.575794@mariner.uk.xensource.com>
	<0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 23:24 +0000, Justin T. Gibbs wrote:
> On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:
> 
> > Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
> >>  o Document the XenBus nodes used in this protocol
> > 
> > Awesome.  But I don't think all of these are really supposed to be
> > part of the guest interface, so you should probably mention which ones
> > are.
> > 
> > For example,
> > 
> >> + * params
> >> + *      Values:         string
> > 
> > this is not intended for use by guests and they should not look at it.
> 
> Guests can export back-end devices.  Here at Spectra we do this all the
> time. :-)

I think Ian meant "guest" in the sense of "frontend", while a backend,
even one running in a driver domain, would  be considered some sort of
service domain rather than a "guest". IOW a "guest" is the purpose for
which you are virtualising, while other domains and just part of the
platform

I admit the terminology is not terribly well defined though.

> It would be hard to implement a blkback driver without this information.
> The comment at the top of your email implies you're okay with it being
> in this file, but that I should mark "local-end use only" nodes?

I think that makes sense, "back-end only" or perhaps some allusion to it
being part of the tools->blkback configuration might express it better?

> > 
> >> + * virtual-device
> >> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> > 
> > This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> > this also encoded in the device path in xenstore ?
> 
> It would appear so.  Should this path naming convention be mandated by
> this file?  Since "virtual-device" exists, it seems that front-ends should
> read it, not parse the path, to determine this information.

This seems sensible and matches the actual behaviour of, at least, the
Linux frontend.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:48:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQbp-0001VZ-W5; Thu, 09 Feb 2012 09:48:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQbo-0001Ug-5f
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:48:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328780882!12578545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25524 invoked from network); 9 Feb 2012 09:48:02 -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;
	9 Feb 2012 09:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:46:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:46:59 +0000
Message-ID: <1328780817.6133.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Justin Gibbs <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:46:57 +0000
In-Reply-To: <AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
	<AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 15:49 +0000, Justin Gibbs wrote:
> On Feb 3, 2012, at 6:31 AM, Jan Beulich wrote:
> 
> >>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> > 
> > These being mostly meaningless to non-Linux, I don't think they
> > belong here.
> > 
> > Jan
> 
> [blkif major number #defines deleted]
> 
> Front and backends must use some common convention for communicating this
> virtual device mapping.  Since Linux was the first Dom0, all blkif drivers that I'm
> aware of, regardless of OS platform, reference the Linux values.

My understanding was that for BSD guests folks generally use the ability
to use a raw number as the disk spec (as referred to by the last
paragraph of "Configuration file syntax" in docs/misc/vbd-interface.txt.
However if you tell me that isn't the case in practice I'd be quite
prepared to believe you ;-)

> The mapping really only matters for HVM guests and the hand-off between a
> QEMU emulated device and the PV driver.  To avoid confusion (e.g. name of
> root mount device, device names in fstab), the PV drivers export alias devices named
> to match the devices QEMU emulates.  The only way to do this successfully is to
> know the major number scheme used by  Dom0/QEMU.

QEMU emulates primary and secondary IDE master+slave, it has no concept
of a major or minor number. Why does the dom0 numbering scheme matter?
(Does this relate to the old, or possibly current, xend misbehaviour of
stat()ing the dom0 device while creating a domain?)

On Linux we treat d0-d3 (however they are specified) as aliasing those 4
IDE devices (although we don't actual present alias devices but instead
use UUID or LABEL based fstab etc).

Whatever non-Linux does for weird compatibility reasons here I think the
right place to document it would be in docs/misc/vbd-interface.txt
following the precedent of the "Notes on Linux as a guest" in that
document.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:48:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQbp-0001VZ-W5; Thu, 09 Feb 2012 09:48:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvQbo-0001Ug-5f
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:48:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328780882!12578545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25524 invoked from network); 9 Feb 2012 09:48:02 -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;
	9 Feb 2012 09:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:46:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:46:59 +0000
Message-ID: <1328780817.6133.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Justin Gibbs <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:46:57 +0000
In-Reply-To: <AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
	<AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 15:49 +0000, Justin Gibbs wrote:
> On Feb 3, 2012, at 6:31 AM, Jan Beulich wrote:
> 
> >>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> > 
> > These being mostly meaningless to non-Linux, I don't think they
> > belong here.
> > 
> > Jan
> 
> [blkif major number #defines deleted]
> 
> Front and backends must use some common convention for communicating this
> virtual device mapping.  Since Linux was the first Dom0, all blkif drivers that I'm
> aware of, regardless of OS platform, reference the Linux values.

My understanding was that for BSD guests folks generally use the ability
to use a raw number as the disk spec (as referred to by the last
paragraph of "Configuration file syntax" in docs/misc/vbd-interface.txt.
However if you tell me that isn't the case in practice I'd be quite
prepared to believe you ;-)

> The mapping really only matters for HVM guests and the hand-off between a
> QEMU emulated device and the PV driver.  To avoid confusion (e.g. name of
> root mount device, device names in fstab), the PV drivers export alias devices named
> to match the devices QEMU emulates.  The only way to do this successfully is to
> know the major number scheme used by  Dom0/QEMU.

QEMU emulates primary and secondary IDE master+slave, it has no concept
of a major or minor number. Why does the dom0 numbering scheme matter?
(Does this relate to the old, or possibly current, xend misbehaviour of
stat()ing the dom0 device while creating a domain?)

On Linux we treat d0-d3 (however they are specified) as aliasing those 4
IDE devices (although we don't actual present alias devices but instead
use UUID or LABEL based fstab etc).

Whatever non-Linux does for weird compatibility reasons here I think the
right place to document it would be in docs/misc/vbd-interface.txt
following the precedent of the "Notes on Linux as a guest" in that
document.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:48:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQbz-0001Wp-Hr; Thu, 09 Feb 2012 09:48: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 1RvQby-0001Wc-4z
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:48:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328780764!52007370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11683 invoked from network); 9 Feb 2012 09:46:04 -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;
	9 Feb 2012 09:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:48:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:48:17 +0000
Message-ID: <1328780895.6133.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Justin Gibbs <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:48:15 +0000
In-Reply-To: <08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> 
> >>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> >> @@ -187,6 +216,25 @@
> >>  *      The machine ABI rules governing the format of all ring request and
> >>  *      response structures.
> >>  *
> >> + * ring-page-order
> >> + *      Values:         <uint32_t>
> >> + *      Default Value:  0
> >> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> > 
> > Why not just max-ring-page-order. After all, the value is meaningless
> > for a backend that only exposes max-ring-pages.
> > 
> >> + *      Notes:          1, 3
> >> + *
> >> + *      The size of the frontend allocated request ring buffer in units
> >> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> >> + *      etc.).
> >> + *
> >> + * ring-pages
> >> + *      Values:         <uint32_t>
> >> + *      Default Value:  1
> >> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> > 
> > Similarly here - just max-ring-pages should do.
> 
> This patch documents existing extensions.  For a new driver to properly negotiate a
> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
> you must use the XenBus node names as I've defined them here.

Can we pick one and mark it as preferred and the other deprecated or
similar? Perhaps backends will have to support both for the foreseeable
future but we should make it possible for frontends to just pick one if
that's what they want while nudging them in the direction of all picking
the same one.

I think the decision should made by the current state of mainline Linux
& BSD front and backends, i.e. we should prefer what has been upstreamed
rather than private forks if possible. Does anyone know what that state
is?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:48:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQbz-0001Wp-Hr; Thu, 09 Feb 2012 09:48: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 1RvQby-0001Wc-4z
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:48:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328780764!52007370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11683 invoked from network); 9 Feb 2012 09:46:04 -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;
	9 Feb 2012 09:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10591881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:48:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	09:48:17 +0000
Message-ID: <1328780895.6133.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Justin Gibbs <justing@spectralogic.com>
Date: Thu, 9 Feb 2012 09:48:15 +0000
In-Reply-To: <08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> 
> >>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> >> @@ -187,6 +216,25 @@
> >>  *      The machine ABI rules governing the format of all ring request and
> >>  *      response structures.
> >>  *
> >> + * ring-page-order
> >> + *      Values:         <uint32_t>
> >> + *      Default Value:  0
> >> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> > 
> > Why not just max-ring-page-order. After all, the value is meaningless
> > for a backend that only exposes max-ring-pages.
> > 
> >> + *      Notes:          1, 3
> >> + *
> >> + *      The size of the frontend allocated request ring buffer in units
> >> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> >> + *      etc.).
> >> + *
> >> + * ring-pages
> >> + *      Values:         <uint32_t>
> >> + *      Default Value:  1
> >> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> > 
> > Similarly here - just max-ring-pages should do.
> 
> This patch documents existing extensions.  For a new driver to properly negotiate a
> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
> you must use the XenBus node names as I've defined them here.

Can we pick one and mark it as preferred and the other deprecated or
similar? Perhaps backends will have to support both for the foreseeable
future but we should make it possible for frontends to just pick one if
that's what they want while nudging them in the direction of all picking
the same one.

I think the decision should made by the current state of mainline Linux
& BSD front and backends, i.e. we should prefer what has been upstreamed
rather than private forks if possible. Does anyone know what that state
is?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:55:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQiP-0001qu-O3; Thu, 09 Feb 2012 09:54:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvQiO-0001qp-1M
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:54:56 +0000
Received: from [85.158.139.83:23117] by server-10.bemta-5.messagelabs.com id
	4A/F3-26909-FE7933F4; Thu, 09 Feb 2012 09:54:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328781294!13710105!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21015 invoked from network); 9 Feb 2012 09:54:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 09:54:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328781294; l=1639;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fi1FORV5y12510vm8aSYzPbN+FQ=;
	b=fQmWTGS98q97Kk9+ruzBFj01PhZ48TEDrIm5kDZBkC8JWL20qnqBpgADwm4DFhFwszE
	q6U/R8WP+A5QOmTLkbh4OcMFgJJUnAnQmPkna02pqvPs6POuTKRmkLN0WvHEk4Ggjkb2s
	5Px3eT5iMFKlRNamF13fr+ZSaX36FUWAQXY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by post.strato.de (mrclete mo38) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j045b5o199amkB ;
	Thu, 9 Feb 2012 10:54:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C983518637; Thu,  9 Feb 2012 10:54:37 +0100 (CET)
Date: Thu, 9 Feb 2012 10:54:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120209095437.GA13435@aepfle.de>
References: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add the dealing of
 MEM_EVENT_FLAG_EVICT_FAIL request in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, hongkaixing@huawei.com wrote:

> xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in
> tools/xenpaging
> 
> If a page is nominated but not evicted,then dom0 accesses the page,it
> will change the page's p2mt to be p2m_ram_paging_in,and the req.flags is
> MEM_EVENT_FLAG_EVICT_FAIL;so it will fail in p2m_mem_paging_evict() because
> of the p2mt;and paging->num_paged_out will not increase in this case;After
> the paging process is terminated, the p2mt p2m_ram_paging_in still remains
> in p2m table.Once domU accesses the nominated page,it will result in BSOD
> or vm'stuck.
> The patch adds the dealing of this request to resume the page before xenpaging
> is ended.

This can happen if p2m_mem_paging_populate() was called by a foreign
domain. In this case MEM_EVENT_FLAG_VCPU_PAUSED is not set and xenpaging
will not sent a response. And in this case the ring is in an
inconsistent state anyway, new requests cant be added, I think.


Acked-by: Olaf Hering <olaf@aepfle.de>

> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
> 
> diff -r 9f4640e40d4f -r 68eae0b487ae tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c	Thu Feb 09 16:50:52 2012 +0800
> +++ b/tools/xenpaging/xenpaging.c	Thu Feb 09 16:58:01 2012 +0800
> @@ -911,7 +911,7 @@
>                          !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
>  
>                  /* Tell Xen to resume the vcpu */
> -                if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> +                if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
>                  {
>                      /* Prepare the response */
>                      rsp.gfn = req.gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 09:55:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 09: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.xensource.com>)
	id 1RvQiP-0001qu-O3; Thu, 09 Feb 2012 09:54:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvQiO-0001qp-1M
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:54:56 +0000
Received: from [85.158.139.83:23117] by server-10.bemta-5.messagelabs.com id
	4A/F3-26909-FE7933F4; Thu, 09 Feb 2012 09:54:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328781294!13710105!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21015 invoked from network); 9 Feb 2012 09:54:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 09:54:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328781294; l=1639;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fi1FORV5y12510vm8aSYzPbN+FQ=;
	b=fQmWTGS98q97Kk9+ruzBFj01PhZ48TEDrIm5kDZBkC8JWL20qnqBpgADwm4DFhFwszE
	q6U/R8WP+A5QOmTLkbh4OcMFgJJUnAnQmPkna02pqvPs6POuTKRmkLN0WvHEk4Ggjkb2s
	5Px3eT5iMFKlRNamF13fr+ZSaX36FUWAQXY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by post.strato.de (mrclete mo38) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j045b5o199amkB ;
	Thu, 9 Feb 2012 10:54:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C983518637; Thu,  9 Feb 2012 10:54:37 +0100 (CET)
Date: Thu, 9 Feb 2012 10:54:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120209095437.GA13435@aepfle.de>
References: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add the dealing of
 MEM_EVENT_FLAG_EVICT_FAIL request in
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, hongkaixing@huawei.com wrote:

> xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in
> tools/xenpaging
> 
> If a page is nominated but not evicted,then dom0 accesses the page,it
> will change the page's p2mt to be p2m_ram_paging_in,and the req.flags is
> MEM_EVENT_FLAG_EVICT_FAIL;so it will fail in p2m_mem_paging_evict() because
> of the p2mt;and paging->num_paged_out will not increase in this case;After
> the paging process is terminated, the p2mt p2m_ram_paging_in still remains
> in p2m table.Once domU accesses the nominated page,it will result in BSOD
> or vm'stuck.
> The patch adds the dealing of this request to resume the page before xenpaging
> is ended.

This can happen if p2m_mem_paging_populate() was called by a foreign
domain. In this case MEM_EVENT_FLAG_VCPU_PAUSED is not set and xenpaging
will not sent a response. And in this case the ring is in an
inconsistent state anyway, new requests cant be added, I think.


Acked-by: Olaf Hering <olaf@aepfle.de>

> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
> 
> diff -r 9f4640e40d4f -r 68eae0b487ae tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c	Thu Feb 09 16:50:52 2012 +0800
> +++ b/tools/xenpaging/xenpaging.c	Thu Feb 09 16:58:01 2012 +0800
> @@ -911,7 +911,7 @@
>                          !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
>  
>                  /* Tell Xen to resume the vcpu */
> -                if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> +                if (( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) || ( req.flags & MEM_EVENT_FLAG_EVICT_FAIL ))
>                  {
>                      /* Prepare the response */
>                      rsp.gfn = req.gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:00:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:00:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQn8-000216-JT; Thu, 09 Feb 2012 09:59: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 1RvQn6-00020w-4d
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:59:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328781545!51721572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24966 invoked from network); 9 Feb 2012 09:59:05 -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;
	9 Feb 2012 09:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10592239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:59:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:59:07 +0000
Date: Thu, 9 Feb 2012 10:02:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20274.42482.96188.319229@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Jackson wrote:
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> > 
> > This will allow us to pass the libxl_device_disk and libxl_device_nic
> > struct from Dom0 to driver domain, and execute the necessary backends
> > there.
> 
> Is this really the best encoding of this information in xenstore ?
> 
> If we're allowed to assume that the backendd is a libxl program too,
> and of a reasonably similar version, perhaps we should have some kind
> of idl-generated mapping from xenstore keys to struct members ?

You have a point, however using the same encoding has two advantages:

- it is well understood and lots of lines of code have been written in many
toolstacks to support it;

- we can reuse the "state" based mechanism to establish a connection:
again not a great protocol, but very well known and understood.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:00:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:00:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQn8-000216-JT; Thu, 09 Feb 2012 09:59: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 1RvQn6-00020w-4d
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 09:59:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328781545!51721572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24966 invoked from network); 9 Feb 2012 09:59:05 -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;
	9 Feb 2012 09:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10592239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:59:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:59:07 +0000
Date: Thu, 9 Feb 2012 10:02:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20274.42482.96188.319229@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Ian Jackson wrote:
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> > 
> > This will allow us to pass the libxl_device_disk and libxl_device_nic
> > struct from Dom0 to driver domain, and execute the necessary backends
> > there.
> 
> Is this really the best encoding of this information in xenstore ?
> 
> If we're allowed to assume that the backendd is a libxl program too,
> and of a reasonably similar version, perhaps we should have some kind
> of idl-generated mapping from xenstore keys to struct members ?

You have a point, however using the same encoding has two advantages:

- it is well understood and lots of lines of code have been written in many
toolstacks to support it;

- we can reuse the "state" based mechanism to establish a connection:
again not a great protocol, but very well known and understood.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:01:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQnz-00028Y-3y; Thu, 09 Feb 2012 10:00:43 +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 1RvQnx-00028K-HY
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:00:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328781618!65120265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18333 invoked from network); 9 Feb 2012 10:00:18 -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;
	9 Feb 2012 10:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10592282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:00:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 10:00:40 +0000
Date: Thu, 9 Feb 2012 10:03:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6Kf7+oBNFZsk6cr=7FRXWEMU7NojoQ=OrBVQ7Za6hw6w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202091003030.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<94532199f647fc03816f.1328189220@debian.localdomain>
	<alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
	<CAPLaKK6Kf7+oBNFZsk6cr=7FRXWEMU7NojoQ=OrBVQ7Za6hw6w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-394858887-1328781850=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add
 libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-394858887-1328781850=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Thu, 2 Feb 2012, Roger Pau Monné wrote:
> 2012/2/2 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > On Thu, 2 Feb 2012, Roger Pau Monne wrote:
> >> # HG changeset patch
> >> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> >> # Date 1328179686 -3600
> >> # Node ID 94532199f647fc03816fc5ae50ab53c8c5b80cd8
> >> # Parent  1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
> >> libxl: add libxl_hotplug_dispatch
> >>
> >> Added a new function to libxl API to handle device hotplug. Actions to
> >> execute upon hotplug device state changes are handled using the
> >> libxl_device_disk_hotplug_actions and libxl_device_nic_hotplug_actions
> >> depending on the type of device. Currently only VIF and VBD devices
> >> are handled by the hotplug mechanism.
> >>
> >> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> >>
> >> diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.c
> >> --- a/tools/libxl/libxl.c       Thu Feb 02 11:45:03 2012 +0100
> >> +++ b/tools/libxl/libxl.c       Thu Feb 02 11:48:06 2012 +0100
> >> @@ -982,6 +982,188 @@ out:
> >>      return rc;
> >>  }
> >>
> >> +static int libxl__hotplug_generic_dispatcher(libxl__gc *gc, char *path,
> >> +                                uint32_t domid,
> >> +                                libxl__hotplug_status state,
> >> +                                libxl__device_generic_hotplug_actions *action,
> >> +                                void *device)
> >> +{
> >> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> >> +    char *spath = libxl__sprintf(gc, "%s/state", path);
> >> +    int rc = 0;
> >> +
> >> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "processing device %s with state %d",
> >> +                                      path, state);
> >> +    switch(state) {
> >> +    case HOTPLUG_DEVICE_INIT:
> >> +        if (action->init) {
> >> +            rc = action->init(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to init"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECT);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_CONNECT:
> >> +        if (action->connect) {
> >> +            rc = action->connect(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to connect"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECTED);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_CONNECTED:
> >> +        if (action->connected) {
> >> +            rc = action->connected(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> >> +                                                  "connected action on"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        break;
> >> +    case HOTPLUG_DEVICE_DISCONNECT:
> >> +        if (action->disconnect) {
> >> +            rc = action->disconnect(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to unplug"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                        HOTPLUG_DEVICE_DISCONNECTED);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_DISCONNECTED:
> >> +        if (action->disconnected) {
> >> +            rc = action->disconnected(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> >> +                                                  "unpluged action on"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        break;
> >> +    case HOTPLUG_DEVICE_FORCE_DISCONNECT:
> >> +        if (action->force_disconnect) {
> >> +            rc = action->force_disconnect(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to force "
> >> +                                                  "disconnect device "
> >> +                                                  "%s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                        HOTPLUG_DEVICE_DISCONNECTED);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_ERROR:
> >> +        if (action->error)
> >> +            rc = action->error(ctx, domid, device);
> >> +        break;
> >> +    }
> >> +    return rc;
> >
> > I can see that we are writing an error code to xenstore in case of
> > errors, but I fail to see where we are writing back a positive response.
> > Of course the caller of libxl_device_disk/nic_hotplug_add could watch
> > the backend state waiting for it to come up, but I think that having an
> > explicit ACK under /hotplug would be much better.
> 
> The Sequence is the following, but I'm not really sure this is the
> most correct way. All states can go to HOTPLUG_DEVICE_ERROR, and the
> following state changes:
> 
> HOTPLUG_DEVICE_INIT no state change
> HOTPLUG_DEVICE_CONNECT -> HOTPLUG_DEVICE_CONNECTED (on success)
> HOTPLUG_DEVICE_CONNECTED no change
> HOTPLUG_DEVICE_DISCONNECT -> HOTPLUG_DEVICE_DISCONNECTED (on success)
> HOTPLUG_DEVICE_FORCE_DISCONNECT -> HOTPLUG_DEVICE_DISCONNECTED (on success)

I see: it is the same as before but under the hotplug path. Somehow I
missed the code that is handling all that, however it is not a bad idea
to keep the same protocol.
--8323329-394858887-1328781850=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-394858887-1328781850=:3196--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:01:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvQnz-00028Y-3y; Thu, 09 Feb 2012 10:00:43 +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 1RvQnx-00028K-HY
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:00:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328781618!65120265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18333 invoked from network); 9 Feb 2012 10:00:18 -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;
	9 Feb 2012 10:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10592282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:00:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 10:00:40 +0000
Date: Thu, 9 Feb 2012 10:03:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6Kf7+oBNFZsk6cr=7FRXWEMU7NojoQ=OrBVQ7Za6hw6w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202091003030.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<94532199f647fc03816f.1328189220@debian.localdomain>
	<alpine.DEB.2.00.1202021831500.3196@kaball-desktop>
	<CAPLaKK6Kf7+oBNFZsk6cr=7FRXWEMU7NojoQ=OrBVQ7Za6hw6w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-394858887-1328781850=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 25 of 29 RFC] libxl: add
 libxl_hotplug_dispatch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-394858887-1328781850=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Thu, 2 Feb 2012, Roger Pau Monné wrote:
> 2012/2/2 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > On Thu, 2 Feb 2012, Roger Pau Monne wrote:
> >> # HG changeset patch
> >> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> >> # Date 1328179686 -3600
> >> # Node ID 94532199f647fc03816fc5ae50ab53c8c5b80cd8
> >> # Parent  1506b1f2ab0fe5f4cd5bcd86a566d5a7be5f838b
> >> libxl: add libxl_hotplug_dispatch
> >>
> >> Added a new function to libxl API to handle device hotplug. Actions to
> >> execute upon hotplug device state changes are handled using the
> >> libxl_device_disk_hotplug_actions and libxl_device_nic_hotplug_actions
> >> depending on the type of device. Currently only VIF and VBD devices
> >> are handled by the hotplug mechanism.
> >>
> >> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> >>
> >> diff -r 1506b1f2ab0f -r 94532199f647 tools/libxl/libxl.c
> >> --- a/tools/libxl/libxl.c       Thu Feb 02 11:45:03 2012 +0100
> >> +++ b/tools/libxl/libxl.c       Thu Feb 02 11:48:06 2012 +0100
> >> @@ -982,6 +982,188 @@ out:
> >>      return rc;
> >>  }
> >>
> >> +static int libxl__hotplug_generic_dispatcher(libxl__gc *gc, char *path,
> >> +                                uint32_t domid,
> >> +                                libxl__hotplug_status state,
> >> +                                libxl__device_generic_hotplug_actions *action,
> >> +                                void *device)
> >> +{
> >> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> >> +    char *spath = libxl__sprintf(gc, "%s/state", path);
> >> +    int rc = 0;
> >> +
> >> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "processing device %s with state %d",
> >> +                                      path, state);
> >> +    switch(state) {
> >> +    case HOTPLUG_DEVICE_INIT:
> >> +        if (action->init) {
> >> +            rc = action->init(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to init"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECT);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_CONNECT:
> >> +        if (action->connect) {
> >> +            rc = action->connect(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to connect"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d", HOTPLUG_DEVICE_CONNECTED);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_CONNECTED:
> >> +        if (action->connected) {
> >> +            rc = action->connected(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> >> +                                                  "connected action on"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        break;
> >> +    case HOTPLUG_DEVICE_DISCONNECT:
> >> +        if (action->disconnect) {
> >> +            rc = action->disconnect(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to unplug"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                        HOTPLUG_DEVICE_DISCONNECTED);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_DISCONNECTED:
> >> +        if (action->disconnected) {
> >> +            rc = action->disconnected(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute "
> >> +                                                  "unpluged action on"
> >> +                                                  " device %s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        break;
> >> +    case HOTPLUG_DEVICE_FORCE_DISCONNECT:
> >> +        if (action->force_disconnect) {
> >> +            rc = action->force_disconnect(ctx, domid, device);
> >> +            if (rc < 0) {
> >> +                LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to force "
> >> +                                                  "disconnect device "
> >> +                                                  "%s", path);
> >> +                libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                                HOTPLUG_DEVICE_ERROR);
> >> +                break;
> >> +            }
> >> +        }
> >> +        libxl__xs_write(gc, XBT_NULL, spath, "%d",
> >> +                        HOTPLUG_DEVICE_DISCONNECTED);
> >> +        break;
> >> +    case HOTPLUG_DEVICE_ERROR:
> >> +        if (action->error)
> >> +            rc = action->error(ctx, domid, device);
> >> +        break;
> >> +    }
> >> +    return rc;
> >
> > I can see that we are writing an error code to xenstore in case of
> > errors, but I fail to see where we are writing back a positive response.
> > Of course the caller of libxl_device_disk/nic_hotplug_add could watch
> > the backend state waiting for it to come up, but I think that having an
> > explicit ACK under /hotplug would be much better.
> 
> The Sequence is the following, but I'm not really sure this is the
> most correct way. All states can go to HOTPLUG_DEVICE_ERROR, and the
> following state changes:
> 
> HOTPLUG_DEVICE_INIT no state change
> HOTPLUG_DEVICE_CONNECT -> HOTPLUG_DEVICE_CONNECTED (on success)
> HOTPLUG_DEVICE_CONNECTED no change
> HOTPLUG_DEVICE_DISCONNECT -> HOTPLUG_DEVICE_DISCONNECTED (on success)
> HOTPLUG_DEVICE_FORCE_DISCONNECT -> HOTPLUG_DEVICE_DISCONNECTED (on success)

I see: it is the same as before but under the hotplug path. Somehow I
missed the code that is handling all that, however it is not a bad idea
to keep the same protocol.
--8323329-394858887-1328781850=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-394858887-1328781850=:3196--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:05:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvQsg-0002Nj-TE; Thu, 09 Feb 2012 10:05:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RvQsf-0002NT-0z
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:05:33 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328781926!13817315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19091 invoked from network); 9 Feb 2012 10:05:26 -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;
	9 Feb 2012 10:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10592423"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:05:26 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 9 Feb 2012
	10:05:26 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Justin Gibbs
	<justing@spectralogic.com>
Date: Thu, 9 Feb 2012 10:05:21 +0000
Thread-Topic: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for
	virtual block device major numbers
Thread-Index: AcznEBpsvzo1/RVRRWqKATZ5wnPJygAAW7cg
Message-ID: <291EDFCB1E9E224A99088639C4762022C80EF535EE@LONPMAILBOX01.citrite.net>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
	<AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
	<1328780817.6133.133.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328780817.6133.133.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> QEMU emulates primary and secondary IDE master+slave, it has no concept
> of a major or minor number. Why does the dom0 numbering scheme
> matter?

For Windows PV drivers I parse the vbd number so I can extract the disk number which is then present as the scsi target id. I'd prefer if vbd-interface.txt remained the canonical place where the numbering scheme is specified though. Putting definitions into blkif.h just weakens that position.

  Paul

> (Does this relate to the old, or possibly current, xend misbehaviour of
> stat()ing the dom0 device while creating a domain?)
> 
> On Linux we treat d0-d3 (however they are specified) as aliasing those 4 IDE
> devices (although we don't actual present alias devices but instead use UUID
> or LABEL based fstab etc).
> 
> Whatever non-Linux does for weird compatibility reasons here I think the
> right place to document it would be in docs/misc/vbd-interface.txt
> following the precedent of the "Notes on Linux as a guest" in that
> document.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:05:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvQsg-0002Nj-TE; Thu, 09 Feb 2012 10:05:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RvQsf-0002NT-0z
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:05:33 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328781926!13817315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19091 invoked from network); 9 Feb 2012 10:05:26 -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;
	9 Feb 2012 10:05:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10592423"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:05:26 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 9 Feb 2012
	10:05:26 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Justin Gibbs
	<justing@spectralogic.com>
Date: Thu, 9 Feb 2012 10:05:21 +0000
Thread-Topic: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for
	virtual block device major numbers
Thread-Index: AcznEBpsvzo1/RVRRWqKATZ5wnPJygAAW7cg
Message-ID: <291EDFCB1E9E224A99088639C4762022C80EF535EE@LONPMAILBOX01.citrite.net>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
	<AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
	<1328780817.6133.133.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328780817.6133.133.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> QEMU emulates primary and secondary IDE master+slave, it has no concept
> of a major or minor number. Why does the dom0 numbering scheme
> matter?

For Windows PV drivers I parse the vbd number so I can extract the disk number which is then present as the scsi target id. I'd prefer if vbd-interface.txt remained the canonical place where the numbering scheme is specified though. Putting definitions into blkif.h just weakens that position.

  Paul

> (Does this relate to the old, or possibly current, xend misbehaviour of
> stat()ing the dom0 device while creating a domain?)
> 
> On Linux we treat d0-d3 (however they are specified) as aliasing those 4 IDE
> devices (although we don't actual present alias devices but instead use UUID
> or LABEL based fstab etc).
> 
> Whatever non-Linux does for weird compatibility reasons here I think the
> right place to document it would be in docs/misc/vbd-interface.txt
> following the precedent of the "Notes on Linux as a guest" in that
> document.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:23:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvR9W-0002jv-IS; Thu, 09 Feb 2012 10:22:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvR9V-0002jq-B5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:22:57 +0000
Received: from [85.158.139.83:29382] by server-5.bemta-5.messagelabs.com id
	74/49-03847-08E933F4; Thu, 09 Feb 2012 10:22:56 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328782972!14352686!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18930 invoked from network); 9 Feb 2012 10:22:53 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Feb 2012 10:22:53 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvR9P-0000A3-S9
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 02:22:51 -0800
Date: Thu, 9 Feb 2012 02:22:51 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328782971857-5469072.post@n5.nabble.com>
In-Reply-To: <1328712798.6133.48.camel@zakaz.uk.xensource.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24701:3574f4d67843

On domUs pv xl file configuration: '/dev/scd0,raw,xvdb,ro,cdrom'

--------------------------------
DomU Mint 11 (based on Natty - Ubuntu 11.04):
udev           167-0ubuntu3
linux-image-2.6.38-8-generic           2.6.38-8.42

With physical cdrom, on xl file configuration: '/dev/scd0,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_PATH=xen-vbd-51728
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64

Not see it but work if do manual mount as root
---------

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_PATH=xen-vbd-51728
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64

Not see it but work if do manual mount as root
--------------------------------


--------------------------------
DomU Mint 12 (based on Oneiric - Ubuntu 11.10):
udev           173-0ubuntu4.1
linux-image-3.0.0-13-generic           3.0.0-13.22

With physical cdrom, on xl file configuration: '/dev/scd0,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: cdrom
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51728
E: ID_PATH_TAG=xen-vbd-51728
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728 /dev/cdrom
E: TAGS=:udev-acl:

Not see it but work if do manual mount as root
---------

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
S: cdrom
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51728
E: ID_PATH_TAG=xen-vbd-51728
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_PART_TABLE_TYPE=dos
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom
E: TAGS=:udev-acl:

Not see it but work if do manual mount as root
---------
---------
---------
I try also different configuration of device as partition...

With physical cdrom, on xl file configuration:
'/dev/scd0,raw,xvdb1,ro,cdrom'

udevadm info --query=all --path /block/xvdb
device path not found
udevadm info --query=all --path /block/xvdb1
P: /devices/vbd-51729/block/xvdb1
N: xvdb1
S: disk/by-path/xen-vbd-51729
S: cdrom1
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51729/block/xvdb1
E: MAJOR=202
E: MINOR=17
E: DEVNAME=/dev/xvdb1
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51729
E: ID_PATH_TAG=xen-vbd-51729
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51729 /dev/cdrom1
E: TAGS=:udev-acl:

See it as cdrom but not work, also with manual mount as root not work
---------

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb1,ro,cdrom'

udevadm info --query=all --path /block/xvdb
device path not found
udevadm info --query=all --path /block/xvdb1
P: /devices/vbd-51729/block/xvdb1
N: xvdb1
S: disk/by-path/xen-vbd-51729
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
S: cdrom1
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51729/block/xvdb1
E: MAJOR=202
E: MINOR=17
E: DEVNAME=/dev/xvdb1
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51729
E: ID_PATH_TAG=xen-vbd-51729
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_PART_TABLE_TYPE=dos
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51729
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom1
E: TAGS=:udev-acl:

Cdrom full working and see it correctly
--------------------------------

If you need more test and data ask me and I do and post

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5469072.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:23:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvR9W-0002jv-IS; Thu, 09 Feb 2012 10:22:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvR9V-0002jq-B5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:22:57 +0000
Received: from [85.158.139.83:29382] by server-5.bemta-5.messagelabs.com id
	74/49-03847-08E933F4; Thu, 09 Feb 2012 10:22:56 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328782972!14352686!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18930 invoked from network); 9 Feb 2012 10:22:53 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Feb 2012 10:22:53 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvR9P-0000A3-S9
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 02:22:51 -0800
Date: Thu, 9 Feb 2012 02:22:51 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328782971857-5469072.post@n5.nabble.com>
In-Reply-To: <1328712798.6133.48.camel@zakaz.uk.xensource.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24701:3574f4d67843

On domUs pv xl file configuration: '/dev/scd0,raw,xvdb,ro,cdrom'

--------------------------------
DomU Mint 11 (based on Natty - Ubuntu 11.04):
udev           167-0ubuntu3
linux-image-2.6.38-8-generic           2.6.38-8.42

With physical cdrom, on xl file configuration: '/dev/scd0,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_PATH=xen-vbd-51728
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64

Not see it but work if do manual mount as root
---------

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_PATH=xen-vbd-51728
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64

Not see it but work if do manual mount as root
--------------------------------


--------------------------------
DomU Mint 12 (based on Oneiric - Ubuntu 11.10):
udev           173-0ubuntu4.1
linux-image-3.0.0-13-generic           3.0.0-13.22

With physical cdrom, on xl file configuration: '/dev/scd0,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: cdrom
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51728
E: ID_PATH_TAG=xen-vbd-51728
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728 /dev/cdrom
E: TAGS=:udev-acl:

Not see it but work if do manual mount as root
---------

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
S: cdrom
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51728
E: ID_PATH_TAG=xen-vbd-51728
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_PART_TABLE_TYPE=dos
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom
E: TAGS=:udev-acl:

Not see it but work if do manual mount as root
---------
---------
---------
I try also different configuration of device as partition...

With physical cdrom, on xl file configuration:
'/dev/scd0,raw,xvdb1,ro,cdrom'

udevadm info --query=all --path /block/xvdb
device path not found
udevadm info --query=all --path /block/xvdb1
P: /devices/vbd-51729/block/xvdb1
N: xvdb1
S: disk/by-path/xen-vbd-51729
S: cdrom1
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51729/block/xvdb1
E: MAJOR=202
E: MINOR=17
E: DEVNAME=/dev/xvdb1
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51729
E: ID_PATH_TAG=xen-vbd-51729
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51729 /dev/cdrom1
E: TAGS=:udev-acl:

See it as cdrom but not work, also with manual mount as root not work
---------

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb1,ro,cdrom'

udevadm info --query=all --path /block/xvdb
device path not found
udevadm info --query=all --path /block/xvdb1
P: /devices/vbd-51729/block/xvdb1
N: xvdb1
S: disk/by-path/xen-vbd-51729
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
S: cdrom1
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51729/block/xvdb1
E: MAJOR=202
E: MINOR=17
E: DEVNAME=/dev/xvdb1
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51729
E: ID_PATH_TAG=xen-vbd-51729
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_PART_TABLE_TYPE=dos
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51729
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom1
E: TAGS=:udev-acl:

Cdrom full working and see it correctly
--------------------------------

If you need more test and data ask me and I do and post

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5469072.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:25:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvRC5-0002rf-B4; Thu, 09 Feb 2012 10:25:37 +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 1RvRC3-0002rW-C6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:25:35 +0000
Received: from [85.158.139.83:49485] by server-8.bemta-5.messagelabs.com id
	6C/9F-08951-E1F933F4; Thu, 09 Feb 2012 10:25:34 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328783131!14351930!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19879 invoked from network); 9 Feb 2012 10:25:33 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.11)
	by server-2.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 10:25:33 -0000
Received: from mail158-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 10:25:31 +0000
Received: from mail158-tx2 (localhost [127.0.0.1])	by
	mail158-tx2-R.bigfish.com (Postfix) with ESMTP id 0470D4045E;
	Thu,  9 Feb 2012 10:25:31 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail158-tx2 (localhost.localdomain [127.0.0.1]) by mail158-tx2
	(MessageSwitch) id 132878312977849_25484;
	Thu,  9 Feb 2012 10:25:29 +0000 (UTC)
Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.242])	by
	mail158-tx2.bigfish.com (Postfix) with ESMTP id 0C43C10004D;
	Thu,  9 Feb 2012 10:25:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 10:25:26 +0000
X-WSS-ID: 0LZ4FMA-02-0DI-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 2FC4CC8146;	Thu,  9 Feb 2012 04:25:21 -0600 (CST)
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, 9 Feb 2012 04:25:37 -0600
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, 9 Feb 2012 04:25:22 -0600
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, 9 Feb 2012
	05:25:21 -0500
Message-ID: <4F339F0F.2090409@amd.com>
Date: Thu, 9 Feb 2012 11:25:19 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Kevin O'Connor <kevin@koconnor.net>
References: <4F31288F.5060904@amd.com> <20120208011808.GA9541@morn.localdomain>
	<4F324F2A.9000308@amd.com> <20120209012818.GA476@morn.localdomain>
In-Reply-To: <20120209012818.GA476@morn.localdomain>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 02:28, Kevin O'Connor wrote:
> On Wed, Feb 08, 2012 at 11:32:10AM +0100, Christoph Egger wrote:
>> On 02/08/12 02:18, Kevin O'Connor wrote:
>>> We can change the seabios makefile to call these scripts with an
>>> explicit $(PYTHON).
>>
>> Awesome!
>
> See the attached patch.
>
>>> That's quite odd.  This looks data related instead of python related.
>>> Try running a "make clean" and then "make" in just the seabios
>>> directory.  If you still see an issue, tar up the seabios "out/"
>>> directory and mail it to me.
>>
>> It failed the same way.
>> I sent you the tarball offlist due its size.
>
> Looks like your version of gcc is defining sections with
> .rodata.__PRETTY_FUNCTION__ - which is odd as that macro isn't used in
> the code.  Does the second attached patch fix it for you?
>
> -Kevin

Both patches work for me and there are no follow-up errors.
Thank you.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:25:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvRC5-0002rf-B4; Thu, 09 Feb 2012 10:25:37 +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 1RvRC3-0002rW-C6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:25:35 +0000
Received: from [85.158.139.83:49485] by server-8.bemta-5.messagelabs.com id
	6C/9F-08951-E1F933F4; Thu, 09 Feb 2012 10:25:34 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328783131!14351930!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19879 invoked from network); 9 Feb 2012 10:25:33 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.11)
	by server-2.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 10:25:33 -0000
Received: from mail158-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 10:25:31 +0000
Received: from mail158-tx2 (localhost [127.0.0.1])	by
	mail158-tx2-R.bigfish.com (Postfix) with ESMTP id 0470D4045E;
	Thu,  9 Feb 2012 10:25:31 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail158-tx2 (localhost.localdomain [127.0.0.1]) by mail158-tx2
	(MessageSwitch) id 132878312977849_25484;
	Thu,  9 Feb 2012 10:25:29 +0000 (UTC)
Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.242])	by
	mail158-tx2.bigfish.com (Postfix) with ESMTP id 0C43C10004D;
	Thu,  9 Feb 2012 10:25:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 10:25:26 +0000
X-WSS-ID: 0LZ4FMA-02-0DI-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 2FC4CC8146;	Thu,  9 Feb 2012 04:25:21 -0600 (CST)
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, 9 Feb 2012 04:25:37 -0600
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, 9 Feb 2012 04:25:22 -0600
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, 9 Feb 2012
	05:25:21 -0500
Message-ID: <4F339F0F.2090409@amd.com>
Date: Thu, 9 Feb 2012 11:25:19 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Kevin O'Connor <kevin@koconnor.net>
References: <4F31288F.5060904@amd.com> <20120208011808.GA9541@morn.localdomain>
	<4F324F2A.9000308@amd.com> <20120209012818.GA476@morn.localdomain>
In-Reply-To: <20120209012818.GA476@morn.localdomain>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] seabios build failure in xen tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 02:28, Kevin O'Connor wrote:
> On Wed, Feb 08, 2012 at 11:32:10AM +0100, Christoph Egger wrote:
>> On 02/08/12 02:18, Kevin O'Connor wrote:
>>> We can change the seabios makefile to call these scripts with an
>>> explicit $(PYTHON).
>>
>> Awesome!
>
> See the attached patch.
>
>>> That's quite odd.  This looks data related instead of python related.
>>> Try running a "make clean" and then "make" in just the seabios
>>> directory.  If you still see an issue, tar up the seabios "out/"
>>> directory and mail it to me.
>>
>> It failed the same way.
>> I sent you the tarball offlist due its size.
>
> Looks like your version of gcc is defining sections with
> .rodata.__PRETTY_FUNCTION__ - which is odd as that macro isn't used in
> the code.  Does the second attached patch fix it for you?
>
> -Kevin

Both patches work for me and there are no follow-up errors.
Thank you.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRMQ-0003BA-GD; Thu, 09 Feb 2012 10:36:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRMO-0003B2-DX
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:36:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328783770!14142388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3111 invoked from network); 9 Feb 2012 10:36:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 10:36:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 10:36:09 +0000
Message-Id: <4F33AFA80200007800071D8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 10:36:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328780895.6133.134.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Justin Gibbs <justing@spectralogic.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I think the decision should made by the current state of mainline Linux
> & BSD front and backends, i.e. we should prefer what has been upstreamed
> rather than private forks if possible. Does anyone know what that state
> is?

Nothing at all is upstream on the Linux side.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRMQ-0003BA-GD; Thu, 09 Feb 2012 10:36:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRMO-0003B2-DX
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:36:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328783770!14142388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3111 invoked from network); 9 Feb 2012 10:36:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 10:36:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 10:36:09 +0000
Message-Id: <4F33AFA80200007800071D8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 10:36:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328780895.6133.134.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Justin Gibbs <justing@spectralogic.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I think the decision should made by the current state of mainline Linux
> & BSD front and backends, i.e. we should prefer what has been upstreamed
> rather than private forks if possible. Does anyone know what that state
> is?

Nothing at all is upstream on the Linux side.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:41:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvRQr-0003KA-9l; Thu, 09 Feb 2012 10:40:53 +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 1RvRQp-0003Jy-QG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:40:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328783995!52025877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8000 invoked from network); 9 Feb 2012 10:39:55 -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;
	9 Feb 2012 10:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10593424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:40:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	10:40:46 +0000
Message-ID: <1328784044.6133.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 9 Feb 2012 10:40:44 +0000
In-Reply-To: <4F33AFA80200007800071D8E@nat28.tlf.novell.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4F33AFA80200007800071D8E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Justin Gibbs <justing@spectralogic.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 10:36 +0000, Jan Beulich wrote:
> >>> On 09.02.12 at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > I think the decision should made by the current state of mainline Linux
> > & BSD front and backends, i.e. we should prefer what has been upstreamed
> > rather than private forks if possible. Does anyone know what that state
> > is?
> 
> Nothing at all is upstream on the Linux side.

Then there may be a case for marking _both_ deprecated and undeprecating
whichever one gets upstreamed first. Of course if something is already
in BSD we should just choose that.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:41:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvRQr-0003KA-9l; Thu, 09 Feb 2012 10:40:53 +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 1RvRQp-0003Jy-QG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:40:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328783995!52025877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8000 invoked from network); 9 Feb 2012 10:39:55 -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;
	9 Feb 2012 10:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10593424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:40:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	10:40:46 +0000
Message-ID: <1328784044.6133.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 9 Feb 2012 10:40:44 +0000
In-Reply-To: <4F33AFA80200007800071D8E@nat28.tlf.novell.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4F33AFA80200007800071D8E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Justin Gibbs <justing@spectralogic.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 10:36 +0000, Jan Beulich wrote:
> >>> On 09.02.12 at 10:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > I think the decision should made by the current state of mainline Linux
> > & BSD front and backends, i.e. we should prefer what has been upstreamed
> > rather than private forks if possible. Does anyone know what that state
> > is?
> 
> Nothing at all is upstream on the Linux side.

Then there may be a case for marking _both_ deprecated and undeprecating
whichever one gets upstreamed first. Of course if something is already
in BSD we should just choose that.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:45:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRVK-0003UA-W4; Thu, 09 Feb 2012 10:45:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvRVJ-0003U5-Oy
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:45:30 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328784302!65130322!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30091 invoked from network); 9 Feb 2012 10:45:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 10:45:03 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19AjO1u008994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 05:45:24 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19AjMXi031518; Thu, 9 Feb 2012 05:45:23 -0500
Message-ID: <4F33A3C1.1080108@redhat.com>
Date: Thu, 09 Feb 2012 11:45:21 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com>
In-Reply-To: <20120209084816.GB18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 09:48, Gleb Natapov wrote:
> On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
>>  * qemu_system_wakeup_request is supposed to be called on events which
>>    should wake up the guest.
>>
> qemu_system_wakeup_request() should get wakeup source as a parameter.
> There are ways to report it to a guest.

Can we do that incrementally, when we actually implement the guest
reporting?

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:45:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:45:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRVK-0003UA-W4; Thu, 09 Feb 2012 10:45:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvRVJ-0003U5-Oy
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:45:30 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328784302!65130322!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30091 invoked from network); 9 Feb 2012 10:45:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 10:45:03 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19AjO1u008994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 05:45:24 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19AjMXi031518; Thu, 9 Feb 2012 05:45:23 -0500
Message-ID: <4F33A3C1.1080108@redhat.com>
Date: Thu, 09 Feb 2012 11:45:21 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com>
In-Reply-To: <20120209084816.GB18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 09:48, Gleb Natapov wrote:
> On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
>>  * qemu_system_wakeup_request is supposed to be called on events which
>>    should wake up the guest.
>>
> qemu_system_wakeup_request() should get wakeup source as a parameter.
> There are ways to report it to a guest.

Can we do that incrementally, when we actually implement the guest
reporting?

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:49:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvRZI-0003mF-Lg; Thu, 09 Feb 2012 10:49:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRZG-0003m4-GT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:49:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328784567!12660920!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 676 invoked from network); 9 Feb 2012 10:49:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 10:49:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 10:49:27 +0000
Message-Id: <4F33B2C50200007800071DA5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 10:49:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<957b5ac44e32778242a9.1328719537@andrewcoop.uk.xensource.com>
In-Reply-To: <957b5ac44e32778242a9.1328719537@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier
 definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 17:45, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Now CONFIG_SMP has been removed, there is no need to define
> smp_{,r,w}mb()s which used to conditionally compiled to different
> operations (even though those conditonally different operations still
> ended up as simple barrier()s)
> 
> Therefore, remove smp_{,r,w}mb()s and just use regular {,r,w}mb()s

Did you read the Linux side description and usage guidelines before
doing this? I don't think doing the adjustment here is a good idea,
even if the smp_ ones are aliases of the plain ones (which doesn't
necessarily have to the case on any future architectures Xen might
get ported to).

Jan

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -260,7 +260,7 @@ static void mwait_idle_with_hints(unsign
>      s_time_t expires = per_cpu(timer_deadline, cpu);
>  
>      __monitor((void *)&mwait_wakeup(cpu), 0, 0);
> -    smp_mb();
> +    mb();
>  
>      /*
>       * Timer deadline passing is the event on which we will be woken via
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/cpu/mtrr/main.c
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -248,7 +248,7 @@ static void set_mtrr(unsigned int reg, u
>  
>  	/* ok, reset count and toggle gate */
>  	atomic_set(&data.count, nr_cpus);
> -	smp_wmb();
> +	wmb();
>  	atomic_set(&data.gate,1);
>  
>  	/* do our MTRR business */
> @@ -271,7 +271,7 @@ static void set_mtrr(unsigned int reg, u
>  		cpu_relax();
>  
>  	atomic_set(&data.count, nr_cpus);
> -	smp_wmb();
> +	wmb();
>  	atomic_set(&data.gate,0);
>  
>  	/*
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -207,7 +207,7 @@ static void dynamic_irq_cleanup(unsigned
>      spin_unlock_irqrestore(&desc->lock, flags);
>  
>      /* Wait to make sure it's not being used on another CPU */
> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
>      if (action)
>          xfree(action);
> @@ -931,7 +931,7 @@ void __init release_irq(unsigned int irq
>      spin_unlock_irqrestore(&desc->lock,flags);
>  
>      /* Wait to make sure it's not being used on another CPU */
> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
>      if (action && action->free_on_release)
>          xfree(action);
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -544,7 +544,7 @@ void domain_shutdown(struct domain *d, u
>  
>      d->is_shutting_down = 1;
>  
> -    smp_mb(); /* set shutdown status /then/ check for per-cpu deferrals */
> +    mb(); /* set shutdown status /then/ check for per-cpu deferrals */
>  
>      for_each_vcpu ( d, v )
>      {
> @@ -594,7 +594,7 @@ int vcpu_start_shutdown_deferral(struct 
>          return 1;
>  
>      v->defer_shutdown = 1;
> -    smp_mb(); /* set deferral status /then/ check for shutdown */
> +    mb(); /* set deferral status /then/ check for shutdown */
>      if ( unlikely(v->domain->is_shutting_down) )
>          vcpu_check_shutdown(v);
>  
> @@ -604,7 +604,7 @@ int vcpu_start_shutdown_deferral(struct 
>  void vcpu_end_shutdown_deferral(struct vcpu *v)
>  {
>      v->defer_shutdown = 0;
> -    smp_mb(); /* clear deferral status /then/ check for shutdown */
> +    mb(); /* clear deferral status /then/ check for shutdown */
>      if ( unlikely(v->domain->is_shutting_down) )
>          vcpu_check_shutdown(v);
>  }
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/rcupdate.c
> --- a/xen/common/rcupdate.c
> +++ b/xen/common/rcupdate.c
> @@ -252,7 +252,7 @@ static void rcu_start_batch(struct rcu_c
>           * next_pending == 0 must be visible in
>           * __rcu_process_callbacks() before it can see new value of cur.
>           */
> -        smp_wmb();
> +        wmb();
>          rcp->cur++;
>  
>          cpumask_copy(&rcp->cpumask, &cpu_online_map);
> @@ -340,7 +340,7 @@ static void __rcu_process_callbacks(stru
>          /* see the comment and corresponding wmb() in
>           * the rcu_start_batch()
>           */
> -        smp_rmb();
> +        rmb();
>  
>          if (!rcp->next_pending) {
>              /* and start it/schedule start if it's a new batch */
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/schedule.c
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -657,7 +657,7 @@ static long do_poll(struct sched_poll *s
>  
>  #ifndef CONFIG_X86 /* set_bit() implies mb() on x86 */
>      /* Check for events /after/ setting flags: avoids wakeup waiting race. 
> */
> -    smp_mb();
> +    mb();
>  
>      /*
>       * Someone may have seen we are blocked but not that we are polling, or
> @@ -1173,12 +1173,12 @@ static void schedule(void)
>  void context_saved(struct vcpu *prev)
>  {
>      /* Clear running flag /after/ writing context to memory. */
> -    smp_wmb();
> +    wmb();
>  
>      prev->is_running = 0;
>  
>      /* Check for migration request /after/ clearing running flag. */
> -    smp_mb();
> +    mb();
>  
>      SCHED_OP(VCPU2OP(prev), context_saved, prev);
>  
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/stop_machine.c
> --- a/xen/common/stop_machine.c
> +++ b/xen/common/stop_machine.c
> @@ -59,7 +59,7 @@ static DEFINE_SPINLOCK(stopmachine_lock)
>  static void stopmachine_set_state(enum stopmachine_state state)
>  {
>      atomic_set(&stopmachine_data.done, 0);
> -    smp_wmb();
> +    wmb();
>      stopmachine_data.state = state;
>  }
>  
> @@ -99,7 +99,7 @@ int stop_machine_run(int (*fn)(void *), 
>      atomic_set(&stopmachine_data.done, 0);
>      stopmachine_data.state = STOPMACHINE_START;
>  
> -    smp_wmb();
> +    wmb();
>  
>      for_each_cpu ( i, &allbutself )
>          tasklet_schedule_on_cpu(&per_cpu(stopmachine_tasklet, i), i);
> @@ -134,7 +134,7 @@ static void stopmachine_action(unsigned 
>  
>      BUG_ON(cpu != smp_processor_id());
>  
> -    smp_mb();
> +    mb();
>  
>      while ( state != STOPMACHINE_EXIT )
>      {
> @@ -157,7 +157,7 @@ static void stopmachine_action(unsigned 
>              break;
>          }
>  
> -        smp_mb();
> +        mb();
>          atomic_inc(&stopmachine_data.done);
>      }
>  
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/asm-x86/system.h
> --- a/xen/include/asm-x86/system.h
> +++ b/xen/include/asm-x86/system.h
> @@ -154,10 +154,6 @@ static always_inline unsigned long __cmp
>  #define rmb()           barrier()
>  #define wmb()           barrier()
>  
> -#define smp_mb()        mb()
> -#define smp_rmb()       rmb()
> -#define smp_wmb()       wmb()
> -
>  #define set_mb(var, value) do { xchg(&var, value); } while (0)
>  #define set_wmb(var, value) do { var = value; wmb(); } while (0)
>  
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/list.h
> --- a/xen/include/xen/list.h
> +++ b/xen/include/xen/list.h
> @@ -102,7 +102,7 @@ static inline void __list_add_rcu(struct
>  {
>      new->next = next;
>      new->prev = prev;
> -    smp_wmb();
> +    wmb();
>      next->prev = new;
>      prev->next = new;
>  }
> @@ -244,7 +244,7 @@ static inline void list_replace_rcu(stru
>  {
>      new->next = old->next;
>      new->prev = old->prev;
> -    smp_wmb();
> +    wmb();
>      new->next->prev = new;
>      new->prev->next = new;
>      old->prev = LIST_POISON2;
> @@ -712,7 +712,7 @@ static inline void hlist_replace_rcu(str
>  
>      new->next = next;
>      new->pprev = old->pprev;
> -    smp_wmb();
> +    wmb();
>      if (next)
>          new->next->pprev = &new->next;
>      *new->pprev = new;
> @@ -754,7 +754,7 @@ static inline void hlist_add_head_rcu(st
>      struct hlist_node *first = h->first;
>      n->next = first;
>      n->pprev = &h->first;
> -    smp_wmb();
> +    wmb();
>      if (first)
>          first->pprev = &n->next;
>      h->first = n;
> @@ -804,7 +804,7 @@ static inline void hlist_add_before_rcu(
>  {
>      n->pprev = next->pprev;
>      n->next = next;
> -    smp_wmb();
> +    wmb();
>      next->pprev = &n->next;
>      *(n->pprev) = n;
>  }
> @@ -832,7 +832,7 @@ static inline void hlist_add_after_rcu(s
>  {
>      n->next = prev->next;
>      n->pprev = &prev->next;
> -    smp_wmb();
> +    wmb();
>      prev->next = n;
>      if (n->next)
>          n->next->pprev = &n->next;
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/rcupdate.h
> --- a/xen/include/xen/rcupdate.h
> +++ b/xen/include/xen/rcupdate.h
> @@ -136,7 +136,7 @@ typedef struct _rcu_read_lock rcu_read_l
>   * call documents which pointers will be dereferenced by RCU read-side
>   * code.
>   */
> -#define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); })
> +#define rcu_assign_pointer(p, v) ({ wmb(); (p) = (v); })
>  
>  void rcu_init(void);
>  void rcu_check_callbacks(int cpu);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:49:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10: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.xensource.com>)
	id 1RvRZI-0003mF-Lg; Thu, 09 Feb 2012 10:49:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRZG-0003m4-GT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:49:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328784567!12660920!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 676 invoked from network); 9 Feb 2012 10:49:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 10:49:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 10:49:27 +0000
Message-Id: <4F33B2C50200007800071DA5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 10:49:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<957b5ac44e32778242a9.1328719537@andrewcoop.uk.xensource.com>
In-Reply-To: <957b5ac44e32778242a9.1328719537@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier
 definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 17:45, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Now CONFIG_SMP has been removed, there is no need to define
> smp_{,r,w}mb()s which used to conditionally compiled to different
> operations (even though those conditonally different operations still
> ended up as simple barrier()s)
> 
> Therefore, remove smp_{,r,w}mb()s and just use regular {,r,w}mb()s

Did you read the Linux side description and usage guidelines before
doing this? I don't think doing the adjustment here is a good idea,
even if the smp_ ones are aliases of the plain ones (which doesn't
necessarily have to the case on any future architectures Xen might
get ported to).

Jan

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -260,7 +260,7 @@ static void mwait_idle_with_hints(unsign
>      s_time_t expires = per_cpu(timer_deadline, cpu);
>  
>      __monitor((void *)&mwait_wakeup(cpu), 0, 0);
> -    smp_mb();
> +    mb();
>  
>      /*
>       * Timer deadline passing is the event on which we will be woken via
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/cpu/mtrr/main.c
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -248,7 +248,7 @@ static void set_mtrr(unsigned int reg, u
>  
>  	/* ok, reset count and toggle gate */
>  	atomic_set(&data.count, nr_cpus);
> -	smp_wmb();
> +	wmb();
>  	atomic_set(&data.gate,1);
>  
>  	/* do our MTRR business */
> @@ -271,7 +271,7 @@ static void set_mtrr(unsigned int reg, u
>  		cpu_relax();
>  
>  	atomic_set(&data.count, nr_cpus);
> -	smp_wmb();
> +	wmb();
>  	atomic_set(&data.gate,0);
>  
>  	/*
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -207,7 +207,7 @@ static void dynamic_irq_cleanup(unsigned
>      spin_unlock_irqrestore(&desc->lock, flags);
>  
>      /* Wait to make sure it's not being used on another CPU */
> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
>      if (action)
>          xfree(action);
> @@ -931,7 +931,7 @@ void __init release_irq(unsigned int irq
>      spin_unlock_irqrestore(&desc->lock,flags);
>  
>      /* Wait to make sure it's not being used on another CPU */
> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
>      if (action && action->free_on_release)
>          xfree(action);
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -544,7 +544,7 @@ void domain_shutdown(struct domain *d, u
>  
>      d->is_shutting_down = 1;
>  
> -    smp_mb(); /* set shutdown status /then/ check for per-cpu deferrals */
> +    mb(); /* set shutdown status /then/ check for per-cpu deferrals */
>  
>      for_each_vcpu ( d, v )
>      {
> @@ -594,7 +594,7 @@ int vcpu_start_shutdown_deferral(struct 
>          return 1;
>  
>      v->defer_shutdown = 1;
> -    smp_mb(); /* set deferral status /then/ check for shutdown */
> +    mb(); /* set deferral status /then/ check for shutdown */
>      if ( unlikely(v->domain->is_shutting_down) )
>          vcpu_check_shutdown(v);
>  
> @@ -604,7 +604,7 @@ int vcpu_start_shutdown_deferral(struct 
>  void vcpu_end_shutdown_deferral(struct vcpu *v)
>  {
>      v->defer_shutdown = 0;
> -    smp_mb(); /* clear deferral status /then/ check for shutdown */
> +    mb(); /* clear deferral status /then/ check for shutdown */
>      if ( unlikely(v->domain->is_shutting_down) )
>          vcpu_check_shutdown(v);
>  }
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/rcupdate.c
> --- a/xen/common/rcupdate.c
> +++ b/xen/common/rcupdate.c
> @@ -252,7 +252,7 @@ static void rcu_start_batch(struct rcu_c
>           * next_pending == 0 must be visible in
>           * __rcu_process_callbacks() before it can see new value of cur.
>           */
> -        smp_wmb();
> +        wmb();
>          rcp->cur++;
>  
>          cpumask_copy(&rcp->cpumask, &cpu_online_map);
> @@ -340,7 +340,7 @@ static void __rcu_process_callbacks(stru
>          /* see the comment and corresponding wmb() in
>           * the rcu_start_batch()
>           */
> -        smp_rmb();
> +        rmb();
>  
>          if (!rcp->next_pending) {
>              /* and start it/schedule start if it's a new batch */
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/schedule.c
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -657,7 +657,7 @@ static long do_poll(struct sched_poll *s
>  
>  #ifndef CONFIG_X86 /* set_bit() implies mb() on x86 */
>      /* Check for events /after/ setting flags: avoids wakeup waiting race. 
> */
> -    smp_mb();
> +    mb();
>  
>      /*
>       * Someone may have seen we are blocked but not that we are polling, or
> @@ -1173,12 +1173,12 @@ static void schedule(void)
>  void context_saved(struct vcpu *prev)
>  {
>      /* Clear running flag /after/ writing context to memory. */
> -    smp_wmb();
> +    wmb();
>  
>      prev->is_running = 0;
>  
>      /* Check for migration request /after/ clearing running flag. */
> -    smp_mb();
> +    mb();
>  
>      SCHED_OP(VCPU2OP(prev), context_saved, prev);
>  
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/stop_machine.c
> --- a/xen/common/stop_machine.c
> +++ b/xen/common/stop_machine.c
> @@ -59,7 +59,7 @@ static DEFINE_SPINLOCK(stopmachine_lock)
>  static void stopmachine_set_state(enum stopmachine_state state)
>  {
>      atomic_set(&stopmachine_data.done, 0);
> -    smp_wmb();
> +    wmb();
>      stopmachine_data.state = state;
>  }
>  
> @@ -99,7 +99,7 @@ int stop_machine_run(int (*fn)(void *), 
>      atomic_set(&stopmachine_data.done, 0);
>      stopmachine_data.state = STOPMACHINE_START;
>  
> -    smp_wmb();
> +    wmb();
>  
>      for_each_cpu ( i, &allbutself )
>          tasklet_schedule_on_cpu(&per_cpu(stopmachine_tasklet, i), i);
> @@ -134,7 +134,7 @@ static void stopmachine_action(unsigned 
>  
>      BUG_ON(cpu != smp_processor_id());
>  
> -    smp_mb();
> +    mb();
>  
>      while ( state != STOPMACHINE_EXIT )
>      {
> @@ -157,7 +157,7 @@ static void stopmachine_action(unsigned 
>              break;
>          }
>  
> -        smp_mb();
> +        mb();
>          atomic_inc(&stopmachine_data.done);
>      }
>  
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/asm-x86/system.h
> --- a/xen/include/asm-x86/system.h
> +++ b/xen/include/asm-x86/system.h
> @@ -154,10 +154,6 @@ static always_inline unsigned long __cmp
>  #define rmb()           barrier()
>  #define wmb()           barrier()
>  
> -#define smp_mb()        mb()
> -#define smp_rmb()       rmb()
> -#define smp_wmb()       wmb()
> -
>  #define set_mb(var, value) do { xchg(&var, value); } while (0)
>  #define set_wmb(var, value) do { var = value; wmb(); } while (0)
>  
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/list.h
> --- a/xen/include/xen/list.h
> +++ b/xen/include/xen/list.h
> @@ -102,7 +102,7 @@ static inline void __list_add_rcu(struct
>  {
>      new->next = next;
>      new->prev = prev;
> -    smp_wmb();
> +    wmb();
>      next->prev = new;
>      prev->next = new;
>  }
> @@ -244,7 +244,7 @@ static inline void list_replace_rcu(stru
>  {
>      new->next = old->next;
>      new->prev = old->prev;
> -    smp_wmb();
> +    wmb();
>      new->next->prev = new;
>      new->prev->next = new;
>      old->prev = LIST_POISON2;
> @@ -712,7 +712,7 @@ static inline void hlist_replace_rcu(str
>  
>      new->next = next;
>      new->pprev = old->pprev;
> -    smp_wmb();
> +    wmb();
>      if (next)
>          new->next->pprev = &new->next;
>      *new->pprev = new;
> @@ -754,7 +754,7 @@ static inline void hlist_add_head_rcu(st
>      struct hlist_node *first = h->first;
>      n->next = first;
>      n->pprev = &h->first;
> -    smp_wmb();
> +    wmb();
>      if (first)
>          first->pprev = &n->next;
>      h->first = n;
> @@ -804,7 +804,7 @@ static inline void hlist_add_before_rcu(
>  {
>      n->pprev = next->pprev;
>      n->next = next;
> -    smp_wmb();
> +    wmb();
>      next->pprev = &n->next;
>      *(n->pprev) = n;
>  }
> @@ -832,7 +832,7 @@ static inline void hlist_add_after_rcu(s
>  {
>      n->next = prev->next;
>      n->pprev = &prev->next;
> -    smp_wmb();
> +    wmb();
>      prev->next = n;
>      if (n->next)
>          n->next->pprev = &n->next;
> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/rcupdate.h
> --- a/xen/include/xen/rcupdate.h
> +++ b/xen/include/xen/rcupdate.h
> @@ -136,7 +136,7 @@ typedef struct _rcu_read_lock rcu_read_l
>   * call documents which pointers will be dereferenced by RCU read-side
>   * code.
>   */
> -#define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); })
> +#define rcu_assign_pointer(p, v) ({ wmb(); (p) = (v); })
>  
>  void rcu_init(void);
>  void rcu_check_callbacks(int cpu);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:50:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRZl-0003p4-2y; Thu, 09 Feb 2012 10:50:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvRZj-0003oZ-Vd
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:50:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328784597!14080357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13308 invoked from network); 9 Feb 2012 10:49:58 -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;
	9 Feb 2012 10:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10593675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:49:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	10:49:58 +0000
Message-ID: <1328784596.6133.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 9 Feb 2012 10:49:56 +0000
In-Reply-To: <1328782971857-5469072.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
	<1328782971857-5469072.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 10:22 +0000, Fantu wrote:
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24701:3574f4d67843

Thanks but I also need to see the xenstore-ls -fp corresponding to each
case. For simplicity lets just concentrate on the
"/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom" case for now. Once we have
solved that we can revisit any others which are still broken.

The issue is, I suspect, related to the lack of ID_CDROM=1 in most of
your outputs. Running "/lib/udev/cdrom_id $DEV" ought to produce some
related output, if not please can you use strace to observe the ioctls
it is making (and post the log).

I suspect this is more likely to be a udev issue with Linux Mint /
Ubuntu. Have you searched the appropriate bug trackers / wikis / etc for
those distros?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:50:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRZl-0003p4-2y; Thu, 09 Feb 2012 10:50:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvRZj-0003oZ-Vd
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:50:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328784597!14080357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13308 invoked from network); 9 Feb 2012 10:49:58 -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;
	9 Feb 2012 10:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10593675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:49:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	10:49:58 +0000
Message-ID: <1328784596.6133.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 9 Feb 2012 10:49:56 +0000
In-Reply-To: <1328782971857-5469072.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
	<1328782971857-5469072.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 10:22 +0000, Fantu wrote:
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24701:3574f4d67843

Thanks but I also need to see the xenstore-ls -fp corresponding to each
case. For simplicity lets just concentrate on the
"/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom" case for now. Once we have
solved that we can revisit any others which are still broken.

The issue is, I suspect, related to the lack of ID_CDROM=1 in most of
your outputs. Running "/lib/udev/cdrom_id $DEV" ought to produce some
related output, if not please can you use strace to observe the ioctls
it is making (and post the log).

I suspect this is more likely to be a udev issue with Linux Mint /
Ubuntu. Have you searched the appropriate bug trackers / wikis / etc for
those distros?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:52:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRbU-00041m-ML; Thu, 09 Feb 2012 10:51:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvRbT-00041a-2I
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:51:51 +0000
Received: from [85.158.139.83:36456] by server-5.bemta-5.messagelabs.com id
	4F/7C-03847-645A33F4; Thu, 09 Feb 2012 10:51:50 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328784708!14347594!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29945 invoked from network); 9 Feb 2012 10:51:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 10:51:49 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19ApmUR030126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 05:51:48 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19Apk5M008553; Thu, 9 Feb 2012 05:51:46 -0500
Message-ID: <4F33A541.6080401@redhat.com>
Date: Thu, 09 Feb 2012 11:51:45 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<20120209085343.GC18866@redhat.com>
In-Reply-To: <20120209085343.GC18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
	to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

>>                 Pretend that resume was caused by power button */
>>              pm1a->sts |=
>>                  (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
> Here we should report real reason for a wakeup (if it can be reported in
> mp1sts that is).

These are available I guess?

/* PM1x_STS */
#define ACPI_BITMASK_TIMER_STATUS               0x0001
#define ACPI_BITMASK_BUS_MASTER_STATUS          0x0010
#define ACPI_BITMASK_GLOBAL_LOCK_STATUS         0x0020
#define ACPI_BITMASK_POWER_BUTTON_STATUS        0x0100
#define ACPI_BITMASK_SLEEP_BUTTON_STATUS        0x0200
#define ACPI_BITMASK_RT_CLOCK_STATUS            0x0400
#define ACPI_BITMASK_PCIEXP_WAKE_STATUS         0x4000  /* ACPI 3.0 */
#define ACPI_BITMASK_WAKE_STATUS                0x8000

What do they mean?  How would the rtc wakeup be tagged?  Set
ACPI_BITMASK_RT_CLOCK_STATUS?  Anything I can use for ps/2 kbd/mouse
wakeup?  What do you suggest to do when there is nothing usable (such as
qemu monitor command which simply doesn't exist on real hardware)?

thanks,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:52:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRbU-00041m-ML; Thu, 09 Feb 2012 10:51:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvRbT-00041a-2I
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:51:51 +0000
Received: from [85.158.139.83:36456] by server-5.bemta-5.messagelabs.com id
	4F/7C-03847-645A33F4; Thu, 09 Feb 2012 10:51:50 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328784708!14347594!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29945 invoked from network); 9 Feb 2012 10:51:49 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 10:51:49 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19ApmUR030126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 05:51:48 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19Apk5M008553; Thu, 9 Feb 2012 05:51:46 -0500
Message-ID: <4F33A541.6080401@redhat.com>
Date: Thu, 09 Feb 2012 11:51:45 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<20120209085343.GC18866@redhat.com>
In-Reply-To: <20120209085343.GC18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
	to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

>>                 Pretend that resume was caused by power button */
>>              pm1a->sts |=
>>                  (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
> Here we should report real reason for a wakeup (if it can be reported in
> mp1sts that is).

These are available I guess?

/* PM1x_STS */
#define ACPI_BITMASK_TIMER_STATUS               0x0001
#define ACPI_BITMASK_BUS_MASTER_STATUS          0x0010
#define ACPI_BITMASK_GLOBAL_LOCK_STATUS         0x0020
#define ACPI_BITMASK_POWER_BUTTON_STATUS        0x0100
#define ACPI_BITMASK_SLEEP_BUTTON_STATUS        0x0200
#define ACPI_BITMASK_RT_CLOCK_STATUS            0x0400
#define ACPI_BITMASK_PCIEXP_WAKE_STATUS         0x4000  /* ACPI 3.0 */
#define ACPI_BITMASK_WAKE_STATUS                0x8000

What do they mean?  How would the rtc wakeup be tagged?  Set
ACPI_BITMASK_RT_CLOCK_STATUS?  Anything I can use for ps/2 kbd/mouse
wakeup?  What do you suggest to do when there is nothing usable (such as
qemu monitor command which simply doesn't exist on real hardware)?

thanks,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:54:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRe1-0004Fs-GS; Thu, 09 Feb 2012 10:54:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRe0-0004Fl-Ey
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:54:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328784817!53538733!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17007 invoked from network); 9 Feb 2012 10:53:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 10:53:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 10:54:26 +0000
Message-Id: <4F33B3F10200007800071DAE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 10:54:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
	<4F32AF53.5070006@citrix.com>
In-Reply-To: <4F32AF53.5070006@citrix.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>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 18:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

Doing this in x86 code is perhaps fine; you shouldn't do this in common
code though (ia64, for example, allows [at least theoretically] to be
built non-SMP, even though particularly on that architecture this seems
to make very little sense).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:54:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRe1-0004Fs-GS; Thu, 09 Feb 2012 10:54:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRe0-0004Fl-Ey
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:54:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328784817!53538733!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17007 invoked from network); 9 Feb 2012 10:53:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 10:53:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 10:54:26 +0000
Message-Id: <4F33B3F10200007800071DAE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 10:54:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
	<4F32AF53.5070006@citrix.com>
In-Reply-To: <4F32AF53.5070006@citrix.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>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 18:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

Doing this in x86 code is perhaps fine; you shouldn't do this in common
code though (ia64, for example, allows [at least theoretically] to be
built non-SMP, even though particularly on that architecture this seems
to make very little sense).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:59:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRiB-0004T7-6Y; Thu, 09 Feb 2012 10:58:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvRi9-0004Sx-SH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:58:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328785119!13828670!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22145 invoked from network); 9 Feb 2012 10:58:39 -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;
	9 Feb 2012 10:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10593938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:58:39 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 10:58:39 +0000
Date: Thu, 9 Feb 2012 10:58:34 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328768914.13189.70.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:

> On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> > On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >          }
> > > >
> > > >          if (strchr(listen, ':') != NULL)
> > > > -            flexarray_append(dm_args,
> > > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > > -                        info->vncunused ? ",to=99" : ""));
> > > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > > >          else
> > > > -            flexarray_append(dm_args,
> > > > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > > > -                        info->vncunused ? ",to=99" : ""));
> > > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > > +        }
> > > > +        if (info->vncunused) {
> > > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> > >
> > > Not new, but I've been meaning to ask: what is to=99 for here? It seems
> > > a bit arbitrary and the default behaviour without it appears to be to
> > > keep looking for an available port which sounds like what we want.
> >
> > QEMU will search for an open port until it reach the vnc display port 99
> > (5999 TCP port).
> >
> > For the 99, I probably read this number somewhere. But after checking in
> > QEMU code, I do not see any limitation for this number. So we could
> > probably change this number for the port number max (-5900, default vnc
> > port).
>
> Can we not just omit it altogether and let qemu do its default thing?

I did not find any default configuration for a VNC display in QEMU. We
have to provide every option we want. The minimum is hostname:display,
and QEMU will only tries to bind this address, or fails and quit. So to
"simulated" -vncunused, we have to provide a ",to=i" options to try
every single port between 5900 and 5900+i, and this option needs to be
last :(.

I hope this respond to your question.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 10:59:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 10:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRiB-0004T7-6Y; Thu, 09 Feb 2012 10:58:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvRi9-0004Sx-SH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 10:58:46 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328785119!13828670!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22145 invoked from network); 9 Feb 2012 10:58:39 -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;
	9 Feb 2012 10:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10593938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 10:58:39 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 10:58:39 +0000
Date: Thu, 9 Feb 2012 10:58:34 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328768914.13189.70.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:

> On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> > On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >          }
> > > >
> > > >          if (strchr(listen, ':') != NULL)
> > > > -            flexarray_append(dm_args,
> > > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > > -                        info->vncunused ? ",to=99" : ""));
> > > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > > >          else
> > > > -            flexarray_append(dm_args,
> > > > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > > > -                        info->vncunused ? ",to=99" : ""));
> > > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > > +        }
> > > > +        if (info->vncunused) {
> > > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> > >
> > > Not new, but I've been meaning to ask: what is to=99 for here? It seems
> > > a bit arbitrary and the default behaviour without it appears to be to
> > > keep looking for an available port which sounds like what we want.
> >
> > QEMU will search for an open port until it reach the vnc display port 99
> > (5999 TCP port).
> >
> > For the 99, I probably read this number somewhere. But after checking in
> > QEMU code, I do not see any limitation for this number. So we could
> > probably change this number for the port number max (-5900, default vnc
> > port).
>
> Can we not just omit it altogether and let qemu do its default thing?

I did not find any default configuration for a VNC display in QEMU. We
have to provide every option we want. The minimum is hostname:display,
and QEMU will only tries to bind this address, or fails and quit. So to
"simulated" -vncunused, we have to provide a ",to=i" options to try
every single port between 5900 and 5900+i, and this option needs to be
last :(.

I hope this respond to your question.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:03:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRmW-0004eK-So; Thu, 09 Feb 2012 11:03:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRmV-0004e8-Gh
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:03:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328785388!10633544!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9654 invoked from network); 9 Feb 2012 11:03:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 11:03:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 11:03:08 +0000
Message-Id: <4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 11:03:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
	<4F32AFBF.7090201@citrix.com>
In-Reply-To: <4F32AFBF.7090201@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>@@ -227,12 +223,6 @@ static int vioapic_write(
>         vioapic_write_indirect(vioapic, length, val);
>         break;
> 
>-#if VIOAPIC_IS_IOSAPIC
>-    case VIOAPIC_REG_EOI:
>-        vioapic_update_EOI(v->domain, val);
>-        break;
>-#endif
>-

Would you mind keeping that code, putting the call inside a conditional
checking VIOAPIC_VERSION_ID >= 0x20?

Jan

>     default:
>         break;
>     }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:03:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRmW-0004eK-So; Thu, 09 Feb 2012 11:03:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRmV-0004e8-Gh
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:03:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328785388!10633544!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9654 invoked from network); 9 Feb 2012 11:03:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 11:03:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 11:03:08 +0000
Message-Id: <4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 11:03:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
	<4F32AFBF.7090201@citrix.com>
In-Reply-To: <4F32AFBF.7090201@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 08.02.12 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>@@ -227,12 +223,6 @@ static int vioapic_write(
>         vioapic_write_indirect(vioapic, length, val);
>         break;
> 
>-#if VIOAPIC_IS_IOSAPIC
>-    case VIOAPIC_REG_EOI:
>-        vioapic_update_EOI(v->domain, val);
>-        break;
>-#endif
>-

Would you mind keeping that code, putting the call inside a conditional
checking VIOAPIC_VERSION_ID >= 0x20?

Jan

>     default:
>         break;
>     }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:10:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvRt2-0004p8-UP; Thu, 09 Feb 2012 11:10:00 +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 1RvRt1-0004oz-Hf
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:09:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328785765!59135709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31677 invoked from network); 9 Feb 2012 11:09:25 -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;
	9 Feb 2012 11:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10594463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:09:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 11:09:55 +0000
Date: Thu, 9 Feb 2012 11:13:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Gerd Hoffmann <kraxel@redhat.com>
In-Reply-To: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
Message-ID: <alpine.DEB.2.00.1202091112570.22056@kaball-desktop>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new
 infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Gerd Hoffmann wrote:
> This patch switches pc s3 suspend over to the new infrastructure.
> The cmos_s3 qemu_irq is killed, the new notifier is used instead.
> The xen hack goes away with that too, the hypercall can simply be
> done in a notifier function now.

nice cleanup

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:10:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvRt2-0004p8-UP; Thu, 09 Feb 2012 11:10:00 +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 1RvRt1-0004oz-Hf
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:09:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328785765!59135709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31677 invoked from network); 9 Feb 2012 11:09:25 -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;
	9 Feb 2012 11:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10594463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:09:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 11:09:55 +0000
Date: Thu, 9 Feb 2012 11:13:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Gerd Hoffmann <kraxel@redhat.com>
In-Reply-To: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
Message-ID: <alpine.DEB.2.00.1202091112570.22056@kaball-desktop>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new
 infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 8 Feb 2012, Gerd Hoffmann wrote:
> This patch switches pc s3 suspend over to the new infrastructure.
> The cmos_s3 qemu_irq is killed, the new notifier is used instead.
> The xen hack goes away with that too, the hypercall can simply be
> done in a notifier function now.

nice cleanup

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:10:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRtB-0004pm-B1; Thu, 09 Feb 2012 11:10:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RvRtA-0004pP-HW
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:10:08 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328785799!12664574!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27876 invoked from network); 9 Feb 2012 11:10:01 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.11)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 11:10:01 -0000
Received: from mail192-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 11:09:59 +0000
Received: from mail192-tx2 (localhost [127.0.0.1])	by
	mail192-tx2-R.bigfish.com (Postfix) with ESMTP id 7E4C42A053F	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:09:59 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail192-tx2 (localhost.localdomain [127.0.0.1]) by mail192-tx2
	(MessageSwitch) id 1328785796220502_17765;
	Thu,  9 Feb 2012 11:09:56 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.239])	by
	mail192-tx2.bigfish.com (Postfix) with ESMTP id 28E033A024E	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:09:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 11:09:51 +0000
X-WSS-ID: 0LZ4HOD-02-2EO-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 2B4A5C8064	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 05:09:48 -0600 (CST)
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, 9 Feb 2012 05:10:04 -0600
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.289.1;
	Thu, 9 Feb 2012 05:09:50 -0600
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, 9 Feb 2012
	06:09:49 -0500
Message-ID: <4F33A97C.3000500@amd.com>
Date: Thu, 9 Feb 2012 12:09:48 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------060102030603000500050603"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] tools: fix qemu build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060102030603000500050603
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Pass --python=$(PYTHON) to qemu's configure.
Fixes error:
Python not found. Use --python=/path/to/python

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------060102030603000500050603
Content-Type: text/plain; name="xen_tools_qemu.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_qemu.diff"
Content-Description: xen_tools_qemu.diff

diff -r f27d5c83b05e tools/Makefile
--- a/tools/Makefile	Mon Feb 06 14:12:36 2012 +0100
+++ b/tools/Makefile	Thu Feb 09 11:59:11 2012 +0100
@@ -156,6 +156,7 @@ subdir-all-qemu-xen-dir subdir-install-q
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=$(LIBEXEC) \
 		--disable-kvm \
+		--python=$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install
 

--------------060102030603000500050603
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060102030603000500050603--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:10:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRtB-0004pm-B1; Thu, 09 Feb 2012 11:10:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RvRtA-0004pP-HW
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:10:08 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328785799!12664574!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27876 invoked from network); 9 Feb 2012 11:10:01 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.11)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 11:10:01 -0000
Received: from mail192-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 11:09:59 +0000
Received: from mail192-tx2 (localhost [127.0.0.1])	by
	mail192-tx2-R.bigfish.com (Postfix) with ESMTP id 7E4C42A053F	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:09:59 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail192-tx2 (localhost.localdomain [127.0.0.1]) by mail192-tx2
	(MessageSwitch) id 1328785796220502_17765;
	Thu,  9 Feb 2012 11:09:56 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.239])	by
	mail192-tx2.bigfish.com (Postfix) with ESMTP id 28E033A024E	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:09:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 11:09:51 +0000
X-WSS-ID: 0LZ4HOD-02-2EO-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 2B4A5C8064	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 05:09:48 -0600 (CST)
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, 9 Feb 2012 05:10:04 -0600
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.289.1;
	Thu, 9 Feb 2012 05:09:50 -0600
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, 9 Feb 2012
	06:09:49 -0500
Message-ID: <4F33A97C.3000500@amd.com>
Date: Thu, 9 Feb 2012 12:09:48 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------060102030603000500050603"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] tools: fix qemu build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060102030603000500050603
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Pass --python=$(PYTHON) to qemu's configure.
Fixes error:
Python not found. Use --python=/path/to/python

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------060102030603000500050603
Content-Type: text/plain; name="xen_tools_qemu.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_qemu.diff"
Content-Description: xen_tools_qemu.diff

diff -r f27d5c83b05e tools/Makefile
--- a/tools/Makefile	Mon Feb 06 14:12:36 2012 +0100
+++ b/tools/Makefile	Thu Feb 09 11:59:11 2012 +0100
@@ -156,6 +156,7 @@ subdir-all-qemu-xen-dir subdir-install-q
 		-L$(XEN_ROOT)/tools/xenstore" \
 		--bindir=$(LIBEXEC) \
 		--disable-kvm \
+		--python=$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) install
 

--------------060102030603000500050603
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060102030603000500050603--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:14:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRxP-00055p-3M; Thu, 09 Feb 2012 11:14:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvRxN-00055c-Rw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:14:30 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328786061!14271109!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24292 invoked from network); 9 Feb 2012 11:14:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 11:14:22 -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 q19BEKV3023598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 06:14:20 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19BEJak030088; Thu, 9 Feb 2012 06:14:20 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 682D2133EEF; Thu,  9 Feb 2012 13:14:19 +0200 (IST)
Date: Thu, 9 Feb 2012 13:14:19 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209111419.GG18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<20120209085343.GC18866@redhat.com> <4F33A541.6080401@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33A541.6080401@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 11:51:45AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >>                 Pretend that resume was caused by power button */
> >>              pm1a->sts |=
> >>                  (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
> > Here we should report real reason for a wakeup (if it can be reported in
> > mp1sts that is).
> 
> These are available I guess?
> 
Yes. Once those defines had the same names as ACPI spec, but some kind soul
renamed them to be more "descriptive". So forgive me if I will use names
that you actually can lookup in ACPI spec.

> /* PM1x_STS */
> #define ACPI_BITMASK_TIMER_STATUS               0x0001
> #define ACPI_BITMASK_BUS_MASTER_STATUS          0x0010
> #define ACPI_BITMASK_GLOBAL_LOCK_STATUS         0x0020
> #define ACPI_BITMASK_POWER_BUTTON_STATUS        0x0100
> #define ACPI_BITMASK_SLEEP_BUTTON_STATUS        0x0200
> #define ACPI_BITMASK_RT_CLOCK_STATUS            0x0400
> #define ACPI_BITMASK_PCIEXP_WAKE_STATUS         0x4000  /* ACPI 3.0 */
> #define ACPI_BITMASK_WAKE_STATUS                0x8000
> 
Only three of those are actually wakeup source related:
PWRBTN_STS (bit 8)
RTC_STS (bit 10)
PCIEXP_WAKE_STS (bit 14)

And of course if system was awoken WAK_STS (bit 15) should be set too.

> What do they mean?  How would the rtc wakeup be tagged?  Set
> ACPI_BITMASK_RT_CLOCK_STATUS?  Anything I can use for ps/2 kbd/mouse
> wakeup?  What do you suggest to do when there is nothing usable (such as
> qemu monitor command which simply doesn't exist on real hardware)?
> 
RTC will set RTC_STS. In other reply I suggested to use PWRBTN_STS for
monitor command wakeup. Other devices are more complicated :( They have
to provide _PRW (Power Resources for Wake) method in the device
description in DSDT. This method, among other things, specifies which
bit in GPE (and which GPE) correspond to the device.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:14:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRxP-00055p-3M; Thu, 09 Feb 2012 11:14:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvRxN-00055c-Rw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:14:30 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328786061!14271109!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24292 invoked from network); 9 Feb 2012 11:14:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 11:14:22 -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 q19BEKV3023598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 06:14:20 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19BEJak030088; Thu, 9 Feb 2012 06:14:20 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 682D2133EEF; Thu,  9 Feb 2012 13:14:19 +0200 (IST)
Date: Thu, 9 Feb 2012 13:14:19 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209111419.GG18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<20120209085343.GC18866@redhat.com> <4F33A541.6080401@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33A541.6080401@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 11:51:45AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >>                 Pretend that resume was caused by power button */
> >>              pm1a->sts |=
> >>                  (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
> > Here we should report real reason for a wakeup (if it can be reported in
> > mp1sts that is).
> 
> These are available I guess?
> 
Yes. Once those defines had the same names as ACPI spec, but some kind soul
renamed them to be more "descriptive". So forgive me if I will use names
that you actually can lookup in ACPI spec.

> /* PM1x_STS */
> #define ACPI_BITMASK_TIMER_STATUS               0x0001
> #define ACPI_BITMASK_BUS_MASTER_STATUS          0x0010
> #define ACPI_BITMASK_GLOBAL_LOCK_STATUS         0x0020
> #define ACPI_BITMASK_POWER_BUTTON_STATUS        0x0100
> #define ACPI_BITMASK_SLEEP_BUTTON_STATUS        0x0200
> #define ACPI_BITMASK_RT_CLOCK_STATUS            0x0400
> #define ACPI_BITMASK_PCIEXP_WAKE_STATUS         0x4000  /* ACPI 3.0 */
> #define ACPI_BITMASK_WAKE_STATUS                0x8000
> 
Only three of those are actually wakeup source related:
PWRBTN_STS (bit 8)
RTC_STS (bit 10)
PCIEXP_WAKE_STS (bit 14)

And of course if system was awoken WAK_STS (bit 15) should be set too.

> What do they mean?  How would the rtc wakeup be tagged?  Set
> ACPI_BITMASK_RT_CLOCK_STATUS?  Anything I can use for ps/2 kbd/mouse
> wakeup?  What do you suggest to do when there is nothing usable (such as
> qemu monitor command which simply doesn't exist on real hardware)?
> 
RTC will set RTC_STS. In other reply I suggested to use PWRBTN_STS for
monitor command wakeup. Other devices are more complicated :( They have
to provide _PRW (Power Resources for Wake) method in the device
description in DSDT. This method, among other things, specifies which
bit in GPE (and which GPE) correspond to the device.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:15:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRyR-0005AE-II; Thu, 09 Feb 2012 11:15:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRyP-00059v-LC
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:15:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328786109!65136327!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5312 invoked from network); 9 Feb 2012 11:15:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 11:15:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 11:15:31 +0000
Message-Id: <4F33B8E30200007800071DD0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 11:15:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7D530CC3.0__="
Subject: [Xen-devel] [PATCH] gnttab: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7D530CC3.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- _GTF_* constants name bit positions, so binary arithmetic on them is
  wrong
- gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
  clear_bit(), as that may access more than the two bytes that are
  intended to be accessed

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
              (id !=3D domid) ||
              (!readonly && (flags & GTF_readonly)) )
         {
-            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
+            gnttab_clear_flag(_GTF_writing, status);
+            gnttab_clear_flag(_GTF_reading, status);
             PIN_FAIL(done, GNTST_general_error,
                      "Unstable flags (%x) or dom (%d). (expected dom %d) =
"
                      "(r/w: %d)\n",
@@ -1716,14 +1717,14 @@ __release_grant_for_copy(
    under the domain's grant table lock. */
 /* Only safe on transitive grants.  Even then, note that we don't
    attempt to drop any pin on the referent grant. */
-static void __fixup_status_for_pin(struct active_grant_entry *act,
+static void __fixup_status_for_pin(const struct active_grant_entry *act,
                                    uint16_t *status)
 {
     if ( !(act->pin & GNTPIN_hstw_mask) )
-        *status &=3D ~_GTF_writing;
+        *status &=3D ~GTF_writing;
=20
     if ( !(act->pin & GNTPIN_hstr_mask) )
-        *status &=3D ~_GTF_reading;
+        *status &=3D ~GTF_reading;
 }
=20
 /* Grab a frame number from a grant entry and update the flags and pin
--- a/xen/include/asm-ia64/grant_table.h
+++ b/xen/include/asm-ia64/grant_table.h
@@ -5,6 +5,8 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
=20
+#include <asm/intrinsics.h>
+
 #define INITIAL_NR_GRANT_FRAMES 1
=20
 // for grant map/unmap
@@ -82,9 +84,19 @@ int guest_physmap_add_page(struct domain
=20
 #define gnttab_mark_dirty(d, f) ((void)f)
=20
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t =
*st)
 {
-	clear_bit(nr, addr);
+	/*
+	 * Note that this cannot be clear_bit(), as the access must be
+	 * confined to the specified 2 bytes.
+	 */
+	uint16_t mask =3D ~(1 << nr), old;
+	CMPXCHG_BUGCHECK_DECL
+
+	do {
+		CMPXCHG_BUGCHECK(st);
+		old =3D *st;
+	} while (cmpxchg_rel(st, old, old & mask) !=3D old);
 }
=20
 #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -48,9 +48,13 @@ int replace_grant_host_mapping(
=20
 #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
=20
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, uint16_t *st)
 {
-    clear_bit(nr, (unsigned long *)addr);
+    /*
+     * Note that this cannot be clear_bit(), as the access must be
+     * confined to the specified 2 bytes.
+     */
+    asm volatile ("lock btrw %1,%0" : "=3Dm" (*st) : "Ir" (nr), "m" =
(*st));
 }
=20
 /* Foreign mappings of HHVM-guest pages do not modify the type count. */




--=__Part7D530CC3.0__=
Content-Type: text/plain; name="gnttab-misc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gnttab-misc.patch"

gnttab: miscellaneous fixes=0A=0A- _GTF_* constants name bit positions, so =
binary arithmetic on them is=0A  wrong=0A- gnttab_clear_flag() cannot (on =
x86 and ia64 at least) simply use=0A  clear_bit(), as that may access more =
than the two bytes that are=0A  intended to be accessed=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -397,7 +397,8 @@ static int _set_status_v2(=
domid_t  domid=0A              (id !=3D domid) ||=0A              =
(!readonly && (flags & GTF_readonly)) )=0A         {=0A-            =
gnttab_clear_flag(_GTF_reading | _GTF_writing, status);=0A+            =
gnttab_clear_flag(_GTF_writing, status);=0A+            gnttab_clear_flag(_=
GTF_reading, status);=0A             PIN_FAIL(done, GNTST_general_error,=0A=
                      "Unstable flags (%x) or dom (%d). (expected dom %d) =
"=0A                      "(r/w: %d)\n",=0A@@ -1716,14 +1717,14 @@ =
__release_grant_for_copy(=0A    under the domain's grant table lock. */=0A =
/* Only safe on transitive grants.  Even then, note that we don't=0A    =
attempt to drop any pin on the referent grant. */=0A-static void __fixup_st=
atus_for_pin(struct active_grant_entry *act,=0A+static void __fixup_status_=
for_pin(const struct active_grant_entry *act,=0A                           =
         uint16_t *status)=0A {=0A     if ( !(act->pin & GNTPIN_hstw_mask) =
)=0A-        *status &=3D ~_GTF_writing;=0A+        *status &=3D ~GTF_writi=
ng;=0A =0A     if ( !(act->pin & GNTPIN_hstr_mask) )=0A-        *status =
&=3D ~_GTF_reading;=0A+        *status &=3D ~GTF_reading;=0A }=0A =0A /* =
Grab a frame number from a grant entry and update the flags and pin=0A--- =
a/xen/include/asm-ia64/grant_table.h=0A+++ b/xen/include/asm-ia64/grant_tab=
le.h=0A@@ -5,6 +5,8 @@=0A #ifndef __ASM_GRANT_TABLE_H__=0A #define =
__ASM_GRANT_TABLE_H__=0A =0A+#include <asm/intrinsics.h>=0A+=0A #define =
INITIAL_NR_GRANT_FRAMES 1=0A =0A // for grant map/unmap=0A@@ -82,9 +84,19 =
@@ int guest_physmap_add_page(struct domain=0A =0A #define gnttab_mark_dirt=
y(d, f) ((void)f)=0A =0A-static inline void gnttab_clear_flag(unsigned =
long nr, uint16_t *addr)=0A+static inline void gnttab_clear_flag(unsigned =
int nr, volatile uint16_t *st)=0A {=0A-	clear_bit(nr, addr);=0A+	=
/*=0A+	 * Note that this cannot be clear_bit(), as the access must be=0A+	=
 * confined to the specified 2 bytes.=0A+	 */=0A+	uint16_t mask =3D =
~(1 << nr), old;=0A+	CMPXCHG_BUGCHECK_DECL=0A+=0A+	do {=0A+		=
CMPXCHG_BUGCHECK(st);=0A+		old =3D *st;=0A+	} while =
(cmpxchg_rel(st, old, old & mask) !=3D old);=0A }=0A =0A #define gnttab_hos=
t_mapping_get_page_type(op, ld, rd)   \=0A--- a/xen/include/asm-x86/grant_t=
able.h=0A+++ b/xen/include/asm-x86/grant_table.h=0A@@ -48,9 +48,13 @@ int =
replace_grant_host_mapping(=0A =0A #define gnttab_mark_dirty(d, f) =
paging_mark_dirty((d), (f))=0A =0A-static inline void gnttab_clear_flag(uns=
igned long nr, uint16_t *addr)=0A+static inline void gnttab_clear_flag(unsi=
gned int nr, uint16_t *st)=0A {=0A-    clear_bit(nr, (unsigned long =
*)addr);=0A+    /*=0A+     * Note that this cannot be clear_bit(), as the =
access must be=0A+     * confined to the specified 2 bytes.=0A+     */=0A+ =
   asm volatile ("lock btrw %1,%0" : "=3Dm" (*st) : "Ir" (nr), "m" =
(*st));=0A }=0A =0A /* Foreign mappings of HHVM-guest pages do not modify =
the type count. */=0A
--=__Part7D530CC3.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part7D530CC3.0__=--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:15:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvRyR-0005AE-II; Thu, 09 Feb 2012 11:15:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvRyP-00059v-LC
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:15:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328786109!65136327!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5312 invoked from network); 9 Feb 2012 11:15:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 11:15:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 11:15:31 +0000
Message-Id: <4F33B8E30200007800071DD0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 11:15:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7D530CC3.0__="
Subject: [Xen-devel] [PATCH] gnttab: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part7D530CC3.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- _GTF_* constants name bit positions, so binary arithmetic on them is
  wrong
- gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
  clear_bit(), as that may access more than the two bytes that are
  intended to be accessed

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
              (id !=3D domid) ||
              (!readonly && (flags & GTF_readonly)) )
         {
-            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
+            gnttab_clear_flag(_GTF_writing, status);
+            gnttab_clear_flag(_GTF_reading, status);
             PIN_FAIL(done, GNTST_general_error,
                      "Unstable flags (%x) or dom (%d). (expected dom %d) =
"
                      "(r/w: %d)\n",
@@ -1716,14 +1717,14 @@ __release_grant_for_copy(
    under the domain's grant table lock. */
 /* Only safe on transitive grants.  Even then, note that we don't
    attempt to drop any pin on the referent grant. */
-static void __fixup_status_for_pin(struct active_grant_entry *act,
+static void __fixup_status_for_pin(const struct active_grant_entry *act,
                                    uint16_t *status)
 {
     if ( !(act->pin & GNTPIN_hstw_mask) )
-        *status &=3D ~_GTF_writing;
+        *status &=3D ~GTF_writing;
=20
     if ( !(act->pin & GNTPIN_hstr_mask) )
-        *status &=3D ~_GTF_reading;
+        *status &=3D ~GTF_reading;
 }
=20
 /* Grab a frame number from a grant entry and update the flags and pin
--- a/xen/include/asm-ia64/grant_table.h
+++ b/xen/include/asm-ia64/grant_table.h
@@ -5,6 +5,8 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
=20
+#include <asm/intrinsics.h>
+
 #define INITIAL_NR_GRANT_FRAMES 1
=20
 // for grant map/unmap
@@ -82,9 +84,19 @@ int guest_physmap_add_page(struct domain
=20
 #define gnttab_mark_dirty(d, f) ((void)f)
=20
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t =
*st)
 {
-	clear_bit(nr, addr);
+	/*
+	 * Note that this cannot be clear_bit(), as the access must be
+	 * confined to the specified 2 bytes.
+	 */
+	uint16_t mask =3D ~(1 << nr), old;
+	CMPXCHG_BUGCHECK_DECL
+
+	do {
+		CMPXCHG_BUGCHECK(st);
+		old =3D *st;
+	} while (cmpxchg_rel(st, old, old & mask) !=3D old);
 }
=20
 #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -48,9 +48,13 @@ int replace_grant_host_mapping(
=20
 #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
=20
-static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
+static inline void gnttab_clear_flag(unsigned int nr, uint16_t *st)
 {
-    clear_bit(nr, (unsigned long *)addr);
+    /*
+     * Note that this cannot be clear_bit(), as the access must be
+     * confined to the specified 2 bytes.
+     */
+    asm volatile ("lock btrw %1,%0" : "=3Dm" (*st) : "Ir" (nr), "m" =
(*st));
 }
=20
 /* Foreign mappings of HHVM-guest pages do not modify the type count. */




--=__Part7D530CC3.0__=
Content-Type: text/plain; name="gnttab-misc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gnttab-misc.patch"

gnttab: miscellaneous fixes=0A=0A- _GTF_* constants name bit positions, so =
binary arithmetic on them is=0A  wrong=0A- gnttab_clear_flag() cannot (on =
x86 and ia64 at least) simply use=0A  clear_bit(), as that may access more =
than the two bytes that are=0A  intended to be accessed=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -397,7 +397,8 @@ static int _set_status_v2(=
domid_t  domid=0A              (id !=3D domid) ||=0A              =
(!readonly && (flags & GTF_readonly)) )=0A         {=0A-            =
gnttab_clear_flag(_GTF_reading | _GTF_writing, status);=0A+            =
gnttab_clear_flag(_GTF_writing, status);=0A+            gnttab_clear_flag(_=
GTF_reading, status);=0A             PIN_FAIL(done, GNTST_general_error,=0A=
                      "Unstable flags (%x) or dom (%d). (expected dom %d) =
"=0A                      "(r/w: %d)\n",=0A@@ -1716,14 +1717,14 @@ =
__release_grant_for_copy(=0A    under the domain's grant table lock. */=0A =
/* Only safe on transitive grants.  Even then, note that we don't=0A    =
attempt to drop any pin on the referent grant. */=0A-static void __fixup_st=
atus_for_pin(struct active_grant_entry *act,=0A+static void __fixup_status_=
for_pin(const struct active_grant_entry *act,=0A                           =
         uint16_t *status)=0A {=0A     if ( !(act->pin & GNTPIN_hstw_mask) =
)=0A-        *status &=3D ~_GTF_writing;=0A+        *status &=3D ~GTF_writi=
ng;=0A =0A     if ( !(act->pin & GNTPIN_hstr_mask) )=0A-        *status =
&=3D ~_GTF_reading;=0A+        *status &=3D ~GTF_reading;=0A }=0A =0A /* =
Grab a frame number from a grant entry and update the flags and pin=0A--- =
a/xen/include/asm-ia64/grant_table.h=0A+++ b/xen/include/asm-ia64/grant_tab=
le.h=0A@@ -5,6 +5,8 @@=0A #ifndef __ASM_GRANT_TABLE_H__=0A #define =
__ASM_GRANT_TABLE_H__=0A =0A+#include <asm/intrinsics.h>=0A+=0A #define =
INITIAL_NR_GRANT_FRAMES 1=0A =0A // for grant map/unmap=0A@@ -82,9 +84,19 =
@@ int guest_physmap_add_page(struct domain=0A =0A #define gnttab_mark_dirt=
y(d, f) ((void)f)=0A =0A-static inline void gnttab_clear_flag(unsigned =
long nr, uint16_t *addr)=0A+static inline void gnttab_clear_flag(unsigned =
int nr, volatile uint16_t *st)=0A {=0A-	clear_bit(nr, addr);=0A+	=
/*=0A+	 * Note that this cannot be clear_bit(), as the access must be=0A+	=
 * confined to the specified 2 bytes.=0A+	 */=0A+	uint16_t mask =3D =
~(1 << nr), old;=0A+	CMPXCHG_BUGCHECK_DECL=0A+=0A+	do {=0A+		=
CMPXCHG_BUGCHECK(st);=0A+		old =3D *st;=0A+	} while =
(cmpxchg_rel(st, old, old & mask) !=3D old);=0A }=0A =0A #define gnttab_hos=
t_mapping_get_page_type(op, ld, rd)   \=0A--- a/xen/include/asm-x86/grant_t=
able.h=0A+++ b/xen/include/asm-x86/grant_table.h=0A@@ -48,9 +48,13 @@ int =
replace_grant_host_mapping(=0A =0A #define gnttab_mark_dirty(d, f) =
paging_mark_dirty((d), (f))=0A =0A-static inline void gnttab_clear_flag(uns=
igned long nr, uint16_t *addr)=0A+static inline void gnttab_clear_flag(unsi=
gned int nr, uint16_t *st)=0A {=0A-    clear_bit(nr, (unsigned long =
*)addr);=0A+    /*=0A+     * Note that this cannot be clear_bit(), as the =
access must be=0A+     * confined to the specified 2 bytes.=0A+     */=0A+ =
   asm volatile ("lock btrw %1,%0" : "=3Dm" (*st) : "Ir" (nr), "m" =
(*st));=0A }=0A =0A /* Foreign mappings of HHVM-guest pages do not modify =
the type count. */=0A
--=__Part7D530CC3.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part7D530CC3.0__=--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:17:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvS06-0005Ly-AO; Thu, 09 Feb 2012 11:17:18 +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 1RvS05-0005Lo-75
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:17:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328786192!59427285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31527 invoked from network); 9 Feb 2012 11: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;
	9 Feb 2012 11:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10594671"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:17:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	11:17:16 +0000
Message-ID: <1328786234.6133.142.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 11:17:14 +0000
In-Reply-To: <alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 10:58 +0000, Anthony PERARD wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> 
> > On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> > > On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > > > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > >          }
> > > > >
> > > > >          if (strchr(listen, ':') != NULL)
> > > > > -            flexarray_append(dm_args,
> > > > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > > > >          else
> > > > > -            flexarray_append(dm_args,
> > > > > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > > > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > > > +        }
> > > > > +        if (info->vncunused) {
> > > > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> > > >
> > > > Not new, but I've been meaning to ask: what is to=99 for here? It seems
> > > > a bit arbitrary and the default behaviour without it appears to be to
> > > > keep looking for an available port which sounds like what we want.
> > >
> > > QEMU will search for an open port until it reach the vnc display port 99
> > > (5999 TCP port).
> > >
> > > For the 99, I probably read this number somewhere. But after checking in
> > > QEMU code, I do not see any limitation for this number. So we could
> > > probably change this number for the port number max (-5900, default vnc
> > > port).
> >
> > Can we not just omit it altogether and let qemu do its default thing?
> 
> I did not find any default configuration for a VNC display in QEMU. We
> have to provide every option we want. The minimum is hostname:display,
> and QEMU will only tries to bind this address, or fails and quit. So to
> "simulated" -vncunused, we have to provide a ",to=i" options to try
> every single port between 5900 and 5900+i, and this option needs to be
> last :(.

I see, I didn't realise the upstream qemu was missing a "just find me a
port" option.

> I hope this respond to your question.

Yes, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:17:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvS06-0005Ly-AO; Thu, 09 Feb 2012 11:17:18 +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 1RvS05-0005Lo-75
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:17:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328786192!59427285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31527 invoked from network); 9 Feb 2012 11: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;
	9 Feb 2012 11:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10594671"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:17:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	11:17:16 +0000
Message-ID: <1328786234.6133.142.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 11:17:14 +0000
In-Reply-To: <alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 10:58 +0000, Anthony PERARD wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> 
> > On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> > > On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > > > @@ -287,13 +285,16 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > > >          }
> > > > >
> > > > >          if (strchr(listen, ':') != NULL)
> > > > > -            flexarray_append(dm_args,
> > > > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > > > >          else
> > > > > -            flexarray_append(dm_args,
> > > > > -                    libxl__sprintf(gc, "%s:%d%s", listen, display,
> > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
> > > > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > > > +        }
> > > > > +        if (info->vncunused) {
> > > > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> > > >
> > > > Not new, but I've been meaning to ask: what is to=99 for here? It seems
> > > > a bit arbitrary and the default behaviour without it appears to be to
> > > > keep looking for an available port which sounds like what we want.
> > >
> > > QEMU will search for an open port until it reach the vnc display port 99
> > > (5999 TCP port).
> > >
> > > For the 99, I probably read this number somewhere. But after checking in
> > > QEMU code, I do not see any limitation for this number. So we could
> > > probably change this number for the port number max (-5900, default vnc
> > > port).
> >
> > Can we not just omit it altogether and let qemu do its default thing?
> 
> I did not find any default configuration for a VNC display in QEMU. We
> have to provide every option we want. The minimum is hostname:display,
> and QEMU will only tries to bind this address, or fails and quit. So to
> "simulated" -vncunused, we have to provide a ",to=i" options to try
> every single port between 5900 and 5900+i, and this option needs to be
> last :(.

I see, I didn't realise the upstream qemu was missing a "just find me a
port" option.

> I hope this respond to your question.

Yes, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:17:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvS0b-0005Ql-Os; Thu, 09 Feb 2012 11:17:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1RvS0a-0005PO-Dn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:17:48 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328786260!12672347!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6483 invoked from network); 9 Feb 2012 11:17:42 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 11:17:42 -0000
Received: by pbbro2 with SMTP id ro2so5403957pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 03:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=N7GanajZGrW9hXJ7mZvLi0MFTGu5qqadc1Fa1q02UYM=;
	b=lNTMcJil2RAna4QNMS/NPJcQdAS/Cquzwye2dvv4TU6rWP7n8sJnZyWtG+xqUNNpRZ
	jDEKluSMWO9P28a6iBXmIirci1E2ZcOAAu3JZbLuRPdyUgGBE3JtpmcllyF/9aHFdnrC
	+UYBP1DBBGPujKexWDpBfX6NCabbOQXWvk91U=
Received: by 10.68.223.68 with SMTP id qs4mr4796939pbc.112.1328786259983;
	Thu, 09 Feb 2012 03:17:39 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id p2sm5408746pbb.14.2012.02.09.03.17.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 03:17:38 -0800 (PST)
Message-ID: <4F33AB4D.9070904@redhat.com>
Date: Thu, 09 Feb 2012 12:17:33 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gerd Hoffmann <kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new
	infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/08/2012 12:00 PM, Gerd Hoffmann wrote:
> +/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> +   BIOS will read it and start S3 resume at POST Entry */
> +static void rtc_notify_suspend(Notifier *notifier, void *data)
> +{
> +    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
> +    rtc_set_memory(&s->dev, 0xF, 0xFE);
> +}
> +

Out of curiosity, who would set this on real hardware?  And since RTC 
memory is nvram, what happens if I remove the mains plug while the 
system is in S3?

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:17:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvS0b-0005Ql-Os; Thu, 09 Feb 2012 11:17:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1RvS0a-0005PO-Dn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:17:48 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328786260!12672347!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6483 invoked from network); 9 Feb 2012 11:17:42 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 11:17:42 -0000
Received: by pbbro2 with SMTP id ro2so5403957pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 03:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=N7GanajZGrW9hXJ7mZvLi0MFTGu5qqadc1Fa1q02UYM=;
	b=lNTMcJil2RAna4QNMS/NPJcQdAS/Cquzwye2dvv4TU6rWP7n8sJnZyWtG+xqUNNpRZ
	jDEKluSMWO9P28a6iBXmIirci1E2ZcOAAu3JZbLuRPdyUgGBE3JtpmcllyF/9aHFdnrC
	+UYBP1DBBGPujKexWDpBfX6NCabbOQXWvk91U=
Received: by 10.68.223.68 with SMTP id qs4mr4796939pbc.112.1328786259983;
	Thu, 09 Feb 2012 03:17:39 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id p2sm5408746pbb.14.2012.02.09.03.17.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 03:17:38 -0800 (PST)
Message-ID: <4F33AB4D.9070904@redhat.com>
Date: Thu, 09 Feb 2012 12:17:33 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gerd Hoffmann <kraxel@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
In-Reply-To: <1328698819-31269-3-git-send-email-kraxel@redhat.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new
	infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/08/2012 12:00 PM, Gerd Hoffmann wrote:
> +/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> +   BIOS will read it and start S3 resume at POST Entry */
> +static void rtc_notify_suspend(Notifier *notifier, void *data)
> +{
> +    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
> +    rtc_set_memory(&s->dev, 0xF, 0xFE);
> +}
> +

Out of curiosity, who would set this on real hardware?  And since RTC 
memory is nvram, what happens if I remove the mains plug while the 
system is in S3?

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:19:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvS2N-0005i3-98; Thu, 09 Feb 2012 11:19:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvS2L-0005hK-1T
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:19:37 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328786370!4265231!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15773 invoked from network); 9 Feb 2012 11:19:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 11:19:30 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19BJT7j025018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 06:19:29 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19BJTdB016614; Thu, 9 Feb 2012 06:19:29 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 7019F133EEF; Thu,  9 Feb 2012 13:19:28 +0200 (IST)
Date: Thu, 9 Feb 2012 13:19:28 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209111928.GH18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33A3C1.1080108@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 11:45:21AM +0100, Gerd Hoffmann wrote:
> On 02/09/12 09:48, Gleb Natapov wrote:
> > On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
> >>  * qemu_system_wakeup_request is supposed to be called on events which
> >>    should wake up the guest.
> >>
> > qemu_system_wakeup_request() should get wakeup source as a parameter.
> > There are ways to report it to a guest.
> 
> Can we do that incrementally, when we actually implement the guest
> reporting?
> 
What do you mean by "when we actually implement the guest
reporting"? The guest reporting is part of ACPI spec and implemented
by all relevant guests. I think that adding wakeup source parameter to
qemu_system_wakeup_request() and reporting RTC_STS and PWRBTN_STS should
not complicate your patch series to much. I agree that DSDT magic required
by other devices can wait for later.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:19:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvS2N-0005i3-98; Thu, 09 Feb 2012 11:19:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvS2L-0005hK-1T
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:19:37 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328786370!4265231!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15773 invoked from network); 9 Feb 2012 11:19:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 11:19:30 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19BJT7j025018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 06:19:29 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19BJTdB016614; Thu, 9 Feb 2012 06:19:29 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 7019F133EEF; Thu,  9 Feb 2012 13:19:28 +0200 (IST)
Date: Thu, 9 Feb 2012 13:19:28 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209111928.GH18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33A3C1.1080108@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 11:45:21AM +0100, Gerd Hoffmann wrote:
> On 02/09/12 09:48, Gleb Natapov wrote:
> > On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
> >>  * qemu_system_wakeup_request is supposed to be called on events which
> >>    should wake up the guest.
> >>
> > qemu_system_wakeup_request() should get wakeup source as a parameter.
> > There are ways to report it to a guest.
> 
> Can we do that incrementally, when we actually implement the guest
> reporting?
> 
What do you mean by "when we actually implement the guest
reporting"? The guest reporting is part of ACPI spec and implemented
by all relevant guests. I think that adding wakeup source parameter to
qemu_system_wakeup_request() and reporting RTC_STS and PWRBTN_STS should
not complicate your patch series to much. I agree that DSDT magic required
by other devices can wait for later.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvSAi-00060d-By; Thu, 09 Feb 2012 11:28:16 +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 1RvSAg-00060V-GR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:28:14 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328786863!52206669!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14908 invoked from network); 9 Feb 2012 11:27:45 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE002.bigfish.com) (65.55.88.12)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 11:27:45 -0000
Received: from mail115-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 11:28:06 +0000
Received: from mail115-tx2 (localhost [127.0.0.1])	by
	mail115-tx2-R.bigfish.com (Postfix) with ESMTP id 4D1AE34020A	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:28:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2
	(MessageSwitch) id 1328786884438414_11414;
	Thu,  9 Feb 2012 11:28:04 +0000 (UTC)
Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.249])	by
	mail115-tx2.bigfish.com (Postfix) with ESMTP id 689A860045	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:28:04 +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; Thu, 9 Feb 2012 11:28:02 +0000
X-WSS-ID: 0LZ4IIP-01-2MX-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 253C710282B4	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 05:28:00 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 9 Feb 2012 05:28:15 -0600
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.289.1;
	Thu, 9 Feb 2012 05:28:00 -0600
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, 9 Feb 2012
	06:27:58 -0500
Message-ID: <4F33ADBD.5080502@amd.com>
Date: Thu, 9 Feb 2012 12:27:57 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------040906010209040104030605"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040906010209040104030605
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Pass PYTHON=$(PYTHON) to gmake when building seabios.
This fixes seabios build error
'python not found'
along with the patches from Kevin O'Connor.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------040906010209040104030605
Content-Type: text/plain; name="xen_tools_seabios.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_seabios.diff"
Content-Description: xen_tools_seabios.diff

diff -r f27d5c83b05e tools/firmware/Makefile
--- a/tools/firmware/Makefile	Mon Feb 06 14:12:36 2012 +0100
+++ b/tools/firmware/Makefile	Thu Feb 09 12:21:42 2012 +0100
@@ -25,7 +25,7 @@ all: seabios-dir
 	echo "==========================================================================="; \
 	false ; \
 	fi
-	$(MAKE) subdirs-$@; \
+	$(MAKE) PYTHON=$(PYTHON) subdirs-$@; \
 
 
 .PHONY: install

--------------040906010209040104030605
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040906010209040104030605--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvSAi-00060d-By; Thu, 09 Feb 2012 11:28:16 +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 1RvSAg-00060V-GR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:28:14 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328786863!52206669!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14908 invoked from network); 9 Feb 2012 11:27:45 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE002.bigfish.com) (65.55.88.12)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 11:27:45 -0000
Received: from mail115-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 11:28:06 +0000
Received: from mail115-tx2 (localhost [127.0.0.1])	by
	mail115-tx2-R.bigfish.com (Postfix) with ESMTP id 4D1AE34020A	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:28:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2
	(MessageSwitch) id 1328786884438414_11414;
	Thu,  9 Feb 2012 11:28:04 +0000 (UTC)
Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.249])	by
	mail115-tx2.bigfish.com (Postfix) with ESMTP id 689A860045	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 11:28:04 +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; Thu, 9 Feb 2012 11:28:02 +0000
X-WSS-ID: 0LZ4IIP-01-2MX-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 253C710282B4	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 05:28:00 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 9 Feb 2012 05:28:15 -0600
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.289.1;
	Thu, 9 Feb 2012 05:28:00 -0600
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, 9 Feb 2012
	06:27:58 -0500
Message-ID: <4F33ADBD.5080502@amd.com>
Date: Thu, 9 Feb 2012 12:27:57 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------040906010209040104030605"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040906010209040104030605
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Pass PYTHON=$(PYTHON) to gmake when building seabios.
This fixes seabios build error
'python not found'
along with the patches from Kevin O'Connor.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------040906010209040104030605
Content-Type: text/plain; name="xen_tools_seabios.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_seabios.diff"
Content-Description: xen_tools_seabios.diff

diff -r f27d5c83b05e tools/firmware/Makefile
--- a/tools/firmware/Makefile	Mon Feb 06 14:12:36 2012 +0100
+++ b/tools/firmware/Makefile	Thu Feb 09 12:21:42 2012 +0100
@@ -25,7 +25,7 @@ all: seabios-dir
 	echo "==========================================================================="; \
 	false ; \
 	fi
-	$(MAKE) subdirs-$@; \
+	$(MAKE) PYTHON=$(PYTHON) subdirs-$@; \
 
 
 .PHONY: install

--------------040906010209040104030605
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040906010209040104030605--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:39:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvSLG-0006F5-Im; Thu, 09 Feb 2012 11:39:10 +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 1RvSLF-0006F0-Bm
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:39:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328787484!60398720!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8449 invoked from network); 9 Feb 2012 11:38:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 11:38:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328787547; l=1641;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=G1uKHI0yy7lVt7wgwKzJ8Th1Bbs=;
	b=XYyxHS7meu4AMg0wdZKzSY54Alu0+ajwDFqS3VJGoIcrB2u7/ZNCFFvZcxuM+iFkPuf
	ZladSI6aV8eUVb0RrUYBb4jb+6mMm71kNPI60gNc8OQF8f6WUdTOGsaCgkSkVsrlok3F2
	C8nKHkdHbZupwleOB4ZTkzYmeFUygU4ois4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo53) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 20030ao19AdZJz
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 12:38:55 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4742D18634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 12:39:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6176980d3c0d969e71a9eebf43d3e2cfb6ca4025
Message-Id: <6176980d3c0d969e71a9.1328787541@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 12:39:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxl: use libxl wrapper for
	yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328787526 -3600
# Node ID 6176980d3c0d969e71a9eebf43d3e2cfb6ca4025
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
tools/libxl: use libxl wrapper for yajl_gen_alloc

To fix compile errors with libyajl2:
use libxl__yajl_gen_alloc()
use libxl_yajl_length
link xl with -lyajl for yajl_gen_string()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -297,13 +297,12 @@ static void printf_info(enum output_form
     if (output_format == OUTPUT_FORMAT_SXP)
         return printf_info_sexp(domid, d_config);
 
-    yajl_gen_config conf = { 1, "    " };
     const char *buf;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
     if (!hand) {
         fprintf(stderr, "unable to allocate JSON generator\n");
         return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:39:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvSLG-0006F5-Im; Thu, 09 Feb 2012 11:39:10 +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 1RvSLF-0006F0-Bm
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:39:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328787484!60398720!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8449 invoked from network); 9 Feb 2012 11:38:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 11:38:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328787547; l=1641;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=G1uKHI0yy7lVt7wgwKzJ8Th1Bbs=;
	b=XYyxHS7meu4AMg0wdZKzSY54Alu0+ajwDFqS3VJGoIcrB2u7/ZNCFFvZcxuM+iFkPuf
	ZladSI6aV8eUVb0RrUYBb4jb+6mMm71kNPI60gNc8OQF8f6WUdTOGsaCgkSkVsrlok3F2
	C8nKHkdHbZupwleOB4ZTkzYmeFUygU4ois4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo53) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 20030ao19AdZJz
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 12:38:55 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4742D18634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 12:39:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6176980d3c0d969e71a9eebf43d3e2cfb6ca4025
Message-Id: <6176980d3c0d969e71a9.1328787541@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 12:39:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxl: use libxl wrapper for
	yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328787526 -3600
# Node ID 6176980d3c0d969e71a9eebf43d3e2cfb6ca4025
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
tools/libxl: use libxl wrapper for yajl_gen_alloc

To fix compile errors with libyajl2:
use libxl__yajl_gen_alloc()
use libxl_yajl_length
link xl with -lyajl for yajl_gen_string()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -297,13 +297,12 @@ static void printf_info(enum output_form
     if (output_format == OUTPUT_FORMAT_SXP)
         return printf_info_sexp(domid, d_config);
 
-    yajl_gen_config conf = { 1, "    " };
     const char *buf;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
     if (!hand) {
         fprintf(stderr, "unable to allocate JSON generator\n");
         return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:50:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvSVb-0006ca-OG; Thu, 09 Feb 2012 11:49:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvSVZ-0006cS-UO
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:49:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328788183!12669663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9894 invoked from network); 9 Feb 2012 11:49:44 -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;
	9 Feb 2012 11:49:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10595929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:49:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	11:49:28 +0000
Message-ID: <1328788166.6133.147.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 11:49:26 +0000
In-Reply-To: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/27] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:35 +0000, Stefano Stabellini wrote:
> Hello everyone,
> this is the sixth version of the patch series that introduces ARMv7
> with virtualization extensions support in Xen.
> The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
> Express simulator.
> See the following announce email for more informations about what we
> are trying to achieve, as well as the original git history:
> 
> See http://marc.info/?l=xen-devel&m=132257857628098&w=2
> 
> 
> The first 7 patches affect generic Xen code and are not ARM specific;
> often they fix real issues, hidden in the default X86 configuration.

I have committed patches 7 (generic code, applied with Keir's ACK) and
patches 8-24. However I stopped before applying #25 "arm: makefiles"
because the full series failed to build with:

        make[3]: Entering directory
        `/local/scratch/ianc/devel/committer.hg/xen/common'
        /home/ianc/devel/cross/gcc-4.6.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -O1 -fno-omit-frame-pointer -marm -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/local/scratch/ianc/devel/committer.hg/xen/include -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -march=armv7-a -mcpu=cortex-a15 -fno-optimize-sibling-calls -g -D__XEN__ -include /local/scratch/ianc/devel/committer.hg/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .event_channel.o.d -c event_channel.c -o event_channel.o
        event_channel.c: In function 'domain_dump_evtchn_info':
        event_channel.c:1297:13: error: implicit declaration of function
        'domain_pirq_to_irq' [-Werror=implicit-function-declaration]
        event_channel.c:1297:13: error: nested extern declaration of
        'domain_pirq_to_irq' [-Werror=nested-externs]
        cc1: all warnings being treated as errors

domain_pirq_to_irq has been in the tree for quite some time so I guess
something has changed wrt implicit #includes? Can you fixup and resend
the fix plus the last three patches please.

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:50:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvSVb-0006ca-OG; Thu, 09 Feb 2012 11:49:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvSVZ-0006cS-UO
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:49:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328788183!12669663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9894 invoked from network); 9 Feb 2012 11:49:44 -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;
	9 Feb 2012 11:49:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10595929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:49:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	11:49:28 +0000
Message-ID: <1328788166.6133.147.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 11:49:26 +0000
In-Reply-To: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/27] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:35 +0000, Stefano Stabellini wrote:
> Hello everyone,
> this is the sixth version of the patch series that introduces ARMv7
> with virtualization extensions support in Xen.
> The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
> Express simulator.
> See the following announce email for more informations about what we
> are trying to achieve, as well as the original git history:
> 
> See http://marc.info/?l=xen-devel&m=132257857628098&w=2
> 
> 
> The first 7 patches affect generic Xen code and are not ARM specific;
> often they fix real issues, hidden in the default X86 configuration.

I have committed patches 7 (generic code, applied with Keir's ACK) and
patches 8-24. However I stopped before applying #25 "arm: makefiles"
because the full series failed to build with:

        make[3]: Entering directory
        `/local/scratch/ianc/devel/committer.hg/xen/common'
        /home/ianc/devel/cross/gcc-4.6.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -O1 -fno-omit-frame-pointer -marm -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/local/scratch/ianc/devel/committer.hg/xen/include -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -march=armv7-a -mcpu=cortex-a15 -fno-optimize-sibling-calls -g -D__XEN__ -include /local/scratch/ianc/devel/committer.hg/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .event_channel.o.d -c event_channel.c -o event_channel.o
        event_channel.c: In function 'domain_dump_evtchn_info':
        event_channel.c:1297:13: error: implicit declaration of function
        'domain_pirq_to_irq' [-Werror=implicit-function-declaration]
        event_channel.c:1297:13: error: nested extern declaration of
        'domain_pirq_to_irq' [-Werror=nested-externs]
        cc1: all warnings being treated as errors

domain_pirq_to_irq has been in the tree for quite some time so I guess
something has changed wrt implicit #includes? Can you fixup and resend
the fix plus the last three patches please.

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:52:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvSXT-0006hV-Dz; Thu, 09 Feb 2012 11:51:47 +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 1RvSXR-0006hN-JX
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:51:45 +0000
Received: from [85.158.139.83:47219] by server-5.bemta-5.messagelabs.com id
	EA/86-03847-053B33F4; Thu, 09 Feb 2012 11:51:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328788301!13518698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5215 invoked from network); 9 Feb 2012 11:51:42 -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;
	9 Feb 2012 11:51:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325480400"; d="scan'208";a="21787353"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06:51:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	06:51:40 -0500
Message-ID: <4F33B34B.30403@citrix.com>
Date: Thu, 9 Feb 2012 11:51:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
	<4F32AF53.5070006@citrix.com>
	<4F33B3F10200007800071DAE@nat28.tlf.novell.com>
In-Reply-To: <4F33B3F10200007800071DAE@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/12 10:54, Jan Beulich wrote:
>>>> On 08.02.12 at 18:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Doing this in x86 code is perhaps fine; you shouldn't do this in common
> code though (ia64, for example, allows [at least theoretically] to be
> built non-SMP, even though particularly on that architecture this seems
> to make very little sense).
>
> Jan

Im some ways, that is the same as x86 !CONFIG_SMP support; theoretically
sensible but we never use it.

Is !SMP 'supported' for IA64 in any way?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:52:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvSXT-0006hV-Dz; Thu, 09 Feb 2012 11:51:47 +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 1RvSXR-0006hN-JX
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:51:45 +0000
Received: from [85.158.139.83:47219] by server-5.bemta-5.messagelabs.com id
	EA/86-03847-053B33F4; Thu, 09 Feb 2012 11:51:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328788301!13518698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5215 invoked from network); 9 Feb 2012 11:51:42 -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;
	9 Feb 2012 11:51:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325480400"; d="scan'208";a="21787353"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06:51:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	06:51:40 -0500
Message-ID: <4F33B34B.30403@citrix.com>
Date: Thu, 9 Feb 2012 11:51:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
	<4F32AF53.5070006@citrix.com>
	<4F33B3F10200007800071DAE@nat28.tlf.novell.com>
In-Reply-To: <4F33B3F10200007800071DAE@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/12 10:54, Jan Beulich wrote:
>>>> On 08.02.12 at 18:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Doing this in x86 code is perhaps fine; you shouldn't do this in common
> code though (ia64, for example, allows [at least theoretically] to be
> built non-SMP, even though particularly on that architecture this seems
> to make very little sense).
>
> Jan

Im some ways, that is the same as x86 !CONFIG_SMP support; theoretically
sensible but we never use it.

Is !SMP 'supported' for IA64 in any way?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:52:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvSYE-0006ky-SW; Thu, 09 Feb 2012 11:52:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvSYD-0006kX-Ps
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:52:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328788345!14075660!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2608 invoked from network); 9 Feb 2012 11:52:27 -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;
	9 Feb 2012 11:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325480400"; d="scan'208";a="21787362"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06:52:25 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	06:52:24 -0500
Message-ID: <4F33B377.4080605@citrix.com>
Date: Thu, 9 Feb 2012 11:52:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
	<4F32AFBF.7090201@citrix.com>
	<4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
In-Reply-To: <4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/12 11:03, Jan Beulich wrote:
>>>> On 08.02.12 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> @@ -227,12 +223,6 @@ static int vioapic_write(
>>         vioapic_write_indirect(vioapic, length, val);
>>         break;
>>
>> -#if VIOAPIC_IS_IOSAPIC
>> -    case VIOAPIC_REG_EOI:
>> -        vioapic_update_EOI(v->domain, val);
>> -        break;
>> -#endif
>> -
> Would you mind keeping that code, putting the call inside a conditional
> checking VIOAPIC_VERSION_ID >= 0x20?
>
> Jan

Yes - In actual fact, I considered the same just after I emailed this patch.

I shall respin.

~Andrew

>>     default:
>>         break;
>>     }

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 11:52:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 11: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.xensource.com>)
	id 1RvSYE-0006ky-SW; Thu, 09 Feb 2012 11:52:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvSYD-0006kX-Ps
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:52:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328788345!14075660!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2608 invoked from network); 9 Feb 2012 11:52:27 -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;
	9 Feb 2012 11:52:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325480400"; d="scan'208";a="21787362"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 06:52:25 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	06:52:24 -0500
Message-ID: <4F33B377.4080605@citrix.com>
Date: Thu, 9 Feb 2012 11:52:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
	<4F32AFBF.7090201@citrix.com>
	<4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
In-Reply-To: <4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/12 11:03, Jan Beulich wrote:
>>>> On 08.02.12 at 18:24, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> @@ -227,12 +223,6 @@ static int vioapic_write(
>>         vioapic_write_indirect(vioapic, length, val);
>>         break;
>>
>> -#if VIOAPIC_IS_IOSAPIC
>> -    case VIOAPIC_REG_EOI:
>> -        vioapic_update_EOI(v->domain, val);
>> -        break;
>> -#endif
>> -
> Would you mind keeping that code, putting the call inside a conditional
> checking VIOAPIC_VERSION_ID >= 0x20?
>
> Jan

Yes - In actual fact, I considered the same just after I emailed this patch.

I shall respin.

~Andrew

>>     default:
>>         break;
>>     }

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvSfP-0007AE-L0; Thu, 09 Feb 2012 11:59:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvSfN-0007A5-NE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:59:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328788791!10746952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9237 invoked from network); 9 Feb 2012 11:59:51 -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;
	9 Feb 2012 11:59:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10596293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:59:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	11:59:52 +0000
Message-ID: <1328788790.6133.148.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 9 Feb 2012 11:59:50 +0000
In-Reply-To: <4F33ADBD.5080502@amd.com>
References: <4F33ADBD.5080502@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> This fixes seabios build error
> 'python not found'
> along with the patches from Kevin O'Connor.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvSfP-0007AE-L0; Thu, 09 Feb 2012 11:59:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvSfN-0007A5-NE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 11:59:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328788791!10746952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9237 invoked from network); 9 Feb 2012 11:59:51 -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;
	9 Feb 2012 11:59:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10596293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 11:59:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	11:59:52 +0000
Message-ID: <1328788790.6133.148.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 9 Feb 2012 11:59:50 +0000
In-Reply-To: <4F33ADBD.5080502@amd.com>
References: <4F33ADBD.5080502@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> This fixes seabios build error
> 'python not found'
> along with the patches from Kevin O'Connor.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:02:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:02:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvShu-0007NU-TS; Thu, 09 Feb 2012 12:02:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvSht-0007NF-HN
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:02:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328788946!10645062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29193 invoked from network); 9 Feb 2012 12:02:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:02:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10596361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 12:02:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	12:02:26 +0000
Message-ID: <1328788945.6133.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 12:02:25 +0000
In-Reply-To: <6176980d3c0d969e71a9.1328787541@probook.site>
References: <6176980d3c0d969e71a9.1328787541@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: use libxl wrapper for
 yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 11:39 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1328787526 -3600
> # Node ID 6176980d3c0d969e71a9eebf43d3e2cfb6ca4025
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> tools/libxl: use libxl wrapper for yajl_gen_alloc
> 
> To fix compile errors with libyajl2:
> use libxl__yajl_gen_alloc()

I didn't notice this when it went in but if this is a public function it
should be libxl_yajl_gen_alloc not libxl__yajl_gen_alloc. Can you also
fix that please?

Ian.

> use libxl_yajl_length
> link xl with -lyajl for yajl_gen_string()
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/Makefile
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
>  	$(AR) rcs libxlutil.a $^
>  
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
> -	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
>  
>  testidl: testidl.o libxlutil.so libxenlight.so
>  	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -297,13 +297,12 @@ static void printf_info(enum output_form
>      if (output_format == OUTPUT_FORMAT_SXP)
>          return printf_info_sexp(domid, d_config);
>  
> -    yajl_gen_config conf = { 1, "    " };
>      const char *buf;
> -    unsigned int len = 0;
> +    libxl_yajl_length len = 0;
>      yajl_gen_status s;
>      yajl_gen hand;
>  
> -    hand = yajl_gen_alloc(&conf, NULL);
> +    hand = libxl__yajl_gen_alloc(NULL);
>      if (!hand) {
>          fprintf(stderr, "unable to allocate JSON generator\n");
>          return;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:02:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:02:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvShu-0007NU-TS; Thu, 09 Feb 2012 12:02:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvSht-0007NF-HN
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:02:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328788946!10645062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29193 invoked from network); 9 Feb 2012 12:02:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:02:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="10596361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 12:02:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	12:02:26 +0000
Message-ID: <1328788945.6133.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 12:02:25 +0000
In-Reply-To: <6176980d3c0d969e71a9.1328787541@probook.site>
References: <6176980d3c0d969e71a9.1328787541@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: use libxl wrapper for
 yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 11:39 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1328787526 -3600
> # Node ID 6176980d3c0d969e71a9eebf43d3e2cfb6ca4025
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> tools/libxl: use libxl wrapper for yajl_gen_alloc
> 
> To fix compile errors with libyajl2:
> use libxl__yajl_gen_alloc()

I didn't notice this when it went in but if this is a public function it
should be libxl_yajl_gen_alloc not libxl__yajl_gen_alloc. Can you also
fix that please?

Ian.

> use libxl_yajl_length
> link xl with -lyajl for yajl_gen_string()
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/Makefile
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
>  	$(AR) rcs libxlutil.a $^
>  
>  xl: $(XL_OBJS) libxlutil.so libxenlight.so
> -	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
>  
>  testidl: testidl.o libxlutil.so libxenlight.so
>  	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> diff -r 8ba7ae0b070b -r 6176980d3c0d tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -297,13 +297,12 @@ static void printf_info(enum output_form
>      if (output_format == OUTPUT_FORMAT_SXP)
>          return printf_info_sexp(domid, d_config);
>  
> -    yajl_gen_config conf = { 1, "    " };
>      const char *buf;
> -    unsigned int len = 0;
> +    libxl_yajl_length len = 0;
>      yajl_gen_status s;
>      yajl_gen hand;
>  
> -    hand = yajl_gen_alloc(&conf, NULL);
> +    hand = libxl__yajl_gen_alloc(NULL);
>      if (!hand) {
>          fprintf(stderr, "unable to allocate JSON generator\n");
>          return;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:03:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvSiJ-0007PW-AM; Thu, 09 Feb 2012 12:02:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvSiH-0007Ow-T7
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:02:58 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328788971!14614754!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9746 invoked from network); 9 Feb 2012 12:02:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 12:02:51 -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 q19C2oox018769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:02:50 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19C2mLx017671; Thu, 9 Feb 2012 07:02:48 -0500
Message-ID: <4F33B5E7.7070502@redhat.com>
Date: Thu, 09 Feb 2012 13:02:47 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com>
In-Reply-To: <20120209111928.GH18866@redhat.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000205040100020909080901"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------000205040100020909080901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/09/12 12:19, Gleb Natapov wrote:
> On Thu, Feb 09, 2012 at 11:45:21AM +0100, Gerd Hoffmann wrote:
>> On 02/09/12 09:48, Gleb Natapov wrote:
>>> On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
>>>>  * qemu_system_wakeup_request is supposed to be called on events which
>>>>    should wake up the guest.
>>>>
>>> qemu_system_wakeup_request() should get wakeup source as a parameter.
>>> There are ways to report it to a guest.
>>
>> Can we do that incrementally, when we actually implement the guest
>> reporting?
>>
> What do you mean by "when we actually implement the guest
> reporting"? The guest reporting is part of ACPI spec and implemented
> by all relevant guests. I think that adding wakeup source parameter to
> qemu_system_wakeup_request() and reporting RTC_STS and PWRBTN_STS should
> not complicate your patch series to much. I agree that DSDT magic required
> by other devices can wait for later.

Incremental patch (just infrastructure, no acpi windup yet) attached.
Something like this?

cheers,
  Gerd

--------------000205040100020909080901
Content-Type: text/plain;
 name="wakeup-reason.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="wakeup-reason.diff"

commit 78fbd17ddc98a2e96e05db62afbe3a69c5fad5e5
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Feb 9 12:52:48 2012 +0100

    reason: infra

diff --git a/sysemu.h b/sysemu.h
index 3b9d7f5..e7060aa 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -38,10 +38,16 @@ void vm_start(void);
 void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
+typedef enum WakeupReason {
+    QEMU_WAKEUP_REASON_OTHER = 0,
+    QEMU_WAKEUP_REASON_RTC,
+} WakeupReason;
+
 void qemu_system_reset_request(void);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
-void qemu_system_wakeup_request(void);
+void qemu_system_wakeup_request(WakeupReason reason);
+void qemu_register_wakeup_notifier(Notifier *notifier);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index 822fd58..17d4b72 100644
--- a/vl.c
+++ b/vl.c
@@ -1286,6 +1286,8 @@ static int debug_requested;
 static bool is_suspended;
 static NotifierList suspend_notifiers =
     NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
+static NotifierList wakeup_notifiers =
+    NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1416,16 +1418,22 @@ void qemu_register_suspend_notifier(Notifier *notifier)
     notifier_list_add(&suspend_notifiers, notifier);
 }
 
-void qemu_system_wakeup_request(void)
+void qemu_system_wakeup_request(WakeupReason reason)
 {
     if (!is_suspended) {
         return;
     }
+    notifier_list_notify(&wakeup_notifiers, &reason);
     reset_requested = 1;
     qemu_notify_event();
     is_suspended = false;
 }
 
+void qemu_register_wakeup_notifier(Notifier *notifier)
+{
+    notifier_list_add(&wakeup_notifiers, notifier);
+}
+
 void qemu_system_killed(int signal, pid_t pid)
 {
     shutdown_signal = signal;

--------------000205040100020909080901
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000205040100020909080901--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:03:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvSiJ-0007PW-AM; Thu, 09 Feb 2012 12:02:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvSiH-0007Ow-T7
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:02:58 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328788971!14614754!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9746 invoked from network); 9 Feb 2012 12:02:51 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 12:02:51 -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 q19C2oox018769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:02:50 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19C2mLx017671; Thu, 9 Feb 2012 07:02:48 -0500
Message-ID: <4F33B5E7.7070502@redhat.com>
Date: Thu, 09 Feb 2012 13:02:47 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com>
In-Reply-To: <20120209111928.GH18866@redhat.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------000205040100020909080901"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------000205040100020909080901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/09/12 12:19, Gleb Natapov wrote:
> On Thu, Feb 09, 2012 at 11:45:21AM +0100, Gerd Hoffmann wrote:
>> On 02/09/12 09:48, Gleb Natapov wrote:
>>> On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
>>>>  * qemu_system_wakeup_request is supposed to be called on events which
>>>>    should wake up the guest.
>>>>
>>> qemu_system_wakeup_request() should get wakeup source as a parameter.
>>> There are ways to report it to a guest.
>>
>> Can we do that incrementally, when we actually implement the guest
>> reporting?
>>
> What do you mean by "when we actually implement the guest
> reporting"? The guest reporting is part of ACPI spec and implemented
> by all relevant guests. I think that adding wakeup source parameter to
> qemu_system_wakeup_request() and reporting RTC_STS and PWRBTN_STS should
> not complicate your patch series to much. I agree that DSDT magic required
> by other devices can wait for later.

Incremental patch (just infrastructure, no acpi windup yet) attached.
Something like this?

cheers,
  Gerd

--------------000205040100020909080901
Content-Type: text/plain;
 name="wakeup-reason.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="wakeup-reason.diff"

commit 78fbd17ddc98a2e96e05db62afbe3a69c5fad5e5
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Feb 9 12:52:48 2012 +0100

    reason: infra

diff --git a/sysemu.h b/sysemu.h
index 3b9d7f5..e7060aa 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -38,10 +38,16 @@ void vm_start(void);
 void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
+typedef enum WakeupReason {
+    QEMU_WAKEUP_REASON_OTHER = 0,
+    QEMU_WAKEUP_REASON_RTC,
+} WakeupReason;
+
 void qemu_system_reset_request(void);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
-void qemu_system_wakeup_request(void);
+void qemu_system_wakeup_request(WakeupReason reason);
+void qemu_register_wakeup_notifier(Notifier *notifier);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index 822fd58..17d4b72 100644
--- a/vl.c
+++ b/vl.c
@@ -1286,6 +1286,8 @@ static int debug_requested;
 static bool is_suspended;
 static NotifierList suspend_notifiers =
     NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
+static NotifierList wakeup_notifiers =
+    NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1416,16 +1418,22 @@ void qemu_register_suspend_notifier(Notifier *notifier)
     notifier_list_add(&suspend_notifiers, notifier);
 }
 
-void qemu_system_wakeup_request(void)
+void qemu_system_wakeup_request(WakeupReason reason)
 {
     if (!is_suspended) {
         return;
     }
+    notifier_list_notify(&wakeup_notifiers, &reason);
     reset_requested = 1;
     qemu_notify_event();
     is_suspended = false;
 }
 
+void qemu_register_wakeup_notifier(Notifier *notifier)
+{
+    notifier_list_add(&wakeup_notifiers, notifier);
+}
+
 void qemu_system_killed(int signal, pid_t pid)
 {
     shutdown_signal = signal;

--------------000205040100020909080901
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000205040100020909080901--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:08:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvSnF-0007i5-BK; Thu, 09 Feb 2012 12:08:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RvSnD-0007hs-GU
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:08:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328789276!14094763!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30278 invoked from network); 9 Feb 2012 12:07:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:07:57 -0000
Received: by iaeh11 with SMTP id h11so7781363iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:07:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=s7wgk7lqurPPgoamWwghjk0PhNkOJtzgtZo0vdRkKu4=;
	b=WX3EPqiSA4pWDfZCQQGSHsoxIwUC1HBynE6lUbZoLHki67xCHeVPzsNqKmzNbn6QdR
	flCW2m+z9MRy1hnY1RZ7+tJQX7L1Wu5iHZEMIbMeTLodc9DGgLh4ATwg+TOW6Ba4v0Et
	Vqtmj5oyohgY9kztLfMPq1+CuPGh+wzJyXVhA=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr29836337igb.10.1328789275865;
	Thu, 09 Feb 2012 04:07:55 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Thu, 9 Feb 2012 04:07:55 -0800 (PST)
In-Reply-To: <5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
Date: Thu, 9 Feb 2012 12:07:55 +0000
X-Google-Sender-Auth: 49gMvbbY_C98ZP9zCUXYGsnIhCM
Message-ID: <CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 5:45 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
> =A0 =A0 =A0 =A0 unmap_domain_page(b);
> =A0 =A0 }
>
> + =A0 =A0/* First, take all pages off the domain list */
> =A0 =A0 lock_page_alloc(p2m);
> -
> - =A0 =A0/* First, take all pages off the domain list */
> =A0 =A0 for(i=3D0; i < 1 << order ; i++)
> =A0 =A0 {
> =A0 =A0 =A0 =A0 p =3D page + i;
> =A0 =A0 =A0 =A0 page_list_del(p, &d->page_list);
> =A0 =A0 }
>
> + =A0 =A0/* Ensure that the PoD cache has never been emptied.
> + =A0 =A0 * This may cause "zombie domains" since the page will never be =
freed. */
> + =A0 =A0BUG_ON( d->arch.relmem !=3D RELMEM_not_started );
> +
> + =A0 =A0unlock_page_alloc(p2m);
> +

I thought we were going to get rid of this BUG_ON? :-)

Other than that, assuming that you've tested it and it works:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:08:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvSnF-0007i5-BK; Thu, 09 Feb 2012 12:08:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RvSnD-0007hs-GU
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:08:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328789276!14094763!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30278 invoked from network); 9 Feb 2012 12:07:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:07:57 -0000
Received: by iaeh11 with SMTP id h11so7781363iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:07:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=s7wgk7lqurPPgoamWwghjk0PhNkOJtzgtZo0vdRkKu4=;
	b=WX3EPqiSA4pWDfZCQQGSHsoxIwUC1HBynE6lUbZoLHki67xCHeVPzsNqKmzNbn6QdR
	flCW2m+z9MRy1hnY1RZ7+tJQX7L1Wu5iHZEMIbMeTLodc9DGgLh4ATwg+TOW6Ba4v0Et
	Vqtmj5oyohgY9kztLfMPq1+CuPGh+wzJyXVhA=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr29836337igb.10.1328789275865;
	Thu, 09 Feb 2012 04:07:55 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Thu, 9 Feb 2012 04:07:55 -0800 (PST)
In-Reply-To: <5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
Date: Thu, 9 Feb 2012 12:07:55 +0000
X-Google-Sender-Auth: 49gMvbbY_C98ZP9zCUXYGsnIhCM
Message-ID: <CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 5:45 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
> =A0 =A0 =A0 =A0 unmap_domain_page(b);
> =A0 =A0 }
>
> + =A0 =A0/* First, take all pages off the domain list */
> =A0 =A0 lock_page_alloc(p2m);
> -
> - =A0 =A0/* First, take all pages off the domain list */
> =A0 =A0 for(i=3D0; i < 1 << order ; i++)
> =A0 =A0 {
> =A0 =A0 =A0 =A0 p =3D page + i;
> =A0 =A0 =A0 =A0 page_list_del(p, &d->page_list);
> =A0 =A0 }
>
> + =A0 =A0/* Ensure that the PoD cache has never been emptied.
> + =A0 =A0 * This may cause "zombie domains" since the page will never be =
freed. */
> + =A0 =A0BUG_ON( d->arch.relmem !=3D RELMEM_not_started );
> +
> + =A0 =A0unlock_page_alloc(p2m);
> +

I thought we were going to get rid of this BUG_ON? :-)

Other than that, assuming that you've tested it and it works:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:25:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvT3e-00087p-0a; Thu, 09 Feb 2012 12:25:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvT3c-00087e-95
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:25:00 +0000
Received: from [85.158.139.83:32939] by server-5.bemta-5.messagelabs.com id
	AA/D3-03847-B1BB33F4; Thu, 09 Feb 2012 12:24:59 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328790298!13773462!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7980 invoked from network); 9 Feb 2012 12:24:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 12:24:58 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19COvTV010301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:24:57 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19COta3021065; Thu, 9 Feb 2012 07:24:56 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 7F8ED133EEF; Thu,  9 Feb 2012 14:24:55 +0200 (IST)
Date: Thu, 9 Feb 2012 14:24:55 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209122455.GI18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-7-git-send-email-kraxel@redhat.com>
	<20120209085658.GE18866@redhat.com> <4F33B56F.5020000@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33B56F.5020000@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm
 wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:00:47PM +0100, Gerd Hoffmann wrote:
> On 02/09/12 09:56, Gleb Natapov wrote:
> > On Wed, Feb 08, 2012 at 12:00:19PM +0100, Gerd Hoffmann wrote:
> >> Add a 'wakeup' property to the mc146818rtc.  It is on by default.
> >> When enabled the rtc will wake up the guest when the alarm fires.
> >>
> >> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> >> ---
> >>  hw/mc146818rtc.c |    5 +++++
> >>  1 files changed, 5 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> >> index 314ed52..3b912c6 100644
> >> --- a/hw/mc146818rtc.c
> >> +++ b/hw/mc146818rtc.c
> >> @@ -86,6 +86,7 @@ typedef struct RTCState {
> >>      uint8_t cmos_index;
> >>      struct tm current_tm;
> >>      int32_t base_year;
> >> +    uint32_t wakeup;
> >>      qemu_irq irq;
> >>      qemu_irq sqw_irq;
> >>      int it_shift;
> >> @@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
> >>  
> >>          s->cmos_data[RTC_REG_C] |= REG_C_AF;
> >>          if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
> >> +            if (s->wakeup) {
> >> +                qemu_system_wakeup_request();
> >> +            }
> > RTC should do wakeup only if RTC_EN bit is set pm1en.
> 
> --verbose please.  Which register, which bit?  There is no RTC_EN in
> hw/mc146818rtc.* ...
> 

Entering --verbose mode.

Here we are on ACPI territory, not RTC :) RTC just provides one input
into ACPI wakeup machinery (Figure 4-11 in ACPI spec version 4). I am
talking about ACPI_BITMASK_RT_CLOCK_ENABLE from hw/acpi.h. It is called
RTC_EN in ACPI spec (man, we should rename them back!). Spec says that
RTC alarm can wakeup the system only if RTC_EN is set in PM1x_EN
register. This way OSPM can control which events can do wakeup.
Notice that for power button wakeup BWRBTN_EN is ignored.

> Is this enable bit specifically for wakeup from suspend?
> 
No, RTC alarm can be configured to generate SCI interrupt while system
is running.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:25:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvT3e-00087p-0a; Thu, 09 Feb 2012 12:25:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvT3c-00087e-95
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:25:00 +0000
Received: from [85.158.139.83:32939] by server-5.bemta-5.messagelabs.com id
	AA/D3-03847-B1BB33F4; Thu, 09 Feb 2012 12:24:59 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328790298!13773462!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7980 invoked from network); 9 Feb 2012 12:24:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 12:24:58 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19COvTV010301
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:24:57 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19COta3021065; Thu, 9 Feb 2012 07:24:56 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 7F8ED133EEF; Thu,  9 Feb 2012 14:24:55 +0200 (IST)
Date: Thu, 9 Feb 2012 14:24:55 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209122455.GI18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-7-git-send-email-kraxel@redhat.com>
	<20120209085658.GE18866@redhat.com> <4F33B56F.5020000@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33B56F.5020000@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm
 wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:00:47PM +0100, Gerd Hoffmann wrote:
> On 02/09/12 09:56, Gleb Natapov wrote:
> > On Wed, Feb 08, 2012 at 12:00:19PM +0100, Gerd Hoffmann wrote:
> >> Add a 'wakeup' property to the mc146818rtc.  It is on by default.
> >> When enabled the rtc will wake up the guest when the alarm fires.
> >>
> >> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> >> ---
> >>  hw/mc146818rtc.c |    5 +++++
> >>  1 files changed, 5 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> >> index 314ed52..3b912c6 100644
> >> --- a/hw/mc146818rtc.c
> >> +++ b/hw/mc146818rtc.c
> >> @@ -86,6 +86,7 @@ typedef struct RTCState {
> >>      uint8_t cmos_index;
> >>      struct tm current_tm;
> >>      int32_t base_year;
> >> +    uint32_t wakeup;
> >>      qemu_irq irq;
> >>      qemu_irq sqw_irq;
> >>      int it_shift;
> >> @@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
> >>  
> >>          s->cmos_data[RTC_REG_C] |= REG_C_AF;
> >>          if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
> >> +            if (s->wakeup) {
> >> +                qemu_system_wakeup_request();
> >> +            }
> > RTC should do wakeup only if RTC_EN bit is set pm1en.
> 
> --verbose please.  Which register, which bit?  There is no RTC_EN in
> hw/mc146818rtc.* ...
> 

Entering --verbose mode.

Here we are on ACPI territory, not RTC :) RTC just provides one input
into ACPI wakeup machinery (Figure 4-11 in ACPI spec version 4). I am
talking about ACPI_BITMASK_RT_CLOCK_ENABLE from hw/acpi.h. It is called
RTC_EN in ACPI spec (man, we should rename them back!). Spec says that
RTC alarm can wakeup the system only if RTC_EN is set in PM1x_EN
register. This way OSPM can control which events can do wakeup.
Notice that for power button wakeup BWRBTN_EN is ignored.

> Is this enable bit specifically for wakeup from suspend?
> 
No, RTC alarm can be configured to generate SCI interrupt while system
is running.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:31:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvT9o-0008Hj-2e; Thu, 09 Feb 2012 12:31:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RvT9m-0008HW-7r
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:31:22 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328790674!13605821!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22127 invoked from network); 9 Feb 2012 12:31:15 -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;
	9 Feb 2012 12:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181042046"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 07:31:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 07:31:13 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q19CVCZK004666;
	Thu, 9 Feb 2012 04:31:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0aa2ccb5622461801936a7f1f86c4c8761fcf316
Message-ID: <0aa2ccb5622461801936.1328790671@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 9 Feb 2012 12:31:11 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] RFC: Automatically adjust dom0 weight
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At the moment, the scheduler treats dom0 the same as any other VM
for the purposes of accounting.  Since dom0 is really a critical
piece of infrastructure, and a part of the hypervisor system as a
whole, it would make more sense to try to give dom0 special rights
wrt CPU time.

This patch will cause the hypervisor to automatically adjust the
weight of dom0 such that it should be able to get either enough
cpu for each of its vcpus, or half of the cpus on the system,
whichever is less.

This patch has been in XenServer for several releases now.

I'm mostly posting to see what the interest in this kind of approach
is.  If there is interest, I'll do the work to make it more configurable.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a91aa7a582fb -r 0aa2ccb56224 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Jan 31 16:34:39 2012 +0000
+++ b/xen/common/sched_credit.c	Thu Feb 09 12:31:00 2012 +0000
@@ -175,6 +175,7 @@ struct csched_private {
     /* Period of master and tick in milliseconds */
     unsigned tslice_ms, tick_period_us, ticks_per_tslice;
     unsigned credits_per_tslice;
+    struct csched_dom * privdom;
 };
 
 static void csched_tick(void *_cpu);
@@ -551,6 +552,61 @@ csched_cpu_pick(const struct scheduler *
     return _csched_cpu_pick(ops, vc, 1);
 }
 
+/* Make sure that the privileged domain always has enough weight for its active
+ * vcpus to get one full pcpu each */
+static inline void __csched_adj_privdom_weight(struct csched_private *prv) {
+    struct csched_dom *sdom = prv->privdom;
+    int other_cpus, new_weight;
+#ifndef NDEBUG
+    int initial_weight;
+#endif
+
+    /* If privdom isn't being accounted for, or is the only active
+     * domain, we're done. */
+    if ( sdom == NULL
+         || list_empty(&sdom->active_sdom_elem)
+         || unlikely(prv->ncpus < 2) 
+         || prv->weight == sdom->weight * sdom->active_vcpu_count ) 
+        return;
+
+    BUG_ON(prv->weight < sdom->weight * sdom->active_vcpu_count);
+
+#ifndef NDEBUG
+    initial_weight = sdom->weight;
+#endif
+
+    /* First, subtract current privdom weight from system weight */
+    prv->weight -= sdom->weight * sdom->active_vcpu_count;
+
+    /* Calculate how many cores to leave to others. */
+    other_cpus = prv->ncpus - sdom->active_vcpu_count;
+
+    /* Don't let privdomain have more than half the available cores */
+    if ( sdom->active_vcpu_count > other_cpus )
+    {
+        /* Privdomain total weight will be equal to the weight of all others,
+         * giving it 50% of available processing power. */
+        new_weight = prv->weight / sdom->active_vcpu_count;
+    }
+    else
+    {
+        /* Calculate new privdomain weight: "other" weight / "other" pcpus */
+        new_weight = prv->weight / other_cpus;
+    }
+
+    if ( new_weight > 0 )
+        sdom->weight = new_weight;
+
+    /* Update system weight to reflect new dom0 weight */
+    prv->weight += sdom->weight * sdom->active_vcpu_count;
+
+#ifndef NDEBUG
+   if(0 && initial_weight != sdom->weight)
+        printk("%s: d%d weight %d -> %d\n",
+               __func__, sdom->dom->domain_id, initial_weight, sdom->weight);
+#endif
+}
+
 static inline void
 __csched_vcpu_acct_start(struct csched_private *prv, struct csched_vcpu *svc)
 {
@@ -572,6 +628,16 @@ __csched_vcpu_acct_start(struct csched_p
         {
             list_add(&sdom->active_sdom_elem, &prv->active_sdom);
         }
+
+        /* is_privileged isn't set when dom0 is created, so check it here. */
+        if ( unlikely(prv->privdom == NULL)
+             && IS_PRIV(sdom->dom) ) {
+            printk("%s: setting dom %d as the privileged domain\n",
+                   __func__, sdom->dom->domain_id);
+            prv->privdom = sdom;
+        }
+
+        __csched_adj_privdom_weight(prv);
     }
 
     spin_unlock_irqrestore(&prv->lock, flags);
@@ -591,11 +657,15 @@ __csched_vcpu_acct_stop_locked(struct cs
     BUG_ON( prv->weight < sdom->weight );
     sdom->active_vcpu_count--;
     list_del_init(&svc->active_vcpu_elem);
+
     prv->weight -= sdom->weight;
+
     if ( list_empty(&sdom->active_vcpu) )
     {
         list_del_init(&sdom->active_sdom_elem);
     }
+
+    __csched_adj_privdom_weight(prv);
 }
 
 static void
@@ -821,6 +891,8 @@ csched_dom_cntl(
                 prv->weight += op->u.credit.weight * sdom->active_vcpu_count;
             }
             sdom->weight = op->u.credit.weight;
+
+            __csched_adj_privdom_weight(prv);
         }
 
         if ( op->u.credit.cap != (uint16_t)~0U )
@@ -856,6 +928,7 @@ csched_alloc_domdata(const struct schedu
 static int
 csched_dom_init(const struct scheduler *ops, struct domain *dom)
 {
+    struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_dom *sdom;
 
     CSCHED_STAT_CRANK(dom_init);
@@ -869,6 +942,12 @@ csched_dom_init(const struct scheduler *
 
     dom->sched_priv = sdom;
 
+    if( IS_PRIV(dom) ) {
+        printk("%s: setting dom %d as the privileged domain\n",
+               __func__, dom->domain_id);
+        prv->privdom = sdom;
+    }
+
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:31:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvT9o-0008Hj-2e; Thu, 09 Feb 2012 12:31:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RvT9m-0008HW-7r
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:31:22 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328790674!13605821!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22127 invoked from network); 9 Feb 2012 12:31:15 -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;
	9 Feb 2012 12:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181042046"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 07:31:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 07:31:13 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q19CVCZK004666;
	Thu, 9 Feb 2012 04:31:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0aa2ccb5622461801936a7f1f86c4c8761fcf316
Message-ID: <0aa2ccb5622461801936.1328790671@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 9 Feb 2012 12:31:11 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] RFC: Automatically adjust dom0 weight
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At the moment, the scheduler treats dom0 the same as any other VM
for the purposes of accounting.  Since dom0 is really a critical
piece of infrastructure, and a part of the hypervisor system as a
whole, it would make more sense to try to give dom0 special rights
wrt CPU time.

This patch will cause the hypervisor to automatically adjust the
weight of dom0 such that it should be able to get either enough
cpu for each of its vcpus, or half of the cpus on the system,
whichever is less.

This patch has been in XenServer for several releases now.

I'm mostly posting to see what the interest in this kind of approach
is.  If there is interest, I'll do the work to make it more configurable.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a91aa7a582fb -r 0aa2ccb56224 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Jan 31 16:34:39 2012 +0000
+++ b/xen/common/sched_credit.c	Thu Feb 09 12:31:00 2012 +0000
@@ -175,6 +175,7 @@ struct csched_private {
     /* Period of master and tick in milliseconds */
     unsigned tslice_ms, tick_period_us, ticks_per_tslice;
     unsigned credits_per_tslice;
+    struct csched_dom * privdom;
 };
 
 static void csched_tick(void *_cpu);
@@ -551,6 +552,61 @@ csched_cpu_pick(const struct scheduler *
     return _csched_cpu_pick(ops, vc, 1);
 }
 
+/* Make sure that the privileged domain always has enough weight for its active
+ * vcpus to get one full pcpu each */
+static inline void __csched_adj_privdom_weight(struct csched_private *prv) {
+    struct csched_dom *sdom = prv->privdom;
+    int other_cpus, new_weight;
+#ifndef NDEBUG
+    int initial_weight;
+#endif
+
+    /* If privdom isn't being accounted for, or is the only active
+     * domain, we're done. */
+    if ( sdom == NULL
+         || list_empty(&sdom->active_sdom_elem)
+         || unlikely(prv->ncpus < 2) 
+         || prv->weight == sdom->weight * sdom->active_vcpu_count ) 
+        return;
+
+    BUG_ON(prv->weight < sdom->weight * sdom->active_vcpu_count);
+
+#ifndef NDEBUG
+    initial_weight = sdom->weight;
+#endif
+
+    /* First, subtract current privdom weight from system weight */
+    prv->weight -= sdom->weight * sdom->active_vcpu_count;
+
+    /* Calculate how many cores to leave to others. */
+    other_cpus = prv->ncpus - sdom->active_vcpu_count;
+
+    /* Don't let privdomain have more than half the available cores */
+    if ( sdom->active_vcpu_count > other_cpus )
+    {
+        /* Privdomain total weight will be equal to the weight of all others,
+         * giving it 50% of available processing power. */
+        new_weight = prv->weight / sdom->active_vcpu_count;
+    }
+    else
+    {
+        /* Calculate new privdomain weight: "other" weight / "other" pcpus */
+        new_weight = prv->weight / other_cpus;
+    }
+
+    if ( new_weight > 0 )
+        sdom->weight = new_weight;
+
+    /* Update system weight to reflect new dom0 weight */
+    prv->weight += sdom->weight * sdom->active_vcpu_count;
+
+#ifndef NDEBUG
+   if(0 && initial_weight != sdom->weight)
+        printk("%s: d%d weight %d -> %d\n",
+               __func__, sdom->dom->domain_id, initial_weight, sdom->weight);
+#endif
+}
+
 static inline void
 __csched_vcpu_acct_start(struct csched_private *prv, struct csched_vcpu *svc)
 {
@@ -572,6 +628,16 @@ __csched_vcpu_acct_start(struct csched_p
         {
             list_add(&sdom->active_sdom_elem, &prv->active_sdom);
         }
+
+        /* is_privileged isn't set when dom0 is created, so check it here. */
+        if ( unlikely(prv->privdom == NULL)
+             && IS_PRIV(sdom->dom) ) {
+            printk("%s: setting dom %d as the privileged domain\n",
+                   __func__, sdom->dom->domain_id);
+            prv->privdom = sdom;
+        }
+
+        __csched_adj_privdom_weight(prv);
     }
 
     spin_unlock_irqrestore(&prv->lock, flags);
@@ -591,11 +657,15 @@ __csched_vcpu_acct_stop_locked(struct cs
     BUG_ON( prv->weight < sdom->weight );
     sdom->active_vcpu_count--;
     list_del_init(&svc->active_vcpu_elem);
+
     prv->weight -= sdom->weight;
+
     if ( list_empty(&sdom->active_vcpu) )
     {
         list_del_init(&sdom->active_sdom_elem);
     }
+
+    __csched_adj_privdom_weight(prv);
 }
 
 static void
@@ -821,6 +891,8 @@ csched_dom_cntl(
                 prv->weight += op->u.credit.weight * sdom->active_vcpu_count;
             }
             sdom->weight = op->u.credit.weight;
+
+            __csched_adj_privdom_weight(prv);
         }
 
         if ( op->u.credit.cap != (uint16_t)~0U )
@@ -856,6 +928,7 @@ csched_alloc_domdata(const struct schedu
 static int
 csched_dom_init(const struct scheduler *ops, struct domain *dom)
 {
+    struct csched_private *prv = CSCHED_PRIV(ops);
     struct csched_dom *sdom;
 
     CSCHED_STAT_CRANK(dom_init);
@@ -869,6 +942,12 @@ csched_dom_init(const struct scheduler *
 
     dom->sched_priv = sdom;
 
+    if( IS_PRIV(dom) ) {
+        printk("%s: setting dom %d as the privileged domain\n",
+               __func__, dom->domain_id);
+        prv->privdom = sdom;
+    }
+
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:32:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTAW-0008KY-Gs; Thu, 09 Feb 2012 12:32:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTAV-0008KD-6W
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:32:07 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328790720!9935798!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1085 invoked from network); 9 Feb 2012 12:32:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 12:32:00 -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 q19CVxAW029210
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:31:59 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19CVvD2018671; Thu, 9 Feb 2012 07:31:58 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 9211C133EEF; Thu,  9 Feb 2012 14:31:57 +0200 (IST)
Date: Thu, 9 Feb 2012 14:31:57 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20120209123157.GJ18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<4F33AB4D.9070904@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33AB4D.9070904@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 12:17:33PM +0100, Paolo Bonzini wrote:
> On 02/08/2012 12:00 PM, Gerd Hoffmann wrote:
> >+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> >+   BIOS will read it and start S3 resume at POST Entry */
> >+static void rtc_notify_suspend(Notifier *notifier, void *data)
> >+{
> >+    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
> >+    rtc_set_memory(&s->dev, 0xF, 0xFE);
> >+}
> >+
> 
> Out of curiosity, who would set this on real hardware?  And since
Real HW may have other ways to notify BIOS that system was S3 suspended
(special chipset register for instance). I think we can write DSDT magic
to write RTC for us, but I prefer to do it from inside QEMU.

> RTC memory is nvram, what happens if I remove the mains plug while
> the system is in S3?
> 
RTC is battery backed, but what do you expect will happen to main memory
where all your data resides during S3 in this case anyway?

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:32:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTAW-0008KY-Gs; Thu, 09 Feb 2012 12:32:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTAV-0008KD-6W
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:32:07 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328790720!9935798!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1085 invoked from network); 9 Feb 2012 12:32:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 12:32:00 -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 q19CVxAW029210
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:31:59 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19CVvD2018671; Thu, 9 Feb 2012 07:31:58 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 9211C133EEF; Thu,  9 Feb 2012 14:31:57 +0200 (IST)
Date: Thu, 9 Feb 2012 14:31:57 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20120209123157.GJ18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<4F33AB4D.9070904@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33AB4D.9070904@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 12:17:33PM +0100, Paolo Bonzini wrote:
> On 02/08/2012 12:00 PM, Gerd Hoffmann wrote:
> >+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
> >+   BIOS will read it and start S3 resume at POST Entry */
> >+static void rtc_notify_suspend(Notifier *notifier, void *data)
> >+{
> >+    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
> >+    rtc_set_memory(&s->dev, 0xF, 0xFE);
> >+}
> >+
> 
> Out of curiosity, who would set this on real hardware?  And since
Real HW may have other ways to notify BIOS that system was S3 suspended
(special chipset register for instance). I think we can write DSDT magic
to write RTC for us, but I prefer to do it from inside QEMU.

> RTC memory is nvram, what happens if I remove the mains plug while
> the system is in S3?
> 
RTC is battery backed, but what do you expect will happen to main memory
where all your data resides during S3 in this case anyway?

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:32:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTAh-0008Lp-Ts; Thu, 09 Feb 2012 12:32: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 1RvTAh-0008Li-3Z
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:32:19 +0000
Received: from [85.158.139.83:11607] by server-2.bemta-5.messagelabs.com id
	F0/D9-20725-2DCB33F4; Thu, 09 Feb 2012 12:32:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328790735!14376323!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5562 invoked from network); 9 Feb 2012 12:32:17 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:32:17 -0000
Received: by damc16 with SMTP id c16so11067054dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:32:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=AQ9ahSUXUBnt10oJnXxc53M0eHd2hd2sqgLyRJd2YZc=;
	b=eC1cOSCRxpOzOMhLwYwHlnGFwdfWShVNiSM7Ls23aTGHRaglojd8TKkeRrhhatGEAd
	f/MPWyDXkoqlcaMKqD3VeXkXAxjjCSYXZG36smqttVRydUmxGrPNNH1FWLXH2C6mX+3y
	1UU/UaMno8gUOlh/GEjzKZY/1UCYJ21qnLn1M=
Received: by 10.68.208.196 with SMTP id mg4mr5374543pbc.108.1328790735508;
	Thu, 09 Feb 2012 04:32:15 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id h6sm5870042pbg.5.2012.02.09.04.32.12
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:32:13 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:32:08 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB58FCC8.2AC02%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AcznJtZ6pcHe2XlpdUSb2FGvuGRPPg==
In-Reply-To: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 22:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> The versioning required allows a driver to declare, "I am compatible
> with any source compatibility breaking changes up to version X of
> the header file".  Declaring support for the latest version does
> not require that a driver implement the new extensions.  Just one
> constant needs to be renamed.  So I don't see this as really altering
> the interface between front and backends (i.e. it is not a "blkif2")
> 
> If the xen-compat.h behavior is that you can safely import the
> public headers so long as you do not bump __XEN_INTERFACE_VERSION__
> until after you have audited and adjusted for the #ifdef guarded
> changes in the header files, then that is exactly what is needed
> in blkif.h.

That's what XEN_INTERFACE_VERSION is for, yes.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:32:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTAh-0008Lp-Ts; Thu, 09 Feb 2012 12:32: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 1RvTAh-0008Li-3Z
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:32:19 +0000
Received: from [85.158.139.83:11607] by server-2.bemta-5.messagelabs.com id
	F0/D9-20725-2DCB33F4; Thu, 09 Feb 2012 12:32:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328790735!14376323!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5562 invoked from network); 9 Feb 2012 12:32:17 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:32:17 -0000
Received: by damc16 with SMTP id c16so11067054dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:32:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=AQ9ahSUXUBnt10oJnXxc53M0eHd2hd2sqgLyRJd2YZc=;
	b=eC1cOSCRxpOzOMhLwYwHlnGFwdfWShVNiSM7Ls23aTGHRaglojd8TKkeRrhhatGEAd
	f/MPWyDXkoqlcaMKqD3VeXkXAxjjCSYXZG36smqttVRydUmxGrPNNH1FWLXH2C6mX+3y
	1UU/UaMno8gUOlh/GEjzKZY/1UCYJ21qnLn1M=
Received: by 10.68.208.196 with SMTP id mg4mr5374543pbc.108.1328790735508;
	Thu, 09 Feb 2012 04:32:15 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id h6sm5870042pbg.5.2012.02.09.04.32.12
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:32:13 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:32:08 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB58FCC8.2AC02%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AcznJtZ6pcHe2XlpdUSb2FGvuGRPPg==
In-Reply-To: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 22:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> The versioning required allows a driver to declare, "I am compatible
> with any source compatibility breaking changes up to version X of
> the header file".  Declaring support for the latest version does
> not require that a driver implement the new extensions.  Just one
> constant needs to be renamed.  So I don't see this as really altering
> the interface between front and backends (i.e. it is not a "blkif2")
> 
> If the xen-compat.h behavior is that you can safely import the
> public headers so long as you do not bump __XEN_INTERFACE_VERSION__
> until after you have audited and adjusted for the #ifdef guarded
> changes in the header files, then that is exactly what is needed
> in blkif.h.

That's what XEN_INTERFACE_VERSION is for, yes.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:34:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTCH-00009v-MB; Thu, 09 Feb 2012 12:33:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RvTCF-00009I-PK
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:33:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328790828!9936158!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8643 invoked from network); 9 Feb 2012 12:33:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:33:49 -0000
Received: by iaeh11 with SMTP id h11so7935168iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=O1JCEhBoGYNa2p39xU57MKggzDo8Kn+2wWsRT+g/MLQ=;
	b=XPjppfaqb2pEKk4Kx1io2c2/xS1HcEu6KV8fvjAlLU5ogrKK8vcDR52BplbqS86GCD
	e4aYiTZDrpyhLFbF9sk0pSKD8VUcm3Y+EWYfVWg2qQ7M6CNqcZ6dz4SSgrS4zJIzN5e3
	6qLRxTDrPi7Qk0VpAT3C1z5wEoSIXARFguqaI=
Received: by 10.50.161.231 with SMTP id xv7mr30127465igb.0.1328790827798;
	Thu, 09 Feb 2012 04:33:47 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id f8sm5100408ibl.6.2012.02.09.04.33.44
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:33:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:33:38 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB58FD22.2AC03%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, RFC] Re:  x86: gnttab_clear_flag() abusing
	clear_bit()
Thread-Index: AcznJwweyqiws14Ubkq93PXN4iPIIA==
In-Reply-To: <4F3399820200007800071D17@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/2012 01:01, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Looks fine to me, in principle. I would add a comment to the x86
>> gnttab_clear_flag() explaining why we have to open code something that looks
>> a lot like clear_bit().
> 
> That one I already did, will submit soon (desiring clarification on the
> below).
> 
> As to the "+m" constraint - I'm being told that "+m" (var) is equivalent
> to "=m" (var) : "m" (var), no matter what the documentation says
> regarding '+' (but they're also not seeing a need to adjust the docs
> accordingly).
> 
> The question is whether we should go with the (documentation-wise
> correct) form, or the shorter one (which they're unlikely to change
> the meaning of, given in how many places "+m" is used in e.g. Linux).

You could switch us to "+m" and see how we get on.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:34:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTCH-00009v-MB; Thu, 09 Feb 2012 12:33:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RvTCF-00009I-PK
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:33:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328790828!9936158!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8643 invoked from network); 9 Feb 2012 12:33:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:33:49 -0000
Received: by iaeh11 with SMTP id h11so7935168iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=O1JCEhBoGYNa2p39xU57MKggzDo8Kn+2wWsRT+g/MLQ=;
	b=XPjppfaqb2pEKk4Kx1io2c2/xS1HcEu6KV8fvjAlLU5ogrKK8vcDR52BplbqS86GCD
	e4aYiTZDrpyhLFbF9sk0pSKD8VUcm3Y+EWYfVWg2qQ7M6CNqcZ6dz4SSgrS4zJIzN5e3
	6qLRxTDrPi7Qk0VpAT3C1z5wEoSIXARFguqaI=
Received: by 10.50.161.231 with SMTP id xv7mr30127465igb.0.1328790827798;
	Thu, 09 Feb 2012 04:33:47 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id f8sm5100408ibl.6.2012.02.09.04.33.44
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:33:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:33:38 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB58FD22.2AC03%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, RFC] Re:  x86: gnttab_clear_flag() abusing
	clear_bit()
Thread-Index: AcznJwweyqiws14Ubkq93PXN4iPIIA==
In-Reply-To: <4F3399820200007800071D17@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH,
 RFC] Re:  x86: gnttab_clear_flag() abusing clear_bit()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/2012 01:01, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Looks fine to me, in principle. I would add a comment to the x86
>> gnttab_clear_flag() explaining why we have to open code something that looks
>> a lot like clear_bit().
> 
> That one I already did, will submit soon (desiring clarification on the
> below).
> 
> As to the "+m" constraint - I'm being told that "+m" (var) is equivalent
> to "=m" (var) : "m" (var), no matter what the documentation says
> regarding '+' (but they're also not seeing a need to adjust the docs
> accordingly).
> 
> The question is whether we should go with the (documentation-wise
> correct) form, or the shorter one (which they're unlikely to change
> the meaning of, given in how many places "+m" is used in e.g. Linux).

You could switch us to "+m" and see how we get on.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTFj-0000Pf-Nh; Thu, 09 Feb 2012 12:37:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTFi-0000PJ-Ry
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:37:31 +0000
Received: from [85.158.143.35:11092] by server-2.bemta-4.messagelabs.com id
	73/ED-02822-90EB33F4; Thu, 09 Feb 2012 12:37:29 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328791047!2131087!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21683 invoked from network); 9 Feb 2012 12:37:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 12:37:28 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19CbQFn014229
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:37:26 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19CbPqa025174; Thu, 9 Feb 2012 07:37:26 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 16190133EEF; Thu,  9 Feb 2012 14:37:25 +0200 (IST)
Date: Thu, 9 Feb 2012 14:37:25 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209123725.GK18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33B5E7.7070502@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:02:47PM +0100, Gerd Hoffmann wrote:
> On 02/09/12 12:19, Gleb Natapov wrote:
> > On Thu, Feb 09, 2012 at 11:45:21AM +0100, Gerd Hoffmann wrote:
> >> On 02/09/12 09:48, Gleb Natapov wrote:
> >>> On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
> >>>>  * qemu_system_wakeup_request is supposed to be called on events which
> >>>>    should wake up the guest.
> >>>>
> >>> qemu_system_wakeup_request() should get wakeup source as a parameter.
> >>> There are ways to report it to a guest.
> >>
> >> Can we do that incrementally, when we actually implement the guest
> >> reporting?
> >>
> > What do you mean by "when we actually implement the guest
> > reporting"? The guest reporting is part of ACPI spec and implemented
> > by all relevant guests. I think that adding wakeup source parameter to
> > qemu_system_wakeup_request() and reporting RTC_STS and PWRBTN_STS should
> > not complicate your patch series to much. I agree that DSDT magic required
> > by other devices can wait for later.
> 
> Incremental patch (just infrastructure, no acpi windup yet) attached.
> Something like this?
> 
We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
prevent it.

> cheers,
>   Gerd

> commit 78fbd17ddc98a2e96e05db62afbe3a69c5fad5e5
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Thu Feb 9 12:52:48 2012 +0100
> 
>     reason: infra
> 
> diff --git a/sysemu.h b/sysemu.h
> index 3b9d7f5..e7060aa 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -38,10 +38,16 @@ void vm_start(void);
>  void vm_stop(RunState state);
>  void vm_stop_force_state(RunState state);
>  
> +typedef enum WakeupReason {
> +    QEMU_WAKEUP_REASON_OTHER = 0,
> +    QEMU_WAKEUP_REASON_RTC,
> +} WakeupReason;
> +
>  void qemu_system_reset_request(void);
>  void qemu_system_suspend_request(void);
>  void qemu_register_suspend_notifier(Notifier *notifier);
> -void qemu_system_wakeup_request(void);
> +void qemu_system_wakeup_request(WakeupReason reason);
> +void qemu_register_wakeup_notifier(Notifier *notifier);
>  void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
>  void qemu_system_debug_request(void);
> diff --git a/vl.c b/vl.c
> index 822fd58..17d4b72 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1286,6 +1286,8 @@ static int debug_requested;
>  static bool is_suspended;
>  static NotifierList suspend_notifiers =
>      NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
> +static NotifierList wakeup_notifiers =
> +    NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  
>  int qemu_shutdown_requested_get(void)
> @@ -1416,16 +1418,22 @@ void qemu_register_suspend_notifier(Notifier *notifier)
>      notifier_list_add(&suspend_notifiers, notifier);
>  }
>  
> -void qemu_system_wakeup_request(void)
> +void qemu_system_wakeup_request(WakeupReason reason)
>  {
>      if (!is_suspended) {
>          return;
>      }
> +    notifier_list_notify(&wakeup_notifiers, &reason);
>      reset_requested = 1;
>      qemu_notify_event();
>      is_suspended = false;
>  }
>  
> +void qemu_register_wakeup_notifier(Notifier *notifier)
> +{
> +    notifier_list_add(&wakeup_notifiers, notifier);
> +}
> +
>  void qemu_system_killed(int signal, pid_t pid)
>  {
>      shutdown_signal = signal;


--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTFj-0000Pf-Nh; Thu, 09 Feb 2012 12:37:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTFi-0000PJ-Ry
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:37:31 +0000
Received: from [85.158.143.35:11092] by server-2.bemta-4.messagelabs.com id
	73/ED-02822-90EB33F4; Thu, 09 Feb 2012 12:37:29 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328791047!2131087!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21683 invoked from network); 9 Feb 2012 12:37:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 12:37:28 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19CbQFn014229
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:37:26 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19CbPqa025174; Thu, 9 Feb 2012 07:37:26 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 16190133EEF; Thu,  9 Feb 2012 14:37:25 +0200 (IST)
Date: Thu, 9 Feb 2012 14:37:25 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209123725.GK18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33B5E7.7070502@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:02:47PM +0100, Gerd Hoffmann wrote:
> On 02/09/12 12:19, Gleb Natapov wrote:
> > On Thu, Feb 09, 2012 at 11:45:21AM +0100, Gerd Hoffmann wrote:
> >> On 02/09/12 09:48, Gleb Natapov wrote:
> >>> On Wed, Feb 08, 2012 at 12:00:14PM +0100, Gerd Hoffmann wrote:
> >>>>  * qemu_system_wakeup_request is supposed to be called on events which
> >>>>    should wake up the guest.
> >>>>
> >>> qemu_system_wakeup_request() should get wakeup source as a parameter.
> >>> There are ways to report it to a guest.
> >>
> >> Can we do that incrementally, when we actually implement the guest
> >> reporting?
> >>
> > What do you mean by "when we actually implement the guest
> > reporting"? The guest reporting is part of ACPI spec and implemented
> > by all relevant guests. I think that adding wakeup source parameter to
> > qemu_system_wakeup_request() and reporting RTC_STS and PWRBTN_STS should
> > not complicate your patch series to much. I agree that DSDT magic required
> > by other devices can wait for later.
> 
> Incremental patch (just infrastructure, no acpi windup yet) attached.
> Something like this?
> 
We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
prevent it.

> cheers,
>   Gerd

> commit 78fbd17ddc98a2e96e05db62afbe3a69c5fad5e5
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Thu Feb 9 12:52:48 2012 +0100
> 
>     reason: infra
> 
> diff --git a/sysemu.h b/sysemu.h
> index 3b9d7f5..e7060aa 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -38,10 +38,16 @@ void vm_start(void);
>  void vm_stop(RunState state);
>  void vm_stop_force_state(RunState state);
>  
> +typedef enum WakeupReason {
> +    QEMU_WAKEUP_REASON_OTHER = 0,
> +    QEMU_WAKEUP_REASON_RTC,
> +} WakeupReason;
> +
>  void qemu_system_reset_request(void);
>  void qemu_system_suspend_request(void);
>  void qemu_register_suspend_notifier(Notifier *notifier);
> -void qemu_system_wakeup_request(void);
> +void qemu_system_wakeup_request(WakeupReason reason);
> +void qemu_register_wakeup_notifier(Notifier *notifier);
>  void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
>  void qemu_system_debug_request(void);
> diff --git a/vl.c b/vl.c
> index 822fd58..17d4b72 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1286,6 +1286,8 @@ static int debug_requested;
>  static bool is_suspended;
>  static NotifierList suspend_notifiers =
>      NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
> +static NotifierList wakeup_notifiers =
> +    NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  
>  int qemu_shutdown_requested_get(void)
> @@ -1416,16 +1418,22 @@ void qemu_register_suspend_notifier(Notifier *notifier)
>      notifier_list_add(&suspend_notifiers, notifier);
>  }
>  
> -void qemu_system_wakeup_request(void)
> +void qemu_system_wakeup_request(WakeupReason reason)
>  {
>      if (!is_suspended) {
>          return;
>      }
> +    notifier_list_notify(&wakeup_notifiers, &reason);
>      reset_requested = 1;
>      qemu_notify_event();
>      is_suspended = false;
>  }
>  
> +void qemu_register_wakeup_notifier(Notifier *notifier)
> +{
> +    notifier_list_add(&wakeup_notifiers, notifier);
> +}
> +
>  void qemu_system_killed(int signal, pid_t pid)
>  {
>      shutdown_signal = signal;


--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTFi-0000PL-Ay; Thu, 09 Feb 2012 12:37: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 1RvTFg-0000P1-1v
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:37:28 +0000
Received: from [85.158.139.83:49011] by server-12.bemta-5.messagelabs.com id
	CB/D2-30830-70EB33F4; Thu, 09 Feb 2012 12:37:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328791045!14314489!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17983 invoked from network); 9 Feb 2012 12:37:26 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:37:26 -0000
Received: by yenm7 with SMTP id m7so21872647yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:37:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ROrjE0XK+0wXogX2sm3N1LaohcZ/EF5sJjgVo+bLLUw=;
	b=P6oYCQfV3RO/bKS0Trdsa8U9jZoiGdVDnkOM5Qw5CtwRHybm0CyOj7xjClpLIa8/Bv
	9qbS7Ozh09N606q4kAaBiP83AjB7W3K9KT3+AgZ0uXQJvJ9sNiWMXiRhJq0+iYykNaEi
	ubbvwpfWiCZq24PwRTCWHA5/NXtE4jlJwJus0=
Received: by 10.50.34.202 with SMTP id b10mr2541555igj.30.1328791044409;
	Thu, 09 Feb 2012 04:37:24 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id f26sm5098487ibc.9.2012.02.09.04.37.21
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:37:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:37:17 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB58FDFD.2AC04%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] gnttab: miscellaneous fixes
Thread-Index: AcznJ46nTRBfxrDcHkqwNPGFTk7tvQ==
In-Reply-To: <4F33B8E30200007800071DD0@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] gnttab: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/2012 03:15, "Jan Beulich" <JBeulich@suse.com> wrote:

> - _GTF_* constants name bit positions, so binary arithmetic on them is
>   wrong
> - gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
>   clear_bit(), as that may access more than the two bytes that are
>   intended to be accessed
> 
> 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
> @@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
>               (id != domid) ||
>               (!readonly && (flags & GTF_readonly)) )
>          {
> -            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
> +            gnttab_clear_flag(_GTF_writing, status);
> +            gnttab_clear_flag(_GTF_reading, status);
>              PIN_FAIL(done, GNTST_general_error,
>                       "Unstable flags (%x) or dom (%d). (expected dom %d) "
>                       "(r/w: %d)\n",
> @@ -1716,14 +1717,14 @@ __release_grant_for_copy(
>     under the domain's grant table lock. */
>  /* Only safe on transitive grants.  Even then, note that we don't
>     attempt to drop any pin on the referent grant. */
> -static void __fixup_status_for_pin(struct active_grant_entry *act,
> +static void __fixup_status_for_pin(const struct active_grant_entry *act,
>                                     uint16_t *status)
>  {
>      if ( !(act->pin & GNTPIN_hstw_mask) )
> -        *status &= ~_GTF_writing;
> +        *status &= ~GTF_writing;
>  
>      if ( !(act->pin & GNTPIN_hstr_mask) )
> -        *status &= ~_GTF_reading;
> +        *status &= ~GTF_reading;
>  }
>  
>  /* Grab a frame number from a grant entry and update the flags and pin
> --- a/xen/include/asm-ia64/grant_table.h
> +++ b/xen/include/asm-ia64/grant_table.h
> @@ -5,6 +5,8 @@
>  #ifndef __ASM_GRANT_TABLE_H__
>  #define __ASM_GRANT_TABLE_H__
>  
> +#include <asm/intrinsics.h>
> +
>  #define INITIAL_NR_GRANT_FRAMES 1
>  
>  // for grant map/unmap
> @@ -82,9 +84,19 @@ int guest_physmap_add_page(struct domain
>  
>  #define gnttab_mark_dirty(d, f) ((void)f)
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t *st)
>  {
> - clear_bit(nr, addr);
> + /*
> +  * Note that this cannot be clear_bit(), as the access must be
> +  * confined to the specified 2 bytes.
> +  */
> + uint16_t mask = ~(1 << nr), old;
> + CMPXCHG_BUGCHECK_DECL
> +
> + do {
> +  CMPXCHG_BUGCHECK(st);
> +  old = *st;
> + } while (cmpxchg_rel(st, old, old & mask) != old);
>  }
>  
>  #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
> --- a/xen/include/asm-x86/grant_table.h
> +++ b/xen/include/asm-x86/grant_table.h
> @@ -48,9 +48,13 @@ int replace_grant_host_mapping(
>  
>  #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, uint16_t *st)
>  {
> -    clear_bit(nr, (unsigned long *)addr);
> +    /*
> +     * Note that this cannot be clear_bit(), as the access must be
> +     * confined to the specified 2 bytes.
> +     */
> +    asm volatile ("lock btrw %1,%0" : "=m" (*st) : "Ir" (nr), "m" (*st));
>  }
>  
>  /* Foreign mappings of HHVM-guest pages do not modify the type count. */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTFi-0000PL-Ay; Thu, 09 Feb 2012 12:37: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 1RvTFg-0000P1-1v
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:37:28 +0000
Received: from [85.158.139.83:49011] by server-12.bemta-5.messagelabs.com id
	CB/D2-30830-70EB33F4; Thu, 09 Feb 2012 12:37:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328791045!14314489!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17983 invoked from network); 9 Feb 2012 12:37:26 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:37:26 -0000
Received: by yenm7 with SMTP id m7so21872647yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:37:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ROrjE0XK+0wXogX2sm3N1LaohcZ/EF5sJjgVo+bLLUw=;
	b=P6oYCQfV3RO/bKS0Trdsa8U9jZoiGdVDnkOM5Qw5CtwRHybm0CyOj7xjClpLIa8/Bv
	9qbS7Ozh09N606q4kAaBiP83AjB7W3K9KT3+AgZ0uXQJvJ9sNiWMXiRhJq0+iYykNaEi
	ubbvwpfWiCZq24PwRTCWHA5/NXtE4jlJwJus0=
Received: by 10.50.34.202 with SMTP id b10mr2541555igj.30.1328791044409;
	Thu, 09 Feb 2012 04:37:24 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id f26sm5098487ibc.9.2012.02.09.04.37.21
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:37:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:37:17 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB58FDFD.2AC04%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] gnttab: miscellaneous fixes
Thread-Index: AcznJ46nTRBfxrDcHkqwNPGFTk7tvQ==
In-Reply-To: <4F33B8E30200007800071DD0@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] gnttab: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/2012 03:15, "Jan Beulich" <JBeulich@suse.com> wrote:

> - _GTF_* constants name bit positions, so binary arithmetic on them is
>   wrong
> - gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
>   clear_bit(), as that may access more than the two bytes that are
>   intended to be accessed
> 
> 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
> @@ -397,7 +397,8 @@ static int _set_status_v2(domid_t  domid
>               (id != domid) ||
>               (!readonly && (flags & GTF_readonly)) )
>          {
> -            gnttab_clear_flag(_GTF_reading | _GTF_writing, status);
> +            gnttab_clear_flag(_GTF_writing, status);
> +            gnttab_clear_flag(_GTF_reading, status);
>              PIN_FAIL(done, GNTST_general_error,
>                       "Unstable flags (%x) or dom (%d). (expected dom %d) "
>                       "(r/w: %d)\n",
> @@ -1716,14 +1717,14 @@ __release_grant_for_copy(
>     under the domain's grant table lock. */
>  /* Only safe on transitive grants.  Even then, note that we don't
>     attempt to drop any pin on the referent grant. */
> -static void __fixup_status_for_pin(struct active_grant_entry *act,
> +static void __fixup_status_for_pin(const struct active_grant_entry *act,
>                                     uint16_t *status)
>  {
>      if ( !(act->pin & GNTPIN_hstw_mask) )
> -        *status &= ~_GTF_writing;
> +        *status &= ~GTF_writing;
>  
>      if ( !(act->pin & GNTPIN_hstr_mask) )
> -        *status &= ~_GTF_reading;
> +        *status &= ~GTF_reading;
>  }
>  
>  /* Grab a frame number from a grant entry and update the flags and pin
> --- a/xen/include/asm-ia64/grant_table.h
> +++ b/xen/include/asm-ia64/grant_table.h
> @@ -5,6 +5,8 @@
>  #ifndef __ASM_GRANT_TABLE_H__
>  #define __ASM_GRANT_TABLE_H__
>  
> +#include <asm/intrinsics.h>
> +
>  #define INITIAL_NR_GRANT_FRAMES 1
>  
>  // for grant map/unmap
> @@ -82,9 +84,19 @@ int guest_physmap_add_page(struct domain
>  
>  #define gnttab_mark_dirty(d, f) ((void)f)
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, volatile uint16_t *st)
>  {
> - clear_bit(nr, addr);
> + /*
> +  * Note that this cannot be clear_bit(), as the access must be
> +  * confined to the specified 2 bytes.
> +  */
> + uint16_t mask = ~(1 << nr), old;
> + CMPXCHG_BUGCHECK_DECL
> +
> + do {
> +  CMPXCHG_BUGCHECK(st);
> +  old = *st;
> + } while (cmpxchg_rel(st, old, old & mask) != old);
>  }
>  
>  #define gnttab_host_mapping_get_page_type(op, ld, rd)   \
> --- a/xen/include/asm-x86/grant_table.h
> +++ b/xen/include/asm-x86/grant_table.h
> @@ -48,9 +48,13 @@ int replace_grant_host_mapping(
>  
>  #define gnttab_mark_dirty(d, f) paging_mark_dirty((d), (f))
>  
> -static inline void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
> +static inline void gnttab_clear_flag(unsigned int nr, uint16_t *st)
>  {
> -    clear_bit(nr, (unsigned long *)addr);
> +    /*
> +     * Note that this cannot be clear_bit(), as the access must be
> +     * confined to the specified 2 bytes.
> +     */
> +    asm volatile ("lock btrw %1,%0" : "=m" (*st) : "Ir" (nr), "m" (*st));
>  }
>  
>  /* Foreign mappings of HHVM-guest pages do not modify the type count. */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTGV-0000Wn-CG; Thu, 09 Feb 2012 12:38:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvTGT-0000Vk-En
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:38:17 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328791090!12685362!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10393 invoked from network); 9 Feb 2012 12:38:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 12:38:10 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19C0oYb030877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:00:50 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19C0l2E017536; Thu, 9 Feb 2012 07:00:48 -0500
Message-ID: <4F33B56F.5020000@redhat.com>
Date: Thu, 09 Feb 2012 13:00:47 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-7-git-send-email-kraxel@redhat.com>
	<20120209085658.GE18866@redhat.com>
In-Reply-To: <20120209085658.GE18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm
 wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 09:56, Gleb Natapov wrote:
> On Wed, Feb 08, 2012 at 12:00:19PM +0100, Gerd Hoffmann wrote:
>> Add a 'wakeup' property to the mc146818rtc.  It is on by default.
>> When enabled the rtc will wake up the guest when the alarm fires.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> ---
>>  hw/mc146818rtc.c |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
>> index 314ed52..3b912c6 100644
>> --- a/hw/mc146818rtc.c
>> +++ b/hw/mc146818rtc.c
>> @@ -86,6 +86,7 @@ typedef struct RTCState {
>>      uint8_t cmos_index;
>>      struct tm current_tm;
>>      int32_t base_year;
>> +    uint32_t wakeup;
>>      qemu_irq irq;
>>      qemu_irq sqw_irq;
>>      int it_shift;
>> @@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
>>  
>>          s->cmos_data[RTC_REG_C] |= REG_C_AF;
>>          if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
>> +            if (s->wakeup) {
>> +                qemu_system_wakeup_request();
>> +            }
> RTC should do wakeup only if RTC_EN bit is set pm1en.

--verbose please.  Which register, which bit?  There is no RTC_EN in
hw/mc146818rtc.* ...

Is this enable bit specifically for wakeup from suspend?

thanks,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:38:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTGV-0000Wn-CG; Thu, 09 Feb 2012 12:38:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvTGT-0000Vk-En
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:38:17 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328791090!12685362!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10393 invoked from network); 9 Feb 2012 12:38:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 12:38:10 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19C0oYb030877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:00:50 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19C0l2E017536; Thu, 9 Feb 2012 07:00:48 -0500
Message-ID: <4F33B56F.5020000@redhat.com>
Date: Thu, 09 Feb 2012 13:00:47 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-7-git-send-email-kraxel@redhat.com>
	<20120209085658.GE18866@redhat.com>
In-Reply-To: <20120209085658.GE18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm
 wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 09:56, Gleb Natapov wrote:
> On Wed, Feb 08, 2012 at 12:00:19PM +0100, Gerd Hoffmann wrote:
>> Add a 'wakeup' property to the mc146818rtc.  It is on by default.
>> When enabled the rtc will wake up the guest when the alarm fires.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> ---
>>  hw/mc146818rtc.c |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
>> index 314ed52..3b912c6 100644
>> --- a/hw/mc146818rtc.c
>> +++ b/hw/mc146818rtc.c
>> @@ -86,6 +86,7 @@ typedef struct RTCState {
>>      uint8_t cmos_index;
>>      struct tm current_tm;
>>      int32_t base_year;
>> +    uint32_t wakeup;
>>      qemu_irq irq;
>>      qemu_irq sqw_irq;
>>      int it_shift;
>> @@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
>>  
>>          s->cmos_data[RTC_REG_C] |= REG_C_AF;
>>          if (s->cmos_data[RTC_REG_B] & REG_B_AIE) {
>> +            if (s->wakeup) {
>> +                qemu_system_wakeup_request();
>> +            }
> RTC should do wakeup only if RTC_EN bit is set pm1en.

--verbose please.  Which register, which bit?  There is no RTC_EN in
hw/mc146818rtc.* ...

Is this enable bit specifically for wakeup from suspend?

thanks,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:39:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTH4-0000dy-Hc; Thu, 09 Feb 2012 12:38:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTH3-0000ct-Aq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:38:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328791126!12609667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18875 invoked from network); 9 Feb 2012 12:38:47 -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;
	9 Feb 2012 12:38:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10597240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 12:38:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	12:38:46 +0000
Message-ID: <1328791125.6133.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 12:38:45 +0000
In-Reply-To: <90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
	<90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2 V3] libxl: Remus -
 suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:00 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 90e59c643c00c079996e13b75f89d1f0cd931a02
> # Parent  c7abecc14cceb18140335ebe20faad826282cd1f
> libxl: Remus - suspend/postflush/commit callbacks
> 
>  * Add libxl callback functions for Remus checkpoint suspend, postflush
>    (aka resume) and checkpoint commit callbacks.
>  * suspend callback is a stub that just bounces off
>    libxl__domain_suspend_common_callback - which suspends the domain and
>    saves the devices model state to a file.
>  * resume callback currently just resumes the domain (and the device model).
>  * commit callback just writes out the saved device model state to the
>    network and sleeps for the checkpoint interval.
>  * Introduce a new public API, libxl_domain_remus_start (currently a stub)
>    that sets up the network and disk buffer and initiates continuous
>    checkpointing.
> 
>  * Future patches will augument these callbacks/functions with more functionalities

                        "augment"

>    like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -471,6 +471,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
>      return ptr;
>  }
>  
> +/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int send_fd, int recv_fd)
> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d", domid);
> +        rc = ERROR_INVAL;
> +        goto remus_fail;
> +    }
> +
> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */

Is it worth checking that the domain has no disks or network (IOW is
this dangerous if they do?)

[...]
> @@ -791,7 +837,27 @@ int libxl__domain_suspend_common(libxl__
>      }
>  
>      memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        /* save_callbacks:
> +         * suspend - called after expiration of checkpoint interval,
> +         *           to *suspend* the domain.
> +         *
> +         * postcopy - called after the domain's dirty pages have been
> +         *            copied into an output buffer. We *resume* the domain
> +         *            & the device model, return to the caller. Caller then
> +         *            flushes the output buffer, while the domain continues to run.
> +         *
> +         * checkpoint - called after the memory checkpoint has been flushed out
> +         *              into the network. Send the saved device state, *wait*
> +         *              for checkpoint ack and *release* the network buffer (TBD).
> +         *              Then *sleep* for the checkpoint interval.
> +         */

I think this comment would be more useful in xenguest.h next to the
callback struct.

Otherwise the patch looks good.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:39:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTH4-0000dy-Hc; Thu, 09 Feb 2012 12:38:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTH3-0000ct-Aq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:38:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328791126!12609667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18875 invoked from network); 9 Feb 2012 12:38:47 -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;
	9 Feb 2012 12:38:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10597240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 12:38:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	12:38:46 +0000
Message-ID: <1328791125.6133.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 12:38:45 +0000
In-Reply-To: <90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
	<90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2 V3] libxl: Remus -
 suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:00 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 90e59c643c00c079996e13b75f89d1f0cd931a02
> # Parent  c7abecc14cceb18140335ebe20faad826282cd1f
> libxl: Remus - suspend/postflush/commit callbacks
> 
>  * Add libxl callback functions for Remus checkpoint suspend, postflush
>    (aka resume) and checkpoint commit callbacks.
>  * suspend callback is a stub that just bounces off
>    libxl__domain_suspend_common_callback - which suspends the domain and
>    saves the devices model state to a file.
>  * resume callback currently just resumes the domain (and the device model).
>  * commit callback just writes out the saved device model state to the
>    network and sleeps for the checkpoint interval.
>  * Introduce a new public API, libxl_domain_remus_start (currently a stub)
>    that sets up the network and disk buffer and initiates continuous
>    checkpointing.
> 
>  * Future patches will augument these callbacks/functions with more functionalities

                        "augment"

>    like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r c7abecc14cce -r 90e59c643c00 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> +++ b/tools/libxl/libxl.c	Thu Feb 02 22:46:33 2012 -0800
> @@ -471,6 +471,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
>      return ptr;
>  }
>  
> +/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int send_fd, int recv_fd)
> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d", domid);
> +        rc = ERROR_INVAL;
> +        goto remus_fail;
> +    }
> +
> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */

Is it worth checking that the domain has no disks or network (IOW is
this dangerous if they do?)

[...]
> @@ -791,7 +837,27 @@ int libxl__domain_suspend_common(libxl__
>      }
>  
>      memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        /* save_callbacks:
> +         * suspend - called after expiration of checkpoint interval,
> +         *           to *suspend* the domain.
> +         *
> +         * postcopy - called after the domain's dirty pages have been
> +         *            copied into an output buffer. We *resume* the domain
> +         *            & the device model, return to the caller. Caller then
> +         *            flushes the output buffer, while the domain continues to run.
> +         *
> +         * checkpoint - called after the memory checkpoint has been flushed out
> +         *              into the network. Send the saved device state, *wait*
> +         *              for checkpoint ack and *release* the network buffer (TBD).
> +         *              Then *sleep* for the checkpoint interval.
> +         */

I think this comment would be more useful in xenguest.h next to the
callback struct.

Otherwise the patch looks good.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:42:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvTKi-0000zy-7S; Thu, 09 Feb 2012 12:42: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 1RvTKg-0000zl-Bh
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:42:38 +0000
Received: from [85.158.139.83:29169] by server-3.bemta-5.messagelabs.com id
	03/14-25605-D3FB33F4; Thu, 09 Feb 2012 12:42:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328791353!14375737!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2257 invoked from network); 9 Feb 2012 12:42:35 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:42:35 -0000
Received: by yenm7 with SMTP id m7so21930254yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:42:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=/OviC9zBH1Kg9qE6MO0n+666ZFtoVBsRTM6rLlvvpAA=;
	b=LSqdNR7zSOau3rAXA8xvpFN5jIbfYb7a0b1bOUXXNegh7rMan3F+2gPmJexyKOfCmZ
	8ln9ILIwCOhhLWI3gylFzr59iZ9PaSa/xUYnI9wc9KW+JIboeP/SHIG7x0g7oG7oufsO
	iS15GE6VVT0/JIrMDAa2kQfkHg9NQea7HiycI=
Received: by 10.50.15.231 with SMTP id a7mr2636522igd.8.1328791353083;
	Thu, 09 Feb 2012 04:42:33 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id ut1sm4039084igc.2.2012.02.09.04.42.30
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:42:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:42:22 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB58FF2E.2AC13%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier definitions
Thread-Index: AcznKERz3JKTOnQRQkS1g+bPC4/kYg==
In-Reply-To: <4F33B2C50200007800071DA5@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier
	definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/2012 02:49, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 08.02.12 at 17:45, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Now CONFIG_SMP has been removed, there is no need to define
>> smp_{,r,w}mb()s which used to conditionally compiled to different
>> operations (even though those conditonally different operations still
>> ended up as simple barrier()s)
>> 
>> Therefore, remove smp_{,r,w}mb()s and just use regular {,r,w}mb()s
> 
> Did you read the Linux side description and usage guidelines before
> doing this? I don't think doing the adjustment here is a good idea,
> even if the smp_ ones are aliases of the plain ones (which doesn't
> necessarily have to the case on any future architectures Xen might
> get ported to).

In that they can document barriers used on shared memory versus I/O memory,
perhaps worth keeping the smp_* variants.

 -- Keir

> Jan
> 
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> 
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/acpi/cpu_idle.c
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -260,7 +260,7 @@ static void mwait_idle_with_hints(unsign
>>      s_time_t expires = per_cpu(timer_deadline, cpu);
>>  
>>      __monitor((void *)&mwait_wakeup(cpu), 0, 0);
>> -    smp_mb();
>> +    mb();
>>  
>>      /*
>>       * Timer deadline passing is the event on which we will be woken via
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/cpu/mtrr/main.c
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -248,7 +248,7 @@ static void set_mtrr(unsigned int reg, u
>>  
>> /* ok, reset count and toggle gate */
>> atomic_set(&data.count, nr_cpus);
>> - smp_wmb();
>> + wmb();
>> atomic_set(&data.gate,1);
>>  
>> /* do our MTRR business */
>> @@ -271,7 +271,7 @@ static void set_mtrr(unsigned int reg, u
>> cpu_relax();
>>  
>> atomic_set(&data.count, nr_cpus);
>> - smp_wmb();
>> + wmb();
>> atomic_set(&data.gate,0);
>>  
>> /*
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/irq.c
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -207,7 +207,7 @@ static void dynamic_irq_cleanup(unsigned
>>      spin_unlock_irqrestore(&desc->lock, flags);
>>  
>>      /* Wait to make sure it's not being used on another CPU */
>> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>>      if (action)
>>          xfree(action);
>> @@ -931,7 +931,7 @@ void __init release_irq(unsigned int irq
>>      spin_unlock_irqrestore(&desc->lock,flags);
>>  
>>      /* Wait to make sure it's not being used on another CPU */
>> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>>      if (action && action->free_on_release)
>>          xfree(action);
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/domain.c
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -544,7 +544,7 @@ void domain_shutdown(struct domain *d, u
>>  
>>      d->is_shutting_down = 1;
>>  
>> -    smp_mb(); /* set shutdown status /then/ check for per-cpu deferrals */
>> +    mb(); /* set shutdown status /then/ check for per-cpu deferrals */
>>  
>>      for_each_vcpu ( d, v )
>>      {
>> @@ -594,7 +594,7 @@ int vcpu_start_shutdown_deferral(struct
>>          return 1;
>>  
>>      v->defer_shutdown = 1;
>> -    smp_mb(); /* set deferral status /then/ check for shutdown */
>> +    mb(); /* set deferral status /then/ check for shutdown */
>>      if ( unlikely(v->domain->is_shutting_down) )
>>          vcpu_check_shutdown(v);
>>  
>> @@ -604,7 +604,7 @@ int vcpu_start_shutdown_deferral(struct
>>  void vcpu_end_shutdown_deferral(struct vcpu *v)
>>  {
>>      v->defer_shutdown = 0;
>> -    smp_mb(); /* clear deferral status /then/ check for shutdown */
>> +    mb(); /* clear deferral status /then/ check for shutdown */
>>      if ( unlikely(v->domain->is_shutting_down) )
>>          vcpu_check_shutdown(v);
>>  }
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/rcupdate.c
>> --- a/xen/common/rcupdate.c
>> +++ b/xen/common/rcupdate.c
>> @@ -252,7 +252,7 @@ static void rcu_start_batch(struct rcu_c
>>           * next_pending == 0 must be visible in
>>           * __rcu_process_callbacks() before it can see new value of cur.
>>           */
>> -        smp_wmb();
>> +        wmb();
>>          rcp->cur++;
>>  
>>          cpumask_copy(&rcp->cpumask, &cpu_online_map);
>> @@ -340,7 +340,7 @@ static void __rcu_process_callbacks(stru
>>          /* see the comment and corresponding wmb() in
>>           * the rcu_start_batch()
>>           */
>> -        smp_rmb();
>> +        rmb();
>>  
>>          if (!rcp->next_pending) {
>>              /* and start it/schedule start if it's a new batch */
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/schedule.c
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -657,7 +657,7 @@ static long do_poll(struct sched_poll *s
>>  
>>  #ifndef CONFIG_X86 /* set_bit() implies mb() on x86 */
>>      /* Check for events /after/ setting flags: avoids wakeup waiting race.
>> */
>> -    smp_mb();
>> +    mb();
>>  
>>      /*
>>       * Someone may have seen we are blocked but not that we are polling, or
>> @@ -1173,12 +1173,12 @@ static void schedule(void)
>>  void context_saved(struct vcpu *prev)
>>  {
>>      /* Clear running flag /after/ writing context to memory. */
>> -    smp_wmb();
>> +    wmb();
>>  
>>      prev->is_running = 0;
>>  
>>      /* Check for migration request /after/ clearing running flag. */
>> -    smp_mb();
>> +    mb();
>>  
>>      SCHED_OP(VCPU2OP(prev), context_saved, prev);
>>  
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/stop_machine.c
>> --- a/xen/common/stop_machine.c
>> +++ b/xen/common/stop_machine.c
>> @@ -59,7 +59,7 @@ static DEFINE_SPINLOCK(stopmachine_lock)
>>  static void stopmachine_set_state(enum stopmachine_state state)
>>  {
>>      atomic_set(&stopmachine_data.done, 0);
>> -    smp_wmb();
>> +    wmb();
>>      stopmachine_data.state = state;
>>  }
>>  
>> @@ -99,7 +99,7 @@ int stop_machine_run(int (*fn)(void *),
>>      atomic_set(&stopmachine_data.done, 0);
>>      stopmachine_data.state = STOPMACHINE_START;
>>  
>> -    smp_wmb();
>> +    wmb();
>>  
>>      for_each_cpu ( i, &allbutself )
>>          tasklet_schedule_on_cpu(&per_cpu(stopmachine_tasklet, i), i);
>> @@ -134,7 +134,7 @@ static void stopmachine_action(unsigned
>>  
>>      BUG_ON(cpu != smp_processor_id());
>>  
>> -    smp_mb();
>> +    mb();
>>  
>>      while ( state != STOPMACHINE_EXIT )
>>      {
>> @@ -157,7 +157,7 @@ static void stopmachine_action(unsigned
>>              break;
>>          }
>>  
>> -        smp_mb();
>> +        mb();
>>          atomic_inc(&stopmachine_data.done);
>>      }
>>  
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/asm-x86/system.h
>> --- a/xen/include/asm-x86/system.h
>> +++ b/xen/include/asm-x86/system.h
>> @@ -154,10 +154,6 @@ static always_inline unsigned long __cmp
>>  #define rmb()           barrier()
>>  #define wmb()           barrier()
>>  
>> -#define smp_mb()        mb()
>> -#define smp_rmb()       rmb()
>> -#define smp_wmb()       wmb()
>> -
>>  #define set_mb(var, value) do { xchg(&var, value); } while (0)
>>  #define set_wmb(var, value) do { var = value; wmb(); } while (0)
>>  
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/list.h
>> --- a/xen/include/xen/list.h
>> +++ b/xen/include/xen/list.h
>> @@ -102,7 +102,7 @@ static inline void __list_add_rcu(struct
>>  {
>>      new->next = next;
>>      new->prev = prev;
>> -    smp_wmb();
>> +    wmb();
>>      next->prev = new;
>>      prev->next = new;
>>  }
>> @@ -244,7 +244,7 @@ static inline void list_replace_rcu(stru
>>  {
>>      new->next = old->next;
>>      new->prev = old->prev;
>> -    smp_wmb();
>> +    wmb();
>>      new->next->prev = new;
>>      new->prev->next = new;
>>      old->prev = LIST_POISON2;
>> @@ -712,7 +712,7 @@ static inline void hlist_replace_rcu(str
>>  
>>      new->next = next;
>>      new->pprev = old->pprev;
>> -    smp_wmb();
>> +    wmb();
>>      if (next)
>>          new->next->pprev = &new->next;
>>      *new->pprev = new;
>> @@ -754,7 +754,7 @@ static inline void hlist_add_head_rcu(st
>>      struct hlist_node *first = h->first;
>>      n->next = first;
>>      n->pprev = &h->first;
>> -    smp_wmb();
>> +    wmb();
>>      if (first)
>>          first->pprev = &n->next;
>>      h->first = n;
>> @@ -804,7 +804,7 @@ static inline void hlist_add_before_rcu(
>>  {
>>      n->pprev = next->pprev;
>>      n->next = next;
>> -    smp_wmb();
>> +    wmb();
>>      next->pprev = &n->next;
>>      *(n->pprev) = n;
>>  }
>> @@ -832,7 +832,7 @@ static inline void hlist_add_after_rcu(s
>>  {
>>      n->next = prev->next;
>>      n->pprev = &prev->next;
>> -    smp_wmb();
>> +    wmb();
>>      prev->next = n;
>>      if (n->next)
>>          n->next->pprev = &n->next;
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/rcupdate.h
>> --- a/xen/include/xen/rcupdate.h
>> +++ b/xen/include/xen/rcupdate.h
>> @@ -136,7 +136,7 @@ typedef struct _rcu_read_lock rcu_read_l
>>   * call documents which pointers will be dereferenced by RCU read-side
>>   * code.
>>   */
>> -#define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); })
>> +#define rcu_assign_pointer(p, v) ({ wmb(); (p) = (v); })
>>  
>>  void rcu_init(void);
>>  void rcu_check_callbacks(int cpu);
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:42:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvTKi-0000zy-7S; Thu, 09 Feb 2012 12:42: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 1RvTKg-0000zl-Bh
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:42:38 +0000
Received: from [85.158.139.83:29169] by server-3.bemta-5.messagelabs.com id
	03/14-25605-D3FB33F4; Thu, 09 Feb 2012 12:42:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328791353!14375737!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2257 invoked from network); 9 Feb 2012 12:42:35 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:42:35 -0000
Received: by yenm7 with SMTP id m7so21930254yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:42:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=/OviC9zBH1Kg9qE6MO0n+666ZFtoVBsRTM6rLlvvpAA=;
	b=LSqdNR7zSOau3rAXA8xvpFN5jIbfYb7a0b1bOUXXNegh7rMan3F+2gPmJexyKOfCmZ
	8ln9ILIwCOhhLWI3gylFzr59iZ9PaSa/xUYnI9wc9KW+JIboeP/SHIG7x0g7oG7oufsO
	iS15GE6VVT0/JIrMDAa2kQfkHg9NQea7HiycI=
Received: by 10.50.15.231 with SMTP id a7mr2636522igd.8.1328791353083;
	Thu, 09 Feb 2012 04:42:33 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id ut1sm4039084igc.2.2012.02.09.04.42.30
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:42:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:42:22 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CB58FF2E.2AC13%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier definitions
Thread-Index: AcznKERz3JKTOnQRQkS1g+bPC4/kYg==
In-Reply-To: <4F33B2C50200007800071DA5@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 4] CONFIG: remove smp barrier
	definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/2012 02:49, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 08.02.12 at 17:45, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Now CONFIG_SMP has been removed, there is no need to define
>> smp_{,r,w}mb()s which used to conditionally compiled to different
>> operations (even though those conditonally different operations still
>> ended up as simple barrier()s)
>> 
>> Therefore, remove smp_{,r,w}mb()s and just use regular {,r,w}mb()s
> 
> Did you read the Linux side description and usage guidelines before
> doing this? I don't think doing the adjustment here is a good idea,
> even if the smp_ ones are aliases of the plain ones (which doesn't
> necessarily have to the case on any future architectures Xen might
> get ported to).

In that they can document barriers used on shared memory versus I/O memory,
perhaps worth keeping the smp_* variants.

 -- Keir

> Jan
> 
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> 
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/acpi/cpu_idle.c
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -260,7 +260,7 @@ static void mwait_idle_with_hints(unsign
>>      s_time_t expires = per_cpu(timer_deadline, cpu);
>>  
>>      __monitor((void *)&mwait_wakeup(cpu), 0, 0);
>> -    smp_mb();
>> +    mb();
>>  
>>      /*
>>       * Timer deadline passing is the event on which we will be woken via
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/cpu/mtrr/main.c
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -248,7 +248,7 @@ static void set_mtrr(unsigned int reg, u
>>  
>> /* ok, reset count and toggle gate */
>> atomic_set(&data.count, nr_cpus);
>> - smp_wmb();
>> + wmb();
>> atomic_set(&data.gate,1);
>>  
>> /* do our MTRR business */
>> @@ -271,7 +271,7 @@ static void set_mtrr(unsigned int reg, u
>> cpu_relax();
>>  
>> atomic_set(&data.count, nr_cpus);
>> - smp_wmb();
>> + wmb();
>> atomic_set(&data.gate,0);
>>  
>> /*
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/arch/x86/irq.c
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -207,7 +207,7 @@ static void dynamic_irq_cleanup(unsigned
>>      spin_unlock_irqrestore(&desc->lock, flags);
>>  
>>      /* Wait to make sure it's not being used on another CPU */
>> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>>      if (action)
>>          xfree(action);
>> @@ -931,7 +931,7 @@ void __init release_irq(unsigned int irq
>>      spin_unlock_irqrestore(&desc->lock,flags);
>>  
>>      /* Wait to make sure it's not being used on another CPU */
>> -    do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>> +    do { mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>>      if (action && action->free_on_release)
>>          xfree(action);
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/domain.c
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -544,7 +544,7 @@ void domain_shutdown(struct domain *d, u
>>  
>>      d->is_shutting_down = 1;
>>  
>> -    smp_mb(); /* set shutdown status /then/ check for per-cpu deferrals */
>> +    mb(); /* set shutdown status /then/ check for per-cpu deferrals */
>>  
>>      for_each_vcpu ( d, v )
>>      {
>> @@ -594,7 +594,7 @@ int vcpu_start_shutdown_deferral(struct
>>          return 1;
>>  
>>      v->defer_shutdown = 1;
>> -    smp_mb(); /* set deferral status /then/ check for shutdown */
>> +    mb(); /* set deferral status /then/ check for shutdown */
>>      if ( unlikely(v->domain->is_shutting_down) )
>>          vcpu_check_shutdown(v);
>>  
>> @@ -604,7 +604,7 @@ int vcpu_start_shutdown_deferral(struct
>>  void vcpu_end_shutdown_deferral(struct vcpu *v)
>>  {
>>      v->defer_shutdown = 0;
>> -    smp_mb(); /* clear deferral status /then/ check for shutdown */
>> +    mb(); /* clear deferral status /then/ check for shutdown */
>>      if ( unlikely(v->domain->is_shutting_down) )
>>          vcpu_check_shutdown(v);
>>  }
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/rcupdate.c
>> --- a/xen/common/rcupdate.c
>> +++ b/xen/common/rcupdate.c
>> @@ -252,7 +252,7 @@ static void rcu_start_batch(struct rcu_c
>>           * next_pending == 0 must be visible in
>>           * __rcu_process_callbacks() before it can see new value of cur.
>>           */
>> -        smp_wmb();
>> +        wmb();
>>          rcp->cur++;
>>  
>>          cpumask_copy(&rcp->cpumask, &cpu_online_map);
>> @@ -340,7 +340,7 @@ static void __rcu_process_callbacks(stru
>>          /* see the comment and corresponding wmb() in
>>           * the rcu_start_batch()
>>           */
>> -        smp_rmb();
>> +        rmb();
>>  
>>          if (!rcp->next_pending) {
>>              /* and start it/schedule start if it's a new batch */
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/schedule.c
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -657,7 +657,7 @@ static long do_poll(struct sched_poll *s
>>  
>>  #ifndef CONFIG_X86 /* set_bit() implies mb() on x86 */
>>      /* Check for events /after/ setting flags: avoids wakeup waiting race.
>> */
>> -    smp_mb();
>> +    mb();
>>  
>>      /*
>>       * Someone may have seen we are blocked but not that we are polling, or
>> @@ -1173,12 +1173,12 @@ static void schedule(void)
>>  void context_saved(struct vcpu *prev)
>>  {
>>      /* Clear running flag /after/ writing context to memory. */
>> -    smp_wmb();
>> +    wmb();
>>  
>>      prev->is_running = 0;
>>  
>>      /* Check for migration request /after/ clearing running flag. */
>> -    smp_mb();
>> +    mb();
>>  
>>      SCHED_OP(VCPU2OP(prev), context_saved, prev);
>>  
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/common/stop_machine.c
>> --- a/xen/common/stop_machine.c
>> +++ b/xen/common/stop_machine.c
>> @@ -59,7 +59,7 @@ static DEFINE_SPINLOCK(stopmachine_lock)
>>  static void stopmachine_set_state(enum stopmachine_state state)
>>  {
>>      atomic_set(&stopmachine_data.done, 0);
>> -    smp_wmb();
>> +    wmb();
>>      stopmachine_data.state = state;
>>  }
>>  
>> @@ -99,7 +99,7 @@ int stop_machine_run(int (*fn)(void *),
>>      atomic_set(&stopmachine_data.done, 0);
>>      stopmachine_data.state = STOPMACHINE_START;
>>  
>> -    smp_wmb();
>> +    wmb();
>>  
>>      for_each_cpu ( i, &allbutself )
>>          tasklet_schedule_on_cpu(&per_cpu(stopmachine_tasklet, i), i);
>> @@ -134,7 +134,7 @@ static void stopmachine_action(unsigned
>>  
>>      BUG_ON(cpu != smp_processor_id());
>>  
>> -    smp_mb();
>> +    mb();
>>  
>>      while ( state != STOPMACHINE_EXIT )
>>      {
>> @@ -157,7 +157,7 @@ static void stopmachine_action(unsigned
>>              break;
>>          }
>>  
>> -        smp_mb();
>> +        mb();
>>          atomic_inc(&stopmachine_data.done);
>>      }
>>  
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/asm-x86/system.h
>> --- a/xen/include/asm-x86/system.h
>> +++ b/xen/include/asm-x86/system.h
>> @@ -154,10 +154,6 @@ static always_inline unsigned long __cmp
>>  #define rmb()           barrier()
>>  #define wmb()           barrier()
>>  
>> -#define smp_mb()        mb()
>> -#define smp_rmb()       rmb()
>> -#define smp_wmb()       wmb()
>> -
>>  #define set_mb(var, value) do { xchg(&var, value); } while (0)
>>  #define set_wmb(var, value) do { var = value; wmb(); } while (0)
>>  
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/list.h
>> --- a/xen/include/xen/list.h
>> +++ b/xen/include/xen/list.h
>> @@ -102,7 +102,7 @@ static inline void __list_add_rcu(struct
>>  {
>>      new->next = next;
>>      new->prev = prev;
>> -    smp_wmb();
>> +    wmb();
>>      next->prev = new;
>>      prev->next = new;
>>  }
>> @@ -244,7 +244,7 @@ static inline void list_replace_rcu(stru
>>  {
>>      new->next = old->next;
>>      new->prev = old->prev;
>> -    smp_wmb();
>> +    wmb();
>>      new->next->prev = new;
>>      new->prev->next = new;
>>      old->prev = LIST_POISON2;
>> @@ -712,7 +712,7 @@ static inline void hlist_replace_rcu(str
>>  
>>      new->next = next;
>>      new->pprev = old->pprev;
>> -    smp_wmb();
>> +    wmb();
>>      if (next)
>>          new->next->pprev = &new->next;
>>      *new->pprev = new;
>> @@ -754,7 +754,7 @@ static inline void hlist_add_head_rcu(st
>>      struct hlist_node *first = h->first;
>>      n->next = first;
>>      n->pprev = &h->first;
>> -    smp_wmb();
>> +    wmb();
>>      if (first)
>>          first->pprev = &n->next;
>>      h->first = n;
>> @@ -804,7 +804,7 @@ static inline void hlist_add_before_rcu(
>>  {
>>      n->pprev = next->pprev;
>>      n->next = next;
>> -    smp_wmb();
>> +    wmb();
>>      next->pprev = &n->next;
>>      *(n->pprev) = n;
>>  }
>> @@ -832,7 +832,7 @@ static inline void hlist_add_after_rcu(s
>>  {
>>      n->next = prev->next;
>>      n->pprev = &prev->next;
>> -    smp_wmb();
>> +    wmb();
>>      prev->next = n;
>>      if (n->next)
>>          n->next->pprev = &n->next;
>> diff -r 101b0d7ebb00 -r 957b5ac44e32 xen/include/xen/rcupdate.h
>> --- a/xen/include/xen/rcupdate.h
>> +++ b/xen/include/xen/rcupdate.h
>> @@ -136,7 +136,7 @@ typedef struct _rcu_read_lock rcu_read_l
>>   * call documents which pointers will be dereferenced by RCU read-side
>>   * code.
>>   */
>> -#define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); })
>> +#define rcu_assign_pointer(p, v) ({ wmb(); (p) = (v); })
>>  
>>  void rcu_init(void);
>>  void rcu_check_callbacks(int cpu);
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:43:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTL0-00012V-2o; Thu, 09 Feb 2012 12:42:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTKx-00011V-Tu
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328791369!10795735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30629 invoked from network); 9 Feb 2012 12:42:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10597335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 12:42:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	12:42:49 +0000
Message-ID: <1328791368.6133.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 12:42:48 +0000
In-Reply-To: <2965835b0c0062a359ac.1328252415@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
	<2965835b0c0062a359ac.1328252415@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2 V3] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:00 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 2965835b0c0062a359ac04c715d7af52c6ba60ee
> # Parent  90e59c643c00c079996e13b75f89d1f0cd931a02
> libxl: Remus - xl remus command
> 
> xl remus acts as a frontend to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication is
>    supported. Support for disk checkpointing and network buffering will
>    be added in future.

>  * Replication is done over ssh connection currently (like live migration
>    with xl). Future versions will have an option to use simple tcp socket
>    based replication channel (for both Remus & live migration).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 90e59c643c00 -r 2965835b0c00 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
> +++ b/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
> @@ -348,6 +348,39 @@ Send <config> instead of config file fro
>  
>  =back
>  
> +=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> +
> +Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
> +between the two hosts.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-i> I<MS>
> +
> +Checkpoint domain memory every MS milliseconds (default 200ms).
> +
> +=item B<-b>
> +
> +Replicate memory checkpoints to /dev/null (blackhole).

Is blackhole replication just a debug thing? If so would be useful to
say so, if not then explaining when/why I might use this option would be
helpful.

> +        /*
> +         * TODO: change this to plain TCP socket based channel
> +         * instead of SSH. For both live-migration and Remus.
> +         */

IMHO comments like "TODO: split brain" are OK, because they highlight
fairly critical missing pieces, but in general I don't think we need to
track everything which might potentially happen to the code in the
future as TODO comments. Just add it to your own TODO list.

o/w looks good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:43:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTL0-00012V-2o; Thu, 09 Feb 2012 12:42:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTKx-00011V-Tu
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328791369!10795735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30629 invoked from network); 9 Feb 2012 12:42:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10597335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 12:42:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	12:42:49 +0000
Message-ID: <1328791368.6133.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 12:42:48 +0000
In-Reply-To: <2965835b0c0062a359ac.1328252415@athos.nss.cs.ubc.ca>
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
	<2965835b0c0062a359ac.1328252415@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2 V3] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-03 at 07:00 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328251593 28800
> # Node ID 2965835b0c0062a359ac04c715d7af52c6ba60ee
> # Parent  90e59c643c00c079996e13b75f89d1f0cd931a02
> libxl: Remus - xl remus command
> 
> xl remus acts as a frontend to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication is
>    supported. Support for disk checkpointing and network buffering will
>    be added in future.

>  * Replication is done over ssh connection currently (like live migration
>    with xl). Future versions will have an option to use simple tcp socket
>    based replication channel (for both Remus & live migration).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 90e59c643c00 -r 2965835b0c00 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
> +++ b/docs/man/xl.pod.1	Thu Feb 02 22:46:33 2012 -0800
> @@ -348,6 +348,39 @@ Send <config> instead of config file fro
>  
>  =back
>  
> +=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> +
> +Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
> +between the two hosts.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-i> I<MS>
> +
> +Checkpoint domain memory every MS milliseconds (default 200ms).
> +
> +=item B<-b>
> +
> +Replicate memory checkpoints to /dev/null (blackhole).

Is blackhole replication just a debug thing? If so would be useful to
say so, if not then explaining when/why I might use this option would be
helpful.

> +        /*
> +         * TODO: change this to plain TCP socket based channel
> +         * instead of SSH. For both live-migration and Remus.
> +         */

IMHO comments like "TODO: split brain" are OK, because they highlight
fairly critical missing pieces, but in general I don't think we need to
track everything which might potentially happen to the code in the
future as TODO comments. Just add it to your own TODO list.

o/w looks good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:45:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTMs-0001Hc-3U; Thu, 09 Feb 2012 12:44: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 1RvTMr-0001HQ-1W
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:44:53 +0000
Received: from [85.158.139.83:27797] by server-10.bemta-5.messagelabs.com id
	9E/E5-26909-4CFB33F4; Thu, 09 Feb 2012 12:44:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328791489!13776951!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26014 invoked from network); 9 Feb 2012 12:44:51 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:44:51 -0000
Received: by ghbf1 with SMTP id f1so22176904ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=W/URcle35F5ismHmlBk1HTo/H2xn36TJO5EFj4dhLuc=;
	b=I0gSB5CcK0mIeT2gj7ioanC935aT/9vPmfMACRKP/jDelG2PZBDpOhz26q0ZhbLtKE
	VikJYpD8f6FqYK0JMru15STy2GriTwm1yMb1YDcAzfdjdTgz2GZLZ8FE/jmG/TOL8zMP
	c8dTlsDGcnAsnMz9QB14zNSaYdkb0338lJVC0=
Received: by 10.50.36.230 with SMTP id t6mr2694919igj.5.1328791489188;
	Thu, 09 Feb 2012 04:44:49 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id nq10sm5095888igc.6.2012.02.09.04.44.45
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:44:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:44:42 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <CB58FFBA.2AC15%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AcznKJfl5IFSHvsXzUCHg/pXpqu18w==
In-Reply-To: <4F339F0A0200007800071D46@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com




On 09/02/2012 01:25, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
>> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:

>>> 
>>> Hmm, I would think these should specifically not be used in the
>>> io/ subtree - those aren't definitions of the interface to Xen, but
>>> ones shared between the respective backends and frontends.
>>> Each interface is (apart from its relying on the ring definitions)
>>> entirely self contained.
>>> 
>>> Jan
>> 
>> 
>> The versioning required allows a driver to declare, "I am compatible
>> with any source compatibility breaking changes up to version X of
>> the header file".  Declaring support for the latest version does
>> not require that a driver implement the new extensions.  Just one
>> constant needs to be renamed.  So I don't see this as really altering
>> the interface between front and backends (i.e. it is not a "blkif2")
> 
> Sure. But pulling in header updates should not require *any* other
> source changes, so long as __XEN_INTERFACE_VERSION__ isn't
> bumped.
> 
> My point about not using __XEN_INTERFACE_VERSION__ under io/
> is that these declare protocols that the hypervisor is completely
> unaware of, whereas the constant really is meant to control
> compatibility with hypervisor changes. In particular is this or any
> other change to the protocols under io/ entirely unrelated to the
> particular hypervisor version (and hence its interface revision).

Actually __XEN_INTERFACE_VERSION__ is simply versioning the *source-level
API* exposed by those headers. It's not really directly linked to versioning
of the hypervisor ABI, after all that has to ensure backward compatibility
whatever we do. Perhaps __XEN_INTERFACE_VERSION__ is simply badly named.

 -- Keir

> It's also unclear to me why simply giving new constants new names
> (instead of changing the meaning of existing ones) is such a big
> deal - the most strait forward solution doubtlessly is not having
> any conditionals in that header, and simply add new things with
> new, unambiguous names.
> 
> Jan
> 
>> If the xen-compat.h behavior is that you can safely import the
>> public headers so long as you do not bump __XEN_INTERFACE_VERSION__
>> until after you have audited and adjusted for the #ifdef guarded
>> changes in the header files, then that is exactly what is needed
>> in blkif.h.
>> 
>> --
>> Justin
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:45:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTMs-0001Hc-3U; Thu, 09 Feb 2012 12:44: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 1RvTMr-0001HQ-1W
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:44:53 +0000
Received: from [85.158.139.83:27797] by server-10.bemta-5.messagelabs.com id
	9E/E5-26909-4CFB33F4; Thu, 09 Feb 2012 12:44:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328791489!13776951!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26014 invoked from network); 9 Feb 2012 12:44:51 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 12:44:51 -0000
Received: by ghbf1 with SMTP id f1so22176904ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 04:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=W/URcle35F5ismHmlBk1HTo/H2xn36TJO5EFj4dhLuc=;
	b=I0gSB5CcK0mIeT2gj7ioanC935aT/9vPmfMACRKP/jDelG2PZBDpOhz26q0ZhbLtKE
	VikJYpD8f6FqYK0JMru15STy2GriTwm1yMb1YDcAzfdjdTgz2GZLZ8FE/jmG/TOL8zMP
	c8dTlsDGcnAsnMz9QB14zNSaYdkb0338lJVC0=
Received: by 10.50.36.230 with SMTP id t6mr2694919igj.5.1328791489188;
	Thu, 09 Feb 2012 04:44:49 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id nq10sm5095888igc.6.2012.02.09.04.44.45
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 04:44:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 04:44:42 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <CB58FFBA.2AC15%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
Thread-Index: AcznKJfl5IFSHvsXzUCHg/pXpqu18w==
In-Reply-To: <4F339F0A0200007800071D46@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com




On 09/02/2012 01:25, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
>> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:

>>> 
>>> Hmm, I would think these should specifically not be used in the
>>> io/ subtree - those aren't definitions of the interface to Xen, but
>>> ones shared between the respective backends and frontends.
>>> Each interface is (apart from its relying on the ring definitions)
>>> entirely self contained.
>>> 
>>> Jan
>> 
>> 
>> The versioning required allows a driver to declare, "I am compatible
>> with any source compatibility breaking changes up to version X of
>> the header file".  Declaring support for the latest version does
>> not require that a driver implement the new extensions.  Just one
>> constant needs to be renamed.  So I don't see this as really altering
>> the interface between front and backends (i.e. it is not a "blkif2")
> 
> Sure. But pulling in header updates should not require *any* other
> source changes, so long as __XEN_INTERFACE_VERSION__ isn't
> bumped.
> 
> My point about not using __XEN_INTERFACE_VERSION__ under io/
> is that these declare protocols that the hypervisor is completely
> unaware of, whereas the constant really is meant to control
> compatibility with hypervisor changes. In particular is this or any
> other change to the protocols under io/ entirely unrelated to the
> particular hypervisor version (and hence its interface revision).

Actually __XEN_INTERFACE_VERSION__ is simply versioning the *source-level
API* exposed by those headers. It's not really directly linked to versioning
of the hypervisor ABI, after all that has to ensure backward compatibility
whatever we do. Perhaps __XEN_INTERFACE_VERSION__ is simply badly named.

 -- Keir

> It's also unclear to me why simply giving new constants new names
> (instead of changing the meaning of existing ones) is such a big
> deal - the most strait forward solution doubtlessly is not having
> any conditionals in that header, and simply add new things with
> new, unambiguous names.
> 
> Jan
> 
>> If the xen-compat.h behavior is that you can safely import the
>> public headers so long as you do not bump __XEN_INTERFACE_VERSION__
>> until after you have audited and adjusted for the #ifdef guarded
>> changes in the header files, then that is exactly what is needed
>> in blkif.h.
>> 
>> --
>> Justin
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:46:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTOG-0001Qc-C8; Thu, 09 Feb 2012 12:46:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvTOE-0001Pz-R1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:46:19 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328791439!52042277!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30608 invoked from network); 9 Feb 2012 12:44:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 12:44:00 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19CkArR002227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:46:10 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19Ck85V029435; Thu, 9 Feb 2012 07:46:09 -0500
Message-ID: <4F33C00F.7040408@redhat.com>
Date: Thu, 09 Feb 2012 13:46:07 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com>
In-Reply-To: <20120209123725.GK18866@redhat.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060700010606030002030902"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------060700010606030002030902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Hi,

>> Incremental patch (just infrastructure, no acpi windup yet) attached.
>> Something like this?
>>
> We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
> alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
> prevent it.

Yea, already figured that after reading your rtc reply ...

One more incremental attached for review.

thanks,
  Gerd


--------------060700010606030002030902
Content-Type: text/plain;
 name="wakeup-reason-2.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="wakeup-reason-2.diff"

commit ef93688e70bf11313ec89c7e609fc142259dfd74
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Feb 9 13:44:37 2012 +0100

    enable/disable reasons

diff --git a/sysemu.h b/sysemu.h
index e7060aa..781bdaf 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -47,6 +47,7 @@ void qemu_system_reset_request(void);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
 void qemu_system_wakeup_request(WakeupReason reason);
+void qemu_system_wakeup_enable(WakeupReason reason, bool enabled);
 void qemu_register_wakeup_notifier(Notifier *notifier);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
diff --git a/vl.c b/vl.c
index 17d4b72..1feac41 100644
--- a/vl.c
+++ b/vl.c
@@ -1288,6 +1288,7 @@ static NotifierList suspend_notifiers =
     NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static NotifierList wakeup_notifiers =
     NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
+static uint32_t wakeup_reason_mask;
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1423,12 +1424,24 @@ void qemu_system_wakeup_request(WakeupReason reason)
     if (!is_suspended) {
         return;
     }
+    if (!(wakeup_reason_mask & (1 << reason))) {
+        return;
+    }
     notifier_list_notify(&wakeup_notifiers, &reason);
     reset_requested = 1;
     qemu_notify_event();
     is_suspended = false;
 }
 
+void qemu_system_wakeup_enable(WakeupReason reason, bool enabled)
+{
+    if (enabled) {
+        wakeup_reason_mask |= (1 << reason);
+    } else {
+        wakeup_reason_mask &= ~(1 << reason);
+    }
+}
+
 void qemu_register_wakeup_notifier(Notifier *notifier)
 {
     notifier_list_add(&wakeup_notifiers, notifier);

--------------060700010606030002030902
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060700010606030002030902--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:46:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTOG-0001Qc-C8; Thu, 09 Feb 2012 12:46:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvTOE-0001Pz-R1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:46:19 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328791439!52042277!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30608 invoked from network); 9 Feb 2012 12:44:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 12:44:00 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19CkArR002227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:46:10 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19Ck85V029435; Thu, 9 Feb 2012 07:46:09 -0500
Message-ID: <4F33C00F.7040408@redhat.com>
Date: Thu, 09 Feb 2012 13:46:07 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com>
In-Reply-To: <20120209123725.GK18866@redhat.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060700010606030002030902"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------060700010606030002030902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Hi,

>> Incremental patch (just infrastructure, no acpi windup yet) attached.
>> Something like this?
>>
> We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
> alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
> prevent it.

Yea, already figured that after reading your rtc reply ...

One more incremental attached for review.

thanks,
  Gerd


--------------060700010606030002030902
Content-Type: text/plain;
 name="wakeup-reason-2.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="wakeup-reason-2.diff"

commit ef93688e70bf11313ec89c7e609fc142259dfd74
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Feb 9 13:44:37 2012 +0100

    enable/disable reasons

diff --git a/sysemu.h b/sysemu.h
index e7060aa..781bdaf 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -47,6 +47,7 @@ void qemu_system_reset_request(void);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
 void qemu_system_wakeup_request(WakeupReason reason);
+void qemu_system_wakeup_enable(WakeupReason reason, bool enabled);
 void qemu_register_wakeup_notifier(Notifier *notifier);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
diff --git a/vl.c b/vl.c
index 17d4b72..1feac41 100644
--- a/vl.c
+++ b/vl.c
@@ -1288,6 +1288,7 @@ static NotifierList suspend_notifiers =
     NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static NotifierList wakeup_notifiers =
     NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
+static uint32_t wakeup_reason_mask;
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1423,12 +1424,24 @@ void qemu_system_wakeup_request(WakeupReason reason)
     if (!is_suspended) {
         return;
     }
+    if (!(wakeup_reason_mask & (1 << reason))) {
+        return;
+    }
     notifier_list_notify(&wakeup_notifiers, &reason);
     reset_requested = 1;
     qemu_notify_event();
     is_suspended = false;
 }
 
+void qemu_system_wakeup_enable(WakeupReason reason, bool enabled)
+{
+    if (enabled) {
+        wakeup_reason_mask |= (1 << reason);
+    } else {
+        wakeup_reason_mask &= ~(1 << reason);
+    }
+}
+
 void qemu_register_wakeup_notifier(Notifier *notifier)
 {
     notifier_list_add(&wakeup_notifiers, notifier);

--------------060700010606030002030902
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060700010606030002030902--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:47:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTPZ-0001YU-S0; Thu, 09 Feb 2012 12:47:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1RvTPY-0001Xu-3A
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:47:40 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328791653!12467439!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5633 invoked from network); 9 Feb 2012 12:47:33 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 12:47:33 -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 q19ClWw8012320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:47:32 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-22.ams2.redhat.com
	[10.36.112.22])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19ClUDN022625; Thu, 9 Feb 2012 07:47:31 -0500
Message-ID: <4F33C062.5080302@redhat.com>
Date: Thu, 09 Feb 2012 13:47:30 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<4F33AB4D.9070904@redhat.com> <20120209123157.GJ18866@redhat.com>
In-Reply-To: <20120209123157.GJ18866@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
	to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/2012 01:31 PM, Gleb Natapov wrote:
> Real HW may have other ways to notify BIOS that system was S3 suspended
> (special chipset register for instance).  I think we can write DSDT magic
> to write RTC for us, but I prefer to do it from inside QEMU.

Heh, I would prefer DSDT magic, but I wouldn't want to write it. ;)

> >  RTC memory is nvram, what happens if I remove the mains plug while
> >  the system is in S3?
>
> RTC is battery backed, but what do you expect will happen to main memory
> where all your data resides during S3 in this case anyway?

Ah, I confused the ACPI resume vector with the BIOS vector at 0040:0067. 
  No ACPI tables -> no resume vector, and S3 resume will fail.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:47:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTPZ-0001YU-S0; Thu, 09 Feb 2012 12:47:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1RvTPY-0001Xu-3A
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:47:40 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328791653!12467439!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5633 invoked from network); 9 Feb 2012 12:47:33 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 12:47:33 -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 q19ClWw8012320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:47:32 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-22.ams2.redhat.com
	[10.36.112.22])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19ClUDN022625; Thu, 9 Feb 2012 07:47:31 -0500
Message-ID: <4F33C062.5080302@redhat.com>
Date: Thu, 09 Feb 2012 13:47:30 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<4F33AB4D.9070904@redhat.com> <20120209123157.GJ18866@redhat.com>
In-Reply-To: <20120209123157.GJ18866@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
	to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/2012 01:31 PM, Gleb Natapov wrote:
> Real HW may have other ways to notify BIOS that system was S3 suspended
> (special chipset register for instance).  I think we can write DSDT magic
> to write RTC for us, but I prefer to do it from inside QEMU.

Heh, I would prefer DSDT magic, but I wouldn't want to write it. ;)

> >  RTC memory is nvram, what happens if I remove the mains plug while
> >  the system is in S3?
>
> RTC is battery backed, but what do you expect will happen to main memory
> where all your data resides during S3 in this case anyway?

Ah, I confused the ACPI resume vector with the BIOS vector at 0040:0067. 
  No ACPI tables -> no resume vector, and S3 resume will fail.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTVJ-00024P-Ld; Thu, 09 Feb 2012 12:53:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvTVH-00024B-Is
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:53:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328792008!4283523!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25284 invoked from network); 9 Feb 2012 12:53:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 12:53:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328792008; l=1639;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=8GsmVNX5/2rinPyqb7lQbegfr3k=;
	b=rxxtjqJCObffrZczwtI6EyL4GEStLSNOQ4kc4vnLbO4b0vUe7j1qIt3OmLudhWdxx+9
	tusB3s5vw1MDs1wGcZMsHxzyVHMQwVznB7zcg9BEyENoKk2znW3Pp8I79UV2tcwEvrPOR
	ud/e62Q6Vw5FcK0GUgXnPa9+LoJxpxt8b5A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (jimi mo50) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02506o19CqH3W
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 13:53:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3B91518638
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 13:53:17 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 14394647c54e40d82f4dbce2d6571a3d9b836719
Message-Id: <14394647c54e40d82f4d.1328791980@probook.site>
In-Reply-To: <patchbomb.1328791978@probook.site>
References: <patchbomb.1328791978@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 13:53:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] tools/libxl: use libxl wrapper for
	yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328791471 -3600
# Node ID 14394647c54e40d82f4dbce2d6571a3d9b836719
# Parent  85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
tools/libxl: use libxl wrapper for yajl_gen_alloc

To fix compile errors with libyajl2:
use libxl_yajl_gen_alloc()
use libxl_yajl_length
link xl with -lyajl for yajl_gen_string()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 85fcc1d0f072 -r 14394647c54e tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
diff -r 85fcc1d0f072 -r 14394647c54e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -297,13 +297,12 @@ static void printf_info(enum output_form
     if (output_format == OUTPUT_FORMAT_SXP)
         return printf_info_sexp(domid, d_config);
 
-    yajl_gen_config conf = { 1, "    " };
     const char *buf;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl_yajl_gen_alloc(NULL);
     if (!hand) {
         fprintf(stderr, "unable to allocate JSON generator\n");
         return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTVJ-00024P-Ld; Thu, 09 Feb 2012 12:53:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvTVH-00024B-Is
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:53:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328792008!4283523!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25284 invoked from network); 9 Feb 2012 12:53:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 12:53:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328792008; l=1639;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=8GsmVNX5/2rinPyqb7lQbegfr3k=;
	b=rxxtjqJCObffrZczwtI6EyL4GEStLSNOQ4kc4vnLbO4b0vUe7j1qIt3OmLudhWdxx+9
	tusB3s5vw1MDs1wGcZMsHxzyVHMQwVznB7zcg9BEyENoKk2znW3Pp8I79UV2tcwEvrPOR
	ud/e62Q6Vw5FcK0GUgXnPa9+LoJxpxt8b5A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (jimi mo50) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02506o19CqH3W
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 13:53:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3B91518638
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 13:53:17 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 14394647c54e40d82f4dbce2d6571a3d9b836719
Message-Id: <14394647c54e40d82f4d.1328791980@probook.site>
In-Reply-To: <patchbomb.1328791978@probook.site>
References: <patchbomb.1328791978@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 13:53:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] tools/libxl: use libxl wrapper for
	yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328791471 -3600
# Node ID 14394647c54e40d82f4dbce2d6571a3d9b836719
# Parent  85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
tools/libxl: use libxl wrapper for yajl_gen_alloc

To fix compile errors with libyajl2:
use libxl_yajl_gen_alloc()
use libxl_yajl_length
link xl with -lyajl for yajl_gen_string()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 85fcc1d0f072 -r 14394647c54e tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) -lyajl $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
diff -r 85fcc1d0f072 -r 14394647c54e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -297,13 +297,12 @@ static void printf_info(enum output_form
     if (output_format == OUTPUT_FORMAT_SXP)
         return printf_info_sexp(domid, d_config);
 
-    yajl_gen_config conf = { 1, "    " };
     const char *buf;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl_yajl_gen_alloc(NULL);
     if (!hand) {
         fprintf(stderr, "unable to allocate JSON generator\n");
         return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTVL-00024a-22; Thu, 09 Feb 2012 12:53:39 +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 1RvTVJ-00024D-ET
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:53:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328791956!53562984!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21222 invoked from network); 9 Feb 2012 12:52:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 12:52:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328792005; l=1875;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=CDRF1PYRGJEJS0Yu2trb9T4fJwE=;
	b=hGD035N/41d8Xa5z2KY20UOArnAkXoDJddJ1QyJCjkXv+bgslaSCfQIzziEE1tk77Q4
	Uuf4Y4wykdxm5h9E3ilkpdsFlf6q2a1Jju7raqRcGnPZg8K/ke+uVV4Ro80JZKcDHHvws
	koe9I5hg2YdbBIOd2f+xEQ72PZogfXWOI6g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (fruni mo46) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D04db1o19CAcPw
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 13:53:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0A3EC18637
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 13:53:17 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
Message-Id: <85fcc1d0f072c4f9d1e8.1328791979@probook.site>
In-Reply-To: <patchbomb.1328791978@probook.site>
References: <patchbomb.1328791978@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 13:52:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328791447 -3600
# Node ID 85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
tools/libxl: rename libxl__yajl_gen_alloc

libxl__yajl_gen_alloc() is called by generic code,
rename it to libx__yajl_gen_alloc().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -813,7 +813,7 @@ char *libxl__object_to_json(libxl_ctx *c
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = libxl__yajl_gen_alloc(NULL);
+    hand = libxl_yajl_gen_alloc(NULL);
     if (!hand)
         return NULL;
 
diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -40,7 +40,7 @@ static inline yajl_handle libxl__yajl_al
     return yajl_alloc(callbacks, allocFuncs, ctx);
 }
 
-static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
 {
     return yajl_gen_alloc(allocFuncs);
 }
@@ -62,7 +62,7 @@ static inline yajl_handle libxl__yajl_al
     return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
 }
 
-static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
 {
     yajl_gen_config conf = { 1, "    " };
     return yajl_gen_alloc(&conf, allocFuncs);
diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -461,7 +461,7 @@ static char *qmp_send_prepare(libxl__gc 
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
-    hand = libxl__yajl_gen_alloc(NULL);
+    hand = libxl_yajl_gen_alloc(NULL);
 
     if (!hand) {
         return NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTVL-00024a-22; Thu, 09 Feb 2012 12:53:39 +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 1RvTVJ-00024D-ET
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:53:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328791956!53562984!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21222 invoked from network); 9 Feb 2012 12:52:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 12:52:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328792005; l=1875;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=CDRF1PYRGJEJS0Yu2trb9T4fJwE=;
	b=hGD035N/41d8Xa5z2KY20UOArnAkXoDJddJ1QyJCjkXv+bgslaSCfQIzziEE1tk77Q4
	Uuf4Y4wykdxm5h9E3ilkpdsFlf6q2a1Jju7raqRcGnPZg8K/ke+uVV4Ro80JZKcDHHvws
	koe9I5hg2YdbBIOd2f+xEQ72PZogfXWOI6g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (fruni mo46) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D04db1o19CAcPw
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 13:53:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0A3EC18637
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 13:53:17 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
Message-Id: <85fcc1d0f072c4f9d1e8.1328791979@probook.site>
In-Reply-To: <patchbomb.1328791978@probook.site>
References: <patchbomb.1328791978@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 13:52:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328791447 -3600
# Node ID 85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
tools/libxl: rename libxl__yajl_gen_alloc

libxl__yajl_gen_alloc() is called by generic code,
rename it to libx__yajl_gen_alloc().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -813,7 +813,7 @@ char *libxl__object_to_json(libxl_ctx *c
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = libxl__yajl_gen_alloc(NULL);
+    hand = libxl_yajl_gen_alloc(NULL);
     if (!hand)
         return NULL;
 
diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -40,7 +40,7 @@ static inline yajl_handle libxl__yajl_al
     return yajl_alloc(callbacks, allocFuncs, ctx);
 }
 
-static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
 {
     return yajl_gen_alloc(allocFuncs);
 }
@@ -62,7 +62,7 @@ static inline yajl_handle libxl__yajl_al
     return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
 }
 
-static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
 {
     yajl_gen_config conf = { 1, "    " };
     return yajl_gen_alloc(&conf, allocFuncs);
diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -461,7 +461,7 @@ static char *qmp_send_prepare(libxl__gc 
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
-    hand = libxl__yajl_gen_alloc(NULL);
+    hand = libxl_yajl_gen_alloc(NULL);
 
     if (!hand) {
         return NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:53:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTVM-000253-FD; Thu, 09 Feb 2012 12:53:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvTVL-00024C-6C
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:53:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328792012!11169734!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29557 invoked from network); 9 Feb 2012 12:53:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 12:53:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328792011; l=329;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ijNBlEIRdW0TDxOjK0ktphgszYs=;
	b=s8rgmtBGSYxMwozRz0/ywse2j3TaFNnUWzHqC07hYcuR2ZVyeKkjkibeOxMt/ggtDAm
	5ii0QO5Jlq6Vf9WV+4GVTwFKA/111BaiJiMkTdlJodOoJmgK379PXSoypNKoqtnPQZDeP
	DaWhk70NZsgtDJsGc68/YkFr/1+xtfIU49A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo20) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z00259o19C5mkH
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 13:53:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CA6F918634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 13:53:16 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1328791978@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 13:52:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] rename libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Changes:
tools/libxl: rename libxl__yajl_gen_alloc
tools/libxl: use libxl wrapper for yajl_gen_alloc

 tools/libxl/Makefile     |    2 +-
 tools/libxl/libxl_json.c |    2 +-
 tools/libxl/libxl_json.h |    4 ++--
 tools/libxl/libxl_qmp.c  |    2 +-
 tools/libxl/xl_cmdimpl.c |    5 ++---
 5 files changed, 7 insertions(+), 8 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:53:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12: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.xensource.com>)
	id 1RvTVM-000253-FD; Thu, 09 Feb 2012 12:53:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvTVL-00024C-6C
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:53:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328792012!11169734!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29557 invoked from network); 9 Feb 2012 12:53:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 12:53:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328792011; l=329;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ijNBlEIRdW0TDxOjK0ktphgszYs=;
	b=s8rgmtBGSYxMwozRz0/ywse2j3TaFNnUWzHqC07hYcuR2ZVyeKkjkibeOxMt/ggtDAm
	5ii0QO5Jlq6Vf9WV+4GVTwFKA/111BaiJiMkTdlJodOoJmgK379PXSoypNKoqtnPQZDeP
	DaWhk70NZsgtDJsGc68/YkFr/1+xtfIU49A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo20) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z00259o19C5mkH
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 13:53:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CA6F918634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 13:53:16 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1328791978@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 13:52:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] rename libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Changes:
tools/libxl: rename libxl__yajl_gen_alloc
tools/libxl: use libxl wrapper for yajl_gen_alloc

 tools/libxl/Makefile     |    2 +-
 tools/libxl/libxl_json.c |    2 +-
 tools/libxl/libxl_json.h |    4 ++--
 tools/libxl/libxl_qmp.c  |    2 +-
 tools/libxl/xl_cmdimpl.c |    5 ++---
 5 files changed, 7 insertions(+), 8 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:54:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:54:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTVj-0002B3-4M; Thu, 09 Feb 2012 12:54:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTVh-0002Ac-GH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:54:01 +0000
Received: from [193.109.254.147:55979] by server-1.bemta-14.messagelabs.com id
	DC/D5-21323-8E1C33F4; Thu, 09 Feb 2012 12:54:00 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328791988!52059920!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1983 invoked from network); 9 Feb 2012 12:53:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 12:53:09 -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 q19Crwvl005160
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:53:58 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19CrvuE008384; Thu, 9 Feb 2012 07:53:57 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id E9692133EEF; Thu,  9 Feb 2012 14:53:56 +0200 (IST)
Date: Thu, 9 Feb 2012 14:53:56 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20120209125356.GL18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<4F33AB4D.9070904@redhat.com> <20120209123157.GJ18866@redhat.com>
	<4F33C062.5080302@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33C062.5080302@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:47:30PM +0100, Paolo Bonzini wrote:
> On 02/09/2012 01:31 PM, Gleb Natapov wrote:
> >Real HW may have other ways to notify BIOS that system was S3 suspended
> >(special chipset register for instance).  I think we can write DSDT magic
> >to write RTC for us, but I prefer to do it from inside QEMU.
> 
> Heh, I would prefer DSDT magic, but I wouldn't want to write it. ;)
> 
The only reason I prefer QEMU doing it is because I have S3 unit test
and writing AML interpreter for it would be too much. But on the second
thought the test can write to RTC by itself, so if you'll write DSDT
code I'll ack it :)

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 12:54:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 12:54:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTVj-0002B3-4M; Thu, 09 Feb 2012 12:54:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTVh-0002Ac-GH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 12:54:01 +0000
Received: from [193.109.254.147:55979] by server-1.bemta-14.messagelabs.com id
	DC/D5-21323-8E1C33F4; Thu, 09 Feb 2012 12:54:00 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328791988!52059920!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1983 invoked from network); 9 Feb 2012 12:53:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 12:53:09 -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 q19Crwvl005160
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 07:53:58 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19CrvuE008384; Thu, 9 Feb 2012 07:53:57 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id E9692133EEF; Thu,  9 Feb 2012 14:53:56 +0200 (IST)
Date: Thu, 9 Feb 2012 14:53:56 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20120209125356.GL18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-3-git-send-email-kraxel@redhat.com>
	<4F33AB4D.9070904@redhat.com> <20120209123157.GJ18866@redhat.com>
	<4F33C062.5080302@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33C062.5080302@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3
 to new infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:47:30PM +0100, Paolo Bonzini wrote:
> On 02/09/2012 01:31 PM, Gleb Natapov wrote:
> >Real HW may have other ways to notify BIOS that system was S3 suspended
> >(special chipset register for instance).  I think we can write DSDT magic
> >to write RTC for us, but I prefer to do it from inside QEMU.
> 
> Heh, I would prefer DSDT magic, but I wouldn't want to write it. ;)
> 
The only reason I prefer QEMU doing it is because I have S3 unit test
and writing AML interpreter for it would be too much. But on the second
thought the test can write to RTC by itself, so if you'll write DSDT
code I'll ack it :)

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTgZ-0002xC-EV; Thu, 09 Feb 2012 13:05:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTgY-0002wr-0N
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:05:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328792707!13986087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17194 invoked from network); 9 Feb 2012 13:05:07 -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;
	9 Feb 2012 13:05:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10597999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 13:05:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	13:05:07 +0000
Message-ID: <1328792705.6133.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 13:05:05 +0000
In-Reply-To: <85fcc1d0f072c4f9d1e8.1328791979@probook.site>
References: <patchbomb.1328791978@probook.site>
	<85fcc1d0f072c4f9d1e8.1328791979@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename
 libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 12:52 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1328791447 -3600
> # Node ID 85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> tools/libxl: rename libxl__yajl_gen_alloc
> 
> libxl__yajl_gen_alloc() is called by generic code,
> rename it to libx__yajl_gen_alloc().

Other than this typo both patches in this series look good to me,
thanks.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -813,7 +813,7 @@ char *libxl__object_to_json(libxl_ctx *c
>      yajl_gen_status s;
>      yajl_gen hand;
>  
> -    hand = libxl__yajl_gen_alloc(NULL);
> +    hand = libxl_yajl_gen_alloc(NULL);
>      if (!hand)
>          return NULL;
>  
> diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h
> +++ b/tools/libxl/libxl_json.h
> @@ -40,7 +40,7 @@ static inline yajl_handle libxl__yajl_al
>      return yajl_alloc(callbacks, allocFuncs, ctx);
>  }
>  
> -static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
> +static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
>  {
>      return yajl_gen_alloc(allocFuncs);
>  }
> @@ -62,7 +62,7 @@ static inline yajl_handle libxl__yajl_al
>      return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
>  }
>  
> -static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
> +static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
>  {
>      yajl_gen_config conf = { 1, "    " };
>      return yajl_gen_alloc(&conf, allocFuncs);
> diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_qmp.c
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -461,7 +461,7 @@ static char *qmp_send_prepare(libxl__gc 
>      yajl_gen hand;
>      callback_id_pair *elm = NULL;
>  
> -    hand = libxl__yajl_gen_alloc(NULL);
> +    hand = libxl_yajl_gen_alloc(NULL);
>  
>      if (!hand) {
>          return NULL;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvTgZ-0002xC-EV; Thu, 09 Feb 2012 13:05:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTgY-0002wr-0N
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:05:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328792707!13986087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17194 invoked from network); 9 Feb 2012 13:05:07 -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;
	9 Feb 2012 13:05:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10597999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 13:05:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	13:05:07 +0000
Message-ID: <1328792705.6133.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 13:05:05 +0000
In-Reply-To: <85fcc1d0f072c4f9d1e8.1328791979@probook.site>
References: <patchbomb.1328791978@probook.site>
	<85fcc1d0f072c4f9d1e8.1328791979@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename
 libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 12:52 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1328791447 -3600
> # Node ID 85fcc1d0f072c4f9d1e8f13b8bb2634228a16f6c
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> tools/libxl: rename libxl__yajl_gen_alloc
> 
> libxl__yajl_gen_alloc() is called by generic code,
> rename it to libx__yajl_gen_alloc().

Other than this typo both patches in this series look good to me,
thanks.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.c
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -813,7 +813,7 @@ char *libxl__object_to_json(libxl_ctx *c
>      yajl_gen_status s;
>      yajl_gen hand;
>  
> -    hand = libxl__yajl_gen_alloc(NULL);
> +    hand = libxl_yajl_gen_alloc(NULL);
>      if (!hand)
>          return NULL;
>  
> diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_json.h
> --- a/tools/libxl/libxl_json.h
> +++ b/tools/libxl/libxl_json.h
> @@ -40,7 +40,7 @@ static inline yajl_handle libxl__yajl_al
>      return yajl_alloc(callbacks, allocFuncs, ctx);
>  }
>  
> -static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
> +static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
>  {
>      return yajl_gen_alloc(allocFuncs);
>  }
> @@ -62,7 +62,7 @@ static inline yajl_handle libxl__yajl_al
>      return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
>  }
>  
> -static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
> +static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
>  {
>      yajl_gen_config conf = { 1, "    " };
>      return yajl_gen_alloc(&conf, allocFuncs);
> diff -r 8ba7ae0b070b -r 85fcc1d0f072 tools/libxl/libxl_qmp.c
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -461,7 +461,7 @@ static char *qmp_send_prepare(libxl__gc 
>      yajl_gen hand;
>      callback_id_pair *elm = NULL;
>  
> -    hand = libxl__yajl_gen_alloc(NULL);
> +    hand = libxl_yajl_gen_alloc(NULL);
>  
>      if (!hand) {
>          return NULL;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:09:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTjz-0003CX-HK; Thu, 09 Feb 2012 13:08:47 +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 1RvTjx-0003CO-B8
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:08:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328792874!62187357!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11075 invoked from network); 9 Feb 2012 13:07:55 -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;
	9 Feb 2012 13:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21789298"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:08:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	08:08:26 -0500
Message-ID: <4F33C549.7040800@citrix.com>
Date: Thu, 9 Feb 2012 13:08:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>	<4F32AFBF.7090201@citrix.com>	<4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
	<4F33B377.4080605@citrix.com>
In-Reply-To: <4F33B377.4080605@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------070207070007000006050103"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070207070007000006050103
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Version 3 attached.

It keeps the EOI register function, protected by an a check on the
IOAPIC version.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070207070007000006050103
Content-Type: text/x-patch; name="remove-itanium-ifdefs-in-x86-tree.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="remove-itanium-ifdefs-in-x86-tree.patch"

# HG changeset patch
# Parent a8f3abaaf3102ab493957d33e17ce59447915401
CONFIG: remove #ifdef __ia64__ from the x86 arch tree

__ia64__ really really should not be defined in the x86 arch subtree,
so remove it from xen/include/public/arch-x86/hvm/save.h

This in turn allows the removal of VIOAPIC_IS_IOSAPIC, as x86 does not
use streamlined {IO,L}APICs, allowing for the removal of more code
from the x86 tree.

Changes since v2:
 *  Leave the EOI register write protected by VIOAPIC_VERSION_ID >=
    0x20.  Currently, only version 0x11 is emulated, but leave this
    correct code in place in case a decision is make to emulate the
    newer version.

Changes since v1:
 *  Refresh patch following the decision not to try emulating a
    version 0x20 IOAPIC

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a8f3abaaf310 xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -59,12 +59,10 @@ static unsigned long vioapic_read_indire
                   | (VIOAPIC_VERSION_ID & 0xff));
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
     case VIOAPIC_REG_ARB_ID:
         result = ((vioapic->id & 0xf) << 24);
         break;
-#endif
 
     default:
     {
@@ -179,14 +177,12 @@ static void vioapic_write_indirect(
         /* Writes are ignored. */
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
         vioapic->id = (val >> 24) & 0xf;
         break;
 
     case VIOAPIC_REG_ARB_ID:
         break;
-#endif
 
     default:
     {
@@ -227,7 +223,7 @@ static int vioapic_write(
         vioapic_write_indirect(vioapic, length, val);
         break;
 
-#if VIOAPIC_IS_IOSAPIC
+#if VIOAPIC_VERSION_ID >= 0x20
     case VIOAPIC_REG_EOI:
         vioapic_update_EOI(v->domain, val);
         break;
diff -r a8f3abaaf310 xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -30,11 +30,7 @@
 #include <xen/smp.h>
 #include <public/hvm/save.h>
 
-#if !VIOAPIC_IS_IOSAPIC
 #define VIOAPIC_VERSION_ID 0x11 /* IOAPIC version */
-#else
-#define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
-#endif
 
 #define VIOAPIC_EDGE_TRIG  0
 #define VIOAPIC_LEVEL_TRIG 1
diff -r a8f3abaaf310 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -344,12 +344,7 @@ DECLARE_HVM_SAVE_TYPE(PIC, 3, struct hvm
  * IO-APIC
  */
 
-#ifdef __ia64__
-#define VIOAPIC_IS_IOSAPIC 1
-#define VIOAPIC_NUM_PINS  24
-#else
 #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
-#endif
 
 struct hvm_hw_vioapic {
     uint64_t base_address;
@@ -368,13 +363,8 @@ struct hvm_hw_vioapic {
             uint8_t trig_mode:1;
             uint8_t mask:1;
             uint8_t reserve:7;
-#if !VIOAPIC_IS_IOSAPIC
             uint8_t reserved[4];
             uint8_t dest_id;
-#else
-            uint8_t reserved[3];
-            uint16_t dest_id;
-#endif
         } fields;
     } redirtbl[VIOAPIC_NUM_PINS];
 };

--------------070207070007000006050103
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070207070007000006050103--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:09:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTjz-0003CX-HK; Thu, 09 Feb 2012 13:08:47 +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 1RvTjx-0003CO-B8
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:08:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328792874!62187357!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11075 invoked from network); 9 Feb 2012 13:07:55 -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;
	9 Feb 2012 13:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21789298"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:08:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	08:08:26 -0500
Message-ID: <4F33C549.7040800@citrix.com>
Date: Thu, 9 Feb 2012 13:08:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>	<4F32AFBF.7090201@citrix.com>	<4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
	<4F33B377.4080605@citrix.com>
In-Reply-To: <4F33B377.4080605@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------070207070007000006050103"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070207070007000006050103
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Version 3 attached.

It keeps the EOI register function, protected by an a check on the
IOAPIC version.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070207070007000006050103
Content-Type: text/x-patch; name="remove-itanium-ifdefs-in-x86-tree.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="remove-itanium-ifdefs-in-x86-tree.patch"

# HG changeset patch
# Parent a8f3abaaf3102ab493957d33e17ce59447915401
CONFIG: remove #ifdef __ia64__ from the x86 arch tree

__ia64__ really really should not be defined in the x86 arch subtree,
so remove it from xen/include/public/arch-x86/hvm/save.h

This in turn allows the removal of VIOAPIC_IS_IOSAPIC, as x86 does not
use streamlined {IO,L}APICs, allowing for the removal of more code
from the x86 tree.

Changes since v2:
 *  Leave the EOI register write protected by VIOAPIC_VERSION_ID >=
    0x20.  Currently, only version 0x11 is emulated, but leave this
    correct code in place in case a decision is make to emulate the
    newer version.

Changes since v1:
 *  Refresh patch following the decision not to try emulating a
    version 0x20 IOAPIC

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a8f3abaaf310 xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -59,12 +59,10 @@ static unsigned long vioapic_read_indire
                   | (VIOAPIC_VERSION_ID & 0xff));
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
     case VIOAPIC_REG_ARB_ID:
         result = ((vioapic->id & 0xf) << 24);
         break;
-#endif
 
     default:
     {
@@ -179,14 +177,12 @@ static void vioapic_write_indirect(
         /* Writes are ignored. */
         break;
 
-#if !VIOAPIC_IS_IOSAPIC
     case VIOAPIC_REG_APIC_ID:
         vioapic->id = (val >> 24) & 0xf;
         break;
 
     case VIOAPIC_REG_ARB_ID:
         break;
-#endif
 
     default:
     {
@@ -227,7 +223,7 @@ static int vioapic_write(
         vioapic_write_indirect(vioapic, length, val);
         break;
 
-#if VIOAPIC_IS_IOSAPIC
+#if VIOAPIC_VERSION_ID >= 0x20
     case VIOAPIC_REG_EOI:
         vioapic_update_EOI(v->domain, val);
         break;
diff -r a8f3abaaf310 xen/include/asm-x86/hvm/vioapic.h
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -30,11 +30,7 @@
 #include <xen/smp.h>
 #include <public/hvm/save.h>
 
-#if !VIOAPIC_IS_IOSAPIC
 #define VIOAPIC_VERSION_ID 0x11 /* IOAPIC version */
-#else
-#define VIOAPIC_VERSION_ID 0x21 /* IOSAPIC version */
-#endif
 
 #define VIOAPIC_EDGE_TRIG  0
 #define VIOAPIC_LEVEL_TRIG 1
diff -r a8f3abaaf310 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -344,12 +344,7 @@ DECLARE_HVM_SAVE_TYPE(PIC, 3, struct hvm
  * IO-APIC
  */
 
-#ifdef __ia64__
-#define VIOAPIC_IS_IOSAPIC 1
-#define VIOAPIC_NUM_PINS  24
-#else
 #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
-#endif
 
 struct hvm_hw_vioapic {
     uint64_t base_address;
@@ -368,13 +363,8 @@ struct hvm_hw_vioapic {
             uint8_t trig_mode:1;
             uint8_t mask:1;
             uint8_t reserve:7;
-#if !VIOAPIC_IS_IOSAPIC
             uint8_t reserved[4];
             uint8_t dest_id;
-#else
-            uint8_t reserved[3];
-            uint16_t dest_id;
-#endif
         } fields;
     } redirtbl[VIOAPIC_NUM_PINS];
 };

--------------070207070007000006050103
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070207070007000006050103--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:12:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTmo-0003Lw-Im; Thu, 09 Feb 2012 13:11:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTml-0003LZ-S3
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:11:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328793093!12686457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8098 invoked from network); 9 Feb 2012 13:11:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 13:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10598153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 13:11:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	13:11:33 +0000
Message-ID: <1328793091.6133.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kris <kris@theendless.org>
Date: Thu, 9 Feb 2012 13:11:31 +0000
In-Reply-To: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
 with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 19:44 +0000, Kris wrote:
> Hi,
> 
> I've been experiencing some issues with Xen-3.4.2-2.el5 (from gitco)
> on CentOS 5.4 when migrating nodes from one physical node to another.
> Each VM has 3 network interfaces (vifs).
> 
> When doing a live migration (xm migrate --live <params>) the network
> of the migrated VM seems to go in to a very odd state when it's done
> migrating. I've searched high and low for some documentation on what
> the state, evt-ch,tx-/rx-ring-ref fields mean with their particular
> integer values, but 1,-1,-1/-1 respectively seems to be indicative of
> something that has gone badly. A state of 4 seems to indicate that the
> interface is in a working state.
> 
> When doing a xm network-list VM on the node it is being migrated *to*
> - in this case all of them are broken, but sometimes it's just one or
> two interfaces are in this state.:
> Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
> 0   0  <REDACTED>   0     1      -1    -1   /-1      /local/domain/0/backend/vif/2/0  
> 1   0  <REDACTED>    1     1      -1    -1   /-1      /local/domain/0/backend/vif/2/1  
> 2   0  <REDACTED>    2     1      -1    -1   /-1      /local/domain/0/backend/vif/2/2
> 
> The result is that the network interfaces with the output above do not
> work.
> 
> Is there anything I can do to perhaps debug this better? Is there any
> documentation I'm missing out that would explain this stuff? Any
> troubleshooting help is appreciated. I've looked at the xend logs and
> there doesn't seem to be anything indicative of why this is occurring.

There's a good chance this is a guest kernel issue. What sort of guests
are they and what kernel version are they running? Is there anything in
the guest kernel logs or on the guest console?

The output of "xenstore-ls -fp" after this has happened would also be
potentially interesting.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:12:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTmo-0003Lw-Im; Thu, 09 Feb 2012 13:11:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvTml-0003LZ-S3
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:11:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328793093!12686457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8098 invoked from network); 9 Feb 2012 13:11:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 13:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10598153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 13:11:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	13:11:33 +0000
Message-ID: <1328793091.6133.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kris <kris@theendless.org>
Date: Thu, 9 Feb 2012 13:11:31 +0000
In-Reply-To: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
 with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 19:44 +0000, Kris wrote:
> Hi,
> 
> I've been experiencing some issues with Xen-3.4.2-2.el5 (from gitco)
> on CentOS 5.4 when migrating nodes from one physical node to another.
> Each VM has 3 network interfaces (vifs).
> 
> When doing a live migration (xm migrate --live <params>) the network
> of the migrated VM seems to go in to a very odd state when it's done
> migrating. I've searched high and low for some documentation on what
> the state, evt-ch,tx-/rx-ring-ref fields mean with their particular
> integer values, but 1,-1,-1/-1 respectively seems to be indicative of
> something that has gone badly. A state of 4 seems to indicate that the
> interface is in a working state.
> 
> When doing a xm network-list VM on the node it is being migrated *to*
> - in this case all of them are broken, but sometimes it's just one or
> two interfaces are in this state.:
> Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
> 0   0  <REDACTED>   0     1      -1    -1   /-1      /local/domain/0/backend/vif/2/0  
> 1   0  <REDACTED>    1     1      -1    -1   /-1      /local/domain/0/backend/vif/2/1  
> 2   0  <REDACTED>    2     1      -1    -1   /-1      /local/domain/0/backend/vif/2/2
> 
> The result is that the network interfaces with the output above do not
> work.
> 
> Is there anything I can do to perhaps debug this better? Is there any
> documentation I'm missing out that would explain this stuff? Any
> troubleshooting help is appreciated. I've looked at the xend logs and
> there doesn't seem to be anything indicative of why this is occurring.

There's a good chance this is a guest kernel issue. What sort of guests
are they and what kernel version are they running? Is there anything in
the guest kernel logs or on the guest console?

The output of "xenstore-ls -fp" after this has happened would also be
potentially interesting.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:15:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTq0-0003Xm-Gx; Thu, 09 Feb 2012 13:15:00 +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 1RvTpx-0003Xb-R1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:14:58 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328793244!52054607!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28704 invoked from network); 9 Feb 2012 13:14:05 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	VA3EHSOBE005.bigfish.com) (216.32.180.13)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 13:14:05 -0000
Received: from mail94-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 13:14:55 +0000
Received: from mail94-va3 (localhost [127.0.0.1])	by mail94-va3-R.bigfish.com
	(Postfix) with ESMTP id 19158400B6	for
	<xen-devel@lists.xensource.com>; Thu, 9 Feb 2012 13:14:55 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3
	(MessageSwitch) id 1328793292503980_22428;
	Thu,  9 Feb 2012 13:14:52 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.244])	by
	mail94-va3.bigfish.com (Postfix) with ESMTP id 75752320052	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 13:14:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 13:14:51 +0000
X-WSS-ID: 0LZ4NGN-02-A1Y-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 278D0C8271	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 07:14:47 -0600 (CST)
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, 9 Feb 2012 07:15:04 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 9 Feb 2012 07:14:48 -0600
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, 9 Feb 2012
	08:14:47 -0500
Message-ID: <4F33C6C6.30005@amd.com>
Date: Thu, 9 Feb 2012 14:14:46 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------050005060904090803000700"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] libxl: add missing includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050005060904090803000700
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


include <poll.h> for struct pollfd
include <time.h> for struct timeval
Fixes gcc complaints about implicit declaration.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------050005060904090803000700
Content-Type: text/plain; name="xen_tools_libxl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_libxl.diff"
Content-Description: xen_tools_libxl.diff

diff -r f27d5c83b05e tools/libxl/libxl_event.h
--- a/tools/libxl/libxl_event.h	Mon Feb 06 14:12:36 2012 +0100
+++ b/tools/libxl/libxl_event.h	Thu Feb 09 14:10:33 2012 +0100
@@ -17,6 +17,8 @@
 #define LIBXL_EVENT_H
 
 #include <libxl.h>
+#include <poll.h>
+#include <time.h>
 
 /*======================================================================*/
 

--------------050005060904090803000700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050005060904090803000700--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:15:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTq0-0003Xm-Gx; Thu, 09 Feb 2012 13:15:00 +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 1RvTpx-0003Xb-R1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:14:58 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328793244!52054607!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28704 invoked from network); 9 Feb 2012 13:14:05 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	VA3EHSOBE005.bigfish.com) (216.32.180.13)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Feb 2012 13:14:05 -0000
Received: from mail94-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 13:14:55 +0000
Received: from mail94-va3 (localhost [127.0.0.1])	by mail94-va3-R.bigfish.com
	(Postfix) with ESMTP id 19158400B6	for
	<xen-devel@lists.xensource.com>; Thu, 9 Feb 2012 13:14:55 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3
	(MessageSwitch) id 1328793292503980_22428;
	Thu,  9 Feb 2012 13:14:52 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.244])	by
	mail94-va3.bigfish.com (Postfix) with ESMTP id 75752320052	for
	<xen-devel@lists.xensource.com>; Thu,  9 Feb 2012 13:14:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server id
	14.1.225.23; Thu, 9 Feb 2012 13:14:51 +0000
X-WSS-ID: 0LZ4NGN-02-A1Y-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 278D0C8271	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 07:14:47 -0600 (CST)
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, 9 Feb 2012 07:15:04 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 9 Feb 2012 07:14:48 -0600
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, 9 Feb 2012
	08:14:47 -0500
Message-ID: <4F33C6C6.30005@amd.com>
Date: Thu, 9 Feb 2012 14:14:46 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------050005060904090803000700"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] libxl: add missing includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050005060904090803000700
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


include <poll.h> for struct pollfd
include <time.h> for struct timeval
Fixes gcc complaints about implicit declaration.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------050005060904090803000700
Content-Type: text/plain; name="xen_tools_libxl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_libxl.diff"
Content-Description: xen_tools_libxl.diff

diff -r f27d5c83b05e tools/libxl/libxl_event.h
--- a/tools/libxl/libxl_event.h	Mon Feb 06 14:12:36 2012 +0100
+++ b/tools/libxl/libxl_event.h	Thu Feb 09 14:10:33 2012 +0100
@@ -17,6 +17,8 @@
 #define LIBXL_EVENT_H
 
 #include <libxl.h>
+#include <poll.h>
+#include <time.h>
 
 /*======================================================================*/
 

--------------050005060904090803000700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050005060904090803000700--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:15:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTqa-0003bM-1J; Thu, 09 Feb 2012 13:15:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tknchris@gmail.com>) id 1RvTqX-0003b3-AP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:15:33 +0000
Received: from [85.158.143.35:29158] by server-2.bemta-4.messagelabs.com id
	02/EB-02822-4F6C33F4; Thu, 09 Feb 2012 13:15:32 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328793329!2137206!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20053 invoked from network); 9 Feb 2012 13:15:30 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 13:15:30 -0000
Received: by vbbfq11 with SMTP id fq11so3989165vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 05:15:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=cDl5JFpbe8qIhok1gBCDJOFsBK3ZlaQv71bqwH0+0Y0=;
	b=Vr+5muugfvwxuuWM0jGszYXbvVfmjXl68O5WlqbK2XdaCgT6Xi4zTDOWVjyw1tt3X0
	hsbQAqOUllBZbBVaOdLhGRC+fLKi3OUdzDKoY2sFx74PGLmRiEIpNkx7ogGHRraBVRiQ
	QwMoq4sKpD0nqpKJD6/iXSEvcigeJe18HT7bU=
MIME-Version: 1.0
Received: by 10.221.13.196 with SMTP id pn4mr764392vcb.74.1328793327568; Thu,
	09 Feb 2012 05:15:27 -0800 (PST)
Received: by 10.52.24.161 with HTTP; Thu, 9 Feb 2012 05:15:27 -0800 (PST)
In-Reply-To: <1328786234.6133.142.camel@zakaz.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
	<1328786234.6133.142.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 08:15:27 -0500
Message-ID: <CAKnNFz8rfUbKSMxJL89UVaSt_qy35hZ-M79a0_0PtvThjLdpyA@mail.gmail.com>
From: chris <tknchris@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8259114966149347872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8259114966149347872==
Content-Type: multipart/alternative; boundary=bcaec54fb9e04505f204b887ce5b

--bcaec54fb9e04505f204b887ce5b
Content-Type: text/plain; charset=ISO-8859-1

Any chance we can have an option to set a static VNC port? :) Also, does
upstream qemu still have the issue where if your vnc connection goes stale
you lose vnc because it only takes a single client connection?

On Thu, Feb 9, 2012 at 6:17 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-02-09 at 10:58 +0000, Anthony PERARD wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> >
> > > On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> > > > On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > > > > @@ -287,13 +285,16 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > >          }
> > > > > >
> > > > > >          if (strchr(listen, ':') != NULL)
> > > > > > -            flexarray_append(dm_args,
> > > > > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > > > > >          else
> > > > > > -            flexarray_append(dm_args,
> > > > > > -                    libxl__sprintf(gc, "%s:%d%s", listen,
> display,
> > > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen,
> display);
> > > > > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > > > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > > > > +        }
> > > > > > +        if (info->vncunused) {
> > > > > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> > > > >
> > > > > Not new, but I've been meaning to ask: what is to=99 for here? It
> seems
> > > > > a bit arbitrary and the default behaviour without it appears to be
> to
> > > > > keep looking for an available port which sounds like what we want.
> > > >
> > > > QEMU will search for an open port until it reach the vnc display
> port 99
> > > > (5999 TCP port).
> > > >
> > > > For the 99, I probably read this number somewhere. But after
> checking in
> > > > QEMU code, I do not see any limitation for this number. So we could
> > > > probably change this number for the port number max (-5900, default
> vnc
> > > > port).
> > >
> > > Can we not just omit it altogether and let qemu do its default thing?
> >
> > I did not find any default configuration for a VNC display in QEMU. We
> > have to provide every option we want. The minimum is hostname:display,
> > and QEMU will only tries to bind this address, or fails and quit. So to
> > "simulated" -vncunused, we have to provide a ",to=i" options to try
> > every single port between 5900 and 5900+i, and this option needs to be
> > last :(.
>
> I see, I didn't realise the upstream qemu was missing a "just find me a
> port" option.
>
> > I hope this respond to your question.
>
> Yes, thanks.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--bcaec54fb9e04505f204b887ce5b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Any chance we can have an option to set a static VNC port? :) Also, does up=
stream qemu still have the issue where if your vnc connection goes stale yo=
u lose vnc because it only takes a single client connection?<br><br><div cl=
ass=3D"gmail_quote">
On Thu, Feb 9, 2012 at 6:17 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div class=3D"h5">On Thu, 2012-02-09 at 10:58 +0000, Anthon=
y PERARD wrote:<br>
&gt; On Thu, 9 Feb 2012, Ian Campbell wrote:<br>
&gt;<br>
&gt; &gt; On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:<br>
&gt; &gt; &gt; On Wed, 8 Feb 2012, Ian Campbell wrote:<br>
&gt; &gt; &gt; &gt; &gt; @@ -287,13 +285,16 @@ static char ** libxl__build_=
device_model_args_new(libxl__gc *gc,<br>
&gt; &gt; &gt; &gt; &gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; =A0 =A0 =A0 =A0 =A0if (strchr(listen, &#39;:&#39;)=
 !=3D NULL)<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0flexarray_append(dm_args,=
<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sp=
rintf(gc, &quot;%s%s&quot;, listen,<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i=
nfo-&gt;vncunused ? &quot;,to=3D99&quot; : &quot;&quot;));<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s&quot;, listen);<br>
&gt; &gt; &gt; &gt; &gt; =A0 =A0 =A0 =A0 =A0else<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0flexarray_append(dm_args,=
<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sp=
rintf(gc, &quot;%s:%d%s&quot;, listen, display,<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i=
nfo-&gt;vncunused ? &quot;,to=3D99&quot; : &quot;&quot;));<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s:%d&quot;, listen, display);<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0if (info-&gt;vncpasswd &amp;&amp;=
 info-&gt;vncpasswd[0]) {<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s,password&quot;, vncarg);<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0if (info-&gt;vncunused) {<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s,to=3D99&quot;, vncarg);<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Not new, but I&#39;ve been meaning to ask: what is to=
=3D99 for here? It seems<br>
&gt; &gt; &gt; &gt; a bit arbitrary and the default behaviour without it ap=
pears to be to<br>
&gt; &gt; &gt; &gt; keep looking for an available port which sounds like wh=
at we want.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; QEMU will search for an open port until it reach the vnc dis=
play port 99<br>
&gt; &gt; &gt; (5999 TCP port).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; For the 99, I probably read this number somewhere. But after=
 checking in<br>
&gt; &gt; &gt; QEMU code, I do not see any limitation for this number. So w=
e could<br>
&gt; &gt; &gt; probably change this number for the port number max (-5900, =
default vnc<br>
&gt; &gt; &gt; port).<br>
&gt; &gt;<br>
&gt; &gt; Can we not just omit it altogether and let qemu do its default th=
ing?<br>
&gt;<br>
&gt; I did not find any default configuration for a VNC display in QEMU. We=
<br>
&gt; have to provide every option we want. The minimum is hostname:display,=
<br>
&gt; and QEMU will only tries to bind this address, or fails and quit. So t=
o<br>
&gt; &quot;simulated&quot; -vncunused, we have to provide a &quot;,to=3Di&q=
uot; options to try<br>
&gt; every single port between 5900 and 5900+i, and this option needs to be=
<br>
&gt; last :(.<br>
<br>
</div></div>I see, I didn&#39;t realise the upstream qemu was missing a &qu=
ot;just find me a<br>
port&quot; option.<br>
<div class=3D"im"><br>
&gt; I hope this respond to your question.<br>
<br>
</div>Yes, thanks.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--bcaec54fb9e04505f204b887ce5b--


--===============8259114966149347872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8259114966149347872==--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:15:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTqa-0003bM-1J; Thu, 09 Feb 2012 13:15:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tknchris@gmail.com>) id 1RvTqX-0003b3-AP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:15:33 +0000
Received: from [85.158.143.35:29158] by server-2.bemta-4.messagelabs.com id
	02/EB-02822-4F6C33F4; Thu, 09 Feb 2012 13:15:32 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328793329!2137206!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20053 invoked from network); 9 Feb 2012 13:15:30 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 13:15:30 -0000
Received: by vbbfq11 with SMTP id fq11so3989165vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 05:15:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=cDl5JFpbe8qIhok1gBCDJOFsBK3ZlaQv71bqwH0+0Y0=;
	b=Vr+5muugfvwxuuWM0jGszYXbvVfmjXl68O5WlqbK2XdaCgT6Xi4zTDOWVjyw1tt3X0
	hsbQAqOUllBZbBVaOdLhGRC+fLKi3OUdzDKoY2sFx74PGLmRiEIpNkx7ogGHRraBVRiQ
	QwMoq4sKpD0nqpKJD6/iXSEvcigeJe18HT7bU=
MIME-Version: 1.0
Received: by 10.221.13.196 with SMTP id pn4mr764392vcb.74.1328793327568; Thu,
	09 Feb 2012 05:15:27 -0800 (PST)
Received: by 10.52.24.161 with HTTP; Thu, 9 Feb 2012 05:15:27 -0800 (PST)
In-Reply-To: <1328786234.6133.142.camel@zakaz.uk.xensource.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
	<1328786234.6133.142.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 08:15:27 -0500
Message-ID: <CAKnNFz8rfUbKSMxJL89UVaSt_qy35hZ-M79a0_0PtvThjLdpyA@mail.gmail.com>
From: chris <tknchris@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8259114966149347872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8259114966149347872==
Content-Type: multipart/alternative; boundary=bcaec54fb9e04505f204b887ce5b

--bcaec54fb9e04505f204b887ce5b
Content-Type: text/plain; charset=ISO-8859-1

Any chance we can have an option to set a static VNC port? :) Also, does
upstream qemu still have the issue where if your vnc connection goes stale
you lose vnc because it only takes a single client connection?

On Thu, Feb 9, 2012 at 6:17 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-02-09 at 10:58 +0000, Anthony PERARD wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> >
> > > On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:
> > > > On Wed, 8 Feb 2012, Ian Campbell wrote:
> > > > > > @@ -287,13 +285,16 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
> > > > > >          }
> > > > > >
> > > > > >          if (strchr(listen, ':') != NULL)
> > > > > > -            flexarray_append(dm_args,
> > > > > > -                    libxl__sprintf(gc, "%s%s", listen,
> > > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > > +            vncarg = libxl__sprintf(gc, "%s", listen);
> > > > > >          else
> > > > > > -            flexarray_append(dm_args,
> > > > > > -                    libxl__sprintf(gc, "%s:%d%s", listen,
> display,
> > > > > > -                        info->vncunused ? ",to=99" : ""));
> > > > > > +            vncarg = libxl__sprintf(gc, "%s:%d", listen,
> display);
> > > > > > +        if (info->vncpasswd && info->vncpasswd[0]) {
> > > > > > +            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
> > > > > > +        }
> > > > > > +        if (info->vncunused) {
> > > > > > +            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
> > > > >
> > > > > Not new, but I've been meaning to ask: what is to=99 for here? It
> seems
> > > > > a bit arbitrary and the default behaviour without it appears to be
> to
> > > > > keep looking for an available port which sounds like what we want.
> > > >
> > > > QEMU will search for an open port until it reach the vnc display
> port 99
> > > > (5999 TCP port).
> > > >
> > > > For the 99, I probably read this number somewhere. But after
> checking in
> > > > QEMU code, I do not see any limitation for this number. So we could
> > > > probably change this number for the port number max (-5900, default
> vnc
> > > > port).
> > >
> > > Can we not just omit it altogether and let qemu do its default thing?
> >
> > I did not find any default configuration for a VNC display in QEMU. We
> > have to provide every option we want. The minimum is hostname:display,
> > and QEMU will only tries to bind this address, or fails and quit. So to
> > "simulated" -vncunused, we have to provide a ",to=i" options to try
> > every single port between 5900 and 5900+i, and this option needs to be
> > last :(.
>
> I see, I didn't realise the upstream qemu was missing a "just find me a
> port" option.
>
> > I hope this respond to your question.
>
> Yes, thanks.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--bcaec54fb9e04505f204b887ce5b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Any chance we can have an option to set a static VNC port? :) Also, does up=
stream qemu still have the issue where if your vnc connection goes stale yo=
u lose vnc because it only takes a single client connection?<br><br><div cl=
ass=3D"gmail_quote">
On Thu, Feb 9, 2012 at 6:17 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div class=3D"h5">On Thu, 2012-02-09 at 10:58 +0000, Anthon=
y PERARD wrote:<br>
&gt; On Thu, 9 Feb 2012, Ian Campbell wrote:<br>
&gt;<br>
&gt; &gt; On Wed, 2012-02-08 at 17:24 +0000, Anthony PERARD wrote:<br>
&gt; &gt; &gt; On Wed, 8 Feb 2012, Ian Campbell wrote:<br>
&gt; &gt; &gt; &gt; &gt; @@ -287,13 +285,16 @@ static char ** libxl__build_=
device_model_args_new(libxl__gc *gc,<br>
&gt; &gt; &gt; &gt; &gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; =A0 =A0 =A0 =A0 =A0if (strchr(listen, &#39;:&#39;)=
 !=3D NULL)<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0flexarray_append(dm_args,=
<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sp=
rintf(gc, &quot;%s%s&quot;, listen,<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i=
nfo-&gt;vncunused ? &quot;,to=3D99&quot; : &quot;&quot;));<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s&quot;, listen);<br>
&gt; &gt; &gt; &gt; &gt; =A0 =A0 =A0 =A0 =A0else<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0flexarray_append(dm_args,=
<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl__sp=
rintf(gc, &quot;%s:%d%s&quot;, listen, display,<br>
&gt; &gt; &gt; &gt; &gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i=
nfo-&gt;vncunused ? &quot;,to=3D99&quot; : &quot;&quot;));<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s:%d&quot;, listen, display);<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0if (info-&gt;vncpasswd &amp;&amp;=
 info-&gt;vncpasswd[0]) {<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s,password&quot;, vncarg);<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0}<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0if (info-&gt;vncunused) {<br>
&gt; &gt; &gt; &gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0vncarg =3D libxl__sprintf=
(gc, &quot;%s,to=3D99&quot;, vncarg);<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Not new, but I&#39;ve been meaning to ask: what is to=
=3D99 for here? It seems<br>
&gt; &gt; &gt; &gt; a bit arbitrary and the default behaviour without it ap=
pears to be to<br>
&gt; &gt; &gt; &gt; keep looking for an available port which sounds like wh=
at we want.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; QEMU will search for an open port until it reach the vnc dis=
play port 99<br>
&gt; &gt; &gt; (5999 TCP port).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; For the 99, I probably read this number somewhere. But after=
 checking in<br>
&gt; &gt; &gt; QEMU code, I do not see any limitation for this number. So w=
e could<br>
&gt; &gt; &gt; probably change this number for the port number max (-5900, =
default vnc<br>
&gt; &gt; &gt; port).<br>
&gt; &gt;<br>
&gt; &gt; Can we not just omit it altogether and let qemu do its default th=
ing?<br>
&gt;<br>
&gt; I did not find any default configuration for a VNC display in QEMU. We=
<br>
&gt; have to provide every option we want. The minimum is hostname:display,=
<br>
&gt; and QEMU will only tries to bind this address, or fails and quit. So t=
o<br>
&gt; &quot;simulated&quot; -vncunused, we have to provide a &quot;,to=3Di&q=
uot; options to try<br>
&gt; every single port between 5900 and 5900+i, and this option needs to be=
<br>
&gt; last :(.<br>
<br>
</div></div>I see, I didn&#39;t realise the upstream qemu was missing a &qu=
ot;just find me a<br>
port&quot; option.<br>
<div class=3D"im"><br>
&gt; I hope this respond to your question.<br>
<br>
</div>Yes, thanks.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--bcaec54fb9e04505f204b887ce5b--


--===============8259114966149347872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8259114966149347872==--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:17:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTsH-0003qA-Ae; Thu, 09 Feb 2012 13:17:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTsF-0003pq-Jw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:17:19 +0000
Received: from [85.158.139.83:43453] by server-10.bemta-5.messagelabs.com id
	50/89-26909-E57C33F4; Thu, 09 Feb 2012 13:17:18 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328793437!14353865!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15171 invoked from network); 9 Feb 2012 13:17:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 13:17:18 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19DHGxQ021812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 08:17:17 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19DHFi1005058; Thu, 9 Feb 2012 08:17:16 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 5870B133EEF; Thu,  9 Feb 2012 15:17:14 +0200 (IST)
Date: Thu, 9 Feb 2012 15:17:14 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209131714.GM18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33C00F.7040408@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:46:07PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >> Incremental patch (just infrastructure, no acpi windup yet) attached.
> >> Something like this?
> >>
> > We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
> > alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
> > prevent it.
> 
> Yea, already figured that after reading your rtc reply ...
> 
> One more incremental attached for review.
> 
We can start from that. But other devices can use STS/EN registers
from different GPEs, so they will have same "reason" bit, but in
different registers. Also I'd rather hide this logic in ACPI code
instead of having it in vl.c.

> thanks,
>   Gerd
> 

> commit ef93688e70bf11313ec89c7e609fc142259dfd74
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Thu Feb 9 13:44:37 2012 +0100
> 
>     enable/disable reasons
> 
> diff --git a/sysemu.h b/sysemu.h
> index e7060aa..781bdaf 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -47,6 +47,7 @@ void qemu_system_reset_request(void);
>  void qemu_system_suspend_request(void);
>  void qemu_register_suspend_notifier(Notifier *notifier);
>  void qemu_system_wakeup_request(WakeupReason reason);
> +void qemu_system_wakeup_enable(WakeupReason reason, bool enabled);
>  void qemu_register_wakeup_notifier(Notifier *notifier);
>  void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
> diff --git a/vl.c b/vl.c
> index 17d4b72..1feac41 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1288,6 +1288,7 @@ static NotifierList suspend_notifiers =
>      NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
>  static NotifierList wakeup_notifiers =
>      NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
> +static uint32_t wakeup_reason_mask;
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  
>  int qemu_shutdown_requested_get(void)
> @@ -1423,12 +1424,24 @@ void qemu_system_wakeup_request(WakeupReason reason)
>      if (!is_suspended) {
>          return;
>      }
> +    if (!(wakeup_reason_mask & (1 << reason))) {
> +        return;
> +    }
>      notifier_list_notify(&wakeup_notifiers, &reason);
>      reset_requested = 1;
>      qemu_notify_event();
>      is_suspended = false;
>  }
>  
> +void qemu_system_wakeup_enable(WakeupReason reason, bool enabled)
> +{
> +    if (enabled) {
> +        wakeup_reason_mask |= (1 << reason);
> +    } else {
> +        wakeup_reason_mask &= ~(1 << reason);
> +    }
> +}
> +
>  void qemu_register_wakeup_notifier(Notifier *notifier)
>  {
>      notifier_list_add(&wakeup_notifiers, notifier);


--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:17:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvTsH-0003qA-Ae; Thu, 09 Feb 2012 13:17:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvTsF-0003pq-Jw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:17:19 +0000
Received: from [85.158.139.83:43453] by server-10.bemta-5.messagelabs.com id
	50/89-26909-E57C33F4; Thu, 09 Feb 2012 13:17:18 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328793437!14353865!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15171 invoked from network); 9 Feb 2012 13:17:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 13:17:18 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19DHGxQ021812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 08:17:17 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19DHFi1005058; Thu, 9 Feb 2012 08:17:16 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 5870B133EEF; Thu,  9 Feb 2012 15:17:14 +0200 (IST)
Date: Thu, 9 Feb 2012 15:17:14 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209131714.GM18866@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33C00F.7040408@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 01:46:07PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >> Incremental patch (just infrastructure, no acpi windup yet) attached.
> >> Something like this?
> >>
> > We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
> > alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
> > prevent it.
> 
> Yea, already figured that after reading your rtc reply ...
> 
> One more incremental attached for review.
> 
We can start from that. But other devices can use STS/EN registers
from different GPEs, so they will have same "reason" bit, but in
different registers. Also I'd rather hide this logic in ACPI code
instead of having it in vl.c.

> thanks,
>   Gerd
> 

> commit ef93688e70bf11313ec89c7e609fc142259dfd74
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Thu Feb 9 13:44:37 2012 +0100
> 
>     enable/disable reasons
> 
> diff --git a/sysemu.h b/sysemu.h
> index e7060aa..781bdaf 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -47,6 +47,7 @@ void qemu_system_reset_request(void);
>  void qemu_system_suspend_request(void);
>  void qemu_register_suspend_notifier(Notifier *notifier);
>  void qemu_system_wakeup_request(WakeupReason reason);
> +void qemu_system_wakeup_enable(WakeupReason reason, bool enabled);
>  void qemu_register_wakeup_notifier(Notifier *notifier);
>  void qemu_system_shutdown_request(void);
>  void qemu_system_powerdown_request(void);
> diff --git a/vl.c b/vl.c
> index 17d4b72..1feac41 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1288,6 +1288,7 @@ static NotifierList suspend_notifiers =
>      NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
>  static NotifierList wakeup_notifiers =
>      NOTIFIER_LIST_INITIALIZER(wakeup_notifiers);
> +static uint32_t wakeup_reason_mask;
>  static RunState vmstop_requested = RUN_STATE_MAX;
>  
>  int qemu_shutdown_requested_get(void)
> @@ -1423,12 +1424,24 @@ void qemu_system_wakeup_request(WakeupReason reason)
>      if (!is_suspended) {
>          return;
>      }
> +    if (!(wakeup_reason_mask & (1 << reason))) {
> +        return;
> +    }
>      notifier_list_notify(&wakeup_notifiers, &reason);
>      reset_requested = 1;
>      qemu_notify_event();
>      is_suspended = false;
>  }
>  
> +void qemu_system_wakeup_enable(WakeupReason reason, bool enabled)
> +{
> +    if (enabled) {
> +        wakeup_reason_mask |= (1 << reason);
> +    } else {
> +        wakeup_reason_mask &= ~(1 << reason);
> +    }
> +}
> +
>  void qemu_register_wakeup_notifier(Notifier *notifier)
>  {
>      notifier_list_add(&wakeup_notifiers, notifier);


--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:30:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvU4G-0004Hh-Qm; Thu, 09 Feb 2012 13:29:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvU4F-0004HX-7A
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:29:43 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328794176!13616144!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10866 invoked from network); 9 Feb 2012 13:29:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 13:29:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19DTZ09025730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 08:29:35 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19DTXqJ008918; Thu, 9 Feb 2012 08:29:33 -0500
Message-ID: <4F33CA3C.50903@redhat.com>
Date: Thu, 09 Feb 2012 14:29:32 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com>
In-Reply-To: <20120209131714.GM18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

>>> We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
>>> alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
>>> prevent it.
>>
>> Yea, already figured that after reading your rtc reply ...
>>
>> One more incremental attached for review.
>>
> We can start from that. But other devices can use STS/EN registers
> from different GPEs, so they will have same "reason" bit, but in
> different registers.

Yes, we'll need more reason bits then, basically one per device.

> Also I'd rather hide this logic in ACPI code
> instead of having it in vl.c.

The acpi bits will be in acpi of course.

I'll try to get a complete v4 out of the door later today, that should
the direction I'm heading to more clear than these incremental bits.

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:30:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvU4G-0004Hh-Qm; Thu, 09 Feb 2012 13:29:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvU4F-0004HX-7A
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:29:43 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328794176!13616144!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10866 invoked from network); 9 Feb 2012 13:29:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 13:29:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19DTZ09025730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 08:29:35 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q19DTXqJ008918; Thu, 9 Feb 2012 08:29:33 -0500
Message-ID: <4F33CA3C.50903@redhat.com>
Date: Thu, 09 Feb 2012 14:29:32 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com>
In-Reply-To: <20120209131714.GM18866@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

>>> We need to give ACPI ability to prevent wakeup. So, for instance, if RTC
>>> alarm calls wakeup but ACPI detects that RTC_EN is cleared it can
>>> prevent it.
>>
>> Yea, already figured that after reading your rtc reply ...
>>
>> One more incremental attached for review.
>>
> We can start from that. But other devices can use STS/EN registers
> from different GPEs, so they will have same "reason" bit, but in
> different registers.

Yes, we'll need more reason bits then, basically one per device.

> Also I'd rather hide this logic in ACPI code
> instead of having it in vl.c.

The acpi bits will be in acpi of course.

I'll try to get a complete v4 out of the door later today, that should
the direction I'm heading to more clear than these incremental bits.

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:38:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUBx-0004WT-Ug; Thu, 09 Feb 2012 13:37:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RvUBw-0004WO-Gj
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:37:40 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328794652!12656453!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32638 invoked from network); 9 Feb 2012 13:37:34 -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;
	9 Feb 2012 13:37:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181051765"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:37:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 08:37:31 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q19DbRqC004782;
	Thu, 9 Feb 2012 05:37:28 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1328718979.4351.47.camel@Abyss>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
	<20120208142247.GW12984@reaktio.net>
	<CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
	<1328718979.4351.47.camel@Abyss>
Date: Thu, 9 Feb 2012 13:37:26 +0000
Message-ID: <1328794646.24055.15.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 16:36 +0000, Dario Faggioli wrote: 
> Yeah, it would be interesting to at least see it.

FYI, posted to xen-unstable an hour ago.

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:38:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13:38:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUBx-0004WT-Ug; Thu, 09 Feb 2012 13:37:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RvUBw-0004WO-Gj
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:37:40 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328794652!12656453!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32638 invoked from network); 9 Feb 2012 13:37:34 -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;
	9 Feb 2012 13:37:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181051765"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 08:37:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 08:37:31 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q19DbRqC004782;
	Thu, 9 Feb 2012 05:37:28 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1328718979.4351.47.camel@Abyss>
References: <20120207201231.GA23813@phenom.dumpdata.com>
	<CAFLBxZZrDGRqTZZuynOZcP1rV9goT9GVNAszkifsz5psesfMPw@mail.gmail.com>
	<20120208142247.GW12984@reaktio.net>
	<CAFLBxZaVF7K868GQ3SKLwKHWpEakmqrFd8Dvy_vGzOWmWUnxHQ@mail.gmail.com>
	<1328718979.4351.47.camel@Abyss>
Date: Thu, 9 Feb 2012 13:37:26 +0000
Message-ID: <1328794646.24055.15.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.thomas@oracle.com" <andrew.thomas@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>
Subject: Re: [Xen-devel] credit1 scheduler question.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-08 at 16:36 +0000, Dario Faggioli wrote: 
> Yeah, it would be interesting to at least see it.

FYI, posted to xen-unstable an hour ago.

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvUJe-0004ld-C1; Thu, 09 Feb 2012 13:45:38 +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 1RvUJb-0004lY-TE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:45:36 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328795077!56043745!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3620 invoked from network); 9 Feb 2012 13:44:39 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 13:44:39 -0000
Received: by obcuy19 with SMTP id uy19so7399893obc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 05:45:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=s6VnpK9XSszYfKTKWkVczjGLIWxLOxXZy7EKMGQ+zvQ=;
	b=hKjuLQLWyVQBjA9Owzl1su6/X2VlOeY+bly5i7yb2i1i0Dki3ACtNguVv4Omeoh+zg
	ObNoMJ6puliDlZC4GNXL7rFKzHkv0T3dw/z6Jk4ZgO28I6ZEQoB+LZuzJKK2CdwuDNcL
	s4EDsv6BxSjy2YGgny7lgaXK7MmpH7RhBy+t8=
Received: by 10.182.36.106 with SMTP id p10mr1670241obj.55.1328795133243; Thu,
	09 Feb 2012 05:45:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Thu, 9 Feb 2012 05:45:03 -0800 (PST)
In-Reply-To: <CAKnNFz8rfUbKSMxJL89UVaSt_qy35hZ-M79a0_0PtvThjLdpyA@mail.gmail.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
	<1328786234.6133.142.camel@zakaz.uk.xensource.com>
	<CAKnNFz8rfUbKSMxJL89UVaSt_qy35hZ-M79a0_0PtvThjLdpyA@mail.gmail.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 13:45:03 +0000
X-Google-Sender-Auth: lZc9V54P5VEAMYgtVQGwwNEXHlA
Message-ID: <CAJJyHjJRqEMDh74_WsbwnYqiOM-KX3akCbkpKd44yiYO7iAH7g@mail.gmail.com>
To: chris <tknchris@gmail.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 13:15, chris <tknchris@gmail.com> wrote:
> Any chance we can have an option to set a static VNC port? :)

It's already there ;-)
vncunused=0
vncdisplay=42

And QEMU will only try one port.

> Also, does
> upstream qemu still have the issue where if your vnc connection goes stale
> you lose vnc because it only takes a single client connection?

No, you can have several vnc client connected to QEMU.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 13: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.xensource.com>)
	id 1RvUJe-0004ld-C1; Thu, 09 Feb 2012 13:45:38 +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 1RvUJb-0004lY-TE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:45:36 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328795077!56043745!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3620 invoked from network); 9 Feb 2012 13:44:39 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 13:44:39 -0000
Received: by obcuy19 with SMTP id uy19so7399893obc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 05:45:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=s6VnpK9XSszYfKTKWkVczjGLIWxLOxXZy7EKMGQ+zvQ=;
	b=hKjuLQLWyVQBjA9Owzl1su6/X2VlOeY+bly5i7yb2i1i0Dki3ACtNguVv4Omeoh+zg
	ObNoMJ6puliDlZC4GNXL7rFKzHkv0T3dw/z6Jk4ZgO28I6ZEQoB+LZuzJKK2CdwuDNcL
	s4EDsv6BxSjy2YGgny7lgaXK7MmpH7RhBy+t8=
Received: by 10.182.36.106 with SMTP id p10mr1670241obj.55.1328795133243; Thu,
	09 Feb 2012 05:45:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Thu, 9 Feb 2012 05:45:03 -0800 (PST)
In-Reply-To: <CAKnNFz8rfUbKSMxJL89UVaSt_qy35hZ-M79a0_0PtvThjLdpyA@mail.gmail.com>
References: <1328701798-30808-1-git-send-email-anthony.perard@citrix.com>
	<1328719630.6133.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202081654020.4334@perard.uk.xensource.com>
	<1328768914.13189.70.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202091044420.4334@perard.uk.xensource.com>
	<1328786234.6133.142.camel@zakaz.uk.xensource.com>
	<CAKnNFz8rfUbKSMxJL89UVaSt_qy35hZ-M79a0_0PtvThjLdpyA@mail.gmail.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 13:45:03 +0000
X-Google-Sender-Auth: lZc9V54P5VEAMYgtVQGwwNEXHlA
Message-ID: <CAJJyHjJRqEMDh74_WsbwnYqiOM-KX3akCbkpKd44yiYO7iAH7g@mail.gmail.com>
To: chris <tknchris@gmail.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 13:15, chris <tknchris@gmail.com> wrote:
> Any chance we can have an option to set a static VNC port? :)

It's already there ;-)
vncunused=0
vncdisplay=42

And QEMU will only try one port.

> Also, does
> upstream qemu still have the issue where if your vnc connection goes stale
> you lose vnc because it only takes a single client connection?

No, you can have several vnc client connected to QEMU.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:57:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvUUt-00059N-8D; Thu, 09 Feb 2012 13:57:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvUUr-00059F-AT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:57:13 +0000
Received: from [85.158.139.83:41428] by server-7.bemta-5.messagelabs.com id
	DC/06-01252-8B0D33F4; Thu, 09 Feb 2012 13:57:12 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328795830!13789305!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9440 invoked from network); 9 Feb 2012 13:57:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Feb 2012 13:57:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvUUn-0002Fw-FD
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:57:09 -0800
Date: Thu, 9 Feb 2012 05:57:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328795829465-5469490.post@n5.nabble.com>
In-Reply-To: <1328784596.6133.141.camel@zakaz.uk.xensource.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
	<1328782971857-5469072.post@n5.nabble.com>
	<1328784596.6133.141.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks

I have rebuild xen to latest revistion, now:
Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b

--------------------------------
DomU Mint 11 (based on Natty - Ubuntu 11.04):
udev           167-0ubuntu3
linux-image-2.6.38-8-generic           2.6.38-8.42

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom' 

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_PATH=xen-vbd-51728
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64

/lib/udev/cdrom_id /dev/xvdb
Give no output

In attachment there are complete output of xenstore-ls and strace of
cdrom_id
http://xen.1045712.n5.nabble.com/file/n5469490/MINT11.txt MINT11.txt 
With strace I see how cdrom capability is at 0
--------------------------------

--------------------------------
DomU Mint 12 (based on Oneiric - Ubuntu 11.10):
udev           173-0ubuntu4.1
linux-image-3.0.0-13-generic           3.0.0-13.22 

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
S: cdrom
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51728
E: ID_PATH_TAG=xen-vbd-51728
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_PART_TABLE_TYPE=dos
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom
E: TAGS=:udev-acl:

/lib/udev/cdrom_id /dev/xvdb
ID_CDROM=1

In attachment there are complete output of xenstore-ls
http://xen.1045712.n5.nabble.com/file/n5469490/MINT12.txt MINT12.txt 
--------------------------------

Soon I'll try again next version of Ubuntu now in  alpha status (12.04 LTS)
and if the problem about cdrom is of distribution I will report it on
launchpad, I had already searched the forums and launchpad about it without
getting resolved.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5469490.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 13:57:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvUUt-00059N-8D; Thu, 09 Feb 2012 13:57:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvUUr-00059F-AT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 13:57:13 +0000
Received: from [85.158.139.83:41428] by server-7.bemta-5.messagelabs.com id
	DC/06-01252-8B0D33F4; Thu, 09 Feb 2012 13:57:12 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328795830!13789305!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9440 invoked from network); 9 Feb 2012 13:57:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Feb 2012 13:57:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvUUn-0002Fw-FD
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 05:57:09 -0800
Date: Thu, 9 Feb 2012 05:57:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328795829465-5469490.post@n5.nabble.com>
In-Reply-To: <1328784596.6133.141.camel@zakaz.uk.xensource.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
	<1328782971857-5469072.post@n5.nabble.com>
	<1328784596.6133.141.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks

I have rebuild xen to latest revistion, now:
Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b

--------------------------------
DomU Mint 11 (based on Natty - Ubuntu 11.04):
udev           167-0ubuntu3
linux-image-2.6.38-8-generic           2.6.38-8.42

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom' 

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_PATH=xen-vbd-51728
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64

/lib/udev/cdrom_id /dev/xvdb
Give no output

In attachment there are complete output of xenstore-ls and strace of
cdrom_id
http://xen.1045712.n5.nabble.com/file/n5469490/MINT11.txt MINT11.txt 
With strace I see how cdrom capability is at 0
--------------------------------

--------------------------------
DomU Mint 12 (based on Oneiric - Ubuntu 11.10):
udev           173-0ubuntu4.1
linux-image-3.0.0-13-generic           3.0.0-13.22 

With iso cdrom, on xl file configuration:
'/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'

udevadm info --query=all --path /block/xvdb
P: /devices/vbd-51728/block/xvdb
N: xvdb
S: disk/by-path/xen-vbd-51728
S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
S: cdrom
E: UDEV_LOG=3
E: DEVPATH=/devices/vbd-51728/block/xvdb
E: MAJOR=202
E: MINOR=16
E: DEVNAME=/dev/xvdb
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_CDROM=1
E: ID_PATH=xen-vbd-51728
E: ID_PATH_TAG=xen-vbd-51728
E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_PART_TABLE_TYPE=dos
E: GENERATED=1
E: UDISKS_PRESENTATION_NOPOLICY=1
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
/dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom
E: TAGS=:udev-acl:

/lib/udev/cdrom_id /dev/xvdb
ID_CDROM=1

In attachment there are complete output of xenstore-ls
http://xen.1045712.n5.nabble.com/file/n5469490/MINT12.txt MINT12.txt 
--------------------------------

Soon I'll try again next version of Ubuntu now in  alpha status (12.04 LTS)
and if the problem about cdrom is of distribution I will report it on
launchpad, I had already searched the forums and launchpad about it without
getting resolved.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5469490.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeZ-0005OC-9Y; Thu, 09 Feb 2012 14:07:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeW-0005Mz-Ro
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:13 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328796424!13614422!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29064 invoked from network); 9 Feb 2012 14:07:06 -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;
	9 Feb 2012 14:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21791153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:06 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XO004850;	Thu, 9 Feb 2012 06:07:05 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:37 +0000
Message-ID: <1328796398-2242-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 2/3] Provide dm_vnc() as a in libxl helper.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Just to use this function in more than one file.c.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_dm.c       |    8 ++++----
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5fec137..3422ec0 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -73,7 +73,7 @@ static const char *libxl__domain_bios(libxl__gc *gc,
     }
 }
 
-static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
+const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *guest_config)
 {
     const libxl_vnc_info *vnc = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -113,7 +113,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const int num_vifs = guest_config->num_vifs;
     const char *keymap = dm_keymap(guest_config);
@@ -328,7 +328,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const char *keymap = dm_keymap(guest_config);
     flexarray_t *dm_args;
@@ -889,7 +889,7 @@ int libxl__create_device_model(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 972c818..957eca2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -899,6 +899,8 @@ _hidden int libxl__wait_for_device_model(libxl__gc *gc,
 
 _hidden int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid);
 
+_hidden const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *g_cfg);
+
 _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
 
 #define LIBXL__LOG_DEBUG   XTL_DEBUG
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeZ-0005OC-9Y; Thu, 09 Feb 2012 14:07:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeW-0005Mz-Ro
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:13 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328796424!13614422!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29064 invoked from network); 9 Feb 2012 14:07:06 -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;
	9 Feb 2012 14:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21791153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:06 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XO004850;	Thu, 9 Feb 2012 06:07:05 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:37 +0000
Message-ID: <1328796398-2242-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 2/3] Provide dm_vnc() as a in libxl helper.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Just to use this function in more than one file.c.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_dm.c       |    8 ++++----
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5fec137..3422ec0 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -73,7 +73,7 @@ static const char *libxl__domain_bios(libxl__gc *gc,
     }
 }
 
-static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
+const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *guest_config)
 {
     const libxl_vnc_info *vnc = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -113,7 +113,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const int num_vifs = guest_config->num_vifs;
     const char *keymap = dm_keymap(guest_config);
@@ -328,7 +328,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const char *keymap = dm_keymap(guest_config);
     flexarray_t *dm_args;
@@ -889,7 +889,7 @@ int libxl__create_device_model(libxl__gc *gc,
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 972c818..957eca2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -899,6 +899,8 @@ _hidden int libxl__wait_for_device_model(libxl__gc *gc,
 
 _hidden int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid);
 
+_hidden const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *g_cfg);
+
 _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
 
 #define LIBXL__LOG_DEBUG   XTL_DEBUG
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeV-0005NH-75; Thu, 09 Feb 2012 14:07:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeT-0005N1-AV
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:09 +0000
Received: from [193.109.254.147:6867] by server-5.bemta-14.messagelabs.com id
	6E/DF-05697-C03D33F4; Thu, 09 Feb 2012 14:07:08 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328796375!52074901!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30524 invoked from network); 9 Feb 2012 14:06:17 -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;
	9 Feb 2012 14:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181056468"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:06 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XP004850;	Thu, 9 Feb 2012 06:07:06 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:38 +0000
Message-ID: <1328796398-2242-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 3/3] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch provide the code to set the VNC password to QEMU upstream through
VNC. The password is still stored in xenstore but will not be used by QEMU
upstream.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_dm.c       |   24 +++++++++++++++---------
 tools/libxl/libxl_internal.h |    3 ++-
 tools/libxl/libxl_qmp.c      |   30 +++++++++++++++++++++++++++++-
 4 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9148b26..deccf88 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -594,7 +594,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if (dm_starting) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-            libxl__qmp_initializations(gc, domid);
+            libxl__qmp_initializations(gc, domid, d_config);
         }
         ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3422ec0..434750a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -361,10 +361,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
+        char *vncarg = NULL;
 
-        if (vnc->passwd && vnc->passwd[0]) {
-            assert(!"missing code for supplying vnc password to qemu");
-        }
         flexarray_append(dm_args, "-vnc");
 
         if (vnc->display) {
@@ -377,13 +375,19 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         }
 
         if (strchr(listen, ':') != NULL)
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s%s", listen,
-                        vnc->findunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s", listen);
         else
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        vnc->findunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+        if (vnc->passwd && vnc->passwd[0]) {
+            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+        }
+        if (vnc->findunused) {
+            /* This option asks to QEMU to try this number of port before to
+             * give up.  So QEMU will try ports between $display and $display +
+             * 99.  This option needs to be the last one of the vnc options. */
+            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
+        }
+        flexarray_append(dm_args, vncarg);
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -964,6 +968,8 @@ int libxl__create_device_model(libxl__gc *gc,
     }
 
     if (vnc && vnc->passwd) {
+        /* This xenstore key will only be used by qemu-xen-traditionnal.
+         * The code to supply vncpasswd to qemu-xen is later. */
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 957eca2..bde91cd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1009,7 +1009,8 @@ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 
 /* this helper calls qmp_initialize, query_serial and qmp_close */
-_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
+                                       const libxl_domain_config *guest_config);
 
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ab34d1d..b80b027 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -877,8 +877,33 @@ out:
     return rc;
 }
 
-int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
+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;
+    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;
+
+    rc = qmp_synchronous_send(qmp, "change", &args,
+                              NULL, NULL, qmp->timeout);
+
+    flexarray_free(parameters);
+    return rc;
+}
+
+int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
+                               const libxl_domain_config *guest_config)
+{
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     libxl__qmp_handler *qmp = NULL;
     int ret = 0;
 
@@ -886,6 +911,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
     if (!qmp)
         return -1;
     ret = libxl__qmp_query_serial(qmp);
+    if (!ret && vnc && vnc->passwd) {
+        ret = qmp_change(gc, qmp, "vnc", "password", vnc->passwd);
+    }
     libxl__qmp_close(qmp);
     return ret;
 }
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeV-0005NH-75; Thu, 09 Feb 2012 14:07:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeT-0005N1-AV
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:09 +0000
Received: from [193.109.254.147:6867] by server-5.bemta-14.messagelabs.com id
	6E/DF-05697-C03D33F4; Thu, 09 Feb 2012 14:07:08 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328796375!52074901!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30524 invoked from network); 9 Feb 2012 14:06:17 -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;
	9 Feb 2012 14:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181056468"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:06 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XP004850;	Thu, 9 Feb 2012 06:07:06 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:38 +0000
Message-ID: <1328796398-2242-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 3/3] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch provide the code to set the VNC password to QEMU upstream through
VNC. The password is still stored in xenstore but will not be used by QEMU
upstream.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_dm.c       |   24 +++++++++++++++---------
 tools/libxl/libxl_internal.h |    3 ++-
 tools/libxl/libxl_qmp.c      |   30 +++++++++++++++++++++++++++++-
 4 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9148b26..deccf88 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -594,7 +594,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if (dm_starting) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-            libxl__qmp_initializations(gc, domid);
+            libxl__qmp_initializations(gc, domid, d_config);
         }
         ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3422ec0..434750a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -361,10 +361,8 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
+        char *vncarg = NULL;
 
-        if (vnc->passwd && vnc->passwd[0]) {
-            assert(!"missing code for supplying vnc password to qemu");
-        }
         flexarray_append(dm_args, "-vnc");
 
         if (vnc->display) {
@@ -377,13 +375,19 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         }
 
         if (strchr(listen, ':') != NULL)
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s%s", listen,
-                        vnc->findunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s", listen);
         else
-            flexarray_append(dm_args,
-                    libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        vnc->findunused ? ",to=99" : ""));
+            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+        if (vnc->passwd && vnc->passwd[0]) {
+            vncarg = libxl__sprintf(gc, "%s,password", vncarg);
+        }
+        if (vnc->findunused) {
+            /* This option asks to QEMU to try this number of port before to
+             * give up.  So QEMU will try ports between $display and $display +
+             * 99.  This option needs to be the last one of the vnc options. */
+            vncarg = libxl__sprintf(gc, "%s,to=99", vncarg);
+        }
+        flexarray_append(dm_args, vncarg);
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -964,6 +968,8 @@ int libxl__create_device_model(libxl__gc *gc,
     }
 
     if (vnc && vnc->passwd) {
+        /* This xenstore key will only be used by qemu-xen-traditionnal.
+         * The code to supply vncpasswd to qemu-xen is later. */
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 957eca2..bde91cd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1009,7 +1009,8 @@ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 
 /* this helper calls qmp_initialize, query_serial and qmp_close */
-_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
+                                       const libxl_domain_config *guest_config);
 
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ab34d1d..b80b027 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -877,8 +877,33 @@ out:
     return rc;
 }
 
-int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
+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;
+    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;
+
+    rc = qmp_synchronous_send(qmp, "change", &args,
+                              NULL, NULL, qmp->timeout);
+
+    flexarray_free(parameters);
+    return rc;
+}
+
+int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
+                               const libxl_domain_config *guest_config)
+{
+    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     libxl__qmp_handler *qmp = NULL;
     int ret = 0;
 
@@ -886,6 +911,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
     if (!qmp)
         return -1;
     ret = libxl__qmp_query_serial(qmp);
+    if (!ret && vnc && vnc->passwd) {
+        ret = qmp_change(gc, qmp, "vnc", "password", vnc->passwd);
+    }
     libxl__qmp_close(qmp);
     return ret;
 }
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeY-0005Nz-Dz; Thu, 09 Feb 2012 14:07:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeW-0005My-6Q
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:12 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328796424!13614422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29050 invoked from network); 9 Feb 2012 14:07:06 -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;
	9 Feb 2012 14:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21791152"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:04 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XM004850;	Thu, 9 Feb 2012 06:07:03 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:35 +0000
Message-ID: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 0/3] Set VNC password to QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD (3):
  libxl_qmp: Use GC instead of CTX as parameter for _initialize.
  Provide dm_vnc() as a in libxl helper.
  libxl: Set VNC password through QMP

 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_dm.c       |   32 ++++++++++++++----------
 tools/libxl/libxl_internal.h |    7 ++++-
 tools/libxl/libxl_qmp.c      |   55 ++++++++++++++++++++++++++++++-----------
 4 files changed, 65 insertions(+), 31 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeU-0005NA-G7; Thu, 09 Feb 2012 14:07:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeS-0005N0-GO
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:08 +0000
Received: from [193.109.254.147:19685] by server-3.bemta-14.messagelabs.com id
	32/51-04696-B03D33F4; Thu, 09 Feb 2012 14:07:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328796375!52074901!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30445 invoked from network); 9 Feb 2012 14:06:16 -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;
	9 Feb 2012 14:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181056463"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:05 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XN004850;	Thu, 9 Feb 2012 06:07:04 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:36 +0000
Message-ID: <1328796398-2242-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 1/3] libxl_qmp: Use GC instead of CTX as
	parameter for _initialize.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This make things a bit easier.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_qmp.c      |   27 ++++++++++++---------------
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..9148b26 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -594,7 +594,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if (dm_starting) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-            libxl__qmp_initializations(ctx, domid);
+            libxl__qmp_initializations(gc, domid);
         }
         ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 832cf35..972c818 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -991,7 +991,7 @@ typedef struct libxl__qmp_handler libxl__qmp_handler;
 /* Initialise and connect to the QMP socket.
  *   Return an handler or NULL if there is an error
  */
-_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx,
+_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
                                                   uint32_t domid);
 /* ask to QEMU the serial port information and store it in xenstore. */
 _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
@@ -1007,7 +1007,7 @@ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 
 /* this helper calls qmp_initialize, query_serial and qmp_close */
-_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid);
+_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid);
 
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e0642e3..ab34d1d 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -289,17 +289,17 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
  * Handler functions
  */
 
-static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid)
+static libxl__qmp_handler *qmp_init_handler(libxl__gc *gc, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
 
     qmp = calloc(1, sizeof (libxl__qmp_handler));
     if (qmp == NULL) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
                          "Failed to allocate qmp_handler");
         return NULL;
     }
-    qmp->ctx = ctx;
+    qmp->ctx = libxl__gc_owner(gc);
     qmp->domid = domid;
     qmp->timeout = 5;
 
@@ -621,20 +621,18 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
  * API
  */
 
-libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
+libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc, uint32_t domid)
 {
     int ret = 0;
     libxl__qmp_handler *qmp = NULL;
     char *qmp_socket;
-    GC_INIT(ctx);
 
-    qmp = qmp_init_handler(ctx, domid);
+    qmp = qmp_init_handler(gc, domid);
 
     qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
                                 libxl_run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
-        GC_FREE;
+        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Connection error");
         qmp_free_handler(qmp);
         return NULL;
     }
@@ -648,9 +646,8 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
         }
     }
 
-    GC_FREE;
     if (!qmp->connected) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
+        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
         libxl__qmp_close(qmp);
         return NULL;
     }
@@ -744,7 +741,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     char *hostaddr = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return -1;
 
@@ -789,7 +786,7 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id)
     libxl_key_value_list args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
@@ -850,7 +847,7 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     libxl_key_value_list args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
@@ -880,12 +877,12 @@ out:
     return rc;
 }
 
-int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
+int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
     int ret = 0;
 
-    qmp = libxl__qmp_initialize(ctx, domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return -1;
     ret = libxl__qmp_query_serial(qmp);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeY-0005Nz-Dz; Thu, 09 Feb 2012 14:07:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeW-0005My-6Q
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:12 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328796424!13614422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29050 invoked from network); 9 Feb 2012 14:07:06 -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;
	9 Feb 2012 14:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21791152"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:04 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XM004850;	Thu, 9 Feb 2012 06:07:03 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:35 +0000
Message-ID: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 0/3] Set VNC password to QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD (3):
  libxl_qmp: Use GC instead of CTX as parameter for _initialize.
  Provide dm_vnc() as a in libxl helper.
  libxl: Set VNC password through QMP

 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_dm.c       |   32 ++++++++++++++----------
 tools/libxl/libxl_internal.h |    7 ++++-
 tools/libxl/libxl_qmp.c      |   55 ++++++++++++++++++++++++++++++-----------
 4 files changed, 65 insertions(+), 31 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUeU-0005NA-G7; Thu, 09 Feb 2012 14:07:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RvUeS-0005N0-GO
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:07:08 +0000
Received: from [193.109.254.147:19685] by server-3.bemta-14.messagelabs.com id
	32/51-04696-B03D33F4; Thu, 09 Feb 2012 14:07:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328796375!52074901!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30445 invoked from network); 9 Feb 2012 14:06:16 -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;
	9 Feb 2012 14:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181056463"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:07:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:07:05 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q19E72XN004850;	Thu, 9 Feb 2012 06:07:04 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 9 Feb 2012 14:06:36 +0000
Message-ID: <1328796398-2242-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2 1/3] libxl_qmp: Use GC instead of CTX as
	parameter for _initialize.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This make things a bit easier.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_create.c   |    2 +-
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_qmp.c      |   27 ++++++++++++---------------
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..9148b26 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -594,7 +594,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
     if (dm_starting) {
         if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-            libxl__qmp_initializations(ctx, domid);
+            libxl__qmp_initializations(gc, domid);
         }
         ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 832cf35..972c818 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -991,7 +991,7 @@ typedef struct libxl__qmp_handler libxl__qmp_handler;
 /* Initialise and connect to the QMP socket.
  *   Return an handler or NULL if there is an error
  */
-_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx,
+_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
                                                   uint32_t domid);
 /* ask to QEMU the serial port information and store it in xenstore. */
 _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
@@ -1007,7 +1007,7 @@ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 
 /* this helper calls qmp_initialize, query_serial and qmp_close */
-_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid);
+_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid);
 
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e0642e3..ab34d1d 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -289,17 +289,17 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
  * Handler functions
  */
 
-static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid)
+static libxl__qmp_handler *qmp_init_handler(libxl__gc *gc, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
 
     qmp = calloc(1, sizeof (libxl__qmp_handler));
     if (qmp == NULL) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
                          "Failed to allocate qmp_handler");
         return NULL;
     }
-    qmp->ctx = ctx;
+    qmp->ctx = libxl__gc_owner(gc);
     qmp->domid = domid;
     qmp->timeout = 5;
 
@@ -621,20 +621,18 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
  * API
  */
 
-libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
+libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc, uint32_t domid)
 {
     int ret = 0;
     libxl__qmp_handler *qmp = NULL;
     char *qmp_socket;
-    GC_INIT(ctx);
 
-    qmp = qmp_init_handler(ctx, domid);
+    qmp = qmp_init_handler(gc, domid);
 
     qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
                                 libxl_run_dir_path(), domid);
     if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
-        GC_FREE;
+        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Connection error");
         qmp_free_handler(qmp);
         return NULL;
     }
@@ -648,9 +646,8 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
         }
     }
 
-    GC_FREE;
     if (!qmp->connected) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
+        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
         libxl__qmp_close(qmp);
         return NULL;
     }
@@ -744,7 +741,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     char *hostaddr = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return -1;
 
@@ -789,7 +786,7 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id)
     libxl_key_value_list args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
@@ -850,7 +847,7 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     libxl_key_value_list args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
@@ -880,12 +877,12 @@ out:
     return rc;
 }
 
-int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
+int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
     int ret = 0;
 
-    qmp = libxl__qmp_initialize(ctx, domid);
+    qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return -1;
     ret = libxl__qmp_query_serial(qmp);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:15:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvUlw-00066l-6Z; Thu, 09 Feb 2012 14:14: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 1RvUlu-00066Z-Ep
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:14:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328796866!52239083!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15864 invoked from network); 9 Feb 2012 14:14:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10599668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:14:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:14:49 +0000
Message-ID: <1328796887.6133.183.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 14:14:47 +0000
In-Reply-To: <1328796398-2242-2-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
	<1328796398-2242-2-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2 1/3] libxl_qmp: Use GC instead of CTX as
 parameter for _initialize.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 14:06 +0000, Anthony PERARD wrote:
> This make things a bit easier.

It's also the correct thing for a libxl__ function to take. BTW you can
use the CTX macro as a shorthand for the libxl__gc_owner stuff.

> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_create.c   |    2 +-
>  tools/libxl/libxl_internal.h |    4 ++--
>  tools/libxl/libxl_qmp.c      |   27 ++++++++++++---------------
>  3 files changed, 15 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f28d814..9148b26 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -594,7 +594,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>      if (dm_starting) {
>          if (d_config->b_info.device_model_version
>              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> -            libxl__qmp_initializations(ctx, domid);
> +            libxl__qmp_initializations(gc, domid);
>          }
>          ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
>          if (ret < 0) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 832cf35..972c818 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -991,7 +991,7 @@ typedef struct libxl__qmp_handler libxl__qmp_handler;
>  /* Initialise and connect to the QMP socket.
>   *   Return an handler or NULL if there is an error
>   */
> -_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx,
> +_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
>                                                    uint32_t domid);
>  /* ask to QEMU the serial port information and store it in xenstore. */
>  _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
> @@ -1007,7 +1007,7 @@ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
>  _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
>  
>  /* this helper calls qmp_initialize, query_serial and qmp_close */
> -_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid);
> +_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid);
>  
>  /* from libxl_json */
>  #include <yajl/yajl_gen.h>
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index e0642e3..ab34d1d 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -289,17 +289,17 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
>   * Handler functions
>   */
>  
> -static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid)
> +static libxl__qmp_handler *qmp_init_handler(libxl__gc *gc, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;
>  
>      qmp = calloc(1, sizeof (libxl__qmp_handler));
>      if (qmp == NULL) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
>                           "Failed to allocate qmp_handler");
>          return NULL;
>      }
> -    qmp->ctx = ctx;
> +    qmp->ctx = libxl__gc_owner(gc);
>      qmp->domid = domid;
>      qmp->timeout = 5;
>  
> @@ -621,20 +621,18 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>   * API
>   */
>  
> -libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
> +libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc, uint32_t domid)
>  {
>      int ret = 0;
>      libxl__qmp_handler *qmp = NULL;
>      char *qmp_socket;
> -    GC_INIT(ctx);
>  
> -    qmp = qmp_init_handler(ctx, domid);
> +    qmp = qmp_init_handler(gc, domid);
>  
>      qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
>                                  libxl_run_dir_path(), domid);
>      if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
> -        GC_FREE;
> +        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Connection error");
>          qmp_free_handler(qmp);
>          return NULL;
>      }
> @@ -648,9 +646,8 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
>          }
>      }
>  
> -    GC_FREE;
>      if (!qmp->connected) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
> +        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
>          libxl__qmp_close(qmp);
>          return NULL;
>      }
> @@ -744,7 +741,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
>      char *hostaddr = NULL;
>      int rc = 0;
>  
> -    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return -1;
>  
> @@ -789,7 +786,7 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id)
>      libxl_key_value_list args = NULL;
>      int rc = 0;
>  
> -    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return ERROR_FAIL;
>  
> @@ -850,7 +847,7 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
>      libxl_key_value_list args = NULL;
>      int rc = 0;
>  
> -    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return ERROR_FAIL;
>  
> @@ -880,12 +877,12 @@ out:
>      return rc;
>  }
>  
> -int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
> +int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;
>      int ret = 0;
>  
> -    qmp = libxl__qmp_initialize(ctx, domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return -1;
>      ret = libxl__qmp_query_serial(qmp);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:15:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvUlw-00066l-6Z; Thu, 09 Feb 2012 14:14: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 1RvUlu-00066Z-Ep
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:14:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328796866!52239083!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15864 invoked from network); 9 Feb 2012 14:14:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10599668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:14:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:14:49 +0000
Message-ID: <1328796887.6133.183.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 14:14:47 +0000
In-Reply-To: <1328796398-2242-2-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
	<1328796398-2242-2-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2 1/3] libxl_qmp: Use GC instead of CTX as
 parameter for _initialize.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 14:06 +0000, Anthony PERARD wrote:
> This make things a bit easier.

It's also the correct thing for a libxl__ function to take. BTW you can
use the CTX macro as a shorthand for the libxl__gc_owner stuff.

> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_create.c   |    2 +-
>  tools/libxl/libxl_internal.h |    4 ++--
>  tools/libxl/libxl_qmp.c      |   27 ++++++++++++---------------
>  3 files changed, 15 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f28d814..9148b26 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -594,7 +594,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>      if (dm_starting) {
>          if (d_config->b_info.device_model_version
>              == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> -            libxl__qmp_initializations(ctx, domid);
> +            libxl__qmp_initializations(gc, domid);
>          }
>          ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
>          if (ret < 0) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 832cf35..972c818 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -991,7 +991,7 @@ typedef struct libxl__qmp_handler libxl__qmp_handler;
>  /* Initialise and connect to the QMP socket.
>   *   Return an handler or NULL if there is an error
>   */
> -_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx,
> +_hidden libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc,
>                                                    uint32_t domid);
>  /* ask to QEMU the serial port information and store it in xenstore. */
>  _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
> @@ -1007,7 +1007,7 @@ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
>  _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
>  
>  /* this helper calls qmp_initialize, query_serial and qmp_close */
> -_hidden int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid);
> +_hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid);
>  
>  /* from libxl_json */
>  #include <yajl/yajl_gen.h>
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index e0642e3..ab34d1d 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -289,17 +289,17 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
>   * Handler functions
>   */
>  
> -static libxl__qmp_handler *qmp_init_handler(libxl_ctx *ctx, uint32_t domid)
> +static libxl__qmp_handler *qmp_init_handler(libxl__gc *gc, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;
>  
>      qmp = calloc(1, sizeof (libxl__qmp_handler));
>      if (qmp == NULL) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
>                           "Failed to allocate qmp_handler");
>          return NULL;
>      }
> -    qmp->ctx = ctx;
> +    qmp->ctx = libxl__gc_owner(gc);
>      qmp->domid = domid;
>      qmp->timeout = 5;
>  
> @@ -621,20 +621,18 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>   * API
>   */
>  
> -libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
> +libxl__qmp_handler *libxl__qmp_initialize(libxl__gc *gc, uint32_t domid)
>  {
>      int ret = 0;
>      libxl__qmp_handler *qmp = NULL;
>      char *qmp_socket;
> -    GC_INIT(ctx);
>  
> -    qmp = qmp_init_handler(ctx, domid);
> +    qmp = qmp_init_handler(gc, domid);
>  
>      qmp_socket = libxl__sprintf(gc, "%s/qmp-libxl-%d",
>                                  libxl_run_dir_path(), domid);
>      if ((ret = qmp_open(qmp, qmp_socket, QMP_SOCKET_CONNECT_TIMEOUT)) < 0) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Connection error");
> -        GC_FREE;
> +        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Connection error");
>          qmp_free_handler(qmp);
>          return NULL;
>      }
> @@ -648,9 +646,8 @@ libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
>          }
>      }
>  
> -    GC_FREE;
>      if (!qmp->connected) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
> +        LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Failed to connect to QMP");
>          libxl__qmp_close(qmp);
>          return NULL;
>      }
> @@ -744,7 +741,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
>      char *hostaddr = NULL;
>      int rc = 0;
>  
> -    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return -1;
>  
> @@ -789,7 +786,7 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id)
>      libxl_key_value_list args = NULL;
>      int rc = 0;
>  
> -    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return ERROR_FAIL;
>  
> @@ -850,7 +847,7 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
>      libxl_key_value_list args = NULL;
>      int rc = 0;
>  
> -    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return ERROR_FAIL;
>  
> @@ -880,12 +877,12 @@ out:
>      return rc;
>  }
>  
> -int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
> +int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid)
>  {
>      libxl__qmp_handler *qmp = NULL;
>      int ret = 0;
>  
> -    qmp = libxl__qmp_initialize(ctx, domid);
> +    qmp = libxl__qmp_initialize(gc, domid);
>      if (!qmp)
>          return -1;
>      ret = libxl__qmp_query_serial(qmp);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvUmq-0006C0-4k; Thu, 09 Feb 2012 14:15:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvUmn-0006BP-SP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:15:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328796939!12695712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9620 invoked from network); 9 Feb 2012 14:15:39 -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;
	9 Feb 2012 14:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10599692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:15:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:15:38 +0000
Message-ID: <1328796937.6133.184.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 14:15:37 +0000
In-Reply-To: <1328796398-2242-3-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
	<1328796398-2242-3-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2 2/3] Provide dm_vnc() as a in libxl
 helper.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 14:06 +0000, Anthony PERARD wrote:
> Just to use this function in more than one file.c.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dm.c       |    8 ++++----
>  tools/libxl/libxl_internal.h |    2 ++
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 5fec137..3422ec0 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -73,7 +73,7 @@ static const char *libxl__domain_bios(libxl__gc *gc,
>      }
>  }
>  
> -static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
> +const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *guest_config)
>  {
>      const libxl_vnc_info *vnc = NULL;
>      if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
> @@ -113,7 +113,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>      const libxl_domain_create_info *c_info = &guest_config->c_info;
>      const libxl_domain_build_info *b_info = &guest_config->b_info;
>      const libxl_device_nic *vifs = guest_config->vifs;
> -    const libxl_vnc_info *vnc = dm_vnc(guest_config);
> +    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
>      const libxl_sdl_info *sdl = dm_sdl(guest_config);
>      const int num_vifs = guest_config->num_vifs;
>      const char *keymap = dm_keymap(guest_config);
> @@ -328,7 +328,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      const libxl_device_nic *vifs = guest_config->vifs;
>      const int num_disks = guest_config->num_disks;
>      const int num_vifs = guest_config->num_vifs;
> -    const libxl_vnc_info *vnc = dm_vnc(guest_config);
> +    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
>      const libxl_sdl_info *sdl = dm_sdl(guest_config);
>      const char *keymap = dm_keymap(guest_config);
>      flexarray_t *dm_args;
> @@ -889,7 +889,7 @@ int libxl__create_device_model(libxl__gc *gc,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      const libxl_domain_create_info *c_info = &guest_config->c_info;
>      const libxl_domain_build_info *b_info = &guest_config->b_info;
> -    const libxl_vnc_info *vnc = dm_vnc(guest_config);
> +    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
>      char *path, *logfile;
>      int logfile_w, null;
>      int rc;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 972c818..957eca2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -899,6 +899,8 @@ _hidden int libxl__wait_for_device_model(libxl__gc *gc,
>  
>  _hidden int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid);
>  
> +_hidden const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *g_cfg);
> +
>  _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
>  
>  #define LIBXL__LOG_DEBUG   XTL_DEBUG



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvUmq-0006C0-4k; Thu, 09 Feb 2012 14:15:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvUmn-0006BP-SP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:15:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328796939!12695712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9620 invoked from network); 9 Feb 2012 14:15:39 -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;
	9 Feb 2012 14:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10599692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:15:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:15:38 +0000
Message-ID: <1328796937.6133.184.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 14:15:37 +0000
In-Reply-To: <1328796398-2242-3-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
	<1328796398-2242-3-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2 2/3] Provide dm_vnc() as a in libxl
 helper.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 14:06 +0000, Anthony PERARD wrote:
> Just to use this function in more than one file.c.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dm.c       |    8 ++++----
>  tools/libxl/libxl_internal.h |    2 ++
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 5fec137..3422ec0 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -73,7 +73,7 @@ static const char *libxl__domain_bios(libxl__gc *gc,
>      }
>  }
>  
> -static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
> +const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *guest_config)
>  {
>      const libxl_vnc_info *vnc = NULL;
>      if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
> @@ -113,7 +113,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>      const libxl_domain_create_info *c_info = &guest_config->c_info;
>      const libxl_domain_build_info *b_info = &guest_config->b_info;
>      const libxl_device_nic *vifs = guest_config->vifs;
> -    const libxl_vnc_info *vnc = dm_vnc(guest_config);
> +    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
>      const libxl_sdl_info *sdl = dm_sdl(guest_config);
>      const int num_vifs = guest_config->num_vifs;
>      const char *keymap = dm_keymap(guest_config);
> @@ -328,7 +328,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>      const libxl_device_nic *vifs = guest_config->vifs;
>      const int num_disks = guest_config->num_disks;
>      const int num_vifs = guest_config->num_vifs;
> -    const libxl_vnc_info *vnc = dm_vnc(guest_config);
> +    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
>      const libxl_sdl_info *sdl = dm_sdl(guest_config);
>      const char *keymap = dm_keymap(guest_config);
>      flexarray_t *dm_args;
> @@ -889,7 +889,7 @@ int libxl__create_device_model(libxl__gc *gc,
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      const libxl_domain_create_info *c_info = &guest_config->c_info;
>      const libxl_domain_build_info *b_info = &guest_config->b_info;
> -    const libxl_vnc_info *vnc = dm_vnc(guest_config);
> +    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
>      char *path, *logfile;
>      int logfile_w, null;
>      int rc;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 972c818..957eca2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -899,6 +899,8 @@ _hidden int libxl__wait_for_device_model(libxl__gc *gc,
>  
>  _hidden int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid);
>  
> +_hidden const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *g_cfg);
> +
>  _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
>  
>  #define LIBXL__LOG_DEBUG   XTL_DEBUG



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:17:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUnq-0006LS-92; Thu, 09 Feb 2012 14:16:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvUno-0006KW-Fa
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:16:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328797002!14183833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14099 invoked from network); 9 Feb 2012 14:16:42 -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;
	9 Feb 2012 14:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10599724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:16:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:16:42 +0000
Message-ID: <1328797000.6133.185.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 14:16:40 +0000
In-Reply-To: <1328796398-2242-4-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
	<1328796398-2242-4-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2 3/3] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 14:06 +0000, Anthony PERARD wrote:
> This patch provide the code to set the VNC password to QEMU upstream through
> VNC. The password is still stored in xenstore but will not be used by QEMU
> upstream.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:17:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvUnq-0006LS-92; Thu, 09 Feb 2012 14:16:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvUno-0006KW-Fa
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:16:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328797002!14183833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14099 invoked from network); 9 Feb 2012 14:16:42 -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;
	9 Feb 2012 14:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10599724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:16:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:16:42 +0000
Message-ID: <1328797000.6133.185.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 9 Feb 2012 14:16:40 +0000
In-Reply-To: <1328796398-2242-4-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
	<1328796398-2242-4-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH V2 3/3] libxl: Set VNC password through QMP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 14:06 +0000, Anthony PERARD wrote:
> This patch provide the code to set the VNC password to QEMU upstream through
> VNC. The password is still stored in xenstore but will not be used by QEMU
> upstream.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:30:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvV1A-0006y7-8G; Thu, 09 Feb 2012 14:30:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RvV18-0006y1-QG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:30:35 +0000
Received: from [85.158.139.83:9397] by server-1.bemta-5.messagelabs.com id
	0A/2B-04285-A88D33F4; Thu, 09 Feb 2012 14:30:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328797830!14392029!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27079 invoked from network); 9 Feb 2012 14:30:33 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:30:33 -0000
Received: by iaeh11 with SMTP id h11so8581420iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 06:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=MhqZISHGNKTENKHJj+KFYcFcYO2UNWlrQHYx9gobhwE=;
	b=hY9X5zXRfcTmbHeP9ZDaZ7OIOvV/Iq2WZeHGFj8S+r7cS4htv+qpuXl7n+3iJx1JFQ
	qnQnMQK/pKpQvTbIr7Ba06IESALdmbCdw9petkq3JPGovIEEABg3Arvt1VkhTC/W8hPl
	EGQ1AF55jFBEBd4uMEwRBNYWogEMNlGBfKjbo=
Received: by 10.50.194.170 with SMTP id hx10mr30910485igc.6.1328797816977;
	Thu, 09 Feb 2012 06:30:16 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id gw1sm5530718igb.0.2012.02.09.06.30.13
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 06:30:15 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 06:30:06 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB59186E.2AC49%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32
	bits mode
Thread-Index: AcznN1FLAnHdU9p0v0mihrR5P8UMUg==
In-Reply-To: <5c798691888303d446b0.1328763218@xdev.gridcentric.ca>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32
 bits mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 20:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>  tools/tests/Makefile                |   2 --
>  tools/tests/xen-access/xen-access.c |  12 +++++++-----
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Please use the proper format macros in inttypes.h rather than casting. I
fixed this up in this case, and have applied the resulting patch.

 -- Keir

> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/Makefile
> --- a/tools/tests/Makefile
> +++ b/tools/tests/Makefile
> @@ -11,9 +11,7 @@ ifeq ($(XEN_TARGET_ARCH),__fixme__)
>  SUBDIRS-y += regression
>  endif
>  SUBDIRS-y += x86_emulator
> -ifneq ($(XEN_TARGET_ARCH),x86_32)
>  SUBDIRS-y += xen-access
> -endif
>  
>  .PHONY: all clean install distclean
>  all clean distclean: %: subdirs-%
> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/xen-access/xen-access.c
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -600,13 +600,13 @@ int main(int argc, char *argv[])
>              case MEM_EVENT_REASON_VIOLATION:
>                  rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
>  
> -                printf("PAGE ACCESS: %c%c%c for GFN %lx (offset %06lx) gla
> %016lx (vcpu %d)\n",
> +                printf("PAGE ACCESS: %c%c%c for GFN %llx (offset %06llx) gla
> %016llx (vcpu %d)\n",
>                          req.access_r ? 'r' : '-',
>                          req.access_w ? 'w' : '-',
>                          req.access_x ? 'x' : '-',
> -                        req.gfn,
> -                        req.offset,
> -                        req.gla,
> +                        (unsigned long long) req.gfn,
> +                        (unsigned long long) req.offset,
> +                        (unsigned long long) req.gla,
>                          req.vcpu_id);
>  
>                  if ( default_access != after_first_access )
> @@ -617,7 +617,9 @@ int main(int argc, char *argv[])
>                  rsp.p2mt = req.p2mt;
>                  break;
>              case MEM_EVENT_REASON_INT3:
> -                printf("INT3: rip=%016lx, gfn=%lx (vcpu %d)\n", req.gla,
> req.gfn,
> +                printf("INT3: rip=%016llx, gfn=%llx (vcpu %d)\n",
> +                        (unsigned long long) req.gla,
> +                        (unsigned long long) req.gfn,
>                          req.vcpu_id);
>  
>                  /* Reinject */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:30:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvV1A-0006y7-8G; Thu, 09 Feb 2012 14:30:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RvV18-0006y1-QG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:30:35 +0000
Received: from [85.158.139.83:9397] by server-1.bemta-5.messagelabs.com id
	0A/2B-04285-A88D33F4; Thu, 09 Feb 2012 14:30:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328797830!14392029!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27079 invoked from network); 9 Feb 2012 14:30:33 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:30:33 -0000
Received: by iaeh11 with SMTP id h11so8581420iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 06:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=MhqZISHGNKTENKHJj+KFYcFcYO2UNWlrQHYx9gobhwE=;
	b=hY9X5zXRfcTmbHeP9ZDaZ7OIOvV/Iq2WZeHGFj8S+r7cS4htv+qpuXl7n+3iJx1JFQ
	qnQnMQK/pKpQvTbIr7Ba06IESALdmbCdw9petkq3JPGovIEEABg3Arvt1VkhTC/W8hPl
	EGQ1AF55jFBEBd4uMEwRBNYWogEMNlGBfKjbo=
Received: by 10.50.194.170 with SMTP id hx10mr30910485igc.6.1328797816977;
	Thu, 09 Feb 2012 06:30:16 -0800 (PST)
Received: from [101.1.150.11] ([96.49.152.177])
	by mx.google.com with ESMTPS id gw1sm5530718igb.0.2012.02.09.06.30.13
	(version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 06:30:15 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 09 Feb 2012 06:30:06 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB59186E.2AC49%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32
	bits mode
Thread-Index: AcznN1FLAnHdU9p0v0mihrR5P8UMUg==
In-Reply-To: <5c798691888303d446b0.1328763218@xdev.gridcentric.ca>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32
 bits mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 08/02/2012 20:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>  tools/tests/Makefile                |   2 --
>  tools/tests/xen-access/xen-access.c |  12 +++++++-----
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Please use the proper format macros in inttypes.h rather than casting. I
fixed this up in this case, and have applied the resulting patch.

 -- Keir

> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/Makefile
> --- a/tools/tests/Makefile
> +++ b/tools/tests/Makefile
> @@ -11,9 +11,7 @@ ifeq ($(XEN_TARGET_ARCH),__fixme__)
>  SUBDIRS-y += regression
>  endif
>  SUBDIRS-y += x86_emulator
> -ifneq ($(XEN_TARGET_ARCH),x86_32)
>  SUBDIRS-y += xen-access
> -endif
>  
>  .PHONY: all clean install distclean
>  all clean distclean: %: subdirs-%
> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/xen-access/xen-access.c
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -600,13 +600,13 @@ int main(int argc, char *argv[])
>              case MEM_EVENT_REASON_VIOLATION:
>                  rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn, &access);
>  
> -                printf("PAGE ACCESS: %c%c%c for GFN %lx (offset %06lx) gla
> %016lx (vcpu %d)\n",
> +                printf("PAGE ACCESS: %c%c%c for GFN %llx (offset %06llx) gla
> %016llx (vcpu %d)\n",
>                          req.access_r ? 'r' : '-',
>                          req.access_w ? 'w' : '-',
>                          req.access_x ? 'x' : '-',
> -                        req.gfn,
> -                        req.offset,
> -                        req.gla,
> +                        (unsigned long long) req.gfn,
> +                        (unsigned long long) req.offset,
> +                        (unsigned long long) req.gla,
>                          req.vcpu_id);
>  
>                  if ( default_access != after_first_access )
> @@ -617,7 +617,9 @@ int main(int argc, char *argv[])
>                  rsp.p2mt = req.p2mt;
>                  break;
>              case MEM_EVENT_REASON_INT3:
> -                printf("INT3: rip=%016lx, gfn=%lx (vcpu %d)\n", req.gla,
> req.gfn,
> +                printf("INT3: rip=%016llx, gfn=%llx (vcpu %d)\n",
> +                        (unsigned long long) req.gla,
> +                        (unsigned long long) req.gfn,
>                          req.vcpu_id);
>  
>                  /* Reinject */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:44:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVDt-0007JS-N6; Thu, 09 Feb 2012 14:43:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvVDr-0007JL-IX
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:43:43 +0000
Received: from [85.158.139.83:48640] by server-2.bemta-5.messagelabs.com id
	71/EC-20725-E9BD33F4; Thu, 09 Feb 2012 14:43:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328798621!7058770!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTU1NDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3739 invoked from network); 9 Feb 2012 14:43:41 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 14:43:41 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 6BFA645808C;
	Thu,  9 Feb 2012 06:43:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=q+O1Rk52ykeUfIJd8ktgrowlamJcym3bAL4wh2nl/G8X
	/QloGf1UL1rD2+jXdvtKvwV7jDYVJ9n+ypQZFlSgqHFWkROABwAAYF/ylc2EdyRb
	JUcMfP/DssN0celH9qd46x9/Wj9XTJcfDCq/3Xu9G0NHh8jmkct4wr6hr6hZWQg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=T0g5XLGYHJT35O7xpo3y7j38z+U=; b=tlm9m6zz
	v1irPfGuegKSr9hw+Rw441UF99Hk/A9gop71ZJN/6POYEcmDE9KLbnNNfkWFWLJS
	e9QzyzTuLlQpOPwKi0uwzxBnIUJjnvvu5YRbOjrlhbLg1Nnzf1gRh/KF7HANu+rk
	YITsERmjH0rCw7Fhu0hXdQ6nlBGnAy7Kh14=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id C7BD345807C; 
	Thu,  9 Feb 2012 06:43:34 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 06:43:35 -0800
Message-ID: <4cd24be77523d04a761c9ab7bb3f9f7f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB59186E.2AC49%keir.xen@gmail.com>
References: <CB59186E.2AC49%keir.xen@gmail.com>
Date: Thu, 9 Feb 2012 06:43:35 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32
 bits mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 08/02/2012 20:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> wrote:
>
>>  tools/tests/Makefile                |   2 --
>>  tools/tests/xen-access/xen-access.c |  12 +++++++-----
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Please use the proper format macros in inttypes.h rather than casting. I
> fixed this up in this case, and have applied the resulting patch.
Ok, thanks!
Andres

>
>  -- Keir
>
>> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/Makefile
>> --- a/tools/tests/Makefile
>> +++ b/tools/tests/Makefile
>> @@ -11,9 +11,7 @@ ifeq ($(XEN_TARGET_ARCH),__fixme__)
>>  SUBDIRS-y += regression
>>  endif
>>  SUBDIRS-y += x86_emulator
>> -ifneq ($(XEN_TARGET_ARCH),x86_32)
>>  SUBDIRS-y += xen-access
>> -endif
>>
>>  .PHONY: all clean install distclean
>>  all clean distclean: %: subdirs-%
>> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/xen-access/xen-access.c
>> --- a/tools/tests/xen-access/xen-access.c
>> +++ b/tools/tests/xen-access/xen-access.c
>> @@ -600,13 +600,13 @@ int main(int argc, char *argv[])
>>              case MEM_EVENT_REASON_VIOLATION:
>>                  rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn,
>> &access);
>>
>> -                printf("PAGE ACCESS: %c%c%c for GFN %lx (offset %06lx)
>> gla
>> %016lx (vcpu %d)\n",
>> +                printf("PAGE ACCESS: %c%c%c for GFN %llx (offset
>> %06llx) gla
>> %016llx (vcpu %d)\n",
>>                          req.access_r ? 'r' : '-',
>>                          req.access_w ? 'w' : '-',
>>                          req.access_x ? 'x' : '-',
>> -                        req.gfn,
>> -                        req.offset,
>> -                        req.gla,
>> +                        (unsigned long long) req.gfn,
>> +                        (unsigned long long) req.offset,
>> +                        (unsigned long long) req.gla,
>>                          req.vcpu_id);
>>
>>                  if ( default_access != after_first_access )
>> @@ -617,7 +617,9 @@ int main(int argc, char *argv[])
>>                  rsp.p2mt = req.p2mt;
>>                  break;
>>              case MEM_EVENT_REASON_INT3:
>> -                printf("INT3: rip=%016lx, gfn=%lx (vcpu %d)\n",
>> req.gla,
>> req.gfn,
>> +                printf("INT3: rip=%016llx, gfn=%llx (vcpu %d)\n",
>> +                        (unsigned long long) req.gla,
>> +                        (unsigned long long) req.gfn,
>>                          req.vcpu_id);
>>
>>                  /* Reinject */
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:44:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVDt-0007JS-N6; Thu, 09 Feb 2012 14:43:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvVDr-0007JL-IX
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:43:43 +0000
Received: from [85.158.139.83:48640] by server-2.bemta-5.messagelabs.com id
	71/EC-20725-E9BD33F4; Thu, 09 Feb 2012 14:43:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328798621!7058770!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTU1NDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3739 invoked from network); 9 Feb 2012 14:43:41 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 14:43:41 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 6BFA645808C;
	Thu,  9 Feb 2012 06:43:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=q+O1Rk52ykeUfIJd8ktgrowlamJcym3bAL4wh2nl/G8X
	/QloGf1UL1rD2+jXdvtKvwV7jDYVJ9n+ypQZFlSgqHFWkROABwAAYF/ylc2EdyRb
	JUcMfP/DssN0celH9qd46x9/Wj9XTJcfDCq/3Xu9G0NHh8jmkct4wr6hr6hZWQg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=T0g5XLGYHJT35O7xpo3y7j38z+U=; b=tlm9m6zz
	v1irPfGuegKSr9hw+Rw441UF99Hk/A9gop71ZJN/6POYEcmDE9KLbnNNfkWFWLJS
	e9QzyzTuLlQpOPwKi0uwzxBnIUJjnvvu5YRbOjrlhbLg1Nnzf1gRh/KF7HANu+rk
	YITsERmjH0rCw7Fhu0hXdQ6nlBGnAy7Kh14=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id C7BD345807C; 
	Thu,  9 Feb 2012 06:43:34 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 06:43:35 -0800
Message-ID: <4cd24be77523d04a761c9ab7bb3f9f7f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB59186E.2AC49%keir.xen@gmail.com>
References: <CB59186E.2AC49%keir.xen@gmail.com>
Date: Thu, 9 Feb 2012 06:43:35 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] Tools: Make xen-access test compile in 32
 bits mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 08/02/2012 20:53, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> wrote:
>
>>  tools/tests/Makefile                |   2 --
>>  tools/tests/xen-access/xen-access.c |  12 +++++++-----
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Please use the proper format macros in inttypes.h rather than casting. I
> fixed this up in this case, and have applied the resulting patch.
Ok, thanks!
Andres

>
>  -- Keir
>
>> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/Makefile
>> --- a/tools/tests/Makefile
>> +++ b/tools/tests/Makefile
>> @@ -11,9 +11,7 @@ ifeq ($(XEN_TARGET_ARCH),__fixme__)
>>  SUBDIRS-y += regression
>>  endif
>>  SUBDIRS-y += x86_emulator
>> -ifneq ($(XEN_TARGET_ARCH),x86_32)
>>  SUBDIRS-y += xen-access
>> -endif
>>
>>  .PHONY: all clean install distclean
>>  all clean distclean: %: subdirs-%
>> diff -r 78ff0c8a944f -r 5c7986918883 tools/tests/xen-access/xen-access.c
>> --- a/tools/tests/xen-access/xen-access.c
>> +++ b/tools/tests/xen-access/xen-access.c
>> @@ -600,13 +600,13 @@ int main(int argc, char *argv[])
>>              case MEM_EVENT_REASON_VIOLATION:
>>                  rc = xc_hvm_get_mem_access(xch, domain_id, req.gfn,
>> &access);
>>
>> -                printf("PAGE ACCESS: %c%c%c for GFN %lx (offset %06lx)
>> gla
>> %016lx (vcpu %d)\n",
>> +                printf("PAGE ACCESS: %c%c%c for GFN %llx (offset
>> %06llx) gla
>> %016llx (vcpu %d)\n",
>>                          req.access_r ? 'r' : '-',
>>                          req.access_w ? 'w' : '-',
>>                          req.access_x ? 'x' : '-',
>> -                        req.gfn,
>> -                        req.offset,
>> -                        req.gla,
>> +                        (unsigned long long) req.gfn,
>> +                        (unsigned long long) req.offset,
>> +                        (unsigned long long) req.gla,
>>                          req.vcpu_id);
>>
>>                  if ( default_access != after_first_access )
>> @@ -617,7 +617,9 @@ int main(int argc, char *argv[])
>>                  rsp.p2mt = req.p2mt;
>>                  break;
>>              case MEM_EVENT_REASON_INT3:
>> -                printf("INT3: rip=%016lx, gfn=%lx (vcpu %d)\n",
>> req.gla,
>> req.gfn,
>> +                printf("INT3: rip=%016llx, gfn=%llx (vcpu %d)\n",
>> +                        (unsigned long long) req.gla,
>> +                        (unsigned long long) req.gfn,
>>                          req.vcpu_id);
>>
>>                  /* Reinject */
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:45:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVFT-0007QN-Lh; Thu, 09 Feb 2012 14:45:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvVFR-0007Pt-DS
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:45:21 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328798712!14189850!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22297 invoked from network); 9 Feb 2012 14:45:14 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 14:45:14 -0000
Received: from macbook.scsiguy.com (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19Ej8cS054527
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 07:45:09 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F339F0A0200007800071D46@nat28.tlf.novell.com>
Date: Thu, 9 Feb 2012 07:45:18 -0700
Message-Id: <02550599-5D2D-4567-A98C-A2F3445B134C@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
	<4F3236C70200007800071AA1@nat28.tlf.novell.com>
	<493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
	<4F339F0A0200007800071D46@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 09 Feb 2012 07:45:09 -0700 (MST)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 9, 2012, at 2:25 AM, Jan Beulich wrote:

>>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
>> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:
>> 
>>>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>>>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>>>> 
>>>>>> NAK. No backwards incompatible changes allowed in public headers.
>>>>> 
>>>>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>>>>> legacy
>>>>> source compatibility.  After trying lots of things, testing the impact on an
>>>>> existing blkfront
>>>>> and blkback implementation, I think the best two options are:
>>>>> 
>>>>> 1. Version the header file and require consumers to declare the interface
>>>>> version
>>>>>    they are using.  If the version isn't declared, the default, legacy,
>>>>> "version 1.0" will
>>>>>    be in effect.
>>>>> 
>>>>>    Positives:   No change in or constant naming conventions.  Data
>>>>> structures and
>>>>>                        constants for new features are properly hidden from
>>>>> legacy implementations.
>>>>>    Negatives: Messy #ifdefs
>>>> 
>>>> We already have this. See use of
>>>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>>>> headers.
>>> 
>>> Hmm, I would think these should specifically not be used in the
>>> io/ subtree - those aren't definitions of the interface to Xen, but
>>> ones shared between the respective backends and frontends.
>>> Each interface is (apart from its relying on the ring definitions)
>>> entirely self contained.
>>> 
>>> Jan
>> 
>> 
>> The versioning required allows a driver to declare, "I am compatible
>> with any source compatibility breaking changes up to version X of
>> the header file".  Declaring support for the latest version does
>> not require that a driver implement the new extensions.  Just one
>> constant needs to be renamed.  So I don't see this as really altering
>> the interface between front and backends (i.e. it is not a "blkif2")
> 
> Sure. But pulling in header updates should not require *any* other
> source changes, so long as __XEN_INTERFACE_VERSION__ isn't
> bumped.

Perhaps my language wasn't clear.  The change to a blkif driver is would
only necessary if __XEN_INTERFACE_VERSION__ is bumped.  I was
trying to say that when the bump is made, the needed change would be
quite small.

> It's also unclear to me why simply giving new constants new names
> (instead of changing the meaning of existing ones) is such a big
> deal - the most strait forward solution doubtlessly is not having
> any conditionals in that header, and simply add new things with
> new, unambiguous names.

The confusion arrises because we'd need to, in order to keep the
terminology consistent, rename existing constants too.  More
specifically, a "request" in the legacy driver is a "logical device
operation".  I would like to retain that convention even if a logical
request consumes multiple ring entries.  However, if
BLKIF_MAX_SEGMENTS_PER_REQUEST comes to mean the
number of segments in the first ring entry of a request, then we
need to come up with another name for the maximum number of
segments in a "logical request".  Changing REQUEST to something
else (e.g. "OP") means even more surgery to existing drivers so
that they consistently use the new terminology.  So, in my alternative
proposal, I chose to shorten SEGMENTS to SEGS instead.  However,
this still leaves BLKIF_MAX_SEGMENTS_PER_REQUEST around
for folks to use incorrectly.

I'd rather just version BLKIF_MAX_SEGMENTS_PER_REQUEST.
I'll post a trial patch with this change shortly.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:45:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVFT-0007QN-Lh; Thu, 09 Feb 2012 14:45:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvVFR-0007Pt-DS
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:45:21 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328798712!14189850!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22297 invoked from network); 9 Feb 2012 14:45:14 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 14:45:14 -0000
Received: from macbook.scsiguy.com (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19Ej8cS054527
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 07:45:09 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F339F0A0200007800071D46@nat28.tlf.novell.com>
Date: Thu, 9 Feb 2012 07:45:18 -0700
Message-Id: <02550599-5D2D-4567-A98C-A2F3445B134C@spectralogic.com>
References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com>
	<CB56DC5E.2A92B%keir.xen@gmail.com>
	<4F3236C70200007800071AA1@nat28.tlf.novell.com>
	<493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com>
	<4F339F0A0200007800071D46@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 09 Feb 2012 07:45:09 -0700 (MST)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 5] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 9, 2012, at 2:25 AM, Jan Beulich wrote:

>>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
>> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote:
>> 
>>>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>>>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>>>> 
>>>>>> NAK. No backwards incompatible changes allowed in public headers.
>>>>> 
>>>>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>>>>> legacy
>>>>> source compatibility.  After trying lots of things, testing the impact on an
>>>>> existing blkfront
>>>>> and blkback implementation, I think the best two options are:
>>>>> 
>>>>> 1. Version the header file and require consumers to declare the interface
>>>>> version
>>>>>    they are using.  If the version isn't declared, the default, legacy,
>>>>> "version 1.0" will
>>>>>    be in effect.
>>>>> 
>>>>>    Positives:   No change in or constant naming conventions.  Data
>>>>> structures and
>>>>>                        constants for new features are properly hidden from
>>>>> legacy implementations.
>>>>>    Negatives: Messy #ifdefs
>>>> 
>>>> We already have this. See use of
>>>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>>>> headers.
>>> 
>>> Hmm, I would think these should specifically not be used in the
>>> io/ subtree - those aren't definitions of the interface to Xen, but
>>> ones shared between the respective backends and frontends.
>>> Each interface is (apart from its relying on the ring definitions)
>>> entirely self contained.
>>> 
>>> Jan
>> 
>> 
>> The versioning required allows a driver to declare, "I am compatible
>> with any source compatibility breaking changes up to version X of
>> the header file".  Declaring support for the latest version does
>> not require that a driver implement the new extensions.  Just one
>> constant needs to be renamed.  So I don't see this as really altering
>> the interface between front and backends (i.e. it is not a "blkif2")
> 
> Sure. But pulling in header updates should not require *any* other
> source changes, so long as __XEN_INTERFACE_VERSION__ isn't
> bumped.

Perhaps my language wasn't clear.  The change to a blkif driver is would
only necessary if __XEN_INTERFACE_VERSION__ is bumped.  I was
trying to say that when the bump is made, the needed change would be
quite small.

> It's also unclear to me why simply giving new constants new names
> (instead of changing the meaning of existing ones) is such a big
> deal - the most strait forward solution doubtlessly is not having
> any conditionals in that header, and simply add new things with
> new, unambiguous names.

The confusion arrises because we'd need to, in order to keep the
terminology consistent, rename existing constants too.  More
specifically, a "request" in the legacy driver is a "logical device
operation".  I would like to retain that convention even if a logical
request consumes multiple ring entries.  However, if
BLKIF_MAX_SEGMENTS_PER_REQUEST comes to mean the
number of segments in the first ring entry of a request, then we
need to come up with another name for the maximum number of
segments in a "logical request".  Changing REQUEST to something
else (e.g. "OP") means even more surgery to existing drivers so
that they consistently use the new terminology.  So, in my alternative
proposal, I chose to shorten SEGMENTS to SEGS instead.  However,
this still leaves BLKIF_MAX_SEGMENTS_PER_REQUEST around
for folks to use incorrectly.

I'd rather just version BLKIF_MAX_SEGMENTS_PER_REQUEST.
I'll post a trial patch with this change shortly.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14: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.xensource.com>)
	id 1RvVFs-0007SW-9t; Thu, 09 Feb 2012 14:45: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 1RvVFq-0007SG-AV
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:45:46 +0000
Received: from [85.158.139.83:64891] by server-3.bemta-5.messagelabs.com id
	67/43-25605-91CD33F4; Thu, 09 Feb 2012 14:45:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328798744!13550758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18252 invoked from network); 9 Feb 2012 14:45:44 -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;
	9 Feb 2012 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10600874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:45:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:45:44 +0000
Message-ID: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 14:45:41 +0000
In-Reply-To: <1328788166.6133.147.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
	<1328788166.6133.147.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/27] xen: ARMv7 with virtualization
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 11:49 +0000, Ian Campbell wrote:

> I have committed patches 7 (generic code, applied with Keir's ACK) and
> patches 8-24. However I stopped before applying #25 "arm: makefiles"
> because the full series failed to build with:
[...]
> domain_pirq_to_irq has been in the tree for quite some time so I guess
> something has changed wrt implicit #includes? Can you fixup and resend
> the fix plus the last three patches please.

I decided to do this. I'll follow up to this mail with the two patches
which I needed to make this compile. Please ACK and I will insert them
before "arm: makefiles" and commit the whole lot.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14: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.xensource.com>)
	id 1RvVFs-0007SW-9t; Thu, 09 Feb 2012 14:45: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 1RvVFq-0007SG-AV
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:45:46 +0000
Received: from [85.158.139.83:64891] by server-3.bemta-5.messagelabs.com id
	67/43-25605-91CD33F4; Thu, 09 Feb 2012 14:45:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328798744!13550758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18252 invoked from network); 9 Feb 2012 14:45:44 -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;
	9 Feb 2012 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10600874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:45:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:45:44 +0000
Message-ID: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 14:45:41 +0000
In-Reply-To: <1328788166.6133.147.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
	<1328788166.6133.147.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/27] xen: ARMv7 with virtualization
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 11:49 +0000, Ian Campbell wrote:

> I have committed patches 7 (generic code, applied with Keir's ACK) and
> patches 8-24. However I stopped before applying #25 "arm: makefiles"
> because the full series failed to build with:
[...]
> domain_pirq_to_irq has been in the tree for quite some time so I guess
> something has changed wrt implicit #includes? Can you fixup and resend
> the fix plus the last three patches please.

I decided to do this. I'll follow up to this mail with the two patches
which I needed to make this compile. Please ACK and I will insert them
before "arm: makefiles" and commit the whole lot.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:46:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvVG1-0007Tj-7G; Thu, 09 Feb 2012 14:45:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvVFz-0007Sm-OS
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:45:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328798749!13569595!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTc0ODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19596 invoked from network); 9 Feb 2012 14:45:49 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 14:45:49 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 9FE4E7EC074;
	Thu,  9 Feb 2012 06:45:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=JnjK/6O0+OkBVrCWk0Hnwc3rfuvvRVohZScEc1HAnMfP
	aCRNnk+9XUAuIAD5NCvY2aRWve7UqB/xObp/SXqEEFRLsoWBmcqhJG5wvnSX4I4W
	HXH06csxcfDKGQcH6StEpFRH+lDp16gYZJ5C8kDPNb/O/V3bys6ZmW9z+xUSKhM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=+DlhRjZdPgLljosNwW2Q4sWCbYY=; b=m6zOu/fa
	P5kwv7L5Om4j6EJcTumdeBM/BQm29GmpBscDiMCCGRqt6dmFzb4SJdicxR8uy1t9
	PLRPQu0PFO+Pj+bbRcxyrJsSyMGA0H231L3riHJgmzDgKzz1M+7TiMl5wQAu+j8/
	3ieHEhZ3V90Gfr9X9vCOJUYASlX/o2o8wrE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 3BF567EC064; 
	Thu,  9 Feb 2012 06:45:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 06:45:48 -0800
Message-ID: <ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
Date: Thu, 9 Feb 2012 06:45:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Feb 9, 2012 at 5:45 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>> =A0 =A0 =A0 =A0 unmap_domain_page(b);
>> =A0 =A0 }
>>
>> + =A0 =A0/* First, take all pages off the domain list */
>> =A0 =A0 lock_page_alloc(p2m);
>> -
>> - =A0 =A0/* First, take all pages off the domain list */
>> =A0 =A0 for(i=3D0; i < 1 << order ; i++)
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 p =3D page + i;
>> =A0 =A0 =A0 =A0 page_list_del(p, &d->page_list);
>> =A0 =A0 }
>>
>> + =A0 =A0/* Ensure that the PoD cache has never been emptied.
>> + =A0 =A0 * This may cause "zombie domains" since the page will never be
>> freed. */
>> + =A0 =A0BUG_ON( d->arch.relmem !=3D RELMEM_not_started );
>> +
>> + =A0 =A0unlock_page_alloc(p2m);
>> +
>
> I thought we were going to get rid of this BUG_ON? :-)
>
> Other than that, assuming that you've tested it and it works:

Well, I've tested it for months. Does it work? Can that ever be fully
answered? ;)

>
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Great, thanks George!

Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or, wait
for more comments. Or, send a micro-patch later removing the BUG_ON.

Andres
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:46:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvVG1-0007Tj-7G; Thu, 09 Feb 2012 14:45:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvVFz-0007Sm-OS
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:45:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328798749!13569595!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTc0ODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19596 invoked from network); 9 Feb 2012 14:45:49 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 14:45:49 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 9FE4E7EC074;
	Thu,  9 Feb 2012 06:45:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=JnjK/6O0+OkBVrCWk0Hnwc3rfuvvRVohZScEc1HAnMfP
	aCRNnk+9XUAuIAD5NCvY2aRWve7UqB/xObp/SXqEEFRLsoWBmcqhJG5wvnSX4I4W
	HXH06csxcfDKGQcH6StEpFRH+lDp16gYZJ5C8kDPNb/O/V3bys6ZmW9z+xUSKhM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=+DlhRjZdPgLljosNwW2Q4sWCbYY=; b=m6zOu/fa
	P5kwv7L5Om4j6EJcTumdeBM/BQm29GmpBscDiMCCGRqt6dmFzb4SJdicxR8uy1t9
	PLRPQu0PFO+Pj+bbRcxyrJsSyMGA0H231L3riHJgmzDgKzz1M+7TiMl5wQAu+j8/
	3ieHEhZ3V90Gfr9X9vCOJUYASlX/o2o8wrE=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 3BF567EC064; 
	Thu,  9 Feb 2012 06:45:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 06:45:48 -0800
Message-ID: <ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
Date: Thu, 9 Feb 2012 06:45:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Feb 9, 2012 at 5:45 AM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>> =A0 =A0 =A0 =A0 unmap_domain_page(b);
>> =A0 =A0 }
>>
>> + =A0 =A0/* First, take all pages off the domain list */
>> =A0 =A0 lock_page_alloc(p2m);
>> -
>> - =A0 =A0/* First, take all pages off the domain list */
>> =A0 =A0 for(i=3D0; i < 1 << order ; i++)
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 p =3D page + i;
>> =A0 =A0 =A0 =A0 page_list_del(p, &d->page_list);
>> =A0 =A0 }
>>
>> + =A0 =A0/* Ensure that the PoD cache has never been emptied.
>> + =A0 =A0 * This may cause "zombie domains" since the page will never be
>> freed. */
>> + =A0 =A0BUG_ON( d->arch.relmem !=3D RELMEM_not_started );
>> +
>> + =A0 =A0unlock_page_alloc(p2m);
>> +
>
> I thought we were going to get rid of this BUG_ON? :-)
>
> Other than that, assuming that you've tested it and it works:

Well, I've tested it for months. Does it work? Can that ever be fully
answered? ;)

>
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Great, thanks George!

Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or, wait
for more comments. Or, send a micro-patch later removing the BUG_ON.

Andres
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:50:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:50: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.xensource.com>)
	id 1RvVKR-0008HH-JD; Thu, 09 Feb 2012 14:50:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvVKP-0008Fo-I5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:50:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328799022!12640570!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14887 invoked from network); 9 Feb 2012 14:50:23 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 14:50:23 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 71A417EC061;
	Thu,  9 Feb 2012 06:50:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kapYGm1UyTUiDMqDLrWe4gKLNr4mMPK648IsWxS6UUcZ
	P+F4m6jdbIud2KmVi37oLMGGe1hoNhmW+Mf7RfVYR8MyjRkJbGUdQn5SsRwRX+0d
	qyodbNZ1EM56fqwzIuybNbzyyyIJf2518jY77S/cgYjeZRotbun265sMC9/pn7A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6eSk5KF150tbshL4MDs8ceZSO6g=; b=IcyNfI5E
	Z8jhcLYT7Nej1T5wEF+08PoQQRoaI+tl6Gba03DJBywZSXLkKdSpOVUPLMGk7j9J
	NR54020EwLQ02QsDsYWmlC/Q6yQRMZRksG3p37phH4qo8fExUFOgUB41gLgkLp5V
	lHURoTTzkLFGxif681JWWdw5zEe5M2GWjxw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 141DF7EC060; 
	Thu,  9 Feb 2012 06:50:22 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 06:50:22 -0800
Message-ID: <61936533ef44253d5e1b7036711d1324.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120209074242.GC71900@ocelot.phlegethon.org>
References: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
	<20120209074242.GC71900@ocelot.phlegethon.org>
Date: Thu, 9 Feb 2012 06:50:22 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
 shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 01:01 -0500 on 09 Feb (1328749297), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c |  4 +++-
>>  xen/arch/x86/mm/p2m.c         |  6 ++++--
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> NACK, I'm afraid, especially the second one.  '<=' comparisons with a
> number that's made up of a count ORed with a type don't make sense.
> If you want to test both type and count, just test them separately.

The type I'm ORing with is a mask with single bit set, not a multi-bit
type mask. And the type is defined as a higher order bit than the count
mask. So, nothing that I'm ORing with could get in the way of the numeric
comparison.

Having said that I understand it's not terribly elegant or easy to
understand.

Andres

>
> Cheers,
>
> Tim.
>
>> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -200,7 +200,9 @@ static struct page_info* mem_sharing_loo
>>              /* Count has to be at least two, because we're called
>>               * with the mfn locked (1) and this is supposed to be
>>               * a shared page (1). */
>> -            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2);
>> +            ASSERT((page->u.inuse.type_info &
>> +                        (PGT_shared_page | PGT_count_mask)) >=
>> +                            (PGT_shared_page | 2));
>>              ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY);
>>              return page;
>>          }
>> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -745,8 +745,10 @@ set_shared_p2m_entry(struct domain *d, u
>>       * sharable first */
>>      ASSERT(p2m_is_shared(ot));
>>      ASSERT(mfn_valid(omfn));
>> -    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask)
>> -                    != PGT_shared_page) )
>> +    /* Set the m2p entry to invalid only if there are no further type
>> +     * refs to this page as shared */
>> +    if ( (mfn_to_page(omfn)->u.inuse.type_info &
>> +            (PGT_shared_page | PGT_count_mask)) <= PGT_shared_page )
>>          set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
>>
>>      P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:50:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:50: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.xensource.com>)
	id 1RvVKR-0008HH-JD; Thu, 09 Feb 2012 14:50:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RvVKP-0008Fo-I5
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:50:29 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328799022!12640570!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14887 invoked from network); 9 Feb 2012 14:50:23 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 14:50:23 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 71A417EC061;
	Thu,  9 Feb 2012 06:50:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kapYGm1UyTUiDMqDLrWe4gKLNr4mMPK648IsWxS6UUcZ
	P+F4m6jdbIud2KmVi37oLMGGe1hoNhmW+Mf7RfVYR8MyjRkJbGUdQn5SsRwRX+0d
	qyodbNZ1EM56fqwzIuybNbzyyyIJf2518jY77S/cgYjeZRotbun265sMC9/pn7A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6eSk5KF150tbshL4MDs8ceZSO6g=; b=IcyNfI5E
	Z8jhcLYT7Nej1T5wEF+08PoQQRoaI+tl6Gba03DJBywZSXLkKdSpOVUPLMGk7j9J
	NR54020EwLQ02QsDsYWmlC/Q6yQRMZRksG3p37phH4qo8fExUFOgUB41gLgkLp5V
	lHURoTTzkLFGxif681JWWdw5zEe5M2GWjxw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 141DF7EC060; 
	Thu,  9 Feb 2012 06:50:22 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 06:50:22 -0800
Message-ID: <61936533ef44253d5e1b7036711d1324.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120209074242.GC71900@ocelot.phlegethon.org>
References: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
	<20120209074242.GC71900@ocelot.phlegethon.org>
Date: Thu, 9 Feb 2012 06:50:22 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
 shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 01:01 -0500 on 09 Feb (1328749297), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c |  4 +++-
>>  xen/arch/x86/mm/p2m.c         |  6 ++++--
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> NACK, I'm afraid, especially the second one.  '<=' comparisons with a
> number that's made up of a count ORed with a type don't make sense.
> If you want to test both type and count, just test them separately.

The type I'm ORing with is a mask with single bit set, not a multi-bit
type mask. And the type is defined as a higher order bit than the count
mask. So, nothing that I'm ORing with could get in the way of the numeric
comparison.

Having said that I understand it's not terribly elegant or easy to
understand.

Andres

>
> Cheers,
>
> Tim.
>
>> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/mem_sharing.c
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -200,7 +200,9 @@ static struct page_info* mem_sharing_loo
>>              /* Count has to be at least two, because we're called
>>               * with the mfn locked (1) and this is supposed to be
>>               * a shared page (1). */
>> -            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2);
>> +            ASSERT((page->u.inuse.type_info &
>> +                        (PGT_shared_page | PGT_count_mask)) >=
>> +                            (PGT_shared_page | 2));
>>              ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY);
>>              return page;
>>          }
>> diff -r 667191f054c3 -r f2efbfaa8d26 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -745,8 +745,10 @@ set_shared_p2m_entry(struct domain *d, u
>>       * sharable first */
>>      ASSERT(p2m_is_shared(ot));
>>      ASSERT(mfn_valid(omfn));
>> -    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask)
>> -                    != PGT_shared_page) )
>> +    /* Set the m2p entry to invalid only if there are no further type
>> +     * refs to this page as shared */
>> +    if ( (mfn_to_page(omfn)->u.inuse.type_info &
>> +            (PGT_shared_page | PGT_count_mask)) <= PGT_shared_page )
>>          set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
>>
>>      P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:53:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvVNN-0000E3-7X; Thu, 09 Feb 2012 14:53:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVNM-0000DU-A7
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:53:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328799204!12165416!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32660 invoked from network); 9 Feb 2012 14:53:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:53:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181065878"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:53:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:53:24 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q19ErLtq004961;	Thu, 9 Feb 2012 06:53:22 -0800
MIME-Version: 1.0
X-Mercurial-Node: abd72cc240fa3d643541d435f3cb72b75c8a5977
Message-ID: <abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
In-Reply-To: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 9 Feb 2012 14:53:21 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, xen-devel@lists.xensource.com
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328798112 0
# Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
# Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
arm: define domain_pirq_to_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
--- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
+++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
@@ -11,6 +11,7 @@ typedef struct {
 
 struct arch_pirq
 {
+    int irq;
 };
 
 struct irq_cfg {
@@ -19,6 +20,8 @@ struct irq_cfg {
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
 
+#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
+
 #endif /* _ASM_HW_IRQ_H */
 /*
  * Local variables:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:53:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvVNN-0000E3-7X; Thu, 09 Feb 2012 14:53:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVNM-0000DU-A7
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:53:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328799204!12165416!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32660 invoked from network); 9 Feb 2012 14:53:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:53:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="181065878"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:53:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:53:24 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q19ErLtq004961;	Thu, 9 Feb 2012 06:53:22 -0800
MIME-Version: 1.0
X-Mercurial-Node: abd72cc240fa3d643541d435f3cb72b75c8a5977
Message-ID: <abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
In-Reply-To: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 9 Feb 2012 14:53:21 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, xen-devel@lists.xensource.com
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328798112 0
# Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
# Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
arm: define domain_pirq_to_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
--- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
+++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
@@ -11,6 +11,7 @@ typedef struct {
 
 struct arch_pirq
 {
+    int irq;
 };
 
 struct irq_cfg {
@@ -19,6 +20,8 @@ struct irq_cfg {
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
 
+#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
+
 #endif /* _ASM_HW_IRQ_H */
 /*
  * Local variables:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:54:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:54:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVNf-0000HH-KM; Thu, 09 Feb 2012 14:53:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVNe-0000G4-7c
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:53:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328799223!4306423!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12166 invoked from network); 9 Feb 2012 14:53:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21792920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:53:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:53:29 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q19ErRId004964;	Thu, 9 Feb 2012 06:53:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: 565c304be85a6b28e6c12c9f849c07f6ee138aa4
Message-ID: <565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
In-Reply-To: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 9 Feb 2012 14:53:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, xen-devel@lists.xensource.com
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328798113 0
# Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
# Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
arm: define stub arch_dump_shared_mem_info

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
@@ -1,4 +1,4 @@
-/*
+ /*
  * xen/arch/arm/mm.c
  *
  * MMU code for an ARMv7-A with virt extensions.
@@ -311,6 +311,10 @@ void __init setup_frametable_mappings(pa
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:54:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:54:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVNf-0000HH-KM; Thu, 09 Feb 2012 14:53:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVNe-0000G4-7c
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:53:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328799223!4306423!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12166 invoked from network); 9 Feb 2012 14:53:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 14:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325480400"; d="scan'208";a="21792920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 09:53:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 09:53:29 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q19ErRId004964;	Thu, 9 Feb 2012 06:53:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: 565c304be85a6b28e6c12c9f849c07f6ee138aa4
Message-ID: <565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
In-Reply-To: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 9 Feb 2012 14:53:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com, xen-devel@lists.xensource.com
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328798113 0
# Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
# Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
arm: define stub arch_dump_shared_mem_info

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
@@ -1,4 +1,4 @@
-/*
+ /*
  * xen/arch/arm/mm.c
  *
  * MMU code for an ARMv7-A with virt extensions.
@@ -311,6 +311,10 @@ void __init setup_frametable_mappings(pa
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14: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.xensource.com>)
	id 1RvVQ8-0000ZH-PD; Thu, 09 Feb 2012 14:56:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvVQ7-0000YP-Hw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:56:23 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328799375!12694153!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16200 invoked from network); 9 Feb 2012 14:56:17 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 14:56:17 -0000
Received: from macbook.scsiguy.com (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19EuBr2054596
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 07:56:12 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F339CCF0200007800071D40@nat28.tlf.novell.com>
Date: Thu, 9 Feb 2012 07:56:22 -0700
Message-Id: <65A1976C-17A0-4921-A03E-B3990C6FCA1D@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
	<4F2C158C02000078000711D4@nat28.tlf.novell.com>
	<6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
	<4F339CCF0200007800071D40@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 09 Feb 2012 07:56:14 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 9, 2012, at 2:15 AM, Jan Beulich wrote:

>>>> On 08.02.12 at 23:00, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:
>> 
>>>> On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
>>>> 
>>>> However, if this is the rule, both types of "max ring size" values
>>>> are "in effect" even if a back-end does not provide them both.  So
>>>> how do you resolve the conflict?  A fully interoperable front should
>>>> allocate the largest possible ring and advertise that size through
>>>> both mechanisms in a fully consistent manner. That's what I was
>>>> trying to indicate by writing the spec this way.
>>> 
>>> Hmm, I would think a fully compatible frontend should bail (revert to
>>> single page ring) on inconsistent max-ring-pages and
>>> max-ring-page-order, if both are provided by the backend. The limit
>>> for ring-pages should always be max-ring-pages, while the one for
>>> ring-page-order should always be max-ring-page-order. Any mixture
>>> is an error, unless both values are consistent with one another.
>>> 
>>> Jan
>> 
>> Mandating that a front-end publish inconsistent values to the
>> XenStore would be a mistake.  Having the front-end only publish the
>> set of nodes that are recognized by the back-end just adds code
>> complexity with no associated increase in functionality.  You
>> actually would lose the ability to tell that the driver supports
>> both schemes.
>> 
>> To clarify what I mean by that, consider the current state of
>> back-ends in the world.  They fall into 1 of 4 camps:
>> 
>> 1. No multi-page ring support
>> 2. "Citrix style" multi-page ring support.
>> 3. "Red Hat style" multi-page ring support.
>> 4. "Both styles" multi-page ring support.
>> 
>> In cases 1-3, one or both of the max-ring-page* nodes is not present.
>> Per the currently proposed spec, this means that these nodes have
>> their default values.  You seem to be advocating that the front-end
>> write the default values into its corresponding node.  For cases 2
>> and 3, this would lead to contradictory values in the XenStore (e.g.
>> ring-page-order=0 and ring-pages=4).  This will not confuse the
>> back-end, but could confuse a human.
> 
> No, that's not what I intended to propose. Instead, I'd see the
> frontend write consistent values (and best always write both node
> flavors) if at least one of the protocols is supported by the backend.

Then your desire is already allowed by the maximum values for
these nodes in the current spec.  I will clarify the notes section to
say that, if both node types are supported by a driver, both node
types should be written with consistent values.

> I'm only suggesting that the frontend should not use either multi-
> page rings at all if it finds both backend node flavors present yet
> having inconsistent values (i.e. absence of either [but not both]
> values does *not* count as inconsistent, and hence a single absent
> node not implicitly assuming its default value).

I think that's a perfectly reasonable behavior, but not the only
reasonable behavior.  If I need to write a front or back end driver that
is more tolerant in order to have optimum performance with an
existing driver that I do not control, the spec should allow me to do this.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14: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.xensource.com>)
	id 1RvVQ8-0000ZH-PD; Thu, 09 Feb 2012 14:56:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvVQ7-0000YP-Hw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:56:23 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328799375!12694153!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16200 invoked from network); 9 Feb 2012 14:56:17 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 14:56:17 -0000
Received: from macbook.scsiguy.com (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19EuBr2054596
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 07:56:12 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F339CCF0200007800071D40@nat28.tlf.novell.com>
Date: Thu, 9 Feb 2012 07:56:22 -0700
Message-Id: <65A1976C-17A0-4921-A03E-B3990C6FCA1D@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<4F2C04F50200007800071056@nat28.tlf.novell.com>
	<33AA3F48-F051-46EA-AC61-5767D8129205@spectralogic.com>
	<4F2C158C02000078000711D4@nat28.tlf.novell.com>
	<6CB4682E-D49F-46B7-B40F-33DF7C7C683A@spectralogic.com>
	<4F339CCF0200007800071D40@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 09 Feb 2012 07:56:14 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	KeirFraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 9, 2012, at 2:15 AM, Jan Beulich wrote:

>>>> On 08.02.12 at 23:00, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> On Feb 3, 2012, at 9:12 AM, Jan Beulich wrote:
>> 
>>>> On 03.02.12 at 16:19, Justin Gibbs <justing@spectralogic.com> wrote:
>>>> 
>>>> However, if this is the rule, both types of "max ring size" values
>>>> are "in effect" even if a back-end does not provide them both.  So
>>>> how do you resolve the conflict?  A fully interoperable front should
>>>> allocate the largest possible ring and advertise that size through
>>>> both mechanisms in a fully consistent manner. That's what I was
>>>> trying to indicate by writing the spec this way.
>>> 
>>> Hmm, I would think a fully compatible frontend should bail (revert to
>>> single page ring) on inconsistent max-ring-pages and
>>> max-ring-page-order, if both are provided by the backend. The limit
>>> for ring-pages should always be max-ring-pages, while the one for
>>> ring-page-order should always be max-ring-page-order. Any mixture
>>> is an error, unless both values are consistent with one another.
>>> 
>>> Jan
>> 
>> Mandating that a front-end publish inconsistent values to the
>> XenStore would be a mistake.  Having the front-end only publish the
>> set of nodes that are recognized by the back-end just adds code
>> complexity with no associated increase in functionality.  You
>> actually would lose the ability to tell that the driver supports
>> both schemes.
>> 
>> To clarify what I mean by that, consider the current state of
>> back-ends in the world.  They fall into 1 of 4 camps:
>> 
>> 1. No multi-page ring support
>> 2. "Citrix style" multi-page ring support.
>> 3. "Red Hat style" multi-page ring support.
>> 4. "Both styles" multi-page ring support.
>> 
>> In cases 1-3, one or both of the max-ring-page* nodes is not present.
>> Per the currently proposed spec, this means that these nodes have
>> their default values.  You seem to be advocating that the front-end
>> write the default values into its corresponding node.  For cases 2
>> and 3, this would lead to contradictory values in the XenStore (e.g.
>> ring-page-order=0 and ring-pages=4).  This will not confuse the
>> back-end, but could confuse a human.
> 
> No, that's not what I intended to propose. Instead, I'd see the
> frontend write consistent values (and best always write both node
> flavors) if at least one of the protocols is supported by the backend.

Then your desire is already allowed by the maximum values for
these nodes in the current spec.  I will clarify the notes section to
say that, if both node types are supported by a driver, both node
types should be written with consistent values.

> I'm only suggesting that the frontend should not use either multi-
> page rings at all if it finds both backend node flavors present yet
> having inconsistent values (i.e. absence of either [but not both]
> values does *not* count as inconsistent, and hence a single absent
> node not implicitly assuming its default value).

I think that's a perfectly reasonable behavior, but not the only
reasonable behavior.  If I need to write a front or back end driver that
is more tolerant in order to have optimum performance with an
existing driver that I do not control, the spec should allow me to do this.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14: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.xensource.com>)
	id 1RvVQ8-0000Yx-7W; Thu, 09 Feb 2012 14:56:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvVQ6-0000YJ-EP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:56:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328799375!12710798!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11890 invoked from network); 9 Feb 2012 14:56:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 14:56:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 14:56:15 +0000
Message-Id: <4F33EC9D0200007800071FE7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 14:56:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
	<4F32AF53.5070006@citrix.com>
	<4F33B3F10200007800071DAE@nat28.tlf.novell.com>
	<4F33B34B.30403@citrix.com>
In-Reply-To: <4F33B34B.30403@citrix.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>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 12:51, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 09/02/12 10:54, Jan Beulich wrote:
>>>>> On 08.02.12 at 18:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Doing this in x86 code is perhaps fine; you shouldn't do this in common
>> code though (ia64, for example, allows [at least theoretically] to be
>> built non-SMP, even though particularly on that architecture this seems
>> to make very little sense).
>>
>> Jan
> 
> Im some ways, that is the same as x86 !CONFIG_SMP support; theoretically
> sensible but we never use it.
> 
> Is !SMP 'supported' for IA64 in any way?

Probably not, but then again the whole ia64 port apparently isn't
supported in any way these days. All I was hinting at is that their
config.h does have provisions for !SMP.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14: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.xensource.com>)
	id 1RvVQ8-0000Yx-7W; Thu, 09 Feb 2012 14:56:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvVQ6-0000YJ-EP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:56:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328799375!12710798!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11890 invoked from network); 9 Feb 2012 14:56:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 14:56:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 14:56:15 +0000
Message-Id: <4F33EC9D0200007800071FE7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 14:56:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<101b0d7ebb00e1af8acf.1328719536@andrewcoop.uk.xensource.com>
	<4F32AF53.5070006@citrix.com>
	<4F33B3F10200007800071DAE@nat28.tlf.novell.com>
	<4F33B34B.30403@citrix.com>
In-Reply-To: <4F33B34B.30403@citrix.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>
Subject: Re: [Xen-devel] [PATCH 1 of 4] CONFIG: remove CONFIG_SMP #ifdefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 12:51, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 09/02/12 10:54, Jan Beulich wrote:
>>>>> On 08.02.12 at 18:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Doing this in x86 code is perhaps fine; you shouldn't do this in common
>> code though (ia64, for example, allows [at least theoretically] to be
>> built non-SMP, even though particularly on that architecture this seems
>> to make very little sense).
>>
>> Jan
> 
> Im some ways, that is the same as x86 !CONFIG_SMP support; theoretically
> sensible but we never use it.
> 
> Is !SMP 'supported' for IA64 in any way?

Probably not, but then again the whole ia64 port apparently isn't
supported in any way these days. All I was hinting at is that their
config.h does have provisions for !SMP.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:58:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVSP-0000so-CF; Thu, 09 Feb 2012 14:58:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvVSO-0000sH-07
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:58:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328799517!12633684!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29792 invoked from network); 9 Feb 2012 14:58:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 14:58:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 14:58:36 +0000
Message-Id: <4F33ED2A0200007800071FEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 14:58:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
	<4F32AFBF.7090201@citrix.com>
	<4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
	<4F33B377.4080605@citrix.com> <4F33C549.7040800@citrix.com>
In-Reply-To: <4F33C549.7040800@citrix.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>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 14:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Version 3 attached.
> 
> It keeps the EOI register function, protected by an a check on the
> IOAPIC version.

Acked-by: Jan Beulich <jbeulich@suse.com>

> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 14:58:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 14:58:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVSP-0000so-CF; Thu, 09 Feb 2012 14:58:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvVSO-0000sH-07
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 14:58:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328799517!12633684!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29792 invoked from network); 9 Feb 2012 14:58:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 14:58:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 09 Feb 2012 14:58:36 +0000
Message-Id: <4F33ED2A0200007800071FEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 09 Feb 2012 14:58:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1328719535@andrewcoop.uk.xensource.com>
	<d59767433c7f8913c198.1328719539@andrewcoop.uk.xensource.com>
	<4F32AFBF.7090201@citrix.com>
	<4F33B5FA0200007800071DBB@nat28.tlf.novell.com>
	<4F33B377.4080605@citrix.com> <4F33C549.7040800@citrix.com>
In-Reply-To: <4F33C549.7040800@citrix.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>
Subject: Re: [Xen-devel] [PATCH 4 of 4] CONFIG: remove #ifdef __ia64__ from
 the x86 arch tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 14:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Version 3 attached.
> 
> It keeps the EOI register function, protected by an a check on the
> IOAPIC version.

Acked-by: Jan Beulich <jbeulich@suse.com>

> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:12:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVfb-0001Lt-Pd; Thu, 09 Feb 2012 15:12:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvVfZ-0001Lo-RC
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:12:22 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328800333!12698617!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28194 invoked from network); 9 Feb 2012 15:12:14 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 15:12:14 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19FC8up054699
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 08:12:09 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1328780895.6133.134.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 08:12:19 -0700
Message-Id: <4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 09 Feb 2012 08:12:10 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 9, 2012, at 2:48 AM, Ian Campbell wrote:

> On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>> 
>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>>> @@ -187,6 +216,25 @@
>>>> *      The machine ABI rules governing the format of all ring request and
>>>> *      response structures.
>>>> *
>>>> + * ring-page-order
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  0
>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>> 
>>> Why not just max-ring-page-order. After all, the value is meaningless
>>> for a backend that only exposes max-ring-pages.
>>> 
>>>> + *      Notes:          1, 3
>>>> + *
>>>> + *      The size of the frontend allocated request ring buffer in units
>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>>> + *      etc.).
>>>> + *
>>>> + * ring-pages
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  1
>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>> 
>>> Similarly here - just max-ring-pages should do.
>> 
>> This patch documents existing extensions.  For a new driver to properly negotiate a
>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
>> you must use the XenBus node names as I've defined them here.
> 
> Can we pick one and mark it as preferred and the other deprecated or
> similar? Perhaps backends will have to support both for the foreseeable
> future but we should make it possible for frontends to just pick one if
> that's what they want while nudging them in the direction of all picking
> the same one.

History says that back-ends are updated more slowly than front-ends.  For
example, my fixes to QEMU's serial port emulation that have been in Xen's
mainline for ~2 years are still not widely deployed on EC2.  Folks running
FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
can get console output.

So, if you want your front-ends to have optimal performance regardless of
what cloud or appliance they are running on, the two types will have to be
supported for some time.  Neither is better than the other, just different.

The opposite is true for back-ends.  If your customer controls the guest
environment and chooses not upgrade, you can't kill support for the
variant they use.

> I think the decision should made by the current state of mainline Linux
> & BSD front and backends, i.e. we should prefer what has been upstreamed
> rather than private forks if possible. Does anyone know what that state
> is?

The state is a bit embarrassing on the BSD side.  FreeBSD has had a
multi-page ring extension since October of 2010.  Unfortunately, I wrote
this extension before stumbling upon the Citrix blkif patch or the
extension being used on EC2.  It is closest to the EC2 implementation,
but not quite compatible.  The saving grace is that I don't know of any
deployments of this back-end outside of Spectra, and we have not shipped
it to customers, so I plan to upstream block front and back drivers that
only implement the Citrix and EC2 style extension once blkif.h settles.  A
preliminary version of these changes went out for review a couple weeks
ago.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:12:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVfb-0001Lt-Pd; Thu, 09 Feb 2012 15:12:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvVfZ-0001Lo-RC
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:12:22 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328800333!12698617!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28194 invoked from network); 9 Feb 2012 15:12:14 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 15:12:14 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19FC8up054699
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 08:12:09 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1328780895.6133.134.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 08:12:19 -0700
Message-Id: <4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 09 Feb 2012 08:12:10 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 9, 2012, at 2:48 AM, Ian Campbell wrote:

> On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>> 
>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>>> @@ -187,6 +216,25 @@
>>>> *      The machine ABI rules governing the format of all ring request and
>>>> *      response structures.
>>>> *
>>>> + * ring-page-order
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  0
>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>> 
>>> Why not just max-ring-page-order. After all, the value is meaningless
>>> for a backend that only exposes max-ring-pages.
>>> 
>>>> + *      Notes:          1, 3
>>>> + *
>>>> + *      The size of the frontend allocated request ring buffer in units
>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>>> + *      etc.).
>>>> + *
>>>> + * ring-pages
>>>> + *      Values:         <uint32_t>
>>>> + *      Default Value:  1
>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>> 
>>> Similarly here - just max-ring-pages should do.
>> 
>> This patch documents existing extensions.  For a new driver to properly negotiate a
>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
>> you must use the XenBus node names as I've defined them here.
> 
> Can we pick one and mark it as preferred and the other deprecated or
> similar? Perhaps backends will have to support both for the foreseeable
> future but we should make it possible for frontends to just pick one if
> that's what they want while nudging them in the direction of all picking
> the same one.

History says that back-ends are updated more slowly than front-ends.  For
example, my fixes to QEMU's serial port emulation that have been in Xen's
mainline for ~2 years are still not widely deployed on EC2.  Folks running
FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
can get console output.

So, if you want your front-ends to have optimal performance regardless of
what cloud or appliance they are running on, the two types will have to be
supported for some time.  Neither is better than the other, just different.

The opposite is true for back-ends.  If your customer controls the guest
environment and chooses not upgrade, you can't kill support for the
variant they use.

> I think the decision should made by the current state of mainline Linux
> & BSD front and backends, i.e. we should prefer what has been upstreamed
> rather than private forks if possible. Does anyone know what that state
> is?

The state is a bit embarrassing on the BSD side.  FreeBSD has had a
multi-page ring extension since October of 2010.  Unfortunately, I wrote
this extension before stumbling upon the Citrix blkif patch or the
extension being used on EC2.  It is closest to the EC2 implementation,
but not quite compatible.  The saving grace is that I don't know of any
deployments of this back-end outside of Spectra, and we have not shipped
it to customers, so I plan to upstream block front and back drivers that
only implement the Citrix and EC2 style extension once blkif.h settles.  A
preliminary version of these changes went out for review a couple weeks
ago.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:15:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvViW-0001SF-D4; Thu, 09 Feb 2012 15:15:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvViU-0001S4-CR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:15:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328800515!2424156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32705 invoked from network); 9 Feb 2012 15:15:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:15:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:15:15 +0000
Date: Thu, 9 Feb 2012 15:18:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328798112 0
> # Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
> # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> arm: define domain_pirq_to_irq
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
> --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
> @@ -11,6 +11,7 @@ typedef struct {
>  
>  struct arch_pirq
>  {
> +    int irq;
>  };
>  
>  struct irq_cfg {
> @@ -19,6 +20,8 @@ struct irq_cfg {
>  
>  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
>  
> +#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
> +
>  #endif /* _ASM_HW_IRQ_H */
>  /*
>   * Local variables:
> 

At the moment we don't have a reason for having pirq != irq so we could
just return irq, like ia64 does.
Otherwise I expect that we would need code to set arch.irq = pirq that
at the moment we don't have.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:15:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvViW-0001SF-D4; Thu, 09 Feb 2012 15:15:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvViU-0001S4-CR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:15:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328800515!2424156!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32705 invoked from network); 9 Feb 2012 15:15:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:15:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:15:15 +0000
Date: Thu, 9 Feb 2012 15:18:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328798112 0
> # Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
> # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> arm: define domain_pirq_to_irq
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
> --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
> @@ -11,6 +11,7 @@ typedef struct {
>  
>  struct arch_pirq
>  {
> +    int irq;
>  };
>  
>  struct irq_cfg {
> @@ -19,6 +20,8 @@ struct irq_cfg {
>  
>  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
>  
> +#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
> +
>  #endif /* _ASM_HW_IRQ_H */
>  /*
>   * Local variables:
> 

At the moment we don't have a reason for having pirq != irq so we could
just return irq, like ia64 does.
Otherwise I expect that we would need code to set arch.irq = pirq that
at the moment we don't have.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:17:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVjx-0001YP-Ss; Thu, 09 Feb 2012 15:16:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kris@theendless.org>) id 1RvVjx-0001YH-0R
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:16:53 +0000
X-Env-Sender: kris@theendless.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328800587!52251809!1
X-Originating-IP: [72.51.30.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19901 invoked from network); 9 Feb 2012 15:16:28 -0000
Received: from theendless.org (HELO mail.theendless.org) (72.51.30.5)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 15:16:28 -0000
Received: by mail.theendless.org (Postfix, from userid 102)
	id 28705DC8002; Thu,  9 Feb 2012 10:16:50 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on theendless.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE
	autolearn=no version=3.2.5
Received: from [192.168.20.24] (unknown [96.45.197.22])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by mail.theendless.org (Postfix) with ESMTP id B9A41DC8001;
	Thu,  9 Feb 2012 10:16:49 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theendless.org;
	s=02012012; t=1328800609;
	bh=1zN2xXWfEmZUh/Uyg2MrLDXzwMM+D19Awx+wDelZZQo=;
	h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:
	Content-Transfer-Encoding:Message-Id:References:To;
	b=NCUkNJl9Q8D6dbjgc80rWgjEoHUohDtZLQ3AanDK64D6qus+QY5kwY0Vf074FGLIJ
	mSkT690KuwX3cTsJiy5n61jBZ+Q8YzQDoR1S9sXCLDQcoIFyWa0sKhYejiPLkV1JLy
	Y0/FXZyxmYDNnTxV86K3X31HcX1knj4HHmD9kHUs=
Mime-Version: 1.0 (Apple Message framework v1257)
From: Kris <kris@theendless.org>
In-Reply-To: <1328793091.6133.170.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 10:16:49 -0500
Message-Id: <33BCF8E1-F585-48BF-8AA4-AF8881FDBB9B@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
	<1328793091.6133.170.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
	with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,

Thanks so much for the response.

The guest kernel is 2.6.32-71.29.1.el6.x86_64 on a CentOS 6.0 system. 

However, this happens on other versions of the kernel on a CentOS 5.X system. I've had it happen *anecdotally* on systems from CentOS 5.0-6.0.

I'll try to replicate this and attempt to issue 'xenstore-ls -fp'.

If there's anything else you or anyone can think of, please recommend them. Especially some sort of explanation of what those integers mean in the network-list?

Thanks again,
Kris



On 2012-02-09, at 8:11 AM, Ian Campbell wrote:

> On Wed, 2012-02-08 at 19:44 +0000, Kris wrote:
>> Hi,
>> 
>> I've been experiencing some issues with Xen-3.4.2-2.el5 (from gitco)
>> on CentOS 5.4 when migrating nodes from one physical node to another.
>> Each VM has 3 network interfaces (vifs).
>> 
>> When doing a live migration (xm migrate --live <params>) the network
>> of the migrated VM seems to go in to a very odd state when it's done
>> migrating. I've searched high and low for some documentation on what
>> the state, evt-ch,tx-/rx-ring-ref fields mean with their particular
>> integer values, but 1,-1,-1/-1 respectively seems to be indicative of
>> something that has gone badly. A state of 4 seems to indicate that the
>> interface is in a working state.
>> 
>> When doing a xm network-list VM on the node it is being migrated *to*
>> - in this case all of them are broken, but sometimes it's just one or
>> two interfaces are in this state.:
>> Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
>> 0   0  <REDACTED>   0     1      -1    -1   /-1      /local/domain/0/backend/vif/2/0  
>> 1   0  <REDACTED>    1     1      -1    -1   /-1      /local/domain/0/backend/vif/2/1  
>> 2   0  <REDACTED>    2     1      -1    -1   /-1      /local/domain/0/backend/vif/2/2
>> 
>> The result is that the network interfaces with the output above do not
>> work.
>> 
>> Is there anything I can do to perhaps debug this better? Is there any
>> documentation I'm missing out that would explain this stuff? Any
>> troubleshooting help is appreciated. I've looked at the xend logs and
>> there doesn't seem to be anything indicative of why this is occurring.
> 
> There's a good chance this is a guest kernel issue. What sort of guests
> are they and what kernel version are they running? Is there anything in
> the guest kernel logs or on the guest console?
> 
> The output of "xenstore-ls -fp" after this has happened would also be
> potentially interesting.
> 
> Ian.
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:17:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVjx-0001YP-Ss; Thu, 09 Feb 2012 15:16:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kris@theendless.org>) id 1RvVjx-0001YH-0R
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:16:53 +0000
X-Env-Sender: kris@theendless.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328800587!52251809!1
X-Originating-IP: [72.51.30.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19901 invoked from network); 9 Feb 2012 15:16:28 -0000
Received: from theendless.org (HELO mail.theendless.org) (72.51.30.5)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 15:16:28 -0000
Received: by mail.theendless.org (Postfix, from userid 102)
	id 28705DC8002; Thu,  9 Feb 2012 10:16:50 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on theendless.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE
	autolearn=no version=3.2.5
Received: from [192.168.20.24] (unknown [96.45.197.22])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by mail.theendless.org (Postfix) with ESMTP id B9A41DC8001;
	Thu,  9 Feb 2012 10:16:49 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theendless.org;
	s=02012012; t=1328800609;
	bh=1zN2xXWfEmZUh/Uyg2MrLDXzwMM+D19Awx+wDelZZQo=;
	h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:
	Content-Transfer-Encoding:Message-Id:References:To;
	b=NCUkNJl9Q8D6dbjgc80rWgjEoHUohDtZLQ3AanDK64D6qus+QY5kwY0Vf074FGLIJ
	mSkT690KuwX3cTsJiy5n61jBZ+Q8YzQDoR1S9sXCLDQcoIFyWa0sKhYejiPLkV1JLy
	Y0/FXZyxmYDNnTxV86K3X31HcX1knj4HHmD9kHUs=
Mime-Version: 1.0 (Apple Message framework v1257)
From: Kris <kris@theendless.org>
In-Reply-To: <1328793091.6133.170.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 10:16:49 -0500
Message-Id: <33BCF8E1-F585-48BF-8AA4-AF8881FDBB9B@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
	<1328793091.6133.170.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
	with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,

Thanks so much for the response.

The guest kernel is 2.6.32-71.29.1.el6.x86_64 on a CentOS 6.0 system. 

However, this happens on other versions of the kernel on a CentOS 5.X system. I've had it happen *anecdotally* on systems from CentOS 5.0-6.0.

I'll try to replicate this and attempt to issue 'xenstore-ls -fp'.

If there's anything else you or anyone can think of, please recommend them. Especially some sort of explanation of what those integers mean in the network-list?

Thanks again,
Kris



On 2012-02-09, at 8:11 AM, Ian Campbell wrote:

> On Wed, 2012-02-08 at 19:44 +0000, Kris wrote:
>> Hi,
>> 
>> I've been experiencing some issues with Xen-3.4.2-2.el5 (from gitco)
>> on CentOS 5.4 when migrating nodes from one physical node to another.
>> Each VM has 3 network interfaces (vifs).
>> 
>> When doing a live migration (xm migrate --live <params>) the network
>> of the migrated VM seems to go in to a very odd state when it's done
>> migrating. I've searched high and low for some documentation on what
>> the state, evt-ch,tx-/rx-ring-ref fields mean with their particular
>> integer values, but 1,-1,-1/-1 respectively seems to be indicative of
>> something that has gone badly. A state of 4 seems to indicate that the
>> interface is in a working state.
>> 
>> When doing a xm network-list VM on the node it is being migrated *to*
>> - in this case all of them are broken, but sometimes it's just one or
>> two interfaces are in this state.:
>> Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
>> 0   0  <REDACTED>   0     1      -1    -1   /-1      /local/domain/0/backend/vif/2/0  
>> 1   0  <REDACTED>    1     1      -1    -1   /-1      /local/domain/0/backend/vif/2/1  
>> 2   0  <REDACTED>    2     1      -1    -1   /-1      /local/domain/0/backend/vif/2/2
>> 
>> The result is that the network interfaces with the output above do not
>> work.
>> 
>> Is there anything I can do to perhaps debug this better? Is there any
>> documentation I'm missing out that would explain this stuff? Any
>> troubleshooting help is appreciated. I've looked at the xend logs and
>> there doesn't seem to be anything indicative of why this is occurring.
> 
> There's a good chance this is a guest kernel issue. What sort of guests
> are they and what kernel version are they running? Is there anything in
> the guest kernel logs or on the guest console?
> 
> The output of "xenstore-ls -fp" after this has happened would also be
> potentially interesting.
> 
> Ian.
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:17:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:17:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVkE-0001Zn-9o; Thu, 09 Feb 2012 15:17:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvVkD-0001ZC-BG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:17:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328800622!14114590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8234 invoked from network); 9 Feb 2012 15:17:02 -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;
	9 Feb 2012 15:17:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:15:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:15:59 +0000
Date: Thu, 9 Feb 2012 15:19:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328798113 0
> # Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
> # Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
> arm: define stub arch_dump_shared_mem_info
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
> --- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
> +++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
> @@ -1,4 +1,4 @@
> -/*
> + /*
>   * xen/arch/arm/mm.c
>   *
>   * MMU code for an ARMv7-A with virt extensions.

I don't mean to be pedantic, but this change breaks the comment indentation


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:17:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:17:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVkE-0001Zn-9o; Thu, 09 Feb 2012 15:17:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvVkD-0001ZC-BG
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:17:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328800622!14114590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8234 invoked from network); 9 Feb 2012 15:17:02 -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;
	9 Feb 2012 15:17:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:15:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:15:59 +0000
Date: Thu, 9 Feb 2012 15:19:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328798113 0
> # Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
> # Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
> arm: define stub arch_dump_shared_mem_info
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
> --- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
> +++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
> @@ -1,4 +1,4 @@
> -/*
> + /*
>   * xen/arch/arm/mm.c
>   *
>   * MMU code for an ARMv7-A with virt extensions.

I don't mean to be pedantic, but this change breaks the comment indentation


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:18:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVkt-0001fG-Og; Thu, 09 Feb 2012 15:17:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvVks-0001eH-3U
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:17:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328800664!14114738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11355 invoked from network); 9 Feb 2012 15:17:44 -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;
	9 Feb 2012 15:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602134"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:17:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:17:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvVkl-0003es-Sw; Thu, 09 Feb 2012 15:17:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvVkl-0005kL-SA;
	Thu, 09 Feb 2012 15:17:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.58263.859206.482623@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:17:43 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> I wasn't aware of this file.  After a brief look, it seems there is
> information missing from both vbd-interface.txt and blkif.h.  Per
> vbd-interface.txt, there is also an error in blkif.h.  The "virtual-device"
> node must tolerate 32bit integers.
> 
> I'll fix the size specification for the "virtual-device" node, but how
> should I reconcile blkif.h and vbd-interface.txt.  I hate information
> duplication since one version is invariably stale.

I wrote vbd-interface.txt and I think it's largely accurate.  I wasn't
aware of any duplication with blkif.h.  If there are differences then
we will have to discuss them here I think, or read the code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:18:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVkt-0001fG-Og; Thu, 09 Feb 2012 15:17:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvVks-0001eH-3U
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:17:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328800664!14114738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11355 invoked from network); 9 Feb 2012 15:17:44 -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;
	9 Feb 2012 15:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602134"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:17:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:17:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvVkl-0003es-Sw; Thu, 09 Feb 2012 15:17:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvVkl-0005kL-SA;
	Thu, 09 Feb 2012 15:17:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.58263.859206.482623@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:17:43 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> I wasn't aware of this file.  After a brief look, it seems there is
> information missing from both vbd-interface.txt and blkif.h.  Per
> vbd-interface.txt, there is also an error in blkif.h.  The "virtual-device"
> node must tolerate 32bit integers.
> 
> I'll fix the size specification for the "virtual-device" node, but how
> should I reconcile blkif.h and vbd-interface.txt.  I hate information
> duplication since one version is invariably stale.

I wrote vbd-interface.txt and I think it's largely accurate.  I wasn't
aware of any duplication with blkif.h.  If there are differences then
we will have to discuss them here I think, or read the code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVms-0001xI-FU; Thu, 09 Feb 2012 15:19: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 1RvVmr-0001x5-0j
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:19:53 +0000
Received: from [85.158.139.83:36998] by server-11.bemta-5.messagelabs.com id
	24/A3-13907-814E33F4; Thu, 09 Feb 2012 15:19:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328800788!14404413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29047 invoked from network); 9 Feb 2012 15:19:51 -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;
	9 Feb 2012 15:19:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:19:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:19:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvVmM-0003fP-6P; Thu, 09 Feb 2012 15:19:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvVmM-0005mG-5c;
	Thu, 09 Feb 2012 15:19:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.58362.161262.627919@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:19:22 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
	<20273.25747.542056.575794@mariner.uk.xensource.com>
	<0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
> On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:
> > Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
> >> + * params
> >> + *      Values:         string
> > 
> > this is not intended for use by guests and they should not look at it.
> 
> Guests can export back-end devices.  Here at Spectra we do this all the
> time. :-)

Sorry, I meant, not intended for use by frontends.  I was using
"guest" as a shorthand for that.

> It would be hard to implement a blkback driver without this information.
> The comment at the top of your email implies you're okay with it being
> in this file, but that I should mark "local-end use only" nodes?

Certainly I think it would be good to document this somewhere and here
is as good as any.

> >> + * virtual-device
> >> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> > 
> > This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> > this also encoded in the device path in xenstore ?
> 
> It would appear so.  Should this path naming convention be mandated by
> this file?  Since "virtual-device" exists, it seems that front-ends should
> read it, not parse the path, to determine this information.

Do we know what current frontends actually do ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVms-0001xI-FU; Thu, 09 Feb 2012 15:19: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 1RvVmr-0001x5-0j
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:19:53 +0000
Received: from [85.158.139.83:36998] by server-11.bemta-5.messagelabs.com id
	24/A3-13907-814E33F4; Thu, 09 Feb 2012 15:19:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328800788!14404413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29047 invoked from network); 9 Feb 2012 15:19:51 -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;
	9 Feb 2012 15:19:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:19:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:19:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvVmM-0003fP-6P; Thu, 09 Feb 2012 15:19:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvVmM-0005mG-5c;
	Thu, 09 Feb 2012 15:19:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.58362.161262.627919@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:19:22 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<a1b6e68ff241424d1a9a.1328246660@ns1.eng.sldomain.com>
	<20273.25747.542056.575794@mariner.uk.xensource.com>
	<0BDA8075-618D-4AE7-BF4E-5A81976D3ECC@spectralogic.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
> On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:
> > Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface"):
> >> + * params
> >> + *      Values:         string
> > 
> > this is not intended for use by guests and they should not look at it.
> 
> Guests can export back-end devices.  Here at Spectra we do this all the
> time. :-)

Sorry, I meant, not intended for use by frontends.  I was using
"guest" as a shorthand for that.

> It would be hard to implement a blkback driver without this information.
> The comment at the top of your email implies you're okay with it being
> in this file, but that I should mark "local-end use only" nodes?

Certainly I think it would be good to document this somewhere and here
is as good as any.

> >> + * virtual-device
> >> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> > 
> > This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> > this also encoded in the device path in xenstore ?
> 
> It would appear so.  Should this path naming convention be mandated by
> this file?  Since "virtual-device" exists, it seems that front-ends should
> read it, not parse the path, to determine this information.

Do we know what current frontends actually do ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:21:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVoW-00029m-W2; Thu, 09 Feb 2012 15:21:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVoV-000296-6L
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:21:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328800888!10850647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30412 invoked from network); 9 Feb 2012 15:21:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:21:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:21:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:21:28 +0000
Message-ID: <1328800887.6133.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:21:27 +0000
In-Reply-To: <alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:18 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1328798112 0
> > # Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
> > # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> > arm: define domain_pirq_to_irq
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
> > --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> > +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
> > @@ -11,6 +11,7 @@ typedef struct {
> >  
> >  struct arch_pirq
> >  {
> > +    int irq;
> >  };
> >  
> >  struct irq_cfg {
> > @@ -19,6 +20,8 @@ struct irq_cfg {
> >  
> >  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
> >  
> > +#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
> > +
> >  #endif /* _ASM_HW_IRQ_H */
> >  /*
> >   * Local variables:
> > 
> 
> At the moment we don't have a reason for having pirq != irq so we could
> just return irq, like ia64 does.

Good idea.

> Otherwise I expect that we would need code to set arch.irq = pirq that
> at the moment we don't have.

Yes.

8<-----------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328800759 0
# Node ID daa129cac86315bad066f4c358bd02817985a8df
# Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
arm: define domain_pirq_to_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 18b9ea53c8ac -r daa129cac863 xen/include/asm-arm/irq.h
--- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
+++ b/xen/include/asm-arm/irq.h	Thu Feb 09 15:19:19 2012 +0000
@@ -19,6 +19,8 @@ struct irq_cfg {
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
 
+#define domain_pirq_to_irq(d, pirq) (pirq)
+
 #endif /* _ASM_HW_IRQ_H */
 /*
  * Local variables:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:21:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVoW-00029m-W2; Thu, 09 Feb 2012 15:21:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVoV-000296-6L
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:21:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328800888!10850647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30412 invoked from network); 9 Feb 2012 15:21:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:21:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:21:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:21:28 +0000
Message-ID: <1328800887.6133.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:21:27 +0000
In-Reply-To: <alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:18 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1328798112 0
> > # Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
> > # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> > arm: define domain_pirq_to_irq
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
> > --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> > +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
> > @@ -11,6 +11,7 @@ typedef struct {
> >  
> >  struct arch_pirq
> >  {
> > +    int irq;
> >  };
> >  
> >  struct irq_cfg {
> > @@ -19,6 +20,8 @@ struct irq_cfg {
> >  
> >  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
> >  
> > +#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
> > +
> >  #endif /* _ASM_HW_IRQ_H */
> >  /*
> >   * Local variables:
> > 
> 
> At the moment we don't have a reason for having pirq != irq so we could
> just return irq, like ia64 does.

Good idea.

> Otherwise I expect that we would need code to set arch.irq = pirq that
> at the moment we don't have.

Yes.

8<-----------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328800759 0
# Node ID daa129cac86315bad066f4c358bd02817985a8df
# Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
arm: define domain_pirq_to_irq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 18b9ea53c8ac -r daa129cac863 xen/include/asm-arm/irq.h
--- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
+++ b/xen/include/asm-arm/irq.h	Thu Feb 09 15:19:19 2012 +0000
@@ -19,6 +19,8 @@ struct irq_cfg {
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
 
+#define domain_pirq_to_irq(d, pirq) (pirq)
+
 #endif /* _ASM_HW_IRQ_H */
 /*
  * Local variables:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:22:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVpF-0002GN-EC; Thu, 09 Feb 2012 15:22:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVpD-0002Eo-Hy
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:22:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328800931!12647004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28578 invoked from network); 9 Feb 2012 15:22:11 -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;
	9 Feb 2012 15:22:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:22:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:22:11 +0000
Message-ID: <1328800930.6133.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:22:10 +0000
In-Reply-To: <alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:19 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1328798113 0
> > # Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
> > # Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
> > arm: define stub arch_dump_shared_mem_info
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
> > --- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
> > +++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
> > @@ -1,4 +1,4 @@
> > -/*
> > + /*
> >   * xen/arch/arm/mm.c
> >   *
> >   * MMU code for an ARMv7-A with virt extensions.
> 
> I don't mean to be pedantic, but this change breaks the comment indentation

Pedantic is good. I accidentally typed something unrelated in the wrong
window and didn't clean up quite enough, I should've looked more closely
at the diff before posting. Fixed version below.

8<-------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328800790 0
# Node ID 2f3d6a6626146c851f5b56aa84d23237cd46d795
# Parent  daa129cac86315bad066f4c358bd02817985a8df
arm: define stub arch_dump_shared_mem_info

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r daa129cac863 -r 2f3d6a662614 xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 09 15:19:19 2012 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 09 15:19:50 2012 +0000
@@ -311,6 +311,10 @@ void __init setup_frametable_mappings(pa
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:22:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVpF-0002GN-EC; Thu, 09 Feb 2012 15:22:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVpD-0002Eo-Hy
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:22:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328800931!12647004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28578 invoked from network); 9 Feb 2012 15:22:11 -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;
	9 Feb 2012 15:22:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:22:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:22:11 +0000
Message-ID: <1328800930.6133.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:22:10 +0000
In-Reply-To: <alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:19 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1328798113 0
> > # Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
> > # Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
> > arm: define stub arch_dump_shared_mem_info
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
> > --- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
> > +++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
> > @@ -1,4 +1,4 @@
> > -/*
> > + /*
> >   * xen/arch/arm/mm.c
> >   *
> >   * MMU code for an ARMv7-A with virt extensions.
> 
> I don't mean to be pedantic, but this change breaks the comment indentation

Pedantic is good. I accidentally typed something unrelated in the wrong
window and didn't clean up quite enough, I should've looked more closely
at the diff before posting. Fixed version below.

8<-------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328800790 0
# Node ID 2f3d6a6626146c851f5b56aa84d23237cd46d795
# Parent  daa129cac86315bad066f4c358bd02817985a8df
arm: define stub arch_dump_shared_mem_info

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r daa129cac863 -r 2f3d6a662614 xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 09 15:19:19 2012 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 09 15:19:50 2012 +0000
@@ -311,6 +311,10 @@ void __init setup_frametable_mappings(pa
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:22:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVpX-0002JN-SV; Thu, 09 Feb 2012 15:22:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVpX-0002ID-3V
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:22:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328800949!10824864!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2455 invoked from network); 9 Feb 2012 15:22:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:22:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:22:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:22:29 +0000
Message-ID: <1328800947.6133.193.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 9 Feb 2012 15:22:27 +0000
In-Reply-To: <1328795829465-5469490.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
	<1328782971857-5469072.post@n5.nabble.com>
	<1328784596.6133.141.camel@zakaz.uk.xensource.com>
	<1328795829465-5469490.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 13:57 +0000, Fantu wrote:
> Thanks
> 
> I have rebuild xen to latest revistion, now:
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b
> 
> --------------------------------
> DomU Mint 11 (based on Natty - Ubuntu 11.04):
> udev           167-0ubuntu3
> linux-image-2.6.38-8-generic           2.6.38-8.42

I wonder if this kernel is missing:
        commit 4352b47ab7918108b389a48d2163c9a4c2aaf139
        Author: Marek Marczykowski <marmarek@mimuw.edu.pl>
        Date:   Tue May 3 12:04:52 2011 -0400
        
            xen-blkfront: fix data size for xenbus_gather in blkfront_connect
            
            barrier variable is int, not long. This overflow caused another variable
            override: "err" (in PV code) and "binfo" (in xenlinux code -
            drivers/xen/blkfront/blkfront.c). The later caused incorrect device
            flags (RO/removable etc).
            
            Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
            Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
            [v1: Changed title]
            Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
        
The symptoms of this could include a device not appearing as a cdrom
when it should. Your xenstore output contains 
        /local/domain/0/backend/vbd/1/51728/device-type = "cdrom"
        (n0,r1)
but the CDROM_GET_CAPABILITY ioctl is failing which is somewhat
consistent with this.

> 
> 
> With iso cdrom, on xl file configuration:
> '/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom' 
> 
> udevadm info --query=all --path /block/xvdb
> P: /devices/vbd-51728/block/xvdb
> N: xvdb
> S: disk/by-path/xen-vbd-51728
> S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
> E: UDEV_LOG=3
> E: DEVPATH=/devices/vbd-51728/block/xvdb
> E: MAJOR=202
> E: MINOR=16
> E: DEVNAME=/dev/xvdb
> E: DEVTYPE=disk
> E: SUBSYSTEM=block
> E: ID_PATH=xen-vbd-51728
> E: ID_PART_TABLE_TYPE=dos
> E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
> E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
> E: ID_FS_TYPE=iso9660
> E: ID_FS_USAGE=filesystem
> E: UDISKS_PRESENTATION_NOPOLICY=1
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
> /dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
> 
> /lib/udev/cdrom_id /dev/xvdb
> Give no output
> 
> In attachment there are complete output of xenstore-ls and strace of
> cdrom_id
> http://xen.1045712.n5.nabble.com/file/n5469490/MINT11.txt MINT11.txt 
> With strace I see how cdrom capability is at 0
> --------------------------------
> 
> --------------------------------
> DomU Mint 12 (based on Oneiric - Ubuntu 11.10):
> udev           173-0ubuntu4.1
> linux-image-3.0.0-13-generic           3.0.0-13.22 
> 
> With iso cdrom, on xl file configuration:
> '/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'
> 
> udevadm info --query=all --path /block/xvdb
> P: /devices/vbd-51728/block/xvdb
> N: xvdb
> S: disk/by-path/xen-vbd-51728
> S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
> S: cdrom
> E: UDEV_LOG=3
> E: DEVPATH=/devices/vbd-51728/block/xvdb
> E: MAJOR=202
> E: MINOR=16
> E: DEVNAME=/dev/xvdb
> E: DEVTYPE=disk
> E: SUBSYSTEM=block
> E: ID_CDROM=1
> E: ID_PATH=xen-vbd-51728
> E: ID_PATH_TAG=xen-vbd-51728
> E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
> E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
> E: ID_FS_TYPE=iso9660
> E: ID_FS_USAGE=filesystem
> E: ID_PART_TABLE_TYPE=dos
> E: GENERATED=1
> E: UDISKS_PRESENTATION_NOPOLICY=1
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
> /dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom
> E: TAGS=:udev-acl:
> 
> /lib/udev/cdrom_id /dev/xvdb
> ID_CDROM=1
> 
> In attachment there are complete output of xenstore-ls
> http://xen.1045712.n5.nabble.com/file/n5469490/MINT12.txt MINT12.txt 
> --------------------------------
> 
> Soon I'll try again next version of Ubuntu now in  alpha status (12.04 LTS)
> and if the problem about cdrom is of distribution I will report it on
> launchpad, I had already searched the forums and launchpad about it without
> getting resolved.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5469490.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:22:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVpX-0002JN-SV; Thu, 09 Feb 2012 15:22:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVpX-0002ID-3V
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:22:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328800949!10824864!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2455 invoked from network); 9 Feb 2012 15:22:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:22:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:22:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:22:29 +0000
Message-ID: <1328800947.6133.193.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 9 Feb 2012 15:22:27 +0000
In-Reply-To: <1328795829465-5469490.post@n5.nabble.com>
References: <1328538755451-5460198.post@n5.nabble.com>
	<1328712798.6133.48.camel@zakaz.uk.xensource.com>
	<1328782971857-5469072.post@n5.nabble.com>
	<1328784596.6133.141.camel@zakaz.uk.xensource.com>
	<1328795829465-5469490.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 13:57 +0000, Fantu wrote:
> Thanks
> 
> I have rebuild xen to latest revistion, now:
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b
> 
> --------------------------------
> DomU Mint 11 (based on Natty - Ubuntu 11.04):
> udev           167-0ubuntu3
> linux-image-2.6.38-8-generic           2.6.38-8.42

I wonder if this kernel is missing:
        commit 4352b47ab7918108b389a48d2163c9a4c2aaf139
        Author: Marek Marczykowski <marmarek@mimuw.edu.pl>
        Date:   Tue May 3 12:04:52 2011 -0400
        
            xen-blkfront: fix data size for xenbus_gather in blkfront_connect
            
            barrier variable is int, not long. This overflow caused another variable
            override: "err" (in PV code) and "binfo" (in xenlinux code -
            drivers/xen/blkfront/blkfront.c). The later caused incorrect device
            flags (RO/removable etc).
            
            Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
            Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
            [v1: Changed title]
            Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
        
The symptoms of this could include a device not appearing as a cdrom
when it should. Your xenstore output contains 
        /local/domain/0/backend/vbd/1/51728/device-type = "cdrom"
        (n0,r1)
but the CDROM_GET_CAPABILITY ioctl is failing which is somewhat
consistent with this.

> 
> 
> With iso cdrom, on xl file configuration:
> '/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom' 
> 
> udevadm info --query=all --path /block/xvdb
> P: /devices/vbd-51728/block/xvdb
> N: xvdb
> S: disk/by-path/xen-vbd-51728
> S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
> E: UDEV_LOG=3
> E: DEVPATH=/devices/vbd-51728/block/xvdb
> E: MAJOR=202
> E: MINOR=16
> E: DEVNAME=/dev/xvdb
> E: DEVTYPE=disk
> E: SUBSYSTEM=block
> E: ID_PATH=xen-vbd-51728
> E: ID_PART_TABLE_TYPE=dos
> E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
> E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
> E: ID_FS_TYPE=iso9660
> E: ID_FS_USAGE=filesystem
> E: UDISKS_PRESENTATION_NOPOLICY=1
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
> /dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
> 
> /lib/udev/cdrom_id /dev/xvdb
> Give no output
> 
> In attachment there are complete output of xenstore-ls and strace of
> cdrom_id
> http://xen.1045712.n5.nabble.com/file/n5469490/MINT11.txt MINT11.txt 
> With strace I see how cdrom capability is at 0
> --------------------------------
> 
> --------------------------------
> DomU Mint 12 (based on Oneiric - Ubuntu 11.10):
> udev           173-0ubuntu4.1
> linux-image-3.0.0-13-generic           3.0.0-13.22 
> 
> With iso cdrom, on xl file configuration:
> '/mnt/vm/iso/precise.iso,raw,xvdb,ro,cdrom'
> 
> udevadm info --query=all --path /block/xvdb
> P: /devices/vbd-51728/block/xvdb
> N: xvdb
> S: disk/by-path/xen-vbd-51728
> S: disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64
> S: cdrom
> E: UDEV_LOG=3
> E: DEVPATH=/devices/vbd-51728/block/xvdb
> E: MAJOR=202
> E: MINOR=16
> E: DEVNAME=/dev/xvdb
> E: DEVTYPE=disk
> E: SUBSYSTEM=block
> E: ID_CDROM=1
> E: ID_PATH=xen-vbd-51728
> E: ID_PATH_TAG=xen-vbd-51728
> E: ID_FS_LABEL=Ubuntu_12.04_LTS_amd64
> E: ID_FS_LABEL_ENC=Ubuntu\x2012.04\x20LTS\x20amd64
> E: ID_FS_TYPE=iso9660
> E: ID_FS_USAGE=filesystem
> E: ID_PART_TABLE_TYPE=dos
> E: GENERATED=1
> E: UDISKS_PRESENTATION_NOPOLICY=1
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51728
> /dev/disk/by-label/Ubuntu\x2012.04\x20LTS\x20amd64 /dev/cdrom
> E: TAGS=:udev-acl:
> 
> /lib/udev/cdrom_id /dev/xvdb
> ID_CDROM=1
> 
> In attachment there are complete output of xenstore-ls
> http://xen.1045712.n5.nabble.com/file/n5469490/MINT12.txt MINT12.txt 
> --------------------------------
> 
> Soon I'll try again next version of Ubuntu now in  alpha status (12.04 LTS)
> and if the problem about cdrom is of distribution I will report it on
> launchpad, I had already searched the forums and launchpad about it without
> getting resolved.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5460198p5469490.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:23:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVpf-0002LO-A2; Thu, 09 Feb 2012 15:22:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvVpe-0002Jd-2p
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:22:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328800959!12715511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29120 invoked from network); 9 Feb 2012 15:22:40 -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;
	9 Feb 2012 15:22:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:22:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:22:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvVpW-0003hF-V5; Thu, 09 Feb 2012 15:22:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvVpW-0005pk-UF;
	Thu, 09 Feb 2012 15:22:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.58558.925282.788540@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:22:38 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> - we can reuse the "state" based mechanism to establish a connection:
> again not a great protocol, but very well known and understood.

I don't think we have, in general, a good understanding of these
"state" based protocols ...

Also for an internal mechanism I think we should have something
autogenerated so avoid having lots of handwritten parsing/emitting code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:23:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVpf-0002LO-A2; Thu, 09 Feb 2012 15:22:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvVpe-0002Jd-2p
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:22:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328800959!12715511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29120 invoked from network); 9 Feb 2012 15:22:40 -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;
	9 Feb 2012 15:22:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:22:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:22:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvVpW-0003hF-V5; Thu, 09 Feb 2012 15:22:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvVpW-0005pk-UF;
	Thu, 09 Feb 2012 15:22:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.58558.925282.788540@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:22:38 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> - we can reuse the "state" based mechanism to establish a connection:
> again not a great protocol, but very well known and understood.

I don't think we have, in general, a good understanding of these
"state" based protocols ...

Also for an internal mechanism I think we should have something
autogenerated so avoid having lots of handwritten parsing/emitting code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:25:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvVrk-0002ku-T4; Thu, 09 Feb 2012 15:24:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvVrj-0002jy-HI
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:24:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328801089!12681399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21347 invoked from network); 9 Feb 2012 15:24:49 -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;
	9 Feb 2012 15:24:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:24:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:24:43 +0000
Date: Thu, 9 Feb 2012 15:28:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328800887.6133.191.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091527190.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
	<1328800887.6133.191.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 15:18 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1328798112 0
> > > # Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
> > > # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> > > arm: define domain_pirq_to_irq
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
> > > --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> > > +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
> > > @@ -11,6 +11,7 @@ typedef struct {
> > >  
> > >  struct arch_pirq
> > >  {
> > > +    int irq;
> > >  };
> > >  
> > >  struct irq_cfg {
> > > @@ -19,6 +20,8 @@ struct irq_cfg {
> > >  
> > >  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
> > >  
> > > +#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
> > > +
> > >  #endif /* _ASM_HW_IRQ_H */
> > >  /*
> > >   * Local variables:
> > > 
> > 
> > At the moment we don't have a reason for having pirq != irq so we could
> > just return irq, like ia64 does.
> 
> Good idea.
> 
> > Otherwise I expect that we would need code to set arch.irq = pirq that
> > at the moment we don't have.
> 
> Yes.
> 
> 8<-----------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328800759 0
> # Node ID daa129cac86315bad066f4c358bd02817985a8df
> # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> arm: define domain_pirq_to_irq
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

ack

> diff -r 18b9ea53c8ac -r daa129cac863 xen/include/asm-arm/irq.h
> --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 15:19:19 2012 +0000
> @@ -19,6 +19,8 @@ struct irq_cfg {
>  
>  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
>  
> +#define domain_pirq_to_irq(d, pirq) (pirq)
> +
>  #endif /* _ASM_HW_IRQ_H */
>  /*
>   * Local variables:
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:25:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 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.xensource.com>)
	id 1RvVrk-0002ku-T4; Thu, 09 Feb 2012 15:24:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvVrj-0002jy-HI
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:24:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328801089!12681399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21347 invoked from network); 9 Feb 2012 15:24:49 -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;
	9 Feb 2012 15:24:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602461"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:24:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:24:43 +0000
Date: Thu, 9 Feb 2012 15:28:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328800887.6133.191.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091527190.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
	<1328800887.6133.191.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 15:18 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1328798112 0
> > > # Node ID abd72cc240fa3d643541d435f3cb72b75c8a5977
> > > # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> > > arm: define domain_pirq_to_irq
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > diff -r 18b9ea53c8ac -r abd72cc240fa xen/include/asm-arm/irq.h
> > > --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> > > +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 14:35:12 2012 +0000
> > > @@ -11,6 +11,7 @@ typedef struct {
> > >  
> > >  struct arch_pirq
> > >  {
> > > +    int irq;
> > >  };
> > >  
> > >  struct irq_cfg {
> > > @@ -19,6 +20,8 @@ struct irq_cfg {
> > >  
> > >  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
> > >  
> > > +#define domain_pirq_to_irq(d, pirq) pirq_field(d, pirq, arch.irq)
> > > +
> > >  #endif /* _ASM_HW_IRQ_H */
> > >  /*
> > >   * Local variables:
> > > 
> > 
> > At the moment we don't have a reason for having pirq != irq so we could
> > just return irq, like ia64 does.
> 
> Good idea.
> 
> > Otherwise I expect that we would need code to set arch.irq = pirq that
> > at the moment we don't have.
> 
> Yes.
> 
> 8<-----------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328800759 0
> # Node ID daa129cac86315bad066f4c358bd02817985a8df
> # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> arm: define domain_pirq_to_irq
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

ack

> diff -r 18b9ea53c8ac -r daa129cac863 xen/include/asm-arm/irq.h
> --- a/xen/include/asm-arm/irq.h	Thu Feb 09 11:33:30 2012 +0000
> +++ b/xen/include/asm-arm/irq.h	Thu Feb 09 15:19:19 2012 +0000
> @@ -19,6 +19,8 @@ struct irq_cfg {
>  
>  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
>  
> +#define domain_pirq_to_irq(d, pirq) (pirq)
> +
>  #endif /* _ASM_HW_IRQ_H */
>  /*
>   * Local variables:
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:25:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVs3-0002oU-AO; Thu, 09 Feb 2012 15:25: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 1RvVs1-0002o5-SJ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:25:14 +0000
Received: from [85.158.139.83:16306] by server-6.bemta-5.messagelabs.com id
	ED/4C-04784-955E33F4; Thu, 09 Feb 2012 15:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328801112!14328033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13917 invoked from network); 9 Feb 2012 15:25:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:25:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:25:12 +0000
Date: Thu, 9 Feb 2012 15:28:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328800930.6133.192.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091528300.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
	<1328800930.6133.192.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 15:19 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1328798113 0
> > > # Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
> > > # Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
> > > arm: define stub arch_dump_shared_mem_info
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
> > > --- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
> > > +++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
> > > @@ -1,4 +1,4 @@
> > > -/*
> > > + /*
> > >   * xen/arch/arm/mm.c
> > >   *
> > >   * MMU code for an ARMv7-A with virt extensions.
> > 
> > I don't mean to be pedantic, but this change breaks the comment indentation
> 
> Pedantic is good. I accidentally typed something unrelated in the wrong
> window and didn't clean up quite enough, I should've looked more closely
> at the diff before posting. Fixed version below.
> 
> 8<-------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328800790 0
> # Node ID 2f3d6a6626146c851f5b56aa84d23237cd46d795
> # Parent  daa129cac86315bad066f4c358bd02817985a8df
> arm: define stub arch_dump_shared_mem_info

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r daa129cac863 -r 2f3d6a662614 xen/arch/arm/mm.c
> --- a/xen/arch/arm/mm.c	Thu Feb 09 15:19:19 2012 +0000
> +++ b/xen/arch/arm/mm.c	Thu Feb 09 15:19:50 2012 +0000
> @@ -311,6 +311,10 @@ void __init setup_frametable_mappings(pa
>      frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
>  }
>  
> +void arch_dump_shared_mem_info(void)
> +{
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:25:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVs3-0002oU-AO; Thu, 09 Feb 2012 15:25: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 1RvVs1-0002o5-SJ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:25:14 +0000
Received: from [85.158.139.83:16306] by server-6.bemta-5.messagelabs.com id
	ED/4C-04784-955E33F4; Thu, 09 Feb 2012 15:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328801112!14328033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13917 invoked from network); 9 Feb 2012 15:25:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:25:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:25:12 +0000
Date: Thu, 9 Feb 2012 15:28:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328800930.6133.192.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091528300.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<565c304be85a6b28e6c1.1328799206@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091508180.22056@kaball-desktop>
	<1328800930.6133.192.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define stub arch_dump_shared_mem_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 15:19 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1328798113 0
> > > # Node ID 565c304be85a6b28e6c12c9f849c07f6ee138aa4
> > > # Parent  abd72cc240fa3d643541d435f3cb72b75c8a5977
> > > arm: define stub arch_dump_shared_mem_info
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > diff -r abd72cc240fa -r 565c304be85a xen/arch/arm/mm.c
> > > --- a/xen/arch/arm/mm.c	Thu Feb 09 14:35:12 2012 +0000
> > > +++ b/xen/arch/arm/mm.c	Thu Feb 09 14:35:13 2012 +0000
> > > @@ -1,4 +1,4 @@
> > > -/*
> > > + /*
> > >   * xen/arch/arm/mm.c
> > >   *
> > >   * MMU code for an ARMv7-A with virt extensions.
> > 
> > I don't mean to be pedantic, but this change breaks the comment indentation
> 
> Pedantic is good. I accidentally typed something unrelated in the wrong
> window and didn't clean up quite enough, I should've looked more closely
> at the diff before posting. Fixed version below.
> 
> 8<-------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1328800790 0
> # Node ID 2f3d6a6626146c851f5b56aa84d23237cd46d795
> # Parent  daa129cac86315bad066f4c358bd02817985a8df
> arm: define stub arch_dump_shared_mem_info

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r daa129cac863 -r 2f3d6a662614 xen/arch/arm/mm.c
> --- a/xen/arch/arm/mm.c	Thu Feb 09 15:19:19 2012 +0000
> +++ b/xen/arch/arm/mm.c	Thu Feb 09 15:19:50 2012 +0000
> @@ -311,6 +311,10 @@ void __init setup_frametable_mappings(pa
>      frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
>  }
>  
> +void arch_dump_shared_mem_info(void)
> +{
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:28:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVvG-0003Iq-CQ; Thu, 09 Feb 2012 15:28:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RvVvD-0003Ic-Ux
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:28:32 +0000
Received: from [85.158.139.83:39764] by server-10.bemta-5.messagelabs.com id
	FB/B7-26909-F16E33F4; Thu, 09 Feb 2012 15:28:31 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328801310!14405700!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28830 invoked from network); 9 Feb 2012 15:28:30 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-6.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 15:28:30 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q19FSOEe018922;
	Thu, 9 Feb 2012 10:28:24 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q19FSOIe027574;
	Thu, 9 Feb 2012 10:28:24 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020910282301105 ; Thu, 09 Feb 2012 10:28:23 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/mixed; boundary=Apple-Mail-13-454269537
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1328778625.6133.107.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 10:28:23 -0500
Message-Id: <92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
	<1328778625.6133.107.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--Apple-Mail-13-454269537
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ian,

Here is the first patch. There are other unused variable issues not so =
easily fixed, so I am putting them in another patch that should come out =
later today, FWIW.

The changeset id in this patch is bogus. It is based on our own =
Mercurial repo, not Xenbits. The code is from the RedHat source RPM =
xen-4.1.2-2.fc16.src.rpm
----


--Apple-Mail-13-454269537
Content-Disposition: attachment;
	filename=patch01.diff
Content-Type: application/octet-stream;
	name="patch01.diff"
Content-Transfer-Encoding: 7bit

# HG changeset patch
# Parent 3faf3f1c25fc32a74d248778cc2d9d0a567967cd
mini-os: stop compiler complaint about unused variables

gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused variables
in mini-os drivers

Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

diff -r 3faf3f1c25fc extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/blkfront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -171,6 +171,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/console/xencons_ring.c
--- a/extras/mini-os/console/xencons_ring.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/console/xencons_ring.c	Thu Feb 09 09:47:34 2012 -0500
@@ -317,6 +317,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/fbfront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -142,6 +142,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
@@ -503,6 +504,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/netfront.c
--- a/extras/mini-os/netfront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/netfront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -421,6 +421,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/pcifront.c
--- a/extras/mini-os/pcifront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/pcifront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -222,6 +222,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:

--Apple-Mail-13-454269537
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii



----
Sincerely,

John

On Feb 9, 2012, at 4:10 AM, Ian Campbell wrote:

> 
> Would you mind resending this with a Signed-off-by as per
> http://wiki.xen.org/wiki/SubmittingXenPatches ? From what you say above
> I guess you also have similar fixes to the other drivers, I think it
> would be fine to bundle all those similar fixes into a single patch.
> 
> Thanks, 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











--Apple-Mail-13-454269537
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Apple-Mail-13-454269537--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:28:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVvG-0003Iq-CQ; Thu, 09 Feb 2012 15:28:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RvVvD-0003Ic-Ux
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:28:32 +0000
Received: from [85.158.139.83:39764] by server-10.bemta-5.messagelabs.com id
	FB/B7-26909-F16E33F4; Thu, 09 Feb 2012 15:28:31 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328801310!14405700!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28830 invoked from network); 9 Feb 2012 15:28:30 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-6.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 15:28:30 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q19FSOEe018922;
	Thu, 9 Feb 2012 10:28:24 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q19FSOIe027574;
	Thu, 9 Feb 2012 10:28:24 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020910282301105 ; Thu, 09 Feb 2012 10:28:23 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/mixed; boundary=Apple-Mail-13-454269537
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1328778625.6133.107.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 10:28:23 -0500
Message-Id: <92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
	<1328778625.6133.107.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--Apple-Mail-13-454269537
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ian,

Here is the first patch. There are other unused variable issues not so =
easily fixed, so I am putting them in another patch that should come out =
later today, FWIW.

The changeset id in this patch is bogus. It is based on our own =
Mercurial repo, not Xenbits. The code is from the RedHat source RPM =
xen-4.1.2-2.fc16.src.rpm
----


--Apple-Mail-13-454269537
Content-Disposition: attachment;
	filename=patch01.diff
Content-Type: application/octet-stream;
	name="patch01.diff"
Content-Transfer-Encoding: 7bit

# HG changeset patch
# Parent 3faf3f1c25fc32a74d248778cc2d9d0a567967cd
mini-os: stop compiler complaint about unused variables

gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused variables
in mini-os drivers

Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

diff -r 3faf3f1c25fc extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/blkfront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -171,6 +171,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/console/xencons_ring.c
--- a/extras/mini-os/console/xencons_ring.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/console/xencons_ring.c	Thu Feb 09 09:47:34 2012 -0500
@@ -317,6 +317,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/fbfront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -142,6 +142,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
@@ -503,6 +504,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/netfront.c
--- a/extras/mini-os/netfront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/netfront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -421,6 +421,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:
diff -r 3faf3f1c25fc extras/mini-os/pcifront.c
--- a/extras/mini-os/pcifront.c	Mon Jan 09 08:56:52 2012 -0500
+++ b/extras/mini-os/pcifront.c	Thu Feb 09 09:47:34 2012 -0500
@@ -222,6 +222,7 @@ again:
 abort_transaction:
     free(err);
     err = xenbus_transaction_end(xbt, 1, &retry);
+    printk("Abort transaction %s\n", message);
     goto error;
 
 done:

--Apple-Mail-13-454269537
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii



----
Sincerely,

John

On Feb 9, 2012, at 4:10 AM, Ian Campbell wrote:

> 
> Would you mind resending this with a Signed-off-by as per
> http://wiki.xen.org/wiki/SubmittingXenPatches ? From what you say above
> I guess you also have similar fixes to the other drivers, I think it
> would be fine to bundle all those similar fixes into a single patch.
> 
> Thanks, 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











--Apple-Mail-13-454269537
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Apple-Mail-13-454269537--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVvb-0003LL-Ie; Thu, 09 Feb 2012 15:28:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVvY-0003Kf-Sw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:28:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328801327!14652180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16557 invoked from network); 9 Feb 2012 15:28:47 -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;
	9 Feb 2012 15:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:28:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:28:46 +0000
Message-ID: <1328801325.6133.196.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kris <kris@theendless.org>
Date: Thu, 9 Feb 2012 15:28:45 +0000
In-Reply-To: <33BCF8E1-F585-48BF-8AA4-AF8881FDBB9B@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
	<1328793091.6133.170.camel@zakaz.uk.xensource.com>
	<33BCF8E1-F585-48BF-8AA4-AF8881FDBB9B@theendless.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
 with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't top post.

On Thu, 2012-02-09 at 15:16 +0000, Kris wrote:
> Especially some sort of explanation of what those integers mean in the network-list?

IIRC those numbers come from the xenstore entry for the device. I expect
-1 means "entry is missing".

The guest should have written them -- hence the question about guests
logs and versions etc.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvVvb-0003LL-Ie; Thu, 09 Feb 2012 15:28:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvVvY-0003Kf-Sw
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:28:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328801327!14652180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16557 invoked from network); 9 Feb 2012 15:28:47 -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;
	9 Feb 2012 15:28:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:28:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:28:46 +0000
Message-ID: <1328801325.6133.196.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kris <kris@theendless.org>
Date: Thu, 9 Feb 2012 15:28:45 +0000
In-Reply-To: <33BCF8E1-F585-48BF-8AA4-AF8881FDBB9B@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
	<1328793091.6133.170.camel@zakaz.uk.xensource.com>
	<33BCF8E1-F585-48BF-8AA4-AF8881FDBB9B@theendless.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
 with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't top post.

On Thu, 2012-02-09 at 15:16 +0000, Kris wrote:
> Especially some sort of explanation of what those integers mean in the network-list?

IIRC those numbers come from the xenstore entry for the device. I expect
-1 means "entry is missing".

The guest should have written them -- hence the question about guests
logs and versions etc.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:30:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVwb-0003UA-DZ; Thu, 09 Feb 2012 15:29:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvVwa-0003TO-0b
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:29:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328801389!14117084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7206 invoked from network); 9 Feb 2012 15:29:50 -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;
	9 Feb 2012 15:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:29:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:29:14 +0000
Date: Thu, 9 Feb 2012 15:32:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20275.58558.925282.788540@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > - we can reuse the "state" based mechanism to establish a connection:
> > again not a great protocol, but very well known and understood.
> 
> I don't think we have, in general, a good understanding of these
> "state" based protocols ...

What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!


> Also for an internal mechanism I think we should have something
> autogenerated so avoid having lots of handwritten parsing/emitting code.
 
If I am not mistaken in this series we are reusing existing code, not
adding new one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:30:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvVwb-0003UA-DZ; Thu, 09 Feb 2012 15:29:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvVwa-0003TO-0b
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:29:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328801389!14117084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7206 invoked from network); 9 Feb 2012 15:29:50 -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;
	9 Feb 2012 15:29:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:29:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:29:14 +0000
Date: Thu, 9 Feb 2012 15:32:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20275.58558.925282.788540@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > - we can reuse the "state" based mechanism to establish a connection:
> > again not a great protocol, but very well known and understood.
> 
> I don't think we have, in general, a good understanding of these
> "state" based protocols ...

What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!


> Also for an internal mechanism I think we should have something
> autogenerated so avoid having lots of handwritten parsing/emitting code.
 
If I am not mistaken in this series we are reusing existing code, not
adding new one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:34:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW0b-0003nS-4P; Thu, 09 Feb 2012 15:34:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW0Z-0003nA-3H
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:34:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328801632!14319898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16749 invoked from network); 9 Feb 2012 15:33:56 -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;
	9 Feb 2012 15:33:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:33:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:33:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW0N-0003l9-Uf; Thu, 09 Feb 2012 15:33:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW0N-00062T-Tn;
	Thu, 09 Feb 2012 15:33:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59231.911637.772528@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:33:51 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> On Thu, 9 Feb 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > - we can reuse the "state" based mechanism to establish a connection:
> > > again not a great protocol, but very well known and understood.
> > 
> > I don't think we have, in general, a good understanding of these
> > "state" based protocols ...
> 
> What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!

In many (most?) of these cases we don't know exactly what the state
numbers mean, let alone exactly the details of the rest of the
protocol.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:34:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW0b-0003nS-4P; Thu, 09 Feb 2012 15:34:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW0Z-0003nA-3H
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:34:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328801632!14319898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16749 invoked from network); 9 Feb 2012 15:33:56 -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;
	9 Feb 2012 15:33:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:33:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:33:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW0N-0003l9-Uf; Thu, 09 Feb 2012 15:33:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW0N-00062T-Tn;
	Thu, 09 Feb 2012 15:33:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59231.911637.772528@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:33:51 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> On Thu, 9 Feb 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > - we can reuse the "state" based mechanism to establish a connection:
> > > again not a great protocol, but very well known and understood.
> > 
> > I don't think we have, in general, a good understanding of these
> > "state" based protocols ...
> 
> What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!

In many (most?) of these cases we don't know exactly what the state
numbers mean, let alone exactly the details of the rest of the
protocol.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:34:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:34:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvW1G-0003qy-Pz; Thu, 09 Feb 2012 15:34:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW1E-0003qh-Py
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:34:45 +0000
Received: from [85.158.139.83:14166] by server-1.bemta-5.messagelabs.com id
	D1/DF-04285-497E33F4; Thu, 09 Feb 2012 15:34:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328801682!14403666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7261 invoked from network); 9 Feb 2012 15:34:43 -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;
	9 Feb 2012 15:34:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:34:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:34:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW0r-0003lK-P9; Thu, 09 Feb 2012 15:34:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW0r-00063B-OA;
	Thu, 09 Feb 2012 15:34:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59261.734949.315541@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:34:21 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a7ef1bfa694bf581310e.1328189210@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<a7ef1bfa694bf581310e.1328189210@debian.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 29 RFC] NetBSD/xencommons: remove xend
 precmd folder creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 15 of 29 RFC] NetBSD/xencommons: remove xend precmd folder creation"):
> NetBSD/xencommons: remove xend precmd folder creation
> 
> Since xend is not started by xencommons move the creation of the
> necessary xend folders to xend init script.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

This looks plausible but I would call them "directories".  "folders"
is strictly a UI term for us I think.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:34:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:34:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvW1G-0003qy-Pz; Thu, 09 Feb 2012 15:34:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW1E-0003qh-Py
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:34:45 +0000
Received: from [85.158.139.83:14166] by server-1.bemta-5.messagelabs.com id
	D1/DF-04285-497E33F4; Thu, 09 Feb 2012 15:34:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328801682!14403666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7261 invoked from network); 9 Feb 2012 15:34:43 -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;
	9 Feb 2012 15:34:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10602868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:34:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:34:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW0r-0003lK-P9; Thu, 09 Feb 2012 15:34:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW0r-00063B-OA;
	Thu, 09 Feb 2012 15:34:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59261.734949.315541@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:34:21 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a7ef1bfa694bf581310e.1328189210@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<a7ef1bfa694bf581310e.1328189210@debian.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 29 RFC] NetBSD/xencommons: remove xend
 precmd folder creation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 15 of 29 RFC] NetBSD/xencommons: remove xend precmd folder creation"):
> NetBSD/xencommons: remove xend precmd folder creation
> 
> Since xend is not started by xencommons move the creation of the
> necessary xend folders to xend init script.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

This looks plausible but I would call them "directories".  "folders"
is strictly a UI term for us I think.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:40:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW6c-0004Ct-Ri; Thu, 09 Feb 2012 15:40:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvW6b-0004Ck-B1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:40:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328802011!13579020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13364 invoked from network); 9 Feb 2012 15:40: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;
	9 Feb 2012 15:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:40: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.213.0; Thu, 9 Feb 2012 15:40:10 +0000
Date: Thu, 9 Feb 2012 15:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20275.59231.911637.772528@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091539530.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<20275.59231.911637.772528@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > again not a great protocol, but very well known and understood.
> > > 
> > > I don't think we have, in general, a good understanding of these
> > > "state" based protocols ...
> > 
> > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> 
> In many (most?) of these cases we don't know exactly what the state
> numbers mean

see xen/include/public/io/xenbus.h


> let alone exactly the details of the rest of the
> protocol.
 
The details of the rest of the protocol are a well known contract
between frontend, backend and the toolstack. In fact they work with
different toolstacks (xend, libxl, xapi), different backend
implementations (Linux, QEMU), different frontends (Linux, Windows PV
drivers). And the examples I mentioned are just the ones that I happen
to work with.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:40:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW6c-0004Ct-Ri; Thu, 09 Feb 2012 15:40:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvW6b-0004Ck-B1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:40:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328802011!13579020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13364 invoked from network); 9 Feb 2012 15:40: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;
	9 Feb 2012 15:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:40: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.213.0; Thu, 9 Feb 2012 15:40:10 +0000
Date: Thu, 9 Feb 2012 15:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20275.59231.911637.772528@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091539530.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<20275.59231.911637.772528@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > again not a great protocol, but very well known and understood.
> > > 
> > > I don't think we have, in general, a good understanding of these
> > > "state" based protocols ...
> > 
> > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> 
> In many (most?) of these cases we don't know exactly what the state
> numbers mean

see xen/include/public/io/xenbus.h


> let alone exactly the details of the rest of the
> protocol.
 
The details of the rest of the protocol are a well known contract
between frontend, backend and the toolstack. In fact they work with
different toolstacks (xend, libxl, xapi), different backend
implementations (Linux, QEMU), different frontends (Linux, Windows PV
drivers). And the examples I mentioned are just the ones that I happen
to work with.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:40:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvW6k-0004DM-8n; Thu, 09 Feb 2012 15:40:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW6i-0004Cr-3p
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328802017!2429145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9545 invoked from network); 9 Feb 2012 15:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:40:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:40:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW6b-0003nC-1f; Thu, 09 Feb 2012 15:40:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW6b-0006AH-0u;
	Thu, 09 Feb 2012 15:40:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59617.15772.210387@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:40:17 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <35164add2785b8606c0e.1328189223@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
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 28 of 29 RFC] libxl: add
	libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev"):
> libxl: add libxl__find_free_vdev
> 
> Add a function that returns the first free xvd<x> device, used to
> attach a DomU image and execute the bootloader against that.

I'm afraid I don't understand the purpose of this at all.

Also the comment "add <some function>" is not accurate because the
real change is to run the bootloader on some other disk.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:40:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvW6k-0004DM-8n; Thu, 09 Feb 2012 15:40:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW6i-0004Cr-3p
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:40:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328802017!2429145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9545 invoked from network); 9 Feb 2012 15:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 15:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:40:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:40:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW6b-0003nC-1f; Thu, 09 Feb 2012 15:40:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW6b-0006AH-0u;
	Thu, 09 Feb 2012 15:40:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59617.15772.210387@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:40:17 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <35164add2785b8606c0e.1328189223@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
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 28 of 29 RFC] libxl: add
	libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev"):
> libxl: add libxl__find_free_vdev
> 
> Add a function that returns the first free xvd<x> device, used to
> attach a DomU image and execute the bootloader against that.

I'm afraid I don't understand the purpose of this at all.

Also the comment "add <some function>" is not accurate because the
real change is to run the bootloader on some other disk.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:41:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW7g-0004Kd-OH; Thu, 09 Feb 2012 15:41:24 +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 1RvW7f-0004KD-Ev
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:41:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328801946!52075193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5575 invoked from network); 9 Feb 2012 15:39:06 -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;
	9 Feb 2012 15:39:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:41:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:41:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW7a-0003nh-NW; Thu, 09 Feb 2012 15:41:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW7a-0006Bc-Mb;
	Thu, 09 Feb 2012 15:41:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59678.686565.57979@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:41:18 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202091539530.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<20275.59231.911637.772528@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091539530.22056@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> The details of the rest of the protocol are a well known contract
> between frontend, backend and the toolstack. In fact they work with
> different toolstacks (xend, libxl, xapi), different backend
> implementations (Linux, QEMU), different frontends (Linux, Windows PV
> drivers). And the examples I mentioned are just the ones that I happen
> to work with.

If they are so well known, please point me to the detailed protocol
specification.

Oh wait you can't because Justin Gibbs hasn't finished the disk one
yet and no-one has started on the others.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:41:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW7g-0004Kd-OH; Thu, 09 Feb 2012 15:41:24 +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 1RvW7f-0004KD-Ev
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:41:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328801946!52075193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5575 invoked from network); 9 Feb 2012 15:39:06 -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;
	9 Feb 2012 15:39:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:41:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:41:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW7a-0003nh-NW; Thu, 09 Feb 2012 15:41:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW7a-0006Bc-Mb;
	Thu, 09 Feb 2012 15:41:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59678.686565.57979@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:41:18 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202091539530.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<20275.59231.911637.772528@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091539530.22056@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> The details of the rest of the protocol are a well known contract
> between frontend, backend and the toolstack. In fact they work with
> different toolstacks (xend, libxl, xapi), different backend
> implementations (Linux, QEMU), different frontends (Linux, Windows PV
> drivers). And the examples I mentioned are just the ones that I happen
> to work with.

If they are so well known, please point me to the detailed protocol
specification.

Oh wait you can't because Justin Gibbs hasn't finished the disk one
yet and no-one has started on the others.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:43:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW9S-0004Xm-GS; Thu, 09 Feb 2012 15:43:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW9Q-0004XQ-MA
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:43:12 +0000
Received: from [193.109.254.147:22148] by server-5.bemta-14.messagelabs.com id
	AE/C5-05697-F89E33F4; Thu, 09 Feb 2012 15:43:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328802140!52092884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13654 invoked from network); 9 Feb 2012 15:42:20 -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;
	9 Feb 2012 15:42:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:43:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:43:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW9O-0003oM-Ni; Thu, 09 Feb 2012 15:43:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW9O-0006Dt-My;
	Thu, 09 Feb 2012 15:43:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59790.700273.845107@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:43:10 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7de94a26474f869177ce.1328189224@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<7de94a26474f869177ce.1328189224@debian.localdomain>
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 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/u> libxl: delegate plug/unplug of disk and nic devices to xldeviced
> 
> Change the calls to libxl_device_<type>_<action> to
> libxl_device_<type>_hotplug_<action> for disk and nic device types.
> Alsoe enables hotplug script calling from libxl itself, by disabling
> some udev rules and removing the commented code in
> libxl__device_hotplug.

Again, I don't think this is the right way to organise the change to
this behaviour.

The right thing to do is probably to change individual device types
one at a type, and to make the new functionality have the same
libxl_device_disk_add name (etc.) as before.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:43:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvW9S-0004Xm-GS; Thu, 09 Feb 2012 15:43:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvW9Q-0004XQ-MA
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:43:12 +0000
Received: from [193.109.254.147:22148] by server-5.bemta-14.messagelabs.com id
	AE/C5-05697-F89E33F4; Thu, 09 Feb 2012 15:43:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328802140!52092884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13654 invoked from network); 9 Feb 2012 15:42:20 -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;
	9 Feb 2012 15:42:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:43:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:43:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvW9O-0003oM-Ni; Thu, 09 Feb 2012 15:43:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvW9O-0006Dt-My;
	Thu, 09 Feb 2012 15:43:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.59790.700273.845107@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:43:10 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7de94a26474f869177ce.1328189224@debian.localdomain>
References: <patchbomb.1328189195@debian.localdomain>
	<7de94a26474f869177ce.1328189224@debian.localdomain>
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 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/u> libxl: delegate plug/unplug of disk and nic devices to xldeviced
> 
> Change the calls to libxl_device_<type>_<action> to
> libxl_device_<type>_hotplug_<action> for disk and nic device types.
> Alsoe enables hotplug script calling from libxl itself, by disabling
> some udev rules and removing the commented code in
> libxl__device_hotplug.

Again, I don't think this is the right way to organise the change to
this behaviour.

The right thing to do is probably to change individual device types
one at a type, and to make the new functionality have the same
libxl_device_disk_add name (etc.) as before.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:43:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvW9n-0004ay-U5; Thu, 09 Feb 2012 15:43:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvW9m-0004Zm-G2
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:43:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328802208!14201190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22125 invoked from network); 9 Feb 2012 15:43: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;
	9 Feb 2012 15:43:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:43:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:43:27 +0000
Message-ID: <1328802111.6133.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Thu, 9 Feb 2012 15:41:51 +0000
In-Reply-To: <92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
	<1328778625.6133.107.camel@zakaz.uk.xensource.com>
	<92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:28 +0000, John McDermott CIV wrote:
> mini-os: stop compiler complaint about unused variables
> 
> gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused
> variables
> in mini-os drivers
> 
> Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although perhaps "$FOO abort transaction", for $FOO in blkfront,netfront
etc might be more helpful if the message actually happens? 

> 
> diff -r 3faf3f1c25fc extras/mini-os/blkfront.c
> --- a/extras/mini-os/blkfront.c Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/blkfront.c Thu Feb 09 09:47:34 2012 -0500
> @@ -171,6 +171,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/console/xencons_ring.c
> --- a/extras/mini-os/console/xencons_ring.c     Mon Jan 09 08:56:52
> 2012 -0500
> +++ b/extras/mini-os/console/xencons_ring.c     Thu Feb 09 09:47:34
> 2012 -0500
> @@ -317,6 +317,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/fbfront.c
> --- a/extras/mini-os/fbfront.c  Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/fbfront.c  Thu Feb 09 09:47:34 2012 -0500
> @@ -142,6 +142,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> @@ -503,6 +504,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/netfront.c
> --- a/extras/mini-os/netfront.c Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/netfront.c Thu Feb 09 09:47:34 2012 -0500
> @@ -421,6 +421,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/pcifront.c
> --- a/extras/mini-os/pcifront.c Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/pcifront.c Thu Feb 09 09:47:34 2012 -0500
> @@ -222,6 +222,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:43:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvW9n-0004ay-U5; Thu, 09 Feb 2012 15:43:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvW9m-0004Zm-G2
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:43:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328802208!14201190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22125 invoked from network); 9 Feb 2012 15:43: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;
	9 Feb 2012 15:43:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:43:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:43:27 +0000
Message-ID: <1328802111.6133.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Thu, 9 Feb 2012 15:41:51 +0000
In-Reply-To: <92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
	<1328778625.6133.107.camel@zakaz.uk.xensource.com>
	<92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:28 +0000, John McDermott CIV wrote:
> mini-os: stop compiler complaint about unused variables
> 
> gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused
> variables
> in mini-os drivers
> 
> Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although perhaps "$FOO abort transaction", for $FOO in blkfront,netfront
etc might be more helpful if the message actually happens? 

> 
> diff -r 3faf3f1c25fc extras/mini-os/blkfront.c
> --- a/extras/mini-os/blkfront.c Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/blkfront.c Thu Feb 09 09:47:34 2012 -0500
> @@ -171,6 +171,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/console/xencons_ring.c
> --- a/extras/mini-os/console/xencons_ring.c     Mon Jan 09 08:56:52
> 2012 -0500
> +++ b/extras/mini-os/console/xencons_ring.c     Thu Feb 09 09:47:34
> 2012 -0500
> @@ -317,6 +317,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/fbfront.c
> --- a/extras/mini-os/fbfront.c  Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/fbfront.c  Thu Feb 09 09:47:34 2012 -0500
> @@ -142,6 +142,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> @@ -503,6 +504,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/netfront.c
> --- a/extras/mini-os/netfront.c Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/netfront.c Thu Feb 09 09:47:34 2012 -0500
> @@ -421,6 +421,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> diff -r 3faf3f1c25fc extras/mini-os/pcifront.c
> --- a/extras/mini-os/pcifront.c Mon Jan 09 08:56:52 2012 -0500
> +++ b/extras/mini-os/pcifront.c Thu Feb 09 09:47:34 2012 -0500
> @@ -222,6 +222,7 @@ again:
>  abort_transaction:
>      free(err);
>      err = xenbus_transaction_end(xbt, 1, &retry);
> +    printk("Abort transaction %s\n", message);
>      goto error;
>  
>  done:
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:52:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:52:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWII-00059u-A5; Thu, 09 Feb 2012 15: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.Campbell@citrix.com>) id 1RvWIH-00059p-64
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:52:21 +0000
Received: from [85.158.139.83:25533] by server-9.bemta-5.messagelabs.com id
	6D/1F-23757-4BBE33F4; Thu, 09 Feb 2012 15:52:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328802739!14409592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14610 invoked from network); 9 Feb 2012 15:52:20 -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;
	9 Feb 2012 15:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:52:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:52:19 +0000
Message-ID: <1328802738.6133.206.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:52:18 +0000
In-Reply-To: <alpine.DEB.2.00.1202091527190.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
	<1328800887.6133.191.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091527190.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:28 +0000, Stefano Stabellini wrote:

> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1328800759 0
> > # Node ID daa129cac86315bad066f4c358bd02817985a8df
> > # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> > arm: define domain_pirq_to_irq
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ack

Thanks. Both acks taken and pushed, along with the remainder of your
series.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:52:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15:52:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWII-00059u-A5; Thu, 09 Feb 2012 15: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.Campbell@citrix.com>) id 1RvWIH-00059p-64
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:52:21 +0000
Received: from [85.158.139.83:25533] by server-9.bemta-5.messagelabs.com id
	6D/1F-23757-4BBE33F4; Thu, 09 Feb 2012 15:52:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328802739!14409592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14610 invoked from network); 9 Feb 2012 15:52:20 -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;
	9 Feb 2012 15:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:52:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:52:19 +0000
Message-ID: <1328802738.6133.206.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:52:18 +0000
In-Reply-To: <alpine.DEB.2.00.1202091527190.22056@kaball-desktop>
References: <1328798741.6133.188.camel@zakaz.uk.xensource.com>
	<abd72cc240fa3d643541.1328799201@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202091515380.22056@kaball-desktop>
	<1328800887.6133.191.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091527190.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: define domain_pirq_to_irq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:28 +0000, Stefano Stabellini wrote:

> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1328800759 0
> > # Node ID daa129cac86315bad066f4c358bd02817985a8df
> > # Parent  18b9ea53c8ac0e2d6aee68dd50a50c0b08a01a1e
> > arm: define domain_pirq_to_irq
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ack

Thanks. Both acks taken and pushed, along with the remainder of your
series.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:53:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvWJY-0005Dp-PE; Thu, 09 Feb 2012 15:53:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvWJX-0005DN-81
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:53:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328802812!12715381!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18867 invoked from network); 9 Feb 2012 15:53:33 -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;
	9 Feb 2012 15:53:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:49:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:49:17 +0000
Message-ID: <1328802555.6133.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:49:15 +0000
In-Reply-To: <alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > - we can reuse the "state" based mechanism to establish a connection:
> > > again not a great protocol, but very well known and understood.
> > 
> > I don't think we have, in general, a good understanding of these
> > "state" based protocols ...
> 
> What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!

And no one I know is able to describe, accurately, exactly what the
state diagram for even one of those actually looks like or indeed should
look like. It became quite evident in these threads about hotplug script
handling etc that no one really knows for sure what (is supposed to)
happens when.

Justin just posted a good description for blkif.h which included a state
machine description. We need the same for pciif.h, netif.h etc etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:53:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvWJY-0005Dp-PE; Thu, 09 Feb 2012 15:53:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvWJX-0005DN-81
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:53:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328802812!12715381!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18867 invoked from network); 9 Feb 2012 15:53:33 -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;
	9 Feb 2012 15:53:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:49:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	15:49:17 +0000
Message-ID: <1328802555.6133.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 15:49:15 +0000
In-Reply-To: <alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > - we can reuse the "state" based mechanism to establish a connection:
> > > again not a great protocol, but very well known and understood.
> > 
> > I don't think we have, in general, a good understanding of these
> > "state" based protocols ...
> 
> What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!

And no one I know is able to describe, accurately, exactly what the
state diagram for even one of those actually looks like or indeed should
look like. It became quite evident in these threads about hotplug script
handling etc that no one really knows for sure what (is supposed to)
happens when.

Justin just posted a good description for blkif.h which included a state
machine description. We need the same for pciif.h, netif.h etc etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:57:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvWNG-0005Pf-Fs; Thu, 09 Feb 2012 15:57:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvWNF-0005PL-Di
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:57:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328803043!10689998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18364 invoked from network); 9 Feb 2012 15:57:23 -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;
	9 Feb 2012 15:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:57:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:57:23 +0000
Date: Thu, 9 Feb 2012 16:00:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328802555.6133.204.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > again not a great protocol, but very well known and understood.
> > > 
> > > I don't think we have, in general, a good understanding of these
> > > "state" based protocols ...
> > 
> > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> 
> And no one I know is able to describe, accurately, exactly what the
> state diagram for even one of those actually looks like or indeed should
> look like. It became quite evident in these threads about hotplug script
> handling etc that no one really knows for sure what (is supposed to)
> happens when.

I thought that most of the thread was about the interface with the block
scripts, that is an entirely different matter and completely obscure.
If I am mistaken, please point me at the right email.


> Justin just posted a good description for blkif.h which included a state
> machine description. We need the same for pciif.h, netif.h etc etc.
 
The state machine is the same for block and network.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 15:57:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 15: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.xensource.com>)
	id 1RvWNG-0005Pf-Fs; Thu, 09 Feb 2012 15:57:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvWNF-0005PL-Di
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 15:57:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328803043!10689998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18364 invoked from network); 9 Feb 2012 15:57:23 -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;
	9 Feb 2012 15:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 15:57:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 15:57:23 +0000
Date: Thu, 9 Feb 2012 16:00:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328802555.6133.204.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > again not a great protocol, but very well known and understood.
> > > 
> > > I don't think we have, in general, a good understanding of these
> > > "state" based protocols ...
> > 
> > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> 
> And no one I know is able to describe, accurately, exactly what the
> state diagram for even one of those actually looks like or indeed should
> look like. It became quite evident in these threads about hotplug script
> handling etc that no one really knows for sure what (is supposed to)
> happens when.

I thought that most of the thread was about the interface with the block
scripts, that is an entirely different matter and completely obscure.
If I am mistaken, please point me at the right email.


> Justin just posted a good description for blkif.h which included a state
> machine description. We need the same for pciif.h, netif.h etc etc.
 
The state machine is the same for block and network.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:00:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWPr-0005wi-2D; Thu, 09 Feb 2012 16:00:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvWPp-0005or-AE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:00:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328803202!10806490!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30562 invoked from network); 9 Feb 2012 16:00:02 -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;
	9 Feb 2012 16:00:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:00:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:00:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvWPh-0003xM-Rs;
	Thu, 09 Feb 2012 16:00:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvWPh-0004CE-I0;
	Thu, 09 Feb 2012 16:00:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11903-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:00:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11903: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11903 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11903/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11902

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  18b9ea53c8ac
baseline version:
 xen                  8ba7ae0b070b

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@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>
  Santosh Jodh <santosh.jodh@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@citrix.com>
  Xiantao Zhang<xiantao.zhang@intel.com>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=18b9ea53c8ac
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 18b9ea53c8ac
+ branch=xen-unstable
+ revision=18b9ea53c8ac
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 18b9ea53c8ac ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 19 changesets with 124 changes to 108 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:00:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWPr-0005wi-2D; Thu, 09 Feb 2012 16:00:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvWPp-0005or-AE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:00:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328803202!10806490!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30562 invoked from network); 9 Feb 2012 16:00:02 -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;
	9 Feb 2012 16:00:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:00:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:00:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvWPh-0003xM-Rs;
	Thu, 09 Feb 2012 16:00:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvWPh-0004CE-I0;
	Thu, 09 Feb 2012 16:00:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11903-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:00:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11903: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11903 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11903/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11902

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  18b9ea53c8ac
baseline version:
 xen                  8ba7ae0b070b

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@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>
  Santosh Jodh <santosh.jodh@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@citrix.com>
  Xiantao Zhang<xiantao.zhang@intel.com>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=18b9ea53c8ac
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 18b9ea53c8ac
+ branch=xen-unstable
+ revision=18b9ea53c8ac
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 18b9ea53c8ac ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 19 changesets with 124 changes to 108 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:01:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWQl-0006QF-RB; Thu, 09 Feb 2012 16:01: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 1RvWQk-0006NM-U6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:01:07 +0000
Received: from [85.158.139.83:29124] by server-4.bemta-5.messagelabs.com id
	7D/7A-28576-2CDE33F4; Thu, 09 Feb 2012 16:01:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328803265!14411242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31395 invoked from network); 9 Feb 2012 16:01:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 16:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:01:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	16:01:05 +0000
Message-ID: <1328803264.6133.209.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:01:04 +0000
In-Reply-To: <alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > again not a great protocol, but very well known and understood.
> > > > 
> > > > I don't think we have, in general, a good understanding of these
> > > > "state" based protocols ...
> > > 
> > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > 
> > And no one I know is able to describe, accurately, exactly what the
> > state diagram for even one of those actually looks like or indeed should
> > look like. It became quite evident in these threads about hotplug script
> > handling etc that no one really knows for sure what (is supposed to)
> > happens when.
> 
> I thought that most of the thread was about the interface with the block
> scripts, that is an entirely different matter and completely obscure.
> If I am mistaken, please point me at the right email.

We are talking about reusing the existing xenbus state machine schema
for a new purpose. Ian J pointed out that these are not generally well
understood, you replied that it was and cited some examples. I pointed
out why these were not examples of why this stuff was well understood at
all, in fact quite the opposite.

> > Justin just posted a good description for blkif.h which included a state
> > machine description. We need the same for pciif.h, netif.h etc etc.
>  
> The state machine is the same for block and network.

No, it's not. This is exactly what IanJ and I are talking about.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:01:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWQl-0006QF-RB; Thu, 09 Feb 2012 16:01: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 1RvWQk-0006NM-U6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:01:07 +0000
Received: from [85.158.139.83:29124] by server-4.bemta-5.messagelabs.com id
	7D/7A-28576-2CDE33F4; Thu, 09 Feb 2012 16:01:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328803265!14411242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31395 invoked from network); 9 Feb 2012 16:01:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 16:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10603722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:01:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	16:01:05 +0000
Message-ID: <1328803264.6133.209.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:01:04 +0000
In-Reply-To: <alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > again not a great protocol, but very well known and understood.
> > > > 
> > > > I don't think we have, in general, a good understanding of these
> > > > "state" based protocols ...
> > > 
> > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > 
> > And no one I know is able to describe, accurately, exactly what the
> > state diagram for even one of those actually looks like or indeed should
> > look like. It became quite evident in these threads about hotplug script
> > handling etc that no one really knows for sure what (is supposed to)
> > happens when.
> 
> I thought that most of the thread was about the interface with the block
> scripts, that is an entirely different matter and completely obscure.
> If I am mistaken, please point me at the right email.

We are talking about reusing the existing xenbus state machine schema
for a new purpose. Ian J pointed out that these are not generally well
understood, you replied that it was and cited some examples. I pointed
out why these were not examples of why this stuff was well understood at
all, in fact quite the opposite.

> > Justin just posted a good description for blkif.h which included a state
> > machine description. We need the same for pciif.h, netif.h etc etc.
>  
> The state machine is the same for block and network.

No, it's not. This is exactly what IanJ and I are talking about.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:01:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:01:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWQh-0006N3-Dc; Thu, 09 Feb 2012 16:01:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvWQg-0006JK-0o
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:01:02 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328803255!13645963!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4379 invoked from network); 9 Feb 2012 16:00:56 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 16:00:56 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19G0sno022070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 11:00:54 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19G0qGW006363; Thu, 9 Feb 2012 11:00:53 -0500
Message-ID: <4F33EDB4.9090904@redhat.com>
Date: Thu, 09 Feb 2012 17:00:52 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com> <4F33CA3C.50903@redhat.com>
In-Reply-To: <4F33CA3C.50903@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

> I'll try to get a complete v4 out of the door later today, that should
> the direction I'm heading to more clear than these incremental bits.

While wading through the acpi mess^Wcode: the acpi timer can s3 wakeups
too IIRC, is that correct?

cheers,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:01:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:01:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWQh-0006N3-Dc; Thu, 09 Feb 2012 16:01:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RvWQg-0006JK-0o
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:01:02 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328803255!13645963!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4379 invoked from network); 9 Feb 2012 16:00:56 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 16:00:56 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19G0sno022070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 11:00:54 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-64.ams2.redhat.com
	[10.36.116.64])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19G0qGW006363; Thu, 9 Feb 2012 11:00:53 -0500
Message-ID: <4F33EDB4.9090904@redhat.com>
Date: Thu, 09 Feb 2012 17:00:52 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120130 Red Hat/3.1.18-1.el6_2
	Thunderbird/3.1.18
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <1328698819-31269-1-git-send-email-kraxel@redhat.com>
	<1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com> <4F33CA3C.50903@redhat.com>
In-Reply-To: <4F33CA3C.50903@redhat.com>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

> I'll try to get a complete v4 out of the door later today, that should
> the direction I'm heading to more clear than these incremental bits.

While wading through the acpi mess^Wcode: the acpi timer can s3 wakeups
too IIRC, is that correct?

cheers,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:04:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWU5-00070g-Mz; Thu, 09 Feb 2012 16:04:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvWU3-0006zp-Ue
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:04:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328803463!10807368!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NDYxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16237 invoked from network); 9 Feb 2012 16:04:25 -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; 9 Feb 2012 16:04:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q19G4Mw7017742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 16:04:23 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
	q19G4Kd8004476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 16:04:21 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
	q19G4JRm023519; Thu, 9 Feb 2012 10:04:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 09 Feb 2012 08:04:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 220084170A; Thu,  9 Feb 2012 11:01:28 -0500 (EST)
Date: Thu, 9 Feb 2012 11:01:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tang Liang <liang.tang@oracle.com>
Message-ID: <20120209160128.GA32058@phenom.dumpdata.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758328-24156-1-git-send-email-liang.tang@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328758328-24156-1-git-send-email-liang.tang@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F33EE87.010B,ss=1,re=0.000,fgs=0
Cc: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/5] EFI: Provide registration for
 efi_init.. etc efi public function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBGZWIgMDksIDIwMTIgYXQgMTE6MzI6MDhBTSArMDgwMCwgVGFuZyBMaWFuZyB3cm90
ZToKPiBUaGUgZWZpIHB1YmxpYyBmdW5jdGlvbnMgYXJlIGNoYW5nZWQgdG8gZnVuY3Rpb24gcG9p
bnRlciBpbiBlZmlfaW5pdF9mdW5jcwo+IHN0cnVjdC4KPiBUaGV5IGFjdCBhcyBlZmkgZ2VuZXJp
YyBmdW5jdGlvbnMgYXMgZGVmYXVsdC4KPiBBcyBhIGJlbmVmaXQgZnJvbSB0aGlzIGNoYW5nZSwg
d2UgY2FuIHJlZ2lzdGVyIHhlbiBlZmkgaW5pdCBmdW5jLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFRh
bmcgTGlhbmcgPGxpYW5nLnRhbmdAb3JhY2xlLmNvbT4KPiAtLS0KPiAgYXJjaC94ODYvcGxhdGZv
cm0vZWZpL2VmaS5jIHwgICA2NSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KystLS0KPiAgaW5jbHVkZS9saW51eC9lZmkuaCAgICAgICAgIHwgICAxMiArKysrKysrLQo+ICAy
IGZpbGVzIGNoYW5nZWQsIDcxIGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25zKC0pCj4gCj4gZGlm
ZiAtLWdpdCBhL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmkuYyBiL2FyY2gveDg2L3BsYXRmb3Jt
L2VmaS9lZmkuYwo+IGluZGV4IDRjZjliZDAuLmQ1NjdlMjkgMTAwNjQ0Cj4gLS0tIGEvYXJjaC94
ODYvcGxhdGZvcm0vZWZpL2VmaS5jCj4gKysrIGIvYXJjaC94ODYvcGxhdGZvcm0vZWZpL2VmaS5j
Cj4gQEAgLTUwLDYgKzUwLDIzIEBACj4gICNkZWZpbmUgUEZYIAkJIkVGSTogIgo+ICAKPiAgaW50
IGVmaV9lbmFibGVkOwo+ICsKPiArc3RhdGljIHZvaWQgZWZpX2luaXRfZ2VuZXJpYyh2b2lkKTsK
PiArCj4gK3N0YXRpYyB2b2lkIGVmaV9lbnRlcl92aXJ0dWFsX21vZGVfZ2VuZXJpYyh2b2lkKTsK
PiArc3RhdGljIHUzMiBlZmlfbWVtX3R5cGVfZ2VuZXJpYyh1bnNpZ25lZCBsb25nIHBoeXNfYWRk
cik7Cj4gK3N0YXRpYyB1NjQgZWZpX21lbV9hdHRyaWJ1dGVzX2dlbmVyaWModW5zaWduZWQgbG9u
ZyBwaHlzX2FkZHIpOwo+ICsKPiArc3RydWN0IGVmaV9pbml0X2Z1bmNzIGVmaV9nZW5lcmljX2Z1
bmNzID0gewo+ICsJLl9fZWZpX2luaXQJCSAgICAgPSBlZmlfaW5pdF9nZW5lcmljLAo+ICsJLl9f
ZWZpX3Jlc2VydmVfYm9vdF9zZXJ2aWNlcyA9IGVmaV9yZXNlcnZlX2Jvb3Rfc2VydmljZXNfZ2Vu
ZXJpYywKCkhtbSwgZGlkIHlvdSBjb21waWxlIHRlc3QgdGhpcz8gSSBnZXQ6CgovaG9tZS9rb25y
YWQvc3NkL2xpbnV4L2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmkuYzo2MjogZXJyb3I6IOKAmGVm
aV9yZXNlcnZlX2Jvb3Rfc2VydmljZXNfZ2VuZXJpY+KAmSB1bmRlY2xhcmVkIGhlcmUgKG5vdCBp
biBhIGZ1bmN0aW9uKQoKVGhlIHBhdGNoIGJlbG93IGZpeGVzIGl0OgoKCkZyb20gNmVjZGMwMDFi
OTlmMDZmNzNmZTU1ZWEyNDY2M2M5YTM5MjFjMjg1ZSBNb24gU2VwIDE3IDAwOjAwOjAwIDIwMDEK
RnJvbTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpEYXRl
OiBUaHUsIDkgRmViIDIwMTIgMTA6NTk6MTcgLTA1MDAKU3ViamVjdDogW1BBVENIXSBlZmk6IEZp
eCBjb21waWxlciBlcnJvciBpbnRyb2R1Y2VkIGJ5IG1vdmluZyBvZiB0aGUgY29kZQogZGVjbGVy
YXRpb24uCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl
dD1VVEYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpUaGUgY29tcGlsZXIgZXJy
b3IgaXMgOgoKYXJjaC94ODYvcGxhdGZvcm0vZWZpL2VmaS5jOjYyOiBlcnJvcjog4oCYZWZpX3Jl
c2VydmVfYm9vdF9zZXJ2aWNlc19nZW5lcmlj4oCZIHVuZGVjbGFyZWQgaGVyZSAobm90IGluIGEg
ZnVuY3Rpb24KCkFuZCBkZWNsZWFyaW5nIGl0IGJlZm9yZSB0aGUgdXNlIGZpeGVzIHRoZSBpc3N1
ZS4KClNpZ25lZC1vZmYtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni9wbGF0Zm9ybS9lZmkvZWZpLmMgfCAgICAxICsKIDEgZmls
ZXMgY2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh
L2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmkuYyBiL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmku
YwppbmRleCBkN2IxOWVlLi5jMjFiMzI1IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9wbGF0Zm9ybS9l
ZmkvZWZpLmMKKysrIGIvYXJjaC94ODYvcGxhdGZvcm0vZWZpL2VmaS5jCkBAIC01Niw2ICs1Niw3
IEBAIHN0YXRpYyB2b2lkIGVmaV9pbml0X2dlbmVyaWModm9pZCk7CiBzdGF0aWMgdm9pZCBlZmlf
ZW50ZXJfdmlydHVhbF9tb2RlX2dlbmVyaWModm9pZCk7CiBzdGF0aWMgdTMyIGVmaV9tZW1fdHlw
ZV9nZW5lcmljKHVuc2lnbmVkIGxvbmcgcGh5c19hZGRyKTsKIHN0YXRpYyB1NjQgZWZpX21lbV9h
dHRyaWJ1dGVzX2dlbmVyaWModW5zaWduZWQgbG9uZyBwaHlzX2FkZHIpOworc3RhdGljIHZvaWQg
ZWZpX3Jlc2VydmVfYm9vdF9zZXJ2aWNlc19nZW5lcmljKHZvaWQpOwogCiBzdHJ1Y3QgZWZpX2lu
aXRfZnVuY3MgZWZpX2dlbmVyaWNfZnVuY3MgPSB7CiAJLl9fZWZpX2luaXQJCSAgICAgPSBlZmlf
aW5pdF9nZW5lcmljLAotLSAKMS43LjcuNQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:04:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWU5-00070g-Mz; Thu, 09 Feb 2012 16:04:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvWU3-0006zp-Ue
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:04:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328803463!10807368!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NDYxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16237 invoked from network); 9 Feb 2012 16:04:25 -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; 9 Feb 2012 16:04:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q19G4Mw7017742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 16:04:23 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
	q19G4Kd8004476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Feb 2012 16:04:21 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
	q19G4JRm023519; Thu, 9 Feb 2012 10:04:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 09 Feb 2012 08:04:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 220084170A; Thu,  9 Feb 2012 11:01:28 -0500 (EST)
Date: Thu, 9 Feb 2012 11:01:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tang Liang <liang.tang@oracle.com>
Message-ID: <20120209160128.GA32058@phenom.dumpdata.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758328-24156-1-git-send-email-liang.tang@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328758328-24156-1-git-send-email-liang.tang@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F33EE87.010B,ss=1,re=0.000,fgs=0
Cc: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/5] EFI: Provide registration for
 efi_init.. etc efi public function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBGZWIgMDksIDIwMTIgYXQgMTE6MzI6MDhBTSArMDgwMCwgVGFuZyBMaWFuZyB3cm90
ZToKPiBUaGUgZWZpIHB1YmxpYyBmdW5jdGlvbnMgYXJlIGNoYW5nZWQgdG8gZnVuY3Rpb24gcG9p
bnRlciBpbiBlZmlfaW5pdF9mdW5jcwo+IHN0cnVjdC4KPiBUaGV5IGFjdCBhcyBlZmkgZ2VuZXJp
YyBmdW5jdGlvbnMgYXMgZGVmYXVsdC4KPiBBcyBhIGJlbmVmaXQgZnJvbSB0aGlzIGNoYW5nZSwg
d2UgY2FuIHJlZ2lzdGVyIHhlbiBlZmkgaW5pdCBmdW5jLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFRh
bmcgTGlhbmcgPGxpYW5nLnRhbmdAb3JhY2xlLmNvbT4KPiAtLS0KPiAgYXJjaC94ODYvcGxhdGZv
cm0vZWZpL2VmaS5jIHwgICA2NSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KystLS0KPiAgaW5jbHVkZS9saW51eC9lZmkuaCAgICAgICAgIHwgICAxMiArKysrKysrLQo+ICAy
IGZpbGVzIGNoYW5nZWQsIDcxIGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25zKC0pCj4gCj4gZGlm
ZiAtLWdpdCBhL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmkuYyBiL2FyY2gveDg2L3BsYXRmb3Jt
L2VmaS9lZmkuYwo+IGluZGV4IDRjZjliZDAuLmQ1NjdlMjkgMTAwNjQ0Cj4gLS0tIGEvYXJjaC94
ODYvcGxhdGZvcm0vZWZpL2VmaS5jCj4gKysrIGIvYXJjaC94ODYvcGxhdGZvcm0vZWZpL2VmaS5j
Cj4gQEAgLTUwLDYgKzUwLDIzIEBACj4gICNkZWZpbmUgUEZYIAkJIkVGSTogIgo+ICAKPiAgaW50
IGVmaV9lbmFibGVkOwo+ICsKPiArc3RhdGljIHZvaWQgZWZpX2luaXRfZ2VuZXJpYyh2b2lkKTsK
PiArCj4gK3N0YXRpYyB2b2lkIGVmaV9lbnRlcl92aXJ0dWFsX21vZGVfZ2VuZXJpYyh2b2lkKTsK
PiArc3RhdGljIHUzMiBlZmlfbWVtX3R5cGVfZ2VuZXJpYyh1bnNpZ25lZCBsb25nIHBoeXNfYWRk
cik7Cj4gK3N0YXRpYyB1NjQgZWZpX21lbV9hdHRyaWJ1dGVzX2dlbmVyaWModW5zaWduZWQgbG9u
ZyBwaHlzX2FkZHIpOwo+ICsKPiArc3RydWN0IGVmaV9pbml0X2Z1bmNzIGVmaV9nZW5lcmljX2Z1
bmNzID0gewo+ICsJLl9fZWZpX2luaXQJCSAgICAgPSBlZmlfaW5pdF9nZW5lcmljLAo+ICsJLl9f
ZWZpX3Jlc2VydmVfYm9vdF9zZXJ2aWNlcyA9IGVmaV9yZXNlcnZlX2Jvb3Rfc2VydmljZXNfZ2Vu
ZXJpYywKCkhtbSwgZGlkIHlvdSBjb21waWxlIHRlc3QgdGhpcz8gSSBnZXQ6CgovaG9tZS9rb25y
YWQvc3NkL2xpbnV4L2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmkuYzo2MjogZXJyb3I6IOKAmGVm
aV9yZXNlcnZlX2Jvb3Rfc2VydmljZXNfZ2VuZXJpY+KAmSB1bmRlY2xhcmVkIGhlcmUgKG5vdCBp
biBhIGZ1bmN0aW9uKQoKVGhlIHBhdGNoIGJlbG93IGZpeGVzIGl0OgoKCkZyb20gNmVjZGMwMDFi
OTlmMDZmNzNmZTU1ZWEyNDY2M2M5YTM5MjFjMjg1ZSBNb24gU2VwIDE3IDAwOjAwOjAwIDIwMDEK
RnJvbTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpEYXRl
OiBUaHUsIDkgRmViIDIwMTIgMTA6NTk6MTcgLTA1MDAKU3ViamVjdDogW1BBVENIXSBlZmk6IEZp
eCBjb21waWxlciBlcnJvciBpbnRyb2R1Y2VkIGJ5IG1vdmluZyBvZiB0aGUgY29kZQogZGVjbGVy
YXRpb24uCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl
dD1VVEYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpUaGUgY29tcGlsZXIgZXJy
b3IgaXMgOgoKYXJjaC94ODYvcGxhdGZvcm0vZWZpL2VmaS5jOjYyOiBlcnJvcjog4oCYZWZpX3Jl
c2VydmVfYm9vdF9zZXJ2aWNlc19nZW5lcmlj4oCZIHVuZGVjbGFyZWQgaGVyZSAobm90IGluIGEg
ZnVuY3Rpb24KCkFuZCBkZWNsZWFyaW5nIGl0IGJlZm9yZSB0aGUgdXNlIGZpeGVzIHRoZSBpc3N1
ZS4KClNpZ25lZC1vZmYtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni9wbGF0Zm9ybS9lZmkvZWZpLmMgfCAgICAxICsKIDEgZmls
ZXMgY2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh
L2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmkuYyBiL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9lZmku
YwppbmRleCBkN2IxOWVlLi5jMjFiMzI1IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9wbGF0Zm9ybS9l
ZmkvZWZpLmMKKysrIGIvYXJjaC94ODYvcGxhdGZvcm0vZWZpL2VmaS5jCkBAIC01Niw2ICs1Niw3
IEBAIHN0YXRpYyB2b2lkIGVmaV9pbml0X2dlbmVyaWModm9pZCk7CiBzdGF0aWMgdm9pZCBlZmlf
ZW50ZXJfdmlydHVhbF9tb2RlX2dlbmVyaWModm9pZCk7CiBzdGF0aWMgdTMyIGVmaV9tZW1fdHlw
ZV9nZW5lcmljKHVuc2lnbmVkIGxvbmcgcGh5c19hZGRyKTsKIHN0YXRpYyB1NjQgZWZpX21lbV9h
dHRyaWJ1dGVzX2dlbmVyaWModW5zaWduZWQgbG9uZyBwaHlzX2FkZHIpOworc3RhdGljIHZvaWQg
ZWZpX3Jlc2VydmVfYm9vdF9zZXJ2aWNlc19nZW5lcmljKHZvaWQpOwogCiBzdHJ1Y3QgZWZpX2lu
aXRfZnVuY3MgZWZpX2dlbmVyaWNfZnVuY3MgPSB7CiAJLl9fZWZpX2luaXQJCSAgICAgPSBlZmlf
aW5pdF9nZW5lcmljLAotLSAKMS43LjcuNQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:06:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWVX-00079q-Ak; Thu, 09 Feb 2012 16:06:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvWVV-00079R-Mb
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:06:02 +0000
Received: from [85.158.139.83:65233] by server-10.bemta-5.messagelabs.com id
	16/E5-26909-8EEE33F4; Thu, 09 Feb 2012 16:06:00 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328803559!14431343!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22832 invoked from network); 9 Feb 2012 16:06:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 16:06:00 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19G5xdx024149
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 11:05:59 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19G5wHd008649; Thu, 9 Feb 2012 11:05:58 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 95DDD133EF0; Thu,  9 Feb 2012 18:05:57 +0200 (IST)
Date: Thu, 9 Feb 2012 18:05:57 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209160557.GB12927@redhat.com>
References: <1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com> <4F33CA3C.50903@redhat.com>
	<4F33EDB4.9090904@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33EDB4.9090904@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 05:00:52PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > I'll try to get a complete v4 out of the door later today, that should
> > the direction I'm heading to more clear than these incremental bits.
> 
> While wading through the acpi mess^Wcode: the acpi timer can s3 wakeups
> too IIRC, is that correct?
> 
According to ACPI spec^Wmess you are correct.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:06:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWVX-00079q-Ak; Thu, 09 Feb 2012 16:06:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RvWVV-00079R-Mb
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:06:02 +0000
Received: from [85.158.139.83:65233] by server-10.bemta-5.messagelabs.com id
	16/E5-26909-8EEE33F4; Thu, 09 Feb 2012 16:06:00 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328803559!14431343!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22832 invoked from network); 9 Feb 2012 16:06:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	9 Feb 2012 16:06:00 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19G5xdx024149
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Feb 2012 11:05:59 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q19G5wHd008649; Thu, 9 Feb 2012 11:05:58 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 95DDD133EF0; Thu,  9 Feb 2012 18:05:57 +0200 (IST)
Date: Thu, 9 Feb 2012 18:05:57 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120209160557.GB12927@redhat.com>
References: <1328698819-31269-2-git-send-email-kraxel@redhat.com>
	<20120209084816.GB18866@redhat.com> <4F33A3C1.1080108@redhat.com>
	<20120209111928.GH18866@redhat.com> <4F33B5E7.7070502@redhat.com>
	<20120209123725.GK18866@redhat.com> <4F33C00F.7040408@redhat.com>
	<20120209131714.GM18866@redhat.com> <4F33CA3C.50903@redhat.com>
	<4F33EDB4.9090904@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F33EDB4.9090904@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 1/6] suspend: add
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, 2012 at 05:00:52PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > I'll try to get a complete v4 out of the door later today, that should
> > the direction I'm heading to more clear than these incremental bits.
> 
> While wading through the acpi mess^Wcode: the acpi timer can s3 wakeups
> too IIRC, is that correct?
> 
According to ACPI spec^Wmess you are correct.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:07:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWWn-0007IR-4p; Thu, 09 Feb 2012 16:07:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvWWl-0007Ho-5B
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:07:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328803633!16022527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30531 invoked from network); 9 Feb 2012 16:07:13 -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;
	9 Feb 2012 16:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10604027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:07:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:07:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvWWe-0003zh-Qq; Thu, 09 Feb 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 1RvWWe-0001lh-MJ;
	Thu, 09 Feb 2012 16:07:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.61232.407436.674268@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:07:12 +0000
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
	<1328778625.6133.107.camel@zakaz.uk.xensource.com>
	<92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
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>,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> Here is the first patch. There are other unused variable issues not so easily fixed, so I am putting them in another patch that should come out later today, FWIW.

Great, thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> The changeset id in this patch is bogus. It is based on our own Mercurial repo, not Xenbits. The code is from the RedHat source RPM xen-4.1.2-2.fc16.src.rpm

Noted, ta.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:07:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWWn-0007IR-4p; Thu, 09 Feb 2012 16:07:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvWWl-0007Ho-5B
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:07:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328803633!16022527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30531 invoked from network); 9 Feb 2012 16:07:13 -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;
	9 Feb 2012 16:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10604027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:07:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:07:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvWWe-0003zh-Qq; Thu, 09 Feb 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 1RvWWe-0001lh-MJ;
	Thu, 09 Feb 2012 16:07:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.61232.407436.674268@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:07:12 +0000
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
References: <B6B460D2-B1C6-47D2-A6CB-CD62E5A542D0@nrl.navy.mil>
	<1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<6A3EEAA2-68A2-41D2-8121-43F8479F275D@nrl.navy.mil>
	<1328778625.6133.107.camel@zakaz.uk.xensource.com>
	<92120908-E3E0-47CE-AE69-772C4DEEB70D@nrl.navy.mil>
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>,
	Samuel Thibault <samuel.thibault@eu.citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> Here is the first patch. There are other unused variable issues not so easily fixed, so I am putting them in another patch that should come out later today, FWIW.

Great, thanks.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

> The changeset id in this patch is bogus. It is based on our own Mercurial repo, not Xenbits. The code is from the RedHat source RPM xen-4.1.2-2.fc16.src.rpm

Noted, ta.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:09:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvWYP-0007T8-Bh; Thu, 09 Feb 2012 16:09:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvWYN-0007SN-C6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:08:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328803733!7560460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26498 invoked from network); 9 Feb 2012 16:08:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 16:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10604124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:08:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:08:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvWYG-00040K-CS; Thu, 09 Feb 2012 16:08:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvWYG-0001nk-Ae;
	Thu, 09 Feb 2012 16:08:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.61332.197371.44329@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:08:52 +0000
To: Keir Fraser <keir.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CB57D267.2A9D3%keir.xen@gmail.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> We should be disablign this warning in Config.mk, where we add
> -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
> same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
> $(call cc-option-add ...) because older gcc versions do not have this
> warning.

Personally in this case I like the new warning.  Shall we at least
wait with disabling it until we get an actual false positive ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:09:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvWYP-0007T8-Bh; Thu, 09 Feb 2012 16:09:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvWYN-0007SN-C6
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:08:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328803733!7560460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26498 invoked from network); 9 Feb 2012 16:08:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 16:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10604124"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:08:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:08:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvWYG-00040K-CS; Thu, 09 Feb 2012 16:08:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvWYG-0001nk-Ae;
	Thu, 09 Feb 2012 16:08:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.61332.197371.44329@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:08:52 +0000
To: Keir Fraser <keir.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CB57D267.2A9D3%keir.xen@gmail.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir Fraser writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> We should be disablign this warning in Config.mk, where we add
> -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
> same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
> $(call cc-option-add ...) because older gcc versions do not have this
> warning.

Personally in this case I like the new warning.  Shall we at least
wait with disabling it until we get an actual false positive ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:10:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:10:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWZD-0007aW-Kx; Thu, 09 Feb 2012 16:09: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 1RvWZC-0007aH-7h
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:09:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328803767!65191187!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1752 invoked from network); 9 Feb 2012 16:09:27 -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;
	9 Feb 2012 16:09:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10604202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16: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.213.0; Thu, 9 Feb 2012
	16:09:42 +0000
Message-ID: <1328803780.6133.210.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:09:40 +0000
In-Reply-To: <20275.61332.197371.44329@mariner.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:08 +0000, Ian Jackson wrote:
> Keir Fraser writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> > We should be disablign this warning in Config.mk, where we add
> > -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
> > same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
> > $(call cc-option-add ...) because older gcc versions do not have this
> > warning.
> 
> Personally in this case I like the new warning.  Shall we at least
> wait with disabling it until we get an actual false positive ?

Yes, lets.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:10:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:10:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWZD-0007aW-Kx; Thu, 09 Feb 2012 16:09: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 1RvWZC-0007aH-7h
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:09:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328803767!65191187!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1752 invoked from network); 9 Feb 2012 16:09:27 -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;
	9 Feb 2012 16:09:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,390,1325462400"; d="scan'208";a="10604202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16: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.213.0; Thu, 9 Feb 2012
	16:09:42 +0000
Message-ID: <1328803780.6133.210.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:09:40 +0000
In-Reply-To: <20275.61332.197371.44329@mariner.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:08 +0000, Ian Jackson wrote:
> Keir Fraser writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> > We should be disablign this warning in Config.mk, where we add
> > -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do the
> > same, if it is creating its own CFLAGS? Note that we add it in Config.mk via
> > $(call cc-option-add ...) because older gcc versions do not have this
> > warning.
> 
> Personally in this case I like the new warning.  Shall we at least
> wait with disabling it until we get an actual false positive ?

Yes, lets.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:15:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWet-0007wh-Hj; Thu, 09 Feb 2012 16:15:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvWes-0007wa-GL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:15:42 +0000
Received: from [85.158.139.83:55839] by server-11.bemta-5.messagelabs.com id
	88/C2-13907-D21F33F4; Thu, 09 Feb 2012 16:15:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328804141!7075276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27594 invoked from network); 9 Feb 2012 16:15:41 -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;
	9 Feb 2012 16:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10604342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:15:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:15:41 +0000
Date: Thu, 9 Feb 2012 16:18:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328803264.6133.209.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > > again not a great protocol, but very well known and understood.
> > > > > 
> > > > > I don't think we have, in general, a good understanding of these
> > > > > "state" based protocols ...
> > > > 
> > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > 
> > > And no one I know is able to describe, accurately, exactly what the
> > > state diagram for even one of those actually looks like or indeed should
> > > look like. It became quite evident in these threads about hotplug script
> > > handling etc that no one really knows for sure what (is supposed to)
> > > happens when.
> > 
> > I thought that most of the thread was about the interface with the block
> > scripts, that is an entirely different matter and completely obscure.
> > If I am mistaken, please point me at the right email.
> 
> We are talking about reusing the existing xenbus state machine schema
> for a new purpose. Ian J pointed out that these are not generally well
> understood, you replied that it was and cited some examples. I pointed
> out why these were not examples of why this stuff was well understood at
> all, in fact quite the opposite.

Sorry but I don't understand how these examples are supposed to be
"quite the opposite".
I quite like the idea of being able to read a single source file of less
than 400 LOC to understand how a protocol works
(drivers/input/misc/xen-kbdfront.c).
In fact I don't think that understanding the protocol has been an issue
for the GSoC student that had to write a new one.
I think we are under influence of a "reiventing the wheel" virus.


> > > Justin just posted a good description for blkif.h which included a state
> > > machine description. We need the same for pciif.h, netif.h etc etc.
> >  
> > The state machine is the same for block and network.
> 
> No, it's not. This is exactly what IanJ and I are talking about.

Could you please elaborate?

I am sure you know that the xenstore state machine is handled the same
way for all the backends in QEMU (see hw/xen_backend.c).
And the same thing is true for the frontends and the backends in Linux.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:15:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWet-0007wh-Hj; Thu, 09 Feb 2012 16:15:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvWes-0007wa-GL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:15:42 +0000
Received: from [85.158.139.83:55839] by server-11.bemta-5.messagelabs.com id
	88/C2-13907-D21F33F4; Thu, 09 Feb 2012 16:15:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328804141!7075276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27594 invoked from network); 9 Feb 2012 16:15:41 -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;
	9 Feb 2012 16:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10604342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:15:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:15:41 +0000
Date: Thu, 9 Feb 2012 16:18:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328803264.6133.209.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > > again not a great protocol, but very well known and understood.
> > > > > 
> > > > > I don't think we have, in general, a good understanding of these
> > > > > "state" based protocols ...
> > > > 
> > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > 
> > > And no one I know is able to describe, accurately, exactly what the
> > > state diagram for even one of those actually looks like or indeed should
> > > look like. It became quite evident in these threads about hotplug script
> > > handling etc that no one really knows for sure what (is supposed to)
> > > happens when.
> > 
> > I thought that most of the thread was about the interface with the block
> > scripts, that is an entirely different matter and completely obscure.
> > If I am mistaken, please point me at the right email.
> 
> We are talking about reusing the existing xenbus state machine schema
> for a new purpose. Ian J pointed out that these are not generally well
> understood, you replied that it was and cited some examples. I pointed
> out why these were not examples of why this stuff was well understood at
> all, in fact quite the opposite.

Sorry but I don't understand how these examples are supposed to be
"quite the opposite".
I quite like the idea of being able to read a single source file of less
than 400 LOC to understand how a protocol works
(drivers/input/misc/xen-kbdfront.c).
In fact I don't think that understanding the protocol has been an issue
for the GSoC student that had to write a new one.
I think we are under influence of a "reiventing the wheel" virus.


> > > Justin just posted a good description for blkif.h which included a state
> > > machine description. We need the same for pciif.h, netif.h etc etc.
> >  
> > The state machine is the same for block and network.
> 
> No, it's not. This is exactly what IanJ and I are talking about.

Could you please elaborate?

I am sure you know that the xenstore state machine is handled the same
way for all the backends in QEMU (see hw/xen_backend.c).
And the same thing is true for the frontends and the backends in Linux.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:28:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWqy-0008Os-03; Thu, 09 Feb 2012 16:28:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RvWqw-0008Ok-Ok
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:28:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328804884!5276185!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18475 invoked from network); 9 Feb 2012 16:28:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 16:28:04 -0000
X-TM-IMSS-Message-ID: <7148e3540000bb3d@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 7148e3540000bb3d ;
	Thu, 9 Feb 2012 11:30:04 -0500
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 q19GS0Q9028664; 
	Thu, 9 Feb 2012 11:28:00 -0500
Message-ID: <4F33F414.5050803@tycho.nsa.gov>
Date: Thu, 09 Feb 2012 11:28:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Are these tools and mini-os changes going to be committed, or do you
have further comments to address? The hypervisor changes went in on
1/28, and Ian's (#8) went in on 1/31; I haven't seen any comments
since 1/30.

On 01/27/2012 05:15 PM, Daniel De Graaf wrote:
> Changes from v5:
>  - Use BSD queue.h instead of GPL list.h in mini-os
>  - Add CONFIG_LWIP to allow simpler disabling of LWIP
>  - Typedef fixups
>  - Create a xenstored_minios.c for minios-specific functions
>  - Formatting cleanup
>  - Using --internal-db is now required for a working stubdom
> 
> Changes from v4:
>  - Add --internal-db flag to use TDB_INTERNAL on non-stubdom
>  - Fewer #ifdefs
> 
> Changes from v3:
>  - mini-os configuration files moved into stubdom/
>  - mini-os extra console support now a config option
>  - Fewer #ifdefs
>  - grant table setup uses hypercall bounce
>  - Xenstore stub domain syslog support re-enabled
> 
> Changes from v2:
>  - configuration support added to mini-os build system
>  - add mini-os support for conditionally compiling frontends, xenbus
>  - XENMEM_remove_from_physmap moved out of arch-specific code
>  - use uint32_t for virqs
>  - warn when dropping grant v2-only flags when switching versions
>  - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
>  - ioctl now returns -EEXIST if xenstored has already been connected
>  - various cosmetic cleanups, shuffling
> 
> Changes from v1:
>  - set_virq_handler implemented in libxc
>  - added custom domain builder for xenstored
>  - xenstore/console domain IDs now pulled from xenstore
>  - migration support when using split xenstored (untested, should work)
>  - slightly less intrusive NO_SOCKETS xenstored patch
>    (still has many ifdefs to avoid pulling in socket headers or symbols)
>  - virq handlers removed from dying domain when clearing event channels
>  - dummy XSM module restricts getdomaininfo similar to no-XSM case
>  - formatting/type fixups
>  - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC
> 
> To start xenstored, run:
> 
> tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t
> 
> This will populate the xenstore domid key /tool/xenstore/domid
> 
> Other notes:
> 
> The console for xenstored is not currently set up by
> init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
> debug=y, output from xenstored will be visible on the hypervisor serial
> console (or ring buffer if enabled with console_to_ring). The xenstore
> stub domain itself supports console output, and init-xenstore-domain
> could be extended to daemonize and spool this output to a log file. The
> normal xenconsole daemon cannot be used here due to the possibility of a
> deadlock.
> 
> ----
> 
> [PATCH 01/24] xen: reinstate previously unused
> [PATCH 02/24] xen: allow global VIRQ handlers to be delegated to
> [PATCH 03/24] xen: change virq parameters from int to uint32_t
> [PATCH 04/24] xen: use XSM instead of IS_PRIV for getdomaininfo
> [PATCH 05/24] xen: Preserve reserved grant entries when switching
> 
> [PATCH 06/24] tools/libxl: pull xenstore/console domids from
> [PATCH 07/24] lib{xc,xl}: Seed grant tables with xenstore and
> 
> [PATCH 08/24] mini-os: use BSD sys/queue.h instead of Linux list.h
>  - New patch by Ian Campbell; requires a qemu tag update with the
>    block-vbd.c change posted at the same time.
> 
> [PATCH 09/24] mini-os: avoid crash if no console is provided
> [PATCH 10/24] mini-os: remove per-fd evtchn limit
> [PATCH 11/24] mini-os: create app-specific configuration
> [PATCH 12/24] mini-os: Move test functions into test.c
> [PATCH 13/24] mini-os: make frontends and xenbus optional
>  - Old patch #13 dropped; others shifted due to new #8
> 
> [PATCH 14/24] xenstored: use grant references instead of
> [PATCH 15/24] xenstored: refactor socket setup code
> [PATCH 16/24] xenstored: add NO_SOCKETS compilation option
> [PATCH 17/24] xenstored: support for tdb_copy with TDB_INTERNAL
> [PATCH 18/24] xenstored: add --internal-db flag
> [PATCH 19/24] xenstored: support running in minios stubdom
> [PATCH 20/24] xenstored: add --event parameter for bootstrapping
> [PATCH 21/24] stubdom: enable xenstored build
> [PATCH 22/24] xenstored: use domain_is_unprivileged instead of
> [PATCH 23/24] xenstored: add --priv-domid parameter
> [PATCH 24/24] xenstored: Add stub domain builder
>  - Swapped 20 <-> 21
> 
> Linux patch unchanged since v3, not reposted this time:
> [PATCH] xenbus: Add support for xenbus backend in stub domain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:28:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvWqy-0008Os-03; Thu, 09 Feb 2012 16:28:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RvWqw-0008Ok-Ok
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:28:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328804884!5276185!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18475 invoked from network); 9 Feb 2012 16:28:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 16:28:04 -0000
X-TM-IMSS-Message-ID: <7148e3540000bb3d@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 7148e3540000bb3d ;
	Thu, 9 Feb 2012 11:30:04 -0500
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 q19GS0Q9028664; 
	Thu, 9 Feb 2012 11:28:00 -0500
Message-ID: <4F33F414.5050803@tycho.nsa.gov>
Date: Thu, 09 Feb 2012 11:28:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Are these tools and mini-os changes going to be committed, or do you
have further comments to address? The hypervisor changes went in on
1/28, and Ian's (#8) went in on 1/31; I haven't seen any comments
since 1/30.

On 01/27/2012 05:15 PM, Daniel De Graaf wrote:
> Changes from v5:
>  - Use BSD queue.h instead of GPL list.h in mini-os
>  - Add CONFIG_LWIP to allow simpler disabling of LWIP
>  - Typedef fixups
>  - Create a xenstored_minios.c for minios-specific functions
>  - Formatting cleanup
>  - Using --internal-db is now required for a working stubdom
> 
> Changes from v4:
>  - Add --internal-db flag to use TDB_INTERNAL on non-stubdom
>  - Fewer #ifdefs
> 
> Changes from v3:
>  - mini-os configuration files moved into stubdom/
>  - mini-os extra console support now a config option
>  - Fewer #ifdefs
>  - grant table setup uses hypercall bounce
>  - Xenstore stub domain syslog support re-enabled
> 
> Changes from v2:
>  - configuration support added to mini-os build system
>  - add mini-os support for conditionally compiling frontends, xenbus
>  - XENMEM_remove_from_physmap moved out of arch-specific code
>  - use uint32_t for virqs
>  - warn when dropping grant v2-only flags when switching versions
>  - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
>  - ioctl now returns -EEXIST if xenstored has already been connected
>  - various cosmetic cleanups, shuffling
> 
> Changes from v1:
>  - set_virq_handler implemented in libxc
>  - added custom domain builder for xenstored
>  - xenstore/console domain IDs now pulled from xenstore
>  - migration support when using split xenstored (untested, should work)
>  - slightly less intrusive NO_SOCKETS xenstored patch
>    (still has many ifdefs to avoid pulling in socket headers or symbols)
>  - virq handlers removed from dying domain when clearing event channels
>  - dummy XSM module restricts getdomaininfo similar to no-XSM case
>  - formatting/type fixups
>  - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC
> 
> To start xenstored, run:
> 
> tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t
> 
> This will populate the xenstore domid key /tool/xenstore/domid
> 
> Other notes:
> 
> The console for xenstored is not currently set up by
> init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
> debug=y, output from xenstored will be visible on the hypervisor serial
> console (or ring buffer if enabled with console_to_ring). The xenstore
> stub domain itself supports console output, and init-xenstore-domain
> could be extended to daemonize and spool this output to a log file. The
> normal xenconsole daemon cannot be used here due to the possibility of a
> deadlock.
> 
> ----
> 
> [PATCH 01/24] xen: reinstate previously unused
> [PATCH 02/24] xen: allow global VIRQ handlers to be delegated to
> [PATCH 03/24] xen: change virq parameters from int to uint32_t
> [PATCH 04/24] xen: use XSM instead of IS_PRIV for getdomaininfo
> [PATCH 05/24] xen: Preserve reserved grant entries when switching
> 
> [PATCH 06/24] tools/libxl: pull xenstore/console domids from
> [PATCH 07/24] lib{xc,xl}: Seed grant tables with xenstore and
> 
> [PATCH 08/24] mini-os: use BSD sys/queue.h instead of Linux list.h
>  - New patch by Ian Campbell; requires a qemu tag update with the
>    block-vbd.c change posted at the same time.
> 
> [PATCH 09/24] mini-os: avoid crash if no console is provided
> [PATCH 10/24] mini-os: remove per-fd evtchn limit
> [PATCH 11/24] mini-os: create app-specific configuration
> [PATCH 12/24] mini-os: Move test functions into test.c
> [PATCH 13/24] mini-os: make frontends and xenbus optional
>  - Old patch #13 dropped; others shifted due to new #8
> 
> [PATCH 14/24] xenstored: use grant references instead of
> [PATCH 15/24] xenstored: refactor socket setup code
> [PATCH 16/24] xenstored: add NO_SOCKETS compilation option
> [PATCH 17/24] xenstored: support for tdb_copy with TDB_INTERNAL
> [PATCH 18/24] xenstored: add --internal-db flag
> [PATCH 19/24] xenstored: support running in minios stubdom
> [PATCH 20/24] xenstored: add --event parameter for bootstrapping
> [PATCH 21/24] stubdom: enable xenstored build
> [PATCH 22/24] xenstored: use domain_is_unprivileged instead of
> [PATCH 23/24] xenstored: add --priv-domid parameter
> [PATCH 24/24] xenstored: Add stub domain builder
>  - Swapped 20 <-> 21
> 
> Linux patch unchanged since v3, not reposted this time:
> [PATCH] xenbus: Add support for xenbus backend in stub domain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:40:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvX2v-0000G6-16; Thu, 09 Feb 2012 16:40:33 +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 1RvX2s-0000G0-Ui
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:40:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328805591!51792174!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17586 invoked from network); 9 Feb 2012 16:39:51 -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;
	9 Feb 2012 16:39:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:40:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	16:40:29 +0000
Message-ID: <1328805627.6133.232.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:40:27 +0000
In-Reply-To: <alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:18 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > > > again not a great protocol, but very well known and understood.
> > > > > > 
> > > > > > I don't think we have, in general, a good understanding of these
> > > > > > "state" based protocols ...
> > > > > 
> > > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > > 
> > > > And no one I know is able to describe, accurately, exactly what the
> > > > state diagram for even one of those actually looks like or indeed should
> > > > look like. It became quite evident in these threads about hotplug script
> > > > handling etc that no one really knows for sure what (is supposed to)
> > > > happens when.
> > > 
> > > I thought that most of the thread was about the interface with the block
> > > scripts, that is an entirely different matter and completely obscure.
> > > If I am mistaken, please point me at the right email.
> > 
> > We are talking about reusing the existing xenbus state machine schema
> > for a new purpose. Ian J pointed out that these are not generally well
> > understood, you replied that it was and cited some examples. I pointed
> > out why these were not examples of why this stuff was well understood at
> > all, in fact quite the opposite.
> 
> Sorry but I don't understand how these examples are supposed to be
> "quite the opposite".
> I quite like the idea of being able to read a single source file of less
> than 400 LOC to understand how a protocol works
> (drivers/input/misc/xen-kbdfront.c).

That is not a protocol specification, merely one implementation of it.
What does the BSD driver do? Is it exactly the same as Linux? Should BSD
driver authors be expected to reverse engineer the protocol from the
Linux code? What/who arbitrates when the two behave differently?

> In fact I don't think that understanding the protocol has been an issue
> for the GSoC student that had to write a new one.

Being able to reverse engineer something which works is not proof that
these things are "well understood" in the general case.

> I think we are under influence of a "reiventing the wheel" virus.

I think we are in danger of making the same mistakes again as have been
made with the device protocols and this is what I want to avoid.

Now, perhaps this style of state machine protocol is a reasonable design
choice in this case, but since we are starting afresh here this specific
new instance should be well documented _up_front_ not left in the "oh,
just read the Linux code" state we have now for many of our devices
which has lead to multiple slightly divergent implementations of the
same basic concept.

> > > > Justin just posted a good description for blkif.h which included a state
> > > > machine description. We need the same for pciif.h, netif.h etc etc.
> > >  
> > > The state machine is the same for block and network.
> > 
> > No, it's not. This is exactly what IanJ and I are talking about.
> 
> Could you please elaborate?
> 
> I am sure you know that the xenstore state machine is handled the same
> way for all the backends in QEMU (see hw/xen_backend.c).
> And the same thing is true for the frontends and the backends in Linux.

A substantial proportion of the threads about this hotplug script stuff
has been about the fact that no one is quite sure what really happens
when for all implementations nor what the common semantics are.

e.g. How do you ask a backend to shut down (do you set it to state 5?
state 6? do you nuke the xenstore dir?). Neither is anyone sure when the
correct point to call the hotplug scripts actually is, or even what
actually happens with them right now across the different backend
drivers or kernel types.

The actual state transitions which netback and blkback go through are
not the same: The netback protocol uses InitWait, the blkback one does
not or is it vice-versa? I can't remember and it isn't documented. Some
Linux frontends handled the kexec reconnect sequencing differently, by
disconnecting or reconnecting the actual underlying devices at subtly
different times and/or handling the transition from Closing back to Init
or InitWait differently.

And this is just for Linux talking to Linux.

I know for sure that the Windows frontends follow a different state
transition path to Linux (and that it has interacted badly with the
kexec differences in the Linux backends discussed above). I bet BSD has
some subtle differences in behaviour too.

The fact is that none of our device state machine protocols are not well
documented (although blkif.h is about to be). If this stuff were well
understood we would already have such documentation because it would be
trivial to write -- but it is not. If you disagree then please document
the netif state machine protocol in the form of a patch to netif.h.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:40:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvX2v-0000G6-16; Thu, 09 Feb 2012 16:40:33 +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 1RvX2s-0000G0-Ui
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:40:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328805591!51792174!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17586 invoked from network); 9 Feb 2012 16:39:51 -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;
	9 Feb 2012 16:39:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:40:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	16:40:29 +0000
Message-ID: <1328805627.6133.232.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 9 Feb 2012 16:40:27 +0000
In-Reply-To: <alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:18 +0000, Stefano Stabellini wrote:
> On Thu, 9 Feb 2012, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > > > again not a great protocol, but very well known and understood.
> > > > > > 
> > > > > > I don't think we have, in general, a good understanding of these
> > > > > > "state" based protocols ...
> > > > > 
> > > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > > 
> > > > And no one I know is able to describe, accurately, exactly what the
> > > > state diagram for even one of those actually looks like or indeed should
> > > > look like. It became quite evident in these threads about hotplug script
> > > > handling etc that no one really knows for sure what (is supposed to)
> > > > happens when.
> > > 
> > > I thought that most of the thread was about the interface with the block
> > > scripts, that is an entirely different matter and completely obscure.
> > > If I am mistaken, please point me at the right email.
> > 
> > We are talking about reusing the existing xenbus state machine schema
> > for a new purpose. Ian J pointed out that these are not generally well
> > understood, you replied that it was and cited some examples. I pointed
> > out why these were not examples of why this stuff was well understood at
> > all, in fact quite the opposite.
> 
> Sorry but I don't understand how these examples are supposed to be
> "quite the opposite".
> I quite like the idea of being able to read a single source file of less
> than 400 LOC to understand how a protocol works
> (drivers/input/misc/xen-kbdfront.c).

That is not a protocol specification, merely one implementation of it.
What does the BSD driver do? Is it exactly the same as Linux? Should BSD
driver authors be expected to reverse engineer the protocol from the
Linux code? What/who arbitrates when the two behave differently?

> In fact I don't think that understanding the protocol has been an issue
> for the GSoC student that had to write a new one.

Being able to reverse engineer something which works is not proof that
these things are "well understood" in the general case.

> I think we are under influence of a "reiventing the wheel" virus.

I think we are in danger of making the same mistakes again as have been
made with the device protocols and this is what I want to avoid.

Now, perhaps this style of state machine protocol is a reasonable design
choice in this case, but since we are starting afresh here this specific
new instance should be well documented _up_front_ not left in the "oh,
just read the Linux code" state we have now for many of our devices
which has lead to multiple slightly divergent implementations of the
same basic concept.

> > > > Justin just posted a good description for blkif.h which included a state
> > > > machine description. We need the same for pciif.h, netif.h etc etc.
> > >  
> > > The state machine is the same for block and network.
> > 
> > No, it's not. This is exactly what IanJ and I are talking about.
> 
> Could you please elaborate?
> 
> I am sure you know that the xenstore state machine is handled the same
> way for all the backends in QEMU (see hw/xen_backend.c).
> And the same thing is true for the frontends and the backends in Linux.

A substantial proportion of the threads about this hotplug script stuff
has been about the fact that no one is quite sure what really happens
when for all implementations nor what the common semantics are.

e.g. How do you ask a backend to shut down (do you set it to state 5?
state 6? do you nuke the xenstore dir?). Neither is anyone sure when the
correct point to call the hotplug scripts actually is, or even what
actually happens with them right now across the different backend
drivers or kernel types.

The actual state transitions which netback and blkback go through are
not the same: The netback protocol uses InitWait, the blkback one does
not or is it vice-versa? I can't remember and it isn't documented. Some
Linux frontends handled the kexec reconnect sequencing differently, by
disconnecting or reconnecting the actual underlying devices at subtly
different times and/or handling the transition from Closing back to Init
or InitWait differently.

And this is just for Linux talking to Linux.

I know for sure that the Windows frontends follow a different state
transition path to Linux (and that it has interacted badly with the
kexec differences in the Linux backends discussed above). I bet BSD has
some subtle differences in behaviour too.

The fact is that none of our device state machine protocols are not well
documented (although blkif.h is about to be). If this stuff were well
understood we would already have such documentation because it would be
trivial to write -- but it is not. If you disagree then please document
the netif state machine protocol in the form of a patch to netif.h.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:41:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvX3W-0000Hz-PX; Thu, 09 Feb 2012 16:41:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvX3V-0000Hi-Lc
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:41:09 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328805660!8498273!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18175 invoked from network); 9 Feb 2012 16:41:03 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 16:41:03 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19Gesv4055315
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 09:40:55 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20275.58263.859206.482623@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 09:40:58 -0700
Message-Id: <BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
	<20275.58263.859206.482623@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Thu, 09 Feb 2012 09:40:55 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
	block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 9, 2012, at 8:17 AM, Ian Jackson wrote:

> Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
>> I wasn't aware of this file.  After a brief look, it seems there is
>> information missing from both vbd-interface.txt and blkif.h.  Per
>> vbd-interface.txt, there is also an error in blkif.h.  The "virtual-device"
>> node must tolerate 32bit integers.
>> 
>> I'll fix the size specification for the "virtual-device" node, but how
>> should I reconcile blkif.h and vbd-interface.txt.  I hate information
>> duplication since one version is invariably stale.
> 
> I wrote vbd-interface.txt and I think it's largely accurate.  I wasn't
> aware of any duplication with blkif.h.  If there are differences then
> we will have to discuss them here I think, or read the code.
> 
> Ian.

I was thinking that the high numbered SCSI disk major numbers
were not covered by vbd-interface.txt.  In looking more closely,
they seem to be covered in "Notes on Linux as a guest".  However,
is this text accurate: 

  "Some old configurations may depend on deprecated
   high-numbered SCSI and IDE disks.  This does not work in
   recent versions of Linux."

The upstreamed Linux driver supports 15 SCSI major numbers.
Are 13 of these the "deprecated high-numbered" ones, or were
there more than 15 at some point?

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:41:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvX3W-0000Hz-PX; Thu, 09 Feb 2012 16:41:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvX3V-0000Hi-Lc
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:41:09 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328805660!8498273!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18175 invoked from network); 9 Feb 2012 16:41:03 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 16:41:03 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19Gesv4055315
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 09:40:55 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20275.58263.859206.482623@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 09:40:58 -0700
Message-Id: <BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
	<20275.58263.859206.482623@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Thu, 09 Feb 2012 09:40:55 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
	block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 9, 2012, at 8:17 AM, Ian Jackson wrote:

> Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
>> I wasn't aware of this file.  After a brief look, it seems there is
>> information missing from both vbd-interface.txt and blkif.h.  Per
>> vbd-interface.txt, there is also an error in blkif.h.  The "virtual-device"
>> node must tolerate 32bit integers.
>> 
>> I'll fix the size specification for the "virtual-device" node, but how
>> should I reconcile blkif.h and vbd-interface.txt.  I hate information
>> duplication since one version is invariably stale.
> 
> I wrote vbd-interface.txt and I think it's largely accurate.  I wasn't
> aware of any duplication with blkif.h.  If there are differences then
> we will have to discuss them here I think, or read the code.
> 
> Ian.

I was thinking that the high numbered SCSI disk major numbers
were not covered by vbd-interface.txt.  In looking more closely,
they seem to be covered in "Notes on Linux as a guest".  However,
is this text accurate: 

  "Some old configurations may depend on deprecated
   high-numbered SCSI and IDE disks.  This does not work in
   recent versions of Linux."

The upstreamed Linux driver supports 15 SCSI major numbers.
Are 13 of these the "deprecated high-numbered" ones, or were
there more than 15 at some point?

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:42:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvX4B-0000Ly-TL; Thu, 09 Feb 2012 16:41:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvX49-0000L2-KE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:41:50 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328805702!4326461!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21211 invoked from network); 9 Feb 2012 16:41:43 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 16:41:43 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19Gesv5055315
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 09:41:39 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80EF535EE@LONPMAILBOX01.citrite.net>
Date: Thu, 9 Feb 2012 09:41:47 -0700
Message-Id: <462CAE07-3506-44ED-B9C7-0A1E105C3727@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
	<AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
	<1328780817.6133.133.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80EF535EE@LONPMAILBOX01.citrite.net>
To: Paul Durrant <Paul.Durrant@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Thu, 09 Feb 2012 09:41:39 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
	block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 9, 2012, at 3:05 AM, Paul Durrant wrote:

>> -----Original Message-----
>> QEMU emulates primary and secondary IDE master+slave, it has no concept
>> of a major or minor number. Why does the dom0 numbering scheme
>> matter?
> 
> For Windows PV drivers I parse the vbd number so I can extract the disk number which is then present as the scsi target id. I'd prefer if vbd-interface.txt remained the canonical place where the numbering scheme is specified though. Putting definitions into blkif.h just weakens that position.

I'll update the patch to just reference vbd-interface.txt.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:42:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvX4B-0000Ly-TL; Thu, 09 Feb 2012 16:41:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RvX49-0000L2-KE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:41:50 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328805702!4326461!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21211 invoked from network); 9 Feb 2012 16:41:43 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 16:41:43 -0000
Received: from jlan-freebsd-comexp.sldomain.com
	(207-225-98-3.dia.static.qwest.net [207.225.98.3])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q19Gesv5055315
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 9 Feb 2012 09:41:39 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80EF535EE@LONPMAILBOX01.citrite.net>
Date: Thu, 9 Feb 2012 09:41:47 -0700
Message-Id: <462CAE07-3506-44ED-B9C7-0A1E105C3727@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<4F2BEFD70200007800070EA0@nat28.tlf.novell.com>
	<AED8BA2D-4AD1-4659-BA08-09018EA071C9@spectralogic.com>
	<1328780817.6133.133.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80EF535EE@LONPMAILBOX01.citrite.net>
To: Paul Durrant <Paul.Durrant@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Thu, 09 Feb 2012 09:41:39 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
	block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 9, 2012, at 3:05 AM, Paul Durrant wrote:

>> -----Original Message-----
>> QEMU emulates primary and secondary IDE master+slave, it has no concept
>> of a major or minor number. Why does the dom0 numbering scheme
>> matter?
> 
> For Windows PV drivers I parse the vbd number so I can extract the disk number which is then present as the scsi target id. I'd prefer if vbd-interface.txt remained the canonical place where the numbering scheme is specified though. Putting definitions into blkif.h just weakens that position.

I'll update the patch to just reference vbd-interface.txt.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:46:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvX81-0000gM-0u; Thu, 09 Feb 2012 16:45:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvX7y-0000fy-UE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:45:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328805940!12723844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24833 invoked from network); 9 Feb 2012 16:45:40 -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;
	9 Feb 2012 16:45:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:45:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:45:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvX7r-0004Gk-Vk; Thu, 09 Feb 2012 16:45:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvX7r-0002TC-Uy;
	Thu, 09 Feb 2012 16:45:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.63539.946253.127969@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:45:39 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <264ae15cae53cbc4dc22.1328711071@cosworth.uk.xensource.com>
References: <264ae15cae53cbc4dc22.1328711071@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Todd Deshane <todd.deshane@xen.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] stubdoms: update README to reference
	xl	configuration syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] stubdoms: update README to reference xl configuration syntax"):
> stubdoms: update README to reference xl configuration syntax

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:46:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16: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.xensource.com>)
	id 1RvX81-0000gM-0u; Thu, 09 Feb 2012 16:45:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvX7y-0000fy-UE
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:45:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328805940!12723844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24833 invoked from network); 9 Feb 2012 16:45:40 -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;
	9 Feb 2012 16:45:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:45:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:45:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvX7r-0004Gk-Vk; Thu, 09 Feb 2012 16:45:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvX7r-0002TC-Uy;
	Thu, 09 Feb 2012 16:45:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.63539.946253.127969@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:45:39 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <264ae15cae53cbc4dc22.1328711071@cosworth.uk.xensource.com>
References: <264ae15cae53cbc4dc22.1328711071@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Todd Deshane <todd.deshane@xen.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] stubdoms: update README to reference
	xl	configuration syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] stubdoms: update README to reference xl configuration syntax"):
> stubdoms: update README to reference xl configuration syntax

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:52:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXED-00012n-HY; Thu, 09 Feb 2012 16:52: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 1RvXEC-00012d-0F
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:52:12 +0000
Received: from [85.158.139.83:51519] by server-4.bemta-5.messagelabs.com id
	98/AA-28576-BB9F33F4; Thu, 09 Feb 2012 16:52:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328806330!14422861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18087 invoked from network); 9 Feb 2012 16:52:10 -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;
	9 Feb 2012 16:52:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:52:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:52:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXE9-0004Mo-AU; Thu, 09 Feb 2012 16:52:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXE9-0002ad-9X;
	Thu, 09 Feb 2012 16:52:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.63929.281245.19908@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:52:09 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
	<20275.58263.859206.482623@mariner.uk.xensource.com>
	<BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> The upstreamed Linux driver supports 15 SCSI major numbers.
> Are 13 of these the "deprecated high-numbered" ones, or were
> there more than 15 at some point?

My understanding was that current upstream Linux does not ever "steal"
scsi major numbers for xen vbds.  If this is wrong then so is my
document :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:52:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXED-00012n-HY; Thu, 09 Feb 2012 16:52: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 1RvXEC-00012d-0F
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:52:12 +0000
Received: from [85.158.139.83:51519] by server-4.bemta-5.messagelabs.com id
	98/AA-28576-BB9F33F4; Thu, 09 Feb 2012 16:52:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328806330!14422861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18087 invoked from network); 9 Feb 2012 16:52:10 -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;
	9 Feb 2012 16:52:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 16:52:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 16:52:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXE9-0004Mo-AU; Thu, 09 Feb 2012 16:52:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXE9-0002ad-9X;
	Thu, 09 Feb 2012 16:52:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.63929.281245.19908@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 16:52:09 +0000
To: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
	<20275.58263.859206.482623@mariner.uk.xensource.com>
	<BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> The upstreamed Linux driver supports 15 SCSI major numbers.
> Are 13 of these the "deprecated high-numbered" ones, or were
> there more than 15 at some point?

My understanding was that current upstream Linux does not ever "steal"
scsi major numbers for xen vbds.  If this is wrong then so is my
document :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:54:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXGC-00017W-4G; Thu, 09 Feb 2012 16:54:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvXG9-00017A-8n
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328806447!10865617!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13878 invoked from network); 9 Feb 2012 16:54:07 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 16:54:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328806447; l=1028;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=NJTAwUpyCZUZI8f6bzF0LE5iq/I=;
	b=PMGeC7jAT+2J5uh7d0NN3p5rlHPxdvPmdHsVRQf4WHRaooYyLri1EL0ElROrECAR6xi
	ZqyOpnhp/Xt/NMKSYHkz6JUVzIielnDnn9vfznrHgU4bR4WX2Q1yGDQG3UUPmIzRZWIZi
	Xg5xpp0Vn+z9ANio7EmnjYzWx7OZa66tVpI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (fruni mo58) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p056aeo19FWb1F
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 17:53:47 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id EAAEE18634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 17:53:53 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 151288df7766f566f49ae0e273682829cf31725c
Message-Id: <151288df7766f566f49a.1328806433@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 17:53:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] docs/man: correct autoballoon in xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328806399 -3600
# Node ID 151288df7766f566f49ae0e273682829cf31725c
# Parent  5497b65d7398a88ee7ac26ffd6f8ddd8143c4253
docs/man: correct autoballoon in xl.conf

Correct wording and default value of autoballoon= in xl.conf(5)
to match code and supplied xl.conf.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 5497b65d7398 -r 151288df7766 docs/man/xl.conf.pod.5
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -47,13 +47,13 @@ The semantics of each C<KEY> defines whi
 
 =item B<autoballoon=BOOLEAN>
 
-If enabled then C<xl> will not attempt to reduce the amount of memory
+If disabled then C<xl> will not attempt to reduce the amount of memory
 assigned to domain 0 in order to create free memory when starting a
 new domain. You should set this if you use the C<dom0_mem> hypervisor
 command line to reduce the amount of memory given to domain 0 by
 default.
 
-Default: C<0>
+Default: C<1>
 
 =item B<lockfile="PATH">
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:54:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXGC-00017W-4G; Thu, 09 Feb 2012 16:54:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvXG9-00017A-8n
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328806447!10865617!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNzIyODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13878 invoked from network); 9 Feb 2012 16:54:07 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Feb 2012 16:54:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328806447; l=1028;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=NJTAwUpyCZUZI8f6bzF0LE5iq/I=;
	b=PMGeC7jAT+2J5uh7d0NN3p5rlHPxdvPmdHsVRQf4WHRaooYyLri1EL0ElROrECAR6xi
	ZqyOpnhp/Xt/NMKSYHkz6JUVzIielnDnn9vfznrHgU4bR4WX2Q1yGDQG3UUPmIzRZWIZi
	Xg5xpp0Vn+z9ANio7EmnjYzWx7OZa66tVpI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (fruni mo58) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p056aeo19FWb1F
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 17:53:47 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id EAAEE18634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 17:53:53 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 151288df7766f566f49ae0e273682829cf31725c
Message-Id: <151288df7766f566f49a.1328806433@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 17:53:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] docs/man: correct autoballoon in xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328806399 -3600
# Node ID 151288df7766f566f49ae0e273682829cf31725c
# Parent  5497b65d7398a88ee7ac26ffd6f8ddd8143c4253
docs/man: correct autoballoon in xl.conf

Correct wording and default value of autoballoon= in xl.conf(5)
to match code and supplied xl.conf.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 5497b65d7398 -r 151288df7766 docs/man/xl.conf.pod.5
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -47,13 +47,13 @@ The semantics of each C<KEY> defines whi
 
 =item B<autoballoon=BOOLEAN>
 
-If enabled then C<xl> will not attempt to reduce the amount of memory
+If disabled then C<xl> will not attempt to reduce the amount of memory
 assigned to domain 0 in order to create free memory when starting a
 new domain. You should set this if you use the C<dom0_mem> hypervisor
 command line to reduce the amount of memory given to domain 0 by
 default.
 
-Default: C<0>
+Default: C<1>
 
 =item B<lockfile="PATH">
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:57:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXJ4-0001JL-65; Thu, 09 Feb 2012 16:57:14 +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 1RvXJ2-0001JC-0v
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:57:12 +0000
Received: from [85.158.139.83:38266] by server-9.bemta-5.messagelabs.com id
	31/CC-23757-7EAF33F4; Thu, 09 Feb 2012 16:57:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328806630!14342227!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5975 invoked from network); 9 Feb 2012 16:57:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 16:57:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328806630; l=543;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=l/3U3e+4Nh9Q3UT35yNawdIGDzk=;
	b=x0xIlmJtCdX5k09aik6i50JeTtwj2x4v3xYqexjO5Uycy7Na5hpYsMk3nahOgq9qPym
	VmIkiJa6AwL0czDZUB1dR4IhOAekPz8BaJOFj8jAaTVP5mvMvW9hK6BRL5Pmv5gXzcxSz
	2hLq3DoY1Q66PdmW+ziR+cGEMpGun+OhqXI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (jimi mo23) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I010dco19FbHsE
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 17:56:50 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0EF9318634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 17:56:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c42517c528976cc5d6d6ac867f844e855b4abf34
Message-Id: <c42517c528976cc5d6d6.1328806615@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 17:56:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mention output_format= in examples/xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328806591 -3600
# Node ID c42517c528976cc5d6d6ac867f844e855b4abf34
# Parent  151288df7766f566f49ae0e273682829cf31725c
mention output_format= in examples/xl.conf

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 151288df7766 -r c42517c52897 tools/examples/xl.conf
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -9,3 +9,6 @@
 
 # default vif script 
 #vifscript="vif-bridge"
+
+# default output format used by "xl list -l"
+#output_format="json"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 16:57:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 16:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXJ4-0001JL-65; Thu, 09 Feb 2012 16:57:14 +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 1RvXJ2-0001JC-0v
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 16:57:12 +0000
Received: from [85.158.139.83:38266] by server-9.bemta-5.messagelabs.com id
	31/CC-23757-7EAF33F4; Thu, 09 Feb 2012 16:57:11 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328806630!14342227!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5975 invoked from network); 9 Feb 2012 16:57:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 16:57:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328806630; l=543;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=l/3U3e+4Nh9Q3UT35yNawdIGDzk=;
	b=x0xIlmJtCdX5k09aik6i50JeTtwj2x4v3xYqexjO5Uycy7Na5hpYsMk3nahOgq9qPym
	VmIkiJa6AwL0czDZUB1dR4IhOAekPz8BaJOFj8jAaTVP5mvMvW9hK6BRL5Pmv5gXzcxSz
	2hLq3DoY1Q66PdmW+ziR+cGEMpGun+OhqXI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (jimi mo23) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I010dco19FbHsE
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 17:56:50 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0EF9318634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 17:56:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c42517c528976cc5d6d6ac867f844e855b4abf34
Message-Id: <c42517c528976cc5d6d6.1328806615@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 17:56:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mention output_format= in examples/xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328806591 -3600
# Node ID c42517c528976cc5d6d6ac867f844e855b4abf34
# Parent  151288df7766f566f49ae0e273682829cf31725c
mention output_format= in examples/xl.conf

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 151288df7766 -r c42517c52897 tools/examples/xl.conf
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -9,3 +9,6 @@
 
 # default vif script 
 #vifscript="vif-bridge"
+
+# default output format used by "xl list -l"
+#output_format="json"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:00:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXMB-0001W4-2V; Thu, 09 Feb 2012 17:00:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RvXM9-0001Vr-F9
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:00:25 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328806816!14334081!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1443 invoked from network); 9 Feb 2012 17:00:16 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-14.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 17:00:16 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q19H09gi029003;
	Thu, 9 Feb 2012 12:00:09 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q19H093o006685;
	Thu, 9 Feb 2012 12:00:09 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020912000801452 ; Thu, 09 Feb 2012 12:00:08 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/mixed; boundary=Apple-Mail-20-459774478
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1328803780.6133.210.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 12:00:08 -0500
Message-Id: <554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--Apple-Mail-20-459774478
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ian,

There is also an unused variable warning in xenbus/xenbus.c. I think the =
compiler should not be warning about this, as the reasonable definition =
of the local DEBUG macro is the cause? Anyways, here is an ugly fix that =
shows where the problem is raised. I tried the old trick of defining the =
variables as volatile, but the new gcc won't let it go by. It won't hurt =
my feelings if you don't use this patch.



--Apple-Mail-20-459774478
Content-Disposition: attachment;
	filename=patch02.diff
Content-Type: application/octet-stream;
	name="patch02.diff"
Content-Transfer-Encoding: 7bit

# HG changeset patch
# Parent 4b43dc4c31c3daa6ca2544af062044210f7ad189
mini-os: stop compiler complaint about unused variables

gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused variables
in mini-os drivers. In this case, gcc is probably wrong to warn about
the construction of the DEBUG macro.

Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

diff -r 4b43dc4c31c3 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Thu Feb 09 09:47:34 2012 -0500
+++ b/extras/mini-os/xenbus/xenbus.c	Thu Feb 09 11:58:10 2012 -0500
@@ -37,8 +37,10 @@
 #ifdef XENBUS_DEBUG
 #define DEBUG(_f, _a...) \
     printk("MINI_OS(file=xenbus.c, line=%d) " _f , __LINE__, ## _a)
+#define COND(e) e
 #else
 #define DEBUG(_f, _a...)    ((void)0)
+#define COND(e)
 #endif
 
 static struct xenstore_domain_interface *xenstore_buf;
@@ -327,13 +331,14 @@ static int allocate_xenbus_id(void)
 /* Initialise xenbus. */
 void init_xenbus(void)
 {
-    int err;
+    COND(int err;)
     printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
     create_thread("xenstore", xenbus_thread_func, NULL);
     DEBUG("buf at %p.\n", xenstore_buf);
-    err = bind_evtchn(start_info.store_evtchn,
+
+    COND(err = ) bind_evtchn(start_info.store_evtchn,
 		      xenbus_evtchn_handler,
               NULL);
     unmask_evtchn(start_info.store_evtchn);
@@ -475,11 +480,17 @@ static void xenbus_debug_msg(const char 
         { "print", sizeof("print") },
         { msg, len },
         { "", 1 }};
+#ifdef XENBUS_DEBUG
     struct xsd_sockmsg *reply;
+#endif
 
+#ifdef XENBUS_DEBUG
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
     DEBUG("Got a reply, type %d, id %d, len %d.\n",
             reply->type, reply->req_id, reply->len);
+#else
+    xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
+#endif
 }
 
 /* List the contents of a directory.  Returns a malloc()ed array of

--Apple-Mail-20-459774478
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



Sincerely,

John
=20
On Feb 9, 2012, at 11:09 AM, Ian Campbell wrote:

> On Thu, 2012-02-09 at 16:08 +0000, Ian Jackson wrote:
>> Keir Fraser writes ("Re: [Xen-devel] Mini-os fbfront.c unused =
variable complaint"):
>>> We should be disablign this warning in Config.mk, where we add
>>> -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do =
the
>>> same, if it is creating its own CFLAGS? Note that we add it in =
Config.mk via
>>> $(call cc-option-add ...) because older gcc versions do not have =
this
>>> warning.
>>=20
>> Personally in this case I like the new warning.  Shall we at least
>> wait with disabling it until we get an actual false positive ?
>=20
> Yes, lets.
>=20
> Ian

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











--Apple-Mail-20-459774478
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Apple-Mail-20-459774478--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:00:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXMB-0001W4-2V; Thu, 09 Feb 2012 17:00:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RvXM9-0001Vr-F9
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:00:25 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328806816!14334081!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1443 invoked from network); 9 Feb 2012 17:00:16 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-14.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 17:00:16 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q19H09gi029003;
	Thu, 9 Feb 2012 12:00:09 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q19H093o006685;
	Thu, 9 Feb 2012 12:00:09 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020912000801452 ; Thu, 09 Feb 2012 12:00:08 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/mixed; boundary=Apple-Mail-20-459774478
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1328803780.6133.210.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 12:00:08 -0500
Message-Id: <554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--Apple-Mail-20-459774478
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ian,

There is also an unused variable warning in xenbus/xenbus.c. I think the =
compiler should not be warning about this, as the reasonable definition =
of the local DEBUG macro is the cause? Anyways, here is an ugly fix that =
shows where the problem is raised. I tried the old trick of defining the =
variables as volatile, but the new gcc won't let it go by. It won't hurt =
my feelings if you don't use this patch.



--Apple-Mail-20-459774478
Content-Disposition: attachment;
	filename=patch02.diff
Content-Type: application/octet-stream;
	name="patch02.diff"
Content-Transfer-Encoding: 7bit

# HG changeset patch
# Parent 4b43dc4c31c3daa6ca2544af062044210f7ad189
mini-os: stop compiler complaint about unused variables

gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused variables
in mini-os drivers. In this case, gcc is probably wrong to warn about
the construction of the DEBUG macro.

Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

diff -r 4b43dc4c31c3 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Thu Feb 09 09:47:34 2012 -0500
+++ b/extras/mini-os/xenbus/xenbus.c	Thu Feb 09 11:58:10 2012 -0500
@@ -37,8 +37,10 @@
 #ifdef XENBUS_DEBUG
 #define DEBUG(_f, _a...) \
     printk("MINI_OS(file=xenbus.c, line=%d) " _f , __LINE__, ## _a)
+#define COND(e) e
 #else
 #define DEBUG(_f, _a...)    ((void)0)
+#define COND(e)
 #endif
 
 static struct xenstore_domain_interface *xenstore_buf;
@@ -327,13 +331,14 @@ static int allocate_xenbus_id(void)
 /* Initialise xenbus. */
 void init_xenbus(void)
 {
-    int err;
+    COND(int err;)
     printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
     create_thread("xenstore", xenbus_thread_func, NULL);
     DEBUG("buf at %p.\n", xenstore_buf);
-    err = bind_evtchn(start_info.store_evtchn,
+
+    COND(err = ) bind_evtchn(start_info.store_evtchn,
 		      xenbus_evtchn_handler,
               NULL);
     unmask_evtchn(start_info.store_evtchn);
@@ -475,11 +480,17 @@ static void xenbus_debug_msg(const char 
         { "print", sizeof("print") },
         { msg, len },
         { "", 1 }};
+#ifdef XENBUS_DEBUG
     struct xsd_sockmsg *reply;
+#endif
 
+#ifdef XENBUS_DEBUG
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
     DEBUG("Got a reply, type %d, id %d, len %d.\n",
             reply->type, reply->req_id, reply->len);
+#else
+    xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
+#endif
 }
 
 /* List the contents of a directory.  Returns a malloc()ed array of

--Apple-Mail-20-459774478
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



Sincerely,

John
=20
On Feb 9, 2012, at 11:09 AM, Ian Campbell wrote:

> On Thu, 2012-02-09 at 16:08 +0000, Ian Jackson wrote:
>> Keir Fraser writes ("Re: [Xen-devel] Mini-os fbfront.c unused =
variable complaint"):
>>> We should be disablign this warning in Config.mk, where we add
>>> -Wno-unused-but-set-variable to CFLAGS. Perhaps mini-os needs to do =
the
>>> same, if it is creating its own CFLAGS? Note that we add it in =
Config.mk via
>>> $(call cc-option-add ...) because older gcc versions do not have =
this
>>> warning.
>>=20
>> Personally in this case I like the new warning.  Shall we at least
>> wait with disabling it until we get an actual false positive ?
>=20
> Yes, lets.
>=20
> Ian

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











--Apple-Mail-20-459774478
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--Apple-Mail-20-459774478--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXOj-0001fo-5K; Thu, 09 Feb 2012 17:03:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvXOh-0001fN-1X
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:03:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328806976!12513425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9827 invoked from network); 9 Feb 2012 17:02:56 -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;
	9 Feb 2012 17:02:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:02:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	17:02:55 +0000
Message-ID: <1328806973.6133.237.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 17:02:53 +0000
In-Reply-To: <20275.63929.281245.19908@mariner.uk.xensource.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
	<20275.58263.859206.482623@mariner.uk.xensource.com>
	<BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
	<20275.63929.281245.19908@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:52 +0000, Ian Jackson wrote:
> Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> > The upstreamed Linux driver supports 15 SCSI major numbers.
> > Are 13 of these the "deprecated high-numbered" ones, or were
> > there more than 15 at some point?
> 
> My understanding was that current upstream Linux does not ever "steal"
> scsi major numbers for xen vbds.  If this is wrong then so is my
> document :-).

Looks like it understands the SCSI/IDE major numbers but translates them
to the xvd major since:
        commit c80a420995e721099906607b07c09a24543b31d9
        Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
        Date:   Thu Dec 2 17:55:00 2010 +0000
        
            xen-blkfront: handle Xen major numbers other than XENVBD
            
            This patch makes sure blkfront handles correctly virtual device numbers
            corresponding to Xen emulated IDE and SCSI disks: in those cases
            blkfront translates the major number to XENVBD and the minor number to a
            low xvd minor.
            
            Note: this behaviour is different from what old xenlinux PV guests used
            to do: they used to steal an IDE or SCSI major number and use it
            instead.
            
            Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
            Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXOj-0001fo-5K; Thu, 09 Feb 2012 17:03:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvXOh-0001fN-1X
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:03:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328806976!12513425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9827 invoked from network); 9 Feb 2012 17:02:56 -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;
	9 Feb 2012 17:02:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:02:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	17:02:55 +0000
Message-ID: <1328806973.6133.237.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 17:02:53 +0000
In-Reply-To: <20275.63929.281245.19908@mariner.uk.xensource.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<65403351f4b4158da7fb.1328246661@ns1.eng.sldomain.com>
	<20273.24695.56347.32673@mariner.uk.xensource.com>
	<1622D889-96CD-4C41-9A1B-CA59FE18F1E0@spectralogic.com>
	<20275.58263.859206.482623@mariner.uk.xensource.com>
	<BA6727C2-520F-4247-99F7-0FFD72FE723B@spectralogic.com>
	<20275.63929.281245.19908@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual
 block device major numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:52 +0000, Ian Jackson wrote:
> Justin T. Gibbs writes ("Re: [Xen-devel] [PATCH 3 of 5] blkif.h: Add definitions for virtual block device major numbers"):
> > The upstreamed Linux driver supports 15 SCSI major numbers.
> > Are 13 of these the "deprecated high-numbered" ones, or were
> > there more than 15 at some point?
> 
> My understanding was that current upstream Linux does not ever "steal"
> scsi major numbers for xen vbds.  If this is wrong then so is my
> document :-).

Looks like it understands the SCSI/IDE major numbers but translates them
to the xvd major since:
        commit c80a420995e721099906607b07c09a24543b31d9
        Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
        Date:   Thu Dec 2 17:55:00 2010 +0000
        
            xen-blkfront: handle Xen major numbers other than XENVBD
            
            This patch makes sure blkfront handles correctly virtual device numbers
            corresponding to Xen emulated IDE and SCSI disks: in those cases
            blkfront translates the major number to XENVBD and the minor number to a
            low xvd minor.
            
            Note: this behaviour is different from what old xenlinux PV guests used
            to do: they used to steal an IDE or SCSI major number and use it
            instead.
            
            Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
            Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:04:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXPm-0001mK-Le; Thu, 09 Feb 2012 17:04:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvXPk-0001la-4s
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:04:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328807041!10866911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 9 Feb 2012 17:04:01 -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;
	9 Feb 2012 17:04:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605851"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:04:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:04:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXPc-0004fz-MZ; Thu, 09 Feb 2012 17:04:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXPc-0002oB-Ln;
	Thu, 09 Feb 2012 17:04:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.64640.659873.173094@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:04:00 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <26217ae46e4549f38936.1328767707@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<26217ae46e4549f38936.1328767707@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 2 of 3] x86/mm: New sharing audit memop"):
> Remove costly mem_sharting audits from the inline path, and instead make them
> callable as a memop.

For the tools parts,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

But a hypervisor maintainer should have the final say.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:04:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXPm-0001mK-Le; Thu, 09 Feb 2012 17:04:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvXPk-0001la-4s
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:04:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328807041!10866911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 9 Feb 2012 17:04:01 -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;
	9 Feb 2012 17:04:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605851"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:04:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:04:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXPc-0004fz-MZ; Thu, 09 Feb 2012 17:04:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXPc-0002oB-Ln;
	Thu, 09 Feb 2012 17:04:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20275.64640.659873.173094@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:04:00 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <26217ae46e4549f38936.1328767707@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<26217ae46e4549f38936.1328767707@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 2 of 3] x86/mm: New sharing audit memop"):
> Remove costly mem_sharting audits from the inline path, and instead make them
> callable as a memop.

For the tools parts,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

But a hypervisor maintainer should have the final say.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:06:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:06:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXRQ-0001wW-KE; Thu, 09 Feb 2012 17:05:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvXRP-0001w5-Bn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:05:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328807144!11216752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7115 invoked from network); 9 Feb 2012 17:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:05:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	17:05:43 +0000
Message-ID: <1328807142.6133.238.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 17:05:42 +0000
In-Reply-To: <c42517c528976cc5d6d6.1328806615@probook.site>
References: <c42517c528976cc5d6d6.1328806615@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] mention output_format= in examples/xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:56 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1328806591 -3600
> # Node ID c42517c528976cc5d6d6ac867f844e855b4abf34
> # Parent  151288df7766f566f49ae0e273682829cf31725c
> mention output_format= in examples/xl.conf
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> 
> diff -r 151288df7766 -r c42517c52897 tools/examples/xl.conf
> --- a/tools/examples/xl.conf
> +++ b/tools/examples/xl.conf
> @@ -9,3 +9,6 @@
>  
>  # default vif script 
>  #vifscript="vif-bridge"
> +
> +# default output format used by "xl list -l"
> +#output_format="json"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:06:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:06:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXRQ-0001wW-KE; Thu, 09 Feb 2012 17:05:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvXRP-0001w5-Bn
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:05:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328807144!11216752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7115 invoked from network); 9 Feb 2012 17:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10605892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:05:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	17:05:43 +0000
Message-ID: <1328807142.6133.238.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 9 Feb 2012 17:05:42 +0000
In-Reply-To: <c42517c528976cc5d6d6.1328806615@probook.site>
References: <c42517c528976cc5d6d6.1328806615@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] mention output_format= in examples/xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 16:56 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1328806591 -3600
> # Node ID c42517c528976cc5d6d6ac867f844e855b4abf34
> # Parent  151288df7766f566f49ae0e273682829cf31725c
> mention output_format= in examples/xl.conf
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.

> 
> diff -r 151288df7766 -r c42517c52897 tools/examples/xl.conf
> --- a/tools/examples/xl.conf
> +++ b/tools/examples/xl.conf
> @@ -9,3 +9,6 @@
>  
>  # default vif script 
>  #vifscript="vif-bridge"
> +
> +# default output format used by "xl list -l"
> +#output_format="json"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXXo-0002I8-S7; Thu, 09 Feb 2012 17:12:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RvXXn-0002I3-Pq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:12:28 +0000
Received: from [85.158.139.83:3788] by server-4.bemta-5.messagelabs.com id
	BE/3C-28576-B7EF33F4; Thu, 09 Feb 2012 17:12:27 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328807544!14441756!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11923 invoked from network); 9 Feb 2012 17:12:26 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:12:26 -0000
Received: by pbbro2 with SMTP id ro2so7323944pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 09:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=QywZbZJD1xWA7lr1d851eKcVvgsSC7fpkvkfzL8FRRE=;
	b=FQLLCYIBnzrzuusniN4/1/l+IF5zNIt+fFLx4B+BYHVp89NGER3HR2MrTdqtab3nQM
	xUHKIj1lkDIpc//mJOVNPfSagIZkZBKpLyDgSvvNr3QXGnftl/Y3YKu1LUZtuwLyQy3l
	MewXVQOzkM1zEZuEsFa66gXiSkWneO8Tiq9z0=
MIME-Version: 1.0
Received: by 10.68.219.234 with SMTP id pr10mr8043212pbc.11.1328807543376;
	Thu, 09 Feb 2012 09:12:23 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Thu, 9 Feb 2012 09:12:23 -0800 (PST)
Date: Fri, 10 Feb 2012 01:12:23 +0800
Message-ID: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm xl
 not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I need to check whether is this intended?  When using xl create hvm
domains, it does execute vif-bridge script.  However, when doing xl
destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
script.  I just did the following to test:

# cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
# cat > /etc/xen/scripts/vif-bridge <<'EOF'
#!/bin/bash
echo "$@" >> vif-bridge.log
/etc/xen/scripts/vif-bridge.orig "$@"
EOF

When using xm and xl to create hvmdomain, I can see vif-bridge.log
appended with:

online type_if=vif
online type_if=vif
add type_if=tap
add type_if=tap

Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
gets to execute vif-bridge once for each vif which looks right.

Now the problem is xl trigger hvmdomain power and xl destroy power.
Both never call vif-bridge script as there isn't any such line like:

offline type_if=vif
offline type_if=vif

Whereby when I tried with xm trigger hvmdomain power, it does call
vif-bridge script as the above two lines get logged.

This will leave the iptables FORWARD rule intact when using xl which I
reported before :(

See http://www.gossamer-threads.com/lists/xen/devel/204990

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXXo-0002I8-S7; Thu, 09 Feb 2012 17:12:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RvXXn-0002I3-Pq
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:12:28 +0000
Received: from [85.158.139.83:3788] by server-4.bemta-5.messagelabs.com id
	BE/3C-28576-B7EF33F4; Thu, 09 Feb 2012 17:12:27 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328807544!14441756!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11923 invoked from network); 9 Feb 2012 17:12:26 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:12:26 -0000
Received: by pbbro2 with SMTP id ro2so7323944pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 09:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=QywZbZJD1xWA7lr1d851eKcVvgsSC7fpkvkfzL8FRRE=;
	b=FQLLCYIBnzrzuusniN4/1/l+IF5zNIt+fFLx4B+BYHVp89NGER3HR2MrTdqtab3nQM
	xUHKIj1lkDIpc//mJOVNPfSagIZkZBKpLyDgSvvNr3QXGnftl/Y3YKu1LUZtuwLyQy3l
	MewXVQOzkM1zEZuEsFa66gXiSkWneO8Tiq9z0=
MIME-Version: 1.0
Received: by 10.68.219.234 with SMTP id pr10mr8043212pbc.11.1328807543376;
	Thu, 09 Feb 2012 09:12:23 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Thu, 9 Feb 2012 09:12:23 -0800 (PST)
Date: Fri, 10 Feb 2012 01:12:23 +0800
Message-ID: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm xl
 not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I need to check whether is this intended?  When using xl create hvm
domains, it does execute vif-bridge script.  However, when doing xl
destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
script.  I just did the following to test:

# cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
# cat > /etc/xen/scripts/vif-bridge <<'EOF'
#!/bin/bash
echo "$@" >> vif-bridge.log
/etc/xen/scripts/vif-bridge.orig "$@"
EOF

When using xm and xl to create hvmdomain, I can see vif-bridge.log
appended with:

online type_if=vif
online type_if=vif
add type_if=tap
add type_if=tap

Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
gets to execute vif-bridge once for each vif which looks right.

Now the problem is xl trigger hvmdomain power and xl destroy power.
Both never call vif-bridge script as there isn't any such line like:

offline type_if=vif
offline type_if=vif

Whereby when I tried with xm trigger hvmdomain power, it does call
vif-bridge script as the above two lines get logged.

This will leave the iptables FORWARD rule intact when using xl which I
reported before :(

See http://www.gossamer-threads.com/lists/xen/devel/204990

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:18:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXdP-0002VC-KP; Thu, 09 Feb 2012 17:18:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvXdN-0002Um-Ou
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:18:14 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328807886!10843550!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24249 invoked from network); 9 Feb 2012 17:18:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 17:18:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328807886; l=1509;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=2WtGdG2fzzArKpGDDONkPR8/gjI=;
	b=wNfKN9hdti+lJ4/MRvm9QyoYdKq+bSsjf9VZdqU96W3F91zbauoysFM4vOfG1ohvcbo
	ngW0pcNPWCAUoTTjlfD2Tav5XMLxgw8dzQ9zzCWjwOkYRM6jkHKKSJlt0fFuU0D7NQwGb
	0RVoax1UzkdgJpDGlpmgzAAhjBiNU4dJGPw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo33) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c00272o19FcF5m
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 18:18:01 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 951CE18634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 18:18:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 7dadba19566dc9e1dfaf7202ab92b998999a143f
Message-Id: <7dadba19566dc9e1dfaf.1328807886@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 18:18:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel
	in xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328807859 -3600
# Node ID 7dadba19566dc9e1dfaf7202ab92b998999a143f
# Parent  c42517c528976cc5d6d6ac867f844e855b4abf34
tools/hotplug: remove 4 from default runlevel in xencommons

LSB defines runlevel 4 as "reserved for local use, default is
normal/full multiuser"

The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
Default-Start: line. As a result insserv will print a warning:

insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).

Since the local admin is responsible to create all symlinks manually in
/etc/init.d/rc4.d/ the xencommons script should not automatically enable
itself in runlevel 4.

So, remove the 4 from Default-Start: line.

Note: This change will not automatically remove old/stale xencommon
symlinks in /etc/init.d/rc4.d/ during a package upgrade.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c42517c52897 -r 7dadba19566d tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -12,7 +12,7 @@
 # Should-Start:
 # Required-Stop:     $syslog $remote_fs
 # Should-Stop:
-# Default-Start:     2 3 4 5
+# Default-Start:     2 3 5
 # Default-Stop:      0 1 6
 # Short-Description: Start/stop xenstored and xenconsoled
 # Description:       Starts and stops the daemons neeeded for xl/xend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:18:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXdP-0002VC-KP; Thu, 09 Feb 2012 17:18:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvXdN-0002Um-Ou
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:18:14 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328807886!10843550!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDc4MTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24249 invoked from network); 9 Feb 2012 17:18:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 17:18:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328807886; l=1509;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=2WtGdG2fzzArKpGDDONkPR8/gjI=;
	b=wNfKN9hdti+lJ4/MRvm9QyoYdKq+bSsjf9VZdqU96W3F91zbauoysFM4vOfG1ohvcbo
	ngW0pcNPWCAUoTTjlfD2Tav5XMLxgw8dzQ9zzCWjwOkYRM6jkHKKSJlt0fFuU0D7NQwGb
	0RVoax1UzkdgJpDGlpmgzAAhjBiNU4dJGPw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo33) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c00272o19FcF5m
	for <xen-devel@lists.xensource.com>;
	Thu, 9 Feb 2012 18:18:01 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 951CE18634
	for <xen-devel@lists.xensource.com>;
	Thu,  9 Feb 2012 18:18:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 7dadba19566dc9e1dfaf7202ab92b998999a143f
Message-Id: <7dadba19566dc9e1dfaf.1328807886@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 09 Feb 2012 18:18:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel
	in xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1328807859 -3600
# Node ID 7dadba19566dc9e1dfaf7202ab92b998999a143f
# Parent  c42517c528976cc5d6d6ac867f844e855b4abf34
tools/hotplug: remove 4 from default runlevel in xencommons

LSB defines runlevel 4 as "reserved for local use, default is
normal/full multiuser"

The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
Default-Start: line. As a result insserv will print a warning:

insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).

Since the local admin is responsible to create all symlinks manually in
/etc/init.d/rc4.d/ the xencommons script should not automatically enable
itself in runlevel 4.

So, remove the 4 from Default-Start: line.

Note: This change will not automatically remove old/stale xencommon
symlinks in /etc/init.d/rc4.d/ during a package upgrade.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c42517c52897 -r 7dadba19566d tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -12,7 +12,7 @@
 # Should-Start:
 # Required-Stop:     $syslog $remote_fs
 # Should-Stop:
-# Default-Start:     2 3 4 5
+# Default-Start:     2 3 5
 # Default-Stop:      0 1 6
 # Short-Description: Start/stop xenstored and xenconsoled
 # Description:       Starts and stops the daemons neeeded for xl/xend

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:20:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXfp-0002g0-6Z; Thu, 09 Feb 2012 17:20:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvXfn-0002ff-El
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:20:43 +0000
Received: from [85.158.139.83:49578] by server-12.bemta-5.messagelabs.com id
	AF/F2-30830-A60043F4; Thu, 09 Feb 2012 17:20:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328808042!14364275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24098 invoked from network); 9 Feb 2012 17:20:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:20:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:20:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:20:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXfl-0004nK-Qm; Thu, 09 Feb 2012 17:20:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXfl-00037I-Pw;
	Thu, 09 Feb 2012 17:20:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.105.622354.251001@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:20:41 +0000
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> There is also an unused variable warning in xenbus/xenbus.c. I think the compiler should not be warning about this, as the reasonable definition of the local DEBUG macro is the cause? Anyways, here is an ugly fix that shows where the problem is raised. I tried the old trick of defining the variables as volatile, but the new gcc won't let it go by. It won't hurt my feelings if you don't use this patch.

Urgh, that "fix" really is very ugly as you say.  I think I'm sold on
disable the warning.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:20:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXfp-0002g0-6Z; Thu, 09 Feb 2012 17:20:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvXfn-0002ff-El
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:20:43 +0000
Received: from [85.158.139.83:49578] by server-12.bemta-5.messagelabs.com id
	AF/F2-30830-A60043F4; Thu, 09 Feb 2012 17:20:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328808042!14364275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24098 invoked from network); 9 Feb 2012 17:20:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:20:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:20:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:20:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXfl-0004nK-Qm; Thu, 09 Feb 2012 17:20:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXfl-00037I-Pw;
	Thu, 09 Feb 2012 17:20:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.105.622354.251001@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:20:41 +0000
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> There is also an unused variable warning in xenbus/xenbus.c. I think the compiler should not be warning about this, as the reasonable definition of the local DEBUG macro is the cause? Anyways, here is an ugly fix that shows where the problem is raised. I tried the old trick of defining the variables as volatile, but the new gcc won't let it go by. It won't hurt my feelings if you don't use this patch.

Urgh, that "fix" really is very ugly as you say.  I think I'm sold on
disable the warning.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:22:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXh1-0002pI-T5; Thu, 09 Feb 2012 17:21: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 1RvXh0-0002oh-03
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:21:58 +0000
Received: from [85.158.139.83:21273] by server-9.bemta-5.messagelabs.com id
	9D/DF-23757-5B0043F4; Thu, 09 Feb 2012 17:21:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328808116!13788454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2305 invoked from network); 9 Feb 2012 17:21:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:21:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:21:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:21:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXgy-0004nj-Ci; Thu, 09 Feb 2012 17:21:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXgy-000393-Bw;
	Thu, 09 Feb 2012 17:21:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.177.301401.848136@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:21:53 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing, and access, instead of domctls"):
> We retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page
> operations to use the memory_op hypercalls (e.g XENMEM_*).

The tools part of this looks sensible (and pretty formulaic) to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

It'll need a hypervisor maintainer to approve the innards.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:22:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXh1-0002pI-T5; Thu, 09 Feb 2012 17:21: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 1RvXh0-0002oh-03
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:21:58 +0000
Received: from [85.158.139.83:21273] by server-9.bemta-5.messagelabs.com id
	9D/DF-23757-5B0043F4; Thu, 09 Feb 2012 17:21:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328808116!13788454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2305 invoked from network); 9 Feb 2012 17:21:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:21:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:21:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:21:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXgy-0004nj-Ci; Thu, 09 Feb 2012 17:21:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXgy-000393-Bw;
	Thu, 09 Feb 2012 17:21:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.177.301401.848136@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:21:53 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing, and access, instead of domctls"):
> We retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page
> operations to use the memory_op hypercalls (e.g XENMEM_*).

The tools part of this looks sensible (and pretty formulaic) to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

It'll need a hypervisor maintainer to approve the innards.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:25:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXkL-000386-1I; Thu, 09 Feb 2012 17:25:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvXkJ-00037f-Ac
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:25:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328808316!13597859!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25601 invoked from network); 9 Feb 2012 17:25:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:25:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:25:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:25:16 +0000
Date: Thu, 9 Feb 2012 17:28:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328805627.6133.232.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091652240.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
	<1328805627.6133.232.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 16:18 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > > > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > > > > again not a great protocol, but very well known and understood.
> > > > > > > 
> > > > > > > I don't think we have, in general, a good understanding of these
> > > > > > > "state" based protocols ...
> > > > > > 
> > > > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > > > 
> > > > > And no one I know is able to describe, accurately, exactly what the
> > > > > state diagram for even one of those actually looks like or indeed should
> > > > > look like. It became quite evident in these threads about hotplug script
> > > > > handling etc that no one really knows for sure what (is supposed to)
> > > > > happens when.
> > > > 
> > > > I thought that most of the thread was about the interface with the block
> > > > scripts, that is an entirely different matter and completely obscure.
> > > > If I am mistaken, please point me at the right email.
> > > 
> > > We are talking about reusing the existing xenbus state machine schema
> > > for a new purpose. Ian J pointed out that these are not generally well
> > > understood, you replied that it was and cited some examples. I pointed
> > > out why these were not examples of why this stuff was well understood at
> > > all, in fact quite the opposite.
> > 
> > Sorry but I don't understand how these examples are supposed to be
> > "quite the opposite".
> > I quite like the idea of being able to read a single source file of less
> > than 400 LOC to understand how a protocol works
> > (drivers/input/misc/xen-kbdfront.c).
> 
> That is not a protocol specification, merely one implementation of it.
> What does the BSD driver do? Is it exactly the same as Linux? Should BSD
> driver authors be expected to reverse engineer the protocol from the
> Linux code? What/who arbitrates when the two behave differently?

The lack of documentation is an issue.


> > In fact I don't think that understanding the protocol has been an issue
> > for the GSoC student that had to write a new one.
> 
> Being able to reverse engineer something which works is not proof that
> these things are "well understood" in the general case.
> 
> > I think we are under influence of a "reiventing the wheel" virus.
> 
> I think we are in danger of making the same mistakes again as have been
> made with the device protocols and this is what I want to avoid.
> 
> Now, perhaps this style of state machine protocol is a reasonable design
> choice in this case, but since we are starting afresh here this specific
> new instance should be well documented _up_front_ not left in the "oh,
> just read the Linux code" state we have now for many of our devices
> which has lead to multiple slightly divergent implementations of the
> same basic concept.

I agree.


> > > > > Justin just posted a good description for blkif.h which included a state
> > > > > machine description. We need the same for pciif.h, netif.h etc etc.
> > > >  
> > > > The state machine is the same for block and network.
> > > 
> > > No, it's not. This is exactly what IanJ and I are talking about.
> > 
> > Could you please elaborate?
> > 
> > I am sure you know that the xenstore state machine is handled the same
> > way for all the backends in QEMU (see hw/xen_backend.c).
> > And the same thing is true for the frontends and the backends in Linux.
> 
> A substantial proportion of the threads about this hotplug script stuff
> has been about the fact that no one is quite sure what really happens
> when for all implementations nor what the common semantics are.
> 
> e.g. How do you ask a backend to shut down (do you set it to state 5?
> state 6? do you nuke the xenstore dir?). Neither is anyone sure when the
> correct point to call the hotplug scripts actually is, or even what
> actually happens with them right now across the different backend
> drivers or kernel types.

Yeah, this needs to be documented in advance.


> The actual state transitions which netback and blkback go through are
> not the same: The netback protocol uses InitWait, the blkback one does
> not or is it vice-versa? I can't remember and it isn't documented. Some
> Linux frontends handled the kexec reconnect sequencing differently, by
> disconnecting or reconnecting the actual underlying devices at subtly
> different times and/or handling the transition from Closing back to Init
> or InitWait differently.

Interesting... however these changes are just about when netfront or
blkfront decide to bring up the interface/device, they don't affect the
protocol itself, I think. What I mean is that from the toolstack POV we
don't need to worry about this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:25:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXkL-000386-1I; Thu, 09 Feb 2012 17:25:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvXkJ-00037f-Ac
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:25:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328808316!13597859!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25601 invoked from network); 9 Feb 2012 17:25:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:25:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:25:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:25:16 +0000
Date: Thu, 9 Feb 2012 17:28:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328805627.6133.232.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202091652240.22056@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
	<1328805627.6133.232.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"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 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 16:18 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > > > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > > > > > > - we can reuse the "state" based mechanism to establish a connection:
> > > > > > > > again not a great protocol, but very well known and understood.
> > > > > > > 
> > > > > > > I don't think we have, in general, a good understanding of these
> > > > > > > "state" based protocols ...
> > > > > > 
> > > > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > > > 
> > > > > And no one I know is able to describe, accurately, exactly what the
> > > > > state diagram for even one of those actually looks like or indeed should
> > > > > look like. It became quite evident in these threads about hotplug script
> > > > > handling etc that no one really knows for sure what (is supposed to)
> > > > > happens when.
> > > > 
> > > > I thought that most of the thread was about the interface with the block
> > > > scripts, that is an entirely different matter and completely obscure.
> > > > If I am mistaken, please point me at the right email.
> > > 
> > > We are talking about reusing the existing xenbus state machine schema
> > > for a new purpose. Ian J pointed out that these are not generally well
> > > understood, you replied that it was and cited some examples. I pointed
> > > out why these were not examples of why this stuff was well understood at
> > > all, in fact quite the opposite.
> > 
> > Sorry but I don't understand how these examples are supposed to be
> > "quite the opposite".
> > I quite like the idea of being able to read a single source file of less
> > than 400 LOC to understand how a protocol works
> > (drivers/input/misc/xen-kbdfront.c).
> 
> That is not a protocol specification, merely one implementation of it.
> What does the BSD driver do? Is it exactly the same as Linux? Should BSD
> driver authors be expected to reverse engineer the protocol from the
> Linux code? What/who arbitrates when the two behave differently?

The lack of documentation is an issue.


> > In fact I don't think that understanding the protocol has been an issue
> > for the GSoC student that had to write a new one.
> 
> Being able to reverse engineer something which works is not proof that
> these things are "well understood" in the general case.
> 
> > I think we are under influence of a "reiventing the wheel" virus.
> 
> I think we are in danger of making the same mistakes again as have been
> made with the device protocols and this is what I want to avoid.
> 
> Now, perhaps this style of state machine protocol is a reasonable design
> choice in this case, but since we are starting afresh here this specific
> new instance should be well documented _up_front_ not left in the "oh,
> just read the Linux code" state we have now for many of our devices
> which has lead to multiple slightly divergent implementations of the
> same basic concept.

I agree.


> > > > > Justin just posted a good description for blkif.h which included a state
> > > > > machine description. We need the same for pciif.h, netif.h etc etc.
> > > >  
> > > > The state machine is the same for block and network.
> > > 
> > > No, it's not. This is exactly what IanJ and I are talking about.
> > 
> > Could you please elaborate?
> > 
> > I am sure you know that the xenstore state machine is handled the same
> > way for all the backends in QEMU (see hw/xen_backend.c).
> > And the same thing is true for the frontends and the backends in Linux.
> 
> A substantial proportion of the threads about this hotplug script stuff
> has been about the fact that no one is quite sure what really happens
> when for all implementations nor what the common semantics are.
> 
> e.g. How do you ask a backend to shut down (do you set it to state 5?
> state 6? do you nuke the xenstore dir?). Neither is anyone sure when the
> correct point to call the hotplug scripts actually is, or even what
> actually happens with them right now across the different backend
> drivers or kernel types.

Yeah, this needs to be documented in advance.


> The actual state transitions which netback and blkback go through are
> not the same: The netback protocol uses InitWait, the blkback one does
> not or is it vice-versa? I can't remember and it isn't documented. Some
> Linux frontends handled the kexec reconnect sequencing differently, by
> disconnecting or reconnecting the actual underlying devices at subtly
> different times and/or handling the transition from Closing back to Init
> or InitWait differently.

Interesting... however these changes are just about when netfront or
blkfront decide to bring up the interface/device, they don't affect the
protocol itself, I think. What I mean is that from the toolstack POV we
don't need to worry about this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:29:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXo2-0003Jz-Vk; Thu, 09 Feb 2012 17:29:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RvXo1-0003Jj-6a
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:29:13 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328808546!5285475!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11632 invoked from network); 9 Feb 2012 17:29:07 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-4.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 17:29:07 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q19HT3hf002160;
	Thu, 9 Feb 2012 12:29:03 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q19HSxxs008741;
	Thu, 9 Feb 2012 12:29:03 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020912290301516 ; Thu, 09 Feb 2012 12:29:03 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <20276.105.622354.251001@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 12:29:03 -0500
Message-Id: <FEED144D-2577-4F42-9127-30EEE1E8511B@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

I would expect most use of mini-os would involve lots of locally hacking the source anyways (we do) and likely to raise this warning again. So it is probably the best choice to disable?

Sincerely,

John
----
On Feb 9, 2012, at 12:20 PM, Ian Jackson wrote:

> John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
>> There is also an unused variable warning in xenbus/xenbus.c. I think the compiler should not be warning about this, as the reasonable definition of the local DEBUG macro is the cause? Anyways, here is an ugly fix that shows where the problem is raised. I tried the old trick of defining the variables as volatile, but the new gcc won't let it go by. It won't hurt my feelings if you don't use this patch.
> 
> Urgh, that "fix" really is very ugly as you say.  I think I'm sold on
> disable the warning.
> 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:29:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvXo2-0003Jz-Vk; Thu, 09 Feb 2012 17:29:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RvXo1-0003Jj-6a
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:29:13 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328808546!5285475!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11632 invoked from network); 9 Feb 2012 17:29:07 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-4.tower-21.messagelabs.com with SMTP;
	9 Feb 2012 17:29:07 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q19HT3hf002160;
	Thu, 9 Feb 2012 12:29:03 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q19HSxxs008741;
	Thu, 9 Feb 2012 12:29:03 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012020912290301516 ; Thu, 09 Feb 2012 12:29:03 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <20276.105.622354.251001@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 12:29:03 -0500
Message-Id: <FEED144D-2577-4F42-9127-30EEE1E8511B@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

I would expect most use of mini-os would involve lots of locally hacking the source anyways (we do) and likely to raise this warning again. So it is probably the best choice to disable?

Sincerely,

John
----
On Feb 9, 2012, at 12:20 PM, Ian Jackson wrote:

> John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
>> There is also an unused variable warning in xenbus/xenbus.c. I think the compiler should not be warning about this, as the reasonable definition of the local DEBUG macro is the cause? Anyways, here is an ugly fix that shows where the problem is raised. I tried the old trick of defining the variables as volatile, but the new gcc won't let it go by. It won't hurt my feelings if you don't use this patch.
> 
> Urgh, that "fix" really is very ugly as you say.  I think I'm sold on
> disable the warning.
> 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:41:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:41:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXzI-0003Vv-AT; Thu, 09 Feb 2012 17:40:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvXzF-0003Vn-Pl
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:40:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328809242!2447841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11837 invoked from network); 9 Feb 2012 17:40:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:40:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:40:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:40:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXz8-0004uR-50; Thu, 09 Feb 2012 17:40:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXz8-0003Ta-2d;
	Thu, 09 Feb 2012 17:40:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.1306.70587.543367@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:40:42 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <4F33F414.5050803@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F33F414.5050803@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain"):
> Are these tools and mini-os changes going to be committed, or do you
> have further comments to address? The hypervisor changes went in on
> 1/28, and Ian's (#8) went in on 1/31; I haven't seen any comments
> since 1/30.

Thanks for the ping.  Yes, I should apply the rest of these now.

I see you have been using git.  Would you care to prepare a public git
branch I can pull, with the already-applied patches removed ?  If so
then that would be most convenient for me.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:41:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:41:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvXzI-0003Vv-AT; Thu, 09 Feb 2012 17:40:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvXzF-0003Vn-Pl
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:40:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328809242!2447841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11837 invoked from network); 9 Feb 2012 17:40:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:40:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10606755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:40:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:40:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvXz8-0004uR-50; Thu, 09 Feb 2012 17:40:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvXz8-0003Ta-2d;
	Thu, 09 Feb 2012 17:40:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.1306.70587.543367@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:40:42 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <4F33F414.5050803@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F33F414.5050803@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain"):
> Are these tools and mini-os changes going to be committed, or do you
> have further comments to address? The hypervisor changes went in on
> 1/28, and Ian's (#8) went in on 1/31; I haven't seen any comments
> since 1/30.

Thanks for the ping.  Yes, I should apply the rest of these now.

I see you have been using git.  Would you care to prepare a public git
branch I can pull, with the already-applied patches removed ?  If so
then that would be most convenient for me.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:42:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvY0k-0003c7-Qw; Thu, 09 Feb 2012 17:42:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvY0i-0003bg-Kz
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:42:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328809331!13652947!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32100 invoked from network); 9 Feb 2012 17:42:13 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 17:42:13 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19HgB5J014059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 12:42:11 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19HgAM0014057;
	Thu, 9 Feb 2012 12:42:10 -0500
Date: Thu, 9 Feb 2012 13:42:10 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Todd Deshane <todd.deshane@xen.org>
Message-ID: <20120209174210.GA14007@andromeda.dapyr.net>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
	<20120117161208.GA21545@phenom.dumpdata.com>
	<CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 28, 2012 at 01:19:23PM -0500, Todd Deshane wrote:
> On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
> >> Hi,
> >>
> >> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
> >> static on the Dom0 system. (I can PCI passthrough the audio card to a
> >> DomU and that works). Native sound works fine.
> >>
> >> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
> >> UTC 2012 i686 i686 i386 GNU/Linux
> >
> > Did you try 64-bit dom0?
> 
> 64bit Dom0 works perfectly.

Aha! I have an inkling this is the
7a7546b377bdaa25ac77f33d9433c59f259b9688

Could you be so kind and try the 32-bit build with that?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:42:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17: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.xensource.com>)
	id 1RvY0k-0003c7-Qw; Thu, 09 Feb 2012 17:42:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvY0i-0003bg-Kz
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:42:21 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328809331!13652947!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32100 invoked from network); 9 Feb 2012 17:42:13 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 17:42:13 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19HgB5J014059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 12:42:11 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19HgAM0014057;
	Thu, 9 Feb 2012 12:42:10 -0500
Date: Thu, 9 Feb 2012 13:42:10 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Todd Deshane <todd.deshane@xen.org>
Message-ID: <20120209174210.GA14007@andromeda.dapyr.net>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
	<20120117161208.GA21545@phenom.dumpdata.com>
	<CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 28, 2012 at 01:19:23PM -0500, Todd Deshane wrote:
> On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
> >> Hi,
> >>
> >> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
> >> static on the Dom0 system. (I can PCI passthrough the audio card to a
> >> DomU and that works). Native sound works fine.
> >>
> >> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
> >> UTC 2012 i686 i686 i386 GNU/Linux
> >
> > Did you try 64-bit dom0?
> 
> 64bit Dom0 works perfectly.

Aha! I have an inkling this is the
7a7546b377bdaa25ac77f33d9433c59f259b9688

Could you be so kind and try the 32-bit build with that?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:58:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYFm-0003z2-BR; Thu, 09 Feb 2012 17:57:54 +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 1RvYFl-0003yx-AQ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:57:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328810249!52278665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32023 invoked from network); 9 Feb 2012 17:57:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:57:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:57:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:57:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYFj-00050L-MX; Thu, 09 Feb 2012 17:57:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYFj-0000Gv-Gz;
	Thu, 09 Feb 2012 17:57:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2335.273506.959266@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:57:51 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and
 performance improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> This series adjusts the error reporting in the various code paths, with
> the intention that fatal errors can be detected by callers and handled
> properly. During my performance analysis with callgrind I found and
> fixed a few bottlenecks in the page-in code paths.

Since these are all xenpaging changes, I'm inclined to follow your
lead and commit them soon.  If anyone has any comments, please shout!

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 17:58:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 17:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYFm-0003z2-BR; Thu, 09 Feb 2012 17:57:54 +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 1RvYFl-0003yx-AQ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 17:57:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328810249!52278665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32023 invoked from network); 9 Feb 2012 17:57:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 17:57:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 17:57:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 17:57:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYFj-00050L-MX; Thu, 09 Feb 2012 17:57:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYFj-0000Gv-Gz;
	Thu, 09 Feb 2012 17:57:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2335.273506.959266@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 17:57:51 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and
 performance improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> This series adjusts the error reporting in the various code paths, with
> the intention that fatal errors can be detected by callers and handled
> properly. During my performance analysis with callgrind I found and
> fixed a few bottlenecks in the page-in code paths.

Since these are all xenpaging changes, I'm inclined to follow your
lead and commit them soon.  If anyone has any comments, please shout!

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:03:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18: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.xensource.com>)
	id 1RvYL8-0004GI-Gk; Thu, 09 Feb 2012 18:03:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYL6-0004Fu-SI
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:03:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328810598!8563319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23586 invoked from network); 9 Feb 2012 18: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;
	9 Feb 2012 18:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:03:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:03:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYL0-00052I-Ix; Thu, 09 Feb 2012 18:03:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYL0-0000os-He;
	Thu, 09 Feb 2012 18:03:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2662.347046.572394@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:03:18 +0000
To: Wei Liu <wei.liu2@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327941744.5553.29.camel@leeds.uk.xensource.com>
References: <1327941744.5553.29.camel@leeds.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xl: add reference for vcpu-set command.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Liu writes ("[Xen-devel] xl: add reference for vcpu-set command."):
> xl: add reference for vcpu-set command.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:03:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18: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.xensource.com>)
	id 1RvYL8-0004GI-Gk; Thu, 09 Feb 2012 18:03:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYL6-0004Fu-SI
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:03:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328810598!8563319!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23586 invoked from network); 9 Feb 2012 18: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;
	9 Feb 2012 18:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:03:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:03:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYL0-00052I-Ix; Thu, 09 Feb 2012 18:03:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYL0-0000os-He;
	Thu, 09 Feb 2012 18:03:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2662.347046.572394@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:03:18 +0000
To: Wei Liu <wei.liu2@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327941744.5553.29.camel@leeds.uk.xensource.com>
References: <1327941744.5553.29.camel@leeds.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xl: add reference for vcpu-set command.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Liu writes ("[Xen-devel] xl: add reference for vcpu-set command."):
> xl: add reference for vcpu-set command.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:03:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYL8-0004GB-49; Thu, 09 Feb 2012 18:03:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvYL6-0004Fs-Af
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:03:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328810596!13663164!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2982 invoked from network); 9 Feb 2012 18:03:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 18:03:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328810596; l=371;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=eKHG7D+zd4DjDVG1LDYXylKksoI=;
	b=ym+BV8ACEj7UOWqZe2K2eLMHJNXKrMGpw5mE1qTId20SEqBa+t6aneLmV/X3eJ2JbFL
	cEguAV0sNAaRaG1psmrVBMDQ9+PcjQk9SlL70NGjN2kghj4rXCWsnxvHqC45MP5G09n+d
	e0367pDug89cTDtyj7L3vaMILeU1vE+6EAU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo4) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h00290o19Hhc4a ;
	Thu, 9 Feb 2012 19:02:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1C6FF18637; Thu,  9 Feb 2012 19:02:58 +0100 (CET)
Date: Thu, 9 Feb 2012 19:02:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120209180257.GA13025@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Jan Beulich wrote:

> Below/attached a draft patch (compile tested only), handling save/
> restore of the bank count, but not allowing for a config setting to
> specify its initial value (yet).

Does it take more than just applying this patch for src+dst host and
migrate a hvm guest? I see no difference, the mce warning is still
there.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:03:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYL8-0004GB-49; Thu, 09 Feb 2012 18:03:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvYL6-0004Fs-Af
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:03:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328810596!13663164!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjU2NDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2982 invoked from network); 9 Feb 2012 18:03:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 18:03:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328810596; l=371;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=eKHG7D+zd4DjDVG1LDYXylKksoI=;
	b=ym+BV8ACEj7UOWqZe2K2eLMHJNXKrMGpw5mE1qTId20SEqBa+t6aneLmV/X3eJ2JbFL
	cEguAV0sNAaRaG1psmrVBMDQ9+PcjQk9SlL70NGjN2kghj4rXCWsnxvHqC45MP5G09n+d
	e0367pDug89cTDtyj7L3vaMILeU1vE+6EAU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJii0PEilS
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-074-117.pools.arcor-ip.net [88.65.74.117])
	by smtp.strato.de (cohen mo4) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h00290o19Hhc4a ;
	Thu, 9 Feb 2012 19:02:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1C6FF18637; Thu,  9 Feb 2012 19:02:58 +0100 (CET)
Date: Thu, 9 Feb 2012 19:02:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120209180257.GA13025@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Jan Beulich wrote:

> Below/attached a draft patch (compile tested only), handling save/
> restore of the bank count, but not allowing for a config setting to
> specify its initial value (yet).

Does it take more than just applying this patch for src+dst host and
migrate a hvm guest? I see no difference, the mce warning is still
there.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:04:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:04:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYMJ-0004Rs-5E; Thu, 09 Feb 2012 18:04:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RvYMH-0004QP-C1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:04:37 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328810669!8563490!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26911 invoked from network); 9 Feb 2012 18:04:30 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 18:04:30 -0000
Received: by damc16 with SMTP id c16so12862628dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 10:04:28 -0800 (PST)
Received: by 10.68.189.65 with SMTP id gg1mr8037503pbc.66.1328810668772;
	Thu, 09 Feb 2012 10:04:28 -0800 (PST)
Received: from [25.70.199.107] ([74.198.150.235])
	by mx.google.com with ESMTPS id p9sm7734390pbb.9.2012.02.09.10.04.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 10:04:26 -0800 (PST)
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
	<90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
	<1328791125.6133.155.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328791125.6133.155.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <8EBF3110-FA51-49CC-8F20-7EBC0E9C1916@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 10:04:20 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2 V3] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-09, at 4:38 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-02-03 at 07:00 +0000, rshriram@cs.ubc.ca wrote:
>> # 
>> 
>> +/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
>> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
>> +                             uint32_t domid, int send_fd, int recv_fd)
>> +{
>> +    GC_INIT(ctx);
>> +    libxl_domain_type type = libxl__domain_type(gc, domid);
>> +    int rc = 0;
>> +
>> +    if (info == NULL) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>> +                   "No remus_info structure supplied for domain %d", domid);
>> +        rc = ERROR_INVAL;
>> +        goto remus_fail;
>> +    }
>> +
>> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> 
> Is it worth checking that the domain has no disks or network (IOW is
> this dangerous if they do?)
> 

A domain with no disks or network wouldnt be of much use though.
 Is it dangerous if they do but are not checkpointed ? Yes.
 Dangerous to what extent depends on how critical the application is.
 But then, this patch intends to put the framework in place so that people can at least play around with memory check pointing.

> [...]
>> @@ -791,7 +837,27 @@ int libxl__domain_suspend_common(libxl__
>>     }
>> 
>>     memset(&callbacks, 0, sizeof(callbacks));
>> -    callbacks.suspend = libxl__domain_suspend_common_callback;
>> +    if (r_info != NULL) {
>> +        /* save_callbacks:
>> +         * suspend - called after expiration of checkpoint interval,
>> +         *           to *suspend* the domain.
>> +         *
>> +         * postcopy - called after the domain's dirty pages have been
>> +         *            copied into an output buffer. We *resume* the domain
>> +         *            & the device model, return to the caller. Caller then
>> +         *            flushes the output buffer, while the domain continues to run.
>> +         *
>> +         * checkpoint - called after the memory checkpoint has been flushed out
>> +         *              into the network. Send the saved device state, *wait*
>> +         *              for checkpoint ack and *release* the network buffer (TBD).
>> +         *              Then *sleep* for the checkpoint interval.
>> +         */
> 
> I think this comment would be more useful in xenguest.h next to the
> callback struct.
> 
> Otherwise the patch looks good.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:04:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:04:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYMJ-0004Rs-5E; Thu, 09 Feb 2012 18:04:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RvYMH-0004QP-C1
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:04:37 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328810669!8563490!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26911 invoked from network); 9 Feb 2012 18:04:30 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 18:04:30 -0000
Received: by damc16 with SMTP id c16so12862628dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 10:04:28 -0800 (PST)
Received: by 10.68.189.65 with SMTP id gg1mr8037503pbc.66.1328810668772;
	Thu, 09 Feb 2012 10:04:28 -0800 (PST)
Received: from [25.70.199.107] ([74.198.150.235])
	by mx.google.com with ESMTPS id p9sm7734390pbb.9.2012.02.09.10.04.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 10:04:26 -0800 (PST)
References: <patchbomb.1328252413@athos.nss.cs.ubc.ca>
	<90e59c643c00c079996e.1328252414@athos.nss.cs.ubc.ca>
	<1328791125.6133.155.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328791125.6133.155.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <8EBF3110-FA51-49CC-8F20-7EBC0E9C1916@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 10:04:20 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2 V3] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-09, at 4:38 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-02-03 at 07:00 +0000, rshriram@cs.ubc.ca wrote:
>> # 
>> 
>> +/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
>> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
>> +                             uint32_t domid, int send_fd, int recv_fd)
>> +{
>> +    GC_INIT(ctx);
>> +    libxl_domain_type type = libxl__domain_type(gc, domid);
>> +    int rc = 0;
>> +
>> +    if (info == NULL) {
>> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>> +                   "No remus_info structure supplied for domain %d", domid);
>> +        rc = ERROR_INVAL;
>> +        goto remus_fail;
>> +    }
>> +
>> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> 
> Is it worth checking that the domain has no disks or network (IOW is
> this dangerous if they do?)
> 

A domain with no disks or network wouldnt be of much use though.
 Is it dangerous if they do but are not checkpointed ? Yes.
 Dangerous to what extent depends on how critical the application is.
 But then, this patch intends to put the framework in place so that people can at least play around with memory check pointing.

> [...]
>> @@ -791,7 +837,27 @@ int libxl__domain_suspend_common(libxl__
>>     }
>> 
>>     memset(&callbacks, 0, sizeof(callbacks));
>> -    callbacks.suspend = libxl__domain_suspend_common_callback;
>> +    if (r_info != NULL) {
>> +        /* save_callbacks:
>> +         * suspend - called after expiration of checkpoint interval,
>> +         *           to *suspend* the domain.
>> +         *
>> +         * postcopy - called after the domain's dirty pages have been
>> +         *            copied into an output buffer. We *resume* the domain
>> +         *            & the device model, return to the caller. Caller then
>> +         *            flushes the output buffer, while the domain continues to run.
>> +         *
>> +         * checkpoint - called after the memory checkpoint has been flushed out
>> +         *              into the network. Send the saved device state, *wait*
>> +         *              for checkpoint ack and *release* the network buffer (TBD).
>> +         *              Then *sleep* for the checkpoint interval.
>> +         */
> 
> I think this comment would be more useful in xenguest.h next to the
> callback struct.
> 
> Otherwise the patch looks good.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:06:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYOE-0004gH-NY; Thu, 09 Feb 2012 18:06: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 1RvYOC-0004g7-KR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:06:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328810773!65209109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27653 invoked from network); 9 Feb 2012 18:06:13 -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;
	9 Feb 2012 18:06:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:06:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:06:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYOA-00053G-SI; Thu, 09 Feb 2012 18:06:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYOA-0000sw-RU;
	Thu, 09 Feb 2012 18:06:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2858.839161.799240@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:06:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328003228.26983.312.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
	<1328003228.26983.312.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain()
 return to caller if !daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain() return to caller if !daemonize"):
> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > libxl: bugfix: create_domain() return to caller if !daemonize

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:06:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYOE-0004gH-NY; Thu, 09 Feb 2012 18:06: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 1RvYOC-0004g7-KR
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:06:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328810773!65209109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27653 invoked from network); 9 Feb 2012 18:06:13 -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;
	9 Feb 2012 18:06:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:06:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:06:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYOA-00053G-SI; Thu, 09 Feb 2012 18:06:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYOA-0000sw-RU;
	Thu, 09 Feb 2012 18:06:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2858.839161.799240@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:06:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328003228.26983.312.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
	<1328003228.26983.312.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>
Subject: Re: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain()
 return to caller if !daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain() return to caller if !daemonize"):
> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > libxl: bugfix: create_domain() return to caller if !daemonize

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYRH-0004wZ-B2; Thu, 09 Feb 2012 18:09:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYRG-0004wI-9Q
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:09:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328810980!16039398!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 9 Feb 2012 18:09:40 -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;
	9 Feb 2012 18:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18: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.213.0; Thu, 9 Feb 2012 18:08:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYQ9-00053t-PX; Thu, 09 Feb 2012 18:08:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYQ9-00011v-Oe;
	Thu, 09 Feb 2012 18:08:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2978.188606.796407@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:08:34 +0000
To: <rshriram@cs.ubc.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAP8mzPOo+muJTB8FLYOetsNm_6EfYia3gnNKFQ-pO0YCcQfqYg@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
	<1328003207.26983.311.camel@zakaz.uk.xensource.com>
	<CAP8mzPOo+muJTB8FLYOetsNm_6EfYia3gnNKFQ-pO0YCcQfqYg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send
 commands to traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Shriram Rajagopalan writes ("Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send commands to traditional qemu"):
> On Tue, Jan 31, 2012 at 1:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     Every caller to libxl__qemu_traditional_cmd seems to be followed with a
>     call to libxl__wait_for_device_model -- might be worth pushing that down
>     into the function?
...
> Yes I noticed that. Though some seem to be using the callback while
> others dont.  This would necessitate another helper function, like
> libxl_qemu_traditional_change_state that does both the command and
> the state check (if callback supplied). This way people could still
> use the libxl_qemu_traditional_cmd for use-cases that dont require a
> special state check. But all this is for another , later patch
> :P. At the moment, I just want to get the remus framework in :D.

Right.

Well, your patch was a good cleanup in itself so I have applied it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYRH-0004wZ-B2; Thu, 09 Feb 2012 18:09:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYRG-0004wI-9Q
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:09:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328810980!16039398!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 9 Feb 2012 18:09:40 -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;
	9 Feb 2012 18:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18: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.213.0; Thu, 9 Feb 2012 18:08:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYQ9-00053t-PX; Thu, 09 Feb 2012 18:08:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYQ9-00011v-Oe;
	Thu, 09 Feb 2012 18:08:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.2978.188606.796407@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:08:34 +0000
To: <rshriram@cs.ubc.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAP8mzPOo+muJTB8FLYOetsNm_6EfYia3gnNKFQ-pO0YCcQfqYg@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
	<1328003207.26983.311.camel@zakaz.uk.xensource.com>
	<CAP8mzPOo+muJTB8FLYOetsNm_6EfYia3gnNKFQ-pO0YCcQfqYg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send
 commands to traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Shriram Rajagopalan writes ("Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send commands to traditional qemu"):
> On Tue, Jan 31, 2012 at 1:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     Every caller to libxl__qemu_traditional_cmd seems to be followed with a
>     call to libxl__wait_for_device_model -- might be worth pushing that down
>     into the function?
...
> Yes I noticed that. Though some seem to be using the callback while
> others dont.  This would necessitate another helper function, like
> libxl_qemu_traditional_change_state that does both the command and
> the state check (if callback supplied). This way people could still
> use the libxl_qemu_traditional_cmd for use-cases that dont require a
> special state check. But all this is for another , later patch
> :P. At the moment, I just want to get the remus framework in :D.

Right.

Well, your patch was a good cleanup in itself so I have applied it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:20:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYbg-0005Jx-PG; Thu, 09 Feb 2012 18:20:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RvYbf-0005Ja-PQ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:20:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328811624!12741696!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4139 invoked from network); 9 Feb 2012 18:20:25 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 18:20:25 -0000
X-TM-IMSS-Message-ID: <effc8bbb0000e7e2@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id effc8bbb0000e7e2 ;
	Thu, 9 Feb 2012 13:32:02 -0500
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 q19IKLG4004863; 
	Thu, 9 Feb 2012 13:20:21 -0500
Message-ID: <4F340E68.3090808@tycho.nsa.gov>
Date: Thu, 09 Feb 2012 13:20:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F33F414.5050803@tycho.nsa.gov>
	<20276.1306.70587.543367@mariner.uk.xensource.com>
In-Reply-To: <20276.1306.70587.543367@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/2012 12:40 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain"):
>> Are these tools and mini-os changes going to be committed, or do you
>> have further comments to address? The hypervisor changes went in on
>> 1/28, and Ian's (#8) went in on 1/31; I haven't seen any comments
>> since 1/30.
> 
> Thanks for the ping.  Yes, I should apply the rest of these now.
> 
> I see you have been using git.  Would you care to prepare a public git
> branch I can pull, with the already-applied patches removed ?  If so
> then that would be most convenient for me.
> 
> Thanks,
> Ian.
> 

Uploaded to git://github.com/danieldg/xen-unstable.git #pending-xs

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:20:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:20:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYbg-0005Jx-PG; Thu, 09 Feb 2012 18:20:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RvYbf-0005Ja-PQ
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:20:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328811624!12741696!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4139 invoked from network); 9 Feb 2012 18:20:25 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-174.messagelabs.com with SMTP;
	9 Feb 2012 18:20:25 -0000
X-TM-IMSS-Message-ID: <effc8bbb0000e7e2@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id effc8bbb0000e7e2 ;
	Thu, 9 Feb 2012 13:32:02 -0500
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 q19IKLG4004863; 
	Thu, 9 Feb 2012 13:20:21 -0500
Message-ID: <4F340E68.3090808@tycho.nsa.gov>
Date: Thu, 09 Feb 2012 13:20:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F33F414.5050803@tycho.nsa.gov>
	<20276.1306.70587.543367@mariner.uk.xensource.com>
In-Reply-To: <20276.1306.70587.543367@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/2012 12:40 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain"):
>> Are these tools and mini-os changes going to be committed, or do you
>> have further comments to address? The hypervisor changes went in on
>> 1/28, and Ian's (#8) went in on 1/31; I haven't seen any comments
>> since 1/30.
> 
> Thanks for the ping.  Yes, I should apply the rest of these now.
> 
> I see you have been using git.  Would you care to prepare a public git
> branch I can pull, with the already-applied patches removed ?  If so
> then that would be most convenient for me.
> 
> Thanks,
> Ian.
> 

Uploaded to git://github.com/danieldg/xen-unstable.git #pending-xs

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:21:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYcV-0005On-7V; Thu, 09 Feb 2012 18:21:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RvYcT-0005Of-Th
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:21:22 +0000
Received: from [85.158.139.83:23456] by server-9.bemta-5.messagelabs.com id
	1E/AC-23757-1AE043F4; Thu, 09 Feb 2012 18:21:21 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328811678!14428195!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1135 invoked from network); 9 Feb 2012 18:21:20 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 18:21:20 -0000
Received: by damc16 with SMTP id c16so12951937dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 10:21:18 -0800 (PST)
Received: by 10.68.218.5 with SMTP id pc5mr8060646pbc.101.1328811678270;
	Thu, 09 Feb 2012 10:21:18 -0800 (PST)
Received: from [25.70.199.107] ([74.198.150.235])
	by mx.google.com with ESMTPS id a5sm7811110pbh.15.2012.02.09.10.21.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 10:21:16 -0800 (PST)
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
	<1328778962.6133.111.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328778962.6133.111.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 10:21:08 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-09, at 1:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
>> # 
> 
> Previously this code would have been equivalent to passing 0 not 1. It
> may be ok to change this but it should be separate.

> However I'm a bit
> dubious about changing it without adding some code to detect if the
> guest supports it.

It requires writing the suspend-cancel entry to xenstore on domain creation (if xen says that the guest supports it)

 And then read this field once during initialization in checkpoint/Remus code.

I haven't properly investigated the domain create code path. Any pointers on where I should start ?

> (I know libxl_domain_resume is currently broken for
> the non-cooperative suspend

It's broken in such a way that neither domain checkpoint or Remus work.
I ll take up your comment on the previous version of the patch:
 Add a new public (or internal) API 
 libxl_domain_suspend_cancel

and make the checkpoint and Remus related code call this instead of the domain_resume. 

Later, after adding the suspend-cancel xenstore entry creation patch, I can switch the code to using the above function with the cooperative flag.

> case but we shouldn't paper over that)
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:21:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:21:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYcV-0005On-7V; Thu, 09 Feb 2012 18:21:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RvYcT-0005Of-Th
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:21:22 +0000
Received: from [85.158.139.83:23456] by server-9.bemta-5.messagelabs.com id
	1E/AC-23757-1AE043F4; Thu, 09 Feb 2012 18:21:21 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328811678!14428195!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1135 invoked from network); 9 Feb 2012 18:21:20 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 18:21:20 -0000
Received: by damc16 with SMTP id c16so12951937dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 10:21:18 -0800 (PST)
Received: by 10.68.218.5 with SMTP id pc5mr8060646pbc.101.1328811678270;
	Thu, 09 Feb 2012 10:21:18 -0800 (PST)
Received: from [25.70.199.107] ([74.198.150.235])
	by mx.google.com with ESMTPS id a5sm7811110pbh.15.2012.02.09.10.21.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 10:21:16 -0800 (PST)
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
	<1328778962.6133.111.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328778962.6133.111.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 10:21:08 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-09, at 1:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
>> # 
> 
> Previously this code would have been equivalent to passing 0 not 1. It
> may be ok to change this but it should be separate.

> However I'm a bit
> dubious about changing it without adding some code to detect if the
> guest supports it.

It requires writing the suspend-cancel entry to xenstore on domain creation (if xen says that the guest supports it)

 And then read this field once during initialization in checkpoint/Remus code.

I haven't properly investigated the domain create code path. Any pointers on where I should start ?

> (I know libxl_domain_resume is currently broken for
> the non-cooperative suspend

It's broken in such a way that neither domain checkpoint or Remus work.
I ll take up your comment on the previous version of the patch:
 Add a new public (or internal) API 
 libxl_domain_suspend_cancel

and make the checkpoint and Remus related code call this instead of the domain_resume. 

Later, after adding the suspend-cancel xenstore entry creation patch, I can switch the code to using the above function with the cooperative flag.

> case but we shouldn't paper over that)
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYgT-0005ft-Up; Thu, 09 Feb 2012 18:25:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYgT-0005fT-1C
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:25:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328811922!12735665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21297 invoked from network); 9 Feb 2012 18:25:23 -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;
	9 Feb 2012 18:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:25:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:25:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYgM-00059h-3I; Thu, 09 Feb 2012 18:25:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYgM-0001VM-2X;
	Thu, 09 Feb 2012 18:25:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.3986.64064.194525@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:25:22 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328123365-12490-7-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-7-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.xensource.com
Subject: Re: [Xen-devel] [PATCH 6/8] libxl: Add
	device_model_stubdomain_seclabel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH 6/8] libxl: Add device_model_stubdomain_seclabel"):
> This allows the security label of stub domains to be specified.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYgT-0005ft-Up; Thu, 09 Feb 2012 18:25:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYgT-0005fT-1C
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:25:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328811922!12735665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21297 invoked from network); 9 Feb 2012 18:25:23 -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;
	9 Feb 2012 18:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:25:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:25:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYgM-00059h-3I; Thu, 09 Feb 2012 18:25:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYgM-0001VM-2X;
	Thu, 09 Feb 2012 18:25:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.3986.64064.194525@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:25:22 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328123365-12490-7-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-7-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.xensource.com
Subject: Re: [Xen-devel] [PATCH 6/8] libxl: Add
	device_model_stubdomain_seclabel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH 6/8] libxl: Add device_model_stubdomain_seclabel"):
> This allows the security label of stub domains to be specified.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:27:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYhu-0005n0-GG; Thu, 09 Feb 2012 18:26: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 1RvYht-0005mp-35
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:26:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328811883!52100184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2700 invoked from network); 9 Feb 2012 18:24:43 -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;
	9 Feb 2012 18:24:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:25:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:25:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYgr-00059s-Qn; Thu, 09 Feb 2012 18:25:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYgr-0001W8-QC;
	Thu, 09 Feb 2012 18:25:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.4017.799390.930938@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:25:53 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328123365-12490-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-8-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.xensource.com
Subject: Re: [Xen-devel] [PATCH 7/8] flask/policy: add device model types
	to	example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH 7/8] flask/policy: add device model types to example policy"):
> This adds an example user for device_model_stubdomain_seclabel.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:27:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:27:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYhu-0005n0-GG; Thu, 09 Feb 2012 18:26: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 1RvYht-0005mp-35
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:26:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328811883!52100184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2700 invoked from network); 9 Feb 2012 18:24:43 -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;
	9 Feb 2012 18:24:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:25:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:25:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYgr-00059s-Qn; Thu, 09 Feb 2012 18:25:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYgr-0001W8-QC;
	Thu, 09 Feb 2012 18:25:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.4017.799390.930938@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:25:53 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328123365-12490-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1328123365-12490-8-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.xensource.com
Subject: Re: [Xen-devel] [PATCH 7/8] flask/policy: add device model types
	to	example policy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("[Xen-devel] [PATCH 7/8] flask/policy: add device model types to example policy"):
> This adds an example user for device_model_stubdomain_seclabel.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18: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.xensource.com>)
	id 1RvYul-0006JK-M1; Thu, 09 Feb 2012 18:40:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYuk-0006J8-Ju
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:40:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328812808!13905400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9526 invoked from network); 9 Feb 2012 18:40:08 -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;
	9 Feb 2012 18:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:40:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:40:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYue-0005Ge-9J; Thu, 09 Feb 2012 18:40:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYue-0004Um-4k;
	Thu, 09 Feb 2012 18:40:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.4872.93209.351529@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:40:08 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <4F340E68.3090808@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F33F414.5050803@tycho.nsa.gov>
	<20276.1306.70587.543367@mariner.uk.xensource.com>
	<4F340E68.3090808@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain"):
> Uploaded to git://github.com/danieldg/xen-unstable.git #pending-xs

Marvellous, pushed, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18: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.xensource.com>)
	id 1RvYul-0006JK-M1; Thu, 09 Feb 2012 18:40:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvYuk-0006J8-Ju
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:40:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328812808!13905400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9526 invoked from network); 9 Feb 2012 18:40:08 -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;
	9 Feb 2012 18:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:40:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:40:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYue-0005Ge-9J; Thu, 09 Feb 2012 18:40:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYue-0004Um-4k;
	Thu, 09 Feb 2012 18:40:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.4872.93209.351529@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:40:08 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <4F340E68.3090808@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F33F414.5050803@tycho.nsa.gov>
	<20276.1306.70587.543367@mariner.uk.xensource.com>
	<4F340E68.3090808@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain"):
> Uploaded to git://github.com/danieldg/xen-unstable.git #pending-xs

Marvellous, pushed, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:41:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYw1-0006Nf-8Z; Thu, 09 Feb 2012 18:41: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 1RvYvv-0006NH-MP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:41:28 +0000
Received: from [85.158.139.83:37700] by server-10.bemta-5.messagelabs.com id
	9D/3D-26909-653143F4; Thu, 09 Feb 2012 18:41:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328812886!14451344!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32177 invoked from network); 9 Feb 2012 18:41:26 -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;
	9 Feb 2012 18:41:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:41:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:41:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYvt-0005H7-Ow; Thu, 09 Feb 2012 18:41:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYvt-0004Y2-O4;
	Thu, 09 Feb 2012 18:41:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.4947.539671.761743@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:41:23 +0000
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3b98813bea086f1892af.1328540813@zhigang.us.oracle.com>,
	<9ae3b2b7b494ab8fbc54.1328299821@zhigang.us.oracle.com>
References: <9ae3b2b7b494ab8fbc54.1328299821@zhigang.us.oracle.com>
	<3b98813bea086f1892af.1328540813@zhigang.us.oracle.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>, Zhigang Wang <w1z2g3@gmail.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix bootloader args setting [and 1
	more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Zhigang Wang writes ("[Xen-devel] [PATCH] libxl: fix bootloader args setting"):
> libxl: fix bootloader args setting

Zhigang Wang writes ("[Xen-devel] [PATCH] libxl: fix bootloader args setting"):
...
> libxl: fix bootloader args setting

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:41:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvYw1-0006Nf-8Z; Thu, 09 Feb 2012 18:41: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 1RvYvv-0006NH-MP
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:41:28 +0000
Received: from [85.158.139.83:37700] by server-10.bemta-5.messagelabs.com id
	9D/3D-26909-653143F4; Thu, 09 Feb 2012 18:41:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328812886!14451344!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32177 invoked from network); 9 Feb 2012 18:41:26 -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;
	9 Feb 2012 18:41:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:41:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:41:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvYvt-0005H7-Ow; Thu, 09 Feb 2012 18:41:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvYvt-0004Y2-O4;
	Thu, 09 Feb 2012 18:41:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.4947.539671.761743@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:41:23 +0000
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3b98813bea086f1892af.1328540813@zhigang.us.oracle.com>,
	<9ae3b2b7b494ab8fbc54.1328299821@zhigang.us.oracle.com>
References: <9ae3b2b7b494ab8fbc54.1328299821@zhigang.us.oracle.com>
	<3b98813bea086f1892af.1328540813@zhigang.us.oracle.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>, Zhigang Wang <w1z2g3@gmail.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix bootloader args setting [and 1
	more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Zhigang Wang writes ("[Xen-devel] [PATCH] libxl: fix bootloader args setting"):
> libxl: fix bootloader args setting

Zhigang Wang writes ("[Xen-devel] [PATCH] libxl: fix bootloader args setting"):
...
> libxl: fix bootloader args setting

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:48:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:48: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.xensource.com>)
	id 1RvZ2e-0006pd-LO; Thu, 09 Feb 2012 18:48:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvZ2b-0006pP-G7
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:48:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328813295!10713702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22868 invoked from network); 9 Feb 2012 18:48:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 18:48:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:48:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:48:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvZ2U-0005JP-OI; Thu, 09 Feb 2012 18:48:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvZ2U-0004gx-NW;
	Thu, 09 Feb 2012 18:48:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.5358.715566.23994@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:48:14 +0000
To: Olaf Hering <olaf@aepfle.de>,
    hongkaixing@huawei.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>,
	<20120209095437.GA13435@aepfle.de>
References: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
	<20120209095437.GA13435@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add the dealing of
 MEM_EVENT_FLAG_EVICT_FAIL request in [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hongkaixing@huawei.com writes ("[Xen-devel] [PATCH] xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in"):
> xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in
> tools/xenpaging

Thanks, and to Olaf for the ack.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 18:48:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 18:48: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.xensource.com>)
	id 1RvZ2e-0006pd-LO; Thu, 09 Feb 2012 18:48:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvZ2b-0006pP-G7
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 18:48:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328813295!10713702!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22868 invoked from network); 9 Feb 2012 18:48:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2012 18:48:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10607789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 18:48:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 18:48:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvZ2U-0005JP-OI; Thu, 09 Feb 2012 18:48:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvZ2U-0004gx-NW;
	Thu, 09 Feb 2012 18:48:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20276.5358.715566.23994@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 18:48:14 +0000
To: Olaf Hering <olaf@aepfle.de>,
    hongkaixing@huawei.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>,
	<20120209095437.GA13435@aepfle.de>
References: <68eae0b487aef8349f16.1328777959@h00166998.china.huawei.com>
	<20120209095437.GA13435@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add the dealing of
 MEM_EVENT_FLAG_EVICT_FAIL request in [and 1 more messages]
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hongkaixing@huawei.com writes ("[Xen-devel] [PATCH] xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in"):
> xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in
> tools/xenpaging

Thanks, and to Olaf for the ack.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 19:56:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 19:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rva61-0008Pz-H6; Thu, 09 Feb 2012 19:55:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rva60-0008Pb-2O
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 19:55:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328817346!12531629!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15298 invoked from network); 9 Feb 2012 19:55:49 -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;
	9 Feb 2012 19:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325480400"; d="scan'208";a="181128695"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:55:45 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:55:45 -0500
Message-ID: <4F3424C0.2050103@citrix.com>
Date: Thu, 9 Feb 2012 19:55:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>	<20120117161208.GA21545@phenom.dumpdata.com>	<CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
	<20120209174210.GA14007@andromeda.dapyr.net>
In-Reply-To: <20120209174210.GA14007@andromeda.dapyr.net>
Cc: Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
 but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/12 17:42, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 28, 2012 at 01:19:23PM -0500, Todd Deshane wrote:
>> On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>>> On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
>>>> Hi,
>>>>
>>>> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
>>>> static on the Dom0 system. (I can PCI passthrough the audio card to a
>>>> DomU and that works). Native sound works fine.
>>>>
>>>> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
>>>> UTC 2012 i686 i686 i386 GNU/Linux
>>>
>>> Did you try 64-bit dom0?
>>
>> 64bit Dom0 works perfectly.
> 
> Aha! I have an inkling this is the
> 7a7546b377bdaa25ac77f33d9433c59f259b9688

This is "x86: xen: size struct xen_spinlock to always fit in
arch_spinlock_t" from the 3.2 stable tree.

There are many spinlock in sound/ affected by the bug fixed by the above
dunno if any would cause sound distortion but there were plenty of
deadlock opportunities though.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 19:56:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 19:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rva61-0008Pz-H6; Thu, 09 Feb 2012 19:55:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rva60-0008Pb-2O
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 19:55:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328817346!12531629!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15298 invoked from network); 9 Feb 2012 19:55:49 -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;
	9 Feb 2012 19:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325480400"; d="scan'208";a="181128695"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 14:55:45 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	14:55:45 -0500
Message-ID: <4F3424C0.2050103@citrix.com>
Date: Thu, 9 Feb 2012 19:55:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>	<20120117161208.GA21545@phenom.dumpdata.com>	<CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
	<20120209174210.GA14007@andromeda.dapyr.net>
In-Reply-To: <20120209174210.GA14007@andromeda.dapyr.net>
Cc: Todd Deshane <todd.deshane@xen.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
 but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 09/02/12 17:42, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 28, 2012 at 01:19:23PM -0500, Todd Deshane wrote:
>> On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>>> On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
>>>> Hi,
>>>>
>>>> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
>>>> static on the Dom0 system. (I can PCI passthrough the audio card to a
>>>> DomU and that works). Native sound works fine.
>>>>
>>>> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
>>>> UTC 2012 i686 i686 i386 GNU/Linux
>>>
>>> Did you try 64-bit dom0?
>>
>> 64bit Dom0 works perfectly.
> 
> Aha! I have an inkling this is the
> 7a7546b377bdaa25ac77f33d9433c59f259b9688

This is "x86: xen: size struct xen_spinlock to always fit in
arch_spinlock_t" from the 3.2 stable tree.

There are many spinlock in sound/ affected by the bug fixed by the above
dunno if any would cause sound distortion but there were plenty of
deadlock opportunities though.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 19:56:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 19: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.xensource.com>)
	id 1Rva6I-0008Rc-Ty; Thu, 09 Feb 2012 19:56: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 1Rva6I-0008RO-7a
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 19:56:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328817310!60477314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14269 invoked from network); 9 Feb 2012 19:55:10 -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;
	9 Feb 2012 19:55:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10608473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 19:56:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	19:56:13 +0000
Message-ID: <1328817372.13189.93.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 19:56:12 +0000
In-Reply-To: <A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
	<1328778962.6133.111.camel@zakaz.uk.xensource.com>
	<A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 18:21 +0000, Shriram Rajagopalan wrote:
> On 2012-02-09, at 1:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> >> # 
> > 
> > Previously this code would have been equivalent to passing 0 not 1. It
> > may be ok to change this but it should be separate.
> 
> > However I'm a bit
> > dubious about changing it without adding some code to detect if the
> > guest supports it.
> 
> It requires writing the suspend-cancel entry to xenstore on domain creation (if xen says that the guest supports it)
> 
>  And then read this field once during initialization in checkpoint/Remus code.
> 
> I haven't properly investigated the domain create code path. Any pointers on where I should start ?
> 
> > (I know libxl_domain_resume is currently broken for
> > the non-cooperative suspend
> 
> It's broken in such a way that neither domain checkpoint or Remus work.
> I ll take up your comment on the previous version of the patch:
>  Add a new public (or internal) API 
>  libxl_domain_suspend_cancel
> 
> and make the checkpoint and Remus related code call this instead of the domain_resume.

I don't think there is any need for that unless you think that is
actually a better API in its own right. Otherwise please just leave the
semantics of the existing calls to libxl_domain_resume alone when you
add the flag (i.e. pass 0 as the co-operative flag at all existing call
sites, retaining the existing behaviour). Other than that your patch was
fine.

Changing existing places to use co-operative resume without also
validating that the guest supports it is wrong in the normal migration
case and also masks a real bug in libxl_domain_resume which needs to be
fixed (it's on my TODO list) not papered over by assuming that all
guests know about cooperative resume.

If you need to make that argument conditional on Remus in subsequent
patches then that is fine since Remus implies, at least to some degree,
support for co-operative resume.

Ian.

> 
> Later, after adding the suspend-cancel xenstore entry creation patch, I can switch the code to using the above function with the cooperative flag.
> 
> > case but we shouldn't paper over that)
> > 
> > Ian.
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 19:56:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 19: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.xensource.com>)
	id 1Rva6I-0008Rc-Ty; Thu, 09 Feb 2012 19:56: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 1Rva6I-0008RO-7a
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 19:56:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328817310!60477314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14269 invoked from network); 9 Feb 2012 19:55:10 -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;
	9 Feb 2012 19:55:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="10608473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 19:56:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 9 Feb 2012
	19:56:13 +0000
Message-ID: <1328817372.13189.93.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 9 Feb 2012 19:56:12 +0000
In-Reply-To: <A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
References: <patchbomb.1328251796@athos.nss.cs.ubc.ca>
	<f853c88f0230a2e9d2e1.1328251800@athos.nss.cs.ubc.ca>
	<1328778962.6133.111.camel@zakaz.uk.xensource.com>
	<A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V3] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 18:21 +0000, Shriram Rajagopalan wrote:
> On 2012-02-09, at 1:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> >> # 
> > 
> > Previously this code would have been equivalent to passing 0 not 1. It
> > may be ok to change this but it should be separate.
> 
> > However I'm a bit
> > dubious about changing it without adding some code to detect if the
> > guest supports it.
> 
> It requires writing the suspend-cancel entry to xenstore on domain creation (if xen says that the guest supports it)
> 
>  And then read this field once during initialization in checkpoint/Remus code.
> 
> I haven't properly investigated the domain create code path. Any pointers on where I should start ?
> 
> > (I know libxl_domain_resume is currently broken for
> > the non-cooperative suspend
> 
> It's broken in such a way that neither domain checkpoint or Remus work.
> I ll take up your comment on the previous version of the patch:
>  Add a new public (or internal) API 
>  libxl_domain_suspend_cancel
> 
> and make the checkpoint and Remus related code call this instead of the domain_resume.

I don't think there is any need for that unless you think that is
actually a better API in its own right. Otherwise please just leave the
semantics of the existing calls to libxl_domain_resume alone when you
add the flag (i.e. pass 0 as the co-operative flag at all existing call
sites, retaining the existing behaviour). Other than that your patch was
fine.

Changing existing places to use co-operative resume without also
validating that the guest supports it is wrong in the normal migration
case and also masks a real bug in libxl_domain_resume which needs to be
fixed (it's on my TODO list) not papered over by assuming that all
guests know about cooperative resume.

If you need to make that argument conditional on Remus in subsequent
patches then that is fine since Remus implies, at least to some degree,
support for co-operative resume.

Ian.

> 
> Later, after adding the suspend-cancel xenstore entry creation patch, I can switch the code to using the above function with the cooperative flag.
> 
> > case but we shouldn't paper over that)
> > 
> > Ian.
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20: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.xensource.com>)
	id 1RvaOM-0000eM-SP; Thu, 09 Feb 2012 20:14:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kris@theendless.org>) id 1RvaOM-0000eH-02
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:14:54 +0000
X-Env-Sender: kris@theendless.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328818430!56100092!1
X-Originating-IP: [72.51.30.5]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5922 invoked from network); 9 Feb 2012 20:13:51 -0000
Received: from theendless.org (HELO mail.theendless.org) (72.51.30.5)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 20:13:51 -0000
Received: by mail.theendless.org (Postfix, from userid 102)
	id 2F567DC8003; Thu,  9 Feb 2012 15:14:46 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on theendless.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	HTML_FONT_FACE_BAD,HTML_MESSAGE,RDNS_NONE autolearn=no version=3.2.5
Received: from [192.168.20.24] (unknown [96.45.197.22])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by mail.theendless.org (Postfix) with ESMTP id E1469DC8002;
	Thu,  9 Feb 2012 15:14:45 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theendless.org;
	s=02012012; t=1328818485;
	bh=cuf4OBUVqNH134Jg0n2X7lhNwKcc4kNx9aFiVACO3I8=;
	h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:
	Message-Id:References:To;
	b=B9jY4sSnpFozWZ9Nz78meQ6aRtwPh4in0qJSHZiXgm7GGfW0WOiGp5ek6MkTqR8dN
	09Ft9hfWQC/5ZIW+3otbvhyOT37fA7de6V5fiTwoIpgdW+xNt90nfK176b/66gShqD
	zNnIqFNPXOBh033kf63rnByDGqjQ7HOxCJpFTUgU=
Mime-Version: 1.0 (Apple Message framework v1257)
From: Kris <kris@theendless.org>
In-Reply-To: <1328793091.6133.170.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:14:45 -0500
Message-Id: <26BE644B-66A9-488C-9A8C-847A3CABA39C@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
	<1328793091.6133.170.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
	with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1631960120241897590=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1631960120241897590==
Content-Type: multipart/alternative; boundary="Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3"


--Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2012-02-09, at 8:11 AM, Ian Campbell wrote:
> There's a good chance this is a guest kernel issue. What sort of =
guests
> are they and what kernel version are they running? Is there anything =
in
> the guest kernel logs or on the guest console?

I did some digging around in the kernel logs for the guest =
post-migration and found an entry that indicates the failure.
Feb  1 18:21:03 XX kernel: netfront: device eth0 has copying receive =
path.
Feb  1 18:21:03 XX kernel: netfront: device eth1 has copying receive =
path.
Feb  1 18:21:03 XX kernel: vif vif-3: 2 reading other end details from =
device/vif/3
Feb  1 18:21:03 XX kernel: xenbus: resume (talk_to_otherend) vif-3 =
failed: -2
Feb  1 18:21:03 XX kernel: Initializing CPU#1
Feb  1 18:21:03 XX kernel: Initializing CPU#2
Feb  1 18:21:03 XX kernel: Initializing CPU#3

Notice line 3&4.

I'll continue to try and replicate, but if this rings any bells, please =
comment.

Kris=

--Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On 2012-02-09, at 8:11 AM, Ian Campbell =
wrote:</div><blockquote type=3D"cite"><div>There's a good chance this is =
a guest kernel issue. What sort of guests<br>are they and what kernel =
version are they running? Is there anything in<br>the guest kernel logs =
or on the guest console?<br></div></blockquote></div><br><div>I did some =
digging around in the kernel logs for the guest post-migration and found =
an entry that indicates the failure.</div><div><span =
class=3D"Apple-style-span" style=3D"color: rgb(20, 20, 20); line-height: =
14px; font-family: 'Lucida Grande'; ">Feb &nbsp;1 18:21:03 XX kernel: =
netfront: device eth0 has copying receive path.<br style=3D"word-wrap: =
break-word; text-rendering: optimizelegibility; ">Feb &nbsp;1 18:21:03 =
XX kernel: netfront: device eth1 has copying receive path.<br =
style=3D"word-wrap: break-word; text-rendering: optimizelegibility; =
">Feb &nbsp;1 18:21:03 XX kernel: vif vif-3: 2 reading other end details =
from device/vif/3<br style=3D"word-wrap: break-word; text-rendering: =
optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: xenbus: resume =
(talk_to_otherend) vif-3 failed: -2<br style=3D"word-wrap: break-word; =
text-rendering: optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: =
Initializing CPU#1<br style=3D"word-wrap: break-word; text-rendering: =
optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: Initializing =
CPU#2<br style=3D"word-wrap: break-word; text-rendering: =
optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: Initializing =
CPU#3</span></div><div><span class=3D"Apple-style-span" style=3D"color: =
rgb(20, 20, 20); line-height: 14px; font-family: 'Lucida Grande'; =
"><br></span></div><div><font class=3D"Apple-style-span" color=3D"#141414"=
 face=3D"'Lucida Grande'"><span class=3D"Apple-style-span" =
style=3D"line-height: 14px;">Notice line =
3&amp;4.</span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: =
14px;"><br></span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: 14px;">I'll continue to =
try and replicate, but if this rings any bells, please =
comment.</span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: =
14px;"><br></span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: =
14px;">Kris</span></font></div></body></html>=

--Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3--


--===============1631960120241897590==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1631960120241897590==--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20: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.xensource.com>)
	id 1RvaOM-0000eM-SP; Thu, 09 Feb 2012 20:14:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kris@theendless.org>) id 1RvaOM-0000eH-02
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:14:54 +0000
X-Env-Sender: kris@theendless.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328818430!56100092!1
X-Originating-IP: [72.51.30.5]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5922 invoked from network); 9 Feb 2012 20:13:51 -0000
Received: from theendless.org (HELO mail.theendless.org) (72.51.30.5)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2012 20:13:51 -0000
Received: by mail.theendless.org (Postfix, from userid 102)
	id 2F567DC8003; Thu,  9 Feb 2012 15:14:46 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on theendless.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	HTML_FONT_FACE_BAD,HTML_MESSAGE,RDNS_NONE autolearn=no version=3.2.5
Received: from [192.168.20.24] (unknown [96.45.197.22])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by mail.theendless.org (Postfix) with ESMTP id E1469DC8002;
	Thu,  9 Feb 2012 15:14:45 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=theendless.org;
	s=02012012; t=1328818485;
	bh=cuf4OBUVqNH134Jg0n2X7lhNwKcc4kNx9aFiVACO3I8=;
	h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:
	Message-Id:References:To;
	b=B9jY4sSnpFozWZ9Nz78meQ6aRtwPh4in0qJSHZiXgm7GGfW0WOiGp5ek6MkTqR8dN
	09Ft9hfWQC/5ZIW+3otbvhyOT37fA7de6V5fiTwoIpgdW+xNt90nfK176b/66gShqD
	zNnIqFNPXOBh033kf63rnByDGqjQ7HOxCJpFTUgU=
Mime-Version: 1.0 (Apple Message framework v1257)
From: Kris <kris@theendless.org>
In-Reply-To: <1328793091.6133.170.camel@zakaz.uk.xensource.com>
Date: Thu, 9 Feb 2012 15:14:45 -0500
Message-Id: <26BE644B-66A9-488C-9A8C-847A3CABA39C@theendless.org>
References: <95AB9C88-9B9D-4798-9580-1350A72F277A@theendless.org>
	<1328793091.6133.170.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Question about xen network and strange happenings
	with migrating a node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1631960120241897590=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1631960120241897590==
Content-Type: multipart/alternative; boundary="Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3"


--Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2012-02-09, at 8:11 AM, Ian Campbell wrote:
> There's a good chance this is a guest kernel issue. What sort of =
guests
> are they and what kernel version are they running? Is there anything =
in
> the guest kernel logs or on the guest console?

I did some digging around in the kernel logs for the guest =
post-migration and found an entry that indicates the failure.
Feb  1 18:21:03 XX kernel: netfront: device eth0 has copying receive =
path.
Feb  1 18:21:03 XX kernel: netfront: device eth1 has copying receive =
path.
Feb  1 18:21:03 XX kernel: vif vif-3: 2 reading other end details from =
device/vif/3
Feb  1 18:21:03 XX kernel: xenbus: resume (talk_to_otherend) vif-3 =
failed: -2
Feb  1 18:21:03 XX kernel: Initializing CPU#1
Feb  1 18:21:03 XX kernel: Initializing CPU#2
Feb  1 18:21:03 XX kernel: Initializing CPU#3

Notice line 3&4.

I'll continue to try and replicate, but if this rings any bells, please =
comment.

Kris=

--Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On 2012-02-09, at 8:11 AM, Ian Campbell =
wrote:</div><blockquote type=3D"cite"><div>There's a good chance this is =
a guest kernel issue. What sort of guests<br>are they and what kernel =
version are they running? Is there anything in<br>the guest kernel logs =
or on the guest console?<br></div></blockquote></div><br><div>I did some =
digging around in the kernel logs for the guest post-migration and found =
an entry that indicates the failure.</div><div><span =
class=3D"Apple-style-span" style=3D"color: rgb(20, 20, 20); line-height: =
14px; font-family: 'Lucida Grande'; ">Feb &nbsp;1 18:21:03 XX kernel: =
netfront: device eth0 has copying receive path.<br style=3D"word-wrap: =
break-word; text-rendering: optimizelegibility; ">Feb &nbsp;1 18:21:03 =
XX kernel: netfront: device eth1 has copying receive path.<br =
style=3D"word-wrap: break-word; text-rendering: optimizelegibility; =
">Feb &nbsp;1 18:21:03 XX kernel: vif vif-3: 2 reading other end details =
from device/vif/3<br style=3D"word-wrap: break-word; text-rendering: =
optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: xenbus: resume =
(talk_to_otherend) vif-3 failed: -2<br style=3D"word-wrap: break-word; =
text-rendering: optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: =
Initializing CPU#1<br style=3D"word-wrap: break-word; text-rendering: =
optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: Initializing =
CPU#2<br style=3D"word-wrap: break-word; text-rendering: =
optimizelegibility; ">Feb &nbsp;1 18:21:03 XX kernel: Initializing =
CPU#3</span></div><div><span class=3D"Apple-style-span" style=3D"color: =
rgb(20, 20, 20); line-height: 14px; font-family: 'Lucida Grande'; =
"><br></span></div><div><font class=3D"Apple-style-span" color=3D"#141414"=
 face=3D"'Lucida Grande'"><span class=3D"Apple-style-span" =
style=3D"line-height: 14px;">Notice line =
3&amp;4.</span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: =
14px;"><br></span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: 14px;">I'll continue to =
try and replicate, but if this rings any bells, please =
comment.</span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: =
14px;"><br></span></font></div><div><font class=3D"Apple-style-span" =
color=3D"#141414" face=3D"'Lucida Grande'"><span =
class=3D"Apple-style-span" style=3D"line-height: =
14px;">Kris</span></font></div></body></html>=

--Apple-Mail=_4361B145-DF98-4FA5-9DBA-4D95A28188B3--


--===============1631960120241897590==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1631960120241897590==--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:16:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvaP5-0000gM-Ak; Thu, 09 Feb 2012 20:15:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvaP4-0000gE-9X
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:15:38 +0000
Received: from [85.158.139.83:30524] by server-2.bemta-5.messagelabs.com id
	9D/47-20725-969243F4; Thu, 09 Feb 2012 20:15:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328818535!14411885!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30790 invoked from network); 9 Feb 2012 20:15:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 20:15:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19KFWb9022147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 15:15:32 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19KFSRt022145;
	Thu, 9 Feb 2012 15:15:28 -0500
Date: Thu, 9 Feb 2012 16:15:28 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120209201527.GB14007@andromeda.dapyr.net>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
	<69f22464-d460-450c-a81b-77bda8cc7568@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <69f22464-d460-450c-a81b-77bda8cc7568@default>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Jan, you're right, I had forgotten about that "chained" dependency.
> Thanks and FWIW, on the entire original patch:
> 
> Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
>  

ok, applied to the tree.
> > It would be nice if all of it could become modules. That way HVM
> > device driver domains could load the whole thing without having much
> > built-in code in the kernel.
> > 
> > Is it possible to do that?
> 
> Konrad, my module expertise is very low, so I will leave that
> to Jan or someone else to answer or look into.

Sounds feasible, but would need to export some symbols. Hmm. Not sure.

> 
> Dan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:16:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20:16:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvaP5-0000gM-Ak; Thu, 09 Feb 2012 20:15:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvaP4-0000gE-9X
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:15:38 +0000
Received: from [85.158.139.83:30524] by server-2.bemta-5.messagelabs.com id
	9D/47-20725-969243F4; Thu, 09 Feb 2012 20:15:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328818535!14411885!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30790 invoked from network); 9 Feb 2012 20:15:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 20:15:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19KFWb9022147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 15:15:32 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19KFSRt022145;
	Thu, 9 Feb 2012 15:15:28 -0500
Date: Thu, 9 Feb 2012 16:15:28 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120209201527.GB14007@andromeda.dapyr.net>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
	<69f22464-d460-450c-a81b-77bda8cc7568@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <69f22464-d460-450c-a81b-77bda8cc7568@default>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Jan, you're right, I had forgotten about that "chained" dependency.
> Thanks and FWIW, on the entire original patch:
> 
> Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
>  

ok, applied to the tree.
> > It would be nice if all of it could become modules. That way HVM
> > device driver domains could load the whole thing without having much
> > built-in code in the kernel.
> > 
> > Is it possible to do that?
> 
> Konrad, my module expertise is very low, so I will leave that
> to Jan or someone else to answer or look into.

Sounds feasible, but would need to export some symbols. Hmm. Not sure.

> 
> Dan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:30:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvacs-0001Dk-Oq; Thu, 09 Feb 2012 20:29:54 +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 1Rvacq-0001Df-IH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:29:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328819254!52110757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29827 invoked from network); 9 Feb 2012 20:27:34 -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;
	9 Feb 2012 20:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,392,1325462400"; d="scan'208";a="10608863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 20:29:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 20:29:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rvacj-0005qO-53;
	Thu, 09 Feb 2012 20:29:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rvaci-00085p-Kh;
	Thu, 09 Feb 2012 20:29:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11904-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 20:29:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11904: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11904 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11904/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11903

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9fc810bb8145
baseline version:
 xen                  18b9ea53c8ac

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=9fc810bb8145
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9fc810bb8145
+ branch=xen-unstable
+ revision=9fc810bb8145
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 9fc810bb8145 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 43 changes to 35 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:30:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20:30:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvacs-0001Dk-Oq; Thu, 09 Feb 2012 20:29:54 +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 1Rvacq-0001Df-IH
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:29:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328819254!52110757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29827 invoked from network); 9 Feb 2012 20:27:34 -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;
	9 Feb 2012 20:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,392,1325462400"; d="scan'208";a="10608863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2012 20:29:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 9 Feb 2012 20:29:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rvacj-0005qO-53;
	Thu, 09 Feb 2012 20:29:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rvaci-00085p-Kh;
	Thu, 09 Feb 2012 20:29:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11904-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 9 Feb 2012 20:29:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11904: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11904 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11904/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11903

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9fc810bb8145
baseline version:
 xen                  18b9ea53c8ac

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=9fc810bb8145
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9fc810bb8145
+ branch=xen-unstable
+ revision=9fc810bb8145
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 9fc810bb8145 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 43 changes to 35 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:34:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20: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.xensource.com>)
	id 1Rvagn-0001iW-1l; Thu, 09 Feb 2012 20:33:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvagl-0001hx-LL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:33:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328819590!59511936!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5317 invoked from network); 9 Feb 2012 20:33:10 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 20:33:10 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id A24741A8083;
	Thu,  9 Feb 2012 12:33:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=XmxDVwA/YisvuXWNrurzEW/Ykk98PDcZ4+Gh2znciNQR
	ZuLzXAUvtYaBUylUOjqj0Vv3ZBo4pwWtZEbzDQunmCX/WCzIjJmnLyL0HNW4y9NU
	kg27SNnqwDx6cDpo37L4ZSCXy54YpNQYCrU8FpT3UxaP7ueVTR3gPWVNvAhc0VM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6bU8Lf0i3xANHF5x7lqmBZkJEVY=; b=twAD4/Mb
	ui1s/c/csjXrwtnbosS5j/SpjO+T9ftiVKkiZMrmVKxMu+y1MNgqzMFhdkVTz2lJ
	F35XY7Hw4xge8G/YvKO264Y7v/Hzwf0Z6i5T34eypl/8fpLEsD8kzcguSlVf2Q9U
	B//1+NgAUQHwILzLsuMHY3Ng/jmmciRxPH0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 06BB01A8069; 
	Thu,  9 Feb 2012 12:33:53 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 12:33:53 -0800
Message-ID: <068d8391fbb2862699b6a8c481ceb7ec.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20276.177.301401.848136@mariner.uk.xensource.com>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
	<20276.177.301401.848136@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 12:33:53 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 1 of 3] Use memops for
> mem paging, sharing, and access, instead of domctls"):
>> We retain the domctl interface for setting up and tearing down
>> paging/sharing/mem access for a domain. But we migrate all the per page
>> operations to use the memory_op hypercalls (e.g XENMEM_*).
>
> The tools part of this looks sensible (and pretty formulaic) to me.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> It'll need a hypervisor maintainer to approve the innards.

Both this and the next patch have been acked by Tim Deegan on the
hypervisor side.

However, I have not tested these in isolation. I've always used them
preceded by the "locking p2m series" posted earlier. I would suggest that
you hold off applying this until the locking p2m series gets applied. I
don't think there should be any problems, but I'm being conservative here.

Thanks!
Andres

>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:34:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20: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.xensource.com>)
	id 1Rvagn-0001iW-1l; Thu, 09 Feb 2012 20:33:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvagl-0001hx-LL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:33:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328819590!59511936!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5317 invoked from network); 9 Feb 2012 20:33:10 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 20:33:10 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id A24741A8083;
	Thu,  9 Feb 2012 12:33:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=XmxDVwA/YisvuXWNrurzEW/Ykk98PDcZ4+Gh2znciNQR
	ZuLzXAUvtYaBUylUOjqj0Vv3ZBo4pwWtZEbzDQunmCX/WCzIjJmnLyL0HNW4y9NU
	kg27SNnqwDx6cDpo37L4ZSCXy54YpNQYCrU8FpT3UxaP7ueVTR3gPWVNvAhc0VM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6bU8Lf0i3xANHF5x7lqmBZkJEVY=; b=twAD4/Mb
	ui1s/c/csjXrwtnbosS5j/SpjO+T9ftiVKkiZMrmVKxMu+y1MNgqzMFhdkVTz2lJ
	F35XY7Hw4xge8G/YvKO264Y7v/Hzwf0Z6i5T34eypl/8fpLEsD8kzcguSlVf2Q9U
	B//1+NgAUQHwILzLsuMHY3Ng/jmmciRxPH0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 06BB01A8069; 
	Thu,  9 Feb 2012 12:33:53 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Thu, 9 Feb 2012 12:33:53 -0800
Message-ID: <068d8391fbb2862699b6a8c481ceb7ec.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20276.177.301401.848136@mariner.uk.xensource.com>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<e187e3e400552b32f23e.1328767706@xdev.gridcentric.ca>
	<20276.177.301401.848136@mariner.uk.xensource.com>
Date: Thu, 9 Feb 2012 12:33:53 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 1 of 3] Use memops for
> mem paging, sharing, and access, instead of domctls"):
>> We retain the domctl interface for setting up and tearing down
>> paging/sharing/mem access for a domain. But we migrate all the per page
>> operations to use the memory_op hypercalls (e.g XENMEM_*).
>
> The tools part of this looks sensible (and pretty formulaic) to me.
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> It'll need a hypervisor maintainer to approve the innards.

Both this and the next patch have been acked by Tim Deegan on the
hypervisor side.

However, I have not tested these in isolation. I've always used them
preceded by the "locking p2m series" posted earlier. I would suggest that
you hold off applying this until the locking p2m series gets applied. I
don't think there should be any problems, but I'm being conservative here.

Thanks!
Andres

>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:40:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvan7-00020J-U5; Thu, 09 Feb 2012 20:40:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rvan6-00020E-OT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:40:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328820021!8577910!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31312 invoked from network); 9 Feb 2012 20:40:22 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 20:40:22 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19KeISW023067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 15:40:19 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19KeIjs023065;
	Thu, 9 Feb 2012 15:40:18 -0500
Date: Thu, 9 Feb 2012 16:40:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120209204018.GC14007@andromeda.dapyr.net>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
	<4F30E62B02000078000717EB@nat28.tlf.novell.com>
	<CACaajQt0MDNAN51g6AuYZn7ApwvuVgn+=GdyPNDJYVh95ecD0g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQt0MDNAN51g6AuYZn7ApwvuVgn+=GdyPNDJYVh95ecD0g@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 02:23:05PM +0400, Vasiliy Tolstov wrote:
> 2012/2/7 Jan Beulich <JBeulich@suse.com>:
> 
> >
> > As outlined above, it is possible, but I'm not certain it is a good idea
> > to have balloon_set_new_target() exported. If you think that's
> > acceptable, I can certainly put together a patch doing that (on top
> > of the one here, and probably not immediately).
> >
> > Jan
> 
> Exporting balloon_set_new_target can be grate feature to do own
> modules for balloon memory inside xen guest, becouse some times we
> need more realtime control from dom0 for memory growing speed inside
> guest.

Sounds like we have two use cases :-)

I am not seeing anything against it but I wonder if other virtualization
offerings would benefit from this as well? As in would it make sense to
export the virtio-ballon or the microsoft one as well? And perhaps have
an unified API? So that the ballloon drivers register and then have a
"virt_mem_set_new_target" exported?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 20:40:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 20:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvan7-00020J-U5; Thu, 09 Feb 2012 20:40:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rvan6-00020E-OT
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 20:40:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328820021!8577910!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31312 invoked from network); 9 Feb 2012 20:40:22 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 20:40:22 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19KeISW023067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 15:40:19 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19KeIjs023065;
	Thu, 9 Feb 2012 15:40:18 -0500
Date: Thu, 9 Feb 2012 16:40:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120209204018.GC14007@andromeda.dapyr.net>
References: <4F2C06A00200007800071071@nat28.tlf.novell.com>
	<d86f0be9-1530-47bd-b3fd-8c251e563b25@default>
	<4F2F998202000078000714CD@nat28.tlf.novell.com>
	<e871af1b-8003-4d3d-8fde-ea40545ff9fe@default>
	<4F3012B602000078000716AB@nat28.tlf.novell.com>
	<20120206170224.GD23240@phenom.dumpdata.com>
	<4F30E62B02000078000717EB@nat28.tlf.novell.com>
	<CACaajQt0MDNAN51g6AuYZn7ApwvuVgn+=GdyPNDJYVh95ecD0g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQt0MDNAN51g6AuYZn7ApwvuVgn+=GdyPNDJYVh95ecD0g@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen/tmem: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 07, 2012 at 02:23:05PM +0400, Vasiliy Tolstov wrote:
> 2012/2/7 Jan Beulich <JBeulich@suse.com>:
> 
> >
> > As outlined above, it is possible, but I'm not certain it is a good idea
> > to have balloon_set_new_target() exported. If you think that's
> > acceptable, I can certainly put together a patch doing that (on top
> > of the one here, and probably not immediately).
> >
> > Jan
> 
> Exporting balloon_set_new_target can be grate feature to do own
> modules for balloon memory inside xen guest, becouse some times we
> need more realtime control from dom0 for memory growing speed inside
> guest.

Sounds like we have two use cases :-)

I am not seeing anything against it but I wonder if other virtualization
offerings would benefit from this as well? As in would it make sense to
export the virtio-ballon or the microsoft one as well? And perhaps have
an unified API? So that the ballloon drivers register and then have a
"virt_mem_set_new_target" exported?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 21:14:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 21:14:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvbJ3-0002sO-Kl; Thu, 09 Feb 2012 21:13:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvbJ1-0002sF-Ub
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 21:13:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328821999!8525978!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16226 invoked from network); 9 Feb 2012 21:13:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 21:13:20 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19LDG5W026691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 16:13:16 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19LDGol026689;
	Thu, 9 Feb 2012 16:13:16 -0500
Date: Thu, 9 Feb 2012 17:13:16 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120209211316.GD14007@andromeda.dapyr.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 07:32:40PM +0300, Anton Samsonov wrote:
> I was experimenting with DomU redundancy and load balancing,
> and I think this GPF started to show up after a couple of DomUs
> with CARP and HAProxy were added that constantly generate
> a strong flow of network traffic by pinging target machines
> and each other as well. Or may be it is not related to CARP
> and pinging, but just depends on traffic volume: the more VMs
> added and running, the more chances that Dom0-DomU networking
> will collapse, the critical point being 8 guest domains, while I need 10.
> 
> I can't give exact steps to reproduce, as it happens randomly,
> usually without any correlated user activity, after several hours
> (or several minutes) of normal performance. But sometimes
> it happens not so long after a balancer's DomU startup or shutdown.
> After GPF happens, all VMs loose their networking connectivity.
> 
> Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)

Do you get the same issue with a pv-ops dom0? So also 3.1, but from
kernel.org?

> with Xen version 4.1.2_05-1.9, which is patched as described
> in openSUSE bug 727081 (bugzilla.novell.com/show_bug.cgi?id=727081).
> Supposedly "offending" DomU is paravirtualized NetBSD 5.1.1
> for AMD64 with recompiled kernel (CARP enabled, no more changes).

What is CARP?
> Other VMs are openSUSE 11.4 and 12.1 for AMD64.
> 
> 
> Trace log in /var/log/messages always looks similar (varying digits
> replaced with asterisks ***):
> 
> 
> general protection fault: 0000 [#1] SMP
> CPU {core-number}
> Modules linked in: 8250 8250_pnp af_packet asus_wmi ata_generic
> blkback_pagemap blkbk blktap bridge btrfs button cdrom dm_mod
> domctl drm drm_kms_helper edd eeepc_wmi ehci_hcd evtchn fuse
> gntdev hid hwmon i2c_algo_bit i2c_core i2c_i801 i915
> iTCO_vendor_support iTCO_wdt linear llc lzo_compress mei(C)
> microcode netbk parport parport_pc pata_via pci_hotplug pcspkr
> ppdev processor r8169 rfkill serial_core [serio_raw] sg
> snd snd_hda_codec snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_intel snd_hwdep snd_mixer_oss snd_page_alloc snd_pcm
> snd_pcm_oss snd_seq snd_seq_device snd_timer soundcore
> sparse_keymap sr_mod stp thermal_sys uas usbbk usbcore
> usbhid usb_storage video wmi xenblk xenbus_be xennet zlib_deflate
> 
> Pid: {process-id}, comm: netback/{0/1} Tainted: G
>          C  3.1.0-1.2-xen #1 System manufacturer System Product Name/P8H67-M
> RIP: e030:[<ffffffff803e7451>]  [<ffffffff803e7451>]
> skb_release_data.part.47+0x61/0xc0
> RSP: e02b:ffff880******d40  EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff880********0 RCX: ffff880******000
> RDX: {..RCX.+.0e80..} RSI: 00000000000000** RDI: 00***c**00000000
> RBP: {.....RBX......} R08: {..RCX.-.cff0..} R09: 0000000*********
> R10: 000000000000000* R11: {.task.+.0470..} R12: ffff880026a51000
> R13: ffff880********0 R14: ffffc900048****0 R15: 0000000000000001
> FS:  00007f*******7*0(0000) GS:ffff880******000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000***********0 CR3: 0000000******000 CR4: 0000000000042660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/{0/1} (pid: {process-id}, threadinfo ffff880******000,
> task ffff880********0)
> Stack:
>  0000000000000000 {.....RBX......} 0000000000000000 ffffffff803e7511
>  {.....RBX......} ffffffffa0***d2c {.....task.....} {thread.+.1e00.}
>  {thread.+.1db0.} {.R14.-.22a40..} ffffc9000000000* 0000000000000000

Hm, that is a pretty neat stack output. Wonder which patch of theirs
does that.

> Call Trace:
>  [<ffffffff803e7511>] __kfree_skb+0x11/0x20
>  [<ffffffffa0***d2c>] net_rx_action+0x66c/0x9c0 [netbk]
>  [<ffffffffa0***72a>] netbk_action_thread+0x5a/0x270 [netbk]
>  [<ffffffff8006438e>] kthread+0x7e/0x90
>  [<ffffffff8050f814>] kernel_thread_helper+0x4/0x10
> Code: 48 8b 7c 02 08 e8 90 69 cf ff 8b 95 d0 00 00 00
>   48 8b 8d d8 00 00 00 48 01 ca 0f b7 02 39 c3 7c
>   d1 f6 42 0c 10 74 1e 48 8b 7a 30
> RIP  [<ffffffff803e7451>] skb_release_data.part.47+0x61/0xc0
>  RSP <ffff880******d40>
> ---[ end trace **************** ]---
> 
> 
> Preceeding and subsequent messages don't seem to be related with GPF,
> time gap is from minutes to half an hour or even more. But if this could give
> some insight, I will post them, too.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 21:14:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 21:14:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvbJ3-0002sO-Kl; Thu, 09 Feb 2012 21:13:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvbJ1-0002sF-Ub
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 21:13:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328821999!8525978!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16226 invoked from network); 9 Feb 2012 21:13:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 21:13:20 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19LDG5W026691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 16:13:16 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19LDGol026689;
	Thu, 9 Feb 2012 16:13:16 -0500
Date: Thu, 9 Feb 2012 17:13:16 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120209211316.GD14007@andromeda.dapyr.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 03, 2012 at 07:32:40PM +0300, Anton Samsonov wrote:
> I was experimenting with DomU redundancy and load balancing,
> and I think this GPF started to show up after a couple of DomUs
> with CARP and HAProxy were added that constantly generate
> a strong flow of network traffic by pinging target machines
> and each other as well. Or may be it is not related to CARP
> and pinging, but just depends on traffic volume: the more VMs
> added and running, the more chances that Dom0-DomU networking
> will collapse, the critical point being 8 guest domains, while I need 10.
> 
> I can't give exact steps to reproduce, as it happens randomly,
> usually without any correlated user activity, after several hours
> (or several minutes) of normal performance. But sometimes
> it happens not so long after a balancer's DomU startup or shutdown.
> After GPF happens, all VMs loose their networking connectivity.
> 
> Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)

Do you get the same issue with a pv-ops dom0? So also 3.1, but from
kernel.org?

> with Xen version 4.1.2_05-1.9, which is patched as described
> in openSUSE bug 727081 (bugzilla.novell.com/show_bug.cgi?id=727081).
> Supposedly "offending" DomU is paravirtualized NetBSD 5.1.1
> for AMD64 with recompiled kernel (CARP enabled, no more changes).

What is CARP?
> Other VMs are openSUSE 11.4 and 12.1 for AMD64.
> 
> 
> Trace log in /var/log/messages always looks similar (varying digits
> replaced with asterisks ***):
> 
> 
> general protection fault: 0000 [#1] SMP
> CPU {core-number}
> Modules linked in: 8250 8250_pnp af_packet asus_wmi ata_generic
> blkback_pagemap blkbk blktap bridge btrfs button cdrom dm_mod
> domctl drm drm_kms_helper edd eeepc_wmi ehci_hcd evtchn fuse
> gntdev hid hwmon i2c_algo_bit i2c_core i2c_i801 i915
> iTCO_vendor_support iTCO_wdt linear llc lzo_compress mei(C)
> microcode netbk parport parport_pc pata_via pci_hotplug pcspkr
> ppdev processor r8169 rfkill serial_core [serio_raw] sg
> snd snd_hda_codec snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_intel snd_hwdep snd_mixer_oss snd_page_alloc snd_pcm
> snd_pcm_oss snd_seq snd_seq_device snd_timer soundcore
> sparse_keymap sr_mod stp thermal_sys uas usbbk usbcore
> usbhid usb_storage video wmi xenblk xenbus_be xennet zlib_deflate
> 
> Pid: {process-id}, comm: netback/{0/1} Tainted: G
>          C  3.1.0-1.2-xen #1 System manufacturer System Product Name/P8H67-M
> RIP: e030:[<ffffffff803e7451>]  [<ffffffff803e7451>]
> skb_release_data.part.47+0x61/0xc0
> RSP: e02b:ffff880******d40  EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff880********0 RCX: ffff880******000
> RDX: {..RCX.+.0e80..} RSI: 00000000000000** RDI: 00***c**00000000
> RBP: {.....RBX......} R08: {..RCX.-.cff0..} R09: 0000000*********
> R10: 000000000000000* R11: {.task.+.0470..} R12: ffff880026a51000
> R13: ffff880********0 R14: ffffc900048****0 R15: 0000000000000001
> FS:  00007f*******7*0(0000) GS:ffff880******000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000***********0 CR3: 0000000******000 CR4: 0000000000042660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/{0/1} (pid: {process-id}, threadinfo ffff880******000,
> task ffff880********0)
> Stack:
>  0000000000000000 {.....RBX......} 0000000000000000 ffffffff803e7511
>  {.....RBX......} ffffffffa0***d2c {.....task.....} {thread.+.1e00.}
>  {thread.+.1db0.} {.R14.-.22a40..} ffffc9000000000* 0000000000000000

Hm, that is a pretty neat stack output. Wonder which patch of theirs
does that.

> Call Trace:
>  [<ffffffff803e7511>] __kfree_skb+0x11/0x20
>  [<ffffffffa0***d2c>] net_rx_action+0x66c/0x9c0 [netbk]
>  [<ffffffffa0***72a>] netbk_action_thread+0x5a/0x270 [netbk]
>  [<ffffffff8006438e>] kthread+0x7e/0x90
>  [<ffffffff8050f814>] kernel_thread_helper+0x4/0x10
> Code: 48 8b 7c 02 08 e8 90 69 cf ff 8b 95 d0 00 00 00
>   48 8b 8d d8 00 00 00 48 01 ca 0f b7 02 39 c3 7c
>   d1 f6 42 0c 10 74 1e 48 8b 7a 30
> RIP  [<ffffffff803e7451>] skb_release_data.part.47+0x61/0xc0
>  RSP <ffff880******d40>
> ---[ end trace **************** ]---
> 
> 
> Preceeding and subsequent messages don't seem to be related with GPF,
> time gap is from minutes to half an hour or even more. But if this could give
> some insight, I will post them, too.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 21:22:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 21: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.xensource.com>)
	id 1RvbRG-0003L9-KE; Thu, 09 Feb 2012 21:21:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvbRF-0003L4-AL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 21:21:57 +0000
Received: from [85.158.139.83:21082] by server-9.bemta-5.messagelabs.com id
	2A/22-23757-4F8343F4; Thu, 09 Feb 2012 21:21:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328822513!14445046!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18764 invoked from network); 9 Feb 2012 21:21:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 21:21:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19LLl8S026964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 16:21:47 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19LLlwD026962;
	Thu, 9 Feb 2012 16:21:47 -0500
Date: Thu, 9 Feb 2012 17:21:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Pasi K?rkk?inen <pasik@iki.fi>, jbarnes@virtuousgeek.org, mjg@redhat.com, 
	linux-kernel@vger.kernel.org
Message-ID: <20120209212147.GE14007@andromeda.dapyr.net>
References: <20120203180952.GP12984@reaktio.net>
	<20120203185527.GA9290@phenom.dumpdata.com>
	<20120205194413.GR12984@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120205194413.GR12984@reaktio.net>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
	Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 05, 2012 at 09:44:13PM +0200, Pasi K?rkk?inen wrote:
> On Fri, Feb 03, 2012 at 01:55:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K?rkk?inen wrote:
> > > Hello,
> > > 
> > > IIRC there was some discussion earlier about these messages in Xen's dmesg:
> > > 
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > 
> > > At least on my systems there's continuous flood of those messages, so they will fill up the
> > > Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuable information, just those messages.
> > 
> > Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
> > which is the intel_ips driver doing.
> > 
> 
> Yeah, it's always the same..
> 
> > > 
> > > I seem to be getting those messages even when there's only dom0 running.
> > > Is the plan to drop those messages? What's causing them? 
> > 
> > Looks to be the intel-ips. If you rename it does the issue disappear?
> 
> I just did "rmmod intel_ips" and the flood stopped.. 
> 
> 
> Btw on baremetal I get this in dmesg:
> 
> [  745.033645] CPU1: Core temperature above threshold, cpu clock throttled (total events = 1)
> [  745.033652] CPU3: Core temperature above threshold, cpu clock throttled (total events = 1)
> [  745.034676] CPU1: Core temperature/speed normal
> [  745.034678] CPU3: Core temperature/speed normal
> [  849.678508] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9682, limit 9000
> [  899.614074] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9896, limit 9000
> [  899.722881] [Hardware Error]: Machine check events logged
> [ 1172.675987] CPU3: Core temperature above threshold, cpu clock throttled (total events = 78)
> [ 1172.675990] CPU1: Core temperature above threshold, cpu clock throttled (total events = 78)
> [ 1172.677038] CPU1: Core temperature/speed normal
> [ 1172.677042] CPU3: Core temperature/speed normal
> [ 1174.260050] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9676, limit 9000
> [ 1199.339634] [Hardware Error]: Machine check events logged

Jesse, and Matthew,

Is there a way to make the intel_ips.c driver be in a "low-power" state?

My first thought about fixing this was that we could allow the
hypervisor to allow those RDMSR but the Linux kernel has no power to
actually influence the power management (as the hypervisor is in charge
of that) - so would the driver be capable of just sitting back and
not influencing the CPU?

> 
> 
> -- Pasi
> 
> 
> > > 
> > > hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=470035,
> > > they're related to dom0 kernel acpi-cpufreq ?
> > > 
> > > Also it seems there was discussion about the subject on 2011/08:
> > > http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00561.html
> > > 
> > > 
> > > Xen hypervisor 4.1.2.
> > > dom0 Linux kernel 3.2.2.
> > > 
> > > 
> > > Thanks,
> > > 
> > > -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 21:22:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 21: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.xensource.com>)
	id 1RvbRG-0003L9-KE; Thu, 09 Feb 2012 21:21:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RvbRF-0003L4-AL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 21:21:57 +0000
Received: from [85.158.139.83:21082] by server-9.bemta-5.messagelabs.com id
	2A/22-23757-4F8343F4; Thu, 09 Feb 2012 21:21:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328822513!14445046!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18764 invoked from network); 9 Feb 2012 21:21:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 21:21:55 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q19LLl8S026964
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Feb 2012 16:21:47 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q19LLlwD026962;
	Thu, 9 Feb 2012 16:21:47 -0500
Date: Thu, 9 Feb 2012 17:21:47 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Pasi K?rkk?inen <pasik@iki.fi>, jbarnes@virtuousgeek.org, mjg@redhat.com, 
	linux-kernel@vger.kernel.org
Message-ID: <20120209212147.GE14007@andromeda.dapyr.net>
References: <20120203180952.GP12984@reaktio.net>
	<20120203185527.GA9290@phenom.dumpdata.com>
	<20120205194413.GR12984@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120205194413.GR12984@reaktio.net>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
	Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Feb 05, 2012 at 09:44:13PM +0200, Pasi K?rkk?inen wrote:
> On Fri, Feb 03, 2012 at 01:55:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K?rkk?inen wrote:
> > > Hello,
> > > 
> > > IIRC there was some discussion earlier about these messages in Xen's dmesg:
> > > 
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from 0x0000000000c800c8 to 0x0000000080c880c8.
> > > 
> > > At least on my systems there's continuous flood of those messages, so they will fill up the
> > > Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any valuable information, just those messages.
> > 
> > Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
> > which is the intel_ips driver doing.
> > 
> 
> Yeah, it's always the same..
> 
> > > 
> > > I seem to be getting those messages even when there's only dom0 running.
> > > Is the plan to drop those messages? What's causing them? 
> > 
> > Looks to be the intel-ips. If you rename it does the issue disappear?
> 
> I just did "rmmod intel_ips" and the flood stopped.. 
> 
> 
> Btw on baremetal I get this in dmesg:
> 
> [  745.033645] CPU1: Core temperature above threshold, cpu clock throttled (total events = 1)
> [  745.033652] CPU3: Core temperature above threshold, cpu clock throttled (total events = 1)
> [  745.034676] CPU1: Core temperature/speed normal
> [  745.034678] CPU3: Core temperature/speed normal
> [  849.678508] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9682, limit 9000
> [  899.614074] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9896, limit 9000
> [  899.722881] [Hardware Error]: Machine check events logged
> [ 1172.675987] CPU3: Core temperature above threshold, cpu clock throttled (total events = 78)
> [ 1172.675990] CPU1: Core temperature above threshold, cpu clock throttled (total events = 78)
> [ 1172.677038] CPU1: Core temperature/speed normal
> [ 1172.677042] CPU3: Core temperature/speed normal
> [ 1174.260050] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 9676, limit 9000
> [ 1199.339634] [Hardware Error]: Machine check events logged

Jesse, and Matthew,

Is there a way to make the intel_ips.c driver be in a "low-power" state?

My first thought about fixing this was that we could allow the
hypervisor to allow those RDMSR but the Linux kernel has no power to
actually influence the power management (as the hypervisor is in charge
of that) - so would the driver be capable of just sitting back and
not influencing the CPU?

> 
> 
> -- Pasi
> 
> 
> > > 
> > > hmm, according to this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=470035,
> > > they're related to dom0 kernel acpi-cpufreq ?
> > > 
> > > Also it seems there was discussion about the subject on 2011/08:
> > > http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00561.html
> > > 
> > > 
> > > Xen hypervisor 4.1.2.
> > > dom0 Linux kernel 3.2.2.
> > > 
> > > 
> > > Thanks,
> > > 
> > > -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 21:27:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 21: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.xensource.com>)
	id 1RvbWb-0003UI-Df; Thu, 09 Feb 2012 21:27:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jbarnes@virtuousgeek.org>) id 1RvbWZ-0003U3-TL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 21:27:28 +0000
X-Env-Sender: jbarnes@virtuousgeek.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328822840!13919520!1
X-Originating-IP: [67.222.55.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiAzMTA2OQ==\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiAzMTA2OQ==\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7486 invoked from network); 9 Feb 2012 21:27:21 -0000
Received: from oproxy7-pub.bluehost.com (HELO oproxy7-pub.bluehost.com)
	(67.222.55.9) by server-5.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 21:27:21 -0000
Received: (qmail 2905 invoked by uid 0); 9 Feb 2012 21:27:20 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114)
	by oproxy7.bluehost.com with SMTP; 9 Feb 2012 21:27:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=virtuousgeek.org; s=default; 
	h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date;
	bh=fJOt4W0lXOeRqqZ+U4d3QRrwkjbw9h4hrEbjTpDaet8=; 
	b=fieRTsLeok+7lZzPoZdJJYKZ8G0qXj3vIsbmxyx8mYOep0z+gDu3kiLf6mhGoAL6HHU0/gAT26R3SwSDEdv88/eTce4nHKK9jcJwD3bZYYC8GTDZDDayMMiWt+XvOgNW;
Received: from c-67-161-37-189.hsd1.ca.comcast.net ([67.161.37.189]
	helo=jbarnes-desktop)
	by box514.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.76) (envelope-from <jbarnes@virtuousgeek.org>)
	id 1RvbWR-0003wO-Nu; Thu, 09 Feb 2012 14:27:19 -0700
Date: Thu, 9 Feb 2012 13:27:15 -0800
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120209132715.2d1c0c9f@jbarnes-desktop>
In-Reply-To: <20120209212147.GE14007@andromeda.dapyr.net>
References: <20120203180952.GP12984@reaktio.net>
	<20120203185527.GA9290@phenom.dumpdata.com>
	<20120205194413.GR12984@reaktio.net>
	<20120209212147.GE14007@andromeda.dapyr.net>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu)
Mime-Version: 1.0
X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org}
	{sentby:smtp auth 67.161.37.189 authed with
	jbarnes@virtuousgeek.org}
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, mjg@redhat.com
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
 Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7205802593020271398=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7205802593020271398==
Content-Type: multipart/signed; micalg=PGP-SHA1;
 boundary="Sig_/4liGmi54FawsoUZLu5aCTz7"; protocol="application/pgp-signature"

--Sig_/4liGmi54FawsoUZLu5aCTz7
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 9 Feb 2012 17:21:47 -0400
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Sun, Feb 05, 2012 at 09:44:13PM +0200, Pasi K?rkk?inen wrote:
> > On Fri, Feb 03, 2012 at 01:55:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K?rkk?inen wrote:
> > > > Hello,
> > > >=20
> > > > IIRC there was some discussion earlier about these messages in Xen'=
s dmesg:
> > > >=20
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > >=20
> > > > At least on my systems there's continuous flood of those messages, =
so they will fill up the
> > > > Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any va=
luable information, just those messages.
> > >=20
> > > Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
> > > which is the intel_ips driver doing.
> > >=20
> >=20
> > Yeah, it's always the same..
> >=20
> > > >=20
> > > > I seem to be getting those messages even when there's only dom0 run=
ning.
> > > > Is the plan to drop those messages? What's causing them?=20
> > >=20
> > > Looks to be the intel-ips. If you rename it does the issue disappear?
> >=20
> > I just did "rmmod intel_ips" and the flood stopped..=20
> >=20
> >=20
> > Btw on baremetal I get this in dmesg:
> >=20
> > [  745.033645] CPU1: Core temperature above threshold, cpu clock thrott=
led (total events =3D 1)
> > [  745.033652] CPU3: Core temperature above threshold, cpu clock thrott=
led (total events =3D 1)
> > [  745.034676] CPU1: Core temperature/speed normal
> > [  745.034678] CPU3: Core temperature/speed normal
> > [  849.678508] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 968=
2, limit 9000
> > [  899.614074] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 989=
6, limit 9000
> > [  899.722881] [Hardware Error]: Machine check events logged
> > [ 1172.675987] CPU3: Core temperature above threshold, cpu clock thrott=
led (total events =3D 78)
> > [ 1172.675990] CPU1: Core temperature above threshold, cpu clock thrott=
led (total events =3D 78)
> > [ 1172.677038] CPU1: Core temperature/speed normal
> > [ 1172.677042] CPU3: Core temperature/speed normal
> > [ 1174.260050] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 967=
6, limit 9000
> > [ 1199.339634] [Hardware Error]: Machine check events logged
>=20
> Jesse, and Matthew,
>=20
> Is there a way to make the intel_ips.c driver be in a "low-power" state?
>=20
> My first thought about fixing this was that we could allow the
> hypervisor to allow those RDMSR but the Linux kernel has no power to
> actually influence the power management (as the hypervisor is in charge
> of that) - so would the driver be capable of just sitting back and
> not influencing the CPU?

Yeah it's easy enough to turn off or disable.  But it doesn't currently
export any knobs for controlling behavior.  I don't have any issue with
exposing some though...

--=20
Jesse Barnes, Intel Open Source Technology Center

--Sig_/4liGmi54FawsoUZLu5aCTz7
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJPNDozAAoJEIEoDkX4Qk9hNG8P/2O4qC/yeOchS+0rkzMnd6iS
+37M6Om9v+pe14NepikfVosYFMNEbDZftI4jdR4X/vWVONlKXIDt+Et77OyoR1oZ
MLvNSEBJ2rIRdyyXVyi9Y7Ypqpsx8F1d8PjtP+t6svaf+C1r9z+6vWAiF8U7KX10
rL5heVhCPdCXI93BHMTu4X2rWHKqFIIc0E89IdKZ19aXgUcBjUzaYwQDrR9oE5LP
dadhyv42is7jHYFp3EwelLcQP0kawtGMWiCYnOVPEss8AOcWC5IBbZSiYChXRRII
WhAVkI+mvpYntgtZUpspXLOEKJnGiH4uOAgzDD2B80gbZAzYcWewkNhkFpoJ94gP
+Ova2zguX0VHEM8uoeL+TQ9yHRely5euWLHBOGgFVczN6DafDCc4qYE73CgEYjjx
s77PHNJHUuD6U3A0Qg431A5gLxiHnpoKuIsmkEq2j1HdkuJbsCru6HAPH7rvx+jz
9qnCjbK0zf35QlVqWbonXJdNvPEXiec5LQmSP2Rq1FitZxhZUJwTOMDNU9CRWWfB
3HfxqdoMuFd9ic9fzzJKIqW2wOcPPPTJl5xuKxIpep76sfQ5wj++XnFhHhGCoqcN
rtnKTn8haMIgr/2AQwoLMT650HsBodWZibSq+qb+x0DQx9gSB9/UMLTpttDEDz6w
g5It+ECVoPZ+951Ut3U7
=U1xd
-----END PGP SIGNATURE-----

--Sig_/4liGmi54FawsoUZLu5aCTz7--


--===============7205802593020271398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7205802593020271398==--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 21:27:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 21: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.xensource.com>)
	id 1RvbWb-0003UI-Df; Thu, 09 Feb 2012 21:27:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jbarnes@virtuousgeek.org>) id 1RvbWZ-0003U3-TL
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 21:27:28 +0000
X-Env-Sender: jbarnes@virtuousgeek.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328822840!13919520!1
X-Originating-IP: [67.222.55.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiAzMTA2OQ==\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiAzMTA2OQ==\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7486 invoked from network); 9 Feb 2012 21:27:21 -0000
Received: from oproxy7-pub.bluehost.com (HELO oproxy7-pub.bluehost.com)
	(67.222.55.9) by server-5.tower-216.messagelabs.com with SMTP;
	9 Feb 2012 21:27:21 -0000
Received: (qmail 2905 invoked by uid 0); 9 Feb 2012 21:27:20 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114)
	by oproxy7.bluehost.com with SMTP; 9 Feb 2012 21:27:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=virtuousgeek.org; s=default; 
	h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date;
	bh=fJOt4W0lXOeRqqZ+U4d3QRrwkjbw9h4hrEbjTpDaet8=; 
	b=fieRTsLeok+7lZzPoZdJJYKZ8G0qXj3vIsbmxyx8mYOep0z+gDu3kiLf6mhGoAL6HHU0/gAT26R3SwSDEdv88/eTce4nHKK9jcJwD3bZYYC8GTDZDDayMMiWt+XvOgNW;
Received: from c-67-161-37-189.hsd1.ca.comcast.net ([67.161.37.189]
	helo=jbarnes-desktop)
	by box514.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.76) (envelope-from <jbarnes@virtuousgeek.org>)
	id 1RvbWR-0003wO-Nu; Thu, 09 Feb 2012 14:27:19 -0700
Date: Thu, 9 Feb 2012 13:27:15 -0800
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120209132715.2d1c0c9f@jbarnes-desktop>
In-Reply-To: <20120209212147.GE14007@andromeda.dapyr.net>
References: <20120203180952.GP12984@reaktio.net>
	<20120203185527.GA9290@phenom.dumpdata.com>
	<20120205194413.GR12984@reaktio.net>
	<20120209212147.GE14007@andromeda.dapyr.net>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu)
Mime-Version: 1.0
X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org}
	{sentby:smtp auth 67.161.37.189 authed with
	jbarnes@virtuousgeek.org}
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, mjg@redhat.com
Subject: Re: [Xen-devel] Stop the continuous flood of (XEN) traps.c:2432:d0
 Domain	attempted WRMSR ..
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7205802593020271398=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7205802593020271398==
Content-Type: multipart/signed; micalg=PGP-SHA1;
 boundary="Sig_/4liGmi54FawsoUZLu5aCTz7"; protocol="application/pgp-signature"

--Sig_/4liGmi54FawsoUZLu5aCTz7
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 9 Feb 2012 17:21:47 -0400
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Sun, Feb 05, 2012 at 09:44:13PM +0200, Pasi K?rkk?inen wrote:
> > On Fri, Feb 03, 2012 at 01:55:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Feb 03, 2012 at 08:09:52PM +0200, Pasi K?rkk?inen wrote:
> > > > Hello,
> > > >=20
> > > > IIRC there was some discussion earlier about these messages in Xen'=
s dmesg:
> > > >=20
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > > (XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from =
0x0000000000c800c8 to 0x0000000080c880c8.
> > > >=20
> > > > At least on my systems there's continuous flood of those messages, =
so they will fill up the
> > > > Xen dmesg log buffer and "xm dmesg" or "xl dmesg" won't show any va=
luable information, just those messages.
> > >=20
> > > Is it always that MSR? That looks to be TURBO_POWER_CURRENT_LIMIT
> > > which is the intel_ips driver doing.
> > >=20
> >=20
> > Yeah, it's always the same..
> >=20
> > > >=20
> > > > I seem to be getting those messages even when there's only dom0 run=
ning.
> > > > Is the plan to drop those messages? What's causing them?=20
> > >=20
> > > Looks to be the intel-ips. If you rename it does the issue disappear?
> >=20
> > I just did "rmmod intel_ips" and the flood stopped..=20
> >=20
> >=20
> > Btw on baremetal I get this in dmesg:
> >=20
> > [  745.033645] CPU1: Core temperature above threshold, cpu clock thrott=
led (total events =3D 1)
> > [  745.033652] CPU3: Core temperature above threshold, cpu clock thrott=
led (total events =3D 1)
> > [  745.034676] CPU1: Core temperature/speed normal
> > [  745.034678] CPU3: Core temperature/speed normal
> > [  849.678508] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 968=
2, limit 9000
> > [  899.614074] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 989=
6, limit 9000
> > [  899.722881] [Hardware Error]: Machine check events logged
> > [ 1172.675987] CPU3: Core temperature above threshold, cpu clock thrott=
led (total events =3D 78)
> > [ 1172.675990] CPU1: Core temperature above threshold, cpu clock thrott=
led (total events =3D 78)
> > [ 1172.677038] CPU1: Core temperature/speed normal
> > [ 1172.677042] CPU3: Core temperature/speed normal
> > [ 1174.260050] intel ips 0000:00:1f.6: MCP limit exceeded: Avg temp 967=
6, limit 9000
> > [ 1199.339634] [Hardware Error]: Machine check events logged
>=20
> Jesse, and Matthew,
>=20
> Is there a way to make the intel_ips.c driver be in a "low-power" state?
>=20
> My first thought about fixing this was that we could allow the
> hypervisor to allow those RDMSR but the Linux kernel has no power to
> actually influence the power management (as the hypervisor is in charge
> of that) - so would the driver be capable of just sitting back and
> not influencing the CPU?

Yeah it's easy enough to turn off or disable.  But it doesn't currently
export any knobs for controlling behavior.  I don't have any issue with
exposing some though...

--=20
Jesse Barnes, Intel Open Source Technology Center

--Sig_/4liGmi54FawsoUZLu5aCTz7
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJPNDozAAoJEIEoDkX4Qk9hNG8P/2O4qC/yeOchS+0rkzMnd6iS
+37M6Om9v+pe14NepikfVosYFMNEbDZftI4jdR4X/vWVONlKXIDt+Et77OyoR1oZ
MLvNSEBJ2rIRdyyXVyi9Y7Ypqpsx8F1d8PjtP+t6svaf+C1r9z+6vWAiF8U7KX10
rL5heVhCPdCXI93BHMTu4X2rWHKqFIIc0E89IdKZ19aXgUcBjUzaYwQDrR9oE5LP
dadhyv42is7jHYFp3EwelLcQP0kawtGMWiCYnOVPEss8AOcWC5IBbZSiYChXRRII
WhAVkI+mvpYntgtZUpspXLOEKJnGiH4uOAgzDD2B80gbZAzYcWewkNhkFpoJ94gP
+Ova2zguX0VHEM8uoeL+TQ9yHRely5euWLHBOGgFVczN6DafDCc4qYE73CgEYjjx
s77PHNJHUuD6U3A0Qg431A5gLxiHnpoKuIsmkEq2j1HdkuJbsCru6HAPH7rvx+jz
9qnCjbK0zf35QlVqWbonXJdNvPEXiec5LQmSP2Rq1FitZxhZUJwTOMDNU9CRWWfB
3HfxqdoMuFd9ic9fzzJKIqW2wOcPPPTJl5xuKxIpep76sfQ5wj++XnFhHhGCoqcN
rtnKTn8haMIgr/2AQwoLMT650HsBodWZibSq+qb+x0DQx9gSB9/UMLTpttDEDz6w
g5It+ECVoPZ+951Ut3U7
=U1xd
-----END PGP SIGNATURE-----

--Sig_/4liGmi54FawsoUZLu5aCTz7--


--===============7205802593020271398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7205802593020271398==--


From xen-devel-bounces@lists.xensource.com Thu Feb 09 23:33:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 23:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvdU1-0004x9-8Q; Thu, 09 Feb 2012 23:32:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvdTz-0004x4-73
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 23:32:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328830368!10837182!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 9 Feb 2012 23:32:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 23:32:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvdTr-0005MS-1S; Thu, 09 Feb 2012 23:32:47 +0000
Date: Thu, 9 Feb 2012 23:32:46 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120209233246.GA20578@ocelot.phlegethon.org>
References: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
	<20120209074242.GC71900@ocelot.phlegethon.org>
	<61936533ef44253d5e1b7036711d1324.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61936533ef44253d5e1b7036711d1324.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
	shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:50 -0800 on 09 Feb (1328770222), Andres Lagar-Cavilla wrote:
> > At 01:01 -0500 on 09 Feb (1328749297), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mem_sharing.c |  4 +++-
> >>  xen/arch/x86/mm/p2m.c         |  6 ++++--
> >>  2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > NACK, I'm afraid, especially the second one.  '<=' comparisons with a
> > number that's made up of a count ORed with a type don't make sense.
> > If you want to test both type and count, just test them separately.
> 
> The type I'm ORing with is a mask with single bit set, not a multi-bit
> type mask. And the type is defined as a higher order bit than the count
> mask.

It is right now, but if someone reshuffles the page_info struct again
you don't want it to banjax your super-cunning code.  Just test the
thing you need to test. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 09 23:33:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 09 Feb 2012 23:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvdU1-0004x9-8Q; Thu, 09 Feb 2012 23:32:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvdTz-0004x4-73
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 23:32:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328830368!10837182!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 9 Feb 2012 23:32:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Feb 2012 23:32:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvdTr-0005MS-1S; Thu, 09 Feb 2012 23:32:47 +0000
Date: Thu, 9 Feb 2012 23:32:46 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120209233246.GA20578@ocelot.phlegethon.org>
References: <f2efbfaa8d26e3b527b2.1328767297@xdev.gridcentric.ca>
	<20120209074242.GC71900@ocelot.phlegethon.org>
	<61936533ef44253d5e1b7036711d1324.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61936533ef44253d5e1b7036711d1324.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make asserts on types and counts of
	shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:50 -0800 on 09 Feb (1328770222), Andres Lagar-Cavilla wrote:
> > At 01:01 -0500 on 09 Feb (1328749297), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mem_sharing.c |  4 +++-
> >>  xen/arch/x86/mm/p2m.c         |  6 ++++--
> >>  2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > NACK, I'm afraid, especially the second one.  '<=' comparisons with a
> > number that's made up of a count ORed with a type don't make sense.
> > If you want to test both type and count, just test them separately.
> 
> The type I'm ORing with is a mask with single bit set, not a multi-bit
> type mask. And the type is defined as a higher order bit than the count
> mask.

It is right now, but if someone reshuffles the page_info struct again
you don't want it to banjax your super-cunning code.  Just test the
thing you need to test. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvew8-00021M-6b; Fri, 10 Feb 2012 01:06:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvew5-0001zx-GY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:06:01 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328835948!10904569!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12675 invoked from network); 10 Feb 2012 01:05:48 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:48 -0000
Received: by wgbdr13 with SMTP id dr13so2045263wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=eMypojxOKfnsiWth1rEFjj6+xpDbXS0H40P0SH5R+OE=;
	b=PYP7kJ1O7VeKM3OxULtY4LpRG0ePtaNiTCzVYNtQQVertYFPzYHDvo2mxzy62EMDoo
	8LiX2uEXYJpqGgE4cC4qyytQDQ8SQFk0CIoES/jVwA1Nr4B3MxaPSX7tiicEaQ9TNDww
	3kPKeut/2FphChu9SzDYe9mfIFt8U2UeSM5XE=
Received: by 10.216.136.76 with SMTP id v54mr9203457wei.30.1328835948186;
	Thu, 09 Feb 2012 17:05:48 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:47 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:42 +0000
Message-Id: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 1/3] hvmloader: Only compile
	32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

32bitbios_support.c only contains code specific to rombios, and should
not be built-in when building hvmloader for SeaBIOS only (as for
rombios.c).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 41a4369..e82146a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o
 OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
@@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += rombios.o
+OBJS += 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvew8-00021M-6b; Fri, 10 Feb 2012 01:06:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvew5-0001zx-GY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:06:01 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328835948!10904569!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12675 invoked from network); 10 Feb 2012 01:05:48 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:48 -0000
Received: by wgbdr13 with SMTP id dr13so2045263wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=eMypojxOKfnsiWth1rEFjj6+xpDbXS0H40P0SH5R+OE=;
	b=PYP7kJ1O7VeKM3OxULtY4LpRG0ePtaNiTCzVYNtQQVertYFPzYHDvo2mxzy62EMDoo
	8LiX2uEXYJpqGgE4cC4qyytQDQ8SQFk0CIoES/jVwA1Nr4B3MxaPSX7tiicEaQ9TNDww
	3kPKeut/2FphChu9SzDYe9mfIFt8U2UeSM5XE=
Received: by 10.216.136.76 with SMTP id v54mr9203457wei.30.1328835948186;
	Thu, 09 Feb 2012 17:05:48 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:47 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:42 +0000
Message-Id: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 1/3] hvmloader: Only compile
	32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

32bitbios_support.c only contains code specific to rombios, and should
not be built-in when building hvmloader for SeaBIOS only (as for
rombios.c).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 41a4369..e82146a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o
 OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
@@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += rombios.o
+OBJS += 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvew0-000202-SL; Fri, 10 Feb 2012 01:05:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvevz-0001zT-Df
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:05:55 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328835947!12771442!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17797 invoked from network); 10 Feb 2012 01:05:49 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:49 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so6635828wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=c/x2obeC5OQ7zDkFSq8NV8zHJYR7MXAHqdqRgS07+9Y=;
	b=qU9wNAVIXWpqkEMyI6SHWI/TCD+xu3zHyrSOQE+po+CvqnLavPSkO7tlrTFy/7hHOx
	OKDG9bweQtKEpp7HrCFoNmSfXRyPCbY7iodxtAtwv5E5HsZgRdRffs/BrhghGzaDQv4e
	2/oz0HCwZM0jEpjHljmYX9wcQtTdhu6kuIjf8=
Received: by 10.180.92.227 with SMTP id cp3mr6113401wib.13.1328835949073;
	Thu, 09 Feb 2012 17:05:49 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:48 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:43 +0000
Message-Id: <04bca2da081cc7cc2d1649c0d2d4d93af2bdccc2.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 2/3] firmware: Use mkhex from hvmloader
	directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

To remain consistent with how other ROMs are built into hvmloader,
call mkhex on etherboot ROMs from the hvmloader directory, instead of
the etherboot directory. In other words, eb-roms.h is not used any more.

Introduce ETHERBOOT_NICS config option to choose which ROMs should be
built (kept rtl8139 and 8086100e per default as before).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                         |    2 ++
 tools/firmware/etherboot/Config   |    2 --
 tools/firmware/etherboot/Makefile |   13 +++----------
 tools/firmware/hvmloader/Makefile |    9 ++++++---
 4 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/Config.mk b/Config.mk
index e2dc4b9..42508b8 100644
--- a/Config.mk
+++ b/Config.mk
@@ -222,6 +222,8 @@ endif
 QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
+ETHERBOOT_NICS ?= rtl8139 8086100e
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/etherboot/Config b/tools/firmware/etherboot/Config
index 143914f..69963b9 100644
--- a/tools/firmware/etherboot/Config
+++ b/tools/firmware/etherboot/Config
@@ -1,6 +1,4 @@
 
-NICS = rtl8139 8086100e
-
 CFLAGS += -UPXE_DHCP_STRICT
 CFLAGS += -DPXE_DHCP_STRICT
 
diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index c09140e..a195888 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -17,23 +17,16 @@ IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 D=ipxe
 T=ipxe.tar.gz
 
-ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(NICS)))
+ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
 
 .NOTPARALLEL:
 
 .PHONY: all
-all: eb-roms.h
+all: $(ROMS)
 
 %.rom: $D/src/arch/i386/Makefile
 	$(MAKE) -C $D/src bin/$(*F).rom
 
-eb-roms.h.new: $(ROMS)
-	cat $^ | ../hvmloader/mkhex etherboot >$@
-
-eb-roms.h: Config
-	$(MAKE) NO_WERROR=1 $@.new
-	mv -f $@.new $@
-
 $T:
 	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
 		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
@@ -56,7 +49,7 @@ $D/src/bin/NIC: $D/src/arch/i386/Makefile
 
 .PHONY: clean
 clean:
-	rm -rf $D $D.git *~ eb-roms.h _$T $T
+	rm -rf $D $D.git *~ _$T $T
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index e82146a..1ea32db 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -58,6 +58,8 @@ else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
 
+ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+
 .PHONY: all
 all: subdirs-all
 	$(MAKE) hvmloader
@@ -70,7 +72,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
+roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
@@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
 	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
 	echo "#endif" >> $@.new
 endif
-
+ifneq ($(ETHERBOOT_ROMS),)
 	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-	cat ../etherboot/eb-roms.h >> $@.new
+	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
 	echo "#endif" >> $@.new
+endif
 
 	mv $@.new $@
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvew0-000202-SL; Fri, 10 Feb 2012 01:05:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvevz-0001zT-Df
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:05:55 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328835947!12771442!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17797 invoked from network); 10 Feb 2012 01:05:49 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:49 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so6635828wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=c/x2obeC5OQ7zDkFSq8NV8zHJYR7MXAHqdqRgS07+9Y=;
	b=qU9wNAVIXWpqkEMyI6SHWI/TCD+xu3zHyrSOQE+po+CvqnLavPSkO7tlrTFy/7hHOx
	OKDG9bweQtKEpp7HrCFoNmSfXRyPCbY7iodxtAtwv5E5HsZgRdRffs/BrhghGzaDQv4e
	2/oz0HCwZM0jEpjHljmYX9wcQtTdhu6kuIjf8=
Received: by 10.180.92.227 with SMTP id cp3mr6113401wib.13.1328835949073;
	Thu, 09 Feb 2012 17:05:49 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:48 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:43 +0000
Message-Id: <04bca2da081cc7cc2d1649c0d2d4d93af2bdccc2.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 2/3] firmware: Use mkhex from hvmloader
	directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

To remain consistent with how other ROMs are built into hvmloader,
call mkhex on etherboot ROMs from the hvmloader directory, instead of
the etherboot directory. In other words, eb-roms.h is not used any more.

Introduce ETHERBOOT_NICS config option to choose which ROMs should be
built (kept rtl8139 and 8086100e per default as before).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                         |    2 ++
 tools/firmware/etherboot/Config   |    2 --
 tools/firmware/etherboot/Makefile |   13 +++----------
 tools/firmware/hvmloader/Makefile |    9 ++++++---
 4 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/Config.mk b/Config.mk
index e2dc4b9..42508b8 100644
--- a/Config.mk
+++ b/Config.mk
@@ -222,6 +222,8 @@ endif
 QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
+ETHERBOOT_NICS ?= rtl8139 8086100e
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/etherboot/Config b/tools/firmware/etherboot/Config
index 143914f..69963b9 100644
--- a/tools/firmware/etherboot/Config
+++ b/tools/firmware/etherboot/Config
@@ -1,6 +1,4 @@
 
-NICS = rtl8139 8086100e
-
 CFLAGS += -UPXE_DHCP_STRICT
 CFLAGS += -DPXE_DHCP_STRICT
 
diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index c09140e..a195888 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -17,23 +17,16 @@ IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 D=ipxe
 T=ipxe.tar.gz
 
-ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(NICS)))
+ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
 
 .NOTPARALLEL:
 
 .PHONY: all
-all: eb-roms.h
+all: $(ROMS)
 
 %.rom: $D/src/arch/i386/Makefile
 	$(MAKE) -C $D/src bin/$(*F).rom
 
-eb-roms.h.new: $(ROMS)
-	cat $^ | ../hvmloader/mkhex etherboot >$@
-
-eb-roms.h: Config
-	$(MAKE) NO_WERROR=1 $@.new
-	mv -f $@.new $@
-
 $T:
 	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
 		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
@@ -56,7 +49,7 @@ $D/src/bin/NIC: $D/src/arch/i386/Makefile
 
 .PHONY: clean
 clean:
-	rm -rf $D $D.git *~ eb-roms.h _$T $T
+	rm -rf $D $D.git *~ _$T $T
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index e82146a..1ea32db 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -58,6 +58,8 @@ else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
 
+ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+
 .PHONY: all
 all: subdirs-all
 	$(MAKE) hvmloader
@@ -70,7 +72,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
+roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
@@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
 	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
 	echo "#endif" >> $@.new
 endif
-
+ifneq ($(ETHERBOOT_ROMS),)
 	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-	cat ../etherboot/eb-roms.h >> $@.new
+	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
 	echo "#endif" >> $@.new
+endif
 
 	mv $@.new $@
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvevz-0001zp-Pu; Fri, 10 Feb 2012 01:05:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvevy-0001zO-Bx
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:05:54 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328835947!12771442!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17787 invoked from network); 10 Feb 2012 01:05:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:47 -0000
Received: by werb14 with SMTP id b14so6635828wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=6ycmTHYpv8TWj7jOIjN4PcOU34lJ6v6qkk7SK9koH9Q=;
	b=sGD73d+Dd/s+l0ryu1zCWKDJtmcS8qZ0GMaRVMJ6GVYXRzjYz1sPb/bVFiAbArsQDw
	9K9PkjvlfVoBIxAuXeL8ggGQb54C83BwLP2eimfsPT0V/qkwwWfup57kFTsSExcex+06
	z3v3LhMo8pVsX1B5tnu8O/Efe2KZJLSy+CDyU=
Received: by 10.216.135.167 with SMTP id u39mr9028739wei.51.1328835947303;
	Thu, 09 Feb 2012 17:05:47 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:46 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:41 +0000
Message-Id: <cover.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 0/3] hvmloader: Make ROM dependencies optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set mainly allows the user to build a seabios or rombios only
version of hvmloader.
In addition, when building a seabios only hvmloader, Option ROMs like
vgabios and etherboot are no longer required, and therefore can be disabled
from the build. Dependency on the bcc compiler can also be avoided the
same way.

v2: Separate patches for separate issues
    Introduced config option to select which NIC to build ROM for
    Fixed initial patch to build multiple etherboot ROMs in hvmloader
    Option ROMs are keyed off wether or not rombios is enabled, rather than
on an individual basis
    Introduced config options to select support for rombios/seabios
    

Julian Pidancet (3):
  hvmloader: Only compile 32bitbios_support.c when rombios is enabled
  firmware: Use mkhex from hvmloader directory for etherboot ROMs
  firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options

 Config.mk                            |    5 ++++
 tools/firmware/Makefile              |   21 +++++++++++-------
 tools/firmware/etherboot/Config      |    2 -
 tools/firmware/etherboot/Makefile    |   13 ++--------
 tools/firmware/hvmloader/Makefile    |   39 ++++++++++++++++++++-------------
 tools/firmware/hvmloader/hvmloader.c |    4 +++
 6 files changed, 49 insertions(+), 35 deletions(-)

-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvew2-00020J-HV; Fri, 10 Feb 2012 01:05:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvew0-0001zW-B2
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:05:56 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328835947!12771442!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17808 invoked from network); 10 Feb 2012 01:05:50 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:50 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so6635828wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=8zbAwgjg2zrHM5dHNRcNthySKxvqWPxDkeLMx7TMPuc=;
	b=SYZtDvSQMi7/ztBjAscdw2z5W1qe7c51fCz4kT6pDj7r+BDxRVE+mdKvqmPzfpOa3Y
	1zFxWUql7V/FhWMH61JOPcIcyRXJweVkYfcraCs7Hu1NGkVXEZQo/e79qKATn/1WgcuT
	YlJyGhLVjyKqGQ76mJXokEVi4dDOP4oiIqhKQ=
Received: by 10.180.90.212 with SMTP id by20mr6149342wib.12.1328835950036;
	Thu, 09 Feb 2012 17:05:50 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:49 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:44 +0000
Message-Id: <49af4f8a096e6d47f5221fc8ec22d8882b5a3faa.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 3/3] firmware: Introduce CONFIG_ROMBIOS and
	CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch introduces configuration options allowing to built either
a rombios only or a seabios only hvmloader.

Building option ROMs like vgabios or etherboot is only enabled for
a rombios hvmloader, since SeaBIOS takes care or extracting option
ROMs itself from the PCI devices (these option ROMs are provided
by the device model and do not need to be built in hvmloader).

The Makefile in tools/firmware/ now only checks for bcc if rombios
is enabled.

These two configuration options are left on by default to remain
compatible.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                            |    3 +++
 tools/firmware/Makefile              |   21 +++++++++++++--------
 tools/firmware/hvmloader/Makefile    |   32 +++++++++++++++++++-------------
 tools/firmware/hvmloader/hvmloader.c |    4 ++++
 4 files changed, 39 insertions(+), 21 deletions(-)

diff --git a/Config.mk b/Config.mk
index 42508b8..a43596c 100644
--- a/Config.mk
+++ b/Config.mk
@@ -224,6 +224,9 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_ROMBIOS ?= y
+CONFIG_SEABIOS ?= y
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index c3ec9a0..29d2041 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
 TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
-SUBDIRS :=
-SUBDIRS += seabios-dir
-SUBDIRS += rombios
-SUBDIRS += vgabios
-SUBDIRS += etherboot
-SUBDIRS += hvmloader
+SUBDIRS-y :=
+SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
+SUBDIRS-$(CONFIG_ROMBIOS) += rombios
+SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
+SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
+SUBDIRS-y += hvmloader
 
 seabios-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
 	cp seabios-config seabios-dir/.config;
 
 .PHONY: all
-all: seabios-dir
+all:
+ifeq ($(CONFIG_ROMBIOS),y)
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -25,7 +26,11 @@ all: seabios-dir
 	echo "==========================================================================="; \
 	false ; \
 	fi
-	$(MAKE) subdirs-$@; \
+endif
+ifeq ($(CONFIG_SEABIOS),y)
+	$(MAKE) seabios-dir
+endif
+	$(MAKE) subdirs-$@
 
 
 .PHONY: install
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 1ea32db..730bbba 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -38,27 +38,33 @@ endif
 CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
-ifneq ($(ROMBIOS_DIR),)
-OBJS += 32bitbios_support.o rombios.o
-CFLAGS += -DENABLE_ROMBIOS
-ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
-endif
-
 SEABIOS_DIR := ../seabios-dir
-ifneq ($(SEABIOS_DIR),)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-endif
 
+ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM    := ../vgabios/VGABIOS-lgpl-latest.bin
 ifeq ($(CIRRUSVGA_DEBUG),y)
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
-
 ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+endif
+
+ROMS := 
+
+ifeq ($(CONFIG_ROMBIOS),y)
+OBJS += 32bitbios_support.o rombios.o
+CFLAGS += -DENABLE_ROMBIOS
+ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
+ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+endif
+
+ifeq ($(CONFIG_SEABIOS),y)
+OBJS += seabios.o
+CFLAGS += -DENABLE_SEABIOS
+SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
+ROMS += $(SEABIOS_ROM)
+endif
 
 .PHONY: all
 all: subdirs-all
@@ -72,7 +78,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+roms.inc: $(ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f120ffe..874ee30 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -147,6 +147,7 @@ static void init_hypercalls(void)
     printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0xffff, extraversion);
 }
 
+#ifdef ENABLE_ROMBIOS
 /*
  * Scan the list of Option ROMs at @roms for one which supports 
  * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
@@ -309,6 +310,7 @@ static int pci_load_option_roms(unsigned int option_rom_end,
 
     return rom_phys_addr - rom_base_addr;
 }
+#endif
 
 /* Replace possibly erroneous memory-size CMOS fields with correct values. */
 static void cmos_write_memory_size(void)
@@ -470,6 +472,7 @@ int main(void)
             bios->create_pir_tables();
     }
 
+#ifdef ENABLE_ROMBIOS
     if ( bios->load_roms )
     {
         switch ( virtual_vga )
@@ -506,6 +509,7 @@ int main(void)
         option_rom_sz = pci_load_option_roms(bios->optionrom_end,
                                              option_rom_phys_addr);
     }
+#endif
 
     acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvevz-0001zp-Pu; Fri, 10 Feb 2012 01:05:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvevy-0001zO-Bx
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:05:54 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328835947!12771442!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17787 invoked from network); 10 Feb 2012 01:05:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:47 -0000
Received: by werb14 with SMTP id b14so6635828wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=6ycmTHYpv8TWj7jOIjN4PcOU34lJ6v6qkk7SK9koH9Q=;
	b=sGD73d+Dd/s+l0ryu1zCWKDJtmcS8qZ0GMaRVMJ6GVYXRzjYz1sPb/bVFiAbArsQDw
	9K9PkjvlfVoBIxAuXeL8ggGQb54C83BwLP2eimfsPT0V/qkwwWfup57kFTsSExcex+06
	z3v3LhMo8pVsX1B5tnu8O/Efe2KZJLSy+CDyU=
Received: by 10.216.135.167 with SMTP id u39mr9028739wei.51.1328835947303;
	Thu, 09 Feb 2012 17:05:47 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:46 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:41 +0000
Message-Id: <cover.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 0/3] hvmloader: Make ROM dependencies optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set mainly allows the user to build a seabios or rombios only
version of hvmloader.
In addition, when building a seabios only hvmloader, Option ROMs like
vgabios and etherboot are no longer required, and therefore can be disabled
from the build. Dependency on the bcc compiler can also be avoided the
same way.

v2: Separate patches for separate issues
    Introduced config option to select which NIC to build ROM for
    Fixed initial patch to build multiple etherboot ROMs in hvmloader
    Option ROMs are keyed off wether or not rombios is enabled, rather than
on an individual basis
    Introduced config options to select support for rombios/seabios
    

Julian Pidancet (3):
  hvmloader: Only compile 32bitbios_support.c when rombios is enabled
  firmware: Use mkhex from hvmloader directory for etherboot ROMs
  firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options

 Config.mk                            |    5 ++++
 tools/firmware/Makefile              |   21 +++++++++++-------
 tools/firmware/etherboot/Config      |    2 -
 tools/firmware/etherboot/Makefile    |   13 ++--------
 tools/firmware/hvmloader/Makefile    |   39 ++++++++++++++++++++-------------
 tools/firmware/hvmloader/hvmloader.c |    4 +++
 6 files changed, 49 insertions(+), 35 deletions(-)

-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:06:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1Rvew2-00020J-HV; Fri, 10 Feb 2012 01:05:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1Rvew0-0001zW-B2
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:05:56 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328835947!12771442!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17808 invoked from network); 10 Feb 2012 01:05:50 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:05:50 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so6635828wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 17:05:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=8zbAwgjg2zrHM5dHNRcNthySKxvqWPxDkeLMx7TMPuc=;
	b=SYZtDvSQMi7/ztBjAscdw2z5W1qe7c51fCz4kT6pDj7r+BDxRVE+mdKvqmPzfpOa3Y
	1zFxWUql7V/FhWMH61JOPcIcyRXJweVkYfcraCs7Hu1NGkVXEZQo/e79qKATn/1WgcuT
	YlJyGhLVjyKqGQ76mJXokEVi4dDOP4oiIqhKQ=
Received: by 10.180.90.212 with SMTP id by20mr6149342wib.12.1328835950036;
	Thu, 09 Feb 2012 17:05:50 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dw7sm10219399wib.4.2012.02.09.17.05.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 09 Feb 2012 17:05:49 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 01:53:44 +0000
Message-Id: <49af4f8a096e6d47f5221fc8ec22d8882b5a3faa.1328837585.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v2 3/3] firmware: Introduce CONFIG_ROMBIOS and
	CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch introduces configuration options allowing to built either
a rombios only or a seabios only hvmloader.

Building option ROMs like vgabios or etherboot is only enabled for
a rombios hvmloader, since SeaBIOS takes care or extracting option
ROMs itself from the PCI devices (these option ROMs are provided
by the device model and do not need to be built in hvmloader).

The Makefile in tools/firmware/ now only checks for bcc if rombios
is enabled.

These two configuration options are left on by default to remain
compatible.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                            |    3 +++
 tools/firmware/Makefile              |   21 +++++++++++++--------
 tools/firmware/hvmloader/Makefile    |   32 +++++++++++++++++++-------------
 tools/firmware/hvmloader/hvmloader.c |    4 ++++
 4 files changed, 39 insertions(+), 21 deletions(-)

diff --git a/Config.mk b/Config.mk
index 42508b8..a43596c 100644
--- a/Config.mk
+++ b/Config.mk
@@ -224,6 +224,9 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_ROMBIOS ?= y
+CONFIG_SEABIOS ?= y
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index c3ec9a0..29d2041 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
 TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
-SUBDIRS :=
-SUBDIRS += seabios-dir
-SUBDIRS += rombios
-SUBDIRS += vgabios
-SUBDIRS += etherboot
-SUBDIRS += hvmloader
+SUBDIRS-y :=
+SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
+SUBDIRS-$(CONFIG_ROMBIOS) += rombios
+SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
+SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
+SUBDIRS-y += hvmloader
 
 seabios-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
 	cp seabios-config seabios-dir/.config;
 
 .PHONY: all
-all: seabios-dir
+all:
+ifeq ($(CONFIG_ROMBIOS),y)
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -25,7 +26,11 @@ all: seabios-dir
 	echo "==========================================================================="; \
 	false ; \
 	fi
-	$(MAKE) subdirs-$@; \
+endif
+ifeq ($(CONFIG_SEABIOS),y)
+	$(MAKE) seabios-dir
+endif
+	$(MAKE) subdirs-$@
 
 
 .PHONY: install
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 1ea32db..730bbba 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -38,27 +38,33 @@ endif
 CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
-ifneq ($(ROMBIOS_DIR),)
-OBJS += 32bitbios_support.o rombios.o
-CFLAGS += -DENABLE_ROMBIOS
-ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
-endif
-
 SEABIOS_DIR := ../seabios-dir
-ifneq ($(SEABIOS_DIR),)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-endif
 
+ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM    := ../vgabios/VGABIOS-lgpl-latest.bin
 ifeq ($(CIRRUSVGA_DEBUG),y)
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
-
 ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+endif
+
+ROMS := 
+
+ifeq ($(CONFIG_ROMBIOS),y)
+OBJS += 32bitbios_support.o rombios.o
+CFLAGS += -DENABLE_ROMBIOS
+ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
+ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+endif
+
+ifeq ($(CONFIG_SEABIOS),y)
+OBJS += seabios.o
+CFLAGS += -DENABLE_SEABIOS
+SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
+ROMS += $(SEABIOS_ROM)
+endif
 
 .PHONY: all
 all: subdirs-all
@@ -72,7 +78,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+roms.inc: $(ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f120ffe..874ee30 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -147,6 +147,7 @@ static void init_hypercalls(void)
     printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0xffff, extraversion);
 }
 
+#ifdef ENABLE_ROMBIOS
 /*
  * Scan the list of Option ROMs at @roms for one which supports 
  * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
@@ -309,6 +310,7 @@ static int pci_load_option_roms(unsigned int option_rom_end,
 
     return rom_phys_addr - rom_base_addr;
 }
+#endif
 
 /* Replace possibly erroneous memory-size CMOS fields with correct values. */
 static void cmos_write_memory_size(void)
@@ -470,6 +472,7 @@ int main(void)
             bios->create_pir_tables();
     }
 
+#ifdef ENABLE_ROMBIOS
     if ( bios->load_roms )
     {
         switch ( virtual_vga )
@@ -506,6 +509,7 @@ int main(void)
         option_rom_sz = pci_load_option_roms(bios->optionrom_end,
                                              option_rom_phys_addr);
     }
+#endif
 
     acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:24:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1RvfDP-0002pU-He; Fri, 10 Feb 2012 01:23:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvfDN-0002pP-2Y
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:23:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328837024!12756030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12599 invoked from network); 10 Feb 2012 01:23:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,393,1325462400"; d="scan'208";a="10611500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 01:23:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 01:23:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvfDD-0007XF-Q3;
	Fri, 10 Feb 2012 01:23:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvfDD-000810-NJ;
	Fri, 10 Feb 2012 01:23:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11905-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 01:23:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11905 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:24:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1RvfDP-0002pU-He; Fri, 10 Feb 2012 01:23:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvfDN-0002pP-2Y
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:23:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328837024!12756030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12599 invoked from network); 10 Feb 2012 01:23:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 01:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,393,1325462400"; d="scan'208";a="10611500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 01:23:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 01:23:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvfDD-0007XF-Q3;
	Fri, 10 Feb 2012 01:23:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvfDD-000810-NJ;
	Fri, 10 Feb 2012 01:23:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11905-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 01:23:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11905 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:32:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1RvfLL-0003DK-Gi; Fri, 10 Feb 2012 01:32:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfLK-0003DE-Cw
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:32:06 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328837456!60496543!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14515 invoked from network); 10 Feb 2012 01:30:58 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 01:30:58 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A1VnEP000369; Thu, 9 Feb 2012 17:31:49 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A1Vndx000366;
	Thu, 9 Feb 2012 17:31:49 -0800
MIME-Version: 1.0
X-Mercurial-Node: 47366457a52076b78c5218c95b87c4ba7c9a723a
Message-Id: <47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
In-Reply-To: <1328817372.13189.93.camel@dagon.hellion.org.uk>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:31:48 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328835221 28800
# Node ID 47366457a52076b78c5218c95b87c4ba7c9a723a
# Parent  2fadbad1577ed4222dd2cf8931b79f514619eb0d
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -298,24 +298,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -325,7 +325,12 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+
+/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
+ *   If this parameter is true, use co-operative resume. The guest
+ *   must support this.
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2802,7 +2802,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 0);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2824,7 +2824,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 0);
     exit(-ERROR_FAIL);
 
  failed_badly:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:32:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01: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.xensource.com>)
	id 1RvfLL-0003DK-Gi; Fri, 10 Feb 2012 01:32:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfLK-0003DE-Cw
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:32:06 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328837456!60496543!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14515 invoked from network); 10 Feb 2012 01:30:58 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 01:30:58 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A1VnEP000369; Thu, 9 Feb 2012 17:31:49 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A1Vndx000366;
	Thu, 9 Feb 2012 17:31:49 -0800
MIME-Version: 1.0
X-Mercurial-Node: 47366457a52076b78c5218c95b87c4ba7c9a723a
Message-Id: <47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
In-Reply-To: <1328817372.13189.93.camel@dagon.hellion.org.uk>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:31:48 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328835221 28800
# Node ID 47366457a52076b78c5218c95b87c4ba7c9a723a
# Parent  2fadbad1577ed4222dd2cf8931b79f514619eb0d
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -298,24 +298,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -325,7 +325,12 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+
+/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
+ *   If this parameter is true, use co-operative resume. The guest
+ *   must support this.
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2802,7 +2802,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 0);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2824,7 +2824,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 0);
     exit(-ERROR_FAIL);
 
  failed_badly:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:46:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfZI-0003Oo-86; Fri, 10 Feb 2012 01:46:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfZF-0003Oj-82
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:46:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328838275!52133755!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22170 invoked from network); 10 Feb 2012 01:44:37 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 01:44:37 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A1jO3f000419; Thu, 9 Feb 2012 17:45:24 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A1jOuF000416;
	Thu, 9 Feb 2012 17:45:24 -0800
MIME-Version: 1.0
X-Mercurial-Node: ae36ea00a09cebdc5a0e08cb28d877dcfc077485
Message-Id: <ae36ea00a09cebdc5a0e.1328838324@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:45:24 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] remus: libcheckpoint - initialize unused
	callback fields to	NULL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328838305 28800
# Node ID ae36ea00a09cebdc5a0e08cb28d877dcfc077485
# Parent  7cbe8d029c59d5ff44bafe8065fef07b6cd0126b
remus: libcheckpoint - initialize unused callback fields to NULL

Add a memset to the save_callbacks struct instance in libcheckpoint's
initialization code. New additions to the callback struct will not
need to add an explicit initialization (to NULL), to maintain
compatibility with older xend/remus based invocation of xc_domain_save.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.c b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
@@ -155,6 +155,7 @@ static PyObject* pycheckpoint_start(PyOb
   } else
     self->checkpoint_cb = NULL;
 
+  memset(&callbacks, 0, sizeof(callbacks));
   callbacks.suspend = suspend_trampoline;
   callbacks.postcopy = postcopy_trampoline;
   callbacks.checkpoint = checkpoint_trampoline;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 01:46:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 01:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfZI-0003Oo-86; Fri, 10 Feb 2012 01:46:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfZF-0003Oj-82
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 01:46:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328838275!52133755!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22170 invoked from network); 10 Feb 2012 01:44:37 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 01:44:37 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A1jO3f000419; Thu, 9 Feb 2012 17:45:24 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A1jOuF000416;
	Thu, 9 Feb 2012 17:45:24 -0800
MIME-Version: 1.0
X-Mercurial-Node: ae36ea00a09cebdc5a0e08cb28d877dcfc077485
Message-Id: <ae36ea00a09cebdc5a0e.1328838324@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:45:24 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] remus: libcheckpoint - initialize unused
	callback fields to	NULL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328838305 28800
# Node ID ae36ea00a09cebdc5a0e08cb28d877dcfc077485
# Parent  7cbe8d029c59d5ff44bafe8065fef07b6cd0126b
remus: libcheckpoint - initialize unused callback fields to NULL

Add a memset to the save_callbacks struct instance in libcheckpoint's
initialization code. New additions to the callback struct will not
need to add an explicit initialization (to NULL), to maintain
compatibility with older xend/remus based invocation of xc_domain_save.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.c b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c
@@ -155,6 +155,7 @@ static PyObject* pycheckpoint_start(PyOb
   } else
     self->checkpoint_cb = NULL;
 
+  memset(&callbacks, 0, sizeof(callbacks));
   callbacks.suspend = suspend_trampoline;
   callbacks.postcopy = postcopy_trampoline;
   callbacks.checkpoint = checkpoint_trampoline;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfrI-00048f-6p; Fri, 10 Feb 2012 02:05:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfrG-00048Y-2b
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:05:06 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328839383!60799334!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20243 invoked from network); 10 Feb 2012 02:03:05 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 02:03:05 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A24rKV002808; Thu, 9 Feb 2012 18:04:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A24r9D002805;
	Thu, 9 Feb 2012 18:04:53 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:58:00 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyBwYXRjaCBzZXJpZXMgaW50cm9kdWNlcyBhIGJhc2ljIGZyYW1ld29yayB0byBpbmNvcnBv
cmF0ZQpSZW11cyBpbnRvIHRoZSBsaWJ4bCB0b29sc3RhY2suIFRoZSBvbmx5IGZ1bmN0aW9uYWxp
dHkgY3VycmVudGx5CmltcGxlbWVudGVkIGlzIG1lbW9yeSBjaGVja3BvaW50aW5nLgoKVGhlc2Ug
cGF0Y2hlcyBkZXBlbmQgb24gCiAxLiAiVjMgbGlieGw6IHJlZmFjdG9yIHN1c3BlbmQvcmVzdW1l
IGNvZGUiIHBhdGNoIHNlcmllcyAocGF0Y2hlcyAxLDIsMyw1LDYpCiAgICAgKG5vdGU6IHBhdGNo
ZXMgMSAmIDIgaGF2ZSBhbHJlYWR5IGJlZW4gY29tbWl0dGVkIGFuZCBvdGhlcnMgaGF2ZSBiZWVu
CiAgICAgIGFja2VkIGJ5IElhbiBDYW1wYmVsbCkKCiAyLiBWNCBvZiAibGlieGw6IHN1cHBvcnQg
c3VzcGVuZF9jYW5jZWwgaW4gZG9tYWluX3Jlc3VtZSIgCiAgIChtZXNzYWdlIGlkOiA0NzM2NjQ1
N2E1MjA3NmI3OGM1Mi4xMzI4ODM3NTA4QGF0aG9zLm5zcy5jcy51YmMuY2EpCgogMy4gU3RlZmFu
bydzICJWNCBsaWJ4bDogc2F2ZS9yZXN0b+KAi3JlIHFlbXUgcGh5c21hcCIKCkNoYW5nZXMgaW4g
VjQ6CiAqIG1vcmUgZXhwbGFuYXRpb24gb24gYmxhY2tob2xlIHJlcGxpY2F0aW9uIGluIHhsLnBv
ZAogKiBtb3ZlZCBjb21tZW50IG9uIHNhdmVfY2FsbGJhY2tzIHRvIHhlbmd1ZXN0LmgKICogcmVi
YXNlZCB0byBjdXJyZW50IHRpcCwgcmVtb3ZlZCB1c2VsZXNzIGNvbW1lbnRzLgoKQ2hhbmdlcyBp
biBWMzoKICogUmViYXNlZCB3LnIudCBTdGVmYW5vJ3MgcGF0Y2hlcy4KCkNoYW5nZXMgaW4gVjI6
CiAqIE1vdmUgbGlieGxfZG9tYWluX3JlbXVzX3N0YXJ0IGludG8gdGhlIHNhdmVfY2FsbGJhY2tz
IGltcGxlbWVudGF0aW9uIHBhdGNoCiAqIHJldHVybiBwcm9wZXIgZXJyb3IgY29kZXMgaW5zdGVh
ZCBvZiAtMS4KICogQWRkIGRvY3VtZW50YXRpb24gdG8gZG9jcy9tYW4veGwucG9kLjEKCnNocmly
YW0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfrI-00048f-6p; Fri, 10 Feb 2012 02:05:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfrG-00048Y-2b
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:05:06 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328839383!60799334!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20243 invoked from network); 10 Feb 2012 02:03:05 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 02:03:05 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A24rKV002808; Thu, 9 Feb 2012 18:04:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A24r9D002805;
	Thu, 9 Feb 2012 18:04:53 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:58:00 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyBwYXRjaCBzZXJpZXMgaW50cm9kdWNlcyBhIGJhc2ljIGZyYW1ld29yayB0byBpbmNvcnBv
cmF0ZQpSZW11cyBpbnRvIHRoZSBsaWJ4bCB0b29sc3RhY2suIFRoZSBvbmx5IGZ1bmN0aW9uYWxp
dHkgY3VycmVudGx5CmltcGxlbWVudGVkIGlzIG1lbW9yeSBjaGVja3BvaW50aW5nLgoKVGhlc2Ug
cGF0Y2hlcyBkZXBlbmQgb24gCiAxLiAiVjMgbGlieGw6IHJlZmFjdG9yIHN1c3BlbmQvcmVzdW1l
IGNvZGUiIHBhdGNoIHNlcmllcyAocGF0Y2hlcyAxLDIsMyw1LDYpCiAgICAgKG5vdGU6IHBhdGNo
ZXMgMSAmIDIgaGF2ZSBhbHJlYWR5IGJlZW4gY29tbWl0dGVkIGFuZCBvdGhlcnMgaGF2ZSBiZWVu
CiAgICAgIGFja2VkIGJ5IElhbiBDYW1wYmVsbCkKCiAyLiBWNCBvZiAibGlieGw6IHN1cHBvcnQg
c3VzcGVuZF9jYW5jZWwgaW4gZG9tYWluX3Jlc3VtZSIgCiAgIChtZXNzYWdlIGlkOiA0NzM2NjQ1
N2E1MjA3NmI3OGM1Mi4xMzI4ODM3NTA4QGF0aG9zLm5zcy5jcy51YmMuY2EpCgogMy4gU3RlZmFu
bydzICJWNCBsaWJ4bDogc2F2ZS9yZXN0b+KAi3JlIHFlbXUgcGh5c21hcCIKCkNoYW5nZXMgaW4g
VjQ6CiAqIG1vcmUgZXhwbGFuYXRpb24gb24gYmxhY2tob2xlIHJlcGxpY2F0aW9uIGluIHhsLnBv
ZAogKiBtb3ZlZCBjb21tZW50IG9uIHNhdmVfY2FsbGJhY2tzIHRvIHhlbmd1ZXN0LmgKICogcmVi
YXNlZCB0byBjdXJyZW50IHRpcCwgcmVtb3ZlZCB1c2VsZXNzIGNvbW1lbnRzLgoKQ2hhbmdlcyBp
biBWMzoKICogUmViYXNlZCB3LnIudCBTdGVmYW5vJ3MgcGF0Y2hlcy4KCkNoYW5nZXMgaW4gVjI6
CiAqIE1vdmUgbGlieGxfZG9tYWluX3JlbXVzX3N0YXJ0IGludG8gdGhlIHNhdmVfY2FsbGJhY2tz
IGltcGxlbWVudGF0aW9uIHBhdGNoCiAqIHJldHVybiBwcm9wZXIgZXJyb3IgY29kZXMgaW5zdGVh
ZCBvZiAtMS4KICogQWRkIGRvY3VtZW50YXRpb24gdG8gZG9jcy9tYW4veGwucG9kLjEKCnNocmly
YW0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfrK-00048q-Nr; Fri, 10 Feb 2012 02:05:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfrJ-00048Z-EK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:05:09 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328839480!52310856!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21084 invoked from network); 10 Feb 2012 02:04:41 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 02:04:41 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A24san002822; Thu, 9 Feb 2012 18:04:54 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A24si3002819;
	Thu, 9 Feb 2012 18:04:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7cbe8d029c59d5ff44bafe8065fef07b6cd0126b
Message-Id: <7cbe8d029c59d5ff44ba.1328839082@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:58:02 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V4] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328836781 28800
# Node ID 7cbe8d029c59d5ff44bafe8065fef07b6cd0126b
# Parent  2cde33aba59badb3f2faa2d77fe5b18441c7f221
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2cde33aba59b -r 7cbe8d029c59 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Feb 09 17:13:15 2012 -0800
+++ b/docs/man/xl.pod.1	Thu Feb 09 17:19:41 2012 -0800
@@ -350,6 +350,41 @@ Send <config> instead of config file fro
 
 =back
 
+=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
+
+Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
+between the two hosts.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-i> I<MS>
+
+Checkpoint domain memory every MS milliseconds (default 200ms).
+
+=item B<-b>
+
+Do not checkpoint the disk. Replicate memory checkpoints to /dev/null (blackhole).
+Network output buffering remains enabled (unless --no-net is supplied).
+Generally useful for debugging.
+
+=item B<-u>
+
+Disable memory checkpoint compression.
+
+=item B<-s> I<sshcommand>
+
+Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
+<host> instead of ssh <host> xl migrate-receive -r [-e].
+
+=item B<-e>
+
+On the new host, do not wait in the background (on <host>) for the death of the
+domain. See the corresponding option of the I<create> subcommand.
+
+=back
+
 =item B<pause> I<domain-id>
 
 Pause a domain.  When in a paused state the domain will still consume
diff -r 2cde33aba59b -r 7cbe8d029c59 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Feb 09 17:13:15 2012 -0800
+++ b/tools/libxl/xl.h	Thu Feb 09 17:19:41 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 2cde33aba59b -r 7cbe8d029c59 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 09 17:13:15 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 09 17:19:41 2012 -0800
@@ -2879,7 +2879,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 send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2914,6 +2914,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -3040,10 +3075,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3057,6 +3092,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3065,7 +3103,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    STDOUT_FILENO, STDIN_FILENO);
+                    STDOUT_FILENO, STDIN_FILENO,
+                    remus);
 
     return 0;
 }
@@ -5999,6 +6038,102 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+    uint8_t *config_data;
+    int config_len;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    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");
+            exit(-1);
+        }
+    } else {
+
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        child = create_migration_child(rune, &send_fd, &recv_fd);
+
+        migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                            rune);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 2cde33aba59b -r 7cbe8d029c59 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Feb 09 17:13:15 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Thu Feb 09 17:19:41 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r [-e]\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfrK-00048q-Nr; Fri, 10 Feb 2012 02:05:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfrJ-00048Z-EK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:05:09 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328839480!52310856!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21084 invoked from network); 10 Feb 2012 02:04:41 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 02:04:41 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A24san002822; Thu, 9 Feb 2012 18:04:54 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A24si3002819;
	Thu, 9 Feb 2012 18:04:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7cbe8d029c59d5ff44bafe8065fef07b6cd0126b
Message-Id: <7cbe8d029c59d5ff44ba.1328839082@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:58:02 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2 V4] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328836781 28800
# Node ID 7cbe8d029c59d5ff44bafe8065fef07b6cd0126b
# Parent  2cde33aba59badb3f2faa2d77fe5b18441c7f221
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2cde33aba59b -r 7cbe8d029c59 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Feb 09 17:13:15 2012 -0800
+++ b/docs/man/xl.pod.1	Thu Feb 09 17:19:41 2012 -0800
@@ -350,6 +350,41 @@ Send <config> instead of config file fro
 
 =back
 
+=item B<remus> [I<OPTIONS>] I<domain-id> I<host>
+
+Enable Remus HA for domain. By default B<xl> relies on ssh as a transport mechanism
+between the two hosts.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-i> I<MS>
+
+Checkpoint domain memory every MS milliseconds (default 200ms).
+
+=item B<-b>
+
+Do not checkpoint the disk. Replicate memory checkpoints to /dev/null (blackhole).
+Network output buffering remains enabled (unless --no-net is supplied).
+Generally useful for debugging.
+
+=item B<-u>
+
+Disable memory checkpoint compression.
+
+=item B<-s> I<sshcommand>
+
+Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
+<host> instead of ssh <host> xl migrate-receive -r [-e].
+
+=item B<-e>
+
+On the new host, do not wait in the background (on <host>) for the death of the
+domain. See the corresponding option of the I<create> subcommand.
+
+=back
+
 =item B<pause> I<domain-id>
 
 Pause a domain.  When in a paused state the domain will still consume
diff -r 2cde33aba59b -r 7cbe8d029c59 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Feb 09 17:13:15 2012 -0800
+++ b/tools/libxl/xl.h	Thu Feb 09 17:19:41 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 2cde33aba59b -r 7cbe8d029c59 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 09 17:13:15 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 09 17:19:41 2012 -0800
@@ -2879,7 +2879,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 send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2914,6 +2914,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -3040,10 +3075,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3057,6 +3092,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3065,7 +3103,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    STDOUT_FILENO, STDIN_FILENO);
+                    STDOUT_FILENO, STDIN_FILENO,
+                    remus);
 
     return 0;
 }
@@ -5999,6 +6038,102 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+    uint8_t *config_data;
+    int config_len;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    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");
+            exit(-1);
+        }
+    } else {
+
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        child = create_migration_child(rune, &send_fd, &recv_fd);
+
+        migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                            rune);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd, recv_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 2cde33aba59b -r 7cbe8d029c59 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Feb 09 17:13:15 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Thu Feb 09 17:19:41 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r [-e]\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:05:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02: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.xensource.com>)
	id 1RvfrO-00049L-68; Fri, 10 Feb 2012 02:05:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfrM-00048e-B3
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:05:12 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328839503!13691603!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28544 invoked from network); 10 Feb 2012 02:05:05 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 02:05:05 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A24ssZ002815; Thu, 9 Feb 2012 18:04:54 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A24s3a002812;
	Thu, 9 Feb 2012 18:04:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2cde33aba59badb3f2faa2d77fe5b18441c7f221
Message-Id: <2cde33aba59badb3f2fa.1328839081@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:58:01 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V4] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328836395 28800
# Node ID 2cde33aba59badb3f2faa2d77fe5b18441c7f221
# Parent  c94dbffb74b2e4b5ca8f9ad7ed13b3a3329b639c
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.
 * Introduce a new public API, libxl_domain_remus_start (currently a stub)
   that sets up the network and disk buffer and initiates continuous
   checkpointing.

 * Future patches will augment these callbacks/functions with more functionalities
   like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxc/xenguest.h	Thu Feb 09 17:13:15 2012 -0800
@@ -33,10 +33,29 @@
 
 /* callbacks provided by xc_domain_save */
 struct save_callbacks {
+    /* Called after expiration of checkpoint interval,
+     * to suspend the guest.
+     */
     int (*suspend)(void* data);
-    /* callback to rendezvous with external checkpoint functions */
+
+    /* Called after the guest's dirty pages have been
+     *  copied into an output buffer.
+     * Callback function resumes the guest & the device model,
+     *  returns to xc_domain_save.
+     * xc_domain_save then flushes the output buffer, while the
+     *  guest continues to run.
+     */
     int (*postcopy)(void* data);
-    /* returns:
+
+    /* Called after the memory checkpoint has been flushed
+     * out into the network. Typical actions performed in this
+     * callback include:
+     *   (a) send the saved device model state (for HVM guests),
+     *   (b) wait for checkpoint ack
+     *   (c) release the network output buffer pertaining to the acked checkpoint.
+     *   (c) sleep for the checkpoint interval.
+     *
+     * returns:
      * 0: terminate checkpointing gracefully
      * 1: take another checkpoint */
     int (*checkpoint)(void* data);
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 09 17:13:15 2012 -0800
@@ -540,6 +540,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = ERROR_INVAL;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
@@ -549,7 +584,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl.h	Thu Feb 09 17:13:15 2012 -0800
@@ -323,6 +323,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 09 17:13:15 2012 -0800
@@ -473,6 +473,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -737,9 +739,43 @@ static int libxl__toolstack_save(uint32_
     return 0;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -770,10 +806,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -797,7 +843,13 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 09 17:13:15 2012 -0800
@@ -629,7 +629,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Thu Feb 09 17:13:15 2012 -0800
@@ -406,6 +406,12 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("weight", integer),
     ], dispose_fn=None)
 
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])
+
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:05:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02: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.xensource.com>)
	id 1RvfrO-00049L-68; Fri, 10 Feb 2012 02:05:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvfrM-00048e-B3
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:05:12 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328839503!13691603!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28544 invoked from network); 10 Feb 2012 02:05:05 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 02:05:05 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1A24ssZ002815; Thu, 9 Feb 2012 18:04:54 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1A24s3a002812;
	Thu, 9 Feb 2012 18:04:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2cde33aba59badb3f2faa2d77fe5b18441c7f221
Message-Id: <2cde33aba59badb3f2fa.1328839081@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 09 Feb 2012 17:58:01 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, stefano.stabellini@eu.citrix.com,
	ian.campbell@citrix.com, ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2 V4] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1328836395 28800
# Node ID 2cde33aba59badb3f2faa2d77fe5b18441c7f221
# Parent  c94dbffb74b2e4b5ca8f9ad7ed13b3a3329b639c
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.
 * Introduce a new public API, libxl_domain_remus_start (currently a stub)
   that sets up the network and disk buffer and initiates continuous
   checkpointing.

 * Future patches will augment these callbacks/functions with more functionalities
   like issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxc/xenguest.h	Thu Feb 09 17:13:15 2012 -0800
@@ -33,10 +33,29 @@
 
 /* callbacks provided by xc_domain_save */
 struct save_callbacks {
+    /* Called after expiration of checkpoint interval,
+     * to suspend the guest.
+     */
     int (*suspend)(void* data);
-    /* callback to rendezvous with external checkpoint functions */
+
+    /* Called after the guest's dirty pages have been
+     *  copied into an output buffer.
+     * Callback function resumes the guest & the device model,
+     *  returns to xc_domain_save.
+     * xc_domain_save then flushes the output buffer, while the
+     *  guest continues to run.
+     */
     int (*postcopy)(void* data);
-    /* returns:
+
+    /* Called after the memory checkpoint has been flushed
+     * out into the network. Typical actions performed in this
+     * callback include:
+     *   (a) send the saved device model state (for HVM guests),
+     *   (b) wait for checkpoint ack
+     *   (c) release the network output buffer pertaining to the acked checkpoint.
+     *   (c) sleep for the checkpoint interval.
+     *
+     * returns:
      * 0: terminate checkpointing gracefully
      * 1: take another checkpoint */
     int (*checkpoint)(void* data);
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl.c	Thu Feb 09 17:13:15 2012 -0800
@@ -540,6 +540,41 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = ERROR_INVAL;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, send_fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
@@ -549,7 +584,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl.h	Thu Feb 09 17:13:15 2012 -0800
@@ -323,6 +323,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int send_fd, int recv_fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Thu Feb 09 17:13:15 2012 -0800
@@ -473,6 +473,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -737,9 +739,43 @@ static int libxl__toolstack_save(uint32_
     return 0;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -770,10 +806,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -797,7 +843,13 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Thu Feb 09 17:13:15 2012 -0800
@@ -629,7 +629,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r c94dbffb74b2 -r 2cde33aba59b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 09 16:54:37 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Thu Feb 09 17:13:15 2012 -0800
@@ -406,6 +406,12 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("weight", integer),
     ], dispose_fn=None)
 
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])
+
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DEATH"),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:08:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfuB-0004Sr-Ir; Fri, 10 Feb 2012 02:08:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1Rvfu9-0004Sa-Uf
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:08:06 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328839678!8600427!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19997 invoked from network); 10 Feb 2012 02:07:59 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 02:07:59 -0000
Received: by obcuy19 with SMTP id uy19so9416637obc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 18:07:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=Afukh7ByRCcGxDsg4MJ+29Hd2l4bMqct+Jow5il4Atw=;
	b=JQptd9grTqJi/Kyj4k5uF6cTeTzT5GJ0kQDGm9CQAlJA7zCJrQZqqMf8V0cVYKjNa4
	b3lHYpqlxTACSMsulYxBbbLxMlUvd08XhDf47EqFtBJCZC4jltA/ln39nv6TOP7Bpab+
	jofdWksr6bmft0HAttXynPyGt4uXIiUH2dIpU=
Received: by 10.50.10.225 with SMTP id l1mr7539209igb.9.1328839678250; Thu, 09
	Feb 2012 18:07:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.6.18 with HTTP; Thu, 9 Feb 2012 18:07:38 -0800 (PST)
In-Reply-To: <4F3424C0.2050103@citrix.com>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
	<20120117161208.GA21545@phenom.dumpdata.com>
	<CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
	<20120209174210.GA14007@andromeda.dapyr.net>
	<4F3424C0.2050103@citrix.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Thu, 9 Feb 2012 21:07:38 -0500
X-Google-Sender-Auth: YQIJiB-invrHup_xzMt2E_lk29Y
Message-ID: <CAMrPLW++8_18_U0Wnmw5X2E1w6Yh-bB1mb9fLv2n-_MiN7RhSA@mail.gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 2:55 PM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 09/02/12 17:42, Konrad Rzeszutek Wilk wrote:
>> On Sat, Jan 28, 2012 at 01:19:23PM -0500, Todd Deshane wrote:
>>> On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote:
>>>> On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
>>>>> Hi,
>>>>>
>>>>> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
>>>>> static on the Dom0 system. (I can PCI passthrough the audio card to a
>>>>> DomU and that works). Native sound works fine.
>>>>>
>>>>> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
>>>>> UTC 2012 i686 i686 i386 GNU/Linux
>>>>
>>>> Did you try 64-bit dom0?
>>>
>>> 64bit Dom0 works perfectly.
>>
>> Aha! I have an inkling this is the
>> 7a7546b377bdaa25ac77f33d9433c59f259b9688
>
> This is "x86: xen: size struct xen_spinlock to always fit in
> arch_spinlock_t" from the 3.2 stable tree.
>
> There are many spinlock in sound/ affected by the bug fixed by the above
> dunno if any would cause sound distortion but there were plenty of
> deadlock opportunities though.

Tried the latest Ubuntu kernel that includes that patch
(http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.2.0-15.24.diff.gz)
and it still has the same problem.

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 02:08:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 02:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvfuB-0004Sr-Ir; Fri, 10 Feb 2012 02:08:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1Rvfu9-0004Sa-Uf
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 02:08:06 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1328839678!8600427!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19997 invoked from network); 10 Feb 2012 02:07:59 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 02:07:59 -0000
Received: by obcuy19 with SMTP id uy19so9416637obc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 09 Feb 2012 18:07:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=Afukh7ByRCcGxDsg4MJ+29Hd2l4bMqct+Jow5il4Atw=;
	b=JQptd9grTqJi/Kyj4k5uF6cTeTzT5GJ0kQDGm9CQAlJA7zCJrQZqqMf8V0cVYKjNa4
	b3lHYpqlxTACSMsulYxBbbLxMlUvd08XhDf47EqFtBJCZC4jltA/ln39nv6TOP7Bpab+
	jofdWksr6bmft0HAttXynPyGt4uXIiUH2dIpU=
Received: by 10.50.10.225 with SMTP id l1mr7539209igb.9.1328839678250; Thu, 09
	Feb 2012 18:07:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.6.18 with HTTP; Thu, 9 Feb 2012 18:07:38 -0800 (PST)
In-Reply-To: <4F3424C0.2050103@citrix.com>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
	<20120117161208.GA21545@phenom.dumpdata.com>
	<CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
	<20120209174210.GA14007@andromeda.dapyr.net>
	<4F3424C0.2050103@citrix.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Thu, 9 Feb 2012 21:07:38 -0500
X-Google-Sender-Auth: YQIJiB-invrHup_xzMt2E_lk29Y
Message-ID: <CAMrPLW++8_18_U0Wnmw5X2E1w6Yh-bB1mb9fLv2n-_MiN7RhSA@mail.gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel mailing list <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 2:55 PM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 09/02/12 17:42, Konrad Rzeszutek Wilk wrote:
>> On Sat, Jan 28, 2012 at 01:19:23PM -0500, Todd Deshane wrote:
>>> On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote:
>>>> On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
>>>>> Hi,
>>>>>
>>>>> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
>>>>> static on the Dom0 system. (I can PCI passthrough the audio card to a
>>>>> DomU and that works). Native sound works fine.
>>>>>
>>>>> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
>>>>> UTC 2012 i686 i686 i386 GNU/Linux
>>>>
>>>> Did you try 64-bit dom0?
>>>
>>> 64bit Dom0 works perfectly.
>>
>> Aha! I have an inkling this is the
>> 7a7546b377bdaa25ac77f33d9433c59f259b9688
>
> This is "x86: xen: size struct xen_spinlock to always fit in
> arch_spinlock_t" from the 3.2 stable tree.
>
> There are many spinlock in sound/ affected by the bug fixed by the above
> dunno if any would cause sound distortion but there were plenty of
> deadlock opportunities though.

Tried the latest Ubuntu kernel that includes that patch
(http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.2.0-15.24.diff.gz)
and it still has the same problem.

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 06:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 06:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvjox-0000yy-7K; Fri, 10 Feb 2012 06:18:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rvjou-0000xN-QW
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 06:18:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328854730!10924661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10837 invoked from network); 10 Feb 2012 06:18:50 -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;
	10 Feb 2012 06:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="10613130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:18:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:18:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rvjon-0000un-70;
	Fri, 10 Feb 2012 06:18:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rvjon-00022B-5f;
	Fri, 10 Feb 2012 06:18:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11907-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 06:18:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11907: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11907 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11907/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 06:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 06:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvjox-0000yy-7K; Fri, 10 Feb 2012 06:18:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rvjou-0000xN-QW
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 06:18:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328854730!10924661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10837 invoked from network); 10 Feb 2012 06:18:50 -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;
	10 Feb 2012 06:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="10613130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:18:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:18:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rvjon-0000un-70;
	Fri, 10 Feb 2012 06:18:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rvjon-00022B-5f;
	Fri, 10 Feb 2012 06:18:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11907-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 06:18:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11907: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11907 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11907/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 07:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 07: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.xensource.com>)
	id 1RvkqO-0002Gk-3i; Fri, 10 Feb 2012 07:24:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvkqM-0002Gf-Cf
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 07:24:30 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328858530!52148527!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NDYxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14050 invoked from network); 10 Feb 2012 07:22:11 -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 Feb 2012 07:22:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q1A7OLua005886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 07:24:22 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
	q1A7OKCl025866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 07:24:20 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
	q1A7OJtB006423; Fri, 10 Feb 2012 01:24:20 -0600
Received: from [10.182.38.234] (/10.182.38.234)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 09 Feb 2012 23:24:19 -0800
Message-ID: <4F34C622.3060905@oracle.com>
Date: Fri, 10 Feb 2012 15:24:18 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Matthew Garrett <mjg59@srcf.ucam.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
	<20120209194723.GA8622@srcf.ucam.org>
In-Reply-To: <20120209194723.GA8622@srcf.ucam.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F34C626.0075,ss=1,re=0.000,fgs=0
Cc: linux-acpi@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,Matthew
the xen efi call need to use hypercall. that is different from the 
generic efi code. do you any idea about that. thanks!


On 2012-2-10 3:47, Matthew Garrett wrote:
> Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd
> really be nice to avoid yet another set of duplicate functions here -
> the ia64/x86 situation is already bad enough. Ideally this would be
> sufficiently generic that arm can also plug into it.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 07:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 07: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.xensource.com>)
	id 1RvkqO-0002Gk-3i; Fri, 10 Feb 2012 07:24:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1RvkqM-0002Gf-Cf
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 07:24:30 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328858530!52148527!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NDYxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14050 invoked from network); 10 Feb 2012 07:22:11 -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 Feb 2012 07:22:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q1A7OLua005886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 07:24:22 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
	q1A7OKCl025866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 07:24:20 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
	q1A7OJtB006423; Fri, 10 Feb 2012 01:24:20 -0600
Received: from [10.182.38.234] (/10.182.38.234)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 09 Feb 2012 23:24:19 -0800
Message-ID: <4F34C622.3060905@oracle.com>
Date: Fri, 10 Feb 2012 15:24:18 +0800
From: liang tang <liang.tang@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Matthew Garrett <mjg59@srcf.ucam.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
	<20120209194723.GA8622@srcf.ucam.org>
In-Reply-To: <20120209194723.GA8622@srcf.ucam.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F34C626.0075,ss=1,re=0.000,fgs=0
Cc: linux-acpi@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,Matthew
the xen efi call need to use hypercall. that is different from the 
generic efi code. do you any idea about that. thanks!


On 2012-2-10 3:47, Matthew Garrett wrote:
> Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd
> really be nice to avoid yet another set of duplicate functions here -
> the ia64/x86 situation is already bad enough. Ideally this would be
> sufficiently generic that arm can also plug into it.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 08:04:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 08:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvlSV-00033E-S4; Fri, 10 Feb 2012 08:03:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1RvlSU-000339-GW
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 08:03:54 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328860993!51858534!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15337 invoked from network); 10 Feb 2012 08:03:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	10 Feb 2012 08:03:14 -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 q1A83ktW022728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 03:03:46 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-23.ams2.redhat.com
	[10.36.112.23])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q1A83hEp029312; Fri, 10 Feb 2012 03:03:44 -0500
Message-ID: <4F34CF5E.9080106@redhat.com>
Date: Fri, 10 Feb 2012 09:03:42 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Paul Brook <paul@codesourcery.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<201202100026.40727.paul@codesourcery.com>
In-Reply-To: <201202100026.40727.paul@codesourcery.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 01:26 AM, Paul Brook wrote:
> The reason we have this is because there are bits of code that rely on
> polling.  IIRC slirp and the floppy DMA engine were the main culprits.
> qemu_calculate_timeout is an ugly hack to poll at least once a second,
> allowing the guest to make forward progress when we miss an event.

At least the floppy DMA engine is fine with it, it uses idle bottom 
halves (which are a hack and could be replaced by timers, but that's not 
relevant now).

Slirp's timeouts indeed require polling.

                 if (time_fasttimo && ((curtime - time_fasttimo) >= 2)) {
                         tcp_fasttimo(slirp);
                         time_fasttimo = 0;
                 }
                 if (do_slowtimo && ((curtime - last_slowtimo) >= 499)) {
                         ip_slowtimo(slirp);
                         tcp_slowtimo(slirp);
                         last_slowtimo = curtime;
                 }

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 08:04:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 08:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvlSV-00033E-S4; Fri, 10 Feb 2012 08:03:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1RvlSU-000339-GW
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 08:03:54 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328860993!51858534!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15337 invoked from network); 10 Feb 2012 08:03:14 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	10 Feb 2012 08:03:14 -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 q1A83ktW022728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 03:03:46 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-23.ams2.redhat.com
	[10.36.112.23])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q1A83hEp029312; Fri, 10 Feb 2012 03:03:44 -0500
Message-ID: <4F34CF5E.9080106@redhat.com>
Date: Fri, 10 Feb 2012 09:03:42 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Paul Brook <paul@codesourcery.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<201202100026.40727.paul@codesourcery.com>
In-Reply-To: <201202100026.40727.paul@codesourcery.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 01:26 AM, Paul Brook wrote:
> The reason we have this is because there are bits of code that rely on
> polling.  IIRC slirp and the floppy DMA engine were the main culprits.
> qemu_calculate_timeout is an ugly hack to poll at least once a second,
> allowing the guest to make forward progress when we miss an event.

At least the floppy DMA engine is fine with it, it uses idle bottom 
halves (which are a hack and could be replaced by timers, but that's not 
relevant now).

Slirp's timeouts indeed require polling.

                 if (time_fasttimo && ((curtime - time_fasttimo) >= 2)) {
                         tcp_fasttimo(slirp);
                         time_fasttimo = 0;
                 }
                 if (do_slowtimo && ((curtime - last_slowtimo) >= 499)) {
                         ip_slowtimo(slirp);
                         tcp_slowtimo(slirp);
                         last_slowtimo = curtime;
                 }

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 08:33:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 08:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvlu2-0003a5-HV; Fri, 10 Feb 2012 08:32:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rvlu1-0003a0-B7
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 08:32:21 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328862734!14288834!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3388 invoked from network); 10 Feb 2012 08:32:14 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 08:32:14 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75430970; Fri, 10 Feb 2012 09:32:13 +0100
Message-ID: <1328862707.2863.57.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 10 Feb 2012 09:31:47 +0100
In-Reply-To: <0aa2ccb5622461801936.1328790671@elijah>
References: <0aa2ccb5622461801936.1328790671@elijah>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] RFC: Automatically adjust dom0 weight
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0463247509246784766=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0463247509246784766==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-OHaDVJbhWlD5bENcFSmQ"


--=-OHaDVJbhWlD5bENcFSmQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-02-09 at 12:31 +0000, George Dunlap wrote:
> At the moment, the scheduler treats dom0 the same as any other VM
> for the purposes of accounting.  Since dom0 is really a critical
> piece of infrastructure, and a part of the hypervisor system as a
> whole, it would make more sense to try to give dom0 special rights
> wrt CPU time.
>=20
To me, this seems more a sensible configuration than a feature to be
embedded in the scheduler. I agree that dom0 always getting some CPU
time is critical in many ways, but I think the scheduler should provide
effective means for achieving such goal and then it is up to toolstack,
sysadmin, etc, to use them appropriately.

I obviously may be wrong, but I see this as a clear example of
implementing a policy, while we should just provide mechanisms. :-)

> This patch will cause the hypervisor to automatically adjust the
> weight of dom0 such that it should be able to get either enough
> cpu for each of its vcpus, or half of the cpus on the system,
> whichever is less.
>=20
That's the point. In fact, I think credit has the proper mechanisms to
affect the CPU time a domain receives, but not in such a way that the
above is achieved, and here's why this needs to be done by modifying he
scheduler (am I wrong?). It's sort of in replacement of a "minimum
guaranteed CPU bandwidth" for a domain mechanism, which maybe is too
complex/not worthwhile to put in place in a generalized fashion.

Just to clarify with an example, in sedf you wouldn't need anything like
this, as you specify exactly the _guaranteed_ CPU bandwidth[*] each vcpu
should be entitled with, i.e., sedf implements the correct mechanism for
enforcing a policy like that one, established by someone else up in the
stack... Then obviously sedf has a whole bunch of limitations, and we
all know it. :-P

Another way of looking at it could be, would user expect that? I mean
seeing dom0's weights dynamically changing? But here I really don't have
the proper backup for providing an answer... :-)

> I'm mostly posting to see what the interest in this kind of approach
> is.  If there is interest, I'll do the work to make it more configurable.
>=20
Yes, if we want this, I think it at least should be possible to turn it
on and off (although then the question becomes what the default should
be).

Summarizing, if something not equal, but maybe equally effective, could
be achieved without this (e.g.,
http://wiki.xen.org/wiki/Xen_Best_Practices), I'd be happy not having
it. However, if we think it could be useful and it is configurable
enough, I can live with it. :-)

Regards,
Dario

[*] For current implementation of sedf, that is true. If that scheduler
would ever properly support SMP, it will need some more tweaking to stay
true, or it will just become "a bit less true" :-D

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-OHaDVJbhWlD5bENcFSmQ
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.11 (GNU/Linux)

iEYEABECAAYFAk801fMACgkQk4XaBE3IOsRFtACgosD7PSLCyizOFn6YdxB8LCjb
AnEAn3mBVRmzwoG+LEPW1+Uz3Aoi2ReB
=9tW5
-----END PGP SIGNATURE-----

--=-OHaDVJbhWlD5bENcFSmQ--



--===============0463247509246784766==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0463247509246784766==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 08:33:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 08:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvlu2-0003a5-HV; Fri, 10 Feb 2012 08:32:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rvlu1-0003a0-B7
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 08:32:21 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328862734!14288834!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3388 invoked from network); 10 Feb 2012 08:32:14 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 08:32:14 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75430970; Fri, 10 Feb 2012 09:32:13 +0100
Message-ID: <1328862707.2863.57.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 10 Feb 2012 09:31:47 +0100
In-Reply-To: <0aa2ccb5622461801936.1328790671@elijah>
References: <0aa2ccb5622461801936.1328790671@elijah>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] RFC: Automatically adjust dom0 weight
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0463247509246784766=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0463247509246784766==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-OHaDVJbhWlD5bENcFSmQ"


--=-OHaDVJbhWlD5bENcFSmQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-02-09 at 12:31 +0000, George Dunlap wrote:
> At the moment, the scheduler treats dom0 the same as any other VM
> for the purposes of accounting.  Since dom0 is really a critical
> piece of infrastructure, and a part of the hypervisor system as a
> whole, it would make more sense to try to give dom0 special rights
> wrt CPU time.
>=20
To me, this seems more a sensible configuration than a feature to be
embedded in the scheduler. I agree that dom0 always getting some CPU
time is critical in many ways, but I think the scheduler should provide
effective means for achieving such goal and then it is up to toolstack,
sysadmin, etc, to use them appropriately.

I obviously may be wrong, but I see this as a clear example of
implementing a policy, while we should just provide mechanisms. :-)

> This patch will cause the hypervisor to automatically adjust the
> weight of dom0 such that it should be able to get either enough
> cpu for each of its vcpus, or half of the cpus on the system,
> whichever is less.
>=20
That's the point. In fact, I think credit has the proper mechanisms to
affect the CPU time a domain receives, but not in such a way that the
above is achieved, and here's why this needs to be done by modifying he
scheduler (am I wrong?). It's sort of in replacement of a "minimum
guaranteed CPU bandwidth" for a domain mechanism, which maybe is too
complex/not worthwhile to put in place in a generalized fashion.

Just to clarify with an example, in sedf you wouldn't need anything like
this, as you specify exactly the _guaranteed_ CPU bandwidth[*] each vcpu
should be entitled with, i.e., sedf implements the correct mechanism for
enforcing a policy like that one, established by someone else up in the
stack... Then obviously sedf has a whole bunch of limitations, and we
all know it. :-P

Another way of looking at it could be, would user expect that? I mean
seeing dom0's weights dynamically changing? But here I really don't have
the proper backup for providing an answer... :-)

> I'm mostly posting to see what the interest in this kind of approach
> is.  If there is interest, I'll do the work to make it more configurable.
>=20
Yes, if we want this, I think it at least should be possible to turn it
on and off (although then the question becomes what the default should
be).

Summarizing, if something not equal, but maybe equally effective, could
be achieved without this (e.g.,
http://wiki.xen.org/wiki/Xen_Best_Practices), I'd be happy not having
it. However, if we think it could be useful and it is configurable
enough, I can live with it. :-)

Regards,
Dario

[*] For current implementation of sedf, that is true. If that scheduler
would ever properly support SMP, it will need some more tweaking to stay
true, or it will just become "a bit less true" :-D

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-OHaDVJbhWlD5bENcFSmQ
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.11 (GNU/Linux)

iEYEABECAAYFAk801fMACgkQk4XaBE3IOsRFtACgosD7PSLCyizOFn6YdxB8LCjb
AnEAn3mBVRmzwoG+LEPW1+Uz3Aoi2ReB
=9tW5
-----END PGP SIGNATURE-----

--=-OHaDVJbhWlD5bENcFSmQ--



--===============0463247509246784766==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0463247509246784766==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 08:52:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 08: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.xensource.com>)
	id 1RvmDS-0003lm-Bl; Fri, 10 Feb 2012 08:52:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RvmDQ-0003lh-3x
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 08:52:24 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328863937!13724465!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11663 invoked from network); 10 Feb 2012 08:52:17 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 08:52:17 -0000
Received: by lagp5 with SMTP id p5so4311437lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 00:52:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=bqKEqmjFjwnKK29+wsEyWM9dRbsjE9BWIH2IB4IDZ4g=;
	b=bDAffRvutVntje4tPnE6VJHLAJSC1034MA7rUJumItfjKc2B5twYv6QKfTg+YjEmIz
	XXPAF77bPp2Xx8696xi9YwYaSPZh0mmOTVqzQvmKW/C7LdGK/FL/Q6K3UUF1ixT/z712
	hFsZMPhZ7Q3TIP0NYJMfBnQCnBcM3bYug8nhg=
Received: by 10.152.114.169 with SMTP id jh9mr3488023lab.20.1328863937085;
	Fri, 10 Feb 2012 00:52:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.5.129 with HTTP; Fri, 10 Feb 2012 00:52:02 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQvRhQD_dtAyBfRQ=SeRmuDnJc+vW1_VAr9SgK+dyb5sig@mail.gmail.com>
References: <4ED39164.5040203@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
	<4ED510C0.8000202@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF99@trantor>
	<CACaajQtWvkLt3d+H+CeQwK-WXxGo9MCUCBipLbvqnXka0yp3Vw@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B0550BB45@BITCOM1.int.sbss.com.au>
	<CACaajQvRhQD_dtAyBfRQ=SeRmuDnJc+vW1_VAr9SgK+dyb5sig@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 10 Feb 2012 12:52:02 +0400
X-Google-Sender-Auth: mU4fhpbfk3moY0pRC3hnYVR2Kek
Message-ID: <CACaajQv=rkHPSk=w1ibiw2QB9E57PH9coha6ukrW-JRguJqpvQ@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQmmCqFp46F6KpvKjaec46kQeRcxpf+m1nAfQCNvyJapnPyYvH9qLQr7ou96iazv41WpqpKV
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> 2012/1/31 James Harper <james.harper@bendigoit.com.au>:
>>>
>>> Sorry for bumping old thread, where i can find latest signed drivers that
>>> contains all fixes ?=) http://www.meadowcourt.org/downloads/
>>> says, that latest version uploaded in Sunday, 10 July 2011...
>>
>> http://www.meadowcourt.org/private/<filename>
>>
>> where <filename> is one of:
>>
>> gplpv_2000_0.11.0.357_debug.msi
>> gplpv_XP_0.11.0.357_debug.msi
>> gplpv_2003x32_0.11.0.357_debug.msi
>> gplpv_2003x64_0.11.0.357_debug.msi
>> gplpv_Vista2008x32_0.11.0.357_debug.msi
>> gplpv_Vista2008x64_0.11.0.357_debug.msi
>> gplpv_2000_0.11.0.357.msi
>> gplpv_XP_0.11.0.357.msi
>> gplpv_2003x32_0.11.0.357.msi
>> gplpv_2003x64_0.11.0.357.msi
>> gplpv_Vista2008x32_0.11.0.357.msi
>> gplpv_Vista2008x64_0.11.0.357.msi
>>
>> james
>>
>


I'm get simple tests and windows does not take BSOD and get good
network speed (download is about 70-80 Mb/s, upload ~40 Mb/s), but now
i get very poor disk performance =(
Now i dont have any tests results, but six mounth ago i have windows
2008 install is about 30 min, now i get 1 hour. I'm use self made
winpe image with integrated xen gpl pv drivers.


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 08:52:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 08: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.xensource.com>)
	id 1RvmDS-0003lm-Bl; Fri, 10 Feb 2012 08:52:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RvmDQ-0003lh-3x
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 08:52:24 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328863937!13724465!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11663 invoked from network); 10 Feb 2012 08:52:17 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 08:52:17 -0000
Received: by lagp5 with SMTP id p5so4311437lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 00:52:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=bqKEqmjFjwnKK29+wsEyWM9dRbsjE9BWIH2IB4IDZ4g=;
	b=bDAffRvutVntje4tPnE6VJHLAJSC1034MA7rUJumItfjKc2B5twYv6QKfTg+YjEmIz
	XXPAF77bPp2Xx8696xi9YwYaSPZh0mmOTVqzQvmKW/C7LdGK/FL/Q6K3UUF1ixT/z712
	hFsZMPhZ7Q3TIP0NYJMfBnQCnBcM3bYug8nhg=
Received: by 10.152.114.169 with SMTP id jh9mr3488023lab.20.1328863937085;
	Fri, 10 Feb 2012 00:52:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.5.129 with HTTP; Fri, 10 Feb 2012 00:52:02 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQvRhQD_dtAyBfRQ=SeRmuDnJc+vW1_VAr9SgK+dyb5sig@mail.gmail.com>
References: <4ED39164.5040203@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
	<4ED510C0.8000202@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF99@trantor>
	<CACaajQtWvkLt3d+H+CeQwK-WXxGo9MCUCBipLbvqnXka0yp3Vw@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B0550BB45@BITCOM1.int.sbss.com.au>
	<CACaajQvRhQD_dtAyBfRQ=SeRmuDnJc+vW1_VAr9SgK+dyb5sig@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 10 Feb 2012 12:52:02 +0400
X-Google-Sender-Auth: mU4fhpbfk3moY0pRC3hnYVR2Kek
Message-ID: <CACaajQv=rkHPSk=w1ibiw2QB9E57PH9coha6ukrW-JRguJqpvQ@mail.gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
X-Gm-Message-State: ALoCoQmmCqFp46F6KpvKjaec46kQeRcxpf+m1nAfQCNvyJapnPyYvH9qLQr7ou96iazv41WpqpKV
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> 2012/1/31 James Harper <james.harper@bendigoit.com.au>:
>>>
>>> Sorry for bumping old thread, where i can find latest signed drivers that
>>> contains all fixes ?=) http://www.meadowcourt.org/downloads/
>>> says, that latest version uploaded in Sunday, 10 July 2011...
>>
>> http://www.meadowcourt.org/private/<filename>
>>
>> where <filename> is one of:
>>
>> gplpv_2000_0.11.0.357_debug.msi
>> gplpv_XP_0.11.0.357_debug.msi
>> gplpv_2003x32_0.11.0.357_debug.msi
>> gplpv_2003x64_0.11.0.357_debug.msi
>> gplpv_Vista2008x32_0.11.0.357_debug.msi
>> gplpv_Vista2008x64_0.11.0.357_debug.msi
>> gplpv_2000_0.11.0.357.msi
>> gplpv_XP_0.11.0.357.msi
>> gplpv_2003x32_0.11.0.357.msi
>> gplpv_2003x64_0.11.0.357.msi
>> gplpv_Vista2008x32_0.11.0.357.msi
>> gplpv_Vista2008x64_0.11.0.357.msi
>>
>> james
>>
>


I'm get simple tests and windows does not take BSOD and get good
network speed (download is about 70-80 Mb/s, upload ~40 Mb/s), but now
i get very poor disk performance =(
Now i dont have any tests results, but six mounth ago i have windows
2008 install is about 30 min, now i get 1 hour. I'm use self made
winpe image with integrated xen gpl pv drivers.


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:01:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09: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.xensource.com>)
	id 1RvmLS-0004Ap-MO; Fri, 10 Feb 2012 09:00:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvmLR-0004Aj-5h
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:00:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328864434!12739925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9664 invoked from network); 10 Feb 2012 09:00:35 -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;
	10 Feb 2012 09:00:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10614984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:00:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:00:34 +0000
Message-ID: <1328864432.6133.241.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Fri, 10 Feb 2012 09:00:32 +0000
In-Reply-To: <47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:31 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328835221 28800
> # Node ID 47366457a52076b78c5218c95b87c4ba7c9a723a
> # Parent  2fadbad1577ed4222dd2cf8931b79f514619eb0d
> libxl: support suspend_cancel in domain_resume
> 
> Add an extra parameter to libxl_domain_resume indicating
> if the caller wishes to use the SUSPEND_CANCEL style
> resume instead of the normal resume.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Thanks
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(although doesn't the libxl__domain_resume_device_model need to be in
another patch to avoid bisection issues? i.e. in with the changes to the
suspend/resume ordering to balance things there?)

> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -298,24 +298,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>      return rc;
>  }
>  
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
>  {
>      GC_INIT(ctx);
>      int rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> -                "non-cooperative hvm domain %u", domid);
> -        rc = ERROR_NI;
> -        goto out;
> -    }
> -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> +    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xc_domain_resume failed for domain %u",
>                          domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        rc = libxl__domain_resume_device_model(gc, domid);
> +        if (rc) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "failed to resume device model for domain %u:%d",
> +                       domid, rc);
> +            goto out;
> +        }
> +    }
> +
>      if (!xs_resume_domain(ctx->xsh, domid)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xs_resume_domain failed for domain %u",
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -325,7 +325,12 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                            uint32_t domid, int fd);
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> +
> +/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> + *   If this parameter is true, use co-operative resume. The guest
> + *   must support this.
> + */
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2802,7 +2802,7 @@ static void migrate_domain(const char *d
>          if (common_domname) {
>              libxl_domain_rename(ctx, domid, away_domname, common_domname);
>          }
> -        rc = libxl_domain_resume(ctx, domid);
> +        rc = libxl_domain_resume(ctx, domid, 0);
>          if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
>  
>          fprintf(stderr, "Migration failed due to problems at target.\n");
> @@ -2824,7 +2824,7 @@ static void migrate_domain(const char *d
>      close(send_fd);
>      migration_child_report(child, recv_fd);
>      fprintf(stderr, "Migration failed, resuming at sender.\n");
> -    libxl_domain_resume(ctx, domid);
> +    libxl_domain_resume(ctx, domid, 0);
>      exit(-ERROR_FAIL);
>  
>   failed_badly:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:01:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09: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.xensource.com>)
	id 1RvmLS-0004Ap-MO; Fri, 10 Feb 2012 09:00:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvmLR-0004Aj-5h
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:00:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328864434!12739925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9664 invoked from network); 10 Feb 2012 09:00:35 -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;
	10 Feb 2012 09:00:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10614984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:00:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:00:34 +0000
Message-ID: <1328864432.6133.241.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Fri, 10 Feb 2012 09:00:32 +0000
In-Reply-To: <47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:31 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1328835221 28800
> # Node ID 47366457a52076b78c5218c95b87c4ba7c9a723a
> # Parent  2fadbad1577ed4222dd2cf8931b79f514619eb0d
> libxl: support suspend_cancel in domain_resume
> 
> Add an extra parameter to libxl_domain_resume indicating
> if the caller wishes to use the SUSPEND_CANCEL style
> resume instead of the normal resume.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Thanks
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(although doesn't the libxl__domain_resume_device_model need to be in
another patch to avoid bisection issues? i.e. in with the changes to the
suspend/resume ordering to balance things there?)

> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -298,24 +298,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>      return rc;
>  }
>  
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
>  {
>      GC_INIT(ctx);
>      int rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> -                "non-cooperative hvm domain %u", domid);
> -        rc = ERROR_NI;
> -        goto out;
> -    }
> -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> +    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xc_domain_resume failed for domain %u",
>                          domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        rc = libxl__domain_resume_device_model(gc, domid);
> +        if (rc) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "failed to resume device model for domain %u:%d",
> +                       domid, rc);
> +            goto out;
> +        }
> +    }
> +
>      if (!xs_resume_domain(ctx->xsh, domid)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xs_resume_domain failed for domain %u",
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -325,7 +325,12 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                            uint32_t domid, int fd);
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> +
> +/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> + *   If this parameter is true, use co-operative resume. The guest
> + *   must support this.
> + */
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2802,7 +2802,7 @@ static void migrate_domain(const char *d
>          if (common_domname) {
>              libxl_domain_rename(ctx, domid, away_domname, common_domname);
>          }
> -        rc = libxl_domain_resume(ctx, domid);
> +        rc = libxl_domain_resume(ctx, domid, 0);
>          if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
>  
>          fprintf(stderr, "Migration failed due to problems at target.\n");
> @@ -2824,7 +2824,7 @@ static void migrate_domain(const char *d
>      close(send_fd);
>      migration_child_report(child, recv_fd);
>      fprintf(stderr, "Migration failed, resuming at sender.\n");
> -    libxl_domain_resume(ctx, domid);
> +    libxl_domain_resume(ctx, domid, 0);
>      exit(-ERROR_FAIL);
>  
>   failed_badly:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:04:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvmO9-0004Io-Gr; Fri, 10 Feb 2012 09:03: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 1RvmO8-0004IX-6C
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328864469!52162776!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29336 invoked from network); 10 Feb 2012 09:01:09 -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;
	10 Feb 2012 09:01:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:03:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:03:21 +0000
Message-ID: <1328864600.6133.242.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Fri, 10 Feb 2012 09:03:20 +0000
In-Reply-To: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
	<e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328837585.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 1/3] hvmloader: Only compile
 32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:53 +0000, Julian Pidancet wrote:
> 32bitbios_support.c only contains code specific to rombios, and should
> not be built-in when building hvmloader for SeaBIOS only (as for
> rombios.c).
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/firmware/hvmloader/Makefile |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index 41a4369..e82146a 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -29,7 +29,7 @@ LOADADDR = 0x100000
>  CFLAGS += $(CFLAGS_xeninclude)
>  
>  OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
> -OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
> +OBJS += smp.o cacheattr.o xenbus.o
>  OBJS += e820.o pci.o pir.o ctype.o
>  ifeq ($(debug),y)
>  OBJS += tests.o
> @@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
>  
>  ROMBIOS_DIR := ../rombios
>  ifneq ($(ROMBIOS_DIR),)
> -OBJS += rombios.o
> +OBJS += 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:04:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09:04:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvmO9-0004Io-Gr; Fri, 10 Feb 2012 09:03: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 1RvmO8-0004IX-6C
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328864469!52162776!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29336 invoked from network); 10 Feb 2012 09:01:09 -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;
	10 Feb 2012 09:01:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:03:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:03:21 +0000
Message-ID: <1328864600.6133.242.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Fri, 10 Feb 2012 09:03:20 +0000
In-Reply-To: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
	<e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328837585.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 1/3] hvmloader: Only compile
 32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:53 +0000, Julian Pidancet wrote:
> 32bitbios_support.c only contains code specific to rombios, and should
> not be built-in when building hvmloader for SeaBIOS only (as for
> rombios.c).
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/firmware/hvmloader/Makefile |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index 41a4369..e82146a 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -29,7 +29,7 @@ LOADADDR = 0x100000
>  CFLAGS += $(CFLAGS_xeninclude)
>  
>  OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
> -OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
> +OBJS += smp.o cacheattr.o xenbus.o
>  OBJS += e820.o pci.o pir.o ctype.o
>  ifeq ($(debug),y)
>  OBJS += tests.o
> @@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
>  
>  ROMBIOS_DIR := ../rombios
>  ifneq ($(ROMBIOS_DIR),)
> -OBJS += rombios.o
> +OBJS += 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:08:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09: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.xensource.com>)
	id 1RvmSW-0004UW-7k; Fri, 10 Feb 2012 09:08:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvmSV-0004UE-66
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:07:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328864873!12592182!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22408 invoked from network); 10 Feb 2012 09:07:53 -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;
	10 Feb 2012 09:07:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:07:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:07:52 +0000
Message-ID: <1328864871.6133.245.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Fri, 10 Feb 2012 09:07:51 +0000
In-Reply-To: <04bca2da081cc7cc2d1649c0d2d4d93af2bdccc2.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
	<04bca2da081cc7cc2d1649c0d2d4d93af2bdccc2.1328837585.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 2/3] firmware: Use mkhex from hvmloader
 directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:53 +0000, Julian Pidancet wrote:
> @@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
>  	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
>  	echo "#endif" >> $@.new
>  endif
> -
> +ifneq ($(ETHERBOOT_ROMS),)
>  	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
> -	cat ../etherboot/eb-roms.h >> $@.new
> +	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new

mkhex uses $1 as the array name and $2 as the binary data. However if
ETHERBOOT_ROMS contains two or more items then the second and subsequent
roms will be $3,$4 etc which are then not included.

I think you need to either quote something somewhere, use shift and $@
in mkhex or stick with the "cat $(ETHERBOOT_ROMS) | ./mkhex ..." style.

The rest of the patch looked good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:08:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09: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.xensource.com>)
	id 1RvmSW-0004UW-7k; Fri, 10 Feb 2012 09:08:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvmSV-0004UE-66
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:07:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328864873!12592182!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22408 invoked from network); 10 Feb 2012 09:07:53 -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;
	10 Feb 2012 09:07:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:07:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:07:52 +0000
Message-ID: <1328864871.6133.245.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Fri, 10 Feb 2012 09:07:51 +0000
In-Reply-To: <04bca2da081cc7cc2d1649c0d2d4d93af2bdccc2.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
	<04bca2da081cc7cc2d1649c0d2d4d93af2bdccc2.1328837585.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 2/3] firmware: Use mkhex from hvmloader
 directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:53 +0000, Julian Pidancet wrote:
> @@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
>  	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
>  	echo "#endif" >> $@.new
>  endif
> -
> +ifneq ($(ETHERBOOT_ROMS),)
>  	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
> -	cat ../etherboot/eb-roms.h >> $@.new
> +	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new

mkhex uses $1 as the array name and $2 as the binary data. However if
ETHERBOOT_ROMS contains two or more items then the second and subsequent
roms will be $3,$4 etc which are then not included.

I think you need to either quote something somewhere, use shift and $@
in mkhex or stick with the "cat $(ETHERBOOT_ROMS) | ./mkhex ..." style.

The rest of the patch looked good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:17:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09: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.xensource.com>)
	id 1RvmbG-0004t8-AJ; Fri, 10 Feb 2012 09:17: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 1RvmbF-0004t2-15
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:17:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328865386!59277344!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24924 invoked from network); 10 Feb 2012 09:16: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;
	10 Feb 2012 09:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:16:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:16:56 +0000
Message-ID: <1328865415.6133.250.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Fri, 10 Feb 2012 09:16:55 +0000
In-Reply-To: <49af4f8a096e6d47f5221fc8ec22d8882b5a3faa.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
	<49af4f8a096e6d47f5221fc8ec22d8882b5a3faa.1328837585.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 3/3] firmware: Introduce CONFIG_ROMBIOS
 and CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:53 +0000, Julian Pidancet wrote:
> @@ -470,6 +472,7 @@ int main(void)
>              bios->create_pir_tables();
>      }
>  
> +#ifdef ENABLE_ROMBIOS
>      if ( bios->load_roms )

Can we make bios->load_roms a function pointer instead of a bool. It can
be NULL for SeaBIOS and contain this block on ROMBIOS? Then all this
code (and pci_load_option_roms) could be moved to rombios.c.

>      {
>          switch ( virtual_vga )
> @@ -506,6 +509,7 @@ int main(void)
>          option_rom_sz = pci_load_option_roms(bios->optionrom_end,
>                                               option_rom_phys_addr);
>      }
> +#endif
>  
>      acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:17:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09: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.xensource.com>)
	id 1RvmbG-0004t8-AJ; Fri, 10 Feb 2012 09:17: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 1RvmbF-0004t2-15
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:17:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328865386!59277344!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24924 invoked from network); 10 Feb 2012 09:16: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;
	10 Feb 2012 09:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:16:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:16:56 +0000
Message-ID: <1328865415.6133.250.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Fri, 10 Feb 2012 09:16:55 +0000
In-Reply-To: <49af4f8a096e6d47f5221fc8ec22d8882b5a3faa.1328837585.git.julian.pidancet@gmail.com>
References: <cover.1328837585.git.julian.pidancet@gmail.com>
	<49af4f8a096e6d47f5221fc8ec22d8882b5a3faa.1328837585.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 3/3] firmware: Introduce CONFIG_ROMBIOS
 and CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:53 +0000, Julian Pidancet wrote:
> @@ -470,6 +472,7 @@ int main(void)
>              bios->create_pir_tables();
>      }
>  
> +#ifdef ENABLE_ROMBIOS
>      if ( bios->load_roms )

Can we make bios->load_roms a function pointer instead of a bool. It can
be NULL for SeaBIOS and contain this block on ROMBIOS? Then all this
code (and pci_load_option_roms) could be moved to rombios.c.

>      {
>          switch ( virtual_vga )
> @@ -506,6 +509,7 @@ int main(void)
>          option_rom_sz = pci_load_option_roms(bios->optionrom_end,
>                                               option_rom_phys_addr);
>      }
> +#endif
>  
>      acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:31:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvmoy-00053f-P5; Fri, 10 Feb 2012 09:31:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvmow-00053X-M6
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:31:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328866264!12776868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 425 invoked from network); 10 Feb 2012 09:31:04 -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 Feb 2012 09:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:31:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:31:04 +0000
Message-ID: <1328866262.6133.257.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
Date: Fri, 10 Feb 2012 09:31:02 +0000
In-Reply-To: <osstest-11905-mainreport@xen.org>
References: <osstest-11905-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:23 +0000, xen.org wrote:
> flight 11905 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
>  test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
>  test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
>  test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/test-amd64-i386-win-vcpus1/gall-mite---var-log-xen-xend.log contains:
        [2012-02-09 22:34:26 2310] ERROR (XendDomainInfo:488) VM start failed
        Traceback (most recent call last):
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start
            XendTask.log_progress(31, 60, self._initDomain)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
            retval = func(*args, **kwds)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain
            self._introduceDomain()
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2685, in _introduceDomain
            raise XendError(str(exn))
        XendError: (22, 'Invalid argument')
        
This try block contains only a single call to
xen.xend.xenstore.xsutil.IntroduceDomain which ultimately turns into a C
call to xs_introduce_domain.

Daniel, I'm afraid I suspect the XS stubdom series for this one. My
suspicion is a missing call to seed_grant_table from xend (or from a
libxc function which xend uses) which prevents xenstored from mapping
the guest's ring, which results in an error from map_interface() in
xenstored.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 09:31:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 09:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvmoy-00053f-P5; Fri, 10 Feb 2012 09:31:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvmow-00053X-M6
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:31:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328866264!12776868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 425 invoked from network); 10 Feb 2012 09:31:04 -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 Feb 2012 09:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10615691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:31:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 09:31:04 +0000
Message-ID: <1328866262.6133.257.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Daniel De Graaf
	<dgdegra@tycho.nsa.gov>
Date: Fri, 10 Feb 2012 09:31:02 +0000
In-Reply-To: <osstest-11905-mainreport@xen.org>
References: <osstest-11905-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 01:23 +0000, xen.org wrote:
> flight 11905 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
>  test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
>  test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
>  test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/test-amd64-i386-win-vcpus1/gall-mite---var-log-xen-xend.log contains:
        [2012-02-09 22:34:26 2310] ERROR (XendDomainInfo:488) VM start failed
        Traceback (most recent call last):
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start
            XendTask.log_progress(31, 60, self._initDomain)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
            retval = func(*args, **kwds)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain
            self._introduceDomain()
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2685, in _introduceDomain
            raise XendError(str(exn))
        XendError: (22, 'Invalid argument')
        
This try block contains only a single call to
xen.xend.xenstore.xsutil.IntroduceDomain which ultimately turns into a C
call to xs_introduce_domain.

Daniel, I'm afraid I suspect the XS stubdom series for this one. My
suspicion is a missing call to seed_grant_table from xend (or from a
libxc function which xend uses) which prevents xenstored from mapping
the guest's ring, which results in an error from map_interface() in
xenstored.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:03:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:03:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvnJw-0005YF-Gk; Fri, 10 Feb 2012 10:03:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvnJv-0005Y5-2W
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 10:03:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328868184!12805218!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9063 invoked from network); 10 Feb 2012 10:03:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 10:03:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 10:03:03 +0000
Message-Id: <4F34F96602000078000722DA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 10:03:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
In-Reply-To: <20120209180257.GA13025@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 19:02, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 30, Jan Beulich wrote:
> 
>> Below/attached a draft patch (compile tested only), handling save/
>> restore of the bank count, but not allowing for a config setting to
>> specify its initial value (yet).
> 
> Does it take more than just applying this patch for src+dst host and
> migrate a hvm guest? I see no difference, the mce warning is still
> there.

No, it shouldn't require anything else. Could you add a printk() each
to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
(and at once checking that they actually get executed? I was under
the impression that adding save records for HVM is a simple drop-in
exercise these days...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:03:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:03:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvnJw-0005YF-Gk; Fri, 10 Feb 2012 10:03:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvnJv-0005Y5-2W
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 10:03:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328868184!12805218!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9063 invoked from network); 10 Feb 2012 10:03:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 10:03:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 10:03:03 +0000
Message-Id: <4F34F96602000078000722DA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 10:03:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
In-Reply-To: <20120209180257.GA13025@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 19:02, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 30, Jan Beulich wrote:
> 
>> Below/attached a draft patch (compile tested only), handling save/
>> restore of the bank count, but not allowing for a config setting to
>> specify its initial value (yet).
> 
> Does it take more than just applying this patch for src+dst host and
> migrate a hvm guest? I see no difference, the mce warning is still
> there.

No, it shouldn't require anything else. Could you add a printk() each
to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
(and at once checking that they actually get executed? I was under
the impression that adding save records for HVM is a simple drop-in
exercise these days...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfm-0005wz-06; Fri, 10 Feb 2012 10:25:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongsoo.kim@resl.kaist.ac.kr>)
	id 1Ruw8v-00061m-H9; Wed, 08 Feb 2012 01:16:17 +0000
X-Env-Sender: dongsoo.kim@resl.kaist.ac.kr
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328663642!51800363!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_40_50,
	HTML_IMAGE_ONLY_28,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11259 invoked from network); 8 Feb 2012 01:14:03 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 01:14:03 -0000
Received: by vbbfq11 with SMTP id fq11so125334vbb.30
	for <multiple recipients>; Tue, 07 Feb 2012 17:16:14 -0800 (PST)
Received: by 10.52.22.143 with SMTP id d15mr11581359vdf.18.1328663774245; Tue,
	07 Feb 2012 17:16:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.65 with HTTP; Tue, 7 Feb 2012 17:15:54 -0800 (PST)
In-Reply-To: <0LZ100H9XVCY7HD0@mailout4.samsung.com>
References: <0LZ100H9XVCY7HD0@mailout4.samsung.com>
From: Dongsoo Kim <dongsoo.kim@resl.kaist.ac.kr>
Date: Wed, 8 Feb 2012 10:15:54 +0900
Message-ID: <CA+HeHOuBy_FZfrEOioq3vsaPjV6siFzne3Za==ZH399VmP0A0g@mail.gmail.com>
To: jm77.ryu@samsung.com
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: xen-arm@lists.xensource.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [XenARM] Para-virtualized linux kernel release for
 the Tegra2 harmony board.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3909538528064563832=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3909538528064563832==
Content-Type: multipart/alternative; boundary=20cf307d07424a353504b869a4b8

--20cf307d07424a353504b869a4b8
Content-Type: text/plain; charset=ISO-8859-1

Hello,

Thank you for hassle free instructions.

I'll give it a shot.

Cheers,

2012/2/8 Jae-Min Ryu <jm77.ryu@samsung.com>

>  We have release a reference code for a para-virtualized linux kernel.
>
>
> You will find it on "git://xenbits.xen.org/people/jm77ryu/linux-xen.git"
>
> In case of xen-arm source, please visit to "git://
> xenbits.xen.org/people/jm77ryu/xen-arm.git"
>
>
> - Build Instructions: -
>
> 1. extract root filesytem contents as following(This requires the root
> privilege)
>     sudo tar -xvpf rootfs_dom0.tar.bz2
>
> 2. cp config_dom0 .config
>
> 3. make ARCH=arm
>
> ** Turn on target board, and download the xen-arm image(xen) and the
> kernel image(vmlinux.out0).
> ** download addresse is :
> ***** xen-arm : 0x8000
> ***** guest kernel images : 0x1e800000
>
> - booting domu -
>
> ** To boot domu (the rootfilesystem of dom0 already has prebuilt domu
> kernel images, see images directory.)
> # smd start     <- start lightweight
> # vm create /etc/xen/dom1
> # xenconsole 1    <= This command switch console to dom 1.
>
> * For domu build, use config_domu configuration file.
> * Don't forget to copy the vmlinux.out1 to rootfs_dom0/images directory
> after domu kernel build.
>
>
>
> _______________________________________________
> Xen-arm mailing list
> Xen-arm@lists.xensource.com
> http://lists.xensource.com/mailman/listinfo/xen-arm
>
>


-- 
=
Dongsoo Nathaniel Kim
Linux kernel, media device S/W engineer / Ph.D Student
Dept. of Computer Science, KAIST
Real-time & Embedded Systems Lab.

--20cf307d07424a353504b869a4b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>Thank you for hassle free instructions.</div><div=
><br></div><div>I&#39;ll give it a shot.</div><div><br></div><div>Cheers,</=
div><div><br><div class=3D"gmail_quote">2012/2/8 Jae-Min Ryu <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jm77.ryu@samsung.com">jm77.ryu@samsung.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>
<p>
We have release a reference code for a para-virtualized linux kernel.</p>
<p><br>You will find it on &quot;git://<a href=3D"http://xenbits.xen.org/pe=
ople/jm77ryu/linux-xen.git" target=3D"_blank">xenbits.xen.org/people/jm77ry=
u/linux-xen.git</a>&quot;<br><br>In case of xen-arm source, please visit to=
 &quot;git://<a href=3D"http://xenbits.xen.org/people/jm77ryu/xen-arm.git" =
target=3D"_blank">xenbits.xen.org/people/jm77ryu/xen-arm.git</a>&quot;<br>

<br><br>- Build Instructions: -<br><br>1. extract root filesytem contents a=
s following(This requires the root privilege)<br>=A0=A0=A0=A0sudo tar -xvpf=
 rootfs_dom0.tar.bz2<br><br>2. cp config_dom0 .config<br><br>3. make ARCH=
=3Darm<br>

<br>** Turn on target board, and download the xen-arm image(xen) and the ke=
rnel image(vmlinux.out0).<br>** download addresse is :<br>***** xen-arm : 0=
x8000<br>***** guest kernel images : 0x1e800000<br><br>- booting domu -<br>

<br>** To boot domu (the rootfilesystem of dom0 already has prebuilt domu k=
ernel images, see images directory.)<br># smd start=A0=A0=A0=A0 &lt;- start=
 lightweight<br># vm create /etc/xen/dom1<br># xenconsole 1=A0=A0=A0=A0&lt;=
=3D This command switch console to dom 1.<br>

<br>* For domu build, use config_domu configuration file.<br>* Don&#39;t fo=
rget to copy the vmlinux.out1 to rootfs_dom0/images directory after domu ke=
rnel build. </p>
<p>=A0</p></div><img border=3D"0" width=3D"0" height=3D"0"><br>____________=
___________________________________<br>
Xen-arm mailing list<br>
<a href=3D"mailto:Xen-arm@lists.xensource.com">Xen-arm@lists.xensource.com<=
/a><br>
<a href=3D"http://lists.xensource.com/mailman/listinfo/xen-arm" target=3D"_=
blank">http://lists.xensource.com/mailman/listinfo/xen-arm</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><span st=
yle=3D"color:rgb(136,136,136);font-family:arial,sans-serif;font-size:11px;f=
ont-style:normal;font-variant:normal;font-weight:normal;letter-spacing:norm=
al;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255=
)">=3D<br>

Dongsoo Nathaniel Kim<br>Linux kernel, media device S/W engineer / Ph.D Stu=
dent<br>Dept. of Computer Science, KAIST<br>Real-time &amp; Embedded System=
s Lab.</span><br>
</div>

--20cf307d07424a353504b869a4b8--


--===============3909538528064563832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3909538528064563832==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfm-0005wz-06; Fri, 10 Feb 2012 10:25:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongsoo.kim@resl.kaist.ac.kr>)
	id 1Ruw8v-00061m-H9; Wed, 08 Feb 2012 01:16:17 +0000
X-Env-Sender: dongsoo.kim@resl.kaist.ac.kr
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328663642!51800363!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_40_50,
	HTML_IMAGE_ONLY_28,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11259 invoked from network); 8 Feb 2012 01:14:03 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 01:14:03 -0000
Received: by vbbfq11 with SMTP id fq11so125334vbb.30
	for <multiple recipients>; Tue, 07 Feb 2012 17:16:14 -0800 (PST)
Received: by 10.52.22.143 with SMTP id d15mr11581359vdf.18.1328663774245; Tue,
	07 Feb 2012 17:16:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.65 with HTTP; Tue, 7 Feb 2012 17:15:54 -0800 (PST)
In-Reply-To: <0LZ100H9XVCY7HD0@mailout4.samsung.com>
References: <0LZ100H9XVCY7HD0@mailout4.samsung.com>
From: Dongsoo Kim <dongsoo.kim@resl.kaist.ac.kr>
Date: Wed, 8 Feb 2012 10:15:54 +0900
Message-ID: <CA+HeHOuBy_FZfrEOioq3vsaPjV6siFzne3Za==ZH399VmP0A0g@mail.gmail.com>
To: jm77.ryu@samsung.com
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: xen-arm@lists.xensource.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [XenARM] Para-virtualized linux kernel release for
 the Tegra2 harmony board.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3909538528064563832=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3909538528064563832==
Content-Type: multipart/alternative; boundary=20cf307d07424a353504b869a4b8

--20cf307d07424a353504b869a4b8
Content-Type: text/plain; charset=ISO-8859-1

Hello,

Thank you for hassle free instructions.

I'll give it a shot.

Cheers,

2012/2/8 Jae-Min Ryu <jm77.ryu@samsung.com>

>  We have release a reference code for a para-virtualized linux kernel.
>
>
> You will find it on "git://xenbits.xen.org/people/jm77ryu/linux-xen.git"
>
> In case of xen-arm source, please visit to "git://
> xenbits.xen.org/people/jm77ryu/xen-arm.git"
>
>
> - Build Instructions: -
>
> 1. extract root filesytem contents as following(This requires the root
> privilege)
>     sudo tar -xvpf rootfs_dom0.tar.bz2
>
> 2. cp config_dom0 .config
>
> 3. make ARCH=arm
>
> ** Turn on target board, and download the xen-arm image(xen) and the
> kernel image(vmlinux.out0).
> ** download addresse is :
> ***** xen-arm : 0x8000
> ***** guest kernel images : 0x1e800000
>
> - booting domu -
>
> ** To boot domu (the rootfilesystem of dom0 already has prebuilt domu
> kernel images, see images directory.)
> # smd start     <- start lightweight
> # vm create /etc/xen/dom1
> # xenconsole 1    <= This command switch console to dom 1.
>
> * For domu build, use config_domu configuration file.
> * Don't forget to copy the vmlinux.out1 to rootfs_dom0/images directory
> after domu kernel build.
>
>
>
> _______________________________________________
> Xen-arm mailing list
> Xen-arm@lists.xensource.com
> http://lists.xensource.com/mailman/listinfo/xen-arm
>
>


-- 
=
Dongsoo Nathaniel Kim
Linux kernel, media device S/W engineer / Ph.D Student
Dept. of Computer Science, KAIST
Real-time & Embedded Systems Lab.

--20cf307d07424a353504b869a4b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>Thank you for hassle free instructions.</div><div=
><br></div><div>I&#39;ll give it a shot.</div><div><br></div><div>Cheers,</=
div><div><br><div class=3D"gmail_quote">2012/2/8 Jae-Min Ryu <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jm77.ryu@samsung.com">jm77.ryu@samsung.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>
<p>
We have release a reference code for a para-virtualized linux kernel.</p>
<p><br>You will find it on &quot;git://<a href=3D"http://xenbits.xen.org/pe=
ople/jm77ryu/linux-xen.git" target=3D"_blank">xenbits.xen.org/people/jm77ry=
u/linux-xen.git</a>&quot;<br><br>In case of xen-arm source, please visit to=
 &quot;git://<a href=3D"http://xenbits.xen.org/people/jm77ryu/xen-arm.git" =
target=3D"_blank">xenbits.xen.org/people/jm77ryu/xen-arm.git</a>&quot;<br>

<br><br>- Build Instructions: -<br><br>1. extract root filesytem contents a=
s following(This requires the root privilege)<br>=A0=A0=A0=A0sudo tar -xvpf=
 rootfs_dom0.tar.bz2<br><br>2. cp config_dom0 .config<br><br>3. make ARCH=
=3Darm<br>

<br>** Turn on target board, and download the xen-arm image(xen) and the ke=
rnel image(vmlinux.out0).<br>** download addresse is :<br>***** xen-arm : 0=
x8000<br>***** guest kernel images : 0x1e800000<br><br>- booting domu -<br>

<br>** To boot domu (the rootfilesystem of dom0 already has prebuilt domu k=
ernel images, see images directory.)<br># smd start=A0=A0=A0=A0 &lt;- start=
 lightweight<br># vm create /etc/xen/dom1<br># xenconsole 1=A0=A0=A0=A0&lt;=
=3D This command switch console to dom 1.<br>

<br>* For domu build, use config_domu configuration file.<br>* Don&#39;t fo=
rget to copy the vmlinux.out1 to rootfs_dom0/images directory after domu ke=
rnel build. </p>
<p>=A0</p></div><img border=3D"0" width=3D"0" height=3D"0"><br>____________=
___________________________________<br>
Xen-arm mailing list<br>
<a href=3D"mailto:Xen-arm@lists.xensource.com">Xen-arm@lists.xensource.com<=
/a><br>
<a href=3D"http://lists.xensource.com/mailman/listinfo/xen-arm" target=3D"_=
blank">http://lists.xensource.com/mailman/listinfo/xen-arm</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><span st=
yle=3D"color:rgb(136,136,136);font-family:arial,sans-serif;font-size:11px;f=
ont-style:normal;font-variant:normal;font-weight:normal;letter-spacing:norm=
al;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255=
)">=3D<br>

Dongsoo Nathaniel Kim<br>Linux kernel, media device S/W engineer / Ph.D Stu=
dent<br>Dept. of Computer Science, KAIST<br>Real-time &amp; Embedded System=
s Lab.</span><br>
</div>

--20cf307d07424a353504b869a4b8--


--===============3909538528064563832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3909538528064563832==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfv-0005yj-Ef; Fri, 10 Feb 2012 10:25:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=0386a6dbf3=mjg59@cavan.codon.org.uk>)
	id 1RvZxt-000845-34
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 19:47:33 +0000
X-Env-Sender: prvs=0386a6dbf3=mjg59@cavan.codon.org.uk
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328816847!2460147!1
X-Originating-IP: [93.93.128.6]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1926 invoked from network); 9 Feb 2012 19:47:27 -0000
Received: from cavan.codon.org.uk (HELO cavan.codon.org.uk) (93.93.128.6)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Feb 2012 19:47:27 -0000
Received: from mjg59 by cavan.codon.org.uk with local (Exim 4.72)
	(envelope-from <mjg59@cavan.codon.org.uk>)
	id 1RvZxj-0002Ia-JX; Thu, 09 Feb 2012 19:47:23 +0000
Date: Thu, 9 Feb 2012 19:47:23 +0000
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Tang Liang <liang.tang@oracle.com>
Message-ID: <20120209194723.GA8622@srcf.ucam.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328758401-24258-1-git-send-email-liang.tang@oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk
X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: linux-acpi@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd 
really be nice to avoid yet another set of duplicate functions here - 
the ia64/x86 situation is already bad enough. Ideally this would be 
sufficiently generic that arm can also plug into it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfv-0005yj-Ef; Fri, 10 Feb 2012 10:25:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=0386a6dbf3=mjg59@cavan.codon.org.uk>)
	id 1RvZxt-000845-34
	for xen-devel@lists.xensource.com; Thu, 09 Feb 2012 19:47:33 +0000
X-Env-Sender: prvs=0386a6dbf3=mjg59@cavan.codon.org.uk
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328816847!2460147!1
X-Originating-IP: [93.93.128.6]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1926 invoked from network); 9 Feb 2012 19:47:27 -0000
Received: from cavan.codon.org.uk (HELO cavan.codon.org.uk) (93.93.128.6)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Feb 2012 19:47:27 -0000
Received: from mjg59 by cavan.codon.org.uk with local (Exim 4.72)
	(envelope-from <mjg59@cavan.codon.org.uk>)
	id 1RvZxj-0002Ia-JX; Thu, 09 Feb 2012 19:47:23 +0000
Date: Thu, 9 Feb 2012 19:47:23 +0000
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Tang Liang <liang.tang@oracle.com>
Message-ID: <20120209194723.GA8622@srcf.ucam.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328758401-24258-1-git-send-email-liang.tang@oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk
X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: linux-acpi@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd 
really be nice to avoid yet another set of duplicate functions here - 
the ia64/x86 situation is already bad enough. Ideally this would be 
sufficiently generic that arm can also plug into it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfq-0005xj-Fy; Fri, 10 Feb 2012 10:25:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agent.peter123@gmail.com>) id 1RvBvw-0001jQ-55
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:07:56 +0000
X-Env-Sender: agent.peter123@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328724468!12392203!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23251 invoked from network); 8 Feb 2012 18:07:49 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 18:07:49 -0000
Received: by qabg1 with SMTP id g1so18670434qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 10:07:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=6PheOr26ymqQ7yL+L8d+wUvYRcmLrHXczeihfhRh9dI=;
	b=tx2A5+OcvLZRVkbucYHnR9rKACxXCYmTkSaQPsKIAexaA5lOekCyOrIVLHTnAYtJo3
	XAz6im6dKsdd80tOmujcdRuSzdNjLYkByur5rwYukkO4U3YofeYe4NLO6gG9hb6jL7SN
	ujWOtoYvUH6+HFocs6bs8/Q65hHngZ6JxKrU8=
MIME-Version: 1.0
Received: by 10.224.59.209 with SMTP id m17mr16283928qah.5.1328724468173; Wed,
	08 Feb 2012 10:07:48 -0800 (PST)
Received: by 10.229.220.207 with HTTP; Wed, 8 Feb 2012 10:07:48 -0800 (PST)
Date: Wed, 8 Feb 2012 13:07:48 -0500
Message-ID: <CAJy3yGD8PM5c6rF-gvXyCWKFLR1CFvJYxNUJgRhzq=+2rnZhpw@mail.gmail.com>
From: Peter Deng <agent.peter123@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Subject: [Xen-devel] Xen Mem Page Sharing -> Implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4028017953792963252=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4028017953792963252==
Content-Type: multipart/alternative; boundary=20cf306f76b6ee0ae404b877c5ca

--20cf306f76b6ee0ae404b877c5ca
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 1, 2012 at 4:27 PM, Andres Lagar-Cavilla <
andres@lagarcavilla.org> wrote:

> > Date: Wed, 1 Feb 2012 13:05:55 -0500
> > From: Peter Deng <agent.peter123@gmail.com>
> > To: xen-devel@lists.xensource.com
> > Subject: [Xen-devel] Xen Mem Page Sharing
> > Message-ID:
> >       <
> CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QOdDodKoYdTR-Q@mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi,
> >
> > I'm am looking into and doing some research on Memory Page Sharing on
> Xen,
> > and I would like to know the current activity status regarding Xen's
> > memory
> > management. Also, while looking through the source code, I am having some
> > trouble translating some of the functions, notably in mem_sharing.c, and
> > one function I would like to have explained is mem_sharing_audit(). One
> > that note, is there recent documentation on Xen code or do I need to
> trace
> > the logs to determine development changes?
>
> Quite recently we effectively overhauled all the sharing support in the
> hypervisor. So it's best you check out the latest xen-unstable tree.
>
> The interface is relatively simple. You identify a page that is a
> candidate for sharing and you call nominate(domain, gfn). You get back a
> 64 bit handle. This is a unique identifier for this *version* of this
> guest page. Should the page change (writes) the handle won't be valid
> anymore.
>
> Once you have two candidates you can coalesce them by calling
> share(source_domain, source_gfn, source_handle, client_domain, client_gfn,
> client_handle). Voila! you've shared and saved memory. You can reshare (to
> coalesce > 2 guest pages into a single backing shared page), but keep in
> mind that the client gfn and handle won't be valid anymore for further
> sharing.
>
> All the user-space visible code is in tools/libxc/xc_memshr.c, with
> prototypes in tools/libxc/xenctrl.h. As you found out, the hypervisor code
> is in arch/x86/mm/mem_sharing.c
>
> It is crucial to understand that the hypervisor won't check the contents
> of the pages. If you select the wrong candidates for sharing, you will
> crash your guest(s). However, the hypervisor will ensure that pages are
> properly unshared when writes happen.
>
> Hope this helps, agent Peter!
> Andres
> >
> > Thanks,
> >
> > Peter
>
>
>
Thanks for the explanation Andres,

So looking through the code, I am getting that the mechanisms for sharing
the pages are present within the hypervisor and the hypervisor will manage
the sharing and unsharing of pages. Now, this leads me into a question that
regards the implementation of sharing pages. In the research articles I
have read, hashing was used to determine the contents of similar pages; is
there code implementation present in Xen that does this or something
related in that area? If so, where is it in the source code?

Thanks,
Peter

--20cf306f76b6ee0ae404b877c5ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Feb 1, 2012 at 4:27 PM, Andres L=
agar-Cavilla <span dir=3D"ltr">&lt;<a href=3D"mailto:andres@lagarcavilla.or=
g">andres@lagarcavilla.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
&gt; Date: Wed, 1 Feb 2012 13:05:55 -0500<br>
&gt; From: Peter Deng &lt;<a href=3D"mailto:agent.peter123@gmail.com">agent=
.peter123@gmail.com</a>&gt;<br>
&gt; To: <a href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@lists.x=
ensource.com</a><br>
&gt; Subject: [Xen-devel] Xen Mem Page Sharing<br>
&gt; Message-ID:<br>
&gt; =A0 =A0 =A0 &lt;<a href=3D"mailto:CAJy3yGDJAWJmPtgwr1esf%2BF%2BY4kopV1=
FGvo8QOdDodKoYdTR-Q@mail.gmail.com">CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QO=
dDodKoYdTR-Q@mail.gmail.com</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3D&quot;iso-8859-1&quot;<br>
<div><div class=3D"h5">&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m am looking into and doing some research on Memory Page Sharing=
 on Xen,<br>
&gt; and I would like to know the current activity status regarding Xen&#39=
;s<br>
&gt; memory<br>
&gt; management. Also, while looking through the source code, I am having s=
ome<br>
&gt; trouble translating some of the functions, notably in mem_sharing.c, a=
nd<br>
&gt; one function I would like to have explained is mem_sharing_audit(). On=
e<br>
&gt; that note, is there recent documentation on Xen code or do I need to t=
race<br>
&gt; the logs to determine development changes?<br>
<br>
</div></div>Quite recently we effectively overhauled all the sharing suppor=
t in the<br>
hypervisor. So it&#39;s best you check out the latest xen-unstable tree.<br=
>
<br>
The interface is relatively simple. You identify a page that is a<br>
candidate for sharing and you call nominate(domain, gfn). You get back a<br=
>
64 bit handle. This is a unique identifier for this *version* of this<br>
guest page. Should the page change (writes) the handle won&#39;t be valid<b=
r>
anymore.<br>
<br>
Once you have two candidates you can coalesce them by calling<br>
share(source_domain, source_gfn, source_handle, client_domain, client_gfn,<=
br>
client_handle). Voila! you&#39;ve shared and saved memory. You can reshare =
(to<br>
coalesce &gt; 2 guest pages into a single backing shared page), but keep in=
<br>
mind that the client gfn and handle won&#39;t be valid anymore for further<=
br>
sharing.<br>
<br>
All the user-space visible code is in tools/libxc/xc_memshr.c, with<br>
prototypes in tools/libxc/xenctrl.h. As you found out, the hypervisor code<=
br>
is in arch/x86/mm/mem_sharing.c<br>
<br>
It is crucial to understand that the hypervisor won&#39;t check the content=
s<br>
of the pages. If you select the wrong candidates for sharing, you will<br>
crash your guest(s). However, the hypervisor will ensure that pages are<br>
properly unshared when writes happen.<br>
<br>
Hope this helps, agent Peter!<br>
Andres<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Peter<br>
<br>
<br>
</blockquote></div><br>
Thanks for the explanation Andres,<br>=A0<br>So looking through the code, I=
 am=20
getting that the mechanisms for sharing the pages are present within the
 hypervisor and the hypervisor will manage the sharing and unsharing of=20
pages. Now, this leads me into a question that regards the=20
implementation of sharing pages. In the research articles I have read,=20
hashing was used to determine the contents of similar pages; is there=20
code implementation present in Xen that does this or something=20
related in that area? If so, where is it in the source code?<br>
<br>
Thanks,<br>
Peter=20

--20cf306f76b6ee0ae404b877c5ca--


--===============4028017953792963252==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4028017953792963252==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfx-0005zG-Og; Fri, 10 Feb 2012 10:25:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RveKD-00069k-I0
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 00:26:53 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328833605!10840733!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MjU4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 548 invoked from network); 10 Feb 2012 00:26:47 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 00:26:47 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RveK2-00012x-P9 from Paul_Brook@mentor.com ;
	Thu, 09 Feb 2012 16:26:42 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 00:26:41 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id E85926EEE6;
	Fri, 10 Feb 2012 00:26:40 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: qemu-devel@nongnu.org
Date: Fri, 10 Feb 2012 00:26:40 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327688498-12362-6-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Message-Id: <201202100026.40727.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 00:26:41.0735 (UTC)
	FILETIME=[A936DD70:01CCE78A]
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.

No.

The reason we have this is because there are bits of code that rely on 
polling.  IIRC slirp and the floppy DMA engine were the main culprits. 
qemu_calculate_timeout is an ugly hack to poll at least once a second, 
allowing the guest to make forward progress when we miss an event.

If you think you've fixed all those polling places then you should remove the 
timeout altogether and block indefinitely.  A 1h timeout is almost certainly 
not the right answer.

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfq-0005xj-Fy; Fri, 10 Feb 2012 10:25:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agent.peter123@gmail.com>) id 1RvBvw-0001jQ-55
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 18:07:56 +0000
X-Env-Sender: agent.peter123@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328724468!12392203!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23251 invoked from network); 8 Feb 2012 18:07:49 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2012 18:07:49 -0000
Received: by qabg1 with SMTP id g1so18670434qab.9
	for <xen-devel@lists.xensource.com>;
	Wed, 08 Feb 2012 10:07:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=6PheOr26ymqQ7yL+L8d+wUvYRcmLrHXczeihfhRh9dI=;
	b=tx2A5+OcvLZRVkbucYHnR9rKACxXCYmTkSaQPsKIAexaA5lOekCyOrIVLHTnAYtJo3
	XAz6im6dKsdd80tOmujcdRuSzdNjLYkByur5rwYukkO4U3YofeYe4NLO6gG9hb6jL7SN
	ujWOtoYvUH6+HFocs6bs8/Q65hHngZ6JxKrU8=
MIME-Version: 1.0
Received: by 10.224.59.209 with SMTP id m17mr16283928qah.5.1328724468173; Wed,
	08 Feb 2012 10:07:48 -0800 (PST)
Received: by 10.229.220.207 with HTTP; Wed, 8 Feb 2012 10:07:48 -0800 (PST)
Date: Wed, 8 Feb 2012 13:07:48 -0500
Message-ID: <CAJy3yGD8PM5c6rF-gvXyCWKFLR1CFvJYxNUJgRhzq=+2rnZhpw@mail.gmail.com>
From: Peter Deng <agent.peter123@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Subject: [Xen-devel] Xen Mem Page Sharing -> Implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4028017953792963252=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4028017953792963252==
Content-Type: multipart/alternative; boundary=20cf306f76b6ee0ae404b877c5ca

--20cf306f76b6ee0ae404b877c5ca
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 1, 2012 at 4:27 PM, Andres Lagar-Cavilla <
andres@lagarcavilla.org> wrote:

> > Date: Wed, 1 Feb 2012 13:05:55 -0500
> > From: Peter Deng <agent.peter123@gmail.com>
> > To: xen-devel@lists.xensource.com
> > Subject: [Xen-devel] Xen Mem Page Sharing
> > Message-ID:
> >       <
> CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QOdDodKoYdTR-Q@mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi,
> >
> > I'm am looking into and doing some research on Memory Page Sharing on
> Xen,
> > and I would like to know the current activity status regarding Xen's
> > memory
> > management. Also, while looking through the source code, I am having some
> > trouble translating some of the functions, notably in mem_sharing.c, and
> > one function I would like to have explained is mem_sharing_audit(). One
> > that note, is there recent documentation on Xen code or do I need to
> trace
> > the logs to determine development changes?
>
> Quite recently we effectively overhauled all the sharing support in the
> hypervisor. So it's best you check out the latest xen-unstable tree.
>
> The interface is relatively simple. You identify a page that is a
> candidate for sharing and you call nominate(domain, gfn). You get back a
> 64 bit handle. This is a unique identifier for this *version* of this
> guest page. Should the page change (writes) the handle won't be valid
> anymore.
>
> Once you have two candidates you can coalesce them by calling
> share(source_domain, source_gfn, source_handle, client_domain, client_gfn,
> client_handle). Voila! you've shared and saved memory. You can reshare (to
> coalesce > 2 guest pages into a single backing shared page), but keep in
> mind that the client gfn and handle won't be valid anymore for further
> sharing.
>
> All the user-space visible code is in tools/libxc/xc_memshr.c, with
> prototypes in tools/libxc/xenctrl.h. As you found out, the hypervisor code
> is in arch/x86/mm/mem_sharing.c
>
> It is crucial to understand that the hypervisor won't check the contents
> of the pages. If you select the wrong candidates for sharing, you will
> crash your guest(s). However, the hypervisor will ensure that pages are
> properly unshared when writes happen.
>
> Hope this helps, agent Peter!
> Andres
> >
> > Thanks,
> >
> > Peter
>
>
>
Thanks for the explanation Andres,

So looking through the code, I am getting that the mechanisms for sharing
the pages are present within the hypervisor and the hypervisor will manage
the sharing and unsharing of pages. Now, this leads me into a question that
regards the implementation of sharing pages. In the research articles I
have read, hashing was used to determine the contents of similar pages; is
there code implementation present in Xen that does this or something
related in that area? If so, where is it in the source code?

Thanks,
Peter

--20cf306f76b6ee0ae404b877c5ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Feb 1, 2012 at 4:27 PM, Andres L=
agar-Cavilla <span dir=3D"ltr">&lt;<a href=3D"mailto:andres@lagarcavilla.or=
g">andres@lagarcavilla.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
&gt; Date: Wed, 1 Feb 2012 13:05:55 -0500<br>
&gt; From: Peter Deng &lt;<a href=3D"mailto:agent.peter123@gmail.com">agent=
.peter123@gmail.com</a>&gt;<br>
&gt; To: <a href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@lists.x=
ensource.com</a><br>
&gt; Subject: [Xen-devel] Xen Mem Page Sharing<br>
&gt; Message-ID:<br>
&gt; =A0 =A0 =A0 &lt;<a href=3D"mailto:CAJy3yGDJAWJmPtgwr1esf%2BF%2BY4kopV1=
FGvo8QOdDodKoYdTR-Q@mail.gmail.com">CAJy3yGDJAWJmPtgwr1esf+F+Y4kopV1FGvo8QO=
dDodKoYdTR-Q@mail.gmail.com</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3D&quot;iso-8859-1&quot;<br>
<div><div class=3D"h5">&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m am looking into and doing some research on Memory Page Sharing=
 on Xen,<br>
&gt; and I would like to know the current activity status regarding Xen&#39=
;s<br>
&gt; memory<br>
&gt; management. Also, while looking through the source code, I am having s=
ome<br>
&gt; trouble translating some of the functions, notably in mem_sharing.c, a=
nd<br>
&gt; one function I would like to have explained is mem_sharing_audit(). On=
e<br>
&gt; that note, is there recent documentation on Xen code or do I need to t=
race<br>
&gt; the logs to determine development changes?<br>
<br>
</div></div>Quite recently we effectively overhauled all the sharing suppor=
t in the<br>
hypervisor. So it&#39;s best you check out the latest xen-unstable tree.<br=
>
<br>
The interface is relatively simple. You identify a page that is a<br>
candidate for sharing and you call nominate(domain, gfn). You get back a<br=
>
64 bit handle. This is a unique identifier for this *version* of this<br>
guest page. Should the page change (writes) the handle won&#39;t be valid<b=
r>
anymore.<br>
<br>
Once you have two candidates you can coalesce them by calling<br>
share(source_domain, source_gfn, source_handle, client_domain, client_gfn,<=
br>
client_handle). Voila! you&#39;ve shared and saved memory. You can reshare =
(to<br>
coalesce &gt; 2 guest pages into a single backing shared page), but keep in=
<br>
mind that the client gfn and handle won&#39;t be valid anymore for further<=
br>
sharing.<br>
<br>
All the user-space visible code is in tools/libxc/xc_memshr.c, with<br>
prototypes in tools/libxc/xenctrl.h. As you found out, the hypervisor code<=
br>
is in arch/x86/mm/mem_sharing.c<br>
<br>
It is crucial to understand that the hypervisor won&#39;t check the content=
s<br>
of the pages. If you select the wrong candidates for sharing, you will<br>
crash your guest(s). However, the hypervisor will ensure that pages are<br>
properly unshared when writes happen.<br>
<br>
Hope this helps, agent Peter!<br>
Andres<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Peter<br>
<br>
<br>
</blockquote></div><br>
Thanks for the explanation Andres,<br>=A0<br>So looking through the code, I=
 am=20
getting that the mechanisms for sharing the pages are present within the
 hypervisor and the hypervisor will manage the sharing and unsharing of=20
pages. Now, this leads me into a question that regards the=20
implementation of sharing pages. In the research articles I have read,=20
hashing was used to determine the contents of similar pages; is there=20
code implementation present in Xen that does this or something=20
related in that area? If so, where is it in the source code?<br>
<br>
Thanks,<br>
Peter=20

--20cf306f76b6ee0ae404b877c5ca--


--===============4028017953792963252==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4028017953792963252==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfx-0005zG-Og; Fri, 10 Feb 2012 10:25:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RveKD-00069k-I0
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 00:26:53 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328833605!10840733!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MjU4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 548 invoked from network); 10 Feb 2012 00:26:47 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 00:26:47 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RveK2-00012x-P9 from Paul_Brook@mentor.com ;
	Thu, 09 Feb 2012 16:26:42 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 00:26:41 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id E85926EEE6;
	Fri, 10 Feb 2012 00:26:40 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: qemu-devel@nongnu.org
Date: Fri, 10 Feb 2012 00:26:40 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327688498-12362-6-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Message-Id: <201202100026.40727.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 00:26:41.0735 (UTC)
	FILETIME=[A936DD70:01CCE78A]
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.

No.

The reason we have this is because there are bits of code that rely on 
polling.  IIRC slirp and the floppy DMA engine were the main culprits. 
qemu_calculate_timeout is an ugly hack to poll at least once a second, 
allowing the guest to make forward progress when we miss an event.

If you think you've fixed all those polling places then you should remove the 
timeout altogether and block indefinitely.  A 1h timeout is almost certainly 
not the right answer.

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfu-0005yV-Mf; Fri, 10 Feb 2012 10:25:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1RvINW-0006oF-B8; Thu, 09 Feb 2012 01:00:50 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328749208!51674493!1
X-Originating-IP: [220.181.13.108]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25613 invoked from network); 9 Feb 2012 01:00:10 -0000
Received: from m13-108.163.com (HELO m13-108.163.com) (220.181.13.108)
	by server-12.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 01:00:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=DmIvZyxTPGrdV5l
	hx0pxiQtVPPzuOCXPTJ5QMFswdck=; b=jHpC3jRswLAJvEV46pp4/2VAy3RmDOc
	qTH5I6hGPzIi/jQ9IAobINAjFQVVhj6/gJa/Lpbk4+DK+ohxgkRbqgrp0JIQTUa9
	Rb7vAxwI/IWK4KH8px1CZ12B3YDfihh+EsmWEcbAXU/PEOM+zpsuRWnWC/8+PhMW
	YByXhA5fAPRk=
Received: from chysun2000 ( [219.142.122.100] ) by ajax-webmail-wmsvr108
	(Coremail) ; Thu, 9 Feb 2012 09:00:38 +0800 (CST)
Date: Thu, 9 Feb 2012 09:00:38 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Message-ID: <38e5794e.42de.1355fa05a3c.Coremail.chysun2000@163.com>
In-Reply-To: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
References: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
MIME-Version: 1.0
X-Originating-IP: [219.142.122.100]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: x8EuRWZvb3Rlcl9odG09MTA0MTo4MQ==
X-CM-TRANSID: bMGowEAJ6UC2GjNPL08WAA--.2969W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiJhZO6kCpn0i8-QACsp
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1832129836271967539=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1832129836271967539==
Content-Type: multipart/alternative; 
	boundary="----=_Part_53732_926248899.1328749238844"

------=_Part_53732_926248899.1328749238844
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi Ian and Xen-ARMs,

I tried this compiler. The compile is OK.

Best Regards,
Frank
--




At 2012-02-09 00:53:08,"Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>On Mon, 2012-02-06 at 01:00 +0000, Frank, Chen wrote:
>> The problem is where to download the cross compiler
>> "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and
>> mcpu=cortex-a15.
>>  
>> Would someone give me one avaiable URL to download the right
>> compiler? 
>
>I use
>http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
>
>Ian.
>
>
>

------=_Part_53732_926248899.1328749238844
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi Ian and Xen-ARMs,<br><br>I tried this compiler. The compile is OK.<br><br>Best Regards,<br>Frank<br>--<br><div></div><div id="divNeteaseMailCard"></div><br><pre><br>At&nbsp;2012-02-09&nbsp;00:53:08,"Ian&nbsp;Campbell"&nbsp;&lt;Ian.Campbell@citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Mon,&nbsp;2012-02-06&nbsp;at&nbsp;01:00&nbsp;+0000,&nbsp;Frank,&nbsp;Chen&nbsp;wrote:
&gt;&gt;&nbsp;The&nbsp;problem&nbsp;is&nbsp;where&nbsp;to&nbsp;download&nbsp;the&nbsp;cross&nbsp;compiler
&gt;&gt;&nbsp;"arm-none-linux-gnueabi-gcc"&nbsp;which&nbsp;supports&nbsp;march=arm-V7a&nbsp;and
&gt;&gt;&nbsp;mcpu=cortex-a15.
&gt;&gt;&nbsp;&nbsp;
&gt;&gt;&nbsp;Would&nbsp;someone&nbsp;give&nbsp;me&nbsp;one&nbsp;avaiable&nbsp;URL&nbsp;to&nbsp;download&nbsp;the&nbsp;right
&gt;&gt;&nbsp;compiler?&nbsp;
&gt;
&gt;I&nbsp;use
&gt;http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
&gt;
&gt;Ian.
&gt;
&gt;
&gt;
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_53732_926248899.1328749238844--



--===============1832129836271967539==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1832129836271967539==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfo-0005xM-8g; Fri, 10 Feb 2012 10:25:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1Rv77v-0007Lx-Iu; Wed, 08 Feb 2012 12:59:59 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328705989!12492534!1
X-Originating-IP: [220.181.13.31]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30265 invoked from network); 8 Feb 2012 12:59:51 -0000
Received: from m13-31.163.com (HELO m13-31.163.com) (220.181.13.31)
	by server-8.tower-174.messagelabs.com with SMTP;
	8 Feb 2012 12:59:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=EzOW42W1Df/VzGb
	z8jW0J2KOwmsCEpDYuqrZ5pZzsvA=; b=VF+jlR2Wo4C5m2WomhJbcTujU4gq5eD
	KlxaDERv/VUjjGSDTc37KPLMVsYk/WApCptqMV3ejcHkhk1EAb9zk9tDGF62W3IY
	+mj1epOD9CxIEx/iEGZmRHj8CiTfZeGhdD9ogfxNRuce4myR9kv+ojmUQ8hbLpuR
	wJOkwLXhtid0=
Received: from chysun2000 ( [117.79.232.253] ) by ajax-webmail-wmsvr31
	(Coremail) ; Wed, 8 Feb 2012 20:59:37 +0800 (CST)
Date: Wed, 8 Feb 2012 20:59:37 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Message-ID: <715c4021.25979.1355d0c3d8d.Coremail.chysun2000@163.com>
In-Reply-To: <alpine.DEB.2.00.1202081035210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202081035210.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
MIME-Version: 1.0
X-Originating-IP: [117.79.232.253]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: dJNiXGZvb3Rlcl9odG09MzcxNTo4MQ==
X-CM-TRANSID: H8GowGAZwUK5cTJPG14UAA--.1720W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiMRRO6ki42H+2LAAAsM
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7021684158236404105=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7021684158236404105==
Content-Type: multipart/alternative; 
	boundary="----=_Part_441978_2009442295.1328705977740"

------=_Part_441978_2009442295.1328705977740
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGkgWGVuLUFSTXMsCgoKSSB1c2VkIHRoZSBsYXRlc3QgY29tcGlsZXIgZnJvbSBMaW5hcm8uCkJ1
dCB0aGUgY29tcGlsZXIgY2Fubm90IHN1cHBvcnQgbWFyY2g9YXJtdjctYSBhbmQgbWNwdT1jb3J0
ZXgtYTE1CgpUaGUgZXJyb3IgaW5mb3JtYXRpb24gaXMgbGlrZSB0aGlzOgptYWtlIC1mIC9ob21l
L2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL1J1bGVzLm1rIC1DIGluY2x1
ZGUKbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvaG9tZS9mcmFuay93b3Jrc3BhY2UveGVu
L3NyYy94ZW4tYXJtLXY2L3hlbi9pbmNsdWRlJwptYWtlWzNdOiBOb3RoaW5nIHRvIGJlIGRvbmUg
Zm9yIGBhbGwnLgptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2hvbWUvZnJhbmsvd29ya3Nw
YWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vaW5jbHVkZScKbWFrZSAtZiAvaG9tZS9mcmFuay93
b3Jrc3BhY2UveGVuL3NyYy94ZW4tYXJtLXY2L3hlbi9SdWxlcy5tayAtQyBhcmNoL2FybSBhc20t
b2Zmc2V0cy5zCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL2hvbWUvZnJhbmsvd29ya3Nw
YWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vYXJjaC9hcm0nCmFybS1saW51eC1nbnVlYWJpLWdj
YyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW1hcm0gLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1m
bm8tY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL2hvbWUvZnJhbmsvd29ya3NwYWNlL3hlbi9zcmMv
eGVuLWFybS12Ni94ZW4vaW5jbHVkZSAtbXNvZnQtZmxvYXQgLW5vcGllIC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1ER0NDX0hBU19WSVNJQklM
SVRZX0FUVFJJQlVURSAtbWFyY2g9YXJtdjctYSAtbWNwdT1jb3J0ZXgtYTE1IC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL2hvbWUvZnJhbmsvd29ya3Nw
YWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmFzbS1vZmZzZXRzLnMuZCAtUyAtbyBhc20tb2Zmc2V0cy5zIGFzbS1vZmZzZXRzLmMKYXNtLW9m
ZnNldHMuYzoxOjA6IGVycm9yOiBzd2l0Y2ggLW1jcHU9Y29ydGV4LWExNSBjb25mbGljdHMgd2l0
aCAtbWFyY2g9YXJtdjctYSBzd2l0Y2ggWy1XZXJyb3JdCmNjMTogYWxsIHdhcm5pbmdzIGJlaW5n
IHRyZWF0ZWQgYXMgZXJyb3JzCgoKSSBtb2RpZmllZCB4ZW4vYXJjaC9hcm0vUnVsZXMubWsgbGlr
ZSB0aGUgZm9sbG93aW5nLCB0aGUgY29tcGlsaW5nIGlzIE9LLgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL1J1bGVzLm1rIGIveGVuL2FyY2gvYXJtL1J1bGVzLm1rCmluZGV4IDMzNmUyMDkuLjQw
N2ZjODIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL2FybS9SdWxlcy5taworKysgYi94ZW4vYXJjaC9h
cm0vUnVsZXMubWsKQEAgLTIyLDcgKzIyLDggQEAgaWZuZXEgKCQoY2FsbCBjYy1vcHRpb24sJChD
QyksLWZ2aXNpYmlsaXR5PWhpZGRlbixuKSxuKQogQ0ZMQUdTICs9IC1ER0NDX0hBU19WSVNJQklM
SVRZX0FUVFJJQlVURQogZW5kaWYKIAotQ0ZMQUdTICs9IC1tYXJjaD1hcm12Ny1hIC1tY3B1PWNv
cnRleC1hMTUKKyNDRkxBR1MgKz0gLW1hcmNoPWFybXY3LWEgLW1jcHU9Y29ydGV4LWExNQorQ0ZM
QUdTICs9IC1tY3B1PWNvcnRleC1hMTUKCgpJIGNoZWNrZWQgYmluYXJ5IGZpbGUgeGVuLCBpdCBk
b2VzIG5vdCBoYXZlIHRoZSB1bnJlc29sdmVkIHN5bWJvbC4KCgpCZXN0IFJlZ2FyZHMsCkZyYW5r
Ci0tCgrlnKggMjAxMi0wMi0wOCAxODozNjo0OO+8jCJTdGVmYW5vIFN0YWJlbGxpbmkiIDxzdGVm
YW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4g5YaZ6YGT77yaCj5PbiBNb24sIDYgRmViIDIw
MTIsIEZyYW5rLCBDaGVuIHdyb3RlOgo+PiBIaSBYZW4tQVJNcywKPj4gw4IgCj4+IEkgYXBwbGll
ZCB0aGlzIHBhdGNoLCAiZXJyb3I6w4IgdW5rbm93bsOCIHR5cGXDgiBuYW1lw4IgJ3hlbl9jYWxs
YmFja190JyBpcyBmaXhlZC4KPgo+VGhhbmtzIGZvciB0ZXN0aW5nIQo+Cj4KPj4gQnV0IEkgc3Rp
bGwgbWVldCB0aGUgcHJvYmxlbS4gVGhlIHByb2JsZW0gaXMKPj4gd2hlcmUgdG8gZG93bmxvYWQg
dGhlIGNyb3NzIGNvbXBpbGVyICJhcm0tbm9uZS1saW51eC1nbnVlYWJpLWdjYyIgd2hpY2ggc3Vw
cG9ydHMgbWFyY2g9YXJtLVY3YSBhbmQgbWNwdT1jb3J0ZXgtYTE1Lgo+PiDDgiAKPj4gV291bGTD
giBzb21lb25lIGdpdmUgbWUgb25lIGF2YWlhYmxlIFVSTCB0byBkb3dubG9hZCB0aGUgcmlnaHQg
Y29tcGlsZXI/w4IgCj4KPldoaWNoIGNyb3NzLWNvbXBpbGVyIGFyZSB5b3UgdXNpbmcgYXQgdGhl
IG1vbWVudD8KPklmIHlvdSBhcmUgb24gVWJ1bnR1LCB3ZSBqdXN0IG5lZWQgdG8KPgo+YXB0LWdl
dCBpbnN0YWxsIGdjYy1hcm0tbGludXgtZ251ZWFiaQo+Cj5pbiBvcmRlciB0byBnZXQgTGluYXJv
J3MgY3Jvc3MtY29tcGlsZXIuCg==
------=_Part_441978_2009442295.1328705977740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPkhpIFhlbi1BUk1zLDxkaXY+PGJyPjwvZGl2PjxkaXY+SSB1c2Vk
IHRoZSBsYXRlc3QgY29tcGlsZXIgZnJvbSBMaW5hcm8uPC9kaXY+PGRpdj5CdXQgdGhlIGNvbXBp
bGVyIGNhbm5vdCBzdXBwb3J0IG1hcmNoPWFybXY3LWEmbmJzcDthbmQmbmJzcDttY3B1PWNvcnRl
eC1hMTU8YnI+PGJyPlRoZSBlcnJvciBpbmZvcm1hdGlvbiBpcyBsaWtlIHRoaXM6PC9kaXY+PGRp
dj48ZGl2PjxkaXY+bWFrZSAtZiAvaG9tZS9mcmFuay93b3Jrc3BhY2UveGVuL3NyYy94ZW4tYXJt
LXY2L3hlbi9SdWxlcy5tayAtQyBpbmNsdWRlPC9kaXY+PGRpdj5tYWtlWzNdOiBFbnRlcmluZyBk
aXJlY3RvcnkgYC9ob21lL2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2lu
Y2x1ZGUnPC9kaXY+PGRpdj5tYWtlWzNdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGwnLjwv
ZGl2PjxkaXY+bWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL2ZyYW5rL3dvcmtzcGFj
ZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2luY2x1ZGUnPC9kaXY+PGRpdj5tYWtlIC1mIC9ob21l
L2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL1J1bGVzLm1rIC1DIGFyY2gv
YXJtIGFzbS1vZmZzZXRzLnM8L2Rpdj48ZGl2Pm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBg
L2hvbWUvZnJhbmsvd29ya3NwYWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vYXJjaC9hcm0nPC9k
aXY+PGRpdj5hcm0tbGludXgtZ251ZWFiaS1nY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tYXJtIC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9o
b21lL2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2luY2x1ZGUgLW1zb2Z0
LWZsb2F0IC1ub3BpZSAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLW1hcmNoPWFybXY3LWEg
LW1jcHU9Y29ydGV4LWExNSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9ob21lL2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2lu
Y2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5hc20tb2Zmc2V0cy5zLmQgLVMgLW8gYXNtLW9m
ZnNldHMucyBhc20tb2Zmc2V0cy5jPC9kaXY+PGRpdj5hc20tb2Zmc2V0cy5jOjE6MDogZXJyb3I6
IHN3aXRjaCAtbWNwdT1jb3J0ZXgtYTE1IGNvbmZsaWN0cyB3aXRoIC1tYXJjaD1hcm12Ny1hIHN3
aXRjaCBbLVdlcnJvcl08L2Rpdj48ZGl2PmNjMTogYWxsIHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQg
YXMgZXJyb3JzPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48L2Rpdj48ZGl2IGlkPSJk
aXZOZXRlYXNlTWFpbENhcmQiPjwvZGl2PkkgbW9kaWZpZWQgeGVuL2FyY2gvYXJtL1J1bGVzLm1r
IGxpa2UgdGhlIGZvbGxvd2luZywgdGhlIGNvbXBpbGluZyBpcyBPSy48L2Rpdj48ZGl2PjxkaXY+
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9SdWxlcy5tayBiL3hlbi9hcmNoL2FybS9SdWxlcy5t
azwvZGl2PjxkaXY+aW5kZXggMzM2ZTIwOS4uNDA3ZmM4MiAxMDA2NDQ8L2Rpdj48ZGl2Pi0tLSBh
L3hlbi9hcmNoL2FybS9SdWxlcy5tazwvZGl2PjxkaXY+KysrIGIveGVuL2FyY2gvYXJtL1J1bGVz
Lm1rPC9kaXY+PGRpdj5AQCAtMjIsNyArMjIsOCBAQCBpZm5lcSAoJChjYWxsIGNjLW9wdGlvbiwk
KENDKSwtZnZpc2liaWxpdHk9aGlkZGVuLG4pLG4pPC9kaXY+PGRpdj4mbmJzcDtDRkxBR1MgKz0g
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFPC9kaXY+PGRpdj4mbmJzcDtlbmRpZjwvZGl2
PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdj4tQ0ZMQUdTICs9IC1tYXJjaD1hcm12Ny1hIC1tY3B1PWNv
cnRleC1hMTU8L2Rpdj48ZGl2PisjQ0ZMQUdTICs9IC1tYXJjaD1hcm12Ny1hIC1tY3B1PWNvcnRl
eC1hMTU8L2Rpdj48ZGl2PitDRkxBR1MgKz0gLW1jcHU9Y29ydGV4LWExNTwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+SSBjaGVja2VkIGJpbmFyeSBmaWxlIHhlbiwgaXQgZG9lcyBub3QgaGF2ZSB0
aGUgdW5yZXNvbHZlZCBzeW1ib2wuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0IFJlZ2Fy
ZHMsPC9kaXY+PGRpdj5GcmFuazwvZGl2PjxkaXY+LS08L2Rpdj48cHJlPjxicj7lnKgmbmJzcDsy
MDEyLTAyLTA4Jm5ic3A7MTg6MzY6NDjvvIwiU3RlZmFubyZuYnNwO1N0YWJlbGxpbmkiJm5ic3A7
Jmx0O3N0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tJmd0OyZuYnNwO+WGmemBk++8mgom
Z3Q7T24mbmJzcDtNb24sJm5ic3A7NiZuYnNwO0ZlYiZuYnNwOzIwMTIsJm5ic3A7RnJhbmssJm5i
c3A7Q2hlbiZuYnNwO3dyb3RlOgomZ3Q7Jmd0OyZuYnNwO0hpJm5ic3A7WGVuLUFSTXMsCiZndDsm
Z3Q7Jm5ic3A7w4ImbmJzcDsKJmd0OyZndDsmbmJzcDtJJm5ic3A7YXBwbGllZCZuYnNwO3RoaXMm
bmJzcDtwYXRjaCwmbmJzcDsiZXJyb3I6w4ImbmJzcDt1bmtub3duw4ImbmJzcDt0eXBlw4ImbmJz
cDtuYW1lw4ImbmJzcDsneGVuX2NhbGxiYWNrX3QnJm5ic3A7aXMmbmJzcDtmaXhlZC4KJmd0Owom
Z3Q7VGhhbmtzJm5ic3A7Zm9yJm5ic3A7dGVzdGluZyEKJmd0OwomZ3Q7CiZndDsmZ3Q7Jm5ic3A7
QnV0Jm5ic3A7SSZuYnNwO3N0aWxsJm5ic3A7bWVldCZuYnNwO3RoZSZuYnNwO3Byb2JsZW0uJm5i
c3A7VGhlJm5ic3A7cHJvYmxlbSZuYnNwO2lzCiZndDsmZ3Q7Jm5ic3A7d2hlcmUmbmJzcDt0byZu
YnNwO2Rvd25sb2FkJm5ic3A7dGhlJm5ic3A7Y3Jvc3MmbmJzcDtjb21waWxlciZuYnNwOyJhcm0t
bm9uZS1saW51eC1nbnVlYWJpLWdjYyImbmJzcDt3aGljaCZuYnNwO3N1cHBvcnRzJm5ic3A7bWFy
Y2g9YXJtLVY3YSZuYnNwO2FuZCZuYnNwO21jcHU9Y29ydGV4LWExNS4KJmd0OyZndDsmbmJzcDvD
giZuYnNwOwomZ3Q7Jmd0OyZuYnNwO1dvdWxkw4ImbmJzcDtzb21lb25lJm5ic3A7Z2l2ZSZuYnNw
O21lJm5ic3A7b25lJm5ic3A7YXZhaWFibGUmbmJzcDtVUkwmbmJzcDt0byZuYnNwO2Rvd25sb2Fk
Jm5ic3A7dGhlJm5ic3A7cmlnaHQmbmJzcDtjb21waWxlcj/DgiZuYnNwOwomZ3Q7CiZndDtXaGlj
aCZuYnNwO2Nyb3NzLWNvbXBpbGVyJm5ic3A7YXJlJm5ic3A7eW91Jm5ic3A7dXNpbmcmbmJzcDth
dCZuYnNwO3RoZSZuYnNwO21vbWVudD8KJmd0O0lmJm5ic3A7eW91Jm5ic3A7YXJlJm5ic3A7b24m
bmJzcDtVYnVudHUsJm5ic3A7d2UmbmJzcDtqdXN0Jm5ic3A7bmVlZCZuYnNwO3RvCiZndDsKJmd0
O2FwdC1nZXQmbmJzcDtpbnN0YWxsJm5ic3A7Z2NjLWFybS1saW51eC1nbnVlYWJpCiZndDsKJmd0
O2luJm5ic3A7b3JkZXImbmJzcDt0byZuYnNwO2dldCZuYnNwO0xpbmFybydzJm5ic3A7Y3Jvc3Mt
Y29tcGlsZXIuCjwvcHJlPjwvZGl2PjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vm
b290ZXIiPjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_441978_2009442295.1328705977740--



--===============7021684158236404105==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7021684158236404105==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfo-0005xM-8g; Fri, 10 Feb 2012 10:25:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1Rv77v-0007Lx-Iu; Wed, 08 Feb 2012 12:59:59 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328705989!12492534!1
X-Originating-IP: [220.181.13.31]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30265 invoked from network); 8 Feb 2012 12:59:51 -0000
Received: from m13-31.163.com (HELO m13-31.163.com) (220.181.13.31)
	by server-8.tower-174.messagelabs.com with SMTP;
	8 Feb 2012 12:59:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=EzOW42W1Df/VzGb
	z8jW0J2KOwmsCEpDYuqrZ5pZzsvA=; b=VF+jlR2Wo4C5m2WomhJbcTujU4gq5eD
	KlxaDERv/VUjjGSDTc37KPLMVsYk/WApCptqMV3ejcHkhk1EAb9zk9tDGF62W3IY
	+mj1epOD9CxIEx/iEGZmRHj8CiTfZeGhdD9ogfxNRuce4myR9kv+ojmUQ8hbLpuR
	wJOkwLXhtid0=
Received: from chysun2000 ( [117.79.232.253] ) by ajax-webmail-wmsvr31
	(Coremail) ; Wed, 8 Feb 2012 20:59:37 +0800 (CST)
Date: Wed, 8 Feb 2012 20:59:37 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Message-ID: <715c4021.25979.1355d0c3d8d.Coremail.chysun2000@163.com>
In-Reply-To: <alpine.DEB.2.00.1202081035210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1202081035210.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
MIME-Version: 1.0
X-Originating-IP: [117.79.232.253]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: dJNiXGZvb3Rlcl9odG09MzcxNTo4MQ==
X-CM-TRANSID: H8GowGAZwUK5cTJPG14UAA--.1720W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiMRRO6ki42H+2LAAAsM
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7021684158236404105=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7021684158236404105==
Content-Type: multipart/alternative; 
	boundary="----=_Part_441978_2009442295.1328705977740"

------=_Part_441978_2009442295.1328705977740
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SGkgWGVuLUFSTXMsCgoKSSB1c2VkIHRoZSBsYXRlc3QgY29tcGlsZXIgZnJvbSBMaW5hcm8uCkJ1
dCB0aGUgY29tcGlsZXIgY2Fubm90IHN1cHBvcnQgbWFyY2g9YXJtdjctYSBhbmQgbWNwdT1jb3J0
ZXgtYTE1CgpUaGUgZXJyb3IgaW5mb3JtYXRpb24gaXMgbGlrZSB0aGlzOgptYWtlIC1mIC9ob21l
L2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL1J1bGVzLm1rIC1DIGluY2x1
ZGUKbWFrZVszXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvaG9tZS9mcmFuay93b3Jrc3BhY2UveGVu
L3NyYy94ZW4tYXJtLXY2L3hlbi9pbmNsdWRlJwptYWtlWzNdOiBOb3RoaW5nIHRvIGJlIGRvbmUg
Zm9yIGBhbGwnLgptYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL2hvbWUvZnJhbmsvd29ya3Nw
YWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vaW5jbHVkZScKbWFrZSAtZiAvaG9tZS9mcmFuay93
b3Jrc3BhY2UveGVuL3NyYy94ZW4tYXJtLXY2L3hlbi9SdWxlcy5tayAtQyBhcmNoL2FybSBhc20t
b2Zmc2V0cy5zCm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBgL2hvbWUvZnJhbmsvd29ya3Nw
YWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vYXJjaC9hcm0nCmFybS1saW51eC1nbnVlYWJpLWdj
YyAtTzEgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLW1hcm0gLWcgLWZuby1zdHJpY3QtYWxpYXNp
bmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0
ZXItc3RhdGVtZW50IC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgLWZuby1idWlsdGluIC1m
bm8tY29tbW9uIC1XcmVkdW5kYW50LWRlY2xzIC1pd2l0aHByZWZpeCBpbmNsdWRlIC1XZXJyb3Ig
LVduby1wb2ludGVyLWFyaXRoIC1waXBlIC1JL2hvbWUvZnJhbmsvd29ya3NwYWNlL3hlbi9zcmMv
eGVuLWFybS12Ni94ZW4vaW5jbHVkZSAtbXNvZnQtZmxvYXQgLW5vcGllIC1mbm8tc3RhY2stcHJv
dGVjdG9yIC1mbm8tZXhjZXB0aW9ucyAtV25lc3RlZC1leHRlcm5zIC1ER0NDX0hBU19WSVNJQklM
SVRZX0FUVFJJQlVURSAtbWFyY2g9YXJtdjctYSAtbWNwdT1jb3J0ZXgtYTE1IC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscyAtZyAtRF9fWEVOX18gLWluY2x1ZGUgL2hvbWUvZnJhbmsvd29ya3Nw
YWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vaW5jbHVkZS94ZW4vY29uZmlnLmggLURWRVJCT1NF
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1EQ09ORklHX0ZSQU1FX1BPSU5URVIgLU1NRCAtTUYg
LmFzbS1vZmZzZXRzLnMuZCAtUyAtbyBhc20tb2Zmc2V0cy5zIGFzbS1vZmZzZXRzLmMKYXNtLW9m
ZnNldHMuYzoxOjA6IGVycm9yOiBzd2l0Y2ggLW1jcHU9Y29ydGV4LWExNSBjb25mbGljdHMgd2l0
aCAtbWFyY2g9YXJtdjctYSBzd2l0Y2ggWy1XZXJyb3JdCmNjMTogYWxsIHdhcm5pbmdzIGJlaW5n
IHRyZWF0ZWQgYXMgZXJyb3JzCgoKSSBtb2RpZmllZCB4ZW4vYXJjaC9hcm0vUnVsZXMubWsgbGlr
ZSB0aGUgZm9sbG93aW5nLCB0aGUgY29tcGlsaW5nIGlzIE9LLgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL1J1bGVzLm1rIGIveGVuL2FyY2gvYXJtL1J1bGVzLm1rCmluZGV4IDMzNmUyMDkuLjQw
N2ZjODIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL2FybS9SdWxlcy5taworKysgYi94ZW4vYXJjaC9h
cm0vUnVsZXMubWsKQEAgLTIyLDcgKzIyLDggQEAgaWZuZXEgKCQoY2FsbCBjYy1vcHRpb24sJChD
QyksLWZ2aXNpYmlsaXR5PWhpZGRlbixuKSxuKQogQ0ZMQUdTICs9IC1ER0NDX0hBU19WSVNJQklM
SVRZX0FUVFJJQlVURQogZW5kaWYKIAotQ0ZMQUdTICs9IC1tYXJjaD1hcm12Ny1hIC1tY3B1PWNv
cnRleC1hMTUKKyNDRkxBR1MgKz0gLW1hcmNoPWFybXY3LWEgLW1jcHU9Y29ydGV4LWExNQorQ0ZM
QUdTICs9IC1tY3B1PWNvcnRleC1hMTUKCgpJIGNoZWNrZWQgYmluYXJ5IGZpbGUgeGVuLCBpdCBk
b2VzIG5vdCBoYXZlIHRoZSB1bnJlc29sdmVkIHN5bWJvbC4KCgpCZXN0IFJlZ2FyZHMsCkZyYW5r
Ci0tCgrlnKggMjAxMi0wMi0wOCAxODozNjo0OO+8jCJTdGVmYW5vIFN0YWJlbGxpbmkiIDxzdGVm
YW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4g5YaZ6YGT77yaCj5PbiBNb24sIDYgRmViIDIw
MTIsIEZyYW5rLCBDaGVuIHdyb3RlOgo+PiBIaSBYZW4tQVJNcywKPj4gw4IgCj4+IEkgYXBwbGll
ZCB0aGlzIHBhdGNoLCAiZXJyb3I6w4IgdW5rbm93bsOCIHR5cGXDgiBuYW1lw4IgJ3hlbl9jYWxs
YmFja190JyBpcyBmaXhlZC4KPgo+VGhhbmtzIGZvciB0ZXN0aW5nIQo+Cj4KPj4gQnV0IEkgc3Rp
bGwgbWVldCB0aGUgcHJvYmxlbS4gVGhlIHByb2JsZW0gaXMKPj4gd2hlcmUgdG8gZG93bmxvYWQg
dGhlIGNyb3NzIGNvbXBpbGVyICJhcm0tbm9uZS1saW51eC1nbnVlYWJpLWdjYyIgd2hpY2ggc3Vw
cG9ydHMgbWFyY2g9YXJtLVY3YSBhbmQgbWNwdT1jb3J0ZXgtYTE1Lgo+PiDDgiAKPj4gV291bGTD
giBzb21lb25lIGdpdmUgbWUgb25lIGF2YWlhYmxlIFVSTCB0byBkb3dubG9hZCB0aGUgcmlnaHQg
Y29tcGlsZXI/w4IgCj4KPldoaWNoIGNyb3NzLWNvbXBpbGVyIGFyZSB5b3UgdXNpbmcgYXQgdGhl
IG1vbWVudD8KPklmIHlvdSBhcmUgb24gVWJ1bnR1LCB3ZSBqdXN0IG5lZWQgdG8KPgo+YXB0LWdl
dCBpbnN0YWxsIGdjYy1hcm0tbGludXgtZ251ZWFiaQo+Cj5pbiBvcmRlciB0byBnZXQgTGluYXJv
J3MgY3Jvc3MtY29tcGlsZXIuCg==
------=_Part_441978_2009442295.1328705977740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPkhpIFhlbi1BUk1zLDxkaXY+PGJyPjwvZGl2PjxkaXY+SSB1c2Vk
IHRoZSBsYXRlc3QgY29tcGlsZXIgZnJvbSBMaW5hcm8uPC9kaXY+PGRpdj5CdXQgdGhlIGNvbXBp
bGVyIGNhbm5vdCBzdXBwb3J0IG1hcmNoPWFybXY3LWEmbmJzcDthbmQmbmJzcDttY3B1PWNvcnRl
eC1hMTU8YnI+PGJyPlRoZSBlcnJvciBpbmZvcm1hdGlvbiBpcyBsaWtlIHRoaXM6PC9kaXY+PGRp
dj48ZGl2PjxkaXY+bWFrZSAtZiAvaG9tZS9mcmFuay93b3Jrc3BhY2UveGVuL3NyYy94ZW4tYXJt
LXY2L3hlbi9SdWxlcy5tayAtQyBpbmNsdWRlPC9kaXY+PGRpdj5tYWtlWzNdOiBFbnRlcmluZyBk
aXJlY3RvcnkgYC9ob21lL2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2lu
Y2x1ZGUnPC9kaXY+PGRpdj5tYWtlWzNdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGwnLjwv
ZGl2PjxkaXY+bWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL2ZyYW5rL3dvcmtzcGFj
ZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2luY2x1ZGUnPC9kaXY+PGRpdj5tYWtlIC1mIC9ob21l
L2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL1J1bGVzLm1rIC1DIGFyY2gv
YXJtIGFzbS1vZmZzZXRzLnM8L2Rpdj48ZGl2Pm1ha2VbM106IEVudGVyaW5nIGRpcmVjdG9yeSBg
L2hvbWUvZnJhbmsvd29ya3NwYWNlL3hlbi9zcmMveGVuLWFybS12Ni94ZW4vYXJjaC9hcm0nPC9k
aXY+PGRpdj5hcm0tbGludXgtZ251ZWFiaS1nY2MgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVy
IC1tYXJtIC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1zdGQ9Z251OTkgLVdhbGwgLVdzdHJpY3Qt
cHJvdG90eXBlcyAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtV25vLXVudXNlZC1idXQt
c2V0LXZhcmlhYmxlIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1vbiAtV3JlZHVuZGFudC1kZWNscyAt
aXdpdGhwcmVmaXggaW5jbHVkZSAtV2Vycm9yIC1Xbm8tcG9pbnRlci1hcml0aCAtcGlwZSAtSS9o
b21lL2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2luY2x1ZGUgLW1zb2Z0
LWZsb2F0IC1ub3BpZSAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLWV4Y2VwdGlvbnMgLVduZXN0
ZWQtZXh0ZXJucyAtREdDQ19IQVNfVklTSUJJTElUWV9BVFRSSUJVVEUgLW1hcmNoPWFybXY3LWEg
LW1jcHU9Y29ydGV4LWExNSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLWcgLURfX1hFTl9f
IC1pbmNsdWRlIC9ob21lL2ZyYW5rL3dvcmtzcGFjZS94ZW4vc3JjL3hlbi1hcm0tdjYveGVuL2lu
Y2x1ZGUveGVuL2NvbmZpZy5oIC1EVkVSQk9TRSAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtRENP
TkZJR19GUkFNRV9QT0lOVEVSIC1NTUQgLU1GIC5hc20tb2Zmc2V0cy5zLmQgLVMgLW8gYXNtLW9m
ZnNldHMucyBhc20tb2Zmc2V0cy5jPC9kaXY+PGRpdj5hc20tb2Zmc2V0cy5jOjE6MDogZXJyb3I6
IHN3aXRjaCAtbWNwdT1jb3J0ZXgtYTE1IGNvbmZsaWN0cyB3aXRoIC1tYXJjaD1hcm12Ny1hIHN3
aXRjaCBbLVdlcnJvcl08L2Rpdj48ZGl2PmNjMTogYWxsIHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQg
YXMgZXJyb3JzPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48L2Rpdj48ZGl2IGlkPSJk
aXZOZXRlYXNlTWFpbENhcmQiPjwvZGl2PkkgbW9kaWZpZWQgeGVuL2FyY2gvYXJtL1J1bGVzLm1r
IGxpa2UgdGhlIGZvbGxvd2luZywgdGhlIGNvbXBpbGluZyBpcyBPSy48L2Rpdj48ZGl2PjxkaXY+
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9SdWxlcy5tayBiL3hlbi9hcmNoL2FybS9SdWxlcy5t
azwvZGl2PjxkaXY+aW5kZXggMzM2ZTIwOS4uNDA3ZmM4MiAxMDA2NDQ8L2Rpdj48ZGl2Pi0tLSBh
L3hlbi9hcmNoL2FybS9SdWxlcy5tazwvZGl2PjxkaXY+KysrIGIveGVuL2FyY2gvYXJtL1J1bGVz
Lm1rPC9kaXY+PGRpdj5AQCAtMjIsNyArMjIsOCBAQCBpZm5lcSAoJChjYWxsIGNjLW9wdGlvbiwk
KENDKSwtZnZpc2liaWxpdHk9aGlkZGVuLG4pLG4pPC9kaXY+PGRpdj4mbmJzcDtDRkxBR1MgKz0g
LURHQ0NfSEFTX1ZJU0lCSUxJVFlfQVRUUklCVVRFPC9kaXY+PGRpdj4mbmJzcDtlbmRpZjwvZGl2
PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdj4tQ0ZMQUdTICs9IC1tYXJjaD1hcm12Ny1hIC1tY3B1PWNv
cnRleC1hMTU8L2Rpdj48ZGl2PisjQ0ZMQUdTICs9IC1tYXJjaD1hcm12Ny1hIC1tY3B1PWNvcnRl
eC1hMTU8L2Rpdj48ZGl2PitDRkxBR1MgKz0gLW1jcHU9Y29ydGV4LWExNTwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+SSBjaGVja2VkIGJpbmFyeSBmaWxlIHhlbiwgaXQgZG9lcyBub3QgaGF2ZSB0
aGUgdW5yZXNvbHZlZCBzeW1ib2wuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0IFJlZ2Fy
ZHMsPC9kaXY+PGRpdj5GcmFuazwvZGl2PjxkaXY+LS08L2Rpdj48cHJlPjxicj7lnKgmbmJzcDsy
MDEyLTAyLTA4Jm5ic3A7MTg6MzY6NDjvvIwiU3RlZmFubyZuYnNwO1N0YWJlbGxpbmkiJm5ic3A7
Jmx0O3N0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tJmd0OyZuYnNwO+WGmemBk++8mgom
Z3Q7T24mbmJzcDtNb24sJm5ic3A7NiZuYnNwO0ZlYiZuYnNwOzIwMTIsJm5ic3A7RnJhbmssJm5i
c3A7Q2hlbiZuYnNwO3dyb3RlOgomZ3Q7Jmd0OyZuYnNwO0hpJm5ic3A7WGVuLUFSTXMsCiZndDsm
Z3Q7Jm5ic3A7w4ImbmJzcDsKJmd0OyZndDsmbmJzcDtJJm5ic3A7YXBwbGllZCZuYnNwO3RoaXMm
bmJzcDtwYXRjaCwmbmJzcDsiZXJyb3I6w4ImbmJzcDt1bmtub3duw4ImbmJzcDt0eXBlw4ImbmJz
cDtuYW1lw4ImbmJzcDsneGVuX2NhbGxiYWNrX3QnJm5ic3A7aXMmbmJzcDtmaXhlZC4KJmd0Owom
Z3Q7VGhhbmtzJm5ic3A7Zm9yJm5ic3A7dGVzdGluZyEKJmd0OwomZ3Q7CiZndDsmZ3Q7Jm5ic3A7
QnV0Jm5ic3A7SSZuYnNwO3N0aWxsJm5ic3A7bWVldCZuYnNwO3RoZSZuYnNwO3Byb2JsZW0uJm5i
c3A7VGhlJm5ic3A7cHJvYmxlbSZuYnNwO2lzCiZndDsmZ3Q7Jm5ic3A7d2hlcmUmbmJzcDt0byZu
YnNwO2Rvd25sb2FkJm5ic3A7dGhlJm5ic3A7Y3Jvc3MmbmJzcDtjb21waWxlciZuYnNwOyJhcm0t
bm9uZS1saW51eC1nbnVlYWJpLWdjYyImbmJzcDt3aGljaCZuYnNwO3N1cHBvcnRzJm5ic3A7bWFy
Y2g9YXJtLVY3YSZuYnNwO2FuZCZuYnNwO21jcHU9Y29ydGV4LWExNS4KJmd0OyZndDsmbmJzcDvD
giZuYnNwOwomZ3Q7Jmd0OyZuYnNwO1dvdWxkw4ImbmJzcDtzb21lb25lJm5ic3A7Z2l2ZSZuYnNw
O21lJm5ic3A7b25lJm5ic3A7YXZhaWFibGUmbmJzcDtVUkwmbmJzcDt0byZuYnNwO2Rvd25sb2Fk
Jm5ic3A7dGhlJm5ic3A7cmlnaHQmbmJzcDtjb21waWxlcj/DgiZuYnNwOwomZ3Q7CiZndDtXaGlj
aCZuYnNwO2Nyb3NzLWNvbXBpbGVyJm5ic3A7YXJlJm5ic3A7eW91Jm5ic3A7dXNpbmcmbmJzcDth
dCZuYnNwO3RoZSZuYnNwO21vbWVudD8KJmd0O0lmJm5ic3A7eW91Jm5ic3A7YXJlJm5ic3A7b24m
bmJzcDtVYnVudHUsJm5ic3A7d2UmbmJzcDtqdXN0Jm5ic3A7bmVlZCZuYnNwO3RvCiZndDsKJmd0
O2FwdC1nZXQmbmJzcDtpbnN0YWxsJm5ic3A7Z2NjLWFybS1saW51eC1nbnVlYWJpCiZndDsKJmd0
O2luJm5ic3A7b3JkZXImbmJzcDt0byZuYnNwO2dldCZuYnNwO0xpbmFybydzJm5ic3A7Y3Jvc3Mt
Y29tcGlsZXIuCjwvcHJlPjwvZGl2PjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vm
b290ZXIiPjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_441978_2009442295.1328705977740--



--===============7021684158236404105==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7021684158236404105==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfu-0005yV-Mf; Fri, 10 Feb 2012 10:25:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1RvINW-0006oF-B8; Thu, 09 Feb 2012 01:00:50 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328749208!51674493!1
X-Originating-IP: [220.181.13.108]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25613 invoked from network); 9 Feb 2012 01:00:10 -0000
Received: from m13-108.163.com (HELO m13-108.163.com) (220.181.13.108)
	by server-12.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 01:00:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=DmIvZyxTPGrdV5l
	hx0pxiQtVPPzuOCXPTJ5QMFswdck=; b=jHpC3jRswLAJvEV46pp4/2VAy3RmDOc
	qTH5I6hGPzIi/jQ9IAobINAjFQVVhj6/gJa/Lpbk4+DK+ohxgkRbqgrp0JIQTUa9
	Rb7vAxwI/IWK4KH8px1CZ12B3YDfihh+EsmWEcbAXU/PEOM+zpsuRWnWC/8+PhMW
	YByXhA5fAPRk=
Received: from chysun2000 ( [219.142.122.100] ) by ajax-webmail-wmsvr108
	(Coremail) ; Thu, 9 Feb 2012 09:00:38 +0800 (CST)
Date: Thu, 9 Feb 2012 09:00:38 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Message-ID: <38e5794e.42de.1355fa05a3c.Coremail.chysun2000@163.com>
In-Reply-To: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
References: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
MIME-Version: 1.0
X-Originating-IP: [219.142.122.100]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: x8EuRWZvb3Rlcl9odG09MTA0MTo4MQ==
X-CM-TRANSID: bMGowEAJ6UC2GjNPL08WAA--.2969W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiJhZO6kCpn0i8-QACsp
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1832129836271967539=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1832129836271967539==
Content-Type: multipart/alternative; 
	boundary="----=_Part_53732_926248899.1328749238844"

------=_Part_53732_926248899.1328749238844
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi Ian and Xen-ARMs,

I tried this compiler. The compile is OK.

Best Regards,
Frank
--




At 2012-02-09 00:53:08,"Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>On Mon, 2012-02-06 at 01:00 +0000, Frank, Chen wrote:
>> The problem is where to download the cross compiler
>> "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and
>> mcpu=cortex-a15.
>>  
>> Would someone give me one avaiable URL to download the right
>> compiler? 
>
>I use
>http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
>
>Ian.
>
>
>

------=_Part_53732_926248899.1328749238844
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi Ian and Xen-ARMs,<br><br>I tried this compiler. The compile is OK.<br><br>Best Regards,<br>Frank<br>--<br><div></div><div id="divNeteaseMailCard"></div><br><pre><br>At&nbsp;2012-02-09&nbsp;00:53:08,"Ian&nbsp;Campbell"&nbsp;&lt;Ian.Campbell@citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Mon,&nbsp;2012-02-06&nbsp;at&nbsp;01:00&nbsp;+0000,&nbsp;Frank,&nbsp;Chen&nbsp;wrote:
&gt;&gt;&nbsp;The&nbsp;problem&nbsp;is&nbsp;where&nbsp;to&nbsp;download&nbsp;the&nbsp;cross&nbsp;compiler
&gt;&gt;&nbsp;"arm-none-linux-gnueabi-gcc"&nbsp;which&nbsp;supports&nbsp;march=arm-V7a&nbsp;and
&gt;&gt;&nbsp;mcpu=cortex-a15.
&gt;&gt;&nbsp;&nbsp;
&gt;&gt;&nbsp;Would&nbsp;someone&nbsp;give&nbsp;me&nbsp;one&nbsp;avaiable&nbsp;URL&nbsp;to&nbsp;download&nbsp;the&nbsp;right
&gt;&gt;&nbsp;compiler?&nbsp;
&gt;
&gt;I&nbsp;use
&gt;http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
&gt;
&gt;Ian.
&gt;
&gt;
&gt;
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_53732_926248899.1328749238844--



--===============1832129836271967539==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1832129836271967539==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfk-0005ws-Vc; Fri, 10 Feb 2012 10:25:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Ruw5S-0005yp-4A
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 01:12:42 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328663555!12993965!1
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQ1OTY0\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24482 invoked from network); 8 Feb 2012 01:12:35 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-13.tower-216.messagelabs.com with SMTP;
	8 Feb 2012 01:12:35 -0000
Received: from epcpsbge5.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZ1002EZVC3W8F0@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Wed, 08 Feb 2012 10:12:34 +0900 (KST)
Message-id: <0LZ1002G5VCYW8F0@mailout1.samsung.com>
X-AuditID: cbfee60f-b7b41ae0000017a9-6b-4f31cbff3de6
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge5.samsung.com (EPCPMTA) with SMTP id AA.17.06057.FFBC13F4;
	Wed, 08 Feb 2012 10:12:31 +0900 (KST)
Date: Wed, 08 Feb 2012 01:12:31 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: xen-arm@lists.xensource.com, xen-devel@lists.xensource.com
MIME-version: 1.0
X-MTR: 20120208011055731@jm77.ryu
Msgkey: 20120208011055731@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120208011055731@jm77.ryu
X-ParentMTR: 
MIME-version: 1.0
X-Generator: Namo ActiveSquare 7 7.0.0.44
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] Para-virtualized linux kernel release for the Tegra2
	harmony board.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2807787590385738763=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2807787590385738763==
Content-type: text/html; charset=euc-kr
Content-transfer-encoding: base64

PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ
VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciIgaHR0cC1lcXVp
dj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGU+UCB7DQoJTUFSR0lOLVRP
UDogNXB4OyBGT05ULUZBTUlMWTogsby4ssO8LCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDlwdA0KfQ0KVEQgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6ILG8
uLLDvCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkxJIHsN
CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBNQVJHSU4tQk9U
VE9NOiA1cHg7IEZPTlQtU0laRTogOXB0DQp9DQpCT0RZIHsNCglMSU5FLUhFSUdIVDogMS40OyBN
QVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBGT05ULVNJWkU6IDlwdA0K
fQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD1BY3RpdmVTcXVhcmU+
PC9IRUFEPg0KPEJPRFk+DQo8UD4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9QWN0aXZl
U3F1YXJlPldlIGhhdmUgcmVsZWFzZSBhIHJlZmVyZW5jZSBjb2RlIGZvciBhIHBhcmEtdmlydHVh
bGl6ZWQgbGludXgga2VybmVsLjwvUD4NCjxQPjxCUj5Zb3Ugd2lsbCBmaW5kIGl0IG9uICJnaXQ6
Ly94ZW5iaXRzLnhlbi5vcmcvcGVvcGxlL2ptNzdyeXUvbGludXgteGVuLmdpdCI8QlI+PEJSPklu
IGNhc2Ugb2YgeGVuLWFybSBzb3VyY2UsIHBsZWFzZSB2aXNpdCB0byAiZ2l0Oi8veGVuYml0cy54
ZW4ub3JnL3Blb3BsZS9qbTc3cnl1L3hlbi1hcm0uZ2l0IjxCUj48QlI+PEJSPi0gQnVpbGQgSW5z
dHJ1Y3Rpb25zOiAtPEJSPjxCUj4xLiBleHRyYWN0IHJvb3QgZmlsZXN5dGVtIGNvbnRlbnRzIGFz
IGZvbGxvd2luZyhUaGlzIHJlcXVpcmVzIHRoZSByb290IHByaXZpbGVnZSk8QlI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7c3VkbyB0YXIgLXh2cGYgcm9vdGZzX2RvbTAudGFyLmJ6MjxCUj48QlI+
Mi4gY3AgY29uZmlnX2RvbTAgLmNvbmZpZzxCUj48QlI+My4gbWFrZSBBUkNIPWFybTxCUj48QlI+
KiogVHVybiBvbiB0YXJnZXQgYm9hcmQsIGFuZCBkb3dubG9hZCB0aGUgeGVuLWFybSBpbWFnZSh4
ZW4pIGFuZCB0aGUga2VybmVsIGltYWdlKHZtbGludXgub3V0MCkuPEJSPioqIGRvd25sb2FkIGFk
ZHJlc3NlIGlzIDo8QlI+KioqKiogeGVuLWFybSA6IDB4ODAwMDxCUj4qKioqKiBndWVzdCBrZXJu
ZWwgaW1hZ2VzIDogMHgxZTgwMDAwMDxCUj48QlI+LSBib290aW5nIGRvbXUgLTxCUj48QlI+Kiog
VG8gYm9vdCBkb211ICh0aGUgcm9vdGZpbGVzeXN0ZW0gb2YgZG9tMCBhbHJlYWR5IGhhcyBwcmVi
dWlsdCBkb211IGtlcm5lbCBpbWFnZXMsIHNlZSBpbWFnZXMgZGlyZWN0b3J5Lik8QlI+IyBzbWQg
c3RhcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0gc3RhcnQgbGlnaHR3ZWlnaHQ8QlI+
IyB2bSBjcmVhdGUgL2V0Yy94ZW4vZG9tMTxCUj4jIHhlbmNvbnNvbGUgMSZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZsdDs9IFRoaXMgY29tbWFuZCBzd2l0Y2ggY29uc29sZSB0byBkb20gMS48QlI+
PEJSPiogRm9yIGRvbXUgYnVpbGQsIHVzZSBjb25maWdfZG9tdSBjb25maWd1cmF0aW9uIGZpbGUu
PEJSPiogRG9uJ3QgZm9yZ2V0IHRvIGNvcHkgdGhlIHZtbGludXgub3V0MSB0byByb290ZnNfZG9t
MC9pbWFnZXMgZGlyZWN0b3J5IGFmdGVyIGRvbXUga2VybmVsIGJ1aWxkLiA8L1A+DQo8UD4mbmJz
cDs8L1A+PC9CT0RZPjwvSFRNTD48aW1nIHNyYz0naHR0cDovL2V4dC5zYW1zdW5nLm5ldC9tYWls
Y2hlY2svU2VlblRpbWVDaGVja2VyP2RvPTMyZmI4ODQzYzFkZDk2MTYxZDdhMWRiNmVjN2M4MTI5
NzNkZmQ2ODU4YjEyMmFjYmVhMDcxMmRkNjZmMDQ1Y2I2ZDNlOGM3ZmFiYTI0YWU2YjcwNzNmYWMx
OWRhZWQyMmYyNjA1ZWFmMTFmNjUyMmQwNDA3ZDFhMjc4ZmU3MzhkMzI5OGEzMmZlN2MwZjQ4NGNm
ODc4ZjlhMjZjZTE1YTAnIGJvcmRlcj0wIHdpZHRoPTAgaGVpZ2h0PTAgc3R5bGU9J2Rpc3BsYXk6
bm9uZSc+





--===============2807787590385738763==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2807787590385738763==--

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfk-0005ws-Vc; Fri, 10 Feb 2012 10:25:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Ruw5S-0005yp-4A
	for xen-devel@lists.xensource.com; Wed, 08 Feb 2012 01:12:42 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328663555!12993965!1
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQ1OTY0\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24482 invoked from network); 8 Feb 2012 01:12:35 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-13.tower-216.messagelabs.com with SMTP;
	8 Feb 2012 01:12:35 -0000
Received: from epcpsbge5.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZ1002EZVC3W8F0@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Wed, 08 Feb 2012 10:12:34 +0900 (KST)
Message-id: <0LZ1002G5VCYW8F0@mailout1.samsung.com>
X-AuditID: cbfee60f-b7b41ae0000017a9-6b-4f31cbff3de6
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge5.samsung.com (EPCPMTA) with SMTP id AA.17.06057.FFBC13F4;
	Wed, 08 Feb 2012 10:12:31 +0900 (KST)
Date: Wed, 08 Feb 2012 01:12:31 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: xen-arm@lists.xensource.com, xen-devel@lists.xensource.com
MIME-version: 1.0
X-MTR: 20120208011055731@jm77.ryu
Msgkey: 20120208011055731@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120208011055731@jm77.ryu
X-ParentMTR: 
MIME-version: 1.0
X-Generator: Namo ActiveSquare 7 7.0.0.44
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] Para-virtualized linux kernel release for the Tegra2
	harmony board.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2807787590385738763=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2807787590385738763==
Content-type: text/html; charset=euc-kr
Content-transfer-encoding: base64

PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ
VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciIgaHR0cC1lcXVp
dj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGU+UCB7DQoJTUFSR0lOLVRP
UDogNXB4OyBGT05ULUZBTUlMWTogsby4ssO8LCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDlwdA0KfQ0KVEQgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6ILG8
uLLDvCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkxJIHsN
CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBNQVJHSU4tQk9U
VE9NOiA1cHg7IEZPTlQtU0laRTogOXB0DQp9DQpCT0RZIHsNCglMSU5FLUhFSUdIVDogMS40OyBN
QVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBGT05ULVNJWkU6IDlwdA0K
fQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD1BY3RpdmVTcXVhcmU+
PC9IRUFEPg0KPEJPRFk+DQo8UD4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9QWN0aXZl
U3F1YXJlPldlIGhhdmUgcmVsZWFzZSBhIHJlZmVyZW5jZSBjb2RlIGZvciBhIHBhcmEtdmlydHVh
bGl6ZWQgbGludXgga2VybmVsLjwvUD4NCjxQPjxCUj5Zb3Ugd2lsbCBmaW5kIGl0IG9uICJnaXQ6
Ly94ZW5iaXRzLnhlbi5vcmcvcGVvcGxlL2ptNzdyeXUvbGludXgteGVuLmdpdCI8QlI+PEJSPklu
IGNhc2Ugb2YgeGVuLWFybSBzb3VyY2UsIHBsZWFzZSB2aXNpdCB0byAiZ2l0Oi8veGVuYml0cy54
ZW4ub3JnL3Blb3BsZS9qbTc3cnl1L3hlbi1hcm0uZ2l0IjxCUj48QlI+PEJSPi0gQnVpbGQgSW5z
dHJ1Y3Rpb25zOiAtPEJSPjxCUj4xLiBleHRyYWN0IHJvb3QgZmlsZXN5dGVtIGNvbnRlbnRzIGFz
IGZvbGxvd2luZyhUaGlzIHJlcXVpcmVzIHRoZSByb290IHByaXZpbGVnZSk8QlI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7c3VkbyB0YXIgLXh2cGYgcm9vdGZzX2RvbTAudGFyLmJ6MjxCUj48QlI+
Mi4gY3AgY29uZmlnX2RvbTAgLmNvbmZpZzxCUj48QlI+My4gbWFrZSBBUkNIPWFybTxCUj48QlI+
KiogVHVybiBvbiB0YXJnZXQgYm9hcmQsIGFuZCBkb3dubG9hZCB0aGUgeGVuLWFybSBpbWFnZSh4
ZW4pIGFuZCB0aGUga2VybmVsIGltYWdlKHZtbGludXgub3V0MCkuPEJSPioqIGRvd25sb2FkIGFk
ZHJlc3NlIGlzIDo8QlI+KioqKiogeGVuLWFybSA6IDB4ODAwMDxCUj4qKioqKiBndWVzdCBrZXJu
ZWwgaW1hZ2VzIDogMHgxZTgwMDAwMDxCUj48QlI+LSBib290aW5nIGRvbXUgLTxCUj48QlI+Kiog
VG8gYm9vdCBkb211ICh0aGUgcm9vdGZpbGVzeXN0ZW0gb2YgZG9tMCBhbHJlYWR5IGhhcyBwcmVi
dWlsdCBkb211IGtlcm5lbCBpbWFnZXMsIHNlZSBpbWFnZXMgZGlyZWN0b3J5Lik8QlI+IyBzbWQg
c3RhcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0gc3RhcnQgbGlnaHR3ZWlnaHQ8QlI+
IyB2bSBjcmVhdGUgL2V0Yy94ZW4vZG9tMTxCUj4jIHhlbmNvbnNvbGUgMSZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZsdDs9IFRoaXMgY29tbWFuZCBzd2l0Y2ggY29uc29sZSB0byBkb20gMS48QlI+
PEJSPiogRm9yIGRvbXUgYnVpbGQsIHVzZSBjb25maWdfZG9tdSBjb25maWd1cmF0aW9uIGZpbGUu
PEJSPiogRG9uJ3QgZm9yZ2V0IHRvIGNvcHkgdGhlIHZtbGludXgub3V0MSB0byByb290ZnNfZG9t
MC9pbWFnZXMgZGlyZWN0b3J5IGFmdGVyIGRvbXUga2VybmVsIGJ1aWxkLiA8L1A+DQo8UD4mbmJz
cDs8L1A+PC9CT0RZPjwvSFRNTD48aW1nIHNyYz0naHR0cDovL2V4dC5zYW1zdW5nLm5ldC9tYWls
Y2hlY2svU2VlblRpbWVDaGVja2VyP2RvPTMyZmI4ODQzYzFkZDk2MTYxZDdhMWRiNmVjN2M4MTI5
NzNkZmQ2ODU4YjEyMmFjYmVhMDcxMmRkNjZmMDQ1Y2I2ZDNlOGM3ZmFiYTI0YWU2YjcwNzNmYWMx
OWRhZWQyMmYyNjA1ZWFmMTFmNjUyMmQwNDA3ZDFhMjc4ZmU3MzhkMzI5OGEzMmZlN2MwZjQ4NGNm
ODc4ZjlhMjZjZTE1YTAnIGJvcmRlcj0wIHdpZHRoPTAgaGVpZ2h0PTAgc3R5bGU9J2Rpc3BsYXk6
bm9uZSc+





--===============2807787590385738763==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2807787590385738763==--

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfs-0005y0-5w; Fri, 10 Feb 2012 10:25:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1RvI6c-0000gR-5X; Thu, 09 Feb 2012 00:43:22 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328748143!55952898!1
X-Originating-IP: [220.181.13.108]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17899 invoked from network); 9 Feb 2012 00:42:24 -0000
Received: from m13-108.163.com (HELO m13-108.163.com) (220.181.13.108)
	by server-3.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 00:42:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=0J8iYVfaQCVQ3UF
	2OPgYiz7n9NksLUScOjPEsDTdy6A=; b=WMiaxzWZpwuafW8LBXx+UnSbB1DCgSM
	pWX4KkpMwNNLdT6MoPY5ZzLu0SrbMvqnQFrvBK0eC2YB6oBXdL0Q13U8k6UvtbSs
	3A85I70rYynkbux05uQir/z3lhoeMASebVx7gSntqtja4UfWmmFpj1SlK++eeR36
	sB4vHl62tW2U=
Received: from chysun2000 ( [219.142.122.100] ) by ajax-webmail-wmsvr108
	(Coremail) ; Thu, 9 Feb 2012 08:43:06 +0800 (CST)
Date: Thu, 9 Feb 2012 08:43:06 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Message-ID: <6aacb887.3dab.1355f904b92.Coremail.chysun2000@163.com>
In-Reply-To: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
References: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
MIME-Version: 1.0
X-Originating-IP: [219.142.122.100]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: DxPiVGZvb3Rlcl9odG09MTAxNzo4MQ==
X-CM-TRANSID: bMGowECZD0OaFjNPXUcWAA--.2905W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiJhZO6kCpn0i8-QABsq
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7393695581740075256=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7393695581740075256==
Content-Type: multipart/alternative; 
	boundary="----=_Part_50084_1579651192.1328748186513"

------=_Part_50084_1579651192.1328748186513
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi Ian,

Thanks. :-)
I will try it.

Best Regards,
Frank
--




At 2012-02-09 00:53:08,"Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>On Mon, 2012-02-06 at 01:00 +0000, Frank, Chen wrote:
>> The problem is where to download the cross compiler
>> "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and
>> mcpu=cortex-a15.
>>  
>> Would someone give me one avaiable URL to download the right
>> compiler? 
>
>I use
>http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
>
>Ian.
>
>
>

------=_Part_50084_1579651192.1328748186513
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi Ian,<br><br>Thanks. :-) <br>I will try it.<br><br>Best Regards,<br>Frank<br>--<br><div></div><div id="divNeteaseMailCard"></div><br><pre><br>At&nbsp;2012-02-09&nbsp;00:53:08,"Ian&nbsp;Campbell"&nbsp;&lt;Ian.Campbell@citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Mon,&nbsp;2012-02-06&nbsp;at&nbsp;01:00&nbsp;+0000,&nbsp;Frank,&nbsp;Chen&nbsp;wrote:
&gt;&gt;&nbsp;The&nbsp;problem&nbsp;is&nbsp;where&nbsp;to&nbsp;download&nbsp;the&nbsp;cross&nbsp;compiler
&gt;&gt;&nbsp;"arm-none-linux-gnueabi-gcc"&nbsp;which&nbsp;supports&nbsp;march=arm-V7a&nbsp;and
&gt;&gt;&nbsp;mcpu=cortex-a15.
&gt;&gt;&nbsp;&nbsp;
&gt;&gt;&nbsp;Would&nbsp;someone&nbsp;give&nbsp;me&nbsp;one&nbsp;avaiable&nbsp;URL&nbsp;to&nbsp;download&nbsp;the&nbsp;right
&gt;&gt;&nbsp;compiler?&nbsp;
&gt;
&gt;I&nbsp;use
&gt;http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
&gt;
&gt;Ian.
&gt;
&gt;
&gt;
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_50084_1579651192.1328748186513--



--===============7393695581740075256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7393695581740075256==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfs-0005y0-5w; Fri, 10 Feb 2012 10:25:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1RvI6c-0000gR-5X; Thu, 09 Feb 2012 00:43:22 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328748143!55952898!1
X-Originating-IP: [220.181.13.108]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjEzLjEwOCA9PiA0NTY0\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17899 invoked from network); 9 Feb 2012 00:42:24 -0000
Received: from m13-108.163.com (HELO m13-108.163.com) (220.181.13.108)
	by server-3.tower-27.messagelabs.com with SMTP;
	9 Feb 2012 00:42:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=0J8iYVfaQCVQ3UF
	2OPgYiz7n9NksLUScOjPEsDTdy6A=; b=WMiaxzWZpwuafW8LBXx+UnSbB1DCgSM
	pWX4KkpMwNNLdT6MoPY5ZzLu0SrbMvqnQFrvBK0eC2YB6oBXdL0Q13U8k6UvtbSs
	3A85I70rYynkbux05uQir/z3lhoeMASebVx7gSntqtja4UfWmmFpj1SlK++eeR36
	sB4vHl62tW2U=
Received: from chysun2000 ( [219.142.122.100] ) by ajax-webmail-wmsvr108
	(Coremail) ; Thu, 9 Feb 2012 08:43:06 +0800 (CST)
Date: Thu, 9 Feb 2012 08:43:06 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Message-ID: <6aacb887.3dab.1355f904b92.Coremail.chysun2000@163.com>
In-Reply-To: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
References: <1328719988.6133.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
	<615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
MIME-Version: 1.0
X-Originating-IP: [219.142.122.100]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: DxPiVGZvb3Rlcl9odG09MTAxNzo4MQ==
X-CM-TRANSID: bMGowECZD0OaFjNPXUcWAA--.2905W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiJhZO6kCpn0i8-QABsq
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7393695581740075256=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7393695581740075256==
Content-Type: multipart/alternative; 
	boundary="----=_Part_50084_1579651192.1328748186513"

------=_Part_50084_1579651192.1328748186513
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi Ian,

Thanks. :-)
I will try it.

Best Regards,
Frank
--




At 2012-02-09 00:53:08,"Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>On Mon, 2012-02-06 at 01:00 +0000, Frank, Chen wrote:
>> The problem is where to download the cross compiler
>> "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and
>> mcpu=cortex-a15.
>>  
>> Would someone give me one avaiable URL to download the right
>> compiler? 
>
>I use
>http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
>
>Ian.
>
>
>

------=_Part_50084_1579651192.1328748186513
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi Ian,<br><br>Thanks. :-) <br>I will try it.<br><br>Best Regards,<br>Frank<br>--<br><div></div><div id="divNeteaseMailCard"></div><br><pre><br>At&nbsp;2012-02-09&nbsp;00:53:08,"Ian&nbsp;Campbell"&nbsp;&lt;Ian.Campbell@citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Mon,&nbsp;2012-02-06&nbsp;at&nbsp;01:00&nbsp;+0000,&nbsp;Frank,&nbsp;Chen&nbsp;wrote:
&gt;&gt;&nbsp;The&nbsp;problem&nbsp;is&nbsp;where&nbsp;to&nbsp;download&nbsp;the&nbsp;cross&nbsp;compiler
&gt;&gt;&nbsp;"arm-none-linux-gnueabi-gcc"&nbsp;which&nbsp;supports&nbsp;march=arm-V7a&nbsp;and
&gt;&gt;&nbsp;mcpu=cortex-a15.
&gt;&gt;&nbsp;&nbsp;
&gt;&gt;&nbsp;Would&nbsp;someone&nbsp;give&nbsp;me&nbsp;one&nbsp;avaiable&nbsp;URL&nbsp;to&nbsp;download&nbsp;the&nbsp;right
&gt;&gt;&nbsp;compiler?&nbsp;
&gt;
&gt;I&nbsp;use
&gt;http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.0/x86_64-gcc-4.6.0-nolibc_arm-unknown-linux-gnueabi.tar.bz2
&gt;
&gt;Ian.
&gt;
&gt;
&gt;
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_50084_1579651192.1328748186513--



--===============7393695581740075256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7393695581740075256==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfz-00060A-9U; Fri, 10 Feb 2012 10:25:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1Rvn9g-0005So-07
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:52:36 +0000
Received: from [85.158.139.83:23215] by server-9.bemta-5.messagelabs.com id
	C5/7A-23757-3E8E43F4; Fri, 10 Feb 2012 09:52:35 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328867552!14524277!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MjU4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16633 invoked from network); 10 Feb 2012 09:52:34 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 09:52:34 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1Rvn9Y-0005l5-FC from Paul_Brook@mentor.com ;
	Fri, 10 Feb 2012 01:52:28 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 09:52:27 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 9087E6EE46;
	Fri, 10 Feb 2012 09:52:26 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 10 Feb 2012 09:52:25 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100026.40727.paul@codesourcery.com>
	<4F34CF5E.9080106@redhat.com>
In-Reply-To: <4F34CF5E.9080106@redhat.com>
MIME-Version: 1.0
Message-Id: <201202100952.26104.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 09:52:27.0449 (UTC)
	FILETIME=[B26FC290:01CCE7D9]
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/10/2012 01:26 AM, Paul Brook wrote:
> > The reason we have this is because there are bits of code that rely on
> > polling.  IIRC slirp and the floppy DMA engine were the main culprits.
> > qemu_calculate_timeout is an ugly hack to poll at least once a second,
> > allowing the guest to make forward progress when we miss an event.
> 
> At least the floppy DMA engine is fine with it, it uses idle bottom
> halves (which are a hack and could be replaced by timers, but that's not
> relevant now).

I thought idle bottom halves were one of the things that made this timout 
necessary.  How else are they going to get run?

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfi-0005we-Oz; Fri, 10 Feb 2012 10:25:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1RuCwi-0000Wv-Fl; Mon, 06 Feb 2012 01:00:41 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328490006!58564065!1
X-Originating-IP: [220.181.13.4]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15100 invoked from network); 6 Feb 2012 01:00:08 -0000
Received: from m13-4.163.com (HELO m13-4.163.com) (220.181.13.4)
	by server-13.tower-27.messagelabs.com with SMTP;
	6 Feb 2012 01:00:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=lqSQHl/nLG6GHyy
	MibYrhwzZNYpi7cocyXLRRWEfajg=; b=SU2qxFcf9ZM2GxIJhOl4ar60lwy250j
	U6UTl6ir9ZMkKiQGXYGVoSbnAvNTGmS8WX085nFZvvAwmgq4zhbgEN8OlHuJTgQj
	RMF2itUWuo+s6HO7mbHpgWaOQwwtpWY7WSlcD587IKnyhwmR5w7gPPHhohscxOeG
	NPCSy6i/ON24=
Received: from chysun2000 ( [219.142.122.100] ) by ajax-webmail-wmsvr4
	(Coremail) ; Mon, 6 Feb 2012 09:00:20 +0800 (CST)
Date: Mon, 6 Feb 2012 09:00:20 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Message-ID: <615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
In-Reply-To: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Originating-IP: [219.142.122.100]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: 6j1Jz2Zvb3Rlcl9odG09NzE4Njo4MQ==
X-CM-TRANSID: BMGowGAp0UIkJi9POh0PAA--.3026W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiLg5K6k0vMNyBGgADsW
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6694128086188554377=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6694128086188554377==
Content-Type: multipart/alternative; 
	boundary="----=_Part_193452_45161644.1328490020087"

------=_Part_193452_45161644.1328490020087
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi Xen-ARMs,
 
I applied this patch, "error: unknown type name 'xen_callback_t' is fixed. But I still meet the problem. The problem is where to download the cross compiler "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and mcpu=cortex-a15.
 
Would someone give me one avaiable URL to download the right compiler? 

Best Regards,
Frank
--




At 2012-01-31 22:51:29,"Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
>On Tue, 31 Jan 2012, Ian Campbell wrote:
>> > make[3]: Entering directory
>> > `/home/frank/workspace/xen/src/xen-arm-v6/xen/include'
>> > for i in public/callback.h public/dom0_ops.h public/elfnote.h
>> > public/event_channel.h public/features.h public/grant_table.h
>> > public/kexec.h public/mem_event.h public/memory.h public/nmi.h
>> > public/physdev.h public/platform.h public/sched.h public/tmem.h
>> > public/trace.h public/vcpu.h public/version.h public/xen-compat.h
>> > public/xen.h public/xencomm.h public/xenoprof.h public/hvm/e820.h
>> > public/hvm/hvm_info_table.h public/hvm/hvm_op.h public/hvm/ioreq.h
>> > public/hvm/params.h public/io/blkif.h public/io/console.h
>> > public/io/fbif.h public/io/fsif.h public/io/kbdif.h
>> > public/io/libxenvchan.h public/io/netif.h public/io/pciif.h
>> > public/io/protocols.h public/io/ring.h public/io/tpmif.h
>> > public/io/usbif.h public/io/vscsiif.h public/io/xenbus.h
>> > public/io/xs_wire.h; do arm-linux-gnueabi-gcc -ansi -include stdint.h
>> > -Wall -W -Werror -S -o /dev/null -xc $i || exit 1; echo $i; done
>> > >headers.chk.new
>> > public/callback.h:87:5: error: unknown type name 'xen_callback_t'
>> 
>> At this point I get:
>> [ -e include/asm ] || ln -sf asm-arm include/asm
>> make -f /local/scratch/ianc/devel/arm/xen-unstable/xen/Rules.mk -C include
>> make[3]: Entering directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
>> 
>> Aha -- the difference is down to XEN_TARGET_ARCH vs. XEN_COMPILE_ARCH,
>> see towards the end of xen/include/Makefile:
>>         ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>>         ...
>>         all: headers.chk
>>         ...
>> 
>> I'm inferring from the Makefile that:
>> XEN_COMPILE_ARCH == the host architecture -- e.g. the machine you are
>> 	compiling on
>> XEN_TARGET_ARCH == the target architecture -- e.g. the machine you want 
>> 	to run the resulting Xen on.
>> 
>> And indeed if I do a native build on an arm system I see the same error
>> as you do. We'll look at fixing this but in the meantime I suggest you
>> use XEN_TARGET_ARCH and not XEN_COMPILE_ARCH.
>
>The following patch fixes the compile issue (that indeed is due to the
>header files check you pointed out).
>
>---
>
>arm: few missing #define
>
>Few missing #define are the cause of a compile failure with
>XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
>native compilation). This patch fill the gaps.
>
>Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
>diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>index c430cf3..e04c4fd 100644
>--- a/xen/include/public/arch-arm.h
>+++ b/xen/include/public/arch-arm.h
>@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
> 
> struct arch_shared_info { };
> typedef struct arch_shared_info arch_shared_info_t;
>+typedef unsigned long xen_callback_t;
>+
> #endif
> 
> #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
>diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
>index 77bd1bd..0b7a2ea 100644
>--- a/xen/include/public/io/protocols.h
>+++ b/xen/include/public/io/protocols.h
>@@ -26,6 +26,7 @@
> #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
> #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
> #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
>+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
> 
> #if defined(__i386__)
> # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
>@@ -33,6 +34,8 @@
> # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
> #elif defined(__ia64__)
> # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
>+#elif defined(__arm__)
>+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
> #else
> # error arch fixup needed here
> #endif

------=_Part_193452_45161644.1328490020087
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi Xen-ARMs,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I applied this patch, "error:&nbsp;unknown&nbsp;type&nbsp;name&nbsp;'xen_callback_t' is fixed. But I still meet the problem. The problem is where to download the cross compiler "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and mcpu=cortex-a15.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Would&nbsp;someone give me one avaiable URL to download the right compiler?&nbsp;<BR></DIV>
<DIV>Best Regards,</DIV>
<DIV>Frank</DIV>
<DIV>--<BR></DIV>
<DIV></DIV>
<DIV id="divNeteaseMailCard"></DIV>
<DIV><BR></DIV><PRE><BR>At&nbsp;2012-01-31&nbsp;22:51:29,"Stefano&nbsp;Stabellini"&nbsp;&lt;stefano.stabellini@eu.citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Tue,&nbsp;31&nbsp;Jan&nbsp;2012,&nbsp;Ian&nbsp;Campbell&nbsp;wrote:
&gt;&gt;&nbsp;&gt;&nbsp;make[3]:&nbsp;Entering&nbsp;directory
&gt;&gt;&nbsp;&gt;&nbsp;`/home/frank/workspace/xen/src/xen-arm-v6/xen/include'
&gt;&gt;&nbsp;&gt;&nbsp;for&nbsp;i&nbsp;in&nbsp;public/callback.h&nbsp;public/dom0_ops.h&nbsp;public/elfnote.h
&gt;&gt;&nbsp;&gt;&nbsp;public/event_channel.h&nbsp;public/features.h&nbsp;public/grant_table.h
&gt;&gt;&nbsp;&gt;&nbsp;public/kexec.h&nbsp;public/mem_event.h&nbsp;public/memory.h&nbsp;public/nmi.h
&gt;&gt;&nbsp;&gt;&nbsp;public/physdev.h&nbsp;public/platform.h&nbsp;public/sched.h&nbsp;public/tmem.h
&gt;&gt;&nbsp;&gt;&nbsp;public/trace.h&nbsp;public/vcpu.h&nbsp;public/version.h&nbsp;public/xen-compat.h
&gt;&gt;&nbsp;&gt;&nbsp;public/xen.h&nbsp;public/xencomm.h&nbsp;public/xenoprof.h&nbsp;public/hvm/e820.h
&gt;&gt;&nbsp;&gt;&nbsp;public/hvm/hvm_info_table.h&nbsp;public/hvm/hvm_op.h&nbsp;public/hvm/ioreq.h
&gt;&gt;&nbsp;&gt;&nbsp;public/hvm/params.h&nbsp;public/io/blkif.h&nbsp;public/io/console.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/fbif.h&nbsp;public/io/fsif.h&nbsp;public/io/kbdif.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/libxenvchan.h&nbsp;public/io/netif.h&nbsp;public/io/pciif.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/protocols.h&nbsp;public/io/ring.h&nbsp;public/io/tpmif.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/usbif.h&nbsp;public/io/vscsiif.h&nbsp;public/io/xenbus.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/xs_wire.h;&nbsp;do&nbsp;arm-linux-gnueabi-gcc&nbsp;-ansi&nbsp;-include&nbsp;stdint.h
&gt;&gt;&nbsp;&gt;&nbsp;-Wall&nbsp;-W&nbsp;-Werror&nbsp;-S&nbsp;-o&nbsp;/dev/null&nbsp;-xc&nbsp;$i&nbsp;||&nbsp;exit&nbsp;1;&nbsp;echo&nbsp;$i;&nbsp;done
&gt;&gt;&nbsp;&gt;&nbsp;&gt;headers.chk.new
&gt;&gt;&nbsp;&gt;&nbsp;public/callback.h:87:5:&nbsp;error:&nbsp;unknown&nbsp;type&nbsp;name&nbsp;'xen_callback_t'
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;At&nbsp;this&nbsp;point&nbsp;I&nbsp;get:
&gt;&gt;&nbsp;[&nbsp;-e&nbsp;include/asm&nbsp;]&nbsp;||&nbsp;ln&nbsp;-sf&nbsp;asm-arm&nbsp;include/asm
&gt;&gt;&nbsp;make&nbsp;-f&nbsp;/local/scratch/ianc/devel/arm/xen-unstable/xen/Rules.mk&nbsp;-C&nbsp;include
&gt;&gt;&nbsp;make[3]:&nbsp;Entering&nbsp;directory&nbsp;`/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
&gt;&gt;&nbsp;make[3]:&nbsp;Nothing&nbsp;to&nbsp;be&nbsp;done&nbsp;for&nbsp;`all'.
&gt;&gt;&nbsp;make[3]:&nbsp;Leaving&nbsp;directory&nbsp;`/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;Aha&nbsp;--&nbsp;the&nbsp;difference&nbsp;is&nbsp;down&nbsp;to&nbsp;XEN_TARGET_ARCH&nbsp;vs.&nbsp;XEN_COMPILE_ARCH,
&gt;&gt;&nbsp;see&nbsp;towards&nbsp;the&nbsp;end&nbsp;of&nbsp;xen/include/Makefile:
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ifeq&nbsp;($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;all:&nbsp;headers.chk
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;I'm&nbsp;inferring&nbsp;from&nbsp;the&nbsp;Makefile&nbsp;that:
&gt;&gt;&nbsp;XEN_COMPILE_ARCH&nbsp;==&nbsp;the&nbsp;host&nbsp;architecture&nbsp;--&nbsp;e.g.&nbsp;the&nbsp;machine&nbsp;you&nbsp;are
&gt;&gt;&nbsp;	compiling&nbsp;on
&gt;&gt;&nbsp;XEN_TARGET_ARCH&nbsp;==&nbsp;the&nbsp;target&nbsp;architecture&nbsp;--&nbsp;e.g.&nbsp;the&nbsp;machine&nbsp;you&nbsp;want&nbsp;
&gt;&gt;&nbsp;	to&nbsp;run&nbsp;the&nbsp;resulting&nbsp;Xen&nbsp;on.
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;And&nbsp;indeed&nbsp;if&nbsp;I&nbsp;do&nbsp;a&nbsp;native&nbsp;build&nbsp;on&nbsp;an&nbsp;arm&nbsp;system&nbsp;I&nbsp;see&nbsp;the&nbsp;same&nbsp;error
&gt;&gt;&nbsp;as&nbsp;you&nbsp;do.&nbsp;We'll&nbsp;look&nbsp;at&nbsp;fixing&nbsp;this&nbsp;but&nbsp;in&nbsp;the&nbsp;meantime&nbsp;I&nbsp;suggest&nbsp;you
&gt;&gt;&nbsp;use&nbsp;XEN_TARGET_ARCH&nbsp;and&nbsp;not&nbsp;XEN_COMPILE_ARCH.
&gt;
&gt;The&nbsp;following&nbsp;patch&nbsp;fixes&nbsp;the&nbsp;compile&nbsp;issue&nbsp;(that&nbsp;indeed&nbsp;is&nbsp;due&nbsp;to&nbsp;the
&gt;header&nbsp;files&nbsp;check&nbsp;you&nbsp;pointed&nbsp;out).
&gt;
&gt;---
&gt;
&gt;arm:&nbsp;few&nbsp;missing&nbsp;#define
&gt;
&gt;Few&nbsp;missing&nbsp;#define&nbsp;are&nbsp;the&nbsp;cause&nbsp;of&nbsp;a&nbsp;compile&nbsp;failure&nbsp;with
&gt;XEN_TARGET_ARM=arm&nbsp;and&nbsp;XEN_COMPILE_ARM=arm&nbsp;(for&nbsp;example&nbsp;in&nbsp;the&nbsp;case&nbsp;of&nbsp;a
&gt;native&nbsp;compilation).&nbsp;This&nbsp;patch&nbsp;fill&nbsp;the&nbsp;gaps.
&gt;
&gt;Signed-off-by:&nbsp;Stefano&nbsp;Stabellini&nbsp;&lt;stefano.stabellini@eu.citrix.com&gt;
&gt;
&gt;diff&nbsp;--git&nbsp;a/xen/include/public/arch-arm.h&nbsp;b/xen/include/public/arch-arm.h
&gt;index&nbsp;c430cf3..e04c4fd&nbsp;100644
&gt;---&nbsp;a/xen/include/public/arch-arm.h
&gt;+++&nbsp;b/xen/include/public/arch-arm.h
&gt;@@&nbsp;-110,6&nbsp;+110,8&nbsp;@@&nbsp;typedef&nbsp;struct&nbsp;arch_vcpu_info&nbsp;arch_vcpu_info_t;
&gt;&nbsp;
&gt;&nbsp;struct&nbsp;arch_shared_info&nbsp;{&nbsp;};
&gt;&nbsp;typedef&nbsp;struct&nbsp;arch_shared_info&nbsp;arch_shared_info_t;
&gt;+typedef&nbsp;unsigned&nbsp;long&nbsp;xen_callback_t;
&gt;+
&gt;&nbsp;#endif
&gt;&nbsp;
&gt;&nbsp;#endif&nbsp;/*&nbsp;&nbsp;__XEN_PUBLIC_ARCH_ARM_H__&nbsp;*/
&gt;diff&nbsp;--git&nbsp;a/xen/include/public/io/protocols.h&nbsp;b/xen/include/public/io/protocols.h
&gt;index&nbsp;77bd1bd..0b7a2ea&nbsp;100644
&gt;---&nbsp;a/xen/include/public/io/protocols.h
&gt;+++&nbsp;b/xen/include/public/io/protocols.h
&gt;@@&nbsp;-26,6&nbsp;+26,7&nbsp;@@
&gt;&nbsp;#define&nbsp;XEN_IO_PROTO_ABI_X86_32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"x86_32-abi"
&gt;&nbsp;#define&nbsp;XEN_IO_PROTO_ABI_X86_64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"x86_64-abi"
&gt;&nbsp;#define&nbsp;XEN_IO_PROTO_ABI_IA64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"ia64-abi"
&gt;+#define&nbsp;XEN_IO_PROTO_ABI_ARM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"arm-abi"
&gt;&nbsp;
&gt;&nbsp;#if&nbsp;defined(__i386__)
&gt;&nbsp;#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_X86_32
&gt;@@&nbsp;-33,6&nbsp;+34,8&nbsp;@@
&gt;&nbsp;#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_X86_64
&gt;&nbsp;#elif&nbsp;defined(__ia64__)
&gt;&nbsp;#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_IA64
&gt;+#elif&nbsp;defined(__arm__)
&gt;+#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_ARM
&gt;&nbsp;#else
&gt;&nbsp;#&nbsp;error&nbsp;arch&nbsp;fixup&nbsp;needed&nbsp;here
&gt;&nbsp;#endif
</PRE></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_193452_45161644.1328490020087--



--===============6694128086188554377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6694128086188554377==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfj-0005wl-TS; Fri, 10 Feb 2012 10:25:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RuaRf-0003Nf-Bq
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 02:06:11 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328580363!5739352!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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15501 invoked from network); 7 Feb 2012 02:06:04 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 02:06:04 -0000
Received: by vbbfq11 with SMTP id fq11so21026775vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 18:06:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=f/Sjn0E1ApHxffUslQ+jt8dWOnXYXLM5EUYLM0Bn/84=;
	b=GCzAo2G7k74oWVtzDrA1pNgDLXs81kRGW9Rwb3Q26JkcujvZggdciVluZg4Z8fBM7I
	nvM4uMOU/B0Gi+niovjNLQmScNobe8oAB44Q0bLnJJvQIr8fRNDFkQYnRiIOY3Y9Sdzm
	OMIVmXTun/LSXKGe3VsDF1LJXqgFUhbETdbFU=
MIME-Version: 1.0
Received: by 10.52.23.97 with SMTP id l1mr9773765vdf.0.1328580363033; Mon, 06
	Feb 2012 18:06:03 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Mon, 6 Feb 2012 18:06:02 -0800 (PST)
Date: Tue, 7 Feb 2012 10:06:02 +0800
Message-ID: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWH?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Subject: [Xen-devel] Projects for Google Summer of Code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5835946330718300186=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5835946330718300186==
Content-Type: multipart/alternative; boundary=20cf3079bc64981a5804b85638bd

--20cf3079bc64981a5804b85638bd
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I have noticed of some projects in GSoC 2011 supported by Xen.org, and I
would like to know if there will be any projects for GSoC 2012? I want to
apply for a project supported by Xen.org because I use Xen and do research
on it for some time and I have great interest in it. I want to get some
more information about it, thank you.

Chunqi Li

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3079bc64981a5804b85638bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I have noticed of some projects in GSoC 2011 supported by Xen.o=
rg, and I would like to know if there will be any projects for GSoC 2012? I=
 want to apply for a project supported by Xen.org because I use Xen and do =
research on it for some time and I have great interest in it. I want to get=
 some more information about it, thank you.</div>
<div><br></div><div>Chunqi Li<br clear=3D"all"><div><br></div>-- <br>Chunqi=
 Li<br>Department of Computer Science<br>School of EECS<br>Peking Universit=
y<br>Beijing, China<br>
</div>

--20cf3079bc64981a5804b85638bd--


--===============5835946330718300186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5835946330718300186==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfz-00060A-9U; Fri, 10 Feb 2012 10:25:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1Rvn9g-0005So-07
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 09:52:36 +0000
Received: from [85.158.139.83:23215] by server-9.bemta-5.messagelabs.com id
	C5/7A-23757-3E8E43F4; Fri, 10 Feb 2012 09:52:35 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328867552!14524277!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MjU4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16633 invoked from network); 10 Feb 2012 09:52:34 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 09:52:34 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1Rvn9Y-0005l5-FC from Paul_Brook@mentor.com ;
	Fri, 10 Feb 2012 01:52:28 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 09:52:27 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 9087E6EE46;
	Fri, 10 Feb 2012 09:52:26 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 10 Feb 2012 09:52:25 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100026.40727.paul@codesourcery.com>
	<4F34CF5E.9080106@redhat.com>
In-Reply-To: <4F34CF5E.9080106@redhat.com>
MIME-Version: 1.0
Message-Id: <201202100952.26104.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 09:52:27.0449 (UTC)
	FILETIME=[B26FC290:01CCE7D9]
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/10/2012 01:26 AM, Paul Brook wrote:
> > The reason we have this is because there are bits of code that rely on
> > polling.  IIRC slirp and the floppy DMA engine were the main culprits.
> > qemu_calculate_timeout is an ugly hack to poll at least once a second,
> > allowing the guest to make forward progress when we miss an event.
> 
> At least the floppy DMA engine is fine with it, it uses idle bottom
> halves (which are a hack and could be replaced by timers, but that's not
> relevant now).

I thought idle bottom halves were one of the things that made this timout 
necessary.  How else are they going to get run?

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfj-0005wl-TS; Fri, 10 Feb 2012 10:25:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RuaRf-0003Nf-Bq
	for xen-devel@lists.xensource.com; Tue, 07 Feb 2012 02:06:11 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328580363!5739352!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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15501 invoked from network); 7 Feb 2012 02:06:04 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2012 02:06:04 -0000
Received: by vbbfq11 with SMTP id fq11so21026775vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 06 Feb 2012 18:06:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=f/Sjn0E1ApHxffUslQ+jt8dWOnXYXLM5EUYLM0Bn/84=;
	b=GCzAo2G7k74oWVtzDrA1pNgDLXs81kRGW9Rwb3Q26JkcujvZggdciVluZg4Z8fBM7I
	nvM4uMOU/B0Gi+niovjNLQmScNobe8oAB44Q0bLnJJvQIr8fRNDFkQYnRiIOY3Y9Sdzm
	OMIVmXTun/LSXKGe3VsDF1LJXqgFUhbETdbFU=
MIME-Version: 1.0
Received: by 10.52.23.97 with SMTP id l1mr9773765vdf.0.1328580363033; Mon, 06
	Feb 2012 18:06:03 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Mon, 6 Feb 2012 18:06:02 -0800 (PST)
Date: Tue, 7 Feb 2012 10:06:02 +0800
Message-ID: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWH?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Subject: [Xen-devel] Projects for Google Summer of Code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5835946330718300186=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5835946330718300186==
Content-Type: multipart/alternative; boundary=20cf3079bc64981a5804b85638bd

--20cf3079bc64981a5804b85638bd
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I have noticed of some projects in GSoC 2011 supported by Xen.org, and I
would like to know if there will be any projects for GSoC 2012? I want to
apply for a project supported by Xen.org because I use Xen and do research
on it for some time and I have great interest in it. I want to get some
more information about it, thank you.

Chunqi Li

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3079bc64981a5804b85638bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I have noticed of some projects in GSoC 2011 supported by Xen.o=
rg, and I would like to know if there will be any projects for GSoC 2012? I=
 want to apply for a project supported by Xen.org because I use Xen and do =
research on it for some time and I have great interest in it. I want to get=
 some more information about it, thank you.</div>
<div><br></div><div>Chunqi Li<br clear=3D"all"><div><br></div>-- <br>Chunqi=
 Li<br>Department of Computer Science<br>School of EECS<br>Peking Universit=
y<br>Beijing, China<br>
</div>

--20cf3079bc64981a5804b85638bd--


--===============5835946330718300186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5835946330718300186==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:26:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnfi-0005we-Oz; Fri, 10 Feb 2012 10:25:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chysun2000@163.com>)
	id 1RuCwi-0000Wv-Fl; Mon, 06 Feb 2012 01:00:41 +0000
X-Env-Sender: chysun2000@163.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328490006!58564065!1
X-Originating-IP: [220.181.13.4]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15100 invoked from network); 6 Feb 2012 01:00:08 -0000
Received: from m13-4.163.com (HELO m13-4.163.com) (220.181.13.4)
	by server-13.tower-27.messagelabs.com with SMTP;
	6 Feb 2012 01:00:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:In-Reply-To:
	References:Subject:MIME-Version:Content-Type; bh=lqSQHl/nLG6GHyy
	MibYrhwzZNYpi7cocyXLRRWEfajg=; b=SU2qxFcf9ZM2GxIJhOl4ar60lwy250j
	U6UTl6ir9ZMkKiQGXYGVoSbnAvNTGmS8WX085nFZvvAwmgq4zhbgEN8OlHuJTgQj
	RMF2itUWuo+s6HO7mbHpgWaOQwwtpWY7WSlcD587IKnyhwmR5w7gPPHhohscxOeG
	NPCSy6i/ON24=
Received: from chysun2000 ( [219.142.122.100] ) by ajax-webmail-wmsvr4
	(Coremail) ; Mon, 6 Feb 2012 09:00:20 +0800 (CST)
Date: Mon, 6 Feb 2012 09:00:20 +0800 (CST)
From: "Frank, Chen" <chysun2000@163.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Message-ID: <615d9ada.f06d.135502cfcf8.Coremail.chysun2000@163.com>
In-Reply-To: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
	<9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Originating-IP: [219.142.122.100]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 163com
X-CM-CTRLDATA: 6j1Jz2Zvb3Rlcl9odG09NzE4Njo4MQ==
X-CM-TRANSID: BMGowGAp0UIkJi9POh0PAA--.3026W
X-CM-SenderInfo: 5fk123bqsqiii6rwjhhfrp/1tbiLg5K6k0vMNyBGgADsW
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Fri, 10 Feb 2012 10:25:41 +0000
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6694128086188554377=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6694128086188554377==
Content-Type: multipart/alternative; 
	boundary="----=_Part_193452_45161644.1328490020087"

------=_Part_193452_45161644.1328490020087
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi Xen-ARMs,
 
I applied this patch, "error: unknown type name 'xen_callback_t' is fixed. But I still meet the problem. The problem is where to download the cross compiler "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and mcpu=cortex-a15.
 
Would someone give me one avaiable URL to download the right compiler? 

Best Regards,
Frank
--




At 2012-01-31 22:51:29,"Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:
>On Tue, 31 Jan 2012, Ian Campbell wrote:
>> > make[3]: Entering directory
>> > `/home/frank/workspace/xen/src/xen-arm-v6/xen/include'
>> > for i in public/callback.h public/dom0_ops.h public/elfnote.h
>> > public/event_channel.h public/features.h public/grant_table.h
>> > public/kexec.h public/mem_event.h public/memory.h public/nmi.h
>> > public/physdev.h public/platform.h public/sched.h public/tmem.h
>> > public/trace.h public/vcpu.h public/version.h public/xen-compat.h
>> > public/xen.h public/xencomm.h public/xenoprof.h public/hvm/e820.h
>> > public/hvm/hvm_info_table.h public/hvm/hvm_op.h public/hvm/ioreq.h
>> > public/hvm/params.h public/io/blkif.h public/io/console.h
>> > public/io/fbif.h public/io/fsif.h public/io/kbdif.h
>> > public/io/libxenvchan.h public/io/netif.h public/io/pciif.h
>> > public/io/protocols.h public/io/ring.h public/io/tpmif.h
>> > public/io/usbif.h public/io/vscsiif.h public/io/xenbus.h
>> > public/io/xs_wire.h; do arm-linux-gnueabi-gcc -ansi -include stdint.h
>> > -Wall -W -Werror -S -o /dev/null -xc $i || exit 1; echo $i; done
>> > >headers.chk.new
>> > public/callback.h:87:5: error: unknown type name 'xen_callback_t'
>> 
>> At this point I get:
>> [ -e include/asm ] || ln -sf asm-arm include/asm
>> make -f /local/scratch/ianc/devel/arm/xen-unstable/xen/Rules.mk -C include
>> make[3]: Entering directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
>> make[3]: Nothing to be done for `all'.
>> make[3]: Leaving directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
>> 
>> Aha -- the difference is down to XEN_TARGET_ARCH vs. XEN_COMPILE_ARCH,
>> see towards the end of xen/include/Makefile:
>>         ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>>         ...
>>         all: headers.chk
>>         ...
>> 
>> I'm inferring from the Makefile that:
>> XEN_COMPILE_ARCH == the host architecture -- e.g. the machine you are
>> 	compiling on
>> XEN_TARGET_ARCH == the target architecture -- e.g. the machine you want 
>> 	to run the resulting Xen on.
>> 
>> And indeed if I do a native build on an arm system I see the same error
>> as you do. We'll look at fixing this but in the meantime I suggest you
>> use XEN_TARGET_ARCH and not XEN_COMPILE_ARCH.
>
>The following patch fixes the compile issue (that indeed is due to the
>header files check you pointed out).
>
>---
>
>arm: few missing #define
>
>Few missing #define are the cause of a compile failure with
>XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
>native compilation). This patch fill the gaps.
>
>Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
>diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>index c430cf3..e04c4fd 100644
>--- a/xen/include/public/arch-arm.h
>+++ b/xen/include/public/arch-arm.h
>@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
> 
> struct arch_shared_info { };
> typedef struct arch_shared_info arch_shared_info_t;
>+typedef unsigned long xen_callback_t;
>+
> #endif
> 
> #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
>diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
>index 77bd1bd..0b7a2ea 100644
>--- a/xen/include/public/io/protocols.h
>+++ b/xen/include/public/io/protocols.h
>@@ -26,6 +26,7 @@
> #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
> #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
> #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
>+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
> 
> #if defined(__i386__)
> # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
>@@ -33,6 +34,8 @@
> # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
> #elif defined(__ia64__)
> # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
>+#elif defined(__arm__)
>+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
> #else
> # error arch fixup needed here
> #endif

------=_Part_193452_45161644.1328490020087
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi Xen-ARMs,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I applied this patch, "error:&nbsp;unknown&nbsp;type&nbsp;name&nbsp;'xen_callback_t' is fixed. But I still meet the problem. The problem is where to download the cross compiler "arm-none-linux-gnueabi-gcc" which supports march=arm-V7a and mcpu=cortex-a15.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Would&nbsp;someone give me one avaiable URL to download the right compiler?&nbsp;<BR></DIV>
<DIV>Best Regards,</DIV>
<DIV>Frank</DIV>
<DIV>--<BR></DIV>
<DIV></DIV>
<DIV id="divNeteaseMailCard"></DIV>
<DIV><BR></DIV><PRE><BR>At&nbsp;2012-01-31&nbsp;22:51:29,"Stefano&nbsp;Stabellini"&nbsp;&lt;stefano.stabellini@eu.citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Tue,&nbsp;31&nbsp;Jan&nbsp;2012,&nbsp;Ian&nbsp;Campbell&nbsp;wrote:
&gt;&gt;&nbsp;&gt;&nbsp;make[3]:&nbsp;Entering&nbsp;directory
&gt;&gt;&nbsp;&gt;&nbsp;`/home/frank/workspace/xen/src/xen-arm-v6/xen/include'
&gt;&gt;&nbsp;&gt;&nbsp;for&nbsp;i&nbsp;in&nbsp;public/callback.h&nbsp;public/dom0_ops.h&nbsp;public/elfnote.h
&gt;&gt;&nbsp;&gt;&nbsp;public/event_channel.h&nbsp;public/features.h&nbsp;public/grant_table.h
&gt;&gt;&nbsp;&gt;&nbsp;public/kexec.h&nbsp;public/mem_event.h&nbsp;public/memory.h&nbsp;public/nmi.h
&gt;&gt;&nbsp;&gt;&nbsp;public/physdev.h&nbsp;public/platform.h&nbsp;public/sched.h&nbsp;public/tmem.h
&gt;&gt;&nbsp;&gt;&nbsp;public/trace.h&nbsp;public/vcpu.h&nbsp;public/version.h&nbsp;public/xen-compat.h
&gt;&gt;&nbsp;&gt;&nbsp;public/xen.h&nbsp;public/xencomm.h&nbsp;public/xenoprof.h&nbsp;public/hvm/e820.h
&gt;&gt;&nbsp;&gt;&nbsp;public/hvm/hvm_info_table.h&nbsp;public/hvm/hvm_op.h&nbsp;public/hvm/ioreq.h
&gt;&gt;&nbsp;&gt;&nbsp;public/hvm/params.h&nbsp;public/io/blkif.h&nbsp;public/io/console.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/fbif.h&nbsp;public/io/fsif.h&nbsp;public/io/kbdif.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/libxenvchan.h&nbsp;public/io/netif.h&nbsp;public/io/pciif.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/protocols.h&nbsp;public/io/ring.h&nbsp;public/io/tpmif.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/usbif.h&nbsp;public/io/vscsiif.h&nbsp;public/io/xenbus.h
&gt;&gt;&nbsp;&gt;&nbsp;public/io/xs_wire.h;&nbsp;do&nbsp;arm-linux-gnueabi-gcc&nbsp;-ansi&nbsp;-include&nbsp;stdint.h
&gt;&gt;&nbsp;&gt;&nbsp;-Wall&nbsp;-W&nbsp;-Werror&nbsp;-S&nbsp;-o&nbsp;/dev/null&nbsp;-xc&nbsp;$i&nbsp;||&nbsp;exit&nbsp;1;&nbsp;echo&nbsp;$i;&nbsp;done
&gt;&gt;&nbsp;&gt;&nbsp;&gt;headers.chk.new
&gt;&gt;&nbsp;&gt;&nbsp;public/callback.h:87:5:&nbsp;error:&nbsp;unknown&nbsp;type&nbsp;name&nbsp;'xen_callback_t'
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;At&nbsp;this&nbsp;point&nbsp;I&nbsp;get:
&gt;&gt;&nbsp;[&nbsp;-e&nbsp;include/asm&nbsp;]&nbsp;||&nbsp;ln&nbsp;-sf&nbsp;asm-arm&nbsp;include/asm
&gt;&gt;&nbsp;make&nbsp;-f&nbsp;/local/scratch/ianc/devel/arm/xen-unstable/xen/Rules.mk&nbsp;-C&nbsp;include
&gt;&gt;&nbsp;make[3]:&nbsp;Entering&nbsp;directory&nbsp;`/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
&gt;&gt;&nbsp;make[3]:&nbsp;Nothing&nbsp;to&nbsp;be&nbsp;done&nbsp;for&nbsp;`all'.
&gt;&gt;&nbsp;make[3]:&nbsp;Leaving&nbsp;directory&nbsp;`/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;Aha&nbsp;--&nbsp;the&nbsp;difference&nbsp;is&nbsp;down&nbsp;to&nbsp;XEN_TARGET_ARCH&nbsp;vs.&nbsp;XEN_COMPILE_ARCH,
&gt;&gt;&nbsp;see&nbsp;towards&nbsp;the&nbsp;end&nbsp;of&nbsp;xen/include/Makefile:
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ifeq&nbsp;($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;all:&nbsp;headers.chk
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;I'm&nbsp;inferring&nbsp;from&nbsp;the&nbsp;Makefile&nbsp;that:
&gt;&gt;&nbsp;XEN_COMPILE_ARCH&nbsp;==&nbsp;the&nbsp;host&nbsp;architecture&nbsp;--&nbsp;e.g.&nbsp;the&nbsp;machine&nbsp;you&nbsp;are
&gt;&gt;&nbsp;	compiling&nbsp;on
&gt;&gt;&nbsp;XEN_TARGET_ARCH&nbsp;==&nbsp;the&nbsp;target&nbsp;architecture&nbsp;--&nbsp;e.g.&nbsp;the&nbsp;machine&nbsp;you&nbsp;want&nbsp;
&gt;&gt;&nbsp;	to&nbsp;run&nbsp;the&nbsp;resulting&nbsp;Xen&nbsp;on.
&gt;&gt;&nbsp;
&gt;&gt;&nbsp;And&nbsp;indeed&nbsp;if&nbsp;I&nbsp;do&nbsp;a&nbsp;native&nbsp;build&nbsp;on&nbsp;an&nbsp;arm&nbsp;system&nbsp;I&nbsp;see&nbsp;the&nbsp;same&nbsp;error
&gt;&gt;&nbsp;as&nbsp;you&nbsp;do.&nbsp;We'll&nbsp;look&nbsp;at&nbsp;fixing&nbsp;this&nbsp;but&nbsp;in&nbsp;the&nbsp;meantime&nbsp;I&nbsp;suggest&nbsp;you
&gt;&gt;&nbsp;use&nbsp;XEN_TARGET_ARCH&nbsp;and&nbsp;not&nbsp;XEN_COMPILE_ARCH.
&gt;
&gt;The&nbsp;following&nbsp;patch&nbsp;fixes&nbsp;the&nbsp;compile&nbsp;issue&nbsp;(that&nbsp;indeed&nbsp;is&nbsp;due&nbsp;to&nbsp;the
&gt;header&nbsp;files&nbsp;check&nbsp;you&nbsp;pointed&nbsp;out).
&gt;
&gt;---
&gt;
&gt;arm:&nbsp;few&nbsp;missing&nbsp;#define
&gt;
&gt;Few&nbsp;missing&nbsp;#define&nbsp;are&nbsp;the&nbsp;cause&nbsp;of&nbsp;a&nbsp;compile&nbsp;failure&nbsp;with
&gt;XEN_TARGET_ARM=arm&nbsp;and&nbsp;XEN_COMPILE_ARM=arm&nbsp;(for&nbsp;example&nbsp;in&nbsp;the&nbsp;case&nbsp;of&nbsp;a
&gt;native&nbsp;compilation).&nbsp;This&nbsp;patch&nbsp;fill&nbsp;the&nbsp;gaps.
&gt;
&gt;Signed-off-by:&nbsp;Stefano&nbsp;Stabellini&nbsp;&lt;stefano.stabellini@eu.citrix.com&gt;
&gt;
&gt;diff&nbsp;--git&nbsp;a/xen/include/public/arch-arm.h&nbsp;b/xen/include/public/arch-arm.h
&gt;index&nbsp;c430cf3..e04c4fd&nbsp;100644
&gt;---&nbsp;a/xen/include/public/arch-arm.h
&gt;+++&nbsp;b/xen/include/public/arch-arm.h
&gt;@@&nbsp;-110,6&nbsp;+110,8&nbsp;@@&nbsp;typedef&nbsp;struct&nbsp;arch_vcpu_info&nbsp;arch_vcpu_info_t;
&gt;&nbsp;
&gt;&nbsp;struct&nbsp;arch_shared_info&nbsp;{&nbsp;};
&gt;&nbsp;typedef&nbsp;struct&nbsp;arch_shared_info&nbsp;arch_shared_info_t;
&gt;+typedef&nbsp;unsigned&nbsp;long&nbsp;xen_callback_t;
&gt;+
&gt;&nbsp;#endif
&gt;&nbsp;
&gt;&nbsp;#endif&nbsp;/*&nbsp;&nbsp;__XEN_PUBLIC_ARCH_ARM_H__&nbsp;*/
&gt;diff&nbsp;--git&nbsp;a/xen/include/public/io/protocols.h&nbsp;b/xen/include/public/io/protocols.h
&gt;index&nbsp;77bd1bd..0b7a2ea&nbsp;100644
&gt;---&nbsp;a/xen/include/public/io/protocols.h
&gt;+++&nbsp;b/xen/include/public/io/protocols.h
&gt;@@&nbsp;-26,6&nbsp;+26,7&nbsp;@@
&gt;&nbsp;#define&nbsp;XEN_IO_PROTO_ABI_X86_32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"x86_32-abi"
&gt;&nbsp;#define&nbsp;XEN_IO_PROTO_ABI_X86_64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"x86_64-abi"
&gt;&nbsp;#define&nbsp;XEN_IO_PROTO_ABI_IA64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"ia64-abi"
&gt;+#define&nbsp;XEN_IO_PROTO_ABI_ARM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"arm-abi"
&gt;&nbsp;
&gt;&nbsp;#if&nbsp;defined(__i386__)
&gt;&nbsp;#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_X86_32
&gt;@@&nbsp;-33,6&nbsp;+34,8&nbsp;@@
&gt;&nbsp;#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_X86_64
&gt;&nbsp;#elif&nbsp;defined(__ia64__)
&gt;&nbsp;#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_IA64
&gt;+#elif&nbsp;defined(__arm__)
&gt;+#&nbsp;define&nbsp;XEN_IO_PROTO_ABI_NATIVE&nbsp;XEN_IO_PROTO_ABI_ARM
&gt;&nbsp;#else
&gt;&nbsp;#&nbsp;error&nbsp;arch&nbsp;fixup&nbsp;needed&nbsp;here
&gt;&nbsp;#endif
</PRE></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_193452_45161644.1328490020087--



--===============6694128086188554377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6694128086188554377==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:42:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10: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.xensource.com>)
	id 1Rvnva-0000qu-6f; Fri, 10 Feb 2012 10:42:06 +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 1RvnvY-0000qU-JI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 10:42:04 +0000
Received: from [85.158.139.83:55832] by server-10.bemta-5.messagelabs.com id
	4F/AF-26909-974F43F4; Fri, 10 Feb 2012 10:42:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328870521!13913165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16444 invoked from network); 10 Feb 2012 10:42:01 -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;
	10 Feb 2012 10:42:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10617956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 10:42:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 10:42:01 +0000
Date: Fri, 10 Feb 2012 10:45:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Teck Choon Giam wrote:
> Hi,
> 
> I need to check whether is this intended?  When using xl create hvm
> domains, it does execute vif-bridge script.  However, when doing xl
> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
> script.  I just did the following to test:
> 
> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
> #!/bin/bash
> echo "$@" >> vif-bridge.log
> /etc/xen/scripts/vif-bridge.orig "$@"
> EOF
> 
> When using xm and xl to create hvmdomain, I can see vif-bridge.log
> appended with:
> 
> online type_if=vif
> online type_if=vif
> add type_if=tap
> add type_if=tap
> 
> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
> gets to execute vif-bridge once for each vif which looks right.
> 
> Now the problem is xl trigger hvmdomain power and xl destroy power.
> Both never call vif-bridge script as there isn't any such line like:
> 
> offline type_if=vif
> offline type_if=vif
> 
> Whereby when I tried with xm trigger hvmdomain power, it does call
> vif-bridge script as the above two lines get logged.
> 
> This will leave the iptables FORWARD rule intact when using xl which I
> reported before :(
> 
> See http://www.gossamer-threads.com/lists/xen/devel/204990

Actually I have just run the same test but I didn't see any issues:
vif-bridge gets called correctly when the domain dies.

It is difficult to tell what is going wrong in your case because
vif-bridge is not called directly by XL (or Xend), it is called by
vif-setup, that is called by udev when the vif network interface is
destroyed.
I suggest you check that your udev scripts are correct
(/etc/udev/rules.d/xen-backend.rules).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:42:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10: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.xensource.com>)
	id 1Rvnva-0000qu-6f; Fri, 10 Feb 2012 10:42:06 +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 1RvnvY-0000qU-JI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 10:42:04 +0000
Received: from [85.158.139.83:55832] by server-10.bemta-5.messagelabs.com id
	4F/AF-26909-974F43F4; Fri, 10 Feb 2012 10:42:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328870521!13913165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16444 invoked from network); 10 Feb 2012 10:42:01 -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;
	10 Feb 2012 10:42:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10617956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 10:42:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 10:42:01 +0000
Date: Fri, 10 Feb 2012 10:45:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 9 Feb 2012, Teck Choon Giam wrote:
> Hi,
> 
> I need to check whether is this intended?  When using xl create hvm
> domains, it does execute vif-bridge script.  However, when doing xl
> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
> script.  I just did the following to test:
> 
> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
> #!/bin/bash
> echo "$@" >> vif-bridge.log
> /etc/xen/scripts/vif-bridge.orig "$@"
> EOF
> 
> When using xm and xl to create hvmdomain, I can see vif-bridge.log
> appended with:
> 
> online type_if=vif
> online type_if=vif
> add type_if=tap
> add type_if=tap
> 
> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
> gets to execute vif-bridge once for each vif which looks right.
> 
> Now the problem is xl trigger hvmdomain power and xl destroy power.
> Both never call vif-bridge script as there isn't any such line like:
> 
> offline type_if=vif
> offline type_if=vif
> 
> Whereby when I tried with xm trigger hvmdomain power, it does call
> vif-bridge script as the above two lines get logged.
> 
> This will leave the iptables FORWARD rule intact when using xl which I
> reported before :(
> 
> See http://www.gossamer-threads.com/lists/xen/devel/204990

Actually I have just run the same test but I didn't see any issues:
vif-bridge gets called correctly when the domain dies.

It is difficult to tell what is going wrong in your case because
vif-bridge is not called directly by XL (or Xend), it is called by
vif-setup, that is called by udev when the vif network interface is
destroyed.
I suggest you check that your udev scripts are correct
(/etc/udev/rules.d/xen-backend.rules).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:46:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnzc-000163-SY; Fri, 10 Feb 2012 10:46:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Rvnzb-00015i-Du
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 10:46:15 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328870768!14127790!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9973 invoked from network); 10 Feb 2012 10:46:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 10:46:09 -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 q1AAk2a7021715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 05:46:02 -0500
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 q1AAk0JS016064; Fri, 10 Feb 2012 05:46:00 -0500
Message-ID: <4F34F567.3040309@redhat.com>
Date: Fri, 10 Feb 2012 11:45:59 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Paul Brook <paul@codesourcery.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100026.40727.paul@codesourcery.com>
	<4F34CF5E.9080106@redhat.com>
	<201202100952.26104.paul@codesourcery.com>
In-Reply-To: <201202100952.26104.paul@codesourcery.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 10:52 AM, Paul Brook wrote:
>> >  At least the floppy DMA engine is fine with it, it uses idle bottom
>> >  halves (which are a hack and could be replaced by timers, but that's not
>> >  relevant now).
> I thought idle bottom halves were one of the things that made this timout
> necessary.  How else are they going to get run?

The timeout is reduced to 10 ms when an idle bottom half is scheduled. 
See qemu_bh_update_timeout in async.c.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 10:46:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 10:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvnzc-000163-SY; Fri, 10 Feb 2012 10:46:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Rvnzb-00015i-Du
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 10:46:15 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328870768!14127790!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9973 invoked from network); 10 Feb 2012 10:46:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 10:46:09 -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 q1AAk2a7021715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 05:46:02 -0500
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 q1AAk0JS016064; Fri, 10 Feb 2012 05:46:00 -0500
Message-ID: <4F34F567.3040309@redhat.com>
Date: Fri, 10 Feb 2012 11:45:59 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Paul Brook <paul@codesourcery.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100026.40727.paul@codesourcery.com>
	<4F34CF5E.9080106@redhat.com>
	<201202100952.26104.paul@codesourcery.com>
In-Reply-To: <201202100952.26104.paul@codesourcery.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 10:52 AM, Paul Brook wrote:
>> >  At least the floppy DMA engine is fine with it, it uses idle bottom
>> >  halves (which are a hack and could be replaced by timers, but that's not
>> >  relevant now).
> I thought idle bottom halves were one of the things that made this timout
> necessary.  How else are they going to get run?

The timeout is reduced to 10 ms when an idle bottom half is scheduled. 
See qemu_bh_update_timeout in async.c.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:06:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvoJH-0001UQ-Qs; Fri, 10 Feb 2012 11:06:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RvoJG-0001UL-HI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:06:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328871986!13759375!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21594 invoked from network); 10 Feb 2012 11:06:28 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:06:28 -0000
Received: by obcuy19 with SMTP id uy19so11597019obc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 03:06:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=vZsCB05TnEiZqi52ZPhH68dihBi57iXTDGn9Sqy02k4=;
	b=UHwMemM0dMidK05KyNXUjgDwD6XtMmaVIEuNBuidoVZ2eu3spFH1sR55kVHRrIytPI
	H6OuIzxx4R8Ml4L9VDGxJVb9CqN64snA+ZtrDyxNjeS2KtoxmmyWYIiGgXLb0jUM2sT+
	XXTWwc8rH2bnanXJ/uJVSvpopQZ1dZSdRw/sQ=
MIME-Version: 1.0
Received: by 10.50.203.33 with SMTP id kn1mr3357827igc.1.1328871986214; Fri,
	10 Feb 2012 03:06:26 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Fri, 10 Feb 2012 03:06:26 -0800 (PST)
Date: Fri, 10 Feb 2012 11:06:26 +0000
X-Google-Sender-Auth: SJG7k_WPqRUO05j7hzg_0gyUWSc
Message-ID: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com, 
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Jackson <ian.jackson@xen.org>
Content-Type: multipart/mixed; boundary=14dae934038bb0b60804b89a1e3c
Subject: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
	graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--14dae934038bb0b60804b89a1e3c
Content-Type: text/plain; charset=ISO-8859-1

A recent changeset introduced a bug whereby an initialization function
that reads /proc/bus/pci is called from graphics set-up functions
even if pass-through graphics are not enabled.  If qemu is run without
permission to this file, this causes qemu to fail during initialization.

This patch changes the initialization functions to only happen if graphics
pass-through are enabled.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

--14dae934038bb0b60804b89a1e3c
Content-Type: text/x-diff; charset=US-ASCII; name="fix-intel_pch_init.diff"
Content-Disposition: attachment; filename="fix-intel_pch_init.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyh40mln0

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgNmVmZWZmOTE0NjA5YTM4NzBlMmQwN2E4ZDcz
YTI2YzQ2MTVhYzYwYgpxZW11OiBEb24ndCBhY2Nlc3MgL3Byb2MvYnVzL3BjaSB1bmxlc3MgZ3Jh
cGhpY3MgcGFzcy10aHJ1IGlzIGVuYWJsZWQKCkEgcmVjZW50IGNoYW5nZXNldCBpbnRyb2R1Y2Vk
IGEgYnVnIHdoZXJlYnkgYW4gaW5pdGlhbGl6YXRpb24gZnVuY3Rpb24KdGhhdCByZWFkcyAvcHJv
Yy9idXMvcGNpIGlzIGNhbGxlZCBmcm9tIGdyYXBoaWNzIHNldC11cCBmdW5jdGlvbnMKZXZlbiBp
ZiBwYXNzLXRocm91Z2ggZ3JhcGhpY3MgYXJlIG5vdCBlbmFibGVkLiAgSWYgcWVtdSBpcyBydW4g
d2l0aG91dApwZXJtaXNzaW9uIHRvIHRoaXMgZmlsZSwgdGhpcyBjYXVzZXMgcWVtdSB0byBmYWls
IGR1cmluZyBpbml0aWFsaXphdGlvbi4KClRoaXMgcGF0Y2ggY2hhbmdlcyB0aGUgaW5pdGlhbGl6
YXRpb24gZnVuY3Rpb25zIHRvIG9ubHkgaGFwcGVuIGlmIGdyYXBoaWNzCnBhc3MtdGhyb3VnaCBh
cmUgZW5hYmxlZC4KClNpZ25lZC1vZmYtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBA
ZXUuY2l0cml4LmNvbT4KCmRpZmYgLXIgNmVmZWZmOTE0NjA5IGh3L3B0LWdyYXBoaWNzLmMKLS0t
IGEvaHcvcHQtZ3JhcGhpY3MuYwlGcmkgRmViIDEwIDExOjAyOjI1IDIwMTIgKzAwMDAKKysrIGIv
aHcvcHQtZ3JhcGhpY3MuYwlGcmkgRmViIDEwIDExOjA0OjAxIDIwMTIgKzAwMDAKQEAgLTIzLDkg
KzIzLDkgQEAgdm9pZCBpbnRlbF9wY2hfaW5pdChQQ0lCdXMgKmJ1cykKIHsKICAgICB1aW50MTZf
dCB2aWQsIGRpZDsKICAgICB1aW50OF90ICByaWQ7Ci0gICAgc3RydWN0IHBjaV9kZXYgKnBjaV9k
ZXZfMWYgPSBwdF9wY2lfZ2V0X2RldigwLCAweDFmLCAwKTsKKyAgICBzdHJ1Y3QgcGNpX2RldiAq
cGNpX2Rldl8xZjsKIAotICAgIGlmICggIWdmeF9wYXNzdGhydSB8fCAhcGNpX2Rldl8xZiApCisg
ICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8ICEocGNpX2Rldl8xZj1wdF9wY2lfZ2V0X2RldigwLCAw
eDFmLCAwKSkgKQogICAgICAgICByZXR1cm47CiAKICAgICB2aWQgPSBwdF9wY2lfaG9zdF9yZWFk
KHBjaV9kZXZfMWYsIFBDSV9WRU5ET1JfSUQsIDIpOwpAQCAtMzksOSArMzksOSBAQCB2b2lkIGlu
dGVsX3BjaF9pbml0KFBDSUJ1cyAqYnVzKQogCiB2b2lkIGlnZF9wY2lfd3JpdGUoUENJRGV2aWNl
ICpwY2lfZGV2LCB1aW50MzJfdCBjb25maWdfYWRkciwgdWludDMyX3QgdmFsLCBpbnQgbGVuKQog
ewotICAgIHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2X2hvc3RfYnJpZGdlID0gcHRfcGNpX2dldF9k
ZXYoMCwgMCwgMCk7CisgICAgc3RydWN0IHBjaV9kZXYgKnBjaV9kZXZfaG9zdF9icmlkZ2U7CiAg
ICAgYXNzZXJ0KHBjaV9kZXYtPmRldmZuID09IDB4MDApOwotICAgIGlmICggIWlnZF9wYXNzdGhy
dSApIHsKKyAgICBpZiAoICFpZ2RfcGFzc3RocnUgfHwgIShwY2lfZGV2X2hvc3RfYnJpZGdlID0g
cHRfcGNpX2dldF9kZXYoMCwgMCwgMCkpKSB7CiAgICAgICAgIHBjaV9kZWZhdWx0X3dyaXRlX2Nv
bmZpZyhwY2lfZGV2LCBjb25maWdfYWRkciwgdmFsLCBsZW4pOwogICAgICAgICByZXR1cm47CiAg
ICAgfQpAQCAtNjIsMTEgKzYyLDExIEBAIHZvaWQgaWdkX3BjaV93cml0ZShQQ0lEZXZpY2UgKnBj
aV9kZXYsIHUKIAogdWludDMyX3QgaWdkX3BjaV9yZWFkKFBDSURldmljZSAqcGNpX2RldiwgdWlu
dDMyX3QgY29uZmlnX2FkZHIsIGludCBsZW4pCiB7Ci0gICAgc3RydWN0IHBjaV9kZXYgKnBjaV9k
ZXZfaG9zdF9icmlkZ2UgPSBwdF9wY2lfZ2V0X2RldigwLCAwLCAwKTsKKyAgICBzdHJ1Y3QgcGNp
X2RldiAqcGNpX2Rldl9ob3N0X2JyaWRnZTsKICAgICB1aW50MzJfdCB2YWw7CiAKICAgICBhc3Nl
cnQocGNpX2Rldi0+ZGV2Zm4gPT0gMHgwMCk7Ci0gICAgaWYgKCAhaWdkX3Bhc3N0aHJ1ICkgewor
ICAgIGlmICggIWlnZF9wYXNzdGhydSB8fCAhKHBjaV9kZXZfaG9zdF9icmlkZ2UgPSBwdF9wY2lf
Z2V0X2RldigwLCAwLCAwKSkgKSB7CiAgICAgICAgIHJldHVybiBwY2lfZGVmYXVsdF9yZWFkX2Nv
bmZpZyhwY2lfZGV2LCBjb25maWdfYWRkciwgbGVuKTsKICAgICB9CiAK
--14dae934038bb0b60804b89a1e3c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--14dae934038bb0b60804b89a1e3c--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:06:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:06:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvoJH-0001UQ-Qs; Fri, 10 Feb 2012 11:06:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RvoJG-0001UL-HI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:06:34 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1328871986!13759375!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21594 invoked from network); 10 Feb 2012 11:06:28 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:06:28 -0000
Received: by obcuy19 with SMTP id uy19so11597019obc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 03:06:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=vZsCB05TnEiZqi52ZPhH68dihBi57iXTDGn9Sqy02k4=;
	b=UHwMemM0dMidK05KyNXUjgDwD6XtMmaVIEuNBuidoVZ2eu3spFH1sR55kVHRrIytPI
	H6OuIzxx4R8Ml4L9VDGxJVb9CqN64snA+ZtrDyxNjeS2KtoxmmyWYIiGgXLb0jUM2sT+
	XXTWwc8rH2bnanXJ/uJVSvpopQZ1dZSdRw/sQ=
MIME-Version: 1.0
Received: by 10.50.203.33 with SMTP id kn1mr3357827igc.1.1328871986214; Fri,
	10 Feb 2012 03:06:26 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Fri, 10 Feb 2012 03:06:26 -0800 (PST)
Date: Fri, 10 Feb 2012 11:06:26 +0000
X-Google-Sender-Auth: SJG7k_WPqRUO05j7hzg_0gyUWSc
Message-ID: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com, 
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Jackson <ian.jackson@xen.org>
Content-Type: multipart/mixed; boundary=14dae934038bb0b60804b89a1e3c
Subject: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
	graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--14dae934038bb0b60804b89a1e3c
Content-Type: text/plain; charset=ISO-8859-1

A recent changeset introduced a bug whereby an initialization function
that reads /proc/bus/pci is called from graphics set-up functions
even if pass-through graphics are not enabled.  If qemu is run without
permission to this file, this causes qemu to fail during initialization.

This patch changes the initialization functions to only happen if graphics
pass-through are enabled.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

--14dae934038bb0b60804b89a1e3c
Content-Type: text/x-diff; charset=US-ASCII; name="fix-intel_pch_init.diff"
Content-Disposition: attachment; filename="fix-intel_pch_init.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyh40mln0

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgNmVmZWZmOTE0NjA5YTM4NzBlMmQwN2E4ZDcz
YTI2YzQ2MTVhYzYwYgpxZW11OiBEb24ndCBhY2Nlc3MgL3Byb2MvYnVzL3BjaSB1bmxlc3MgZ3Jh
cGhpY3MgcGFzcy10aHJ1IGlzIGVuYWJsZWQKCkEgcmVjZW50IGNoYW5nZXNldCBpbnRyb2R1Y2Vk
IGEgYnVnIHdoZXJlYnkgYW4gaW5pdGlhbGl6YXRpb24gZnVuY3Rpb24KdGhhdCByZWFkcyAvcHJv
Yy9idXMvcGNpIGlzIGNhbGxlZCBmcm9tIGdyYXBoaWNzIHNldC11cCBmdW5jdGlvbnMKZXZlbiBp
ZiBwYXNzLXRocm91Z2ggZ3JhcGhpY3MgYXJlIG5vdCBlbmFibGVkLiAgSWYgcWVtdSBpcyBydW4g
d2l0aG91dApwZXJtaXNzaW9uIHRvIHRoaXMgZmlsZSwgdGhpcyBjYXVzZXMgcWVtdSB0byBmYWls
IGR1cmluZyBpbml0aWFsaXphdGlvbi4KClRoaXMgcGF0Y2ggY2hhbmdlcyB0aGUgaW5pdGlhbGl6
YXRpb24gZnVuY3Rpb25zIHRvIG9ubHkgaGFwcGVuIGlmIGdyYXBoaWNzCnBhc3MtdGhyb3VnaCBh
cmUgZW5hYmxlZC4KClNpZ25lZC1vZmYtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBA
ZXUuY2l0cml4LmNvbT4KCmRpZmYgLXIgNmVmZWZmOTE0NjA5IGh3L3B0LWdyYXBoaWNzLmMKLS0t
IGEvaHcvcHQtZ3JhcGhpY3MuYwlGcmkgRmViIDEwIDExOjAyOjI1IDIwMTIgKzAwMDAKKysrIGIv
aHcvcHQtZ3JhcGhpY3MuYwlGcmkgRmViIDEwIDExOjA0OjAxIDIwMTIgKzAwMDAKQEAgLTIzLDkg
KzIzLDkgQEAgdm9pZCBpbnRlbF9wY2hfaW5pdChQQ0lCdXMgKmJ1cykKIHsKICAgICB1aW50MTZf
dCB2aWQsIGRpZDsKICAgICB1aW50OF90ICByaWQ7Ci0gICAgc3RydWN0IHBjaV9kZXYgKnBjaV9k
ZXZfMWYgPSBwdF9wY2lfZ2V0X2RldigwLCAweDFmLCAwKTsKKyAgICBzdHJ1Y3QgcGNpX2RldiAq
cGNpX2Rldl8xZjsKIAotICAgIGlmICggIWdmeF9wYXNzdGhydSB8fCAhcGNpX2Rldl8xZiApCisg
ICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8ICEocGNpX2Rldl8xZj1wdF9wY2lfZ2V0X2RldigwLCAw
eDFmLCAwKSkgKQogICAgICAgICByZXR1cm47CiAKICAgICB2aWQgPSBwdF9wY2lfaG9zdF9yZWFk
KHBjaV9kZXZfMWYsIFBDSV9WRU5ET1JfSUQsIDIpOwpAQCAtMzksOSArMzksOSBAQCB2b2lkIGlu
dGVsX3BjaF9pbml0KFBDSUJ1cyAqYnVzKQogCiB2b2lkIGlnZF9wY2lfd3JpdGUoUENJRGV2aWNl
ICpwY2lfZGV2LCB1aW50MzJfdCBjb25maWdfYWRkciwgdWludDMyX3QgdmFsLCBpbnQgbGVuKQog
ewotICAgIHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2X2hvc3RfYnJpZGdlID0gcHRfcGNpX2dldF9k
ZXYoMCwgMCwgMCk7CisgICAgc3RydWN0IHBjaV9kZXYgKnBjaV9kZXZfaG9zdF9icmlkZ2U7CiAg
ICAgYXNzZXJ0KHBjaV9kZXYtPmRldmZuID09IDB4MDApOwotICAgIGlmICggIWlnZF9wYXNzdGhy
dSApIHsKKyAgICBpZiAoICFpZ2RfcGFzc3RocnUgfHwgIShwY2lfZGV2X2hvc3RfYnJpZGdlID0g
cHRfcGNpX2dldF9kZXYoMCwgMCwgMCkpKSB7CiAgICAgICAgIHBjaV9kZWZhdWx0X3dyaXRlX2Nv
bmZpZyhwY2lfZGV2LCBjb25maWdfYWRkciwgdmFsLCBsZW4pOwogICAgICAgICByZXR1cm47CiAg
ICAgfQpAQCAtNjIsMTEgKzYyLDExIEBAIHZvaWQgaWdkX3BjaV93cml0ZShQQ0lEZXZpY2UgKnBj
aV9kZXYsIHUKIAogdWludDMyX3QgaWdkX3BjaV9yZWFkKFBDSURldmljZSAqcGNpX2RldiwgdWlu
dDMyX3QgY29uZmlnX2FkZHIsIGludCBsZW4pCiB7Ci0gICAgc3RydWN0IHBjaV9kZXYgKnBjaV9k
ZXZfaG9zdF9icmlkZ2UgPSBwdF9wY2lfZ2V0X2RldigwLCAwLCAwKTsKKyAgICBzdHJ1Y3QgcGNp
X2RldiAqcGNpX2Rldl9ob3N0X2JyaWRnZTsKICAgICB1aW50MzJfdCB2YWw7CiAKICAgICBhc3Nl
cnQocGNpX2Rldi0+ZGV2Zm4gPT0gMHgwMCk7Ci0gICAgaWYgKCAhaWdkX3Bhc3N0aHJ1ICkgewor
ICAgIGlmICggIWlnZF9wYXNzdGhydSB8fCAhKHBjaV9kZXZfaG9zdF9icmlkZ2UgPSBwdF9wY2lf
Z2V0X2RldigwLCAwLCAwKSkgKSB7CiAgICAgICAgIHJldHVybiBwY2lfZGVmYXVsdF9yZWFkX2Nv
bmZpZyhwY2lfZGV2LCBjb25maWdfYWRkciwgbGVuKTsKICAgICB9CiAK
--14dae934038bb0b60804b89a1e3c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--14dae934038bb0b60804b89a1e3c--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:16:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11: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.xensource.com>)
	id 1RvoSN-0001i9-BP; Fri, 10 Feb 2012 11:15:59 +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 1RvoSM-0001i2-0H
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:15:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328872505!52192072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7578 invoked from network); 10 Feb 2012 11:15:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10618899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11: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.213.0; Fri, 10 Feb 2012 11:15:56 +0000
Date: Fri, 10 Feb 2012 11:19:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paul Brook <paul@codesourcery.com>
In-Reply-To: <201202101109.03374.paul@codesourcery.com>
Message-ID: <alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Paul Brook wrote:
> > >> >  At least the floppy DMA engine is fine with it, it uses idle bottom
> > >> >  halves (which are a hack and could be replaced by timers, but that's
> > >> >  not relevant now).
> > > 
> > > I thought idle bottom halves were one of the things that made this timout
> > > necessary.  How else are they going to get run?
> > 
> > The timeout is reduced to 10 ms when an idle bottom half is scheduled.
> > See qemu_bh_update_timeout in async.c.
> 
> Ah, I see.  Idle BH are indeed a nasty hack that should be removed, but not 
> directly relevant to this 1s timeout.
> 
> I don't think this changes my overall conlusion:  Either we need this timeout 
> to poll below the user-thinks-qemu-died threshold, or we should be blocking 
> indefinitely.
 
I think you are right and the right thing to do would be blocking
indefinitely.
However if slirp doesn't support it, we could have a timeout of 1000 if
CONFIG_SLIRP, otherwise block indefinitely.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:16:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11: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.xensource.com>)
	id 1RvoSN-0001i9-BP; Fri, 10 Feb 2012 11:15:59 +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 1RvoSM-0001i2-0H
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:15:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328872505!52192072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7578 invoked from network); 10 Feb 2012 11:15:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10618899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11: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.213.0; Fri, 10 Feb 2012 11:15:56 +0000
Date: Fri, 10 Feb 2012 11:19:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paul Brook <paul@codesourcery.com>
In-Reply-To: <201202101109.03374.paul@codesourcery.com>
Message-ID: <alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Paul Brook wrote:
> > >> >  At least the floppy DMA engine is fine with it, it uses idle bottom
> > >> >  halves (which are a hack and could be replaced by timers, but that's
> > >> >  not relevant now).
> > > 
> > > I thought idle bottom halves were one of the things that made this timout
> > > necessary.  How else are they going to get run?
> > 
> > The timeout is reduced to 10 ms when an idle bottom half is scheduled.
> > See qemu_bh_update_timeout in async.c.
> 
> Ah, I see.  Idle BH are indeed a nasty hack that should be removed, but not 
> directly relevant to this 1s timeout.
> 
> I don't think this changes my overall conlusion:  Either we need this timeout 
> to poll below the user-thinks-qemu-died threshold, or we should be blocking 
> indefinitely.
 
I think you are right and the right thing to do would be blocking
indefinitely.
However if slirp doesn't support it, we could have a timeout of 1000 if
CONFIG_SLIRP, otherwise block indefinitely.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:18:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvoUj-0001rQ-Hs; Fri, 10 Feb 2012 11:18:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1RvoUh-0001rG-KD
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:18:23 +0000
Received: from [85.158.139.83:4437] by server-2.bemta-5.messagelabs.com id
	C2/4E-20725-EFCF43F4; Fri, 10 Feb 2012 11:18:22 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328872701!13887486!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19656 invoked from network); 10 Feb 2012 11:18:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	10 Feb 2012 11:18:22 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1ABIFQN015037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 06:18:15 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-23.ams2.redhat.com
	[10.36.112.23])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q1ABICwa023263; Fri, 10 Feb 2012 06:18:13 -0500
Message-ID: <4F34FCF3.4080300@redhat.com>
Date: Fri, 10 Feb 2012 12:18:11 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
	<alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Paul Brook <paul@codesourcery.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
> I think you are right and the right thing to do would be blocking
> indefinitely.
> However if slirp doesn't support it, we could have a timeout of 1000 if
> CONFIG_SLIRP, otherwise block indefinitely.

You could add a similar hack to qemu_bh_update_timeout for 
slirp_update_timeout.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:18:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvoUj-0001rQ-Hs; Fri, 10 Feb 2012 11:18:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1RvoUh-0001rG-KD
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:18:23 +0000
Received: from [85.158.139.83:4437] by server-2.bemta-5.messagelabs.com id
	C2/4E-20725-EFCF43F4; Fri, 10 Feb 2012 11:18:22 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328872701!13887486!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTIzMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19656 invoked from network); 10 Feb 2012 11:18:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	10 Feb 2012 11:18:22 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1ABIFQN015037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 06:18:15 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-23.ams2.redhat.com
	[10.36.112.23])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q1ABICwa023263; Fri, 10 Feb 2012 06:18:13 -0500
Message-ID: <4F34FCF3.4080300@redhat.com>
Date: Fri, 10 Feb 2012 12:18:11 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
	<alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Paul Brook <paul@codesourcery.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
> I think you are right and the right thing to do would be blocking
> indefinitely.
> However if slirp doesn't support it, we could have a timeout of 1000 if
> CONFIG_SLIRP, otherwise block indefinitely.

You could add a similar hack to qemu_bh_update_timeout for 
slirp_update_timeout.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:25:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvobL-00029k-CV; Fri, 10 Feb 2012 11:25:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvobJ-00029Y-NK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328873106!10969217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15151 invoked from network); 10 Feb 2012 11:25:06 -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 Feb 2012 11:25:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10619188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11:25:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 11:25:06 +0000
Date: Fri, 10 Feb 2012 11:28:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions
> even if pass-through graphics are not enabled.  If qemu is run without
> permission to this file, this causes qemu to fail during initialization.
> 
> This patch changes the initialization functions to only happen if graphics
> pass-through are enabled.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

could you please send patches inline?


> # HG changeset patch
> # Parent 6efeff914609a3870e2d07a8d73a26c4615ac60b
> qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
> 
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions
> even if pass-through graphics are not enabled.  If qemu is run without
> permission to this file, this causes qemu to fail during initialization.
> 
> This patch changes the initialization functions to only happen if graphics
> pass-through are enabled.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 6efeff914609 hw/pt-graphics.c
> --- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pt-graphics.c	Fri Feb 10 11:04:01 2012 +0000
> @@ -23,9 +23,9 @@ void intel_pch_init(PCIBus *bus)
>  {
>      uint16_t vid, did;
>      uint8_t  rid;
> -    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
> +    struct pci_dev *pci_dev_1f;
>  
> -    if ( !gfx_passthru || !pci_dev_1f )
> +    if ( !gfx_passthru || !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
>          return;

I would rather have it as a seprate test after if ( !gfx_passthru ),
same for the others below


>      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
>  
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
>          pci_default_write_config(pci_dev, config_addr, val, len);
>          return;
>      }

Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?

If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
also remove the assert?


> @@ -62,11 +62,11 @@ void igd_pci_write(PCIDevice *pci_dev, u
>  
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      uint32_t val;
>  
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ) {
>          return pci_default_read_config(pci_dev, config_addr, len);
>      }

same here

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:25:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvobL-00029k-CV; Fri, 10 Feb 2012 11:25:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvobJ-00029Y-NK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328873106!10969217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15151 invoked from network); 10 Feb 2012 11:25:06 -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 Feb 2012 11:25:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10619188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11:25:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 11:25:06 +0000
Date: Fri, 10 Feb 2012 11:28:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions
> even if pass-through graphics are not enabled.  If qemu is run without
> permission to this file, this causes qemu to fail during initialization.
> 
> This patch changes the initialization functions to only happen if graphics
> pass-through are enabled.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

could you please send patches inline?


> # HG changeset patch
> # Parent 6efeff914609a3870e2d07a8d73a26c4615ac60b
> qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
> 
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions
> even if pass-through graphics are not enabled.  If qemu is run without
> permission to this file, this causes qemu to fail during initialization.
> 
> This patch changes the initialization functions to only happen if graphics
> pass-through are enabled.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 6efeff914609 hw/pt-graphics.c
> --- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pt-graphics.c	Fri Feb 10 11:04:01 2012 +0000
> @@ -23,9 +23,9 @@ void intel_pch_init(PCIBus *bus)
>  {
>      uint16_t vid, did;
>      uint8_t  rid;
> -    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
> +    struct pci_dev *pci_dev_1f;
>  
> -    if ( !gfx_passthru || !pci_dev_1f )
> +    if ( !gfx_passthru || !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
>          return;

I would rather have it as a seprate test after if ( !gfx_passthru ),
same for the others below


>      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
>  
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
>          pci_default_write_config(pci_dev, config_addr, val, len);
>          return;
>      }

Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?

If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
also remove the assert?


> @@ -62,11 +62,11 @@ void igd_pci_write(PCIDevice *pci_dev, u
>  
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      uint32_t val;
>  
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ) {
>          return pci_default_read_config(pci_dev, config_addr, len);
>      }

same here

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11: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.xensource.com>)
	id 1RvoiU-0002Ld-Qu; Fri, 10 Feb 2012 11:32:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RvoiR-0002LY-LI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:32:35 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328873531!52373120!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDMzNDE1Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16029 invoked from network); 10 Feb 2012 11:32:11 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 11:32:11 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q1ABWPh6012961;
	Fri, 10 Feb 2012 12:32:25 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q1ABWNt0019944;
	Fri, 10 Feb 2012 12:32:23 +0100
Message-ID: <4F350047.4030507@siemens.com>
Date: Fri, 10 Feb 2012 12:32:23 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
	<alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
	<4F34FCF3.4080300@redhat.com>
In-Reply-To: <4F34FCF3.4080300@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Paul Brook <paul@codesourcery.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-10 12:18, Paolo Bonzini wrote:
> On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
>> I think you are right and the right thing to do would be blocking
>> indefinitely.
>> However if slirp doesn't support it, we could have a timeout of 1000 if
>> CONFIG_SLIRP, otherwise block indefinitely.
> 
> You could add a similar hack to qemu_bh_update_timeout for
> slirp_update_timeout.

Real solutions would be preferred, but I know that the code is hairy. In
any case, please no CONFIG_SLIRP code forks.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11: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.xensource.com>)
	id 1RvoiU-0002Ld-Qu; Fri, 10 Feb 2012 11:32:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RvoiR-0002LY-LI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:32:35 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328873531!52373120!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDMzNDE1Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16029 invoked from network); 10 Feb 2012 11:32:11 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 11:32:11 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q1ABWPh6012961;
	Fri, 10 Feb 2012 12:32:25 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q1ABWNt0019944;
	Fri, 10 Feb 2012 12:32:23 +0100
Message-ID: <4F350047.4030507@siemens.com>
Date: Fri, 10 Feb 2012 12:32:23 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
	<alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
	<4F34FCF3.4080300@redhat.com>
In-Reply-To: <4F34FCF3.4080300@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Paul Brook <paul@codesourcery.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-02-10 12:18, Paolo Bonzini wrote:
> On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
>> I think you are right and the right thing to do would be blocking
>> indefinitely.
>> However if slirp doesn't support it, we could have a timeout of 1000 if
>> CONFIG_SLIRP, otherwise block indefinitely.
> 
> You could add a similar hack to qemu_bh_update_timeout for
> slirp_update_timeout.

Real solutions would be preferred, but I know that the code is hairy. In
any case, please no CONFIG_SLIRP code forks.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:58:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp7K-00032n-Vz; Fri, 10 Feb 2012 11:58:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp7J-00032P-GY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:58:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328875091!4442853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25028 invoked from network); 10 Feb 2012 11:58:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:58:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10620056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11:58: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.213.0; Fri, 10 Feb 2012 11:58:10 +0000
Date: Fri, 10 Feb 2012 12:01:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (4):
      arm: add stub hvm/save.h
      libxl: do not allocate e820 for non x86 guests.
      blktap2/libvhd: Build shared objects using -fPIC.
      tools: only compile libfsimage/xfs on X86

Stefano Stabellini (6):
      arm: few missing #define
      arm: compile libxc
      arm: compile libxenguest
      arm: compile libxl
      arm: compile memshr
      arm: compile xentrace
      arm: compile xentrace

 tools/blktap2/vhd/lib/Makefile         |   13 +++-
 tools/libfsimage/Makefile              |    3 +-
 tools/libxc/Makefile                   |   16 ++++-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h              |   60 ++++++++++++++++++
 tools/libxc/xc_dom_arm.c               |   49 +++++++++++++++
 tools/libxc/xc_nohvm.c                 |   31 +++++++++
 tools/libxc/xc_nomigrate.c             |   40 ++++++++++++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    1 +
 tools/libxl/libxl_create.c             |    3 +-
 tools/libxl/libxl_json.c               |    8 +++
 tools/libxl/libxl_nocpuid.c            |    2 +-
 tools/libxl/libxl_pci.c                |    2 +
 tools/memshr/bidir-hash.c              |   31 +++++++++
 tools/xentrace/xenctx.c                |   12 ++++
 xen/include/public/arch-arm.h          |    2 +
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 xen/include/public/io/protocols.h      |    3 +
 21 files changed, 419 insertions(+), 10 deletions(-)

A git tree based on a22587ae517170a7755d3a88611ae0e2d5bb555e, is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:58:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp7K-00032n-Vz; Fri, 10 Feb 2012 11:58:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp7J-00032P-GY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:58:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328875091!4442853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25028 invoked from network); 10 Feb 2012 11:58:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:58:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10620056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11:58: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.213.0; Fri, 10 Feb 2012 11:58:10 +0000
Date: Fri, 10 Feb 2012 12:01:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (4):
      arm: add stub hvm/save.h
      libxl: do not allocate e820 for non x86 guests.
      blktap2/libvhd: Build shared objects using -fPIC.
      tools: only compile libfsimage/xfs on X86

Stefano Stabellini (6):
      arm: few missing #define
      arm: compile libxc
      arm: compile libxenguest
      arm: compile libxl
      arm: compile memshr
      arm: compile xentrace
      arm: compile xentrace

 tools/blktap2/vhd/lib/Makefile         |   13 +++-
 tools/libfsimage/Makefile              |    3 +-
 tools/libxc/Makefile                   |   16 ++++-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h              |   60 ++++++++++++++++++
 tools/libxc/xc_dom_arm.c               |   49 +++++++++++++++
 tools/libxc/xc_nohvm.c                 |   31 +++++++++
 tools/libxc/xc_nomigrate.c             |   40 ++++++++++++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    1 +
 tools/libxl/libxl_create.c             |    3 +-
 tools/libxl/libxl_json.c               |    8 +++
 tools/libxl/libxl_nocpuid.c            |    2 +-
 tools/libxl/libxl_pci.c                |    2 +
 tools/memshr/bidir-hash.c              |   31 +++++++++
 tools/xentrace/xenctx.c                |   12 ++++
 xen/include/public/arch-arm.h          |    2 +
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 xen/include/public/io/protocols.h      |    3 +
 21 files changed, 419 insertions(+), 10 deletions(-)

A git tree based on a22587ae517170a7755d3a88611ae0e2d5bb555e, is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8Q-00039A-MV; Fri, 10 Feb 2012 11:59: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 1Rvp8P-00038i-AY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:25 +0000
Received: from [85.158.139.83:55775] by server-8.bemta-5.messagelabs.com id
	68/C6-08951-C96053F4; Fri, 10 Feb 2012 11:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18066 invoked from network); 10 Feb 2012 11:59:23 -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;
	10 Feb 2012 11:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825052"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DX007170;
	Fri, 10 Feb 2012 03:59:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:41 +0000
Message-ID: <1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for non
	x86 guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ++-
 tools/libxl/libxl_pci.c    |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..3a63be0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -616,7 +616,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
+#if defined(__i386__) || defined(__x86_64__)
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         d_config->b_info.u.pv.e820_host) {
         int rc;
@@ -626,6 +626,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
                       rc, errno);
     }
+#endif
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 99591c2..c545b85 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1149,6 +1149,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -1390,6 +1391,7 @@ int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_conf
     }
     return 0;
 }
+#endif
 
 /*
  * Local variables:
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8Q-00039A-MV; Fri, 10 Feb 2012 11:59: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 1Rvp8P-00038i-AY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:25 +0000
Received: from [85.158.139.83:55775] by server-8.bemta-5.messagelabs.com id
	68/C6-08951-C96053F4; Fri, 10 Feb 2012 11:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18066 invoked from network); 10 Feb 2012 11:59:23 -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;
	10 Feb 2012 11:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825052"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DX007170;
	Fri, 10 Feb 2012 03:59:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:41 +0000
Message-ID: <1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for non
	x86 guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ++-
 tools/libxl/libxl_pci.c    |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..3a63be0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -616,7 +616,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
+#if defined(__i386__) || defined(__x86_64__)
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         d_config->b_info.u.pv.e820_host) {
         int rc;
@@ -626,6 +626,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
                       rc, errno);
     }
+#endif
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 99591c2..c545b85 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1149,6 +1149,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -1390,6 +1391,7 @@ int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_conf
     }
     return 0;
 }
+#endif
 
 /*
  * Local variables:
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8Q-000392-9S; Fri, 10 Feb 2012 11:59: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 1Rvp8O-00038d-Oe
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:25 +0000
Received: from [85.158.139.83:55728] by server-2.bemta-5.messagelabs.com id
	C6/74-20725-B96053F4; Fri, 10 Feb 2012 11:59:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18020 invoked from network); 10 Feb 2012 11:59:23 -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;
	10 Feb 2012 11:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825051"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:20 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DZ007170;
	Fri, 10 Feb 2012 03:59:14 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:43 +0000
Message-ID: <1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 05/10] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index e6fd488..3ee8c59 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8Q-000392-9S; Fri, 10 Feb 2012 11:59: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 1Rvp8O-00038d-Oe
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:25 +0000
Received: from [85.158.139.83:55728] by server-2.bemta-5.messagelabs.com id
	C6/74-20725-B96053F4; Fri, 10 Feb 2012 11:59:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18020 invoked from network); 10 Feb 2012 11:59:23 -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;
	10 Feb 2012 11:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825051"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:20 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DZ007170;
	Fri, 10 Feb 2012 03:59:14 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:43 +0000
Message-ID: <1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 05/10] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index e6fd488..3ee8c59 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8T-00039y-9f; Fri, 10 Feb 2012 11:59:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8S-00038i-JC
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:28 +0000
Received: from [85.158.139.83:52996] by server-8.bemta-5.messagelabs.com id
	4D/F6-08951-0A6053F4; Fri, 10 Feb 2012 11:59:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18263 invoked from network); 10 Feb 2012 11:59:27 -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;
	10 Feb 2012 11:59:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825053"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:26 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Dd007170;
	Fri, 10 Feb 2012 03:59:20 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:47 +0000
Message-ID: <1328875368-9608-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 09/10] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8T-00039y-9f; Fri, 10 Feb 2012 11:59:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8S-00038i-JC
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:28 +0000
Received: from [85.158.139.83:52996] by server-8.bemta-5.messagelabs.com id
	4D/F6-08951-0A6053F4; Fri, 10 Feb 2012 11:59:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18263 invoked from network); 10 Feb 2012 11:59:27 -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;
	10 Feb 2012 11:59:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825053"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:26 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Dd007170;
	Fri, 10 Feb 2012 03:59:20 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:47 +0000
Message-ID: <1328875368-9608-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 09/10] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8W-0003B5-O5; Fri, 10 Feb 2012 11:59: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 1Rvp8V-0003AP-0O
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:31 +0000
Received: from [85.158.139.83:53188] by server-5.bemta-5.messagelabs.com id
	7C/C1-03847-2A6053F4; Fri, 10 Feb 2012 11:59:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18454 invoked from network); 10 Feb 2012 11:59:29 -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;
	10 Feb 2012 11:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825054"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:28 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Db007170;
	Fri, 10 Feb 2012 03:59:17 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:45 +0000
Message-ID: <1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_json.c    |    8 ++++++++
 tools/libxl/libxl_nocpuid.c |    2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 5418683..e48e83a 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,6 +140,7 @@ out:
     return s;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                 libxl_cpuid_policy_list *pcpuid)
 {
@@ -199,6 +200,13 @@ empty:
 out:
     return s;
 }
+#else
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+#endif
 
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..313d55b 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11:59:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8W-0003B5-O5; Fri, 10 Feb 2012 11:59: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 1Rvp8V-0003AP-0O
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:31 +0000
Received: from [85.158.139.83:53188] by server-5.bemta-5.messagelabs.com id
	7C/C1-03847-2A6053F4; Fri, 10 Feb 2012 11:59:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328875161!14519711!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18454 invoked from network); 10 Feb 2012 11:59:29 -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;
	10 Feb 2012 11:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825054"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:28 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Db007170;
	Fri, 10 Feb 2012 03:59:17 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:45 +0000
Message-ID: <1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_json.c    |    8 ++++++++
 tools/libxl/libxl_nocpuid.c |    2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 5418683..e48e83a 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,6 +140,7 @@ out:
     return s;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
                                 libxl_cpuid_policy_list *pcpuid)
 {
@@ -199,6 +200,13 @@ empty:
 out:
     return s;
 }
+#else
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+#endif
 
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..313d55b 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11: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.xensource.com>)
	id 1Rvp8i-0003EW-UQ; Fri, 10 Feb 2012 11:59:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8f-0003CA-If
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21062 invoked from network); 10 Feb 2012 11:59:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221220"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:24 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DY007170;
	Fri, 10 Feb 2012 03:59:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:42 +0000
Message-ID: <1328875368-9608-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 04/10] blktap2/libvhd: Build shared objects
	using -fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap2/vhd/lib/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile
index b72e4d9..1acee70 100644
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -49,27 +49,32 @@ LIB-SRCS        += atomicio.c
 LIB-OBJS         = $(patsubst %.c,%.o,$(LIB-SRCS))
 LIB-OBJS        += $(LVM-UTIL-OBJ)
 
+LIB-PICOBJS      = $(patsubst %.o,%.opic,$(LIB-OBJS))
+
 LIBVHD           = libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 all: build
 
-build: $(LIBVHD-BUILD)
+build: libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 libvhd.a: $(LIB-OBJS)
+	$(AR) rc $@ $^
+
+libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR): $(LIB-PICOBJS)
 	$(CC) -Wl,$(SONAME_LDFLAG),$(LIBVHD-SONAME) $(SHLIB_LDFLAGS) \
 		$(LDFLAGS) -o libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $^ $(LIBS)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) libvhd.so
-	$(AR) rc $@ $^
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) $(LIBVHD) $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so
 
 clean:
-	rm -rf *.a *.so* *.o *~ $(DEPS) $(LIBVHD)
+	rm -rf *.a *.so* *.o *.opic *~ $(DEPS) $(LIBVHD)
 
 .PHONY: all build clean install libvhd
 
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 11:59:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 11: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.xensource.com>)
	id 1Rvp8i-0003EW-UQ; Fri, 10 Feb 2012 11:59:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8f-0003CA-If
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21062 invoked from network); 10 Feb 2012 11:59:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221220"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:24 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DY007170;
	Fri, 10 Feb 2012 03:59:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:42 +0000
Message-ID: <1328875368-9608-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 04/10] blktap2/libvhd: Build shared objects
	using -fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap2/vhd/lib/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile
index b72e4d9..1acee70 100644
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -49,27 +49,32 @@ LIB-SRCS        += atomicio.c
 LIB-OBJS         = $(patsubst %.c,%.o,$(LIB-SRCS))
 LIB-OBJS        += $(LVM-UTIL-OBJ)
 
+LIB-PICOBJS      = $(patsubst %.o,%.opic,$(LIB-OBJS))
+
 LIBVHD           = libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 all: build
 
-build: $(LIBVHD-BUILD)
+build: libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 libvhd.a: $(LIB-OBJS)
+	$(AR) rc $@ $^
+
+libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR): $(LIB-PICOBJS)
 	$(CC) -Wl,$(SONAME_LDFLAG),$(LIBVHD-SONAME) $(SHLIB_LDFLAGS) \
 		$(LDFLAGS) -o libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $^ $(LIBS)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) libvhd.so
-	$(AR) rc $@ $^
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) $(LIBVHD) $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so
 
 clean:
-	rm -rf *.a *.so* *.o *~ $(DEPS) $(LIBVHD)
+	rm -rf *.a *.so* *.o *.opic *~ $(DEPS) $(LIBVHD)
 
 .PHONY: all build clean install libvhd
 
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12:00:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8q-0003Go-1S; Fri, 10 Feb 2012 11:59:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8i-0003D9-BK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20098 invoked from network); 10 Feb 2012 11:59:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221206"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DV007170;
	Fri, 10 Feb 2012 03:59:08 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:39 +0000
Message-ID: <1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Few missing #define are the cause of a compile failure with
XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
native compilation). This patch fill the gaps.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm.h     |    2 ++
 xen/include/public/io/protocols.h |    3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c430cf3..e3d5c08 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
 
 struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
+typedef uint64_t xen_callback_t;
+
 #endif
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
index 77bd1bd..0b7a2ea 100644
--- a/xen/include/public/io/protocols.h
+++ b/xen/include/public/io/protocols.h
@@ -26,6 +26,7 @@
 #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -33,6 +34,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
 #elif defined(__ia64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12:00:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvp8q-0003Go-1S; Fri, 10 Feb 2012 11:59:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8i-0003D9-BK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20098 invoked from network); 10 Feb 2012 11:59:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221206"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DV007170;
	Fri, 10 Feb 2012 03:59:08 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:39 +0000
Message-ID: <1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Few missing #define are the cause of a compile failure with
XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
native compilation). This patch fill the gaps.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm.h     |    2 ++
 xen/include/public/io/protocols.h |    3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c430cf3..e3d5c08 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
 
 struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
+typedef uint64_t xen_callback_t;
+
 #endif
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
index 77bd1bd..0b7a2ea 100644
--- a/xen/include/public/io/protocols.h
+++ b/xen/include/public/io/protocols.h
@@ -26,6 +26,7 @@
 #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -33,6 +34,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
 #elif defined(__ia64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12: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.xensource.com>)
	id 1Rvp8z-0003KM-FL; Fri, 10 Feb 2012 12:00:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8h-0003Cs-Cq
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20761 invoked from network); 10 Feb 2012 11:59:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221217"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DW007170;
	Fri, 10 Feb 2012 03:59:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:40 +0000
Message-ID: <1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 02/10] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12: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.xensource.com>)
	id 1Rvp8z-0003KM-FL; Fri, 10 Feb 2012 12:00:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8h-0003Cs-Cq
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20761 invoked from network); 10 Feb 2012 11:59:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221217"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7DW007170;
	Fri, 10 Feb 2012 03:59:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:40 +0000
Message-ID: <1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 02/10] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvp94-0003Nw-DO; Fri, 10 Feb 2012 12:00:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8h-0003D1-Ts
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21309 invoked from network); 10 Feb 2012 11:59:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221223"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:27 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Da007170;
	Fri, 10 Feb 2012 03:59:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:44 +0000
Message-ID: <1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 06/10] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Also provide empty implementations of xc_domain_save, xc_domain_restore
and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
set.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile       |   15 ++++++++++--
 tools/libxc/xc_dom_arm.c   |   49 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nohvm.c     |   31 +++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c |   40 +++++++++++++++++++++++++++++++++++
 4 files changed, 132 insertions(+), 3 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 create mode 100644 tools/libxc/xc_nohvm.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..57ceee6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,17 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
+ifeq ($(CONFIG_HVM),y)
+GUEST_SRCS-y += xc_hvm_build.c
+else
+GUEST_SRCS-y += xc_nohvm.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -62,6 +70,7 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nohvm.c b/tools/libxc/xc_nohvm.c
new file mode 100644
index 0000000..a899f7c
--- /dev/null
+++ b/tools/libxc/xc_nohvm.c
@@ -0,0 +1,31 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..63090e0
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,40 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      unsigned int console_evtchn, unsigned long *console_mfn,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvp94-0003Nw-DO; Fri, 10 Feb 2012 12:00:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8h-0003D1-Ts
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21309 invoked from network); 10 Feb 2012 11:59:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221223"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:27 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Da007170;
	Fri, 10 Feb 2012 03:59:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:44 +0000
Message-ID: <1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 06/10] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Also provide empty implementations of xc_domain_save, xc_domain_restore
and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
set.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile       |   15 ++++++++++--
 tools/libxc/xc_dom_arm.c   |   49 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nohvm.c     |   31 +++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c |   40 +++++++++++++++++++++++++++++++++++
 4 files changed, 132 insertions(+), 3 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 create mode 100644 tools/libxc/xc_nohvm.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..57ceee6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,17 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
+ifeq ($(CONFIG_HVM),y)
+GUEST_SRCS-y += xc_hvm_build.c
+else
+GUEST_SRCS-y += xc_nohvm.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -62,6 +70,7 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nohvm.c b/tools/libxc/xc_nohvm.c
new file mode 100644
index 0000000..a899f7c
--- /dev/null
+++ b/tools/libxc/xc_nohvm.c
@@ -0,0 +1,31 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..63090e0
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,40 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      unsigned int console_evtchn, unsigned long *console_mfn,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvp98-0003Pc-CY; Fri, 10 Feb 2012 12:00:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8k-0003Da-EH
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21523 invoked from network); 10 Feb 2012 11:59:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221228"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:30 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Dc007170;
	Fri, 10 Feb 2012 03:59:18 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:46 +0000
Message-ID: <1328875368-9608-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 08/10] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvp98-0003Pc-CY; Fri, 10 Feb 2012 12:00:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8k-0003Da-EH
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328875156!12300942!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21523 invoked from network); 10 Feb 2012 11:59:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="181221228"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:30 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7Dc007170;
	Fri, 10 Feb 2012 03:59:18 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:46 +0000
Message-ID: <1328875368-9608-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 08/10] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12: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.xensource.com>)
	id 1Rvp9K-0003VX-4o; Fri, 10 Feb 2012 12:00:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8l-0003Dq-C2
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328875178!10956819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16924 invoked from network); 10 Feb 2012 11:59:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825057"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:38 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7De007170;
	Fri, 10 Feb 2012 03:59:21 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:48 +0000
Message-ID: <1328875368-9608-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 10/10] tools: only compile libfsimage/xfs on
	X86
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

xfs is not portable, only compile it on X86

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libfsimage/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 2deb830..bcb8b40 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,7 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS-y = common ufs reiserfs iso9660 fat zfs xfs
+SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC="$(CC)" ./check-libext2fs)
 
 .PHONY: all clean install
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:00:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12: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.xensource.com>)
	id 1Rvp9K-0003VX-4o; Fri, 10 Feb 2012 12:00:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvp8l-0003Dq-C2
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:59:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328875178!10956819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16924 invoked from network); 10 Feb 2012 11:59:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 11:59:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325480400"; d="scan'208";a="21825057"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 06:59:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 06:59:38 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ABx7De007170;
	Fri, 10 Feb 2012 03:59:21 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 12:02:48 +0000
Message-ID: <1328875368-9608-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v2 10/10] tools: only compile libfsimage/xfs on
	X86
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

xfs is not portable, only compile it on X86

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libfsimage/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 2deb830..bcb8b40 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,7 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS-y = common ufs reiserfs iso9660 fat zfs xfs
+SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC="$(CC)" ./check-libext2fs)
 
 .PHONY: all clean install
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:08:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12:08:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvpGj-00057Z-4G; Fri, 10 Feb 2012 12:08:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvpGh-00057U-EJ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 12:07:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328875672!12807965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21700 invoked from network); 10 Feb 2012 12:07:53 -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 Feb 2012 12:07:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10620306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 12:07:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 12:07:52 +0000
Message-ID: <1328875670.6133.259.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 12:07:50 +0000
In-Reply-To: <1328866262.6133.257.camel@zakaz.uk.xensource.com>
References: <osstest-11905-mainreport@xen.org>
	<1328866262.6133.257.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 09:31 +0000, Ian Campbell wrote:
> On Fri, 2012-02-10 at 01:23 +0000, xen.org wrote:
> > flight 11905 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
> >  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
> >  test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
> >  test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
> >  test-i386-i386-win            7 windows-install           fail REGR. vs. 11904
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/test-amd64-i386-win-vcpus1/gall-mite---var-log-xen-xend.log contains:
>         [2012-02-09 22:34:26 2310] ERROR (XendDomainInfo:488) VM start failed
>         Traceback (most recent call last):
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start
>             XendTask.log_progress(31, 60, self._initDomain)
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
>             retval = func(*args, **kwds)
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain
>             self._introduceDomain()
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2685, in _introduceDomain
>             raise XendError(str(exn))
>         XendError: (22, 'Invalid argument')
>         
> This try block contains only a single call to
> xen.xend.xenstore.xsutil.IntroduceDomain which ultimately turns into a C
> call to xs_introduce_domain.
> 
> Daniel, I'm afraid I suspect the XS stubdom series for this one. My
> suspicion is a missing call to seed_grant_table from xend (or from a
> libxc function which xend uses) which prevents xenstored from mapping
> the guest's ring, which results in an error from map_interface() in
> xenstored.

The following seems to fix it for me. I also tested an HVM migration
with xm since that seemed like something which might also suffer. It
seemed ok.

8<------------------------------------------------------------


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328875524 0
# Node ID 866498ce4469b6bbdbc338c516f39ac21e6aa7e7
# Parent  abc689ef19c2ab2bf86efee9f1e5107eb76c7ff7
xend: populate HVM guest grant table on boot

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r abc689ef19c2 -r 866498ce4469 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Fri Feb 10 11:27:30 2012 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Feb 10 12:05:24 2012 +0000
@@ -1008,6 +1008,30 @@ static PyObject *pyxc_hvm_build(XcObject
     return Py_BuildValue("{}");
 }
 
+static PyObject *pyxc_gnttab_hvm_seed(XcObject *self,
+				      PyObject *args,
+				      PyObject *kwds)
+{
+    uint32_t dom, console_domid, xenstore_domid;
+    unsigned long xenstore_gmfn = 0;
+    unsigned long console_gmfn = 0;
+    static char *kwd_list[] = { "domid",
+				"console_gmfn", "xenstore_gmfn",
+				"console_domid", "xenstore_domid", NULL };
+    if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiiii", kwd_list,
+                                      &dom,
+				      &console_gmfn, &xenstore_gmfn,
+				      &console_domid, &xenstore_domid) )
+        return NULL;
+
+    if ( xc_dom_gnttab_hvm_seed(self->xc_handle, dom,
+				console_gmfn, xenstore_gmfn,
+				console_domid, xenstore_domid) != 0 )
+        return pyxc_error_to_exception(self->xc_handle);
+
+    return Py_None;
+}
+
 static PyObject *pyxc_evtchn_alloc_unbound(XcObject *self,
                                            PyObject *args,
                                            PyObject *kwds)
@@ -2439,6 +2463,17 @@ static PyMethodDef pyxc_methods[] = {
       " vcpu_avail [long, 1]: Which Virtual CPUS available.\n\n"
       "Returns: [int] 0 on success; -1 on error.\n" },
 
+    { "gnttab_hvm_seed",
+      (PyCFunction)pyxc_gnttab_hvm_seed,
+      METH_KEYWORDS, "\n"
+      "Initialise HVM guest grant table.\n"
+      " dom     [int]:      Identifier of domain to build into.\n"
+      " console_gmfn [int]: \n"
+      " xenstore_gmfn [int]: \n"
+      " console_domid [int]: \n"
+      " xenstore_domid [int]: \n"
+      "Returns: None on sucess. Raises exception on error.\n" },
+
     { "hvm_get_param", 
       (PyCFunction)pyxc_get_hvm_param, 
       METH_VARARGS | METH_KEYWORDS, "\n"
diff -r abc689ef19c2 -r 866498ce4469 tools/python/xen/xend/XendConstants.py
--- a/tools/python/xen/xend/XendConstants.py	Fri Feb 10 11:27:30 2012 +0000
+++ b/tools/python/xen/xend/XendConstants.py	Fri Feb 10 12:05:24 2012 +0000
@@ -52,6 +52,7 @@ HVM_PARAM_TIMER_MODE   = 10
 HVM_PARAM_HPET_ENABLED = 11
 HVM_PARAM_ACPI_S_STATE = 14
 HVM_PARAM_VPT_ALIGN    = 16
+HVM_PARAM_CONSOLE_PFN  = 17
 HVM_PARAM_NESTEDHVM    = 24 # x86
 
 restart_modes = [
diff -r abc689ef19c2 -r 866498ce4469 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Fri Feb 10 11:27:30 2012 +0000
+++ b/tools/python/xen/xend/image.py	Fri Feb 10 12:05:24 2012 +0000
@@ -971,6 +971,13 @@ class HVMImageHandler(ImageHandler):
         xc.hvm_set_param(self.vm.getDomid(), HVM_PARAM_STORE_EVTCHN,
                          store_evtchn)
 
+        console_mfn = xc.hvm_get_param(self.vm.getDomid(), HVM_PARAM_CONSOLE_PFN)
+        xc.gnttab_hvm_seed(domid = self.vm.getDomid(),
+                           console_gmfn = console_mfn,
+                           xenstore_gmfn = rc['store_mfn'],
+                           console_domid = 0,
+                           xenstore_domid = 0)
+
         return rc
 
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:08:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12:08:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvpGj-00057Z-4G; Fri, 10 Feb 2012 12:08:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvpGh-00057U-EJ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 12:07:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328875672!12807965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21700 invoked from network); 10 Feb 2012 12:07:53 -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 Feb 2012 12:07:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10620306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 12:07:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 12:07:52 +0000
Message-ID: <1328875670.6133.259.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 12:07:50 +0000
In-Reply-To: <1328866262.6133.257.camel@zakaz.uk.xensource.com>
References: <osstest-11905-mainreport@xen.org>
	<1328866262.6133.257.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 09:31 +0000, Ian Campbell wrote:
> On Fri, 2012-02-10 at 01:23 +0000, xen.org wrote:
> > flight 11905 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
> >  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
> >  test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
> >  test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
> >  test-i386-i386-win            7 windows-install           fail REGR. vs. 11904
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11905/test-amd64-i386-win-vcpus1/gall-mite---var-log-xen-xend.log contains:
>         [2012-02-09 22:34:26 2310] ERROR (XendDomainInfo:488) VM start failed
>         Traceback (most recent call last):
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start
>             XendTask.log_progress(31, 60, self._initDomain)
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
>             retval = func(*args, **kwds)
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain
>             self._introduceDomain()
>           File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2685, in _introduceDomain
>             raise XendError(str(exn))
>         XendError: (22, 'Invalid argument')
>         
> This try block contains only a single call to
> xen.xend.xenstore.xsutil.IntroduceDomain which ultimately turns into a C
> call to xs_introduce_domain.
> 
> Daniel, I'm afraid I suspect the XS stubdom series for this one. My
> suspicion is a missing call to seed_grant_table from xend (or from a
> libxc function which xend uses) which prevents xenstored from mapping
> the guest's ring, which results in an error from map_interface() in
> xenstored.

The following seems to fix it for me. I also tested an HVM migration
with xm since that seemed like something which might also suffer. It
seemed ok.

8<------------------------------------------------------------


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328875524 0
# Node ID 866498ce4469b6bbdbc338c516f39ac21e6aa7e7
# Parent  abc689ef19c2ab2bf86efee9f1e5107eb76c7ff7
xend: populate HVM guest grant table on boot

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r abc689ef19c2 -r 866498ce4469 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Fri Feb 10 11:27:30 2012 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Feb 10 12:05:24 2012 +0000
@@ -1008,6 +1008,30 @@ static PyObject *pyxc_hvm_build(XcObject
     return Py_BuildValue("{}");
 }
 
+static PyObject *pyxc_gnttab_hvm_seed(XcObject *self,
+				      PyObject *args,
+				      PyObject *kwds)
+{
+    uint32_t dom, console_domid, xenstore_domid;
+    unsigned long xenstore_gmfn = 0;
+    unsigned long console_gmfn = 0;
+    static char *kwd_list[] = { "domid",
+				"console_gmfn", "xenstore_gmfn",
+				"console_domid", "xenstore_domid", NULL };
+    if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiiii", kwd_list,
+                                      &dom,
+				      &console_gmfn, &xenstore_gmfn,
+				      &console_domid, &xenstore_domid) )
+        return NULL;
+
+    if ( xc_dom_gnttab_hvm_seed(self->xc_handle, dom,
+				console_gmfn, xenstore_gmfn,
+				console_domid, xenstore_domid) != 0 )
+        return pyxc_error_to_exception(self->xc_handle);
+
+    return Py_None;
+}
+
 static PyObject *pyxc_evtchn_alloc_unbound(XcObject *self,
                                            PyObject *args,
                                            PyObject *kwds)
@@ -2439,6 +2463,17 @@ static PyMethodDef pyxc_methods[] = {
       " vcpu_avail [long, 1]: Which Virtual CPUS available.\n\n"
       "Returns: [int] 0 on success; -1 on error.\n" },
 
+    { "gnttab_hvm_seed",
+      (PyCFunction)pyxc_gnttab_hvm_seed,
+      METH_KEYWORDS, "\n"
+      "Initialise HVM guest grant table.\n"
+      " dom     [int]:      Identifier of domain to build into.\n"
+      " console_gmfn [int]: \n"
+      " xenstore_gmfn [int]: \n"
+      " console_domid [int]: \n"
+      " xenstore_domid [int]: \n"
+      "Returns: None on sucess. Raises exception on error.\n" },
+
     { "hvm_get_param", 
       (PyCFunction)pyxc_get_hvm_param, 
       METH_VARARGS | METH_KEYWORDS, "\n"
diff -r abc689ef19c2 -r 866498ce4469 tools/python/xen/xend/XendConstants.py
--- a/tools/python/xen/xend/XendConstants.py	Fri Feb 10 11:27:30 2012 +0000
+++ b/tools/python/xen/xend/XendConstants.py	Fri Feb 10 12:05:24 2012 +0000
@@ -52,6 +52,7 @@ HVM_PARAM_TIMER_MODE   = 10
 HVM_PARAM_HPET_ENABLED = 11
 HVM_PARAM_ACPI_S_STATE = 14
 HVM_PARAM_VPT_ALIGN    = 16
+HVM_PARAM_CONSOLE_PFN  = 17
 HVM_PARAM_NESTEDHVM    = 24 # x86
 
 restart_modes = [
diff -r abc689ef19c2 -r 866498ce4469 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Fri Feb 10 11:27:30 2012 +0000
+++ b/tools/python/xen/xend/image.py	Fri Feb 10 12:05:24 2012 +0000
@@ -971,6 +971,13 @@ class HVMImageHandler(ImageHandler):
         xc.hvm_set_param(self.vm.getDomid(), HVM_PARAM_STORE_EVTCHN,
                          store_evtchn)
 
+        console_mfn = xc.hvm_get_param(self.vm.getDomid(), HVM_PARAM_CONSOLE_PFN)
+        xc.gnttab_hvm_seed(domid = self.vm.getDomid(),
+                           console_gmfn = console_mfn,
+                           xenstore_gmfn = rc['store_mfn'],
+                           console_domid = 0,
+                           xenstore_domid = 0)
+
         return rc
 
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:13:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvpLJ-0005IO-FF; Fri, 10 Feb 2012 12:12: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 1RvpLG-0005IB-EQ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 12:12:44 +0000
Received: from [85.158.139.83:54524] by server-10.bemta-5.messagelabs.com id
	45/6D-26909-9B9053F4; Fri, 10 Feb 2012 12:12:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328875960!14529699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23574 invoked from network); 10 Feb 2012 12:12:40 -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;
	10 Feb 2012 12:12:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10620423"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 12:12:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 12:12:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvpLD-0003jI-Lx;
	Fri, 10 Feb 2012 12:12:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvpLD-000491-LX;
	Fri, 10 Feb 2012 12:12:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11911-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 12:12:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11911: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11911 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11911/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11907

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 12:13:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 12:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvpLJ-0005IO-FF; Fri, 10 Feb 2012 12:12: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 1RvpLG-0005IB-EQ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 12:12:44 +0000
Received: from [85.158.139.83:54524] by server-10.bemta-5.messagelabs.com id
	45/6D-26909-9B9053F4; Fri, 10 Feb 2012 12:12:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328875960!14529699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4ODYwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23574 invoked from network); 10 Feb 2012 12:12:40 -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;
	10 Feb 2012 12:12:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="10620423"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 12:12:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 12:12:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvpLD-0003jI-Lx;
	Fri, 10 Feb 2012 12:12:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvpLD-000491-LX;
	Fri, 10 Feb 2012 12:12:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11911-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 12:12:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11911: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11911 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11911/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11907

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:03:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq83-00061v-1g; Fri, 10 Feb 2012 13:03:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rvq81-00061o-OS
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:03:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328878977!14438991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22489 invoked from network); 10 Feb 2012 13:02:57 -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;
	10 Feb 2012 13:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10621626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13: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.213.0; Fri, 10 Feb 2012 13:02:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rvq7s-00048X-I3;
	Fri, 10 Feb 2012 13:02:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rvq7s-0005w4-Gz;
	Fri, 10 Feb 2012 13:02:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11918-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 13:02:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11918: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11918 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11918/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win           7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 11911 REGR. vs. 11904
 test-i386-i386-win            7 windows-install  fail in 11911 REGR. vs. 11904

Tests which are failing intermittently (not blocking):
 build-amd64-oldkern           4 xen-build                   fail pass in 11911
 build-i386                    4 xen-build                   fail pass in 11911
 build-i386-oldkern            4 xen-build                   fail pass in 11911
 build-amd64                   4 xen-build                   fail pass in 11911
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11911 pass in 11907

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-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-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install   fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11911 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11911 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11911 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11911 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11911 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11911 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11911 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11911 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11911 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11911 never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-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 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:03:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq83-00061v-1g; Fri, 10 Feb 2012 13:03:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rvq81-00061o-OS
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:03:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328878977!14438991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22489 invoked from network); 10 Feb 2012 13:02:57 -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;
	10 Feb 2012 13:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10621626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13: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.213.0; Fri, 10 Feb 2012 13:02:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rvq7s-00048X-I3;
	Fri, 10 Feb 2012 13:02:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rvq7s-0005w4-Gz;
	Fri, 10 Feb 2012 13:02:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11918-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 13:02:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11918: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11918 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11918/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win           7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 11911 REGR. vs. 11904
 test-i386-i386-win            7 windows-install  fail in 11911 REGR. vs. 11904

Tests which are failing intermittently (not blocking):
 build-amd64-oldkern           4 xen-build                   fail pass in 11911
 build-i386                    4 xen-build                   fail pass in 11911
 build-i386-oldkern            4 xen-build                   fail pass in 11911
 build-amd64                   4 xen-build                   fail pass in 11911
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11911 pass in 11907

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-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-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install   fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11911 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11911 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11911 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11911 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11911 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11911 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11911 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11911 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11911 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11911 never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-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 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq8y-00064d-Gc; Fri, 10 Feb 2012 13:04:04 +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 1Rvq8w-00064I-TY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12995 invoked from network); 10 Feb 2012 13:03:10 -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;
	10 Feb 2012 13:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826637"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:04:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:59 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXZ007755;
	Fri, 10 Feb 2012 05:03:59 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:43 +0000
Message-ID: <1328879024-5621-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Prior to setting up the page tables, parse the DTB for the location
and size of RAM.

Use this information to get the physical address to relocate Xen to in
setup_pagetables().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/mm.c             |    3 +-
 xen/arch/arm/setup.c          |    5 +
 xen/common/Makefile           |    3 +
 xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/mm.h      |    5 +-
 xen/include/xen/device_tree.h |   36 ++++++++
 6 files changed, 227 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/device_tree.c
 create mode 100644 xen/include/xen/device_tree.h

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f1fe4ba..24f977c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -20,6 +20,7 @@
 #include <xen/config.h>
 #include <xen/compile.h>
 #include <xen/types.h>
+#include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
@@ -159,7 +160,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
         write_pte(xen_second + second_linear_offset(dest_va), pte);
     }
 
-    xen_paddr = XEN_PADDR;
+    xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 51afb31..e212a2e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -19,6 +19,7 @@
 
 #include <xen/config.h>
 #include <xen/compile.h>
+#include <xen/device_tree.h>
 #include <xen/domain_page.h>
 #include <xen/types.h>
 #include <xen/string.h>
@@ -68,8 +69,12 @@ void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long atag_paddr)
 
 {
+    void *fdt;
     int i;
 
+    fdt = (void *)BOOT_MISC_VIRT_START + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
+    device_tree_early_init(fdt);
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 4b1e6f2..372b259 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-y += bitmap.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-$(HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
@@ -60,3 +61,5 @@ subdir-$(ia64) += hvm
 
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
+
+CFLAGS += -Ilibfdt
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
new file mode 100644
index 0000000..a60ff6d
--- /dev/null
+++ b/xen/common/device_tree.c
@@ -0,0 +1,179 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/device_tree.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#include <libfdt.h>
+
+struct dt_early_info __initdata early_info;
+
+static void __init get_val(const u32 **cell, u32 cells, u64 *val)
+{
+    *val = 0;
+
+    while (cells--) {
+        *val <<= 32;
+        *val |= fdt32_to_cpu(*(*cell)++);
+    }
+}
+
+static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
+                                u64 *start, u64 *size)
+{
+    get_val(cell, address_cells, start);
+    get_val(cell, size_cells, size);
+}
+
+static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if (!prop || prop->len < sizeof(u32))
+        return 0; /* default to 0 */
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+static void __init process_memory_node(const void *fdt, int node,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    size_t reg_cells;
+    int i;
+    int banks;
+    const u32 *cell;
+    paddr_t start, size;
+
+    if (address_cells < 1 || size_cells < 1) {
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if (!prop) {
+        early_printk("fdt: node `%s': missing `reg' property\n",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    reg_cells = address_cells + size_cells;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
+
+    for (i = 0; i < banks; i++) {
+        get_register(&cell, address_cells, size_cells, &start, &size);
+        early_info.mem.bank[early_info.mem.nr_banks].start = start;
+        early_info.mem.bank[early_info.mem.nr_banks].size = size;
+        early_info.mem.nr_banks++;
+    }
+}
+
+#define MAX_DEPTH 16
+
+static void __init early_scan(const void *fdt)
+{
+    int node;
+    int depth;
+    const char *name;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+
+    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= MAX_DEPTH) {
+            early_printk("fdt: node '%s': nested too deep\n",
+                         fdt_get_name(fdt, node, NULL));
+            continue;
+        }
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        if (strncmp(name, "memory", 6) == 0)
+            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
+    }
+}
+
+static void __init early_print_info(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    int i;
+
+    for (i = 0; i < mi->nr_banks; i++)
+        early_printk("RAM: %016llx - %016llx\n",
+                     mi->bank[i].start, mi->bank[i].start + mi->bank[i].size - 1);
+}
+
+/**
+ * device_tree_early_init - initialize early info from a DTB
+ * @fdt: flattened device tree binary
+ */
+void __init device_tree_early_init(const void *fdt)
+{
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if (ret < 0)
+        early_panic("No valid device tree\n");
+
+    early_scan(fdt);
+    early_print_info();
+}
+
+/**
+ * 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
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..8efa63b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -6,9 +6,8 @@
 #include <asm/page.h>
 #include <public/xen.h>
 
-/* Find a suitable place at the top of memory for Xen to live */
-/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
-#define XEN_PADDR 0x80ffe00000ull
+/* Align Xen to a 2 MiB boundary. */
+#define XEN_PADDR_ALIGN (1 << 21)
 
 /*
  * Per-page-frame information.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
new file mode 100644
index 0000000..eb7f219
--- /dev/null
+++ b/xen/include/xen/device_tree.h
@@ -0,0 +1,36 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __XEN_DEVICE_TREE_H__
+#define __XEN_DEVICE_TREE_H__
+
+#include <xen/types.h>
+
+#define NR_MEM_BANKS 8
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+};
+
+struct dt_mem_info {
+    int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};    
+
+struct dt_early_info {
+    struct dt_mem_info mem;
+};
+
+extern struct dt_early_info early_info;
+
+void device_tree_early_init(const void *fdt);
+paddr_t device_tree_get_xen_paddr(void);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq8y-00064d-Gc; Fri, 10 Feb 2012 13:04:04 +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 1Rvq8w-00064I-TY
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12995 invoked from network); 10 Feb 2012 13:03:10 -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;
	10 Feb 2012 13:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826637"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:04:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:59 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXZ007755;
	Fri, 10 Feb 2012 05:03:59 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:43 +0000
Message-ID: <1328879024-5621-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Prior to setting up the page tables, parse the DTB for the location
and size of RAM.

Use this information to get the physical address to relocate Xen to in
setup_pagetables().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/mm.c             |    3 +-
 xen/arch/arm/setup.c          |    5 +
 xen/common/Makefile           |    3 +
 xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/mm.h      |    5 +-
 xen/include/xen/device_tree.h |   36 ++++++++
 6 files changed, 227 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/device_tree.c
 create mode 100644 xen/include/xen/device_tree.h

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f1fe4ba..24f977c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -20,6 +20,7 @@
 #include <xen/config.h>
 #include <xen/compile.h>
 #include <xen/types.h>
+#include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
@@ -159,7 +160,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
         write_pte(xen_second + second_linear_offset(dest_va), pte);
     }
 
-    xen_paddr = XEN_PADDR;
+    xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 51afb31..e212a2e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -19,6 +19,7 @@
 
 #include <xen/config.h>
 #include <xen/compile.h>
+#include <xen/device_tree.h>
 #include <xen/domain_page.h>
 #include <xen/types.h>
 #include <xen/string.h>
@@ -68,8 +69,12 @@ void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long atag_paddr)
 
 {
+    void *fdt;
     int i;
 
+    fdt = (void *)BOOT_MISC_VIRT_START + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
+    device_tree_early_init(fdt);
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 4b1e6f2..372b259 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-y += bitmap.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-$(HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
@@ -60,3 +61,5 @@ subdir-$(ia64) += hvm
 
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
+
+CFLAGS += -Ilibfdt
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
new file mode 100644
index 0000000..a60ff6d
--- /dev/null
+++ b/xen/common/device_tree.c
@@ -0,0 +1,179 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/device_tree.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#include <libfdt.h>
+
+struct dt_early_info __initdata early_info;
+
+static void __init get_val(const u32 **cell, u32 cells, u64 *val)
+{
+    *val = 0;
+
+    while (cells--) {
+        *val <<= 32;
+        *val |= fdt32_to_cpu(*(*cell)++);
+    }
+}
+
+static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
+                                u64 *start, u64 *size)
+{
+    get_val(cell, address_cells, start);
+    get_val(cell, size_cells, size);
+}
+
+static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if (!prop || prop->len < sizeof(u32))
+        return 0; /* default to 0 */
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+static void __init process_memory_node(const void *fdt, int node,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    size_t reg_cells;
+    int i;
+    int banks;
+    const u32 *cell;
+    paddr_t start, size;
+
+    if (address_cells < 1 || size_cells < 1) {
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if (!prop) {
+        early_printk("fdt: node `%s': missing `reg' property\n",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    reg_cells = address_cells + size_cells;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
+
+    for (i = 0; i < banks; i++) {
+        get_register(&cell, address_cells, size_cells, &start, &size);
+        early_info.mem.bank[early_info.mem.nr_banks].start = start;
+        early_info.mem.bank[early_info.mem.nr_banks].size = size;
+        early_info.mem.nr_banks++;
+    }
+}
+
+#define MAX_DEPTH 16
+
+static void __init early_scan(const void *fdt)
+{
+    int node;
+    int depth;
+    const char *name;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+
+    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= MAX_DEPTH) {
+            early_printk("fdt: node '%s': nested too deep\n",
+                         fdt_get_name(fdt, node, NULL));
+            continue;
+        }
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        if (strncmp(name, "memory", 6) == 0)
+            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
+    }
+}
+
+static void __init early_print_info(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    int i;
+
+    for (i = 0; i < mi->nr_banks; i++)
+        early_printk("RAM: %016llx - %016llx\n",
+                     mi->bank[i].start, mi->bank[i].start + mi->bank[i].size - 1);
+}
+
+/**
+ * device_tree_early_init - initialize early info from a DTB
+ * @fdt: flattened device tree binary
+ */
+void __init device_tree_early_init(const void *fdt)
+{
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if (ret < 0)
+        early_panic("No valid device tree\n");
+
+    early_scan(fdt);
+    early_print_info();
+}
+
+/**
+ * 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
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..8efa63b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -6,9 +6,8 @@
 #include <asm/page.h>
 #include <public/xen.h>
 
-/* Find a suitable place at the top of memory for Xen to live */
-/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
-#define XEN_PADDR 0x80ffe00000ull
+/* Align Xen to a 2 MiB boundary. */
+#define XEN_PADDR_ALIGN (1 << 21)
 
 /*
  * Per-page-frame information.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
new file mode 100644
index 0000000..eb7f219
--- /dev/null
+++ b/xen/include/xen/device_tree.h
@@ -0,0 +1,36 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __XEN_DEVICE_TREE_H__
+#define __XEN_DEVICE_TREE_H__
+
+#include <xen/types.h>
+
+#define NR_MEM_BANKS 8
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+};
+
+struct dt_mem_info {
+    int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};    
+
+struct dt_early_info {
+    struct dt_mem_info mem;
+};
+
+extern struct dt_early_info early_info;
+
+void device_tree_early_init(const void *fdt);
+paddr_t device_tree_get_xen_paddr(void);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq8z-00065H-TV; Fri, 10 Feb 2012 13:04: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 1Rvq8y-00064A-8S
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12682 invoked from network); 10 Feb 2012 13:03:07 -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;
	10 Feb 2012 13:03:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826634"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:56 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXV007755;
	Fri, 10 Feb 2012 05:03:55 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:39 +0000
Message-ID: <1328879024-5621-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] libfdt: add to build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Rules.mk      |    2 ++
 xen/common/Makefile        |    1 +
 xen/common/libfdt/Makefile |    5 +++++
 3 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 336e209..14082dd 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,6 +6,8 @@
 # 'make clean' before rebuilding.
 #
 
+HAS_DEVICE_TREE := y
+
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
 CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
 CFLAGS += -I$(BASEDIR)/include
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..4b1e6f2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,3 +59,4 @@ subdir-$(x86_64) += hvm
 subdir-$(ia64) += hvm
 
 subdir-y += libelf
+subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
new file mode 100644
index 0000000..0e65bc0
--- /dev/null
+++ b/xen/common/libfdt/Makefile
@@ -0,0 +1,5 @@
+include Makefile.libfdt
+
+obj-y += $(LIBFDT_OBJS)
+
+CFLAGS += -I.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq8z-00065H-TV; Fri, 10 Feb 2012 13:04: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 1Rvq8y-00064A-8S
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12682 invoked from network); 10 Feb 2012 13:03:07 -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;
	10 Feb 2012 13:03:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826634"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:56 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXV007755;
	Fri, 10 Feb 2012 05:03:55 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:39 +0000
Message-ID: <1328879024-5621-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] libfdt: add to build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Rules.mk      |    2 ++
 xen/common/Makefile        |    1 +
 xen/common/libfdt/Makefile |    5 +++++
 3 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 336e209..14082dd 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,6 +6,8 @@
 # 'make clean' before rebuilding.
 #
 
+HAS_DEVICE_TREE := y
+
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
 CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
 CFLAGS += -I$(BASEDIR)/include
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..4b1e6f2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,3 +59,4 @@ subdir-$(x86_64) += hvm
 subdir-$(ia64) += hvm
 
 subdir-y += libelf
+subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
new file mode 100644
index 0000000..0e65bc0
--- /dev/null
+++ b/xen/common/libfdt/Makefile
@@ -0,0 +1,5 @@
+include Makefile.libfdt
+
+obj-y += $(LIBFDT_OBJS)
+
+CFLAGS += -I.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq8y-00064q-Tv; Fri, 10 Feb 2012 13:04:04 +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 1Rvq8x-00064B-B0
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12791 invoked from network); 10 Feb 2012 13:03:08 -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;
	10 Feb 2012 13:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826635"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:58 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXX007755;
	Fri, 10 Feb 2012 05:03:57 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:41 +0000
Message-ID: <1328879024-5621-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] arm: map device tree blob in initial page
	tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add a mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

It is mapped into the first L2 slot after the fixmap.  When this slot
is reused in setup_pagetables(), flush the TLB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/head.S          |    9 +++++++++
 xen/arch/arm/mm.c            |    5 +++--
 xen/include/asm-arm/config.h |    6 ++++++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 22ac512..51c26f6 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -200,7 +200,16 @@ hyp:
        orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
        add   r4, r4, #8
        strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#else
+       add   r4, r4, #8             /* Skip over unused fixmap slot */
 #endif
+       mov   r3, #0x0
+       lsr   r2, r8, #21
+       lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+       orr   r2, r2, #0xf00
+       orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+       add   r4, r4, #8
+       strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
        PRINT("- Turning on paging -\r\n")
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c863507..f1fe4ba 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -161,10 +161,11 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
 
     xen_paddr = XEN_PADDR;
 
-    /* Map the destination in the empty L2 above the fixmap */
-    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    /* Map the destination in the boot misc area. */
+    dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
     write_pte(xen_second + second_table_offset(dest_va), pte);
+    flush_xen_data_tlb_va(dest_va);
 
     /* Calculate virt-to-phys offset for the new location */
     phys_offset = xen_paddr - (unsigned long) _start;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 9294f8f..c2ab0a2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -55,15 +55,21 @@
  *  0  -   2M   Unmapped
  *  2M -   4M   Xen text, data, bss
  *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *  6M  -  8M   Early boot misc (see below)
  *
  * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  *
  *  1G -   2G   Xenheap: always-mapped memory
  *  2G -   4G   Domheap: on-demand-mapped
+ *
+ * The early boot misc area is used:
+ *   - in head.S for the DTB for device_tree_early_init().
+ *   - 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
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvq8y-00064q-Tv; Fri, 10 Feb 2012 13:04:04 +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 1Rvq8x-00064B-B0
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12791 invoked from network); 10 Feb 2012 13:03:08 -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;
	10 Feb 2012 13:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826635"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:58 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXX007755;
	Fri, 10 Feb 2012 05:03:57 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:41 +0000
Message-ID: <1328879024-5621-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] arm: map device tree blob in initial page
	tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add a mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

It is mapped into the first L2 slot after the fixmap.  When this slot
is reused in setup_pagetables(), flush the TLB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/head.S          |    9 +++++++++
 xen/arch/arm/mm.c            |    5 +++--
 xen/include/asm-arm/config.h |    6 ++++++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 22ac512..51c26f6 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -200,7 +200,16 @@ hyp:
        orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
        add   r4, r4, #8
        strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#else
+       add   r4, r4, #8             /* Skip over unused fixmap slot */
 #endif
+       mov   r3, #0x0
+       lsr   r2, r8, #21
+       lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+       orr   r2, r2, #0xf00
+       orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+       add   r4, r4, #8
+       strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
        PRINT("- Turning on paging -\r\n")
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c863507..f1fe4ba 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -161,10 +161,11 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
 
     xen_paddr = XEN_PADDR;
 
-    /* Map the destination in the empty L2 above the fixmap */
-    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    /* Map the destination in the boot misc area. */
+    dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
     write_pte(xen_second + second_table_offset(dest_va), pte);
+    flush_xen_data_tlb_va(dest_va);
 
     /* Calculate virt-to-phys offset for the new location */
     phys_offset = xen_paddr - (unsigned long) _start;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 9294f8f..c2ab0a2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -55,15 +55,21 @@
  *  0  -   2M   Unmapped
  *  2M -   4M   Xen text, data, bss
  *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *  6M  -  8M   Early boot misc (see below)
  *
  * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  *
  *  1G -   2G   Xenheap: always-mapped memory
  *  2G -   4G   Domheap: on-demand-mapped
+ *
+ * The early boot misc area is used:
+ *   - in head.S for the DTB for device_tree_early_init().
+ *   - 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
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq8z-000658-G2; Fri, 10 Feb 2012 13:04: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 1Rvq8x-000647-Ns
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12612 invoked from network); 10 Feb 2012 13:03:06 -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;
	10 Feb 2012 13:03:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826633"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:53 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1AD3qXS007755	for
	<xen-devel@lists.xensource.com>; Fri, 10 Feb 2012 05:03:53 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:36 +0000
Message-ID: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series adds preliminary device tree support to Xen for ARM.

libfdt for parsing a device tree in flattened device tree (fdt) format
and added and used to find the location and size of RAM.  This info is
then used when relocating Xen and setting up the mm and heaps.

Since we don't have a bootloader when using the model the device tree
blob (DTB) is linked into .dtb section of the Xen image.  The DTB
needs to be present in xen/arch/arm/platfom.dtb to build.  See the
wiki[1] for the Linux kernel which has a DTB for the model.

This series is also available in the device-tree-v4 branch of
git://xenbits.xen.org/people/dvrabel/xen-unstable.git

Changes since v1:

- map DTB in head.S using the L2 slot after the fixmap.
- new patch 8 for setting up mm/heaps.

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq8z-000658-G2; Fri, 10 Feb 2012 13:04: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 1Rvq8x-000647-Ns
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328878985!52212079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12612 invoked from network); 10 Feb 2012 13:03:06 -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;
	10 Feb 2012 13:03:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21826633"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:53 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1AD3qXS007755	for
	<xen-devel@lists.xensource.com>; Fri, 10 Feb 2012 05:03:53 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:36 +0000
Message-ID: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series adds preliminary device tree support to Xen for ARM.

libfdt for parsing a device tree in flattened device tree (fdt) format
and added and used to find the location and size of RAM.  This info is
then used when relocating Xen and setting up the mm and heaps.

Since we don't have a bootloader when using the model the device tree
blob (DTB) is linked into .dtb section of the Xen image.  The DTB
needs to be present in xen/arch/arm/platfom.dtb to build.  See the
wiki[1] for the Linux kernel which has a DTB for the model.

This series is also available in the device-tree-v4 branch of
git://xenbits.xen.org/people/dvrabel/xen-unstable.git

Changes since v1:

- map DTB in head.S using the L2 slot after the fixmap.
- new patch 8 for setting up mm/heaps.

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9L-0006Aa-Nw; Fri, 10 Feb 2012 13:04:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9J-00069L-Qa
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328879058!8619539!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3144 invoked from network); 10 Feb 2012 13:04:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229034"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:59 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXY007755;
	Fri, 10 Feb 2012 05:03:58 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:42 +0000
Message-ID: <1328879024-5621-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] arm: add early_printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add early_printk() which can be used before setup_pagetables().  This
will be used when doing the early parsing of the DTB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/early_printk.c        |   72 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/early_printk.h |   27 +++++++++++++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/early_printk.c
 create mode 100644 xen/include/asm-arm/early_printk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ac346a5..4794cfc 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-y += lib
 
 obj-y += dtb.o
 obj-y += dummy.o
+obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
new file mode 100644
index 0000000..3e51252
--- /dev/null
+++ b/xen/arch/arm/early_printk.c
@@ -0,0 +1,72 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+static void __init early_putch(char c)
+{
+    volatile uint32_t *r;
+
+    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
+                     + XEN_VIRT_START + (1 << 21));
+
+    /* XXX: assuming a PL011 UART. */
+    while(*(r + 0x6) & 0x8)
+        ;
+    *r = c;
+}
+
+static void __init early_puts(const char *s)
+{
+    while (*s != '\0') {
+        if (*s == '\n')
+            early_putch('\r');
+        early_putch(*s);
+        s++;
+    }
+}
+
+static void __init early_vprintk(const char *fmt, va_list args)
+{
+    char buf[80];
+
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    early_puts(buf);
+}
+
+void __init early_printk(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+}
+
+void __attribute__((noreturn)) __init
+early_panic(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+
+    while(1);
+}
+
+#endif /* #ifdef EARLY_UART_ADDRESS */
diff --git a/xen/include/asm-arm/early_printk.h b/xen/include/asm-arm/early_printk.h
new file mode 100644
index 0000000..f45f21e
--- /dev/null
+++ b/xen/include/asm-arm/early_printk.h
@@ -0,0 +1,27 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARM_EARLY_PRINTK_H__
+#define __ARM_EARLY_PRINTK_H__
+
+#include <xen/config.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+void early_printk(const char *fmt, ...);
+void early_panic(const char *fmt, ...);
+
+#else
+
+static inline void early_printk(const char *fmt, ...) {}
+static inline void early_panic(const char *fmt, ...) {}
+
+#endif
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9L-0006Aa-Nw; Fri, 10 Feb 2012 13:04:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9J-00069L-Qa
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328879058!8619539!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3144 invoked from network); 10 Feb 2012 13:04:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229034"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:59 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXY007755;
	Fri, 10 Feb 2012 05:03:58 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:42 +0000
Message-ID: <1328879024-5621-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] arm: add early_printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add early_printk() which can be used before setup_pagetables().  This
will be used when doing the early parsing of the DTB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/early_printk.c        |   72 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/early_printk.h |   27 +++++++++++++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/early_printk.c
 create mode 100644 xen/include/asm-arm/early_printk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ac346a5..4794cfc 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-y += lib
 
 obj-y += dtb.o
 obj-y += dummy.o
+obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
new file mode 100644
index 0000000..3e51252
--- /dev/null
+++ b/xen/arch/arm/early_printk.c
@@ -0,0 +1,72 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+static void __init early_putch(char c)
+{
+    volatile uint32_t *r;
+
+    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
+                     + XEN_VIRT_START + (1 << 21));
+
+    /* XXX: assuming a PL011 UART. */
+    while(*(r + 0x6) & 0x8)
+        ;
+    *r = c;
+}
+
+static void __init early_puts(const char *s)
+{
+    while (*s != '\0') {
+        if (*s == '\n')
+            early_putch('\r');
+        early_putch(*s);
+        s++;
+    }
+}
+
+static void __init early_vprintk(const char *fmt, va_list args)
+{
+    char buf[80];
+
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    early_puts(buf);
+}
+
+void __init early_printk(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+}
+
+void __attribute__((noreturn)) __init
+early_panic(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+
+    while(1);
+}
+
+#endif /* #ifdef EARLY_UART_ADDRESS */
diff --git a/xen/include/asm-arm/early_printk.h b/xen/include/asm-arm/early_printk.h
new file mode 100644
index 0000000..f45f21e
--- /dev/null
+++ b/xen/include/asm-arm/early_printk.h
@@ -0,0 +1,27 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARM_EARLY_PRINTK_H__
+#define __ARM_EARLY_PRINTK_H__
+
+#include <xen/config.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+void early_printk(const char *fmt, ...);
+void early_panic(const char *fmt, ...);
+
+#else
+
+static inline void early_printk(const char *fmt, ...) {}
+static inline void early_panic(const char *fmt, ...) {}
+
+#endif
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9L-0006AP-BS; Fri, 10 Feb 2012 13:04:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9J-00069F-8z
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328879055!10115358!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30071 invoked from network); 10 Feb 2012 13:04:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229039"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:04:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:04:00 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXa007755;
	Fri, 10 Feb 2012 05:04:00 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:44 +0000
Message-ID: <1328879024-5621-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] arm: setup MM using information from the
	device tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Setup memory management, heaps etc. using the location and size of the
first memory bank given in the device tree.

The DTB is also copied so it can be used afterwards.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c         |   22 +++++----
 xen/arch/arm/mm.c             |    3 +
 xen/arch/arm/setup.c          |   98 +++++++++++++++++++++++++++++++----------
 xen/common/device_tree.c      |    7 +++-
 xen/include/asm-arm/mm.h      |   11 +++--
 xen/include/asm-arm/setup.h   |    2 +
 xen/include/xen/device_tree.h |    3 +-
 7 files changed, 107 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d4ffa4f..f2339fa 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -11,6 +11,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/byteorder.h>
+#include <asm/setup.h>
 
 #include "kernel.h"
 
@@ -32,25 +33,28 @@ struct minimal_dtb_header {
 
 #define DTB_MAGIC 0xd00dfeed
 
-static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+/**
+ * copy_from_paddr - copy data from a physical address
+ * @dst: destination virtual address
+ * @paddr: source physical address
+ * @len: length to copy
+ */
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
-    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
-           len, flash, dst);
-
     while (len) {
         paddr_t p;
         unsigned long l, s;
 
-        p = flash >> PAGE_SHIFT;
-        s = flash & (PAGE_SIZE-1);
+        p = paddr >> PAGE_SHIFT;
+        s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
         set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
         memcpy(dst, src + s, l);
 
-        flash += l;
+        paddr += l;
         dst += l;
         len -= l;
     }
@@ -108,7 +112,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -150,7 +154,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 24f977c..0d6c0ca 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,7 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
 
+unsigned long frametable_base_mfn;
 unsigned long frametable_virt_end;
 
 /* Map a 4k page in a fixmap entry */
@@ -301,6 +302,8 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     unsigned long frametable_size = nr_pages * sizeof(struct page_info);
     unsigned long base_mfn;
 
+    frametable_base_mfn = ps >> PAGE_SHIFT;
+
     /* Round up to 32M boundary */
     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
     base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e212a2e..eff7098 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,16 +64,89 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+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;
+    unsigned long ram_pages;
+    unsigned long heap_pages, xenheap_pages, domheap_pages;
+    unsigned long dtb_pages;
+    unsigned long boot_mfn_start, boot_mfn_end;
+
+    /*
+     * TODO: only using the first RAM bank for now.  The heaps and the
+     * frame table assume RAM is physically contiguous.
+     */
+    ram_start = early_info.mem.bank[0].start;
+    ram_size  = early_info.mem.bank[0].size;
+    ram_end = ram_start + ram_size;
+    ram_pages = ram_size >> PAGE_SHIFT;
+
+    /*
+     * Calculate the sizes for the heaps using these constraints:
+     *
+     *  - heaps must be 32 MiB aligned
+     *  - must not include Xen itself
+     *  - xen heap must be at most 1 GiB
+     *
+     * XXX: needs a platform with at least 1GiB of RAM or the dom
+     * heap will be empty and no domains can be created.
+     */
+    heap_pages = (ram_size >> PAGE_SHIFT) - (32 << (20 - PAGE_SHIFT));
+    xenheap_pages = min(1ul << (30 - PAGE_SHIFT), heap_pages);
+    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);
+
+    /*
+     * Need a single mapped page for populating bootmem_region_list
+     * and enough mapped pages for copying the DTB.
+     *
+     * TODO: The DTB (and other payloads) are assumed to be towards
+     * the start of RAM.
+     */
+    dtb_pages = (dtb_size + PAGE_SIZE-1) >> PAGE_SHIFT;
+    boot_mfn_start = xenheap_mfn_end - dtb_pages - 1;
+    boot_mfn_end = xenheap_mfn_end;
+
+    init_boot_pages(pfn_to_paddr(boot_mfn_start), pfn_to_paddr(boot_mfn_end));
+
+    /*
+     * Copy the DTB.
+     *
+     * TODO: handle other payloads too.
+     */
+    device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+
+    /* 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));
+
+    setup_frametable_mappings(ram_start, ram_end);
+
+    /* Add xenheap memory that was not already added to the boot
+       allocator. */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
+                       pfn_to_paddr(boot_mfn_start));
+
+    end_boot_allocator();
+}
+
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
                       unsigned long atag_paddr)
 
 {
     void *fdt;
+    size_t fdt_size;
     int i;
 
     fdt = (void *)BOOT_MISC_VIRT_START + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
-    device_tree_early_init(fdt);
+    fdt_size = device_tree_early_init(fdt);
 
     setup_pagetables(boot_phys_offset);
 
@@ -97,28 +170,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     init_xen_time();
 
-    /* TODO: This needs some thought, as well as device-tree mapping.
-     * For testing, assume that the whole xenheap is contiguous in RAM */
-    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
-    /* Must pass a single mapped page for populating bootmem_region_list. */
-    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
-                    pfn_to_paddr(xenheap_mfn_start+1));
-
-    /* Add non-xenheap memory */
-    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
-
-    /* TODO Make sure Xen's own pages aren't added
-     *     -- the memory above doesn't include our relocation target.  */
-    /* TODO Handle payloads too */
-
-    /* TODO Need to find actual memory, for now use 4GB at 512GB */
-    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
-
-    /* Add xenheap memory */
-    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
-                       pfn_to_paddr(xenheap_mfn_end));
-
-    end_boot_allocator();
+    setup_mm(atag_paddr, fdt_size);
 
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index a60ff6d..788b2d3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -22,6 +22,7 @@
 #include <libfdt.h>
 
 struct dt_early_info __initdata early_info;
+void *device_tree_flattened;
 
 static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
@@ -126,8 +127,10 @@ static void __init early_print_info(void)
 /**
  * device_tree_early_init - initialize early info from a DTB
  * @fdt: flattened device tree binary
+ *
+ * Returns the size of the DTB.
  */
-void __init device_tree_early_init(const void *fdt)
+size_t __init device_tree_early_init(const void *fdt)
 {
     int ret;
 
@@ -137,6 +140,8 @@ void __init device_tree_early_init(const void *fdt)
 
     early_scan(fdt);
     early_print_info();
+
+    return fdt_totalsize(fdt);
 }
 
 /**
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 8efa63b..bfc0f76 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -128,6 +128,8 @@ extern void share_xen_page_with_privileged_guests(
     struct page_info *page, int readonly);
 
 #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+/* MFN of the first page in the frame table. */
+extern unsigned long frametable_base_mfn;
 
 extern unsigned long max_page;
 extern unsigned long total_pages;
@@ -151,15 +153,14 @@ extern void clear_fixmap(unsigned map);
 })
 
 #define max_pdx                 max_page
-/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
-#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
-#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define pfn_to_pdx(pfn)         (pfn)
+#define pdx_to_pfn(pdx)         (pdx)
 #define virt_to_pdx(va)         virt_to_mfn(va)
 #define pdx_to_virt(pdx)        mfn_to_virt(pdx)
 
 /* Convert between machine frame numbers and page-info structures. */
-#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
-#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define mfn_to_page(mfn)  (frame_table + (pfn_to_pdx(mfn) - frametable_base_mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table) + frametable_base_mfn)
 #define __page_to_mfn(pg)  page_to_mfn(pg)
 #define __mfn_to_page(mfn) mfn_to_page(mfn)
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 2041f06..05ff89e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,8 @@
 
 #include <public/version.h>
 
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index eb7f219..3cafdc7 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -29,8 +29,9 @@ struct dt_early_info {
 };
 
 extern struct dt_early_info early_info;
+extern void *device_tree_flattened;
 
-void device_tree_early_init(const void *fdt);
+size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9M-0006B7-LZ; Fri, 10 Feb 2012 13:04:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9L-00069c-1p
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328879055!10115358!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30422 invoked from network); 10 Feb 2012 13:04:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229023"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:55 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXU007755;
	Fri, 10 Feb 2012 05:03:54 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:38 +0000
Message-ID: <1328879024-5621-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] libfdt: fixup libfdt_env.h for xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/libfdt_env.h |   27 ++++++++++-----------------
 xen/include/xen/types.h        |    2 ++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
index 449bf60..8c0c030 100644
--- a/xen/common/libfdt/libfdt_env.h
+++ b/xen/common/libfdt/libfdt_env.h
@@ -1,23 +1,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <stdint.h>
-#include <string.h>
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <asm/byteorder.h>
 
-#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
-static inline uint32_t fdt32_to_cpu(uint32_t x)
-{
-	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
-}
-#define cpu_to_fdt32(x) fdt32_to_cpu(x)
-
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
-	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
-		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
-}
-#define cpu_to_fdt64(x) fdt64_to_cpu(x)
-#undef _B
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
 
 #endif /* _LIBFDT_ENV_H */
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index ac96647..8596ded 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -57,4 +57,6 @@ typedef __u32 __be32;
 typedef __u64 __le64;
 typedef __u64 __be64;
 
+typedef unsigned long uintptr_t;
+
 #endif /* __TYPES_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9M-0006Az-9O; Fri, 10 Feb 2012 13:04:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9K-00069X-L7
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328879055!10115358!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30381 invoked from network); 10 Feb 2012 13:04:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229028"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:57 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXW007755;
	Fri, 10 Feb 2012 05:03:56 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:40 +0000
Message-ID: <1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the xen
	image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Link a device tree blob (DTB) into the xen image.  This is loaded
immediately after Xen and xen_start() is called with the correct
address in atag_paddr.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile  |    7 +++++--
 xen/arch/arm/dtb.S     |    2 ++
 xen/arch/arm/head.S    |    4 ++++
 xen/arch/arm/xen.lds.S |    5 +++++
 4 files changed, 16 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/dtb.S

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..ac346a5 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,5 +1,6 @@
 subdir-y += lib
 
+obj-y += dtb.o
 obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
@@ -27,7 +28,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
-	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	# XXX strip it
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
@@ -50,7 +51,7 @@ endif
 $(BASEDIR)/common/symbols-dummy.o:
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
 
-$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o dtb.o
 	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
@@ -71,6 +72,8 @@ xen.lds: xen.lds.S
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
+dtb.o: platform.dtb
+
 .PHONY: clean
 clean::
 	rm -f asm-offsets.s xen.lds
diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
new file mode 100644
index 0000000..0728c04
--- /dev/null
+++ b/xen/arch/arm/dtb.S
@@ -0,0 +1,2 @@
+        .section .dtb,#alloc
+        .incbin "platform.dtb"
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 57b990d..22ac512 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -55,6 +55,10 @@ start:
        adr   r9, start              /* r9  := paddr (start) */
        sub   r10, r9, r0            /* r10 := phys-offset */
 
+        /* XXX: using the DTB in the .dtb section. */
+        ldr   r8, =_sdtb
+        add   r8, r10                /* r8 := paddr(DTB) */
+
 #ifdef EARLY_UART_ADDRESS
        /* Say hello */
        ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5a62e2c..30fc7b7 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -122,6 +122,11 @@ SECTIONS
   } :text
   _end = . ;
 
+  /* XXX: don't yet have a bootloader to provide the DTB, link it into
+     Xen in its own section. */
+  _sdtb = .;
+  .dtb : { dtb.o(.dtb) } :text
+
   /* Sections to be discarded */
   /DISCARD/ : {
        *(.exit.text)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9L-0006AP-BS; Fri, 10 Feb 2012 13:04:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9J-00069F-8z
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328879055!10115358!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30071 invoked from network); 10 Feb 2012 13:04:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229039"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:04:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:04:00 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXa007755;
	Fri, 10 Feb 2012 05:04:00 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:44 +0000
Message-ID: <1328879024-5621-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] arm: setup MM using information from the
	device tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Setup memory management, heaps etc. using the location and size of the
first memory bank given in the device tree.

The DTB is also copied so it can be used afterwards.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c         |   22 +++++----
 xen/arch/arm/mm.c             |    3 +
 xen/arch/arm/setup.c          |   98 +++++++++++++++++++++++++++++++----------
 xen/common/device_tree.c      |    7 +++-
 xen/include/asm-arm/mm.h      |   11 +++--
 xen/include/asm-arm/setup.h   |    2 +
 xen/include/xen/device_tree.h |    3 +-
 7 files changed, 107 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d4ffa4f..f2339fa 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -11,6 +11,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/byteorder.h>
+#include <asm/setup.h>
 
 #include "kernel.h"
 
@@ -32,25 +33,28 @@ struct minimal_dtb_header {
 
 #define DTB_MAGIC 0xd00dfeed
 
-static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+/**
+ * copy_from_paddr - copy data from a physical address
+ * @dst: destination virtual address
+ * @paddr: source physical address
+ * @len: length to copy
+ */
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
-    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
-           len, flash, dst);
-
     while (len) {
         paddr_t p;
         unsigned long l, s;
 
-        p = flash >> PAGE_SHIFT;
-        s = flash & (PAGE_SIZE-1);
+        p = paddr >> PAGE_SHIFT;
+        s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
         set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
         memcpy(dst, src + s, l);
 
-        flash += l;
+        paddr += l;
         dst += l;
         len -= l;
     }
@@ -108,7 +112,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -150,7 +154,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 24f977c..0d6c0ca 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,7 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
 
+unsigned long frametable_base_mfn;
 unsigned long frametable_virt_end;
 
 /* Map a 4k page in a fixmap entry */
@@ -301,6 +302,8 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     unsigned long frametable_size = nr_pages * sizeof(struct page_info);
     unsigned long base_mfn;
 
+    frametable_base_mfn = ps >> PAGE_SHIFT;
+
     /* Round up to 32M boundary */
     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
     base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e212a2e..eff7098 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,16 +64,89 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+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;
+    unsigned long ram_pages;
+    unsigned long heap_pages, xenheap_pages, domheap_pages;
+    unsigned long dtb_pages;
+    unsigned long boot_mfn_start, boot_mfn_end;
+
+    /*
+     * TODO: only using the first RAM bank for now.  The heaps and the
+     * frame table assume RAM is physically contiguous.
+     */
+    ram_start = early_info.mem.bank[0].start;
+    ram_size  = early_info.mem.bank[0].size;
+    ram_end = ram_start + ram_size;
+    ram_pages = ram_size >> PAGE_SHIFT;
+
+    /*
+     * Calculate the sizes for the heaps using these constraints:
+     *
+     *  - heaps must be 32 MiB aligned
+     *  - must not include Xen itself
+     *  - xen heap must be at most 1 GiB
+     *
+     * XXX: needs a platform with at least 1GiB of RAM or the dom
+     * heap will be empty and no domains can be created.
+     */
+    heap_pages = (ram_size >> PAGE_SHIFT) - (32 << (20 - PAGE_SHIFT));
+    xenheap_pages = min(1ul << (30 - PAGE_SHIFT), heap_pages);
+    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);
+
+    /*
+     * Need a single mapped page for populating bootmem_region_list
+     * and enough mapped pages for copying the DTB.
+     *
+     * TODO: The DTB (and other payloads) are assumed to be towards
+     * the start of RAM.
+     */
+    dtb_pages = (dtb_size + PAGE_SIZE-1) >> PAGE_SHIFT;
+    boot_mfn_start = xenheap_mfn_end - dtb_pages - 1;
+    boot_mfn_end = xenheap_mfn_end;
+
+    init_boot_pages(pfn_to_paddr(boot_mfn_start), pfn_to_paddr(boot_mfn_end));
+
+    /*
+     * Copy the DTB.
+     *
+     * TODO: handle other payloads too.
+     */
+    device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+
+    /* 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));
+
+    setup_frametable_mappings(ram_start, ram_end);
+
+    /* Add xenheap memory that was not already added to the boot
+       allocator. */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
+                       pfn_to_paddr(boot_mfn_start));
+
+    end_boot_allocator();
+}
+
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
                       unsigned long atag_paddr)
 
 {
     void *fdt;
+    size_t fdt_size;
     int i;
 
     fdt = (void *)BOOT_MISC_VIRT_START + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
-    device_tree_early_init(fdt);
+    fdt_size = device_tree_early_init(fdt);
 
     setup_pagetables(boot_phys_offset);
 
@@ -97,28 +170,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     init_xen_time();
 
-    /* TODO: This needs some thought, as well as device-tree mapping.
-     * For testing, assume that the whole xenheap is contiguous in RAM */
-    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
-    /* Must pass a single mapped page for populating bootmem_region_list. */
-    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
-                    pfn_to_paddr(xenheap_mfn_start+1));
-
-    /* Add non-xenheap memory */
-    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
-
-    /* TODO Make sure Xen's own pages aren't added
-     *     -- the memory above doesn't include our relocation target.  */
-    /* TODO Handle payloads too */
-
-    /* TODO Need to find actual memory, for now use 4GB at 512GB */
-    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
-
-    /* Add xenheap memory */
-    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
-                       pfn_to_paddr(xenheap_mfn_end));
-
-    end_boot_allocator();
+    setup_mm(atag_paddr, fdt_size);
 
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index a60ff6d..788b2d3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -22,6 +22,7 @@
 #include <libfdt.h>
 
 struct dt_early_info __initdata early_info;
+void *device_tree_flattened;
 
 static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
@@ -126,8 +127,10 @@ static void __init early_print_info(void)
 /**
  * device_tree_early_init - initialize early info from a DTB
  * @fdt: flattened device tree binary
+ *
+ * Returns the size of the DTB.
  */
-void __init device_tree_early_init(const void *fdt)
+size_t __init device_tree_early_init(const void *fdt)
 {
     int ret;
 
@@ -137,6 +140,8 @@ void __init device_tree_early_init(const void *fdt)
 
     early_scan(fdt);
     early_print_info();
+
+    return fdt_totalsize(fdt);
 }
 
 /**
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 8efa63b..bfc0f76 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -128,6 +128,8 @@ extern void share_xen_page_with_privileged_guests(
     struct page_info *page, int readonly);
 
 #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+/* MFN of the first page in the frame table. */
+extern unsigned long frametable_base_mfn;
 
 extern unsigned long max_page;
 extern unsigned long total_pages;
@@ -151,15 +153,14 @@ extern void clear_fixmap(unsigned map);
 })
 
 #define max_pdx                 max_page
-/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
-#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
-#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define pfn_to_pdx(pfn)         (pfn)
+#define pdx_to_pfn(pdx)         (pdx)
 #define virt_to_pdx(va)         virt_to_mfn(va)
 #define pdx_to_virt(pdx)        mfn_to_virt(pdx)
 
 /* Convert between machine frame numbers and page-info structures. */
-#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
-#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define mfn_to_page(mfn)  (frame_table + (pfn_to_pdx(mfn) - frametable_base_mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table) + frametable_base_mfn)
 #define __page_to_mfn(pg)  page_to_mfn(pg)
 #define __mfn_to_page(mfn) mfn_to_page(mfn)
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 2041f06..05ff89e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,8 @@
 
 #include <public/version.h>
 
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index eb7f219..3cafdc7 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -29,8 +29,9 @@ struct dt_early_info {
 };
 
 extern struct dt_early_info early_info;
+extern void *device_tree_flattened;
 
-void device_tree_early_init(const void *fdt);
+size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9M-0006B7-LZ; Fri, 10 Feb 2012 13:04:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9L-00069c-1p
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328879055!10115358!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30422 invoked from network); 10 Feb 2012 13:04:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229023"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:55 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXU007755;
	Fri, 10 Feb 2012 05:03:54 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:38 +0000
Message-ID: <1328879024-5621-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] libfdt: fixup libfdt_env.h for xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/libfdt_env.h |   27 ++++++++++-----------------
 xen/include/xen/types.h        |    2 ++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
index 449bf60..8c0c030 100644
--- a/xen/common/libfdt/libfdt_env.h
+++ b/xen/common/libfdt/libfdt_env.h
@@ -1,23 +1,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <stdint.h>
-#include <string.h>
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <asm/byteorder.h>
 
-#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
-static inline uint32_t fdt32_to_cpu(uint32_t x)
-{
-	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
-}
-#define cpu_to_fdt32(x) fdt32_to_cpu(x)
-
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
-	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
-		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
-}
-#define cpu_to_fdt64(x) fdt64_to_cpu(x)
-#undef _B
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
 
 #endif /* _LIBFDT_ENV_H */
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index ac96647..8596ded 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -57,4 +57,6 @@ typedef __u32 __be32;
 typedef __u64 __le64;
 typedef __u64 __be64;
 
+typedef unsigned long uintptr_t;
+
 #endif /* __TYPES_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9M-0006Az-9O; Fri, 10 Feb 2012 13:04:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rvq9K-00069X-L7
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328879055!10115358!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30381 invoked from network); 10 Feb 2012 13:04:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229028"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:57 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXW007755;
	Fri, 10 Feb 2012 05:03:56 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:40 +0000
Message-ID: <1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the xen
	image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Link a device tree blob (DTB) into the xen image.  This is loaded
immediately after Xen and xen_start() is called with the correct
address in atag_paddr.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile  |    7 +++++--
 xen/arch/arm/dtb.S     |    2 ++
 xen/arch/arm/head.S    |    4 ++++
 xen/arch/arm/xen.lds.S |    5 +++++
 4 files changed, 16 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/dtb.S

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..ac346a5 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,5 +1,6 @@
 subdir-y += lib
 
+obj-y += dtb.o
 obj-y += dummy.o
 obj-y += entry.o
 obj-y += domain.o
@@ -27,7 +28,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
-	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	# XXX strip it
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
@@ -50,7 +51,7 @@ endif
 $(BASEDIR)/common/symbols-dummy.o:
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
 
-$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o dtb.o
 	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
@@ -71,6 +72,8 @@ xen.lds: xen.lds.S
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
+dtb.o: platform.dtb
+
 .PHONY: clean
 clean::
 	rm -f asm-offsets.s xen.lds
diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
new file mode 100644
index 0000000..0728c04
--- /dev/null
+++ b/xen/arch/arm/dtb.S
@@ -0,0 +1,2 @@
+        .section .dtb,#alloc
+        .incbin "platform.dtb"
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 57b990d..22ac512 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -55,6 +55,10 @@ start:
        adr   r9, start              /* r9  := paddr (start) */
        sub   r10, r9, r0            /* r10 := phys-offset */
 
+        /* XXX: using the DTB in the .dtb section. */
+        ldr   r8, =_sdtb
+        add   r8, r10                /* r8 := paddr(DTB) */
+
 #ifdef EARLY_UART_ADDRESS
        /* Say hello */
        ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5a62e2c..30fc7b7 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -122,6 +122,11 @@ SECTIONS
   } :text
   _end = . ;
 
+  /* XXX: don't yet have a bootloader to provide the DTB, link it into
+     Xen in its own section. */
+  _sdtb = .;
+  .dtb : { dtb.o(.dtb) } :text
+
   /* Sections to be discarded */
   /DISCARD/ : {
        *(.exit.text)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvq9e-0006Lr-4Y; Fri, 10 Feb 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 <david.vrabel@citrix.com>) id 1Rvq9S-0006Dw-2U
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:44 +0000
Received: from [85.158.139.83:46694] by server-4.bemta-5.messagelabs.com id
	46/FC-28576-0E5153F4; Fri, 10 Feb 2012 13:04:32 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328879054!13905276!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30962 invoked from network); 10 Feb 2012 13:04:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229022"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:54 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXT007755;
	Fri, 10 Feb 2012 05:03:54 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:37 +0000
Message-ID: <1328879024-5621-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git

This will be used by Xen to parse the DTBs provided by bootloaders on
ARM platforms.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/Makefile.libfdt   |   10 +
 xen/common/libfdt/TODO              |    3 +
 xen/common/libfdt/fdt.c             |  222 +++++++
 xen/common/libfdt/fdt.h             |   60 ++
 xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
 xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
 xen/common/libfdt/fdt_strerror.c    |   96 +++
 xen/common/libfdt/fdt_sw.c          |  256 ++++++++
 xen/common/libfdt/fdt_wip.c         |  118 ++++
 xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
 xen/common/libfdt/libfdt_env.h      |   23 +
 xen/common/libfdt/libfdt_internal.h |   95 +++
 xen/common/libfdt/version.lds       |   54 ++
 13 files changed, 3211 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile.libfdt
 create mode 100644 xen/common/libfdt/TODO
 create mode 100644 xen/common/libfdt/fdt.c
 create mode 100644 xen/common/libfdt/fdt.h
 create mode 100644 xen/common/libfdt/fdt_ro.c
 create mode 100644 xen/common/libfdt/fdt_rw.c
 create mode 100644 xen/common/libfdt/fdt_strerror.c
 create mode 100644 xen/common/libfdt/fdt_sw.c
 create mode 100644 xen/common/libfdt/fdt_wip.c
 create mode 100644 xen/common/libfdt/libfdt.h
 create mode 100644 xen/common/libfdt/libfdt_env.h
 create mode 100644 xen/common/libfdt/libfdt_internal.h
 create mode 100644 xen/common/libfdt/version.lds

diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
new file mode 100644
index 0000000..d55a6f8
--- /dev/null
+++ b/xen/common/libfdt/Makefile.libfdt
@@ -0,0 +1,10 @@
+# Makefile.libfdt
+#
+# This is not a complete Makefile of itself.  Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_VERSION = version.lds
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
new file mode 100644
index 0000000..288437e
--- /dev/null
+++ b/xen/common/libfdt/TODO
@@ -0,0 +1,3 @@
+- Tree traversal functions
+- Graft function
+- Complete libfdt.h documenting comments
diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
new file mode 100644
index 0000000..e56833a
--- /dev/null
+++ b/xen/common/libfdt/fdt.c
@@ -0,0 +1,222 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_check_header(const void *fdt)
+{
+	if (fdt_magic(fdt) == FDT_MAGIC) {
+		/* Complete tree */
+		if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+		if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+	} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+		/* Unfinished sequential-write blob */
+		if (fdt_size_dt_struct(fdt) == 0)
+			return -FDT_ERR_BADSTATE;
+	} else {
+		return -FDT_ERR_BADMAGIC;
+	}
+
+	return 0;
+}
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
+{
+	const char *p;
+
+	if (fdt_version(fdt) >= 0x11)
+		if (((offset + len) < offset)
+		    || ((offset + len) > fdt_size_dt_struct(fdt)))
+			return NULL;
+
+	p = _fdt_offset_ptr(fdt, offset);
+
+	if (p + len < p)
+		return NULL;
+	return p;
+}
+
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+	const uint32_t *tagp, *lenp;
+	uint32_t tag;
+	int offset = startoffset;
+	const char *p;
+
+	*nextoffset = -FDT_ERR_TRUNCATED;
+	tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
+	if (!tagp)
+		return FDT_END; /* premature end */
+	tag = fdt32_to_cpu(*tagp);
+	offset += FDT_TAGSIZE;
+
+	*nextoffset = -FDT_ERR_BADSTRUCTURE;
+	switch (tag) {
+	case FDT_BEGIN_NODE:
+		/* skip name */
+		do {
+			p = fdt_offset_ptr(fdt, offset++, 1);
+		} while (p && (*p != '\0'));
+		if (!p)
+			return FDT_END; /* premature end */
+		break;
+
+	case FDT_PROP:
+		lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
+		if (!lenp)
+			return FDT_END; /* premature end */
+		/* skip-name offset, length and value */
+		offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+			+ fdt32_to_cpu(*lenp);
+		break;
+
+	case FDT_END:
+	case FDT_END_NODE:
+	case FDT_NOP:
+		break;
+
+	default:
+		return FDT_END;
+	}
+
+	if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
+		return FDT_END; /* premature end */
+
+	*nextoffset = FDT_TAGALIGN(offset);
+	return tag;
+}
+
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int _fdt_check_prop_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int fdt_next_node(const void *fdt, int offset, int *depth)
+{
+	int nextoffset = 0;
+	uint32_t tag;
+
+	if (offset >= 0)
+		if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+			return nextoffset;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_PROP:
+		case FDT_NOP:
+			break;
+
+		case FDT_BEGIN_NODE:
+			if (depth)
+				(*depth)++;
+			break;
+
+		case FDT_END_NODE:
+			if (depth && ((--(*depth)) < 0))
+				return nextoffset;
+			break;
+
+		case FDT_END:
+			if ((nextoffset >= 0)
+			    || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
+				return -FDT_ERR_NOTFOUND;
+			else
+				return nextoffset;
+		}
+	} while (tag != FDT_BEGIN_NODE);
+
+	return offset;
+}
+
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+{
+	int len = strlen(s) + 1;
+	const char *last = strtab + tabsize - len;
+	const char *p;
+
+	for (p = strtab; p <= last; p++)
+		if (memcmp(p, s, len) == 0)
+			return p;
+	return NULL;
+}
+
+int fdt_move(const void *fdt, void *buf, int bufsize)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_totalsize(fdt) > bufsize)
+		return -FDT_ERR_NOSPACE;
+
+	memmove(buf, fdt, fdt_totalsize(fdt));
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
new file mode 100644
index 0000000..48ccfd9
--- /dev/null
+++ b/xen/common/libfdt/fdt.h
@@ -0,0 +1,60 @@
+#ifndef _FDT_H
+#define _FDT_H
+
+#ifndef __ASSEMBLY__
+
+struct fdt_header {
+	uint32_t magic;			 /* magic word FDT_MAGIC */
+	uint32_t totalsize;		 /* total size of DT block */
+	uint32_t off_dt_struct;		 /* offset to structure */
+	uint32_t off_dt_strings;	 /* offset to strings */
+	uint32_t off_mem_rsvmap;	 /* offset to memory reserve map */
+	uint32_t version;		 /* format version */
+	uint32_t last_comp_version;	 /* last compatible version */
+
+	/* version 2 fields below */
+	uint32_t boot_cpuid_phys;	 /* Which physical CPU id we're
+					    booting on */
+	/* version 3 fields below */
+	uint32_t size_dt_strings;	 /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;	 /* size of the structure block */
+};
+
+struct fdt_reserve_entry {
+	uint64_t address;
+	uint64_t size;
+};
+
+struct fdt_node_header {
+	uint32_t tag;
+	char name[0];
+};
+
+struct fdt_property {
+	uint32_t tag;
+	uint32_t len;
+	uint32_t nameoff;
+	char data[0];
+};
+
+#endif /* !__ASSEMBLY */
+
+#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_TAGSIZE	sizeof(uint32_t)
+
+#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
+#define FDT_END_NODE	0x2		/* End node */
+#define FDT_PROP	0x3		/* Property: name off,
+					   size, content */
+#define FDT_NOP		0x4		/* nop */
+#define FDT_END		0x9
+
+#define FDT_V1_SIZE	(7*sizeof(uint32_t))
+#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(uint32_t))
+#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V16_SIZE	FDT_V3_SIZE
+#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(uint32_t))
+
+#endif /* _FDT_H */
diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
new file mode 100644
index 0000000..02b6d68
--- /dev/null
+++ b/xen/common/libfdt/fdt_ro.c
@@ -0,0 +1,574 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_nodename_eq(const void *fdt, int offset,
+			    const char *s, int len)
+{
+	const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+
+	if (! p)
+		/* short match */
+		return 0;
+
+	if (memcmp(p, s, len) != 0)
+		return 0;
+
+	if (p[len] == '\0')
+		return 1;
+	else if (!memchr(s, '@', len) && (p[len] == '@'))
+		return 1;
+	else
+		return 0;
+}
+
+const char *fdt_string(const void *fdt, int stroffset)
+{
+	return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+}
+
+static int _fdt_string_eq(const void *fdt, int stroffset,
+			  const char *s, int len)
+{
+	const char *p = fdt_string(fdt, stroffset);
+
+	return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+}
+
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
+{
+	FDT_CHECK_HEADER(fdt);
+	*address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
+	*size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+	return 0;
+}
+
+int fdt_num_mem_rsv(const void *fdt)
+{
+	int i = 0;
+
+	while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+		i++;
+	return i;
+}
+
+static int _nextprop(const void *fdt, int offset)
+{
+	uint32_t tag;
+	int nextoffset;
+
+	do {
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_END:
+			if (nextoffset >= 0)
+				return -FDT_ERR_BADSTRUCTURE;
+			else
+				return nextoffset;
+
+		case FDT_PROP:
+			return offset;
+		}
+		offset = nextoffset;
+	} while (tag == FDT_NOP);
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
+			       const char *name, int namelen)
+{
+	int depth;
+
+	FDT_CHECK_HEADER(fdt);
+
+	for (depth = 0;
+	     (offset >= 0) && (depth >= 0);
+	     offset = fdt_next_node(fdt, offset, &depth))
+		if ((depth == 1)
+		    && _fdt_nodename_eq(fdt, offset, name, namelen))
+			return offset;
+
+	if (depth < 0)
+		return -FDT_ERR_NOTFOUND;
+	return offset; /* error */
+}
+
+int fdt_subnode_offset(const void *fdt, int parentoffset,
+		       const char *name)
+{
+	return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_path_offset(const void *fdt, const char *path)
+{
+	const char *end = path + strlen(path);
+	const char *p = path;
+	int offset = 0;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* see if we have an alias */
+	if (*path != '/') {
+		const char *q = strchr(path, '/');
+
+		if (!q)
+			q = end;
+
+		p = fdt_get_alias_namelen(fdt, p, q - p);
+		if (!p)
+			return -FDT_ERR_BADPATH;
+		offset = fdt_path_offset(fdt, p);
+
+		p = q;
+	}
+
+	while (*p) {
+		const char *q;
+
+		while (*p == '/')
+			p++;
+		if (! *p)
+			return offset;
+		q = strchr(p, '/');
+		if (! q)
+			q = end;
+
+		offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
+		if (offset < 0)
+			return offset;
+
+		p = q;
+	}
+
+	return offset;
+}
+
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+	const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
+	int err;
+
+	if (((err = fdt_check_header(fdt)) != 0)
+	    || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+			goto fail;
+
+	if (len)
+		*len = strlen(nh->name);
+
+	return nh->name;
+
+ fail:
+	if (len)
+		*len = err;
+	return NULL;
+}
+
+int fdt_first_property_offset(const void *fdt, int nodeoffset)
+{
+	int offset;
+
+	if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+int fdt_next_property_offset(const void *fdt, int offset)
+{
+	if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp)
+{
+	int err;
+	const struct fdt_property *prop;
+
+	if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
+		if (lenp)
+			*lenp = err;
+		return NULL;
+	}
+
+	prop = _fdt_offset_ptr(fdt, offset);
+
+	if (lenp)
+		*lenp = fdt32_to_cpu(prop->len);
+
+	return prop;
+}
+
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int offset,
+						    const char *name,
+						    int namelen, int *lenp)
+{
+	for (offset = fdt_first_property_offset(fdt, offset);
+	     (offset >= 0);
+	     (offset = fdt_next_property_offset(fdt, offset))) {
+		const struct fdt_property *prop;
+
+		if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
+			offset = -FDT_ERR_INTERNAL;
+			break;
+		}
+		if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
+				   name, namelen))
+			return prop;
+	}
+
+	if (lenp)
+		*lenp = offset;
+	return NULL;
+}
+
+const struct fdt_property *fdt_get_property(const void *fdt,
+					    int nodeoffset,
+					    const char *name, int *lenp)
+{
+	return fdt_get_property_namelen(fdt, nodeoffset, name,
+					strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
+	if (! prop)
+		return NULL;
+
+	return prop->data;
+}
+
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_by_offset(fdt, offset, lenp);
+	if (!prop)
+		return NULL;
+	if (namep)
+		*namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+	return prop->data;
+}
+
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp)
+{
+	return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
+{
+	const uint32_t *php;
+	int len;
+
+	/* FIXME: This is a bit sub-optimal, since we potentially scan
+	 * over all the properties twice. */
+	php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
+	if (!php || (len != sizeof(*php))) {
+		php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
+		if (!php || (len != sizeof(*php)))
+			return 0;
+	}
+
+	return fdt32_to_cpu(*php);
+}
+
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen)
+{
+	int aliasoffset;
+
+	aliasoffset = fdt_path_offset(fdt, "/aliases");
+	if (aliasoffset < 0)
+		return NULL;
+
+	return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+	return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+	int pdepth = 0, p = 0;
+	int offset, depth, namelen;
+	const char *name;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (buflen < 2)
+		return -FDT_ERR_NOSPACE;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		while (pdepth > depth) {
+			do {
+				p--;
+			} while (buf[p-1] != '/');
+			pdepth--;
+		}
+
+		if (pdepth >= depth) {
+			name = fdt_get_name(fdt, offset, &namelen);
+			if (!name)
+				return namelen;
+			if ((p + namelen + 1) <= buflen) {
+				memcpy(buf + p, name, namelen);
+				p += namelen;
+				buf[p++] = '/';
+				pdepth++;
+			}
+		}
+
+		if (offset == nodeoffset) {
+			if (pdepth < (depth + 1))
+				return -FDT_ERR_NOSPACE;
+
+			if (p > 1) /* special case so that root path is "/", not "" */
+				p--;
+			buf[p] = '\0';
+			return 0;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth)
+{
+	int offset, depth;
+	int supernodeoffset = -FDT_ERR_INTERNAL;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (supernodedepth < 0)
+		return -FDT_ERR_NOTFOUND;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		if (depth == supernodedepth)
+			supernodeoffset = offset;
+
+		if (offset == nodeoffset) {
+			if (nodedepth)
+				*nodedepth = depth;
+
+			if (supernodedepth > depth)
+				return -FDT_ERR_NOTFOUND;
+			else
+				return supernodeoffset;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+	int nodedepth;
+	int err;
+
+	err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+	if (err)
+		return (err < 0) ? err : -FDT_ERR_INTERNAL;
+	return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+	int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+	if (nodedepth < 0)
+		return nodedepth;
+	return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+					    nodedepth - 1, NULL);
+}
+
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen)
+{
+	int offset;
+	const void *val;
+	int len;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_getprop(), then if that didn't
+	 * find what we want, we scan over them again making our way
+	 * to the next node.  Still it's the easiest to implement
+	 * approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		val = fdt_getprop(fdt, offset, propname, &len);
+		if (val && (len == proplen)
+		    && (memcmp(val, propval, len) == 0))
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
+{
+	int offset;
+
+	if ((phandle == 0) || (phandle == -1))
+		return -FDT_ERR_BADPHANDLE;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we
+	 * potentially scan each property of a node in
+	 * fdt_get_phandle(), then if that didn't find what
+	 * we want, we scan over them again making our way to the next
+	 * node.  Still it's the easiest to implement approach;
+	 * performance can come later. */
+	for (offset = fdt_next_node(fdt, -1, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		if (fdt_get_phandle(fdt, offset) == phandle)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+				    const char *str)
+{
+	int len = strlen(str);
+	const char *p;
+
+	while (listlen >= len) {
+		if (memcmp(str, strlist, len+1) == 0)
+			return 1;
+		p = memchr(strlist, '\0', listlen);
+		if (!p)
+			return 0; /* malformed strlist.. */
+		listlen -= (p-strlist) + 1;
+		strlist = p + 1;
+	}
+	return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible)
+{
+	const void *prop;
+	int len;
+
+	prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+	if (!prop)
+		return len;
+	if (_fdt_stringlist_contains(prop, len, compatible))
+		return 0;
+	else
+		return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible)
+{
+	int offset, err;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_node_check_compatible(), then if
+	 * that didn't find what we want, we scan over them again
+	 * making our way to the next node.  Still it's the easiest to
+	 * implement approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		err = fdt_node_check_compatible(fdt, offset, compatible);
+		if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
+			return err;
+		else if (err == 0)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
new file mode 100644
index 0000000..994037b
--- /dev/null
+++ b/xen/common/libfdt/fdt_rw.c
@@ -0,0 +1,465 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_blocks_misordered(const void *fdt,
+			      int mem_rsv_size, int struct_size)
+{
+	return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
+		|| (fdt_off_dt_struct(fdt) <
+		    (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
+		|| (fdt_off_dt_strings(fdt) <
+		    (fdt_off_dt_struct(fdt) + struct_size))
+		|| (fdt_totalsize(fdt) <
+		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
+}
+
+static int _fdt_rw_check_header(void *fdt)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_version(fdt) < 17)
+		return -FDT_ERR_BADVERSION;
+	if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
+				   fdt_size_dt_struct(fdt)))
+		return -FDT_ERR_BADLAYOUT;
+	if (fdt_version(fdt) > 17)
+		fdt_set_version(fdt, 17);
+
+	return 0;
+}
+
+#define FDT_RW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_rw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static inline int _fdt_data_size(void *fdt)
+{
+	return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+}
+
+static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
+{
+	char *p = splicepoint;
+	char *end = (char *)fdt + _fdt_data_size(fdt);
+
+	if (((p + oldlen) < p) || ((p + oldlen) > end))
+		return -FDT_ERR_BADOFFSET;
+	if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
+		return -FDT_ERR_NOSPACE;
+	memmove(p + newlen, p + oldlen, end - p - oldlen);
+	return 0;
+}
+
+static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
+			       int oldn, int newn)
+{
+	int delta = (newn - oldn) * sizeof(*p);
+	int err;
+	err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
+	if (err)
+		return err;
+	fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_struct(void *fdt, void *p,
+			      int oldlen, int newlen)
+{
+	int delta = newlen - oldlen;
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
+		return err;
+
+	fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_string(void *fdt, int newlen)
+{
+	void *p = (char *)fdt
+		+ fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, 0, newlen)))
+		return err;
+
+	fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
+	const char *p;
+	char *new;
+	int len = strlen(s) + 1;
+	int err;
+
+	p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
+	if (p)
+		/* found it */
+		return (p - strtab);
+
+	new = strtab + fdt_size_dt_strings(fdt);
+	err = _fdt_splice_string(fdt, len);
+	if (err)
+		return err;
+
+	memcpy(new, s, len);
+	return (new - strtab);
+}
+
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
+	err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
+	if (err)
+		return err;
+
+	re->address = cpu_to_fdt64(address);
+	re->size = cpu_to_fdt64(size);
+	return 0;
+}
+
+int fdt_del_mem_rsv(void *fdt, int n)
+{
+	struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	if (n >= fdt_num_mem_rsv(fdt))
+		return -FDT_ERR_NOTFOUND;
+
+	err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
+	if (err)
+		return err;
+	return 0;
+}
+
+static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
+				int len, struct fdt_property **prop)
+{
+	int oldlen;
+	int err;
+
+	*prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
+	if (! (*prop))
+		return oldlen;
+
+	if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
+				      FDT_TAGALIGN(len))))
+		return err;
+
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
+			     int len, struct fdt_property **prop)
+{
+	int proplen;
+	int nextoffset;
+	int namestroff;
+	int err;
+
+	if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return nextoffset;
+
+	namestroff = _fdt_find_add_string(fdt, name);
+	if (namestroff < 0)
+		return namestroff;
+
+	*prop = _fdt_offset_ptr_w(fdt, nextoffset);
+	proplen = sizeof(**prop) + FDT_TAGALIGN(len);
+
+	err = _fdt_splice_struct(fdt, *prop, 0, proplen);
+	if (err)
+		return err;
+
+	(*prop)->tag = cpu_to_fdt32(FDT_PROP);
+	(*prop)->nameoff = cpu_to_fdt32(namestroff);
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+	char *namep;
+	int oldlen, newlen;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
+	if (!namep)
+		return oldlen;
+
+	newlen = strlen(name);
+
+	err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
+				 FDT_TAGALIGN(newlen+1));
+	if (err)
+		return err;
+
+	memcpy(namep, name, newlen+1);
+	return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len)
+{
+	struct fdt_property *prop;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
+	if (err == -FDT_ERR_NOTFOUND)
+		err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
+	if (err)
+		return err;
+
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_delprop(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len, proplen;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	proplen = sizeof(*prop) + FDT_TAGALIGN(len);
+	return _fdt_splice_struct(fdt, prop, proplen, 0);
+}
+
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen)
+{
+	struct fdt_node_header *nh;
+	int offset, nextoffset;
+	int nodelen;
+	int err;
+	uint32_t tag;
+	uint32_t *endtag;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
+	if (offset >= 0)
+		return -FDT_ERR_EXISTS;
+	else if (offset != -FDT_ERR_NOTFOUND)
+		return offset;
+
+	/* Try to place the new node after the parent's properties */
+	fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+	} while ((tag == FDT_PROP) || (tag == FDT_NOP));
+
+	nh = _fdt_offset_ptr_w(fdt, offset);
+	nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
+
+	err = _fdt_splice_struct(fdt, nh, 0, nodelen);
+	if (err)
+		return err;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
+	memcpy(nh->name, name, namelen);
+	endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
+	*endtag = cpu_to_fdt32(FDT_END_NODE);
+
+	return offset;
+}
+
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
+{
+	return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_del_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
+				  endoffset - nodeoffset, 0);
+}
+
+static void _fdt_packblocks(const char *old, char *new,
+			    int mem_rsv_size, int struct_size)
+{
+	int mem_rsv_off, struct_off, strings_off;
+
+	mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
+	struct_off = mem_rsv_off + mem_rsv_size;
+	strings_off = struct_off + struct_size;
+
+	memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
+	fdt_set_off_mem_rsvmap(new, mem_rsv_off);
+
+	memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
+	fdt_set_off_dt_struct(new, struct_off);
+	fdt_set_size_dt_struct(new, struct_size);
+
+	memmove(new + strings_off, old + fdt_off_dt_strings(old),
+		fdt_size_dt_strings(old));
+	fdt_set_off_dt_strings(new, strings_off);
+	fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
+}
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize)
+{
+	int err;
+	int mem_rsv_size, struct_size;
+	int newsize;
+	const char *fdtstart = fdt;
+	const char *fdtend = fdtstart + fdt_totalsize(fdt);
+	char *tmp;
+
+	FDT_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+
+	if (fdt_version(fdt) >= 17) {
+		struct_size = fdt_size_dt_struct(fdt);
+	} else {
+		struct_size = 0;
+		while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
+			;
+		if (struct_size < 0)
+			return struct_size;
+	}
+
+	if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
+		/* no further work necessary */
+		err = fdt_move(fdt, buf, bufsize);
+		if (err)
+			return err;
+		fdt_set_version(buf, 17);
+		fdt_set_size_dt_struct(buf, struct_size);
+		fdt_set_totalsize(buf, bufsize);
+		return 0;
+	}
+
+	/* Need to reorder */
+	newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
+		+ struct_size + fdt_size_dt_strings(fdt);
+
+	if (bufsize < newsize)
+		return -FDT_ERR_NOSPACE;
+
+	/* First attempt to build converted tree at beginning of buffer */
+	tmp = buf;
+	/* But if that overlaps with the old tree... */
+	if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
+		/* Try right after the old tree instead */
+		tmp = (char *)(uintptr_t)fdtend;
+		if ((tmp + newsize) > ((char *)buf + bufsize))
+			return -FDT_ERR_NOSPACE;
+	}
+
+	_fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
+	memmove(buf, tmp, newsize);
+
+	fdt_set_magic(buf, FDT_MAGIC);
+	fdt_set_totalsize(buf, bufsize);
+	fdt_set_version(buf, 17);
+	fdt_set_last_comp_version(buf, 16);
+	fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
+
+	return 0;
+}
+
+int fdt_pack(void *fdt)
+{
+	int mem_rsv_size;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+	_fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
+	fdt_set_totalsize(fdt, _fdt_data_size(fdt));
+
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
new file mode 100644
index 0000000..e6c3cee
--- /dev/null
+++ b/xen/common/libfdt/fdt_strerror.c
@@ -0,0 +1,96 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+struct fdt_errtabent {
+	const char *str;
+};
+
+#define FDT_ERRTABENT(val) \
+	[(val)] = { .str = #val, }
+
+static struct fdt_errtabent fdt_errtable[] = {
+	FDT_ERRTABENT(FDT_ERR_NOTFOUND),
+	FDT_ERRTABENT(FDT_ERR_EXISTS),
+	FDT_ERRTABENT(FDT_ERR_NOSPACE),
+
+	FDT_ERRTABENT(FDT_ERR_BADOFFSET),
+	FDT_ERRTABENT(FDT_ERR_BADPATH),
+	FDT_ERRTABENT(FDT_ERR_BADSTATE),
+
+	FDT_ERRTABENT(FDT_ERR_TRUNCATED),
+	FDT_ERRTABENT(FDT_ERR_BADMAGIC),
+	FDT_ERRTABENT(FDT_ERR_BADVERSION),
+	FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
+	FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+};
+#define FDT_ERRTABSIZE	(sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
+
+const char *fdt_strerror(int errval)
+{
+	if (errval > 0)
+		return "<valid offset/length>";
+	else if (errval == 0)
+		return "<no error>";
+	else if (errval > -FDT_ERRTABSIZE) {
+		const char *s = fdt_errtable[-errval].str;
+
+		if (s)
+			return s;
+	}
+
+	return "<unknown error>";
+}
diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
new file mode 100644
index 0000000..55ebebf
--- /dev/null
+++ b/xen/common/libfdt/fdt_sw.c
@@ -0,0 +1,256 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_sw_check_header(void *fdt)
+{
+	if (fdt_magic(fdt) != FDT_SW_MAGIC)
+		return -FDT_ERR_BADMAGIC;
+	/* FIXME: should check more details about the header state */
+	return 0;
+}
+
+#define FDT_SW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_sw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static void *_fdt_grab_space(void *fdt, size_t len)
+{
+	int offset = fdt_size_dt_struct(fdt);
+	int spaceleft;
+
+	spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
+		- fdt_size_dt_strings(fdt);
+
+	if ((offset + len < offset) || (offset + len > spaceleft))
+		return NULL;
+
+	fdt_set_size_dt_struct(fdt, offset + len);
+	return _fdt_offset_ptr_w(fdt, offset);
+}
+
+int fdt_create(void *buf, int bufsize)
+{
+	void *fdt = buf;
+
+	if (bufsize < sizeof(struct fdt_header))
+		return -FDT_ERR_NOSPACE;
+
+	memset(buf, 0, bufsize);
+
+	fdt_set_magic(fdt, FDT_SW_MAGIC);
+	fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+	fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+	fdt_set_totalsize(fdt,  bufsize);
+
+	fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
+					      sizeof(struct fdt_reserve_entry)));
+	fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
+	fdt_set_off_dt_strings(fdt, bufsize);
+
+	return 0;
+}
+
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int offset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	if (fdt_size_dt_struct(fdt))
+		return -FDT_ERR_BADSTATE;
+
+	offset = fdt_off_dt_struct(fdt);
+	if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
+		return -FDT_ERR_NOSPACE;
+
+	re = (struct fdt_reserve_entry *)((char *)fdt + offset);
+	re->address = cpu_to_fdt64(addr);
+	re->size = cpu_to_fdt64(size);
+
+	fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
+
+	return 0;
+}
+
+int fdt_finish_reservemap(void *fdt)
+{
+	return fdt_add_reservemap_entry(fdt, 0, 0);
+}
+
+int fdt_begin_node(void *fdt, const char *name)
+{
+	struct fdt_node_header *nh;
+	int namelen = strlen(name) + 1;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
+	if (! nh)
+		return -FDT_ERR_NOSPACE;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memcpy(nh->name, name, namelen);
+	return 0;
+}
+
+int fdt_end_node(void *fdt)
+{
+	uint32_t *en;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	en = _fdt_grab_space(fdt, FDT_TAGSIZE);
+	if (! en)
+		return -FDT_ERR_NOSPACE;
+
+	*en = cpu_to_fdt32(FDT_END_NODE);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_totalsize(fdt);
+	const char *p;
+	int strtabsize = fdt_size_dt_strings(fdt);
+	int len = strlen(s) + 1;
+	int struct_top, offset;
+
+	p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
+	if (p)
+		return p - strtab;
+
+	/* Add it */
+	offset = -strtabsize - len;
+	struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	if (fdt_totalsize(fdt) + offset < struct_top)
+		return 0; /* no more room :( */
+
+	memcpy(strtab + offset, s, len);
+	fdt_set_size_dt_strings(fdt, strtabsize + len);
+	return offset;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+	struct fdt_property *prop;
+	int nameoff;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nameoff = _fdt_find_add_string(fdt, name);
+	if (nameoff == 0)
+		return -FDT_ERR_NOSPACE;
+
+	prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
+	if (! prop)
+		return -FDT_ERR_NOSPACE;
+
+	prop->tag = cpu_to_fdt32(FDT_PROP);
+	prop->nameoff = cpu_to_fdt32(nameoff);
+	prop->len = cpu_to_fdt32(len);
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_finish(void *fdt)
+{
+	char *p = (char *)fdt;
+	uint32_t *end;
+	int oldstroffset, newstroffset;
+	uint32_t tag;
+	int offset, nextoffset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	/* Add terminator */
+	end = _fdt_grab_space(fdt, sizeof(*end));
+	if (! end)
+		return -FDT_ERR_NOSPACE;
+	*end = cpu_to_fdt32(FDT_END);
+
+	/* Relocate the string table */
+	oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
+	newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
+	fdt_set_off_dt_strings(fdt, newstroffset);
+
+	/* Walk the structure, correcting string offsets */
+	offset = 0;
+	while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
+		if (tag == FDT_PROP) {
+			struct fdt_property *prop =
+				_fdt_offset_ptr_w(fdt, offset);
+			int nameoff;
+
+			nameoff = fdt32_to_cpu(prop->nameoff);
+			nameoff += fdt_size_dt_strings(fdt);
+			prop->nameoff = cpu_to_fdt32(nameoff);
+		}
+		offset = nextoffset;
+	}
+	if (nextoffset < 0)
+		return nextoffset;
+
+	/* Finally, adjust the header */
+	fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
+	fdt_set_magic(fdt, FDT_MAGIC);
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
new file mode 100644
index 0000000..6025fa1
--- /dev/null
+++ b/xen/common/libfdt/fdt_wip.c
@@ -0,0 +1,118 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len)
+{
+	void *propval;
+	int proplen;
+
+	propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
+	if (! propval)
+		return proplen;
+
+	if (proplen != len)
+		return -FDT_ERR_NOSPACE;
+
+	memcpy(propval, val, len);
+	return 0;
+}
+
+static void _fdt_nop_region(void *start, int len)
+{
+	uint32_t *p;
+
+	for (p = start; (char *)p < ((char *)start + len); p++)
+		*p = cpu_to_fdt32(FDT_NOP);
+}
+
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len;
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	_fdt_nop_region(prop, len + sizeof(*prop));
+
+	return 0;
+}
+
+int _fdt_node_end_offset(void *fdt, int offset)
+{
+	int depth = 0;
+
+	while ((offset >= 0) && (depth >= 0))
+		offset = fdt_next_node(fdt, offset, &depth);
+
+	return offset;
+}
+
+int fdt_nop_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	_fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
+			endoffset - nodeoffset);
+	return 0;
+}
diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
new file mode 100644
index 0000000..55f3eb3
--- /dev/null
+++ b/xen/common/libfdt/libfdt.h
@@ -0,0 +1,1235 @@
+#ifndef _LIBFDT_H
+#define _LIBFDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <libfdt_env.h>
+#include <fdt.h>
+
+#define FDT_FIRST_SUPPORTED_VERSION	0x10
+#define FDT_LAST_SUPPORTED_VERSION	0x11
+
+/* Error codes: informative error codes */
+#define FDT_ERR_NOTFOUND	1
+	/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
+#define FDT_ERR_EXISTS		2
+	/* FDT_ERR_EXISTS: Attemped to create a node or property which
+	 * already exists */
+#define FDT_ERR_NOSPACE		3
+	/* FDT_ERR_NOSPACE: Operation needed to expand the device
+	 * tree, but its buffer did not have sufficient space to
+	 * contain the expanded tree. Use fdt_open_into() to move the
+	 * device tree to a buffer with more space. */
+
+/* Error codes: codes for bad parameters */
+#define FDT_ERR_BADOFFSET	4
+	/* FDT_ERR_BADOFFSET: Function was passed a structure block
+	 * offset which is out-of-bounds, or which points to an
+	 * unsuitable part of the structure for the operation. */
+#define FDT_ERR_BADPATH		5
+	/* FDT_ERR_BADPATH: Function was passed a badly formatted path
+	 * (e.g. missing a leading / for a function which requires an
+	 * absolute path) */
+#define FDT_ERR_BADPHANDLE	6
+	/* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
+	 * value.  phandle values of 0 and -1 are not permitted. */
+#define FDT_ERR_BADSTATE	7
+	/* FDT_ERR_BADSTATE: Function was passed an incomplete device
+	 * tree created by the sequential-write functions, which is
+	 * not sufficiently complete for the requested operation. */
+
+/* Error codes: codes for bad device tree blobs */
+#define FDT_ERR_TRUNCATED	8
+	/* FDT_ERR_TRUNCATED: Structure block of the given device tree
+	 * ends without an FDT_END tag. */
+#define FDT_ERR_BADMAGIC	9
+	/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+	 * device tree at all - it is missing the flattened device
+	 * tree magic number. */
+#define FDT_ERR_BADVERSION	10
+	/* FDT_ERR_BADVERSION: Given device tree has a version which
+	 * can't be handled by the requested operation.  For
+	 * read-write functions, this may mean that fdt_open_into() is
+	 * required to convert the tree to the expected version. */
+#define FDT_ERR_BADSTRUCTURE	11
+	/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+	 * structure block or other serious error (e.g. misnested
+	 * nodes, or subnodes preceding properties). */
+#define FDT_ERR_BADLAYOUT	12
+	/* FDT_ERR_BADLAYOUT: For read-write functions, the given
+	 * device tree has it's sub-blocks in an order that the
+	 * function can't handle (memory reserve map, then structure,
+	 * then strings).  Use fdt_open_into() to reorganize the tree
+	 * into a form suitable for the read-write operations. */
+
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL	13
+	/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+	 * Should never be returned, if it is, it indicates a bug in
+	 * libfdt itself. */
+
+#define FDT_ERR_MAX		13
+
+/**********************************************************************/
+/* Low-level functions (you probably don't need these)                */
+/**********************************************************************/
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
+{
+	return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
+}
+
+uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+
+/**********************************************************************/
+/* Traversal functions                                                */
+/**********************************************************************/
+
+int fdt_next_node(const void *fdt, int offset, int *depth);
+
+/**********************************************************************/
+/* General functions                                                  */
+/**********************************************************************/
+
+#define fdt_get_header(fdt, field) \
+	(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
+#define fdt_magic(fdt) 			(fdt_get_header(fdt, magic))
+#define fdt_totalsize(fdt)		(fdt_get_header(fdt, totalsize))
+#define fdt_off_dt_struct(fdt)		(fdt_get_header(fdt, off_dt_struct))
+#define fdt_off_dt_strings(fdt)		(fdt_get_header(fdt, off_dt_strings))
+#define fdt_off_mem_rsvmap(fdt)		(fdt_get_header(fdt, off_mem_rsvmap))
+#define fdt_version(fdt)		(fdt_get_header(fdt, version))
+#define fdt_last_comp_version(fdt) 	(fdt_get_header(fdt, last_comp_version))
+#define fdt_boot_cpuid_phys(fdt) 	(fdt_get_header(fdt, boot_cpuid_phys))
+#define fdt_size_dt_strings(fdt) 	(fdt_get_header(fdt, size_dt_strings))
+#define fdt_size_dt_struct(fdt)		(fdt_get_header(fdt, size_dt_struct))
+
+#define __fdt_set_hdr(name) \
+	static inline void fdt_set_##name(void *fdt, uint32_t val) \
+	{ \
+		struct fdt_header *fdth = (struct fdt_header*)fdt; \
+		fdth->name = cpu_to_fdt32(val); \
+	}
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
+
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ *     0, if the buffer appears to contain a valid device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings, as above
+ */
+int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize.  The buffer may overlap
+ * with the existing device tree blob at fdt.  Therefore,
+ *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_move(const void *fdt, void *buf, int bufsize);
+
+/**********************************************************************/
+/* Read-only functions                                                */
+/**********************************************************************/
+
+/**
+ * fdt_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ *     a pointer to the string, on success
+ *     NULL, if stroffset is out of bounds
+ */
+const char *fdt_string(const void *fdt, int stroffset);
+
+/**
+ * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map.  This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ *     the number of entries
+ */
+int fdt_num_mem_rsv(const void *fdt);
+
+/**
+ * fdt_get_mem_rsv - retrieve one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
+/**
+ * fdt_subnode_offset_namelen - find a subnode based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_subnode_offset(), but only examine the first
+ * namelen characters of name for matching the subnode name.  This is
+ * useful for finding subnodes based on a portion of a larger string,
+ * such as a full path.
+ */
+int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+			       const char *name, int namelen);
+/**
+ * fdt_subnode_offset - find a subnode of a given node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_subnode_offset() finds a subnode of the node at structure block
+ * offset parentoffset with the given name.  name may include a unit
+ * address, in which case fdt_subnode_offset() will find the subnode
+ * with that unit address, or the unit address may be omitted, in
+ * which case fdt_subnode_offset() will find an arbitrary subnode
+ * whose name excluding unit address matches the given name.
+ *
+ * returns:
+ *	structure block offset of the requested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_path_offset - find a tree node by its full path
+ * @fdt: pointer to the device tree blob
+ * @path: full path of the node to locate
+ *
+ * fdt_path_offset() finds a node of a given path in the device tree.
+ * Each path component may omit the unit address portion, but the
+ * results of this are undefined if any such path component is
+ * ambiguous (that is if there are multiple nodes at the relevant
+ * level matching the given component, differentiated only by unit
+ * address).
+ *
+ * returns:
+ *	structure block offset of the node with the requested path (>=0), on success
+ *	-FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
+ *	-FDT_ERR_NOTFOUND, if the requested node does not exist
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_path_offset(const void *fdt, const char *path);
+
+/**
+ * fdt_get_name - retrieve the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the starting node
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_name() retrieves the name (including unit address) of the
+ * device tree node at structure block offset nodeoffset.  If lenp is
+ * non-NULL, the length of this name is also returned, in the integer
+ * pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the node's name, on success
+ *		If lenp is non-NULL, *lenp contains the length of that name (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE, standard meanings
+ */
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+
+/**
+ * fdt_first_property_offset - find the offset of a node's first property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ *
+ * fdt_first_property_offset() finds the first property of the node at
+ * the given structure block offset.
+ *
+ * returns:
+ *	structure block offset of the property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested node has no properties
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_first_property_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_next_property_offset - step through a node's properties
+ * @fdt: pointer to the device tree blob
+ * @offset: structure block offset of a property
+ *
+ * fdt_next_property_offset() finds the property immediately after the
+ * one at the given structure block offset.  This will be a property
+ * of the same node as the given property.
+ *
+ * returns:
+ *	structure block offset of the next property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the given property is the last in its node
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_next_property_offset(const void *fdt, int offset);
+
+/**
+ * fdt_get_property_by_offset - retrieve the property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @offset: offset of the property to retrieve
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property_by_offset() retrieves a pointer to the
+ * fdt_property structure within the device tree blob at the given
+ * offset.  If lenp is non-NULL, the length of the property value is
+ * also returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp);
+
+/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int nodeoffset,
+						    const char *name,
+						    int namelen, int *lenp);
+
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset.  If lenp is
+ * non-NULL, the length of the property value is also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
+					    const char *name, int *lenp);
+static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
+						      const char *name,
+						      int *lenp)
+{
+	return (struct fdt_property *)(uintptr_t)
+		fdt_get_property(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_getprop_by_offset - retrieve the value of a property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @ffset: offset of the property to read
+ * @namep: pointer to a string variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop_by_offset() retrieves a pointer to the value of the
+ * property at structure block offset 'offset' (this will be a pointer
+ * to within the device blob itself, not a copy of the value).  If
+ * lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.  If namep is non-NULL,
+ * the property's namne will also be returned in the char * pointed to
+ * by namep (this will be a pointer to within the device tree's string
+ * block, not a new copy of the name).
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *		if namep is non-NULL *namep contiains a pointer to the property
+ *		name.
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp);
+
+/**
+ * fdt_getprop_namelen - get property value based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_getprop(), but only examine the first namelen
+ * characters of name for matching the property name.
+ */
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp);
+
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp);
+static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
+				  const char *name, int *lenp)
+{
+	return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_get_phandle - retrieve the phandle of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the node
+ *
+ * fdt_get_phandle() retrieves the phandle of the device tree node at
+ * structure block offset nodeoffset.
+ *
+ * returns:
+ *	the phandle of the node at nodeoffset, on success (!= 0, != -1)
+ *	0, if the node has no phandle, or another error occurs
+ */
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_get_alias_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias.  That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ *	a pointer to the expansion of the alias named 'name', of it exists
+ *	NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	0, on success
+ *		buf contains the absolute path of the node at
+ *		nodeoffset, as a NUL-terminated string.
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ *		characters and will not fit in the given buffer.
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth).  So
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node.  If the node at
+ * nodeoffset has depth D, then:
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ *	structure block offset of the node at node offset's ancestor
+ *		of depth supernodedepth (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+*	-FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node.  The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	depth of the node at nodeoffset (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ *	structure block offset of the parent of the node at nodeoffset
+ *		(>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_node_offset_by_prop_value - find nodes with a given property value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @propname: property name to check
+ * @propval: property value to search for
+ * @proplen: length of the value in propval
+ *
+ * fdt_node_offset_by_prop_value() returns the offset of the first
+ * node after startoffset, which has a property named propname whose
+ * value is of length proplen and has value equal to propval; or if
+ * startoffset is -1, the very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
+ *					       propval, proplen);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
+ *						       propval, proplen);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen);
+
+/**
+ * fdt_node_offset_by_phandle - find the node with a given phandle
+ * @fdt: pointer to the device tree blob
+ * @phandle: phandle value
+ *
+ * fdt_node_offset_by_phandle() returns the offset of the node
+ * which has the given phandle value.  If there is more than one node
+ * in the tree with the given phandle (an invalid tree), results are
+ * undefined.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0), on success
+ *	-FDT_ERR_NOTFOUND, no node with that phandle exists
+ *	-FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
+
+/**
+ * fdt_node_check_compatible: check a node's compatible property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ *	0, if the node has a 'compatible' property listing the given string
+ *	1, if the node has a 'compatible' property, but it does not list
+ *		the given string
+ *	-FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * 	-FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible);
+
+/**
+ * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @compatible: 'compatible' string to match against
+ *
+ * fdt_node_offset_by_compatible() returns the offset of the first
+ * node after startoffset, which has a 'compatible' property which
+ * lists the given compatible string; or if startoffset is -1, the
+ * very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible);
+
+/**********************************************************************/
+/* Write-in-place functions                                           */
+/**********************************************************************/
+
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+					   const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Sequential write functions                                         */
+/**********************************************************************/
+
+int fdt_create(void *buf, int bufsize);
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
+int fdt_finish_reservemap(void *fdt);
+int fdt_begin_node(void *fdt, const char *name);
+int fdt_property(void *fdt, const char *name, const void *val, int len);
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_property(fdt, name, &val, sizeof(val));
+}
+#define fdt_property_string(fdt, name, str) \
+	fdt_property(fdt, name, str, strlen(str)+1)
+int fdt_end_node(void *fdt);
+int fdt_finish(void *fdt);
+
+/**********************************************************************/
+/* Read-write functions                                               */
+/**********************************************************************/
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize);
+int fdt_pack(void *fdt);
+
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_mem_rsv(void *fdt, int n);
+
+/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string.  NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ *		to contain the new name
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+				   uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_string(fdt, nodeoffset, name, str) \
+	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Debugging / informational functions                                */
+/**********************************************************************/
+
+const char *fdt_strerror(int errval);
+
+#endif /* _LIBFDT_H */
diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
new file mode 100644
index 0000000..449bf60
--- /dev/null
+++ b/xen/common/libfdt/libfdt_env.h
@@ -0,0 +1,23 @@
+#ifndef _LIBFDT_ENV_H
+#define _LIBFDT_ENV_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <string.h>
+
+#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
+static inline uint32_t fdt32_to_cpu(uint32_t x)
+{
+	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
+}
+#define cpu_to_fdt32(x) fdt32_to_cpu(x)
+
+static inline uint64_t fdt64_to_cpu(uint64_t x)
+{
+	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
+		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
+}
+#define cpu_to_fdt64(x) fdt64_to_cpu(x)
+#undef _B
+
+#endif /* _LIBFDT_ENV_H */
diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
new file mode 100644
index 0000000..381133b
--- /dev/null
+++ b/xen/common/libfdt/libfdt_internal.h
@@ -0,0 +1,95 @@
+#ifndef _LIBFDT_INTERNAL_H
+#define _LIBFDT_INTERNAL_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include <fdt.h>
+
+#define FDT_ALIGN(x, a)		(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)		(FDT_ALIGN((x), FDT_TAGSIZE))
+
+#define FDT_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = fdt_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+int _fdt_check_node_offset(const void *fdt, int offset);
+int _fdt_check_prop_offset(const void *fdt, int offset);
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
+int _fdt_node_end_offset(void *fdt, int nodeoffset);
+
+static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
+{
+	return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
+}
+
+static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
+{
+	return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
+}
+
+static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
+{
+	const struct fdt_reserve_entry *rsv_table =
+		(const struct fdt_reserve_entry *)
+		((const char *)fdt + fdt_off_mem_rsvmap(fdt));
+
+	return rsv_table + n;
+}
+static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
+{
+	return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
+}
+
+#define FDT_SW_MAGIC		(~FDT_MAGIC)
+
+#endif /* _LIBFDT_INTERNAL_H */
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
new file mode 100644
index 0000000..3c3994e
--- /dev/null
+++ b/xen/common/libfdt/version.lds
@@ -0,0 +1,54 @@
+LIBFDT_1.2 {
+	global:
+		fdt_next_node;
+		fdt_check_header;
+		fdt_move;
+		fdt_string;
+		fdt_num_mem_rsv;
+		fdt_get_mem_rsv;
+		fdt_subnode_offset_namelen;
+		fdt_subnode_offset;
+		fdt_path_offset;
+		fdt_get_name;
+		fdt_get_property_namelen;
+		fdt_get_property;
+		fdt_getprop_namelen;
+		fdt_getprop;
+		fdt_get_phandle;
+		fdt_get_alias_namelen;
+		fdt_get_alias;
+		fdt_get_path;
+		fdt_supernode_atdepth_offset;
+		fdt_node_depth;
+		fdt_parent_offset;
+		fdt_node_offset_by_prop_value;
+		fdt_node_offset_by_phandle;
+		fdt_node_check_compatible;
+		fdt_node_offset_by_compatible;
+		fdt_setprop_inplace;
+		fdt_nop_property;
+		fdt_nop_node;
+		fdt_create;
+		fdt_add_reservemap_entry;
+		fdt_finish_reservemap;
+		fdt_begin_node;
+		fdt_property;
+		fdt_end_node;
+		fdt_finish;
+		fdt_open_into;
+		fdt_pack;
+		fdt_add_mem_rsv;
+		fdt_del_mem_rsv;
+		fdt_set_name;
+		fdt_setprop;
+		fdt_delprop;
+		fdt_add_subnode_namelen;
+		fdt_add_subnode;
+		fdt_del_node;
+		fdt_strerror;
+		fdt_offset_ptr;
+		fdt_next_tag;
+
+	local:
+		*;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:04:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvq9e-0006Lr-4Y; Fri, 10 Feb 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 <david.vrabel@citrix.com>) id 1Rvq9S-0006Dw-2U
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:04:44 +0000
Received: from [85.158.139.83:46694] by server-4.bemta-5.messagelabs.com id
	46/FC-28576-0E5153F4; Fri, 10 Feb 2012 13:04:32 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328879054!13905276!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30962 invoked from network); 10 Feb 2012 13:04:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229022"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:03:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:03:54 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AD3qXT007755;
	Fri, 10 Feb 2012 05:03:54 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 10 Feb 2012 13:03:37 +0000
Message-ID: <1328879024-5621-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git

This will be used by Xen to parse the DTBs provided by bootloaders on
ARM platforms.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/libfdt/Makefile.libfdt   |   10 +
 xen/common/libfdt/TODO              |    3 +
 xen/common/libfdt/fdt.c             |  222 +++++++
 xen/common/libfdt/fdt.h             |   60 ++
 xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
 xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
 xen/common/libfdt/fdt_strerror.c    |   96 +++
 xen/common/libfdt/fdt_sw.c          |  256 ++++++++
 xen/common/libfdt/fdt_wip.c         |  118 ++++
 xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
 xen/common/libfdt/libfdt_env.h      |   23 +
 xen/common/libfdt/libfdt_internal.h |   95 +++
 xen/common/libfdt/version.lds       |   54 ++
 13 files changed, 3211 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile.libfdt
 create mode 100644 xen/common/libfdt/TODO
 create mode 100644 xen/common/libfdt/fdt.c
 create mode 100644 xen/common/libfdt/fdt.h
 create mode 100644 xen/common/libfdt/fdt_ro.c
 create mode 100644 xen/common/libfdt/fdt_rw.c
 create mode 100644 xen/common/libfdt/fdt_strerror.c
 create mode 100644 xen/common/libfdt/fdt_sw.c
 create mode 100644 xen/common/libfdt/fdt_wip.c
 create mode 100644 xen/common/libfdt/libfdt.h
 create mode 100644 xen/common/libfdt/libfdt_env.h
 create mode 100644 xen/common/libfdt/libfdt_internal.h
 create mode 100644 xen/common/libfdt/version.lds

diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
new file mode 100644
index 0000000..d55a6f8
--- /dev/null
+++ b/xen/common/libfdt/Makefile.libfdt
@@ -0,0 +1,10 @@
+# Makefile.libfdt
+#
+# This is not a complete Makefile of itself.  Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_VERSION = version.lds
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
new file mode 100644
index 0000000..288437e
--- /dev/null
+++ b/xen/common/libfdt/TODO
@@ -0,0 +1,3 @@
+- Tree traversal functions
+- Graft function
+- Complete libfdt.h documenting comments
diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
new file mode 100644
index 0000000..e56833a
--- /dev/null
+++ b/xen/common/libfdt/fdt.c
@@ -0,0 +1,222 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_check_header(const void *fdt)
+{
+	if (fdt_magic(fdt) == FDT_MAGIC) {
+		/* Complete tree */
+		if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+		if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+	} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+		/* Unfinished sequential-write blob */
+		if (fdt_size_dt_struct(fdt) == 0)
+			return -FDT_ERR_BADSTATE;
+	} else {
+		return -FDT_ERR_BADMAGIC;
+	}
+
+	return 0;
+}
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
+{
+	const char *p;
+
+	if (fdt_version(fdt) >= 0x11)
+		if (((offset + len) < offset)
+		    || ((offset + len) > fdt_size_dt_struct(fdt)))
+			return NULL;
+
+	p = _fdt_offset_ptr(fdt, offset);
+
+	if (p + len < p)
+		return NULL;
+	return p;
+}
+
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+	const uint32_t *tagp, *lenp;
+	uint32_t tag;
+	int offset = startoffset;
+	const char *p;
+
+	*nextoffset = -FDT_ERR_TRUNCATED;
+	tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
+	if (!tagp)
+		return FDT_END; /* premature end */
+	tag = fdt32_to_cpu(*tagp);
+	offset += FDT_TAGSIZE;
+
+	*nextoffset = -FDT_ERR_BADSTRUCTURE;
+	switch (tag) {
+	case FDT_BEGIN_NODE:
+		/* skip name */
+		do {
+			p = fdt_offset_ptr(fdt, offset++, 1);
+		} while (p && (*p != '\0'));
+		if (!p)
+			return FDT_END; /* premature end */
+		break;
+
+	case FDT_PROP:
+		lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
+		if (!lenp)
+			return FDT_END; /* premature end */
+		/* skip-name offset, length and value */
+		offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+			+ fdt32_to_cpu(*lenp);
+		break;
+
+	case FDT_END:
+	case FDT_END_NODE:
+	case FDT_NOP:
+		break;
+
+	default:
+		return FDT_END;
+	}
+
+	if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
+		return FDT_END; /* premature end */
+
+	*nextoffset = FDT_TAGALIGN(offset);
+	return tag;
+}
+
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int _fdt_check_prop_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int fdt_next_node(const void *fdt, int offset, int *depth)
+{
+	int nextoffset = 0;
+	uint32_t tag;
+
+	if (offset >= 0)
+		if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+			return nextoffset;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_PROP:
+		case FDT_NOP:
+			break;
+
+		case FDT_BEGIN_NODE:
+			if (depth)
+				(*depth)++;
+			break;
+
+		case FDT_END_NODE:
+			if (depth && ((--(*depth)) < 0))
+				return nextoffset;
+			break;
+
+		case FDT_END:
+			if ((nextoffset >= 0)
+			    || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
+				return -FDT_ERR_NOTFOUND;
+			else
+				return nextoffset;
+		}
+	} while (tag != FDT_BEGIN_NODE);
+
+	return offset;
+}
+
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+{
+	int len = strlen(s) + 1;
+	const char *last = strtab + tabsize - len;
+	const char *p;
+
+	for (p = strtab; p <= last; p++)
+		if (memcmp(p, s, len) == 0)
+			return p;
+	return NULL;
+}
+
+int fdt_move(const void *fdt, void *buf, int bufsize)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_totalsize(fdt) > bufsize)
+		return -FDT_ERR_NOSPACE;
+
+	memmove(buf, fdt, fdt_totalsize(fdt));
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
new file mode 100644
index 0000000..48ccfd9
--- /dev/null
+++ b/xen/common/libfdt/fdt.h
@@ -0,0 +1,60 @@
+#ifndef _FDT_H
+#define _FDT_H
+
+#ifndef __ASSEMBLY__
+
+struct fdt_header {
+	uint32_t magic;			 /* magic word FDT_MAGIC */
+	uint32_t totalsize;		 /* total size of DT block */
+	uint32_t off_dt_struct;		 /* offset to structure */
+	uint32_t off_dt_strings;	 /* offset to strings */
+	uint32_t off_mem_rsvmap;	 /* offset to memory reserve map */
+	uint32_t version;		 /* format version */
+	uint32_t last_comp_version;	 /* last compatible version */
+
+	/* version 2 fields below */
+	uint32_t boot_cpuid_phys;	 /* Which physical CPU id we're
+					    booting on */
+	/* version 3 fields below */
+	uint32_t size_dt_strings;	 /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;	 /* size of the structure block */
+};
+
+struct fdt_reserve_entry {
+	uint64_t address;
+	uint64_t size;
+};
+
+struct fdt_node_header {
+	uint32_t tag;
+	char name[0];
+};
+
+struct fdt_property {
+	uint32_t tag;
+	uint32_t len;
+	uint32_t nameoff;
+	char data[0];
+};
+
+#endif /* !__ASSEMBLY */
+
+#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_TAGSIZE	sizeof(uint32_t)
+
+#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
+#define FDT_END_NODE	0x2		/* End node */
+#define FDT_PROP	0x3		/* Property: name off,
+					   size, content */
+#define FDT_NOP		0x4		/* nop */
+#define FDT_END		0x9
+
+#define FDT_V1_SIZE	(7*sizeof(uint32_t))
+#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(uint32_t))
+#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V16_SIZE	FDT_V3_SIZE
+#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(uint32_t))
+
+#endif /* _FDT_H */
diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
new file mode 100644
index 0000000..02b6d68
--- /dev/null
+++ b/xen/common/libfdt/fdt_ro.c
@@ -0,0 +1,574 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_nodename_eq(const void *fdt, int offset,
+			    const char *s, int len)
+{
+	const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+
+	if (! p)
+		/* short match */
+		return 0;
+
+	if (memcmp(p, s, len) != 0)
+		return 0;
+
+	if (p[len] == '\0')
+		return 1;
+	else if (!memchr(s, '@', len) && (p[len] == '@'))
+		return 1;
+	else
+		return 0;
+}
+
+const char *fdt_string(const void *fdt, int stroffset)
+{
+	return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+}
+
+static int _fdt_string_eq(const void *fdt, int stroffset,
+			  const char *s, int len)
+{
+	const char *p = fdt_string(fdt, stroffset);
+
+	return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+}
+
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
+{
+	FDT_CHECK_HEADER(fdt);
+	*address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
+	*size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+	return 0;
+}
+
+int fdt_num_mem_rsv(const void *fdt)
+{
+	int i = 0;
+
+	while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+		i++;
+	return i;
+}
+
+static int _nextprop(const void *fdt, int offset)
+{
+	uint32_t tag;
+	int nextoffset;
+
+	do {
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_END:
+			if (nextoffset >= 0)
+				return -FDT_ERR_BADSTRUCTURE;
+			else
+				return nextoffset;
+
+		case FDT_PROP:
+			return offset;
+		}
+		offset = nextoffset;
+	} while (tag == FDT_NOP);
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
+			       const char *name, int namelen)
+{
+	int depth;
+
+	FDT_CHECK_HEADER(fdt);
+
+	for (depth = 0;
+	     (offset >= 0) && (depth >= 0);
+	     offset = fdt_next_node(fdt, offset, &depth))
+		if ((depth == 1)
+		    && _fdt_nodename_eq(fdt, offset, name, namelen))
+			return offset;
+
+	if (depth < 0)
+		return -FDT_ERR_NOTFOUND;
+	return offset; /* error */
+}
+
+int fdt_subnode_offset(const void *fdt, int parentoffset,
+		       const char *name)
+{
+	return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_path_offset(const void *fdt, const char *path)
+{
+	const char *end = path + strlen(path);
+	const char *p = path;
+	int offset = 0;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* see if we have an alias */
+	if (*path != '/') {
+		const char *q = strchr(path, '/');
+
+		if (!q)
+			q = end;
+
+		p = fdt_get_alias_namelen(fdt, p, q - p);
+		if (!p)
+			return -FDT_ERR_BADPATH;
+		offset = fdt_path_offset(fdt, p);
+
+		p = q;
+	}
+
+	while (*p) {
+		const char *q;
+
+		while (*p == '/')
+			p++;
+		if (! *p)
+			return offset;
+		q = strchr(p, '/');
+		if (! q)
+			q = end;
+
+		offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
+		if (offset < 0)
+			return offset;
+
+		p = q;
+	}
+
+	return offset;
+}
+
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+	const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
+	int err;
+
+	if (((err = fdt_check_header(fdt)) != 0)
+	    || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+			goto fail;
+
+	if (len)
+		*len = strlen(nh->name);
+
+	return nh->name;
+
+ fail:
+	if (len)
+		*len = err;
+	return NULL;
+}
+
+int fdt_first_property_offset(const void *fdt, int nodeoffset)
+{
+	int offset;
+
+	if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+int fdt_next_property_offset(const void *fdt, int offset)
+{
+	if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp)
+{
+	int err;
+	const struct fdt_property *prop;
+
+	if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
+		if (lenp)
+			*lenp = err;
+		return NULL;
+	}
+
+	prop = _fdt_offset_ptr(fdt, offset);
+
+	if (lenp)
+		*lenp = fdt32_to_cpu(prop->len);
+
+	return prop;
+}
+
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int offset,
+						    const char *name,
+						    int namelen, int *lenp)
+{
+	for (offset = fdt_first_property_offset(fdt, offset);
+	     (offset >= 0);
+	     (offset = fdt_next_property_offset(fdt, offset))) {
+		const struct fdt_property *prop;
+
+		if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
+			offset = -FDT_ERR_INTERNAL;
+			break;
+		}
+		if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
+				   name, namelen))
+			return prop;
+	}
+
+	if (lenp)
+		*lenp = offset;
+	return NULL;
+}
+
+const struct fdt_property *fdt_get_property(const void *fdt,
+					    int nodeoffset,
+					    const char *name, int *lenp)
+{
+	return fdt_get_property_namelen(fdt, nodeoffset, name,
+					strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
+	if (! prop)
+		return NULL;
+
+	return prop->data;
+}
+
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_by_offset(fdt, offset, lenp);
+	if (!prop)
+		return NULL;
+	if (namep)
+		*namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+	return prop->data;
+}
+
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp)
+{
+	return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
+{
+	const uint32_t *php;
+	int len;
+
+	/* FIXME: This is a bit sub-optimal, since we potentially scan
+	 * over all the properties twice. */
+	php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
+	if (!php || (len != sizeof(*php))) {
+		php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
+		if (!php || (len != sizeof(*php)))
+			return 0;
+	}
+
+	return fdt32_to_cpu(*php);
+}
+
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen)
+{
+	int aliasoffset;
+
+	aliasoffset = fdt_path_offset(fdt, "/aliases");
+	if (aliasoffset < 0)
+		return NULL;
+
+	return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+	return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+	int pdepth = 0, p = 0;
+	int offset, depth, namelen;
+	const char *name;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (buflen < 2)
+		return -FDT_ERR_NOSPACE;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		while (pdepth > depth) {
+			do {
+				p--;
+			} while (buf[p-1] != '/');
+			pdepth--;
+		}
+
+		if (pdepth >= depth) {
+			name = fdt_get_name(fdt, offset, &namelen);
+			if (!name)
+				return namelen;
+			if ((p + namelen + 1) <= buflen) {
+				memcpy(buf + p, name, namelen);
+				p += namelen;
+				buf[p++] = '/';
+				pdepth++;
+			}
+		}
+
+		if (offset == nodeoffset) {
+			if (pdepth < (depth + 1))
+				return -FDT_ERR_NOSPACE;
+
+			if (p > 1) /* special case so that root path is "/", not "" */
+				p--;
+			buf[p] = '\0';
+			return 0;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth)
+{
+	int offset, depth;
+	int supernodeoffset = -FDT_ERR_INTERNAL;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (supernodedepth < 0)
+		return -FDT_ERR_NOTFOUND;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		if (depth == supernodedepth)
+			supernodeoffset = offset;
+
+		if (offset == nodeoffset) {
+			if (nodedepth)
+				*nodedepth = depth;
+
+			if (supernodedepth > depth)
+				return -FDT_ERR_NOTFOUND;
+			else
+				return supernodeoffset;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+	int nodedepth;
+	int err;
+
+	err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+	if (err)
+		return (err < 0) ? err : -FDT_ERR_INTERNAL;
+	return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+	int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+	if (nodedepth < 0)
+		return nodedepth;
+	return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+					    nodedepth - 1, NULL);
+}
+
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen)
+{
+	int offset;
+	const void *val;
+	int len;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_getprop(), then if that didn't
+	 * find what we want, we scan over them again making our way
+	 * to the next node.  Still it's the easiest to implement
+	 * approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		val = fdt_getprop(fdt, offset, propname, &len);
+		if (val && (len == proplen)
+		    && (memcmp(val, propval, len) == 0))
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
+{
+	int offset;
+
+	if ((phandle == 0) || (phandle == -1))
+		return -FDT_ERR_BADPHANDLE;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we
+	 * potentially scan each property of a node in
+	 * fdt_get_phandle(), then if that didn't find what
+	 * we want, we scan over them again making our way to the next
+	 * node.  Still it's the easiest to implement approach;
+	 * performance can come later. */
+	for (offset = fdt_next_node(fdt, -1, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		if (fdt_get_phandle(fdt, offset) == phandle)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+				    const char *str)
+{
+	int len = strlen(str);
+	const char *p;
+
+	while (listlen >= len) {
+		if (memcmp(str, strlist, len+1) == 0)
+			return 1;
+		p = memchr(strlist, '\0', listlen);
+		if (!p)
+			return 0; /* malformed strlist.. */
+		listlen -= (p-strlist) + 1;
+		strlist = p + 1;
+	}
+	return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible)
+{
+	const void *prop;
+	int len;
+
+	prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+	if (!prop)
+		return len;
+	if (_fdt_stringlist_contains(prop, len, compatible))
+		return 0;
+	else
+		return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible)
+{
+	int offset, err;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_node_check_compatible(), then if
+	 * that didn't find what we want, we scan over them again
+	 * making our way to the next node.  Still it's the easiest to
+	 * implement approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		err = fdt_node_check_compatible(fdt, offset, compatible);
+		if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
+			return err;
+		else if (err == 0)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
new file mode 100644
index 0000000..994037b
--- /dev/null
+++ b/xen/common/libfdt/fdt_rw.c
@@ -0,0 +1,465 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_blocks_misordered(const void *fdt,
+			      int mem_rsv_size, int struct_size)
+{
+	return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
+		|| (fdt_off_dt_struct(fdt) <
+		    (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
+		|| (fdt_off_dt_strings(fdt) <
+		    (fdt_off_dt_struct(fdt) + struct_size))
+		|| (fdt_totalsize(fdt) <
+		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
+}
+
+static int _fdt_rw_check_header(void *fdt)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_version(fdt) < 17)
+		return -FDT_ERR_BADVERSION;
+	if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
+				   fdt_size_dt_struct(fdt)))
+		return -FDT_ERR_BADLAYOUT;
+	if (fdt_version(fdt) > 17)
+		fdt_set_version(fdt, 17);
+
+	return 0;
+}
+
+#define FDT_RW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_rw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static inline int _fdt_data_size(void *fdt)
+{
+	return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+}
+
+static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
+{
+	char *p = splicepoint;
+	char *end = (char *)fdt + _fdt_data_size(fdt);
+
+	if (((p + oldlen) < p) || ((p + oldlen) > end))
+		return -FDT_ERR_BADOFFSET;
+	if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
+		return -FDT_ERR_NOSPACE;
+	memmove(p + newlen, p + oldlen, end - p - oldlen);
+	return 0;
+}
+
+static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
+			       int oldn, int newn)
+{
+	int delta = (newn - oldn) * sizeof(*p);
+	int err;
+	err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
+	if (err)
+		return err;
+	fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_struct(void *fdt, void *p,
+			      int oldlen, int newlen)
+{
+	int delta = newlen - oldlen;
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
+		return err;
+
+	fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_string(void *fdt, int newlen)
+{
+	void *p = (char *)fdt
+		+ fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, 0, newlen)))
+		return err;
+
+	fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
+	const char *p;
+	char *new;
+	int len = strlen(s) + 1;
+	int err;
+
+	p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
+	if (p)
+		/* found it */
+		return (p - strtab);
+
+	new = strtab + fdt_size_dt_strings(fdt);
+	err = _fdt_splice_string(fdt, len);
+	if (err)
+		return err;
+
+	memcpy(new, s, len);
+	return (new - strtab);
+}
+
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
+	err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
+	if (err)
+		return err;
+
+	re->address = cpu_to_fdt64(address);
+	re->size = cpu_to_fdt64(size);
+	return 0;
+}
+
+int fdt_del_mem_rsv(void *fdt, int n)
+{
+	struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	if (n >= fdt_num_mem_rsv(fdt))
+		return -FDT_ERR_NOTFOUND;
+
+	err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
+	if (err)
+		return err;
+	return 0;
+}
+
+static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
+				int len, struct fdt_property **prop)
+{
+	int oldlen;
+	int err;
+
+	*prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
+	if (! (*prop))
+		return oldlen;
+
+	if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
+				      FDT_TAGALIGN(len))))
+		return err;
+
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
+			     int len, struct fdt_property **prop)
+{
+	int proplen;
+	int nextoffset;
+	int namestroff;
+	int err;
+
+	if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return nextoffset;
+
+	namestroff = _fdt_find_add_string(fdt, name);
+	if (namestroff < 0)
+		return namestroff;
+
+	*prop = _fdt_offset_ptr_w(fdt, nextoffset);
+	proplen = sizeof(**prop) + FDT_TAGALIGN(len);
+
+	err = _fdt_splice_struct(fdt, *prop, 0, proplen);
+	if (err)
+		return err;
+
+	(*prop)->tag = cpu_to_fdt32(FDT_PROP);
+	(*prop)->nameoff = cpu_to_fdt32(namestroff);
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+	char *namep;
+	int oldlen, newlen;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
+	if (!namep)
+		return oldlen;
+
+	newlen = strlen(name);
+
+	err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
+				 FDT_TAGALIGN(newlen+1));
+	if (err)
+		return err;
+
+	memcpy(namep, name, newlen+1);
+	return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len)
+{
+	struct fdt_property *prop;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
+	if (err == -FDT_ERR_NOTFOUND)
+		err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
+	if (err)
+		return err;
+
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_delprop(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len, proplen;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	proplen = sizeof(*prop) + FDT_TAGALIGN(len);
+	return _fdt_splice_struct(fdt, prop, proplen, 0);
+}
+
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen)
+{
+	struct fdt_node_header *nh;
+	int offset, nextoffset;
+	int nodelen;
+	int err;
+	uint32_t tag;
+	uint32_t *endtag;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
+	if (offset >= 0)
+		return -FDT_ERR_EXISTS;
+	else if (offset != -FDT_ERR_NOTFOUND)
+		return offset;
+
+	/* Try to place the new node after the parent's properties */
+	fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+	} while ((tag == FDT_PROP) || (tag == FDT_NOP));
+
+	nh = _fdt_offset_ptr_w(fdt, offset);
+	nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
+
+	err = _fdt_splice_struct(fdt, nh, 0, nodelen);
+	if (err)
+		return err;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
+	memcpy(nh->name, name, namelen);
+	endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
+	*endtag = cpu_to_fdt32(FDT_END_NODE);
+
+	return offset;
+}
+
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
+{
+	return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_del_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
+				  endoffset - nodeoffset, 0);
+}
+
+static void _fdt_packblocks(const char *old, char *new,
+			    int mem_rsv_size, int struct_size)
+{
+	int mem_rsv_off, struct_off, strings_off;
+
+	mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
+	struct_off = mem_rsv_off + mem_rsv_size;
+	strings_off = struct_off + struct_size;
+
+	memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
+	fdt_set_off_mem_rsvmap(new, mem_rsv_off);
+
+	memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
+	fdt_set_off_dt_struct(new, struct_off);
+	fdt_set_size_dt_struct(new, struct_size);
+
+	memmove(new + strings_off, old + fdt_off_dt_strings(old),
+		fdt_size_dt_strings(old));
+	fdt_set_off_dt_strings(new, strings_off);
+	fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
+}
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize)
+{
+	int err;
+	int mem_rsv_size, struct_size;
+	int newsize;
+	const char *fdtstart = fdt;
+	const char *fdtend = fdtstart + fdt_totalsize(fdt);
+	char *tmp;
+
+	FDT_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+
+	if (fdt_version(fdt) >= 17) {
+		struct_size = fdt_size_dt_struct(fdt);
+	} else {
+		struct_size = 0;
+		while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
+			;
+		if (struct_size < 0)
+			return struct_size;
+	}
+
+	if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
+		/* no further work necessary */
+		err = fdt_move(fdt, buf, bufsize);
+		if (err)
+			return err;
+		fdt_set_version(buf, 17);
+		fdt_set_size_dt_struct(buf, struct_size);
+		fdt_set_totalsize(buf, bufsize);
+		return 0;
+	}
+
+	/* Need to reorder */
+	newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
+		+ struct_size + fdt_size_dt_strings(fdt);
+
+	if (bufsize < newsize)
+		return -FDT_ERR_NOSPACE;
+
+	/* First attempt to build converted tree at beginning of buffer */
+	tmp = buf;
+	/* But if that overlaps with the old tree... */
+	if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
+		/* Try right after the old tree instead */
+		tmp = (char *)(uintptr_t)fdtend;
+		if ((tmp + newsize) > ((char *)buf + bufsize))
+			return -FDT_ERR_NOSPACE;
+	}
+
+	_fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
+	memmove(buf, tmp, newsize);
+
+	fdt_set_magic(buf, FDT_MAGIC);
+	fdt_set_totalsize(buf, bufsize);
+	fdt_set_version(buf, 17);
+	fdt_set_last_comp_version(buf, 16);
+	fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
+
+	return 0;
+}
+
+int fdt_pack(void *fdt)
+{
+	int mem_rsv_size;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+	_fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
+	fdt_set_totalsize(fdt, _fdt_data_size(fdt));
+
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
new file mode 100644
index 0000000..e6c3cee
--- /dev/null
+++ b/xen/common/libfdt/fdt_strerror.c
@@ -0,0 +1,96 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+struct fdt_errtabent {
+	const char *str;
+};
+
+#define FDT_ERRTABENT(val) \
+	[(val)] = { .str = #val, }
+
+static struct fdt_errtabent fdt_errtable[] = {
+	FDT_ERRTABENT(FDT_ERR_NOTFOUND),
+	FDT_ERRTABENT(FDT_ERR_EXISTS),
+	FDT_ERRTABENT(FDT_ERR_NOSPACE),
+
+	FDT_ERRTABENT(FDT_ERR_BADOFFSET),
+	FDT_ERRTABENT(FDT_ERR_BADPATH),
+	FDT_ERRTABENT(FDT_ERR_BADSTATE),
+
+	FDT_ERRTABENT(FDT_ERR_TRUNCATED),
+	FDT_ERRTABENT(FDT_ERR_BADMAGIC),
+	FDT_ERRTABENT(FDT_ERR_BADVERSION),
+	FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
+	FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+};
+#define FDT_ERRTABSIZE	(sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
+
+const char *fdt_strerror(int errval)
+{
+	if (errval > 0)
+		return "<valid offset/length>";
+	else if (errval == 0)
+		return "<no error>";
+	else if (errval > -FDT_ERRTABSIZE) {
+		const char *s = fdt_errtable[-errval].str;
+
+		if (s)
+			return s;
+	}
+
+	return "<unknown error>";
+}
diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
new file mode 100644
index 0000000..55ebebf
--- /dev/null
+++ b/xen/common/libfdt/fdt_sw.c
@@ -0,0 +1,256 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_sw_check_header(void *fdt)
+{
+	if (fdt_magic(fdt) != FDT_SW_MAGIC)
+		return -FDT_ERR_BADMAGIC;
+	/* FIXME: should check more details about the header state */
+	return 0;
+}
+
+#define FDT_SW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_sw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static void *_fdt_grab_space(void *fdt, size_t len)
+{
+	int offset = fdt_size_dt_struct(fdt);
+	int spaceleft;
+
+	spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
+		- fdt_size_dt_strings(fdt);
+
+	if ((offset + len < offset) || (offset + len > spaceleft))
+		return NULL;
+
+	fdt_set_size_dt_struct(fdt, offset + len);
+	return _fdt_offset_ptr_w(fdt, offset);
+}
+
+int fdt_create(void *buf, int bufsize)
+{
+	void *fdt = buf;
+
+	if (bufsize < sizeof(struct fdt_header))
+		return -FDT_ERR_NOSPACE;
+
+	memset(buf, 0, bufsize);
+
+	fdt_set_magic(fdt, FDT_SW_MAGIC);
+	fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+	fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+	fdt_set_totalsize(fdt,  bufsize);
+
+	fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
+					      sizeof(struct fdt_reserve_entry)));
+	fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
+	fdt_set_off_dt_strings(fdt, bufsize);
+
+	return 0;
+}
+
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int offset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	if (fdt_size_dt_struct(fdt))
+		return -FDT_ERR_BADSTATE;
+
+	offset = fdt_off_dt_struct(fdt);
+	if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
+		return -FDT_ERR_NOSPACE;
+
+	re = (struct fdt_reserve_entry *)((char *)fdt + offset);
+	re->address = cpu_to_fdt64(addr);
+	re->size = cpu_to_fdt64(size);
+
+	fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
+
+	return 0;
+}
+
+int fdt_finish_reservemap(void *fdt)
+{
+	return fdt_add_reservemap_entry(fdt, 0, 0);
+}
+
+int fdt_begin_node(void *fdt, const char *name)
+{
+	struct fdt_node_header *nh;
+	int namelen = strlen(name) + 1;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
+	if (! nh)
+		return -FDT_ERR_NOSPACE;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memcpy(nh->name, name, namelen);
+	return 0;
+}
+
+int fdt_end_node(void *fdt)
+{
+	uint32_t *en;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	en = _fdt_grab_space(fdt, FDT_TAGSIZE);
+	if (! en)
+		return -FDT_ERR_NOSPACE;
+
+	*en = cpu_to_fdt32(FDT_END_NODE);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_totalsize(fdt);
+	const char *p;
+	int strtabsize = fdt_size_dt_strings(fdt);
+	int len = strlen(s) + 1;
+	int struct_top, offset;
+
+	p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
+	if (p)
+		return p - strtab;
+
+	/* Add it */
+	offset = -strtabsize - len;
+	struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	if (fdt_totalsize(fdt) + offset < struct_top)
+		return 0; /* no more room :( */
+
+	memcpy(strtab + offset, s, len);
+	fdt_set_size_dt_strings(fdt, strtabsize + len);
+	return offset;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+	struct fdt_property *prop;
+	int nameoff;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nameoff = _fdt_find_add_string(fdt, name);
+	if (nameoff == 0)
+		return -FDT_ERR_NOSPACE;
+
+	prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
+	if (! prop)
+		return -FDT_ERR_NOSPACE;
+
+	prop->tag = cpu_to_fdt32(FDT_PROP);
+	prop->nameoff = cpu_to_fdt32(nameoff);
+	prop->len = cpu_to_fdt32(len);
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_finish(void *fdt)
+{
+	char *p = (char *)fdt;
+	uint32_t *end;
+	int oldstroffset, newstroffset;
+	uint32_t tag;
+	int offset, nextoffset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	/* Add terminator */
+	end = _fdt_grab_space(fdt, sizeof(*end));
+	if (! end)
+		return -FDT_ERR_NOSPACE;
+	*end = cpu_to_fdt32(FDT_END);
+
+	/* Relocate the string table */
+	oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
+	newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
+	fdt_set_off_dt_strings(fdt, newstroffset);
+
+	/* Walk the structure, correcting string offsets */
+	offset = 0;
+	while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
+		if (tag == FDT_PROP) {
+			struct fdt_property *prop =
+				_fdt_offset_ptr_w(fdt, offset);
+			int nameoff;
+
+			nameoff = fdt32_to_cpu(prop->nameoff);
+			nameoff += fdt_size_dt_strings(fdt);
+			prop->nameoff = cpu_to_fdt32(nameoff);
+		}
+		offset = nextoffset;
+	}
+	if (nextoffset < 0)
+		return nextoffset;
+
+	/* Finally, adjust the header */
+	fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
+	fdt_set_magic(fdt, FDT_MAGIC);
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
new file mode 100644
index 0000000..6025fa1
--- /dev/null
+++ b/xen/common/libfdt/fdt_wip.c
@@ -0,0 +1,118 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len)
+{
+	void *propval;
+	int proplen;
+
+	propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
+	if (! propval)
+		return proplen;
+
+	if (proplen != len)
+		return -FDT_ERR_NOSPACE;
+
+	memcpy(propval, val, len);
+	return 0;
+}
+
+static void _fdt_nop_region(void *start, int len)
+{
+	uint32_t *p;
+
+	for (p = start; (char *)p < ((char *)start + len); p++)
+		*p = cpu_to_fdt32(FDT_NOP);
+}
+
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len;
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	_fdt_nop_region(prop, len + sizeof(*prop));
+
+	return 0;
+}
+
+int _fdt_node_end_offset(void *fdt, int offset)
+{
+	int depth = 0;
+
+	while ((offset >= 0) && (depth >= 0))
+		offset = fdt_next_node(fdt, offset, &depth);
+
+	return offset;
+}
+
+int fdt_nop_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	_fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
+			endoffset - nodeoffset);
+	return 0;
+}
diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
new file mode 100644
index 0000000..55f3eb3
--- /dev/null
+++ b/xen/common/libfdt/libfdt.h
@@ -0,0 +1,1235 @@
+#ifndef _LIBFDT_H
+#define _LIBFDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <libfdt_env.h>
+#include <fdt.h>
+
+#define FDT_FIRST_SUPPORTED_VERSION	0x10
+#define FDT_LAST_SUPPORTED_VERSION	0x11
+
+/* Error codes: informative error codes */
+#define FDT_ERR_NOTFOUND	1
+	/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
+#define FDT_ERR_EXISTS		2
+	/* FDT_ERR_EXISTS: Attemped to create a node or property which
+	 * already exists */
+#define FDT_ERR_NOSPACE		3
+	/* FDT_ERR_NOSPACE: Operation needed to expand the device
+	 * tree, but its buffer did not have sufficient space to
+	 * contain the expanded tree. Use fdt_open_into() to move the
+	 * device tree to a buffer with more space. */
+
+/* Error codes: codes for bad parameters */
+#define FDT_ERR_BADOFFSET	4
+	/* FDT_ERR_BADOFFSET: Function was passed a structure block
+	 * offset which is out-of-bounds, or which points to an
+	 * unsuitable part of the structure for the operation. */
+#define FDT_ERR_BADPATH		5
+	/* FDT_ERR_BADPATH: Function was passed a badly formatted path
+	 * (e.g. missing a leading / for a function which requires an
+	 * absolute path) */
+#define FDT_ERR_BADPHANDLE	6
+	/* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
+	 * value.  phandle values of 0 and -1 are not permitted. */
+#define FDT_ERR_BADSTATE	7
+	/* FDT_ERR_BADSTATE: Function was passed an incomplete device
+	 * tree created by the sequential-write functions, which is
+	 * not sufficiently complete for the requested operation. */
+
+/* Error codes: codes for bad device tree blobs */
+#define FDT_ERR_TRUNCATED	8
+	/* FDT_ERR_TRUNCATED: Structure block of the given device tree
+	 * ends without an FDT_END tag. */
+#define FDT_ERR_BADMAGIC	9
+	/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+	 * device tree at all - it is missing the flattened device
+	 * tree magic number. */
+#define FDT_ERR_BADVERSION	10
+	/* FDT_ERR_BADVERSION: Given device tree has a version which
+	 * can't be handled by the requested operation.  For
+	 * read-write functions, this may mean that fdt_open_into() is
+	 * required to convert the tree to the expected version. */
+#define FDT_ERR_BADSTRUCTURE	11
+	/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+	 * structure block or other serious error (e.g. misnested
+	 * nodes, or subnodes preceding properties). */
+#define FDT_ERR_BADLAYOUT	12
+	/* FDT_ERR_BADLAYOUT: For read-write functions, the given
+	 * device tree has it's sub-blocks in an order that the
+	 * function can't handle (memory reserve map, then structure,
+	 * then strings).  Use fdt_open_into() to reorganize the tree
+	 * into a form suitable for the read-write operations. */
+
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL	13
+	/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+	 * Should never be returned, if it is, it indicates a bug in
+	 * libfdt itself. */
+
+#define FDT_ERR_MAX		13
+
+/**********************************************************************/
+/* Low-level functions (you probably don't need these)                */
+/**********************************************************************/
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
+{
+	return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
+}
+
+uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+
+/**********************************************************************/
+/* Traversal functions                                                */
+/**********************************************************************/
+
+int fdt_next_node(const void *fdt, int offset, int *depth);
+
+/**********************************************************************/
+/* General functions                                                  */
+/**********************************************************************/
+
+#define fdt_get_header(fdt, field) \
+	(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
+#define fdt_magic(fdt) 			(fdt_get_header(fdt, magic))
+#define fdt_totalsize(fdt)		(fdt_get_header(fdt, totalsize))
+#define fdt_off_dt_struct(fdt)		(fdt_get_header(fdt, off_dt_struct))
+#define fdt_off_dt_strings(fdt)		(fdt_get_header(fdt, off_dt_strings))
+#define fdt_off_mem_rsvmap(fdt)		(fdt_get_header(fdt, off_mem_rsvmap))
+#define fdt_version(fdt)		(fdt_get_header(fdt, version))
+#define fdt_last_comp_version(fdt) 	(fdt_get_header(fdt, last_comp_version))
+#define fdt_boot_cpuid_phys(fdt) 	(fdt_get_header(fdt, boot_cpuid_phys))
+#define fdt_size_dt_strings(fdt) 	(fdt_get_header(fdt, size_dt_strings))
+#define fdt_size_dt_struct(fdt)		(fdt_get_header(fdt, size_dt_struct))
+
+#define __fdt_set_hdr(name) \
+	static inline void fdt_set_##name(void *fdt, uint32_t val) \
+	{ \
+		struct fdt_header *fdth = (struct fdt_header*)fdt; \
+		fdth->name = cpu_to_fdt32(val); \
+	}
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
+
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ *     0, if the buffer appears to contain a valid device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings, as above
+ */
+int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize.  The buffer may overlap
+ * with the existing device tree blob at fdt.  Therefore,
+ *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_move(const void *fdt, void *buf, int bufsize);
+
+/**********************************************************************/
+/* Read-only functions                                                */
+/**********************************************************************/
+
+/**
+ * fdt_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ *     a pointer to the string, on success
+ *     NULL, if stroffset is out of bounds
+ */
+const char *fdt_string(const void *fdt, int stroffset);
+
+/**
+ * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map.  This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ *     the number of entries
+ */
+int fdt_num_mem_rsv(const void *fdt);
+
+/**
+ * fdt_get_mem_rsv - retrieve one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
+/**
+ * fdt_subnode_offset_namelen - find a subnode based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_subnode_offset(), but only examine the first
+ * namelen characters of name for matching the subnode name.  This is
+ * useful for finding subnodes based on a portion of a larger string,
+ * such as a full path.
+ */
+int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+			       const char *name, int namelen);
+/**
+ * fdt_subnode_offset - find a subnode of a given node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_subnode_offset() finds a subnode of the node at structure block
+ * offset parentoffset with the given name.  name may include a unit
+ * address, in which case fdt_subnode_offset() will find the subnode
+ * with that unit address, or the unit address may be omitted, in
+ * which case fdt_subnode_offset() will find an arbitrary subnode
+ * whose name excluding unit address matches the given name.
+ *
+ * returns:
+ *	structure block offset of the requested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_path_offset - find a tree node by its full path
+ * @fdt: pointer to the device tree blob
+ * @path: full path of the node to locate
+ *
+ * fdt_path_offset() finds a node of a given path in the device tree.
+ * Each path component may omit the unit address portion, but the
+ * results of this are undefined if any such path component is
+ * ambiguous (that is if there are multiple nodes at the relevant
+ * level matching the given component, differentiated only by unit
+ * address).
+ *
+ * returns:
+ *	structure block offset of the node with the requested path (>=0), on success
+ *	-FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
+ *	-FDT_ERR_NOTFOUND, if the requested node does not exist
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_path_offset(const void *fdt, const char *path);
+
+/**
+ * fdt_get_name - retrieve the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the starting node
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_name() retrieves the name (including unit address) of the
+ * device tree node at structure block offset nodeoffset.  If lenp is
+ * non-NULL, the length of this name is also returned, in the integer
+ * pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the node's name, on success
+ *		If lenp is non-NULL, *lenp contains the length of that name (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE, standard meanings
+ */
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+
+/**
+ * fdt_first_property_offset - find the offset of a node's first property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ *
+ * fdt_first_property_offset() finds the first property of the node at
+ * the given structure block offset.
+ *
+ * returns:
+ *	structure block offset of the property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested node has no properties
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_first_property_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_next_property_offset - step through a node's properties
+ * @fdt: pointer to the device tree blob
+ * @offset: structure block offset of a property
+ *
+ * fdt_next_property_offset() finds the property immediately after the
+ * one at the given structure block offset.  This will be a property
+ * of the same node as the given property.
+ *
+ * returns:
+ *	structure block offset of the next property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the given property is the last in its node
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_next_property_offset(const void *fdt, int offset);
+
+/**
+ * fdt_get_property_by_offset - retrieve the property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @offset: offset of the property to retrieve
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property_by_offset() retrieves a pointer to the
+ * fdt_property structure within the device tree blob at the given
+ * offset.  If lenp is non-NULL, the length of the property value is
+ * also returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp);
+
+/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int nodeoffset,
+						    const char *name,
+						    int namelen, int *lenp);
+
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset.  If lenp is
+ * non-NULL, the length of the property value is also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
+					    const char *name, int *lenp);
+static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
+						      const char *name,
+						      int *lenp)
+{
+	return (struct fdt_property *)(uintptr_t)
+		fdt_get_property(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_getprop_by_offset - retrieve the value of a property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @ffset: offset of the property to read
+ * @namep: pointer to a string variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop_by_offset() retrieves a pointer to the value of the
+ * property at structure block offset 'offset' (this will be a pointer
+ * to within the device blob itself, not a copy of the value).  If
+ * lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.  If namep is non-NULL,
+ * the property's namne will also be returned in the char * pointed to
+ * by namep (this will be a pointer to within the device tree's string
+ * block, not a new copy of the name).
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *		if namep is non-NULL *namep contiains a pointer to the property
+ *		name.
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp);
+
+/**
+ * fdt_getprop_namelen - get property value based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_getprop(), but only examine the first namelen
+ * characters of name for matching the property name.
+ */
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp);
+
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp);
+static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
+				  const char *name, int *lenp)
+{
+	return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_get_phandle - retrieve the phandle of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the node
+ *
+ * fdt_get_phandle() retrieves the phandle of the device tree node at
+ * structure block offset nodeoffset.
+ *
+ * returns:
+ *	the phandle of the node at nodeoffset, on success (!= 0, != -1)
+ *	0, if the node has no phandle, or another error occurs
+ */
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_get_alias_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias.  That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ *	a pointer to the expansion of the alias named 'name', of it exists
+ *	NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	0, on success
+ *		buf contains the absolute path of the node at
+ *		nodeoffset, as a NUL-terminated string.
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ *		characters and will not fit in the given buffer.
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth).  So
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node.  If the node at
+ * nodeoffset has depth D, then:
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ *	structure block offset of the node at node offset's ancestor
+ *		of depth supernodedepth (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+*	-FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node.  The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	depth of the node at nodeoffset (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ *	structure block offset of the parent of the node at nodeoffset
+ *		(>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_node_offset_by_prop_value - find nodes with a given property value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @propname: property name to check
+ * @propval: property value to search for
+ * @proplen: length of the value in propval
+ *
+ * fdt_node_offset_by_prop_value() returns the offset of the first
+ * node after startoffset, which has a property named propname whose
+ * value is of length proplen and has value equal to propval; or if
+ * startoffset is -1, the very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
+ *					       propval, proplen);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
+ *						       propval, proplen);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen);
+
+/**
+ * fdt_node_offset_by_phandle - find the node with a given phandle
+ * @fdt: pointer to the device tree blob
+ * @phandle: phandle value
+ *
+ * fdt_node_offset_by_phandle() returns the offset of the node
+ * which has the given phandle value.  If there is more than one node
+ * in the tree with the given phandle (an invalid tree), results are
+ * undefined.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0), on success
+ *	-FDT_ERR_NOTFOUND, no node with that phandle exists
+ *	-FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
+
+/**
+ * fdt_node_check_compatible: check a node's compatible property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ *	0, if the node has a 'compatible' property listing the given string
+ *	1, if the node has a 'compatible' property, but it does not list
+ *		the given string
+ *	-FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * 	-FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible);
+
+/**
+ * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @compatible: 'compatible' string to match against
+ *
+ * fdt_node_offset_by_compatible() returns the offset of the first
+ * node after startoffset, which has a 'compatible' property which
+ * lists the given compatible string; or if startoffset is -1, the
+ * very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible);
+
+/**********************************************************************/
+/* Write-in-place functions                                           */
+/**********************************************************************/
+
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+					   const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Sequential write functions                                         */
+/**********************************************************************/
+
+int fdt_create(void *buf, int bufsize);
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
+int fdt_finish_reservemap(void *fdt);
+int fdt_begin_node(void *fdt, const char *name);
+int fdt_property(void *fdt, const char *name, const void *val, int len);
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_property(fdt, name, &val, sizeof(val));
+}
+#define fdt_property_string(fdt, name, str) \
+	fdt_property(fdt, name, str, strlen(str)+1)
+int fdt_end_node(void *fdt);
+int fdt_finish(void *fdt);
+
+/**********************************************************************/
+/* Read-write functions                                               */
+/**********************************************************************/
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize);
+int fdt_pack(void *fdt);
+
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_mem_rsv(void *fdt, int n);
+
+/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string.  NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ *		to contain the new name
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+				   uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_string(fdt, nodeoffset, name, str) \
+	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Debugging / informational functions                                */
+/**********************************************************************/
+
+const char *fdt_strerror(int errval);
+
+#endif /* _LIBFDT_H */
diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
new file mode 100644
index 0000000..449bf60
--- /dev/null
+++ b/xen/common/libfdt/libfdt_env.h
@@ -0,0 +1,23 @@
+#ifndef _LIBFDT_ENV_H
+#define _LIBFDT_ENV_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <string.h>
+
+#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
+static inline uint32_t fdt32_to_cpu(uint32_t x)
+{
+	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
+}
+#define cpu_to_fdt32(x) fdt32_to_cpu(x)
+
+static inline uint64_t fdt64_to_cpu(uint64_t x)
+{
+	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
+		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
+}
+#define cpu_to_fdt64(x) fdt64_to_cpu(x)
+#undef _B
+
+#endif /* _LIBFDT_ENV_H */
diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
new file mode 100644
index 0000000..381133b
--- /dev/null
+++ b/xen/common/libfdt/libfdt_internal.h
@@ -0,0 +1,95 @@
+#ifndef _LIBFDT_INTERNAL_H
+#define _LIBFDT_INTERNAL_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include <fdt.h>
+
+#define FDT_ALIGN(x, a)		(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)		(FDT_ALIGN((x), FDT_TAGSIZE))
+
+#define FDT_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = fdt_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+int _fdt_check_node_offset(const void *fdt, int offset);
+int _fdt_check_prop_offset(const void *fdt, int offset);
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
+int _fdt_node_end_offset(void *fdt, int nodeoffset);
+
+static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
+{
+	return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
+}
+
+static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
+{
+	return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
+}
+
+static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
+{
+	const struct fdt_reserve_entry *rsv_table =
+		(const struct fdt_reserve_entry *)
+		((const char *)fdt + fdt_off_mem_rsvmap(fdt));
+
+	return rsv_table + n;
+}
+static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
+{
+	return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
+}
+
+#define FDT_SW_MAGIC		(~FDT_MAGIC)
+
+#endif /* _LIBFDT_INTERNAL_H */
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
new file mode 100644
index 0000000..3c3994e
--- /dev/null
+++ b/xen/common/libfdt/version.lds
@@ -0,0 +1,54 @@
+LIBFDT_1.2 {
+	global:
+		fdt_next_node;
+		fdt_check_header;
+		fdt_move;
+		fdt_string;
+		fdt_num_mem_rsv;
+		fdt_get_mem_rsv;
+		fdt_subnode_offset_namelen;
+		fdt_subnode_offset;
+		fdt_path_offset;
+		fdt_get_name;
+		fdt_get_property_namelen;
+		fdt_get_property;
+		fdt_getprop_namelen;
+		fdt_getprop;
+		fdt_get_phandle;
+		fdt_get_alias_namelen;
+		fdt_get_alias;
+		fdt_get_path;
+		fdt_supernode_atdepth_offset;
+		fdt_node_depth;
+		fdt_parent_offset;
+		fdt_node_offset_by_prop_value;
+		fdt_node_offset_by_phandle;
+		fdt_node_check_compatible;
+		fdt_node_offset_by_compatible;
+		fdt_setprop_inplace;
+		fdt_nop_property;
+		fdt_nop_node;
+		fdt_create;
+		fdt_add_reservemap_entry;
+		fdt_finish_reservemap;
+		fdt_begin_node;
+		fdt_property;
+		fdt_end_node;
+		fdt_finish;
+		fdt_open_into;
+		fdt_pack;
+		fdt_add_mem_rsv;
+		fdt_del_mem_rsv;
+		fdt_set_name;
+		fdt_setprop;
+		fdt_delprop;
+		fdt_add_subnode_namelen;
+		fdt_add_subnode;
+		fdt_del_node;
+		fdt_strerror;
+		fdt_offset_ptr;
+		fdt_next_tag;
+
+	local:
+		*;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:05:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9w-0006U4-CG; Fri, 10 Feb 2012 13:05:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvq9u-0006Qs-7j
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:05:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328879094!8619657!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6188 invoked from network); 10 Feb 2012 13:04:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229168"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:04:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:04:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1AD4qfO007774;	Fri, 10 Feb 2012 05:04:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: cc609327d4fba381388be7826760017f02d1748f
Message-ID: <cc609327d4fba381388b.1328879091@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 10 Feb 2012 13:04:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl: Add -F to usage for xl shutdown/reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328879048 0
# Node ID cc609327d4fba381388be7826760017f02d1748f
# Parent  13621819e3c7b3a80cc3cf5a092585fae21751d7
xl: Add -F to usage for xl shutdown/reboot

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 13621819e3c7 -r cc609327d4fb tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Fri Feb 10 12:08:18 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Fri Feb 10 13:04:08 2012 +0000
@@ -48,12 +48,19 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0,
       "Issue a shutdown signal to a domain",
-      "<Domain>",
+      "[options] <Domain>",
+      "-h                      Print this help.\n"
+      "-F                      Fallback to ACPI power event for HVM guests with\n"
+      "                        no PV drivers.\n"
+      "-w                      Wait for guest to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0,
       "Issue a reboot signal to a domain",
-      "<Domain>",
+      "[options] <Domain>",
+      "-h                      Print this help.\n"
+      "-F                      Fallback to ACPI reset event for HVM guests with\n"
+      "                        no PV drivers.\n"
     },
     { "pci-attach",
       &main_pciattach, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:05:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvq9w-0006U4-CG; Fri, 10 Feb 2012 13:05:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvq9u-0006Qs-7j
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:05:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328879094!8619657!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzEyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6188 invoked from network); 10 Feb 2012 13:04:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:04:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181229168"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:04:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 08:04:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1AD4qfO007774;	Fri, 10 Feb 2012 05:04:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: cc609327d4fba381388be7826760017f02d1748f
Message-ID: <cc609327d4fba381388b.1328879091@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 10 Feb 2012 13:04:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] xl: Add -F to usage for xl shutdown/reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328879048 0
# Node ID cc609327d4fba381388be7826760017f02d1748f
# Parent  13621819e3c7b3a80cc3cf5a092585fae21751d7
xl: Add -F to usage for xl shutdown/reboot

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 13621819e3c7 -r cc609327d4fb tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Fri Feb 10 12:08:18 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Fri Feb 10 13:04:08 2012 +0000
@@ -48,12 +48,19 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0,
       "Issue a shutdown signal to a domain",
-      "<Domain>",
+      "[options] <Domain>",
+      "-h                      Print this help.\n"
+      "-F                      Fallback to ACPI power event for HVM guests with\n"
+      "                        no PV drivers.\n"
+      "-w                      Wait for guest to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0,
       "Issue a reboot signal to a domain",
-      "<Domain>",
+      "[options] <Domain>",
+      "-h                      Print this help.\n"
+      "-F                      Fallback to ACPI reset event for HVM guests with\n"
+      "                        no PV drivers.\n"
     },
     { "pci-attach",
       &main_pciattach, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:07:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvqBi-00077U-2y; Fri, 10 Feb 2012 13:06:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RvqBg-000768-IM
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:06:53 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328879205!12837118!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31758 invoked from network); 10 Feb 2012 13:06:46 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-174.messagelabs.com with SMTP;
	10 Feb 2012 13:06:46 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75440920; Fri, 10 Feb 2012 14:06:44 +0100
Message-ID: <1328879201.4351.65.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: =?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <yzt356@gmail.com>
Date: Fri, 10 Feb 2012 14:06:41 +0100
In-Reply-To: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
References: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: "lars.kurth" <lars.kurth@citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Projects for Google Summer of Code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1034445397539615188=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1034445397539615188==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-h4iOC7dNOi9tWwpj5GnO"


--=-h4iOC7dNOi9tWwpj5GnO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-02-07 at 10:06 +0800, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:
> Hi all,
> I have noticed of some projects in GSoC 2011 supported by Xen.org, and
> I would like to know if there will be any projects for GSoC 2012?
>
There will most likely be some... Or at least Xen.org will probably
submit some project, then it all depends on them being approved. :-)

> I want to apply for a project supported by Xen.org because I use Xen
> and do research on it for some time and I have great interest in it.
>
This is always something nice to hear. :-)

> I want to get some more information about it, thank you.
>=20
Ok then, I think you can keep monitoring GSoC Website and also this
mailing list, as I think updates will be announced here when they become
available.

Regards,
Dario=20
--=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)



--=-h4iOC7dNOi9tWwpj5GnO
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)

iEYEABECAAYFAk81FmIACgkQk4XaBE3IOsQlBACgjUl8KrcAKb47Qjm4jZEsImMN
vBMAn0sWYDI2oZAtIWB5uzwb5v7unjon
=y5Kj
-----END PGP SIGNATURE-----

--=-h4iOC7dNOi9tWwpj5GnO--



--===============1034445397539615188==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1034445397539615188==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:07:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvqBi-00077U-2y; Fri, 10 Feb 2012 13:06:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RvqBg-000768-IM
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:06:53 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328879205!12837118!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31758 invoked from network); 10 Feb 2012 13:06:46 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-174.messagelabs.com with SMTP;
	10 Feb 2012 13:06:46 -0000
Received: from [213.136.142.51] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75440920; Fri, 10 Feb 2012 14:06:44 +0100
Message-ID: <1328879201.4351.65.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: =?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <yzt356@gmail.com>
Date: Fri, 10 Feb 2012 14:06:41 +0100
In-Reply-To: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
References: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: "lars.kurth" <lars.kurth@citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Projects for Google Summer of Code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1034445397539615188=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1034445397539615188==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-h4iOC7dNOi9tWwpj5GnO"


--=-h4iOC7dNOi9tWwpj5GnO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-02-07 at 10:06 +0800, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:
> Hi all,
> I have noticed of some projects in GSoC 2011 supported by Xen.org, and
> I would like to know if there will be any projects for GSoC 2012?
>
There will most likely be some... Or at least Xen.org will probably
submit some project, then it all depends on them being approved. :-)

> I want to apply for a project supported by Xen.org because I use Xen
> and do research on it for some time and I have great interest in it.
>
This is always something nice to hear. :-)

> I want to get some more information about it, thank you.
>=20
Ok then, I think you can keep monitoring GSoC Website and also this
mailing list, as I think updates will be announced here when they become
available.

Regards,
Dario=20
--=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)



--=-h4iOC7dNOi9tWwpj5GnO
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)

iEYEABECAAYFAk81FmIACgkQk4XaBE3IOsQlBACgjUl8KrcAKb47Qjm4jZEsImMN
vBMAn0sWYDI2oZAtIWB5uzwb5v7unjon
=y5Kj
-----END PGP SIGNATURE-----

--=-h4iOC7dNOi9tWwpj5GnO--



--===============1034445397539615188==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1034445397539615188==--



From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1RvqU1-00086o-BO; Fri, 10 Feb 2012 13:25: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 1RvqTz-00086b-GG
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:25:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328880293!53731637!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10340 invoked from network); 10 Feb 2012 13:24: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; 10 Feb 2012 13:24:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvqTt-00081R-Gn; Fri, 10 Feb 2012 13:25:41 +0000
Date: Fri, 10 Feb 2012 13:25:41 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120210132541.GB27895@ocelot.phlegethon.org>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-8-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328879024-5621-8-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 13:03 +0000 on 10 Feb (1328879023), David Vrabel wrote:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 51afb31..e212a2e 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -19,6 +19,7 @@
>  
>  #include <xen/config.h>
>  #include <xen/compile.h>
> +#include <xen/device_tree.h>
>  #include <xen/domain_page.h>
>  #include <xen/types.h>
>  #include <xen/string.h>
> @@ -68,8 +69,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>                        unsigned long atag_paddr)
>  
>  {
> +    void *fdt;
>      int i;
>  
> +    fdt = (void *)BOOT_MISC_VIRT_START + (atag_paddr & ((1 << SECOND_SHIFT) - 1));

Please linewrap below 80 coluns. 

> +static void __init process_memory_node(const void *fdt, int node,
> +                                       u32 address_cells, u32 size_cells)
> +{
> +    const struct fdt_property *prop;
> +    size_t reg_cells;
> +    int i;
> +    int banks;
> +    const u32 *cell;
> +    paddr_t start, size;
> +
> +    if (address_cells < 1 || size_cells < 1) {
> +        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
> +                     fdt_get_name(fdt, node, NULL));
> +        return;
> +    }
> +
> +    prop = fdt_get_property(fdt, node, "reg", NULL);
> +    if (!prop) {
> +        early_printk("fdt: node `%s': missing `reg' property\n",
> +                     fdt_get_name(fdt, node, NULL));
> +        return;
> +    }
> +
> +    cell = (const u32 *)prop->data;
> +    reg_cells = address_cells + size_cells;
> +    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
> +
> +    for (i = 0; i < banks; i++) {
> +        get_register(&cell, address_cells, size_cells, &start, &size);
> +        early_info.mem.bank[early_info.mem.nr_banks].start = start;
> +        early_info.mem.bank[early_info.mem.nr_banks].size = size;
> +        early_info.mem.nr_banks++;

This needs a check that you don't overrun NR_MEM_BANKS. 

Aside from that, this whole series gets my ack.

Cheers,

Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1RvqU1-00086o-BO; Fri, 10 Feb 2012 13:25: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 1RvqTz-00086b-GG
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:25:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328880293!53731637!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10340 invoked from network); 10 Feb 2012 13:24: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; 10 Feb 2012 13:24:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvqTt-00081R-Gn; Fri, 10 Feb 2012 13:25:41 +0000
Date: Fri, 10 Feb 2012 13:25:41 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120210132541.GB27895@ocelot.phlegethon.org>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-8-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328879024-5621-8-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 13:03 +0000 on 10 Feb (1328879023), David Vrabel wrote:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 51afb31..e212a2e 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -19,6 +19,7 @@
>  
>  #include <xen/config.h>
>  #include <xen/compile.h>
> +#include <xen/device_tree.h>
>  #include <xen/domain_page.h>
>  #include <xen/types.h>
>  #include <xen/string.h>
> @@ -68,8 +69,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>                        unsigned long atag_paddr)
>  
>  {
> +    void *fdt;
>      int i;
>  
> +    fdt = (void *)BOOT_MISC_VIRT_START + (atag_paddr & ((1 << SECOND_SHIFT) - 1));

Please linewrap below 80 coluns. 

> +static void __init process_memory_node(const void *fdt, int node,
> +                                       u32 address_cells, u32 size_cells)
> +{
> +    const struct fdt_property *prop;
> +    size_t reg_cells;
> +    int i;
> +    int banks;
> +    const u32 *cell;
> +    paddr_t start, size;
> +
> +    if (address_cells < 1 || size_cells < 1) {
> +        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
> +                     fdt_get_name(fdt, node, NULL));
> +        return;
> +    }
> +
> +    prop = fdt_get_property(fdt, node, "reg", NULL);
> +    if (!prop) {
> +        early_printk("fdt: node `%s': missing `reg' property\n",
> +                     fdt_get_name(fdt, node, NULL));
> +        return;
> +    }
> +
> +    cell = (const u32 *)prop->data;
> +    reg_cells = address_cells + size_cells;
> +    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
> +
> +    for (i = 0; i < banks; i++) {
> +        get_register(&cell, address_cells, size_cells, &start, &size);
> +        early_info.mem.bank[early_info.mem.nr_banks].start = start;
> +        early_info.mem.bank[early_info.mem.nr_banks].size = size;
> +        early_info.mem.nr_banks++;

This needs a check that you don't overrun NR_MEM_BANKS. 

Aside from that, this whole series gets my ack.

Cheers,

Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:32:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvqab-00005u-7C; Fri, 10 Feb 2012 13:32: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 1RvqaZ-00005o-SC
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:32:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328880705!59613176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1809 invoked from network); 10 Feb 2012 13:31:45 -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;
	10 Feb 2012 13:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:32:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 13:32:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvqaS-0004IJ-QN;
	Fri, 10 Feb 2012 13:32:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvqaS-0008Ag-P5;
	Fri, 10 Feb 2012 13:32:28 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RvqaS-0008Ag-P5@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 13:32:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-win
test windows-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  aae516b78fce
  Bug not present: 585caf50a926


  changeset:   24757:aae516b78fce
  user:        Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  date:        Thu Feb 09 18:33:32 2012 +0000
      
      xenstored: use grant references instead of map_foreign_range
      
      make xenstored use grantref rather than map_foreign_range (which can
      only be used by privileged domains)
      
      This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
      instead of xc_map_foreign_range where available.
      
      Previous versions of this patch have been sent to xen-devel. See
      http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
      http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
      
      Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
      Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
      Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>
      Cc: Ian Jackson <ian.jackson@eu.citrix.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-win.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 11911 fail [host=earwig] / 11904 ok.
Failure / basis pass flights: 11911 / 11904
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 9fc810bb8145
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#8cc8a3651c9c5bc2d0086d12f4b870fc525b9387-8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#9fc810bb8145-730f6ed72d70
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 62 nodes in revision graph
Searching for test results:
 11908 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11905 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11907 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11904 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 9fc810bb8145
 11906 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 9fc810bb8145
 11914 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc aae516b78fce
 11909 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 86dca025cc2d
 11912 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 674fcff272be
 11910 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc f371834bac09
 11913 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
 11915 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
 11918 []
 11911 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11917 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc aae516b78fce
 11919 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
 11920 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc aae516b78fce
Searching for interesting versions
 Result found: flight 11904 (pass), for basis pass
 Result found: flight 11905 (fail), for basis failure
 Repro found: flight 11906 (pass), for basis pass
 Repro found: flight 11907 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
No revisions left to test, checking graph state.
 Result found: flight 11913 (pass), for last pass
 Result found: flight 11914 (fail), for first failure
 Repro found: flight 11915 (pass), for last pass
 Repro found: flight 11917 (fail), for first failure
 Repro found: flight 11919 (pass), for last pass
 Repro found: flight 11920 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  aae516b78fce
  Bug not present: 585caf50a926

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24757:aae516b78fce
  user:        Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  date:        Thu Feb 09 18:33:32 2012 +0000
      
      xenstored: use grant references instead of map_foreign_range
      
      make xenstored use grantref rather than map_foreign_range (which can
      only be used by privileged domains)
      
      This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
      instead of xc_map_foreign_range where available.
      
      Previous versions of this patch have been sent to xen-devel. See
      http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
      http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
      
      Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
      Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
      Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>
      Cc: Ian Jackson <ian.jackson@eu.citrix.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-win.windows-install.{dot,ps,png,html}.
----------------------------------------
11920: ALL FAIL

flight 11920 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11920/


jobs:
 test-amd64-amd64-win                                         fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:32:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvqab-00005u-7C; Fri, 10 Feb 2012 13:32: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 1RvqaZ-00005o-SC
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:32:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328880705!59613176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1809 invoked from network); 10 Feb 2012 13:31:45 -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;
	10 Feb 2012 13:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:32:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 13:32:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvqaS-0004IJ-QN;
	Fri, 10 Feb 2012 13:32:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvqaS-0008Ag-P5;
	Fri, 10 Feb 2012 13:32:28 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RvqaS-0008Ag-P5@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 13:32:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-win
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-win
test windows-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  aae516b78fce
  Bug not present: 585caf50a926


  changeset:   24757:aae516b78fce
  user:        Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  date:        Thu Feb 09 18:33:32 2012 +0000
      
      xenstored: use grant references instead of map_foreign_range
      
      make xenstored use grantref rather than map_foreign_range (which can
      only be used by privileged domains)
      
      This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
      instead of xc_map_foreign_range where available.
      
      Previous versions of this patch have been sent to xen-devel. See
      http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
      http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
      
      Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
      Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
      Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>
      Cc: Ian Jackson <ian.jackson@eu.citrix.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-win.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 11911 fail [host=earwig] / 11904 ok.
Failure / basis pass flights: 11911 / 11904
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 9fc810bb8145
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#8cc8a3651c9c5bc2d0086d12f4b870fc525b9387-8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#9fc810bb8145-730f6ed72d70
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 62 nodes in revision graph
Searching for test results:
 11908 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11905 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11907 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11904 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 9fc810bb8145
 11906 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 9fc810bb8145
 11914 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc aae516b78fce
 11909 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 86dca025cc2d
 11912 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 674fcff272be
 11910 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc f371834bac09
 11913 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
 11915 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
 11918 []
 11911 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 730f6ed72d70
 11917 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc aae516b78fce
 11919 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
 11920 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc aae516b78fce
Searching for interesting versions
 Result found: flight 11904 (pass), for basis pass
 Result found: flight 11905 (fail), for basis failure
 Repro found: flight 11906 (pass), for basis pass
 Repro found: flight 11907 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387 86a8d63bc11431509506b95c1481e1a023302cbc 585caf50a926
No revisions left to test, checking graph state.
 Result found: flight 11913 (pass), for last pass
 Result found: flight 11914 (fail), for first failure
 Repro found: flight 11915 (pass), for last pass
 Repro found: flight 11917 (fail), for first failure
 Repro found: flight 11919 (pass), for last pass
 Repro found: flight 11920 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  aae516b78fce
  Bug not present: 585caf50a926

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24757:aae516b78fce
  user:        Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  date:        Thu Feb 09 18:33:32 2012 +0000
      
      xenstored: use grant references instead of map_foreign_range
      
      make xenstored use grantref rather than map_foreign_range (which can
      only be used by privileged domains)
      
      This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
      instead of xc_map_foreign_range where available.
      
      Previous versions of this patch have been sent to xen-devel. See
      http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
      http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
      
      Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
      Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
      Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
      Acked-by: Ian Campbell <ian.campbell@citrix.com>
      Cc: Ian Jackson <ian.jackson@eu.citrix.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-win.windows-install.{dot,ps,png,html}.
----------------------------------------
11920: ALL FAIL

flight 11920 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11920/


jobs:
 test-amd64-amd64-win                                         fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:36:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:36:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvqdl-0000Fb-94; Fri, 10 Feb 2012 13:35:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvqdj-0000FE-Oc
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:35:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328880945!12779791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11010 invoked from network); 10 Feb 2012 13:35: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;
	10 Feb 2012 13:35:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622407"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:35:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 13:35:45 +0000
Message-ID: <1328880943.6133.264.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 10 Feb 2012 13:35:43 +0000
In-Reply-To: <1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Link a device tree blob (DTB) into the xen image.  This is loaded
> immediately after Xen and xen_start() is called with the correct
> address in atag_paddr.

Is platform.dtb supposed to be included in this patch/series or is it
intended that I should supply it from somewhere? (in which case, how and
where etc).

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/Makefile  |    7 +++++--
>  xen/arch/arm/dtb.S     |    2 ++
>  xen/arch/arm/head.S    |    4 ++++
>  xen/arch/arm/xen.lds.S |    5 +++++
>  4 files changed, 16 insertions(+), 2 deletions(-)
>  create mode 100644 xen/arch/arm/dtb.S
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 9bc2fc8..ac346a5 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -1,5 +1,6 @@
>  subdir-y += lib
>  
> +obj-y += dtb.o
>  obj-y += dummy.o
>  obj-y += entry.o
>  obj-y += domain.o
> @@ -27,7 +28,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
>  $(TARGET): $(TARGET)-syms
>  	# XXX: VE model loads by VMA so instead of
>  	# making a proper ELF we link with LMA == VMA and adjust crudely
> -	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
> +	$(OBJCOPY) --change-addresses +0x80000000 $< $@
>  	# XXX strip it
>  
>  #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
> @@ -50,7 +51,7 @@ endif
>  $(BASEDIR)/common/symbols-dummy.o:
>  	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
>  
> -$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> +$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o dtb.o
>  	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>  	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
>  	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
> @@ -71,6 +72,8 @@ xen.lds: xen.lds.S
>  	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
>  	mv -f .xen.lds.d.new .xen.lds.d
>  
> +dtb.o: platform.dtb
> +
>  .PHONY: clean
>  clean::
>  	rm -f asm-offsets.s xen.lds
> diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
> new file mode 100644
> index 0000000..0728c04
> --- /dev/null
> +++ b/xen/arch/arm/dtb.S
> @@ -0,0 +1,2 @@
> +        .section .dtb,#alloc
> +        .incbin "platform.dtb"
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 57b990d..22ac512 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -55,6 +55,10 @@ start:
>         adr   r9, start              /* r9  := paddr (start) */
>         sub   r10, r9, r0            /* r10 := phys-offset */
>  
> +        /* XXX: using the DTB in the .dtb section. */
> +        ldr   r8, =_sdtb
> +        add   r8, r10                /* r8 := paddr(DTB) */
> +
>  #ifdef EARLY_UART_ADDRESS
>         /* Say hello */
>         ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 5a62e2c..30fc7b7 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -122,6 +122,11 @@ SECTIONS
>    } :text
>    _end = . ;
>  
> +  /* XXX: don't yet have a bootloader to provide the DTB, link it into
> +     Xen in its own section. */
> +  _sdtb = .;
> +  .dtb : { dtb.o(.dtb) } :text
> +
>    /* Sections to be discarded */
>    /DISCARD/ : {
>         *(.exit.text)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:36:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:36:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvqdl-0000Fb-94; Fri, 10 Feb 2012 13:35:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvqdj-0000FE-Oc
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:35:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328880945!12779791!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11010 invoked from network); 10 Feb 2012 13:35: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;
	10 Feb 2012 13:35:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622407"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:35:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 13:35:45 +0000
Message-ID: <1328880943.6133.264.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 10 Feb 2012 13:35:43 +0000
In-Reply-To: <1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Link a device tree blob (DTB) into the xen image.  This is loaded
> immediately after Xen and xen_start() is called with the correct
> address in atag_paddr.

Is platform.dtb supposed to be included in this patch/series or is it
intended that I should supply it from somewhere? (in which case, how and
where etc).

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/Makefile  |    7 +++++--
>  xen/arch/arm/dtb.S     |    2 ++
>  xen/arch/arm/head.S    |    4 ++++
>  xen/arch/arm/xen.lds.S |    5 +++++
>  4 files changed, 16 insertions(+), 2 deletions(-)
>  create mode 100644 xen/arch/arm/dtb.S
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 9bc2fc8..ac346a5 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -1,5 +1,6 @@
>  subdir-y += lib
>  
> +obj-y += dtb.o
>  obj-y += dummy.o
>  obj-y += entry.o
>  obj-y += domain.o
> @@ -27,7 +28,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
>  $(TARGET): $(TARGET)-syms
>  	# XXX: VE model loads by VMA so instead of
>  	# making a proper ELF we link with LMA == VMA and adjust crudely
> -	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
> +	$(OBJCOPY) --change-addresses +0x80000000 $< $@
>  	# XXX strip it
>  
>  #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
> @@ -50,7 +51,7 @@ endif
>  $(BASEDIR)/common/symbols-dummy.o:
>  	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
>  
> -$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> +$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o dtb.o
>  	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>  	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
>  	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
> @@ -71,6 +72,8 @@ xen.lds: xen.lds.S
>  	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
>  	mv -f .xen.lds.d.new .xen.lds.d
>  
> +dtb.o: platform.dtb
> +
>  .PHONY: clean
>  clean::
>  	rm -f asm-offsets.s xen.lds
> diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
> new file mode 100644
> index 0000000..0728c04
> --- /dev/null
> +++ b/xen/arch/arm/dtb.S
> @@ -0,0 +1,2 @@
> +        .section .dtb,#alloc
> +        .incbin "platform.dtb"
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 57b990d..22ac512 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -55,6 +55,10 @@ start:
>         adr   r9, start              /* r9  := paddr (start) */
>         sub   r10, r9, r0            /* r10 := phys-offset */
>  
> +        /* XXX: using the DTB in the .dtb section. */
> +        ldr   r8, =_sdtb
> +        add   r8, r10                /* r8 := paddr(DTB) */
> +
>  #ifdef EARLY_UART_ADDRESS
>         /* Say hello */
>         ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 5a62e2c..30fc7b7 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -122,6 +122,11 @@ SECTIONS
>    } :text
>    _end = . ;
>  
> +  /* XXX: don't yet have a bootloader to provide the DTB, link it into
> +     Xen in its own section. */
> +  _sdtb = .;
> +  .dtb : { dtb.o(.dtb) } :text
> +
>    /* Sections to be discarded */
>    /DISCARD/ : {
>         *(.exit.text)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:38:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1RvqgM-0000Yw-P0; Fri, 10 Feb 2012 13:38: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 1RvqgK-0000YU-65
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:38:33 +0000
Received: from [85.158.139.83:60301] by server-2.bemta-5.messagelabs.com id
	BD/EA-20725-7DD153F4; Fri, 10 Feb 2012 13:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328881109!14543890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25113 invoked from network); 10 Feb 2012 13:38:29 -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;
	10 Feb 2012 13:38:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:38:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 13:38:28 +0000
Message-ID: <1328881106.6133.266.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, Keir Fraser <keir@xen.org>
Date: Fri, 10 Feb 2012 13:38:26 +0000
In-Reply-To: <1328879024-5621-2-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/8] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git
> 
> This will be used by Xen to parse the DTBs provided by bootloaders on
> ARM platforms.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Seems reasonable to me. I'd like to see an Ack from Keir before I commit
this and the following 2 xen/common/mumble patches (or have Keir take
them directly).

Ian.

> ---
>  xen/common/libfdt/Makefile.libfdt   |   10 +
>  xen/common/libfdt/TODO              |    3 +
>  xen/common/libfdt/fdt.c             |  222 +++++++
>  xen/common/libfdt/fdt.h             |   60 ++
>  xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
>  xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
>  xen/common/libfdt/fdt_strerror.c    |   96 +++
>  xen/common/libfdt/fdt_sw.c          |  256 ++++++++
>  xen/common/libfdt/fdt_wip.c         |  118 ++++
>  xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
>  xen/common/libfdt/libfdt_env.h      |   23 +
>  xen/common/libfdt/libfdt_internal.h |   95 +++
>  xen/common/libfdt/version.lds       |   54 ++
>  13 files changed, 3211 insertions(+), 0 deletions(-)
>  create mode 100644 xen/common/libfdt/Makefile.libfdt
>  create mode 100644 xen/common/libfdt/TODO
>  create mode 100644 xen/common/libfdt/fdt.c
>  create mode 100644 xen/common/libfdt/fdt.h
>  create mode 100644 xen/common/libfdt/fdt_ro.c
>  create mode 100644 xen/common/libfdt/fdt_rw.c
>  create mode 100644 xen/common/libfdt/fdt_strerror.c
>  create mode 100644 xen/common/libfdt/fdt_sw.c
>  create mode 100644 xen/common/libfdt/fdt_wip.c
>  create mode 100644 xen/common/libfdt/libfdt.h
>  create mode 100644 xen/common/libfdt/libfdt_env.h
>  create mode 100644 xen/common/libfdt/libfdt_internal.h
>  create mode 100644 xen/common/libfdt/version.lds
> 
> diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
> new file mode 100644
> index 0000000..d55a6f8
> --- /dev/null
> +++ b/xen/common/libfdt/Makefile.libfdt
> @@ -0,0 +1,10 @@
> +# Makefile.libfdt
> +#
> +# This is not a complete Makefile of itself.  Instead, it is designed to
> +# be easily embeddable into other systems of Makefiles.
> +#
> +LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
> +LIBFDT_INCLUDES = fdt.h libfdt.h
> +LIBFDT_VERSION = version.lds
> +LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
> +LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
> diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
> new file mode 100644
> index 0000000..288437e
> --- /dev/null
> +++ b/xen/common/libfdt/TODO
> @@ -0,0 +1,3 @@
> +- Tree traversal functions
> +- Graft function
> +- Complete libfdt.h documenting comments
> diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
> new file mode 100644
> index 0000000..e56833a
> --- /dev/null
> +++ b/xen/common/libfdt/fdt.c
> @@ -0,0 +1,222 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +int fdt_check_header(const void *fdt)
> +{
> +       if (fdt_magic(fdt) == FDT_MAGIC) {
> +               /* Complete tree */
> +               if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
> +                       return -FDT_ERR_BADVERSION;
> +               if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
> +                       return -FDT_ERR_BADVERSION;
> +       } else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
> +               /* Unfinished sequential-write blob */
> +               if (fdt_size_dt_struct(fdt) == 0)
> +                       return -FDT_ERR_BADSTATE;
> +       } else {
> +               return -FDT_ERR_BADMAGIC;
> +       }
> +
> +       return 0;
> +}
> +
> +const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
> +{
> +       const char *p;
> +
> +       if (fdt_version(fdt) >= 0x11)
> +               if (((offset + len) < offset)
> +                   || ((offset + len) > fdt_size_dt_struct(fdt)))
> +                       return NULL;
> +
> +       p = _fdt_offset_ptr(fdt, offset);
> +
> +       if (p + len < p)
> +               return NULL;
> +       return p;
> +}
> +
> +uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
> +{
> +       const uint32_t *tagp, *lenp;
> +       uint32_t tag;
> +       int offset = startoffset;
> +       const char *p;
> +
> +       *nextoffset = -FDT_ERR_TRUNCATED;
> +       tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
> +       if (!tagp)
> +               return FDT_END; /* premature end */
> +       tag = fdt32_to_cpu(*tagp);
> +       offset += FDT_TAGSIZE;
> +
> +       *nextoffset = -FDT_ERR_BADSTRUCTURE;
> +       switch (tag) {
> +       case FDT_BEGIN_NODE:
> +               /* skip name */
> +               do {
> +                       p = fdt_offset_ptr(fdt, offset++, 1);
> +               } while (p && (*p != '\0'));
> +               if (!p)
> +                       return FDT_END; /* premature end */
> +               break;
> +
> +       case FDT_PROP:
> +               lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
> +               if (!lenp)
> +                       return FDT_END; /* premature end */
> +               /* skip-name offset, length and value */
> +               offset += sizeof(struct fdt_property) - FDT_TAGSIZE
> +                       + fdt32_to_cpu(*lenp);
> +               break;
> +
> +       case FDT_END:
> +       case FDT_END_NODE:
> +       case FDT_NOP:
> +               break;
> +
> +       default:
> +               return FDT_END;
> +       }
> +
> +       if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
> +               return FDT_END; /* premature end */
> +
> +       *nextoffset = FDT_TAGALIGN(offset);
> +       return tag;
> +}
> +
> +int _fdt_check_node_offset(const void *fdt, int offset)
> +{
> +       if ((offset < 0) || (offset % FDT_TAGSIZE)
> +           || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
> +               return -FDT_ERR_BADOFFSET;
> +
> +       return offset;
> +}
> +
> +int _fdt_check_prop_offset(const void *fdt, int offset)
> +{
> +       if ((offset < 0) || (offset % FDT_TAGSIZE)
> +           || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
> +               return -FDT_ERR_BADOFFSET;
> +
> +       return offset;
> +}
> +
> +int fdt_next_node(const void *fdt, int offset, int *depth)
> +{
> +       int nextoffset = 0;
> +       uint32_t tag;
> +
> +       if (offset >= 0)
> +               if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
> +                       return nextoffset;
> +
> +       do {
> +               offset = nextoffset;
> +               tag = fdt_next_tag(fdt, offset, &nextoffset);
> +
> +               switch (tag) {
> +               case FDT_PROP:
> +               case FDT_NOP:
> +                       break;
> +
> +               case FDT_BEGIN_NODE:
> +                       if (depth)
> +                               (*depth)++;
> +                       break;
> +
> +               case FDT_END_NODE:
> +                       if (depth && ((--(*depth)) < 0))
> +                               return nextoffset;
> +                       break;
> +
> +               case FDT_END:
> +                       if ((nextoffset >= 0)
> +                           || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
> +                               return -FDT_ERR_NOTFOUND;
> +                       else
> +                               return nextoffset;
> +               }
> +       } while (tag != FDT_BEGIN_NODE);
> +
> +       return offset;
> +}
> +
> +const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
> +{
> +       int len = strlen(s) + 1;
> +       const char *last = strtab + tabsize - len;
> +       const char *p;
> +
> +       for (p = strtab; p <= last; p++)
> +               if (memcmp(p, s, len) == 0)
> +                       return p;
> +       return NULL;
> +}
> +
> +int fdt_move(const void *fdt, void *buf, int bufsize)
> +{
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (fdt_totalsize(fdt) > bufsize)
> +               return -FDT_ERR_NOSPACE;
> +
> +       memmove(buf, fdt, fdt_totalsize(fdt));
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
> new file mode 100644
> index 0000000..48ccfd9
> --- /dev/null
> +++ b/xen/common/libfdt/fdt.h
> @@ -0,0 +1,60 @@
> +#ifndef _FDT_H
> +#define _FDT_H
> +
> +#ifndef __ASSEMBLY__
> +
> +struct fdt_header {
> +       uint32_t magic;                  /* magic word FDT_MAGIC */
> +       uint32_t totalsize;              /* total size of DT block */
> +       uint32_t off_dt_struct;          /* offset to structure */
> +       uint32_t off_dt_strings;         /* offset to strings */
> +       uint32_t off_mem_rsvmap;         /* offset to memory reserve map */
> +       uint32_t version;                /* format version */
> +       uint32_t last_comp_version;      /* last compatible version */
> +
> +       /* version 2 fields below */
> +       uint32_t boot_cpuid_phys;        /* Which physical CPU id we're
> +                                           booting on */
> +       /* version 3 fields below */
> +       uint32_t size_dt_strings;        /* size of the strings block */
> +
> +       /* version 17 fields below */
> +       uint32_t size_dt_struct;         /* size of the structure block */
> +};
> +
> +struct fdt_reserve_entry {
> +       uint64_t address;
> +       uint64_t size;
> +};
> +
> +struct fdt_node_header {
> +       uint32_t tag;
> +       char name[0];
> +};
> +
> +struct fdt_property {
> +       uint32_t tag;
> +       uint32_t len;
> +       uint32_t nameoff;
> +       char data[0];
> +};
> +
> +#endif /* !__ASSEMBLY */
> +
> +#define FDT_MAGIC      0xd00dfeed      /* 4: version, 4: total size */
> +#define FDT_TAGSIZE    sizeof(uint32_t)
> +
> +#define FDT_BEGIN_NODE 0x1             /* Start node: full name */
> +#define FDT_END_NODE   0x2             /* End node */
> +#define FDT_PROP       0x3             /* Property: name off,
> +                                          size, content */
> +#define FDT_NOP                0x4             /* nop */
> +#define FDT_END                0x9
> +
> +#define FDT_V1_SIZE    (7*sizeof(uint32_t))
> +#define FDT_V2_SIZE    (FDT_V1_SIZE + sizeof(uint32_t))
> +#define FDT_V3_SIZE    (FDT_V2_SIZE + sizeof(uint32_t))
> +#define FDT_V16_SIZE   FDT_V3_SIZE
> +#define FDT_V17_SIZE   (FDT_V16_SIZE + sizeof(uint32_t))
> +
> +#endif /* _FDT_H */
> diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
> new file mode 100644
> index 0000000..02b6d68
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_ro.c
> @@ -0,0 +1,574 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +static int _fdt_nodename_eq(const void *fdt, int offset,
> +                           const char *s, int len)
> +{
> +       const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
> +
> +       if (! p)
> +               /* short match */
> +               return 0;
> +
> +       if (memcmp(p, s, len) != 0)
> +               return 0;
> +
> +       if (p[len] == '\0')
> +               return 1;
> +       else if (!memchr(s, '@', len) && (p[len] == '@'))
> +               return 1;
> +       else
> +               return 0;
> +}
> +
> +const char *fdt_string(const void *fdt, int stroffset)
> +{
> +       return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
> +}
> +
> +static int _fdt_string_eq(const void *fdt, int stroffset,
> +                         const char *s, int len)
> +{
> +       const char *p = fdt_string(fdt, stroffset);
> +
> +       return (strlen(p) == len) && (memcmp(p, s, len) == 0);
> +}
> +
> +int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
> +{
> +       FDT_CHECK_HEADER(fdt);
> +       *address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
> +       *size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
> +       return 0;
> +}
> +
> +int fdt_num_mem_rsv(const void *fdt)
> +{
> +       int i = 0;
> +
> +       while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
> +               i++;
> +       return i;
> +}
> +
> +static int _nextprop(const void *fdt, int offset)
> +{
> +       uint32_t tag;
> +       int nextoffset;
> +
> +       do {
> +               tag = fdt_next_tag(fdt, offset, &nextoffset);
> +
> +               switch (tag) {
> +               case FDT_END:
> +                       if (nextoffset >= 0)
> +                               return -FDT_ERR_BADSTRUCTURE;
> +                       else
> +                               return nextoffset;
> +
> +               case FDT_PROP:
> +                       return offset;
> +               }
> +               offset = nextoffset;
> +       } while (tag == FDT_NOP);
> +
> +       return -FDT_ERR_NOTFOUND;
> +}
> +
> +int fdt_subnode_offset_namelen(const void *fdt, int offset,
> +                              const char *name, int namelen)
> +{
> +       int depth;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       for (depth = 0;
> +            (offset >= 0) && (depth >= 0);
> +            offset = fdt_next_node(fdt, offset, &depth))
> +               if ((depth == 1)
> +                   && _fdt_nodename_eq(fdt, offset, name, namelen))
> +                       return offset;
> +
> +       if (depth < 0)
> +               return -FDT_ERR_NOTFOUND;
> +       return offset; /* error */
> +}
> +
> +int fdt_subnode_offset(const void *fdt, int parentoffset,
> +                      const char *name)
> +{
> +       return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
> +}
> +
> +int fdt_path_offset(const void *fdt, const char *path)
> +{
> +       const char *end = path + strlen(path);
> +       const char *p = path;
> +       int offset = 0;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* see if we have an alias */
> +       if (*path != '/') {
> +               const char *q = strchr(path, '/');
> +
> +               if (!q)
> +                       q = end;
> +
> +               p = fdt_get_alias_namelen(fdt, p, q - p);
> +               if (!p)
> +                       return -FDT_ERR_BADPATH;
> +               offset = fdt_path_offset(fdt, p);
> +
> +               p = q;
> +       }
> +
> +       while (*p) {
> +               const char *q;
> +
> +               while (*p == '/')
> +                       p++;
> +               if (! *p)
> +                       return offset;
> +               q = strchr(p, '/');
> +               if (! q)
> +                       q = end;
> +
> +               offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
> +               if (offset < 0)
> +                       return offset;
> +
> +               p = q;
> +       }
> +
> +       return offset;
> +}
> +
> +const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
> +{
> +       const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
> +       int err;
> +
> +       if (((err = fdt_check_header(fdt)) != 0)
> +           || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
> +                       goto fail;
> +
> +       if (len)
> +               *len = strlen(nh->name);
> +
> +       return nh->name;
> +
> + fail:
> +       if (len)
> +               *len = err;
> +       return NULL;
> +}
> +
> +int fdt_first_property_offset(const void *fdt, int nodeoffset)
> +{
> +       int offset;
> +
> +       if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
> +               return offset;
> +
> +       return _nextprop(fdt, offset);
> +}
> +
> +int fdt_next_property_offset(const void *fdt, int offset)
> +{
> +       if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
> +               return offset;
> +
> +       return _nextprop(fdt, offset);
> +}
> +
> +const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
> +                                                     int offset,
> +                                                     int *lenp)
> +{
> +       int err;
> +       const struct fdt_property *prop;
> +
> +       if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
> +               if (lenp)
> +                       *lenp = err;
> +               return NULL;
> +       }
> +
> +       prop = _fdt_offset_ptr(fdt, offset);
> +
> +       if (lenp)
> +               *lenp = fdt32_to_cpu(prop->len);
> +
> +       return prop;
> +}
> +
> +const struct fdt_property *fdt_get_property_namelen(const void *fdt,
> +                                                   int offset,
> +                                                   const char *name,
> +                                                   int namelen, int *lenp)
> +{
> +       for (offset = fdt_first_property_offset(fdt, offset);
> +            (offset >= 0);
> +            (offset = fdt_next_property_offset(fdt, offset))) {
> +               const struct fdt_property *prop;
> +
> +               if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
> +                       offset = -FDT_ERR_INTERNAL;
> +                       break;
> +               }
> +               if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
> +                                  name, namelen))
> +                       return prop;
> +       }
> +
> +       if (lenp)
> +               *lenp = offset;
> +       return NULL;
> +}
> +
> +const struct fdt_property *fdt_get_property(const void *fdt,
> +                                           int nodeoffset,
> +                                           const char *name, int *lenp)
> +{
> +       return fdt_get_property_namelen(fdt, nodeoffset, name,
> +                                       strlen(name), lenp);
> +}
> +
> +const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> +                               const char *name, int namelen, int *lenp)
> +{
> +       const struct fdt_property *prop;
> +
> +       prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
> +       if (! prop)
> +               return NULL;
> +
> +       return prop->data;
> +}
> +
> +const void *fdt_getprop_by_offset(const void *fdt, int offset,
> +                                 const char **namep, int *lenp)
> +{
> +       const struct fdt_property *prop;
> +
> +       prop = fdt_get_property_by_offset(fdt, offset, lenp);
> +       if (!prop)
> +               return NULL;
> +       if (namep)
> +               *namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
> +       return prop->data;
> +}
> +
> +const void *fdt_getprop(const void *fdt, int nodeoffset,
> +                       const char *name, int *lenp)
> +{
> +       return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
> +}
> +
> +uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
> +{
> +       const uint32_t *php;
> +       int len;
> +
> +       /* FIXME: This is a bit sub-optimal, since we potentially scan
> +        * over all the properties twice. */
> +       php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
> +       if (!php || (len != sizeof(*php))) {
> +               php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
> +               if (!php || (len != sizeof(*php)))
> +                       return 0;
> +       }
> +
> +       return fdt32_to_cpu(*php);
> +}
> +
> +const char *fdt_get_alias_namelen(const void *fdt,
> +                                 const char *name, int namelen)
> +{
> +       int aliasoffset;
> +
> +       aliasoffset = fdt_path_offset(fdt, "/aliases");
> +       if (aliasoffset < 0)
> +               return NULL;
> +
> +       return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
> +}
> +
> +const char *fdt_get_alias(const void *fdt, const char *name)
> +{
> +       return fdt_get_alias_namelen(fdt, name, strlen(name));
> +}
> +
> +int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
> +{
> +       int pdepth = 0, p = 0;
> +       int offset, depth, namelen;
> +       const char *name;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (buflen < 2)
> +               return -FDT_ERR_NOSPACE;
> +
> +       for (offset = 0, depth = 0;
> +            (offset >= 0) && (offset <= nodeoffset);
> +            offset = fdt_next_node(fdt, offset, &depth)) {
> +               while (pdepth > depth) {
> +                       do {
> +                               p--;
> +                       } while (buf[p-1] != '/');
> +                       pdepth--;
> +               }
> +
> +               if (pdepth >= depth) {
> +                       name = fdt_get_name(fdt, offset, &namelen);
> +                       if (!name)
> +                               return namelen;
> +                       if ((p + namelen + 1) <= buflen) {
> +                               memcpy(buf + p, name, namelen);
> +                               p += namelen;
> +                               buf[p++] = '/';
> +                               pdepth++;
> +                       }
> +               }
> +
> +               if (offset == nodeoffset) {
> +                       if (pdepth < (depth + 1))
> +                               return -FDT_ERR_NOSPACE;
> +
> +                       if (p > 1) /* special case so that root path is "/", not "" */
> +                               p--;
> +                       buf[p] = '\0';
> +                       return 0;
> +               }
> +       }
> +
> +       if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
> +               return -FDT_ERR_BADOFFSET;
> +       else if (offset == -FDT_ERR_BADOFFSET)
> +               return -FDT_ERR_BADSTRUCTURE;
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
> +                                int supernodedepth, int *nodedepth)
> +{
> +       int offset, depth;
> +       int supernodeoffset = -FDT_ERR_INTERNAL;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (supernodedepth < 0)
> +               return -FDT_ERR_NOTFOUND;
> +
> +       for (offset = 0, depth = 0;
> +            (offset >= 0) && (offset <= nodeoffset);
> +            offset = fdt_next_node(fdt, offset, &depth)) {
> +               if (depth == supernodedepth)
> +                       supernodeoffset = offset;
> +
> +               if (offset == nodeoffset) {
> +                       if (nodedepth)
> +                               *nodedepth = depth;
> +
> +                       if (supernodedepth > depth)
> +                               return -FDT_ERR_NOTFOUND;
> +                       else
> +                               return supernodeoffset;
> +               }
> +       }
> +
> +       if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
> +               return -FDT_ERR_BADOFFSET;
> +       else if (offset == -FDT_ERR_BADOFFSET)
> +               return -FDT_ERR_BADSTRUCTURE;
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +int fdt_node_depth(const void *fdt, int nodeoffset)
> +{
> +       int nodedepth;
> +       int err;
> +
> +       err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
> +       if (err)
> +               return (err < 0) ? err : -FDT_ERR_INTERNAL;
> +       return nodedepth;
> +}
> +
> +int fdt_parent_offset(const void *fdt, int nodeoffset)
> +{
> +       int nodedepth = fdt_node_depth(fdt, nodeoffset);
> +
> +       if (nodedepth < 0)
> +               return nodedepth;
> +       return fdt_supernode_atdepth_offset(fdt, nodeoffset,
> +                                           nodedepth - 1, NULL);
> +}
> +
> +int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
> +                                 const char *propname,
> +                                 const void *propval, int proplen)
> +{
> +       int offset;
> +       const void *val;
> +       int len;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* FIXME: The algorithm here is pretty horrible: we scan each
> +        * property of a node in fdt_getprop(), then if that didn't
> +        * find what we want, we scan over them again making our way
> +        * to the next node.  Still it's the easiest to implement
> +        * approach; performance can come later. */
> +       for (offset = fdt_next_node(fdt, startoffset, NULL);
> +            offset >= 0;
> +            offset = fdt_next_node(fdt, offset, NULL)) {
> +               val = fdt_getprop(fdt, offset, propname, &len);
> +               if (val && (len == proplen)
> +                   && (memcmp(val, propval, len) == 0))
> +                       return offset;
> +       }
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
> +{
> +       int offset;
> +
> +       if ((phandle == 0) || (phandle == -1))
> +               return -FDT_ERR_BADPHANDLE;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* FIXME: The algorithm here is pretty horrible: we
> +        * potentially scan each property of a node in
> +        * fdt_get_phandle(), then if that didn't find what
> +        * we want, we scan over them again making our way to the next
> +        * node.  Still it's the easiest to implement approach;
> +        * performance can come later. */
> +       for (offset = fdt_next_node(fdt, -1, NULL);
> +            offset >= 0;
> +            offset = fdt_next_node(fdt, offset, NULL)) {
> +               if (fdt_get_phandle(fdt, offset) == phandle)
> +                       return offset;
> +       }
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +static int _fdt_stringlist_contains(const char *strlist, int listlen,
> +                                   const char *str)
> +{
> +       int len = strlen(str);
> +       const char *p;
> +
> +       while (listlen >= len) {
> +               if (memcmp(str, strlist, len+1) == 0)
> +                       return 1;
> +               p = memchr(strlist, '\0', listlen);
> +               if (!p)
> +                       return 0; /* malformed strlist.. */
> +               listlen -= (p-strlist) + 1;
> +               strlist = p + 1;
> +       }
> +       return 0;
> +}
> +
> +int fdt_node_check_compatible(const void *fdt, int nodeoffset,
> +                             const char *compatible)
> +{
> +       const void *prop;
> +       int len;
> +
> +       prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
> +       if (!prop)
> +               return len;
> +       if (_fdt_stringlist_contains(prop, len, compatible))
> +               return 0;
> +       else
> +               return 1;
> +}
> +
> +int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
> +                                 const char *compatible)
> +{
> +       int offset, err;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* FIXME: The algorithm here is pretty horrible: we scan each
> +        * property of a node in fdt_node_check_compatible(), then if
> +        * that didn't find what we want, we scan over them again
> +        * making our way to the next node.  Still it's the easiest to
> +        * implement approach; performance can come later. */
> +       for (offset = fdt_next_node(fdt, startoffset, NULL);
> +            offset >= 0;
> +            offset = fdt_next_node(fdt, offset, NULL)) {
> +               err = fdt_node_check_compatible(fdt, offset, compatible);
> +               if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
> +                       return err;
> +               else if (err == 0)
> +                       return offset;
> +       }
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
> new file mode 100644
> index 0000000..994037b
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_rw.c
> @@ -0,0 +1,465 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +static int _fdt_blocks_misordered(const void *fdt,
> +                             int mem_rsv_size, int struct_size)
> +{
> +       return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
> +               || (fdt_off_dt_struct(fdt) <
> +                   (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
> +               || (fdt_off_dt_strings(fdt) <
> +                   (fdt_off_dt_struct(fdt) + struct_size))
> +               || (fdt_totalsize(fdt) <
> +                   (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
> +}
> +
> +static int _fdt_rw_check_header(void *fdt)
> +{
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (fdt_version(fdt) < 17)
> +               return -FDT_ERR_BADVERSION;
> +       if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
> +                                  fdt_size_dt_struct(fdt)))
> +               return -FDT_ERR_BADLAYOUT;
> +       if (fdt_version(fdt) > 17)
> +               fdt_set_version(fdt, 17);
> +
> +       return 0;
> +}
> +
> +#define FDT_RW_CHECK_HEADER(fdt) \
> +       { \
> +               int err; \
> +               if ((err = _fdt_rw_check_header(fdt)) != 0) \
> +                       return err; \
> +       }
> +
> +static inline int _fdt_data_size(void *fdt)
> +{
> +       return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
> +}
> +
> +static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
> +{
> +       char *p = splicepoint;
> +       char *end = (char *)fdt + _fdt_data_size(fdt);
> +
> +       if (((p + oldlen) < p) || ((p + oldlen) > end))
> +               return -FDT_ERR_BADOFFSET;
> +       if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
> +               return -FDT_ERR_NOSPACE;
> +       memmove(p + newlen, p + oldlen, end - p - oldlen);
> +       return 0;
> +}
> +
> +static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
> +                              int oldn, int newn)
> +{
> +       int delta = (newn - oldn) * sizeof(*p);
> +       int err;
> +       err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
> +       if (err)
> +               return err;
> +       fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
> +       fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
> +       return 0;
> +}
> +
> +static int _fdt_splice_struct(void *fdt, void *p,
> +                             int oldlen, int newlen)
> +{
> +       int delta = newlen - oldlen;
> +       int err;
> +
> +       if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
> +               return err;
> +
> +       fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
> +       fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
> +       return 0;
> +}
> +
> +static int _fdt_splice_string(void *fdt, int newlen)
> +{
> +       void *p = (char *)fdt
> +               + fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
> +       int err;
> +
> +       if ((err = _fdt_splice(fdt, p, 0, newlen)))
> +               return err;
> +
> +       fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
> +       return 0;
> +}
> +
> +static int _fdt_find_add_string(void *fdt, const char *s)
> +{
> +       char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
> +       const char *p;
> +       char *new;
> +       int len = strlen(s) + 1;
> +       int err;
> +
> +       p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
> +       if (p)
> +               /* found it */
> +               return (p - strtab);
> +
> +       new = strtab + fdt_size_dt_strings(fdt);
> +       err = _fdt_splice_string(fdt, len);
> +       if (err)
> +               return err;
> +
> +       memcpy(new, s, len);
> +       return (new - strtab);
> +}
> +
> +int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
> +{
> +       struct fdt_reserve_entry *re;
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
> +       err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
> +       if (err)
> +               return err;
> +
> +       re->address = cpu_to_fdt64(address);
> +       re->size = cpu_to_fdt64(size);
> +       return 0;
> +}
> +
> +int fdt_del_mem_rsv(void *fdt, int n)
> +{
> +       struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       if (n >= fdt_num_mem_rsv(fdt))
> +               return -FDT_ERR_NOTFOUND;
> +
> +       err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
> +       if (err)
> +               return err;
> +       return 0;
> +}
> +
> +static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
> +                               int len, struct fdt_property **prop)
> +{
> +       int oldlen;
> +       int err;
> +
> +       *prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
> +       if (! (*prop))
> +               return oldlen;
> +
> +       if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
> +                                     FDT_TAGALIGN(len))))
> +               return err;
> +
> +       (*prop)->len = cpu_to_fdt32(len);
> +       return 0;
> +}
> +
> +static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
> +                            int len, struct fdt_property **prop)
> +{
> +       int proplen;
> +       int nextoffset;
> +       int namestroff;
> +       int err;
> +
> +       if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
> +               return nextoffset;
> +
> +       namestroff = _fdt_find_add_string(fdt, name);
> +       if (namestroff < 0)
> +               return namestroff;
> +
> +       *prop = _fdt_offset_ptr_w(fdt, nextoffset);
> +       proplen = sizeof(**prop) + FDT_TAGALIGN(len);
> +
> +       err = _fdt_splice_struct(fdt, *prop, 0, proplen);
> +       if (err)
> +               return err;
> +
> +       (*prop)->tag = cpu_to_fdt32(FDT_PROP);
> +       (*prop)->nameoff = cpu_to_fdt32(namestroff);
> +       (*prop)->len = cpu_to_fdt32(len);
> +       return 0;
> +}
> +
> +int fdt_set_name(void *fdt, int nodeoffset, const char *name)
> +{
> +       char *namep;
> +       int oldlen, newlen;
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
> +       if (!namep)
> +               return oldlen;
> +
> +       newlen = strlen(name);
> +
> +       err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
> +                                FDT_TAGALIGN(newlen+1));
> +       if (err)
> +               return err;
> +
> +       memcpy(namep, name, newlen+1);
> +       return 0;
> +}
> +
> +int fdt_setprop(void *fdt, int nodeoffset, const char *name,
> +               const void *val, int len)
> +{
> +       struct fdt_property *prop;
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
> +       if (err == -FDT_ERR_NOTFOUND)
> +               err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
> +       if (err)
> +               return err;
> +
> +       memcpy(prop->data, val, len);
> +       return 0;
> +}
> +
> +int fdt_delprop(void *fdt, int nodeoffset, const char *name)
> +{
> +       struct fdt_property *prop;
> +       int len, proplen;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
> +       if (! prop)
> +               return len;
> +
> +       proplen = sizeof(*prop) + FDT_TAGALIGN(len);
> +       return _fdt_splice_struct(fdt, prop, proplen, 0);
> +}
> +
> +int fdt_add_subnode_namelen(void *fdt, int parentoffset,
> +                           const char *name, int namelen)
> +{
> +       struct fdt_node_header *nh;
> +       int offset, nextoffset;
> +       int nodelen;
> +       int err;
> +       uint32_t tag;
> +       uint32_t *endtag;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
> +       if (offset >= 0)
> +               return -FDT_ERR_EXISTS;
> +       else if (offset != -FDT_ERR_NOTFOUND)
> +               return offset;
> +
> +       /* Try to place the new node after the parent's properties */
> +       fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
> +       do {
> +               offset = nextoffset;
> +               tag = fdt_next_tag(fdt, offset, &nextoffset);
> +       } while ((tag == FDT_PROP) || (tag == FDT_NOP));
> +
> +       nh = _fdt_offset_ptr_w(fdt, offset);
> +       nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
> +
> +       err = _fdt_splice_struct(fdt, nh, 0, nodelen);
> +       if (err)
> +               return err;
> +
> +       nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
> +       memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
> +       memcpy(nh->name, name, namelen);
> +       endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
> +       *endtag = cpu_to_fdt32(FDT_END_NODE);
> +
> +       return offset;
> +}
> +
> +int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
> +{
> +       return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
> +}
> +
> +int fdt_del_node(void *fdt, int nodeoffset)
> +{
> +       int endoffset;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       endoffset = _fdt_node_end_offset(fdt, nodeoffset);
> +       if (endoffset < 0)
> +               return endoffset;
> +
> +       return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
> +                                 endoffset - nodeoffset, 0);
> +}
> +
> +static void _fdt_packblocks(const char *old, char *new,
> +                           int mem_rsv_size, int struct_size)
> +{
> +       int mem_rsv_off, struct_off, strings_off;
> +
> +       mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
> +       struct_off = mem_rsv_off + mem_rsv_size;
> +       strings_off = struct_off + struct_size;
> +
> +       memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
> +       fdt_set_off_mem_rsvmap(new, mem_rsv_off);
> +
> +       memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
> +       fdt_set_off_dt_struct(new, struct_off);
> +       fdt_set_size_dt_struct(new, struct_size);
> +
> +       memmove(new + strings_off, old + fdt_off_dt_strings(old),
> +               fdt_size_dt_strings(old));
> +       fdt_set_off_dt_strings(new, strings_off);
> +       fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
> +}
> +
> +int fdt_open_into(const void *fdt, void *buf, int bufsize)
> +{
> +       int err;
> +       int mem_rsv_size, struct_size;
> +       int newsize;
> +       const char *fdtstart = fdt;
> +       const char *fdtend = fdtstart + fdt_totalsize(fdt);
> +       char *tmp;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
> +               * sizeof(struct fdt_reserve_entry);
> +
> +       if (fdt_version(fdt) >= 17) {
> +               struct_size = fdt_size_dt_struct(fdt);
> +       } else {
> +               struct_size = 0;
> +               while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
> +                       ;
> +               if (struct_size < 0)
> +                       return struct_size;
> +       }
> +
> +       if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
> +               /* no further work necessary */
> +               err = fdt_move(fdt, buf, bufsize);
> +               if (err)
> +                       return err;
> +               fdt_set_version(buf, 17);
> +               fdt_set_size_dt_struct(buf, struct_size);
> +               fdt_set_totalsize(buf, bufsize);
> +               return 0;
> +       }
> +
> +       /* Need to reorder */
> +       newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
> +               + struct_size + fdt_size_dt_strings(fdt);
> +
> +       if (bufsize < newsize)
> +               return -FDT_ERR_NOSPACE;
> +
> +       /* First attempt to build converted tree at beginning of buffer */
> +       tmp = buf;
> +       /* But if that overlaps with the old tree... */
> +       if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
> +               /* Try right after the old tree instead */
> +               tmp = (char *)(uintptr_t)fdtend;
> +               if ((tmp + newsize) > ((char *)buf + bufsize))
> +                       return -FDT_ERR_NOSPACE;
> +       }
> +
> +       _fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
> +       memmove(buf, tmp, newsize);
> +
> +       fdt_set_magic(buf, FDT_MAGIC);
> +       fdt_set_totalsize(buf, bufsize);
> +       fdt_set_version(buf, 17);
> +       fdt_set_last_comp_version(buf, 16);
> +       fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
> +
> +       return 0;
> +}
> +
> +int fdt_pack(void *fdt)
> +{
> +       int mem_rsv_size;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
> +               * sizeof(struct fdt_reserve_entry);
> +       _fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
> +       fdt_set_totalsize(fdt, _fdt_data_size(fdt));
> +
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
> new file mode 100644
> index 0000000..e6c3cee
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_strerror.c
> @@ -0,0 +1,96 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +struct fdt_errtabent {
> +       const char *str;
> +};
> +
> +#define FDT_ERRTABENT(val) \
> +       [(val)] = { .str = #val, }
> +
> +static struct fdt_errtabent fdt_errtable[] = {
> +       FDT_ERRTABENT(FDT_ERR_NOTFOUND),
> +       FDT_ERRTABENT(FDT_ERR_EXISTS),
> +       FDT_ERRTABENT(FDT_ERR_NOSPACE),
> +
> +       FDT_ERRTABENT(FDT_ERR_BADOFFSET),
> +       FDT_ERRTABENT(FDT_ERR_BADPATH),
> +       FDT_ERRTABENT(FDT_ERR_BADSTATE),
> +
> +       FDT_ERRTABENT(FDT_ERR_TRUNCATED),
> +       FDT_ERRTABENT(FDT_ERR_BADMAGIC),
> +       FDT_ERRTABENT(FDT_ERR_BADVERSION),
> +       FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
> +       FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
> +};
> +#define FDT_ERRTABSIZE (sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
> +
> +const char *fdt_strerror(int errval)
> +{
> +       if (errval > 0)
> +               return "<valid offset/length>";
> +       else if (errval == 0)
> +               return "<no error>";
> +       else if (errval > -FDT_ERRTABSIZE) {
> +               const char *s = fdt_errtable[-errval].str;
> +
> +               if (s)
> +                       return s;
> +       }
> +
> +       return "<unknown error>";
> +}
> diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
> new file mode 100644
> index 0000000..55ebebf
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_sw.c
> @@ -0,0 +1,256 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +static int _fdt_sw_check_header(void *fdt)
> +{
> +       if (fdt_magic(fdt) != FDT_SW_MAGIC)
> +               return -FDT_ERR_BADMAGIC;
> +       /* FIXME: should check more details about the header state */
> +       return 0;
> +}
> +
> +#define FDT_SW_CHECK_HEADER(fdt) \
> +       { \
> +               int err; \
> +               if ((err = _fdt_sw_check_header(fdt)) != 0) \
> +                       return err; \
> +       }
> +
> +static void *_fdt_grab_space(void *fdt, size_t len)
> +{
> +       int offset = fdt_size_dt_struct(fdt);
> +       int spaceleft;
> +
> +       spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
> +               - fdt_size_dt_strings(fdt);
> +
> +       if ((offset + len < offset) || (offset + len > spaceleft))
> +               return NULL;
> +
> +       fdt_set_size_dt_struct(fdt, offset + len);
> +       return _fdt_offset_ptr_w(fdt, offset);
> +}
> +
> +int fdt_create(void *buf, int bufsize)
> +{
> +       void *fdt = buf;
> +
> +       if (bufsize < sizeof(struct fdt_header))
> +               return -FDT_ERR_NOSPACE;
> +
> +       memset(buf, 0, bufsize);
> +
> +       fdt_set_magic(fdt, FDT_SW_MAGIC);
> +       fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
> +       fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
> +       fdt_set_totalsize(fdt,  bufsize);
> +
> +       fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
> +                                             sizeof(struct fdt_reserve_entry)));
> +       fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
> +       fdt_set_off_dt_strings(fdt, bufsize);
> +
> +       return 0;
> +}
> +
> +int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
> +{
> +       struct fdt_reserve_entry *re;
> +       int offset;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       if (fdt_size_dt_struct(fdt))
> +               return -FDT_ERR_BADSTATE;
> +
> +       offset = fdt_off_dt_struct(fdt);
> +       if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
> +               return -FDT_ERR_NOSPACE;
> +
> +       re = (struct fdt_reserve_entry *)((char *)fdt + offset);
> +       re->address = cpu_to_fdt64(addr);
> +       re->size = cpu_to_fdt64(size);
> +
> +       fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
> +
> +       return 0;
> +}
> +
> +int fdt_finish_reservemap(void *fdt)
> +{
> +       return fdt_add_reservemap_entry(fdt, 0, 0);
> +}
> +
> +int fdt_begin_node(void *fdt, const char *name)
> +{
> +       struct fdt_node_header *nh;
> +       int namelen = strlen(name) + 1;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
> +       if (! nh)
> +               return -FDT_ERR_NOSPACE;
> +
> +       nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
> +       memcpy(nh->name, name, namelen);
> +       return 0;
> +}
> +
> +int fdt_end_node(void *fdt)
> +{
> +       uint32_t *en;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       en = _fdt_grab_space(fdt, FDT_TAGSIZE);
> +       if (! en)
> +               return -FDT_ERR_NOSPACE;
> +
> +       *en = cpu_to_fdt32(FDT_END_NODE);
> +       return 0;
> +}
> +
> +static int _fdt_find_add_string(void *fdt, const char *s)
> +{
> +       char *strtab = (char *)fdt + fdt_totalsize(fdt);
> +       const char *p;
> +       int strtabsize = fdt_size_dt_strings(fdt);
> +       int len = strlen(s) + 1;
> +       int struct_top, offset;
> +
> +       p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
> +       if (p)
> +               return p - strtab;
> +
> +       /* Add it */
> +       offset = -strtabsize - len;
> +       struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
> +       if (fdt_totalsize(fdt) + offset < struct_top)
> +               return 0; /* no more room :( */
> +
> +       memcpy(strtab + offset, s, len);
> +       fdt_set_size_dt_strings(fdt, strtabsize + len);
> +       return offset;
> +}
> +
> +int fdt_property(void *fdt, const char *name, const void *val, int len)
> +{
> +       struct fdt_property *prop;
> +       int nameoff;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       nameoff = _fdt_find_add_string(fdt, name);
> +       if (nameoff == 0)
> +               return -FDT_ERR_NOSPACE;
> +
> +       prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
> +       if (! prop)
> +               return -FDT_ERR_NOSPACE;
> +
> +       prop->tag = cpu_to_fdt32(FDT_PROP);
> +       prop->nameoff = cpu_to_fdt32(nameoff);
> +       prop->len = cpu_to_fdt32(len);
> +       memcpy(prop->data, val, len);
> +       return 0;
> +}
> +
> +int fdt_finish(void *fdt)
> +{
> +       char *p = (char *)fdt;
> +       uint32_t *end;
> +       int oldstroffset, newstroffset;
> +       uint32_t tag;
> +       int offset, nextoffset;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       /* Add terminator */
> +       end = _fdt_grab_space(fdt, sizeof(*end));
> +       if (! end)
> +               return -FDT_ERR_NOSPACE;
> +       *end = cpu_to_fdt32(FDT_END);
> +
> +       /* Relocate the string table */
> +       oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
> +       newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
> +       memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
> +       fdt_set_off_dt_strings(fdt, newstroffset);
> +
> +       /* Walk the structure, correcting string offsets */
> +       offset = 0;
> +       while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
> +               if (tag == FDT_PROP) {
> +                       struct fdt_property *prop =
> +                               _fdt_offset_ptr_w(fdt, offset);
> +                       int nameoff;
> +
> +                       nameoff = fdt32_to_cpu(prop->nameoff);
> +                       nameoff += fdt_size_dt_strings(fdt);
> +                       prop->nameoff = cpu_to_fdt32(nameoff);
> +               }
> +               offset = nextoffset;
> +       }
> +       if (nextoffset < 0)
> +               return nextoffset;
> +
> +       /* Finally, adjust the header */
> +       fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
> +       fdt_set_magic(fdt, FDT_MAGIC);
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
> new file mode 100644
> index 0000000..6025fa1
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_wip.c
> @@ -0,0 +1,118 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
> +                       const void *val, int len)
> +{
> +       void *propval;
> +       int proplen;
> +
> +       propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
> +       if (! propval)
> +               return proplen;
> +
> +       if (proplen != len)
> +               return -FDT_ERR_NOSPACE;
> +
> +       memcpy(propval, val, len);
> +       return 0;
> +}
> +
> +static void _fdt_nop_region(void *start, int len)
> +{
> +       uint32_t *p;
> +
> +       for (p = start; (char *)p < ((char *)start + len); p++)
> +               *p = cpu_to_fdt32(FDT_NOP);
> +}
> +
> +int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
> +{
> +       struct fdt_property *prop;
> +       int len;
> +
> +       prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
> +       if (! prop)
> +               return len;
> +
> +       _fdt_nop_region(prop, len + sizeof(*prop));
> +
> +       return 0;
> +}
> +
> +int _fdt_node_end_offset(void *fdt, int offset)
> +{
> +       int depth = 0;
> +
> +       while ((offset >= 0) && (depth >= 0))
> +               offset = fdt_next_node(fdt, offset, &depth);
> +
> +       return offset;
> +}
> +
> +int fdt_nop_node(void *fdt, int nodeoffset)
> +{
> +       int endoffset;
> +
> +       endoffset = _fdt_node_end_offset(fdt, nodeoffset);
> +       if (endoffset < 0)
> +               return endoffset;
> +
> +       _fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
> +                       endoffset - nodeoffset);
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
> new file mode 100644
> index 0000000..55f3eb3
> --- /dev/null
> +++ b/xen/common/libfdt/libfdt.h
> @@ -0,0 +1,1235 @@
> +#ifndef _LIBFDT_H
> +#define _LIBFDT_H
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include <libfdt_env.h>
> +#include <fdt.h>
> +
> +#define FDT_FIRST_SUPPORTED_VERSION    0x10
> +#define FDT_LAST_SUPPORTED_VERSION     0x11
> +
> +/* Error codes: informative error codes */
> +#define FDT_ERR_NOTFOUND       1
> +       /* FDT_ERR_NOTFOUND: The requested node or property does not exist */
> +#define FDT_ERR_EXISTS         2
> +       /* FDT_ERR_EXISTS: Attemped to create a node or property which
> +        * already exists */
> +#define FDT_ERR_NOSPACE                3
> +       /* FDT_ERR_NOSPACE: Operation needed to expand the device
> +        * tree, but its buffer did not have sufficient space to
> +        * contain the expanded tree. Use fdt_open_into() to move the
> +        * device tree to a buffer with more space. */
> +
> +/* Error codes: codes for bad parameters */
> +#define FDT_ERR_BADOFFSET      4
> +       /* FDT_ERR_BADOFFSET: Function was passed a structure block
> +        * offset which is out-of-bounds, or which points to an
> +        * unsuitable part of the structure for the operation. */
> +#define FDT_ERR_BADPATH                5
> +       /* FDT_ERR_BADPATH: Function was passed a badly formatted path
> +        * (e.g. missing a leading / for a function which requires an
> +        * absolute path) */
> +#define FDT_ERR_BADPHANDLE     6
> +       /* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
> +        * value.  phandle values of 0 and -1 are not permitted. */
> +#define FDT_ERR_BADSTATE       7
> +       /* FDT_ERR_BADSTATE: Function was passed an incomplete device
> +        * tree created by the sequential-write functions, which is
> +        * not sufficiently complete for the requested operation. */
> +
> +/* Error codes: codes for bad device tree blobs */
> +#define FDT_ERR_TRUNCATED      8
> +       /* FDT_ERR_TRUNCATED: Structure block of the given device tree
> +        * ends without an FDT_END tag. */
> +#define FDT_ERR_BADMAGIC       9
> +       /* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
> +        * device tree at all - it is missing the flattened device
> +        * tree magic number. */
> +#define FDT_ERR_BADVERSION     10
> +       /* FDT_ERR_BADVERSION: Given device tree has a version which
> +        * can't be handled by the requested operation.  For
> +        * read-write functions, this may mean that fdt_open_into() is
> +        * required to convert the tree to the expected version. */
> +#define FDT_ERR_BADSTRUCTURE   11
> +       /* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
> +        * structure block or other serious error (e.g. misnested
> +        * nodes, or subnodes preceding properties). */
> +#define FDT_ERR_BADLAYOUT      12
> +       /* FDT_ERR_BADLAYOUT: For read-write functions, the given
> +        * device tree has it's sub-blocks in an order that the
> +        * function can't handle (memory reserve map, then structure,
> +        * then strings).  Use fdt_open_into() to reorganize the tree
> +        * into a form suitable for the read-write operations. */
> +
> +/* "Can't happen" error indicating a bug in libfdt */
> +#define FDT_ERR_INTERNAL       13
> +       /* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
> +        * Should never be returned, if it is, it indicates a bug in
> +        * libfdt itself. */
> +
> +#define FDT_ERR_MAX            13
> +
> +/**********************************************************************/
> +/* Low-level functions (you probably don't need these)                */
> +/**********************************************************************/
> +
> +const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
> +static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
> +{
> +       return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
> +}
> +
> +uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
> +
> +/**********************************************************************/
> +/* Traversal functions                                                */
> +/**********************************************************************/
> +
> +int fdt_next_node(const void *fdt, int offset, int *depth);
> +
> +/**********************************************************************/
> +/* General functions                                                  */
> +/**********************************************************************/
> +
> +#define fdt_get_header(fdt, field) \
> +       (fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
> +#define fdt_magic(fdt)                         (fdt_get_header(fdt, magic))
> +#define fdt_totalsize(fdt)             (fdt_get_header(fdt, totalsize))
> +#define fdt_off_dt_struct(fdt)         (fdt_get_header(fdt, off_dt_struct))
> +#define fdt_off_dt_strings(fdt)                (fdt_get_header(fdt, off_dt_strings))
> +#define fdt_off_mem_rsvmap(fdt)                (fdt_get_header(fdt, off_mem_rsvmap))
> +#define fdt_version(fdt)               (fdt_get_header(fdt, version))
> +#define fdt_last_comp_version(fdt)     (fdt_get_header(fdt, last_comp_version))
> +#define fdt_boot_cpuid_phys(fdt)       (fdt_get_header(fdt, boot_cpuid_phys))
> +#define fdt_size_dt_strings(fdt)       (fdt_get_header(fdt, size_dt_strings))
> +#define fdt_size_dt_struct(fdt)                (fdt_get_header(fdt, size_dt_struct))
> +
> +#define __fdt_set_hdr(name) \
> +       static inline void fdt_set_##name(void *fdt, uint32_t val) \
> +       { \
> +               struct fdt_header *fdth = (struct fdt_header*)fdt; \
> +               fdth->name = cpu_to_fdt32(val); \
> +       }
> +__fdt_set_hdr(magic);
> +__fdt_set_hdr(totalsize);
> +__fdt_set_hdr(off_dt_struct);
> +__fdt_set_hdr(off_dt_strings);
> +__fdt_set_hdr(off_mem_rsvmap);
> +__fdt_set_hdr(version);
> +__fdt_set_hdr(last_comp_version);
> +__fdt_set_hdr(boot_cpuid_phys);
> +__fdt_set_hdr(size_dt_strings);
> +__fdt_set_hdr(size_dt_struct);
> +#undef __fdt_set_hdr
> +
> +/**
> + * fdt_check_header - sanity check a device tree or possible device tree
> + * @fdt: pointer to data which might be a flattened device tree
> + *
> + * fdt_check_header() checks that the given buffer contains what
> + * appears to be a flattened device tree with sane information in its
> + * header.
> + *
> + * returns:
> + *     0, if the buffer appears to contain a valid device tree
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings, as above
> + */
> +int fdt_check_header(const void *fdt);
> +
> +/**
> + * fdt_move - move a device tree around in memory
> + * @fdt: pointer to the device tree to move
> + * @buf: pointer to memory where the device is to be moved
> + * @bufsize: size of the memory space at buf
> + *
> + * fdt_move() relocates, if possible, the device tree blob located at
> + * fdt to the buffer at buf of size bufsize.  The buffer may overlap
> + * with the existing device tree blob at fdt.  Therefore,
> + *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
> + * should always succeed.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings
> + */
> +int fdt_move(const void *fdt, void *buf, int bufsize);
> +
> +/**********************************************************************/
> +/* Read-only functions                                                */
> +/**********************************************************************/
> +
> +/**
> + * fdt_string - retrieve a string from the strings block of a device tree
> + * @fdt: pointer to the device tree blob
> + * @stroffset: offset of the string within the strings block (native endian)
> + *
> + * fdt_string() retrieves a pointer to a single string from the
> + * strings block of the device tree blob at fdt.
> + *
> + * returns:
> + *     a pointer to the string, on success
> + *     NULL, if stroffset is out of bounds
> + */
> +const char *fdt_string(const void *fdt, int stroffset);
> +
> +/**
> + * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
> + * @fdt: pointer to the device tree blob
> + *
> + * Returns the number of entries in the device tree blob's memory
> + * reservation map.  This does not include the terminating 0,0 entry
> + * or any other (0,0) entries reserved for expansion.
> + *
> + * returns:
> + *     the number of entries
> + */
> +int fdt_num_mem_rsv(const void *fdt);
> +
> +/**
> + * fdt_get_mem_rsv - retrieve one memory reserve map entry
> + * @fdt: pointer to the device tree blob
> + * @address, @size: pointers to 64-bit variables
> + *
> + * On success, *address and *size will contain the address and size of
> + * the n-th reserve map entry from the device tree blob, in
> + * native-endian format.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings
> + */
> +int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
> +
> +/**
> + * fdt_subnode_offset_namelen - find a subnode based on substring
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + * @namelen: number of characters of name to consider
> + *
> + * Identical to fdt_subnode_offset(), but only examine the first
> + * namelen characters of name for matching the subnode name.  This is
> + * useful for finding subnodes based on a portion of a larger string,
> + * such as a full path.
> + */
> +int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
> +                              const char *name, int namelen);
> +/**
> + * fdt_subnode_offset - find a subnode of a given node
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + *
> + * fdt_subnode_offset() finds a subnode of the node at structure block
> + * offset parentoffset with the given name.  name may include a unit
> + * address, in which case fdt_subnode_offset() will find the subnode
> + * with that unit address, or the unit address may be omitted, in
> + * which case fdt_subnode_offset() will find an arbitrary subnode
> + * whose name excluding unit address matches the given name.
> + *
> + * returns:
> + *     structure block offset of the requested subnode (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the requested subnode does not exist
> + *     -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
> +
> +/**
> + * fdt_path_offset - find a tree node by its full path
> + * @fdt: pointer to the device tree blob
> + * @path: full path of the node to locate
> + *
> + * fdt_path_offset() finds a node of a given path in the device tree.
> + * Each path component may omit the unit address portion, but the
> + * results of this are undefined if any such path component is
> + * ambiguous (that is if there are multiple nodes at the relevant
> + * level matching the given component, differentiated only by unit
> + * address).
> + *
> + * returns:
> + *     structure block offset of the node with the requested path (>=0), on success
> + *     -FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
> + *     -FDT_ERR_NOTFOUND, if the requested node does not exist
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_path_offset(const void *fdt, const char *path);
> +
> +/**
> + * fdt_get_name - retrieve the name of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of the starting node
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_get_name() retrieves the name (including unit address) of the
> + * device tree node at structure block offset nodeoffset.  If lenp is
> + * non-NULL, the length of this name is also returned, in the integer
> + * pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the node's name, on success
> + *             If lenp is non-NULL, *lenp contains the length of that name (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL *lenp contains an error code (<0):
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE, standard meanings
> + */
> +const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
> +
> +/**
> + * fdt_first_property_offset - find the offset of a node's first property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of a node
> + *
> + * fdt_first_property_offset() finds the first property of the node at
> + * the given structure block offset.
> + *
> + * returns:
> + *     structure block offset of the property (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the requested node has no properties
> + *     -FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_first_property_offset(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_next_property_offset - step through a node's properties
> + * @fdt: pointer to the device tree blob
> + * @offset: structure block offset of a property
> + *
> + * fdt_next_property_offset() finds the property immediately after the
> + * one at the given structure block offset.  This will be a property
> + * of the same node as the given property.
> + *
> + * returns:
> + *     structure block offset of the next property (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the given property is the last in its node
> + *     -FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_next_property_offset(const void *fdt, int offset);
> +
> +/**
> + * fdt_get_property_by_offset - retrieve the property at a given offset
> + * @fdt: pointer to the device tree blob
> + * @offset: offset of the property to retrieve
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_get_property_by_offset() retrieves a pointer to the
> + * fdt_property structure within the device tree blob at the given
> + * offset.  If lenp is non-NULL, the length of the property value is
> + * also returned, in the integer pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the structure representing the property
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
> +                                                     int offset,
> +                                                     int *lenp);
> +
> +/**
> + * fdt_get_property_namelen - find a property based on substring
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @namelen: number of characters of name to consider
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * Identical to fdt_get_property_namelen(), but only examine the first
> + * namelen characters of name for matching the property name.
> + */
> +const struct fdt_property *fdt_get_property_namelen(const void *fdt,
> +                                                   int nodeoffset,
> +                                                   const char *name,
> +                                                   int namelen, int *lenp);
> +
> +/**
> + * fdt_get_property - find a given property in a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_get_property() retrieves a pointer to the fdt_property
> + * structure within the device tree blob corresponding to the property
> + * named 'name' of the node at offset nodeoffset.  If lenp is
> + * non-NULL, the length of the property value is also returned, in the
> + * integer pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the structure representing the property
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_NOTFOUND, node does not have named property
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
> +                                           const char *name, int *lenp);
> +static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
> +                                                     const char *name,
> +                                                     int *lenp)
> +{
> +       return (struct fdt_property *)(uintptr_t)
> +               fdt_get_property(fdt, nodeoffset, name, lenp);
> +}
> +
> +/**
> + * fdt_getprop_by_offset - retrieve the value of a property at a given offset
> + * @fdt: pointer to the device tree blob
> + * @ffset: offset of the property to read
> + * @namep: pointer to a string variable (will be overwritten) or NULL
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_getprop_by_offset() retrieves a pointer to the value of the
> + * property at structure block offset 'offset' (this will be a pointer
> + * to within the device blob itself, not a copy of the value).  If
> + * lenp is non-NULL, the length of the property value is also
> + * returned, in the integer pointed to by lenp.  If namep is non-NULL,
> + * the property's namne will also be returned in the char * pointed to
> + * by namep (this will be a pointer to within the device tree's string
> + * block, not a new copy of the name).
> + *
> + * returns:
> + *     pointer to the property's value
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *             if namep is non-NULL *namep contiains a pointer to the property
> + *             name.
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const void *fdt_getprop_by_offset(const void *fdt, int offset,
> +                                 const char **namep, int *lenp);
> +
> +/**
> + * fdt_getprop_namelen - get property value based on substring
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @namelen: number of characters of name to consider
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * Identical to fdt_getprop(), but only examine the first namelen
> + * characters of name for matching the property name.
> + */
> +const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> +                               const char *name, int namelen, int *lenp);
> +
> +/**
> + * fdt_getprop - retrieve the value of a given property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_getprop() retrieves a pointer to the value of the property
> + * named 'name' of the node at offset nodeoffset (this will be a
> + * pointer to within the device blob itself, not a copy of the value).
> + * If lenp is non-NULL, the length of the property value is also
> + * returned, in the integer pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the property's value
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_NOTFOUND, node does not have named property
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const void *fdt_getprop(const void *fdt, int nodeoffset,
> +                       const char *name, int *lenp);
> +static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
> +                                 const char *name, int *lenp)
> +{
> +       return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
> +}
> +
> +/**
> + * fdt_get_phandle - retrieve the phandle of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of the node
> + *
> + * fdt_get_phandle() retrieves the phandle of the device tree node at
> + * structure block offset nodeoffset.
> + *
> + * returns:
> + *     the phandle of the node at nodeoffset, on success (!= 0, != -1)
> + *     0, if the node has no phandle, or another error occurs
> + */
> +uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_get_alias_namelen - get alias based on substring
> + * @fdt: pointer to the device tree blob
> + * @name: name of the alias th look up
> + * @namelen: number of characters of name to consider
> + *
> + * Identical to fdt_get_alias(), but only examine the first namelen
> + * characters of name for matching the alias name.
> + */
> +const char *fdt_get_alias_namelen(const void *fdt,
> +                                 const char *name, int namelen);
> +
> +/**
> + * fdt_get_alias - retreive the path referenced by a given alias
> + * @fdt: pointer to the device tree blob
> + * @name: name of the alias th look up
> + *
> + * fdt_get_alias() retrieves the value of a given alias.  That is, the
> + * value of the property named 'name' in the node /aliases.
> + *
> + * returns:
> + *     a pointer to the expansion of the alias named 'name', of it exists
> + *     NULL, if the given alias or the /aliases node does not exist
> + */
> +const char *fdt_get_alias(const void *fdt, const char *name);
> +
> +/**
> + * fdt_get_path - determine the full path of a node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose path to find
> + * @buf: character buffer to contain the returned path (will be overwritten)
> + * @buflen: size of the character buffer at buf
> + *
> + * fdt_get_path() computes the full path of the node at offset
> + * nodeoffset, and records that path in the buffer at buf.
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset.
> + *
> + * returns:
> + *     0, on success
> + *             buf contains the absolute path of the node at
> + *             nodeoffset, as a NUL-terminated string.
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
> + *             characters and will not fit in the given buffer.
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
> +
> +/**
> + * fdt_supernode_atdepth_offset - find a specific ancestor of a node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose parent to find
> + * @supernodedepth: depth of the ancestor to find
> + * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_supernode_atdepth_offset() finds an ancestor of the given node
> + * at a specific depth from the root (where the root itself has depth
> + * 0, its immediate subnodes depth 1 and so forth).  So
> + *     fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
> + * will always return 0, the offset of the root node.  If the node at
> + * nodeoffset has depth D, then:
> + *     fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
> + * will return nodeoffset itself.
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset.
> + *
> + * returns:
> +
> + *     structure block offset of the node at node offset's ancestor
> + *             of depth supernodedepth (>=0), on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> +*      -FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
> +                                int supernodedepth, int *nodedepth);
> +
> +/**
> + * fdt_node_depth - find the depth of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose parent to find
> + *
> + * fdt_node_depth() finds the depth of a given node.  The root node
> + * has depth 0, its immediate subnodes depth 1 and so forth.
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset.
> + *
> + * returns:
> + *     depth of the node at nodeoffset (>=0), on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_depth(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_parent_offset - find the parent of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose parent to find
> + *
> + * fdt_parent_offset() locates the parent node of a given node (that
> + * is, it finds the offset of the node which contains the node at
> + * nodeoffset as a subnode).
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset, *twice*.
> + *
> + * returns:
> + *     structure block offset of the parent of the node at nodeoffset
> + *             (>=0), on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_parent_offset(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_node_offset_by_prop_value - find nodes with a given property value
> + * @fdt: pointer to the device tree blob
> + * @startoffset: only find nodes after this offset
> + * @propname: property name to check
> + * @propval: property value to search for
> + * @proplen: length of the value in propval
> + *
> + * fdt_node_offset_by_prop_value() returns the offset of the first
> + * node after startoffset, which has a property named propname whose
> + * value is of length proplen and has value equal to propval; or if
> + * startoffset is -1, the very first such node in the tree.
> + *
> + * To iterate through all nodes matching the criterion, the following
> + * idiom can be used:
> + *     offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
> + *                                            propval, proplen);
> + *     while (offset != -FDT_ERR_NOTFOUND) {
> + *             // other code here
> + *             offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
> + *                                                    propval, proplen);
> + *     }
> + *
> + * Note the -1 in the first call to the function, if 0 is used here
> + * instead, the function will never locate the root node, even if it
> + * matches the criterion.
> + *
> + * returns:
> + *     structure block offset of the located node (>= 0, >startoffset),
> + *              on success
> + *     -FDT_ERR_NOTFOUND, no node matching the criterion exists in the
> + *             tree after startoffset
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
> +                                 const char *propname,
> +                                 const void *propval, int proplen);
> +
> +/**
> + * fdt_node_offset_by_phandle - find the node with a given phandle
> + * @fdt: pointer to the device tree blob
> + * @phandle: phandle value
> + *
> + * fdt_node_offset_by_phandle() returns the offset of the node
> + * which has the given phandle value.  If there is more than one node
> + * in the tree with the given phandle (an invalid tree), results are
> + * undefined.
> + *
> + * returns:
> + *     structure block offset of the located node (>= 0), on success
> + *     -FDT_ERR_NOTFOUND, no node with that phandle exists
> + *     -FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
> +
> +/**
> + * fdt_node_check_compatible: check a node's compatible property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of a tree node
> + * @compatible: string to match against
> + *
> + *
> + * fdt_node_check_compatible() returns 0 if the given node contains a
> + * 'compatible' property with the given string as one of its elements,
> + * it returns non-zero otherwise, or on error.
> + *
> + * returns:
> + *     0, if the node has a 'compatible' property listing the given string
> + *     1, if the node has a 'compatible' property, but it does not list
> + *             the given string
> + *     -FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
> + *     -FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_check_compatible(const void *fdt, int nodeoffset,
> +                             const char *compatible);
> +
> +/**
> + * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
> + * @fdt: pointer to the device tree blob
> + * @startoffset: only find nodes after this offset
> + * @compatible: 'compatible' string to match against
> + *
> + * fdt_node_offset_by_compatible() returns the offset of the first
> + * node after startoffset, which has a 'compatible' property which
> + * lists the given compatible string; or if startoffset is -1, the
> + * very first such node in the tree.
> + *
> + * To iterate through all nodes matching the criterion, the following
> + * idiom can be used:
> + *     offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
> + *     while (offset != -FDT_ERR_NOTFOUND) {
> + *             // other code here
> + *             offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
> + *     }
> + *
> + * Note the -1 in the first call to the function, if 0 is used here
> + * instead, the function will never locate the root node, even if it
> + * matches the criterion.
> + *
> + * returns:
> + *     structure block offset of the located node (>= 0, >startoffset),
> + *              on success
> + *     -FDT_ERR_NOTFOUND, no node matching the criterion exists in the
> + *             tree after startoffset
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
> +                                 const char *compatible);
> +
> +/**********************************************************************/
> +/* Write-in-place functions                                           */
> +/**********************************************************************/
> +
> +/**
> + * fdt_setprop_inplace - change a property's value, but not its size
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: pointer to data to replace the property value with
> + * @len: length of the property value
> + *
> + * fdt_setprop_inplace() replaces the value of a given property with
> + * the data in val, of length len.  This function cannot change the
> + * size of a property, and so will only work if len is equal to the
> + * current length of the property.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the given property value, and will not alter or move any other part
> + * of the tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, if len is not equal to the property's current length
> + *     -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
> +                       const void *val, int len);
> +
> +/**
> + * fdt_setprop_inplace_cell - change the value of a single-cell property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: cell (32-bit integer) value to replace the property with
> + *
> + * fdt_setprop_inplace_cell() replaces the value of a given property
> + * with the 32-bit integer cell value in val, converting val to
> + * big-endian if necessary.  This function cannot change the size of a
> + * property, and so will only work if the property already exists and
> + * has length 4.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the given property value, and will not alter or move any other part
> + * of the tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, if the property's length is not equal to 4
> +  *    -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
> +                                          const char *name, uint32_t val)
> +{
> +       val = cpu_to_fdt32(val);
> +       return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
> +}
> +
> +/**
> + * fdt_nop_property - replace a property with nop tags
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to nop
> + * @name: name of the property to nop
> + *
> + * fdt_nop_property() will replace a given property's representation
> + * in the blob with FDT_NOP tags, effectively removing it from the
> + * tree.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the property, and will not alter or move any other part of the
> + * tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
> +
> +/**
> + * fdt_nop_node - replace a node (subtree) with nop tags
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node to nop
> + *
> + * fdt_nop_node() will replace a given node's representation in the
> + * blob, including all its subnodes, if any, with FDT_NOP tags,
> + * effectively removing it from the tree.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the node and its properties and subnodes, and will not alter or
> + * move any other part of the tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_nop_node(void *fdt, int nodeoffset);
> +
> +/**********************************************************************/
> +/* Sequential write functions                                         */
> +/**********************************************************************/
> +
> +int fdt_create(void *buf, int bufsize);
> +int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
> +int fdt_finish_reservemap(void *fdt);
> +int fdt_begin_node(void *fdt, const char *name);
> +int fdt_property(void *fdt, const char *name, const void *val, int len);
> +static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
> +{
> +       val = cpu_to_fdt32(val);
> +       return fdt_property(fdt, name, &val, sizeof(val));
> +}
> +#define fdt_property_string(fdt, name, str) \
> +       fdt_property(fdt, name, str, strlen(str)+1)
> +int fdt_end_node(void *fdt);
> +int fdt_finish(void *fdt);
> +
> +/**********************************************************************/
> +/* Read-write functions                                               */
> +/**********************************************************************/
> +
> +int fdt_open_into(const void *fdt, void *buf, int bufsize);
> +int fdt_pack(void *fdt);
> +
> +/**
> + * fdt_add_mem_rsv - add one memory reserve map entry
> + * @fdt: pointer to the device tree blob
> + * @address, @size: 64-bit values (native endian)
> + *
> + * Adds a reserve map entry to the given blob reserving a region at
> + * address address of length size.
> + *
> + * This function will insert data into the reserve map and will
> + * therefore change the indexes of some entries in the table.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new reservation entry
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
> +
> +/**
> + * fdt_del_mem_rsv - remove a memory reserve map entry
> + * @fdt: pointer to the device tree blob
> + * @n: entry to remove
> + *
> + * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
> + * the blob.
> + *
> + * This function will delete data from the reservation table and will
> + * therefore change the indexes of some entries in the table.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
> + *             are less than n+1 reserve map entries)
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_del_mem_rsv(void *fdt, int n);
> +
> +/**
> + * fdt_set_name - change the name of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of a node
> + * @name: name to give the node
> + *
> + * fdt_set_name() replaces the name (including unit address, if any)
> + * of the given node with the given string.  NOTE: this function can't
> + * efficiently check if the new name is unique amongst the given
> + * node's siblings; results are undefined if this function is invoked
> + * with a name equal to one of the given node's siblings.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob
> + *             to contain the new name
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings
> + */
> +int fdt_set_name(void *fdt, int nodeoffset, const char *name);
> +
> +/**
> + * fdt_setprop - create or change a property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: pointer to data to set the property value to
> + * @len: length of the property value
> + *
> + * fdt_setprop() sets the value of the named property in the given
> + * node to the given value and length, creating the property if it
> + * does not already exist.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new property value
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_setprop(void *fdt, int nodeoffset, const char *name,
> +               const void *val, int len);
> +
> +/**
> + * fdt_setprop_cell - set a property to a single cell value
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: 32-bit integer value for the property (native endian)
> + *
> + * fdt_setprop_cell() sets the value of the named property in the
> + * given node to the given cell value (converting to big-endian if
> + * necessary), or creates a new property with that value if it does
> + * not already exist.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new property value
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
> +                                  uint32_t val)
> +{
> +       val = cpu_to_fdt32(val);
> +       return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
> +}
> +
> +/**
> + * fdt_setprop_string - set a property to a string value
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @str: string value for the property
> + *
> + * fdt_setprop_string() sets the value of the named property in the
> + * given node to the given string value (using the length of the
> + * string to determine the new length of the property), or creates a
> + * new property with that value if it does not already exist.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new property value
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +#define fdt_setprop_string(fdt, nodeoffset, name, str) \
> +       fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
> +
> +/**
> + * fdt_delprop - delete a property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to nop
> + * @name: name of the property to nop
> + *
> + * fdt_del_property() will delete the given property.
> + *
> + * This function will delete data from the blob, and will therefore
> + * change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_delprop(void *fdt, int nodeoffset, const char *name);
> +
> +/**
> + * fdt_add_subnode_namelen - creates a new node based on substring
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + * @namelen: number of characters of name to consider
> + *
> + * Identical to fdt_add_subnode(), but use only the first namelen
> + * characters of name as the name of the new node.  This is useful for
> + * creating subnodes based on a portion of a larger string, such as a
> + * full path.
> + */
> +int fdt_add_subnode_namelen(void *fdt, int parentoffset,
> +                           const char *name, int namelen);
> +
> +/**
> + * fdt_add_subnode - creates a new node
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + *
> + * fdt_add_subnode() creates a new node as a subnode of the node at
> + * structure block offset parentoffset, with the given name (which
> + * should include the unit address, if any).
> + *
> + * This function will insert data into the blob, and will therefore
> + * change the offsets of some existing nodes.
> +
> + * returns:
> + *     structure block offset of the created nodeequested subnode (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the requested subnode does not exist
> + *     -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
> + *     -FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
> + *             the given name
> + *     -FDT_ERR_NOSPACE, if there is insufficient free space in the
> + *             blob to contain the new node
> + *     -FDT_ERR_NOSPACE
> + *     -FDT_ERR_BADLAYOUT
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
> +
> +/**
> + * fdt_del_node - delete a node (subtree)
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node to nop
> + *
> + * fdt_del_node() will remove the given node, including all its
> + * subnodes if any, from the blob.
> + *
> + * This function will delete data from the blob, and will therefore
> + * change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_del_node(void *fdt, int nodeoffset);
> +
> +/**********************************************************************/
> +/* Debugging / informational functions                                */
> +/**********************************************************************/
> +
> +const char *fdt_strerror(int errval);
> +
> +#endif /* _LIBFDT_H */
> diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
> new file mode 100644
> index 0000000..449bf60
> --- /dev/null
> +++ b/xen/common/libfdt/libfdt_env.h
> @@ -0,0 +1,23 @@
> +#ifndef _LIBFDT_ENV_H
> +#define _LIBFDT_ENV_H
> +
> +#include <stddef.h>
> +#include <stdint.h>
> +#include <string.h>
> +
> +#define _B(n)  ((unsigned long long)((uint8_t *)&x)[n])
> +static inline uint32_t fdt32_to_cpu(uint32_t x)
> +{
> +       return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
> +}
> +#define cpu_to_fdt32(x) fdt32_to_cpu(x)
> +
> +static inline uint64_t fdt64_to_cpu(uint64_t x)
> +{
> +       return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
> +               | (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
> +}
> +#define cpu_to_fdt64(x) fdt64_to_cpu(x)
> +#undef _B
> +
> +#endif /* _LIBFDT_ENV_H */
> diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
> new file mode 100644
> index 0000000..381133b
> --- /dev/null
> +++ b/xen/common/libfdt/libfdt_internal.h
> @@ -0,0 +1,95 @@
> +#ifndef _LIBFDT_INTERNAL_H
> +#define _LIBFDT_INTERNAL_H
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include <fdt.h>
> +
> +#define FDT_ALIGN(x, a)                (((x) + (a) - 1) & ~((a) - 1))
> +#define FDT_TAGALIGN(x)                (FDT_ALIGN((x), FDT_TAGSIZE))
> +
> +#define FDT_CHECK_HEADER(fdt) \
> +       { \
> +               int err; \
> +               if ((err = fdt_check_header(fdt)) != 0) \
> +                       return err; \
> +       }
> +
> +int _fdt_check_node_offset(const void *fdt, int offset);
> +int _fdt_check_prop_offset(const void *fdt, int offset);
> +const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
> +int _fdt_node_end_offset(void *fdt, int nodeoffset);
> +
> +static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
> +{
> +       return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
> +}
> +
> +static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
> +{
> +       return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
> +}
> +
> +static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
> +{
> +       const struct fdt_reserve_entry *rsv_table =
> +               (const struct fdt_reserve_entry *)
> +               ((const char *)fdt + fdt_off_mem_rsvmap(fdt));
> +
> +       return rsv_table + n;
> +}
> +static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
> +{
> +       return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
> +}
> +
> +#define FDT_SW_MAGIC           (~FDT_MAGIC)
> +
> +#endif /* _LIBFDT_INTERNAL_H */
> diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
> new file mode 100644
> index 0000000..3c3994e
> --- /dev/null
> +++ b/xen/common/libfdt/version.lds
> @@ -0,0 +1,54 @@
> +LIBFDT_1.2 {
> +       global:
> +               fdt_next_node;
> +               fdt_check_header;
> +               fdt_move;
> +               fdt_string;
> +               fdt_num_mem_rsv;
> +               fdt_get_mem_rsv;
> +               fdt_subnode_offset_namelen;
> +               fdt_subnode_offset;
> +               fdt_path_offset;
> +               fdt_get_name;
> +               fdt_get_property_namelen;
> +               fdt_get_property;
> +               fdt_getprop_namelen;
> +               fdt_getprop;
> +               fdt_get_phandle;
> +               fdt_get_alias_namelen;
> +               fdt_get_alias;
> +               fdt_get_path;
> +               fdt_supernode_atdepth_offset;
> +               fdt_node_depth;
> +               fdt_parent_offset;
> +               fdt_node_offset_by_prop_value;
> +               fdt_node_offset_by_phandle;
> +               fdt_node_check_compatible;
> +               fdt_node_offset_by_compatible;
> +               fdt_setprop_inplace;
> +               fdt_nop_property;
> +               fdt_nop_node;
> +               fdt_create;
> +               fdt_add_reservemap_entry;
> +               fdt_finish_reservemap;
> +               fdt_begin_node;
> +               fdt_property;
> +               fdt_end_node;
> +               fdt_finish;
> +               fdt_open_into;
> +               fdt_pack;
> +               fdt_add_mem_rsv;
> +               fdt_del_mem_rsv;
> +               fdt_set_name;
> +               fdt_setprop;
> +               fdt_delprop;
> +               fdt_add_subnode_namelen;
> +               fdt_add_subnode;
> +               fdt_del_node;
> +               fdt_strerror;
> +               fdt_offset_ptr;
> +               fdt_next_tag;
> +
> +       local:
> +               *;
> +};
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:38:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1RvqgM-0000Yw-P0; Fri, 10 Feb 2012 13:38: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 1RvqgK-0000YU-65
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:38:33 +0000
Received: from [85.158.139.83:60301] by server-2.bemta-5.messagelabs.com id
	BD/EA-20725-7DD153F4; Fri, 10 Feb 2012 13:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1328881109!14543890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25113 invoked from network); 10 Feb 2012 13:38:29 -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;
	10 Feb 2012 13:38:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:38:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 13:38:28 +0000
Message-ID: <1328881106.6133.266.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, Keir Fraser <keir@xen.org>
Date: Fri, 10 Feb 2012 13:38:26 +0000
In-Reply-To: <1328879024-5621-2-git-send-email-david.vrabel@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/8] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git
> 
> This will be used by Xen to parse the DTBs provided by bootloaders on
> ARM platforms.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Seems reasonable to me. I'd like to see an Ack from Keir before I commit
this and the following 2 xen/common/mumble patches (or have Keir take
them directly).

Ian.

> ---
>  xen/common/libfdt/Makefile.libfdt   |   10 +
>  xen/common/libfdt/TODO              |    3 +
>  xen/common/libfdt/fdt.c             |  222 +++++++
>  xen/common/libfdt/fdt.h             |   60 ++
>  xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
>  xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
>  xen/common/libfdt/fdt_strerror.c    |   96 +++
>  xen/common/libfdt/fdt_sw.c          |  256 ++++++++
>  xen/common/libfdt/fdt_wip.c         |  118 ++++
>  xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
>  xen/common/libfdt/libfdt_env.h      |   23 +
>  xen/common/libfdt/libfdt_internal.h |   95 +++
>  xen/common/libfdt/version.lds       |   54 ++
>  13 files changed, 3211 insertions(+), 0 deletions(-)
>  create mode 100644 xen/common/libfdt/Makefile.libfdt
>  create mode 100644 xen/common/libfdt/TODO
>  create mode 100644 xen/common/libfdt/fdt.c
>  create mode 100644 xen/common/libfdt/fdt.h
>  create mode 100644 xen/common/libfdt/fdt_ro.c
>  create mode 100644 xen/common/libfdt/fdt_rw.c
>  create mode 100644 xen/common/libfdt/fdt_strerror.c
>  create mode 100644 xen/common/libfdt/fdt_sw.c
>  create mode 100644 xen/common/libfdt/fdt_wip.c
>  create mode 100644 xen/common/libfdt/libfdt.h
>  create mode 100644 xen/common/libfdt/libfdt_env.h
>  create mode 100644 xen/common/libfdt/libfdt_internal.h
>  create mode 100644 xen/common/libfdt/version.lds
> 
> diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
> new file mode 100644
> index 0000000..d55a6f8
> --- /dev/null
> +++ b/xen/common/libfdt/Makefile.libfdt
> @@ -0,0 +1,10 @@
> +# Makefile.libfdt
> +#
> +# This is not a complete Makefile of itself.  Instead, it is designed to
> +# be easily embeddable into other systems of Makefiles.
> +#
> +LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
> +LIBFDT_INCLUDES = fdt.h libfdt.h
> +LIBFDT_VERSION = version.lds
> +LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
> +LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
> diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
> new file mode 100644
> index 0000000..288437e
> --- /dev/null
> +++ b/xen/common/libfdt/TODO
> @@ -0,0 +1,3 @@
> +- Tree traversal functions
> +- Graft function
> +- Complete libfdt.h documenting comments
> diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
> new file mode 100644
> index 0000000..e56833a
> --- /dev/null
> +++ b/xen/common/libfdt/fdt.c
> @@ -0,0 +1,222 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +int fdt_check_header(const void *fdt)
> +{
> +       if (fdt_magic(fdt) == FDT_MAGIC) {
> +               /* Complete tree */
> +               if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
> +                       return -FDT_ERR_BADVERSION;
> +               if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
> +                       return -FDT_ERR_BADVERSION;
> +       } else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
> +               /* Unfinished sequential-write blob */
> +               if (fdt_size_dt_struct(fdt) == 0)
> +                       return -FDT_ERR_BADSTATE;
> +       } else {
> +               return -FDT_ERR_BADMAGIC;
> +       }
> +
> +       return 0;
> +}
> +
> +const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
> +{
> +       const char *p;
> +
> +       if (fdt_version(fdt) >= 0x11)
> +               if (((offset + len) < offset)
> +                   || ((offset + len) > fdt_size_dt_struct(fdt)))
> +                       return NULL;
> +
> +       p = _fdt_offset_ptr(fdt, offset);
> +
> +       if (p + len < p)
> +               return NULL;
> +       return p;
> +}
> +
> +uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
> +{
> +       const uint32_t *tagp, *lenp;
> +       uint32_t tag;
> +       int offset = startoffset;
> +       const char *p;
> +
> +       *nextoffset = -FDT_ERR_TRUNCATED;
> +       tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
> +       if (!tagp)
> +               return FDT_END; /* premature end */
> +       tag = fdt32_to_cpu(*tagp);
> +       offset += FDT_TAGSIZE;
> +
> +       *nextoffset = -FDT_ERR_BADSTRUCTURE;
> +       switch (tag) {
> +       case FDT_BEGIN_NODE:
> +               /* skip name */
> +               do {
> +                       p = fdt_offset_ptr(fdt, offset++, 1);
> +               } while (p && (*p != '\0'));
> +               if (!p)
> +                       return FDT_END; /* premature end */
> +               break;
> +
> +       case FDT_PROP:
> +               lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
> +               if (!lenp)
> +                       return FDT_END; /* premature end */
> +               /* skip-name offset, length and value */
> +               offset += sizeof(struct fdt_property) - FDT_TAGSIZE
> +                       + fdt32_to_cpu(*lenp);
> +               break;
> +
> +       case FDT_END:
> +       case FDT_END_NODE:
> +       case FDT_NOP:
> +               break;
> +
> +       default:
> +               return FDT_END;
> +       }
> +
> +       if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
> +               return FDT_END; /* premature end */
> +
> +       *nextoffset = FDT_TAGALIGN(offset);
> +       return tag;
> +}
> +
> +int _fdt_check_node_offset(const void *fdt, int offset)
> +{
> +       if ((offset < 0) || (offset % FDT_TAGSIZE)
> +           || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
> +               return -FDT_ERR_BADOFFSET;
> +
> +       return offset;
> +}
> +
> +int _fdt_check_prop_offset(const void *fdt, int offset)
> +{
> +       if ((offset < 0) || (offset % FDT_TAGSIZE)
> +           || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
> +               return -FDT_ERR_BADOFFSET;
> +
> +       return offset;
> +}
> +
> +int fdt_next_node(const void *fdt, int offset, int *depth)
> +{
> +       int nextoffset = 0;
> +       uint32_t tag;
> +
> +       if (offset >= 0)
> +               if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
> +                       return nextoffset;
> +
> +       do {
> +               offset = nextoffset;
> +               tag = fdt_next_tag(fdt, offset, &nextoffset);
> +
> +               switch (tag) {
> +               case FDT_PROP:
> +               case FDT_NOP:
> +                       break;
> +
> +               case FDT_BEGIN_NODE:
> +                       if (depth)
> +                               (*depth)++;
> +                       break;
> +
> +               case FDT_END_NODE:
> +                       if (depth && ((--(*depth)) < 0))
> +                               return nextoffset;
> +                       break;
> +
> +               case FDT_END:
> +                       if ((nextoffset >= 0)
> +                           || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
> +                               return -FDT_ERR_NOTFOUND;
> +                       else
> +                               return nextoffset;
> +               }
> +       } while (tag != FDT_BEGIN_NODE);
> +
> +       return offset;
> +}
> +
> +const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
> +{
> +       int len = strlen(s) + 1;
> +       const char *last = strtab + tabsize - len;
> +       const char *p;
> +
> +       for (p = strtab; p <= last; p++)
> +               if (memcmp(p, s, len) == 0)
> +                       return p;
> +       return NULL;
> +}
> +
> +int fdt_move(const void *fdt, void *buf, int bufsize)
> +{
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (fdt_totalsize(fdt) > bufsize)
> +               return -FDT_ERR_NOSPACE;
> +
> +       memmove(buf, fdt, fdt_totalsize(fdt));
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
> new file mode 100644
> index 0000000..48ccfd9
> --- /dev/null
> +++ b/xen/common/libfdt/fdt.h
> @@ -0,0 +1,60 @@
> +#ifndef _FDT_H
> +#define _FDT_H
> +
> +#ifndef __ASSEMBLY__
> +
> +struct fdt_header {
> +       uint32_t magic;                  /* magic word FDT_MAGIC */
> +       uint32_t totalsize;              /* total size of DT block */
> +       uint32_t off_dt_struct;          /* offset to structure */
> +       uint32_t off_dt_strings;         /* offset to strings */
> +       uint32_t off_mem_rsvmap;         /* offset to memory reserve map */
> +       uint32_t version;                /* format version */
> +       uint32_t last_comp_version;      /* last compatible version */
> +
> +       /* version 2 fields below */
> +       uint32_t boot_cpuid_phys;        /* Which physical CPU id we're
> +                                           booting on */
> +       /* version 3 fields below */
> +       uint32_t size_dt_strings;        /* size of the strings block */
> +
> +       /* version 17 fields below */
> +       uint32_t size_dt_struct;         /* size of the structure block */
> +};
> +
> +struct fdt_reserve_entry {
> +       uint64_t address;
> +       uint64_t size;
> +};
> +
> +struct fdt_node_header {
> +       uint32_t tag;
> +       char name[0];
> +};
> +
> +struct fdt_property {
> +       uint32_t tag;
> +       uint32_t len;
> +       uint32_t nameoff;
> +       char data[0];
> +};
> +
> +#endif /* !__ASSEMBLY */
> +
> +#define FDT_MAGIC      0xd00dfeed      /* 4: version, 4: total size */
> +#define FDT_TAGSIZE    sizeof(uint32_t)
> +
> +#define FDT_BEGIN_NODE 0x1             /* Start node: full name */
> +#define FDT_END_NODE   0x2             /* End node */
> +#define FDT_PROP       0x3             /* Property: name off,
> +                                          size, content */
> +#define FDT_NOP                0x4             /* nop */
> +#define FDT_END                0x9
> +
> +#define FDT_V1_SIZE    (7*sizeof(uint32_t))
> +#define FDT_V2_SIZE    (FDT_V1_SIZE + sizeof(uint32_t))
> +#define FDT_V3_SIZE    (FDT_V2_SIZE + sizeof(uint32_t))
> +#define FDT_V16_SIZE   FDT_V3_SIZE
> +#define FDT_V17_SIZE   (FDT_V16_SIZE + sizeof(uint32_t))
> +
> +#endif /* _FDT_H */
> diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
> new file mode 100644
> index 0000000..02b6d68
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_ro.c
> @@ -0,0 +1,574 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +static int _fdt_nodename_eq(const void *fdt, int offset,
> +                           const char *s, int len)
> +{
> +       const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
> +
> +       if (! p)
> +               /* short match */
> +               return 0;
> +
> +       if (memcmp(p, s, len) != 0)
> +               return 0;
> +
> +       if (p[len] == '\0')
> +               return 1;
> +       else if (!memchr(s, '@', len) && (p[len] == '@'))
> +               return 1;
> +       else
> +               return 0;
> +}
> +
> +const char *fdt_string(const void *fdt, int stroffset)
> +{
> +       return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
> +}
> +
> +static int _fdt_string_eq(const void *fdt, int stroffset,
> +                         const char *s, int len)
> +{
> +       const char *p = fdt_string(fdt, stroffset);
> +
> +       return (strlen(p) == len) && (memcmp(p, s, len) == 0);
> +}
> +
> +int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
> +{
> +       FDT_CHECK_HEADER(fdt);
> +       *address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
> +       *size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
> +       return 0;
> +}
> +
> +int fdt_num_mem_rsv(const void *fdt)
> +{
> +       int i = 0;
> +
> +       while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
> +               i++;
> +       return i;
> +}
> +
> +static int _nextprop(const void *fdt, int offset)
> +{
> +       uint32_t tag;
> +       int nextoffset;
> +
> +       do {
> +               tag = fdt_next_tag(fdt, offset, &nextoffset);
> +
> +               switch (tag) {
> +               case FDT_END:
> +                       if (nextoffset >= 0)
> +                               return -FDT_ERR_BADSTRUCTURE;
> +                       else
> +                               return nextoffset;
> +
> +               case FDT_PROP:
> +                       return offset;
> +               }
> +               offset = nextoffset;
> +       } while (tag == FDT_NOP);
> +
> +       return -FDT_ERR_NOTFOUND;
> +}
> +
> +int fdt_subnode_offset_namelen(const void *fdt, int offset,
> +                              const char *name, int namelen)
> +{
> +       int depth;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       for (depth = 0;
> +            (offset >= 0) && (depth >= 0);
> +            offset = fdt_next_node(fdt, offset, &depth))
> +               if ((depth == 1)
> +                   && _fdt_nodename_eq(fdt, offset, name, namelen))
> +                       return offset;
> +
> +       if (depth < 0)
> +               return -FDT_ERR_NOTFOUND;
> +       return offset; /* error */
> +}
> +
> +int fdt_subnode_offset(const void *fdt, int parentoffset,
> +                      const char *name)
> +{
> +       return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
> +}
> +
> +int fdt_path_offset(const void *fdt, const char *path)
> +{
> +       const char *end = path + strlen(path);
> +       const char *p = path;
> +       int offset = 0;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* see if we have an alias */
> +       if (*path != '/') {
> +               const char *q = strchr(path, '/');
> +
> +               if (!q)
> +                       q = end;
> +
> +               p = fdt_get_alias_namelen(fdt, p, q - p);
> +               if (!p)
> +                       return -FDT_ERR_BADPATH;
> +               offset = fdt_path_offset(fdt, p);
> +
> +               p = q;
> +       }
> +
> +       while (*p) {
> +               const char *q;
> +
> +               while (*p == '/')
> +                       p++;
> +               if (! *p)
> +                       return offset;
> +               q = strchr(p, '/');
> +               if (! q)
> +                       q = end;
> +
> +               offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
> +               if (offset < 0)
> +                       return offset;
> +
> +               p = q;
> +       }
> +
> +       return offset;
> +}
> +
> +const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
> +{
> +       const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
> +       int err;
> +
> +       if (((err = fdt_check_header(fdt)) != 0)
> +           || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
> +                       goto fail;
> +
> +       if (len)
> +               *len = strlen(nh->name);
> +
> +       return nh->name;
> +
> + fail:
> +       if (len)
> +               *len = err;
> +       return NULL;
> +}
> +
> +int fdt_first_property_offset(const void *fdt, int nodeoffset)
> +{
> +       int offset;
> +
> +       if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
> +               return offset;
> +
> +       return _nextprop(fdt, offset);
> +}
> +
> +int fdt_next_property_offset(const void *fdt, int offset)
> +{
> +       if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
> +               return offset;
> +
> +       return _nextprop(fdt, offset);
> +}
> +
> +const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
> +                                                     int offset,
> +                                                     int *lenp)
> +{
> +       int err;
> +       const struct fdt_property *prop;
> +
> +       if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
> +               if (lenp)
> +                       *lenp = err;
> +               return NULL;
> +       }
> +
> +       prop = _fdt_offset_ptr(fdt, offset);
> +
> +       if (lenp)
> +               *lenp = fdt32_to_cpu(prop->len);
> +
> +       return prop;
> +}
> +
> +const struct fdt_property *fdt_get_property_namelen(const void *fdt,
> +                                                   int offset,
> +                                                   const char *name,
> +                                                   int namelen, int *lenp)
> +{
> +       for (offset = fdt_first_property_offset(fdt, offset);
> +            (offset >= 0);
> +            (offset = fdt_next_property_offset(fdt, offset))) {
> +               const struct fdt_property *prop;
> +
> +               if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
> +                       offset = -FDT_ERR_INTERNAL;
> +                       break;
> +               }
> +               if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
> +                                  name, namelen))
> +                       return prop;
> +       }
> +
> +       if (lenp)
> +               *lenp = offset;
> +       return NULL;
> +}
> +
> +const struct fdt_property *fdt_get_property(const void *fdt,
> +                                           int nodeoffset,
> +                                           const char *name, int *lenp)
> +{
> +       return fdt_get_property_namelen(fdt, nodeoffset, name,
> +                                       strlen(name), lenp);
> +}
> +
> +const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> +                               const char *name, int namelen, int *lenp)
> +{
> +       const struct fdt_property *prop;
> +
> +       prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
> +       if (! prop)
> +               return NULL;
> +
> +       return prop->data;
> +}
> +
> +const void *fdt_getprop_by_offset(const void *fdt, int offset,
> +                                 const char **namep, int *lenp)
> +{
> +       const struct fdt_property *prop;
> +
> +       prop = fdt_get_property_by_offset(fdt, offset, lenp);
> +       if (!prop)
> +               return NULL;
> +       if (namep)
> +               *namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
> +       return prop->data;
> +}
> +
> +const void *fdt_getprop(const void *fdt, int nodeoffset,
> +                       const char *name, int *lenp)
> +{
> +       return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
> +}
> +
> +uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
> +{
> +       const uint32_t *php;
> +       int len;
> +
> +       /* FIXME: This is a bit sub-optimal, since we potentially scan
> +        * over all the properties twice. */
> +       php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
> +       if (!php || (len != sizeof(*php))) {
> +               php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
> +               if (!php || (len != sizeof(*php)))
> +                       return 0;
> +       }
> +
> +       return fdt32_to_cpu(*php);
> +}
> +
> +const char *fdt_get_alias_namelen(const void *fdt,
> +                                 const char *name, int namelen)
> +{
> +       int aliasoffset;
> +
> +       aliasoffset = fdt_path_offset(fdt, "/aliases");
> +       if (aliasoffset < 0)
> +               return NULL;
> +
> +       return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
> +}
> +
> +const char *fdt_get_alias(const void *fdt, const char *name)
> +{
> +       return fdt_get_alias_namelen(fdt, name, strlen(name));
> +}
> +
> +int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
> +{
> +       int pdepth = 0, p = 0;
> +       int offset, depth, namelen;
> +       const char *name;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (buflen < 2)
> +               return -FDT_ERR_NOSPACE;
> +
> +       for (offset = 0, depth = 0;
> +            (offset >= 0) && (offset <= nodeoffset);
> +            offset = fdt_next_node(fdt, offset, &depth)) {
> +               while (pdepth > depth) {
> +                       do {
> +                               p--;
> +                       } while (buf[p-1] != '/');
> +                       pdepth--;
> +               }
> +
> +               if (pdepth >= depth) {
> +                       name = fdt_get_name(fdt, offset, &namelen);
> +                       if (!name)
> +                               return namelen;
> +                       if ((p + namelen + 1) <= buflen) {
> +                               memcpy(buf + p, name, namelen);
> +                               p += namelen;
> +                               buf[p++] = '/';
> +                               pdepth++;
> +                       }
> +               }
> +
> +               if (offset == nodeoffset) {
> +                       if (pdepth < (depth + 1))
> +                               return -FDT_ERR_NOSPACE;
> +
> +                       if (p > 1) /* special case so that root path is "/", not "" */
> +                               p--;
> +                       buf[p] = '\0';
> +                       return 0;
> +               }
> +       }
> +
> +       if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
> +               return -FDT_ERR_BADOFFSET;
> +       else if (offset == -FDT_ERR_BADOFFSET)
> +               return -FDT_ERR_BADSTRUCTURE;
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
> +                                int supernodedepth, int *nodedepth)
> +{
> +       int offset, depth;
> +       int supernodeoffset = -FDT_ERR_INTERNAL;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (supernodedepth < 0)
> +               return -FDT_ERR_NOTFOUND;
> +
> +       for (offset = 0, depth = 0;
> +            (offset >= 0) && (offset <= nodeoffset);
> +            offset = fdt_next_node(fdt, offset, &depth)) {
> +               if (depth == supernodedepth)
> +                       supernodeoffset = offset;
> +
> +               if (offset == nodeoffset) {
> +                       if (nodedepth)
> +                               *nodedepth = depth;
> +
> +                       if (supernodedepth > depth)
> +                               return -FDT_ERR_NOTFOUND;
> +                       else
> +                               return supernodeoffset;
> +               }
> +       }
> +
> +       if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
> +               return -FDT_ERR_BADOFFSET;
> +       else if (offset == -FDT_ERR_BADOFFSET)
> +               return -FDT_ERR_BADSTRUCTURE;
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +int fdt_node_depth(const void *fdt, int nodeoffset)
> +{
> +       int nodedepth;
> +       int err;
> +
> +       err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
> +       if (err)
> +               return (err < 0) ? err : -FDT_ERR_INTERNAL;
> +       return nodedepth;
> +}
> +
> +int fdt_parent_offset(const void *fdt, int nodeoffset)
> +{
> +       int nodedepth = fdt_node_depth(fdt, nodeoffset);
> +
> +       if (nodedepth < 0)
> +               return nodedepth;
> +       return fdt_supernode_atdepth_offset(fdt, nodeoffset,
> +                                           nodedepth - 1, NULL);
> +}
> +
> +int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
> +                                 const char *propname,
> +                                 const void *propval, int proplen)
> +{
> +       int offset;
> +       const void *val;
> +       int len;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* FIXME: The algorithm here is pretty horrible: we scan each
> +        * property of a node in fdt_getprop(), then if that didn't
> +        * find what we want, we scan over them again making our way
> +        * to the next node.  Still it's the easiest to implement
> +        * approach; performance can come later. */
> +       for (offset = fdt_next_node(fdt, startoffset, NULL);
> +            offset >= 0;
> +            offset = fdt_next_node(fdt, offset, NULL)) {
> +               val = fdt_getprop(fdt, offset, propname, &len);
> +               if (val && (len == proplen)
> +                   && (memcmp(val, propval, len) == 0))
> +                       return offset;
> +       }
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
> +{
> +       int offset;
> +
> +       if ((phandle == 0) || (phandle == -1))
> +               return -FDT_ERR_BADPHANDLE;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* FIXME: The algorithm here is pretty horrible: we
> +        * potentially scan each property of a node in
> +        * fdt_get_phandle(), then if that didn't find what
> +        * we want, we scan over them again making our way to the next
> +        * node.  Still it's the easiest to implement approach;
> +        * performance can come later. */
> +       for (offset = fdt_next_node(fdt, -1, NULL);
> +            offset >= 0;
> +            offset = fdt_next_node(fdt, offset, NULL)) {
> +               if (fdt_get_phandle(fdt, offset) == phandle)
> +                       return offset;
> +       }
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> +
> +static int _fdt_stringlist_contains(const char *strlist, int listlen,
> +                                   const char *str)
> +{
> +       int len = strlen(str);
> +       const char *p;
> +
> +       while (listlen >= len) {
> +               if (memcmp(str, strlist, len+1) == 0)
> +                       return 1;
> +               p = memchr(strlist, '\0', listlen);
> +               if (!p)
> +                       return 0; /* malformed strlist.. */
> +               listlen -= (p-strlist) + 1;
> +               strlist = p + 1;
> +       }
> +       return 0;
> +}
> +
> +int fdt_node_check_compatible(const void *fdt, int nodeoffset,
> +                             const char *compatible)
> +{
> +       const void *prop;
> +       int len;
> +
> +       prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
> +       if (!prop)
> +               return len;
> +       if (_fdt_stringlist_contains(prop, len, compatible))
> +               return 0;
> +       else
> +               return 1;
> +}
> +
> +int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
> +                                 const char *compatible)
> +{
> +       int offset, err;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       /* FIXME: The algorithm here is pretty horrible: we scan each
> +        * property of a node in fdt_node_check_compatible(), then if
> +        * that didn't find what we want, we scan over them again
> +        * making our way to the next node.  Still it's the easiest to
> +        * implement approach; performance can come later. */
> +       for (offset = fdt_next_node(fdt, startoffset, NULL);
> +            offset >= 0;
> +            offset = fdt_next_node(fdt, offset, NULL)) {
> +               err = fdt_node_check_compatible(fdt, offset, compatible);
> +               if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
> +                       return err;
> +               else if (err == 0)
> +                       return offset;
> +       }
> +
> +       return offset; /* error from fdt_next_node() */
> +}
> diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
> new file mode 100644
> index 0000000..994037b
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_rw.c
> @@ -0,0 +1,465 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +static int _fdt_blocks_misordered(const void *fdt,
> +                             int mem_rsv_size, int struct_size)
> +{
> +       return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
> +               || (fdt_off_dt_struct(fdt) <
> +                   (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
> +               || (fdt_off_dt_strings(fdt) <
> +                   (fdt_off_dt_struct(fdt) + struct_size))
> +               || (fdt_totalsize(fdt) <
> +                   (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
> +}
> +
> +static int _fdt_rw_check_header(void *fdt)
> +{
> +       FDT_CHECK_HEADER(fdt);
> +
> +       if (fdt_version(fdt) < 17)
> +               return -FDT_ERR_BADVERSION;
> +       if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
> +                                  fdt_size_dt_struct(fdt)))
> +               return -FDT_ERR_BADLAYOUT;
> +       if (fdt_version(fdt) > 17)
> +               fdt_set_version(fdt, 17);
> +
> +       return 0;
> +}
> +
> +#define FDT_RW_CHECK_HEADER(fdt) \
> +       { \
> +               int err; \
> +               if ((err = _fdt_rw_check_header(fdt)) != 0) \
> +                       return err; \
> +       }
> +
> +static inline int _fdt_data_size(void *fdt)
> +{
> +       return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
> +}
> +
> +static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
> +{
> +       char *p = splicepoint;
> +       char *end = (char *)fdt + _fdt_data_size(fdt);
> +
> +       if (((p + oldlen) < p) || ((p + oldlen) > end))
> +               return -FDT_ERR_BADOFFSET;
> +       if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
> +               return -FDT_ERR_NOSPACE;
> +       memmove(p + newlen, p + oldlen, end - p - oldlen);
> +       return 0;
> +}
> +
> +static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
> +                              int oldn, int newn)
> +{
> +       int delta = (newn - oldn) * sizeof(*p);
> +       int err;
> +       err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
> +       if (err)
> +               return err;
> +       fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
> +       fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
> +       return 0;
> +}
> +
> +static int _fdt_splice_struct(void *fdt, void *p,
> +                             int oldlen, int newlen)
> +{
> +       int delta = newlen - oldlen;
> +       int err;
> +
> +       if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
> +               return err;
> +
> +       fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
> +       fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
> +       return 0;
> +}
> +
> +static int _fdt_splice_string(void *fdt, int newlen)
> +{
> +       void *p = (char *)fdt
> +               + fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
> +       int err;
> +
> +       if ((err = _fdt_splice(fdt, p, 0, newlen)))
> +               return err;
> +
> +       fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
> +       return 0;
> +}
> +
> +static int _fdt_find_add_string(void *fdt, const char *s)
> +{
> +       char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
> +       const char *p;
> +       char *new;
> +       int len = strlen(s) + 1;
> +       int err;
> +
> +       p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
> +       if (p)
> +               /* found it */
> +               return (p - strtab);
> +
> +       new = strtab + fdt_size_dt_strings(fdt);
> +       err = _fdt_splice_string(fdt, len);
> +       if (err)
> +               return err;
> +
> +       memcpy(new, s, len);
> +       return (new - strtab);
> +}
> +
> +int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
> +{
> +       struct fdt_reserve_entry *re;
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
> +       err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
> +       if (err)
> +               return err;
> +
> +       re->address = cpu_to_fdt64(address);
> +       re->size = cpu_to_fdt64(size);
> +       return 0;
> +}
> +
> +int fdt_del_mem_rsv(void *fdt, int n)
> +{
> +       struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       if (n >= fdt_num_mem_rsv(fdt))
> +               return -FDT_ERR_NOTFOUND;
> +
> +       err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
> +       if (err)
> +               return err;
> +       return 0;
> +}
> +
> +static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
> +                               int len, struct fdt_property **prop)
> +{
> +       int oldlen;
> +       int err;
> +
> +       *prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
> +       if (! (*prop))
> +               return oldlen;
> +
> +       if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
> +                                     FDT_TAGALIGN(len))))
> +               return err;
> +
> +       (*prop)->len = cpu_to_fdt32(len);
> +       return 0;
> +}
> +
> +static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
> +                            int len, struct fdt_property **prop)
> +{
> +       int proplen;
> +       int nextoffset;
> +       int namestroff;
> +       int err;
> +
> +       if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
> +               return nextoffset;
> +
> +       namestroff = _fdt_find_add_string(fdt, name);
> +       if (namestroff < 0)
> +               return namestroff;
> +
> +       *prop = _fdt_offset_ptr_w(fdt, nextoffset);
> +       proplen = sizeof(**prop) + FDT_TAGALIGN(len);
> +
> +       err = _fdt_splice_struct(fdt, *prop, 0, proplen);
> +       if (err)
> +               return err;
> +
> +       (*prop)->tag = cpu_to_fdt32(FDT_PROP);
> +       (*prop)->nameoff = cpu_to_fdt32(namestroff);
> +       (*prop)->len = cpu_to_fdt32(len);
> +       return 0;
> +}
> +
> +int fdt_set_name(void *fdt, int nodeoffset, const char *name)
> +{
> +       char *namep;
> +       int oldlen, newlen;
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
> +       if (!namep)
> +               return oldlen;
> +
> +       newlen = strlen(name);
> +
> +       err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
> +                                FDT_TAGALIGN(newlen+1));
> +       if (err)
> +               return err;
> +
> +       memcpy(namep, name, newlen+1);
> +       return 0;
> +}
> +
> +int fdt_setprop(void *fdt, int nodeoffset, const char *name,
> +               const void *val, int len)
> +{
> +       struct fdt_property *prop;
> +       int err;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
> +       if (err == -FDT_ERR_NOTFOUND)
> +               err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
> +       if (err)
> +               return err;
> +
> +       memcpy(prop->data, val, len);
> +       return 0;
> +}
> +
> +int fdt_delprop(void *fdt, int nodeoffset, const char *name)
> +{
> +       struct fdt_property *prop;
> +       int len, proplen;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
> +       if (! prop)
> +               return len;
> +
> +       proplen = sizeof(*prop) + FDT_TAGALIGN(len);
> +       return _fdt_splice_struct(fdt, prop, proplen, 0);
> +}
> +
> +int fdt_add_subnode_namelen(void *fdt, int parentoffset,
> +                           const char *name, int namelen)
> +{
> +       struct fdt_node_header *nh;
> +       int offset, nextoffset;
> +       int nodelen;
> +       int err;
> +       uint32_t tag;
> +       uint32_t *endtag;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
> +       if (offset >= 0)
> +               return -FDT_ERR_EXISTS;
> +       else if (offset != -FDT_ERR_NOTFOUND)
> +               return offset;
> +
> +       /* Try to place the new node after the parent's properties */
> +       fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
> +       do {
> +               offset = nextoffset;
> +               tag = fdt_next_tag(fdt, offset, &nextoffset);
> +       } while ((tag == FDT_PROP) || (tag == FDT_NOP));
> +
> +       nh = _fdt_offset_ptr_w(fdt, offset);
> +       nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
> +
> +       err = _fdt_splice_struct(fdt, nh, 0, nodelen);
> +       if (err)
> +               return err;
> +
> +       nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
> +       memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
> +       memcpy(nh->name, name, namelen);
> +       endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
> +       *endtag = cpu_to_fdt32(FDT_END_NODE);
> +
> +       return offset;
> +}
> +
> +int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
> +{
> +       return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
> +}
> +
> +int fdt_del_node(void *fdt, int nodeoffset)
> +{
> +       int endoffset;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       endoffset = _fdt_node_end_offset(fdt, nodeoffset);
> +       if (endoffset < 0)
> +               return endoffset;
> +
> +       return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
> +                                 endoffset - nodeoffset, 0);
> +}
> +
> +static void _fdt_packblocks(const char *old, char *new,
> +                           int mem_rsv_size, int struct_size)
> +{
> +       int mem_rsv_off, struct_off, strings_off;
> +
> +       mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
> +       struct_off = mem_rsv_off + mem_rsv_size;
> +       strings_off = struct_off + struct_size;
> +
> +       memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
> +       fdt_set_off_mem_rsvmap(new, mem_rsv_off);
> +
> +       memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
> +       fdt_set_off_dt_struct(new, struct_off);
> +       fdt_set_size_dt_struct(new, struct_size);
> +
> +       memmove(new + strings_off, old + fdt_off_dt_strings(old),
> +               fdt_size_dt_strings(old));
> +       fdt_set_off_dt_strings(new, strings_off);
> +       fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
> +}
> +
> +int fdt_open_into(const void *fdt, void *buf, int bufsize)
> +{
> +       int err;
> +       int mem_rsv_size, struct_size;
> +       int newsize;
> +       const char *fdtstart = fdt;
> +       const char *fdtend = fdtstart + fdt_totalsize(fdt);
> +       char *tmp;
> +
> +       FDT_CHECK_HEADER(fdt);
> +
> +       mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
> +               * sizeof(struct fdt_reserve_entry);
> +
> +       if (fdt_version(fdt) >= 17) {
> +               struct_size = fdt_size_dt_struct(fdt);
> +       } else {
> +               struct_size = 0;
> +               while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
> +                       ;
> +               if (struct_size < 0)
> +                       return struct_size;
> +       }
> +
> +       if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
> +               /* no further work necessary */
> +               err = fdt_move(fdt, buf, bufsize);
> +               if (err)
> +                       return err;
> +               fdt_set_version(buf, 17);
> +               fdt_set_size_dt_struct(buf, struct_size);
> +               fdt_set_totalsize(buf, bufsize);
> +               return 0;
> +       }
> +
> +       /* Need to reorder */
> +       newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
> +               + struct_size + fdt_size_dt_strings(fdt);
> +
> +       if (bufsize < newsize)
> +               return -FDT_ERR_NOSPACE;
> +
> +       /* First attempt to build converted tree at beginning of buffer */
> +       tmp = buf;
> +       /* But if that overlaps with the old tree... */
> +       if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
> +               /* Try right after the old tree instead */
> +               tmp = (char *)(uintptr_t)fdtend;
> +               if ((tmp + newsize) > ((char *)buf + bufsize))
> +                       return -FDT_ERR_NOSPACE;
> +       }
> +
> +       _fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
> +       memmove(buf, tmp, newsize);
> +
> +       fdt_set_magic(buf, FDT_MAGIC);
> +       fdt_set_totalsize(buf, bufsize);
> +       fdt_set_version(buf, 17);
> +       fdt_set_last_comp_version(buf, 16);
> +       fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
> +
> +       return 0;
> +}
> +
> +int fdt_pack(void *fdt)
> +{
> +       int mem_rsv_size;
> +
> +       FDT_RW_CHECK_HEADER(fdt);
> +
> +       mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
> +               * sizeof(struct fdt_reserve_entry);
> +       _fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
> +       fdt_set_totalsize(fdt, _fdt_data_size(fdt));
> +
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
> new file mode 100644
> index 0000000..e6c3cee
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_strerror.c
> @@ -0,0 +1,96 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +struct fdt_errtabent {
> +       const char *str;
> +};
> +
> +#define FDT_ERRTABENT(val) \
> +       [(val)] = { .str = #val, }
> +
> +static struct fdt_errtabent fdt_errtable[] = {
> +       FDT_ERRTABENT(FDT_ERR_NOTFOUND),
> +       FDT_ERRTABENT(FDT_ERR_EXISTS),
> +       FDT_ERRTABENT(FDT_ERR_NOSPACE),
> +
> +       FDT_ERRTABENT(FDT_ERR_BADOFFSET),
> +       FDT_ERRTABENT(FDT_ERR_BADPATH),
> +       FDT_ERRTABENT(FDT_ERR_BADSTATE),
> +
> +       FDT_ERRTABENT(FDT_ERR_TRUNCATED),
> +       FDT_ERRTABENT(FDT_ERR_BADMAGIC),
> +       FDT_ERRTABENT(FDT_ERR_BADVERSION),
> +       FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
> +       FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
> +};
> +#define FDT_ERRTABSIZE (sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
> +
> +const char *fdt_strerror(int errval)
> +{
> +       if (errval > 0)
> +               return "<valid offset/length>";
> +       else if (errval == 0)
> +               return "<no error>";
> +       else if (errval > -FDT_ERRTABSIZE) {
> +               const char *s = fdt_errtable[-errval].str;
> +
> +               if (s)
> +                       return s;
> +       }
> +
> +       return "<unknown error>";
> +}
> diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
> new file mode 100644
> index 0000000..55ebebf
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_sw.c
> @@ -0,0 +1,256 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +static int _fdt_sw_check_header(void *fdt)
> +{
> +       if (fdt_magic(fdt) != FDT_SW_MAGIC)
> +               return -FDT_ERR_BADMAGIC;
> +       /* FIXME: should check more details about the header state */
> +       return 0;
> +}
> +
> +#define FDT_SW_CHECK_HEADER(fdt) \
> +       { \
> +               int err; \
> +               if ((err = _fdt_sw_check_header(fdt)) != 0) \
> +                       return err; \
> +       }
> +
> +static void *_fdt_grab_space(void *fdt, size_t len)
> +{
> +       int offset = fdt_size_dt_struct(fdt);
> +       int spaceleft;
> +
> +       spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
> +               - fdt_size_dt_strings(fdt);
> +
> +       if ((offset + len < offset) || (offset + len > spaceleft))
> +               return NULL;
> +
> +       fdt_set_size_dt_struct(fdt, offset + len);
> +       return _fdt_offset_ptr_w(fdt, offset);
> +}
> +
> +int fdt_create(void *buf, int bufsize)
> +{
> +       void *fdt = buf;
> +
> +       if (bufsize < sizeof(struct fdt_header))
> +               return -FDT_ERR_NOSPACE;
> +
> +       memset(buf, 0, bufsize);
> +
> +       fdt_set_magic(fdt, FDT_SW_MAGIC);
> +       fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
> +       fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
> +       fdt_set_totalsize(fdt,  bufsize);
> +
> +       fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
> +                                             sizeof(struct fdt_reserve_entry)));
> +       fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
> +       fdt_set_off_dt_strings(fdt, bufsize);
> +
> +       return 0;
> +}
> +
> +int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
> +{
> +       struct fdt_reserve_entry *re;
> +       int offset;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       if (fdt_size_dt_struct(fdt))
> +               return -FDT_ERR_BADSTATE;
> +
> +       offset = fdt_off_dt_struct(fdt);
> +       if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
> +               return -FDT_ERR_NOSPACE;
> +
> +       re = (struct fdt_reserve_entry *)((char *)fdt + offset);
> +       re->address = cpu_to_fdt64(addr);
> +       re->size = cpu_to_fdt64(size);
> +
> +       fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
> +
> +       return 0;
> +}
> +
> +int fdt_finish_reservemap(void *fdt)
> +{
> +       return fdt_add_reservemap_entry(fdt, 0, 0);
> +}
> +
> +int fdt_begin_node(void *fdt, const char *name)
> +{
> +       struct fdt_node_header *nh;
> +       int namelen = strlen(name) + 1;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
> +       if (! nh)
> +               return -FDT_ERR_NOSPACE;
> +
> +       nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
> +       memcpy(nh->name, name, namelen);
> +       return 0;
> +}
> +
> +int fdt_end_node(void *fdt)
> +{
> +       uint32_t *en;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       en = _fdt_grab_space(fdt, FDT_TAGSIZE);
> +       if (! en)
> +               return -FDT_ERR_NOSPACE;
> +
> +       *en = cpu_to_fdt32(FDT_END_NODE);
> +       return 0;
> +}
> +
> +static int _fdt_find_add_string(void *fdt, const char *s)
> +{
> +       char *strtab = (char *)fdt + fdt_totalsize(fdt);
> +       const char *p;
> +       int strtabsize = fdt_size_dt_strings(fdt);
> +       int len = strlen(s) + 1;
> +       int struct_top, offset;
> +
> +       p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
> +       if (p)
> +               return p - strtab;
> +
> +       /* Add it */
> +       offset = -strtabsize - len;
> +       struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
> +       if (fdt_totalsize(fdt) + offset < struct_top)
> +               return 0; /* no more room :( */
> +
> +       memcpy(strtab + offset, s, len);
> +       fdt_set_size_dt_strings(fdt, strtabsize + len);
> +       return offset;
> +}
> +
> +int fdt_property(void *fdt, const char *name, const void *val, int len)
> +{
> +       struct fdt_property *prop;
> +       int nameoff;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       nameoff = _fdt_find_add_string(fdt, name);
> +       if (nameoff == 0)
> +               return -FDT_ERR_NOSPACE;
> +
> +       prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
> +       if (! prop)
> +               return -FDT_ERR_NOSPACE;
> +
> +       prop->tag = cpu_to_fdt32(FDT_PROP);
> +       prop->nameoff = cpu_to_fdt32(nameoff);
> +       prop->len = cpu_to_fdt32(len);
> +       memcpy(prop->data, val, len);
> +       return 0;
> +}
> +
> +int fdt_finish(void *fdt)
> +{
> +       char *p = (char *)fdt;
> +       uint32_t *end;
> +       int oldstroffset, newstroffset;
> +       uint32_t tag;
> +       int offset, nextoffset;
> +
> +       FDT_SW_CHECK_HEADER(fdt);
> +
> +       /* Add terminator */
> +       end = _fdt_grab_space(fdt, sizeof(*end));
> +       if (! end)
> +               return -FDT_ERR_NOSPACE;
> +       *end = cpu_to_fdt32(FDT_END);
> +
> +       /* Relocate the string table */
> +       oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
> +       newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
> +       memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
> +       fdt_set_off_dt_strings(fdt, newstroffset);
> +
> +       /* Walk the structure, correcting string offsets */
> +       offset = 0;
> +       while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
> +               if (tag == FDT_PROP) {
> +                       struct fdt_property *prop =
> +                               _fdt_offset_ptr_w(fdt, offset);
> +                       int nameoff;
> +
> +                       nameoff = fdt32_to_cpu(prop->nameoff);
> +                       nameoff += fdt_size_dt_strings(fdt);
> +                       prop->nameoff = cpu_to_fdt32(nameoff);
> +               }
> +               offset = nextoffset;
> +       }
> +       if (nextoffset < 0)
> +               return nextoffset;
> +
> +       /* Finally, adjust the header */
> +       fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
> +       fdt_set_magic(fdt, FDT_MAGIC);
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
> new file mode 100644
> index 0000000..6025fa1
> --- /dev/null
> +++ b/xen/common/libfdt/fdt_wip.c
> @@ -0,0 +1,118 @@
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include "libfdt_env.h"
> +
> +#include <fdt.h>
> +#include <libfdt.h>
> +
> +#include "libfdt_internal.h"
> +
> +int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
> +                       const void *val, int len)
> +{
> +       void *propval;
> +       int proplen;
> +
> +       propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
> +       if (! propval)
> +               return proplen;
> +
> +       if (proplen != len)
> +               return -FDT_ERR_NOSPACE;
> +
> +       memcpy(propval, val, len);
> +       return 0;
> +}
> +
> +static void _fdt_nop_region(void *start, int len)
> +{
> +       uint32_t *p;
> +
> +       for (p = start; (char *)p < ((char *)start + len); p++)
> +               *p = cpu_to_fdt32(FDT_NOP);
> +}
> +
> +int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
> +{
> +       struct fdt_property *prop;
> +       int len;
> +
> +       prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
> +       if (! prop)
> +               return len;
> +
> +       _fdt_nop_region(prop, len + sizeof(*prop));
> +
> +       return 0;
> +}
> +
> +int _fdt_node_end_offset(void *fdt, int offset)
> +{
> +       int depth = 0;
> +
> +       while ((offset >= 0) && (depth >= 0))
> +               offset = fdt_next_node(fdt, offset, &depth);
> +
> +       return offset;
> +}
> +
> +int fdt_nop_node(void *fdt, int nodeoffset)
> +{
> +       int endoffset;
> +
> +       endoffset = _fdt_node_end_offset(fdt, nodeoffset);
> +       if (endoffset < 0)
> +               return endoffset;
> +
> +       _fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
> +                       endoffset - nodeoffset);
> +       return 0;
> +}
> diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
> new file mode 100644
> index 0000000..55f3eb3
> --- /dev/null
> +++ b/xen/common/libfdt/libfdt.h
> @@ -0,0 +1,1235 @@
> +#ifndef _LIBFDT_H
> +#define _LIBFDT_H
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include <libfdt_env.h>
> +#include <fdt.h>
> +
> +#define FDT_FIRST_SUPPORTED_VERSION    0x10
> +#define FDT_LAST_SUPPORTED_VERSION     0x11
> +
> +/* Error codes: informative error codes */
> +#define FDT_ERR_NOTFOUND       1
> +       /* FDT_ERR_NOTFOUND: The requested node or property does not exist */
> +#define FDT_ERR_EXISTS         2
> +       /* FDT_ERR_EXISTS: Attemped to create a node or property which
> +        * already exists */
> +#define FDT_ERR_NOSPACE                3
> +       /* FDT_ERR_NOSPACE: Operation needed to expand the device
> +        * tree, but its buffer did not have sufficient space to
> +        * contain the expanded tree. Use fdt_open_into() to move the
> +        * device tree to a buffer with more space. */
> +
> +/* Error codes: codes for bad parameters */
> +#define FDT_ERR_BADOFFSET      4
> +       /* FDT_ERR_BADOFFSET: Function was passed a structure block
> +        * offset which is out-of-bounds, or which points to an
> +        * unsuitable part of the structure for the operation. */
> +#define FDT_ERR_BADPATH                5
> +       /* FDT_ERR_BADPATH: Function was passed a badly formatted path
> +        * (e.g. missing a leading / for a function which requires an
> +        * absolute path) */
> +#define FDT_ERR_BADPHANDLE     6
> +       /* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
> +        * value.  phandle values of 0 and -1 are not permitted. */
> +#define FDT_ERR_BADSTATE       7
> +       /* FDT_ERR_BADSTATE: Function was passed an incomplete device
> +        * tree created by the sequential-write functions, which is
> +        * not sufficiently complete for the requested operation. */
> +
> +/* Error codes: codes for bad device tree blobs */
> +#define FDT_ERR_TRUNCATED      8
> +       /* FDT_ERR_TRUNCATED: Structure block of the given device tree
> +        * ends without an FDT_END tag. */
> +#define FDT_ERR_BADMAGIC       9
> +       /* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
> +        * device tree at all - it is missing the flattened device
> +        * tree magic number. */
> +#define FDT_ERR_BADVERSION     10
> +       /* FDT_ERR_BADVERSION: Given device tree has a version which
> +        * can't be handled by the requested operation.  For
> +        * read-write functions, this may mean that fdt_open_into() is
> +        * required to convert the tree to the expected version. */
> +#define FDT_ERR_BADSTRUCTURE   11
> +       /* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
> +        * structure block or other serious error (e.g. misnested
> +        * nodes, or subnodes preceding properties). */
> +#define FDT_ERR_BADLAYOUT      12
> +       /* FDT_ERR_BADLAYOUT: For read-write functions, the given
> +        * device tree has it's sub-blocks in an order that the
> +        * function can't handle (memory reserve map, then structure,
> +        * then strings).  Use fdt_open_into() to reorganize the tree
> +        * into a form suitable for the read-write operations. */
> +
> +/* "Can't happen" error indicating a bug in libfdt */
> +#define FDT_ERR_INTERNAL       13
> +       /* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
> +        * Should never be returned, if it is, it indicates a bug in
> +        * libfdt itself. */
> +
> +#define FDT_ERR_MAX            13
> +
> +/**********************************************************************/
> +/* Low-level functions (you probably don't need these)                */
> +/**********************************************************************/
> +
> +const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
> +static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
> +{
> +       return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
> +}
> +
> +uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
> +
> +/**********************************************************************/
> +/* Traversal functions                                                */
> +/**********************************************************************/
> +
> +int fdt_next_node(const void *fdt, int offset, int *depth);
> +
> +/**********************************************************************/
> +/* General functions                                                  */
> +/**********************************************************************/
> +
> +#define fdt_get_header(fdt, field) \
> +       (fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
> +#define fdt_magic(fdt)                         (fdt_get_header(fdt, magic))
> +#define fdt_totalsize(fdt)             (fdt_get_header(fdt, totalsize))
> +#define fdt_off_dt_struct(fdt)         (fdt_get_header(fdt, off_dt_struct))
> +#define fdt_off_dt_strings(fdt)                (fdt_get_header(fdt, off_dt_strings))
> +#define fdt_off_mem_rsvmap(fdt)                (fdt_get_header(fdt, off_mem_rsvmap))
> +#define fdt_version(fdt)               (fdt_get_header(fdt, version))
> +#define fdt_last_comp_version(fdt)     (fdt_get_header(fdt, last_comp_version))
> +#define fdt_boot_cpuid_phys(fdt)       (fdt_get_header(fdt, boot_cpuid_phys))
> +#define fdt_size_dt_strings(fdt)       (fdt_get_header(fdt, size_dt_strings))
> +#define fdt_size_dt_struct(fdt)                (fdt_get_header(fdt, size_dt_struct))
> +
> +#define __fdt_set_hdr(name) \
> +       static inline void fdt_set_##name(void *fdt, uint32_t val) \
> +       { \
> +               struct fdt_header *fdth = (struct fdt_header*)fdt; \
> +               fdth->name = cpu_to_fdt32(val); \
> +       }
> +__fdt_set_hdr(magic);
> +__fdt_set_hdr(totalsize);
> +__fdt_set_hdr(off_dt_struct);
> +__fdt_set_hdr(off_dt_strings);
> +__fdt_set_hdr(off_mem_rsvmap);
> +__fdt_set_hdr(version);
> +__fdt_set_hdr(last_comp_version);
> +__fdt_set_hdr(boot_cpuid_phys);
> +__fdt_set_hdr(size_dt_strings);
> +__fdt_set_hdr(size_dt_struct);
> +#undef __fdt_set_hdr
> +
> +/**
> + * fdt_check_header - sanity check a device tree or possible device tree
> + * @fdt: pointer to data which might be a flattened device tree
> + *
> + * fdt_check_header() checks that the given buffer contains what
> + * appears to be a flattened device tree with sane information in its
> + * header.
> + *
> + * returns:
> + *     0, if the buffer appears to contain a valid device tree
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings, as above
> + */
> +int fdt_check_header(const void *fdt);
> +
> +/**
> + * fdt_move - move a device tree around in memory
> + * @fdt: pointer to the device tree to move
> + * @buf: pointer to memory where the device is to be moved
> + * @bufsize: size of the memory space at buf
> + *
> + * fdt_move() relocates, if possible, the device tree blob located at
> + * fdt to the buffer at buf of size bufsize.  The buffer may overlap
> + * with the existing device tree blob at fdt.  Therefore,
> + *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
> + * should always succeed.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings
> + */
> +int fdt_move(const void *fdt, void *buf, int bufsize);
> +
> +/**********************************************************************/
> +/* Read-only functions                                                */
> +/**********************************************************************/
> +
> +/**
> + * fdt_string - retrieve a string from the strings block of a device tree
> + * @fdt: pointer to the device tree blob
> + * @stroffset: offset of the string within the strings block (native endian)
> + *
> + * fdt_string() retrieves a pointer to a single string from the
> + * strings block of the device tree blob at fdt.
> + *
> + * returns:
> + *     a pointer to the string, on success
> + *     NULL, if stroffset is out of bounds
> + */
> +const char *fdt_string(const void *fdt, int stroffset);
> +
> +/**
> + * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
> + * @fdt: pointer to the device tree blob
> + *
> + * Returns the number of entries in the device tree blob's memory
> + * reservation map.  This does not include the terminating 0,0 entry
> + * or any other (0,0) entries reserved for expansion.
> + *
> + * returns:
> + *     the number of entries
> + */
> +int fdt_num_mem_rsv(const void *fdt);
> +
> +/**
> + * fdt_get_mem_rsv - retrieve one memory reserve map entry
> + * @fdt: pointer to the device tree blob
> + * @address, @size: pointers to 64-bit variables
> + *
> + * On success, *address and *size will contain the address and size of
> + * the n-th reserve map entry from the device tree blob, in
> + * native-endian format.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings
> + */
> +int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
> +
> +/**
> + * fdt_subnode_offset_namelen - find a subnode based on substring
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + * @namelen: number of characters of name to consider
> + *
> + * Identical to fdt_subnode_offset(), but only examine the first
> + * namelen characters of name for matching the subnode name.  This is
> + * useful for finding subnodes based on a portion of a larger string,
> + * such as a full path.
> + */
> +int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
> +                              const char *name, int namelen);
> +/**
> + * fdt_subnode_offset - find a subnode of a given node
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + *
> + * fdt_subnode_offset() finds a subnode of the node at structure block
> + * offset parentoffset with the given name.  name may include a unit
> + * address, in which case fdt_subnode_offset() will find the subnode
> + * with that unit address, or the unit address may be omitted, in
> + * which case fdt_subnode_offset() will find an arbitrary subnode
> + * whose name excluding unit address matches the given name.
> + *
> + * returns:
> + *     structure block offset of the requested subnode (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the requested subnode does not exist
> + *     -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
> +
> +/**
> + * fdt_path_offset - find a tree node by its full path
> + * @fdt: pointer to the device tree blob
> + * @path: full path of the node to locate
> + *
> + * fdt_path_offset() finds a node of a given path in the device tree.
> + * Each path component may omit the unit address portion, but the
> + * results of this are undefined if any such path component is
> + * ambiguous (that is if there are multiple nodes at the relevant
> + * level matching the given component, differentiated only by unit
> + * address).
> + *
> + * returns:
> + *     structure block offset of the node with the requested path (>=0), on success
> + *     -FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
> + *     -FDT_ERR_NOTFOUND, if the requested node does not exist
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_path_offset(const void *fdt, const char *path);
> +
> +/**
> + * fdt_get_name - retrieve the name of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of the starting node
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_get_name() retrieves the name (including unit address) of the
> + * device tree node at structure block offset nodeoffset.  If lenp is
> + * non-NULL, the length of this name is also returned, in the integer
> + * pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the node's name, on success
> + *             If lenp is non-NULL, *lenp contains the length of that name (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL *lenp contains an error code (<0):
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE, standard meanings
> + */
> +const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
> +
> +/**
> + * fdt_first_property_offset - find the offset of a node's first property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of a node
> + *
> + * fdt_first_property_offset() finds the first property of the node at
> + * the given structure block offset.
> + *
> + * returns:
> + *     structure block offset of the property (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the requested node has no properties
> + *     -FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_first_property_offset(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_next_property_offset - step through a node's properties
> + * @fdt: pointer to the device tree blob
> + * @offset: structure block offset of a property
> + *
> + * fdt_next_property_offset() finds the property immediately after the
> + * one at the given structure block offset.  This will be a property
> + * of the same node as the given property.
> + *
> + * returns:
> + *     structure block offset of the next property (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the given property is the last in its node
> + *     -FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_next_property_offset(const void *fdt, int offset);
> +
> +/**
> + * fdt_get_property_by_offset - retrieve the property at a given offset
> + * @fdt: pointer to the device tree blob
> + * @offset: offset of the property to retrieve
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_get_property_by_offset() retrieves a pointer to the
> + * fdt_property structure within the device tree blob at the given
> + * offset.  If lenp is non-NULL, the length of the property value is
> + * also returned, in the integer pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the structure representing the property
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
> +                                                     int offset,
> +                                                     int *lenp);
> +
> +/**
> + * fdt_get_property_namelen - find a property based on substring
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @namelen: number of characters of name to consider
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * Identical to fdt_get_property_namelen(), but only examine the first
> + * namelen characters of name for matching the property name.
> + */
> +const struct fdt_property *fdt_get_property_namelen(const void *fdt,
> +                                                   int nodeoffset,
> +                                                   const char *name,
> +                                                   int namelen, int *lenp);
> +
> +/**
> + * fdt_get_property - find a given property in a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_get_property() retrieves a pointer to the fdt_property
> + * structure within the device tree blob corresponding to the property
> + * named 'name' of the node at offset nodeoffset.  If lenp is
> + * non-NULL, the length of the property value is also returned, in the
> + * integer pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the structure representing the property
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_NOTFOUND, node does not have named property
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
> +                                           const char *name, int *lenp);
> +static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
> +                                                     const char *name,
> +                                                     int *lenp)
> +{
> +       return (struct fdt_property *)(uintptr_t)
> +               fdt_get_property(fdt, nodeoffset, name, lenp);
> +}
> +
> +/**
> + * fdt_getprop_by_offset - retrieve the value of a property at a given offset
> + * @fdt: pointer to the device tree blob
> + * @ffset: offset of the property to read
> + * @namep: pointer to a string variable (will be overwritten) or NULL
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_getprop_by_offset() retrieves a pointer to the value of the
> + * property at structure block offset 'offset' (this will be a pointer
> + * to within the device blob itself, not a copy of the value).  If
> + * lenp is non-NULL, the length of the property value is also
> + * returned, in the integer pointed to by lenp.  If namep is non-NULL,
> + * the property's namne will also be returned in the char * pointed to
> + * by namep (this will be a pointer to within the device tree's string
> + * block, not a new copy of the name).
> + *
> + * returns:
> + *     pointer to the property's value
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *             if namep is non-NULL *namep contiains a pointer to the property
> + *             name.
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const void *fdt_getprop_by_offset(const void *fdt, int offset,
> +                                 const char **namep, int *lenp);
> +
> +/**
> + * fdt_getprop_namelen - get property value based on substring
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @namelen: number of characters of name to consider
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * Identical to fdt_getprop(), but only examine the first namelen
> + * characters of name for matching the property name.
> + */
> +const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
> +                               const char *name, int namelen, int *lenp);
> +
> +/**
> + * fdt_getprop - retrieve the value of a given property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to find
> + * @name: name of the property to find
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_getprop() retrieves a pointer to the value of the property
> + * named 'name' of the node at offset nodeoffset (this will be a
> + * pointer to within the device blob itself, not a copy of the value).
> + * If lenp is non-NULL, the length of the property value is also
> + * returned, in the integer pointed to by lenp.
> + *
> + * returns:
> + *     pointer to the property's value
> + *             if lenp is non-NULL, *lenp contains the length of the property
> + *             value (>=0)
> + *     NULL, on error
> + *             if lenp is non-NULL, *lenp contains an error code (<0):
> + *             -FDT_ERR_NOTFOUND, node does not have named property
> + *             -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *             -FDT_ERR_BADMAGIC,
> + *             -FDT_ERR_BADVERSION,
> + *             -FDT_ERR_BADSTATE,
> + *             -FDT_ERR_BADSTRUCTURE,
> + *             -FDT_ERR_TRUNCATED, standard meanings
> + */
> +const void *fdt_getprop(const void *fdt, int nodeoffset,
> +                       const char *name, int *lenp);
> +static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
> +                                 const char *name, int *lenp)
> +{
> +       return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
> +}
> +
> +/**
> + * fdt_get_phandle - retrieve the phandle of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of the node
> + *
> + * fdt_get_phandle() retrieves the phandle of the device tree node at
> + * structure block offset nodeoffset.
> + *
> + * returns:
> + *     the phandle of the node at nodeoffset, on success (!= 0, != -1)
> + *     0, if the node has no phandle, or another error occurs
> + */
> +uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_get_alias_namelen - get alias based on substring
> + * @fdt: pointer to the device tree blob
> + * @name: name of the alias th look up
> + * @namelen: number of characters of name to consider
> + *
> + * Identical to fdt_get_alias(), but only examine the first namelen
> + * characters of name for matching the alias name.
> + */
> +const char *fdt_get_alias_namelen(const void *fdt,
> +                                 const char *name, int namelen);
> +
> +/**
> + * fdt_get_alias - retreive the path referenced by a given alias
> + * @fdt: pointer to the device tree blob
> + * @name: name of the alias th look up
> + *
> + * fdt_get_alias() retrieves the value of a given alias.  That is, the
> + * value of the property named 'name' in the node /aliases.
> + *
> + * returns:
> + *     a pointer to the expansion of the alias named 'name', of it exists
> + *     NULL, if the given alias or the /aliases node does not exist
> + */
> +const char *fdt_get_alias(const void *fdt, const char *name);
> +
> +/**
> + * fdt_get_path - determine the full path of a node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose path to find
> + * @buf: character buffer to contain the returned path (will be overwritten)
> + * @buflen: size of the character buffer at buf
> + *
> + * fdt_get_path() computes the full path of the node at offset
> + * nodeoffset, and records that path in the buffer at buf.
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset.
> + *
> + * returns:
> + *     0, on success
> + *             buf contains the absolute path of the node at
> + *             nodeoffset, as a NUL-terminated string.
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
> + *             characters and will not fit in the given buffer.
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
> +
> +/**
> + * fdt_supernode_atdepth_offset - find a specific ancestor of a node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose parent to find
> + * @supernodedepth: depth of the ancestor to find
> + * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_supernode_atdepth_offset() finds an ancestor of the given node
> + * at a specific depth from the root (where the root itself has depth
> + * 0, its immediate subnodes depth 1 and so forth).  So
> + *     fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
> + * will always return 0, the offset of the root node.  If the node at
> + * nodeoffset has depth D, then:
> + *     fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
> + * will return nodeoffset itself.
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset.
> + *
> + * returns:
> +
> + *     structure block offset of the node at node offset's ancestor
> + *             of depth supernodedepth (>=0), on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> +*      -FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
> +                                int supernodedepth, int *nodedepth);
> +
> +/**
> + * fdt_node_depth - find the depth of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose parent to find
> + *
> + * fdt_node_depth() finds the depth of a given node.  The root node
> + * has depth 0, its immediate subnodes depth 1 and so forth.
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset.
> + *
> + * returns:
> + *     depth of the node at nodeoffset (>=0), on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_depth(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_parent_offset - find the parent of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose parent to find
> + *
> + * fdt_parent_offset() locates the parent node of a given node (that
> + * is, it finds the offset of the node which contains the node at
> + * nodeoffset as a subnode).
> + *
> + * NOTE: This function is expensive, as it must scan the device tree
> + * structure from the start to nodeoffset, *twice*.
> + *
> + * returns:
> + *     structure block offset of the parent of the node at nodeoffset
> + *             (>=0), on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_parent_offset(const void *fdt, int nodeoffset);
> +
> +/**
> + * fdt_node_offset_by_prop_value - find nodes with a given property value
> + * @fdt: pointer to the device tree blob
> + * @startoffset: only find nodes after this offset
> + * @propname: property name to check
> + * @propval: property value to search for
> + * @proplen: length of the value in propval
> + *
> + * fdt_node_offset_by_prop_value() returns the offset of the first
> + * node after startoffset, which has a property named propname whose
> + * value is of length proplen and has value equal to propval; or if
> + * startoffset is -1, the very first such node in the tree.
> + *
> + * To iterate through all nodes matching the criterion, the following
> + * idiom can be used:
> + *     offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
> + *                                            propval, proplen);
> + *     while (offset != -FDT_ERR_NOTFOUND) {
> + *             // other code here
> + *             offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
> + *                                                    propval, proplen);
> + *     }
> + *
> + * Note the -1 in the first call to the function, if 0 is used here
> + * instead, the function will never locate the root node, even if it
> + * matches the criterion.
> + *
> + * returns:
> + *     structure block offset of the located node (>= 0, >startoffset),
> + *              on success
> + *     -FDT_ERR_NOTFOUND, no node matching the criterion exists in the
> + *             tree after startoffset
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
> +                                 const char *propname,
> +                                 const void *propval, int proplen);
> +
> +/**
> + * fdt_node_offset_by_phandle - find the node with a given phandle
> + * @fdt: pointer to the device tree blob
> + * @phandle: phandle value
> + *
> + * fdt_node_offset_by_phandle() returns the offset of the node
> + * which has the given phandle value.  If there is more than one node
> + * in the tree with the given phandle (an invalid tree), results are
> + * undefined.
> + *
> + * returns:
> + *     structure block offset of the located node (>= 0), on success
> + *     -FDT_ERR_NOTFOUND, no node with that phandle exists
> + *     -FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
> +
> +/**
> + * fdt_node_check_compatible: check a node's compatible property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of a tree node
> + * @compatible: string to match against
> + *
> + *
> + * fdt_node_check_compatible() returns 0 if the given node contains a
> + * 'compatible' property with the given string as one of its elements,
> + * it returns non-zero otherwise, or on error.
> + *
> + * returns:
> + *     0, if the node has a 'compatible' property listing the given string
> + *     1, if the node has a 'compatible' property, but it does not list
> + *             the given string
> + *     -FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
> + *     -FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_check_compatible(const void *fdt, int nodeoffset,
> +                             const char *compatible);
> +
> +/**
> + * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
> + * @fdt: pointer to the device tree blob
> + * @startoffset: only find nodes after this offset
> + * @compatible: 'compatible' string to match against
> + *
> + * fdt_node_offset_by_compatible() returns the offset of the first
> + * node after startoffset, which has a 'compatible' property which
> + * lists the given compatible string; or if startoffset is -1, the
> + * very first such node in the tree.
> + *
> + * To iterate through all nodes matching the criterion, the following
> + * idiom can be used:
> + *     offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
> + *     while (offset != -FDT_ERR_NOTFOUND) {
> + *             // other code here
> + *             offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
> + *     }
> + *
> + * Note the -1 in the first call to the function, if 0 is used here
> + * instead, the function will never locate the root node, even if it
> + * matches the criterion.
> + *
> + * returns:
> + *     structure block offset of the located node (>= 0, >startoffset),
> + *              on success
> + *     -FDT_ERR_NOTFOUND, no node matching the criterion exists in the
> + *             tree after startoffset
> + *     -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE, standard meanings
> + */
> +int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
> +                                 const char *compatible);
> +
> +/**********************************************************************/
> +/* Write-in-place functions                                           */
> +/**********************************************************************/
> +
> +/**
> + * fdt_setprop_inplace - change a property's value, but not its size
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: pointer to data to replace the property value with
> + * @len: length of the property value
> + *
> + * fdt_setprop_inplace() replaces the value of a given property with
> + * the data in val, of length len.  This function cannot change the
> + * size of a property, and so will only work if len is equal to the
> + * current length of the property.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the given property value, and will not alter or move any other part
> + * of the tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, if len is not equal to the property's current length
> + *     -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
> +                       const void *val, int len);
> +
> +/**
> + * fdt_setprop_inplace_cell - change the value of a single-cell property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: cell (32-bit integer) value to replace the property with
> + *
> + * fdt_setprop_inplace_cell() replaces the value of a given property
> + * with the 32-bit integer cell value in val, converting val to
> + * big-endian if necessary.  This function cannot change the size of a
> + * property, and so will only work if the property already exists and
> + * has length 4.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the given property value, and will not alter or move any other part
> + * of the tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, if the property's length is not equal to 4
> +  *    -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
> +                                          const char *name, uint32_t val)
> +{
> +       val = cpu_to_fdt32(val);
> +       return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
> +}
> +
> +/**
> + * fdt_nop_property - replace a property with nop tags
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to nop
> + * @name: name of the property to nop
> + *
> + * fdt_nop_property() will replace a given property's representation
> + * in the blob with FDT_NOP tags, effectively removing it from the
> + * tree.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the property, and will not alter or move any other part of the
> + * tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
> +
> +/**
> + * fdt_nop_node - replace a node (subtree) with nop tags
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node to nop
> + *
> + * fdt_nop_node() will replace a given node's representation in the
> + * blob, including all its subnodes, if any, with FDT_NOP tags,
> + * effectively removing it from the tree.
> + *
> + * This function will alter only the bytes in the blob which contain
> + * the node and its properties and subnodes, and will not alter or
> + * move any other part of the tree.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_nop_node(void *fdt, int nodeoffset);
> +
> +/**********************************************************************/
> +/* Sequential write functions                                         */
> +/**********************************************************************/
> +
> +int fdt_create(void *buf, int bufsize);
> +int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
> +int fdt_finish_reservemap(void *fdt);
> +int fdt_begin_node(void *fdt, const char *name);
> +int fdt_property(void *fdt, const char *name, const void *val, int len);
> +static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
> +{
> +       val = cpu_to_fdt32(val);
> +       return fdt_property(fdt, name, &val, sizeof(val));
> +}
> +#define fdt_property_string(fdt, name, str) \
> +       fdt_property(fdt, name, str, strlen(str)+1)
> +int fdt_end_node(void *fdt);
> +int fdt_finish(void *fdt);
> +
> +/**********************************************************************/
> +/* Read-write functions                                               */
> +/**********************************************************************/
> +
> +int fdt_open_into(const void *fdt, void *buf, int bufsize);
> +int fdt_pack(void *fdt);
> +
> +/**
> + * fdt_add_mem_rsv - add one memory reserve map entry
> + * @fdt: pointer to the device tree blob
> + * @address, @size: 64-bit values (native endian)
> + *
> + * Adds a reserve map entry to the given blob reserving a region at
> + * address address of length size.
> + *
> + * This function will insert data into the reserve map and will
> + * therefore change the indexes of some entries in the table.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new reservation entry
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
> +
> +/**
> + * fdt_del_mem_rsv - remove a memory reserve map entry
> + * @fdt: pointer to the device tree blob
> + * @n: entry to remove
> + *
> + * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
> + * the blob.
> + *
> + * This function will delete data from the reservation table and will
> + * therefore change the indexes of some entries in the table.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
> + *             are less than n+1 reserve map entries)
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_del_mem_rsv(void *fdt, int n);
> +
> +/**
> + * fdt_set_name - change the name of a given node
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: structure block offset of a node
> + * @name: name to give the node
> + *
> + * fdt_set_name() replaces the name (including unit address, if any)
> + * of the given node with the given string.  NOTE: this function can't
> + * efficiently check if the new name is unique amongst the given
> + * node's siblings; results are undefined if this function is invoked
> + * with a name equal to one of the given node's siblings.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob
> + *             to contain the new name
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE, standard meanings
> + */
> +int fdt_set_name(void *fdt, int nodeoffset, const char *name);
> +
> +/**
> + * fdt_setprop - create or change a property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: pointer to data to set the property value to
> + * @len: length of the property value
> + *
> + * fdt_setprop() sets the value of the named property in the given
> + * node to the given value and length, creating the property if it
> + * does not already exist.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new property value
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_setprop(void *fdt, int nodeoffset, const char *name,
> +               const void *val, int len);
> +
> +/**
> + * fdt_setprop_cell - set a property to a single cell value
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @val: 32-bit integer value for the property (native endian)
> + *
> + * fdt_setprop_cell() sets the value of the named property in the
> + * given node to the given cell value (converting to big-endian if
> + * necessary), or creates a new property with that value if it does
> + * not already exist.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new property value
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
> +                                  uint32_t val)
> +{
> +       val = cpu_to_fdt32(val);
> +       return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
> +}
> +
> +/**
> + * fdt_setprop_string - set a property to a string value
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to change
> + * @name: name of the property to change
> + * @str: string value for the property
> + *
> + * fdt_setprop_string() sets the value of the named property in the
> + * given node to the given string value (using the length of the
> + * string to determine the new length of the property), or creates a
> + * new property with that value if it does not already exist.
> + *
> + * This function may insert or delete data from the blob, and will
> + * therefore change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
> + *             contain the new property value
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +#define fdt_setprop_string(fdt, nodeoffset, name, str) \
> +       fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
> +
> +/**
> + * fdt_delprop - delete a property
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node whose property to nop
> + * @name: name of the property to nop
> + *
> + * fdt_del_property() will delete the given property.
> + *
> + * This function will delete data from the blob, and will therefore
> + * change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_NOTFOUND, node does not have the named property
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_delprop(void *fdt, int nodeoffset, const char *name);
> +
> +/**
> + * fdt_add_subnode_namelen - creates a new node based on substring
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + * @namelen: number of characters of name to consider
> + *
> + * Identical to fdt_add_subnode(), but use only the first namelen
> + * characters of name as the name of the new node.  This is useful for
> + * creating subnodes based on a portion of a larger string, such as a
> + * full path.
> + */
> +int fdt_add_subnode_namelen(void *fdt, int parentoffset,
> +                           const char *name, int namelen);
> +
> +/**
> + * fdt_add_subnode - creates a new node
> + * @fdt: pointer to the device tree blob
> + * @parentoffset: structure block offset of a node
> + * @name: name of the subnode to locate
> + *
> + * fdt_add_subnode() creates a new node as a subnode of the node at
> + * structure block offset parentoffset, with the given name (which
> + * should include the unit address, if any).
> + *
> + * This function will insert data into the blob, and will therefore
> + * change the offsets of some existing nodes.
> +
> + * returns:
> + *     structure block offset of the created nodeequested subnode (>=0), on success
> + *     -FDT_ERR_NOTFOUND, if the requested subnode does not exist
> + *     -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
> + *     -FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
> + *             the given name
> + *     -FDT_ERR_NOSPACE, if there is insufficient free space in the
> + *             blob to contain the new node
> + *     -FDT_ERR_NOSPACE
> + *     -FDT_ERR_BADLAYOUT
> + *      -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings.
> + */
> +int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
> +
> +/**
> + * fdt_del_node - delete a node (subtree)
> + * @fdt: pointer to the device tree blob
> + * @nodeoffset: offset of the node to nop
> + *
> + * fdt_del_node() will remove the given node, including all its
> + * subnodes if any, from the blob.
> + *
> + * This function will delete data from the blob, and will therefore
> + * change the offsets of some existing nodes.
> + *
> + * returns:
> + *     0, on success
> + *     -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
> + *     -FDT_ERR_BADLAYOUT,
> + *     -FDT_ERR_BADMAGIC,
> + *     -FDT_ERR_BADVERSION,
> + *     -FDT_ERR_BADSTATE,
> + *     -FDT_ERR_BADSTRUCTURE,
> + *     -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_del_node(void *fdt, int nodeoffset);
> +
> +/**********************************************************************/
> +/* Debugging / informational functions                                */
> +/**********************************************************************/
> +
> +const char *fdt_strerror(int errval);
> +
> +#endif /* _LIBFDT_H */
> diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
> new file mode 100644
> index 0000000..449bf60
> --- /dev/null
> +++ b/xen/common/libfdt/libfdt_env.h
> @@ -0,0 +1,23 @@
> +#ifndef _LIBFDT_ENV_H
> +#define _LIBFDT_ENV_H
> +
> +#include <stddef.h>
> +#include <stdint.h>
> +#include <string.h>
> +
> +#define _B(n)  ((unsigned long long)((uint8_t *)&x)[n])
> +static inline uint32_t fdt32_to_cpu(uint32_t x)
> +{
> +       return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
> +}
> +#define cpu_to_fdt32(x) fdt32_to_cpu(x)
> +
> +static inline uint64_t fdt64_to_cpu(uint64_t x)
> +{
> +       return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
> +               | (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
> +}
> +#define cpu_to_fdt64(x) fdt64_to_cpu(x)
> +#undef _B
> +
> +#endif /* _LIBFDT_ENV_H */
> diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
> new file mode 100644
> index 0000000..381133b
> --- /dev/null
> +++ b/xen/common/libfdt/libfdt_internal.h
> @@ -0,0 +1,95 @@
> +#ifndef _LIBFDT_INTERNAL_H
> +#define _LIBFDT_INTERNAL_H
> +/*
> + * libfdt - Flat Device Tree manipulation
> + * Copyright (C) 2006 David Gibson, IBM Corporation.
> + *
> + * libfdt is dual licensed: you can use it either under the terms of
> + * the GPL, or the BSD license, at your option.
> + *
> + *  a) This library 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 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 General Public License for more details.
> + *
> + *     You should have received a copy of the GNU General Public
> + *     License along with this library; if not, write to the Free
> + *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + *     MA 02110-1301 USA
> + *
> + * Alternatively,
> + *
> + *  b) Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *     1. Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *     2. Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> + *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
> + *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> + *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> + *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> + *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include <fdt.h>
> +
> +#define FDT_ALIGN(x, a)                (((x) + (a) - 1) & ~((a) - 1))
> +#define FDT_TAGALIGN(x)                (FDT_ALIGN((x), FDT_TAGSIZE))
> +
> +#define FDT_CHECK_HEADER(fdt) \
> +       { \
> +               int err; \
> +               if ((err = fdt_check_header(fdt)) != 0) \
> +                       return err; \
> +       }
> +
> +int _fdt_check_node_offset(const void *fdt, int offset);
> +int _fdt_check_prop_offset(const void *fdt, int offset);
> +const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
> +int _fdt_node_end_offset(void *fdt, int nodeoffset);
> +
> +static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
> +{
> +       return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
> +}
> +
> +static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
> +{
> +       return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
> +}
> +
> +static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
> +{
> +       const struct fdt_reserve_entry *rsv_table =
> +               (const struct fdt_reserve_entry *)
> +               ((const char *)fdt + fdt_off_mem_rsvmap(fdt));
> +
> +       return rsv_table + n;
> +}
> +static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
> +{
> +       return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
> +}
> +
> +#define FDT_SW_MAGIC           (~FDT_MAGIC)
> +
> +#endif /* _LIBFDT_INTERNAL_H */
> diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
> new file mode 100644
> index 0000000..3c3994e
> --- /dev/null
> +++ b/xen/common/libfdt/version.lds
> @@ -0,0 +1,54 @@
> +LIBFDT_1.2 {
> +       global:
> +               fdt_next_node;
> +               fdt_check_header;
> +               fdt_move;
> +               fdt_string;
> +               fdt_num_mem_rsv;
> +               fdt_get_mem_rsv;
> +               fdt_subnode_offset_namelen;
> +               fdt_subnode_offset;
> +               fdt_path_offset;
> +               fdt_get_name;
> +               fdt_get_property_namelen;
> +               fdt_get_property;
> +               fdt_getprop_namelen;
> +               fdt_getprop;
> +               fdt_get_phandle;
> +               fdt_get_alias_namelen;
> +               fdt_get_alias;
> +               fdt_get_path;
> +               fdt_supernode_atdepth_offset;
> +               fdt_node_depth;
> +               fdt_parent_offset;
> +               fdt_node_offset_by_prop_value;
> +               fdt_node_offset_by_phandle;
> +               fdt_node_check_compatible;
> +               fdt_node_offset_by_compatible;
> +               fdt_setprop_inplace;
> +               fdt_nop_property;
> +               fdt_nop_node;
> +               fdt_create;
> +               fdt_add_reservemap_entry;
> +               fdt_finish_reservemap;
> +               fdt_begin_node;
> +               fdt_property;
> +               fdt_end_node;
> +               fdt_finish;
> +               fdt_open_into;
> +               fdt_pack;
> +               fdt_add_mem_rsv;
> +               fdt_del_mem_rsv;
> +               fdt_set_name;
> +               fdt_setprop;
> +               fdt_delprop;
> +               fdt_add_subnode_namelen;
> +               fdt_add_subnode;
> +               fdt_del_node;
> +               fdt_strerror;
> +               fdt_offset_ptr;
> +               fdt_next_tag;
> +
> +       local:
> +               *;
> +};
> --
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:39:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvqgz-0000fm-Gs; Fri, 10 Feb 2012 13:39:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <young.zhang.free@gmail.com>) id 1Rvqgx-0000eI-UO
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:39:12 +0000
X-Env-Sender: young.zhang.free@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328881143!12850910!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 10 Feb 2012 13:39:05 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:39:05 -0000
Received: by pbbro2 with SMTP id ro2so13135208pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 05:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=I8KOrRm5rfQXiM0UKEHUwEb6nnYBr23iMgm/2f5uEek=;
	b=E6+VFmSkYbftb50DPUV1knRFsw5LSbdshjWMXasuxQxTGVBUDfLBBtEoTtQoBFNSij
	xqJT13aiAEuhXCrZQJYV1tQgsVyjus+D0SqybKbC11XovpoL4rA8cl6zUAUFn8AVr8cu
	Wfa4m7x/qskkybodLCoCeOEXtmxWDu8W4kMOA=
MIME-Version: 1.0
Received: by 10.68.73.106 with SMTP id k10mr16709843pbv.35.1328881143562; Fri,
	10 Feb 2012 05:39:03 -0800 (PST)
Received: by 10.68.7.69 with HTTP; Fri, 10 Feb 2012 05:39:03 -0800 (PST)
Date: Fri, 10 Feb 2012 21:39:03 +0800
Message-ID: <CABaSDNg9DcCz4RZdf+=tTY=EjhyYKSTVce05AXM7uXecBH+KSg@mail.gmail.com>
From: young zhang <young.zhang.free@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to add a new trace event?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I want to trace something which is not covered by current events,  but
i found the logic is very complicated. Is there any simple example of
adding a new trace event?

-- 
young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:39:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13:39:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvqgz-0000fm-Gs; Fri, 10 Feb 2012 13:39:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <young.zhang.free@gmail.com>) id 1Rvqgx-0000eI-UO
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:39:12 +0000
X-Env-Sender: young.zhang.free@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328881143!12850910!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 10 Feb 2012 13:39:05 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 13:39:05 -0000
Received: by pbbro2 with SMTP id ro2so13135208pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 05:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=I8KOrRm5rfQXiM0UKEHUwEb6nnYBr23iMgm/2f5uEek=;
	b=E6+VFmSkYbftb50DPUV1knRFsw5LSbdshjWMXasuxQxTGVBUDfLBBtEoTtQoBFNSij
	xqJT13aiAEuhXCrZQJYV1tQgsVyjus+D0SqybKbC11XovpoL4rA8cl6zUAUFn8AVr8cu
	Wfa4m7x/qskkybodLCoCeOEXtmxWDu8W4kMOA=
MIME-Version: 1.0
Received: by 10.68.73.106 with SMTP id k10mr16709843pbv.35.1328881143562; Fri,
	10 Feb 2012 05:39:03 -0800 (PST)
Received: by 10.68.7.69 with HTTP; Fri, 10 Feb 2012 05:39:03 -0800 (PST)
Date: Fri, 10 Feb 2012 21:39:03 +0800
Message-ID: <CABaSDNg9DcCz4RZdf+=tTY=EjhyYKSTVce05AXM7uXecBH+KSg@mail.gmail.com>
From: young zhang <young.zhang.free@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] how to add a new trace event?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I want to trace something which is not covered by current events,  but
i found the logic is very complicated. Is there any simple example of
adding a new trace event?

-- 
young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:41:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvqii-0000v1-2x; Fri, 10 Feb 2012 13:41:00 +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 1Rvqih-0000uj-6x
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:40:59 +0000
Received: from [85.158.139.83:17591] by server-12.bemta-5.messagelabs.com id
	1B/75-30830-A6E153F4; Fri, 10 Feb 2012 13:40:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328881255!14466910!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8725 invoked from network); 10 Feb 2012 13:40:56 -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;
	10 Feb 2012 13:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181234153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:40:54 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 10 Feb 2012
	08:40:54 -0500
Message-ID: <4F351E65.6020604@citrix.com>
Date: Fri, 10 Feb 2012 13:40:53 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>	
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328880943.6133.264.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/12 13:35, Ian Campbell wrote:
> On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Link a device tree blob (DTB) into the xen image.  This is loaded
>> immediately after Xen and xen_start() is called with the correct
>> address in atag_paddr.
> 
> Is platform.dtb supposed to be included in this patch/series or is it
> intended that I should supply it from somewhere? (in which case, how and
> where etc).

I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.

Would it be better build the DTB from source included in Xen? Or specify
the DTB in some other way (makefile variables?)?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:41:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvqii-0000v1-2x; Fri, 10 Feb 2012 13:41:00 +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 1Rvqih-0000uj-6x
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:40:59 +0000
Received: from [85.158.139.83:17591] by server-12.bemta-5.messagelabs.com id
	1B/75-30830-A6E153F4; Fri, 10 Feb 2012 13:40:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328881255!14466910!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8725 invoked from network); 10 Feb 2012 13:40:56 -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;
	10 Feb 2012 13:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181234153"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 08:40:54 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 10 Feb 2012
	08:40:54 -0500
Message-ID: <4F351E65.6020604@citrix.com>
Date: Fri, 10 Feb 2012 13:40:53 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>	
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328880943.6133.264.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/12 13:35, Ian Campbell wrote:
> On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Link a device tree blob (DTB) into the xen image.  This is loaded
>> immediately after Xen and xen_start() is called with the correct
>> address in atag_paddr.
> 
> Is platform.dtb supposed to be included in this patch/series or is it
> intended that I should supply it from somewhere? (in which case, how and
> where etc).

I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.

Would it be better build the DTB from source included in Xen? Or specify
the DTB in some other way (makefile variables?)?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:44:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvqlw-0001Er-Ng; Fri, 10 Feb 2012 13:44:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvqlv-0001Eg-K4
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:44:19 +0000
Received: from [193.109.254.147:40614] by server-7.bemta-14.messagelabs.com id
	45/3B-04457-23F153F4; Fri, 10 Feb 2012 13:44:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328881407!52233712!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9777 invoked from network); 10 Feb 2012 13:43:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 13:43:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvqlt-00085D-At; Fri, 10 Feb 2012 13:44:17 +0000
Date: Fri, 10 Feb 2012 13:44:17 +0000
From: Tim Deegan <tim@xen.org>
To: Peter Deng <agent.peter123@gmail.com>
Message-ID: <20120210134417.GA30945@ocelot.phlegethon.org>
References: <CAJy3yGD8PM5c6rF-gvXyCWKFLR1CFvJYxNUJgRhzq=+2rnZhpw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJy3yGD8PM5c6rF-gvXyCWKFLR1CFvJYxNUJgRhzq=+2rnZhpw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen Mem Page Sharing -> Implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 13:07 -0500 on 08 Feb (1328706468), Peter Deng wrote:
> So looking through the code, I am getting that the mechanisms for sharing
> the pages are present within the hypervisor and the hypervisor will manage
> the sharing and unsharing of pages. Now, this leads me into a question that
> regards the implementation of sharing pages. In the research articles I
> have read, hashing was used to determine the contents of similar pages; is
> there code implementation present in Xen that does this or something
> related in that area? If so, where is it in the source code?

No, Xen itself does not contain any code for selecting which pages to
share.  We leave that to the tools.

Incidentally, here are some reasons why hashing pages of RAM and
scanning for duplicates might not be such a great idea:
http://www.usenix.org/events/usenix09/tech/full_papers/milos/milos_html/index.html
(N.B.: that paper does _not_ describe the page-sharing interface that's
currently in Xen; Satori was a research prototype for sharing memory
between _PV_ guests).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:44:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvqlw-0001Er-Ng; Fri, 10 Feb 2012 13:44:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvqlv-0001Eg-K4
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:44:19 +0000
Received: from [193.109.254.147:40614] by server-7.bemta-14.messagelabs.com id
	45/3B-04457-23F153F4; Fri, 10 Feb 2012 13:44:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328881407!52233712!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9777 invoked from network); 10 Feb 2012 13:43:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 13:43:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvqlt-00085D-At; Fri, 10 Feb 2012 13:44:17 +0000
Date: Fri, 10 Feb 2012 13:44:17 +0000
From: Tim Deegan <tim@xen.org>
To: Peter Deng <agent.peter123@gmail.com>
Message-ID: <20120210134417.GA30945@ocelot.phlegethon.org>
References: <CAJy3yGD8PM5c6rF-gvXyCWKFLR1CFvJYxNUJgRhzq=+2rnZhpw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJy3yGD8PM5c6rF-gvXyCWKFLR1CFvJYxNUJgRhzq=+2rnZhpw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen Mem Page Sharing -> Implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 13:07 -0500 on 08 Feb (1328706468), Peter Deng wrote:
> So looking through the code, I am getting that the mechanisms for sharing
> the pages are present within the hypervisor and the hypervisor will manage
> the sharing and unsharing of pages. Now, this leads me into a question that
> regards the implementation of sharing pages. In the research articles I
> have read, hashing was used to determine the contents of similar pages; is
> there code implementation present in Xen that does this or something
> related in that area? If so, where is it in the source code?

No, Xen itself does not contain any code for selecting which pages to
share.  We leave that to the tools.

Incidentally, here are some reasons why hashing pages of RAM and
scanning for duplicates might not be such a great idea:
http://www.usenix.org/events/usenix09/tech/full_papers/milos/milos_html/index.html
(N.B.: that paper does _not_ describe the page-sharing interface that's
currently in Xen; Satori was a research prototype for sharing memory
between _PV_ guests).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:48:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1RvqpW-0001Ul-QD; Fri, 10 Feb 2012 13:48: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 1RvqpU-0001UQ-Mn
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:48:00 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328881643!59327656!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24216 invoked from network); 10 Feb 2012 13:47:24 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 13:47:24 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvqpM-0005UV-LD
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 05:47:52 -0800
Date: Fri, 10 Feb 2012 05:47:52 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328881672637-5472477.post@n5.nabble.com>
In-Reply-To: <1328777821.6133.99.camel@zakaz.uk.xensource.com>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have try Precise PV on HVM with qemu upstream and spice but not work.
Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b 

DomU xl configuration file:
----------------------------------------------------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,xvda,rw',
'/dev/scd0,raw,xvdb,ro,cdrom']
boot='c'
xen_platform_pci=1
device_model_version="qemu-xen"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
stdvga=0
sdl=0
spice=1
spicehost="0.0.0.0"
spiceport=6000
spicepasswd="test"
----------------------------------------------------------------

Without spice the domU starts but vnc is unusable and network doesn't work.

With spice it doesn't start:
xl create /etc/xen/PRECISEHVM.cfg
Parsing config file /etc/xen/PRECISEHVM.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019bc70
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_qmp.c:636:libxl__qmp_initialize: Connection error: No
such file or directory
libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
during startup
libxl: error: libxl_create.c:602:do_domain_create: device model did not
start: -1

And on log:
qemu-system-i386: -spice
port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on: there is no
option group "spice"
spice is not supported by this qemu build.

Is there something wrong on configuration file or are there some bugs?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5472477.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:48:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1RvqpW-0001Ul-QD; Fri, 10 Feb 2012 13:48: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 1RvqpU-0001UQ-Mn
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:48:00 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328881643!59327656!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24216 invoked from network); 10 Feb 2012 13:47:24 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 13:47:24 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvqpM-0005UV-LD
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 05:47:52 -0800
Date: Fri, 10 Feb 2012 05:47:52 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328881672637-5472477.post@n5.nabble.com>
In-Reply-To: <1328777821.6133.99.camel@zakaz.uk.xensource.com>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have try Precise PV on HVM with qemu upstream and spice but not work.
Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b 

DomU xl configuration file:
----------------------------------------------------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,xvda,rw',
'/dev/scd0,raw,xvdb,ro,cdrom']
boot='c'
xen_platform_pci=1
device_model_version="qemu-xen"
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
stdvga=0
sdl=0
spice=1
spicehost="0.0.0.0"
spiceport=6000
spicepasswd="test"
----------------------------------------------------------------

Without spice the domU starts but vnc is unusable and network doesn't work.

With spice it doesn't start:
xl create /etc/xen/PRECISEHVM.cfg
Parsing config file /etc/xen/PRECISEHVM.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019bc70
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_qmp.c:636:libxl__qmp_initialize: Connection error: No
such file or directory
libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
during startup
libxl: error: libxl_create.c:602:do_domain_create: device model did not
start: -1

And on log:
qemu-system-i386: -spice
port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on: there is no
option group "spice"
spice is not supported by this qemu build.

Is there something wrong on configuration file or are there some bugs?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5472477.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:52:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvqu7-0001pz-L9; Fri, 10 Feb 2012 13:52:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvqu6-0001pm-T6
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:52:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328881960!12844498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14238 invoked from network); 10 Feb 2012 13:52:40 -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 Feb 2012 13:52:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:52:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 13:52:39 +0000
Message-ID: <1328881958.6133.268.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 10 Feb 2012 13:52:38 +0000
In-Reply-To: <4F351E65.6020604@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
> On 10/02/12 13:35, Ian Campbell wrote:
> > On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> Link a device tree blob (DTB) into the xen image.  This is loaded
> >> immediately after Xen and xen_start() is called with the correct
> >> address in atag_paddr.
> > 
> > Is platform.dtb supposed to be included in this patch/series or is it
> > intended that I should supply it from somewhere? (in which case, how and
> > where etc).
> 
> I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
> 
> Would it be better build the DTB from source included in Xen?

I guess that's what Linux has done but I don't know if we want to
replicate all that and keep syncing etc. On the flip side I suppose it's
currently only a single platform.

Does Linux have an "upstream" for its DTB stuff or is it all done in
tree?

> Or specify the DTB in some other way (makefile variables?)?

A CONFIG_mumble would be a quick and easy thing to do as a placeholder
if nothing else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 13:52:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 13: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.xensource.com>)
	id 1Rvqu7-0001pz-L9; Fri, 10 Feb 2012 13:52:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvqu6-0001pm-T6
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:52:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328881960!12844498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14238 invoked from network); 10 Feb 2012 13:52:40 -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 Feb 2012 13:52:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10622797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 13:52:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 13:52:39 +0000
Message-ID: <1328881958.6133.268.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 10 Feb 2012 13:52:38 +0000
In-Reply-To: <4F351E65.6020604@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
> On 10/02/12 13:35, Ian Campbell wrote:
> > On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> Link a device tree blob (DTB) into the xen image.  This is loaded
> >> immediately after Xen and xen_start() is called with the correct
> >> address in atag_paddr.
> > 
> > Is platform.dtb supposed to be included in this patch/series or is it
> > intended that I should supply it from somewhere? (in which case, how and
> > where etc).
> 
> I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
> 
> Would it be better build the DTB from source included in Xen?

I guess that's what Linux has done but I don't know if we want to
replicate all that and keep syncing etc. On the flip side I suppose it's
currently only a single platform.

Does Linux have an "upstream" for its DTB stuff or is it all done in
tree?

> Or specify the DTB in some other way (makefile variables?)?

A CONFIG_mumble would be a quick and easy thing to do as a placeholder
if nothing else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:08:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvr9M-00025E-7Y; Fri, 10 Feb 2012 14:08:32 +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 1Rvr9K-000259-U8
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:08:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328882863!59619317!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5930 invoked from network); 10 Feb 2012 14:07:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 14:07:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181239442"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:08:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 09:08:06 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AE84RI007923;
	Fri, 10 Feb 2012 06:08:05 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
Date: Fri, 10 Feb 2012 14:08:02 +0000
Message-ID: <1328882882.3480.16.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 11:28 +0000, Stefano Stabellini wrote:
> could you please send patches inline?

I'll see what I can do. :-)

> > diff -r 6efeff914609 hw/pt-graphics.c
> > --- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
> > +++ b/hw/pt-graphics.c	Fri Feb 10 11:04:01 2012 +0000
> > @@ -23,9 +23,9 @@ void intel_pch_init(PCIBus *bus)
> >  {
> >      uint16_t vid, did;
> >      uint8_t  rid;
> > -    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
> > +    struct pci_dev *pci_dev_1f;
> >  
> > -    if ( !gfx_passthru || !pci_dev_1f )
> > +    if ( !gfx_passthru || !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
> >          return;
> 
> I would rather have it as a seprate test after if ( !gfx_passthru ),
> same for the others below

Sure.

> 
> 
> >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> >  
> >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> >  {
> > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > +    struct pci_dev *pci_dev_host_bridge;
> >      assert(pci_dev->devfn == 0x00);
> > -    if ( !igd_passthru ) {
> > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> >          pci_default_write_config(pci_dev, config_addr, val, len);
> >          return;
> >      }
> 
> Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> 
> If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> also remove the assert?

The assert is about pci_dev, but the check is about the return value of
pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
expected relationship between them, it wasn't immediately clear from the
code.  

Are you saying that if the assert passes, that the function will never
return NULL?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:08:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvr9M-00025E-7Y; Fri, 10 Feb 2012 14:08:32 +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 1Rvr9K-000259-U8
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:08:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328882863!59619317!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5930 invoked from network); 10 Feb 2012 14:07:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 14:07:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181239442"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:08:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 09:08:06 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AE84RI007923;
	Fri, 10 Feb 2012 06:08:05 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
Date: Fri, 10 Feb 2012 14:08:02 +0000
Message-ID: <1328882882.3480.16.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 11:28 +0000, Stefano Stabellini wrote:
> could you please send patches inline?

I'll see what I can do. :-)

> > diff -r 6efeff914609 hw/pt-graphics.c
> > --- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
> > +++ b/hw/pt-graphics.c	Fri Feb 10 11:04:01 2012 +0000
> > @@ -23,9 +23,9 @@ void intel_pch_init(PCIBus *bus)
> >  {
> >      uint16_t vid, did;
> >      uint8_t  rid;
> > -    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
> > +    struct pci_dev *pci_dev_1f;
> >  
> > -    if ( !gfx_passthru || !pci_dev_1f )
> > +    if ( !gfx_passthru || !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
> >          return;
> 
> I would rather have it as a seprate test after if ( !gfx_passthru ),
> same for the others below

Sure.

> 
> 
> >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> >  
> >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> >  {
> > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > +    struct pci_dev *pci_dev_host_bridge;
> >      assert(pci_dev->devfn == 0x00);
> > -    if ( !igd_passthru ) {
> > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> >          pci_default_write_config(pci_dev, config_addr, val, len);
> >          return;
> >      }
> 
> Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> 
> If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> also remove the assert?

The assert is about pci_dev, but the check is about the return value of
pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
expected relationship between them, it wasn't immediately clear from the
code.  

Are you saying that if the assert passes, that the function will never
return NULL?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:38:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14: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.xensource.com>)
	id 1Rvrbf-0002ll-FG; Fri, 10 Feb 2012 14:37:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvrbe-0002ld-DI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:37:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328884659!12849165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4914 invoked from network); 10 Feb 2012 14:37:40 -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;
	10 Feb 2012 14:37:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 14:37:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 14:37:39 +0000
Date: Fri, 10 Feb 2012 14:41:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1328882882.3480.16.camel@elijah>
Message-ID: <alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
	<1328882882.3480.16.camel@elijah>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> > >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> > >  
> > >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> > >  {
> > > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > > +    struct pci_dev *pci_dev_host_bridge;
> > >      assert(pci_dev->devfn == 0x00);
> > > -    if ( !igd_passthru ) {
> > > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> > >          pci_default_write_config(pci_dev, config_addr, val, len);
> > >          return;
> > >      }
> > 
> > Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> > 
> > If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> > also remove the assert?
> 
> The assert is about pci_dev, but the check is about the return value of
> pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
> expected relationship between them, it wasn't immediately clear from the
> code.  

I thought you were worried about the BDF being wrong (00:00.0), BDF that
is the same as pci_dev->devfn and already checked by assert.
However now I realize that pt_pci_get_dev could also fail because pcilib
cannot read the host bridge properly so I think that the check makes
sense.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:38:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14: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.xensource.com>)
	id 1Rvrbf-0002ll-FG; Fri, 10 Feb 2012 14:37:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvrbe-0002ld-DI
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:37:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328884659!12849165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4914 invoked from network); 10 Feb 2012 14:37:40 -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;
	10 Feb 2012 14:37:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 14:37:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 14:37:39 +0000
Date: Fri, 10 Feb 2012 14:41:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1328882882.3480.16.camel@elijah>
Message-ID: <alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
	<1328882882.3480.16.camel@elijah>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> > >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> > >  
> > >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> > >  {
> > > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > > +    struct pci_dev *pci_dev_host_bridge;
> > >      assert(pci_dev->devfn == 0x00);
> > > -    if ( !igd_passthru ) {
> > > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> > >          pci_default_write_config(pci_dev, config_addr, val, len);
> > >          return;
> > >      }
> > 
> > Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> > 
> > If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> > also remove the assert?
> 
> The assert is about pci_dev, but the check is about the return value of
> pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
> expected relationship between them, it wasn't immediately clear from the
> code.  

I thought you were worried about the BDF being wrong (00:00.0), BDF that
is the same as pci_dev->devfn and already checked by assert.
However now I realize that pt_pci_get_dev could also fail because pcilib
cannot read the host bridge properly so I think that the check makes
sense.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:41:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvrf5-0002sP-3s; Fri, 10 Feb 2012 14:41:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rvrf3-0002sF-VU
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:41:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328884870!13736153!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22107 invoked from network); 10 Feb 2012 14:41:11 -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;
	10 Feb 2012 14:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181245040"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:41:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 09:41:09 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AEf7pT007968;
	Fri, 10 Feb 2012 06:41:08 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
	<1328882882.3480.16.camel@elijah>
	<alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
Date: Fri, 10 Feb 2012 14:41:06 +0000
Message-ID: <1328884866.3480.19.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 14:41 +0000, Stefano Stabellini wrote:
> On Fri, 10 Feb 2012, George Dunlap wrote:
> > > >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > > > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> > > >  
> > > >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> > > >  {
> > > > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > > > +    struct pci_dev *pci_dev_host_bridge;
> > > >      assert(pci_dev->devfn == 0x00);
> > > > -    if ( !igd_passthru ) {
> > > > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> > > >          pci_default_write_config(pci_dev, config_addr, val, len);
> > > >          return;
> > > >      }
> > > 
> > > Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> > > 
> > > If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> > > also remove the assert?
> > 
> > The assert is about pci_dev, but the check is about the return value of
> > pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
> > expected relationship between them, it wasn't immediately clear from the
> > code.  
> 
> I thought you were worried about the BDF being wrong (00:00.0), BDF that
> is the same as pci_dev->devfn and already checked by assert.
> However now I realize that pt_pci_get_dev could also fail because pcilib
> cannot read the host bridge properly so I think that the check makes
> sense.

OK -- in that case, since the fail path involves calling
pci_default_write_config(), would it make sense to keep both checks in
the same if()?

Or, I could just send the patch which I already have ready, which
retains the current behavior of assuming that pt_pci_get_dev()
succeeds. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:41:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:41:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvrf5-0002sP-3s; Fri, 10 Feb 2012 14:41:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rvrf3-0002sF-VU
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:41:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328884870!13736153!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22107 invoked from network); 10 Feb 2012 14:41:11 -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;
	10 Feb 2012 14:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181245040"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 09:41:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 09:41:09 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1AEf7pT007968;
	Fri, 10 Feb 2012 06:41:08 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
	<1328882882.3480.16.camel@elijah>
	<alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
Date: Fri, 10 Feb 2012 14:41:06 +0000
Message-ID: <1328884866.3480.19.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 14:41 +0000, Stefano Stabellini wrote:
> On Fri, 10 Feb 2012, George Dunlap wrote:
> > > >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > > > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> > > >  
> > > >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> > > >  {
> > > > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > > > +    struct pci_dev *pci_dev_host_bridge;
> > > >      assert(pci_dev->devfn == 0x00);
> > > > -    if ( !igd_passthru ) {
> > > > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> > > >          pci_default_write_config(pci_dev, config_addr, val, len);
> > > >          return;
> > > >      }
> > > 
> > > Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> > > 
> > > If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> > > also remove the assert?
> > 
> > The assert is about pci_dev, but the check is about the return value of
> > pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
> > expected relationship between them, it wasn't immediately clear from the
> > code.  
> 
> I thought you were worried about the BDF being wrong (00:00.0), BDF that
> is the same as pci_dev->devfn and already checked by assert.
> However now I realize that pt_pci_get_dev could also fail because pcilib
> cannot read the host bridge properly so I think that the check makes
> sense.

OK -- in that case, since the fail path involves calling
pci_default_write_config(), would it make sense to keep both checks in
the same if()?

Or, I could just send the patch which I already have ready, which
retains the current behavior of assuming that pt_pci_get_dev()
succeeds. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:41:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvrf8-0002si-Gq; Fri, 10 Feb 2012 14:41:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1Rvrf5-0002sJ-Sz
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:41:20 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328884872!12832517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12803 invoked from network); 10 Feb 2012 14:41:13 -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;
	10 Feb 2012 14:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624177"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 14:41:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 10 Feb 2012
	14:41:13 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Dario Faggioli <raistlin@linux.it>, =?utf-8?B?5p2O5pil5aWH?=
	<yzt356@gmail.com>
Date: Fri, 10 Feb 2012 14:41:04 +0000
Thread-Topic: [Xen-devel] Projects for Google Summer of Code
Thread-Index: Aczn9NmWgWT3adtAQ9iWAMFpeEcsEgADEIgQ
Message-ID: <344C0F67BC927847A2C92F9EE358DB0ECD70DED2D4@LONPMAILBOX01.citrite.net>
References: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
	<1328879201.4351.65.camel@Abyss>
In-Reply-To: <1328879201.4351.65.camel@Abyss>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Projects for Google Summer of Code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

V2Ugd2lsbCBkZWZpbml0ZWx5IGFwcGx5IHRvIGJlIGEgR1NvQyBtZW50b3Jpbmcgb3JnIGFuZCB3
ZSBhcmUgbGlrZWx5IHRvIGdldCBhY2NlcHRlZCAod2UgaGF2ZSBiZWVuIGluIHRoZSBsYXN0IDIg
eWVhcnM7IHRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgd2Ugd29uJ3QgZ2V0IGFjY2VwdGVkIHRoaXMg
eWVhcikuIA0KDQpXZSBkbyBub3QgaGF2ZSBhIHByb2plY3QgbGlzdCB5ZXQuIFdlIGFyZSBzdGFy
dGluZyB0byBicmFpbnN0b3JtLiBJdCBpcyBlbnRpcmVseSBPSyBmb3IgYSBzdHVkZW50IHRvIHBy
b3Bvc2UgYSBwcm9qZWN0ICBpZGVhLiAgT25jZSB3ZSBrbm93IHRoYXQgWGVuIGhhcyBiZWVuIGFj
Y2VwdGVkIGFzIGEgbWVudG9yaW5nIG9yZ2FuaXNhdGlvbiB3ZSB3aWxsIGZvcm0gYSBjb21taXR0
ZWUgdG8gc2VsZWN0IHRoZSBtb3N0IHByb21pc2luZyBwcm9qZWN0IGlkZWFzLiBXZSB3aWxsIGJl
IG11Y2ggbW9yZSBjYXJlZnVsIHdpdGggb3VyIHByb2plY3RzIHRoaXMgeWVhcjogc29tZSBvZiB0
aGUgcHJvamVjdHMgbGFzdCB5ZWFyIHdlcmUgdG9vIGFtYml0aW91cyBmb3Igc3R1ZGVudHMuDQoN
CldhdGNoIHRoZSBibG9nIGFuZCBtYWlsaW5nIGxpc3QuIFlvdSBtYXkgZ2V0IGEgYmV0dGVyIGZl
ZWxpbmcgb2Ygd2hhdCBpcyBpbnRlcmVzdGluZyAoYXNzdW1pbmcgeW91IHdhbnQgdG8gcHJvcG9z
ZSBhIHByb2plY3QgeW91cnNlbHZlcykuIEFsc28gb2YgY291cnNlIGlmIHdlIGtub3cgYSBzdHVk
ZW50IGFuZCBrbm93IHRoYXQgaGUvc2hlIGNhbiBkZWxpdmVyIHRoZSBwcm9qZWN0LCB5b3UgaGF2
ZSBhbiBhZHZhbnlhZ2Ugb3ZlciBzb21lYm9keSB3ZSBuZXZlciBoZWFyZCBvZi4NCg0KSG9wZSB0
aGlzIGhlbHBlZA0KTGFycyANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERh
cmlvIEZhZ2dpb2xpIFttYWlsdG86cmFpc3RsaW5AbGludXguaXRdIA0KU2VudDogMTAgRmVicnVh
cnkgMjAxMiAxMzowNw0KVG86IOadjuaYpeWlhw0KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tOyBMYXJzIEt1cnRoDQpTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gUHJvamVjdHMgZm9y
IEdvb2dsZSBTdW1tZXIgb2YgQ29kZQ0KDQpPbiBUdWUsIDIwMTItMDItMDcgYXQgMTA6MDYgKzA4
MDAsIOadjuaYpeWlhyB3cm90ZToNCj4gSGkgYWxsLA0KPiBJIGhhdmUgbm90aWNlZCBvZiBzb21l
IHByb2plY3RzIGluIEdTb0MgMjAxMSBzdXBwb3J0ZWQgYnkgWGVuLm9yZywgYW5kIA0KPiBJIHdv
dWxkIGxpa2UgdG8ga25vdyBpZiB0aGVyZSB3aWxsIGJlIGFueSBwcm9qZWN0cyBmb3IgR1NvQyAy
MDEyPw0KPg0KVGhlcmUgd2lsbCBtb3N0IGxpa2VseSBiZSBzb21lLi4uIE9yIGF0IGxlYXN0IFhl
bi5vcmcgd2lsbCBwcm9iYWJseSBzdWJtaXQgc29tZSBwcm9qZWN0LCB0aGVuIGl0IGFsbCBkZXBl
bmRzIG9uIHRoZW0gYmVpbmcgYXBwcm92ZWQuIDotKQ0KDQo+IEkgd2FudCB0byBhcHBseSBmb3Ig
YSBwcm9qZWN0IHN1cHBvcnRlZCBieSBYZW4ub3JnIGJlY2F1c2UgSSB1c2UgWGVuIA0KPiBhbmQg
ZG8gcmVzZWFyY2ggb24gaXQgZm9yIHNvbWUgdGltZSBhbmQgSSBoYXZlIGdyZWF0IGludGVyZXN0
IGluIGl0Lg0KPg0KVGhpcyBpcyBhbHdheXMgc29tZXRoaW5nIG5pY2UgdG8gaGVhci4gOi0pDQoN
Cj4gSSB3YW50IHRvIGdldCBzb21lIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaXQsIHRoYW5rIHlv
dS4NCj4gDQpPayB0aGVuLCBJIHRoaW5rIHlvdSBjYW4ga2VlcCBtb25pdG9yaW5nIEdTb0MgV2Vi
c2l0ZSBhbmQgYWxzbyB0aGlzIG1haWxpbmcgbGlzdCwgYXMgSSB0aGluayB1cGRhdGVzIHdpbGwg
YmUgYW5ub3VuY2VkIGhlcmUgd2hlbiB0aGV5IGJlY29tZSBhdmFpbGFibGUuDQoNClJlZ2FyZHMs
DQpEYXJpbw0KLS0NCjw8VGhpcyBoYXBwZW5zIGJlY2F1c2UgSSBjaG9vc2UgaXQgdG8gaGFwcGVu
IT4+IChSYWlzdGxpbiBNYWplcmUpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpEYXJpbyBGYWdnaW9saSwgUGguRCwg
aHR0cDovL3JldGlzLnNzc3VwLml0L3Blb3BsZS9mYWdnaW9saQ0KU2VuaW9yIFNvZnR3YXJlIEVu
Z2luZWVyLCBDaXRyaXggU3lzdGVtcyBSJkQgTHRkLiwgQ2FtYnJpZGdlIChVSykNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:41:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1Rvrf8-0002si-Gq; Fri, 10 Feb 2012 14:41:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth@citrix.com>) id 1Rvrf5-0002sJ-Sz
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:41:20 +0000
X-Env-Sender: lars.kurth@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328884872!12832517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12803 invoked from network); 10 Feb 2012 14:41:13 -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;
	10 Feb 2012 14:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624177"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 14:41:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 10 Feb 2012
	14:41:13 +0000
From: Lars Kurth <lars.kurth@citrix.com>
To: Dario Faggioli <raistlin@linux.it>, =?utf-8?B?5p2O5pil5aWH?=
	<yzt356@gmail.com>
Date: Fri, 10 Feb 2012 14:41:04 +0000
Thread-Topic: [Xen-devel] Projects for Google Summer of Code
Thread-Index: Aczn9NmWgWT3adtAQ9iWAMFpeEcsEgADEIgQ
Message-ID: <344C0F67BC927847A2C92F9EE358DB0ECD70DED2D4@LONPMAILBOX01.citrite.net>
References: <CABpY8MLUcVY-jAf9bQPJBaiJigDQ34TD+gYU9N7Xg=6BpS8Y5Q@mail.gmail.com>
	<1328879201.4351.65.camel@Abyss>
In-Reply-To: <1328879201.4351.65.camel@Abyss>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Projects for Google Summer of Code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

V2Ugd2lsbCBkZWZpbml0ZWx5IGFwcGx5IHRvIGJlIGEgR1NvQyBtZW50b3Jpbmcgb3JnIGFuZCB3
ZSBhcmUgbGlrZWx5IHRvIGdldCBhY2NlcHRlZCAod2UgaGF2ZSBiZWVuIGluIHRoZSBsYXN0IDIg
eWVhcnM7IHRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgd2Ugd29uJ3QgZ2V0IGFjY2VwdGVkIHRoaXMg
eWVhcikuIA0KDQpXZSBkbyBub3QgaGF2ZSBhIHByb2plY3QgbGlzdCB5ZXQuIFdlIGFyZSBzdGFy
dGluZyB0byBicmFpbnN0b3JtLiBJdCBpcyBlbnRpcmVseSBPSyBmb3IgYSBzdHVkZW50IHRvIHBy
b3Bvc2UgYSBwcm9qZWN0ICBpZGVhLiAgT25jZSB3ZSBrbm93IHRoYXQgWGVuIGhhcyBiZWVuIGFj
Y2VwdGVkIGFzIGEgbWVudG9yaW5nIG9yZ2FuaXNhdGlvbiB3ZSB3aWxsIGZvcm0gYSBjb21taXR0
ZWUgdG8gc2VsZWN0IHRoZSBtb3N0IHByb21pc2luZyBwcm9qZWN0IGlkZWFzLiBXZSB3aWxsIGJl
IG11Y2ggbW9yZSBjYXJlZnVsIHdpdGggb3VyIHByb2plY3RzIHRoaXMgeWVhcjogc29tZSBvZiB0
aGUgcHJvamVjdHMgbGFzdCB5ZWFyIHdlcmUgdG9vIGFtYml0aW91cyBmb3Igc3R1ZGVudHMuDQoN
CldhdGNoIHRoZSBibG9nIGFuZCBtYWlsaW5nIGxpc3QuIFlvdSBtYXkgZ2V0IGEgYmV0dGVyIGZl
ZWxpbmcgb2Ygd2hhdCBpcyBpbnRlcmVzdGluZyAoYXNzdW1pbmcgeW91IHdhbnQgdG8gcHJvcG9z
ZSBhIHByb2plY3QgeW91cnNlbHZlcykuIEFsc28gb2YgY291cnNlIGlmIHdlIGtub3cgYSBzdHVk
ZW50IGFuZCBrbm93IHRoYXQgaGUvc2hlIGNhbiBkZWxpdmVyIHRoZSBwcm9qZWN0LCB5b3UgaGF2
ZSBhbiBhZHZhbnlhZ2Ugb3ZlciBzb21lYm9keSB3ZSBuZXZlciBoZWFyZCBvZi4NCg0KSG9wZSB0
aGlzIGhlbHBlZA0KTGFycyANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERh
cmlvIEZhZ2dpb2xpIFttYWlsdG86cmFpc3RsaW5AbGludXguaXRdIA0KU2VudDogMTAgRmVicnVh
cnkgMjAxMiAxMzowNw0KVG86IOadjuaYpeWlhw0KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tOyBMYXJzIEt1cnRoDQpTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gUHJvamVjdHMgZm9y
IEdvb2dsZSBTdW1tZXIgb2YgQ29kZQ0KDQpPbiBUdWUsIDIwMTItMDItMDcgYXQgMTA6MDYgKzA4
MDAsIOadjuaYpeWlhyB3cm90ZToNCj4gSGkgYWxsLA0KPiBJIGhhdmUgbm90aWNlZCBvZiBzb21l
IHByb2plY3RzIGluIEdTb0MgMjAxMSBzdXBwb3J0ZWQgYnkgWGVuLm9yZywgYW5kIA0KPiBJIHdv
dWxkIGxpa2UgdG8ga25vdyBpZiB0aGVyZSB3aWxsIGJlIGFueSBwcm9qZWN0cyBmb3IgR1NvQyAy
MDEyPw0KPg0KVGhlcmUgd2lsbCBtb3N0IGxpa2VseSBiZSBzb21lLi4uIE9yIGF0IGxlYXN0IFhl
bi5vcmcgd2lsbCBwcm9iYWJseSBzdWJtaXQgc29tZSBwcm9qZWN0LCB0aGVuIGl0IGFsbCBkZXBl
bmRzIG9uIHRoZW0gYmVpbmcgYXBwcm92ZWQuIDotKQ0KDQo+IEkgd2FudCB0byBhcHBseSBmb3Ig
YSBwcm9qZWN0IHN1cHBvcnRlZCBieSBYZW4ub3JnIGJlY2F1c2UgSSB1c2UgWGVuIA0KPiBhbmQg
ZG8gcmVzZWFyY2ggb24gaXQgZm9yIHNvbWUgdGltZSBhbmQgSSBoYXZlIGdyZWF0IGludGVyZXN0
IGluIGl0Lg0KPg0KVGhpcyBpcyBhbHdheXMgc29tZXRoaW5nIG5pY2UgdG8gaGVhci4gOi0pDQoN
Cj4gSSB3YW50IHRvIGdldCBzb21lIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaXQsIHRoYW5rIHlv
dS4NCj4gDQpPayB0aGVuLCBJIHRoaW5rIHlvdSBjYW4ga2VlcCBtb25pdG9yaW5nIEdTb0MgV2Vi
c2l0ZSBhbmQgYWxzbyB0aGlzIG1haWxpbmcgbGlzdCwgYXMgSSB0aGluayB1cGRhdGVzIHdpbGwg
YmUgYW5ub3VuY2VkIGhlcmUgd2hlbiB0aGV5IGJlY29tZSBhdmFpbGFibGUuDQoNClJlZ2FyZHMs
DQpEYXJpbw0KLS0NCjw8VGhpcyBoYXBwZW5zIGJlY2F1c2UgSSBjaG9vc2UgaXQgdG8gaGFwcGVu
IT4+IChSYWlzdGxpbiBNYWplcmUpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpEYXJpbyBGYWdnaW9saSwgUGguRCwg
aHR0cDovL3JldGlzLnNzc3VwLml0L3Blb3BsZS9mYWdnaW9saQ0KU2VuaW9yIFNvZnR3YXJlIEVu
Z2luZWVyLCBDaXRyaXggU3lzdGVtcyBSJkQgTHRkLiwgQ2FtYnJpZGdlIChVSykNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvrkZ-0003J9-VV; Fri, 10 Feb 2012 14:46:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvrkY-0003ID-Hp
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:46:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328885211!4472274!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MDc5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14639 invoked from network); 10 Feb 2012 14:46:52 -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; 10 Feb 2012 14:46:52 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q1AEknP7023019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 14:46:50 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
	q1AEknbh018456
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 14:46: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
	q1AEkmGs017950; Fri, 10 Feb 2012 08:46:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 06:46:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 36A0041723; Fri, 10 Feb 2012 09:43:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 09:43:52 -0500
Message-Id: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F352DDA.012C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] vcpu hotplug fix for v3.3-rc3 (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When playing with xl/xm vcpu-set I found out that Linux 3.3 has a bunch of problems.
Some of them were in generic code base (patches for that are queued up by Greg KH),
and some were in the Xen base. Previously I had posted:

    xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
    xen/bootup: During bootup suppress XENBUS: Unable to read cpu state

and this is meant to be on top of those to make vCPU hotplugging work properly
with 3.3 kernel. Some of those should be back-ported to 3.0 but I am not sure
which ones (and if there are other ones as well) so won't do that until I get some time
to do a proper testing of them on v3.0.

If you want to full kitchensink, please see #testing branch. If you just want
to see those patches above (and others queued up for 3.3-rc3), take a look at
#stable/for-linus-fixes-3.3 in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvrkZ-0003J9-VV; Fri, 10 Feb 2012 14:46:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvrkY-0003ID-Hp
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:46:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328885211!4472274!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MDc5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14639 invoked from network); 10 Feb 2012 14:46:52 -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; 10 Feb 2012 14:46:52 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q1AEknP7023019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 14:46:50 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
	q1AEknbh018456
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 14:46: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
	q1AEkmGs017950; Fri, 10 Feb 2012 08:46:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 06:46:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 36A0041723; Fri, 10 Feb 2012 09:43:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 09:43:52 -0500
Message-Id: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F352DDA.012C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] vcpu hotplug fix for v3.3-rc3 (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When playing with xl/xm vcpu-set I found out that Linux 3.3 has a bunch of problems.
Some of them were in generic code base (patches for that are queued up by Greg KH),
and some were in the Xen base. Previously I had posted:

    xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
    xen/bootup: During bootup suppress XENBUS: Unable to read cpu state

and this is meant to be on top of those to make vCPU hotplugging work properly
with 3.3 kernel. Some of those should be back-ported to 3.0 but I am not sure
which ones (and if there are other ones as well) so won't do that until I get some time
to do a proper testing of them on v3.0.

If you want to full kitchensink, please see #testing branch. If you just want
to see those patches above (and others queued up for 3.3-rc3), take a look at
#stable/for-linus-fixes-3.3 in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvrkY-0003Iw-Is; Fri, 10 Feb 2012 14:46: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 1RvrkX-0003If-PL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:46:57 +0000
Received: from [85.158.143.35:22538] by server-1.bemta-4.messagelabs.com id
	CC/18-04451-0ED253F4; Fri, 10 Feb 2012 14:46:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328885215!2320414!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5587 invoked from network); 10 Feb 2012 14:46:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 14:46:56 -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 q1AEkqT6009020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 14:46: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
	q1AEkpfn024457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 14:46:52 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
	q1AEkpYP017983; Fri, 10 Feb 2012 08:46:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 06:46:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E182F41723; Fri, 10 Feb 2012 09:43:58 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 09:43:53 -0500
Message-Id: <1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
References: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F352DDE.010E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/cpu: Make VCPU hotplug code online CPUs
	properly.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Offlining CPUs works. Onlining does not work anymore and it looks
like we were missing a cpu_up() call in the hotplug bring up path.

When the vCPUs are initialized, if they are onlined or never had
been in use (so maxcpus > vcpus) the vCPUs are in xen_play_dead
having called VCPUOP_down and are not running. When a vCPU is
onlined, the bootup (or any other currently running CPU) is suppose
to call VCPUOP_up on the vCPU that is not running and make the
vCPU unhinge itself out of the xen_play_dead and continue in
cpu_idle. We did not make the hypercall on onlining, nor did we
recreate the timer, spinlocks, ipi interrupts so the vCPU never
was onlined. This patch fixes it by calling cpu_on() and we
also make the code more readable.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/cpu_hotplug.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..df80af8 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -8,18 +8,20 @@
 
 static void enable_hotplug_cpu(int cpu)
 {
-	if (!cpu_present(cpu))
+	if (!cpu_present(cpu)) {
 		arch_register_cpu(cpu);
-
-	set_cpu_present(cpu, true);
+		set_cpu_present(cpu, true);
+		(void)cpu_up(cpu);
+	}
 }
 
 static void disable_hotplug_cpu(int cpu)
 {
-	if (cpu_present(cpu))
+	if (cpu_present(cpu)) {
+		(void)cpu_down(cpu);
+		set_cpu_present(cpu, false);
 		arch_unregister_cpu(cpu);
-
-	set_cpu_present(cpu, false);
+	}
 }
 
 static int vcpu_online(unsigned int cpu)
@@ -53,7 +55,6 @@ static void vcpu_hotplug(unsigned int cpu)
 		enable_hotplug_cpu(cpu);
 		break;
 	case 0:
-		(void)cpu_down(cpu);
 		disable_hotplug_cpu(cpu);
 		break;
 	default:
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 14:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 14:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvrkY-0003Iw-Is; Fri, 10 Feb 2012 14:46: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 1RvrkX-0003If-PL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:46:57 +0000
Received: from [85.158.143.35:22538] by server-1.bemta-4.messagelabs.com id
	CC/18-04451-0ED253F4; Fri, 10 Feb 2012 14:46:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1328885215!2320414!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5587 invoked from network); 10 Feb 2012 14:46:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 14:46:56 -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 q1AEkqT6009020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 14:46: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
	q1AEkpfn024457
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 14:46:52 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
	q1AEkpYP017983; Fri, 10 Feb 2012 08:46:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 06:46:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E182F41723; Fri, 10 Feb 2012 09:43:58 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 09:43:53 -0500
Message-Id: <1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
References: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F352DDE.010E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/cpu: Make VCPU hotplug code online CPUs
	properly.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Offlining CPUs works. Onlining does not work anymore and it looks
like we were missing a cpu_up() call in the hotplug bring up path.

When the vCPUs are initialized, if they are onlined or never had
been in use (so maxcpus > vcpus) the vCPUs are in xen_play_dead
having called VCPUOP_down and are not running. When a vCPU is
onlined, the bootup (or any other currently running CPU) is suppose
to call VCPUOP_up on the vCPU that is not running and make the
vCPU unhinge itself out of the xen_play_dead and continue in
cpu_idle. We did not make the hypercall on onlining, nor did we
recreate the timer, spinlocks, ipi interrupts so the vCPU never
was onlined. This patch fixes it by calling cpu_on() and we
also make the code more readable.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/cpu_hotplug.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..df80af8 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -8,18 +8,20 @@
 
 static void enable_hotplug_cpu(int cpu)
 {
-	if (!cpu_present(cpu))
+	if (!cpu_present(cpu)) {
 		arch_register_cpu(cpu);
-
-	set_cpu_present(cpu, true);
+		set_cpu_present(cpu, true);
+		(void)cpu_up(cpu);
+	}
 }
 
 static void disable_hotplug_cpu(int cpu)
 {
-	if (cpu_present(cpu))
+	if (cpu_present(cpu)) {
+		(void)cpu_down(cpu);
+		set_cpu_present(cpu, false);
 		arch_unregister_cpu(cpu);
-
-	set_cpu_present(cpu, false);
+	}
 }
 
 static int vcpu_online(unsigned int cpu)
@@ -53,7 +55,6 @@ static void vcpu_hotplug(unsigned int cpu)
 		enable_hotplug_cpu(cpu);
 		break;
 	case 0:
-		(void)cpu_down(cpu);
 		disable_hotplug_cpu(cpu);
 		break;
 	default:
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:01:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvry4-0003zJ-8R; Fri, 10 Feb 2012 15:00:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvry3-0003zD-B1
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:00:55 +0000
Received: from [85.158.139.83:54248] by server-11.bemta-5.messagelabs.com id
	BB/2F-13907-621353F4; Fri, 10 Feb 2012 15:00:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328886053!13925310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1907 invoked from network); 10 Feb 2012 15:00:53 -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;
	10 Feb 2012 15:00:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 14:59:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 14:59:24 +0000
Date: Fri, 10 Feb 2012 15:02:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1328884866.3480.19.camel@elijah>
Message-ID: <alpine.DEB.2.00.1202101457230.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
	<1328882882.3480.16.camel@elijah>
	<alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
	<1328884866.3480.19.camel@elijah>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> On Fri, 2012-02-10 at 14:41 +0000, Stefano Stabellini wrote:
> > On Fri, 10 Feb 2012, George Dunlap wrote:
> > > > >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > > > > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> > > > >  
> > > > >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> > > > >  {
> > > > > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > > > > +    struct pci_dev *pci_dev_host_bridge;
> > > > >      assert(pci_dev->devfn == 0x00);
> > > > > -    if ( !igd_passthru ) {
> > > > > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> > > > >          pci_default_write_config(pci_dev, config_addr, val, len);
> > > > >          return;
> > > > >      }
> > > > 
> > > > Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> > > > 
> > > > If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> > > > also remove the assert?
> > > 
> > > The assert is about pci_dev, but the check is about the return value of
> > > pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
> > > expected relationship between them, it wasn't immediately clear from the
> > > code.  
> > 
> > I thought you were worried about the BDF being wrong (00:00.0), BDF that
> > is the same as pci_dev->devfn and already checked by assert.
> > However now I realize that pt_pci_get_dev could also fail because pcilib
> > cannot read the host bridge properly so I think that the check makes
> > sense.
> 
> OK -- in that case, since the fail path involves calling
> pci_default_write_config(), would it make sense to keep both checks in
> the same if()?
> 
> Or, I could just send the patch which I already have ready, which
> retains the current behavior of assuming that pt_pci_get_dev()
> succeeds. :-)

Considering that pci_dev_host_bridge is only used in a very specific set
of cases, we could call pt_pci_get_dev and check for the validity of
pci_dev_host_bridge only in case we need to use it.
So it is probably a good idea to move the check below in case
config_addr == 0x58, print a message and return an error.
Same thing for igd_pci_read.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:01:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvry4-0003zJ-8R; Fri, 10 Feb 2012 15:00:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvry3-0003zD-B1
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:00:55 +0000
Received: from [85.158.139.83:54248] by server-11.bemta-5.messagelabs.com id
	BB/2F-13907-621353F4; Fri, 10 Feb 2012 15:00:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328886053!13925310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1907 invoked from network); 10 Feb 2012 15:00:53 -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;
	10 Feb 2012 15:00:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 14:59:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 14:59:24 +0000
Date: Fri, 10 Feb 2012 15:02:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1328884866.3480.19.camel@elijah>
Message-ID: <alpine.DEB.2.00.1202101457230.7456@kaball-desktop>
References: <CAFLBxZa=NKgZd+RNTND124LHrYkO1Ej=gYmm3Dxa=cux++h0FA@mail.gmail.com>
	<alpine.DEB.2.00.1202101123160.7456@kaball-desktop>
	<1328882882.3480.16.camel@elijah>
	<alpine.DEB.2.00.1202101422150.7456@kaball-desktop>
	<1328884866.3480.19.camel@elijah>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> On Fri, 2012-02-10 at 14:41 +0000, Stefano Stabellini wrote:
> > On Fri, 10 Feb 2012, George Dunlap wrote:
> > > > >      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> > > > > @@ -39,9 +39,9 @@ void intel_pch_init(PCIBus *bus)
> > > > >  
> > > > >  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
> > > > >  {
> > > > > -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > > > > +    struct pci_dev *pci_dev_host_bridge;
> > > > >      assert(pci_dev->devfn == 0x00);
> > > > > -    if ( !igd_passthru ) {
> > > > > +    if ( !igd_passthru || !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0))) {
> > > > >          pci_default_write_config(pci_dev, config_addr, val, len);
> > > > >          return;
> > > > >      }
> > > > 
> > > > Why are you adding this test (!(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) ?
> > > > 
> > > > If you are worried that pci_dev_host_bridge could be NULL, shouldn't you
> > > > also remove the assert?
> > > 
> > > The assert is about pci_dev, but the check is about the return value of
> > > pci_host_bridge() (to which pci_dev_host_bridge is set).  If there's an
> > > expected relationship between them, it wasn't immediately clear from the
> > > code.  
> > 
> > I thought you were worried about the BDF being wrong (00:00.0), BDF that
> > is the same as pci_dev->devfn and already checked by assert.
> > However now I realize that pt_pci_get_dev could also fail because pcilib
> > cannot read the host bridge properly so I think that the check makes
> > sense.
> 
> OK -- in that case, since the fail path involves calling
> pci_default_write_config(), would it make sense to keep both checks in
> the same if()?
> 
> Or, I could just send the patch which I already have ready, which
> retains the current behavior of assuming that pt_pci_get_dev()
> succeeds. :-)

Considering that pci_dev_host_bridge is only used in a very specific set
of cases, we could call pt_pci_get_dev and check for the validity of
pci_dev_host_bridge only in case we need to use it.
So it is probably a good idea to move the check below in case
config_addr == 0x58, print a message and return an error.
Same thing for igd_pci_read.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:04:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs0x-000479-RX; Fri, 10 Feb 2012 15:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvs0w-00046t-BL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:03:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328886228!14172917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9549 invoked from network); 10 Feb 2012 15:03:48 -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 Feb 2012 15:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:03:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 15:03:48 +0000
Message-ID: <1328886226.6133.271.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 10 Feb 2012 15:03:46 +0000
In-Reply-To: <1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
References: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
	<1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/cpu: Make VCPU hotplug code online CPUs
 properly.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 14:43 +0000, Konrad Rzeszutek Wilk wrote:
> Offlining CPUs works. Onlining does not work anymore and it looks
> like we were missing a cpu_up() call in the hotplug bring up path.

Wasn't this a deliberate decision as part of the pvops upstreaming to be
consistent with native cpu hotplug? After hotplugging a CPU
administrator action is needed to actually online it.

http://xen.1045712.n5.nabble.com/cpu-down-but-no-cpu-up-in-drivers-xen-cpu-hotplug-c-td2545244.html

The fix is to add a udev rule:
http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:04:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs0x-000479-RX; Fri, 10 Feb 2012 15:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rvs0w-00046t-BL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:03:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328886228!14172917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9549 invoked from network); 10 Feb 2012 15:03:48 -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 Feb 2012 15:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10624809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:03:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 15:03:48 +0000
Message-ID: <1328886226.6133.271.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 10 Feb 2012 15:03:46 +0000
In-Reply-To: <1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
References: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
	<1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/cpu: Make VCPU hotplug code online CPUs
 properly.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 14:43 +0000, Konrad Rzeszutek Wilk wrote:
> Offlining CPUs works. Onlining does not work anymore and it looks
> like we were missing a cpu_up() call in the hotplug bring up path.

Wasn't this a deliberate decision as part of the pvops upstreaming to be
consistent with native cpu hotplug? After hotplugging a CPU
administrator action is needed to actually online it.

http://xen.1045712.n5.nabble.com/cpu-down-but-no-cpu-up-in-drivers-xen-cpu-hotplug-c-td2545244.html

The fix is to add a udev rule:
http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4u-0004LJ-AS; Fri, 10 Feb 2012 15:08:00 +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 1Rvs4s-0004Kl-Ce
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:58 +0000
Received: from [85.158.139.83:45870] by server-2.bemta-5.messagelabs.com id
	E7/FF-20725-DC2353F4; Fri, 10 Feb 2012 15:07:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328886474!14500770!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5620 invoked from network); 10 Feb 2012 15:07:55 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.141)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:55 -0000
Received: from mail89-db3-R.bigfish.com (10.3.81.229) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:54 +0000
Received: from mail89-db3 (localhost [127.0.0.1])	by mail89-db3-R.bigfish.com
	(Postfix) with ESMTP id 09E343801F4;
	Fri, 10 Feb 2012 15:07:54 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail89-db3 (localhost.localdomain [127.0.0.1]) by mail89-db3
	(MessageSwitch) id 1328886471659611_13625;
	Fri, 10 Feb 2012 15:07:51 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.235])	by
	mail89-db3.bigfish.com (Postfix) with ESMTP id 928633E004A;
	Fri, 10 Feb 2012 15:07:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:50 +0000
X-WSS-ID: 0LZ6NCX-02-GCS-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 2845DC82EB;	Fri, 10 Feb 2012 09:07:45 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 10 Feb 2012 09:08:06 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:47 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id CAEC849C65C; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id B9464594882; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9cf24ad61936e5d9a6acac9de1dc1fac6694c31e
Message-ID: <9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:06 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 6 V5] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885349 -3600
# Node ID 9cf24ad61936e5d9a6acac9de1dc1fac6694c31e
# Parent  593deed8f62d73dc617f6dd0a95abd05755d002e
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
guest space. Hypervisor needs this vector to inject msi into guest after
write PPR log entry into guest buffer.

iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to machine
bdf. IOMMU emulator receives iommu cmd from guest OS and then forwards them
to host iommu. But virtual device id in cmds from guest must be converted
into physical id before sending them to real hardware.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 10 15:49:09 2012 +0100
@@ -48,14 +48,31 @@
         (reg)->hi = (val) >> 32; \
     } while (0)
 
-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;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->gbdf == guest_bdf) && (pdev->gseg == guest_seg) )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
-static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_seg,
+                          uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, machine_seg, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct doma
     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]));
     iommu_set_devid_to_cmd(&entry[0], gdev_id);
 
     memcpy(log, entry, sizeof(ppr_entry_t));
@@ -256,7 +273,7 @@ void guest_iommu_add_event_log(struct do
     log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
 
     /* re-write physical device id into virtual device id */
-    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    dev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
     iommu_set_devid_to_cmd(&entry[0], dev_id);
     memcpy(log, entry, sizeof(event_entry_t));
 
@@ -278,7 +295,7 @@ static int do_complete_ppr_request(struc
     uint16_t dev_id;
     struct amd_iommu *iommu;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
     iommu = find_iommu_for_device(0, dev_id);
 
     if ( !iommu )
@@ -330,7 +347,7 @@ static int do_invalidate_iotlb_pages(str
     struct amd_iommu *iommu;
     uint16_t dev_id;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
 
     iommu = find_iommu_for_device(0, dev_id);
     if ( !iommu )
@@ -409,7 +426,7 @@ static int do_invalidate_dte(struct doma
 
     g_iommu = domain_iommu(d);
     gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = machine_bdf(d, gbdf);
+    mbdf = machine_bdf(d, 0, gbdf);
 
     /* Guest can only update DTEs for its passthru devices */
     if ( mbdf == 0 || gbdf == 0 )
@@ -916,3 +933,45 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() || !iommu_enabled || !iommuv2_enabled )
+        return ret;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gseg = gseg;
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/drivers/passthrough/iommu.c	Fri Feb 10 15:49:09 2012 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
+                                     guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_seg,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+
     default:
         ret = -ENOSYS;
         break;
diff -r 593deed8f62d -r 9cf24ad61936 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/include/public/domctl.h	Fri Feb 10 15:49:09 2012 +0100
@@ -871,6 +871,31 @@ struct xen_domctl_set_access_required {
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
 
+/* 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;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind {
+            uint16_t            g_seg;
+            uint16_t            g_bdf;
+            uint16_t            m_seg;
+            uint16_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -936,6 +961,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_guest_iommu_op                67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -984,6 +1010,7 @@ struct xen_domctl {
         struct xen_domctl_debug_op          debug_op;
         struct xen_domctl_mem_event_op      mem_event_op;
         struct xen_domctl_mem_sharing_op    mem_sharing_op;
+        struct xen_domctl_guest_iommu_op    guest_iommu_op;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
         struct xen_domctl_vcpuextstate      vcpuextstate;
diff -r 593deed8f62d -r 9cf24ad61936 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/include/xen/iommu.h	Fri Feb 10 15:49:09 2012 +0100
@@ -164,6 +164,12 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+/* Only used by AMD IOMMU so far */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf, 
+                   uint16_t mseg, uint16_t mbdf);
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r 593deed8f62d -r 9cf24ad61936 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/include/xen/pci.h	Fri Feb 10 15:49:09 2012 +0100
@@ -62,6 +62,11 @@ struct pci_dev {
     const u16 seg;
     const u8 bus;
     const u8 devfn;
+
+    /* Used by iommu to represent virtual seg and bdf value in guest space */
+    u16 gseg;
+    u16 gbdf;
+
     struct pci_dev_info info;
     struct arch_pci_dev arch;
     u64 vf_rlen[6];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4u-0004LJ-AS; Fri, 10 Feb 2012 15:08:00 +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 1Rvs4s-0004Kl-Ce
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:58 +0000
Received: from [85.158.139.83:45870] by server-2.bemta-5.messagelabs.com id
	E7/FF-20725-DC2353F4; Fri, 10 Feb 2012 15:07:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328886474!14500770!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5620 invoked from network); 10 Feb 2012 15:07:55 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.141)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:55 -0000
Received: from mail89-db3-R.bigfish.com (10.3.81.229) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:54 +0000
Received: from mail89-db3 (localhost [127.0.0.1])	by mail89-db3-R.bigfish.com
	(Postfix) with ESMTP id 09E343801F4;
	Fri, 10 Feb 2012 15:07:54 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail89-db3 (localhost.localdomain [127.0.0.1]) by mail89-db3
	(MessageSwitch) id 1328886471659611_13625;
	Fri, 10 Feb 2012 15:07:51 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.235])	by
	mail89-db3.bigfish.com (Postfix) with ESMTP id 928633E004A;
	Fri, 10 Feb 2012 15:07:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:50 +0000
X-WSS-ID: 0LZ6NCX-02-GCS-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 2845DC82EB;	Fri, 10 Feb 2012 09:07:45 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 10 Feb 2012 09:08:06 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:47 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id CAEC849C65C; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id B9464594882; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9cf24ad61936e5d9a6acac9de1dc1fac6694c31e
Message-ID: <9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:06 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 6 V5] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885349 -3600
# Node ID 9cf24ad61936e5d9a6acac9de1dc1fac6694c31e
# Parent  593deed8f62d73dc617f6dd0a95abd05755d002e
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
guest space. Hypervisor needs this vector to inject msi into guest after
write PPR log entry into guest buffer.

iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to machine
bdf. IOMMU emulator receives iommu cmd from guest OS and then forwards them
to host iommu. But virtual device id in cmds from guest must be converted
into physical id before sending them to real hardware.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Feb 10 15:49:09 2012 +0100
@@ -48,14 +48,31 @@
         (reg)->hi = (val) >> 32; \
     } while (0)
 
-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;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->gbdf == guest_bdf) && (pdev->gseg == guest_seg) )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
-static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_seg,
+                          uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, machine_seg, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct doma
     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]));
     iommu_set_devid_to_cmd(&entry[0], gdev_id);
 
     memcpy(log, entry, sizeof(ppr_entry_t));
@@ -256,7 +273,7 @@ void guest_iommu_add_event_log(struct do
     log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
 
     /* re-write physical device id into virtual device id */
-    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    dev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
     iommu_set_devid_to_cmd(&entry[0], dev_id);
     memcpy(log, entry, sizeof(event_entry_t));
 
@@ -278,7 +295,7 @@ static int do_complete_ppr_request(struc
     uint16_t dev_id;
     struct amd_iommu *iommu;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
     iommu = find_iommu_for_device(0, dev_id);
 
     if ( !iommu )
@@ -330,7 +347,7 @@ static int do_invalidate_iotlb_pages(str
     struct amd_iommu *iommu;
     uint16_t dev_id;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
 
     iommu = find_iommu_for_device(0, dev_id);
     if ( !iommu )
@@ -409,7 +426,7 @@ static int do_invalidate_dte(struct doma
 
     g_iommu = domain_iommu(d);
     gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = machine_bdf(d, gbdf);
+    mbdf = machine_bdf(d, 0, gbdf);
 
     /* Guest can only update DTEs for its passthru devices */
     if ( mbdf == 0 || gbdf == 0 )
@@ -916,3 +933,45 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() || !iommu_enabled || !iommuv2_enabled )
+        return ret;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gseg = gseg;
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/drivers/passthrough/iommu.c	Fri Feb 10 15:49:09 2012 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
+                                     guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_seg,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+
     default:
         ret = -ENOSYS;
         break;
diff -r 593deed8f62d -r 9cf24ad61936 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/include/public/domctl.h	Fri Feb 10 15:49:09 2012 +0100
@@ -871,6 +871,31 @@ struct xen_domctl_set_access_required {
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
 
+/* 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;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind {
+            uint16_t            g_seg;
+            uint16_t            g_bdf;
+            uint16_t            m_seg;
+            uint16_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -936,6 +961,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_guest_iommu_op                67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -984,6 +1010,7 @@ struct xen_domctl {
         struct xen_domctl_debug_op          debug_op;
         struct xen_domctl_mem_event_op      mem_event_op;
         struct xen_domctl_mem_sharing_op    mem_sharing_op;
+        struct xen_domctl_guest_iommu_op    guest_iommu_op;
 #if defined(__i386__) || defined(__x86_64__)
         struct xen_domctl_cpuid             cpuid;
         struct xen_domctl_vcpuextstate      vcpuextstate;
diff -r 593deed8f62d -r 9cf24ad61936 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/include/xen/iommu.h	Fri Feb 10 15:49:09 2012 +0100
@@ -164,6 +164,12 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+/* Only used by AMD IOMMU so far */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf, 
+                   uint16_t mseg, uint16_t mbdf);
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r 593deed8f62d -r 9cf24ad61936 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Thu Feb 09 06:09:17 2012 -0800
+++ b/xen/include/xen/pci.h	Fri Feb 10 15:49:09 2012 +0100
@@ -62,6 +62,11 @@ struct pci_dev {
     const u16 seg;
     const u8 bus;
     const u8 devfn;
+
+    /* Used by iommu to represent virtual seg and bdf value in guest space */
+    u16 gseg;
+    u16 gbdf;
+
     struct pci_dev_info info;
     struct arch_pci_dev arch;
     u64 vf_rlen[6];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4u-0004LV-NT; Fri, 10 Feb 2012 15:08:00 +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 1Rvs4t-0004Kj-DH
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:59 +0000
Received: from [85.158.139.83:45987] by server-12.bemta-5.messagelabs.com id
	1A/98-30830-FC2353F4; Fri, 10 Feb 2012 15:07:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328886476!13957904!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30137 invoked from network); 10 Feb 2012 15:07:57 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.141)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:57 -0000
Received: from mail49-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:56 +0000
Received: from mail49-db3 (localhost [127.0.0.1])	by mail49-db3-R.bigfish.com
	(Postfix) with ESMTP id B21B41006C1;
	Fri, 10 Feb 2012 15:07:55 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3
	(MessageSwitch) id 1328886473409915_8913;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.250])	by
	mail49-db3.bigfish.com (Postfix) with ESMTP id 5D5C138004A;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:51 +0000
X-WSS-ID: 0LZ6NCZ-01-1VR-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 21C321028360;	Fri, 10 Feb 2012 09:07:47 -0600 (CST)
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, 10 Feb 2012 09:08:06 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:48 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0A24849C660; Fri, 10 Feb 2012
	15:07:38 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EE5E4594885; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: db10bcca843c65260426800f9e05da8359faf439
Message-ID: <db10bcca843c65260426.1328886429@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:09 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 6 V5] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885358 -3600
# Node ID db10bcca843c65260426800f9e05da8359faf439
# Parent  16974b6159e13262126ad1e719727592184e5bea
libxc: add wrappers for new hypercalls
Please see patch 1 for hypercall description.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 16974b6159e1 -r db10bcca843c tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Feb 10 15:49:17 2012 +0100
+++ b/tools/libxc/xc_domain.c	Fri Feb 10 15:49:18 2012 +0100
@@ -1352,6 +1352,59 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+    uint32_t domid,
+    uint16_t gseg,
+    uint16_t gbdf,
+    uint16_t mseg,
+    uint16_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_seg = gseg;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_seg = mseg;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r 16974b6159e1 -r db10bcca843c tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Feb 10 15:49:17 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Feb 10 15:49:18 2012 +0100
@@ -1725,6 +1725,21 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint16_t gseg,
+                          uint16_t gbdf,
+                          uint16_t mseg, 
+                          uint16_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4u-0004LV-NT; Fri, 10 Feb 2012 15:08:00 +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 1Rvs4t-0004Kj-DH
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:59 +0000
Received: from [85.158.139.83:45987] by server-12.bemta-5.messagelabs.com id
	1A/98-30830-FC2353F4; Fri, 10 Feb 2012 15:07:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328886476!13957904!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30137 invoked from network); 10 Feb 2012 15:07:57 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.141)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:57 -0000
Received: from mail49-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:56 +0000
Received: from mail49-db3 (localhost [127.0.0.1])	by mail49-db3-R.bigfish.com
	(Postfix) with ESMTP id B21B41006C1;
	Fri, 10 Feb 2012 15:07:55 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3
	(MessageSwitch) id 1328886473409915_8913;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.250])	by
	mail49-db3.bigfish.com (Postfix) with ESMTP id 5D5C138004A;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:51 +0000
X-WSS-ID: 0LZ6NCZ-01-1VR-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 21C321028360;	Fri, 10 Feb 2012 09:07:47 -0600 (CST)
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, 10 Feb 2012 09:08:06 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:48 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0A24849C660; Fri, 10 Feb 2012
	15:07:38 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EE5E4594885; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: db10bcca843c65260426800f9e05da8359faf439
Message-ID: <db10bcca843c65260426.1328886429@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:09 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 6 V5] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885358 -3600
# Node ID db10bcca843c65260426800f9e05da8359faf439
# Parent  16974b6159e13262126ad1e719727592184e5bea
libxc: add wrappers for new hypercalls
Please see patch 1 for hypercall description.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 16974b6159e1 -r db10bcca843c tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Feb 10 15:49:17 2012 +0100
+++ b/tools/libxc/xc_domain.c	Fri Feb 10 15:49:18 2012 +0100
@@ -1352,6 +1352,59 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+    uint32_t domid,
+    uint16_t gseg,
+    uint16_t gbdf,
+    uint16_t mseg,
+    uint16_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_seg = gseg;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_seg = mseg;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r 16974b6159e1 -r db10bcca843c tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Feb 10 15:49:17 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Feb 10 15:49:18 2012 +0100
@@ -1725,6 +1725,21 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint16_t gseg,
+                          uint16_t gbdf,
+                          uint16_t mseg, 
+                          uint16_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4q-0004Kb-Gu; Fri, 10 Feb 2012 15:07:56 +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 1Rvs4p-0004KP-2k
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:55 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328886435!51934845!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28047 invoked from network); 10 Feb 2012 15:07:15 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.144)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:15 -0000
Received: from mail13-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:53 +0000
Received: from mail13-db3 (localhost [127.0.0.1])	by mail13-db3-R.bigfish.com
	(Postfix) with ESMTP id 6990440732;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail13-db3 (localhost.localdomain [127.0.0.1]) by mail13-db3
	(MessageSwitch) id 1328886470377849_3320;
	Fri, 10 Feb 2012 15:07:50 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.251])	by
	mail13-db3.bigfish.com (Postfix) with ESMTP id 4BA63260048;
	Fri, 10 Feb 2012 15:07:50 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:48 +0000
X-WSS-ID: 0LZ6NCV-02-GCQ-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 280DDC82ED;	Fri, 10 Feb 2012 09:07:42 -0600 (CST)
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, 10 Feb 2012 09:08:03 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:45 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DB48F49C65D; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id CBC8C594883; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3c47f70c84e23b96e766c062a4bbae5bcf4f6dbe
Message-ID: <3c47f70c84e23b96e766.1328886427@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:07 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 6 V5] amd iommu: Add a hypercall for
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885355 -3600
# Node ID 3c47f70c84e23b96e766c062a4bbae5bcf4f6dbe
# Parent  9cf24ad61936e5d9a6acac9de1dc1fac6694c31e
amd iommu: Add a hypercall for hvmloader.
IOMMU MMIO base address is dynamically allocated by firmware.
This patch allows hvmloader to notify hypervisor where the
iommu mmio pages are.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 9cf24ad61936 -r 3c47f70c84e2 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Feb 10 15:49:09 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Feb 10 15:49:15 2012 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -3775,6 +3776,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 ) 
diff -r 9cf24ad61936 -r 3c47f70c84e2 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Fri Feb 10 15:49:09 2012 +0100
+++ b/xen/include/public/hvm/params.h	Fri Feb 10 15:49:15 2012 +0100
@@ -141,7 +141,8 @@
 
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
+#define HVM_PARAM_IOMMU_BASE   27
 
-#define HVM_NR_PARAMS          27
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4q-0004Kb-Gu; Fri, 10 Feb 2012 15:07:56 +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 1Rvs4p-0004KP-2k
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:55 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328886435!51934845!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28047 invoked from network); 10 Feb 2012 15:07:15 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.144)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:15 -0000
Received: from mail13-db3-R.bigfish.com (10.3.81.250) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:53 +0000
Received: from mail13-db3 (localhost [127.0.0.1])	by mail13-db3-R.bigfish.com
	(Postfix) with ESMTP id 6990440732;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail13-db3 (localhost.localdomain [127.0.0.1]) by mail13-db3
	(MessageSwitch) id 1328886470377849_3320;
	Fri, 10 Feb 2012 15:07:50 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.251])	by
	mail13-db3.bigfish.com (Postfix) with ESMTP id 4BA63260048;
	Fri, 10 Feb 2012 15:07:50 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:48 +0000
X-WSS-ID: 0LZ6NCV-02-GCQ-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 280DDC82ED;	Fri, 10 Feb 2012 09:07:42 -0600 (CST)
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, 10 Feb 2012 09:08:03 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:45 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DB48F49C65D; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id CBC8C594883; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3c47f70c84e23b96e766c062a4bbae5bcf4f6dbe
Message-ID: <3c47f70c84e23b96e766.1328886427@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:07 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 6 V5] amd iommu: Add a hypercall for
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885355 -3600
# Node ID 3c47f70c84e23b96e766c062a4bbae5bcf4f6dbe
# Parent  9cf24ad61936e5d9a6acac9de1dc1fac6694c31e
amd iommu: Add a hypercall for hvmloader.
IOMMU MMIO base address is dynamically allocated by firmware.
This patch allows hvmloader to notify hypervisor where the
iommu mmio pages are.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 9cf24ad61936 -r 3c47f70c84e2 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Feb 10 15:49:09 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Feb 10 15:49:15 2012 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -3775,6 +3776,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 ) 
diff -r 9cf24ad61936 -r 3c47f70c84e2 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Fri Feb 10 15:49:09 2012 +0100
+++ b/xen/include/public/hvm/params.h	Fri Feb 10 15:49:15 2012 +0100
@@ -141,7 +141,8 @@
 
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
+#define HVM_PARAM_IOMMU_BASE   27
 
-#define HVM_NR_PARAMS          27
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4s-0004Ky-Tv; Fri, 10 Feb 2012 15:07:58 +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 1Rvs4s-0004Kj-2E
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:58 +0000
Received: from [85.158.139.83:45859] by server-12.bemta-5.messagelabs.com id
	46/88-30830-DC2353F4; Fri, 10 Feb 2012 15:07:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328886474!13714628!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2649 invoked from network); 10 Feb 2012 15:07:55 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.144)
	by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:55 -0000
Received: from mail33-db3-R.bigfish.com (10.3.81.232) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:54 +0000
Received: from mail33-db3 (localhost [127.0.0.1])	by mail33-db3-R.bigfish.com
	(Postfix) with ESMTP id DDC7A2A03D1;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
X-SpamScore: -2
X-BigFish: VPS-2(zz1a09Jzz1202hzz8275dhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail33-db3 (localhost.localdomain [127.0.0.1]) by mail33-db3
	(MessageSwitch) id 1328886470704067_6909;
	Fri, 10 Feb 2012 15:07:50 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.239])	by
	mail33-db3.bigfish.com (Postfix) with ESMTP id 9D6D24026E;
	Fri, 10 Feb 2012 15:07:50 +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; Fri, 10 Feb 2012 15:07:48 +0000
X-WSS-ID: 0LZ6NCW-01-1VK-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 285C11028361;	Fri, 10 Feb 2012 09:07:43 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 10 Feb 2012 09:08:03 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:39 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C5F8C49C0F1; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A87225940FF; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:05 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 6 V5] amd iommu: support ats/gpgpu passthru
 on iommuv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
This is patch set v5. It includes all pending patches that are needed to enable gpgpu passthrough and heterogeneous computing in guest OSes. Basically, this patch set gives guest VM the same capability of running openCL applications on amd platforms as native OSes. Upstream Linux 3.3 rc2 with amd iommuv2 kernel driver has been tested well as guest OS, and since last submission, lots of regression tests have been done to make sure this does not break non-iommuv2 systems. Please review it, feedbacks are appreciated.

Many thanks,
Wei

For more details, please refer to old thread.
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 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. 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4s-0004Ky-Tv; Fri, 10 Feb 2012 15:07:58 +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 1Rvs4s-0004Kj-2E
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:58 +0000
Received: from [85.158.139.83:45859] by server-12.bemta-5.messagelabs.com id
	46/88-30830-DC2353F4; Fri, 10 Feb 2012 15:07:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328886474!13714628!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2649 invoked from network); 10 Feb 2012 15:07:55 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.144)
	by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:55 -0000
Received: from mail33-db3-R.bigfish.com (10.3.81.232) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:54 +0000
Received: from mail33-db3 (localhost [127.0.0.1])	by mail33-db3-R.bigfish.com
	(Postfix) with ESMTP id DDC7A2A03D1;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
X-SpamScore: -2
X-BigFish: VPS-2(zz1a09Jzz1202hzz8275dhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail33-db3 (localhost.localdomain [127.0.0.1]) by mail33-db3
	(MessageSwitch) id 1328886470704067_6909;
	Fri, 10 Feb 2012 15:07:50 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.239])	by
	mail33-db3.bigfish.com (Postfix) with ESMTP id 9D6D24026E;
	Fri, 10 Feb 2012 15:07:50 +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; Fri, 10 Feb 2012 15:07:48 +0000
X-WSS-ID: 0LZ6NCW-01-1VK-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 285C11028361;	Fri, 10 Feb 2012 09:07:43 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 10 Feb 2012 09:08:03 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:39 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C5F8C49C0F1; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A87225940FF; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:05 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 6 V5] amd iommu: support ats/gpgpu passthru
 on iommuv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
This is patch set v5. It includes all pending patches that are needed to enable gpgpu passthrough and heterogeneous computing in guest OSes. Basically, this patch set gives guest VM the same capability of running openCL applications on amd platforms as native OSes. Upstream Linux 3.3 rc2 with amd iommuv2 kernel driver has been tested well as guest OS, and since last submission, lots of regression tests have been done to make sure this does not break non-iommuv2 systems. Please review it, feedbacks are appreciated.

Many thanks,
Wei

For more details, please refer to old thread.
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 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. 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4v-0004Lg-4I; Fri, 10 Feb 2012 15:08:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rvs4s-0004Kk-Ce
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:59 +0000
Received: from [85.158.139.83:45871] by server-6.bemta-5.messagelabs.com id
	99/75-04784-DC2353F4; Fri, 10 Feb 2012 15:07:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328886474!14500770!2
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5627 invoked from network); 10 Feb 2012 15:07:55 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.141)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:55 -0000
Received: from mail115-db3-R.bigfish.com (10.3.81.225) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:55 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by
	mail115-db3-R.bigfish.com (Postfix) with ESMTP id 456304E0547;
	Fri, 10 Feb 2012 15:07:55 +0000 (UTC)
X-SpamScore: 3
X-BigFish: VPS3(zz853kzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3
	(MessageSwitch) id 1328886473980608_20851;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.244])	by
	mail115-db3.bigfish.com (Postfix) with ESMTP id EC13AC0053;
	Fri, 10 Feb 2012 15:07:53 +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; Fri, 10 Feb 2012 15:07:52 +0000
X-WSS-ID: 0LZ6ND0-01-1VT-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 22304102835F;	Fri, 10 Feb 2012 09:07:47 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 10 Feb 2012 09:08:07 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:48 -0600
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, 10 Feb 2012
	10:07:39 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 351B349C662; Fri, 10 Feb 2012
	15:07:38 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 23292594887; Fri, 10 Feb 2012
	16:07:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 09721a5ff84451b5a95d6cdc445867fa158dd449
Message-ID: <09721a5ff84451b5a95d.1328886431@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:11 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 6 V5] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885360 -3600
# Node ID 09721a5ff84451b5a95d6cdc445867fa158dd449
# Parent  c39f5736e36429091839a8db10179deeb6b0c622
libxl: Introduce a new guest config file parameter
Use guest_iommu = {1,0} to enable or disable guest iommu emulation.
Default value is 0. Regression tests have been done to make sure
it does not break non-iommuv2 systems.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r c39f5736e364 -r 09721a5ff844 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:19 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:20 2012 +0100
@@ -820,6 +820,10 @@ certainly belong in a more appropriate s
 
 Enable graphics device PCI passthrough. XXX which device is passed through ?
 
+=item B<guest_iommu=BOOLEAN>
+
+Enable virtual iommu device for hvm guest. It should be enabled to passthrough AMD GPGPU.
+
 =item B<nomigrate=BOOLEAN>
 
 Disable migration of this domain.  This enables certain other features
diff -r c39f5736e364 -r 09721a5ff844 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Feb 10 15:49:19 2012 +0100
+++ b/tools/libxl/libxl_create.c	Fri Feb 10 15:49:20 2012 +0100
@@ -100,6 +100,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.guest_iommu = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
@@ -169,13 +170,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "guest_iommu";
+        localents[7] = (info->u.hvm.guest_iommu) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r c39f5736e364 -r 09721a5ff844 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Feb 10 15:49:19 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Fri Feb 10 15:49:20 2012 +0100
@@ -239,6 +239,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", libxl_timer_mode),
                                        ("nested_hvm", bool),
+                                       ("guest_iommu", bool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
diff -r c39f5736e364 -r 09721a5ff844 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Feb 10 15:49:19 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 10 15:49:20 2012 +0100
@@ -748,6 +748,8 @@ static void parse_config_data(const char
 
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long (config, "guest_iommu", &l, 0))
+            b_info->u.hvm.guest_iommu = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs4v-0004Lg-4I; Fri, 10 Feb 2012 15:08:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rvs4s-0004Kk-Ce
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:07:59 +0000
Received: from [85.158.139.83:45871] by server-6.bemta-5.messagelabs.com id
	99/75-04784-DC2353F4; Fri, 10 Feb 2012 15:07:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1328886474!14500770!2
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5627 invoked from network); 10 Feb 2012 15:07:55 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.141)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:07:55 -0000
Received: from mail115-db3-R.bigfish.com (10.3.81.225) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:55 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by
	mail115-db3-R.bigfish.com (Postfix) with ESMTP id 456304E0547;
	Fri, 10 Feb 2012 15:07:55 +0000 (UTC)
X-SpamScore: 3
X-BigFish: VPS3(zz853kzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3
	(MessageSwitch) id 1328886473980608_20851;
	Fri, 10 Feb 2012 15:07:53 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.244])	by
	mail115-db3.bigfish.com (Postfix) with ESMTP id EC13AC0053;
	Fri, 10 Feb 2012 15:07:53 +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; Fri, 10 Feb 2012 15:07:52 +0000
X-WSS-ID: 0LZ6ND0-01-1VT-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 22304102835F;	Fri, 10 Feb 2012 09:07:47 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 10 Feb 2012 09:08:07 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:48 -0600
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, 10 Feb 2012
	10:07:39 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 351B349C662; Fri, 10 Feb 2012
	15:07:38 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 23292594887; Fri, 10 Feb 2012
	16:07:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 09721a5ff84451b5a95d6cdc445867fa158dd449
Message-ID: <09721a5ff84451b5a95d.1328886431@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:11 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 6 V5] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885360 -3600
# Node ID 09721a5ff84451b5a95d6cdc445867fa158dd449
# Parent  c39f5736e36429091839a8db10179deeb6b0c622
libxl: Introduce a new guest config file parameter
Use guest_iommu = {1,0} to enable or disable guest iommu emulation.
Default value is 0. Regression tests have been done to make sure
it does not break non-iommuv2 systems.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r c39f5736e364 -r 09721a5ff844 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:19 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:20 2012 +0100
@@ -820,6 +820,10 @@ certainly belong in a more appropriate s
 
 Enable graphics device PCI passthrough. XXX which device is passed through ?
 
+=item B<guest_iommu=BOOLEAN>
+
+Enable virtual iommu device for hvm guest. It should be enabled to passthrough AMD GPGPU.
+
 =item B<nomigrate=BOOLEAN>
 
 Disable migration of this domain.  This enables certain other features
diff -r c39f5736e364 -r 09721a5ff844 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Feb 10 15:49:19 2012 +0100
+++ b/tools/libxl/libxl_create.c	Fri Feb 10 15:49:20 2012 +0100
@@ -100,6 +100,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.guest_iommu = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
@@ -169,13 +170,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "guest_iommu";
+        localents[7] = (info->u.hvm.guest_iommu) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r c39f5736e364 -r 09721a5ff844 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Feb 10 15:49:19 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Fri Feb 10 15:49:20 2012 +0100
@@ -239,6 +239,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", libxl_timer_mode),
                                        ("nested_hvm", bool),
+                                       ("guest_iommu", bool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
diff -r c39f5736e364 -r 09721a5ff844 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Feb 10 15:49:19 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 10 15:49:20 2012 +0100
@@ -748,6 +748,8 @@ static void parse_config_data(const char
 
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long (config, "guest_iommu", &l, 0))
+            b_info->u.hvm.guest_iommu = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs56-0004Qt-Qh; Fri, 10 Feb 2012 15:08:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rvs55-0004NW-N6
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:08:12 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328886483!14358331!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23164 invoked from network); 10 Feb 2012 15:08:05 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.15)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:08:05 -0000
Received: from mail179-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; Fri, 10 Feb 2012 15:08:03 +0000
Received: from mail179-tx2 (localhost [127.0.0.1])	by
	mail179-tx2-R.bigfish.com (Postfix) with ESMTP id 8AAC9380759;
	Fri, 10 Feb 2012 15:08:03 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail179-tx2 (localhost.localdomain [127.0.0.1]) by mail179-tx2
	(MessageSwitch) id 1328886479898124_3902;
	Fri, 10 Feb 2012 15:07:59 +0000 (UTC)
Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.238])	by
	mail179-tx2.bigfish.com (Postfix) with ESMTP id CC1503C0045;
	Fri, 10 Feb 2012 15:07:59 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:57 +0000
X-WSS-ID: 0LZ6ND6-01-1W0-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 20DED102835E;	Fri, 10 Feb 2012 09:07:54 -0600 (CST)
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, 10 Feb 2012 09:08:13 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:40 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EDF7B49C65F; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id DCF26594884; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 16974b6159e13262126ad1e719727592184e5bea
Message-ID: <16974b6159e13262126a.1328886428@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:08 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 6 V5] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885357 -3600
# Node ID 16974b6159e13262126ad1e719727592184e5bea
# Parent  3c47f70c84e23b96e766c062a4bbae5bcf4f6dbe
hvmloader: Build IVRS table.
There are 32 ivrs padding entries allocated at the beginning. If a passthru
device has been found from qemu bus, a padding entry will be replaced by the
real device entry. Patch has been tested with both Rombios and Seabios

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3c47f70c84e2 -r 16974b6159e1 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Feb 10 15:49:15 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Feb 10 15:49:17 2012 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r 3c47f70c84e2 -r 16974b6159e1 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Feb 10 15:49:15 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Feb 10 15:49:17 2012 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,87 @@ static struct acpi_20_waet *construct_wa
     return waet;
 }
 
+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0 || iommu_bdf == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs) 
+    {
+        printf("unable to build IVRS tables: out of memory\n");
+        return NULL;
+    }
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio) 
+    {   
+        printf("unable to reserve iommu mmio pages: out of memory\n");
+        return NULL;
+    }
+    
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+    {
+        printf("unable to set iommu mmio base address\n");
+        return NULL;
+    }
+        
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum), 
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
 static int construct_secondary_tables(unsigned long *table_ptrs,
                                       struct acpi_info *info)
 {
@@ -206,6 +289,7 @@ static int construct_secondary_tables(un
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -293,6 +377,13 @@ static int construct_secondary_tables(un
         }
     }
 
+    if ( !strncmp(xenstore_read("guest_iommu", "1"), "1", 1) )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r 3c47f70c84e2 -r 16974b6159e1 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Fri Feb 10 15:49:15 2012 +0100
+++ b/tools/firmware/hvmloader/pci.c	Fri Feb 10 15:49:17 2012 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf = 0;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,12 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
 
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            continue;
+        }
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
+
         switch ( class )
         {
         case 0x0300:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvs56-0004Qt-Qh; Fri, 10 Feb 2012 15:08:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rvs55-0004NW-N6
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:08:12 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328886483!14358331!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23164 invoked from network); 10 Feb 2012 15:08:05 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.15)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:08:05 -0000
Received: from mail179-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; Fri, 10 Feb 2012 15:08:03 +0000
Received: from mail179-tx2 (localhost [127.0.0.1])	by
	mail179-tx2-R.bigfish.com (Postfix) with ESMTP id 8AAC9380759;
	Fri, 10 Feb 2012 15:08:03 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail179-tx2 (localhost.localdomain [127.0.0.1]) by mail179-tx2
	(MessageSwitch) id 1328886479898124_3902;
	Fri, 10 Feb 2012 15:07:59 +0000 (UTC)
Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.238])	by
	mail179-tx2.bigfish.com (Postfix) with ESMTP id CC1503C0045;
	Fri, 10 Feb 2012 15:07:59 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:57 +0000
X-WSS-ID: 0LZ6ND6-01-1W0-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 20DED102835E;	Fri, 10 Feb 2012 09:07:54 -0600 (CST)
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, 10 Feb 2012 09:08:13 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:40 -0600
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, 10 Feb 2012
	10:07:38 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EDF7B49C65F; Fri, 10 Feb 2012
	15:07:37 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id DCF26594884; Fri, 10 Feb 2012
	16:07:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 16974b6159e13262126ad1e719727592184e5bea
Message-ID: <16974b6159e13262126a.1328886428@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:08 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 6 V5] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885357 -3600
# Node ID 16974b6159e13262126ad1e719727592184e5bea
# Parent  3c47f70c84e23b96e766c062a4bbae5bcf4f6dbe
hvmloader: Build IVRS table.
There are 32 ivrs padding entries allocated at the beginning. If a passthru
device has been found from qemu bus, a padding entry will be replaced by the
real device entry. Patch has been tested with both Rombios and Seabios

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3c47f70c84e2 -r 16974b6159e1 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Feb 10 15:49:15 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Feb 10 15:49:17 2012 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r 3c47f70c84e2 -r 16974b6159e1 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Feb 10 15:49:15 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Feb 10 15:49:17 2012 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,87 @@ static struct acpi_20_waet *construct_wa
     return waet;
 }
 
+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0 || iommu_bdf == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs) 
+    {
+        printf("unable to build IVRS tables: out of memory\n");
+        return NULL;
+    }
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio) 
+    {   
+        printf("unable to reserve iommu mmio pages: out of memory\n");
+        return NULL;
+    }
+    
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+    {
+        printf("unable to set iommu mmio base address\n");
+        return NULL;
+    }
+        
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum), 
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
 static int construct_secondary_tables(unsigned long *table_ptrs,
                                       struct acpi_info *info)
 {
@@ -206,6 +289,7 @@ static int construct_secondary_tables(un
     struct acpi_20_hpet *hpet;
     struct acpi_20_waet *waet;
     struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
     unsigned char *ssdt;
     static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
     uint16_t *tis_hdr;
@@ -293,6 +377,13 @@ static int construct_secondary_tables(un
         }
     }
 
+    if ( !strncmp(xenstore_read("guest_iommu", "1"), "1", 1) )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r 3c47f70c84e2 -r 16974b6159e1 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Fri Feb 10 15:49:15 2012 +0100
+++ b/tools/firmware/hvmloader/pci.c	Fri Feb 10 15:49:17 2012 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf = 0;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,12 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
 
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            continue;
+        }
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
+
         switch ( class )
         {
         case 0x0300:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvs59-0004Rg-8W; Fri, 10 Feb 2012 15:08:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rvs57-0004OJ-DR
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:08:13 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328886486!14041107!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5859 invoked from network); 10 Feb 2012 15:08:07 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:08:07 -0000
Received: from mail44-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:08:06 +0000
Received: from mail44-ch1 (localhost [127.0.0.1])	by mail44-ch1-R.bigfish.com
	(Postfix) with ESMTP id D516D3400BD;
	Fri, 10 Feb 2012 15:08:05 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1
	(MessageSwitch) id 1328886482322880_5964;
	Fri, 10 Feb 2012 15:08:02 +0000 (UTC)
Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.234])	by mail44-ch1.bigfish.com (Postfix) with ESMTP id
	2C492420045;	Fri, 10 Feb 2012 15:08:02 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:59 +0000
X-WSS-ID: 0LZ6ND7-02-GD6-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 2C7FDC82E6;	Fri, 10 Feb 2012 09:07:54 -0600 (CST)
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, 10 Feb 2012 09:08:14 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:55 -0600
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, 10 Feb 2012
	10:07:39 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 224B349C661; Fri, 10 Feb 2012
	15:07:38 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 0BEAE594886; Fri, 10 Feb 2012
	16:07:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c39f5736e36429091839a8db10179deeb6b0c622
Message-ID: <c39f5736e36429091839.1328886430@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:10 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 6 V5] libxl: bind virtual bdf to physical
 bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885359 -3600
# Node ID c39f5736e36429091839a8db10179deeb6b0c622
# Parent  db10bcca843c65260426800f9e05da8359faf439
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r db10bcca843c -r c39f5736e364 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Feb 10 15:49:18 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Feb 10 15:49:19 2012 +0100
@@ -721,6 +721,13 @@ out:
             LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
             return ERROR_FAIL;
         }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, 0, pcidev->vdevfn, pcidev->domain, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+                LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+                return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:08:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvs59-0004Rg-8W; Fri, 10 Feb 2012 15:08:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Rvs57-0004OJ-DR
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:08:13 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328886486!14041107!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5859 invoked from network); 10 Feb 2012 15:08:07 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:08:07 -0000
Received: from mail44-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:08:06 +0000
Received: from mail44-ch1 (localhost [127.0.0.1])	by mail44-ch1-R.bigfish.com
	(Postfix) with ESMTP id D516D3400BD;
	Fri, 10 Feb 2012 15:08:05 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1
	(MessageSwitch) id 1328886482322880_5964;
	Fri, 10 Feb 2012 15:08:02 +0000 (UTC)
Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.234])	by mail44-ch1.bigfish.com (Postfix) with ESMTP id
	2C492420045;	Fri, 10 Feb 2012 15:08:02 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:07:59 +0000
X-WSS-ID: 0LZ6ND7-02-GD6-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 2C7FDC82E6;	Fri, 10 Feb 2012 09:07:54 -0600 (CST)
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, 10 Feb 2012 09:08:14 -0600
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.289.1;
	Fri, 10 Feb 2012 09:07:55 -0600
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, 10 Feb 2012
	10:07:39 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 224B349C661; Fri, 10 Feb 2012
	15:07:38 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 0BEAE594886; Fri, 10 Feb 2012
	16:07:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c39f5736e36429091839a8db10179deeb6b0c622
Message-ID: <c39f5736e36429091839.1328886430@gran.amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 10 Feb 2012 16:07:10 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <Ian.Jackson@eu.citrix.com>, <Ian.Campbell@citrix.com>,
	<JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 6 V5] libxl: bind virtual bdf to physical
 bdf after device assignment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1328885359 -3600
# Node ID c39f5736e36429091839a8db10179deeb6b0c622
# Parent  db10bcca843c65260426800f9e05da8359faf439
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r db10bcca843c -r c39f5736e364 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Feb 10 15:49:18 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Feb 10 15:49:19 2012 +0100
@@ -721,6 +721,13 @@ out:
             LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_assign_device failed");
             return ERROR_FAIL;
         }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, 0, pcidev->vdevfn, pcidev->domain, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+                LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+                return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:22:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1RvsIt-0005bg-BF; Fri, 10 Feb 2012 15:22:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RvsIs-0005ad-3Y
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:22:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328887339!12857646!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29686 invoked from network); 10 Feb 2012 15:22:20 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 15:22:20 -0000
Received: by werb14 with SMTP id b14so8414741wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 07:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=SwEa02t/ERmS/8q69l/ItoB02qrzaL2Jne/AE791opQ=;
	b=aFTw+e0HKrwsnQ2Pcw6D5C1xeIVTP7dHCH1bhT/jqmAF4/1N6Pexli9J9mexA1e2IC
	JQmHnn2YqBdshHsYVd+6iuTha6bTYh3hkdVG3iyAvMJvNIXpYUwVCDnoacr/Pj26a85m
	3SXaMyhjSMz8z6SrpwtQyzuKyULD1oFK+3O48=
MIME-Version: 1.0
Received: by 10.180.86.105 with SMTP id o9mr9983045wiz.4.1328887339831; Fri,
	10 Feb 2012 07:22:19 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Fri, 10 Feb 2012 07:22:19 -0800 (PST)
Date: Fri, 10 Feb 2012 16:22:19 +0100
X-Google-Sender-Auth: R8Iwpqd9oaRHj7dY5egyh82qSco
Message-ID: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've recently setup a Linux Dom0 with a 3.0.17 kernel and Xen 4.1.2,
and since the 3.x series doesn't have blktap support I'm using qdisk
to attach raw images. I've been playing with small images, something
like 1GB, and everything seemed fine, speed was not fantastic but it
was ok. Today I've set up a bigger machine, with a 20GB raw hdd and
the disk write throughput is really slow, inferior to 0.5MB/s. I'm
trying to install a Debian PV there, and after more than 3 hours it is
still installing the base system.

I've looked at the xenstore backend entries, and everything looks fine:

/local/domain/0/backend/qdisk/21/51712/frontend =
"/local/domain/21/device/vbd/51712"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/params =
"aio:/hdd/vm/servlet/servlet.img"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/frontend-id = "21"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/online = "1"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/removable = "0"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/bootable = "1"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/state = "4"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/dev = "xvda"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/type = "tap"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/mode = "w"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/feature-barrier = "1"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/info = "0"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/sector-size = "512"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/sectors = "40960000"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/hotplug-status = "connected"   (n0,r21)

Also, the related qemu-dm process doesn't seem to be hung by CPU, in
fact it is reporting a CPU usage of 0% almost all the time. I've
attached to the qemu-dm process with strace, and it is doing lseeks
and writes like crazy, is this normal? Is there any improvement when
using qemu-upstream?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:22:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1RvsIt-0005bg-BF; Fri, 10 Feb 2012 15:22:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RvsIs-0005ad-3Y
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:22:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328887339!12857646!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29686 invoked from network); 10 Feb 2012 15:22:20 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 15:22:20 -0000
Received: by werb14 with SMTP id b14so8414741wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 07:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=SwEa02t/ERmS/8q69l/ItoB02qrzaL2Jne/AE791opQ=;
	b=aFTw+e0HKrwsnQ2Pcw6D5C1xeIVTP7dHCH1bhT/jqmAF4/1N6Pexli9J9mexA1e2IC
	JQmHnn2YqBdshHsYVd+6iuTha6bTYh3hkdVG3iyAvMJvNIXpYUwVCDnoacr/Pj26a85m
	3SXaMyhjSMz8z6SrpwtQyzuKyULD1oFK+3O48=
MIME-Version: 1.0
Received: by 10.180.86.105 with SMTP id o9mr9983045wiz.4.1328887339831; Fri,
	10 Feb 2012 07:22:19 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Fri, 10 Feb 2012 07:22:19 -0800 (PST)
Date: Fri, 10 Feb 2012 16:22:19 +0100
X-Google-Sender-Auth: R8Iwpqd9oaRHj7dY5egyh82qSco
Message-ID: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I've recently setup a Linux Dom0 with a 3.0.17 kernel and Xen 4.1.2,
and since the 3.x series doesn't have blktap support I'm using qdisk
to attach raw images. I've been playing with small images, something
like 1GB, and everything seemed fine, speed was not fantastic but it
was ok. Today I've set up a bigger machine, with a 20GB raw hdd and
the disk write throughput is really slow, inferior to 0.5MB/s. I'm
trying to install a Debian PV there, and after more than 3 hours it is
still installing the base system.

I've looked at the xenstore backend entries, and everything looks fine:

/local/domain/0/backend/qdisk/21/51712/frontend =
"/local/domain/21/device/vbd/51712"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/params =
"aio:/hdd/vm/servlet/servlet.img"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/frontend-id = "21"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/online = "1"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/removable = "0"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/bootable = "1"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/state = "4"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/dev = "xvda"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/type = "tap"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/mode = "w"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/feature-barrier = "1"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/info = "0"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/sector-size = "512"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/sectors = "40960000"   (n0,r21)
/local/domain/0/backend/qdisk/21/51712/hotplug-status = "connected"   (n0,r21)

Also, the related qemu-dm process doesn't seem to be hung by CPU, in
fact it is reporting a CPU usage of 0% almost all the time. I've
attached to the qemu-dm process with strace, and it is doing lseeks
and writes like crazy, is this normal? Is there any improvement when
using qemu-upstream?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:29:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1RvsPq-0006E3-FY; Fri, 10 Feb 2012 15:29:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvsPo-0006Dr-FW
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:29:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328887770!5433949!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5894 invoked from network); 10 Feb 2012 15:29:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:29:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 15:29:29 +0000
Message-Id: <4F3545E8020000780007261B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 15:29:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1328886425@gran.amd.com>
	<9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
In-Reply-To: <9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 6 V5] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.02.12 at 16:07, Wei Wang <wei.wang2@amd.com> wrote:
> @@ -916,3 +933,45 @@ const struct hvm_mmio_handler iommu_mmio
>      .read_handler = guest_iommu_mmio_read,
>      .write_handler = guest_iommu_mmio_write
>  };
> +
> +/* iommu hypercall handler */
> +int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
> +                   uint16_t mseg, uint16_t mbdf)
> +{
> +    struct pci_dev *pdev;
> +    int ret = -ENODEV;
> +
> +    if ( !iommu_found() || !iommu_enabled || !iommuv2_enabled )
> +        return ret;
> +
> +    spin_lock(&pcidevs_lock);
> +
> +    for_each_pdev( d, pdev )
> +    {
> +        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) || 
> +             (pdev->devfn != PCI_DEVFN2(mbdf)) )
> +            continue;
> +
> +        pdev->gseg = gseg;
> +        pdev->gbdf = gbdf;
> +        ret = 0;
> +    }
> +
> +    spin_unlock(&pcidevs_lock);
> +    return ret;
> +}
> +
> +void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
> +                   uint16_t dest_mode, uint16_t delivery_mode, 
> +                   uint16_t trig_mode)

Why are these all uint16_t?

> +{
> +    struct guest_iommu *iommu = domain_iommu(d);
> +
> +    if ( !iommu )
> +        return;
> +
> +    iommu->msi.vector = vector;
> +    iommu->msi.dest = dest;
> +    iommu->msi.dest_mode = dest_mode;
> +    iommu->msi.trig_mode = trig_mode;
> +}
> diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/iommu.c
> --- a/xen/drivers/passthrough/iommu.c	Thu Feb 09 06:09:17 2012 -0800
> +++ b/xen/drivers/passthrough/iommu.c	Fri Feb 10 15:49:09 2012 +0100
> @@ -648,6 +648,40 @@ int iommu_do_domctl(
>          put_domain(d);
>          break;
>  
> +    case XEN_DOMCTL_guest_iommu_op:
> +    {
> +        xen_domctl_guest_iommu_op_t * guest_op;
> +
> +        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
> +        {
> +            gdprintk(XENLOG_ERR,
> +                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() 
> failed\n");
> +            ret = -EINVAL;
> +            break;
> +        }
> +
> +        guest_op = &(domctl->u.guest_iommu_op);
> +        switch ( guest_op->op )
> +        {
> +            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:

Indentation.

> +                iommu_set_msi(d, guest_op->u.msi.vector, 
> +                              guest_op->u.msi.dest,
> +                              guest_op->u.msi.dest_mode, 
> +                              guest_op->u.msi.delivery_mode,
> +                              guest_op->u.msi.trig_mode);
> +                ret = 0;
> +                break;
> +            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
> +                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
> +                                     guest_op->u.bdf_bind.g_bdf,
> +                                     guest_op->u.bdf_bind.m_seg,
> +                                     guest_op->u.bdf_bind.m_bdf);
> +                break;
> +        }
> +        put_domain(d);
> +        break;
> +    }
> +
>      default:
>          ret = -ENOSYS;
>          break;
> diff -r 593deed8f62d -r 9cf24ad61936 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Feb 09 06:09:17 2012 -0800
> +++ b/xen/include/public/domctl.h	Fri Feb 10 15:49:09 2012 +0100
> @@ -871,6 +871,31 @@ struct xen_domctl_set_access_required {
>  typedef struct xen_domctl_set_access_required 
> xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +/* 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;
> +        uint8_t  dest_mode;
> +        uint8_t  delivery_mode;
> +        uint8_t  trig_mode;

Indentation again.

Jan

> +        } msi;
> +        struct bdf_bind {
> +            uint16_t            g_seg;
> +            uint16_t            g_bdf;
> +            uint16_t            m_seg;
> +            uint16_t            m_bdf;
> +        } bdf_bind;
> +    } u;
> +};
> +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:29:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1RvsPq-0006E3-FY; Fri, 10 Feb 2012 15:29:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvsPo-0006Dr-FW
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:29:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328887770!5433949!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5894 invoked from network); 10 Feb 2012 15:29:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:29:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 15:29:29 +0000
Message-Id: <4F3545E8020000780007261B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 15:29:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1328886425@gran.amd.com>
	<9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
In-Reply-To: <9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 6 V5] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.02.12 at 16:07, Wei Wang <wei.wang2@amd.com> wrote:
> @@ -916,3 +933,45 @@ const struct hvm_mmio_handler iommu_mmio
>      .read_handler = guest_iommu_mmio_read,
>      .write_handler = guest_iommu_mmio_write
>  };
> +
> +/* iommu hypercall handler */
> +int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
> +                   uint16_t mseg, uint16_t mbdf)
> +{
> +    struct pci_dev *pdev;
> +    int ret = -ENODEV;
> +
> +    if ( !iommu_found() || !iommu_enabled || !iommuv2_enabled )
> +        return ret;
> +
> +    spin_lock(&pcidevs_lock);
> +
> +    for_each_pdev( d, pdev )
> +    {
> +        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) || 
> +             (pdev->devfn != PCI_DEVFN2(mbdf)) )
> +            continue;
> +
> +        pdev->gseg = gseg;
> +        pdev->gbdf = gbdf;
> +        ret = 0;
> +    }
> +
> +    spin_unlock(&pcidevs_lock);
> +    return ret;
> +}
> +
> +void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
> +                   uint16_t dest_mode, uint16_t delivery_mode, 
> +                   uint16_t trig_mode)

Why are these all uint16_t?

> +{
> +    struct guest_iommu *iommu = domain_iommu(d);
> +
> +    if ( !iommu )
> +        return;
> +
> +    iommu->msi.vector = vector;
> +    iommu->msi.dest = dest;
> +    iommu->msi.dest_mode = dest_mode;
> +    iommu->msi.trig_mode = trig_mode;
> +}
> diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/iommu.c
> --- a/xen/drivers/passthrough/iommu.c	Thu Feb 09 06:09:17 2012 -0800
> +++ b/xen/drivers/passthrough/iommu.c	Fri Feb 10 15:49:09 2012 +0100
> @@ -648,6 +648,40 @@ int iommu_do_domctl(
>          put_domain(d);
>          break;
>  
> +    case XEN_DOMCTL_guest_iommu_op:
> +    {
> +        xen_domctl_guest_iommu_op_t * guest_op;
> +
> +        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
> +        {
> +            gdprintk(XENLOG_ERR,
> +                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() 
> failed\n");
> +            ret = -EINVAL;
> +            break;
> +        }
> +
> +        guest_op = &(domctl->u.guest_iommu_op);
> +        switch ( guest_op->op )
> +        {
> +            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:

Indentation.

> +                iommu_set_msi(d, guest_op->u.msi.vector, 
> +                              guest_op->u.msi.dest,
> +                              guest_op->u.msi.dest_mode, 
> +                              guest_op->u.msi.delivery_mode,
> +                              guest_op->u.msi.trig_mode);
> +                ret = 0;
> +                break;
> +            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
> +                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
> +                                     guest_op->u.bdf_bind.g_bdf,
> +                                     guest_op->u.bdf_bind.m_seg,
> +                                     guest_op->u.bdf_bind.m_bdf);
> +                break;
> +        }
> +        put_domain(d);
> +        break;
> +    }
> +
>      default:
>          ret = -ENOSYS;
>          break;
> diff -r 593deed8f62d -r 9cf24ad61936 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Feb 09 06:09:17 2012 -0800
> +++ b/xen/include/public/domctl.h	Fri Feb 10 15:49:09 2012 +0100
> @@ -871,6 +871,31 @@ struct xen_domctl_set_access_required {
>  typedef struct xen_domctl_set_access_required 
> xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +/* 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;
> +        uint8_t  dest_mode;
> +        uint8_t  delivery_mode;
> +        uint8_t  trig_mode;

Indentation again.

Jan

> +        } msi;
> +        struct bdf_bind {
> +            uint16_t            g_seg;
> +            uint16_t            g_bdf;
> +            uint16_t            m_seg;
> +            uint16_t            m_bdf;
> +        } bdf_bind;
> +    } u;
> +};
> +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:34:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsUF-0006Wm-Si; Fri, 10 Feb 2012 15:34:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvsUE-0006Wc-8d
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:34:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328888043!14177926!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29868 invoked from network); 10 Feb 2012 15:34:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:34:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvsU3-0008R0-S5; Fri, 10 Feb 2012 15:33:59 +0000
Date: Fri, 10 Feb 2012 15:33:59 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210153359.GA32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<e29c2634afb1de9aee84.1328766346@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e29c2634afb1de9aee84.1328766346@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 7] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 00:45 -0500 on 09 Feb (1328748346), Andres Lagar-Cavilla wrote:
> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
> 
> The lock is always taken recursively, as there are many paths that
> call get_gfn, and later, make another attempt at grabbing the p2m_lock.
> 
> The lock is not taken for shadow lookups. We believe there are no problems
> remaining for synchronized p2m+shadow paging, but we are not enabling this
> combination due to lack of testing. Unlocked shadow p2m access are tolerable as
> long as shadows do not gain support for paging or sharing.
> 
> HAP (EPT) lookups and all modifications do take the lock.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:34:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:34:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsUF-0006Wm-Si; Fri, 10 Feb 2012 15:34:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvsUE-0006Wc-8d
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:34:10 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328888043!14177926!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29868 invoked from network); 10 Feb 2012 15:34:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:34:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvsU3-0008R0-S5; Fri, 10 Feb 2012 15:33:59 +0000
Date: Fri, 10 Feb 2012 15:33:59 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210153359.GA32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<e29c2634afb1de9aee84.1328766346@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e29c2634afb1de9aee84.1328766346@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 7] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 00:45 -0500 on 09 Feb (1328748346), Andres Lagar-Cavilla wrote:
> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
> 
> The lock is always taken recursively, as there are many paths that
> call get_gfn, and later, make another attempt at grabbing the p2m_lock.
> 
> The lock is not taken for shadow lookups. We believe there are no problems
> remaining for synchronized p2m+shadow paging, but we are not enabling this
> combination due to lack of testing. Unlocked shadow p2m access are tolerable as
> long as shadows do not gain support for paging or sharing.
> 
> HAP (EPT) lookups and all modifications do take the lock.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:36:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1RvsWZ-0006hp-EJ; Fri, 10 Feb 2012 15:36:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvsWY-0006hb-0K
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:36:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328888187!12806267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5312 invoked from network); 10 Feb 2012 15:36:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:36:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvsWP-0008Rf-O7; Fri, 10 Feb 2012 15:36:25 +0000
Date: Fri, 10 Feb 2012 15:36:25 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210153625.GB32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:45 -0800 on 09 Feb (1328769948), Andres Lagar-Cavilla wrote:
> > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Great, thanks George!
> 
> Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or, wait
> for more comments. Or, send a micro-patch later removing the BUG_ON.

One of the later patches needs a bit of work; when you're addressing
that, can you refresh this to drop the BUG_ON and add the ack? 
Then with any luck the whole series can go in at once.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:36:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1RvsWZ-0006hp-EJ; Fri, 10 Feb 2012 15:36:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RvsWY-0006hb-0K
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:36:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328888187!12806267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5312 invoked from network); 10 Feb 2012 15:36:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:36:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvsWP-0008Rf-O7; Fri, 10 Feb 2012 15:36:25 +0000
Date: Fri, 10 Feb 2012 15:36:25 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210153625.GB32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:45 -0800 on 09 Feb (1328769948), Andres Lagar-Cavilla wrote:
> > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Great, thanks George!
> 
> Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or, wait
> for more comments. Or, send a micro-patch later removing the BUG_ON.

One of the later patches needs a bit of work; when you're addressing
that, can you refresh this to drop the BUG_ON and add the ack? 
Then with any luck the whole series can go in at once.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:37:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsXJ-0006mF-UW; Fri, 10 Feb 2012 15:37:21 +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 1RvsXI-0006m3-P7
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:37:21 +0000
Received: from [85.158.139.83:55452] by server-4.bemta-5.messagelabs.com id
	AE/D8-28576-0B9353F4; Fri, 10 Feb 2012 15:37:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328888239!13718909!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11117 invoked from network); 10 Feb 2012 15:37:19 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.207)
	by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:37:19 -0000
Received: from mail13-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:37:19 +0000
Received: from mail13-am1 (localhost [127.0.0.1])	by mail13-am1-R.bigfish.com
	(Postfix) with ESMTP id DEEB42067C;
	Fri, 10 Feb 2012 15:37:18 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1
	(MessageSwitch) id 1328888236685846_11667;
	Fri, 10 Feb 2012 15:37:16 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.247])	by
	mail13-am1.bigfish.com (Postfix) with ESMTP id 9669D100045;
	Fri, 10 Feb 2012 15:37:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:37:16 +0000
X-WSS-ID: 0LZ6OPY-02-0GK-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 2146CC82ED;	Fri, 10 Feb 2012 09:37:10 -0600 (CST)
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, 10 Feb 2012 09:37:31 -0600
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, 10 Feb 2012 09:37:12 -0600
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, 10 Feb 2012
	10:37:11 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4695549C0F1; Fri, 10 Feb 2012
	15:37:07 +0000 (GMT)
Message-ID: <4F353AD2.7030705@amd.com>
Date: Fri, 10 Feb 2012 16:42:10 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328886425@gran.amd.com>
	<9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
	<4F3545E8020000780007261B@nat28.tlf.novell.com>
In-Reply-To: <4F3545E8020000780007261B@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 6 V5] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 04:29 PM, Jan Beulich wrote:
>>>> On 10.02.12 at 16:07, Wei Wang<wei.wang2@amd.com>  wrote:
>> @@ -916,3 +933,45 @@ const struct hvm_mmio_handler iommu_mmio
>>       .read_handler = guest_iommu_mmio_read,
>>       .write_handler = guest_iommu_mmio_write
>>   };
>> +
>> +/* iommu hypercall handler */
>> +int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
>> +                   uint16_t mseg, uint16_t mbdf)
>> +{
>> +    struct pci_dev *pdev;
>> +    int ret = -ENODEV;
>> +
>> +    if ( !iommu_found() || !iommu_enabled || !iommuv2_enabled )
>> +        return ret;
>> +
>> +    spin_lock(&pcidevs_lock);
>> +
>> +    for_each_pdev( d, pdev )
>> +    {
>> +        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) ||
>> +             (pdev->devfn != PCI_DEVFN2(mbdf)) )
>> +            continue;
>> +
>> +        pdev->gseg = gseg;
>> +        pdev->gbdf = gbdf;
>> +        ret = 0;
>> +    }
>> +
>> +    spin_unlock(&pcidevs_lock);
>> +    return ret;
>> +}
>> +
>> +void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
>> +                   uint16_t dest_mode, uint16_t delivery_mode,
>> +                   uint16_t trig_mode)
>
> Why are these all uint16_t?

uint8_t might better... I will change it.

>
>> +{
>> +    struct guest_iommu *iommu = domain_iommu(d);
>> +
>> +    if ( !iommu )
>> +        return;
>> +
>> +    iommu->msi.vector = vector;
>> +    iommu->msi.dest = dest;
>> +    iommu->msi.dest_mode = dest_mode;
>> +    iommu->msi.trig_mode = trig_mode;
>> +}
>> diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/iommu.c
>> --- a/xen/drivers/passthrough/iommu.c	Thu Feb 09 06:09:17 2012 -0800
>> +++ b/xen/drivers/passthrough/iommu.c	Fri Feb 10 15:49:09 2012 +0100
>> @@ -648,6 +648,40 @@ int iommu_do_domctl(
>>           put_domain(d);
>>           break;
>>
>> +    case XEN_DOMCTL_guest_iommu_op:
>> +    {
>> +        xen_domctl_guest_iommu_op_t * guest_op;
>> +
>> +        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
>> +        {
>> +            gdprintk(XENLOG_ERR,
>> +                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id()
>> failed\n");
>> +            ret = -EINVAL;
>> +            break;
>> +        }
>> +
>> +        guest_op =&(domctl->u.guest_iommu_op);
>> +        switch ( guest_op->op )
>> +        {
>> +            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
>
> Indentation.
can be fixed.

Thanks,
Wei
>
>> +                iommu_set_msi(d, guest_op->u.msi.vector,
>> +                              guest_op->u.msi.dest,
>> +                              guest_op->u.msi.dest_mode,
>> +                              guest_op->u.msi.delivery_mode,
>> +                              guest_op->u.msi.trig_mode);
>> +                ret = 0;
>> +                break;
>> +            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
>> +                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
>> +                                     guest_op->u.bdf_bind.g_bdf,
>> +                                     guest_op->u.bdf_bind.m_seg,
>> +                                     guest_op->u.bdf_bind.m_bdf);
>> +                break;
>> +        }
>> +        put_domain(d);
>> +        break;
>> +    }
>> +
>>       default:
>>           ret = -ENOSYS;
>>           break;
>> diff -r 593deed8f62d -r 9cf24ad61936 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Thu Feb 09 06:09:17 2012 -0800
>> +++ b/xen/include/public/domctl.h	Fri Feb 10 15:49:09 2012 +0100
>> @@ -871,6 +871,31 @@ struct xen_domctl_set_access_required {
>>   typedef struct xen_domctl_set_access_required
>> xen_domctl_set_access_required_t;
>>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>>
>> +/* 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;
>> +        uint8_t  dest_mode;
>> +        uint8_t  delivery_mode;
>> +        uint8_t  trig_mode;
>
> Indentation again.
>
> Jan
>
>> +        } msi;
>> +        struct bdf_bind {
>> +            uint16_t            g_seg;
>> +            uint16_t            g_bdf;
>> +            uint16_t            m_seg;
>> +            uint16_t            m_bdf;
>> +        } bdf_bind;
>> +    } u;
>> +};
>> +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
>> +
>>   struct xen_domctl {
>>       uint32_t cmd;
>>   #define XEN_DOMCTL_createdomain                   1
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:37:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsXJ-0006mF-UW; Fri, 10 Feb 2012 15:37:21 +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 1RvsXI-0006m3-P7
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:37:21 +0000
Received: from [85.158.139.83:55452] by server-4.bemta-5.messagelabs.com id
	AE/D8-28576-0B9353F4; Fri, 10 Feb 2012 15:37:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328888239!13718909!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11117 invoked from network); 10 Feb 2012 15:37:19 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.207)
	by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Feb 2012 15:37:19 -0000
Received: from mail13-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:37:19 +0000
Received: from mail13-am1 (localhost [127.0.0.1])	by mail13-am1-R.bigfish.com
	(Postfix) with ESMTP id DEEB42067C;
	Fri, 10 Feb 2012 15:37:18 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1
	(MessageSwitch) id 1328888236685846_11667;
	Fri, 10 Feb 2012 15:37:16 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.247])	by
	mail13-am1.bigfish.com (Postfix) with ESMTP id 9669D100045;
	Fri, 10 Feb 2012 15:37:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Fri, 10 Feb 2012 15:37:16 +0000
X-WSS-ID: 0LZ6OPY-02-0GK-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 2146CC82ED;	Fri, 10 Feb 2012 09:37:10 -0600 (CST)
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, 10 Feb 2012 09:37:31 -0600
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, 10 Feb 2012 09:37:12 -0600
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, 10 Feb 2012
	10:37:11 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4695549C0F1; Fri, 10 Feb 2012
	15:37:07 +0000 (GMT)
Message-ID: <4F353AD2.7030705@amd.com>
Date: Fri, 10 Feb 2012 16:42:10 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1328886425@gran.amd.com>
	<9cf24ad61936e5d9a6ac.1328886426@gran.amd.com>
	<4F3545E8020000780007261B@nat28.tlf.novell.com>
In-Reply-To: <4F3545E8020000780007261B@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 6 V5] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/10/2012 04:29 PM, Jan Beulich wrote:
>>>> On 10.02.12 at 16:07, Wei Wang<wei.wang2@amd.com>  wrote:
>> @@ -916,3 +933,45 @@ const struct hvm_mmio_handler iommu_mmio
>>       .read_handler = guest_iommu_mmio_read,
>>       .write_handler = guest_iommu_mmio_write
>>   };
>> +
>> +/* iommu hypercall handler */
>> +int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
>> +                   uint16_t mseg, uint16_t mbdf)
>> +{
>> +    struct pci_dev *pdev;
>> +    int ret = -ENODEV;
>> +
>> +    if ( !iommu_found() || !iommu_enabled || !iommuv2_enabled )
>> +        return ret;
>> +
>> +    spin_lock(&pcidevs_lock);
>> +
>> +    for_each_pdev( d, pdev )
>> +    {
>> +        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) ||
>> +             (pdev->devfn != PCI_DEVFN2(mbdf)) )
>> +            continue;
>> +
>> +        pdev->gseg = gseg;
>> +        pdev->gbdf = gbdf;
>> +        ret = 0;
>> +    }
>> +
>> +    spin_unlock(&pcidevs_lock);
>> +    return ret;
>> +}
>> +
>> +void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
>> +                   uint16_t dest_mode, uint16_t delivery_mode,
>> +                   uint16_t trig_mode)
>
> Why are these all uint16_t?

uint8_t might better... I will change it.

>
>> +{
>> +    struct guest_iommu *iommu = domain_iommu(d);
>> +
>> +    if ( !iommu )
>> +        return;
>> +
>> +    iommu->msi.vector = vector;
>> +    iommu->msi.dest = dest;
>> +    iommu->msi.dest_mode = dest_mode;
>> +    iommu->msi.trig_mode = trig_mode;
>> +}
>> diff -r 593deed8f62d -r 9cf24ad61936 xen/drivers/passthrough/iommu.c
>> --- a/xen/drivers/passthrough/iommu.c	Thu Feb 09 06:09:17 2012 -0800
>> +++ b/xen/drivers/passthrough/iommu.c	Fri Feb 10 15:49:09 2012 +0100
>> @@ -648,6 +648,40 @@ int iommu_do_domctl(
>>           put_domain(d);
>>           break;
>>
>> +    case XEN_DOMCTL_guest_iommu_op:
>> +    {
>> +        xen_domctl_guest_iommu_op_t * guest_op;
>> +
>> +        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
>> +        {
>> +            gdprintk(XENLOG_ERR,
>> +                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id()
>> failed\n");
>> +            ret = -EINVAL;
>> +            break;
>> +        }
>> +
>> +        guest_op =&(domctl->u.guest_iommu_op);
>> +        switch ( guest_op->op )
>> +        {
>> +            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
>
> Indentation.
can be fixed.

Thanks,
Wei
>
>> +                iommu_set_msi(d, guest_op->u.msi.vector,
>> +                              guest_op->u.msi.dest,
>> +                              guest_op->u.msi.dest_mode,
>> +                              guest_op->u.msi.delivery_mode,
>> +                              guest_op->u.msi.trig_mode);
>> +                ret = 0;
>> +                break;
>> +            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
>> +                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
>> +                                     guest_op->u.bdf_bind.g_bdf,
>> +                                     guest_op->u.bdf_bind.m_seg,
>> +                                     guest_op->u.bdf_bind.m_bdf);
>> +                break;
>> +        }
>> +        put_domain(d);
>> +        break;
>> +    }
>> +
>>       default:
>>           ret = -ENOSYS;
>>           break;
>> diff -r 593deed8f62d -r 9cf24ad61936 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Thu Feb 09 06:09:17 2012 -0800
>> +++ b/xen/include/public/domctl.h	Fri Feb 10 15:49:09 2012 +0100
>> @@ -871,6 +871,31 @@ struct xen_domctl_set_access_required {
>>   typedef struct xen_domctl_set_access_required
>> xen_domctl_set_access_required_t;
>>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>>
>> +/* 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;
>> +        uint8_t  dest_mode;
>> +        uint8_t  delivery_mode;
>> +        uint8_t  trig_mode;
>
> Indentation again.
>
> Jan
>
>> +        } msi;
>> +        struct bdf_bind {
>> +            uint16_t            g_seg;
>> +            uint16_t            g_bdf;
>> +            uint16_t            m_seg;
>> +            uint16_t            m_bdf;
>> +        } bdf_bind;
>> +    } u;
>> +};
>> +typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
>> +
>>   struct xen_domctl {
>>       uint32_t cmd;
>>   #define XEN_DOMCTL_createdomain                   1
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:38:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsYB-0006t0-1s; Fri, 10 Feb 2012 15:38:15 +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 1RvsY8-0006ru-PL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:38:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328888238!53754577!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18233 invoked from network); 10 Feb 2012 15:37:18 -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; 10 Feb 2012 15:37:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvsY4-0008SN-2p; Fri, 10 Feb 2012 15:38:08 +0000
Date: Fri, 10 Feb 2012 15:38:08 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210153808.GC32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<667191f054c34b6c1e72.1328766352@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <667191f054c34b6c1e72.1328766352@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 7 of 7] x86/mm: When removing/adding a page
	from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 00:45 -0500 on 09 Feb (1328748352), Andres Lagar-Cavilla wrote:
> When removing the m2p mapping it is unconditionally set to invalid, which
> breaks sharing.
> 
> When adding to the physmap, if the previous holder of that entry is a shared
> page, we unshare to default to normal case handling.
> 
> And, we cannot add a shared page directly to the physmap. Proper interfaces
> must be employed, otherwise book-keeping goes awry.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:38:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsYB-0006t0-1s; Fri, 10 Feb 2012 15:38:15 +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 1RvsY8-0006ru-PL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:38:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328888238!53754577!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18233 invoked from network); 10 Feb 2012 15:37:18 -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; 10 Feb 2012 15:37:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvsY4-0008SN-2p; Fri, 10 Feb 2012 15:38:08 +0000
Date: Fri, 10 Feb 2012 15:38:08 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210153808.GC32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<667191f054c34b6c1e72.1328766352@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <667191f054c34b6c1e72.1328766352@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 7 of 7] x86/mm: When removing/adding a page
	from/to the physmap, keep in mind it could be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 00:45 -0500 on 09 Feb (1328748352), Andres Lagar-Cavilla wrote:
> When removing the m2p mapping it is unconditionally set to invalid, which
> breaks sharing.
> 
> When adding to the physmap, if the previous holder of that entry is a shared
> page, we unshare to default to normal case handling.
> 
> And, we cannot add a shared page directly to the physmap. Proper interfaces
> must be employed, otherwise book-keeping goes awry.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:38:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsY9-0006sV-DJ; Fri, 10 Feb 2012 15:38:13 +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 1RvsY7-0006s7-R2
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:38:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328888217!60600626!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MDc5Mg==\n,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcxNjI4ODkgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6179 invoked from network); 10 Feb 2012 15:36:58 -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; 10 Feb 2012 15:36:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q1AFblrN027675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 15:37:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1AFbkj9019366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 15:37:46 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
	q1AFbjZs026133; Fri, 10 Feb 2012 09:37:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 07:37:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F057841886; Fri, 10 Feb 2012 10:34:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rostedt@goodmis.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, 
	x86@kernel.org, linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 10:34:50 -0500
Message-Id: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F3539CC.00B6,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The attached patch fixes RH BZ #742032, #787403, and #745574
and touch x86 subsystem.

The patch description gives a very good overview of the problem and
one solution. The one solution it chooses is not the most architecturally
sound but it does not cause performance degradation. If this your
first time reading this, please read the patch first and then come back to
this cover letter as I've some perf numbers and more detailed explanation here.

A bit of overview of the __page_change_attr_set_clr:

Its purpose is to change page attributes from one type to another.
It is important to understand that the entrance that code:
__page_change_attr_set_clr is guarded by cpa_lock spin-lock - which makes
that whole code be single threaded.

Albeit it seems that if debug mode is turned on, it can run in parallel. The
effect of using the posted patch is that __page_change_attr_set_clr() will be
affected when we change caching attributes on 4KB pages and/or the NX flag.

The execution of __page_change_attr_set_clr is concentrated in
(looked for ioremap_* and set_pages_*):
 - during bootup ("Write protecting the ..")
 - suspend/resume and graphic adapters evicting their buffers from the card
   to RAM (which is usually done during suspend but can be done via the
   'evict' attribute in debugfs)
 - when setting the memory for the cursor (AGP cards using i8xx chipset) -
   done during bootup and startup of Xserver.
 - setting up memory for Intel GTT scratch (i9xx) page (done during bootup)
 - payload (purgatory code) for kexec (done during kexec -l).
 - ioremap_* during PCI devices load - InfiniBand and video cards like to use
   ioremap_wc.
 - Intel, radeon, nouveau running into memory pressure and evicting pages from
   their GEM/TTM pool (once an hour or so if compiling a lot with only 4GB).

These are the cases I found when running on baremetal (and Xen) using a normal
Fedora Core 16 distro.

The alternate solution to the problem I am trying to solve, which is much
more architecturally sound (but has some perf disadvantages) is to wrap
the pte_flags with paravirt call everywhere. For that these patches two patches:
http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch

make the pte_flags function (after bootup and patching with alternative asm)
look as so:

   48 89 f8             	mov    %rdi,%rax
   66 66 66 90          	data32 data32 xchg %ax,%ax

[the 66 66 .. is 'nop']. Looks good right? Well, it does work very well on Intel
(used an i3 2100), but on AMD A8-3850 it hits a performance wall - that I found out
is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled in (but the tracer
is set to the default 'nop'). If I disable that specific config option the numbers
are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on the AMD box.
Interestingly enough I only see these on AMD machines - not on the Intel ones.

The benchmarks (kernbench 5 times) were carried out using a Fedora Core 16 .config in
single-mode bootup with the swap disk enabled.

I ran some benchmarks (kernbench) under an i3 2100 and AMD A8-3850 and
the results are in:

https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdHBOaUJzckRrNTdtN0FZcm5pLXNCbWc
and
https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdDJLRTZGbDB0S0Eta0FHd0lkZThOM0E

respectively (all aggregated with raw data and pictures is in
http://darnok.org/results/baseline_pte_flags_pte_attrs/)

The interesting thing is that on Intel i3 2100 it does not matter which solution
is chosen - just to make sure I also ran it on 32 logical CPU SandyBridge beast and it just
breezed through this with no trouble. On AMD A8-3850 it stumbles when using the non-posted
version - wrapping the pte_flags with paravirt everywhere. Even if the code is optimized so
that it ends up looking as so:

        pushq   %rax,%rdi	[the pte]
        mov     %rdi,%rax       [the paravirt ident patching - used to be callq]
        nop
        nop
        nop
        nop
	[and here the check for !pgprot_val(cpa->mask_clr) happens]
        movq    16(%rbx), %rdi          [cpa->mask_clr -> rdi]
        notq    %rdi
        andq    %rax, %rdi

vs where there was none of this (that is a virgin 3.2-rc4):

        ...
	[and here the check for !pgprot_val(cpa->mask_clr) happens]
        movq    16(%rbx), %rdi          [cpa->mask_clr -> rdi]
        notq    %rdi
        andq    %rax, %rdi

[The full .S annotate outputs, are at http://darnok.org/results/baseline_pte_flags_pte_attrs/]

So on AMD if I use the posted patch  - where I wrap the pte_flags in just one specific place
(__page_change_attr_set_clr) - the degradation disappears.

I called that case the pte_attrs in the benchmarks numbers. It could be that the
AMD degradation is due to insertion of improper nops in the 'callq *pv_mmu_ops+104' space
but not sure. [edit: That was my original thinking but after some more runs it looks
to be due to whatever CONFIG_FUNCTION_TRACER introduces]

The posted patch (pte_attrs), introduces three extra operations
(http://darnok.org/results/baseline_pte_flags_pte_attrs/baseline-vs-pte_attrs.diff)

        call    pte_val         [this calls mcount and does the pvops call (which gets patched over)]
        movq    %r14, %rdi      [used for pte_pfn call right after the next movq]
        movq    %rax, -144(%rbp)[save our new pte flag value on stack]

        [.. call pte_pfn - which the original code did as well]

Performance wise it was on par (on in one case faster?) than baseline (v3.2-rc4 virgin).
This is on Intel and AMD.

Naturally if the "# CONFIG_PARAVIRT is not set", the assembler code is _exactly_ the same
as before this patch (no surprise since it ends up becoming native_pte_flags)
and the performance is on par.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:38:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsY9-0006sV-DJ; Fri, 10 Feb 2012 15:38:13 +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 1RvsY7-0006s7-R2
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:38:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328888217!60600626!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MDc5Mg==\n,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcxNjI4ODkgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6179 invoked from network); 10 Feb 2012 15:36:58 -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; 10 Feb 2012 15:36:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q1AFblrN027675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 15:37:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1AFbkj9019366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 15:37:46 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
	q1AFbjZs026133; Fri, 10 Feb 2012 09:37:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 07:37:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F057841886; Fri, 10 Feb 2012 10:34:52 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rostedt@goodmis.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, 
	x86@kernel.org, linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 10:34:50 -0500
Message-Id: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F3539CC.00B6,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The attached patch fixes RH BZ #742032, #787403, and #745574
and touch x86 subsystem.

The patch description gives a very good overview of the problem and
one solution. The one solution it chooses is not the most architecturally
sound but it does not cause performance degradation. If this your
first time reading this, please read the patch first and then come back to
this cover letter as I've some perf numbers and more detailed explanation here.

A bit of overview of the __page_change_attr_set_clr:

Its purpose is to change page attributes from one type to another.
It is important to understand that the entrance that code:
__page_change_attr_set_clr is guarded by cpa_lock spin-lock - which makes
that whole code be single threaded.

Albeit it seems that if debug mode is turned on, it can run in parallel. The
effect of using the posted patch is that __page_change_attr_set_clr() will be
affected when we change caching attributes on 4KB pages and/or the NX flag.

The execution of __page_change_attr_set_clr is concentrated in
(looked for ioremap_* and set_pages_*):
 - during bootup ("Write protecting the ..")
 - suspend/resume and graphic adapters evicting their buffers from the card
   to RAM (which is usually done during suspend but can be done via the
   'evict' attribute in debugfs)
 - when setting the memory for the cursor (AGP cards using i8xx chipset) -
   done during bootup and startup of Xserver.
 - setting up memory for Intel GTT scratch (i9xx) page (done during bootup)
 - payload (purgatory code) for kexec (done during kexec -l).
 - ioremap_* during PCI devices load - InfiniBand and video cards like to use
   ioremap_wc.
 - Intel, radeon, nouveau running into memory pressure and evicting pages from
   their GEM/TTM pool (once an hour or so if compiling a lot with only 4GB).

These are the cases I found when running on baremetal (and Xen) using a normal
Fedora Core 16 distro.

The alternate solution to the problem I am trying to solve, which is much
more architecturally sound (but has some perf disadvantages) is to wrap
the pte_flags with paravirt call everywhere. For that these patches two patches:
http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch

make the pte_flags function (after bootup and patching with alternative asm)
look as so:

   48 89 f8             	mov    %rdi,%rax
   66 66 66 90          	data32 data32 xchg %ax,%ax

[the 66 66 .. is 'nop']. Looks good right? Well, it does work very well on Intel
(used an i3 2100), but on AMD A8-3850 it hits a performance wall - that I found out
is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled in (but the tracer
is set to the default 'nop'). If I disable that specific config option the numbers
are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on the AMD box.
Interestingly enough I only see these on AMD machines - not on the Intel ones.

The benchmarks (kernbench 5 times) were carried out using a Fedora Core 16 .config in
single-mode bootup with the swap disk enabled.

I ran some benchmarks (kernbench) under an i3 2100 and AMD A8-3850 and
the results are in:

https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdHBOaUJzckRrNTdtN0FZcm5pLXNCbWc
and
https://docs.google.com/spreadsheet/ccc?key=0Aj5ukWh4htwMdDJLRTZGbDB0S0Eta0FHd0lkZThOM0E

respectively (all aggregated with raw data and pictures is in
http://darnok.org/results/baseline_pte_flags_pte_attrs/)

The interesting thing is that on Intel i3 2100 it does not matter which solution
is chosen - just to make sure I also ran it on 32 logical CPU SandyBridge beast and it just
breezed through this with no trouble. On AMD A8-3850 it stumbles when using the non-posted
version - wrapping the pte_flags with paravirt everywhere. Even if the code is optimized so
that it ends up looking as so:

        pushq   %rax,%rdi	[the pte]
        mov     %rdi,%rax       [the paravirt ident patching - used to be callq]
        nop
        nop
        nop
        nop
	[and here the check for !pgprot_val(cpa->mask_clr) happens]
        movq    16(%rbx), %rdi          [cpa->mask_clr -> rdi]
        notq    %rdi
        andq    %rax, %rdi

vs where there was none of this (that is a virgin 3.2-rc4):

        ...
	[and here the check for !pgprot_val(cpa->mask_clr) happens]
        movq    16(%rbx), %rdi          [cpa->mask_clr -> rdi]
        notq    %rdi
        andq    %rax, %rdi

[The full .S annotate outputs, are at http://darnok.org/results/baseline_pte_flags_pte_attrs/]

So on AMD if I use the posted patch  - where I wrap the pte_flags in just one specific place
(__page_change_attr_set_clr) - the degradation disappears.

I called that case the pte_attrs in the benchmarks numbers. It could be that the
AMD degradation is due to insertion of improper nops in the 'callq *pv_mmu_ops+104' space
but not sure. [edit: That was my original thinking but after some more runs it looks
to be due to whatever CONFIG_FUNCTION_TRACER introduces]

The posted patch (pte_attrs), introduces three extra operations
(http://darnok.org/results/baseline_pte_flags_pte_attrs/baseline-vs-pte_attrs.diff)

        call    pte_val         [this calls mcount and does the pvops call (which gets patched over)]
        movq    %r14, %rdi      [used for pte_pfn call right after the next movq]
        movq    %rax, -144(%rbp)[save our new pte flag value on stack]

        [.. call pte_pfn - which the original code did as well]

Performance wise it was on par (on in one case faster?) than baseline (v3.2-rc4 virgin).
This is on Intel and AMD.

Naturally if the "# CONFIG_PARAVIRT is not set", the assembler code is _exactly_ the same
as before this patch (no surprise since it ends up becoming native_pte_flags)
and the performance is on par.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:38:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsYX-0006yW-Fn; Fri, 10 Feb 2012 15:38:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvsYW-0006x5-3j
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:38:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328888306!10967613!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2855 invoked from network); 10 Feb 2012 15:38:29 -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; 10 Feb 2012 15:38: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 q1AFbm4F032650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 15:37:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1AFblQb027117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 15:37:48 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
	q1AFbkIu006132; Fri, 10 Feb 2012 09:37:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 07:37:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 062974171F; Fri, 10 Feb 2012 10:34:53 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rostedt@goodmis.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, 
	x86@kernel.org, linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 10:34:51 -0500
Message-Id: <1328888091-9692-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F3539CF.0084,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, stable@kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86/cpa: Use pte_attrs instead of pte_flags on
	CPA/set_p.._wb/wc operations.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When using the paravirt interface, most of the page operations are wrapped
in the pvops interface. The one that is not is the pte_flags. The reason
being that for most cases, the "raw" PTE flag values for baremetal and whatever
pvops platform is running (in this case) - share the same bit meaning.

Except for PAT. Under Linux, the PAT MSR is written to be:

          PAT4                 PAT0
+---+----+----+----+-----+----+----+
 WC | WC | WB | UC | UC- | WC | WB |  <= Linux
+---+----+----+----+-----+----+----+
 WC | WT | WB | UC | UC- | WT | WB |  <= BIOS
+---+----+----+----+-----+----+----+
 WC | WP | WC | UC | UC- | WT | WB |  <= Xen
+---+----+----+----+-----+----+----+

The lookup of this index table translates to looking up
Bit 7, Bit 4, and Bit 3 of PTE:

 PAT/PSE (bit 7) ... PCD (bit 4) .. PWT (bit 3).

If all bits are off, then we are using PAT0. If bit 3 turned on,
then we are using PAT1, if bit 3 and bit 4, then PAT2..

Back to the PAT MSR table:

As you can see, the PAT1 translates to PAT4 under Xen. Under Linux
we only use PAT0, PAT1, and PAT2 for the caching as:

 WB = none (so PAT0)
 WC = PWT (bit 3 on)
 UC = PWT | PCD (bit 3 and 4 are on).

But to make it work with Xen, we end up doing for WC a translation:

 PWT (so bit 3 on) --> PAT (so bit 7 is on) and clear bit 3

And to translate back (when the paravirt pte_val is used) we would:

 PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.

This works quite well, except if code uses the pte_flags, as pte_flags
reads the raw value and does not go through the paravirt. Which means
that if (when running under Xen):

 1) we allocate some pages.
 2) call set_pages_array_wc, which ends up calling:
     __page_change_att_set_clr(.., __pgprot(__PAGE_WC),  /* set */
                                 , __pgprot(__PAGE_MASK), /* clear */
    which ends up reading the _raw_ PTE flags and _only_ look at the
    _PTE_FLAG_MASK contents with __PAGE_MASK cleared (0x18) and
    __PAGE_WC (0x8) set.

     read raw *pte -> 0x67
     *pte = 0x67 & ^0x18 | 0x8
     *pte = 0x67 & 0xfffffe7 | 0x8
     *pte = 0x6f

   [now set_pte_atomic is called, and 0x6f is written in, but under
    xen_make_pte, the bit 3 is translated to bit 7, so it ends up
    writting 0xa7, which is correct]

 3) do something to them.
 4) call set_pages_array_wb
     __page_change_att_set_clr(.., __pgprot(__PAGE_WB),  /* set */
                                 , __pgprot(__PAGE_MASK), /* clear */
    which ends up reading the _raw_ PTE and _only_ look at the
    _PTE_FLAG_MASK contents with _PAGE_MASK cleared (0x18) and
    __PAGE_WB (0x0) set:

     read raw *pte -> 0xa7
     *pte = 0xa7 & &0x18 | 0
     *pte = 0xa7 & 0xfffffe7 | 0
     *pte = 0xa7

   [we check whether the old PTE is different from the new one

    if (pte_val(old_pte) != pte_val(new_pte)) {
        set_pte_atomic(kpte, new_pte);
        ...

   and find out that 0xA7 == 0xA7 so we do not write the new PTE value in]

   End result is that we failed at removing the WC caching bit!

 5) free them.
   [and have pages with PAT4 (bit 7) set, so other subsystems end up using
    the pages that have the write combined bit set resulting in crashes. Yikes!].

The fix, which this patch proposes, is to wrap the pte_pgprot in the CPA
code with newly introduced pte_attrs which can go through the pvops interface
to get the "emulated" value instead of the raw. Naturally if CONFIG_PARAVIRT is
not set, it would end calling native_pte_val.

The other way to fix this is by wrapping pte_flags and go through the pvops
interface and it really is the Right Thing to do.  The problem is, that past
experience with mprotect stuff demonstrates that it be really expensive in inner
loops, and pte_flags() is used in some very perf-critical areas.

Example code to run this and see the various mysterious subsystems/applications
crashing

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("wb_to_wc_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION(WB_TO_WC);

static int thread(void *arg)
{
	struct page *a[MAX_PAGES];
	unsigned int i, j;
	do {
		for (j = 0, i = 0;i < MAX_PAGES; i++, j++) {
			a[i] = alloc_page(GFP_KERNEL);
			if (!a[i])
				break;
		}
		set_pages_array_wc(a, j);
		set_current_state(TASK_INTERRUPTIBLE);
		schedule_timeout_interruptible(HZ);
		for (i = 0; i < j; i++) {
			unsigned long *addr = page_address(a[i]);
			if (addr) {
				memset(addr, 0xc2, PAGE_SIZE);
			}
		}
		set_pages_array_wb(a, j);
		for (i = 0; i< MAX_PAGES; i++) {
			if (a[i])
				__free_page(a[i]);
			a[i] = NULL;
		}
	} while (!kthread_should_stop());
	return 0;
}
static struct task_struct *t;
static int __init wb_to_wc_init(void)
{
	t = kthread_run(thread, NULL, "wb_to_wc_and_back");
	return 0;
}
static void __exit wb_to_wc_exit(void)
{
	if (t)
		kthread_stop(t);
}
module_init(wb_to_wc_init);
module_exit(wb_to_wc_exit);

This fixes RH BZ #742032, #787403, and #745574
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Tom Goetz <tom.goetz@virtualcomputer.com>
CC: stable@kernel.org
---
 arch/x86/include/asm/pgtable.h |    5 +++++
 arch/x86/mm/pageattr.c         |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..fa7bd2c 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -349,6 +349,11 @@ static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
 	return __pgprot(preservebits | addbits);
 }
 
+static inline pgprot_t pte_attrs(pte_t pte)
+{
+	return __pgprot(pte_val(pte) & PTE_FLAGS_MASK);
+}
+
 #define pte_pgprot(x) __pgprot(pte_flags(x) & PTE_FLAGS_MASK)
 
 #define canon_pgprot(p) __pgprot(massage_pgprot(p))
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index e1ebde3..1ae1b4b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -651,7 +651,7 @@ repeat:
 
 	if (level == PG_LEVEL_4K) {
 		pte_t new_pte;
-		pgprot_t new_prot = pte_pgprot(old_pte);
+		pgprot_t new_prot = pte_attrs(old_pte);
 		unsigned long pfn = pte_pfn(old_pte);
 
 		pgprot_val(new_prot) &= ~pgprot_val(cpa->mask_clr);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:38:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsYX-0006yW-Fn; Fri, 10 Feb 2012 15:38:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RvsYW-0006x5-3j
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:38:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328888306!10967613!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2855 invoked from network); 10 Feb 2012 15:38:29 -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; 10 Feb 2012 15:38: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 q1AFbm4F032650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 15:37:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1AFblQb027117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 15:37:48 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
	q1AFbkIu006132; Fri, 10 Feb 2012 09:37:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 07:37:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 062974171F; Fri, 10 Feb 2012 10:34:53 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rostedt@goodmis.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, 
	x86@kernel.org, linux-kernel@vger.kernel.org
Date: Fri, 10 Feb 2012 10:34:51 -0500
Message-Id: <1328888091-9692-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F3539CF.0084,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, stable@kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86/cpa: Use pte_attrs instead of pte_flags on
	CPA/set_p.._wb/wc operations.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When using the paravirt interface, most of the page operations are wrapped
in the pvops interface. The one that is not is the pte_flags. The reason
being that for most cases, the "raw" PTE flag values for baremetal and whatever
pvops platform is running (in this case) - share the same bit meaning.

Except for PAT. Under Linux, the PAT MSR is written to be:

          PAT4                 PAT0
+---+----+----+----+-----+----+----+
 WC | WC | WB | UC | UC- | WC | WB |  <= Linux
+---+----+----+----+-----+----+----+
 WC | WT | WB | UC | UC- | WT | WB |  <= BIOS
+---+----+----+----+-----+----+----+
 WC | WP | WC | UC | UC- | WT | WB |  <= Xen
+---+----+----+----+-----+----+----+

The lookup of this index table translates to looking up
Bit 7, Bit 4, and Bit 3 of PTE:

 PAT/PSE (bit 7) ... PCD (bit 4) .. PWT (bit 3).

If all bits are off, then we are using PAT0. If bit 3 turned on,
then we are using PAT1, if bit 3 and bit 4, then PAT2..

Back to the PAT MSR table:

As you can see, the PAT1 translates to PAT4 under Xen. Under Linux
we only use PAT0, PAT1, and PAT2 for the caching as:

 WB = none (so PAT0)
 WC = PWT (bit 3 on)
 UC = PWT | PCD (bit 3 and 4 are on).

But to make it work with Xen, we end up doing for WC a translation:

 PWT (so bit 3 on) --> PAT (so bit 7 is on) and clear bit 3

And to translate back (when the paravirt pte_val is used) we would:

 PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.

This works quite well, except if code uses the pte_flags, as pte_flags
reads the raw value and does not go through the paravirt. Which means
that if (when running under Xen):

 1) we allocate some pages.
 2) call set_pages_array_wc, which ends up calling:
     __page_change_att_set_clr(.., __pgprot(__PAGE_WC),  /* set */
                                 , __pgprot(__PAGE_MASK), /* clear */
    which ends up reading the _raw_ PTE flags and _only_ look at the
    _PTE_FLAG_MASK contents with __PAGE_MASK cleared (0x18) and
    __PAGE_WC (0x8) set.

     read raw *pte -> 0x67
     *pte = 0x67 & ^0x18 | 0x8
     *pte = 0x67 & 0xfffffe7 | 0x8
     *pte = 0x6f

   [now set_pte_atomic is called, and 0x6f is written in, but under
    xen_make_pte, the bit 3 is translated to bit 7, so it ends up
    writting 0xa7, which is correct]

 3) do something to them.
 4) call set_pages_array_wb
     __page_change_att_set_clr(.., __pgprot(__PAGE_WB),  /* set */
                                 , __pgprot(__PAGE_MASK), /* clear */
    which ends up reading the _raw_ PTE and _only_ look at the
    _PTE_FLAG_MASK contents with _PAGE_MASK cleared (0x18) and
    __PAGE_WB (0x0) set:

     read raw *pte -> 0xa7
     *pte = 0xa7 & &0x18 | 0
     *pte = 0xa7 & 0xfffffe7 | 0
     *pte = 0xa7

   [we check whether the old PTE is different from the new one

    if (pte_val(old_pte) != pte_val(new_pte)) {
        set_pte_atomic(kpte, new_pte);
        ...

   and find out that 0xA7 == 0xA7 so we do not write the new PTE value in]

   End result is that we failed at removing the WC caching bit!

 5) free them.
   [and have pages with PAT4 (bit 7) set, so other subsystems end up using
    the pages that have the write combined bit set resulting in crashes. Yikes!].

The fix, which this patch proposes, is to wrap the pte_pgprot in the CPA
code with newly introduced pte_attrs which can go through the pvops interface
to get the "emulated" value instead of the raw. Naturally if CONFIG_PARAVIRT is
not set, it would end calling native_pte_val.

The other way to fix this is by wrapping pte_flags and go through the pvops
interface and it really is the Right Thing to do.  The problem is, that past
experience with mprotect stuff demonstrates that it be really expensive in inner
loops, and pte_flags() is used in some very perf-critical areas.

Example code to run this and see the various mysterious subsystems/applications
crashing

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("wb_to_wc_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION(WB_TO_WC);

static int thread(void *arg)
{
	struct page *a[MAX_PAGES];
	unsigned int i, j;
	do {
		for (j = 0, i = 0;i < MAX_PAGES; i++, j++) {
			a[i] = alloc_page(GFP_KERNEL);
			if (!a[i])
				break;
		}
		set_pages_array_wc(a, j);
		set_current_state(TASK_INTERRUPTIBLE);
		schedule_timeout_interruptible(HZ);
		for (i = 0; i < j; i++) {
			unsigned long *addr = page_address(a[i]);
			if (addr) {
				memset(addr, 0xc2, PAGE_SIZE);
			}
		}
		set_pages_array_wb(a, j);
		for (i = 0; i< MAX_PAGES; i++) {
			if (a[i])
				__free_page(a[i]);
			a[i] = NULL;
		}
	} while (!kthread_should_stop());
	return 0;
}
static struct task_struct *t;
static int __init wb_to_wc_init(void)
{
	t = kthread_run(thread, NULL, "wb_to_wc_and_back");
	return 0;
}
static void __exit wb_to_wc_exit(void)
{
	if (t)
		kthread_stop(t);
}
module_init(wb_to_wc_init);
module_exit(wb_to_wc_exit);

This fixes RH BZ #742032, #787403, and #745574
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Tom Goetz <tom.goetz@virtualcomputer.com>
CC: stable@kernel.org
---
 arch/x86/include/asm/pgtable.h |    5 +++++
 arch/x86/mm/pageattr.c         |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..fa7bd2c 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -349,6 +349,11 @@ static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
 	return __pgprot(preservebits | addbits);
 }
 
+static inline pgprot_t pte_attrs(pte_t pte)
+{
+	return __pgprot(pte_val(pte) & PTE_FLAGS_MASK);
+}
+
 #define pte_pgprot(x) __pgprot(pte_flags(x) & PTE_FLAGS_MASK)
 
 #define canon_pgprot(p) __pgprot(massage_pgprot(p))
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index e1ebde3..1ae1b4b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -651,7 +651,7 @@ repeat:
 
 	if (level == PG_LEVEL_4K) {
 		pte_t new_pte;
-		pgprot_t new_prot = pte_pgprot(old_pte);
+		pgprot_t new_prot = pte_attrs(old_pte);
 		unsigned long pfn = pte_pfn(old_pte);
 
 		pgprot_val(new_prot) &= ~pgprot_val(cpa->mask_clr);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:44:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsdl-0007Ya-B3; Fri, 10 Feb 2012 15:44:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvsdj-0007YN-NL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:43:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328888633!12861052!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19368 invoked from network); 10 Feb 2012 15:43:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:43:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvsdb-0008Tz-3r; Fri, 10 Feb 2012 15:43:51 +0000
Date: Fri, 10 Feb 2012 15:43:51 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210154351.GD32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
	<20120210153625.GB32107@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120210153625.GB32107@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:36 +0000 on 10 Feb (1328888185), Tim Deegan wrote:
> At 06:45 -0800 on 09 Feb (1328769948), Andres Lagar-Cavilla wrote:
> > > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> > 
> > Great, thanks George!
> > 
> > Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or, wait
> > for more comments. Or, send a micro-patch later removing the BUG_ON.
> 
> One of the later patches needs a bit of work; when you're addressing
> that, can you refresh this to drop the BUG_ON and add the ack? 

Scratch that - on closer inspection the other patch is fine.  I'll tidy
this BUG_ON up as I apply it. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:44:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsdl-0007Ya-B3; Fri, 10 Feb 2012 15:44:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvsdj-0007YN-NL
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:43:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328888633!12861052!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19368 invoked from network); 10 Feb 2012 15:43:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:43:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvsdb-0008Tz-3r; Fri, 10 Feb 2012 15:43:51 +0000
Date: Fri, 10 Feb 2012 15:43:51 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210154351.GD32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
	<20120210153625.GB32107@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120210153625.GB32107@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:36 +0000 on 10 Feb (1328888185), Tim Deegan wrote:
> At 06:45 -0800 on 09 Feb (1328769948), Andres Lagar-Cavilla wrote:
> > > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> > 
> > Great, thanks George!
> > 
> > Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or, wait
> > for more comments. Or, send a micro-patch later removing the BUG_ON.
> 
> One of the later patches needs a bit of work; when you're addressing
> that, can you refresh this to drop the BUG_ON and add the ack? 

Scratch that - on closer inspection the other patch is fine.  I'll tidy
this BUG_ON up as I apply it. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:45:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsei-0007cz-Sq; Fri, 10 Feb 2012 15:45:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1Rvseh-0007cM-C9
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:44:59 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328888693!14282512!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24872 invoked from network); 10 Feb 2012 15:44:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 15:44:53 -0000
Received: from p5b2e45df.dip.t-dialin.net ([91.46.69.223] 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 1Rvseb-0004jh-71; Fri, 10 Feb 2012 15:44:53 +0000
Message-ID: <4F353B73.1050309@canonical.com>
Date: Fri, 10 Feb 2012 16:44:51 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	Ian Campbell <ian.campbell@citrix.com>
X-Enigmail-Version: 1.3.5
Subject: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If I did not miss something, it looks to me like guests started with xl will use
the bridge specified in the guest config or xenbr0 as a default.
Just wondering whether adding a defaultbridge config option to xl.conf would be
considered a waste of time (because its not desired to have that) or some worth
of adding when I would come up with a patch?

Cheers,
-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:45:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsei-0007cz-Sq; Fri, 10 Feb 2012 15:45:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1Rvseh-0007cM-C9
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:44:59 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328888693!14282512!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24872 invoked from network); 10 Feb 2012 15:44:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 15:44:53 -0000
Received: from p5b2e45df.dip.t-dialin.net ([91.46.69.223] 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 1Rvseb-0004jh-71; Fri, 10 Feb 2012 15:44:53 +0000
Message-ID: <4F353B73.1050309@canonical.com>
Date: Fri, 10 Feb 2012 16:44:51 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	Ian Campbell <ian.campbell@citrix.com>
X-Enigmail-Version: 1.3.5
Subject: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If I did not miss something, it looks to me like guests started with xl will use
the bridge specified in the guest config or xenbr0 as a default.
Just wondering whether adding a defaultbridge config option to xl.conf would be
considered a waste of time (because its not desired to have that) or some worth
of adding when I would come up with a patch?

Cheers,
-Stefan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:46:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsfk-0007jX-Bz; Fri, 10 Feb 2012 15:46:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rvsfi-0007j3-VG
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:46:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328888755!12861368!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25600 invoked from network); 10 Feb 2012 15:45:56 -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; 10 Feb 2012 15:45:56 -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 q1AFjol5009024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 15:45:51 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
	q1AFjnmV010071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 15:45:49 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
	q1AFjmuS012179; Fri, 10 Feb 2012 09:45:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 07:45:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 985FC401A2; Fri, 10 Feb 2012 10:42:55 -0500 (EST)
Date: Fri, 10 Feb 2012 10:42:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120210154255.GA9857@phenom.dumpdata.com>
References: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
	<1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
	<1328886226.6133.271.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328886226.6133.271.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F353BB0.004C,ss=1,re=0.000,fgs=0
Cc: gregkh@linuxfoundation.org,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/cpu: Make VCPU hotplug code online CPUs
 properly.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, 2012 at 03:03:46PM +0000, Ian Campbell wrote:
> On Fri, 2012-02-10 at 14:43 +0000, Konrad Rzeszutek Wilk wrote:
> > Offlining CPUs works. Onlining does not work anymore and it looks
> > like we were missing a cpu_up() call in the hotplug bring up path.
> 
> Wasn't this a deliberate decision as part of the pvops upstreaming to be
> consistent with native cpu hotplug? After hotplugging a CPU

Ah, hadn't seen that. Thanks for spotting that!

> administrator action is needed to actually online it.
> 
> http://xen.1045712.n5.nabble.com/cpu-down-but-no-cpu-up-in-drivers-xen-cpu-hotplug-c-td2545244.html
> 
> The fix is to add a udev rule:
> http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug

Ah, so I see that it is run (the udev does it) but it actually does not bring the CPU up.

It looks as if the 'online' attribute is actually not present at all, even
after bringing the CPU "up-but-not-online". Oh joy! Should be easy to reproduce
on baremetal.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:46:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsfk-0007jX-Bz; Fri, 10 Feb 2012 15:46:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rvsfi-0007j3-VG
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:46:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328888755!12861368!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25600 invoked from network); 10 Feb 2012 15:45:56 -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; 10 Feb 2012 15:45:56 -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 q1AFjol5009024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 15:45:51 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
	q1AFjnmV010071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 15:45:49 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
	q1AFjmuS012179; Fri, 10 Feb 2012 09:45:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 07:45:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 985FC401A2; Fri, 10 Feb 2012 10:42:55 -0500 (EST)
Date: Fri, 10 Feb 2012 10:42:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120210154255.GA9857@phenom.dumpdata.com>
References: <1328885033-8450-1-git-send-email-konrad.wilk@oracle.com>
	<1328885033-8450-2-git-send-email-konrad.wilk@oracle.com>
	<1328886226.6133.271.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328886226.6133.271.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F353BB0.004C,ss=1,re=0.000,fgs=0
Cc: gregkh@linuxfoundation.org,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen/cpu: Make VCPU hotplug code online CPUs
 properly.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, 2012 at 03:03:46PM +0000, Ian Campbell wrote:
> On Fri, 2012-02-10 at 14:43 +0000, Konrad Rzeszutek Wilk wrote:
> > Offlining CPUs works. Onlining does not work anymore and it looks
> > like we were missing a cpu_up() call in the hotplug bring up path.
> 
> Wasn't this a deliberate decision as part of the pvops upstreaming to be
> consistent with native cpu hotplug? After hotplugging a CPU

Ah, hadn't seen that. Thanks for spotting that!

> administrator action is needed to actually online it.
> 
> http://xen.1045712.n5.nabble.com/cpu-down-but-no-cpu-up-in-drivers-xen-cpu-hotplug-c-td2545244.html
> 
> The fix is to add a udev rule:
> http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug

Ah, so I see that it is run (the udev does it) but it actually does not bring the CPU up.

It looks as if the 'online' attribute is actually not present at all, even
after bringing the CPU "up-but-not-online". Oh joy! Should be easy to reproduce
on baremetal.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:48:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvshj-00081f-T9; Fri, 10 Feb 2012 15:48:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvshi-00080C-FF
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:48:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328888879!14840583!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMzU4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10973 invoked from network); 10 Feb 2012 15:48:00 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-12.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 15:48:00 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 316B371406B;
	Fri, 10 Feb 2012 07:47:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LAGHoAbem9aLd4Qgp4bdIboyHuTsTAuN8KbB7iQ+wXku
	fjK1ciIKJEgYsLLRWmKBb5z5wXs90qrHXAzTpGv9+BRjPZBcg1GnwThcQYIf77cC
	scYz6l/XZZPTvw4JmH1xe3p5B3g8Psz1pyzOSHNxCUGRc+kGXye2MySy1eLiK9M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=L74wnX5scxufeKrJ2zP/2m2Fevs=; b=i46xwvql
	+4mXcDJsyHGuJU6OcWnbNq2INKYfz/s6JmLTtTb1I/LP+L8Z0EnJghO0dOdMixHT
	QxNj6+ft7e2MakcJ4zeZzSyJLmsPlgUR27DK/EatVSrPTBvi85UXSbBILp45WOpJ
	uG8bgcRvoGrI0tMjG5Z+orLvXsTKYh6VDp8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id A72D971406F; 
	Fri, 10 Feb 2012 07:47:58 -0800 (PST)
Received: from 69.165.142.248 (proxying for 69.165.142.248)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 07:47:59 -0800
Message-ID: <03d952f7c004ecaa621edaada17ec16a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120210154351.GD32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
	<20120210153625.GB32107@ocelot.phlegethon.org>
	<20120210154351.GD32107@ocelot.phlegethon.org>
Date: Fri, 10 Feb 2012 07:47:59 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 15:36 +0000 on 10 Feb (1328888185), Tim Deegan wrote:
>> At 06:45 -0800 on 09 Feb (1328769948), Andres Lagar-Cavilla wrote:
>> > > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> >
>> > Great, thanks George!
>> >
>> > Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or,
>> wait
>> > for more comments. Or, send a micro-patch later removing the BUG_ON.
>>
>> One of the later patches needs a bit of work; when you're addressing
>> that, can you refresh this to drop the BUG_ON and add the ack?
>
> Scratch that - on closer inspection the other patch is fine.  I'll tidy
> this BUG_ON up as I apply it.

Sweet :)
Andres
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:48:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvshj-00081f-T9; Fri, 10 Feb 2012 15:48:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvshi-00080C-FF
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:48:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328888879!14840583!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMzU4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10973 invoked from network); 10 Feb 2012 15:48:00 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-12.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 15:48:00 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 316B371406B;
	Fri, 10 Feb 2012 07:47:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LAGHoAbem9aLd4Qgp4bdIboyHuTsTAuN8KbB7iQ+wXku
	fjK1ciIKJEgYsLLRWmKBb5z5wXs90qrHXAzTpGv9+BRjPZBcg1GnwThcQYIf77cC
	scYz6l/XZZPTvw4JmH1xe3p5B3g8Psz1pyzOSHNxCUGRc+kGXye2MySy1eLiK9M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=L74wnX5scxufeKrJ2zP/2m2Fevs=; b=i46xwvql
	+4mXcDJsyHGuJU6OcWnbNq2INKYfz/s6JmLTtTb1I/LP+L8Z0EnJghO0dOdMixHT
	QxNj6+ft7e2MakcJ4zeZzSyJLmsPlgUR27DK/EatVSrPTBvi85UXSbBILp45WOpJ
	uG8bgcRvoGrI0tMjG5Z+orLvXsTKYh6VDp8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id A72D971406F; 
	Fri, 10 Feb 2012 07:47:58 -0800 (PST)
Received: from 69.165.142.248 (proxying for 69.165.142.248)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 07:47:59 -0800
Message-ID: <03d952f7c004ecaa621edaada17ec16a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120210154351.GD32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
	<20120210153625.GB32107@ocelot.phlegethon.org>
	<20120210154351.GD32107@ocelot.phlegethon.org>
Date: Fri, 10 Feb 2012 07:47:59 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 15:36 +0000 on 10 Feb (1328888185), Tim Deegan wrote:
>> At 06:45 -0800 on 09 Feb (1328769948), Andres Lagar-Cavilla wrote:
>> > > Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> >
>> > Great, thanks George!
>> >
>> > Tim, I can resend with BUG_ON eliminated and George's Acked-by. Or,
>> wait
>> > for more comments. Or, send a micro-patch later removing the BUG_ON.
>>
>> One of the later patches needs a bit of work; when you're addressing
>> that, can you refresh this to drop the BUG_ON and add the ack?
>
> Scratch that - on closer inspection the other patch is fine.  I'll tidy
> this BUG_ON up as I apply it.

Sweet :)
Andres
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:50:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:50:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsjX-0008FE-ED; Fri, 10 Feb 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1RvsjV-0008F0-99
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:49:57 +0000
Received: from [85.158.139.83:13286] by server-12.bemta-5.messagelabs.com id
	B7/CC-30830-4AC353F4; Fri, 10 Feb 2012 15:49:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328888995!14535314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24416 invoked from network); 10 Feb 2012 15:49:56 -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;
	10 Feb 2012 15:49:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:49:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 15:49:32 +0000
Date: Fri, 10 Feb 2012 15:53:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2074795121-1328889196=:7456"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-2074795121-1328889196=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Fri, 10 Feb 2012, Roger Pau Monné wrote:
> Hello,
> 
> I've recently setup a Linux Dom0 with a 3.0.17 kernel and Xen 4.1.2,
> and since the 3.x series doesn't have blktap support I'm using qdisk
> to attach raw images. I've been playing with small images, something
> like 1GB, and everything seemed fine, speed was not fantastic but it
> was ok. Today I've set up a bigger machine, with a 20GB raw hdd and
> the disk write throughput is really slow, inferior to 0.5MB/s. I'm
> trying to install a Debian PV there, and after more than 3 hours it is
> still installing the base system.
> 
> I've looked at the xenstore backend entries, and everything looks fine:
> 
> /local/domain/0/backend/qdisk/21/51712/frontend =
> "/local/domain/21/device/vbd/51712"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/params =
> "aio:/hdd/vm/servlet/servlet.img"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/frontend-id = "21"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/online = "1"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/removable = "0"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/bootable = "1"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/state = "4"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/dev = "xvda"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/type = "tap"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/mode = "w"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/feature-barrier = "1"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/info = "0"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/sector-size = "512"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/sectors = "40960000"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/hotplug-status = "connected"   (n0,r21)
> 
> Also, the related qemu-dm process doesn't seem to be hung by CPU, in
> fact it is reporting a CPU usage of 0% almost all the time. I've
> attached to the qemu-dm process with strace, and it is doing lseeks
> and writes like crazy, is this normal? Is there any improvement when
> using qemu-upstream?

Yes, great improvements.
The old qemu-xen uses threads to simulate async IO so it is very slow;
upstream QEMU uses Linux AIO and is much faster.
I wouldn't expect it to hang completely though, that might be a bug.
--8323329-2074795121-1328889196=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-2074795121-1328889196=:7456--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:50:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:50:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsjX-0008FE-ED; Fri, 10 Feb 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1RvsjV-0008F0-99
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:49:57 +0000
Received: from [85.158.139.83:13286] by server-12.bemta-5.messagelabs.com id
	B7/CC-30830-4AC353F4; Fri, 10 Feb 2012 15:49:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328888995!14535314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24416 invoked from network); 10 Feb 2012 15:49:56 -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;
	10 Feb 2012 15:49:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:49:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 15:49:32 +0000
Date: Fri, 10 Feb 2012 15:53:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2074795121-1328889196=:7456"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-2074795121-1328889196=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Fri, 10 Feb 2012, Roger Pau Monné wrote:
> Hello,
> 
> I've recently setup a Linux Dom0 with a 3.0.17 kernel and Xen 4.1.2,
> and since the 3.x series doesn't have blktap support I'm using qdisk
> to attach raw images. I've been playing with small images, something
> like 1GB, and everything seemed fine, speed was not fantastic but it
> was ok. Today I've set up a bigger machine, with a 20GB raw hdd and
> the disk write throughput is really slow, inferior to 0.5MB/s. I'm
> trying to install a Debian PV there, and after more than 3 hours it is
> still installing the base system.
> 
> I've looked at the xenstore backend entries, and everything looks fine:
> 
> /local/domain/0/backend/qdisk/21/51712/frontend =
> "/local/domain/21/device/vbd/51712"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/params =
> "aio:/hdd/vm/servlet/servlet.img"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/frontend-id = "21"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/online = "1"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/removable = "0"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/bootable = "1"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/state = "4"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/dev = "xvda"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/type = "tap"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/mode = "w"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/feature-barrier = "1"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/info = "0"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/sector-size = "512"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/sectors = "40960000"   (n0,r21)
> /local/domain/0/backend/qdisk/21/51712/hotplug-status = "connected"   (n0,r21)
> 
> Also, the related qemu-dm process doesn't seem to be hung by CPU, in
> fact it is reporting a CPU usage of 0% almost all the time. I've
> attached to the qemu-dm process with strace, and it is doing lseeks
> and writes like crazy, is this normal? Is there any improvement when
> using qemu-upstream?

Yes, great improvements.
The old qemu-xen uses threads to simulate async IO so it is very slow;
upstream QEMU uses Linux AIO and is much faster.
I wouldn't expect it to hang completely though, that might be a bug.
--8323329-2074795121-1328889196=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-2074795121-1328889196=:7456--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:50:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsjg-0008Gn-1O; Fri, 10 Feb 2012 15:50:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rvsje-0008Fg-Bq
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:50:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328888999!12856229!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20264 invoked from network); 10 Feb 2012 15:50:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:50:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 15:49:59 +0000
Message-Id: <4F354AB6020000780007267B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 15:49:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
In-Reply-To: <1328758401-24258-1-git-send-email-liang.tang@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 04:33, Tang Liang <liang.tang@oracle.com> wrote:

As noted in a private mail already, this lack a From:, as large parts of
this are quite obviously derived from what we have in our SLE and
openSUSE trees. Feel free to also stick my Signed-off-by in further
down.

> The efi memory is owned by Xen and efi run-time service can not be called
> directly,so a new efi driver is needed by Xen efi.
> We call efi run-time service through the Xen in Xen efi driver.
> 
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> 
> --- a/arch/x86/platform/efi/Makefile
> +++ b/arch/x86/platform/efi/Makefile
> @@ -1 +1,4 @@
>  obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
> +ifdef CONFIG_XEN
> +obj-$(CONFIG_EFI)		+= efi-xen.o

Calling this just xen.c would seem more natural to me. The *-xen.c
naming convention really is necessary only in the legacy (and forward
ported) trees.

> +endif
> diff --git a/arch/x86/platform/efi/efi-xen.c b/arch/x86/platform/efi/efi-xen.c
> new file mode 100644
> index 0000000..f4f6235
> --- /dev/null
> +++ b/arch/x86/platform/efi/efi-xen.c
> @@ -0,0 +1,432 @@
> +/*
> + * Common EFI (Extensible Firmware Interface) support functions
> + * Based on Extensible Firmware Interface Specification version 1.0
> + *
> + * Copyright (C) 1999 VA Linux Systems
> + * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
> + * Copyright (C) 1999-2002 Hewlett-Packard Co.
> + *	David Mosberger-Tang <davidm@hpl.hp.com>
> + *	Stephane Eranian <eranian@hpl.hp.com>
> + * Copyright (C) 2005-2008 Intel Co.
> + *	Fenghua Yu <fenghua.yu@intel.com>
> + *	Bibo Mao <bibo.mao@intel.com>
> + *	Chandramouli Narayanan <mouli@linux.intel.com>
> + *	Huang Ying <ying.huang@intel.com>
> + * Copyright (C) 2011-2012 Oracle Co.
> + *	Liang Tang <liang.tang@oracle.com>
> + *

I think everything between here ...

> + * Copied from efi_32.c to eliminate the duplicated code between EFI
> + * 32/64 support code. --ying 2007-10-26
> + *
> + * All EFI Runtime Services are not implemented yet as EFI only
> + * supports physical mode addressing on SoftSDV. This is to be fixed
> + * in a future version.  --drummond 1999-07-20
> + *
> + * Implemented EFI runtime services and virtual mode calls.  --davidm
> + *
> + * Goutham Rao: <goutham.rao@intel.com>
> + *	Skip non-WB memory and ignore empty memory ranges.

... and here is meaningless in this file.

> + */
>...
> +struct efi __read_mostly efi_xen = {

With this just being copied in an __init function below, this can be
both static and __initdata (or even const __initconst).

> +	.mps                      = EFI_INVALID_TABLE_ADDR,
> +	.acpi                     = EFI_INVALID_TABLE_ADDR,
> +	.acpi20                   = EFI_INVALID_TABLE_ADDR,
> +	.smbios                   = EFI_INVALID_TABLE_ADDR,
> +	.sal_systab               = EFI_INVALID_TABLE_ADDR,
> +	.boot_info                = EFI_INVALID_TABLE_ADDR,
> +	.hcdp                     = EFI_INVALID_TABLE_ADDR,
> +	.uga                      = EFI_INVALID_TABLE_ADDR,
> +	.uv_systab                = EFI_INVALID_TABLE_ADDR,
> +	.get_time                 = xen_efi_get_time,
> +	.set_time                 = xen_efi_set_time,
> +	.get_wakeup_time          = xen_efi_get_wakeup_time,
> +	.set_wakeup_time          = xen_efi_set_wakeup_time,
> +	.get_variable             = xen_efi_get_variable,
> +	.get_next_variable        = xen_efi_get_next_variable,
> +	.set_variable             = xen_efi_set_variable,
> +	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
> +	.query_variable_info      = xen_efi_query_variable_info,
> +	.update_capsule           = xen_efi_update_capsule,
> +	.query_capsule_caps       = xen_efi_query_capsule_caps,
> +};
>...
> +static void efi_enter_virtual_mode_xen(void)  { };
> +static void efi_reserve_boot_services_xen(void) { };

With the generic wrapper checking for NULL pointers I don't see why you
need empty placeholders here.

> +
> +struct efi_init_funcs xen_efi_funcs = {

static const.

> +	.__efi_init		     = efi_init_xen,
> +	.__efi_reserve_boot_services = efi_reserve_boot_services_xen,
> +	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_xen,
> +	.__efi_mem_type		     = efi_mem_type_xen,
> +	.__efi_mem_attributes	     = efi_mem_attributes_xen
> +};
> +
> +static void register_xen_efi_function(void)
> +{
> +	efi_init_function_register(&xen_efi_funcs);
> +}
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -476,6 +476,7 @@ extern struct efi_memory_map memmap;
>  extern void efi_init_function_register(struct efi_init_funcs *funcs);
>  extern void get_efi_table_info(efi_config_table_t *config_tables, int 
> nr_tables,
>  			       struct efi *efi_t);
> +extern void __init xen_efi_probe(void);

No __init in declarations.

Jan

>  
>  /**
>   * efi_range_is_wc - check the WC bit on an address range


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:50:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvsjg-0008Gn-1O; Fri, 10 Feb 2012 15:50:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rvsje-0008Fg-Bq
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:50:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1328888999!12856229!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20264 invoked from network); 10 Feb 2012 15:50:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 15:50:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 15:49:59 +0000
Message-Id: <4F354AB6020000780007267B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 15:49:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <liang.tang@oracle.com>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
In-Reply-To: <1328758401-24258-1-git-send-email-liang.tang@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 04:33, Tang Liang <liang.tang@oracle.com> wrote:

As noted in a private mail already, this lack a From:, as large parts of
this are quite obviously derived from what we have in our SLE and
openSUSE trees. Feel free to also stick my Signed-off-by in further
down.

> The efi memory is owned by Xen and efi run-time service can not be called
> directly,so a new efi driver is needed by Xen efi.
> We call efi run-time service through the Xen in Xen efi driver.
> 
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> 
> --- a/arch/x86/platform/efi/Makefile
> +++ b/arch/x86/platform/efi/Makefile
> @@ -1 +1,4 @@
>  obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
> +ifdef CONFIG_XEN
> +obj-$(CONFIG_EFI)		+= efi-xen.o

Calling this just xen.c would seem more natural to me. The *-xen.c
naming convention really is necessary only in the legacy (and forward
ported) trees.

> +endif
> diff --git a/arch/x86/platform/efi/efi-xen.c b/arch/x86/platform/efi/efi-xen.c
> new file mode 100644
> index 0000000..f4f6235
> --- /dev/null
> +++ b/arch/x86/platform/efi/efi-xen.c
> @@ -0,0 +1,432 @@
> +/*
> + * Common EFI (Extensible Firmware Interface) support functions
> + * Based on Extensible Firmware Interface Specification version 1.0
> + *
> + * Copyright (C) 1999 VA Linux Systems
> + * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
> + * Copyright (C) 1999-2002 Hewlett-Packard Co.
> + *	David Mosberger-Tang <davidm@hpl.hp.com>
> + *	Stephane Eranian <eranian@hpl.hp.com>
> + * Copyright (C) 2005-2008 Intel Co.
> + *	Fenghua Yu <fenghua.yu@intel.com>
> + *	Bibo Mao <bibo.mao@intel.com>
> + *	Chandramouli Narayanan <mouli@linux.intel.com>
> + *	Huang Ying <ying.huang@intel.com>
> + * Copyright (C) 2011-2012 Oracle Co.
> + *	Liang Tang <liang.tang@oracle.com>
> + *

I think everything between here ...

> + * Copied from efi_32.c to eliminate the duplicated code between EFI
> + * 32/64 support code. --ying 2007-10-26
> + *
> + * All EFI Runtime Services are not implemented yet as EFI only
> + * supports physical mode addressing on SoftSDV. This is to be fixed
> + * in a future version.  --drummond 1999-07-20
> + *
> + * Implemented EFI runtime services and virtual mode calls.  --davidm
> + *
> + * Goutham Rao: <goutham.rao@intel.com>
> + *	Skip non-WB memory and ignore empty memory ranges.

... and here is meaningless in this file.

> + */
>...
> +struct efi __read_mostly efi_xen = {

With this just being copied in an __init function below, this can be
both static and __initdata (or even const __initconst).

> +	.mps                      = EFI_INVALID_TABLE_ADDR,
> +	.acpi                     = EFI_INVALID_TABLE_ADDR,
> +	.acpi20                   = EFI_INVALID_TABLE_ADDR,
> +	.smbios                   = EFI_INVALID_TABLE_ADDR,
> +	.sal_systab               = EFI_INVALID_TABLE_ADDR,
> +	.boot_info                = EFI_INVALID_TABLE_ADDR,
> +	.hcdp                     = EFI_INVALID_TABLE_ADDR,
> +	.uga                      = EFI_INVALID_TABLE_ADDR,
> +	.uv_systab                = EFI_INVALID_TABLE_ADDR,
> +	.get_time                 = xen_efi_get_time,
> +	.set_time                 = xen_efi_set_time,
> +	.get_wakeup_time          = xen_efi_get_wakeup_time,
> +	.set_wakeup_time          = xen_efi_set_wakeup_time,
> +	.get_variable             = xen_efi_get_variable,
> +	.get_next_variable        = xen_efi_get_next_variable,
> +	.set_variable             = xen_efi_set_variable,
> +	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
> +	.query_variable_info      = xen_efi_query_variable_info,
> +	.update_capsule           = xen_efi_update_capsule,
> +	.query_capsule_caps       = xen_efi_query_capsule_caps,
> +};
>...
> +static void efi_enter_virtual_mode_xen(void)  { };
> +static void efi_reserve_boot_services_xen(void) { };

With the generic wrapper checking for NULL pointers I don't see why you
need empty placeholders here.

> +
> +struct efi_init_funcs xen_efi_funcs = {

static const.

> +	.__efi_init		     = efi_init_xen,
> +	.__efi_reserve_boot_services = efi_reserve_boot_services_xen,
> +	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_xen,
> +	.__efi_mem_type		     = efi_mem_type_xen,
> +	.__efi_mem_attributes	     = efi_mem_attributes_xen
> +};
> +
> +static void register_xen_efi_function(void)
> +{
> +	efi_init_function_register(&xen_efi_funcs);
> +}
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -476,6 +476,7 @@ extern struct efi_memory_map memmap;
>  extern void efi_init_function_register(struct efi_init_funcs *funcs);
>  extern void get_efi_table_info(efi_config_table_t *config_tables, int 
> nr_tables,
>  			       struct efi *efi_t);
> +extern void __init xen_efi_probe(void);

No __init in declarations.

Jan

>  
>  /**
>   * efi_range_is_wc - check the WC bit on an address range


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:52:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1RvslS-0008W3-Jj; Fri, 10 Feb 2012 15:51:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvslQ-0008VV-On
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:51:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328889110!12808636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29212 invoked from network); 10 Feb 2012 15:51: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;
	10 Feb 2012 15:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:51:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 15:51:50 +0000
Message-ID: <1328889108.6133.272.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 10 Feb 2012 15:51:48 +0000
In-Reply-To: <4F353B73.1050309@canonical.com>
References: <4F353B73.1050309@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 15:44 +0000, Stefan Bader wrote:
> If I did not miss something, it looks to me like guests started with xl will use
> the bridge specified in the guest config or xenbr0 as a default.
> Just wondering whether adding a defaultbridge config option to xl.conf would be
> considered a waste of time (because its not desired to have that) or some worth
> of adding when I would come up with a patch?

Sounds useful enough to me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:52:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1RvslS-0008W3-Jj; Fri, 10 Feb 2012 15:51:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvslQ-0008VV-On
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:51:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328889110!12808636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29212 invoked from network); 10 Feb 2012 15:51: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;
	10 Feb 2012 15:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:51:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 15:51:50 +0000
Message-ID: <1328889108.6133.272.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 10 Feb 2012 15:51:48 +0000
In-Reply-To: <4F353B73.1050309@canonical.com>
References: <4F353B73.1050309@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 15:44 +0000, Stefan Bader wrote:
> If I did not miss something, it looks to me like guests started with xl will use
> the bridge specified in the guest config or xenbr0 as a default.
> Just wondering whether adding a defaultbridge config option to xl.conf would be
> considered a waste of time (because its not desired to have that) or some worth
> of adding when I would come up with a patch?

Sounds useful enough to me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:56:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvspn-0000MT-AR; Fri, 10 Feb 2012 15:56:27 +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 1Rvspk-0000ML-LO
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:56:25 +0000
Received: from [85.158.139.83:52933] by server-6.bemta-5.messagelabs.com id
	18/CE-04784-72E353F4; Fri, 10 Feb 2012 15:56:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328889381!14572612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28686 invoked from network); 10 Feb 2012 15:56:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 15:56:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21832908"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 10:56:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 10:56:20 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1AFuJWh008087; Fri, 10 Feb 2012 07:56:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
Message-ID: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 10 Feb 2012 15:56:18 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: stefano.stabellni@citrix.com
Subject: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1328888874 0
# Node ID e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
# Parent  6efeff914609a3870e2d07a8d73a26c4615ac60b
qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled

A recent changeset introduced a bug whereby an initialization function
that reads /proc/bus/pci is called from graphics set-up functions even
if pass-through graphics are not enabled.  If qemu is run without
permission to this file, this causes qemu to fail during
initialization.

This patch re-works the functions so that the initialization happens
only if we actually need to do the pci host read or write.  It also
makes failures call abort().

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6efeff914609 -r e4a4e4f4156d hw/pass-through.h
--- a/hw/pass-through.h	Fri Feb 10 11:02:25 2012 +0000
+++ b/hw/pass-through.h	Fri Feb 10 15:47:54 2012 +0000
@@ -29,6 +29,8 @@
 /* Log acesss */
 #define PT_LOGGING_ENABLED
 
+/* Print errors even if logging is disabled */
+#define PT_ERR(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
 #ifdef PT_LOGGING_ENABLED
 #define PT_LOG(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
 #define PT_LOG_DEV(_dev, _f, _a...)   fprintf(logfile, "%s: [%02x:%02x:%01x] " _f, __func__,    \
diff -r 6efeff914609 -r e4a4e4f4156d hw/pt-graphics.c
--- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
+++ b/hw/pt-graphics.c	Fri Feb 10 15:47:54 2012 +0000
@@ -23,11 +23,17 @@ void intel_pch_init(PCIBus *bus)
 {
     uint16_t vid, did;
     uint8_t  rid;
-    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
+    struct pci_dev *pci_dev_1f;
 
-    if ( !gfx_passthru || !pci_dev_1f )
+    if ( !gfx_passthru )
         return;
 
+    if ( !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
+    {
+        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
     vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
@@ -39,36 +45,45 @@ void intel_pch_init(PCIBus *bus)
 
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
-    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    struct pci_dev *pci_dev_host_bridge;
     assert(pci_dev->devfn == 0x00);
-    if ( !igd_passthru ) {
-        pci_default_write_config(pci_dev, config_addr, val, len);
-        return;
-    }
+    if ( !igd_passthru )
+        goto write_default;
 
     switch (config_addr)
     {
         case 0x58:        // PAVPC Offset
-            pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            pci_default_write_config(pci_dev, config_addr, val, len);
+            goto write_default;
     }
+
+    /* Host write */
+    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
+    {
+        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+               config_addr, len, val);
+#endif
+    return;
+
+write_default:
+    pci_default_write_config(pci_dev, config_addr, val, len);
 }
 
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
-    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    struct pci_dev *pci_dev_host_bridge;
     uint32_t val;
 
     assert(pci_dev->devfn == 0x00);
-    if ( !igd_passthru ) {
-        return pci_default_read_config(pci_dev, config_addr, len);
-    }
+    if ( !igd_passthru )
+        goto read_default;
 
     switch (config_addr)
     {
@@ -81,16 +96,28 @@ uint32_t igd_pci_read(PCIDevice *pci_dev
         case 0x58:        /* SNB: PAVPC Offset */
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
-            val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            goto read_default;
     }
+
+    /* Host read */
+    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
+    {
+        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+               config_addr, len, val);
+#endif
     return val;
+   
+read_default:
+   
+   return pci_default_read_config(pci_dev, config_addr, len);
 }
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:56:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvspn-0000MT-AR; Fri, 10 Feb 2012 15:56:27 +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 1Rvspk-0000ML-LO
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:56:25 +0000
Received: from [85.158.139.83:52933] by server-6.bemta-5.messagelabs.com id
	18/CE-04784-72E353F4; Fri, 10 Feb 2012 15:56:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328889381!14572612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28686 invoked from network); 10 Feb 2012 15:56:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 15:56:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="21832908"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 10:56:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 10:56:20 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1AFuJWh008087; Fri, 10 Feb 2012 07:56:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
Message-ID: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 10 Feb 2012 15:56:18 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: stefano.stabellni@citrix.com
Subject: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1328888874 0
# Node ID e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
# Parent  6efeff914609a3870e2d07a8d73a26c4615ac60b
qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled

A recent changeset introduced a bug whereby an initialization function
that reads /proc/bus/pci is called from graphics set-up functions even
if pass-through graphics are not enabled.  If qemu is run without
permission to this file, this causes qemu to fail during
initialization.

This patch re-works the functions so that the initialization happens
only if we actually need to do the pci host read or write.  It also
makes failures call abort().

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6efeff914609 -r e4a4e4f4156d hw/pass-through.h
--- a/hw/pass-through.h	Fri Feb 10 11:02:25 2012 +0000
+++ b/hw/pass-through.h	Fri Feb 10 15:47:54 2012 +0000
@@ -29,6 +29,8 @@
 /* Log acesss */
 #define PT_LOGGING_ENABLED
 
+/* Print errors even if logging is disabled */
+#define PT_ERR(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
 #ifdef PT_LOGGING_ENABLED
 #define PT_LOG(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
 #define PT_LOG_DEV(_dev, _f, _a...)   fprintf(logfile, "%s: [%02x:%02x:%01x] " _f, __func__,    \
diff -r 6efeff914609 -r e4a4e4f4156d hw/pt-graphics.c
--- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
+++ b/hw/pt-graphics.c	Fri Feb 10 15:47:54 2012 +0000
@@ -23,11 +23,17 @@ void intel_pch_init(PCIBus *bus)
 {
     uint16_t vid, did;
     uint8_t  rid;
-    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
+    struct pci_dev *pci_dev_1f;
 
-    if ( !gfx_passthru || !pci_dev_1f )
+    if ( !gfx_passthru )
         return;
 
+    if ( !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
+    {
+        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
     vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
@@ -39,36 +45,45 @@ void intel_pch_init(PCIBus *bus)
 
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
-    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    struct pci_dev *pci_dev_host_bridge;
     assert(pci_dev->devfn == 0x00);
-    if ( !igd_passthru ) {
-        pci_default_write_config(pci_dev, config_addr, val, len);
-        return;
-    }
+    if ( !igd_passthru )
+        goto write_default;
 
     switch (config_addr)
     {
         case 0x58:        // PAVPC Offset
-            pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            pci_default_write_config(pci_dev, config_addr, val, len);
+            goto write_default;
     }
+
+    /* Host write */
+    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
+    {
+        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+               config_addr, len, val);
+#endif
+    return;
+
+write_default:
+    pci_default_write_config(pci_dev, config_addr, val, len);
 }
 
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
-    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    struct pci_dev *pci_dev_host_bridge;
     uint32_t val;
 
     assert(pci_dev->devfn == 0x00);
-    if ( !igd_passthru ) {
-        return pci_default_read_config(pci_dev, config_addr, len);
-    }
+    if ( !igd_passthru )
+        goto read_default;
 
     switch (config_addr)
     {
@@ -81,16 +96,28 @@ uint32_t igd_pci_read(PCIDevice *pci_dev
         case 0x58:        /* SNB: PAVPC Offset */
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
-            val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            goto read_default;
     }
+
+    /* Host read */
+    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
+    {
+        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+               config_addr, len, val);
+#endif
     return val;
+   
+read_default:
+   
+   return pci_default_read_config(pci_dev, config_addr, len);
 }
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:59:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvssi-0000UX-U0; Fri, 10 Feb 2012 15:59:28 +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 1Rvssh-0000UQ-Ps
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:59:28 +0000
Received: from [85.158.139.83:11249] by server-11.bemta-5.messagelabs.com id
	91/DB-13907-FDE353F4; Fri, 10 Feb 2012 15:59:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328889565!7142469!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4706 invoked from network); 10 Feb 2012 15:59:26 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 15:59:26 -0000
Received: by yhkk6 with SMTP id k6so39529475yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 07:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=iUJrdtY/1IZDfP91ClOYAV2yHWLldz3MRD1iAC3y3CM=;
	b=T6kAm22bQz3Oo5XmDtgJQERmGlJB5uB/KiJg3OzLA2coWsGaK3NXHh6r8FULx5skQu
	FPU/SsHkCREmxTFP5cTdirh5uGqnYQGuiXNCfUNfgxbhodyZLCUUkiuEEpwo8EbEugH1
	uCG41HqpRbE/ZSCTEgCwCl84SQMx8egCHdByk=
MIME-Version: 1.0
Received: by 10.50.34.164 with SMTP id a4mr12367628igj.14.1328889564388; Fri,
	10 Feb 2012 07:59:24 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Fri, 10 Feb 2012 07:59:24 -0800 (PST)
In-Reply-To: <ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
Date: Fri, 10 Feb 2012 15:59:24 +0000
X-Google-Sender-Auth: 0irCIrgErgtqSVbWwXd4GPT_v_Y
Message-ID: <CAFLBxZZgGt_2CCDnSZVifWeuC1sOaL7dR+KbJO7S9n7Z2UAnwQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: andres@lagarcavilla.org
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 2:45 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>> On Thu, Feb 9, 2012 at 5:45 AM, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>>> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>>> =A0 =A0 =A0 =A0 unmap_domain_page(b);
>>> =A0 =A0 }
>>>
>>> + =A0 =A0/* First, take all pages off the domain list */
>>> =A0 =A0 lock_page_alloc(p2m);
>>> -
>>> - =A0 =A0/* First, take all pages off the domain list */
>>> =A0 =A0 for(i=3D0; i < 1 << order ; i++)
>>> =A0 =A0 {
>>> =A0 =A0 =A0 =A0 p =3D page + i;
>>> =A0 =A0 =A0 =A0 page_list_del(p, &d->page_list);
>>> =A0 =A0 }
>>>
>>> + =A0 =A0/* Ensure that the PoD cache has never been emptied.
>>> + =A0 =A0 * This may cause "zombie domains" since the page will never be
>>> freed. */
>>> + =A0 =A0BUG_ON( d->arch.relmem !=3D RELMEM_not_started );
>>> +
>>> + =A0 =A0unlock_page_alloc(p2m);
>>> +
>>
>> I thought we were going to get rid of this BUG_ON? :-)
>>
>> Other than that, assuming that you've tested it and it works:
>
> Well, I've tested it for months. Does it work? Can that ever be fully
> answered? ;)

As long as "tested it for months" includes booting in PoD mode (memory
< maxmem) on a regular basis, I'm happy. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 15:59:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 15: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.xensource.com>)
	id 1Rvssi-0000UX-U0; Fri, 10 Feb 2012 15:59:28 +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 1Rvssh-0000UQ-Ps
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 15:59:28 +0000
Received: from [85.158.139.83:11249] by server-11.bemta-5.messagelabs.com id
	91/DB-13907-FDE353F4; Fri, 10 Feb 2012 15:59:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328889565!7142469!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4706 invoked from network); 10 Feb 2012 15:59:26 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 15:59:26 -0000
Received: by yhkk6 with SMTP id k6so39529475yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 07:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=iUJrdtY/1IZDfP91ClOYAV2yHWLldz3MRD1iAC3y3CM=;
	b=T6kAm22bQz3Oo5XmDtgJQERmGlJB5uB/KiJg3OzLA2coWsGaK3NXHh6r8FULx5skQu
	FPU/SsHkCREmxTFP5cTdirh5uGqnYQGuiXNCfUNfgxbhodyZLCUUkiuEEpwo8EbEugH1
	uCG41HqpRbE/ZSCTEgCwCl84SQMx8egCHdByk=
MIME-Version: 1.0
Received: by 10.50.34.164 with SMTP id a4mr12367628igj.14.1328889564388; Fri,
	10 Feb 2012 07:59:24 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Fri, 10 Feb 2012 07:59:24 -0800 (PST)
In-Reply-To: <ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
	<5416a3b371f2387dfcf2.1328766348@xdev.gridcentric.ca>
	<CAFLBxZZZrbNvxsuVhiPdaOpEbYtmYuCrzDdg8Z=OpDw3HZvCJA@mail.gmail.com>
	<ff07926d9c888f8e55bfff494d8ef2ac.squirrel@webmail.lagarcavilla.org>
Date: Fri, 10 Feb 2012 15:59:24 +0000
X-Google-Sender-Auth: 0irCIrgErgtqSVbWwXd4GPT_v_Y
Message-ID: <CAFLBxZZgGt_2CCDnSZVifWeuC1sOaL7dR+KbJO7S9n7Z2UAnwQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: andres@lagarcavilla.org
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 7] Rework locking in the PoD layer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 9, 2012 at 2:45 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>> On Thu, Feb 9, 2012 at 5:45 AM, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>>> @@ -114,15 +114,20 @@ p2m_pod_cache_add(struct p2m_domain *p2m
>>> =A0 =A0 =A0 =A0 unmap_domain_page(b);
>>> =A0 =A0 }
>>>
>>> + =A0 =A0/* First, take all pages off the domain list */
>>> =A0 =A0 lock_page_alloc(p2m);
>>> -
>>> - =A0 =A0/* First, take all pages off the domain list */
>>> =A0 =A0 for(i=3D0; i < 1 << order ; i++)
>>> =A0 =A0 {
>>> =A0 =A0 =A0 =A0 p =3D page + i;
>>> =A0 =A0 =A0 =A0 page_list_del(p, &d->page_list);
>>> =A0 =A0 }
>>>
>>> + =A0 =A0/* Ensure that the PoD cache has never been emptied.
>>> + =A0 =A0 * This may cause "zombie domains" since the page will never be
>>> freed. */
>>> + =A0 =A0BUG_ON( d->arch.relmem !=3D RELMEM_not_started );
>>> +
>>> + =A0 =A0unlock_page_alloc(p2m);
>>> +
>>
>> I thought we were going to get rid of this BUG_ON? :-)
>>
>> Other than that, assuming that you've tested it and it works:
>
> Well, I've tested it for months. Does it work? Can that ever be fully
> answered? ;)

As long as "tested it for months" includes booting in PoD mode (memory
< maxmem) on a regular basis, I'm happy. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:00:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1RvstJ-0000tO-D8; Fri, 10 Feb 2012 16:00:05 +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 1RvstI-0000Xk-4N
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:00:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328889569!59350792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18693 invoked from network); 10 Feb 2012 15:59:29 -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 Feb 2012 15:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:59:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 15:59:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvstD-0005Mh-BV;
	Fri, 10 Feb 2012 15:59:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvstD-0006lN-Ae;
	Fri, 10 Feb 2012 15:59:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11929-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 15:59:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11929: regressions - trouble:
	blocked/fail/pass/preparing/queued/running
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11929 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11929/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 build-amd64-pvops             4 kernel-build             running [st=running!]
 test-i386-i386-pv               <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 test-amd64-amd64-win          7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win           7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 11911 REGR. vs. 11904
 test-i386-i386-win            7 windows-install  fail in 11911 REGR. vs. 11904

Tests which are failing intermittently (not blocking):
 build-amd64-oldkern           4 xen-build                   fail pass in 11911
 build-i386                    4 xen-build                   fail pass in 11911
 build-i386-oldkern            4 xen-build                   fail pass in 11911
 build-amd64                   4 xen-build                   fail pass in 11911
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11911 pass in 11907

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install   fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11911 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11911 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11911 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11911 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11911 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11911 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11911 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11911 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11911 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11911 never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            running 
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          queued  
 test-amd64-i386-xl                                           preparing
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 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                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        queued  
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 queued  
 test-amd64-amd64-pv                                          queued  
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     queued  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         queued  
 test-amd64-i386-win                                          blocked 
 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                                blocked 
 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.

(No revision log; it would be 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:00:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 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.xensource.com>)
	id 1RvstJ-0000tO-D8; Fri, 10 Feb 2012 16:00:05 +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 1RvstI-0000Xk-4N
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:00:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328889569!59350792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18693 invoked from network); 10 Feb 2012 15:59:29 -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 Feb 2012 15:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 15:59:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 15:59:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RvstD-0005Mh-BV;
	Fri, 10 Feb 2012 15:59:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RvstD-0006lN-Ae;
	Fri, 10 Feb 2012 15:59:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11929-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 15:59:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11929: regressions - trouble:
	blocked/fail/pass/preparing/queued/running
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11929 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11929/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 build-amd64-pvops             4 kernel-build             running [st=running!]
 test-i386-i386-pv               <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 test-amd64-amd64-win          7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-win           7 windows-install  fail in 11911 REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 11911 REGR. vs. 11904
 test-i386-i386-win            7 windows-install  fail in 11911 REGR. vs. 11904

Tests which are failing intermittently (not blocking):
 build-amd64-oldkern           4 xen-build                   fail pass in 11911
 build-i386                    4 xen-build                   fail pass in 11911
 build-i386-oldkern            4 xen-build                   fail pass in 11911
 build-amd64                   4 xen-build                   fail pass in 11911
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11911 pass in 11907

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install   fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11911 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11911 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11911 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11911 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11911 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11911 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11911 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11911 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11911 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11911 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11911 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11911 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11911 never pass

version targeted for testing:
 xen                  730f6ed72d70
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            running 
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          queued  
 test-amd64-i386-xl                                           preparing
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 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                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        queued  
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 queued  
 test-amd64-amd64-pv                                          queued  
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     queued  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         queued  
 test-amd64-i386-win                                          blocked 
 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                                blocked 
 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.

(No revision log; it would be 501 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:04:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsxV-0001Gf-Cp; Fri, 10 Feb 2012 16:04:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RvsxU-0001GR-NK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:04:25 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328889856!11376249!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29687 invoked from network); 10 Feb 2012 16:04:18 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:04:18 -0000
Received: by pbbro2 with SMTP id ro2so13857704pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 08:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=LnVLJz1WWrgU8T+poDMof+waA+0m4/1zjsD+3XDXUww=;
	b=Rw+uYAXrAvWFTRL+TThh5i9no8qLDcHF8uOYT5PBdF/lSiscJtfHy6vowwjlsxo0Uo
	sn3qT2L3PBE3SGwKiogyV2rtkSKp8sDBdF862FCisf4MRZgvn9EBuDKpr1ZE56Oeyr5l
	EzR2x/wNk2TUQjrePEvZecx8u1leMnWKVHh08=
MIME-Version: 1.0
Received: by 10.68.220.232 with SMTP id pz8mr17701880pbc.28.1328889856414;
	Fri, 10 Feb 2012 08:04:16 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Fri, 10 Feb 2012 08:04:16 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
	<alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
Date: Sat, 11 Feb 2012 00:04:16 +0800
Message-ID: <CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Stefano,


On Fri, Feb 10, 2012 at 6:45 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 9 Feb 2012, Teck Choon Giam wrote:
>> Hi,
>>
>> I need to check whether is this intended? =A0When using xl create hvm
>> domains, it does execute vif-bridge script. =A0However, when doing xl
>> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
>> script. =A0I just did the following to test:
>>
>> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
>> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
>> #!/bin/bash
>> echo "$@" >> vif-bridge.log
>> /etc/xen/scripts/vif-bridge.orig "$@"
>> EOF
>>
>> When using xm and xl to create hvmdomain, I can see vif-bridge.log
>> appended with:
>>
>> online type_if=3Dvif
>> online type_if=3Dvif
>> add type_if=3Dtap
>> add type_if=3Dtap
>>
>> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
>> gets to execute vif-bridge once for each vif which looks right.
>>
>> Now the problem is xl trigger hvmdomain power and xl destroy power.
>> Both never call vif-bridge script as there isn't any such line like:
>>
>> offline type_if=3Dvif
>> offline type_if=3Dvif
>>
>> Whereby when I tried with xm trigger hvmdomain power, it does call
>> vif-bridge script as the above two lines get logged.
>>
>> This will leave the iptables FORWARD rule intact when using xl which I
>> reported before :(
>>
>> See http://www.gossamer-threads.com/lists/xen/devel/204990
>
> Actually I have just run the same test but I didn't see any issues:
> vif-bridge gets called correctly when the domain dies.
>
> It is difficult to tell what is going wrong in your case because
> vif-bridge is not called directly by XL (or Xend), it is called by
> vif-setup, that is called by udev when the vif network interface is
> destroyed.
> I suggest you check that your udev scripts are correct
> (/etc/udev/rules.d/xen-backend.rules).

Here is the content of the rules:

# cat /etc/udev/rules.d/xen-backend.rules
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"tap*",
RUN+=3D"/etc/xen/scripts/blktap $env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vbd*", RUN+=3D"/etc/xen/scripts/=
block
$env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vtpm*", RUN+=3D"/etc/xen/scripts=
/vtpm
$env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif2-*",
RUN+=3D"/etc/xen/scripts/vif2 $env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vscsi*",
RUN+=3D"/etc/xen/scripts/vscsi $env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", ACTION=3D=3D"remove",
RUN+=3D"/etc/xen/scripts/xen-hotplug-cleanup"
KERNEL=3D=3D"evtchn", NAME=3D"xen/%k"
SUBSYSTEM=3D=3D"xen", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/%k", MODE=3D"=
0600"
SUBSYSTEM=3D=3D"blktap2", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/blktap-2/=
%k",
MODE=3D"0600"
KERNEL=3D=3D"blktap-control", NAME=3D"xen/blktap-2/control", MODE=3D"0600"
KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600"
KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600"
KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0600"
SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add",
RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"

I guess the responsible lines are:

SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"

So this is my testing:

# cp -pvf /etc/xen/scripts/vif-setup /etc/xen/scripts/vif-setup.orig
# cat > /etc/xen/scripts/vif-setup <<'EOF'
#!/bin/bash
echo "$@" >> $0.log
/etc/xen/scripts/vif-setup.orig "$@"
EOF

Now my testing purely on xm/xl trigger hvmdomain power.

Online/Offline get called using xm but xl wise is Online get called
but not Offline with hvm domains like windows XP/server 2008r2... any
idea what else can make this behaviour difference between xl/xm?

The /etc/xen/scripts/vif-setup.log as below.

The below is using xl create hvmdomain and get logged:
online type_if=3Dvif
online type_if=3Dvif
add type_if=3Dtap
add type_if=3Dtap
When using xl trigger hvmdomain power... no log entry at all.

Now test with xm create hvmdonain and get logged:
online type_if=3Dvif
online type_if=3Dvif
add type_if=3Dtap
add type_if=3Dtap
Now test with xm trigger hvmdomain power and get logged:
offline type_if=3Dvif
offline type_if=3Dvif

Thanks for your kind prompt response to my question.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:04:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvsxV-0001Gf-Cp; Fri, 10 Feb 2012 16:04:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RvsxU-0001GR-NK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:04:25 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328889856!11376249!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29687 invoked from network); 10 Feb 2012 16:04:18 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:04:18 -0000
Received: by pbbro2 with SMTP id ro2so13857704pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 08:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=LnVLJz1WWrgU8T+poDMof+waA+0m4/1zjsD+3XDXUww=;
	b=Rw+uYAXrAvWFTRL+TThh5i9no8qLDcHF8uOYT5PBdF/lSiscJtfHy6vowwjlsxo0Uo
	sn3qT2L3PBE3SGwKiogyV2rtkSKp8sDBdF862FCisf4MRZgvn9EBuDKpr1ZE56Oeyr5l
	EzR2x/wNk2TUQjrePEvZecx8u1leMnWKVHh08=
MIME-Version: 1.0
Received: by 10.68.220.232 with SMTP id pz8mr17701880pbc.28.1328889856414;
	Fri, 10 Feb 2012 08:04:16 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Fri, 10 Feb 2012 08:04:16 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
	<alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
Date: Sat, 11 Feb 2012 00:04:16 +0800
Message-ID: <CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Stefano,


On Fri, Feb 10, 2012 at 6:45 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 9 Feb 2012, Teck Choon Giam wrote:
>> Hi,
>>
>> I need to check whether is this intended? =A0When using xl create hvm
>> domains, it does execute vif-bridge script. =A0However, when doing xl
>> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
>> script. =A0I just did the following to test:
>>
>> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
>> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
>> #!/bin/bash
>> echo "$@" >> vif-bridge.log
>> /etc/xen/scripts/vif-bridge.orig "$@"
>> EOF
>>
>> When using xm and xl to create hvmdomain, I can see vif-bridge.log
>> appended with:
>>
>> online type_if=3Dvif
>> online type_if=3Dvif
>> add type_if=3Dtap
>> add type_if=3Dtap
>>
>> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
>> gets to execute vif-bridge once for each vif which looks right.
>>
>> Now the problem is xl trigger hvmdomain power and xl destroy power.
>> Both never call vif-bridge script as there isn't any such line like:
>>
>> offline type_if=3Dvif
>> offline type_if=3Dvif
>>
>> Whereby when I tried with xm trigger hvmdomain power, it does call
>> vif-bridge script as the above two lines get logged.
>>
>> This will leave the iptables FORWARD rule intact when using xl which I
>> reported before :(
>>
>> See http://www.gossamer-threads.com/lists/xen/devel/204990
>
> Actually I have just run the same test but I didn't see any issues:
> vif-bridge gets called correctly when the domain dies.
>
> It is difficult to tell what is going wrong in your case because
> vif-bridge is not called directly by XL (or Xend), it is called by
> vif-setup, that is called by udev when the vif network interface is
> destroyed.
> I suggest you check that your udev scripts are correct
> (/etc/udev/rules.d/xen-backend.rules).

Here is the content of the rules:

# cat /etc/udev/rules.d/xen-backend.rules
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"tap*",
RUN+=3D"/etc/xen/scripts/blktap $env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vbd*", RUN+=3D"/etc/xen/scripts/=
block
$env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vtpm*", RUN+=3D"/etc/xen/scripts=
/vtpm
$env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif2-*",
RUN+=3D"/etc/xen/scripts/vif2 $env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vscsi*",
RUN+=3D"/etc/xen/scripts/vscsi $env{ACTION}"
SUBSYSTEM=3D=3D"xen-backend", ACTION=3D=3D"remove",
RUN+=3D"/etc/xen/scripts/xen-hotplug-cleanup"
KERNEL=3D=3D"evtchn", NAME=3D"xen/%k"
SUBSYSTEM=3D=3D"xen", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/%k", MODE=3D"=
0600"
SUBSYSTEM=3D=3D"blktap2", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/blktap-2/=
%k",
MODE=3D"0600"
KERNEL=3D=3D"blktap-control", NAME=3D"xen/blktap-2/control", MODE=3D"0600"
KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600"
KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600"
KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0600"
SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add",
RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"

I guess the responsible lines are:

SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"

So this is my testing:

# cp -pvf /etc/xen/scripts/vif-setup /etc/xen/scripts/vif-setup.orig
# cat > /etc/xen/scripts/vif-setup <<'EOF'
#!/bin/bash
echo "$@" >> $0.log
/etc/xen/scripts/vif-setup.orig "$@"
EOF

Now my testing purely on xm/xl trigger hvmdomain power.

Online/Offline get called using xm but xl wise is Online get called
but not Offline with hvm domains like windows XP/server 2008r2... any
idea what else can make this behaviour difference between xl/xm?

The /etc/xen/scripts/vif-setup.log as below.

The below is using xl create hvmdomain and get logged:
online type_if=3Dvif
online type_if=3Dvif
add type_if=3Dtap
add type_if=3Dtap
When using xl trigger hvmdomain power... no log entry at all.

Now test with xm create hvmdonain and get logged:
online type_if=3Dvif
online type_if=3Dvif
add type_if=3Dtap
add type_if=3Dtap
Now test with xm trigger hvmdomain power and get logged:
offline type_if=3Dvif
offline type_if=3Dvif

Thanks for your kind prompt response to my question.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:05:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvsyj-0001Md-S8; Fri, 10 Feb 2012 16:05:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rvsyi-0001MH-1a
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:05:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328889932!14368137!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25741 invoked from network); 10 Feb 2012 16:05:33 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:05:33 -0000
Received: by obcuy19 with SMTP id uy19so13118502obc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 08:05:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=qeEo89/nLI8LPScfflaF6UA69s8+WKV7TqxGxWV0Pos=;
	b=kXNNlMdft6XtCSM+6wCoaNNshy5LSZhgrt55ldv8lmXRchcACKRoosdmVO5aV+z1PL
	+gTJv6jYOdMqEaK0PtWyk6ERdnyNi6piEbWj8KhuVaMVk1SCMfb8/n7E0vHZ6tU9TP2f
	2705Gb0bItxPnxsAct9PuktlB5o6Ie3ZLw2xY=
MIME-Version: 1.0
Received: by 10.50.11.200 with SMTP id s8mr12453071igb.10.1328889931924; Fri,
	10 Feb 2012 08:05:31 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Fri, 10 Feb 2012 08:05:31 -0800 (PST)
In-Reply-To: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
References: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
Date: Fri, 10 Feb 2012 16:05:31 +0000
X-Google-Sender-Auth: kwqrSwHhRlbpGRbjRC6jIjLFD-o
Message-ID: <CAFLBxZbR3b76YtQJ9wnyZ9JsQA06MtG5Ug3Xz-nz8mFRS_7xtA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, didn't get the CC right...
 -George

On Fri, Feb 10, 2012 at 3:56 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1328888874 0
> # Node ID e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
> # Parent =A06efeff914609a3870e2d07a8d73a26c4615ac60b
> qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
>
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions even
> if pass-through graphics are not enabled. =A0If qemu is run without
> permission to this file, this causes qemu to fail during
> initialization.
>
> This patch re-works the functions so that the initialization happens
> only if we actually need to do the pci host read or write. =A0It also
> makes failures call abort().
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff -r 6efeff914609 -r e4a4e4f4156d hw/pass-through.h
> --- a/hw/pass-through.h Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pass-through.h Fri Feb 10 15:47:54 2012 +0000
> @@ -29,6 +29,8 @@
> =A0/* Log acesss */
> =A0#define PT_LOGGING_ENABLED
>
> +/* Print errors even if logging is disabled */
> +#define PT_ERR(_f, _a...) =A0 fprintf(logfile, "%s: " _f, __func__, ##_a)
> =A0#ifdef PT_LOGGING_ENABLED
> =A0#define PT_LOG(_f, _a...) =A0 fprintf(logfile, "%s: " _f, __func__, ##=
_a)
> =A0#define PT_LOG_DEV(_dev, _f, _a...) =A0 fprintf(logfile, "%s: [%02x:%0=
2x:%01x] " _f, __func__, =A0 =A0\
> diff -r 6efeff914609 -r e4a4e4f4156d hw/pt-graphics.c
> --- a/hw/pt-graphics.c =A0Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pt-graphics.c =A0Fri Feb 10 15:47:54 2012 +0000
> @@ -23,11 +23,17 @@ void intel_pch_init(PCIBus *bus)
> =A0{
> =A0 =A0 uint16_t vid, did;
> =A0 =A0 uint8_t =A0rid;
> - =A0 =A0struct pci_dev *pci_dev_1f =3D pt_pci_get_dev(0, 0x1f, 0);
> + =A0 =A0struct pci_dev *pci_dev_1f;
>
> - =A0 =A0if ( !gfx_passthru || !pci_dev_1f )
> + =A0 =A0if ( !gfx_passthru )
> =A0 =A0 =A0 =A0 return;
>
> + =A0 =A0if ( !(pci_dev_1f=3Dpt_pci_get_dev(0, 0x1f, 0)) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> + =A0 =A0 =A0 =A0abort();
> + =A0 =A0}
> +
> =A0 =A0 vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> =A0 =A0 did =3D pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
> =A0 =A0 rid =3D pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
> @@ -39,36 +45,45 @@ void intel_pch_init(PCIBus *bus)
>
> =A0void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t =
val, int len)
> =A0{
> - =A0 =A0struct pci_dev *pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0);
> + =A0 =A0struct pci_dev *pci_dev_host_bridge;
> =A0 =A0 assert(pci_dev->devfn =3D=3D 0x00);
> - =A0 =A0if ( !igd_passthru ) {
> - =A0 =A0 =A0 =A0pci_default_write_config(pci_dev, config_addr, val, len);
> - =A0 =A0 =A0 =A0return;
> - =A0 =A0}
> + =A0 =A0if ( !igd_passthru )
> + =A0 =A0 =A0 =A0goto write_default;
>
> =A0 =A0 switch (config_addr)
> =A0 =A0 {
> =A0 =A0 =A0 =A0 case 0x58: =A0 =A0 =A0 =A0// PAVPC Offset
> - =A0 =A0 =A0 =A0 =A0 =A0pt_pci_host_write(pci_dev_host_bridge, config_ad=
dr, val, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> - =A0 =A0 =A0 =A0 =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x=
\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0config_addr, len, val);
> -#endif
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 default:
> - =A0 =A0 =A0 =A0 =A0 =A0pci_default_write_config(pci_dev, config_addr, v=
al, len);
> + =A0 =A0 =A0 =A0 =A0 =A0goto write_default;
> =A0 =A0 }
> +
> + =A0 =A0/* Host write */
> + =A0 =A0if ( !(pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0)) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> + =A0 =A0 =A0 =A0abort();
> + =A0 =A0}
> +
> + =A0 =A0pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> + =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 config_addr, len, val);
> +#endif
> + =A0 =A0return;
> +
> +write_default:
> + =A0 =A0pci_default_write_config(pci_dev, config_addr, val, len);
> =A0}
>
> =A0uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int le=
n)
> =A0{
> - =A0 =A0struct pci_dev *pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0);
> + =A0 =A0struct pci_dev *pci_dev_host_bridge;
> =A0 =A0 uint32_t val;
>
> =A0 =A0 assert(pci_dev->devfn =3D=3D 0x00);
> - =A0 =A0if ( !igd_passthru ) {
> - =A0 =A0 =A0 =A0return pci_default_read_config(pci_dev, config_addr, len=
);
> - =A0 =A0}
> + =A0 =A0if ( !igd_passthru )
> + =A0 =A0 =A0 =A0goto read_default;
>
> =A0 =A0 switch (config_addr)
> =A0 =A0 {
> @@ -81,16 +96,28 @@ uint32_t igd_pci_read(PCIDevice *pci_dev
> =A0 =A0 =A0 =A0 case 0x58: =A0 =A0 =A0 =A0/* SNB: PAVPC Offset */
> =A0 =A0 =A0 =A0 case 0xa4: =A0 =A0 =A0 =A0/* SNB: graphics base of stolen=
 memory */
> =A0 =A0 =A0 =A0 case 0xa8: =A0 =A0 =A0 =A0/* SNB: base of GTT stolen memo=
ry */
> - =A0 =A0 =A0 =A0 =A0 =A0val =3D pt_pci_host_read(pci_dev_host_bridge, co=
nfig_addr, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> - =A0 =A0 =A0 =A0 =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x=
\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0config_addr, len, val);
> -#endif
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 default:
> - =A0 =A0 =A0 =A0 =A0 =A0val =3D pci_default_read_config(pci_dev, config_=
addr, len);
> + =A0 =A0 =A0 =A0 =A0 =A0goto read_default;
> =A0 =A0 }
> +
> + =A0 =A0/* Host read */
> + =A0 =A0if ( !(pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0)) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> + =A0 =A0 =A0 =A0abort();
> + =A0 =A0}
> +
> + =A0 =A0val =3D pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> + =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 config_addr, len, val);
> +#endif
> =A0 =A0 return val;
> +
> +read_default:
> +
> + =A0 return pci_default_read_config(pci_dev, config_addr, len);
> =A0}
>
> =A0/*
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:05:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvsyj-0001Md-S8; Fri, 10 Feb 2012 16:05:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rvsyi-0001MH-1a
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:05:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328889932!14368137!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25741 invoked from network); 10 Feb 2012 16:05:33 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:05:33 -0000
Received: by obcuy19 with SMTP id uy19so13118502obc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 08:05:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=qeEo89/nLI8LPScfflaF6UA69s8+WKV7TqxGxWV0Pos=;
	b=kXNNlMdft6XtCSM+6wCoaNNshy5LSZhgrt55ldv8lmXRchcACKRoosdmVO5aV+z1PL
	+gTJv6jYOdMqEaK0PtWyk6ERdnyNi6piEbWj8KhuVaMVk1SCMfb8/n7E0vHZ6tU9TP2f
	2705Gb0bItxPnxsAct9PuktlB5o6Ie3ZLw2xY=
MIME-Version: 1.0
Received: by 10.50.11.200 with SMTP id s8mr12453071igb.10.1328889931924; Fri,
	10 Feb 2012 08:05:31 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Fri, 10 Feb 2012 08:05:31 -0800 (PST)
In-Reply-To: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
References: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
Date: Fri, 10 Feb 2012 16:05:31 +0000
X-Google-Sender-Auth: kwqrSwHhRlbpGRbjRC6jIjLFD-o
Message-ID: <CAFLBxZbR3b76YtQJ9wnyZ9JsQA06MtG5Ug3Xz-nz8mFRS_7xtA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, didn't get the CC right...
 -George

On Fri, Feb 10, 2012 at 3:56 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1328888874 0
> # Node ID e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
> # Parent =A06efeff914609a3870e2d07a8d73a26c4615ac60b
> qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
>
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions even
> if pass-through graphics are not enabled. =A0If qemu is run without
> permission to this file, this causes qemu to fail during
> initialization.
>
> This patch re-works the functions so that the initialization happens
> only if we actually need to do the pci host read or write. =A0It also
> makes failures call abort().
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff -r 6efeff914609 -r e4a4e4f4156d hw/pass-through.h
> --- a/hw/pass-through.h Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pass-through.h Fri Feb 10 15:47:54 2012 +0000
> @@ -29,6 +29,8 @@
> =A0/* Log acesss */
> =A0#define PT_LOGGING_ENABLED
>
> +/* Print errors even if logging is disabled */
> +#define PT_ERR(_f, _a...) =A0 fprintf(logfile, "%s: " _f, __func__, ##_a)
> =A0#ifdef PT_LOGGING_ENABLED
> =A0#define PT_LOG(_f, _a...) =A0 fprintf(logfile, "%s: " _f, __func__, ##=
_a)
> =A0#define PT_LOG_DEV(_dev, _f, _a...) =A0 fprintf(logfile, "%s: [%02x:%0=
2x:%01x] " _f, __func__, =A0 =A0\
> diff -r 6efeff914609 -r e4a4e4f4156d hw/pt-graphics.c
> --- a/hw/pt-graphics.c =A0Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pt-graphics.c =A0Fri Feb 10 15:47:54 2012 +0000
> @@ -23,11 +23,17 @@ void intel_pch_init(PCIBus *bus)
> =A0{
> =A0 =A0 uint16_t vid, did;
> =A0 =A0 uint8_t =A0rid;
> - =A0 =A0struct pci_dev *pci_dev_1f =3D pt_pci_get_dev(0, 0x1f, 0);
> + =A0 =A0struct pci_dev *pci_dev_1f;
>
> - =A0 =A0if ( !gfx_passthru || !pci_dev_1f )
> + =A0 =A0if ( !gfx_passthru )
> =A0 =A0 =A0 =A0 return;
>
> + =A0 =A0if ( !(pci_dev_1f=3Dpt_pci_get_dev(0, 0x1f, 0)) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> + =A0 =A0 =A0 =A0abort();
> + =A0 =A0}
> +
> =A0 =A0 vid =3D pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
> =A0 =A0 did =3D pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
> =A0 =A0 rid =3D pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
> @@ -39,36 +45,45 @@ void intel_pch_init(PCIBus *bus)
>
> =A0void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t =
val, int len)
> =A0{
> - =A0 =A0struct pci_dev *pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0);
> + =A0 =A0struct pci_dev *pci_dev_host_bridge;
> =A0 =A0 assert(pci_dev->devfn =3D=3D 0x00);
> - =A0 =A0if ( !igd_passthru ) {
> - =A0 =A0 =A0 =A0pci_default_write_config(pci_dev, config_addr, val, len);
> - =A0 =A0 =A0 =A0return;
> - =A0 =A0}
> + =A0 =A0if ( !igd_passthru )
> + =A0 =A0 =A0 =A0goto write_default;
>
> =A0 =A0 switch (config_addr)
> =A0 =A0 {
> =A0 =A0 =A0 =A0 case 0x58: =A0 =A0 =A0 =A0// PAVPC Offset
> - =A0 =A0 =A0 =A0 =A0 =A0pt_pci_host_write(pci_dev_host_bridge, config_ad=
dr, val, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> - =A0 =A0 =A0 =A0 =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x=
\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0config_addr, len, val);
> -#endif
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 default:
> - =A0 =A0 =A0 =A0 =A0 =A0pci_default_write_config(pci_dev, config_addr, v=
al, len);
> + =A0 =A0 =A0 =A0 =A0 =A0goto write_default;
> =A0 =A0 }
> +
> + =A0 =A0/* Host write */
> + =A0 =A0if ( !(pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0)) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> + =A0 =A0 =A0 =A0abort();
> + =A0 =A0}
> +
> + =A0 =A0pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> + =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 config_addr, len, val);
> +#endif
> + =A0 =A0return;
> +
> +write_default:
> + =A0 =A0pci_default_write_config(pci_dev, config_addr, val, len);
> =A0}
>
> =A0uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int le=
n)
> =A0{
> - =A0 =A0struct pci_dev *pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0);
> + =A0 =A0struct pci_dev *pci_dev_host_bridge;
> =A0 =A0 uint32_t val;
>
> =A0 =A0 assert(pci_dev->devfn =3D=3D 0x00);
> - =A0 =A0if ( !igd_passthru ) {
> - =A0 =A0 =A0 =A0return pci_default_read_config(pci_dev, config_addr, len=
);
> - =A0 =A0}
> + =A0 =A0if ( !igd_passthru )
> + =A0 =A0 =A0 =A0goto read_default;
>
> =A0 =A0 switch (config_addr)
> =A0 =A0 {
> @@ -81,16 +96,28 @@ uint32_t igd_pci_read(PCIDevice *pci_dev
> =A0 =A0 =A0 =A0 case 0x58: =A0 =A0 =A0 =A0/* SNB: PAVPC Offset */
> =A0 =A0 =A0 =A0 case 0xa4: =A0 =A0 =A0 =A0/* SNB: graphics base of stolen=
 memory */
> =A0 =A0 =A0 =A0 case 0xa8: =A0 =A0 =A0 =A0/* SNB: base of GTT stolen memo=
ry */
> - =A0 =A0 =A0 =A0 =A0 =A0val =3D pt_pci_host_read(pci_dev_host_bridge, co=
nfig_addr, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> - =A0 =A0 =A0 =A0 =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x=
\n",
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0config_addr, len, val);
> -#endif
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 =A0 default:
> - =A0 =A0 =A0 =A0 =A0 =A0val =3D pci_default_read_config(pci_dev, config_=
addr, len);
> + =A0 =A0 =A0 =A0 =A0 =A0goto read_default;
> =A0 =A0 }
> +
> + =A0 =A0/* Host read */
> + =A0 =A0if ( !(pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, 0)) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> + =A0 =A0 =A0 =A0abort();
> + =A0 =A0}
> +
> + =A0 =A0val =3D pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> + =A0 =A0PT_LOG_DEV(pci_dev, "addr=3D%x len=3D%x val=3D%x\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 config_addr, len, val);
> +#endif
> =A0 =A0 return val;
> +
> +read_default:
> +
> + =A0 return pci_default_read_config(pci_dev, config_addr, len);
> =A0}
>
> =A0/*
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:10:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvt3P-0001b2-Jm; Fri, 10 Feb 2012 16:10:31 +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 1Rvt3N-0001as-SB
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:10:29 +0000
Received: from [85.158.139.83:20715] by server-3.bemta-5.messagelabs.com id
	15/41-25605-471453F4; Fri, 10 Feb 2012 16:10:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328890225!7143914!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6333 invoked from network); 10 Feb 2012 16:10:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:10:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvt3H-0008aa-IE; Fri, 10 Feb 2012 16:10:23 +0000
Date: Fri, 10 Feb 2012 16:10:23 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210161023.GE32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 7] Synchronized p2m lookups v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 00:45 -0500 on 09 Feb (1328748345), Andres Lagar-Cavilla wrote:
> Up until now, p2m lookups (get_gfn*) in the x86 architecture were not
> synchronized against concurrent updates. With the addition of sharing and
> paging subsystems that can dynamically modify the p2m, the need for
> synchronized lookups becomes more pressing.
> 
> Without synchronized lookups, we've encountered host crashes triggered by race
> conditions, particularly when exercising the sharing subsystem.
> 
> In this patch series we make p2m lookups fully synchronized. We still use a
> single per-domain p2m lock (profiling work tbd may or may not indicate the need
> for fine-grained locking).
> 
> We only enforce locking of p2m queries for hap-assisted domains. These are the
> domains (in the case of EPT) that can exercise the paging and sharing
> subsystems and thus most in need of synchronized lookups.
> 
> While the code *should* work for domains relying on shadow paging, it has not
> been tested, hence we do not enable this at the moment.
> 
> Finally, the locking discipline in the PoD subsystem has been updated, since
> PoD relied on some assumptions about the way the p2m lock is used.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:10:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvt3P-0001b2-Jm; Fri, 10 Feb 2012 16:10:31 +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 1Rvt3N-0001as-SB
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:10:29 +0000
Received: from [85.158.139.83:20715] by server-3.bemta-5.messagelabs.com id
	15/41-25605-471453F4; Fri, 10 Feb 2012 16:10:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1328890225!7143914!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6333 invoked from network); 10 Feb 2012 16:10:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:10:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvt3H-0008aa-IE; Fri, 10 Feb 2012 16:10:23 +0000
Date: Fri, 10 Feb 2012 16:10:23 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210161023.GE32107@ocelot.phlegethon.org>
References: <patchbomb.1328766345@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328766345@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: george.dunlap@eu.citrix.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 7] Synchronized p2m lookups v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 00:45 -0500 on 09 Feb (1328748345), Andres Lagar-Cavilla wrote:
> Up until now, p2m lookups (get_gfn*) in the x86 architecture were not
> synchronized against concurrent updates. With the addition of sharing and
> paging subsystems that can dynamically modify the p2m, the need for
> synchronized lookups becomes more pressing.
> 
> Without synchronized lookups, we've encountered host crashes triggered by race
> conditions, particularly when exercising the sharing subsystem.
> 
> In this patch series we make p2m lookups fully synchronized. We still use a
> single per-domain p2m lock (profiling work tbd may or may not indicate the need
> for fine-grained locking).
> 
> We only enforce locking of p2m queries for hap-assisted domains. These are the
> domains (in the case of EPT) that can exercise the paging and sharing
> subsystems and thus most in need of synchronized lookups.
> 
> While the code *should* work for domains relying on shadow paging, it has not
> been tested, hence we do not enable this at the moment.
> 
> Finally, the locking discipline in the PoD subsystem has been updated, since
> PoD relied on some assumptions about the way the p2m lock is used.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvt5v-0001jZ-GF; Fri, 10 Feb 2012 16:13:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rvt5u-0001jM-AK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:13:06 +0000
Received: from [85.158.139.83:37054] by server-11.bemta-5.messagelabs.com id
	7C/00-13907-112453F4; Fri, 10 Feb 2012 16:13:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328890385!14560889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19919 invoked from network); 10 Feb 2012 16:13:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 16:13:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 16:13:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rvt5s-0005RE-Mv	for xen-devel@lists.xensource.com;
	Fri, 10 Feb 2012 16:13:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rvt5s-0001iB-L8	for
	xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:13:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20277.16912.643471.644212@mariner.uk.xensource.com>
Date: Fri, 10 Feb 2012 16:13:04 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11929-mainreport@xen.org>
References: <osstest-11929-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11929: regressions - trouble:
 blocked/fail/pass/preparing/queued/running
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11929: regressions - trouble: blocked/fail/pass/preparing/queued/running"):
> flight 11929 xen-unstable running [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11929/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
>  test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
>  test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
>  test-amd64-amd64-xl-pcipt-intel    <none executed>              queued

This is my fault.  I messed something up and had to kill this one.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvt5v-0001jZ-GF; Fri, 10 Feb 2012 16:13:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rvt5u-0001jM-AK
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:13:06 +0000
Received: from [85.158.139.83:37054] by server-11.bemta-5.messagelabs.com id
	7C/00-13907-112453F4; Fri, 10 Feb 2012 16:13:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328890385!14560889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19919 invoked from network); 10 Feb 2012 16:13:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10626769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 16:13:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 16:13:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rvt5s-0005RE-Mv	for xen-devel@lists.xensource.com;
	Fri, 10 Feb 2012 16:13:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rvt5s-0001iB-L8	for
	xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:13:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20277.16912.643471.644212@mariner.uk.xensource.com>
Date: Fri, 10 Feb 2012 16:13:04 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11929-mainreport@xen.org>
References: <osstest-11929-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11929: regressions - trouble:
 blocked/fail/pass/preparing/queued/running
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11929: regressions - trouble: blocked/fail/pass/preparing/queued/running"):
> flight 11929 xen-unstable running [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11929/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
>  test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
>  test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
>  test-amd64-amd64-xl-pcipt-intel    <none executed>              queued

This is my fault.  I messed something up and had to kill this one.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:14:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvt6u-0001oV-0U; Fri, 10 Feb 2012 16:14:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvt6t-0001o3-26
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:14:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328890437!12864496!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27417 invoked from network); 10 Feb 2012 16:14:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:14:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvt6j-0008bn-9z; Fri, 10 Feb 2012 16:13:57 +0000
Date: Fri, 10 Feb 2012 16:13:57 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210161357.GF32107@ocelot.phlegethon.org>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
	interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:08 -0500 on 09 Feb (1328749705), Andres Lagar-Cavilla wrote:
> i(Was switch from domctl to memops)
> Changes from v1 posted Feb 2nd 2012
> 
> - Patches 1 & 2 Acked-by Tim Deegan on the hypervisor side
> - Added patch 3 to clean up the enable domctl interface, based on
>   discussion with Ian Campbell
> 
> Description from original post follows:
> 
> Per page operations in the paging, sharing, and access tracking subsystems are
> all implemented with domctls (e.g. a domctl to evict one page, or to share one
> page).
> 
> Under heavy load, the domctl path reveals a lack of scalability. The domctl
> lock serializes dom0's vcpus in the hypervisor. When performing thousands of
> per-page operations on dozens of domains, these vcpus will spin in the
> hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
> vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
> its other work-starved processes.
> 
> We retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page
> operations to use the memory_op hypercalls (e.g XENMEM_*).
> 
> This is a backwards-incompatible ABI change. It's been floating on the list for
> a couple weeks now, with no nacks thus far.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Applied 1 and 2; thanks.

I'll leave patch 3 for others to comment -- I know there are out-of-tree
users of the mem-access interface, and changing the hypercalls is less
disruptive than changing the libxc interface.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:14:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvt6u-0001oV-0U; Fri, 10 Feb 2012 16:14:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvt6t-0001o3-26
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:14:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328890437!12864496!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27417 invoked from network); 10 Feb 2012 16:14:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:14:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rvt6j-0008bn-9z; Fri, 10 Feb 2012 16:13:57 +0000
Date: Fri, 10 Feb 2012 16:13:57 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210161357.GF32107@ocelot.phlegethon.org>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1328767705@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
	interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 01:08 -0500 on 09 Feb (1328749705), Andres Lagar-Cavilla wrote:
> i(Was switch from domctl to memops)
> Changes from v1 posted Feb 2nd 2012
> 
> - Patches 1 & 2 Acked-by Tim Deegan on the hypervisor side
> - Added patch 3 to clean up the enable domctl interface, based on
>   discussion with Ian Campbell
> 
> Description from original post follows:
> 
> Per page operations in the paging, sharing, and access tracking subsystems are
> all implemented with domctls (e.g. a domctl to evict one page, or to share one
> page).
> 
> Under heavy load, the domctl path reveals a lack of scalability. The domctl
> lock serializes dom0's vcpus in the hypervisor. When performing thousands of
> per-page operations on dozens of domains, these vcpus will spin in the
> hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
> vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
> its other work-starved processes.
> 
> We retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page
> operations to use the memory_op hypercalls (e.g XENMEM_*).
> 
> This is a backwards-incompatible ABI change. It's been floating on the list for
> a couple weeks now, with no nacks thus far.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Applied 1 and 2; thanks.

I'll leave patch 3 for others to comment -- I know there are out-of-tree
users of the mem-access interface, and changing the hypercalls is less
disruptive than changing the libxc interface.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:23:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtFT-0002Mr-7B; Fri, 10 Feb 2012 16:22:59 +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 1RvtFR-0002Mi-32
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:22:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328890937!51947171!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18283 invoked from network); 10 Feb 2012 16:22:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:22:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvtFM-0008eD-VD; Fri, 10 Feb 2012 16:22:52 +0000
Date: Fri, 10 Feb 2012 16:22:52 +0000
From: Tim Deegan <tim@xen.org>
To: hongkaixing@huawei.com
Message-ID: <20120210162252.GG32107@ocelot.phlegethon.org>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
User-Agent: Mutt/1.4.2.1i
Cc: xiaowei.yang@huawei.com, Olaf Hering <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:53 +0800 on 09 Feb (1328806434), hongkaixing@huawei.com wrote:
> # HG changeset patch
> # User h00166998@h00166998.china.huawei.com
> # Date 1328777452 -28800
> # Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> xenpaging:close domU's event channel and free port
> 
> Every domain (X86 64 bit)has 4096 event channels.In source code,
> domU's event channel is allocated in mem_event_enable(),but just
> unbind dom0's event channel in xenpaging_teardown().This bug will
> result in that we can not use xenpaging after reopening it for 4096
> times.We should free domU's event channel in mem_event_disable().so
> that we can reuse the port.

Yep, looks like a bug.

> diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
> +++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
> @@ -241,7 +241,12 @@
>              mem_event_ring_unlock(med);
>              return -EBUSY;
>          }
> -
> +        
> +        if( med->shared_page!=NULL )
> +        {
> +            free_xen_event_channel(d->vcpu[0], (med->shared_page)->port);
> +        }
> +             

But you shouldn't use the value from the shared page, in case it has
been corrupted by a buggy or malicious guest.  Can you please save the
event channel in a new field in struct mem_event_domain, so the guest
can't overwrite it?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:23:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtFT-0002Mr-7B; Fri, 10 Feb 2012 16:22:59 +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 1RvtFR-0002Mi-32
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:22:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328890937!51947171!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18283 invoked from network); 10 Feb 2012 16:22:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:22:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvtFM-0008eD-VD; Fri, 10 Feb 2012 16:22:52 +0000
Date: Fri, 10 Feb 2012 16:22:52 +0000
From: Tim Deegan <tim@xen.org>
To: hongkaixing@huawei.com
Message-ID: <20120210162252.GG32107@ocelot.phlegethon.org>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
User-Agent: Mutt/1.4.2.1i
Cc: xiaowei.yang@huawei.com, Olaf Hering <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:53 +0800 on 09 Feb (1328806434), hongkaixing@huawei.com wrote:
> # HG changeset patch
> # User h00166998@h00166998.china.huawei.com
> # Date 1328777452 -28800
> # Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> xenpaging:close domU's event channel and free port
> 
> Every domain (X86 64 bit)has 4096 event channels.In source code,
> domU's event channel is allocated in mem_event_enable(),but just
> unbind dom0's event channel in xenpaging_teardown().This bug will
> result in that we can not use xenpaging after reopening it for 4096
> times.We should free domU's event channel in mem_event_disable().so
> that we can reuse the port.

Yep, looks like a bug.

> diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
> +++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
> @@ -241,7 +241,12 @@
>              mem_event_ring_unlock(med);
>              return -EBUSY;
>          }
> -
> +        
> +        if( med->shared_page!=NULL )
> +        {
> +            free_xen_event_channel(d->vcpu[0], (med->shared_page)->port);
> +        }
> +             

But you shouldn't use the value from the shared page, in case it has
been corrupted by a buggy or malicious guest.  Can you please save the
event channel in a new field in struct mem_event_domain, so the guest
can't overwrite it?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtOQ-0002pP-3r; Fri, 10 Feb 2012 16:32:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvtOO-0002oh-LU
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:32:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328891525!13806445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22842 invoked from network); 10 Feb 2012 16:32:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:32:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181268531"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11:32:05 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 10 Feb 2012
	11:32:04 -0500
Message-ID: <4F354683.7010009@citrix.com>
Date: Fri, 10 Feb 2012 16:32:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: "hongkaixing@huawei.com" <hongkaixing@huawei.com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
In-Reply-To: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
X-Enigmail-Version: 1.1.2
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free	port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 09/02/12 08:53, hongkaixing@huawei.com wrote:
> # HG changeset patch
> # User h00166998@h00166998.china.huawei.com
> # Date 1328777452 -28800
> # Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> xenpaging:close domU's event channel and free port
>
> Every domain (X86 64 bit)has 4096 event channels.In source code,
> domU's event channel is allocated in mem_event_enable(),but just
> unbind dom0's event channel in xenpaging_teardown().This bug will
> result in that we can not use xenpaging after reopening it for 4096
> times.We should free domU's event channel in mem_event_disable().so
> that we can reuse the port.
>
> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>
> diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
> +++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
> @@ -241,7 +241,12 @@
>              mem_event_ring_unlock(med);
>              return -EBUSY;
>          }
> -
> +        
You have introduced trailing whitespace onto this line as part of the patch

> +        if( med->shared_page!=NULL )
> +        {
> +            free_xen_event_channel(d->vcpu[0], (med->shared_page)->port);
> +        }
> +             
>          unmap_domain_page(med->ring_page);
>          med->ring_page = 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtOQ-0002pP-3r; Fri, 10 Feb 2012 16:32:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RvtOO-0002oh-LU
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:32:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1328891525!13806445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgwNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22842 invoked from network); 10 Feb 2012 16:32:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 16:32:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325480400"; d="scan'208";a="181268531"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 11:32:05 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 10 Feb 2012
	11:32:04 -0500
Message-ID: <4F354683.7010009@citrix.com>
Date: Fri, 10 Feb 2012 16:32:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: "hongkaixing@huawei.com" <hongkaixing@huawei.com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
In-Reply-To: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
X-Enigmail-Version: 1.1.2
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free	port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 09/02/12 08:53, hongkaixing@huawei.com wrote:
> # HG changeset patch
> # User h00166998@h00166998.china.huawei.com
> # Date 1328777452 -28800
> # Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> xenpaging:close domU's event channel and free port
>
> Every domain (X86 64 bit)has 4096 event channels.In source code,
> domU's event channel is allocated in mem_event_enable(),but just
> unbind dom0's event channel in xenpaging_teardown().This bug will
> result in that we can not use xenpaging after reopening it for 4096
> times.We should free domU's event channel in mem_event_disable().so
> that we can reuse the port.
>
> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>
> diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
> +++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
> @@ -241,7 +241,12 @@
>              mem_event_ring_unlock(med);
>              return -EBUSY;
>          }
> -
> +        
You have introduced trailing whitespace onto this line as part of the patch

> +        if( med->shared_page!=NULL )
> +        {
> +            free_xen_event_channel(d->vcpu[0], (med->shared_page)->port);
> +        }
> +             
>          unmap_domain_page(med->ring_page);
>          med->ring_page = 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtWU-0003H4-5K; Fri, 10 Feb 2012 16:40:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvtWR-0003Gw-LF
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:40:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328892025!10977467!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7309 invoked from network); 10 Feb 2012 16:40:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Feb 2012 16:40:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328892025; l=889;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TT3bnQuuM4OyooqOYpvwLW5rWAo=;
	b=DWfnc4tqzWKGQi9+tEAqXAGR8URJZKMw4liLkFQ7Ny8saSEbALVnn16HTqVlR+Tht1N
	coLD9jc9rTGw8zfCiFReYtnnJmHOHfWA9b0tj0AbpNSG1aDoGGBeyRJIzfG5jDv4gLj36
	GpIKKCVb6LjEukxbpmUDnWhwbRG1RALJjIk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by post.strato.de (mrclete mo54) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N04f59o1AF16IW ;
	Fri, 10 Feb 2012 17:40:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BA22D18637; Fri, 10 Feb 2012 17:40:10 +0100 (CET)
Date: Fri, 10 Feb 2012 17:40:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120210164010.GA10009@aepfle.de>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, hongkaixing@huawei.com wrote:

> xenpaging:close domU's event channel and free port
> 
> Every domain (X86 64 bit)has 4096 event channels.In source code,
> domU's event channel is allocated in mem_event_enable(),but just
> unbind dom0's event channel in xenpaging_teardown().This bug will
> result in that we can not use xenpaging after reopening it for 4096
> times.We should free domU's event channel in mem_event_disable().so
> that we can reuse the port.

Does that fix a real bug?

xenpaging_teardown() does both xc_mem_paging_disable() and
xc_evtchn_unbind(). The former fails often because the domain is gone
and so it doesnt even reach the function in mem_event.c.
The latter is called unconditionally.

Also I would expect that once xenpaging exits the kernel driver does a
cleanup of all used ports. I havent checked wether thats true.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtWU-0003H4-5K; Fri, 10 Feb 2012 16:40:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvtWR-0003Gw-LF
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:40:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328892025!10977467!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7309 invoked from network); 10 Feb 2012 16:40:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Feb 2012 16:40:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328892025; l=889;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TT3bnQuuM4OyooqOYpvwLW5rWAo=;
	b=DWfnc4tqzWKGQi9+tEAqXAGR8URJZKMw4liLkFQ7Ny8saSEbALVnn16HTqVlR+Tht1N
	coLD9jc9rTGw8zfCiFReYtnnJmHOHfWA9b0tj0AbpNSG1aDoGGBeyRJIzfG5jDv4gLj36
	GpIKKCVb6LjEukxbpmUDnWhwbRG1RALJjIk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by post.strato.de (mrclete mo54) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N04f59o1AF16IW ;
	Fri, 10 Feb 2012 17:40:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BA22D18637; Fri, 10 Feb 2012 17:40:10 +0100 (CET)
Date: Fri, 10 Feb 2012 17:40:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120210164010.GA10009@aepfle.de>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 09, hongkaixing@huawei.com wrote:

> xenpaging:close domU's event channel and free port
> 
> Every domain (X86 64 bit)has 4096 event channels.In source code,
> domU's event channel is allocated in mem_event_enable(),but just
> unbind dom0's event channel in xenpaging_teardown().This bug will
> result in that we can not use xenpaging after reopening it for 4096
> times.We should free domU's event channel in mem_event_disable().so
> that we can reuse the port.

Does that fix a real bug?

xenpaging_teardown() does both xc_mem_paging_disable() and
xc_evtchn_unbind(). The former fails often because the domain is gone
and so it doesnt even reach the function in mem_event.c.
The latter is called unconditionally.

Also I would expect that once xenpaging exits the kernel driver does a
cleanup of all used ports. I havent checked wether thats true.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:51:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvtgh-0003XT-Du; Fri, 10 Feb 2012 16:51:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvtgf-0003XO-Qu
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:51:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328892659!14368022!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3089 invoked from network); 10 Feb 2012 16:50:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:50:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvtgY-0008kR-83; Fri, 10 Feb 2012 16:50:58 +0000
Date: Fri, 10 Feb 2012 16:50:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120210165058.GH32107@ocelot.phlegethon.org>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
	<1328881958.6133.268.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328881958.6133.268.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
	xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:52 +0000 on 10 Feb (1328881958), Ian Campbell wrote:
> On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
> > On 10/02/12 13:35, Ian Campbell wrote:
> > > On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> > >> From: David Vrabel <david.vrabel@citrix.com>
> > >>
> > >> Link a device tree blob (DTB) into the xen image.  This is loaded
> > >> immediately after Xen and xen_start() is called with the correct
> > >> address in atag_paddr.
> > > 
> > > Is platform.dtb supposed to be included in this patch/series or is it
> > > intended that I should supply it from somewhere? (in which case, how and
> > > where etc).
> > 
> > I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
> > 
> > Would it be better build the DTB from source included in Xen?
> 
> I guess that's what Linux has done but I don't know if we want to
> replicate all that and keep syncing etc. On the flip side I suppose it's
> currently only a single platform.

I think we should take it into our tree in some form, unless there's a
way to automatically extract it from the dom0 kernel at boot.  It should
be possible to recompile Xen without needing to configure and build a
linux kernel.

In theory this will eventually be provided by the bootloader or
firmware, right?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:51:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16: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.xensource.com>)
	id 1Rvtgh-0003XT-Du; Fri, 10 Feb 2012 16:51:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rvtgf-0003XO-Qu
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:51:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328892659!14368022!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3089 invoked from network); 10 Feb 2012 16:50:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:50:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RvtgY-0008kR-83; Fri, 10 Feb 2012 16:50:58 +0000
Date: Fri, 10 Feb 2012 16:50:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120210165058.GH32107@ocelot.phlegethon.org>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
	<1328881958.6133.268.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328881958.6133.268.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
	xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:52 +0000 on 10 Feb (1328881958), Ian Campbell wrote:
> On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
> > On 10/02/12 13:35, Ian Campbell wrote:
> > > On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> > >> From: David Vrabel <david.vrabel@citrix.com>
> > >>
> > >> Link a device tree blob (DTB) into the xen image.  This is loaded
> > >> immediately after Xen and xen_start() is called with the correct
> > >> address in atag_paddr.
> > > 
> > > Is platform.dtb supposed to be included in this patch/series or is it
> > > intended that I should supply it from somewhere? (in which case, how and
> > > where etc).
> > 
> > I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
> > 
> > Would it be better build the DTB from source included in Xen?
> 
> I guess that's what Linux has done but I don't know if we want to
> replicate all that and keep syncing etc. On the flip side I suppose it's
> currently only a single platform.

I think we should take it into our tree in some form, unless there's a
way to automatically extract it from the dom0 kernel at boot.  It should
be possible to recompile Xen without needing to configure and build a
linux kernel.

In theory this will eventually be provided by the bootloader or
firmware, right?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:54:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtjJ-0003e7-05; Fri, 10 Feb 2012 16:53:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvtjG-0003dl-Py
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:53:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328892820!12705182!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28651 invoked from network); 10 Feb 2012 16:53:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Feb 2012 16:53:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328892820; l=544;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=coNuGOck9CQGu0emwEwjIj9lKmM=;
	b=qP5Zi6c0pnWQXJ+5HVZpMM0yGkRNaN37/1nwGu8U9CJNZIa/T0pBHouL+OS0mqfFv74
	aDPcl4vKKzi4TiB6cq90mt+rYKjLpY9PYWxKzFLY7V4LHdmrURp3Ybl69Jh0MN9YtFu08
	Y+1/bfmt7RaTvvITj1mMmM3vm44Y1Hhj5B8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (klopstock mo45) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 601449o1AG2IOR ;
	Fri, 10 Feb 2012 17:53:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BF05F18637; Fri, 10 Feb 2012 17:53:38 +0100 (CET)
Date: Fri, 10 Feb 2012 17:53:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120210165338.GA23915@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F34F96602000078000722DA@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> No, it shouldn't require anything else. Could you add a printk() each
> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
> (and at once checking that they actually get executed? I was under
> the impression that adding save records for HVM is a simple drop-in
> exercise these days...

The functions are called on both sides with no errors.


Regarding these messages, are they guest addresses?

(XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:54:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvtjJ-0003e7-05; Fri, 10 Feb 2012 16:53:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RvtjG-0003dl-Py
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:53:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328892820!12705182!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28651 invoked from network); 10 Feb 2012 16:53:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Feb 2012 16:53:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328892820; l=544;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=coNuGOck9CQGu0emwEwjIj9lKmM=;
	b=qP5Zi6c0pnWQXJ+5HVZpMM0yGkRNaN37/1nwGu8U9CJNZIa/T0pBHouL+OS0mqfFv74
	aDPcl4vKKzi4TiB6cq90mt+rYKjLpY9PYWxKzFLY7V4LHdmrURp3Ybl69Jh0MN9YtFu08
	Y+1/bfmt7RaTvvITj1mMmM3vm44Y1Hhj5B8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (klopstock mo45) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 601449o1AG2IOR ;
	Fri, 10 Feb 2012 17:53:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BF05F18637; Fri, 10 Feb 2012 17:53:38 +0100 (CET)
Date: Fri, 10 Feb 2012 17:53:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120210165338.GA23915@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F34F96602000078000722DA@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> No, it shouldn't require anything else. Could you add a printk() each
> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
> (and at once checking that they actually get executed? I was under
> the impression that adding save records for HVM is a simple drop-in
> exercise these days...

The functions are called on both sides with no errors.


Regarding these messages, are they guest addresses?

(XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:58:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvtns-0003zD-VZ; Fri, 10 Feb 2012 16:58:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rvtnr-0003z7-TE
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:58:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328893087!52430089!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27131 invoked from network); 10 Feb 2012 16:58:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:58:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 16:58:29 +0000
Message-Id: <4F355AC50200007800072701@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 16:58:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <xen-devel@lists.xensource.com>,<konrad.wilk@oracle.com>,
	<liang.tang@oracle.com>, <mjg59@srcf.ucam.org>,
	<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758328-24156-1-git-send-email-liang.tang@oracle.com>
In-Reply-To: <1328758328-24156-1-git-send-email-liang.tang@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH 1/5] EFI: Provide registration for
 efi_init.. etc efi public function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 04:32, Tang Liang <liang.tang@oracle.com> wrote:
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -50,6 +50,23 @@
>  #define PFX 		"EFI: "
>  
>  int efi_enabled;
> +
> +static void efi_init_generic(void);
> +
> +static void efi_enter_virtual_mode_generic(void);
> +static u32 efi_mem_type_generic(unsigned long phys_addr);
> +static u64 efi_mem_attributes_generic(unsigned long phys_addr);
> +
> +struct efi_init_funcs efi_generic_funcs = {

static const.

> +	.__efi_init		     = efi_init_generic,
> +	.__efi_reserve_boot_services = efi_reserve_boot_services_generic,
> +	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_generic,
> +	.__efi_mem_type		     = efi_mem_type_generic,
> +	.__efi_mem_attributes	     = efi_mem_attributes_generic
> +};
> +
> +struct efi_init_funcs *efi_override_funcs =  &efi_generic_funcs;

const struct ...

> +
>  EXPORT_SYMBOL(efi_enabled);
>  
>  struct efi __read_mostly efi = {
> @@ -781,3 +798,41 @@ u64 efi_mem_attributes(unsigned long phys_addr)
>  	}
>  	return 0;
>  }
> +
> +void efi_init_function_register(struct efi_init_funcs *funcs)

... (const struct ...

> +{
> +	efi_override_funcs = funcs;
> +}
> +
> +void __init efi_init(void)
> +{
> +	if (efi_override_funcs->__efi_init)
> +		efi_override_funcs->__efi_init();
> +}
> +
> +void __init efi_reserve_boot_services(void)
> +{
> +	if (efi_override_funcs->__efi_reserve_boot_services)
> +		efi_override_funcs->__efi_reserve_boot_services();
> +}
> +
> +void __init efi_enter_virtual_mode(void)
> +{
> +	if (efi_override_funcs->__efi_enter_virtual_mode)
> +		efi_override_funcs->__efi_enter_virtual_mode();
> +}
> +
> +
> +u32 efi_mem_type(unsigned long phys_addr)
> +{
> +	if (efi_override_funcs->__efi_mem_type)
> +		return efi_override_funcs->__efi_mem_type(phys_addr);
> +	return EFI_INVALID_TYPE;
> +}
> +
> +u64 efi_mem_attributes(unsigned long phys_addr)
> +{
> +	if (efi_override_funcs->__efi_mem_attributes)
> +		return efi_override_funcs->__efi_mem_attributes(phys_addr);
> +	return EFI_INVALID_ATTRIBUTE;
> +}
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -79,8 +79,9 @@ typedef	struct {
>  #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
>  #define EFI_PAL_CODE			13
>  #define EFI_MAX_MEMORY_TYPE		14
> -

I would suggest to retain the newline.

> +#define EFI_INVALID_TYPE		0xffffffff
>  /* Attribute values: */
> +#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid attribute*/
>  #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
>  #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
>  #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
> @@ -434,6 +435,14 @@ extern struct efi {
>  	efi_set_virtual_address_map_t *set_virtual_address_map;
>  } efi;
>  
> +struct efi_init_funcs {
> +	void (*__efi_init)(void);
> +	void (*__efi_reserve_boot_services)(void);
> +	void (*__efi_enter_virtual_mode)(void);
> +	u32 (*__efi_mem_type)(unsigned long phys_addr);
> +	u64 (*__efi_mem_attributes)(unsigned long phys_addr);

What is the reason for having the __ (or even the whole __efi_) at
their beginning?

Jan

> +};
> +
>  static inline int
>  efi_guidcmp (efi_guid_t left, efi_guid_t right)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 16:58:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 16:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvtns-0003zD-VZ; Fri, 10 Feb 2012 16:58:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rvtnr-0003z7-TE
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 16:58:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328893087!52430089!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27131 invoked from network); 10 Feb 2012 16:58:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:58:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 16:58:29 +0000
Message-Id: <4F355AC50200007800072701@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 16:58:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <xen-devel@lists.xensource.com>,<konrad.wilk@oracle.com>,
	<liang.tang@oracle.com>, <mjg59@srcf.ucam.org>,
	<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758328-24156-1-git-send-email-liang.tang@oracle.com>
In-Reply-To: <1328758328-24156-1-git-send-email-liang.tang@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH 1/5] EFI: Provide registration for
 efi_init.. etc efi public function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.02.12 at 04:32, Tang Liang <liang.tang@oracle.com> wrote:
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -50,6 +50,23 @@
>  #define PFX 		"EFI: "
>  
>  int efi_enabled;
> +
> +static void efi_init_generic(void);
> +
> +static void efi_enter_virtual_mode_generic(void);
> +static u32 efi_mem_type_generic(unsigned long phys_addr);
> +static u64 efi_mem_attributes_generic(unsigned long phys_addr);
> +
> +struct efi_init_funcs efi_generic_funcs = {

static const.

> +	.__efi_init		     = efi_init_generic,
> +	.__efi_reserve_boot_services = efi_reserve_boot_services_generic,
> +	.__efi_enter_virtual_mode    = efi_enter_virtual_mode_generic,
> +	.__efi_mem_type		     = efi_mem_type_generic,
> +	.__efi_mem_attributes	     = efi_mem_attributes_generic
> +};
> +
> +struct efi_init_funcs *efi_override_funcs =  &efi_generic_funcs;

const struct ...

> +
>  EXPORT_SYMBOL(efi_enabled);
>  
>  struct efi __read_mostly efi = {
> @@ -781,3 +798,41 @@ u64 efi_mem_attributes(unsigned long phys_addr)
>  	}
>  	return 0;
>  }
> +
> +void efi_init_function_register(struct efi_init_funcs *funcs)

... (const struct ...

> +{
> +	efi_override_funcs = funcs;
> +}
> +
> +void __init efi_init(void)
> +{
> +	if (efi_override_funcs->__efi_init)
> +		efi_override_funcs->__efi_init();
> +}
> +
> +void __init efi_reserve_boot_services(void)
> +{
> +	if (efi_override_funcs->__efi_reserve_boot_services)
> +		efi_override_funcs->__efi_reserve_boot_services();
> +}
> +
> +void __init efi_enter_virtual_mode(void)
> +{
> +	if (efi_override_funcs->__efi_enter_virtual_mode)
> +		efi_override_funcs->__efi_enter_virtual_mode();
> +}
> +
> +
> +u32 efi_mem_type(unsigned long phys_addr)
> +{
> +	if (efi_override_funcs->__efi_mem_type)
> +		return efi_override_funcs->__efi_mem_type(phys_addr);
> +	return EFI_INVALID_TYPE;
> +}
> +
> +u64 efi_mem_attributes(unsigned long phys_addr)
> +{
> +	if (efi_override_funcs->__efi_mem_attributes)
> +		return efi_override_funcs->__efi_mem_attributes(phys_addr);
> +	return EFI_INVALID_ATTRIBUTE;
> +}
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -79,8 +79,9 @@ typedef	struct {
>  #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
>  #define EFI_PAL_CODE			13
>  #define EFI_MAX_MEMORY_TYPE		14
> -

I would suggest to retain the newline.

> +#define EFI_INVALID_TYPE		0xffffffff
>  /* Attribute values: */
> +#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid attribute*/
>  #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
>  #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
>  #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
> @@ -434,6 +435,14 @@ extern struct efi {
>  	efi_set_virtual_address_map_t *set_virtual_address_map;
>  } efi;
>  
> +struct efi_init_funcs {
> +	void (*__efi_init)(void);
> +	void (*__efi_reserve_boot_services)(void);
> +	void (*__efi_enter_virtual_mode)(void);
> +	u32 (*__efi_mem_type)(unsigned long phys_addr);
> +	u64 (*__efi_mem_attributes)(unsigned long phys_addr);

What is the reason for having the __ (or even the whole __efi_) at
their beginning?

Jan

> +};
> +
>  static inline int
>  efi_guidcmp (efi_guid_t left, efi_guid_t right)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1RvtpW-00046G-Fb; Fri, 10 Feb 2012 17:00:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvtpU-00045u-MG
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:00:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328893183!52430295!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30596 invoked from network); 10 Feb 2012 16:59:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:59:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 17:00:06 +0000
Message-Id: <4F355B260200007800072704@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 17:00:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
In-Reply-To: <20120210165338.GA23915@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.02.12 at 17:53, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 10, Jan Beulich wrote:
> 
>> No, it shouldn't require anything else. Could you add a printk() each
>> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
>> (and at once checking that they actually get executed? I was under
>> the impression that adding save records for HVM is a simple drop-in
>> exercise these days...
> 
> The functions are called on both sides with no errors.

And the bank count also is correctly reflecting the original, save-side
value on the restore side?

> Regarding these messages, are they guest addresses?
> 
> (XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4

No, these are hypervisor ones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1RvtpW-00046G-Fb; Fri, 10 Feb 2012 17:00:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RvtpU-00045u-MG
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:00:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1328893183!52430295!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30596 invoked from network); 10 Feb 2012 16:59:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 16:59:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 10 Feb 2012 17:00:06 +0000
Message-Id: <4F355B260200007800072704@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 10 Feb 2012 17:00:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
In-Reply-To: <20120210165338.GA23915@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.02.12 at 17:53, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 10, Jan Beulich wrote:
> 
>> No, it shouldn't require anything else. Could you add a printk() each
>> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
>> (and at once checking that they actually get executed? I was under
>> the impression that adding save records for HVM is a simple drop-in
>> exercise these days...
> 
> The functions are called on both sides with no errors.

And the bank count also is correctly reflecting the original, save-side
value on the restore side?

> Regarding these messages, are they guest addresses?
> 
> (XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4

No, these are hypervisor ones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:05:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1Rvtu4-0004JT-7n; Fri, 10 Feb 2012 17:04:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvtu2-0004JD-7q
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:04:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328893487!10865362!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21082 invoked from network); 10 Feb 2012 17:04:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:04:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10628245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:04:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:04:14 +0000
Date: Fri, 10 Feb 2012 17:07:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4F350047.4030507@siemens.com>
Message-ID: <alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
	<alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
	<4F34FCF3.4080300@redhat.com> <4F350047.4030507@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Paul Brook <paul@codesourcery.com>, Paolo Bonzini <pbonzini@redhat.com>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Jan Kiszka wrote:
> On 2012-02-10 12:18, Paolo Bonzini wrote:
> > On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
> >> I think you are right and the right thing to do would be blocking
> >> indefinitely.
> >> However if slirp doesn't support it, we could have a timeout of 1000 if
> >> CONFIG_SLIRP, otherwise block indefinitely.
> > 
> > You could add a similar hack to qemu_bh_update_timeout for
> > slirp_update_timeout.
> 
> Real solutions would be preferred, but I know that the code is hairy. In
> any case, please no CONFIG_SLIRP code forks.

I tried to follow your suggestions, what do you guys think about the
approach of the patch below?

---


main_loop_wait: block indefinitely

- remove qemu_calculate_timeout;

- explicitly size timeout to uint32_t;

- introduce slirp_update_timeout;

- pass NULL as timeout argument to select in case timeout is the maximum
value;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>



diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index 692381c..4a105e9 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -366,7 +366,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
     }
 }
 
-static void os_host_main_loop_wait(int *timeout)
+static void os_host_main_loop_wait(uint32_t *timeout)
 {
     int ret, ret2, i;
     PollingEntry *pe;
@@ -410,7 +410,7 @@ static void os_host_main_loop_wait(int *timeout)
     *timeout = 0;
 }
 #else
-static inline void os_host_main_loop_wait(int *timeout)
+static inline void os_host_main_loop_wait(uint32_t *timeout)
 {
 }
 #endif
@@ -419,21 +419,17 @@ int main_loop_wait(int nonblocking)
 {
     fd_set rfds, wfds, xfds;
     int ret, nfds;
-    struct timeval tv;
-    int timeout;
+    struct timeval tv, *tvarg = NULL;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
     os_host_main_loop_wait(&timeout);
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
@@ -442,16 +438,23 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
diff --git a/main-loop.h b/main-loop.h
index f971013..22c0dc9 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -352,6 +352,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..3e1ce08 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index de17f3b..f1386d5 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -62,7 +62,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..6af7534 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -42,4 +42,13 @@ void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr,
 size_t slirp_socket_can_recv(Slirp *slirp, struct in_addr guest_addr,
                              int guest_port);
 
+#ifdef CONFIG_SLIRP
+static inline void slirp_update_timeout(uint32_t *timeout)
+{
+    *timeout = MIN(1000, *timeout);
+}
+#else
+static inline void slirp_update_timeout(uint32_t *timeout) { }
+#endif
+
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:05:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1Rvtu4-0004JT-7n; Fri, 10 Feb 2012 17:04:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvtu2-0004JD-7q
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:04:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328893487!10865362!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21082 invoked from network); 10 Feb 2012 17:04:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:04:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10628245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:04:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:04:14 +0000
Date: Fri, 10 Feb 2012 17:07:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Kiszka <jan.kiszka@siemens.com>
In-Reply-To: <4F350047.4030507@siemens.com>
Message-ID: <alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
	<201202101109.03374.paul@codesourcery.com>
	<alpine.DEB.2.00.1202101114370.7456@kaball-desktop>
	<4F34FCF3.4080300@redhat.com> <4F350047.4030507@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Paul Brook <paul@codesourcery.com>, Paolo Bonzini <pbonzini@redhat.com>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Jan Kiszka wrote:
> On 2012-02-10 12:18, Paolo Bonzini wrote:
> > On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
> >> I think you are right and the right thing to do would be blocking
> >> indefinitely.
> >> However if slirp doesn't support it, we could have a timeout of 1000 if
> >> CONFIG_SLIRP, otherwise block indefinitely.
> > 
> > You could add a similar hack to qemu_bh_update_timeout for
> > slirp_update_timeout.
> 
> Real solutions would be preferred, but I know that the code is hairy. In
> any case, please no CONFIG_SLIRP code forks.

I tried to follow your suggestions, what do you guys think about the
approach of the patch below?

---


main_loop_wait: block indefinitely

- remove qemu_calculate_timeout;

- explicitly size timeout to uint32_t;

- introduce slirp_update_timeout;

- pass NULL as timeout argument to select in case timeout is the maximum
value;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>



diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index 692381c..4a105e9 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -366,7 +366,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
     }
 }
 
-static void os_host_main_loop_wait(int *timeout)
+static void os_host_main_loop_wait(uint32_t *timeout)
 {
     int ret, ret2, i;
     PollingEntry *pe;
@@ -410,7 +410,7 @@ static void os_host_main_loop_wait(int *timeout)
     *timeout = 0;
 }
 #else
-static inline void os_host_main_loop_wait(int *timeout)
+static inline void os_host_main_loop_wait(uint32_t *timeout)
 {
 }
 #endif
@@ -419,21 +419,17 @@ int main_loop_wait(int nonblocking)
 {
     fd_set rfds, wfds, xfds;
     int ret, nfds;
-    struct timeval tv;
-    int timeout;
+    struct timeval tv, *tvarg = NULL;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
     os_host_main_loop_wait(&timeout);
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
@@ -442,16 +438,23 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
diff --git a/main-loop.h b/main-loop.h
index f971013..22c0dc9 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -352,6 +352,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..3e1ce08 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index de17f3b..f1386d5 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -62,7 +62,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..6af7534 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -42,4 +42,13 @@ void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr,
 size_t slirp_socket_can_recv(Slirp *slirp, struct in_addr guest_addr,
                              int guest_port);
 
+#ifdef CONFIG_SLIRP
+static inline void slirp_update_timeout(uint32_t *timeout)
+{
+    *timeout = MIN(1000, *timeout);
+}
+#else
+static inline void slirp_update_timeout(uint32_t *timeout) { }
+#endif
+
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvtuc-0004N7-RU; Fri, 10 Feb 2012 17:05:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rvtub-0004M6-Af
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:05:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328893522!12353439!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7265 invoked from network); 10 Feb 2012 17:05:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 17:05:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328893522; l=728;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WKBggIs9DeoesxSLuv5q3+iwoHE=;
	b=FOyRAfy2AOwJwqjY0BekfpiZaHgfWyvVIZEzqNvSwl+rlTzZ0loIFUcyA/dGkV9BAzY
	Wukb5JWZF6VVcvAPhjmm6cHwAmu7bZPDldDqNC3MTVqqI19KMwvVv/4T9xx10ueDjzT3C
	8/gx1XfUDxCwApsc7k02k0dF09LHf8zfpLk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (cohen mo22) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0025bo1AFikRC ;
	Fri, 10 Feb 2012 18:05:09 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3DDC818637; Fri, 10 Feb 2012 18:05:16 +0100 (CET)
Date: Fri, 10 Feb 2012 18:05:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120210170516.GA25896@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
	<4F355B260200007800072704@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F355B260200007800072704@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> >>> On 10.02.12 at 17:53, Olaf Hering <olaf@aepfle.de> wrote:
> > On Fri, Feb 10, Jan Beulich wrote:
> > 
> >> No, it shouldn't require anything else. Could you add a printk() each
> >> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
> >> (and at once checking that they actually get executed? I was under
> >> the impression that adding save records for HVM is a simple drop-in
> >> exercise these days...
> > 
> > The functions are called on both sides with no errors.
> 
> And the bank count also is correctly reflecting the original, save-side
> value on the restore side?

Oh, the count is zero on both sides?
I will double check my dbg patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvtuc-0004N7-RU; Fri, 10 Feb 2012 17:05:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rvtub-0004M6-Af
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:05:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328893522!12353439!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7265 invoked from network); 10 Feb 2012 17:05:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 17:05:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328893522; l=728;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WKBggIs9DeoesxSLuv5q3+iwoHE=;
	b=FOyRAfy2AOwJwqjY0BekfpiZaHgfWyvVIZEzqNvSwl+rlTzZ0loIFUcyA/dGkV9BAzY
	Wukb5JWZF6VVcvAPhjmm6cHwAmu7bZPDldDqNC3MTVqqI19KMwvVv/4T9xx10ueDjzT3C
	8/gx1XfUDxCwApsc7k02k0dF09LHf8zfpLk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (cohen mo22) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0025bo1AFikRC ;
	Fri, 10 Feb 2012 18:05:09 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3DDC818637; Fri, 10 Feb 2012 18:05:16 +0100 (CET)
Date: Fri, 10 Feb 2012 18:05:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120210170516.GA25896@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
	<4F355B260200007800072704@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F355B260200007800072704@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> >>> On 10.02.12 at 17:53, Olaf Hering <olaf@aepfle.de> wrote:
> > On Fri, Feb 10, Jan Beulich wrote:
> > 
> >> No, it shouldn't require anything else. Could you add a printk() each
> >> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
> >> (and at once checking that they actually get executed? I was under
> >> the impression that adding save records for HVM is a simple drop-in
> >> exercise these days...
> > 
> > The functions are called on both sides with no errors.
> 
> And the bank count also is correctly reflecting the original, save-side
> value on the restore side?

Oh, the count is zero on both sides?
I will double check my dbg patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:11:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvtzq-0004fg-KI; Fri, 10 Feb 2012 17:10:54 +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 1Rvtzo-0004fW-OJ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:10:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328893826!65358384!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 10 Feb 2012 17:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10628426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:10:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:10:48 +0000
Date: Fri, 10 Feb 2012 17:14:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202101713500.7456@kaball-desktop>
References: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "stefano.stabellni@citrix.com" <stefano.stabellni@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1328888874 0
> # Node ID e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
> # Parent  6efeff914609a3870e2d07a8d73a26c4615ac60b
> qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
> 
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions even
> if pass-through graphics are not enabled.  If qemu is run without
> permission to this file, this causes qemu to fail during
> initialization.
> 
> This patch re-works the functions so that the initialization happens
> only if we actually need to do the pci host read or write.  It also
> makes failures call abort().
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

the patch is OK


> diff -r 6efeff914609 -r e4a4e4f4156d hw/pass-through.h
> --- a/hw/pass-through.h	Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pass-through.h	Fri Feb 10 15:47:54 2012 +0000
> @@ -29,6 +29,8 @@
>  /* Log acesss */
>  #define PT_LOGGING_ENABLED
>  
> +/* Print errors even if logging is disabled */
> +#define PT_ERR(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
>  #ifdef PT_LOGGING_ENABLED
>  #define PT_LOG(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
>  #define PT_LOG_DEV(_dev, _f, _a...)   fprintf(logfile, "%s: [%02x:%02x:%01x] " _f, __func__,    \
> diff -r 6efeff914609 -r e4a4e4f4156d hw/pt-graphics.c
> --- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pt-graphics.c	Fri Feb 10 15:47:54 2012 +0000
> @@ -23,11 +23,17 @@ void intel_pch_init(PCIBus *bus)
>  {
>      uint16_t vid, did;
>      uint8_t  rid;
> -    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
> +    struct pci_dev *pci_dev_1f;
>  
> -    if ( !gfx_passthru || !pci_dev_1f )
> +    if ( !gfx_passthru )
>          return;
>  
> +    if ( !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
> +    {
> +        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
>      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
>      did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>      rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
> @@ -39,36 +45,45 @@ void intel_pch_init(PCIBus *bus)
>  
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> -        pci_default_write_config(pci_dev, config_addr, val, len);
> -        return;
> -    }
> +    if ( !igd_passthru )
> +        goto write_default;
>  
>      switch (config_addr)
>      {
>          case 0x58:        // PAVPC Offset
> -            pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> -            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> -                    config_addr, len, val);
> -#endif
>              break;
>          default:
> -            pci_default_write_config(pci_dev, config_addr, val, len);
> +            goto write_default;
>      }
> +
> +    /* Host write */
> +    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
> +    {
> +        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> +               config_addr, len, val);
> +#endif
> +    return;
> +
> +write_default:
> +    pci_default_write_config(pci_dev, config_addr, val, len);
>  }
>  
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      uint32_t val;
>  
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> -        return pci_default_read_config(pci_dev, config_addr, len);
> -    }
> +    if ( !igd_passthru )
> +        goto read_default;
>  
>      switch (config_addr)
>      {
> @@ -81,16 +96,28 @@ uint32_t igd_pci_read(PCIDevice *pci_dev
>          case 0x58:        /* SNB: PAVPC Offset */
>          case 0xa4:        /* SNB: graphics base of stolen memory */
>          case 0xa8:        /* SNB: base of GTT stolen memory */
> -            val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> -            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> -                    config_addr, len, val);
> -#endif
>              break;
>          default:
> -            val = pci_default_read_config(pci_dev, config_addr, len);
> +            goto read_default;
>      }
> +
> +    /* Host read */
> +    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
> +    {
> +        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> +               config_addr, len, val);
> +#endif
>      return val;
> +   
> +read_default:
> +   
> +   return pci_default_read_config(pci_dev, config_addr, len);
>  }
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:11:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvtzq-0004fg-KI; Fri, 10 Feb 2012 17:10:54 +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 1Rvtzo-0004fW-OJ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:10:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328893826!65358384!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 10 Feb 2012 17:10:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10628426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:10:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:10:48 +0000
Date: Fri, 10 Feb 2012 17:14:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202101713500.7456@kaball-desktop>
References: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "stefano.stabellni@citrix.com" <stefano.stabellni@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1328888874 0
> # Node ID e4a4e4f4156dcdffb8e81fb28bb16b6a9d611af7
> # Parent  6efeff914609a3870e2d07a8d73a26c4615ac60b
> qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
> 
> A recent changeset introduced a bug whereby an initialization function
> that reads /proc/bus/pci is called from graphics set-up functions even
> if pass-through graphics are not enabled.  If qemu is run without
> permission to this file, this causes qemu to fail during
> initialization.
> 
> This patch re-works the functions so that the initialization happens
> only if we actually need to do the pci host read or write.  It also
> makes failures call abort().
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

the patch is OK


> diff -r 6efeff914609 -r e4a4e4f4156d hw/pass-through.h
> --- a/hw/pass-through.h	Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pass-through.h	Fri Feb 10 15:47:54 2012 +0000
> @@ -29,6 +29,8 @@
>  /* Log acesss */
>  #define PT_LOGGING_ENABLED
>  
> +/* Print errors even if logging is disabled */
> +#define PT_ERR(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
>  #ifdef PT_LOGGING_ENABLED
>  #define PT_LOG(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
>  #define PT_LOG_DEV(_dev, _f, _a...)   fprintf(logfile, "%s: [%02x:%02x:%01x] " _f, __func__,    \
> diff -r 6efeff914609 -r e4a4e4f4156d hw/pt-graphics.c
> --- a/hw/pt-graphics.c	Fri Feb 10 11:02:25 2012 +0000
> +++ b/hw/pt-graphics.c	Fri Feb 10 15:47:54 2012 +0000
> @@ -23,11 +23,17 @@ void intel_pch_init(PCIBus *bus)
>  {
>      uint16_t vid, did;
>      uint8_t  rid;
> -    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
> +    struct pci_dev *pci_dev_1f;
>  
> -    if ( !gfx_passthru || !pci_dev_1f )
> +    if ( !gfx_passthru )
>          return;
>  
> +    if ( !(pci_dev_1f=pt_pci_get_dev(0, 0x1f, 0)) )
> +    {
> +        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
>      vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
>      did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>      rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
> @@ -39,36 +45,45 @@ void intel_pch_init(PCIBus *bus)
>  
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> -        pci_default_write_config(pci_dev, config_addr, val, len);
> -        return;
> -    }
> +    if ( !igd_passthru )
> +        goto write_default;
>  
>      switch (config_addr)
>      {
>          case 0x58:        // PAVPC Offset
> -            pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> -            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> -                    config_addr, len, val);
> -#endif
>              break;
>          default:
> -            pci_default_write_config(pci_dev, config_addr, val, len);
> +            goto write_default;
>      }
> +
> +    /* Host write */
> +    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
> +    {
> +        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> +               config_addr, len, val);
> +#endif
> +    return;
> +
> +write_default:
> +    pci_default_write_config(pci_dev, config_addr, val, len);
>  }
>  
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  {
> -    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    struct pci_dev *pci_dev_host_bridge;
>      uint32_t val;
>  
>      assert(pci_dev->devfn == 0x00);
> -    if ( !igd_passthru ) {
> -        return pci_default_read_config(pci_dev, config_addr, len);
> -    }
> +    if ( !igd_passthru )
> +        goto read_default;
>  
>      switch (config_addr)
>      {
> @@ -81,16 +96,28 @@ uint32_t igd_pci_read(PCIDevice *pci_dev
>          case 0x58:        /* SNB: PAVPC Offset */
>          case 0xa4:        /* SNB: graphics base of stolen memory */
>          case 0xa8:        /* SNB: base of GTT stolen memory */
> -            val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> -            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> -                    config_addr, len, val);
> -#endif
>              break;
>          default:
> -            val = pci_default_read_config(pci_dev, config_addr, len);
> +            goto read_default;
>      }
> +
> +    /* Host read */
> +    if ( !(pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0)) )
> +    {
> +        PT_ERR("Error: Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> +               config_addr, len, val);
> +#endif
>      return val;
> +   
> +read_default:
> +   
> +   return pci_default_read_config(pci_dev, config_addr, len);
>  }
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:13:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1Rvu25-0004lS-6G; Fri, 10 Feb 2012 17:13:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvu23-0004l9-Fn
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:13:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328893985!14370997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10990 invoked from network); 10 Feb 2012 17:13:05 -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;
	10 Feb 2012 17:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10628464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:13:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:13:05 +0000
Date: Fri, 10 Feb 2012 17:16:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101716040.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
	<alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
	<CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-837351818-1328894209=:7456"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-837351818-1328894209=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Fri, 10 Feb 2012, Teck Choon Giam wrote:
> Hi Stefano,
> 
> On Fri, Feb 10, 2012 at 6:45 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 9 Feb 2012, Teck Choon Giam wrote:
> >> Hi,
> >>
> >> I need to check whether is this intended?  When using xl create hvm
> >> domains, it does execute vif-bridge script.  However, when doing xl
> >> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
> >> script.  I just did the following to test:
> >>
> >> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
> >> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
> >> #!/bin/bash
> >> echo "$@" >> vif-bridge.log
> >> /etc/xen/scripts/vif-bridge.orig "$@"
> >> EOF
> >>
> >> When using xm and xl to create hvmdomain, I can see vif-bridge.log
> >> appended with:
> >>
> >> online type_if=vif
> >> online type_if=vif
> >> add type_if=tap
> >> add type_if=tap
> >>
> >> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
> >> gets to execute vif-bridge once for each vif which looks right.
> >>
> >> Now the problem is xl trigger hvmdomain power and xl destroy power.
> >> Both never call vif-bridge script as there isn't any such line like:
> >>
> >> offline type_if=vif
> >> offline type_if=vif
> >>
> >> Whereby when I tried with xm trigger hvmdomain power, it does call
> >> vif-bridge script as the above two lines get logged.
> >>
> >> This will leave the iptables FORWARD rule intact when using xl which I
> >> reported before :(
> >>
> >> See http://www.gossamer-threads.com/lists/xen/devel/204990
> >
> > Actually I have just run the same test but I didn't see any issues:
> > vif-bridge gets called correctly when the domain dies.
> >
> > It is difficult to tell what is going wrong in your case because
> > vif-bridge is not called directly by XL (or Xend), it is called by
> > vif-setup, that is called by udev when the vif network interface is
> > destroyed.
> > I suggest you check that your udev scripts are correct
> > (/etc/udev/rules.d/xen-backend.rules).
> 
> Here is the content of the rules:
> 
> # cat /etc/udev/rules.d/xen-backend.rules
> SUBSYSTEM=="xen-backend", KERNEL=="tap*",
> RUN+="/etc/xen/scripts/blktap $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block
> $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm
> $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vif2-*",
> RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online",
> RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline",
> RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
> SUBSYSTEM=="xen-backend", KERNEL=="vscsi*",
> RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
> SUBSYSTEM=="xen-backend", ACTION=="remove",
> RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
> KERNEL=="evtchn", NAME="xen/%k"
> SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
> SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k",
> MODE="0600"
> KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
> KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
> KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
> KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add",
> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
> 
> I guess the responsible lines are:
> 
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online",
> RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline",
> RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
> 
> So this is my testing:
> 
> # cp -pvf /etc/xen/scripts/vif-setup /etc/xen/scripts/vif-setup.orig
> # cat > /etc/xen/scripts/vif-setup <<'EOF'
> #!/bin/bash
> echo "$@" >> $0.log
> /etc/xen/scripts/vif-setup.orig "$@"
> EOF
> 
> Now my testing purely on xm/xl trigger hvmdomain power.
> 
> Online/Offline get called using xm but xl wise is Online get called
> but not Offline with hvm domains like windows XP/server 2008r2... any
> idea what else can make this behaviour difference between xl/xm?
> 
> The /etc/xen/scripts/vif-setup.log as below.
> 
> The below is using xl create hvmdomain and get logged:
> online type_if=vif
> online type_if=vif
> add type_if=tap
> add type_if=tap
> When using xl trigger hvmdomain power... no log entry at all.

Does xl trigger hvmdomain power do anything at all?
Is the guest shutting down?

--8323329-837351818-1328894209=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-837351818-1328894209=:7456--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:13:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1Rvu25-0004lS-6G; Fri, 10 Feb 2012 17:13:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rvu23-0004l9-Fn
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:13:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328893985!14370997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10990 invoked from network); 10 Feb 2012 17:13:05 -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;
	10 Feb 2012 17:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="10628464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:13:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:13:05 +0000
Date: Fri, 10 Feb 2012 17:16:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202101716040.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
	<alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
	<CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-837351818-1328894209=:7456"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-837351818-1328894209=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Fri, 10 Feb 2012, Teck Choon Giam wrote:
> Hi Stefano,
> 
> On Fri, Feb 10, 2012 at 6:45 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 9 Feb 2012, Teck Choon Giam wrote:
> >> Hi,
> >>
> >> I need to check whether is this intended?  When using xl create hvm
> >> domains, it does execute vif-bridge script.  However, when doing xl
> >> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
> >> script.  I just did the following to test:
> >>
> >> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
> >> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
> >> #!/bin/bash
> >> echo "$@" >> vif-bridge.log
> >> /etc/xen/scripts/vif-bridge.orig "$@"
> >> EOF
> >>
> >> When using xm and xl to create hvmdomain, I can see vif-bridge.log
> >> appended with:
> >>
> >> online type_if=vif
> >> online type_if=vif
> >> add type_if=tap
> >> add type_if=tap
> >>
> >> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
> >> gets to execute vif-bridge once for each vif which looks right.
> >>
> >> Now the problem is xl trigger hvmdomain power and xl destroy power.
> >> Both never call vif-bridge script as there isn't any such line like:
> >>
> >> offline type_if=vif
> >> offline type_if=vif
> >>
> >> Whereby when I tried with xm trigger hvmdomain power, it does call
> >> vif-bridge script as the above two lines get logged.
> >>
> >> This will leave the iptables FORWARD rule intact when using xl which I
> >> reported before :(
> >>
> >> See http://www.gossamer-threads.com/lists/xen/devel/204990
> >
> > Actually I have just run the same test but I didn't see any issues:
> > vif-bridge gets called correctly when the domain dies.
> >
> > It is difficult to tell what is going wrong in your case because
> > vif-bridge is not called directly by XL (or Xend), it is called by
> > vif-setup, that is called by udev when the vif network interface is
> > destroyed.
> > I suggest you check that your udev scripts are correct
> > (/etc/udev/rules.d/xen-backend.rules).
> 
> Here is the content of the rules:
> 
> # cat /etc/udev/rules.d/xen-backend.rules
> SUBSYSTEM=="xen-backend", KERNEL=="tap*",
> RUN+="/etc/xen/scripts/blktap $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block
> $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm
> $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vif2-*",
> RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online",
> RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline",
> RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
> SUBSYSTEM=="xen-backend", KERNEL=="vscsi*",
> RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
> SUBSYSTEM=="xen-backend", ACTION=="remove",
> RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
> KERNEL=="evtchn", NAME="xen/%k"
> SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
> SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k",
> MODE="0600"
> KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
> KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
> KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
> KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add",
> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
> 
> I guess the responsible lines are:
> 
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online",
> RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
> SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline",
> RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
> 
> So this is my testing:
> 
> # cp -pvf /etc/xen/scripts/vif-setup /etc/xen/scripts/vif-setup.orig
> # cat > /etc/xen/scripts/vif-setup <<'EOF'
> #!/bin/bash
> echo "$@" >> $0.log
> /etc/xen/scripts/vif-setup.orig "$@"
> EOF
> 
> Now my testing purely on xm/xl trigger hvmdomain power.
> 
> Online/Offline get called using xm but xl wise is Online get called
> but not Offline with hvm domains like windows XP/server 2008r2... any
> idea what else can make this behaviour difference between xl/xm?
> 
> The /etc/xen/scripts/vif-setup.log as below.
> 
> The below is using xl create hvmdomain and get logged:
> online type_if=vif
> online type_if=vif
> add type_if=tap
> add type_if=tap
> When using xl trigger hvmdomain power... no log entry at all.

Does xl trigger hvmdomain power do anything at all?
Is the guest shutting down?

--8323329-837351818-1328894209=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-837351818-1328894209=:7456--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:22:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1RvuAT-00054s-Dy; Fri, 10 Feb 2012 17:21: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 1RvuAS-00054e-2A
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:21:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328894479!59362914!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23917 invoked from network); 10 Feb 2012 17:21:20 -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; 10 Feb 2012 17:21: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 q1AHLeOc013993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 17:21:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1AHLZEa001259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 17:21:35 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
	q1AHLVog008762; Fri, 10 Feb 2012 11:21:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 09:21:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 86E01422F9; Fri, 10 Feb 2012 12:18:38 -0500 (EST)
Date: Fri, 10 Feb 2012 12:18:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20120210171838.GB25046@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F355228.0055,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
	virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +	if (pr->id == -1) {
> +		int device_declaration;
> +		int apic_id = -1;
> +
> +		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
> +			device_declaration = 0;
> +		else
> +			device_declaration = 1;
> +
> +		apic_id = acpi_get_cpuid(pr->handle,
> +			device_declaration, pr->acpi_id);
> +		if (apic_id == -1) {
> +			/* Processor is not present in MADT table */

So I was struggling to find an easy way to make the cases below (where
VCPU != physical CPU) work with using the driver that iterates over the
'processor' and was mystified to why it would not work, even with this
patchset. Found out that the acpi_get_cpuid does this:


201 #ifdef CONFIG_SMP
202         for_each_possible_cpu(i) {
203                 if (cpu_physical_id(i) == apic_id)
204                         return i;
205         }

and since not-online vCPUs (so dom0_max_vcpus) are not in the "possible"
bitmask, we never get to check line 203 and end up returning -1 for
offline/not-present/not-possible vCPUs.

Which means that we end up here:
> +			return 0;
> +		}
> +

instead of going through the pr->id = 0.

By the end of this, the information that the hypervisor gets is
actually limited to the amount of CPUs that we specified in dom0_max_vcpus=

> +		/*
> +		 * It's possible to have pr->id as '-1' even when it's actually
> +		 * present in MADT table, e.g. due to limiting dom0 max vcpus
> +		 * less than physical present number. In such case we still want
> +		 * to parse ACPI processor object information, so mimic the
> +		 * pr->id to CPU-0. This should be safe because we only care
> +		 * about raw ACPI information, which only relies on pr->acpi_id.
> +		 * For other information relying on pr->id and gathered through
> +		 * SMP function call, it's safe to let them run on CPU-0 since
> +		 * underlying Xen will collect them. Only a valid pr->id can
> +		 * make later invocations forward progress.
> +		 */
> +		pr->id = 0;
> +	}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:22:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17: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.xensource.com>)
	id 1RvuAT-00054s-Dy; Fri, 10 Feb 2012 17:21: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 1RvuAS-00054e-2A
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:21:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328894479!59362914!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM5NjQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23917 invoked from network); 10 Feb 2012 17:21:20 -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; 10 Feb 2012 17:21: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 q1AHLeOc013993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 10 Feb 2012 17:21:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1AHLZEa001259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 10 Feb 2012 17:21:35 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
	q1AHLVog008762; Fri, 10 Feb 2012 11:21:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 10 Feb 2012 09:21:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 86E01422F9; Fri, 10 Feb 2012 12:18:38 -0500 (EST)
Date: Fri, 10 Feb 2012 12:18:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Message-ID: <20120210171838.GB25046@phenom.dumpdata.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
	<1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F355228.0055,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: Re: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen
	virtual CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +	if (pr->id == -1) {
> +		int device_declaration;
> +		int apic_id = -1;
> +
> +		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
> +			device_declaration = 0;
> +		else
> +			device_declaration = 1;
> +
> +		apic_id = acpi_get_cpuid(pr->handle,
> +			device_declaration, pr->acpi_id);
> +		if (apic_id == -1) {
> +			/* Processor is not present in MADT table */

So I was struggling to find an easy way to make the cases below (where
VCPU != physical CPU) work with using the driver that iterates over the
'processor' and was mystified to why it would not work, even with this
patchset. Found out that the acpi_get_cpuid does this:


201 #ifdef CONFIG_SMP
202         for_each_possible_cpu(i) {
203                 if (cpu_physical_id(i) == apic_id)
204                         return i;
205         }

and since not-online vCPUs (so dom0_max_vcpus) are not in the "possible"
bitmask, we never get to check line 203 and end up returning -1 for
offline/not-present/not-possible vCPUs.

Which means that we end up here:
> +			return 0;
> +		}
> +

instead of going through the pr->id = 0.

By the end of this, the information that the hypervisor gets is
actually limited to the amount of CPUs that we specified in dom0_max_vcpus=

> +		/*
> +		 * It's possible to have pr->id as '-1' even when it's actually
> +		 * present in MADT table, e.g. due to limiting dom0 max vcpus
> +		 * less than physical present number. In such case we still want
> +		 * to parse ACPI processor object information, so mimic the
> +		 * pr->id to CPU-0. This should be safe because we only care
> +		 * about raw ACPI information, which only relies on pr->acpi_id.
> +		 * For other information relying on pr->id and gathered through
> +		 * SMP function call, it's safe to let them run on CPU-0 since
> +		 * underlying Xen will collect them. Only a valid pr->id can
> +		 * make later invocations forward progress.
> +		 */
> +		pr->id = 0;
> +	}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:26:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuEC-0005HW-N7; Fri, 10 Feb 2012 17:25:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvuEA-0005HA-PH
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:25:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328894736!13459783!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30047 invoked from network); 10 Feb 2012 17:25:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:25:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="10628899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:25:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:25:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvuE4-0005s4-ER; Fri, 10 Feb 2012 17:25:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvuE4-000335-D2;
	Fri, 10 Feb 2012 17:25:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20277.21264.232573.409262@mariner.uk.xensource.com>
Date: Fri, 10 Feb 2012 17:25:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328875670.6133.259.camel@zakaz.uk.xensource.com>
References: <osstest-11905-mainreport@xen.org>
	<1328866262.6133.257.camel@zakaz.uk.xensource.com>
	<1328875670.6133.259.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL"):
> On Fri, 2012-02-10 at 09:31 +0000, Ian Campbell wrote:
> > Daniel, I'm afraid I suspect the XS stubdom series for this one. My
> > suspicion is a missing call to seed_grant_table from xend (or from a
> > libxc function which xend uses) which prevents xenstored from mapping
> > the guest's ring, which results in an error from map_interface() in
> > xenstored.
> 
> The following seems to fix it for me. I also tested an HVM migration
> with xm since that seemed like something which might also suffer. It
> seemed ok.

Thanks for debugging this, Ian.  I have applied your patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:26:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuEC-0005HW-N7; Fri, 10 Feb 2012 17:25:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RvuEA-0005HA-PH
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:25:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328894736!13459783!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30047 invoked from network); 10 Feb 2012 17:25:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:25:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="10628899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:25:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:25:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RvuE4-0005s4-ER; Fri, 10 Feb 2012 17:25:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RvuE4-000335-D2;
	Fri, 10 Feb 2012 17:25:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20277.21264.232573.409262@mariner.uk.xensource.com>
Date: Fri, 10 Feb 2012 17:25:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328875670.6133.259.camel@zakaz.uk.xensource.com>
References: <osstest-11905-mainreport@xen.org>
	<1328866262.6133.257.camel@zakaz.uk.xensource.com>
	<1328875670.6133.259.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11905: regressions - FAIL"):
> On Fri, 2012-02-10 at 09:31 +0000, Ian Campbell wrote:
> > Daniel, I'm afraid I suspect the XS stubdom series for this one. My
> > suspicion is a missing call to seed_grant_table from xend (or from a
> > libxc function which xend uses) which prevents xenstored from mapping
> > the guest's ring, which results in an error from map_interface() in
> > xenstored.
> 
> The following seems to fix it for me. I also tested an HVM migration
> with xm since that seemed like something which might also suffer. It
> seemed ok.

Thanks for debugging this, Ian.  I have applied your patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:30:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuIj-0005Rp-3U; Fri, 10 Feb 2012 17:30:25 +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 1RvuIh-0005Rf-4u
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:30:23 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328894973!59651027!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31947 invoked from network); 10 Feb 2012 17:29:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:29:34 -0000
Received: by damc16 with SMTP id c16so19505675dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 09:30:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=sxA2/MPveedniHcm3jTu/Yhw/YNE1eUOVJosaxxusl8=;
	b=Upe7rF6ziQZGqLtLQMPSimF+EkIUYRVMAph5mAmqU1Di8JfAZnYwcgLR7gCDuiH2gv
	Am9y92gQwn5ilONN/ltewdrhWHrSxJTq5KTDELM4gNzxVN6yM79tkgnAOKKckp3BW9d+
	7+UhOxOTU147EfCU35r9rR46Zc6MoRbf33hTY=
MIME-Version: 1.0
Received: by 10.68.220.232 with SMTP id pz8mr18356703pbc.28.1328895016656;
	Fri, 10 Feb 2012 09:30:16 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Fri, 10 Feb 2012 09:30:16 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202101716040.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
	<alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
	<CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
	<alpine.DEB.2.00.1202101716040.7456@kaball-desktop>
Date: Sat, 11 Feb 2012 01:30:16 +0800
Message-ID: <CAEwRVpMFUCMFJJb9um-yY3QjhenVPbJaAjdOZbOAE9aDXnueNw@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Feb 11, 2012 at 1:16 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 10 Feb 2012, Teck Choon Giam wrote:
>> Hi Stefano,
>>
>> On Fri, Feb 10, 2012 at 6:45 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 9 Feb 2012, Teck Choon Giam wrote:
>> >> Hi,
>> >>
>> >> I need to check whether is this intended? =A0When using xl create hvm
>> >> domains, it does execute vif-bridge script. =A0However, when doing xl
>> >> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
>> >> script. =A0I just did the following to test:
>> >>
>> >> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
>> >> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
>> >> #!/bin/bash
>> >> echo "$@" >> vif-bridge.log
>> >> /etc/xen/scripts/vif-bridge.orig "$@"
>> >> EOF
>> >>
>> >> When using xm and xl to create hvmdomain, I can see vif-bridge.log
>> >> appended with:
>> >>
>> >> online type_if=3Dvif
>> >> online type_if=3Dvif
>> >> add type_if=3Dtap
>> >> add type_if=3Dtap
>> >>
>> >> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
>> >> gets to execute vif-bridge once for each vif which looks right.
>> >>
>> >> Now the problem is xl trigger hvmdomain power and xl destroy power.
>> >> Both never call vif-bridge script as there isn't any such line like:
>> >>
>> >> offline type_if=3Dvif
>> >> offline type_if=3Dvif
>> >>
>> >> Whereby when I tried with xm trigger hvmdomain power, it does call
>> >> vif-bridge script as the above two lines get logged.
>> >>
>> >> This will leave the iptables FORWARD rule intact when using xl which I
>> >> reported before :(
>> >>
>> >> See http://www.gossamer-threads.com/lists/xen/devel/204990
>> >
>> > Actually I have just run the same test but I didn't see any issues:
>> > vif-bridge gets called correctly when the domain dies.
>> >
>> > It is difficult to tell what is going wrong in your case because
>> > vif-bridge is not called directly by XL (or Xend), it is called by
>> > vif-setup, that is called by udev when the vif network interface is
>> > destroyed.
>> > I suggest you check that your udev scripts are correct
>> > (/etc/udev/rules.d/xen-backend.rules).
>>
>> Here is the content of the rules:
>>
>> # cat /etc/udev/rules.d/xen-backend.rules
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"tap*",
>> RUN+=3D"/etc/xen/scripts/blktap $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vbd*", RUN+=3D"/etc/xen/scrip=
ts/block
>> $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vtpm*", RUN+=3D"/etc/xen/scri=
pts/vtpm
>> $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif2-*",
>> RUN+=3D"/etc/xen/scripts/vif2 $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
>> RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
>> RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vscsi*",
>> RUN+=3D"/etc/xen/scripts/vscsi $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", ACTION=3D=3D"remove",
>> RUN+=3D"/etc/xen/scripts/xen-hotplug-cleanup"
>> KERNEL=3D=3D"evtchn", NAME=3D"xen/%k"
>> SUBSYSTEM=3D=3D"xen", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/%k", MODE=
=3D"0600"
>> SUBSYSTEM=3D=3D"blktap2", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/blktap=
-2/%k",
>> MODE=3D"0600"
>> KERNEL=3D=3D"blktap-control", NAME=3D"xen/blktap-2/control", MODE=3D"060=
0"
>> KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600"
>> KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600"
>> KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0600"
>> SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add",
>> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
>>
>> I guess the responsible lines are:
>>
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
>> RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
>> RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"
>>
>> So this is my testing:
>>
>> # cp -pvf /etc/xen/scripts/vif-setup /etc/xen/scripts/vif-setup.orig
>> # cat > /etc/xen/scripts/vif-setup <<'EOF'
>> #!/bin/bash
>> echo "$@" >> $0.log
>> /etc/xen/scripts/vif-setup.orig "$@"
>> EOF
>>
>> Now my testing purely on xm/xl trigger hvmdomain power.
>>
>> Online/Offline get called using xm but xl wise is Online get called
>> but not Offline with hvm domains like windows XP/server 2008r2... any
>> idea what else can make this behaviour difference between xl/xm?
>>
>> The /etc/xen/scripts/vif-setup.log as below.
>>
>> The below is using xl create hvmdomain and get logged:
>> online type_if=3Dvif
>> online type_if=3Dvif
>> add type_if=3Dtap
>> add type_if=3Dtap
>> When using xl trigger hvmdomain power... no log entry at all.
>
> Does xl trigger hvmdomain power do anything at all?
> Is the guest shutting down?

Yes, it does for both xm/xl.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:30:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuIj-0005Rp-3U; Fri, 10 Feb 2012 17:30:25 +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 1RvuIh-0005Rf-4u
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:30:23 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328894973!59651027!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31947 invoked from network); 10 Feb 2012 17:29:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:29:34 -0000
Received: by damc16 with SMTP id c16so19505675dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 09:30:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=sxA2/MPveedniHcm3jTu/Yhw/YNE1eUOVJosaxxusl8=;
	b=Upe7rF6ziQZGqLtLQMPSimF+EkIUYRVMAph5mAmqU1Di8JfAZnYwcgLR7gCDuiH2gv
	Am9y92gQwn5ilONN/ltewdrhWHrSxJTq5KTDELM4gNzxVN6yM79tkgnAOKKckp3BW9d+
	7+UhOxOTU147EfCU35r9rR46Zc6MoRbf33hTY=
MIME-Version: 1.0
Received: by 10.68.220.232 with SMTP id pz8mr18356703pbc.28.1328895016656;
	Fri, 10 Feb 2012 09:30:16 -0800 (PST)
Received: by 10.68.134.10 with HTTP; Fri, 10 Feb 2012 09:30:16 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202101716040.7456@kaball-desktop>
References: <CAEwRVpPn_7oqg6J5vh035qS-QOX96ArZiiAw0Y597pM9_0LnZg@mail.gmail.com>
	<alpine.DEB.2.00.1202101027070.7456@kaball-desktop>
	<CAEwRVpND8S55v5Knt3k6b9deWF2nnkT2Df7P0MJZJJWi13aGYQ@mail.gmail.com>
	<alpine.DEB.2.00.1202101716040.7456@kaball-desktop>
Date: Sat, 11 Feb 2012 01:30:16 +0800
Message-ID: <CAEwRVpMFUCMFJJb9um-yY3QjhenVPbJaAjdOZbOAE9aDXnueNw@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-4.1.3-rc1-pre changeset 23224:cccd6c68e1b9 hvm
 xl not execute vif-bridge when xl destroy hvmdomain or xl trigger hvmdomain
 power
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Feb 11, 2012 at 1:16 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 10 Feb 2012, Teck Choon Giam wrote:
>> Hi Stefano,
>>
>> On Fri, Feb 10, 2012 at 6:45 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 9 Feb 2012, Teck Choon Giam wrote:
>> >> Hi,
>> >>
>> >> I need to check whether is this intended? =A0When using xl create hvm
>> >> domains, it does execute vif-bridge script. =A0However, when doing xl
>> >> destroy or xl trigger hvmdomain power it doesn't execute vif-bridge
>> >> script. =A0I just did the following to test:
>> >>
>> >> # cp -pvf /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.orig
>> >> # cat > /etc/xen/scripts/vif-bridge <<'EOF'
>> >> #!/bin/bash
>> >> echo "$@" >> vif-bridge.log
>> >> /etc/xen/scripts/vif-bridge.orig "$@"
>> >> EOF
>> >>
>> >> When using xm and xl to create hvmdomain, I can see vif-bridge.log
>> >> appended with:
>> >>
>> >> online type_if=3Dvif
>> >> online type_if=3Dvif
>> >> add type_if=3Dtap
>> >> add type_if=3Dtap
>> >>
>> >> Since I have allocated 2 vifs (one for WAN and one for LAN)... so it
>> >> gets to execute vif-bridge once for each vif which looks right.
>> >>
>> >> Now the problem is xl trigger hvmdomain power and xl destroy power.
>> >> Both never call vif-bridge script as there isn't any such line like:
>> >>
>> >> offline type_if=3Dvif
>> >> offline type_if=3Dvif
>> >>
>> >> Whereby when I tried with xm trigger hvmdomain power, it does call
>> >> vif-bridge script as the above two lines get logged.
>> >>
>> >> This will leave the iptables FORWARD rule intact when using xl which I
>> >> reported before :(
>> >>
>> >> See http://www.gossamer-threads.com/lists/xen/devel/204990
>> >
>> > Actually I have just run the same test but I didn't see any issues:
>> > vif-bridge gets called correctly when the domain dies.
>> >
>> > It is difficult to tell what is going wrong in your case because
>> > vif-bridge is not called directly by XL (or Xend), it is called by
>> > vif-setup, that is called by udev when the vif network interface is
>> > destroyed.
>> > I suggest you check that your udev scripts are correct
>> > (/etc/udev/rules.d/xen-backend.rules).
>>
>> Here is the content of the rules:
>>
>> # cat /etc/udev/rules.d/xen-backend.rules
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"tap*",
>> RUN+=3D"/etc/xen/scripts/blktap $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vbd*", RUN+=3D"/etc/xen/scrip=
ts/block
>> $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vtpm*", RUN+=3D"/etc/xen/scri=
pts/vtpm
>> $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif2-*",
>> RUN+=3D"/etc/xen/scripts/vif2 $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
>> RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
>> RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vscsi*",
>> RUN+=3D"/etc/xen/scripts/vscsi $env{ACTION}"
>> SUBSYSTEM=3D=3D"xen-backend", ACTION=3D=3D"remove",
>> RUN+=3D"/etc/xen/scripts/xen-hotplug-cleanup"
>> KERNEL=3D=3D"evtchn", NAME=3D"xen/%k"
>> SUBSYSTEM=3D=3D"xen", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/%k", MODE=
=3D"0600"
>> SUBSYSTEM=3D=3D"blktap2", KERNEL=3D=3D"blktap[0-9]*", NAME=3D"xen/blktap=
-2/%k",
>> MODE=3D"0600"
>> KERNEL=3D=3D"blktap-control", NAME=3D"xen/blktap-2/control", MODE=3D"060=
0"
>> KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600"
>> KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600"
>> KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0600"
>> SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add",
>> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap"
>>
>> I guess the responsible lines are:
>>
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"online",
>> RUN+=3D"/etc/xen/scripts/vif-setup online type_if=3Dvif"
>> SUBSYSTEM=3D=3D"xen-backend", KERNEL=3D=3D"vif-*", ACTION=3D=3D"offline",
>> RUN+=3D"/etc/xen/scripts/vif-setup offline type_if=3Dvif"
>>
>> So this is my testing:
>>
>> # cp -pvf /etc/xen/scripts/vif-setup /etc/xen/scripts/vif-setup.orig
>> # cat > /etc/xen/scripts/vif-setup <<'EOF'
>> #!/bin/bash
>> echo "$@" >> $0.log
>> /etc/xen/scripts/vif-setup.orig "$@"
>> EOF
>>
>> Now my testing purely on xm/xl trigger hvmdomain power.
>>
>> Online/Offline get called using xm but xl wise is Online get called
>> but not Offline with hvm domains like windows XP/server 2008r2... any
>> idea what else can make this behaviour difference between xl/xm?
>>
>> The /etc/xen/scripts/vif-setup.log as below.
>>
>> The below is using xl create hvmdomain and get logged:
>> online type_if=3Dvif
>> online type_if=3Dvif
>> add type_if=3Dtap
>> add type_if=3Dtap
>> When using xl trigger hvmdomain power... no log entry at all.
>
> Does xl trigger hvmdomain power do anything at all?
> Is the guest shutting down?

Yes, it does for both xm/xl.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuKP-0005ZA-Jp; Fri, 10 Feb 2012 17:32:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvuKM-0005Yf-VS
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:32:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328895120!12874018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8047 invoked from network); 10 Feb 2012 17:32:01 -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;
	10 Feb 2012 17:32:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="10629098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:32:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:32:00 +0000
Date: Fri, 10 Feb 2012 17:35:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1328881672637-5472477.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Fantu wrote:
> I have try Precise PV on HVM with qemu upstream and spice but not work.
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b 
> 
> DomU xl configuration file:
> ----------------------------------------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,xvda,rw',
> '/dev/scd0,raw,xvdb,ro,cdrom']

You shouldn't use xvda/xvdb in HVM guests config file unless you want a
PV only disk, that is OK for a secondary disk but you are not going to
be able to boot from it.
So at least your primary disk should be hda.


> boot='c'
> xen_platform_pci=1
> device_model_version="qemu-xen"
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> stdvga=0
> sdl=0
> spice=1
> spicehost="0.0.0.0"
> spiceport=6000
> spicepasswd="test"
> ----------------------------------------------------------------
> 
> Without spice the domU starts but vnc is unusable and network doesn't work.

Those are quite a serious issues, what kind of guest is this?
I suggest you try to get network and vnc to work without spice before
proceeding any further.
I use upstream qemu with xen rather regularly and I haven't seen these
problems. Could you please post your qemu logs? Does the guest work
correctly with the old qemu?


> With spice it doesn't start:
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019bc70
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:636:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
> during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> And on log:
> qemu-system-i386: -spice
> port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on: there is no
> option group "spice"
> spice is not supported by this qemu build.
> 
> Is there something wrong on configuration file or are there some bugs?
> Thanks for any reply and sorry for bad english.

Your QEMU build doesn't support spice. You might have to compile
upstream QEMU yourself, passing the right option to configure to enable
spice.
The QEMU tree is cloned in tools/qemu-xen-dir by default, give a look at
tools/Makefile:subdir-all-qemu-xen-dir to see the configure options used
by the Xen build system.
Something like this should work:

./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$(XEN_ROOT)/tools/include -I$(XEN_ROOT)/tools/libxc -I$(XEN_ROOT)/tools/xenstore" --extra-ldflags="-L$(XEN_ROOT)/tools/libxc -L$(XEN_ROOT)/tools/xenstore" --disable-kvm --enable-spice

provided that you have all the dependencies to build qemu+spice on your
system and that XEN_ROOT points to the xen-unstable directory.
I have to warn you that spice requires lots of libraries in order to
compile succesfully, see:

http://people.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-qemu-kvm-spice/

Once you manage to do this, maybe you would like to volunteer to update
the wiki with more detailed instructions on how to compile and use SPICE
on Xen? ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuKP-0005ZA-Jp; Fri, 10 Feb 2012 17:32:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RvuKM-0005Yf-VS
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:32:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328895120!12874018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8047 invoked from network); 10 Feb 2012 17:32:01 -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;
	10 Feb 2012 17:32:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="10629098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:32:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 17:32:00 +0000
Date: Fri, 10 Feb 2012 17:35:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1328881672637-5472477.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Fantu wrote:
> I have try Precise PV on HVM with qemu upstream and spice but not work.
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b 
> 
> DomU xl configuration file:
> ----------------------------------------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,xvda,rw',
> '/dev/scd0,raw,xvdb,ro,cdrom']

You shouldn't use xvda/xvdb in HVM guests config file unless you want a
PV only disk, that is OK for a secondary disk but you are not going to
be able to boot from it.
So at least your primary disk should be hda.


> boot='c'
> xen_platform_pci=1
> device_model_version="qemu-xen"
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> stdvga=0
> sdl=0
> spice=1
> spicehost="0.0.0.0"
> spiceport=6000
> spicepasswd="test"
> ----------------------------------------------------------------
> 
> Without spice the domU starts but vnc is unusable and network doesn't work.

Those are quite a serious issues, what kind of guest is this?
I suggest you try to get network and vnc to work without spice before
proceeding any further.
I use upstream qemu with xen rather regularly and I haven't seen these
problems. Could you please post your qemu logs? Does the guest work
correctly with the old qemu?


> With spice it doesn't start:
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019bc70
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:636:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
> during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> And on log:
> qemu-system-i386: -spice
> port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on: there is no
> option group "spice"
> spice is not supported by this qemu build.
> 
> Is there something wrong on configuration file or are there some bugs?
> Thanks for any reply and sorry for bad english.

Your QEMU build doesn't support spice. You might have to compile
upstream QEMU yourself, passing the right option to configure to enable
spice.
The QEMU tree is cloned in tools/qemu-xen-dir by default, give a look at
tools/Makefile:subdir-all-qemu-xen-dir to see the configure options used
by the Xen build system.
Something like this should work:

./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$(XEN_ROOT)/tools/include -I$(XEN_ROOT)/tools/libxc -I$(XEN_ROOT)/tools/xenstore" --extra-ldflags="-L$(XEN_ROOT)/tools/libxc -L$(XEN_ROOT)/tools/xenstore" --disable-kvm --enable-spice

provided that you have all the dependencies to build qemu+spice on your
system and that XEN_ROOT points to the xen-unstable directory.
I have to warn you that spice requires lots of libraries in order to
compile succesfully, see:

http://people.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-qemu-kvm-spice/

Once you manage to do this, maybe you would like to volunteer to update
the wiki with more detailed instructions on how to compile and use SPICE
on Xen? ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:39:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuQt-0005o6-GA; Fri, 10 Feb 2012 17:38:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RvuQs-0005ny-K3
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:38:50 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328895523!7728852!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3630 invoked from network); 10 Feb 2012 17:38:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-174.messagelabs.com with SMTP;
	10 Feb 2012 17:38:43 -0000
Received: from p5b2e45df.dip.t-dialin.net ([91.46.69.223] 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 1RvuQk-0004BX-Qe; Fri, 10 Feb 2012 17:38:42 +0000
Message-ID: <4F355621.7050900@canonical.com>
Date: Fri, 10 Feb 2012 18:38:41 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F353B73.1050309@canonical.com>
	<1328889108.6133.272.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328889108.6133.272.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Content-Type: multipart/mixed; boundary="------------030707060905020705020305"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------030707060905020705020305
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10.02.2012 16:51, Ian Campbell wrote:
> On Fri, 2012-02-10 at 15:44 +0000, Stefan Bader wrote:
>> If I did not miss something, it looks to me like guests started with xl will use
>> the bridge specified in the guest config or xenbr0 as a default.
>> Just wondering whether adding a defaultbridge config option to xl.conf would be
>> considered a waste of time (because its not desired to have that) or some worth
>> of adding when I would come up with a patch?
> 
> Sounds useful enough to me.
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

So maybe the following is good. Hopefully not introduced any stupid typos while
moving it from the version where it was tested to HEAD.

-Stefan


>From d58ebda4fbe831b491d43a6988f3006b8f1a9825 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 10 Feb 2012 18:03:26 +0100
Subject: [PATCH] Add defaultbridge config option for xl.conf

Currently guests created with the xl stack will have "xenbr0"
written as their default into xenstore. It can be changed in
the individual guest config files, but there is no way to
have that default globally changed.

Add a config option to xl.conf that allows to have a different
default bridge name.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 docs/man/xl.conf.pod.5   |    6 ++++++
 tools/libxl/xl.c         |    4 ++++
 tools/libxl/xl.h         |    1 +
 tools/libxl/xl_cmdimpl.c |    5 +++++
 4 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8837eb1..85752fb 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -68,6 +68,12 @@ Configures the default hotplug script used by virtual network
devices.

 Default: C</etc/xen/scripts/vif-bridge>

+=item B<defaultbridge="NAME">
+
+Configures the default bridge to set for virtual network devices.
+
+Default: C<xenbr0>
+
 =item B<output_format="json|sxp">

 Configures the default output format used by xl when printing "machine
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9dac998..df9b1e7 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+char *default_bridge = NULL;
 enum output_format default_output_format = OUTPUT_FORMAT_JSON;

 static xentoollog_level minmsglevel = XTL_PROGRESS;
@@ -79,6 +80,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);

+    if (!xlu_cfg_get_string (config, "defaultbridge", &buf, 0))
+	default_bridge = strdup(buf);
+
     if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
         if (!strcmp(buf, "json"))
             default_output_format = OUTPUT_FORMAT_JSON;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index a852a43..702b208 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -110,6 +110,7 @@ extern int autoballoon;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
+extern char *default_bridge;

 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 61ca902..05d8ef3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -842,6 +842,11 @@ static void parse_config_data(const char
*configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }

+	    if (default_bridge) {
+		free(nic->bridge);
+		nic->bridge = strdup(default_bridge);
+	    }
+
             p = strtok(buf2, ",");
             if (!p)
                 goto skip;
-- 
1.7.5.4

--------------030707060905020705020305
Content-Type: text/x-diff;
 name="0001-Add-defaultbridge-config-option-for-xl.conf.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Add-defaultbridge-config-option-for-xl.conf.patch"

>From d58ebda4fbe831b491d43a6988f3006b8f1a9825 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 10 Feb 2012 18:03:26 +0100
Subject: [PATCH] Add defaultbridge config option for xl.conf

Currently guests created with the xl stack will have "xenbr0"
written as their default into xenstore. It can be changed in
the individual guest config files, but there is no way to
have that default globally changed.

Add a config option to xl.conf that allows to have a different
default bridge name.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 docs/man/xl.conf.pod.5   |    6 ++++++
 tools/libxl/xl.c         |    4 ++++
 tools/libxl/xl.h         |    1 +
 tools/libxl/xl_cmdimpl.c |    5 +++++
 4 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8837eb1..85752fb 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -68,6 +68,12 @@ Configures the default hotplug script used by virtual network devices.
 
 Default: C</etc/xen/scripts/vif-bridge>
 
+=item B<defaultbridge="NAME">
+
+Configures the default bridge to set for virtual network devices.
+
+Default: C<xenbr0>
+
 =item B<output_format="json|sxp">
 
 Configures the default output format used by xl when printing "machine
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9dac998..df9b1e7 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+char *default_bridge = NULL;
 enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 
 static xentoollog_level minmsglevel = XTL_PROGRESS;
@@ -79,6 +80,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
+    if (!xlu_cfg_get_string (config, "defaultbridge", &buf, 0))
+	default_bridge = strdup(buf);
+
     if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
         if (!strcmp(buf, "json"))
             default_output_format = OUTPUT_FORMAT_JSON;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index a852a43..702b208 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -110,6 +110,7 @@ extern int autoballoon;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
+extern char *default_bridge;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 61ca902..05d8ef3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -842,6 +842,11 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+	    if (default_bridge) {
+		free(nic->bridge);
+		nic->bridge = strdup(default_bridge);
+	    }
+
             p = strtok(buf2, ",");
             if (!p)
                 goto skip;
-- 
1.7.5.4


--------------030707060905020705020305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------030707060905020705020305--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:39:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuQt-0005o6-GA; Fri, 10 Feb 2012 17:38:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RvuQs-0005ny-K3
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:38:50 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328895523!7728852!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3630 invoked from network); 10 Feb 2012 17:38:43 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-174.messagelabs.com with SMTP;
	10 Feb 2012 17:38:43 -0000
Received: from p5b2e45df.dip.t-dialin.net ([91.46.69.223] 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 1RvuQk-0004BX-Qe; Fri, 10 Feb 2012 17:38:42 +0000
Message-ID: <4F355621.7050900@canonical.com>
Date: Fri, 10 Feb 2012 18:38:41 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F353B73.1050309@canonical.com>
	<1328889108.6133.272.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328889108.6133.272.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Content-Type: multipart/mixed; boundary="------------030707060905020705020305"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------030707060905020705020305
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10.02.2012 16:51, Ian Campbell wrote:
> On Fri, 2012-02-10 at 15:44 +0000, Stefan Bader wrote:
>> If I did not miss something, it looks to me like guests started with xl will use
>> the bridge specified in the guest config or xenbr0 as a default.
>> Just wondering whether adding a defaultbridge config option to xl.conf would be
>> considered a waste of time (because its not desired to have that) or some worth
>> of adding when I would come up with a patch?
> 
> Sounds useful enough to me.
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

So maybe the following is good. Hopefully not introduced any stupid typos while
moving it from the version where it was tested to HEAD.

-Stefan


>From d58ebda4fbe831b491d43a6988f3006b8f1a9825 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 10 Feb 2012 18:03:26 +0100
Subject: [PATCH] Add defaultbridge config option for xl.conf

Currently guests created with the xl stack will have "xenbr0"
written as their default into xenstore. It can be changed in
the individual guest config files, but there is no way to
have that default globally changed.

Add a config option to xl.conf that allows to have a different
default bridge name.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 docs/man/xl.conf.pod.5   |    6 ++++++
 tools/libxl/xl.c         |    4 ++++
 tools/libxl/xl.h         |    1 +
 tools/libxl/xl_cmdimpl.c |    5 +++++
 4 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8837eb1..85752fb 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -68,6 +68,12 @@ Configures the default hotplug script used by virtual network
devices.

 Default: C</etc/xen/scripts/vif-bridge>

+=item B<defaultbridge="NAME">
+
+Configures the default bridge to set for virtual network devices.
+
+Default: C<xenbr0>
+
 =item B<output_format="json|sxp">

 Configures the default output format used by xl when printing "machine
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9dac998..df9b1e7 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+char *default_bridge = NULL;
 enum output_format default_output_format = OUTPUT_FORMAT_JSON;

 static xentoollog_level minmsglevel = XTL_PROGRESS;
@@ -79,6 +80,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);

+    if (!xlu_cfg_get_string (config, "defaultbridge", &buf, 0))
+	default_bridge = strdup(buf);
+
     if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
         if (!strcmp(buf, "json"))
             default_output_format = OUTPUT_FORMAT_JSON;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index a852a43..702b208 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -110,6 +110,7 @@ extern int autoballoon;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
+extern char *default_bridge;

 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 61ca902..05d8ef3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -842,6 +842,11 @@ static void parse_config_data(const char
*configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }

+	    if (default_bridge) {
+		free(nic->bridge);
+		nic->bridge = strdup(default_bridge);
+	    }
+
             p = strtok(buf2, ",");
             if (!p)
                 goto skip;
-- 
1.7.5.4

--------------030707060905020705020305
Content-Type: text/x-diff;
 name="0001-Add-defaultbridge-config-option-for-xl.conf.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Add-defaultbridge-config-option-for-xl.conf.patch"

>From d58ebda4fbe831b491d43a6988f3006b8f1a9825 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 10 Feb 2012 18:03:26 +0100
Subject: [PATCH] Add defaultbridge config option for xl.conf

Currently guests created with the xl stack will have "xenbr0"
written as their default into xenstore. It can be changed in
the individual guest config files, but there is no way to
have that default globally changed.

Add a config option to xl.conf that allows to have a different
default bridge name.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 docs/man/xl.conf.pod.5   |    6 ++++++
 tools/libxl/xl.c         |    4 ++++
 tools/libxl/xl.h         |    1 +
 tools/libxl/xl_cmdimpl.c |    5 +++++
 4 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8837eb1..85752fb 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -68,6 +68,12 @@ Configures the default hotplug script used by virtual network devices.
 
 Default: C</etc/xen/scripts/vif-bridge>
 
+=item B<defaultbridge="NAME">
+
+Configures the default bridge to set for virtual network devices.
+
+Default: C<xenbr0>
+
 =item B<output_format="json|sxp">
 
 Configures the default output format used by xl when printing "machine
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9dac998..df9b1e7 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+char *default_bridge = NULL;
 enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 
 static xentoollog_level minmsglevel = XTL_PROGRESS;
@@ -79,6 +80,9 @@ static void parse_global_config(const char *configfile,
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
+    if (!xlu_cfg_get_string (config, "defaultbridge", &buf, 0))
+	default_bridge = strdup(buf);
+
     if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
         if (!strcmp(buf, "json"))
             default_output_format = OUTPUT_FORMAT_JSON;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index a852a43..702b208 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -110,6 +110,7 @@ extern int autoballoon;
 extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
+extern char *default_bridge;
 
 enum output_format {
     OUTPUT_FORMAT_JSON,
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 61ca902..05d8ef3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -842,6 +842,11 @@ static void parse_config_data(const char *configfile_filename_report,
                 nic->script = strdup(default_vifscript);
             }
 
+	    if (default_bridge) {
+		free(nic->bridge);
+		nic->bridge = strdup(default_bridge);
+	    }
+
             p = strtok(buf2, ",");
             if (!p)
                 goto skip;
-- 
1.7.5.4


--------------030707060905020705020305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------030707060905020705020305--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:39:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuR7-0005p2-Be; Fri, 10 Feb 2012 17:39:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RvuR5-0005oP-OV
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:39:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328895535!12892173!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4031 invoked from network); 10 Feb 2012 17:38:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325480400"; d="scan'208";a="21837314"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 12:38:55 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 10 Feb 2012
	12:38:55 -0500
Message-ID: <4F35562D.1010107@citrix.com>
Date: Fri, 10 Feb 2012 17:38:53 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
	<1328881958.6133.268.camel@zakaz.uk.xensource.com>
	<20120210165058.GH32107@ocelot.phlegethon.org>
In-Reply-To: <20120210165058.GH32107@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/12 16:50, Tim Deegan wrote:
> At 13:52 +0000 on 10 Feb (1328881958), Ian Campbell wrote:
>> On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
>>> On 10/02/12 13:35, Ian Campbell wrote:
>>>> On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
>>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>>
>>>>> Link a device tree blob (DTB) into the xen image.  This is loaded
>>>>> immediately after Xen and xen_start() is called with the correct
>>>>> address in atag_paddr.
>>>>
>>>> Is platform.dtb supposed to be included in this patch/series or is it
>>>> intended that I should supply it from somewhere? (in which case, how and
>>>> where etc).
>>>
>>> I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
>>>
>>> Would it be better build the DTB from source included in Xen?
>>
>> I guess that's what Linux has done but I don't know if we want to
>> replicate all that and keep syncing etc. On the flip side I suppose it's
>> currently only a single platform.
> 
> I think we should take it into our tree in some form, unless there's a
> way to automatically extract it from the dom0 kernel at boot.  It should
> be possible to recompile Xen without needing to configure and build a
> linux kernel.

I'm going to take the device trees out of the kernel and put them in a
separate repository.  The DTB can be built independantly of Xen and
Linux and easily hacked on for local changes (e.g., to change the
Xen/Linux command lines).

You will be able to specify the DTB to include in Xen by setting the DTB
make variable (either on the command line or in .config).

This sound ok?

> In theory this will eventually be provided by the bootloader or
> firmware, right?

Yes.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:39:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuR7-0005p2-Be; Fri, 10 Feb 2012 17:39:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RvuR5-0005oP-OV
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:39:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1328895535!12892173!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjA5MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4031 invoked from network); 10 Feb 2012 17:38:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 17:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325480400"; d="scan'208";a="21837314"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 12:38:55 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 10 Feb 2012
	12:38:55 -0500
Message-ID: <4F35562D.1010107@citrix.com>
Date: Fri, 10 Feb 2012 17:38:53 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
	<1328881958.6133.268.camel@zakaz.uk.xensource.com>
	<20120210165058.GH32107@ocelot.phlegethon.org>
In-Reply-To: <20120210165058.GH32107@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/12 16:50, Tim Deegan wrote:
> At 13:52 +0000 on 10 Feb (1328881958), Ian Campbell wrote:
>> On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
>>> On 10/02/12 13:35, Ian Campbell wrote:
>>>> On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
>>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>>
>>>>> Link a device tree blob (DTB) into the xen image.  This is loaded
>>>>> immediately after Xen and xen_start() is called with the correct
>>>>> address in atag_paddr.
>>>>
>>>> Is platform.dtb supposed to be included in this patch/series or is it
>>>> intended that I should supply it from somewhere? (in which case, how and
>>>> where etc).
>>>
>>> I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
>>>
>>> Would it be better build the DTB from source included in Xen?
>>
>> I guess that's what Linux has done but I don't know if we want to
>> replicate all that and keep syncing etc. On the flip side I suppose it's
>> currently only a single platform.
> 
> I think we should take it into our tree in some form, unless there's a
> way to automatically extract it from the dom0 kernel at boot.  It should
> be possible to recompile Xen without needing to configure and build a
> linux kernel.

I'm going to take the device trees out of the kernel and put them in a
separate repository.  The DTB can be built independantly of Xen and
Linux and easily hacked on for local changes (e.g., to change the
Xen/Linux command lines).

You will be able to specify the DTB to include in Xen by setting the DTB
make variable (either on the command line or in .config).

This sound ok?

> In theory this will eventually be provided by the bootloader or
> firmware, right?

Yes.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:47:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuYg-0006AY-Qu; Fri, 10 Feb 2012 17:46:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvuYe-0006AN-OU
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:46:52 +0000
Received: from [193.109.254.147:19473] by server-1.bemta-14.messagelabs.com id
	73/8E-21323-C08553F4; Fri, 10 Feb 2012 17:46:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328895960!52271661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14676 invoked from network); 10 Feb 2012 17:46:00 -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;
	10 Feb 2012 17:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="10629312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:46:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 17:46:51 +0000
Message-ID: <1328896010.6133.276.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 10 Feb 2012 17:46:50 +0000
In-Reply-To: <4F35562D.1010107@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
	<1328881958.6133.268.camel@zakaz.uk.xensource.com>
	<20120210165058.GH32107@ocelot.phlegethon.org>
	<4F35562D.1010107@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 17:38 +0000, David Vrabel wrote:
> On 10/02/12 16:50, Tim Deegan wrote:
> > At 13:52 +0000 on 10 Feb (1328881958), Ian Campbell wrote:
> >> On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
> >>> On 10/02/12 13:35, Ian Campbell wrote:
> >>>> On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> >>>>> From: David Vrabel <david.vrabel@citrix.com>
> >>>>>
> >>>>> Link a device tree blob (DTB) into the xen image.  This is loaded
> >>>>> immediately after Xen and xen_start() is called with the correct
> >>>>> address in atag_paddr.
> >>>>
> >>>> Is platform.dtb supposed to be included in this patch/series or is it
> >>>> intended that I should supply it from somewhere? (in which case, how and
> >>>> where etc).
> >>>
> >>> I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
> >>>
> >>> Would it be better build the DTB from source included in Xen?
> >>
> >> I guess that's what Linux has done but I don't know if we want to
> >> replicate all that and keep syncing etc. On the flip side I suppose it's
> >> currently only a single platform.
> > 
> > I think we should take it into our tree in some form, unless there's a
> > way to automatically extract it from the dom0 kernel at boot.  It should
> > be possible to recompile Xen without needing to configure and build a
> > linux kernel.
> 
> I'm going to take the device trees out of the kernel and put them in a
> separate repository.  The DTB can be built independantly of Xen and
> Linux and easily hacked on for local changes (e.g., to change the
> Xen/Linux command lines).
> 
> You will be able to specify the DTB to include in Xen by setting the DTB
> make variable (either on the command line or in .config).

I'm happy with having just the .config option in the hypervisor for the
time being until we see how the chips land WRT bootloader adoption of
device tree etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 17:47:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 17:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvuYg-0006AY-Qu; Fri, 10 Feb 2012 17:46:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RvuYe-0006AN-OU
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 17:46:52 +0000
Received: from [193.109.254.147:19473] by server-1.bemta-14.messagelabs.com id
	73/8E-21323-C08553F4; Fri, 10 Feb 2012 17:46:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328895960!52271661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTEyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14676 invoked from network); 10 Feb 2012 17:46:00 -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;
	10 Feb 2012 17:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="10629312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 17:46:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 10 Feb 2012 17:46:51 +0000
Message-ID: <1328896010.6133.276.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 10 Feb 2012 17:46:50 +0000
In-Reply-To: <4F35562D.1010107@citrix.com>
References: <1328879024-5621-1-git-send-email-david.vrabel@citrix.com>
	<1328879024-5621-5-git-send-email-david.vrabel@citrix.com>
	<1328880943.6133.264.camel@zakaz.uk.xensource.com>
	<4F351E65.6020604@citrix.com>
	<1328881958.6133.268.camel@zakaz.uk.xensource.com>
	<20120210165058.GH32107@ocelot.phlegethon.org>
	<4F35562D.1010107@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 17:38 +0000, David Vrabel wrote:
> On 10/02/12 16:50, Tim Deegan wrote:
> > At 13:52 +0000 on 10 Feb (1328881958), Ian Campbell wrote:
> >> On Fri, 2012-02-10 at 13:40 +0000, David Vrabel wrote:
> >>> On 10/02/12 13:35, Ian Campbell wrote:
> >>>> On Fri, 2012-02-10 at 13:03 +0000, David Vrabel wrote:
> >>>>> From: David Vrabel <david.vrabel@citrix.com>
> >>>>>
> >>>>> Link a device tree blob (DTB) into the xen image.  This is loaded
> >>>>> immediately after Xen and xen_start() is called with the correct
> >>>>> address in atag_paddr.
> >>>>
> >>>> Is platform.dtb supposed to be included in this patch/series or is it
> >>>> intended that I should supply it from somewhere? (in which case, how and
> >>>> where etc).
> >>>
> >>> I make a symlink to vexpress-v2p-aem-v7a.dtb built in my Linux tree.
> >>>
> >>> Would it be better build the DTB from source included in Xen?
> >>
> >> I guess that's what Linux has done but I don't know if we want to
> >> replicate all that and keep syncing etc. On the flip side I suppose it's
> >> currently only a single platform.
> > 
> > I think we should take it into our tree in some form, unless there's a
> > way to automatically extract it from the dom0 kernel at boot.  It should
> > be possible to recompile Xen without needing to configure and build a
> > linux kernel.
> 
> I'm going to take the device trees out of the kernel and put them in a
> separate repository.  The DTB can be built independantly of Xen and
> Linux and easily hacked on for local changes (e.g., to change the
> Xen/Linux command lines).
> 
> You will be able to specify the DTB to include in Xen by setting the DTB
> make variable (either on the command line or in .config).

I'm happy with having just the .config option in the hypervisor for the
time being until we see how the chips land WRT bootloader adoption of
device tree etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 18:06:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 18: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.xensource.com>)
	id 1Rvur4-0006Zf-99; Fri, 10 Feb 2012 18:05:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvur3-0006ZW-CQ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 18:05:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328897146!14065187!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTczOTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9374 invoked from network); 10 Feb 2012 18:05:46 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 18:05:46 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 1D92A714070;
	Fri, 10 Feb 2012 10:05:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=g7xMZkLh/lePVthjKAxS9U7xlgNUcIrJYsUFdEJMsD5c
	OFnNqlGD3HONHujGHsLqwwI4LfW3gwjwx3zcXRiW5YL7BinPa8+fMnpuL7WWY2vt
	k9lZVw+zAnpJ/KkEmXr2TUSqUPuL5HodzNTFw6rI9MSkFVF2s6BPfJSP5Ycec1g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=WguMaKgTufZCApiCbvEX0iCPmAg=; b=A+xWDi2X
	8t006xtd/lZziw0vQuS8Jipux4Y4QDplPBH4iv1SJE8q6KvBH90dPsybTTZ5AF55
	ZdooEvS3jBd08T7AjVxtxXzjMtTBYFdaBCa/dFB/xPtHc27e0G4igqtKKYQZmMc7
	UJcwbyzj2gxd7zKSv0PuJz/6/csv079uMOM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 3554C71406A; 
	Fri, 10 Feb 2012 10:05:45 -0800 (PST)
Received: from 69.165.142.248 (proxying for 69.165.142.248)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 10:05:46 -0800
Message-ID: <c23b61090ff73461c9dd407b936ede74.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202133459.GP48883@ocelot.phlegethon.org>
References: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
	<20120202133459.GP48883@ocelot.phlegethon.org>
Date: Fri, 10 Feb 2012 10:05:46 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] Domain relinquish resources racing with p2m access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 12:49 -0800 on 01 Feb (1328100564), Andres Lagar-Cavilla wrote:
>> So we've run into this interesting (race?) condition while doing
>> stress-testing. We pummel the domain with paging, sharing and mmap
>> operations from dom0, and concurrently we launch a domain destruction.
>> Often we get in the logs something along these lines
>>
>> (XEN) mm.c:958:d0 Error getting mfn 859b1a (pfn ffffffffffffffff) from
>> L1
>> entry 8000000859b1a625 for l1e_owner=0, pg_owner=1
>>
>> We're using the synchronized p2m patches just posted, so my analysis is
>> as
>> follows:
>>
>> - the domain destroy domctl kicks in. It calls relinquish resources.
>> This
>> disowns and puts most domain pages, resulting in invalid (0xff...ff) m2p
>> entries
>>
>> - In parallel, a do_mmu_update is making progress, it has no issues
>> performing a p2m lookup because the p2m has not been torn down yet; we
>> haven't gotten to the RCU callback. Eventually, the mapping fails in
>> page_get_owner in get_pafe_from_l1e.
>>
>> The map is failed, as expected, but what makes me uneasy is the fact
>> that
>> there is a still active p2m lurking around, with seemingly valid
>> translations to valid mfn's, while all the domain pages are gone.
>
> Yes.  That's OK as long as we know that any user of that page will
> fail, but I'm not sure that we do.
>
> At one point we talked about get_gfn() taking a refcount on the
> underlying MFN, which would fix this more cleanly.  ISTR the problem was
> how to make sure the refcount was moved when the gfn->mfn mapping
> changed.

Oh, I ditched that because it's too hairy and error prone. There are
plenty of nested get_gfn's with the n>1 call changing the mfn. So unless
we make a point of remembering the mfn at the point of get_gfn, it's just
impossible to make this work. And then "remembering the mfn" means a
serious uglification of existing code.

>
> Can you stick a WARN() in mm.c to get the actual path that leads to the
> failure?

As a debug aid or as actual code to make it into the tree? This typically
happens in batches of a few dozens, so a WARN is going to massively spam
the console with stack traces. Guess how I found out ...

The moral is that the code is reasonably defensive, so this gets caught,
albeit in a rather verbose way. But this might eventually bite someone who
does a get_gfn and doesn't either check that the domain is dying or ensure
that a get_page succeeds.

Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 18:06:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 18: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.xensource.com>)
	id 1Rvur4-0006Zf-99; Fri, 10 Feb 2012 18:05:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvur3-0006ZW-CQ
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 18:05:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328897146!14065187!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTczOTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9374 invoked from network); 10 Feb 2012 18:05:46 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 18:05:46 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 1D92A714070;
	Fri, 10 Feb 2012 10:05:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=g7xMZkLh/lePVthjKAxS9U7xlgNUcIrJYsUFdEJMsD5c
	OFnNqlGD3HONHujGHsLqwwI4LfW3gwjwx3zcXRiW5YL7BinPa8+fMnpuL7WWY2vt
	k9lZVw+zAnpJ/KkEmXr2TUSqUPuL5HodzNTFw6rI9MSkFVF2s6BPfJSP5Ycec1g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=WguMaKgTufZCApiCbvEX0iCPmAg=; b=A+xWDi2X
	8t006xtd/lZziw0vQuS8Jipux4Y4QDplPBH4iv1SJE8q6KvBH90dPsybTTZ5AF55
	ZdooEvS3jBd08T7AjVxtxXzjMtTBYFdaBCa/dFB/xPtHc27e0G4igqtKKYQZmMc7
	UJcwbyzj2gxd7zKSv0PuJz/6/csv079uMOM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 3554C71406A; 
	Fri, 10 Feb 2012 10:05:45 -0800 (PST)
Received: from 69.165.142.248 (proxying for 69.165.142.248)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 10:05:46 -0800
Message-ID: <c23b61090ff73461c9dd407b936ede74.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120202133459.GP48883@ocelot.phlegethon.org>
References: <0642c1aa7bb490b322c1a5c7d12ebb54.squirrel@webmail.lagarcavilla.org>
	<20120202133459.GP48883@ocelot.phlegethon.org>
Date: Fri, 10 Feb 2012 10:05:46 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] Domain relinquish resources racing with p2m access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 12:49 -0800 on 01 Feb (1328100564), Andres Lagar-Cavilla wrote:
>> So we've run into this interesting (race?) condition while doing
>> stress-testing. We pummel the domain with paging, sharing and mmap
>> operations from dom0, and concurrently we launch a domain destruction.
>> Often we get in the logs something along these lines
>>
>> (XEN) mm.c:958:d0 Error getting mfn 859b1a (pfn ffffffffffffffff) from
>> L1
>> entry 8000000859b1a625 for l1e_owner=0, pg_owner=1
>>
>> We're using the synchronized p2m patches just posted, so my analysis is
>> as
>> follows:
>>
>> - the domain destroy domctl kicks in. It calls relinquish resources.
>> This
>> disowns and puts most domain pages, resulting in invalid (0xff...ff) m2p
>> entries
>>
>> - In parallel, a do_mmu_update is making progress, it has no issues
>> performing a p2m lookup because the p2m has not been torn down yet; we
>> haven't gotten to the RCU callback. Eventually, the mapping fails in
>> page_get_owner in get_pafe_from_l1e.
>>
>> The map is failed, as expected, but what makes me uneasy is the fact
>> that
>> there is a still active p2m lurking around, with seemingly valid
>> translations to valid mfn's, while all the domain pages are gone.
>
> Yes.  That's OK as long as we know that any user of that page will
> fail, but I'm not sure that we do.
>
> At one point we talked about get_gfn() taking a refcount on the
> underlying MFN, which would fix this more cleanly.  ISTR the problem was
> how to make sure the refcount was moved when the gfn->mfn mapping
> changed.

Oh, I ditched that because it's too hairy and error prone. There are
plenty of nested get_gfn's with the n>1 call changing the mfn. So unless
we make a point of remembering the mfn at the point of get_gfn, it's just
impossible to make this work. And then "remembering the mfn" means a
serious uglification of existing code.

>
> Can you stick a WARN() in mm.c to get the actual path that leads to the
> failure?

As a debug aid or as actual code to make it into the tree? This typically
happens in batches of a few dozens, so a WARN is going to massively spam
the console with stack traces. Guess how I found out ...

The moral is that the code is reasonably defensive, so this gets caught,
albeit in a rather verbose way. But this might eventually bite someone who
does a get_gfn and doesn't either check that the domain is dying or ensure
that a get_page succeeds.

Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 18:14:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 18:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvuyk-0006oY-Mu; Fri, 10 Feb 2012 18:13:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvuyi-0006oQ-1K
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 18:13:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328897562!60620140!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19752 invoked from network); 10 Feb 2012 18:12:42 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-2.tower-27.messagelabs.com with SMTP;
	10 Feb 2012 18:12:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id F22197EC072;
	Fri, 10 Feb 2012 10:13:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ssX5oklkvyJf+PXJZSm9SwcfvYtvWaERKPupRQgO8mOm
	JYus43LmooqMUL7HhrQ1iZG9ljDMQhcpilvSLEpO0beJrWENbGSvl6030AV/WODa
	df78tx5XJedu9rMjCnkqvcx4gNsJ2B5Sq3JEIf5R5SbGPpFBBhLN+VzKJ7K5bBo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SVzCIHyhx/SQ3OoFS5QaXtoMtTo=; b=EfWdET9z
	w6ZoBhmbPZKhip81HYtwYd+Mz6eUZv/vRjS0zyUl9NZAltwiaCvEbx2/EyEJHjYp
	eC99fFWy27oN41cHLhMZK6hvK1lESEHNNfhM8k0sgOOm/6gV3uq2UX6SaIDUxUUI
	dL4o8AU/PZ1syfzG7mCHlTQ8wpPOSzVpOnk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 515407EC060; 
	Fri, 10 Feb 2012 10:13:44 -0800 (PST)
Received: from 69.165.142.248 (proxying for 69.165.142.248)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 10:13:44 -0800
Message-ID: <59a249b9f97604d7cb364b8edc38c6bf.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120210161357.GF32107@ocelot.phlegethon.org>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<20120210161357.GF32107@ocelot.phlegethon.org>
Date: Fri, 10 Feb 2012 10:13:44 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 01:08 -0500 on 09 Feb (1328749705), Andres Lagar-Cavilla wrote:
>> i(Was switch from domctl to memops)
>> Changes from v1 posted Feb 2nd 2012
>>
>> - Patches 1 & 2 Acked-by Tim Deegan on the hypervisor side
>> - Added patch 3 to clean up the enable domctl interface, based on
>>   discussion with Ian Campbell
>>
>> Description from original post follows:
>>
>> Per page operations in the paging, sharing, and access tracking
>> subsystems are
>> all implemented with domctls (e.g. a domctl to evict one page, or to
>> share one
>> page).
>>
>> Under heavy load, the domctl path reveals a lack of scalability. The
>> domctl
>> lock serializes dom0's vcpus in the hypervisor. When performing
>> thousands of
>> per-page operations on dozens of domains, these vcpus will spin in the
>> hypervisor. Beyond the aggressive locking, an added inefficiency of
>> blocking
>> vcpus in the domctl lock is that dom0 is prevented from re-scheduling
>> any of
>> its other work-starved processes.
>>
>> We retain the domctl interface for setting up and tearing down
>> paging/sharing/mem access for a domain. But we migrate all the per page
>> operations to use the memory_op hypercalls (e.g XENMEM_*).
>>
>> This is a backwards-incompatible ABI change. It's been floating on the
>> list for
>> a couple weeks now, with no nacks thus far.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
> Applied 1 and 2; thanks.
>
> I'll leave patch 3 for others to comment -- I know there are out-of-tree
> users of the mem-access interface, and changing the hypercalls is less
> disruptive than changing the libxc interface.

Makes a lot of sense. Thanks.

I don't view this change as sine qua-non, yet, "it would be nice if"...

Is there a timeout mechanism if out-of-tree consumers are not on the ball?

Actually, this hiatus allows me to float a perhaps cleaner way to map the
ring: the known problem is that the pager may die abruptly, and Xen is
still posting events to a page now belonging to some other dom0 process.
This is dealt with in the qemu-dm case by stuffing the ring in an unused
pfn (presumably somewhere in the mmio hole?)

Would that work? Is there a policy for parceling out these "magic pfn's"?

Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 18:14:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 18:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvuyk-0006oY-Mu; Fri, 10 Feb 2012 18:13:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvuyi-0006oQ-1K
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 18:13:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328897562!60620140!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19752 invoked from network); 10 Feb 2012 18:12:42 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-2.tower-27.messagelabs.com with SMTP;
	10 Feb 2012 18:12:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id F22197EC072;
	Fri, 10 Feb 2012 10:13:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ssX5oklkvyJf+PXJZSm9SwcfvYtvWaERKPupRQgO8mOm
	JYus43LmooqMUL7HhrQ1iZG9ljDMQhcpilvSLEpO0beJrWENbGSvl6030AV/WODa
	df78tx5XJedu9rMjCnkqvcx4gNsJ2B5Sq3JEIf5R5SbGPpFBBhLN+VzKJ7K5bBo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SVzCIHyhx/SQ3OoFS5QaXtoMtTo=; b=EfWdET9z
	w6ZoBhmbPZKhip81HYtwYd+Mz6eUZv/vRjS0zyUl9NZAltwiaCvEbx2/EyEJHjYp
	eC99fFWy27oN41cHLhMZK6hvK1lESEHNNfhM8k0sgOOm/6gV3uq2UX6SaIDUxUUI
	dL4o8AU/PZ1syfzG7mCHlTQ8wpPOSzVpOnk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 515407EC060; 
	Fri, 10 Feb 2012 10:13:44 -0800 (PST)
Received: from 69.165.142.248 (proxying for 69.165.142.248)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 10:13:44 -0800
Message-ID: <59a249b9f97604d7cb364b8edc38c6bf.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120210161357.GF32107@ocelot.phlegethon.org>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<20120210161357.GF32107@ocelot.phlegethon.org>
Date: Fri, 10 Feb 2012 10:13:44 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 01:08 -0500 on 09 Feb (1328749705), Andres Lagar-Cavilla wrote:
>> i(Was switch from domctl to memops)
>> Changes from v1 posted Feb 2nd 2012
>>
>> - Patches 1 & 2 Acked-by Tim Deegan on the hypervisor side
>> - Added patch 3 to clean up the enable domctl interface, based on
>>   discussion with Ian Campbell
>>
>> Description from original post follows:
>>
>> Per page operations in the paging, sharing, and access tracking
>> subsystems are
>> all implemented with domctls (e.g. a domctl to evict one page, or to
>> share one
>> page).
>>
>> Under heavy load, the domctl path reveals a lack of scalability. The
>> domctl
>> lock serializes dom0's vcpus in the hypervisor. When performing
>> thousands of
>> per-page operations on dozens of domains, these vcpus will spin in the
>> hypervisor. Beyond the aggressive locking, an added inefficiency of
>> blocking
>> vcpus in the domctl lock is that dom0 is prevented from re-scheduling
>> any of
>> its other work-starved processes.
>>
>> We retain the domctl interface for setting up and tearing down
>> paging/sharing/mem access for a domain. But we migrate all the per page
>> operations to use the memory_op hypercalls (e.g XENMEM_*).
>>
>> This is a backwards-incompatible ABI change. It's been floating on the
>> list for
>> a couple weeks now, with no nacks thus far.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
> Applied 1 and 2; thanks.
>
> I'll leave patch 3 for others to comment -- I know there are out-of-tree
> users of the mem-access interface, and changing the hypercalls is less
> disruptive than changing the libxc interface.

Makes a lot of sense. Thanks.

I don't view this change as sine qua-non, yet, "it would be nice if"...

Is there a timeout mechanism if out-of-tree consumers are not on the ball?

Actually, this hiatus allows me to float a perhaps cleaner way to map the
ring: the known problem is that the pager may die abruptly, and Xen is
still posting events to a page now belonging to some other dom0 process.
This is dealt with in the qemu-dm case by stuffing the ring in an unused
pfn (presumably somewhere in the mmio hole?)

Would that work? Is there a policy for parceling out these "magic pfn's"?

Andres

>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 19:02:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 19:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvvjd-0007qk-61; Fri, 10 Feb 2012 19:02:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dimitrios.melissovas@epfl.ch>) id 1Rvvjc-0007qZ-0g
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 19:02:16 +0000
X-Env-Sender: dimitrios.melissovas@epfl.ch
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328900528!10980511!1
X-Originating-IP: [128.178.224.219]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_00_10,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3367 invoked from network); 10 Feb 2012 19:02:08 -0000
Received: from smtp0.epfl.ch (HELO smtp0.epfl.ch) (128.178.224.219)
	by server-8.tower-21.messagelabs.com with SMTP;
	10 Feb 2012 19:02:08 -0000
Received: (qmail 5865 invoked by uid 107); 10 Feb 2012 19:02:06 -0000
X-Virus-Scanned: ClamAV
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43) (authenticated)
	by smtp0.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPA;
	Fri, 10 Feb 2012 20:02:06 +0100
Received: by yhkk6 with SMTP id k6so41595954yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 11:02:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.184.168 with SMTP id ev8mr13351362igc.29.1328900523799;
	Fri, 10 Feb 2012 11:02:03 -0800 (PST)
Received: by 10.182.51.225 with HTTP; Fri, 10 Feb 2012 11:02:03 -0800 (PST)
Date: Fri, 10 Feb 2012 20:02:03 +0100
Message-ID: <CAMnSOvBNKQMAEGyovbsKXJViZbUQ7oN-LK1syp-YSH6apjW+aw@mail.gmail.com>
From: Dimitrios Melissovas <dimitrios.melissovas@epfl.ch>
To: xen-devel@lists.xensource.com
Cc: rshriram@cs.ubc.ca
Subject: [Xen-devel] Remus: Possible disk replication consistency bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6233444660754342065=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6233444660754342065==
Content-Type: multipart/alternative; boundary=14dae9340449a9b39304b8a0c391

--14dae9340449a9b39304b8a0c391
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

Short version:

1. Is there any way to get disk replication to work with the blktap2 driver
when I use two file disk images (say, a disk image and a swap image).

2. [Possible bug] How does Remus guarantee that when, after failover, a
replicated VM boots at the backup physical machine, its memory state is
going to be consistent with its disk state? Remus uses two separate
channels, one for memory updates, and the other for disk updates. The
primary decides when to send individual commit messages to each of these
channels, but there appears to be no mechanism in place at the backup site
to coordinate if and when these updates should be applied. Thus, we have
the following execution scenario:

- Backup receives commit for disk updates for epoch E
- Primary crashes before sending commit for memory updates for epoch E
- Backup resumes the execution of the guest VM using the latest available
information
- The guest VM's memory state corresponds to epoch E - 1 and its disk state
- corresponds to epoch E. This is inconsistent.

Long version:

1.

In the simplified version of what I need, I have a single guest VM that has
access to two disk images, disk.img and swap.img, which are both replicated
using the blktap2 driver.

In order to achieve this, I used the following guide,
http://remusha.wikidot.com/ , which nets me the following setup
configuration (I deviated a little when creating the guest):

- Xen 4.2 (unstable), changeset (changeset version 24465:5b2676ac1321)
- Dom0 kernel: Linux v2.6.32.40 x86_64 (commit version
2b494f184d3337d10d59226e3632af56ea66629a)
- DomU kernel: Linux 3.0.4 x86_64

I have a guest VM, named frank, whose configuration file, frank.cfg,
contains the following parameters:

disk = [
'tap2:remus:nslrack83.epfl.ch:9002
|aio:/vserver/images/domains/frank/disk.img,xvda2,w',
'tap2:remus:nslrack83.epfl.ch:9003
|aio:/vserver/images/domains/frank/swap.img,xvda1,w',
]

which is correct, according to the documentation guidelines posted on
http://nss.cs.ubc.ca/remus/doc.html . Notice that I have assigned
a different tapdisk remote server channel to disk.img and swap.img

Assigning the same port number to both of them will not work, since both
the primary and the backup physical machines spawn one tapdisk daemon each
per disk image. I suppose that both daemons on the backup will try to bind
the same port number and, thus, one of them will fail. This causes the
procedure to hang. (In fact, the affected tapdisk instances on the primary
and backup will enter some kind of busy polling function and will consume
100% of the CPU assigned to them).

For whatever reason, however, things are not much different at all when I
assign different ports for replicating disk.img and swap.img. This is
something that I cannot explain, myself, and that is where I ultimately
gave up on trying to get disk replication working with blktap2.

Note that if we were to disable access to swap.img in frank.cfg, then the
whole process works as it should, disk, memory replication & all, which
demonstrates that I have a working setup among my physical machines.

2.

In the meantime, I have also been digging into the source code of Remus,
blktap2 and some parts of drbd, and I think I may have come across a
possible bug. If my observations are correct, then, it is possible that
after a (very unlucky) primary machine failure, the replicated VM is
resumed on the backup machine where its memory is in epoch A state and its
disk is in epoch B state.

- If we are using blktap2, then it can be that A = B + 1 (the disk state is
one epoch behind than the memory state) or A = B - 1 (the disk state is one
epoch ahead of the memory state)
- If we are using drbd, then it can be that A = B - 1 (the disk state is
one epoch ahead the memory state)

Remus is using two different channels of communication, one for memory
updates and one for disk updates. If I understand the code structure
correctly, the issue I describe stems from the fact that Remus is also
using these channels to send two separate commit messages; one to the
xc_restore process, for memory, and one to the server tapdisk2 daemon
(similar for drbd) for disk updates.

These messages are needed in order to trace the boundaries of checkpoint
epochs for each channel. However, what I feel that is missing (or I haven't
been able to find it) is a process on the backup machine side that decides
when the local VM state (memory or disk) gets updated. For example, the
backup should update the state of a VM to epoch A iff we have received all
updates pertaining to epoch A (disk and memory). Then, and only then, can
the backup send a Checkpoint Acknowledgement message to the primary, at
which point the primary can release the VM's network buffers.

The files of interest to us are the following:
xen-unstable/tools/libxc/xc_domain_save.c
xen-unstable/tools/remus/remus
xen-unstable/tools/python/xen/remus/device.py
xen-unstable/tools/blktap2/drivers/block-remus.c

- assuming that we are using disk replication with blktap2

Assume that the primary machine is about to send a commit message to the
backup machine. Thus, we are at line 1982 in the xc_domain_save.c file. The
primary is about to execute the discard_file_cache() function which, as a
consequence, causes the primary to do an fsync() on the migration socket.

I am not sure about the particular mechanics involved in calling fsync() on
a connected TCP socket, but I presume that the intended behaviour is to
wait until the last byte written in that socket is acknowledged by the
receiver (violates the end to end argument, but works in the general case
where you have two machines connected back to back with a crossover cable).

Then, the primary invokes the checkpoint callback, which brings us to the
commit() function at line 166 in remus. This function invokes the
buf.commit() command for each of the available buffers. For network
buffers, this causes them to release their output, whereas for disk
buffers, this causes remus to wait for an acknowledgement response for that
particular disk from the backup, as seen in device.py. Since disk buffers
have been inserted first, remus waits for acknowledgements for all disk
buffers before it release any network buffer.

Notice that at line 89 in function postsuspend() in device.py, remus sends
a 'flush' message to the disk control channel, which is all it takes for
the secondary machine to release the pending disk updates to its disk state
(block-remus.c).

The bug described can occur if the primary crashes after invoking the
discard_file_cache() command in xc_domain_save.c and before having a chance
to invoke any of the buf.commit() commands in remus. If the 'flush' message
has not left the primary's socket buffer yet, at the time of the crash,
then we have the A = B + 1 case outlined above, where the memory state is
one epoch ahead of the disk state. Similarly, if the primary crashes after
sending the 'flush' message but before calling the discard_file_cache()
command, we have the A = B - 1 case, where the VM's memory state is one
epoch behind the VM's disk state.

What's even more worrying, however, is that block-remus.c and
xc_domain_save.c have two entirely disjoint heartbeat mechanisms, which can
potentially amount to an entirely new level of trouble

- assuming that we use drbd

The setup is similar to the one described for blktap2. In this case,
however, remus forces the primary to wait in the preresume() callback until
it has received an acknowledgement for the disk updates. Unless I am
missing something, this makes little sense to me, as we are keeping the VM
suspended for a roundtrip time's worth of time, whereas it could have been
running. Shouldn't the waiting logic be moved to the commit() function
instead?

In any case, we have a similar scenario. drbd finishes sending the commit
message to the backup VM and the primary crashes immediately, before
returning from the postcopy callback. Thus, the backup machine receives a
commit for the disk updates but no commit for the memory updates. Since the
two do not coordinate with each other, it will happily apply the disk
updates and ruin memory-disk consistency on the guest VM.

- Epilogue

I think it would be better/cleaner/more consistent to have some kind of
remus server daemon running on the backup physical machine. That daemon
would coordinate when disk and memory are to be committed to the guest VM's
state (when that demon has received all checkpoint state pertaining to a
particular VM that is). As such, it is the daemon that should decide when
to send a Checkpoint Acknowledgement message to the primary physical
machine.

Cheers!
dmelisso

--14dae9340449a9b39304b8a0c391
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings,<br><br>Short version:<br><br>1. Is there any way to get disk rep=
lication to work with the blktap2 driver<br>when I use two file disk images=
 (say, a disk image and a swap image).<br><br>2. [Possible bug] How does Re=
mus guarantee that when, after failover, a<br>
replicated VM boots at the backup physical machine, its memory state is<br>=
going to be consistent with its disk state? Remus uses two separate<br>chan=
nels, one for memory updates, and the other for disk updates. The<br>primar=
y decides when to send individual commit messages to each of these<br>
channels, but there appears to be no mechanism in place at the backup site<=
br>to coordinate if and when these updates should be applied. Thus, we have=
<br>the following execution scenario:<br><br>- Backup receives commit for d=
isk updates for epoch E<br>
- Primary crashes before sending commit for memory updates for epoch E<br>-=
 Backup resumes the execution of the guest VM using the latest available in=
formation<br>- The guest VM&#39;s memory state corresponds to epoch E - 1 a=
nd its disk state<br>
- corresponds to epoch E. This is inconsistent.<br><br>Long version:<br><br=
>1.<br><br>In the simplified version of what I need, I have a single guest =
VM that has<br>access to two disk images, disk.img and swap.img, which are =
both replicated<br>
using the blktap2 driver.<br><br>In order to achieve this, I used the follo=
wing guide,<br><a href=3D"http://remusha.wikidot.com/">http://remusha.wikid=
ot.com/</a> , which nets me the following setup<br>configuration (I deviate=
d a little when creating the guest):<br>
<br>- Xen 4.2 (unstable), changeset (changeset version 24465:5b2676ac1321)<=
br>- Dom0 kernel: Linux v2.6.32.40 x86_64 (commit version 2b494f184d3337d10=
d59226e3632af56ea66629a)<br>- DomU kernel: Linux 3.0.4 x86_64<br><br>I have=
 a guest VM, named frank, whose configuration file, frank.cfg,<br>
contains the following parameters:<br><br>disk =3D [<br>&#39;tap2:remus:nsl=
rack83.epfl.ch:9002|aio:/vserver/images/domains/frank/disk.img,xvda2,w&#39;=
,<br>&#39;tap2:remus:nslrack83.epfl.ch:9003|aio:/vserver/images/domains/fra=
nk/swap.img,xvda1,w&#39;,<br>
]<br><br>which is correct, according to the documentation guidelines posted=
 on<br><a href=3D"http://nss.cs.ubc.ca/remus/doc.html">http://nss.cs.ubc.ca=
/remus/doc.html</a> . Notice that I have assigned<br>a different tapdisk re=
mote server channel to disk.img and swap.img<br>
<br>Assigning the same port number to both of them will not work, since bot=
h<br>the primary and the backup physical machines spawn one tapdisk daemon =
each<br>per disk image. I suppose that both daemons on the backup will try =
to bind<br>
the same port number and, thus, one of them will fail. This causes the<br>p=
rocedure to hang. (In fact, the affected tapdisk instances on the primary<b=
r>and backup will enter some kind of busy polling function and will consume=
<br>
100% of the CPU assigned to them).<br><br>For whatever reason, however, thi=
ngs are not much different at all when I<br>assign different ports for repl=
icating disk.img and swap.img. This is<br>something that I cannot explain, =
myself, and that is where I ultimately<br>
gave up on trying to get disk replication working with blktap2.<br><br>Note=
 that if we were to disable access to swap.img in frank.cfg, then the<br>wh=
ole process works as it should, disk, memory replication &amp; all, which<b=
r>
demonstrates that I have a working setup among my physical machines.<br><br=
>2.<br><br>In the meantime, I have also been digging into the source code o=
f Remus,<br>blktap2 and some parts of drbd, and I think I may have come acr=
oss a<br>
possible bug. If my observations are correct, then, it is possible that<br>=
after a (very unlucky) primary machine failure, the replicated VM is<br>res=
umed on the backup machine where its memory is in epoch A state and its<br>
disk is in epoch B state.<br><br>- If we are using blktap2, then it can be =
that A =3D B + 1 (the disk state is<br>one epoch behind than the memory sta=
te) or A =3D B - 1 (the disk state is one<br>epoch ahead of the memory stat=
e)<br>
- If we are using drbd, then it can be that A =3D B - 1 (the disk state is<=
br>one epoch ahead the memory state)<br><br>Remus is using two different ch=
annels of communication, one for memory<br>updates and one for disk updates=
. If I understand the code structure<br>
correctly, the issue I describe stems from the fact that Remus is also<br>u=
sing these channels to send two separate commit messages; one to the<br>xc_=
restore process, for memory, and one to the server tapdisk2 daemon<br>(simi=
lar for drbd) for disk updates.<br>
<br>These messages are needed in order to trace the boundaries of checkpoin=
t<br>epochs for each channel. However, what I feel that is missing (or I ha=
ven&#39;t<br>been able to find it) is a process on the backup machine side =
that decides<br>
when the local VM state (memory or disk) gets updated. For example, the<br>=
backup should update the state of a VM to epoch A iff we have received all<=
br>updates pertaining to epoch A (disk and memory). Then, and only then, ca=
n<br>
the backup send a Checkpoint Acknowledgement message to the primary, at<br>=
which point the primary can release the VM&#39;s network buffers.<br><br>Th=
e files of interest to us are the following:<br>xen-unstable/tools/libxc/xc=
_domain_save.c<br>
xen-unstable/tools/remus/remus<br>xen-unstable/tools/python/xen/remus/devic=
e.py<br>xen-unstable/tools/blktap2/drivers/block-remus.c<br><br>- assuming =
that we are using disk replication with blktap2<br><br>Assume that the prim=
ary machine is about to send a commit message to the<br>
backup machine. Thus, we are at line 1982 in the xc_domain_save.c file. The=
<br>primary is about to execute the discard_file_cache() function which, as=
 a<br>consequence, causes the primary to do an fsync() on the migration soc=
ket.<br>
<br>I am not sure about the particular mechanics involved in calling fsync(=
) on<br>a connected TCP socket, but I presume that the intended behaviour i=
s to<br>wait until the last byte written in that socket is acknowledged by =
the<br>
receiver (violates the end to end argument, but works in the general case<b=
r>where you have two machines connected back to back with a crossover cable=
).<br><br>Then, the primary invokes the checkpoint callback, which brings u=
s to the<br>
commit() function at line 166 in remus. This function invokes the<br>buf.co=
mmit() command for each of the available buffers. For network<br>buffers, t=
his causes them to release their output, whereas for disk<br>buffers, this =
causes remus to wait for an acknowledgement response for that<br>
particular disk from the backup, as seen in device.py. Since disk buffers<b=
r>have been inserted first, remus waits for acknowledgements for all disk<b=
r>buffers before it release any network buffer.<br><br>Notice that at line =
89 in function postsuspend() in device.py, remus sends<br>
a &#39;flush&#39; message to the disk control channel, which is all it take=
s for<br>the secondary machine to release the pending disk updates to its d=
isk state<br>(block-remus.c).<br><br>The bug described can occur if the pri=
mary crashes after invoking the<br>
discard_file_cache() command in xc_domain_save.c and before having a chance=
<br>to invoke any of the buf.commit() commands in remus. If the &#39;flush&=
#39; message<br>has not left the primary&#39;s socket buffer yet, at the ti=
me of the crash,<br>
then we have the A =3D B + 1 case outlined above, where the memory state is=
<br>one epoch ahead of the disk state. Similarly, if the primary crashes af=
ter<br>sending the &#39;flush&#39; message but before calling the discard_f=
ile_cache()<br>
command, we have the A =3D B - 1 case, where the VM&#39;s memory state is o=
ne<br>epoch behind the VM&#39;s disk state.<br><br>What&#39;s even more wor=
rying, however, is that block-remus.c and<br>xc_domain_save.c have two enti=
rely disjoint heartbeat mechanisms, which can<br>
potentially amount to an entirely new level of trouble<br><br>- assuming th=
at we use drbd<br><br>The setup is similar to the one described for blktap2=
. In this case,<br>however, remus forces the primary to wait in the preresu=
me() callback until<br>
it has received an acknowledgement for the disk updates. Unless I am<br>mis=
sing something, this makes little sense to me, as we are keeping the VM<br>=
suspended for a roundtrip time&#39;s worth of time, whereas it could have b=
een<br>
running. Shouldn&#39;t the waiting logic be moved to the commit() function<=
br>instead?<br><br>In any case, we have a similar scenario. drbd finishes s=
ending the commit<br>message to the backup VM and the primary crashes immed=
iately, before<br>
returning from the postcopy callback. Thus, the backup machine receives a<b=
r>commit for the disk updates but no commit for the memory updates. Since t=
he<br>two do not coordinate with each other, it will happily apply the disk=
<br>
updates and ruin memory-disk consistency on the guest VM.<br><br>- Epilogue=
<br><br>I think it would be better/cleaner/more consistent to have some kin=
d of<br>remus server daemon running on the backup physical machine. That da=
emon<br>
would coordinate when disk and memory are to be committed to the guest VM&#=
39;s<br>state (when that demon has received all checkpoint state pertaining=
 to a<br>particular VM that is). As such, it is the daemon that should deci=
de when<br>
to send a Checkpoint Acknowledgement message to the primary physical<br>mac=
hine.<br><br>Cheers!<br>dmelisso<br>

--14dae9340449a9b39304b8a0c391--


--===============6233444660754342065==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6233444660754342065==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 19:02:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 19:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvvjd-0007qk-61; Fri, 10 Feb 2012 19:02:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dimitrios.melissovas@epfl.ch>) id 1Rvvjc-0007qZ-0g
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 19:02:16 +0000
X-Env-Sender: dimitrios.melissovas@epfl.ch
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328900528!10980511!1
X-Originating-IP: [128.178.224.219]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_00_10,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3367 invoked from network); 10 Feb 2012 19:02:08 -0000
Received: from smtp0.epfl.ch (HELO smtp0.epfl.ch) (128.178.224.219)
	by server-8.tower-21.messagelabs.com with SMTP;
	10 Feb 2012 19:02:08 -0000
Received: (qmail 5865 invoked by uid 107); 10 Feb 2012 19:02:06 -0000
X-Virus-Scanned: ClamAV
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43) (authenticated)
	by smtp0.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPA;
	Fri, 10 Feb 2012 20:02:06 +0100
Received: by yhkk6 with SMTP id k6so41595954yhk.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 11:02:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.184.168 with SMTP id ev8mr13351362igc.29.1328900523799;
	Fri, 10 Feb 2012 11:02:03 -0800 (PST)
Received: by 10.182.51.225 with HTTP; Fri, 10 Feb 2012 11:02:03 -0800 (PST)
Date: Fri, 10 Feb 2012 20:02:03 +0100
Message-ID: <CAMnSOvBNKQMAEGyovbsKXJViZbUQ7oN-LK1syp-YSH6apjW+aw@mail.gmail.com>
From: Dimitrios Melissovas <dimitrios.melissovas@epfl.ch>
To: xen-devel@lists.xensource.com
Cc: rshriram@cs.ubc.ca
Subject: [Xen-devel] Remus: Possible disk replication consistency bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6233444660754342065=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6233444660754342065==
Content-Type: multipart/alternative; boundary=14dae9340449a9b39304b8a0c391

--14dae9340449a9b39304b8a0c391
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

Short version:

1. Is there any way to get disk replication to work with the blktap2 driver
when I use two file disk images (say, a disk image and a swap image).

2. [Possible bug] How does Remus guarantee that when, after failover, a
replicated VM boots at the backup physical machine, its memory state is
going to be consistent with its disk state? Remus uses two separate
channels, one for memory updates, and the other for disk updates. The
primary decides when to send individual commit messages to each of these
channels, but there appears to be no mechanism in place at the backup site
to coordinate if and when these updates should be applied. Thus, we have
the following execution scenario:

- Backup receives commit for disk updates for epoch E
- Primary crashes before sending commit for memory updates for epoch E
- Backup resumes the execution of the guest VM using the latest available
information
- The guest VM's memory state corresponds to epoch E - 1 and its disk state
- corresponds to epoch E. This is inconsistent.

Long version:

1.

In the simplified version of what I need, I have a single guest VM that has
access to two disk images, disk.img and swap.img, which are both replicated
using the blktap2 driver.

In order to achieve this, I used the following guide,
http://remusha.wikidot.com/ , which nets me the following setup
configuration (I deviated a little when creating the guest):

- Xen 4.2 (unstable), changeset (changeset version 24465:5b2676ac1321)
- Dom0 kernel: Linux v2.6.32.40 x86_64 (commit version
2b494f184d3337d10d59226e3632af56ea66629a)
- DomU kernel: Linux 3.0.4 x86_64

I have a guest VM, named frank, whose configuration file, frank.cfg,
contains the following parameters:

disk = [
'tap2:remus:nslrack83.epfl.ch:9002
|aio:/vserver/images/domains/frank/disk.img,xvda2,w',
'tap2:remus:nslrack83.epfl.ch:9003
|aio:/vserver/images/domains/frank/swap.img,xvda1,w',
]

which is correct, according to the documentation guidelines posted on
http://nss.cs.ubc.ca/remus/doc.html . Notice that I have assigned
a different tapdisk remote server channel to disk.img and swap.img

Assigning the same port number to both of them will not work, since both
the primary and the backup physical machines spawn one tapdisk daemon each
per disk image. I suppose that both daemons on the backup will try to bind
the same port number and, thus, one of them will fail. This causes the
procedure to hang. (In fact, the affected tapdisk instances on the primary
and backup will enter some kind of busy polling function and will consume
100% of the CPU assigned to them).

For whatever reason, however, things are not much different at all when I
assign different ports for replicating disk.img and swap.img. This is
something that I cannot explain, myself, and that is where I ultimately
gave up on trying to get disk replication working with blktap2.

Note that if we were to disable access to swap.img in frank.cfg, then the
whole process works as it should, disk, memory replication & all, which
demonstrates that I have a working setup among my physical machines.

2.

In the meantime, I have also been digging into the source code of Remus,
blktap2 and some parts of drbd, and I think I may have come across a
possible bug. If my observations are correct, then, it is possible that
after a (very unlucky) primary machine failure, the replicated VM is
resumed on the backup machine where its memory is in epoch A state and its
disk is in epoch B state.

- If we are using blktap2, then it can be that A = B + 1 (the disk state is
one epoch behind than the memory state) or A = B - 1 (the disk state is one
epoch ahead of the memory state)
- If we are using drbd, then it can be that A = B - 1 (the disk state is
one epoch ahead the memory state)

Remus is using two different channels of communication, one for memory
updates and one for disk updates. If I understand the code structure
correctly, the issue I describe stems from the fact that Remus is also
using these channels to send two separate commit messages; one to the
xc_restore process, for memory, and one to the server tapdisk2 daemon
(similar for drbd) for disk updates.

These messages are needed in order to trace the boundaries of checkpoint
epochs for each channel. However, what I feel that is missing (or I haven't
been able to find it) is a process on the backup machine side that decides
when the local VM state (memory or disk) gets updated. For example, the
backup should update the state of a VM to epoch A iff we have received all
updates pertaining to epoch A (disk and memory). Then, and only then, can
the backup send a Checkpoint Acknowledgement message to the primary, at
which point the primary can release the VM's network buffers.

The files of interest to us are the following:
xen-unstable/tools/libxc/xc_domain_save.c
xen-unstable/tools/remus/remus
xen-unstable/tools/python/xen/remus/device.py
xen-unstable/tools/blktap2/drivers/block-remus.c

- assuming that we are using disk replication with blktap2

Assume that the primary machine is about to send a commit message to the
backup machine. Thus, we are at line 1982 in the xc_domain_save.c file. The
primary is about to execute the discard_file_cache() function which, as a
consequence, causes the primary to do an fsync() on the migration socket.

I am not sure about the particular mechanics involved in calling fsync() on
a connected TCP socket, but I presume that the intended behaviour is to
wait until the last byte written in that socket is acknowledged by the
receiver (violates the end to end argument, but works in the general case
where you have two machines connected back to back with a crossover cable).

Then, the primary invokes the checkpoint callback, which brings us to the
commit() function at line 166 in remus. This function invokes the
buf.commit() command for each of the available buffers. For network
buffers, this causes them to release their output, whereas for disk
buffers, this causes remus to wait for an acknowledgement response for that
particular disk from the backup, as seen in device.py. Since disk buffers
have been inserted first, remus waits for acknowledgements for all disk
buffers before it release any network buffer.

Notice that at line 89 in function postsuspend() in device.py, remus sends
a 'flush' message to the disk control channel, which is all it takes for
the secondary machine to release the pending disk updates to its disk state
(block-remus.c).

The bug described can occur if the primary crashes after invoking the
discard_file_cache() command in xc_domain_save.c and before having a chance
to invoke any of the buf.commit() commands in remus. If the 'flush' message
has not left the primary's socket buffer yet, at the time of the crash,
then we have the A = B + 1 case outlined above, where the memory state is
one epoch ahead of the disk state. Similarly, if the primary crashes after
sending the 'flush' message but before calling the discard_file_cache()
command, we have the A = B - 1 case, where the VM's memory state is one
epoch behind the VM's disk state.

What's even more worrying, however, is that block-remus.c and
xc_domain_save.c have two entirely disjoint heartbeat mechanisms, which can
potentially amount to an entirely new level of trouble

- assuming that we use drbd

The setup is similar to the one described for blktap2. In this case,
however, remus forces the primary to wait in the preresume() callback until
it has received an acknowledgement for the disk updates. Unless I am
missing something, this makes little sense to me, as we are keeping the VM
suspended for a roundtrip time's worth of time, whereas it could have been
running. Shouldn't the waiting logic be moved to the commit() function
instead?

In any case, we have a similar scenario. drbd finishes sending the commit
message to the backup VM and the primary crashes immediately, before
returning from the postcopy callback. Thus, the backup machine receives a
commit for the disk updates but no commit for the memory updates. Since the
two do not coordinate with each other, it will happily apply the disk
updates and ruin memory-disk consistency on the guest VM.

- Epilogue

I think it would be better/cleaner/more consistent to have some kind of
remus server daemon running on the backup physical machine. That daemon
would coordinate when disk and memory are to be committed to the guest VM's
state (when that demon has received all checkpoint state pertaining to a
particular VM that is). As such, it is the daemon that should decide when
to send a Checkpoint Acknowledgement message to the primary physical
machine.

Cheers!
dmelisso

--14dae9340449a9b39304b8a0c391
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings,<br><br>Short version:<br><br>1. Is there any way to get disk rep=
lication to work with the blktap2 driver<br>when I use two file disk images=
 (say, a disk image and a swap image).<br><br>2. [Possible bug] How does Re=
mus guarantee that when, after failover, a<br>
replicated VM boots at the backup physical machine, its memory state is<br>=
going to be consistent with its disk state? Remus uses two separate<br>chan=
nels, one for memory updates, and the other for disk updates. The<br>primar=
y decides when to send individual commit messages to each of these<br>
channels, but there appears to be no mechanism in place at the backup site<=
br>to coordinate if and when these updates should be applied. Thus, we have=
<br>the following execution scenario:<br><br>- Backup receives commit for d=
isk updates for epoch E<br>
- Primary crashes before sending commit for memory updates for epoch E<br>-=
 Backup resumes the execution of the guest VM using the latest available in=
formation<br>- The guest VM&#39;s memory state corresponds to epoch E - 1 a=
nd its disk state<br>
- corresponds to epoch E. This is inconsistent.<br><br>Long version:<br><br=
>1.<br><br>In the simplified version of what I need, I have a single guest =
VM that has<br>access to two disk images, disk.img and swap.img, which are =
both replicated<br>
using the blktap2 driver.<br><br>In order to achieve this, I used the follo=
wing guide,<br><a href=3D"http://remusha.wikidot.com/">http://remusha.wikid=
ot.com/</a> , which nets me the following setup<br>configuration (I deviate=
d a little when creating the guest):<br>
<br>- Xen 4.2 (unstable), changeset (changeset version 24465:5b2676ac1321)<=
br>- Dom0 kernel: Linux v2.6.32.40 x86_64 (commit version 2b494f184d3337d10=
d59226e3632af56ea66629a)<br>- DomU kernel: Linux 3.0.4 x86_64<br><br>I have=
 a guest VM, named frank, whose configuration file, frank.cfg,<br>
contains the following parameters:<br><br>disk =3D [<br>&#39;tap2:remus:nsl=
rack83.epfl.ch:9002|aio:/vserver/images/domains/frank/disk.img,xvda2,w&#39;=
,<br>&#39;tap2:remus:nslrack83.epfl.ch:9003|aio:/vserver/images/domains/fra=
nk/swap.img,xvda1,w&#39;,<br>
]<br><br>which is correct, according to the documentation guidelines posted=
 on<br><a href=3D"http://nss.cs.ubc.ca/remus/doc.html">http://nss.cs.ubc.ca=
/remus/doc.html</a> . Notice that I have assigned<br>a different tapdisk re=
mote server channel to disk.img and swap.img<br>
<br>Assigning the same port number to both of them will not work, since bot=
h<br>the primary and the backup physical machines spawn one tapdisk daemon =
each<br>per disk image. I suppose that both daemons on the backup will try =
to bind<br>
the same port number and, thus, one of them will fail. This causes the<br>p=
rocedure to hang. (In fact, the affected tapdisk instances on the primary<b=
r>and backup will enter some kind of busy polling function and will consume=
<br>
100% of the CPU assigned to them).<br><br>For whatever reason, however, thi=
ngs are not much different at all when I<br>assign different ports for repl=
icating disk.img and swap.img. This is<br>something that I cannot explain, =
myself, and that is where I ultimately<br>
gave up on trying to get disk replication working with blktap2.<br><br>Note=
 that if we were to disable access to swap.img in frank.cfg, then the<br>wh=
ole process works as it should, disk, memory replication &amp; all, which<b=
r>
demonstrates that I have a working setup among my physical machines.<br><br=
>2.<br><br>In the meantime, I have also been digging into the source code o=
f Remus,<br>blktap2 and some parts of drbd, and I think I may have come acr=
oss a<br>
possible bug. If my observations are correct, then, it is possible that<br>=
after a (very unlucky) primary machine failure, the replicated VM is<br>res=
umed on the backup machine where its memory is in epoch A state and its<br>
disk is in epoch B state.<br><br>- If we are using blktap2, then it can be =
that A =3D B + 1 (the disk state is<br>one epoch behind than the memory sta=
te) or A =3D B - 1 (the disk state is one<br>epoch ahead of the memory stat=
e)<br>
- If we are using drbd, then it can be that A =3D B - 1 (the disk state is<=
br>one epoch ahead the memory state)<br><br>Remus is using two different ch=
annels of communication, one for memory<br>updates and one for disk updates=
. If I understand the code structure<br>
correctly, the issue I describe stems from the fact that Remus is also<br>u=
sing these channels to send two separate commit messages; one to the<br>xc_=
restore process, for memory, and one to the server tapdisk2 daemon<br>(simi=
lar for drbd) for disk updates.<br>
<br>These messages are needed in order to trace the boundaries of checkpoin=
t<br>epochs for each channel. However, what I feel that is missing (or I ha=
ven&#39;t<br>been able to find it) is a process on the backup machine side =
that decides<br>
when the local VM state (memory or disk) gets updated. For example, the<br>=
backup should update the state of a VM to epoch A iff we have received all<=
br>updates pertaining to epoch A (disk and memory). Then, and only then, ca=
n<br>
the backup send a Checkpoint Acknowledgement message to the primary, at<br>=
which point the primary can release the VM&#39;s network buffers.<br><br>Th=
e files of interest to us are the following:<br>xen-unstable/tools/libxc/xc=
_domain_save.c<br>
xen-unstable/tools/remus/remus<br>xen-unstable/tools/python/xen/remus/devic=
e.py<br>xen-unstable/tools/blktap2/drivers/block-remus.c<br><br>- assuming =
that we are using disk replication with blktap2<br><br>Assume that the prim=
ary machine is about to send a commit message to the<br>
backup machine. Thus, we are at line 1982 in the xc_domain_save.c file. The=
<br>primary is about to execute the discard_file_cache() function which, as=
 a<br>consequence, causes the primary to do an fsync() on the migration soc=
ket.<br>
<br>I am not sure about the particular mechanics involved in calling fsync(=
) on<br>a connected TCP socket, but I presume that the intended behaviour i=
s to<br>wait until the last byte written in that socket is acknowledged by =
the<br>
receiver (violates the end to end argument, but works in the general case<b=
r>where you have two machines connected back to back with a crossover cable=
).<br><br>Then, the primary invokes the checkpoint callback, which brings u=
s to the<br>
commit() function at line 166 in remus. This function invokes the<br>buf.co=
mmit() command for each of the available buffers. For network<br>buffers, t=
his causes them to release their output, whereas for disk<br>buffers, this =
causes remus to wait for an acknowledgement response for that<br>
particular disk from the backup, as seen in device.py. Since disk buffers<b=
r>have been inserted first, remus waits for acknowledgements for all disk<b=
r>buffers before it release any network buffer.<br><br>Notice that at line =
89 in function postsuspend() in device.py, remus sends<br>
a &#39;flush&#39; message to the disk control channel, which is all it take=
s for<br>the secondary machine to release the pending disk updates to its d=
isk state<br>(block-remus.c).<br><br>The bug described can occur if the pri=
mary crashes after invoking the<br>
discard_file_cache() command in xc_domain_save.c and before having a chance=
<br>to invoke any of the buf.commit() commands in remus. If the &#39;flush&=
#39; message<br>has not left the primary&#39;s socket buffer yet, at the ti=
me of the crash,<br>
then we have the A =3D B + 1 case outlined above, where the memory state is=
<br>one epoch ahead of the disk state. Similarly, if the primary crashes af=
ter<br>sending the &#39;flush&#39; message but before calling the discard_f=
ile_cache()<br>
command, we have the A =3D B - 1 case, where the VM&#39;s memory state is o=
ne<br>epoch behind the VM&#39;s disk state.<br><br>What&#39;s even more wor=
rying, however, is that block-remus.c and<br>xc_domain_save.c have two enti=
rely disjoint heartbeat mechanisms, which can<br>
potentially amount to an entirely new level of trouble<br><br>- assuming th=
at we use drbd<br><br>The setup is similar to the one described for blktap2=
. In this case,<br>however, remus forces the primary to wait in the preresu=
me() callback until<br>
it has received an acknowledgement for the disk updates. Unless I am<br>mis=
sing something, this makes little sense to me, as we are keeping the VM<br>=
suspended for a roundtrip time&#39;s worth of time, whereas it could have b=
een<br>
running. Shouldn&#39;t the waiting logic be moved to the commit() function<=
br>instead?<br><br>In any case, we have a similar scenario. drbd finishes s=
ending the commit<br>message to the backup VM and the primary crashes immed=
iately, before<br>
returning from the postcopy callback. Thus, the backup machine receives a<b=
r>commit for the disk updates but no commit for the memory updates. Since t=
he<br>two do not coordinate with each other, it will happily apply the disk=
<br>
updates and ruin memory-disk consistency on the guest VM.<br><br>- Epilogue=
<br><br>I think it would be better/cleaner/more consistent to have some kin=
d of<br>remus server daemon running on the backup physical machine. That da=
emon<br>
would coordinate when disk and memory are to be committed to the guest VM&#=
39;s<br>state (when that demon has received all checkpoint state pertaining=
 to a<br>particular VM that is). As such, it is the daemon that should deci=
de when<br>
to send a Checkpoint Acknowledgement message to the primary physical<br>mac=
hine.<br><br>Cheers!<br>dmelisso<br>

--14dae9340449a9b39304b8a0c391--


--===============6233444660754342065==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6233444660754342065==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 19:47:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 19:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvwPL-0000ZU-6G; Fri, 10 Feb 2012 19:45:23 +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 1RvwPJ-0000ZM-GN
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 19:45:21 +0000
Received: from [85.158.139.83:27787] by server-7.bemta-5.messagelabs.com id
	AA/43-01252-0D3753F4; Fri, 10 Feb 2012 19:45:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328903117!14609469!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11008 invoked from network); 10 Feb 2012 19:45:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 19:45:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328903117; l=1040;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=yp2Xe3VRKY/iOHmqWdTfibykXpM=;
	b=qc3FrNfvsfJkYxDpcdBDjiAihrEivmYsSXdpmi6cFhYQen3LD03q7xMkTiNgnzILonS
	xlyxCNzgyWy7HePb4XfH5ISeDzOQw2ngSTLA4MXHwtIfis5TP1siN8MkafY8G++p4/OZ0
	C8p28QHZTcuokEBgx+ysDtzQksrdNIZU+N0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (jimi mo1) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e006a5o1AGsVHY ;
	Fri, 10 Feb 2012 20:45:11 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A4FC318637; Fri, 10 Feb 2012 20:45:17 +0100 (CET)
Date: Fri, 10 Feb 2012 20:45:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210194517.GA23684@aepfle.de>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<20120210161357.GF32107@ocelot.phlegethon.org>
	<59a249b9f97604d7cb364b8edc38c6bf.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <59a249b9f97604d7cb364b8edc38c6bf.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Tim Deegan <tim@xen.org>, ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Andres Lagar-Cavilla wrote:

> Is there a timeout mechanism if out-of-tree consumers are not on the ball?

I would guess they need an adjustment for a step from 4.1 to 4.2.
Wasnt there already enough churn in the source in that area? And the
(old) SONAME is gone as well, so they need to be recompiled anyway.

> Actually, this hiatus allows me to float a perhaps cleaner way to map the
> ring: the known problem is that the pager may die abruptly, and Xen is
> still posting events to a page now belonging to some other dom0 process.
> This is dealt with in the qemu-dm case by stuffing the ring in an unused
> pfn (presumably somewhere in the mmio hole?)
> 
> Would that work? Is there a policy for parceling out these "magic pfn's"?

I was just thinking about this issue. The bug is that the ring lives in
dom0, the page should belong to domU and should be destroyed along with
it. And ring users in dom0 should request (and maybe initially allocate
and setup) a certain gfn belonging to domU.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 19:47:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 19:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvwPL-0000ZU-6G; Fri, 10 Feb 2012 19:45:23 +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 1RvwPJ-0000ZM-GN
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 19:45:21 +0000
Received: from [85.158.139.83:27787] by server-7.bemta-5.messagelabs.com id
	AA/43-01252-0D3753F4; Fri, 10 Feb 2012 19:45:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1328903117!14609469!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11008 invoked from network); 10 Feb 2012 19:45:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 19:45:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328903117; l=1040;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=yp2Xe3VRKY/iOHmqWdTfibykXpM=;
	b=qc3FrNfvsfJkYxDpcdBDjiAihrEivmYsSXdpmi6cFhYQen3LD03q7xMkTiNgnzILonS
	xlyxCNzgyWy7HePb4XfH5ISeDzOQw2ngSTLA4MXHwtIfis5TP1siN8MkafY8G++p4/OZ0
	C8p28QHZTcuokEBgx+ysDtzQksrdNIZU+N0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (jimi mo1) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e006a5o1AGsVHY ;
	Fri, 10 Feb 2012 20:45:11 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A4FC318637; Fri, 10 Feb 2012 20:45:17 +0100 (CET)
Date: Fri, 10 Feb 2012 20:45:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120210194517.GA23684@aepfle.de>
References: <patchbomb.1328767705@xdev.gridcentric.ca>
	<20120210161357.GF32107@ocelot.phlegethon.org>
	<59a249b9f97604d7cb364b8edc38c6bf.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <59a249b9f97604d7cb364b8edc38c6bf.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Tim Deegan <tim@xen.org>, ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Andres Lagar-Cavilla wrote:

> Is there a timeout mechanism if out-of-tree consumers are not on the ball?

I would guess they need an adjustment for a step from 4.1 to 4.2.
Wasnt there already enough churn in the source in that area? And the
(old) SONAME is gone as well, so they need to be recompiled anyway.

> Actually, this hiatus allows me to float a perhaps cleaner way to map the
> ring: the known problem is that the pager may die abruptly, and Xen is
> still posting events to a page now belonging to some other dom0 process.
> This is dealt with in the qemu-dm case by stuffing the ring in an unused
> pfn (presumably somewhere in the mmio hole?)
> 
> Would that work? Is there a policy for parceling out these "magic pfn's"?

I was just thinking about this issue. The bug is that the ring lives in
dom0, the page should belong to domU and should be destroyed along with
it. And ring users in dom0 should request (and maybe initially allocate
and setup) a certain gfn belonging to domU.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvwhx-0001IY-Lb; Fri, 10 Feb 2012 20:04:37 +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 1Rvwhw-0001IR-IN
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:04:36 +0000
Received: from [85.158.139.83:6865] by server-2.bemta-5.messagelabs.com id
	37/EF-20725-358753F4; Fri, 10 Feb 2012 20:04:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328904271!14513065!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12951 invoked from network); 10 Feb 2012 20:04:34 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 20:04:34 -0000
Received: by pbbro2 with SMTP id ro2so14993151pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 12:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=jrG1ioNE0WQhJoJHTqb4pog3AEjbu4DfMuc1Dc3Tavg=;
	b=AbKU68nkliO8xpk5ZeWPORtsgihDgbdqPVHv6SDpjMjklIc3KGPM3IlBRQhpyvIojQ
	u4FwNcjuwfrqZMK4gUjyo6V6nvOMQChc4mkD3PZP9AEKv+UtRVDj7bEu1xhxnP8zKdPO
	9owLlxRpcp5ecvNdzuyom8VAL0fhfoxRSNy5I=
Received: by 10.68.217.72 with SMTP id ow8mr19195467pbc.130.1328904271052;
	Fri, 10 Feb 2012 12:04:31 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id o7sm15940971pbq.8.2012.02.10.12.04.27
	(version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 12:04:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 10 Feb 2012 12:04:23 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB5AB847.2AF41%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
	interfaces v2
Thread-Index: AczoLy6cxHKQv6A070q8CjFf7Cl5QQ==
In-Reply-To: <20120210194517.GA23684@aepfle.de>
Mime-version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Tim Deegan <tim@xen.org>, ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/2012 11:45, "Olaf Hering" <olaf@aepfle.de> wrote:

>> Actually, this hiatus allows me to float a perhaps cleaner way to map the
>> ring: the known problem is that the pager may die abruptly, and Xen is
>> still posting events to a page now belonging to some other dom0 process.
>> This is dealt with in the qemu-dm case by stuffing the ring in an unused
>> pfn (presumably somewhere in the mmio hole?)
>> 
>> Would that work? Is there a policy for parceling out these "magic pfn's"?
> 
> I was just thinking about this issue. The bug is that the ring lives in
> dom0, the page should belong to domU and should be destroyed along with
> it. And ring users in dom0 should request (and maybe initially allocate
> and setup) a certain gfn belonging to domU.

Yes indeed. The gpfn could be allocated by the domain builder, or by
hvmloader (which might be too late!).

 -- Keir
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:05:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvwhx-0001IY-Lb; Fri, 10 Feb 2012 20:04:37 +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 1Rvwhw-0001IR-IN
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:04:36 +0000
Received: from [85.158.139.83:6865] by server-2.bemta-5.messagelabs.com id
	37/EF-20725-358753F4; Fri, 10 Feb 2012 20:04:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328904271!14513065!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12951 invoked from network); 10 Feb 2012 20:04:34 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 20:04:34 -0000
Received: by pbbro2 with SMTP id ro2so14993151pbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 12:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=jrG1ioNE0WQhJoJHTqb4pog3AEjbu4DfMuc1Dc3Tavg=;
	b=AbKU68nkliO8xpk5ZeWPORtsgihDgbdqPVHv6SDpjMjklIc3KGPM3IlBRQhpyvIojQ
	u4FwNcjuwfrqZMK4gUjyo6V6nvOMQChc4mkD3PZP9AEKv+UtRVDj7bEu1xhxnP8zKdPO
	9owLlxRpcp5ecvNdzuyom8VAL0fhfoxRSNy5I=
Received: by 10.68.217.72 with SMTP id ow8mr19195467pbc.130.1328904271052;
	Fri, 10 Feb 2012 12:04:31 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id o7sm15940971pbq.8.2012.02.10.12.04.27
	(version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 12:04:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 10 Feb 2012 12:04:23 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB5AB847.2AF41%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
	interfaces v2
Thread-Index: AczoLy6cxHKQv6A070q8CjFf7Cl5QQ==
In-Reply-To: <20120210194517.GA23684@aepfle.de>
Mime-version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Tim Deegan <tim@xen.org>, ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/2012 11:45, "Olaf Hering" <olaf@aepfle.de> wrote:

>> Actually, this hiatus allows me to float a perhaps cleaner way to map the
>> ring: the known problem is that the pager may die abruptly, and Xen is
>> still posting events to a page now belonging to some other dom0 process.
>> This is dealt with in the qemu-dm case by stuffing the ring in an unused
>> pfn (presumably somewhere in the mmio hole?)
>> 
>> Would that work? Is there a policy for parceling out these "magic pfn's"?
> 
> I was just thinking about this issue. The bug is that the ring lives in
> dom0, the page should belong to domU and should be destroyed along with
> it. And ring users in dom0 should request (and maybe initially allocate
> and setup) a certain gfn belonging to domU.

Yes indeed. The gpfn could be allocated by the domain builder, or by
hvmloader (which might be too late!).

 -- Keir
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:12:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20: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.xensource.com>)
	id 1Rvwok-0001VS-J7; Fri, 10 Feb 2012 20:11:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvwoi-0001VN-PV
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:11:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328904690!14312205!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU1ODQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30585 invoked from network); 10 Feb 2012 20:11:30 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.202) by server-6.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 20:11:30 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 8D2AA334069;
	Fri, 10 Feb 2012 12:11:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=oyozbr5DDc7RdAkdS05LxUgGQucIurpKaaV7ykX+t8iI
	/YkFtrMyzCI+g9LtoVyc4CEd1fIcoR1AW3+Is/OrD/Ss+wbjltE2ad33CBn41rDM
	L+tzpqdfpu7MGVWiikj1qzYiUKSqWkpw1zmRoLGBrR6+wrv1tkHYFVeYi3/dxBM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=u8C8VUvNLmsV4Gwj+p86G6KMj+A=; b=FbPxhnsR
	16HH/2JL+Dizm0QDdjEvcATEBiohm8EkKqS/Zb+q68dHr4TBOBDa/+UyfvGIG6K7
	N0mw9jedpS5UFfSIUYJM1Jc0y/ceoyO5BPCn4E3m4kmlp009m8WuSCJhDeawd541
	xqPUI2GoVWsGe7hy+PpRwQzM7cP6fJU1iSY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 04B1E334064; 
	Fri, 10 Feb 2012 12:11:28 -0800 (PST)
Received: from 69.165.162.46 (proxying for 69.165.162.46)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 12:11:29 -0800
Message-ID: <54af50e4d70943ce8539bd3ce0e3120c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB5AB847.2AF41%keir.xen@gmail.com>
References: <CB5AB847.2AF41%keir.xen@gmail.com>
Date: Fri, 10 Feb 2012 12:11:29 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	Tim Deegan <tim@xen.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 10/02/2012 11:45, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>>> Actually, this hiatus allows me to float a perhaps cleaner way to map
>>> the
>>> ring: the known problem is that the pager may die abruptly, and Xen is
>>> still posting events to a page now belonging to some other dom0
>>> process.
>>> This is dealt with in the qemu-dm case by stuffing the ring in an
>>> unused
>>> pfn (presumably somewhere in the mmio hole?)
>>>
>>> Would that work? Is there a policy for parceling out these "magic
>>> pfn's"?
>>
>> I was just thinking about this issue. The bug is that the ring lives in
>> dom0, the page should belong to domU and should be destroyed along with
>> it. And ring users in dom0 should request (and maybe initially allocate
>> and setup) a certain gfn belonging to domU.
>
> Yes indeed. The gpfn could be allocated by the domain builder, or by
> hvmloader (which might be too late!).

Well, let's say the domain builder reserves three gpfns (paging, access,
sharing). When helpers for each come up, the enable domctl allocates the
actual frame. Or, we could have the frames allocated up front, it's not
terrible wastage -- the enable domctl would init the ring.

My question was more along the lines of how to choose which guest pfns to
reserve for this.

Andres
>
>  -- Keir
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:12:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20: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.xensource.com>)
	id 1Rvwok-0001VS-J7; Fri, 10 Feb 2012 20:11:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rvwoi-0001VN-PV
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:11:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1328904690!14312205!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU1ODQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30585 invoked from network); 10 Feb 2012 20:11:30 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.202) by server-6.tower-216.messagelabs.com with SMTP;
	10 Feb 2012 20:11:30 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 8D2AA334069;
	Fri, 10 Feb 2012 12:11:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=oyozbr5DDc7RdAkdS05LxUgGQucIurpKaaV7ykX+t8iI
	/YkFtrMyzCI+g9LtoVyc4CEd1fIcoR1AW3+Is/OrD/Ss+wbjltE2ad33CBn41rDM
	L+tzpqdfpu7MGVWiikj1qzYiUKSqWkpw1zmRoLGBrR6+wrv1tkHYFVeYi3/dxBM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=u8C8VUvNLmsV4Gwj+p86G6KMj+A=; b=FbPxhnsR
	16HH/2JL+Dizm0QDdjEvcATEBiohm8EkKqS/Zb+q68dHr4TBOBDa/+UyfvGIG6K7
	N0mw9jedpS5UFfSIUYJM1Jc0y/ceoyO5BPCn4E3m4kmlp009m8WuSCJhDeawd541
	xqPUI2GoVWsGe7hy+PpRwQzM7cP6fJU1iSY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 04B1E334064; 
	Fri, 10 Feb 2012 12:11:28 -0800 (PST)
Received: from 69.165.162.46 (proxying for 69.165.162.46)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 10 Feb 2012 12:11:29 -0800
Message-ID: <54af50e4d70943ce8539bd3ce0e3120c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB5AB847.2AF41%keir.xen@gmail.com>
References: <CB5AB847.2AF41%keir.xen@gmail.com>
Date: Fri, 10 Feb 2012 12:11:29 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	Tim Deegan <tim@xen.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 10/02/2012 11:45, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>>> Actually, this hiatus allows me to float a perhaps cleaner way to map
>>> the
>>> ring: the known problem is that the pager may die abruptly, and Xen is
>>> still posting events to a page now belonging to some other dom0
>>> process.
>>> This is dealt with in the qemu-dm case by stuffing the ring in an
>>> unused
>>> pfn (presumably somewhere in the mmio hole?)
>>>
>>> Would that work? Is there a policy for parceling out these "magic
>>> pfn's"?
>>
>> I was just thinking about this issue. The bug is that the ring lives in
>> dom0, the page should belong to domU and should be destroyed along with
>> it. And ring users in dom0 should request (and maybe initially allocate
>> and setup) a certain gfn belonging to domU.
>
> Yes indeed. The gpfn could be allocated by the domain builder, or by
> hvmloader (which might be too late!).

Well, let's say the domain builder reserves three gpfns (paging, access,
sharing). When helpers for each come up, the enable domctl allocates the
actual frame. Or, we could have the frames allocated up front, it's not
terrible wastage -- the enable domctl would init the ring.

My question was more along the lines of how to choose which guest pfns to
reserve for this.

Andres
>
>  -- Keir
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:30:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvx6T-0001sm-CM; Fri, 10 Feb 2012 20:29:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rvx6R-0001sh-Cs
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:29:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328905786!12889353!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5943 invoked from network); 10 Feb 2012 20:29:48 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 20:29:48 -0000
Received: by damc16 with SMTP id c16so20332688dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 12:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5lxc7s3YX3BYaxL8oky8K4hTIbmHG8EG1JyHc5OE4/E=;
	b=fuQGHxGnq53uOuag2J0NqFVY0HYlacwO3lZfi7NelcSkxGQpI4V58gwvtXQuzeZTNh
	1DCoVLya+H/5fy9jcmrJt6xUAxDaNUU1J0+ZLqCRZXaEQgA9WAr8t9KIxgyBwAeNtTa1
	VdyVrGav7ueSML9qPwSTWnR+DC8tJsmYN71i8=
Received: by 10.68.74.164 with SMTP id u4mr19079278pbv.85.1328905785836;
	Fri, 10 Feb 2012 12:29:45 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id
	kx17sm16075130pbb.19.2012.02.10.12.29.37
	(version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 12:29:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 10 Feb 2012 12:29:32 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB5ABE2C.2AF48%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
	interfaces v2
Thread-Index: AczoMrILFZgGKN6JPE+/9f1mKq943Q==
In-Reply-To: <54af50e4d70943ce8539bd3ce0e3120c.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	Tim Deegan <tim@xen.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/2012 12:11, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>>> I was just thinking about this issue. The bug is that the ring lives in
>>> dom0, the page should belong to domU and should be destroyed along with
>>> it. And ring users in dom0 should request (and maybe initially allocate
>>> and setup) a certain gfn belonging to domU.
>> 
>> Yes indeed. The gpfn could be allocated by the domain builder, or by
>> hvmloader (which might be too late!).
> 
> Well, let's say the domain builder reserves three gpfns (paging, access,
> sharing). When helpers for each come up, the enable domctl allocates the
> actual frame. Or, we could have the frames allocated up front, it's not
> terrible wastage -- the enable domctl would init the ring.
> 
> My question was more along the lines of how to choose which guest pfns to
> reserve for this.

Domain builder (xc_hvm_build.c) would be the sensible place to reserve, and
push that info down to Xen in some way. Then allocate the pages during the
enable domctl, via alloc_xenheap_page() (for a few arcane reasons, it's
better to use this than alloc_domheap_page() for this particular purpose).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:30:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rvx6T-0001sm-CM; Fri, 10 Feb 2012 20:29:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rvx6R-0001sh-Cs
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:29:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328905786!12889353!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5943 invoked from network); 10 Feb 2012 20:29:48 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2012 20:29:48 -0000
Received: by damc16 with SMTP id c16so20332688dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 12:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5lxc7s3YX3BYaxL8oky8K4hTIbmHG8EG1JyHc5OE4/E=;
	b=fuQGHxGnq53uOuag2J0NqFVY0HYlacwO3lZfi7NelcSkxGQpI4V58gwvtXQuzeZTNh
	1DCoVLya+H/5fy9jcmrJt6xUAxDaNUU1J0+ZLqCRZXaEQgA9WAr8t9KIxgyBwAeNtTa1
	VdyVrGav7ueSML9qPwSTWnR+DC8tJsmYN71i8=
Received: by 10.68.74.164 with SMTP id u4mr19079278pbv.85.1328905785836;
	Fri, 10 Feb 2012 12:29:45 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id
	kx17sm16075130pbb.19.2012.02.10.12.29.37
	(version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 12:29:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 10 Feb 2012 12:29:32 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB5ABE2C.2AF48%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
	interfaces v2
Thread-Index: AczoMrILFZgGKN6JPE+/9f1mKq943Q==
In-Reply-To: <54af50e4d70943ce8539bd3ce0e3120c.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	Tim Deegan <tim@xen.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 3] Update paging/sharing/access
 interfaces v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/02/2012 12:11, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>>> I was just thinking about this issue. The bug is that the ring lives in
>>> dom0, the page should belong to domU and should be destroyed along with
>>> it. And ring users in dom0 should request (and maybe initially allocate
>>> and setup) a certain gfn belonging to domU.
>> 
>> Yes indeed. The gpfn could be allocated by the domain builder, or by
>> hvmloader (which might be too late!).
> 
> Well, let's say the domain builder reserves three gpfns (paging, access,
> sharing). When helpers for each come up, the enable domctl allocates the
> actual frame. Or, we could have the frames allocated up front, it's not
> terrible wastage -- the enable domctl would init the ring.
> 
> My question was more along the lines of how to choose which guest pfns to
> reserve for this.

Domain builder (xc_hvm_build.c) would be the sensible place to reserve, and
push that info down to Xen in some way. Then allocate the pages during the
enable domctl, via alloc_xenheap_page() (for a few arcane reasons, it's
better to use this than alloc_domheap_page() for this particular purpose).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:58:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20: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.xensource.com>)
	id 1RvxXI-00029k-UT; Fri, 10 Feb 2012 20:57:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvxXH-00029f-2D
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:57:39 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328907412!51971197!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3231 invoked from network); 10 Feb 2012 20:56:53 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 20:56:53 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1AKvRcM007029
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 10 Feb 2012 12:57:28 -0800
Received: by bkcjg15 with SMTP id jg15so5903043bkc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 12:57:26 -0800 (PST)
Received: by 10.204.154.86 with SMTP id n22mr3062650bkw.85.1328907446297; Fri,
	10 Feb 2012 12:57:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Fri, 10 Feb 2012 12:56:46 -0800 (PST)
In-Reply-To: <CAMnSOvBNKQMAEGyovbsKXJViZbUQ7oN-LK1syp-YSH6apjW+aw@mail.gmail.com>
References: <CAMnSOvBNKQMAEGyovbsKXJViZbUQ7oN-LK1syp-YSH6apjW+aw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 10 Feb 2012 12:56:46 -0800
Message-ID: <CAP8mzPPNccroDVqoq7J9XiFNQYNGYe3a5U4sJ9xfckFNZH=wOQ@mail.gmail.com>
To: Dimitrios Melissovas <dimitrios.melissovas@epfl.ch>
Cc: Andrew Warfield <andy@cs.ubc.ca>, Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Remus: Possible disk replication consistency bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4394173418061665659=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4394173418061665659==
Content-Type: multipart/alternative; boundary=0015175d039646a63f04b8a26001

--0015175d039646a63f04b8a26001
Content-Type: text/plain; charset=ISO-8859-1

Hi dmelisso,

On Fri, Feb 10, 2012 at 11:02 AM, Dimitrios Melissovas <
dimitrios.melissovas@epfl.ch> wrote:

> Greetings,
>
> Short version:
>
> 1. Is there any way to get disk replication to work with the blktap2 driver
> when I use two file disk images (say, a disk image and a swap image).
>
>
It used to be possible. I have run remus with 3 blktap2 disks.

I even remember fixing up some issue in the blktap2 code in
unstable/4.1-testing,
that broke the replication (but that was almost a year ago).

Let me check what has changed in the unstable repo, to break the blktap2
replication again.

2. [Possible bug] How does Remus guarantee that when, after failover, a
> replicated VM boots at the backup physical machine, its memory state is
> going to be consistent with its disk state?


Currently there is no synchronization mechanism. I certainly agree that it
is a bug and
a very very rare one, for I have not been able to reproduce the bug/observe
side-effects.

I even have a fix for the drbd version, though not in the daemonized form
that you are talking about.
I havent found time to add a similar fix to the blktap2 version, which is
why I havent sent out a fix.


> Remus uses two separate
> channels, one for memory updates, and the other for disk updates. The
> primary decides when to send individual commit messages to each of these
> channels, but there appears to be no mechanism in place at the backup site
> to coordinate if and when these updates should be applied. Thus, we have
> the following execution scenario:
>
> - Backup receives commit for disk updates for epoch E
> - Primary crashes before sending commit for memory updates for epoch E
> - Backup resumes the execution of the guest VM using the latest available
> information
> - The guest VM's memory state corresponds to epoch E - 1 and its disk state
> - corresponds to epoch E. This is inconsistent.
>


> - Epilogue
>
> I think it would be better/cleaner/more consistent to have some kind of
> remus server daemon running on the backup physical machine. That daemon
> would coordinate when disk and memory are to be committed to the guest VM's
> state (when that demon has received all checkpoint state pertaining to a
> particular VM that is). As such, it is the daemon that should decide when
> to send a Checkpoint Acknowledgement message to the primary physical
> machine.
>
>
Yes I agree. Stefano posted patches in xen-devel, introducing callbacks in
xc_domain_restore.

My intention is to add one or more callbacks, that would
(a) send explicit checkpoint acknowledgements to the primary (rather than
relying on the fsync() on primary)
(b) only send the checkpoint ack after ensuring that all disks have
received their checkpoints.

With the explicit ack from xc_domain_restore callback, one could actually
get rid of the disk
level acknowledgements. The primary would only send a "barrier" or "flush"
to delimit checkpoints.


> Cheers!
> dmelisso
>

--0015175d039646a63f04b8a26001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi dmelisso,<br><br><div class=3D"gmail_quote">On Fri, Feb 10, 2012 at 11:0=
2 AM, Dimitrios Melissovas <span dir=3D"ltr">&lt;<a href=3D"mailto:dimitrio=
s.melissovas@epfl.ch">dimitrios.melissovas@epfl.ch</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

Greetings,<br><br>Short version:<br><br>1. Is there any way to get disk rep=
lication to work with the blktap2 driver<br>when I use two file disk images=
 (say, a disk image and a swap image).<br><br></blockquote><div><br>It used=
 to be possible. I have run remus with 3 blktap2 disks.<br>

<br>I even remember fixing up some issue in the blktap2 code in unstable/4.=
1-testing,<br>that broke the replication (but that was almost a year ago).<=
br><br>Let me check what has changed in the unstable repo, to break the blk=
tap2 replication again.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. [Possible bu=
g] How does Remus guarantee that when, after failover, a<br>
replicated VM boots at the backup physical machine, its memory state is<br>=
going to be consistent with its disk state?</blockquote><div><br>Currently =
there is no synchronization mechanism. I certainly agree that it is a bug a=
nd<br>

a very very rare one, for I have not been able to reproduce the bug/observe=
 side-effects.<br><br>I even have a fix for the drbd version, though not in=
 the daemonized form that you are talking about.<br>I havent found time to =
add a similar fix to the blktap2 version, which is why I havent sent out a =
fix.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Remus uses =
two separate<br>channels, one for memory updates, and the other for disk up=
dates. The<br>

primary decides when to send individual commit messages to each of these<br=
>
channels, but there appears to be no mechanism in place at the backup site<=
br>to coordinate if and when these updates should be applied. Thus, we have=
<br>the following execution scenario:<br><br>- Backup receives commit for d=
isk updates for epoch E<br>


- Primary crashes before sending commit for memory updates for epoch E<br>-=
 Backup resumes the execution of the guest VM using the latest available in=
formation<br>- The guest VM&#39;s memory state corresponds to epoch E - 1 a=
nd its disk state<br>


- corresponds to epoch E. This is inconsistent.<br></blockquote><div>=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">- Epilogue<br><br>I th=
ink it would be better/cleaner/more consistent to have some kind of<br>

remus server daemon running on the backup physical machine. That daemon<br>
would coordinate when disk and memory are to be committed to the guest VM&#=
39;s<br>state (when that demon has received all checkpoint state pertaining=
 to a<br>particular VM that is). As such, it is the daemon that should deci=
de when<br>


to send a Checkpoint Acknowledgement message to the primary physical<br>mac=
hine.<br><br></blockquote><div><br>Yes I agree. Stefano posted patches in x=
en-devel, introducing callbacks in xc_domain_restore.<br><br>My intention i=
s to add one or more callbacks, that would <br>

(a) send explicit checkpoint acknowledgements to the primary (rather than r=
elying on the fsync() on primary)<br>(b) only send the checkpoint ack after=
 ensuring that all disks have received their checkpoints.<br><br>With the e=
xplicit ack from xc_domain_restore callback, one could actually get rid of =
the disk<br>

level acknowledgements. The primary would only send a &quot;barrier&quot; o=
r &quot;flush&quot; to delimit checkpoints.<br>=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

Cheers!<br>dmelisso<br>
</blockquote></div><br>

--0015175d039646a63f04b8a26001--


--===============4394173418061665659==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4394173418061665659==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 20:58:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 20: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.xensource.com>)
	id 1RvxXI-00029k-UT; Fri, 10 Feb 2012 20:57:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RvxXH-00029f-2D
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 20:57:39 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328907412!51971197!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3231 invoked from network); 10 Feb 2012 20:56:53 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 20:56:53 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1AKvRcM007029
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 10 Feb 2012 12:57:28 -0800
Received: by bkcjg15 with SMTP id jg15so5903043bkc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 10 Feb 2012 12:57:26 -0800 (PST)
Received: by 10.204.154.86 with SMTP id n22mr3062650bkw.85.1328907446297; Fri,
	10 Feb 2012 12:57:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Fri, 10 Feb 2012 12:56:46 -0800 (PST)
In-Reply-To: <CAMnSOvBNKQMAEGyovbsKXJViZbUQ7oN-LK1syp-YSH6apjW+aw@mail.gmail.com>
References: <CAMnSOvBNKQMAEGyovbsKXJViZbUQ7oN-LK1syp-YSH6apjW+aw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 10 Feb 2012 12:56:46 -0800
Message-ID: <CAP8mzPPNccroDVqoq7J9XiFNQYNGYe3a5U4sJ9xfckFNZH=wOQ@mail.gmail.com>
To: Dimitrios Melissovas <dimitrios.melissovas@epfl.ch>
Cc: Andrew Warfield <andy@cs.ubc.ca>, Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Remus: Possible disk replication consistency bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4394173418061665659=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4394173418061665659==
Content-Type: multipart/alternative; boundary=0015175d039646a63f04b8a26001

--0015175d039646a63f04b8a26001
Content-Type: text/plain; charset=ISO-8859-1

Hi dmelisso,

On Fri, Feb 10, 2012 at 11:02 AM, Dimitrios Melissovas <
dimitrios.melissovas@epfl.ch> wrote:

> Greetings,
>
> Short version:
>
> 1. Is there any way to get disk replication to work with the blktap2 driver
> when I use two file disk images (say, a disk image and a swap image).
>
>
It used to be possible. I have run remus with 3 blktap2 disks.

I even remember fixing up some issue in the blktap2 code in
unstable/4.1-testing,
that broke the replication (but that was almost a year ago).

Let me check what has changed in the unstable repo, to break the blktap2
replication again.

2. [Possible bug] How does Remus guarantee that when, after failover, a
> replicated VM boots at the backup physical machine, its memory state is
> going to be consistent with its disk state?


Currently there is no synchronization mechanism. I certainly agree that it
is a bug and
a very very rare one, for I have not been able to reproduce the bug/observe
side-effects.

I even have a fix for the drbd version, though not in the daemonized form
that you are talking about.
I havent found time to add a similar fix to the blktap2 version, which is
why I havent sent out a fix.


> Remus uses two separate
> channels, one for memory updates, and the other for disk updates. The
> primary decides when to send individual commit messages to each of these
> channels, but there appears to be no mechanism in place at the backup site
> to coordinate if and when these updates should be applied. Thus, we have
> the following execution scenario:
>
> - Backup receives commit for disk updates for epoch E
> - Primary crashes before sending commit for memory updates for epoch E
> - Backup resumes the execution of the guest VM using the latest available
> information
> - The guest VM's memory state corresponds to epoch E - 1 and its disk state
> - corresponds to epoch E. This is inconsistent.
>


> - Epilogue
>
> I think it would be better/cleaner/more consistent to have some kind of
> remus server daemon running on the backup physical machine. That daemon
> would coordinate when disk and memory are to be committed to the guest VM's
> state (when that demon has received all checkpoint state pertaining to a
> particular VM that is). As such, it is the daemon that should decide when
> to send a Checkpoint Acknowledgement message to the primary physical
> machine.
>
>
Yes I agree. Stefano posted patches in xen-devel, introducing callbacks in
xc_domain_restore.

My intention is to add one or more callbacks, that would
(a) send explicit checkpoint acknowledgements to the primary (rather than
relying on the fsync() on primary)
(b) only send the checkpoint ack after ensuring that all disks have
received their checkpoints.

With the explicit ack from xc_domain_restore callback, one could actually
get rid of the disk
level acknowledgements. The primary would only send a "barrier" or "flush"
to delimit checkpoints.


> Cheers!
> dmelisso
>

--0015175d039646a63f04b8a26001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi dmelisso,<br><br><div class=3D"gmail_quote">On Fri, Feb 10, 2012 at 11:0=
2 AM, Dimitrios Melissovas <span dir=3D"ltr">&lt;<a href=3D"mailto:dimitrio=
s.melissovas@epfl.ch">dimitrios.melissovas@epfl.ch</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

Greetings,<br><br>Short version:<br><br>1. Is there any way to get disk rep=
lication to work with the blktap2 driver<br>when I use two file disk images=
 (say, a disk image and a swap image).<br><br></blockquote><div><br>It used=
 to be possible. I have run remus with 3 blktap2 disks.<br>

<br>I even remember fixing up some issue in the blktap2 code in unstable/4.=
1-testing,<br>that broke the replication (but that was almost a year ago).<=
br><br>Let me check what has changed in the unstable repo, to break the blk=
tap2 replication again.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. [Possible bu=
g] How does Remus guarantee that when, after failover, a<br>
replicated VM boots at the backup physical machine, its memory state is<br>=
going to be consistent with its disk state?</blockquote><div><br>Currently =
there is no synchronization mechanism. I certainly agree that it is a bug a=
nd<br>

a very very rare one, for I have not been able to reproduce the bug/observe=
 side-effects.<br><br>I even have a fix for the drbd version, though not in=
 the daemonized form that you are talking about.<br>I havent found time to =
add a similar fix to the blktap2 version, which is why I havent sent out a =
fix.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Remus uses =
two separate<br>channels, one for memory updates, and the other for disk up=
dates. The<br>

primary decides when to send individual commit messages to each of these<br=
>
channels, but there appears to be no mechanism in place at the backup site<=
br>to coordinate if and when these updates should be applied. Thus, we have=
<br>the following execution scenario:<br><br>- Backup receives commit for d=
isk updates for epoch E<br>


- Primary crashes before sending commit for memory updates for epoch E<br>-=
 Backup resumes the execution of the guest VM using the latest available in=
formation<br>- The guest VM&#39;s memory state corresponds to epoch E - 1 a=
nd its disk state<br>


- corresponds to epoch E. This is inconsistent.<br></blockquote><div>=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">- Epilogue<br><br>I th=
ink it would be better/cleaner/more consistent to have some kind of<br>

remus server daemon running on the backup physical machine. That daemon<br>
would coordinate when disk and memory are to be committed to the guest VM&#=
39;s<br>state (when that demon has received all checkpoint state pertaining=
 to a<br>particular VM that is). As such, it is the daemon that should deci=
de when<br>


to send a Checkpoint Acknowledgement message to the primary physical<br>mac=
hine.<br><br></blockquote><div><br>Yes I agree. Stefano posted patches in x=
en-devel, introducing callbacks in xc_domain_restore.<br><br>My intention i=
s to add one or more callbacks, that would <br>

(a) send explicit checkpoint acknowledgements to the primary (rather than r=
elying on the fsync() on primary)<br>(b) only send the checkpoint ack after=
 ensuring that all disks have received their checkpoints.<br><br>With the e=
xplicit ack from xc_domain_restore callback, one could actually get rid of =
the disk<br>

level acknowledgements. The primary would only send a &quot;barrier&quot; o=
r &quot;flush&quot; to delimit checkpoints.<br>=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

Cheers!<br>dmelisso<br>
</blockquote></div><br>

--0015175d039646a63f04b8a26001--


--===============4394173418061665659==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4394173418061665659==--


From xen-devel-bounces@lists.xensource.com Fri Feb 10 21:29:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 21: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.xensource.com>)
	id 1Rvy1Y-0002Xc-U7; Fri, 10 Feb 2012 21:28:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rvy1W-0002XX-2p
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 21:28:54 +0000
Received: from [85.158.139.83:17844] by server-10.bemta-5.messagelabs.com id
	17/6E-26909-51C853F4; Fri, 10 Feb 2012 21:28:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328909332!14603633!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12309 invoked from network); 10 Feb 2012 21:28:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Feb 2012 21:28:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328909332; l=1016;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=IC7jDq3hQiV1jms49XIyNKmfOlY=;
	b=DDJjC5pmZlMqraX4u1WAHelDq+b0Tuc2tvlJSpKUTLVJTglHkjTywyqroEyHyFKsgT7
	/TmWjHCXds6euDdRM5DdJHpFyPvlmzuP/bkH2JWmL84+RA1OeGuS3Egt9NmcVGCkVl8Nm
	xD1rigHScfa2C0M54BzL/0ClEkd/aLMOBoo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (fruni mo19) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C0395co1AKitEG ;
	Fri, 10 Feb 2012 22:28:40 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8ED9818637; Fri, 10 Feb 2012 22:28:46 +0100 (CET)
Date: Fri, 10 Feb 2012 22:28:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120210212846.GA31185@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F34F96602000078000722DA@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> >>> On 09.02.12 at 19:02, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Jan 30, Jan Beulich wrote:
> > 
> >> Below/attached a draft patch (compile tested only), handling save/
> >> restore of the bank count, but not allowing for a config setting to
> >> specify its initial value (yet).
> > 
> > Does it take more than just applying this patch for src+dst host and
> > migrate a hvm guest? I see no difference, the mce warning is still
> > there.
> 
> No, it shouldn't require anything else. Could you add a printk() each
> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
> (and at once checking that they actually get executed? I was under
> the impression that adding save records for HVM is a simple drop-in
> exercise these days...

These functions are called for dom0, but not for domU. And as a result
arch.nr_vmce_banks remains zero. I assume the guest needs to be
initialized in some way as well, and that does not happen?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 21:29:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 21: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.xensource.com>)
	id 1Rvy1Y-0002Xc-U7; Fri, 10 Feb 2012 21:28:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rvy1W-0002XX-2p
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 21:28:54 +0000
Received: from [85.158.139.83:17844] by server-10.bemta-5.messagelabs.com id
	17/6E-26909-51C853F4; Fri, 10 Feb 2012 21:28:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328909332!14603633!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDIwMDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12309 invoked from network); 10 Feb 2012 21:28:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Feb 2012 21:28:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1328909332; l=1016;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=IC7jDq3hQiV1jms49XIyNKmfOlY=;
	b=DDJjC5pmZlMqraX4u1WAHelDq+b0Tuc2tvlJSpKUTLVJTglHkjTywyqroEyHyFKsgT7
	/TmWjHCXds6euDdRM5DdJHpFyPvlmzuP/bkH2JWmL84+RA1OeGuS3Egt9NmcVGCkVl8Nm
	xD1rigHScfa2C0M54BzL/0ClEkd/aLMOBoo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhy0NFa8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-069-036.pools.arcor-ip.net [88.65.69.36])
	by smtp.strato.de (fruni mo19) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C0395co1AKitEG ;
	Fri, 10 Feb 2012 22:28:40 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8ED9818637; Fri, 10 Feb 2012 22:28:46 +0100 (CET)
Date: Fri, 10 Feb 2012 22:28:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120210212846.GA31185@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F34F96602000078000722DA@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> >>> On 09.02.12 at 19:02, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Jan 30, Jan Beulich wrote:
> > 
> >> Below/attached a draft patch (compile tested only), handling save/
> >> restore of the bank count, but not allowing for a config setting to
> >> specify its initial value (yet).
> > 
> > Does it take more than just applying this patch for src+dst host and
> > migrate a hvm guest? I see no difference, the mce warning is still
> > there.
> 
> No, it shouldn't require anything else. Could you add a printk() each
> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
> (and at once checking that they actually get executed? I was under
> the impression that adding save records for HVM is a simple drop-in
> exercise these days...

These functions are called for dom0, but not for domU. And as a result
arch.nr_vmce_banks remains zero. I assume the guest needs to be
initialized in some way as well, and that does not happen?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 22:02:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 22:02:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvyXJ-0002tB-1R; Fri, 10 Feb 2012 22:01:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvyXH-0002t6-0X
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 22:01:43 +0000
Received: from [85.158.139.83:25826] by server-12.bemta-5.messagelabs.com id
	4F/F6-30830-6C3953F4; Fri, 10 Feb 2012 22:01:42 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328911300!14590109!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18143 invoked from network); 10 Feb 2012 22:01:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 22:01:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvyXE-0002Co-2r
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:01:40 -0800
Date: Fri, 10 Feb 2012 14:01:40 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328911300080-5473881.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
	<alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have redo...

Install precise daily build 64 bit with this config:
------------------------------------------------------------------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
'/dev/scd0,raw,hdb,ro,cdrom']
boot='d'
xen_platform_pci=1
device_model_version='qemu-xen'
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
stdvga=0
sdl=0
------------------------------------------------------------------------------
Vnc is working but have refresh heavy lag and and some partial refresh
problem (I not know good english for explain good), , is near unusable,
network now seem to be working.

After I change boot to 'c', vnc same problem.

Nothing on log about, and vnc on PV domU work correctly.

I tried also with qemu traditional and the mouse is not working (is lock on
center), performance problem persist but there aren't partial image refresh
problem.

About spice need compiled as default, I'll try to do the patch for the
missing parts in build and xl and xen requirements in readme.

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5473881.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 22:02:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 22:02:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RvyXJ-0002tB-1R; Fri, 10 Feb 2012 22:01:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvyXH-0002t6-0X
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 22:01:43 +0000
Received: from [85.158.139.83:25826] by server-12.bemta-5.messagelabs.com id
	4F/F6-30830-6C3953F4; Fri, 10 Feb 2012 22:01:42 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328911300!14590109!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18143 invoked from network); 10 Feb 2012 22:01:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 22:01:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RvyXE-0002Co-2r
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 14:01:40 -0800
Date: Fri, 10 Feb 2012 14:01:40 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1328911300080-5473881.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
	<alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have redo...

Install precise daily build 64 bit with this config:
------------------------------------------------------------------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
'/dev/scd0,raw,hdb,ro,cdrom']
boot='d'
xen_platform_pci=1
device_model_version='qemu-xen'
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
stdvga=0
sdl=0
------------------------------------------------------------------------------
Vnc is working but have refresh heavy lag and and some partial refresh
problem (I not know good english for explain good), , is near unusable,
network now seem to be working.

After I change boot to 'c', vnc same problem.

Nothing on log about, and vnc on PV domU work correctly.

I tried also with qemu traditional and the mouse is not working (is lock on
center), performance problem persist but there aren't partial image refresh
problem.

About spice need compiled as default, I'll try to do the patch for the
missing parts in build and xl and xen requirements in readme.

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5473881.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 23:41:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 23: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.xensource.com>)
	id 1Rw05C-0003gd-GB; Fri, 10 Feb 2012 23:40:50 +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 1Rw05B-0003gV-0L
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 23:40:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328917193!52277909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18533 invoked from network); 10 Feb 2012 23:39:53 -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;
	10 Feb 2012 23:39:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,399,1325462400"; d="scan'208";a="10633517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 23:40:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 23:40:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rw055-0008AW-Pu;
	Fri, 10 Feb 2012 23:40:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rw055-00085W-Og;
	Fri, 10 Feb 2012 23:40:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11934-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 23:40:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11934: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11934 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11934/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xl-winxpsp3-vcpus1  9 guest-localmigrate  fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      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-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0dcb9d1e7b55
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavila.org>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tim Deegan <tjd-xen@phlegethon.org>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 683 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 10 23:41:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 10 Feb 2012 23: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.xensource.com>)
	id 1Rw05C-0003gd-GB; Fri, 10 Feb 2012 23:40:50 +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 1Rw05B-0003gV-0L
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 23:40:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328917193!52277909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18533 invoked from network); 10 Feb 2012 23:39:53 -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;
	10 Feb 2012 23:39:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,399,1325462400"; d="scan'208";a="10633517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2012 23:40:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 10 Feb 2012 23:40:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rw055-0008AW-Pu;
	Fri, 10 Feb 2012 23:40:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rw055-00085W-Og;
	Fri, 10 Feb 2012 23:40:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11934-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 10 Feb 2012 23:40:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11934: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11934 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11934/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 11904
 test-amd64-i386-xl-winxpsp3-vcpus1  9 guest-localmigrate  fail REGR. vs. 11904
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 11904
 test-i386-i386-win            7 windows-install           fail REGR. vs. 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      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-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0dcb9d1e7b55
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavila.org>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tim Deegan <tjd-xen@phlegethon.org>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 683 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 04:29:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 04: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.xensource.com>)
	id 1Rw4Zu-0003PF-Tk; Sat, 11 Feb 2012 04:28:50 +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 1Rw4Zt-0003PA-Hr
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 04:28:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328934505!65395143!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26976 invoked from network); 11 Feb 2012 04:28:25 -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;
	11 Feb 2012 04:28:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,399,1325462400"; d="scan'208";a="10634655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2012 04:28:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 11 Feb 2012 04:28:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rw4Zr-0001UA-Lp;
	Sat, 11 Feb 2012 04:28:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rw4Zr-0004Ju-Kz;
	Sat, 11 Feb 2012 04:28:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11937-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 11 Feb 2012 04:28:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11937: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11937 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11937/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  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-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavila.org>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tim Deegan <tjd-xen@phlegethon.org>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=9ad1e42c341b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9ad1e42c341b
+ branch=xen-unstable
+ revision=9ad1e42c341b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 9ad1e42c341b 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 37 changesets with 149 changes to 92 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 04:29:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 04: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.xensource.com>)
	id 1Rw4Zu-0003PF-Tk; Sat, 11 Feb 2012 04:28:50 +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 1Rw4Zt-0003PA-Hr
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 04:28:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328934505!65395143!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26976 invoked from network); 11 Feb 2012 04:28:25 -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;
	11 Feb 2012 04:28:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,399,1325462400"; d="scan'208";a="10634655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2012 04:28:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 11 Feb 2012 04:28:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rw4Zr-0001UA-Lp;
	Sat, 11 Feb 2012 04:28:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rw4Zr-0004Ju-Kz;
	Sat, 11 Feb 2012 04:28:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11937-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 11 Feb 2012 04:28:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11937: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11937 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11937/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11904

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  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-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9fc810bb8145

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavila.org>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@lagarcavilla>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Diego Ongaro <diego.ongaro@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  hongkaixing <hongkaixing@huawei.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  shizhen <bicky.shi@huawei.com>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tim Deegan <tjd-xen@phlegethon.org>
  Wei Liu <wei.liu2@citrix.com>
  Yongjie Ren <yongjie.ren@intel.com>
  Zhigang Wang <zhigang.x.wang@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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=9ad1e42c341b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9ad1e42c341b
+ branch=xen-unstable
+ revision=9ad1e42c341b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 9ad1e42c341b 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 37 changesets with 149 changes to 92 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 07:40:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 07:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rw7Z1-0006RU-9u; Sat, 11 Feb 2012 07:40:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rw7Yy-0006RL-NZ
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 07:40:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328945998!12933855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 940 invoked from network); 11 Feb 2012 07:39:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 07:39:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,400,1325462400"; d="scan'208";a="10635368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2012 07:39:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 11 Feb 2012 07:39:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rw7Yr-0002gE-FG;
	Sat, 11 Feb 2012 07:39:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rw7Yr-0003mv-BL;
	Sat, 11 Feb 2012 07:39:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11942-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 11 Feb 2012 07:39:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11942: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11942 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11942/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11937
 build-amd64-oldkern           4 xen-build                   fail pass in 11937
 build-amd64                   4 xen-build                   fail pass in 11937

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11937

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-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-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-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-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11937 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11937 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11937 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11937 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11937 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11937 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11937 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11937 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11937 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11937 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11937 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11937 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11937 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11937 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11937 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11937 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11937 never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9ad1e42c341b

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 07:40:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 07:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rw7Z1-0006RU-9u; Sat, 11 Feb 2012 07:40:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rw7Yy-0006RL-NZ
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 07:40:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328945998!12933855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 940 invoked from network); 11 Feb 2012 07:39:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 07:39:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,400,1325462400"; d="scan'208";a="10635368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2012 07:39:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 11 Feb 2012 07:39:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rw7Yr-0002gE-FG;
	Sat, 11 Feb 2012 07:39:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rw7Yr-0003mv-BL;
	Sat, 11 Feb 2012 07:39:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11942-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 11 Feb 2012 07:39:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11942: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11942 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11942/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11937
 build-amd64-oldkern           4 xen-build                   fail pass in 11937
 build-amd64                   4 xen-build                   fail pass in 11937

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11937

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-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-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-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-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11937 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11937 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11937 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11937 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11937 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11937 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11937 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11937 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11937 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11937 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11937 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11937 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11937 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11937 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11937 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11937 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11937 never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9ad1e42c341b

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 11:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 11:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwB82-0000lq-8G; Sat, 11 Feb 2012 11:28:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nupurghatnekar@gmail.com>) id 1RwB7y-0000ll-Mw
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 11:28:27 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328959651!62446692!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, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: , surbl: (ASYNC_NO)
	c3VyYmxfcmVjaGVja19kZWxheTogNDg0MzMwMyAoYWJhbmRvbmVkOiB
	hc2VlbXNldGhpLndvcmRw\ncmVzcy5jb20p\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23220 invoked from network); 11 Feb 2012 11:27:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 11:27:31 -0000
Received: by wibhm2 with SMTP id hm2so10544249wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 03:28:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=TVfbz7YkxvWh8v+q/+14VGQp8HYUhYUktczx+eHzoEU=;
	b=gRyHMnCwRIaH2eacae/vp+IXR4+5TiPUjgyUq7CKeDikyFHv807/oJLwEppXzA0ATH
	IpM9OSlCgVfVwjhqARSOAzXet4urU9ZF6/peTwHklwxk0EhYIcRQtEFmo+bB6vjjc1y4
	PEMR1dnb9KMUH4WNY8yR+hOWB0VeLU2uun5Lw=
MIME-Version: 1.0
Received: by 10.216.138.234 with SMTP id a84mr4699083wej.40.1328959699088;
	Sat, 11 Feb 2012 03:28:19 -0800 (PST)
Received: by 10.180.106.72 with HTTP; Sat, 11 Feb 2012 03:28:19 -0800 (PST)
Date: Sat, 11 Feb 2012 16:58:19 +0530
Message-ID: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Setting up an Event Channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0611271552646939759=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0611271552646939759==
Content-Type: multipart/alternative; boundary=0016e6d7755cc8f61f04b8ae8a7e

--0016e6d7755cc8f61f04b8ae8a7e
Content-Type: text/plain; charset=UTF-8

I have been trying to setup an event channel. Following this blog
http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/

But few of the functions used seem deprecated.
Any pointers as to how to progress?

-- 

Nupur Ghatnekar

--0016e6d7755cc8f61f04b8ae8a7e
Content-Type: text/html; charset=UTF-8

I have been trying to setup an event channel. Following this blog <a href="http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/">http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/</a><br>
<br>But few of the functions used seem deprecated. <br>Any pointers as to how to progress?<br clear="all"><br>-- <br><br>Nupur Ghatnekar<br>

--0016e6d7755cc8f61f04b8ae8a7e--


--===============0611271552646939759==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0611271552646939759==--


From xen-devel-bounces@lists.xensource.com Sat Feb 11 11:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 11:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwB82-0000lq-8G; Sat, 11 Feb 2012 11:28:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nupurghatnekar@gmail.com>) id 1RwB7y-0000ll-Mw
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 11:28:27 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328959651!62446692!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, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: , surbl: (ASYNC_NO)
	c3VyYmxfcmVjaGVja19kZWxheTogNDg0MzMwMyAoYWJhbmRvbmVkOiB
	hc2VlbXNldGhpLndvcmRw\ncmVzcy5jb20p\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23220 invoked from network); 11 Feb 2012 11:27:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 11:27:31 -0000
Received: by wibhm2 with SMTP id hm2so10544249wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 03:28:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=TVfbz7YkxvWh8v+q/+14VGQp8HYUhYUktczx+eHzoEU=;
	b=gRyHMnCwRIaH2eacae/vp+IXR4+5TiPUjgyUq7CKeDikyFHv807/oJLwEppXzA0ATH
	IpM9OSlCgVfVwjhqARSOAzXet4urU9ZF6/peTwHklwxk0EhYIcRQtEFmo+bB6vjjc1y4
	PEMR1dnb9KMUH4WNY8yR+hOWB0VeLU2uun5Lw=
MIME-Version: 1.0
Received: by 10.216.138.234 with SMTP id a84mr4699083wej.40.1328959699088;
	Sat, 11 Feb 2012 03:28:19 -0800 (PST)
Received: by 10.180.106.72 with HTTP; Sat, 11 Feb 2012 03:28:19 -0800 (PST)
Date: Sat, 11 Feb 2012 16:58:19 +0530
Message-ID: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Setting up an Event Channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0611271552646939759=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0611271552646939759==
Content-Type: multipart/alternative; boundary=0016e6d7755cc8f61f04b8ae8a7e

--0016e6d7755cc8f61f04b8ae8a7e
Content-Type: text/plain; charset=UTF-8

I have been trying to setup an event channel. Following this blog
http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/

But few of the functions used seem deprecated.
Any pointers as to how to progress?

-- 

Nupur Ghatnekar

--0016e6d7755cc8f61f04b8ae8a7e
Content-Type: text/html; charset=UTF-8

I have been trying to setup an event channel. Following this blog <a href="http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/">http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/</a><br>
<br>But few of the functions used seem deprecated. <br>Any pointers as to how to progress?<br clear="all"><br>-- <br><br>Nupur Ghatnekar<br>

--0016e6d7755cc8f61f04b8ae8a7e--


--===============0611271552646939759==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0611271552646939759==--


From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIys-0004i3-Rq; Sat, 11 Feb 2012 19:51:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyq-0004gU-Gs
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:32 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24273 invoked from network); 11 Feb 2012 19:51:26 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:26 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=oFyCcYI3FG/jaKOMIgP7EIQP/Ro1ZJ5tgegOvmd3lMw=;
	b=qFSYOGr4OhV1xt3do8yqHkY2Wl+Aa8XkzoNegTf4l43covq6J7ARmbxHOa7agbg/X4
	HIcsar9mOM4vZfPQSCwerelWuKIcICl1nMbiACbsnk2gaM0d3uTT1gaUu5oFXX7q75yd
	Y3mHMz4b+2LrKvHWdixfgpEqg6WijdmwzvWp0=
Received: by 10.180.107.2 with SMTP id gy2mr67470wib.12.1328989886414;
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:02 +0000
Message-Id: <82d0187e1ef4edffc22f75131b03ca30492a388c.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 2/5] hvmloader: Allow the mkhex command to
	take several file arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/mkhex |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/hvmloader/mkhex b/tools/firmware/hvmloader/mkhex
index 4517e36..cb21257 100755
--- a/tools/firmware/hvmloader/mkhex
+++ b/tools/firmware/hvmloader/mkhex
@@ -21,6 +21,7 @@
 #
 
 echo "unsigned $1[] = {"
-od -v -t x $2 | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
+shift
+od -v -t x $@ | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
 echo "};"
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIys-0004i3-Rq; Sat, 11 Feb 2012 19:51:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyq-0004gU-Gs
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:32 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24273 invoked from network); 11 Feb 2012 19:51:26 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:26 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=oFyCcYI3FG/jaKOMIgP7EIQP/Ro1ZJ5tgegOvmd3lMw=;
	b=qFSYOGr4OhV1xt3do8yqHkY2Wl+Aa8XkzoNegTf4l43covq6J7ARmbxHOa7agbg/X4
	HIcsar9mOM4vZfPQSCwerelWuKIcICl1nMbiACbsnk2gaM0d3uTT1gaUu5oFXX7q75yd
	Y3mHMz4b+2LrKvHWdixfgpEqg6WijdmwzvWp0=
Received: by 10.180.107.2 with SMTP id gy2mr67470wib.12.1328989886414;
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:02 +0000
Message-Id: <82d0187e1ef4edffc22f75131b03ca30492a388c.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 2/5] hvmloader: Allow the mkhex command to
	take several file arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/mkhex |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/firmware/hvmloader/mkhex b/tools/firmware/hvmloader/mkhex
index 4517e36..cb21257 100755
--- a/tools/firmware/hvmloader/mkhex
+++ b/tools/firmware/hvmloader/mkhex
@@ -21,6 +21,7 @@
 #
 
 echo "unsigned $1[] = {"
-od -v -t x $2 | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
+shift
+od -v -t x $@ | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
 echo "};"
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyt-0004iK-89; Sat, 11 Feb 2012 19:51:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyr-0004gq-F6
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:33 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!3
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24288 invoked from network); 11 Feb 2012 19:51:27 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:27 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=c/x2obeC5OQ7zDkFSq8NV8zHJYR7MXAHqdqRgS07+9Y=;
	b=jDGBFzHLyLt7e5J8nn8N0DDBwq3twL+XIg3EZNLZ95se6HN69h3kvxcDrLgZglk9ze
	tirvfvoc46G8z/17LlnD7NcORuRpDJs8ZkVaT0hvS/vB1+0F2QqfSbLkmWcM5nyh0AxY
	0c5KtYy3xKMsjKBFPjI5uIrgOIu6p/YWrdj0c=
Received: by 10.180.90.225 with SMTP id bz1mr10097943wib.5.1328989887342;
	Sat, 11 Feb 2012 11:51:27 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:03 +0000
Message-Id: <68dc4b371841c649d1dcff9cca84295e9a24dc65.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 3/5] firmware: Use mkhex from hvmloader
	directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

To remain consistent with how other ROMs are built into hvmloader,
call mkhex on etherboot ROMs from the hvmloader directory, instead of
the etherboot directory. In other words, eb-roms.h is not used any more.

Introduce ETHERBOOT_NICS config option to choose which ROMs should be
built (kept rtl8139 and 8086100e per default as before).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                         |    2 ++
 tools/firmware/etherboot/Config   |    2 --
 tools/firmware/etherboot/Makefile |   13 +++----------
 tools/firmware/hvmloader/Makefile |    9 ++++++---
 4 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/Config.mk b/Config.mk
index e2dc4b9..42508b8 100644
--- a/Config.mk
+++ b/Config.mk
@@ -222,6 +222,8 @@ endif
 QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
+ETHERBOOT_NICS ?= rtl8139 8086100e
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/etherboot/Config b/tools/firmware/etherboot/Config
index 143914f..69963b9 100644
--- a/tools/firmware/etherboot/Config
+++ b/tools/firmware/etherboot/Config
@@ -1,6 +1,4 @@
 
-NICS = rtl8139 8086100e
-
 CFLAGS += -UPXE_DHCP_STRICT
 CFLAGS += -DPXE_DHCP_STRICT
 
diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index c09140e..a195888 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -17,23 +17,16 @@ IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 D=ipxe
 T=ipxe.tar.gz
 
-ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(NICS)))
+ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
 
 .NOTPARALLEL:
 
 .PHONY: all
-all: eb-roms.h
+all: $(ROMS)
 
 %.rom: $D/src/arch/i386/Makefile
 	$(MAKE) -C $D/src bin/$(*F).rom
 
-eb-roms.h.new: $(ROMS)
-	cat $^ | ../hvmloader/mkhex etherboot >$@
-
-eb-roms.h: Config
-	$(MAKE) NO_WERROR=1 $@.new
-	mv -f $@.new $@
-
 $T:
 	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
 		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
@@ -56,7 +49,7 @@ $D/src/bin/NIC: $D/src/arch/i386/Makefile
 
 .PHONY: clean
 clean:
-	rm -rf $D $D.git *~ eb-roms.h _$T $T
+	rm -rf $D $D.git *~ _$T $T
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index e82146a..1ea32db 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -58,6 +58,8 @@ else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
 
+ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+
 .PHONY: all
 all: subdirs-all
 	$(MAKE) hvmloader
@@ -70,7 +72,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
+roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
@@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
 	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
 	echo "#endif" >> $@.new
 endif
-
+ifneq ($(ETHERBOOT_ROMS),)
 	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-	cat ../etherboot/eb-roms.h >> $@.new
+	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
 	echo "#endif" >> $@.new
+endif
 
 	mv $@.new $@
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyt-0004iK-89; Sat, 11 Feb 2012 19:51:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyr-0004gq-F6
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:33 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!3
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24288 invoked from network); 11 Feb 2012 19:51:27 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:27 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=c/x2obeC5OQ7zDkFSq8NV8zHJYR7MXAHqdqRgS07+9Y=;
	b=jDGBFzHLyLt7e5J8nn8N0DDBwq3twL+XIg3EZNLZ95se6HN69h3kvxcDrLgZglk9ze
	tirvfvoc46G8z/17LlnD7NcORuRpDJs8ZkVaT0hvS/vB1+0F2QqfSbLkmWcM5nyh0AxY
	0c5KtYy3xKMsjKBFPjI5uIrgOIu6p/YWrdj0c=
Received: by 10.180.90.225 with SMTP id bz1mr10097943wib.5.1328989887342;
	Sat, 11 Feb 2012 11:51:27 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:26 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:03 +0000
Message-Id: <68dc4b371841c649d1dcff9cca84295e9a24dc65.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 3/5] firmware: Use mkhex from hvmloader
	directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

To remain consistent with how other ROMs are built into hvmloader,
call mkhex on etherboot ROMs from the hvmloader directory, instead of
the etherboot directory. In other words, eb-roms.h is not used any more.

Introduce ETHERBOOT_NICS config option to choose which ROMs should be
built (kept rtl8139 and 8086100e per default as before).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                         |    2 ++
 tools/firmware/etherboot/Config   |    2 --
 tools/firmware/etherboot/Makefile |   13 +++----------
 tools/firmware/hvmloader/Makefile |    9 ++++++---
 4 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/Config.mk b/Config.mk
index e2dc4b9..42508b8 100644
--- a/Config.mk
+++ b/Config.mk
@@ -222,6 +222,8 @@ endif
 QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
+ETHERBOOT_NICS ?= rtl8139 8086100e
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/etherboot/Config b/tools/firmware/etherboot/Config
index 143914f..69963b9 100644
--- a/tools/firmware/etherboot/Config
+++ b/tools/firmware/etherboot/Config
@@ -1,6 +1,4 @@
 
-NICS = rtl8139 8086100e
-
 CFLAGS += -UPXE_DHCP_STRICT
 CFLAGS += -DPXE_DHCP_STRICT
 
diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index c09140e..a195888 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -17,23 +17,16 @@ IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 D=ipxe
 T=ipxe.tar.gz
 
-ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(NICS)))
+ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
 
 .NOTPARALLEL:
 
 .PHONY: all
-all: eb-roms.h
+all: $(ROMS)
 
 %.rom: $D/src/arch/i386/Makefile
 	$(MAKE) -C $D/src bin/$(*F).rom
 
-eb-roms.h.new: $(ROMS)
-	cat $^ | ../hvmloader/mkhex etherboot >$@
-
-eb-roms.h: Config
-	$(MAKE) NO_WERROR=1 $@.new
-	mv -f $@.new $@
-
 $T:
 	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
 		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
@@ -56,7 +49,7 @@ $D/src/bin/NIC: $D/src/arch/i386/Makefile
 
 .PHONY: clean
 clean:
-	rm -rf $D $D.git *~ eb-roms.h _$T $T
+	rm -rf $D $D.git *~ _$T $T
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index e82146a..1ea32db 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -58,6 +58,8 @@ else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
 
+ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+
 .PHONY: all
 all: subdirs-all
 	$(MAKE) hvmloader
@@ -70,7 +72,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
+roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
@@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
 	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
 	echo "#endif" >> $@.new
 endif
-
+ifneq ($(ETHERBOOT_ROMS),)
 	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
-	cat ../etherboot/eb-roms.h >> $@.new
+	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
 	echo "#endif" >> $@.new
+endif
 
 	mv $@.new $@
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyq-0004hH-90; Sat, 11 Feb 2012 19:51:32 +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 1RwIyo-0004h3-PE
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:31 +0000
Received: from [85.158.139.83:52443] by server-11.bemta-5.messagelabs.com id
	95/DC-13907-2C6C63F4; Sat, 11 Feb 2012 19:51:30 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328989885!14678281!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20730 invoked from network); 11 Feb 2012 19:51:28 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:28 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so11480928wer.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=D6kIYNSVmp7sPrWl59PMgJtZCVS4eWYjOIBvIL3U9nI=;
	b=VyLX2/bqlseCuJTo7GZGBSdFrajzsXcd0eIxmqZrE/aby+xXkPKHA3b9jhQYHAD8+4
	BTPmVcudq3Y8BtHKz0wqTqClnaHxzYqlMDHem/WGUAMx1yXyvlX0b2PKfsohq1Wj3ChR
	wfnx7Nfm/tuFS1cek7U1qbTT0gZghh+KU1UvY=
Received: by 10.180.81.66 with SMTP id y2mr15963207wix.20.1328989888507;
	Sat, 11 Feb 2012 11:51:28 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:27 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:04 +0000
Message-Id: <bcc9b695f6ae5a4d915116f154d2b5e23fbf5865.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 4/5] hvmloader: Move option ROM loading into
	a separate optionnal file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Make load_rom field in struct bios_config an optionnal callback rather
than a boolean value. It allow BIOS specific code to implement it's own
option ROM loading methods.

Facilities to scan PCI devices, extract an deploy ROMs are moved into
a separate file that can be compiled optionnaly.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile     |    2 +-
 tools/firmware/hvmloader/config.h     |    3 +-
 tools/firmware/hvmloader/hvmloader.c  |  218 +--------------------------------
 tools/firmware/hvmloader/option_rom.h |    7 +
 tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
 tools/firmware/hvmloader/seabios.c    |    5 +-
 7 files changed, 259 insertions(+), 228 deletions(-)
 create mode 100644 tools/firmware/hvmloader/optionroms.c

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 1ea32db..5a5ee41 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += 32bitbios_support.o rombios.o
+OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 9cac9c1..1f80263 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -18,8 +18,7 @@ struct bios_config {
     unsigned int bios_address;
 
     /* ROMS */
-    int load_roms;
-    unsigned int optionrom_start, optionrom_end;
+    void (*load_roms)(void);
 
     void (*bios_load)(const struct bios_config *config);
 
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f120ffe..ad50189 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -24,16 +24,11 @@
 #include "hypercall.h"
 #include "config.h"
 #include "pci_regs.h"
-#include "option_rom.h"
 #include "apic_regs.h"
 #include "acpi/acpi2_0.h"
 #include <xen/version.h>
 #include <xen/hvm/params.h>
 
-#define ROM_INCLUDE_VGABIOS
-#define ROM_INCLUDE_ETHERBOOT
-#include "roms.inc"
-
 asm (
     "    .text                       \n"
     "    .globl _start               \n"
@@ -147,169 +142,6 @@ static void init_hypercalls(void)
     printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0xffff, extraversion);
 }
 
-/*
- * Scan the list of Option ROMs at @roms for one which supports 
- * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
- * copy it to @dest and return its size rounded up to a multiple 2kB. This
- * function will not copy ROMs beyond address option_rom_end.
- */
-#define round_option_rom(x) (((x) + 2047) & ~2047)
-static int scan_option_rom(
-    unsigned int option_rom_end,
-    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
-    void *roms, uint32_t dest)
-{
-    struct option_rom_header *rom;
-    struct option_rom_pnp_header *pnph;
-    struct option_rom_pci_header *pcih;
-    uint8_t csum;
-    int i;
-
-    static uint32_t orom_ids[64];
-    static int nr_roms;
-
-    /* Avoid duplicate ROMs. */
-    for ( i = 0; i < nr_roms; i++ )
-        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
-            return 0;
-
-    rom = roms;
-    for ( ; ; )
-    {
-        /* Invalid signature means we're out of option ROMs. */
-        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
-             (rom->rom_size == 0) )
-            break;
-
-        /* Invalid checksum means we're out of option ROMs. */
-        csum = 0;
-        for ( i = 0; i < (rom->rom_size * 512); i++ )
-            csum += ((uint8_t *)rom)[i];
-        if ( csum != 0 )
-            break;
-
-        /* Check the PCI PnP header (if any) for a match. */
-        pcih = (struct option_rom_pci_header *)
-            ((char *)rom + rom->pci_header_offset);
-        if ( (rom->pci_header_offset != 0) &&
-             !strncmp((char *)pcih->signature, "PCIR", 4) &&
-             (pcih->vendor_id == vendor_id) &&
-             (pcih->device_id == device_id) )
-            goto found;
-
-        rom = (struct option_rom_header *)
-            ((char *)rom + rom->rom_size * 512);
-    }
-
-    return 0;
-
- found:
-    /* Find the PnP expansion header (if any). */
-    pnph = ((rom->expansion_header_offset != 0)
-            ? ((struct option_rom_pnp_header *)
-               ((char *)rom + rom->expansion_header_offset))
-            : ((struct option_rom_pnp_header *)NULL));
-    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
-        pnph = ((pnph->next_header_offset != 0)
-                ? ((struct option_rom_pnp_header *)
-                   ((char *)rom + pnph->next_header_offset))
-                : ((struct option_rom_pnp_header *)NULL));
-
-    printf("Loading PCI Option ROM ...\n");
-    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
-        printf(" - Manufacturer: %s\n",
-               (char *)rom + pnph->manufacturer_name_offset);
-    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
-        printf(" - Product name: %s\n",
-               (char *)rom + pnph->product_name_offset);
-
-    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
-    {
-        printf("Option ROM size %x exceeds available space\n",
-               rom->rom_size * 512);
-        return 0;
-    }
-
-    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
-    memcpy((void *)dest, rom, rom->rom_size * 512);
-    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
-    return round_option_rom(rom->rom_size * 512 + 1);
-}
-
-/*
- * Scan the PCI bus for the first NIC supported by etherboot, and copy
- * the corresponding rom data to *copy_rom_dest. Returns the length of the
- * selected rom, or 0 if no NIC found.
- */
-static int scan_etherboot_nic(unsigned int option_rom_end,
-                              uint32_t copy_rom_dest)
-{
-    uint16_t class, vendor_id, device_id, devfn;
-    int rom_size = 0;
-
-    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
-    {
-        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
-        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
-        device_id = pci_readw(devfn, PCI_DEVICE_ID);
-
-        /* We're only interested in NICs. */
-        if ( (vendor_id != 0xffff) &&
-             (device_id != 0xffff) &&
-             (class == 0x0200) )
-            rom_size = scan_option_rom(
-                option_rom_end,
-                devfn, vendor_id, device_id, etherboot, copy_rom_dest);
-    }
-
-    return rom_size;
-}
-
-/*
- * Scan the PCI bus for the devices that have an option ROM, and copy
- * the corresponding rom data to rom_phys_addr.
- */
-static int pci_load_option_roms(unsigned int option_rom_end,
-                                uint32_t rom_base_addr)
-{
-    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
-    uint16_t vendor_id, device_id, devfn, class;
-
-    for ( devfn = 0; devfn < 256; devfn++ )
-    {
-        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
-        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
-        device_id = pci_readw(devfn, PCI_DEVICE_ID);
-
-        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
-            continue;
-
-        /*
-         * Currently only scan options from mass storage devices and serial
-         * bus controller (Fibre Channel included).
-         */
-        if ( (class != 0x1) && (class != 0xc) )
-            continue;
-
-        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
-        if ( !option_rom_addr )
-            continue;
-
-        /* Ensure Expansion Bar is enabled before copying */
-        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
-
-        rom_phys_addr += scan_option_rom(
-            option_rom_end,
-            devfn, vendor_id, device_id,
-            (void *)(option_rom_addr & ~2047), rom_phys_addr);
-
-        /* Restore the default original value of Expansion Bar */
-        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
-    }
-
-    return rom_phys_addr - rom_base_addr;
-}
-
 /* Replace possibly erroneous memory-size CMOS fields with correct values. */
 static void cmos_write_memory_size(void)
 {
@@ -421,8 +253,6 @@ static void acpi_enable_sci(void)
 int main(void)
 {
     const struct bios_config *bios;
-    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
-    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
     int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
@@ -471,41 +301,7 @@ int main(void)
     }
 
     if ( bios->load_roms )
-    {
-        switch ( virtual_vga )
-        {
-        case VGA_cirrus:
-            printf("Loading Cirrus VGABIOS ...\n");
-            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
-                   vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
-            vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
-            break;
-        case VGA_std:
-            printf("Loading Standard VGABIOS ...\n");
-            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
-                   vgabios_stdvga, sizeof(vgabios_stdvga));
-            vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
-            break;
-        case VGA_pt:
-            printf("Loading VGABIOS of passthroughed gfx ...\n");
-            vgabios_sz = round_option_rom(
-                (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
-            break;
-        default:
-            printf("No emulated VGA adaptor ...\n");
-            break;
-        }
-
-        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
-        if ( etherboot_phys_addr < bios->optionrom_start )
-            etherboot_phys_addr = bios->optionrom_start;
-        etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
-                                          etherboot_phys_addr);
-
-        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
-        option_rom_sz = pci_load_option_roms(bios->optionrom_end,
-                                             option_rom_phys_addr);
-    }
+        bios->load_roms();
 
     acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
 
@@ -536,18 +332,6 @@ int main(void)
     if ( SCRATCH_PHYSICAL_ADDRESS != scratch_start )
         printf(" %05x-%05lx: Scratch space\n",
                SCRATCH_PHYSICAL_ADDRESS, scratch_start);
-    if ( vgabios_sz )
-        printf(" %05x-%05x: VGA BIOS\n",
-               VGABIOS_PHYSICAL_ADDRESS,
-               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
-    if ( etherboot_sz )
-        printf(" %05x-%05x: Etherboot ROM\n",
-               etherboot_phys_addr,
-               etherboot_phys_addr + etherboot_sz - 1);
-    if ( option_rom_sz )
-        printf(" %05x-%05x: PCI Option ROMs\n",
-               option_rom_phys_addr,
-               option_rom_phys_addr + option_rom_sz - 1);
     printf(" %05x-%05x: Main BIOS\n",
            bios->bios_address,
            bios->bios_address + bios->image_size - 1);
diff --git a/tools/firmware/hvmloader/option_rom.h b/tools/firmware/hvmloader/option_rom.h
index f0c7ec4..1ada3e2 100644
--- a/tools/firmware/hvmloader/option_rom.h
+++ b/tools/firmware/hvmloader/option_rom.h
@@ -47,6 +47,13 @@ struct option_rom_pci_header {
     uint16_t reserved;
 } __attribute__ ((packed));
 
+#define round_option_rom(x) (((x) + 2047) & ~2047)
+int scan_etherboot_nic(unsigned int option_rom_end,
+                       uint32_t copy_rom_dest,
+                       void *etherboot_rom);
+int pci_load_option_roms(unsigned int option_rom_end,
+                         uint32_t rom_base_addr);
+
 #endif /* __HVMLOADER_OPTION_ROM_H__ */
 
 /*
diff --git a/tools/firmware/hvmloader/optionroms.c b/tools/firmware/hvmloader/optionroms.c
new file mode 100644
index 0000000..e35aebc
--- /dev/null
+++ b/tools/firmware/hvmloader/optionroms.c
@@ -0,0 +1,189 @@
+/*
+ * optionroms.c: Option ROM loading support.
+ *
+ * Leendert van Doorn, leendert@watson.ibm.com
+ * Copyright (c) 2005, International Business Machines Corporation.
+ *
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include "config.h"
+#include "option_rom.h"
+#include "util.h"
+#include "pci_regs.h"
+
+/*
+ * Scan the list of Option ROMs at @roms for one which supports 
+ * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
+ * copy it to @dest and return its size rounded up to a multiple 2kB. This
+ * function will not copy ROMs beyond address option_rom_end.
+ */
+static int scan_option_rom(
+    unsigned int option_rom_end,
+    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
+    void *roms, uint32_t dest)
+{
+    struct option_rom_header *rom;
+    struct option_rom_pnp_header *pnph;
+    struct option_rom_pci_header *pcih;
+    uint8_t csum;
+    int i;
+
+    static uint32_t orom_ids[64];
+    static int nr_roms;
+
+    /* Avoid duplicate ROMs. */
+    for ( i = 0; i < nr_roms; i++ )
+        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
+            return 0;
+
+    rom = roms;
+    for ( ; ; )
+    {
+        /* Invalid signature means we're out of option ROMs. */
+        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
+             (rom->rom_size == 0) )
+            break;
+
+        /* Invalid checksum means we're out of option ROMs. */
+        csum = 0;
+        for ( i = 0; i < (rom->rom_size * 512); i++ )
+            csum += ((uint8_t *)rom)[i];
+        if ( csum != 0 )
+            break;
+
+        /* Check the PCI PnP header (if any) for a match. */
+        pcih = (struct option_rom_pci_header *)
+            ((char *)rom + rom->pci_header_offset);
+        if ( (rom->pci_header_offset != 0) &&
+             !strncmp((char *)pcih->signature, "PCIR", 4) &&
+             (pcih->vendor_id == vendor_id) &&
+             (pcih->device_id == device_id) )
+            goto found;
+
+        rom = (struct option_rom_header *)
+            ((char *)rom + rom->rom_size * 512);
+    }
+
+    return 0;
+
+ found:
+    /* Find the PnP expansion header (if any). */
+    pnph = ((rom->expansion_header_offset != 0)
+            ? ((struct option_rom_pnp_header *)
+               ((char *)rom + rom->expansion_header_offset))
+            : ((struct option_rom_pnp_header *)NULL));
+    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
+        pnph = ((pnph->next_header_offset != 0)
+                ? ((struct option_rom_pnp_header *)
+                   ((char *)rom + pnph->next_header_offset))
+                : ((struct option_rom_pnp_header *)NULL));
+
+    printf("Loading PCI Option ROM ...\n");
+    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
+        printf(" - Manufacturer: %s\n",
+               (char *)rom + pnph->manufacturer_name_offset);
+    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
+        printf(" - Product name: %s\n",
+               (char *)rom + pnph->product_name_offset);
+
+    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
+    {
+        printf("Option ROM size %x exceeds available space\n",
+               rom->rom_size * 512);
+        return 0;
+    }
+
+    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
+    memcpy((void *)dest, rom, rom->rom_size * 512);
+    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
+    return round_option_rom(rom->rom_size * 512 + 1);
+}
+
+/*
+ * Scan the PCI bus for the first NIC supported by etherboot, and copy
+ * the corresponding rom data to *copy_rom_dest. Returns the length of the
+ * selected rom, or 0 if no NIC found.
+ */
+int scan_etherboot_nic(unsigned int option_rom_end,
+                       uint32_t copy_rom_dest,
+                       void *etherboot_rom)
+{
+    uint16_t class, vendor_id, device_id, devfn;
+    int rom_size = 0;
+
+    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
+    {
+        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
+        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(devfn, PCI_DEVICE_ID);
+
+        /* We're only interested in NICs. */
+        if ( (vendor_id != 0xffff) &&
+             (device_id != 0xffff) &&
+             (class == 0x0200) )
+            rom_size = scan_option_rom(
+                option_rom_end,
+                devfn, vendor_id, device_id, etherboot_rom, copy_rom_dest);
+    }
+
+    return rom_size;
+}
+
+/*
+ * Scan the PCI bus for the devices that have an option ROM, and copy
+ * the corresponding rom data to rom_phys_addr.
+ */
+int pci_load_option_roms(unsigned int option_rom_end,
+                         uint32_t rom_base_addr)
+{
+    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
+    uint16_t vendor_id, device_id, devfn, class;
+
+    for ( devfn = 0; devfn < 256; devfn++ )
+    {
+        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
+        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(devfn, PCI_DEVICE_ID);
+
+        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
+            continue;
+
+        /*
+         * Currently only scan options from mass storage devices and serial
+         * bus controller (Fibre Channel included).
+         */
+        if ( (class != 0x1) && (class != 0xc) )
+            continue;
+
+        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
+        if ( !option_rom_addr )
+            continue;
+
+        /* Ensure Expansion Bar is enabled before copying */
+        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
+
+        rom_phys_addr += scan_option_rom(
+            option_rom_end,
+            devfn, vendor_id, device_id,
+            (void *)(option_rom_addr & ~2047), rom_phys_addr);
+
+        /* Restore the default original value of Expansion Bar */
+        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
+    }
+
+    return rom_phys_addr - rom_base_addr;
+}
diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
index d5831aa..e0d4182 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -29,10 +29,13 @@
 #include "pci_regs.h"
 #include "util.h"
 #include "hypercall.h"
+#include "option_rom.h"
 
 #include <xen/hvm/params.h>
 
 #define ROM_INCLUDE_ROMBIOS
+#define ROM_INCLUDE_VGABIOS
+#define ROM_INCLUDE_ETHERBOOT
 #include "roms.inc"
 
 #define ROMBIOS_BEGIN          0x000F0000
@@ -64,6 +67,61 @@ static void rombios_setup_bios_info(void)
     memset(info, 0, sizeof(*info));
 }
 
+static void rombios_load_roms(void)
+{
+    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
+    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+
+    switch ( virtual_vga )
+    {
+    case VGA_cirrus:
+        printf("Loading Cirrus VGABIOS ...\n");
+        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
+               vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
+        vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
+        break;
+    case VGA_std:
+        printf("Loading Standard VGABIOS ...\n");
+        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
+               vgabios_stdvga, sizeof(vgabios_stdvga));
+        vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
+        break;
+    case VGA_pt:
+        printf("Loading VGABIOS of passthroughed gfx ...\n");
+        vgabios_sz = round_option_rom(
+            (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+        break;
+    default:
+        printf("No emulated VGA adaptor ...\n");
+        break;
+    }
+
+    etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
+    if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
+        etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
+    etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
+                                      etherboot_phys_addr,
+                                      etherboot);
+
+    option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
+    option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
+                                         option_rom_phys_addr);
+
+    printf("Option ROMs:\n");
+    if ( vgabios_sz )
+        printf(" %05x-%05x: VGA BIOS\n",
+               VGABIOS_PHYSICAL_ADDRESS,
+               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
+    if ( etherboot_sz )
+        printf(" %05x-%05x: Etherboot ROM\n",
+               etherboot_phys_addr,
+               etherboot_phys_addr + etherboot_sz - 1);
+    if ( option_rom_sz )
+        printf(" %05x-%05x: PCI Option ROMs\n",
+               option_rom_phys_addr,
+               option_rom_phys_addr + option_rom_sz - 1);
+}
+
 static void rombios_load(const struct bios_config *config)
 {
     uint32_t bioshigh;
@@ -158,10 +216,7 @@ struct bios_config rombios_config =  {
 
     .bios_address = ROMBIOS_PHYSICAL_ADDRESS,
 
-    .load_roms = 1,
-
-    .optionrom_start = OPTIONROM_PHYSICAL_ADDRESS,
-    .optionrom_end = OPTIONROM_PHYSICAL_END,
+    .load_roms = rombios_load_roms,
 
     .bios_load = rombios_load,
 
diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
index 3045157..15ddf35 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -143,10 +143,7 @@ struct bios_config seabios_config = {
 
     .bios_address = SEABIOS_PHYSICAL_ADDRESS,
 
-    .load_roms = 0,
-
-    .optionrom_start = 0,
-    .optionrom_end = 0,
+    .load_roms = NULL,
 
     .bios_load = NULL,
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyq-0004hH-90; Sat, 11 Feb 2012 19:51:32 +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 1RwIyo-0004h3-PE
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:31 +0000
Received: from [85.158.139.83:52443] by server-11.bemta-5.messagelabs.com id
	95/DC-13907-2C6C63F4; Sat, 11 Feb 2012 19:51:30 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328989885!14678281!2
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20730 invoked from network); 11 Feb 2012 19:51:28 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:28 -0000
Received: by mail-we0-f171.google.com with SMTP id b14so11480928wer.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=D6kIYNSVmp7sPrWl59PMgJtZCVS4eWYjOIBvIL3U9nI=;
	b=VyLX2/bqlseCuJTo7GZGBSdFrajzsXcd0eIxmqZrE/aby+xXkPKHA3b9jhQYHAD8+4
	BTPmVcudq3Y8BtHKz0wqTqClnaHxzYqlMDHem/WGUAMx1yXyvlX0b2PKfsohq1Wj3ChR
	wfnx7Nfm/tuFS1cek7U1qbTT0gZghh+KU1UvY=
Received: by 10.180.81.66 with SMTP id y2mr15963207wix.20.1328989888507;
	Sat, 11 Feb 2012 11:51:28 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:27 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:04 +0000
Message-Id: <bcc9b695f6ae5a4d915116f154d2b5e23fbf5865.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 4/5] hvmloader: Move option ROM loading into
	a separate optionnal file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Make load_rom field in struct bios_config an optionnal callback rather
than a boolean value. It allow BIOS specific code to implement it's own
option ROM loading methods.

Facilities to scan PCI devices, extract an deploy ROMs are moved into
a separate file that can be compiled optionnaly.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile     |    2 +-
 tools/firmware/hvmloader/config.h     |    3 +-
 tools/firmware/hvmloader/hvmloader.c  |  218 +--------------------------------
 tools/firmware/hvmloader/option_rom.h |    7 +
 tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
 tools/firmware/hvmloader/seabios.c    |    5 +-
 7 files changed, 259 insertions(+), 228 deletions(-)
 create mode 100644 tools/firmware/hvmloader/optionroms.c

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 1ea32db..5a5ee41 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += 32bitbios_support.o rombios.o
+OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 9cac9c1..1f80263 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -18,8 +18,7 @@ struct bios_config {
     unsigned int bios_address;
 
     /* ROMS */
-    int load_roms;
-    unsigned int optionrom_start, optionrom_end;
+    void (*load_roms)(void);
 
     void (*bios_load)(const struct bios_config *config);
 
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index f120ffe..ad50189 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -24,16 +24,11 @@
 #include "hypercall.h"
 #include "config.h"
 #include "pci_regs.h"
-#include "option_rom.h"
 #include "apic_regs.h"
 #include "acpi/acpi2_0.h"
 #include <xen/version.h>
 #include <xen/hvm/params.h>
 
-#define ROM_INCLUDE_VGABIOS
-#define ROM_INCLUDE_ETHERBOOT
-#include "roms.inc"
-
 asm (
     "    .text                       \n"
     "    .globl _start               \n"
@@ -147,169 +142,6 @@ static void init_hypercalls(void)
     printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0xffff, extraversion);
 }
 
-/*
- * Scan the list of Option ROMs at @roms for one which supports 
- * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
- * copy it to @dest and return its size rounded up to a multiple 2kB. This
- * function will not copy ROMs beyond address option_rom_end.
- */
-#define round_option_rom(x) (((x) + 2047) & ~2047)
-static int scan_option_rom(
-    unsigned int option_rom_end,
-    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
-    void *roms, uint32_t dest)
-{
-    struct option_rom_header *rom;
-    struct option_rom_pnp_header *pnph;
-    struct option_rom_pci_header *pcih;
-    uint8_t csum;
-    int i;
-
-    static uint32_t orom_ids[64];
-    static int nr_roms;
-
-    /* Avoid duplicate ROMs. */
-    for ( i = 0; i < nr_roms; i++ )
-        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
-            return 0;
-
-    rom = roms;
-    for ( ; ; )
-    {
-        /* Invalid signature means we're out of option ROMs. */
-        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
-             (rom->rom_size == 0) )
-            break;
-
-        /* Invalid checksum means we're out of option ROMs. */
-        csum = 0;
-        for ( i = 0; i < (rom->rom_size * 512); i++ )
-            csum += ((uint8_t *)rom)[i];
-        if ( csum != 0 )
-            break;
-
-        /* Check the PCI PnP header (if any) for a match. */
-        pcih = (struct option_rom_pci_header *)
-            ((char *)rom + rom->pci_header_offset);
-        if ( (rom->pci_header_offset != 0) &&
-             !strncmp((char *)pcih->signature, "PCIR", 4) &&
-             (pcih->vendor_id == vendor_id) &&
-             (pcih->device_id == device_id) )
-            goto found;
-
-        rom = (struct option_rom_header *)
-            ((char *)rom + rom->rom_size * 512);
-    }
-
-    return 0;
-
- found:
-    /* Find the PnP expansion header (if any). */
-    pnph = ((rom->expansion_header_offset != 0)
-            ? ((struct option_rom_pnp_header *)
-               ((char *)rom + rom->expansion_header_offset))
-            : ((struct option_rom_pnp_header *)NULL));
-    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
-        pnph = ((pnph->next_header_offset != 0)
-                ? ((struct option_rom_pnp_header *)
-                   ((char *)rom + pnph->next_header_offset))
-                : ((struct option_rom_pnp_header *)NULL));
-
-    printf("Loading PCI Option ROM ...\n");
-    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
-        printf(" - Manufacturer: %s\n",
-               (char *)rom + pnph->manufacturer_name_offset);
-    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
-        printf(" - Product name: %s\n",
-               (char *)rom + pnph->product_name_offset);
-
-    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
-    {
-        printf("Option ROM size %x exceeds available space\n",
-               rom->rom_size * 512);
-        return 0;
-    }
-
-    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
-    memcpy((void *)dest, rom, rom->rom_size * 512);
-    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
-    return round_option_rom(rom->rom_size * 512 + 1);
-}
-
-/*
- * Scan the PCI bus for the first NIC supported by etherboot, and copy
- * the corresponding rom data to *copy_rom_dest. Returns the length of the
- * selected rom, or 0 if no NIC found.
- */
-static int scan_etherboot_nic(unsigned int option_rom_end,
-                              uint32_t copy_rom_dest)
-{
-    uint16_t class, vendor_id, device_id, devfn;
-    int rom_size = 0;
-
-    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
-    {
-        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
-        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
-        device_id = pci_readw(devfn, PCI_DEVICE_ID);
-
-        /* We're only interested in NICs. */
-        if ( (vendor_id != 0xffff) &&
-             (device_id != 0xffff) &&
-             (class == 0x0200) )
-            rom_size = scan_option_rom(
-                option_rom_end,
-                devfn, vendor_id, device_id, etherboot, copy_rom_dest);
-    }
-
-    return rom_size;
-}
-
-/*
- * Scan the PCI bus for the devices that have an option ROM, and copy
- * the corresponding rom data to rom_phys_addr.
- */
-static int pci_load_option_roms(unsigned int option_rom_end,
-                                uint32_t rom_base_addr)
-{
-    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
-    uint16_t vendor_id, device_id, devfn, class;
-
-    for ( devfn = 0; devfn < 256; devfn++ )
-    {
-        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
-        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
-        device_id = pci_readw(devfn, PCI_DEVICE_ID);
-
-        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
-            continue;
-
-        /*
-         * Currently only scan options from mass storage devices and serial
-         * bus controller (Fibre Channel included).
-         */
-        if ( (class != 0x1) && (class != 0xc) )
-            continue;
-
-        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
-        if ( !option_rom_addr )
-            continue;
-
-        /* Ensure Expansion Bar is enabled before copying */
-        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
-
-        rom_phys_addr += scan_option_rom(
-            option_rom_end,
-            devfn, vendor_id, device_id,
-            (void *)(option_rom_addr & ~2047), rom_phys_addr);
-
-        /* Restore the default original value of Expansion Bar */
-        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
-    }
-
-    return rom_phys_addr - rom_base_addr;
-}
-
 /* Replace possibly erroneous memory-size CMOS fields with correct values. */
 static void cmos_write_memory_size(void)
 {
@@ -421,8 +253,6 @@ static void acpi_enable_sci(void)
 int main(void)
 {
     const struct bios_config *bios;
-    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
-    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
     int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
@@ -471,41 +301,7 @@ int main(void)
     }
 
     if ( bios->load_roms )
-    {
-        switch ( virtual_vga )
-        {
-        case VGA_cirrus:
-            printf("Loading Cirrus VGABIOS ...\n");
-            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
-                   vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
-            vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
-            break;
-        case VGA_std:
-            printf("Loading Standard VGABIOS ...\n");
-            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
-                   vgabios_stdvga, sizeof(vgabios_stdvga));
-            vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
-            break;
-        case VGA_pt:
-            printf("Loading VGABIOS of passthroughed gfx ...\n");
-            vgabios_sz = round_option_rom(
-                (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
-            break;
-        default:
-            printf("No emulated VGA adaptor ...\n");
-            break;
-        }
-
-        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
-        if ( etherboot_phys_addr < bios->optionrom_start )
-            etherboot_phys_addr = bios->optionrom_start;
-        etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
-                                          etherboot_phys_addr);
-
-        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
-        option_rom_sz = pci_load_option_roms(bios->optionrom_end,
-                                             option_rom_phys_addr);
-    }
+        bios->load_roms();
 
     acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
 
@@ -536,18 +332,6 @@ int main(void)
     if ( SCRATCH_PHYSICAL_ADDRESS != scratch_start )
         printf(" %05x-%05lx: Scratch space\n",
                SCRATCH_PHYSICAL_ADDRESS, scratch_start);
-    if ( vgabios_sz )
-        printf(" %05x-%05x: VGA BIOS\n",
-               VGABIOS_PHYSICAL_ADDRESS,
-               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
-    if ( etherboot_sz )
-        printf(" %05x-%05x: Etherboot ROM\n",
-               etherboot_phys_addr,
-               etherboot_phys_addr + etherboot_sz - 1);
-    if ( option_rom_sz )
-        printf(" %05x-%05x: PCI Option ROMs\n",
-               option_rom_phys_addr,
-               option_rom_phys_addr + option_rom_sz - 1);
     printf(" %05x-%05x: Main BIOS\n",
            bios->bios_address,
            bios->bios_address + bios->image_size - 1);
diff --git a/tools/firmware/hvmloader/option_rom.h b/tools/firmware/hvmloader/option_rom.h
index f0c7ec4..1ada3e2 100644
--- a/tools/firmware/hvmloader/option_rom.h
+++ b/tools/firmware/hvmloader/option_rom.h
@@ -47,6 +47,13 @@ struct option_rom_pci_header {
     uint16_t reserved;
 } __attribute__ ((packed));
 
+#define round_option_rom(x) (((x) + 2047) & ~2047)
+int scan_etherboot_nic(unsigned int option_rom_end,
+                       uint32_t copy_rom_dest,
+                       void *etherboot_rom);
+int pci_load_option_roms(unsigned int option_rom_end,
+                         uint32_t rom_base_addr);
+
 #endif /* __HVMLOADER_OPTION_ROM_H__ */
 
 /*
diff --git a/tools/firmware/hvmloader/optionroms.c b/tools/firmware/hvmloader/optionroms.c
new file mode 100644
index 0000000..e35aebc
--- /dev/null
+++ b/tools/firmware/hvmloader/optionroms.c
@@ -0,0 +1,189 @@
+/*
+ * optionroms.c: Option ROM loading support.
+ *
+ * Leendert van Doorn, leendert@watson.ibm.com
+ * Copyright (c) 2005, International Business Machines Corporation.
+ *
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include "config.h"
+#include "option_rom.h"
+#include "util.h"
+#include "pci_regs.h"
+
+/*
+ * Scan the list of Option ROMs at @roms for one which supports 
+ * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
+ * copy it to @dest and return its size rounded up to a multiple 2kB. This
+ * function will not copy ROMs beyond address option_rom_end.
+ */
+static int scan_option_rom(
+    unsigned int option_rom_end,
+    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
+    void *roms, uint32_t dest)
+{
+    struct option_rom_header *rom;
+    struct option_rom_pnp_header *pnph;
+    struct option_rom_pci_header *pcih;
+    uint8_t csum;
+    int i;
+
+    static uint32_t orom_ids[64];
+    static int nr_roms;
+
+    /* Avoid duplicate ROMs. */
+    for ( i = 0; i < nr_roms; i++ )
+        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
+            return 0;
+
+    rom = roms;
+    for ( ; ; )
+    {
+        /* Invalid signature means we're out of option ROMs. */
+        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
+             (rom->rom_size == 0) )
+            break;
+
+        /* Invalid checksum means we're out of option ROMs. */
+        csum = 0;
+        for ( i = 0; i < (rom->rom_size * 512); i++ )
+            csum += ((uint8_t *)rom)[i];
+        if ( csum != 0 )
+            break;
+
+        /* Check the PCI PnP header (if any) for a match. */
+        pcih = (struct option_rom_pci_header *)
+            ((char *)rom + rom->pci_header_offset);
+        if ( (rom->pci_header_offset != 0) &&
+             !strncmp((char *)pcih->signature, "PCIR", 4) &&
+             (pcih->vendor_id == vendor_id) &&
+             (pcih->device_id == device_id) )
+            goto found;
+
+        rom = (struct option_rom_header *)
+            ((char *)rom + rom->rom_size * 512);
+    }
+
+    return 0;
+
+ found:
+    /* Find the PnP expansion header (if any). */
+    pnph = ((rom->expansion_header_offset != 0)
+            ? ((struct option_rom_pnp_header *)
+               ((char *)rom + rom->expansion_header_offset))
+            : ((struct option_rom_pnp_header *)NULL));
+    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
+        pnph = ((pnph->next_header_offset != 0)
+                ? ((struct option_rom_pnp_header *)
+                   ((char *)rom + pnph->next_header_offset))
+                : ((struct option_rom_pnp_header *)NULL));
+
+    printf("Loading PCI Option ROM ...\n");
+    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
+        printf(" - Manufacturer: %s\n",
+               (char *)rom + pnph->manufacturer_name_offset);
+    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
+        printf(" - Product name: %s\n",
+               (char *)rom + pnph->product_name_offset);
+
+    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
+    {
+        printf("Option ROM size %x exceeds available space\n",
+               rom->rom_size * 512);
+        return 0;
+    }
+
+    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
+    memcpy((void *)dest, rom, rom->rom_size * 512);
+    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
+    return round_option_rom(rom->rom_size * 512 + 1);
+}
+
+/*
+ * Scan the PCI bus for the first NIC supported by etherboot, and copy
+ * the corresponding rom data to *copy_rom_dest. Returns the length of the
+ * selected rom, or 0 if no NIC found.
+ */
+int scan_etherboot_nic(unsigned int option_rom_end,
+                       uint32_t copy_rom_dest,
+                       void *etherboot_rom)
+{
+    uint16_t class, vendor_id, device_id, devfn;
+    int rom_size = 0;
+
+    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
+    {
+        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
+        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(devfn, PCI_DEVICE_ID);
+
+        /* We're only interested in NICs. */
+        if ( (vendor_id != 0xffff) &&
+             (device_id != 0xffff) &&
+             (class == 0x0200) )
+            rom_size = scan_option_rom(
+                option_rom_end,
+                devfn, vendor_id, device_id, etherboot_rom, copy_rom_dest);
+    }
+
+    return rom_size;
+}
+
+/*
+ * Scan the PCI bus for the devices that have an option ROM, and copy
+ * the corresponding rom data to rom_phys_addr.
+ */
+int pci_load_option_roms(unsigned int option_rom_end,
+                         uint32_t rom_base_addr)
+{
+    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
+    uint16_t vendor_id, device_id, devfn, class;
+
+    for ( devfn = 0; devfn < 256; devfn++ )
+    {
+        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
+        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(devfn, PCI_DEVICE_ID);
+
+        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
+            continue;
+
+        /*
+         * Currently only scan options from mass storage devices and serial
+         * bus controller (Fibre Channel included).
+         */
+        if ( (class != 0x1) && (class != 0xc) )
+            continue;
+
+        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
+        if ( !option_rom_addr )
+            continue;
+
+        /* Ensure Expansion Bar is enabled before copying */
+        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
+
+        rom_phys_addr += scan_option_rom(
+            option_rom_end,
+            devfn, vendor_id, device_id,
+            (void *)(option_rom_addr & ~2047), rom_phys_addr);
+
+        /* Restore the default original value of Expansion Bar */
+        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
+    }
+
+    return rom_phys_addr - rom_base_addr;
+}
diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
index d5831aa..e0d4182 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -29,10 +29,13 @@
 #include "pci_regs.h"
 #include "util.h"
 #include "hypercall.h"
+#include "option_rom.h"
 
 #include <xen/hvm/params.h>
 
 #define ROM_INCLUDE_ROMBIOS
+#define ROM_INCLUDE_VGABIOS
+#define ROM_INCLUDE_ETHERBOOT
 #include "roms.inc"
 
 #define ROMBIOS_BEGIN          0x000F0000
@@ -64,6 +67,61 @@ static void rombios_setup_bios_info(void)
     memset(info, 0, sizeof(*info));
 }
 
+static void rombios_load_roms(void)
+{
+    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
+    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+
+    switch ( virtual_vga )
+    {
+    case VGA_cirrus:
+        printf("Loading Cirrus VGABIOS ...\n");
+        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
+               vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
+        vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
+        break;
+    case VGA_std:
+        printf("Loading Standard VGABIOS ...\n");
+        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
+               vgabios_stdvga, sizeof(vgabios_stdvga));
+        vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
+        break;
+    case VGA_pt:
+        printf("Loading VGABIOS of passthroughed gfx ...\n");
+        vgabios_sz = round_option_rom(
+            (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+        break;
+    default:
+        printf("No emulated VGA adaptor ...\n");
+        break;
+    }
+
+    etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
+    if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
+        etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
+    etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
+                                      etherboot_phys_addr,
+                                      etherboot);
+
+    option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
+    option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
+                                         option_rom_phys_addr);
+
+    printf("Option ROMs:\n");
+    if ( vgabios_sz )
+        printf(" %05x-%05x: VGA BIOS\n",
+               VGABIOS_PHYSICAL_ADDRESS,
+               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
+    if ( etherboot_sz )
+        printf(" %05x-%05x: Etherboot ROM\n",
+               etherboot_phys_addr,
+               etherboot_phys_addr + etherboot_sz - 1);
+    if ( option_rom_sz )
+        printf(" %05x-%05x: PCI Option ROMs\n",
+               option_rom_phys_addr,
+               option_rom_phys_addr + option_rom_sz - 1);
+}
+
 static void rombios_load(const struct bios_config *config)
 {
     uint32_t bioshigh;
@@ -158,10 +216,7 @@ struct bios_config rombios_config =  {
 
     .bios_address = ROMBIOS_PHYSICAL_ADDRESS,
 
-    .load_roms = 1,
-
-    .optionrom_start = OPTIONROM_PHYSICAL_ADDRESS,
-    .optionrom_end = OPTIONROM_PHYSICAL_END,
+    .load_roms = rombios_load_roms,
 
     .bios_load = rombios_load,
 
diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
index 3045157..15ddf35 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -143,10 +143,7 @@ struct bios_config seabios_config = {
 
     .bios_address = SEABIOS_PHYSICAL_ADDRESS,
 
-    .load_roms = 0,
-
-    .optionrom_start = 0,
-    .optionrom_end = 0,
+    .load_roms = NULL,
 
     .bios_load = NULL,
 
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyv-0004j3-Ld; Sat, 11 Feb 2012 19:51:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyt-0004h2-MT
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:35 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!4
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24305 invoked from network); 11 Feb 2012 19:51:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:29 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=q4cEI60QzhOTdm6SHOrwgL2m4HO+Nh0QCV5FcxmG/UQ=;
	b=n3oTpCVZXpztvYtvptZMSEy8zYUzlkUPgomrqw0j9PTh0G2u9T/yFag5qF0Ve1L6Sq
	V4F7fJN9SKs4etVFQq4r38XpQaJnPpC1XqrVQwUV4ONo5wMejiUi8FUIhG6tsTyBQevm
	D2dexBgltzAmDENU+cVnMZOyss93c1IOHTkno=
Received: by 10.216.136.96 with SMTP id v74mr2495937wei.27.1328989889450;
	Sat, 11 Feb 2012 11:51:29 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:29 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:05 +0000
Message-Id: <0849e9a95e551e4c6f390774e68387b6ff6751fb.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 5/5] firmware: Introduce CONFIG_ROMBIOS and
	CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch introduces configuration options allowing to built either
a rombios only or a seabios only hvmloader.

Building option ROMs like vgabios or etherboot is only enabled for
a rombios hvmloader, since SeaBIOS takes care or extracting option
ROMs itself from the PCI devices (these option ROMs are provided
by the device model and do not need to be built in hvmloader).

The Makefile in tools/firmware/ now only checks for bcc if rombios
is enabled.

These two configuration options are left on by default to remain
compatible.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                         |    3 +++
 tools/firmware/Makefile           |   18 ++++++++++--------
 tools/firmware/hvmloader/Makefile |   32 +++++++++++++++++++-------------
 3 files changed, 32 insertions(+), 21 deletions(-)

diff --git a/Config.mk b/Config.mk
index 42508b8..a43596c 100644
--- a/Config.mk
+++ b/Config.mk
@@ -224,6 +224,9 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_ROMBIOS ?= y
+CONFIG_SEABIOS ?= y
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index c3ec9a0..5d40bcd 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
 TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
-SUBDIRS :=
-SUBDIRS += seabios-dir
-SUBDIRS += rombios
-SUBDIRS += vgabios
-SUBDIRS += etherboot
-SUBDIRS += hvmloader
+SUBDIRS-y :=
+SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
+SUBDIRS-$(CONFIG_ROMBIOS) += rombios
+SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
+SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
+SUBDIRS-y += hvmloader
 
 seabios-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
 	cp seabios-config seabios-dir/.config;
 
 .PHONY: all
-all: seabios-dir
+all: $(SUBDIRS-y)
+ifeq ($(CONFIG_ROMBIOS),y)
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -25,7 +26,8 @@ all: seabios-dir
 	echo "==========================================================================="; \
 	false ; \
 	fi
-	$(MAKE) subdirs-$@; \
+endif
+	$(MAKE) subdirs-$@
 
 
 .PHONY: install
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 5a5ee41..175dba6 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -38,27 +38,33 @@ endif
 CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
-ifneq ($(ROMBIOS_DIR),)
-OBJS += optionroms.o 32bitbios_support.o rombios.o
-CFLAGS += -DENABLE_ROMBIOS
-ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
-endif
-
 SEABIOS_DIR := ../seabios-dir
-ifneq ($(SEABIOS_DIR),)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-endif
 
+ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM    := ../vgabios/VGABIOS-lgpl-latest.bin
 ifeq ($(CIRRUSVGA_DEBUG),y)
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
-
 ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+endif
+
+ROMS := 
+
+ifeq ($(CONFIG_ROMBIOS),y)
+OBJS += optionroms.o 32bitbios_support.o rombios.o
+CFLAGS += -DENABLE_ROMBIOS
+ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
+ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+endif
+
+ifeq ($(CONFIG_SEABIOS),y)
+OBJS += seabios.o
+CFLAGS += -DENABLE_SEABIOS
+SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
+ROMS += $(SEABIOS_ROM)
+endif
 
 .PHONY: all
 all: subdirs-all
@@ -72,7 +78,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+roms.inc: $(ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyl-0004gZ-Ev; Sat, 11 Feb 2012 19:51:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyj-0004g7-Nq
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:25 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24190 invoked from network); 11 Feb 2012 19:51:19 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:19 -0000
Received: by wibhm2 with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=mJBskk1j+LTxKZvD7/sH1c3WFjATk+xjHfFtRSbGP/I=;
	b=sN6Kocdkp2PNn0VK0f6pvVDqryhkEIvOH61rNeKGUbMbZ0Ug2hh8hcxb1tr03jLAac
	dsEBpJVAWmm/srNocPld2IqnT4uuChvt0sGiKuDl7gc2m25QsIIfaGRf37UsQuoMpxw7
	x85OSpOcPoyOzjwL9kY7qKxzsT3/TN4zFK2zE=
Received: by 10.180.83.97 with SMTP id p1mr16018904wiy.19.1328989879276;
	Sat, 11 Feb 2012 11:51:19 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:17 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:00 +0000
Message-Id: <cover.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set mainly allows the user to build a seabios or rombios only
version of hvmloader.
In addition, when building a seabios only hvmloader, Option ROMs like
vgabios and etherboot are no longer required, and therefore can be disabled
from the build. Dependency on the bcc compiler can also be avoided the
same way.

v2: Separate patches for separate issues
   Introduced config option to select which NIC to build ROM for
   Fixed initial patch to build multiple etherboot ROMs in hvmloader
   Option ROMs are keyed off wether or not rombios is enabled, rather than
on an individual basis
   Introduced config options to select support for rombios/seabios

v3: Fix mkhex script to take several file arguments on the command line
    Reorganize hvmloader option ROM loading code to make it optionnal, and
make bios->load_roms a callback that the BIOS support code has to implement
if option ROM loading is desired.
    Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
created.

Julian Pidancet (5):
  hvmloader: Only compile 32bitbios_support.c when rombios is enabled
  hvmloader: Allow the mkhex command to take several file arguments
  firmware: Use mkhex from hvmloader directory for etherboot ROMs
  hvmloader: Move option ROM loading into a separate optionnal file
  firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options

 Config.mk                             |    5 +
 tools/firmware/Makefile               |   18 ++--
 tools/firmware/etherboot/Config       |    2 -
 tools/firmware/etherboot/Makefile     |   13 +--
 tools/firmware/hvmloader/Makefile     |   39 ++++---
 tools/firmware/hvmloader/config.h     |    3 +-
 tools/firmware/hvmloader/hvmloader.c  |  218 +--------------------------------
 tools/firmware/hvmloader/mkhex        |    3 +-
 tools/firmware/hvmloader/option_rom.h |    7 +
 tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
 tools/firmware/hvmloader/seabios.c    |    5 +-
 12 files changed, 302 insertions(+), 263 deletions(-)
 create mode 100644 tools/firmware/hvmloader/optionroms.c

-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyv-0004j3-Ld; Sat, 11 Feb 2012 19:51:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyt-0004h2-MT
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:35 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!4
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24305 invoked from network); 11 Feb 2012 19:51:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:29 -0000
Received: by mail-wi0-f171.google.com with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=q4cEI60QzhOTdm6SHOrwgL2m4HO+Nh0QCV5FcxmG/UQ=;
	b=n3oTpCVZXpztvYtvptZMSEy8zYUzlkUPgomrqw0j9PTh0G2u9T/yFag5qF0Ve1L6Sq
	V4F7fJN9SKs4etVFQq4r38XpQaJnPpC1XqrVQwUV4ONo5wMejiUi8FUIhG6tsTyBQevm
	D2dexBgltzAmDENU+cVnMZOyss93c1IOHTkno=
Received: by 10.216.136.96 with SMTP id v74mr2495937wei.27.1328989889450;
	Sat, 11 Feb 2012 11:51:29 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:29 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:05 +0000
Message-Id: <0849e9a95e551e4c6f390774e68387b6ff6751fb.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 5/5] firmware: Introduce CONFIG_ROMBIOS and
	CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch introduces configuration options allowing to built either
a rombios only or a seabios only hvmloader.

Building option ROMs like vgabios or etherboot is only enabled for
a rombios hvmloader, since SeaBIOS takes care or extracting option
ROMs itself from the PCI devices (these option ROMs are provided
by the device model and do not need to be built in hvmloader).

The Makefile in tools/firmware/ now only checks for bcc if rombios
is enabled.

These two configuration options are left on by default to remain
compatible.

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 Config.mk                         |    3 +++
 tools/firmware/Makefile           |   18 ++++++++++--------
 tools/firmware/hvmloader/Makefile |   32 +++++++++++++++++++-------------
 3 files changed, 32 insertions(+), 21 deletions(-)

diff --git a/Config.mk b/Config.mk
index 42508b8..a43596c 100644
--- a/Config.mk
+++ b/Config.mk
@@ -224,6 +224,9 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_ROMBIOS ?= y
+CONFIG_SEABIOS ?= y
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index c3ec9a0..5d40bcd 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
 TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
-SUBDIRS :=
-SUBDIRS += seabios-dir
-SUBDIRS += rombios
-SUBDIRS += vgabios
-SUBDIRS += etherboot
-SUBDIRS += hvmloader
+SUBDIRS-y :=
+SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
+SUBDIRS-$(CONFIG_ROMBIOS) += rombios
+SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
+SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
+SUBDIRS-y += hvmloader
 
 seabios-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
 	cp seabios-config seabios-dir/.config;
 
 .PHONY: all
-all: seabios-dir
+all: $(SUBDIRS-y)
+ifeq ($(CONFIG_ROMBIOS),y)
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -25,7 +26,8 @@ all: seabios-dir
 	echo "==========================================================================="; \
 	false ; \
 	fi
-	$(MAKE) subdirs-$@; \
+endif
+	$(MAKE) subdirs-$@
 
 
 .PHONY: install
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 5a5ee41..175dba6 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -38,27 +38,33 @@ endif
 CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
-ifneq ($(ROMBIOS_DIR),)
-OBJS += optionroms.o 32bitbios_support.o rombios.o
-CFLAGS += -DENABLE_ROMBIOS
-ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
-endif
-
 SEABIOS_DIR := ../seabios-dir
-ifneq ($(SEABIOS_DIR),)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-endif
 
+ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM    := ../vgabios/VGABIOS-lgpl-latest.bin
 ifeq ($(CIRRUSVGA_DEBUG),y)
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.debug.bin
 else
 CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
 endif
-
 ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
+endif
+
+ROMS := 
+
+ifeq ($(CONFIG_ROMBIOS),y)
+OBJS += optionroms.o 32bitbios_support.o rombios.o
+CFLAGS += -DENABLE_ROMBIOS
+ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
+ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+endif
+
+ifeq ($(CONFIG_SEABIOS),y)
+OBJS += seabios.o
+CFLAGS += -DENABLE_SEABIOS
+SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
+ROMS += $(SEABIOS_ROM)
+endif
 
 .PHONY: all
 all: subdirs-all
@@ -72,7 +78,7 @@ hvmloader: $(OBJS) acpi/acpi.a
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
 
-roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
+roms.inc: $(ROMS)
 	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
 
 ifneq ($(ROMBIOS_ROM),)
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyl-0004gZ-Ev; Sat, 11 Feb 2012 19:51:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1RwIyj-0004g7-Nq
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:25 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328989879!11071820!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24190 invoked from network); 11 Feb 2012 19:51:19 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:19 -0000
Received: by wibhm2 with SMTP id hm2so11395288wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=mJBskk1j+LTxKZvD7/sH1c3WFjATk+xjHfFtRSbGP/I=;
	b=sN6Kocdkp2PNn0VK0f6pvVDqryhkEIvOH61rNeKGUbMbZ0Ug2hh8hcxb1tr03jLAac
	dsEBpJVAWmm/srNocPld2IqnT4uuChvt0sGiKuDl7gc2m25QsIIfaGRf37UsQuoMpxw7
	x85OSpOcPoyOzjwL9kY7qKxzsT3/TN4zFK2zE=
Received: by 10.180.83.97 with SMTP id p1mr16018904wiy.19.1328989879276;
	Sat, 11 Feb 2012 11:51:19 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:17 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:00 +0000
Message-Id: <cover.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set mainly allows the user to build a seabios or rombios only
version of hvmloader.
In addition, when building a seabios only hvmloader, Option ROMs like
vgabios and etherboot are no longer required, and therefore can be disabled
from the build. Dependency on the bcc compiler can also be avoided the
same way.

v2: Separate patches for separate issues
   Introduced config option to select which NIC to build ROM for
   Fixed initial patch to build multiple etherboot ROMs in hvmloader
   Option ROMs are keyed off wether or not rombios is enabled, rather than
on an individual basis
   Introduced config options to select support for rombios/seabios

v3: Fix mkhex script to take several file arguments on the command line
    Reorganize hvmloader option ROM loading code to make it optionnal, and
make bios->load_roms a callback that the BIOS support code has to implement
if option ROM loading is desired.
    Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
created.

Julian Pidancet (5):
  hvmloader: Only compile 32bitbios_support.c when rombios is enabled
  hvmloader: Allow the mkhex command to take several file arguments
  firmware: Use mkhex from hvmloader directory for etherboot ROMs
  hvmloader: Move option ROM loading into a separate optionnal file
  firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options

 Config.mk                             |    5 +
 tools/firmware/Makefile               |   18 ++--
 tools/firmware/etherboot/Config       |    2 -
 tools/firmware/etherboot/Makefile     |   13 +--
 tools/firmware/hvmloader/Makefile     |   39 ++++---
 tools/firmware/hvmloader/config.h     |    3 +-
 tools/firmware/hvmloader/hvmloader.c  |  218 +--------------------------------
 tools/firmware/hvmloader/mkhex        |    3 +-
 tools/firmware/hvmloader/option_rom.h |    7 +
 tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
 tools/firmware/hvmloader/seabios.c    |    5 +-
 12 files changed, 302 insertions(+), 263 deletions(-)
 create mode 100644 tools/firmware/hvmloader/optionroms.c

-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyl-0004gk-RB; Sat, 11 Feb 2012 19:51:27 +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 1RwIyl-0004gR-5y
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:27 +0000
Received: from [85.158.139.83:8885] by server-2.bemta-5.messagelabs.com id
	68/37-20725-EB6C63F4; Sat, 11 Feb 2012 19:51:26 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328989885!14678281!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20705 invoked from network); 11 Feb 2012 19:51:25 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:25 -0000
Received: by werb14 with SMTP id b14so11480928wer.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=eMypojxOKfnsiWth1rEFjj6+xpDbXS0H40P0SH5R+OE=;
	b=uzZNJbsP0p1PZDL4VsHDNWfWqbYlhQZ9lkfOuUEZ3Ydbh+n5kZumwQp6SQTNQSv5Ew
	lMtb9jdnoVgUsSwsJxz0vw8z5UEBR0UqAXIPNwKedI/kJtDjuEJlj2CaoSkLhzvhB2rc
	6lVBL/oryPiKVbxau8D2dqQ5teKzJcTY4lbkc=
Received: by 10.180.92.71 with SMTP id ck7mr20291888wib.3.1328989885539;
	Sat, 11 Feb 2012 11:51:25 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:25 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:01 +0000
Message-Id: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 1/5] hvmloader: Only compile
	32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

32bitbios_support.c only contains code specific to rombios, and should
not be built-in when building hvmloader for SeaBIOS only (as for
rombios.c).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 41a4369..e82146a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o
 OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
@@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += rombios.o
+OBJS += 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 19:52:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 19:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwIyl-0004gk-RB; Sat, 11 Feb 2012 19:51:27 +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 1RwIyl-0004gR-5y
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 19:51:27 +0000
Received: from [85.158.139.83:8885] by server-2.bemta-5.messagelabs.com id
	68/37-20725-EB6C63F4; Sat, 11 Feb 2012 19:51:26 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328989885!14678281!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20705 invoked from network); 11 Feb 2012 19:51:25 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2012 19:51:25 -0000
Received: by werb14 with SMTP id b14so11480928wer.30
	for <xen-devel@lists.xensource.com>;
	Sat, 11 Feb 2012 11:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references;
	bh=eMypojxOKfnsiWth1rEFjj6+xpDbXS0H40P0SH5R+OE=;
	b=uzZNJbsP0p1PZDL4VsHDNWfWqbYlhQZ9lkfOuUEZ3Ydbh+n5kZumwQp6SQTNQSv5Ew
	lMtb9jdnoVgUsSwsJxz0vw8z5UEBR0UqAXIPNwKedI/kJtDjuEJlj2CaoSkLhzvhB2rc
	6lVBL/oryPiKVbxau8D2dqQ5teKzJcTY4lbkc=
Received: by 10.180.92.71 with SMTP id ck7mr20291888wib.3.1328989885539;
	Sat, 11 Feb 2012 11:51:25 -0800 (PST)
Received: from localhost.localdomain (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id dr5sm30298239wib.0.2012.02.11.11.51.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 11 Feb 2012 11:51:25 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
To: xen-devel@lists.xensource.com
Date: Sat, 11 Feb 2012 20:39:01 +0000
Message-Id: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328991838.git.julian.pidancet@gmail.com>
X-Mailer: git-send-email 1.7.3.4
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
Cc: Ian.Campbell@citrix.com, Julian Pidancet <julian.pidancet@gmail.com>
Subject: [Xen-devel] [PATCH v3 1/5] hvmloader: Only compile
	32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

32bitbios_support.c only contains code specific to rombios, and should
not be built-in when building hvmloader for SeaBIOS only (as for
rombios.c).

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 tools/firmware/hvmloader/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 41a4369..e82146a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -29,7 +29,7 @@ LOADADDR = 0x100000
 CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
-OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
+OBJS += smp.o cacheattr.o xenbus.o
 OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
@@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
 
 ROMBIOS_DIR := ../rombios
 ifneq ($(ROMBIOS_DIR),)
-OBJS += rombios.o
+OBJS += 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
-- 
Julian Pidancet


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 11 23:03:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 23:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwLxw-0007Vx-W0; Sat, 11 Feb 2012 23:02:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <j.farzin@yahoo.com>) id 1RwLxu-0007Vp-K5
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 23:02:46 +0000
X-Env-Sender: j.farzin@yahoo.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329001359!14591986!1
X-Originating-IP: [72.30.239.142]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2274 invoked from network); 11 Feb 2012 23:02:39 -0000
Received: from nm32-vm6.bullet.mail.bf1.yahoo.com (HELO
	nm32-vm6.bullet.mail.bf1.yahoo.com) (72.30.239.142)
	by server-14.tower-21.messagelabs.com with SMTP;
	11 Feb 2012 23:02:39 -0000
Received: from [98.139.214.32] by nm32.bullet.mail.bf1.yahoo.com with NNFMP;
	11 Feb 2012 23:02:38 -0000
Received: from [98.139.212.220] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;
	11 Feb 2012 23:02:38 -0000
Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP;
	11 Feb 2012 23:02:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 757207.33244.bm@omp1029.mail.bf1.yahoo.com
Received: (qmail 6143 invoked by uid 60001); 11 Feb 2012 23:02:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1329001358; bh=HyZfXNC6S8eA2d+vXPCxdO6B6huwmbMMbmbwDi95S2k=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=plKeGlBPNGJl6oNOeTdvqWOPsLHORW6OZlwehNcyJvcWmWGbVAYQuINSFzo/KdWHn+sweUwCl0c5E6BCpE7AIEjTMSjqiucAEWaso2r0E+bFc+tZjttEe8iXOv9AVkZZYABNA5OXngT964bC5Bvfw287MJCo7pnkVGUcrEewTtA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=ol9et7OfNzAZeb526r8ffwn4RzYjsk0b418vrwOIfmZ9CjnYAXO9gCo5ae89m46hn7+lrM/q7aZh85MeJ1Sz40HIzm93lgsKI+xEMZ/z+8+07BcyWbj3a6hrxwb9nnqqyVabyPIpOAByfhbS45Wa12tpA7VJk15y3X3GMqzW96k=;
X-YMail-OSG: eLy30HIVM1kgmaHLnj2sfl5P48qfmOH7_OQhAArM1LGW5AU
	p8w5_eGam2FkPHvLfjt5Wqn6mEAQnwKAejZNI_zo9Z08DawArzsrqEIKQKS2
	PqCSzuuFaG5CKhb3jVHCwFlAIDfs2cLYIPavY6u6PrTJ_.KFWZI6BGRm1CmZ
	IkB91GAhvmDTxlauaJfBwsTgW4iqz0w19I4XTZ62B4BU2TZQoMHdiqGDiESm
	eKuyEzWRaNA_.wHUUSBJ.IVkzJwhlSH816BhF4J3EIrLZwLfydFNgD8W6JUS
	StWMxhpoFzqFENrXoTIix.MbzrsRJE.yBrInNg1eWxDBHAhNEwZhAVFzuXOS
	jPCI91r0_P0yWo4w.YhB2JssGoh_1kYBnus_X1GaXGaSzwaZrssC7U_BS8pl
	_JjjTtxw1bJ.RkkQ4iJy_hyvfjtBWYesdlzrEBb5aawG_PS_uV32twAyP5HO
	mM5jVxKfry9h7spvWmaAN5w--
Received: from [95.81.88.17] by web161504.mail.bf1.yahoo.com via HTTP;
	Sat, 11 Feb 2012 15:02:38 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.338427
Message-ID: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Date: Sat, 11 Feb 2012 15:02:38 -0800 (PST)
From: Javanshir Farzin <j.farzin@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] which linux distribution for XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7720588131513021482=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7720588131513021482==
Content-Type: multipart/alternative; boundary="1835785293-943809492-1329001358=:95462"

--1835785293-943809492-1329001358=:95462
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,
I want to change XEN source code after that I will copile it, and I will su=
rvey change's effect. I have ubuntu 11.4 and centos 5.2. Which of the linux=
 distributions is suitable for my job?
thanks
--1835785293-943809492-1329001358=:95462
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">Hello,<br>I want to change XEN source code af=
ter that I will copile it, and I will survey change's effect. I have ubuntu=
 11.4 and centos 5.2. Which of the linux distributions is suitable for my j=
ob?<br>thanks</td></tr></table>
--1835785293-943809492-1329001358=:95462--


--===============7720588131513021482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7720588131513021482==--


From xen-devel-bounces@lists.xensource.com Sat Feb 11 23:03:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 11 Feb 2012 23:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwLxw-0007Vx-W0; Sat, 11 Feb 2012 23:02:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <j.farzin@yahoo.com>) id 1RwLxu-0007Vp-K5
	for xen-devel@lists.xensource.com; Sat, 11 Feb 2012 23:02:46 +0000
X-Env-Sender: j.farzin@yahoo.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329001359!14591986!1
X-Originating-IP: [72.30.239.142]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2274 invoked from network); 11 Feb 2012 23:02:39 -0000
Received: from nm32-vm6.bullet.mail.bf1.yahoo.com (HELO
	nm32-vm6.bullet.mail.bf1.yahoo.com) (72.30.239.142)
	by server-14.tower-21.messagelabs.com with SMTP;
	11 Feb 2012 23:02:39 -0000
Received: from [98.139.214.32] by nm32.bullet.mail.bf1.yahoo.com with NNFMP;
	11 Feb 2012 23:02:38 -0000
Received: from [98.139.212.220] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;
	11 Feb 2012 23:02:38 -0000
Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP;
	11 Feb 2012 23:02:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 757207.33244.bm@omp1029.mail.bf1.yahoo.com
Received: (qmail 6143 invoked by uid 60001); 11 Feb 2012 23:02:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1329001358; bh=HyZfXNC6S8eA2d+vXPCxdO6B6huwmbMMbmbwDi95S2k=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=plKeGlBPNGJl6oNOeTdvqWOPsLHORW6OZlwehNcyJvcWmWGbVAYQuINSFzo/KdWHn+sweUwCl0c5E6BCpE7AIEjTMSjqiucAEWaso2r0E+bFc+tZjttEe8iXOv9AVkZZYABNA5OXngT964bC5Bvfw287MJCo7pnkVGUcrEewTtA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=ol9et7OfNzAZeb526r8ffwn4RzYjsk0b418vrwOIfmZ9CjnYAXO9gCo5ae89m46hn7+lrM/q7aZh85MeJ1Sz40HIzm93lgsKI+xEMZ/z+8+07BcyWbj3a6hrxwb9nnqqyVabyPIpOAByfhbS45Wa12tpA7VJk15y3X3GMqzW96k=;
X-YMail-OSG: eLy30HIVM1kgmaHLnj2sfl5P48qfmOH7_OQhAArM1LGW5AU
	p8w5_eGam2FkPHvLfjt5Wqn6mEAQnwKAejZNI_zo9Z08DawArzsrqEIKQKS2
	PqCSzuuFaG5CKhb3jVHCwFlAIDfs2cLYIPavY6u6PrTJ_.KFWZI6BGRm1CmZ
	IkB91GAhvmDTxlauaJfBwsTgW4iqz0w19I4XTZ62B4BU2TZQoMHdiqGDiESm
	eKuyEzWRaNA_.wHUUSBJ.IVkzJwhlSH816BhF4J3EIrLZwLfydFNgD8W6JUS
	StWMxhpoFzqFENrXoTIix.MbzrsRJE.yBrInNg1eWxDBHAhNEwZhAVFzuXOS
	jPCI91r0_P0yWo4w.YhB2JssGoh_1kYBnus_X1GaXGaSzwaZrssC7U_BS8pl
	_JjjTtxw1bJ.RkkQ4iJy_hyvfjtBWYesdlzrEBb5aawG_PS_uV32twAyP5HO
	mM5jVxKfry9h7spvWmaAN5w--
Received: from [95.81.88.17] by web161504.mail.bf1.yahoo.com via HTTP;
	Sat, 11 Feb 2012 15:02:38 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.338427
Message-ID: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Date: Sat, 11 Feb 2012 15:02:38 -0800 (PST)
From: Javanshir Farzin <j.farzin@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] which linux distribution for XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7720588131513021482=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7720588131513021482==
Content-Type: multipart/alternative; boundary="1835785293-943809492-1329001358=:95462"

--1835785293-943809492-1329001358=:95462
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,
I want to change XEN source code after that I will copile it, and I will su=
rvey change's effect. I have ubuntu 11.4 and centos 5.2. Which of the linux=
 distributions is suitable for my job?
thanks
--1835785293-943809492-1329001358=:95462
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">Hello,<br>I want to change XEN source code af=
ter that I will copile it, and I will survey change's effect. I have ubuntu=
 11.4 and centos 5.2. Which of the linux distributions is suitable for my j=
ob?<br>thanks</td></tr></table>
--1835785293-943809492-1329001358=:95462--


--===============7720588131513021482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7720588131513021482==--


From xen-devel-bounces@lists.xensource.com Sun Feb 12 06:36:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Feb 2012 06: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.xensource.com>)
	id 1RwT2R-0000FE-CV; Sun, 12 Feb 2012 06:35:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwT2P-0000F9-P1
	for xen-devel@lists.xensource.com; Sun, 12 Feb 2012 06:35:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329028547!13008123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28362 invoked from network); 12 Feb 2012 06:35:47 -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 Feb 2012 06:35:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,406,1325462400"; d="scan'208";a="10641101"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2012 06:35:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 12 Feb 2012 06:35:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RwT2I-0002hk-ME;
	Sun, 12 Feb 2012 06:35:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RwT2H-0001XJ-V8;
	Sun, 12 Feb 2012 06:35:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11943-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 12 Feb 2012 06:35:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11943: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11943 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11943/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11942

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9ad1e42c341b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 12 06:36:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Feb 2012 06: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.xensource.com>)
	id 1RwT2R-0000FE-CV; Sun, 12 Feb 2012 06:35:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwT2P-0000F9-P1
	for xen-devel@lists.xensource.com; Sun, 12 Feb 2012 06:35:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329028547!13008123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28362 invoked from network); 12 Feb 2012 06:35:47 -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 Feb 2012 06:35:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,406,1325462400"; d="scan'208";a="10641101"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2012 06:35:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 12 Feb 2012 06:35:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RwT2I-0002hk-ME;
	Sun, 12 Feb 2012 06:35:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RwT2H-0001XJ-V8;
	Sun, 12 Feb 2012 06:35:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11943-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 12 Feb 2012 06:35:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11943: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11943 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11943/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11942

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9ad1e42c341b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 12 20:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Feb 2012 20:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwgIY-0002oO-76; Sun, 12 Feb 2012 20:45:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1RwgIW-0002oJ-CE
	for xen-devel@lists.xensource.com; Sun, 12 Feb 2012 20:45:24 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329079517!11051309!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8535 invoked from network); 12 Feb 2012 20:45:17 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2012 20:45:17 -0000
Received: by lagp5 with SMTP id p5so6599952lag.30
	for <xen-devel@lists.xensource.com>;
	Sun, 12 Feb 2012 12:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=L6POEE0Mer9pFUuObPZvZgppgX2lweR907XG9JVFhAw=;
	b=hGIt1hzdoFpG14TnsLwYycvNkrigWEJFnGIhx29hBiudLHuzPKFpNLuhPYR2Q80c5c
	J2KmvmVZXCUEwNVUGfk8ovlwSw6ARySUBIgnih1Yw27/OZ5fVFCOe940ESV1QlDhTo3N
	HvULSEt2SA3+RI+i10BCAOFpVrMKlTa2mbZQ0=
MIME-Version: 1.0
Received: by 10.112.85.70 with SMTP id f6mr4727527lbz.16.1329079516951; Sun,
	12 Feb 2012 12:45:16 -0800 (PST)
Received: by 10.152.41.196 with HTTP; Sun, 12 Feb 2012 12:45:16 -0800 (PST)
Date: Sun, 12 Feb 2012 15:45:16 -0500
Message-ID: <CAJEOSFtfnH+6wq519pZ4+9MyzR_jm73z9yp73=zYPU3p0o9WAg@mail.gmail.com>
From: X <studyxen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] exception interception
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6649803818759907843=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6649803818759907843==
Content-Type: multipart/alternative; boundary=f46d04016ca97c750604b8ca70ff

--f46d04016ca97c750604b8ca70ff
Content-Type: text/plain; charset=ISO-8859-1

Hello,

Could someone kindly point me to the code in Xen for handling the
exceptions intercepted from PV guest kernels?

Thanks.

===More detail===
I was looking at some futex code in a guest kernel. The kernel code below
must have caused an exception and thus trapped into Xen. But I have not
figured out where exactly Xen processes the intercepted exception.

from guest kernel's arch/x86/include/asm/futex.h, in function
futex_atomic_cmpxchg_inatomic
asm volatile("1:\t" LOCK_PREFIX "cmpxchgl %4, %2\n"
     "2:\t.section .fixup, \"ax\"\n"
     "3:\tmov     %3, %0\n"
     "\tjmp     2b\n"
     "\t.previous\n"
     _ASM_EXTABLE(1b, 3b)
     : "+r" (ret), "=a" (oldval), "+m" (*uaddr)
     : "i" (-EFAULT), "r" (newval), "1" (oldval)
     : "memory"
);
==========

X

--f46d04016ca97c750604b8ca70ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=A0<div><br></div><div>Could someone kindly point me to the code in X=
en for handling the exceptions intercepted from PV guest kernels?</div><div=
><br></div><div>Thanks.=A0</div><div><br></div><div>=3D=3D=3DMore detail=3D=
=3D=3D</div><div>
I was looking at some futex code in a guest kernel. The kernel code below m=
ust have caused an exception and thus trapped into Xen. But I have not figu=
red out where exactly Xen processes the intercepted exception.=A0</div><div=
>
<br></div><div>from guest kernel&#39;s arch/x86/include/asm/futex.h, in fun=
ction futex_atomic_cmpxchg_inatomic</div><div><div><span class=3D"Apple-tab=
-span" style=3D"white-space:pre">	</span>asm volatile(&quot;1:\t&quot; LOCK=
_PREFIX &quot;cmpxchgl %4, %2\n&quot;</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 &quot;2:\t.section .fixup, \&quot;ax\&quot;\n&quot;</div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0 =A0 &quot;3:=
\tmov =A0 =A0 %3, %0\n&quot;</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 &quot;\tjmp =A0 =A0 2b\n&quot;</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre">		</span> =A0 =A0 &quot;\t.previous\n&quot;</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =
=A0 =A0 _ASM_EXTABLE(1b, 3b)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 : &quot;+r&quot; (ret), &quot;=3Da&quot; (oldval), &quot;+m&quot; (*ua=
ddr)</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		<=
/span> =A0 =A0 : &quot;i&quot; (-EFAULT), &quot;r&quot; (newval), &quot;1&q=
uot; (oldval)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 : &quot;memory&quot;</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre">	</span>);</div></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
</div><div><br></div><div>X</div>

--f46d04016ca97c750604b8ca70ff--


--===============6649803818759907843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6649803818759907843==--


From xen-devel-bounces@lists.xensource.com Sun Feb 12 20:46:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Feb 2012 20:46:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwgIY-0002oO-76; Sun, 12 Feb 2012 20:45:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1RwgIW-0002oJ-CE
	for xen-devel@lists.xensource.com; Sun, 12 Feb 2012 20:45:24 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329079517!11051309!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8535 invoked from network); 12 Feb 2012 20:45:17 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2012 20:45:17 -0000
Received: by lagp5 with SMTP id p5so6599952lag.30
	for <xen-devel@lists.xensource.com>;
	Sun, 12 Feb 2012 12:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=L6POEE0Mer9pFUuObPZvZgppgX2lweR907XG9JVFhAw=;
	b=hGIt1hzdoFpG14TnsLwYycvNkrigWEJFnGIhx29hBiudLHuzPKFpNLuhPYR2Q80c5c
	J2KmvmVZXCUEwNVUGfk8ovlwSw6ARySUBIgnih1Yw27/OZ5fVFCOe940ESV1QlDhTo3N
	HvULSEt2SA3+RI+i10BCAOFpVrMKlTa2mbZQ0=
MIME-Version: 1.0
Received: by 10.112.85.70 with SMTP id f6mr4727527lbz.16.1329079516951; Sun,
	12 Feb 2012 12:45:16 -0800 (PST)
Received: by 10.152.41.196 with HTTP; Sun, 12 Feb 2012 12:45:16 -0800 (PST)
Date: Sun, 12 Feb 2012 15:45:16 -0500
Message-ID: <CAJEOSFtfnH+6wq519pZ4+9MyzR_jm73z9yp73=zYPU3p0o9WAg@mail.gmail.com>
From: X <studyxen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] exception interception
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6649803818759907843=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6649803818759907843==
Content-Type: multipart/alternative; boundary=f46d04016ca97c750604b8ca70ff

--f46d04016ca97c750604b8ca70ff
Content-Type: text/plain; charset=ISO-8859-1

Hello,

Could someone kindly point me to the code in Xen for handling the
exceptions intercepted from PV guest kernels?

Thanks.

===More detail===
I was looking at some futex code in a guest kernel. The kernel code below
must have caused an exception and thus trapped into Xen. But I have not
figured out where exactly Xen processes the intercepted exception.

from guest kernel's arch/x86/include/asm/futex.h, in function
futex_atomic_cmpxchg_inatomic
asm volatile("1:\t" LOCK_PREFIX "cmpxchgl %4, %2\n"
     "2:\t.section .fixup, \"ax\"\n"
     "3:\tmov     %3, %0\n"
     "\tjmp     2b\n"
     "\t.previous\n"
     _ASM_EXTABLE(1b, 3b)
     : "+r" (ret), "=a" (oldval), "+m" (*uaddr)
     : "i" (-EFAULT), "r" (newval), "1" (oldval)
     : "memory"
);
==========

X

--f46d04016ca97c750604b8ca70ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=A0<div><br></div><div>Could someone kindly point me to the code in X=
en for handling the exceptions intercepted from PV guest kernels?</div><div=
><br></div><div>Thanks.=A0</div><div><br></div><div>=3D=3D=3DMore detail=3D=
=3D=3D</div><div>
I was looking at some futex code in a guest kernel. The kernel code below m=
ust have caused an exception and thus trapped into Xen. But I have not figu=
red out where exactly Xen processes the intercepted exception.=A0</div><div=
>
<br></div><div>from guest kernel&#39;s arch/x86/include/asm/futex.h, in fun=
ction futex_atomic_cmpxchg_inatomic</div><div><div><span class=3D"Apple-tab=
-span" style=3D"white-space:pre">	</span>asm volatile(&quot;1:\t&quot; LOCK=
_PREFIX &quot;cmpxchgl %4, %2\n&quot;</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 &quot;2:\t.section .fixup, \&quot;ax\&quot;\n&quot;</div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0 =A0 &quot;3:=
\tmov =A0 =A0 %3, %0\n&quot;</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 &quot;\tjmp =A0 =A0 2b\n&quot;</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre">		</span> =A0 =A0 &quot;\t.previous\n&quot;</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =
=A0 =A0 _ASM_EXTABLE(1b, 3b)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 : &quot;+r&quot; (ret), &quot;=3Da&quot; (oldval), &quot;+m&quot; (*ua=
ddr)</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		<=
/span> =A0 =A0 : &quot;i&quot; (-EFAULT), &quot;r&quot; (newval), &quot;1&q=
uot; (oldval)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span> =A0=
 =A0 : &quot;memory&quot;</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre">	</span>);</div></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
</div><div><br></div><div>X</div>

--f46d04016ca97c750604b8ca70ff--


--===============6649803818759907843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6649803818759907843==--


From xen-devel-bounces@lists.xensource.com Sun Feb 12 21:34:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Feb 2012 21:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwh3h-00039M-Ce; Sun, 12 Feb 2012 21:34:09 +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 1Rwh3f-00039H-Po
	for Xen-devel@lists.xensource.com; Sun, 12 Feb 2012 21:34:08 +0000
Received: from [85.158.139.83:53827] by server-12.bemta-5.messagelabs.com id
	C0/9F-30830-F40383F4; Sun, 12 Feb 2012 21:34:07 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329082444!13905527!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA3MTUzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15834 invoked from network); 12 Feb 2012 21:34:04 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2012 21:34:04 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1CLXjvK004827
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:49 GMT
Received: from vega-b.dur.ac.uk (vega-b.dur.ac.uk [129.234.250.134])
	by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1CLXOrk013136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:24 GMT
Received: from vega-b.dur.ac.uk (localhost [127.0.0.1])
	by vega-b.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q1CLXOdX003911
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:24 GMT
Received: from localhost (dcl0may@localhost)
	by vega-b.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q1CLXN3U003907
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:24 GMT
Date: Sun, 12 Feb 2012 21:33:23 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
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: q1CLXjvK004827
Subject: [Xen-devel] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I get the backtrace below if I try to boot a PV guest running F17 Alpha 
TC2 in graphical mode. Is this a known problem?

 	Michael Young

WARNING: at drivers/xen/events.c:209 evtchn_from_irq+0x41/0x50()
Invalid irq -1!
Modules linked in:
Pid: 17, comm: xenbus Tainted: G        W 
3.3.0-0.rc3.git3.1.fc17.x86_64 #1
Call Trace:
  <IRQ>  [<ffffffff8106047f>] warn_slowpath_common+0x7f/0xc0
  [<ffffffff81060576>] warn_slowpath_fmt+0x46/0x50
  [<ffffffff8100f942>] ? check_events+0x12/0x20
  [<ffffffff813c5bf1>] evtchn_from_irq+0x41/0x50
  [<ffffffff813c6302>] notify_remote_via_irq+0x12/0x50
  [<ffffffff8137e016>] xenfb_event_handler+0x26/0x50
  [<ffffffff8110b0fc>] handle_irq_event_percpu+0x6c/0x390
  [<ffffffff8110b468>] handle_irq_event+0x48/0x70
  [<ffffffff8110e7b7>] handle_edge_irq+0x77/0x110
  [<ffffffff813c56f3>] __xen_evtchn_do_upcall+0x1c3/0x290
  [<ffffffff813c782f>] xen_evtchn_do_upcall+0x2f/0x50
  [<ffffffff816a7a3e>] xen_do_hypervisor_callback+0x1e/0x30
  <EOI>  [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
  [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
  [<ffffffff813c9ed7>] ? xb_read+0xd7/0x190
  [<ffffffff811a2359>] ? kmem_cache_alloc_trace+0xd9/0x240
  [<ffffffff813cb170>] ? unregister_xenbus_watch+0x1d0/0x1d0
  [<ffffffff813cb1f9>] ? xenbus_thread+0x89/0x2b0
  [<ffffffff81089ac7>] ? kthread+0xb7/0xc0
  [<ffffffff810cd02d>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff816a78f4>] ? kernel_thread_helper+0x4/0x10
  [<ffffffff8169dcb4>] ? retint_restore_args+0x13/0x13
  [<ffffffff816a78f0>] ? gs_change+0x13/0x13


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 12 21:34:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 12 Feb 2012 21:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwh3h-00039M-Ce; Sun, 12 Feb 2012 21:34:09 +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 1Rwh3f-00039H-Po
	for Xen-devel@lists.xensource.com; Sun, 12 Feb 2012 21:34:08 +0000
Received: from [85.158.139.83:53827] by server-12.bemta-5.messagelabs.com id
	C0/9F-30830-F40383F4; Sun, 12 Feb 2012 21:34:07 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329082444!13905527!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA3MTUzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15834 invoked from network); 12 Feb 2012 21:34:04 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2012 21:34:04 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1CLXjvK004827
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:49 GMT
Received: from vega-b.dur.ac.uk (vega-b.dur.ac.uk [129.234.250.134])
	by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1CLXOrk013136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:24 GMT
Received: from vega-b.dur.ac.uk (localhost [127.0.0.1])
	by vega-b.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q1CLXOdX003911
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:24 GMT
Received: from localhost (dcl0may@localhost)
	by vega-b.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q1CLXN3U003907
	for <Xen-devel@lists.xensource.com>; Sun, 12 Feb 2012 21:33:24 GMT
Date: Sun, 12 Feb 2012 21:33:23 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
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: q1CLXjvK004827
Subject: [Xen-devel] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I get the backtrace below if I try to boot a PV guest running F17 Alpha 
TC2 in graphical mode. Is this a known problem?

 	Michael Young

WARNING: at drivers/xen/events.c:209 evtchn_from_irq+0x41/0x50()
Invalid irq -1!
Modules linked in:
Pid: 17, comm: xenbus Tainted: G        W 
3.3.0-0.rc3.git3.1.fc17.x86_64 #1
Call Trace:
  <IRQ>  [<ffffffff8106047f>] warn_slowpath_common+0x7f/0xc0
  [<ffffffff81060576>] warn_slowpath_fmt+0x46/0x50
  [<ffffffff8100f942>] ? check_events+0x12/0x20
  [<ffffffff813c5bf1>] evtchn_from_irq+0x41/0x50
  [<ffffffff813c6302>] notify_remote_via_irq+0x12/0x50
  [<ffffffff8137e016>] xenfb_event_handler+0x26/0x50
  [<ffffffff8110b0fc>] handle_irq_event_percpu+0x6c/0x390
  [<ffffffff8110b468>] handle_irq_event+0x48/0x70
  [<ffffffff8110e7b7>] handle_edge_irq+0x77/0x110
  [<ffffffff813c56f3>] __xen_evtchn_do_upcall+0x1c3/0x290
  [<ffffffff813c782f>] xen_evtchn_do_upcall+0x2f/0x50
  [<ffffffff816a7a3e>] xen_do_hypervisor_callback+0x1e/0x30
  <EOI>  [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
  [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
  [<ffffffff813c9ed7>] ? xb_read+0xd7/0x190
  [<ffffffff811a2359>] ? kmem_cache_alloc_trace+0xd9/0x240
  [<ffffffff813cb170>] ? unregister_xenbus_watch+0x1d0/0x1d0
  [<ffffffff813cb1f9>] ? xenbus_thread+0x89/0x2b0
  [<ffffffff81089ac7>] ? kthread+0xb7/0xc0
  [<ffffffff810cd02d>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff816a78f4>] ? kernel_thread_helper+0x4/0x10
  [<ffffffff8169dcb4>] ? retint_restore_args+0x13/0x13
  [<ffffffff816a78f0>] ? gs_change+0x13/0x13


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 05:49:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwoly-00021L-Tl; Mon, 13 Feb 2012 05:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rwolx-00021G-RD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 05:48:22 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329112094!14022469!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMTI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 13 Feb 2012 05:48:15 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-11.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 05:48:15 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZB00IOBHG23Z@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:48:03 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZB00BQSHG2NI@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:48:02 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHB36791; Mon,
	13 Feb 2012 13:47:23 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 13 Feb 2012 13:47:15 +0800
Received: from h00166998 (10.166.80.196) by szxeml406-hub.china.huawei.com
	(10.82.67.93) with Microsoft SMTP Server id 14.1.323.3; Mon,
	13 Feb 2012 13:47:01 +0800
Date: Mon, 13 Feb 2012 13:47:00 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120210164010.GA10009@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <002201ccea12$e83c0420$b8b40c60$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczoErWOFMZXj8b0QM6cZUa6Ipg7pAB/+bFQ
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Saturday, February 11, 2012 12:40 AM
> To: hongkaixing@huawei.com
> Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> hanweidong@huawei.com
> Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> 
> On Thu, Feb 09, hongkaixing@huawei.com wrote:
> 
> > xenpaging:close domU's event channel and free port
> >
> > Every domain (X86 64 bit)has 4096 event channels.In source code,
> > domU's event channel is allocated in mem_event_enable(),but just
> > unbind dom0's event channel in xenpaging_teardown().This bug will
> > result in that we can not use xenpaging after reopening it for 4096
> > times.We should free domU's event channel in mem_event_disable().so
> > that we can reuse the port.
> 
> Does that fix a real bug?
> 
> xenpaging_teardown() does both xc_mem_paging_disable() and
> xc_evtchn_unbind(). The former fails often because the domain is gone
> and so it doesnt even reach the function in mem_event.c.
> The latter is called unconditionally.

   I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.
so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
(28 = No space left on device): Internal error".Because there is no available free port for this domU.
Only the port's state is ECS_FREE,then it can be allocated by get_free_port();


> 
> Also I would expect that once xenpaging exits the kernel driver does a
> cleanup of all used ports. I havent checked wether thats true.
> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 05:49:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwoly-00021L-Tl; Mon, 13 Feb 2012 05:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rwolx-00021G-RD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 05:48:22 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329112094!14022469!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMTI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 13 Feb 2012 05:48:15 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-11.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 05:48:15 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZB00IOBHG23Z@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:48:03 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZB00BQSHG2NI@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:48:02 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHB36791; Mon,
	13 Feb 2012 13:47:23 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 13 Feb 2012 13:47:15 +0800
Received: from h00166998 (10.166.80.196) by szxeml406-hub.china.huawei.com
	(10.82.67.93) with Microsoft SMTP Server id 14.1.323.3; Mon,
	13 Feb 2012 13:47:01 +0800
Date: Mon, 13 Feb 2012 13:47:00 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120210164010.GA10009@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <002201ccea12$e83c0420$b8b40c60$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczoErWOFMZXj8b0QM6cZUa6Ipg7pAB/+bFQ
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Saturday, February 11, 2012 12:40 AM
> To: hongkaixing@huawei.com
> Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> hanweidong@huawei.com
> Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> 
> On Thu, Feb 09, hongkaixing@huawei.com wrote:
> 
> > xenpaging:close domU's event channel and free port
> >
> > Every domain (X86 64 bit)has 4096 event channels.In source code,
> > domU's event channel is allocated in mem_event_enable(),but just
> > unbind dom0's event channel in xenpaging_teardown().This bug will
> > result in that we can not use xenpaging after reopening it for 4096
> > times.We should free domU's event channel in mem_event_disable().so
> > that we can reuse the port.
> 
> Does that fix a real bug?
> 
> xenpaging_teardown() does both xc_mem_paging_disable() and
> xc_evtchn_unbind(). The former fails often because the domain is gone
> and so it doesnt even reach the function in mem_event.c.
> The latter is called unconditionally.

   I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.
so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
(28 = No space left on device): Internal error".Because there is no available free port for this domU.
Only the port's state is ECS_FREE,then it can be allocated by get_free_port();


> 
> Also I would expect that once xenpaging exits the kernel driver does a
> cleanup of all used ports. I havent checked wether thats true.
> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 06:54:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 06: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.xensource.com>)
	id 1RwpnV-0002Qo-2f; Mon, 13 Feb 2012 06:54:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwpnT-0002Qj-DC
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 06:53:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329116033!13976909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1706 invoked from network); 13 Feb 2012 06:53:53 -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 Feb 2012 06:53:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,410,1325462400"; d="scan'208";a="10648145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 06:53:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 06:53:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RwpnM-0003Jv-FD;
	Mon, 13 Feb 2012 06:53:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RwpnM-0000zR-09;
	Mon, 13 Feb 2012 06:53:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11944-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 06:53:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11944: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11944 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11944/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11943

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9ad1e42c341b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 06:54:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 06: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.xensource.com>)
	id 1RwpnV-0002Qo-2f; Mon, 13 Feb 2012 06:54:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwpnT-0002Qj-DC
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 06:53:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329116033!13976909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1706 invoked from network); 13 Feb 2012 06:53:53 -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 Feb 2012 06:53:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,410,1325462400"; d="scan'208";a="10648145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 06:53:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 06:53:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RwpnM-0003Jv-FD;
	Mon, 13 Feb 2012 06:53:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RwpnM-0000zR-09;
	Mon, 13 Feb 2012 06:53:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11944-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 06:53:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11944: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11944 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11944/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11943

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9ad1e42c341b
baseline version:
 xen                  9ad1e42c341b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 07:15:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 07:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwq7g-0002jv-Tn; Mon, 13 Feb 2012 07:14:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1Rwq7e-0002jm-LY
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:14:50 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329117284!15069040!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16070 invoked from network); 13 Feb 2012 07:14:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 07:14:44 -0000
Received: by werb14 with SMTP id b14so14204864wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 12 Feb 2012 23:14:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=RxIdl7JtTcWcBUFHCbuKGsvjoVeUCIpa8Dj3TjVj/8E=;
	b=pdrRtK7d2mrEhvcz8aabZQrSUt3X13UkwErTl1jM2u+kT1jxYr97CxN7yGeJCvjr7z
	yuzevGkdZBRnYdX6EMwUncdtpOMjfr9kDgrxbpVW6UrCPx48UO/FHv/JzdtG3ld8CRM1
	DydiTW8s9fEfIKqEbr+yk6A/9ItFZALylhyPc=
MIME-Version: 1.0
Received: by 10.180.107.68 with SMTP id ha4mr22535448wib.9.1329117284182; Sun,
	12 Feb 2012 23:14:44 -0800 (PST)
Received: by 10.223.4.215 with HTTP; Sun, 12 Feb 2012 23:14:44 -0800 (PST)
In-Reply-To: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
References: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Date: Mon, 13 Feb 2012 16:14:44 +0900
Message-ID: <CAP2B85_WGsFdAhOuywum9tvZcMG1xfV_y2tFfL_MzWAN2cpw8A@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Javanshir Farzin <j.farzin@yahoo.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] which linux distribution for XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4463687457721216064=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4463687457721216064==
Content-Type: multipart/alternative; boundary=e89a8f13ec3496ab8904b8d33bc6

--e89a8f13ec3496ab8904b8d33bc6
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 12, 2012 at 8:02 AM, Javanshir Farzin <j.farzin@yahoo.com>wrote:

> Hello,
> I want to change XEN source code after that I will copile it, and I will
> survey change's effect. I have ubuntu 11.4 and centos 5.2. Which of the
> linux distributions is suitable for my job?
> thanks


I run ubuntu Kernel 2.6.32 without problems. Exactly what do you intend to
do that would requiere a specific version of Linux?


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank for
notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+

--e89a8f13ec3496ab8904b8d33bc6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Feb 12, 2012 at 8:02 AM, Javansh=
ir Farzin <span dir=3D"ltr">&lt;<a href=3D"mailto:j.farzin@yahoo.com">j.far=
zin@yahoo.com</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">
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td vali=
gn=3D"top" style=3D"font:inherit">Hello,<br>I want to change XEN source cod=
e after that I will copile it, and I will survey change&#39;s effect. I hav=
e ubuntu 11.4 and centos 5.2. Which of the linux distributions is suitable =
for my job?<br>
thanks</td></tr></tbody></table></blockquote><div><br></div><div>I run ubun=
tu=A0Kernel 2.6.32=A0without problems. Exactly what do you intend to do tha=
t would requiere a specific version of Linux?</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>+-=3D=3D=
=3D=3D=3D---------------------------+<br>| +-------------------------------=
--+ | This space intentionally blank for notetaking.<br>| |=A0=A0 | Daniel =
Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | <br>
| |=A0=A0 | Consultant/Programmer.|<br>| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |<br>+----------------------------------=
---+<br><br>

--e89a8f13ec3496ab8904b8d33bc6--


--===============4463687457721216064==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4463687457721216064==--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 07:15:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 07:15:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwq7g-0002jv-Tn; Mon, 13 Feb 2012 07:14:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1Rwq7e-0002jm-LY
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:14:50 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329117284!15069040!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16070 invoked from network); 13 Feb 2012 07:14:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 07:14:44 -0000
Received: by werb14 with SMTP id b14so14204864wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 12 Feb 2012 23:14:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=RxIdl7JtTcWcBUFHCbuKGsvjoVeUCIpa8Dj3TjVj/8E=;
	b=pdrRtK7d2mrEhvcz8aabZQrSUt3X13UkwErTl1jM2u+kT1jxYr97CxN7yGeJCvjr7z
	yuzevGkdZBRnYdX6EMwUncdtpOMjfr9kDgrxbpVW6UrCPx48UO/FHv/JzdtG3ld8CRM1
	DydiTW8s9fEfIKqEbr+yk6A/9ItFZALylhyPc=
MIME-Version: 1.0
Received: by 10.180.107.68 with SMTP id ha4mr22535448wib.9.1329117284182; Sun,
	12 Feb 2012 23:14:44 -0800 (PST)
Received: by 10.223.4.215 with HTTP; Sun, 12 Feb 2012 23:14:44 -0800 (PST)
In-Reply-To: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
References: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Date: Mon, 13 Feb 2012 16:14:44 +0900
Message-ID: <CAP2B85_WGsFdAhOuywum9tvZcMG1xfV_y2tFfL_MzWAN2cpw8A@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Javanshir Farzin <j.farzin@yahoo.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] which linux distribution for XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4463687457721216064=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4463687457721216064==
Content-Type: multipart/alternative; boundary=e89a8f13ec3496ab8904b8d33bc6

--e89a8f13ec3496ab8904b8d33bc6
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 12, 2012 at 8:02 AM, Javanshir Farzin <j.farzin@yahoo.com>wrote:

> Hello,
> I want to change XEN source code after that I will copile it, and I will
> survey change's effect. I have ubuntu 11.4 and centos 5.2. Which of the
> linux distributions is suitable for my job?
> thanks


I run ubuntu Kernel 2.6.32 without problems. Exactly what do you intend to
do that would requiere a specific version of Linux?


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank for
notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+

--e89a8f13ec3496ab8904b8d33bc6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Feb 12, 2012 at 8:02 AM, Javansh=
ir Farzin <span dir=3D"ltr">&lt;<a href=3D"mailto:j.farzin@yahoo.com">j.far=
zin@yahoo.com</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">
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td vali=
gn=3D"top" style=3D"font:inherit">Hello,<br>I want to change XEN source cod=
e after that I will copile it, and I will survey change&#39;s effect. I hav=
e ubuntu 11.4 and centos 5.2. Which of the linux distributions is suitable =
for my job?<br>
thanks</td></tr></tbody></table></blockquote><div><br></div><div>I run ubun=
tu=A0Kernel 2.6.32=A0without problems. Exactly what do you intend to do tha=
t would requiere a specific version of Linux?</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>+-=3D=3D=
=3D=3D=3D---------------------------+<br>| +-------------------------------=
--+ | This space intentionally blank for notetaking.<br>| |=A0=A0 | Daniel =
Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | <br>
| |=A0=A0 | Consultant/Programmer.|<br>| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |<br>+----------------------------------=
---+<br><br>

--e89a8f13ec3496ab8904b8d33bc6--


--===============4463687457721216064==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4463687457721216064==--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 07:18:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 07: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.xensource.com>)
	id 1RwqAd-0002pV-HY; Mon, 13 Feb 2012 07:17:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RwqAc-0002pF-Fh
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:17:54 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329117404!60797043!1
X-Originating-IP: [74.125.82.171]
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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19781 invoked from network); 13 Feb 2012 07:16:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 07:16:44 -0000
Received: by werb14 with SMTP id b14so14209694wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 12 Feb 2012 23:17:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=hRvj816KsLJNkDTqnj822EJXgJAa5gnXhP0OUCA97eQ=;
	b=CYEesqja0AVjMf3ykw6D4cccLzgArnFTHaeAI2QkxNexiSq9FXtwueZtJ8GtYgWVPr
	X3tmlr2PTJcw5QTx8AW29G/BxWOvrkKwUMrkMiq7ApTn/Qh6ptC+IiRflr2Se6Ay0wEv
	Cf58CGCojLE1nxtobk456sTmgIyDsWEHlqdc0=
MIME-Version: 1.0
Received: by 10.180.14.193 with SMTP id r1mr16342188wic.9.1329117467989; Sun,
	12 Feb 2012 23:17:47 -0800 (PST)
Received: by 10.223.4.215 with HTTP; Sun, 12 Feb 2012 23:17:47 -0800 (PST)
In-Reply-To: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
References: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
Date: Mon, 13 Feb 2012 16:17:47 +0900
Message-ID: <CAP2B859QxrFz8ziHxZswp8P__v84zKn73L-eC3Dj=eQ79Xc7sA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Setting up an Event Channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Feb 11, 2012 at 8:28 PM, Nupur Ghatnekar
<nupurghatnekar@gmail.com> wrote:
> I have been trying to setup an event channel. Following this blog
> http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip65=
5z-5/
>
> But few of the functions used seem deprecated.
> Any pointers as to how to progress?
>

In what context are you trying to set up the event channel? Is it a
PV-guest a HVM Guest? Can you issue hypercalls?

Daniel

> --
>
> Nupur Ghatnekar
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 07:18:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 07: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.xensource.com>)
	id 1RwqAd-0002pV-HY; Mon, 13 Feb 2012 07:17:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RwqAc-0002pF-Fh
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:17:54 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329117404!60797043!1
X-Originating-IP: [74.125.82.171]
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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19781 invoked from network); 13 Feb 2012 07:16:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 07:16:44 -0000
Received: by werb14 with SMTP id b14so14209694wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 12 Feb 2012 23:17:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=hRvj816KsLJNkDTqnj822EJXgJAa5gnXhP0OUCA97eQ=;
	b=CYEesqja0AVjMf3ykw6D4cccLzgArnFTHaeAI2QkxNexiSq9FXtwueZtJ8GtYgWVPr
	X3tmlr2PTJcw5QTx8AW29G/BxWOvrkKwUMrkMiq7ApTn/Qh6ptC+IiRflr2Se6Ay0wEv
	Cf58CGCojLE1nxtobk456sTmgIyDsWEHlqdc0=
MIME-Version: 1.0
Received: by 10.180.14.193 with SMTP id r1mr16342188wic.9.1329117467989; Sun,
	12 Feb 2012 23:17:47 -0800 (PST)
Received: by 10.223.4.215 with HTTP; Sun, 12 Feb 2012 23:17:47 -0800 (PST)
In-Reply-To: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
References: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
Date: Mon, 13 Feb 2012 16:17:47 +0900
Message-ID: <CAP2B859QxrFz8ziHxZswp8P__v84zKn73L-eC3Dj=eQ79Xc7sA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Setting up an Event Channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Feb 11, 2012 at 8:28 PM, Nupur Ghatnekar
<nupurghatnekar@gmail.com> wrote:
> I have been trying to setup an event channel. Following this blog
> http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip65=
5z-5/
>
> But few of the functions used seem deprecated.
> Any pointers as to how to progress?
>

In what context are you trying to set up the event channel? Is it a
PV-guest a HVM Guest? Can you issue hypercalls?

Daniel

> --
>
> Nupur Ghatnekar
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 08:31:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 08: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.xensource.com>)
	id 1RwrJW-0004FB-VU; Mon, 13 Feb 2012 08:31:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RwrJU-0004F6-WA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:31:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329121861!13041013!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzc4NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzc4NjQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26006 invoked from network); 13 Feb 2012 08:31:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 13 Feb 2012 08:31:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329121861; l=480;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7I23YCT85g2zm6S2I/UsG3Ag+pw=;
	b=uE7QI12CUKjpPqNz5SPIvi5VqYbGLJabBuViyIkdhUpABvlb2WjogkhfbqlDw83OMzB
	9OlmvkNkOgBZXvIqlIAm2EhJBBf5zg5JkhKJ6Wco2jp1+55FojYECftFQNA4C36fmA2Gm
	1DcUVvFK1FSVhrc5B61X6tUZnx/shuC3jCE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7tEHQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-062.pools.arcor-ip.net [84.57.87.62])
	by post.strato.de (mrclete mo57) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w05125o1D7SrW8 ;
	Mon, 13 Feb 2012 09:30:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A97AD18637; Mon, 13 Feb 2012 09:30:57 +0100 (CET)
Date: Mon, 13 Feb 2012 09:30:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120213083057.GA4964@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
	<4F355B260200007800072704@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F355B260200007800072704@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> > Regarding these messages, are they guest addresses?
> > 
> > (XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4
> 
> No, these are hypervisor ones.

These are the functions they belong to:

(XEN) traps.c:3131: GPF (0000): ffff82c4801d61ec -> ffff82c48022aa2e
(XEN) do_general_protection: ffff82c4801d61ec vmx_msr_read_intercept+0x2d8/0x358
(XEN) do_general_protection: ffff82c48022aa2e vmac+0x6c8/0x99a

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 08:31:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 08: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.xensource.com>)
	id 1RwrJW-0004FB-VU; Mon, 13 Feb 2012 08:31:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RwrJU-0004F6-WA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:31:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329121861!13041013!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzc4NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzc4NjQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26006 invoked from network); 13 Feb 2012 08:31:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 13 Feb 2012 08:31:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329121861; l=480;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7I23YCT85g2zm6S2I/UsG3Ag+pw=;
	b=uE7QI12CUKjpPqNz5SPIvi5VqYbGLJabBuViyIkdhUpABvlb2WjogkhfbqlDw83OMzB
	9OlmvkNkOgBZXvIqlIAm2EhJBBf5zg5JkhKJ6Wco2jp1+55FojYECftFQNA4C36fmA2Gm
	1DcUVvFK1FSVhrc5B61X6tUZnx/shuC3jCE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7tEHQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-062.pools.arcor-ip.net [84.57.87.62])
	by post.strato.de (mrclete mo57) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w05125o1D7SrW8 ;
	Mon, 13 Feb 2012 09:30:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A97AD18637; Mon, 13 Feb 2012 09:30:57 +0100 (CET)
Date: Mon, 13 Feb 2012 09:30:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120213083057.GA4964@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
	<4F355B260200007800072704@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F355B260200007800072704@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, Jan Beulich wrote:

> > Regarding these messages, are they guest addresses?
> > 
> > (XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4
> 
> No, these are hypervisor ones.

These are the functions they belong to:

(XEN) traps.c:3131: GPF (0000): ffff82c4801d61ec -> ffff82c48022aa2e
(XEN) do_general_protection: ffff82c4801d61ec vmx_msr_read_intercept+0x2d8/0x358
(XEN) do_general_protection: ffff82c48022aa2e vmac+0x6c8/0x99a

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rws4l-0004Wr-6D; Mon, 13 Feb 2012 09:19:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1Rws4i-0004Wm-UW
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:19:57 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329124789!11252291!1
X-Originating-IP: [209.85.220.193]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4422 invoked from network); 13 Feb 2012 09:19:50 -0000
Received: from mail-vx0-f193.google.com (HELO mail-vx0-f193.google.com)
	(209.85.220.193)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 09:19:50 -0000
Received: by vcmm1 with SMTP id m1so340304vcm.0
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 01:19:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=tsULlEok+2MK21c/9VdfPhWWxi/71B5aVV+zX+47zow=;
	b=syvXiI5Egx5WpA1lcFzxSBL5T1EKnvtm4B3Q/tFIlnM9RpGiTGLCFghXd29gdcVRod
	iHhkEr/FNfD6goFPNCn1fVFo28EGtubQQpI47SslQYdMArntIgIWx38Bw3FmKUXRblmK
	6MiYYww5JlCcwU5KVRZ0yQrn5pfIM6z5GkoQQ=
MIME-Version: 1.0
Received: by 10.220.148.146 with SMTP id p18mr8688279vcv.6.1329124789146; Mon,
	13 Feb 2012 01:19:49 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Mon, 13 Feb 2012 01:19:49 -0800 (PST)
Date: Mon, 13 Feb 2012 17:19:49 +0800
Message-ID: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] What's the function of evtchn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4134173660047492556=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4134173660047492556==
Content-Type: multipart/alternative; boundary=f46d043bdfb8eb538004b8d4fa00

--f46d043bdfb8eb538004b8d4fa00
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I'm reading some code of Xen-4.0-unstable and I occurred some obstacle when
reading xen-unstable\unmodified_drivers\linux-2.6\platform-pci\evtchn.c. I
don't exactly know what evtchn is, so I can't understand some of the code.
I search evtchn in google but get few information.

Can anyone help? Thanks.

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--f46d043bdfb8eb538004b8d4fa00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I&#39;m reading some code of Xen-4.0-unstable and I=A0occurred=
=A0some obstacle when reading xen-unstable\unmodified_drivers\linux-2.6\pla=
tform-pci\evtchn.c. I don&#39;t exactly know what evtchn is, so I can&#39;t=
 understand some of the code. I search evtchn in google but get few informa=
tion.</div>
<div><br></div><div>Can anyone help? Thanks.<br clear=3D"all"><div><br></di=
v>-- <br>Chunqi Li<br>Department of Computer Science<br>School of EECS<br>P=
eking University<br>Beijing, China<br>
</div>

--f46d043bdfb8eb538004b8d4fa00--


--===============4134173660047492556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4134173660047492556==--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rws4l-0004Wr-6D; Mon, 13 Feb 2012 09:19:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1Rws4i-0004Wm-UW
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:19:57 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329124789!11252291!1
X-Originating-IP: [209.85.220.193]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4422 invoked from network); 13 Feb 2012 09:19:50 -0000
Received: from mail-vx0-f193.google.com (HELO mail-vx0-f193.google.com)
	(209.85.220.193)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 09:19:50 -0000
Received: by vcmm1 with SMTP id m1so340304vcm.0
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 01:19:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=tsULlEok+2MK21c/9VdfPhWWxi/71B5aVV+zX+47zow=;
	b=syvXiI5Egx5WpA1lcFzxSBL5T1EKnvtm4B3Q/tFIlnM9RpGiTGLCFghXd29gdcVRod
	iHhkEr/FNfD6goFPNCn1fVFo28EGtubQQpI47SslQYdMArntIgIWx38Bw3FmKUXRblmK
	6MiYYww5JlCcwU5KVRZ0yQrn5pfIM6z5GkoQQ=
MIME-Version: 1.0
Received: by 10.220.148.146 with SMTP id p18mr8688279vcv.6.1329124789146; Mon,
	13 Feb 2012 01:19:49 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Mon, 13 Feb 2012 01:19:49 -0800 (PST)
Date: Mon, 13 Feb 2012 17:19:49 +0800
Message-ID: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] What's the function of evtchn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4134173660047492556=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4134173660047492556==
Content-Type: multipart/alternative; boundary=f46d043bdfb8eb538004b8d4fa00

--f46d043bdfb8eb538004b8d4fa00
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I'm reading some code of Xen-4.0-unstable and I occurred some obstacle when
reading xen-unstable\unmodified_drivers\linux-2.6\platform-pci\evtchn.c. I
don't exactly know what evtchn is, so I can't understand some of the code.
I search evtchn in google but get few information.

Can anyone help? Thanks.

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--f46d043bdfb8eb538004b8d4fa00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I&#39;m reading some code of Xen-4.0-unstable and I=A0occurred=
=A0some obstacle when reading xen-unstable\unmodified_drivers\linux-2.6\pla=
tform-pci\evtchn.c. I don&#39;t exactly know what evtchn is, so I can&#39;t=
 understand some of the code. I search evtchn in google but get few informa=
tion.</div>
<div><br></div><div>Can anyone help? Thanks.<br clear=3D"all"><div><br></di=
v>-- <br>Chunqi Li<br>Department of Computer Science<br>School of EECS<br>P=
eking University<br>Beijing, China<br>
</div>

--f46d043bdfb8eb538004b8d4fa00--


--===============4134173660047492556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4134173660047492556==--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwsFT-0004gj-Bb; Mon, 13 Feb 2012 09:31: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 1RwsFS-0004ge-5P
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:31:02 +0000
Received: from [85.158.139.83:26741] by server-2.bemta-5.messagelabs.com id
	E3/82-20725-558D83F4; Mon, 13 Feb 2012 09:31:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329125460!14796408!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10891 invoked from network); 13 Feb 2012 09:31: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 09:31:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 09:30:59 +0000
Message-Id: <4F38E65D0200007800072771@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 09:30:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
In-Reply-To: <20120210212846.GA31185@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 10, Jan Beulich wrote:
> 
>> >>> On 09.02.12 at 19:02, Olaf Hering <olaf@aepfle.de> wrote:
>> > On Mon, Jan 30, Jan Beulich wrote:
>> > 
>> >> Below/attached a draft patch (compile tested only), handling save/
>> >> restore of the bank count, but not allowing for a config setting to
>> >> specify its initial value (yet).
>> > 
>> > Does it take more than just applying this patch for src+dst host and
>> > migrate a hvm guest? I see no difference, the mce warning is still
>> > there.
>> 
>> No, it shouldn't require anything else. Could you add a printk() each
>> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
>> (and at once checking that they actually get executed? I was under
>> the impression that adding save records for HVM is a simple drop-in
>> exercise these days...
> 
> These functions are called for dom0, but not for domU. And as a result
> arch.nr_vmce_banks remains zero. I assume the guest needs to be
> initialized in some way as well, and that does not happen?

These functions should be called with Dom0 being current domain,
but the struct domain * argument should certainly be that of the
DomU being saved/restored.

Guest initialization happens in vmce_init_vcpu(), called from
vcpu_initialise() (irrespective of the kind of domain, i.e. equally for
PV and HVM).

I spotted another problem with the patch though - MCG_CAP reads
aren't reflecting the possibly non-host bank count. I'm in the process
of addressing this, but the whole MCG_* handling is bogus as being
per-domain instead of per-vCPU (and at least MCG_CAP lacking
save/restore too).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwsFT-0004gj-Bb; Mon, 13 Feb 2012 09:31: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 1RwsFS-0004ge-5P
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:31:02 +0000
Received: from [85.158.139.83:26741] by server-2.bemta-5.messagelabs.com id
	E3/82-20725-558D83F4; Mon, 13 Feb 2012 09:31:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329125460!14796408!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10891 invoked from network); 13 Feb 2012 09:31: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 09:31:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 09:30:59 +0000
Message-Id: <4F38E65D0200007800072771@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 09:30:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
In-Reply-To: <20120210212846.GA31185@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 10, Jan Beulich wrote:
> 
>> >>> On 09.02.12 at 19:02, Olaf Hering <olaf@aepfle.de> wrote:
>> > On Mon, Jan 30, Jan Beulich wrote:
>> > 
>> >> Below/attached a draft patch (compile tested only), handling save/
>> >> restore of the bank count, but not allowing for a config setting to
>> >> specify its initial value (yet).
>> > 
>> > Does it take more than just applying this patch for src+dst host and
>> > migrate a hvm guest? I see no difference, the mce warning is still
>> > there.
>> 
>> No, it shouldn't require anything else. Could you add a printk() each
>> to vmce_{save,load}_vcpu_ctxt() printing what gets saved/restored
>> (and at once checking that they actually get executed? I was under
>> the impression that adding save records for HVM is a simple drop-in
>> exercise these days...
> 
> These functions are called for dom0, but not for domU. And as a result
> arch.nr_vmce_banks remains zero. I assume the guest needs to be
> initialized in some way as well, and that does not happen?

These functions should be called with Dom0 being current domain,
but the struct domain * argument should certainly be that of the
DomU being saved/restored.

Guest initialization happens in vmce_init_vcpu(), called from
vcpu_initialise() (irrespective of the kind of domain, i.e. equally for
PV and HVM).

I spotted another problem with the patch though - MCG_CAP reads
aren't reflecting the possibly non-host bank count. I'm in the process
of addressing this, but the whole MCG_* handling is bogus as being
per-domain instead of per-vCPU (and at least MCG_CAP lacking
save/restore too).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:36:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwsKC-0004oV-2q; Mon, 13 Feb 2012 09:35: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 1RwsKA-0004oQ-SG
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:35:54 +0000
Received: from [85.158.139.83:47048] by server-4.bemta-5.messagelabs.com id
	DD/C0-28576-979D83F4; Mon, 13 Feb 2012 09:35:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329125752!7467171!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19401 invoked from network); 13 Feb 2012 09:35:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 09:35:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 09:35:52 +0000
Message-Id: <4F38E784020000780007277C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 09:35:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>Guest initialization happens in vmce_init_vcpu(), called from
>vcpu_initialise() (irrespective of the kind of domain, i.e. equally for
>PV and HVM).

And wrong I was - HVM guests get filtered much earlier in that function.
I'll get back with an updated patch hopefully soon.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:36:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwsKC-0004oV-2q; Mon, 13 Feb 2012 09:35: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 1RwsKA-0004oQ-SG
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:35:54 +0000
Received: from [85.158.139.83:47048] by server-4.bemta-5.messagelabs.com id
	DD/C0-28576-979D83F4; Mon, 13 Feb 2012 09:35:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329125752!7467171!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19401 invoked from network); 13 Feb 2012 09:35:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 09:35:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 09:35:52 +0000
Message-Id: <4F38E784020000780007277C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 09:35:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>Guest initialization happens in vmce_init_vcpu(), called from
>vcpu_initialise() (irrespective of the kind of domain, i.e. equally for
>PV and HVM).

And wrong I was - HVM guests get filtered much earlier in that function.
I'll get back with an updated patch hopefully soon.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:39:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09: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.xensource.com>)
	id 1RwsN4-0004w4-Lk; Mon, 13 Feb 2012 09:38:54 +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 1RwsN2-0004vq-Hq
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:38:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329125876!53973709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23258 invoked from network); 13 Feb 2012 09:37:56 -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 Feb 2012 09:37:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10653357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 09:38:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 09:38:46 +0000
Message-ID: <1329125924.31256.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "=?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <Chunqi Li>" <yzt356@gmail.com>
Date: Mon, 13 Feb 2012 09:38:44 +0000
In-Reply-To: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
References: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] What's the function of evtchn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAyLTEzIGF0IDA5OjE5ICswMDAwLCDmnY7mmKXlpYcgd3JvdGU6Cj4gSGkg
YWxsLAo+IEknbSByZWFkaW5nIHNvbWUgY29kZSBvZiBYZW4tNC4wLXVuc3RhYmxlIGFuZCBJIG9j
Y3VycmVkIHNvbWUgb2JzdGFjbGUKPiB3aGVuIHJlYWRpbmcgeGVuLXVuc3RhYmxlXHVubW9kaWZp
ZWRfZHJpdmVyc1xsaW51eC0yLjZccGxhdGZvcm0tcGNpCj4gXGV2dGNobi5jLiBJIGRvbid0IGV4
YWN0bHkga25vdyB3aGF0IGV2dGNobiBpcywgc28gSSBjYW4ndCB1bmRlcnN0YW5kCj4gc29tZSBv
ZiB0aGUgY29kZS4gSSBzZWFyY2ggZXZ0Y2huIGluIGdvb2dsZSBidXQgZ2V0IGZldyBpbmZvcm1h
dGlvbi4KClRyeSBzZWFyY2hpbmcgZm9yICJldmVudCBjaGFubmVsIiBmb3Igd2hpY2ggZXZ0Y2hu
IGlzIHRoZSBhYmJyZXZpYXRpb24uCkV2ZW50IGNoYW5uZWxzIGFyZSB0aGUgWGVuIFBWIElSUSBt
ZWNoYW5pc20uCgpUaGUgcGFydGljdWxhciBmaWxlIHlvdSBoYXZlIGZvdW5kIGlzIHBhcnQgb2Yg
dGhlIGluZnJhc3RydWN0dXJlIGZvciBQVgpkcml2ZXJzIHJ1bm5pbmcgaW4gZnVsbHkgdmlydHVh
bGlzZWQgZ3Vlc3RzLgoKSWFuLgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:39:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09: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.xensource.com>)
	id 1RwsN4-0004w4-Lk; Mon, 13 Feb 2012 09:38:54 +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 1RwsN2-0004vq-Hq
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:38:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329125876!53973709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23258 invoked from network); 13 Feb 2012 09:37:56 -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 Feb 2012 09:37:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10653357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 09:38:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 09:38:46 +0000
Message-ID: <1329125924.31256.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "=?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <Chunqi Li>" <yzt356@gmail.com>
Date: Mon, 13 Feb 2012 09:38:44 +0000
In-Reply-To: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
References: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] What's the function of evtchn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAyLTEzIGF0IDA5OjE5ICswMDAwLCDmnY7mmKXlpYcgd3JvdGU6Cj4gSGkg
YWxsLAo+IEknbSByZWFkaW5nIHNvbWUgY29kZSBvZiBYZW4tNC4wLXVuc3RhYmxlIGFuZCBJIG9j
Y3VycmVkIHNvbWUgb2JzdGFjbGUKPiB3aGVuIHJlYWRpbmcgeGVuLXVuc3RhYmxlXHVubW9kaWZp
ZWRfZHJpdmVyc1xsaW51eC0yLjZccGxhdGZvcm0tcGNpCj4gXGV2dGNobi5jLiBJIGRvbid0IGV4
YWN0bHkga25vdyB3aGF0IGV2dGNobiBpcywgc28gSSBjYW4ndCB1bmRlcnN0YW5kCj4gc29tZSBv
ZiB0aGUgY29kZS4gSSBzZWFyY2ggZXZ0Y2huIGluIGdvb2dsZSBidXQgZ2V0IGZldyBpbmZvcm1h
dGlvbi4KClRyeSBzZWFyY2hpbmcgZm9yICJldmVudCBjaGFubmVsIiBmb3Igd2hpY2ggZXZ0Y2hu
IGlzIHRoZSBhYmJyZXZpYXRpb24uCkV2ZW50IGNoYW5uZWxzIGFyZSB0aGUgWGVuIFBWIElSUSBt
ZWNoYW5pc20uCgpUaGUgcGFydGljdWxhciBmaWxlIHlvdSBoYXZlIGZvdW5kIGlzIHBhcnQgb2Yg
dGhlIGluZnJhc3RydWN0dXJlIGZvciBQVgpkcml2ZXJzIHJ1bm5pbmcgaW4gZnVsbHkgdmlydHVh
bGlzZWQgZ3Vlc3RzLgoKSWFuLgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:46:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwsUG-00058y-J1; Mon, 13 Feb 2012 09:46:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Tiejun.Chen@windriver.com>) id 1RwsUF-00058n-SH
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:46:20 +0000
X-Env-Sender: Tiejun.Chen@windriver.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329126256!61125098!1
X-Originating-IP: [147.11.1.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29460 invoked from network); 13 Feb 2012 09:44:18 -0000
Received: from mail.windriver.com (HELO mail.windriver.com) (147.11.1.11)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 09:44:18 -0000
Received: from ALA-HCA.corp.ad.wrs.com (ala-hca [147.11.189.40])
	by mail.windriver.com (8.14.3/8.14.3) with ESMTP id q1D9kDqg022278
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 13 Feb 2012 01:46:13 -0800 (PST)
Received: from [128.224.162.71] (128.224.162.71) by ALA-HCA.corp.ad.wrs.com
	(147.11.189.50) with Microsoft SMTP Server id 14.1.255.0;
	Mon, 13 Feb 2012 01:46:13 -0800
Message-ID: <4F38DBC5.9080508@windriver.com>
Date: Mon, 13 Feb 2012 17:45:41 +0800
From: "tiejun.chen" <tiejun.chen@windriver.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: =?UTF-8?B?IuadjuaYpeWlhyA8Q2h1bnFpIExpPiI=?= <yzt356@gmail.com>
References: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
In-Reply-To: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] What's the function of evtchn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

5p2O5pil5aWHIDxDaHVucWkgTGk+IHdyb3RlOgo+IEhpIGFsbCwKPiBJJ20gcmVhZGluZyBzb21l
IGNvZGUgb2YgWGVuLTQuMC11bnN0YWJsZSBhbmQgSSBvY2N1cnJlZCBzb21lIG9ic3RhY2xlIHdo
ZW4KPiByZWFkaW5nIHhlbi11bnN0YWJsZVx1bm1vZGlmaWVkX2RyaXZlcnNcbGludXgtMi42XHBs
YXRmb3JtLXBjaVxldnRjaG4uYy4gSQo+IGRvbid0IGV4YWN0bHkga25vdyB3aGF0IGV2dGNobiBp
cywgc28gSSBjYW4ndCB1bmRlcnN0YW5kIHNvbWUgb2YgdGhlIGNvZGUuCj4gSSBzZWFyY2ggZXZ0
Y2huIGluIGdvb2dsZSBidXQgZ2V0IGZldyBpbmZvcm1hdGlvbi4KPiAKPiBDYW4gYW55b25lIGhl
bHA/IFRoYW5rcy4KClhlbiBpbXBsZW1lbnRzIG9uZSBhc3luY2hyb25vdXMgZXZlbnQgY29tbXVu
aWNhdGlvbiBtZWNoYW5pc20sIEV2ZW50IENoYW5uZWwuCkl0cyB1c2VkIHRvIGNvbW11bmljYXRl
ZCBiZXR3ZWVuIFhlbiBoeXBlcnZpc29yIGFuZCBEb21haW4sIG9yIGJldHdlZW4gRG9tYWluCmFu
ZCBEb21haW4uCgpUaWVqdW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Feb 13 09:46:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 09:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwsUG-00058y-J1; Mon, 13 Feb 2012 09:46:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Tiejun.Chen@windriver.com>) id 1RwsUF-00058n-SH
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 09:46:20 +0000
X-Env-Sender: Tiejun.Chen@windriver.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329126256!61125098!1
X-Originating-IP: [147.11.1.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29460 invoked from network); 13 Feb 2012 09:44:18 -0000
Received: from mail.windriver.com (HELO mail.windriver.com) (147.11.1.11)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 09:44:18 -0000
Received: from ALA-HCA.corp.ad.wrs.com (ala-hca [147.11.189.40])
	by mail.windriver.com (8.14.3/8.14.3) with ESMTP id q1D9kDqg022278
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 13 Feb 2012 01:46:13 -0800 (PST)
Received: from [128.224.162.71] (128.224.162.71) by ALA-HCA.corp.ad.wrs.com
	(147.11.189.50) with Microsoft SMTP Server id 14.1.255.0;
	Mon, 13 Feb 2012 01:46:13 -0800
Message-ID: <4F38DBC5.9080508@windriver.com>
Date: Mon, 13 Feb 2012 17:45:41 +0800
From: "tiejun.chen" <tiejun.chen@windriver.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: =?UTF-8?B?IuadjuaYpeWlhyA8Q2h1bnFpIExpPiI=?= <yzt356@gmail.com>
References: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
In-Reply-To: <CABpY8MJAswwOOeKmei+F3tJXEQsFUDhGX++vW=AXohWxFobQWA@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] What's the function of evtchn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

5p2O5pil5aWHIDxDaHVucWkgTGk+IHdyb3RlOgo+IEhpIGFsbCwKPiBJJ20gcmVhZGluZyBzb21l
IGNvZGUgb2YgWGVuLTQuMC11bnN0YWJsZSBhbmQgSSBvY2N1cnJlZCBzb21lIG9ic3RhY2xlIHdo
ZW4KPiByZWFkaW5nIHhlbi11bnN0YWJsZVx1bm1vZGlmaWVkX2RyaXZlcnNcbGludXgtMi42XHBs
YXRmb3JtLXBjaVxldnRjaG4uYy4gSQo+IGRvbid0IGV4YWN0bHkga25vdyB3aGF0IGV2dGNobiBp
cywgc28gSSBjYW4ndCB1bmRlcnN0YW5kIHNvbWUgb2YgdGhlIGNvZGUuCj4gSSBzZWFyY2ggZXZ0
Y2huIGluIGdvb2dsZSBidXQgZ2V0IGZldyBpbmZvcm1hdGlvbi4KPiAKPiBDYW4gYW55b25lIGhl
bHA/IFRoYW5rcy4KClhlbiBpbXBsZW1lbnRzIG9uZSBhc3luY2hyb25vdXMgZXZlbnQgY29tbXVu
aWNhdGlvbiBtZWNoYW5pc20sIEV2ZW50IENoYW5uZWwuCkl0cyB1c2VkIHRvIGNvbW11bmljYXRl
ZCBiZXR3ZWVuIFhlbiBoeXBlcnZpc29yIGFuZCBEb21haW4sIG9yIGJldHdlZW4gRG9tYWluCmFu
ZCBEb21haW4uCgpUaWVqdW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:18:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10: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.xensource.com>)
	id 1Rwsyp-0005nS-AO; Mon, 13 Feb 2012 10:17:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwsyo-0005nK-Cy
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:17:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329128267!14734421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18194 invoked from network); 13 Feb 2012 10:17:48 -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;
	13 Feb 2012 10:17:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10655424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10: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.213.0;
	Mon, 13 Feb 2012 10:17:46 +0000
Message-ID: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 10:17:45 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This weeks update. I was away last Monday so this covers two weeks worth
of updates. I have dropped things which were marked as DONE in the last
update and added a bunch more DONE (so the list is shrinking!). Please
send me corrections (especially "done").

hypervisor, blockers:
      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich -- more fixes
        required than first thought, patches posted)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * sharing patches posted

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate). (Ian Campbell, DONE).
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                repost pending)
              * topologyinfo datastructure should be a list of tuples,
                not a tuple of lists. (Ian Campbell, DONE)
              * xl to use json for machine readable output instead of
                sexp by default (Ian Campbell, DONE)
              * xl feature parity with xend wrt driver domain support
                (George Dunlap)
              * More formally deprecate xm/xend. Manpage patches already
                in tree. Needs release noting and communication around
                -rc1 to remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla, patches posted?)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? (Roger Pau Monet, patches posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monet)
      * libyajl v2 support (Roger Pau Monet, DONE)
      * Configure/control paging via xl/libxl (Olaf Herring)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini)
      * Nested-virtualisation (currently should be marked
        experimental,likely to release that way? Consider nested-svm
        separate to nested-vmx. Nested-svm is in better shape)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches posted)

Tools, need to decide if pre- or post-4.2 feature:
              * Autoconf (Roger Pau Monet posted a patch, we'll probably
                take this for 4.2)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:18:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10: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.xensource.com>)
	id 1Rwsyp-0005nS-AO; Mon, 13 Feb 2012 10:17:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwsyo-0005nK-Cy
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:17:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329128267!14734421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18194 invoked from network); 13 Feb 2012 10:17:48 -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;
	13 Feb 2012 10:17:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10655424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10: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.213.0;
	Mon, 13 Feb 2012 10:17:46 +0000
Message-ID: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 10:17:45 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This weeks update. I was away last Monday so this covers two weeks worth
of updates. I have dropped things which were marked as DONE in the last
update and added a bunch more DONE (so the list is shrinking!). Please
send me corrections (especially "done").

hypervisor, blockers:
      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich -- more fixes
        required than first thought, patches posted)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * sharing patches posted

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate). (Ian Campbell, DONE).
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                repost pending)
              * topologyinfo datastructure should be a list of tuples,
                not a tuple of lists. (Ian Campbell, DONE)
              * xl to use json for machine readable output instead of
                sexp by default (Ian Campbell, DONE)
              * xl feature parity with xend wrt driver domain support
                (George Dunlap)
              * More formally deprecate xm/xend. Manpage patches already
                in tree. Needs release noting and communication around
                -rc1 to remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla, patches posted?)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? (Roger Pau Monet, patches posted)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monet)
      * libyajl v2 support (Roger Pau Monet, DONE)
      * Configure/control paging via xl/libxl (Olaf Herring)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard, Stefano
                Stabellini)
      * Nested-virtualisation (currently should be marked
        experimental,likely to release that way? Consider nested-svm
        separate to nested-vmx. Nested-svm is in better shape)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches posted)

Tools, need to decide if pre- or post-4.2 feature:
              * Autoconf (Roger Pau Monet posted a patch, we'll probably
                take this for 4.2)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt17-0005yg-Mj; Mon, 13 Feb 2012 10:20:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqqx-0003tY-MV
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:01:40 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329120091!14416772!2
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3831 invoked from network); 13 Feb 2012 08:01:33 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-10.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 08:01:33 -0000
Received: from epcpsbge3.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00GAKNJAR6E0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:01:31 +0900 (KST)
Message-id: <0LZB00GFHNMJR6E0@mailout2.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-82-4f38c35b3628
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 2E.6D.17710.B53C83F4;
	Mon, 13 Feb 2012 17:01:31 +0900 (KST)
Date: Mon, 13 Feb 2012 08:01:31 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080044709@jm77.ryu
Msgkey: 20120213080044709@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075949918@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 09/14]  arm: implement cache ops for ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <23280134.70181329120087475.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgY2FjaGUgb3BzIGZvciBBUk12Nw0KDQogeGVuL2FyY2gvYXJtL3hlbi9N
YWtlZmlsZSAgIHwgICAxICsNCiB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMgfCAgOTQgKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIDIgZmlsZXMgY2hhbmdlZCwgOTUgaW5z
ZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkNCg0KU2lnbmVkLW9mZi1ieTogSmFlbWluIFJ5dSA8
am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgMTVhYWEyMGUxNGJmIHhlbi9hcmNoL2Fy
bS94ZW4vTWFrZWZpbGUNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUJU3VuIEZlYiAx
MiAxMTo1NTowNCAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCVN1
biBGZWIgMTIgMTI6MDU6MTYgMjAxMiArMDkwMA0KQEAgLTIyLDMgKzIyLDQgQEAgb2JqLXkgKz0g
cDJtLm8NCiBvYmoteSArPSBwZXJmbW9uLm8NCiBvYmoteSArPSBwY2kubw0KIG9iai15ICs9IGFy
bXY3Lm8NCitvYmoteSArPSBjYWNoZS12Ny5vDQpkaWZmIC1yIDE1YWFhMjBlMTRiZiB4ZW4vYXJj
aC9hcm0veGVuL2NhY2hlLXY3LlMNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMJU3VuIEZlYiAxMiAx
MjowNToxNiAyMDEyICswOTAwDQpAQCAtMCwwICsxLDk0IEBADQorI2luY2x1ZGUgPHhlbi9saW5r
YWdlLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFzbS9jcHUtb3BzLmg+
DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+
DQorDQorCS5tYWNybyB2N193YXlfb3AsIG9wDQorCWRtYgkJCQkJQCBlbnN1cmUgb3JkZXJpbmcg
d2l0aCBwcmV2aW91cyBtZW1vcnkgYWNjZXNzZXMNCisJbXJjCXAxNSwgMSwgcjAsIGMwLCBjMCwg
MQkJQCByZWFkIGNsaWRyDQorCWFuZHMJcjMsIHIwLCAjMHg3MDAwMDAwCQlAIGV4dHJhY3QgbG9j
IGZyb20gY2xpZHINCisJbW92CXIzLCByMywgbHNyICMyMwkJCUAgbGVmdCBhbGlnbiBsb2MgYml0
IGZpZWxkDQorCWJlcQk1MGYJCQkJQCBpZiBsb2MgaXMgMCwgdGhlbiBubyBuZWVkIHRvIGNsZWFu
DQorCW1vdglyMTAsICMwCQkJCUAgc3RhcnQgY2xlYW4gYXQgY2FjaGUgbGV2ZWwgMA0KKzEwOg0K
KwlhZGQJcjIsIHIxMCwgcjEwLCBsc3IgIzEJCUAgd29yayBvdXQgM3ggY3VycmVudCBjYWNoZSBs
ZXZlbA0KKwltb3YJcjEsIHIwLCBsc3IgcjIJCQlAIGV4dHJhY3QgY2FjaGUgdHlwZSBiaXRzIGZy
b20gY2xpZHINCisJYW5kCXIxLCByMSwgIzcJCQlAIG1hc2sgb2YgdGhlIGJpdHMgZm9yIGN1cnJl
bnQgY2FjaGUgb25seQ0KKwljbXAJcjEsICMyCQkJCUAgc2VlIHdoYXQgY2FjaGUgd2UgaGF2ZSBh
dCB0aGlzIGxldmVsDQorCWJsdAk0MGYJCQkJQCBza2lwIGlmIG5vIGNhY2hlLCBvciBqdXN0IGkt
Y2FjaGUNCisJbWNyCXAxNSwgMiwgcjEwLCBjMCwgYzAsIDAJCUAgc2VsZWN0IGN1cnJlbnQgY2Fj
aGUgbGV2ZWwgaW4gY3Nzcg0KKwlpc2IJCQkJCUAgaXNiIHRvIHN5Y2ggdGhlIG5ldyBjc3NyJmNz
aWRyDQorCW1yYwlwMTUsIDEsIHIxLCBjMCwgYzAsIDAJCUAgcmVhZCB0aGUgbmV3IGNzaWRyDQor
CWFuZAlyMiwgcjEsICM3CQkJQCBleHRyYWN0IHRoZSBsZW5ndGggb2YgdGhlIGNhY2hlIGxpbmVz
DQorCWFkZAlyMiwgcjIsICM0CQkJQCBhZGQgNCAobGluZSBsZW5ndGggb2Zmc2V0KQ0KKwlsZHIJ
cjQsID0weDNmZg0KKwlhbmRzCXI0LCByNCwgcjEsIGxzciAjMwkJQCBmaW5kIG1heGltdW0gbnVt
YmVyIG9uIHRoZSB3YXkgc2l6ZQ0KKwljbHoJcjUsIHI0CQkJCUAgZmluZCBiaXQgcG9zaXRpb24g
b2Ygd2F5IHNpemUgaW5jcmVtZW50DQorCWxkcglyNywgPTB4N2ZmZg0KKwlhbmRzCXI3LCByNywg
cjEsIGxzciAjMTMJCUAgZXh0cmFjdCBtYXggbnVtYmVyIG9mIHRoZSBpbmRleCBzaXplDQorMjA6
DQorCW1vdglyOSwgcjQJCQkJQCBjcmVhdGUgd29ya2luZyBjb3B5IG9mIG1heCB3YXkgc2l6ZQ0K
KzMwOg0KKwlvcnIJcjExLCByMTAsIHI5LCBsc2wgcjUJCUAgZmFjdG9yIHdheSBhbmQgY2FjaGUg
bnVtYmVyIGludG8gcjExDQorCW9ycglyMTEsIHIxMSwgcjcsIGxzbCByMgkJQCBmYWN0b3IgaW5k
ZXggbnVtYmVyIGludG8gcjExDQorCW1jcglwMTUsIDAsIHIxMSwgYzcsIFxvcCAsIDIJQCBjbGVh
biAmIGludmFsaWRhdGUgYnkgc2V0L3dheQ0KKwlzdWJzCXI5LCByOSwgIzEJCQlAIGRlY3JlbWVu
dCB0aGUgd2F5DQorCWJnZQkzMGINCisJc3VicwlyNywgcjcsICMxCQkJQCBkZWNyZW1lbnQgdGhl
IGluZGV4DQorCWJnZQkyMGINCis0MDoNCisJYWRkCXIxMCwgcjEwLCAjMgkJCUAgaW5jcmVtZW50
IGNhY2hlIG51bWJlcg0KKwljbXAJcjMsIHIxMA0KKwliZ3QJMTBiDQorNTA6DQorCW1vdglyMTAs
ICMwCQkJCUAgc3dpdGggYmFjayB0byBjYWNoZSBsZXZlbCAwDQorCW1jcglwMTUsIDIsIHIxMCwg
YzAsIGMwLCAwCQlAIHNlbGVjdCBjdXJyZW50IGNhY2hlIGxldmVsIGluIGNzc3INCisJZHNiDQor
CWlzYg0KKwkuZW5kbQ0KKwkudGV4dA0KKw0KK1BSSVZBVEUodjdfZmx1c2hfY2FjaGVfYWxsKQ0K
KwlzdG1mZAlzcCEsIHtyNC1yNSwgcjcsIHI5LXIxMSwgbHJ9DQorDQorCXY3X3dheV9vcCBjMTQN
CisNCisJbW92CXIwLCAjMA0KKwltY3IJcDE1LCAwLCByMCwgYzcsIGM1LCAwCQlAIEkrQlRCIGNh
Y2hlIGludmFsaWRhdGUNCisJbGRtZmQJc3AhLCB7cjQtcjUsIHI3LCByOS1yMTEsIGxyfQ0KKwlt
b3YJcGMsIGxyDQorDQorREVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNoX2NhY2hlX2FsbCwgdjdfZmx1
c2hfY2FjaGVfYWxsKQ0KKw0KK1BSSVZBVEUodjdfZmx1c2hfY2FjaGVfcmFuZ2UpDQorCW1yYyAg
ICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUg0KKwlhbmQgICAgIHIzLCByMywg
IzcJCUAgY2FjaGUgbGluZSBzaXplIGVuY29kaW5nDQorCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6
ZSBvZmZzZXQNCisJbW92ICAgICByMiwgcjIsIGxzbCByMwkJQCBhY3R1YWwgY2FjaGUgbGluZSBz
aXplDQorMToNCisJbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTQsIDEJCUAgY2xlYW4gJiBpbnZhbGlk
YXRlIEQgbGluZSAvIHVuaWZpZWQgbGluZQ0KKwlhZGQJcjAsIHIwLCByMg0KKwljbXAJcjAsIHIx
DQorCWJsbwkxYg0KKwlkc2INCisJbW92CXBjLCBscg0KKw0KK0RFQ0xBUkVfQ1BVX09QKGNwdV9m
bHVzaF9jYWNoZV9yYW5nZSwgdjdfZmx1c2hfY2FjaGVfcmFuZ2UpDQorDQorUFJJVkFURSh2N19j
bGVhbl9jYWNoZV9yYW5nZSkNCisJbXJjICAgICBwMTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFk
IENTSURSDQorCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcN
CisJbW92ICAgICByMywgIzE2CQkJQCBzaXplIG9mZnNldA0KKwltb3YgICAgIHIyLCByMiwgbHNs
IHIzCQlAIGFjdHVhbCBjYWNoZSBsaW5lIHNpemUNCisNCisxOg0KKwltY3IJcDE1LCAwLCByMCwg
YzcsIGMxMCwgMQkJQCBjbGVhbiBEIGVudHJ5DQorCWFkZAlyMCwgcjAsIHIyDQorCWNtcAlyMCwg
cjENCisJYmxvCTFiDQorCWRzYg0KKwltb3YJcGMsIGxyDQorDQorREVDTEFSRV9DUFVfT1AoY3B1
X2NsZWFuX2NhY2hlX3JhbmdlLCB2N19jbGVhbl9jYWNoZV9yYW5nZSkNCisNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch09.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch09.diff"


YXJtOiBpbXBsZW1lbnQgY2FjaGUgb3BzIGZvciBBUk12NwoKIHhlbi9hcmNoL2FybS94ZW4v
TWFrZWZpbGUgICB8ICAgMSArCiB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMgfCAgOTQg
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogMiBmaWxlcyBjaGFuZ2Vk
LCA5NSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKU2lnbmVkLW9mZi1ieTogSmFl
bWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CgpkaWZmIC1yIDE1YWFhMjBlMTRiZiB4
ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUJU3VuIEZlYiAxMiAxMTo1NTowNCAyMDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94
ZW4vTWFrZWZpbGUJU3VuIEZlYiAxMiAxMjowNToxNiAyMDEyICswOTAwCkBAIC0yMiwzICsy
Miw0IEBAIG9iai15ICs9IHAybS5vCiBvYmoteSArPSBwZXJmbW9uLm8KIG9iai15ICs9IHBj
aS5vCiBvYmoteSArPSBhcm12Ny5vCitvYmoteSArPSBjYWNoZS12Ny5vCmRpZmYgLXIgMTVh
YWEyMGUxNGJmIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUwotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2Nh
Y2hlLXY3LlMJU3VuIEZlYiAxMiAxMjowNToxNiAyMDEyICswOTAwCkBAIC0wLDAgKzEsOTQg
QEAKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorI2luY2x1ZGUgPGFzbS9wYWdlLmg+Cisj
aW5jbHVkZSA8YXNtL2NwdS1vcHMuaD4KKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CisjaW5j
bHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+CisKKwkubWFjcm8gdjdfd2F5X29wLCBvcAorCWRt
YgkJCQkJQCBlbnN1cmUgb3JkZXJpbmcgd2l0aCBwcmV2aW91cyBtZW1vcnkgYWNjZXNzZXMK
KwltcmMJcDE1LCAxLCByMCwgYzAsIGMwLCAxCQlAIHJlYWQgY2xpZHIKKwlhbmRzCXIzLCBy
MCwgIzB4NzAwMDAwMAkJQCBleHRyYWN0IGxvYyBmcm9tIGNsaWRyCisJbW92CXIzLCByMywg
bHNyICMyMwkJCUAgbGVmdCBhbGlnbiBsb2MgYml0IGZpZWxkCisJYmVxCTUwZgkJCQlAIGlm
IGxvYyBpcyAwLCB0aGVuIG5vIG5lZWQgdG8gY2xlYW4KKwltb3YJcjEwLCAjMAkJCQlAIHN0
YXJ0IGNsZWFuIGF0IGNhY2hlIGxldmVsIDAKKzEwOgorCWFkZAlyMiwgcjEwLCByMTAsIGxz
ciAjMQkJQCB3b3JrIG91dCAzeCBjdXJyZW50IGNhY2hlIGxldmVsCisJbW92CXIxLCByMCwg
bHNyIHIyCQkJQCBleHRyYWN0IGNhY2hlIHR5cGUgYml0cyBmcm9tIGNsaWRyCisJYW5kCXIx
LCByMSwgIzcJCQlAIG1hc2sgb2YgdGhlIGJpdHMgZm9yIGN1cnJlbnQgY2FjaGUgb25seQor
CWNtcAlyMSwgIzIJCQkJQCBzZWUgd2hhdCBjYWNoZSB3ZSBoYXZlIGF0IHRoaXMgbGV2ZWwK
KwlibHQJNDBmCQkJCUAgc2tpcCBpZiBubyBjYWNoZSwgb3IganVzdCBpLWNhY2hlCisJbWNy
CXAxNSwgMiwgcjEwLCBjMCwgYzAsIDAJCUAgc2VsZWN0IGN1cnJlbnQgY2FjaGUgbGV2ZWwg
aW4gY3NzcgorCWlzYgkJCQkJQCBpc2IgdG8gc3ljaCB0aGUgbmV3IGNzc3ImY3NpZHIKKwlt
cmMJcDE1LCAxLCByMSwgYzAsIGMwLCAwCQlAIHJlYWQgdGhlIG5ldyBjc2lkcgorCWFuZAly
MiwgcjEsICM3CQkJQCBleHRyYWN0IHRoZSBsZW5ndGggb2YgdGhlIGNhY2hlIGxpbmVzCisJ
YWRkCXIyLCByMiwgIzQJCQlAIGFkZCA0IChsaW5lIGxlbmd0aCBvZmZzZXQpCisJbGRyCXI0
LCA9MHgzZmYKKwlhbmRzCXI0LCByNCwgcjEsIGxzciAjMwkJQCBmaW5kIG1heGltdW0gbnVt
YmVyIG9uIHRoZSB3YXkgc2l6ZQorCWNseglyNSwgcjQJCQkJQCBmaW5kIGJpdCBwb3NpdGlv
biBvZiB3YXkgc2l6ZSBpbmNyZW1lbnQKKwlsZHIJcjcsID0weDdmZmYKKwlhbmRzCXI3LCBy
NywgcjEsIGxzciAjMTMJCUAgZXh0cmFjdCBtYXggbnVtYmVyIG9mIHRoZSBpbmRleCBzaXpl
CisyMDoKKwltb3YJcjksIHI0CQkJCUAgY3JlYXRlIHdvcmtpbmcgY29weSBvZiBtYXggd2F5
IHNpemUKKzMwOgorCW9ycglyMTEsIHIxMCwgcjksIGxzbCByNQkJQCBmYWN0b3Igd2F5IGFu
ZCBjYWNoZSBudW1iZXIgaW50byByMTEKKwlvcnIJcjExLCByMTEsIHI3LCBsc2wgcjIJCUAg
ZmFjdG9yIGluZGV4IG51bWJlciBpbnRvIHIxMQorCW1jcglwMTUsIDAsIHIxMSwgYzcsIFxv
cCAsIDIJQCBjbGVhbiAmIGludmFsaWRhdGUgYnkgc2V0L3dheQorCXN1YnMJcjksIHI5LCAj
MQkJCUAgZGVjcmVtZW50IHRoZSB3YXkKKwliZ2UJMzBiCisJc3VicwlyNywgcjcsICMxCQkJ
QCBkZWNyZW1lbnQgdGhlIGluZGV4CisJYmdlCTIwYgorNDA6CisJYWRkCXIxMCwgcjEwLCAj
MgkJCUAgaW5jcmVtZW50IGNhY2hlIG51bWJlcgorCWNtcAlyMywgcjEwCisJYmd0CTEwYgor
NTA6CisJbW92CXIxMCwgIzAJCQkJQCBzd2l0aCBiYWNrIHRvIGNhY2hlIGxldmVsIDAKKwlt
Y3IJcDE1LCAyLCByMTAsIGMwLCBjMCwgMAkJQCBzZWxlY3QgY3VycmVudCBjYWNoZSBsZXZl
bCBpbiBjc3NyCisJZHNiCisJaXNiCisJLmVuZG0KKwkudGV4dAorCitQUklWQVRFKHY3X2Zs
dXNoX2NhY2hlX2FsbCkKKwlzdG1mZAlzcCEsIHtyNC1yNSwgcjcsIHI5LXIxMSwgbHJ9CisK
Kwl2N193YXlfb3AgYzE0CisKKwltb3YJcjAsICMwCisJbWNyCXAxNSwgMCwgcjAsIGM3LCBj
NSwgMAkJQCBJK0JUQiBjYWNoZSBpbnZhbGlkYXRlCisJbGRtZmQJc3AhLCB7cjQtcjUsIHI3
LCByOS1yMTEsIGxyfQorCW1vdglwYywgbHIKKworREVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNo
X2NhY2hlX2FsbCwgdjdfZmx1c2hfY2FjaGVfYWxsKQorCitQUklWQVRFKHY3X2ZsdXNoX2Nh
Y2hlX3JhbmdlKQorCW1yYyAgICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lE
UgorCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcKKwlt
b3YgICAgIHIzLCAjMTYJCQlAIHNpemUgb2Zmc2V0CisJbW92ICAgICByMiwgcjIsIGxzbCBy
MwkJQCBhY3R1YWwgY2FjaGUgbGluZSBzaXplCisxOgorCW1jcglwMTUsIDAsIHIwLCBjNywg
YzE0LCAxCQlAIGNsZWFuICYgaW52YWxpZGF0ZSBEIGxpbmUgLyB1bmlmaWVkIGxpbmUKKwlh
ZGQJcjAsIHIwLCByMgorCWNtcAlyMCwgcjEKKwlibG8JMWIKKwlkc2IKKwltb3YJcGMsIGxy
CisKK0RFQ0xBUkVfQ1BVX09QKGNwdV9mbHVzaF9jYWNoZV9yYW5nZSwgdjdfZmx1c2hfY2Fj
aGVfcmFuZ2UpCisKK1BSSVZBVEUodjdfY2xlYW5fY2FjaGVfcmFuZ2UpCisJbXJjICAgICBw
MTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFkIENTSURSCisJYW5kICAgICByMywgcjMsICM3
CQlAIGNhY2hlIGxpbmUgc2l6ZSBlbmNvZGluZworCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6
ZSBvZmZzZXQKKwltb3YgICAgIHIyLCByMiwgbHNsIHIzCQlAIGFjdHVhbCBjYWNoZSBsaW5l
IHNpemUKKworMToKKwltY3IJcDE1LCAwLCByMCwgYzcsIGMxMCwgMQkJQCBjbGVhbiBEIGVu
dHJ5CisJYWRkCXIwLCByMCwgcjIKKwljbXAJcjAsIHIxCisJYmxvCTFiCisJZHNiCisJbW92
CXBjLCBscgorCitERUNMQVJFX0NQVV9PUChjcHVfY2xlYW5fY2FjaGVfcmFuZ2UsIHY3X2Ns
ZWFuX2NhY2hlX3JhbmdlKQorCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt16-0005xp-Ti; Mon, 13 Feb 2012 10:20:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqp9-0003Ma-Km
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:59:48 +0000
Received: from [85.158.139.83:51794] by server-1.bemta-5.messagelabs.com id
	AA/6E-04285-2F2C83F4; Mon, 13 Feb 2012 07:59:46 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329119983!7452746!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24234 invoked from network); 13 Feb 2012 07:59:45 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-16.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 07:59:45 -0000
Received: from epcpsbge8.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005VZN88EV50@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:59:42 +0900 (KST)
Message-id: <0LZB0057ZNJIEV60@mailout1.samsung.com>
X-AuditID: cbfee612-b7c09ae0000024ca-d2-4f38c2ec73c7
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge8.samsung.com (EPCPMTA) with SMTP id C8.E0.09418.CE2C83F4;
	Mon, 13 Feb 2012 16:59:40 +0900 (KST)
Date: Mon, 13 Feb 2012 07:59:40 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075853731@jm77.ryu
Msgkey: 20120213075853731@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075753031@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 07/14] arm: implement the functions which are
 required to create the dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <10687328.70051329119976618.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgdGhlIGZ1bmN0aW9ucyB3aGljaCBhcmUgcmVxdWlyZWQgdG8gY3JlYXRl
IHRoZSBkb20wLg0KDQogeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZSAgICAgICB8ICAgIDEgKw0K
IHhlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21haW4uYyAgfCAgMTQ0ICsrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tDQogeGVuL2Fy
Y2gvYXJtL3hlbi9hcm12Ny5TICAgICAgICB8ICAgMTkgKysrKysrKysNCiB4ZW4vYXJjaC9hcm0v
eGVuL2RvbWFpbl9idWlsZC5jIHwgIDE4OSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQ0K
IHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgfCAgICAyIC0NCiB4ZW4vaW5jbHVkZS9h
c20tYXJtL2N1cnJlbnQuaCAgIHwgICAyMyArKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFy
bS9kb21haW4uaCAgICB8ICAgMzkgKy0tLS0tLS0tLS0tLS0tLS0NCiA3IGZpbGVzIGNoYW5nZWQs
IDM1NiBpbnNlcnRpb25zKCspLCA2MSBkZWxldGlvbnMoLSkNCg0KU2lnbmVkLW9mZi1ieTogSmFl
bWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgMDhmMzlhOWRhMDRmIHhl
bi9hcmNoL2FybS94ZW4vTWFrZWZpbGUNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUJ
TW9uIEZlYiAwNiAxMToxNzowMSAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL01h
a2VmaWxlCVN1biBGZWIgMTIgMTE6NDY6MzIgMjAxMiArMDkwMA0KQEAgLTIxLDMgKzIxLDQgQEAg
b2JqLXkgKz0gY3Jhc2gubw0KIG9iai15ICs9IHAybS5vDQogb2JqLXkgKz0gcGVyZm1vbi5vDQog
b2JqLXkgKz0gcGNpLm8NCitvYmoteSArPSBhcm12Ny5vDQpkaWZmIC1yIDA4ZjM5YTlkYTA0ZiB4
ZW4vYXJjaC9hcm0veGVuL2FyY2hfZG9tYWluLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vYXJj
aF9kb21haW4uYwlNb24gRmViIDA2IDExOjE3OjAxIDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNo
L2FybS94ZW4vYXJjaF9kb21haW4uYwlTdW4gRmViIDEyIDExOjQ2OjMyIDIwMTIgKzA5MDANCkBA
IC0zMSw2ICszMSwxMiBAQA0KICNpbmNsdWRlIDx4ZW4vaXJxLmg+DQogI2luY2x1ZGUgPHhlbi9p
cnFfY3B1c3RhdC5oPg0KICNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPg0KKyNpbmNsdWRlIDxhc20v
Y3VycmVudC5oPgkNCisjaW5jbHVkZSA8YXNtL2NwdS1vcHMuaD4NCisjaW5jbHVkZSA8YXNtL21l
bW9yeS5oPg0KKyNpbmNsdWRlIDxhc20vbW11Lmg+DQorDQorc3RydWN0IHZjcHUgKnN3aXRjaF90
byggc3RydWN0IHZjcHUgKiwgc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCAqLCBzdHJ1Y3QgdmNw
dV9ndWVzdF9jb250ZXh0ICopOw0KIA0KIHZvaWQgYXJjaF9kdW1wX2RvbWFpbl9pbmZvKHN0cnVj
dCBkb21haW4gKmQpDQogew0KQEAgLTUyLDMzICs1OCw4NCBAQCB1bnNpZ25lZCBsb25nIGh5cGVy
Y2FsbF9jcmVhdGVfY29udGludWF0DQogDQogaW50IGFyY2hfZG9tYWluX2NyZWF0ZShzdHJ1Y3Qg
ZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgZG9tY3JfZmxhZ3MpDQogew0KLQlOT1RfWUVUKCk7DQor
CWludCByYzsNCiANCi0JcmV0dXJuIC1FSU5WQUw7DQorCXJjID0gMDsNCisJaWYgKGlzX2lkbGVf
ZG9tYWluKGQpKQ0KKwkJcmV0dXJuIHJjOw0KKw0KKwlkLT5hcmNoLmlvcG9ydF9jYXBzID0gcmFu
Z2VzZXRfbmV3KGQsICJJL08gUG9ydHMiLCBSQU5HRVNFVEZfcHJldHR5cHJpbnRfaGV4KTsNCisJ
cmMgPSAtRU5PTUVNOw0KKwlpZiAoZC0+YXJjaC5pb3BvcnRfY2FwcyA9PSBOVUxMKSB7DQorCQln
b3RvIGZhaWxlZDsNCisJfQ0KKw0KKwlpZiAoKGQtPnNoYXJlZF9pbmZvID0gYWxsb2NfeGVuaGVh
cF9wYWdlcygwLCBNRU1GX2JpdHMoMzIpKSkgPT0gTlVMTCkgew0KKwkJZ290byBmYWlsZWQ7DQor
CX0NCisNCisJY2xlYXJfcGFnZShkLT5zaGFyZWRfaW5mbyk7DQorCXNoYXJlX3hlbl9wYWdlX3dp
dGhfZ3Vlc3QodmlydF90b19wYWdlKGQtPnNoYXJlZF9pbmZvKSwgZCwgWEVOU0hBUkVfd3JpdGFi
bGUpOw0KKw0KKwlkLT5hcmNoLnBpcnFfaXJxID0geG1hbGxvY19hcnJheShpbnQsIGQtPm5yX3Bp
cnFzKTsNCisJaWYgKCFkLT5hcmNoLnBpcnFfaXJxKSB7DQorCQlnb3RvIGZhaWxlZDsNCisJfQ0K
Kw0KKwltZW1zZXQoZC0+YXJjaC5waXJxX2lycSwgMCwgZC0+bnJfcGlycXMgKiBzaXplb2YoKmQt
PmFyY2gucGlycV9pcnEpKTsNCisNCisJZC0+YXJjaC5pcnFfcGlycSA9IHhtYWxsb2NfYXJyYXko
aW50LCBucl9pcnFzKTsNCisJaWYgKCAhZC0+YXJjaC5pcnFfcGlycSApIHsNCisJCWdvdG8gZmFp
bGVkOw0KKwl9DQorDQorCW1lbXNldChkLT5hcmNoLmlycV9waXJxLCAwLCBucl9pcnFzICogc2l6
ZW9mKCpkLT5hcmNoLmlycV9waXJxKSk7DQorDQorCXJldHVybiAwOw0KKw0KK2ZhaWxlZDoNCisJ
ZC0+aXNfZHlpbmcgPSBET01EWUlOR19kZWFkOw0KKwl4ZnJlZShkLT5hcmNoLnBpcnFfaXJxKTsN
CisJeGZyZWUoZC0+YXJjaC5pcnFfcGlycSk7DQorDQorCWZyZWVfeGVuaGVhcF9wYWdlKGQtPnNo
YXJlZF9pbmZvKTsNCisNCisJcmV0dXJuIHJjOw0KIH0NCiANCiB2b2lkIGFyY2hfZG9tYWluX2Rl
c3Ryb3koc3RydWN0IGRvbWFpbiAqZCkNCiB7DQotCU5PVF9ZRVQoKTsNCisJZnJlZV94ZW5oZWFw
X3BhZ2UoZC0+c2hhcmVkX2luZm8pOw0KKw0KKwl4ZnJlZShkLT5hcmNoLnBpcnFfaXJxKTsNCisJ
eGZyZWUoZC0+YXJjaC5pcnFfcGlycSk7DQogfQ0KIA0KIHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRl
eHQgKmFsbG9jX3ZjcHVfZ3Vlc3RfY29udGV4dCh2b2lkKQ0KIHsNCi0JTk9UX1lFVCgpOw0KKwlz
dHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICp2Z2M7DQogDQotCXJldHVybiBOVUxMOw0KKwl2Z2Mg
PSB4bWFsbG9jKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQpOw0KKw0KKwlyZXR1cm4gdmdjOw0K
IH0NCiANCiB2b2lkIGZyZWVfdmNwdV9ndWVzdF9jb250ZXh0KHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQgKmNvbnRleHQpDQogew0KLQlOT1RfWUVUKCk7DQorCXhmcmVlKGNvbnRleHQpOw0KIH0N
CiANCiANCiBzdHJ1Y3QgdmNwdSAqYWxsb2NfdmNwdV9zdHJ1Y3Qodm9pZCkNCiB7DQotCU5PVF9Z
RVQoKTsNCi0JcmV0dXJuIE5VTEw7DQorCXN0cnVjdCB2Y3B1ICp2Ow0KKw0KKwl2ID0geG1hbGxv
YyhzdHJ1Y3QgdmNwdSk7DQorCWlmICggdiAhPSBOVUxMICkNCisJCW1lbXNldCh2LCAwLCBzaXpl
b2Yoc3RydWN0IHZjcHUpKTsNCisNCisNCisJcmV0dXJuIHY7DQogfQ0KIA0KIHZvaWQgYXJjaF92
Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KQ0KQEAgLTg4LDcgKzE0NSw2IEBAIHZvaWQgYXJjaF92
Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KQ0KIA0KIGludCB2Y3B1X2luaXRpYWxpc2Uoc3RydWN0
IHZjcHUgKnYpDQogew0KLQlOT1RfWUVUKCk7DQogCXJldHVybiAwOw0KIH0NCiANCkBAIC05OSwy
NyArMTU1LDMyIEBAIHZvaWQgdmNwdV9kZXN0cm95KHN0cnVjdCB2Y3B1ICp2KQ0KIA0KIHZvaWQg
ZnJlZV92Y3B1X3N0cnVjdChzdHJ1Y3QgdmNwdSAqdikNCiB7DQotCU5PVF9ZRVQoKTsNCisJeGZy
ZWUodik7DQogfQ0KIA0KIHN0cnVjdCBkb21haW4gKmFsbG9jX2RvbWFpbl9zdHJ1Y3Qodm9pZCkN
CiB7DQotCU5PVF9ZRVQoKTsNCisJc3RydWN0IGRvbWFpbiAqZDsNCiANCi0JcmV0dXJuIE5VTEw7
DQorCWQgPSB4bWFsbG9jKHN0cnVjdCBkb21haW4pOw0KKwlpZiAoIGQgIT0gTlVMTCApDQorCQlt
ZW1zZXQoZCwgMCwgc2l6ZW9mKHN0cnVjdCBkb21haW4pKTsNCisNCisJcmV0dXJuIGQ7DQogfQ0K
IA0KIA0KIHZvaWQgZnJlZV9kb21haW5fc3RydWN0KHN0cnVjdCBkb21haW4gKmQpDQogew0KLQlO
T1RfWUVUKCk7DQorCXhmcmVlKGQpOw0KIH0NCiANCisvKiBUaGlzIGlzIGNhbGxlZCBieSBhcmNo
X2ZpbmFsX3NldHVwX2d1ZXN0IGFuZCBkb19ib290X3ZjcHUgKi8NCiBpbnQgYXJjaF9zZXRfaW5m
b19ndWVzdChzdHJ1Y3QgdmNwdSAqdiwgdmNwdV9ndWVzdF9jb250ZXh0X3QgKmN0eCkNCiB7DQog
CU5PVF9ZRVQoKTsNCiANCi0JcmV0dXJuIDA7DQorCXJldHVybiAtRUlOVkFMOw0KIA0KIH0NCiAN
CkBAIC0xMzUsMTIgKzE5NiwxNyBAQCB2b2lkIGR1bXBfcGFnZWZyYW1lX2luZm8oc3RydWN0IGRv
bWFpbiAqDQogDQogdm9pZCBjb250ZXh0X3N3aXRjaChzdHJ1Y3QgdmNwdSAqcHJldiwgc3RydWN0
IHZjcHUgKm5leHQpDQogew0KLQlOT1RfWUVUKCk7DQorCUFTU0VSVChwcmV2ICE9IG5leHQpOw0K
KwlBU1NFUlQodmNwdV9ydW5uYWJsZShuZXh0KSk7DQorDQorICAgICAgICBwcmV2ID0gIHN3aXRj
aF90byhwcmV2LCAmcHJldi0+YXJjaC5jdHgsICZuZXh0LT5hcmNoLmN0eCk7DQogfQ0KIA0KIHZv
aWQgY29udGludWVfcnVubmluZyhzdHJ1Y3QgdmNwdSAqc2FtZSkNCiB7DQogCU5PVF9ZRVQoKTsN
CisNCisJcmV0dXJuIDsNCiB9DQogDQogdm9pZCBzeW5jX2xhenlfZXhlY3N0YXRlX2NwdSh1bnNp
Z25lZCBpbnQgY3B1KQ0KQEAgLTE2OCw2ICsyMzQsMjQgQEAgdm9pZCByZWxpbnF1aXNoX21lbW9y
eShzdHJ1Y3QgZG9tYWluICpkLA0KIAlOT1RfWUVUKCk7DQogfQ0KIA0KK3ZvaWQgdHJhY2VfZG9t
aGVhcF9wYWdlcyhjb25zdCBjaGFyICpjYXB0aW9uLCBzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg
bGlzdF9oZWFkICpsaXN0KQ0KK3sNCisJc3RydWN0IGxpc3RfaGVhZCAqZW50Ow0KKwlzdHJ1Y3Qg
cGFnZV9pbmZvICAqcGFnZTsNCisNCisJLyogVXNlIGEgcmVjdXJzaXZlIGxvY2ssIGFzIHdlIG1h
eSBlbnRlciAnZnJlZV9kb21oZWFwX3BhZ2UnLiAqLw0KKwlzcGluX2xvY2tfcmVjdXJzaXZlKCZk
LT5wYWdlX2FsbG9jX2xvY2spOw0KKw0KKwllbnQgPSBsaXN0LT5uZXh0Ow0KKwl3aGlsZSAoIGVu
dCAhPSBsaXN0ICkNCisJew0KKwkJcGFnZSA9IGxpc3RfZW50cnkoZW50LCBzdHJ1Y3QgcGFnZV9p
bmZvLCBsaXN0KTsNCisJCWVudCA9IGVudC0+bmV4dDsNCisJfQ0KKw0KKwlzcGluX3VubG9ja19y
ZWN1cnNpdmUoJmQtPnBhZ2VfYWxsb2NfbG9jayk7DQorfQ0KKw0KIGludCBkb21haW5fcmVsaW5x
dWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCiB7DQogCU5PVF9ZRVQoKTsNCkBAIC0x
NzcsNyArMjYxLDE2IEBAIGludCBkb21haW5fcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGQN
CiANCiB2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKQ0KIHsNCi0JTk9UX1lFVCgpOw0K
Kwl3aGlsZSgxKSB7DQorCQlpZiAoY3B1X2lzX2hhbHRhYmxlKHNtcF9wcm9jZXNzb3JfaWQoKSkp
IHsNCisJCQlsb2NhbF9pcnFfZGlzYWJsZSgpOw0KKwkJCWNwdV9pZGxlKCk7DQorCQkJbG9jYWxf
aXJxX2VuYWJsZSgpOw0KKwkJfQ0KKw0KKwkJZG9fdGFza2xldCgpOw0KKwkJZG9fc29mdGlycSgp
Ow0KKwl9DQogfQ0KIA0KIGxvbmcgYXJjaF9kb192Y3B1X29wKGludCBjbWQsIHN0cnVjdCB2Y3B1
ICp2LCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykNCkBAIC0xODksMjIgKzI4MiwzMyBAQCBs
b25nIGFyY2hfZG9fdmNwdV9vcChpbnQgY21kLCBzdHJ1Y3QgdmNwDQogDQogdm9pZCB2Y3B1X2tp
Y2soc3RydWN0IHZjcHUgKnYpDQogew0KLQlOT1RfWUVUKCk7DQorCWJvb2xfdCBydW5uaW5nID0g
di0+aXNfcnVubmluZzsNCisNCisJdmNwdV91bmJsb2NrKHYpOw0KKw0KKwlpZiAocnVubmluZyAm
JiAoaW5faXJxKCkgfHwgKHYgIT0gY3VycmVudCkpKSB7DQorCQljcHVfcmFpc2Vfc29mdGlycSh2
LT5wcm9jZXNzb3IsIFZDUFVfS0lDS19TT0ZUSVJRKTsNCisJfQ0KIH0NCiANCiB2b2lkIHZjcHVf
bWFya19ldmVudHNfcGVuZGluZyhzdHJ1Y3QgdmNwdSAqdikNCiB7DQotCU5PVF9ZRVQoKTsNCisJ
aW50IGFscmVhZHkgPSB0ZXN0X2FuZF9zZXRfYml0KDAsICh1bnNpZ25lZCBsb25nICopJnZjcHVf
aW5mbyh2LCBldnRjaG5fdXBjYWxsX3BlbmRpbmcpKTsNCisNCisJaWYgKGFscmVhZHkpIHsNCisJ
CXJldHVybjsNCisJfQ0KKw0KKwl2Y3B1X2tpY2sodik7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIHZj
cHVfa2lja19zb2Z0aXJxKHZvaWQpDQogew0KLQlOT1RfWUVUKCk7DQogfQ0KIA0KIHN0YXRpYyBp
bnQgX19pbml0IHZjcHVfa2lja19zb2Z0aXJxX2luaXQodm9pZCkNCiB7DQotCU5PVF9ZRVQoKTsN
CisJb3Blbl9zb2Z0aXJxKFZDUFVfS0lDS19TT0ZUSVJRLCB2Y3B1X2tpY2tfc29mdGlycSk7DQog
DQogCXJldHVybiAwOw0KIH0NCmRpZmYgLXIgMDhmMzlhOWRhMDRmIHhlbi9hcmNoL2FybS94ZW4v
YXJtdjcuUw0KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDANCisr
KyBiL3hlbi9hcmNoL2FybS94ZW4vYXJtdjcuUwlTdW4gRmViIDEyIDExOjQ2OjMyIDIwMTIgKzA5
MDANCkBAIC0wLDAgKzEsMTkgQEANCisjaW5jbHVkZSA8YXNtL3BhZ2UuaD4NCisjaW5jbHVkZSA8
YXNtL2NwdS1vcHMuaD4NCisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPg0KKyNpbmNsdWRlIDxhc20v
YXNtLW1hY3Jvcy5oPg0KKyNpbmNsdWRlIDxhc20vYXNtLW9mZnNldHMuaD4NCisjaW5jbHVkZSA8
cHVibGljL2FyY2gtYXJtLmg+DQorDQorCS50ZXh0DQorRU5UUlkoY3B1X2lkbGUpDQorCWRzYg0K
Kwl3ZmkNCisJbW92CXBjLCBscg0KKw0KK0VOVFJZKGNwdV9oYWx0KQ0KKwltb3YJcGMsIGxyDQor
DQorRU5UUlkoY3B1X3Jlc2V0KQ0KKwltb3YJcGMsIGxyDQorDQpkaWZmIC1yIDA4ZjM5YTlkYTA0
ZiB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jDQotLS0gYS94ZW4vYXJjaC9hcm0veGVu
L2RvbWFpbl9idWlsZC5jCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMA0KKysrIGIveGVu
L2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwlTdW4gRmViIDEyIDExOjQ2OjMyIDIwMTIgKzA5
MDANCkBAIC0zMyw2ICszMyw2NyBAQA0KICNpbmNsdWRlIDxwdWJsaWMveGVuLmg+DQogI2luY2x1
ZGUgPHB1YmxpYy92ZXJzaW9uLmg+DQogDQorZXh0ZXJuIHZvaWQgcmV0dXJuX3RvX2d1ZXN0KCk7
DQorDQordm9pZCB2Y3B1X2NvbnRleHRfaW5pdChzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgbG9u
ZyBzdGssIHVuc2lnbmVkIGxvbmcgcGMsIHN0cnVjdCBzdGFydF9pbmZvICpzaSkNCit7DQorCXZv
aWQgKnN0YWNrOw0KKwlzdHJ1Y3QgY3B1X2luZm8gKmNpOw0KKwlzdHJ1Y3QgY3B1X2N0eCAqY3B1
X2N0eDsNCisNCisJc3RhY2sgPSBhbGxvY194ZW5oZWFwX3BhZ2VzKFNUQUNLX09SREVSLCAwKTsN
CisJaWYoc3RhY2sgPT0gTlVMTCkgew0KKwkJcmV0dXJuOw0KKwl9DQorDQorCWNpID0gKHN0cnVj
dCBjcHVfaW5mbyAqKXN0YWNrOw0KKwljaS0+dmNwdSA9IHY7DQorCWNpLT52c3AgPSAwOw0KKwlj
aS0+dnNwc3IgPSBQU1JfTU9ERV9TVkM7DQorCWNpLT52ZGFjciA9IERBQ1JfU1RBVF9TVkM7DQor
DQorCXN0YWNrICs9IChTVEFDS19TSVpFIC0gc2l6ZW9mKHN0cnVjdCBjcHVfY3R4KSk7DQorDQor
CWNwdV9jdHggPSAoc3RydWN0IGNwdV9jdHggKilzdGFjazsNCisJY3B1X2N0eC0+cjAgPSAwOw0K
KwljcHVfY3R4LT5yMTIgPSAodW5zaWduZWQgbG9uZylzaTsNCisJY3B1X2N0eC0+dXNwID0gc3Rr
Ow0KKwljcHVfY3R4LT51bHIgPSAwOw0KKwljcHVfY3R4LT5zc3AgPSAodW5zaWduZWQgbG9uZyko
c3RhY2sgKyBzaXplb2Yoc3RydWN0IGNwdV9jdHgpKTsNCisJY3B1X2N0eC0+cGMgPSBwYzsNCisJ
Y3B1X2N0eC0+c3BzciA9IDB4MTA7DQorDQorCVZDUFVfUkVHKHYsIHIxMykgPSAodW5zaWduZWQg
bG9uZylzdGFjazsNCisJVkNQVV9SRUcodiwgcjE0KSA9ICh1bnNpZ25lZCBsb25nKXJldHVybl90
b19ndWVzdDsNCisNCisJVkNQVV9SRUcodiwgZGFjcikgPSBEQUNSX1NUQVRfU1ZDOw0KKwlWQ1BV
X1JFRyh2LCBmY3NlaWRyKSA9IDA7DQorCVZDUFVfUkVHKHYsIGNvbnRleHRpZHIpID0gMDsNCisJ
VkNQVV9SRUcodiwgY3BhcikgPSAoMHg0MCkgfCAoMSA8PCAxMyk7DQorfQ0KKw0KKyNkZWZpbmUg
RE9NX1BGTl9BTElHTgkoU0VDVElPTl9TSVpFID4+IFBBR0VfU0hJRlQpDQorDQorc3RhdGljIHVu
c2lnbmVkIGxvbmcgYWxsb2NfZG9tYWluX3BhZ2VzKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVk
IGludCBzaXplKQ0KK3sNCisJdW5zaWduZWQgcGh5czsNCisJdW5zaWduZWQgbG9uZyBwYWdlcyA9
IHNpemUgPj4gUEFHRV9TSElGVDsNCisNCisJZC0+bWF4X3BhZ2VzID0gfigweDBVTCk7DQorDQor
CXBoeXMgPSBhbGxvY19ib290X3BhZ2VzKHBhZ2VzLCBET01fUEZOX0FMSUdOKTsNCisJDQorCWlm
ICghcGh5cykgew0KKwkJZC0+dG90X3BhZ2VzID0gMDsNCisJCXJldHVybiAwOw0KKwl9DQorDQor
CWQtPnRvdF9wYWdlcyA9IHBhZ2VzOw0KKw0KKwkvKiBTZXQgUGFnZSBPd25lciAqLw0KKwlyZXR1
cm4gcGh5cyA8PD0gUEFHRV9TSElGVDsNCit9DQorDQogLyoNCiAgKiBkb21haW5fY29uc3RydWN0
KCkgc2hvdWxkIGJlIGFsd2F5cyBpbnZva2VkIGluIGlkbGUgZG9tYWluDQogICovDQpAQCAtNDAs
OCArMTAxLDEzMiBAQCBpbnQgZG9tYWluX2NvbnN0cnVjdChzdHJ1Y3QgZG9tYWluICpkLA0KIAkJ
ICAgICB1bnNpZ25lZCBsb25nIGltZ19zdGFydCwgdW5zaWduZWQgbG9uZyBpbWdfbGVuLCANCiAJ
CSAgICAgdW5zaWduZWQgbG9uZyBkb21fc2l6ZSwgdW5zaWduZWQgaW50IHZjcHVzKQ0KIHsNCi0J
Tk9UX1lFVCgpOw0KKwlpbnQgaSwgcmM7DQorCXN0cnVjdCB2Y3B1ICp2Ow0KKwlzdHJ1Y3QgZWxm
X2JpbmFyeSBlbGY7DQorCXN0cnVjdCBlbGZfZG9tX3Bhcm1zIHBhcm1zOw0KKwlzdHJ1Y3Qgc3Rh
cnRfaW5mbyAqc2k7DQorCXVuc2lnbmVkIGxvbmcgdnN0YXJ0LCB2ZW5kLCB2ZW50cnk7DQorCXVu
c2lnbmVkIGxvbmcgcHN0YXJ0LCBwZW5kLCBwbWFwLCBsZW47DQogDQotCXJldHVybiAtRUlOVkFM
Ow0KKwlsMWVfdCAqZ3B0Ow0KKw0KKwlCVUdfT04oZCA9PSBOVUxMKTsNCisJQlVHX09OKGRvbV9z
aXplICYgflNFQ1RJT05fTUFTSyk7DQorDQorCXBzdGFydCA9IGFsbG9jX2RvbWFpbl9wYWdlcyhk
LCBkb21fc2l6ZSk7DQorCWlmICghcHN0YXJ0KSB7DQorCQlyZXR1cm4gLUVOT01FTTsNCisJfQ0K
Kw0KKwltZW1jcHkoKHBzdGFydCArIGRvbV9zaXplIC0gaW1nX2xlbiksIGltZ19zdGFydCwgaW1n
X2xlbik7DQorCWltZ19zdGFydCA9IHBzdGFydCArIGRvbV9zaXplIC0gaW1nX2xlbjsNCisNCisJ
aWYgKChyYyA9IGVsZl9pbml0KCZlbGYsIGltZ19zdGFydCwgaW1nX2xlbikpICE9IDApIHsNCisJ
CXJldHVybiByYzsNCisJfQ0KKw0KKwllbGZfcGFyc2VfYmluYXJ5KCZlbGYpOw0KKw0KKwlpZiAo
KHJjID0gZWxmX3hlbl9wYXJzZSgmZWxmLCAmcGFybXMpKSAhPSAwKSB7DQorCQlyZXR1cm4gcmM7
DQorCX0NCisNCisJZC0+dmNwdSA9IHhtYWxsb2NfYXJyYXkoc3RydWN0IHZjcHUgKiwgTUFYX1ZJ
UlRfQ1BVUyk7DQorCWlmICghZC0+dmNwdSkgew0KKwkJcmV0dXJuIC1FTk9NRU07DQorCX0NCisN
CisJbWVtc2V0KGQtPnZjcHUsIDAsIE1BWF9WSVJUX0NQVVMgKiBzaXplb2YoKmQtPnZjcHUpKTsN
CisJZC0+bWF4X3ZjcHVzID0gTUFYX1ZJUlRfQ1BVUzsNCisNCisJZm9yIChpID0gMDsgaSA8IE1B
WF9WSVJUX0NQVVM7IGkrKykgew0KKwkJZC0+c2hhcmVkX2luZm8tPnZjcHVfaW5mb1tpXS5ldnRj
aG5fdXBjYWxsX21hc2sgPSAxOw0KKwkJZC0+c2hhcmVkX2luZm8tPnZjcHVfaW5mb1tpXS5hcmNo
LmNwc3IgPSAoVlBTUl9JX0JJVCB8IFZQU1JfRl9CSVQgfCBWUFNSX01PREVfU1ZDKTsNCisJfQ0K
Kw0KKwlmb3IgKGkgPSAwOyBpIDwgdmNwdXM7IGkrKykgew0KKwkJaWYgKGFsbG9jX3ZjcHUoZCwg
aSwgaSkgPT0gTlVMTCkgew0KKwkJCXJldHVybiAtRU5PTUVNOw0KKwkJfQ0KKwl9DQorDQorCXZz
dGFydCA9IHBhcm1zLnZpcnRfa3N0YXJ0ICYgU0VDVElPTl9NQVNLOw0KKwl2ZW5kID0gcm91bmRf
dXAocGFybXMudmlydF9rZW5kLCBMMV9UQUJMRV9TSVpFKTsNCisJdmVudHJ5ID0gcGFybXMudmly
dF9lbnRyeTsNCisNCisJbGVuID0gdmVuZCAtIHZzdGFydDsNCisNCisJLyogR3Vlc3QgIHBhZ2Ug
dGFibGUgaXMgbG9jYXRlZCBpbiB0aGUgZW5kIG9mIHZlbmQgKi8NCisJZ3B0ID0gKGwxZV90ICop
KHBzdGFydCArIGxlbik7DQorCQ0KKwkvKiBEdXBsaWNhdGUgTDEgcGFnZSB0YWJsZSAqLw0KKwlt
ZW1jcHkoZ3B0LCB4ZW5fdHJhbnNsYXRpb25fdGFibGUsIEwxX1RBQkxFX1NJWkUpOw0KKw0KKwlw
bWFwID0gcHN0YXJ0Ow0KKwlwZW5kID0gcG1hcCArIGRvbV9zaXplOw0KKw0KKw0KKwlncHQgPSBs
MV9saW5lYXJfb2Zmc2V0KGdwdCwgdnN0YXJ0KTsNCisNCisJLyogQ3JlYXRlIDE6MSBtYXBwaW5n
ICovDQorCWRvIHsNCisJCSpncHQgPSBNS19MMUUocG1hcCwgTDFFX1RZUEVfR1VFU1QpOw0KKwkJ
cG1hcCArPSBTRUNUSU9OX1NJWkU7DQorCX0gd2hpbGUoZ3B0KyssIHBtYXAgPCBwZW5kKTsNCisg
DQorCS8qIEFjdGl2YXRlIGd1ZXN0IGFkZHJlc3Mgc3BhY2UgdG8gcmVsb2NhdGUgZ3Vlc3QgaW1h
Z2UgKi8NCisJbW11X3N3aXRjaF90dGIoZ3B0ICYgfigweDQwMDAgLSAxKSk7DQorDQorCWVsZi5k
ZXN0ID0gKHZvaWQgKil2ZW50cnk7DQorCWVsZl9sb2FkX2JpbmFyeSgmZWxmKTsNCisNCisJc2kg
PSAoc3RydWN0IHN0YXJ0X2luZm8gKikodmVuZCArIEwxX1RBQkxFX1NJWkUpOw0KKwltZW1zZXQo
c2ksIDAsIFBBR0VfU0laRSk7DQorCQ0KKw0KKwlzaS0+bnJfcGFnZXMgCSAgPSBkLT50b3RfcGFn
ZXM7DQorCXNpLT5zaGFyZWRfaW5mbyAgID0gdmlydF90b19tYWRkcihkLT5zaGFyZWRfaW5mbyk7
DQorCXNpLT5wdF9iYXNlIAkgID0gdmVuZDsNCisJc2ktPm5yX3B0X2ZyYW1lcyAgPSA0Ow0KKwlz
aS0+bWZuX2xpc3QgCSAgPSAwOw0KKwlzaS0+Zmlyc3RfcDJtX3BmbiA9IHBzdGFydCA+PiBQQUdF
X1NISUZUOw0KKwlzaS0+ZmxhZ3MgCSAgPSAwOw0KKwlzaS0+bWluX21mbgkgID0gcHN0YXJ0ID4+
IFBBR0VfU0hJRlQ7DQorDQorCWlmIChkLT5kb21haW5faWQgPT0gMCkgew0KKwkJc2ktPmZsYWdz
ID0gU0lGX1BSSVZJTEVHRUQgfCBTSUZfSU5JVERPTUFJTjsNCisJfQ0KKw0KKwl2ID0gZC0+dmNw
dVswXTsNCisNCisJVkNQVV9SRUcodiwgdHRicjApID0gKHVuc2lnbmVkIGxvbmcpZ3B0Ow0KKw0K
KwltbXVfc3dpdGNoX3R0YihWQ1BVX1JFRyhpZGxlX3ZjcHVbMF0sIHR0YnIwKSk7DQorDQorCXZj
cHVfY29udGV4dF9pbml0KHYsIDAsIHZlbnRyeSwgc2kpOw0KKw0KKwl2LT5pc19pbml0aWFsaXNl
ZCA9IDE7DQorCWNsZWFyX2JpdChfVlBGX2Rvd24sICZ2LT5wYXVzZV9mbGFncyk7DQorDQorCXJj
ID0gMDsNCisNCisJLyogRE9NMCBpcyBwZXJtaXR0ZWQgZnVsbCBJL08gY2FwYWJpbGl0aWVzLiAq
Lw0KKwlyYyB8PSBpb3BvcnRzX3Blcm1pdF9hY2Nlc3MoZG9tMCwgMCwgMHhGRkZGKTsNCisJcmMg
fD0gaW9tZW1fcGVybWl0X2FjY2Vzcyhkb20wLCAwVUwsIH4wVUwpOw0KKwlyYyB8PSBpcnFzX3Bl
cm1pdF9hY2Nlc3MoZG9tMCwgMCwgZC0+bnJfcGlycXMgLSAxKTsNCisNCisJcmV0dXJuIHJjOw0K
IH0NCiANCitpbnQgZWxmX3Nhbml0eV9jaGVjayhjb25zdCBFbGZfRWhkciAqZWhkcikNCit7DQor
CWlmICggIUlTX0VMRigqZWhkcikgfHwNCisJCShlaGRyLT5lX2lkZW50W0VJX0RBVEFdICE9IEVM
RkRBVEEyTFNCKSB8fA0KKwkJKGVoZHItPmVfdHlwZSAhPSBFVF9FWEVDKSApIHsNCisJCXByaW50
aygiRE9NMCBpbWFnZSBpcyBub3QgYSBYZW4tY29tcGF0aWJsZSBFbGYgaW1hZ2UuXG4iKTsNCisJ
CXJldHVybiAwOw0KKwl9DQorDQorCXJldHVybiAxOw0KK30NCmRpZmYgLXIgMDhmMzlhOWRhMDRm
IHhlbi9hcmNoL2FybS94ZW4vbW0uYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9tbS5jCU1vbiBG
ZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9tbS5jCVN1
biBGZWIgMTIgMTE6NDY6MzIgMjAxMiArMDkwMA0KQEAgLTIxNyw4ICsyMTcsNiBAQCB1bnNpZ25l
ZCBsb25nIGFsbG9jX3BhZ2VfdGFibGVzKGwxZV90ICpsDQogCQlyZXR1cm4gMDsNCiAJfQ0KIA0K
LS8vCWNhY2hlX2NsZWFuX3JhbmdlKHBhZ2UsIHBhZ2UgKyBQQUdFX1NJWkUsIDApOw0KLQ0KIAl3
aXJlX3BhZ2VfdGFibGVzKGwxZSwgcGFnZSk7DQogDQogCXJldHVybiBwYWdlOw0KZGlmZiAtciAw
OGYzOWE5ZGEwNGYgeGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgNCi0tLSBhL3hlbi9pbmNs
dWRlL2FzbS1hcm0vY3VycmVudC5oCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMA0KKysr
IGIveGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgJU3VuIEZlYiAxMiAxMTo0NjozMiAyMDEy
ICswOTAwDQpAQCAtMjcsNiArMjcsMjkgQEANCiAjaWZuZGVmIF9fQVNTRU1CTFlfXw0KIHN0cnVj
dCB2Y3B1Ow0KIA0KK3N0cnVjdCBjcHVfY3R4IHsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICBy
MDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByMTsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcg
ICByMjsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByMzsNCisgICAgICAgIHVuc2lnbmVkIGxv
bmcgICByNDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByNTsNCisgICAgICAgIHVuc2lnbmVk
IGxvbmcgICByNjsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByNzsNCisgICAgICAgIHVuc2ln
bmVkIGxvbmcgICByODsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByOTsNCisgICAgICAgIHVu
c2lnbmVkIGxvbmcgICByMTA7DQorICAgICAgICB1bnNpZ25lZCBsb25nICAgcjExOw0KKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHIxMjsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICB1c3A7DQor
ICAgICAgICB1bnNpZ25lZCBsb25nICAgdWxyOw0KKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHNz
cDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICBzbHI7DQorICAgICAgICB1bnNpZ25lZCBsb25n
ICAgcGM7DQorICAgICAgICB1bnNpZ25lZCBsb25nICAgc3BzcjsNCit9Ow0KKw0KKw0KIHN0cnVj
dCBjcHVfaW5mbyB7DQogCXN0cnVjdCB2Y3B1CSp2Y3B1Ow0KIAl1bnNpZ25lZCBsb25nCXZzcHNy
Ow0KZGlmZiAtciAwOGYzOWE5ZGEwNGYgeGVuL2luY2x1ZGUvYXNtLWFybS9kb21haW4uaA0KLS0t
IGEveGVuL2luY2x1ZGUvYXNtLWFybS9kb21haW4uaAlNb24gRmViIDA2IDExOjE3OjAxIDIwMTIg
KzA5MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmgJU3VuIEZlYiAxMiAxMTo0
NjozMiAyMDEyICswOTAwDQpAQCAtOCw0MiArOCw4IEBADQogI2luY2x1ZGUgPGFzbS9pb21tdS5o
Pg0KICNpbmNsdWRlIDxwdWJsaWMvYXJjaC1hcm0uaD4NCiANCi0jaWYgMA0KLSNkZWZpbmUgTUFQ
SEFTSF9FTlRSSUVTCQkJOA0KLSNkZWZpbmUgTUFQSEFTSF9IQVNIRk4ocGZuKQkJKChwZm4pICYg
KE1BUEhBU0hfRU5UUklFUy0xKSkNCi0jZGVmaW5lIE1BUEhBU0hFTlRfTk9USU5VU0UJCSgodTE2
KX4wVSkNCi0NCi1zdHJ1Y3QgdmNwdV9tYXBoYXNoIHsNCi0gICAgc3RydWN0IHZjcHVfbWFwaGFz
aF9lbnRyeSB7DQotICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsNCi0gICAgICAgIHVpbnQxNl90
ICAgICAgaWR4Ow0KLSAgICAgICAgdWludDE2X3QgICAgICByZWZjbnQ7DQotICAgIH0gaGFzaFtN
QVBIQVNIX0VOVFJJRVNdOw0KLX1fX2NhY2hlbGluZV9hbGlnbmVkOw0KLQ0KLQ0KLSNkZWZpbmUg
TUFQQ0FDSEVfT1JERVIgICA4DQotI2RlZmluZSBNQVBDQUNIRV9FTlRSSUVTICgxIDw8IE1BUENB
Q0hFX09SREVSKQ0KLQ0KLXN0cnVjdCBtYXBjYWNoZSB7DQotICAgIC8qIFRoZSBQVEVzIHRoYXQg
cHJvdmlkZSB0aGUgbWFwcGluZ3MsIGFuZCBhIGN1cnNvciBpbnRvIHRoZSBhcnJheS4gKi8NCi0g
ICAgbDJlX3QJKnRhYmxlOw0KLSAgICB1bnNpZ25lZCBpbnQgY3Vyc29yOw0KLQ0KLSAgICAvKiBQ
cm90ZWN0cyBtYXBfZG9tYWluX3BhZ2UoKS4gKi8NCi0gICAgc3BpbmxvY2tfdCBsb2NrOw0KLQ0K
LSAgICAvKiBXaGljaCBtYXBwaW5ncyBhcmUgaW4gdXNlLCBhbmQgd2hpY2ggYXJlIGdhcmJhZ2Ug
dG8gcmVhcCBuZXh0IGVwb2NoPyAqLw0KLSAgICB1bnNpZ25lZCBsb25nIGludXNlW0JJVFNfVE9f
TE9OR1MoTUFQQ0FDSEVfRU5UUklFUyldOw0KLSAgICB1bnNpZ25lZCBsb25nIGdhcmJhZ2VbQklU
U19UT19MT05HUyhNQVBDQUNIRV9FTlRSSUVTKV07DQotDQotICAgIC8qIExvY2stZnJlZSBwZXIt
VkNQVSBoYXNoIG9mIHJlY2VudGx5LXVzZWQgbWFwcGluZ3MuICovDQotICAgIHN0cnVjdCB2Y3B1
X21hcGhhc2ggdmNwdV9tYXBoYXNoW01BWF9WSVJUX0NQVVNdOw0KLX1fX2NhY2hlbGluZV9hbGln
bmVkOw0KLSNlbmRpZg0KIHN0cnVjdCBhcmNoX2RvbWFpbg0KIHsNCi0jaWYgMA0KICAgICAvKiBJ
L08tcG9ydCBhZG1pbi1zcGVjaWZpZWQgYWNjZXNzIGNhcGFiaWxpdGllcy4gKi8NCiAgICAgc3Ry
dWN0IHJhbmdlc2V0CSppb3BvcnRfY2FwczsNCiANCkBAIC01MSw4ICsxNyw3IEBAIHN0cnVjdCBh
cmNoX2RvbWFpbg0KICAgICBpbnQgKnBpcnFfaXJxOw0KIA0KICAgICB1bnNpZ25lZCBsb25nICpw
aXJxX2VvaV9tYXA7DQotICAgIHVuc2lnbmVkIGxvbmcgcGlycV9lb2lfbWFwX21mbjsNCi0jZW5k
aWYNCisNCiAgICAgc3RydWN0IHBhZ2VfbGlzdF9oZWFkIHJlbG1lbV9saXN0Ow0KIH07DQogDQpA
QCAtNjEsNyArMjYsNyBAQCBzdHJ1Y3QgYXJjaF92Y3B1DQogCXN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQgY3R4Ow0KIH0gX19jYWNoZWxpbmVfYWxpZ25lZDsNCiANCi0vLyNkZWZpbmUgVkNQVV9S
RUcodiwgcmVnKQl2LT5hcmNoLmN0eC5yZWcNCisjZGVmaW5lIFZDUFVfUkVHKHYsIHJlZykJdi0+
YXJjaC5jdHgucmVnDQogDQogI2RlZmluZSByZXR1cm5fcmVnKHYpCQkoKHYpLT5hcmNoLmN0eC5y
MCkNCiANCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch07.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch07.diff"


YXJtOiBpbXBsZW1lbnQgdGhlIGZ1bmN0aW9ucyB3aGljaCBhcmUgcmVxdWlyZWQgdG8gY3Jl
YXRlIHRoZSBkb20wLgoKIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUgICAgICAgfCAgICAx
ICsKIHhlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21haW4uYyAgfCAgMTQ0ICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t
CiB4ZW4vYXJjaC9hcm0veGVuL2FybXY3LlMgICAgICAgIHwgICAxOSArKysrKysrKwogeGVu
L2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYyB8ICAxODkgKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKy0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgfCAgICAy
IC0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vY3VycmVudC5oICAgfCAgIDIzICsrKysrKysrKysK
IHhlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmggICAgfCAgIDM5ICstLS0tLS0tLS0tLS0t
LS0tCiA3IGZpbGVzIGNoYW5nZWQsIDM1NiBpbnNlcnRpb25zKCspLCA2MSBkZWxldGlvbnMo
LSkKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoK
ZGlmZiAtciAwOGYzOWE5ZGEwNGYgeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQotLS0gYS94
ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkw
MAorKysgYi94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCVN1biBGZWIgMTIgMTE6NDY6MzIg
MjAxMiArMDkwMApAQCAtMjEsMyArMjEsNCBAQCBvYmoteSArPSBjcmFzaC5vCiBvYmoteSAr
PSBwMm0ubwogb2JqLXkgKz0gcGVyZm1vbi5vCiBvYmoteSArPSBwY2kubworb2JqLXkgKz0g
YXJtdjcubwpkaWZmIC1yIDA4ZjM5YTlkYTA0ZiB4ZW4vYXJjaC9hcm0veGVuL2FyY2hfZG9t
YWluLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jCU1vbiBGZWIgMDYg
MTE6MTc6MDEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2FyY2hfZG9tYWlu
LmMJU3VuIEZlYiAxMiAxMTo0NjozMiAyMDEyICswOTAwCkBAIC0zMSw2ICszMSwxMiBAQAog
I2luY2x1ZGUgPHhlbi9pcnEuaD4KICNpbmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4KICNp
bmNsdWRlIDx4ZW4vc29mdGlycS5oPgorI2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+CQorI2lu
Y2x1ZGUgPGFzbS9jcHUtb3BzLmg+CisjaW5jbHVkZSA8YXNtL21lbW9yeS5oPgorI2luY2x1
ZGUgPGFzbS9tbXUuaD4KKworc3RydWN0IHZjcHUgKnN3aXRjaF90byggc3RydWN0IHZjcHUg
Kiwgc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCAqLCBzdHJ1Y3QgdmNwdV9ndWVzdF9jb250
ZXh0ICopOwogCiB2b2lkIGFyY2hfZHVtcF9kb21haW5faW5mbyhzdHJ1Y3QgZG9tYWluICpk
KQogewpAQCAtNTIsMzMgKzU4LDg0IEBAIHVuc2lnbmVkIGxvbmcgaHlwZXJjYWxsX2NyZWF0
ZV9jb250aW51YXQKIAogaW50IGFyY2hfZG9tYWluX2NyZWF0ZShzdHJ1Y3QgZG9tYWluICpk
LCB1bnNpZ25lZCBpbnQgZG9tY3JfZmxhZ3MpCiB7Ci0JTk9UX1lFVCgpOworCWludCByYzsK
IAotCXJldHVybiAtRUlOVkFMOworCXJjID0gMDsKKwlpZiAoaXNfaWRsZV9kb21haW4oZCkp
CisJCXJldHVybiByYzsKKworCWQtPmFyY2guaW9wb3J0X2NhcHMgPSByYW5nZXNldF9uZXco
ZCwgIkkvTyBQb3J0cyIsIFJBTkdFU0VURl9wcmV0dHlwcmludF9oZXgpOworCXJjID0gLUVO
T01FTTsKKwlpZiAoZC0+YXJjaC5pb3BvcnRfY2FwcyA9PSBOVUxMKSB7CisJCWdvdG8gZmFp
bGVkOworCX0KKworCWlmICgoZC0+c2hhcmVkX2luZm8gPSBhbGxvY194ZW5oZWFwX3BhZ2Vz
KDAsIE1FTUZfYml0cygzMikpKSA9PSBOVUxMKSB7CisJCWdvdG8gZmFpbGVkOworCX0KKwor
CWNsZWFyX3BhZ2UoZC0+c2hhcmVkX2luZm8pOworCXNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vl
c3QodmlydF90b19wYWdlKGQtPnNoYXJlZF9pbmZvKSwgZCwgWEVOU0hBUkVfd3JpdGFibGUp
OworCisJZC0+YXJjaC5waXJxX2lycSA9IHhtYWxsb2NfYXJyYXkoaW50LCBkLT5ucl9waXJx
cyk7CisJaWYgKCFkLT5hcmNoLnBpcnFfaXJxKSB7CisJCWdvdG8gZmFpbGVkOworCX0KKwor
CW1lbXNldChkLT5hcmNoLnBpcnFfaXJxLCAwLCBkLT5ucl9waXJxcyAqIHNpemVvZigqZC0+
YXJjaC5waXJxX2lycSkpOworCisJZC0+YXJjaC5pcnFfcGlycSA9IHhtYWxsb2NfYXJyYXko
aW50LCBucl9pcnFzKTsKKwlpZiAoICFkLT5hcmNoLmlycV9waXJxICkgeworCQlnb3RvIGZh
aWxlZDsKKwl9CisKKwltZW1zZXQoZC0+YXJjaC5pcnFfcGlycSwgMCwgbnJfaXJxcyAqIHNp
emVvZigqZC0+YXJjaC5pcnFfcGlycSkpOworCisJcmV0dXJuIDA7CisKK2ZhaWxlZDoKKwlk
LT5pc19keWluZyA9IERPTURZSU5HX2RlYWQ7CisJeGZyZWUoZC0+YXJjaC5waXJxX2lycSk7
CisJeGZyZWUoZC0+YXJjaC5pcnFfcGlycSk7CisKKwlmcmVlX3hlbmhlYXBfcGFnZShkLT5z
aGFyZWRfaW5mbyk7CisKKwlyZXR1cm4gcmM7CiB9CiAKIHZvaWQgYXJjaF9kb21haW5fZGVz
dHJveShzdHJ1Y3QgZG9tYWluICpkKQogewotCU5PVF9ZRVQoKTsKKwlmcmVlX3hlbmhlYXBf
cGFnZShkLT5zaGFyZWRfaW5mbyk7CisKKwl4ZnJlZShkLT5hcmNoLnBpcnFfaXJxKTsKKwl4
ZnJlZShkLT5hcmNoLmlycV9waXJxKTsKIH0KIAogc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4
dCAqYWxsb2NfdmNwdV9ndWVzdF9jb250ZXh0KHZvaWQpCiB7Ci0JTk9UX1lFVCgpOworCXN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgKnZnYzsKIAotCXJldHVybiBOVUxMOworCXZnYyA9
IHhtYWxsb2Moc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCk7CisKKwlyZXR1cm4gdmdjOwog
fQogCiB2b2lkIGZyZWVfdmNwdV9ndWVzdF9jb250ZXh0KHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQgKmNvbnRleHQpCiB7Ci0JTk9UX1lFVCgpOworCXhmcmVlKGNvbnRleHQpOwogfQog
CiAKIHN0cnVjdCB2Y3B1ICphbGxvY192Y3B1X3N0cnVjdCh2b2lkKQogewotCU5PVF9ZRVQo
KTsKLQlyZXR1cm4gTlVMTDsKKwlzdHJ1Y3QgdmNwdSAqdjsKKworCXYgPSB4bWFsbG9jKHN0
cnVjdCB2Y3B1KTsKKwlpZiAoIHYgIT0gTlVMTCApCisJCW1lbXNldCh2LCAwLCBzaXplb2Yo
c3RydWN0IHZjcHUpKTsKKworCisJcmV0dXJuIHY7CiB9CiAKIHZvaWQgYXJjaF92Y3B1X3Jl
c2V0KHN0cnVjdCB2Y3B1ICp2KQpAQCAtODgsNyArMTQ1LDYgQEAgdm9pZCBhcmNoX3ZjcHVf
cmVzZXQoc3RydWN0IHZjcHUgKnYpCiAKIGludCB2Y3B1X2luaXRpYWxpc2Uoc3RydWN0IHZj
cHUgKnYpCiB7Ci0JTk9UX1lFVCgpOwogCXJldHVybiAwOwogfQogCkBAIC05OSwyNyArMTU1
LDMyIEBAIHZvaWQgdmNwdV9kZXN0cm95KHN0cnVjdCB2Y3B1ICp2KQogCiB2b2lkIGZyZWVf
dmNwdV9zdHJ1Y3Qoc3RydWN0IHZjcHUgKnYpCiB7Ci0JTk9UX1lFVCgpOworCXhmcmVlKHYp
OwogfQogCiBzdHJ1Y3QgZG9tYWluICphbGxvY19kb21haW5fc3RydWN0KHZvaWQpCiB7Ci0J
Tk9UX1lFVCgpOworCXN0cnVjdCBkb21haW4gKmQ7CiAKLQlyZXR1cm4gTlVMTDsKKwlkID0g
eG1hbGxvYyhzdHJ1Y3QgZG9tYWluKTsKKwlpZiAoIGQgIT0gTlVMTCApCisJCW1lbXNldChk
LCAwLCBzaXplb2Yoc3RydWN0IGRvbWFpbikpOworCisJcmV0dXJuIGQ7CiB9CiAKIAogdm9p
ZCBmcmVlX2RvbWFpbl9zdHJ1Y3Qoc3RydWN0IGRvbWFpbiAqZCkKIHsKLQlOT1RfWUVUKCk7
CisJeGZyZWUoZCk7CiB9CiAKKy8qIFRoaXMgaXMgY2FsbGVkIGJ5IGFyY2hfZmluYWxfc2V0
dXBfZ3Vlc3QgYW5kIGRvX2Jvb3RfdmNwdSAqLwogaW50IGFyY2hfc2V0X2luZm9fZ3Vlc3Qo
c3RydWN0IHZjcHUgKnYsIHZjcHVfZ3Vlc3RfY29udGV4dF90ICpjdHgpCiB7CiAJTk9UX1lF
VCgpOwogCi0JcmV0dXJuIDA7CisJcmV0dXJuIC1FSU5WQUw7CiAKIH0KIApAQCAtMTM1LDEy
ICsxOTYsMTcgQEAgdm9pZCBkdW1wX3BhZ2VmcmFtZV9pbmZvKHN0cnVjdCBkb21haW4gKgog
CiB2b2lkIGNvbnRleHRfc3dpdGNoKHN0cnVjdCB2Y3B1ICpwcmV2LCBzdHJ1Y3QgdmNwdSAq
bmV4dCkKIHsKLQlOT1RfWUVUKCk7CisJQVNTRVJUKHByZXYgIT0gbmV4dCk7CisJQVNTRVJU
KHZjcHVfcnVubmFibGUobmV4dCkpOworCisgICAgICAgIHByZXYgPSAgc3dpdGNoX3RvKHBy
ZXYsICZwcmV2LT5hcmNoLmN0eCwgJm5leHQtPmFyY2guY3R4KTsKIH0KIAogdm9pZCBjb250
aW51ZV9ydW5uaW5nKHN0cnVjdCB2Y3B1ICpzYW1lKQogewogCU5PVF9ZRVQoKTsKKworCXJl
dHVybiA7CiB9CiAKIHZvaWQgc3luY19sYXp5X2V4ZWNzdGF0ZV9jcHUodW5zaWduZWQgaW50
IGNwdSkKQEAgLTE2OCw2ICsyMzQsMjQgQEAgdm9pZCByZWxpbnF1aXNoX21lbW9yeShzdHJ1
Y3QgZG9tYWluICpkLAogCU5PVF9ZRVQoKTsKIH0KIAordm9pZCB0cmFjZV9kb21oZWFwX3Bh
Z2VzKGNvbnN0IGNoYXIgKmNhcHRpb24sIHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBsaXN0
X2hlYWQgKmxpc3QpCit7CisJc3RydWN0IGxpc3RfaGVhZCAqZW50OworCXN0cnVjdCBwYWdl
X2luZm8gICpwYWdlOworCisJLyogVXNlIGEgcmVjdXJzaXZlIGxvY2ssIGFzIHdlIG1heSBl
bnRlciAnZnJlZV9kb21oZWFwX3BhZ2UnLiAqLworCXNwaW5fbG9ja19yZWN1cnNpdmUoJmQt
PnBhZ2VfYWxsb2NfbG9jayk7CisKKwllbnQgPSBsaXN0LT5uZXh0OworCXdoaWxlICggZW50
ICE9IGxpc3QgKQorCXsKKwkJcGFnZSA9IGxpc3RfZW50cnkoZW50LCBzdHJ1Y3QgcGFnZV9p
bmZvLCBsaXN0KTsKKwkJZW50ID0gZW50LT5uZXh0OworCX0KKworCXNwaW5fdW5sb2NrX3Jl
Y3Vyc2l2ZSgmZC0+cGFnZV9hbGxvY19sb2NrKTsKK30KKwogaW50IGRvbWFpbl9yZWxpbnF1
aXNoX3Jlc291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQogewogCU5PVF9ZRVQoKTsKQEAgLTE3
Nyw3ICsyNjEsMTYgQEAgaW50IGRvbWFpbl9yZWxpbnF1aXNoX3Jlc291cmNlcyhzdHJ1Y3Qg
ZAogCiB2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKQogewotCU5PVF9ZRVQoKTsK
Kwl3aGlsZSgxKSB7CisJCWlmIChjcHVfaXNfaGFsdGFibGUoc21wX3Byb2Nlc3Nvcl9pZCgp
KSkgeworCQkJbG9jYWxfaXJxX2Rpc2FibGUoKTsKKwkJCWNwdV9pZGxlKCk7CisJCQlsb2Nh
bF9pcnFfZW5hYmxlKCk7CisJCX0KKworCQlkb190YXNrbGV0KCk7CisJCWRvX3NvZnRpcnEo
KTsKKwl9CiB9CiAKIGxvbmcgYXJjaF9kb192Y3B1X29wKGludCBjbWQsIHN0cnVjdCB2Y3B1
ICp2LCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKQEAgLTE4OSwyMiArMjgyLDMzIEBA
IGxvbmcgYXJjaF9kb192Y3B1X29wKGludCBjbWQsIHN0cnVjdCB2Y3AKIAogdm9pZCB2Y3B1
X2tpY2soc3RydWN0IHZjcHUgKnYpCiB7Ci0JTk9UX1lFVCgpOworCWJvb2xfdCBydW5uaW5n
ID0gdi0+aXNfcnVubmluZzsKKworCXZjcHVfdW5ibG9jayh2KTsKKworCWlmIChydW5uaW5n
ICYmIChpbl9pcnEoKSB8fCAodiAhPSBjdXJyZW50KSkpIHsKKwkJY3B1X3JhaXNlX3NvZnRp
cnEodi0+cHJvY2Vzc29yLCBWQ1BVX0tJQ0tfU09GVElSUSk7CisJfQogfQogCiB2b2lkIHZj
cHVfbWFya19ldmVudHNfcGVuZGluZyhzdHJ1Y3QgdmNwdSAqdikKIHsKLQlOT1RfWUVUKCk7
CisJaW50IGFscmVhZHkgPSB0ZXN0X2FuZF9zZXRfYml0KDAsICh1bnNpZ25lZCBsb25nICop
JnZjcHVfaW5mbyh2LCBldnRjaG5fdXBjYWxsX3BlbmRpbmcpKTsKKworCWlmIChhbHJlYWR5
KSB7CisJCXJldHVybjsKKwl9CisKKwl2Y3B1X2tpY2sodik7CiB9CiAKIHN0YXRpYyB2b2lk
IHZjcHVfa2lja19zb2Z0aXJxKHZvaWQpCiB7Ci0JTk9UX1lFVCgpOwogfQogCiBzdGF0aWMg
aW50IF9faW5pdCB2Y3B1X2tpY2tfc29mdGlycV9pbml0KHZvaWQpCiB7Ci0JTk9UX1lFVCgp
OworCW9wZW5fc29mdGlycShWQ1BVX0tJQ0tfU09GVElSUSwgdmNwdV9raWNrX3NvZnRpcnEp
OwogCiAJcmV0dXJuIDA7CiB9CmRpZmYgLXIgMDhmMzlhOWRhMDRmIHhlbi9hcmNoL2FybS94
ZW4vYXJtdjcuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2FybXY3LlMJU3VuIEZlYiAxMiAxMTo0NjozMiAy
MDEyICswOTAwCkBAIC0wLDAgKzEsMTkgQEAKKyNpbmNsdWRlIDxhc20vcGFnZS5oPgorI2lu
Y2x1ZGUgPGFzbS9jcHUtb3BzLmg+CisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgorI2luY2x1
ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+Cisj
aW5jbHVkZSA8cHVibGljL2FyY2gtYXJtLmg+CisKKwkudGV4dAorRU5UUlkoY3B1X2lkbGUp
CisJZHNiCisJd2ZpCisJbW92CXBjLCBscgorCitFTlRSWShjcHVfaGFsdCkKKwltb3YJcGMs
IGxyCisKK0VOVFJZKGNwdV9yZXNldCkKKwltb3YJcGMsIGxyCisKZGlmZiAtciAwOGYzOWE5
ZGEwNGYgeGVuL2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwotLS0gYS94ZW4vYXJjaC9h
cm0veGVuL2RvbWFpbl9idWlsZC5jCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMAor
KysgYi94ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jCVN1biBGZWIgMTIgMTE6NDY6
MzIgMjAxMiArMDkwMApAQCAtMzMsNiArMzMsNjcgQEAKICNpbmNsdWRlIDxwdWJsaWMveGVu
Lmg+CiAjaW5jbHVkZSA8cHVibGljL3ZlcnNpb24uaD4KIAorZXh0ZXJuIHZvaWQgcmV0dXJu
X3RvX2d1ZXN0KCk7CisKK3ZvaWQgdmNwdV9jb250ZXh0X2luaXQoc3RydWN0IHZjcHUgKnYs
IHVuc2lnbmVkIGxvbmcgc3RrLCB1bnNpZ25lZCBsb25nIHBjLCBzdHJ1Y3Qgc3RhcnRfaW5m
byAqc2kpCit7CisJdm9pZCAqc3RhY2s7CisJc3RydWN0IGNwdV9pbmZvICpjaTsKKwlzdHJ1
Y3QgY3B1X2N0eCAqY3B1X2N0eDsKKworCXN0YWNrID0gYWxsb2NfeGVuaGVhcF9wYWdlcyhT
VEFDS19PUkRFUiwgMCk7CisJaWYoc3RhY2sgPT0gTlVMTCkgeworCQlyZXR1cm47CisJfQor
CisJY2kgPSAoc3RydWN0IGNwdV9pbmZvICopc3RhY2s7CisJY2ktPnZjcHUgPSB2OworCWNp
LT52c3AgPSAwOworCWNpLT52c3BzciA9IFBTUl9NT0RFX1NWQzsKKwljaS0+dmRhY3IgPSBE
QUNSX1NUQVRfU1ZDOworCisJc3RhY2sgKz0gKFNUQUNLX1NJWkUgLSBzaXplb2Yoc3RydWN0
IGNwdV9jdHgpKTsKKworCWNwdV9jdHggPSAoc3RydWN0IGNwdV9jdHggKilzdGFjazsKKwlj
cHVfY3R4LT5yMCA9IDA7CisJY3B1X2N0eC0+cjEyID0gKHVuc2lnbmVkIGxvbmcpc2k7CisJ
Y3B1X2N0eC0+dXNwID0gc3RrOworCWNwdV9jdHgtPnVsciA9IDA7CisJY3B1X2N0eC0+c3Nw
ID0gKHVuc2lnbmVkIGxvbmcpKHN0YWNrICsgc2l6ZW9mKHN0cnVjdCBjcHVfY3R4KSk7CisJ
Y3B1X2N0eC0+cGMgPSBwYzsKKwljcHVfY3R4LT5zcHNyID0gMHgxMDsKKworCVZDUFVfUkVH
KHYsIHIxMykgPSAodW5zaWduZWQgbG9uZylzdGFjazsKKwlWQ1BVX1JFRyh2LCByMTQpID0g
KHVuc2lnbmVkIGxvbmcpcmV0dXJuX3RvX2d1ZXN0OworCisJVkNQVV9SRUcodiwgZGFjcikg
PSBEQUNSX1NUQVRfU1ZDOworCVZDUFVfUkVHKHYsIGZjc2VpZHIpID0gMDsKKwlWQ1BVX1JF
Ryh2LCBjb250ZXh0aWRyKSA9IDA7CisJVkNQVV9SRUcodiwgY3BhcikgPSAoMHg0MCkgfCAo
MSA8PCAxMyk7Cit9CisKKyNkZWZpbmUgRE9NX1BGTl9BTElHTgkoU0VDVElPTl9TSVpFID4+
IFBBR0VfU0hJRlQpCisKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGFsbG9jX2RvbWFpbl9wYWdl
cyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgc2l6ZSkKK3sKKwl1bnNpZ25lZCBw
aHlzOworCXVuc2lnbmVkIGxvbmcgcGFnZXMgPSBzaXplID4+IFBBR0VfU0hJRlQ7CisKKwlk
LT5tYXhfcGFnZXMgPSB+KDB4MFVMKTsKKworCXBoeXMgPSBhbGxvY19ib290X3BhZ2VzKHBh
Z2VzLCBET01fUEZOX0FMSUdOKTsKKwkKKwlpZiAoIXBoeXMpIHsKKwkJZC0+dG90X3BhZ2Vz
ID0gMDsKKwkJcmV0dXJuIDA7CisJfQorCisJZC0+dG90X3BhZ2VzID0gcGFnZXM7CisKKwkv
KiBTZXQgUGFnZSBPd25lciAqLworCXJldHVybiBwaHlzIDw8PSBQQUdFX1NISUZUOworfQor
CiAvKgogICogZG9tYWluX2NvbnN0cnVjdCgpIHNob3VsZCBiZSBhbHdheXMgaW52b2tlZCBp
biBpZGxlIGRvbWFpbgogICovCkBAIC00MCw4ICsxMDEsMTMyIEBAIGludCBkb21haW5fY29u
c3RydWN0KHN0cnVjdCBkb21haW4gKmQsCiAJCSAgICAgdW5zaWduZWQgbG9uZyBpbWdfc3Rh
cnQsIHVuc2lnbmVkIGxvbmcgaW1nX2xlbiwgCiAJCSAgICAgdW5zaWduZWQgbG9uZyBkb21f
c2l6ZSwgdW5zaWduZWQgaW50IHZjcHVzKQogewotCU5PVF9ZRVQoKTsKKwlpbnQgaSwgcmM7
CisJc3RydWN0IHZjcHUgKnY7CisJc3RydWN0IGVsZl9iaW5hcnkgZWxmOworCXN0cnVjdCBl
bGZfZG9tX3Bhcm1zIHBhcm1zOworCXN0cnVjdCBzdGFydF9pbmZvICpzaTsKKwl1bnNpZ25l
ZCBsb25nIHZzdGFydCwgdmVuZCwgdmVudHJ5OworCXVuc2lnbmVkIGxvbmcgcHN0YXJ0LCBw
ZW5kLCBwbWFwLCBsZW47CiAKLQlyZXR1cm4gLUVJTlZBTDsKKwlsMWVfdCAqZ3B0OworCisJ
QlVHX09OKGQgPT0gTlVMTCk7CisJQlVHX09OKGRvbV9zaXplICYgflNFQ1RJT05fTUFTSyk7
CisKKwlwc3RhcnQgPSBhbGxvY19kb21haW5fcGFnZXMoZCwgZG9tX3NpemUpOworCWlmICgh
cHN0YXJ0KSB7CisJCXJldHVybiAtRU5PTUVNOworCX0KKworCW1lbWNweSgocHN0YXJ0ICsg
ZG9tX3NpemUgLSBpbWdfbGVuKSwgaW1nX3N0YXJ0LCBpbWdfbGVuKTsKKwlpbWdfc3RhcnQg
PSBwc3RhcnQgKyBkb21fc2l6ZSAtIGltZ19sZW47CisKKwlpZiAoKHJjID0gZWxmX2luaXQo
JmVsZiwgaW1nX3N0YXJ0LCBpbWdfbGVuKSkgIT0gMCkgeworCQlyZXR1cm4gcmM7CisJfQor
CisJZWxmX3BhcnNlX2JpbmFyeSgmZWxmKTsKKworCWlmICgocmMgPSBlbGZfeGVuX3BhcnNl
KCZlbGYsICZwYXJtcykpICE9IDApIHsKKwkJcmV0dXJuIHJjOworCX0KKworCWQtPnZjcHUg
PSB4bWFsbG9jX2FycmF5KHN0cnVjdCB2Y3B1ICosIE1BWF9WSVJUX0NQVVMpOworCWlmICgh
ZC0+dmNwdSkgeworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisKKwltZW1zZXQoZC0+dmNwdSwg
MCwgTUFYX1ZJUlRfQ1BVUyAqIHNpemVvZigqZC0+dmNwdSkpOworCWQtPm1heF92Y3B1cyA9
IE1BWF9WSVJUX0NQVVM7CisKKwlmb3IgKGkgPSAwOyBpIDwgTUFYX1ZJUlRfQ1BVUzsgaSsr
KSB7CisJCWQtPnNoYXJlZF9pbmZvLT52Y3B1X2luZm9baV0uZXZ0Y2huX3VwY2FsbF9tYXNr
ID0gMTsKKwkJZC0+c2hhcmVkX2luZm8tPnZjcHVfaW5mb1tpXS5hcmNoLmNwc3IgPSAoVlBT
Ul9JX0JJVCB8IFZQU1JfRl9CSVQgfCBWUFNSX01PREVfU1ZDKTsKKwl9CisKKwlmb3IgKGkg
PSAwOyBpIDwgdmNwdXM7IGkrKykgeworCQlpZiAoYWxsb2NfdmNwdShkLCBpLCBpKSA9PSBO
VUxMKSB7CisJCQlyZXR1cm4gLUVOT01FTTsKKwkJfQorCX0KKworCXZzdGFydCA9IHBhcm1z
LnZpcnRfa3N0YXJ0ICYgU0VDVElPTl9NQVNLOworCXZlbmQgPSByb3VuZF91cChwYXJtcy52
aXJ0X2tlbmQsIEwxX1RBQkxFX1NJWkUpOworCXZlbnRyeSA9IHBhcm1zLnZpcnRfZW50cnk7
CisKKwlsZW4gPSB2ZW5kIC0gdnN0YXJ0OworCisJLyogR3Vlc3QgIHBhZ2UgdGFibGUgaXMg
bG9jYXRlZCBpbiB0aGUgZW5kIG9mIHZlbmQgKi8KKwlncHQgPSAobDFlX3QgKikocHN0YXJ0
ICsgbGVuKTsKKwkKKwkvKiBEdXBsaWNhdGUgTDEgcGFnZSB0YWJsZSAqLworCW1lbWNweShn
cHQsIHhlbl90cmFuc2xhdGlvbl90YWJsZSwgTDFfVEFCTEVfU0laRSk7CisKKwlwbWFwID0g
cHN0YXJ0OworCXBlbmQgPSBwbWFwICsgZG9tX3NpemU7CisKKworCWdwdCA9IGwxX2xpbmVh
cl9vZmZzZXQoZ3B0LCB2c3RhcnQpOworCisJLyogQ3JlYXRlIDE6MSBtYXBwaW5nICovCisJ
ZG8geworCQkqZ3B0ID0gTUtfTDFFKHBtYXAsIEwxRV9UWVBFX0dVRVNUKTsKKwkJcG1hcCAr
PSBTRUNUSU9OX1NJWkU7CisJfSB3aGlsZShncHQrKywgcG1hcCA8IHBlbmQpOworIAorCS8q
IEFjdGl2YXRlIGd1ZXN0IGFkZHJlc3Mgc3BhY2UgdG8gcmVsb2NhdGUgZ3Vlc3QgaW1hZ2Ug
Ki8KKwltbXVfc3dpdGNoX3R0YihncHQgJiB+KDB4NDAwMCAtIDEpKTsKKworCWVsZi5kZXN0
ID0gKHZvaWQgKil2ZW50cnk7CisJZWxmX2xvYWRfYmluYXJ5KCZlbGYpOworCisJc2kgPSAo
c3RydWN0IHN0YXJ0X2luZm8gKikodmVuZCArIEwxX1RBQkxFX1NJWkUpOworCW1lbXNldChz
aSwgMCwgUEFHRV9TSVpFKTsKKwkKKworCXNpLT5ucl9wYWdlcyAJICA9IGQtPnRvdF9wYWdl
czsKKwlzaS0+c2hhcmVkX2luZm8gICA9IHZpcnRfdG9fbWFkZHIoZC0+c2hhcmVkX2luZm8p
OworCXNpLT5wdF9iYXNlIAkgID0gdmVuZDsKKwlzaS0+bnJfcHRfZnJhbWVzICA9IDQ7CisJ
c2ktPm1mbl9saXN0IAkgID0gMDsKKwlzaS0+Zmlyc3RfcDJtX3BmbiA9IHBzdGFydCA+PiBQ
QUdFX1NISUZUOworCXNpLT5mbGFncyAJICA9IDA7CisJc2ktPm1pbl9tZm4JICA9IHBzdGFy
dCA+PiBQQUdFX1NISUZUOworCisJaWYgKGQtPmRvbWFpbl9pZCA9PSAwKSB7CisJCXNpLT5m
bGFncyA9IFNJRl9QUklWSUxFR0VEIHwgU0lGX0lOSVRET01BSU47CisJfQorCisJdiA9IGQt
PnZjcHVbMF07CisKKwlWQ1BVX1JFRyh2LCB0dGJyMCkgPSAodW5zaWduZWQgbG9uZylncHQ7
CisKKwltbXVfc3dpdGNoX3R0YihWQ1BVX1JFRyhpZGxlX3ZjcHVbMF0sIHR0YnIwKSk7CisK
Kwl2Y3B1X2NvbnRleHRfaW5pdCh2LCAwLCB2ZW50cnksIHNpKTsKKworCXYtPmlzX2luaXRp
YWxpc2VkID0gMTsKKwljbGVhcl9iaXQoX1ZQRl9kb3duLCAmdi0+cGF1c2VfZmxhZ3MpOwor
CisJcmMgPSAwOworCisJLyogRE9NMCBpcyBwZXJtaXR0ZWQgZnVsbCBJL08gY2FwYWJpbGl0
aWVzLiAqLworCXJjIHw9IGlvcG9ydHNfcGVybWl0X2FjY2Vzcyhkb20wLCAwLCAweEZGRkYp
OworCXJjIHw9IGlvbWVtX3Blcm1pdF9hY2Nlc3MoZG9tMCwgMFVMLCB+MFVMKTsKKwlyYyB8
PSBpcnFzX3Blcm1pdF9hY2Nlc3MoZG9tMCwgMCwgZC0+bnJfcGlycXMgLSAxKTsKKworCXJl
dHVybiByYzsKIH0KIAoraW50IGVsZl9zYW5pdHlfY2hlY2soY29uc3QgRWxmX0VoZHIgKmVo
ZHIpCit7CisJaWYgKCAhSVNfRUxGKCplaGRyKSB8fAorCQkoZWhkci0+ZV9pZGVudFtFSV9E
QVRBXSAhPSBFTEZEQVRBMkxTQikgfHwKKwkJKGVoZHItPmVfdHlwZSAhPSBFVF9FWEVDKSAp
IHsKKwkJcHJpbnRrKCJET00wIGltYWdlIGlzIG5vdCBhIFhlbi1jb21wYXRpYmxlIEVsZiBp
bWFnZS5cbiIpOworCQlyZXR1cm4gMDsKKwl9CisKKwlyZXR1cm4gMTsKK30KZGlmZiAtciAw
OGYzOWE5ZGEwNGYgeGVuL2FyY2gvYXJtL3hlbi9tbS5jCi0tLSBhL3hlbi9hcmNoL2FybS94
ZW4vbW0uYwlNb24gRmViIDA2IDExOjE3OjAxIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9tbS5jCVN1biBGZWIgMTIgMTE6NDY6MzIgMjAxMiArMDkwMApAQCAtMjE3LDgg
KzIxNyw2IEBAIHVuc2lnbmVkIGxvbmcgYWxsb2NfcGFnZV90YWJsZXMobDFlX3QgKmwKIAkJ
cmV0dXJuIDA7CiAJfQogCi0vLwljYWNoZV9jbGVhbl9yYW5nZShwYWdlLCBwYWdlICsgUEFH
RV9TSVpFLCAwKTsKLQogCXdpcmVfcGFnZV90YWJsZXMobDFlLCBwYWdlKTsKIAogCXJldHVy
biBwYWdlOwpkaWZmIC1yIDA4ZjM5YTlkYTA0ZiB4ZW4vaW5jbHVkZS9hc20tYXJtL2N1cnJl
bnQuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20tYXJtL2N1cnJlbnQuaAlNb24gRmViIDA2IDEx
OjE3OjAxIDIwMTIgKzA5MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgJ
U3VuIEZlYiAxMiAxMTo0NjozMiAyMDEyICswOTAwCkBAIC0yNyw2ICsyNywyOSBAQAogI2lm
bmRlZiBfX0FTU0VNQkxZX18KIHN0cnVjdCB2Y3B1OwogCitzdHJ1Y3QgY3B1X2N0eCB7Cisg
ICAgICAgIHVuc2lnbmVkIGxvbmcgICByMDsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIx
OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjI7CisgICAgICAgIHVuc2lnbmVkIGxvbmcg
ICByMzsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHI0OworICAgICAgICB1bnNpZ25lZCBs
b25nICAgcjU7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByNjsKKyAgICAgICAgdW5zaWdu
ZWQgbG9uZyAgIHI3OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjg7CisgICAgICAgIHVu
c2lnbmVkIGxvbmcgICByOTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMDsKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHIxMTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMjsK
KyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHVzcDsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAg
IHVscjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHNzcDsKKyAgICAgICAgdW5zaWduZWQg
bG9uZyAgIHNscjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHBjOworICAgICAgICB1bnNp
Z25lZCBsb25nICAgc3BzcjsKK307CisKKwogc3RydWN0IGNwdV9pbmZvIHsKIAlzdHJ1Y3Qg
dmNwdQkqdmNwdTsKIAl1bnNpZ25lZCBsb25nCXZzcHNyOwpkaWZmIC1yIDA4ZjM5YTlkYTA0
ZiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1h
cm0vZG9tYWluLmgJTW9uIEZlYiAwNiAxMToxNzowMSAyMDEyICswOTAwCisrKyBiL3hlbi9p
bmNsdWRlL2FzbS1hcm0vZG9tYWluLmgJU3VuIEZlYiAxMiAxMTo0NjozMiAyMDEyICswOTAw
CkBAIC04LDQyICs4LDggQEAKICNpbmNsdWRlIDxhc20vaW9tbXUuaD4KICNpbmNsdWRlIDxw
dWJsaWMvYXJjaC1hcm0uaD4KIAotI2lmIDAKLSNkZWZpbmUgTUFQSEFTSF9FTlRSSUVTCQkJ
OAotI2RlZmluZSBNQVBIQVNIX0hBU0hGTihwZm4pCQkoKHBmbikgJiAoTUFQSEFTSF9FTlRS
SUVTLTEpKQotI2RlZmluZSBNQVBIQVNIRU5UX05PVElOVVNFCQkoKHUxNil+MFUpCi0KLXN0
cnVjdCB2Y3B1X21hcGhhc2ggewotICAgIHN0cnVjdCB2Y3B1X21hcGhhc2hfZW50cnkgewot
ICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKLSAgICAgICAgdWludDE2X3QgICAgICBpZHg7
Ci0gICAgICAgIHVpbnQxNl90ICAgICAgcmVmY250OwotICAgIH0gaGFzaFtNQVBIQVNIX0VO
VFJJRVNdOwotfV9fY2FjaGVsaW5lX2FsaWduZWQ7Ci0KLQotI2RlZmluZSBNQVBDQUNIRV9P
UkRFUiAgIDgKLSNkZWZpbmUgTUFQQ0FDSEVfRU5UUklFUyAoMSA8PCBNQVBDQUNIRV9PUkRF
UikKLQotc3RydWN0IG1hcGNhY2hlIHsKLSAgICAvKiBUaGUgUFRFcyB0aGF0IHByb3ZpZGUg
dGhlIG1hcHBpbmdzLCBhbmQgYSBjdXJzb3IgaW50byB0aGUgYXJyYXkuICovCi0gICAgbDJl
X3QJKnRhYmxlOwotICAgIHVuc2lnbmVkIGludCBjdXJzb3I7Ci0KLSAgICAvKiBQcm90ZWN0
cyBtYXBfZG9tYWluX3BhZ2UoKS4gKi8KLSAgICBzcGlubG9ja190IGxvY2s7Ci0KLSAgICAv
KiBXaGljaCBtYXBwaW5ncyBhcmUgaW4gdXNlLCBhbmQgd2hpY2ggYXJlIGdhcmJhZ2UgdG8g
cmVhcCBuZXh0IGVwb2NoPyAqLwotICAgIHVuc2lnbmVkIGxvbmcgaW51c2VbQklUU19UT19M
T05HUyhNQVBDQUNIRV9FTlRSSUVTKV07Ci0gICAgdW5zaWduZWQgbG9uZyBnYXJiYWdlW0JJ
VFNfVE9fTE9OR1MoTUFQQ0FDSEVfRU5UUklFUyldOwotCi0gICAgLyogTG9jay1mcmVlIHBl
ci1WQ1BVIGhhc2ggb2YgcmVjZW50bHktdXNlZCBtYXBwaW5ncy4gKi8KLSAgICBzdHJ1Y3Qg
dmNwdV9tYXBoYXNoIHZjcHVfbWFwaGFzaFtNQVhfVklSVF9DUFVTXTsKLX1fX2NhY2hlbGlu
ZV9hbGlnbmVkOwotI2VuZGlmCiBzdHJ1Y3QgYXJjaF9kb21haW4KIHsKLSNpZiAwCiAgICAg
LyogSS9PLXBvcnQgYWRtaW4tc3BlY2lmaWVkIGFjY2VzcyBjYXBhYmlsaXRpZXMuICovCiAg
ICAgc3RydWN0IHJhbmdlc2V0CSppb3BvcnRfY2FwczsKIApAQCAtNTEsOCArMTcsNyBAQCBz
dHJ1Y3QgYXJjaF9kb21haW4KICAgICBpbnQgKnBpcnFfaXJxOwogCiAgICAgdW5zaWduZWQg
bG9uZyAqcGlycV9lb2lfbWFwOwotICAgIHVuc2lnbmVkIGxvbmcgcGlycV9lb2lfbWFwX21m
bjsKLSNlbmRpZgorCiAgICAgc3RydWN0IHBhZ2VfbGlzdF9oZWFkIHJlbG1lbV9saXN0Owog
fTsKIApAQCAtNjEsNyArMjYsNyBAQCBzdHJ1Y3QgYXJjaF92Y3B1CiAJc3RydWN0IHZjcHVf
Z3Vlc3RfY29udGV4dCBjdHg7CiB9IF9fY2FjaGVsaW5lX2FsaWduZWQ7CiAKLS8vI2RlZmlu
ZSBWQ1BVX1JFRyh2LCByZWcpCXYtPmFyY2guY3R4LnJlZworI2RlZmluZSBWQ1BVX1JFRyh2
LCByZWcpCXYtPmFyY2guY3R4LnJlZwogCiAjZGVmaW5lIHJldHVybl9yZWcodikJCSgodikt
PmFyY2guY3R4LnIwKQogCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt19-00060L-9M; Mon, 13 Feb 2012 10:20:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqvH-00044e-En
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:06:07 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329120359!15075500!1
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22947 invoked from network); 13 Feb 2012 08:06:00 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-12.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 08:06:00 -0000
Received: from epcpsbge6.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB002TDNLD9NB0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:05:37 +0900 (KST)
Message-id: <0LZB0024ZNTD9NC0@mailout2.samsung.com>
X-AuditID: cbfee610-b7b53ae000003b1c-26-4f38c44e2b56
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge6.samsung.com (EPCPMTA) with SMTP id 31.C9.15132.E44C83F4;
	Mon, 13 Feb 2012 17:05:34 +0900 (KST)
Date: Mon, 13 Feb 2012 08:05:34 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080444730@jm77.ryu
Msgkey: 20120213080444730@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080356110@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 13/14]  arm: implement miscellaneous stuffs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <5484515.70401329120331271.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgbWlzY2VsbGFuZW91cyBzdHVmZnMNCg0KIHhlbi9hcmNoL2FybS94ZW4v
YXJjaF9kb21haW4uYyB8ICA2ICsrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUyAg
ICB8ICA0ICsrLS0NCiB4ZW4vYXJjaC9hcm0veGVuL21tLmMgICAgICAgICAgfCAgMiArKw0KIHhl
bi9hcmNoL2FybS94ZW4vc2V0dXAuYyAgICAgICB8ICAxICsNCiB4ZW4vYXJjaC9hcm0veGVuL3N0
YXJ0LlMgICAgICAgfCAgOSArKysrKysrKysNCiA1IGZpbGVzIGNoYW5nZWQsIDIwIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcu
cnl1QHNhbXN1bmcuY29tPg0KDQpkaWZmIC1yIDU0ODhlNGZmNDViZSB4ZW4vYXJjaC9hcm0veGVu
L2FyY2hfZG9tYWluLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21haW4uYwlTdW4g
RmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9k
b21haW4uYwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDANCkBAIC0xOTksNiArMTk5LDEy
IEBAIHZvaWQgY29udGV4dF9zd2l0Y2goc3RydWN0IHZjcHUgKnByZXYsIHMNCiAJQVNTRVJUKHBy
ZXYgIT0gbmV4dCk7DQogCUFTU0VSVCh2Y3B1X3J1bm5hYmxlKG5leHQpKTsNCiANCisJaWYgKCFp
c19pZGxlX2RvbWFpbihuZXh0LT5kb21haW4pKSB7DQorCQlzZXRfdHRicihuZXh0LT5hcmNoLmN0
eC50dGJyMCk7DQorCQljcHVfZmx1c2hfdGxiX2FsbCgpOw0KKwkJLyogVE9ETyA6IENQVSBleGNs
dXNpdmUgbW9uaXRvciBzaG91bGQgYmUgY2xlYXJlZC4gKi8NCisJfQ0KKw0KICAgICAgICAgcHJl
diA9ICBzd2l0Y2hfdG8ocHJldiwgJnByZXYtPmFyY2guY3R4LCAmbmV4dC0+YXJjaC5jdHgpOw0K
IH0NCiANCmRpZmYgLXIgNTQ4OGU0ZmY0NWJlIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUw0K
LS0tIGEveGVuL2FyY2gvYXJtL3hlbi9jYWNoZS12Ny5TCVN1biBGZWIgMTIgMTU6MTM6MjkgMjAx
MiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9jYWNoZS12Ny5TCVN1biBGZWIgMTIgMTU6
NDg6NTcgMjAxMiArMDkwMA0KQEAgLTYxLDcgKzYxLDcgQEAgRU5UUlkoY3B1X2ZsdXNoX2NhY2hl
X2FsbCkNCiBFTlRSWShjcHVfZmx1c2hfY2FjaGVfcmFuZ2UpDQogCW1yYyAgICAgcDE1LCAxLCBy
MywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUg0KIAlhbmQgICAgIHIzLCByMywgIzcJCUAgY2FjaGUg
bGluZSBzaXplIGVuY29kaW5nDQotCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6ZSBvZmZzZXQNCisJ
bW92ICAgICByMiwgIzE2CQkJQCBzaXplIG9mZnNldA0KIAltb3YgICAgIHIyLCByMiwgbHNsIHIz
CQlAIGFjdHVhbCBjYWNoZSBsaW5lIHNpemUNCiAxOg0KIAltY3IJcDE1LCAwLCByMCwgYzcsIGMx
NCwgMQkJQCBjbGVhbiAmIGludmFsaWRhdGUgRCBsaW5lIC8gdW5pZmllZCBsaW5lDQpAQCAtNzQs
NyArNzQsNyBAQCAxOg0KIEVOVFJZKGNwdV9jbGVhbl9jYWNoZV9yYW5nZSkNCiAJbXJjICAgICBw
MTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFkIENTSURSDQogCWFuZCAgICAgcjMsIHIzLCAjNwkJ
QCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcNCi0JbW92ICAgICByMywgIzE2CQkJQCBzaXplIG9m
ZnNldA0KKwltb3YgICAgIHIyLCAjMTYJCQlAIHNpemUgb2Zmc2V0DQogCW1vdiAgICAgcjIsIHIy
LCBsc2wgcjMJCUAgYWN0dWFsIGNhY2hlIGxpbmUgc2l6ZQ0KIA0KIDE6DQpkaWZmIC1yIDU0ODhl
NGZmNDViZSB4ZW4vYXJjaC9hcm0veGVuL21tLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vbW0u
YwlTdW4gRmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4v
bW0uYwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDANCkBAIC0yNjYsNiArMjY2LDggQEAg
dW5zaWduZWQgbG9uZyBhbGxvY19wYWdlX3RhYmxlcyhsMWVfdCAqbA0KIAkJcmV0dXJuIDA7DQog
CX0NCiANCisJY3B1X2NsZWFuX2NhY2hlX3JhbmdlKHBhZ2UsIHBhZ2UgKyBQQUdFX1NJWkUpOw0K
Kw0KIAl3aXJlX3BhZ2VfdGFibGVzKGwxZSwgcGFnZSk7DQogDQogCXJldHVybiBwYWdlOw0KZGlm
ZiAtciA1NDg4ZTRmZjQ1YmUgeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jDQotLS0gYS94ZW4vYXJj
aC9hcm0veGVuL3NldHVwLmMJU3VuIEZlYiAxMiAxNToxMzoyOSAyMDEyICswOTAwDQorKysgYi94
ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMJU3VuIEZlYiAxMiAxNTo0ODo1NyAyMDEyICswOTAwDQpA
QCAtMTk1LDYgKzE5NSw3IEBAIHN0YXRpYyB2b2lkIGlkbGVfZG9tYWluX2luaXQodm9pZCkNCiAN
CiAJLyogaWRsZSB2Y3B1IGlzIGFsbG9jYXRlZCBieSBzY2hlZHVsZXJfaW5pdCgpICovDQogCXYg
PSBpZGxlX3ZjcHVbMF07DQorCVZDUFVfUkVHKHYsIHR0YnIwKSA9IGdldF90dGJyKCk7DQogDQog
CXNldF9jdXJyZW50X3ZjcHUodik7DQogfQ0KZGlmZiAtciA1NDg4ZTRmZjQ1YmUgeGVuL2FyY2gv
YXJtL3hlbi9zdGFydC5TDQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJU3VuIEZlYiAx
MiAxNToxMzoyOSAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJU3Vu
IEZlYiAxMiAxNTo0ODo1NyAyMDEyICswOTAwDQpAQCAtMTI4LDYgKzEyOCwxMSBAQCAzOg0KIAlt
Y3IJcDE1LCAwLCByNSwgYzEwLCBjMiwgMA0KIAltY3IJcDE1LCAwLCByNiwgYzEwLCBjMiwgMQ0K
IA0KKyAgICAgICAgQCBTZXR1cCBFeGNlcHRpb24gVmVjdG9yIFRhYmxlDQorICAgICAgICBsZHIg
ICAgIGlwLCA9ZXhjZXB0aW9uX3ZlY3Rvcl90YWJsZQ0KKyAgICAgICAgbWNyICAgICBWQkFSKGlw
KQ0KKw0KKw0KIAlAIFR1cm4gb24gTU1VDQogCWxkcglyMCwgPShTQ1RMUl9UUkUgfCBTQ1RMUl9T
VyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJfQyB8IFNDVExSX0EgfCBTQ1RMUl9NKQ0KIAlt
Y3IJU0NUTFIocjApDQpAQCAtMjE5LDYgKzIyNCwxMCBAQCBFTlRSWShzbGF2ZV9jcHVfc3RhcnQp
DQogCW1jcglwMTUsIDAsIHI1LCBjMTAsIGMyLCAwDQogCW1jcglwMTUsIDAsIHI2LCBjMTAsIGMy
LCAxDQogDQorICAgICAgICBAIFNldHVwIEV4Y2VwdGlvbiBWZWN0b3IgVGFibGUNCisgICAgICAg
IGxkciAgICAgaXAsID1leGNlcHRpb25fdmVjdG9yX3RhYmxlDQorICAgICAgICBtY3IgICAgIFZC
QVIoaXApDQorDQogCUAgVHVybiBvbiBNTVUNCiAJbGRyCXIwLCA9KFNDVExSX1RSRSB8IFNDVExS
X1NXIHwgU0NUTFJfWiB8IFNDVExSX0kgfCBTQ1RMUl9DIHwgU0NUTFJfQSB8IFNDVExSX00pDQog
CW1jcglTQ1RMUihyMCkNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch13.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch13.diff"


YXJtOiBpbXBsZW1lbnQgbWlzY2VsbGFuZW91cyBzdHVmZnMKCiB4ZW4vYXJjaC9hcm0veGVu
L2FyY2hfZG9tYWluLmMgfCAgNiArKysrKysKIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcu
UyAgICB8ICA0ICsrLS0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICB8ICAyICsr
CiB4ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMgICAgICAgfCAgMSArCiB4ZW4vYXJjaC9hcm0v
eGVuL3N0YXJ0LlMgICAgICAgfCAgOSArKysrKysrKysKIDUgZmlsZXMgY2hhbmdlZCwgMjAg
aW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBS
eXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciA1NDg4ZTRmZjQ1YmUgeGVuL2Fy
Y2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9k
b21haW4uYwlTdW4gRmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9hcmNoX2RvbWFpbi5jCVN1biBGZWIgMTIgMTU6NDg6NTcgMjAxMiArMDkwMApA
QCAtMTk5LDYgKzE5OSwxMiBAQCB2b2lkIGNvbnRleHRfc3dpdGNoKHN0cnVjdCB2Y3B1ICpw
cmV2LCBzCiAJQVNTRVJUKHByZXYgIT0gbmV4dCk7CiAJQVNTRVJUKHZjcHVfcnVubmFibGUo
bmV4dCkpOwogCisJaWYgKCFpc19pZGxlX2RvbWFpbihuZXh0LT5kb21haW4pKSB7CisJCXNl
dF90dGJyKG5leHQtPmFyY2guY3R4LnR0YnIwKTsKKwkJY3B1X2ZsdXNoX3RsYl9hbGwoKTsK
KwkJLyogVE9ETyA6IENQVSBleGNsdXNpdmUgbW9uaXRvciBzaG91bGQgYmUgY2xlYXJlZC4g
Ki8KKwl9CisKICAgICAgICAgcHJldiA9ICBzd2l0Y2hfdG8ocHJldiwgJnByZXYtPmFyY2gu
Y3R4LCAmbmV4dC0+YXJjaC5jdHgpOwogfQogCmRpZmYgLXIgNTQ4OGU0ZmY0NWJlIHhlbi9h
cmNoL2FybS94ZW4vY2FjaGUtdjcuUwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3
LlMJU3VuIEZlYiAxMiAxNToxMzoyOSAyMDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94
ZW4vY2FjaGUtdjcuUwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDAKQEAgLTYxLDcg
KzYxLDcgQEAgRU5UUlkoY3B1X2ZsdXNoX2NhY2hlX2FsbCkKIEVOVFJZKGNwdV9mbHVzaF9j
YWNoZV9yYW5nZSkKIAltcmMgICAgIHAxNSwgMSwgcjMsIGMwLCBjMCwgMAlAIHJlYWQgQ1NJ
RFIKIAlhbmQgICAgIHIzLCByMywgIzcJCUAgY2FjaGUgbGluZSBzaXplIGVuY29kaW5nCi0J
bW92ICAgICByMywgIzE2CQkJQCBzaXplIG9mZnNldAorCW1vdiAgICAgcjIsICMxNgkJCUAg
c2l6ZSBvZmZzZXQKIAltb3YgICAgIHIyLCByMiwgbHNsIHIzCQlAIGFjdHVhbCBjYWNoZSBs
aW5lIHNpemUKIDE6CiAJbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTQsIDEJCUAgY2xlYW4gJiBp
bnZhbGlkYXRlIEQgbGluZSAvIHVuaWZpZWQgbGluZQpAQCAtNzQsNyArNzQsNyBAQCAxOgog
RU5UUlkoY3B1X2NsZWFuX2NhY2hlX3JhbmdlKQogCW1yYyAgICAgcDE1LCAxLCByMywgYzAs
IGMwLCAwCUAgcmVhZCBDU0lEUgogCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5l
IHNpemUgZW5jb2RpbmcKLQltb3YgICAgIHIzLCAjMTYJCQlAIHNpemUgb2Zmc2V0CisJbW92
ICAgICByMiwgIzE2CQkJQCBzaXplIG9mZnNldAogCW1vdiAgICAgcjIsIHIyLCBsc2wgcjMJ
CUAgYWN0dWFsIGNhY2hlIGxpbmUgc2l6ZQogCiAxOgpkaWZmIC1yIDU0ODhlNGZmNDViZSB4
ZW4vYXJjaC9hcm0veGVuL21tLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9tbS5jCVN1biBG
ZWIgMTIgMTU6MTM6MjkgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL21tLmMJ
U3VuIEZlYiAxMiAxNTo0ODo1NyAyMDEyICswOTAwCkBAIC0yNjYsNiArMjY2LDggQEAgdW5z
aWduZWQgbG9uZyBhbGxvY19wYWdlX3RhYmxlcyhsMWVfdCAqbAogCQlyZXR1cm4gMDsKIAl9
CiAKKwljcHVfY2xlYW5fY2FjaGVfcmFuZ2UocGFnZSwgcGFnZSArIFBBR0VfU0laRSk7CisK
IAl3aXJlX3BhZ2VfdGFibGVzKGwxZSwgcGFnZSk7CiAKIAlyZXR1cm4gcGFnZTsKZGlmZiAt
ciA1NDg4ZTRmZjQ1YmUgeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCi0tLSBhL3hlbi9hcmNo
L2FybS94ZW4vc2V0dXAuYwlTdW4gRmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDAKKysrIGIv
eGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCVN1biBGZWIgMTIgMTU6NDg6NTcgMjAxMiArMDkw
MApAQCAtMTk1LDYgKzE5NSw3IEBAIHN0YXRpYyB2b2lkIGlkbGVfZG9tYWluX2luaXQodm9p
ZCkKIAogCS8qIGlkbGUgdmNwdSBpcyBhbGxvY2F0ZWQgYnkgc2NoZWR1bGVyX2luaXQoKSAq
LwogCXYgPSBpZGxlX3ZjcHVbMF07CisJVkNQVV9SRUcodiwgdHRicjApID0gZ2V0X3R0YnIo
KTsKIAogCXNldF9jdXJyZW50X3ZjcHUodik7CiB9CmRpZmYgLXIgNTQ4OGU0ZmY0NWJlIHhl
bi9hcmNoL2FybS94ZW4vc3RhcnQuUwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJ
U3VuIEZlYiAxMiAxNToxMzoyOSAyMDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4v
c3RhcnQuUwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDAKQEAgLTEyOCw2ICsxMjgs
MTEgQEAgMzoKIAltY3IJcDE1LCAwLCByNSwgYzEwLCBjMiwgMAogCW1jcglwMTUsIDAsIHI2
LCBjMTAsIGMyLCAxCiAKKyAgICAgICAgQCBTZXR1cCBFeGNlcHRpb24gVmVjdG9yIFRhYmxl
CisgICAgICAgIGxkciAgICAgaXAsID1leGNlcHRpb25fdmVjdG9yX3RhYmxlCisgICAgICAg
IG1jciAgICAgVkJBUihpcCkKKworCiAJQCBUdXJuIG9uIE1NVQogCWxkcglyMCwgPShTQ1RM
Ul9UUkUgfCBTQ1RMUl9TVyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJfQyB8IFNDVExS
X0EgfCBTQ1RMUl9NKQogCW1jcglTQ1RMUihyMCkKQEAgLTIxOSw2ICsyMjQsMTAgQEAgRU5U
Ulkoc2xhdmVfY3B1X3N0YXJ0KQogCW1jcglwMTUsIDAsIHI1LCBjMTAsIGMyLCAwCiAJbWNy
CXAxNSwgMCwgcjYsIGMxMCwgYzIsIDEKIAorICAgICAgICBAIFNldHVwIEV4Y2VwdGlvbiBW
ZWN0b3IgVGFibGUKKyAgICAgICAgbGRyICAgICBpcCwgPWV4Y2VwdGlvbl92ZWN0b3JfdGFi
bGUKKyAgICAgICAgbWNyICAgICBWQkFSKGlwKQorCiAJQCBUdXJuIG9uIE1NVQogCWxkcgly
MCwgPShTQ1RMUl9UUkUgfCBTQ1RMUl9TVyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJf
QyB8IFNDVExSX0EgfCBTQ1RMUl9NKQogCW1jcglTQ1RMUihyMCkK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt18-0005zU-Fm; Mon, 13 Feb 2012 10:20:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqtB-0003yZ-4H
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:03:57 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329120227!8950105!2
X-Originating-IP: [203.254.224.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzMgPT4gMjQzNjYx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7236 invoked from network); 13 Feb 2012 08:03:49 -0000
Received: from mailout3.samsung.com (HELO mailout3.samsung.com)
	(203.254.224.33) by server-10.tower-21.messagelabs.com with SMTP;
	13 Feb 2012 08:03:49 -0000
Received: from epcpsbge8.samsung.com (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00IVBNPYJYB0@mailout3.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:03:46 +0900 (KST)
Message-id: <0LZB00IVONQAJYB0@mailout3.samsung.com>
X-AuditID: cbfee612-b7c09ae0000024ca-52-4f38c3e22cba
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge8.samsung.com (EPCPMTA) with SMTP id 9F.C3.09418.2E3C83F4;
	Mon, 13 Feb 2012 17:03:46 +0900 (KST)
Date: Mon, 13 Feb 2012 08:03:46 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: =?euc-kr?Q?=B7=F9=C0=E7=B9=CE?= <jm77.ryu@samsung.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080232243@jm77.ryu
Msgkey: 20120213080232243@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080134863@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 11/14] arm: add files that are required to
 support the Tegra2 harmony board.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <7423992.70311329120222915.JavaMail.weblogic@epv6ml04>

YXJtOiBhZGQgZmlsZXMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgVGVncmEyIGhh
cm1vbnkgYm9hcmQuDQoNCiB4ZW4vYXJjaC9hcm0vdGVncmEvTWFrZWZpbGUgICAgICAgIHwgICAg
MyArLQ0KIHhlbi9hcmNoL2FybS90ZWdyYS9lbnRyeS5TICAgICAgICAgfCAgIDMzICsrKysrKysr
DQogeGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMgICAgICB8ICAzMzAgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vdGVncmEvdGltZXIuYyAgICAgICAgIHwgIDEx
MCArKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0veGVuL2NwdS5jICAg
ICAgICAgICAgIHwgICAgNSArDQogeGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5jICAgICAgICAgICB8
ICAgIDEgLQ0KIHhlbi9hcmNoL2FybS94ZW4vaXJxLmMgICAgICAgICAgICAgfCAgIDQ2ICsrKysr
KysrKysrLQ0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgICAgfCAgIDI0ICsrKysr
Kw0KIHhlbi9hcmNoL2FybS94ZW4vc2V0dXAuYyAgICAgICAgICAgfCAgICA2ICstDQogeGVuL2Fy
Y2gvYXJtL3hlbi90aW1lLmMgICAgICAgICAgICB8ICAgIDEgLQ0KIHhlbi9kcml2ZXJzL2NoYXIv
Y29uc29sZS5jICAgICAgICAgfCAgICA0ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2dpYy5oICAg
ICAgICAgIHwgIDEwMSArKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNt
LWFybS9pcnEuaCAgICAgICAgICB8ICAgIDMgKy0NCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3Jh
L2F2cC5oICAgIHwgIDE0NCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4
ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2NvbmZpZy5oIHwgICAgNyArLQ0KIHhlbi9pbmNsdWRl
L2FzbS1hcm0vdGVncmEvaXJxcy5oICAgfCAgIDYwICsrKysrKysrKysrKysrKw0KIHhlbi9pbmNs
dWRlL2FzbS1hcm0vdGVncmEvc21wLmggICAgfCAgICA3ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJt
L3RlZ3JhL3RlZ3JhLmggIHwgICA3NSArKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS94
ZW4vaXJxLmggICAgICAgICAgICAgIHwgICAgNiArDQogMTkgZmlsZXMgY2hhbmdlZCwgOTUyIGlu
c2VydGlvbnMoKyksIDE0IGRlbGV0aW9ucygtKQ0KDQpTaWduZWQtb2ZmLWJ5OiBKYWVtaW4gUnl1
IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCg0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gv
YXJtL3RlZ3JhL01ha2VmaWxlDQotLS0gYS94ZW4vYXJjaC9hcm0vdGVncmEvTWFrZWZpbGUJU3Vu
IEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvTWFr
ZWZpbGUJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtMSwxICsxLDIgQEANCi1v
YmoteSArPSBkdW1teS5vDQorb2JqLXkgKz0gdGltZXIubyBlbnRyeS5vIHRlZ3JhMjUwLm8NCisN
CmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9hcmNoL2FybS90ZWdyYS9lbnRyeS5TDQotLS0gL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysrIGIveGVuL2FyY2gvYXJt
L3RlZ3JhL2VudHJ5LlMJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtMCwwICsx
LDMzIEBADQorLyoNCisgKiBlbnRyeS5TDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMDggU2Ft
c3VuZyBFbGVjdHJvbmljcw0KKyAqICAgICAgICAgIEphZU1pbiBSeXUgIDxqbTc3LnJ5dUBzYW1z
dW5nLmNvbT4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9m
IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVk
IGJ5DQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCisgKg0KKyAqIFRoaXMgcHJv
Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0K
KyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdh
cnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB
UiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBt
b3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9m
IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFsb25nIHdpdGggdGhpcyBwcm9n
cmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQorICogRm91bmRhdGlvbiwg
SW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcg
IFVTQQ0KKyAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+IA0KKyNpbmxjdWRlIDxhc20v
YXJjaC9pcnFzLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0
ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1k
b21haW4uaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQorDQorCS5hbGlnbgk1DQor
DQorRU5UUlkoYXJjaF9jb250ZXh0X3N3aXRjaCkNCisJbW92CXBjLCBscg0KKw0KZGlmZiAtciA2
YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMNCi0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEv
dGVncmEyNTAuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC0wLDAgKzEsMzMw
IEBADQorLyoNCisgKiB0ZWdyYTI1MC5jDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAx
MSBTYW1zdW5nIEVsZWN0cm9uaWNzIA0KKyAqICAgICAgICAgSmFlTWluIFJ5dSAgPGptNzcucnl1
QHNhbXN1bmcuY29tPg0KKyAqDQorICogU2VjdXJlIFhlbiBvbiBBUk0gYXJjaGl0ZWN0dXJlIGRl
c2lnbmVkIGJ5IFNhbmctYnVtIFN1aCBjb25zaXN0cyBvZiANCisgKiBYZW4gb24gQVJNIGFuZCB0
aGUgYXNzb2NpYXRlZCBhY2Nlc3MgY29udHJvbC4NCisgKiANCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAq
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBv
ZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24uDQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh
dCBpdCB3aWxsIGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhv
dXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBG
SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBo
YXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisg
KiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0
d2FyZQ0KKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBC
b3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisjaW5jbHVkZSA8eGVuL2NvbmZp
Zy5oPg0KKyNpbmNsdWRlIDx4ZW4vc3BpbmxvY2suaD4NCisjaW5jbHVkZSA8eGVuL2xpYi5oPg0K
KyNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+DQorI2luY2x1ZGUgPHhlbi9lcnJuby5oPg0KKyNpbmNs
dWRlIDx4ZW4vc21wLmg+DQorI2luY2x1ZGUgPHhlbi9pcnEuaD4NCisjaW5jbHVkZSA8eGVuL21t
Lmg+DQorI2luY2x1ZGUgPGFzbS9tbXUuaD4NCisjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+DQor
I2luY2x1ZGUgPGFzbS9naWMuaD4NCisjaW5jbHVkZSA8YXNtL3JlZ3MuaD4NCisjaW5jbHVkZSA8
YXNtL2lvLmg+DQorI2luY2x1ZGUgPGFzbS9mbHVzaHRsYi5oPg0KKyNpbmNsdWRlIDxhc20vYXJj
aC90ZWdyYS5oPg0KKyNpbmNsdWRlIDxhc20vYXJjaC9pcnFzLmg+DQorDQorI2RlZmluZSBURUdS
QTI1MF9NRU1PUllfQkFTRSAgICAgMHgwMDAwMDAwMFVMDQorI2RlZmluZSBURUdSQTI1MF9NRU1P
UllfU0laRSAgICAgMHg0MDAwMDAwMFVMDQorDQorI2RlZmluZSBURUdSQTI1MF9ERVZfQkFTRSAg
ICAgICAgMHg1MDAwMDAwMFVMDQorI2RlZmluZSBURUdSQTI1MF9ERVZfU0laRSAgICAgICAgMHgw
MDMwMDAwMFVMDQorDQorREVDTEFSRV9NRU1PUllfTUFQKHRlZ3JhMjUwKSA9IHsNCisgICAgICAg
IE1FTU1BUF9FTlRSWShURUdSQTI1MF9NRU1PUllfQkFTRSwgVEVHUkEyNTBfTUVNT1JZX1NJWkUs
IE1FTU9SWV9UWVBFX1JBTSwgTDFFX1RZUEVfSFlQRVJWSVNPUiksDQorICAgICAgICBNRU1NQVBf
RU5UUlkoVEVHUkEyNTBfREVWX0JBU0UsICAgIFRFR1JBMjUwX0RFVl9TSVpFLCAgICBNRU1PUllf
VFlQRV9ERVYsIEwxRV9UWVBFX0RFVklDRSkNCit9Ow0KKw0KKy8vIFJlZ2lzdGVyIEFQQkRNQV9J
UlFfTUFTS19DTFJfMA0KKyNkZWZpbmUgQVBCRE1BX0lSUV9TVEFfQ1BVXzAJKDB4MTQpDQorI2Rl
ZmluZSBBUEJETUFfSVJRX01BU0tfU0VUXzAJKDB4MjApDQorI2RlZmluZSBBUEJETUFfSVJRX01B
U0tfQ0xSXzAJKDB4MjQpDQorDQordm9pZCAqdGVncmFfZ2ljX2NwdV9iYXNlW01BWF9QSFlTX0NQ
VVNdICA9IHswLCAwfTsNCit2b2lkICp0ZWdyYV9naWNfZGlzdF9iYXNlID0gMDsNCisNCitzdHJ1
Y3QgdGVncmFfaXJxX2N0cmwgew0KKwl1bnNpZ25lZCBpbnQgaXJxX3N0YXJ0Ow0KKwl2b2lkICAq
cmVnOw0KK307DQorDQorc3RhdGljIHN0cnVjdCB0ZWdyYV9pcnFfY3RybCB0ZWdyYV9pcnFfY3Ry
bFsoSU5UX1NZU19OUiArIElOVF9TWVNfU1ogLSAxKSAvIElOVF9TWVNfU1pdOw0KKw0KKyNkZWZp
bmUgZ2ljX2lycShpcnEpCShpcnEpDQorDQorc3RhdGljIHZvaWQgdGVncmFfbWFzayhzdHJ1Y3Qg
aXJxX2Rlc2MgKmRlc2MpDQorew0KKwlzdHJ1Y3QgdGVncmFfaXJxX2N0cmwgKmNoaXA7DQorCXVu
c2lnbmVkIGludCBpcnEgPSBkZXNjX3RvX2lycShkZXNjKTsNCisJdW5zaWduZWQgaW50IG1hc2sg
PSAxIDw8IChpcnEgJSAzMik7DQorDQorCW1taW9fd3JpdGVsKG1hc2ssIHRlZ3JhX2dpY19kaXN0
X2Jhc2UgKyBfSUNESUNFUiArIChnaWNfaXJxKGlycSkgLyAzMikgKiA0KTsNCisNCisJaXJxIC09
IElOVF9QUklfQkFTRTsNCisJY2hpcCA9ICZ0ZWdyYV9pcnFfY3RybFtpcnEgLyBJTlRfU1lTX1Na
XTsNCisJbW1pb193cml0ZWwoMSA8PCAoaXJxICYgMzEpLCBjaGlwLT5yZWcgKyBJQ1RMUl9DUFVf
SUVSX0NMUl8wKTsNCit9DQorDQorc3RhdGljIHZvaWQgdGVncmFfdW5tYXNrKHN0cnVjdCBpcnFf
ZGVzYyAqZGVzYykNCit7DQorCXN0cnVjdCB0ZWdyYV9pcnFfY3RybCAqY2hpcDsNCisJdW5zaWdu
ZWQgaW50IGlycSA9IGRlc2NfdG9faXJxKGRlc2MpOw0KKwl1bnNpZ25lZCBpbnQgbWFzayA9IDEg
PDwgKGlycSAlIDMyKTsNCisNCisJbW1pb193cml0ZWwobWFzaywgdGVncmFfZ2ljX2Rpc3RfYmFz
ZSArIF9JQ0RJU0VSICsgKGdpY19pcnEoaXJxKSAvIDMyKSAqIDQpOw0KKw0KKwlpcnEgLT0gSU5U
X1BSSV9CQVNFOw0KKwljaGlwID0gJnRlZ3JhX2lycV9jdHJsW2lycSAvIElOVF9TWVNfU1pdOw0K
KwltbWlvX3dyaXRlbCgxIDw8IChpcnEgJiAzMSksIGNoaXAtPnJlZyArIElDVExSX0NQVV9JRVJf
U0VUXzApOw0KK30NCisNCitzdGF0aWMgdm9pZCB0ZWdyYV9hY2soc3RydWN0IGlycV9kZXNjICpk
ZXNjKQ0KK3sNCisJdW5zaWduZWQgaW50IGlycSA9IGRlc2NfdG9faXJxKGRlc2MpOw0KKwl1bnNp
Z25lZCBpbnQgbWFzayA9IDEgPDwgKGlycSAlIDMyKTsNCisJdW5zaWduZWQgaW50IGNwdSA9IHNt
cF9wcm9jZXNzb3JfaWQoKTsNCisNCisJdGVncmFfbWFzayhkZXNjKTsNCisNCisgICAgICAgIG1t
aW9fd3JpdGVsKG1hc2ssIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNESUNFUiArIChnaWNfaXJx
KGlycSkgLyAzMikgKiA0KTsNCisgICAgICAgIG1taW9fd3JpdGVsKGdpY19pcnEoaXJxKSwgdGVn
cmFfZ2ljX2NwdV9iYXNlW2NwdV0gKyBfSUNDRU9JUik7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIHRl
Z3JhX2VuZChzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpDQorew0KKwl0ZWdyYV91bm1hc2soZGVzYyk7
DQorfQ0KKw0KK2h3X2lycV9jb250cm9sbGVyIHRlZ3JhX2lycV9jb250cm9sbGVyID0gew0KKwku
dHlwZW5hbWUgPSAibGV2ZWwiLA0KKwkuc3RhcnR1cCAgPSB0ZWdyYV91bm1hc2ssDQorCS5zaHV0
ZG93biA9IHRlZ3JhX21hc2ssDQorCS5lbmFibGUJICA9IHRlZ3JhX3VubWFzaywNCisJLmRpc2Fi
bGUgID0gdGVncmFfbWFzaywNCisJLmFjawkgID0gdGVncmFfYWNrLA0KKwkuZW5kCSAgPSB0ZWdy
YV9lbmQsDQorfTsNCisNCitzdGF0aWMgdm9pZCB0ZWdyYTI1MF9pcnFfaW5pdCgpDQorew0KKwl1
bnNpZ25lZCBpbnQgbWF4X2lycSwgaTsNCisJdW5zaWduZWQgaW50IGNwdSA9IHNtcF9wcm9jZXNz
b3JfaWQoKTsNCisJdW5zaWduZWQgbG9uZyBjcHVtYXNrID0gMSA8PCBjcHU7DQorDQorCWZvciAo
aSA9IDA7IGkgPCBBUlJBWV9TSVpFKHRlZ3JhX2lycV9jdHJsKTsgaSsrKSB7DQorCQl0ZWdyYV9p
cnFfY3RybFtpXS5pcnFfc3RhcnQgPSBJTlRfUFJJX0JBU0UgKyBJTlRfU1lTX1NaICogaTsNCisJ
CXRlZ3JhX2lycV9jdHJsW2ldLnJlZyA9IElPX0FERFJFU1MoSU5UX1BQSV9BRERSRVNTKGkpKTsN
CisJCW1taW9fd3JpdGVsKDB4RkZGRkZGRkYsIHRlZ3JhX2lycV9jdHJsW2ldLnJlZyArIElDVExS
X0NQVV9JRVJfQ0xSXzApOw0KKwkJbW1pb193cml0ZWwoMHgwMDAwMDAwMCwgdGVncmFfaXJxX2N0
cmxbaV0ucmVnICsgSUNUTFJfQ1BVX0lFUF9DTEFTU18wKTsNCisJfQ0KKw0KKwlmb3IgKGkgPSBJ
TlRfUFJJX0JBU0U7IGkgPCBJTlRfR1BJT19CQVNFOyBpKyspIHsNCisJCWlycV9kZXNjW2ldLmhh
bmRsZXIgPSAmdGVncmFfaXJxX2NvbnRyb2xsZXI7DQorCX0NCisNCisJY3B1bWFzayB8PSBjcHVt
YXNrIDw8IDg7DQorCWNwdW1hc2sgfD0gY3B1bWFzayA8PCAxNjsNCisNCisJdGVncmFfZ2ljX2Rp
c3RfYmFzZSA9IElPX0FERFJFU1MoVEVHUkFfQVJNX0lOVF9ESVNUX0JBU0UpOw0KKwl0ZWdyYV9n
aWNfY3B1X2Jhc2VbY3B1XSA9IElPX0FERFJFU1MoVEVHUkFfR0lDX1BST0NfSUZfQkFTRSk7DQor
DQorCW1taW9fd3JpdGVsKDAsIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNERENSKTsNCisJDQor
ICAgICAgICAvKg0KKyAgICAgICAgICogRmluZCBvdXQgaG93IG1hbnkgaW50ZXJydXB0cyBhcmUg
c3VwcG9ydGVkLg0KKyAgICAgICAgICovDQorICAgICAgICBtYXhfaXJxID0gbW1pb19yZWFkbCh0
ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDVFIpICYgMHgxZjsNCisgICAgICAgIG1heF9pcnEg
PSAobWF4X2lycSArIDEpICogMzI7DQorDQorICAgICAgICAvKg0KKyAgICAgICAgICogVGhlIEdJ
QyBvbmx5IHN1cHBvcnRzIHVwIHRvIDEwMjAgaW50ZXJydXB0IHNvdXJjZXMuDQorICAgICAgICAg
KiBMaW1pdCB0aGlzIHRvIGVpdGhlciB0aGUgYXJjaGl0ZWN0ZWQgbWF4aW11bSwgb3IgdGhlDQor
ICAgICAgICAgKiBwbGF0Zm9ybSBtYXhpbXVtLg0KKyAgICAgICAgICovDQorICAgICAgICBpZiAo
bWF4X2lycSA+IG1heCgxMDIwLCBOUl9JUlFTKSkNCisgICAgICAgICAgICAgICAgbWF4X2lycSA9
IG1heCgxMDIwLCBOUl9JUlFTKTsNCisNCisgICAgICAgIC8qDQorICAgICAgICAgKiBTZXQgYWxs
IGdsb2JhbCBpbnRlcnJ1cHRzIHRvIGJlIGxldmVsIHRyaWdnZXJlZCwgYWN0aXZlIGxvdy4NCisg
ICAgICAgICAqLw0KKyAgICAgICAgZm9yIChpID0gMzI7IGkgPCBtYXhfaXJxOyBpICs9IDE2KQ0K
KyAgICAgICAgICAgICAgICBtbWlvX3dyaXRlbCgwLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lD
RElDRlIgKyBpICogNCAvIDE2KTsNCisNCisgICAgICAgIC8qDQorICAgICAgICAgKiBTZXQgYWxs
IGdsb2JhbCBpbnRlcnJ1cHRzIHRvIHRoaXMgQ1BVIG9ubHkuDQorICAgICAgICAgKi8NCisgICAg
ICAgIGZvciAoaSA9IDMyOyBpIDwgbWF4X2lycTsgaSArPSA0KQ0KKyAgICAgICAgICAgICAgICBt
bWlvX3dyaXRlbChjcHVtYXNrLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElQVFIgKyBpICog
NCAvIDQpOw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFNldCBwcmlvcml0eSBvbiBhbGwgaW50
ZXJydXB0cy4NCisgICAgICAgICAqLw0KKyAgICAgICAgZm9yIChpID0gMDsgaSA8IG1heF9pcnE7
IGkgKz0gNCkNCisgICAgICAgICAgICAgICAgbW1pb193cml0ZWwoMHhhMGEwYTBhMCwgdGVncmFf
Z2ljX2Rpc3RfYmFzZSArIF9JQ0RJUFIgKyBpICogNCAvIDQpOw0KKw0KKyAgICAgICAgLyoNCisg
ICAgICAgICAqIERpc2FibGUgYWxsIGludGVycnVwdHMuDQorICAgICAgICAgKi8NCisgICAgICAg
IGZvciAoaSA9IDA7IGkgPCBtYXhfaXJxOyBpICs9IDMyKQ0KKyAgICAgICAgICAgICAgICBtbWlv
X3dyaXRlbCgweGZmZmZmZmZmLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDRVIgKyBpICog
NCAvIDMyKTsNCisNCisgICAgICAgIG1taW9fd3JpdGVsKDEsIHRlZ3JhX2dpY19kaXN0X2Jhc2Ug
KyBfSUNERENSKTsNCisNCisgICAgICAgIG1taW9fd3JpdGVsKDB4ZjAsIHRlZ3JhX2dpY19jcHVf
YmFzZVtjcHVdICsgX0lDQ1BNUik7DQorICAgICAgICBtbWlvX3dyaXRlbCgxLCB0ZWdyYV9naWNf
Y3B1X2Jhc2VbY3B1XSArIF9JQ0NJQ1IpOw0KKw0KKw0KK30NCisNCisjZGVmaW5lIENMS19SU1Rf
Q09OVFJPTExFUl9SU1RfQ1BVX0NNUExYX0NMUl8wICAoMHgzNDQpDQorI2RlZmluZSBDTEtfUlNU
X0NPTlRST0xMRVJfQ0xLX0NQVV9DTVBMWF8wICAgICAgKDB4NGMpDQorI2RlZmluZSBDUFVfQ0xL
X1NUT1AoY3B1KSAgICAgICAgICAgICAgICAgICAgICAgKDB4MTw8KDgrY3B1KSkNCisjZGVmaW5l
IENQVV9SRVNFVChjcHUpICAgICAgICAgICAgICAgICAgICAgICAgICAoMHgxMDExdWw8PChjcHUp
KQ0KKw0KKyNkZWZpbmUgRVZQX0NQVV9SRVNFVF9WRUNUT1JfMCAgICAgICAgICAJKDB4MTAwKQ0K
KyNkZWZpbmUgRkxPV19DVFJMX0hBTFRfQ1BVeF9FVkVOVFMoY3B1KSAJKChjcHUpID8gKChjcHUg
LSAxKSAqIDB4OCArIDB4MTQpIDogMHgwKQ0KKw0KKw0KK3ZvbGF0aWxlIGludCB0ZWdyYTI1MF9j
b3JlX21hcCA9IDE7DQorDQorYXNtKA0KKyIudHlwZSB0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQs
ICNmdW5jdGlvbglcbiINCisiLmdsb2JhbCB0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQJCVxuIg0K
KyJ0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQ6CQkJXG4iDQorIgltc3IJY3Bzcl9jLCAjMHhEMwkJ
CVxuIg0KKyIJbW92CXIwLCAjMAkJCQlcbiINCisiCW1jcglwMTUsIDIsIHIwLCBjMCwgYzAsIDAJ
CVxuIg0KKyIJbXJjCXAxNSwgMSwgcjAsIGMwLCBjMCwgMAkJXG4iDQorIglsZHIJcjEsID0weDdG
RkYJCQlcbiINCisiCWFuZAlyMiwgcjEsIHIwLCBsc3IgIzEzCQlcbiINCisiCWxkcglyMSwgPTB4
M0ZGCQkJXG4iDQorIglhbmQJcjMsIHIxLCByMCwgbHNyICMzCQlcbiINCisiCWFkZAlyMiwgcjIs
ICMxCQkJXG4iDQorIglhbmQJcjAsIHIwLCAjMHgwNwkJCVxuIg0KKyIJYWRkCXIwLCByMCwgIzQJ
CQlcbiINCisiCWNseglyMSwgcjMJCQkJXG4iDQorIglhZGQJcjQsIHIzLCAjMQkJCVxuIg0KKyIx
OglzdWIJcjIsIHIyLCAjMQkJCVxuIg0KKyIJbW92CXIzLCByNAkJCQlcbiINCisiMjoJc3Vicwly
MywgcjMsICMxCQkJXG4iDQorIgltb3YJcjUsIHIzLCBsc2wgcjEJCQlcbiINCisiCW1vdglyNiwg
cjIsIGxzbCByMAkJCVxuIg0KKyIJb3JyCXI1LCByNSwgcjYJCQlcbiINCisiCW1jcglwMTUsIDAs
IHI1LCBjNywgYzYsIDIJCVxuIg0KKyIJYmd0CTJiCQkJCVxuIg0KKyIJY21wCXIyLCAjMAkJCQlc
biINCisiCWJndAkxYgkJCQlcbiINCisiCWRzYgkJCQkJXG4iDQorIglpc2IJCQkJCVxuIg0KKyIJ
bXJjCXAxNSwgMCwgcjAsIGMwLCBjMCwgNQkJXG4iDQorIglhbmQJcjAsIHIwLCAjMTUJCQlcbiIN
CisiCWFkcglyNCwgMWYJCQkJXG4iDQorIglsZG1pYQlyNCwge3I1LCByNn0JCQlcbiINCisiCXN1
YglyNCwgcjQsIHI1CQkJXG4iDQorIglhZGQJcjYsIHI2LCByNAkJCVxuIg0KKyIJbW92CXIxLCAj
MQkJCQlcbiINCisiCWxzbAlyMSwgcjEsIHIwCQkJXG4iDQorInNwaW46CWxkcglyNywgW3I2XQkJ
CVxuIg0KKyIJdHN0CXI3LCByMQkJCQlcbiINCisiCWJlcQlzcGluCQkJCVxuIg0KKyIJYglzbGF2
ZV9jcHVfc3RhcnQJCQlcbiINCisiMToJLmxvbmcJLgkJCQlcbiINCisiCS5sb25nCXRlZ3JhMjUw
X2NvcmVfbWFwCQlcbiINCispOw0KKw0KK2ludCB3YWtldXBfY3B1KHVuc2lnbmVkIGludCBjcHUp
DQorew0KKwl0ZWdyYTI1MF9jb3JlX21hcCB8PSAxIDw8ICBjcHU7DQorDQorCWNwdV9mbHVzaF9j
YWNoZV9hbGwoKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK2V4dGVybiB2b2lkIHRlZ3JhMjUw
X3NsYXZlX2NwdV9zdGFydCh2b2lkKTsNCisNCitzdGF0aWMgdm9pZCB0ZWdyYTI1MF9ldnBfaW5p
dCh2b2lkKQ0KK3sNCisJdW5zaWduZWQgbG9uZyByLCBvcmcsIGxvb3AsIGN0cmw7DQorDQorCS8q
IEluaXRpYWxpemUgU25vb3AgQ29udHJvbCBVbml0ICovDQorCWN0cmwgPSBtbWlvX3JlYWRsKElP
X0FERFJFU1MoVEVHUkFfU0NVX0JBU0UpICsgMHgwKTsNCisJY3RybCB8PSAxOw0KKwltbWlvX3dy
aXRlbChjdHJsLCBJT19BRERSRVNTKFRFR1JBX1NDVV9CQVNFKSArIDB4MCk7DQorDQorCW9yZyA9
IG1taW9fcmVhZGwoSU9fQUREUkVTUyhURUdSQV9FWENFUFRJT05fVkVDVE9SU19CQVNFKSArIEVW
UF9DUFVfUkVTRVRfVkVDVE9SXzApOw0KKw0KKwkvKiBTZXQgYm9vdCBlbnRyeSAqLw0KKwltbWlv
X3dyaXRlbChfX3BhKHRlZ3JhMjUwX3NsYXZlX2NwdV9zdGFydCksIElPX0FERFJFU1MoVEVHUkFf
RVhDRVBUSU9OX1ZFQ1RPUlNfQkFTRSkgKyBFVlBfQ1BVX1JFU0VUX1ZFQ1RPUl8wKTsNCisNCisJ
ZHNiKCk7DQorCWlzYigpOw0KKw0KKwkvKiBIYWx0IENQVSAqLw0KKwltbWlvX3dyaXRlbCgwLCBJ
T19BRERSRVNTKFRFR1JBX0ZMT1dfQ1RSTF9CQVNFKSArIEZMT1dfQ1RSTF9IQUxUX0NQVXhfRVZF
TlRTKDEpKTsNCisNCisJZHNiKCk7DQorCWlzYigpOw0KKw0KKwkvKiBDUFUgQ2xvY2sgU3RvcCAq
Lw0KKwlyID0gbW1pb19yZWFkbChJT19BRERSRVNTKFRFR1JBX0NMS19SRVNFVF9CQVNFKSArIENM
S19SU1RfQ09OVFJPTExFUl9DTEtfQ1BVX0NNUExYXzApOw0KKwlyICY9IH5DUFVfQ0xLX1NUT1Ao
MSk7DQorCW1taW9fd3JpdGVsKHIsIElPX0FERFJFU1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpICsg
Q0xLX1JTVF9DT05UUk9MTEVSX0NMS19DUFVfQ01QTFhfMCk7DQorDQorCWRzYigpOw0KKwlpc2Io
KTsNCisNCisJLyogUmVzdGFydCBTbGF2ZSBDUFUgKi8NCisJbW1pb193cml0ZWwoQ1BVX1JFU0VU
KDEpLCBJT19BRERSRVNTKFRFR1JBX0NMS19SRVNFVF9CQVNFKSArIENMS19SU1RfQ09OVFJPTExF
Ul9SU1RfQ1BVX0NNUExYX0NMUl8wKTsNCisNCisJZHNiKCk7DQorCWlzYigpOw0KKw0KKyAgICAg
ICAgLyogV2FpdCB1dGlsIHRoZSBwb3dlciB1bml0IGlzIGluIHN0YWJsZSAqLw0KKyAgICAgICAg
bG9vcCA9IDEwMDAwOw0KKyAgICAgICAgd2hpbGUoKC0tbG9vcCkgPiAwICk7DQorfQ0KKw0KK3Zv
aWQgdGVncmEyNTBfaW9yZW1hcCh2b2lkKQ0KK3sNCisJbWFwX3BhZ2VzX3RvX3hlbihJT19BRERS
RVNTKFRFR1JBX0FSTV9DUFVfQkFTRSksDQorCQlURUdSQV9BUk1fQ1BVX0JBU0UgPj4gUEFHRV9T
SElGVCwgMHgxMDAwMDAgPj4gUEFHRV9TSElGVCwNCisJCUwxRV9UWVBFX0RFVklDRSk7DQorDQor
CW1hcF9wYWdlc190b194ZW4oSU9fQUREUkVTUyhURUdSQV9QUFNCX0RFVklDRV9CQVNFKSwNCisJ
CVRFR1JBX1BQU0JfREVWSUNFX0JBU0UgPj4gUEFHRV9TSElGVCwgMHgxMDAwMDAgPj4gUEFHRV9T
SElGVCwgDQorCQlMMUVfVFlQRV9ERVZJQ0UpOw0KKw0KKwltYXBfcGFnZXNfdG9feGVuKElPX0FE
RFJFU1MoVEVHUkFfQVBCX0RFVklDRV9CQVNFKSwNCisJCVRFR1JBX0FQQl9ERVZJQ0VfQkFTRSA+
PiBQQUdFX1NISUZULCAweDEwMDAwMCA+PiBQQUdFX1NISUZULA0KKwkJTDFFX1RZUEVfREVWSUNF
KTsNCit9DQorDQoraW50IG1hY2hpbmVfc2V0dXAodm9pZCkNCit7DQorCWNwdV90b3BvbG9neV9p
bml0KDIpOw0KKw0KKwl0ZWdyYTI1MF9pb3JlbWFwKCk7DQorDQorCXRlZ3JhMjUwX2V2cF9pbml0
KCk7DQorDQorCXRlZ3JhMjUwX2lycV9pbml0KCk7DQorDQorCXRlZ3JhMjUwX3RpbWVyX2luaXQo
KTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gv
YXJtL3RlZ3JhL3RpbWVyLmMNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvdGltZXIuYwlTdW4gRmViIDEyIDE1OjA0
OjA2IDIwMTIgKzA5MDANCkBAIC0wLDAgKzEsMTEwIEBADQorLyoNCisgKiBhcmNoL2FybS9tYWNo
LXRlZ3JhL3RpbWVyLmMNCisgKg0KKyAqIFRpbWVyIGFuZCBjbG9jayBldmVudCBzdXBwb3J0IGZv
ciBOVklESUEgVGVncmEgU29Dcw0KKyAqDQorICogQ29weXJpZ2h0IChjKSAyMDA4LTIwMDksIE5W
SURJQSBDb3Jwb3JhdGlvbi4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkN
CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRo
ZSBMaWNlbnNlLCBvcg0KKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uDQor
ICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3
aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZl
biB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3INCisgKiBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yDQorICogbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJl
Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYWxvbmcNCisg
KiB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uLCBJbmMuLA0KKyAqIDUxIEZyYW5rbGluIFN0cmVldCwgRmlmdGggRmxvb3IsIEJv
c3RvbiwgTUEgIDAyMTEwLTEzMDEsIFVTQS4NCisgKi8NCisNCisjaW5jbHVkZSA8eGVuL3NjaGVk
Lmg+DQorI2luY2x1ZGUgPHhlbi9pcnEuaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisjaW5j
bHVkZSA8eGVuL3NvZnRpcnEuaD4NCisjaW5jbHVkZSA8eGVuL3NwaW5sb2NrLmg+DQorI2luY2x1
ZGUgPGFzbS90aW1lLmg+DQorI2luY2x1ZGUgPGFzbS9hcmNoL2lycXMuaD4NCisjaW5jbHVkZSA8
YXNtL2FyY2gvdGVncmEuaD4NCisNCisNCisjZGVmaW5lIENMS19SU1RfQ09OVFJPTExFUl9PU0Nf
Q1RSTF8wCTB4NTANCisNCisjZGVmaW5lIFRJTUVSMV9PRkZTCQkJMHgwMCAgLyogcmVzZXJ2ZWQg
Zm9yIEFWUCAqLw0KKyNkZWZpbmUgVElNRVIyX09GRlMJCQkweDA4ICAvKiByZXNlcnZlZCBmb3Ig
QVZQICovDQorI2RlZmluZSBUSU1FUjNfT0ZGUwkJCTB4NTAgIC8qIHVzZWQgYXMgT1MgQ1BVIGV2
ZW50IHRpbWVyICovDQorI2RlZmluZSBUSU1FUjRfT0ZGUwkJCTB4NTggIC8qIHJlc2VydmVkIGFz
IExQMiB3YWtldXAgdHJpZ2dlciAqLw0KKw0KKyNkZWZpbmUgVElNRVJfVE1SX1BUVl8wCQkJMHgw
DQorI2RlZmluZSBUSU1FUl9UTVJfUENSXzAJCQkweDQNCisNCisjZGVmaW5lIFRJTUVSVVNfT0ZG
UwkJCTB4MTANCisjZGVmaW5lIFRJTUVSVVNfQ05UUl8xVVNfMAkJMHgwDQorI2RlZmluZSBUSU1F
UlVTX1VTRUNfQ0ZHXzAJCTB4NA0KKw0KKyNkZWZpbmUgTlNFQ19QRVJfU0VDCQkJMTAwMDAwMDAw
MEwNCisNCit2b2lkIHRlZ3JhX2Nsb2NrZXZlbnRfaW50ZXJydXB0KGludCBpcnEsIHZvaWQgKmRl
dl9pZCwgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQorew0KKyAgICAgICAgbW1pb193cml0
ZWwoMSA8PCAzMCwgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBUSU1FUjNfT0ZGUykgKyBU
SU1FUl9UTVJfUENSXzApOw0KK30NCisNCitzdGF0aWMgc3RydWN0IGlycWFjdGlvbiB0ZWdyYV9j
bG9ja2V2ZW50X2lycSA9IHsNCisgICAgICAgIC5uYW1lICAgICAgICAgICA9ICJUaW1lcl9ldmVu
dCIsDQorICAgICAgICAuaGFuZGxlciAgICAgICAgPSB0ZWdyYV9jbG9ja2V2ZW50X2ludGVycnVw
dCwNCit9Ow0KKw0KK3ZvaWQgdGVncmFfbHAyd2FrZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAq
ZGV2X2lkLCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCit7DQorICAgICAgICBtbWlvX3dy
aXRlbCgxPDwzMCwgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBUSU1FUjRfT0ZGUykgKyBU
SU1FUl9UTVJfUENSXzApOw0KK30NCisNCitzdGF0aWMgc3RydWN0IGlycWFjdGlvbiB0ZWdyYV9s
cDJ3YWtlX2lycSA9IHsNCisgICAgICAgIC5uYW1lICAgICAgICAgICA9ICJ0aW1lcl9scDJ3YWtl
IiwNCisgICAgICAgIC5oYW5kbGVyICAgICAgICA9IHRlZ3JhX2xwMndha2VfaW50ZXJydXB0LA0K
K307DQorDQorc3RhdGljIHVuc2lnbmVkIGxvbmcgbWVhc3VyZV9pbnB1dF9mcmVxKHVuc2lnbmVk
IGludCAqbSwgdW5zaWduZWQgaW50ICpuKQ0KK3sNCisJdm9pZCAqY2xrX3JzdCA9IElPX0FERFJF
U1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpOw0KKwl1bnNpZ25lZCBsb25nIG9zYyA9IG1taW9fcmVh
ZGwoY2xrX3JzdCArIENMS19SU1RfQ09OVFJPTExFUl9PU0NfQ1RSTF8wKTsNCisJb3NjID4+PSAz
MDsNCisNCisJc3dpdGNoIChvc2MpIHsNCisJCWNhc2UgMDogaWYgKG0gJiYgbikgeyAqbT0xOyAq
bj0xMzsgfSByZXR1cm4gMTMwMDA7DQorCQljYXNlIDE6IGlmIChtICYmIG4pIHsgKm09NTsgKm49
OTY7IH0gcmV0dXJuIDE5MjAwOw0KKwkJY2FzZSAyOiBpZiAobSAmJiBuKSB7ICptPTE7ICpuPTEy
OyB9IHJldHVybiAxMjAwMDsNCisJCWNhc2UgMzogaWYgKG0gJiYgbikgeyAqbT0xOyAqbj0yNjsg
fSByZXR1cm4gMjYwMDA7DQorCX0NCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK3ZvaWQgdGVncmEy
NTBfdGltZXJfaW5pdCh2b2lkKQ0KK3sNCisgICAgICAgIHZvaWQgKnRtcjsNCisgICAgICAgIHVu
c2lnbmVkIGludCBtLCBuOw0KKyAgICAgICAgdW5zaWduZWQgbG9uZyB2YWw7DQorICAgICAgICB1
MzIgcmVnOw0KKw0KKyAgICAgICAgdG1yID0gSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBU
SU1FUlVTX09GRlMpOw0KKyAgICAgICAgdmFsID0gbWVhc3VyZV9pbnB1dF9mcmVxKCZtLCAmbik7
DQorDQorICAgICAgICB2YWwgPSAoKG0tMSk8PDgpIHwgKG4tMSk7DQorDQorICAgICAgICBtbWlv
X3dyaXRlbCh2YWwsIHRtciArIFRJTUVSVVNfVVNFQ19DRkdfMCk7DQorICAgICAgICBtbWlvX3dy
aXRlbCgwLCBJT19BRERSRVNTKFRFR1JBX1RNUjFfQkFTRSArIFRJTUVSM19PRkZTKSAgKyBUSU1F
Ul9UTVJfUFRWXzApOw0KKw0KKyAgICAgICAgcmVnID0gMHhjMDAwMjcwZjsNCisgICAgICAgIG1t
aW9fd3JpdGVsKHJlZywgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBUSU1FUjNfT0ZGUykg
KyBUSU1FUl9UTVJfUFRWXzApOw0KKw0KKyAgICAgICAgaWYgKHNldHVwX2lycShJTlRfVE1SMywg
JnRlZ3JhX2Nsb2NrZXZlbnRfaXJxKSkgew0KKyAgICAgICAgICAgICAgICBCVUcoKTsNCisgICAg
ICAgIH0NCisgICAgICAgIGlmIChzZXR1cF9pcnEoSU5UX1RNUjQsICZ0ZWdyYV9scDJ3YWtlX2ly
cSkpIHsNCisgICAgICAgICAgICAgICAgQlVHKCk7DQorICAgICAgICB9DQorfQ0KKw0KZGlmZiAt
ciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3hlbi9jcHUuYw0KLS0tIGEveGVuL2FyY2gvYXJt
L3hlbi9jcHUuYwlTdW4gRmViIDEyIDEyOjI0OjIxIDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNo
L2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtNTMsNiAr
NTMsMTEgQEAgaW50IF9fY3B1X3VwKHVuc2lnbmVkIGludCBjcHUpDQogew0KIAlpbnQgcmV0ID0g
MDsNCiANCisJcmV0ID0gd2FrZXVwX2NwdShjcHUpOw0KKwlpZiAoIXJldCkgew0KKwkJcmV0dXJu
IC1FSU5WQUw7DQorCX0NCisNCiAJd2hpbGUoIWNwdV9vbmxpbmUoY3B1KSkgew0KIAkJY3B1X3Jl
bGF4KCk7DQogCQlwcm9jZXNzX3BlbmRpbmdfc29mdGlycXMoKTsNCmRpZmYgLXIgNmFmOGE4OWM5
OWNkIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9mYXVs
dC5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9mYXVsdC5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTMzLDcgKzMzLDYg
QEANCiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPg0KICNpbmNsdWRlIDxhc20vZ3Vlc3RfYWNj
ZXNzLmg+DQogI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCi0jaW5jbHVkZSA8YXNtL21lbW9yeS5o
Pg0KIA0KIGFzbWxpbmthZ2Ugdm9pZCBfX2RpdjAodm9pZCkNCiB7DQpkaWZmIC1yIDZhZjhhODlj
OTljZCB4ZW4vYXJjaC9hcm0veGVuL2lycS5jDQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2lycS5j
CVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9p
cnEuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC0zOCw5ICszOCwyNyBAQCBo
d19pcnFfY29udHJvbGxlciBub19pcnFfdHlwZSA9IHsNCiAJLnNodXRkb3duID0gaXJxX3NodXRk
b3duX25vbmUsDQogCS5lbmFibGUgICA9IGlycV9lbmFibGVfbm9uZSwNCiAJLmRpc2FibGUgID0g
aXJxX2Rpc2FibGVfbm9uZSwNCisJLmVuZAkgID0gaXJxX2VuZF9ub25lLA0KKwkuYWNrCSAgPSBp
cnFfYWNrX25vbmUsDQogfTsNCiANCi1zdHJ1Y3QgaXJxX2Rlc2MgKmlycV9kZXNjOw0KKy8vc3Ry
dWN0IGlycV9kZXNjICppcnFfZGVzYzsNCisNCitpcnFfZGVzY190IGlycV9kZXNjW05SX0lSUVNd
ID0gew0KKyAgICAgICAgWzAgLi4uIE5SX0lSUVMgLSAxXSA9IHsNCisgICAgICAgICAgICAgICAg
LnN0YXR1cyA9IElSUV9ESVNBQkxFRCwNCisgICAgICAgICAgICAgICAgLmhhbmRsZXIgPSAmbm9f
aXJxX3R5cGUsDQorICAgICAgICAgICAgICAgIC5hY3Rpb24gPSBOVUxMLA0KKyAgICAgICAgICAg
ICAgICAubG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRA0KKyAgICAgICAgfQ0KK307DQorDQorc3Ry
dWN0IGlycV9jZmcgaXJxX2NmZ1tOUl9JUlFTXSA9IHsNCisgICAgICAgIFswIC4uLiBOUl9JUlFT
IC0gMV0gPXsNCisgICAgICAgICAgICAgICAgLmlycSA9IDANCisgICAgICAgIH0NCit9Ow0KKw0K
IA0KIGludCBwaXJxX2d1ZXN0X3VubWFzayhzdHJ1Y3QgZG9tYWluICpkKQ0KIHsNCkBAIC03NSw2
ICs5MywzMiBAQCBzdHJ1Y3QgcGlycSAqYWxsb2NfcGlycV9zdHJ1Y3Qoc3RydWN0IGRvDQogCXJl
dHVybiBOVUxMOw0KIH0NCiANCitpbnQgc2V0dXBfaXJxKHVuc2lnbmVkIGludCBpcnEsIHN0cnVj
dCBpcnFhY3Rpb24gKm5ldykNCit7DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQorCXN0cnVjdCBp
cnFfZGVzYyAqZGVzYzsNCisNCisJaWYoaXJxID49IE5SX0lSUVMpIHsNCisJCXByaW50aygiQkFE
IElSUSA9ICVkXG4iLCBpcnEpOw0KKwl9DQorDQorCWRlc2MgPSBpcnFfdG9fZGVzYyhpcnEpOw0K
Kw0KKwlzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3MpOw0KKwlkZXNjLT5hY3Rp
b24gPSBuZXc7DQorCWlmIChkZXNjLT5oYW5kbGVyKSB7DQorCQlpZiAoZGVzYy0+aGFuZGxlci0+
c3RhcnR1cCkgew0KKwkJCWRlc2MtPmhhbmRsZXItPnN0YXJ0dXAoZGVzYyk7DQorCQl9IGVsc2Ug
aWYoZGVzYy0+aGFuZGxlci0+ZW5hYmxlKSB7DQorCQkJZGVzYy0+aGFuZGxlci0+ZW5hYmxlKGRl
c2MpOw0KKwkJfQ0KKwl9DQorDQorCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ss
IGZsYWdzKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KIGludCBhcmNoX2luaXRfb25lX2lycV9k
ZXNjKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQogCU5PVF9ZRVQoKTsNCmRpZmYgLXIgNmFm
OGE4OWM5OWNkIHhlbi9hcmNoL2FybS94ZW4vbW0uYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9t
bS5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9tbS5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTI1NSwzICsyNTUsMjcg
QEAgaW50IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcgdmlydCwgdQ0KIAlyZXR1cm4gMDsN
CiB9DQogDQoraW50IG1hcF9wYWdlc190b194ZW4odW5zaWduZWQgbG9uZyB2aXJ0LCB1bnNpZ25l
ZCBsb25nIG1mbiwgaW50IG5yLCB1bnNpZ25lZCBsb25nIGZsYWdzKQ0KK3sNCisgICAgICAgIHVu
c2lnbmVkIGxvbmcgdmFkZHIgPSByb3VuZF9kb3duKHZpcnQsIFBBR0VfU0laRSk7DQorICAgICAg
ICB1bnNpZ25lZCBsb25nIG1hZGRyID0gbWZuIDw8IFBBR0VfU0hJRlQ7DQorICAgICAgICB1bnNp
Z25lZCBpbnQgZW5kID0gdmlydCArIChuciA8PCBQQUdFX1NISUZUKTsNCisNCisgICAgICAgIGwx
ZV90ICpsMWUgPSBsMV9saW5lYXJfb2Zmc2V0X3hlbih2YWRkcik7DQorDQorICAgICAgICBkbyB7
DQorICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgbGltaXQgPSAodmFkZHIgKyBTRUNUSU9O
X1NJWkUpICYgKFNFQ1RJT05fTUFTSyk7DQorICAgICAgICAgICAgICAgIGxpbWl0ID0gKGxpbWl0
IDwgZW5kKSA/IGxpbWl0IDogZW5kOw0KKw0KKyAgICAgICAgICAgICAgICBpZiAoKCh2YWRkciB8
IG1hZGRyIHwgbGltaXQpICYgflNFQ1RJT05fTUFTSykgPT0gMCkgew0KKyAgICAgICAgICAgICAg
ICAgICAgICAgICpsMWUgPSBNS19MMUUobWFkZHIsIGZsYWdzKTsNCisgICAgICAgICAgICAgICAg
ICAgICAgICBwdGVfc3luYyhsMWUpOw0KKw0KKyAgICAgICAgICAgICAgICAgICAgICAgIHZhZGRy
ICs9IFNFQ1RJT05fU0laRTsNCisgICAgICAgICAgICAgICAgICAgICAgICBtYWRkciArPSBTRUNU
SU9OX1NJWkU7DQorICAgICAgICAgICAgICAgIH0NCisgICAgICAgIH0gd2hpbGUobDFlKyssIHZh
ZGRyIDwgZW5kKTsNCisNCisgICAgICAgIHJldHVybiAwOw0KK30NCisNCmRpZmYgLXIgNmFmOGE4
OWM5OWNkIHhlbi9hcmNoL2FybS94ZW4vc2V0dXAuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9z
ZXR1cC5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJt
L3hlbi9zZXR1cC5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTY0LDExICs2
NCwxMSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IGRvbTBfc2l6ZSA9IDI1NiAqIDEwDQogaW50ZWdl
cl9wYXJhbSgiZG9tMF9zaXplIiwgZG9tMF9zaXplKTsNCiANCiAvL3N0YXRpYyB1bnNpZ25lZCBs
b25nIGRvbTBfaW1hZ2Vfc3RhcnQgPSAweDQwQjAwMDAwVUw7DQotc3RhdGljIHVuc2lnbmVkIGxv
bmcgZG9tMF9pbWFnZV9zdGFydCA9IDB4MDBCMDAwMDBVTDsNCitzdGF0aWMgdW5zaWduZWQgbG9u
ZyBkb20wX2ltYWdlX3N0YXJ0ID0gMHhBMDAwMDBVTDsNCiBpbnRlZ2VyX3BhcmFtKCJpbWFnZV9z
dGFydCIsIGRvbTBfaW1hZ2Vfc3RhcnQpOw0KIA0KIC8vc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9t
MF9pbWFnZV9zaXplID0gMHhBMDAwMDBVTDsNCi1zdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2lt
YWdlX3NpemUgPSAweEEwMDAwMFVMOw0KK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c2l6ZSA9IDB4MTQwMDAwMFVMOw0KIGludGVnZXJfcGFyYW0oImltYWdlX2xlbmd0aCIsIGRvbTBf
aW1hZ2Vfc2l6ZSk7DQogDQogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVz
X2luZm9fdCAqaW5mbykNCkBAIC0yMTEsNiArMjExLDggQEAgYXNtbGlua2FnZSB2b2lkIHN0YXJ0
X3hlbih2b2lkKQ0KIA0KIAl0YXNrbGV0X3N1YnN5c19pbml0KCk7DQogDQorCW1hY2hpbmVfc2V0
dXAoKTsNCisNCiAJdGltZXJfaW5pdCgpOw0KIA0KIAlpZGxlX2RvbWFpbl9pbml0KCk7DQpkaWZm
IC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0veGVuL3RpbWUuYw0KLS0tIGEveGVuL2FyY2gv
YXJtL3hlbi90aW1lLmMJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3RpbWUuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC03
OSw1ICs3OSw0IEBAIHZvaWQgZG9tYWluX3NldF90aW1lX29mZnNldChzdHJ1Y3QgZG9tYWkNCiAN
CiB2b2lkIHRpbWVrZWVwaW5nX2luaXQodm9pZCkNCiB7DQotCU5PVF9ZRVQoKTsNCiB9DQpkaWZm
IC1yIDZhZjhhODljOTljZCB4ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYw0KLS0tIGEveGVuL2Ry
aXZlcnMvY2hhci9jb25zb2xlLmMJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysg
Yi94ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDANCkBAIC00MTIsNyArNDEyLDExIEBAIGxvbmcgZG9fY29uc29sZV9pbyhpbnQgY21kLCBpbnQg
Y291bnQsIFgNCiAgKiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KICAqLw0KIA0KKyNpZiBkZWZpbmVkKF9fYXJtX18pDQorc3RhdGljIGJvb2xf
dCBjb25zb2xlX2xvY2tzX2J1c3RlZCA9IDE7DQorI2Vsc2UNCiBzdGF0aWMgYm9vbF90IGNvbnNv
bGVfbG9ja3NfYnVzdGVkOw0KKyNlbmRpZg0KIA0KIHN0YXRpYyB2b2lkIF9fcHV0c3RyKGNvbnN0
IGNoYXIgKnN0cikNCiB7DQpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJt
L2dpYy5oDQotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysr
IGIveGVuL2luY2x1ZGUvYXNtLWFybS9naWMuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDANCkBAIC0wLDAgKzEsMTAxIEBADQorLyoNCisgKiBnaWMuaA0KKyAqDQorICogQ29weXJpZ2h0
IChDKSAyMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBKYWVtaW4gUnl1ICA8
am03Ny5yeXVAc2Ftc3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0
d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAqIGl0IHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNl
IGFzDQorICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uDQorICoN
CisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxs
IGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJlY2Vp
dmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisgKiBhbG9uZyB3
aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KKyAq
IEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1B
ICAwMjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisjaWZuZGVmIF9fQVJNX0dJQ19IX18NCisjZGVm
aW5lIF9fQVJNX0dJQ19IX18NCisNCisNCisvKiBEaXN0cmlidXRvciBSZWdpc3RlciBNYXAgKi8N
CisjZGVmaW5lIF9JQ0REQ1IJCTB4MDAwICAvKiBEaXN0cmlidXRvciBDb250cm9sIFJlZ2lzdGVy
ICovDQorI2RlZmluZSBfSUNESUNUUgkweDAwNCAgLyogSW50ZXJydXB0IENvbnRyb2xsZXIgVHlw
ZSBSZWdpc3RlciAqLw0KKyNkZWZpbmUgX0lDRElJRFIJMHgwMDggIC8qIERpc3RyaWJ1dG9yIElt
cGxlbWVudGVyIElkIFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMAkweDA4MCAgLyogSW50
ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMQkweDA4NCAgLyog
SW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMgkweDA4OCAg
LyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMwkweDA4
YyAgLyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSNAkw
eDA5MCAgLyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNF
UgkweDEwMCAgLyogSW50ZXJydXB0IFNldC1FbmFibGUgUmVnaXN0ZXIgKi8NCisjZGVmaW5lIF9J
Q0RJQ0VSCTB4MTgwICAvKiBJbnRlcnJ1cHQgQ2xlYXItRW5hYmxlIFJlZ2lzdGVyICovDQorI2Rl
ZmluZSBfSUNESVNQUgkweDIwMCAgLyogSW50ZXJydXB0IFNldC1QZW5kaW5nIFJlZ2lzdGVyICov
DQorI2RlZmluZSBfSUNESUNQUgkweDI4MCAgLyogSW50ZXJydXB0IENsZWFyLVBlbmRpbmcgUmVn
aXN0ZXIgKi8NCisjZGVmaW5lIF9JQ0RBQlIJCTB4MzAwICAvKiBBY3RpdmUgQml0IFJlZ2lzdGVy
cyAqLw0KKyNkZWZpbmUgX0lDRElQUgkJMHg0MDAgIC8qIEludGVycnVwdCBQcmlvcml0eSBSZWdp
c3RlciAqLw0KKyNkZWZpbmUgX0lDRElQVFIJMHg4MDAgIC8qIEludGVycnVwdCBQcm9jZXNzb3Ig
VGFyZ2V0cyBSZWdpc3RlcnMgKi8NCisjZGVmaW5lIF9JQ0RJQ0ZSCTB4QzAwICAvKiBJbnRlcnJ1
cHQgQ29uZmlndXJhdGlvbiBSZWdpc3RlcnMgKi8NCisjZGVmaW5lIF9JQ0RTR0lSCTB4RjAwICAv
KiBTb2Z0d2FyZSBHZW5lcmF0ZWQgSW50ZXJydXB0IFJlZ2lzdGVyICovDQorDQorI2RlZmluZSBJ
Q0REQ1IoKQkoX0lDRERDUikNCisjZGVmaW5lIElDRElDVFIoKQkoX0lDRElDVFIpDQorI2RlZmlu
ZSBJQ0RJU1IoeCkJKF9JQ0RJU1IwICsgKHggLyBCSVRTX1BFUl9MT05HKSAqIEJZVEVTX1BFUl9M
T05HKQ0KKyNkZWZpbmUgSUNESVNFUih4KQkoX0lDRElTRVIgKyAoeCAvIEJJVFNfUEVSX0xPTkcp
ICogQllURVNfUEVSX0xPTkcpDQorI2RlZmluZSBJQ0RJQ0VSKHgpCShfSUNESUNFUiArICh4IC8g
QklUU19QRVJfTE9ORykgKiBCWVRFU19QRVJfTE9ORykNCisjZGVmaW5lIElDRElTUFIoeCkJKF9J
Q0RJU1BSICsgKHggLyBCSVRTX1BFUl9MT05HKSAqIEJZVEVTX1BFUl9MT05HKQ0KKyNkZWZpbmUg
SUNESUNQUih4KQkoX0lDRElDUFIgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xP
TkcpDQorI2RlZmluZSBJQ0RBQlIoeCkJKF9JQ0RBQlIgICsgKHggLyBCSVRTX1BFUl9MT05HKSAq
IEJZVEVTX1BFUl9MT05HKQ0KKyNkZWZpbmUgSUNESVBSKHgpCShfSUNESVBSICArICh4IC8gIDQp
ICogQllURVNfUEVSX0xPTkcpDQorI2RlZmluZSBJQ0RJUFRSKHgpCShfSUNESVBUUiArICh4IC8g
IDQpICogQllURVNfUEVSX0xPTkcpDQorI2RlZmluZSBJQ0RTR0lSKCkJKF9JQ0RTR0lSKQ0KKw0K
Ky8qIENQVSBJbnRlcmZhY2UgUmVnaXN0ZXIgTWFwICovDQorI2RlZmluZSBfSUNDSUNSCQkweDAw
MCAgLyogQ1BVIEludGVyZmFjZSBDb250cm9sIFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNDUE1S
CQkweDAwNCAgLyogSW50ZXJydXB0IFByaW9yaXR5IE1hc2sgUmVnaXN0ZXIgKi8NCisjZGVmaW5l
IF9JQ0NCUFIJCTB4MDA4ICAvKiBCaW5yYXJ5IFBvaW50IFJlZ2lzdGVyICovDQorI2RlZmluZSBf
SUNDSUFSCQkweDAwQyAgLyogSW50ZXJydXB0IEFja25vd2xlZGdlIFJlZ2lzdGVyICovDQorI2Rl
ZmluZSBfSUNDRU9JUgkweDAxMCAgLyogRW5kIG9mIEludGVycnVwdCBSZWdpc3RlciAqLw0KKyNk
ZWZpbmUgX0lDQ1JQUgkJMHgwMTQgIC8qIFJ1bm5pbmcgUHJpb3JpdHkgUmVnaXN0ZXIgKi8NCisj
ZGVmaW5lIF9JQ0NIUElSCTB4MDE4ICAvKiBIaWdoZXN0IFBlbmRpbmcgSW50ZXJydXB0IFJlZ2lz
dGVyICovDQorI2RlZmluZSBfSUNDQUJQUgkweDAxQyAgLyogQWxpYXNlZCBCaW5hcnkgUG9pbnQg
UmVnaXN0ZXIgKi8NCisjZGVmaW5lIF9JQ0NJSURSCTB4MEZDICAvKiBDUFUgSW50ZXJmYWNlIElk
IFJlZ2lzdGVyICovDQorDQorI2RlZmluZSBJQ0NJQ1IoKQkoX0lDQ0lDUikNCisjZGVmaW5lIElD
Q1BNUigpCShfSUNDUE1SKQ0KKyNkZWZpbmUgSUNDQlBSKCkJKF9JQ0NCUFIpDQorI2RlZmluZSBJ
Q0NJQVIoKQkoX0lDQ0lBUikNCisjZGVmaW5lIElDQ0VPSVIoKQkoX0lDQ0VPSVIpDQorI2RlZmlu
ZSBJQ0NSUFIoKQkoX0lDQ1JQUikNCisjZGVmaW5lIElDQ0hQSVIoKQkoX0lDQ0hQSVIpDQorI2Rl
ZmluZSBJQ0NJSURSKCkJKF9JQ0NJSURSKQ0KKw0KKyNkZWZpbmUgU0VDVVJFX0lOVEVSUlVQVAkw
DQorI2RlZmluZSBOT05TRUNVUkVfSU5URVJSVVBUCTENCisNCisjZGVmaW5lIFNHSSh4KQkJCSh4
KQ0KKyNkZWZpbmUgUFBJKHgpCQkJKHggKyAxNikNCisjZGVmaW5lIFNQSSh4KQkJCSh4ICsgMzIp
DQorDQorI2lmbmRlZiBfX0FTU0VNQkxZX18NCisNCisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+DQor
DQorI2RlZmluZSBHSUNfRElTVFJJQlVUT1IoeCkgICAgICAoX2dpY19kaXN0cmlidXRvcl9iYXNl
ICsgeCkNCisjZGVmaW5lIEdJQ19DUFVfSU5URVJGQUNFKHgpICAgIChfZ2ljX2NwdV9iYXNlICsg
eCkNCisNCit2b2lkIGdpY19zZXRfY3B1KHVuc2lnbmVkIGludCBpcnEsIHVuc2lnbmVkIGludCBt
YXNrKTsNCit2b2lkIGdpY19zZXRfaXJxX3ByaW9yaXR5KHVuc2lnbmVkIGludCBpcnEsIHVuc2ln
bmVkIGludCBwcmlvcml0eSk7DQordm9pZCBnaWNfYWNrX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsN
Cit2b2lkIGdpY19tYXNrX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsNCit2b2lkIGdpY191bm1hc2tf
aXJxKHVuc2lnbmVkIGludCBpcnEpOw0KK3ZvaWQgZ2ljX2VuZF9pcnEodW5zaWduZWQgaW50IGly
cSk7DQordm9pZCBnaWNfY2hhbmdlX2lycV9zdGF0ZSh1bnNpZ25lZCBpbnQgaXJxLCB1bnNpZ25l
ZCBpbnQgc3RhdGUpOw0KKw0KK2V4dGVybiB2b2lkICpfZ2ljX2NwdV9iYXNlW05SX0NQVVNdOw0K
K2V4dGVybiB2b2lkICpfZ2ljX2Rpc3RyaWJ1dG9yX2Jhc2U7DQorI2VuZGlmDQorI2VuZGlmDQpk
aWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJtL2lycS5oDQotLS0gYS94ZW4v
aW5jbHVkZS9hc20tYXJtL2lycS5oCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysr
IGIveGVuL2luY2x1ZGUvYXNtLWFybS9pcnEuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDANCkBAIC0xNSw2ICsxNSw3IEBADQogDQogI2RlZmluZSBpcnFfY2ZnKGlycSkJCSgmaXJxX2Nm
Z1tpcnFdKQ0KICNkZWZpbmUgaXJxX3RvX2Rlc2MoaXJxKQkoJmlycV9kZXNjW2lycV0pCQ0KKyNk
ZWZpbmUgZGVzY190b19pcnEoZGVzYykJKChkZXNjIC0gJmlycV9kZXNjWzBdKSAvIHNpemVvZihz
dHJ1Y3QgaXJxX2Rlc2MpKTsNCiANCiAjZGVmaW5lIElSUV9NQVhfR1VFU1RTCQk3DQogdHlwZWRl
ZiBzdHJ1Y3Qgew0KQEAgLTQwLDggKzQxLDYgQEAgdHlwZWRlZiBzdHJ1Y3Qgew0KICAgICBERUNM
QVJFX0JJVE1BUChfYml0cyxOUl9JUlFTKTsNCiB9IHZtYXNrX3Q7DQogDQotZXh0ZXJuIHN0cnVj
dCBpcnFfZGVzYyAqaXJxX2Rlc2M7DQotDQogc3RhdGljIGlubGluZSBpbnQgaXJxX2Rlc2NfaW5p
dGlhbGl6ZWQoc3RydWN0IGlycV9kZXNjICpkZXNjKQ0KIHsNCiAJcmV0dXJuIDA7DQpkaWZmIC1y
IDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2F2cC5oDQotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNt
LWFybS90ZWdyYS9hdnAuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC0wLDAg
KzEsMTQ0IEBADQorLyoNCisgKiBDb3B5cmlnaHQgKGMpIDIwMTAgTlZJRElBIENvcnBvcmF0aW9u
Lg0KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQorICoNCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQg
dXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQNCisgKiBtb2Rp
ZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnMgYXJlIG1ldDoNCisgKg0KKyAqIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt
dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSwNCisgKiB0aGlzIGxpc3Qgb2Yg
Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLg0KKyAqDQorICogUmVkaXN0
cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmln
aHQgbm90aWNlLA0KKyAqIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n
IGRpc2NsYWltZXIgaW4gdGhlIGRvY3VtZW50YXRpb24NCisgKiBhbmQvb3Igb3RoZXIgbWF0ZXJp
YWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4NCisgKg0KKyAqIE5laXRoZXIgdGhl
IG5hbWUgb2YgdGhlIE5WSURJQSBDb3Jwb3JhdGlvbiBub3IgdGhlIG5hbWVzIG9mIGl0cyBjb250
cmlidXRvcnMNCisgKiBtYXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMg
ZGVyaXZlZCBmcm9tIHRoaXMgc29mdHdhcmUNCisgKiB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdy
aXR0ZW4gcGVybWlzc2lvbi4NCisgKg0KKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkg
VEhFIENPUFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTIElTIg0KKyAqIEFORCBB
TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J
VEVEIFRPLCBUSEUNCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO
RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQ0KKyAqIEFSRSBESVNDTEFJTUVELiBJ
TiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUiBPUiBDT05UUklCVVRPUlMgQkUN
CisgKiBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFM
LCBFWEVNUExBUlksIE9SDQorICogQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJV
VCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YNCisgKiBTVUJTVElUVVRFIEdPT0RTIE9S
IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MNCisg
KiBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJ
TElUWSwgV0hFVEhFUiBJTg0KKyAqIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JU
IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpDQorICogQVJJU0lORyBJTiBBTlkg
V0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU
SEUNCisgKiBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4NCisgKg0KKyAqLw0KKw0KKyNpZm5k
ZWYgSU5DTFVERURfQVZQX0gNCisjZGVmaW5lIElOQ0xVREVEX0FWUF9IDQorDQorI2luY2x1ZGUg
ImFwMTUvYXJpY3Rsci5oIg0KKyNpbmNsdWRlICJhcDE1L2FydGltZXIuaCINCisvLyBGSVhNRTog
Z2V0IHRoZSBhcmFybWV2IGhlYWRlcg0KKw0KKy8vIDMgY29udHJvbGxlcnMgaW4gY29udGlndW91
cyBtZW1vcnkgc3RhcnRpbmcgYXQgSU5URVJSVVBUX0JBU0UsIGVhY2gNCisvLyBjb250cm9sbGVy
J3MgYXBlcnR1cmUgaXMgSU5URVJSVVBUX1NJWkUgbGFyZ2UNCisjZGVmaW5lIElOVEVSUlVQVF9C
QVNFIDB4NjAwMDQwMDANCisjZGVmaW5lIElOVEVSUlVQVF9TSVpFIDB4MTAwDQorI2RlZmluZSBJ
TlRFUlJVUFRfTlVNX0NPTlRST0xMRVJTIDMNCisNCisjZGVmaW5lIElOVEVSUlVQVF9QRU5ESU5H
KCBjdGxyICkgXA0KKyAgICAoSU5URVJSVVBUX0JBU0UgKyAoKGN0bHIpICogSU5URVJSVVBUX1NJ
WkUpICsgSUNUTFJfVklSUV9DT1BfMCkNCisNCisjZGVmaW5lIElOVEVSUlVQVF9TRVQoIGN0bHIg
KSBcDQorICAgIChJTlRFUlJVUFRfQkFTRSArICgoY3RscikgKiBJTlRFUlJVUFRfU0laRSkgKyBJ
Q1RMUl9DT1BfSUVSX1NFVF8wKQ0KKw0KKyNkZWZpbmUgSU5URVJSVVBUX0NMUiggY3RsciApIFwN
CisgICAgKElOVEVSUlVQVF9CQVNFICsgKChjdGxyKSAqIElOVEVSUlVQVF9TSVpFKSArIElDVExS
X0NPUF9JRVJfQ0xSXzApDQorDQorI2RlZmluZSBPU0NfQ1RSTCAgICAgICAgKCAweDYwMDA2MDAw
ICsgMHg1MCApDQorI2RlZmluZSBPU0NfRlJFUV9ERVQgICAgKCAweDYwMDA2MDAwICsgMHg1OCAp
DQorI2RlZmluZSBPU0NfREVUX1NUQVRVUyAgKCAweDYwMDA2MDAwICsgMHg1QyApDQorDQorI2Rl
ZmluZSBUSU1FUl9VU0VDICAgICAgKCAweDYwMDA1MDEwICkNCisjZGVmaW5lIFRJTUVSX0NGRyAg
ICAgICAoIDB4NjAwMDUwMTQgKQ0KKyNkZWZpbmUgVElNRVJfMF9CQVNFICAgICggMHg2MDAwNTAw
MCApDQorI2RlZmluZSBUSU1FUl8wICAgICAgICAgKCBUSU1FUl8wX0JBU0UgKyBUSU1FUl9UTVJf
UFRWXzAgKQ0KKyNkZWZpbmUgVElNRVJfMF9DTEVBUiAgICggVElNRVJfMF9CQVNFICsgVElNRVJf
VE1SX1BDUl8wICkNCisjZGVmaW5lIFRJTUVSXzFfQkFTRSAgICAoIDB4NjAwMDUwMDggKQ0KKyNk
ZWZpbmUgVElNRVJfMSAgICAgICAgICggVElNRVJfMV9CQVNFICsgVElNRVJfVE1SX1BUVl8wICkN
CisjZGVmaW5lIFRJTUVSXzFfQ0xFQVIgICAoIFRJTUVSXzFfQkFTRSArIFRJTUVSX1RNUl9QQ1Jf
MCApDQorDQorI2RlZmluZSBDTE9DS19SU1RfTE8gICAgKDB4NjAwMDYwMDQpDQorI2RlZmluZSBD
TE9DS19DVExSX0hJICAgKDB4NjAwMDYwMTQpDQorI2RlZmluZSBDTE9DS19DVExSX0xPICAgKDB4
NjAwMDYwMTApDQorDQorI2RlZmluZSBDQUNIRV9DVExSICAgICAgKDB4NjAwMEMwMDApDQorI2Rl
ZmluZSBDQUNIRV9DT05UUk9MXzAgICAgICAgICAoMHgwKQ0KKw0KKyNkZWZpbmUgUFBJX0lOVFJf
SURfVElNRVJfMCAgICAgKDApDQorI2RlZmluZSBQUElfSU5UUl9JRF9USU1FUl8xICAgICAoMSkN
CisjZGVmaW5lIFBQSV9JTlRSX0lEX1RJTUVSXzIgICAgICg5KQ0KKyNkZWZpbmUgUFBJX0lOVFJf
SURfVElNRVJfMyAgICAgKDEwKQ0KKw0KKy8qIGZsb3cgY29udHJvbGxlciAqLw0KKyNkZWZpbmUg
RkxPV19DT05UUk9MTEVSICAgICAoMHg2MDAwNzAwNCkNCisNCisvKiBleGNlcHRpb24gdmVjdG9y
cyAqLw0KKyNkZWZpbmUgVkVDVE9SX0JBU0UgICAgICAgICAgICAgKCAweDYwMDBGMjAwICkNCisj
ZGVmaW5lIFZFQ1RPUl9SRVNFVCAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyAwICkNCisjZGVm
aW5lIFZFQ1RPUl9VTkRFRiAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyA0ICkNCisjZGVmaW5l
IFZFQ1RPUl9TV0kgICAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyA4ICkNCisjZGVmaW5lIFZF
Q1RPUl9QUkVGRVRDSF9BQk9SVCAgICggVkVDVE9SX0JBU0UgKyAxMiApDQorI2RlZmluZSBWRUNU
T1JfREFUQV9BQk9SVCAgICAgICAoIFZFQ1RPUl9CQVNFICsgMTYgKQ0KKyNkZWZpbmUgVkVDVE9S
X0lSUSAgICAgICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDI0ICkNCisjZGVmaW5lIFZFQ1RPUl9G
SVEgICAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyAyOCApDQorDQorI2RlZmluZSBNT0RFX0RJ
U0FCTEVfSU5UUiAweGMwDQorI2RlZmluZSBNT0RFX1VTUiAweDEwDQorI2RlZmluZSBNT0RFX0ZJ
USAweDExDQorI2RlZmluZSBNT0RFX0lSUSAweDEyDQorI2RlZmluZSBNT0RFX1NWQyAweDEzDQor
I2RlZmluZSBNT0RFX0FCVCAweDE3DQorI2RlZmluZSBNT0RFX1VORCAweDFCDQorI2RlZmluZSBN
T0RFX1NZUyAweDFGDQorDQorI2RlZmluZSBBUDE1X0NBQ0hFX0xJTkVfU0laRSAgICAgICAgICAg
IDMyDQorDQorI2RlZmluZSBBUDE1X0FQQl9MMl9DQUNIRV9CQVNFIDB4NzAwMGU4MDAgDQorI2Rl
ZmluZSBBUDE1X0FQQl9DTEtfUlNUX0JBU0UgIDB4NjAwMDYwMDANCisjZGVmaW5lIEFQMTVfQVBC
X01JU0NfQkFTRSAgICAgMHg3MDAwMDAwMA0KKw0KKyNkZWZpbmUgQVAxMF9BUEJfQ0xLX1JTVF9C
QVNFICAweDYwMDA2MDAwDQorI2RlZmluZSBBUDEwX0FQQl9NSVNDX0JBU0UgICAgIDB4NzAwMDAw
MDANCisNCisjZGVmaW5lIE1NVV9UTEJfQkFTRSAgICAgICAgICAgICAgMHhmMDAwZjAwMA0KKyNk
ZWZpbmUgTU1VX1RMQl9DQUNIRV9XSU5ET1dfMCAgICAweDQwDQorI2RlZmluZSBNTVVfVExCX0NB
Q0hFX09QVElPTlNfMCAgIDB4NDQNCisNCisjZGVmaW5lIEFQMTVfUElOTVVYX0NGR19DVExfMCAg
IDB4NzAwMDAwMjQNCisjZGVmaW5lIEFQMTVfQVZQX0pUQUdfRU5BQkxFICAgIDB4QzANCisNCisj
ZGVmaW5lIFBNQ19TQ1JBVENIMjJfUkVHX0xQMCAgIDB4NzAwMGU0YTgNCisNCisjZGVmaW5lIEFW
UF9XRFRfUkVTRVQgICAweDJGMDBCQUQwDQorDQorLyogQ2FjaGVkIHRvIHVuY2FjaGVkIG9mZnNl
dCBmb3IgQVZQDQorICoNCisgKiBIYXJkd2FyZSBoYXMgdW5jYWNoZWQgcmVtYXAgYXBlcnR1cmUg
Zm9yIEFWUCBhcyBBVlAgZG9lc24ndCBoYXZlIE1NVQ0KKyAqIGJ1dCBzdGlsbCBoYXMgY2FjaGUg
KG5hbWVkIENPUCBjYWNoZSkuDQorICoNCisgKiBUaGlzIGFwZXJ0dXJlIG1vdmVkIGJldHdlZW4g
QVAxNSBhbmQgQVAyMC4NCisgKi8NCisjZGVmaW5lIEFQMTVfQ0FDSEVEX1RPX1VOQ0FDSEVEX09G
RlNFVCAweDkwMDAwMDAwDQorI2RlZmluZSBBUDIwX0NBQ0hFRF9UT19VTkNBQ0hFRF9PRkZTRVQg
MHg4MDAwMDAwMA0KKw0KKyNkZWZpbmUgQVBYWF9FWFRfTUVNX1NUQVJUICAgICAgMHgwMDAwMDAw
MA0KKyNkZWZpbmUgQVBYWF9FWFRfTUVNX0VORCAgICAgICAgMHg0MDAwMDAwMA0KKw0KKyNkZWZp
bmUgQVBYWF9NTUlPX1NUQVJUICAgICAgICAgMHg0MDAwMDAwMA0KKyNkZWZpbmUgQVBYWF9NTUlP
X0VORCAgICAgICAgICAgMHhGRkYwMDAwMA0KKw0KKyNkZWZpbmUgVFhYX0VYVF9NRU1fU1RBUlQg
ICAgICAgMHg4MDAwMDAwMA0KKyNkZWZpbmUgVFhYX0VYVF9NRU1fRU5EICAgICAgICAgMHhjMDAw
MDAwMA0KKw0KKyNkZWZpbmUgVFhYX01NSU9fU1RBUlQgICAgICAgICAgMHg0MDAwMDAwMA0KKyNk
ZWZpbmUgVFhYX01NSU9fRU5EICAgICAgICAgICAgMHg4MDAwMDAwMA0KKw0KKyNlbmRpZg0KZGlm
ZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS9jb25maWcuaA0KLS0t
IGEveGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS9jb25maWcuaAlTdW4gRmViIDEyIDEyOjI0OjIx
IDIwMTIgKzA5MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvY29uZmlnLmgJU3Vu
IEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtMSwxMSArMSw2IEBADQogI2lmbmRlZiBf
X1RFR1JBX0NPTkZJR19IX18NCiAjZGVmaW5lIF9fVEVHUkFfQ09ORklHX0hfXw0KIA0KLSNkZWZp
bmUgSFoJMTAwDQotI2RlZmluZSBDTE9DS19USUNLX1JBVEUJCTEwMDAwMDANCisjZGVmaW5lIE1B
WF9QSFlTX0NQVVMJMg0KIA0KLSNkZWZpbmUgTUFYX1BIWVNfQ1BVUwkJMg0KLQ0KLSNkZWZpbmUg
QlVJTFRJTl9DT01NQU5EX0xJTkVfU0laRSAyNTYNCi0jZGVmaW5lIEJVSUxUSU5fQ09NTUFORF9M
SU5FCSIiDQogI2VuZGlmDQpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJt
L3RlZ3JhL2lycXMuaA0KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvaXJxcy5oCVN1biBGZWIgMTIgMTU6
MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw2MCBAQA0KKy8qDQorICogYXJjaC9hcm0vbWFj
aC10ZWdyYS9pbmNsdWRlL21hY2gvaXJxcy5oDQorICoNCisgKiBDb3B5cmlnaHQgKGMpIDIwMDks
IE5WSURJQSBDb3Jwb3JhdGlvbi4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3
YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIg
dGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg
YnkNCisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9m
IHRoZSBMaWNlbnNlLCBvcg0KKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24u
DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBp
dCB3aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3INCisgKiBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UgZm9yDQorICogbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYWxvbmcN
CisgKiB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uLCBJbmMuLA0KKyAqIDUxIEZyYW5rbGluIFN0cmVldCwgRmlmdGggRmxvb3Is
IEJvc3RvbiwgTUEgIDAyMTEwLTEzMDEsIFVTQS4NCisgKi8NCisNCisjaWZuZGVmIF9fVEVHUkFf
SVJRU19IDQorI2RlZmluZSBfX1RFR1JBX0lSUVNfSA0KKw0KKyNkZWZpbmUgTlJfSVJRUwkJCTUx
Mg0KKw0KKyNkZWZpbmUgSU5UX1BSSV9CQVNFCQkzMg0KKyNkZWZpbmUgSU5UX1JUQwkJCShJTlRf
UFJJX0JBU0UgKyAyKQ0KKyNkZWZpbmUgSU5UX1VTQgkJCShJTlRfUFJJX0JBU0UgKyAyMCkNCisj
ZGVmaW5lIElOVF9VU0IyCQkoSU5UX1BSSV9CQVNFICsgMjEpDQorI2RlZmluZSBJTlRfQVBCX0RN
QQkJKElOVF9QUklfQkFTRSArIDI2KQ0KKw0KKyNkZWZpbmUgSU5UX1NFQ19CQVNFCQkoSU5UX1BS
SV9CQVNFICsgMzIpDQorI2RlZmluZSBJTlRfR1BJTzEJCShJTlRfU0VDX0JBU0UgKyAwKQ0KKyNk
ZWZpbmUgSU5UX0dQSU8yCQkoSU5UX1NFQ19CQVNFICsgMSkNCisjZGVmaW5lIElOVF9HUElPMwkJ
KElOVF9TRUNfQkFTRSArIDIpDQorI2RlZmluZSBJTlRfR1BJTzQJCShJTlRfU0VDX0JBU0UgKyAz
KQ0KKyNkZWZpbmUgSU5UX1RNUjMJCShJTlRfU0VDX0JBU0UgKyA5KQ0KKyNkZWZpbmUgSU5UX1RN
UjQJCShJTlRfU0VDX0JBU0UgKyAxMCkNCisjZGVmaW5lIElOVF9TWVNfU1RBVFNfTU9OCShJTlRf
U0VDX0JBU0UgKyAyMikNCisjZGVmaW5lIElOVF9HUElPNQkJKElOVF9TRUNfQkFTRSArIDIzKQ0K
Kw0KKyNkZWZpbmUgSU5UX1RSSV9CQVNFCQkoSU5UX1NFQ19CQVNFICsgMzIpDQorI2RlZmluZSBJ
TlRfS0JDCQkJKElOVF9UUklfQkFTRSArIDIxKQ0KKyNkZWZpbmUgSU5UX0VYVEVSTkFMX1BNVQko
SU5UX1RSSV9CQVNFICsgMjIpDQorI2RlZmluZSBJTlRfR1BJTzYJCShJTlRfVFJJX0JBU0UgKyAy
MykNCisjZGVmaW5lIElOVF9HUElPNwkJKElOVF9UUklfQkFTRSArIDI1KQ0KKw0KKyNkZWZpbmUg
SU5UX1FVQURfQkFTRQkJKElOVF9UUklfQkFTRSArIDMyKQ0KKyNkZWZpbmUgSU5UX1VTQjMJCShJ
TlRfUVVBRF9CQVNFICsgMSkNCisNCisjZGVmaW5lIElOVF9HUElPX0JBU0UJCShJTlRfUVVBRF9C
QVNFICsgMzIpDQorI2RlZmluZSBJTlRfR1BJT19OUgkJKDI4KjgpDQorDQorI2RlZmluZSBJTlRf
QVBCRE1BX0JBU0UJIAkoSU5UX0dQSU9fQkFTRSArIElOVF9HUElPX05SKQ0KKyNkZWZpbmUgSU5U
X0FQQkRNQV9OUgkJKDE2KQ0KKw0KKyNkZWZpbmUgSU5UX1NZU19OUgkoSU5UX0dQSU9fQkFTRSAt
IElOVF9QUklfQkFTRSkNCisjZGVmaW5lIElOVF9TWVNfU1oJKElOVF9TRUNfQkFTRSAtIElOVF9Q
UklfQkFTRSkNCisNCisjZW5kaWYNCmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vdGVncmEvc21wLmgNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwDQorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL3NtcC5oCVN1biBGZWIgMTIg
MTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw3IEBADQorI2lmbmRlZiBBU01BUk1fQVJD
SF9TTVBfSA0KKyNkZWZpbmUgQVNNQVJNX0FSQ0hfU01QX0gNCisNCisNCisjaW5jbHVkZSA8YXNt
L2dpYy5oPg0KKw0KKyNlbmRpZg0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUvYXNt
LWFybS90ZWdyYS90ZWdyYS5oDQotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS90ZWdyYS5oCVN1biBGZWIg
MTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw3NSBAQA0KKyNpZm5kZWYgX19URUdS
QTI1MF9IX18NCisjZGVmaW5lIF9fVEVHUkEyNTBfSF9fDQorDQorI2RlZmluZSBURUdSQV9BUk1f
Q1BVX0JBU0UJCTB4NTAwMDAwMDANCisjZGVmaW5lIFRFR1JBX1BQU0JfREVWSUNFX0JBU0UJCTB4
NjAwMDAwMDANCisjZGVmaW5lIFRFR1JBX0FQQl9ERVZJQ0VfQkFTRQkJMHg3MDAwMDAwMA0KKw0K
KyNkZWZpbmUgVEVHUkFfQVJNX1BFUklGX0JBU0UJCTB4NTAwNDAwMDANCisjZGVmaW5lIFRFR1JB
X0FSTV9QRVJJRl9TSVpFCQlTWl84Sw0KKw0KKyNkZWZpbmUgVEVHUkFfU0NVX0JBU0UJCQkweDUw
MDQwMDAwDQorI2RlZmluZSBURUdSQV9TQ1VfU0laRQkJCVNaXzI1Ng0KKw0KKyNkZWZpbmUgVEVH
UkFfR0lDX1BST0NfSUZfQkFTRQkJMHg1MDA0MDEwMA0KKyNkZWZpbmUgVEVHUkFfR0lDX1BST0Nf
SUZfU0laRQkJU1pfMjU2DQorDQorI2RlZmluZSBURUdSQV9BUk1fSU5UX0RJU1RfQkFTRQkJMHg1
MDA0MTAwMA0KKyNkZWZpbmUgVEVHUkFfQVJNX0lOVF9ESVNUX1NJWkUJCVNaXzRLDQorDQorI2Rl
ZmluZSBURUdSQV9QUklNQVJZX0lDVExSX0JBU0UJMHg2MDAwNDAwMA0KKyNkZWZpbmUgVEVHUkFf
UFJJTUFSWV9JQ1RMUl9TSVpFCVNaXzY0DQorDQorI2RlZmluZSBURUdSQV9TRUNPTkRBUllfSUNU
TFJfQkFTRQkweDYwMDA0MTAwDQorI2RlZmluZSBURUdSQV9TRUNPTkRBUllfSUNUTFJfU0laRQlT
Wl82NA0KKw0KKyNkZWZpbmUgVEVHUkFfVEVSVElBUllfSUNUTFJfQkFTRQkweDYwMDA0MjAwDQor
I2RlZmluZSBURUdSQV9URVJUSUFSWV9JQ1RMUl9TSVpFCVNaXzY0DQorDQorI2RlZmluZSBURUdS
QV9RVUFURVJOQVJZX0lDVExSX0JBU0UJMHg2MDAwNDMwMA0KKyNkZWZpbmUgVEVHUkFfUVVBVEVS
TkFSWV9JQ1RMUl9TSVpFCVNaXzY0DQorDQorI2RlZmluZSBURUdSQV9UTVIxX0JBU0UJCQkweDYw
MDA1MDAwDQorI2RlZmluZSBURUdSQV9UTVIxX1NJWkUJCQlTWl84DQorDQorI2RlZmluZSBURUdS
QV9UTVIyX0JBU0UJCQkweDYwMDA1MDA4DQorI2RlZmluZSBURUdSQV9UTVIyX1NJWkUJCQlTWl84
DQorDQorI2RlZmluZSBURUdSQV9UTVJVU19CQVNFCQkweDYwMDA1MDEwDQorI2RlZmluZSBURUdS
QV9UTVJVU19TSVpFCQlTWl82NA0KKw0KKyNkZWZpbmUgVEVHUkFfVE1SM19CQVNFCQkJMHg2MDAw
NTA1MA0KKyNkZWZpbmUgVEVHUkFfVE1SM19TSVpFCQkJU1pfOA0KKw0KKyNkZWZpbmUgVEVHUkFf
VE1SNF9CQVNFCQkJMHg2MDAwNTA1OA0KKyNkZWZpbmUgVEVHUkFfVE1SNF9TSVpFCQkJU1pfOA0K
Kw0KKyNkZWZpbmUgVEVHUkFfQ0xLX1JFU0VUX0JBU0UJCTB4NjAwMDYwMDANCisjZGVmaW5lIFRF
R1JBX0NMS19SRVNFVF9TSVpFCQlTWl80Sw0KKw0KKyNkZWZpbmUgVEVHUkFfRkxPV19DVFJMX0JB
U0UJCTB4NjAwMDcwMDANCisjZGVmaW5lIFRFR1JBX0ZMT1dfQ1RSTF9TSVpFCQkyMA0KKw0KKyNk
ZWZpbmUgVEVHUkFfR1BJT19CQVNFCQkJMHg2MDAwRDAwMA0KKyNkZWZpbmUgVEVHUkFfR1BJT19T
SVpFCQkJU1pfNEsNCisNCisjZGVmaW5lIFRFR1JBX0VYQ0VQVElPTl9WRUNUT1JTX0JBU0UgICAg
MHg2MDAwRjAwMA0KKyNkZWZpbmUgVEVHUkFfRVhDRVBUSU9OX1ZFQ1RPUlNfU0laRSAgICBTWl80
Sw0KKw0KKyNkZWZpbmUgSUNUTFJfQ1BVX0lFUl8wCQkJKDB4MjApDQorI2RlZmluZSBJQ1RMUl9D
UFVfSUVSX1NFVF8wCQkoMHgyNCkNCisjZGVmaW5lIElDVExSX0NQVV9JRVJfQ0xSXzAJCSgweDI4
KQ0KKyNkZWZpbmUgSUNUTFJfQ1BVX0lFUF9DTEFTU18wCQkoMHgyQykNCisjZGVmaW5lIElDVExS
X0NPUF9JRVJfMAkJCSgweDMwKQ0KKyNkZWZpbmUgSUNUTFJfQ09QX0lFUl9TRVRfMAkJKDB4MzQp
DQorI2RlZmluZSBJQ1RMUl9DT1BfSUVSX0NMUl8wCQkoMHgzOCkNCisjZGVmaW5lIElDVExSX0NP
UF9JRVBfQ0xBU1NfMAkJKDB4M0MpDQorDQorI2RlZmluZSBBUk1fUEVSSUZfQkFTRQkJCSgweDUw
MDQwMDAwKQ0KKw0KKy8vI2RlZmluZSBJT19BRERSRVNTKHgpCQkJKCgoKCh4KSAmIDB4NzAwMDAw
MDApID4+IDgpICsgKCgoeCkgJiAweDBGMDAwMDAwKSA+PiA0KSkgfCgoeCkgJiAweEZGRkZGKSB8
IDB4RkIwMDAwMDAgKQ0KKyNkZWZpbmUgSU9fQUREUkVTUyh4KQkJCSgoKCh4KSAmIDB4RjAwMDAw
MDApID4+IDgpIHwgKCh4KSAmIDB4RkZGRkYpIHwgKDB4RkIwMDAwMDAgKSkNCisjZGVmaW5lIElO
VF9QUElfQUREUkVTUyhfaW5zdCkJCSgweDYwMDA0MDAwICsgKDB4MTAwICogKF9pbnN0KSkpDQor
I2RlZmluZSBJTlRfQVBCRE1BX0FERFJFU1MJCSgweDYwMDBhMDAwKQ0KKw0KKyNlbmRpZg0KZGlm
ZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUveGVuL2lycS5oDQotLS0gYS94ZW4vaW5jbHVk
ZS94ZW4vaXJxLmgJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysgYi94ZW4vaW5j
bHVkZS94ZW4vaXJxLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtOTUsNiAr
OTUsMTAgQEAgaW50IGFyY2hfaW5pdF9vbmVfaXJxX2Rlc2Moc3RydWN0IGlycV9kZQ0KIA0KICNk
ZWZpbmUgaXJxX2Rlc2NfaW5pdGlhbGl6ZWQoZGVzYykgKChkZXNjKS0+aGFuZGxlciAhPSBOVUxM
KQ0KIA0KKyNpZiBkZWZpbmVkKF9fYXJtX18pDQorZXh0ZXJuIGlycV9kZXNjX3QgaXJxX2Rlc2Nb
TlJfSVJRU107DQorI2VuZGlmDQorDQogI2lmIGRlZmluZWQoX19pYTY0X18pDQogZXh0ZXJuIGly
cV9kZXNjX3QgaXJxX2Rlc2NbTlJfVkVDVE9SU107DQogDQpAQCAtMTIxLDYgKzEyNSw4IEBAIGV4
dGVybiB2b2lkIGlycV9hY3Rvcl9ub25lKHN0cnVjdCBpcnFfZGUNCiAjZGVmaW5lIGlycV9zaHV0
ZG93bl9ub25lIGlycV9hY3Rvcl9ub25lDQogI2RlZmluZSBpcnFfZGlzYWJsZV9ub25lIGlycV9h
Y3Rvcl9ub25lDQogI2RlZmluZSBpcnFfZW5hYmxlX25vbmUgaXJxX2FjdG9yX25vbmUNCisjZGVm
aW5lIGlycV9hY2tfbm9uZQlpcnFfYWN0b3Jfbm9uZQ0KKyNkZWZpbmUgaXJxX2VuZF9ub25lCWly
cV9hY3Rvcl9ub25lDQogDQogc3RydWN0IGRvbWFpbjsNCiBzdHJ1Y3QgdmNwdTsNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch11.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch11.diff"


YXJtOiBhZGQgZmlsZXMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgVGVncmEy
IGhhcm1vbnkgYm9hcmQuCgogeGVuL2FyY2gvYXJtL3RlZ3JhL01ha2VmaWxlICAgICAgICB8
ICAgIDMgKy0KIHhlbi9hcmNoL2FybS90ZWdyYS9lbnRyeS5TICAgICAgICAgfCAgIDMzICsr
KysrKysrCiB4ZW4vYXJjaC9hcm0vdGVncmEvdGVncmEyNTAuYyAgICAgIHwgIDMzMCArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKwogeGVuL2FyY2gvYXJtL3RlZ3JhL3RpbWVyLmMg
ICAgICAgICB8ICAxMTAgKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9h
cm0veGVuL2NwdS5jICAgICAgICAgICAgIHwgICAgNSArCiB4ZW4vYXJjaC9hcm0veGVuL2Zh
dWx0LmMgICAgICAgICAgIHwgICAgMSAtCiB4ZW4vYXJjaC9hcm0veGVuL2lycS5jICAgICAg
ICAgICAgIHwgICA0NiArKysrKysrKysrKy0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAg
ICAgICAgICAgfCAgIDI0ICsrKysrKwogeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jICAgICAg
ICAgICB8ICAgIDYgKy0KIHhlbi9hcmNoL2FybS94ZW4vdGltZS5jICAgICAgICAgICAgfCAg
ICAxIC0KIHhlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jICAgICAgICAgfCAgICA0ICsKIHhl
bi9pbmNsdWRlL2FzbS1hcm0vZ2ljLmggICAgICAgICAgfCAgMTAxICsrKysrKysrKysrKysr
KysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vaXJxLmggICAgICAgICAgfCAgICAz
ICstCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2F2cC5oICAgIHwgIDE0NCArKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVn
cmEvY29uZmlnLmggfCAgICA3ICstCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2lycXMu
aCAgIHwgICA2MCArKysrKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEv
c21wLmggICAgfCAgICA3ICsKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvdGVncmEuaCAg
fCAgIDc1ICsrKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUveGVuL2lycS5oICAgICAg
ICAgICAgICB8ICAgIDYgKwogMTkgZmlsZXMgY2hhbmdlZCwgOTUyIGluc2VydGlvbnMoKyks
IDE0IGRlbGV0aW9ucygtKQoKU2lnbmVkLW9mZi1ieTogSmFlbWluIFJ5dSA8am03Ny5yeXVA
c2Ftc3VuZy5jb20+CgpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0vdGVncmEv
TWFrZWZpbGUKLS0tIGEveGVuL2FyY2gvYXJtL3RlZ3JhL01ha2VmaWxlCVN1biBGZWIgMTIg
MTI6MjQ6MjEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvTWFrZWZpbGUJ
U3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwCkBAIC0xLDEgKzEsMiBAQAotb2JqLXkg
Kz0gZHVtbXkubworb2JqLXkgKz0gdGltZXIubyBlbnRyeS5vIHRlZ3JhMjUwLm8KKwpkaWZm
IC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0vdGVncmEvZW50cnkuUwotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0v
dGVncmEvZW50cnkuUwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAgLTAsMCAr
MSwzMyBAQAorLyoKKyAqIGVudHJ5LlMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDggU2Ft
c3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgSmFlTWluIFJ5dSAgPGptNzcucnl1QHNh
bXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBw
dWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICog
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi
ZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1Mg
Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUg
cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICog
YWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMw
LCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2Nv
bmZpZy5oPiAKKyNpbmxjdWRlIDxhc20vYXJjaC9pcnFzLmg+CisjaW5jbHVkZSA8YXNtL3Bh
Z2UuaD4KKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNy
b3MuaD4KKyNpbmNsdWRlIDxhc20vY3B1LWRvbWFpbi5oPgorI2luY2x1ZGUgPGFzbS9hc20t
b2Zmc2V0cy5oPgorCisJLmFsaWduCTUKKworRU5UUlkoYXJjaF9jb250ZXh0X3N3aXRjaCkK
Kwltb3YJcGMsIGxyCisKZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3RlZ3Jh
L3RlZ3JhMjUwLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMJU3VuIEZlYiAxMiAxNTow
NDowNiAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzMwIEBACisvKgorICogdGVncmEyNTAuYwor
ICoKKyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MgCisg
KiAgICAgICAgIEphZU1pbiBSeXUgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBT
ZWN1cmUgWGVuIG9uIEFSTSBhcmNoaXRlY3R1cmUgZGVzaWduZWQgYnkgU2FuZy1idW0gU3Vo
IGNvbnNpc3RzIG9mIAorICogWGVuIG9uIEFSTSBhbmQgdGhlIGFzc29jaWF0ZWQgYWNjZXNz
IGNvbnRyb2wuCisgKiAKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBw
dWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICog
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi
ZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1Mg
Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUg
cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICog
YWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMw
LCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2Nv
bmZpZy5oPgorI2luY2x1ZGUgPHhlbi9zcGlubG9jay5oPgorI2luY2x1ZGUgPHhlbi9saWIu
aD4KKyNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+Cisj
aW5jbHVkZSA8eGVuL3NtcC5oPgorI2luY2x1ZGUgPHhlbi9pcnEuaD4KKyNpbmNsdWRlIDx4
ZW4vbW0uaD4KKyNpbmNsdWRlIDxhc20vbW11Lmg+CisjaW5jbHVkZSA8YXNtL3BsYXRmb3Jt
Lmg+CisjaW5jbHVkZSA8YXNtL2dpYy5oPgorI2luY2x1ZGUgPGFzbS9yZWdzLmg+CisjaW5j
bHVkZSA8YXNtL2lvLmg+CisjaW5jbHVkZSA8YXNtL2ZsdXNodGxiLmg+CisjaW5jbHVkZSA8
YXNtL2FyY2gvdGVncmEuaD4KKyNpbmNsdWRlIDxhc20vYXJjaC9pcnFzLmg+CisKKyNkZWZp
bmUgVEVHUkEyNTBfTUVNT1JZX0JBU0UgICAgIDB4MDAwMDAwMDBVTAorI2RlZmluZSBURUdS
QTI1MF9NRU1PUllfU0laRSAgICAgMHg0MDAwMDAwMFVMCisKKyNkZWZpbmUgVEVHUkEyNTBf
REVWX0JBU0UgICAgICAgIDB4NTAwMDAwMDBVTAorI2RlZmluZSBURUdSQTI1MF9ERVZfU0la
RSAgICAgICAgMHgwMDMwMDAwMFVMCisKK0RFQ0xBUkVfTUVNT1JZX01BUCh0ZWdyYTI1MCkg
PSB7CisgICAgICAgIE1FTU1BUF9FTlRSWShURUdSQTI1MF9NRU1PUllfQkFTRSwgVEVHUkEy
NTBfTUVNT1JZX1NJWkUsIE1FTU9SWV9UWVBFX1JBTSwgTDFFX1RZUEVfSFlQRVJWSVNPUiks
CisgICAgICAgIE1FTU1BUF9FTlRSWShURUdSQTI1MF9ERVZfQkFTRSwgICAgVEVHUkEyNTBf
REVWX1NJWkUsICAgIE1FTU9SWV9UWVBFX0RFViwgTDFFX1RZUEVfREVWSUNFKQorfTsKKwor
Ly8gUmVnaXN0ZXIgQVBCRE1BX0lSUV9NQVNLX0NMUl8wCisjZGVmaW5lIEFQQkRNQV9JUlFf
U1RBX0NQVV8wCSgweDE0KQorI2RlZmluZSBBUEJETUFfSVJRX01BU0tfU0VUXzAJKDB4MjAp
CisjZGVmaW5lIEFQQkRNQV9JUlFfTUFTS19DTFJfMAkoMHgyNCkKKwordm9pZCAqdGVncmFf
Z2ljX2NwdV9iYXNlW01BWF9QSFlTX0NQVVNdICA9IHswLCAwfTsKK3ZvaWQgKnRlZ3JhX2dp
Y19kaXN0X2Jhc2UgPSAwOworCitzdHJ1Y3QgdGVncmFfaXJxX2N0cmwgeworCXVuc2lnbmVk
IGludCBpcnFfc3RhcnQ7CisJdm9pZCAgKnJlZzsKK307CisKK3N0YXRpYyBzdHJ1Y3QgdGVn
cmFfaXJxX2N0cmwgdGVncmFfaXJxX2N0cmxbKElOVF9TWVNfTlIgKyBJTlRfU1lTX1NaIC0g
MSkgLyBJTlRfU1lTX1NaXTsKKworI2RlZmluZSBnaWNfaXJxKGlycSkJKGlycSkKKworc3Rh
dGljIHZvaWQgdGVncmFfbWFzayhzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpCit7CisJc3RydWN0
IHRlZ3JhX2lycV9jdHJsICpjaGlwOworCXVuc2lnbmVkIGludCBpcnEgPSBkZXNjX3RvX2ly
cShkZXNjKTsKKwl1bnNpZ25lZCBpbnQgbWFzayA9IDEgPDwgKGlycSAlIDMyKTsKKworCW1t
aW9fd3JpdGVsKG1hc2ssIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNESUNFUiArIChnaWNf
aXJxKGlycSkgLyAzMikgKiA0KTsKKworCWlycSAtPSBJTlRfUFJJX0JBU0U7CisJY2hpcCA9
ICZ0ZWdyYV9pcnFfY3RybFtpcnEgLyBJTlRfU1lTX1NaXTsKKwltbWlvX3dyaXRlbCgxIDw8
IChpcnEgJiAzMSksIGNoaXAtPnJlZyArIElDVExSX0NQVV9JRVJfQ0xSXzApOworfQorCitz
dGF0aWMgdm9pZCB0ZWdyYV91bm1hc2soc3RydWN0IGlycV9kZXNjICpkZXNjKQoreworCXN0
cnVjdCB0ZWdyYV9pcnFfY3RybCAqY2hpcDsKKwl1bnNpZ25lZCBpbnQgaXJxID0gZGVzY190
b19pcnEoZGVzYyk7CisJdW5zaWduZWQgaW50IG1hc2sgPSAxIDw8IChpcnEgJSAzMik7CisK
KwltbWlvX3dyaXRlbChtYXNrLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElTRVIgKyAo
Z2ljX2lycShpcnEpIC8gMzIpICogNCk7CisKKwlpcnEgLT0gSU5UX1BSSV9CQVNFOworCWNo
aXAgPSAmdGVncmFfaXJxX2N0cmxbaXJxIC8gSU5UX1NZU19TWl07CisJbW1pb193cml0ZWwo
MSA8PCAoaXJxICYgMzEpLCBjaGlwLT5yZWcgKyBJQ1RMUl9DUFVfSUVSX1NFVF8wKTsKK30K
Kworc3RhdGljIHZvaWQgdGVncmFfYWNrKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykKK3sKKwl1
bnNpZ25lZCBpbnQgaXJxID0gZGVzY190b19pcnEoZGVzYyk7CisJdW5zaWduZWQgaW50IG1h
c2sgPSAxIDw8IChpcnEgJSAzMik7CisJdW5zaWduZWQgaW50IGNwdSA9IHNtcF9wcm9jZXNz
b3JfaWQoKTsKKworCXRlZ3JhX21hc2soZGVzYyk7CisKKyAgICAgICAgbW1pb193cml0ZWwo
bWFzaywgdGVncmFfZ2ljX2Rpc3RfYmFzZSArIF9JQ0RJQ0VSICsgKGdpY19pcnEoaXJxKSAv
IDMyKSAqIDQpOworICAgICAgICBtbWlvX3dyaXRlbChnaWNfaXJxKGlycSksIHRlZ3JhX2dp
Y19jcHVfYmFzZVtjcHVdICsgX0lDQ0VPSVIpOworfQorCitzdGF0aWMgdm9pZCB0ZWdyYV9l
bmQoc3RydWN0IGlycV9kZXNjICpkZXNjKQoreworCXRlZ3JhX3VubWFzayhkZXNjKTsKK30K
KworaHdfaXJxX2NvbnRyb2xsZXIgdGVncmFfaXJxX2NvbnRyb2xsZXIgPSB7CisJLnR5cGVu
YW1lID0gImxldmVsIiwKKwkuc3RhcnR1cCAgPSB0ZWdyYV91bm1hc2ssCisJLnNodXRkb3du
ID0gdGVncmFfbWFzaywKKwkuZW5hYmxlCSAgPSB0ZWdyYV91bm1hc2ssCisJLmRpc2FibGUg
ID0gdGVncmFfbWFzaywKKwkuYWNrCSAgPSB0ZWdyYV9hY2ssCisJLmVuZAkgID0gdGVncmFf
ZW5kLAorfTsKKworc3RhdGljIHZvaWQgdGVncmEyNTBfaXJxX2luaXQoKQoreworCXVuc2ln
bmVkIGludCBtYXhfaXJxLCBpOworCXVuc2lnbmVkIGludCBjcHUgPSBzbXBfcHJvY2Vzc29y
X2lkKCk7CisJdW5zaWduZWQgbG9uZyBjcHVtYXNrID0gMSA8PCBjcHU7CisKKwlmb3IgKGkg
PSAwOyBpIDwgQVJSQVlfU0laRSh0ZWdyYV9pcnFfY3RybCk7IGkrKykgeworCQl0ZWdyYV9p
cnFfY3RybFtpXS5pcnFfc3RhcnQgPSBJTlRfUFJJX0JBU0UgKyBJTlRfU1lTX1NaICogaTsK
KwkJdGVncmFfaXJxX2N0cmxbaV0ucmVnID0gSU9fQUREUkVTUyhJTlRfUFBJX0FERFJFU1Mo
aSkpOworCQltbWlvX3dyaXRlbCgweEZGRkZGRkZGLCB0ZWdyYV9pcnFfY3RybFtpXS5yZWcg
KyBJQ1RMUl9DUFVfSUVSX0NMUl8wKTsKKwkJbW1pb193cml0ZWwoMHgwMDAwMDAwMCwgdGVn
cmFfaXJxX2N0cmxbaV0ucmVnICsgSUNUTFJfQ1BVX0lFUF9DTEFTU18wKTsKKwl9CisKKwlm
b3IgKGkgPSBJTlRfUFJJX0JBU0U7IGkgPCBJTlRfR1BJT19CQVNFOyBpKyspIHsKKwkJaXJx
X2Rlc2NbaV0uaGFuZGxlciA9ICZ0ZWdyYV9pcnFfY29udHJvbGxlcjsKKwl9CisKKwljcHVt
YXNrIHw9IGNwdW1hc2sgPDwgODsKKwljcHVtYXNrIHw9IGNwdW1hc2sgPDwgMTY7CisKKwl0
ZWdyYV9naWNfZGlzdF9iYXNlID0gSU9fQUREUkVTUyhURUdSQV9BUk1fSU5UX0RJU1RfQkFT
RSk7CisJdGVncmFfZ2ljX2NwdV9iYXNlW2NwdV0gPSBJT19BRERSRVNTKFRFR1JBX0dJQ19Q
Uk9DX0lGX0JBU0UpOworCisJbW1pb193cml0ZWwoMCwgdGVncmFfZ2ljX2Rpc3RfYmFzZSAr
IF9JQ0REQ1IpOworCQorICAgICAgICAvKgorICAgICAgICAgKiBGaW5kIG91dCBob3cgbWFu
eSBpbnRlcnJ1cHRzIGFyZSBzdXBwb3J0ZWQuCisgICAgICAgICAqLworICAgICAgICBtYXhf
aXJxID0gbW1pb19yZWFkbCh0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDVFIpICYgMHgx
ZjsKKyAgICAgICAgbWF4X2lycSA9IChtYXhfaXJxICsgMSkgKiAzMjsKKworICAgICAgICAv
KgorICAgICAgICAgKiBUaGUgR0lDIG9ubHkgc3VwcG9ydHMgdXAgdG8gMTAyMCBpbnRlcnJ1
cHQgc291cmNlcy4KKyAgICAgICAgICogTGltaXQgdGhpcyB0byBlaXRoZXIgdGhlIGFyY2hp
dGVjdGVkIG1heGltdW0sIG9yIHRoZQorICAgICAgICAgKiBwbGF0Zm9ybSBtYXhpbXVtLgor
ICAgICAgICAgKi8KKyAgICAgICAgaWYgKG1heF9pcnEgPiBtYXgoMTAyMCwgTlJfSVJRUykp
CisgICAgICAgICAgICAgICAgbWF4X2lycSA9IG1heCgxMDIwLCBOUl9JUlFTKTsKKworICAg
ICAgICAvKgorICAgICAgICAgKiBTZXQgYWxsIGdsb2JhbCBpbnRlcnJ1cHRzIHRvIGJlIGxl
dmVsIHRyaWdnZXJlZCwgYWN0aXZlIGxvdy4KKyAgICAgICAgICovCisgICAgICAgIGZvciAo
aSA9IDMyOyBpIDwgbWF4X2lycTsgaSArPSAxNikKKyAgICAgICAgICAgICAgICBtbWlvX3dy
aXRlbCgwLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDRlIgKyBpICogNCAvIDE2KTsK
KworICAgICAgICAvKgorICAgICAgICAgKiBTZXQgYWxsIGdsb2JhbCBpbnRlcnJ1cHRzIHRv
IHRoaXMgQ1BVIG9ubHkuCisgICAgICAgICAqLworICAgICAgICBmb3IgKGkgPSAzMjsgaSA8
IG1heF9pcnE7IGkgKz0gNCkKKyAgICAgICAgICAgICAgICBtbWlvX3dyaXRlbChjcHVtYXNr
LCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElQVFIgKyBpICogNCAvIDQpOworICAgICAg
ICAvKgorICAgICAgICAgKiBTZXQgcHJpb3JpdHkgb24gYWxsIGludGVycnVwdHMuCisgICAg
ICAgICAqLworICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbWF4X2lycTsgaSArPSA0KQorICAg
ICAgICAgICAgICAgIG1taW9fd3JpdGVsKDB4YTBhMGEwYTAsIHRlZ3JhX2dpY19kaXN0X2Jh
c2UgKyBfSUNESVBSICsgaSAqIDQgLyA0KTsKKworICAgICAgICAvKgorICAgICAgICAgKiBE
aXNhYmxlIGFsbCBpbnRlcnJ1cHRzLgorICAgICAgICAgKi8KKyAgICAgICAgZm9yIChpID0g
MDsgaSA8IG1heF9pcnE7IGkgKz0gMzIpCisgICAgICAgICAgICAgICAgbW1pb193cml0ZWwo
MHhmZmZmZmZmZiwgdGVncmFfZ2ljX2Rpc3RfYmFzZSArIF9JQ0RJQ0VSICsgaSAqIDQgLyAz
Mik7CisKKyAgICAgICAgbW1pb193cml0ZWwoMSwgdGVncmFfZ2ljX2Rpc3RfYmFzZSArIF9J
Q0REQ1IpOworCisgICAgICAgIG1taW9fd3JpdGVsKDB4ZjAsIHRlZ3JhX2dpY19jcHVfYmFz
ZVtjcHVdICsgX0lDQ1BNUik7CisgICAgICAgIG1taW9fd3JpdGVsKDEsIHRlZ3JhX2dpY19j
cHVfYmFzZVtjcHVdICsgX0lDQ0lDUik7CisKKworfQorCisjZGVmaW5lIENMS19SU1RfQ09O
VFJPTExFUl9SU1RfQ1BVX0NNUExYX0NMUl8wICAoMHgzNDQpCisjZGVmaW5lIENMS19SU1Rf
Q09OVFJPTExFUl9DTEtfQ1BVX0NNUExYXzAgICAgICAoMHg0YykKKyNkZWZpbmUgQ1BVX0NM
S19TVE9QKGNwdSkgICAgICAgICAgICAgICAgICAgICAgICgweDE8PCg4K2NwdSkpCisjZGVm
aW5lIENQVV9SRVNFVChjcHUpICAgICAgICAgICAgICAgICAgICAgICAgICAoMHgxMDExdWw8
PChjcHUpKQorCisjZGVmaW5lIEVWUF9DUFVfUkVTRVRfVkVDVE9SXzAgICAgICAgICAgCSgw
eDEwMCkKKyNkZWZpbmUgRkxPV19DVFJMX0hBTFRfQ1BVeF9FVkVOVFMoY3B1KSAJKChjcHUp
ID8gKChjcHUgLSAxKSAqIDB4OCArIDB4MTQpIDogMHgwKQorCisKK3ZvbGF0aWxlIGludCB0
ZWdyYTI1MF9jb3JlX21hcCA9IDE7CisKK2FzbSgKKyIudHlwZSB0ZWdyYTI1MF9zbGF2ZV9j
cHVfc3RhcnQsICNmdW5jdGlvbglcbiIKKyIuZ2xvYmFsIHRlZ3JhMjUwX3NsYXZlX2NwdV9z
dGFydAkJXG4iCisidGVncmEyNTBfc2xhdmVfY3B1X3N0YXJ0OgkJCVxuIgorIgltc3IJY3Bz
cl9jLCAjMHhEMwkJCVxuIgorIgltb3YJcjAsICMwCQkJCVxuIgorIgltY3IJcDE1LCAyLCBy
MCwgYzAsIGMwLCAwCQlcbiIKKyIJbXJjCXAxNSwgMSwgcjAsIGMwLCBjMCwgMAkJXG4iCisi
CWxkcglyMSwgPTB4N0ZGRgkJCVxuIgorIglhbmQJcjIsIHIxLCByMCwgbHNyICMxMwkJXG4i
CisiCWxkcglyMSwgPTB4M0ZGCQkJXG4iCisiCWFuZAlyMywgcjEsIHIwLCBsc3IgIzMJCVxu
IgorIglhZGQJcjIsIHIyLCAjMQkJCVxuIgorIglhbmQJcjAsIHIwLCAjMHgwNwkJCVxuIgor
IglhZGQJcjAsIHIwLCAjNAkJCVxuIgorIgljbHoJcjEsIHIzCQkJCVxuIgorIglhZGQJcjQs
IHIzLCAjMQkJCVxuIgorIjE6CXN1YglyMiwgcjIsICMxCQkJXG4iCisiCW1vdglyMywgcjQJ
CQkJXG4iCisiMjoJc3VicwlyMywgcjMsICMxCQkJXG4iCisiCW1vdglyNSwgcjMsIGxzbCBy
MQkJCVxuIgorIgltb3YJcjYsIHIyLCBsc2wgcjAJCQlcbiIKKyIJb3JyCXI1LCByNSwgcjYJ
CQlcbiIKKyIJbWNyCXAxNSwgMCwgcjUsIGM3LCBjNiwgMgkJXG4iCisiCWJndAkyYgkJCQlc
biIKKyIJY21wCXIyLCAjMAkJCQlcbiIKKyIJYmd0CTFiCQkJCVxuIgorIglkc2IJCQkJCVxu
IgorIglpc2IJCQkJCVxuIgorIgltcmMJcDE1LCAwLCByMCwgYzAsIGMwLCA1CQlcbiIKKyIJ
YW5kCXIwLCByMCwgIzE1CQkJXG4iCisiCWFkcglyNCwgMWYJCQkJXG4iCisiCWxkbWlhCXI0
LCB7cjUsIHI2fQkJCVxuIgorIglzdWIJcjQsIHI0LCByNQkJCVxuIgorIglhZGQJcjYsIHI2
LCByNAkJCVxuIgorIgltb3YJcjEsICMxCQkJCVxuIgorIglsc2wJcjEsIHIxLCByMAkJCVxu
IgorInNwaW46CWxkcglyNywgW3I2XQkJCVxuIgorIgl0c3QJcjcsIHIxCQkJCVxuIgorIgli
ZXEJc3BpbgkJCQlcbiIKKyIJYglzbGF2ZV9jcHVfc3RhcnQJCQlcbiIKKyIxOgkubG9uZwku
CQkJCVxuIgorIgkubG9uZwl0ZWdyYTI1MF9jb3JlX21hcAkJXG4iCispOworCitpbnQgd2Fr
ZXVwX2NwdSh1bnNpZ25lZCBpbnQgY3B1KQoreworCXRlZ3JhMjUwX2NvcmVfbWFwIHw9IDEg
PDwgIGNwdTsKKworCWNwdV9mbHVzaF9jYWNoZV9hbGwoKTsKKworCXJldHVybiAwOworfQor
CitleHRlcm4gdm9pZCB0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQodm9pZCk7CisKK3N0YXRp
YyB2b2lkIHRlZ3JhMjUwX2V2cF9pbml0KHZvaWQpCit7CisJdW5zaWduZWQgbG9uZyByLCBv
cmcsIGxvb3AsIGN0cmw7CisKKwkvKiBJbml0aWFsaXplIFNub29wIENvbnRyb2wgVW5pdCAq
LworCWN0cmwgPSBtbWlvX3JlYWRsKElPX0FERFJFU1MoVEVHUkFfU0NVX0JBU0UpICsgMHgw
KTsKKwljdHJsIHw9IDE7CisJbW1pb193cml0ZWwoY3RybCwgSU9fQUREUkVTUyhURUdSQV9T
Q1VfQkFTRSkgKyAweDApOworCisJb3JnID0gbW1pb19yZWFkbChJT19BRERSRVNTKFRFR1JB
X0VYQ0VQVElPTl9WRUNUT1JTX0JBU0UpICsgRVZQX0NQVV9SRVNFVF9WRUNUT1JfMCk7CisK
KwkvKiBTZXQgYm9vdCBlbnRyeSAqLworCW1taW9fd3JpdGVsKF9fcGEodGVncmEyNTBfc2xh
dmVfY3B1X3N0YXJ0KSwgSU9fQUREUkVTUyhURUdSQV9FWENFUFRJT05fVkVDVE9SU19CQVNF
KSArIEVWUF9DUFVfUkVTRVRfVkVDVE9SXzApOworCisJZHNiKCk7CisJaXNiKCk7CisKKwkv
KiBIYWx0IENQVSAqLworCW1taW9fd3JpdGVsKDAsIElPX0FERFJFU1MoVEVHUkFfRkxPV19D
VFJMX0JBU0UpICsgRkxPV19DVFJMX0hBTFRfQ1BVeF9FVkVOVFMoMSkpOworCisJZHNiKCk7
CisJaXNiKCk7CisKKwkvKiBDUFUgQ2xvY2sgU3RvcCAqLworCXIgPSBtbWlvX3JlYWRsKElP
X0FERFJFU1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpICsgQ0xLX1JTVF9DT05UUk9MTEVSX0NM
S19DUFVfQ01QTFhfMCk7CisJciAmPSB+Q1BVX0NMS19TVE9QKDEpOworCW1taW9fd3JpdGVs
KHIsIElPX0FERFJFU1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpICsgQ0xLX1JTVF9DT05UUk9M
TEVSX0NMS19DUFVfQ01QTFhfMCk7CisKKwlkc2IoKTsKKwlpc2IoKTsKKworCS8qIFJlc3Rh
cnQgU2xhdmUgQ1BVICovCisJbW1pb193cml0ZWwoQ1BVX1JFU0VUKDEpLCBJT19BRERSRVNT
KFRFR1JBX0NMS19SRVNFVF9CQVNFKSArIENMS19SU1RfQ09OVFJPTExFUl9SU1RfQ1BVX0NN
UExYX0NMUl8wKTsKKworCWRzYigpOworCWlzYigpOworCisgICAgICAgIC8qIFdhaXQgdXRp
bCB0aGUgcG93ZXIgdW5pdCBpcyBpbiBzdGFibGUgKi8KKyAgICAgICAgbG9vcCA9IDEwMDAw
OworICAgICAgICB3aGlsZSgoLS1sb29wKSA+IDAgKTsKK30KKwordm9pZCB0ZWdyYTI1MF9p
b3JlbWFwKHZvaWQpCit7CisJbWFwX3BhZ2VzX3RvX3hlbihJT19BRERSRVNTKFRFR1JBX0FS
TV9DUFVfQkFTRSksCisJCVRFR1JBX0FSTV9DUFVfQkFTRSA+PiBQQUdFX1NISUZULCAweDEw
MDAwMCA+PiBQQUdFX1NISUZULAorCQlMMUVfVFlQRV9ERVZJQ0UpOworCisJbWFwX3BhZ2Vz
X3RvX3hlbihJT19BRERSRVNTKFRFR1JBX1BQU0JfREVWSUNFX0JBU0UpLAorCQlURUdSQV9Q
UFNCX0RFVklDRV9CQVNFID4+IFBBR0VfU0hJRlQsIDB4MTAwMDAwID4+IFBBR0VfU0hJRlQs
IAorCQlMMUVfVFlQRV9ERVZJQ0UpOworCisJbWFwX3BhZ2VzX3RvX3hlbihJT19BRERSRVNT
KFRFR1JBX0FQQl9ERVZJQ0VfQkFTRSksCisJCVRFR1JBX0FQQl9ERVZJQ0VfQkFTRSA+PiBQ
QUdFX1NISUZULCAweDEwMDAwMCA+PiBQQUdFX1NISUZULAorCQlMMUVfVFlQRV9ERVZJQ0Up
OworfQorCitpbnQgbWFjaGluZV9zZXR1cCh2b2lkKQoreworCWNwdV90b3BvbG9neV9pbml0
KDIpOworCisJdGVncmEyNTBfaW9yZW1hcCgpOworCisJdGVncmEyNTBfZXZwX2luaXQoKTsK
KworCXRlZ3JhMjUwX2lycV9pbml0KCk7CisKKwl0ZWdyYTI1MF90aW1lcl9pbml0KCk7CisK
KwlyZXR1cm4gMDsKK30KKwpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0vdGVn
cmEvdGltZXIuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MAorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvdGltZXIuYwlTdW4gRmViIDEyIDE1OjA0OjA2
IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMTAgQEAKKy8qCisgKiBhcmNoL2FybS9tYWNoLXRl
Z3JhL3RpbWVyLmMKKyAqCisgKiBUaW1lciBhbmQgY2xvY2sgZXZlbnQgc3VwcG9ydCBmb3Ig
TlZJRElBIFRlZ3JhIFNvQ3MKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgtMjAwOSwgTlZJ
RElBIENvcnBvcmF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl
ZCBieQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24g
MiBvZiB0aGUgTGljZW5zZSwgb3IKKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZl
cnNpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl
IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFOVFk7
IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkg
b3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBhbG9uZworICogd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUg
dG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKKyAqIDUxIEZyYW5rbGlu
IFN0cmVldCwgRmlmdGggRmxvb3IsIEJvc3RvbiwgTUEgIDAyMTEwLTEzMDEsIFVTQS4KKyAq
LworCisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVuL2lycS5oPgorI2lu
Y2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL3NvZnRpcnEuaD4KKyNpbmNsdWRl
IDx4ZW4vc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20vdGltZS5oPgorI2luY2x1ZGUgPGFz
bS9hcmNoL2lycXMuaD4KKyNpbmNsdWRlIDxhc20vYXJjaC90ZWdyYS5oPgorCisKKyNkZWZp
bmUgQ0xLX1JTVF9DT05UUk9MTEVSX09TQ19DVFJMXzAJMHg1MAorCisjZGVmaW5lIFRJTUVS
MV9PRkZTCQkJMHgwMCAgLyogcmVzZXJ2ZWQgZm9yIEFWUCAqLworI2RlZmluZSBUSU1FUjJf
T0ZGUwkJCTB4MDggIC8qIHJlc2VydmVkIGZvciBBVlAgKi8KKyNkZWZpbmUgVElNRVIzX09G
RlMJCQkweDUwICAvKiB1c2VkIGFzIE9TIENQVSBldmVudCB0aW1lciAqLworI2RlZmluZSBU
SU1FUjRfT0ZGUwkJCTB4NTggIC8qIHJlc2VydmVkIGFzIExQMiB3YWtldXAgdHJpZ2dlciAq
LworCisjZGVmaW5lIFRJTUVSX1RNUl9QVFZfMAkJCTB4MAorI2RlZmluZSBUSU1FUl9UTVJf
UENSXzAJCQkweDQKKworI2RlZmluZSBUSU1FUlVTX09GRlMJCQkweDEwCisjZGVmaW5lIFRJ
TUVSVVNfQ05UUl8xVVNfMAkJMHgwCisjZGVmaW5lIFRJTUVSVVNfVVNFQ19DRkdfMAkJMHg0
CisKKyNkZWZpbmUgTlNFQ19QRVJfU0VDCQkJMTAwMDAwMDAwMEwKKwordm9pZCB0ZWdyYV9j
bG9ja2V2ZW50X2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBjcHVf
dXNlcl9yZWdzICpyZWdzKQoreworICAgICAgICBtbWlvX3dyaXRlbCgxIDw8IDMwLCBJT19B
RERSRVNTKFRFR1JBX1RNUjFfQkFTRSArIFRJTUVSM19PRkZTKSArIFRJTUVSX1RNUl9QQ1Jf
MCk7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgaXJxYWN0aW9uIHRlZ3JhX2Nsb2NrZXZlbnRfaXJx
ID0geworICAgICAgICAubmFtZSAgICAgICAgICAgPSAiVGltZXJfZXZlbnQiLAorICAgICAg
ICAuaGFuZGxlciAgICAgICAgPSB0ZWdyYV9jbG9ja2V2ZW50X2ludGVycnVwdCwKK307CisK
K3ZvaWQgdGVncmFfbHAyd2FrZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLCBz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKK3sKKyAgICAgICAgbW1pb193cml0ZWwoMTw8
MzAsIElPX0FERFJFU1MoVEVHUkFfVE1SMV9CQVNFICsgVElNRVI0X09GRlMpICsgVElNRVJf
VE1SX1BDUl8wKTsKK30KKworc3RhdGljIHN0cnVjdCBpcnFhY3Rpb24gdGVncmFfbHAyd2Fr
ZV9pcnEgPSB7CisgICAgICAgIC5uYW1lICAgICAgICAgICA9ICJ0aW1lcl9scDJ3YWtlIiwK
KyAgICAgICAgLmhhbmRsZXIgICAgICAgID0gdGVncmFfbHAyd2FrZV9pbnRlcnJ1cHQsCit9
OworCitzdGF0aWMgdW5zaWduZWQgbG9uZyBtZWFzdXJlX2lucHV0X2ZyZXEodW5zaWduZWQg
aW50ICptLCB1bnNpZ25lZCBpbnQgKm4pCit7CisJdm9pZCAqY2xrX3JzdCA9IElPX0FERFJF
U1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpOworCXVuc2lnbmVkIGxvbmcgb3NjID0gbW1pb19y
ZWFkbChjbGtfcnN0ICsgQ0xLX1JTVF9DT05UUk9MTEVSX09TQ19DVFJMXzApOworCW9zYyA+
Pj0gMzA7CisKKwlzd2l0Y2ggKG9zYykgeworCQljYXNlIDA6IGlmIChtICYmIG4pIHsgKm09
MTsgKm49MTM7IH0gcmV0dXJuIDEzMDAwOworCQljYXNlIDE6IGlmIChtICYmIG4pIHsgKm09
NTsgKm49OTY7IH0gcmV0dXJuIDE5MjAwOworCQljYXNlIDI6IGlmIChtICYmIG4pIHsgKm09
MTsgKm49MTI7IH0gcmV0dXJuIDEyMDAwOworCQljYXNlIDM6IGlmIChtICYmIG4pIHsgKm09
MTsgKm49MjY7IH0gcmV0dXJuIDI2MDAwOworCX0KKworCXJldHVybiAwOworfQorCit2b2lk
IHRlZ3JhMjUwX3RpbWVyX2luaXQodm9pZCkKK3sKKyAgICAgICAgdm9pZCAqdG1yOworICAg
ICAgICB1bnNpZ25lZCBpbnQgbSwgbjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyB2YWw7Cisg
ICAgICAgIHUzMiByZWc7CisKKyAgICAgICAgdG1yID0gSU9fQUREUkVTUyhURUdSQV9UTVIx
X0JBU0UgKyBUSU1FUlVTX09GRlMpOworICAgICAgICB2YWwgPSBtZWFzdXJlX2lucHV0X2Zy
ZXEoJm0sICZuKTsKKworICAgICAgICB2YWwgPSAoKG0tMSk8PDgpIHwgKG4tMSk7CisKKyAg
ICAgICAgbW1pb193cml0ZWwodmFsLCB0bXIgKyBUSU1FUlVTX1VTRUNfQ0ZHXzApOworICAg
ICAgICBtbWlvX3dyaXRlbCgwLCBJT19BRERSRVNTKFRFR1JBX1RNUjFfQkFTRSArIFRJTUVS
M19PRkZTKSAgKyBUSU1FUl9UTVJfUFRWXzApOworCisgICAgICAgIHJlZyA9IDB4YzAwMDI3
MGY7CisgICAgICAgIG1taW9fd3JpdGVsKHJlZywgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JB
U0UgKyBUSU1FUjNfT0ZGUykgKyBUSU1FUl9UTVJfUFRWXzApOworCisgICAgICAgIGlmIChz
ZXR1cF9pcnEoSU5UX1RNUjMsICZ0ZWdyYV9jbG9ja2V2ZW50X2lycSkpIHsKKyAgICAgICAg
ICAgICAgICBCVUcoKTsKKyAgICAgICAgfQorICAgICAgICBpZiAoc2V0dXBfaXJxKElOVF9U
TVI0LCAmdGVncmFfbHAyd2FrZV9pcnEpKSB7CisgICAgICAgICAgICAgICAgQlVHKCk7Cisg
ICAgICAgIH0KK30KKwpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0veGVuL2Nw
dS5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxMjoyNDoyMSAy
MDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxNTow
NDowNiAyMDEyICswOTAwCkBAIC01Myw2ICs1MywxMSBAQCBpbnQgX19jcHVfdXAodW5zaWdu
ZWQgaW50IGNwdSkKIHsKIAlpbnQgcmV0ID0gMDsKIAorCXJldCA9IHdha2V1cF9jcHUoY3B1
KTsKKwlpZiAoIXJldCkgeworCQlyZXR1cm4gLUVJTlZBTDsKKwl9CisKIAl3aGlsZSghY3B1
X29ubGluZShjcHUpKSB7CiAJCWNwdV9yZWxheCgpOwogCQlwcm9jZXNzX3BlbmRpbmdfc29m
dGlycXMoKTsKZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5j
Ci0tLSBhL3hlbi9hcmNoL2FybS94ZW4vZmF1bHQuYwlTdW4gRmViIDEyIDEyOjI0OjIxIDIw
MTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5jCVN1biBGZWIgMTIgMTU6
MDQ6MDYgMjAxMiArMDkwMApAQCAtMzMsNyArMzMsNiBAQAogI2luY2x1ZGUgPGFzbS9wcm9j
ZXNzb3IuaD4NCiAjaW5jbHVkZSA8YXNtL2d1ZXN0X2FjY2Vzcy5oPg0KICNpbmNsdWRlIDxh
c20vc3lzdGVtLmg+DQotI2luY2x1ZGUgPGFzbS9tZW1vcnkuaD4NCiANCiBhc21saW5rYWdl
IHZvaWQgX19kaXYwKHZvaWQpDQogew0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gv
YXJtL3hlbi9pcnEuYwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2lycS5jCVN1biBGZWIgMTIg
MTI6MjQ6MjEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2lycS5jCVN1biBG
ZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMApAQCAtMzgsOSArMzgsMjcgQEAgaHdfaXJxX2Nv
bnRyb2xsZXIgbm9faXJxX3R5cGUgPSB7CiAJLnNodXRkb3duID0gaXJxX3NodXRkb3duX25v
bmUsCiAJLmVuYWJsZSAgID0gaXJxX2VuYWJsZV9ub25lLAogCS5kaXNhYmxlICA9IGlycV9k
aXNhYmxlX25vbmUsCisJLmVuZAkgID0gaXJxX2VuZF9ub25lLAorCS5hY2sJICA9IGlycV9h
Y2tfbm9uZSwKIH07CiAKLXN0cnVjdCBpcnFfZGVzYyAqaXJxX2Rlc2M7CisvL3N0cnVjdCBp
cnFfZGVzYyAqaXJxX2Rlc2M7CisKK2lycV9kZXNjX3QgaXJxX2Rlc2NbTlJfSVJRU10gPSB7
CisgICAgICAgIFswIC4uLiBOUl9JUlFTIC0gMV0gPSB7CisgICAgICAgICAgICAgICAgLnN0
YXR1cyA9IElSUV9ESVNBQkxFRCwKKyAgICAgICAgICAgICAgICAuaGFuZGxlciA9ICZub19p
cnFfdHlwZSwKKyAgICAgICAgICAgICAgICAuYWN0aW9uID0gTlVMTCwKKyAgICAgICAgICAg
ICAgICAubG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRAorICAgICAgICB9Cit9OworCitzdHJ1
Y3QgaXJxX2NmZyBpcnFfY2ZnW05SX0lSUVNdID0geworICAgICAgICBbMCAuLi4gTlJfSVJR
UyAtIDFdID17CisgICAgICAgICAgICAgICAgLmlycSA9IDAKKyAgICAgICAgfQorfTsKKwog
CiBpbnQgcGlycV9ndWVzdF91bm1hc2soc3RydWN0IGRvbWFpbiAqZCkKIHsKQEAgLTc1LDYg
KzkzLDMyIEBAIHN0cnVjdCBwaXJxICphbGxvY19waXJxX3N0cnVjdChzdHJ1Y3QgZG8KIAly
ZXR1cm4gTlVMTDsKIH0KIAoraW50IHNldHVwX2lycSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1
Y3QgaXJxYWN0aW9uICpuZXcpCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwlzdHJ1Y3Qg
aXJxX2Rlc2MgKmRlc2M7CisKKwlpZihpcnEgPj0gTlJfSVJRUykgeworCQlwcmludGsoIkJB
RCBJUlEgPSAlZFxuIiwgaXJxKTsKKwl9CisKKwlkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsK
KworCXNwaW5fbG9ja19pcnFzYXZlKCZkZXNjLT5sb2NrLCBmbGFncyk7CisJZGVzYy0+YWN0
aW9uID0gbmV3OworCWlmIChkZXNjLT5oYW5kbGVyKSB7CisJCWlmIChkZXNjLT5oYW5kbGVy
LT5zdGFydHVwKSB7CisJCQlkZXNjLT5oYW5kbGVyLT5zdGFydHVwKGRlc2MpOworCQl9IGVs
c2UgaWYoZGVzYy0+aGFuZGxlci0+ZW5hYmxlKSB7CisJCQlkZXNjLT5oYW5kbGVyLT5lbmFi
bGUoZGVzYyk7CisJCX0KKwl9CisKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZkZXNjLT5s
b2NrLCBmbGFncyk7CisKKwlyZXR1cm4gMDsKK30KKwogaW50IGFyY2hfaW5pdF9vbmVfaXJx
X2Rlc2Moc3RydWN0IGlycV9kZXNjICpkZXNjKQogewogCU5PVF9ZRVQoKTsKZGlmZiAtciA2
YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3hlbi9tbS5jCi0tLSBhL3hlbi9hcmNoL2FybS94
ZW4vbW0uYwlTdW4gRmViIDEyIDEyOjI0OjIxIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9tbS5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMApAQCAtMjU1LDMg
KzI1NSwyNyBAQCBpbnQgYWxsb2NfcGFnZV9tYXAodW5zaWduZWQgbG9uZyB2aXJ0LCB1CiAJ
cmV0dXJuIDA7CiB9CiAKK2ludCBtYXBfcGFnZXNfdG9feGVuKHVuc2lnbmVkIGxvbmcgdmly
dCwgdW5zaWduZWQgbG9uZyBtZm4sIGludCBuciwgdW5zaWduZWQgbG9uZyBmbGFncykKK3sK
KyAgICAgICAgdW5zaWduZWQgbG9uZyB2YWRkciA9IHJvdW5kX2Rvd24odmlydCwgUEFHRV9T
SVpFKTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBtYWRkciA9IG1mbiA8PCBQQUdFX1NISUZU
OworICAgICAgICB1bnNpZ25lZCBpbnQgZW5kID0gdmlydCArIChuciA8PCBQQUdFX1NISUZU
KTsKKworICAgICAgICBsMWVfdCAqbDFlID0gbDFfbGluZWFyX29mZnNldF94ZW4odmFkZHIp
OworCisgICAgICAgIGRvIHsKKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIGxpbWl0
ID0gKHZhZGRyICsgU0VDVElPTl9TSVpFKSAmIChTRUNUSU9OX01BU0spOworICAgICAgICAg
ICAgICAgIGxpbWl0ID0gKGxpbWl0IDwgZW5kKSA/IGxpbWl0IDogZW5kOworCisgICAgICAg
ICAgICAgICAgaWYgKCgodmFkZHIgfCBtYWRkciB8IGxpbWl0KSAmIH5TRUNUSU9OX01BU0sp
ID09IDApIHsKKyAgICAgICAgICAgICAgICAgICAgICAgICpsMWUgPSBNS19MMUUobWFkZHIs
IGZsYWdzKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIHB0ZV9zeW5jKGwxZSk7CisKKyAg
ICAgICAgICAgICAgICAgICAgICAgIHZhZGRyICs9IFNFQ1RJT05fU0laRTsKKyAgICAgICAg
ICAgICAgICAgICAgICAgIG1hZGRyICs9IFNFQ1RJT05fU0laRTsKKyAgICAgICAgICAgICAg
ICB9CisgICAgICAgIH0gd2hpbGUobDFlKyssIHZhZGRyIDwgZW5kKTsKKworICAgICAgICBy
ZXR1cm4gMDsKK30KKwpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0veGVuL3Nl
dHVwLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCVN1biBGZWIgMTIgMTI6MjQ6
MjEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMJU3VuIEZlYiAx
MiAxNTowNDowNiAyMDEyICswOTAwCkBAIC02NCwxMSArNjQsMTEgQEAgc3RhdGljIHVuc2ln
bmVkIGludCBkb20wX3NpemUgPSAyNTYgKiAxMAogaW50ZWdlcl9wYXJhbSgiZG9tMF9zaXpl
IiwgZG9tMF9zaXplKTsKIAogLy9zdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3N0
YXJ0ID0gMHg0MEIwMDAwMFVMOwotc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFnZV9z
dGFydCA9IDB4MDBCMDAwMDBVTDsKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c3RhcnQgPSAweEEwMDAwMFVMOwogaW50ZWdlcl9wYXJhbSgiaW1hZ2Vfc3RhcnQiLCBkb20w
X2ltYWdlX3N0YXJ0KTsKIAogLy9zdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3Np
emUgPSAweEEwMDAwMFVMOwotc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFnZV9zaXpl
ID0gMHhBMDAwMDBVTDsKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vfc2l6ZSA9
IDB4MTQwMDAwMFVMOwogaW50ZWdlcl9wYXJhbSgiaW1hZ2VfbGVuZ3RoIiwgZG9tMF9pbWFn
ZV9zaXplKTsKIAogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVzX2lu
Zm9fdCAqaW5mbykKQEAgLTIxMSw2ICsyMTEsOCBAQCBhc21saW5rYWdlIHZvaWQgc3RhcnRf
eGVuKHZvaWQpCiAKIAl0YXNrbGV0X3N1YnN5c19pbml0KCk7CiAKKwltYWNoaW5lX3NldHVw
KCk7CisKIAl0aW1lcl9pbml0KCk7CiAKIAlpZGxlX2RvbWFpbl9pbml0KCk7CmRpZmYgLXIg
NmFmOGE4OWM5OWNkIHhlbi9hcmNoL2FybS94ZW4vdGltZS5jCi0tLSBhL3hlbi9hcmNoL2Fy
bS94ZW4vdGltZS5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMAorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3RpbWUuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAg
LTc5LDUgKzc5LDQgQEAgdm9pZCBkb21haW5fc2V0X3RpbWVfb2Zmc2V0KHN0cnVjdCBkb21h
aQogCiB2b2lkIHRpbWVrZWVwaW5nX2luaXQodm9pZCkKIHsKLQlOT1RfWUVUKCk7CiB9CmRp
ZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jCi0tLSBhL3hl
bi9kcml2ZXJzL2NoYXIvY29uc29sZS5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkw
MAorKysgYi94ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYwlTdW4gRmViIDEyIDE1OjA0OjA2
IDIwMTIgKzA5MDAKQEAgLTQxMiw3ICs0MTIsMTEgQEAgbG9uZyBkb19jb25zb2xlX2lvKGlu
dCBjbWQsIGludCBjb3VudCwgWAogICogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioKICAqLwogCisjaWYgZGVmaW5lZChfX2FybV9fKQor
c3RhdGljIGJvb2xfdCBjb25zb2xlX2xvY2tzX2J1c3RlZCA9IDE7CisjZWxzZQogc3RhdGlj
IGJvb2xfdCBjb25zb2xlX2xvY2tzX2J1c3RlZDsKKyNlbmRpZgogCiBzdGF0aWMgdm9pZCBf
X3B1dHN0cihjb25zdCBjaGFyICpzdHIpCiB7CmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9p
bmNsdWRlL2FzbS1hcm0vZ2ljLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9naWMuaAlTdW4gRmViIDEy
IDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMDEgQEAKKy8qCisgKiBnaWMuaAor
ICoKKyAqIENvcHlyaWdodCAoQykgMjAxMSBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAg
ICAgICBKYWVtaW4gUnl1ICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9v
ciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVi
bGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzCisgKiBwdWJsaXNoZWQgYnkgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0
ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VU
IEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Uu
ICBTZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRh
aWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsg
aWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwgSW5j
LiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcg
IFVTQQorICovCisKKyNpZm5kZWYgX19BUk1fR0lDX0hfXworI2RlZmluZSBfX0FSTV9HSUNf
SF9fCisKKworLyogRGlzdHJpYnV0b3IgUmVnaXN0ZXIgTWFwICovCisjZGVmaW5lIF9JQ0RE
Q1IJCTB4MDAwICAvKiBEaXN0cmlidXRvciBDb250cm9sIFJlZ2lzdGVyICovCisjZGVmaW5l
IF9JQ0RJQ1RSCTB4MDA0ICAvKiBJbnRlcnJ1cHQgQ29udHJvbGxlciBUeXBlIFJlZ2lzdGVy
ICovCisjZGVmaW5lIF9JQ0RJSURSCTB4MDA4ICAvKiBEaXN0cmlidXRvciBJbXBsZW1lbnRl
ciBJZCBSZWdpc3RlciAqLworI2RlZmluZSBfSUNESVNSMAkweDA4MCAgLyogSW50ZXJydXB0
IFNlY3VyaXR5IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RJU1IxCTB4MDg0ICAvKiBJbnRl
cnJ1cHQgU2VjdXJpdHkgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDRElTUjIJMHgwODggIC8q
IEludGVycnVwdCBTZWN1cml0eSBSZWdpc3RlciAqLworI2RlZmluZSBfSUNESVNSMwkweDA4
YyAgLyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RJU1I0
CTB4MDkwICAvKiBJbnRlcnJ1cHQgU2VjdXJpdHkgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lD
RElTRVIJMHgxMDAgIC8qIEludGVycnVwdCBTZXQtRW5hYmxlIFJlZ2lzdGVyICovCisjZGVm
aW5lIF9JQ0RJQ0VSCTB4MTgwICAvKiBJbnRlcnJ1cHQgQ2xlYXItRW5hYmxlIFJlZ2lzdGVy
ICovCisjZGVmaW5lIF9JQ0RJU1BSCTB4MjAwICAvKiBJbnRlcnJ1cHQgU2V0LVBlbmRpbmcg
UmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDRElDUFIJMHgyODAgIC8qIEludGVycnVwdCBDbGVh
ci1QZW5kaW5nIFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RBQlIJCTB4MzAwICAvKiBBY3Rp
dmUgQml0IFJlZ2lzdGVycyAqLworI2RlZmluZSBfSUNESVBSCQkweDQwMCAgLyogSW50ZXJy
dXB0IFByaW9yaXR5IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RJUFRSCTB4ODAwICAvKiBJ
bnRlcnJ1cHQgUHJvY2Vzc29yIFRhcmdldHMgUmVnaXN0ZXJzICovCisjZGVmaW5lIF9JQ0RJ
Q0ZSCTB4QzAwICAvKiBJbnRlcnJ1cHQgQ29uZmlndXJhdGlvbiBSZWdpc3RlcnMgKi8KKyNk
ZWZpbmUgX0lDRFNHSVIJMHhGMDAgIC8qIFNvZnR3YXJlIEdlbmVyYXRlZCBJbnRlcnJ1cHQg
UmVnaXN0ZXIgKi8KKworI2RlZmluZSBJQ0REQ1IoKQkoX0lDRERDUikKKyNkZWZpbmUgSUNE
SUNUUigpCShfSUNESUNUUikKKyNkZWZpbmUgSUNESVNSKHgpCShfSUNESVNSMCArICh4IC8g
QklUU19QRVJfTE9ORykgKiBCWVRFU19QRVJfTE9ORykKKyNkZWZpbmUgSUNESVNFUih4KQko
X0lDRElTRVIgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xPTkcpCisjZGVm
aW5lIElDRElDRVIoeCkJKF9JQ0RJQ0VSICsgKHggLyBCSVRTX1BFUl9MT05HKSAqIEJZVEVT
X1BFUl9MT05HKQorI2RlZmluZSBJQ0RJU1BSKHgpCShfSUNESVNQUiArICh4IC8gQklUU19Q
RVJfTE9ORykgKiBCWVRFU19QRVJfTE9ORykKKyNkZWZpbmUgSUNESUNQUih4KQkoX0lDRElD
UFIgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xPTkcpCisjZGVmaW5lIElD
REFCUih4KQkoX0lDREFCUiAgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xP
TkcpCisjZGVmaW5lIElDRElQUih4KQkoX0lDRElQUiAgKyAoeCAvICA0KSAqIEJZVEVTX1BF
Ul9MT05HKQorI2RlZmluZSBJQ0RJUFRSKHgpCShfSUNESVBUUiArICh4IC8gIDQpICogQllU
RVNfUEVSX0xPTkcpCisjZGVmaW5lIElDRFNHSVIoKQkoX0lDRFNHSVIpCisKKy8qIENQVSBJ
bnRlcmZhY2UgUmVnaXN0ZXIgTWFwICovCisjZGVmaW5lIF9JQ0NJQ1IJCTB4MDAwICAvKiBD
UFUgSW50ZXJmYWNlIENvbnRyb2wgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDQ1BNUgkJMHgw
MDQgIC8qIEludGVycnVwdCBQcmlvcml0eSBNYXNrIFJlZ2lzdGVyICovCisjZGVmaW5lIF9J
Q0NCUFIJCTB4MDA4ICAvKiBCaW5yYXJ5IFBvaW50IFJlZ2lzdGVyICovCisjZGVmaW5lIF9J
Q0NJQVIJCTB4MDBDICAvKiBJbnRlcnJ1cHQgQWNrbm93bGVkZ2UgUmVnaXN0ZXIgKi8KKyNk
ZWZpbmUgX0lDQ0VPSVIJMHgwMTAgIC8qIEVuZCBvZiBJbnRlcnJ1cHQgUmVnaXN0ZXIgKi8K
KyNkZWZpbmUgX0lDQ1JQUgkJMHgwMTQgIC8qIFJ1bm5pbmcgUHJpb3JpdHkgUmVnaXN0ZXIg
Ki8KKyNkZWZpbmUgX0lDQ0hQSVIJMHgwMTggIC8qIEhpZ2hlc3QgUGVuZGluZyBJbnRlcnJ1
cHQgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDQ0FCUFIJMHgwMUMgIC8qIEFsaWFzZWQgQmlu
YXJ5IFBvaW50IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0NJSURSCTB4MEZDICAvKiBDUFUg
SW50ZXJmYWNlIElkIFJlZ2lzdGVyICovCisKKyNkZWZpbmUgSUNDSUNSKCkJKF9JQ0NJQ1Ip
CisjZGVmaW5lIElDQ1BNUigpCShfSUNDUE1SKQorI2RlZmluZSBJQ0NCUFIoKQkoX0lDQ0JQ
UikKKyNkZWZpbmUgSUNDSUFSKCkJKF9JQ0NJQVIpCisjZGVmaW5lIElDQ0VPSVIoKQkoX0lD
Q0VPSVIpCisjZGVmaW5lIElDQ1JQUigpCShfSUNDUlBSKQorI2RlZmluZSBJQ0NIUElSKCkJ
KF9JQ0NIUElSKQorI2RlZmluZSBJQ0NJSURSKCkJKF9JQ0NJSURSKQorCisjZGVmaW5lIFNF
Q1VSRV9JTlRFUlJVUFQJMAorI2RlZmluZSBOT05TRUNVUkVfSU5URVJSVVBUCTEKKworI2Rl
ZmluZSBTR0koeCkJCQkoeCkKKyNkZWZpbmUgUFBJKHgpCQkJKHggKyAxNikKKyNkZWZpbmUg
U1BJKHgpCQkJKHggKyAzMikKKworI2lmbmRlZiBfX0FTU0VNQkxZX18KKworI2luY2x1ZGUg
PHhlbi90eXBlcy5oPgorCisjZGVmaW5lIEdJQ19ESVNUUklCVVRPUih4KSAgICAgIChfZ2lj
X2Rpc3RyaWJ1dG9yX2Jhc2UgKyB4KQorI2RlZmluZSBHSUNfQ1BVX0lOVEVSRkFDRSh4KSAg
ICAoX2dpY19jcHVfYmFzZSArIHgpCisKK3ZvaWQgZ2ljX3NldF9jcHUodW5zaWduZWQgaW50
IGlycSwgdW5zaWduZWQgaW50IG1hc2spOwordm9pZCBnaWNfc2V0X2lycV9wcmlvcml0eSh1
bnNpZ25lZCBpbnQgaXJxLCB1bnNpZ25lZCBpbnQgcHJpb3JpdHkpOwordm9pZCBnaWNfYWNr
X2lycSh1bnNpZ25lZCBpbnQgaXJxKTsKK3ZvaWQgZ2ljX21hc2tfaXJxKHVuc2lnbmVkIGlu
dCBpcnEpOwordm9pZCBnaWNfdW5tYXNrX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsKK3ZvaWQg
Z2ljX2VuZF9pcnEodW5zaWduZWQgaW50IGlycSk7Cit2b2lkIGdpY19jaGFuZ2VfaXJxX3N0
YXRlKHVuc2lnbmVkIGludCBpcnEsIHVuc2lnbmVkIGludCBzdGF0ZSk7CisKK2V4dGVybiB2
b2lkICpfZ2ljX2NwdV9iYXNlW05SX0NQVVNdOworZXh0ZXJuIHZvaWQgKl9naWNfZGlzdHJp
YnV0b3JfYmFzZTsKKyNlbmRpZgorI2VuZGlmCmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9p
bmNsdWRlL2FzbS1hcm0vaXJxLmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9pcnEuaAlT
dW4gRmViIDEyIDEyOjI0OjIxIDIwMTIgKzA5MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFy
bS9pcnEuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAgLTE1LDYgKzE1LDcg
QEAKIAogI2RlZmluZSBpcnFfY2ZnKGlycSkJCSgmaXJxX2NmZ1tpcnFdKQogI2RlZmluZSBp
cnFfdG9fZGVzYyhpcnEpCSgmaXJxX2Rlc2NbaXJxXSkJCisjZGVmaW5lIGRlc2NfdG9faXJx
KGRlc2MpCSgoZGVzYyAtICZpcnFfZGVzY1swXSkgLyBzaXplb2Yoc3RydWN0IGlycV9kZXNj
KSk7CiAKICNkZWZpbmUgSVJRX01BWF9HVUVTVFMJCTcKIHR5cGVkZWYgc3RydWN0IHsKQEAg
LTQwLDggKzQxLDYgQEAgdHlwZWRlZiBzdHJ1Y3QgewogICAgIERFQ0xBUkVfQklUTUFQKF9i
aXRzLE5SX0lSUVMpOwogfSB2bWFza190OwogCi1leHRlcm4gc3RydWN0IGlycV9kZXNjICpp
cnFfZGVzYzsKLQogc3RhdGljIGlubGluZSBpbnQgaXJxX2Rlc2NfaW5pdGlhbGl6ZWQoc3Ry
dWN0IGlycV9kZXNjICpkZXNjKQogewogCXJldHVybiAwOwpkaWZmIC1yIDZhZjhhODljOTlj
ZCB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2F2cC5oCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVn
cmEvYXZwLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTQ0
IEBACisvKgorICogQ29weXJpZ2h0IChjKSAyMDEwIE5WSURJQSBDb3Jwb3JhdGlvbi4KKyAq
IEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp
biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmlj
YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnMgYXJlIG1ldDoKKyAqCisgKiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUg
bXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UsCisgKiB0aGlzIGxpc3Qg
b2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICoKKyAqIFJl
ZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg
Y29weXJpZ2h0IG5vdGljZSwKKyAqIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg
Zm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlIGRvY3VtZW50YXRpb24KKyAqIGFuZC9vciBv
dGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAq
IE5laXRoZXIgdGhlIG5hbWUgb2YgdGhlIE5WSURJQSBDb3Jwb3JhdGlvbiBub3IgdGhlIG5h
bWVzIG9mIGl0cyBjb250cmlidXRvcnMKKyAqIG1heSBiZSB1c2VkIHRvIGVuZG9yc2Ugb3Ig
cHJvbW90ZSBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZQorICogd2l0aG91
dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24uCisgKgorICogVEhJUyBTT0ZU
V0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJV
VE9SUyAiQVMgSVMiCisgKiBBTkQgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVT
LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJB
TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg
UFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZ
UklHSFQgSE9MREVSIE9SIENPTlRSSUJVVE9SUyBCRQorICogTElBQkxFIEZPUiBBTlkgRElS
RUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICog
Q09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg
UFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg
T0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUworICogSU5URVJSVVBUSU9O
KSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRI
RVIgSU4KKyAqIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJ
TkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpCisgKiBBUklTSU5HIElOIEFOWSBXQVkgT1VU
IE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRQor
ICogUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisgKgorICovCisKKyNpZm5kZWYgSU5D
TFVERURfQVZQX0gKKyNkZWZpbmUgSU5DTFVERURfQVZQX0gKKworI2luY2x1ZGUgImFwMTUv
YXJpY3Rsci5oIgorI2luY2x1ZGUgImFwMTUvYXJ0aW1lci5oIgorLy8gRklYTUU6IGdldCB0
aGUgYXJhcm1ldiBoZWFkZXIKKworLy8gMyBjb250cm9sbGVycyBpbiBjb250aWd1b3VzIG1l
bW9yeSBzdGFydGluZyBhdCBJTlRFUlJVUFRfQkFTRSwgZWFjaAorLy8gY29udHJvbGxlcidz
IGFwZXJ0dXJlIGlzIElOVEVSUlVQVF9TSVpFIGxhcmdlCisjZGVmaW5lIElOVEVSUlVQVF9C
QVNFIDB4NjAwMDQwMDAKKyNkZWZpbmUgSU5URVJSVVBUX1NJWkUgMHgxMDAKKyNkZWZpbmUg
SU5URVJSVVBUX05VTV9DT05UUk9MTEVSUyAzCisKKyNkZWZpbmUgSU5URVJSVVBUX1BFTkRJ
TkcoIGN0bHIgKSBcCisgICAgKElOVEVSUlVQVF9CQVNFICsgKChjdGxyKSAqIElOVEVSUlVQ
VF9TSVpFKSArIElDVExSX1ZJUlFfQ09QXzApCisKKyNkZWZpbmUgSU5URVJSVVBUX1NFVCgg
Y3RsciApIFwKKyAgICAoSU5URVJSVVBUX0JBU0UgKyAoKGN0bHIpICogSU5URVJSVVBUX1NJ
WkUpICsgSUNUTFJfQ09QX0lFUl9TRVRfMCkKKworI2RlZmluZSBJTlRFUlJVUFRfQ0xSKCBj
dGxyICkgXAorICAgIChJTlRFUlJVUFRfQkFTRSArICgoY3RscikgKiBJTlRFUlJVUFRfU0la
RSkgKyBJQ1RMUl9DT1BfSUVSX0NMUl8wKQorCisjZGVmaW5lIE9TQ19DVFJMICAgICAgICAo
IDB4NjAwMDYwMDAgKyAweDUwICkKKyNkZWZpbmUgT1NDX0ZSRVFfREVUICAgICggMHg2MDAw
NjAwMCArIDB4NTggKQorI2RlZmluZSBPU0NfREVUX1NUQVRVUyAgKCAweDYwMDA2MDAwICsg
MHg1QyApCisKKyNkZWZpbmUgVElNRVJfVVNFQyAgICAgICggMHg2MDAwNTAxMCApCisjZGVm
aW5lIFRJTUVSX0NGRyAgICAgICAoIDB4NjAwMDUwMTQgKQorI2RlZmluZSBUSU1FUl8wX0JB
U0UgICAgKCAweDYwMDA1MDAwICkKKyNkZWZpbmUgVElNRVJfMCAgICAgICAgICggVElNRVJf
MF9CQVNFICsgVElNRVJfVE1SX1BUVl8wICkKKyNkZWZpbmUgVElNRVJfMF9DTEVBUiAgICgg
VElNRVJfMF9CQVNFICsgVElNRVJfVE1SX1BDUl8wICkKKyNkZWZpbmUgVElNRVJfMV9CQVNF
ICAgICggMHg2MDAwNTAwOCApCisjZGVmaW5lIFRJTUVSXzEgICAgICAgICAoIFRJTUVSXzFf
QkFTRSArIFRJTUVSX1RNUl9QVFZfMCApCisjZGVmaW5lIFRJTUVSXzFfQ0xFQVIgICAoIFRJ
TUVSXzFfQkFTRSArIFRJTUVSX1RNUl9QQ1JfMCApCisKKyNkZWZpbmUgQ0xPQ0tfUlNUX0xP
ICAgICgweDYwMDA2MDA0KQorI2RlZmluZSBDTE9DS19DVExSX0hJICAgKDB4NjAwMDYwMTQp
CisjZGVmaW5lIENMT0NLX0NUTFJfTE8gICAoMHg2MDAwNjAxMCkKKworI2RlZmluZSBDQUNI
RV9DVExSICAgICAgKDB4NjAwMEMwMDApCisjZGVmaW5lIENBQ0hFX0NPTlRST0xfMCAgICAg
ICAgICgweDApCisKKyNkZWZpbmUgUFBJX0lOVFJfSURfVElNRVJfMCAgICAgKDApCisjZGVm
aW5lIFBQSV9JTlRSX0lEX1RJTUVSXzEgICAgICgxKQorI2RlZmluZSBQUElfSU5UUl9JRF9U
SU1FUl8yICAgICAoOSkKKyNkZWZpbmUgUFBJX0lOVFJfSURfVElNRVJfMyAgICAgKDEwKQor
CisvKiBmbG93IGNvbnRyb2xsZXIgKi8KKyNkZWZpbmUgRkxPV19DT05UUk9MTEVSICAgICAo
MHg2MDAwNzAwNCkKKworLyogZXhjZXB0aW9uIHZlY3RvcnMgKi8KKyNkZWZpbmUgVkVDVE9S
X0JBU0UgICAgICAgICAgICAgKCAweDYwMDBGMjAwICkKKyNkZWZpbmUgVkVDVE9SX1JFU0VU
ICAgICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDAgKQorI2RlZmluZSBWRUNUT1JfVU5ERUYg
ICAgICAgICAgICAoIFZFQ1RPUl9CQVNFICsgNCApCisjZGVmaW5lIFZFQ1RPUl9TV0kgICAg
ICAgICAgICAgICggVkVDVE9SX0JBU0UgKyA4ICkKKyNkZWZpbmUgVkVDVE9SX1BSRUZFVENI
X0FCT1JUICAgKCBWRUNUT1JfQkFTRSArIDEyICkKKyNkZWZpbmUgVkVDVE9SX0RBVEFfQUJP
UlQgICAgICAgKCBWRUNUT1JfQkFTRSArIDE2ICkKKyNkZWZpbmUgVkVDVE9SX0lSUSAgICAg
ICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDI0ICkKKyNkZWZpbmUgVkVDVE9SX0ZJUSAgICAg
ICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDI4ICkKKworI2RlZmluZSBNT0RFX0RJU0FCTEVf
SU5UUiAweGMwCisjZGVmaW5lIE1PREVfVVNSIDB4MTAKKyNkZWZpbmUgTU9ERV9GSVEgMHgx
MQorI2RlZmluZSBNT0RFX0lSUSAweDEyCisjZGVmaW5lIE1PREVfU1ZDIDB4MTMKKyNkZWZp
bmUgTU9ERV9BQlQgMHgxNworI2RlZmluZSBNT0RFX1VORCAweDFCCisjZGVmaW5lIE1PREVf
U1lTIDB4MUYKKworI2RlZmluZSBBUDE1X0NBQ0hFX0xJTkVfU0laRSAgICAgICAgICAgIDMy
CisKKyNkZWZpbmUgQVAxNV9BUEJfTDJfQ0FDSEVfQkFTRSAweDcwMDBlODAwIAorI2RlZmlu
ZSBBUDE1X0FQQl9DTEtfUlNUX0JBU0UgIDB4NjAwMDYwMDAKKyNkZWZpbmUgQVAxNV9BUEJf
TUlTQ19CQVNFICAgICAweDcwMDAwMDAwCisKKyNkZWZpbmUgQVAxMF9BUEJfQ0xLX1JTVF9C
QVNFICAweDYwMDA2MDAwCisjZGVmaW5lIEFQMTBfQVBCX01JU0NfQkFTRSAgICAgMHg3MDAw
MDAwMAorCisjZGVmaW5lIE1NVV9UTEJfQkFTRSAgICAgICAgICAgICAgMHhmMDAwZjAwMAor
I2RlZmluZSBNTVVfVExCX0NBQ0hFX1dJTkRPV18wICAgIDB4NDAKKyNkZWZpbmUgTU1VX1RM
Ql9DQUNIRV9PUFRJT05TXzAgICAweDQ0CisKKyNkZWZpbmUgQVAxNV9QSU5NVVhfQ0ZHX0NU
TF8wICAgMHg3MDAwMDAyNAorI2RlZmluZSBBUDE1X0FWUF9KVEFHX0VOQUJMRSAgICAweEMw
CisKKyNkZWZpbmUgUE1DX1NDUkFUQ0gyMl9SRUdfTFAwICAgMHg3MDAwZTRhOAorCisjZGVm
aW5lIEFWUF9XRFRfUkVTRVQgICAweDJGMDBCQUQwCisKKy8qIENhY2hlZCB0byB1bmNhY2hl
ZCBvZmZzZXQgZm9yIEFWUAorICoKKyAqIEhhcmR3YXJlIGhhcyB1bmNhY2hlZCByZW1hcCBh
cGVydHVyZSBmb3IgQVZQIGFzIEFWUCBkb2Vzbid0IGhhdmUgTU1VCisgKiBidXQgc3RpbGwg
aGFzIGNhY2hlIChuYW1lZCBDT1AgY2FjaGUpLgorICoKKyAqIFRoaXMgYXBlcnR1cmUgbW92
ZWQgYmV0d2VlbiBBUDE1IGFuZCBBUDIwLgorICovCisjZGVmaW5lIEFQMTVfQ0FDSEVEX1RP
X1VOQ0FDSEVEX09GRlNFVCAweDkwMDAwMDAwCisjZGVmaW5lIEFQMjBfQ0FDSEVEX1RPX1VO
Q0FDSEVEX09GRlNFVCAweDgwMDAwMDAwCisKKyNkZWZpbmUgQVBYWF9FWFRfTUVNX1NUQVJU
ICAgICAgMHgwMDAwMDAwMAorI2RlZmluZSBBUFhYX0VYVF9NRU1fRU5EICAgICAgICAweDQw
MDAwMDAwCisKKyNkZWZpbmUgQVBYWF9NTUlPX1NUQVJUICAgICAgICAgMHg0MDAwMDAwMAor
I2RlZmluZSBBUFhYX01NSU9fRU5EICAgICAgICAgICAweEZGRjAwMDAwCisKKyNkZWZpbmUg
VFhYX0VYVF9NRU1fU1RBUlQgICAgICAgMHg4MDAwMDAwMAorI2RlZmluZSBUWFhfRVhUX01F
TV9FTkQgICAgICAgICAweGMwMDAwMDAwCisKKyNkZWZpbmUgVFhYX01NSU9fU1RBUlQgICAg
ICAgICAgMHg0MDAwMDAwMAorI2RlZmluZSBUWFhfTU1JT19FTkQgICAgICAgICAgICAweDgw
MDAwMDAwCisKKyNlbmRpZgpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20t
YXJtL3RlZ3JhL2NvbmZpZy5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvY29u
ZmlnLmgJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS1hcm0vdGVncmEvY29uZmlnLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAw
CkBAIC0xLDExICsxLDYgQEAKICNpZm5kZWYgX19URUdSQV9DT05GSUdfSF9fCiAjZGVmaW5l
IF9fVEVHUkFfQ09ORklHX0hfXwogCi0jZGVmaW5lIEhaCTEwMAotI2RlZmluZSBDTE9DS19U
SUNLX1JBVEUJCTEwMDAwMDAKKyNkZWZpbmUgTUFYX1BIWVNfQ1BVUwkyCiAKLSNkZWZpbmUg
TUFYX1BIWVNfQ1BVUwkJMgotCi0jZGVmaW5lIEJVSUxUSU5fQ09NTUFORF9MSU5FX1NJWkUg
MjU2Ci0jZGVmaW5lIEJVSUxUSU5fQ09NTUFORF9MSU5FCSIiCiAjZW5kaWYKZGlmZiAtciA2
YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS9pcnFzLmgKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUv
YXNtLWFybS90ZWdyYS9pcnFzLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwCkBA
IC0wLDAgKzEsNjAgQEAKKy8qCisgKiBhcmNoL2FybS9tYWNoLXRlZ3JhL2luY2x1ZGUvbWFj
aC9pcnFzLmgKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDksIE5WSURJQSBDb3Jwb3JhdGlv
bi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBG
cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vu
c2UsIG9yCisgKiAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLCBidXQgV0lUSE9VVAorICogQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g
dGhlIGltcGxpZWQgd2FycmFudHkgb2YgTUVSQ0hBTlRBQklMSVRZIG9yCisgKiBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UgZm9yCisgKiBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYWxv
bmcKKyAqIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4sCisgKiA1MSBGcmFua2xpbiBTdHJlZXQsIEZpZnRo
IEZsb29yLCBCb3N0b24sIE1BICAwMjExMC0xMzAxLCBVU0EuCisgKi8KKworI2lmbmRlZiBf
X1RFR1JBX0lSUVNfSAorI2RlZmluZSBfX1RFR1JBX0lSUVNfSAorCisjZGVmaW5lIE5SX0lS
UVMJCQk1MTIKKworI2RlZmluZSBJTlRfUFJJX0JBU0UJCTMyCisjZGVmaW5lIElOVF9SVEMJ
CQkoSU5UX1BSSV9CQVNFICsgMikKKyNkZWZpbmUgSU5UX1VTQgkJCShJTlRfUFJJX0JBU0Ug
KyAyMCkKKyNkZWZpbmUgSU5UX1VTQjIJCShJTlRfUFJJX0JBU0UgKyAyMSkKKyNkZWZpbmUg
SU5UX0FQQl9ETUEJCShJTlRfUFJJX0JBU0UgKyAyNikKKworI2RlZmluZSBJTlRfU0VDX0JB
U0UJCShJTlRfUFJJX0JBU0UgKyAzMikKKyNkZWZpbmUgSU5UX0dQSU8xCQkoSU5UX1NFQ19C
QVNFICsgMCkKKyNkZWZpbmUgSU5UX0dQSU8yCQkoSU5UX1NFQ19CQVNFICsgMSkKKyNkZWZp
bmUgSU5UX0dQSU8zCQkoSU5UX1NFQ19CQVNFICsgMikKKyNkZWZpbmUgSU5UX0dQSU80CQko
SU5UX1NFQ19CQVNFICsgMykKKyNkZWZpbmUgSU5UX1RNUjMJCShJTlRfU0VDX0JBU0UgKyA5
KQorI2RlZmluZSBJTlRfVE1SNAkJKElOVF9TRUNfQkFTRSArIDEwKQorI2RlZmluZSBJTlRf
U1lTX1NUQVRTX01PTgkoSU5UX1NFQ19CQVNFICsgMjIpCisjZGVmaW5lIElOVF9HUElPNQkJ
KElOVF9TRUNfQkFTRSArIDIzKQorCisjZGVmaW5lIElOVF9UUklfQkFTRQkJKElOVF9TRUNf
QkFTRSArIDMyKQorI2RlZmluZSBJTlRfS0JDCQkJKElOVF9UUklfQkFTRSArIDIxKQorI2Rl
ZmluZSBJTlRfRVhURVJOQUxfUE1VCShJTlRfVFJJX0JBU0UgKyAyMikKKyNkZWZpbmUgSU5U
X0dQSU82CQkoSU5UX1RSSV9CQVNFICsgMjMpCisjZGVmaW5lIElOVF9HUElPNwkJKElOVF9U
UklfQkFTRSArIDI1KQorCisjZGVmaW5lIElOVF9RVUFEX0JBU0UJCShJTlRfVFJJX0JBU0Ug
KyAzMikKKyNkZWZpbmUgSU5UX1VTQjMJCShJTlRfUVVBRF9CQVNFICsgMSkKKworI2RlZmlu
ZSBJTlRfR1BJT19CQVNFCQkoSU5UX1FVQURfQkFTRSArIDMyKQorI2RlZmluZSBJTlRfR1BJ
T19OUgkJKDI4KjgpCisKKyNkZWZpbmUgSU5UX0FQQkRNQV9CQVNFCSAJKElOVF9HUElPX0JB
U0UgKyBJTlRfR1BJT19OUikKKyNkZWZpbmUgSU5UX0FQQkRNQV9OUgkJKDE2KQorCisjZGVm
aW5lIElOVF9TWVNfTlIJKElOVF9HUElPX0JBU0UgLSBJTlRfUFJJX0JBU0UpCisjZGVmaW5l
IElOVF9TWVNfU1oJKElOVF9TRUNfQkFTRSAtIElOVF9QUklfQkFTRSkKKworI2VuZGlmCmRp
ZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvc21wLmgKLS0t
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2lu
Y2x1ZGUvYXNtLWFybS90ZWdyYS9zbXAuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDAKQEAgLTAsMCArMSw3IEBACisjaWZuZGVmIEFTTUFSTV9BUkNIX1NNUF9ICisjZGVmaW5l
IEFTTUFSTV9BUkNIX1NNUF9ICisKKworI2luY2x1ZGUgPGFzbS9naWMuaD4KKworI2VuZGlm
CmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvdGVncmEu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL3RlZ3JhLmgJU3VuIEZlYiAxMiAxNTowNDowNiAy
MDEyICswOTAwCkBAIC0wLDAgKzEsNzUgQEAKKyNpZm5kZWYgX19URUdSQTI1MF9IX18KKyNk
ZWZpbmUgX19URUdSQTI1MF9IX18KKworI2RlZmluZSBURUdSQV9BUk1fQ1BVX0JBU0UJCTB4
NTAwMDAwMDAKKyNkZWZpbmUgVEVHUkFfUFBTQl9ERVZJQ0VfQkFTRQkJMHg2MDAwMDAwMAor
I2RlZmluZSBURUdSQV9BUEJfREVWSUNFX0JBU0UJCTB4NzAwMDAwMDAKKworI2RlZmluZSBU
RUdSQV9BUk1fUEVSSUZfQkFTRQkJMHg1MDA0MDAwMAorI2RlZmluZSBURUdSQV9BUk1fUEVS
SUZfU0laRQkJU1pfOEsKKworI2RlZmluZSBURUdSQV9TQ1VfQkFTRQkJCTB4NTAwNDAwMDAK
KyNkZWZpbmUgVEVHUkFfU0NVX1NJWkUJCQlTWl8yNTYKKworI2RlZmluZSBURUdSQV9HSUNf
UFJPQ19JRl9CQVNFCQkweDUwMDQwMTAwCisjZGVmaW5lIFRFR1JBX0dJQ19QUk9DX0lGX1NJ
WkUJCVNaXzI1NgorCisjZGVmaW5lIFRFR1JBX0FSTV9JTlRfRElTVF9CQVNFCQkweDUwMDQx
MDAwCisjZGVmaW5lIFRFR1JBX0FSTV9JTlRfRElTVF9TSVpFCQlTWl80SworCisjZGVmaW5l
IFRFR1JBX1BSSU1BUllfSUNUTFJfQkFTRQkweDYwMDA0MDAwCisjZGVmaW5lIFRFR1JBX1BS
SU1BUllfSUNUTFJfU0laRQlTWl82NAorCisjZGVmaW5lIFRFR1JBX1NFQ09OREFSWV9JQ1RM
Ul9CQVNFCTB4NjAwMDQxMDAKKyNkZWZpbmUgVEVHUkFfU0VDT05EQVJZX0lDVExSX1NJWkUJ
U1pfNjQKKworI2RlZmluZSBURUdSQV9URVJUSUFSWV9JQ1RMUl9CQVNFCTB4NjAwMDQyMDAK
KyNkZWZpbmUgVEVHUkFfVEVSVElBUllfSUNUTFJfU0laRQlTWl82NAorCisjZGVmaW5lIFRF
R1JBX1FVQVRFUk5BUllfSUNUTFJfQkFTRQkweDYwMDA0MzAwCisjZGVmaW5lIFRFR1JBX1FV
QVRFUk5BUllfSUNUTFJfU0laRQlTWl82NAorCisjZGVmaW5lIFRFR1JBX1RNUjFfQkFTRQkJ
CTB4NjAwMDUwMDAKKyNkZWZpbmUgVEVHUkFfVE1SMV9TSVpFCQkJU1pfOAorCisjZGVmaW5l
IFRFR1JBX1RNUjJfQkFTRQkJCTB4NjAwMDUwMDgKKyNkZWZpbmUgVEVHUkFfVE1SMl9TSVpF
CQkJU1pfOAorCisjZGVmaW5lIFRFR1JBX1RNUlVTX0JBU0UJCTB4NjAwMDUwMTAKKyNkZWZp
bmUgVEVHUkFfVE1SVVNfU0laRQkJU1pfNjQKKworI2RlZmluZSBURUdSQV9UTVIzX0JBU0UJ
CQkweDYwMDA1MDUwCisjZGVmaW5lIFRFR1JBX1RNUjNfU0laRQkJCVNaXzgKKworI2RlZmlu
ZSBURUdSQV9UTVI0X0JBU0UJCQkweDYwMDA1MDU4CisjZGVmaW5lIFRFR1JBX1RNUjRfU0la
RQkJCVNaXzgKKworI2RlZmluZSBURUdSQV9DTEtfUkVTRVRfQkFTRQkJMHg2MDAwNjAwMAor
I2RlZmluZSBURUdSQV9DTEtfUkVTRVRfU0laRQkJU1pfNEsKKworI2RlZmluZSBURUdSQV9G
TE9XX0NUUkxfQkFTRQkJMHg2MDAwNzAwMAorI2RlZmluZSBURUdSQV9GTE9XX0NUUkxfU0la
RQkJMjAKKworI2RlZmluZSBURUdSQV9HUElPX0JBU0UJCQkweDYwMDBEMDAwCisjZGVmaW5l
IFRFR1JBX0dQSU9fU0laRQkJCVNaXzRLCisKKyNkZWZpbmUgVEVHUkFfRVhDRVBUSU9OX1ZF
Q1RPUlNfQkFTRSAgICAweDYwMDBGMDAwCisjZGVmaW5lIFRFR1JBX0VYQ0VQVElPTl9WRUNU
T1JTX1NJWkUgICAgU1pfNEsKKworI2RlZmluZSBJQ1RMUl9DUFVfSUVSXzAJCQkoMHgyMCkK
KyNkZWZpbmUgSUNUTFJfQ1BVX0lFUl9TRVRfMAkJKDB4MjQpCisjZGVmaW5lIElDVExSX0NQ
VV9JRVJfQ0xSXzAJCSgweDI4KQorI2RlZmluZSBJQ1RMUl9DUFVfSUVQX0NMQVNTXzAJCSgw
eDJDKQorI2RlZmluZSBJQ1RMUl9DT1BfSUVSXzAJCQkoMHgzMCkKKyNkZWZpbmUgSUNUTFJf
Q09QX0lFUl9TRVRfMAkJKDB4MzQpCisjZGVmaW5lIElDVExSX0NPUF9JRVJfQ0xSXzAJCSgw
eDM4KQorI2RlZmluZSBJQ1RMUl9DT1BfSUVQX0NMQVNTXzAJCSgweDNDKQorCisjZGVmaW5l
IEFSTV9QRVJJRl9CQVNFCQkJKDB4NTAwNDAwMDApCisKKy8vI2RlZmluZSBJT19BRERSRVNT
KHgpCQkJKCgoKCh4KSAmIDB4NzAwMDAwMDApID4+IDgpICsgKCgoeCkgJiAweDBGMDAwMDAw
KSA+PiA0KSkgfCgoeCkgJiAweEZGRkZGKSB8IDB4RkIwMDAwMDAgKQorI2RlZmluZSBJT19B
RERSRVNTKHgpCQkJKCgoKHgpICYgMHhGMDAwMDAwMCkgPj4gOCkgfCAoKHgpICYgMHhGRkZG
RikgfCAoMHhGQjAwMDAwMCApKQorI2RlZmluZSBJTlRfUFBJX0FERFJFU1MoX2luc3QpCQko
MHg2MDAwNDAwMCArICgweDEwMCAqIChfaW5zdCkpKQorI2RlZmluZSBJTlRfQVBCRE1BX0FE
RFJFU1MJCSgweDYwMDBhMDAwKQorCisjZW5kaWYKZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVu
L2luY2x1ZGUveGVuL2lycS5oCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9pcnEuaAlTdW4gRmVi
IDEyIDEyOjI0OjIxIDIwMTIgKzA5MDAKKysrIGIveGVuL2luY2x1ZGUveGVuL2lycS5oCVN1
biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMApAQCAtOTUsNiArOTUsMTAgQEAgaW50IGFy
Y2hfaW5pdF9vbmVfaXJxX2Rlc2Moc3RydWN0IGlycV9kZQogCiAjZGVmaW5lIGlycV9kZXNj
X2luaXRpYWxpemVkKGRlc2MpICgoZGVzYyktPmhhbmRsZXIgIT0gTlVMTCkKIAorI2lmIGRl
ZmluZWQoX19hcm1fXykKK2V4dGVybiBpcnFfZGVzY190IGlycV9kZXNjW05SX0lSUVNdOwor
I2VuZGlmCisKICNpZiBkZWZpbmVkKF9faWE2NF9fKQogZXh0ZXJuIGlycV9kZXNjX3QgaXJx
X2Rlc2NbTlJfVkVDVE9SU107CiAKQEAgLTEyMSw2ICsxMjUsOCBAQCBleHRlcm4gdm9pZCBp
cnFfYWN0b3Jfbm9uZShzdHJ1Y3QgaXJxX2RlCiAjZGVmaW5lIGlycV9zaHV0ZG93bl9ub25l
IGlycV9hY3Rvcl9ub25lCiAjZGVmaW5lIGlycV9kaXNhYmxlX25vbmUgaXJxX2FjdG9yX25v
bmUKICNkZWZpbmUgaXJxX2VuYWJsZV9ub25lIGlycV9hY3Rvcl9ub25lCisjZGVmaW5lIGly
cV9hY2tfbm9uZQlpcnFfYWN0b3Jfbm9uZQorI2RlZmluZSBpcnFfZW5kX25vbmUJaXJxX2Fj
dG9yX25vbmUKIAogc3RydWN0IGRvbWFpbjsKIHN0cnVjdCB2Y3B1Owo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt15-0005wh-KZ; Mon, 13 Feb 2012 10:20:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqm9-0003F1-3u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:56:41 +0000
Received: from [85.158.139.83:63096] by server-9.bemta-5.messagelabs.com id
	5D/CF-23757-832C83F4; Mon, 13 Feb 2012 07:56:40 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329119796!7366403!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26549 invoked from network); 13 Feb 2012 07:56:39 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-8.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 07:56:39 -0000
Received: from epcpsbge8.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005VZN88EV50@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:56:36 +0900 (KST)
Message-id: <0LZB0052INECEV60@mailout1.samsung.com>
X-AuditID: cbfee612-b7c09ae0000024ca-7a-4f38c23437fc
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge8.samsung.com (EPCPMTA) with SMTP id A0.9E.09418.432C83F4;
	Mon, 13 Feb 2012 16:56:36 +0900 (KST)
Date: Mon, 13 Feb 2012 07:56:36 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075537186@jm77.ryu
Msgkey: 20120213075537186@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075324312@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 04/14]  arm: implement xen init code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <19113662.69871329119793084.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgeGVuIGluaXQgY29kZQ0KDQogeGVuL2FyY2gvYXJtL3hlbi9jcHUuYyAg
IHwgICA4NCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKystLS0tLS0tDQogeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jIHwg
IDEwMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQ0KIDIgZmlsZXMgY2hhbmdl
ZCwgMTY3IGluc2VydGlvbnMoKyksIDE4IGRlbGV0aW9ucygtKQ0KDQpTaWduZWQtb2ZmLWJ5OiBK
YWVtaW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCg0KZGlmZiAtciBmYjA4MTViYTQwYTEg
eGVuL2FyY2gvYXJtL3hlbi9jcHUuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9jcHUuYwlGcmkg
RmViIDAzIDE2OjI2OjQ5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vY3B1LmMJ
RnJpIEZlYiAwMyAxNzoyODoxNSAyMDEyICswOTAwDQpAQCAtMjgsNiArMjgsMTEgQEANCiAjaW5j
bHVkZSA8eGVuL3NjaGVkLmg+DQogI2luY2x1ZGUgPHhlbi9wcmVlbXB0Lmg+DQogI2luY2x1ZGUg
PHhlbi9wZXJjcHUuaD4NCisjaW5jbHVkZSA8YXNtL21tdS5oPg0KKyNpbmNsdWRlIDxhc20vY3Vy
cmVudC5oPg0KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4NCisjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nv
ci5oPg0KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4NCiANCiBjcHVtYXNrX3QgY3B1X29ubGluZV9t
YXA7DQogY3B1bWFza190IGNwdV9wcmVzZW50X21hcDsNCkBAIC00Niw3ICs1MSwxMiBAQCBERUZJ
TkVfUEVSX0NQVV9SRUFEX01PU1RMWShjcHVtYXNrX3Zhcl90DQogDQogaW50IF9fY3B1X3VwKHVu
c2lnbmVkIGludCBjcHUpDQogew0KLQlOT1RfWUVUKCk7DQorCWludCByZXQgPSAwOw0KKw0KKwl3
aGlsZSghY3B1X29ubGluZShjcHUpKSB7DQorCQljcHVfcmVsYXgoKTsNCisJCXByb2Nlc3NfcGVu
ZGluZ19zb2Z0aXJxcygpOw0KKwl9DQogDQogCXJldHVybiAwOw0KIH0NCkBAIC02MywzNSArNzMs
OTMgQEAgdm9pZCBfX2NwdV9kaWUodW5zaWduZWQgaW50IGNwdSkNCiANCiB2b2lkIHNldF9jcHVf
c2libGluZ19tYXAodW5zaWduZWQgaW50IGNwdSkNCiB7DQotCU5PVF9ZRVQoKTsNCisJdW5zaWdu
ZWQgaW50IGk7DQorDQorCWZvcl9lYWNoX3ByZXNlbnRfY3B1KGkpIHsNCisJCWNwdW1hc2tfc2V0
X2NwdShpLCAmcGVyX2NwdShjcHVfc2libGluZ19tYXNrLCBjcHUpKTsNCisJCWNwdW1hc2tfc2V0
X2NwdShjcHUsICZwZXJfY3B1KGNwdV9zaWJsaW5nX21hc2ssIGkpKTsNCisNCisJCWNwdW1hc2tf
c2V0X2NwdShpLCAmcGVyX2NwdShjcHVfY29yZV9tYXNrLCBjcHUpKTsNCisJCWNwdW1hc2tfc2V0
X2NwdShjcHUsICZwZXJfY3B1KGNwdV9jb3JlX21hc2ssIGkpKTsNCisJfQ0KIH0NCiANCiB2b2lk
IHNtcF9wcmVwYXJlX2NwdXModW5zaWduZWQgaW50IG1heF9jcHVzKQ0KIHsNCi0JTk9UX1lFVCgp
Ow0KKwlzZXRfY3B1X3NpYmxpbmdfbWFwKDApOw0KIH0NCiANCiB2b2lkIHNtcF9wcmVwYXJlX2Jv
b3RfY3B1KHZvaWQpDQogew0KLQlOT1RfWUVUKCk7DQorCWludCBjcHUgPSBzbXBfcHJvY2Vzc29y
X2lkKCk7DQorDQorCWNwdW1hc2tfc2V0X2NwdShjcHUsICZjcHVfb25saW5lX21hcCk7DQorCWNw
dW1hc2tfc2V0X2NwdShjcHUsICZjcHVfcHJlc2VudF9tYXApOw0KKwljcHVtYXNrX3NldF9jcHUo
Y3B1LCAmY3B1X3Bvc3NpYmxlX21hcCk7DQorDQorCWNwdV9pbmZvX2luaXQoZ2V0X2NwdV9pbmZv
KCkpOw0KIH0NCiANCiBhc21saW5rYWdlIHZvaWQgc3RhcnRfeGVuX29uX3NsYXZlX2NwdSh2b2lk
KQ0KIHsNCi0JTk9UX1lFVCgpOw0KKwl1bnNpZ25lZCBpbnQgY3B1Ow0KKwlzdHJ1Y3QgdmNwdSAq
djsJDQorDQorCWNwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsNCisNCisgICAgICAgIC8qIGlkbGUg
dmNwdSBpcyBhbGxvY2F0ZWQgYnkgc2NoZWR1bGVyX2luaXQoKSAqLw0KKyAgICAgICAgdiA9IGlk
bGVfdmNwdVtjcHVdOw0KKwlzZXRfY3VycmVudChpZGxlX3ZjcHVbY3B1XSk7DQorDQorCXNldF9j
cHVfc2libGluZ19tYXAoY3B1KTsNCisNCisJbm90aWZ5X2NwdV9zdGFydGluZyhjcHUpOw0KKwl3
bWIoKTsNCisNCisJY3B1bWFza19zZXRfY3B1KGNwdSwgJmNwdV9vbmxpbmVfbWFwKTsNCisJd21i
KCk7DQorDQorCWxvY2FsX2lycV9lbmFibGUoKTsNCisJbG9jYWxfZmlxX2VuYWJsZSgpOw0KKw0K
KwlzdGFydHVwX2NwdV9pZGxlX2xvb3AoKTsNCiB9DQogDQogdm9pZCBzbXBfc2VuZF9ldmVudF9j
aGVja19tYXNrKGNvbnN0IGNwdW1hc2tfdCAqbWFzaykNCiB7DQotCU5PVF9ZRVQoKTsNCisJaW50
IGNwdTsNCisJdW5zaWduZWQgbG9uZyBtYXAgPSAwOw0KKw0KKwlmb3JfZWFjaF9jcHUoY3B1LCBt
YXNrKSB7DQorCQltYXAgfD0gMSA8PCBjcHU7DQorCX0NCisNCisJLyogVHJpZ2dlciByZW1vdGUg
Q1BVICovDQogfQ0KIA0KIHZvaWQgc21wX2NhbGxfZnVuY3Rpb24odm9pZCAoKmYpKHZvaWQgKnBh
cmFtKSwgdm9pZCAqcGFyYW0sIGludCB3YWl0KQ0KIHsNCi0JTk9UX1lFVCgpOw0KIH0NCiANCiB2
b2lkIHNtcF9zZW5kX3N0YXRlX2R1bXAodW5zaWduZWQgaW50IGNwdSkNCiB7DQotCU5PVF9ZRVQo
KTsNCiB9DQorDQordm9pZCBjcHVfdG9wb2xvZ3lfaW5pdCh1bnNpZ25lZCBpbnQgY3B1cykNCit7
DQorCWludCBpOw0KKw0KKwlpZiAoY3B1cyA9PSAwKSB7DQorCQljcHVzID0gMTsNCisJfQ0KKw0K
KwlpZiAoY3B1cyA+IE1BWF9QSFlTX0NQVVMpIHsNCisJCWNwdXMgPSBNQVhfUEhZU19DUFVTOw0K
Kwl9DQorDQorCWZvciAoaSA9IDA7IGkgPCBjcHVzOyBpKyspIHsNCisJCWNwdW1hc2tfc2V0X2Nw
dShpLCAmY3B1X3Bvc3NpYmxlX21hcCk7DQorCQljcHVtYXNrX3NldF9jcHUoaSwgJmNwdV9wcmVz
ZW50X21hcCk7DQorCX0NCit9DQorDQpkaWZmIC1yIGZiMDgxNWJhNDBhMSB4ZW4vYXJjaC9hcm0v
eGVuL3NldHVwLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vc2V0dXAuYwlGcmkgRmViIDAzIDE2
OjI2OjQ5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vc2V0dXAuYwlGcmkgRmVi
IDAzIDE3OjI4OjE1IDIwMTIgKzA5MDANCkBAIC0zMCwzNSArMzAsMTE2IEBADQogI2luY2x1ZGUg
PHhlbi9wcmVlbXB0Lmg+DQogI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+DQogI2luY2x1ZGUg
PHB1YmxpYy9zY2hlZC5oPg0KLQ0KKyNpbmNsdWRlIDxhc20vbW11Lmg+DQogDQogc3RydWN0IGRv
bWFpbiBfZG9tX3hlbiA9IHsNCi0gICAgICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCi0g
ICAgICAgIC5kb21haW5faWQgPSBET01JRF9YRU4sDQotICAgICAgICAuZG9tYWluX2xvY2sgPSBT
UElOX0xPQ0tfVU5MT0NLRUQsDQorCS5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCisJLmRvbWFp
bl9pZCA9IERPTUlEX1hFTiwNCisJLmRvbWFpbl9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VELA0K
IH07DQogDQogc3RydWN0IGRvbWFpbiBfZG9tX2lvID0gew0KLSAgICAgICAgLnJlZmNudCA9IEFU
T01JQ19JTklUKDEpLA0KLSAgICAgICAgLmRvbWFpbl9pZCA9IERPTUlEX0lPLA0KLSAgICAgICAg
LmRvbWFpbl9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VELA0KKwkucmVmY250ID0gQVRPTUlDX0lO
SVQoMSksDQorCS5kb21haW5faWQgPSBET01JRF9JTywNCisJLmRvbWFpbl9sb2NrID0gU1BJTl9M
T0NLX1VOTE9DS0VELA0KIH07DQogDQogc3RydWN0IGRvbWFpbiBfZG9tX2NvdyA9IHsNCi0gICAg
ICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCi0gICAgICAgIC5kb21haW5faWQgPSBET01J
RF9DT1csDQotICAgICAgICAuZG9tYWluX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsDQorCS5y
ZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCisJLmRvbWFpbl9pZCA9IERPTUlEX0NPVywNCisJLmRv
bWFpbl9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VELA0KIH07DQogDQogc3RydWN0IGRvbWFpbiAq
ZG9tX3hlbiA9ICZfZG9tX3hlbjsNCiBzdHJ1Y3QgZG9tYWluICpkb21faW8gPSAmX2RvbV9pbzsN
CiBzdHJ1Y3QgZG9tYWluICpkb21fY293ID0gJl9kb21fY293Ow0KIA0KKy8qIG1heGNwdXM6IG1h
eGltdW0gbnVtYmVyIG9mIENQVXMgdG8gYmUgYWN0aXZhdGVkICovDQorc3RhdGljIHVuc2lnbmVk
IGludCBtYXhfY3B1cyA9IE5SX0NQVVM7DQoraW50ZWdlcl9wYXJhbSgibWF4Y3B1cyIsIG1heF9j
cHVzKTsNCisNCisvKiBEZWZhdWx0IGRvbWFpbiBzaXplID0gNjRNQiAqLw0KK3N0YXRpYyB1bnNp
Z25lZCBpbnQgZG9tMF9zaXplID0gMjU2ICogMTAyNCAqIDEwMjQ7DQoraW50ZWdlcl9wYXJhbSgi
ZG9tMF9zaXplIiwgZG9tMF9zaXplKTsNCisNCisvL3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBf
aW1hZ2Vfc3RhcnQgPSAweDQwQjAwMDAwVUw7DQorc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9p
bWFnZV9zdGFydCA9IDB4MDBCMDAwMDBVTDsNCitpbnRlZ2VyX3BhcmFtKCJpbWFnZV9zdGFydCIs
IGRvbTBfaW1hZ2Vfc3RhcnQpOw0KKw0KKy8vc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFn
ZV9zaXplID0gMHhBMDAwMDBVTDsNCitzdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3Np
emUgPSAweEEwMDAwMFVMOw0KK2ludGVnZXJfcGFyYW0oImltYWdlX2xlbmd0aCIsIGRvbTBfaW1h
Z2Vfc2l6ZSk7DQorDQogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVzX2lu
Zm9fdCAqaW5mbykNCiB7DQogfQ0KIA0KK3N0YXRpYyB2b2lkIGlkbGVfZG9tYWluX2luaXQodm9p
ZCkNCit7DQorCXN0cnVjdCB2Y3B1ICp2Ow0KKw0KKwlzY2hlZHVsZXJfaW5pdCgpOw0KKw0KKwkv
KiBpZGxlIHZjcHUgaXMgYWxsb2NhdGVkIGJ5IHNjaGVkdWxlcl9pbml0KCkgKi8NCisJdiA9IGlk
bGVfdmNwdVswXTsNCisNCisJc2V0X2N1cnJlbnRfdmNwdSh2KTsNCit9DQorDQogYXNtbGlua2Fn
ZSB2b2lkIHN0YXJ0X3hlbih2b2lkKQ0KIHsNCisJdW5zaWduZWQgaW50IGk7DQorDQorCXNtcF9w
cmVwYXJlX2Jvb3RfY3B1KCk7DQorDQorCXNvZnRpcnFfaW5pdCgpOw0KKw0KKwl0YXNrbGV0X3N1
YnN5c19pbml0KCk7DQorDQorCXRpbWVyX2luaXQoKTsNCisNCisJaWRsZV9kb21haW5faW5pdCgp
Ow0KKw0KKwlyY3VfaW5pdCgpOw0KKw0KKwlsb2NhbF9pcnFfZW5hYmxlKCk7DQorDQorCXNtcF9w
cmVwYXJlX2NwdXMobWF4X2NwdXMpOw0KKw0KKwlkb19wcmVzbXBfaW5pdGNhbGxzKCk7DQorDQor
CXRpbWVrZWVwaW5nX2luaXQoKTsNCisNCisJZm9yX2VhY2hfcHJlc2VudF9jcHUoaSkgew0KKwkJ
aWYgKG51bV9vbmxpbmVfY3B1cygpIDwgbWF4X2NwdXMgJiYgIWNwdV9vbmxpbmUoaSkpIHsNCisJ
CQlpbnQgcmV0ID0gY3B1X3VwKGkpOw0KKwkNCisJCQlpZiAocmV0ICE9IDApIHsNCisJCQkJcHJp
bnRrKCJGYWlsIHRvIGJyaW5nIHVwIENQVSAldSAoZXJyb3IgJWQpXG4iLCBpLCByZXQpOw0KKwkJ
CX0NCisJCX0NCisJfQ0KKw0KKwlwcmludGsoIkJyb3VnaHQgdXAgJWxkIENQVXNcbiIsIChsb25n
KW51bV9vbmxpbmVfY3B1cygpKTsNCisNCisJZG9faW5pdGNhbGxzKCk7DQorDQorCWRvbTAgPSBk
b21haW5fY3JlYXRlKDAsIDAsIDApOw0KKwlpZiAoZG9tMCA9PSBOVUxMKSB7DQorCQlwYW5pYygi
RG9tYWluIGNyZWF0aW9uIGZhaWxlZFxuIik7DQorCX0NCisNCisNCisJaWYgKGRvbWFpbl9jb25z
dHJ1Y3QoZG9tMCwNCisJCQkgICAgIGRvbTBfaW1hZ2Vfc3RhcnQsIA0KKwkJCSAgICAgZG9tMF9p
bWFnZV9zaXplLCANCisJCQkgICAgIGRvbTBfc2l6ZSwgDQorCQkJICAgICBtYXhfY3B1cykpIHsN
CisJCVBBTklDKCJEb21haW4gY29uc3RydWN0aW9uIGZhaWxlZFxuIik7DQorCX0NCisNCisJZG9t
YWluX3VucGF1c2VfYnlfc3lzdGVtY29udHJvbGxlcihkb20wKTsNCisNCisJc3RhcnR1cF9jcHVf
aWRsZV9sb29wKCk7DQogfQ0KIA0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch04.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch04.diff"


YXJtOiBpbXBsZW1lbnQgeGVuIGluaXQgY29kZQoKIHhlbi9hcmNoL2FybS94ZW4vY3B1LmMg
ICB8ICAgODQgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLQogeGVuL2FyY2gvYXJtL3hlbi9zZXR1
cC5jIHwgIDEwMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQogMiBm
aWxlcyBjaGFuZ2VkLCAxNjcgaW5zZXJ0aW9ucygrKSwgMTggZGVsZXRpb25zKC0pCgpTaWdu
ZWQtb2ZmLWJ5OiBKYWVtaW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KCmRpZmYgLXIg
ZmIwODE1YmE0MGExIHhlbi9hcmNoL2FybS94ZW4vY3B1LmMKLS0tIGEveGVuL2FyY2gvYXJt
L3hlbi9jcHUuYwlGcmkgRmViIDAzIDE2OjI2OjQ5IDIwMTIgKzA5MDAKKysrIGIveGVuL2Fy
Y2gvYXJtL3hlbi9jcHUuYwlGcmkgRmViIDAzIDE3OjI4OjE1IDIwMTIgKzA5MDAKQEAgLTI4
LDYgKzI4LDExIEBACiAjaW5jbHVkZSA8eGVuL3NjaGVkLmg+CiAjaW5jbHVkZSA8eGVuL3By
ZWVtcHQuaD4KICNpbmNsdWRlIDx4ZW4vcGVyY3B1Lmg+CisjaW5jbHVkZSA8YXNtL21tdS5o
PgorI2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+CisjaW5jbHVkZSA8YXNtL2RlbGF5Lmg+Cisj
aW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgorI2luY2x1ZGUgPGFzbS9kZWxheS5oPgogCiBj
cHVtYXNrX3QgY3B1X29ubGluZV9tYXA7CiBjcHVtYXNrX3QgY3B1X3ByZXNlbnRfbWFwOwpA
QCAtNDYsNyArNTEsMTIgQEAgREVGSU5FX1BFUl9DUFVfUkVBRF9NT1NUTFkoY3B1bWFza192
YXJfdAogCiBpbnQgX19jcHVfdXAodW5zaWduZWQgaW50IGNwdSkKIHsKLQlOT1RfWUVUKCk7
CisJaW50IHJldCA9IDA7CisKKwl3aGlsZSghY3B1X29ubGluZShjcHUpKSB7CisJCWNwdV9y
ZWxheCgpOworCQlwcm9jZXNzX3BlbmRpbmdfc29mdGlycXMoKTsKKwl9CiAKIAlyZXR1cm4g
MDsKIH0KQEAgLTYzLDM1ICs3Myw5MyBAQCB2b2lkIF9fY3B1X2RpZSh1bnNpZ25lZCBpbnQg
Y3B1KQogCiB2b2lkIHNldF9jcHVfc2libGluZ19tYXAodW5zaWduZWQgaW50IGNwdSkKIHsK
LQlOT1RfWUVUKCk7CisJdW5zaWduZWQgaW50IGk7CisKKwlmb3JfZWFjaF9wcmVzZW50X2Nw
dShpKSB7CisJCWNwdW1hc2tfc2V0X2NwdShpLCAmcGVyX2NwdShjcHVfc2libGluZ19tYXNr
LCBjcHUpKTsKKwkJY3B1bWFza19zZXRfY3B1KGNwdSwgJnBlcl9jcHUoY3B1X3NpYmxpbmdf
bWFzaywgaSkpOworCisJCWNwdW1hc2tfc2V0X2NwdShpLCAmcGVyX2NwdShjcHVfY29yZV9t
YXNrLCBjcHUpKTsKKwkJY3B1bWFza19zZXRfY3B1KGNwdSwgJnBlcl9jcHUoY3B1X2NvcmVf
bWFzaywgaSkpOworCX0KIH0KIAogdm9pZCBzbXBfcHJlcGFyZV9jcHVzKHVuc2lnbmVkIGlu
dCBtYXhfY3B1cykKIHsKLQlOT1RfWUVUKCk7CisJc2V0X2NwdV9zaWJsaW5nX21hcCgwKTsK
IH0KIAogdm9pZCBzbXBfcHJlcGFyZV9ib290X2NwdSh2b2lkKQogewotCU5PVF9ZRVQoKTsK
KwlpbnQgY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgpOworCisJY3B1bWFza19zZXRfY3B1KGNw
dSwgJmNwdV9vbmxpbmVfbWFwKTsKKwljcHVtYXNrX3NldF9jcHUoY3B1LCAmY3B1X3ByZXNl
bnRfbWFwKTsKKwljcHVtYXNrX3NldF9jcHUoY3B1LCAmY3B1X3Bvc3NpYmxlX21hcCk7CisK
KwljcHVfaW5mb19pbml0KGdldF9jcHVfaW5mbygpKTsKIH0KIAogYXNtbGlua2FnZSB2b2lk
IHN0YXJ0X3hlbl9vbl9zbGF2ZV9jcHUodm9pZCkKIHsKLQlOT1RfWUVUKCk7CisJdW5zaWdu
ZWQgaW50IGNwdTsKKwlzdHJ1Y3QgdmNwdSAqdjsJCisKKwljcHUgPSBzbXBfcHJvY2Vzc29y
X2lkKCk7CisKKyAgICAgICAgLyogaWRsZSB2Y3B1IGlzIGFsbG9jYXRlZCBieSBzY2hlZHVs
ZXJfaW5pdCgpICovCisgICAgICAgIHYgPSBpZGxlX3ZjcHVbY3B1XTsKKwlzZXRfY3VycmVu
dChpZGxlX3ZjcHVbY3B1XSk7CisKKwlzZXRfY3B1X3NpYmxpbmdfbWFwKGNwdSk7CisKKwlu
b3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7CisJd21iKCk7CisKKwljcHVtYXNrX3NldF9jcHUo
Y3B1LCAmY3B1X29ubGluZV9tYXApOworCXdtYigpOworCisJbG9jYWxfaXJxX2VuYWJsZSgp
OworCWxvY2FsX2ZpcV9lbmFibGUoKTsKKworCXN0YXJ0dXBfY3B1X2lkbGVfbG9vcCgpOwog
fQogCiB2b2lkIHNtcF9zZW5kX2V2ZW50X2NoZWNrX21hc2soY29uc3QgY3B1bWFza190ICpt
YXNrKQogewotCU5PVF9ZRVQoKTsKKwlpbnQgY3B1OworCXVuc2lnbmVkIGxvbmcgbWFwID0g
MDsKKworCWZvcl9lYWNoX2NwdShjcHUsIG1hc2spIHsKKwkJbWFwIHw9IDEgPDwgY3B1Owor
CX0KKworCS8qIFRyaWdnZXIgcmVtb3RlIENQVSAqLwogfQogCiB2b2lkIHNtcF9jYWxsX2Z1
bmN0aW9uKHZvaWQgKCpmKSh2b2lkICpwYXJhbSksIHZvaWQgKnBhcmFtLCBpbnQgd2FpdCkK
IHsKLQlOT1RfWUVUKCk7CiB9CiAKIHZvaWQgc21wX3NlbmRfc3RhdGVfZHVtcCh1bnNpZ25l
ZCBpbnQgY3B1KQogewotCU5PVF9ZRVQoKTsKIH0KKwordm9pZCBjcHVfdG9wb2xvZ3lfaW5p
dCh1bnNpZ25lZCBpbnQgY3B1cykKK3sKKwlpbnQgaTsKKworCWlmIChjcHVzID09IDApIHsK
KwkJY3B1cyA9IDE7CisJfQorCisJaWYgKGNwdXMgPiBNQVhfUEhZU19DUFVTKSB7CisJCWNw
dXMgPSBNQVhfUEhZU19DUFVTOworCX0KKworCWZvciAoaSA9IDA7IGkgPCBjcHVzOyBpKysp
IHsKKwkJY3B1bWFza19zZXRfY3B1KGksICZjcHVfcG9zc2libGVfbWFwKTsKKwkJY3B1bWFz
a19zZXRfY3B1KGksICZjcHVfcHJlc2VudF9tYXApOworCX0KK30KKwpkaWZmIC1yIGZiMDgx
NWJhNDBhMSB4ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hl
bi9zZXR1cC5jCUZyaSBGZWIgMDMgMTY6MjY6NDkgMjAxMiArMDkwMAorKysgYi94ZW4vYXJj
aC9hcm0veGVuL3NldHVwLmMJRnJpIEZlYiAwMyAxNzoyODoxNSAyMDEyICswOTAwCkBAIC0z
MCwzNSArMzAsMTE2IEBACiAjaW5jbHVkZSA8eGVuL3ByZWVtcHQuaD4KICNpbmNsdWRlIDxw
dWJsaWMvdmVyc2lvbi5oPgogI2luY2x1ZGUgPHB1YmxpYy9zY2hlZC5oPgotCisjaW5jbHVk
ZSA8YXNtL21tdS5oPgogCiBzdHJ1Y3QgZG9tYWluIF9kb21feGVuID0gewotICAgICAgICAu
cmVmY250ID0gQVRPTUlDX0lOSVQoMSksCi0gICAgICAgIC5kb21haW5faWQgPSBET01JRF9Y
RU4sCi0gICAgICAgIC5kb21haW5fbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRCwKKwkucmVm
Y250ID0gQVRPTUlDX0lOSVQoMSksCisJLmRvbWFpbl9pZCA9IERPTUlEX1hFTiwKKwkuZG9t
YWluX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsCiB9OwogCiBzdHJ1Y3QgZG9tYWluIF9k
b21faW8gPSB7Ci0gICAgICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwKLSAgICAgICAg
LmRvbWFpbl9pZCA9IERPTUlEX0lPLAotICAgICAgICAuZG9tYWluX2xvY2sgPSBTUElOX0xP
Q0tfVU5MT0NLRUQsCisJLnJlZmNudCA9IEFUT01JQ19JTklUKDEpLAorCS5kb21haW5faWQg
PSBET01JRF9JTywKKwkuZG9tYWluX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsCiB9Owog
CiBzdHJ1Y3QgZG9tYWluIF9kb21fY293ID0gewotICAgICAgICAucmVmY250ID0gQVRPTUlD
X0lOSVQoMSksCi0gICAgICAgIC5kb21haW5faWQgPSBET01JRF9DT1csCi0gICAgICAgIC5k
b21haW5fbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRCwKKwkucmVmY250ID0gQVRPTUlDX0lO
SVQoMSksCisJLmRvbWFpbl9pZCA9IERPTUlEX0NPVywKKwkuZG9tYWluX2xvY2sgPSBTUElO
X0xPQ0tfVU5MT0NLRUQsCiB9OwogCiBzdHJ1Y3QgZG9tYWluICpkb21feGVuID0gJl9kb21f
eGVuOwogc3RydWN0IGRvbWFpbiAqZG9tX2lvID0gJl9kb21faW87CiBzdHJ1Y3QgZG9tYWlu
ICpkb21fY293ID0gJl9kb21fY293OwogCisvKiBtYXhjcHVzOiBtYXhpbXVtIG51bWJlciBv
ZiBDUFVzIHRvIGJlIGFjdGl2YXRlZCAqLworc3RhdGljIHVuc2lnbmVkIGludCBtYXhfY3B1
cyA9IE5SX0NQVVM7CitpbnRlZ2VyX3BhcmFtKCJtYXhjcHVzIiwgbWF4X2NwdXMpOworCisv
KiBEZWZhdWx0IGRvbWFpbiBzaXplID0gNjRNQiAqLworc3RhdGljIHVuc2lnbmVkIGludCBk
b20wX3NpemUgPSAyNTYgKiAxMDI0ICogMTAyNDsKK2ludGVnZXJfcGFyYW0oImRvbTBfc2l6
ZSIsIGRvbTBfc2l6ZSk7CisKKy8vc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFnZV9z
dGFydCA9IDB4NDBCMDAwMDBVTDsKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c3RhcnQgPSAweDAwQjAwMDAwVUw7CitpbnRlZ2VyX3BhcmFtKCJpbWFnZV9zdGFydCIsIGRv
bTBfaW1hZ2Vfc3RhcnQpOworCisvL3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c2l6ZSA9IDB4QTAwMDAwVUw7CitzdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3Np
emUgPSAweEEwMDAwMFVMOworaW50ZWdlcl9wYXJhbSgiaW1hZ2VfbGVuZ3RoIiwgZG9tMF9p
bWFnZV9zaXplKTsKKwogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVz
X2luZm9fdCAqaW5mbykKIHsKIH0KIAorc3RhdGljIHZvaWQgaWRsZV9kb21haW5faW5pdCh2
b2lkKQoreworCXN0cnVjdCB2Y3B1ICp2OworCisJc2NoZWR1bGVyX2luaXQoKTsKKworCS8q
IGlkbGUgdmNwdSBpcyBhbGxvY2F0ZWQgYnkgc2NoZWR1bGVyX2luaXQoKSAqLworCXYgPSBp
ZGxlX3ZjcHVbMF07CisKKwlzZXRfY3VycmVudF92Y3B1KHYpOworfQorCiBhc21saW5rYWdl
IHZvaWQgc3RhcnRfeGVuKHZvaWQpCiB7CisJdW5zaWduZWQgaW50IGk7CisKKwlzbXBfcHJl
cGFyZV9ib290X2NwdSgpOworCisJc29mdGlycV9pbml0KCk7CisKKwl0YXNrbGV0X3N1YnN5
c19pbml0KCk7CisKKwl0aW1lcl9pbml0KCk7CisKKwlpZGxlX2RvbWFpbl9pbml0KCk7CisK
KwlyY3VfaW5pdCgpOworCisJbG9jYWxfaXJxX2VuYWJsZSgpOworCisJc21wX3ByZXBhcmVf
Y3B1cyhtYXhfY3B1cyk7CisKKwlkb19wcmVzbXBfaW5pdGNhbGxzKCk7CisKKwl0aW1la2Vl
cGluZ19pbml0KCk7CisKKwlmb3JfZWFjaF9wcmVzZW50X2NwdShpKSB7CisJCWlmIChudW1f
b25saW5lX2NwdXMoKSA8IG1heF9jcHVzICYmICFjcHVfb25saW5lKGkpKSB7CisJCQlpbnQg
cmV0ID0gY3B1X3VwKGkpOworCQorCQkJaWYgKHJldCAhPSAwKSB7CisJCQkJcHJpbnRrKCJG
YWlsIHRvIGJyaW5nIHVwIENQVSAldSAoZXJyb3IgJWQpXG4iLCBpLCByZXQpOworCQkJfQor
CQl9CisJfQorCisJcHJpbnRrKCJCcm91Z2h0IHVwICVsZCBDUFVzXG4iLCAobG9uZyludW1f
b25saW5lX2NwdXMoKSk7CisKKwlkb19pbml0Y2FsbHMoKTsKKworCWRvbTAgPSBkb21haW5f
Y3JlYXRlKDAsIDAsIDApOworCWlmIChkb20wID09IE5VTEwpIHsKKwkJcGFuaWMoIkRvbWFp
biBjcmVhdGlvbiBmYWlsZWRcbiIpOworCX0KKworCisJaWYgKGRvbWFpbl9jb25zdHJ1Y3Qo
ZG9tMCwKKwkJCSAgICAgZG9tMF9pbWFnZV9zdGFydCwgCisJCQkgICAgIGRvbTBfaW1hZ2Vf
c2l6ZSwgCisJCQkgICAgIGRvbTBfc2l6ZSwgCisJCQkgICAgIG1heF9jcHVzKSkgeworCQlQ
QU5JQygiRG9tYWluIGNvbnN0cnVjdGlvbiBmYWlsZWRcbiIpOworCX0KKworCWRvbWFpbl91
bnBhdXNlX2J5X3N5c3RlbWNvbnRyb2xsZXIoZG9tMCk7CisKKwlzdGFydHVwX2NwdV9pZGxl
X2xvb3AoKTsKIH0KIAo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt1A-00061Z-3h; Mon, 13 Feb 2012 10:20:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqxx-00048o-Dq
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:08:53 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329120523!13095854!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25106 invoked from network); 13 Feb 2012 08:08:46 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-11.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 08:08:46 -0000
Received: from epcpsbge2.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005LVNUTEV60@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:08:43 +0900 (KST)
Message-id: <0LZB005PRNYJEV60@mailout1.samsung.com>
X-AuditID: cbfee60c-b7c83ae000001e65-2d-4f38c50bacf6
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge2.samsung.com (EPCPMTA) with SMTP id 5C.DF.07781.B05C83F4;
	Mon, 13 Feb 2012 17:08:43 +0900 (KST)
Date: Mon, 13 Feb 2012 08:08:43 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080806499@jm77.ryu
Msgkey: 20120213080806499@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213074805604@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 01/14]  arm: start working on ARM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <31461408.70521329120519895.JavaMail.weblogic@epv6ml04>

YXJtOiBzdGFydCB3b3JraW5nIG9uIEFSTS4NCg0KQ29uZmlnLm1rICAgICAgICAgICAgICAgICB8
ICAxICsNCnhlbi9SdWxlcy5tayAgICAgICAgICAgICAgfCAgMiArLQ0KeGVuL2NvbW1vbi9rZXhl
Yy5jICAgICAgICB8ICAyICsrDQp4ZW4vY29tbW9uL3N5c2N0bC5jICAgICAgIHwgIDggKysrKysr
KysNCnhlbi9jb21tb24vdG1lbV94ZW4uYyAgICAgfCAgMiArLQ0KeGVuL2RyaXZlcnMvTWFrZWZp
bGUgICAgICB8ICAyICsrDQp4ZW4vZHJpdmVycy9jaGFyL01ha2VmaWxlIHwgIDIgKysNCnhlbi9p
bmNsdWRlL3B1YmxpYy94ZW4uaCAgfCAgMiArKw0KeGVuL2luY2x1ZGUveGVuL2xpYmVsZi5oICB8
ICAyICstDQo5IGZpbGVzIGNoYW5nZWQsIDIwIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0p
DQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgDQoNCmRpZmYgLXIgYjNkZTgyYjM1MTg5IENv
bmZpZy5taw0KLS0tIGEvQ29uZmlnLm1rIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMA0K
KysrIGIvQ29uZmlnLm1rIEZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMA0KQEAgLTE1LDYg
KzE1LDcgQEAgZGVidWcgPz0geQ0KWEVOX0NPTVBJTEVfQVJDSCAgICA/PSAkKHNoZWxsIHVuYW1l
IC1tIHwgc2VkIC1lIHMvaS44Ni94ODZfMzIvIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
LWUgcy9pODZwYy94ODZfMzIvIC1lIHMvYW1kNjQveDg2XzY0LykNClhFTl9UQVJHRVRfQVJDSCAg
ICAgPz0gJChYRU5fQ09NUElMRV9BUkNIKQ0KK1hFTl9UQVJHRVRfU1VCQVJDSCAgPz0gJChYRU5f
VEFSR0VUX0FSQ0gpDQpYRU5fT1MgICAgICAgICAgICAgID89ICQoc2hlbGwgdW5hbWUgLXMpDQoN
CkNPTkZJR18kKFhFTl9PUykgOj0geQ0KZGlmZiAtciBiM2RlODJiMzUxODkgeGVuL1J1bGVzLm1r
DQotLS0gYS94ZW4vUnVsZXMubWsgICAgICBGcmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDAN
CisrKyBiL3hlbi9SdWxlcy5tayAgICAgIEZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMA0K
QEAgLTI2LDkgKzI2LDkgQEAgcGVyZmMgOj0geQ0KZW5kaWYNCg0KIyBTZXQgQVJDSC9TVUJBUkNI
IGFwcHJvcHJpYXRlbHkuDQotb3ZlcnJpZGUgVEFSR0VUX1NVQkFSQ0ggIDo9ICQoWEVOX1RBUkdF
VF9BUkNIKQ0Kb3ZlcnJpZGUgVEFSR0VUX0FSQ0ggICAgIDo9ICQoc2hlbGwgZWNobyAkKFhFTl9U
QVJHRVRfQVJDSCkgfCBcDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VkIC1lICdz
L3g4Ni4qL3g4Ni8nKQ0KK292ZXJyaWRlIFRBUkdFVF9TVUJBUkNIICA6PSAkKFhFTl9UQVJHRVRf
U1VCQVJDSCkNCg0KVEFSR0VUIDo9ICQoQkFTRURJUikveGVuDQoNCmRpZmYgLXIgYjNkZTgyYjM1
MTg5IHhlbi9jb21tb24va2V4ZWMuYw0KLS0tIGEveGVuL2NvbW1vbi9rZXhlYy5jICAgICAgICBG
cmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9jb21tb24va2V4ZWMuYyAg
ICAgICAgRnJpIEZlYiAwMyAxNTo1Mjo0MCAyMDEyICswOTAwDQpAQCAtMjExLDcgKzIxMSw5IEBA
IHN0YXRpYyB2b2lkIGtleGVjX2NvbW1vbl9zaHV0ZG93bih2b2lkKQ0KICAgICBjb25zb2xlX3N0
YXJ0X3N5bmMoKTsNCiAgICAgc3Bpbl9kZWJ1Z19kaXNhYmxlKCk7DQogICAgIG9uZV9jcHVfb25s
eSgpOw0KKyNpZiAhZGVmaW5lZChfX2FybV9fKQ0KICAgICBhY3BpX2RtYXJfcmVpbnN0YXRlKCk7
DQorI2VuZGlmDQp9DQoNCnZvaWQga2V4ZWNfY3Jhc2godm9pZCkNCmRpZmYgLXIgYjNkZTgyYjM1
MTg5IHhlbi9jb21tb24vc3lzY3RsLmMNCi0tLSBhL3hlbi9jb21tb24vc3lzY3RsLmMgICAgICAg
RnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICswOTAwDQorKysgYi94ZW4vY29tbW9uL3N5c2N0bC5j
ICAgICAgIEZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMA0KQEAgLTIyNiw2ICsyMjYsNyBA
QCBsb25nIGRvX3N5c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNjDQoNCiAgICAgY2FzZSBY
RU5fU1lTQ1RMX2dldF9wbXN0YXQ6DQogICAgIHsNCisjaWYgIWRlZmluZWQoX19hcm1fXykNCiAg
ICAgICAgIHJldCA9IHhzbV9nZXRfcG1zdGF0KCk7DQogICAgICAgICBpZiAoIHJldCApDQogICAg
ICAgICAgICAgYnJlYWs7DQpAQCAtMjM5LDExICsyNDAsMTUgQEAgbG9uZyBkb19zeXNjdGwoWEVO
X0dVRVNUX0hBTkRMRSh4ZW5fc3lzYw0KICAgICAgICAgICAgIHJldCA9IC1FRkFVTFQ7DQogICAg
ICAgICAgICAgYnJlYWs7DQogICAgICAgICB9DQorI2Vsc2UNCisgICAgICAgcmV0ID0gLUVJTlZB
TDsNCisjZW5kaWYNCiAgICAgfQ0KICAgICBicmVhazsNCg0KICAgICBjYXNlIFhFTl9TWVNDVExf
cG1fb3A6DQogICAgIHsNCisjaWYgIWRlZmluZWQoX19hcm1fXykNCiAgICAgICAgIHJldCA9IHhz
bV9wbV9vcCgpOw0KICAgICAgICAgaWYgKCByZXQgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KQEAg
LTI1Nyw2ICsyNjIsOSBAQCBsb25nIGRvX3N5c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNj
DQogICAgICAgICAgICAgcmV0ID0gLUVGQVVMVDsNCiAgICAgICAgICAgICBicmVhazsNCiAgICAg
ICAgIH0NCisjZWxzZQ0KKyAgICAgICByZXQgPSAtRUlOVkFMOw0KKyNlbmRpZg0KICAgICB9DQog
ICAgIGJyZWFrOw0KDQpkaWZmIC1yIGIzZGU4MmIzNTE4OSB4ZW4vY29tbW9uL3RtZW1feGVuLmMN
Ci0tLSBhL3hlbi9jb21tb24vdG1lbV94ZW4uYyAgICAgRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEy
ICswOTAwDQorKysgYi94ZW4vY29tbW9uL3RtZW1feGVuLmMgICAgIEZyaSBGZWIgMDMgMTU6NTI6
NDAgMjAxMiArMDkwMA0KQEAgLTg3LDcgKzg3LDcgQEAgdm9pZCB0bWhfY29weV9wYWdlKGNoYXIg
KnRvLCBjaGFyKmZyb20pDQojZW5kaWYNCn0NCg0KLSNpZmRlZiBfX2lhNjRfXw0KKyNpZiBkZWZp
bmVkKF9faWE2NF9fKSB8fCBkZWZpbmVkKF9fYXJtX18pDQpzdGF0aWMgaW5saW5lIHZvaWQgKmNs
aV9nZXRfcGFnZSh0bWVtX2NsaV9tZm5fdCBjbWZuLCB1bnNpZ25lZCBsb25nICpwY2xpX21mbiwN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZnBfdCAqKnBjbGlfcGZwLCBib29s
X3QgY2xpX3dyaXRlKQ0Kew0KZGlmZiAtciBiM2RlODJiMzUxODkgeGVuL2RyaXZlcnMvTWFrZWZp
bGUNCi0tLSBhL3hlbi9kcml2ZXJzL01ha2VmaWxlICAgICAgRnJpIEZlYiAwMyAxMjoyMTowOSAy
MDEyICswOTAwDQorKysgYi94ZW4vZHJpdmVycy9NYWtlZmlsZSAgICAgIEZyaSBGZWIgMDMgMTU6
NTI6NDAgMjAxMiArMDkwMA0KQEAgLTEsNiArMSw4IEBADQpzdWJkaXIteSArPSBjaGFyDQoraWZu
ZXEgKCQoVEFSR0VUX0FSQ0gpLGFybSkNCnN1YmRpci15ICs9IGNwdWZyZXENCnN1YmRpci15ICs9
IHBjaQ0Kc3ViZGlyLXkgKz0gcGFzc3Rocm91Z2gNCnN1YmRpci0kKEhBU19BQ1BJKSArPSBhY3Bp
DQpzdWJkaXItJChIQVNfVkdBKSArPSB2aWRlbw0KK2VuZGlmDQpkaWZmIC1yIGIzZGU4MmIzNTE4
OSB4ZW4vZHJpdmVycy9jaGFyL01ha2VmaWxlDQotLS0gYS94ZW4vZHJpdmVycy9jaGFyL01ha2Vm
aWxlIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMA0KKysrIGIveGVuL2RyaXZlcnMvY2hh
ci9NYWtlZmlsZSBGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDANCkBAIC0xLDMgKzEsNSBA
QA0Kb2JqLXkgKz0gY29uc29sZS5vDQoraWZuZXEgKCQoVEFSR0VUX0FSQ0gpLGFybSkNCm9iai15
ICs9IG5zMTY1NTAubw0KK2VuZGlmDQpvYmoteSArPSBzZXJpYWwubw0KZGlmZiAtciBiM2RlODJi
MzUxODkgeGVuL2luY2x1ZGUvcHVibGljL3hlbi5oDQotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
eGVuLmggIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMA0KKysrIGIveGVuL2luY2x1ZGUv
cHVibGljL3hlbi5oICBGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDANCkBAIC0zMyw2ICsz
Myw4IEBADQojaW5jbHVkZSAiYXJjaC14ODYveGVuLmgiDQojZWxpZiBkZWZpbmVkKF9faWE2NF9f
KQ0KI2luY2x1ZGUgImFyY2gtaWE2NC5oIg0KKyNlbGlmIGRlZmluZWQoX19hcm1fXykNCisjaW5j
bHVkZSAiYXJjaC1hcm0uaCINCiNlbHNlDQojZXJyb3IgIlVuc3VwcG9ydGVkIGFyY2hpdGVjdHVy
ZSINCiNlbmRpZg0KZGlmZiAtciBiM2RlODJiMzUxODkgeGVuL2luY2x1ZGUveGVuL2xpYmVsZi5o
DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vbGliZWxmLmggIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAx
MiArMDkwMA0KKysrIGIveGVuL2luY2x1ZGUveGVuL2xpYmVsZi5oICBGcmkgRmViIDAzIDE1OjUy
OjQwIDIwMTIgKzA5MDANCkBAIC0yMyw3ICsyMyw3IEBADQojaWZuZGVmIF9fWEVOX0xJQkVMRl9I
X18NCiNkZWZpbmUgX19YRU5fTElCRUxGX0hfXw0KDQotI2lmIGRlZmluZWQoX19pMzg2X18pIHx8
IGRlZmluZWQoX194ODZfNjRfXykgfHwgZGVmaW5lZChfX2lhNjRfXykNCisjaWYgZGVmaW5lZChf
X2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82NF9fKSB8fCBkZWZpbmVkKF9faWE2NF9fKSB8fCBk
ZWZpbmVkKF9fYXJtX18pDQojZGVmaW5lIFhFTl9FTEZfTElUVExFX0VORElBTg0KI2Vsc2UNCiNl
cnJvciBkZWZpbmUgYXJjaGl0ZWN0dXJhbCBlbmRpYW5uZXNz


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch01.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch01.diff"


YXJtOiBzdGFydCB3b3JraW5nIG9uIEFSTS4KCiBDb25maWcubWsgICAgICAgICAgICAgICAg
IHwgIDEgKwogeGVuL1J1bGVzLm1rICAgICAgICAgICAgICB8ICAyICstCiB4ZW4vY29tbW9u
L2tleGVjLmMgICAgICAgIHwgIDIgKysKIHhlbi9jb21tb24vc3lzY3RsLmMgICAgICAgfCAg
OCArKysrKysrKwogeGVuL2NvbW1vbi90bWVtX3hlbi5jICAgICB8ICAyICstCiB4ZW4vZHJp
dmVycy9NYWtlZmlsZSAgICAgIHwgIDIgKysKIHhlbi9kcml2ZXJzL2NoYXIvTWFrZWZpbGUg
fCAgMiArKwogeGVuL2luY2x1ZGUvcHVibGljL3hlbi5oICB8ICAyICsrCiB4ZW4vaW5jbHVk
ZS94ZW4vbGliZWxmLmggIHwgIDIgKy0KIDkgZmlsZXMgY2hhbmdlZCwgMjAgaW5zZXJ0aW9u
cygrKSwgMyBkZWxldGlvbnMoLSkKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcu
cnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciBiM2RlODJiMzUxODkgQ29uZmlnLm1rCi0tLSBh
L0NvbmZpZy5tawlGcmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDAKKysrIGIvQ29uZmln
Lm1rCUZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMApAQCAtMTUsNiArMTUsNyBAQCBk
ZWJ1ZyA/PSB5CiBYRU5fQ09NUElMRV9BUkNIICAgID89ICQoc2hlbGwgdW5hbWUgLW0gfCBz
ZWQgLWUgcy9pLjg2L3g4Nl8zMi8gXAogICAgICAgICAgICAgICAgICAgICAgICAgIC1lIHMv
aTg2cGMveDg2XzMyLyAtZSBzL2FtZDY0L3g4Nl82NC8pCiBYRU5fVEFSR0VUX0FSQ0ggICAg
ID89ICQoWEVOX0NPTVBJTEVfQVJDSCkKK1hFTl9UQVJHRVRfU1VCQVJDSCAgPz0gJChYRU5f
VEFSR0VUX0FSQ0gpCiBYRU5fT1MgICAgICAgICAgICAgID89ICQoc2hlbGwgdW5hbWUgLXMp
CiAKIENPTkZJR18kKFhFTl9PUykgOj0geQpkaWZmIC1yIGIzZGU4MmIzNTE4OSB4ZW4vUnVs
ZXMubWsKLS0tIGEveGVuL1J1bGVzLm1rCUZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkw
MAorKysgYi94ZW4vUnVsZXMubWsJRnJpIEZlYiAwMyAxNTo1Mjo0MCAyMDEyICswOTAwCkBA
IC0yNiw5ICsyNiw5IEBAIHBlcmZjIDo9IHkKIGVuZGlmCiAKICMgU2V0IEFSQ0gvU1VCQVJD
SCBhcHByb3ByaWF0ZWx5Lgotb3ZlcnJpZGUgVEFSR0VUX1NVQkFSQ0ggIDo9ICQoWEVOX1RB
UkdFVF9BUkNIKQogb3ZlcnJpZGUgVEFSR0VUX0FSQ0ggICAgIDo9ICQoc2hlbGwgZWNobyAk
KFhFTl9UQVJHRVRfQVJDSCkgfCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
ZWQgLWUgJ3MveDg2LioveDg2LycpCitvdmVycmlkZSBUQVJHRVRfU1VCQVJDSCAgOj0gJChY
RU5fVEFSR0VUX1NVQkFSQ0gpCiAKIFRBUkdFVCA6PSAkKEJBU0VESVIpL3hlbgogCmRpZmYg
LXIgYjNkZTgyYjM1MTg5IHhlbi9jb21tb24va2V4ZWMuYwotLS0gYS94ZW4vY29tbW9uL2tl
eGVjLmMJRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICswOTAwCisrKyBiL3hlbi9jb21tb24v
a2V4ZWMuYwlGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDAKQEAgLTIxMSw3ICsyMTEs
OSBAQCBzdGF0aWMgdm9pZCBrZXhlY19jb21tb25fc2h1dGRvd24odm9pZCkKICAgICBjb25z
b2xlX3N0YXJ0X3N5bmMoKTsKICAgICBzcGluX2RlYnVnX2Rpc2FibGUoKTsKICAgICBvbmVf
Y3B1X29ubHkoKTsKKyNpZiAhZGVmaW5lZChfX2FybV9fKQogICAgIGFjcGlfZG1hcl9yZWlu
c3RhdGUoKTsKKyNlbmRpZgogfQogCiB2b2lkIGtleGVjX2NyYXNoKHZvaWQpCmRpZmYgLXIg
YjNkZTgyYjM1MTg5IHhlbi9jb21tb24vc3lzY3RsLmMKLS0tIGEveGVuL2NvbW1vbi9zeXNj
dGwuYwlGcmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDAKKysrIGIveGVuL2NvbW1vbi9z
eXNjdGwuYwlGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDAKQEAgLTIyNiw2ICsyMjYs
NyBAQCBsb25nIGRvX3N5c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNjCiAKICAgICBj
YXNlIFhFTl9TWVNDVExfZ2V0X3Btc3RhdDoKICAgICB7CisjaWYgIWRlZmluZWQoX19hcm1f
XykKICAgICAgICAgcmV0ID0geHNtX2dldF9wbXN0YXQoKTsKICAgICAgICAgaWYgKCByZXQg
KQogICAgICAgICAgICAgYnJlYWs7CkBAIC0yMzksMTEgKzI0MCwxNSBAQCBsb25nIGRvX3N5
c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNjCiAgICAgICAgICAgICByZXQgPSAtRUZB
VUxUOwogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIH0KKyNlbHNlCisJcmV0ID0gLUVJ
TlZBTDsKKyNlbmRpZgogICAgIH0KICAgICBicmVhazsKIAogICAgIGNhc2UgWEVOX1NZU0NU
TF9wbV9vcDoKICAgICB7CisjaWYgIWRlZmluZWQoX19hcm1fXykKICAgICAgICAgcmV0ID0g
eHNtX3BtX29wKCk7CiAgICAgICAgIGlmICggcmV0ICkKICAgICAgICAgICAgIGJyZWFrOwpA
QCAtMjU3LDYgKzI2Miw5IEBAIGxvbmcgZG9fc3lzY3RsKFhFTl9HVUVTVF9IQU5ETEUoeGVu
X3N5c2MKICAgICAgICAgICAgIHJldCA9IC1FRkFVTFQ7CiAgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgfQorI2Vsc2UKKwlyZXQgPSAtRUlOVkFMOworI2VuZGlmCiAgICAgfQogICAg
IGJyZWFrOwogCmRpZmYgLXIgYjNkZTgyYjM1MTg5IHhlbi9jb21tb24vdG1lbV94ZW4uYwot
LS0gYS94ZW4vY29tbW9uL3RtZW1feGVuLmMJRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICsw
OTAwCisrKyBiL3hlbi9jb21tb24vdG1lbV94ZW4uYwlGcmkgRmViIDAzIDE1OjUyOjQwIDIw
MTIgKzA5MDAKQEAgLTg3LDcgKzg3LDcgQEAgdm9pZCB0bWhfY29weV9wYWdlKGNoYXIgKnRv
LCBjaGFyKmZyb20pCiAjZW5kaWYKIH0KIAotI2lmZGVmIF9faWE2NF9fCisjaWYgZGVmaW5l
ZChfX2lhNjRfXykgfHwgZGVmaW5lZChfX2FybV9fKQogc3RhdGljIGlubGluZSB2b2lkICpj
bGlfZ2V0X3BhZ2UodG1lbV9jbGlfbWZuX3QgY21mbiwgdW5zaWduZWQgbG9uZyAqcGNsaV9t
Zm4sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZnBfdCAqKnBjbGlfcGZw
LCBib29sX3QgY2xpX3dyaXRlKQogewpkaWZmIC1yIGIzZGU4MmIzNTE4OSB4ZW4vZHJpdmVy
cy9NYWtlZmlsZQotLS0gYS94ZW4vZHJpdmVycy9NYWtlZmlsZQlGcmkgRmViIDAzIDEyOjIx
OjA5IDIwMTIgKzA5MDAKKysrIGIveGVuL2RyaXZlcnMvTWFrZWZpbGUJRnJpIEZlYiAwMyAx
NTo1Mjo0MCAyMDEyICswOTAwCkBAIC0xLDYgKzEsOCBAQAogc3ViZGlyLXkgKz0gY2hhcgor
aWZuZXEgKCQoVEFSR0VUX0FSQ0gpLGFybSkKIHN1YmRpci15ICs9IGNwdWZyZXEKIHN1YmRp
ci15ICs9IHBjaQogc3ViZGlyLXkgKz0gcGFzc3Rocm91Z2gKIHN1YmRpci0kKEhBU19BQ1BJ
KSArPSBhY3BpCiBzdWJkaXItJChIQVNfVkdBKSArPSB2aWRlbworZW5kaWYKZGlmZiAtciBi
M2RlODJiMzUxODkgeGVuL2RyaXZlcnMvY2hhci9NYWtlZmlsZQotLS0gYS94ZW4vZHJpdmVy
cy9jaGFyL01ha2VmaWxlCUZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMAorKysgYi94
ZW4vZHJpdmVycy9jaGFyL01ha2VmaWxlCUZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkw
MApAQCAtMSwzICsxLDUgQEAKIG9iai15ICs9IGNvbnNvbGUubworaWZuZXEgKCQoVEFSR0VU
X0FSQ0gpLGFybSkKIG9iai15ICs9IG5zMTY1NTAubworZW5kaWYKIG9iai15ICs9IHNlcmlh
bC5vCmRpZmYgLXIgYjNkZTgyYjM1MTg5IHhlbi9pbmNsdWRlL3B1YmxpYy94ZW4uaAotLS0g
YS94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgJRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICsw
OTAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy94ZW4uaAlGcmkgRmViIDAzIDE1OjUyOjQw
IDIwMTIgKzA5MDAKQEAgLTMzLDYgKzMzLDggQEAKICNpbmNsdWRlICJhcmNoLXg4Ni94ZW4u
aCIKICNlbGlmIGRlZmluZWQoX19pYTY0X18pCiAjaW5jbHVkZSAiYXJjaC1pYTY0LmgiCisj
ZWxpZiBkZWZpbmVkKF9fYXJtX18pCisjaW5jbHVkZSAiYXJjaC1hcm0uaCIKICNlbHNlCiAj
ZXJyb3IgIlVuc3VwcG9ydGVkIGFyY2hpdGVjdHVyZSIKICNlbmRpZgpkaWZmIC1yIGIzZGU4
MmIzNTE4OSB4ZW4vaW5jbHVkZS94ZW4vbGliZWxmLmgKLS0tIGEveGVuL2luY2x1ZGUveGVu
L2xpYmVsZi5oCUZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMAorKysgYi94ZW4vaW5j
bHVkZS94ZW4vbGliZWxmLmgJRnJpIEZlYiAwMyAxNTo1Mjo0MCAyMDEyICswOTAwCkBAIC0y
Myw3ICsyMyw3IEBACiAjaWZuZGVmIF9fWEVOX0xJQkVMRl9IX18KICNkZWZpbmUgX19YRU5f
TElCRUxGX0hfXwogCi0jaWYgZGVmaW5lZChfX2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82
NF9fKSB8fCBkZWZpbmVkKF9faWE2NF9fKQorI2lmIGRlZmluZWQoX19pMzg2X18pIHx8IGRl
ZmluZWQoX194ODZfNjRfXykgfHwgZGVmaW5lZChfX2lhNjRfXykgfHwgZGVmaW5lZChfX2Fy
bV9fKQogI2RlZmluZSBYRU5fRUxGX0xJVFRMRV9FTkRJQU4KICNlbHNlCiAjZXJyb3IgZGVm
aW5lIGFyY2hpdGVjdHVyYWwgZW5kaWFubmVzcwo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt17-0005yg-Mj; Mon, 13 Feb 2012 10:20:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqqx-0003tY-MV
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:01:40 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329120091!14416772!2
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3831 invoked from network); 13 Feb 2012 08:01:33 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-10.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 08:01:33 -0000
Received: from epcpsbge3.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00GAKNJAR6E0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:01:31 +0900 (KST)
Message-id: <0LZB00GFHNMJR6E0@mailout2.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-82-4f38c35b3628
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 2E.6D.17710.B53C83F4;
	Mon, 13 Feb 2012 17:01:31 +0900 (KST)
Date: Mon, 13 Feb 2012 08:01:31 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080044709@jm77.ryu
Msgkey: 20120213080044709@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075949918@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 09/14]  arm: implement cache ops for ARMv7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <23280134.70181329120087475.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgY2FjaGUgb3BzIGZvciBBUk12Nw0KDQogeGVuL2FyY2gvYXJtL3hlbi9N
YWtlZmlsZSAgIHwgICAxICsNCiB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMgfCAgOTQgKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIDIgZmlsZXMgY2hhbmdlZCwgOTUgaW5z
ZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkNCg0KU2lnbmVkLW9mZi1ieTogSmFlbWluIFJ5dSA8
am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgMTVhYWEyMGUxNGJmIHhlbi9hcmNoL2Fy
bS94ZW4vTWFrZWZpbGUNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUJU3VuIEZlYiAx
MiAxMTo1NTowNCAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCVN1
biBGZWIgMTIgMTI6MDU6MTYgMjAxMiArMDkwMA0KQEAgLTIyLDMgKzIyLDQgQEAgb2JqLXkgKz0g
cDJtLm8NCiBvYmoteSArPSBwZXJmbW9uLm8NCiBvYmoteSArPSBwY2kubw0KIG9iai15ICs9IGFy
bXY3Lm8NCitvYmoteSArPSBjYWNoZS12Ny5vDQpkaWZmIC1yIDE1YWFhMjBlMTRiZiB4ZW4vYXJj
aC9hcm0veGVuL2NhY2hlLXY3LlMNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMJU3VuIEZlYiAxMiAx
MjowNToxNiAyMDEyICswOTAwDQpAQCAtMCwwICsxLDk0IEBADQorI2luY2x1ZGUgPHhlbi9saW5r
YWdlLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFzbS9jcHUtb3BzLmg+
DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+
DQorDQorCS5tYWNybyB2N193YXlfb3AsIG9wDQorCWRtYgkJCQkJQCBlbnN1cmUgb3JkZXJpbmcg
d2l0aCBwcmV2aW91cyBtZW1vcnkgYWNjZXNzZXMNCisJbXJjCXAxNSwgMSwgcjAsIGMwLCBjMCwg
MQkJQCByZWFkIGNsaWRyDQorCWFuZHMJcjMsIHIwLCAjMHg3MDAwMDAwCQlAIGV4dHJhY3QgbG9j
IGZyb20gY2xpZHINCisJbW92CXIzLCByMywgbHNyICMyMwkJCUAgbGVmdCBhbGlnbiBsb2MgYml0
IGZpZWxkDQorCWJlcQk1MGYJCQkJQCBpZiBsb2MgaXMgMCwgdGhlbiBubyBuZWVkIHRvIGNsZWFu
DQorCW1vdglyMTAsICMwCQkJCUAgc3RhcnQgY2xlYW4gYXQgY2FjaGUgbGV2ZWwgMA0KKzEwOg0K
KwlhZGQJcjIsIHIxMCwgcjEwLCBsc3IgIzEJCUAgd29yayBvdXQgM3ggY3VycmVudCBjYWNoZSBs
ZXZlbA0KKwltb3YJcjEsIHIwLCBsc3IgcjIJCQlAIGV4dHJhY3QgY2FjaGUgdHlwZSBiaXRzIGZy
b20gY2xpZHINCisJYW5kCXIxLCByMSwgIzcJCQlAIG1hc2sgb2YgdGhlIGJpdHMgZm9yIGN1cnJl
bnQgY2FjaGUgb25seQ0KKwljbXAJcjEsICMyCQkJCUAgc2VlIHdoYXQgY2FjaGUgd2UgaGF2ZSBh
dCB0aGlzIGxldmVsDQorCWJsdAk0MGYJCQkJQCBza2lwIGlmIG5vIGNhY2hlLCBvciBqdXN0IGkt
Y2FjaGUNCisJbWNyCXAxNSwgMiwgcjEwLCBjMCwgYzAsIDAJCUAgc2VsZWN0IGN1cnJlbnQgY2Fj
aGUgbGV2ZWwgaW4gY3Nzcg0KKwlpc2IJCQkJCUAgaXNiIHRvIHN5Y2ggdGhlIG5ldyBjc3NyJmNz
aWRyDQorCW1yYwlwMTUsIDEsIHIxLCBjMCwgYzAsIDAJCUAgcmVhZCB0aGUgbmV3IGNzaWRyDQor
CWFuZAlyMiwgcjEsICM3CQkJQCBleHRyYWN0IHRoZSBsZW5ndGggb2YgdGhlIGNhY2hlIGxpbmVz
DQorCWFkZAlyMiwgcjIsICM0CQkJQCBhZGQgNCAobGluZSBsZW5ndGggb2Zmc2V0KQ0KKwlsZHIJ
cjQsID0weDNmZg0KKwlhbmRzCXI0LCByNCwgcjEsIGxzciAjMwkJQCBmaW5kIG1heGltdW0gbnVt
YmVyIG9uIHRoZSB3YXkgc2l6ZQ0KKwljbHoJcjUsIHI0CQkJCUAgZmluZCBiaXQgcG9zaXRpb24g
b2Ygd2F5IHNpemUgaW5jcmVtZW50DQorCWxkcglyNywgPTB4N2ZmZg0KKwlhbmRzCXI3LCByNywg
cjEsIGxzciAjMTMJCUAgZXh0cmFjdCBtYXggbnVtYmVyIG9mIHRoZSBpbmRleCBzaXplDQorMjA6
DQorCW1vdglyOSwgcjQJCQkJQCBjcmVhdGUgd29ya2luZyBjb3B5IG9mIG1heCB3YXkgc2l6ZQ0K
KzMwOg0KKwlvcnIJcjExLCByMTAsIHI5LCBsc2wgcjUJCUAgZmFjdG9yIHdheSBhbmQgY2FjaGUg
bnVtYmVyIGludG8gcjExDQorCW9ycglyMTEsIHIxMSwgcjcsIGxzbCByMgkJQCBmYWN0b3IgaW5k
ZXggbnVtYmVyIGludG8gcjExDQorCW1jcglwMTUsIDAsIHIxMSwgYzcsIFxvcCAsIDIJQCBjbGVh
biAmIGludmFsaWRhdGUgYnkgc2V0L3dheQ0KKwlzdWJzCXI5LCByOSwgIzEJCQlAIGRlY3JlbWVu
dCB0aGUgd2F5DQorCWJnZQkzMGINCisJc3VicwlyNywgcjcsICMxCQkJQCBkZWNyZW1lbnQgdGhl
IGluZGV4DQorCWJnZQkyMGINCis0MDoNCisJYWRkCXIxMCwgcjEwLCAjMgkJCUAgaW5jcmVtZW50
IGNhY2hlIG51bWJlcg0KKwljbXAJcjMsIHIxMA0KKwliZ3QJMTBiDQorNTA6DQorCW1vdglyMTAs
ICMwCQkJCUAgc3dpdGggYmFjayB0byBjYWNoZSBsZXZlbCAwDQorCW1jcglwMTUsIDIsIHIxMCwg
YzAsIGMwLCAwCQlAIHNlbGVjdCBjdXJyZW50IGNhY2hlIGxldmVsIGluIGNzc3INCisJZHNiDQor
CWlzYg0KKwkuZW5kbQ0KKwkudGV4dA0KKw0KK1BSSVZBVEUodjdfZmx1c2hfY2FjaGVfYWxsKQ0K
KwlzdG1mZAlzcCEsIHtyNC1yNSwgcjcsIHI5LXIxMSwgbHJ9DQorDQorCXY3X3dheV9vcCBjMTQN
CisNCisJbW92CXIwLCAjMA0KKwltY3IJcDE1LCAwLCByMCwgYzcsIGM1LCAwCQlAIEkrQlRCIGNh
Y2hlIGludmFsaWRhdGUNCisJbGRtZmQJc3AhLCB7cjQtcjUsIHI3LCByOS1yMTEsIGxyfQ0KKwlt
b3YJcGMsIGxyDQorDQorREVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNoX2NhY2hlX2FsbCwgdjdfZmx1
c2hfY2FjaGVfYWxsKQ0KKw0KK1BSSVZBVEUodjdfZmx1c2hfY2FjaGVfcmFuZ2UpDQorCW1yYyAg
ICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUg0KKwlhbmQgICAgIHIzLCByMywg
IzcJCUAgY2FjaGUgbGluZSBzaXplIGVuY29kaW5nDQorCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6
ZSBvZmZzZXQNCisJbW92ICAgICByMiwgcjIsIGxzbCByMwkJQCBhY3R1YWwgY2FjaGUgbGluZSBz
aXplDQorMToNCisJbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTQsIDEJCUAgY2xlYW4gJiBpbnZhbGlk
YXRlIEQgbGluZSAvIHVuaWZpZWQgbGluZQ0KKwlhZGQJcjAsIHIwLCByMg0KKwljbXAJcjAsIHIx
DQorCWJsbwkxYg0KKwlkc2INCisJbW92CXBjLCBscg0KKw0KK0RFQ0xBUkVfQ1BVX09QKGNwdV9m
bHVzaF9jYWNoZV9yYW5nZSwgdjdfZmx1c2hfY2FjaGVfcmFuZ2UpDQorDQorUFJJVkFURSh2N19j
bGVhbl9jYWNoZV9yYW5nZSkNCisJbXJjICAgICBwMTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFk
IENTSURSDQorCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcN
CisJbW92ICAgICByMywgIzE2CQkJQCBzaXplIG9mZnNldA0KKwltb3YgICAgIHIyLCByMiwgbHNs
IHIzCQlAIGFjdHVhbCBjYWNoZSBsaW5lIHNpemUNCisNCisxOg0KKwltY3IJcDE1LCAwLCByMCwg
YzcsIGMxMCwgMQkJQCBjbGVhbiBEIGVudHJ5DQorCWFkZAlyMCwgcjAsIHIyDQorCWNtcAlyMCwg
cjENCisJYmxvCTFiDQorCWRzYg0KKwltb3YJcGMsIGxyDQorDQorREVDTEFSRV9DUFVfT1AoY3B1
X2NsZWFuX2NhY2hlX3JhbmdlLCB2N19jbGVhbl9jYWNoZV9yYW5nZSkNCisNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch09.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch09.diff"


YXJtOiBpbXBsZW1lbnQgY2FjaGUgb3BzIGZvciBBUk12NwoKIHhlbi9hcmNoL2FybS94ZW4v
TWFrZWZpbGUgICB8ICAgMSArCiB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMgfCAgOTQg
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogMiBmaWxlcyBjaGFuZ2Vk
LCA5NSBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKU2lnbmVkLW9mZi1ieTogSmFl
bWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CgpkaWZmIC1yIDE1YWFhMjBlMTRiZiB4
ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUJU3VuIEZlYiAxMiAxMTo1NTowNCAyMDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94
ZW4vTWFrZWZpbGUJU3VuIEZlYiAxMiAxMjowNToxNiAyMDEyICswOTAwCkBAIC0yMiwzICsy
Miw0IEBAIG9iai15ICs9IHAybS5vCiBvYmoteSArPSBwZXJmbW9uLm8KIG9iai15ICs9IHBj
aS5vCiBvYmoteSArPSBhcm12Ny5vCitvYmoteSArPSBjYWNoZS12Ny5vCmRpZmYgLXIgMTVh
YWEyMGUxNGJmIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUwotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2Nh
Y2hlLXY3LlMJU3VuIEZlYiAxMiAxMjowNToxNiAyMDEyICswOTAwCkBAIC0wLDAgKzEsOTQg
QEAKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorI2luY2x1ZGUgPGFzbS9wYWdlLmg+Cisj
aW5jbHVkZSA8YXNtL2NwdS1vcHMuaD4KKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CisjaW5j
bHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+CisKKwkubWFjcm8gdjdfd2F5X29wLCBvcAorCWRt
YgkJCQkJQCBlbnN1cmUgb3JkZXJpbmcgd2l0aCBwcmV2aW91cyBtZW1vcnkgYWNjZXNzZXMK
KwltcmMJcDE1LCAxLCByMCwgYzAsIGMwLCAxCQlAIHJlYWQgY2xpZHIKKwlhbmRzCXIzLCBy
MCwgIzB4NzAwMDAwMAkJQCBleHRyYWN0IGxvYyBmcm9tIGNsaWRyCisJbW92CXIzLCByMywg
bHNyICMyMwkJCUAgbGVmdCBhbGlnbiBsb2MgYml0IGZpZWxkCisJYmVxCTUwZgkJCQlAIGlm
IGxvYyBpcyAwLCB0aGVuIG5vIG5lZWQgdG8gY2xlYW4KKwltb3YJcjEwLCAjMAkJCQlAIHN0
YXJ0IGNsZWFuIGF0IGNhY2hlIGxldmVsIDAKKzEwOgorCWFkZAlyMiwgcjEwLCByMTAsIGxz
ciAjMQkJQCB3b3JrIG91dCAzeCBjdXJyZW50IGNhY2hlIGxldmVsCisJbW92CXIxLCByMCwg
bHNyIHIyCQkJQCBleHRyYWN0IGNhY2hlIHR5cGUgYml0cyBmcm9tIGNsaWRyCisJYW5kCXIx
LCByMSwgIzcJCQlAIG1hc2sgb2YgdGhlIGJpdHMgZm9yIGN1cnJlbnQgY2FjaGUgb25seQor
CWNtcAlyMSwgIzIJCQkJQCBzZWUgd2hhdCBjYWNoZSB3ZSBoYXZlIGF0IHRoaXMgbGV2ZWwK
KwlibHQJNDBmCQkJCUAgc2tpcCBpZiBubyBjYWNoZSwgb3IganVzdCBpLWNhY2hlCisJbWNy
CXAxNSwgMiwgcjEwLCBjMCwgYzAsIDAJCUAgc2VsZWN0IGN1cnJlbnQgY2FjaGUgbGV2ZWwg
aW4gY3NzcgorCWlzYgkJCQkJQCBpc2IgdG8gc3ljaCB0aGUgbmV3IGNzc3ImY3NpZHIKKwlt
cmMJcDE1LCAxLCByMSwgYzAsIGMwLCAwCQlAIHJlYWQgdGhlIG5ldyBjc2lkcgorCWFuZAly
MiwgcjEsICM3CQkJQCBleHRyYWN0IHRoZSBsZW5ndGggb2YgdGhlIGNhY2hlIGxpbmVzCisJ
YWRkCXIyLCByMiwgIzQJCQlAIGFkZCA0IChsaW5lIGxlbmd0aCBvZmZzZXQpCisJbGRyCXI0
LCA9MHgzZmYKKwlhbmRzCXI0LCByNCwgcjEsIGxzciAjMwkJQCBmaW5kIG1heGltdW0gbnVt
YmVyIG9uIHRoZSB3YXkgc2l6ZQorCWNseglyNSwgcjQJCQkJQCBmaW5kIGJpdCBwb3NpdGlv
biBvZiB3YXkgc2l6ZSBpbmNyZW1lbnQKKwlsZHIJcjcsID0weDdmZmYKKwlhbmRzCXI3LCBy
NywgcjEsIGxzciAjMTMJCUAgZXh0cmFjdCBtYXggbnVtYmVyIG9mIHRoZSBpbmRleCBzaXpl
CisyMDoKKwltb3YJcjksIHI0CQkJCUAgY3JlYXRlIHdvcmtpbmcgY29weSBvZiBtYXggd2F5
IHNpemUKKzMwOgorCW9ycglyMTEsIHIxMCwgcjksIGxzbCByNQkJQCBmYWN0b3Igd2F5IGFu
ZCBjYWNoZSBudW1iZXIgaW50byByMTEKKwlvcnIJcjExLCByMTEsIHI3LCBsc2wgcjIJCUAg
ZmFjdG9yIGluZGV4IG51bWJlciBpbnRvIHIxMQorCW1jcglwMTUsIDAsIHIxMSwgYzcsIFxv
cCAsIDIJQCBjbGVhbiAmIGludmFsaWRhdGUgYnkgc2V0L3dheQorCXN1YnMJcjksIHI5LCAj
MQkJCUAgZGVjcmVtZW50IHRoZSB3YXkKKwliZ2UJMzBiCisJc3VicwlyNywgcjcsICMxCQkJ
QCBkZWNyZW1lbnQgdGhlIGluZGV4CisJYmdlCTIwYgorNDA6CisJYWRkCXIxMCwgcjEwLCAj
MgkJCUAgaW5jcmVtZW50IGNhY2hlIG51bWJlcgorCWNtcAlyMywgcjEwCisJYmd0CTEwYgor
NTA6CisJbW92CXIxMCwgIzAJCQkJQCBzd2l0aCBiYWNrIHRvIGNhY2hlIGxldmVsIDAKKwlt
Y3IJcDE1LCAyLCByMTAsIGMwLCBjMCwgMAkJQCBzZWxlY3QgY3VycmVudCBjYWNoZSBsZXZl
bCBpbiBjc3NyCisJZHNiCisJaXNiCisJLmVuZG0KKwkudGV4dAorCitQUklWQVRFKHY3X2Zs
dXNoX2NhY2hlX2FsbCkKKwlzdG1mZAlzcCEsIHtyNC1yNSwgcjcsIHI5LXIxMSwgbHJ9CisK
Kwl2N193YXlfb3AgYzE0CisKKwltb3YJcjAsICMwCisJbWNyCXAxNSwgMCwgcjAsIGM3LCBj
NSwgMAkJQCBJK0JUQiBjYWNoZSBpbnZhbGlkYXRlCisJbGRtZmQJc3AhLCB7cjQtcjUsIHI3
LCByOS1yMTEsIGxyfQorCW1vdglwYywgbHIKKworREVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNo
X2NhY2hlX2FsbCwgdjdfZmx1c2hfY2FjaGVfYWxsKQorCitQUklWQVRFKHY3X2ZsdXNoX2Nh
Y2hlX3JhbmdlKQorCW1yYyAgICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lE
UgorCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcKKwlt
b3YgICAgIHIzLCAjMTYJCQlAIHNpemUgb2Zmc2V0CisJbW92ICAgICByMiwgcjIsIGxzbCBy
MwkJQCBhY3R1YWwgY2FjaGUgbGluZSBzaXplCisxOgorCW1jcglwMTUsIDAsIHIwLCBjNywg
YzE0LCAxCQlAIGNsZWFuICYgaW52YWxpZGF0ZSBEIGxpbmUgLyB1bmlmaWVkIGxpbmUKKwlh
ZGQJcjAsIHIwLCByMgorCWNtcAlyMCwgcjEKKwlibG8JMWIKKwlkc2IKKwltb3YJcGMsIGxy
CisKK0RFQ0xBUkVfQ1BVX09QKGNwdV9mbHVzaF9jYWNoZV9yYW5nZSwgdjdfZmx1c2hfY2Fj
aGVfcmFuZ2UpCisKK1BSSVZBVEUodjdfY2xlYW5fY2FjaGVfcmFuZ2UpCisJbXJjICAgICBw
MTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFkIENTSURSCisJYW5kICAgICByMywgcjMsICM3
CQlAIGNhY2hlIGxpbmUgc2l6ZSBlbmNvZGluZworCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6
ZSBvZmZzZXQKKwltb3YgICAgIHIyLCByMiwgbHNsIHIzCQlAIGFjdHVhbCBjYWNoZSBsaW5l
IHNpemUKKworMToKKwltY3IJcDE1LCAwLCByMCwgYzcsIGMxMCwgMQkJQCBjbGVhbiBEIGVu
dHJ5CisJYWRkCXIwLCByMCwgcjIKKwljbXAJcjAsIHIxCisJYmxvCTFiCisJZHNiCisJbW92
CXBjLCBscgorCitERUNMQVJFX0NQVV9PUChjcHVfY2xlYW5fY2FjaGVfcmFuZ2UsIHY3X2Ns
ZWFuX2NhY2hlX3JhbmdlKQorCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt19-00060L-9M; Mon, 13 Feb 2012 10:20:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqvH-00044e-En
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:06:07 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329120359!15075500!1
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22947 invoked from network); 13 Feb 2012 08:06:00 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-12.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 08:06:00 -0000
Received: from epcpsbge6.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB002TDNLD9NB0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:05:37 +0900 (KST)
Message-id: <0LZB0024ZNTD9NC0@mailout2.samsung.com>
X-AuditID: cbfee610-b7b53ae000003b1c-26-4f38c44e2b56
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge6.samsung.com (EPCPMTA) with SMTP id 31.C9.15132.E44C83F4;
	Mon, 13 Feb 2012 17:05:34 +0900 (KST)
Date: Mon, 13 Feb 2012 08:05:34 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080444730@jm77.ryu
Msgkey: 20120213080444730@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080356110@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 13/14]  arm: implement miscellaneous stuffs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <5484515.70401329120331271.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgbWlzY2VsbGFuZW91cyBzdHVmZnMNCg0KIHhlbi9hcmNoL2FybS94ZW4v
YXJjaF9kb21haW4uYyB8ICA2ICsrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUyAg
ICB8ICA0ICsrLS0NCiB4ZW4vYXJjaC9hcm0veGVuL21tLmMgICAgICAgICAgfCAgMiArKw0KIHhl
bi9hcmNoL2FybS94ZW4vc2V0dXAuYyAgICAgICB8ICAxICsNCiB4ZW4vYXJjaC9hcm0veGVuL3N0
YXJ0LlMgICAgICAgfCAgOSArKysrKysrKysNCiA1IGZpbGVzIGNoYW5nZWQsIDIwIGluc2VydGlv
bnMoKyksIDIgZGVsZXRpb25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcu
cnl1QHNhbXN1bmcuY29tPg0KDQpkaWZmIC1yIDU0ODhlNGZmNDViZSB4ZW4vYXJjaC9hcm0veGVu
L2FyY2hfZG9tYWluLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21haW4uYwlTdW4g
RmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9k
b21haW4uYwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDANCkBAIC0xOTksNiArMTk5LDEy
IEBAIHZvaWQgY29udGV4dF9zd2l0Y2goc3RydWN0IHZjcHUgKnByZXYsIHMNCiAJQVNTRVJUKHBy
ZXYgIT0gbmV4dCk7DQogCUFTU0VSVCh2Y3B1X3J1bm5hYmxlKG5leHQpKTsNCiANCisJaWYgKCFp
c19pZGxlX2RvbWFpbihuZXh0LT5kb21haW4pKSB7DQorCQlzZXRfdHRicihuZXh0LT5hcmNoLmN0
eC50dGJyMCk7DQorCQljcHVfZmx1c2hfdGxiX2FsbCgpOw0KKwkJLyogVE9ETyA6IENQVSBleGNs
dXNpdmUgbW9uaXRvciBzaG91bGQgYmUgY2xlYXJlZC4gKi8NCisJfQ0KKw0KICAgICAgICAgcHJl
diA9ICBzd2l0Y2hfdG8ocHJldiwgJnByZXYtPmFyY2guY3R4LCAmbmV4dC0+YXJjaC5jdHgpOw0K
IH0NCiANCmRpZmYgLXIgNTQ4OGU0ZmY0NWJlIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUw0K
LS0tIGEveGVuL2FyY2gvYXJtL3hlbi9jYWNoZS12Ny5TCVN1biBGZWIgMTIgMTU6MTM6MjkgMjAx
MiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9jYWNoZS12Ny5TCVN1biBGZWIgMTIgMTU6
NDg6NTcgMjAxMiArMDkwMA0KQEAgLTYxLDcgKzYxLDcgQEAgRU5UUlkoY3B1X2ZsdXNoX2NhY2hl
X2FsbCkNCiBFTlRSWShjcHVfZmx1c2hfY2FjaGVfcmFuZ2UpDQogCW1yYyAgICAgcDE1LCAxLCBy
MywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUg0KIAlhbmQgICAgIHIzLCByMywgIzcJCUAgY2FjaGUg
bGluZSBzaXplIGVuY29kaW5nDQotCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6ZSBvZmZzZXQNCisJ
bW92ICAgICByMiwgIzE2CQkJQCBzaXplIG9mZnNldA0KIAltb3YgICAgIHIyLCByMiwgbHNsIHIz
CQlAIGFjdHVhbCBjYWNoZSBsaW5lIHNpemUNCiAxOg0KIAltY3IJcDE1LCAwLCByMCwgYzcsIGMx
NCwgMQkJQCBjbGVhbiAmIGludmFsaWRhdGUgRCBsaW5lIC8gdW5pZmllZCBsaW5lDQpAQCAtNzQs
NyArNzQsNyBAQCAxOg0KIEVOVFJZKGNwdV9jbGVhbl9jYWNoZV9yYW5nZSkNCiAJbXJjICAgICBw
MTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFkIENTSURSDQogCWFuZCAgICAgcjMsIHIzLCAjNwkJ
QCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcNCi0JbW92ICAgICByMywgIzE2CQkJQCBzaXplIG9m
ZnNldA0KKwltb3YgICAgIHIyLCAjMTYJCQlAIHNpemUgb2Zmc2V0DQogCW1vdiAgICAgcjIsIHIy
LCBsc2wgcjMJCUAgYWN0dWFsIGNhY2hlIGxpbmUgc2l6ZQ0KIA0KIDE6DQpkaWZmIC1yIDU0ODhl
NGZmNDViZSB4ZW4vYXJjaC9hcm0veGVuL21tLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vbW0u
YwlTdW4gRmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4v
bW0uYwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDANCkBAIC0yNjYsNiArMjY2LDggQEAg
dW5zaWduZWQgbG9uZyBhbGxvY19wYWdlX3RhYmxlcyhsMWVfdCAqbA0KIAkJcmV0dXJuIDA7DQog
CX0NCiANCisJY3B1X2NsZWFuX2NhY2hlX3JhbmdlKHBhZ2UsIHBhZ2UgKyBQQUdFX1NJWkUpOw0K
Kw0KIAl3aXJlX3BhZ2VfdGFibGVzKGwxZSwgcGFnZSk7DQogDQogCXJldHVybiBwYWdlOw0KZGlm
ZiAtciA1NDg4ZTRmZjQ1YmUgeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jDQotLS0gYS94ZW4vYXJj
aC9hcm0veGVuL3NldHVwLmMJU3VuIEZlYiAxMiAxNToxMzoyOSAyMDEyICswOTAwDQorKysgYi94
ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMJU3VuIEZlYiAxMiAxNTo0ODo1NyAyMDEyICswOTAwDQpA
QCAtMTk1LDYgKzE5NSw3IEBAIHN0YXRpYyB2b2lkIGlkbGVfZG9tYWluX2luaXQodm9pZCkNCiAN
CiAJLyogaWRsZSB2Y3B1IGlzIGFsbG9jYXRlZCBieSBzY2hlZHVsZXJfaW5pdCgpICovDQogCXYg
PSBpZGxlX3ZjcHVbMF07DQorCVZDUFVfUkVHKHYsIHR0YnIwKSA9IGdldF90dGJyKCk7DQogDQog
CXNldF9jdXJyZW50X3ZjcHUodik7DQogfQ0KZGlmZiAtciA1NDg4ZTRmZjQ1YmUgeGVuL2FyY2gv
YXJtL3hlbi9zdGFydC5TDQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJU3VuIEZlYiAx
MiAxNToxMzoyOSAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJU3Vu
IEZlYiAxMiAxNTo0ODo1NyAyMDEyICswOTAwDQpAQCAtMTI4LDYgKzEyOCwxMSBAQCAzOg0KIAlt
Y3IJcDE1LCAwLCByNSwgYzEwLCBjMiwgMA0KIAltY3IJcDE1LCAwLCByNiwgYzEwLCBjMiwgMQ0K
IA0KKyAgICAgICAgQCBTZXR1cCBFeGNlcHRpb24gVmVjdG9yIFRhYmxlDQorICAgICAgICBsZHIg
ICAgIGlwLCA9ZXhjZXB0aW9uX3ZlY3Rvcl90YWJsZQ0KKyAgICAgICAgbWNyICAgICBWQkFSKGlw
KQ0KKw0KKw0KIAlAIFR1cm4gb24gTU1VDQogCWxkcglyMCwgPShTQ1RMUl9UUkUgfCBTQ1RMUl9T
VyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJfQyB8IFNDVExSX0EgfCBTQ1RMUl9NKQ0KIAlt
Y3IJU0NUTFIocjApDQpAQCAtMjE5LDYgKzIyNCwxMCBAQCBFTlRSWShzbGF2ZV9jcHVfc3RhcnQp
DQogCW1jcglwMTUsIDAsIHI1LCBjMTAsIGMyLCAwDQogCW1jcglwMTUsIDAsIHI2LCBjMTAsIGMy
LCAxDQogDQorICAgICAgICBAIFNldHVwIEV4Y2VwdGlvbiBWZWN0b3IgVGFibGUNCisgICAgICAg
IGxkciAgICAgaXAsID1leGNlcHRpb25fdmVjdG9yX3RhYmxlDQorICAgICAgICBtY3IgICAgIFZC
QVIoaXApDQorDQogCUAgVHVybiBvbiBNTVUNCiAJbGRyCXIwLCA9KFNDVExSX1RSRSB8IFNDVExS
X1NXIHwgU0NUTFJfWiB8IFNDVExSX0kgfCBTQ1RMUl9DIHwgU0NUTFJfQSB8IFNDVExSX00pDQog
CW1jcglTQ1RMUihyMCkNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch13.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch13.diff"


YXJtOiBpbXBsZW1lbnQgbWlzY2VsbGFuZW91cyBzdHVmZnMKCiB4ZW4vYXJjaC9hcm0veGVu
L2FyY2hfZG9tYWluLmMgfCAgNiArKysrKysKIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcu
UyAgICB8ICA0ICsrLS0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICB8ICAyICsr
CiB4ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMgICAgICAgfCAgMSArCiB4ZW4vYXJjaC9hcm0v
eGVuL3N0YXJ0LlMgICAgICAgfCAgOSArKysrKysrKysKIDUgZmlsZXMgY2hhbmdlZCwgMjAg
aW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBS
eXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciA1NDg4ZTRmZjQ1YmUgeGVuL2Fy
Y2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9k
b21haW4uYwlTdW4gRmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9hcmNoX2RvbWFpbi5jCVN1biBGZWIgMTIgMTU6NDg6NTcgMjAxMiArMDkwMApA
QCAtMTk5LDYgKzE5OSwxMiBAQCB2b2lkIGNvbnRleHRfc3dpdGNoKHN0cnVjdCB2Y3B1ICpw
cmV2LCBzCiAJQVNTRVJUKHByZXYgIT0gbmV4dCk7CiAJQVNTRVJUKHZjcHVfcnVubmFibGUo
bmV4dCkpOwogCisJaWYgKCFpc19pZGxlX2RvbWFpbihuZXh0LT5kb21haW4pKSB7CisJCXNl
dF90dGJyKG5leHQtPmFyY2guY3R4LnR0YnIwKTsKKwkJY3B1X2ZsdXNoX3RsYl9hbGwoKTsK
KwkJLyogVE9ETyA6IENQVSBleGNsdXNpdmUgbW9uaXRvciBzaG91bGQgYmUgY2xlYXJlZC4g
Ki8KKwl9CisKICAgICAgICAgcHJldiA9ICBzd2l0Y2hfdG8ocHJldiwgJnByZXYtPmFyY2gu
Y3R4LCAmbmV4dC0+YXJjaC5jdHgpOwogfQogCmRpZmYgLXIgNTQ4OGU0ZmY0NWJlIHhlbi9h
cmNoL2FybS94ZW4vY2FjaGUtdjcuUwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3
LlMJU3VuIEZlYiAxMiAxNToxMzoyOSAyMDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94
ZW4vY2FjaGUtdjcuUwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDAKQEAgLTYxLDcg
KzYxLDcgQEAgRU5UUlkoY3B1X2ZsdXNoX2NhY2hlX2FsbCkKIEVOVFJZKGNwdV9mbHVzaF9j
YWNoZV9yYW5nZSkKIAltcmMgICAgIHAxNSwgMSwgcjMsIGMwLCBjMCwgMAlAIHJlYWQgQ1NJ
RFIKIAlhbmQgICAgIHIzLCByMywgIzcJCUAgY2FjaGUgbGluZSBzaXplIGVuY29kaW5nCi0J
bW92ICAgICByMywgIzE2CQkJQCBzaXplIG9mZnNldAorCW1vdiAgICAgcjIsICMxNgkJCUAg
c2l6ZSBvZmZzZXQKIAltb3YgICAgIHIyLCByMiwgbHNsIHIzCQlAIGFjdHVhbCBjYWNoZSBs
aW5lIHNpemUKIDE6CiAJbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTQsIDEJCUAgY2xlYW4gJiBp
bnZhbGlkYXRlIEQgbGluZSAvIHVuaWZpZWQgbGluZQpAQCAtNzQsNyArNzQsNyBAQCAxOgog
RU5UUlkoY3B1X2NsZWFuX2NhY2hlX3JhbmdlKQogCW1yYyAgICAgcDE1LCAxLCByMywgYzAs
IGMwLCAwCUAgcmVhZCBDU0lEUgogCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5l
IHNpemUgZW5jb2RpbmcKLQltb3YgICAgIHIzLCAjMTYJCQlAIHNpemUgb2Zmc2V0CisJbW92
ICAgICByMiwgIzE2CQkJQCBzaXplIG9mZnNldAogCW1vdiAgICAgcjIsIHIyLCBsc2wgcjMJ
CUAgYWN0dWFsIGNhY2hlIGxpbmUgc2l6ZQogCiAxOgpkaWZmIC1yIDU0ODhlNGZmNDViZSB4
ZW4vYXJjaC9hcm0veGVuL21tLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9tbS5jCVN1biBG
ZWIgMTIgMTU6MTM6MjkgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL21tLmMJ
U3VuIEZlYiAxMiAxNTo0ODo1NyAyMDEyICswOTAwCkBAIC0yNjYsNiArMjY2LDggQEAgdW5z
aWduZWQgbG9uZyBhbGxvY19wYWdlX3RhYmxlcyhsMWVfdCAqbAogCQlyZXR1cm4gMDsKIAl9
CiAKKwljcHVfY2xlYW5fY2FjaGVfcmFuZ2UocGFnZSwgcGFnZSArIFBBR0VfU0laRSk7CisK
IAl3aXJlX3BhZ2VfdGFibGVzKGwxZSwgcGFnZSk7CiAKIAlyZXR1cm4gcGFnZTsKZGlmZiAt
ciA1NDg4ZTRmZjQ1YmUgeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCi0tLSBhL3hlbi9hcmNo
L2FybS94ZW4vc2V0dXAuYwlTdW4gRmViIDEyIDE1OjEzOjI5IDIwMTIgKzA5MDAKKysrIGIv
eGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCVN1biBGZWIgMTIgMTU6NDg6NTcgMjAxMiArMDkw
MApAQCAtMTk1LDYgKzE5NSw3IEBAIHN0YXRpYyB2b2lkIGlkbGVfZG9tYWluX2luaXQodm9p
ZCkKIAogCS8qIGlkbGUgdmNwdSBpcyBhbGxvY2F0ZWQgYnkgc2NoZWR1bGVyX2luaXQoKSAq
LwogCXYgPSBpZGxlX3ZjcHVbMF07CisJVkNQVV9SRUcodiwgdHRicjApID0gZ2V0X3R0YnIo
KTsKIAogCXNldF9jdXJyZW50X3ZjcHUodik7CiB9CmRpZmYgLXIgNTQ4OGU0ZmY0NWJlIHhl
bi9hcmNoL2FybS94ZW4vc3RhcnQuUwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJ
U3VuIEZlYiAxMiAxNToxMzoyOSAyMDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4v
c3RhcnQuUwlTdW4gRmViIDEyIDE1OjQ4OjU3IDIwMTIgKzA5MDAKQEAgLTEyOCw2ICsxMjgs
MTEgQEAgMzoKIAltY3IJcDE1LCAwLCByNSwgYzEwLCBjMiwgMAogCW1jcglwMTUsIDAsIHI2
LCBjMTAsIGMyLCAxCiAKKyAgICAgICAgQCBTZXR1cCBFeGNlcHRpb24gVmVjdG9yIFRhYmxl
CisgICAgICAgIGxkciAgICAgaXAsID1leGNlcHRpb25fdmVjdG9yX3RhYmxlCisgICAgICAg
IG1jciAgICAgVkJBUihpcCkKKworCiAJQCBUdXJuIG9uIE1NVQogCWxkcglyMCwgPShTQ1RM
Ul9UUkUgfCBTQ1RMUl9TVyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJfQyB8IFNDVExS
X0EgfCBTQ1RMUl9NKQogCW1jcglTQ1RMUihyMCkKQEAgLTIxOSw2ICsyMjQsMTAgQEAgRU5U
Ulkoc2xhdmVfY3B1X3N0YXJ0KQogCW1jcglwMTUsIDAsIHI1LCBjMTAsIGMyLCAwCiAJbWNy
CXAxNSwgMCwgcjYsIGMxMCwgYzIsIDEKIAorICAgICAgICBAIFNldHVwIEV4Y2VwdGlvbiBW
ZWN0b3IgVGFibGUKKyAgICAgICAgbGRyICAgICBpcCwgPWV4Y2VwdGlvbl92ZWN0b3JfdGFi
bGUKKyAgICAgICAgbWNyICAgICBWQkFSKGlwKQorCiAJQCBUdXJuIG9uIE1NVQogCWxkcgly
MCwgPShTQ1RMUl9UUkUgfCBTQ1RMUl9TVyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJf
QyB8IFNDVExSX0EgfCBTQ1RMUl9NKQogCW1jcglTQ1RMUihyMCkK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt1A-00061Z-3h; Mon, 13 Feb 2012 10:20:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqxx-00048o-Dq
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:08:53 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329120523!13095854!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25106 invoked from network); 13 Feb 2012 08:08:46 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-11.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 08:08:46 -0000
Received: from epcpsbge2.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005LVNUTEV60@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:08:43 +0900 (KST)
Message-id: <0LZB005PRNYJEV60@mailout1.samsung.com>
X-AuditID: cbfee60c-b7c83ae000001e65-2d-4f38c50bacf6
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge2.samsung.com (EPCPMTA) with SMTP id 5C.DF.07781.B05C83F4;
	Mon, 13 Feb 2012 17:08:43 +0900 (KST)
Date: Mon, 13 Feb 2012 08:08:43 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080806499@jm77.ryu
Msgkey: 20120213080806499@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213074805604@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 01/14]  arm: start working on ARM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <31461408.70521329120519895.JavaMail.weblogic@epv6ml04>

YXJtOiBzdGFydCB3b3JraW5nIG9uIEFSTS4NCg0KQ29uZmlnLm1rICAgICAgICAgICAgICAgICB8
ICAxICsNCnhlbi9SdWxlcy5tayAgICAgICAgICAgICAgfCAgMiArLQ0KeGVuL2NvbW1vbi9rZXhl
Yy5jICAgICAgICB8ICAyICsrDQp4ZW4vY29tbW9uL3N5c2N0bC5jICAgICAgIHwgIDggKysrKysr
KysNCnhlbi9jb21tb24vdG1lbV94ZW4uYyAgICAgfCAgMiArLQ0KeGVuL2RyaXZlcnMvTWFrZWZp
bGUgICAgICB8ICAyICsrDQp4ZW4vZHJpdmVycy9jaGFyL01ha2VmaWxlIHwgIDIgKysNCnhlbi9p
bmNsdWRlL3B1YmxpYy94ZW4uaCAgfCAgMiArKw0KeGVuL2luY2x1ZGUveGVuL2xpYmVsZi5oICB8
ICAyICstDQo5IGZpbGVzIGNoYW5nZWQsIDIwIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0p
DQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgDQoNCmRpZmYgLXIgYjNkZTgyYjM1MTg5IENv
bmZpZy5taw0KLS0tIGEvQ29uZmlnLm1rIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMA0K
KysrIGIvQ29uZmlnLm1rIEZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMA0KQEAgLTE1LDYg
KzE1LDcgQEAgZGVidWcgPz0geQ0KWEVOX0NPTVBJTEVfQVJDSCAgICA/PSAkKHNoZWxsIHVuYW1l
IC1tIHwgc2VkIC1lIHMvaS44Ni94ODZfMzIvIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
LWUgcy9pODZwYy94ODZfMzIvIC1lIHMvYW1kNjQveDg2XzY0LykNClhFTl9UQVJHRVRfQVJDSCAg
ICAgPz0gJChYRU5fQ09NUElMRV9BUkNIKQ0KK1hFTl9UQVJHRVRfU1VCQVJDSCAgPz0gJChYRU5f
VEFSR0VUX0FSQ0gpDQpYRU5fT1MgICAgICAgICAgICAgID89ICQoc2hlbGwgdW5hbWUgLXMpDQoN
CkNPTkZJR18kKFhFTl9PUykgOj0geQ0KZGlmZiAtciBiM2RlODJiMzUxODkgeGVuL1J1bGVzLm1r
DQotLS0gYS94ZW4vUnVsZXMubWsgICAgICBGcmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDAN
CisrKyBiL3hlbi9SdWxlcy5tayAgICAgIEZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMA0K
QEAgLTI2LDkgKzI2LDkgQEAgcGVyZmMgOj0geQ0KZW5kaWYNCg0KIyBTZXQgQVJDSC9TVUJBUkNI
IGFwcHJvcHJpYXRlbHkuDQotb3ZlcnJpZGUgVEFSR0VUX1NVQkFSQ0ggIDo9ICQoWEVOX1RBUkdF
VF9BUkNIKQ0Kb3ZlcnJpZGUgVEFSR0VUX0FSQ0ggICAgIDo9ICQoc2hlbGwgZWNobyAkKFhFTl9U
QVJHRVRfQVJDSCkgfCBcDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VkIC1lICdz
L3g4Ni4qL3g4Ni8nKQ0KK292ZXJyaWRlIFRBUkdFVF9TVUJBUkNIICA6PSAkKFhFTl9UQVJHRVRf
U1VCQVJDSCkNCg0KVEFSR0VUIDo9ICQoQkFTRURJUikveGVuDQoNCmRpZmYgLXIgYjNkZTgyYjM1
MTg5IHhlbi9jb21tb24va2V4ZWMuYw0KLS0tIGEveGVuL2NvbW1vbi9rZXhlYy5jICAgICAgICBG
cmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9jb21tb24va2V4ZWMuYyAg
ICAgICAgRnJpIEZlYiAwMyAxNTo1Mjo0MCAyMDEyICswOTAwDQpAQCAtMjExLDcgKzIxMSw5IEBA
IHN0YXRpYyB2b2lkIGtleGVjX2NvbW1vbl9zaHV0ZG93bih2b2lkKQ0KICAgICBjb25zb2xlX3N0
YXJ0X3N5bmMoKTsNCiAgICAgc3Bpbl9kZWJ1Z19kaXNhYmxlKCk7DQogICAgIG9uZV9jcHVfb25s
eSgpOw0KKyNpZiAhZGVmaW5lZChfX2FybV9fKQ0KICAgICBhY3BpX2RtYXJfcmVpbnN0YXRlKCk7
DQorI2VuZGlmDQp9DQoNCnZvaWQga2V4ZWNfY3Jhc2godm9pZCkNCmRpZmYgLXIgYjNkZTgyYjM1
MTg5IHhlbi9jb21tb24vc3lzY3RsLmMNCi0tLSBhL3hlbi9jb21tb24vc3lzY3RsLmMgICAgICAg
RnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICswOTAwDQorKysgYi94ZW4vY29tbW9uL3N5c2N0bC5j
ICAgICAgIEZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMA0KQEAgLTIyNiw2ICsyMjYsNyBA
QCBsb25nIGRvX3N5c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNjDQoNCiAgICAgY2FzZSBY
RU5fU1lTQ1RMX2dldF9wbXN0YXQ6DQogICAgIHsNCisjaWYgIWRlZmluZWQoX19hcm1fXykNCiAg
ICAgICAgIHJldCA9IHhzbV9nZXRfcG1zdGF0KCk7DQogICAgICAgICBpZiAoIHJldCApDQogICAg
ICAgICAgICAgYnJlYWs7DQpAQCAtMjM5LDExICsyNDAsMTUgQEAgbG9uZyBkb19zeXNjdGwoWEVO
X0dVRVNUX0hBTkRMRSh4ZW5fc3lzYw0KICAgICAgICAgICAgIHJldCA9IC1FRkFVTFQ7DQogICAg
ICAgICAgICAgYnJlYWs7DQogICAgICAgICB9DQorI2Vsc2UNCisgICAgICAgcmV0ID0gLUVJTlZB
TDsNCisjZW5kaWYNCiAgICAgfQ0KICAgICBicmVhazsNCg0KICAgICBjYXNlIFhFTl9TWVNDVExf
cG1fb3A6DQogICAgIHsNCisjaWYgIWRlZmluZWQoX19hcm1fXykNCiAgICAgICAgIHJldCA9IHhz
bV9wbV9vcCgpOw0KICAgICAgICAgaWYgKCByZXQgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KQEAg
LTI1Nyw2ICsyNjIsOSBAQCBsb25nIGRvX3N5c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNj
DQogICAgICAgICAgICAgcmV0ID0gLUVGQVVMVDsNCiAgICAgICAgICAgICBicmVhazsNCiAgICAg
ICAgIH0NCisjZWxzZQ0KKyAgICAgICByZXQgPSAtRUlOVkFMOw0KKyNlbmRpZg0KICAgICB9DQog
ICAgIGJyZWFrOw0KDQpkaWZmIC1yIGIzZGU4MmIzNTE4OSB4ZW4vY29tbW9uL3RtZW1feGVuLmMN
Ci0tLSBhL3hlbi9jb21tb24vdG1lbV94ZW4uYyAgICAgRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEy
ICswOTAwDQorKysgYi94ZW4vY29tbW9uL3RtZW1feGVuLmMgICAgIEZyaSBGZWIgMDMgMTU6NTI6
NDAgMjAxMiArMDkwMA0KQEAgLTg3LDcgKzg3LDcgQEAgdm9pZCB0bWhfY29weV9wYWdlKGNoYXIg
KnRvLCBjaGFyKmZyb20pDQojZW5kaWYNCn0NCg0KLSNpZmRlZiBfX2lhNjRfXw0KKyNpZiBkZWZp
bmVkKF9faWE2NF9fKSB8fCBkZWZpbmVkKF9fYXJtX18pDQpzdGF0aWMgaW5saW5lIHZvaWQgKmNs
aV9nZXRfcGFnZSh0bWVtX2NsaV9tZm5fdCBjbWZuLCB1bnNpZ25lZCBsb25nICpwY2xpX21mbiwN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZnBfdCAqKnBjbGlfcGZwLCBib29s
X3QgY2xpX3dyaXRlKQ0Kew0KZGlmZiAtciBiM2RlODJiMzUxODkgeGVuL2RyaXZlcnMvTWFrZWZp
bGUNCi0tLSBhL3hlbi9kcml2ZXJzL01ha2VmaWxlICAgICAgRnJpIEZlYiAwMyAxMjoyMTowOSAy
MDEyICswOTAwDQorKysgYi94ZW4vZHJpdmVycy9NYWtlZmlsZSAgICAgIEZyaSBGZWIgMDMgMTU6
NTI6NDAgMjAxMiArMDkwMA0KQEAgLTEsNiArMSw4IEBADQpzdWJkaXIteSArPSBjaGFyDQoraWZu
ZXEgKCQoVEFSR0VUX0FSQ0gpLGFybSkNCnN1YmRpci15ICs9IGNwdWZyZXENCnN1YmRpci15ICs9
IHBjaQ0Kc3ViZGlyLXkgKz0gcGFzc3Rocm91Z2gNCnN1YmRpci0kKEhBU19BQ1BJKSArPSBhY3Bp
DQpzdWJkaXItJChIQVNfVkdBKSArPSB2aWRlbw0KK2VuZGlmDQpkaWZmIC1yIGIzZGU4MmIzNTE4
OSB4ZW4vZHJpdmVycy9jaGFyL01ha2VmaWxlDQotLS0gYS94ZW4vZHJpdmVycy9jaGFyL01ha2Vm
aWxlIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMA0KKysrIGIveGVuL2RyaXZlcnMvY2hh
ci9NYWtlZmlsZSBGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDANCkBAIC0xLDMgKzEsNSBA
QA0Kb2JqLXkgKz0gY29uc29sZS5vDQoraWZuZXEgKCQoVEFSR0VUX0FSQ0gpLGFybSkNCm9iai15
ICs9IG5zMTY1NTAubw0KK2VuZGlmDQpvYmoteSArPSBzZXJpYWwubw0KZGlmZiAtciBiM2RlODJi
MzUxODkgeGVuL2luY2x1ZGUvcHVibGljL3hlbi5oDQotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
eGVuLmggIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMA0KKysrIGIveGVuL2luY2x1ZGUv
cHVibGljL3hlbi5oICBGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDANCkBAIC0zMyw2ICsz
Myw4IEBADQojaW5jbHVkZSAiYXJjaC14ODYveGVuLmgiDQojZWxpZiBkZWZpbmVkKF9faWE2NF9f
KQ0KI2luY2x1ZGUgImFyY2gtaWE2NC5oIg0KKyNlbGlmIGRlZmluZWQoX19hcm1fXykNCisjaW5j
bHVkZSAiYXJjaC1hcm0uaCINCiNlbHNlDQojZXJyb3IgIlVuc3VwcG9ydGVkIGFyY2hpdGVjdHVy
ZSINCiNlbmRpZg0KZGlmZiAtciBiM2RlODJiMzUxODkgeGVuL2luY2x1ZGUveGVuL2xpYmVsZi5o
DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vbGliZWxmLmggIEZyaSBGZWIgMDMgMTI6MjE6MDkgMjAx
MiArMDkwMA0KKysrIGIveGVuL2luY2x1ZGUveGVuL2xpYmVsZi5oICBGcmkgRmViIDAzIDE1OjUy
OjQwIDIwMTIgKzA5MDANCkBAIC0yMyw3ICsyMyw3IEBADQojaWZuZGVmIF9fWEVOX0xJQkVMRl9I
X18NCiNkZWZpbmUgX19YRU5fTElCRUxGX0hfXw0KDQotI2lmIGRlZmluZWQoX19pMzg2X18pIHx8
IGRlZmluZWQoX194ODZfNjRfXykgfHwgZGVmaW5lZChfX2lhNjRfXykNCisjaWYgZGVmaW5lZChf
X2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82NF9fKSB8fCBkZWZpbmVkKF9faWE2NF9fKSB8fCBk
ZWZpbmVkKF9fYXJtX18pDQojZGVmaW5lIFhFTl9FTEZfTElUVExFX0VORElBTg0KI2Vsc2UNCiNl
cnJvciBkZWZpbmUgYXJjaGl0ZWN0dXJhbCBlbmRpYW5uZXNz


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch01.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch01.diff"


YXJtOiBzdGFydCB3b3JraW5nIG9uIEFSTS4KCiBDb25maWcubWsgICAgICAgICAgICAgICAg
IHwgIDEgKwogeGVuL1J1bGVzLm1rICAgICAgICAgICAgICB8ICAyICstCiB4ZW4vY29tbW9u
L2tleGVjLmMgICAgICAgIHwgIDIgKysKIHhlbi9jb21tb24vc3lzY3RsLmMgICAgICAgfCAg
OCArKysrKysrKwogeGVuL2NvbW1vbi90bWVtX3hlbi5jICAgICB8ICAyICstCiB4ZW4vZHJp
dmVycy9NYWtlZmlsZSAgICAgIHwgIDIgKysKIHhlbi9kcml2ZXJzL2NoYXIvTWFrZWZpbGUg
fCAgMiArKwogeGVuL2luY2x1ZGUvcHVibGljL3hlbi5oICB8ICAyICsrCiB4ZW4vaW5jbHVk
ZS94ZW4vbGliZWxmLmggIHwgIDIgKy0KIDkgZmlsZXMgY2hhbmdlZCwgMjAgaW5zZXJ0aW9u
cygrKSwgMyBkZWxldGlvbnMoLSkKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcu
cnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciBiM2RlODJiMzUxODkgQ29uZmlnLm1rCi0tLSBh
L0NvbmZpZy5tawlGcmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDAKKysrIGIvQ29uZmln
Lm1rCUZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkwMApAQCAtMTUsNiArMTUsNyBAQCBk
ZWJ1ZyA/PSB5CiBYRU5fQ09NUElMRV9BUkNIICAgID89ICQoc2hlbGwgdW5hbWUgLW0gfCBz
ZWQgLWUgcy9pLjg2L3g4Nl8zMi8gXAogICAgICAgICAgICAgICAgICAgICAgICAgIC1lIHMv
aTg2cGMveDg2XzMyLyAtZSBzL2FtZDY0L3g4Nl82NC8pCiBYRU5fVEFSR0VUX0FSQ0ggICAg
ID89ICQoWEVOX0NPTVBJTEVfQVJDSCkKK1hFTl9UQVJHRVRfU1VCQVJDSCAgPz0gJChYRU5f
VEFSR0VUX0FSQ0gpCiBYRU5fT1MgICAgICAgICAgICAgID89ICQoc2hlbGwgdW5hbWUgLXMp
CiAKIENPTkZJR18kKFhFTl9PUykgOj0geQpkaWZmIC1yIGIzZGU4MmIzNTE4OSB4ZW4vUnVs
ZXMubWsKLS0tIGEveGVuL1J1bGVzLm1rCUZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkw
MAorKysgYi94ZW4vUnVsZXMubWsJRnJpIEZlYiAwMyAxNTo1Mjo0MCAyMDEyICswOTAwCkBA
IC0yNiw5ICsyNiw5IEBAIHBlcmZjIDo9IHkKIGVuZGlmCiAKICMgU2V0IEFSQ0gvU1VCQVJD
SCBhcHByb3ByaWF0ZWx5Lgotb3ZlcnJpZGUgVEFSR0VUX1NVQkFSQ0ggIDo9ICQoWEVOX1RB
UkdFVF9BUkNIKQogb3ZlcnJpZGUgVEFSR0VUX0FSQ0ggICAgIDo9ICQoc2hlbGwgZWNobyAk
KFhFTl9UQVJHRVRfQVJDSCkgfCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
ZWQgLWUgJ3MveDg2LioveDg2LycpCitvdmVycmlkZSBUQVJHRVRfU1VCQVJDSCAgOj0gJChY
RU5fVEFSR0VUX1NVQkFSQ0gpCiAKIFRBUkdFVCA6PSAkKEJBU0VESVIpL3hlbgogCmRpZmYg
LXIgYjNkZTgyYjM1MTg5IHhlbi9jb21tb24va2V4ZWMuYwotLS0gYS94ZW4vY29tbW9uL2tl
eGVjLmMJRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICswOTAwCisrKyBiL3hlbi9jb21tb24v
a2V4ZWMuYwlGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDAKQEAgLTIxMSw3ICsyMTEs
OSBAQCBzdGF0aWMgdm9pZCBrZXhlY19jb21tb25fc2h1dGRvd24odm9pZCkKICAgICBjb25z
b2xlX3N0YXJ0X3N5bmMoKTsKICAgICBzcGluX2RlYnVnX2Rpc2FibGUoKTsKICAgICBvbmVf
Y3B1X29ubHkoKTsKKyNpZiAhZGVmaW5lZChfX2FybV9fKQogICAgIGFjcGlfZG1hcl9yZWlu
c3RhdGUoKTsKKyNlbmRpZgogfQogCiB2b2lkIGtleGVjX2NyYXNoKHZvaWQpCmRpZmYgLXIg
YjNkZTgyYjM1MTg5IHhlbi9jb21tb24vc3lzY3RsLmMKLS0tIGEveGVuL2NvbW1vbi9zeXNj
dGwuYwlGcmkgRmViIDAzIDEyOjIxOjA5IDIwMTIgKzA5MDAKKysrIGIveGVuL2NvbW1vbi9z
eXNjdGwuYwlGcmkgRmViIDAzIDE1OjUyOjQwIDIwMTIgKzA5MDAKQEAgLTIyNiw2ICsyMjYs
NyBAQCBsb25nIGRvX3N5c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNjCiAKICAgICBj
YXNlIFhFTl9TWVNDVExfZ2V0X3Btc3RhdDoKICAgICB7CisjaWYgIWRlZmluZWQoX19hcm1f
XykKICAgICAgICAgcmV0ID0geHNtX2dldF9wbXN0YXQoKTsKICAgICAgICAgaWYgKCByZXQg
KQogICAgICAgICAgICAgYnJlYWs7CkBAIC0yMzksMTEgKzI0MCwxNSBAQCBsb25nIGRvX3N5
c2N0bChYRU5fR1VFU1RfSEFORExFKHhlbl9zeXNjCiAgICAgICAgICAgICByZXQgPSAtRUZB
VUxUOwogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIH0KKyNlbHNlCisJcmV0ID0gLUVJ
TlZBTDsKKyNlbmRpZgogICAgIH0KICAgICBicmVhazsKIAogICAgIGNhc2UgWEVOX1NZU0NU
TF9wbV9vcDoKICAgICB7CisjaWYgIWRlZmluZWQoX19hcm1fXykKICAgICAgICAgcmV0ID0g
eHNtX3BtX29wKCk7CiAgICAgICAgIGlmICggcmV0ICkKICAgICAgICAgICAgIGJyZWFrOwpA
QCAtMjU3LDYgKzI2Miw5IEBAIGxvbmcgZG9fc3lzY3RsKFhFTl9HVUVTVF9IQU5ETEUoeGVu
X3N5c2MKICAgICAgICAgICAgIHJldCA9IC1FRkFVTFQ7CiAgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgfQorI2Vsc2UKKwlyZXQgPSAtRUlOVkFMOworI2VuZGlmCiAgICAgfQogICAg
IGJyZWFrOwogCmRpZmYgLXIgYjNkZTgyYjM1MTg5IHhlbi9jb21tb24vdG1lbV94ZW4uYwot
LS0gYS94ZW4vY29tbW9uL3RtZW1feGVuLmMJRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICsw
OTAwCisrKyBiL3hlbi9jb21tb24vdG1lbV94ZW4uYwlGcmkgRmViIDAzIDE1OjUyOjQwIDIw
MTIgKzA5MDAKQEAgLTg3LDcgKzg3LDcgQEAgdm9pZCB0bWhfY29weV9wYWdlKGNoYXIgKnRv
LCBjaGFyKmZyb20pCiAjZW5kaWYKIH0KIAotI2lmZGVmIF9faWE2NF9fCisjaWYgZGVmaW5l
ZChfX2lhNjRfXykgfHwgZGVmaW5lZChfX2FybV9fKQogc3RhdGljIGlubGluZSB2b2lkICpj
bGlfZ2V0X3BhZ2UodG1lbV9jbGlfbWZuX3QgY21mbiwgdW5zaWduZWQgbG9uZyAqcGNsaV9t
Zm4sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZnBfdCAqKnBjbGlfcGZw
LCBib29sX3QgY2xpX3dyaXRlKQogewpkaWZmIC1yIGIzZGU4MmIzNTE4OSB4ZW4vZHJpdmVy
cy9NYWtlZmlsZQotLS0gYS94ZW4vZHJpdmVycy9NYWtlZmlsZQlGcmkgRmViIDAzIDEyOjIx
OjA5IDIwMTIgKzA5MDAKKysrIGIveGVuL2RyaXZlcnMvTWFrZWZpbGUJRnJpIEZlYiAwMyAx
NTo1Mjo0MCAyMDEyICswOTAwCkBAIC0xLDYgKzEsOCBAQAogc3ViZGlyLXkgKz0gY2hhcgor
aWZuZXEgKCQoVEFSR0VUX0FSQ0gpLGFybSkKIHN1YmRpci15ICs9IGNwdWZyZXEKIHN1YmRp
ci15ICs9IHBjaQogc3ViZGlyLXkgKz0gcGFzc3Rocm91Z2gKIHN1YmRpci0kKEhBU19BQ1BJ
KSArPSBhY3BpCiBzdWJkaXItJChIQVNfVkdBKSArPSB2aWRlbworZW5kaWYKZGlmZiAtciBi
M2RlODJiMzUxODkgeGVuL2RyaXZlcnMvY2hhci9NYWtlZmlsZQotLS0gYS94ZW4vZHJpdmVy
cy9jaGFyL01ha2VmaWxlCUZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMAorKysgYi94
ZW4vZHJpdmVycy9jaGFyL01ha2VmaWxlCUZyaSBGZWIgMDMgMTU6NTI6NDAgMjAxMiArMDkw
MApAQCAtMSwzICsxLDUgQEAKIG9iai15ICs9IGNvbnNvbGUubworaWZuZXEgKCQoVEFSR0VU
X0FSQ0gpLGFybSkKIG9iai15ICs9IG5zMTY1NTAubworZW5kaWYKIG9iai15ICs9IHNlcmlh
bC5vCmRpZmYgLXIgYjNkZTgyYjM1MTg5IHhlbi9pbmNsdWRlL3B1YmxpYy94ZW4uaAotLS0g
YS94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgJRnJpIEZlYiAwMyAxMjoyMTowOSAyMDEyICsw
OTAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy94ZW4uaAlGcmkgRmViIDAzIDE1OjUyOjQw
IDIwMTIgKzA5MDAKQEAgLTMzLDYgKzMzLDggQEAKICNpbmNsdWRlICJhcmNoLXg4Ni94ZW4u
aCIKICNlbGlmIGRlZmluZWQoX19pYTY0X18pCiAjaW5jbHVkZSAiYXJjaC1pYTY0LmgiCisj
ZWxpZiBkZWZpbmVkKF9fYXJtX18pCisjaW5jbHVkZSAiYXJjaC1hcm0uaCIKICNlbHNlCiAj
ZXJyb3IgIlVuc3VwcG9ydGVkIGFyY2hpdGVjdHVyZSIKICNlbmRpZgpkaWZmIC1yIGIzZGU4
MmIzNTE4OSB4ZW4vaW5jbHVkZS94ZW4vbGliZWxmLmgKLS0tIGEveGVuL2luY2x1ZGUveGVu
L2xpYmVsZi5oCUZyaSBGZWIgMDMgMTI6MjE6MDkgMjAxMiArMDkwMAorKysgYi94ZW4vaW5j
bHVkZS94ZW4vbGliZWxmLmgJRnJpIEZlYiAwMyAxNTo1Mjo0MCAyMDEyICswOTAwCkBAIC0y
Myw3ICsyMyw3IEBACiAjaWZuZGVmIF9fWEVOX0xJQkVMRl9IX18KICNkZWZpbmUgX19YRU5f
TElCRUxGX0hfXwogCi0jaWYgZGVmaW5lZChfX2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82
NF9fKSB8fCBkZWZpbmVkKF9faWE2NF9fKQorI2lmIGRlZmluZWQoX19pMzg2X18pIHx8IGRl
ZmluZWQoX194ODZfNjRfXykgfHwgZGVmaW5lZChfX2lhNjRfXykgfHwgZGVmaW5lZChfX2Fy
bV9fKQogI2RlZmluZSBYRU5fRUxGX0xJVFRMRV9FTkRJQU4KICNlbHNlCiAjZXJyb3IgZGVm
aW5lIGFyY2hpdGVjdHVyYWwgZW5kaWFubmVzcwo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt16-0005xp-Ti; Mon, 13 Feb 2012 10:20:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqp9-0003Ma-Km
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:59:48 +0000
Received: from [85.158.139.83:51794] by server-1.bemta-5.messagelabs.com id
	AA/6E-04285-2F2C83F4; Mon, 13 Feb 2012 07:59:46 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329119983!7452746!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24234 invoked from network); 13 Feb 2012 07:59:45 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-16.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 07:59:45 -0000
Received: from epcpsbge8.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005VZN88EV50@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:59:42 +0900 (KST)
Message-id: <0LZB0057ZNJIEV60@mailout1.samsung.com>
X-AuditID: cbfee612-b7c09ae0000024ca-d2-4f38c2ec73c7
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge8.samsung.com (EPCPMTA) with SMTP id C8.E0.09418.CE2C83F4;
	Mon, 13 Feb 2012 16:59:40 +0900 (KST)
Date: Mon, 13 Feb 2012 07:59:40 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075853731@jm77.ryu
Msgkey: 20120213075853731@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075753031@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 07/14] arm: implement the functions which are
 required to create the dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <10687328.70051329119976618.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgdGhlIGZ1bmN0aW9ucyB3aGljaCBhcmUgcmVxdWlyZWQgdG8gY3JlYXRl
IHRoZSBkb20wLg0KDQogeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZSAgICAgICB8ICAgIDEgKw0K
IHhlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21haW4uYyAgfCAgMTQ0ICsrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tDQogeGVuL2Fy
Y2gvYXJtL3hlbi9hcm12Ny5TICAgICAgICB8ICAgMTkgKysrKysrKysNCiB4ZW4vYXJjaC9hcm0v
eGVuL2RvbWFpbl9idWlsZC5jIHwgIDE4OSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQ0K
IHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgfCAgICAyIC0NCiB4ZW4vaW5jbHVkZS9h
c20tYXJtL2N1cnJlbnQuaCAgIHwgICAyMyArKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFy
bS9kb21haW4uaCAgICB8ICAgMzkgKy0tLS0tLS0tLS0tLS0tLS0NCiA3IGZpbGVzIGNoYW5nZWQs
IDM1NiBpbnNlcnRpb25zKCspLCA2MSBkZWxldGlvbnMoLSkNCg0KU2lnbmVkLW9mZi1ieTogSmFl
bWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgMDhmMzlhOWRhMDRmIHhl
bi9hcmNoL2FybS94ZW4vTWFrZWZpbGUNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUJ
TW9uIEZlYiAwNiAxMToxNzowMSAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL01h
a2VmaWxlCVN1biBGZWIgMTIgMTE6NDY6MzIgMjAxMiArMDkwMA0KQEAgLTIxLDMgKzIxLDQgQEAg
b2JqLXkgKz0gY3Jhc2gubw0KIG9iai15ICs9IHAybS5vDQogb2JqLXkgKz0gcGVyZm1vbi5vDQog
b2JqLXkgKz0gcGNpLm8NCitvYmoteSArPSBhcm12Ny5vDQpkaWZmIC1yIDA4ZjM5YTlkYTA0ZiB4
ZW4vYXJjaC9hcm0veGVuL2FyY2hfZG9tYWluLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vYXJj
aF9kb21haW4uYwlNb24gRmViIDA2IDExOjE3OjAxIDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNo
L2FybS94ZW4vYXJjaF9kb21haW4uYwlTdW4gRmViIDEyIDExOjQ2OjMyIDIwMTIgKzA5MDANCkBA
IC0zMSw2ICszMSwxMiBAQA0KICNpbmNsdWRlIDx4ZW4vaXJxLmg+DQogI2luY2x1ZGUgPHhlbi9p
cnFfY3B1c3RhdC5oPg0KICNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPg0KKyNpbmNsdWRlIDxhc20v
Y3VycmVudC5oPgkNCisjaW5jbHVkZSA8YXNtL2NwdS1vcHMuaD4NCisjaW5jbHVkZSA8YXNtL21l
bW9yeS5oPg0KKyNpbmNsdWRlIDxhc20vbW11Lmg+DQorDQorc3RydWN0IHZjcHUgKnN3aXRjaF90
byggc3RydWN0IHZjcHUgKiwgc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCAqLCBzdHJ1Y3QgdmNw
dV9ndWVzdF9jb250ZXh0ICopOw0KIA0KIHZvaWQgYXJjaF9kdW1wX2RvbWFpbl9pbmZvKHN0cnVj
dCBkb21haW4gKmQpDQogew0KQEAgLTUyLDMzICs1OCw4NCBAQCB1bnNpZ25lZCBsb25nIGh5cGVy
Y2FsbF9jcmVhdGVfY29udGludWF0DQogDQogaW50IGFyY2hfZG9tYWluX2NyZWF0ZShzdHJ1Y3Qg
ZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgZG9tY3JfZmxhZ3MpDQogew0KLQlOT1RfWUVUKCk7DQor
CWludCByYzsNCiANCi0JcmV0dXJuIC1FSU5WQUw7DQorCXJjID0gMDsNCisJaWYgKGlzX2lkbGVf
ZG9tYWluKGQpKQ0KKwkJcmV0dXJuIHJjOw0KKw0KKwlkLT5hcmNoLmlvcG9ydF9jYXBzID0gcmFu
Z2VzZXRfbmV3KGQsICJJL08gUG9ydHMiLCBSQU5HRVNFVEZfcHJldHR5cHJpbnRfaGV4KTsNCisJ
cmMgPSAtRU5PTUVNOw0KKwlpZiAoZC0+YXJjaC5pb3BvcnRfY2FwcyA9PSBOVUxMKSB7DQorCQln
b3RvIGZhaWxlZDsNCisJfQ0KKw0KKwlpZiAoKGQtPnNoYXJlZF9pbmZvID0gYWxsb2NfeGVuaGVh
cF9wYWdlcygwLCBNRU1GX2JpdHMoMzIpKSkgPT0gTlVMTCkgew0KKwkJZ290byBmYWlsZWQ7DQor
CX0NCisNCisJY2xlYXJfcGFnZShkLT5zaGFyZWRfaW5mbyk7DQorCXNoYXJlX3hlbl9wYWdlX3dp
dGhfZ3Vlc3QodmlydF90b19wYWdlKGQtPnNoYXJlZF9pbmZvKSwgZCwgWEVOU0hBUkVfd3JpdGFi
bGUpOw0KKw0KKwlkLT5hcmNoLnBpcnFfaXJxID0geG1hbGxvY19hcnJheShpbnQsIGQtPm5yX3Bp
cnFzKTsNCisJaWYgKCFkLT5hcmNoLnBpcnFfaXJxKSB7DQorCQlnb3RvIGZhaWxlZDsNCisJfQ0K
Kw0KKwltZW1zZXQoZC0+YXJjaC5waXJxX2lycSwgMCwgZC0+bnJfcGlycXMgKiBzaXplb2YoKmQt
PmFyY2gucGlycV9pcnEpKTsNCisNCisJZC0+YXJjaC5pcnFfcGlycSA9IHhtYWxsb2NfYXJyYXko
aW50LCBucl9pcnFzKTsNCisJaWYgKCAhZC0+YXJjaC5pcnFfcGlycSApIHsNCisJCWdvdG8gZmFp
bGVkOw0KKwl9DQorDQorCW1lbXNldChkLT5hcmNoLmlycV9waXJxLCAwLCBucl9pcnFzICogc2l6
ZW9mKCpkLT5hcmNoLmlycV9waXJxKSk7DQorDQorCXJldHVybiAwOw0KKw0KK2ZhaWxlZDoNCisJ
ZC0+aXNfZHlpbmcgPSBET01EWUlOR19kZWFkOw0KKwl4ZnJlZShkLT5hcmNoLnBpcnFfaXJxKTsN
CisJeGZyZWUoZC0+YXJjaC5pcnFfcGlycSk7DQorDQorCWZyZWVfeGVuaGVhcF9wYWdlKGQtPnNo
YXJlZF9pbmZvKTsNCisNCisJcmV0dXJuIHJjOw0KIH0NCiANCiB2b2lkIGFyY2hfZG9tYWluX2Rl
c3Ryb3koc3RydWN0IGRvbWFpbiAqZCkNCiB7DQotCU5PVF9ZRVQoKTsNCisJZnJlZV94ZW5oZWFw
X3BhZ2UoZC0+c2hhcmVkX2luZm8pOw0KKw0KKwl4ZnJlZShkLT5hcmNoLnBpcnFfaXJxKTsNCisJ
eGZyZWUoZC0+YXJjaC5pcnFfcGlycSk7DQogfQ0KIA0KIHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRl
eHQgKmFsbG9jX3ZjcHVfZ3Vlc3RfY29udGV4dCh2b2lkKQ0KIHsNCi0JTk9UX1lFVCgpOw0KKwlz
dHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICp2Z2M7DQogDQotCXJldHVybiBOVUxMOw0KKwl2Z2Mg
PSB4bWFsbG9jKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQpOw0KKw0KKwlyZXR1cm4gdmdjOw0K
IH0NCiANCiB2b2lkIGZyZWVfdmNwdV9ndWVzdF9jb250ZXh0KHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQgKmNvbnRleHQpDQogew0KLQlOT1RfWUVUKCk7DQorCXhmcmVlKGNvbnRleHQpOw0KIH0N
CiANCiANCiBzdHJ1Y3QgdmNwdSAqYWxsb2NfdmNwdV9zdHJ1Y3Qodm9pZCkNCiB7DQotCU5PVF9Z
RVQoKTsNCi0JcmV0dXJuIE5VTEw7DQorCXN0cnVjdCB2Y3B1ICp2Ow0KKw0KKwl2ID0geG1hbGxv
YyhzdHJ1Y3QgdmNwdSk7DQorCWlmICggdiAhPSBOVUxMICkNCisJCW1lbXNldCh2LCAwLCBzaXpl
b2Yoc3RydWN0IHZjcHUpKTsNCisNCisNCisJcmV0dXJuIHY7DQogfQ0KIA0KIHZvaWQgYXJjaF92
Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KQ0KQEAgLTg4LDcgKzE0NSw2IEBAIHZvaWQgYXJjaF92
Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KQ0KIA0KIGludCB2Y3B1X2luaXRpYWxpc2Uoc3RydWN0
IHZjcHUgKnYpDQogew0KLQlOT1RfWUVUKCk7DQogCXJldHVybiAwOw0KIH0NCiANCkBAIC05OSwy
NyArMTU1LDMyIEBAIHZvaWQgdmNwdV9kZXN0cm95KHN0cnVjdCB2Y3B1ICp2KQ0KIA0KIHZvaWQg
ZnJlZV92Y3B1X3N0cnVjdChzdHJ1Y3QgdmNwdSAqdikNCiB7DQotCU5PVF9ZRVQoKTsNCisJeGZy
ZWUodik7DQogfQ0KIA0KIHN0cnVjdCBkb21haW4gKmFsbG9jX2RvbWFpbl9zdHJ1Y3Qodm9pZCkN
CiB7DQotCU5PVF9ZRVQoKTsNCisJc3RydWN0IGRvbWFpbiAqZDsNCiANCi0JcmV0dXJuIE5VTEw7
DQorCWQgPSB4bWFsbG9jKHN0cnVjdCBkb21haW4pOw0KKwlpZiAoIGQgIT0gTlVMTCApDQorCQlt
ZW1zZXQoZCwgMCwgc2l6ZW9mKHN0cnVjdCBkb21haW4pKTsNCisNCisJcmV0dXJuIGQ7DQogfQ0K
IA0KIA0KIHZvaWQgZnJlZV9kb21haW5fc3RydWN0KHN0cnVjdCBkb21haW4gKmQpDQogew0KLQlO
T1RfWUVUKCk7DQorCXhmcmVlKGQpOw0KIH0NCiANCisvKiBUaGlzIGlzIGNhbGxlZCBieSBhcmNo
X2ZpbmFsX3NldHVwX2d1ZXN0IGFuZCBkb19ib290X3ZjcHUgKi8NCiBpbnQgYXJjaF9zZXRfaW5m
b19ndWVzdChzdHJ1Y3QgdmNwdSAqdiwgdmNwdV9ndWVzdF9jb250ZXh0X3QgKmN0eCkNCiB7DQog
CU5PVF9ZRVQoKTsNCiANCi0JcmV0dXJuIDA7DQorCXJldHVybiAtRUlOVkFMOw0KIA0KIH0NCiAN
CkBAIC0xMzUsMTIgKzE5NiwxNyBAQCB2b2lkIGR1bXBfcGFnZWZyYW1lX2luZm8oc3RydWN0IGRv
bWFpbiAqDQogDQogdm9pZCBjb250ZXh0X3N3aXRjaChzdHJ1Y3QgdmNwdSAqcHJldiwgc3RydWN0
IHZjcHUgKm5leHQpDQogew0KLQlOT1RfWUVUKCk7DQorCUFTU0VSVChwcmV2ICE9IG5leHQpOw0K
KwlBU1NFUlQodmNwdV9ydW5uYWJsZShuZXh0KSk7DQorDQorICAgICAgICBwcmV2ID0gIHN3aXRj
aF90byhwcmV2LCAmcHJldi0+YXJjaC5jdHgsICZuZXh0LT5hcmNoLmN0eCk7DQogfQ0KIA0KIHZv
aWQgY29udGludWVfcnVubmluZyhzdHJ1Y3QgdmNwdSAqc2FtZSkNCiB7DQogCU5PVF9ZRVQoKTsN
CisNCisJcmV0dXJuIDsNCiB9DQogDQogdm9pZCBzeW5jX2xhenlfZXhlY3N0YXRlX2NwdSh1bnNp
Z25lZCBpbnQgY3B1KQ0KQEAgLTE2OCw2ICsyMzQsMjQgQEAgdm9pZCByZWxpbnF1aXNoX21lbW9y
eShzdHJ1Y3QgZG9tYWluICpkLA0KIAlOT1RfWUVUKCk7DQogfQ0KIA0KK3ZvaWQgdHJhY2VfZG9t
aGVhcF9wYWdlcyhjb25zdCBjaGFyICpjYXB0aW9uLCBzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg
bGlzdF9oZWFkICpsaXN0KQ0KK3sNCisJc3RydWN0IGxpc3RfaGVhZCAqZW50Ow0KKwlzdHJ1Y3Qg
cGFnZV9pbmZvICAqcGFnZTsNCisNCisJLyogVXNlIGEgcmVjdXJzaXZlIGxvY2ssIGFzIHdlIG1h
eSBlbnRlciAnZnJlZV9kb21oZWFwX3BhZ2UnLiAqLw0KKwlzcGluX2xvY2tfcmVjdXJzaXZlKCZk
LT5wYWdlX2FsbG9jX2xvY2spOw0KKw0KKwllbnQgPSBsaXN0LT5uZXh0Ow0KKwl3aGlsZSAoIGVu
dCAhPSBsaXN0ICkNCisJew0KKwkJcGFnZSA9IGxpc3RfZW50cnkoZW50LCBzdHJ1Y3QgcGFnZV9p
bmZvLCBsaXN0KTsNCisJCWVudCA9IGVudC0+bmV4dDsNCisJfQ0KKw0KKwlzcGluX3VubG9ja19y
ZWN1cnNpdmUoJmQtPnBhZ2VfYWxsb2NfbG9jayk7DQorfQ0KKw0KIGludCBkb21haW5fcmVsaW5x
dWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCiB7DQogCU5PVF9ZRVQoKTsNCkBAIC0x
NzcsNyArMjYxLDE2IEBAIGludCBkb21haW5fcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGQN
CiANCiB2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKQ0KIHsNCi0JTk9UX1lFVCgpOw0K
Kwl3aGlsZSgxKSB7DQorCQlpZiAoY3B1X2lzX2hhbHRhYmxlKHNtcF9wcm9jZXNzb3JfaWQoKSkp
IHsNCisJCQlsb2NhbF9pcnFfZGlzYWJsZSgpOw0KKwkJCWNwdV9pZGxlKCk7DQorCQkJbG9jYWxf
aXJxX2VuYWJsZSgpOw0KKwkJfQ0KKw0KKwkJZG9fdGFza2xldCgpOw0KKwkJZG9fc29mdGlycSgp
Ow0KKwl9DQogfQ0KIA0KIGxvbmcgYXJjaF9kb192Y3B1X29wKGludCBjbWQsIHN0cnVjdCB2Y3B1
ICp2LCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykNCkBAIC0xODksMjIgKzI4MiwzMyBAQCBs
b25nIGFyY2hfZG9fdmNwdV9vcChpbnQgY21kLCBzdHJ1Y3QgdmNwDQogDQogdm9pZCB2Y3B1X2tp
Y2soc3RydWN0IHZjcHUgKnYpDQogew0KLQlOT1RfWUVUKCk7DQorCWJvb2xfdCBydW5uaW5nID0g
di0+aXNfcnVubmluZzsNCisNCisJdmNwdV91bmJsb2NrKHYpOw0KKw0KKwlpZiAocnVubmluZyAm
JiAoaW5faXJxKCkgfHwgKHYgIT0gY3VycmVudCkpKSB7DQorCQljcHVfcmFpc2Vfc29mdGlycSh2
LT5wcm9jZXNzb3IsIFZDUFVfS0lDS19TT0ZUSVJRKTsNCisJfQ0KIH0NCiANCiB2b2lkIHZjcHVf
bWFya19ldmVudHNfcGVuZGluZyhzdHJ1Y3QgdmNwdSAqdikNCiB7DQotCU5PVF9ZRVQoKTsNCisJ
aW50IGFscmVhZHkgPSB0ZXN0X2FuZF9zZXRfYml0KDAsICh1bnNpZ25lZCBsb25nICopJnZjcHVf
aW5mbyh2LCBldnRjaG5fdXBjYWxsX3BlbmRpbmcpKTsNCisNCisJaWYgKGFscmVhZHkpIHsNCisJ
CXJldHVybjsNCisJfQ0KKw0KKwl2Y3B1X2tpY2sodik7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIHZj
cHVfa2lja19zb2Z0aXJxKHZvaWQpDQogew0KLQlOT1RfWUVUKCk7DQogfQ0KIA0KIHN0YXRpYyBp
bnQgX19pbml0IHZjcHVfa2lja19zb2Z0aXJxX2luaXQodm9pZCkNCiB7DQotCU5PVF9ZRVQoKTsN
CisJb3Blbl9zb2Z0aXJxKFZDUFVfS0lDS19TT0ZUSVJRLCB2Y3B1X2tpY2tfc29mdGlycSk7DQog
DQogCXJldHVybiAwOw0KIH0NCmRpZmYgLXIgMDhmMzlhOWRhMDRmIHhlbi9hcmNoL2FybS94ZW4v
YXJtdjcuUw0KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDANCisr
KyBiL3hlbi9hcmNoL2FybS94ZW4vYXJtdjcuUwlTdW4gRmViIDEyIDExOjQ2OjMyIDIwMTIgKzA5
MDANCkBAIC0wLDAgKzEsMTkgQEANCisjaW5jbHVkZSA8YXNtL3BhZ2UuaD4NCisjaW5jbHVkZSA8
YXNtL2NwdS1vcHMuaD4NCisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPg0KKyNpbmNsdWRlIDxhc20v
YXNtLW1hY3Jvcy5oPg0KKyNpbmNsdWRlIDxhc20vYXNtLW9mZnNldHMuaD4NCisjaW5jbHVkZSA8
cHVibGljL2FyY2gtYXJtLmg+DQorDQorCS50ZXh0DQorRU5UUlkoY3B1X2lkbGUpDQorCWRzYg0K
Kwl3ZmkNCisJbW92CXBjLCBscg0KKw0KK0VOVFJZKGNwdV9oYWx0KQ0KKwltb3YJcGMsIGxyDQor
DQorRU5UUlkoY3B1X3Jlc2V0KQ0KKwltb3YJcGMsIGxyDQorDQpkaWZmIC1yIDA4ZjM5YTlkYTA0
ZiB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jDQotLS0gYS94ZW4vYXJjaC9hcm0veGVu
L2RvbWFpbl9idWlsZC5jCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMA0KKysrIGIveGVu
L2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwlTdW4gRmViIDEyIDExOjQ2OjMyIDIwMTIgKzA5
MDANCkBAIC0zMyw2ICszMyw2NyBAQA0KICNpbmNsdWRlIDxwdWJsaWMveGVuLmg+DQogI2luY2x1
ZGUgPHB1YmxpYy92ZXJzaW9uLmg+DQogDQorZXh0ZXJuIHZvaWQgcmV0dXJuX3RvX2d1ZXN0KCk7
DQorDQordm9pZCB2Y3B1X2NvbnRleHRfaW5pdChzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgbG9u
ZyBzdGssIHVuc2lnbmVkIGxvbmcgcGMsIHN0cnVjdCBzdGFydF9pbmZvICpzaSkNCit7DQorCXZv
aWQgKnN0YWNrOw0KKwlzdHJ1Y3QgY3B1X2luZm8gKmNpOw0KKwlzdHJ1Y3QgY3B1X2N0eCAqY3B1
X2N0eDsNCisNCisJc3RhY2sgPSBhbGxvY194ZW5oZWFwX3BhZ2VzKFNUQUNLX09SREVSLCAwKTsN
CisJaWYoc3RhY2sgPT0gTlVMTCkgew0KKwkJcmV0dXJuOw0KKwl9DQorDQorCWNpID0gKHN0cnVj
dCBjcHVfaW5mbyAqKXN0YWNrOw0KKwljaS0+dmNwdSA9IHY7DQorCWNpLT52c3AgPSAwOw0KKwlj
aS0+dnNwc3IgPSBQU1JfTU9ERV9TVkM7DQorCWNpLT52ZGFjciA9IERBQ1JfU1RBVF9TVkM7DQor
DQorCXN0YWNrICs9IChTVEFDS19TSVpFIC0gc2l6ZW9mKHN0cnVjdCBjcHVfY3R4KSk7DQorDQor
CWNwdV9jdHggPSAoc3RydWN0IGNwdV9jdHggKilzdGFjazsNCisJY3B1X2N0eC0+cjAgPSAwOw0K
KwljcHVfY3R4LT5yMTIgPSAodW5zaWduZWQgbG9uZylzaTsNCisJY3B1X2N0eC0+dXNwID0gc3Rr
Ow0KKwljcHVfY3R4LT51bHIgPSAwOw0KKwljcHVfY3R4LT5zc3AgPSAodW5zaWduZWQgbG9uZyko
c3RhY2sgKyBzaXplb2Yoc3RydWN0IGNwdV9jdHgpKTsNCisJY3B1X2N0eC0+cGMgPSBwYzsNCisJ
Y3B1X2N0eC0+c3BzciA9IDB4MTA7DQorDQorCVZDUFVfUkVHKHYsIHIxMykgPSAodW5zaWduZWQg
bG9uZylzdGFjazsNCisJVkNQVV9SRUcodiwgcjE0KSA9ICh1bnNpZ25lZCBsb25nKXJldHVybl90
b19ndWVzdDsNCisNCisJVkNQVV9SRUcodiwgZGFjcikgPSBEQUNSX1NUQVRfU1ZDOw0KKwlWQ1BV
X1JFRyh2LCBmY3NlaWRyKSA9IDA7DQorCVZDUFVfUkVHKHYsIGNvbnRleHRpZHIpID0gMDsNCisJ
VkNQVV9SRUcodiwgY3BhcikgPSAoMHg0MCkgfCAoMSA8PCAxMyk7DQorfQ0KKw0KKyNkZWZpbmUg
RE9NX1BGTl9BTElHTgkoU0VDVElPTl9TSVpFID4+IFBBR0VfU0hJRlQpDQorDQorc3RhdGljIHVu
c2lnbmVkIGxvbmcgYWxsb2NfZG9tYWluX3BhZ2VzKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVk
IGludCBzaXplKQ0KK3sNCisJdW5zaWduZWQgcGh5czsNCisJdW5zaWduZWQgbG9uZyBwYWdlcyA9
IHNpemUgPj4gUEFHRV9TSElGVDsNCisNCisJZC0+bWF4X3BhZ2VzID0gfigweDBVTCk7DQorDQor
CXBoeXMgPSBhbGxvY19ib290X3BhZ2VzKHBhZ2VzLCBET01fUEZOX0FMSUdOKTsNCisJDQorCWlm
ICghcGh5cykgew0KKwkJZC0+dG90X3BhZ2VzID0gMDsNCisJCXJldHVybiAwOw0KKwl9DQorDQor
CWQtPnRvdF9wYWdlcyA9IHBhZ2VzOw0KKw0KKwkvKiBTZXQgUGFnZSBPd25lciAqLw0KKwlyZXR1
cm4gcGh5cyA8PD0gUEFHRV9TSElGVDsNCit9DQorDQogLyoNCiAgKiBkb21haW5fY29uc3RydWN0
KCkgc2hvdWxkIGJlIGFsd2F5cyBpbnZva2VkIGluIGlkbGUgZG9tYWluDQogICovDQpAQCAtNDAs
OCArMTAxLDEzMiBAQCBpbnQgZG9tYWluX2NvbnN0cnVjdChzdHJ1Y3QgZG9tYWluICpkLA0KIAkJ
ICAgICB1bnNpZ25lZCBsb25nIGltZ19zdGFydCwgdW5zaWduZWQgbG9uZyBpbWdfbGVuLCANCiAJ
CSAgICAgdW5zaWduZWQgbG9uZyBkb21fc2l6ZSwgdW5zaWduZWQgaW50IHZjcHVzKQ0KIHsNCi0J
Tk9UX1lFVCgpOw0KKwlpbnQgaSwgcmM7DQorCXN0cnVjdCB2Y3B1ICp2Ow0KKwlzdHJ1Y3QgZWxm
X2JpbmFyeSBlbGY7DQorCXN0cnVjdCBlbGZfZG9tX3Bhcm1zIHBhcm1zOw0KKwlzdHJ1Y3Qgc3Rh
cnRfaW5mbyAqc2k7DQorCXVuc2lnbmVkIGxvbmcgdnN0YXJ0LCB2ZW5kLCB2ZW50cnk7DQorCXVu
c2lnbmVkIGxvbmcgcHN0YXJ0LCBwZW5kLCBwbWFwLCBsZW47DQogDQotCXJldHVybiAtRUlOVkFM
Ow0KKwlsMWVfdCAqZ3B0Ow0KKw0KKwlCVUdfT04oZCA9PSBOVUxMKTsNCisJQlVHX09OKGRvbV9z
aXplICYgflNFQ1RJT05fTUFTSyk7DQorDQorCXBzdGFydCA9IGFsbG9jX2RvbWFpbl9wYWdlcyhk
LCBkb21fc2l6ZSk7DQorCWlmICghcHN0YXJ0KSB7DQorCQlyZXR1cm4gLUVOT01FTTsNCisJfQ0K
Kw0KKwltZW1jcHkoKHBzdGFydCArIGRvbV9zaXplIC0gaW1nX2xlbiksIGltZ19zdGFydCwgaW1n
X2xlbik7DQorCWltZ19zdGFydCA9IHBzdGFydCArIGRvbV9zaXplIC0gaW1nX2xlbjsNCisNCisJ
aWYgKChyYyA9IGVsZl9pbml0KCZlbGYsIGltZ19zdGFydCwgaW1nX2xlbikpICE9IDApIHsNCisJ
CXJldHVybiByYzsNCisJfQ0KKw0KKwllbGZfcGFyc2VfYmluYXJ5KCZlbGYpOw0KKw0KKwlpZiAo
KHJjID0gZWxmX3hlbl9wYXJzZSgmZWxmLCAmcGFybXMpKSAhPSAwKSB7DQorCQlyZXR1cm4gcmM7
DQorCX0NCisNCisJZC0+dmNwdSA9IHhtYWxsb2NfYXJyYXkoc3RydWN0IHZjcHUgKiwgTUFYX1ZJ
UlRfQ1BVUyk7DQorCWlmICghZC0+dmNwdSkgew0KKwkJcmV0dXJuIC1FTk9NRU07DQorCX0NCisN
CisJbWVtc2V0KGQtPnZjcHUsIDAsIE1BWF9WSVJUX0NQVVMgKiBzaXplb2YoKmQtPnZjcHUpKTsN
CisJZC0+bWF4X3ZjcHVzID0gTUFYX1ZJUlRfQ1BVUzsNCisNCisJZm9yIChpID0gMDsgaSA8IE1B
WF9WSVJUX0NQVVM7IGkrKykgew0KKwkJZC0+c2hhcmVkX2luZm8tPnZjcHVfaW5mb1tpXS5ldnRj
aG5fdXBjYWxsX21hc2sgPSAxOw0KKwkJZC0+c2hhcmVkX2luZm8tPnZjcHVfaW5mb1tpXS5hcmNo
LmNwc3IgPSAoVlBTUl9JX0JJVCB8IFZQU1JfRl9CSVQgfCBWUFNSX01PREVfU1ZDKTsNCisJfQ0K
Kw0KKwlmb3IgKGkgPSAwOyBpIDwgdmNwdXM7IGkrKykgew0KKwkJaWYgKGFsbG9jX3ZjcHUoZCwg
aSwgaSkgPT0gTlVMTCkgew0KKwkJCXJldHVybiAtRU5PTUVNOw0KKwkJfQ0KKwl9DQorDQorCXZz
dGFydCA9IHBhcm1zLnZpcnRfa3N0YXJ0ICYgU0VDVElPTl9NQVNLOw0KKwl2ZW5kID0gcm91bmRf
dXAocGFybXMudmlydF9rZW5kLCBMMV9UQUJMRV9TSVpFKTsNCisJdmVudHJ5ID0gcGFybXMudmly
dF9lbnRyeTsNCisNCisJbGVuID0gdmVuZCAtIHZzdGFydDsNCisNCisJLyogR3Vlc3QgIHBhZ2Ug
dGFibGUgaXMgbG9jYXRlZCBpbiB0aGUgZW5kIG9mIHZlbmQgKi8NCisJZ3B0ID0gKGwxZV90ICop
KHBzdGFydCArIGxlbik7DQorCQ0KKwkvKiBEdXBsaWNhdGUgTDEgcGFnZSB0YWJsZSAqLw0KKwlt
ZW1jcHkoZ3B0LCB4ZW5fdHJhbnNsYXRpb25fdGFibGUsIEwxX1RBQkxFX1NJWkUpOw0KKw0KKwlw
bWFwID0gcHN0YXJ0Ow0KKwlwZW5kID0gcG1hcCArIGRvbV9zaXplOw0KKw0KKw0KKwlncHQgPSBs
MV9saW5lYXJfb2Zmc2V0KGdwdCwgdnN0YXJ0KTsNCisNCisJLyogQ3JlYXRlIDE6MSBtYXBwaW5n
ICovDQorCWRvIHsNCisJCSpncHQgPSBNS19MMUUocG1hcCwgTDFFX1RZUEVfR1VFU1QpOw0KKwkJ
cG1hcCArPSBTRUNUSU9OX1NJWkU7DQorCX0gd2hpbGUoZ3B0KyssIHBtYXAgPCBwZW5kKTsNCisg
DQorCS8qIEFjdGl2YXRlIGd1ZXN0IGFkZHJlc3Mgc3BhY2UgdG8gcmVsb2NhdGUgZ3Vlc3QgaW1h
Z2UgKi8NCisJbW11X3N3aXRjaF90dGIoZ3B0ICYgfigweDQwMDAgLSAxKSk7DQorDQorCWVsZi5k
ZXN0ID0gKHZvaWQgKil2ZW50cnk7DQorCWVsZl9sb2FkX2JpbmFyeSgmZWxmKTsNCisNCisJc2kg
PSAoc3RydWN0IHN0YXJ0X2luZm8gKikodmVuZCArIEwxX1RBQkxFX1NJWkUpOw0KKwltZW1zZXQo
c2ksIDAsIFBBR0VfU0laRSk7DQorCQ0KKw0KKwlzaS0+bnJfcGFnZXMgCSAgPSBkLT50b3RfcGFn
ZXM7DQorCXNpLT5zaGFyZWRfaW5mbyAgID0gdmlydF90b19tYWRkcihkLT5zaGFyZWRfaW5mbyk7
DQorCXNpLT5wdF9iYXNlIAkgID0gdmVuZDsNCisJc2ktPm5yX3B0X2ZyYW1lcyAgPSA0Ow0KKwlz
aS0+bWZuX2xpc3QgCSAgPSAwOw0KKwlzaS0+Zmlyc3RfcDJtX3BmbiA9IHBzdGFydCA+PiBQQUdF
X1NISUZUOw0KKwlzaS0+ZmxhZ3MgCSAgPSAwOw0KKwlzaS0+bWluX21mbgkgID0gcHN0YXJ0ID4+
IFBBR0VfU0hJRlQ7DQorDQorCWlmIChkLT5kb21haW5faWQgPT0gMCkgew0KKwkJc2ktPmZsYWdz
ID0gU0lGX1BSSVZJTEVHRUQgfCBTSUZfSU5JVERPTUFJTjsNCisJfQ0KKw0KKwl2ID0gZC0+dmNw
dVswXTsNCisNCisJVkNQVV9SRUcodiwgdHRicjApID0gKHVuc2lnbmVkIGxvbmcpZ3B0Ow0KKw0K
KwltbXVfc3dpdGNoX3R0YihWQ1BVX1JFRyhpZGxlX3ZjcHVbMF0sIHR0YnIwKSk7DQorDQorCXZj
cHVfY29udGV4dF9pbml0KHYsIDAsIHZlbnRyeSwgc2kpOw0KKw0KKwl2LT5pc19pbml0aWFsaXNl
ZCA9IDE7DQorCWNsZWFyX2JpdChfVlBGX2Rvd24sICZ2LT5wYXVzZV9mbGFncyk7DQorDQorCXJj
ID0gMDsNCisNCisJLyogRE9NMCBpcyBwZXJtaXR0ZWQgZnVsbCBJL08gY2FwYWJpbGl0aWVzLiAq
Lw0KKwlyYyB8PSBpb3BvcnRzX3Blcm1pdF9hY2Nlc3MoZG9tMCwgMCwgMHhGRkZGKTsNCisJcmMg
fD0gaW9tZW1fcGVybWl0X2FjY2Vzcyhkb20wLCAwVUwsIH4wVUwpOw0KKwlyYyB8PSBpcnFzX3Bl
cm1pdF9hY2Nlc3MoZG9tMCwgMCwgZC0+bnJfcGlycXMgLSAxKTsNCisNCisJcmV0dXJuIHJjOw0K
IH0NCiANCitpbnQgZWxmX3Nhbml0eV9jaGVjayhjb25zdCBFbGZfRWhkciAqZWhkcikNCit7DQor
CWlmICggIUlTX0VMRigqZWhkcikgfHwNCisJCShlaGRyLT5lX2lkZW50W0VJX0RBVEFdICE9IEVM
RkRBVEEyTFNCKSB8fA0KKwkJKGVoZHItPmVfdHlwZSAhPSBFVF9FWEVDKSApIHsNCisJCXByaW50
aygiRE9NMCBpbWFnZSBpcyBub3QgYSBYZW4tY29tcGF0aWJsZSBFbGYgaW1hZ2UuXG4iKTsNCisJ
CXJldHVybiAwOw0KKwl9DQorDQorCXJldHVybiAxOw0KK30NCmRpZmYgLXIgMDhmMzlhOWRhMDRm
IHhlbi9hcmNoL2FybS94ZW4vbW0uYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9tbS5jCU1vbiBG
ZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9tbS5jCVN1
biBGZWIgMTIgMTE6NDY6MzIgMjAxMiArMDkwMA0KQEAgLTIxNyw4ICsyMTcsNiBAQCB1bnNpZ25l
ZCBsb25nIGFsbG9jX3BhZ2VfdGFibGVzKGwxZV90ICpsDQogCQlyZXR1cm4gMDsNCiAJfQ0KIA0K
LS8vCWNhY2hlX2NsZWFuX3JhbmdlKHBhZ2UsIHBhZ2UgKyBQQUdFX1NJWkUsIDApOw0KLQ0KIAl3
aXJlX3BhZ2VfdGFibGVzKGwxZSwgcGFnZSk7DQogDQogCXJldHVybiBwYWdlOw0KZGlmZiAtciAw
OGYzOWE5ZGEwNGYgeGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgNCi0tLSBhL3hlbi9pbmNs
dWRlL2FzbS1hcm0vY3VycmVudC5oCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMA0KKysr
IGIveGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgJU3VuIEZlYiAxMiAxMTo0NjozMiAyMDEy
ICswOTAwDQpAQCAtMjcsNiArMjcsMjkgQEANCiAjaWZuZGVmIF9fQVNTRU1CTFlfXw0KIHN0cnVj
dCB2Y3B1Ow0KIA0KK3N0cnVjdCBjcHVfY3R4IHsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICBy
MDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByMTsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcg
ICByMjsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByMzsNCisgICAgICAgIHVuc2lnbmVkIGxv
bmcgICByNDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByNTsNCisgICAgICAgIHVuc2lnbmVk
IGxvbmcgICByNjsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByNzsNCisgICAgICAgIHVuc2ln
bmVkIGxvbmcgICByODsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByOTsNCisgICAgICAgIHVu
c2lnbmVkIGxvbmcgICByMTA7DQorICAgICAgICB1bnNpZ25lZCBsb25nICAgcjExOw0KKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHIxMjsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICB1c3A7DQor
ICAgICAgICB1bnNpZ25lZCBsb25nICAgdWxyOw0KKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHNz
cDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcgICBzbHI7DQorICAgICAgICB1bnNpZ25lZCBsb25n
ICAgcGM7DQorICAgICAgICB1bnNpZ25lZCBsb25nICAgc3BzcjsNCit9Ow0KKw0KKw0KIHN0cnVj
dCBjcHVfaW5mbyB7DQogCXN0cnVjdCB2Y3B1CSp2Y3B1Ow0KIAl1bnNpZ25lZCBsb25nCXZzcHNy
Ow0KZGlmZiAtciAwOGYzOWE5ZGEwNGYgeGVuL2luY2x1ZGUvYXNtLWFybS9kb21haW4uaA0KLS0t
IGEveGVuL2luY2x1ZGUvYXNtLWFybS9kb21haW4uaAlNb24gRmViIDA2IDExOjE3OjAxIDIwMTIg
KzA5MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmgJU3VuIEZlYiAxMiAxMTo0
NjozMiAyMDEyICswOTAwDQpAQCAtOCw0MiArOCw4IEBADQogI2luY2x1ZGUgPGFzbS9pb21tdS5o
Pg0KICNpbmNsdWRlIDxwdWJsaWMvYXJjaC1hcm0uaD4NCiANCi0jaWYgMA0KLSNkZWZpbmUgTUFQ
SEFTSF9FTlRSSUVTCQkJOA0KLSNkZWZpbmUgTUFQSEFTSF9IQVNIRk4ocGZuKQkJKChwZm4pICYg
KE1BUEhBU0hfRU5UUklFUy0xKSkNCi0jZGVmaW5lIE1BUEhBU0hFTlRfTk9USU5VU0UJCSgodTE2
KX4wVSkNCi0NCi1zdHJ1Y3QgdmNwdV9tYXBoYXNoIHsNCi0gICAgc3RydWN0IHZjcHVfbWFwaGFz
aF9lbnRyeSB7DQotICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsNCi0gICAgICAgIHVpbnQxNl90
ICAgICAgaWR4Ow0KLSAgICAgICAgdWludDE2X3QgICAgICByZWZjbnQ7DQotICAgIH0gaGFzaFtN
QVBIQVNIX0VOVFJJRVNdOw0KLX1fX2NhY2hlbGluZV9hbGlnbmVkOw0KLQ0KLQ0KLSNkZWZpbmUg
TUFQQ0FDSEVfT1JERVIgICA4DQotI2RlZmluZSBNQVBDQUNIRV9FTlRSSUVTICgxIDw8IE1BUENB
Q0hFX09SREVSKQ0KLQ0KLXN0cnVjdCBtYXBjYWNoZSB7DQotICAgIC8qIFRoZSBQVEVzIHRoYXQg
cHJvdmlkZSB0aGUgbWFwcGluZ3MsIGFuZCBhIGN1cnNvciBpbnRvIHRoZSBhcnJheS4gKi8NCi0g
ICAgbDJlX3QJKnRhYmxlOw0KLSAgICB1bnNpZ25lZCBpbnQgY3Vyc29yOw0KLQ0KLSAgICAvKiBQ
cm90ZWN0cyBtYXBfZG9tYWluX3BhZ2UoKS4gKi8NCi0gICAgc3BpbmxvY2tfdCBsb2NrOw0KLQ0K
LSAgICAvKiBXaGljaCBtYXBwaW5ncyBhcmUgaW4gdXNlLCBhbmQgd2hpY2ggYXJlIGdhcmJhZ2Ug
dG8gcmVhcCBuZXh0IGVwb2NoPyAqLw0KLSAgICB1bnNpZ25lZCBsb25nIGludXNlW0JJVFNfVE9f
TE9OR1MoTUFQQ0FDSEVfRU5UUklFUyldOw0KLSAgICB1bnNpZ25lZCBsb25nIGdhcmJhZ2VbQklU
U19UT19MT05HUyhNQVBDQUNIRV9FTlRSSUVTKV07DQotDQotICAgIC8qIExvY2stZnJlZSBwZXIt
VkNQVSBoYXNoIG9mIHJlY2VudGx5LXVzZWQgbWFwcGluZ3MuICovDQotICAgIHN0cnVjdCB2Y3B1
X21hcGhhc2ggdmNwdV9tYXBoYXNoW01BWF9WSVJUX0NQVVNdOw0KLX1fX2NhY2hlbGluZV9hbGln
bmVkOw0KLSNlbmRpZg0KIHN0cnVjdCBhcmNoX2RvbWFpbg0KIHsNCi0jaWYgMA0KICAgICAvKiBJ
L08tcG9ydCBhZG1pbi1zcGVjaWZpZWQgYWNjZXNzIGNhcGFiaWxpdGllcy4gKi8NCiAgICAgc3Ry
dWN0IHJhbmdlc2V0CSppb3BvcnRfY2FwczsNCiANCkBAIC01MSw4ICsxNyw3IEBAIHN0cnVjdCBh
cmNoX2RvbWFpbg0KICAgICBpbnQgKnBpcnFfaXJxOw0KIA0KICAgICB1bnNpZ25lZCBsb25nICpw
aXJxX2VvaV9tYXA7DQotICAgIHVuc2lnbmVkIGxvbmcgcGlycV9lb2lfbWFwX21mbjsNCi0jZW5k
aWYNCisNCiAgICAgc3RydWN0IHBhZ2VfbGlzdF9oZWFkIHJlbG1lbV9saXN0Ow0KIH07DQogDQpA
QCAtNjEsNyArMjYsNyBAQCBzdHJ1Y3QgYXJjaF92Y3B1DQogCXN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQgY3R4Ow0KIH0gX19jYWNoZWxpbmVfYWxpZ25lZDsNCiANCi0vLyNkZWZpbmUgVkNQVV9S
RUcodiwgcmVnKQl2LT5hcmNoLmN0eC5yZWcNCisjZGVmaW5lIFZDUFVfUkVHKHYsIHJlZykJdi0+
YXJjaC5jdHgucmVnDQogDQogI2RlZmluZSByZXR1cm5fcmVnKHYpCQkoKHYpLT5hcmNoLmN0eC5y
MCkNCiANCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch07.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch07.diff"


YXJtOiBpbXBsZW1lbnQgdGhlIGZ1bmN0aW9ucyB3aGljaCBhcmUgcmVxdWlyZWQgdG8gY3Jl
YXRlIHRoZSBkb20wLgoKIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUgICAgICAgfCAgICAx
ICsKIHhlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21haW4uYyAgfCAgMTQ0ICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t
CiB4ZW4vYXJjaC9hcm0veGVuL2FybXY3LlMgICAgICAgIHwgICAxOSArKysrKysrKwogeGVu
L2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYyB8ICAxODkgKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKy0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgfCAgICAy
IC0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vY3VycmVudC5oICAgfCAgIDIzICsrKysrKysrKysK
IHhlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmggICAgfCAgIDM5ICstLS0tLS0tLS0tLS0t
LS0tCiA3IGZpbGVzIGNoYW5nZWQsIDM1NiBpbnNlcnRpb25zKCspLCA2MSBkZWxldGlvbnMo
LSkKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoK
ZGlmZiAtciAwOGYzOWE5ZGEwNGYgeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQotLS0gYS94
ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkw
MAorKysgYi94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCVN1biBGZWIgMTIgMTE6NDY6MzIg
MjAxMiArMDkwMApAQCAtMjEsMyArMjEsNCBAQCBvYmoteSArPSBjcmFzaC5vCiBvYmoteSAr
PSBwMm0ubwogb2JqLXkgKz0gcGVyZm1vbi5vCiBvYmoteSArPSBwY2kubworb2JqLXkgKz0g
YXJtdjcubwpkaWZmIC1yIDA4ZjM5YTlkYTA0ZiB4ZW4vYXJjaC9hcm0veGVuL2FyY2hfZG9t
YWluLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jCU1vbiBGZWIgMDYg
MTE6MTc6MDEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2FyY2hfZG9tYWlu
LmMJU3VuIEZlYiAxMiAxMTo0NjozMiAyMDEyICswOTAwCkBAIC0zMSw2ICszMSwxMiBAQAog
I2luY2x1ZGUgPHhlbi9pcnEuaD4KICNpbmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4KICNp
bmNsdWRlIDx4ZW4vc29mdGlycS5oPgorI2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+CQorI2lu
Y2x1ZGUgPGFzbS9jcHUtb3BzLmg+CisjaW5jbHVkZSA8YXNtL21lbW9yeS5oPgorI2luY2x1
ZGUgPGFzbS9tbXUuaD4KKworc3RydWN0IHZjcHUgKnN3aXRjaF90byggc3RydWN0IHZjcHUg
Kiwgc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCAqLCBzdHJ1Y3QgdmNwdV9ndWVzdF9jb250
ZXh0ICopOwogCiB2b2lkIGFyY2hfZHVtcF9kb21haW5faW5mbyhzdHJ1Y3QgZG9tYWluICpk
KQogewpAQCAtNTIsMzMgKzU4LDg0IEBAIHVuc2lnbmVkIGxvbmcgaHlwZXJjYWxsX2NyZWF0
ZV9jb250aW51YXQKIAogaW50IGFyY2hfZG9tYWluX2NyZWF0ZShzdHJ1Y3QgZG9tYWluICpk
LCB1bnNpZ25lZCBpbnQgZG9tY3JfZmxhZ3MpCiB7Ci0JTk9UX1lFVCgpOworCWludCByYzsK
IAotCXJldHVybiAtRUlOVkFMOworCXJjID0gMDsKKwlpZiAoaXNfaWRsZV9kb21haW4oZCkp
CisJCXJldHVybiByYzsKKworCWQtPmFyY2guaW9wb3J0X2NhcHMgPSByYW5nZXNldF9uZXco
ZCwgIkkvTyBQb3J0cyIsIFJBTkdFU0VURl9wcmV0dHlwcmludF9oZXgpOworCXJjID0gLUVO
T01FTTsKKwlpZiAoZC0+YXJjaC5pb3BvcnRfY2FwcyA9PSBOVUxMKSB7CisJCWdvdG8gZmFp
bGVkOworCX0KKworCWlmICgoZC0+c2hhcmVkX2luZm8gPSBhbGxvY194ZW5oZWFwX3BhZ2Vz
KDAsIE1FTUZfYml0cygzMikpKSA9PSBOVUxMKSB7CisJCWdvdG8gZmFpbGVkOworCX0KKwor
CWNsZWFyX3BhZ2UoZC0+c2hhcmVkX2luZm8pOworCXNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vl
c3QodmlydF90b19wYWdlKGQtPnNoYXJlZF9pbmZvKSwgZCwgWEVOU0hBUkVfd3JpdGFibGUp
OworCisJZC0+YXJjaC5waXJxX2lycSA9IHhtYWxsb2NfYXJyYXkoaW50LCBkLT5ucl9waXJx
cyk7CisJaWYgKCFkLT5hcmNoLnBpcnFfaXJxKSB7CisJCWdvdG8gZmFpbGVkOworCX0KKwor
CW1lbXNldChkLT5hcmNoLnBpcnFfaXJxLCAwLCBkLT5ucl9waXJxcyAqIHNpemVvZigqZC0+
YXJjaC5waXJxX2lycSkpOworCisJZC0+YXJjaC5pcnFfcGlycSA9IHhtYWxsb2NfYXJyYXko
aW50LCBucl9pcnFzKTsKKwlpZiAoICFkLT5hcmNoLmlycV9waXJxICkgeworCQlnb3RvIGZh
aWxlZDsKKwl9CisKKwltZW1zZXQoZC0+YXJjaC5pcnFfcGlycSwgMCwgbnJfaXJxcyAqIHNp
emVvZigqZC0+YXJjaC5pcnFfcGlycSkpOworCisJcmV0dXJuIDA7CisKK2ZhaWxlZDoKKwlk
LT5pc19keWluZyA9IERPTURZSU5HX2RlYWQ7CisJeGZyZWUoZC0+YXJjaC5waXJxX2lycSk7
CisJeGZyZWUoZC0+YXJjaC5pcnFfcGlycSk7CisKKwlmcmVlX3hlbmhlYXBfcGFnZShkLT5z
aGFyZWRfaW5mbyk7CisKKwlyZXR1cm4gcmM7CiB9CiAKIHZvaWQgYXJjaF9kb21haW5fZGVz
dHJveShzdHJ1Y3QgZG9tYWluICpkKQogewotCU5PVF9ZRVQoKTsKKwlmcmVlX3hlbmhlYXBf
cGFnZShkLT5zaGFyZWRfaW5mbyk7CisKKwl4ZnJlZShkLT5hcmNoLnBpcnFfaXJxKTsKKwl4
ZnJlZShkLT5hcmNoLmlycV9waXJxKTsKIH0KIAogc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4
dCAqYWxsb2NfdmNwdV9ndWVzdF9jb250ZXh0KHZvaWQpCiB7Ci0JTk9UX1lFVCgpOworCXN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgKnZnYzsKIAotCXJldHVybiBOVUxMOworCXZnYyA9
IHhtYWxsb2Moc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCk7CisKKwlyZXR1cm4gdmdjOwog
fQogCiB2b2lkIGZyZWVfdmNwdV9ndWVzdF9jb250ZXh0KHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQgKmNvbnRleHQpCiB7Ci0JTk9UX1lFVCgpOworCXhmcmVlKGNvbnRleHQpOwogfQog
CiAKIHN0cnVjdCB2Y3B1ICphbGxvY192Y3B1X3N0cnVjdCh2b2lkKQogewotCU5PVF9ZRVQo
KTsKLQlyZXR1cm4gTlVMTDsKKwlzdHJ1Y3QgdmNwdSAqdjsKKworCXYgPSB4bWFsbG9jKHN0
cnVjdCB2Y3B1KTsKKwlpZiAoIHYgIT0gTlVMTCApCisJCW1lbXNldCh2LCAwLCBzaXplb2Yo
c3RydWN0IHZjcHUpKTsKKworCisJcmV0dXJuIHY7CiB9CiAKIHZvaWQgYXJjaF92Y3B1X3Jl
c2V0KHN0cnVjdCB2Y3B1ICp2KQpAQCAtODgsNyArMTQ1LDYgQEAgdm9pZCBhcmNoX3ZjcHVf
cmVzZXQoc3RydWN0IHZjcHUgKnYpCiAKIGludCB2Y3B1X2luaXRpYWxpc2Uoc3RydWN0IHZj
cHUgKnYpCiB7Ci0JTk9UX1lFVCgpOwogCXJldHVybiAwOwogfQogCkBAIC05OSwyNyArMTU1
LDMyIEBAIHZvaWQgdmNwdV9kZXN0cm95KHN0cnVjdCB2Y3B1ICp2KQogCiB2b2lkIGZyZWVf
dmNwdV9zdHJ1Y3Qoc3RydWN0IHZjcHUgKnYpCiB7Ci0JTk9UX1lFVCgpOworCXhmcmVlKHYp
OwogfQogCiBzdHJ1Y3QgZG9tYWluICphbGxvY19kb21haW5fc3RydWN0KHZvaWQpCiB7Ci0J
Tk9UX1lFVCgpOworCXN0cnVjdCBkb21haW4gKmQ7CiAKLQlyZXR1cm4gTlVMTDsKKwlkID0g
eG1hbGxvYyhzdHJ1Y3QgZG9tYWluKTsKKwlpZiAoIGQgIT0gTlVMTCApCisJCW1lbXNldChk
LCAwLCBzaXplb2Yoc3RydWN0IGRvbWFpbikpOworCisJcmV0dXJuIGQ7CiB9CiAKIAogdm9p
ZCBmcmVlX2RvbWFpbl9zdHJ1Y3Qoc3RydWN0IGRvbWFpbiAqZCkKIHsKLQlOT1RfWUVUKCk7
CisJeGZyZWUoZCk7CiB9CiAKKy8qIFRoaXMgaXMgY2FsbGVkIGJ5IGFyY2hfZmluYWxfc2V0
dXBfZ3Vlc3QgYW5kIGRvX2Jvb3RfdmNwdSAqLwogaW50IGFyY2hfc2V0X2luZm9fZ3Vlc3Qo
c3RydWN0IHZjcHUgKnYsIHZjcHVfZ3Vlc3RfY29udGV4dF90ICpjdHgpCiB7CiAJTk9UX1lF
VCgpOwogCi0JcmV0dXJuIDA7CisJcmV0dXJuIC1FSU5WQUw7CiAKIH0KIApAQCAtMTM1LDEy
ICsxOTYsMTcgQEAgdm9pZCBkdW1wX3BhZ2VmcmFtZV9pbmZvKHN0cnVjdCBkb21haW4gKgog
CiB2b2lkIGNvbnRleHRfc3dpdGNoKHN0cnVjdCB2Y3B1ICpwcmV2LCBzdHJ1Y3QgdmNwdSAq
bmV4dCkKIHsKLQlOT1RfWUVUKCk7CisJQVNTRVJUKHByZXYgIT0gbmV4dCk7CisJQVNTRVJU
KHZjcHVfcnVubmFibGUobmV4dCkpOworCisgICAgICAgIHByZXYgPSAgc3dpdGNoX3RvKHBy
ZXYsICZwcmV2LT5hcmNoLmN0eCwgJm5leHQtPmFyY2guY3R4KTsKIH0KIAogdm9pZCBjb250
aW51ZV9ydW5uaW5nKHN0cnVjdCB2Y3B1ICpzYW1lKQogewogCU5PVF9ZRVQoKTsKKworCXJl
dHVybiA7CiB9CiAKIHZvaWQgc3luY19sYXp5X2V4ZWNzdGF0ZV9jcHUodW5zaWduZWQgaW50
IGNwdSkKQEAgLTE2OCw2ICsyMzQsMjQgQEAgdm9pZCByZWxpbnF1aXNoX21lbW9yeShzdHJ1
Y3QgZG9tYWluICpkLAogCU5PVF9ZRVQoKTsKIH0KIAordm9pZCB0cmFjZV9kb21oZWFwX3Bh
Z2VzKGNvbnN0IGNoYXIgKmNhcHRpb24sIHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBsaXN0
X2hlYWQgKmxpc3QpCit7CisJc3RydWN0IGxpc3RfaGVhZCAqZW50OworCXN0cnVjdCBwYWdl
X2luZm8gICpwYWdlOworCisJLyogVXNlIGEgcmVjdXJzaXZlIGxvY2ssIGFzIHdlIG1heSBl
bnRlciAnZnJlZV9kb21oZWFwX3BhZ2UnLiAqLworCXNwaW5fbG9ja19yZWN1cnNpdmUoJmQt
PnBhZ2VfYWxsb2NfbG9jayk7CisKKwllbnQgPSBsaXN0LT5uZXh0OworCXdoaWxlICggZW50
ICE9IGxpc3QgKQorCXsKKwkJcGFnZSA9IGxpc3RfZW50cnkoZW50LCBzdHJ1Y3QgcGFnZV9p
bmZvLCBsaXN0KTsKKwkJZW50ID0gZW50LT5uZXh0OworCX0KKworCXNwaW5fdW5sb2NrX3Jl
Y3Vyc2l2ZSgmZC0+cGFnZV9hbGxvY19sb2NrKTsKK30KKwogaW50IGRvbWFpbl9yZWxpbnF1
aXNoX3Jlc291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQogewogCU5PVF9ZRVQoKTsKQEAgLTE3
Nyw3ICsyNjEsMTYgQEAgaW50IGRvbWFpbl9yZWxpbnF1aXNoX3Jlc291cmNlcyhzdHJ1Y3Qg
ZAogCiB2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKQogewotCU5PVF9ZRVQoKTsK
Kwl3aGlsZSgxKSB7CisJCWlmIChjcHVfaXNfaGFsdGFibGUoc21wX3Byb2Nlc3Nvcl9pZCgp
KSkgeworCQkJbG9jYWxfaXJxX2Rpc2FibGUoKTsKKwkJCWNwdV9pZGxlKCk7CisJCQlsb2Nh
bF9pcnFfZW5hYmxlKCk7CisJCX0KKworCQlkb190YXNrbGV0KCk7CisJCWRvX3NvZnRpcnEo
KTsKKwl9CiB9CiAKIGxvbmcgYXJjaF9kb192Y3B1X29wKGludCBjbWQsIHN0cnVjdCB2Y3B1
ICp2LCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKQEAgLTE4OSwyMiArMjgyLDMzIEBA
IGxvbmcgYXJjaF9kb192Y3B1X29wKGludCBjbWQsIHN0cnVjdCB2Y3AKIAogdm9pZCB2Y3B1
X2tpY2soc3RydWN0IHZjcHUgKnYpCiB7Ci0JTk9UX1lFVCgpOworCWJvb2xfdCBydW5uaW5n
ID0gdi0+aXNfcnVubmluZzsKKworCXZjcHVfdW5ibG9jayh2KTsKKworCWlmIChydW5uaW5n
ICYmIChpbl9pcnEoKSB8fCAodiAhPSBjdXJyZW50KSkpIHsKKwkJY3B1X3JhaXNlX3NvZnRp
cnEodi0+cHJvY2Vzc29yLCBWQ1BVX0tJQ0tfU09GVElSUSk7CisJfQogfQogCiB2b2lkIHZj
cHVfbWFya19ldmVudHNfcGVuZGluZyhzdHJ1Y3QgdmNwdSAqdikKIHsKLQlOT1RfWUVUKCk7
CisJaW50IGFscmVhZHkgPSB0ZXN0X2FuZF9zZXRfYml0KDAsICh1bnNpZ25lZCBsb25nICop
JnZjcHVfaW5mbyh2LCBldnRjaG5fdXBjYWxsX3BlbmRpbmcpKTsKKworCWlmIChhbHJlYWR5
KSB7CisJCXJldHVybjsKKwl9CisKKwl2Y3B1X2tpY2sodik7CiB9CiAKIHN0YXRpYyB2b2lk
IHZjcHVfa2lja19zb2Z0aXJxKHZvaWQpCiB7Ci0JTk9UX1lFVCgpOwogfQogCiBzdGF0aWMg
aW50IF9faW5pdCB2Y3B1X2tpY2tfc29mdGlycV9pbml0KHZvaWQpCiB7Ci0JTk9UX1lFVCgp
OworCW9wZW5fc29mdGlycShWQ1BVX0tJQ0tfU09GVElSUSwgdmNwdV9raWNrX3NvZnRpcnEp
OwogCiAJcmV0dXJuIDA7CiB9CmRpZmYgLXIgMDhmMzlhOWRhMDRmIHhlbi9hcmNoL2FybS94
ZW4vYXJtdjcuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2FybXY3LlMJU3VuIEZlYiAxMiAxMTo0NjozMiAy
MDEyICswOTAwCkBAIC0wLDAgKzEsMTkgQEAKKyNpbmNsdWRlIDxhc20vcGFnZS5oPgorI2lu
Y2x1ZGUgPGFzbS9jcHUtb3BzLmg+CisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgorI2luY2x1
ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+Cisj
aW5jbHVkZSA8cHVibGljL2FyY2gtYXJtLmg+CisKKwkudGV4dAorRU5UUlkoY3B1X2lkbGUp
CisJZHNiCisJd2ZpCisJbW92CXBjLCBscgorCitFTlRSWShjcHVfaGFsdCkKKwltb3YJcGMs
IGxyCisKK0VOVFJZKGNwdV9yZXNldCkKKwltb3YJcGMsIGxyCisKZGlmZiAtciAwOGYzOWE5
ZGEwNGYgeGVuL2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwotLS0gYS94ZW4vYXJjaC9h
cm0veGVuL2RvbWFpbl9idWlsZC5jCU1vbiBGZWIgMDYgMTE6MTc6MDEgMjAxMiArMDkwMAor
KysgYi94ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jCVN1biBGZWIgMTIgMTE6NDY6
MzIgMjAxMiArMDkwMApAQCAtMzMsNiArMzMsNjcgQEAKICNpbmNsdWRlIDxwdWJsaWMveGVu
Lmg+CiAjaW5jbHVkZSA8cHVibGljL3ZlcnNpb24uaD4KIAorZXh0ZXJuIHZvaWQgcmV0dXJu
X3RvX2d1ZXN0KCk7CisKK3ZvaWQgdmNwdV9jb250ZXh0X2luaXQoc3RydWN0IHZjcHUgKnYs
IHVuc2lnbmVkIGxvbmcgc3RrLCB1bnNpZ25lZCBsb25nIHBjLCBzdHJ1Y3Qgc3RhcnRfaW5m
byAqc2kpCit7CisJdm9pZCAqc3RhY2s7CisJc3RydWN0IGNwdV9pbmZvICpjaTsKKwlzdHJ1
Y3QgY3B1X2N0eCAqY3B1X2N0eDsKKworCXN0YWNrID0gYWxsb2NfeGVuaGVhcF9wYWdlcyhT
VEFDS19PUkRFUiwgMCk7CisJaWYoc3RhY2sgPT0gTlVMTCkgeworCQlyZXR1cm47CisJfQor
CisJY2kgPSAoc3RydWN0IGNwdV9pbmZvICopc3RhY2s7CisJY2ktPnZjcHUgPSB2OworCWNp
LT52c3AgPSAwOworCWNpLT52c3BzciA9IFBTUl9NT0RFX1NWQzsKKwljaS0+dmRhY3IgPSBE
QUNSX1NUQVRfU1ZDOworCisJc3RhY2sgKz0gKFNUQUNLX1NJWkUgLSBzaXplb2Yoc3RydWN0
IGNwdV9jdHgpKTsKKworCWNwdV9jdHggPSAoc3RydWN0IGNwdV9jdHggKilzdGFjazsKKwlj
cHVfY3R4LT5yMCA9IDA7CisJY3B1X2N0eC0+cjEyID0gKHVuc2lnbmVkIGxvbmcpc2k7CisJ
Y3B1X2N0eC0+dXNwID0gc3RrOworCWNwdV9jdHgtPnVsciA9IDA7CisJY3B1X2N0eC0+c3Nw
ID0gKHVuc2lnbmVkIGxvbmcpKHN0YWNrICsgc2l6ZW9mKHN0cnVjdCBjcHVfY3R4KSk7CisJ
Y3B1X2N0eC0+cGMgPSBwYzsKKwljcHVfY3R4LT5zcHNyID0gMHgxMDsKKworCVZDUFVfUkVH
KHYsIHIxMykgPSAodW5zaWduZWQgbG9uZylzdGFjazsKKwlWQ1BVX1JFRyh2LCByMTQpID0g
KHVuc2lnbmVkIGxvbmcpcmV0dXJuX3RvX2d1ZXN0OworCisJVkNQVV9SRUcodiwgZGFjcikg
PSBEQUNSX1NUQVRfU1ZDOworCVZDUFVfUkVHKHYsIGZjc2VpZHIpID0gMDsKKwlWQ1BVX1JF
Ryh2LCBjb250ZXh0aWRyKSA9IDA7CisJVkNQVV9SRUcodiwgY3BhcikgPSAoMHg0MCkgfCAo
MSA8PCAxMyk7Cit9CisKKyNkZWZpbmUgRE9NX1BGTl9BTElHTgkoU0VDVElPTl9TSVpFID4+
IFBBR0VfU0hJRlQpCisKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGFsbG9jX2RvbWFpbl9wYWdl
cyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgc2l6ZSkKK3sKKwl1bnNpZ25lZCBw
aHlzOworCXVuc2lnbmVkIGxvbmcgcGFnZXMgPSBzaXplID4+IFBBR0VfU0hJRlQ7CisKKwlk
LT5tYXhfcGFnZXMgPSB+KDB4MFVMKTsKKworCXBoeXMgPSBhbGxvY19ib290X3BhZ2VzKHBh
Z2VzLCBET01fUEZOX0FMSUdOKTsKKwkKKwlpZiAoIXBoeXMpIHsKKwkJZC0+dG90X3BhZ2Vz
ID0gMDsKKwkJcmV0dXJuIDA7CisJfQorCisJZC0+dG90X3BhZ2VzID0gcGFnZXM7CisKKwkv
KiBTZXQgUGFnZSBPd25lciAqLworCXJldHVybiBwaHlzIDw8PSBQQUdFX1NISUZUOworfQor
CiAvKgogICogZG9tYWluX2NvbnN0cnVjdCgpIHNob3VsZCBiZSBhbHdheXMgaW52b2tlZCBp
biBpZGxlIGRvbWFpbgogICovCkBAIC00MCw4ICsxMDEsMTMyIEBAIGludCBkb21haW5fY29u
c3RydWN0KHN0cnVjdCBkb21haW4gKmQsCiAJCSAgICAgdW5zaWduZWQgbG9uZyBpbWdfc3Rh
cnQsIHVuc2lnbmVkIGxvbmcgaW1nX2xlbiwgCiAJCSAgICAgdW5zaWduZWQgbG9uZyBkb21f
c2l6ZSwgdW5zaWduZWQgaW50IHZjcHVzKQogewotCU5PVF9ZRVQoKTsKKwlpbnQgaSwgcmM7
CisJc3RydWN0IHZjcHUgKnY7CisJc3RydWN0IGVsZl9iaW5hcnkgZWxmOworCXN0cnVjdCBl
bGZfZG9tX3Bhcm1zIHBhcm1zOworCXN0cnVjdCBzdGFydF9pbmZvICpzaTsKKwl1bnNpZ25l
ZCBsb25nIHZzdGFydCwgdmVuZCwgdmVudHJ5OworCXVuc2lnbmVkIGxvbmcgcHN0YXJ0LCBw
ZW5kLCBwbWFwLCBsZW47CiAKLQlyZXR1cm4gLUVJTlZBTDsKKwlsMWVfdCAqZ3B0OworCisJ
QlVHX09OKGQgPT0gTlVMTCk7CisJQlVHX09OKGRvbV9zaXplICYgflNFQ1RJT05fTUFTSyk7
CisKKwlwc3RhcnQgPSBhbGxvY19kb21haW5fcGFnZXMoZCwgZG9tX3NpemUpOworCWlmICgh
cHN0YXJ0KSB7CisJCXJldHVybiAtRU5PTUVNOworCX0KKworCW1lbWNweSgocHN0YXJ0ICsg
ZG9tX3NpemUgLSBpbWdfbGVuKSwgaW1nX3N0YXJ0LCBpbWdfbGVuKTsKKwlpbWdfc3RhcnQg
PSBwc3RhcnQgKyBkb21fc2l6ZSAtIGltZ19sZW47CisKKwlpZiAoKHJjID0gZWxmX2luaXQo
JmVsZiwgaW1nX3N0YXJ0LCBpbWdfbGVuKSkgIT0gMCkgeworCQlyZXR1cm4gcmM7CisJfQor
CisJZWxmX3BhcnNlX2JpbmFyeSgmZWxmKTsKKworCWlmICgocmMgPSBlbGZfeGVuX3BhcnNl
KCZlbGYsICZwYXJtcykpICE9IDApIHsKKwkJcmV0dXJuIHJjOworCX0KKworCWQtPnZjcHUg
PSB4bWFsbG9jX2FycmF5KHN0cnVjdCB2Y3B1ICosIE1BWF9WSVJUX0NQVVMpOworCWlmICgh
ZC0+dmNwdSkgeworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisKKwltZW1zZXQoZC0+dmNwdSwg
MCwgTUFYX1ZJUlRfQ1BVUyAqIHNpemVvZigqZC0+dmNwdSkpOworCWQtPm1heF92Y3B1cyA9
IE1BWF9WSVJUX0NQVVM7CisKKwlmb3IgKGkgPSAwOyBpIDwgTUFYX1ZJUlRfQ1BVUzsgaSsr
KSB7CisJCWQtPnNoYXJlZF9pbmZvLT52Y3B1X2luZm9baV0uZXZ0Y2huX3VwY2FsbF9tYXNr
ID0gMTsKKwkJZC0+c2hhcmVkX2luZm8tPnZjcHVfaW5mb1tpXS5hcmNoLmNwc3IgPSAoVlBT
Ul9JX0JJVCB8IFZQU1JfRl9CSVQgfCBWUFNSX01PREVfU1ZDKTsKKwl9CisKKwlmb3IgKGkg
PSAwOyBpIDwgdmNwdXM7IGkrKykgeworCQlpZiAoYWxsb2NfdmNwdShkLCBpLCBpKSA9PSBO
VUxMKSB7CisJCQlyZXR1cm4gLUVOT01FTTsKKwkJfQorCX0KKworCXZzdGFydCA9IHBhcm1z
LnZpcnRfa3N0YXJ0ICYgU0VDVElPTl9NQVNLOworCXZlbmQgPSByb3VuZF91cChwYXJtcy52
aXJ0X2tlbmQsIEwxX1RBQkxFX1NJWkUpOworCXZlbnRyeSA9IHBhcm1zLnZpcnRfZW50cnk7
CisKKwlsZW4gPSB2ZW5kIC0gdnN0YXJ0OworCisJLyogR3Vlc3QgIHBhZ2UgdGFibGUgaXMg
bG9jYXRlZCBpbiB0aGUgZW5kIG9mIHZlbmQgKi8KKwlncHQgPSAobDFlX3QgKikocHN0YXJ0
ICsgbGVuKTsKKwkKKwkvKiBEdXBsaWNhdGUgTDEgcGFnZSB0YWJsZSAqLworCW1lbWNweShn
cHQsIHhlbl90cmFuc2xhdGlvbl90YWJsZSwgTDFfVEFCTEVfU0laRSk7CisKKwlwbWFwID0g
cHN0YXJ0OworCXBlbmQgPSBwbWFwICsgZG9tX3NpemU7CisKKworCWdwdCA9IGwxX2xpbmVh
cl9vZmZzZXQoZ3B0LCB2c3RhcnQpOworCisJLyogQ3JlYXRlIDE6MSBtYXBwaW5nICovCisJ
ZG8geworCQkqZ3B0ID0gTUtfTDFFKHBtYXAsIEwxRV9UWVBFX0dVRVNUKTsKKwkJcG1hcCAr
PSBTRUNUSU9OX1NJWkU7CisJfSB3aGlsZShncHQrKywgcG1hcCA8IHBlbmQpOworIAorCS8q
IEFjdGl2YXRlIGd1ZXN0IGFkZHJlc3Mgc3BhY2UgdG8gcmVsb2NhdGUgZ3Vlc3QgaW1hZ2Ug
Ki8KKwltbXVfc3dpdGNoX3R0YihncHQgJiB+KDB4NDAwMCAtIDEpKTsKKworCWVsZi5kZXN0
ID0gKHZvaWQgKil2ZW50cnk7CisJZWxmX2xvYWRfYmluYXJ5KCZlbGYpOworCisJc2kgPSAo
c3RydWN0IHN0YXJ0X2luZm8gKikodmVuZCArIEwxX1RBQkxFX1NJWkUpOworCW1lbXNldChz
aSwgMCwgUEFHRV9TSVpFKTsKKwkKKworCXNpLT5ucl9wYWdlcyAJICA9IGQtPnRvdF9wYWdl
czsKKwlzaS0+c2hhcmVkX2luZm8gICA9IHZpcnRfdG9fbWFkZHIoZC0+c2hhcmVkX2luZm8p
OworCXNpLT5wdF9iYXNlIAkgID0gdmVuZDsKKwlzaS0+bnJfcHRfZnJhbWVzICA9IDQ7CisJ
c2ktPm1mbl9saXN0IAkgID0gMDsKKwlzaS0+Zmlyc3RfcDJtX3BmbiA9IHBzdGFydCA+PiBQ
QUdFX1NISUZUOworCXNpLT5mbGFncyAJICA9IDA7CisJc2ktPm1pbl9tZm4JICA9IHBzdGFy
dCA+PiBQQUdFX1NISUZUOworCisJaWYgKGQtPmRvbWFpbl9pZCA9PSAwKSB7CisJCXNpLT5m
bGFncyA9IFNJRl9QUklWSUxFR0VEIHwgU0lGX0lOSVRET01BSU47CisJfQorCisJdiA9IGQt
PnZjcHVbMF07CisKKwlWQ1BVX1JFRyh2LCB0dGJyMCkgPSAodW5zaWduZWQgbG9uZylncHQ7
CisKKwltbXVfc3dpdGNoX3R0YihWQ1BVX1JFRyhpZGxlX3ZjcHVbMF0sIHR0YnIwKSk7CisK
Kwl2Y3B1X2NvbnRleHRfaW5pdCh2LCAwLCB2ZW50cnksIHNpKTsKKworCXYtPmlzX2luaXRp
YWxpc2VkID0gMTsKKwljbGVhcl9iaXQoX1ZQRl9kb3duLCAmdi0+cGF1c2VfZmxhZ3MpOwor
CisJcmMgPSAwOworCisJLyogRE9NMCBpcyBwZXJtaXR0ZWQgZnVsbCBJL08gY2FwYWJpbGl0
aWVzLiAqLworCXJjIHw9IGlvcG9ydHNfcGVybWl0X2FjY2Vzcyhkb20wLCAwLCAweEZGRkYp
OworCXJjIHw9IGlvbWVtX3Blcm1pdF9hY2Nlc3MoZG9tMCwgMFVMLCB+MFVMKTsKKwlyYyB8
PSBpcnFzX3Blcm1pdF9hY2Nlc3MoZG9tMCwgMCwgZC0+bnJfcGlycXMgLSAxKTsKKworCXJl
dHVybiByYzsKIH0KIAoraW50IGVsZl9zYW5pdHlfY2hlY2soY29uc3QgRWxmX0VoZHIgKmVo
ZHIpCit7CisJaWYgKCAhSVNfRUxGKCplaGRyKSB8fAorCQkoZWhkci0+ZV9pZGVudFtFSV9E
QVRBXSAhPSBFTEZEQVRBMkxTQikgfHwKKwkJKGVoZHItPmVfdHlwZSAhPSBFVF9FWEVDKSAp
IHsKKwkJcHJpbnRrKCJET00wIGltYWdlIGlzIG5vdCBhIFhlbi1jb21wYXRpYmxlIEVsZiBp
bWFnZS5cbiIpOworCQlyZXR1cm4gMDsKKwl9CisKKwlyZXR1cm4gMTsKK30KZGlmZiAtciAw
OGYzOWE5ZGEwNGYgeGVuL2FyY2gvYXJtL3hlbi9tbS5jCi0tLSBhL3hlbi9hcmNoL2FybS94
ZW4vbW0uYwlNb24gRmViIDA2IDExOjE3OjAxIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9tbS5jCVN1biBGZWIgMTIgMTE6NDY6MzIgMjAxMiArMDkwMApAQCAtMjE3LDgg
KzIxNyw2IEBAIHVuc2lnbmVkIGxvbmcgYWxsb2NfcGFnZV90YWJsZXMobDFlX3QgKmwKIAkJ
cmV0dXJuIDA7CiAJfQogCi0vLwljYWNoZV9jbGVhbl9yYW5nZShwYWdlLCBwYWdlICsgUEFH
RV9TSVpFLCAwKTsKLQogCXdpcmVfcGFnZV90YWJsZXMobDFlLCBwYWdlKTsKIAogCXJldHVy
biBwYWdlOwpkaWZmIC1yIDA4ZjM5YTlkYTA0ZiB4ZW4vaW5jbHVkZS9hc20tYXJtL2N1cnJl
bnQuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20tYXJtL2N1cnJlbnQuaAlNb24gRmViIDA2IDEx
OjE3OjAxIDIwMTIgKzA5MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgJ
U3VuIEZlYiAxMiAxMTo0NjozMiAyMDEyICswOTAwCkBAIC0yNyw2ICsyNywyOSBAQAogI2lm
bmRlZiBfX0FTU0VNQkxZX18KIHN0cnVjdCB2Y3B1OwogCitzdHJ1Y3QgY3B1X2N0eCB7Cisg
ICAgICAgIHVuc2lnbmVkIGxvbmcgICByMDsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIx
OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjI7CisgICAgICAgIHVuc2lnbmVkIGxvbmcg
ICByMzsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHI0OworICAgICAgICB1bnNpZ25lZCBs
b25nICAgcjU7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByNjsKKyAgICAgICAgdW5zaWdu
ZWQgbG9uZyAgIHI3OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjg7CisgICAgICAgIHVu
c2lnbmVkIGxvbmcgICByOTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMDsKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHIxMTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMjsK
KyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHVzcDsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAg
IHVscjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHNzcDsKKyAgICAgICAgdW5zaWduZWQg
bG9uZyAgIHNscjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHBjOworICAgICAgICB1bnNp
Z25lZCBsb25nICAgc3BzcjsKK307CisKKwogc3RydWN0IGNwdV9pbmZvIHsKIAlzdHJ1Y3Qg
dmNwdQkqdmNwdTsKIAl1bnNpZ25lZCBsb25nCXZzcHNyOwpkaWZmIC1yIDA4ZjM5YTlkYTA0
ZiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1h
cm0vZG9tYWluLmgJTW9uIEZlYiAwNiAxMToxNzowMSAyMDEyICswOTAwCisrKyBiL3hlbi9p
bmNsdWRlL2FzbS1hcm0vZG9tYWluLmgJU3VuIEZlYiAxMiAxMTo0NjozMiAyMDEyICswOTAw
CkBAIC04LDQyICs4LDggQEAKICNpbmNsdWRlIDxhc20vaW9tbXUuaD4KICNpbmNsdWRlIDxw
dWJsaWMvYXJjaC1hcm0uaD4KIAotI2lmIDAKLSNkZWZpbmUgTUFQSEFTSF9FTlRSSUVTCQkJ
OAotI2RlZmluZSBNQVBIQVNIX0hBU0hGTihwZm4pCQkoKHBmbikgJiAoTUFQSEFTSF9FTlRS
SUVTLTEpKQotI2RlZmluZSBNQVBIQVNIRU5UX05PVElOVVNFCQkoKHUxNil+MFUpCi0KLXN0
cnVjdCB2Y3B1X21hcGhhc2ggewotICAgIHN0cnVjdCB2Y3B1X21hcGhhc2hfZW50cnkgewot
ICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKLSAgICAgICAgdWludDE2X3QgICAgICBpZHg7
Ci0gICAgICAgIHVpbnQxNl90ICAgICAgcmVmY250OwotICAgIH0gaGFzaFtNQVBIQVNIX0VO
VFJJRVNdOwotfV9fY2FjaGVsaW5lX2FsaWduZWQ7Ci0KLQotI2RlZmluZSBNQVBDQUNIRV9P
UkRFUiAgIDgKLSNkZWZpbmUgTUFQQ0FDSEVfRU5UUklFUyAoMSA8PCBNQVBDQUNIRV9PUkRF
UikKLQotc3RydWN0IG1hcGNhY2hlIHsKLSAgICAvKiBUaGUgUFRFcyB0aGF0IHByb3ZpZGUg
dGhlIG1hcHBpbmdzLCBhbmQgYSBjdXJzb3IgaW50byB0aGUgYXJyYXkuICovCi0gICAgbDJl
X3QJKnRhYmxlOwotICAgIHVuc2lnbmVkIGludCBjdXJzb3I7Ci0KLSAgICAvKiBQcm90ZWN0
cyBtYXBfZG9tYWluX3BhZ2UoKS4gKi8KLSAgICBzcGlubG9ja190IGxvY2s7Ci0KLSAgICAv
KiBXaGljaCBtYXBwaW5ncyBhcmUgaW4gdXNlLCBhbmQgd2hpY2ggYXJlIGdhcmJhZ2UgdG8g
cmVhcCBuZXh0IGVwb2NoPyAqLwotICAgIHVuc2lnbmVkIGxvbmcgaW51c2VbQklUU19UT19M
T05HUyhNQVBDQUNIRV9FTlRSSUVTKV07Ci0gICAgdW5zaWduZWQgbG9uZyBnYXJiYWdlW0JJ
VFNfVE9fTE9OR1MoTUFQQ0FDSEVfRU5UUklFUyldOwotCi0gICAgLyogTG9jay1mcmVlIHBl
ci1WQ1BVIGhhc2ggb2YgcmVjZW50bHktdXNlZCBtYXBwaW5ncy4gKi8KLSAgICBzdHJ1Y3Qg
dmNwdV9tYXBoYXNoIHZjcHVfbWFwaGFzaFtNQVhfVklSVF9DUFVTXTsKLX1fX2NhY2hlbGlu
ZV9hbGlnbmVkOwotI2VuZGlmCiBzdHJ1Y3QgYXJjaF9kb21haW4KIHsKLSNpZiAwCiAgICAg
LyogSS9PLXBvcnQgYWRtaW4tc3BlY2lmaWVkIGFjY2VzcyBjYXBhYmlsaXRpZXMuICovCiAg
ICAgc3RydWN0IHJhbmdlc2V0CSppb3BvcnRfY2FwczsKIApAQCAtNTEsOCArMTcsNyBAQCBz
dHJ1Y3QgYXJjaF9kb21haW4KICAgICBpbnQgKnBpcnFfaXJxOwogCiAgICAgdW5zaWduZWQg
bG9uZyAqcGlycV9lb2lfbWFwOwotICAgIHVuc2lnbmVkIGxvbmcgcGlycV9lb2lfbWFwX21m
bjsKLSNlbmRpZgorCiAgICAgc3RydWN0IHBhZ2VfbGlzdF9oZWFkIHJlbG1lbV9saXN0Owog
fTsKIApAQCAtNjEsNyArMjYsNyBAQCBzdHJ1Y3QgYXJjaF92Y3B1CiAJc3RydWN0IHZjcHVf
Z3Vlc3RfY29udGV4dCBjdHg7CiB9IF9fY2FjaGVsaW5lX2FsaWduZWQ7CiAKLS8vI2RlZmlu
ZSBWQ1BVX1JFRyh2LCByZWcpCXYtPmFyY2guY3R4LnJlZworI2RlZmluZSBWQ1BVX1JFRyh2
LCByZWcpCXYtPmFyY2guY3R4LnJlZwogCiAjZGVmaW5lIHJldHVybl9yZWcodikJCSgodikt
PmFyY2guY3R4LnIwKQogCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt15-0005wh-KZ; Mon, 13 Feb 2012 10:20:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqm9-0003F1-3u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:56:41 +0000
Received: from [85.158.139.83:63096] by server-9.bemta-5.messagelabs.com id
	5D/CF-23757-832C83F4; Mon, 13 Feb 2012 07:56:40 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329119796!7366403!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26549 invoked from network); 13 Feb 2012 07:56:39 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-8.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 07:56:39 -0000
Received: from epcpsbge8.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005VZN88EV50@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:56:36 +0900 (KST)
Message-id: <0LZB0052INECEV60@mailout1.samsung.com>
X-AuditID: cbfee612-b7c09ae0000024ca-7a-4f38c23437fc
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge8.samsung.com (EPCPMTA) with SMTP id A0.9E.09418.432C83F4;
	Mon, 13 Feb 2012 16:56:36 +0900 (KST)
Date: Mon, 13 Feb 2012 07:56:36 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075537186@jm77.ryu
Msgkey: 20120213075537186@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075324312@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 04/14]  arm: implement xen init code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <19113662.69871329119793084.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgeGVuIGluaXQgY29kZQ0KDQogeGVuL2FyY2gvYXJtL3hlbi9jcHUuYyAg
IHwgICA4NCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKystLS0tLS0tDQogeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jIHwg
IDEwMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQ0KIDIgZmlsZXMgY2hhbmdl
ZCwgMTY3IGluc2VydGlvbnMoKyksIDE4IGRlbGV0aW9ucygtKQ0KDQpTaWduZWQtb2ZmLWJ5OiBK
YWVtaW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCg0KZGlmZiAtciBmYjA4MTViYTQwYTEg
eGVuL2FyY2gvYXJtL3hlbi9jcHUuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9jcHUuYwlGcmkg
RmViIDAzIDE2OjI2OjQ5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vY3B1LmMJ
RnJpIEZlYiAwMyAxNzoyODoxNSAyMDEyICswOTAwDQpAQCAtMjgsNiArMjgsMTEgQEANCiAjaW5j
bHVkZSA8eGVuL3NjaGVkLmg+DQogI2luY2x1ZGUgPHhlbi9wcmVlbXB0Lmg+DQogI2luY2x1ZGUg
PHhlbi9wZXJjcHUuaD4NCisjaW5jbHVkZSA8YXNtL21tdS5oPg0KKyNpbmNsdWRlIDxhc20vY3Vy
cmVudC5oPg0KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4NCisjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nv
ci5oPg0KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4NCiANCiBjcHVtYXNrX3QgY3B1X29ubGluZV9t
YXA7DQogY3B1bWFza190IGNwdV9wcmVzZW50X21hcDsNCkBAIC00Niw3ICs1MSwxMiBAQCBERUZJ
TkVfUEVSX0NQVV9SRUFEX01PU1RMWShjcHVtYXNrX3Zhcl90DQogDQogaW50IF9fY3B1X3VwKHVu
c2lnbmVkIGludCBjcHUpDQogew0KLQlOT1RfWUVUKCk7DQorCWludCByZXQgPSAwOw0KKw0KKwl3
aGlsZSghY3B1X29ubGluZShjcHUpKSB7DQorCQljcHVfcmVsYXgoKTsNCisJCXByb2Nlc3NfcGVu
ZGluZ19zb2Z0aXJxcygpOw0KKwl9DQogDQogCXJldHVybiAwOw0KIH0NCkBAIC02MywzNSArNzMs
OTMgQEAgdm9pZCBfX2NwdV9kaWUodW5zaWduZWQgaW50IGNwdSkNCiANCiB2b2lkIHNldF9jcHVf
c2libGluZ19tYXAodW5zaWduZWQgaW50IGNwdSkNCiB7DQotCU5PVF9ZRVQoKTsNCisJdW5zaWdu
ZWQgaW50IGk7DQorDQorCWZvcl9lYWNoX3ByZXNlbnRfY3B1KGkpIHsNCisJCWNwdW1hc2tfc2V0
X2NwdShpLCAmcGVyX2NwdShjcHVfc2libGluZ19tYXNrLCBjcHUpKTsNCisJCWNwdW1hc2tfc2V0
X2NwdShjcHUsICZwZXJfY3B1KGNwdV9zaWJsaW5nX21hc2ssIGkpKTsNCisNCisJCWNwdW1hc2tf
c2V0X2NwdShpLCAmcGVyX2NwdShjcHVfY29yZV9tYXNrLCBjcHUpKTsNCisJCWNwdW1hc2tfc2V0
X2NwdShjcHUsICZwZXJfY3B1KGNwdV9jb3JlX21hc2ssIGkpKTsNCisJfQ0KIH0NCiANCiB2b2lk
IHNtcF9wcmVwYXJlX2NwdXModW5zaWduZWQgaW50IG1heF9jcHVzKQ0KIHsNCi0JTk9UX1lFVCgp
Ow0KKwlzZXRfY3B1X3NpYmxpbmdfbWFwKDApOw0KIH0NCiANCiB2b2lkIHNtcF9wcmVwYXJlX2Jv
b3RfY3B1KHZvaWQpDQogew0KLQlOT1RfWUVUKCk7DQorCWludCBjcHUgPSBzbXBfcHJvY2Vzc29y
X2lkKCk7DQorDQorCWNwdW1hc2tfc2V0X2NwdShjcHUsICZjcHVfb25saW5lX21hcCk7DQorCWNw
dW1hc2tfc2V0X2NwdShjcHUsICZjcHVfcHJlc2VudF9tYXApOw0KKwljcHVtYXNrX3NldF9jcHUo
Y3B1LCAmY3B1X3Bvc3NpYmxlX21hcCk7DQorDQorCWNwdV9pbmZvX2luaXQoZ2V0X2NwdV9pbmZv
KCkpOw0KIH0NCiANCiBhc21saW5rYWdlIHZvaWQgc3RhcnRfeGVuX29uX3NsYXZlX2NwdSh2b2lk
KQ0KIHsNCi0JTk9UX1lFVCgpOw0KKwl1bnNpZ25lZCBpbnQgY3B1Ow0KKwlzdHJ1Y3QgdmNwdSAq
djsJDQorDQorCWNwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsNCisNCisgICAgICAgIC8qIGlkbGUg
dmNwdSBpcyBhbGxvY2F0ZWQgYnkgc2NoZWR1bGVyX2luaXQoKSAqLw0KKyAgICAgICAgdiA9IGlk
bGVfdmNwdVtjcHVdOw0KKwlzZXRfY3VycmVudChpZGxlX3ZjcHVbY3B1XSk7DQorDQorCXNldF9j
cHVfc2libGluZ19tYXAoY3B1KTsNCisNCisJbm90aWZ5X2NwdV9zdGFydGluZyhjcHUpOw0KKwl3
bWIoKTsNCisNCisJY3B1bWFza19zZXRfY3B1KGNwdSwgJmNwdV9vbmxpbmVfbWFwKTsNCisJd21i
KCk7DQorDQorCWxvY2FsX2lycV9lbmFibGUoKTsNCisJbG9jYWxfZmlxX2VuYWJsZSgpOw0KKw0K
KwlzdGFydHVwX2NwdV9pZGxlX2xvb3AoKTsNCiB9DQogDQogdm9pZCBzbXBfc2VuZF9ldmVudF9j
aGVja19tYXNrKGNvbnN0IGNwdW1hc2tfdCAqbWFzaykNCiB7DQotCU5PVF9ZRVQoKTsNCisJaW50
IGNwdTsNCisJdW5zaWduZWQgbG9uZyBtYXAgPSAwOw0KKw0KKwlmb3JfZWFjaF9jcHUoY3B1LCBt
YXNrKSB7DQorCQltYXAgfD0gMSA8PCBjcHU7DQorCX0NCisNCisJLyogVHJpZ2dlciByZW1vdGUg
Q1BVICovDQogfQ0KIA0KIHZvaWQgc21wX2NhbGxfZnVuY3Rpb24odm9pZCAoKmYpKHZvaWQgKnBh
cmFtKSwgdm9pZCAqcGFyYW0sIGludCB3YWl0KQ0KIHsNCi0JTk9UX1lFVCgpOw0KIH0NCiANCiB2
b2lkIHNtcF9zZW5kX3N0YXRlX2R1bXAodW5zaWduZWQgaW50IGNwdSkNCiB7DQotCU5PVF9ZRVQo
KTsNCiB9DQorDQordm9pZCBjcHVfdG9wb2xvZ3lfaW5pdCh1bnNpZ25lZCBpbnQgY3B1cykNCit7
DQorCWludCBpOw0KKw0KKwlpZiAoY3B1cyA9PSAwKSB7DQorCQljcHVzID0gMTsNCisJfQ0KKw0K
KwlpZiAoY3B1cyA+IE1BWF9QSFlTX0NQVVMpIHsNCisJCWNwdXMgPSBNQVhfUEhZU19DUFVTOw0K
Kwl9DQorDQorCWZvciAoaSA9IDA7IGkgPCBjcHVzOyBpKyspIHsNCisJCWNwdW1hc2tfc2V0X2Nw
dShpLCAmY3B1X3Bvc3NpYmxlX21hcCk7DQorCQljcHVtYXNrX3NldF9jcHUoaSwgJmNwdV9wcmVz
ZW50X21hcCk7DQorCX0NCit9DQorDQpkaWZmIC1yIGZiMDgxNWJhNDBhMSB4ZW4vYXJjaC9hcm0v
eGVuL3NldHVwLmMNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vc2V0dXAuYwlGcmkgRmViIDAzIDE2
OjI2OjQ5IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vc2V0dXAuYwlGcmkgRmVi
IDAzIDE3OjI4OjE1IDIwMTIgKzA5MDANCkBAIC0zMCwzNSArMzAsMTE2IEBADQogI2luY2x1ZGUg
PHhlbi9wcmVlbXB0Lmg+DQogI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+DQogI2luY2x1ZGUg
PHB1YmxpYy9zY2hlZC5oPg0KLQ0KKyNpbmNsdWRlIDxhc20vbW11Lmg+DQogDQogc3RydWN0IGRv
bWFpbiBfZG9tX3hlbiA9IHsNCi0gICAgICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCi0g
ICAgICAgIC5kb21haW5faWQgPSBET01JRF9YRU4sDQotICAgICAgICAuZG9tYWluX2xvY2sgPSBT
UElOX0xPQ0tfVU5MT0NLRUQsDQorCS5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCisJLmRvbWFp
bl9pZCA9IERPTUlEX1hFTiwNCisJLmRvbWFpbl9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VELA0K
IH07DQogDQogc3RydWN0IGRvbWFpbiBfZG9tX2lvID0gew0KLSAgICAgICAgLnJlZmNudCA9IEFU
T01JQ19JTklUKDEpLA0KLSAgICAgICAgLmRvbWFpbl9pZCA9IERPTUlEX0lPLA0KLSAgICAgICAg
LmRvbWFpbl9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VELA0KKwkucmVmY250ID0gQVRPTUlDX0lO
SVQoMSksDQorCS5kb21haW5faWQgPSBET01JRF9JTywNCisJLmRvbWFpbl9sb2NrID0gU1BJTl9M
T0NLX1VOTE9DS0VELA0KIH07DQogDQogc3RydWN0IGRvbWFpbiBfZG9tX2NvdyA9IHsNCi0gICAg
ICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCi0gICAgICAgIC5kb21haW5faWQgPSBET01J
RF9DT1csDQotICAgICAgICAuZG9tYWluX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsDQorCS5y
ZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwNCisJLmRvbWFpbl9pZCA9IERPTUlEX0NPVywNCisJLmRv
bWFpbl9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VELA0KIH07DQogDQogc3RydWN0IGRvbWFpbiAq
ZG9tX3hlbiA9ICZfZG9tX3hlbjsNCiBzdHJ1Y3QgZG9tYWluICpkb21faW8gPSAmX2RvbV9pbzsN
CiBzdHJ1Y3QgZG9tYWluICpkb21fY293ID0gJl9kb21fY293Ow0KIA0KKy8qIG1heGNwdXM6IG1h
eGltdW0gbnVtYmVyIG9mIENQVXMgdG8gYmUgYWN0aXZhdGVkICovDQorc3RhdGljIHVuc2lnbmVk
IGludCBtYXhfY3B1cyA9IE5SX0NQVVM7DQoraW50ZWdlcl9wYXJhbSgibWF4Y3B1cyIsIG1heF9j
cHVzKTsNCisNCisvKiBEZWZhdWx0IGRvbWFpbiBzaXplID0gNjRNQiAqLw0KK3N0YXRpYyB1bnNp
Z25lZCBpbnQgZG9tMF9zaXplID0gMjU2ICogMTAyNCAqIDEwMjQ7DQoraW50ZWdlcl9wYXJhbSgi
ZG9tMF9zaXplIiwgZG9tMF9zaXplKTsNCisNCisvL3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBf
aW1hZ2Vfc3RhcnQgPSAweDQwQjAwMDAwVUw7DQorc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9p
bWFnZV9zdGFydCA9IDB4MDBCMDAwMDBVTDsNCitpbnRlZ2VyX3BhcmFtKCJpbWFnZV9zdGFydCIs
IGRvbTBfaW1hZ2Vfc3RhcnQpOw0KKw0KKy8vc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFn
ZV9zaXplID0gMHhBMDAwMDBVTDsNCitzdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3Np
emUgPSAweEEwMDAwMFVMOw0KK2ludGVnZXJfcGFyYW0oImltYWdlX2xlbmd0aCIsIGRvbTBfaW1h
Z2Vfc2l6ZSk7DQorDQogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVzX2lu
Zm9fdCAqaW5mbykNCiB7DQogfQ0KIA0KK3N0YXRpYyB2b2lkIGlkbGVfZG9tYWluX2luaXQodm9p
ZCkNCit7DQorCXN0cnVjdCB2Y3B1ICp2Ow0KKw0KKwlzY2hlZHVsZXJfaW5pdCgpOw0KKw0KKwkv
KiBpZGxlIHZjcHUgaXMgYWxsb2NhdGVkIGJ5IHNjaGVkdWxlcl9pbml0KCkgKi8NCisJdiA9IGlk
bGVfdmNwdVswXTsNCisNCisJc2V0X2N1cnJlbnRfdmNwdSh2KTsNCit9DQorDQogYXNtbGlua2Fn
ZSB2b2lkIHN0YXJ0X3hlbih2b2lkKQ0KIHsNCisJdW5zaWduZWQgaW50IGk7DQorDQorCXNtcF9w
cmVwYXJlX2Jvb3RfY3B1KCk7DQorDQorCXNvZnRpcnFfaW5pdCgpOw0KKw0KKwl0YXNrbGV0X3N1
YnN5c19pbml0KCk7DQorDQorCXRpbWVyX2luaXQoKTsNCisNCisJaWRsZV9kb21haW5faW5pdCgp
Ow0KKw0KKwlyY3VfaW5pdCgpOw0KKw0KKwlsb2NhbF9pcnFfZW5hYmxlKCk7DQorDQorCXNtcF9w
cmVwYXJlX2NwdXMobWF4X2NwdXMpOw0KKw0KKwlkb19wcmVzbXBfaW5pdGNhbGxzKCk7DQorDQor
CXRpbWVrZWVwaW5nX2luaXQoKTsNCisNCisJZm9yX2VhY2hfcHJlc2VudF9jcHUoaSkgew0KKwkJ
aWYgKG51bV9vbmxpbmVfY3B1cygpIDwgbWF4X2NwdXMgJiYgIWNwdV9vbmxpbmUoaSkpIHsNCisJ
CQlpbnQgcmV0ID0gY3B1X3VwKGkpOw0KKwkNCisJCQlpZiAocmV0ICE9IDApIHsNCisJCQkJcHJp
bnRrKCJGYWlsIHRvIGJyaW5nIHVwIENQVSAldSAoZXJyb3IgJWQpXG4iLCBpLCByZXQpOw0KKwkJ
CX0NCisJCX0NCisJfQ0KKw0KKwlwcmludGsoIkJyb3VnaHQgdXAgJWxkIENQVXNcbiIsIChsb25n
KW51bV9vbmxpbmVfY3B1cygpKTsNCisNCisJZG9faW5pdGNhbGxzKCk7DQorDQorCWRvbTAgPSBk
b21haW5fY3JlYXRlKDAsIDAsIDApOw0KKwlpZiAoZG9tMCA9PSBOVUxMKSB7DQorCQlwYW5pYygi
RG9tYWluIGNyZWF0aW9uIGZhaWxlZFxuIik7DQorCX0NCisNCisNCisJaWYgKGRvbWFpbl9jb25z
dHJ1Y3QoZG9tMCwNCisJCQkgICAgIGRvbTBfaW1hZ2Vfc3RhcnQsIA0KKwkJCSAgICAgZG9tMF9p
bWFnZV9zaXplLCANCisJCQkgICAgIGRvbTBfc2l6ZSwgDQorCQkJICAgICBtYXhfY3B1cykpIHsN
CisJCVBBTklDKCJEb21haW4gY29uc3RydWN0aW9uIGZhaWxlZFxuIik7DQorCX0NCisNCisJZG9t
YWluX3VucGF1c2VfYnlfc3lzdGVtY29udHJvbGxlcihkb20wKTsNCisNCisJc3RhcnR1cF9jcHVf
aWRsZV9sb29wKCk7DQogfQ0KIA0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch04.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch04.diff"


YXJtOiBpbXBsZW1lbnQgeGVuIGluaXQgY29kZQoKIHhlbi9hcmNoL2FybS94ZW4vY3B1LmMg
ICB8ICAgODQgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLQogeGVuL2FyY2gvYXJtL3hlbi9zZXR1
cC5jIHwgIDEwMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQogMiBm
aWxlcyBjaGFuZ2VkLCAxNjcgaW5zZXJ0aW9ucygrKSwgMTggZGVsZXRpb25zKC0pCgpTaWdu
ZWQtb2ZmLWJ5OiBKYWVtaW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KCmRpZmYgLXIg
ZmIwODE1YmE0MGExIHhlbi9hcmNoL2FybS94ZW4vY3B1LmMKLS0tIGEveGVuL2FyY2gvYXJt
L3hlbi9jcHUuYwlGcmkgRmViIDAzIDE2OjI2OjQ5IDIwMTIgKzA5MDAKKysrIGIveGVuL2Fy
Y2gvYXJtL3hlbi9jcHUuYwlGcmkgRmViIDAzIDE3OjI4OjE1IDIwMTIgKzA5MDAKQEAgLTI4
LDYgKzI4LDExIEBACiAjaW5jbHVkZSA8eGVuL3NjaGVkLmg+CiAjaW5jbHVkZSA8eGVuL3By
ZWVtcHQuaD4KICNpbmNsdWRlIDx4ZW4vcGVyY3B1Lmg+CisjaW5jbHVkZSA8YXNtL21tdS5o
PgorI2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+CisjaW5jbHVkZSA8YXNtL2RlbGF5Lmg+Cisj
aW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgorI2luY2x1ZGUgPGFzbS9kZWxheS5oPgogCiBj
cHVtYXNrX3QgY3B1X29ubGluZV9tYXA7CiBjcHVtYXNrX3QgY3B1X3ByZXNlbnRfbWFwOwpA
QCAtNDYsNyArNTEsMTIgQEAgREVGSU5FX1BFUl9DUFVfUkVBRF9NT1NUTFkoY3B1bWFza192
YXJfdAogCiBpbnQgX19jcHVfdXAodW5zaWduZWQgaW50IGNwdSkKIHsKLQlOT1RfWUVUKCk7
CisJaW50IHJldCA9IDA7CisKKwl3aGlsZSghY3B1X29ubGluZShjcHUpKSB7CisJCWNwdV9y
ZWxheCgpOworCQlwcm9jZXNzX3BlbmRpbmdfc29mdGlycXMoKTsKKwl9CiAKIAlyZXR1cm4g
MDsKIH0KQEAgLTYzLDM1ICs3Myw5MyBAQCB2b2lkIF9fY3B1X2RpZSh1bnNpZ25lZCBpbnQg
Y3B1KQogCiB2b2lkIHNldF9jcHVfc2libGluZ19tYXAodW5zaWduZWQgaW50IGNwdSkKIHsK
LQlOT1RfWUVUKCk7CisJdW5zaWduZWQgaW50IGk7CisKKwlmb3JfZWFjaF9wcmVzZW50X2Nw
dShpKSB7CisJCWNwdW1hc2tfc2V0X2NwdShpLCAmcGVyX2NwdShjcHVfc2libGluZ19tYXNr
LCBjcHUpKTsKKwkJY3B1bWFza19zZXRfY3B1KGNwdSwgJnBlcl9jcHUoY3B1X3NpYmxpbmdf
bWFzaywgaSkpOworCisJCWNwdW1hc2tfc2V0X2NwdShpLCAmcGVyX2NwdShjcHVfY29yZV9t
YXNrLCBjcHUpKTsKKwkJY3B1bWFza19zZXRfY3B1KGNwdSwgJnBlcl9jcHUoY3B1X2NvcmVf
bWFzaywgaSkpOworCX0KIH0KIAogdm9pZCBzbXBfcHJlcGFyZV9jcHVzKHVuc2lnbmVkIGlu
dCBtYXhfY3B1cykKIHsKLQlOT1RfWUVUKCk7CisJc2V0X2NwdV9zaWJsaW5nX21hcCgwKTsK
IH0KIAogdm9pZCBzbXBfcHJlcGFyZV9ib290X2NwdSh2b2lkKQogewotCU5PVF9ZRVQoKTsK
KwlpbnQgY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgpOworCisJY3B1bWFza19zZXRfY3B1KGNw
dSwgJmNwdV9vbmxpbmVfbWFwKTsKKwljcHVtYXNrX3NldF9jcHUoY3B1LCAmY3B1X3ByZXNl
bnRfbWFwKTsKKwljcHVtYXNrX3NldF9jcHUoY3B1LCAmY3B1X3Bvc3NpYmxlX21hcCk7CisK
KwljcHVfaW5mb19pbml0KGdldF9jcHVfaW5mbygpKTsKIH0KIAogYXNtbGlua2FnZSB2b2lk
IHN0YXJ0X3hlbl9vbl9zbGF2ZV9jcHUodm9pZCkKIHsKLQlOT1RfWUVUKCk7CisJdW5zaWdu
ZWQgaW50IGNwdTsKKwlzdHJ1Y3QgdmNwdSAqdjsJCisKKwljcHUgPSBzbXBfcHJvY2Vzc29y
X2lkKCk7CisKKyAgICAgICAgLyogaWRsZSB2Y3B1IGlzIGFsbG9jYXRlZCBieSBzY2hlZHVs
ZXJfaW5pdCgpICovCisgICAgICAgIHYgPSBpZGxlX3ZjcHVbY3B1XTsKKwlzZXRfY3VycmVu
dChpZGxlX3ZjcHVbY3B1XSk7CisKKwlzZXRfY3B1X3NpYmxpbmdfbWFwKGNwdSk7CisKKwlu
b3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7CisJd21iKCk7CisKKwljcHVtYXNrX3NldF9jcHUo
Y3B1LCAmY3B1X29ubGluZV9tYXApOworCXdtYigpOworCisJbG9jYWxfaXJxX2VuYWJsZSgp
OworCWxvY2FsX2ZpcV9lbmFibGUoKTsKKworCXN0YXJ0dXBfY3B1X2lkbGVfbG9vcCgpOwog
fQogCiB2b2lkIHNtcF9zZW5kX2V2ZW50X2NoZWNrX21hc2soY29uc3QgY3B1bWFza190ICpt
YXNrKQogewotCU5PVF9ZRVQoKTsKKwlpbnQgY3B1OworCXVuc2lnbmVkIGxvbmcgbWFwID0g
MDsKKworCWZvcl9lYWNoX2NwdShjcHUsIG1hc2spIHsKKwkJbWFwIHw9IDEgPDwgY3B1Owor
CX0KKworCS8qIFRyaWdnZXIgcmVtb3RlIENQVSAqLwogfQogCiB2b2lkIHNtcF9jYWxsX2Z1
bmN0aW9uKHZvaWQgKCpmKSh2b2lkICpwYXJhbSksIHZvaWQgKnBhcmFtLCBpbnQgd2FpdCkK
IHsKLQlOT1RfWUVUKCk7CiB9CiAKIHZvaWQgc21wX3NlbmRfc3RhdGVfZHVtcCh1bnNpZ25l
ZCBpbnQgY3B1KQogewotCU5PVF9ZRVQoKTsKIH0KKwordm9pZCBjcHVfdG9wb2xvZ3lfaW5p
dCh1bnNpZ25lZCBpbnQgY3B1cykKK3sKKwlpbnQgaTsKKworCWlmIChjcHVzID09IDApIHsK
KwkJY3B1cyA9IDE7CisJfQorCisJaWYgKGNwdXMgPiBNQVhfUEhZU19DUFVTKSB7CisJCWNw
dXMgPSBNQVhfUEhZU19DUFVTOworCX0KKworCWZvciAoaSA9IDA7IGkgPCBjcHVzOyBpKysp
IHsKKwkJY3B1bWFza19zZXRfY3B1KGksICZjcHVfcG9zc2libGVfbWFwKTsKKwkJY3B1bWFz
a19zZXRfY3B1KGksICZjcHVfcHJlc2VudF9tYXApOworCX0KK30KKwpkaWZmIC1yIGZiMDgx
NWJhNDBhMSB4ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hl
bi9zZXR1cC5jCUZyaSBGZWIgMDMgMTY6MjY6NDkgMjAxMiArMDkwMAorKysgYi94ZW4vYXJj
aC9hcm0veGVuL3NldHVwLmMJRnJpIEZlYiAwMyAxNzoyODoxNSAyMDEyICswOTAwCkBAIC0z
MCwzNSArMzAsMTE2IEBACiAjaW5jbHVkZSA8eGVuL3ByZWVtcHQuaD4KICNpbmNsdWRlIDxw
dWJsaWMvdmVyc2lvbi5oPgogI2luY2x1ZGUgPHB1YmxpYy9zY2hlZC5oPgotCisjaW5jbHVk
ZSA8YXNtL21tdS5oPgogCiBzdHJ1Y3QgZG9tYWluIF9kb21feGVuID0gewotICAgICAgICAu
cmVmY250ID0gQVRPTUlDX0lOSVQoMSksCi0gICAgICAgIC5kb21haW5faWQgPSBET01JRF9Y
RU4sCi0gICAgICAgIC5kb21haW5fbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRCwKKwkucmVm
Y250ID0gQVRPTUlDX0lOSVQoMSksCisJLmRvbWFpbl9pZCA9IERPTUlEX1hFTiwKKwkuZG9t
YWluX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsCiB9OwogCiBzdHJ1Y3QgZG9tYWluIF9k
b21faW8gPSB7Ci0gICAgICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwKLSAgICAgICAg
LmRvbWFpbl9pZCA9IERPTUlEX0lPLAotICAgICAgICAuZG9tYWluX2xvY2sgPSBTUElOX0xP
Q0tfVU5MT0NLRUQsCisJLnJlZmNudCA9IEFUT01JQ19JTklUKDEpLAorCS5kb21haW5faWQg
PSBET01JRF9JTywKKwkuZG9tYWluX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsCiB9Owog
CiBzdHJ1Y3QgZG9tYWluIF9kb21fY293ID0gewotICAgICAgICAucmVmY250ID0gQVRPTUlD
X0lOSVQoMSksCi0gICAgICAgIC5kb21haW5faWQgPSBET01JRF9DT1csCi0gICAgICAgIC5k
b21haW5fbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRCwKKwkucmVmY250ID0gQVRPTUlDX0lO
SVQoMSksCisJLmRvbWFpbl9pZCA9IERPTUlEX0NPVywKKwkuZG9tYWluX2xvY2sgPSBTUElO
X0xPQ0tfVU5MT0NLRUQsCiB9OwogCiBzdHJ1Y3QgZG9tYWluICpkb21feGVuID0gJl9kb21f
eGVuOwogc3RydWN0IGRvbWFpbiAqZG9tX2lvID0gJl9kb21faW87CiBzdHJ1Y3QgZG9tYWlu
ICpkb21fY293ID0gJl9kb21fY293OwogCisvKiBtYXhjcHVzOiBtYXhpbXVtIG51bWJlciBv
ZiBDUFVzIHRvIGJlIGFjdGl2YXRlZCAqLworc3RhdGljIHVuc2lnbmVkIGludCBtYXhfY3B1
cyA9IE5SX0NQVVM7CitpbnRlZ2VyX3BhcmFtKCJtYXhjcHVzIiwgbWF4X2NwdXMpOworCisv
KiBEZWZhdWx0IGRvbWFpbiBzaXplID0gNjRNQiAqLworc3RhdGljIHVuc2lnbmVkIGludCBk
b20wX3NpemUgPSAyNTYgKiAxMDI0ICogMTAyNDsKK2ludGVnZXJfcGFyYW0oImRvbTBfc2l6
ZSIsIGRvbTBfc2l6ZSk7CisKKy8vc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFnZV9z
dGFydCA9IDB4NDBCMDAwMDBVTDsKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c3RhcnQgPSAweDAwQjAwMDAwVUw7CitpbnRlZ2VyX3BhcmFtKCJpbWFnZV9zdGFydCIsIGRv
bTBfaW1hZ2Vfc3RhcnQpOworCisvL3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c2l6ZSA9IDB4QTAwMDAwVUw7CitzdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3Np
emUgPSAweEEwMDAwMFVMOworaW50ZWdlcl9wYXJhbSgiaW1hZ2VfbGVuZ3RoIiwgZG9tMF9p
bWFnZV9zaXplKTsKKwogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVz
X2luZm9fdCAqaW5mbykKIHsKIH0KIAorc3RhdGljIHZvaWQgaWRsZV9kb21haW5faW5pdCh2
b2lkKQoreworCXN0cnVjdCB2Y3B1ICp2OworCisJc2NoZWR1bGVyX2luaXQoKTsKKworCS8q
IGlkbGUgdmNwdSBpcyBhbGxvY2F0ZWQgYnkgc2NoZWR1bGVyX2luaXQoKSAqLworCXYgPSBp
ZGxlX3ZjcHVbMF07CisKKwlzZXRfY3VycmVudF92Y3B1KHYpOworfQorCiBhc21saW5rYWdl
IHZvaWQgc3RhcnRfeGVuKHZvaWQpCiB7CisJdW5zaWduZWQgaW50IGk7CisKKwlzbXBfcHJl
cGFyZV9ib290X2NwdSgpOworCisJc29mdGlycV9pbml0KCk7CisKKwl0YXNrbGV0X3N1YnN5
c19pbml0KCk7CisKKwl0aW1lcl9pbml0KCk7CisKKwlpZGxlX2RvbWFpbl9pbml0KCk7CisK
KwlyY3VfaW5pdCgpOworCisJbG9jYWxfaXJxX2VuYWJsZSgpOworCisJc21wX3ByZXBhcmVf
Y3B1cyhtYXhfY3B1cyk7CisKKwlkb19wcmVzbXBfaW5pdGNhbGxzKCk7CisKKwl0aW1la2Vl
cGluZ19pbml0KCk7CisKKwlmb3JfZWFjaF9wcmVzZW50X2NwdShpKSB7CisJCWlmIChudW1f
b25saW5lX2NwdXMoKSA8IG1heF9jcHVzICYmICFjcHVfb25saW5lKGkpKSB7CisJCQlpbnQg
cmV0ID0gY3B1X3VwKGkpOworCQorCQkJaWYgKHJldCAhPSAwKSB7CisJCQkJcHJpbnRrKCJG
YWlsIHRvIGJyaW5nIHVwIENQVSAldSAoZXJyb3IgJWQpXG4iLCBpLCByZXQpOworCQkJfQor
CQl9CisJfQorCisJcHJpbnRrKCJCcm91Z2h0IHVwICVsZCBDUFVzXG4iLCAobG9uZyludW1f
b25saW5lX2NwdXMoKSk7CisKKwlkb19pbml0Y2FsbHMoKTsKKworCWRvbTAgPSBkb21haW5f
Y3JlYXRlKDAsIDAsIDApOworCWlmIChkb20wID09IE5VTEwpIHsKKwkJcGFuaWMoIkRvbWFp
biBjcmVhdGlvbiBmYWlsZWRcbiIpOworCX0KKworCisJaWYgKGRvbWFpbl9jb25zdHJ1Y3Qo
ZG9tMCwKKwkJCSAgICAgZG9tMF9pbWFnZV9zdGFydCwgCisJCQkgICAgIGRvbTBfaW1hZ2Vf
c2l6ZSwgCisJCQkgICAgIGRvbTBfc2l6ZSwgCisJCQkgICAgIG1heF9jcHVzKSkgeworCQlQ
QU5JQygiRG9tYWluIGNvbnN0cnVjdGlvbiBmYWlsZWRcbiIpOworCX0KKworCWRvbWFpbl91
bnBhdXNlX2J5X3N5c3RlbWNvbnRyb2xsZXIoZG9tMCk7CisKKwlzdGFydHVwX2NwdV9pZGxl
X2xvb3AoKTsKIH0KIAo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt18-0005zU-Fm; Mon, 13 Feb 2012 10:20:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqtB-0003yZ-4H
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:03:57 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329120227!8950105!2
X-Originating-IP: [203.254.224.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzMgPT4gMjQzNjYx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7236 invoked from network); 13 Feb 2012 08:03:49 -0000
Received: from mailout3.samsung.com (HELO mailout3.samsung.com)
	(203.254.224.33) by server-10.tower-21.messagelabs.com with SMTP;
	13 Feb 2012 08:03:49 -0000
Received: from epcpsbge8.samsung.com (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00IVBNPYJYB0@mailout3.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:03:46 +0900 (KST)
Message-id: <0LZB00IVONQAJYB0@mailout3.samsung.com>
X-AuditID: cbfee612-b7c09ae0000024ca-52-4f38c3e22cba
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge8.samsung.com (EPCPMTA) with SMTP id 9F.C3.09418.2E3C83F4;
	Mon, 13 Feb 2012 17:03:46 +0900 (KST)
Date: Mon, 13 Feb 2012 08:03:46 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: =?euc-kr?Q?=B7=F9=C0=E7=B9=CE?= <jm77.ryu@samsung.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080232243@jm77.ryu
Msgkey: 20120213080232243@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080134863@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 11/14] arm: add files that are required to
 support the Tegra2 harmony board.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <7423992.70311329120222915.JavaMail.weblogic@epv6ml04>

YXJtOiBhZGQgZmlsZXMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgVGVncmEyIGhh
cm1vbnkgYm9hcmQuDQoNCiB4ZW4vYXJjaC9hcm0vdGVncmEvTWFrZWZpbGUgICAgICAgIHwgICAg
MyArLQ0KIHhlbi9hcmNoL2FybS90ZWdyYS9lbnRyeS5TICAgICAgICAgfCAgIDMzICsrKysrKysr
DQogeGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMgICAgICB8ICAzMzAgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vdGVncmEvdGltZXIuYyAgICAgICAgIHwgIDEx
MCArKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0veGVuL2NwdS5jICAg
ICAgICAgICAgIHwgICAgNSArDQogeGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5jICAgICAgICAgICB8
ICAgIDEgLQ0KIHhlbi9hcmNoL2FybS94ZW4vaXJxLmMgICAgICAgICAgICAgfCAgIDQ2ICsrKysr
KysrKysrLQ0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgICAgfCAgIDI0ICsrKysr
Kw0KIHhlbi9hcmNoL2FybS94ZW4vc2V0dXAuYyAgICAgICAgICAgfCAgICA2ICstDQogeGVuL2Fy
Y2gvYXJtL3hlbi90aW1lLmMgICAgICAgICAgICB8ICAgIDEgLQ0KIHhlbi9kcml2ZXJzL2NoYXIv
Y29uc29sZS5jICAgICAgICAgfCAgICA0ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2dpYy5oICAg
ICAgICAgIHwgIDEwMSArKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNt
LWFybS9pcnEuaCAgICAgICAgICB8ICAgIDMgKy0NCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3Jh
L2F2cC5oICAgIHwgIDE0NCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4
ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2NvbmZpZy5oIHwgICAgNyArLQ0KIHhlbi9pbmNsdWRl
L2FzbS1hcm0vdGVncmEvaXJxcy5oICAgfCAgIDYwICsrKysrKysrKysrKysrKw0KIHhlbi9pbmNs
dWRlL2FzbS1hcm0vdGVncmEvc21wLmggICAgfCAgICA3ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJt
L3RlZ3JhL3RlZ3JhLmggIHwgICA3NSArKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS94
ZW4vaXJxLmggICAgICAgICAgICAgIHwgICAgNiArDQogMTkgZmlsZXMgY2hhbmdlZCwgOTUyIGlu
c2VydGlvbnMoKyksIDE0IGRlbGV0aW9ucygtKQ0KDQpTaWduZWQtb2ZmLWJ5OiBKYWVtaW4gUnl1
IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCg0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gv
YXJtL3RlZ3JhL01ha2VmaWxlDQotLS0gYS94ZW4vYXJjaC9hcm0vdGVncmEvTWFrZWZpbGUJU3Vu
IEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvTWFr
ZWZpbGUJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtMSwxICsxLDIgQEANCi1v
YmoteSArPSBkdW1teS5vDQorb2JqLXkgKz0gdGltZXIubyBlbnRyeS5vIHRlZ3JhMjUwLm8NCisN
CmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9hcmNoL2FybS90ZWdyYS9lbnRyeS5TDQotLS0gL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysrIGIveGVuL2FyY2gvYXJt
L3RlZ3JhL2VudHJ5LlMJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtMCwwICsx
LDMzIEBADQorLyoNCisgKiBlbnRyeS5TDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMDggU2Ft
c3VuZyBFbGVjdHJvbmljcw0KKyAqICAgICAgICAgIEphZU1pbiBSeXUgIDxqbTc3LnJ5dUBzYW1z
dW5nLmNvbT4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9m
IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVk
IGJ5DQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCisgKg0KKyAqIFRoaXMgcHJv
Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0K
KyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdh
cnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB
UiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBt
b3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9m
IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFsb25nIHdpdGggdGhpcyBwcm9n
cmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQorICogRm91bmRhdGlvbiwg
SW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcg
IFVTQQ0KKyAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+IA0KKyNpbmxjdWRlIDxhc20v
YXJjaC9pcnFzLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0
ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1k
b21haW4uaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQorDQorCS5hbGlnbgk1DQor
DQorRU5UUlkoYXJjaF9jb250ZXh0X3N3aXRjaCkNCisJbW92CXBjLCBscg0KKw0KZGlmZiAtciA2
YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMNCi0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEv
dGVncmEyNTAuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC0wLDAgKzEsMzMw
IEBADQorLyoNCisgKiB0ZWdyYTI1MC5jDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAx
MSBTYW1zdW5nIEVsZWN0cm9uaWNzIA0KKyAqICAgICAgICAgSmFlTWluIFJ5dSAgPGptNzcucnl1
QHNhbXN1bmcuY29tPg0KKyAqDQorICogU2VjdXJlIFhlbiBvbiBBUk0gYXJjaGl0ZWN0dXJlIGRl
c2lnbmVkIGJ5IFNhbmctYnVtIFN1aCBjb25zaXN0cyBvZiANCisgKiBYZW4gb24gQVJNIGFuZCB0
aGUgYXNzb2NpYXRlZCBhY2Nlc3MgY29udHJvbC4NCisgKiANCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAq
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBv
ZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24uDQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh
dCBpdCB3aWxsIGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhv
dXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBG
SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBo
YXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisg
KiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0
d2FyZQ0KKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBC
b3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisjaW5jbHVkZSA8eGVuL2NvbmZp
Zy5oPg0KKyNpbmNsdWRlIDx4ZW4vc3BpbmxvY2suaD4NCisjaW5jbHVkZSA8eGVuL2xpYi5oPg0K
KyNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+DQorI2luY2x1ZGUgPHhlbi9lcnJuby5oPg0KKyNpbmNs
dWRlIDx4ZW4vc21wLmg+DQorI2luY2x1ZGUgPHhlbi9pcnEuaD4NCisjaW5jbHVkZSA8eGVuL21t
Lmg+DQorI2luY2x1ZGUgPGFzbS9tbXUuaD4NCisjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+DQor
I2luY2x1ZGUgPGFzbS9naWMuaD4NCisjaW5jbHVkZSA8YXNtL3JlZ3MuaD4NCisjaW5jbHVkZSA8
YXNtL2lvLmg+DQorI2luY2x1ZGUgPGFzbS9mbHVzaHRsYi5oPg0KKyNpbmNsdWRlIDxhc20vYXJj
aC90ZWdyYS5oPg0KKyNpbmNsdWRlIDxhc20vYXJjaC9pcnFzLmg+DQorDQorI2RlZmluZSBURUdS
QTI1MF9NRU1PUllfQkFTRSAgICAgMHgwMDAwMDAwMFVMDQorI2RlZmluZSBURUdSQTI1MF9NRU1P
UllfU0laRSAgICAgMHg0MDAwMDAwMFVMDQorDQorI2RlZmluZSBURUdSQTI1MF9ERVZfQkFTRSAg
ICAgICAgMHg1MDAwMDAwMFVMDQorI2RlZmluZSBURUdSQTI1MF9ERVZfU0laRSAgICAgICAgMHgw
MDMwMDAwMFVMDQorDQorREVDTEFSRV9NRU1PUllfTUFQKHRlZ3JhMjUwKSA9IHsNCisgICAgICAg
IE1FTU1BUF9FTlRSWShURUdSQTI1MF9NRU1PUllfQkFTRSwgVEVHUkEyNTBfTUVNT1JZX1NJWkUs
IE1FTU9SWV9UWVBFX1JBTSwgTDFFX1RZUEVfSFlQRVJWSVNPUiksDQorICAgICAgICBNRU1NQVBf
RU5UUlkoVEVHUkEyNTBfREVWX0JBU0UsICAgIFRFR1JBMjUwX0RFVl9TSVpFLCAgICBNRU1PUllf
VFlQRV9ERVYsIEwxRV9UWVBFX0RFVklDRSkNCit9Ow0KKw0KKy8vIFJlZ2lzdGVyIEFQQkRNQV9J
UlFfTUFTS19DTFJfMA0KKyNkZWZpbmUgQVBCRE1BX0lSUV9TVEFfQ1BVXzAJKDB4MTQpDQorI2Rl
ZmluZSBBUEJETUFfSVJRX01BU0tfU0VUXzAJKDB4MjApDQorI2RlZmluZSBBUEJETUFfSVJRX01B
U0tfQ0xSXzAJKDB4MjQpDQorDQordm9pZCAqdGVncmFfZ2ljX2NwdV9iYXNlW01BWF9QSFlTX0NQ
VVNdICA9IHswLCAwfTsNCit2b2lkICp0ZWdyYV9naWNfZGlzdF9iYXNlID0gMDsNCisNCitzdHJ1
Y3QgdGVncmFfaXJxX2N0cmwgew0KKwl1bnNpZ25lZCBpbnQgaXJxX3N0YXJ0Ow0KKwl2b2lkICAq
cmVnOw0KK307DQorDQorc3RhdGljIHN0cnVjdCB0ZWdyYV9pcnFfY3RybCB0ZWdyYV9pcnFfY3Ry
bFsoSU5UX1NZU19OUiArIElOVF9TWVNfU1ogLSAxKSAvIElOVF9TWVNfU1pdOw0KKw0KKyNkZWZp
bmUgZ2ljX2lycShpcnEpCShpcnEpDQorDQorc3RhdGljIHZvaWQgdGVncmFfbWFzayhzdHJ1Y3Qg
aXJxX2Rlc2MgKmRlc2MpDQorew0KKwlzdHJ1Y3QgdGVncmFfaXJxX2N0cmwgKmNoaXA7DQorCXVu
c2lnbmVkIGludCBpcnEgPSBkZXNjX3RvX2lycShkZXNjKTsNCisJdW5zaWduZWQgaW50IG1hc2sg
PSAxIDw8IChpcnEgJSAzMik7DQorDQorCW1taW9fd3JpdGVsKG1hc2ssIHRlZ3JhX2dpY19kaXN0
X2Jhc2UgKyBfSUNESUNFUiArIChnaWNfaXJxKGlycSkgLyAzMikgKiA0KTsNCisNCisJaXJxIC09
IElOVF9QUklfQkFTRTsNCisJY2hpcCA9ICZ0ZWdyYV9pcnFfY3RybFtpcnEgLyBJTlRfU1lTX1Na
XTsNCisJbW1pb193cml0ZWwoMSA8PCAoaXJxICYgMzEpLCBjaGlwLT5yZWcgKyBJQ1RMUl9DUFVf
SUVSX0NMUl8wKTsNCit9DQorDQorc3RhdGljIHZvaWQgdGVncmFfdW5tYXNrKHN0cnVjdCBpcnFf
ZGVzYyAqZGVzYykNCit7DQorCXN0cnVjdCB0ZWdyYV9pcnFfY3RybCAqY2hpcDsNCisJdW5zaWdu
ZWQgaW50IGlycSA9IGRlc2NfdG9faXJxKGRlc2MpOw0KKwl1bnNpZ25lZCBpbnQgbWFzayA9IDEg
PDwgKGlycSAlIDMyKTsNCisNCisJbW1pb193cml0ZWwobWFzaywgdGVncmFfZ2ljX2Rpc3RfYmFz
ZSArIF9JQ0RJU0VSICsgKGdpY19pcnEoaXJxKSAvIDMyKSAqIDQpOw0KKw0KKwlpcnEgLT0gSU5U
X1BSSV9CQVNFOw0KKwljaGlwID0gJnRlZ3JhX2lycV9jdHJsW2lycSAvIElOVF9TWVNfU1pdOw0K
KwltbWlvX3dyaXRlbCgxIDw8IChpcnEgJiAzMSksIGNoaXAtPnJlZyArIElDVExSX0NQVV9JRVJf
U0VUXzApOw0KK30NCisNCitzdGF0aWMgdm9pZCB0ZWdyYV9hY2soc3RydWN0IGlycV9kZXNjICpk
ZXNjKQ0KK3sNCisJdW5zaWduZWQgaW50IGlycSA9IGRlc2NfdG9faXJxKGRlc2MpOw0KKwl1bnNp
Z25lZCBpbnQgbWFzayA9IDEgPDwgKGlycSAlIDMyKTsNCisJdW5zaWduZWQgaW50IGNwdSA9IHNt
cF9wcm9jZXNzb3JfaWQoKTsNCisNCisJdGVncmFfbWFzayhkZXNjKTsNCisNCisgICAgICAgIG1t
aW9fd3JpdGVsKG1hc2ssIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNESUNFUiArIChnaWNfaXJx
KGlycSkgLyAzMikgKiA0KTsNCisgICAgICAgIG1taW9fd3JpdGVsKGdpY19pcnEoaXJxKSwgdGVn
cmFfZ2ljX2NwdV9iYXNlW2NwdV0gKyBfSUNDRU9JUik7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIHRl
Z3JhX2VuZChzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpDQorew0KKwl0ZWdyYV91bm1hc2soZGVzYyk7
DQorfQ0KKw0KK2h3X2lycV9jb250cm9sbGVyIHRlZ3JhX2lycV9jb250cm9sbGVyID0gew0KKwku
dHlwZW5hbWUgPSAibGV2ZWwiLA0KKwkuc3RhcnR1cCAgPSB0ZWdyYV91bm1hc2ssDQorCS5zaHV0
ZG93biA9IHRlZ3JhX21hc2ssDQorCS5lbmFibGUJICA9IHRlZ3JhX3VubWFzaywNCisJLmRpc2Fi
bGUgID0gdGVncmFfbWFzaywNCisJLmFjawkgID0gdGVncmFfYWNrLA0KKwkuZW5kCSAgPSB0ZWdy
YV9lbmQsDQorfTsNCisNCitzdGF0aWMgdm9pZCB0ZWdyYTI1MF9pcnFfaW5pdCgpDQorew0KKwl1
bnNpZ25lZCBpbnQgbWF4X2lycSwgaTsNCisJdW5zaWduZWQgaW50IGNwdSA9IHNtcF9wcm9jZXNz
b3JfaWQoKTsNCisJdW5zaWduZWQgbG9uZyBjcHVtYXNrID0gMSA8PCBjcHU7DQorDQorCWZvciAo
aSA9IDA7IGkgPCBBUlJBWV9TSVpFKHRlZ3JhX2lycV9jdHJsKTsgaSsrKSB7DQorCQl0ZWdyYV9p
cnFfY3RybFtpXS5pcnFfc3RhcnQgPSBJTlRfUFJJX0JBU0UgKyBJTlRfU1lTX1NaICogaTsNCisJ
CXRlZ3JhX2lycV9jdHJsW2ldLnJlZyA9IElPX0FERFJFU1MoSU5UX1BQSV9BRERSRVNTKGkpKTsN
CisJCW1taW9fd3JpdGVsKDB4RkZGRkZGRkYsIHRlZ3JhX2lycV9jdHJsW2ldLnJlZyArIElDVExS
X0NQVV9JRVJfQ0xSXzApOw0KKwkJbW1pb193cml0ZWwoMHgwMDAwMDAwMCwgdGVncmFfaXJxX2N0
cmxbaV0ucmVnICsgSUNUTFJfQ1BVX0lFUF9DTEFTU18wKTsNCisJfQ0KKw0KKwlmb3IgKGkgPSBJ
TlRfUFJJX0JBU0U7IGkgPCBJTlRfR1BJT19CQVNFOyBpKyspIHsNCisJCWlycV9kZXNjW2ldLmhh
bmRsZXIgPSAmdGVncmFfaXJxX2NvbnRyb2xsZXI7DQorCX0NCisNCisJY3B1bWFzayB8PSBjcHVt
YXNrIDw8IDg7DQorCWNwdW1hc2sgfD0gY3B1bWFzayA8PCAxNjsNCisNCisJdGVncmFfZ2ljX2Rp
c3RfYmFzZSA9IElPX0FERFJFU1MoVEVHUkFfQVJNX0lOVF9ESVNUX0JBU0UpOw0KKwl0ZWdyYV9n
aWNfY3B1X2Jhc2VbY3B1XSA9IElPX0FERFJFU1MoVEVHUkFfR0lDX1BST0NfSUZfQkFTRSk7DQor
DQorCW1taW9fd3JpdGVsKDAsIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNERENSKTsNCisJDQor
ICAgICAgICAvKg0KKyAgICAgICAgICogRmluZCBvdXQgaG93IG1hbnkgaW50ZXJydXB0cyBhcmUg
c3VwcG9ydGVkLg0KKyAgICAgICAgICovDQorICAgICAgICBtYXhfaXJxID0gbW1pb19yZWFkbCh0
ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDVFIpICYgMHgxZjsNCisgICAgICAgIG1heF9pcnEg
PSAobWF4X2lycSArIDEpICogMzI7DQorDQorICAgICAgICAvKg0KKyAgICAgICAgICogVGhlIEdJ
QyBvbmx5IHN1cHBvcnRzIHVwIHRvIDEwMjAgaW50ZXJydXB0IHNvdXJjZXMuDQorICAgICAgICAg
KiBMaW1pdCB0aGlzIHRvIGVpdGhlciB0aGUgYXJjaGl0ZWN0ZWQgbWF4aW11bSwgb3IgdGhlDQor
ICAgICAgICAgKiBwbGF0Zm9ybSBtYXhpbXVtLg0KKyAgICAgICAgICovDQorICAgICAgICBpZiAo
bWF4X2lycSA+IG1heCgxMDIwLCBOUl9JUlFTKSkNCisgICAgICAgICAgICAgICAgbWF4X2lycSA9
IG1heCgxMDIwLCBOUl9JUlFTKTsNCisNCisgICAgICAgIC8qDQorICAgICAgICAgKiBTZXQgYWxs
IGdsb2JhbCBpbnRlcnJ1cHRzIHRvIGJlIGxldmVsIHRyaWdnZXJlZCwgYWN0aXZlIGxvdy4NCisg
ICAgICAgICAqLw0KKyAgICAgICAgZm9yIChpID0gMzI7IGkgPCBtYXhfaXJxOyBpICs9IDE2KQ0K
KyAgICAgICAgICAgICAgICBtbWlvX3dyaXRlbCgwLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lD
RElDRlIgKyBpICogNCAvIDE2KTsNCisNCisgICAgICAgIC8qDQorICAgICAgICAgKiBTZXQgYWxs
IGdsb2JhbCBpbnRlcnJ1cHRzIHRvIHRoaXMgQ1BVIG9ubHkuDQorICAgICAgICAgKi8NCisgICAg
ICAgIGZvciAoaSA9IDMyOyBpIDwgbWF4X2lycTsgaSArPSA0KQ0KKyAgICAgICAgICAgICAgICBt
bWlvX3dyaXRlbChjcHVtYXNrLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElQVFIgKyBpICog
NCAvIDQpOw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFNldCBwcmlvcml0eSBvbiBhbGwgaW50
ZXJydXB0cy4NCisgICAgICAgICAqLw0KKyAgICAgICAgZm9yIChpID0gMDsgaSA8IG1heF9pcnE7
IGkgKz0gNCkNCisgICAgICAgICAgICAgICAgbW1pb193cml0ZWwoMHhhMGEwYTBhMCwgdGVncmFf
Z2ljX2Rpc3RfYmFzZSArIF9JQ0RJUFIgKyBpICogNCAvIDQpOw0KKw0KKyAgICAgICAgLyoNCisg
ICAgICAgICAqIERpc2FibGUgYWxsIGludGVycnVwdHMuDQorICAgICAgICAgKi8NCisgICAgICAg
IGZvciAoaSA9IDA7IGkgPCBtYXhfaXJxOyBpICs9IDMyKQ0KKyAgICAgICAgICAgICAgICBtbWlv
X3dyaXRlbCgweGZmZmZmZmZmLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDRVIgKyBpICog
NCAvIDMyKTsNCisNCisgICAgICAgIG1taW9fd3JpdGVsKDEsIHRlZ3JhX2dpY19kaXN0X2Jhc2Ug
KyBfSUNERENSKTsNCisNCisgICAgICAgIG1taW9fd3JpdGVsKDB4ZjAsIHRlZ3JhX2dpY19jcHVf
YmFzZVtjcHVdICsgX0lDQ1BNUik7DQorICAgICAgICBtbWlvX3dyaXRlbCgxLCB0ZWdyYV9naWNf
Y3B1X2Jhc2VbY3B1XSArIF9JQ0NJQ1IpOw0KKw0KKw0KK30NCisNCisjZGVmaW5lIENMS19SU1Rf
Q09OVFJPTExFUl9SU1RfQ1BVX0NNUExYX0NMUl8wICAoMHgzNDQpDQorI2RlZmluZSBDTEtfUlNU
X0NPTlRST0xMRVJfQ0xLX0NQVV9DTVBMWF8wICAgICAgKDB4NGMpDQorI2RlZmluZSBDUFVfQ0xL
X1NUT1AoY3B1KSAgICAgICAgICAgICAgICAgICAgICAgKDB4MTw8KDgrY3B1KSkNCisjZGVmaW5l
IENQVV9SRVNFVChjcHUpICAgICAgICAgICAgICAgICAgICAgICAgICAoMHgxMDExdWw8PChjcHUp
KQ0KKw0KKyNkZWZpbmUgRVZQX0NQVV9SRVNFVF9WRUNUT1JfMCAgICAgICAgICAJKDB4MTAwKQ0K
KyNkZWZpbmUgRkxPV19DVFJMX0hBTFRfQ1BVeF9FVkVOVFMoY3B1KSAJKChjcHUpID8gKChjcHUg
LSAxKSAqIDB4OCArIDB4MTQpIDogMHgwKQ0KKw0KKw0KK3ZvbGF0aWxlIGludCB0ZWdyYTI1MF9j
b3JlX21hcCA9IDE7DQorDQorYXNtKA0KKyIudHlwZSB0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQs
ICNmdW5jdGlvbglcbiINCisiLmdsb2JhbCB0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQJCVxuIg0K
KyJ0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQ6CQkJXG4iDQorIgltc3IJY3Bzcl9jLCAjMHhEMwkJ
CVxuIg0KKyIJbW92CXIwLCAjMAkJCQlcbiINCisiCW1jcglwMTUsIDIsIHIwLCBjMCwgYzAsIDAJ
CVxuIg0KKyIJbXJjCXAxNSwgMSwgcjAsIGMwLCBjMCwgMAkJXG4iDQorIglsZHIJcjEsID0weDdG
RkYJCQlcbiINCisiCWFuZAlyMiwgcjEsIHIwLCBsc3IgIzEzCQlcbiINCisiCWxkcglyMSwgPTB4
M0ZGCQkJXG4iDQorIglhbmQJcjMsIHIxLCByMCwgbHNyICMzCQlcbiINCisiCWFkZAlyMiwgcjIs
ICMxCQkJXG4iDQorIglhbmQJcjAsIHIwLCAjMHgwNwkJCVxuIg0KKyIJYWRkCXIwLCByMCwgIzQJ
CQlcbiINCisiCWNseglyMSwgcjMJCQkJXG4iDQorIglhZGQJcjQsIHIzLCAjMQkJCVxuIg0KKyIx
OglzdWIJcjIsIHIyLCAjMQkJCVxuIg0KKyIJbW92CXIzLCByNAkJCQlcbiINCisiMjoJc3Vicwly
MywgcjMsICMxCQkJXG4iDQorIgltb3YJcjUsIHIzLCBsc2wgcjEJCQlcbiINCisiCW1vdglyNiwg
cjIsIGxzbCByMAkJCVxuIg0KKyIJb3JyCXI1LCByNSwgcjYJCQlcbiINCisiCW1jcglwMTUsIDAs
IHI1LCBjNywgYzYsIDIJCVxuIg0KKyIJYmd0CTJiCQkJCVxuIg0KKyIJY21wCXIyLCAjMAkJCQlc
biINCisiCWJndAkxYgkJCQlcbiINCisiCWRzYgkJCQkJXG4iDQorIglpc2IJCQkJCVxuIg0KKyIJ
bXJjCXAxNSwgMCwgcjAsIGMwLCBjMCwgNQkJXG4iDQorIglhbmQJcjAsIHIwLCAjMTUJCQlcbiIN
CisiCWFkcglyNCwgMWYJCQkJXG4iDQorIglsZG1pYQlyNCwge3I1LCByNn0JCQlcbiINCisiCXN1
YglyNCwgcjQsIHI1CQkJXG4iDQorIglhZGQJcjYsIHI2LCByNAkJCVxuIg0KKyIJbW92CXIxLCAj
MQkJCQlcbiINCisiCWxzbAlyMSwgcjEsIHIwCQkJXG4iDQorInNwaW46CWxkcglyNywgW3I2XQkJ
CVxuIg0KKyIJdHN0CXI3LCByMQkJCQlcbiINCisiCWJlcQlzcGluCQkJCVxuIg0KKyIJYglzbGF2
ZV9jcHVfc3RhcnQJCQlcbiINCisiMToJLmxvbmcJLgkJCQlcbiINCisiCS5sb25nCXRlZ3JhMjUw
X2NvcmVfbWFwCQlcbiINCispOw0KKw0KK2ludCB3YWtldXBfY3B1KHVuc2lnbmVkIGludCBjcHUp
DQorew0KKwl0ZWdyYTI1MF9jb3JlX21hcCB8PSAxIDw8ICBjcHU7DQorDQorCWNwdV9mbHVzaF9j
YWNoZV9hbGwoKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK2V4dGVybiB2b2lkIHRlZ3JhMjUw
X3NsYXZlX2NwdV9zdGFydCh2b2lkKTsNCisNCitzdGF0aWMgdm9pZCB0ZWdyYTI1MF9ldnBfaW5p
dCh2b2lkKQ0KK3sNCisJdW5zaWduZWQgbG9uZyByLCBvcmcsIGxvb3AsIGN0cmw7DQorDQorCS8q
IEluaXRpYWxpemUgU25vb3AgQ29udHJvbCBVbml0ICovDQorCWN0cmwgPSBtbWlvX3JlYWRsKElP
X0FERFJFU1MoVEVHUkFfU0NVX0JBU0UpICsgMHgwKTsNCisJY3RybCB8PSAxOw0KKwltbWlvX3dy
aXRlbChjdHJsLCBJT19BRERSRVNTKFRFR1JBX1NDVV9CQVNFKSArIDB4MCk7DQorDQorCW9yZyA9
IG1taW9fcmVhZGwoSU9fQUREUkVTUyhURUdSQV9FWENFUFRJT05fVkVDVE9SU19CQVNFKSArIEVW
UF9DUFVfUkVTRVRfVkVDVE9SXzApOw0KKw0KKwkvKiBTZXQgYm9vdCBlbnRyeSAqLw0KKwltbWlv
X3dyaXRlbChfX3BhKHRlZ3JhMjUwX3NsYXZlX2NwdV9zdGFydCksIElPX0FERFJFU1MoVEVHUkFf
RVhDRVBUSU9OX1ZFQ1RPUlNfQkFTRSkgKyBFVlBfQ1BVX1JFU0VUX1ZFQ1RPUl8wKTsNCisNCisJ
ZHNiKCk7DQorCWlzYigpOw0KKw0KKwkvKiBIYWx0IENQVSAqLw0KKwltbWlvX3dyaXRlbCgwLCBJ
T19BRERSRVNTKFRFR1JBX0ZMT1dfQ1RSTF9CQVNFKSArIEZMT1dfQ1RSTF9IQUxUX0NQVXhfRVZF
TlRTKDEpKTsNCisNCisJZHNiKCk7DQorCWlzYigpOw0KKw0KKwkvKiBDUFUgQ2xvY2sgU3RvcCAq
Lw0KKwlyID0gbW1pb19yZWFkbChJT19BRERSRVNTKFRFR1JBX0NMS19SRVNFVF9CQVNFKSArIENM
S19SU1RfQ09OVFJPTExFUl9DTEtfQ1BVX0NNUExYXzApOw0KKwlyICY9IH5DUFVfQ0xLX1NUT1Ao
MSk7DQorCW1taW9fd3JpdGVsKHIsIElPX0FERFJFU1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpICsg
Q0xLX1JTVF9DT05UUk9MTEVSX0NMS19DUFVfQ01QTFhfMCk7DQorDQorCWRzYigpOw0KKwlpc2Io
KTsNCisNCisJLyogUmVzdGFydCBTbGF2ZSBDUFUgKi8NCisJbW1pb193cml0ZWwoQ1BVX1JFU0VU
KDEpLCBJT19BRERSRVNTKFRFR1JBX0NMS19SRVNFVF9CQVNFKSArIENMS19SU1RfQ09OVFJPTExF
Ul9SU1RfQ1BVX0NNUExYX0NMUl8wKTsNCisNCisJZHNiKCk7DQorCWlzYigpOw0KKw0KKyAgICAg
ICAgLyogV2FpdCB1dGlsIHRoZSBwb3dlciB1bml0IGlzIGluIHN0YWJsZSAqLw0KKyAgICAgICAg
bG9vcCA9IDEwMDAwOw0KKyAgICAgICAgd2hpbGUoKC0tbG9vcCkgPiAwICk7DQorfQ0KKw0KK3Zv
aWQgdGVncmEyNTBfaW9yZW1hcCh2b2lkKQ0KK3sNCisJbWFwX3BhZ2VzX3RvX3hlbihJT19BRERS
RVNTKFRFR1JBX0FSTV9DUFVfQkFTRSksDQorCQlURUdSQV9BUk1fQ1BVX0JBU0UgPj4gUEFHRV9T
SElGVCwgMHgxMDAwMDAgPj4gUEFHRV9TSElGVCwNCisJCUwxRV9UWVBFX0RFVklDRSk7DQorDQor
CW1hcF9wYWdlc190b194ZW4oSU9fQUREUkVTUyhURUdSQV9QUFNCX0RFVklDRV9CQVNFKSwNCisJ
CVRFR1JBX1BQU0JfREVWSUNFX0JBU0UgPj4gUEFHRV9TSElGVCwgMHgxMDAwMDAgPj4gUEFHRV9T
SElGVCwgDQorCQlMMUVfVFlQRV9ERVZJQ0UpOw0KKw0KKwltYXBfcGFnZXNfdG9feGVuKElPX0FE
RFJFU1MoVEVHUkFfQVBCX0RFVklDRV9CQVNFKSwNCisJCVRFR1JBX0FQQl9ERVZJQ0VfQkFTRSA+
PiBQQUdFX1NISUZULCAweDEwMDAwMCA+PiBQQUdFX1NISUZULA0KKwkJTDFFX1RZUEVfREVWSUNF
KTsNCit9DQorDQoraW50IG1hY2hpbmVfc2V0dXAodm9pZCkNCit7DQorCWNwdV90b3BvbG9neV9p
bml0KDIpOw0KKw0KKwl0ZWdyYTI1MF9pb3JlbWFwKCk7DQorDQorCXRlZ3JhMjUwX2V2cF9pbml0
KCk7DQorDQorCXRlZ3JhMjUwX2lycV9pbml0KCk7DQorDQorCXRlZ3JhMjUwX3RpbWVyX2luaXQo
KTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gv
YXJtL3RlZ3JhL3RpbWVyLmMNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvdGltZXIuYwlTdW4gRmViIDEyIDE1OjA0
OjA2IDIwMTIgKzA5MDANCkBAIC0wLDAgKzEsMTEwIEBADQorLyoNCisgKiBhcmNoL2FybS9tYWNo
LXRlZ3JhL3RpbWVyLmMNCisgKg0KKyAqIFRpbWVyIGFuZCBjbG9jayBldmVudCBzdXBwb3J0IGZv
ciBOVklESUEgVGVncmEgU29Dcw0KKyAqDQorICogQ29weXJpZ2h0IChjKSAyMDA4LTIwMDksIE5W
SURJQSBDb3Jwb3JhdGlvbi4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkN
CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRo
ZSBMaWNlbnNlLCBvcg0KKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uDQor
ICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3
aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZl
biB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3INCisgKiBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yDQorICogbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJl
Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYWxvbmcNCisg
KiB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uLCBJbmMuLA0KKyAqIDUxIEZyYW5rbGluIFN0cmVldCwgRmlmdGggRmxvb3IsIEJv
c3RvbiwgTUEgIDAyMTEwLTEzMDEsIFVTQS4NCisgKi8NCisNCisjaW5jbHVkZSA8eGVuL3NjaGVk
Lmg+DQorI2luY2x1ZGUgPHhlbi9pcnEuaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisjaW5j
bHVkZSA8eGVuL3NvZnRpcnEuaD4NCisjaW5jbHVkZSA8eGVuL3NwaW5sb2NrLmg+DQorI2luY2x1
ZGUgPGFzbS90aW1lLmg+DQorI2luY2x1ZGUgPGFzbS9hcmNoL2lycXMuaD4NCisjaW5jbHVkZSA8
YXNtL2FyY2gvdGVncmEuaD4NCisNCisNCisjZGVmaW5lIENMS19SU1RfQ09OVFJPTExFUl9PU0Nf
Q1RSTF8wCTB4NTANCisNCisjZGVmaW5lIFRJTUVSMV9PRkZTCQkJMHgwMCAgLyogcmVzZXJ2ZWQg
Zm9yIEFWUCAqLw0KKyNkZWZpbmUgVElNRVIyX09GRlMJCQkweDA4ICAvKiByZXNlcnZlZCBmb3Ig
QVZQICovDQorI2RlZmluZSBUSU1FUjNfT0ZGUwkJCTB4NTAgIC8qIHVzZWQgYXMgT1MgQ1BVIGV2
ZW50IHRpbWVyICovDQorI2RlZmluZSBUSU1FUjRfT0ZGUwkJCTB4NTggIC8qIHJlc2VydmVkIGFz
IExQMiB3YWtldXAgdHJpZ2dlciAqLw0KKw0KKyNkZWZpbmUgVElNRVJfVE1SX1BUVl8wCQkJMHgw
DQorI2RlZmluZSBUSU1FUl9UTVJfUENSXzAJCQkweDQNCisNCisjZGVmaW5lIFRJTUVSVVNfT0ZG
UwkJCTB4MTANCisjZGVmaW5lIFRJTUVSVVNfQ05UUl8xVVNfMAkJMHgwDQorI2RlZmluZSBUSU1F
UlVTX1VTRUNfQ0ZHXzAJCTB4NA0KKw0KKyNkZWZpbmUgTlNFQ19QRVJfU0VDCQkJMTAwMDAwMDAw
MEwNCisNCit2b2lkIHRlZ3JhX2Nsb2NrZXZlbnRfaW50ZXJydXB0KGludCBpcnEsIHZvaWQgKmRl
dl9pZCwgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQorew0KKyAgICAgICAgbW1pb193cml0
ZWwoMSA8PCAzMCwgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBUSU1FUjNfT0ZGUykgKyBU
SU1FUl9UTVJfUENSXzApOw0KK30NCisNCitzdGF0aWMgc3RydWN0IGlycWFjdGlvbiB0ZWdyYV9j
bG9ja2V2ZW50X2lycSA9IHsNCisgICAgICAgIC5uYW1lICAgICAgICAgICA9ICJUaW1lcl9ldmVu
dCIsDQorICAgICAgICAuaGFuZGxlciAgICAgICAgPSB0ZWdyYV9jbG9ja2V2ZW50X2ludGVycnVw
dCwNCit9Ow0KKw0KK3ZvaWQgdGVncmFfbHAyd2FrZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAq
ZGV2X2lkLCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCit7DQorICAgICAgICBtbWlvX3dy
aXRlbCgxPDwzMCwgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBUSU1FUjRfT0ZGUykgKyBU
SU1FUl9UTVJfUENSXzApOw0KK30NCisNCitzdGF0aWMgc3RydWN0IGlycWFjdGlvbiB0ZWdyYV9s
cDJ3YWtlX2lycSA9IHsNCisgICAgICAgIC5uYW1lICAgICAgICAgICA9ICJ0aW1lcl9scDJ3YWtl
IiwNCisgICAgICAgIC5oYW5kbGVyICAgICAgICA9IHRlZ3JhX2xwMndha2VfaW50ZXJydXB0LA0K
K307DQorDQorc3RhdGljIHVuc2lnbmVkIGxvbmcgbWVhc3VyZV9pbnB1dF9mcmVxKHVuc2lnbmVk
IGludCAqbSwgdW5zaWduZWQgaW50ICpuKQ0KK3sNCisJdm9pZCAqY2xrX3JzdCA9IElPX0FERFJF
U1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpOw0KKwl1bnNpZ25lZCBsb25nIG9zYyA9IG1taW9fcmVh
ZGwoY2xrX3JzdCArIENMS19SU1RfQ09OVFJPTExFUl9PU0NfQ1RSTF8wKTsNCisJb3NjID4+PSAz
MDsNCisNCisJc3dpdGNoIChvc2MpIHsNCisJCWNhc2UgMDogaWYgKG0gJiYgbikgeyAqbT0xOyAq
bj0xMzsgfSByZXR1cm4gMTMwMDA7DQorCQljYXNlIDE6IGlmIChtICYmIG4pIHsgKm09NTsgKm49
OTY7IH0gcmV0dXJuIDE5MjAwOw0KKwkJY2FzZSAyOiBpZiAobSAmJiBuKSB7ICptPTE7ICpuPTEy
OyB9IHJldHVybiAxMjAwMDsNCisJCWNhc2UgMzogaWYgKG0gJiYgbikgeyAqbT0xOyAqbj0yNjsg
fSByZXR1cm4gMjYwMDA7DQorCX0NCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KK3ZvaWQgdGVncmEy
NTBfdGltZXJfaW5pdCh2b2lkKQ0KK3sNCisgICAgICAgIHZvaWQgKnRtcjsNCisgICAgICAgIHVu
c2lnbmVkIGludCBtLCBuOw0KKyAgICAgICAgdW5zaWduZWQgbG9uZyB2YWw7DQorICAgICAgICB1
MzIgcmVnOw0KKw0KKyAgICAgICAgdG1yID0gSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBU
SU1FUlVTX09GRlMpOw0KKyAgICAgICAgdmFsID0gbWVhc3VyZV9pbnB1dF9mcmVxKCZtLCAmbik7
DQorDQorICAgICAgICB2YWwgPSAoKG0tMSk8PDgpIHwgKG4tMSk7DQorDQorICAgICAgICBtbWlv
X3dyaXRlbCh2YWwsIHRtciArIFRJTUVSVVNfVVNFQ19DRkdfMCk7DQorICAgICAgICBtbWlvX3dy
aXRlbCgwLCBJT19BRERSRVNTKFRFR1JBX1RNUjFfQkFTRSArIFRJTUVSM19PRkZTKSAgKyBUSU1F
Ul9UTVJfUFRWXzApOw0KKw0KKyAgICAgICAgcmVnID0gMHhjMDAwMjcwZjsNCisgICAgICAgIG1t
aW9fd3JpdGVsKHJlZywgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JBU0UgKyBUSU1FUjNfT0ZGUykg
KyBUSU1FUl9UTVJfUFRWXzApOw0KKw0KKyAgICAgICAgaWYgKHNldHVwX2lycShJTlRfVE1SMywg
JnRlZ3JhX2Nsb2NrZXZlbnRfaXJxKSkgew0KKyAgICAgICAgICAgICAgICBCVUcoKTsNCisgICAg
ICAgIH0NCisgICAgICAgIGlmIChzZXR1cF9pcnEoSU5UX1RNUjQsICZ0ZWdyYV9scDJ3YWtlX2ly
cSkpIHsNCisgICAgICAgICAgICAgICAgQlVHKCk7DQorICAgICAgICB9DQorfQ0KKw0KZGlmZiAt
ciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3hlbi9jcHUuYw0KLS0tIGEveGVuL2FyY2gvYXJt
L3hlbi9jcHUuYwlTdW4gRmViIDEyIDEyOjI0OjIxIDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNo
L2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtNTMsNiAr
NTMsMTEgQEAgaW50IF9fY3B1X3VwKHVuc2lnbmVkIGludCBjcHUpDQogew0KIAlpbnQgcmV0ID0g
MDsNCiANCisJcmV0ID0gd2FrZXVwX2NwdShjcHUpOw0KKwlpZiAoIXJldCkgew0KKwkJcmV0dXJu
IC1FSU5WQUw7DQorCX0NCisNCiAJd2hpbGUoIWNwdV9vbmxpbmUoY3B1KSkgew0KIAkJY3B1X3Jl
bGF4KCk7DQogCQlwcm9jZXNzX3BlbmRpbmdfc29mdGlycXMoKTsNCmRpZmYgLXIgNmFmOGE4OWM5
OWNkIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9mYXVs
dC5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9mYXVsdC5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTMzLDcgKzMzLDYg
QEANCiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPg0KICNpbmNsdWRlIDxhc20vZ3Vlc3RfYWNj
ZXNzLmg+DQogI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCi0jaW5jbHVkZSA8YXNtL21lbW9yeS5o
Pg0KIA0KIGFzbWxpbmthZ2Ugdm9pZCBfX2RpdjAodm9pZCkNCiB7DQpkaWZmIC1yIDZhZjhhODlj
OTljZCB4ZW4vYXJjaC9hcm0veGVuL2lycS5jDQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2lycS5j
CVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9p
cnEuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC0zOCw5ICszOCwyNyBAQCBo
d19pcnFfY29udHJvbGxlciBub19pcnFfdHlwZSA9IHsNCiAJLnNodXRkb3duID0gaXJxX3NodXRk
b3duX25vbmUsDQogCS5lbmFibGUgICA9IGlycV9lbmFibGVfbm9uZSwNCiAJLmRpc2FibGUgID0g
aXJxX2Rpc2FibGVfbm9uZSwNCisJLmVuZAkgID0gaXJxX2VuZF9ub25lLA0KKwkuYWNrCSAgPSBp
cnFfYWNrX25vbmUsDQogfTsNCiANCi1zdHJ1Y3QgaXJxX2Rlc2MgKmlycV9kZXNjOw0KKy8vc3Ry
dWN0IGlycV9kZXNjICppcnFfZGVzYzsNCisNCitpcnFfZGVzY190IGlycV9kZXNjW05SX0lSUVNd
ID0gew0KKyAgICAgICAgWzAgLi4uIE5SX0lSUVMgLSAxXSA9IHsNCisgICAgICAgICAgICAgICAg
LnN0YXR1cyA9IElSUV9ESVNBQkxFRCwNCisgICAgICAgICAgICAgICAgLmhhbmRsZXIgPSAmbm9f
aXJxX3R5cGUsDQorICAgICAgICAgICAgICAgIC5hY3Rpb24gPSBOVUxMLA0KKyAgICAgICAgICAg
ICAgICAubG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRA0KKyAgICAgICAgfQ0KK307DQorDQorc3Ry
dWN0IGlycV9jZmcgaXJxX2NmZ1tOUl9JUlFTXSA9IHsNCisgICAgICAgIFswIC4uLiBOUl9JUlFT
IC0gMV0gPXsNCisgICAgICAgICAgICAgICAgLmlycSA9IDANCisgICAgICAgIH0NCit9Ow0KKw0K
IA0KIGludCBwaXJxX2d1ZXN0X3VubWFzayhzdHJ1Y3QgZG9tYWluICpkKQ0KIHsNCkBAIC03NSw2
ICs5MywzMiBAQCBzdHJ1Y3QgcGlycSAqYWxsb2NfcGlycV9zdHJ1Y3Qoc3RydWN0IGRvDQogCXJl
dHVybiBOVUxMOw0KIH0NCiANCitpbnQgc2V0dXBfaXJxKHVuc2lnbmVkIGludCBpcnEsIHN0cnVj
dCBpcnFhY3Rpb24gKm5ldykNCit7DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQorCXN0cnVjdCBp
cnFfZGVzYyAqZGVzYzsNCisNCisJaWYoaXJxID49IE5SX0lSUVMpIHsNCisJCXByaW50aygiQkFE
IElSUSA9ICVkXG4iLCBpcnEpOw0KKwl9DQorDQorCWRlc2MgPSBpcnFfdG9fZGVzYyhpcnEpOw0K
Kw0KKwlzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3MpOw0KKwlkZXNjLT5hY3Rp
b24gPSBuZXc7DQorCWlmIChkZXNjLT5oYW5kbGVyKSB7DQorCQlpZiAoZGVzYy0+aGFuZGxlci0+
c3RhcnR1cCkgew0KKwkJCWRlc2MtPmhhbmRsZXItPnN0YXJ0dXAoZGVzYyk7DQorCQl9IGVsc2Ug
aWYoZGVzYy0+aGFuZGxlci0+ZW5hYmxlKSB7DQorCQkJZGVzYy0+aGFuZGxlci0+ZW5hYmxlKGRl
c2MpOw0KKwkJfQ0KKwl9DQorDQorCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ss
IGZsYWdzKTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0KIGludCBhcmNoX2luaXRfb25lX2lycV9k
ZXNjKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQogCU5PVF9ZRVQoKTsNCmRpZmYgLXIgNmFm
OGE4OWM5OWNkIHhlbi9hcmNoL2FybS94ZW4vbW0uYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9t
bS5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9tbS5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTI1NSwzICsyNTUsMjcg
QEAgaW50IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcgdmlydCwgdQ0KIAlyZXR1cm4gMDsN
CiB9DQogDQoraW50IG1hcF9wYWdlc190b194ZW4odW5zaWduZWQgbG9uZyB2aXJ0LCB1bnNpZ25l
ZCBsb25nIG1mbiwgaW50IG5yLCB1bnNpZ25lZCBsb25nIGZsYWdzKQ0KK3sNCisgICAgICAgIHVu
c2lnbmVkIGxvbmcgdmFkZHIgPSByb3VuZF9kb3duKHZpcnQsIFBBR0VfU0laRSk7DQorICAgICAg
ICB1bnNpZ25lZCBsb25nIG1hZGRyID0gbWZuIDw8IFBBR0VfU0hJRlQ7DQorICAgICAgICB1bnNp
Z25lZCBpbnQgZW5kID0gdmlydCArIChuciA8PCBQQUdFX1NISUZUKTsNCisNCisgICAgICAgIGwx
ZV90ICpsMWUgPSBsMV9saW5lYXJfb2Zmc2V0X3hlbih2YWRkcik7DQorDQorICAgICAgICBkbyB7
DQorICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgbGltaXQgPSAodmFkZHIgKyBTRUNUSU9O
X1NJWkUpICYgKFNFQ1RJT05fTUFTSyk7DQorICAgICAgICAgICAgICAgIGxpbWl0ID0gKGxpbWl0
IDwgZW5kKSA/IGxpbWl0IDogZW5kOw0KKw0KKyAgICAgICAgICAgICAgICBpZiAoKCh2YWRkciB8
IG1hZGRyIHwgbGltaXQpICYgflNFQ1RJT05fTUFTSykgPT0gMCkgew0KKyAgICAgICAgICAgICAg
ICAgICAgICAgICpsMWUgPSBNS19MMUUobWFkZHIsIGZsYWdzKTsNCisgICAgICAgICAgICAgICAg
ICAgICAgICBwdGVfc3luYyhsMWUpOw0KKw0KKyAgICAgICAgICAgICAgICAgICAgICAgIHZhZGRy
ICs9IFNFQ1RJT05fU0laRTsNCisgICAgICAgICAgICAgICAgICAgICAgICBtYWRkciArPSBTRUNU
SU9OX1NJWkU7DQorICAgICAgICAgICAgICAgIH0NCisgICAgICAgIH0gd2hpbGUobDFlKyssIHZh
ZGRyIDwgZW5kKTsNCisNCisgICAgICAgIHJldHVybiAwOw0KK30NCisNCmRpZmYgLXIgNmFmOGE4
OWM5OWNkIHhlbi9hcmNoL2FybS94ZW4vc2V0dXAuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9z
ZXR1cC5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJt
L3hlbi9zZXR1cC5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTY0LDExICs2
NCwxMSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IGRvbTBfc2l6ZSA9IDI1NiAqIDEwDQogaW50ZWdl
cl9wYXJhbSgiZG9tMF9zaXplIiwgZG9tMF9zaXplKTsNCiANCiAvL3N0YXRpYyB1bnNpZ25lZCBs
b25nIGRvbTBfaW1hZ2Vfc3RhcnQgPSAweDQwQjAwMDAwVUw7DQotc3RhdGljIHVuc2lnbmVkIGxv
bmcgZG9tMF9pbWFnZV9zdGFydCA9IDB4MDBCMDAwMDBVTDsNCitzdGF0aWMgdW5zaWduZWQgbG9u
ZyBkb20wX2ltYWdlX3N0YXJ0ID0gMHhBMDAwMDBVTDsNCiBpbnRlZ2VyX3BhcmFtKCJpbWFnZV9z
dGFydCIsIGRvbTBfaW1hZ2Vfc3RhcnQpOw0KIA0KIC8vc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9t
MF9pbWFnZV9zaXplID0gMHhBMDAwMDBVTDsNCi1zdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2lt
YWdlX3NpemUgPSAweEEwMDAwMFVMOw0KK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c2l6ZSA9IDB4MTQwMDAwMFVMOw0KIGludGVnZXJfcGFyYW0oImltYWdlX2xlbmd0aCIsIGRvbTBf
aW1hZ2Vfc2l6ZSk7DQogDQogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVz
X2luZm9fdCAqaW5mbykNCkBAIC0yMTEsNiArMjExLDggQEAgYXNtbGlua2FnZSB2b2lkIHN0YXJ0
X3hlbih2b2lkKQ0KIA0KIAl0YXNrbGV0X3N1YnN5c19pbml0KCk7DQogDQorCW1hY2hpbmVfc2V0
dXAoKTsNCisNCiAJdGltZXJfaW5pdCgpOw0KIA0KIAlpZGxlX2RvbWFpbl9pbml0KCk7DQpkaWZm
IC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0veGVuL3RpbWUuYw0KLS0tIGEveGVuL2FyY2gv
YXJtL3hlbi90aW1lLmMJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3RpbWUuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC03
OSw1ICs3OSw0IEBAIHZvaWQgZG9tYWluX3NldF90aW1lX29mZnNldChzdHJ1Y3QgZG9tYWkNCiAN
CiB2b2lkIHRpbWVrZWVwaW5nX2luaXQodm9pZCkNCiB7DQotCU5PVF9ZRVQoKTsNCiB9DQpkaWZm
IC1yIDZhZjhhODljOTljZCB4ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYw0KLS0tIGEveGVuL2Ry
aXZlcnMvY2hhci9jb25zb2xlLmMJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysg
Yi94ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDANCkBAIC00MTIsNyArNDEyLDExIEBAIGxvbmcgZG9fY29uc29sZV9pbyhpbnQgY21kLCBpbnQg
Y291bnQsIFgNCiAgKiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KICAqLw0KIA0KKyNpZiBkZWZpbmVkKF9fYXJtX18pDQorc3RhdGljIGJvb2xf
dCBjb25zb2xlX2xvY2tzX2J1c3RlZCA9IDE7DQorI2Vsc2UNCiBzdGF0aWMgYm9vbF90IGNvbnNv
bGVfbG9ja3NfYnVzdGVkOw0KKyNlbmRpZg0KIA0KIHN0YXRpYyB2b2lkIF9fcHV0c3RyKGNvbnN0
IGNoYXIgKnN0cikNCiB7DQpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJt
L2dpYy5oDQotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysr
IGIveGVuL2luY2x1ZGUvYXNtLWFybS9naWMuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDANCkBAIC0wLDAgKzEsMTAxIEBADQorLyoNCisgKiBnaWMuaA0KKyAqDQorICogQ29weXJpZ2h0
IChDKSAyMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBKYWVtaW4gUnl1ICA8
am03Ny5yeXVAc2Ftc3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0
d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAqIGl0IHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNl
IGFzDQorICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uDQorICoN
CisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxs
IGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJlY2Vp
dmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisgKiBhbG9uZyB3
aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KKyAq
IEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1B
ICAwMjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisjaWZuZGVmIF9fQVJNX0dJQ19IX18NCisjZGVm
aW5lIF9fQVJNX0dJQ19IX18NCisNCisNCisvKiBEaXN0cmlidXRvciBSZWdpc3RlciBNYXAgKi8N
CisjZGVmaW5lIF9JQ0REQ1IJCTB4MDAwICAvKiBEaXN0cmlidXRvciBDb250cm9sIFJlZ2lzdGVy
ICovDQorI2RlZmluZSBfSUNESUNUUgkweDAwNCAgLyogSW50ZXJydXB0IENvbnRyb2xsZXIgVHlw
ZSBSZWdpc3RlciAqLw0KKyNkZWZpbmUgX0lDRElJRFIJMHgwMDggIC8qIERpc3RyaWJ1dG9yIElt
cGxlbWVudGVyIElkIFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMAkweDA4MCAgLyogSW50
ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMQkweDA4NCAgLyog
SW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMgkweDA4OCAg
LyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSMwkweDA4
YyAgLyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNSNAkw
eDA5MCAgLyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNESVNF
UgkweDEwMCAgLyogSW50ZXJydXB0IFNldC1FbmFibGUgUmVnaXN0ZXIgKi8NCisjZGVmaW5lIF9J
Q0RJQ0VSCTB4MTgwICAvKiBJbnRlcnJ1cHQgQ2xlYXItRW5hYmxlIFJlZ2lzdGVyICovDQorI2Rl
ZmluZSBfSUNESVNQUgkweDIwMCAgLyogSW50ZXJydXB0IFNldC1QZW5kaW5nIFJlZ2lzdGVyICov
DQorI2RlZmluZSBfSUNESUNQUgkweDI4MCAgLyogSW50ZXJydXB0IENsZWFyLVBlbmRpbmcgUmVn
aXN0ZXIgKi8NCisjZGVmaW5lIF9JQ0RBQlIJCTB4MzAwICAvKiBBY3RpdmUgQml0IFJlZ2lzdGVy
cyAqLw0KKyNkZWZpbmUgX0lDRElQUgkJMHg0MDAgIC8qIEludGVycnVwdCBQcmlvcml0eSBSZWdp
c3RlciAqLw0KKyNkZWZpbmUgX0lDRElQVFIJMHg4MDAgIC8qIEludGVycnVwdCBQcm9jZXNzb3Ig
VGFyZ2V0cyBSZWdpc3RlcnMgKi8NCisjZGVmaW5lIF9JQ0RJQ0ZSCTB4QzAwICAvKiBJbnRlcnJ1
cHQgQ29uZmlndXJhdGlvbiBSZWdpc3RlcnMgKi8NCisjZGVmaW5lIF9JQ0RTR0lSCTB4RjAwICAv
KiBTb2Z0d2FyZSBHZW5lcmF0ZWQgSW50ZXJydXB0IFJlZ2lzdGVyICovDQorDQorI2RlZmluZSBJ
Q0REQ1IoKQkoX0lDRERDUikNCisjZGVmaW5lIElDRElDVFIoKQkoX0lDRElDVFIpDQorI2RlZmlu
ZSBJQ0RJU1IoeCkJKF9JQ0RJU1IwICsgKHggLyBCSVRTX1BFUl9MT05HKSAqIEJZVEVTX1BFUl9M
T05HKQ0KKyNkZWZpbmUgSUNESVNFUih4KQkoX0lDRElTRVIgKyAoeCAvIEJJVFNfUEVSX0xPTkcp
ICogQllURVNfUEVSX0xPTkcpDQorI2RlZmluZSBJQ0RJQ0VSKHgpCShfSUNESUNFUiArICh4IC8g
QklUU19QRVJfTE9ORykgKiBCWVRFU19QRVJfTE9ORykNCisjZGVmaW5lIElDRElTUFIoeCkJKF9J
Q0RJU1BSICsgKHggLyBCSVRTX1BFUl9MT05HKSAqIEJZVEVTX1BFUl9MT05HKQ0KKyNkZWZpbmUg
SUNESUNQUih4KQkoX0lDRElDUFIgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xP
TkcpDQorI2RlZmluZSBJQ0RBQlIoeCkJKF9JQ0RBQlIgICsgKHggLyBCSVRTX1BFUl9MT05HKSAq
IEJZVEVTX1BFUl9MT05HKQ0KKyNkZWZpbmUgSUNESVBSKHgpCShfSUNESVBSICArICh4IC8gIDQp
ICogQllURVNfUEVSX0xPTkcpDQorI2RlZmluZSBJQ0RJUFRSKHgpCShfSUNESVBUUiArICh4IC8g
IDQpICogQllURVNfUEVSX0xPTkcpDQorI2RlZmluZSBJQ0RTR0lSKCkJKF9JQ0RTR0lSKQ0KKw0K
Ky8qIENQVSBJbnRlcmZhY2UgUmVnaXN0ZXIgTWFwICovDQorI2RlZmluZSBfSUNDSUNSCQkweDAw
MCAgLyogQ1BVIEludGVyZmFjZSBDb250cm9sIFJlZ2lzdGVyICovDQorI2RlZmluZSBfSUNDUE1S
CQkweDAwNCAgLyogSW50ZXJydXB0IFByaW9yaXR5IE1hc2sgUmVnaXN0ZXIgKi8NCisjZGVmaW5l
IF9JQ0NCUFIJCTB4MDA4ICAvKiBCaW5yYXJ5IFBvaW50IFJlZ2lzdGVyICovDQorI2RlZmluZSBf
SUNDSUFSCQkweDAwQyAgLyogSW50ZXJydXB0IEFja25vd2xlZGdlIFJlZ2lzdGVyICovDQorI2Rl
ZmluZSBfSUNDRU9JUgkweDAxMCAgLyogRW5kIG9mIEludGVycnVwdCBSZWdpc3RlciAqLw0KKyNk
ZWZpbmUgX0lDQ1JQUgkJMHgwMTQgIC8qIFJ1bm5pbmcgUHJpb3JpdHkgUmVnaXN0ZXIgKi8NCisj
ZGVmaW5lIF9JQ0NIUElSCTB4MDE4ICAvKiBIaWdoZXN0IFBlbmRpbmcgSW50ZXJydXB0IFJlZ2lz
dGVyICovDQorI2RlZmluZSBfSUNDQUJQUgkweDAxQyAgLyogQWxpYXNlZCBCaW5hcnkgUG9pbnQg
UmVnaXN0ZXIgKi8NCisjZGVmaW5lIF9JQ0NJSURSCTB4MEZDICAvKiBDUFUgSW50ZXJmYWNlIElk
IFJlZ2lzdGVyICovDQorDQorI2RlZmluZSBJQ0NJQ1IoKQkoX0lDQ0lDUikNCisjZGVmaW5lIElD
Q1BNUigpCShfSUNDUE1SKQ0KKyNkZWZpbmUgSUNDQlBSKCkJKF9JQ0NCUFIpDQorI2RlZmluZSBJ
Q0NJQVIoKQkoX0lDQ0lBUikNCisjZGVmaW5lIElDQ0VPSVIoKQkoX0lDQ0VPSVIpDQorI2RlZmlu
ZSBJQ0NSUFIoKQkoX0lDQ1JQUikNCisjZGVmaW5lIElDQ0hQSVIoKQkoX0lDQ0hQSVIpDQorI2Rl
ZmluZSBJQ0NJSURSKCkJKF9JQ0NJSURSKQ0KKw0KKyNkZWZpbmUgU0VDVVJFX0lOVEVSUlVQVAkw
DQorI2RlZmluZSBOT05TRUNVUkVfSU5URVJSVVBUCTENCisNCisjZGVmaW5lIFNHSSh4KQkJCSh4
KQ0KKyNkZWZpbmUgUFBJKHgpCQkJKHggKyAxNikNCisjZGVmaW5lIFNQSSh4KQkJCSh4ICsgMzIp
DQorDQorI2lmbmRlZiBfX0FTU0VNQkxZX18NCisNCisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+DQor
DQorI2RlZmluZSBHSUNfRElTVFJJQlVUT1IoeCkgICAgICAoX2dpY19kaXN0cmlidXRvcl9iYXNl
ICsgeCkNCisjZGVmaW5lIEdJQ19DUFVfSU5URVJGQUNFKHgpICAgIChfZ2ljX2NwdV9iYXNlICsg
eCkNCisNCit2b2lkIGdpY19zZXRfY3B1KHVuc2lnbmVkIGludCBpcnEsIHVuc2lnbmVkIGludCBt
YXNrKTsNCit2b2lkIGdpY19zZXRfaXJxX3ByaW9yaXR5KHVuc2lnbmVkIGludCBpcnEsIHVuc2ln
bmVkIGludCBwcmlvcml0eSk7DQordm9pZCBnaWNfYWNrX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsN
Cit2b2lkIGdpY19tYXNrX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsNCit2b2lkIGdpY191bm1hc2tf
aXJxKHVuc2lnbmVkIGludCBpcnEpOw0KK3ZvaWQgZ2ljX2VuZF9pcnEodW5zaWduZWQgaW50IGly
cSk7DQordm9pZCBnaWNfY2hhbmdlX2lycV9zdGF0ZSh1bnNpZ25lZCBpbnQgaXJxLCB1bnNpZ25l
ZCBpbnQgc3RhdGUpOw0KKw0KK2V4dGVybiB2b2lkICpfZ2ljX2NwdV9iYXNlW05SX0NQVVNdOw0K
K2V4dGVybiB2b2lkICpfZ2ljX2Rpc3RyaWJ1dG9yX2Jhc2U7DQorI2VuZGlmDQorI2VuZGlmDQpk
aWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJtL2lycS5oDQotLS0gYS94ZW4v
aW5jbHVkZS9hc20tYXJtL2lycS5oCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMA0KKysr
IGIveGVuL2luY2x1ZGUvYXNtLWFybS9pcnEuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDANCkBAIC0xNSw2ICsxNSw3IEBADQogDQogI2RlZmluZSBpcnFfY2ZnKGlycSkJCSgmaXJxX2Nm
Z1tpcnFdKQ0KICNkZWZpbmUgaXJxX3RvX2Rlc2MoaXJxKQkoJmlycV9kZXNjW2lycV0pCQ0KKyNk
ZWZpbmUgZGVzY190b19pcnEoZGVzYykJKChkZXNjIC0gJmlycV9kZXNjWzBdKSAvIHNpemVvZihz
dHJ1Y3QgaXJxX2Rlc2MpKTsNCiANCiAjZGVmaW5lIElSUV9NQVhfR1VFU1RTCQk3DQogdHlwZWRl
ZiBzdHJ1Y3Qgew0KQEAgLTQwLDggKzQxLDYgQEAgdHlwZWRlZiBzdHJ1Y3Qgew0KICAgICBERUNM
QVJFX0JJVE1BUChfYml0cyxOUl9JUlFTKTsNCiB9IHZtYXNrX3Q7DQogDQotZXh0ZXJuIHN0cnVj
dCBpcnFfZGVzYyAqaXJxX2Rlc2M7DQotDQogc3RhdGljIGlubGluZSBpbnQgaXJxX2Rlc2NfaW5p
dGlhbGl6ZWQoc3RydWN0IGlycV9kZXNjICpkZXNjKQ0KIHsNCiAJcmV0dXJuIDA7DQpkaWZmIC1y
IDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2F2cC5oDQotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNt
LWFybS90ZWdyYS9hdnAuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDANCkBAIC0wLDAg
KzEsMTQ0IEBADQorLyoNCisgKiBDb3B5cmlnaHQgKGMpIDIwMTAgTlZJRElBIENvcnBvcmF0aW9u
Lg0KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQorICoNCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQg
dXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQNCisgKiBtb2Rp
ZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnMgYXJlIG1ldDoNCisgKg0KKyAqIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt
dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSwNCisgKiB0aGlzIGxpc3Qgb2Yg
Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLg0KKyAqDQorICogUmVkaXN0
cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmln
aHQgbm90aWNlLA0KKyAqIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n
IGRpc2NsYWltZXIgaW4gdGhlIGRvY3VtZW50YXRpb24NCisgKiBhbmQvb3Igb3RoZXIgbWF0ZXJp
YWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4NCisgKg0KKyAqIE5laXRoZXIgdGhl
IG5hbWUgb2YgdGhlIE5WSURJQSBDb3Jwb3JhdGlvbiBub3IgdGhlIG5hbWVzIG9mIGl0cyBjb250
cmlidXRvcnMNCisgKiBtYXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMg
ZGVyaXZlZCBmcm9tIHRoaXMgc29mdHdhcmUNCisgKiB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdy
aXR0ZW4gcGVybWlzc2lvbi4NCisgKg0KKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkg
VEhFIENPUFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTIElTIg0KKyAqIEFORCBB
TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J
VEVEIFRPLCBUSEUNCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO
RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQ0KKyAqIEFSRSBESVNDTEFJTUVELiBJ
TiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIEhPTERFUiBPUiBDT05UUklCVVRPUlMgQkUN
CisgKiBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFM
LCBFWEVNUExBUlksIE9SDQorICogQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJV
VCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YNCisgKiBTVUJTVElUVVRFIEdPT0RTIE9S
IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MNCisg
KiBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJ
TElUWSwgV0hFVEhFUiBJTg0KKyAqIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JU
IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpDQorICogQVJJU0lORyBJTiBBTlkg
V0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU
SEUNCisgKiBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4NCisgKg0KKyAqLw0KKw0KKyNpZm5k
ZWYgSU5DTFVERURfQVZQX0gNCisjZGVmaW5lIElOQ0xVREVEX0FWUF9IDQorDQorI2luY2x1ZGUg
ImFwMTUvYXJpY3Rsci5oIg0KKyNpbmNsdWRlICJhcDE1L2FydGltZXIuaCINCisvLyBGSVhNRTog
Z2V0IHRoZSBhcmFybWV2IGhlYWRlcg0KKw0KKy8vIDMgY29udHJvbGxlcnMgaW4gY29udGlndW91
cyBtZW1vcnkgc3RhcnRpbmcgYXQgSU5URVJSVVBUX0JBU0UsIGVhY2gNCisvLyBjb250cm9sbGVy
J3MgYXBlcnR1cmUgaXMgSU5URVJSVVBUX1NJWkUgbGFyZ2UNCisjZGVmaW5lIElOVEVSUlVQVF9C
QVNFIDB4NjAwMDQwMDANCisjZGVmaW5lIElOVEVSUlVQVF9TSVpFIDB4MTAwDQorI2RlZmluZSBJ
TlRFUlJVUFRfTlVNX0NPTlRST0xMRVJTIDMNCisNCisjZGVmaW5lIElOVEVSUlVQVF9QRU5ESU5H
KCBjdGxyICkgXA0KKyAgICAoSU5URVJSVVBUX0JBU0UgKyAoKGN0bHIpICogSU5URVJSVVBUX1NJ
WkUpICsgSUNUTFJfVklSUV9DT1BfMCkNCisNCisjZGVmaW5lIElOVEVSUlVQVF9TRVQoIGN0bHIg
KSBcDQorICAgIChJTlRFUlJVUFRfQkFTRSArICgoY3RscikgKiBJTlRFUlJVUFRfU0laRSkgKyBJ
Q1RMUl9DT1BfSUVSX1NFVF8wKQ0KKw0KKyNkZWZpbmUgSU5URVJSVVBUX0NMUiggY3RsciApIFwN
CisgICAgKElOVEVSUlVQVF9CQVNFICsgKChjdGxyKSAqIElOVEVSUlVQVF9TSVpFKSArIElDVExS
X0NPUF9JRVJfQ0xSXzApDQorDQorI2RlZmluZSBPU0NfQ1RSTCAgICAgICAgKCAweDYwMDA2MDAw
ICsgMHg1MCApDQorI2RlZmluZSBPU0NfRlJFUV9ERVQgICAgKCAweDYwMDA2MDAwICsgMHg1OCAp
DQorI2RlZmluZSBPU0NfREVUX1NUQVRVUyAgKCAweDYwMDA2MDAwICsgMHg1QyApDQorDQorI2Rl
ZmluZSBUSU1FUl9VU0VDICAgICAgKCAweDYwMDA1MDEwICkNCisjZGVmaW5lIFRJTUVSX0NGRyAg
ICAgICAoIDB4NjAwMDUwMTQgKQ0KKyNkZWZpbmUgVElNRVJfMF9CQVNFICAgICggMHg2MDAwNTAw
MCApDQorI2RlZmluZSBUSU1FUl8wICAgICAgICAgKCBUSU1FUl8wX0JBU0UgKyBUSU1FUl9UTVJf
UFRWXzAgKQ0KKyNkZWZpbmUgVElNRVJfMF9DTEVBUiAgICggVElNRVJfMF9CQVNFICsgVElNRVJf
VE1SX1BDUl8wICkNCisjZGVmaW5lIFRJTUVSXzFfQkFTRSAgICAoIDB4NjAwMDUwMDggKQ0KKyNk
ZWZpbmUgVElNRVJfMSAgICAgICAgICggVElNRVJfMV9CQVNFICsgVElNRVJfVE1SX1BUVl8wICkN
CisjZGVmaW5lIFRJTUVSXzFfQ0xFQVIgICAoIFRJTUVSXzFfQkFTRSArIFRJTUVSX1RNUl9QQ1Jf
MCApDQorDQorI2RlZmluZSBDTE9DS19SU1RfTE8gICAgKDB4NjAwMDYwMDQpDQorI2RlZmluZSBD
TE9DS19DVExSX0hJICAgKDB4NjAwMDYwMTQpDQorI2RlZmluZSBDTE9DS19DVExSX0xPICAgKDB4
NjAwMDYwMTApDQorDQorI2RlZmluZSBDQUNIRV9DVExSICAgICAgKDB4NjAwMEMwMDApDQorI2Rl
ZmluZSBDQUNIRV9DT05UUk9MXzAgICAgICAgICAoMHgwKQ0KKw0KKyNkZWZpbmUgUFBJX0lOVFJf
SURfVElNRVJfMCAgICAgKDApDQorI2RlZmluZSBQUElfSU5UUl9JRF9USU1FUl8xICAgICAoMSkN
CisjZGVmaW5lIFBQSV9JTlRSX0lEX1RJTUVSXzIgICAgICg5KQ0KKyNkZWZpbmUgUFBJX0lOVFJf
SURfVElNRVJfMyAgICAgKDEwKQ0KKw0KKy8qIGZsb3cgY29udHJvbGxlciAqLw0KKyNkZWZpbmUg
RkxPV19DT05UUk9MTEVSICAgICAoMHg2MDAwNzAwNCkNCisNCisvKiBleGNlcHRpb24gdmVjdG9y
cyAqLw0KKyNkZWZpbmUgVkVDVE9SX0JBU0UgICAgICAgICAgICAgKCAweDYwMDBGMjAwICkNCisj
ZGVmaW5lIFZFQ1RPUl9SRVNFVCAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyAwICkNCisjZGVm
aW5lIFZFQ1RPUl9VTkRFRiAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyA0ICkNCisjZGVmaW5l
IFZFQ1RPUl9TV0kgICAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyA4ICkNCisjZGVmaW5lIFZF
Q1RPUl9QUkVGRVRDSF9BQk9SVCAgICggVkVDVE9SX0JBU0UgKyAxMiApDQorI2RlZmluZSBWRUNU
T1JfREFUQV9BQk9SVCAgICAgICAoIFZFQ1RPUl9CQVNFICsgMTYgKQ0KKyNkZWZpbmUgVkVDVE9S
X0lSUSAgICAgICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDI0ICkNCisjZGVmaW5lIFZFQ1RPUl9G
SVEgICAgICAgICAgICAgICggVkVDVE9SX0JBU0UgKyAyOCApDQorDQorI2RlZmluZSBNT0RFX0RJ
U0FCTEVfSU5UUiAweGMwDQorI2RlZmluZSBNT0RFX1VTUiAweDEwDQorI2RlZmluZSBNT0RFX0ZJ
USAweDExDQorI2RlZmluZSBNT0RFX0lSUSAweDEyDQorI2RlZmluZSBNT0RFX1NWQyAweDEzDQor
I2RlZmluZSBNT0RFX0FCVCAweDE3DQorI2RlZmluZSBNT0RFX1VORCAweDFCDQorI2RlZmluZSBN
T0RFX1NZUyAweDFGDQorDQorI2RlZmluZSBBUDE1X0NBQ0hFX0xJTkVfU0laRSAgICAgICAgICAg
IDMyDQorDQorI2RlZmluZSBBUDE1X0FQQl9MMl9DQUNIRV9CQVNFIDB4NzAwMGU4MDAgDQorI2Rl
ZmluZSBBUDE1X0FQQl9DTEtfUlNUX0JBU0UgIDB4NjAwMDYwMDANCisjZGVmaW5lIEFQMTVfQVBC
X01JU0NfQkFTRSAgICAgMHg3MDAwMDAwMA0KKw0KKyNkZWZpbmUgQVAxMF9BUEJfQ0xLX1JTVF9C
QVNFICAweDYwMDA2MDAwDQorI2RlZmluZSBBUDEwX0FQQl9NSVNDX0JBU0UgICAgIDB4NzAwMDAw
MDANCisNCisjZGVmaW5lIE1NVV9UTEJfQkFTRSAgICAgICAgICAgICAgMHhmMDAwZjAwMA0KKyNk
ZWZpbmUgTU1VX1RMQl9DQUNIRV9XSU5ET1dfMCAgICAweDQwDQorI2RlZmluZSBNTVVfVExCX0NB
Q0hFX09QVElPTlNfMCAgIDB4NDQNCisNCisjZGVmaW5lIEFQMTVfUElOTVVYX0NGR19DVExfMCAg
IDB4NzAwMDAwMjQNCisjZGVmaW5lIEFQMTVfQVZQX0pUQUdfRU5BQkxFICAgIDB4QzANCisNCisj
ZGVmaW5lIFBNQ19TQ1JBVENIMjJfUkVHX0xQMCAgIDB4NzAwMGU0YTgNCisNCisjZGVmaW5lIEFW
UF9XRFRfUkVTRVQgICAweDJGMDBCQUQwDQorDQorLyogQ2FjaGVkIHRvIHVuY2FjaGVkIG9mZnNl
dCBmb3IgQVZQDQorICoNCisgKiBIYXJkd2FyZSBoYXMgdW5jYWNoZWQgcmVtYXAgYXBlcnR1cmUg
Zm9yIEFWUCBhcyBBVlAgZG9lc24ndCBoYXZlIE1NVQ0KKyAqIGJ1dCBzdGlsbCBoYXMgY2FjaGUg
KG5hbWVkIENPUCBjYWNoZSkuDQorICoNCisgKiBUaGlzIGFwZXJ0dXJlIG1vdmVkIGJldHdlZW4g
QVAxNSBhbmQgQVAyMC4NCisgKi8NCisjZGVmaW5lIEFQMTVfQ0FDSEVEX1RPX1VOQ0FDSEVEX09G
RlNFVCAweDkwMDAwMDAwDQorI2RlZmluZSBBUDIwX0NBQ0hFRF9UT19VTkNBQ0hFRF9PRkZTRVQg
MHg4MDAwMDAwMA0KKw0KKyNkZWZpbmUgQVBYWF9FWFRfTUVNX1NUQVJUICAgICAgMHgwMDAwMDAw
MA0KKyNkZWZpbmUgQVBYWF9FWFRfTUVNX0VORCAgICAgICAgMHg0MDAwMDAwMA0KKw0KKyNkZWZp
bmUgQVBYWF9NTUlPX1NUQVJUICAgICAgICAgMHg0MDAwMDAwMA0KKyNkZWZpbmUgQVBYWF9NTUlP
X0VORCAgICAgICAgICAgMHhGRkYwMDAwMA0KKw0KKyNkZWZpbmUgVFhYX0VYVF9NRU1fU1RBUlQg
ICAgICAgMHg4MDAwMDAwMA0KKyNkZWZpbmUgVFhYX0VYVF9NRU1fRU5EICAgICAgICAgMHhjMDAw
MDAwMA0KKw0KKyNkZWZpbmUgVFhYX01NSU9fU1RBUlQgICAgICAgICAgMHg0MDAwMDAwMA0KKyNk
ZWZpbmUgVFhYX01NSU9fRU5EICAgICAgICAgICAgMHg4MDAwMDAwMA0KKw0KKyNlbmRpZg0KZGlm
ZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS9jb25maWcuaA0KLS0t
IGEveGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS9jb25maWcuaAlTdW4gRmViIDEyIDEyOjI0OjIx
IDIwMTIgKzA5MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvY29uZmlnLmgJU3Vu
IEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtMSwxMSArMSw2IEBADQogI2lmbmRlZiBf
X1RFR1JBX0NPTkZJR19IX18NCiAjZGVmaW5lIF9fVEVHUkFfQ09ORklHX0hfXw0KIA0KLSNkZWZp
bmUgSFoJMTAwDQotI2RlZmluZSBDTE9DS19USUNLX1JBVEUJCTEwMDAwMDANCisjZGVmaW5lIE1B
WF9QSFlTX0NQVVMJMg0KIA0KLSNkZWZpbmUgTUFYX1BIWVNfQ1BVUwkJMg0KLQ0KLSNkZWZpbmUg
QlVJTFRJTl9DT01NQU5EX0xJTkVfU0laRSAyNTYNCi0jZGVmaW5lIEJVSUxUSU5fQ09NTUFORF9M
SU5FCSIiDQogI2VuZGlmDQpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20tYXJt
L3RlZ3JhL2lycXMuaA0KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvaXJxcy5oCVN1biBGZWIgMTIgMTU6
MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw2MCBAQA0KKy8qDQorICogYXJjaC9hcm0vbWFj
aC10ZWdyYS9pbmNsdWRlL21hY2gvaXJxcy5oDQorICoNCisgKiBDb3B5cmlnaHQgKGMpIDIwMDks
IE5WSURJQSBDb3Jwb3JhdGlvbi4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3
YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIg
dGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg
YnkNCisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9m
IHRoZSBMaWNlbnNlLCBvcg0KKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24u
DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBp
dCB3aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3INCisgKiBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UgZm9yDQorICogbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYWxvbmcN
CisgKiB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uLCBJbmMuLA0KKyAqIDUxIEZyYW5rbGluIFN0cmVldCwgRmlmdGggRmxvb3Is
IEJvc3RvbiwgTUEgIDAyMTEwLTEzMDEsIFVTQS4NCisgKi8NCisNCisjaWZuZGVmIF9fVEVHUkFf
SVJRU19IDQorI2RlZmluZSBfX1RFR1JBX0lSUVNfSA0KKw0KKyNkZWZpbmUgTlJfSVJRUwkJCTUx
Mg0KKw0KKyNkZWZpbmUgSU5UX1BSSV9CQVNFCQkzMg0KKyNkZWZpbmUgSU5UX1JUQwkJCShJTlRf
UFJJX0JBU0UgKyAyKQ0KKyNkZWZpbmUgSU5UX1VTQgkJCShJTlRfUFJJX0JBU0UgKyAyMCkNCisj
ZGVmaW5lIElOVF9VU0IyCQkoSU5UX1BSSV9CQVNFICsgMjEpDQorI2RlZmluZSBJTlRfQVBCX0RN
QQkJKElOVF9QUklfQkFTRSArIDI2KQ0KKw0KKyNkZWZpbmUgSU5UX1NFQ19CQVNFCQkoSU5UX1BS
SV9CQVNFICsgMzIpDQorI2RlZmluZSBJTlRfR1BJTzEJCShJTlRfU0VDX0JBU0UgKyAwKQ0KKyNk
ZWZpbmUgSU5UX0dQSU8yCQkoSU5UX1NFQ19CQVNFICsgMSkNCisjZGVmaW5lIElOVF9HUElPMwkJ
KElOVF9TRUNfQkFTRSArIDIpDQorI2RlZmluZSBJTlRfR1BJTzQJCShJTlRfU0VDX0JBU0UgKyAz
KQ0KKyNkZWZpbmUgSU5UX1RNUjMJCShJTlRfU0VDX0JBU0UgKyA5KQ0KKyNkZWZpbmUgSU5UX1RN
UjQJCShJTlRfU0VDX0JBU0UgKyAxMCkNCisjZGVmaW5lIElOVF9TWVNfU1RBVFNfTU9OCShJTlRf
U0VDX0JBU0UgKyAyMikNCisjZGVmaW5lIElOVF9HUElPNQkJKElOVF9TRUNfQkFTRSArIDIzKQ0K
Kw0KKyNkZWZpbmUgSU5UX1RSSV9CQVNFCQkoSU5UX1NFQ19CQVNFICsgMzIpDQorI2RlZmluZSBJ
TlRfS0JDCQkJKElOVF9UUklfQkFTRSArIDIxKQ0KKyNkZWZpbmUgSU5UX0VYVEVSTkFMX1BNVQko
SU5UX1RSSV9CQVNFICsgMjIpDQorI2RlZmluZSBJTlRfR1BJTzYJCShJTlRfVFJJX0JBU0UgKyAy
MykNCisjZGVmaW5lIElOVF9HUElPNwkJKElOVF9UUklfQkFTRSArIDI1KQ0KKw0KKyNkZWZpbmUg
SU5UX1FVQURfQkFTRQkJKElOVF9UUklfQkFTRSArIDMyKQ0KKyNkZWZpbmUgSU5UX1VTQjMJCShJ
TlRfUVVBRF9CQVNFICsgMSkNCisNCisjZGVmaW5lIElOVF9HUElPX0JBU0UJCShJTlRfUVVBRF9C
QVNFICsgMzIpDQorI2RlZmluZSBJTlRfR1BJT19OUgkJKDI4KjgpDQorDQorI2RlZmluZSBJTlRf
QVBCRE1BX0JBU0UJIAkoSU5UX0dQSU9fQkFTRSArIElOVF9HUElPX05SKQ0KKyNkZWZpbmUgSU5U
X0FQQkRNQV9OUgkJKDE2KQ0KKw0KKyNkZWZpbmUgSU5UX1NZU19OUgkoSU5UX0dQSU9fQkFTRSAt
IElOVF9QUklfQkFTRSkNCisjZGVmaW5lIElOVF9TWVNfU1oJKElOVF9TRUNfQkFTRSAtIElOVF9Q
UklfQkFTRSkNCisNCisjZW5kaWYNCmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vdGVncmEvc21wLmgNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwDQorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL3NtcC5oCVN1biBGZWIgMTIg
MTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw3IEBADQorI2lmbmRlZiBBU01BUk1fQVJD
SF9TTVBfSA0KKyNkZWZpbmUgQVNNQVJNX0FSQ0hfU01QX0gNCisNCisNCisjaW5jbHVkZSA8YXNt
L2dpYy5oPg0KKw0KKyNlbmRpZg0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUvYXNt
LWFybS90ZWdyYS90ZWdyYS5oDQotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS90ZWdyYS5oCVN1biBGZWIg
MTIgMTU6MDQ6MDYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw3NSBAQA0KKyNpZm5kZWYgX19URUdS
QTI1MF9IX18NCisjZGVmaW5lIF9fVEVHUkEyNTBfSF9fDQorDQorI2RlZmluZSBURUdSQV9BUk1f
Q1BVX0JBU0UJCTB4NTAwMDAwMDANCisjZGVmaW5lIFRFR1JBX1BQU0JfREVWSUNFX0JBU0UJCTB4
NjAwMDAwMDANCisjZGVmaW5lIFRFR1JBX0FQQl9ERVZJQ0VfQkFTRQkJMHg3MDAwMDAwMA0KKw0K
KyNkZWZpbmUgVEVHUkFfQVJNX1BFUklGX0JBU0UJCTB4NTAwNDAwMDANCisjZGVmaW5lIFRFR1JB
X0FSTV9QRVJJRl9TSVpFCQlTWl84Sw0KKw0KKyNkZWZpbmUgVEVHUkFfU0NVX0JBU0UJCQkweDUw
MDQwMDAwDQorI2RlZmluZSBURUdSQV9TQ1VfU0laRQkJCVNaXzI1Ng0KKw0KKyNkZWZpbmUgVEVH
UkFfR0lDX1BST0NfSUZfQkFTRQkJMHg1MDA0MDEwMA0KKyNkZWZpbmUgVEVHUkFfR0lDX1BST0Nf
SUZfU0laRQkJU1pfMjU2DQorDQorI2RlZmluZSBURUdSQV9BUk1fSU5UX0RJU1RfQkFTRQkJMHg1
MDA0MTAwMA0KKyNkZWZpbmUgVEVHUkFfQVJNX0lOVF9ESVNUX1NJWkUJCVNaXzRLDQorDQorI2Rl
ZmluZSBURUdSQV9QUklNQVJZX0lDVExSX0JBU0UJMHg2MDAwNDAwMA0KKyNkZWZpbmUgVEVHUkFf
UFJJTUFSWV9JQ1RMUl9TSVpFCVNaXzY0DQorDQorI2RlZmluZSBURUdSQV9TRUNPTkRBUllfSUNU
TFJfQkFTRQkweDYwMDA0MTAwDQorI2RlZmluZSBURUdSQV9TRUNPTkRBUllfSUNUTFJfU0laRQlT
Wl82NA0KKw0KKyNkZWZpbmUgVEVHUkFfVEVSVElBUllfSUNUTFJfQkFTRQkweDYwMDA0MjAwDQor
I2RlZmluZSBURUdSQV9URVJUSUFSWV9JQ1RMUl9TSVpFCVNaXzY0DQorDQorI2RlZmluZSBURUdS
QV9RVUFURVJOQVJZX0lDVExSX0JBU0UJMHg2MDAwNDMwMA0KKyNkZWZpbmUgVEVHUkFfUVVBVEVS
TkFSWV9JQ1RMUl9TSVpFCVNaXzY0DQorDQorI2RlZmluZSBURUdSQV9UTVIxX0JBU0UJCQkweDYw
MDA1MDAwDQorI2RlZmluZSBURUdSQV9UTVIxX1NJWkUJCQlTWl84DQorDQorI2RlZmluZSBURUdS
QV9UTVIyX0JBU0UJCQkweDYwMDA1MDA4DQorI2RlZmluZSBURUdSQV9UTVIyX1NJWkUJCQlTWl84
DQorDQorI2RlZmluZSBURUdSQV9UTVJVU19CQVNFCQkweDYwMDA1MDEwDQorI2RlZmluZSBURUdS
QV9UTVJVU19TSVpFCQlTWl82NA0KKw0KKyNkZWZpbmUgVEVHUkFfVE1SM19CQVNFCQkJMHg2MDAw
NTA1MA0KKyNkZWZpbmUgVEVHUkFfVE1SM19TSVpFCQkJU1pfOA0KKw0KKyNkZWZpbmUgVEVHUkFf
VE1SNF9CQVNFCQkJMHg2MDAwNTA1OA0KKyNkZWZpbmUgVEVHUkFfVE1SNF9TSVpFCQkJU1pfOA0K
Kw0KKyNkZWZpbmUgVEVHUkFfQ0xLX1JFU0VUX0JBU0UJCTB4NjAwMDYwMDANCisjZGVmaW5lIFRF
R1JBX0NMS19SRVNFVF9TSVpFCQlTWl80Sw0KKw0KKyNkZWZpbmUgVEVHUkFfRkxPV19DVFJMX0JB
U0UJCTB4NjAwMDcwMDANCisjZGVmaW5lIFRFR1JBX0ZMT1dfQ1RSTF9TSVpFCQkyMA0KKw0KKyNk
ZWZpbmUgVEVHUkFfR1BJT19CQVNFCQkJMHg2MDAwRDAwMA0KKyNkZWZpbmUgVEVHUkFfR1BJT19T
SVpFCQkJU1pfNEsNCisNCisjZGVmaW5lIFRFR1JBX0VYQ0VQVElPTl9WRUNUT1JTX0JBU0UgICAg
MHg2MDAwRjAwMA0KKyNkZWZpbmUgVEVHUkFfRVhDRVBUSU9OX1ZFQ1RPUlNfU0laRSAgICBTWl80
Sw0KKw0KKyNkZWZpbmUgSUNUTFJfQ1BVX0lFUl8wCQkJKDB4MjApDQorI2RlZmluZSBJQ1RMUl9D
UFVfSUVSX1NFVF8wCQkoMHgyNCkNCisjZGVmaW5lIElDVExSX0NQVV9JRVJfQ0xSXzAJCSgweDI4
KQ0KKyNkZWZpbmUgSUNUTFJfQ1BVX0lFUF9DTEFTU18wCQkoMHgyQykNCisjZGVmaW5lIElDVExS
X0NPUF9JRVJfMAkJCSgweDMwKQ0KKyNkZWZpbmUgSUNUTFJfQ09QX0lFUl9TRVRfMAkJKDB4MzQp
DQorI2RlZmluZSBJQ1RMUl9DT1BfSUVSX0NMUl8wCQkoMHgzOCkNCisjZGVmaW5lIElDVExSX0NP
UF9JRVBfQ0xBU1NfMAkJKDB4M0MpDQorDQorI2RlZmluZSBBUk1fUEVSSUZfQkFTRQkJCSgweDUw
MDQwMDAwKQ0KKw0KKy8vI2RlZmluZSBJT19BRERSRVNTKHgpCQkJKCgoKCh4KSAmIDB4NzAwMDAw
MDApID4+IDgpICsgKCgoeCkgJiAweDBGMDAwMDAwKSA+PiA0KSkgfCgoeCkgJiAweEZGRkZGKSB8
IDB4RkIwMDAwMDAgKQ0KKyNkZWZpbmUgSU9fQUREUkVTUyh4KQkJCSgoKCh4KSAmIDB4RjAwMDAw
MDApID4+IDgpIHwgKCh4KSAmIDB4RkZGRkYpIHwgKDB4RkIwMDAwMDAgKSkNCisjZGVmaW5lIElO
VF9QUElfQUREUkVTUyhfaW5zdCkJCSgweDYwMDA0MDAwICsgKDB4MTAwICogKF9pbnN0KSkpDQor
I2RlZmluZSBJTlRfQVBCRE1BX0FERFJFU1MJCSgweDYwMDBhMDAwKQ0KKw0KKyNlbmRpZg0KZGlm
ZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUveGVuL2lycS5oDQotLS0gYS94ZW4vaW5jbHVk
ZS94ZW4vaXJxLmgJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwDQorKysgYi94ZW4vaW5j
bHVkZS94ZW4vaXJxLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwDQpAQCAtOTUsNiAr
OTUsMTAgQEAgaW50IGFyY2hfaW5pdF9vbmVfaXJxX2Rlc2Moc3RydWN0IGlycV9kZQ0KIA0KICNk
ZWZpbmUgaXJxX2Rlc2NfaW5pdGlhbGl6ZWQoZGVzYykgKChkZXNjKS0+aGFuZGxlciAhPSBOVUxM
KQ0KIA0KKyNpZiBkZWZpbmVkKF9fYXJtX18pDQorZXh0ZXJuIGlycV9kZXNjX3QgaXJxX2Rlc2Nb
TlJfSVJRU107DQorI2VuZGlmDQorDQogI2lmIGRlZmluZWQoX19pYTY0X18pDQogZXh0ZXJuIGly
cV9kZXNjX3QgaXJxX2Rlc2NbTlJfVkVDVE9SU107DQogDQpAQCAtMTIxLDYgKzEyNSw4IEBAIGV4
dGVybiB2b2lkIGlycV9hY3Rvcl9ub25lKHN0cnVjdCBpcnFfZGUNCiAjZGVmaW5lIGlycV9zaHV0
ZG93bl9ub25lIGlycV9hY3Rvcl9ub25lDQogI2RlZmluZSBpcnFfZGlzYWJsZV9ub25lIGlycV9h
Y3Rvcl9ub25lDQogI2RlZmluZSBpcnFfZW5hYmxlX25vbmUgaXJxX2FjdG9yX25vbmUNCisjZGVm
aW5lIGlycV9hY2tfbm9uZQlpcnFfYWN0b3Jfbm9uZQ0KKyNkZWZpbmUgaXJxX2VuZF9ub25lCWly
cV9hY3Rvcl9ub25lDQogDQogc3RydWN0IGRvbWFpbjsNCiBzdHJ1Y3QgdmNwdTsNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch11.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch11.diff"


YXJtOiBhZGQgZmlsZXMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgVGVncmEy
IGhhcm1vbnkgYm9hcmQuCgogeGVuL2FyY2gvYXJtL3RlZ3JhL01ha2VmaWxlICAgICAgICB8
ICAgIDMgKy0KIHhlbi9hcmNoL2FybS90ZWdyYS9lbnRyeS5TICAgICAgICAgfCAgIDMzICsr
KysrKysrCiB4ZW4vYXJjaC9hcm0vdGVncmEvdGVncmEyNTAuYyAgICAgIHwgIDMzMCArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKwogeGVuL2FyY2gvYXJtL3RlZ3JhL3RpbWVyLmMg
ICAgICAgICB8ICAxMTAgKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9h
cm0veGVuL2NwdS5jICAgICAgICAgICAgIHwgICAgNSArCiB4ZW4vYXJjaC9hcm0veGVuL2Zh
dWx0LmMgICAgICAgICAgIHwgICAgMSAtCiB4ZW4vYXJjaC9hcm0veGVuL2lycS5jICAgICAg
ICAgICAgIHwgICA0NiArKysrKysrKysrKy0KIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAg
ICAgICAgICAgfCAgIDI0ICsrKysrKwogeGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jICAgICAg
ICAgICB8ICAgIDYgKy0KIHhlbi9hcmNoL2FybS94ZW4vdGltZS5jICAgICAgICAgICAgfCAg
ICAxIC0KIHhlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jICAgICAgICAgfCAgICA0ICsKIHhl
bi9pbmNsdWRlL2FzbS1hcm0vZ2ljLmggICAgICAgICAgfCAgMTAxICsrKysrKysrKysrKysr
KysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vaXJxLmggICAgICAgICAgfCAgICAz
ICstCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2F2cC5oICAgIHwgIDE0NCArKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVn
cmEvY29uZmlnLmggfCAgICA3ICstCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2lycXMu
aCAgIHwgICA2MCArKysrKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEv
c21wLmggICAgfCAgICA3ICsKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvdGVncmEuaCAg
fCAgIDc1ICsrKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUveGVuL2lycS5oICAgICAg
ICAgICAgICB8ICAgIDYgKwogMTkgZmlsZXMgY2hhbmdlZCwgOTUyIGluc2VydGlvbnMoKyks
IDE0IGRlbGV0aW9ucygtKQoKU2lnbmVkLW9mZi1ieTogSmFlbWluIFJ5dSA8am03Ny5yeXVA
c2Ftc3VuZy5jb20+CgpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0vdGVncmEv
TWFrZWZpbGUKLS0tIGEveGVuL2FyY2gvYXJtL3RlZ3JhL01ha2VmaWxlCVN1biBGZWIgMTIg
MTI6MjQ6MjEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvTWFrZWZpbGUJ
U3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwCkBAIC0xLDEgKzEsMiBAQAotb2JqLXkg
Kz0gZHVtbXkubworb2JqLXkgKz0gdGltZXIubyBlbnRyeS5vIHRlZ3JhMjUwLm8KKwpkaWZm
IC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0vdGVncmEvZW50cnkuUwotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0v
dGVncmEvZW50cnkuUwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAgLTAsMCAr
MSwzMyBAQAorLyoKKyAqIGVudHJ5LlMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDggU2Ft
c3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgSmFlTWluIFJ5dSAgPGptNzcucnl1QHNh
bXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBw
dWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICog
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi
ZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1Mg
Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUg
cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICog
YWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMw
LCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2Nv
bmZpZy5oPiAKKyNpbmxjdWRlIDxhc20vYXJjaC9pcnFzLmg+CisjaW5jbHVkZSA8YXNtL3Bh
Z2UuaD4KKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNy
b3MuaD4KKyNpbmNsdWRlIDxhc20vY3B1LWRvbWFpbi5oPgorI2luY2x1ZGUgPGFzbS9hc20t
b2Zmc2V0cy5oPgorCisJLmFsaWduCTUKKworRU5UUlkoYXJjaF9jb250ZXh0X3N3aXRjaCkK
Kwltb3YJcGMsIGxyCisKZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3RlZ3Jh
L3RlZ3JhMjUwLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMJU3VuIEZlYiAxMiAxNTow
NDowNiAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzMwIEBACisvKgorICogdGVncmEyNTAuYwor
ICoKKyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MgCisg
KiAgICAgICAgIEphZU1pbiBSeXUgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBT
ZWN1cmUgWGVuIG9uIEFSTSBhcmNoaXRlY3R1cmUgZGVzaWduZWQgYnkgU2FuZy1idW0gU3Vo
IGNvbnNpc3RzIG9mIAorICogWGVuIG9uIEFSTSBhbmQgdGhlIGFzc29jaWF0ZWQgYWNjZXNz
IGNvbnRyb2wuCisgKiAKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBw
dWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICog
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi
ZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1Mg
Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUg
cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICog
YWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMw
LCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2Nv
bmZpZy5oPgorI2luY2x1ZGUgPHhlbi9zcGlubG9jay5oPgorI2luY2x1ZGUgPHhlbi9saWIu
aD4KKyNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+Cisj
aW5jbHVkZSA8eGVuL3NtcC5oPgorI2luY2x1ZGUgPHhlbi9pcnEuaD4KKyNpbmNsdWRlIDx4
ZW4vbW0uaD4KKyNpbmNsdWRlIDxhc20vbW11Lmg+CisjaW5jbHVkZSA8YXNtL3BsYXRmb3Jt
Lmg+CisjaW5jbHVkZSA8YXNtL2dpYy5oPgorI2luY2x1ZGUgPGFzbS9yZWdzLmg+CisjaW5j
bHVkZSA8YXNtL2lvLmg+CisjaW5jbHVkZSA8YXNtL2ZsdXNodGxiLmg+CisjaW5jbHVkZSA8
YXNtL2FyY2gvdGVncmEuaD4KKyNpbmNsdWRlIDxhc20vYXJjaC9pcnFzLmg+CisKKyNkZWZp
bmUgVEVHUkEyNTBfTUVNT1JZX0JBU0UgICAgIDB4MDAwMDAwMDBVTAorI2RlZmluZSBURUdS
QTI1MF9NRU1PUllfU0laRSAgICAgMHg0MDAwMDAwMFVMCisKKyNkZWZpbmUgVEVHUkEyNTBf
REVWX0JBU0UgICAgICAgIDB4NTAwMDAwMDBVTAorI2RlZmluZSBURUdSQTI1MF9ERVZfU0la
RSAgICAgICAgMHgwMDMwMDAwMFVMCisKK0RFQ0xBUkVfTUVNT1JZX01BUCh0ZWdyYTI1MCkg
PSB7CisgICAgICAgIE1FTU1BUF9FTlRSWShURUdSQTI1MF9NRU1PUllfQkFTRSwgVEVHUkEy
NTBfTUVNT1JZX1NJWkUsIE1FTU9SWV9UWVBFX1JBTSwgTDFFX1RZUEVfSFlQRVJWSVNPUiks
CisgICAgICAgIE1FTU1BUF9FTlRSWShURUdSQTI1MF9ERVZfQkFTRSwgICAgVEVHUkEyNTBf
REVWX1NJWkUsICAgIE1FTU9SWV9UWVBFX0RFViwgTDFFX1RZUEVfREVWSUNFKQorfTsKKwor
Ly8gUmVnaXN0ZXIgQVBCRE1BX0lSUV9NQVNLX0NMUl8wCisjZGVmaW5lIEFQQkRNQV9JUlFf
U1RBX0NQVV8wCSgweDE0KQorI2RlZmluZSBBUEJETUFfSVJRX01BU0tfU0VUXzAJKDB4MjAp
CisjZGVmaW5lIEFQQkRNQV9JUlFfTUFTS19DTFJfMAkoMHgyNCkKKwordm9pZCAqdGVncmFf
Z2ljX2NwdV9iYXNlW01BWF9QSFlTX0NQVVNdICA9IHswLCAwfTsKK3ZvaWQgKnRlZ3JhX2dp
Y19kaXN0X2Jhc2UgPSAwOworCitzdHJ1Y3QgdGVncmFfaXJxX2N0cmwgeworCXVuc2lnbmVk
IGludCBpcnFfc3RhcnQ7CisJdm9pZCAgKnJlZzsKK307CisKK3N0YXRpYyBzdHJ1Y3QgdGVn
cmFfaXJxX2N0cmwgdGVncmFfaXJxX2N0cmxbKElOVF9TWVNfTlIgKyBJTlRfU1lTX1NaIC0g
MSkgLyBJTlRfU1lTX1NaXTsKKworI2RlZmluZSBnaWNfaXJxKGlycSkJKGlycSkKKworc3Rh
dGljIHZvaWQgdGVncmFfbWFzayhzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpCit7CisJc3RydWN0
IHRlZ3JhX2lycV9jdHJsICpjaGlwOworCXVuc2lnbmVkIGludCBpcnEgPSBkZXNjX3RvX2ly
cShkZXNjKTsKKwl1bnNpZ25lZCBpbnQgbWFzayA9IDEgPDwgKGlycSAlIDMyKTsKKworCW1t
aW9fd3JpdGVsKG1hc2ssIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNESUNFUiArIChnaWNf
aXJxKGlycSkgLyAzMikgKiA0KTsKKworCWlycSAtPSBJTlRfUFJJX0JBU0U7CisJY2hpcCA9
ICZ0ZWdyYV9pcnFfY3RybFtpcnEgLyBJTlRfU1lTX1NaXTsKKwltbWlvX3dyaXRlbCgxIDw8
IChpcnEgJiAzMSksIGNoaXAtPnJlZyArIElDVExSX0NQVV9JRVJfQ0xSXzApOworfQorCitz
dGF0aWMgdm9pZCB0ZWdyYV91bm1hc2soc3RydWN0IGlycV9kZXNjICpkZXNjKQoreworCXN0
cnVjdCB0ZWdyYV9pcnFfY3RybCAqY2hpcDsKKwl1bnNpZ25lZCBpbnQgaXJxID0gZGVzY190
b19pcnEoZGVzYyk7CisJdW5zaWduZWQgaW50IG1hc2sgPSAxIDw8IChpcnEgJSAzMik7CisK
KwltbWlvX3dyaXRlbChtYXNrLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElTRVIgKyAo
Z2ljX2lycShpcnEpIC8gMzIpICogNCk7CisKKwlpcnEgLT0gSU5UX1BSSV9CQVNFOworCWNo
aXAgPSAmdGVncmFfaXJxX2N0cmxbaXJxIC8gSU5UX1NZU19TWl07CisJbW1pb193cml0ZWwo
MSA8PCAoaXJxICYgMzEpLCBjaGlwLT5yZWcgKyBJQ1RMUl9DUFVfSUVSX1NFVF8wKTsKK30K
Kworc3RhdGljIHZvaWQgdGVncmFfYWNrKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykKK3sKKwl1
bnNpZ25lZCBpbnQgaXJxID0gZGVzY190b19pcnEoZGVzYyk7CisJdW5zaWduZWQgaW50IG1h
c2sgPSAxIDw8IChpcnEgJSAzMik7CisJdW5zaWduZWQgaW50IGNwdSA9IHNtcF9wcm9jZXNz
b3JfaWQoKTsKKworCXRlZ3JhX21hc2soZGVzYyk7CisKKyAgICAgICAgbW1pb193cml0ZWwo
bWFzaywgdGVncmFfZ2ljX2Rpc3RfYmFzZSArIF9JQ0RJQ0VSICsgKGdpY19pcnEoaXJxKSAv
IDMyKSAqIDQpOworICAgICAgICBtbWlvX3dyaXRlbChnaWNfaXJxKGlycSksIHRlZ3JhX2dp
Y19jcHVfYmFzZVtjcHVdICsgX0lDQ0VPSVIpOworfQorCitzdGF0aWMgdm9pZCB0ZWdyYV9l
bmQoc3RydWN0IGlycV9kZXNjICpkZXNjKQoreworCXRlZ3JhX3VubWFzayhkZXNjKTsKK30K
KworaHdfaXJxX2NvbnRyb2xsZXIgdGVncmFfaXJxX2NvbnRyb2xsZXIgPSB7CisJLnR5cGVu
YW1lID0gImxldmVsIiwKKwkuc3RhcnR1cCAgPSB0ZWdyYV91bm1hc2ssCisJLnNodXRkb3du
ID0gdGVncmFfbWFzaywKKwkuZW5hYmxlCSAgPSB0ZWdyYV91bm1hc2ssCisJLmRpc2FibGUg
ID0gdGVncmFfbWFzaywKKwkuYWNrCSAgPSB0ZWdyYV9hY2ssCisJLmVuZAkgID0gdGVncmFf
ZW5kLAorfTsKKworc3RhdGljIHZvaWQgdGVncmEyNTBfaXJxX2luaXQoKQoreworCXVuc2ln
bmVkIGludCBtYXhfaXJxLCBpOworCXVuc2lnbmVkIGludCBjcHUgPSBzbXBfcHJvY2Vzc29y
X2lkKCk7CisJdW5zaWduZWQgbG9uZyBjcHVtYXNrID0gMSA8PCBjcHU7CisKKwlmb3IgKGkg
PSAwOyBpIDwgQVJSQVlfU0laRSh0ZWdyYV9pcnFfY3RybCk7IGkrKykgeworCQl0ZWdyYV9p
cnFfY3RybFtpXS5pcnFfc3RhcnQgPSBJTlRfUFJJX0JBU0UgKyBJTlRfU1lTX1NaICogaTsK
KwkJdGVncmFfaXJxX2N0cmxbaV0ucmVnID0gSU9fQUREUkVTUyhJTlRfUFBJX0FERFJFU1Mo
aSkpOworCQltbWlvX3dyaXRlbCgweEZGRkZGRkZGLCB0ZWdyYV9pcnFfY3RybFtpXS5yZWcg
KyBJQ1RMUl9DUFVfSUVSX0NMUl8wKTsKKwkJbW1pb193cml0ZWwoMHgwMDAwMDAwMCwgdGVn
cmFfaXJxX2N0cmxbaV0ucmVnICsgSUNUTFJfQ1BVX0lFUF9DTEFTU18wKTsKKwl9CisKKwlm
b3IgKGkgPSBJTlRfUFJJX0JBU0U7IGkgPCBJTlRfR1BJT19CQVNFOyBpKyspIHsKKwkJaXJx
X2Rlc2NbaV0uaGFuZGxlciA9ICZ0ZWdyYV9pcnFfY29udHJvbGxlcjsKKwl9CisKKwljcHVt
YXNrIHw9IGNwdW1hc2sgPDwgODsKKwljcHVtYXNrIHw9IGNwdW1hc2sgPDwgMTY7CisKKwl0
ZWdyYV9naWNfZGlzdF9iYXNlID0gSU9fQUREUkVTUyhURUdSQV9BUk1fSU5UX0RJU1RfQkFT
RSk7CisJdGVncmFfZ2ljX2NwdV9iYXNlW2NwdV0gPSBJT19BRERSRVNTKFRFR1JBX0dJQ19Q
Uk9DX0lGX0JBU0UpOworCisJbW1pb193cml0ZWwoMCwgdGVncmFfZ2ljX2Rpc3RfYmFzZSAr
IF9JQ0REQ1IpOworCQorICAgICAgICAvKgorICAgICAgICAgKiBGaW5kIG91dCBob3cgbWFu
eSBpbnRlcnJ1cHRzIGFyZSBzdXBwb3J0ZWQuCisgICAgICAgICAqLworICAgICAgICBtYXhf
aXJxID0gbW1pb19yZWFkbCh0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDVFIpICYgMHgx
ZjsKKyAgICAgICAgbWF4X2lycSA9IChtYXhfaXJxICsgMSkgKiAzMjsKKworICAgICAgICAv
KgorICAgICAgICAgKiBUaGUgR0lDIG9ubHkgc3VwcG9ydHMgdXAgdG8gMTAyMCBpbnRlcnJ1
cHQgc291cmNlcy4KKyAgICAgICAgICogTGltaXQgdGhpcyB0byBlaXRoZXIgdGhlIGFyY2hp
dGVjdGVkIG1heGltdW0sIG9yIHRoZQorICAgICAgICAgKiBwbGF0Zm9ybSBtYXhpbXVtLgor
ICAgICAgICAgKi8KKyAgICAgICAgaWYgKG1heF9pcnEgPiBtYXgoMTAyMCwgTlJfSVJRUykp
CisgICAgICAgICAgICAgICAgbWF4X2lycSA9IG1heCgxMDIwLCBOUl9JUlFTKTsKKworICAg
ICAgICAvKgorICAgICAgICAgKiBTZXQgYWxsIGdsb2JhbCBpbnRlcnJ1cHRzIHRvIGJlIGxl
dmVsIHRyaWdnZXJlZCwgYWN0aXZlIGxvdy4KKyAgICAgICAgICovCisgICAgICAgIGZvciAo
aSA9IDMyOyBpIDwgbWF4X2lycTsgaSArPSAxNikKKyAgICAgICAgICAgICAgICBtbWlvX3dy
aXRlbCgwLCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElDRlIgKyBpICogNCAvIDE2KTsK
KworICAgICAgICAvKgorICAgICAgICAgKiBTZXQgYWxsIGdsb2JhbCBpbnRlcnJ1cHRzIHRv
IHRoaXMgQ1BVIG9ubHkuCisgICAgICAgICAqLworICAgICAgICBmb3IgKGkgPSAzMjsgaSA8
IG1heF9pcnE7IGkgKz0gNCkKKyAgICAgICAgICAgICAgICBtbWlvX3dyaXRlbChjcHVtYXNr
LCB0ZWdyYV9naWNfZGlzdF9iYXNlICsgX0lDRElQVFIgKyBpICogNCAvIDQpOworICAgICAg
ICAvKgorICAgICAgICAgKiBTZXQgcHJpb3JpdHkgb24gYWxsIGludGVycnVwdHMuCisgICAg
ICAgICAqLworICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbWF4X2lycTsgaSArPSA0KQorICAg
ICAgICAgICAgICAgIG1taW9fd3JpdGVsKDB4YTBhMGEwYTAsIHRlZ3JhX2dpY19kaXN0X2Jh
c2UgKyBfSUNESVBSICsgaSAqIDQgLyA0KTsKKworICAgICAgICAvKgorICAgICAgICAgKiBE
aXNhYmxlIGFsbCBpbnRlcnJ1cHRzLgorICAgICAgICAgKi8KKyAgICAgICAgZm9yIChpID0g
MDsgaSA8IG1heF9pcnE7IGkgKz0gMzIpCisgICAgICAgICAgICAgICAgbW1pb193cml0ZWwo
MHhmZmZmZmZmZiwgdGVncmFfZ2ljX2Rpc3RfYmFzZSArIF9JQ0RJQ0VSICsgaSAqIDQgLyAz
Mik7CisKKyAgICAgICAgbW1pb193cml0ZWwoMSwgdGVncmFfZ2ljX2Rpc3RfYmFzZSArIF9J
Q0REQ1IpOworCisgICAgICAgIG1taW9fd3JpdGVsKDB4ZjAsIHRlZ3JhX2dpY19jcHVfYmFz
ZVtjcHVdICsgX0lDQ1BNUik7CisgICAgICAgIG1taW9fd3JpdGVsKDEsIHRlZ3JhX2dpY19j
cHVfYmFzZVtjcHVdICsgX0lDQ0lDUik7CisKKworfQorCisjZGVmaW5lIENMS19SU1RfQ09O
VFJPTExFUl9SU1RfQ1BVX0NNUExYX0NMUl8wICAoMHgzNDQpCisjZGVmaW5lIENMS19SU1Rf
Q09OVFJPTExFUl9DTEtfQ1BVX0NNUExYXzAgICAgICAoMHg0YykKKyNkZWZpbmUgQ1BVX0NM
S19TVE9QKGNwdSkgICAgICAgICAgICAgICAgICAgICAgICgweDE8PCg4K2NwdSkpCisjZGVm
aW5lIENQVV9SRVNFVChjcHUpICAgICAgICAgICAgICAgICAgICAgICAgICAoMHgxMDExdWw8
PChjcHUpKQorCisjZGVmaW5lIEVWUF9DUFVfUkVTRVRfVkVDVE9SXzAgICAgICAgICAgCSgw
eDEwMCkKKyNkZWZpbmUgRkxPV19DVFJMX0hBTFRfQ1BVeF9FVkVOVFMoY3B1KSAJKChjcHUp
ID8gKChjcHUgLSAxKSAqIDB4OCArIDB4MTQpIDogMHgwKQorCisKK3ZvbGF0aWxlIGludCB0
ZWdyYTI1MF9jb3JlX21hcCA9IDE7CisKK2FzbSgKKyIudHlwZSB0ZWdyYTI1MF9zbGF2ZV9j
cHVfc3RhcnQsICNmdW5jdGlvbglcbiIKKyIuZ2xvYmFsIHRlZ3JhMjUwX3NsYXZlX2NwdV9z
dGFydAkJXG4iCisidGVncmEyNTBfc2xhdmVfY3B1X3N0YXJ0OgkJCVxuIgorIgltc3IJY3Bz
cl9jLCAjMHhEMwkJCVxuIgorIgltb3YJcjAsICMwCQkJCVxuIgorIgltY3IJcDE1LCAyLCBy
MCwgYzAsIGMwLCAwCQlcbiIKKyIJbXJjCXAxNSwgMSwgcjAsIGMwLCBjMCwgMAkJXG4iCisi
CWxkcglyMSwgPTB4N0ZGRgkJCVxuIgorIglhbmQJcjIsIHIxLCByMCwgbHNyICMxMwkJXG4i
CisiCWxkcglyMSwgPTB4M0ZGCQkJXG4iCisiCWFuZAlyMywgcjEsIHIwLCBsc3IgIzMJCVxu
IgorIglhZGQJcjIsIHIyLCAjMQkJCVxuIgorIglhbmQJcjAsIHIwLCAjMHgwNwkJCVxuIgor
IglhZGQJcjAsIHIwLCAjNAkJCVxuIgorIgljbHoJcjEsIHIzCQkJCVxuIgorIglhZGQJcjQs
IHIzLCAjMQkJCVxuIgorIjE6CXN1YglyMiwgcjIsICMxCQkJXG4iCisiCW1vdglyMywgcjQJ
CQkJXG4iCisiMjoJc3VicwlyMywgcjMsICMxCQkJXG4iCisiCW1vdglyNSwgcjMsIGxzbCBy
MQkJCVxuIgorIgltb3YJcjYsIHIyLCBsc2wgcjAJCQlcbiIKKyIJb3JyCXI1LCByNSwgcjYJ
CQlcbiIKKyIJbWNyCXAxNSwgMCwgcjUsIGM3LCBjNiwgMgkJXG4iCisiCWJndAkyYgkJCQlc
biIKKyIJY21wCXIyLCAjMAkJCQlcbiIKKyIJYmd0CTFiCQkJCVxuIgorIglkc2IJCQkJCVxu
IgorIglpc2IJCQkJCVxuIgorIgltcmMJcDE1LCAwLCByMCwgYzAsIGMwLCA1CQlcbiIKKyIJ
YW5kCXIwLCByMCwgIzE1CQkJXG4iCisiCWFkcglyNCwgMWYJCQkJXG4iCisiCWxkbWlhCXI0
LCB7cjUsIHI2fQkJCVxuIgorIglzdWIJcjQsIHI0LCByNQkJCVxuIgorIglhZGQJcjYsIHI2
LCByNAkJCVxuIgorIgltb3YJcjEsICMxCQkJCVxuIgorIglsc2wJcjEsIHIxLCByMAkJCVxu
IgorInNwaW46CWxkcglyNywgW3I2XQkJCVxuIgorIgl0c3QJcjcsIHIxCQkJCVxuIgorIgli
ZXEJc3BpbgkJCQlcbiIKKyIJYglzbGF2ZV9jcHVfc3RhcnQJCQlcbiIKKyIxOgkubG9uZwku
CQkJCVxuIgorIgkubG9uZwl0ZWdyYTI1MF9jb3JlX21hcAkJXG4iCispOworCitpbnQgd2Fr
ZXVwX2NwdSh1bnNpZ25lZCBpbnQgY3B1KQoreworCXRlZ3JhMjUwX2NvcmVfbWFwIHw9IDEg
PDwgIGNwdTsKKworCWNwdV9mbHVzaF9jYWNoZV9hbGwoKTsKKworCXJldHVybiAwOworfQor
CitleHRlcm4gdm9pZCB0ZWdyYTI1MF9zbGF2ZV9jcHVfc3RhcnQodm9pZCk7CisKK3N0YXRp
YyB2b2lkIHRlZ3JhMjUwX2V2cF9pbml0KHZvaWQpCit7CisJdW5zaWduZWQgbG9uZyByLCBv
cmcsIGxvb3AsIGN0cmw7CisKKwkvKiBJbml0aWFsaXplIFNub29wIENvbnRyb2wgVW5pdCAq
LworCWN0cmwgPSBtbWlvX3JlYWRsKElPX0FERFJFU1MoVEVHUkFfU0NVX0JBU0UpICsgMHgw
KTsKKwljdHJsIHw9IDE7CisJbW1pb193cml0ZWwoY3RybCwgSU9fQUREUkVTUyhURUdSQV9T
Q1VfQkFTRSkgKyAweDApOworCisJb3JnID0gbW1pb19yZWFkbChJT19BRERSRVNTKFRFR1JB
X0VYQ0VQVElPTl9WRUNUT1JTX0JBU0UpICsgRVZQX0NQVV9SRVNFVF9WRUNUT1JfMCk7CisK
KwkvKiBTZXQgYm9vdCBlbnRyeSAqLworCW1taW9fd3JpdGVsKF9fcGEodGVncmEyNTBfc2xh
dmVfY3B1X3N0YXJ0KSwgSU9fQUREUkVTUyhURUdSQV9FWENFUFRJT05fVkVDVE9SU19CQVNF
KSArIEVWUF9DUFVfUkVTRVRfVkVDVE9SXzApOworCisJZHNiKCk7CisJaXNiKCk7CisKKwkv
KiBIYWx0IENQVSAqLworCW1taW9fd3JpdGVsKDAsIElPX0FERFJFU1MoVEVHUkFfRkxPV19D
VFJMX0JBU0UpICsgRkxPV19DVFJMX0hBTFRfQ1BVeF9FVkVOVFMoMSkpOworCisJZHNiKCk7
CisJaXNiKCk7CisKKwkvKiBDUFUgQ2xvY2sgU3RvcCAqLworCXIgPSBtbWlvX3JlYWRsKElP
X0FERFJFU1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpICsgQ0xLX1JTVF9DT05UUk9MTEVSX0NM
S19DUFVfQ01QTFhfMCk7CisJciAmPSB+Q1BVX0NMS19TVE9QKDEpOworCW1taW9fd3JpdGVs
KHIsIElPX0FERFJFU1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpICsgQ0xLX1JTVF9DT05UUk9M
TEVSX0NMS19DUFVfQ01QTFhfMCk7CisKKwlkc2IoKTsKKwlpc2IoKTsKKworCS8qIFJlc3Rh
cnQgU2xhdmUgQ1BVICovCisJbW1pb193cml0ZWwoQ1BVX1JFU0VUKDEpLCBJT19BRERSRVNT
KFRFR1JBX0NMS19SRVNFVF9CQVNFKSArIENMS19SU1RfQ09OVFJPTExFUl9SU1RfQ1BVX0NN
UExYX0NMUl8wKTsKKworCWRzYigpOworCWlzYigpOworCisgICAgICAgIC8qIFdhaXQgdXRp
bCB0aGUgcG93ZXIgdW5pdCBpcyBpbiBzdGFibGUgKi8KKyAgICAgICAgbG9vcCA9IDEwMDAw
OworICAgICAgICB3aGlsZSgoLS1sb29wKSA+IDAgKTsKK30KKwordm9pZCB0ZWdyYTI1MF9p
b3JlbWFwKHZvaWQpCit7CisJbWFwX3BhZ2VzX3RvX3hlbihJT19BRERSRVNTKFRFR1JBX0FS
TV9DUFVfQkFTRSksCisJCVRFR1JBX0FSTV9DUFVfQkFTRSA+PiBQQUdFX1NISUZULCAweDEw
MDAwMCA+PiBQQUdFX1NISUZULAorCQlMMUVfVFlQRV9ERVZJQ0UpOworCisJbWFwX3BhZ2Vz
X3RvX3hlbihJT19BRERSRVNTKFRFR1JBX1BQU0JfREVWSUNFX0JBU0UpLAorCQlURUdSQV9Q
UFNCX0RFVklDRV9CQVNFID4+IFBBR0VfU0hJRlQsIDB4MTAwMDAwID4+IFBBR0VfU0hJRlQs
IAorCQlMMUVfVFlQRV9ERVZJQ0UpOworCisJbWFwX3BhZ2VzX3RvX3hlbihJT19BRERSRVNT
KFRFR1JBX0FQQl9ERVZJQ0VfQkFTRSksCisJCVRFR1JBX0FQQl9ERVZJQ0VfQkFTRSA+PiBQ
QUdFX1NISUZULCAweDEwMDAwMCA+PiBQQUdFX1NISUZULAorCQlMMUVfVFlQRV9ERVZJQ0Up
OworfQorCitpbnQgbWFjaGluZV9zZXR1cCh2b2lkKQoreworCWNwdV90b3BvbG9neV9pbml0
KDIpOworCisJdGVncmEyNTBfaW9yZW1hcCgpOworCisJdGVncmEyNTBfZXZwX2luaXQoKTsK
KworCXRlZ3JhMjUwX2lycV9pbml0KCk7CisKKwl0ZWdyYTI1MF90aW1lcl9pbml0KCk7CisK
KwlyZXR1cm4gMDsKK30KKwpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0vdGVn
cmEvdGltZXIuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MAorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvdGltZXIuYwlTdW4gRmViIDEyIDE1OjA0OjA2
IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMTAgQEAKKy8qCisgKiBhcmNoL2FybS9tYWNoLXRl
Z3JhL3RpbWVyLmMKKyAqCisgKiBUaW1lciBhbmQgY2xvY2sgZXZlbnQgc3VwcG9ydCBmb3Ig
TlZJRElBIFRlZ3JhIFNvQ3MKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgtMjAwOSwgTlZJ
RElBIENvcnBvcmF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl
ZCBieQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24g
MiBvZiB0aGUgTGljZW5zZSwgb3IKKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZl
cnNpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl
IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFOVFk7
IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkg
b3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBhbG9uZworICogd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUg
dG8gdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLiwKKyAqIDUxIEZyYW5rbGlu
IFN0cmVldCwgRmlmdGggRmxvb3IsIEJvc3RvbiwgTUEgIDAyMTEwLTEzMDEsIFVTQS4KKyAq
LworCisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVuL2lycS5oPgorI2lu
Y2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL3NvZnRpcnEuaD4KKyNpbmNsdWRl
IDx4ZW4vc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxhc20vdGltZS5oPgorI2luY2x1ZGUgPGFz
bS9hcmNoL2lycXMuaD4KKyNpbmNsdWRlIDxhc20vYXJjaC90ZWdyYS5oPgorCisKKyNkZWZp
bmUgQ0xLX1JTVF9DT05UUk9MTEVSX09TQ19DVFJMXzAJMHg1MAorCisjZGVmaW5lIFRJTUVS
MV9PRkZTCQkJMHgwMCAgLyogcmVzZXJ2ZWQgZm9yIEFWUCAqLworI2RlZmluZSBUSU1FUjJf
T0ZGUwkJCTB4MDggIC8qIHJlc2VydmVkIGZvciBBVlAgKi8KKyNkZWZpbmUgVElNRVIzX09G
RlMJCQkweDUwICAvKiB1c2VkIGFzIE9TIENQVSBldmVudCB0aW1lciAqLworI2RlZmluZSBU
SU1FUjRfT0ZGUwkJCTB4NTggIC8qIHJlc2VydmVkIGFzIExQMiB3YWtldXAgdHJpZ2dlciAq
LworCisjZGVmaW5lIFRJTUVSX1RNUl9QVFZfMAkJCTB4MAorI2RlZmluZSBUSU1FUl9UTVJf
UENSXzAJCQkweDQKKworI2RlZmluZSBUSU1FUlVTX09GRlMJCQkweDEwCisjZGVmaW5lIFRJ
TUVSVVNfQ05UUl8xVVNfMAkJMHgwCisjZGVmaW5lIFRJTUVSVVNfVVNFQ19DRkdfMAkJMHg0
CisKKyNkZWZpbmUgTlNFQ19QRVJfU0VDCQkJMTAwMDAwMDAwMEwKKwordm9pZCB0ZWdyYV9j
bG9ja2V2ZW50X2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBjcHVf
dXNlcl9yZWdzICpyZWdzKQoreworICAgICAgICBtbWlvX3dyaXRlbCgxIDw8IDMwLCBJT19B
RERSRVNTKFRFR1JBX1RNUjFfQkFTRSArIFRJTUVSM19PRkZTKSArIFRJTUVSX1RNUl9QQ1Jf
MCk7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgaXJxYWN0aW9uIHRlZ3JhX2Nsb2NrZXZlbnRfaXJx
ID0geworICAgICAgICAubmFtZSAgICAgICAgICAgPSAiVGltZXJfZXZlbnQiLAorICAgICAg
ICAuaGFuZGxlciAgICAgICAgPSB0ZWdyYV9jbG9ja2V2ZW50X2ludGVycnVwdCwKK307CisK
K3ZvaWQgdGVncmFfbHAyd2FrZV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLCBz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKK3sKKyAgICAgICAgbW1pb193cml0ZWwoMTw8
MzAsIElPX0FERFJFU1MoVEVHUkFfVE1SMV9CQVNFICsgVElNRVI0X09GRlMpICsgVElNRVJf
VE1SX1BDUl8wKTsKK30KKworc3RhdGljIHN0cnVjdCBpcnFhY3Rpb24gdGVncmFfbHAyd2Fr
ZV9pcnEgPSB7CisgICAgICAgIC5uYW1lICAgICAgICAgICA9ICJ0aW1lcl9scDJ3YWtlIiwK
KyAgICAgICAgLmhhbmRsZXIgICAgICAgID0gdGVncmFfbHAyd2FrZV9pbnRlcnJ1cHQsCit9
OworCitzdGF0aWMgdW5zaWduZWQgbG9uZyBtZWFzdXJlX2lucHV0X2ZyZXEodW5zaWduZWQg
aW50ICptLCB1bnNpZ25lZCBpbnQgKm4pCit7CisJdm9pZCAqY2xrX3JzdCA9IElPX0FERFJF
U1MoVEVHUkFfQ0xLX1JFU0VUX0JBU0UpOworCXVuc2lnbmVkIGxvbmcgb3NjID0gbW1pb19y
ZWFkbChjbGtfcnN0ICsgQ0xLX1JTVF9DT05UUk9MTEVSX09TQ19DVFJMXzApOworCW9zYyA+
Pj0gMzA7CisKKwlzd2l0Y2ggKG9zYykgeworCQljYXNlIDA6IGlmIChtICYmIG4pIHsgKm09
MTsgKm49MTM7IH0gcmV0dXJuIDEzMDAwOworCQljYXNlIDE6IGlmIChtICYmIG4pIHsgKm09
NTsgKm49OTY7IH0gcmV0dXJuIDE5MjAwOworCQljYXNlIDI6IGlmIChtICYmIG4pIHsgKm09
MTsgKm49MTI7IH0gcmV0dXJuIDEyMDAwOworCQljYXNlIDM6IGlmIChtICYmIG4pIHsgKm09
MTsgKm49MjY7IH0gcmV0dXJuIDI2MDAwOworCX0KKworCXJldHVybiAwOworfQorCit2b2lk
IHRlZ3JhMjUwX3RpbWVyX2luaXQodm9pZCkKK3sKKyAgICAgICAgdm9pZCAqdG1yOworICAg
ICAgICB1bnNpZ25lZCBpbnQgbSwgbjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyB2YWw7Cisg
ICAgICAgIHUzMiByZWc7CisKKyAgICAgICAgdG1yID0gSU9fQUREUkVTUyhURUdSQV9UTVIx
X0JBU0UgKyBUSU1FUlVTX09GRlMpOworICAgICAgICB2YWwgPSBtZWFzdXJlX2lucHV0X2Zy
ZXEoJm0sICZuKTsKKworICAgICAgICB2YWwgPSAoKG0tMSk8PDgpIHwgKG4tMSk7CisKKyAg
ICAgICAgbW1pb193cml0ZWwodmFsLCB0bXIgKyBUSU1FUlVTX1VTRUNfQ0ZHXzApOworICAg
ICAgICBtbWlvX3dyaXRlbCgwLCBJT19BRERSRVNTKFRFR1JBX1RNUjFfQkFTRSArIFRJTUVS
M19PRkZTKSAgKyBUSU1FUl9UTVJfUFRWXzApOworCisgICAgICAgIHJlZyA9IDB4YzAwMDI3
MGY7CisgICAgICAgIG1taW9fd3JpdGVsKHJlZywgSU9fQUREUkVTUyhURUdSQV9UTVIxX0JB
U0UgKyBUSU1FUjNfT0ZGUykgKyBUSU1FUl9UTVJfUFRWXzApOworCisgICAgICAgIGlmIChz
ZXR1cF9pcnEoSU5UX1RNUjMsICZ0ZWdyYV9jbG9ja2V2ZW50X2lycSkpIHsKKyAgICAgICAg
ICAgICAgICBCVUcoKTsKKyAgICAgICAgfQorICAgICAgICBpZiAoc2V0dXBfaXJxKElOVF9U
TVI0LCAmdGVncmFfbHAyd2FrZV9pcnEpKSB7CisgICAgICAgICAgICAgICAgQlVHKCk7Cisg
ICAgICAgIH0KK30KKwpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0veGVuL2Nw
dS5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxMjoyNDoyMSAy
MDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxNTow
NDowNiAyMDEyICswOTAwCkBAIC01Myw2ICs1MywxMSBAQCBpbnQgX19jcHVfdXAodW5zaWdu
ZWQgaW50IGNwdSkKIHsKIAlpbnQgcmV0ID0gMDsKIAorCXJldCA9IHdha2V1cF9jcHUoY3B1
KTsKKwlpZiAoIXJldCkgeworCQlyZXR1cm4gLUVJTlZBTDsKKwl9CisKIAl3aGlsZSghY3B1
X29ubGluZShjcHUpKSB7CiAJCWNwdV9yZWxheCgpOwogCQlwcm9jZXNzX3BlbmRpbmdfc29m
dGlycXMoKTsKZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5j
Ci0tLSBhL3hlbi9hcmNoL2FybS94ZW4vZmF1bHQuYwlTdW4gRmViIDEyIDEyOjI0OjIxIDIw
MTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5jCVN1biBGZWIgMTIgMTU6
MDQ6MDYgMjAxMiArMDkwMApAQCAtMzMsNyArMzMsNiBAQAogI2luY2x1ZGUgPGFzbS9wcm9j
ZXNzb3IuaD4NCiAjaW5jbHVkZSA8YXNtL2d1ZXN0X2FjY2Vzcy5oPg0KICNpbmNsdWRlIDxh
c20vc3lzdGVtLmg+DQotI2luY2x1ZGUgPGFzbS9tZW1vcnkuaD4NCiANCiBhc21saW5rYWdl
IHZvaWQgX19kaXYwKHZvaWQpDQogew0KZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVuL2FyY2gv
YXJtL3hlbi9pcnEuYwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2lycS5jCVN1biBGZWIgMTIg
MTI6MjQ6MjEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2lycS5jCVN1biBG
ZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMApAQCAtMzgsOSArMzgsMjcgQEAgaHdfaXJxX2Nv
bnRyb2xsZXIgbm9faXJxX3R5cGUgPSB7CiAJLnNodXRkb3duID0gaXJxX3NodXRkb3duX25v
bmUsCiAJLmVuYWJsZSAgID0gaXJxX2VuYWJsZV9ub25lLAogCS5kaXNhYmxlICA9IGlycV9k
aXNhYmxlX25vbmUsCisJLmVuZAkgID0gaXJxX2VuZF9ub25lLAorCS5hY2sJICA9IGlycV9h
Y2tfbm9uZSwKIH07CiAKLXN0cnVjdCBpcnFfZGVzYyAqaXJxX2Rlc2M7CisvL3N0cnVjdCBp
cnFfZGVzYyAqaXJxX2Rlc2M7CisKK2lycV9kZXNjX3QgaXJxX2Rlc2NbTlJfSVJRU10gPSB7
CisgICAgICAgIFswIC4uLiBOUl9JUlFTIC0gMV0gPSB7CisgICAgICAgICAgICAgICAgLnN0
YXR1cyA9IElSUV9ESVNBQkxFRCwKKyAgICAgICAgICAgICAgICAuaGFuZGxlciA9ICZub19p
cnFfdHlwZSwKKyAgICAgICAgICAgICAgICAuYWN0aW9uID0gTlVMTCwKKyAgICAgICAgICAg
ICAgICAubG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRAorICAgICAgICB9Cit9OworCitzdHJ1
Y3QgaXJxX2NmZyBpcnFfY2ZnW05SX0lSUVNdID0geworICAgICAgICBbMCAuLi4gTlJfSVJR
UyAtIDFdID17CisgICAgICAgICAgICAgICAgLmlycSA9IDAKKyAgICAgICAgfQorfTsKKwog
CiBpbnQgcGlycV9ndWVzdF91bm1hc2soc3RydWN0IGRvbWFpbiAqZCkKIHsKQEAgLTc1LDYg
KzkzLDMyIEBAIHN0cnVjdCBwaXJxICphbGxvY19waXJxX3N0cnVjdChzdHJ1Y3QgZG8KIAly
ZXR1cm4gTlVMTDsKIH0KIAoraW50IHNldHVwX2lycSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1
Y3QgaXJxYWN0aW9uICpuZXcpCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwlzdHJ1Y3Qg
aXJxX2Rlc2MgKmRlc2M7CisKKwlpZihpcnEgPj0gTlJfSVJRUykgeworCQlwcmludGsoIkJB
RCBJUlEgPSAlZFxuIiwgaXJxKTsKKwl9CisKKwlkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsK
KworCXNwaW5fbG9ja19pcnFzYXZlKCZkZXNjLT5sb2NrLCBmbGFncyk7CisJZGVzYy0+YWN0
aW9uID0gbmV3OworCWlmIChkZXNjLT5oYW5kbGVyKSB7CisJCWlmIChkZXNjLT5oYW5kbGVy
LT5zdGFydHVwKSB7CisJCQlkZXNjLT5oYW5kbGVyLT5zdGFydHVwKGRlc2MpOworCQl9IGVs
c2UgaWYoZGVzYy0+aGFuZGxlci0+ZW5hYmxlKSB7CisJCQlkZXNjLT5oYW5kbGVyLT5lbmFi
bGUoZGVzYyk7CisJCX0KKwl9CisKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZkZXNjLT5s
b2NrLCBmbGFncyk7CisKKwlyZXR1cm4gMDsKK30KKwogaW50IGFyY2hfaW5pdF9vbmVfaXJx
X2Rlc2Moc3RydWN0IGlycV9kZXNjICpkZXNjKQogewogCU5PVF9ZRVQoKTsKZGlmZiAtciA2
YWY4YTg5Yzk5Y2QgeGVuL2FyY2gvYXJtL3hlbi9tbS5jCi0tLSBhL3hlbi9hcmNoL2FybS94
ZW4vbW0uYwlTdW4gRmViIDEyIDEyOjI0OjIxIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9tbS5jCVN1biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMApAQCAtMjU1LDMg
KzI1NSwyNyBAQCBpbnQgYWxsb2NfcGFnZV9tYXAodW5zaWduZWQgbG9uZyB2aXJ0LCB1CiAJ
cmV0dXJuIDA7CiB9CiAKK2ludCBtYXBfcGFnZXNfdG9feGVuKHVuc2lnbmVkIGxvbmcgdmly
dCwgdW5zaWduZWQgbG9uZyBtZm4sIGludCBuciwgdW5zaWduZWQgbG9uZyBmbGFncykKK3sK
KyAgICAgICAgdW5zaWduZWQgbG9uZyB2YWRkciA9IHJvdW5kX2Rvd24odmlydCwgUEFHRV9T
SVpFKTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBtYWRkciA9IG1mbiA8PCBQQUdFX1NISUZU
OworICAgICAgICB1bnNpZ25lZCBpbnQgZW5kID0gdmlydCArIChuciA8PCBQQUdFX1NISUZU
KTsKKworICAgICAgICBsMWVfdCAqbDFlID0gbDFfbGluZWFyX29mZnNldF94ZW4odmFkZHIp
OworCisgICAgICAgIGRvIHsKKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIGxpbWl0
ID0gKHZhZGRyICsgU0VDVElPTl9TSVpFKSAmIChTRUNUSU9OX01BU0spOworICAgICAgICAg
ICAgICAgIGxpbWl0ID0gKGxpbWl0IDwgZW5kKSA/IGxpbWl0IDogZW5kOworCisgICAgICAg
ICAgICAgICAgaWYgKCgodmFkZHIgfCBtYWRkciB8IGxpbWl0KSAmIH5TRUNUSU9OX01BU0sp
ID09IDApIHsKKyAgICAgICAgICAgICAgICAgICAgICAgICpsMWUgPSBNS19MMUUobWFkZHIs
IGZsYWdzKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIHB0ZV9zeW5jKGwxZSk7CisKKyAg
ICAgICAgICAgICAgICAgICAgICAgIHZhZGRyICs9IFNFQ1RJT05fU0laRTsKKyAgICAgICAg
ICAgICAgICAgICAgICAgIG1hZGRyICs9IFNFQ1RJT05fU0laRTsKKyAgICAgICAgICAgICAg
ICB9CisgICAgICAgIH0gd2hpbGUobDFlKyssIHZhZGRyIDwgZW5kKTsKKworICAgICAgICBy
ZXR1cm4gMDsKK30KKwpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vYXJjaC9hcm0veGVuL3Nl
dHVwLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCVN1biBGZWIgMTIgMTI6MjQ6
MjEgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMJU3VuIEZlYiAx
MiAxNTowNDowNiAyMDEyICswOTAwCkBAIC02NCwxMSArNjQsMTEgQEAgc3RhdGljIHVuc2ln
bmVkIGludCBkb20wX3NpemUgPSAyNTYgKiAxMAogaW50ZWdlcl9wYXJhbSgiZG9tMF9zaXpl
IiwgZG9tMF9zaXplKTsKIAogLy9zdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3N0
YXJ0ID0gMHg0MEIwMDAwMFVMOwotc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFnZV9z
dGFydCA9IDB4MDBCMDAwMDBVTDsKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vf
c3RhcnQgPSAweEEwMDAwMFVMOwogaW50ZWdlcl9wYXJhbSgiaW1hZ2Vfc3RhcnQiLCBkb20w
X2ltYWdlX3N0YXJ0KTsKIAogLy9zdGF0aWMgdW5zaWduZWQgbG9uZyBkb20wX2ltYWdlX3Np
emUgPSAweEEwMDAwMFVMOwotc3RhdGljIHVuc2lnbmVkIGxvbmcgZG9tMF9pbWFnZV9zaXpl
ID0gMHhBMDAwMDBVTDsKK3N0YXRpYyB1bnNpZ25lZCBsb25nIGRvbTBfaW1hZ2Vfc2l6ZSA9
IDB4MTQwMDAwMFVMOwogaW50ZWdlcl9wYXJhbSgiaW1hZ2VfbGVuZ3RoIiwgZG9tMF9pbWFn
ZV9zaXplKTsKIAogdm9pZCBhcmNoX2dldF94ZW5fY2Fwcyh4ZW5fY2FwYWJpbGl0aWVzX2lu
Zm9fdCAqaW5mbykKQEAgLTIxMSw2ICsyMTEsOCBAQCBhc21saW5rYWdlIHZvaWQgc3RhcnRf
eGVuKHZvaWQpCiAKIAl0YXNrbGV0X3N1YnN5c19pbml0KCk7CiAKKwltYWNoaW5lX3NldHVw
KCk7CisKIAl0aW1lcl9pbml0KCk7CiAKIAlpZGxlX2RvbWFpbl9pbml0KCk7CmRpZmYgLXIg
NmFmOGE4OWM5OWNkIHhlbi9hcmNoL2FybS94ZW4vdGltZS5jCi0tLSBhL3hlbi9hcmNoL2Fy
bS94ZW4vdGltZS5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkwMAorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3RpbWUuYwlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAg
LTc5LDUgKzc5LDQgQEAgdm9pZCBkb21haW5fc2V0X3RpbWVfb2Zmc2V0KHN0cnVjdCBkb21h
aQogCiB2b2lkIHRpbWVrZWVwaW5nX2luaXQodm9pZCkKIHsKLQlOT1RfWUVUKCk7CiB9CmRp
ZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jCi0tLSBhL3hl
bi9kcml2ZXJzL2NoYXIvY29uc29sZS5jCVN1biBGZWIgMTIgMTI6MjQ6MjEgMjAxMiArMDkw
MAorKysgYi94ZW4vZHJpdmVycy9jaGFyL2NvbnNvbGUuYwlTdW4gRmViIDEyIDE1OjA0OjA2
IDIwMTIgKzA5MDAKQEAgLTQxMiw3ICs0MTIsMTEgQEAgbG9uZyBkb19jb25zb2xlX2lvKGlu
dCBjbWQsIGludCBjb3VudCwgWAogICogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioKICAqLwogCisjaWYgZGVmaW5lZChfX2FybV9fKQor
c3RhdGljIGJvb2xfdCBjb25zb2xlX2xvY2tzX2J1c3RlZCA9IDE7CisjZWxzZQogc3RhdGlj
IGJvb2xfdCBjb25zb2xlX2xvY2tzX2J1c3RlZDsKKyNlbmRpZgogCiBzdGF0aWMgdm9pZCBf
X3B1dHN0cihjb25zdCBjaGFyICpzdHIpCiB7CmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9p
bmNsdWRlL2FzbS1hcm0vZ2ljLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9naWMuaAlTdW4gRmViIDEy
IDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMDEgQEAKKy8qCisgKiBnaWMuaAor
ICoKKyAqIENvcHlyaWdodCAoQykgMjAxMSBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAg
ICAgICBKYWVtaW4gUnl1ICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9v
ciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVi
bGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzCisgKiBwdWJsaXNoZWQgYnkgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0
ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VU
IEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Uu
ICBTZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRh
aWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsg
aWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwgSW5j
LiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcg
IFVTQQorICovCisKKyNpZm5kZWYgX19BUk1fR0lDX0hfXworI2RlZmluZSBfX0FSTV9HSUNf
SF9fCisKKworLyogRGlzdHJpYnV0b3IgUmVnaXN0ZXIgTWFwICovCisjZGVmaW5lIF9JQ0RE
Q1IJCTB4MDAwICAvKiBEaXN0cmlidXRvciBDb250cm9sIFJlZ2lzdGVyICovCisjZGVmaW5l
IF9JQ0RJQ1RSCTB4MDA0ICAvKiBJbnRlcnJ1cHQgQ29udHJvbGxlciBUeXBlIFJlZ2lzdGVy
ICovCisjZGVmaW5lIF9JQ0RJSURSCTB4MDA4ICAvKiBEaXN0cmlidXRvciBJbXBsZW1lbnRl
ciBJZCBSZWdpc3RlciAqLworI2RlZmluZSBfSUNESVNSMAkweDA4MCAgLyogSW50ZXJydXB0
IFNlY3VyaXR5IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RJU1IxCTB4MDg0ICAvKiBJbnRl
cnJ1cHQgU2VjdXJpdHkgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDRElTUjIJMHgwODggIC8q
IEludGVycnVwdCBTZWN1cml0eSBSZWdpc3RlciAqLworI2RlZmluZSBfSUNESVNSMwkweDA4
YyAgLyogSW50ZXJydXB0IFNlY3VyaXR5IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RJU1I0
CTB4MDkwICAvKiBJbnRlcnJ1cHQgU2VjdXJpdHkgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lD
RElTRVIJMHgxMDAgIC8qIEludGVycnVwdCBTZXQtRW5hYmxlIFJlZ2lzdGVyICovCisjZGVm
aW5lIF9JQ0RJQ0VSCTB4MTgwICAvKiBJbnRlcnJ1cHQgQ2xlYXItRW5hYmxlIFJlZ2lzdGVy
ICovCisjZGVmaW5lIF9JQ0RJU1BSCTB4MjAwICAvKiBJbnRlcnJ1cHQgU2V0LVBlbmRpbmcg
UmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDRElDUFIJMHgyODAgIC8qIEludGVycnVwdCBDbGVh
ci1QZW5kaW5nIFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RBQlIJCTB4MzAwICAvKiBBY3Rp
dmUgQml0IFJlZ2lzdGVycyAqLworI2RlZmluZSBfSUNESVBSCQkweDQwMCAgLyogSW50ZXJy
dXB0IFByaW9yaXR5IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0RJUFRSCTB4ODAwICAvKiBJ
bnRlcnJ1cHQgUHJvY2Vzc29yIFRhcmdldHMgUmVnaXN0ZXJzICovCisjZGVmaW5lIF9JQ0RJ
Q0ZSCTB4QzAwICAvKiBJbnRlcnJ1cHQgQ29uZmlndXJhdGlvbiBSZWdpc3RlcnMgKi8KKyNk
ZWZpbmUgX0lDRFNHSVIJMHhGMDAgIC8qIFNvZnR3YXJlIEdlbmVyYXRlZCBJbnRlcnJ1cHQg
UmVnaXN0ZXIgKi8KKworI2RlZmluZSBJQ0REQ1IoKQkoX0lDRERDUikKKyNkZWZpbmUgSUNE
SUNUUigpCShfSUNESUNUUikKKyNkZWZpbmUgSUNESVNSKHgpCShfSUNESVNSMCArICh4IC8g
QklUU19QRVJfTE9ORykgKiBCWVRFU19QRVJfTE9ORykKKyNkZWZpbmUgSUNESVNFUih4KQko
X0lDRElTRVIgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xPTkcpCisjZGVm
aW5lIElDRElDRVIoeCkJKF9JQ0RJQ0VSICsgKHggLyBCSVRTX1BFUl9MT05HKSAqIEJZVEVT
X1BFUl9MT05HKQorI2RlZmluZSBJQ0RJU1BSKHgpCShfSUNESVNQUiArICh4IC8gQklUU19Q
RVJfTE9ORykgKiBCWVRFU19QRVJfTE9ORykKKyNkZWZpbmUgSUNESUNQUih4KQkoX0lDRElD
UFIgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xPTkcpCisjZGVmaW5lIElD
REFCUih4KQkoX0lDREFCUiAgKyAoeCAvIEJJVFNfUEVSX0xPTkcpICogQllURVNfUEVSX0xP
TkcpCisjZGVmaW5lIElDRElQUih4KQkoX0lDRElQUiAgKyAoeCAvICA0KSAqIEJZVEVTX1BF
Ul9MT05HKQorI2RlZmluZSBJQ0RJUFRSKHgpCShfSUNESVBUUiArICh4IC8gIDQpICogQllU
RVNfUEVSX0xPTkcpCisjZGVmaW5lIElDRFNHSVIoKQkoX0lDRFNHSVIpCisKKy8qIENQVSBJ
bnRlcmZhY2UgUmVnaXN0ZXIgTWFwICovCisjZGVmaW5lIF9JQ0NJQ1IJCTB4MDAwICAvKiBD
UFUgSW50ZXJmYWNlIENvbnRyb2wgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDQ1BNUgkJMHgw
MDQgIC8qIEludGVycnVwdCBQcmlvcml0eSBNYXNrIFJlZ2lzdGVyICovCisjZGVmaW5lIF9J
Q0NCUFIJCTB4MDA4ICAvKiBCaW5yYXJ5IFBvaW50IFJlZ2lzdGVyICovCisjZGVmaW5lIF9J
Q0NJQVIJCTB4MDBDICAvKiBJbnRlcnJ1cHQgQWNrbm93bGVkZ2UgUmVnaXN0ZXIgKi8KKyNk
ZWZpbmUgX0lDQ0VPSVIJMHgwMTAgIC8qIEVuZCBvZiBJbnRlcnJ1cHQgUmVnaXN0ZXIgKi8K
KyNkZWZpbmUgX0lDQ1JQUgkJMHgwMTQgIC8qIFJ1bm5pbmcgUHJpb3JpdHkgUmVnaXN0ZXIg
Ki8KKyNkZWZpbmUgX0lDQ0hQSVIJMHgwMTggIC8qIEhpZ2hlc3QgUGVuZGluZyBJbnRlcnJ1
cHQgUmVnaXN0ZXIgKi8KKyNkZWZpbmUgX0lDQ0FCUFIJMHgwMUMgIC8qIEFsaWFzZWQgQmlu
YXJ5IFBvaW50IFJlZ2lzdGVyICovCisjZGVmaW5lIF9JQ0NJSURSCTB4MEZDICAvKiBDUFUg
SW50ZXJmYWNlIElkIFJlZ2lzdGVyICovCisKKyNkZWZpbmUgSUNDSUNSKCkJKF9JQ0NJQ1Ip
CisjZGVmaW5lIElDQ1BNUigpCShfSUNDUE1SKQorI2RlZmluZSBJQ0NCUFIoKQkoX0lDQ0JQ
UikKKyNkZWZpbmUgSUNDSUFSKCkJKF9JQ0NJQVIpCisjZGVmaW5lIElDQ0VPSVIoKQkoX0lD
Q0VPSVIpCisjZGVmaW5lIElDQ1JQUigpCShfSUNDUlBSKQorI2RlZmluZSBJQ0NIUElSKCkJ
KF9JQ0NIUElSKQorI2RlZmluZSBJQ0NJSURSKCkJKF9JQ0NJSURSKQorCisjZGVmaW5lIFNF
Q1VSRV9JTlRFUlJVUFQJMAorI2RlZmluZSBOT05TRUNVUkVfSU5URVJSVVBUCTEKKworI2Rl
ZmluZSBTR0koeCkJCQkoeCkKKyNkZWZpbmUgUFBJKHgpCQkJKHggKyAxNikKKyNkZWZpbmUg
U1BJKHgpCQkJKHggKyAzMikKKworI2lmbmRlZiBfX0FTU0VNQkxZX18KKworI2luY2x1ZGUg
PHhlbi90eXBlcy5oPgorCisjZGVmaW5lIEdJQ19ESVNUUklCVVRPUih4KSAgICAgIChfZ2lj
X2Rpc3RyaWJ1dG9yX2Jhc2UgKyB4KQorI2RlZmluZSBHSUNfQ1BVX0lOVEVSRkFDRSh4KSAg
ICAoX2dpY19jcHVfYmFzZSArIHgpCisKK3ZvaWQgZ2ljX3NldF9jcHUodW5zaWduZWQgaW50
IGlycSwgdW5zaWduZWQgaW50IG1hc2spOwordm9pZCBnaWNfc2V0X2lycV9wcmlvcml0eSh1
bnNpZ25lZCBpbnQgaXJxLCB1bnNpZ25lZCBpbnQgcHJpb3JpdHkpOwordm9pZCBnaWNfYWNr
X2lycSh1bnNpZ25lZCBpbnQgaXJxKTsKK3ZvaWQgZ2ljX21hc2tfaXJxKHVuc2lnbmVkIGlu
dCBpcnEpOwordm9pZCBnaWNfdW5tYXNrX2lycSh1bnNpZ25lZCBpbnQgaXJxKTsKK3ZvaWQg
Z2ljX2VuZF9pcnEodW5zaWduZWQgaW50IGlycSk7Cit2b2lkIGdpY19jaGFuZ2VfaXJxX3N0
YXRlKHVuc2lnbmVkIGludCBpcnEsIHVuc2lnbmVkIGludCBzdGF0ZSk7CisKK2V4dGVybiB2
b2lkICpfZ2ljX2NwdV9iYXNlW05SX0NQVVNdOworZXh0ZXJuIHZvaWQgKl9naWNfZGlzdHJp
YnV0b3JfYmFzZTsKKyNlbmRpZgorI2VuZGlmCmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9p
bmNsdWRlL2FzbS1hcm0vaXJxLmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9pcnEuaAlT
dW4gRmViIDEyIDEyOjI0OjIxIDIwMTIgKzA5MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFy
bS9pcnEuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5MDAKQEAgLTE1LDYgKzE1LDcg
QEAKIAogI2RlZmluZSBpcnFfY2ZnKGlycSkJCSgmaXJxX2NmZ1tpcnFdKQogI2RlZmluZSBp
cnFfdG9fZGVzYyhpcnEpCSgmaXJxX2Rlc2NbaXJxXSkJCisjZGVmaW5lIGRlc2NfdG9faXJx
KGRlc2MpCSgoZGVzYyAtICZpcnFfZGVzY1swXSkgLyBzaXplb2Yoc3RydWN0IGlycV9kZXNj
KSk7CiAKICNkZWZpbmUgSVJRX01BWF9HVUVTVFMJCTcKIHR5cGVkZWYgc3RydWN0IHsKQEAg
LTQwLDggKzQxLDYgQEAgdHlwZWRlZiBzdHJ1Y3QgewogICAgIERFQ0xBUkVfQklUTUFQKF9i
aXRzLE5SX0lSUVMpOwogfSB2bWFza190OwogCi1leHRlcm4gc3RydWN0IGlycV9kZXNjICpp
cnFfZGVzYzsKLQogc3RhdGljIGlubGluZSBpbnQgaXJxX2Rlc2NfaW5pdGlhbGl6ZWQoc3Ry
dWN0IGlycV9kZXNjICpkZXNjKQogewogCXJldHVybiAwOwpkaWZmIC1yIDZhZjhhODljOTlj
ZCB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2F2cC5oCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVn
cmEvYXZwLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTQ0
IEBACisvKgorICogQ29weXJpZ2h0IChjKSAyMDEwIE5WSURJQSBDb3Jwb3JhdGlvbi4KKyAq
IEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp
biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmlj
YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp
dGlvbnMgYXJlIG1ldDoKKyAqCisgKiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUg
bXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UsCisgKiB0aGlzIGxpc3Qg
b2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICoKKyAqIFJl
ZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg
Y29weXJpZ2h0IG5vdGljZSwKKyAqIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg
Zm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlIGRvY3VtZW50YXRpb24KKyAqIGFuZC9vciBv
dGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAq
IE5laXRoZXIgdGhlIG5hbWUgb2YgdGhlIE5WSURJQSBDb3Jwb3JhdGlvbiBub3IgdGhlIG5h
bWVzIG9mIGl0cyBjb250cmlidXRvcnMKKyAqIG1heSBiZSB1c2VkIHRvIGVuZG9yc2Ugb3Ig
cHJvbW90ZSBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZQorICogd2l0aG91
dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24uCisgKgorICogVEhJUyBTT0ZU
V0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJV
VE9SUyAiQVMgSVMiCisgKiBBTkQgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVT
LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJB
TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg
UFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZ
UklHSFQgSE9MREVSIE9SIENPTlRSSUJVVE9SUyBCRQorICogTElBQkxFIEZPUiBBTlkgRElS
RUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICog
Q09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg
UFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg
T0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUworICogSU5URVJSVVBUSU9O
KSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRI
RVIgSU4KKyAqIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJ
TkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpCisgKiBBUklTSU5HIElOIEFOWSBXQVkgT1VU
IE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRQor
ICogUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisgKgorICovCisKKyNpZm5kZWYgSU5D
TFVERURfQVZQX0gKKyNkZWZpbmUgSU5DTFVERURfQVZQX0gKKworI2luY2x1ZGUgImFwMTUv
YXJpY3Rsci5oIgorI2luY2x1ZGUgImFwMTUvYXJ0aW1lci5oIgorLy8gRklYTUU6IGdldCB0
aGUgYXJhcm1ldiBoZWFkZXIKKworLy8gMyBjb250cm9sbGVycyBpbiBjb250aWd1b3VzIG1l
bW9yeSBzdGFydGluZyBhdCBJTlRFUlJVUFRfQkFTRSwgZWFjaAorLy8gY29udHJvbGxlcidz
IGFwZXJ0dXJlIGlzIElOVEVSUlVQVF9TSVpFIGxhcmdlCisjZGVmaW5lIElOVEVSUlVQVF9C
QVNFIDB4NjAwMDQwMDAKKyNkZWZpbmUgSU5URVJSVVBUX1NJWkUgMHgxMDAKKyNkZWZpbmUg
SU5URVJSVVBUX05VTV9DT05UUk9MTEVSUyAzCisKKyNkZWZpbmUgSU5URVJSVVBUX1BFTkRJ
TkcoIGN0bHIgKSBcCisgICAgKElOVEVSUlVQVF9CQVNFICsgKChjdGxyKSAqIElOVEVSUlVQ
VF9TSVpFKSArIElDVExSX1ZJUlFfQ09QXzApCisKKyNkZWZpbmUgSU5URVJSVVBUX1NFVCgg
Y3RsciApIFwKKyAgICAoSU5URVJSVVBUX0JBU0UgKyAoKGN0bHIpICogSU5URVJSVVBUX1NJ
WkUpICsgSUNUTFJfQ09QX0lFUl9TRVRfMCkKKworI2RlZmluZSBJTlRFUlJVUFRfQ0xSKCBj
dGxyICkgXAorICAgIChJTlRFUlJVUFRfQkFTRSArICgoY3RscikgKiBJTlRFUlJVUFRfU0la
RSkgKyBJQ1RMUl9DT1BfSUVSX0NMUl8wKQorCisjZGVmaW5lIE9TQ19DVFJMICAgICAgICAo
IDB4NjAwMDYwMDAgKyAweDUwICkKKyNkZWZpbmUgT1NDX0ZSRVFfREVUICAgICggMHg2MDAw
NjAwMCArIDB4NTggKQorI2RlZmluZSBPU0NfREVUX1NUQVRVUyAgKCAweDYwMDA2MDAwICsg
MHg1QyApCisKKyNkZWZpbmUgVElNRVJfVVNFQyAgICAgICggMHg2MDAwNTAxMCApCisjZGVm
aW5lIFRJTUVSX0NGRyAgICAgICAoIDB4NjAwMDUwMTQgKQorI2RlZmluZSBUSU1FUl8wX0JB
U0UgICAgKCAweDYwMDA1MDAwICkKKyNkZWZpbmUgVElNRVJfMCAgICAgICAgICggVElNRVJf
MF9CQVNFICsgVElNRVJfVE1SX1BUVl8wICkKKyNkZWZpbmUgVElNRVJfMF9DTEVBUiAgICgg
VElNRVJfMF9CQVNFICsgVElNRVJfVE1SX1BDUl8wICkKKyNkZWZpbmUgVElNRVJfMV9CQVNF
ICAgICggMHg2MDAwNTAwOCApCisjZGVmaW5lIFRJTUVSXzEgICAgICAgICAoIFRJTUVSXzFf
QkFTRSArIFRJTUVSX1RNUl9QVFZfMCApCisjZGVmaW5lIFRJTUVSXzFfQ0xFQVIgICAoIFRJ
TUVSXzFfQkFTRSArIFRJTUVSX1RNUl9QQ1JfMCApCisKKyNkZWZpbmUgQ0xPQ0tfUlNUX0xP
ICAgICgweDYwMDA2MDA0KQorI2RlZmluZSBDTE9DS19DVExSX0hJICAgKDB4NjAwMDYwMTQp
CisjZGVmaW5lIENMT0NLX0NUTFJfTE8gICAoMHg2MDAwNjAxMCkKKworI2RlZmluZSBDQUNI
RV9DVExSICAgICAgKDB4NjAwMEMwMDApCisjZGVmaW5lIENBQ0hFX0NPTlRST0xfMCAgICAg
ICAgICgweDApCisKKyNkZWZpbmUgUFBJX0lOVFJfSURfVElNRVJfMCAgICAgKDApCisjZGVm
aW5lIFBQSV9JTlRSX0lEX1RJTUVSXzEgICAgICgxKQorI2RlZmluZSBQUElfSU5UUl9JRF9U
SU1FUl8yICAgICAoOSkKKyNkZWZpbmUgUFBJX0lOVFJfSURfVElNRVJfMyAgICAgKDEwKQor
CisvKiBmbG93IGNvbnRyb2xsZXIgKi8KKyNkZWZpbmUgRkxPV19DT05UUk9MTEVSICAgICAo
MHg2MDAwNzAwNCkKKworLyogZXhjZXB0aW9uIHZlY3RvcnMgKi8KKyNkZWZpbmUgVkVDVE9S
X0JBU0UgICAgICAgICAgICAgKCAweDYwMDBGMjAwICkKKyNkZWZpbmUgVkVDVE9SX1JFU0VU
ICAgICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDAgKQorI2RlZmluZSBWRUNUT1JfVU5ERUYg
ICAgICAgICAgICAoIFZFQ1RPUl9CQVNFICsgNCApCisjZGVmaW5lIFZFQ1RPUl9TV0kgICAg
ICAgICAgICAgICggVkVDVE9SX0JBU0UgKyA4ICkKKyNkZWZpbmUgVkVDVE9SX1BSRUZFVENI
X0FCT1JUICAgKCBWRUNUT1JfQkFTRSArIDEyICkKKyNkZWZpbmUgVkVDVE9SX0RBVEFfQUJP
UlQgICAgICAgKCBWRUNUT1JfQkFTRSArIDE2ICkKKyNkZWZpbmUgVkVDVE9SX0lSUSAgICAg
ICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDI0ICkKKyNkZWZpbmUgVkVDVE9SX0ZJUSAgICAg
ICAgICAgICAgKCBWRUNUT1JfQkFTRSArIDI4ICkKKworI2RlZmluZSBNT0RFX0RJU0FCTEVf
SU5UUiAweGMwCisjZGVmaW5lIE1PREVfVVNSIDB4MTAKKyNkZWZpbmUgTU9ERV9GSVEgMHgx
MQorI2RlZmluZSBNT0RFX0lSUSAweDEyCisjZGVmaW5lIE1PREVfU1ZDIDB4MTMKKyNkZWZp
bmUgTU9ERV9BQlQgMHgxNworI2RlZmluZSBNT0RFX1VORCAweDFCCisjZGVmaW5lIE1PREVf
U1lTIDB4MUYKKworI2RlZmluZSBBUDE1X0NBQ0hFX0xJTkVfU0laRSAgICAgICAgICAgIDMy
CisKKyNkZWZpbmUgQVAxNV9BUEJfTDJfQ0FDSEVfQkFTRSAweDcwMDBlODAwIAorI2RlZmlu
ZSBBUDE1X0FQQl9DTEtfUlNUX0JBU0UgIDB4NjAwMDYwMDAKKyNkZWZpbmUgQVAxNV9BUEJf
TUlTQ19CQVNFICAgICAweDcwMDAwMDAwCisKKyNkZWZpbmUgQVAxMF9BUEJfQ0xLX1JTVF9C
QVNFICAweDYwMDA2MDAwCisjZGVmaW5lIEFQMTBfQVBCX01JU0NfQkFTRSAgICAgMHg3MDAw
MDAwMAorCisjZGVmaW5lIE1NVV9UTEJfQkFTRSAgICAgICAgICAgICAgMHhmMDAwZjAwMAor
I2RlZmluZSBNTVVfVExCX0NBQ0hFX1dJTkRPV18wICAgIDB4NDAKKyNkZWZpbmUgTU1VX1RM
Ql9DQUNIRV9PUFRJT05TXzAgICAweDQ0CisKKyNkZWZpbmUgQVAxNV9QSU5NVVhfQ0ZHX0NU
TF8wICAgMHg3MDAwMDAyNAorI2RlZmluZSBBUDE1X0FWUF9KVEFHX0VOQUJMRSAgICAweEMw
CisKKyNkZWZpbmUgUE1DX1NDUkFUQ0gyMl9SRUdfTFAwICAgMHg3MDAwZTRhOAorCisjZGVm
aW5lIEFWUF9XRFRfUkVTRVQgICAweDJGMDBCQUQwCisKKy8qIENhY2hlZCB0byB1bmNhY2hl
ZCBvZmZzZXQgZm9yIEFWUAorICoKKyAqIEhhcmR3YXJlIGhhcyB1bmNhY2hlZCByZW1hcCBh
cGVydHVyZSBmb3IgQVZQIGFzIEFWUCBkb2Vzbid0IGhhdmUgTU1VCisgKiBidXQgc3RpbGwg
aGFzIGNhY2hlIChuYW1lZCBDT1AgY2FjaGUpLgorICoKKyAqIFRoaXMgYXBlcnR1cmUgbW92
ZWQgYmV0d2VlbiBBUDE1IGFuZCBBUDIwLgorICovCisjZGVmaW5lIEFQMTVfQ0FDSEVEX1RP
X1VOQ0FDSEVEX09GRlNFVCAweDkwMDAwMDAwCisjZGVmaW5lIEFQMjBfQ0FDSEVEX1RPX1VO
Q0FDSEVEX09GRlNFVCAweDgwMDAwMDAwCisKKyNkZWZpbmUgQVBYWF9FWFRfTUVNX1NUQVJU
ICAgICAgMHgwMDAwMDAwMAorI2RlZmluZSBBUFhYX0VYVF9NRU1fRU5EICAgICAgICAweDQw
MDAwMDAwCisKKyNkZWZpbmUgQVBYWF9NTUlPX1NUQVJUICAgICAgICAgMHg0MDAwMDAwMAor
I2RlZmluZSBBUFhYX01NSU9fRU5EICAgICAgICAgICAweEZGRjAwMDAwCisKKyNkZWZpbmUg
VFhYX0VYVF9NRU1fU1RBUlQgICAgICAgMHg4MDAwMDAwMAorI2RlZmluZSBUWFhfRVhUX01F
TV9FTkQgICAgICAgICAweGMwMDAwMDAwCisKKyNkZWZpbmUgVFhYX01NSU9fU1RBUlQgICAg
ICAgICAgMHg0MDAwMDAwMAorI2RlZmluZSBUWFhfTU1JT19FTkQgICAgICAgICAgICAweDgw
MDAwMDAwCisKKyNlbmRpZgpkaWZmIC1yIDZhZjhhODljOTljZCB4ZW4vaW5jbHVkZS9hc20t
YXJtL3RlZ3JhL2NvbmZpZy5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvY29u
ZmlnLmgJU3VuIEZlYiAxMiAxMjoyNDoyMSAyMDEyICswOTAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS1hcm0vdGVncmEvY29uZmlnLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAw
CkBAIC0xLDExICsxLDYgQEAKICNpZm5kZWYgX19URUdSQV9DT05GSUdfSF9fCiAjZGVmaW5l
IF9fVEVHUkFfQ09ORklHX0hfXwogCi0jZGVmaW5lIEhaCTEwMAotI2RlZmluZSBDTE9DS19U
SUNLX1JBVEUJCTEwMDAwMDAKKyNkZWZpbmUgTUFYX1BIWVNfQ1BVUwkyCiAKLSNkZWZpbmUg
TUFYX1BIWVNfQ1BVUwkJMgotCi0jZGVmaW5lIEJVSUxUSU5fQ09NTUFORF9MSU5FX1NJWkUg
MjU2Ci0jZGVmaW5lIEJVSUxUSU5fQ09NTUFORF9MSU5FCSIiCiAjZW5kaWYKZGlmZiAtciA2
YWY4YTg5Yzk5Y2QgeGVuL2luY2x1ZGUvYXNtLWFybS90ZWdyYS9pcnFzLmgKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUv
YXNtLWFybS90ZWdyYS9pcnFzLmgJU3VuIEZlYiAxMiAxNTowNDowNiAyMDEyICswOTAwCkBA
IC0wLDAgKzEsNjAgQEAKKy8qCisgKiBhcmNoL2FybS9tYWNoLXRlZ3JhL2luY2x1ZGUvbWFj
aC9pcnFzLmgKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDksIE5WSURJQSBDb3Jwb3JhdGlv
bi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBG
cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vu
c2UsIG9yCisgKiAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLCBidXQgV0lUSE9VVAorICogQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g
dGhlIGltcGxpZWQgd2FycmFudHkgb2YgTUVSQ0hBTlRBQklMSVRZIG9yCisgKiBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UgZm9yCisgKiBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYWxv
bmcKKyAqIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4sCisgKiA1MSBGcmFua2xpbiBTdHJlZXQsIEZpZnRo
IEZsb29yLCBCb3N0b24sIE1BICAwMjExMC0xMzAxLCBVU0EuCisgKi8KKworI2lmbmRlZiBf
X1RFR1JBX0lSUVNfSAorI2RlZmluZSBfX1RFR1JBX0lSUVNfSAorCisjZGVmaW5lIE5SX0lS
UVMJCQk1MTIKKworI2RlZmluZSBJTlRfUFJJX0JBU0UJCTMyCisjZGVmaW5lIElOVF9SVEMJ
CQkoSU5UX1BSSV9CQVNFICsgMikKKyNkZWZpbmUgSU5UX1VTQgkJCShJTlRfUFJJX0JBU0Ug
KyAyMCkKKyNkZWZpbmUgSU5UX1VTQjIJCShJTlRfUFJJX0JBU0UgKyAyMSkKKyNkZWZpbmUg
SU5UX0FQQl9ETUEJCShJTlRfUFJJX0JBU0UgKyAyNikKKworI2RlZmluZSBJTlRfU0VDX0JB
U0UJCShJTlRfUFJJX0JBU0UgKyAzMikKKyNkZWZpbmUgSU5UX0dQSU8xCQkoSU5UX1NFQ19C
QVNFICsgMCkKKyNkZWZpbmUgSU5UX0dQSU8yCQkoSU5UX1NFQ19CQVNFICsgMSkKKyNkZWZp
bmUgSU5UX0dQSU8zCQkoSU5UX1NFQ19CQVNFICsgMikKKyNkZWZpbmUgSU5UX0dQSU80CQko
SU5UX1NFQ19CQVNFICsgMykKKyNkZWZpbmUgSU5UX1RNUjMJCShJTlRfU0VDX0JBU0UgKyA5
KQorI2RlZmluZSBJTlRfVE1SNAkJKElOVF9TRUNfQkFTRSArIDEwKQorI2RlZmluZSBJTlRf
U1lTX1NUQVRTX01PTgkoSU5UX1NFQ19CQVNFICsgMjIpCisjZGVmaW5lIElOVF9HUElPNQkJ
KElOVF9TRUNfQkFTRSArIDIzKQorCisjZGVmaW5lIElOVF9UUklfQkFTRQkJKElOVF9TRUNf
QkFTRSArIDMyKQorI2RlZmluZSBJTlRfS0JDCQkJKElOVF9UUklfQkFTRSArIDIxKQorI2Rl
ZmluZSBJTlRfRVhURVJOQUxfUE1VCShJTlRfVFJJX0JBU0UgKyAyMikKKyNkZWZpbmUgSU5U
X0dQSU82CQkoSU5UX1RSSV9CQVNFICsgMjMpCisjZGVmaW5lIElOVF9HUElPNwkJKElOVF9U
UklfQkFTRSArIDI1KQorCisjZGVmaW5lIElOVF9RVUFEX0JBU0UJCShJTlRfVFJJX0JBU0Ug
KyAzMikKKyNkZWZpbmUgSU5UX1VTQjMJCShJTlRfUVVBRF9CQVNFICsgMSkKKworI2RlZmlu
ZSBJTlRfR1BJT19CQVNFCQkoSU5UX1FVQURfQkFTRSArIDMyKQorI2RlZmluZSBJTlRfR1BJ
T19OUgkJKDI4KjgpCisKKyNkZWZpbmUgSU5UX0FQQkRNQV9CQVNFCSAJKElOVF9HUElPX0JB
U0UgKyBJTlRfR1BJT19OUikKKyNkZWZpbmUgSU5UX0FQQkRNQV9OUgkJKDE2KQorCisjZGVm
aW5lIElOVF9TWVNfTlIJKElOVF9HUElPX0JBU0UgLSBJTlRfUFJJX0JBU0UpCisjZGVmaW5l
IElOVF9TWVNfU1oJKElOVF9TRUNfQkFTRSAtIElOVF9QUklfQkFTRSkKKworI2VuZGlmCmRp
ZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvc21wLmgKLS0t
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2lu
Y2x1ZGUvYXNtLWFybS90ZWdyYS9zbXAuaAlTdW4gRmViIDEyIDE1OjA0OjA2IDIwMTIgKzA5
MDAKQEAgLTAsMCArMSw3IEBACisjaWZuZGVmIEFTTUFSTV9BUkNIX1NNUF9ICisjZGVmaW5l
IEFTTUFSTV9BUkNIX1NNUF9ICisKKworI2luY2x1ZGUgPGFzbS9naWMuaD4KKworI2VuZGlm
CmRpZmYgLXIgNmFmOGE4OWM5OWNkIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvdGVncmEu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL3RlZ3JhLmgJU3VuIEZlYiAxMiAxNTowNDowNiAy
MDEyICswOTAwCkBAIC0wLDAgKzEsNzUgQEAKKyNpZm5kZWYgX19URUdSQTI1MF9IX18KKyNk
ZWZpbmUgX19URUdSQTI1MF9IX18KKworI2RlZmluZSBURUdSQV9BUk1fQ1BVX0JBU0UJCTB4
NTAwMDAwMDAKKyNkZWZpbmUgVEVHUkFfUFBTQl9ERVZJQ0VfQkFTRQkJMHg2MDAwMDAwMAor
I2RlZmluZSBURUdSQV9BUEJfREVWSUNFX0JBU0UJCTB4NzAwMDAwMDAKKworI2RlZmluZSBU
RUdSQV9BUk1fUEVSSUZfQkFTRQkJMHg1MDA0MDAwMAorI2RlZmluZSBURUdSQV9BUk1fUEVS
SUZfU0laRQkJU1pfOEsKKworI2RlZmluZSBURUdSQV9TQ1VfQkFTRQkJCTB4NTAwNDAwMDAK
KyNkZWZpbmUgVEVHUkFfU0NVX1NJWkUJCQlTWl8yNTYKKworI2RlZmluZSBURUdSQV9HSUNf
UFJPQ19JRl9CQVNFCQkweDUwMDQwMTAwCisjZGVmaW5lIFRFR1JBX0dJQ19QUk9DX0lGX1NJ
WkUJCVNaXzI1NgorCisjZGVmaW5lIFRFR1JBX0FSTV9JTlRfRElTVF9CQVNFCQkweDUwMDQx
MDAwCisjZGVmaW5lIFRFR1JBX0FSTV9JTlRfRElTVF9TSVpFCQlTWl80SworCisjZGVmaW5l
IFRFR1JBX1BSSU1BUllfSUNUTFJfQkFTRQkweDYwMDA0MDAwCisjZGVmaW5lIFRFR1JBX1BS
SU1BUllfSUNUTFJfU0laRQlTWl82NAorCisjZGVmaW5lIFRFR1JBX1NFQ09OREFSWV9JQ1RM
Ul9CQVNFCTB4NjAwMDQxMDAKKyNkZWZpbmUgVEVHUkFfU0VDT05EQVJZX0lDVExSX1NJWkUJ
U1pfNjQKKworI2RlZmluZSBURUdSQV9URVJUSUFSWV9JQ1RMUl9CQVNFCTB4NjAwMDQyMDAK
KyNkZWZpbmUgVEVHUkFfVEVSVElBUllfSUNUTFJfU0laRQlTWl82NAorCisjZGVmaW5lIFRF
R1JBX1FVQVRFUk5BUllfSUNUTFJfQkFTRQkweDYwMDA0MzAwCisjZGVmaW5lIFRFR1JBX1FV
QVRFUk5BUllfSUNUTFJfU0laRQlTWl82NAorCisjZGVmaW5lIFRFR1JBX1RNUjFfQkFTRQkJ
CTB4NjAwMDUwMDAKKyNkZWZpbmUgVEVHUkFfVE1SMV9TSVpFCQkJU1pfOAorCisjZGVmaW5l
IFRFR1JBX1RNUjJfQkFTRQkJCTB4NjAwMDUwMDgKKyNkZWZpbmUgVEVHUkFfVE1SMl9TSVpF
CQkJU1pfOAorCisjZGVmaW5lIFRFR1JBX1RNUlVTX0JBU0UJCTB4NjAwMDUwMTAKKyNkZWZp
bmUgVEVHUkFfVE1SVVNfU0laRQkJU1pfNjQKKworI2RlZmluZSBURUdSQV9UTVIzX0JBU0UJ
CQkweDYwMDA1MDUwCisjZGVmaW5lIFRFR1JBX1RNUjNfU0laRQkJCVNaXzgKKworI2RlZmlu
ZSBURUdSQV9UTVI0X0JBU0UJCQkweDYwMDA1MDU4CisjZGVmaW5lIFRFR1JBX1RNUjRfU0la
RQkJCVNaXzgKKworI2RlZmluZSBURUdSQV9DTEtfUkVTRVRfQkFTRQkJMHg2MDAwNjAwMAor
I2RlZmluZSBURUdSQV9DTEtfUkVTRVRfU0laRQkJU1pfNEsKKworI2RlZmluZSBURUdSQV9G
TE9XX0NUUkxfQkFTRQkJMHg2MDAwNzAwMAorI2RlZmluZSBURUdSQV9GTE9XX0NUUkxfU0la
RQkJMjAKKworI2RlZmluZSBURUdSQV9HUElPX0JBU0UJCQkweDYwMDBEMDAwCisjZGVmaW5l
IFRFR1JBX0dQSU9fU0laRQkJCVNaXzRLCisKKyNkZWZpbmUgVEVHUkFfRVhDRVBUSU9OX1ZF
Q1RPUlNfQkFTRSAgICAweDYwMDBGMDAwCisjZGVmaW5lIFRFR1JBX0VYQ0VQVElPTl9WRUNU
T1JTX1NJWkUgICAgU1pfNEsKKworI2RlZmluZSBJQ1RMUl9DUFVfSUVSXzAJCQkoMHgyMCkK
KyNkZWZpbmUgSUNUTFJfQ1BVX0lFUl9TRVRfMAkJKDB4MjQpCisjZGVmaW5lIElDVExSX0NQ
VV9JRVJfQ0xSXzAJCSgweDI4KQorI2RlZmluZSBJQ1RMUl9DUFVfSUVQX0NMQVNTXzAJCSgw
eDJDKQorI2RlZmluZSBJQ1RMUl9DT1BfSUVSXzAJCQkoMHgzMCkKKyNkZWZpbmUgSUNUTFJf
Q09QX0lFUl9TRVRfMAkJKDB4MzQpCisjZGVmaW5lIElDVExSX0NPUF9JRVJfQ0xSXzAJCSgw
eDM4KQorI2RlZmluZSBJQ1RMUl9DT1BfSUVQX0NMQVNTXzAJCSgweDNDKQorCisjZGVmaW5l
IEFSTV9QRVJJRl9CQVNFCQkJKDB4NTAwNDAwMDApCisKKy8vI2RlZmluZSBJT19BRERSRVNT
KHgpCQkJKCgoKCh4KSAmIDB4NzAwMDAwMDApID4+IDgpICsgKCgoeCkgJiAweDBGMDAwMDAw
KSA+PiA0KSkgfCgoeCkgJiAweEZGRkZGKSB8IDB4RkIwMDAwMDAgKQorI2RlZmluZSBJT19B
RERSRVNTKHgpCQkJKCgoKHgpICYgMHhGMDAwMDAwMCkgPj4gOCkgfCAoKHgpICYgMHhGRkZG
RikgfCAoMHhGQjAwMDAwMCApKQorI2RlZmluZSBJTlRfUFBJX0FERFJFU1MoX2luc3QpCQko
MHg2MDAwNDAwMCArICgweDEwMCAqIChfaW5zdCkpKQorI2RlZmluZSBJTlRfQVBCRE1BX0FE
RFJFU1MJCSgweDYwMDBhMDAwKQorCisjZW5kaWYKZGlmZiAtciA2YWY4YTg5Yzk5Y2QgeGVu
L2luY2x1ZGUveGVuL2lycS5oCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi9pcnEuaAlTdW4gRmVi
IDEyIDEyOjI0OjIxIDIwMTIgKzA5MDAKKysrIGIveGVuL2luY2x1ZGUveGVuL2lycS5oCVN1
biBGZWIgMTIgMTU6MDQ6MDYgMjAxMiArMDkwMApAQCAtOTUsNiArOTUsMTAgQEAgaW50IGFy
Y2hfaW5pdF9vbmVfaXJxX2Rlc2Moc3RydWN0IGlycV9kZQogCiAjZGVmaW5lIGlycV9kZXNj
X2luaXRpYWxpemVkKGRlc2MpICgoZGVzYyktPmhhbmRsZXIgIT0gTlVMTCkKIAorI2lmIGRl
ZmluZWQoX19hcm1fXykKK2V4dGVybiBpcnFfZGVzY190IGlycV9kZXNjW05SX0lSUVNdOwor
I2VuZGlmCisKICNpZiBkZWZpbmVkKF9faWE2NF9fKQogZXh0ZXJuIGlycV9kZXNjX3QgaXJx
X2Rlc2NbTlJfVkVDVE9SU107CiAKQEAgLTEyMSw2ICsxMjUsOCBAQCBleHRlcm4gdm9pZCBp
cnFfYWN0b3Jfbm9uZShzdHJ1Y3QgaXJxX2RlCiAjZGVmaW5lIGlycV9zaHV0ZG93bl9ub25l
IGlycV9hY3Rvcl9ub25lCiAjZGVmaW5lIGlycV9kaXNhYmxlX25vbmUgaXJxX2FjdG9yX25v
bmUKICNkZWZpbmUgaXJxX2VuYWJsZV9ub25lIGlycV9hY3Rvcl9ub25lCisjZGVmaW5lIGly
cV9hY2tfbm9uZQlpcnFfYWN0b3Jfbm9uZQorI2RlZmluZSBpcnFfZW5kX25vbmUJaXJxX2Fj
dG9yX25vbmUKIAogc3RydWN0IGRvbWFpbjsKIHN0cnVjdCB2Y3B1Owo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt16-0005x5-2M; Mon, 13 Feb 2012 10:20:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqnP-0003HT-Bm
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:57:59 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329119871!14601060!1
X-Originating-IP: [203.254.224.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzMgPT4gMjQzNjYx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2145 invoked from network); 13 Feb 2012 07:57:51 -0000
Received: from mailout3.samsung.com (HELO mailout3.samsung.com)
	(203.254.224.33) by server-9.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:57:51 -0000
Received: from epcpsbge5.samsung.com (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00IENNDFJYB0@mailout3.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:57:43 +0900 (KST)
Message-id: <0LZB00IJVNG7JYB0@mailout3.samsung.com>
X-AuditID: cbfee60f-b7bd0ae00000422c-6d-4f38c2771377
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge5.samsung.com (EPCPMTA) with SMTP id BD.8F.16940.772C83F4;
	Mon, 13 Feb 2012 16:57:43 +0900 (KST)
Date: Mon, 13 Feb 2012 07:57:43 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075640084@jm77.ryu
Msgkey: 20120213075640084@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075537186@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 05/14] arm: implement exception and hypercall
	entries.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <6088535.69921329119859824.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgZXhjZXB0aW9uIGFuZCBoeXBlcmNhbGwgZW50cmllcy4NCg0KIHhlbi9h
cmNoL2FybS94ZW4vTWFrZWZpbGUgICAgICB8ICAgIDMgKw0KIHhlbi9hcmNoL2FybS94ZW4vYXNt
LW9mZnNldHMuYyB8ICAgNjEgKysrKysrKysNCiB4ZW4vYXJjaC9hcm0veGVuL2VudHJ5LlMgICAg
ICAgfCAgNTk2ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94
ZW4vaHlwZXJjYWxscy5TICB8ICAgNjcgKysrKysrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9waHlz
ZGV2LmMgICAgIHwgICA0MSArKysrKw0KIDUgZmlsZXMgY2hhbmdlZCwgNzY4IGluc2VydGlvbnMo
KyksIDAgZGVsZXRpb25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1
QHNhbXN1bmcuY29tPg0KDQpkaWZmIC1yIDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL01h
a2VmaWxlDQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCUZyaSBGZWIgMDMgMTc6Mjg6
MzQgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQlGcmkgRmViIDAz
IDE3OjQ3OjE2IDIwMTIgKzA5MDANCkBAIC0xLDUgKzEsOCBAQA0KIG9iai15ICs9IHN0YXJ0Lm8N
CiBvYmoteSArPSBzZXR1cC5vDQorb2JqLXkgKz0gZW50cnkubw0KK29iai15ICs9IGh5cGVyY2Fs
bHMubw0KK29iai15ICs9IHBoeXNkZXYubw0KIG9iai15ICs9IG1tLm8NCiBvYmoteSArPSBpcnEu
bw0KIG9iai15ICs9IGFyY2hfZG9tYWluLm8NCmRpZmYgLXIgMjhhNjAzOGRhOTlmIHhlbi9hcmNo
L2FybS94ZW4vYXNtLW9mZnNldHMuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9hc20tb2Zmc2V0
cy5jCUZyaSBGZWIgMDMgMTc6Mjg6MzQgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9hc20tb2Zmc2V0cy5jCUZyaSBGZWIgMDMgMTc6NDc6MTYgMjAxMiArMDkwMA0KQEAgLTM0LDYg
KzM0LDY3IEBADQogDQogaW50IG1haW4odm9pZCkNCiB7DQorCURFRklORShPRkZTRVRfU09GVElS
UV9QRU5ESU5HLAkJb2Zmc2V0b2Yoc3RydWN0IGlycV9jcHVzdGF0LCBfX3NvZnRpcnFfcGVuZGlu
ZykpOw0KKwlERUZJTkUoT0ZGU0VUX0xPQ0FMX0lSUV9DT1VOVCwJCW9mZnNldG9mKHN0cnVjdCBp
cnFfY3B1c3RhdCwgX19sb2NhbF9pcnFfY291bnQpKTsNCisJREVGSU5FKE9GRlNFVF9OTUlfQ09V
TlQsCQlvZmZzZXRvZihzdHJ1Y3QgaXJxX2NwdXN0YXQsIF9fbm1pX2NvdW50KSk7DQorCURFRklO
RShTSVpFX0lSUV9DUFVfU1RBVCwJCXNpemVvZihzdHJ1Y3QgaXJxX2NwdXN0YXQpKTsNCisJQkxB
TksoKTsNCisJREVGSU5FKE9GRlNFVF9WQ1BVX0lORk8sCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdSwg
dmNwdV9pbmZvKSk7DQorCURFRklORShPRkZTRVRfQVJDSF9WQ1BVLAkJb2Zmc2V0b2Yoc3RydWN0
IHZjcHUsIGFyY2gpKTsNCisJQkxBTksoKTsNCisJREVGSU5FKE9GRlNFVF9FVlRDSE5fVVBDQUxM
X01BU0ssCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2luZm8sIGV2dGNobl91cGNhbGxfbWFzaykpOw0K
KwlERUZJTkUoT0ZGU0VUX0VWVENITl9VUENBTExfUEVORElORywJb2Zmc2V0b2Yoc3RydWN0IHZj
cHVfaW5mbywgZXZ0Y2huX3VwY2FsbF9wZW5kaW5nKSk7DQorCURFRklORShPRkZTRVRfQVJDSF9W
Q1BVX0lORk8sCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9pbmZvLCBhcmNoKSk7DQorCURFRklORShP
RkZTRVRfVFNQLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3ZjcHVfaW5mbywgc3ApKTsNCisJREVG
SU5FKE9GRlNFVF9UTFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBscikpOw0K
KwlERUZJTkUoT0ZGU0VUX1RDUFNSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3ZjcHVfaW5mbywg
Y3BzcikpOw0KKwlERUZJTkUoT0ZGU0VUX1RTUFNSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3Zj
cHVfaW5mbywgc3BzcikpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUiwJCQlvZmZzZXRvZihzdHJ1Y3Qg
YXJjaF92Y3B1X2luZm8sIGNyKSk7DQorCURFRklORShPRkZTRVRfVkRBQ1IsCQkJb2Zmc2V0b2Yo
c3RydWN0IGFyY2hfdmNwdV9pbmZvLCBkYWNyKSk7DQorCURFRklORShPRkZTRVRfVkNQQVIsCQkJ
b2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBjcGFyKSk7DQorCURFRklORShPRkZTRVRf
VlBJRFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBwaWRyKSk7DQorCURFRklO
RShPRkZTRVRfVkZTUiwJCQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIGZzcikpOw0K
KwlERUZJTkUoT0ZGU0VUX1ZGQVIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBm
YXIpKTsNCisJQkxBTksoKTsNCisJREVGSU5FKE9GRlNFVF9HVUVTVF9DT05URVhULAkJb2Zmc2V0
b2Yoc3RydWN0IGFyY2hfdmNwdSwgY3R4KSk7DQorCURFRklORShPRkZTRVRfVkVDVE9SX1JFU0VU
LAkJMCk7DQorCURFRklORShPRkZTRVRfVkVDVE9SX1VORCwJCTQpOw0KKwlERUZJTkUoT0ZGU0VU
X1ZFQ1RPUl9TV0ksCQk4KTsNCisJREVGSU5FKE9GRlNFVF9WRUNUT1JfUEFCVCwJCTEyKTsNCisJ
REVGSU5FKE9GRlNFVF9WRUNUT1JfREFCVCwJCTE2KTsNCisJREVGSU5FKE9GRlNFVF9WRUNUT1Jf
SVJRLAkJMjQpOw0KKwlERUZJTkUoT0ZGU0VUX1ZFQ1RPUl9GSVEsCQkyOCk7DQorCUJMQU5LKCk7
DQorCURFRklORShPRkZTRVRfVkNQVSwJCQlvZmZzZXRvZihzdHJ1Y3QgY3B1X2luZm8sIHZjcHUp
KTsNCisJREVGSU5FKE9GRlNFVF9WUFNSLAkJCW9mZnNldG9mKHN0cnVjdCBjcHVfaW5mbywgdnNw
c3IpKTsNCisJREVGSU5FKE9GRlNFVF9WU1AsCQkJb2Zmc2V0b2Yoc3RydWN0IGNwdV9pbmZvLCB2
c3ApKTsNCisJREVGSU5FKE9GRlNFVF9WTFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGNwdV9pbmZvLCB2
bHIpKTsNCisJQkxBTksoKTsNCisJREVGSU5FKE9GRlNFVF9WQ1BVX1IwLAkJCW9mZnNldG9mKHN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHIwKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SMSwJ
CQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCByMSkpOw0KKwlERUZJTkUoT0ZG
U0VUX1ZDUFVfUjIsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjIpKTsN
CisJREVGSU5FKE9GRlNFVF9WQ1BVX1IzLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQsIHIzKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SNCwJCQlvZmZzZXRvZihzdHJ1Y3Qg
dmNwdV9ndWVzdF9jb250ZXh0LCByNCkpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjUsCQkJb2Zm
c2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjUpKTsNCisJREVGSU5FKE9GRlNFVF9W
Q1BVX1I2LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI2KSk7DQorCURF
RklORShPRkZTRVRfVkNQVV9SNywJCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0
LCByNykpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjgsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVf
Z3Vlc3RfY29udGV4dCwgcjgpKTsNCisJREVGSU5FKE9GRlNFVF9WQ1BVX1I5LAkJCW9mZnNldG9m
KHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI5KSk7DQorCURFRklORShPRkZTRVRfVkNQVV9S
MTAsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjEwKSk7DQorCURFRklO
RShPRkZTRVRfVkNQVV9SMTEsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwg
cjExKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SMTIsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVf
Z3Vlc3RfY29udGV4dCwgcjEyKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SMTMsCQkJb2Zmc2V0
b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjEzKSk7DQorCURFRklORShPRkZTRVRfVkNQ
VV9SMTQsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjE0KSk7DQorCURF
RklORShPRkZTRVRfVkNQVV9SMTUsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4
dCwgcjE1KSk7DQorCURFRklORShPRkZTRVRfVkNQVV9EQUNSLAkJb2Zmc2V0b2Yoc3RydWN0IHZj
cHVfZ3Vlc3RfY29udGV4dCwgZGFjcikpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfVkJBUiwJCW9m
ZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHZiYXIpKTsNCisJREVGSU5FKE9GRlNF
VF9WQ1BVX0NPTlRFWFRJRFIsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBj
b250ZXh0aWRyKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9GQ1NFSURSLAkJb2Zmc2V0b2Yoc3Ry
dWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgZmNzZWlkcikpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVf
VFRCUjAsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCB0dGJyMCkpOw0KKwlE
RUZJTkUoT0ZGU0VUX1ZDUFVfVFRCUjEsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250
ZXh0LCB0dGJyMSkpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfVFRCQ1IsCQlvZmZzZXRvZihzdHJ1
Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCB0dGJjcikpOw0KKwkvL0RFRklORShPRkZTRVRfSFlQRVJW
SVNPUl9DQUxMQkFDSywJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgZXZlbnRf
Y2FsbGJhY2spKTsNCisJLy9ERUZJTkUoT0ZGU0VUX0ZBSUxTQUZFX0NBTExCQUNLLAlvZmZzZXRv
ZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBmYWlsc2FmZV9jYWxsYmFjaykpOw0KIAlCTEFO
SygpOw0KIA0KIAlyZXR1cm4gMDsgDQpkaWZmIC1yIDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0v
eGVuL2VudHJ5LlMNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
DQorKysgYi94ZW4vYXJjaC9hcm0veGVuL2VudHJ5LlMJRnJpIEZlYiAwMyAxNzo0NzoxNiAyMDEy
ICswOTAwDQpAQCAtMCwwICsxLDU5NiBAQA0KKy8qDQorICogZW50cnkuUw0KKyAqDQorICogQ29w
eXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcw0KKyAqICAgICAgICAgIFNh
bmctYnVtIFN1aCA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+DQorICogICAgICAgICAgSmFlTWluIFJ5
dSAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExp
Y2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4N
CisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0
IHdpbGwgYmUgdXNlZnVsLA0KKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5F
U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUg
cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFs
b25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJl
DQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3Rv
biwgTUEgIDAyMTExLTEzMDcgIFVTQQ0KKyAqLw0KKyNpbmNsdWRlIDxhc20vcHJvY2Vzc29yLmg+
DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5j
bHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1kb21haW4uaD4NCisj
aW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQorI2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5o
Pg0KKw0KKy5tYWNybyBTQVZFX0NPTlRFWFQJIG9mZnNldCBjb3JyZWN0aW9uDQorCXN1YiAgICAg
bHIsIGxyLCAjXGNvcnJlY3Rpb24NCisJc3RyICAgICByMCwgW3NwLCAjLTE2XQ0KKwlzdHIgICAg
IGxyLCBbc3AsICMtMTJdDQorDQorCW1ycyAgICAgcjAsIHNwc3INCisJbW92ICAgICBsciwgI1xv
ZmZzZXQNCisJc3RyICAgICByMCwgW3NwLCAjLThdDQorCXN0ciAgICAgbHIsIFtzcCwgIy00XQ0K
Kw0KKwlzdWIgICAgIHIwLCBzcCwgIzE2DQorDQorCW1zciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9J
X0JJVCB8IFBTUl9GX0JJVCB8IFBTUl9NT0RFX1NWQykNCisNCisJc3ViCXNwLCBzcCwgI0NUWFRf
RlJBTUVfU0laRQ0KK1NQRklYKAl0c3QJc3AsICM0CQkpDQorU1BGSVgoCWJpY25lCXNwLCBzcCwg
IzQJKQ0KKwlzdG1pYglzcCwge3IxIC0gbHJ9Xg0KKwlsZG1pYQlyMCwge3IxIC0gcjR9DQorCWFk
ZAlyNSwgc3AsICNDVFhUX1NTUA0KKwlhZGQJcjAsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFDQorU1BG
SVgoCWFkZG5lCXIwLCByMCwgIzQJKQ0KKwlzdHIJcjEsIFtzcF0NCisJbW92CXIxLCBscg0KKwlz
dG1pYQlyNSwge3IwIC0gcjR9DQorCW1zcglzcHNyX2N4c2YsIHIzDQorLmVuZG0NCisNCisubWFj
cm8gUkVTVE9SRV9DT05URVhUDQorCWxkcglyMCwgW3NwLCAjQ1RYVF9TUFNSXQ0KKwltc3IJc3Bz
cl9jeHNmLCByMA0KKwlsZG1pYQlzcCwge3IwIC0gbHJ9Xg0KKwlhZGQJc3AsIHNwLCAjQ1RYVF9T
U1ANCisJbGRtaWEJc3AsIHtzcCwgbHIsIHBjfV4NCisuZW5kbQ0KKw0KKwkuYWxpZ24JNQ0KKwku
Z2xvYmFsIGV4Y2VwdGlvbl92ZWN0b3JfdGFibGUNCitleGNlcHRpb25fdmVjdG9yX3RhYmxlOg0K
KwlsZHIJcGMsIC5yc3QNCisJbGRyCXBjLCAudW5kDQorCWxkcglwYywgLnN3aQ0KKwlsZHIJcGMs
IC5wYWJ0DQorCWxkcglwYywgLmRhYnQNCisJbGRyCXBjLCAuYWR4DQorCWxkcglwYywgLmlycQ0K
KwlsZHIJcGMsIC5maXENCisNCisucnN0OgkubG9uZwl2ZWN0b3JfcmVzZXQNCisudW5kOgkubG9u
Zwl2ZWN0b3JfdW5kDQorLnN3aToJLmxvbmcJdmVjdG9yX3N3aQ0KKy5wYWJ0OgkubG9uZwl2ZWN0
b3JfcGFidA0KKy5kYWJ0OgkubG9uZwl2ZWN0b3JfZGFidA0KKy5hZHg6CS5sb25nCXZlY3Rvcl9y
ZXNlcnZlZA0KKy5pcnE6CS5sb25nCXZlY3Rvcl9pcnENCisuZmlxOgkubG9uZwl2ZWN0b3JfZmlx
DQorDQorCS5hbGlnbgk1DQordmVjdG9yX3Jlc2V0Og0KKzE6DQorCWIJMWINCisNCisJLmFsaWdu
CTUNCit2ZWN0b3JfaXJxOg0KKwlTQVZFX0NPTlRFWFQJMHgxOCwgNA0KKw0KKwltcnMJcjAsIHNw
c3INCisJYW5kCXIwLCByMCwgI1BTUl9NT0RFX01BU0sNCisJZW9ycwlyMCwgcjAsICNQU1JfTU9E
RV9TVkMNCisNCisJYm5lCXJldHVybl90b19ndWVzdA0KKw0KKwljcHNpZAlpDQorDQorCVJFU1RP
UkVfQ09OVEVYVA0KKw0KKwkuYWxpZ24JNQ0KK3ZlY3Rvcl9kYWJ0Og0KKwlzdHIJcjAsIFtzcCwg
Iy0xNl0NCisJc3RyCWxyLCBbc3AsICMtMTJdDQorCW1ycyAgICAgcjAsIHNwc3INCisJc3RyICAg
ICByMCwgW3NwLCAjLThdDQorCXN1YiAgICAgcjAsIHNwLCAjMTYNCisNCisJbXNyICAgICBjcHNy
X2N4c2YsICMoUFNSX0lfQklUIHwgUFNSX0ZfQklUIHwgUFNSX01PREVfU1ZDKQ0KKw0KKwlzdWIg
ICAgIHNwLCBzcCwgI0NUWFRfRlJBTUVfU0laRQ0KK1NQRklYKCAgdHN0ICAgICBzcCwgIzQgICAg
ICApDQorU1BGSVgoICBiaWNuZSAgIHNwLCBzcCwgIzQgICkNCisJc3RtaWIgICBzcCwge3IxIC0g
bHJ9Xg0KKwlsZG1pYSAgIHIwLCB7cjEgLSByM30NCisJYWRkICAgICByNSwgc3AsICNDVFhUX1NT
UA0KKwlhZGQgICAgIHIwLCBzcCwgI0NUWFRfRlJBTUVfU0laRQ0KK1NQRklYKCAgYWRkbmUgICBy
MCwgcjAsICM0ICApDQorCXN0ciAgICAgcjEsIFtzcF0NCisJbW92ICAgICByMSwgbHINCisJc3Rt
aWEgICByNSwge3IwIC0gcjN9DQorDQorCW1yYyAgICAgcDE1LCAwLCByMCwgYzYsIGMwLCAwDQor
CW1yYyAgICAgcDE1LCAwLCByMSwgYzUsIGMwLCAwDQorDQorCWFuZAlyNCwgcjMsICNQU1JfTU9E
RV9NQVNLDQorCWVvcnMJcjQsIHI0LCAjUFNSX01PREVfU1ZDDQorDQorCWJlcQlkb19kYXRhX2Fi
b3J0DQorDQorCWNwc2llCWkNCisJCQ0KKwljY2kgICAgIHI4DQorCWxkciAgICAgcjksIFtyOF0N
CisNCisJbGRyICAgICByMTAsIFtyOSwgI09GRlNFVF9WQ1BVX0lORk8gXQ0KKwlsZHIgICAgIHIx
NCwgW3I5LCAjKE9GRlNFVF9BUkNIX1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNF
VF9WQ1BVX1ZCQVIpXQ0KKwljbXAgICAgIHIxNCwgIzANCisJYmVxICAgICB0cmFwX3RhYmxlX2lu
dmFsaWQNCisNCisJYWRkCXIxNCwgcjE0LCAjT0ZGU0VUX1ZFQ1RPUl9EQUJUDQorDQorCXN0ciAg
ICAgcjAsIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1ZGQVIpXQ0KKwlz
dHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9WRlNSKV0N
CisNCisJQCBGb2xsb3dpbmcgaXMgYWRkZWQgdG8gbWl4IGV2dGNobiB1cGNhbGwgbWFzayBhbmQg
cHNyDQorCWxkcglyNCwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQ
U1IpXQ0KKw0KKwlvcnIJcjksIHI0LCAjVlBTUl9JX0JJVA0KKwlzdHIJcjksIFtyMTAsICMoT0ZG
U0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJbGRyICAgICByMCwgW3Nw
LCAjQ1RYVF9VU1BdDQorCWxkciAgICAgcjEsIFtzcCwgI0NUWFRfVUxSXQ0KKw0KKwlsZHIgICAg
IHI1LCBbcjgsICNPRkZTRVRfVlBTUl0NCisJYmljICAgICByMywgcjMsICNQU1JfTU9ERV9NQVNL
DQorCW9yciAgICAgcjMsIHIzLCByNQ0KKw0KKwl0c3QJcjQsICNWUFNSX0lfQklUDQorCW9ycm5l
CXIzLCByMywgI1BTUl9JX0JJVA0KKw0KKwlzdHIgICAgIHIwLCBbcjEwLCAjKE9GRlNFVF9BUkNI
X1ZDUFVfSU5GTyArIE9GRlNFVF9UU1ApXQ0KKwlzdHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQ0KKwlzdHIgICAgIHIzLCBbcjEwLCAjKE9GRlNF
VF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1BTUildDQorDQorCWNtcCAgICAgcjUsICNQU1Jf
TU9ERV9TVkMNCisJbGRybmUgICByMCwgW3I4LCAjOF0NCisNCisJbW92ICAgICByNSwgI1BTUl9N
T0RFX1NWQw0KKwlzdHIgICAgIHI1LCBbcjgsICM0XQ0KKwlzdHIgICAgIHIwLCBbcjgsICM4XQ0K
KwlzdHIgICAgIHIyLCBbcjgsICMxMl0NCisNCisJbGRyICAgICByNSwgPURBQ1JfU1RBVF9TVkMN
CisJbWNyICAgICBwMTUsIDAsIHI1LCBjMywgYzAsIDANCisNCisJY3BzaWQJaQ0KKw0KKwlhZGQg
ICAgIHI4LCByOCwgIzgNCisJbGRtaWEgICByOCwge3IxMywgcjE0fV4NCisJbGRtaWEgICBzcCwg
e3IwLXIxMn0NCisJbGRyICAgICBzcCwgW3NwLCAjQ1RYVF9TU1BdDQorCW1zciAgICAgc3Bzciwg
I1BTUl9NT0RFX1VTUg0KKwltb3ZzICAgIHBjLCBscg0KKw0KKwkuYWxpZ24JNQ0KK3ZlY3Rvcl9w
YWJ0Og0KKwlzdHIgICAgIHIwLCBbc3AsICMtMTZdDQorCXN0ciAgICAgbHIsIFtzcCwgIy0xMl0N
CisJbXJzICAgICByMCwgc3Bzcg0KKwlzdHIgICAgIHIwLCBbc3AsICMtOF0NCisJc3ViICAgICBy
MCwgc3AsICMxNg0KKw0KKwltc3IgICAgIGNwc3JfY3hzZiwgIyhQU1JfSV9CSVQgfCBQU1JfRl9C
SVQgfCBQU1JfTU9ERV9TVkMpDQorDQorCXN1YiAgICAgc3AsIHNwLCAjQ1RYVF9GUkFNRV9TSVpF
DQorU1BGSVgoICB0c3QgICAgIHNwLCAjNCAgICAgICkNCitTUEZJWCggIGJpY25lICAgc3AsIHNw
LCAjNCAgKQ0KKwlzdG1pYiAgIHNwLCB7cjEgLSBscn1eDQorCWxkbWlhICAgcjAsIHtyMSAtIHIz
fQ0KKwlhZGQgICAgIHI1LCBzcCwgI0NUWFRfU1NQDQorCWFkZCAgICAgcjAsIHNwLCAjQ1RYVF9G
UkFNRV9TSVpFDQorU1BGSVgoICBhZGRuZSAgIHIwLCByMCwgIzQgICkNCisJc3RyICAgICByMSwg
W3NwXQ0KKwltb3YgICAgIHIxLCBscg0KKwlzdG1pYSAgIHI1LCB7cjAgLSByM30NCisNCisJbXJj
ICAgICBwMTUsIDAsIHIwLCBjNiwgYzAsIDANCisJbXJjICAgICBwMTUsIDAsIHIxLCBjNSwgYzAs
IDANCisNCisJYW5kICAgICByNCwgcjMsICNQU1JfTU9ERV9NQVNLDQorCWVvcnMgICAgcjQsIHI0
LCAjUFNSX01PREVfU1ZDDQorDQorCWJlcQlkb19wcmVmZXRjaF9hYm9ydA0KKw0KKwljcHNpZQlp
CQkNCisNCisJY2NpICAgICByOA0KKwlsZHIgICAgIHI5LCBbcjhdDQorDQorCWxkciAgICAgcjEw
LCBbcjksICNPRkZTRVRfVkNQVV9JTkZPXQ0KKwlsZHIgICAgIHIxNCwgW3I5LCAjKE9GRlNFVF9B
UkNIX1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNFVF9WQ1BVX1ZCQVIpXQ0KKwlj
bXAgICAgIGxyLCAjMA0KKwliZXEgICAgIHRyYXBfdGFibGVfaW52YWxpZA0KKw0KKwlhZGQJcjE0
LCByMTQsICNPRkZTRVRfVkVDVE9SX1BBQlQNCisNCisJbGRyCXI0LCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildDQorDQorCW9ycglyOSwgcjQsICNWUFNSX0lf
QklUDQorCXN0cglyOSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQ
U1IpXQ0KKw0KKwlsZHIgICAgIHIwLCBbc3AsICNDVFhUX1VTUF0NCisJbGRyICAgICByMSwgW3Nw
LCAjQ1RYVF9VTFJdDQorDQorCWxkciAgICAgcjUsIFtyOCwgIzRdDQorCWJpYyAgICAgcjMsIHIz
LCAjUFNSX01PREVfTUFTSw0KKwlvcnIgICAgIHIzLCByMywgcjUNCisNCisJdHN0CXI0LCAjVlBT
Ul9JX0JJVA0KKwlvcnJuZQlyMywgcjMsICNQU1JfSV9CSVQNCisNCisJc3RyICAgICByMCwgW3Ix
MCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0NCisJc3RyICAgICByMSwg
W3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVExSKV0NCisJc3RyICAgICBy
MywgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQU1IpXQ0KKw0KKwlj
bXAgICAgIHI1LCAjUFNSX01PREVfU1ZDDQorCWxkcm5lICAgcjAsIFtyOCwgIzhdDQorDQorCW1v
diAgICAgcjUsICNQU1JfTU9ERV9TVkMNCisJc3RyICAgICByNSwgW3I4LCAjNF0NCisJc3RyICAg
ICByMCwgW3I4LCAjOF0NCisJc3RyICAgICByMiwgW3I4LCAjMTJdDQorDQorCWxkciAgICAgcjUs
ID1EQUNSX1NUQVRfU1ZDDQorCW1jciAgICAgcDE1LCAwLCByNSwgYzMsIGMwLCAwDQorDQorCWNw
c2lkCWkNCisNCisJYWRkICAgICByOCwgcjgsICM4DQorCWxkbWlhICAgcjgsIHtyMTMsIHIxNH1e
DQorCWxkbWlhICAgc3AsIHtyMC1yMTJ9DQorCWxkciAgICAgc3AsIFtzcCwgI0NUWFRfU1NQXQ0K
Kwltc3IgICAgIHNwc3IsICNQU1JfTU9ERV9VU1INCisJbW92cyAgICBwYywgbHINCisNCisJLmFs
aWduCTUNCit2ZWN0b3JfdW5kOg0KKwlzdHIgICAgIHIwLCBbc3AsICMtMTZdDQorCXN0ciAgICAg
bHIsIFtzcCwgIy0xMl0NCisJbXJzICAgICByMCwgc3Bzcg0KKwlzdHIgICAgIHIwLCBbc3AsICMt
OF0NCisJc3ViICAgICByMCwgc3AsICMxNg0KKw0KKwltc3IgICAgIGNwc3JfY3hzZiwgIyhQU1Jf
SV9CSVQgfCBQU1JfRl9CSVQgfCBQU1JfTU9ERV9TVkMpDQorDQorCXN1YiAgICAgc3AsIHNwLCAj
Q1RYVF9GUkFNRV9TSVpFDQorU1BGSVgoICB0c3QgICAgIHNwLCAjNCAgICAgICkNCitTUEZJWCgg
IGJpY25lICAgc3AsIHNwLCAjNCAgKQ0KKwlzdG1pYiAgIHNwLCB7cjEgLSBscn1eDQorCWxkbWlh
ICAgcjAsIHtyMSAtIHIzfQ0KKwlhZGQgICAgIHI1LCBzcCwgI0NUWFRfU1NQDQorCWFkZCAgICAg
cjAsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFDQorU1BGSVgoICBhZGRuZSAgIHIwLCByMCwgIzQgICkN
CisJc3RyICAgICByMSwgW3NwXQ0KKwltb3YgICAgIHIxLCBscg0KKwlzdG1pYSAgIHI1LCB7cjAg
LSByM30NCisNCisJYW5kICAgICByNCwgcjMsICNQU1JfTU9ERV9NQVNLDQorCWVvcnMgICAgcjQs
IHI0LCAjUFNSX01PREVfU1ZDDQorDQorCWJlcSAgICAgZG9fdW5kZWZpbmVkX2luc3RydWN0aW9u
DQorDQorCWNwc2llCWkNCisNCisJY2NpICAgICByOA0KKwlsZHIgICAgIHI5LCBbcjhdDQorDQor
CWxkciAgICAgcjEwLCBbcjksICNPRkZTRVRfVkNQVV9JTkZPXQ0KKwlsZHIgICAgIHIxNCwgW3I5
LCAjKE9GRlNFVF9BUkNIX1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNFVF9WQ1BV
X1ZCQVIpXQ0KKwljbXAgICAgIGxyLCAjMA0KKwliZXEgICAgIHRyYXBfdGFibGVfaW52YWxpZA0K
Kw0KKwlhZGQJcjE0LCByMTQsICNPRkZTRVRfVkVDVE9SX1VORA0KKw0KKwlsZHIJcjQsIFtyMTAs
ICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJb3JyCXI5LCBy
NCwgI1ZQU1JfSV9CSVQNCisJc3RyCXI5LCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyAr
IE9GRlNFVF9UQ1BTUildDQorDQorCWxkciAgICAgcjAsIFtzcCwgI0NUWFRfVVNQXQ0KKwlsZHIg
ICAgIHIxLCBbc3AsICNDVFhUX1VMUl0NCisNCisJbGRyICAgICByNSwgW3I4LCAjNF0NCisJYmlj
ICAgICByMywgcjMsICNQU1JfTU9ERV9NQVNLDQorCW9yciAgICAgcjMsIHIzLCByNQ0KKw0KKwl0
c3QJcjQsICNWUFNSX0lfQklUDQorCW9ycm5lCXIzLCByMywgI1BTUl9JX0JJVA0KKw0KKwlzdHIg
ICAgIHIwLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1ApXQ0KKwlz
dHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQ0K
KwlzdHIgICAgIHIzLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1BT
UildDQorDQorCWNtcCAgICAgcjUsICNQU1JfTU9ERV9TVkMNCisJbGRybmUgICByMCwgW3I4LCAj
OF0NCisNCisJbW92ICAgICByNSwgI1BTUl9NT0RFX1NWQw0KKwlzdHIgICAgIHI1LCBbcjgsICM0
XQ0KKwlzdHIgICAgIHIwLCBbcjgsICM4XQ0KKwlzdHIgICAgIHIyLCBbcjgsICMxMl0NCisJc3Ry
ICAgICByMSwgW3I4LCAjMTZdDQorDQorCWxkciAgICAgcjUsID1EQUNSX1NUQVRfU1ZDDQorCW1j
ciAgICAgcDE1LCAwLCByNSwgYzMsIGMwLCAwDQorDQorCWNwc2lkCWkNCisNCisJYWRkICAgICBy
OCwgcjgsICM4DQorCWxkbWlhICAgcjgsIHtyMTMsIHIxNH1eDQorCWxkbWlhICAgc3AsIHtyMC1y
MTJ9DQorCWxkciAgICAgc3AsIFtzcCwgI0NUWFRfU1NQXQ0KKwltc3IgICAgIHNwc3IsICNQU1Jf
TU9ERV9VU1INCisJbW92cyAgICBwYywgbHINCisNCisJLmFsaWduCTUNCit2ZWN0b3JfZmlxOg0K
KwlzdWJzICAgIHBjLCBsciwgIzQNCisNCisJLmFsaWduCTUNCit2ZWN0b3JfcmVzZXJ2ZWQ6DQor
CWIJdmVjdG9yX3Jlc2VydmVkDQorDQorCS5hbGlnbgk1DQordHJhcF90YWJsZV9pbnZhbGlkOg0K
KwliCXRyYXBfdGFibGVfaW52YWxpZA0KKw0KKwkuYWxpZ24JNQ0KK3ZlY3Rvcl9zd2k6DQorCXN0
cglzcCwgW3NwLCAjKENUWFRfU1NQIC0gQ1RYVF9GUkFNRV9TSVpFKV0NCisJc3ViICAgICBzcCwg
c3AsICNDVFhUX0ZSQU1FX1NJWkUNCisJc3RtaWEgICBzcCwge3IwIC0gbHJ9Xg0KKwltcnMgICAg
IHIxMSwgc3Bzcg0KKwlzdHIgICAgIHIxNCwgW3NwLCAjQ1RYVF9QQ10NCisJc3RyICAgICByMTEs
IFtzcCwgI0NUWFRfU1BTUl0NCisNCisJY3BzaWUJaQ0KKw0KKwljY2kJcjgNCisJbGRyCXIxMiwg
W3I4LCAjNF0NCisJZW9ycwlyMTIsIHIxMiwgI1BTUl9NT0RFX1NWQw0KKw0KKwliZXEJaW52b2tl
X2h5cGVyY2FsbA0KKwkJDQorCW1vdglyMTIsICNQU1JfTU9ERV9TVkMNCisJc3RyICAgICByMTIs
IFtyOCwgIzRdDQorCXN0ciAgICAgcjE0LCBbcjgsICMxMl0NCisNCisJbGRyICAgICByOSwgW3I4
XQ0KKwlsZHIgICAgIHIxMCwgW3I5LCAjT0ZGU0VUX1ZDUFVfSU5GT10NCisJbGRyICAgICByMTQs
IFtyOSwgIyhPRkZTRVRfQVJDSF9WQ1BVICsgT0ZGU0VUX0dVRVNUX0NPTlRFWFQgKyBPRkZTRVRf
VkNQVV9WQkFSKV0NCisJY21wICAgICByMTQsICMwDQorCWJlcQl0cmFwX3RhYmxlX2ludmFsaWQN
CisNCisJYWRkCXIxNCwgcjE0LCAjT0ZGU0VUX1ZFQ1RPUl9TV0kNCisNCisJbGRyCXI0LCBbcjEw
LCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildDQorDQorCW9ycglyOSwg
cjQsICNWUFNSX0lfQklUDQorCXN0cglyOSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8g
KyBPRkZTRVRfVENQU1IpXQ0KKw0KKwl0c3QJcjQsICNWUFNSX0lfQklUDQorCW9ycm5lCXIxMSwg
cjExLCAjUFNSX0lfQklUDQorDQorCWxkciAgICAgcjQsIFtzcCwgI0NUWFRfVVNQXQ0KKwlsZHIg
ICAgIHI1LCBbc3AsICNDVFhUX1VMUl0NCisNCisJc3RyICAgICByNCwgW3IxMCwgIyhPRkZTRVRf
QVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0NCisJc3RyICAgICByNSwgW3IxMCwgIyhPRkZT
RVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVExSKV0NCisJc3RyICAgICByMTEsIFtyMTAsICMo
T0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0NCisNCisJbGRyICAgICByMTEs
ID1EQUNSX1NUQVRfU1ZDDQorCW1jciAgICAgcDE1LCAwLCByMTEsIGMzLCBjMCwgMA0KKw0KKwlj
cHNpZAlpDQorDQorCWFkZCAgICAgcjgsIHI4LCAjOA0KKwlsZG1pYSAgIHI4LCB7cjEzLCByMTR9
Xg0KKwlsZG1pYSAgIHNwLCB7cjAtcjEyfQ0KKwlsZHIgICAgIHNwLCBbc3AsICNDVFhUX1NTUF0N
CisJbXNyICAgICBzcHNyLCAjUFNSX01PREVfVVNSDQorCW1vdnMgICAgcGMsIGxyDQorDQoraW52
b2tlX2h5cGVyY2FsbDoNCisJbGRyICAgICByMTIsIFtsciwgIy00XQ0KKwliaWMgICAgIHIxMiwg
cjEyLCAjMHhmZjAwMDAwMA0KKw0KKwlhZHIgICAgIHIxNCwgMWYNCisJYWRyICAgICByMTEsIGh5
cGVyY2FsbF90YWJsZQ0KKwlsZHIgICAgIHBjLCBbcjExLCByMTIsIGxzbCAjMl0NCisNCisxOg0K
KwlzdHIgICAgIHIwLCBbc3AsICNDVFhUX1IwXQ0KKw0KKwliCXJldHVybl90b19ndWVzdA0KKw0K
K0VOVFJZKHJldHVybl90b19ndWVzdCkJDQorCWNwc2llCWkNCisJYmwJZG9fc29mdGlycQ0KKw0K
KwljY2kJcjgNCisJbGRyCXIxMCwgW3I4LCAjT0ZGU0VUX1ZDUFVdDQorDQorCWxkcglyMTEsIFty
MTAsICNPRkZTRVRfVkNQVV9JTkZPXQ0KKwlsZHIJcjksIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQ
VV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJdHN0CXI5LCAjVlBTUl9JX0JJVA0KKwlibmUJ
cmVzdW1lX2d1ZXN0X2RvbWFpbg0KKw0KKwlsZHIJcjEyLCBbcjExLCAjT0ZGU0VUX0VWVENITl9V
UENBTExfUEVORElOR10NCisNCisJdHN0CXIxMiwgIzB4RkYNCisJYmVxCXJlc3VtZV9ndWVzdF9k
b21haW4NCisNCitkb191cGNhbGw6DQorCWxkciAgICAgcjE0LCBbcjEwLCAjKE9GRlNFVF9BUkNI
X1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNFVF9WQ1BVX1ZCQVIpXQ0KKwljbXAJ
bHIsICMwDQorCWJlcQl0cmFwX3RhYmxlX2ludmFsaWQNCisNCisJYWRkCXIxNCwgcjE0LCAjT0ZG
U0VUX1ZFQ1RPUl9JUlENCisNCisJbGRyCXI0LCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5G
TyArIE9GRlNFVF9UQ1BTUildDQorDQorCW9ycglyOSwgcjQsICNWUFNSX0lfQklUDQorCXN0cgly
OSwgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQ0KKw0KKwls
ZHIJcjAsIFtzcCwgI0NUWFRfVVNQXQ0KKwlsZHIJcjEsIFtzcCwgI0NUWFRfVUxSXQ0KKwlsZHIJ
cjIsIFtzcCwgI0NUWFRfUENdDQorCWxkcglyMywgW3NwLCAjQ1RYVF9TUFNSXQ0KKw0KKwlsZHIJ
cjUsIFtyOCwgIzRdDQorCWJpYwlyMywgcjMsICNQU1JfTU9ERV9NQVNLDQorCW9ycglyMywgcjMs
IHI1DQorDQorCXRzdAlyNCwgI1ZQU1JfSV9CSVQNCisJb3JybmUJcjMsIHIzLCAjUFNSX0lfQklU
DQorDQorCXN0cglyMCwgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQ
KV0NCisJc3RyCXIxLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIp
XQ0KKwlzdHIJcjMsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNS
KV0NCisNCisJY21wCXI1LCAjUFNSX01PREVfU1ZDDQorCWxkcm5lCXIwLCBbcjgsICM4XQ0KKw0K
Kwltb3YJcjUsICNQU1JfTU9ERV9TVkMNCisJc3RyCXI1LCBbcjgsICM0XQ0KKwlzdHIJcjAsIFty
OCwgIzhdDQorCXN0cglyMiwgW3I4LCAjMTJdDQorDQorCWxkcglyNSwgPURBQ1JfU1RBVF9TVkMN
CisJbWNyICAgICBwMTUsIDAsIHI1LCBjMywgYzAsIDANCisJDQorCWNwc2lkCWkNCisNCisJYWRk
CXI4LCByOCwgIzgNCisJbGRtaWEJcjgsIHtyMTMsIHIxNH1eDQorCWxkbWlhCXNwLCB7cjAtcjEy
fQ0KKwlsZHIJc3AsIFtzcCwgI0NUWFRfU1NQXQ0KKwltc3IJc3BzciwgI1BTUl9NT0RFX1VTUg0K
Kwltb3ZzCXBjLCBscg0KKw0KK3Jlc3VtZV9ndWVzdF9kb21haW46DQorCWNjaQlyOA0KKwlsZHIJ
cjMsIFtyOCwgI09GRlNFVF9WUFNSXQ0KKwlsZHIJaXAsIFtzcCwgI0NUWFRfU1BTUl0NCisJY21w
CXIzLCAjUFNSX01PREVfU1ZDDQorDQorCWxkcm5lCXI3LCA9REFDUl9TVEFUX0hZUA0KKwlsZHJl
cSAgIHI3LCA9REFDUl9TVEFUX1NWQw0KKwltY3IJcDE1LCAwLCByNywgYzMsIGMwLCAwDQorDQor
CWNwc2lkCWkNCisNCisJUkVTVE9SRV9DT05URVhUDQorDQorLyoNCisgKiBQcm90b3R5cGUgOiBf
X3N3aXRjaF90byhzdHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICosIHN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgKikNCisgKi8NCisJCS5hbGlnbgk1DQorRU5UUlkoc3dp
dGNoX3RvKQ0KKwlhZGQgICAgIGlwLCByMSwgI09GRlNFVF9WQ1BVX1I0DQorCXN0bWlhICAgaXAs
IHtyNCAtIHNsLCBmcCwgaXAsIHNwLCBscn0NCisNCisJbXJjCXAxNSwgMCwgcjQsIGMzLCBjMCwg
MA0KKwltcmMJcDE1LCAwLCByNywgYzEzLCBjMCwgMQ0KKw0KKwlzdHIJcjQsIFtyMSwgI09GRlNF
VF9WQ1BVX0RBQ1JdDQorCXN0cglyNywgW3IxLCAjT0ZGU0VUX1ZDUFVfQ09OVEVYVElEUl0NCisN
CisJbGRyCXI0LCBbcjIsICNPRkZTRVRfVkNQVV9EQUNSXQ0KKwlsZHIJcjcsIFtyMiwgI09GRlNF
VF9WQ1BVX0NPTlRFWFRJRFJdDQorDQorCW1jcglwMTUsIDAsIHI0LCBjMywgYzAsIDANCisJbWNy
CXAxNSwgMCwgcjcsIGMxMywgYzAsIDENCisNCisJYWRkCWlwLCByMiwgI09GRlNFVF9WQ1BVX1I0
DQorCWxkbWlhICAgaXAsICB7cjQgLSBzbCwgZnAsIGlwLCBzcCwgbHJ9DQorIA0KKwliCWNvbnRl
eHRfc2F2ZWQNCisNCisJLmFsaWduCTUNCisJLnR5cGUgaHlwZXJjYWxsX3RhYmxlLCAjb2JqZWN0
DQorRU5UUlkoaHlwZXJjYWxsX3RhYmxlKQ0KKwkubG9uZwlkb19zZXRfdHJhcF90YWJsZQkvKiAg
MCAqLw0KKwkubG9uZwlkb19tbXVfdXBkYXRlDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyog
c2V0X2dkdCAqLw0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIHN0YWNrX3N3aXRjaCAqLw0K
KwkubG9uZwlkb19zZXRfY2FsbGJhY2tzCQ0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIGZw
dV9zd2l0Y2ggKi8NCisJLmxvbmcJZG9fc2NoZWRfb3BfY29tcGF0DQorCS5sb25nCWRvX25pX2h5
cGVyY2FsbAkJDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbA0KKwkubG9uZwlkb19uaV9oeXBlcmNh
bGwNCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKiAxMCAqLw0KKwkubG9uZwlkb19uaV9oeXBl
cmNhbGwNCisJLmxvbmcJZG9fbWVtb3J5X29wDQorCS5sb25nCWRvX211bHRpY2FsbA0KKwkubG9u
Zwlkb191cGRhdGVfdmFfbWFwcGluZw0KKwkubG9uZwlkb19zZXRfdGltZXJfb3AJCS8qIDE1ICov
DQorCS5sb25nCWRvX2V2ZW50X2NoYW5uZWxfb3ANCisJLmxvbmcJZG9feGVuX3ZlcnNpb24NCisJ
LmxvbmcJZG9fY29uc29sZV9pbw0KKwkubG9uZwlkb19waHlzZGV2X29wDQorCS5sb25nCWRvX2dy
YW50X3RhYmxlX29wCS8qIDIwICovDQorCS5sb25nCWRvX3ZtX2Fzc2lzdA0KKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwNCisJLmxvbmcJZG9fcmVzdG9yZV90cmFwX2ZyYW1lDQorCS5sb25nCWRvX3Zj
cHVfb3ANCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKiAyNSAqLw0KKwkubG9uZwlkb19tbXVl
eHRfb3ANCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsDQorCS5sb25nCWRvX25taV9vcA0KKwkubG9u
Zwlkb19zY2hlZF9vcA0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDMwIDogY2FsbGJhY2tv
cAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKgl4ZW5vcHJvZgkJKi8NCisJLmxvbmcJ
ZG9fbmlfaHlwZXJjYWxsCQkvKglldmVudF9jaGFubmVsX29wCSovDQorCS5sb25nCWRvX25pX2h5
cGVyY2FsbAkJLyoJcGh5c2Rldl9vcAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKglo
dm1fb3AJCQkqLw0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDM1IDogc3lzY3RsCQkJKi8N
CisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKiAgICAgIGRvbWN0bAkJCSovDQorCS5sb25nCWRv
X25pX2h5cGVyY2FsbAkJLyoJa2V4ZWNfb3AJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJ
LyoJdG1lbV9vcAkJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJeGNfcmVzZXJ2ZWRf
b3AJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyogNDAgOiB1bmRlZmluZWQJCSovDQor
CS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLw0KKwkubG9uZwlkb19uaV9o
eXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKgl1
bmRlZmluZWQJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLw0K
KwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDQ1IDogdW5kZWZpbmVkCQkqLw0KKwkubG9uZwlk
b19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxs
CQkvKgl1bmRlZmluZWQJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVk
CQkqLw0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJ
ZG9fbmlfaHlwZXJjYWxsCQkvKiA1MCA6CXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJZG9fbmlfaHlw
ZXJjYWxsCQkvKgl1bmRlZmluZWQJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyogCXVu
ZGVmaW5lZAkJKi8NCisNCisgICAgICAgIC5zZWN0aW9uIC5kYXRhDQorRU5UUlkoeGVuX3RyYW5z
bGF0aW9uX3RhYmxlKQ0KKyAgICAgICAgLmxvbmcgICBzdGFydCAtIDB4NDAwMA0KKw0KZGlmZiAt
ciAyOGE2MDM4ZGE5OWYgeGVuL2FyY2gvYXJtL3hlbi9oeXBlcmNhbGxzLlMNCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVu
L2h5cGVyY2FsbHMuUwlGcmkgRmViIDAzIDE3OjQ3OjE2IDIwMTIgKzA5MDANCkBAIC0wLDAgKzEs
NjcgQEANCisvKg0KKyAqIGh5cGVyY2FsbHMuUw0KKyAqDQorICogQ29weXJpZ2h0IChDKSAyMDA4
LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcw0KKyAqICAgICAgICAgIFNhbmctYnVtIFN1aCA8c2J1
ay5zdWhAc2Ftc3VuZy5jb20+DQorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBz
YW1zdW5nLmNvbT4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlz
aGVkIGJ5DQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCisgKg0KKyAqIFRoaXMg
cHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVs
LA0KKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVk
IHdhcnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv
ciBtb3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFsb25nIHdpdGggdGhpcyBw
cm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQorICogRm91bmRhdGlv
biwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEz
MDcgIFVTQQ0KKyAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+DQorI2luY2x1ZGUgPGFz
bS9wcm9jZXNzb3IuaD4NCisjaW5jbHVkZSA8YXNtL3BhZ2UuaD4NCisjaW5jbHVkZSA8YXNtL3N5
c3RlbS5oPg0KKyNpbmNsdWRlIDxhc20vY3B1LWRvbWFpbi5oPg0KKyNpbmNsdWRlIDxhc20vYXNt
LW9mZnNldHMuaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4NCisNCisjaW5jbHVkZSA8
cHVibGljL2FyY2gtYXJtLmg+DQorDQorDQorRU5UUlkoZG9fc2V0X2RvbWFpbikNCisgICAgICAg
IG1vdiAgICAgcGMsIGxyDQorDQorDQorRU5UUlkoZG9fcmVzdG9yZV90cmFwX2ZyYW1lKQ0KKwlj
Y2kJcjgNCisJbGRyCXI0LCBbcjgsICNPRkZTRVRfVkNQVV0NCisJbGRyCXI2LCBbc3AsICNDVFhU
X1VTUF0NCisJbGRyCXIxMSwgW3I0LCAjT0ZGU0VUX1ZDUFVfSU5GT10NCisNCisJbGRyICAgICBy
MywgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQU1IpXQ0KKwlsZHIg
ICAgIHIyLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQ0KKwls
ZHIgICAgIHIxLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1ApXQ0K
Kw0KKwlsZHIJcjcsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNS
KV0NCisNCisJdHN0CXIzLCAjUFNSX0lfQklUDQorCW9ycm5lCXI3LCAjVlBTUl9JX0JJVA0KKwli
aWNlcQlyNywgI1ZQU1JfSV9CSVQNCisNCisJYmljCXI1LCByMywgIyhQU1JfTU9ERV9NQVNLIHwg
UFNSX0lfQklUKQ0KKwlvcnIJcjUsIHI1LCAjUFNSX01PREVfVVNSDQorCWFuZAlyMywgcjMsICNQ
U1JfTU9ERV9NQVNLDQorDQorCUAgQ29uc3RydWN0IGxhdGVzdCBndWVzdCBjb250ZXh0DQorCXN0
cglyMSwgW3NwLCAjQ1RYVF9VU1BdDQorCXN0cglyMiwgW3NwLCAjQ1RYVF9QQ10NCisJc3RyCXI1
LCBbc3AsICNDVFhUX1NQU1JdDQorCXN0cglyMywgW3I4LCAjNF0NCisJc3RyCXI2LCBbcjgsICM4
XQ0KKw0KKwlAIFVwZGF0ZSBWUFNSDQorCXN0ciAgICByNywgW3IxMSwgIyhPRkZTRVRfQVJDSF9W
Q1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQ0KKw0KKwltb3YJcGMsIGxyDQpkaWZmIC1yIDI4YTYw
MzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL3BoeXNkZXYuYw0KLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vcGh5c2Rldi5j
CUZyaSBGZWIgMDMgMTc6NDc6MTYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw0MSBAQA0KKy8qDQor
ICogcGh5c2Rldi5jDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBTYW1zdW5nIEVs
ZWN0cm9uaWNzDQorICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNv
bT4NCisgKiAgICAgICAgICBKYWVNaW4gUnl1ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPg0KKyAq
DQorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vciBtb2RpZnkNCisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCisgKiB0aGUg
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0KKyAqDQorICogVGhpcyBwcm9ncmFtIGlzIGRpc3Ry
aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQorICogYnV0IFdJVEhP
VVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlDQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4N
CisgKg0KKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlDQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwg
d3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1w
bGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQorICovDQor
DQorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4NCisjaW5jbHVkZSA8eGVuL2xpYi5oPg0KKyNpbmNs
dWRlIDx4ZW4vdHlwZXMuaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisjaW5jbHVkZSA8eGVu
L2Vycm5vLmg+DQorI2luY2x1ZGUgPHhlbi9zcGlubG9jay5oPg0KKyNpbmNsdWRlIDx4ZW4vYml0
bWFwLmg+DQorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KKyNpbmNsdWRlIDx4ZW4vZXZlbnQuaD4N
CisjaW5jbHVkZSA8eGVuL2lycS5oPg0KKyNpbmNsdWRlIDx4ZW4vZ3Vlc3RfYWNjZXNzLmg+DQor
I2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5oPg0KKyNpbmNsdWRlIDxwdWJsaWMvcGh5c2Rldi5o
Pg0KKw0KK2ludCBkb19waHlzZGV2X29wKGludCBjbWQsIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkg
YXJnKQ0KK3sNCisJTk9UX1lFVCgpOw0KKw0KKwlyZXR1cm4gLUVJTlZBTDsNCit9DQo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch05.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch05.diff"


YXJtOiBpbXBsZW1lbnQgZXhjZXB0aW9uIGFuZCBoeXBlcmNhbGwgZW50cmllcy4KCiB4ZW4v
YXJjaC9hcm0veGVuL01ha2VmaWxlICAgICAgfCAgICAzICsKIHhlbi9hcmNoL2FybS94ZW4v
YXNtLW9mZnNldHMuYyB8ICAgNjEgKysrKysrKysKIHhlbi9hcmNoL2FybS94ZW4vZW50cnku
UyAgICAgICB8ICA1OTYgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4v
YXJjaC9hcm0veGVuL2h5cGVyY2FsbHMuUyAgfCAgIDY3ICsrKysrKysrKwogeGVuL2FyY2gv
YXJtL3hlbi9waHlzZGV2LmMgICAgIHwgICA0MSArKysrKwogNSBmaWxlcyBjaGFuZ2VkLCA3
NjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKClNpZ25lZC1vZmYtYnk6IEphZW1p
biBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciAyOGE2MDM4ZGE5OWYgeGVu
L2FyY2gvYXJtL3hlbi9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxl
CUZyaSBGZWIgMDMgMTc6Mjg6MzQgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVu
L01ha2VmaWxlCUZyaSBGZWIgMDMgMTc6NDc6MTYgMjAxMiArMDkwMApAQCAtMSw1ICsxLDgg
QEAKIG9iai15ICs9IHN0YXJ0Lm8KIG9iai15ICs9IHNldHVwLm8KK29iai15ICs9IGVudHJ5
Lm8KK29iai15ICs9IGh5cGVyY2FsbHMubworb2JqLXkgKz0gcGh5c2Rldi5vCiBvYmoteSAr
PSBtbS5vCiBvYmoteSArPSBpcnEubwogb2JqLXkgKz0gYXJjaF9kb21haW4ubwpkaWZmIC1y
IDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL2FzbS1vZmZzZXRzLmMKLS0tIGEveGVu
L2FyY2gvYXJtL3hlbi9hc20tb2Zmc2V0cy5jCUZyaSBGZWIgMDMgMTc6Mjg6MzQgMjAxMiAr
MDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2FzbS1vZmZzZXRzLmMJRnJpIEZlYiAwMyAx
Nzo0NzoxNiAyMDEyICswOTAwCkBAIC0zNCw2ICszNCw2NyBAQAogCiBpbnQgbWFpbih2b2lk
KQogeworCURFRklORShPRkZTRVRfU09GVElSUV9QRU5ESU5HLAkJb2Zmc2V0b2Yoc3RydWN0
IGlycV9jcHVzdGF0LCBfX3NvZnRpcnFfcGVuZGluZykpOworCURFRklORShPRkZTRVRfTE9D
QUxfSVJRX0NPVU5ULAkJb2Zmc2V0b2Yoc3RydWN0IGlycV9jcHVzdGF0LCBfX2xvY2FsX2ly
cV9jb3VudCkpOworCURFRklORShPRkZTRVRfTk1JX0NPVU5ULAkJb2Zmc2V0b2Yoc3RydWN0
IGlycV9jcHVzdGF0LCBfX25taV9jb3VudCkpOworCURFRklORShTSVpFX0lSUV9DUFVfU1RB
VCwJCXNpemVvZihzdHJ1Y3QgaXJxX2NwdXN0YXQpKTsKKwlCTEFOSygpOworCURFRklORShP
RkZTRVRfVkNQVV9JTkZPLAkJb2Zmc2V0b2Yoc3RydWN0IHZjcHUsIHZjcHVfaW5mbykpOwor
CURFRklORShPRkZTRVRfQVJDSF9WQ1BVLAkJb2Zmc2V0b2Yoc3RydWN0IHZjcHUsIGFyY2gp
KTsKKwlCTEFOSygpOworCURFRklORShPRkZTRVRfRVZUQ0hOX1VQQ0FMTF9NQVNLLAlvZmZz
ZXRvZihzdHJ1Y3QgdmNwdV9pbmZvLCBldnRjaG5fdXBjYWxsX21hc2spKTsKKwlERUZJTkUo
T0ZGU0VUX0VWVENITl9VUENBTExfUEVORElORywJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfaW5m
bywgZXZ0Y2huX3VwY2FsbF9wZW5kaW5nKSk7CisJREVGSU5FKE9GRlNFVF9BUkNIX1ZDUFVf
SU5GTywJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2luZm8sIGFyY2gpKTsKKwlERUZJTkUoT0ZG
U0VUX1RTUCwJCQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIHNwKSk7CisJREVG
SU5FKE9GRlNFVF9UTFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBscikp
OworCURFRklORShPRkZTRVRfVENQU1IsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9p
bmZvLCBjcHNyKSk7CisJREVGSU5FKE9GRlNFVF9UU1BTUiwJCQlvZmZzZXRvZihzdHJ1Y3Qg
YXJjaF92Y3B1X2luZm8sIHNwc3IpKTsKKwlERUZJTkUoT0ZGU0VUX1ZDUiwJCQlvZmZzZXRv
ZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIGNyKSk7CisJREVGSU5FKE9GRlNFVF9WREFDUiwJ
CQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIGRhY3IpKTsKKwlERUZJTkUoT0ZG
U0VUX1ZDUEFSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3ZjcHVfaW5mbywgY3BhcikpOwor
CURFRklORShPRkZTRVRfVlBJRFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZv
LCBwaWRyKSk7CisJREVGSU5FKE9GRlNFVF9WRlNSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNo
X3ZjcHVfaW5mbywgZnNyKSk7CisJREVGSU5FKE9GRlNFVF9WRkFSLAkJCW9mZnNldG9mKHN0
cnVjdCBhcmNoX3ZjcHVfaW5mbywgZmFyKSk7CisJQkxBTksoKTsKKwlERUZJTkUoT0ZGU0VU
X0dVRVNUX0NPTlRFWFQsCQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1LCBjdHgpKTsKKwlE
RUZJTkUoT0ZGU0VUX1ZFQ1RPUl9SRVNFVCwJCTApOworCURFRklORShPRkZTRVRfVkVDVE9S
X1VORCwJCTQpOworCURFRklORShPRkZTRVRfVkVDVE9SX1NXSSwJCTgpOworCURFRklORShP
RkZTRVRfVkVDVE9SX1BBQlQsCQkxMik7CisJREVGSU5FKE9GRlNFVF9WRUNUT1JfREFCVCwJ
CTE2KTsKKwlERUZJTkUoT0ZGU0VUX1ZFQ1RPUl9JUlEsCQkyNCk7CisJREVGSU5FKE9GRlNF
VF9WRUNUT1JfRklRLAkJMjgpOworCUJMQU5LKCk7CisJREVGSU5FKE9GRlNFVF9WQ1BVLAkJ
CW9mZnNldG9mKHN0cnVjdCBjcHVfaW5mbywgdmNwdSkpOworCURFRklORShPRkZTRVRfVlBT
UiwJCQlvZmZzZXRvZihzdHJ1Y3QgY3B1X2luZm8sIHZzcHNyKSk7CisJREVGSU5FKE9GRlNF
VF9WU1AsCQkJb2Zmc2V0b2Yoc3RydWN0IGNwdV9pbmZvLCB2c3ApKTsKKwlERUZJTkUoT0ZG
U0VUX1ZMUiwJCQlvZmZzZXRvZihzdHJ1Y3QgY3B1X2luZm8sIHZscikpOworCUJMQU5LKCk7
CisJREVGSU5FKE9GRlNFVF9WQ1BVX1IwLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0
X2NvbnRleHQsIHIwKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1IxLAkJCW9mZnNldG9mKHN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHIxKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1Iy
LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHIyKSk7CisJREVGSU5F
KE9GRlNFVF9WQ1BVX1IzLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQs
IHIzKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I0LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1
X2d1ZXN0X2NvbnRleHQsIHI0KSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I1LAkJCW9mZnNl
dG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI1KSk7CisJREVGSU5FKE9GRlNFVF9W
Q1BVX1I2LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI2KSk7CisJ
REVGSU5FKE9GRlNFVF9WQ1BVX1I3LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQsIHI3KSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I4LAkJCW9mZnNldG9mKHN0cnVj
dCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI4KSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I5LAkJ
CW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI5KSk7CisJREVGSU5FKE9G
RlNFVF9WQ1BVX1IxMCwJCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBy
MTApKTsKKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjExLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1
X2d1ZXN0X2NvbnRleHQsIHIxMSkpOworCURFRklORShPRkZTRVRfVkNQVV9SMTIsCQkJb2Zm
c2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjEyKSk7CisJREVGSU5FKE9GRlNF
VF9WQ1BVX1IxMywJCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCByMTMp
KTsKKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjE0LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1
ZXN0X2NvbnRleHQsIHIxNCkpOworCURFRklORShPRkZTRVRfVkNQVV9SMTUsCQkJb2Zmc2V0
b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjE1KSk7CisJREVGSU5FKE9GRlNFVF9W
Q1BVX0RBQ1IsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBkYWNyKSk7
CisJREVGSU5FKE9GRlNFVF9WQ1BVX1ZCQVIsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVz
dF9jb250ZXh0LCB2YmFyKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX0NPTlRFWFRJRFIsCQlv
ZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBjb250ZXh0aWRyKSk7CisJREVG
SU5FKE9GRlNFVF9WQ1BVX0ZDU0VJRFIsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9j
b250ZXh0LCBmY3NlaWRyKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1RUQlIwLAkJb2Zmc2V0
b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgdHRicjApKTsKKwlERUZJTkUoT0ZGU0VU
X1ZDUFVfVFRCUjEsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCB0dGJy
MSkpOworCURFRklORShPRkZTRVRfVkNQVV9UVEJDUiwJCW9mZnNldG9mKHN0cnVjdCB2Y3B1
X2d1ZXN0X2NvbnRleHQsIHR0YmNyKSk7CisJLy9ERUZJTkUoT0ZGU0VUX0hZUEVSVklTT1Jf
Q0FMTEJBQ0ssCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIGV2ZW50X2Nh
bGxiYWNrKSk7CisJLy9ERUZJTkUoT0ZGU0VUX0ZBSUxTQUZFX0NBTExCQUNLLAlvZmZzZXRv
ZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBmYWlsc2FmZV9jYWxsYmFjaykpOwogCUJM
QU5LKCk7CiAKIAlyZXR1cm4gMDsgCmRpZmYgLXIgMjhhNjAzOGRhOTlmIHhlbi9hcmNoL2Fy
bS94ZW4vZW50cnkuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2VudHJ5LlMJRnJpIEZlYiAwMyAxNzo0Nzox
NiAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTk2IEBACisvKgorICogZW50cnkuUworICoKKyAq
IENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAg
ICAgIFNhbmctYnVtIFN1aCA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBK
YWVNaW4gUnl1ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2
ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkg
V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl
IHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4K
KyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5v
dCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5
IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EK
KyAqLworI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KKyNpbmNsdWRlIDxhc20vcGFnZS5o
PgorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5o
PgorI2luY2x1ZGUgPGFzbS9jcHUtZG9tYWluLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1vZmZz
ZXRzLmg+CisjaW5jbHVkZSA8cHVibGljL2FyY2gtYXJtLmg+CisKKy5tYWNybyBTQVZFX0NP
TlRFWFQJIG9mZnNldCBjb3JyZWN0aW9uCisJc3ViICAgICBsciwgbHIsICNcY29ycmVjdGlv
bgorCXN0ciAgICAgcjAsIFtzcCwgIy0xNl0KKwlzdHIgICAgIGxyLCBbc3AsICMtMTJdCisK
KwltcnMgICAgIHIwLCBzcHNyCisJbW92ICAgICBsciwgI1xvZmZzZXQKKwlzdHIgICAgIHIw
LCBbc3AsICMtOF0KKwlzdHIgICAgIGxyLCBbc3AsICMtNF0KKworCXN1YiAgICAgcjAsIHNw
LCAjMTYKKworCW1zciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9JX0JJVCB8IFBTUl9GX0JJVCB8
IFBTUl9NT0RFX1NWQykKKworCXN1YglzcCwgc3AsICNDVFhUX0ZSQU1FX1NJWkUKK1NQRklY
KAl0c3QJc3AsICM0CQkpCitTUEZJWCgJYmljbmUJc3AsIHNwLCAjNAkpCisJc3RtaWIJc3As
IHtyMSAtIGxyfV4KKwlsZG1pYQlyMCwge3IxIC0gcjR9CisJYWRkCXI1LCBzcCwgI0NUWFRf
U1NQCisJYWRkCXIwLCBzcCwgI0NUWFRfRlJBTUVfU0laRQorU1BGSVgoCWFkZG5lCXIwLCBy
MCwgIzQJKQorCXN0cglyMSwgW3NwXQorCW1vdglyMSwgbHIKKwlzdG1pYQlyNSwge3IwIC0g
cjR9CisJbXNyCXNwc3JfY3hzZiwgcjMKKy5lbmRtCisKKy5tYWNybyBSRVNUT1JFX0NPTlRF
WFQKKwlsZHIJcjAsIFtzcCwgI0NUWFRfU1BTUl0KKwltc3IJc3Bzcl9jeHNmLCByMAorCWxk
bWlhCXNwLCB7cjAgLSBscn1eCisJYWRkCXNwLCBzcCwgI0NUWFRfU1NQCisJbGRtaWEJc3As
IHtzcCwgbHIsIHBjfV4KKy5lbmRtCisKKwkuYWxpZ24JNQorCS5nbG9iYWwgZXhjZXB0aW9u
X3ZlY3Rvcl90YWJsZQorZXhjZXB0aW9uX3ZlY3Rvcl90YWJsZToKKwlsZHIJcGMsIC5yc3QK
KwlsZHIJcGMsIC51bmQKKwlsZHIJcGMsIC5zd2kKKwlsZHIJcGMsIC5wYWJ0CisJbGRyCXBj
LCAuZGFidAorCWxkcglwYywgLmFkeAorCWxkcglwYywgLmlycQorCWxkcglwYywgLmZpcQor
CisucnN0OgkubG9uZwl2ZWN0b3JfcmVzZXQKKy51bmQ6CS5sb25nCXZlY3Rvcl91bmQKKy5z
d2k6CS5sb25nCXZlY3Rvcl9zd2kKKy5wYWJ0OgkubG9uZwl2ZWN0b3JfcGFidAorLmRhYnQ6
CS5sb25nCXZlY3Rvcl9kYWJ0CisuYWR4OgkubG9uZwl2ZWN0b3JfcmVzZXJ2ZWQKKy5pcnE6
CS5sb25nCXZlY3Rvcl9pcnEKKy5maXE6CS5sb25nCXZlY3Rvcl9maXEKKworCS5hbGlnbgk1
Cit2ZWN0b3JfcmVzZXQ6CisxOgorCWIJMWIKKworCS5hbGlnbgk1Cit2ZWN0b3JfaXJxOgor
CVNBVkVfQ09OVEVYVAkweDE4LCA0CisKKwltcnMJcjAsIHNwc3IKKwlhbmQJcjAsIHIwLCAj
UFNSX01PREVfTUFTSworCWVvcnMJcjAsIHIwLCAjUFNSX01PREVfU1ZDCisKKwlibmUJcmV0
dXJuX3RvX2d1ZXN0CisKKwljcHNpZAlpCisKKwlSRVNUT1JFX0NPTlRFWFQKKworCS5hbGln
bgk1Cit2ZWN0b3JfZGFidDoKKwlzdHIJcjAsIFtzcCwgIy0xNl0KKwlzdHIJbHIsIFtzcCwg
Iy0xMl0KKwltcnMgICAgIHIwLCBzcHNyCisJc3RyICAgICByMCwgW3NwLCAjLThdCisJc3Vi
ICAgICByMCwgc3AsICMxNgorCisJbXNyICAgICBjcHNyX2N4c2YsICMoUFNSX0lfQklUIHwg
UFNSX0ZfQklUIHwgUFNSX01PREVfU1ZDKQorCisJc3ViICAgICBzcCwgc3AsICNDVFhUX0ZS
QU1FX1NJWkUKK1NQRklYKCAgdHN0ICAgICBzcCwgIzQgICAgICApCitTUEZJWCggIGJpY25l
ICAgc3AsIHNwLCAjNCAgKQorCXN0bWliICAgc3AsIHtyMSAtIGxyfV4KKwlsZG1pYSAgIHIw
LCB7cjEgLSByM30KKwlhZGQgICAgIHI1LCBzcCwgI0NUWFRfU1NQCisJYWRkICAgICByMCwg
c3AsICNDVFhUX0ZSQU1FX1NJWkUKK1NQRklYKCAgYWRkbmUgICByMCwgcjAsICM0ICApCisJ
c3RyICAgICByMSwgW3NwXQorCW1vdiAgICAgcjEsIGxyCisJc3RtaWEgICByNSwge3IwIC0g
cjN9CisKKwltcmMgICAgIHAxNSwgMCwgcjAsIGM2LCBjMCwgMAorCW1yYyAgICAgcDE1LCAw
LCByMSwgYzUsIGMwLCAwCisKKwlhbmQJcjQsIHIzLCAjUFNSX01PREVfTUFTSworCWVvcnMJ
cjQsIHI0LCAjUFNSX01PREVfU1ZDCisKKwliZXEJZG9fZGF0YV9hYm9ydAorCisJY3BzaWUJ
aQorCQkKKwljY2kgICAgIHI4CisJbGRyICAgICByOSwgW3I4XQorCisJbGRyICAgICByMTAs
IFtyOSwgI09GRlNFVF9WQ1BVX0lORk8gXQorCWxkciAgICAgcjE0LCBbcjksICMoT0ZGU0VU
X0FSQ0hfVkNQVSArIE9GRlNFVF9HVUVTVF9DT05URVhUICsgT0ZGU0VUX1ZDUFVfVkJBUild
CisJY21wICAgICByMTQsICMwCisJYmVxICAgICB0cmFwX3RhYmxlX2ludmFsaWQKKworCWFk
ZAlyMTQsIHIxNCwgI09GRlNFVF9WRUNUT1JfREFCVAorCisJc3RyICAgICByMCwgW3IxMCwg
IyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVkZBUildCisJc3RyICAgICByMSwg
W3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVkZTUildCisKKwlAIEZv
bGxvd2luZyBpcyBhZGRlZCB0byBtaXggZXZ0Y2huIHVwY2FsbCBtYXNrIGFuZCBwc3IKKwls
ZHIJcjQsIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0K
KworCW9ycglyOSwgcjQsICNWUFNSX0lfQklUCisJc3RyCXI5LCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildCisKKwlsZHIgICAgIHIwLCBbc3AsICND
VFhUX1VTUF0KKwlsZHIgICAgIHIxLCBbc3AsICNDVFhUX1VMUl0KKworCWxkciAgICAgcjUs
IFtyOCwgI09GRlNFVF9WUFNSXQorCWJpYyAgICAgcjMsIHIzLCAjUFNSX01PREVfTUFTSwor
CW9yciAgICAgcjMsIHIzLCByNQorCisJdHN0CXI0LCAjVlBTUl9JX0JJVAorCW9ycm5lCXIz
LCByMywgI1BTUl9JX0JJVAorCisJc3RyICAgICByMCwgW3IxMCwgIyhPRkZTRVRfQVJDSF9W
Q1BVX0lORk8gKyBPRkZTRVRfVFNQKV0KKwlzdHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQorCXN0ciAgICAgcjMsIFtyMTAsICMoT0ZG
U0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0KKworCWNtcCAgICAgcjUsICNQ
U1JfTU9ERV9TVkMKKwlsZHJuZSAgIHIwLCBbcjgsICM4XQorCisJbW92ICAgICByNSwgI1BT
Ul9NT0RFX1NWQworCXN0ciAgICAgcjUsIFtyOCwgIzRdCisJc3RyICAgICByMCwgW3I4LCAj
OF0KKwlzdHIgICAgIHIyLCBbcjgsICMxMl0KKworCWxkciAgICAgcjUsID1EQUNSX1NUQVRf
U1ZDCisJbWNyICAgICBwMTUsIDAsIHI1LCBjMywgYzAsIDAKKworCWNwc2lkCWkKKworCWFk
ZCAgICAgcjgsIHI4LCAjOAorCWxkbWlhICAgcjgsIHtyMTMsIHIxNH1eCisJbGRtaWEgICBz
cCwge3IwLXIxMn0KKwlsZHIgICAgIHNwLCBbc3AsICNDVFhUX1NTUF0KKwltc3IgICAgIHNw
c3IsICNQU1JfTU9ERV9VU1IKKwltb3ZzICAgIHBjLCBscgorCisJLmFsaWduCTUKK3ZlY3Rv
cl9wYWJ0OgorCXN0ciAgICAgcjAsIFtzcCwgIy0xNl0KKwlzdHIgICAgIGxyLCBbc3AsICMt
MTJdCisJbXJzICAgICByMCwgc3BzcgorCXN0ciAgICAgcjAsIFtzcCwgIy04XQorCXN1YiAg
ICAgcjAsIHNwLCAjMTYKKworCW1zciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9JX0JJVCB8IFBT
Ul9GX0JJVCB8IFBTUl9NT0RFX1NWQykKKworCXN1YiAgICAgc3AsIHNwLCAjQ1RYVF9GUkFN
RV9TSVpFCitTUEZJWCggIHRzdCAgICAgc3AsICM0ICAgICAgKQorU1BGSVgoICBiaWNuZSAg
IHNwLCBzcCwgIzQgICkKKwlzdG1pYiAgIHNwLCB7cjEgLSBscn1eCisJbGRtaWEgICByMCwg
e3IxIC0gcjN9CisJYWRkICAgICByNSwgc3AsICNDVFhUX1NTUAorCWFkZCAgICAgcjAsIHNw
LCAjQ1RYVF9GUkFNRV9TSVpFCitTUEZJWCggIGFkZG5lICAgcjAsIHIwLCAjNCAgKQorCXN0
ciAgICAgcjEsIFtzcF0KKwltb3YgICAgIHIxLCBscgorCXN0bWlhICAgcjUsIHtyMCAtIHIz
fQorCisJbXJjICAgICBwMTUsIDAsIHIwLCBjNiwgYzAsIDAKKwltcmMgICAgIHAxNSwgMCwg
cjEsIGM1LCBjMCwgMAorCisJYW5kICAgICByNCwgcjMsICNQU1JfTU9ERV9NQVNLCisJZW9y
cyAgICByNCwgcjQsICNQU1JfTU9ERV9TVkMKKworCWJlcQlkb19wcmVmZXRjaF9hYm9ydAor
CisJY3BzaWUJaQkJCisKKwljY2kgICAgIHI4CisJbGRyICAgICByOSwgW3I4XQorCisJbGRy
ICAgICByMTAsIFtyOSwgI09GRlNFVF9WQ1BVX0lORk9dCisJbGRyICAgICByMTQsIFtyOSwg
IyhPRkZTRVRfQVJDSF9WQ1BVICsgT0ZGU0VUX0dVRVNUX0NPTlRFWFQgKyBPRkZTRVRfVkNQ
VV9WQkFSKV0KKwljbXAgICAgIGxyLCAjMAorCWJlcSAgICAgdHJhcF90YWJsZV9pbnZhbGlk
CisKKwlhZGQJcjE0LCByMTQsICNPRkZTRVRfVkVDVE9SX1BBQlQKKworCWxkcglyNCwgW3Ix
MCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQorCisJb3JyCXI5
LCByNCwgI1ZQU1JfSV9CSVQKKwlzdHIJcjksIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9J
TkZPICsgT0ZGU0VUX1RDUFNSKV0KKworCWxkciAgICAgcjAsIFtzcCwgI0NUWFRfVVNQXQor
CWxkciAgICAgcjEsIFtzcCwgI0NUWFRfVUxSXQorCisJbGRyICAgICByNSwgW3I4LCAjNF0K
KwliaWMgICAgIHIzLCByMywgI1BTUl9NT0RFX01BU0sKKwlvcnIgICAgIHIzLCByMywgcjUK
KworCXRzdAlyNCwgI1ZQU1JfSV9CSVQKKwlvcnJuZQlyMywgcjMsICNQU1JfSV9CSVQKKwor
CXN0ciAgICAgcjAsIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RT
UCldCisJc3RyICAgICByMSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZT
RVRfVExSKV0KKwlzdHIgICAgIHIzLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyAr
IE9GRlNFVF9UU1BTUildCisKKwljbXAgICAgIHI1LCAjUFNSX01PREVfU1ZDCisJbGRybmUg
ICByMCwgW3I4LCAjOF0KKworCW1vdiAgICAgcjUsICNQU1JfTU9ERV9TVkMKKwlzdHIgICAg
IHI1LCBbcjgsICM0XQorCXN0ciAgICAgcjAsIFtyOCwgIzhdCisJc3RyICAgICByMiwgW3I4
LCAjMTJdCisKKwlsZHIgICAgIHI1LCA9REFDUl9TVEFUX1NWQworCW1jciAgICAgcDE1LCAw
LCByNSwgYzMsIGMwLCAwCisKKwljcHNpZAlpCisKKwlhZGQgICAgIHI4LCByOCwgIzgKKwls
ZG1pYSAgIHI4LCB7cjEzLCByMTR9XgorCWxkbWlhICAgc3AsIHtyMC1yMTJ9CisJbGRyICAg
ICBzcCwgW3NwLCAjQ1RYVF9TU1BdCisJbXNyICAgICBzcHNyLCAjUFNSX01PREVfVVNSCisJ
bW92cyAgICBwYywgbHIKKworCS5hbGlnbgk1Cit2ZWN0b3JfdW5kOgorCXN0ciAgICAgcjAs
IFtzcCwgIy0xNl0KKwlzdHIgICAgIGxyLCBbc3AsICMtMTJdCisJbXJzICAgICByMCwgc3Bz
cgorCXN0ciAgICAgcjAsIFtzcCwgIy04XQorCXN1YiAgICAgcjAsIHNwLCAjMTYKKworCW1z
ciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9JX0JJVCB8IFBTUl9GX0JJVCB8IFBTUl9NT0RFX1NW
QykKKworCXN1YiAgICAgc3AsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFCitTUEZJWCggIHRzdCAg
ICAgc3AsICM0ICAgICAgKQorU1BGSVgoICBiaWNuZSAgIHNwLCBzcCwgIzQgICkKKwlzdG1p
YiAgIHNwLCB7cjEgLSBscn1eCisJbGRtaWEgICByMCwge3IxIC0gcjN9CisJYWRkICAgICBy
NSwgc3AsICNDVFhUX1NTUAorCWFkZCAgICAgcjAsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFCitT
UEZJWCggIGFkZG5lICAgcjAsIHIwLCAjNCAgKQorCXN0ciAgICAgcjEsIFtzcF0KKwltb3Yg
ICAgIHIxLCBscgorCXN0bWlhICAgcjUsIHtyMCAtIHIzfQorCisJYW5kICAgICByNCwgcjMs
ICNQU1JfTU9ERV9NQVNLCisJZW9ycyAgICByNCwgcjQsICNQU1JfTU9ERV9TVkMKKworCWJl
cSAgICAgZG9fdW5kZWZpbmVkX2luc3RydWN0aW9uCisKKwljcHNpZQlpCisKKwljY2kgICAg
IHI4CisJbGRyICAgICByOSwgW3I4XQorCisJbGRyICAgICByMTAsIFtyOSwgI09GRlNFVF9W
Q1BVX0lORk9dCisJbGRyICAgICByMTQsIFtyOSwgIyhPRkZTRVRfQVJDSF9WQ1BVICsgT0ZG
U0VUX0dVRVNUX0NPTlRFWFQgKyBPRkZTRVRfVkNQVV9WQkFSKV0KKwljbXAgICAgIGxyLCAj
MAorCWJlcSAgICAgdHJhcF90YWJsZV9pbnZhbGlkCisKKwlhZGQJcjE0LCByMTQsICNPRkZT
RVRfVkVDVE9SX1VORAorCisJbGRyCXI0LCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5G
TyArIE9GRlNFVF9UQ1BTUildCisKKwlvcnIJcjksIHI0LCAjVlBTUl9JX0JJVAorCXN0cgly
OSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQorCisJ
bGRyICAgICByMCwgW3NwLCAjQ1RYVF9VU1BdCisJbGRyICAgICByMSwgW3NwLCAjQ1RYVF9V
TFJdCisKKwlsZHIgICAgIHI1LCBbcjgsICM0XQorCWJpYyAgICAgcjMsIHIzLCAjUFNSX01P
REVfTUFTSworCW9yciAgICAgcjMsIHIzLCByNQorCisJdHN0CXI0LCAjVlBTUl9JX0JJVAor
CW9ycm5lCXIzLCByMywgI1BTUl9JX0JJVAorCisJc3RyICAgICByMCwgW3IxMCwgIyhPRkZT
RVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0KKwlzdHIgICAgIHIxLCBbcjEwLCAj
KE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQorCXN0ciAgICAgcjMsIFty
MTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0KKworCWNtcCAg
ICAgcjUsICNQU1JfTU9ERV9TVkMKKwlsZHJuZSAgIHIwLCBbcjgsICM4XQorCisJbW92ICAg
ICByNSwgI1BTUl9NT0RFX1NWQworCXN0ciAgICAgcjUsIFtyOCwgIzRdCisJc3RyICAgICBy
MCwgW3I4LCAjOF0KKwlzdHIgICAgIHIyLCBbcjgsICMxMl0KKwlzdHIgICAgIHIxLCBbcjgs
ICMxNl0KKworCWxkciAgICAgcjUsID1EQUNSX1NUQVRfU1ZDCisJbWNyICAgICBwMTUsIDAs
IHI1LCBjMywgYzAsIDAKKworCWNwc2lkCWkKKworCWFkZCAgICAgcjgsIHI4LCAjOAorCWxk
bWlhICAgcjgsIHtyMTMsIHIxNH1eCisJbGRtaWEgICBzcCwge3IwLXIxMn0KKwlsZHIgICAg
IHNwLCBbc3AsICNDVFhUX1NTUF0KKwltc3IgICAgIHNwc3IsICNQU1JfTU9ERV9VU1IKKwlt
b3ZzICAgIHBjLCBscgorCisJLmFsaWduCTUKK3ZlY3Rvcl9maXE6CisJc3VicyAgICBwYywg
bHIsICM0CisKKwkuYWxpZ24JNQordmVjdG9yX3Jlc2VydmVkOgorCWIJdmVjdG9yX3Jlc2Vy
dmVkCisKKwkuYWxpZ24JNQordHJhcF90YWJsZV9pbnZhbGlkOgorCWIJdHJhcF90YWJsZV9p
bnZhbGlkCisKKwkuYWxpZ24JNQordmVjdG9yX3N3aToKKwlzdHIJc3AsIFtzcCwgIyhDVFhU
X1NTUCAtIENUWFRfRlJBTUVfU0laRSldCisJc3ViICAgICBzcCwgc3AsICNDVFhUX0ZSQU1F
X1NJWkUKKwlzdG1pYSAgIHNwLCB7cjAgLSBscn1eCisJbXJzICAgICByMTEsIHNwc3IKKwlz
dHIgICAgIHIxNCwgW3NwLCAjQ1RYVF9QQ10KKwlzdHIgICAgIHIxMSwgW3NwLCAjQ1RYVF9T
UFNSXQorCisJY3BzaWUJaQorCisJY2NpCXI4CisJbGRyCXIxMiwgW3I4LCAjNF0KKwllb3Jz
CXIxMiwgcjEyLCAjUFNSX01PREVfU1ZDCisKKwliZXEJaW52b2tlX2h5cGVyY2FsbAorCQkK
Kwltb3YJcjEyLCAjUFNSX01PREVfU1ZDCisJc3RyICAgICByMTIsIFtyOCwgIzRdCisJc3Ry
ICAgICByMTQsIFtyOCwgIzEyXQorCisJbGRyICAgICByOSwgW3I4XQorCWxkciAgICAgcjEw
LCBbcjksICNPRkZTRVRfVkNQVV9JTkZPXQorCWxkciAgICAgcjE0LCBbcjksICMoT0ZGU0VU
X0FSQ0hfVkNQVSArIE9GRlNFVF9HVUVTVF9DT05URVhUICsgT0ZGU0VUX1ZDUFVfVkJBUild
CisJY21wICAgICByMTQsICMwCisJYmVxCXRyYXBfdGFibGVfaW52YWxpZAorCisJYWRkCXIx
NCwgcjE0LCAjT0ZGU0VUX1ZFQ1RPUl9TV0kKKworCWxkcglyNCwgW3IxMCwgIyhPRkZTRVRf
QVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQorCisJb3JyCXI5LCByNCwgI1ZQU1Jf
SV9CSVQKKwlzdHIJcjksIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VU
X1RDUFNSKV0KKworCXRzdAlyNCwgI1ZQU1JfSV9CSVQKKwlvcnJuZQlyMTEsIHIxMSwgI1BT
Ul9JX0JJVAorCisJbGRyICAgICByNCwgW3NwLCAjQ1RYVF9VU1BdCisJbGRyICAgICByNSwg
W3NwLCAjQ1RYVF9VTFJdCisKKwlzdHIgICAgIHI0LCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZD
UFVfSU5GTyArIE9GRlNFVF9UU1ApXQorCXN0ciAgICAgcjUsIFtyMTAsICMoT0ZGU0VUX0FS
Q0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RMUildCisJc3RyICAgICByMTEsIFtyMTAsICMoT0ZG
U0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0KKworCWxkciAgICAgcjExLCA9
REFDUl9TVEFUX1NWQworCW1jciAgICAgcDE1LCAwLCByMTEsIGMzLCBjMCwgMAorCisJY3Bz
aWQJaQorCisJYWRkICAgICByOCwgcjgsICM4CisJbGRtaWEgICByOCwge3IxMywgcjE0fV4K
KwlsZG1pYSAgIHNwLCB7cjAtcjEyfQorCWxkciAgICAgc3AsIFtzcCwgI0NUWFRfU1NQXQor
CW1zciAgICAgc3BzciwgI1BTUl9NT0RFX1VTUgorCW1vdnMgICAgcGMsIGxyCisKK2ludm9r
ZV9oeXBlcmNhbGw6CisJbGRyICAgICByMTIsIFtsciwgIy00XQorCWJpYyAgICAgcjEyLCBy
MTIsICMweGZmMDAwMDAwCisKKwlhZHIgICAgIHIxNCwgMWYKKwlhZHIgICAgIHIxMSwgaHlw
ZXJjYWxsX3RhYmxlCisJbGRyICAgICBwYywgW3IxMSwgcjEyLCBsc2wgIzJdCisKKzE6CisJ
c3RyICAgICByMCwgW3NwLCAjQ1RYVF9SMF0KKworCWIJcmV0dXJuX3RvX2d1ZXN0CisKK0VO
VFJZKHJldHVybl90b19ndWVzdCkJCisJY3BzaWUJaQorCWJsCWRvX3NvZnRpcnEKKworCWNj
aQlyOAorCWxkcglyMTAsIFtyOCwgI09GRlNFVF9WQ1BVXQorCisJbGRyCXIxMSwgW3IxMCwg
I09GRlNFVF9WQ1BVX0lORk9dCisJbGRyCXI5LCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVf
SU5GTyArIE9GRlNFVF9UQ1BTUildCisKKwl0c3QJcjksICNWUFNSX0lfQklUCisJYm5lCXJl
c3VtZV9ndWVzdF9kb21haW4KKworCWxkcglyMTIsIFtyMTEsICNPRkZTRVRfRVZUQ0hOX1VQ
Q0FMTF9QRU5ESU5HXQorCisJdHN0CXIxMiwgIzB4RkYKKwliZXEJcmVzdW1lX2d1ZXN0X2Rv
bWFpbgorCitkb191cGNhbGw6CisJbGRyICAgICByMTQsIFtyMTAsICMoT0ZGU0VUX0FSQ0hf
VkNQVSArIE9GRlNFVF9HVUVTVF9DT05URVhUICsgT0ZGU0VUX1ZDUFVfVkJBUildCisJY21w
CWxyLCAjMAorCWJlcQl0cmFwX3RhYmxlX2ludmFsaWQKKworCWFkZAlyMTQsIHIxNCwgI09G
RlNFVF9WRUNUT1JfSVJRCisKKwlsZHIJcjQsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9J
TkZPICsgT0ZGU0VUX1RDUFNSKV0KKworCW9ycglyOSwgcjQsICNWUFNSX0lfQklUCisJc3Ry
CXI5LCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildCisK
KwlsZHIJcjAsIFtzcCwgI0NUWFRfVVNQXQorCWxkcglyMSwgW3NwLCAjQ1RYVF9VTFJdCisJ
bGRyCXIyLCBbc3AsICNDVFhUX1BDXQorCWxkcglyMywgW3NwLCAjQ1RYVF9TUFNSXQorCisJ
bGRyCXI1LCBbcjgsICM0XQorCWJpYwlyMywgcjMsICNQU1JfTU9ERV9NQVNLCisJb3JyCXIz
LCByMywgcjUKKworCXRzdAlyNCwgI1ZQU1JfSV9CSVQKKwlvcnJuZQlyMywgcjMsICNQU1Jf
SV9CSVQKKworCXN0cglyMCwgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZT
RVRfVFNQKV0KKwlzdHIJcjEsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZG
U0VUX1RMUildCisJc3RyCXIzLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9G
RlNFVF9UU1BTUildCisKKwljbXAJcjUsICNQU1JfTU9ERV9TVkMKKwlsZHJuZQlyMCwgW3I4
LCAjOF0KKworCW1vdglyNSwgI1BTUl9NT0RFX1NWQworCXN0cglyNSwgW3I4LCAjNF0KKwlz
dHIJcjAsIFtyOCwgIzhdCisJc3RyCXIyLCBbcjgsICMxMl0KKworCWxkcglyNSwgPURBQ1Jf
U1RBVF9TVkMKKwltY3IgICAgIHAxNSwgMCwgcjUsIGMzLCBjMCwgMAorCQorCWNwc2lkCWkK
KworCWFkZAlyOCwgcjgsICM4CisJbGRtaWEJcjgsIHtyMTMsIHIxNH1eCisJbGRtaWEJc3As
IHtyMC1yMTJ9CisJbGRyCXNwLCBbc3AsICNDVFhUX1NTUF0KKwltc3IJc3BzciwgI1BTUl9N
T0RFX1VTUgorCW1vdnMJcGMsIGxyCisKK3Jlc3VtZV9ndWVzdF9kb21haW46CisJY2NpCXI4
CisJbGRyCXIzLCBbcjgsICNPRkZTRVRfVlBTUl0KKwlsZHIJaXAsIFtzcCwgI0NUWFRfU1BT
Ul0KKwljbXAJcjMsICNQU1JfTU9ERV9TVkMKKworCWxkcm5lCXI3LCA9REFDUl9TVEFUX0hZ
UAorCWxkcmVxICAgcjcsID1EQUNSX1NUQVRfU1ZDCisJbWNyCXAxNSwgMCwgcjcsIGMzLCBj
MCwgMAorCisJY3BzaWQJaQorCisJUkVTVE9SRV9DT05URVhUCisKKy8qCisgKiBQcm90b3R5
cGUgOiBfX3N3aXRjaF90byhzdHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgdmNwdV9ndWVzdF9jb250
ZXh0ICosIHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgKikKKyAqLworCQkuYWxpZ24JNQor
RU5UUlkoc3dpdGNoX3RvKQorCWFkZCAgICAgaXAsIHIxLCAjT0ZGU0VUX1ZDUFVfUjQKKwlz
dG1pYSAgIGlwLCB7cjQgLSBzbCwgZnAsIGlwLCBzcCwgbHJ9CisKKwltcmMJcDE1LCAwLCBy
NCwgYzMsIGMwLCAwCisJbXJjCXAxNSwgMCwgcjcsIGMxMywgYzAsIDEKKworCXN0cglyNCwg
W3IxLCAjT0ZGU0VUX1ZDUFVfREFDUl0KKwlzdHIJcjcsIFtyMSwgI09GRlNFVF9WQ1BVX0NP
TlRFWFRJRFJdCisKKwlsZHIJcjQsIFtyMiwgI09GRlNFVF9WQ1BVX0RBQ1JdCisJbGRyCXI3
LCBbcjIsICNPRkZTRVRfVkNQVV9DT05URVhUSURSXQorCisJbWNyCXAxNSwgMCwgcjQsIGMz
LCBjMCwgMAorCW1jcglwMTUsIDAsIHI3LCBjMTMsIGMwLCAxCisKKwlhZGQJaXAsIHIyLCAj
T0ZGU0VUX1ZDUFVfUjQKKwlsZG1pYSAgIGlwLCAge3I0IC0gc2wsIGZwLCBpcCwgc3AsIGxy
fQorIAorCWIJY29udGV4dF9zYXZlZAorCisJLmFsaWduCTUKKwkudHlwZSBoeXBlcmNhbGxf
dGFibGUsICNvYmplY3QKK0VOVFJZKGh5cGVyY2FsbF90YWJsZSkKKwkubG9uZwlkb19zZXRf
dHJhcF90YWJsZQkvKiAgMCAqLworCS5sb25nCWRvX21tdV91cGRhdGUKKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwJCS8qIHNldF9nZHQgKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8q
IHN0YWNrX3N3aXRjaCAqLworCS5sb25nCWRvX3NldF9jYWxsYmFja3MJCisJLmxvbmcJZG9f
bmlfaHlwZXJjYWxsCQkvKiBmcHVfc3dpdGNoICovCisJLmxvbmcJZG9fc2NoZWRfb3BfY29t
cGF0CisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkKKwkubG9uZwlkb19uaV9oeXBlcmNhbGwK
KwkubG9uZwlkb19uaV9oeXBlcmNhbGwKKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDEw
ICovCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCisJLmxvbmcJZG9fbWVtb3J5X29wCisJLmxv
bmcJZG9fbXVsdGljYWxsCisJLmxvbmcJZG9fdXBkYXRlX3ZhX21hcHBpbmcKKwkubG9uZwlk
b19zZXRfdGltZXJfb3AJCS8qIDE1ICovCisJLmxvbmcJZG9fZXZlbnRfY2hhbm5lbF9vcAor
CS5sb25nCWRvX3hlbl92ZXJzaW9uCisJLmxvbmcJZG9fY29uc29sZV9pbworCS5sb25nCWRv
X3BoeXNkZXZfb3AKKwkubG9uZwlkb19ncmFudF90YWJsZV9vcAkvKiAyMCAqLworCS5sb25n
CWRvX3ZtX2Fzc2lzdAorCS5sb25nCWRvX25pX2h5cGVyY2FsbAorCS5sb25nCWRvX3Jlc3Rv
cmVfdHJhcF9mcmFtZQorCS5sb25nCWRvX3ZjcHVfb3AKKwkubG9uZwlkb19uaV9oeXBlcmNh
bGwJCS8qIDI1ICovCisJLmxvbmcJZG9fbW11ZXh0X29wCisJLmxvbmcJZG9fbmlfaHlwZXJj
YWxsCisJLmxvbmcJZG9fbm1pX29wCisJLmxvbmcJZG9fc2NoZWRfb3AKKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwJCS8qIDMwIDogY2FsbGJhY2tvcAkJKi8KKwkubG9uZwlkb19uaV9oeXBl
cmNhbGwJCS8qCXhlbm9wcm9mCQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJZXZl
bnRfY2hhbm5lbF9vcAkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJcGh5c2Rldl9v
cAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCWh2bV9vcAkJCSovCisJLmxvbmcJ
ZG9fbmlfaHlwZXJjYWxsCQkvKiAzNSA6IHN5c2N0bAkJCSovCisJLmxvbmcJZG9fbmlfaHlw
ZXJjYWxsCQkvKiAgICAgIGRvbWN0bAkJCSovCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkv
KglrZXhlY19vcAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXRtZW1fb3AJCQkq
LworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJeGNfcmVzZXJ2ZWRfb3AJCSovCisJLmxv
bmcJZG9fbmlfaHlwZXJjYWxsCQkvKiA0MCA6IHVuZGVmaW5lZAkJKi8KKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJ
CS8qCXVuZGVmaW5lZAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5l
ZAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8KKwkubG9u
Zwlkb19uaV9oeXBlcmNhbGwJCS8qIDQ1IDogdW5kZWZpbmVkCQkqLworCS5sb25nCWRvX25p
X2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJ
LyoJdW5kZWZpbmVkCQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVk
CQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLworCS5sb25n
CWRvX25pX2h5cGVyY2FsbAkJLyogNTAgOgl1bmRlZmluZWQJCSovCisJLmxvbmcJZG9fbmlf
aHlwZXJjYWxsCQkvKgl1bmRlZmluZWQJCSovCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkv
KiAJdW5kZWZpbmVkCQkqLworCisgICAgICAgIC5zZWN0aW9uIC5kYXRhCitFTlRSWSh4ZW5f
dHJhbnNsYXRpb25fdGFibGUpCisgICAgICAgIC5sb25nICAgc3RhcnQgLSAweDQwMDAKKwpk
aWZmIC1yIDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL2h5cGVyY2FsbHMuUwotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJj
aC9hcm0veGVuL2h5cGVyY2FsbHMuUwlGcmkgRmViIDAzIDE3OjQ3OjE2IDIwMTIgKzA5MDAK
QEAgLTAsMCArMSw2NyBAQAorLyoNCisgKiBoeXBlcmNhbGxzLlMNCisgKg0KKyAqIENvcHly
aWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBT
YW5nLWJ1bSBTdWggPHNidWsuc3VoQHNhbXN1bmcuY29tPg0KKyAqICAgICAgICAgIEphZU1p
biBSeXUgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0g
aXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlm
eQ0KKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZl
cnNpb24gMiBvZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uDQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAq
IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g
IFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRh
aWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3Jh
bTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KKyAqIEZvdW5kYXRpb24s
IEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0x
MzA3ICBVU0ENCisgKi8NCisNCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPg0KKyNpbmNsdWRl
IDxhc20vcHJvY2Vzc29yLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUg
PGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1kb21haW4uaD4NCisjaW5jbHVk
ZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+DQor
DQorI2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5oPg0KKw0KKw0KK0VOVFJZKGRvX3NldF9k
b21haW4pDQorICAgICAgICBtb3YgICAgIHBjLCBscg0KKw0KKw0KK0VOVFJZKGRvX3Jlc3Rv
cmVfdHJhcF9mcmFtZSkNCisJY2NpCXI4DQorCWxkcglyNCwgW3I4LCAjT0ZGU0VUX1ZDUFVd
DQorCWxkcglyNiwgW3NwLCAjQ1RYVF9VU1BdDQorCWxkcglyMTEsIFtyNCwgI09GRlNFVF9W
Q1BVX0lORk9dDQorDQorCWxkciAgICAgcjMsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9J
TkZPICsgT0ZGU0VUX1RTUFNSKV0NCisJbGRyICAgICByMiwgW3IxMSwgIyhPRkZTRVRfQVJD
SF9WQ1BVX0lORk8gKyBPRkZTRVRfVExSKV0NCisJbGRyICAgICByMSwgW3IxMSwgIyhPRkZT
RVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0NCisNCisJbGRyCXI3LCBbcjExLCAj
KE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildDQorDQorCXRzdAlyMywg
I1BTUl9JX0JJVA0KKwlvcnJuZQlyNywgI1ZQU1JfSV9CSVQNCisJYmljZXEJcjcsICNWUFNS
X0lfQklUDQorDQorCWJpYwlyNSwgcjMsICMoUFNSX01PREVfTUFTSyB8IFBTUl9JX0JJVCkN
CisJb3JyCXI1LCByNSwgI1BTUl9NT0RFX1VTUg0KKwlhbmQJcjMsIHIzLCAjUFNSX01PREVf
TUFTSw0KKw0KKwlAIENvbnN0cnVjdCBsYXRlc3QgZ3Vlc3QgY29udGV4dA0KKwlzdHIJcjEs
IFtzcCwgI0NUWFRfVVNQXQ0KKwlzdHIJcjIsIFtzcCwgI0NUWFRfUENdDQorCXN0cglyNSwg
W3NwLCAjQ1RYVF9TUFNSXQ0KKwlzdHIJcjMsIFtyOCwgIzRdDQorCXN0cglyNiwgW3I4LCAj
OF0NCisNCisJQCBVcGRhdGUgVlBTUg0KKwlzdHIgICAgcjcsIFtyMTEsICMoT0ZGU0VUX0FS
Q0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJbW92CXBjLCBscg0KZGlmZiAt
ciAyOGE2MDM4ZGE5OWYgeGVuL2FyY2gvYXJtL3hlbi9waHlzZGV2LmMKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9waHlzZGV2LmMJRnJpIEZlYiAwMyAxNzo0NzoxNiAyMDEyICswOTAwCkBAIC0wLDAgKzEs
NDEgQEAKKy8qCisgKiBwaHlzZGV2LmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAx
MSBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsu
c3VoQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBz
YW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91
IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g
dGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAq
IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNv
ZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMz
MCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9j
b25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+CisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+
CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vZXJybm8uaD4KKyNpbmNs
dWRlIDx4ZW4vc3BpbmxvY2suaD4KKyNpbmNsdWRlIDx4ZW4vYml0bWFwLmg+CisjaW5jbHVk
ZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVuL2V2ZW50Lmg+CisjaW5jbHVkZSA8eGVu
L2lycS5oPgorI2luY2x1ZGUgPHhlbi9ndWVzdF9hY2Nlc3MuaD4KKyNpbmNsdWRlIDxwdWJs
aWMvYXJjaC1hcm0uaD4KKyNpbmNsdWRlIDxwdWJsaWMvcGh5c2Rldi5oPgorCitpbnQgZG9f
cGh5c2Rldl9vcChpbnQgY21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKK3sKKwlO
T1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt16-0005x5-2M; Mon, 13 Feb 2012 10:20:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqnP-0003HT-Bm
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:57:59 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329119871!14601060!1
X-Originating-IP: [203.254.224.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzMgPT4gMjQzNjYx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2145 invoked from network); 13 Feb 2012 07:57:51 -0000
Received: from mailout3.samsung.com (HELO mailout3.samsung.com)
	(203.254.224.33) by server-9.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:57:51 -0000
Received: from epcpsbge5.samsung.com (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00IENNDFJYB0@mailout3.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:57:43 +0900 (KST)
Message-id: <0LZB00IJVNG7JYB0@mailout3.samsung.com>
X-AuditID: cbfee60f-b7bd0ae00000422c-6d-4f38c2771377
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge5.samsung.com (EPCPMTA) with SMTP id BD.8F.16940.772C83F4;
	Mon, 13 Feb 2012 16:57:43 +0900 (KST)
Date: Mon, 13 Feb 2012 07:57:43 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075640084@jm77.ryu
Msgkey: 20120213075640084@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075537186@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 05/14] arm: implement exception and hypercall
	entries.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <6088535.69921329119859824.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgZXhjZXB0aW9uIGFuZCBoeXBlcmNhbGwgZW50cmllcy4NCg0KIHhlbi9h
cmNoL2FybS94ZW4vTWFrZWZpbGUgICAgICB8ICAgIDMgKw0KIHhlbi9hcmNoL2FybS94ZW4vYXNt
LW9mZnNldHMuYyB8ICAgNjEgKysrKysrKysNCiB4ZW4vYXJjaC9hcm0veGVuL2VudHJ5LlMgICAg
ICAgfCAgNTk2ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94
ZW4vaHlwZXJjYWxscy5TICB8ICAgNjcgKysrKysrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9waHlz
ZGV2LmMgICAgIHwgICA0MSArKysrKw0KIDUgZmlsZXMgY2hhbmdlZCwgNzY4IGluc2VydGlvbnMo
KyksIDAgZGVsZXRpb25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1
QHNhbXN1bmcuY29tPg0KDQpkaWZmIC1yIDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL01h
a2VmaWxlDQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCUZyaSBGZWIgMDMgMTc6Mjg6
MzQgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQlGcmkgRmViIDAz
IDE3OjQ3OjE2IDIwMTIgKzA5MDANCkBAIC0xLDUgKzEsOCBAQA0KIG9iai15ICs9IHN0YXJ0Lm8N
CiBvYmoteSArPSBzZXR1cC5vDQorb2JqLXkgKz0gZW50cnkubw0KK29iai15ICs9IGh5cGVyY2Fs
bHMubw0KK29iai15ICs9IHBoeXNkZXYubw0KIG9iai15ICs9IG1tLm8NCiBvYmoteSArPSBpcnEu
bw0KIG9iai15ICs9IGFyY2hfZG9tYWluLm8NCmRpZmYgLXIgMjhhNjAzOGRhOTlmIHhlbi9hcmNo
L2FybS94ZW4vYXNtLW9mZnNldHMuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9hc20tb2Zmc2V0
cy5jCUZyaSBGZWIgMDMgMTc6Mjg6MzQgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9hc20tb2Zmc2V0cy5jCUZyaSBGZWIgMDMgMTc6NDc6MTYgMjAxMiArMDkwMA0KQEAgLTM0LDYg
KzM0LDY3IEBADQogDQogaW50IG1haW4odm9pZCkNCiB7DQorCURFRklORShPRkZTRVRfU09GVElS
UV9QRU5ESU5HLAkJb2Zmc2V0b2Yoc3RydWN0IGlycV9jcHVzdGF0LCBfX3NvZnRpcnFfcGVuZGlu
ZykpOw0KKwlERUZJTkUoT0ZGU0VUX0xPQ0FMX0lSUV9DT1VOVCwJCW9mZnNldG9mKHN0cnVjdCBp
cnFfY3B1c3RhdCwgX19sb2NhbF9pcnFfY291bnQpKTsNCisJREVGSU5FKE9GRlNFVF9OTUlfQ09V
TlQsCQlvZmZzZXRvZihzdHJ1Y3QgaXJxX2NwdXN0YXQsIF9fbm1pX2NvdW50KSk7DQorCURFRklO
RShTSVpFX0lSUV9DUFVfU1RBVCwJCXNpemVvZihzdHJ1Y3QgaXJxX2NwdXN0YXQpKTsNCisJQkxB
TksoKTsNCisJREVGSU5FKE9GRlNFVF9WQ1BVX0lORk8sCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdSwg
dmNwdV9pbmZvKSk7DQorCURFRklORShPRkZTRVRfQVJDSF9WQ1BVLAkJb2Zmc2V0b2Yoc3RydWN0
IHZjcHUsIGFyY2gpKTsNCisJQkxBTksoKTsNCisJREVGSU5FKE9GRlNFVF9FVlRDSE5fVVBDQUxM
X01BU0ssCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2luZm8sIGV2dGNobl91cGNhbGxfbWFzaykpOw0K
KwlERUZJTkUoT0ZGU0VUX0VWVENITl9VUENBTExfUEVORElORywJb2Zmc2V0b2Yoc3RydWN0IHZj
cHVfaW5mbywgZXZ0Y2huX3VwY2FsbF9wZW5kaW5nKSk7DQorCURFRklORShPRkZTRVRfQVJDSF9W
Q1BVX0lORk8sCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9pbmZvLCBhcmNoKSk7DQorCURFRklORShP
RkZTRVRfVFNQLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3ZjcHVfaW5mbywgc3ApKTsNCisJREVG
SU5FKE9GRlNFVF9UTFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBscikpOw0K
KwlERUZJTkUoT0ZGU0VUX1RDUFNSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3ZjcHVfaW5mbywg
Y3BzcikpOw0KKwlERUZJTkUoT0ZGU0VUX1RTUFNSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3Zj
cHVfaW5mbywgc3BzcikpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUiwJCQlvZmZzZXRvZihzdHJ1Y3Qg
YXJjaF92Y3B1X2luZm8sIGNyKSk7DQorCURFRklORShPRkZTRVRfVkRBQ1IsCQkJb2Zmc2V0b2Yo
c3RydWN0IGFyY2hfdmNwdV9pbmZvLCBkYWNyKSk7DQorCURFRklORShPRkZTRVRfVkNQQVIsCQkJ
b2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBjcGFyKSk7DQorCURFRklORShPRkZTRVRf
VlBJRFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBwaWRyKSk7DQorCURFRklO
RShPRkZTRVRfVkZTUiwJCQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIGZzcikpOw0K
KwlERUZJTkUoT0ZGU0VUX1ZGQVIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBm
YXIpKTsNCisJQkxBTksoKTsNCisJREVGSU5FKE9GRlNFVF9HVUVTVF9DT05URVhULAkJb2Zmc2V0
b2Yoc3RydWN0IGFyY2hfdmNwdSwgY3R4KSk7DQorCURFRklORShPRkZTRVRfVkVDVE9SX1JFU0VU
LAkJMCk7DQorCURFRklORShPRkZTRVRfVkVDVE9SX1VORCwJCTQpOw0KKwlERUZJTkUoT0ZGU0VU
X1ZFQ1RPUl9TV0ksCQk4KTsNCisJREVGSU5FKE9GRlNFVF9WRUNUT1JfUEFCVCwJCTEyKTsNCisJ
REVGSU5FKE9GRlNFVF9WRUNUT1JfREFCVCwJCTE2KTsNCisJREVGSU5FKE9GRlNFVF9WRUNUT1Jf
SVJRLAkJMjQpOw0KKwlERUZJTkUoT0ZGU0VUX1ZFQ1RPUl9GSVEsCQkyOCk7DQorCUJMQU5LKCk7
DQorCURFRklORShPRkZTRVRfVkNQVSwJCQlvZmZzZXRvZihzdHJ1Y3QgY3B1X2luZm8sIHZjcHUp
KTsNCisJREVGSU5FKE9GRlNFVF9WUFNSLAkJCW9mZnNldG9mKHN0cnVjdCBjcHVfaW5mbywgdnNw
c3IpKTsNCisJREVGSU5FKE9GRlNFVF9WU1AsCQkJb2Zmc2V0b2Yoc3RydWN0IGNwdV9pbmZvLCB2
c3ApKTsNCisJREVGSU5FKE9GRlNFVF9WTFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGNwdV9pbmZvLCB2
bHIpKTsNCisJQkxBTksoKTsNCisJREVGSU5FKE9GRlNFVF9WQ1BVX1IwLAkJCW9mZnNldG9mKHN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHIwKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SMSwJ
CQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCByMSkpOw0KKwlERUZJTkUoT0ZG
U0VUX1ZDUFVfUjIsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjIpKTsN
CisJREVGSU5FKE9GRlNFVF9WQ1BVX1IzLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQsIHIzKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SNCwJCQlvZmZzZXRvZihzdHJ1Y3Qg
dmNwdV9ndWVzdF9jb250ZXh0LCByNCkpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjUsCQkJb2Zm
c2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjUpKTsNCisJREVGSU5FKE9GRlNFVF9W
Q1BVX1I2LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI2KSk7DQorCURF
RklORShPRkZTRVRfVkNQVV9SNywJCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0
LCByNykpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjgsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVf
Z3Vlc3RfY29udGV4dCwgcjgpKTsNCisJREVGSU5FKE9GRlNFVF9WQ1BVX1I5LAkJCW9mZnNldG9m
KHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI5KSk7DQorCURFRklORShPRkZTRVRfVkNQVV9S
MTAsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjEwKSk7DQorCURFRklO
RShPRkZTRVRfVkNQVV9SMTEsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwg
cjExKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SMTIsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVf
Z3Vlc3RfY29udGV4dCwgcjEyKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9SMTMsCQkJb2Zmc2V0
b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjEzKSk7DQorCURFRklORShPRkZTRVRfVkNQ
VV9SMTQsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjE0KSk7DQorCURF
RklORShPRkZTRVRfVkNQVV9SMTUsCQkJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4
dCwgcjE1KSk7DQorCURFRklORShPRkZTRVRfVkNQVV9EQUNSLAkJb2Zmc2V0b2Yoc3RydWN0IHZj
cHVfZ3Vlc3RfY29udGV4dCwgZGFjcikpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfVkJBUiwJCW9m
ZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHZiYXIpKTsNCisJREVGSU5FKE9GRlNF
VF9WQ1BVX0NPTlRFWFRJRFIsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBj
b250ZXh0aWRyKSk7DQorCURFRklORShPRkZTRVRfVkNQVV9GQ1NFSURSLAkJb2Zmc2V0b2Yoc3Ry
dWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgZmNzZWlkcikpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVf
VFRCUjAsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCB0dGJyMCkpOw0KKwlE
RUZJTkUoT0ZGU0VUX1ZDUFVfVFRCUjEsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250
ZXh0LCB0dGJyMSkpOw0KKwlERUZJTkUoT0ZGU0VUX1ZDUFVfVFRCQ1IsCQlvZmZzZXRvZihzdHJ1
Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCB0dGJjcikpOw0KKwkvL0RFRklORShPRkZTRVRfSFlQRVJW
SVNPUl9DQUxMQkFDSywJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgZXZlbnRf
Y2FsbGJhY2spKTsNCisJLy9ERUZJTkUoT0ZGU0VUX0ZBSUxTQUZFX0NBTExCQUNLLAlvZmZzZXRv
ZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBmYWlsc2FmZV9jYWxsYmFjaykpOw0KIAlCTEFO
SygpOw0KIA0KIAlyZXR1cm4gMDsgDQpkaWZmIC1yIDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0v
eGVuL2VudHJ5LlMNCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
DQorKysgYi94ZW4vYXJjaC9hcm0veGVuL2VudHJ5LlMJRnJpIEZlYiAwMyAxNzo0NzoxNiAyMDEy
ICswOTAwDQpAQCAtMCwwICsxLDU5NiBAQA0KKy8qDQorICogZW50cnkuUw0KKyAqDQorICogQ29w
eXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcw0KKyAqICAgICAgICAgIFNh
bmctYnVtIFN1aCA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+DQorICogICAgICAgICAgSmFlTWluIFJ5
dSAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExp
Y2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4N
CisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0
IHdpbGwgYmUgdXNlZnVsLA0KKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5F
U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUg
cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFs
b25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJl
DQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3Rv
biwgTUEgIDAyMTExLTEzMDcgIFVTQQ0KKyAqLw0KKyNpbmNsdWRlIDxhc20vcHJvY2Vzc29yLmg+
DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5j
bHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1kb21haW4uaD4NCisj
aW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQorI2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5o
Pg0KKw0KKy5tYWNybyBTQVZFX0NPTlRFWFQJIG9mZnNldCBjb3JyZWN0aW9uDQorCXN1YiAgICAg
bHIsIGxyLCAjXGNvcnJlY3Rpb24NCisJc3RyICAgICByMCwgW3NwLCAjLTE2XQ0KKwlzdHIgICAg
IGxyLCBbc3AsICMtMTJdDQorDQorCW1ycyAgICAgcjAsIHNwc3INCisJbW92ICAgICBsciwgI1xv
ZmZzZXQNCisJc3RyICAgICByMCwgW3NwLCAjLThdDQorCXN0ciAgICAgbHIsIFtzcCwgIy00XQ0K
Kw0KKwlzdWIgICAgIHIwLCBzcCwgIzE2DQorDQorCW1zciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9J
X0JJVCB8IFBTUl9GX0JJVCB8IFBTUl9NT0RFX1NWQykNCisNCisJc3ViCXNwLCBzcCwgI0NUWFRf
RlJBTUVfU0laRQ0KK1NQRklYKAl0c3QJc3AsICM0CQkpDQorU1BGSVgoCWJpY25lCXNwLCBzcCwg
IzQJKQ0KKwlzdG1pYglzcCwge3IxIC0gbHJ9Xg0KKwlsZG1pYQlyMCwge3IxIC0gcjR9DQorCWFk
ZAlyNSwgc3AsICNDVFhUX1NTUA0KKwlhZGQJcjAsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFDQorU1BG
SVgoCWFkZG5lCXIwLCByMCwgIzQJKQ0KKwlzdHIJcjEsIFtzcF0NCisJbW92CXIxLCBscg0KKwlz
dG1pYQlyNSwge3IwIC0gcjR9DQorCW1zcglzcHNyX2N4c2YsIHIzDQorLmVuZG0NCisNCisubWFj
cm8gUkVTVE9SRV9DT05URVhUDQorCWxkcglyMCwgW3NwLCAjQ1RYVF9TUFNSXQ0KKwltc3IJc3Bz
cl9jeHNmLCByMA0KKwlsZG1pYQlzcCwge3IwIC0gbHJ9Xg0KKwlhZGQJc3AsIHNwLCAjQ1RYVF9T
U1ANCisJbGRtaWEJc3AsIHtzcCwgbHIsIHBjfV4NCisuZW5kbQ0KKw0KKwkuYWxpZ24JNQ0KKwku
Z2xvYmFsIGV4Y2VwdGlvbl92ZWN0b3JfdGFibGUNCitleGNlcHRpb25fdmVjdG9yX3RhYmxlOg0K
KwlsZHIJcGMsIC5yc3QNCisJbGRyCXBjLCAudW5kDQorCWxkcglwYywgLnN3aQ0KKwlsZHIJcGMs
IC5wYWJ0DQorCWxkcglwYywgLmRhYnQNCisJbGRyCXBjLCAuYWR4DQorCWxkcglwYywgLmlycQ0K
KwlsZHIJcGMsIC5maXENCisNCisucnN0OgkubG9uZwl2ZWN0b3JfcmVzZXQNCisudW5kOgkubG9u
Zwl2ZWN0b3JfdW5kDQorLnN3aToJLmxvbmcJdmVjdG9yX3N3aQ0KKy5wYWJ0OgkubG9uZwl2ZWN0
b3JfcGFidA0KKy5kYWJ0OgkubG9uZwl2ZWN0b3JfZGFidA0KKy5hZHg6CS5sb25nCXZlY3Rvcl9y
ZXNlcnZlZA0KKy5pcnE6CS5sb25nCXZlY3Rvcl9pcnENCisuZmlxOgkubG9uZwl2ZWN0b3JfZmlx
DQorDQorCS5hbGlnbgk1DQordmVjdG9yX3Jlc2V0Og0KKzE6DQorCWIJMWINCisNCisJLmFsaWdu
CTUNCit2ZWN0b3JfaXJxOg0KKwlTQVZFX0NPTlRFWFQJMHgxOCwgNA0KKw0KKwltcnMJcjAsIHNw
c3INCisJYW5kCXIwLCByMCwgI1BTUl9NT0RFX01BU0sNCisJZW9ycwlyMCwgcjAsICNQU1JfTU9E
RV9TVkMNCisNCisJYm5lCXJldHVybl90b19ndWVzdA0KKw0KKwljcHNpZAlpDQorDQorCVJFU1RP
UkVfQ09OVEVYVA0KKw0KKwkuYWxpZ24JNQ0KK3ZlY3Rvcl9kYWJ0Og0KKwlzdHIJcjAsIFtzcCwg
Iy0xNl0NCisJc3RyCWxyLCBbc3AsICMtMTJdDQorCW1ycyAgICAgcjAsIHNwc3INCisJc3RyICAg
ICByMCwgW3NwLCAjLThdDQorCXN1YiAgICAgcjAsIHNwLCAjMTYNCisNCisJbXNyICAgICBjcHNy
X2N4c2YsICMoUFNSX0lfQklUIHwgUFNSX0ZfQklUIHwgUFNSX01PREVfU1ZDKQ0KKw0KKwlzdWIg
ICAgIHNwLCBzcCwgI0NUWFRfRlJBTUVfU0laRQ0KK1NQRklYKCAgdHN0ICAgICBzcCwgIzQgICAg
ICApDQorU1BGSVgoICBiaWNuZSAgIHNwLCBzcCwgIzQgICkNCisJc3RtaWIgICBzcCwge3IxIC0g
bHJ9Xg0KKwlsZG1pYSAgIHIwLCB7cjEgLSByM30NCisJYWRkICAgICByNSwgc3AsICNDVFhUX1NT
UA0KKwlhZGQgICAgIHIwLCBzcCwgI0NUWFRfRlJBTUVfU0laRQ0KK1NQRklYKCAgYWRkbmUgICBy
MCwgcjAsICM0ICApDQorCXN0ciAgICAgcjEsIFtzcF0NCisJbW92ICAgICByMSwgbHINCisJc3Rt
aWEgICByNSwge3IwIC0gcjN9DQorDQorCW1yYyAgICAgcDE1LCAwLCByMCwgYzYsIGMwLCAwDQor
CW1yYyAgICAgcDE1LCAwLCByMSwgYzUsIGMwLCAwDQorDQorCWFuZAlyNCwgcjMsICNQU1JfTU9E
RV9NQVNLDQorCWVvcnMJcjQsIHI0LCAjUFNSX01PREVfU1ZDDQorDQorCWJlcQlkb19kYXRhX2Fi
b3J0DQorDQorCWNwc2llCWkNCisJCQ0KKwljY2kgICAgIHI4DQorCWxkciAgICAgcjksIFtyOF0N
CisNCisJbGRyICAgICByMTAsIFtyOSwgI09GRlNFVF9WQ1BVX0lORk8gXQ0KKwlsZHIgICAgIHIx
NCwgW3I5LCAjKE9GRlNFVF9BUkNIX1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNF
VF9WQ1BVX1ZCQVIpXQ0KKwljbXAgICAgIHIxNCwgIzANCisJYmVxICAgICB0cmFwX3RhYmxlX2lu
dmFsaWQNCisNCisJYWRkCXIxNCwgcjE0LCAjT0ZGU0VUX1ZFQ1RPUl9EQUJUDQorDQorCXN0ciAg
ICAgcjAsIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1ZGQVIpXQ0KKwlz
dHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9WRlNSKV0N
CisNCisJQCBGb2xsb3dpbmcgaXMgYWRkZWQgdG8gbWl4IGV2dGNobiB1cGNhbGwgbWFzayBhbmQg
cHNyDQorCWxkcglyNCwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQ
U1IpXQ0KKw0KKwlvcnIJcjksIHI0LCAjVlBTUl9JX0JJVA0KKwlzdHIJcjksIFtyMTAsICMoT0ZG
U0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJbGRyICAgICByMCwgW3Nw
LCAjQ1RYVF9VU1BdDQorCWxkciAgICAgcjEsIFtzcCwgI0NUWFRfVUxSXQ0KKw0KKwlsZHIgICAg
IHI1LCBbcjgsICNPRkZTRVRfVlBTUl0NCisJYmljICAgICByMywgcjMsICNQU1JfTU9ERV9NQVNL
DQorCW9yciAgICAgcjMsIHIzLCByNQ0KKw0KKwl0c3QJcjQsICNWUFNSX0lfQklUDQorCW9ycm5l
CXIzLCByMywgI1BTUl9JX0JJVA0KKw0KKwlzdHIgICAgIHIwLCBbcjEwLCAjKE9GRlNFVF9BUkNI
X1ZDUFVfSU5GTyArIE9GRlNFVF9UU1ApXQ0KKwlzdHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQ0KKwlzdHIgICAgIHIzLCBbcjEwLCAjKE9GRlNF
VF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1BTUildDQorDQorCWNtcCAgICAgcjUsICNQU1Jf
TU9ERV9TVkMNCisJbGRybmUgICByMCwgW3I4LCAjOF0NCisNCisJbW92ICAgICByNSwgI1BTUl9N
T0RFX1NWQw0KKwlzdHIgICAgIHI1LCBbcjgsICM0XQ0KKwlzdHIgICAgIHIwLCBbcjgsICM4XQ0K
KwlzdHIgICAgIHIyLCBbcjgsICMxMl0NCisNCisJbGRyICAgICByNSwgPURBQ1JfU1RBVF9TVkMN
CisJbWNyICAgICBwMTUsIDAsIHI1LCBjMywgYzAsIDANCisNCisJY3BzaWQJaQ0KKw0KKwlhZGQg
ICAgIHI4LCByOCwgIzgNCisJbGRtaWEgICByOCwge3IxMywgcjE0fV4NCisJbGRtaWEgICBzcCwg
e3IwLXIxMn0NCisJbGRyICAgICBzcCwgW3NwLCAjQ1RYVF9TU1BdDQorCW1zciAgICAgc3Bzciwg
I1BTUl9NT0RFX1VTUg0KKwltb3ZzICAgIHBjLCBscg0KKw0KKwkuYWxpZ24JNQ0KK3ZlY3Rvcl9w
YWJ0Og0KKwlzdHIgICAgIHIwLCBbc3AsICMtMTZdDQorCXN0ciAgICAgbHIsIFtzcCwgIy0xMl0N
CisJbXJzICAgICByMCwgc3Bzcg0KKwlzdHIgICAgIHIwLCBbc3AsICMtOF0NCisJc3ViICAgICBy
MCwgc3AsICMxNg0KKw0KKwltc3IgICAgIGNwc3JfY3hzZiwgIyhQU1JfSV9CSVQgfCBQU1JfRl9C
SVQgfCBQU1JfTU9ERV9TVkMpDQorDQorCXN1YiAgICAgc3AsIHNwLCAjQ1RYVF9GUkFNRV9TSVpF
DQorU1BGSVgoICB0c3QgICAgIHNwLCAjNCAgICAgICkNCitTUEZJWCggIGJpY25lICAgc3AsIHNw
LCAjNCAgKQ0KKwlzdG1pYiAgIHNwLCB7cjEgLSBscn1eDQorCWxkbWlhICAgcjAsIHtyMSAtIHIz
fQ0KKwlhZGQgICAgIHI1LCBzcCwgI0NUWFRfU1NQDQorCWFkZCAgICAgcjAsIHNwLCAjQ1RYVF9G
UkFNRV9TSVpFDQorU1BGSVgoICBhZGRuZSAgIHIwLCByMCwgIzQgICkNCisJc3RyICAgICByMSwg
W3NwXQ0KKwltb3YgICAgIHIxLCBscg0KKwlzdG1pYSAgIHI1LCB7cjAgLSByM30NCisNCisJbXJj
ICAgICBwMTUsIDAsIHIwLCBjNiwgYzAsIDANCisJbXJjICAgICBwMTUsIDAsIHIxLCBjNSwgYzAs
IDANCisNCisJYW5kICAgICByNCwgcjMsICNQU1JfTU9ERV9NQVNLDQorCWVvcnMgICAgcjQsIHI0
LCAjUFNSX01PREVfU1ZDDQorDQorCWJlcQlkb19wcmVmZXRjaF9hYm9ydA0KKw0KKwljcHNpZQlp
CQkNCisNCisJY2NpICAgICByOA0KKwlsZHIgICAgIHI5LCBbcjhdDQorDQorCWxkciAgICAgcjEw
LCBbcjksICNPRkZTRVRfVkNQVV9JTkZPXQ0KKwlsZHIgICAgIHIxNCwgW3I5LCAjKE9GRlNFVF9B
UkNIX1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNFVF9WQ1BVX1ZCQVIpXQ0KKwlj
bXAgICAgIGxyLCAjMA0KKwliZXEgICAgIHRyYXBfdGFibGVfaW52YWxpZA0KKw0KKwlhZGQJcjE0
LCByMTQsICNPRkZTRVRfVkVDVE9SX1BBQlQNCisNCisJbGRyCXI0LCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildDQorDQorCW9ycglyOSwgcjQsICNWUFNSX0lf
QklUDQorCXN0cglyOSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQ
U1IpXQ0KKw0KKwlsZHIgICAgIHIwLCBbc3AsICNDVFhUX1VTUF0NCisJbGRyICAgICByMSwgW3Nw
LCAjQ1RYVF9VTFJdDQorDQorCWxkciAgICAgcjUsIFtyOCwgIzRdDQorCWJpYyAgICAgcjMsIHIz
LCAjUFNSX01PREVfTUFTSw0KKwlvcnIgICAgIHIzLCByMywgcjUNCisNCisJdHN0CXI0LCAjVlBT
Ul9JX0JJVA0KKwlvcnJuZQlyMywgcjMsICNQU1JfSV9CSVQNCisNCisJc3RyICAgICByMCwgW3Ix
MCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0NCisJc3RyICAgICByMSwg
W3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVExSKV0NCisJc3RyICAgICBy
MywgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQU1IpXQ0KKw0KKwlj
bXAgICAgIHI1LCAjUFNSX01PREVfU1ZDDQorCWxkcm5lICAgcjAsIFtyOCwgIzhdDQorDQorCW1v
diAgICAgcjUsICNQU1JfTU9ERV9TVkMNCisJc3RyICAgICByNSwgW3I4LCAjNF0NCisJc3RyICAg
ICByMCwgW3I4LCAjOF0NCisJc3RyICAgICByMiwgW3I4LCAjMTJdDQorDQorCWxkciAgICAgcjUs
ID1EQUNSX1NUQVRfU1ZDDQorCW1jciAgICAgcDE1LCAwLCByNSwgYzMsIGMwLCAwDQorDQorCWNw
c2lkCWkNCisNCisJYWRkICAgICByOCwgcjgsICM4DQorCWxkbWlhICAgcjgsIHtyMTMsIHIxNH1e
DQorCWxkbWlhICAgc3AsIHtyMC1yMTJ9DQorCWxkciAgICAgc3AsIFtzcCwgI0NUWFRfU1NQXQ0K
Kwltc3IgICAgIHNwc3IsICNQU1JfTU9ERV9VU1INCisJbW92cyAgICBwYywgbHINCisNCisJLmFs
aWduCTUNCit2ZWN0b3JfdW5kOg0KKwlzdHIgICAgIHIwLCBbc3AsICMtMTZdDQorCXN0ciAgICAg
bHIsIFtzcCwgIy0xMl0NCisJbXJzICAgICByMCwgc3Bzcg0KKwlzdHIgICAgIHIwLCBbc3AsICMt
OF0NCisJc3ViICAgICByMCwgc3AsICMxNg0KKw0KKwltc3IgICAgIGNwc3JfY3hzZiwgIyhQU1Jf
SV9CSVQgfCBQU1JfRl9CSVQgfCBQU1JfTU9ERV9TVkMpDQorDQorCXN1YiAgICAgc3AsIHNwLCAj
Q1RYVF9GUkFNRV9TSVpFDQorU1BGSVgoICB0c3QgICAgIHNwLCAjNCAgICAgICkNCitTUEZJWCgg
IGJpY25lICAgc3AsIHNwLCAjNCAgKQ0KKwlzdG1pYiAgIHNwLCB7cjEgLSBscn1eDQorCWxkbWlh
ICAgcjAsIHtyMSAtIHIzfQ0KKwlhZGQgICAgIHI1LCBzcCwgI0NUWFRfU1NQDQorCWFkZCAgICAg
cjAsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFDQorU1BGSVgoICBhZGRuZSAgIHIwLCByMCwgIzQgICkN
CisJc3RyICAgICByMSwgW3NwXQ0KKwltb3YgICAgIHIxLCBscg0KKwlzdG1pYSAgIHI1LCB7cjAg
LSByM30NCisNCisJYW5kICAgICByNCwgcjMsICNQU1JfTU9ERV9NQVNLDQorCWVvcnMgICAgcjQs
IHI0LCAjUFNSX01PREVfU1ZDDQorDQorCWJlcSAgICAgZG9fdW5kZWZpbmVkX2luc3RydWN0aW9u
DQorDQorCWNwc2llCWkNCisNCisJY2NpICAgICByOA0KKwlsZHIgICAgIHI5LCBbcjhdDQorDQor
CWxkciAgICAgcjEwLCBbcjksICNPRkZTRVRfVkNQVV9JTkZPXQ0KKwlsZHIgICAgIHIxNCwgW3I5
LCAjKE9GRlNFVF9BUkNIX1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNFVF9WQ1BV
X1ZCQVIpXQ0KKwljbXAgICAgIGxyLCAjMA0KKwliZXEgICAgIHRyYXBfdGFibGVfaW52YWxpZA0K
Kw0KKwlhZGQJcjE0LCByMTQsICNPRkZTRVRfVkVDVE9SX1VORA0KKw0KKwlsZHIJcjQsIFtyMTAs
ICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJb3JyCXI5LCBy
NCwgI1ZQU1JfSV9CSVQNCisJc3RyCXI5LCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyAr
IE9GRlNFVF9UQ1BTUildDQorDQorCWxkciAgICAgcjAsIFtzcCwgI0NUWFRfVVNQXQ0KKwlsZHIg
ICAgIHIxLCBbc3AsICNDVFhUX1VMUl0NCisNCisJbGRyICAgICByNSwgW3I4LCAjNF0NCisJYmlj
ICAgICByMywgcjMsICNQU1JfTU9ERV9NQVNLDQorCW9yciAgICAgcjMsIHIzLCByNQ0KKw0KKwl0
c3QJcjQsICNWUFNSX0lfQklUDQorCW9ycm5lCXIzLCByMywgI1BTUl9JX0JJVA0KKw0KKwlzdHIg
ICAgIHIwLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1ApXQ0KKwlz
dHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQ0K
KwlzdHIgICAgIHIzLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1BT
UildDQorDQorCWNtcCAgICAgcjUsICNQU1JfTU9ERV9TVkMNCisJbGRybmUgICByMCwgW3I4LCAj
OF0NCisNCisJbW92ICAgICByNSwgI1BTUl9NT0RFX1NWQw0KKwlzdHIgICAgIHI1LCBbcjgsICM0
XQ0KKwlzdHIgICAgIHIwLCBbcjgsICM4XQ0KKwlzdHIgICAgIHIyLCBbcjgsICMxMl0NCisJc3Ry
ICAgICByMSwgW3I4LCAjMTZdDQorDQorCWxkciAgICAgcjUsID1EQUNSX1NUQVRfU1ZDDQorCW1j
ciAgICAgcDE1LCAwLCByNSwgYzMsIGMwLCAwDQorDQorCWNwc2lkCWkNCisNCisJYWRkICAgICBy
OCwgcjgsICM4DQorCWxkbWlhICAgcjgsIHtyMTMsIHIxNH1eDQorCWxkbWlhICAgc3AsIHtyMC1y
MTJ9DQorCWxkciAgICAgc3AsIFtzcCwgI0NUWFRfU1NQXQ0KKwltc3IgICAgIHNwc3IsICNQU1Jf
TU9ERV9VU1INCisJbW92cyAgICBwYywgbHINCisNCisJLmFsaWduCTUNCit2ZWN0b3JfZmlxOg0K
KwlzdWJzICAgIHBjLCBsciwgIzQNCisNCisJLmFsaWduCTUNCit2ZWN0b3JfcmVzZXJ2ZWQ6DQor
CWIJdmVjdG9yX3Jlc2VydmVkDQorDQorCS5hbGlnbgk1DQordHJhcF90YWJsZV9pbnZhbGlkOg0K
KwliCXRyYXBfdGFibGVfaW52YWxpZA0KKw0KKwkuYWxpZ24JNQ0KK3ZlY3Rvcl9zd2k6DQorCXN0
cglzcCwgW3NwLCAjKENUWFRfU1NQIC0gQ1RYVF9GUkFNRV9TSVpFKV0NCisJc3ViICAgICBzcCwg
c3AsICNDVFhUX0ZSQU1FX1NJWkUNCisJc3RtaWEgICBzcCwge3IwIC0gbHJ9Xg0KKwltcnMgICAg
IHIxMSwgc3Bzcg0KKwlzdHIgICAgIHIxNCwgW3NwLCAjQ1RYVF9QQ10NCisJc3RyICAgICByMTEs
IFtzcCwgI0NUWFRfU1BTUl0NCisNCisJY3BzaWUJaQ0KKw0KKwljY2kJcjgNCisJbGRyCXIxMiwg
W3I4LCAjNF0NCisJZW9ycwlyMTIsIHIxMiwgI1BTUl9NT0RFX1NWQw0KKw0KKwliZXEJaW52b2tl
X2h5cGVyY2FsbA0KKwkJDQorCW1vdglyMTIsICNQU1JfTU9ERV9TVkMNCisJc3RyICAgICByMTIs
IFtyOCwgIzRdDQorCXN0ciAgICAgcjE0LCBbcjgsICMxMl0NCisNCisJbGRyICAgICByOSwgW3I4
XQ0KKwlsZHIgICAgIHIxMCwgW3I5LCAjT0ZGU0VUX1ZDUFVfSU5GT10NCisJbGRyICAgICByMTQs
IFtyOSwgIyhPRkZTRVRfQVJDSF9WQ1BVICsgT0ZGU0VUX0dVRVNUX0NPTlRFWFQgKyBPRkZTRVRf
VkNQVV9WQkFSKV0NCisJY21wICAgICByMTQsICMwDQorCWJlcQl0cmFwX3RhYmxlX2ludmFsaWQN
CisNCisJYWRkCXIxNCwgcjE0LCAjT0ZGU0VUX1ZFQ1RPUl9TV0kNCisNCisJbGRyCXI0LCBbcjEw
LCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildDQorDQorCW9ycglyOSwg
cjQsICNWUFNSX0lfQklUDQorCXN0cglyOSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8g
KyBPRkZTRVRfVENQU1IpXQ0KKw0KKwl0c3QJcjQsICNWUFNSX0lfQklUDQorCW9ycm5lCXIxMSwg
cjExLCAjUFNSX0lfQklUDQorDQorCWxkciAgICAgcjQsIFtzcCwgI0NUWFRfVVNQXQ0KKwlsZHIg
ICAgIHI1LCBbc3AsICNDVFhUX1VMUl0NCisNCisJc3RyICAgICByNCwgW3IxMCwgIyhPRkZTRVRf
QVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0NCisJc3RyICAgICByNSwgW3IxMCwgIyhPRkZT
RVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVExSKV0NCisJc3RyICAgICByMTEsIFtyMTAsICMo
T0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0NCisNCisJbGRyICAgICByMTEs
ID1EQUNSX1NUQVRfU1ZDDQorCW1jciAgICAgcDE1LCAwLCByMTEsIGMzLCBjMCwgMA0KKw0KKwlj
cHNpZAlpDQorDQorCWFkZCAgICAgcjgsIHI4LCAjOA0KKwlsZG1pYSAgIHI4LCB7cjEzLCByMTR9
Xg0KKwlsZG1pYSAgIHNwLCB7cjAtcjEyfQ0KKwlsZHIgICAgIHNwLCBbc3AsICNDVFhUX1NTUF0N
CisJbXNyICAgICBzcHNyLCAjUFNSX01PREVfVVNSDQorCW1vdnMgICAgcGMsIGxyDQorDQoraW52
b2tlX2h5cGVyY2FsbDoNCisJbGRyICAgICByMTIsIFtsciwgIy00XQ0KKwliaWMgICAgIHIxMiwg
cjEyLCAjMHhmZjAwMDAwMA0KKw0KKwlhZHIgICAgIHIxNCwgMWYNCisJYWRyICAgICByMTEsIGh5
cGVyY2FsbF90YWJsZQ0KKwlsZHIgICAgIHBjLCBbcjExLCByMTIsIGxzbCAjMl0NCisNCisxOg0K
KwlzdHIgICAgIHIwLCBbc3AsICNDVFhUX1IwXQ0KKw0KKwliCXJldHVybl90b19ndWVzdA0KKw0K
K0VOVFJZKHJldHVybl90b19ndWVzdCkJDQorCWNwc2llCWkNCisJYmwJZG9fc29mdGlycQ0KKw0K
KwljY2kJcjgNCisJbGRyCXIxMCwgW3I4LCAjT0ZGU0VUX1ZDUFVdDQorDQorCWxkcglyMTEsIFty
MTAsICNPRkZTRVRfVkNQVV9JTkZPXQ0KKwlsZHIJcjksIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQ
VV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJdHN0CXI5LCAjVlBTUl9JX0JJVA0KKwlibmUJ
cmVzdW1lX2d1ZXN0X2RvbWFpbg0KKw0KKwlsZHIJcjEyLCBbcjExLCAjT0ZGU0VUX0VWVENITl9V
UENBTExfUEVORElOR10NCisNCisJdHN0CXIxMiwgIzB4RkYNCisJYmVxCXJlc3VtZV9ndWVzdF9k
b21haW4NCisNCitkb191cGNhbGw6DQorCWxkciAgICAgcjE0LCBbcjEwLCAjKE9GRlNFVF9BUkNI
X1ZDUFUgKyBPRkZTRVRfR1VFU1RfQ09OVEVYVCArIE9GRlNFVF9WQ1BVX1ZCQVIpXQ0KKwljbXAJ
bHIsICMwDQorCWJlcQl0cmFwX3RhYmxlX2ludmFsaWQNCisNCisJYWRkCXIxNCwgcjE0LCAjT0ZG
U0VUX1ZFQ1RPUl9JUlENCisNCisJbGRyCXI0LCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5G
TyArIE9GRlNFVF9UQ1BTUildDQorDQorCW9ycglyOSwgcjQsICNWUFNSX0lfQklUDQorCXN0cgly
OSwgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQ0KKw0KKwls
ZHIJcjAsIFtzcCwgI0NUWFRfVVNQXQ0KKwlsZHIJcjEsIFtzcCwgI0NUWFRfVUxSXQ0KKwlsZHIJ
cjIsIFtzcCwgI0NUWFRfUENdDQorCWxkcglyMywgW3NwLCAjQ1RYVF9TUFNSXQ0KKw0KKwlsZHIJ
cjUsIFtyOCwgIzRdDQorCWJpYwlyMywgcjMsICNQU1JfTU9ERV9NQVNLDQorCW9ycglyMywgcjMs
IHI1DQorDQorCXRzdAlyNCwgI1ZQU1JfSV9CSVQNCisJb3JybmUJcjMsIHIzLCAjUFNSX0lfQklU
DQorDQorCXN0cglyMCwgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQ
KV0NCisJc3RyCXIxLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIp
XQ0KKwlzdHIJcjMsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNS
KV0NCisNCisJY21wCXI1LCAjUFNSX01PREVfU1ZDDQorCWxkcm5lCXIwLCBbcjgsICM4XQ0KKw0K
Kwltb3YJcjUsICNQU1JfTU9ERV9TVkMNCisJc3RyCXI1LCBbcjgsICM0XQ0KKwlzdHIJcjAsIFty
OCwgIzhdDQorCXN0cglyMiwgW3I4LCAjMTJdDQorDQorCWxkcglyNSwgPURBQ1JfU1RBVF9TVkMN
CisJbWNyICAgICBwMTUsIDAsIHI1LCBjMywgYzAsIDANCisJDQorCWNwc2lkCWkNCisNCisJYWRk
CXI4LCByOCwgIzgNCisJbGRtaWEJcjgsIHtyMTMsIHIxNH1eDQorCWxkbWlhCXNwLCB7cjAtcjEy
fQ0KKwlsZHIJc3AsIFtzcCwgI0NUWFRfU1NQXQ0KKwltc3IJc3BzciwgI1BTUl9NT0RFX1VTUg0K
Kwltb3ZzCXBjLCBscg0KKw0KK3Jlc3VtZV9ndWVzdF9kb21haW46DQorCWNjaQlyOA0KKwlsZHIJ
cjMsIFtyOCwgI09GRlNFVF9WUFNSXQ0KKwlsZHIJaXAsIFtzcCwgI0NUWFRfU1BTUl0NCisJY21w
CXIzLCAjUFNSX01PREVfU1ZDDQorDQorCWxkcm5lCXI3LCA9REFDUl9TVEFUX0hZUA0KKwlsZHJl
cSAgIHI3LCA9REFDUl9TVEFUX1NWQw0KKwltY3IJcDE1LCAwLCByNywgYzMsIGMwLCAwDQorDQor
CWNwc2lkCWkNCisNCisJUkVTVE9SRV9DT05URVhUDQorDQorLyoNCisgKiBQcm90b3R5cGUgOiBf
X3N3aXRjaF90byhzdHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICosIHN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgKikNCisgKi8NCisJCS5hbGlnbgk1DQorRU5UUlkoc3dp
dGNoX3RvKQ0KKwlhZGQgICAgIGlwLCByMSwgI09GRlNFVF9WQ1BVX1I0DQorCXN0bWlhICAgaXAs
IHtyNCAtIHNsLCBmcCwgaXAsIHNwLCBscn0NCisNCisJbXJjCXAxNSwgMCwgcjQsIGMzLCBjMCwg
MA0KKwltcmMJcDE1LCAwLCByNywgYzEzLCBjMCwgMQ0KKw0KKwlzdHIJcjQsIFtyMSwgI09GRlNF
VF9WQ1BVX0RBQ1JdDQorCXN0cglyNywgW3IxLCAjT0ZGU0VUX1ZDUFVfQ09OVEVYVElEUl0NCisN
CisJbGRyCXI0LCBbcjIsICNPRkZTRVRfVkNQVV9EQUNSXQ0KKwlsZHIJcjcsIFtyMiwgI09GRlNF
VF9WQ1BVX0NPTlRFWFRJRFJdDQorDQorCW1jcglwMTUsIDAsIHI0LCBjMywgYzAsIDANCisJbWNy
CXAxNSwgMCwgcjcsIGMxMywgYzAsIDENCisNCisJYWRkCWlwLCByMiwgI09GRlNFVF9WQ1BVX1I0
DQorCWxkbWlhICAgaXAsICB7cjQgLSBzbCwgZnAsIGlwLCBzcCwgbHJ9DQorIA0KKwliCWNvbnRl
eHRfc2F2ZWQNCisNCisJLmFsaWduCTUNCisJLnR5cGUgaHlwZXJjYWxsX3RhYmxlLCAjb2JqZWN0
DQorRU5UUlkoaHlwZXJjYWxsX3RhYmxlKQ0KKwkubG9uZwlkb19zZXRfdHJhcF90YWJsZQkvKiAg
MCAqLw0KKwkubG9uZwlkb19tbXVfdXBkYXRlDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyog
c2V0X2dkdCAqLw0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIHN0YWNrX3N3aXRjaCAqLw0K
KwkubG9uZwlkb19zZXRfY2FsbGJhY2tzCQ0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIGZw
dV9zd2l0Y2ggKi8NCisJLmxvbmcJZG9fc2NoZWRfb3BfY29tcGF0DQorCS5sb25nCWRvX25pX2h5
cGVyY2FsbAkJDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbA0KKwkubG9uZwlkb19uaV9oeXBlcmNh
bGwNCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKiAxMCAqLw0KKwkubG9uZwlkb19uaV9oeXBl
cmNhbGwNCisJLmxvbmcJZG9fbWVtb3J5X29wDQorCS5sb25nCWRvX211bHRpY2FsbA0KKwkubG9u
Zwlkb191cGRhdGVfdmFfbWFwcGluZw0KKwkubG9uZwlkb19zZXRfdGltZXJfb3AJCS8qIDE1ICov
DQorCS5sb25nCWRvX2V2ZW50X2NoYW5uZWxfb3ANCisJLmxvbmcJZG9feGVuX3ZlcnNpb24NCisJ
LmxvbmcJZG9fY29uc29sZV9pbw0KKwkubG9uZwlkb19waHlzZGV2X29wDQorCS5sb25nCWRvX2dy
YW50X3RhYmxlX29wCS8qIDIwICovDQorCS5sb25nCWRvX3ZtX2Fzc2lzdA0KKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwNCisJLmxvbmcJZG9fcmVzdG9yZV90cmFwX2ZyYW1lDQorCS5sb25nCWRvX3Zj
cHVfb3ANCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKiAyNSAqLw0KKwkubG9uZwlkb19tbXVl
eHRfb3ANCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsDQorCS5sb25nCWRvX25taV9vcA0KKwkubG9u
Zwlkb19zY2hlZF9vcA0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDMwIDogY2FsbGJhY2tv
cAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKgl4ZW5vcHJvZgkJKi8NCisJLmxvbmcJ
ZG9fbmlfaHlwZXJjYWxsCQkvKglldmVudF9jaGFubmVsX29wCSovDQorCS5sb25nCWRvX25pX2h5
cGVyY2FsbAkJLyoJcGh5c2Rldl9vcAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKglo
dm1fb3AJCQkqLw0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDM1IDogc3lzY3RsCQkJKi8N
CisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKiAgICAgIGRvbWN0bAkJCSovDQorCS5sb25nCWRv
X25pX2h5cGVyY2FsbAkJLyoJa2V4ZWNfb3AJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJ
LyoJdG1lbV9vcAkJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJeGNfcmVzZXJ2ZWRf
b3AJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyogNDAgOiB1bmRlZmluZWQJCSovDQor
CS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLw0KKwkubG9uZwlkb19uaV9o
eXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkvKgl1
bmRlZmluZWQJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLw0K
KwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDQ1IDogdW5kZWZpbmVkCQkqLw0KKwkubG9uZwlk
b19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxs
CQkvKgl1bmRlZmluZWQJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVk
CQkqLw0KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJ
ZG9fbmlfaHlwZXJjYWxsCQkvKiA1MCA6CXVuZGVmaW5lZAkJKi8NCisJLmxvbmcJZG9fbmlfaHlw
ZXJjYWxsCQkvKgl1bmRlZmluZWQJCSovDQorCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyogCXVu
ZGVmaW5lZAkJKi8NCisNCisgICAgICAgIC5zZWN0aW9uIC5kYXRhDQorRU5UUlkoeGVuX3RyYW5z
bGF0aW9uX3RhYmxlKQ0KKyAgICAgICAgLmxvbmcgICBzdGFydCAtIDB4NDAwMA0KKw0KZGlmZiAt
ciAyOGE2MDM4ZGE5OWYgeGVuL2FyY2gvYXJtL3hlbi9oeXBlcmNhbGxzLlMNCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVu
L2h5cGVyY2FsbHMuUwlGcmkgRmViIDAzIDE3OjQ3OjE2IDIwMTIgKzA5MDANCkBAIC0wLDAgKzEs
NjcgQEANCisvKg0KKyAqIGh5cGVyY2FsbHMuUw0KKyAqDQorICogQ29weXJpZ2h0IChDKSAyMDA4
LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcw0KKyAqICAgICAgICAgIFNhbmctYnVtIFN1aCA8c2J1
ay5zdWhAc2Ftc3VuZy5jb20+DQorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBz
YW1zdW5nLmNvbT4NCisgKg0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlz
aGVkIGJ5DQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCisgKg0KKyAqIFRoaXMg
cHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVs
LA0KKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVk
IHdhcnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv
ciBtb3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFsb25nIHdpdGggdGhpcyBw
cm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQorICogRm91bmRhdGlv
biwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEz
MDcgIFVTQQ0KKyAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+DQorI2luY2x1ZGUgPGFz
bS9wcm9jZXNzb3IuaD4NCisjaW5jbHVkZSA8YXNtL3BhZ2UuaD4NCisjaW5jbHVkZSA8YXNtL3N5
c3RlbS5oPg0KKyNpbmNsdWRlIDxhc20vY3B1LWRvbWFpbi5oPg0KKyNpbmNsdWRlIDxhc20vYXNt
LW9mZnNldHMuaD4NCisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4NCisNCisjaW5jbHVkZSA8
cHVibGljL2FyY2gtYXJtLmg+DQorDQorDQorRU5UUlkoZG9fc2V0X2RvbWFpbikNCisgICAgICAg
IG1vdiAgICAgcGMsIGxyDQorDQorDQorRU5UUlkoZG9fcmVzdG9yZV90cmFwX2ZyYW1lKQ0KKwlj
Y2kJcjgNCisJbGRyCXI0LCBbcjgsICNPRkZTRVRfVkNQVV0NCisJbGRyCXI2LCBbc3AsICNDVFhU
X1VTUF0NCisJbGRyCXIxMSwgW3I0LCAjT0ZGU0VUX1ZDUFVfSU5GT10NCisNCisJbGRyICAgICBy
MywgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQU1IpXQ0KKwlsZHIg
ICAgIHIyLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQ0KKwls
ZHIgICAgIHIxLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UU1ApXQ0K
Kw0KKwlsZHIJcjcsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNS
KV0NCisNCisJdHN0CXIzLCAjUFNSX0lfQklUDQorCW9ycm5lCXI3LCAjVlBTUl9JX0JJVA0KKwli
aWNlcQlyNywgI1ZQU1JfSV9CSVQNCisNCisJYmljCXI1LCByMywgIyhQU1JfTU9ERV9NQVNLIHwg
UFNSX0lfQklUKQ0KKwlvcnIJcjUsIHI1LCAjUFNSX01PREVfVVNSDQorCWFuZAlyMywgcjMsICNQ
U1JfTU9ERV9NQVNLDQorDQorCUAgQ29uc3RydWN0IGxhdGVzdCBndWVzdCBjb250ZXh0DQorCXN0
cglyMSwgW3NwLCAjQ1RYVF9VU1BdDQorCXN0cglyMiwgW3NwLCAjQ1RYVF9QQ10NCisJc3RyCXI1
LCBbc3AsICNDVFhUX1NQU1JdDQorCXN0cglyMywgW3I4LCAjNF0NCisJc3RyCXI2LCBbcjgsICM4
XQ0KKw0KKwlAIFVwZGF0ZSBWUFNSDQorCXN0ciAgICByNywgW3IxMSwgIyhPRkZTRVRfQVJDSF9W
Q1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQ0KKw0KKwltb3YJcGMsIGxyDQpkaWZmIC1yIDI4YTYw
MzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL3BoeXNkZXYuYw0KLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDANCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vcGh5c2Rldi5j
CUZyaSBGZWIgMDMgMTc6NDc6MTYgMjAxMiArMDkwMA0KQEAgLTAsMCArMSw0MSBAQA0KKy8qDQor
ICogcGh5c2Rldi5jDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBTYW1zdW5nIEVs
ZWN0cm9uaWNzDQorICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNv
bT4NCisgKiAgICAgICAgICBKYWVNaW4gUnl1ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPg0KKyAq
DQorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vciBtb2RpZnkNCisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCisgKiB0aGUg
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0KKyAqDQorICogVGhpcyBwcm9ncmFtIGlzIGRpc3Ry
aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQorICogYnV0IFdJVEhP
VVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlDQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4N
CisgKg0KKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlDQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwg
d3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1w
bGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQorICovDQor
DQorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4NCisjaW5jbHVkZSA8eGVuL2xpYi5oPg0KKyNpbmNs
dWRlIDx4ZW4vdHlwZXMuaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisjaW5jbHVkZSA8eGVu
L2Vycm5vLmg+DQorI2luY2x1ZGUgPHhlbi9zcGlubG9jay5oPg0KKyNpbmNsdWRlIDx4ZW4vYml0
bWFwLmg+DQorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KKyNpbmNsdWRlIDx4ZW4vZXZlbnQuaD4N
CisjaW5jbHVkZSA8eGVuL2lycS5oPg0KKyNpbmNsdWRlIDx4ZW4vZ3Vlc3RfYWNjZXNzLmg+DQor
I2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5oPg0KKyNpbmNsdWRlIDxwdWJsaWMvcGh5c2Rldi5o
Pg0KKw0KK2ludCBkb19waHlzZGV2X29wKGludCBjbWQsIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkg
YXJnKQ0KK3sNCisJTk9UX1lFVCgpOw0KKw0KKwlyZXR1cm4gLUVJTlZBTDsNCit9DQo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch05.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch05.diff"


YXJtOiBpbXBsZW1lbnQgZXhjZXB0aW9uIGFuZCBoeXBlcmNhbGwgZW50cmllcy4KCiB4ZW4v
YXJjaC9hcm0veGVuL01ha2VmaWxlICAgICAgfCAgICAzICsKIHhlbi9hcmNoL2FybS94ZW4v
YXNtLW9mZnNldHMuYyB8ICAgNjEgKysrKysrKysKIHhlbi9hcmNoL2FybS94ZW4vZW50cnku
UyAgICAgICB8ICA1OTYgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4v
YXJjaC9hcm0veGVuL2h5cGVyY2FsbHMuUyAgfCAgIDY3ICsrKysrKysrKwogeGVuL2FyY2gv
YXJtL3hlbi9waHlzZGV2LmMgICAgIHwgICA0MSArKysrKwogNSBmaWxlcyBjaGFuZ2VkLCA3
NjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKClNpZ25lZC1vZmYtYnk6IEphZW1p
biBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciAyOGE2MDM4ZGE5OWYgeGVu
L2FyY2gvYXJtL3hlbi9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxl
CUZyaSBGZWIgMDMgMTc6Mjg6MzQgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVu
L01ha2VmaWxlCUZyaSBGZWIgMDMgMTc6NDc6MTYgMjAxMiArMDkwMApAQCAtMSw1ICsxLDgg
QEAKIG9iai15ICs9IHN0YXJ0Lm8KIG9iai15ICs9IHNldHVwLm8KK29iai15ICs9IGVudHJ5
Lm8KK29iai15ICs9IGh5cGVyY2FsbHMubworb2JqLXkgKz0gcGh5c2Rldi5vCiBvYmoteSAr
PSBtbS5vCiBvYmoteSArPSBpcnEubwogb2JqLXkgKz0gYXJjaF9kb21haW4ubwpkaWZmIC1y
IDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL2FzbS1vZmZzZXRzLmMKLS0tIGEveGVu
L2FyY2gvYXJtL3hlbi9hc20tb2Zmc2V0cy5jCUZyaSBGZWIgMDMgMTc6Mjg6MzQgMjAxMiAr
MDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2FzbS1vZmZzZXRzLmMJRnJpIEZlYiAwMyAx
Nzo0NzoxNiAyMDEyICswOTAwCkBAIC0zNCw2ICszNCw2NyBAQAogCiBpbnQgbWFpbih2b2lk
KQogeworCURFRklORShPRkZTRVRfU09GVElSUV9QRU5ESU5HLAkJb2Zmc2V0b2Yoc3RydWN0
IGlycV9jcHVzdGF0LCBfX3NvZnRpcnFfcGVuZGluZykpOworCURFRklORShPRkZTRVRfTE9D
QUxfSVJRX0NPVU5ULAkJb2Zmc2V0b2Yoc3RydWN0IGlycV9jcHVzdGF0LCBfX2xvY2FsX2ly
cV9jb3VudCkpOworCURFRklORShPRkZTRVRfTk1JX0NPVU5ULAkJb2Zmc2V0b2Yoc3RydWN0
IGlycV9jcHVzdGF0LCBfX25taV9jb3VudCkpOworCURFRklORShTSVpFX0lSUV9DUFVfU1RB
VCwJCXNpemVvZihzdHJ1Y3QgaXJxX2NwdXN0YXQpKTsKKwlCTEFOSygpOworCURFRklORShP
RkZTRVRfVkNQVV9JTkZPLAkJb2Zmc2V0b2Yoc3RydWN0IHZjcHUsIHZjcHVfaW5mbykpOwor
CURFRklORShPRkZTRVRfQVJDSF9WQ1BVLAkJb2Zmc2V0b2Yoc3RydWN0IHZjcHUsIGFyY2gp
KTsKKwlCTEFOSygpOworCURFRklORShPRkZTRVRfRVZUQ0hOX1VQQ0FMTF9NQVNLLAlvZmZz
ZXRvZihzdHJ1Y3QgdmNwdV9pbmZvLCBldnRjaG5fdXBjYWxsX21hc2spKTsKKwlERUZJTkUo
T0ZGU0VUX0VWVENITl9VUENBTExfUEVORElORywJb2Zmc2V0b2Yoc3RydWN0IHZjcHVfaW5m
bywgZXZ0Y2huX3VwY2FsbF9wZW5kaW5nKSk7CisJREVGSU5FKE9GRlNFVF9BUkNIX1ZDUFVf
SU5GTywJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2luZm8sIGFyY2gpKTsKKwlERUZJTkUoT0ZG
U0VUX1RTUCwJCQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIHNwKSk7CisJREVG
SU5FKE9GRlNFVF9UTFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZvLCBscikp
OworCURFRklORShPRkZTRVRfVENQU1IsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9p
bmZvLCBjcHNyKSk7CisJREVGSU5FKE9GRlNFVF9UU1BTUiwJCQlvZmZzZXRvZihzdHJ1Y3Qg
YXJjaF92Y3B1X2luZm8sIHNwc3IpKTsKKwlERUZJTkUoT0ZGU0VUX1ZDUiwJCQlvZmZzZXRv
ZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIGNyKSk7CisJREVGSU5FKE9GRlNFVF9WREFDUiwJ
CQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1X2luZm8sIGRhY3IpKTsKKwlERUZJTkUoT0ZG
U0VUX1ZDUEFSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNoX3ZjcHVfaW5mbywgY3BhcikpOwor
CURFRklORShPRkZTRVRfVlBJRFIsCQkJb2Zmc2V0b2Yoc3RydWN0IGFyY2hfdmNwdV9pbmZv
LCBwaWRyKSk7CisJREVGSU5FKE9GRlNFVF9WRlNSLAkJCW9mZnNldG9mKHN0cnVjdCBhcmNo
X3ZjcHVfaW5mbywgZnNyKSk7CisJREVGSU5FKE9GRlNFVF9WRkFSLAkJCW9mZnNldG9mKHN0
cnVjdCBhcmNoX3ZjcHVfaW5mbywgZmFyKSk7CisJQkxBTksoKTsKKwlERUZJTkUoT0ZGU0VU
X0dVRVNUX0NPTlRFWFQsCQlvZmZzZXRvZihzdHJ1Y3QgYXJjaF92Y3B1LCBjdHgpKTsKKwlE
RUZJTkUoT0ZGU0VUX1ZFQ1RPUl9SRVNFVCwJCTApOworCURFRklORShPRkZTRVRfVkVDVE9S
X1VORCwJCTQpOworCURFRklORShPRkZTRVRfVkVDVE9SX1NXSSwJCTgpOworCURFRklORShP
RkZTRVRfVkVDVE9SX1BBQlQsCQkxMik7CisJREVGSU5FKE9GRlNFVF9WRUNUT1JfREFCVCwJ
CTE2KTsKKwlERUZJTkUoT0ZGU0VUX1ZFQ1RPUl9JUlEsCQkyNCk7CisJREVGSU5FKE9GRlNF
VF9WRUNUT1JfRklRLAkJMjgpOworCUJMQU5LKCk7CisJREVGSU5FKE9GRlNFVF9WQ1BVLAkJ
CW9mZnNldG9mKHN0cnVjdCBjcHVfaW5mbywgdmNwdSkpOworCURFRklORShPRkZTRVRfVlBT
UiwJCQlvZmZzZXRvZihzdHJ1Y3QgY3B1X2luZm8sIHZzcHNyKSk7CisJREVGSU5FKE9GRlNF
VF9WU1AsCQkJb2Zmc2V0b2Yoc3RydWN0IGNwdV9pbmZvLCB2c3ApKTsKKwlERUZJTkUoT0ZG
U0VUX1ZMUiwJCQlvZmZzZXRvZihzdHJ1Y3QgY3B1X2luZm8sIHZscikpOworCUJMQU5LKCk7
CisJREVGSU5FKE9GRlNFVF9WQ1BVX1IwLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0
X2NvbnRleHQsIHIwKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1IxLAkJCW9mZnNldG9mKHN0
cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHIxKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1Iy
LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHIyKSk7CisJREVGSU5F
KE9GRlNFVF9WQ1BVX1IzLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQs
IHIzKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I0LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1
X2d1ZXN0X2NvbnRleHQsIHI0KSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I1LAkJCW9mZnNl
dG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI1KSk7CisJREVGSU5FKE9GRlNFVF9W
Q1BVX1I2LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI2KSk7CisJ
REVGSU5FKE9GRlNFVF9WQ1BVX1I3LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2Nv
bnRleHQsIHI3KSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I4LAkJCW9mZnNldG9mKHN0cnVj
dCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI4KSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1I5LAkJ
CW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIHI5KSk7CisJREVGSU5FKE9G
RlNFVF9WQ1BVX1IxMCwJCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBy
MTApKTsKKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjExLAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1
X2d1ZXN0X2NvbnRleHQsIHIxMSkpOworCURFRklORShPRkZTRVRfVkNQVV9SMTIsCQkJb2Zm
c2V0b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjEyKSk7CisJREVGSU5FKE9GRlNF
VF9WQ1BVX1IxMywJCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCByMTMp
KTsKKwlERUZJTkUoT0ZGU0VUX1ZDUFVfUjE0LAkJCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1
ZXN0X2NvbnRleHQsIHIxNCkpOworCURFRklORShPRkZTRVRfVkNQVV9SMTUsCQkJb2Zmc2V0
b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgcjE1KSk7CisJREVGSU5FKE9GRlNFVF9W
Q1BVX0RBQ1IsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBkYWNyKSk7
CisJREVGSU5FKE9GRlNFVF9WQ1BVX1ZCQVIsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVz
dF9jb250ZXh0LCB2YmFyKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX0NPTlRFWFRJRFIsCQlv
ZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBjb250ZXh0aWRyKSk7CisJREVG
SU5FKE9GRlNFVF9WQ1BVX0ZDU0VJRFIsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9j
b250ZXh0LCBmY3NlaWRyKSk7CisJREVGSU5FKE9GRlNFVF9WQ1BVX1RUQlIwLAkJb2Zmc2V0
b2Yoc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCwgdHRicjApKTsKKwlERUZJTkUoT0ZGU0VU
X1ZDUFVfVFRCUjEsCQlvZmZzZXRvZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCB0dGJy
MSkpOworCURFRklORShPRkZTRVRfVkNQVV9UVEJDUiwJCW9mZnNldG9mKHN0cnVjdCB2Y3B1
X2d1ZXN0X2NvbnRleHQsIHR0YmNyKSk7CisJLy9ERUZJTkUoT0ZGU0VUX0hZUEVSVklTT1Jf
Q0FMTEJBQ0ssCW9mZnNldG9mKHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQsIGV2ZW50X2Nh
bGxiYWNrKSk7CisJLy9ERUZJTkUoT0ZGU0VUX0ZBSUxTQUZFX0NBTExCQUNLLAlvZmZzZXRv
ZihzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0LCBmYWlsc2FmZV9jYWxsYmFjaykpOwogCUJM
QU5LKCk7CiAKIAlyZXR1cm4gMDsgCmRpZmYgLXIgMjhhNjAzOGRhOTlmIHhlbi9hcmNoL2Fy
bS94ZW4vZW50cnkuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2VudHJ5LlMJRnJpIEZlYiAwMyAxNzo0Nzox
NiAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTk2IEBACisvKgorICogZW50cnkuUworICoKKyAq
IENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAg
ICAgIFNhbmctYnVtIFN1aCA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBK
YWVNaW4gUnl1ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2
ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkg
V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl
IHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4K
KyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5v
dCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5
IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EK
KyAqLworI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KKyNpbmNsdWRlIDxhc20vcGFnZS5o
PgorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5o
PgorI2luY2x1ZGUgPGFzbS9jcHUtZG9tYWluLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1vZmZz
ZXRzLmg+CisjaW5jbHVkZSA8cHVibGljL2FyY2gtYXJtLmg+CisKKy5tYWNybyBTQVZFX0NP
TlRFWFQJIG9mZnNldCBjb3JyZWN0aW9uCisJc3ViICAgICBsciwgbHIsICNcY29ycmVjdGlv
bgorCXN0ciAgICAgcjAsIFtzcCwgIy0xNl0KKwlzdHIgICAgIGxyLCBbc3AsICMtMTJdCisK
KwltcnMgICAgIHIwLCBzcHNyCisJbW92ICAgICBsciwgI1xvZmZzZXQKKwlzdHIgICAgIHIw
LCBbc3AsICMtOF0KKwlzdHIgICAgIGxyLCBbc3AsICMtNF0KKworCXN1YiAgICAgcjAsIHNw
LCAjMTYKKworCW1zciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9JX0JJVCB8IFBTUl9GX0JJVCB8
IFBTUl9NT0RFX1NWQykKKworCXN1YglzcCwgc3AsICNDVFhUX0ZSQU1FX1NJWkUKK1NQRklY
KAl0c3QJc3AsICM0CQkpCitTUEZJWCgJYmljbmUJc3AsIHNwLCAjNAkpCisJc3RtaWIJc3As
IHtyMSAtIGxyfV4KKwlsZG1pYQlyMCwge3IxIC0gcjR9CisJYWRkCXI1LCBzcCwgI0NUWFRf
U1NQCisJYWRkCXIwLCBzcCwgI0NUWFRfRlJBTUVfU0laRQorU1BGSVgoCWFkZG5lCXIwLCBy
MCwgIzQJKQorCXN0cglyMSwgW3NwXQorCW1vdglyMSwgbHIKKwlzdG1pYQlyNSwge3IwIC0g
cjR9CisJbXNyCXNwc3JfY3hzZiwgcjMKKy5lbmRtCisKKy5tYWNybyBSRVNUT1JFX0NPTlRF
WFQKKwlsZHIJcjAsIFtzcCwgI0NUWFRfU1BTUl0KKwltc3IJc3Bzcl9jeHNmLCByMAorCWxk
bWlhCXNwLCB7cjAgLSBscn1eCisJYWRkCXNwLCBzcCwgI0NUWFRfU1NQCisJbGRtaWEJc3As
IHtzcCwgbHIsIHBjfV4KKy5lbmRtCisKKwkuYWxpZ24JNQorCS5nbG9iYWwgZXhjZXB0aW9u
X3ZlY3Rvcl90YWJsZQorZXhjZXB0aW9uX3ZlY3Rvcl90YWJsZToKKwlsZHIJcGMsIC5yc3QK
KwlsZHIJcGMsIC51bmQKKwlsZHIJcGMsIC5zd2kKKwlsZHIJcGMsIC5wYWJ0CisJbGRyCXBj
LCAuZGFidAorCWxkcglwYywgLmFkeAorCWxkcglwYywgLmlycQorCWxkcglwYywgLmZpcQor
CisucnN0OgkubG9uZwl2ZWN0b3JfcmVzZXQKKy51bmQ6CS5sb25nCXZlY3Rvcl91bmQKKy5z
d2k6CS5sb25nCXZlY3Rvcl9zd2kKKy5wYWJ0OgkubG9uZwl2ZWN0b3JfcGFidAorLmRhYnQ6
CS5sb25nCXZlY3Rvcl9kYWJ0CisuYWR4OgkubG9uZwl2ZWN0b3JfcmVzZXJ2ZWQKKy5pcnE6
CS5sb25nCXZlY3Rvcl9pcnEKKy5maXE6CS5sb25nCXZlY3Rvcl9maXEKKworCS5hbGlnbgk1
Cit2ZWN0b3JfcmVzZXQ6CisxOgorCWIJMWIKKworCS5hbGlnbgk1Cit2ZWN0b3JfaXJxOgor
CVNBVkVfQ09OVEVYVAkweDE4LCA0CisKKwltcnMJcjAsIHNwc3IKKwlhbmQJcjAsIHIwLCAj
UFNSX01PREVfTUFTSworCWVvcnMJcjAsIHIwLCAjUFNSX01PREVfU1ZDCisKKwlibmUJcmV0
dXJuX3RvX2d1ZXN0CisKKwljcHNpZAlpCisKKwlSRVNUT1JFX0NPTlRFWFQKKworCS5hbGln
bgk1Cit2ZWN0b3JfZGFidDoKKwlzdHIJcjAsIFtzcCwgIy0xNl0KKwlzdHIJbHIsIFtzcCwg
Iy0xMl0KKwltcnMgICAgIHIwLCBzcHNyCisJc3RyICAgICByMCwgW3NwLCAjLThdCisJc3Vi
ICAgICByMCwgc3AsICMxNgorCisJbXNyICAgICBjcHNyX2N4c2YsICMoUFNSX0lfQklUIHwg
UFNSX0ZfQklUIHwgUFNSX01PREVfU1ZDKQorCisJc3ViICAgICBzcCwgc3AsICNDVFhUX0ZS
QU1FX1NJWkUKK1NQRklYKCAgdHN0ICAgICBzcCwgIzQgICAgICApCitTUEZJWCggIGJpY25l
ICAgc3AsIHNwLCAjNCAgKQorCXN0bWliICAgc3AsIHtyMSAtIGxyfV4KKwlsZG1pYSAgIHIw
LCB7cjEgLSByM30KKwlhZGQgICAgIHI1LCBzcCwgI0NUWFRfU1NQCisJYWRkICAgICByMCwg
c3AsICNDVFhUX0ZSQU1FX1NJWkUKK1NQRklYKCAgYWRkbmUgICByMCwgcjAsICM0ICApCisJ
c3RyICAgICByMSwgW3NwXQorCW1vdiAgICAgcjEsIGxyCisJc3RtaWEgICByNSwge3IwIC0g
cjN9CisKKwltcmMgICAgIHAxNSwgMCwgcjAsIGM2LCBjMCwgMAorCW1yYyAgICAgcDE1LCAw
LCByMSwgYzUsIGMwLCAwCisKKwlhbmQJcjQsIHIzLCAjUFNSX01PREVfTUFTSworCWVvcnMJ
cjQsIHI0LCAjUFNSX01PREVfU1ZDCisKKwliZXEJZG9fZGF0YV9hYm9ydAorCisJY3BzaWUJ
aQorCQkKKwljY2kgICAgIHI4CisJbGRyICAgICByOSwgW3I4XQorCisJbGRyICAgICByMTAs
IFtyOSwgI09GRlNFVF9WQ1BVX0lORk8gXQorCWxkciAgICAgcjE0LCBbcjksICMoT0ZGU0VU
X0FSQ0hfVkNQVSArIE9GRlNFVF9HVUVTVF9DT05URVhUICsgT0ZGU0VUX1ZDUFVfVkJBUild
CisJY21wICAgICByMTQsICMwCisJYmVxICAgICB0cmFwX3RhYmxlX2ludmFsaWQKKworCWFk
ZAlyMTQsIHIxNCwgI09GRlNFVF9WRUNUT1JfREFCVAorCisJc3RyICAgICByMCwgW3IxMCwg
IyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVkZBUildCisJc3RyICAgICByMSwg
W3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVkZTUildCisKKwlAIEZv
bGxvd2luZyBpcyBhZGRlZCB0byBtaXggZXZ0Y2huIHVwY2FsbCBtYXNrIGFuZCBwc3IKKwls
ZHIJcjQsIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0K
KworCW9ycglyOSwgcjQsICNWUFNSX0lfQklUCisJc3RyCXI5LCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildCisKKwlsZHIgICAgIHIwLCBbc3AsICND
VFhUX1VTUF0KKwlsZHIgICAgIHIxLCBbc3AsICNDVFhUX1VMUl0KKworCWxkciAgICAgcjUs
IFtyOCwgI09GRlNFVF9WUFNSXQorCWJpYyAgICAgcjMsIHIzLCAjUFNSX01PREVfTUFTSwor
CW9yciAgICAgcjMsIHIzLCByNQorCisJdHN0CXI0LCAjVlBTUl9JX0JJVAorCW9ycm5lCXIz
LCByMywgI1BTUl9JX0JJVAorCisJc3RyICAgICByMCwgW3IxMCwgIyhPRkZTRVRfQVJDSF9W
Q1BVX0lORk8gKyBPRkZTRVRfVFNQKV0KKwlzdHIgICAgIHIxLCBbcjEwLCAjKE9GRlNFVF9B
UkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQorCXN0ciAgICAgcjMsIFtyMTAsICMoT0ZG
U0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0KKworCWNtcCAgICAgcjUsICNQ
U1JfTU9ERV9TVkMKKwlsZHJuZSAgIHIwLCBbcjgsICM4XQorCisJbW92ICAgICByNSwgI1BT
Ul9NT0RFX1NWQworCXN0ciAgICAgcjUsIFtyOCwgIzRdCisJc3RyICAgICByMCwgW3I4LCAj
OF0KKwlzdHIgICAgIHIyLCBbcjgsICMxMl0KKworCWxkciAgICAgcjUsID1EQUNSX1NUQVRf
U1ZDCisJbWNyICAgICBwMTUsIDAsIHI1LCBjMywgYzAsIDAKKworCWNwc2lkCWkKKworCWFk
ZCAgICAgcjgsIHI4LCAjOAorCWxkbWlhICAgcjgsIHtyMTMsIHIxNH1eCisJbGRtaWEgICBz
cCwge3IwLXIxMn0KKwlsZHIgICAgIHNwLCBbc3AsICNDVFhUX1NTUF0KKwltc3IgICAgIHNw
c3IsICNQU1JfTU9ERV9VU1IKKwltb3ZzICAgIHBjLCBscgorCisJLmFsaWduCTUKK3ZlY3Rv
cl9wYWJ0OgorCXN0ciAgICAgcjAsIFtzcCwgIy0xNl0KKwlzdHIgICAgIGxyLCBbc3AsICMt
MTJdCisJbXJzICAgICByMCwgc3BzcgorCXN0ciAgICAgcjAsIFtzcCwgIy04XQorCXN1YiAg
ICAgcjAsIHNwLCAjMTYKKworCW1zciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9JX0JJVCB8IFBT
Ul9GX0JJVCB8IFBTUl9NT0RFX1NWQykKKworCXN1YiAgICAgc3AsIHNwLCAjQ1RYVF9GUkFN
RV9TSVpFCitTUEZJWCggIHRzdCAgICAgc3AsICM0ICAgICAgKQorU1BGSVgoICBiaWNuZSAg
IHNwLCBzcCwgIzQgICkKKwlzdG1pYiAgIHNwLCB7cjEgLSBscn1eCisJbGRtaWEgICByMCwg
e3IxIC0gcjN9CisJYWRkICAgICByNSwgc3AsICNDVFhUX1NTUAorCWFkZCAgICAgcjAsIHNw
LCAjQ1RYVF9GUkFNRV9TSVpFCitTUEZJWCggIGFkZG5lICAgcjAsIHIwLCAjNCAgKQorCXN0
ciAgICAgcjEsIFtzcF0KKwltb3YgICAgIHIxLCBscgorCXN0bWlhICAgcjUsIHtyMCAtIHIz
fQorCisJbXJjICAgICBwMTUsIDAsIHIwLCBjNiwgYzAsIDAKKwltcmMgICAgIHAxNSwgMCwg
cjEsIGM1LCBjMCwgMAorCisJYW5kICAgICByNCwgcjMsICNQU1JfTU9ERV9NQVNLCisJZW9y
cyAgICByNCwgcjQsICNQU1JfTU9ERV9TVkMKKworCWJlcQlkb19wcmVmZXRjaF9hYm9ydAor
CisJY3BzaWUJaQkJCisKKwljY2kgICAgIHI4CisJbGRyICAgICByOSwgW3I4XQorCisJbGRy
ICAgICByMTAsIFtyOSwgI09GRlNFVF9WQ1BVX0lORk9dCisJbGRyICAgICByMTQsIFtyOSwg
IyhPRkZTRVRfQVJDSF9WQ1BVICsgT0ZGU0VUX0dVRVNUX0NPTlRFWFQgKyBPRkZTRVRfVkNQ
VV9WQkFSKV0KKwljbXAgICAgIGxyLCAjMAorCWJlcSAgICAgdHJhcF90YWJsZV9pbnZhbGlk
CisKKwlhZGQJcjE0LCByMTQsICNPRkZTRVRfVkVDVE9SX1BBQlQKKworCWxkcglyNCwgW3Ix
MCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQorCisJb3JyCXI5
LCByNCwgI1ZQU1JfSV9CSVQKKwlzdHIJcjksIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9J
TkZPICsgT0ZGU0VUX1RDUFNSKV0KKworCWxkciAgICAgcjAsIFtzcCwgI0NUWFRfVVNQXQor
CWxkciAgICAgcjEsIFtzcCwgI0NUWFRfVUxSXQorCisJbGRyICAgICByNSwgW3I4LCAjNF0K
KwliaWMgICAgIHIzLCByMywgI1BTUl9NT0RFX01BU0sKKwlvcnIgICAgIHIzLCByMywgcjUK
KworCXRzdAlyNCwgI1ZQU1JfSV9CSVQKKwlvcnJuZQlyMywgcjMsICNQU1JfSV9CSVQKKwor
CXN0ciAgICAgcjAsIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RT
UCldCisJc3RyICAgICByMSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZT
RVRfVExSKV0KKwlzdHIgICAgIHIzLCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyAr
IE9GRlNFVF9UU1BTUildCisKKwljbXAgICAgIHI1LCAjUFNSX01PREVfU1ZDCisJbGRybmUg
ICByMCwgW3I4LCAjOF0KKworCW1vdiAgICAgcjUsICNQU1JfTU9ERV9TVkMKKwlzdHIgICAg
IHI1LCBbcjgsICM0XQorCXN0ciAgICAgcjAsIFtyOCwgIzhdCisJc3RyICAgICByMiwgW3I4
LCAjMTJdCisKKwlsZHIgICAgIHI1LCA9REFDUl9TVEFUX1NWQworCW1jciAgICAgcDE1LCAw
LCByNSwgYzMsIGMwLCAwCisKKwljcHNpZAlpCisKKwlhZGQgICAgIHI4LCByOCwgIzgKKwls
ZG1pYSAgIHI4LCB7cjEzLCByMTR9XgorCWxkbWlhICAgc3AsIHtyMC1yMTJ9CisJbGRyICAg
ICBzcCwgW3NwLCAjQ1RYVF9TU1BdCisJbXNyICAgICBzcHNyLCAjUFNSX01PREVfVVNSCisJ
bW92cyAgICBwYywgbHIKKworCS5hbGlnbgk1Cit2ZWN0b3JfdW5kOgorCXN0ciAgICAgcjAs
IFtzcCwgIy0xNl0KKwlzdHIgICAgIGxyLCBbc3AsICMtMTJdCisJbXJzICAgICByMCwgc3Bz
cgorCXN0ciAgICAgcjAsIFtzcCwgIy04XQorCXN1YiAgICAgcjAsIHNwLCAjMTYKKworCW1z
ciAgICAgY3Bzcl9jeHNmLCAjKFBTUl9JX0JJVCB8IFBTUl9GX0JJVCB8IFBTUl9NT0RFX1NW
QykKKworCXN1YiAgICAgc3AsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFCitTUEZJWCggIHRzdCAg
ICAgc3AsICM0ICAgICAgKQorU1BGSVgoICBiaWNuZSAgIHNwLCBzcCwgIzQgICkKKwlzdG1p
YiAgIHNwLCB7cjEgLSBscn1eCisJbGRtaWEgICByMCwge3IxIC0gcjN9CisJYWRkICAgICBy
NSwgc3AsICNDVFhUX1NTUAorCWFkZCAgICAgcjAsIHNwLCAjQ1RYVF9GUkFNRV9TSVpFCitT
UEZJWCggIGFkZG5lICAgcjAsIHIwLCAjNCAgKQorCXN0ciAgICAgcjEsIFtzcF0KKwltb3Yg
ICAgIHIxLCBscgorCXN0bWlhICAgcjUsIHtyMCAtIHIzfQorCisJYW5kICAgICByNCwgcjMs
ICNQU1JfTU9ERV9NQVNLCisJZW9ycyAgICByNCwgcjQsICNQU1JfTU9ERV9TVkMKKworCWJl
cSAgICAgZG9fdW5kZWZpbmVkX2luc3RydWN0aW9uCisKKwljcHNpZQlpCisKKwljY2kgICAg
IHI4CisJbGRyICAgICByOSwgW3I4XQorCisJbGRyICAgICByMTAsIFtyOSwgI09GRlNFVF9W
Q1BVX0lORk9dCisJbGRyICAgICByMTQsIFtyOSwgIyhPRkZTRVRfQVJDSF9WQ1BVICsgT0ZG
U0VUX0dVRVNUX0NPTlRFWFQgKyBPRkZTRVRfVkNQVV9WQkFSKV0KKwljbXAgICAgIGxyLCAj
MAorCWJlcSAgICAgdHJhcF90YWJsZV9pbnZhbGlkCisKKwlhZGQJcjE0LCByMTQsICNPRkZT
RVRfVkVDVE9SX1VORAorCisJbGRyCXI0LCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5G
TyArIE9GRlNFVF9UQ1BTUildCisKKwlvcnIJcjksIHI0LCAjVlBTUl9JX0JJVAorCXN0cgly
OSwgW3IxMCwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQorCisJ
bGRyICAgICByMCwgW3NwLCAjQ1RYVF9VU1BdCisJbGRyICAgICByMSwgW3NwLCAjQ1RYVF9V
TFJdCisKKwlsZHIgICAgIHI1LCBbcjgsICM0XQorCWJpYyAgICAgcjMsIHIzLCAjUFNSX01P
REVfTUFTSworCW9yciAgICAgcjMsIHIzLCByNQorCisJdHN0CXI0LCAjVlBTUl9JX0JJVAor
CW9ycm5lCXIzLCByMywgI1BTUl9JX0JJVAorCisJc3RyICAgICByMCwgW3IxMCwgIyhPRkZT
RVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0KKwlzdHIgICAgIHIxLCBbcjEwLCAj
KE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UTFIpXQorCXN0ciAgICAgcjMsIFty
MTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0KKworCWNtcCAg
ICAgcjUsICNQU1JfTU9ERV9TVkMKKwlsZHJuZSAgIHIwLCBbcjgsICM4XQorCisJbW92ICAg
ICByNSwgI1BTUl9NT0RFX1NWQworCXN0ciAgICAgcjUsIFtyOCwgIzRdCisJc3RyICAgICBy
MCwgW3I4LCAjOF0KKwlzdHIgICAgIHIyLCBbcjgsICMxMl0KKwlzdHIgICAgIHIxLCBbcjgs
ICMxNl0KKworCWxkciAgICAgcjUsID1EQUNSX1NUQVRfU1ZDCisJbWNyICAgICBwMTUsIDAs
IHI1LCBjMywgYzAsIDAKKworCWNwc2lkCWkKKworCWFkZCAgICAgcjgsIHI4LCAjOAorCWxk
bWlhICAgcjgsIHtyMTMsIHIxNH1eCisJbGRtaWEgICBzcCwge3IwLXIxMn0KKwlsZHIgICAg
IHNwLCBbc3AsICNDVFhUX1NTUF0KKwltc3IgICAgIHNwc3IsICNQU1JfTU9ERV9VU1IKKwlt
b3ZzICAgIHBjLCBscgorCisJLmFsaWduCTUKK3ZlY3Rvcl9maXE6CisJc3VicyAgICBwYywg
bHIsICM0CisKKwkuYWxpZ24JNQordmVjdG9yX3Jlc2VydmVkOgorCWIJdmVjdG9yX3Jlc2Vy
dmVkCisKKwkuYWxpZ24JNQordHJhcF90YWJsZV9pbnZhbGlkOgorCWIJdHJhcF90YWJsZV9p
bnZhbGlkCisKKwkuYWxpZ24JNQordmVjdG9yX3N3aToKKwlzdHIJc3AsIFtzcCwgIyhDVFhU
X1NTUCAtIENUWFRfRlJBTUVfU0laRSldCisJc3ViICAgICBzcCwgc3AsICNDVFhUX0ZSQU1F
X1NJWkUKKwlzdG1pYSAgIHNwLCB7cjAgLSBscn1eCisJbXJzICAgICByMTEsIHNwc3IKKwlz
dHIgICAgIHIxNCwgW3NwLCAjQ1RYVF9QQ10KKwlzdHIgICAgIHIxMSwgW3NwLCAjQ1RYVF9T
UFNSXQorCisJY3BzaWUJaQorCisJY2NpCXI4CisJbGRyCXIxMiwgW3I4LCAjNF0KKwllb3Jz
CXIxMiwgcjEyLCAjUFNSX01PREVfU1ZDCisKKwliZXEJaW52b2tlX2h5cGVyY2FsbAorCQkK
Kwltb3YJcjEyLCAjUFNSX01PREVfU1ZDCisJc3RyICAgICByMTIsIFtyOCwgIzRdCisJc3Ry
ICAgICByMTQsIFtyOCwgIzEyXQorCisJbGRyICAgICByOSwgW3I4XQorCWxkciAgICAgcjEw
LCBbcjksICNPRkZTRVRfVkNQVV9JTkZPXQorCWxkciAgICAgcjE0LCBbcjksICMoT0ZGU0VU
X0FSQ0hfVkNQVSArIE9GRlNFVF9HVUVTVF9DT05URVhUICsgT0ZGU0VUX1ZDUFVfVkJBUild
CisJY21wICAgICByMTQsICMwCisJYmVxCXRyYXBfdGFibGVfaW52YWxpZAorCisJYWRkCXIx
NCwgcjE0LCAjT0ZGU0VUX1ZFQ1RPUl9TV0kKKworCWxkcglyNCwgW3IxMCwgIyhPRkZTRVRf
QVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVENQU1IpXQorCisJb3JyCXI5LCByNCwgI1ZQU1Jf
SV9CSVQKKwlzdHIJcjksIFtyMTAsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VU
X1RDUFNSKV0KKworCXRzdAlyNCwgI1ZQU1JfSV9CSVQKKwlvcnJuZQlyMTEsIHIxMSwgI1BT
Ul9JX0JJVAorCisJbGRyICAgICByNCwgW3NwLCAjQ1RYVF9VU1BdCisJbGRyICAgICByNSwg
W3NwLCAjQ1RYVF9VTFJdCisKKwlzdHIgICAgIHI0LCBbcjEwLCAjKE9GRlNFVF9BUkNIX1ZD
UFVfSU5GTyArIE9GRlNFVF9UU1ApXQorCXN0ciAgICAgcjUsIFtyMTAsICMoT0ZGU0VUX0FS
Q0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RMUildCisJc3RyICAgICByMTEsIFtyMTAsICMoT0ZG
U0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RTUFNSKV0KKworCWxkciAgICAgcjExLCA9
REFDUl9TVEFUX1NWQworCW1jciAgICAgcDE1LCAwLCByMTEsIGMzLCBjMCwgMAorCisJY3Bz
aWQJaQorCisJYWRkICAgICByOCwgcjgsICM4CisJbGRtaWEgICByOCwge3IxMywgcjE0fV4K
KwlsZG1pYSAgIHNwLCB7cjAtcjEyfQorCWxkciAgICAgc3AsIFtzcCwgI0NUWFRfU1NQXQor
CW1zciAgICAgc3BzciwgI1BTUl9NT0RFX1VTUgorCW1vdnMgICAgcGMsIGxyCisKK2ludm9r
ZV9oeXBlcmNhbGw6CisJbGRyICAgICByMTIsIFtsciwgIy00XQorCWJpYyAgICAgcjEyLCBy
MTIsICMweGZmMDAwMDAwCisKKwlhZHIgICAgIHIxNCwgMWYKKwlhZHIgICAgIHIxMSwgaHlw
ZXJjYWxsX3RhYmxlCisJbGRyICAgICBwYywgW3IxMSwgcjEyLCBsc2wgIzJdCisKKzE6CisJ
c3RyICAgICByMCwgW3NwLCAjQ1RYVF9SMF0KKworCWIJcmV0dXJuX3RvX2d1ZXN0CisKK0VO
VFJZKHJldHVybl90b19ndWVzdCkJCisJY3BzaWUJaQorCWJsCWRvX3NvZnRpcnEKKworCWNj
aQlyOAorCWxkcglyMTAsIFtyOCwgI09GRlNFVF9WQ1BVXQorCisJbGRyCXIxMSwgW3IxMCwg
I09GRlNFVF9WQ1BVX0lORk9dCisJbGRyCXI5LCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVf
SU5GTyArIE9GRlNFVF9UQ1BTUildCisKKwl0c3QJcjksICNWUFNSX0lfQklUCisJYm5lCXJl
c3VtZV9ndWVzdF9kb21haW4KKworCWxkcglyMTIsIFtyMTEsICNPRkZTRVRfRVZUQ0hOX1VQ
Q0FMTF9QRU5ESU5HXQorCisJdHN0CXIxMiwgIzB4RkYKKwliZXEJcmVzdW1lX2d1ZXN0X2Rv
bWFpbgorCitkb191cGNhbGw6CisJbGRyICAgICByMTQsIFtyMTAsICMoT0ZGU0VUX0FSQ0hf
VkNQVSArIE9GRlNFVF9HVUVTVF9DT05URVhUICsgT0ZGU0VUX1ZDUFVfVkJBUildCisJY21w
CWxyLCAjMAorCWJlcQl0cmFwX3RhYmxlX2ludmFsaWQKKworCWFkZAlyMTQsIHIxNCwgI09G
RlNFVF9WRUNUT1JfSVJRCisKKwlsZHIJcjQsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9J
TkZPICsgT0ZGU0VUX1RDUFNSKV0KKworCW9ycglyOSwgcjQsICNWUFNSX0lfQklUCisJc3Ry
CXI5LCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildCisK
KwlsZHIJcjAsIFtzcCwgI0NUWFRfVVNQXQorCWxkcglyMSwgW3NwLCAjQ1RYVF9VTFJdCisJ
bGRyCXIyLCBbc3AsICNDVFhUX1BDXQorCWxkcglyMywgW3NwLCAjQ1RYVF9TUFNSXQorCisJ
bGRyCXI1LCBbcjgsICM0XQorCWJpYwlyMywgcjMsICNQU1JfTU9ERV9NQVNLCisJb3JyCXIz
LCByMywgcjUKKworCXRzdAlyNCwgI1ZQU1JfSV9CSVQKKwlvcnJuZQlyMywgcjMsICNQU1Jf
SV9CSVQKKworCXN0cglyMCwgW3IxMSwgIyhPRkZTRVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZT
RVRfVFNQKV0KKwlzdHIJcjEsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9JTkZPICsgT0ZG
U0VUX1RMUildCisJc3RyCXIzLCBbcjExLCAjKE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9G
RlNFVF9UU1BTUildCisKKwljbXAJcjUsICNQU1JfTU9ERV9TVkMKKwlsZHJuZQlyMCwgW3I4
LCAjOF0KKworCW1vdglyNSwgI1BTUl9NT0RFX1NWQworCXN0cglyNSwgW3I4LCAjNF0KKwlz
dHIJcjAsIFtyOCwgIzhdCisJc3RyCXIyLCBbcjgsICMxMl0KKworCWxkcglyNSwgPURBQ1Jf
U1RBVF9TVkMKKwltY3IgICAgIHAxNSwgMCwgcjUsIGMzLCBjMCwgMAorCQorCWNwc2lkCWkK
KworCWFkZAlyOCwgcjgsICM4CisJbGRtaWEJcjgsIHtyMTMsIHIxNH1eCisJbGRtaWEJc3As
IHtyMC1yMTJ9CisJbGRyCXNwLCBbc3AsICNDVFhUX1NTUF0KKwltc3IJc3BzciwgI1BTUl9N
T0RFX1VTUgorCW1vdnMJcGMsIGxyCisKK3Jlc3VtZV9ndWVzdF9kb21haW46CisJY2NpCXI4
CisJbGRyCXIzLCBbcjgsICNPRkZTRVRfVlBTUl0KKwlsZHIJaXAsIFtzcCwgI0NUWFRfU1BT
Ul0KKwljbXAJcjMsICNQU1JfTU9ERV9TVkMKKworCWxkcm5lCXI3LCA9REFDUl9TVEFUX0hZ
UAorCWxkcmVxICAgcjcsID1EQUNSX1NUQVRfU1ZDCisJbWNyCXAxNSwgMCwgcjcsIGMzLCBj
MCwgMAorCisJY3BzaWQJaQorCisJUkVTVE9SRV9DT05URVhUCisKKy8qCisgKiBQcm90b3R5
cGUgOiBfX3N3aXRjaF90byhzdHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgdmNwdV9ndWVzdF9jb250
ZXh0ICosIHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgKikKKyAqLworCQkuYWxpZ24JNQor
RU5UUlkoc3dpdGNoX3RvKQorCWFkZCAgICAgaXAsIHIxLCAjT0ZGU0VUX1ZDUFVfUjQKKwlz
dG1pYSAgIGlwLCB7cjQgLSBzbCwgZnAsIGlwLCBzcCwgbHJ9CisKKwltcmMJcDE1LCAwLCBy
NCwgYzMsIGMwLCAwCisJbXJjCXAxNSwgMCwgcjcsIGMxMywgYzAsIDEKKworCXN0cglyNCwg
W3IxLCAjT0ZGU0VUX1ZDUFVfREFDUl0KKwlzdHIJcjcsIFtyMSwgI09GRlNFVF9WQ1BVX0NP
TlRFWFRJRFJdCisKKwlsZHIJcjQsIFtyMiwgI09GRlNFVF9WQ1BVX0RBQ1JdCisJbGRyCXI3
LCBbcjIsICNPRkZTRVRfVkNQVV9DT05URVhUSURSXQorCisJbWNyCXAxNSwgMCwgcjQsIGMz
LCBjMCwgMAorCW1jcglwMTUsIDAsIHI3LCBjMTMsIGMwLCAxCisKKwlhZGQJaXAsIHIyLCAj
T0ZGU0VUX1ZDUFVfUjQKKwlsZG1pYSAgIGlwLCAge3I0IC0gc2wsIGZwLCBpcCwgc3AsIGxy
fQorIAorCWIJY29udGV4dF9zYXZlZAorCisJLmFsaWduCTUKKwkudHlwZSBoeXBlcmNhbGxf
dGFibGUsICNvYmplY3QKK0VOVFJZKGh5cGVyY2FsbF90YWJsZSkKKwkubG9uZwlkb19zZXRf
dHJhcF90YWJsZQkvKiAgMCAqLworCS5sb25nCWRvX21tdV91cGRhdGUKKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwJCS8qIHNldF9nZHQgKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8q
IHN0YWNrX3N3aXRjaCAqLworCS5sb25nCWRvX3NldF9jYWxsYmFja3MJCisJLmxvbmcJZG9f
bmlfaHlwZXJjYWxsCQkvKiBmcHVfc3dpdGNoICovCisJLmxvbmcJZG9fc2NoZWRfb3BfY29t
cGF0CisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkKKwkubG9uZwlkb19uaV9oeXBlcmNhbGwK
KwkubG9uZwlkb19uaV9oeXBlcmNhbGwKKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qIDEw
ICovCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCisJLmxvbmcJZG9fbWVtb3J5X29wCisJLmxv
bmcJZG9fbXVsdGljYWxsCisJLmxvbmcJZG9fdXBkYXRlX3ZhX21hcHBpbmcKKwkubG9uZwlk
b19zZXRfdGltZXJfb3AJCS8qIDE1ICovCisJLmxvbmcJZG9fZXZlbnRfY2hhbm5lbF9vcAor
CS5sb25nCWRvX3hlbl92ZXJzaW9uCisJLmxvbmcJZG9fY29uc29sZV9pbworCS5sb25nCWRv
X3BoeXNkZXZfb3AKKwkubG9uZwlkb19ncmFudF90YWJsZV9vcAkvKiAyMCAqLworCS5sb25n
CWRvX3ZtX2Fzc2lzdAorCS5sb25nCWRvX25pX2h5cGVyY2FsbAorCS5sb25nCWRvX3Jlc3Rv
cmVfdHJhcF9mcmFtZQorCS5sb25nCWRvX3ZjcHVfb3AKKwkubG9uZwlkb19uaV9oeXBlcmNh
bGwJCS8qIDI1ICovCisJLmxvbmcJZG9fbW11ZXh0X29wCisJLmxvbmcJZG9fbmlfaHlwZXJj
YWxsCisJLmxvbmcJZG9fbm1pX29wCisJLmxvbmcJZG9fc2NoZWRfb3AKKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwJCS8qIDMwIDogY2FsbGJhY2tvcAkJKi8KKwkubG9uZwlkb19uaV9oeXBl
cmNhbGwJCS8qCXhlbm9wcm9mCQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJZXZl
bnRfY2hhbm5lbF9vcAkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJcGh5c2Rldl9v
cAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCWh2bV9vcAkJCSovCisJLmxvbmcJ
ZG9fbmlfaHlwZXJjYWxsCQkvKiAzNSA6IHN5c2N0bAkJCSovCisJLmxvbmcJZG9fbmlfaHlw
ZXJjYWxsCQkvKiAgICAgIGRvbWN0bAkJCSovCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkv
KglrZXhlY19vcAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXRtZW1fb3AJCQkq
LworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJeGNfcmVzZXJ2ZWRfb3AJCSovCisJLmxv
bmcJZG9fbmlfaHlwZXJjYWxsCQkvKiA0MCA6IHVuZGVmaW5lZAkJKi8KKwkubG9uZwlkb19u
aV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJ
CS8qCXVuZGVmaW5lZAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5l
ZAkJKi8KKwkubG9uZwlkb19uaV9oeXBlcmNhbGwJCS8qCXVuZGVmaW5lZAkJKi8KKwkubG9u
Zwlkb19uaV9oeXBlcmNhbGwJCS8qIDQ1IDogdW5kZWZpbmVkCQkqLworCS5sb25nCWRvX25p
X2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJ
LyoJdW5kZWZpbmVkCQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVk
CQkqLworCS5sb25nCWRvX25pX2h5cGVyY2FsbAkJLyoJdW5kZWZpbmVkCQkqLworCS5sb25n
CWRvX25pX2h5cGVyY2FsbAkJLyogNTAgOgl1bmRlZmluZWQJCSovCisJLmxvbmcJZG9fbmlf
aHlwZXJjYWxsCQkvKgl1bmRlZmluZWQJCSovCisJLmxvbmcJZG9fbmlfaHlwZXJjYWxsCQkv
KiAJdW5kZWZpbmVkCQkqLworCisgICAgICAgIC5zZWN0aW9uIC5kYXRhCitFTlRSWSh4ZW5f
dHJhbnNsYXRpb25fdGFibGUpCisgICAgICAgIC5sb25nICAgc3RhcnQgLSAweDQwMDAKKwpk
aWZmIC1yIDI4YTYwMzhkYTk5ZiB4ZW4vYXJjaC9hcm0veGVuL2h5cGVyY2FsbHMuUwotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJj
aC9hcm0veGVuL2h5cGVyY2FsbHMuUwlGcmkgRmViIDAzIDE3OjQ3OjE2IDIwMTIgKzA5MDAK
QEAgLTAsMCArMSw2NyBAQAorLyoNCisgKiBoeXBlcmNhbGxzLlMNCisgKg0KKyAqIENvcHly
aWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBT
YW5nLWJ1bSBTdWggPHNidWsuc3VoQHNhbXN1bmcuY29tPg0KKyAqICAgICAgICAgIEphZU1p
biBSeXUgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0g
aXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlm
eQ0KKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZl
cnNpb24gMiBvZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uDQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAq
IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g
IFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRh
aWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3Jh
bTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KKyAqIEZvdW5kYXRpb24s
IEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0x
MzA3ICBVU0ENCisgKi8NCisNCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPg0KKyNpbmNsdWRl
IDxhc20vcHJvY2Vzc29yLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorI2luY2x1ZGUg
PGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1kb21haW4uaD4NCisjaW5jbHVk
ZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+DQor
DQorI2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5oPg0KKw0KKw0KK0VOVFJZKGRvX3NldF9k
b21haW4pDQorICAgICAgICBtb3YgICAgIHBjLCBscg0KKw0KKw0KK0VOVFJZKGRvX3Jlc3Rv
cmVfdHJhcF9mcmFtZSkNCisJY2NpCXI4DQorCWxkcglyNCwgW3I4LCAjT0ZGU0VUX1ZDUFVd
DQorCWxkcglyNiwgW3NwLCAjQ1RYVF9VU1BdDQorCWxkcglyMTEsIFtyNCwgI09GRlNFVF9W
Q1BVX0lORk9dDQorDQorCWxkciAgICAgcjMsIFtyMTEsICMoT0ZGU0VUX0FSQ0hfVkNQVV9J
TkZPICsgT0ZGU0VUX1RTUFNSKV0NCisJbGRyICAgICByMiwgW3IxMSwgIyhPRkZTRVRfQVJD
SF9WQ1BVX0lORk8gKyBPRkZTRVRfVExSKV0NCisJbGRyICAgICByMSwgW3IxMSwgIyhPRkZT
RVRfQVJDSF9WQ1BVX0lORk8gKyBPRkZTRVRfVFNQKV0NCisNCisJbGRyCXI3LCBbcjExLCAj
KE9GRlNFVF9BUkNIX1ZDUFVfSU5GTyArIE9GRlNFVF9UQ1BTUildDQorDQorCXRzdAlyMywg
I1BTUl9JX0JJVA0KKwlvcnJuZQlyNywgI1ZQU1JfSV9CSVQNCisJYmljZXEJcjcsICNWUFNS
X0lfQklUDQorDQorCWJpYwlyNSwgcjMsICMoUFNSX01PREVfTUFTSyB8IFBTUl9JX0JJVCkN
CisJb3JyCXI1LCByNSwgI1BTUl9NT0RFX1VTUg0KKwlhbmQJcjMsIHIzLCAjUFNSX01PREVf
TUFTSw0KKw0KKwlAIENvbnN0cnVjdCBsYXRlc3QgZ3Vlc3QgY29udGV4dA0KKwlzdHIJcjEs
IFtzcCwgI0NUWFRfVVNQXQ0KKwlzdHIJcjIsIFtzcCwgI0NUWFRfUENdDQorCXN0cglyNSwg
W3NwLCAjQ1RYVF9TUFNSXQ0KKwlzdHIJcjMsIFtyOCwgIzRdDQorCXN0cglyNiwgW3I4LCAj
OF0NCisNCisJQCBVcGRhdGUgVlBTUg0KKwlzdHIgICAgcjcsIFtyMTEsICMoT0ZGU0VUX0FS
Q0hfVkNQVV9JTkZPICsgT0ZGU0VUX1RDUFNSKV0NCisNCisJbW92CXBjLCBscg0KZGlmZiAt
ciAyOGE2MDM4ZGE5OWYgeGVuL2FyY2gvYXJtL3hlbi9waHlzZGV2LmMKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9waHlzZGV2LmMJRnJpIEZlYiAwMyAxNzo0NzoxNiAyMDEyICswOTAwCkBAIC0wLDAgKzEs
NDEgQEAKKy8qCisgKiBwaHlzZGV2LmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAx
MSBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsu
c3VoQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBz
YW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91
IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g
dGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAq
IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNv
ZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMz
MCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9j
b25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+CisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+
CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vZXJybm8uaD4KKyNpbmNs
dWRlIDx4ZW4vc3BpbmxvY2suaD4KKyNpbmNsdWRlIDx4ZW4vYml0bWFwLmg+CisjaW5jbHVk
ZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVuL2V2ZW50Lmg+CisjaW5jbHVkZSA8eGVu
L2lycS5oPgorI2luY2x1ZGUgPHhlbi9ndWVzdF9hY2Nlc3MuaD4KKyNpbmNsdWRlIDxwdWJs
aWMvYXJjaC1hcm0uaD4KKyNpbmNsdWRlIDxwdWJsaWMvcGh5c2Rldi5oPgorCitpbnQgZG9f
cGh5c2Rldl9vcChpbnQgY21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKK3sKKwlO
T1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt13-0005vJ-26; Mon, 13 Feb 2012 10:20:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=0387cb7a1b=mjg59@cavan.codon.org.uk>)
	id 1Rvqn9-0001LA-2i
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:45:35 +0000
X-Env-Sender: prvs=0387cb7a1b=mjg59@cavan.codon.org.uk
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328881528!12851972!1
X-Originating-IP: [93.93.128.6]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3732 invoked from network); 10 Feb 2012 13:45:28 -0000
Received: from cavan.codon.org.uk (HELO cavan.codon.org.uk) (93.93.128.6)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 13:45:28 -0000
Received: from mjg59 by cavan.codon.org.uk with local (Exim 4.72)
	(envelope-from <mjg59@cavan.codon.org.uk>)
	id 1Rvqn0-0007jZ-2k; Fri, 10 Feb 2012 13:45:26 +0000
Date: Fri, 10 Feb 2012 13:45:26 +0000
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: liang tang <liang.tang@oracle.com>
Message-ID: <20120210134525.GA29662@srcf.ucam.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
	<20120209194723.GA8622@srcf.ucam.org> <4F34C622.3060905@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F34C622.3060905@oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk
X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: linux-acpi@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, 2012 at 03:24:18PM +0800, liang tang wrote:
> Hi,Matthew
> the xen efi call need to use hypercall. that is different from the
> generic efi code. do you any idea about that. thanks!

Right, but 32-bit EFI needs to make different calls to 64-bit EFI 
anyway. It would be good if the abstraction could be done at this level 
instead of duplicating the code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt18-0005zu-TR; Mon, 13 Feb 2012 10:20:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqtz-00040j-JG
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:04:47 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329120278!4726411!2
X-Originating-IP: [203.254.224.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzQgPT4gMjQwMTQ5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1302 invoked from network); 13 Feb 2012 08:04:40 -0000
Received: from mailout4.samsung.com (HELO mailout4.samsung.com)
	(203.254.224.34) by server-16.tower-21.messagelabs.com with SMTP;
	13 Feb 2012 08:04:40 -0000
Received: from epcpsbge7.samsung.com (mailout4.samsung.com [203.254.224.34])
	by mailout4.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00LX7NQYOHB0@mailout4.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:04:38 +0900 (KST)
Message-id: <0LZB00LYMNRQOHB0@mailout4.samsung.com>
X-AuditID: cbfee611-b7b12ae0000036c1-a7-4f38c3d1fafa
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge7.samsung.com (EPCPMTA) with SMTP id 64.FF.14017.1D3C83F4;
	Mon, 13 Feb 2012 17:03:29 +0900 (KST)
Date: Mon, 13 Feb 2012 08:04:38 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080356110@jm77.ryu
Msgkey: 20120213080356110@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080232243@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 12/14]  arm: implement get/put page functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <25214000.70331329120274085.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgZ2V0L3B1dCBwYWdlIGZ1bmN0aW9ucw0KDQogeGVuL2FyY2gvYXJtL3hl
bi9tbS5jIHwgIDYxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0NCiAxIGZpbGVzIGNoYW5nZWQsIDU1IGluc2VydGlvbnMoKyksIDYg
ZGVsZXRpb25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1
bmcuY29tPg0KDQpkaWZmIC1yIGMzZTczMzNlZWZjMyB4ZW4vYXJjaC9hcm0veGVuL21tLmMNCi0t
LSBhL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlTdW4gRmViIDEyIDE1OjA0OjI0IDIwMTIgKzA5MDAN
CisrKyBiL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlTdW4gRmViIDEyIDE1OjEzOjA5IDIwMTIgKzA5
MDANCkBAIC03MywyOSArNzMsNzggQEAgdm9pZCBtZW1ndWFyZF91bmd1YXJkX3JhbmdlKHZvaWQg
KnAsIHVucw0KIA0KIHZvaWQgcHV0X3BhZ2Uoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkNCiB7DQot
CU5PVF9ZRVQoKTsNCisgICAgICAgIHUzMiBueCwgeCwgeSA9IHBhZ2UtPmNvdW50X2luZm87DQor
DQorICAgICAgICBkbyB7DQorICAgICAgICAgICAgICAgIHggID0geTsNCisgICAgICAgICAgICAg
ICAgbnggPSB4IC0gMTsNCisgICAgICAgIH0gd2hpbGUgKCB1bmxpa2VseSgoeSA9IGNtcHhjaGco
JnBhZ2UtPmNvdW50X2luZm8sIHgsIG54KSkgIT0geCkgKTsNCisNCisgICAgICAgIGlmICggdW5s
aWtlbHkoKG54ICYgUEdDX2NvdW50X21hc2spID09IDApICkgew0KKyAgICAgICAgICAgICAgICBm
cmVlX2RvbWhlYXBfcGFnZShwYWdlKTsNCisgICAgICAgIH0NCisNCiB9DQogDQogc3RydWN0IGRv
bWFpbiAqcGFnZV9nZXRfb3duZXJfYW5kX3JlZmVyZW5jZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdl
KQ0KIHsNCi0JTk9UX1lFVCgpOw0KKyAgICAgICAgdW5zaWduZWQgbG9uZyB4LCB5ID0gcGFnZS0+
Y291bnRfaW5mbzsNCisNCisgICAgICAgIGRvIHsNCisgICAgICAgICAgICAgICAgeCA9IHk7DQor
ICAgICAgICAgICAgICAgIGlmKHVubGlrZWx5KCgoeCArIDIpICYgUEdDX2NvdW50X21hc2spIDw9
IDIpICkNCisgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsNCisgICAgICAgIH0g
d2hpbGUoKHkgPSBjbXB4Y2hnKCZwYWdlLT5jb3VudF9pbmZvLHgseCsxKSkgIT0geCk7DQorDQor
ICAgICAgICByZXR1cm4gcGFnZV9nZXRfb3duZXIocGFnZSk7DQorDQogfQ0KIA0KIGludCBnZXRf
cGFnZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCBzdHJ1Y3QgZG9tYWluICpkb21haW4pDQogew0K
LQlOT1RfWUVUKCk7DQorICAgICAgICBzdHJ1Y3QgZG9tYWluICpvd25lciA9IHBhZ2VfZ2V0X293
bmVyX2FuZF9yZWZlcmVuY2UocGFnZSk7DQogDQotCXJldHVybiAwOw0KKyAgICAgICAgaWYgKGxp
a2VseShvd25lciA9PSBkb21haW4pKQ0KKyAgICAgICAgICAgICAgICByZXR1cm4gMTsNCisNCisg
ICAgICAgIGlmIChvd25lciAhPSBkb21haW4pDQorICAgICAgICAgICAgICAgIHB1dF9wYWdlKHBh
Z2UpOw0KKw0KKyAgICAgICAgcmV0dXJuIDA7DQogfQ0KIA0KIHZvaWQgc2hhcmVfeGVuX3BhZ2Vf
d2l0aF9ndWVzdChzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCBzdHJ1Y3QgZG9tYWluICpkLCBpbnQg
cmVhZG9ubHkpDQogew0KLQlOT1RfWUVUKCk7DQorICAgICAgICBpZihwYWdlX2dldF9vd25lcihw
YWdlKSA9PSBkKQ0KKyAgICAgICAgICAgICAgICByZXR1cm47DQorDQorICAgICAgICBzZXRfZ3Bm
bl9mcm9tX21mbihwYWdlX3RvX21mbihwYWdlKSwgSU5WQUxJRF9NMlBfRU5UUlkpOw0KKw0KKyAg
ICAgICAgc3Bpbl9sb2NrKCZkLT5wYWdlX2FsbG9jX2xvY2spOw0KKw0KKyAgICAgICAgLyogVGhl
IGluY3JlbWVudGVkIHR5cGUgY291bnQgcGlucyBhcyB3cml0YWJsZSBvciByZWFkLW9ubHkuICov
DQorICAgICAgICBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAgPSAocmVhZG9ubHkgPyBQR1Rfbm9u
ZSA6IFBHVF93cml0YWJsZV9wYWdlKTsNCisgICAgICAgIHBhZ2UtPnUuaW51c2UudHlwZV9pbmZv
IHw9IFBHVF92YWxpZGF0ZWQgfCAxOw0KKw0KKyAgICAgICAgcGFnZV9zZXRfb3duZXIocGFnZSwg
ZCk7DQorICAgICAgICB3bWIoKTsgLyogaW5zdGFsbCB2YWxpZCBkb21haW4gcHRyIGJlZm9yZSB1
cGRhdGluZyByZWZjbnQuICovDQorICAgICAgICBBU1NFUlQoKHBhZ2UtPmNvdW50X2luZm8gJiB+
UEdDX3hlbl9oZWFwKSA9PSAwKTsNCisNCisgICAgICAgIGlmICghZC0+aXNfZHlpbmcpIHsNCisg
ICAgICAgICAgICAgICAgcGFnZS0+Y291bnRfaW5mbyB8PSBQR0NfYWxsb2NhdGVkIHwgMTsNCisN
CisgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2VseShkLT54ZW5oZWFwX3BhZ2VzKysgPT0gMCkg
KQ0KKyAgICAgICAgICAgICAgICAgICAgICAgIGdldF9rbm93bmFsaXZlX2RvbWFpbihkKTsNCisN
CisgICAgICAgICAgICAgICAgcGFnZV9saXN0X2FkZF90YWlsKHBhZ2UsICZkLT54ZW5wYWdlX2xp
c3QpOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgc3Bpbl91bmxvY2soJmQtPnBhZ2VfYWxsb2Nf
bG9jayk7DQogfQ0KIA0KIHZvaWQgc2hhcmVfeGVuX3BhZ2Vfd2l0aF9wcml2aWxlZ2VkX2d1ZXN0
cyhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCBpbnQgcmVhZG9ubHkpDQogew0KLQlOT1RfWUVUKCk7
DQorICAgICAgICBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KHBhZ2UsIGRvbV94ZW4sIHJlYWRv
bmx5KTsNCiB9DQogDQogc3RhdGljIGludCBwaW5fcGFnZV90YWJsZSh1MzIgbWZuLCBzdHJ1Y3Qg
ZG9tYWluICpkKQ0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch12.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch12.diff"


YXJtOiBpbXBsZW1lbnQgZ2V0L3B1dCBwYWdlIGZ1bmN0aW9ucwoKIHhlbi9hcmNoL2FybS94
ZW4vbW0uYyB8ICA2MSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDU1IGluc2VydGlvbnMo
KyksIDYgZGVsZXRpb25zKC0pCgpTaWduZWQtb2ZmLWJ5OiBKYWVtaW4gUnl1IDxqbTc3LnJ5
dUBzYW1zdW5nLmNvbT4KCmRpZmYgLXIgYzNlNzMzM2VlZmMzIHhlbi9hcmNoL2FybS94ZW4v
bW0uYwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL21tLmMJU3VuIEZlYiAxMiAxNTowNDoyNCAy
MDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlTdW4gRmViIDEyIDE1OjEz
OjA5IDIwMTIgKzA5MDAKQEAgLTczLDI5ICs3Myw3OCBAQCB2b2lkIG1lbWd1YXJkX3VuZ3Vh
cmRfcmFuZ2Uodm9pZCAqcCwgdW5zCiAKIHZvaWQgcHV0X3BhZ2Uoc3RydWN0IHBhZ2VfaW5m
byAqcGFnZSkKIHsKLQlOT1RfWUVUKCk7CisgICAgICAgIHUzMiBueCwgeCwgeSA9IHBhZ2Ut
PmNvdW50X2luZm87CisKKyAgICAgICAgZG8geworICAgICAgICAgICAgICAgIHggID0geTsK
KyAgICAgICAgICAgICAgICBueCA9IHggLSAxOworICAgICAgICB9IHdoaWxlICggdW5saWtl
bHkoKHkgPSBjbXB4Y2hnKCZwYWdlLT5jb3VudF9pbmZvLCB4LCBueCkpICE9IHgpICk7CisK
KyAgICAgICAgaWYgKCB1bmxpa2VseSgobnggJiBQR0NfY291bnRfbWFzaykgPT0gMCkgKSB7
CisgICAgICAgICAgICAgICAgZnJlZV9kb21oZWFwX3BhZ2UocGFnZSk7CisgICAgICAgIH0K
KwogfQogCiBzdHJ1Y3QgZG9tYWluICpwYWdlX2dldF9vd25lcl9hbmRfcmVmZXJlbmNlKHN0
cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiB7Ci0JTk9UX1lFVCgpOworICAgICAgICB1bnNpZ25l
ZCBsb25nIHgsIHkgPSBwYWdlLT5jb3VudF9pbmZvOworCisgICAgICAgIGRvIHsKKyAgICAg
ICAgICAgICAgICB4ID0geTsKKyAgICAgICAgICAgICAgICBpZih1bmxpa2VseSgoKHggKyAy
KSAmIFBHQ19jb3VudF9tYXNrKSA8PSAyKSApCisgICAgICAgICAgICAgICAgICAgICAgICBy
ZXR1cm4gTlVMTDsKKyAgICAgICAgfSB3aGlsZSgoeSA9IGNtcHhjaGcoJnBhZ2UtPmNvdW50
X2luZm8seCx4KzEpKSAhPSB4KTsKKworICAgICAgICByZXR1cm4gcGFnZV9nZXRfb3duZXIo
cGFnZSk7CisKIH0KIAogaW50IGdldF9wYWdlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHN0
cnVjdCBkb21haW4gKmRvbWFpbikKIHsKLQlOT1RfWUVUKCk7CisgICAgICAgIHN0cnVjdCBk
b21haW4gKm93bmVyID0gcGFnZV9nZXRfb3duZXJfYW5kX3JlZmVyZW5jZShwYWdlKTsKIAot
CXJldHVybiAwOworICAgICAgICBpZiAobGlrZWx5KG93bmVyID09IGRvbWFpbikpCisgICAg
ICAgICAgICAgICAgcmV0dXJuIDE7CisKKyAgICAgICAgaWYgKG93bmVyICE9IGRvbWFpbikK
KyAgICAgICAgICAgICAgICBwdXRfcGFnZShwYWdlKTsKKworICAgICAgICByZXR1cm4gMDsK
IH0KIAogdm9pZCBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KHN0cnVjdCBwYWdlX2luZm8g
KnBhZ2UsIHN0cnVjdCBkb21haW4gKmQsIGludCByZWFkb25seSkKIHsKLQlOT1RfWUVUKCk7
CisgICAgICAgIGlmKHBhZ2VfZ2V0X293bmVyKHBhZ2UpID09IGQpCisgICAgICAgICAgICAg
ICAgcmV0dXJuOworCisgICAgICAgIHNldF9ncGZuX2Zyb21fbWZuKHBhZ2VfdG9fbWZuKHBh
Z2UpLCBJTlZBTElEX00yUF9FTlRSWSk7CisKKyAgICAgICAgc3Bpbl9sb2NrKCZkLT5wYWdl
X2FsbG9jX2xvY2spOworCisgICAgICAgIC8qIFRoZSBpbmNyZW1lbnRlZCB0eXBlIGNvdW50
IHBpbnMgYXMgd3JpdGFibGUgb3IgcmVhZC1vbmx5LiAqLworICAgICAgICBwYWdlLT51Lmlu
dXNlLnR5cGVfaW5mbyAgPSAocmVhZG9ubHkgPyBQR1Rfbm9uZSA6IFBHVF93cml0YWJsZV9w
YWdlKTsKKyAgICAgICAgcGFnZS0+dS5pbnVzZS50eXBlX2luZm8gfD0gUEdUX3ZhbGlkYXRl
ZCB8IDE7CisKKyAgICAgICAgcGFnZV9zZXRfb3duZXIocGFnZSwgZCk7CisgICAgICAgIHdt
YigpOyAvKiBpbnN0YWxsIHZhbGlkIGRvbWFpbiBwdHIgYmVmb3JlIHVwZGF0aW5nIHJlZmNu
dC4gKi8KKyAgICAgICAgQVNTRVJUKChwYWdlLT5jb3VudF9pbmZvICYgflBHQ194ZW5faGVh
cCkgPT0gMCk7CisKKyAgICAgICAgaWYgKCFkLT5pc19keWluZykgeworICAgICAgICAgICAg
ICAgIHBhZ2UtPmNvdW50X2luZm8gfD0gUEdDX2FsbG9jYXRlZCB8IDE7CisKKyAgICAgICAg
ICAgICAgICBpZiAoIHVubGlrZWx5KGQtPnhlbmhlYXBfcGFnZXMrKyA9PSAwKSApCisgICAg
ICAgICAgICAgICAgICAgICAgICBnZXRfa25vd25hbGl2ZV9kb21haW4oZCk7CisKKyAgICAg
ICAgICAgICAgICBwYWdlX2xpc3RfYWRkX3RhaWwocGFnZSwgJmQtPnhlbnBhZ2VfbGlzdCk7
CisgICAgICAgIH0KKworICAgICAgICBzcGluX3VubG9jaygmZC0+cGFnZV9hbGxvY19sb2Nr
KTsKIH0KIAogdm9pZCBzaGFyZV94ZW5fcGFnZV93aXRoX3ByaXZpbGVnZWRfZ3Vlc3RzKHN0
cnVjdCBwYWdlX2luZm8gKnBhZ2UsIGludCByZWFkb25seSkKIHsKLQlOT1RfWUVUKCk7Cisg
ICAgICAgIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3QocGFnZSwgZG9tX3hlbiwgcmVhZG9u
bHkpOwogfQogCiBzdGF0aWMgaW50IHBpbl9wYWdlX3RhYmxlKHUzMiBtZm4sIHN0cnVjdCBk
b21haW4gKmQpCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt12-0005v8-MI; Mon, 13 Feb 2012 10:20:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rvqce-0000DW-Tr
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:34:45 +0000
X-Env-Sender: 350608693@qq.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328880831!52217319!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=1.4 required=7.0 tests=FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28414 invoked from network); 10 Feb 2012 13:33:52 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 13:33:52 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rvqcc-0003uc-1U
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 05:34:42 -0800
Date: Fri, 10 Feb 2012 05:34:42 -0800 (PST)
From: yunjiedu <350608693@qq.com>
To: xen-devel@lists.xensource.com
Message-ID: <1328880882031-5472445.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Subject: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,all,

today,i use function printk() in file xen/arch/x86/mm/paging.c,but Where the
output of printk() is stored (which log files)?I try to find,but without
results. Also is this output enabled by default ? If no, how to enable them?
thanks

--
View this message in context: http://xen.1045712.n5.nabble.com/where-printk-output-tp5472445p5472445.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt13-0005vR-HP; Mon, 13 Feb 2012 10:20:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvzzN-0003fg-Dl
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 23:34:49 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328916848!51978386!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MDY2MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12460 invoked from network); 10 Feb 2012 23:34:09 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 23:34:09 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RvzzG-0007Ar-Kq from Paul_Brook@mentor.com ;
	Fri, 10 Feb 2012 15:34:42 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 23:34:40 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 4468C6EEE7;
	Fri, 10 Feb 2012 23:34:40 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: qemu-devel@nongnu.org
Date: Fri, 10 Feb 2012 23:34:39 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<4F350047.4030507@siemens.com>
	<alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201202102334.40125.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 23:34:41.0256 (UTC)
	FILETIME=[8FAD4E80:01CCE84C]
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +#ifdef CONFIG_SLIRP
> +static inline void slirp_update_timeout(uint32_t *timeout)
> +{
> +    *timeout = MIN(1000, *timeout);
> +}
> +#else
> +static inline void slirp_update_timeout(uint32_t *timeout) { }
> +#endif

Shouldn't we be testing whether slirp is actually in use? I doubt many people 
go to the effort of rebuilding without SLIRP support.

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt12-0005v8-MI; Mon, 13 Feb 2012 10:20:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rvqce-0000DW-Tr
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:34:45 +0000
X-Env-Sender: 350608693@qq.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328880831!52217319!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=1.4 required=7.0 tests=FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28414 invoked from network); 10 Feb 2012 13:33:52 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 13:33:52 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rvqcc-0003uc-1U
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 05:34:42 -0800
Date: Fri, 10 Feb 2012 05:34:42 -0800 (PST)
From: yunjiedu <350608693@qq.com>
To: xen-devel@lists.xensource.com
Message-ID: <1328880882031-5472445.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Subject: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,all,

today,i use function printk() in file xen/arch/x86/mm/paging.c,but Where the
output of printk() is stored (which log files)?I try to find,but without
results. Also is this output enabled by default ? If no, how to enable them?
thanks

--
View this message in context: http://xen.1045712.n5.nabble.com/where-printk-output-tp5472445p5472445.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt16-0005xN-Gl; Mon, 13 Feb 2012 10:20:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqoI-0003K2-4e
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:58:54 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329119926!13681425!1
X-Originating-IP: [203.254.224.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzMgPT4gMjQzNjYx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1959 invoked from network); 13 Feb 2012 07:58:46 -0000
Received: from mailout3.samsung.com (HELO mailout3.samsung.com)
	(203.254.224.33) by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:58:46 -0000
Received: from epcpsbge3.samsung.com (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00CJ0NH6VYD0@mailout3.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:58:45 +0900 (KST)
Message-id: <0LZB00CJVNHXVYD0@mailout3.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-e7-4f38c2b54930
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 4C.AA.17710.5B2C83F4;
	Mon, 13 Feb 2012 16:58:45 +0900 (KST)
Date: Mon, 13 Feb 2012 07:58:45 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075753031@jm77.ryu
Msgkey: 20120213075753031@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075640084@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 06/14] arm: allow access to the xenheap and the
	boot pages.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <13906246.69971329119922192.JavaMail.weblogic@epv6ml04>

DQphcm06IGFsbG93IGFjY2VzcyB0byB0aGUgeGVuaGVhcCBhbmQgdGhlIGJvb3QgcGFnZXMuDQoN
ClRoaXMgcGF0Y2ggY29sbGVjdHMgbWFjaGluZSBwYWdlIGZyYW1lcywgY3JlYXRlcyBmcmFtZSB0
YWJsZSB0byBhbGxvdyBhY2Nlc3MgdG8gdGhlIHhlbmhlYXAgYW5kIHRoZSBib290IHBhZ2VzLg0K
DQogeGVuL2FyY2gvYXJtL3hlbi9tbS5jICAgICAgICAgIHwgICA2NSArKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9zZXR1
cC5jICAgICAgIHwgIDExNSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vY29t
bW9uL3BhZ2VfYWxsb2MuYyAgICAgICAgfCAgICA1ICsrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0v
bW0uaCAgICAgICB8ICAgMjggKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNt
LWFybS9tbXUuaCAgICAgIHwgICAxMCArKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9wbGF0
Zm9ybS5oIHwgICA2MiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPg0K
DQpkaWZmIC1yIDRkNjFmMDJmZGUzNyB4ZW4vYXJjaC9hcm0veGVuL21tLmMNCi0tLSBhL3hlbi9h
cmNoL2FybS94ZW4vbW0uYwlGcmkgRmViIDAzIDE3OjQ3OjMyIDIwMTIgKzA5MDANCisrKyBiL3hl
bi9hcmNoL2FybS94ZW4vbW0uYwlNb24gRmViIDA2IDExOjE2OjM3IDIwMTIgKzA5MDANCkBAIC0x
OTIsMyArMTkyLDY4IEBAIGludCBwYWdlX2lzX3JhbV90eXBlKHVuc2lnbmVkIGxvbmcgbWZuLCAN
CiANCiAJcmV0dXJuIC1FSU5WQUw7DQogfQ0KKw0KKyNkZWZpbmUgUFRTX1BFUl9QQUdFICAgIDQN
CisNCisvKg0KKyAqIDQgcGFnZSB0YWJsZXMgcGVyIGEgcGFnZS4NCisgKi8NCitzdGF0aWMgaW5s
aW5lIHZvaWQgd2lyZV9wYWdlX3RhYmxlcyhsMWVfdCAqbDFlLCB1bnNpZ25lZCBsb25nIHRhYmxl
cykNCit7DQorCWwxZSA9IChsMWVfdCAqKSgodW5zaWduZWQgbG9uZylsMWUgJiB+KFBUU19QRVJf
UEFHRSAtIDEpKTsNCisNCisJKihsMWUgKyAwKSA9IE1LX0wxRSh0YWJsZXMgKyAwLCAgICBMMUVf
R1VFU1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAwKTsNCisJKihsMWUgKyAxKSA9IE1LX0wxRSh0
YWJsZXMgKyAxMDI0LCBMMUVfR1VFU1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAxKTsNCisJKihs
MWUgKyAyKSA9IE1LX0wxRSh0YWJsZXMgKyAyMDQ4LCBMMUVfR1VFU1RfVEFCTEUpOyBwdGVfc3lu
YyhsMWUgKyAyKTsNCisJKihsMWUgKyAzKSA9IE1LX0wxRSh0YWJsZXMgKyAzMDcyLCBMMUVfR1VF
U1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAzKTsNCit9DQorDQordW5zaWduZWQgbG9uZyBhbGxv
Y19wYWdlX3RhYmxlcyhsMWVfdCAqbDFlKQ0KK3sNCisJdW5zaWduZWQgbG9uZyBwYWdlOw0KKw0K
KwlwYWdlID0gYWxsb2NfY2xlYW5fcGFnZXMoMSk7DQorCWlmICghcGFnZSkgew0KKwkJcmV0dXJu
IDA7DQorCX0NCisNCisvLwljYWNoZV9jbGVhbl9yYW5nZShwYWdlLCBwYWdlICsgUEFHRV9TSVpF
LCAwKTsNCisNCisJd2lyZV9wYWdlX3RhYmxlcyhsMWUsIHBhZ2UpOw0KKw0KKwlyZXR1cm4gcGFn
ZTsNCit9DQorDQorDQoraW50IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcgdmlydCwgdW5z
aWduZWQgbG9uZyBwaHlzLCB1bnNpZ25lZCBpbnQgc2l6ZSwgdW5zaWduZWQgaW50IGZsYWdzKQ0K
K3sNCisJbDFlX3QgKmwxZTsNCisJdW5zaWduZWQgbG9uZyB2YWRkciA9IHJvdW5kX2Rvd24odmly
dCwgUEFHRV9TSVpFKTsNCisJdW5zaWduZWQgbG9uZyBsYXN0ID0gdmlydCArIHNpemU7DQorDQor
CWwxZSA9IGwxX2xpbmVhcl9vZmZzZXRfeGVuKHZhZGRyKTsNCisNCisJZG8gew0KKwkJbDJlX3Qg
KmwyZTsNCisJCXVuc2lnbmVkIGxvbmcgZW5kID0gKHZhZGRyICsgKFNFQ1RJT05fU0laRSAqIFBU
U19QRVJfUEFHRSkpICYgKFNFQ1RJT05fTUFTSyk7DQorCQllbmQgPSAoZW5kIDwgbGFzdCkgPyBl
bmQgOiBsYXN0Ow0KKw0KKwkJaWYgKCFsMWVfdmFsKCpsMWUpKSB7DQorCQkJaWYgKCFhbGxvY19w
YWdlX3RhYmxlcyhsMWUpKSB7DQorCQkJCXJldHVybiAtRU5PTUVNOw0KKwkJCX0NCisJCX0NCisN
CisJCWwyZSA9IGwyX2xpbmVhcl9vZmZzZXQobDFlLCB2YWRkcik7DQorCQlkbyB7DQorCQkJKmwy
ZSA9IE1LX0wyRShwaHlzLCBmbGFncyk7DQorCQkJcHRlX3N5bmMobDJlKTsNCisNCisJCQlwaHlz
ICs9IFBBR0VfU0laRTsNCisJCQl2YWRkciArPSBQQUdFX1NJWkU7DQorCQl9IHdoaWxlKGwyZSsr
LCB2YWRkciA8IGVuZCk7DQorCX0gd2hpbGUobDFlICs9IDQsIHZhZGRyIDwgbGFzdCk7DQorDQor
CXJldHVybiAwOw0KK30NCisNCmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9hcmNoL2FybS94ZW4v
c2V0dXAuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCUZyaSBGZWIgMDMgMTc6NDc6
MzIgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCU1vbiBGZWIgMDYg
MTE6MTY6MzcgMjAxMiArMDkwMA0KQEAgLTMxLDYgKzMxLDcgQEANCiAjaW5jbHVkZSA8cHVibGlj
L3ZlcnNpb24uaD4NCiAjaW5jbHVkZSA8cHVibGljL3NjaGVkLmg+DQogI2luY2x1ZGUgPGFzbS9t
bXUuaD4NCisjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+DQogDQogc3RydWN0IGRvbWFpbiBfZG9t
X3hlbiA9IHsNCiAJLnJlZmNudCA9IEFUT01JQ19JTklUKDEpLA0KQEAgLTc0LDYgKzc1LDExOCBA
QCB2b2lkIGFyY2hfZ2V0X3hlbl9jYXBzKHhlbl9jYXBhYmlsaXRpZXNfDQogew0KIH0NCiANCitz
dGF0aWMgdW5zaWduZWQgbG9uZyBsb29rdXBfeGVuX3BoeXNfc3RhcnQodm9pZCkNCit7DQorICAg
ICAgICBsMWVfdCAqbDFlOw0KKw0KKyAgICAgICAgbDFlID0gbDFfbGluZWFyX29mZnNldF94ZW4o
WEVOX1ZJUlRfU1RBUlQpOw0KKw0KKyAgICAgICAgcmV0dXJuIGwxZV92YWwoKmwxZSkgJiBTRUNU
SU9OX01BU0s7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBsb25nIGxvb2t1cF94ZW5fcGh5c19l
bmQodm9pZCkNCit7DQorCWwxZV90ICpsMWU7DQorDQorCWwxZSA9IGwxX2xpbmVhcl9vZmZzZXRf
eGVuKFhFTl9WSVJUX1NUQVJUKTsNCisNCisJd2hpbGUobDFlX3ZhbCgqKGwxZSArIDEpKSAhPSAw
KQ0KKwkJbDFlKys7DQorDQorCXJldHVybiAobDFlX3ZhbCgqbDFlKSAmIFNFQ1RJT05fTUFTSykg
KyBTRUNUSU9OX1NJWkU7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBpbnQgYm9vdF9wYWdlX2Nv
bGxlY3Rvcih1bnNpZ25lZCBsb25nIHN0YXJ0LCB1bnNpZ25lZCBsb25nIHNpemUpDQorew0KKwl1
bnNpZ25lZCBsb25nIGVuZCA9IHN0YXJ0ICsgc2l6ZTsNCisNCisJaW5pdF9ib290X3BhZ2VzKHN0
YXJ0LCBlbmQpOw0KKw0KKwlzdGFydCA9IHN0YXJ0ID4+IFBBR0VfU0hJRlQ7DQorCWVuZCAgID0g
ZW5kICAgPj4gUEFHRV9TSElGVDsNCisNCisJbWluX3BhZ2UgPSBtaW4oc3RhcnQsIG1pbl9wYWdl
KTsNCisJbWF4X3BhZ2UgPSBtYXgoZW5kLCBtYXhfcGFnZSk7DQorDQorCXJldHVybiBzaXplID4+
IFBBR0VfU0hJRlQ7DQorfQ0KKw0KKyNkZWZpbmUgRlJBTUVfVEFCTEVfQkFTRQkweEZDMDAwMDAw
VUwNCisNCisvKg0KKyAqIFRoZSB2aXJ0dWFsIGFkZHJlc3Mgb2YgdGhlIGZyYW1lIHRhYmxlIHNo
b3VsZCBiZSBhbGlnbmVkIHRvIDRNQiBib3VuZGFyeS4NCisgKi8NCitzdHJ1Y3QgcGFnZV9pbmZv
ICphbGxvY19mcmFtZV90YWJsZSh1bnNpZ25lZCBpbnQgc3opDQorew0KKwl1bnNpZ25lZCBsb25n
IHN0YXJ0Ow0KKw0KKwlzdGFydCA9IGFsbG9jX3BhZ2VzKHN6ID4+IFBBR0VfU0hJRlQpOw0KKwlp
ZiAoIXN0YXJ0KSB7DQorCQlyZXR1cm4gTlVMTDsNCisJfQ0KKw0KKwlpZihhbGxvY19wYWdlX21h
cChGUkFNRV9UQUJMRV9CQVNFLCBzdGFydCwgc3osIEwyRV9HVUVTVF9QQUdFKSA8IDApIHsNCisJ
CXJldHVybiBOVUxMOw0KKwl9DQorDQorCXJldHVybiAoc3RydWN0IHBhZ2VfaW5mbyAqKUZSQU1F
X1RBQkxFX0JBU0U7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGZyYW1lX3RhYmxlX3NldHVwKHVuc2ln
bmVkIGludCBucl9ib290X3BhZ2VzKQ0KK3sNCisJaW50IGk7DQorCXVuc2lnbmVkIGludCBzaXpl
Ow0KKw0KKyAgICAgICAgc2l6ZSA9IHJvdW5kX3VwKG5yX2Jvb3RfcGFnZXMgKiBzaXplb2Yoc3Ry
dWN0IHBhZ2VfaW5mbyksIFBBR0VfU0laRSk7DQorDQorCS8qIFRoZSBsb2NhdGlvbiBvZiB0aGUg
ZnJhbWVfdGFibGUgY291bGQgYmUgY2hhbmdlZCBpbiBuZWFyIGZ1dHVyZS4NCisJICogU28sIGRl
Y2lzaW9uIG1ha2luZyBvZiB0aGUgdmlydHVhbCBhZGRyZXNzIGlzIGFsd2F5cyBwZXJmb3JtZWQg
aW4gDQorCSAqIGFsbG9jX2ZyYW1lX3RhYmxlKCkNCisJICovDQorDQorCWZyYW1lX3RhYmxlID0g
YWxsb2NfZnJhbWVfdGFibGUoc2l6ZSk7DQorCWlmIChmcmFtZV90YWJsZSA9PSBOVUxMKSB7DQor
CQlwYW5pYygiTm9tZW1cbiIpOw0KKwl9DQorDQorICAgICAgICBtZW1zZXQoZnJhbWVfdGFibGUs
IDAsIHNpemUpOw0KK30NCisNCit1bnNpZ25lZCBpbnQgcHJlcGFyZV9wYWdlX2ZyYW1lcyh2b2lk
KQ0KK3sNCisJc3RydWN0IG1lbW9yeV9tYXAgKmVudDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcg
c3RhcnQsIGVuZDsNCisJdW5zaWduZWQgaW50IHBhZ2VzID0gMDsNCisNCisJLyogRm9yIHZpcnRf
dG9fbWFkZHIoKSBtYWNyby4gKi8NCisJeGVuX3BoeXNfc3RhcnQgPSBsb29rdXBfeGVuX3BoeXNf
c3RhcnQoKTsNCisJeGVuX3BoeXNfZW5kID0gbG9va3VwX3hlbl9waHlzX2VuZCgpOw0KKw0KKyAg
ICAgICAgLyogRm9yIHBvcHVsYXRpbmcgYm9vdG1lbV9yZWdpb25fbGlzdCAqLw0KKyAgICAgICAg
c3RhcnQgPSByb3VuZF9kb3duKHZpcnRfdG9fbWFkZHIoJl9lbmQpLCBQQUdFX1NJWkUpOw0KKyAg
ICAgICAgZW5kID0gc3RhcnQgKyBQQUdFX1NJWkU7DQorDQorICAgICAgICBpbml0X2Jvb3RfcGFn
ZXMoc3RhcnQsIGVuZCk7DQorDQorCS8qIEZvciBlYXJseSB4ZW5oZWFwIGFsbG9jYXRpb24gKi8N
CisgICAgICAgIHhlbmhlYXBfcGh5c19zdGFydCA9IGVuZDsNCisgICAgICAgIHhlbmhlYXBfcGh5
c19lbmQgPSB4ZW5fcGh5c19lbmQ7DQorDQorCWl0ZXJhdGVfbWVtb3J5X21hcChlbnQpIHsNCisJ
CWlmIChlbnQtPnR5cGUgPT0gTUVNT1JZX1RZUEVfUkFNKSB7DQorCQkJcGFnZXMgKz0gYm9vdF9w
YWdlX2NvbGxlY3RvcihlbnQtPmJhc2UsIGVudC0+c2l6ZSk7DQorCQl9DQorCX0NCisNCisJcmVz
ZXJ2ZV9ib290X3BhZ2VzKHhlbl9waHlzX3N0YXJ0LCB4ZW5fcGh5c19lbmQpOw0KKw0KKwlmcmFt
ZV90YWJsZV9zZXR1cChwYWdlcyk7DQorDQorICAgICAgICBpbml0X3hlbmhlYXBfcGFnZXMoeGVu
aGVhcF9waHlzX3N0YXJ0LCB4ZW5oZWFwX3BoeXNfZW5kKTsNCisNCisJcmV0dXJuIHBhZ2VzOw0K
K30NCisNCiBzdGF0aWMgdm9pZCBpZGxlX2RvbWFpbl9pbml0KHZvaWQpDQogew0KIAlzdHJ1Y3Qg
dmNwdSAqdjsNCkBAIC05Miw2ICsyMDUsOCBAQCBhc21saW5rYWdlIHZvaWQgc3RhcnRfeGVuKHZv
aWQpDQogDQogCXNtcF9wcmVwYXJlX2Jvb3RfY3B1KCk7DQogDQorCXByZXBhcmVfcGFnZV9mcmFt
ZXMoKTsNCisNCiAJc29mdGlycV9pbml0KCk7DQogDQogCXRhc2tsZXRfc3Vic3lzX2luaXQoKTsN
CmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9jb21tb24vcGFnZV9hbGxvYy5jDQotLS0gYS94ZW4v
Y29tbW9uL3BhZ2VfYWxsb2MuYwlGcmkgRmViIDAzIDE3OjQ3OjMyIDIwMTIgKzA5MDANCisrKyBi
L3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCU1vbiBGZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMA0K
QEAgLTE0Niw2ICsxNDYsMTEgQEAgc3RhdGljIHZvaWQgX19pbml0IGJvb3RtZW1fcmVnaW9uX3ph
cCh1bg0KICAgICB9DQogfQ0KIA0KK3ZvaWQgX19pbml0IHJlc2VydmVfYm9vdF9wYWdlcyhwYWRk
cl90IHBzLCBwYWRkcl90IHBlKQ0KK3sNCisgICAgICAgIGJvb3RtZW1fcmVnaW9uX3phcChwcyA+
PiBQQUdFX1NISUZULCBwZSA+PiBQQUdFX1NISUZUKTsNCit9DQorDQogdm9pZCBfX2luaXQgaW5p
dF9ib290X3BhZ2VzKHBhZGRyX3QgcHMsIHBhZGRyX3QgcGUpDQogew0KICAgICB1bnNpZ25lZCBs
b25nIGJhZF9zcGZuLCBiYWRfZXBmbjsNCmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9pbmNsdWRl
L2FzbS1hcm0vbW0uaA0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9tbS5oCUZyaSBGZWIgMDMg
MTc6NDc6MzIgMjAxMiArMDkwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9tbS5oCU1vbiBG
ZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMA0KQEAgLTEwOCw2ICsxMDgsMTMgQEANCiANCiAjZGVm
aW5lIHdyaXRlX3B0YmFzZSh2KQljcHVfc3dpdGNoX3R0YigodiktPmFyY2guY3R4LnR0YnIwKQ0K
IA0KKyNpZiAwDQorI3VuZGVmIHBhZ2VfbGlzdF9lbnRyeQ0KK3N0cnVjdCBwYWdlX2xpc3RfZW50
cnkNCit7DQorCXVuc2lnbmVkIGxvbmcgbmV4dCwgcHJldjsNCit9Ow0KKyNlbmRpZg0KIHN0cnVj
dCBwYWdlX2luZm8NCiB7DQogCXN0cnVjdCBwYWdlX2xpc3RfZW50cnkgbGlzdDsNCkBAIC0xODcs
NiArMTk0LDcgQEAgZXh0ZXJuIHVuc2lnbmVkIGxvbmcgbWluX3BhZ2UsIG1heF9wYWdlOw0KIGV4
dGVybiBzdHJ1Y3QgZG9tYWluICpkb21feGVuLCAqZG9tX2lvLCAqZG9tX2NvdzsNCiBleHRlcm4g
c3RydWN0IHBhZ2VfaW5mbyAqZnJhbWVfdGFibGU7DQogDQorZXh0ZXJuIGwxZV90ICp4ZW5fdHJh
bnNsYXRpb25fdGFibGU7DQogdm9pZCBtZW1ndWFyZF9ndWFyZF9zdGFjayh2b2lkICpwKTsNCiAN
CiB2b2lkIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwg
c3RydWN0IGRvbWFpbiAqZCwgaW50IHJlYWRvbmx5KTsNCkBAIC0yMTQsNiArMjIyLDExIEBAIGxv
bmcgYXJjaF9tZW1vcnlfb3AoaW50IG9wLCBYRU5fR1VFU1RfSEENCiANCiBpbnQgbWFwX3BhZ2Vz
X3RvX3hlbih1bnNpZ25lZCBsb25nIHZpcnQsIHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgbnIsIHVu
c2lnbmVkIGxvbmcgZmxhZ3MpOw0KIA0KK3Vuc2lnbmVkIGxvbmcgYWxsb2NfcGFnZV9tYXBfdGFi
bGVzKGwxZV90ICpsMWUpOw0KKw0KK2ludCBhbGxvY19wYWdlX21hcCh1bnNpZ25lZCBsb25nIHZp
cnQsIHVuc2lnbmVkIGxvbmcgcGh5cywgdW5zaWduZWQgaW50IHNpemUsIHVuc2lnbmVkIGludCBm
bGFncyk7DQorDQorDQogc3RhdGljIGlubGluZSB2b2lkIHB1dF9wYWdlX2FuZF90eXBlKHN0cnVj
dCBwYWdlX2luZm8gKnBhZ2UpDQogew0KIAlwdXRfcGFnZV90eXBlKHBhZ2UpOw0KQEAgLTIzNCw0
ICsyNDcsMTkgQEAgc3RhdGljIGlubGluZSBpbnQgZ2V0X3BhZ2VfYW5kX3R5cGUoc3RydQ0KIAly
ZXR1cm4gcmM7DQogfQ0KIA0KKy8qDQorICogVERCIDogUGFnZSBvd25lciBzZXR0aW5nLg0KKyAq
Lw0KKyNkZWZpbmUgYWxsb2NfcGFnZXMobnIpCVwNCisJKGFsbG9jX2Jvb3RfcGFnZXMobnIsIFBB
R0VfU0laRSkgPDwgUEFHRV9TSElGVCkNCisNCisjZGVmaW5lIGFsbG9jX2NsZWFuX3BhZ2VzKG5y
KQkJCQlcDQorKHsJCQkJCQkJXA0KKwl1bnNpZ25lZCBsb25nIHBhZ2U7CQkJCVwNCisJcGFnZSA9
IGFsbG9jX3BhZ2VzKG5yKTsJCQkJXA0KKwlpZiAocGFnZSkgewkJCQkJXA0KKwkJbWVtc2V0KHBh
Z2UsIDAsIG5yIDw8IFBBR0VfU0hJRlQpOwlcDQorCX0JCQkJCQlcDQorCXBhZ2U7CQkJCQkJXA0K
K30pDQogI2VuZGlmIC8qIF9fQVJNX01NX0hfXyAqLw0KZGlmZiAtciA0ZDYxZjAyZmRlMzcgeGVu
L2luY2x1ZGUvYXNtLWFybS9tbXUuaA0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaAlG
cmkgRmViIDAzIDE3OjQ3OjMyIDIwMTIgKzA5MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0v
bW11LmgJTW9uIEZlYiAwNiAxMToxNjozNyAyMDEyICswOTAwDQpAQCAtMTQwLDYgKzE0MCwxNiBA
QA0KICNkZWZpbmUgbDFfbGluZWFyX29mZnNldF94ZW4odmEpCVwNCiAJKGwxX2xpbmVhcl9vZmZz
ZXQoKHhlbl90cmFuc2xhdGlvbl90YWJsZSksIHZhKSkNCiANCisjZGVmaW5lIHB0ZV9zeW5jKHB0
cikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQor
ZG8geyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KKyAgICAgICAgX19hc21fXyBfX3ZvbGF0aWxlX18oICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCisgICAgICAgICJtY3IgcDE1LCAw
LCAlMCwgYzcsIGMxMCwgMSBAIGNsZWFuIEQgZW50cnkgICAgIFxuIiAgICAgICAgICAgICBcDQor
ICAgICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KKyAgICAgICAgOiAiciIocHRyKSwgInIiKDApICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCisgICAgICAgIDogIm1lbW9yeSIp
OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQor
fXdoaWxlKDApDQorDQorDQogdHlwZWRlZiBzdHJ1Y3QgeyB1bnNpZ25lZCBsb25nIGwyZTsgfSBs
MmVfdDsNCiB0eXBlZGVmIHN0cnVjdCB7IHVuc2lnbmVkIGxvbmcgbDFlOyB9IGwxZV90Ow0KIA0K
ZGlmZiAtciA0ZDYxZjAyZmRlMzcgeGVuL2luY2x1ZGUvYXNtLWFybS9wbGF0Zm9ybS5oDQotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysrIGIveGVuL2luY2x1
ZGUvYXNtLWFybS9wbGF0Zm9ybS5oCU1vbiBGZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMA0KQEAg
LTAsMCArMSw2MiBAQA0KKy8qDQorICogcGxhdGZvcm0uaA0KKyAqDQorICogQ29weXJpZ2h0IChD
KSAyMDA4IFNhbXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBKYWVNaW4gUnl1ICA8am03
Ny5yeXVAc2Ftc3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2Fy
ZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAqIGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFz
IHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uDQorICoNCisg
KiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJl
IHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBB
IFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVk
IGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisgKiBhbG9uZyB3aXRo
IHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KKyAqIEZv
dW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAw
MjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisjaWZuZGVmIF9fQVJNX1BMQVRGT1JNX0hfXw0KKyNk
ZWZpbmUgX19BUk1fUExBVEZPUk1fSF9fDQorDQorI2luY2x1ZGUgPHhlbi9saXN0Lmg+DQorDQor
I2RlZmluZSBNRU1PUllfVFlQRV9SQU0JCSgwKQ0KKyNkZWZpbmUgTUVNT1JZX1RZUEVfUk9NCQko
MSkNCisjZGVmaW5lIE1FTU9SWV9UWVBFX0RFVgkJKDIpDQorI2RlZmluZSBNRU1PUllfVFlQRV9N
QVNLCSgweEYpDQorDQorI2lmZGVmIF9fQVNTRU1CTFlfXw0KKyNkZWZpbmUgREVDTEFSRV9QTEFU
Rk9STV9PUChnb3AsIG5vcCkJXA0KKyAgICAgICAgLnNldCBnb3AsIG5vcCAgICAgICAgICAgICAg
ICAgICA7XA0KKwkuZ2xvYmFsIGdvcCAgICAgICAgICAgICAgICAgICAgIDsNCisjZWxzZQ0KKyNk
ZWZpbmUgREVDTEFSRV9QTEFURk9STV9PUChnb3AsIG5vcCkJXA0KKyAgICAgICAgdHlwZW9mIChu
b3ApIGdvcCAgICAgICAgICAgICAgICBcDQorCV9fYXR0cmlidXRlX18oKHdlYWssIGFsaWFzKCNu
b3ApKSkNCisNCisNCisjZGVmaW5lIERFQ0xBUkVfTUVNT1JZX01BUChfbikgIFwNCitzdHJ1Y3Qg
bWVtb3J5X21hcCBfX2F0dHJpYnV0ZV9fICgoX19zZWN0aW9uX18oIi5pbml0Lm1lbXRhYmxlIikp
KSBfbiAjIyBfbWVtbWFwW10NCisNCisjZGVmaW5lIE1FTU1BUF9FTlRSWShiLCBzLCB0LCBmKSB7
YiwgcywgdCwgKGIgJiB+KDB4MTAwMDAwIC0gMSkpIHwgZn0NCisNCitzdHJ1Y3QgbWVtb3J5X21h
cCB7DQorCXVuc2lnbmVkIGxvbmcgYmFzZTsNCisJdW5zaWduZWQgaW50IHNpemU7DQorCXVuc2ln
bmVkIGludCB0eXBlOw0KKwl1bnNpZ25lZCBpbnQgZmxhZ3M7DQorfTsNCisNCisjZGVmaW5lIGl0
ZXJhdGVfbWVtb3J5X21hcChlbnRyeSkJXA0KKwlmb3IgKGVudHJ5ID0gJl9zbWVtdGFibGU7IGVu
dHJ5IDwgJl9lbWVtdGFibGU7IGVudHJ5KyspDQorCQ0KKyNkZWZpbmUgbWVtb3J5X21hcF90eXBl
KGVudHJ5KQkoZW50cnktPnR5cGUgJiBNRU1PUllfVFlQRV9NQVNLKQ0KKw0KK2V4dGVybiBzdHJ1
Y3QgbWVtb3J5X21hcCAqX3NtZW10YWJsZSwgKl9lbWVtdGFibGU7DQorDQorI2VuZGlmDQorI2Vu
ZGlmIC8qIF9fQVJNX1BMQVRGT1JNX0hfXyAqLw0KKw0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch06.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch06.diff"


CmFybTogYWxsb3cgYWNjZXNzIHRvIHRoZSB4ZW5oZWFwIGFuZCB0aGUgYm9vdCBwYWdlcy4K
ClRoaXMgcGF0Y2ggY29sbGVjdHMgbWFjaGluZSBwYWdlIGZyYW1lcywgY3JlYXRlcyBmcmFt
ZSB0YWJsZSB0byBhbGxvdyBhY2Nlc3MgdG8gdGhlIHhlbmhlYXAgYW5kIHRoZSBib290IHBh
Z2VzLgoKIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICB8ICAgNjUgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogeGVuL2FyY2gvYXJt
L3hlbi9zZXR1cC5jICAgICAgIHwgIDExNSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysKIHhlbi9jb21tb24vcGFnZV9hbGxvYy5jICAgICAgICB8ICAgIDUgKysrCiB4ZW4v
aW5jbHVkZS9hc20tYXJtL21tLmggICAgICAgfCAgIDI4ICsrKysrKysrKysrKysrKysrKysr
KwogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCAgICAgIHwgICAxMCArKysrKysrCiB4ZW4v
aW5jbHVkZS9hc20tYXJtL3BsYXRmb3JtLmggfCAgIDYyICsrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUg
PGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciA0ZDYxZjAyZmRlMzcgeGVuL2FyY2gv
YXJtL3hlbi9tbS5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlGcmkgRmViIDAzIDE3
OjQ3OjMyIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9tbS5jCU1vbiBGZWIg
MDYgMTE6MTY6MzcgMjAxMiArMDkwMApAQCAtMTkyLDMgKzE5Miw2OCBAQCBpbnQgcGFnZV9p
c19yYW1fdHlwZSh1bnNpZ25lZCBsb25nIG1mbiwgCiAKIAlyZXR1cm4gLUVJTlZBTDsKIH0K
KworI2RlZmluZSBQVFNfUEVSX1BBR0UgICAgNAorCisvKgorICogNCBwYWdlIHRhYmxlcyBw
ZXIgYSBwYWdlLgorICovCitzdGF0aWMgaW5saW5lIHZvaWQgd2lyZV9wYWdlX3RhYmxlcyhs
MWVfdCAqbDFlLCB1bnNpZ25lZCBsb25nIHRhYmxlcykKK3sKKwlsMWUgPSAobDFlX3QgKiko
KHVuc2lnbmVkIGxvbmcpbDFlICYgfihQVFNfUEVSX1BBR0UgLSAxKSk7CisKKwkqKGwxZSAr
IDApID0gTUtfTDFFKHRhYmxlcyArIDAsICAgIEwxRV9HVUVTVF9UQUJMRSk7IHB0ZV9zeW5j
KGwxZSArIDApOworCSoobDFlICsgMSkgPSBNS19MMUUodGFibGVzICsgMTAyNCwgTDFFX0dV
RVNUX1RBQkxFKTsgcHRlX3N5bmMobDFlICsgMSk7CisJKihsMWUgKyAyKSA9IE1LX0wxRSh0
YWJsZXMgKyAyMDQ4LCBMMUVfR1VFU1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAyKTsKKwkq
KGwxZSArIDMpID0gTUtfTDFFKHRhYmxlcyArIDMwNzIsIEwxRV9HVUVTVF9UQUJMRSk7IHB0
ZV9zeW5jKGwxZSArIDMpOworfQorCit1bnNpZ25lZCBsb25nIGFsbG9jX3BhZ2VfdGFibGVz
KGwxZV90ICpsMWUpCit7CisJdW5zaWduZWQgbG9uZyBwYWdlOworCisJcGFnZSA9IGFsbG9j
X2NsZWFuX3BhZ2VzKDEpOworCWlmICghcGFnZSkgeworCQlyZXR1cm4gMDsKKwl9CisKKy8v
CWNhY2hlX2NsZWFuX3JhbmdlKHBhZ2UsIHBhZ2UgKyBQQUdFX1NJWkUsIDApOworCisJd2ly
ZV9wYWdlX3RhYmxlcyhsMWUsIHBhZ2UpOworCisJcmV0dXJuIHBhZ2U7Cit9CisKKworaW50
IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcgdmlydCwgdW5zaWduZWQgbG9uZyBwaHlz
LCB1bnNpZ25lZCBpbnQgc2l6ZSwgdW5zaWduZWQgaW50IGZsYWdzKQoreworCWwxZV90ICps
MWU7CisJdW5zaWduZWQgbG9uZyB2YWRkciA9IHJvdW5kX2Rvd24odmlydCwgUEFHRV9TSVpF
KTsKKwl1bnNpZ25lZCBsb25nIGxhc3QgPSB2aXJ0ICsgc2l6ZTsKKworCWwxZSA9IGwxX2xp
bmVhcl9vZmZzZXRfeGVuKHZhZGRyKTsKKworCWRvIHsKKwkJbDJlX3QgKmwyZTsKKwkJdW5z
aWduZWQgbG9uZyBlbmQgPSAodmFkZHIgKyAoU0VDVElPTl9TSVpFICogUFRTX1BFUl9QQUdF
KSkgJiAoU0VDVElPTl9NQVNLKTsKKwkJZW5kID0gKGVuZCA8IGxhc3QpID8gZW5kIDogbGFz
dDsKKworCQlpZiAoIWwxZV92YWwoKmwxZSkpIHsKKwkJCWlmICghYWxsb2NfcGFnZV90YWJs
ZXMobDFlKSkgeworCQkJCXJldHVybiAtRU5PTUVNOworCQkJfQorCQl9CisKKwkJbDJlID0g
bDJfbGluZWFyX29mZnNldChsMWUsIHZhZGRyKTsKKwkJZG8geworCQkJKmwyZSA9IE1LX0wy
RShwaHlzLCBmbGFncyk7CisJCQlwdGVfc3luYyhsMmUpOworCisJCQlwaHlzICs9IFBBR0Vf
U0laRTsKKwkJCXZhZGRyICs9IFBBR0VfU0laRTsKKwkJfSB3aGlsZShsMmUrKywgdmFkZHIg
PCBlbmQpOworCX0gd2hpbGUobDFlICs9IDQsIHZhZGRyIDwgbGFzdCk7CisKKwlyZXR1cm4g
MDsKK30KKwpkaWZmIC1yIDRkNjFmMDJmZGUzNyB4ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMK
LS0tIGEveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCUZyaSBGZWIgMDMgMTc6NDc6MzIgMjAx
MiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMJTW9uIEZlYiAwNiAxMTox
NjozNyAyMDEyICswOTAwCkBAIC0zMSw2ICszMSw3IEBACiAjaW5jbHVkZSA8cHVibGljL3Zl
cnNpb24uaD4KICNpbmNsdWRlIDxwdWJsaWMvc2NoZWQuaD4KICNpbmNsdWRlIDxhc20vbW11
Lmg+CisjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+CiAKIHN0cnVjdCBkb21haW4gX2RvbV94
ZW4gPSB7CiAJLnJlZmNudCA9IEFUT01JQ19JTklUKDEpLApAQCAtNzQsNiArNzUsMTE4IEBA
IHZvaWQgYXJjaF9nZXRfeGVuX2NhcHMoeGVuX2NhcGFiaWxpdGllc18KIHsKIH0KIAorc3Rh
dGljIHVuc2lnbmVkIGxvbmcgbG9va3VwX3hlbl9waHlzX3N0YXJ0KHZvaWQpCit7CisgICAg
ICAgIGwxZV90ICpsMWU7CisKKyAgICAgICAgbDFlID0gbDFfbGluZWFyX29mZnNldF94ZW4o
WEVOX1ZJUlRfU1RBUlQpOworCisgICAgICAgIHJldHVybiBsMWVfdmFsKCpsMWUpICYgU0VD
VElPTl9NQVNLOworfQorCitzdGF0aWMgdW5zaWduZWQgbG9uZyBsb29rdXBfeGVuX3BoeXNf
ZW5kKHZvaWQpCit7CisJbDFlX3QgKmwxZTsKKworCWwxZSA9IGwxX2xpbmVhcl9vZmZzZXRf
eGVuKFhFTl9WSVJUX1NUQVJUKTsKKworCXdoaWxlKGwxZV92YWwoKihsMWUgKyAxKSkgIT0g
MCkKKwkJbDFlKys7CisKKwlyZXR1cm4gKGwxZV92YWwoKmwxZSkgJiBTRUNUSU9OX01BU0sp
ICsgU0VDVElPTl9TSVpFOworfQorCitzdGF0aWMgdW5zaWduZWQgaW50IGJvb3RfcGFnZV9j
b2xsZWN0b3IodW5zaWduZWQgbG9uZyBzdGFydCwgdW5zaWduZWQgbG9uZyBzaXplKQorewor
CXVuc2lnbmVkIGxvbmcgZW5kID0gc3RhcnQgKyBzaXplOworCisJaW5pdF9ib290X3BhZ2Vz
KHN0YXJ0LCBlbmQpOworCisJc3RhcnQgPSBzdGFydCA+PiBQQUdFX1NISUZUOworCWVuZCAg
ID0gZW5kICAgPj4gUEFHRV9TSElGVDsKKworCW1pbl9wYWdlID0gbWluKHN0YXJ0LCBtaW5f
cGFnZSk7CisJbWF4X3BhZ2UgPSBtYXgoZW5kLCBtYXhfcGFnZSk7CisKKwlyZXR1cm4gc2l6
ZSA+PiBQQUdFX1NISUZUOworfQorCisjZGVmaW5lIEZSQU1FX1RBQkxFX0JBU0UJMHhGQzAw
MDAwMFVMCisKKy8qCisgKiBUaGUgdmlydHVhbCBhZGRyZXNzIG9mIHRoZSBmcmFtZSB0YWJs
ZSBzaG91bGQgYmUgYWxpZ25lZCB0byA0TUIgYm91bmRhcnkuCisgKi8KK3N0cnVjdCBwYWdl
X2luZm8gKmFsbG9jX2ZyYW1lX3RhYmxlKHVuc2lnbmVkIGludCBzeikKK3sKKwl1bnNpZ25l
ZCBsb25nIHN0YXJ0OworCisJc3RhcnQgPSBhbGxvY19wYWdlcyhzeiA+PiBQQUdFX1NISUZU
KTsKKwlpZiAoIXN0YXJ0KSB7CisJCXJldHVybiBOVUxMOworCX0KKworCWlmKGFsbG9jX3Bh
Z2VfbWFwKEZSQU1FX1RBQkxFX0JBU0UsIHN0YXJ0LCBzeiwgTDJFX0dVRVNUX1BBR0UpIDwg
MCkgeworCQlyZXR1cm4gTlVMTDsKKwl9CisKKwlyZXR1cm4gKHN0cnVjdCBwYWdlX2luZm8g
KilGUkFNRV9UQUJMRV9CQVNFOworfQorCitzdGF0aWMgdm9pZCBmcmFtZV90YWJsZV9zZXR1
cCh1bnNpZ25lZCBpbnQgbnJfYm9vdF9wYWdlcykKK3sKKwlpbnQgaTsKKwl1bnNpZ25lZCBp
bnQgc2l6ZTsKKworICAgICAgICBzaXplID0gcm91bmRfdXAobnJfYm9vdF9wYWdlcyAqIHNp
emVvZihzdHJ1Y3QgcGFnZV9pbmZvKSwgUEFHRV9TSVpFKTsKKworCS8qIFRoZSBsb2NhdGlv
biBvZiB0aGUgZnJhbWVfdGFibGUgY291bGQgYmUgY2hhbmdlZCBpbiBuZWFyIGZ1dHVyZS4K
KwkgKiBTbywgZGVjaXNpb24gbWFraW5nIG9mIHRoZSB2aXJ0dWFsIGFkZHJlc3MgaXMgYWx3
YXlzIHBlcmZvcm1lZCBpbiAKKwkgKiBhbGxvY19mcmFtZV90YWJsZSgpCisJICovCisKKwlm
cmFtZV90YWJsZSA9IGFsbG9jX2ZyYW1lX3RhYmxlKHNpemUpOworCWlmIChmcmFtZV90YWJs
ZSA9PSBOVUxMKSB7CisJCXBhbmljKCJOb21lbVxuIik7CisJfQorCisgICAgICAgIG1lbXNl
dChmcmFtZV90YWJsZSwgMCwgc2l6ZSk7Cit9CisKK3Vuc2lnbmVkIGludCBwcmVwYXJlX3Bh
Z2VfZnJhbWVzKHZvaWQpCit7CisJc3RydWN0IG1lbW9yeV9tYXAgKmVudDsKKyAgICAgICAg
dW5zaWduZWQgbG9uZyBzdGFydCwgZW5kOworCXVuc2lnbmVkIGludCBwYWdlcyA9IDA7CisK
KwkvKiBGb3IgdmlydF90b19tYWRkcigpIG1hY3JvLiAqLworCXhlbl9waHlzX3N0YXJ0ID0g
bG9va3VwX3hlbl9waHlzX3N0YXJ0KCk7CisJeGVuX3BoeXNfZW5kID0gbG9va3VwX3hlbl9w
aHlzX2VuZCgpOworCisgICAgICAgIC8qIEZvciBwb3B1bGF0aW5nIGJvb3RtZW1fcmVnaW9u
X2xpc3QgKi8KKyAgICAgICAgc3RhcnQgPSByb3VuZF9kb3duKHZpcnRfdG9fbWFkZHIoJl9l
bmQpLCBQQUdFX1NJWkUpOworICAgICAgICBlbmQgPSBzdGFydCArIFBBR0VfU0laRTsKKwor
ICAgICAgICBpbml0X2Jvb3RfcGFnZXMoc3RhcnQsIGVuZCk7CisKKwkvKiBGb3IgZWFybHkg
eGVuaGVhcCBhbGxvY2F0aW9uICovCisgICAgICAgIHhlbmhlYXBfcGh5c19zdGFydCA9IGVu
ZDsKKyAgICAgICAgeGVuaGVhcF9waHlzX2VuZCA9IHhlbl9waHlzX2VuZDsKKworCWl0ZXJh
dGVfbWVtb3J5X21hcChlbnQpIHsKKwkJaWYgKGVudC0+dHlwZSA9PSBNRU1PUllfVFlQRV9S
QU0pIHsKKwkJCXBhZ2VzICs9IGJvb3RfcGFnZV9jb2xsZWN0b3IoZW50LT5iYXNlLCBlbnQt
PnNpemUpOworCQl9CisJfQorCisJcmVzZXJ2ZV9ib290X3BhZ2VzKHhlbl9waHlzX3N0YXJ0
LCB4ZW5fcGh5c19lbmQpOworCisJZnJhbWVfdGFibGVfc2V0dXAocGFnZXMpOworCisgICAg
ICAgIGluaXRfeGVuaGVhcF9wYWdlcyh4ZW5oZWFwX3BoeXNfc3RhcnQsIHhlbmhlYXBfcGh5
c19lbmQpOworCisJcmV0dXJuIHBhZ2VzOworfQorCiBzdGF0aWMgdm9pZCBpZGxlX2RvbWFp
bl9pbml0KHZvaWQpCiB7CiAJc3RydWN0IHZjcHUgKnY7CkBAIC05Miw2ICsyMDUsOCBAQCBh
c21saW5rYWdlIHZvaWQgc3RhcnRfeGVuKHZvaWQpCiAKIAlzbXBfcHJlcGFyZV9ib290X2Nw
dSgpOwogCisJcHJlcGFyZV9wYWdlX2ZyYW1lcygpOworCiAJc29mdGlycV9pbml0KCk7CiAK
IAl0YXNrbGV0X3N1YnN5c19pbml0KCk7CmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9jb21t
b24vcGFnZV9hbGxvYy5jCi0tLSBhL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCUZyaSBGZWIg
MDMgMTc6NDc6MzIgMjAxMiArMDkwMAorKysgYi94ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYwlN
b24gRmViIDA2IDExOjE2OjM3IDIwMTIgKzA5MDAKQEAgLTE0Niw2ICsxNDYsMTEgQEAgc3Rh
dGljIHZvaWQgX19pbml0IGJvb3RtZW1fcmVnaW9uX3phcCh1bgogICAgIH0KIH0KIAordm9p
ZCBfX2luaXQgcmVzZXJ2ZV9ib290X3BhZ2VzKHBhZGRyX3QgcHMsIHBhZGRyX3QgcGUpCit7
CisgICAgICAgIGJvb3RtZW1fcmVnaW9uX3phcChwcyA+PiBQQUdFX1NISUZULCBwZSA+PiBQ
QUdFX1NISUZUKTsKK30KKwogdm9pZCBfX2luaXQgaW5pdF9ib290X3BhZ2VzKHBhZGRyX3Qg
cHMsIHBhZGRyX3QgcGUpCiB7CiAgICAgdW5zaWduZWQgbG9uZyBiYWRfc3BmbiwgYmFkX2Vw
Zm47CmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9pbmNsdWRlL2FzbS1hcm0vbW0uaAotLS0g
YS94ZW4vaW5jbHVkZS9hc20tYXJtL21tLmgJRnJpIEZlYiAwMyAxNzo0NzozMiAyMDEyICsw
OTAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW0uaAlNb24gRmViIDA2IDExOjE2OjM3
IDIwMTIgKzA5MDAKQEAgLTEwOCw2ICsxMDgsMTMgQEAKIAogI2RlZmluZSB3cml0ZV9wdGJh
c2UodikJY3B1X3N3aXRjaF90dGIoKHYpLT5hcmNoLmN0eC50dGJyMCkKIAorI2lmIDAKKyN1
bmRlZiBwYWdlX2xpc3RfZW50cnkKK3N0cnVjdCBwYWdlX2xpc3RfZW50cnkKK3sKKwl1bnNp
Z25lZCBsb25nIG5leHQsIHByZXY7Cit9OworI2VuZGlmCiBzdHJ1Y3QgcGFnZV9pbmZvCiB7
CiAJc3RydWN0IHBhZ2VfbGlzdF9lbnRyeSBsaXN0OwpAQCAtMTg3LDYgKzE5NCw3IEBAIGV4
dGVybiB1bnNpZ25lZCBsb25nIG1pbl9wYWdlLCBtYXhfcGFnZTsKIGV4dGVybiBzdHJ1Y3Qg
ZG9tYWluICpkb21feGVuLCAqZG9tX2lvLCAqZG9tX2NvdzsKIGV4dGVybiBzdHJ1Y3QgcGFn
ZV9pbmZvICpmcmFtZV90YWJsZTsKIAorZXh0ZXJuIGwxZV90ICp4ZW5fdHJhbnNsYXRpb25f
dGFibGU7CiB2b2lkIG1lbWd1YXJkX2d1YXJkX3N0YWNrKHZvaWQgKnApOwogCiB2b2lkIHNo
YXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgc3RydWN0
IGRvbWFpbiAqZCwgaW50IHJlYWRvbmx5KTsKQEAgLTIxNCw2ICsyMjIsMTEgQEAgbG9uZyBh
cmNoX21lbW9yeV9vcChpbnQgb3AsIFhFTl9HVUVTVF9IQQogCiBpbnQgbWFwX3BhZ2VzX3Rv
X3hlbih1bnNpZ25lZCBsb25nIHZpcnQsIHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgbnIsIHVu
c2lnbmVkIGxvbmcgZmxhZ3MpOwogCit1bnNpZ25lZCBsb25nIGFsbG9jX3BhZ2VfbWFwX3Rh
YmxlcyhsMWVfdCAqbDFlKTsKKworaW50IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcg
dmlydCwgdW5zaWduZWQgbG9uZyBwaHlzLCB1bnNpZ25lZCBpbnQgc2l6ZSwgdW5zaWduZWQg
aW50IGZsYWdzKTsKKworCiBzdGF0aWMgaW5saW5lIHZvaWQgcHV0X3BhZ2VfYW5kX3R5cGUo
c3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkKIHsKIAlwdXRfcGFnZV90eXBlKHBhZ2UpOwpAQCAt
MjM0LDQgKzI0NywxOSBAQCBzdGF0aWMgaW5saW5lIGludCBnZXRfcGFnZV9hbmRfdHlwZShz
dHJ1CiAJcmV0dXJuIHJjOwogfQogCisvKgorICogVERCIDogUGFnZSBvd25lciBzZXR0aW5n
LgorICovCisjZGVmaW5lIGFsbG9jX3BhZ2VzKG5yKQlcCisJKGFsbG9jX2Jvb3RfcGFnZXMo
bnIsIFBBR0VfU0laRSkgPDwgUEFHRV9TSElGVCkKKworI2RlZmluZSBhbGxvY19jbGVhbl9w
YWdlcyhucikJCQkJXAorKHsJCQkJCQkJXAorCXVuc2lnbmVkIGxvbmcgcGFnZTsJCQkJXAor
CXBhZ2UgPSBhbGxvY19wYWdlcyhucik7CQkJCVwKKwlpZiAocGFnZSkgewkJCQkJXAorCQlt
ZW1zZXQocGFnZSwgMCwgbnIgPDwgUEFHRV9TSElGVCk7CVwKKwl9CQkJCQkJXAorCXBhZ2U7
CQkJCQkJXAorfSkKICNlbmRpZiAvKiBfX0FSTV9NTV9IX18gKi8KZGlmZiAtciA0ZDYxZjAy
ZmRlMzcgeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20t
YXJtL21tdS5oCUZyaSBGZWIgMDMgMTc6NDc6MzIgMjAxMiArMDkwMAorKysgYi94ZW4vaW5j
bHVkZS9hc20tYXJtL21tdS5oCU1vbiBGZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMApAQCAt
MTQwLDYgKzE0MCwxNiBAQAogI2RlZmluZSBsMV9saW5lYXJfb2Zmc2V0X3hlbih2YSkJXAog
CShsMV9saW5lYXJfb2Zmc2V0KCh4ZW5fdHJhbnNsYXRpb25fdGFibGUpLCB2YSkpCiAKKyNk
ZWZpbmUgcHRlX3N5bmMocHRyKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKK2RvIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgX19hc21f
XyBfX3ZvbGF0aWxlX18oICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgIm1jciBwMTUsIDAsICUwLCBjNywgYzEwLCAxIEAgY2xlYW4gRCBl
bnRyeSAgICAgXG4iICAgICAgICAgICAgIFwKKyAgICAgICAgOiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgOiAiciIocHRyKSwgInIiKDApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKKyAgICAgICAgOiAibWVtb3J5Iik7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKK313aGlsZSgwKQorCisKIHR5
cGVkZWYgc3RydWN0IHsgdW5zaWduZWQgbG9uZyBsMmU7IH0gbDJlX3Q7CiB0eXBlZGVmIHN0
cnVjdCB7IHVuc2lnbmVkIGxvbmcgbDFlOyB9IGwxZV90OwogCmRpZmYgLXIgNGQ2MWYwMmZk
ZTM3IHhlbi9pbmNsdWRlL2FzbS1hcm0vcGxhdGZvcm0uaAotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3Bs
YXRmb3JtLmgJTW9uIEZlYiAwNiAxMToxNjozNyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjIg
QEAKKy8qCisgKiBwbGF0Zm9ybS5oCisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4IFNhbXN1
bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAgIEphZU1pbiBSeXUgIDxqbTc3LnJ5dUBzYW1z
dW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVi
bGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRo
aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUg
dXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJl
Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFs
b25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3
YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwg
Qm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2lmbmRlZiBfX0FSTV9QTEFU
Rk9STV9IX18KKyNkZWZpbmUgX19BUk1fUExBVEZPUk1fSF9fCisKKyNpbmNsdWRlIDx4ZW4v
bGlzdC5oPgorCisjZGVmaW5lIE1FTU9SWV9UWVBFX1JBTQkJKDApCisjZGVmaW5lIE1FTU9S
WV9UWVBFX1JPTQkJKDEpCisjZGVmaW5lIE1FTU9SWV9UWVBFX0RFVgkJKDIpCisjZGVmaW5l
IE1FTU9SWV9UWVBFX01BU0sJKDB4RikKKworI2lmZGVmIF9fQVNTRU1CTFlfXworI2RlZmlu
ZSBERUNMQVJFX1BMQVRGT1JNX09QKGdvcCwgbm9wKQlcCisgICAgICAgIC5zZXQgZ29wLCBu
b3AgICAgICAgICAgICAgICAgICAgO1wKKwkuZ2xvYmFsIGdvcCAgICAgICAgICAgICAgICAg
ICAgIDsKKyNlbHNlCisjZGVmaW5lIERFQ0xBUkVfUExBVEZPUk1fT1AoZ29wLCBub3ApCVwK
KyAgICAgICAgdHlwZW9mIChub3ApIGdvcCAgICAgICAgICAgICAgICBcCisJX19hdHRyaWJ1
dGVfXygod2VhaywgYWxpYXMoI25vcCkpKQorCisKKyNkZWZpbmUgREVDTEFSRV9NRU1PUllf
TUFQKF9uKSAgXAorc3RydWN0IG1lbW9yeV9tYXAgX19hdHRyaWJ1dGVfXyAoKF9fc2VjdGlv
bl9fKCIuaW5pdC5tZW10YWJsZSIpKSkgX24gIyMgX21lbW1hcFtdCisKKyNkZWZpbmUgTUVN
TUFQX0VOVFJZKGIsIHMsIHQsIGYpIHtiLCBzLCB0LCAoYiAmIH4oMHgxMDAwMDAgLSAxKSkg
fCBmfQorCitzdHJ1Y3QgbWVtb3J5X21hcCB7CisJdW5zaWduZWQgbG9uZyBiYXNlOworCXVu
c2lnbmVkIGludCBzaXplOworCXVuc2lnbmVkIGludCB0eXBlOworCXVuc2lnbmVkIGludCBm
bGFnczsKK307CisKKyNkZWZpbmUgaXRlcmF0ZV9tZW1vcnlfbWFwKGVudHJ5KQlcCisJZm9y
IChlbnRyeSA9ICZfc21lbXRhYmxlOyBlbnRyeSA8ICZfZW1lbXRhYmxlOyBlbnRyeSsrKQor
CQorI2RlZmluZSBtZW1vcnlfbWFwX3R5cGUoZW50cnkpCShlbnRyeS0+dHlwZSAmIE1FTU9S
WV9UWVBFX01BU0spCisKK2V4dGVybiBzdHJ1Y3QgbWVtb3J5X21hcCAqX3NtZW10YWJsZSwg
Kl9lbWVtdGFibGU7CisKKyNlbmRpZgorI2VuZGlmIC8qIF9fQVJNX1BMQVRGT1JNX0hfXyAq
LworCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt17-0005yC-A7; Mon, 13 Feb 2012 10:20:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqq0-0003rV-E3
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:00:40 +0000
Received: from [85.158.139.83:57958] by server-3.bemta-5.messagelabs.com id
	BB/ED-25605-723C83F4; Mon, 13 Feb 2012 08:00:39 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329120037!14713126!1
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29154 invoked from network); 13 Feb 2012 08:00:38 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-7.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 08:00:38 -0000
Received: from epcpsbge3.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB0007ENJOD280@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:00:37 +0900 (KST)
Message-id: <0LZB0009YNL1D280@mailout1.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-3c-4f38c324210a
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id B9.AC.17710.423C83F4;
	Mon, 13 Feb 2012 17:00:36 +0900 (KST)
Date: Mon, 13 Feb 2012 08:00:36 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075949918@jm77.ryu
Msgkey: 20120213075949918@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075853731@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 08/14] arm: implement do_set_trap_table function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <17343029.70141329120032962.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgZG9fc2V0X3RyYXBfdGFibGUgZnVuY3Rpb24NCg0KU2lnbmVkLW9mZi1i
eTogSmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgMzM0ZGZkZWJk
ZTEyIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9mYXVs
dC5jCVN1biBGZWIgMTIgMTE6NDY6NTIgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9mYXVsdC5jCVN1biBGZWIgMTIgMTE6NTQ6MzMgMjAxMiArMDkwMA0KQEAgLTExOCw2ICsxMTgs
MjIgQEAgdm9pZCB1bnJlZ2lzdGVyX2d1ZXN0X25taV9jYWxsYmFjayh2b2lkKQ0KIA0KIGxvbmcg
ZG9fc2V0X3RyYXBfdGFibGUoWEVOX0dVRVNUX0hBTkRMRSh0cmFwX2luZm9fdCkgdHJhcHMpDQog
ew0KKwl1bnNpZ25lZCBsb25nIHRyYXBfdGFibGU7DQorDQorCWlmICggZ3Vlc3RfaGFuZGxlX2lz
X251bGwodHJhcHMpICkNCisJCWdvdG8gZmFpbGVkOw0KKw0KKwl0cmFwX3RhYmxlID0gKHVuc2ln
bmVkIGxvbmcpdHJhcHMucDsNCisNCisJY3VycmVudC0+YXJjaC5jdHgudmJhciA9IHRyYXBfdGFi
bGU7DQorDQorCXJldHVybiAwOw0KKw0KK2ZhaWxlZDoNCisJY3VycmVudC0+YXJjaC5jdHgudmJh
ciA9IDA7DQorDQorCXByaW50aygiVHJhcCB0YWJsZSBpbnN0YWxsIGZhaWxlZFxuIik7DQorDQog
CXJldHVybiAtRUZBVUxUOw0KIH0NCiANCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch08.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch08.diff"


YXJtOiBpbXBsZW1lbnQgZG9fc2V0X3RyYXBfdGFibGUgZnVuY3Rpb24KClNpZ25lZC1vZmYt
Ynk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciAzMzRkZmRl
YmRlMTIgeGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4v
ZmF1bHQuYwlTdW4gRmViIDEyIDExOjQ2OjUyIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9mYXVsdC5jCVN1biBGZWIgMTIgMTE6NTQ6MzMgMjAxMiArMDkwMApAQCAtMTE4
LDYgKzExOCwyMiBAQCB2b2lkIHVucmVnaXN0ZXJfZ3Vlc3Rfbm1pX2NhbGxiYWNrKHZvaWQp
CiANCiBsb25nIGRvX3NldF90cmFwX3RhYmxlKFhFTl9HVUVTVF9IQU5ETEUodHJhcF9pbmZv
X3QpIHRyYXBzKQ0KIHsNCisJdW5zaWduZWQgbG9uZyB0cmFwX3RhYmxlOw0KKw0KKwlpZiAo
IGd1ZXN0X2hhbmRsZV9pc19udWxsKHRyYXBzKSApDQorCQlnb3RvIGZhaWxlZDsNCisNCisJ
dHJhcF90YWJsZSA9ICh1bnNpZ25lZCBsb25nKXRyYXBzLnA7DQorDQorCWN1cnJlbnQtPmFy
Y2guY3R4LnZiYXIgPSB0cmFwX3RhYmxlOw0KKw0KKwlyZXR1cm4gMDsNCisNCitmYWlsZWQ6
DQorCWN1cnJlbnQtPmFyY2guY3R4LnZiYXIgPSAwOw0KKw0KKwlwcmludGsoIlRyYXAgdGFi
bGUgaW5zdGFsbCBmYWlsZWRcbiIpOw0KKw0KIAlyZXR1cm4gLUVGQVVMVDsNCiB9DQogDQo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt16-0005xN-Gl; Mon, 13 Feb 2012 10:20:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqoI-0003K2-4e
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:58:54 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329119926!13681425!1
X-Originating-IP: [203.254.224.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzMgPT4gMjQzNjYx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1959 invoked from network); 13 Feb 2012 07:58:46 -0000
Received: from mailout3.samsung.com (HELO mailout3.samsung.com)
	(203.254.224.33) by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:58:46 -0000
Received: from epcpsbge3.samsung.com (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00CJ0NH6VYD0@mailout3.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:58:45 +0900 (KST)
Message-id: <0LZB00CJVNHXVYD0@mailout3.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-e7-4f38c2b54930
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 4C.AA.17710.5B2C83F4;
	Mon, 13 Feb 2012 16:58:45 +0900 (KST)
Date: Mon, 13 Feb 2012 07:58:45 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075753031@jm77.ryu
Msgkey: 20120213075753031@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075640084@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 06/14] arm: allow access to the xenheap and the
	boot pages.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <13906246.69971329119922192.JavaMail.weblogic@epv6ml04>

DQphcm06IGFsbG93IGFjY2VzcyB0byB0aGUgeGVuaGVhcCBhbmQgdGhlIGJvb3QgcGFnZXMuDQoN
ClRoaXMgcGF0Y2ggY29sbGVjdHMgbWFjaGluZSBwYWdlIGZyYW1lcywgY3JlYXRlcyBmcmFtZSB0
YWJsZSB0byBhbGxvdyBhY2Nlc3MgdG8gdGhlIHhlbmhlYXAgYW5kIHRoZSBib290IHBhZ2VzLg0K
DQogeGVuL2FyY2gvYXJtL3hlbi9tbS5jICAgICAgICAgIHwgICA2NSArKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9zZXR1
cC5jICAgICAgIHwgIDExNSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vY29t
bW9uL3BhZ2VfYWxsb2MuYyAgICAgICAgfCAgICA1ICsrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0v
bW0uaCAgICAgICB8ICAgMjggKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNt
LWFybS9tbXUuaCAgICAgIHwgICAxMCArKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9wbGF0
Zm9ybS5oIHwgICA2MiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPg0K
DQpkaWZmIC1yIDRkNjFmMDJmZGUzNyB4ZW4vYXJjaC9hcm0veGVuL21tLmMNCi0tLSBhL3hlbi9h
cmNoL2FybS94ZW4vbW0uYwlGcmkgRmViIDAzIDE3OjQ3OjMyIDIwMTIgKzA5MDANCisrKyBiL3hl
bi9hcmNoL2FybS94ZW4vbW0uYwlNb24gRmViIDA2IDExOjE2OjM3IDIwMTIgKzA5MDANCkBAIC0x
OTIsMyArMTkyLDY4IEBAIGludCBwYWdlX2lzX3JhbV90eXBlKHVuc2lnbmVkIGxvbmcgbWZuLCAN
CiANCiAJcmV0dXJuIC1FSU5WQUw7DQogfQ0KKw0KKyNkZWZpbmUgUFRTX1BFUl9QQUdFICAgIDQN
CisNCisvKg0KKyAqIDQgcGFnZSB0YWJsZXMgcGVyIGEgcGFnZS4NCisgKi8NCitzdGF0aWMgaW5s
aW5lIHZvaWQgd2lyZV9wYWdlX3RhYmxlcyhsMWVfdCAqbDFlLCB1bnNpZ25lZCBsb25nIHRhYmxl
cykNCit7DQorCWwxZSA9IChsMWVfdCAqKSgodW5zaWduZWQgbG9uZylsMWUgJiB+KFBUU19QRVJf
UEFHRSAtIDEpKTsNCisNCisJKihsMWUgKyAwKSA9IE1LX0wxRSh0YWJsZXMgKyAwLCAgICBMMUVf
R1VFU1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAwKTsNCisJKihsMWUgKyAxKSA9IE1LX0wxRSh0
YWJsZXMgKyAxMDI0LCBMMUVfR1VFU1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAxKTsNCisJKihs
MWUgKyAyKSA9IE1LX0wxRSh0YWJsZXMgKyAyMDQ4LCBMMUVfR1VFU1RfVEFCTEUpOyBwdGVfc3lu
YyhsMWUgKyAyKTsNCisJKihsMWUgKyAzKSA9IE1LX0wxRSh0YWJsZXMgKyAzMDcyLCBMMUVfR1VF
U1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAzKTsNCit9DQorDQordW5zaWduZWQgbG9uZyBhbGxv
Y19wYWdlX3RhYmxlcyhsMWVfdCAqbDFlKQ0KK3sNCisJdW5zaWduZWQgbG9uZyBwYWdlOw0KKw0K
KwlwYWdlID0gYWxsb2NfY2xlYW5fcGFnZXMoMSk7DQorCWlmICghcGFnZSkgew0KKwkJcmV0dXJu
IDA7DQorCX0NCisNCisvLwljYWNoZV9jbGVhbl9yYW5nZShwYWdlLCBwYWdlICsgUEFHRV9TSVpF
LCAwKTsNCisNCisJd2lyZV9wYWdlX3RhYmxlcyhsMWUsIHBhZ2UpOw0KKw0KKwlyZXR1cm4gcGFn
ZTsNCit9DQorDQorDQoraW50IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcgdmlydCwgdW5z
aWduZWQgbG9uZyBwaHlzLCB1bnNpZ25lZCBpbnQgc2l6ZSwgdW5zaWduZWQgaW50IGZsYWdzKQ0K
K3sNCisJbDFlX3QgKmwxZTsNCisJdW5zaWduZWQgbG9uZyB2YWRkciA9IHJvdW5kX2Rvd24odmly
dCwgUEFHRV9TSVpFKTsNCisJdW5zaWduZWQgbG9uZyBsYXN0ID0gdmlydCArIHNpemU7DQorDQor
CWwxZSA9IGwxX2xpbmVhcl9vZmZzZXRfeGVuKHZhZGRyKTsNCisNCisJZG8gew0KKwkJbDJlX3Qg
KmwyZTsNCisJCXVuc2lnbmVkIGxvbmcgZW5kID0gKHZhZGRyICsgKFNFQ1RJT05fU0laRSAqIFBU
U19QRVJfUEFHRSkpICYgKFNFQ1RJT05fTUFTSyk7DQorCQllbmQgPSAoZW5kIDwgbGFzdCkgPyBl
bmQgOiBsYXN0Ow0KKw0KKwkJaWYgKCFsMWVfdmFsKCpsMWUpKSB7DQorCQkJaWYgKCFhbGxvY19w
YWdlX3RhYmxlcyhsMWUpKSB7DQorCQkJCXJldHVybiAtRU5PTUVNOw0KKwkJCX0NCisJCX0NCisN
CisJCWwyZSA9IGwyX2xpbmVhcl9vZmZzZXQobDFlLCB2YWRkcik7DQorCQlkbyB7DQorCQkJKmwy
ZSA9IE1LX0wyRShwaHlzLCBmbGFncyk7DQorCQkJcHRlX3N5bmMobDJlKTsNCisNCisJCQlwaHlz
ICs9IFBBR0VfU0laRTsNCisJCQl2YWRkciArPSBQQUdFX1NJWkU7DQorCQl9IHdoaWxlKGwyZSsr
LCB2YWRkciA8IGVuZCk7DQorCX0gd2hpbGUobDFlICs9IDQsIHZhZGRyIDwgbGFzdCk7DQorDQor
CXJldHVybiAwOw0KK30NCisNCmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9hcmNoL2FybS94ZW4v
c2V0dXAuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCUZyaSBGZWIgMDMgMTc6NDc6
MzIgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCU1vbiBGZWIgMDYg
MTE6MTY6MzcgMjAxMiArMDkwMA0KQEAgLTMxLDYgKzMxLDcgQEANCiAjaW5jbHVkZSA8cHVibGlj
L3ZlcnNpb24uaD4NCiAjaW5jbHVkZSA8cHVibGljL3NjaGVkLmg+DQogI2luY2x1ZGUgPGFzbS9t
bXUuaD4NCisjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+DQogDQogc3RydWN0IGRvbWFpbiBfZG9t
X3hlbiA9IHsNCiAJLnJlZmNudCA9IEFUT01JQ19JTklUKDEpLA0KQEAgLTc0LDYgKzc1LDExOCBA
QCB2b2lkIGFyY2hfZ2V0X3hlbl9jYXBzKHhlbl9jYXBhYmlsaXRpZXNfDQogew0KIH0NCiANCitz
dGF0aWMgdW5zaWduZWQgbG9uZyBsb29rdXBfeGVuX3BoeXNfc3RhcnQodm9pZCkNCit7DQorICAg
ICAgICBsMWVfdCAqbDFlOw0KKw0KKyAgICAgICAgbDFlID0gbDFfbGluZWFyX29mZnNldF94ZW4o
WEVOX1ZJUlRfU1RBUlQpOw0KKw0KKyAgICAgICAgcmV0dXJuIGwxZV92YWwoKmwxZSkgJiBTRUNU
SU9OX01BU0s7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBsb25nIGxvb2t1cF94ZW5fcGh5c19l
bmQodm9pZCkNCit7DQorCWwxZV90ICpsMWU7DQorDQorCWwxZSA9IGwxX2xpbmVhcl9vZmZzZXRf
eGVuKFhFTl9WSVJUX1NUQVJUKTsNCisNCisJd2hpbGUobDFlX3ZhbCgqKGwxZSArIDEpKSAhPSAw
KQ0KKwkJbDFlKys7DQorDQorCXJldHVybiAobDFlX3ZhbCgqbDFlKSAmIFNFQ1RJT05fTUFTSykg
KyBTRUNUSU9OX1NJWkU7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBpbnQgYm9vdF9wYWdlX2Nv
bGxlY3Rvcih1bnNpZ25lZCBsb25nIHN0YXJ0LCB1bnNpZ25lZCBsb25nIHNpemUpDQorew0KKwl1
bnNpZ25lZCBsb25nIGVuZCA9IHN0YXJ0ICsgc2l6ZTsNCisNCisJaW5pdF9ib290X3BhZ2VzKHN0
YXJ0LCBlbmQpOw0KKw0KKwlzdGFydCA9IHN0YXJ0ID4+IFBBR0VfU0hJRlQ7DQorCWVuZCAgID0g
ZW5kICAgPj4gUEFHRV9TSElGVDsNCisNCisJbWluX3BhZ2UgPSBtaW4oc3RhcnQsIG1pbl9wYWdl
KTsNCisJbWF4X3BhZ2UgPSBtYXgoZW5kLCBtYXhfcGFnZSk7DQorDQorCXJldHVybiBzaXplID4+
IFBBR0VfU0hJRlQ7DQorfQ0KKw0KKyNkZWZpbmUgRlJBTUVfVEFCTEVfQkFTRQkweEZDMDAwMDAw
VUwNCisNCisvKg0KKyAqIFRoZSB2aXJ0dWFsIGFkZHJlc3Mgb2YgdGhlIGZyYW1lIHRhYmxlIHNo
b3VsZCBiZSBhbGlnbmVkIHRvIDRNQiBib3VuZGFyeS4NCisgKi8NCitzdHJ1Y3QgcGFnZV9pbmZv
ICphbGxvY19mcmFtZV90YWJsZSh1bnNpZ25lZCBpbnQgc3opDQorew0KKwl1bnNpZ25lZCBsb25n
IHN0YXJ0Ow0KKw0KKwlzdGFydCA9IGFsbG9jX3BhZ2VzKHN6ID4+IFBBR0VfU0hJRlQpOw0KKwlp
ZiAoIXN0YXJ0KSB7DQorCQlyZXR1cm4gTlVMTDsNCisJfQ0KKw0KKwlpZihhbGxvY19wYWdlX21h
cChGUkFNRV9UQUJMRV9CQVNFLCBzdGFydCwgc3osIEwyRV9HVUVTVF9QQUdFKSA8IDApIHsNCisJ
CXJldHVybiBOVUxMOw0KKwl9DQorDQorCXJldHVybiAoc3RydWN0IHBhZ2VfaW5mbyAqKUZSQU1F
X1RBQkxFX0JBU0U7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGZyYW1lX3RhYmxlX3NldHVwKHVuc2ln
bmVkIGludCBucl9ib290X3BhZ2VzKQ0KK3sNCisJaW50IGk7DQorCXVuc2lnbmVkIGludCBzaXpl
Ow0KKw0KKyAgICAgICAgc2l6ZSA9IHJvdW5kX3VwKG5yX2Jvb3RfcGFnZXMgKiBzaXplb2Yoc3Ry
dWN0IHBhZ2VfaW5mbyksIFBBR0VfU0laRSk7DQorDQorCS8qIFRoZSBsb2NhdGlvbiBvZiB0aGUg
ZnJhbWVfdGFibGUgY291bGQgYmUgY2hhbmdlZCBpbiBuZWFyIGZ1dHVyZS4NCisJICogU28sIGRl
Y2lzaW9uIG1ha2luZyBvZiB0aGUgdmlydHVhbCBhZGRyZXNzIGlzIGFsd2F5cyBwZXJmb3JtZWQg
aW4gDQorCSAqIGFsbG9jX2ZyYW1lX3RhYmxlKCkNCisJICovDQorDQorCWZyYW1lX3RhYmxlID0g
YWxsb2NfZnJhbWVfdGFibGUoc2l6ZSk7DQorCWlmIChmcmFtZV90YWJsZSA9PSBOVUxMKSB7DQor
CQlwYW5pYygiTm9tZW1cbiIpOw0KKwl9DQorDQorICAgICAgICBtZW1zZXQoZnJhbWVfdGFibGUs
IDAsIHNpemUpOw0KK30NCisNCit1bnNpZ25lZCBpbnQgcHJlcGFyZV9wYWdlX2ZyYW1lcyh2b2lk
KQ0KK3sNCisJc3RydWN0IG1lbW9yeV9tYXAgKmVudDsNCisgICAgICAgIHVuc2lnbmVkIGxvbmcg
c3RhcnQsIGVuZDsNCisJdW5zaWduZWQgaW50IHBhZ2VzID0gMDsNCisNCisJLyogRm9yIHZpcnRf
dG9fbWFkZHIoKSBtYWNyby4gKi8NCisJeGVuX3BoeXNfc3RhcnQgPSBsb29rdXBfeGVuX3BoeXNf
c3RhcnQoKTsNCisJeGVuX3BoeXNfZW5kID0gbG9va3VwX3hlbl9waHlzX2VuZCgpOw0KKw0KKyAg
ICAgICAgLyogRm9yIHBvcHVsYXRpbmcgYm9vdG1lbV9yZWdpb25fbGlzdCAqLw0KKyAgICAgICAg
c3RhcnQgPSByb3VuZF9kb3duKHZpcnRfdG9fbWFkZHIoJl9lbmQpLCBQQUdFX1NJWkUpOw0KKyAg
ICAgICAgZW5kID0gc3RhcnQgKyBQQUdFX1NJWkU7DQorDQorICAgICAgICBpbml0X2Jvb3RfcGFn
ZXMoc3RhcnQsIGVuZCk7DQorDQorCS8qIEZvciBlYXJseSB4ZW5oZWFwIGFsbG9jYXRpb24gKi8N
CisgICAgICAgIHhlbmhlYXBfcGh5c19zdGFydCA9IGVuZDsNCisgICAgICAgIHhlbmhlYXBfcGh5
c19lbmQgPSB4ZW5fcGh5c19lbmQ7DQorDQorCWl0ZXJhdGVfbWVtb3J5X21hcChlbnQpIHsNCisJ
CWlmIChlbnQtPnR5cGUgPT0gTUVNT1JZX1RZUEVfUkFNKSB7DQorCQkJcGFnZXMgKz0gYm9vdF9w
YWdlX2NvbGxlY3RvcihlbnQtPmJhc2UsIGVudC0+c2l6ZSk7DQorCQl9DQorCX0NCisNCisJcmVz
ZXJ2ZV9ib290X3BhZ2VzKHhlbl9waHlzX3N0YXJ0LCB4ZW5fcGh5c19lbmQpOw0KKw0KKwlmcmFt
ZV90YWJsZV9zZXR1cChwYWdlcyk7DQorDQorICAgICAgICBpbml0X3hlbmhlYXBfcGFnZXMoeGVu
aGVhcF9waHlzX3N0YXJ0LCB4ZW5oZWFwX3BoeXNfZW5kKTsNCisNCisJcmV0dXJuIHBhZ2VzOw0K
K30NCisNCiBzdGF0aWMgdm9pZCBpZGxlX2RvbWFpbl9pbml0KHZvaWQpDQogew0KIAlzdHJ1Y3Qg
dmNwdSAqdjsNCkBAIC05Miw2ICsyMDUsOCBAQCBhc21saW5rYWdlIHZvaWQgc3RhcnRfeGVuKHZv
aWQpDQogDQogCXNtcF9wcmVwYXJlX2Jvb3RfY3B1KCk7DQogDQorCXByZXBhcmVfcGFnZV9mcmFt
ZXMoKTsNCisNCiAJc29mdGlycV9pbml0KCk7DQogDQogCXRhc2tsZXRfc3Vic3lzX2luaXQoKTsN
CmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9jb21tb24vcGFnZV9hbGxvYy5jDQotLS0gYS94ZW4v
Y29tbW9uL3BhZ2VfYWxsb2MuYwlGcmkgRmViIDAzIDE3OjQ3OjMyIDIwMTIgKzA5MDANCisrKyBi
L3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCU1vbiBGZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMA0K
QEAgLTE0Niw2ICsxNDYsMTEgQEAgc3RhdGljIHZvaWQgX19pbml0IGJvb3RtZW1fcmVnaW9uX3ph
cCh1bg0KICAgICB9DQogfQ0KIA0KK3ZvaWQgX19pbml0IHJlc2VydmVfYm9vdF9wYWdlcyhwYWRk
cl90IHBzLCBwYWRkcl90IHBlKQ0KK3sNCisgICAgICAgIGJvb3RtZW1fcmVnaW9uX3phcChwcyA+
PiBQQUdFX1NISUZULCBwZSA+PiBQQUdFX1NISUZUKTsNCit9DQorDQogdm9pZCBfX2luaXQgaW5p
dF9ib290X3BhZ2VzKHBhZGRyX3QgcHMsIHBhZGRyX3QgcGUpDQogew0KICAgICB1bnNpZ25lZCBs
b25nIGJhZF9zcGZuLCBiYWRfZXBmbjsNCmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9pbmNsdWRl
L2FzbS1hcm0vbW0uaA0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9tbS5oCUZyaSBGZWIgMDMg
MTc6NDc6MzIgMjAxMiArMDkwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9tbS5oCU1vbiBG
ZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMA0KQEAgLTEwOCw2ICsxMDgsMTMgQEANCiANCiAjZGVm
aW5lIHdyaXRlX3B0YmFzZSh2KQljcHVfc3dpdGNoX3R0YigodiktPmFyY2guY3R4LnR0YnIwKQ0K
IA0KKyNpZiAwDQorI3VuZGVmIHBhZ2VfbGlzdF9lbnRyeQ0KK3N0cnVjdCBwYWdlX2xpc3RfZW50
cnkNCit7DQorCXVuc2lnbmVkIGxvbmcgbmV4dCwgcHJldjsNCit9Ow0KKyNlbmRpZg0KIHN0cnVj
dCBwYWdlX2luZm8NCiB7DQogCXN0cnVjdCBwYWdlX2xpc3RfZW50cnkgbGlzdDsNCkBAIC0xODcs
NiArMTk0LDcgQEAgZXh0ZXJuIHVuc2lnbmVkIGxvbmcgbWluX3BhZ2UsIG1heF9wYWdlOw0KIGV4
dGVybiBzdHJ1Y3QgZG9tYWluICpkb21feGVuLCAqZG9tX2lvLCAqZG9tX2NvdzsNCiBleHRlcm4g
c3RydWN0IHBhZ2VfaW5mbyAqZnJhbWVfdGFibGU7DQogDQorZXh0ZXJuIGwxZV90ICp4ZW5fdHJh
bnNsYXRpb25fdGFibGU7DQogdm9pZCBtZW1ndWFyZF9ndWFyZF9zdGFjayh2b2lkICpwKTsNCiAN
CiB2b2lkIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwg
c3RydWN0IGRvbWFpbiAqZCwgaW50IHJlYWRvbmx5KTsNCkBAIC0yMTQsNiArMjIyLDExIEBAIGxv
bmcgYXJjaF9tZW1vcnlfb3AoaW50IG9wLCBYRU5fR1VFU1RfSEENCiANCiBpbnQgbWFwX3BhZ2Vz
X3RvX3hlbih1bnNpZ25lZCBsb25nIHZpcnQsIHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgbnIsIHVu
c2lnbmVkIGxvbmcgZmxhZ3MpOw0KIA0KK3Vuc2lnbmVkIGxvbmcgYWxsb2NfcGFnZV9tYXBfdGFi
bGVzKGwxZV90ICpsMWUpOw0KKw0KK2ludCBhbGxvY19wYWdlX21hcCh1bnNpZ25lZCBsb25nIHZp
cnQsIHVuc2lnbmVkIGxvbmcgcGh5cywgdW5zaWduZWQgaW50IHNpemUsIHVuc2lnbmVkIGludCBm
bGFncyk7DQorDQorDQogc3RhdGljIGlubGluZSB2b2lkIHB1dF9wYWdlX2FuZF90eXBlKHN0cnVj
dCBwYWdlX2luZm8gKnBhZ2UpDQogew0KIAlwdXRfcGFnZV90eXBlKHBhZ2UpOw0KQEAgLTIzNCw0
ICsyNDcsMTkgQEAgc3RhdGljIGlubGluZSBpbnQgZ2V0X3BhZ2VfYW5kX3R5cGUoc3RydQ0KIAly
ZXR1cm4gcmM7DQogfQ0KIA0KKy8qDQorICogVERCIDogUGFnZSBvd25lciBzZXR0aW5nLg0KKyAq
Lw0KKyNkZWZpbmUgYWxsb2NfcGFnZXMobnIpCVwNCisJKGFsbG9jX2Jvb3RfcGFnZXMobnIsIFBB
R0VfU0laRSkgPDwgUEFHRV9TSElGVCkNCisNCisjZGVmaW5lIGFsbG9jX2NsZWFuX3BhZ2VzKG5y
KQkJCQlcDQorKHsJCQkJCQkJXA0KKwl1bnNpZ25lZCBsb25nIHBhZ2U7CQkJCVwNCisJcGFnZSA9
IGFsbG9jX3BhZ2VzKG5yKTsJCQkJXA0KKwlpZiAocGFnZSkgewkJCQkJXA0KKwkJbWVtc2V0KHBh
Z2UsIDAsIG5yIDw8IFBBR0VfU0hJRlQpOwlcDQorCX0JCQkJCQlcDQorCXBhZ2U7CQkJCQkJXA0K
K30pDQogI2VuZGlmIC8qIF9fQVJNX01NX0hfXyAqLw0KZGlmZiAtciA0ZDYxZjAyZmRlMzcgeGVu
L2luY2x1ZGUvYXNtLWFybS9tbXUuaA0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaAlG
cmkgRmViIDAzIDE3OjQ3OjMyIDIwMTIgKzA5MDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0v
bW11LmgJTW9uIEZlYiAwNiAxMToxNjozNyAyMDEyICswOTAwDQpAQCAtMTQwLDYgKzE0MCwxNiBA
QA0KICNkZWZpbmUgbDFfbGluZWFyX29mZnNldF94ZW4odmEpCVwNCiAJKGwxX2xpbmVhcl9vZmZz
ZXQoKHhlbl90cmFuc2xhdGlvbl90YWJsZSksIHZhKSkNCiANCisjZGVmaW5lIHB0ZV9zeW5jKHB0
cikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQor
ZG8geyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KKyAgICAgICAgX19hc21fXyBfX3ZvbGF0aWxlX18oICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCisgICAgICAgICJtY3IgcDE1LCAw
LCAlMCwgYzcsIGMxMCwgMSBAIGNsZWFuIEQgZW50cnkgICAgIFxuIiAgICAgICAgICAgICBcDQor
ICAgICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KKyAgICAgICAgOiAiciIocHRyKSwgInIiKDApICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCisgICAgICAgIDogIm1lbW9yeSIp
OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQor
fXdoaWxlKDApDQorDQorDQogdHlwZWRlZiBzdHJ1Y3QgeyB1bnNpZ25lZCBsb25nIGwyZTsgfSBs
MmVfdDsNCiB0eXBlZGVmIHN0cnVjdCB7IHVuc2lnbmVkIGxvbmcgbDFlOyB9IGwxZV90Ow0KIA0K
ZGlmZiAtciA0ZDYxZjAyZmRlMzcgeGVuL2luY2x1ZGUvYXNtLWFybS9wbGF0Zm9ybS5oDQotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMA0KKysrIGIveGVuL2luY2x1
ZGUvYXNtLWFybS9wbGF0Zm9ybS5oCU1vbiBGZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMA0KQEAg
LTAsMCArMSw2MiBAQA0KKy8qDQorICogcGxhdGZvcm0uaA0KKyAqDQorICogQ29weXJpZ2h0IChD
KSAyMDA4IFNhbXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBKYWVNaW4gUnl1ICA8am03
Ny5yeXVAc2Ftc3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2Fy
ZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAqIGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFz
IHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uDQorICoNCisg
KiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJl
IHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBB
IFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVk
IGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UNCisgKiBhbG9uZyB3aXRo
IHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KKyAqIEZv
dW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAw
MjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisjaWZuZGVmIF9fQVJNX1BMQVRGT1JNX0hfXw0KKyNk
ZWZpbmUgX19BUk1fUExBVEZPUk1fSF9fDQorDQorI2luY2x1ZGUgPHhlbi9saXN0Lmg+DQorDQor
I2RlZmluZSBNRU1PUllfVFlQRV9SQU0JCSgwKQ0KKyNkZWZpbmUgTUVNT1JZX1RZUEVfUk9NCQko
MSkNCisjZGVmaW5lIE1FTU9SWV9UWVBFX0RFVgkJKDIpDQorI2RlZmluZSBNRU1PUllfVFlQRV9N
QVNLCSgweEYpDQorDQorI2lmZGVmIF9fQVNTRU1CTFlfXw0KKyNkZWZpbmUgREVDTEFSRV9QTEFU
Rk9STV9PUChnb3AsIG5vcCkJXA0KKyAgICAgICAgLnNldCBnb3AsIG5vcCAgICAgICAgICAgICAg
ICAgICA7XA0KKwkuZ2xvYmFsIGdvcCAgICAgICAgICAgICAgICAgICAgIDsNCisjZWxzZQ0KKyNk
ZWZpbmUgREVDTEFSRV9QTEFURk9STV9PUChnb3AsIG5vcCkJXA0KKyAgICAgICAgdHlwZW9mIChu
b3ApIGdvcCAgICAgICAgICAgICAgICBcDQorCV9fYXR0cmlidXRlX18oKHdlYWssIGFsaWFzKCNu
b3ApKSkNCisNCisNCisjZGVmaW5lIERFQ0xBUkVfTUVNT1JZX01BUChfbikgIFwNCitzdHJ1Y3Qg
bWVtb3J5X21hcCBfX2F0dHJpYnV0ZV9fICgoX19zZWN0aW9uX18oIi5pbml0Lm1lbXRhYmxlIikp
KSBfbiAjIyBfbWVtbWFwW10NCisNCisjZGVmaW5lIE1FTU1BUF9FTlRSWShiLCBzLCB0LCBmKSB7
YiwgcywgdCwgKGIgJiB+KDB4MTAwMDAwIC0gMSkpIHwgZn0NCisNCitzdHJ1Y3QgbWVtb3J5X21h
cCB7DQorCXVuc2lnbmVkIGxvbmcgYmFzZTsNCisJdW5zaWduZWQgaW50IHNpemU7DQorCXVuc2ln
bmVkIGludCB0eXBlOw0KKwl1bnNpZ25lZCBpbnQgZmxhZ3M7DQorfTsNCisNCisjZGVmaW5lIGl0
ZXJhdGVfbWVtb3J5X21hcChlbnRyeSkJXA0KKwlmb3IgKGVudHJ5ID0gJl9zbWVtdGFibGU7IGVu
dHJ5IDwgJl9lbWVtdGFibGU7IGVudHJ5KyspDQorCQ0KKyNkZWZpbmUgbWVtb3J5X21hcF90eXBl
KGVudHJ5KQkoZW50cnktPnR5cGUgJiBNRU1PUllfVFlQRV9NQVNLKQ0KKw0KK2V4dGVybiBzdHJ1
Y3QgbWVtb3J5X21hcCAqX3NtZW10YWJsZSwgKl9lbWVtdGFibGU7DQorDQorI2VuZGlmDQorI2Vu
ZGlmIC8qIF9fQVJNX1BMQVRGT1JNX0hfXyAqLw0KKw0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch06.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch06.diff"


CmFybTogYWxsb3cgYWNjZXNzIHRvIHRoZSB4ZW5oZWFwIGFuZCB0aGUgYm9vdCBwYWdlcy4K
ClRoaXMgcGF0Y2ggY29sbGVjdHMgbWFjaGluZSBwYWdlIGZyYW1lcywgY3JlYXRlcyBmcmFt
ZSB0YWJsZSB0byBhbGxvdyBhY2Nlc3MgdG8gdGhlIHhlbmhlYXAgYW5kIHRoZSBib290IHBh
Z2VzLgoKIHhlbi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICB8ICAgNjUgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogeGVuL2FyY2gvYXJt
L3hlbi9zZXR1cC5jICAgICAgIHwgIDExNSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysKIHhlbi9jb21tb24vcGFnZV9hbGxvYy5jICAgICAgICB8ICAgIDUgKysrCiB4ZW4v
aW5jbHVkZS9hc20tYXJtL21tLmggICAgICAgfCAgIDI4ICsrKysrKysrKysrKysrKysrKysr
KwogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCAgICAgIHwgICAxMCArKysrKysrCiB4ZW4v
aW5jbHVkZS9hc20tYXJtL3BsYXRmb3JtLmggfCAgIDYyICsrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUg
PGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciA0ZDYxZjAyZmRlMzcgeGVuL2FyY2gv
YXJtL3hlbi9tbS5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlGcmkgRmViIDAzIDE3
OjQ3OjMyIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9tbS5jCU1vbiBGZWIg
MDYgMTE6MTY6MzcgMjAxMiArMDkwMApAQCAtMTkyLDMgKzE5Miw2OCBAQCBpbnQgcGFnZV9p
c19yYW1fdHlwZSh1bnNpZ25lZCBsb25nIG1mbiwgCiAKIAlyZXR1cm4gLUVJTlZBTDsKIH0K
KworI2RlZmluZSBQVFNfUEVSX1BBR0UgICAgNAorCisvKgorICogNCBwYWdlIHRhYmxlcyBw
ZXIgYSBwYWdlLgorICovCitzdGF0aWMgaW5saW5lIHZvaWQgd2lyZV9wYWdlX3RhYmxlcyhs
MWVfdCAqbDFlLCB1bnNpZ25lZCBsb25nIHRhYmxlcykKK3sKKwlsMWUgPSAobDFlX3QgKiko
KHVuc2lnbmVkIGxvbmcpbDFlICYgfihQVFNfUEVSX1BBR0UgLSAxKSk7CisKKwkqKGwxZSAr
IDApID0gTUtfTDFFKHRhYmxlcyArIDAsICAgIEwxRV9HVUVTVF9UQUJMRSk7IHB0ZV9zeW5j
KGwxZSArIDApOworCSoobDFlICsgMSkgPSBNS19MMUUodGFibGVzICsgMTAyNCwgTDFFX0dV
RVNUX1RBQkxFKTsgcHRlX3N5bmMobDFlICsgMSk7CisJKihsMWUgKyAyKSA9IE1LX0wxRSh0
YWJsZXMgKyAyMDQ4LCBMMUVfR1VFU1RfVEFCTEUpOyBwdGVfc3luYyhsMWUgKyAyKTsKKwkq
KGwxZSArIDMpID0gTUtfTDFFKHRhYmxlcyArIDMwNzIsIEwxRV9HVUVTVF9UQUJMRSk7IHB0
ZV9zeW5jKGwxZSArIDMpOworfQorCit1bnNpZ25lZCBsb25nIGFsbG9jX3BhZ2VfdGFibGVz
KGwxZV90ICpsMWUpCit7CisJdW5zaWduZWQgbG9uZyBwYWdlOworCisJcGFnZSA9IGFsbG9j
X2NsZWFuX3BhZ2VzKDEpOworCWlmICghcGFnZSkgeworCQlyZXR1cm4gMDsKKwl9CisKKy8v
CWNhY2hlX2NsZWFuX3JhbmdlKHBhZ2UsIHBhZ2UgKyBQQUdFX1NJWkUsIDApOworCisJd2ly
ZV9wYWdlX3RhYmxlcyhsMWUsIHBhZ2UpOworCisJcmV0dXJuIHBhZ2U7Cit9CisKKworaW50
IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcgdmlydCwgdW5zaWduZWQgbG9uZyBwaHlz
LCB1bnNpZ25lZCBpbnQgc2l6ZSwgdW5zaWduZWQgaW50IGZsYWdzKQoreworCWwxZV90ICps
MWU7CisJdW5zaWduZWQgbG9uZyB2YWRkciA9IHJvdW5kX2Rvd24odmlydCwgUEFHRV9TSVpF
KTsKKwl1bnNpZ25lZCBsb25nIGxhc3QgPSB2aXJ0ICsgc2l6ZTsKKworCWwxZSA9IGwxX2xp
bmVhcl9vZmZzZXRfeGVuKHZhZGRyKTsKKworCWRvIHsKKwkJbDJlX3QgKmwyZTsKKwkJdW5z
aWduZWQgbG9uZyBlbmQgPSAodmFkZHIgKyAoU0VDVElPTl9TSVpFICogUFRTX1BFUl9QQUdF
KSkgJiAoU0VDVElPTl9NQVNLKTsKKwkJZW5kID0gKGVuZCA8IGxhc3QpID8gZW5kIDogbGFz
dDsKKworCQlpZiAoIWwxZV92YWwoKmwxZSkpIHsKKwkJCWlmICghYWxsb2NfcGFnZV90YWJs
ZXMobDFlKSkgeworCQkJCXJldHVybiAtRU5PTUVNOworCQkJfQorCQl9CisKKwkJbDJlID0g
bDJfbGluZWFyX29mZnNldChsMWUsIHZhZGRyKTsKKwkJZG8geworCQkJKmwyZSA9IE1LX0wy
RShwaHlzLCBmbGFncyk7CisJCQlwdGVfc3luYyhsMmUpOworCisJCQlwaHlzICs9IFBBR0Vf
U0laRTsKKwkJCXZhZGRyICs9IFBBR0VfU0laRTsKKwkJfSB3aGlsZShsMmUrKywgdmFkZHIg
PCBlbmQpOworCX0gd2hpbGUobDFlICs9IDQsIHZhZGRyIDwgbGFzdCk7CisKKwlyZXR1cm4g
MDsKK30KKwpkaWZmIC1yIDRkNjFmMDJmZGUzNyB4ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMK
LS0tIGEveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCUZyaSBGZWIgMDMgMTc6NDc6MzIgMjAx
MiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3NldHVwLmMJTW9uIEZlYiAwNiAxMTox
NjozNyAyMDEyICswOTAwCkBAIC0zMSw2ICszMSw3IEBACiAjaW5jbHVkZSA8cHVibGljL3Zl
cnNpb24uaD4KICNpbmNsdWRlIDxwdWJsaWMvc2NoZWQuaD4KICNpbmNsdWRlIDxhc20vbW11
Lmg+CisjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+CiAKIHN0cnVjdCBkb21haW4gX2RvbV94
ZW4gPSB7CiAJLnJlZmNudCA9IEFUT01JQ19JTklUKDEpLApAQCAtNzQsNiArNzUsMTE4IEBA
IHZvaWQgYXJjaF9nZXRfeGVuX2NhcHMoeGVuX2NhcGFiaWxpdGllc18KIHsKIH0KIAorc3Rh
dGljIHVuc2lnbmVkIGxvbmcgbG9va3VwX3hlbl9waHlzX3N0YXJ0KHZvaWQpCit7CisgICAg
ICAgIGwxZV90ICpsMWU7CisKKyAgICAgICAgbDFlID0gbDFfbGluZWFyX29mZnNldF94ZW4o
WEVOX1ZJUlRfU1RBUlQpOworCisgICAgICAgIHJldHVybiBsMWVfdmFsKCpsMWUpICYgU0VD
VElPTl9NQVNLOworfQorCitzdGF0aWMgdW5zaWduZWQgbG9uZyBsb29rdXBfeGVuX3BoeXNf
ZW5kKHZvaWQpCit7CisJbDFlX3QgKmwxZTsKKworCWwxZSA9IGwxX2xpbmVhcl9vZmZzZXRf
eGVuKFhFTl9WSVJUX1NUQVJUKTsKKworCXdoaWxlKGwxZV92YWwoKihsMWUgKyAxKSkgIT0g
MCkKKwkJbDFlKys7CisKKwlyZXR1cm4gKGwxZV92YWwoKmwxZSkgJiBTRUNUSU9OX01BU0sp
ICsgU0VDVElPTl9TSVpFOworfQorCitzdGF0aWMgdW5zaWduZWQgaW50IGJvb3RfcGFnZV9j
b2xsZWN0b3IodW5zaWduZWQgbG9uZyBzdGFydCwgdW5zaWduZWQgbG9uZyBzaXplKQorewor
CXVuc2lnbmVkIGxvbmcgZW5kID0gc3RhcnQgKyBzaXplOworCisJaW5pdF9ib290X3BhZ2Vz
KHN0YXJ0LCBlbmQpOworCisJc3RhcnQgPSBzdGFydCA+PiBQQUdFX1NISUZUOworCWVuZCAg
ID0gZW5kICAgPj4gUEFHRV9TSElGVDsKKworCW1pbl9wYWdlID0gbWluKHN0YXJ0LCBtaW5f
cGFnZSk7CisJbWF4X3BhZ2UgPSBtYXgoZW5kLCBtYXhfcGFnZSk7CisKKwlyZXR1cm4gc2l6
ZSA+PiBQQUdFX1NISUZUOworfQorCisjZGVmaW5lIEZSQU1FX1RBQkxFX0JBU0UJMHhGQzAw
MDAwMFVMCisKKy8qCisgKiBUaGUgdmlydHVhbCBhZGRyZXNzIG9mIHRoZSBmcmFtZSB0YWJs
ZSBzaG91bGQgYmUgYWxpZ25lZCB0byA0TUIgYm91bmRhcnkuCisgKi8KK3N0cnVjdCBwYWdl
X2luZm8gKmFsbG9jX2ZyYW1lX3RhYmxlKHVuc2lnbmVkIGludCBzeikKK3sKKwl1bnNpZ25l
ZCBsb25nIHN0YXJ0OworCisJc3RhcnQgPSBhbGxvY19wYWdlcyhzeiA+PiBQQUdFX1NISUZU
KTsKKwlpZiAoIXN0YXJ0KSB7CisJCXJldHVybiBOVUxMOworCX0KKworCWlmKGFsbG9jX3Bh
Z2VfbWFwKEZSQU1FX1RBQkxFX0JBU0UsIHN0YXJ0LCBzeiwgTDJFX0dVRVNUX1BBR0UpIDwg
MCkgeworCQlyZXR1cm4gTlVMTDsKKwl9CisKKwlyZXR1cm4gKHN0cnVjdCBwYWdlX2luZm8g
KilGUkFNRV9UQUJMRV9CQVNFOworfQorCitzdGF0aWMgdm9pZCBmcmFtZV90YWJsZV9zZXR1
cCh1bnNpZ25lZCBpbnQgbnJfYm9vdF9wYWdlcykKK3sKKwlpbnQgaTsKKwl1bnNpZ25lZCBp
bnQgc2l6ZTsKKworICAgICAgICBzaXplID0gcm91bmRfdXAobnJfYm9vdF9wYWdlcyAqIHNp
emVvZihzdHJ1Y3QgcGFnZV9pbmZvKSwgUEFHRV9TSVpFKTsKKworCS8qIFRoZSBsb2NhdGlv
biBvZiB0aGUgZnJhbWVfdGFibGUgY291bGQgYmUgY2hhbmdlZCBpbiBuZWFyIGZ1dHVyZS4K
KwkgKiBTbywgZGVjaXNpb24gbWFraW5nIG9mIHRoZSB2aXJ0dWFsIGFkZHJlc3MgaXMgYWx3
YXlzIHBlcmZvcm1lZCBpbiAKKwkgKiBhbGxvY19mcmFtZV90YWJsZSgpCisJICovCisKKwlm
cmFtZV90YWJsZSA9IGFsbG9jX2ZyYW1lX3RhYmxlKHNpemUpOworCWlmIChmcmFtZV90YWJs
ZSA9PSBOVUxMKSB7CisJCXBhbmljKCJOb21lbVxuIik7CisJfQorCisgICAgICAgIG1lbXNl
dChmcmFtZV90YWJsZSwgMCwgc2l6ZSk7Cit9CisKK3Vuc2lnbmVkIGludCBwcmVwYXJlX3Bh
Z2VfZnJhbWVzKHZvaWQpCit7CisJc3RydWN0IG1lbW9yeV9tYXAgKmVudDsKKyAgICAgICAg
dW5zaWduZWQgbG9uZyBzdGFydCwgZW5kOworCXVuc2lnbmVkIGludCBwYWdlcyA9IDA7CisK
KwkvKiBGb3IgdmlydF90b19tYWRkcigpIG1hY3JvLiAqLworCXhlbl9waHlzX3N0YXJ0ID0g
bG9va3VwX3hlbl9waHlzX3N0YXJ0KCk7CisJeGVuX3BoeXNfZW5kID0gbG9va3VwX3hlbl9w
aHlzX2VuZCgpOworCisgICAgICAgIC8qIEZvciBwb3B1bGF0aW5nIGJvb3RtZW1fcmVnaW9u
X2xpc3QgKi8KKyAgICAgICAgc3RhcnQgPSByb3VuZF9kb3duKHZpcnRfdG9fbWFkZHIoJl9l
bmQpLCBQQUdFX1NJWkUpOworICAgICAgICBlbmQgPSBzdGFydCArIFBBR0VfU0laRTsKKwor
ICAgICAgICBpbml0X2Jvb3RfcGFnZXMoc3RhcnQsIGVuZCk7CisKKwkvKiBGb3IgZWFybHkg
eGVuaGVhcCBhbGxvY2F0aW9uICovCisgICAgICAgIHhlbmhlYXBfcGh5c19zdGFydCA9IGVu
ZDsKKyAgICAgICAgeGVuaGVhcF9waHlzX2VuZCA9IHhlbl9waHlzX2VuZDsKKworCWl0ZXJh
dGVfbWVtb3J5X21hcChlbnQpIHsKKwkJaWYgKGVudC0+dHlwZSA9PSBNRU1PUllfVFlQRV9S
QU0pIHsKKwkJCXBhZ2VzICs9IGJvb3RfcGFnZV9jb2xsZWN0b3IoZW50LT5iYXNlLCBlbnQt
PnNpemUpOworCQl9CisJfQorCisJcmVzZXJ2ZV9ib290X3BhZ2VzKHhlbl9waHlzX3N0YXJ0
LCB4ZW5fcGh5c19lbmQpOworCisJZnJhbWVfdGFibGVfc2V0dXAocGFnZXMpOworCisgICAg
ICAgIGluaXRfeGVuaGVhcF9wYWdlcyh4ZW5oZWFwX3BoeXNfc3RhcnQsIHhlbmhlYXBfcGh5
c19lbmQpOworCisJcmV0dXJuIHBhZ2VzOworfQorCiBzdGF0aWMgdm9pZCBpZGxlX2RvbWFp
bl9pbml0KHZvaWQpCiB7CiAJc3RydWN0IHZjcHUgKnY7CkBAIC05Miw2ICsyMDUsOCBAQCBh
c21saW5rYWdlIHZvaWQgc3RhcnRfeGVuKHZvaWQpCiAKIAlzbXBfcHJlcGFyZV9ib290X2Nw
dSgpOwogCisJcHJlcGFyZV9wYWdlX2ZyYW1lcygpOworCiAJc29mdGlycV9pbml0KCk7CiAK
IAl0YXNrbGV0X3N1YnN5c19pbml0KCk7CmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9jb21t
b24vcGFnZV9hbGxvYy5jCi0tLSBhL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCUZyaSBGZWIg
MDMgMTc6NDc6MzIgMjAxMiArMDkwMAorKysgYi94ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYwlN
b24gRmViIDA2IDExOjE2OjM3IDIwMTIgKzA5MDAKQEAgLTE0Niw2ICsxNDYsMTEgQEAgc3Rh
dGljIHZvaWQgX19pbml0IGJvb3RtZW1fcmVnaW9uX3phcCh1bgogICAgIH0KIH0KIAordm9p
ZCBfX2luaXQgcmVzZXJ2ZV9ib290X3BhZ2VzKHBhZGRyX3QgcHMsIHBhZGRyX3QgcGUpCit7
CisgICAgICAgIGJvb3RtZW1fcmVnaW9uX3phcChwcyA+PiBQQUdFX1NISUZULCBwZSA+PiBQ
QUdFX1NISUZUKTsKK30KKwogdm9pZCBfX2luaXQgaW5pdF9ib290X3BhZ2VzKHBhZGRyX3Qg
cHMsIHBhZGRyX3QgcGUpCiB7CiAgICAgdW5zaWduZWQgbG9uZyBiYWRfc3BmbiwgYmFkX2Vw
Zm47CmRpZmYgLXIgNGQ2MWYwMmZkZTM3IHhlbi9pbmNsdWRlL2FzbS1hcm0vbW0uaAotLS0g
YS94ZW4vaW5jbHVkZS9hc20tYXJtL21tLmgJRnJpIEZlYiAwMyAxNzo0NzozMiAyMDEyICsw
OTAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW0uaAlNb24gRmViIDA2IDExOjE2OjM3
IDIwMTIgKzA5MDAKQEAgLTEwOCw2ICsxMDgsMTMgQEAKIAogI2RlZmluZSB3cml0ZV9wdGJh
c2UodikJY3B1X3N3aXRjaF90dGIoKHYpLT5hcmNoLmN0eC50dGJyMCkKIAorI2lmIDAKKyN1
bmRlZiBwYWdlX2xpc3RfZW50cnkKK3N0cnVjdCBwYWdlX2xpc3RfZW50cnkKK3sKKwl1bnNp
Z25lZCBsb25nIG5leHQsIHByZXY7Cit9OworI2VuZGlmCiBzdHJ1Y3QgcGFnZV9pbmZvCiB7
CiAJc3RydWN0IHBhZ2VfbGlzdF9lbnRyeSBsaXN0OwpAQCAtMTg3LDYgKzE5NCw3IEBAIGV4
dGVybiB1bnNpZ25lZCBsb25nIG1pbl9wYWdlLCBtYXhfcGFnZTsKIGV4dGVybiBzdHJ1Y3Qg
ZG9tYWluICpkb21feGVuLCAqZG9tX2lvLCAqZG9tX2NvdzsKIGV4dGVybiBzdHJ1Y3QgcGFn
ZV9pbmZvICpmcmFtZV90YWJsZTsKIAorZXh0ZXJuIGwxZV90ICp4ZW5fdHJhbnNsYXRpb25f
dGFibGU7CiB2b2lkIG1lbWd1YXJkX2d1YXJkX3N0YWNrKHZvaWQgKnApOwogCiB2b2lkIHNo
YXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgc3RydWN0
IGRvbWFpbiAqZCwgaW50IHJlYWRvbmx5KTsKQEAgLTIxNCw2ICsyMjIsMTEgQEAgbG9uZyBh
cmNoX21lbW9yeV9vcChpbnQgb3AsIFhFTl9HVUVTVF9IQQogCiBpbnQgbWFwX3BhZ2VzX3Rv
X3hlbih1bnNpZ25lZCBsb25nIHZpcnQsIHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgbnIsIHVu
c2lnbmVkIGxvbmcgZmxhZ3MpOwogCit1bnNpZ25lZCBsb25nIGFsbG9jX3BhZ2VfbWFwX3Rh
YmxlcyhsMWVfdCAqbDFlKTsKKworaW50IGFsbG9jX3BhZ2VfbWFwKHVuc2lnbmVkIGxvbmcg
dmlydCwgdW5zaWduZWQgbG9uZyBwaHlzLCB1bnNpZ25lZCBpbnQgc2l6ZSwgdW5zaWduZWQg
aW50IGZsYWdzKTsKKworCiBzdGF0aWMgaW5saW5lIHZvaWQgcHV0X3BhZ2VfYW5kX3R5cGUo
c3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkKIHsKIAlwdXRfcGFnZV90eXBlKHBhZ2UpOwpAQCAt
MjM0LDQgKzI0NywxOSBAQCBzdGF0aWMgaW5saW5lIGludCBnZXRfcGFnZV9hbmRfdHlwZShz
dHJ1CiAJcmV0dXJuIHJjOwogfQogCisvKgorICogVERCIDogUGFnZSBvd25lciBzZXR0aW5n
LgorICovCisjZGVmaW5lIGFsbG9jX3BhZ2VzKG5yKQlcCisJKGFsbG9jX2Jvb3RfcGFnZXMo
bnIsIFBBR0VfU0laRSkgPDwgUEFHRV9TSElGVCkKKworI2RlZmluZSBhbGxvY19jbGVhbl9w
YWdlcyhucikJCQkJXAorKHsJCQkJCQkJXAorCXVuc2lnbmVkIGxvbmcgcGFnZTsJCQkJXAor
CXBhZ2UgPSBhbGxvY19wYWdlcyhucik7CQkJCVwKKwlpZiAocGFnZSkgewkJCQkJXAorCQlt
ZW1zZXQocGFnZSwgMCwgbnIgPDwgUEFHRV9TSElGVCk7CVwKKwl9CQkJCQkJXAorCXBhZ2U7
CQkJCQkJXAorfSkKICNlbmRpZiAvKiBfX0FSTV9NTV9IX18gKi8KZGlmZiAtciA0ZDYxZjAy
ZmRlMzcgeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20t
YXJtL21tdS5oCUZyaSBGZWIgMDMgMTc6NDc6MzIgMjAxMiArMDkwMAorKysgYi94ZW4vaW5j
bHVkZS9hc20tYXJtL21tdS5oCU1vbiBGZWIgMDYgMTE6MTY6MzcgMjAxMiArMDkwMApAQCAt
MTQwLDYgKzE0MCwxNiBAQAogI2RlZmluZSBsMV9saW5lYXJfb2Zmc2V0X3hlbih2YSkJXAog
CShsMV9saW5lYXJfb2Zmc2V0KCh4ZW5fdHJhbnNsYXRpb25fdGFibGUpLCB2YSkpCiAKKyNk
ZWZpbmUgcHRlX3N5bmMocHRyKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKK2RvIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgX19hc21f
XyBfX3ZvbGF0aWxlX18oICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgIm1jciBwMTUsIDAsICUwLCBjNywgYzEwLCAxIEAgY2xlYW4gRCBl
bnRyeSAgICAgXG4iICAgICAgICAgICAgIFwKKyAgICAgICAgOiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgOiAiciIocHRyKSwgInIiKDApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFwKKyAgICAgICAgOiAibWVtb3J5Iik7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKK313aGlsZSgwKQorCisKIHR5
cGVkZWYgc3RydWN0IHsgdW5zaWduZWQgbG9uZyBsMmU7IH0gbDJlX3Q7CiB0eXBlZGVmIHN0
cnVjdCB7IHVuc2lnbmVkIGxvbmcgbDFlOyB9IGwxZV90OwogCmRpZmYgLXIgNGQ2MWYwMmZk
ZTM3IHhlbi9pbmNsdWRlL2FzbS1hcm0vcGxhdGZvcm0uaAotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3Bs
YXRmb3JtLmgJTW9uIEZlYiAwNiAxMToxNjozNyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjIg
QEAKKy8qCisgKiBwbGF0Zm9ybS5oCisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4IFNhbXN1
bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAgIEphZU1pbiBSeXUgIDxqbTc3LnJ5dUBzYW1z
dW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVi
bGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRo
aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUg
dXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJl
Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFs
b25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3
YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwg
Qm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2lmbmRlZiBfX0FSTV9QTEFU
Rk9STV9IX18KKyNkZWZpbmUgX19BUk1fUExBVEZPUk1fSF9fCisKKyNpbmNsdWRlIDx4ZW4v
bGlzdC5oPgorCisjZGVmaW5lIE1FTU9SWV9UWVBFX1JBTQkJKDApCisjZGVmaW5lIE1FTU9S
WV9UWVBFX1JPTQkJKDEpCisjZGVmaW5lIE1FTU9SWV9UWVBFX0RFVgkJKDIpCisjZGVmaW5l
IE1FTU9SWV9UWVBFX01BU0sJKDB4RikKKworI2lmZGVmIF9fQVNTRU1CTFlfXworI2RlZmlu
ZSBERUNMQVJFX1BMQVRGT1JNX09QKGdvcCwgbm9wKQlcCisgICAgICAgIC5zZXQgZ29wLCBu
b3AgICAgICAgICAgICAgICAgICAgO1wKKwkuZ2xvYmFsIGdvcCAgICAgICAgICAgICAgICAg
ICAgIDsKKyNlbHNlCisjZGVmaW5lIERFQ0xBUkVfUExBVEZPUk1fT1AoZ29wLCBub3ApCVwK
KyAgICAgICAgdHlwZW9mIChub3ApIGdvcCAgICAgICAgICAgICAgICBcCisJX19hdHRyaWJ1
dGVfXygod2VhaywgYWxpYXMoI25vcCkpKQorCisKKyNkZWZpbmUgREVDTEFSRV9NRU1PUllf
TUFQKF9uKSAgXAorc3RydWN0IG1lbW9yeV9tYXAgX19hdHRyaWJ1dGVfXyAoKF9fc2VjdGlv
bl9fKCIuaW5pdC5tZW10YWJsZSIpKSkgX24gIyMgX21lbW1hcFtdCisKKyNkZWZpbmUgTUVN
TUFQX0VOVFJZKGIsIHMsIHQsIGYpIHtiLCBzLCB0LCAoYiAmIH4oMHgxMDAwMDAgLSAxKSkg
fCBmfQorCitzdHJ1Y3QgbWVtb3J5X21hcCB7CisJdW5zaWduZWQgbG9uZyBiYXNlOworCXVu
c2lnbmVkIGludCBzaXplOworCXVuc2lnbmVkIGludCB0eXBlOworCXVuc2lnbmVkIGludCBm
bGFnczsKK307CisKKyNkZWZpbmUgaXRlcmF0ZV9tZW1vcnlfbWFwKGVudHJ5KQlcCisJZm9y
IChlbnRyeSA9ICZfc21lbXRhYmxlOyBlbnRyeSA8ICZfZW1lbXRhYmxlOyBlbnRyeSsrKQor
CQorI2RlZmluZSBtZW1vcnlfbWFwX3R5cGUoZW50cnkpCShlbnRyeS0+dHlwZSAmIE1FTU9S
WV9UWVBFX01BU0spCisKK2V4dGVybiBzdHJ1Y3QgbWVtb3J5X21hcCAqX3NtZW10YWJsZSwg
Kl9lbWVtdGFibGU7CisKKyNlbmRpZgorI2VuZGlmIC8qIF9fQVJNX1BMQVRGT1JNX0hfXyAq
LworCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt18-0005zu-TR; Mon, 13 Feb 2012 10:20:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqtz-00040j-JG
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:04:47 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329120278!4726411!2
X-Originating-IP: [203.254.224.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzQgPT4gMjQwMTQ5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1302 invoked from network); 13 Feb 2012 08:04:40 -0000
Received: from mailout4.samsung.com (HELO mailout4.samsung.com)
	(203.254.224.34) by server-16.tower-21.messagelabs.com with SMTP;
	13 Feb 2012 08:04:40 -0000
Received: from epcpsbge7.samsung.com (mailout4.samsung.com [203.254.224.34])
	by mailout4.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00LX7NQYOHB0@mailout4.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:04:38 +0900 (KST)
Message-id: <0LZB00LYMNRQOHB0@mailout4.samsung.com>
X-AuditID: cbfee611-b7b12ae0000036c1-a7-4f38c3d1fafa
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge7.samsung.com (EPCPMTA) with SMTP id 64.FF.14017.1D3C83F4;
	Mon, 13 Feb 2012 17:03:29 +0900 (KST)
Date: Mon, 13 Feb 2012 08:04:38 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080356110@jm77.ryu
Msgkey: 20120213080356110@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080232243@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 12/14]  arm: implement get/put page functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <25214000.70331329120274085.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgZ2V0L3B1dCBwYWdlIGZ1bmN0aW9ucw0KDQogeGVuL2FyY2gvYXJtL3hl
bi9tbS5jIHwgIDYxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0NCiAxIGZpbGVzIGNoYW5nZWQsIDU1IGluc2VydGlvbnMoKyksIDYg
ZGVsZXRpb25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1
bmcuY29tPg0KDQpkaWZmIC1yIGMzZTczMzNlZWZjMyB4ZW4vYXJjaC9hcm0veGVuL21tLmMNCi0t
LSBhL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlTdW4gRmViIDEyIDE1OjA0OjI0IDIwMTIgKzA5MDAN
CisrKyBiL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlTdW4gRmViIDEyIDE1OjEzOjA5IDIwMTIgKzA5
MDANCkBAIC03MywyOSArNzMsNzggQEAgdm9pZCBtZW1ndWFyZF91bmd1YXJkX3JhbmdlKHZvaWQg
KnAsIHVucw0KIA0KIHZvaWQgcHV0X3BhZ2Uoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSkNCiB7DQot
CU5PVF9ZRVQoKTsNCisgICAgICAgIHUzMiBueCwgeCwgeSA9IHBhZ2UtPmNvdW50X2luZm87DQor
DQorICAgICAgICBkbyB7DQorICAgICAgICAgICAgICAgIHggID0geTsNCisgICAgICAgICAgICAg
ICAgbnggPSB4IC0gMTsNCisgICAgICAgIH0gd2hpbGUgKCB1bmxpa2VseSgoeSA9IGNtcHhjaGco
JnBhZ2UtPmNvdW50X2luZm8sIHgsIG54KSkgIT0geCkgKTsNCisNCisgICAgICAgIGlmICggdW5s
aWtlbHkoKG54ICYgUEdDX2NvdW50X21hc2spID09IDApICkgew0KKyAgICAgICAgICAgICAgICBm
cmVlX2RvbWhlYXBfcGFnZShwYWdlKTsNCisgICAgICAgIH0NCisNCiB9DQogDQogc3RydWN0IGRv
bWFpbiAqcGFnZV9nZXRfb3duZXJfYW5kX3JlZmVyZW5jZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdl
KQ0KIHsNCi0JTk9UX1lFVCgpOw0KKyAgICAgICAgdW5zaWduZWQgbG9uZyB4LCB5ID0gcGFnZS0+
Y291bnRfaW5mbzsNCisNCisgICAgICAgIGRvIHsNCisgICAgICAgICAgICAgICAgeCA9IHk7DQor
ICAgICAgICAgICAgICAgIGlmKHVubGlrZWx5KCgoeCArIDIpICYgUEdDX2NvdW50X21hc2spIDw9
IDIpICkNCisgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsNCisgICAgICAgIH0g
d2hpbGUoKHkgPSBjbXB4Y2hnKCZwYWdlLT5jb3VudF9pbmZvLHgseCsxKSkgIT0geCk7DQorDQor
ICAgICAgICByZXR1cm4gcGFnZV9nZXRfb3duZXIocGFnZSk7DQorDQogfQ0KIA0KIGludCBnZXRf
cGFnZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCBzdHJ1Y3QgZG9tYWluICpkb21haW4pDQogew0K
LQlOT1RfWUVUKCk7DQorICAgICAgICBzdHJ1Y3QgZG9tYWluICpvd25lciA9IHBhZ2VfZ2V0X293
bmVyX2FuZF9yZWZlcmVuY2UocGFnZSk7DQogDQotCXJldHVybiAwOw0KKyAgICAgICAgaWYgKGxp
a2VseShvd25lciA9PSBkb21haW4pKQ0KKyAgICAgICAgICAgICAgICByZXR1cm4gMTsNCisNCisg
ICAgICAgIGlmIChvd25lciAhPSBkb21haW4pDQorICAgICAgICAgICAgICAgIHB1dF9wYWdlKHBh
Z2UpOw0KKw0KKyAgICAgICAgcmV0dXJuIDA7DQogfQ0KIA0KIHZvaWQgc2hhcmVfeGVuX3BhZ2Vf
d2l0aF9ndWVzdChzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCBzdHJ1Y3QgZG9tYWluICpkLCBpbnQg
cmVhZG9ubHkpDQogew0KLQlOT1RfWUVUKCk7DQorICAgICAgICBpZihwYWdlX2dldF9vd25lcihw
YWdlKSA9PSBkKQ0KKyAgICAgICAgICAgICAgICByZXR1cm47DQorDQorICAgICAgICBzZXRfZ3Bm
bl9mcm9tX21mbihwYWdlX3RvX21mbihwYWdlKSwgSU5WQUxJRF9NMlBfRU5UUlkpOw0KKw0KKyAg
ICAgICAgc3Bpbl9sb2NrKCZkLT5wYWdlX2FsbG9jX2xvY2spOw0KKw0KKyAgICAgICAgLyogVGhl
IGluY3JlbWVudGVkIHR5cGUgY291bnQgcGlucyBhcyB3cml0YWJsZSBvciByZWFkLW9ubHkuICov
DQorICAgICAgICBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAgPSAocmVhZG9ubHkgPyBQR1Rfbm9u
ZSA6IFBHVF93cml0YWJsZV9wYWdlKTsNCisgICAgICAgIHBhZ2UtPnUuaW51c2UudHlwZV9pbmZv
IHw9IFBHVF92YWxpZGF0ZWQgfCAxOw0KKw0KKyAgICAgICAgcGFnZV9zZXRfb3duZXIocGFnZSwg
ZCk7DQorICAgICAgICB3bWIoKTsgLyogaW5zdGFsbCB2YWxpZCBkb21haW4gcHRyIGJlZm9yZSB1
cGRhdGluZyByZWZjbnQuICovDQorICAgICAgICBBU1NFUlQoKHBhZ2UtPmNvdW50X2luZm8gJiB+
UEdDX3hlbl9oZWFwKSA9PSAwKTsNCisNCisgICAgICAgIGlmICghZC0+aXNfZHlpbmcpIHsNCisg
ICAgICAgICAgICAgICAgcGFnZS0+Y291bnRfaW5mbyB8PSBQR0NfYWxsb2NhdGVkIHwgMTsNCisN
CisgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2VseShkLT54ZW5oZWFwX3BhZ2VzKysgPT0gMCkg
KQ0KKyAgICAgICAgICAgICAgICAgICAgICAgIGdldF9rbm93bmFsaXZlX2RvbWFpbihkKTsNCisN
CisgICAgICAgICAgICAgICAgcGFnZV9saXN0X2FkZF90YWlsKHBhZ2UsICZkLT54ZW5wYWdlX2xp
c3QpOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgc3Bpbl91bmxvY2soJmQtPnBhZ2VfYWxsb2Nf
bG9jayk7DQogfQ0KIA0KIHZvaWQgc2hhcmVfeGVuX3BhZ2Vfd2l0aF9wcml2aWxlZ2VkX2d1ZXN0
cyhzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCBpbnQgcmVhZG9ubHkpDQogew0KLQlOT1RfWUVUKCk7
DQorICAgICAgICBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KHBhZ2UsIGRvbV94ZW4sIHJlYWRv
bmx5KTsNCiB9DQogDQogc3RhdGljIGludCBwaW5fcGFnZV90YWJsZSh1MzIgbWZuLCBzdHJ1Y3Qg
ZG9tYWluICpkKQ0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch12.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch12.diff"


YXJtOiBpbXBsZW1lbnQgZ2V0L3B1dCBwYWdlIGZ1bmN0aW9ucwoKIHhlbi9hcmNoL2FybS94
ZW4vbW0uYyB8ICA2MSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDU1IGluc2VydGlvbnMo
KyksIDYgZGVsZXRpb25zKC0pCgpTaWduZWQtb2ZmLWJ5OiBKYWVtaW4gUnl1IDxqbTc3LnJ5
dUBzYW1zdW5nLmNvbT4KCmRpZmYgLXIgYzNlNzMzM2VlZmMzIHhlbi9hcmNoL2FybS94ZW4v
bW0uYwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL21tLmMJU3VuIEZlYiAxMiAxNTowNDoyNCAy
MDEyICswOTAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vbW0uYwlTdW4gRmViIDEyIDE1OjEz
OjA5IDIwMTIgKzA5MDAKQEAgLTczLDI5ICs3Myw3OCBAQCB2b2lkIG1lbWd1YXJkX3VuZ3Vh
cmRfcmFuZ2Uodm9pZCAqcCwgdW5zCiAKIHZvaWQgcHV0X3BhZ2Uoc3RydWN0IHBhZ2VfaW5m
byAqcGFnZSkKIHsKLQlOT1RfWUVUKCk7CisgICAgICAgIHUzMiBueCwgeCwgeSA9IHBhZ2Ut
PmNvdW50X2luZm87CisKKyAgICAgICAgZG8geworICAgICAgICAgICAgICAgIHggID0geTsK
KyAgICAgICAgICAgICAgICBueCA9IHggLSAxOworICAgICAgICB9IHdoaWxlICggdW5saWtl
bHkoKHkgPSBjbXB4Y2hnKCZwYWdlLT5jb3VudF9pbmZvLCB4LCBueCkpICE9IHgpICk7CisK
KyAgICAgICAgaWYgKCB1bmxpa2VseSgobnggJiBQR0NfY291bnRfbWFzaykgPT0gMCkgKSB7
CisgICAgICAgICAgICAgICAgZnJlZV9kb21oZWFwX3BhZ2UocGFnZSk7CisgICAgICAgIH0K
KwogfQogCiBzdHJ1Y3QgZG9tYWluICpwYWdlX2dldF9vd25lcl9hbmRfcmVmZXJlbmNlKHN0
cnVjdCBwYWdlX2luZm8gKnBhZ2UpCiB7Ci0JTk9UX1lFVCgpOworICAgICAgICB1bnNpZ25l
ZCBsb25nIHgsIHkgPSBwYWdlLT5jb3VudF9pbmZvOworCisgICAgICAgIGRvIHsKKyAgICAg
ICAgICAgICAgICB4ID0geTsKKyAgICAgICAgICAgICAgICBpZih1bmxpa2VseSgoKHggKyAy
KSAmIFBHQ19jb3VudF9tYXNrKSA8PSAyKSApCisgICAgICAgICAgICAgICAgICAgICAgICBy
ZXR1cm4gTlVMTDsKKyAgICAgICAgfSB3aGlsZSgoeSA9IGNtcHhjaGcoJnBhZ2UtPmNvdW50
X2luZm8seCx4KzEpKSAhPSB4KTsKKworICAgICAgICByZXR1cm4gcGFnZV9nZXRfb3duZXIo
cGFnZSk7CisKIH0KIAogaW50IGdldF9wYWdlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHN0
cnVjdCBkb21haW4gKmRvbWFpbikKIHsKLQlOT1RfWUVUKCk7CisgICAgICAgIHN0cnVjdCBk
b21haW4gKm93bmVyID0gcGFnZV9nZXRfb3duZXJfYW5kX3JlZmVyZW5jZShwYWdlKTsKIAot
CXJldHVybiAwOworICAgICAgICBpZiAobGlrZWx5KG93bmVyID09IGRvbWFpbikpCisgICAg
ICAgICAgICAgICAgcmV0dXJuIDE7CisKKyAgICAgICAgaWYgKG93bmVyICE9IGRvbWFpbikK
KyAgICAgICAgICAgICAgICBwdXRfcGFnZShwYWdlKTsKKworICAgICAgICByZXR1cm4gMDsK
IH0KIAogdm9pZCBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KHN0cnVjdCBwYWdlX2luZm8g
KnBhZ2UsIHN0cnVjdCBkb21haW4gKmQsIGludCByZWFkb25seSkKIHsKLQlOT1RfWUVUKCk7
CisgICAgICAgIGlmKHBhZ2VfZ2V0X293bmVyKHBhZ2UpID09IGQpCisgICAgICAgICAgICAg
ICAgcmV0dXJuOworCisgICAgICAgIHNldF9ncGZuX2Zyb21fbWZuKHBhZ2VfdG9fbWZuKHBh
Z2UpLCBJTlZBTElEX00yUF9FTlRSWSk7CisKKyAgICAgICAgc3Bpbl9sb2NrKCZkLT5wYWdl
X2FsbG9jX2xvY2spOworCisgICAgICAgIC8qIFRoZSBpbmNyZW1lbnRlZCB0eXBlIGNvdW50
IHBpbnMgYXMgd3JpdGFibGUgb3IgcmVhZC1vbmx5LiAqLworICAgICAgICBwYWdlLT51Lmlu
dXNlLnR5cGVfaW5mbyAgPSAocmVhZG9ubHkgPyBQR1Rfbm9uZSA6IFBHVF93cml0YWJsZV9w
YWdlKTsKKyAgICAgICAgcGFnZS0+dS5pbnVzZS50eXBlX2luZm8gfD0gUEdUX3ZhbGlkYXRl
ZCB8IDE7CisKKyAgICAgICAgcGFnZV9zZXRfb3duZXIocGFnZSwgZCk7CisgICAgICAgIHdt
YigpOyAvKiBpbnN0YWxsIHZhbGlkIGRvbWFpbiBwdHIgYmVmb3JlIHVwZGF0aW5nIHJlZmNu
dC4gKi8KKyAgICAgICAgQVNTRVJUKChwYWdlLT5jb3VudF9pbmZvICYgflBHQ194ZW5faGVh
cCkgPT0gMCk7CisKKyAgICAgICAgaWYgKCFkLT5pc19keWluZykgeworICAgICAgICAgICAg
ICAgIHBhZ2UtPmNvdW50X2luZm8gfD0gUEdDX2FsbG9jYXRlZCB8IDE7CisKKyAgICAgICAg
ICAgICAgICBpZiAoIHVubGlrZWx5KGQtPnhlbmhlYXBfcGFnZXMrKyA9PSAwKSApCisgICAg
ICAgICAgICAgICAgICAgICAgICBnZXRfa25vd25hbGl2ZV9kb21haW4oZCk7CisKKyAgICAg
ICAgICAgICAgICBwYWdlX2xpc3RfYWRkX3RhaWwocGFnZSwgJmQtPnhlbnBhZ2VfbGlzdCk7
CisgICAgICAgIH0KKworICAgICAgICBzcGluX3VubG9jaygmZC0+cGFnZV9hbGxvY19sb2Nr
KTsKIH0KIAogdm9pZCBzaGFyZV94ZW5fcGFnZV93aXRoX3ByaXZpbGVnZWRfZ3Vlc3RzKHN0
cnVjdCBwYWdlX2luZm8gKnBhZ2UsIGludCByZWFkb25seSkKIHsKLQlOT1RfWUVUKCk7Cisg
ICAgICAgIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3QocGFnZSwgZG9tX3hlbiwgcmVhZG9u
bHkpOwogfQogCiBzdGF0aWMgaW50IHBpbl9wYWdlX3RhYmxlKHUzMiBtZm4sIHN0cnVjdCBk
b21haW4gKmQpCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt17-0005yC-A7; Mon, 13 Feb 2012 10:20:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqq0-0003rV-E3
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:00:40 +0000
Received: from [85.158.139.83:57958] by server-3.bemta-5.messagelabs.com id
	BB/ED-25605-723C83F4; Mon, 13 Feb 2012 08:00:39 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329120037!14713126!1
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29154 invoked from network); 13 Feb 2012 08:00:38 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-7.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 08:00:38 -0000
Received: from epcpsbge3.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB0007ENJOD280@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:00:37 +0900 (KST)
Message-id: <0LZB0009YNL1D280@mailout1.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-3c-4f38c324210a
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id B9.AC.17710.423C83F4;
	Mon, 13 Feb 2012 17:00:36 +0900 (KST)
Date: Mon, 13 Feb 2012 08:00:36 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075949918@jm77.ryu
Msgkey: 20120213075949918@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213075853731@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 08/14] arm: implement do_set_trap_table function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <17343029.70141329120032962.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgZG9fc2V0X3RyYXBfdGFibGUgZnVuY3Rpb24NCg0KU2lnbmVkLW9mZi1i
eTogSmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgMzM0ZGZkZWJk
ZTEyIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9mYXVs
dC5jCVN1biBGZWIgMTIgMTE6NDY6NTIgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hl
bi9mYXVsdC5jCVN1biBGZWIgMTIgMTE6NTQ6MzMgMjAxMiArMDkwMA0KQEAgLTExOCw2ICsxMTgs
MjIgQEAgdm9pZCB1bnJlZ2lzdGVyX2d1ZXN0X25taV9jYWxsYmFjayh2b2lkKQ0KIA0KIGxvbmcg
ZG9fc2V0X3RyYXBfdGFibGUoWEVOX0dVRVNUX0hBTkRMRSh0cmFwX2luZm9fdCkgdHJhcHMpDQog
ew0KKwl1bnNpZ25lZCBsb25nIHRyYXBfdGFibGU7DQorDQorCWlmICggZ3Vlc3RfaGFuZGxlX2lz
X251bGwodHJhcHMpICkNCisJCWdvdG8gZmFpbGVkOw0KKw0KKwl0cmFwX3RhYmxlID0gKHVuc2ln
bmVkIGxvbmcpdHJhcHMucDsNCisNCisJY3VycmVudC0+YXJjaC5jdHgudmJhciA9IHRyYXBfdGFi
bGU7DQorDQorCXJldHVybiAwOw0KKw0KK2ZhaWxlZDoNCisJY3VycmVudC0+YXJjaC5jdHgudmJh
ciA9IDA7DQorDQorCXByaW50aygiVHJhcCB0YWJsZSBpbnN0YWxsIGZhaWxlZFxuIik7DQorDQog
CXJldHVybiAtRUZBVUxUOw0KIH0NCiANCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch08.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch08.diff"


YXJtOiBpbXBsZW1lbnQgZG9fc2V0X3RyYXBfdGFibGUgZnVuY3Rpb24KClNpZ25lZC1vZmYt
Ynk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciAzMzRkZmRl
YmRlMTIgeGVuL2FyY2gvYXJtL3hlbi9mYXVsdC5jCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4v
ZmF1bHQuYwlTdW4gRmViIDEyIDExOjQ2OjUyIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9mYXVsdC5jCVN1biBGZWIgMTIgMTE6NTQ6MzMgMjAxMiArMDkwMApAQCAtMTE4
LDYgKzExOCwyMiBAQCB2b2lkIHVucmVnaXN0ZXJfZ3Vlc3Rfbm1pX2NhbGxiYWNrKHZvaWQp
CiANCiBsb25nIGRvX3NldF90cmFwX3RhYmxlKFhFTl9HVUVTVF9IQU5ETEUodHJhcF9pbmZv
X3QpIHRyYXBzKQ0KIHsNCisJdW5zaWduZWQgbG9uZyB0cmFwX3RhYmxlOw0KKw0KKwlpZiAo
IGd1ZXN0X2hhbmRsZV9pc19udWxsKHRyYXBzKSApDQorCQlnb3RvIGZhaWxlZDsNCisNCisJ
dHJhcF90YWJsZSA9ICh1bnNpZ25lZCBsb25nKXRyYXBzLnA7DQorDQorCWN1cnJlbnQtPmFy
Y2guY3R4LnZiYXIgPSB0cmFwX3RhYmxlOw0KKw0KKwlyZXR1cm4gMDsNCisNCitmYWlsZWQ6
DQorCWN1cnJlbnQtPmFyY2guY3R4LnZiYXIgPSAwOw0KKw0KKwlwcmludGsoIlRyYXAgdGFi
bGUgaW5zdGFsbCBmYWlsZWRcbiIpOw0KKw0KIAlyZXR1cm4gLUVGQVVMVDsNCiB9DQogDQo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt13-0005vJ-26; Mon, 13 Feb 2012 10:20:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=0387cb7a1b=mjg59@cavan.codon.org.uk>)
	id 1Rvqn9-0001LA-2i
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 13:45:35 +0000
X-Env-Sender: prvs=0387cb7a1b=mjg59@cavan.codon.org.uk
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328881528!12851972!1
X-Originating-IP: [93.93.128.6]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3732 invoked from network); 10 Feb 2012 13:45:28 -0000
Received: from cavan.codon.org.uk (HELO cavan.codon.org.uk) (93.93.128.6)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Feb 2012 13:45:28 -0000
Received: from mjg59 by cavan.codon.org.uk with local (Exim 4.72)
	(envelope-from <mjg59@cavan.codon.org.uk>)
	id 1Rvqn0-0007jZ-2k; Fri, 10 Feb 2012 13:45:26 +0000
Date: Fri, 10 Feb 2012 13:45:26 +0000
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: liang tang <liang.tang@oracle.com>
Message-ID: <20120210134525.GA29662@srcf.ucam.org>
References: <1328758250-23989-1-git-send-email-liang.tang@oracle.com>
	<1328758401-24258-1-git-send-email-liang.tang@oracle.com>
	<20120209194723.GA8622@srcf.ucam.org> <4F34C622.3060905@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F34C622.3060905@oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk
X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: linux-acpi@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 3/5] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, 2012 at 03:24:18PM +0800, liang tang wrote:
> Hi,Matthew
> the xen efi call need to use hypercall. that is different from the
> generic efi code. do you any idea about that. thanks!

Right, but 32-bit EFI needs to make different calls to 64-bit EFI 
anyway. It would be good if the abstraction could be done at this level 
instead of duplicating the code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt13-0005vR-HP; Mon, 13 Feb 2012 10:20:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvzzN-0003fg-Dl
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 23:34:49 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328916848!51978386!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MDY2MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12460 invoked from network); 10 Feb 2012 23:34:09 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Feb 2012 23:34:09 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RvzzG-0007Ar-Kq from Paul_Brook@mentor.com ;
	Fri, 10 Feb 2012 15:34:42 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 23:34:40 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 4468C6EEE7;
	Fri, 10 Feb 2012 23:34:40 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: qemu-devel@nongnu.org
Date: Fri, 10 Feb 2012 23:34:39 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<4F350047.4030507@siemens.com>
	<alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201202102334.40125.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 23:34:41.0256 (UTC)
	FILETIME=[8FAD4E80:01CCE84C]
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +#ifdef CONFIG_SLIRP
> +static inline void slirp_update_timeout(uint32_t *timeout)
> +{
> +    *timeout = MIN(1000, *timeout);
> +}
> +#else
> +static inline void slirp_update_timeout(uint32_t *timeout) { }
> +#endif

Shouldn't we be testing whether slirp is actually in use? I doubt many people 
go to the effort of rebuilding without SLIRP support.

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt12-0005uv-B5; Mon, 13 Feb 2012 10:20:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvoLn-0001cZ-RX
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:09:12 +0000
Received: from [85.158.139.83:15024] by server-12.bemta-5.messagelabs.com id
	8F/A5-30830-6DAF43F4; Fri, 10 Feb 2012 11:09:10 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328872148!14511602!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MjU4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10799 invoked from network); 10 Feb 2012 11:09:09 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 11:09:09 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RvoLh-0002mw-BY from Paul_Brook@mentor.com ;
	Fri, 10 Feb 2012 03:09:05 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 11:09:04 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 8AFCD6EE61;
	Fri, 10 Feb 2012 11:09:03 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 10 Feb 2012 11:09:02 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
In-Reply-To: <4F34F567.3040309@redhat.com>
MIME-Version: 1.0
Message-Id: <201202101109.03374.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 11:09:04.0309 (UTC)
	FILETIME=[6660EE50:01CCE7E4]
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >> >  At least the floppy DMA engine is fine with it, it uses idle bottom
> >> >  halves (which are a hack and could be replaced by timers, but that's
> >> >  not relevant now).
> > 
> > I thought idle bottom halves were one of the things that made this timout
> > necessary.  How else are they going to get run?
> 
> The timeout is reduced to 10 ms when an idle bottom half is scheduled.
> See qemu_bh_update_timeout in async.c.

Ah, I see.  Idle BH are indeed a nasty hack that should be removed, but not 
directly relevant to this 1s timeout.

I don't think this changes my overall conlusion:  Either we need this timeout 
to poll below the user-thinks-qemu-died threshold, or we should be blocking 
indefinitely.

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt14-0005vm-DJ; Mon, 13 Feb 2012 10:20:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqiv-00039v-GE
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:53:22 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329119591!14532228!2
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19414 invoked from network); 13 Feb 2012 07:53:14 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-8.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:53:14 -0000
Received: from epcpsbge7.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB0031FN7WRKB0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:10 +0900 (KST)
Message-id: <0LZB0032AN8MRKB0@mailout2.samsung.com>
X-AuditID: cbfee611-b7b12ae0000036c1-4c-4f38c1224dce
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge7.samsung.com (EPCPMTA) with SMTP id 5B.09.14017.221C83F4;
	Mon, 13 Feb 2012 16:52:02 +0900 (KST)
Date: Mon, 13 Feb 2012 07:53:10 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213074940046@jm77.ryu
Msgkey: 20120213074940046@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213074805604@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 02/14] arm: import the files required to "arm"
	port.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <23931488.69631329119586906.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBvcnQgdGhlIGZpbGVzIHJlcXVpcmVkIHRvICJhcm0iIHBvcnQuDQoNCmNvbmZpZy9h
cm0ubWsgICAgICAgICAgICAgICAgICAgICAgfCAgIDI4ICsrKw0KIHhlbi9hcmNoL2FybS9NYWtl
ZmlsZSAgICAgICAgICAgICAgfCAgIDQ3ICsrKysrDQogeGVuL2FyY2gvYXJtL1J1bGVzLm1rICAg
ICAgICAgICAgICB8ICAgMjUgKysrDQogeGVuL2FyY2gvYXJtL2xpYi9NYWtlZmlsZSAgICAgICAg
ICB8ICAgMTEgKw0KIHhlbi9hcmNoL2FybS9saWIvYXNobGRpMy5TICAgICAgICAgfCAgIDQ1ICsr
KysrDQogeGVuL2FyY2gvYXJtL2xpYi9hc2hyZGkzLlMgICAgICAgICB8ICAgNDYgKysrKysNCiB4
ZW4vYXJjaC9hcm0vbGliL2JwYWJpLWFzbS5TICAgICAgIHwgICA1NSArKysrKysNCiB4ZW4vYXJj
aC9hcm0vbGliL2JwYWJpLmMgICAgICAgICAgIHwgICA1MSArKysrKysNCiB4ZW4vYXJjaC9hcm0v
bGliL2NsZWFyYml0LlMgICAgICAgIHwgICAyNCArKw0KIHhlbi9hcmNoL2FybS9saWIvY29weV90
ZW1wbGF0ZS5TICAgfCAgMjU1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9h
cmNoL2FybS9saWIvZGVsYXkuUyAgICAgICAgICAgfCAgICA3ICsNCiB4ZW4vYXJjaC9hcm0vbGli
L2RpdjY0LlMgICAgICAgICAgIHwgIDE5OSArKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4v
YXJjaC9hcm0vbGliL2ZpbmRiaXQuUyAgICAgICAgIHwgICA4MSArKysrKysrKysNCiB4ZW4vYXJj
aC9hcm0vbGliL2djY2xpYi5oICAgICAgICAgIHwgICAzMyArKysrDQogeGVuL2FyY2gvYXJtL2xp
Yi9nZXR1c2VyLlMgICAgICAgICB8ICAgNzcgKysrKysrKysrDQogeGVuL2FyY2gvYXJtL2xpYi9s
aWIxZnVuY3MuUyAgICAgICB8ICAyNTYgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0K
IHhlbi9hcmNoL2FybS9saWIvbG9uZ2xvbmcuaCAgICAgICAgfCAgMTgzICsrKysrKysrKysrKysr
KysrKysrKysNCiB4ZW4vYXJjaC9hcm0vbGliL2xzaHJkaTMuUyAgICAgICAgIHwgICAxNyArKw0K
IHhlbi9hcmNoL2FybS9saWIvbWF0aC5jICAgICAgICAgICAgfCAgICAzICsNCiB4ZW4vYXJjaC9h
cm0vbGliL21lbWNoci5TICAgICAgICAgIHwgICAxNCArDQogeGVuL2FyY2gvYXJtL2xpYi9tZW1j
cHkuUyAgICAgICAgICB8ICAgNjAgKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvbWVtbW92ZS5T
ICAgICAgICAgfCAgMjA3ICsrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0v
bGliL21lbW9yeS5TICAgICAgICAgIHwgIDQyMSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vbGliL21lbXNldC5TICAgICAg
ICAgIHwgICA2OSArKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvbWVtemVyby5TICAgICAgICAg
fCAgIDcxICsrKysrKysrDQogeGVuL2FyY2gvYXJtL2xpYi9tdWxkaTMuYyAgICAgICAgICB8ICAg
ODYgKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvcHV0dXNlci5TICAgICAgICAgfCAgIDc1
ICsrKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvc2V0Yml0LlMgICAgICAgICAgfCAgIDIyICsr
DQogeGVuL2FyY2gvYXJtL2xpYi9zdHJjaHIuUyAgICAgICAgICB8ICAgMTUgKw0KIHhlbi9hcmNo
L2FybS9saWIvdGVzdGNoYW5nZWJpdC5TICAgfCAgIDIyICsrDQogeGVuL2FyY2gvYXJtL2xpYi90
ZXN0Y2xlYXJiaXQuUyAgICB8ICAgMjIgKysNCiB4ZW4vYXJjaC9hcm0vbGliL3Rlc3RzZXRiaXQu
UyAgICAgIHwgICAyMCArKw0KIHhlbi9hcmNoL2FybS9saWIvdWFjY2Vzcy5TICAgICAgICAgfCAg
Njg0ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2FyY2gvYXJtL2xpYi91ZGl2ZGkz
LmMgICAgICAgICB8ICAyNDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJj
aC9hcm0vbGliL3VsZGl2bW9kLlMgICAgICAgIHwgIDE0OCArKysrKysrKysrKysrKysrKw0KIHhl
bi9hcmNoL2FybS90ZWdyYS9NYWtlZmlsZSAgICAgICAgfCAgICAxICsNCiB4ZW4vYXJjaC9hcm0v
dGVncmEvUnVsZXMubWsgICAgICAgIHwgICAgMSArDQogeGVuL2FyY2gvYXJtL3RlZ3JhL2R1bW15
LmMgICAgICAgICB8ICAgIDMgKw0KIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUgICAgICAgICAg
fCAgIDE5ICsrDQogeGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jICAgICB8ICAyMTIgKysr
KysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21jdGwuYyAg
ICAgfCAgIDQzICsrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9hcmNoX3N5c2N0bC5jICAgICB8ICAg
MzggKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vYXNtLW9mZnNldHMuYyAgICAgfCAgIDQwICsrKysN
CiB4ZW4vYXJjaC9hcm0veGVuL2J1Zy5jICAgICAgICAgICAgIHwgICAzMiArKysNCiB4ZW4vYXJj
aC9hcm0veGVuL2NwdS5jICAgICAgICAgICAgIHwgICA5NyArKysrKysrKysrKw0KIHhlbi9hcmNo
L2FybS94ZW4vY3Jhc2guYyAgICAgICAgICAgfCAgIDI1ICsrKw0KIHhlbi9hcmNoL2FybS94ZW4v
ZG9tYWluX2J1aWxkLmMgICAgfCAgIDQ3ICsrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9kb21haW5f
cGFnZS5jICAgICB8ICAgMjIgKysNCiB4ZW4vYXJjaC9hcm0veGVuL2ZhdWx0LmMgICAgICAgICAg
IHwgIDEyMyArKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vZ3JhbnRfdGFibGUuYyAg
ICAgfCAgIDUzICsrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vaW9tbXUuYyAgICAgICAgICAgfCAg
IDI0ICsrDQogeGVuL2FyY2gvYXJtL3hlbi9pcnEuYyAgICAgICAgICAgICB8ICAgODQgKysrKysr
KysrKw0KIHhlbi9hcmNoL2FybS94ZW4vbWFjaGluZV9rZXhlYy5jICAgfCAgIDMxICsrKw0KIHhl
bi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgICAgfCAgMTk0ICsrKysrKysrKysrKysrKysr
KysrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9wMm0uYyAgICAgICAgICAgICB8ICAgNDQgKysrKysN
CiB4ZW4vYXJjaC9hcm0veGVuL3BjaS5jICAgICAgICAgICAgIHwgICA3NCArKysrKysrKw0KIHhl
bi9hcmNoL2FybS94ZW4vcGVyZm1vbi5jICAgICAgICAgfCAgIDI2ICsrKw0KIHhlbi9hcmNoL2Fy
bS94ZW4vc2V0dXAuYyAgICAgICAgICAgfCAgIDY0ICsrKysrKysNCiB4ZW4vYXJjaC9hcm0veGVu
L3NodXRkb3duLmMgICAgICAgIHwgICAzOCArKysrDQogeGVuL2FyY2gvYXJtL3hlbi90aW1lLmMg
ICAgICAgICAgICB8ICAgODMgKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vdGxiLmMgICAg
ICAgICAgICAgfCAgIDI2ICsrKw0KIHhlbi9hcmNoL2FybS94ZW4veGVuLmxkcy5TICAgICAgICAg
fCAgMTU5ICsrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2FjcGkuaCAg
ICAgICAgIHwgICAgOCArDQogeGVuL2luY2x1ZGUvYXNtLWFybS9hc20tbWFjcm9zLmggICB8ICAx
MDYgKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9hdG9taWMuaCAgICAgICB8ICAx
NzkgKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9iaXRvcHMuaCAg
ICAgICB8ICAxOTMgKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJt
L2J1Zy5oICAgICAgICAgIHwgICAzMiArKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2J5dGVvcmRl
ci5oICAgIHwgICAgOSArDQogeGVuL2luY2x1ZGUvYXNtLWFybS9jYWNoZS5oICAgICAgICB8ICAg
MTEgKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vY29uZmlnLmggICAgICAgfCAgIDYxICsrKysrKysN
CiB4ZW4vaW5jbHVkZS9hc20tYXJtL2NwdS1kb21haW4uaCAgIHwgICAzOSArKysrDQogeGVuL2lu
Y2x1ZGUvYXNtLWFybS9jdXJyZW50LmggICAgICB8ICAgNzMgKysrKysrKysNCiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL2RlYnVnZ2VyLmggICAgIHwgICAyNCArKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0v
ZGVsYXkuaCAgICAgICAgfCAgICA2ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RpdjY0LmggICAg
ICAgIHwgICA0MyArKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmggICAgICAgfCAg
IDc5ICsrKysrKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vZWxmLmggICAgICAgICAgfCAgIDUz
ICsrKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vZXZlbnQuaCAgICAgICAgfCAgIDM5ICsrKysN
CiB4ZW4vaW5jbHVkZS9hc20tYXJtL2ZsdXNodGxiLmggICAgIHwgICAyNSArKysNCiB4ZW4vaW5j
bHVkZS9hc20tYXJtL2dyYW50X3RhYmxlLmggIHwgICA2MiArKysrKysrDQogeGVuL2luY2x1ZGUv
YXNtLWFybS9ndWVzdF9hY2Nlc3MuaCB8ICAxMzYgKysrKysrKysrKysrKysrKw0KIHhlbi9pbmNs
dWRlL2FzbS1hcm0vaGFyZGlycS5oICAgICAgfCAgIDIxICsrDQogeGVuL2luY2x1ZGUvYXNtLWFy
bS9oeXBlcmNhbGwuaCAgICB8ICAgNjggKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2lu
aXQuaCAgICAgICAgIHwgICAgNCArDQogeGVuL2luY2x1ZGUvYXNtLWFybS9pby5oICAgICAgICAg
ICB8ICAgMzIgKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9pb2NhcC5oICAgICAgICB8ICAgMTUg
Kw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vaW9tbXUuaCAgICAgICAgfCAgIDE0ICsNCiB4ZW4vaW5j
bHVkZS9hc20tYXJtL2lycS5oICAgICAgICAgIHwgICA1MCArKysrKysNCiB4ZW4vaW5jbHVkZS9h
c20tYXJtL21tLmggICAgICAgICAgIHwgIDIzNyArKysrKysrKysrKysrKysrKysrKysrKysrKysr
DQogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCAgICAgICAgICB8ICAgMTEgKw0KIHhlbi9pbmNs
dWRlL2FzbS1hcm0vbXVsdGljYWxsLmggICAgfCAgICA5ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJt
L251bWEuaCAgICAgICAgIHwgICAyMSArKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vcDJtLmggICAg
ICAgICAgfCAgIDEwICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BhZ2UuaCAgICAgICAgIHwgICA5
NSArKysrKysrKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vcGNpLmggICAgICAgICAgfCAgICA5
ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BlcmNwdS5oICAgICAgIHwgICAxNiArDQogeGVuL2lu
Y2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaCAgICB8ICAyMTkgKysrKysrKysrKysrKysrKysrKysr
KysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3JlZ3MuaCAgICAgICAgIHwgICAxNyArKw0KIHhl
bi9pbmNsdWRlL2FzbS1hcm0vc21wLmggICAgICAgICAgfCAgIDI4ICsrKw0KIHhlbi9pbmNsdWRl
L2FzbS1hcm0vc29mdGlycS5oICAgICAgfCAgIDExICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3Nw
aW5sb2NrLmggICAgIHwgIDIwMCArKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL3N0cmluZy5oICAgICAgIHwgICA0OSArKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1h
cm0vc3lzdGVtLmggICAgICAgfCAgMTQ4ICsrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUv
YXNtLWFybS90ZWdyYS9jb25maWcuaCB8ICAgMTEgKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGlt
ZS5oICAgICAgICAgfCAgIDI0ICsrDQogeGVuL2luY2x1ZGUvYXNtLWFybS90cmFjZS5oICAgICAg
ICB8ICAgIDYgKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vdHlwZXMuaCAgICAgICAgfCAgIDU4ICsr
KysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3hlbm9wcm9mLmggICAgIHwgICA0MyArKysrKw0K
IHhlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oICAgICAgfCAgMTgwICsrKysrKysrKysrKysr
KysrKysrKw0KIDEwOSBmaWxlcyBjaGFuZ2VkLCA4MDA4IGluc2VydGlvbnMoKyksIDAgZGVsZXRp
b25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29t
Pg0KDQo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch02.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch02.diff"


YXJtOiBpbXBvcnQgdGhlIGZpbGVzIHJlcXVpcmVkIHRvICJhcm0iIHBvcnQuCgogY29uZmln
L2FybS5tayAgICAgICAgICAgICAgICAgICAgICB8ICAgMjggKysrCiB4ZW4vYXJjaC9hcm0v
TWFrZWZpbGUgICAgICAgICAgICAgIHwgICA0NyArKysrKwogeGVuL2FyY2gvYXJtL1J1bGVz
Lm1rICAgICAgICAgICAgICB8ICAgMjUgKysrCiB4ZW4vYXJjaC9hcm0vbGliL01ha2VmaWxl
ICAgICAgICAgIHwgICAxMSArCiB4ZW4vYXJjaC9hcm0vbGliL2FzaGxkaTMuUyAgICAgICAg
IHwgICA0NSArKysrKwogeGVuL2FyY2gvYXJtL2xpYi9hc2hyZGkzLlMgICAgICAgICB8ICAg
NDYgKysrKysKIHhlbi9hcmNoL2FybS9saWIvYnBhYmktYXNtLlMgICAgICAgfCAgIDU1ICsr
KysrKwogeGVuL2FyY2gvYXJtL2xpYi9icGFiaS5jICAgICAgICAgICB8ICAgNTEgKysrKysr
CiB4ZW4vYXJjaC9hcm0vbGliL2NsZWFyYml0LlMgICAgICAgIHwgICAyNCArKwogeGVuL2Fy
Y2gvYXJtL2xpYi9jb3B5X3RlbXBsYXRlLlMgICB8ICAyNTUgKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL2RlbGF5LlMgICAgICAgICAgIHwgICAg
NyArCiB4ZW4vYXJjaC9hcm0vbGliL2RpdjY0LlMgICAgICAgICAgIHwgIDE5OSArKysrKysr
KysrKysrKysrKysrKysrKysKIHhlbi9hcmNoL2FybS9saWIvZmluZGJpdC5TICAgICAgICAg
fCAgIDgxICsrKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9nY2NsaWIuaCAgICAgICAgICB8
ICAgMzMgKysrKwogeGVuL2FyY2gvYXJtL2xpYi9nZXR1c2VyLlMgICAgICAgICB8ICAgNzcg
KysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL2xpYjFmdW5jcy5TICAgICAgIHwgIDI1NiAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL2xvbmds
b25nLmggICAgICAgIHwgIDE4MyArKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9h
cm0vbGliL2xzaHJkaTMuUyAgICAgICAgIHwgICAxNyArKwogeGVuL2FyY2gvYXJtL2xpYi9t
YXRoLmMgICAgICAgICAgICB8ICAgIDMgKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1jaHIuUyAg
ICAgICAgICB8ICAgMTQgKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1jcHkuUyAgICAgICAgICB8
ICAgNjAgKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1tb3ZlLlMgICAgICAgICB8ICAy
MDcgKysrKysrKysrKysrKysrKysrKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1vcnku
UyAgICAgICAgICB8ICA0MjEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL21lbXNldC5TICAgICAgICAgIHwg
ICA2OSArKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9tZW16ZXJvLlMgICAgICAgICB8ICAg
NzEgKysrKysrKysKIHhlbi9hcmNoL2FybS9saWIvbXVsZGkzLmMgICAgICAgICAgfCAgIDg2
ICsrKysrKysrKysKIHhlbi9hcmNoL2FybS9saWIvcHV0dXNlci5TICAgICAgICAgfCAgIDc1
ICsrKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9zZXRiaXQuUyAgICAgICAgICB8ICAgMjIg
KysKIHhlbi9hcmNoL2FybS9saWIvc3RyY2hyLlMgICAgICAgICAgfCAgIDE1ICsKIHhlbi9h
cmNoL2FybS9saWIvdGVzdGNoYW5nZWJpdC5TICAgfCAgIDIyICsrCiB4ZW4vYXJjaC9hcm0v
bGliL3Rlc3RjbGVhcmJpdC5TICAgIHwgICAyMiArKwogeGVuL2FyY2gvYXJtL2xpYi90ZXN0
c2V0Yml0LlMgICAgICB8ICAgMjAgKysKIHhlbi9hcmNoL2FybS9saWIvdWFjY2Vzcy5TICAg
ICAgICAgfCAgNjg0ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9h
cm0vbGliL3VkaXZkaTMuYyAgICAgICAgIHwgIDI0MiArKysrKysrKysrKysrKysrKysrKysr
KysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi91bGRpdm1vZC5TICAgICAgICB8ICAxNDggKysr
KysrKysrKysrKysrKysKIHhlbi9hcmNoL2FybS90ZWdyYS9NYWtlZmlsZSAgICAgICAgfCAg
ICAxICsKIHhlbi9hcmNoL2FybS90ZWdyYS9SdWxlcy5tayAgICAgICAgfCAgICAxICsKIHhl
bi9hcmNoL2FybS90ZWdyYS9kdW1teS5jICAgICAgICAgfCAgICAzICsKIHhlbi9hcmNoL2Fy
bS94ZW4vTWFrZWZpbGUgICAgICAgICAgfCAgIDE5ICsrCiB4ZW4vYXJjaC9hcm0veGVuL2Fy
Y2hfZG9tYWluLmMgICAgIHwgIDIxMiArKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4v
YXJjaC9hcm0veGVuL2FyY2hfZG9tY3RsLmMgICAgIHwgICA0MyArKysrKwogeGVuL2FyY2gv
YXJtL3hlbi9hcmNoX3N5c2N0bC5jICAgICB8ICAgMzggKysrKwogeGVuL2FyY2gvYXJtL3hl
bi9hc20tb2Zmc2V0cy5jICAgICB8ICAgNDAgKysrKwogeGVuL2FyY2gvYXJtL3hlbi9idWcu
YyAgICAgICAgICAgICB8ICAgMzIgKysrCiB4ZW4vYXJjaC9hcm0veGVuL2NwdS5jICAgICAg
ICAgICAgIHwgICA5NyArKysrKysrKysrKwogeGVuL2FyY2gvYXJtL3hlbi9jcmFzaC5jICAg
ICAgICAgICB8ICAgMjUgKysrCiB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jICAg
IHwgICA0NyArKysrKwogeGVuL2FyY2gvYXJtL3hlbi9kb21haW5fcGFnZS5jICAgICB8ICAg
MjIgKysKIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYyAgICAgICAgICAgfCAgMTIzICsrKysr
KysrKysrKysrCiB4ZW4vYXJjaC9hcm0veGVuL2dyYW50X3RhYmxlLmMgICAgIHwgICA1MyAr
KysrKysKIHhlbi9hcmNoL2FybS94ZW4vaW9tbXUuYyAgICAgICAgICAgfCAgIDI0ICsrCiB4
ZW4vYXJjaC9hcm0veGVuL2lycS5jICAgICAgICAgICAgIHwgICA4NCArKysrKysrKysrCiB4
ZW4vYXJjaC9hcm0veGVuL21hY2hpbmVfa2V4ZWMuYyAgIHwgICAzMSArKysKIHhlbi9hcmNo
L2FybS94ZW4vbW0uYyAgICAgICAgICAgICAgfCAgMTk0ICsrKysrKysrKysrKysrKysrKysr
KysrCiB4ZW4vYXJjaC9hcm0veGVuL3AybS5jICAgICAgICAgICAgIHwgICA0NCArKysrKwog
eGVuL2FyY2gvYXJtL3hlbi9wY2kuYyAgICAgICAgICAgICB8ICAgNzQgKysrKysrKysKIHhl
bi9hcmNoL2FybS94ZW4vcGVyZm1vbi5jICAgICAgICAgfCAgIDI2ICsrKwogeGVuL2FyY2gv
YXJtL3hlbi9zZXR1cC5jICAgICAgICAgICB8ICAgNjQgKysrKysrKwogeGVuL2FyY2gvYXJt
L3hlbi9zaHV0ZG93bi5jICAgICAgICB8ICAgMzggKysrKwogeGVuL2FyY2gvYXJtL3hlbi90
aW1lLmMgICAgICAgICAgICB8ICAgODMgKysrKysrKysrKwogeGVuL2FyY2gvYXJtL3hlbi90
bGIuYyAgICAgICAgICAgICB8ICAgMjYgKysrCiB4ZW4vYXJjaC9hcm0veGVuL3hlbi5sZHMu
UyAgICAgICAgIHwgIDE1OSArKysrKysrKysrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20t
YXJtL2FjcGkuaCAgICAgICAgIHwgICAgOCArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2FzbS1t
YWNyb3MuaCAgIHwgIDEwNiArKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vYXRv
bWljLmggICAgICAgfCAgMTc5ICsrKysrKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUv
YXNtLWFybS9iaXRvcHMuaCAgICAgICB8ICAxOTMgKysrKysrKysrKysrKysrKysrKysrKysK
IHhlbi9pbmNsdWRlL2FzbS1hcm0vYnVnLmggICAgICAgICAgfCAgIDMyICsrKwogeGVuL2lu
Y2x1ZGUvYXNtLWFybS9ieXRlb3JkZXIuaCAgICB8ICAgIDkgKwogeGVuL2luY2x1ZGUvYXNt
LWFybS9jYWNoZS5oICAgICAgICB8ICAgMTEgKwogeGVuL2luY2x1ZGUvYXNtLWFybS9jb25m
aWcuaCAgICAgICB8ICAgNjEgKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9jcHUtZG9t
YWluLmggICB8ICAgMzkgKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmggICAg
ICB8ICAgNzMgKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vZGVidWdnZXIuaCAgICAg
fCAgIDI0ICsrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RlbGF5LmggICAgICAgIHwgICAgNiAr
CiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RpdjY0LmggICAgICAgIHwgICA0MyArKysrKwogeGVu
L2luY2x1ZGUvYXNtLWFybS9kb21haW4uaCAgICAgICB8ICAgNzkgKysrKysrKysrCiB4ZW4v
aW5jbHVkZS9hc20tYXJtL2VsZi5oICAgICAgICAgIHwgICA1MyArKysrKysKIHhlbi9pbmNs
dWRlL2FzbS1hcm0vZXZlbnQuaCAgICAgICAgfCAgIDM5ICsrKysKIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vZmx1c2h0bGIuaCAgICAgfCAgIDI1ICsrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9n
cmFudF90YWJsZS5oICB8ICAgNjIgKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9ndWVz
dF9hY2Nlc3MuaCB8ICAxMzYgKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFy
bS9oYXJkaXJxLmggICAgICB8ICAgMjEgKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vaHlwZXJj
YWxsLmggICAgfCAgIDY4ICsrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2luaXQuaCAg
ICAgICAgIHwgICAgNCArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2lvLmggICAgICAgICAgIHwg
ICAzMiArKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vaW9jYXAuaCAgICAgICAgfCAgIDE1ICsK
IHhlbi9pbmNsdWRlL2FzbS1hcm0vaW9tbXUuaCAgICAgICAgfCAgIDE0ICsKIHhlbi9pbmNs
dWRlL2FzbS1hcm0vaXJxLmggICAgICAgICAgfCAgIDUwICsrKysrKwogeGVuL2luY2x1ZGUv
YXNtLWFybS9tbS5oICAgICAgICAgICB8ICAyMzcgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCAgICAgICAgICB8ICAgMTEgKwogeGVu
L2luY2x1ZGUvYXNtLWFybS9tdWx0aWNhbGwuaCAgICB8ICAgIDkgKwogeGVuL2luY2x1ZGUv
YXNtLWFybS9udW1hLmggICAgICAgICB8ICAgMjEgKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0v
cDJtLmggICAgICAgICAgfCAgIDEwICsKIHhlbi9pbmNsdWRlL2FzbS1hcm0vcGFnZS5oICAg
ICAgICAgfCAgIDk1ICsrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BjaS5oICAg
ICAgICAgIHwgICAgOSArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BlcmNwdS5oICAgICAgIHwg
ICAxNiArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3Byb2Nlc3Nvci5oICAgIHwgIDIxOSArKysr
KysrKysrKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9yZWdzLmggICAg
ICAgICB8ICAgMTcgKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vc21wLmggICAgICAgICAgfCAg
IDI4ICsrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9zb2Z0aXJxLmggICAgICB8ICAgMTEgKwog
eGVuL2luY2x1ZGUvYXNtLWFybS9zcGlubG9jay5oICAgICB8ICAyMDAgKysrKysrKysrKysr
KysrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3N0cmluZy5oICAgICAgIHwgICA0
OSArKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9zeXN0ZW0uaCAgICAgICB8ICAxNDggKysr
KysrKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvY29uZmlnLmggfCAg
IDExICsKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGltZS5oICAgICAgICAgfCAgIDI0ICsrCiB4
ZW4vaW5jbHVkZS9hc20tYXJtL3RyYWNlLmggICAgICAgIHwgICAgNiArCiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL3R5cGVzLmggICAgICAgIHwgICA1OCArKysrKysrCiB4ZW4vaW5jbHVkZS9h
c20tYXJtL3hlbm9wcm9mLmggICAgIHwgICA0MyArKysrKwogeGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gtYXJtLmggICAgICB8ICAxODAgKysrKysrKysrKysrKysrKysrKysrCiAxMDkgZmls
ZXMgY2hhbmdlZCwgODAwOCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKU2lnbmVk
LW9mZi1ieTogSmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CgpkaWZmIC1yIGU3
MDE0NjFiMTI1MSBjb25maWcvYXJtLm1rCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCisrKyBiL2NvbmZpZy9hcm0ubWsJRnJpIEZlYiAwMyAxNjowNzow
MyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMjggQEAKKyMKKyMgQ3Jvc3MgVG9vbCBjaGFpbiBj
b25maWd1cmF0aW9uCisjCitUT09MQ0hBSU5fUFJFRklYID0gL29wdC9hcm0tbm9uZS1saW51
eC1nbnVlYWJpLW9sZC9iaW4vYXJtLW5vbmUtbGludXgtZ251ZWFiaS0KKworIworIyBUb29s
Y2hhaW4gY29uZmlndXJhdGlvbgorIworQVMgICAgICAgICAgICAgID0gJChUT09MQ0hBSU5f
UFJFRklYKWFzCitMRCAgICAgICAgICAgICAgPSAkKFRPT0xDSEFJTl9QUkVGSVgpbGQKK0ND
ICAgICAgICAgICAgICA9ICQoVE9PTENIQUlOX1BSRUZJWClnY2MKK0NQUCAgICAgICAgICAg
ICA9ICQoVE9PTENIQUlOX1BSRUZJWClnY2MgLUUKK0FSICAgICAgICAgICAgICA9ICQoVE9P
TENIQUlOX1BSRUZJWClhcgorUkFOTElCICAgICAgICAgID0gJChUT09MQ0hBSU5fUFJFRklY
KXJhbmxpYgorTk0gICAgICAgICAgICAgID0gJChUT09MQ0hBSU5fUFJFRklYKW5tCitTVFJJ
UCAgICAgICAgICAgPSAkKFRPT0xDSEFJTl9QUkVGSVgpc3RyaXAKK09CSkNPUFkgICAgICAg
ICA9ICQoVE9PTENIQUlOX1BSRUZJWClvYmpjb3B5CitPQkpEVU1QICAgICAgICAgPSAkKFRP
T0xDSEFJTl9QUkVGSVgpb2JqZHVtcAorCitESVNURElSICAgICAgICAgPz0gJChYRU5fUk9P
VCkvZGlzdAorREVTVERJUiAgICAgICAgID89ICQoRElTVERJUikvaW5zdGFsbAorCitJTlNU
QUxMICAgICAgICAgPSBpbnN0YWxsCitJTlNUQUxMX0RJUiAgICAgPSAkKElOU1RBTEwpIC1k
IC1tMDc1NQorSU5TVEFMTF9EQVRBICAgID0gJChJTlNUQUxMKSAtbTA2NDQKK0lOU1RBTExf
UFJPRyAgICA9ICQoSU5TVEFMTCkgLW0wNzU1CisKK0NPTkZJR19BUk0JOj0geQpkaWZmIC1y
IGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vTWFrZWZpbGUKLS0tIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL01ha2VmaWxl
CUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQ3IEBACisjCisj
IHhlbi9hcmNoL2FybS9NYWtlZmlsZQorIworCitpZm5kZWYgVEFSR0VUX1NVQkFSQ0gKKyQo
ZXJyb3IgWEVOX1RBUkdFVF9TVUJBUkNIIG11c3QgYmUgc3VwcGxpZWQuIFNlZSBDb25maWcu
bWsgZmlsZSkKK2VuZGlmCisKK3N1YmRpci15ICs9ICQoVEFSR0VUX1NVQkFSQ0gpIHhlbiBs
aWIKKworT0JKQ09QWUZMQUdTICAgIDo9LU8gYmluYXJ5IC1SIC5ub3RlIC1SIC5jb21tZW50
IC1TCisKKyQoVEFSR0VUKTogJChUQVJHRVQpLXN5bXMKKwkkKE5NKSAtbiAkPCB8IGdyZXAg
LXYgJyBbYVV3XSAnID4gJChARCkvU3lzdGVtLm1hcAorCSQoT0JKQ09QWSkgLU8gYmluYXJ5
IC1SIC5ub3RlIC1SIC5jb21tZW50IC1TICQ8ICRACisKKyQoVEFSR0VUKS1zeW1zOiB4ZW4u
bGRzICQoQUxMX09CSlMpIAorCSQoTUFLRSkgLWYgJChCQVNFRElSKS9SdWxlcy5tayAkKEJB
U0VESVIpL2NvbW1vbi9zeW1ib2xzLWR1bW15Lm8KKwkkKExEKSAkKExERkxBR1MpIC1UIHhl
bi5sZHMgLU4gLU1hcCAkKEBEKS8uJChARikuMC5tYXAgJChBTExfT0JKUykgXAorCSQoQkFT
RURJUikvY29tbW9uL3N5bWJvbHMtZHVtbXkubyAtbyAkKEBEKS8uJChARikuMAorCSQoTk0p
IC1uICQoQEQpLy4kKEBGKS4wIHwgJChCQVNFRElSKS90b29scy9zeW1ib2xzID4kKEBEKS8u
JChARikuMC5TCisJJChNQUtFKSAtZiAkKEJBU0VESVIpL1J1bGVzLm1rICQoQEQpLy4kKEBG
KS4wLm8KKwkkKExEKSAkKExERkxBR1MpIC1UIHhlbi5sZHMgLU4gLU1hcCAkKEBEKS8uJChA
RikuMS5tYXAgJChBTExfT0JKUykgXAorCSQoQEQpLy4kKEBGKS4wLm8gLW8gJChARCkvLiQo
QEYpLjEKKwkkKE5NKSAtbiAkKEBEKS8uJChARikuMSB8ICQoQkFTRURJUikvdG9vbHMvc3lt
Ym9scyA+JChARCkvLiQoQEYpLjEuUworCSQoTUFLRSkgLWYgJChCQVNFRElSKS9SdWxlcy5t
ayAkKEBEKS8uJChARikuMS5vCisJJChMRCkgJChMREZMQUdTKSAtVCB4ZW4ubGRzIC1OIC1N
YXAgJEAubWFwICQoQUxMX09CSlMpIFwKKwkkKEBEKS8uJChARikuMS5vIC1vICRACisJcm0g
LWYgJChARCkvLiQoQEYpLlswLTldKgorCisKK3hlbi5sZHM6ICQoQkFTRURJUikvaW5jbHVk
ZS9hc20vYXJjaAorCSQoQ0MpIC1FICQoQ0ZMQUdTKSAtUCAkKEFGTEFHUykgLW8gJEAgeGVu
L3hlbi5sZHMuUworCitjbGVhbjo6IEZPUkNFCisJcm0gLWYgeGVuLWJpbiB4ZW4tc3ltcyB4
ZW4ubGRzIGFzbS1vZmZzZXRzLnMKKwlybSAtZiAqLm8gJChUQVJHRVRfU1VCQVJDSCkvKi5v
IGxpYi8qLm8geGVuLyoubyB4ZW4ubGRzCisJcm0gLWYgJChCQVNFRElSKS9pbmNsdWRlL2Fz
bS1hcm0vYXJjaAorCXJtIC1mICQoQkFTRURJUikvaW5jbHVkZS9hc20KKworYXNtLW9mZnNl
dHMuczogJChCQVNFRElSKS9pbmNsdWRlL2FzbS9hcmNoCisJJChDQykgJChDRkxBR1MpIC1T
IC1vICRAIHhlbi9hc20tb2Zmc2V0cy5jCisKKyQoQkFTRURJUikvaW5jbHVkZS9hc20vYXJj
aDoKKwlbIC1lICQoQkFTRURJUikvaW5jbHVkZS9hc20vYXJjaCBdIHx8IFwKKwlsbiAtc2Yg
JChCQVNFRElSKS9pbmNsdWRlL2FzbS8kKFRBUkdFVF9TVUJBUkNIKSAkKEJBU0VESVIpL2lu
Y2x1ZGUvYXNtL2FyY2gKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vUnVs
ZXMubWsKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIveGVuL2FyY2gvYXJtL1J1bGVzLm1rCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDI1IEBACisjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjCisjIGFybS1zcGVjaWZpYyBkZWZpbml0aW9ucworCisjCisjIElmIHlvdSBjaGFu
Z2UgYW55IG9mIHRoZXNlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyB0aGVuIHlvdSBtdXN0Cisj
ICdtYWtlIGNsZWFuJyBiZWZvcmUgcmVidWlsZGluZy4KKyMKKworaWZlcSAoJChUQVJHRVRf
U1VCQVJDSCksKQorJChlcnJvciAiWEVOX1RBUkdFVF9TVUJBUkNIIG11c3QgYmUgc3VwcGxp
ZWQuIikKK2VuZGlmCisKK3hlbm9wcm9mIDo9IHkKKworIyBFYWNoIFNvQyBtYXkgaGF2ZSBp
dHMgb3duIGJ1aWxkIHJ1bGVzCistaW5jbHVkZSAkKEJBU0VESVIpL2FyY2gvJChUQVJHRVRf
QVJDSCkvJChUQVJHRVRfU1VCQVJDSCkvUnVsZXMubWsKKworQ0ZMQUdTCSs9IC1tYWJpPWFh
cGNzLWxpbnV4IC1tbm8tdGh1bWItaW50ZXJ3b3JrIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1v
bgorQ0ZMQUdTICArPSAtbm9zdGRpbmMgLWZuby1zdHJpY3QtYWxpYXNpbmcgLW1uby10aHVt
Yi1pbnRlcndvcmsKK0NGTEFHUyAgKz0gLWl3aXRocHJlZml4IGluY2x1ZGUgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlCitDRkxBR1MgICs9IC1JJChCQVNFRElSKS9pbmNsdWRlIC1JJChC
QVNFRElSKS9pbmNsdWRlL3NlY3VyaXR5IC1JJChCQVNFRElSKS9pbmNsdWRlL3NlY3VyaXR5
L2NyeXB0bworQ0ZMQUdTCSs9ICQoQ0ZMQUdTLXkpCisKKworCmRpZmYgLXIgZTcwMTQ2MWIx
MjUxIHhlbi9hcmNoL2FybS9saWIvTWFrZWZpbGUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9NYWtlZmlsZQlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMSBAQAorb2JqLXkg
Kz0gZGl2NjQubworb2JqLXkgKz0gbWVtemVyby5vIG1lbXNldC5vIG1lbWNweS5vIG1lbWNo
ci5vIG1lbW1vdmUubworb2JqLXkgKz0gc3RyY2hyLm8gbGliMWZ1bmNzLm8gCitvYmoteSAr
PSBjbGVhcmJpdC5vIHRlc3RjaGFuZ2ViaXQubyB0ZXN0Y2xlYXJiaXQubyB0ZXN0c2V0Yml0
Lm8gc2V0Yml0Lm8gZmluZGJpdC5vCitvYmoteSArPSBnZXR1c2VyLm8gcHV0dXNlci5vIHVh
Y2Nlc3Mubworb2JqLXkgKz0gYXNobGRpMy5vIGFzaHJkaTMubworCitvYmoteSArPSBtdWxk
aTMubworb2JqLXkgKz0gZGVsYXkubworb2JqLXkgKz0gbHNocmRpMy5vIGJwYWJpLm8gYnBh
YmktYXNtLm8KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL2FzaGxk
aTMuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi94ZW4vYXJjaC9hcm0vbGliL2FzaGxkaTMuUwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSw0NSBAQAorLyogQ29weXJpZ2h0IDE5OTUsIDE5OTYsIDE5OTgs
IDE5OTksIDIwMDAsIDIwMDMsIDIwMDQsIDIwMDUKKyAgIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbiwgSW5jLgorCitUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAordW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBH
TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkgdGhlCitGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9yIChhdCB5b3VyIG9wdGlv
bikgYW55CitsYXRlciB2ZXJzaW9uLgorCitJbiBhZGRpdGlvbiB0byB0aGUgcGVybWlzc2lv
bnMgaW4gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCB0aGUKK0ZyZWUgU29mdHdh
cmUgRm91bmRhdGlvbiBnaXZlcyB5b3UgdW5saW1pdGVkIHBlcm1pc3Npb24gdG8gbGluayB0
aGUKK2NvbXBpbGVkIHZlcnNpb24gb2YgdGhpcyBmaWxlIGludG8gY29tYmluYXRpb25zIHdp
dGggb3RoZXIgcHJvZ3JhbXMsCithbmQgdG8gZGlzdHJpYnV0ZSB0aG9zZSBjb21iaW5hdGlv
bnMgd2l0aG91dCBhbnkgcmVzdHJpY3Rpb24gY29taW5nCitmcm9tIHRoZSB1c2Ugb2YgdGhp
cyBmaWxlLiAgKFRoZSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHJlc3RyaWN0aW9ucworZG8g
YXBwbHkgaW4gb3RoZXIgcmVzcGVjdHM7IGZvciBleGFtcGxlLCB0aGV5IGNvdmVyIG1vZGlm
aWNhdGlvbiBvZgordGhlIGZpbGUsIGFuZCBkaXN0cmlidXRpb24gd2hlbiBub3QgbGlua2Vk
IGludG8gYSBjb21iaW5lCitleGVjdXRhYmxlLikKKworVGhpcyBmaWxlIGlzIGRpc3RyaWJ1
dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dAorV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl
IHRoZSBHTlUKK0dlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKwor
WW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UKK2Fsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBzZWUgdGhlIGZpbGUgQ09Q
WUlORy4gIElmIG5vdCwgd3JpdGUgdG8KK3RoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24s
IDUxIEZyYW5rbGluIFN0cmVldCwgRmlmdGggRmxvb3IsCitCb3N0b24sIE1BIDAyMTEwLTEz
MDEsIFVTQS4gICovCisKKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxh
c20vYXNtLW1hY3Jvcy5oPgorCisjZGVmaW5lIGFsIHIwCisjZGVmaW5lIGFoIHIxCisKK0VO
VFJZKF9fYXNobGRpMykKK0VOVFJZKF9fYWVhYmlfbGxzbCkKKworCXN1YnMJcjMsIHIyLCAj
MzIKKwlyc2IJaXAsIHIyLCAjMzIKKwltb3ZtaQlhaCwgYWgsIGxzbCByMgorCW1vdnBsCWFo
LCBhbCwgbHNsIHIzCisJb3JybWkJYWgsIGFoLCBhbCwgbHNyIGlwCisJbW92CWFsLCBhbCwg
bHNsIHIyCisJbW92CXBjLCBscgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2Fy
bS9saWIvYXNocmRpMy5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvYXNocmRpMy5TCUZyaSBGZWIgMDMgMTY6
MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQ2IEBACisvKiBDb3B5cmlnaHQgMTk5NSwg
MTk5NiwgMTk5OCwgMTk5OSwgMjAwMCwgMjAwMywgMjAwNCwgMjAwNQorICAgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1RoaXMgZmlsZSBpcyBmcmVlIHNvZnR3YXJlOyB5
b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5IGl0Cit1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0
aGUKK0ZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0
IHlvdXIgb3B0aW9uKSBhbnkKK2xhdGVyIHZlcnNpb24uCisKK0luIGFkZGl0aW9uIHRvIHRo
ZSBwZXJtaXNzaW9ucyBpbiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIHRoZQor
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uIGdpdmVzIHlvdSB1bmxpbWl0ZWQgcGVybWlzc2lv
biB0byBsaW5rIHRoZQorY29tcGlsZWQgdmVyc2lvbiBvZiB0aGlzIGZpbGUgaW50byBjb21i
aW5hdGlvbnMgd2l0aCBvdGhlciBwcm9ncmFtcywKK2FuZCB0byBkaXN0cmlidXRlIHRob3Nl
IGNvbWJpbmF0aW9ucyB3aXRob3V0IGFueSByZXN0cmljdGlvbiBjb21pbmcKK2Zyb20gdGhl
IHVzZSBvZiB0aGlzIGZpbGUuICAoVGhlIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgcmVzdHJp
Y3Rpb25zCitkbyBhcHBseSBpbiBvdGhlciByZXNwZWN0czsgZm9yIGV4YW1wbGUsIHRoZXkg
Y292ZXIgbW9kaWZpY2F0aW9uIG9mCit0aGUgZmlsZSwgYW5kIGRpc3RyaWJ1dGlvbiB3aGVu
IG5vdCBsaW5rZWQgaW50byBhIGNvbWJpbmUKK2V4ZWN1dGFibGUuKQorCitUaGlzIGZpbGUg
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0
CitXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJh
bnR5IG9mCitNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV
UlBPU0UuICBTZWUgdGhlIEdOVQorR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBk
ZXRhaWxzLgorCitZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZQorYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IHNlZSB0
aGUgZmlsZSBDT1BZSU5HLiAgSWYgbm90LCB3cml0ZSB0bwordGhlIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbiwgNTEgRnJhbmtsaW4gU3RyZWV0LCBGaWZ0aCBGbG9vciwKK0Jvc3Rvbiwg
TUEgMDIxMTAtMTMwMSwgVVNBLiAgKi8KKworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgor
I2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisK
KyNkZWZpbmUgYWwgcjAKKyNkZWZpbmUgYWggcjEKKworRU5UUlkoX19hc2hyZGkzKQorRU5U
UlkoX19hZWFiaV9sYXNyKQorCisJc3VicwlyMywgcjIsICMzMgorCXJzYglpcCwgcjIsICMz
MgorCW1vdm1pCWFsLCBhbCwgbHNyIHIyCisJbW92cGwJYWwsIGFoLCBhc3IgcjMKKwlvcnJt
aQlhbCwgYWwsIGFoLCBsc2wgaXAKKwltb3YJYWgsIGFoLCBhc3IgcjIKKwltb3YJcGMsIGxy
CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL2xpYi9icGFiaS1hc20uUwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
YXJjaC9hcm0vbGliL2JwYWJpLWFzbS5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDU1IEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUg
PGFzbS9hc20tbWFjcm9zLmg+CisKKyNpZmRlZiBfX0FSTUVCX18KKyNkZWZpbmUgeHhoIHIw
CisjZGVmaW5lIHh4bCByMQorI2RlZmluZSB5eWggcjIKKyNkZWZpbmUgeXlsIHIzCisjZWxz
ZQorI2RlZmluZSB4eGggcjEKKyNkZWZpbmUgeHhsIHIwCisjZGVmaW5lIHl5aCByMworI2Rl
ZmluZSB5eWwgcjIKKyNlbmRpZgkKKwkKKyNpZiAwCitFTlRSWShfX2FlYWJpX2xkaXZtb2Qp
CisJc3RtZmQJc3AhLCB7cjQtcjcsIHIxMSwgcjE0fQorCW1vdglyNiwgcjAKKwltb3YJcjcs
IHIxCisJbW92CXI1LCByMgorCW1vdglyNCwgcjMKKworCWJsCV9fZGl2ZGkzCisKKwltdWwJ
cjQsIHIwLCByNAorCW1sYQlyMTIsIHI1LCByMSwgcjQKKworCXVtdWxsCXIyLCByMywgcjAs
IHI1CisJYWRkCXIzLCByMTIsIHIzCisJc3VicwlyMiwgcjUsIHIyCisJc2JjCXIzLCByNywg
cjMKKwlsZG1mZAlzcCEsIHtyNC1yNywgcjExLCByMTR9CisKKwlieAlyMTQKKyNlbmRpZgor
CitFTlRSWShfX2FlYWJpX2xkaXZtb2QpCisJc3ViCXNwLCBzcCwgIzgKKwlzdG1mZAlzcCEs
IHtzcCwgbHJ9CisJYmwJX19nbnVfbGRpdm1vZF9oZWxwZXIgKFBMVCkKKwlsZHIJbHIsIFtz
cCwgIzRdCisJYWRkCXNwLCBzcCwgIzgKKwlsZG1mZAlzcCEsIHtyMiwgcjN9CisJYngJbHIK
KwkKK0VOVFJZKF9fYWVhYmlfdWxkaXZtb2QpCisJc3ViCXNwLCBzcCwgIzgKKwlzdG1mZAlz
cCEsIHtzcCwgbHJ9CisJYmwJX19nbnVfdWxkaXZtb2RfaGVscGVyIChQTFQpCisJbGRyCWxy
LCBbc3AsICM0XQorCWFkZAlzcCwgc3AsICM4CisJbGRtZmQJc3AhLCB7cjIsIHIzfQorCWJ4
CWxyCisJCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvYnBhYmkuYwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
YXJjaC9hcm0vbGliL2JwYWJpLmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBA
IC0wLDAgKzEsNTEgQEAKKy8qIE1pc2NlbGxhbmVvdXMgQlBBQkkgZnVuY3Rpb25zLgorCisg
ICBDb3B5cmlnaHQgKEMpIDIwMDMsIDIwMDQgIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwg
SW5jLgorICAgQ29udHJpYnV0ZWQgYnkgQ29kZVNvdXJjZXJ5LCBMTEMuCisKKyAgIFRoaXMg
ZmlsZSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5IGl0CisgICB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0aGUKKyAgIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkKKyAgIGxh
dGVyIHZlcnNpb24uCisKKyAgIEluIGFkZGl0aW9uIHRvIHRoZSBwZXJtaXNzaW9ucyBpbiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIHRoZQorICAgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uIGdpdmVzIHlvdSB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBsaW5rIHRoZQor
ICAgY29tcGlsZWQgdmVyc2lvbiBvZiB0aGlzIGZpbGUgaW50byBjb21iaW5hdGlvbnMgd2l0
aCBvdGhlciBwcm9ncmFtcywKKyAgIGFuZCB0byBkaXN0cmlidXRlIHRob3NlIGNvbWJpbmF0
aW9ucyB3aXRob3V0IGFueSByZXN0cmljdGlvbiBjb21pbmcKKyAgIGZyb20gdGhlIHVzZSBv
ZiB0aGlzIGZpbGUuICAoVGhlIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgcmVzdHJpY3Rpb25z
CisgICBkbyBhcHBseSBpbiBvdGhlciByZXNwZWN0czsgZm9yIGV4YW1wbGUsIHRoZXkgY292
ZXIgbW9kaWZpY2F0aW9uIG9mCisgICB0aGUgZmlsZSwgYW5kIGRpc3RyaWJ1dGlvbiB3aGVu
IG5vdCBsaW5rZWQgaW50byBhIGNvbWJpbmUKKyAgIGV4ZWN1dGFibGUuKQorCisgICBUaGlz
IGZpbGUgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1
bCwgYnV0CisgICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs
aWVkIHdhcnJhbnR5IG9mCisgICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQ
QVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorICAgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorCisgICBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg
YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICAgYWxvbmcgd2l0
aCB0aGlzIHByb2dyYW07IHNlZSB0aGUgZmlsZSBDT1BZSU5HLiAgSWYgbm90LCB3cml0ZSB0
bworICAgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgNTkgVGVtcGxlIFBsYWNlIC0g
U3VpdGUgMzMwLAorICAgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuICAqLworCitleHRl
cm4gbG9uZyBsb25nIF9fZGl2ZGkzIChsb25nIGxvbmcsIGxvbmcgbG9uZyk7CitleHRlcm4g
dW5zaWduZWQgbG9uZyBsb25nIF9fdWRpdmRpMyAodW5zaWduZWQgbG9uZyBsb25nLCB1bnNp
Z25lZCBsb25nIGxvbmcpOworCitsb25nIGxvbmcgX19nbnVfbGRpdm1vZF9oZWxwZXIgKGxv
bmcgbG9uZyBhLCBsb25nIGxvbmcgYiwgbG9uZyBsb25nICpyZW1haW5kZXIpCit7CisJbG9u
ZyBsb25nIHF1b3RpZW50OworCisJcXVvdGllbnQgPSBfX2RpdmRpMyAoYSwgYik7CisJKnJl
bWFpbmRlciA9IGEgLSBiICogcXVvdGllbnQ7CisJcmV0dXJuIHF1b3RpZW50OworfQorCit1
bnNpZ25lZCBsb25nIGxvbmcgX19nbnVfdWxkaXZtb2RfaGVscGVyICh1bnNpZ25lZCBsb25n
IGxvbmcgYSwgdW5zaWduZWQgbG9uZyBsb25nIGIsIHVuc2lnbmVkIGxvbmcgbG9uZyAqcmVt
YWluZGVyKQoreworCXVuc2lnbmVkIGxvbmcgbG9uZyBxdW90aWVudDsKKworCXF1b3RpZW50
ID0gX191ZGl2ZGkzIChhLCBiKTsKKwkqcmVtYWluZGVyID0gYSAtIGIgKiBxdW90aWVudDsK
KworCXJldHVybiBxdW90aWVudDsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJj
aC9hcm0vbGliL2NsZWFyYml0LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9jbGVhcmJpdC5TCUZyaSBGZWIg
MDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDI0IEBACisjaW5jbHVkZSA8eGVu
L2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KKyNpbmNsdWRlIDxhc20v
YXNtLW1hY3Jvcy5oPgorCisgICAgICAgICAgICAgICAgLnRleHQKKworLyoKKyAqIFB1cnBv
c2UgIDogRnVuY3Rpb24gdG8gY2xlYXIgYSBiaXQKKyAqIFByb3RvdHlwZTogaW50IGNsZWFy
X2JpdChpbnQgYml0LCB2b2lkICphZGRyKQorICovCitFTlRSWShfY2xlYXJfYml0X2JlKQor
CQllb3IJcjAsIHIwLCAjMHgxOAkJQCBiaWcgZW5kaWFuIGJ5dGUgb3JkZXJpbmcKK0VOVFJZ
KF9jbGVhcl9iaXRfbGUpCisJCWFuZAlyMiwgcjAsICM3CisJCW1vdglyMywgIzEKKwkJbW92
CXIzLCByMywgbHNsIHIyCisJCXNhdmVfYW5kX2Rpc2FibGVfaXJxcyBpcCwgcjIKKwkJbGRy
YglyMiwgW3IxLCByMCwgbHNyICMzXQorCQliaWMJcjIsIHIyLCByMworCQlzdHJiCXIyLCBb
cjEsIHIwLCBsc3IgIzNdCisJCXJlc3RvcmVfaXJxcyBpcAorCQltb3YJcGMsbHIKKworCmRp
ZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvY29weV90ZW1wbGF0ZS5TCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9h
cmNoL2FybS9saWIvY29weV90ZW1wbGF0ZS5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiAr
MDkwMApAQCAtMCwwICsxLDI1NSBAQAorLyoKKyAqICBsaW51eC9hcmNoL2FybS9saWIvY29w
eV90ZW1wbGF0ZS5zCisgKgorICogIENvZGUgdGVtcGxhdGUgZm9yIG9wdGltaXplZCBtZW1v
cnkgY29weSBmdW5jdGlvbnMKKyAqCisgKiAgQXV0aG9yOglOaWNvbGFzIFBpdHJlCisgKiAg
Q3JlYXRlZDoJU2VwIDI4LCAyMDA1CisgKiAgQ29weXJpZ2h0OglNb250YVZpc3RhIFNvZnR3
YXJlLCBJbmMuCisgKgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIgYXMKKyAq
ICBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqLworCisv
KgorICogVGhpcyBjYW4gYmUgdXNlZCB0byBlbmFibGUgY29kZSB0byBjYWNoZWxpbmUgYWxp
Z24gdGhlIHNvdXJjZSBwb2ludGVyLgorICogRXhwZXJpbWVudHMgb24gdGVzdGVkIGFyY2hp
dGVjdHVyZXMgKFN0cm9uZ0FSTSBhbmQgWFNjYWxlKSBkaWRuJ3Qgc2hvdworICogdGhpcyBh
IHdvcnRod2hpbGUgdGhpbmcgdG8gZG8uICBUaGF0IG1pZ2h0IGJlIGRpZmZlcmVudCBpbiB0
aGUgZnV0dXJlLgorICovCisvLyNkZWZpbmUgQ0FMR04oY29kZS4uLikJY29kZQorI2RlZmlu
ZSBDQUxHTihjb2RlLi4uKQorCisvKgorICogVGhlb3J5IG9mIG9wZXJhdGlvbgorICogLS0t
LS0tLS0tLS0tLS0tLS0tLQorICoKKyAqIFRoaXMgZmlsZSBwcm92aWRlcyB0aGUgY29yZSBj
b2RlIGZvciBhIGZvcndhcmQgbWVtb3J5IGNvcHkgdXNlZCBpbgorICogdGhlIGltcGxlbWVu
dGF0aW9uIG9mIG1lbWNvcHkoKSwgY29weV90b191c2VyKCkgYW5kIGNvcHlfZnJvbV91c2Vy
KCkuCisgKgorICogVGhlIGluY2x1ZGluZyBmaWxlIG11c3QgZGVmaW5lIHRoZSBmb2xsb3dp
bmcgYWNjZXNzb3IgbWFjcm9zCisgKiBhY2NvcmRpbmcgdG8gdGhlIG5lZWQgb2YgdGhlIGdp
dmVuIGZ1bmN0aW9uOgorICoKKyAqIGxkcjF3IHB0ciByZWcgYWJvcnQKKyAqCisgKglUaGlz
IGxvYWRzIG9uZSB3b3JkIGZyb20gJ3B0cicsIHN0b3JlcyBpdCBpbiAncmVnJyBhbmQgaW5j
cmVtZW50cworICoJJ3B0cicgdG8gdGhlIG5leHQgd29yZC4gVGhlICdhYm9ydCcgYXJndW1l
bnQgaXMgdXNlZCBmb3IgZml4dXAgdGFibGVzLgorICoKKyAqIGxkcjR3IHB0ciByZWcxIHJl
ZzIgcmVnMyByZWc0IGFib3J0CisgKiBsZHI4dyBwdHIsIHJlZzEgcmVnMiByZWczIHJlZzQg
cmVnNSByZWc2IHJlZzcgcmVnOCBhYm9ydAorICoKKyAqCVRoaXMgbG9hZHMgZm91ciBvciBl
aWdodCB3b3JkcyBzdGFydGluZyBmcm9tICdwdHInLCBzdG9yZXMgdGhlbQorICoJaW4gcHJv
dmlkZWQgcmVnaXN0ZXJzIGFuZCBpbmNyZW1lbnRzICdwdHInIHBhc3QgdGhvc2Ugd29yZHMu
CisgKglUaGUnYWJvcnQnIGFyZ3VtZW50IGlzIHVzZWQgZm9yIGZpeHVwIHRhYmxlcy4KKyAq
CisgKiBsZHIxYiBwdHIgcmVnIGNvbmQgYWJvcnQKKyAqCisgKglTaW1pbGFyIHRvIGxkcjF3
LCBidXQgaXQgbG9hZHMgYSBieXRlIGFuZCBpbmNyZW1lbnRzICdwdHInIG9uZSBieXRlLgor
ICoJSXQgYWxzbyBtdXN0IGFwcGx5IHRoZSBjb25kaXRpb24gY29kZSBpZiBwcm92aWRlZCwg
b3RoZXJ3aXNlIHRoZQorICoJImFsIiBjb25kaXRpb24gaXMgYXNzdW1lZCBieSBkZWZhdWx0
LgorICoKKyAqIHN0cjF3IHB0ciByZWcgYWJvcnQKKyAqIHN0cjh3IHB0ciByZWcxIHJlZzIg
cmVnMyByZWc0IHJlZzUgcmVnNiByZWc3IHJlZzggYWJvcnQKKyAqIHN0cjFiIHB0ciByZWcg
Y29uZCBhYm9ydAorICoKKyAqCVNhbWUgYXMgdGhlaXIgbGRyKiBjb3VudGVycGFydHMsIGJ1
dCBkYXRhIGlzIHN0b3JlZCB0byAncHRyJyBsb2NhdGlvbgorICoJcmF0aGVyIHRoYW4gYmVp
bmcgbG9hZGVkLgorICoKKyAqIGVudGVyIHJlZzEgcmVnMgorICoKKyAqCVByZXNlcnZlIHRo
ZSBwcm92aWRlZCByZWdpc3RlcnMgb24gdGhlIHN0YWNrIHBsdXMgYW55IGFkZGl0aW9uYWwK
KyAqCWRhdGEgYXMgbmVlZGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbiBpbmNsdWRpbmcgdGhp
cyBjb2RlLiBDYWxsZWQKKyAqCXVwb24gY29kZSBlbnRyeS4KKyAqCisgKiBleGl0IHJlZzEg
cmVnMgorICoKKyAqCVJlc3RvcmUgcmVnaXN0ZXJzIHdpdGggdGhlIHZhbHVlcyBwcmV2aW91
c2x5IHNhdmVkIHdpdGggdGhlCisgKgkncHJlc2VydicgbWFjcm8uIENhbGxlZCB1cG9uIGNv
ZGUgdGVybWluYXRpb24uCisgKi8KKworCisJCWVudGVyCXI0LCBscgorCisJCXN1YnMJcjIs
IHIyLCAjNAorCQlibHQJOGYKKwkJYW5kcwlpcCwgcjAsICMzCisJCXBsZAlbcjEsICMwXQor
CQlibmUJOWYKKwkJYW5kcwlpcCwgcjEsICMzCisJCWJuZQkxMGYKKworMToJCXN1YnMJcjIs
IHIyLCAjKDI4KQorCQlzdG1mZAlzcCEsIHtyNSAtIHI4fQorCQlibHQJNWYKKworCUNBTEdO
KAlhbmRzCWlwLCByMSwgIzMxCQkpCisJQ0FMR04oCXJzYglyMywgaXAsICMzMgkJKQorCUNB
TEdOKAlzYmNuZXMJcjQsIHIzLCByMgkJKSAgQCBDIGlzIGFsd2F5cyBzZXQgaGVyZQorCUNB
TEdOKAliY3MJMmYJCQkpCisJQ0FMR04oCWFkcglyNCwgNmYJCQkpCisJQ0FMR04oCXN1YnMJ
cjIsIHIyLCByMwkJKSAgQCBDIGdldHMgc2V0CisJQ0FMR04oCWFkZAlwYywgcjQsIGlwCQkp
CisKKwkJcGxkCVtyMSwgIzBdCisyOgkJc3VicwlyMiwgcjIsICM5NgorCQlwbGQJW3IxLCAj
MjhdCisJCWJsdAk0ZgorCQlwbGQJW3IxLCAjNjBdCisJCXBsZAlbcjEsICM5Ml0KKworMzoJ
CXBsZAlbcjEsICMxMjRdCis0OgkJbGRyOHcJcjEsIHIzLCByNCwgcjUsIHI2LCByNywgcjgs
IGlwLCBsciwgYWJvcnQ9MjBmCisJCXN1YnMJcjIsIHIyLCAjMzIKKwkJc3RyOHcJcjAsIHIz
LCByNCwgcjUsIHI2LCByNywgcjgsIGlwLCBsciwgYWJvcnQ9MjBmCisJCWJnZQkzYgorCQlj
bW4JcjIsICM5NgkKKwkJYmdlCTRiCisKKzU6CQlhbmRzCWlwLCByMiwgIzI4CisJCXJzYglp
cCwgaXAsICMzMgorCQlhZGRuZQlwYywgcGMsIGlwCQlAIEMgaXMgYWx3YXlzIGNsZWFyIGhl
cmUKKwkJYgk3ZgorNjoJCW5vcAorCQlsZHIxdwlyMSwgcjMsIGFib3J0PTIwZgorCQlsZHIx
dwlyMSwgcjQsIGFib3J0PTIwZgorCQlsZHIxdwlyMSwgcjUsIGFib3J0PTIwZgorCQlsZHIx
dwlyMSwgcjYsIGFib3J0PTIwZgorCQlsZHIxdwlyMSwgcjcsIGFib3J0PTIwZgorCQlsZHIx
dwlyMSwgcjgsIGFib3J0PTIwZgorCQlsZHIxdwlyMSwgbHIsIGFib3J0PTIwZgorCisJCWFk
ZAlwYywgcGMsIGlwCisJCW5vcAorCQlub3AKKwkJc3RyMXcJcjAsIHIzLCBhYm9ydD0yMGYK
KwkJc3RyMXcJcjAsIHI0LCBhYm9ydD0yMGYKKwkJc3RyMXcJcjAsIHI1LCBhYm9ydD0yMGYK
KwkJc3RyMXcJcjAsIHI2LCBhYm9ydD0yMGYKKwkJc3RyMXcJcjAsIHI3LCBhYm9ydD0yMGYK
KwkJc3RyMXcJcjAsIHI4LCBhYm9ydD0yMGYKKwkJc3RyMXcJcjAsIGxyLCBhYm9ydD0yMGYK
KworCUNBTEdOKAliY3MJMmIJCQkpCisKKzc6CQlsZG1mZAlzcCEsIHtyNSAtIHI4fQorCis4
OgkJbW92cwlyMiwgcjIsIGxzbCAjMzEKKwkJbGRyMWIJcjEsIHIzLCBuZSwgYWJvcnQ9MjFm
CisJCWxkcjFiCXIxLCByNCwgY3MsIGFib3J0PTIxZgorCQlsZHIxYglyMSwgaXAsIGNzLCBh
Ym9ydD0yMWYKKwkJc3RyMWIJcjAsIHIzLCBuZSwgYWJvcnQ9MjFmCisJCXN0cjFiCXIwLCBy
NCwgY3MsIGFib3J0PTIxZgorCQlzdHIxYglyMCwgaXAsIGNzLCBhYm9ydD0yMWYKKworCQll
eGl0CXI0LCBwYworCis5OgkJcnNiCWlwLCBpcCwgIzQKKwkJY21wCWlwLCAjMgorCQlsZHIx
YglyMSwgcjMsIGd0LCBhYm9ydD0yMWYKKwkJbGRyMWIJcjEsIHI0LCBnZSwgYWJvcnQ9MjFm
CisJCWxkcjFiCXIxLCBsciwgYWJvcnQ9MjFmCisJCXN0cjFiCXIwLCByMywgZ3QsIGFib3J0
PTIxZgorCQlzdHIxYglyMCwgcjQsIGdlLCBhYm9ydD0yMWYKKwkJc3VicwlyMiwgcjIsIGlw
CisJCXN0cjFiCXIwLCBsciwgYWJvcnQ9MjFmCisJCWJsdAk4YgorCQlhbmRzCWlwLCByMSwg
IzMKKwkJYmVxCTFiCisKKzEwOgkJYmljCXIxLCByMSwgIzMKKwkJY21wCWlwLCAjMgorCQls
ZHIxdwlyMSwgbHIsIGFib3J0PTIxZgorCQliZXEJMTdmCisJCWJndAkxOGYKKworCisJCS5t
YWNybwlmb3J3YXJkX2NvcHlfc2hpZnQgcHVsbCBwdXNoCisKKwkJc3VicwlyMiwgcjIsICMy
OAorCQlibHQJMTRmCisKKwlDQUxHTigJYW5kcwlpcCwgcjEsICMzMQkJKQorCUNBTEdOKAly
c2IJaXAsIGlwLCAjMzIJCSkKKwlDQUxHTigJc2JjbmVzCXI0LCBpcCwgcjIJCSkgIEAgQyBp
cyBhbHdheXMgc2V0IGhlcmUKKwlDQUxHTigJc3ViY2MJcjIsIHIyLCBpcAkJKQorCUNBTEdO
KAliY2MJMTVmCQkJKQorCisxMToJCXN0bWZkCXNwISwge3I1IC0gcjl9CisKKwkJcGxkCVty
MSwgIzBdCisJCXN1YnMJcjIsIHIyLCAjOTYKKwkJcGxkCVtyMSwgIzI4XQorCQlibHQJMTNm
CisJCXBsZAlbcjEsICM2MF0KKwkJcGxkCVtyMSwgIzkyXQorCisxMjoJCXBsZAlbcjEsICMx
MjRdCisxMzoJCWxkcjR3CXIxLCByNCwgcjUsIHI2LCByNywgYWJvcnQ9MTlmCisJCW1vdgly
MywgbHIsIHB1bGwgI1xwdWxsCisJCXN1YnMJcjIsIHIyLCAjMzIKKwkJbGRyNHcJcjEsIHI4
LCByOSwgaXAsIGxyLCBhYm9ydD0xOWYKKwkJb3JyCXIzLCByMywgcjQsIHB1c2ggI1xwdXNo
CisJCW1vdglyNCwgcjQsIHB1bGwgI1xwdWxsCisJCW9ycglyNCwgcjQsIHI1LCBwdXNoICNc
cHVzaAorCQltb3YJcjUsIHI1LCBwdWxsICNccHVsbAorCQlvcnIJcjUsIHI1LCByNiwgcHVz
aCAjXHB1c2gKKwkJbW92CXI2LCByNiwgcHVsbCAjXHB1bGwKKwkJb3JyCXI2LCByNiwgcjcs
IHB1c2ggI1xwdXNoCisJCW1vdglyNywgcjcsIHB1bGwgI1xwdWxsCisJCW9ycglyNywgcjcs
IHI4LCBwdXNoICNccHVzaAorCQltb3YJcjgsIHI4LCBwdWxsICNccHVsbAorCQlvcnIJcjgs
IHI4LCByOSwgcHVzaCAjXHB1c2gKKwkJbW92CXI5LCByOSwgcHVsbCAjXHB1bGwKKwkJb3Jy
CXI5LCByOSwgaXAsIHB1c2ggI1xwdXNoCisJCW1vdglpcCwgaXAsIHB1bGwgI1xwdWxsCisJ
CW9ycglpcCwgaXAsIGxyLCBwdXNoICNccHVzaAorCQlzdHI4dwlyMCwgcjMsIHI0LCByNSwg
cjYsIHI3LCByOCwgcjksIGlwLCAsIGFib3J0PTE5ZgorCQliZ2UJMTJiCisJCWNtbglyMiwg
Izk2CQorCQliZ2UJMTNiCisKKwkJbGRtZmQJc3AhLCB7cjUgLSByOX0KKworMTQ6CQlhbmRz
CWlwLCByMiwgIzI4CisJCWJlcQkxNmYKKworMTU6CQltb3YJcjMsIGxyLCBwdWxsICNccHVs
bAorCQlsZHIxdwlyMSwgbHIsIGFib3J0PTIxZgorCQlzdWJzCWlwLCBpcCwgIzQKKwkJb3Jy
CXIzLCByMywgbHIsIHB1c2ggI1xwdXNoCisJCXN0cjF3CXIwLCByMywgYWJvcnQ9MjFmCisJ
CWJndAkxNWIKKwlDQUxHTigJY21wCXIyLCAjMAkJCSkKKwlDQUxHTigJYmdlCTExYgkJCSkK
KworMTY6CQlzdWIJcjEsIHIxLCAjKFxwdXNoIC8gOCkKKwkJYgk4YgorCisJCS5lbmRtCisK
KworCQlmb3J3YXJkX2NvcHlfc2hpZnQJcHVsbD04CXB1c2g9MjQKKworMTc6CQlmb3J3YXJk
X2NvcHlfc2hpZnQJcHVsbD0xNglwdXNoPTE2CisKKzE4OgkJZm9yd2FyZF9jb3B5X3NoaWZ0
CXB1bGw9MjQJcHVzaD04CisKKworLyoKKyAqIEFib3J0IHByZWFtYmxlIGFuZCBjb21wbGV0
aW9uIG1hY3Jvcy4KKyAqIElmIGEgZml4dXAgaGFuZGxlciBpcyByZXF1aXJlZCB0aGVuIHRo
b3NlIG1hY3JvcyBtdXN0IHN1cnJvdW5kIGl0LgorICogSXQgaXMgYXNzdW1lZCB0aGF0IHRo
ZSBmaXh1cCBjb2RlIHdpbGwgaGFuZGxlIHRoZSBwcml2YXRlIHBhcnQgb2YKKyAqIHRoZSBl
eGl0IG1hY3JvLgorICovCisKKwkubWFjcm8JY29weV9hYm9ydF9wcmVhbWJsZQorMTk6CWxk
bWZkCXNwISwge3I1IC0gcjl9CisJYgkyMWYKKzIwOglsZG1mZAlzcCEsIHtyNSAtIHI4fQor
MjE6CisJLmVuZG0KKworCS5tYWNybwljb3B5X2Fib3J0X2VuZAorCWxkbWZkCXNwISwge3I0
LCBwY30KKwkuZW5kbQorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIv
ZGVsYXkuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi94ZW4vYXJjaC9hcm0vbGliL2RlbGF5LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEy
ICswOTAwCkBAIC0wLDAgKzEsNyBAQAorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNs
dWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisJCS50ZXh0CisKK0VOVFJZKF91ZGVsYXkpCisJ
bW92CXBjLGxyCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvZGl2NjQu
UwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vYXJjaC9hcm0vbGliL2RpdjY0LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAw
CkBAIC0wLDAgKzEsMTk5IEBACisvKgorICogIGxpbnV4L2FyY2gvYXJtL2xpYi9kaXY2NC5T
CisgKgorICogIE9wdGltaXplZCBjb21wdXRhdGlvbiBvZiA2NC1iaXQgZGl2aWRlbmQgLyAz
Mi1iaXQgZGl2aXNvciAgCisgKgorICogIEF1dGhvcjoJTmljb2xhcyBQaXRyZQorICogIENy
ZWF0ZWQ6CU9jdCA1LCAyMDAzCisgKiAgQ29weXJpZ2h0OglNb250YSBWaXN0YSBTb2Z0d2Fy
ZSwgSW5jLgorICoKKyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0IHVuZGVyIHRoZSB0ZXJt
cyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzCisgKiAg
cHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKi8KKyNpbmNs
dWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKyNpZmRl
ZiBfX0FSTUVCX18KKyNkZWZpbmUgeGggcjAKKyNkZWZpbmUgeGwgcjEKKyNkZWZpbmUgeWgg
cjIKKyNkZWZpbmUgeWwgcjMKKyNlbHNlCisjZGVmaW5lIHhsIHIwCisjZGVmaW5lIHhoIHIx
CisjZGVmaW5lIHlsIHIyCisjZGVmaW5lIHloIHIzCisjZW5kaWYKKworLyoKKyAqIF9fZG9f
ZGl2NjQ6IHBlcmZvcm0gYSBkaXZpc2lvbiB3aXRoIDY0LWJpdCBkaXZpZGVuZCBhbmQgMzIt
Yml0IGRpdmlzb3IuCisgKgorICogTm90ZTogQ2FsbGluZyBjb252ZW50aW9uIGlzIHRvdGFs
bHkgbm9uIHN0YW5kYXJkIGZvciBvcHRpbWFsIGNvZGUuCisgKiAgICAgICBUaGlzIGlzIG1l
YW50IHRvIGJlIHVzZWQgYnkgZG9fZGl2KCkgZnJvbSBpbmNsdWRlL2FzbS9kaXY2NC5oIG9u
bHkuCisgKgorICogSW5wdXQgcGFyYW1ldGVyczoKKyAqIAl4aC14bAk9IGRpdmlkZW5kIChj
bG9iYmVyZWQpCisgKiAJcjQJPSBkaXZpc29yIChwcmVzZXJ2ZWQpCisgKgorICogT3V0cHV0
IHZhbHVlczoKKyAqIAl5aC15bAk9IHJlc3VsdAorICogCXhoCT0gcmVtYWluZGVyCisgKgor
ICogQ2xvYmJlcmVkIHJlZ3M6IHhsLCBpcAorICovCisKK0VOVFJZKF9fZG9fZGl2NjQpCisK
KwlAIFRlc3QgZm9yIGVhc3kgcGF0aHMgZmlyc3QuCisJc3VicwlpcCwgcjQsICMxCisJYmxz
CTlmCQkJQCBkaXZpc29yIGlzIDAgb3IgMQorCXRzdAlpcCwgcjQKKwliZXEJOGYJCQlAIGRp
dmlzb3IgaXMgcG93ZXIgb2YgMgorCisJQCBTZWUgaWYgd2UgbmVlZCB0byBoYW5kbGUgdXBw
ZXIgMzItYml0IHJlc3VsdC4KKwljbXAJeGgsIHI0CisJbW92CXloLCAjMAorCWJsbwkzZgor
CisJQCBBbGlnbiBkaXZpc29yIHdpdGggdXBwZXIgcGFydCBvZiBkaXZpZGVuZC4KKwlAIFRo
ZSBhbGlnbmVkIGRpdmlzb3IgaXMgc3RvcmVkIGluIHlsIHByZXNlcnZpbmcgdGhlIG9yaWdp
bmFsLgorCUAgVGhlIGJpdCBwb3NpdGlvbiBpcyBzdG9yZWQgaW4gaXAuCisKKyNpZiBfX0xJ
TlVYX0FSTV9BUkNIX18gPj0gNQorCisJY2x6CXlsLCByNAorCWNseglpcCwgeGgKKwlzdWIJ
eWwsIHlsLCBpcAorCW1vdglpcCwgIzEKKwltb3YJaXAsIGlwLCBsc2wgeWwKKwltb3YJeWws
IHI0LCBsc2wgeWwKKworI2Vsc2UKKworCW1vdgl5bCwgcjQKKwltb3YJaXAsICMxCisxOglj
bXAJeWwsICMweDgwMDAwMDAwCisJY21wY2MJeWwsIHhoCisJbW92Y2MJeWwsIHlsLCBsc2wg
IzEKKwltb3ZjYwlpcCwgaXAsIGxzbCAjMQorCWJjYwkxYgorCisjZW5kaWYKKworCUAgVGhl
IGRpdmlzaW9uIGxvb3AgZm9yIG5lZWRlZCB1cHBlciBiaXQgcG9zaXRpb25zLgorIAlAIEJy
ZWFrIG91dCBlYXJseSBpZiBkaXZpZGVuZCByZWFjaGVzIDAuCisyOgljbXAJeGgsIHlsCisJ
b3JyY3MJeWgsIHloLCBpcAorCXN1YmNzcwl4aCwgeGgsIHlsCisJbW92bmVzCWlwLCBpcCwg
bHNyICMxCisJbW92CXlsLCB5bCwgbHNyICMxCisJYm5lCTJiCisKKwlAIFNlZSBpZiB3ZSBu
ZWVkIHRvIGhhbmRsZSBsb3dlciAzMi1iaXQgcmVzdWx0LgorMzoJY21wCXhoLCAjMAorCW1v
dgl5bCwgIzAKKwljbXBlcQl4bCwgcjQKKwltb3Zsbwl4aCwgeGwKKwltb3ZsbwlwYywgbHIK
KworCUAgVGhlIGRpdmlzaW9uIGxvb3AgZm9yIGxvd2VyIGJpdCBwb3NpdGlvbnMuCisJQCBI
ZXJlIHdlIHNoaWZ0IHJlbWFpbmVyIGJpdHMgbGVmdHdhcmRzIHJhdGhlciB0aGFuIG1vdmlu
ZyB0aGUKKwlAIGRpdmlzb3IgZm9yIGNvbXBhcmlzb25zLCBjb25zaWRlcmluZyB0aGUgY2Fy
cnktb3V0IGJpdCBhcyB3ZWxsLgorCW1vdglpcCwgIzB4ODAwMDAwMDAKKzQ6CW1vdnMJeGws
IHhsLCBsc2wgIzEKKwlhZGNzCXhoLCB4aCwgeGgKKwliZXEJNmYKKwljbXBjYwl4aCwgcjQK
KzU6CW9ycmNzCXlsLCB5bCwgaXAKKwlzdWJjcwl4aCwgeGgsIHI0CisJbW92cwlpcCwgaXAs
IGxzciAjMQorCWJuZQk0YgorCW1vdglwYywgbHIKKworCUAgVGhlIHRvcCBwYXJ0IG9mIHJl
bWFpbmRlciBiZWNhbWUgemVyby4gIElmIGNhcnJ5IGlzIHNldAorCUAgKHRoZSAzM3RoIGJp
dCkgdGhpcyBpcyBhIGZhbHNlIHBvc2l0aXZlIHNvIHJlc3VtZSB0aGUgbG9vcC4KKwlAIE90
aGVyd2lzZSwgaWYgbG93ZXIgcGFydCBpcyBhbHNvIG51bGwgdGhlbiB3ZSBhcmUgZG9uZS4K
KzY6CWJjcwk1YgorCWNtcAl4bCwgIzAKKwltb3ZlcQlwYywgbHIKKworCUAgV2Ugc3RpbGwg
aGF2ZSByZW1haW5lciBiaXRzIGluIHRoZSBsb3cgcGFydC4gIEJyaW5nIHRoZW0gdXAuCisK
KyNpZiBfX0xJTlVYX0FSTV9BUkNIX18gPj0gNQorCisJY2x6CXhoLCB4bAkJCUAgd2Uga25v
dyB4aCBpcyB6ZXJvIGhlcmUgc28uLi4KKwlhZGQJeGgsIHhoLCAjMQorCW1vdgl4bCwgeGws
IGxzbCB4aAorCW1vdglpcCwgaXAsIGxzciB4aAorCisjZWxzZQorCis3Ogltb3ZzCXhsLCB4
bCwgbHNsICMxCisJbW92CWlwLCBpcCwgbHNyICMxCisJYmNjCTdiCisKKyNlbmRpZgorCisJ
QCBDdXJyZW50IHJlbWFpbmRlciBpcyBub3cgMS4gIEl0IGlzIHdvcnRobGVzcyB0byBjb21w
YXJlIHdpdGgKKwlAIGRpdmlzb3IgYXQgdGhpcyBwb2ludCBzaW5jZSBkaXZpc29yIGNhbiBu
b3QgYmUgc21hbGxlciB0aGFuIDMgaGVyZS4KKwlAIElmIHBvc3NpYmxlLCBicmFuY2ggZm9y
IGFub3RoZXIgc2hpZnQgaW4gdGhlIGRpdmlzaW9uIGxvb3AuCisJQCBJZiBubyBiaXQgcG9z
aXRpb24gbGVmdCB0aGVuIHdlIGFyZSBkb25lLgorCW1vdnMJaXAsIGlwLCBsc3IgIzEKKwlt
b3YJeGgsICMxCisJYm5lCTRiCisJbW92CXBjLCBscgorCis4OglAIERpdmlzaW9uIGJ5IGEg
cG93ZXIgb2YgMjogZGV0ZXJtaW5lIHdoYXQgdGhhdCBkaXZpc29yIG9yZGVyIGlzCisJQCB0
aGVuIHNpbXBseSBzaGlmdCB2YWx1ZXMgYXJvdW5kCisKKyNpZiBfX0xJTlVYX0FSTV9BUkNI
X18gPj0gNQorCisJY2x6CWlwLCByNAorCXJzYglpcCwgaXAsICMzMQorCisjZWxzZQorCisJ
bW92CXlsLCByNAorCWNtcAlyNCwgIygxIDw8IDE2KQorCW1vdglpcCwgIzAKKwltb3Zocwl5
bCwgeWwsIGxzciAjMTYKKwltb3ZocwlpcCwgIzE2CisKKwljbXAJeWwsICMoMSA8PCA4KQor
CW1vdmhzCXlsLCB5bCwgbHNyICM4CisJYWRkaHMJaXAsIGlwLCAjOAorCisJY21wCXlsLCAj
KDEgPDwgNCkKKwltb3Zocwl5bCwgeWwsIGxzciAjNAorCWFkZGhzCWlwLCBpcCwgIzQKKwor
CWNtcAl5bCwgIygxIDw8IDIpCisJYWRkaGkJaXAsIGlwLCAjMworCWFkZGxzCWlwLCBpcCwg
eWwsIGxzciAjMQorCisjZW5kaWYKKworCW1vdgl5aCwgeGgsIGxzciBpcAorCW1vdgl5bCwg
eGwsIGxzciBpcAorCXJzYglpcCwgaXAsICMzMgorCW9ycgl5bCwgeWwsIHhoLCBsc2wgaXAK
Kwltb3YJeGgsIHhsLCBsc2wgaXAKKwltb3YJeGgsIHhoLCBsc3IgaXAKKwltb3YJcGMsIGxy
CisKKwlAIGVxIC0+IGRpdmlzaW9uIGJ5IDE6IG9idmlvdXMgZW5vdWdoLi4uCis5Ogltb3Zl
cQl5bCwgeGwKKwltb3ZlcQl5aCwgeGgKKwltb3ZlcQl4aCwgIzAKKwltb3ZlcQlwYywgbHIK
KworCUAgRGl2aXNpb24gYnkgMDoKKwlzdHIJbHIsIFtzcCwgIy04XSEKKwlibAlfX2RpdjAK
KworCUAgYXMgd3JvbmcgYXMgaXQgY291bGQgYmUuLi4KKwltb3YJeWwsICMwCisJbW92CXlo
LCAjMAorCW1vdgl4aCwgIzAKKwlsZHIJcGMsIFtzcF0sICM4CisKZGlmZiAtciBlNzAxNDYx
YjEyNTEgeGVuL2FyY2gvYXJtL2xpYi9maW5kYml0LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9maW5kYml0
LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsODEgQEAKKyNp
bmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKwor
ICAgICAgICAgICAgICAgIC50ZXh0CisKKy8qCisgKiBQdXJwb3NlICA6IEZpbmQgYSAnemVy
bycgYml0CisgKiBQcm90b3R5cGU6IGludCBmaW5kX2ZpcnN0X3plcm9fYml0KHZvaWQgKmFk
ZHIsIHVuc2lnbmVkIGludCBtYXhiaXQpOworICovCitFTlRSWShfZmluZF9maXJzdF96ZXJv
X2JpdCkKKwkJdGVxCXIxLCAjMAkKKwkJYmVxCTNmCisJCW1vdglyMiwgIzAKKzE6CQlsZHJi
CXIzLCBbcjAsIHIyLCBsc3IgIzNdCisJCWVvcnMJcjMsIHIzLCAjMHhmZgkJQCBpbnZlcnQg
Yml0cworCQlibmUJLmZvdW5kCQkJQCBhbnkgbm93IHNldCAtIGZvdW5kIHplcm8gYml0CisJ
CWFkZAlyMiwgcjIsICM4CQlAIG5leHQgYml0IHBvaW50ZXIKKzI6CQljbXAJcjIsIHIxCQkJ
QCBhbnkgbW9yZT8KKwkJYmxvCTFiCiszOgkJbW92CXIwLCByMQkJCUAgbm8gZnJlZSBiaXRz
CisJCW1vdglwYyxscgorCisvKgorICogUHVycG9zZSAgOiBGaW5kIG5leHQgJ3plcm8nIGJp
dAorICogUHJvdG90eXBlOiBpbnQgZmluZF9uZXh0X3plcm9fYml0KHZvaWQgKmFkZHIsIHVu
c2lnbmVkIGludCBtYXhiaXQsIGludCBvZmZzZXQpCisgKi8KK0VOVFJZKF9maW5kX25leHRf
emVyb19iaXQpCisJCXRlcQlyMSwgIzAKKwkJYmVxCTNiCisJCWFuZHMJaXAsIHIyLCAjNwor
CQliZXEJMWIJCQlAIElmIG5ldyBieXRlLCBnb3RvIG9sZCByb3V0aW5lCisJCWxkcmIJcjMs
IFtyMCwgcjIsIGxzciAjM10KKwkJZW9yCXIzLCByMywgIzB4ZmYJCUAgbm93IGxvb2tpbmcg
Zm9yIGEgMSBiaXQKKwkJbW92cwlyMywgcjMsIGxzciBpcAkJQCBzaGlmdCBvZmYgdW51c2Vk
IGJpdHMKKwkJYm5lCS5mb3VuZAorCQlvcnIJcjIsIHIyLCAjNwkJQCBpZiB6ZXJvLCB0aGVu
IG5vIGJpdHMgaGVyZQorCQlhZGQJcjIsIHIyLCAjMQkJQCBhbGlnbiBiaXQgcG9pbnRlcgor
CQliCTJiCQkJQCBsb29wIGZvciBuZXh0IGJpdAorCisvKgorICogUHVycG9zZSAgOiBGaW5k
IGEgJ29uZScgYml0CisgKiBQcm90b3R5cGU6IGludCBmaW5kX2ZpcnN0X2JpdChjb25zdCB1
bnNpZ25lZCBsb25nICphZGRyLCB1bnNpZ25lZCBpbnQgbWF4Yml0KTsKKyAqLworRU5UUlko
X2ZpbmRfZmlyc3RfYml0KQorCQl0ZXEJcjEsICMwCQorCQliZXEJM2YKKwkJbW92CXIyLCAj
MAorMToJCWxkcmIJcjMsIFtyMCwgcjIsIGxzciAjM10KKwkJbW92cwlyMywgcjMKKwkJYm5l
CS5mb3VuZAkJCUAgYW55IG5vdyBzZXQgLSBmb3VuZCB6ZXJvIGJpdAorCQlhZGQJcjIsIHIy
LCAjOAkJQCBuZXh0IGJpdCBwb2ludGVyCisyOgkJY21wCXIyLCByMQkJCUAgYW55IG1vcmU/
CisJCWJsbwkxYgorMzoJCW1vdglyMCwgcjEJCQlAIG5vIGZyZWUgYml0cworCQltb3YJcGMs
bHIKKworLyoKKyAqIFB1cnBvc2UgIDogRmluZCBuZXh0ICdvbmUnIGJpdAorICogUHJvdG90
eXBlOiBpbnQgZmluZF9uZXh0X3plcm9fYml0KHZvaWQgKmFkZHIsIHVuc2lnbmVkIGludCBt
YXhiaXQsIGludCBvZmZzZXQpCisgKi8KK0VOVFJZKF9maW5kX25leHRfYml0KQorCQl0ZXEJ
cjEsICMwCisJCWJlcQkzYgorCQlhbmRzCWlwLCByMiwgIzcKKwkJYmVxCTFiCQkJQCBJZiBu
ZXcgYnl0ZSwgZ290byBvbGQgcm91dGluZQorCQlsZHJiCXIzLCBbcjAsIHIyLCBsc3IgIzNd
CisJCW1vdnMJcjMsIHIzLCBsc3IgaXAJCUAgc2hpZnQgb2ZmIHVudXNlZCBiaXRzCisJCWJu
ZQkuZm91bmQKKwkJb3JyCXIyLCByMiwgIzcJCUAgaWYgemVybywgdGhlbiBubyBiaXRzIGhl
cmUKKwkJYWRkCXIyLCByMiwgIzEJCUAgYWxpZ24gYml0IHBvaW50ZXIKKwkJYgkyYgkJCUAg
bG9vcCBmb3IgbmV4dCBiaXQKKworICAKKy5mb3VuZDoKKwkJcnNiCXIxLCByMywgIzAKKwkJ
YW5kCXIzLCByMywgcjEKKwkJY2x6CXIzLCByMworCQlyc2IJcjMsIHIzLCAjMzEKKwkJYWRk
CXIwLCByMiwgcjMKKwkJbW92CXBjLGxyCisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2Fy
Y2gvYXJtL2xpYi9nY2NsaWIuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL2djY2xpYi5oCUZyaSBGZWIgMDMg
MTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDMzIEBACisvKiBnY2NsaWIuaCAtLSBk
ZWZpbml0aW9ucyBmb3IgdmFyaW91cyBmdW5jdGlvbnMgJ2JvcnJvd2VkJyBmcm9tIGdjYy0y
Ljk1LjMgKi8KKy8qIEkgTW9sdG9uICAgICAyOS8wNy8wMSAqLworCisjaWZuZGVmIF9fR0ND
TElCX0hfXworI2RlZmluZSBfX0dDQ0xJQl9IX18KKyNkZWZpbmUgQklUU19QRVJfVU5JVCAg
OAorI2RlZmluZSBTSV9UWVBFX1NJWkUgKHNpemVvZiAoU0l0eXBlKSAqIEJJVFNfUEVSX1VO
SVQpCisKK3R5cGVkZWYgdW5zaWduZWQgaW50IFVRSXR5cGUgICAgX19hdHRyaWJ1dGVfXyAo
KG1vZGUgKFFJKSkpOwordHlwZWRlZiAgICAgICAgICBpbnQgU0l0eXBlICAgICBfX2F0dHJp
YnV0ZV9fICgobW9kZSAoU0kpKSk7Cit0eXBlZGVmIHVuc2lnbmVkIGludCBVU0l0eXBlICAg
IF9fYXR0cmlidXRlX18gKChtb2RlIChTSSkpKTsKK3R5cGVkZWYgICAgICAgICAgaW50IERJ
dHlwZSAgICAgX19hdHRyaWJ1dGVfXyAoKG1vZGUgKERJKSkpOwordHlwZWRlZiAgICAgICAg
ICBpbnQgd29yZF90eXBlIAlfX2F0dHJpYnV0ZV9fICgobW9kZSAoX193b3JkX18pKSk7Cit0
eXBlZGVmIHVuc2lnbmVkIGludCBVREl0eXBlICAgIF9fYXR0cmlidXRlX18gKChtb2RlIChE
SSkpKTsKKworI2lmZGVmIF9fQVJNRUJfXworICBzdHJ1Y3QgRElzdHJ1Y3Qge1NJdHlwZSBo
aWdoLCBsb3c7fTsKKyNlbHNlCisgIHN0cnVjdCBESXN0cnVjdCB7U0l0eXBlIGxvdywgaGln
aDt9OworI2VuZGlmCisKK3R5cGVkZWYgdW5pb24KK3sKKyAgc3RydWN0IERJc3RydWN0IHM7
CisgIERJdHlwZSBsbDsKK30gREl1bmlvbjsKKwordHlwZWRlZiBzdHJ1Y3QgX19hdHRyaWJ1
dGVfXygocmVnX3JldHVybikpCit7CisgICAgICAgIGxvbmcgbG9uZyBxdW90OworICAgICAg
ICBsb25nIGxvbmcgcmVtOworfSBsbGRpdl90X3JyOworI2VuZGlmCmRpZmYgLXIgZTcwMTQ2
MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvZ2V0dXNlci5TCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvZ2V0dXNl
ci5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDc3IEBACisv
KgorICogIGxpbnV4L2FyY2gvYXJtL2xpYi9nZXR1c2VyLlMKKyAqCisgKiAgQ29weXJpZ2h0
IChDKSAyMDAxIFJ1c3NlbGwgS2luZworICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv
ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1
bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNp
b24gMiBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24u
CisgKgorICogIElkZWEgZnJvbSB4ODYgdmVyc2lvbiwgKEMpIENvcHlyaWdodCAxOTk4IExp
bnVzIFRvcnZhbGRzCisgKgorICogVGhlc2UgZnVuY3Rpb25zIGhhdmUgYSBub24tc3RhbmRh
cmQgY2FsbCBpbnRlcmZhY2UgdG8gbWFrZSB0aGVtIG1vcmUKKyAqIGVmZmljaWVudCwgZXNw
ZWNpYWxseSBhcyB0aGV5IHJldHVybiBhbiBlcnJvciB2YWx1ZSBpbiBhZGRpdGlvbiB0bwor
ICogdGhlICJyZWFsIiByZXR1cm4gdmFsdWUuCisgKgorICogX19nZXRfdXNlcl9YCisgKgor
ICogSW5wdXRzOglyMCBjb250YWlucyB0aGUgYWRkcmVzcworICogT3V0cHV0czoJcjAgaXMg
dGhlIGVycm9yIGNvZGUKKyAqCQlyMiwgcjMgY29udGFpbnMgdGhlIHplcm8tZXh0ZW5kZWQg
dmFsdWUKKyAqCQlsciBjb3JydXB0ZWQKKyAqCisgKiBObyBvdGhlciByZWdpc3RlcnMgbXVz
dCBiZSBhbHRlcmVkLiAgKHNlZSBpbmNsdWRlL2FzbS1hcm0vdWFjY2Vzcy5oCisgKiBmb3Ig
c3BlY2lmaWMgQVNNIHJlZ2lzdGVyIHVzYWdlKS4KKyAqCisgKiBOb3RlIHRoYXQgQUREUl9M
SU1JVCBpcyBlaXRoZXIgMCBvciAweGMwMDAwMDAwLgorICogTm90ZSBhbHNvIHRoYXQgaXQg
aXMgaW50ZW5kZWQgdGhhdCBfX2dldF91c2VyX2JhZCBpcyBub3QgZ2xvYmFsLgorICovCisj
aW5jbHVkZSA8eGVuL2Vycm5vLmg+CisKKwkuZ2xvYmFsCV9fZ2V0X3VzZXJfMQorX19nZXRf
dXNlcl8xOgorMToJbGRyYnQJcjIsIFtyMF0KKwltb3YJcjAsICMwCisJbW92CXBjLCBscgor
CisJLmdsb2JhbAlfX2dldF91c2VyXzIKK19fZ2V0X3VzZXJfMjoKKzI6CWxkcmJ0CXIyLCBb
cjBdLCAjMQorMzoJbGRyYnQJcjMsIFtyMF0KKyNpZm5kZWYgX19BUk1FQl9fCisJb3JyCXIy
LCByMiwgcjMsIGxzbCAjOAorI2Vsc2UKKwlvcnIJcjIsIHIzLCByMiwgbHNsICM4CisjZW5k
aWYKKwltb3YJcjAsICMwCisJbW92CXBjLCBscgorCisJLmdsb2JhbAlfX2dldF91c2VyXzQK
K19fZ2V0X3VzZXJfNDoKKzQ6CWxkcnQJcjIsIFtyMF0KKwltb3YJcjAsICMwCisJbW92CXBj
LCBscgorCisJLmdsb2JhbAlfX2dldF91c2VyXzgKK19fZ2V0X3VzZXJfODoKKzU6CWxkcnQJ
cjIsIFtyMF0sICM0Cis2OglsZHJ0CXIzLCBbcjBdCisJbW92CXIwLCAjMAorCW1vdglwYywg
bHIKKworCS5nbG9iYWwgX19nZXRfdXNlcl9iYWQKK19fZ2V0X3VzZXJfYmFkXzg6CisJbW92
CXIzLCAjMAorX19nZXRfdXNlcl9iYWQ6CisJbW92CXIyLCAjMAorCW1vdglyMCwgIy1FRkFV
TFQKKwltb3YJcGMsIGxyCisKKy5zZWN0aW9uIF9fZXhfdGFibGUsICJhIgorCS5sb25nCTFi
LCBfX2dldF91c2VyX2JhZAorCS5sb25nCTJiLCBfX2dldF91c2VyX2JhZAorCS5sb25nCTNi
LCBfX2dldF91c2VyX2JhZAorCS5sb25nCTRiLCBfX2dldF91c2VyX2JhZAorCS5sb25nCTVi
LCBfX2dldF91c2VyX2JhZF84CisJLmxvbmcJNmIsIF9fZ2V0X3VzZXJfYmFkXzgKKy5wcmV2
aW91cwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL2xpYjFmdW5jcy5T
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hl
bi9hcmNoL2FybS9saWIvbGliMWZ1bmNzLlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsMjU2IEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1
ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisKKworLm1hY3JvIEFSTV9ESVZfQk9EWSBkaXZpZGVu
ZCwgZGl2aXNvciwgcmVzdWx0LCBjdXJiaXQKKworCUAgSW5pdGlhbGx5IHNoaWZ0IHRoZSBk
aXZpc29yIGxlZnQgMyBiaXRzIGlmIHBvc3NpYmxlLAorCUAgc2V0IGN1cmJpdCBhY2NvcmRp
bmdseS4gIFRoaXMgYWxsb3dzIGZvciBjdXJiaXQgdG8gYmUgbG9jYXRlZAorCUAgYXQgdGhl
IGxlZnQgZW5kIG9mIGVhY2ggNCBiaXQgbmliYmxlcyBpbiB0aGUgZGl2aXNpb24gbG9vcAor
CUAgdG8gc2F2ZSBvbmUgbG9vcCBpbiBtb3N0IGNhc2VzLgorCXRzdAlcZGl2aXNvciwgIzB4
ZTAwMDAwMDAKKwltb3ZlcQlcZGl2aXNvciwgXGRpdmlzb3IsIGxzbCAjMworCW1vdmVxCVxj
dXJiaXQsICM4CisJbW92bmUJXGN1cmJpdCwgIzEKKworCUAgVW5sZXNzIHRoZSBkaXZpc29y
IGlzIHZlcnkgYmlnLCBzaGlmdCBpdCB1cCBpbiBtdWx0aXBsZXMgb2YKKwlAIGZvdXIgYml0
cywgc2luY2UgdGhpcyBpcyB0aGUgYW1vdW50IG9mIHVud2luZGluZyBpbiB0aGUgbWFpbgor
CUAgZGl2aXNpb24gbG9vcC4gIENvbnRpbnVlIHNoaWZ0aW5nIHVudGlsIHRoZSBkaXZpc29y
IGlzIAorCUAgbGFyZ2VyIHRoYW4gdGhlIGRpdmlkZW5kLgorMToJY21wCVxkaXZpc29yLCAj
MHgxMDAwMDAwMAorCWNtcGxvCVxkaXZpc29yLCBcZGl2aWRlbmQKKwltb3ZsbwlcZGl2aXNv
ciwgXGRpdmlzb3IsIGxzbCAjNAorCW1vdmxvCVxjdXJiaXQsIFxjdXJiaXQsIGxzbCAjNAor
CWJsbwkxYgorCisJQCBGb3IgdmVyeSBiaWcgZGl2aXNvcnMsIHdlIG11c3Qgc2hpZnQgaXQg
YSBiaXQgYXQgYSB0aW1lLCBvcgorCUAgd2Ugd2lsbCBiZSBpbiBkYW5nZXIgb2Ygb3ZlcmZs
b3dpbmcuCisxOgljbXAJXGRpdmlzb3IsICMweDgwMDAwMDAwCisJY21wbG8JXGRpdmlzb3Is
IFxkaXZpZGVuZAorCW1vdmxvCVxkaXZpc29yLCBcZGl2aXNvciwgbHNsICMxCisJbW92bG8J
XGN1cmJpdCwgXGN1cmJpdCwgbHNsICMxCisJYmxvCTFiCisKKwltb3YJXHJlc3VsdCwgIzAK
KworCUAgRGl2aXNpb24gbG9vcAorMToJY21wCVxkaXZpZGVuZCwgXGRpdmlzb3IKKwlzdWJo
cwlcZGl2aWRlbmQsIFxkaXZpZGVuZCwgXGRpdmlzb3IKKwlvcnJocwlccmVzdWx0LCAgIFxy
ZXN1bHQsICAgXGN1cmJpdAorCWNtcAlcZGl2aWRlbmQsIFxkaXZpc29yLCAgbHNyICMxCisJ
c3ViaHMJXGRpdmlkZW5kLCBcZGl2aWRlbmQsIFxkaXZpc29yLCBsc3IgIzEKKwlvcnJocwlc
cmVzdWx0LCAgIFxyZXN1bHQsICAgXGN1cmJpdCwgIGxzciAjMQorCWNtcAlcZGl2aWRlbmQs
IFxkaXZpc29yLCAgbHNyICMyCisJc3ViaHMJXGRpdmlkZW5kLCBcZGl2aWRlbmQsIFxkaXZp
c29yLCBsc3IgIzIKKwlvcnJocwlccmVzdWx0LCAgIFxyZXN1bHQsICAgXGN1cmJpdCwgIGxz
ciAjMgorCWNtcAlcZGl2aWRlbmQsIFxkaXZpc29yLCAgbHNyICMzCisJc3ViaHMJXGRpdmlk
ZW5kLCBcZGl2aWRlbmQsIFxkaXZpc29yLCBsc3IgIzMKKwlvcnJocwlccmVzdWx0LCAgIFxy
ZXN1bHQsICAgXGN1cmJpdCwgIGxzciAjMworCWNtcAlcZGl2aWRlbmQsICMwCQkJQCBFYXJs
eSB0ZXJtaW5hdGlvbj8KKwltb3ZuZXMJXGN1cmJpdCwgICBcY3VyYml0LCAgbHNyICM0CUAg
Tm8sIGFueSBtb3JlIGJpdHMgdG8gZG8/CisJbW92bmUJXGRpdmlzb3IsICBcZGl2aXNvciwg
bHNyICM0CisJYm5lCTFiCisKKy5lbmRtCisKKworLm1hY3JvIEFSTV9ESVYyX09SREVSIGRp
dmlzb3IsIG9yZGVyCisJY21wCVxkaXZpc29yLCAjKDEgPDwgMTYpCisJbW92aHMJXGRpdmlz
b3IsIFxkaXZpc29yLCBsc3IgIzE2CisJbW92aHMJXG9yZGVyLCAjMTYKKwltb3Zsbwlcb3Jk
ZXIsICMwCisKKwljbXAJXGRpdmlzb3IsICMoMSA8PCA4KQorCW1vdmhzCVxkaXZpc29yLCBc
ZGl2aXNvciwgbHNyICM4CisJYWRkaHMJXG9yZGVyLCBcb3JkZXIsICM4CisKKwljbXAJXGRp
dmlzb3IsICMoMSA8PCA0KQorCW1vdmhzCVxkaXZpc29yLCBcZGl2aXNvciwgbHNyICM0CisJ
YWRkaHMJXG9yZGVyLCBcb3JkZXIsICM0CisKKwljbXAJXGRpdmlzb3IsICMoMSA8PCAyKQor
CWFkZGhpCVxvcmRlciwgXG9yZGVyLCAjMworCWFkZGxzCVxvcmRlciwgXG9yZGVyLCBcZGl2
aXNvciwgbHNyICMxCisuZW5kbQorCisKKy5tYWNybyBBUk1fTU9EX0JPRFkgZGl2aWRlbmQs
IGRpdmlzb3IsIG9yZGVyLCBzcGFyZQorCW1vdglcb3JkZXIsICMwCisKKwlAIFVubGVzcyB0
aGUgZGl2aXNvciBpcyB2ZXJ5IGJpZywgc2hpZnQgaXQgdXAgaW4gbXVsdGlwbGVzIG9mCisJ
QCBmb3VyIGJpdHMsIHNpbmNlIHRoaXMgaXMgdGhlIGFtb3VudCBvZiB1bndpbmRpbmcgaW4g
dGhlIG1haW4KKwlAIGRpdmlzaW9uIGxvb3AuICBDb250aW51ZSBzaGlmdGluZyB1bnRpbCB0
aGUgZGl2aXNvciBpcyAKKwlAIGxhcmdlciB0aGFuIHRoZSBkaXZpZGVuZC4KKzE6CWNtcAlc
ZGl2aXNvciwgIzB4MTAwMDAwMDAKKwljbXBsbwlcZGl2aXNvciwgXGRpdmlkZW5kCisJbW92
bG8JXGRpdmlzb3IsIFxkaXZpc29yLCBsc2wgIzQKKwlhZGRsbwlcb3JkZXIsIFxvcmRlciwg
IzQKKwlibG8JMWIKKworCUAgRm9yIHZlcnkgYmlnIGRpdmlzb3JzLCB3ZSBtdXN0IHNoaWZ0
IGl0IGEgYml0IGF0IGEgdGltZSwgb3IKKwlAIHdlIHdpbGwgYmUgaW4gZGFuZ2VyIG9mIG92
ZXJmbG93aW5nLgorMToJY21wCVxkaXZpc29yLCAjMHg4MDAwMDAwMAorCWNtcGxvCVxkaXZp
c29yLCBcZGl2aWRlbmQKKwltb3ZsbwlcZGl2aXNvciwgXGRpdmlzb3IsIGxzbCAjMQorCWFk
ZGxvCVxvcmRlciwgXG9yZGVyLCAjMQorCWJsbwkxYgorCisJQCBQZXJmb3JtIGFsbCBuZWVk
ZWQgc3Vic3RyYWN0aW9ucyB0byBrZWVwIG9ubHkgdGhlIHJlbWluZGVyLgorCUAgRG8gY29t
cGFyaXNvbnMgaW4gYmF0Y2ggb2YgNCBmaXJzdC4KKwlzdWJzCVxvcmRlciwgXG9yZGVyLCAj
MwkJQCB5ZXMsIDMgaXMgaW50ZW5kZWQgaGVyZQorCWJsdAkyZgorCisxOgljbXAJXGRpdmlk
ZW5kLCBcZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvcgor
CWNtcAlcZGl2aWRlbmQsIFxkaXZpc29yLCAgbHNyICMxCisJc3ViaHMJXGRpdmlkZW5kLCBc
ZGl2aWRlbmQsIFxkaXZpc29yLCBsc3IgIzEKKwljbXAJXGRpdmlkZW5kLCBcZGl2aXNvciwg
IGxzciAjMgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvciwgbHNyICMy
CisJY21wCVxkaXZpZGVuZCwgXGRpdmlzb3IsICBsc3IgIzMKKwlzdWJocwlcZGl2aWRlbmQs
IFxkaXZpZGVuZCwgXGRpdmlzb3IsIGxzciAjMworCWNtcAlcZGl2aWRlbmQsICMxCisJbW92
CVxkaXZpc29yLCBcZGl2aXNvciwgbHNyICM0CisJc3ViZ2VzCVxvcmRlciwgXG9yZGVyLCAj
NAorCWJnZQkxYgorCisJdHN0CVxvcmRlciwgIzMKKwl0ZXFuZQlcZGl2aWRlbmQsICMwCisJ
YmVxCTVmCisKKwlAIEVpdGhlciAxLCAyIG9yIDMgY29tcGFyaXNvbi9zdWJzdHJhY3Rpb25z
IGFyZSBsZWZ0LgorMjoJY21uCVxvcmRlciwgIzIKKwlibHQJNGYKKwliZXEJM2YKKwljbXAJ
XGRpdmlkZW5kLCBcZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2
aXNvcgorCW1vdglcZGl2aXNvciwgIFxkaXZpc29yLCAgbHNyICMxCiszOgljbXAJXGRpdmlk
ZW5kLCBcZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvcgor
CW1vdglcZGl2aXNvciwgIFxkaXZpc29yLCAgbHNyICMxCis0OgljbXAJXGRpdmlkZW5kLCBc
ZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvcgorNToKKy5l
bmRtCisKKworRU5UUlkoX191ZGl2c2kzKQorRU5UUlkoX19hZWFiaV91aWRpdikKKwlzdWJz
CXIyLCByMSwgIzEKKwltb3ZlcQlwYywgbHIKKwliY2MJTGRpdjAKKwljbXAJcjAsIHIxCisJ
YmxzCTExZgorCXRzdAlyMSwgcjIKKwliZXEJMTJmCisKKwlBUk1fRElWX0JPRFkgcjAsIHIx
LCByMiwgcjMKKworCW1vdglyMCwgcjIKKwltb3YJcGMsIGxyCisKKzExOgltb3ZlcQlyMCwg
IzEKKwltb3ZuZQlyMCwgIzAKKwltb3YJcGMsIGxyCisKKzEyOglBUk1fRElWMl9PUkRFUiBy
MSwgcjIKKworCW1vdglyMCwgcjAsIGxzciByMgorCW1vdglwYywgbHIKKworCitFTlRSWShf
X3Vtb2RzaTMpCisJc3VicwlyMiwgcjEsICMxCQkJQCBjb21wYXJlIGRpdmlzb3Igd2l0aCAx
CisJYmNjCUxkaXYwCisJY21wbmUJcjAsIHIxCQkJCUAgY29tcGFyZSBkaXZpZGVuZCB3aXRo
IGRpdmlzb3IKKwltb3ZlcSAgIHIwLCAjMAorCXRzdGhpCXIxLCByMgkJCQlAIHNlZSBpZiBk
aXZpc29yIGlzIHBvd2VyIG9mIDIKKwlhbmRlcQlyMCwgcjAsIHIyCisJbW92bHMJcGMsIGxy
CisKKwlBUk1fTU9EX0JPRFkgcjAsIHIxLCByMiwgcjMKKworCW1vdglwYywgbHIKKworCitF
TlRSWShfX2RpdnNpMykKK0VOVFJZKF9fYWVhYmlfaWRpdikKKwljbXAJcjEsICMwCisJZW9y
CWlwLCByMCwgcjEJCQlAIHNhdmUgdGhlIHNpZ24gb2YgdGhlIHJlc3VsdC4KKwliZXEJTGRp
djAKKwlyc2JtaQlyMSwgcjEsICMwCQkJQCBsb29wcyBiZWxvdyB1c2UgdW5zaWduZWQuCisJ
c3VicwlyMiwgcjEsICMxCQkJQCBkaXZpc2lvbiBieSAxIG9yIC0xID8KKwliZXEJMTBmCisJ
bW92cwlyMywgcjAKKwlyc2JtaQlyMywgcjAsICMwCQkJQCBwb3NpdGl2ZSBkaXZpZGVuZCB2
YWx1ZQorCWNtcAlyMywgcjEKKwlibHMJMTFmCisJdHN0CXIxLCByMgkJCQlAIGRpdmlzb3Ig
aXMgcG93ZXIgb2YgMiA/CisJYmVxCTEyZgorCisJQVJNX0RJVl9CT0RZIHIzLCByMSwgcjAs
IHIyCisKKwljbXAJaXAsICMwCisJcnNibWkJcjAsIHIwLCAjMAorCW1vdglwYywgbHIKKwor
MTA6CXRlcQlpcCwgcjAJCQkJQCBzYW1lIHNpZ24gPworCXJzYm1pCXIwLCByMCwgIzAKKwlt
b3YJcGMsIGxyCisKKzExOgltb3ZsbwlyMCwgIzAKKwltb3ZlcQlyMCwgaXAsIGFzciAjMzEK
KwlvcnJlcQlyMCwgcjAsICMxCisJbW92CXBjLCBscgorCisxMjoJQVJNX0RJVjJfT1JERVIg
cjEsIHIyCisKKwljbXAJaXAsICMwCisJbW92CXIwLCByMywgbHNyIHIyCisJcnNibWkJcjAs
IHIwLCAjMAorCW1vdglwYywgbHIKKworCitFTlRSWShfX21vZHNpMykKKworCWNtcAlyMSwg
IzAKKwliZXEJTGRpdjAKKwlyc2JtaQlyMSwgcjEsICMwCQkJQCBsb29wcyBiZWxvdyB1c2Ug
dW5zaWduZWQuCisJbW92cwlpcCwgcjAJCQkJQCBwcmVzZXJ2ZSBzaWduIG9mIGRpdmlkZW5k
CisJcnNibWkJcjAsIHIwLCAjMAkJCUAgaWYgbmVnYXRpdmUgbWFrZSBwb3NpdGl2ZQorCXN1
YnMJcjIsIHIxLCAjMQkJCUAgY29tcGFyZSBkaXZpc29yIHdpdGggMQorCWNtcG5lCXIwLCBy
MQkJCQlAIGNvbXBhcmUgZGl2aWRlbmQgd2l0aCBkaXZpc29yCisJbW92ZXEJcjAsICMwCisJ
dHN0aGkJcjEsIHIyCQkJCUAgc2VlIGlmIGRpdmlzb3IgaXMgcG93ZXIgb2YgMgorCWFuZGVx
CXIwLCByMCwgcjIKKwlibHMJMTBmCisKKwlBUk1fTU9EX0JPRFkgcjAsIHIxLCByMiwgcjMK
KworMTA6CWNtcAlpcCwgIzAKKwlyc2JtaQlyMCwgcjAsICMwCisJbW92CXBjLCBscgorCitF
TlRSWShfX2FlYWJpX3VpZGl2bW9kKQorCXN0bWZkICAgc3AhLCB7cjAsIHIxLCBpcCwgbHJ9
CisJYmwgICAgICBfX2FlYWJpX3VpZGl2CisJbGRtZmQgICBzcCEsIHtyMSwgcjIsIGlwLCBs
cn0KKwltdWwgICAgIHIzLCByMCwgcjIKKwlzdWIgICAgIHIxLCByMSwgcjMKKwltb3YgICAg
IHBjLCBscgorCitFTlRSWShfX2FlYWJpX2lkaXZtb2QpCisJc3RtZmQgICBzcCEsIHtyMCwg
cjEsIGlwLCBscn0KKwlibCAgICAgIF9fYWVhYmlfaWRpdgorCWxkbWZkICAgc3AhLCB7cjEs
IHIyLCBpcCwgbHJ9CisJbXVsICAgICByMywgcjAsIHIyCisJc3ViICAgICByMSwgcjEsIHIz
CisJbW92ICAgICBwYywgbHIKKworTGRpdjA6CisKKwlzdHIJbHIsIFtzcCwgIy04XSEKKwli
bAlfX2RpdjAKKwltb3YJcjAsICMwCQkJQCBBYm91dCBhcyB3cm9uZyBhcyBpdCBjb3VsZCBi
ZS4KKwlsZHIJcGMsIFtzcF0sICM4CisKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJj
aC9hcm0vbGliL2xvbmdsb25nLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9sb25nbG9uZy5oCUZyaSBGZWIg
MDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDE4MyBAQAorLyogbG9uZ2xvbmcu
aCAtLSBiYXNlZCBvbiBjb2RlIGZyb20gZ2NjLTIuOTUuMworCisgICBkZWZpbml0aW9ucyBm
b3IgbWl4ZWQgc2l6ZSAzMi82NCBiaXQgYXJpdGhtZXRpYy4KKyAgIENvcHlyaWdodCAoQykg
MTk5MSwgOTIsIDk0LCA5NSwgOTYsIDE5OTcsIDE5OTggRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uLCBJbmMuCisKKyAgIFRoaXMgZGVmaW5pdGlvbiBmaWxlIGlzIGZyZWUgc29mdHdhcmU7
IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0CisgICBhbmQvb3IgbW9kaWZ5IGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljCisgICBMaWNlbnNlIGFzIHB1Ymxp
c2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIKKyAgIHZlcnNp
b24gMiwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKworICAgVGhp
cyBkZWZpbml0aW9uIGZpbGUgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3
aWxsIGJlCisgICB1c2VmdWwsIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkCisgICB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IgRklU
TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCisgICBTZWUgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisKKyAgIFlvdSBzaG91bGQgaGF2
ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisg
ICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBT
b2Z0d2FyZQorICAgRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUg
MzMwLAorICAgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuICAqLworCisvKiBCb3Jyb3dl
ZCBmcm9tIEdDQyAyLjk1LjMsIEkgTW9sdG9uIDI5LzA3LzAxICovCisKKyNpZm5kZWYgU0lf
VFlQRV9TSVpFCisjZGVmaW5lIFNJX1RZUEVfU0laRSAzMgorI2VuZGlmCisKKyNkZWZpbmUg
X19CSVRTNCAoU0lfVFlQRV9TSVpFIC8gNCkKKyNkZWZpbmUgX19sbF9CICgxTCA8PCAoU0lf
VFlQRV9TSVpFIC8gMikpCisjZGVmaW5lIF9fbGxfbG93cGFydCh0KSAoKFVTSXR5cGUpICh0
KSAlIF9fbGxfQikKKyNkZWZpbmUgX19sbF9oaWdocGFydCh0KSAoKFVTSXR5cGUpICh0KSAv
IF9fbGxfQikKKworLyogRGVmaW5lIGF1eGlsaWFyeSBhc20gbWFjcm9zLgorCisgICAxKSB1
bXVsX3BwbW0oaGlnaF9wcm9kLCBsb3dfcHJvZCwgbXVsdGlwbGVyLCBtdWx0aXBsaWNhbmQp
CisgICBtdWx0aXBsaWVzIHR3byBVU0l0eXBlIGludGVnZXJzIE1VTFRJUExFUiBhbmQgTVVM
VElQTElDQU5ELAorICAgYW5kIGdlbmVyYXRlcyBhIHR3by1wYXJ0IFVTSXR5cGUgcHJvZHVj
dCBpbiBISUdIX1BST0QgYW5kCisgICBMT1dfUFJPRC4KKworICAgMikgX191bXVsc2lkaTMo
YSxiKSBtdWx0aXBsaWVzIHR3byBVU0l0eXBlIGludGVnZXJzIEEgYW5kIEIsCisgICBhbmQg
cmV0dXJucyBhIFVESXR5cGUgcHJvZHVjdC4gIFRoaXMgaXMganVzdCBhIHZhcmlhbnQgb2Yg
dW11bF9wcG1tLgorCisgICAzKSB1ZGl2X3Fybm5kKHF1b3RpZW50LCByZW1haW5kZXIsIGhp
Z2hfbnVtZXJhdG9yLCBsb3dfbnVtZXJhdG9yLAorICAgZGVub21pbmF0b3IpIGRpdmlkZXMg
YSB0d28td29yZCB1bnNpZ25lZCBpbnRlZ2VyLCBjb21wb3NlZCBieSB0aGUKKyAgIGludGVn
ZXJzIEhJR0hfTlVNRVJBVE9SIGFuZCBMT1dfTlVNRVJBVE9SLCBieSBERU5PTUlOQVRPUiBh
bmQKKyAgIHBsYWNlcyB0aGUgcXVvdGllbnQgaW4gUVVPVElFTlQgYW5kIHRoZSByZW1haW5k
ZXIgaW4gUkVNQUlOREVSLgorICAgSElHSF9OVU1FUkFUT1IgbXVzdCBiZSBsZXNzIHRoYW4g
REVOT01JTkFUT1IgZm9yIGNvcnJlY3Qgb3BlcmF0aW9uLgorICAgSWYsIGluIGFkZGl0aW9u
LCB0aGUgbW9zdCBzaWduaWZpY2FudCBiaXQgb2YgREVOT01JTkFUT1IgbXVzdCBiZSAxLAor
ICAgdGhlbiB0aGUgcHJlLXByb2Nlc3NvciBzeW1ib2wgVURJVl9ORUVEU19OT1JNQUxJWkFU
SU9OIGlzIGRlZmluZWQgdG8gMS4KKworICAgNCkgc2Rpdl9xcm5uZChxdW90aWVudCwgcmVt
YWluZGVyLCBoaWdoX251bWVyYXRvciwgbG93X251bWVyYXRvciwKKyAgIGRlbm9taW5hdG9y
KS4gIExpa2UgdWRpdl9xcm5uZCBidXQgdGhlIG51bWJlcnMgYXJlIHNpZ25lZC4gIFRoZQor
ICAgcXVvdGllbnQgaXMgcm91bmRlZCB0b3dhcmRzIDAuCisKKyAgIDUpIGNvdW50X2xlYWRp
bmdfemVyb3MoY291bnQsIHgpIGNvdW50cyB0aGUgbnVtYmVyIG9mIHplcm8tYml0cyBmcm9t
CisgICB0aGUgbXNiIHRvIHRoZSBmaXJzdCBub24temVybyBiaXQuICBUaGlzIGlzIHRoZSBu
dW1iZXIgb2Ygc3RlcHMgWAorICAgbmVlZHMgdG8gYmUgc2hpZnRlZCBsZWZ0IHRvIHNldCB0
aGUgbXNiLiAgVW5kZWZpbmVkIGZvciBYID09IDAuCisKKyAgIDYpIGFkZF9zc2FhYWEoaGln
aF9zdW0sIGxvd19zdW0sIGhpZ2hfYWRkZW5kXzEsIGxvd19hZGRlbmRfMSwKKyAgIGhpZ2hf
YWRkZW5kXzIsIGxvd19hZGRlbmRfMikgYWRkcyB0d28gdHdvLXdvcmQgdW5zaWduZWQgaW50
ZWdlcnMsCisgICBjb21wb3NlZCBieSBISUdIX0FEREVORF8xIGFuZCBMT1dfQURERU5EXzEs
IGFuZCBISUdIX0FEREVORF8yIGFuZAorICAgTE9XX0FEREVORF8yIHJlc3BlY3RpdmVseS4g
IFRoZSByZXN1bHQgaXMgcGxhY2VkIGluIEhJR0hfU1VNIGFuZAorICAgTE9XX1NVTS4gIE92
ZXJmbG93IChpLmUuIGNhcnJ5IG91dCkgaXMgbm90IHN0b3JlZCBhbnl3aGVyZSwgYW5kIGlz
CisgICBsb3N0LgorCisgICA3KSBzdWJfZGRtbXNzKGhpZ2hfZGlmZmVyZW5jZSwgbG93X2Rp
ZmZlcmVuY2UsIGhpZ2hfbWludWVuZCwKKyAgIGxvd19taW51ZW5kLCBoaWdoX3N1YnRyYWhl
bmQsIGxvd19zdWJ0cmFoZW5kKSBzdWJ0cmFjdHMgdHdvCisgICB0d28td29yZCB1bnNpZ25l
ZCBpbnRlZ2VycywgY29tcG9zZWQgYnkgSElHSF9NSU5VRU5EXzEgYW5kCisgICBMT1dfTUlO
VUVORF8xLCBhbmQgSElHSF9TVUJUUkFIRU5EXzIgYW5kIExPV19TVUJUUkFIRU5EXzIKKyAg
IHJlc3BlY3RpdmVseS4gIFRoZSByZXN1bHQgaXMgcGxhY2VkIGluIEhJR0hfRElGRkVSRU5D
RSBhbmQKKyAgIExPV19ESUZGRVJFTkNFLiAgT3ZlcmZsb3cgKGkuZS4gY2Fycnkgb3V0KSBp
cyBub3Qgc3RvcmVkIGFueXdoZXJlLAorICAgYW5kIGlzIGxvc3QuCisKKyAgIElmIGFueSBv
ZiB0aGVzZSBtYWNyb3MgYXJlIGxlZnQgdW5kZWZpbmVkIGZvciBhIHBhcnRpY3VsYXIgQ1BV
LAorICAgQyBtYWNyb3MgYXJlIHVzZWQuICAqLworCisjaWYgZGVmaW5lZCAoX19hcm1fXykK
KyNkZWZpbmUgYWRkX3NzYWFhYShzaCwgc2wsIGFoLCBhbCwgYmgsIGJsKSBcCisgIF9fYXNt
X18gKCJhZGRzCSUxLCAlNCwgJTUJCQkJCVxuXAorCWFkYwklMCwgJTIsICUzIgkJCQkJCVwK
KwkgICA6ICI9ciIgKChVU0l0eXBlKSAoc2gpKSwJCQkJCVwKKwkgICAgICI9JnIiICgoVVNJ
dHlwZSkgKHNsKSkJCQkJCVwKKwkgICA6ICIlciIgKChVU0l0eXBlKSAoYWgpKSwJCQkJCVwK
KwkgICAgICJySSIgKChVU0l0eXBlKSAoYmgpKSwJCQkJCVwKKwkgICAgICIlciIgKChVU0l0
eXBlKSAoYWwpKSwJCQkJCVwKKwkgICAgICJySSIgKChVU0l0eXBlKSAoYmwpKSkKKyNkZWZp
bmUgc3ViX2RkbW1zcyhzaCwgc2wsIGFoLCBhbCwgYmgsIGJsKSBcCisgIF9fYXNtX18gKCJz
dWJzCSUxLCAlNCwgJTUJCQkJCVxuXAorCXNiYwklMCwgJTIsICUzIgkJCQkJCVwKKwkgICA6
ICI9ciIgKChVU0l0eXBlKSAoc2gpKSwJCQkJCVwKKwkgICAgICI9JnIiICgoVVNJdHlwZSkg
KHNsKSkJCQkJCVwKKwkgICA6ICJyIiAoKFVTSXR5cGUpIChhaCkpLAkJCQkJXAorCSAgICAg
InJJIiAoKFVTSXR5cGUpIChiaCkpLAkJCQkJXAorCSAgICAgInIiICgoVVNJdHlwZSkgKGFs
KSksCQkJCQlcCisJICAgICAickkiICgoVVNJdHlwZSkgKGJsKSkpCisjZGVmaW5lIHVtdWxf
cHBtbSh4aCwgeGwsIGEsIGIpIFwKK3tyZWdpc3RlciBVU0l0eXBlIF9fdDAsIF9fdDEsIF9f
dDI7CQkJCQlcCisgIF9fYXNtX18gKCIlQCBJbmxpbmVkIHVtdWxfcHBtbQkJCQkJXG5cCisJ
bW92CSUyLCAlNSwgbHNyICMxNgkJCQkJCVxuXAorCW1vdgklMCwgJTYsIGxzciAjMTYJCQkJ
CQlcblwKKwliaWMJJTMsICU1LCAlMiwgbHNsICMxNgkJCQkJXG5cCisJYmljCSU0LCAlNiwg
JTAsIGxzbCAjMTYJCQkJCVxuXAorCW11bAklMSwgJTMsICU0CQkJCQkJXG5cCisJbXVsCSU0
LCAlMiwgJTQJCQkJCQlcblwKKwltdWwJJTMsICUwLCAlMwkJCQkJCVxuXAorCW11bAklMCwg
JTIsICUwCQkJCQkJXG5cCisJYWRkcwklMywgJTQsICUzCQkJCQkJXG5cCisJYWRkY3MJJTAs
ICUwLCAjNjU1MzYJCQkJCQlcblwKKwlhZGRzCSUxLCAlMSwgJTMsIGxzbCAjMTYJCQkJCVxu
XAorCWFkYwklMCwgJTAsICUzLCBsc3IgIzE2IgkJCQkJXAorCSAgIDogIj0mciIgKChVU0l0
eXBlKSAoeGgpKSwJCQkJCVwKKwkgICAgICI9ciIgKChVU0l0eXBlKSAoeGwpKSwJCQkJCVwK
KwkgICAgICI9JnIiIChfX3QwKSwgIj0mciIgKF9fdDEpLCAiPXIiIChfX3QyKQkJCVwKKwkg
ICA6ICJyIiAoKFVTSXR5cGUpIChhKSksCQkJCQlcCisJICAgICAiciIgKChVU0l0eXBlKSAo
YikpKTt9CisjZGVmaW5lIFVNVUxfVElNRSAyMAorI2RlZmluZSBVRElWX1RJTUUgMTAwCisj
ZW5kaWYgLyogX19hcm1fXyAqLworCisjZGVmaW5lIF9fdW11bHNpZGkzKHUsIHYpIFwKKyAg
KHtESXVuaW9uIF9fdzsJCQkJCQkJXAorICAgIHVtdWxfcHBtbSAoX193LnMuaGlnaCwgX193
LnMubG93LCB1LCB2KTsJCQkJXAorICAgIF9fdy5sbDsgfSkKKworI2RlZmluZSBfX3VkaXZf
cXJubmRfYyhxLCByLCBuMSwgbjAsIGQpIFwKKyAgZG8gewkJCQkJCQkJCVwKKyAgICBVU0l0
eXBlIF9fZDEsIF9fZDAsIF9fcTEsIF9fcTA7CQkJCQlcCisgICAgVVNJdHlwZSBfX3IxLCBf
X3IwLCBfX207CQkJCQkJXAorICAgIF9fZDEgPSBfX2xsX2hpZ2hwYXJ0IChkKTsJCQkJCQlc
CisgICAgX19kMCA9IF9fbGxfbG93cGFydCAoZCk7CQkJCQkJXAorCQkJCQkJCQkJXAorICAg
IF9fcjEgPSAobjEpICUgX19kMTsJCQkJCQkJXAorICAgIF9fcTEgPSAobjEpIC8gX19kMTsJ
CQkJCQkJXAorICAgIF9fbSA9IChVU0l0eXBlKSBfX3ExICogX19kMDsJCQkJCVwKKyAgICBf
X3IxID0gX19yMSAqIF9fbGxfQiB8IF9fbGxfaGlnaHBhcnQgKG4wKTsJCQkJXAorICAgIGlm
IChfX3IxIDwgX19tKQkJCQkJCQlcCisgICAgICB7CQkJCQkJCQkJXAorCV9fcTEtLSwgX19y
MSArPSAoZCk7CQkJCQkJXAorCWlmIChfX3IxID49IChkKSkgLyogaS5lLiB3ZSBkaWRuJ3Qg
Z2V0IGNhcnJ5IHdoZW4gYWRkaW5nIHRvIF9fcjEgKi9cCisJICBpZiAoX19yMSA8IF9fbSkJ
CQkJCQlcCisJICAgIF9fcTEtLSwgX19yMSArPSAoZCk7CQkJCQlcCisgICAgICB9CQkJCQkJ
CQkJXAorICAgIF9fcjEgLT0gX19tOwkJCQkJCQlcCisJCQkJCQkJCQlcCisgICAgX19yMCA9
IF9fcjEgJSBfX2QxOwkJCQkJCQlcCisgICAgX19xMCA9IF9fcjEgLyBfX2QxOwkJCQkJCQlc
CisgICAgX19tID0gKFVTSXR5cGUpIF9fcTAgKiBfX2QwOwkJCQkJXAorICAgIF9fcjAgPSBf
X3IwICogX19sbF9CIHwgX19sbF9sb3dwYXJ0IChuMCk7CQkJCVwKKyAgICBpZiAoX19yMCA8
IF9fbSkJCQkJCQkJXAorICAgICAgewkJCQkJCQkJCVwKKwlfX3EwLS0sIF9fcjAgKz0gKGQp
OwkJCQkJCVwKKwlpZiAoX19yMCA+PSAoZCkpCQkJCQkJXAorCSAgaWYgKF9fcjAgPCBfX20p
CQkJCQkJXAorCSAgICBfX3EwLS0sIF9fcjAgKz0gKGQpOwkJCQkJXAorICAgICAgfQkJCQkJ
CQkJCVwKKyAgICBfX3IwIC09IF9fbTsJCQkJCQkJXAorCQkJCQkJCQkJXAorICAgIChxKSA9
IChVU0l0eXBlKSBfX3ExICogX19sbF9CIHwgX19xMDsJCQkJXAorICAgIChyKSA9IF9fcjA7
CQkJCQkJCQlcCisgIH0gd2hpbGUgKDApCisKKyNkZWZpbmUgVURJVl9ORUVEU19OT1JNQUxJ
WkFUSU9OIDEKKyNkZWZpbmUgdWRpdl9xcm5uZCBfX3VkaXZfcXJubmRfYworCisjZGVmaW5l
IGNvdW50X2xlYWRpbmdfemVyb3MoY291bnQsIHgpIFwKKyAgZG8gewkJCQkJCQkJCVwKKyAg
ICBVU0l0eXBlIF9feHIgPSAoeCk7CQkJCQkJCVwKKyAgICBVU0l0eXBlIF9fYTsJCQkJCQkJ
XAorCQkJCQkJCQkJXAorICAgIGlmIChTSV9UWVBFX1NJWkUgPD0gMzIpCQkJCQkJXAorICAg
ICAgewkJCQkJCQkJCVwKKwlfX2EgPSBfX3hyIDwgKChVU0l0eXBlKTE8PDIqX19CSVRTNCkJ
CQkJXAorCSAgPyAoX194ciA8ICgoVVNJdHlwZSkxPDxfX0JJVFM0KSA/IDAgOiBfX0JJVFM0
KQkJXAorCSAgOiAoX194ciA8ICgoVVNJdHlwZSkxPDwzKl9fQklUUzQpID8gIDIqX19CSVRT
NCA6IDMqX19CSVRTNCk7CVwKKyAgICAgIH0JCQkJCQkJCQlcCisgICAgZWxzZQkJCQkJCQkJ
XAorICAgICAgewkJCQkJCQkJCVwKKwlmb3IgKF9fYSA9IFNJX1RZUEVfU0laRSAtIDg7IF9f
YSA+IDA7IF9fYSAtPSA4KQkJCVwKKwkgIGlmICgoKF9feHIgPj4gX19hKSAmIDB4ZmYpICE9
IDApCQkJCVwKKwkgICAgYnJlYWs7CQkJCQkJCVwKKyAgICAgIH0JCQkJCQkJCQlcCisJCQkJ
CQkJCQlcCisgICAgKGNvdW50KSA9IFNJX1RZUEVfU0laRSAtIChfX2Nsel90YWJbX194ciA+
PiBfX2FdICsgX19hKTsJCVwKKyAgfSB3aGlsZSAoMCkKZGlmZiAtciBlNzAxNDYxYjEyNTEg
eGVuL2FyY2gvYXJtL2xpYi9sc2hyZGkzLlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9sc2hyZGkzLlMJRnJp
IEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTcgQEAKKyNpbmNsdWRl
IDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworI2RlZmlu
ZSBhbCByMAorI2RlZmluZSBhaCByMQorCitFTlRSWShfX2xzaHJkaTMpCitFTlRSWShfX2Fl
YWJpX2xsc3IpCisKKyAgICAgICAgc3VicyAgICByMywgcjIsICMzMgorICAgICAgICByc2Ig
ICAgIGlwLCByMiwgIzMyCisgICAgICAgIG1vdm1pICAgYWwsIGFsLCBsc3IgcjIKKyAgICAg
ICAgbW92cGwgICBhbCwgYWgsIGxzciByMworIAlvcnJtaSAgIGFsLCBhbCwgYWgsIGxzbCBp
cCAKKyAgICAgICAgbW92ICAgICBhaCwgYWgsIGxzciByMgorICAgICAgICBtb3YgICAgIHBj
LCBscgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvbWF0aC5jCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9h
cmNoL2FybS9saWIvbWF0aC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAt
MCwwICsxLDMgQEAKK3ZvaWQgbWR1bW15KHZvaWQpCit7Cit9CmRpZmYgLXIgZTcwMTQ2MWIx
MjUxIHhlbi9hcmNoL2FybS9saWIvbWVtY2hyLlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9tZW1jaHIuUwlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxNCBAQAorI2luY2x1
ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisJLnRl
eHQKKwkuYWxpZ24JNQorRU5UUlkobWVtY2hyKQorMToJc3VicwlyMiwgcjIsICMxCisJYm1p
CTJmCisJbGRyYglyMywgW3IwXSwgIzEKKwl0ZXEJcjMsIHIxCisJYm5lCTFiCisJc3ViCXIw
LCByMCwgIzEKKzI6CW1vdm5lCXIwLCAjMAorCW1vdglwYyxscgpkaWZmIC1yIGU3MDE0NjFi
MTI1MSB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvbWVtY3B5LlMJ
RnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjAgQEAKKy8qCisg
KiAgbGludXgvYXJjaC9hcm0vbGliL21lbWNweS5TCisgKgorICogIEF1dGhvcjoJTmljb2xh
cyBQaXRyZQorICogIENyZWF0ZWQ6CVNlcCAyOCwgMjAwNQorICogIENvcHlyaWdodDoJTW9u
dGFWaXN0YSBTb2Z0d2FyZSwgSW5jLgorICoKKyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0
IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVy
c2lvbiAyIGFzCisgKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24uCisgKi8KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNt
LW1hY3Jvcy5oPgorCisKKwkubWFjcm8gbGRyMXcgcHRyIHJlZyBhYm9ydAorCWxkciBccmVn
LCBbXHB0cl0sICM0CisJLmVuZG0KKworCS5tYWNybyBsZHI0dyBwdHIgcmVnMSByZWcyIHJl
ZzMgcmVnNCBhYm9ydAorCWxkbWlhIFxwdHIhLCB7XHJlZzEsIFxyZWcyLCBccmVnMywgXHJl
ZzR9CisJLmVuZG0KKworCS5tYWNybyBsZHI4dyBwdHIgcmVnMSByZWcyIHJlZzMgcmVnNCBy
ZWc1IHJlZzYgcmVnNyByZWc4IGFib3J0CisJbGRtaWEgXHB0ciEsIHtccmVnMSwgXHJlZzIs
IFxyZWczLCBccmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywgXHJlZzh9CisJLmVuZG0KKwor
CS5tYWNybyBsZHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQKKwlsZHJcY29uZFwoKWIgXHJl
ZywgW1xwdHJdLCAjMQorCS5lbmRtCisKKwkubWFjcm8gc3RyMXcgcHRyIHJlZyBhYm9ydAor
CXN0ciBccmVnLCBbXHB0cl0sICM0CisJLmVuZG0KKworCS5tYWNybyBzdHI4dyBwdHIgcmVn
MSByZWcyIHJlZzMgcmVnNCByZWc1IHJlZzYgcmVnNyByZWc4IGFib3J0CisJc3RtaWEgXHB0
ciEsIHtccmVnMSwgXHJlZzIsIFxyZWczLCBccmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywg
XHJlZzh9CisJLmVuZG0KKworCS5tYWNybyBzdHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQK
KwlzdHJcY29uZFwoKWIgXHJlZywgW1xwdHJdLCAjMQorCS5lbmRtCisKKwkubWFjcm8gZW50
ZXIgcmVnMSByZWcyCisJc3RtZGIgc3AhLCB7cjAsIFxyZWcxLCBccmVnMn0KKwkuZW5kbQor
CisJLm1hY3JvIGV4aXQgcmVnMSByZWcyCisJbGRtZmQgc3AhLCB7cjAsIFxyZWcxLCBccmVn
Mn0KKwkuZW5kbQorCisJLnRleHQKKworLyogUHJvdG90eXBlOiB2b2lkICptZW1jcHkodm9p
ZCAqZGVzdCwgY29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgbik7ICovCisKK0VOVFJZKG1lbWNw
eSkKKworI2luY2x1ZGUgImNvcHlfdGVtcGxhdGUuUyIKKwpkaWZmIC1yIGU3MDE0NjFiMTI1
MSB4ZW4vYXJjaC9hcm0vbGliL21lbW1vdmUuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL21lbW1vdmUuUwlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyMDcgQEAKKy8qCisg
KiAgbGludXgvYXJjaC9hcm0vbGliL21lbW1vdmUuUworICoKKyAqICBBdXRob3I6CU5pY29s
YXMgUGl0cmUKKyAqICBDcmVhdGVkOglTZXAgMjgsIDIwMDUKKyAqICBDb3B5cmlnaHQ6CShD
KSBNb250YVZpc3RhIFNvZnR3YXJlIEluYy4KKyAqCisgKiAgVGhpcyBwcm9ncmFtIGlzIGZy
ZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAq
ICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IHZlcnNpb24gMiBhcworICogIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uLgorICovCisKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNt
L2FzbS1tYWNyb3MuaD4KKworCisvKgorICogVGhpcyBjYW4gYmUgdXNlZCB0byBlbmFibGUg
Y29kZSB0byBjYWNoZWxpbmUgYWxpZ24gdGhlIHNvdXJjZSBwb2ludGVyLgorICogRXhwZXJp
bWVudHMgb24gdGVzdGVkIGFyY2hpdGVjdHVyZXMgKFN0cm9uZ0FSTSBhbmQgWFNjYWxlKSBk
aWRuJ3Qgc2hvdworICogdGhpcyBhIHdvcnRod2hpbGUgdGhpbmcgdG8gZG8uICBUaGF0IG1p
Z2h0IGJlIGRpZmZlcmVudCBpbiB0aGUgZnV0dXJlLgorICovCisvLyNkZWZpbmUgQ0FMR04o
Y29kZS4uLikgICAgICAgIGNvZGUKKyNkZWZpbmUgQ0FMR04oY29kZS4uLikKKworCQkudGV4
dAorCisvKgorICogUHJvdG90eXBlOiB2b2lkICptZW1tb3ZlKHZvaWQgKmRlc3QsIGNvbnN0
IHZvaWQgKnNyYywgc2l6ZV90IG4pOworICoKKyAqIE5vdGU6CisgKgorICogSWYgdGhlIG1l
bW9yeSByZWdpb25zIGRvbid0IG92ZXJsYXAsIHdlIHNpbXBseSBicmFuY2ggdG8gbWVtY3B5
IHdoaWNoIGlzCisgKiBub3JtYWxseSBhIGJpdCBmYXN0ZXIuIE90aGVyd2lzZSB0aGUgY29w
eSBpcyBkb25lIGdvaW5nIGRvd253YXJkcy4gIFRoaXMKKyAqIGlzIGEgdHJhbnNwb3NpdGlv
biBvZiB0aGUgY29kZSBmcm9tIGNvcHlfdGVtcGxhdGUuUyBidXQgd2l0aCB0aGUgY29weQor
ICogb2NjdXJyaW5nIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24uCisgKi8KKworRU5UUlko
bWVtbW92ZSkKKworCQlzdWJzCWlwLCByMCwgcjEKKwkJY21waGkJcjIsIGlwCisJCWJscwlt
ZW1jcHkKKworCQlzdG1mZAlzcCEsIHtyMCwgcjQsIGxyfQorCQlhZGQJcjEsIHIxLCByMgor
CQlhZGQJcjAsIHIwLCByMgorCQlzdWJzCXIyLCByMiwgIzQKKwkJYmx0CThmCisJCWFuZHMJ
aXAsIHIwLCAjMworCVBMRCgJcGxkCVtyMSwgIy00XQkJKQorCQlibmUJOWYKKwkJYW5kcwlp
cCwgcjEsICMzCisJCWJuZQkxMGYKKworMToJCXN1YnMJcjIsIHIyLCAjKDI4KQorCQlzdG1m
ZAlzcCEsIHtyNSAtIHI4fQorCQlibHQJNWYKKworCUNBTEdOKAlhbmRzCWlwLCByMSwgIzMx
CQkpCisJQ0FMR04oCXNiY25lcwlyNCwgaXAsIHIyCQkpICBAIEMgaXMgYWx3YXlzIHNldCBo
ZXJlCisJQ0FMR04oCWJjcwkyZgkJCSkKKwlDQUxHTigJYWRyCXI0LCA2ZgkJCSkKKwlDQUxH
TigJc3VicwlyMiwgcjIsIGlwCQkpICBAIEMgaXMgc2V0IGhlcmUKKwlDQUxHTigJYWRkCXBj
LCByNCwgaXAJCSkKKworCVBMRCgJcGxkCVtyMSwgIy00XQkJKQorMjoJUExEKAlzdWJzCXIy
LCByMiwgIzk2CQkpCisJUExEKAlwbGQJW3IxLCAjLTMyXQkJKQorCVBMRCgJYmx0CTRmCQkJ
KQorCVBMRCgJcGxkCVtyMSwgIy02NF0JCSkKKwlQTEQoCXBsZAlbcjEsICMtOTZdCQkpCisK
KzM6CVBMRCgJcGxkCVtyMSwgIy0xMjhdCQkpCis0OgkJbGRtZGIJcjEhLCB7cjMsIHI0LCBy
NSwgcjYsIHI3LCByOCwgaXAsIGxyfQorCQlzdWJzCXIyLCByMiwgIzMyCisJCXN0bWRiCXIw
ISwge3IzLCByNCwgcjUsIHI2LCByNywgcjgsIGlwLCBscn0KKwkJYmdlCTNiCisJUExEKAlj
bW4JcjIsICM5NgkJCSkKKwlQTEQoCWJnZQk0YgkJCSkKKworNToJCWFuZHMJaXAsIHIyLCAj
MjgKKwkJcnNiCWlwLCBpcCwgIzMyCisJCWFkZG5lCXBjLCBwYywgaXAJCUAgQyBpcyBhbHdh
eXMgY2xlYXIgaGVyZQorCQliCTdmCis2OgkJbm9wCisJCWxkcglyMywgW3IxLCAjLTRdIQor
CQlsZHIJcjQsIFtyMSwgIy00XSEKKwkJbGRyCXI1LCBbcjEsICMtNF0hCisJCWxkcglyNiwg
W3IxLCAjLTRdIQorCQlsZHIJcjcsIFtyMSwgIy00XSEKKwkJbGRyCXI4LCBbcjEsICMtNF0h
CisJCWxkcglsciwgW3IxLCAjLTRdIQorCisJCWFkZAlwYywgcGMsIGlwCisJCW5vcAorCQlu
b3AKKwkJc3RyCXIzLCBbcjAsICMtNF0hCisJCXN0cglyNCwgW3IwLCAjLTRdIQorCQlzdHIJ
cjUsIFtyMCwgIy00XSEKKwkJc3RyCXI2LCBbcjAsICMtNF0hCisJCXN0cglyNywgW3IwLCAj
LTRdIQorCQlzdHIJcjgsIFtyMCwgIy00XSEKKwkJc3RyCWxyLCBbcjAsICMtNF0hCisKKwlD
QUxHTigJYmNzCTJiCQkJKQorCis3OgkJbGRtZmQJc3AhLCB7cjUgLSByOH0KKworODoJCW1v
dnMJcjIsIHIyLCBsc2wgIzMxCisJCWxkcm5lYglyMywgW3IxLCAjLTFdIQorCQlsZHJjc2IJ
cjQsIFtyMSwgIy0xXSEKKwkJbGRyY3NiCWlwLCBbcjEsICMtMV0KKwkJc3RybmViCXIzLCBb
cjAsICMtMV0hCisJCXN0cmNzYglyNCwgW3IwLCAjLTFdIQorCQlzdHJjc2IJaXAsIFtyMCwg
Iy0xXQorCQlsZG1mZAlzcCEsIHtyMCwgcjQsIHBjfQorCis5OgkJY21wCWlwLCAjMgorCQls
ZHJndGIJcjMsIFtyMSwgIy0xXSEKKwkJbGRyZ2ViCXI0LCBbcjEsICMtMV0hCisJCWxkcmIJ
bHIsIFtyMSwgIy0xXSEKKwkJc3RyZ3RiCXIzLCBbcjAsICMtMV0hCisJCXN0cmdlYglyNCwg
W3IwLCAjLTFdIQorCQlzdWJzCXIyLCByMiwgaXAKKwkJc3RyYglsciwgW3IwLCAjLTFdIQor
CQlibHQJOGIKKwkJYW5kcwlpcCwgcjEsICMzCisJCWJlcQkxYgorCisxMDoJCWJpYwlyMSwg
cjEsICMzCisJCWNtcAlpcCwgIzIKKwkJbGRyCXIzLCBbcjEsICMwXQorCQliZXEJMTdmCisJ
CWJsdAkxOGYKKworCisJCS5tYWNybwliYWNrd2FyZF9jb3B5X3NoaWZ0IHB1c2ggcHVsbAor
CisJCXN1YnMJcjIsIHIyLCAjMjgKKwkJYmx0CTE0ZgorCisJQ0FMR04oCWFuZHMJaXAsIHIx
LCAjMzEJCSkKKwlDQUxHTigJcnNiCWlwLCBpcCwgIzMyCQkpCisJQ0FMR04oCXNiY25lcwly
NCwgaXAsIHIyCQkpICBAIEMgaXMgYWx3YXlzIHNldCBoZXJlCisJQ0FMR04oCXN1YmNjCXIy
LCByMiwgaXAJCSkKKwlDQUxHTigJYmNjCTE1ZgkJCSkKKworMTE6CQlzdG1mZAlzcCEsIHty
NSAtIHI5fQorCisJUExEKAlwbGQJW3IxLCAjLTRdCQkpCisJUExEKAlzdWJzCXIyLCByMiwg
Izk2CQkpCisJUExEKAlwbGQJW3IxLCAjLTMyXQkJKQorCVBMRCgJYmx0CTEzZgkJCSkKKwlQ
TEQoCXBsZAlbcjEsICMtNjRdCQkpCisJUExEKAlwbGQJW3IxLCAjLTk2XQkJKQorCisxMjoJ
UExEKAlwbGQJW3IxLCAjLTEyOF0JCSkKKzEzOgkJbGRtZGIgICByMSEsIHtyNywgcjgsIHI5
LCBpcH0KKwkJbW92ICAgICBsciwgcjMsIHB1c2ggI1xwdXNoCisJCXN1YnMgICAgcjIsIHIy
LCAjMzIKKwkJbGRtZGIgICByMSEsIHtyMywgcjQsIHI1LCByNn0KKwkJb3JyICAgICBsciwg
bHIsIGlwLCBwdWxsICNccHVsbAorCQltb3YgICAgIGlwLCBpcCwgcHVzaCAjXHB1c2gKKwkJ
b3JyICAgICBpcCwgaXAsIHI5LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI5LCByOSwgcHVz
aCAjXHB1c2gKKwkJb3JyICAgICByOSwgcjksIHI4LCBwdWxsICNccHVsbAorCQltb3YgICAg
IHI4LCByOCwgcHVzaCAjXHB1c2gKKwkJb3JyICAgICByOCwgcjgsIHI3LCBwdWxsICNccHVs
bAorCQltb3YgICAgIHI3LCByNywgcHVzaCAjXHB1c2gKKwkJb3JyICAgICByNywgcjcsIHI2
LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI2LCByNiwgcHVzaCAjXHB1c2gKKwkJb3JyICAg
ICByNiwgcjYsIHI1LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI1LCByNSwgcHVzaCAjXHB1
c2gKKwkJb3JyICAgICByNSwgcjUsIHI0LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI0LCBy
NCwgcHVzaCAjXHB1c2gKKwkJb3JyICAgICByNCwgcjQsIHIzLCBwdWxsICNccHVsbAorCQlz
dG1kYiAgIHIwISwge3I0IC0gcjksIGlwLCBscn0KKwkJYmdlCTEyYgorCVBMRCgJY21uCXIy
LCAjOTYJCQkpCisJUExEKAliZ2UJMTNiCQkJKQorCisJCWxkbWZkCXNwISwge3I1IC0gcjl9
CisKKzE0OgkJYW5kcwlpcCwgcjIsICMyOAorCQliZXEJMTZmCisKKzE1OgkJbW92ICAgICBs
ciwgcjMsIHB1c2ggI1xwdXNoCisJCWxkcglyMywgW3IxLCAjLTRdIQorCQlzdWJzCWlwLCBp
cCwgIzQKKwkJb3JyCWxyLCBsciwgcjMsIHB1bGwgI1xwdWxsCisJCXN0cglsciwgW3IwLCAj
LTRdIQorCQliZ3QJMTViCisJQ0FMR04oCWNtcAlyMiwgIzAJCQkpCisJQ0FMR04oCWJnZQkx
MWIJCQkpCisKKzE2OgkJYWRkCXIxLCByMSwgIyhccHVsbCAvIDgpCisJCWIJOGIKKworCQku
ZW5kbQorCisKKwkJYmFja3dhcmRfY29weV9zaGlmdAlwdXNoPTgJcHVsbD0yNAorCisxNzoJ
CWJhY2t3YXJkX2NvcHlfc2hpZnQJcHVzaD0xNglwdWxsPTE2CisKKzE4OgkJYmFja3dhcmRf
Y29weV9zaGlmdAlwdXNoPTI0CXB1bGw9OAorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9h
cmNoL2FybS9saWIvbWVtb3J5LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9tZW1vcnkuUwlGcmkgRmViIDAz
IDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw0MjEgQEAKKy8qCisgKiAgbGludXgv
YXJjaC9hcm0vbGliL21lbWNweS5TCisgKgorICogIEF1dGhvcjoJTmljb2xhcyBQaXRyZQor
ICogIENyZWF0ZWQ6CVNlcCAyOCwgMjAwNQorICogIENvcHlyaWdodDoJTW9udGFWaXN0YSBT
b2Z0d2FyZSwgSW5jLgorICoKKyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsg
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFz
CisgKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKi8K
KworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5o
PgorCisKKwkubWFjcm8gbGRyMXcgcHRyIHJlZyBhYm9ydAorCWxkciBccmVnLCBbXHB0cl0s
ICM0CisJLmVuZG0KKworCS5tYWNybyBsZHI0dyBwdHIgcmVnMSByZWcyIHJlZzMgcmVnNCBh
Ym9ydAorCWxkbWlhIFxwdHIhLCB7XHJlZzEsIFxyZWcyLCBccmVnMywgXHJlZzR9CisJLmVu
ZG0KKworCS5tYWNybyBsZHI4dyBwdHIgcmVnMSByZWcyIHJlZzMgcmVnNCByZWc1IHJlZzYg
cmVnNyByZWc4IGFib3J0CisJbGRtaWEgXHB0ciEsIHtccmVnMSwgXHJlZzIsIFxyZWczLCBc
cmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywgXHJlZzh9CisJLmVuZG0KKworCS5tYWNybyBs
ZHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQKKwlsZHJcY29uZFwoKWIgXHJlZywgW1xwdHJd
LCAjMQorCS5lbmRtCisKKwkubWFjcm8gc3RyMXcgcHRyIHJlZyBhYm9ydAorCXN0ciBccmVn
LCBbXHB0cl0sICM0CisJLmVuZG0KKworCS5tYWNybyBzdHI4dyBwdHIgcmVnMSByZWcyIHJl
ZzMgcmVnNCByZWc1IHJlZzYgcmVnNyByZWc4IGFib3J0CisJc3RtaWEgXHB0ciEsIHtccmVn
MSwgXHJlZzIsIFxyZWczLCBccmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywgXHJlZzh9CisJ
LmVuZG0KKworCS5tYWNybyBzdHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQKKwlzdHJcY29u
ZFwoKWIgXHJlZywgW1xwdHJdLCAjMQorCS5lbmRtCisKKwkubWFjcm8gZW50ZXIgcmVnMSBy
ZWcyCisJc3RtZGIgc3AhLCB7cjAsIFxyZWcxLCBccmVnMn0KKwkuZW5kbQorCisJLm1hY3Jv
IGV4aXQgcmVnMSByZWcyCisJbGRtZmQgc3AhLCB7cjAsIFxyZWcxLCBccmVnMn0KKwkuZW5k
bQorCisJLnRleHQKKworLyogUHJvdG90eXBlOiB2b2lkICptZW1jcHkodm9pZCAqZGVzdCwg
Y29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgbik7ICovCisKK0VOVFJZKG1lbWNweSkKKworI2lu
Y2x1ZGUgImNvcHlfdGVtcGxhdGUuUyIKKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNp
bmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisJLnRleHQKKwkuYWxpZ24JNQorRU5UUlko
bWVtY2hyKQorMToJc3VicwlyMiwgcjIsICMxCisJYm1pCTJmCisJbGRyYglyMywgW3IwXSwg
IzEKKwl0ZXEJcjMsIHIxCisJYm5lCTFiCisJc3ViCXIwLCByMCwgIzEKKzI6CW1vdm5lCXIw
LCAjMAorCW1vdglwYyxscgorLyoKKyAqICBsaW51eC9hcmNoL2FybS9saWIvbWVtbW92ZS5T
CisgKgorICogIEF1dGhvcjoJTmljb2xhcyBQaXRyZQorICogIENyZWF0ZWQ6CVNlcCAyOCwg
MjAwNQorICogIENvcHlyaWdodDoJKEMpIE1vbnRhVmlzdGEgU29mdHdhcmUgSW5jLgorICoK
KyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzCisgKiAgcHVibGlzaGVkIGJ5
IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKi8KKworI2luY2x1ZGUgPHhlbi9j
b25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisKKy8qCisgKiBUaGlz
IGNhbiBiZSB1c2VkIHRvIGVuYWJsZSBjb2RlIHRvIGNhY2hlbGluZSBhbGlnbiB0aGUgc291
cmNlIHBvaW50ZXIuCisgKiBFeHBlcmltZW50cyBvbiB0ZXN0ZWQgYXJjaGl0ZWN0dXJlcyAo
U3Ryb25nQVJNIGFuZCBYU2NhbGUpIGRpZG4ndCBzaG93CisgKiB0aGlzIGEgd29ydGh3aGls
ZSB0aGluZyB0byBkby4gIFRoYXQgbWlnaHQgYmUgZGlmZmVyZW50IGluIHRoZSBmdXR1cmUu
CisgKi8KKy8vI2RlZmluZSBDQUxHTihjb2RlLi4uKSAgICAgICAgY29kZQorI2RlZmluZSBD
QUxHTihjb2RlLi4uKQorCisJCS50ZXh0CisKKy8qCisgKiBQcm90b3R5cGU6IHZvaWQgKm1l
bW1vdmUodm9pZCAqZGVzdCwgY29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgbik7CisgKgorICog
Tm90ZToKKyAqCisgKiBJZiB0aGUgbWVtb3J5IHJlZ2lvbnMgZG9uJ3Qgb3ZlcmxhcCwgd2Ug
c2ltcGx5IGJyYW5jaCB0byBtZW1jcHkgd2hpY2ggaXMKKyAqIG5vcm1hbGx5IGEgYml0IGZh
c3Rlci4gT3RoZXJ3aXNlIHRoZSBjb3B5IGlzIGRvbmUgZ29pbmcgZG93bndhcmRzLiAgVGhp
cworICogaXMgYSB0cmFuc3Bvc2l0aW9uIG9mIHRoZSBjb2RlIGZyb20gY29weV90ZW1wbGF0
ZS5TIGJ1dCB3aXRoIHRoZSBjb3B5CisgKiBvY2N1cnJpbmcgaW4gdGhlIG9wcG9zaXRlIGRp
cmVjdGlvbi4KKyAqLworCitFTlRSWShtZW1tb3ZlKQorCisJCXN1YnMJaXAsIHIwLCByMQor
CQljbXBoaQlyMiwgaXAKKwkJYmxzCW1lbWNweQorCisJCXN0bWZkCXNwISwge3IwLCByNCwg
bHJ9CisJCWFkZAlyMSwgcjEsIHIyCisJCWFkZAlyMCwgcjAsIHIyCisJCXN1YnMJcjIsIHIy
LCAjNAorCQlibHQJOGYKKwkJYW5kcwlpcCwgcjAsICMzCisJUExEKAlwbGQJW3IxLCAjLTRd
CQkpCisJCWJuZQk5ZgorCQlhbmRzCWlwLCByMSwgIzMKKwkJYm5lCTEwZgorCisxOgkJc3Vi
cwlyMiwgcjIsICMoMjgpCisJCXN0bWZkCXNwISwge3I1IC0gcjh9CisJCWJsdAk1ZgorCisJ
Q0FMR04oCWFuZHMJaXAsIHIxLCAjMzEJCSkKKwlDQUxHTigJc2JjbmVzCXI0LCBpcCwgcjIJ
CSkgIEAgQyBpcyBhbHdheXMgc2V0IGhlcmUKKwlDQUxHTigJYmNzCTJmCQkJKQorCUNBTEdO
KAlhZHIJcjQsIDZmCQkJKQorCUNBTEdOKAlzdWJzCXIyLCByMiwgaXAJCSkgIEAgQyBpcyBz
ZXQgaGVyZQorCUNBTEdOKAlhZGQJcGMsIHI0LCBpcAkJKQorCisJUExEKAlwbGQJW3IxLCAj
LTRdCQkpCisyOglQTEQoCXN1YnMJcjIsIHIyLCAjOTYJCSkKKwlQTEQoCXBsZAlbcjEsICMt
MzJdCQkpCisJUExEKAlibHQJNGYJCQkpCisJUExEKAlwbGQJW3IxLCAjLTY0XQkJKQorCVBM
RCgJcGxkCVtyMSwgIy05Nl0JCSkKKworMzoJUExEKAlwbGQJW3IxLCAjLTEyOF0JCSkKKzQ6
CQlsZG1kYglyMSEsIHtyMywgcjQsIHI1LCByNiwgcjcsIHI4LCBpcCwgbHJ9CisJCXN1YnMJ
cjIsIHIyLCAjMzIKKwkJc3RtZGIJcjAhLCB7cjMsIHI0LCByNSwgcjYsIHI3LCByOCwgaXAs
IGxyfQorCQliZ2UJM2IKKwlQTEQoCWNtbglyMiwgIzk2CQkJKQorCVBMRCgJYmdlCTRiCQkJ
KQorCis1OgkJYW5kcwlpcCwgcjIsICMyOAorCQlyc2IJaXAsIGlwLCAjMzIKKwkJYWRkbmUJ
cGMsIHBjLCBpcAkJQCBDIGlzIGFsd2F5cyBjbGVhciBoZXJlCisJCWIJN2YKKzY6CQlub3AK
KwkJbGRyCXIzLCBbcjEsICMtNF0hCisJCWxkcglyNCwgW3IxLCAjLTRdIQorCQlsZHIJcjUs
IFtyMSwgIy00XSEKKwkJbGRyCXI2LCBbcjEsICMtNF0hCisJCWxkcglyNywgW3IxLCAjLTRd
IQorCQlsZHIJcjgsIFtyMSwgIy00XSEKKwkJbGRyCWxyLCBbcjEsICMtNF0hCisKKwkJYWRk
CXBjLCBwYywgaXAKKwkJbm9wCisJCW5vcAorCQlzdHIJcjMsIFtyMCwgIy00XSEKKwkJc3Ry
CXI0LCBbcjAsICMtNF0hCisJCXN0cglyNSwgW3IwLCAjLTRdIQorCQlzdHIJcjYsIFtyMCwg
Iy00XSEKKwkJc3RyCXI3LCBbcjAsICMtNF0hCisJCXN0cglyOCwgW3IwLCAjLTRdIQorCQlz
dHIJbHIsIFtyMCwgIy00XSEKKworCUNBTEdOKAliY3MJMmIJCQkpCisKKzc6CQlsZG1mZAlz
cCEsIHtyNSAtIHI4fQorCis4OgkJbW92cwlyMiwgcjIsIGxzbCAjMzEKKwkJbGRybmViCXIz
LCBbcjEsICMtMV0hCisJCWxkcmNzYglyNCwgW3IxLCAjLTFdIQorCQlsZHJjc2IJaXAsIFty
MSwgIy0xXQorCQlzdHJuZWIJcjMsIFtyMCwgIy0xXSEKKwkJc3RyY3NiCXI0LCBbcjAsICMt
MV0hCisJCXN0cmNzYglpcCwgW3IwLCAjLTFdCisJCWxkbWZkCXNwISwge3IwLCByNCwgcGN9
CisKKzk6CQljbXAJaXAsICMyCisJCWxkcmd0YglyMywgW3IxLCAjLTFdIQorCQlsZHJnZWIJ
cjQsIFtyMSwgIy0xXSEKKwkJbGRyYglsciwgW3IxLCAjLTFdIQorCQlzdHJndGIJcjMsIFty
MCwgIy0xXSEKKwkJc3RyZ2ViCXI0LCBbcjAsICMtMV0hCisJCXN1YnMJcjIsIHIyLCBpcAor
CQlzdHJiCWxyLCBbcjAsICMtMV0hCisJCWJsdAk4YgorCQlhbmRzCWlwLCByMSwgIzMKKwkJ
YmVxCTFiCisKKzEwOgkJYmljCXIxLCByMSwgIzMKKwkJY21wCWlwLCAjMgorCQlsZHIJcjMs
IFtyMSwgIzBdCisJCWJlcQkxN2YKKwkJYmx0CTE4ZgorCisKKwkJLm1hY3JvCWJhY2t3YXJk
X2NvcHlfc2hpZnQgcHVzaCBwdWxsCisKKwkJc3VicwlyMiwgcjIsICMyOAorCQlibHQJMTRm
CisKKwlDQUxHTigJYW5kcwlpcCwgcjEsICMzMQkJKQorCUNBTEdOKAlyc2IJaXAsIGlwLCAj
MzIJCSkKKwlDQUxHTigJc2JjbmVzCXI0LCBpcCwgcjIJCSkgIEAgQyBpcyBhbHdheXMgc2V0
IGhlcmUKKwlDQUxHTigJc3ViY2MJcjIsIHIyLCBpcAkJKQorCUNBTEdOKAliY2MJMTVmCQkJ
KQorCisxMToJCXN0bWZkCXNwISwge3I1IC0gcjl9CisKKwlQTEQoCXBsZAlbcjEsICMtNF0J
CSkKKwlQTEQoCXN1YnMJcjIsIHIyLCAjOTYJCSkKKwlQTEQoCXBsZAlbcjEsICMtMzJdCQkp
CisJUExEKAlibHQJMTNmCQkJKQorCVBMRCgJcGxkCVtyMSwgIy02NF0JCSkKKwlQTEQoCXBs
ZAlbcjEsICMtOTZdCQkpCisKKzEyOglQTEQoCXBsZAlbcjEsICMtMTI4XQkJKQorMTM6CQls
ZG1kYiAgIHIxISwge3I3LCByOCwgcjksIGlwfQorCQltb3YgICAgIGxyLCByMywgcHVzaCAj
XHB1c2gKKwkJc3VicyAgICByMiwgcjIsICMzMgorCQlsZG1kYiAgIHIxISwge3IzLCByNCwg
cjUsIHI2fQorCQlvcnIgICAgIGxyLCBsciwgaXAsIHB1bGwgI1xwdWxsCisJCW1vdiAgICAg
aXAsIGlwLCBwdXNoICNccHVzaAorCQlvcnIgICAgIGlwLCBpcCwgcjksIHB1bGwgI1xwdWxs
CisJCW1vdiAgICAgcjksIHI5LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI5LCByOSwgcjgs
IHB1bGwgI1xwdWxsCisJCW1vdiAgICAgcjgsIHI4LCBwdXNoICNccHVzaAorCQlvcnIgICAg
IHI4LCByOCwgcjcsIHB1bGwgI1xwdWxsCisJCW1vdiAgICAgcjcsIHI3LCBwdXNoICNccHVz
aAorCQlvcnIgICAgIHI3LCByNywgcjYsIHB1bGwgI1xwdWxsCisJCW1vdiAgICAgcjYsIHI2
LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI2LCByNiwgcjUsIHB1bGwgI1xwdWxsCisJCW1v
diAgICAgcjUsIHI1LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI1LCByNSwgcjQsIHB1bGwg
I1xwdWxsCisJCW1vdiAgICAgcjQsIHI0LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI0LCBy
NCwgcjMsIHB1bGwgI1xwdWxsCisJCXN0bWRiICAgcjAhLCB7cjQgLSByOSwgaXAsIGxyfQor
CQliZ2UJMTJiCisJUExEKAljbW4JcjIsICM5NgkJCSkKKwlQTEQoCWJnZQkxM2IJCQkpCisK
KwkJbGRtZmQJc3AhLCB7cjUgLSByOX0KKworMTQ6CQlhbmRzCWlwLCByMiwgIzI4CisJCWJl
cQkxNmYKKworMTU6CQltb3YgICAgIGxyLCByMywgcHVzaCAjXHB1c2gKKwkJbGRyCXIzLCBb
cjEsICMtNF0hCisJCXN1YnMJaXAsIGlwLCAjNAorCQlvcnIJbHIsIGxyLCByMywgcHVsbCAj
XHB1bGwKKwkJc3RyCWxyLCBbcjAsICMtNF0hCisJCWJndAkxNWIKKwlDQUxHTigJY21wCXIy
LCAjMAkJCSkKKwlDQUxHTigJYmdlCTExYgkJCSkKKworMTY6CQlhZGQJcjEsIHIxLCAjKFxw
dWxsIC8gOCkKKwkJYgk4YgorCisJCS5lbmRtCisKKworCQliYWNrd2FyZF9jb3B5X3NoaWZ0
CXB1c2g9OAlwdWxsPTI0CisKKzE3OgkJYmFja3dhcmRfY29weV9zaGlmdAlwdXNoPTE2CXB1
bGw9MTYKKworMTg6CQliYWNrd2FyZF9jb3B5X3NoaWZ0CXB1c2g9MjQJcHVsbD04CisKKyNp
bmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKwor
CS50ZXh0CisJLmFsaWduCTUKKwkud29yZAkwCisKKzE6CXN1YnMJcjIsIHIyLCAjNAkJQCAx
IGRvIHdlIGhhdmUgZW5vdWdoCisJYmx0CTVmCQkJQCAxIGJ5dGVzIHRvIGFsaWduIHdpdGg/
CisJY21wCXIzLCAjMgkJCUAgMQorCXN0cmx0YglyMSwgW3IwXSwgIzEJCUAgMQorCXN0cmxl
YglyMSwgW3IwXSwgIzEJCUAgMQorCXN0cmIJcjEsIFtyMF0sICMxCQlAIDEKKwlhZGQJcjIs
IHIyLCByMwkJQCAxIChyMiA9IHIyIC0gKDQgLSByMykpCisvKgorICogVGhlIHBvaW50ZXIg
aXMgbm93IGFsaWduZWQgYW5kIHRoZSBsZW5ndGggaXMgYWRqdXN0ZWQuICBUcnkgZG9pbmcg
dGhlCisgKiBtZW16ZXJvIGFnYWluLgorICovCisKK0VOVFJZKG1lbXNldCkKKwlhbmRzCXIz
LCByMCwgIzMJCUAgMSB1bmFsaWduZWQ/CisJYm5lCTFiCQkJQCAxCisvKgorICogd2Uga25v
dyB0aGF0IHRoZSBwb2ludGVyIGluIHIwIGlzIGFsaWduZWQgdG8gYSB3b3JkIGJvdW5kYXJ5
LgorICovCisJb3JyCXIxLCByMSwgcjEsIGxzbCAjOAorCW9ycglyMSwgcjEsIHIxLCBsc2wg
IzE2CisJbW92CXIzLCByMQorCWNtcAlyMiwgIzE2CisJYmx0CTRmCisvKgorICogV2UgbmVl
ZCBhbiBleHRyYSByZWdpc3RlciBmb3IgdGhpcyBsb29wIC0gc2F2ZSB0aGUgcmV0dXJuIGFk
ZHJlc3MgYW5kCisgKiB1c2UgdGhlIExSCisgKi8KKwlzdHIJbHIsIFtzcCwgIy00XSEKKwlt
b3YJaXAsIHIxCisJbW92CWxyLCByMQorCisyOglzdWJzCXIyLCByMiwgIzY0CisJc3RtZ2Vp
YQlyMCEsIHtyMSwgcjMsIGlwLCBscn0JQCA2NCBieXRlcyBhdCBhIHRpbWUuCisJc3RtZ2Vp
YQlyMCEsIHtyMSwgcjMsIGlwLCBscn0KKwlzdG1nZWlhCXIwISwge3IxLCByMywgaXAsIGxy
fQorCXN0bWdlaWEJcjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJYmd0CTJiCisJbGRtZXFmZCBz
cCEsIHtwY30JQCBOb3cgPDY0IGJ5dGVzIHRvIGdvLgorLyoKKyAqIE5vIG5lZWQgdG8gY29y
cmVjdCB0aGUgY291bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZyb20gbm93IG9uCisg
Ki8KKwl0c3QJcjIsICMzMgorCXN0bW5laWEJcjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJc3Rt
bmVpYQlyMCEsIHtyMSwgcjMsIGlwLCBscn0KKwl0c3QJcjIsICMxNgorCXN0bW5laWEJcjAh
LCB7cjEsIHIzLCBpcCwgbHJ9CisJbGRyCWxyLCBbc3BdLCAjNAorCis0Ogl0c3QJcjIsICM4
CisJc3RtbmVpYQlyMCEsIHtyMSwgcjN9CisJdHN0CXIyLCAjNAorCXN0cm5lCXIxLCBbcjBd
LCAjNAorLyoKKyAqIFdoZW4gd2UgZ2V0IGhlcmUsIHdlJ3ZlIGdvdCBsZXNzIHRoYW4gNCBi
eXRlcyB0byB6ZXJvLiAgV2UKKyAqIG1heSBoYXZlIGFuIHVuYWxpZ25lZCBwb2ludGVyIGFz
IHdlbGwuCisgKi8KKzU6CXRzdAlyMiwgIzIKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJc3Ry
bmViCXIxLCBbcjBdLCAjMQorCXRzdAlyMiwgIzEKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJ
bW92CXBjLGxyCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9hc20t
bWFjcm9zLmg+CisKKwkudGV4dAorCS5hbGlnbgk1CisJLndvcmQJMAorLyoKKyAqIEFsaWdu
IHRoZSBwb2ludGVyIGluIHIwLiAgcjMgY29udGFpbnMgdGhlIG51bWJlciBvZiBieXRlcyB0
aGF0IHdlIGFyZQorICogbWlzLWFsaWduZWQgYnksIGFuZCByMSBpcyB0aGUgbnVtYmVyIG9m
IGJ5dGVzLiAgSWYgcjEgPCA0LCB0aGVuIHdlCisgKiBkb24ndCBib3RoZXI7IHdlIHVzZSBi
eXRlIHN0b3JlcyBpbnN0ZWFkLgorICovCisxOglzdWJzCXIxLCByMSwgIzQJCUAgMSBkbyB3
ZSBoYXZlIGVub3VnaAorCWJsdAk1ZgkJCUAgMSBieXRlcyB0byBhbGlnbiB3aXRoPworCWNt
cAlyMywgIzIJCQlAIDEKKwlzdHJsdGIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJsZWIJcjIs
IFtyMF0sICMxCQlAIDEKKwlzdHJiCXIyLCBbcjBdLCAjMQkJQCAxCisJYWRkCXIxLCByMSwg
cjMJCUAgMSAocjEgPSByMSAtICg0IC0gcjMpKQorLyoKKyAqIFRoZSBwb2ludGVyIGlzIG5v
dyBhbGlnbmVkIGFuZCB0aGUgbGVuZ3RoIGlzIGFkanVzdGVkLiAgVHJ5IGRvaW5nIHRoZQor
ICogbWVtemVybyBhZ2Fpbi4KKyAqLworCitFTlRSWShfX21lbXplcm8pCisJbW92CXIyLCAj
MAkJCUAgMQorCWFuZHMJcjMsIHIwLCAjMwkJQCAxIHVuYWxpZ25lZD8KKwlibmUJMWIJCQlA
IDEKKy8qCisgKiByMyA9IDAsIGFuZCB3ZSBrbm93IHRoYXQgdGhlIHBvaW50ZXIgaW4gcjAg
aXMgYWxpZ25lZCB0byBhIHdvcmQgYm91bmRhcnkuCisgKi8KKwljbXAJcjEsICMxNgkJCUAg
MSB3ZSBjYW4gc2tpcCB0aGlzIGNodW5rIGlmIHdlCisJYmx0CTRmCQkJQCAxIGhhdmUgPCAx
NiBieXRlcworLyoKKyAqIFdlIG5lZWQgYW4gZXh0cmEgcmVnaXN0ZXIgZm9yIHRoaXMgbG9v
cCAtIHNhdmUgdGhlIHJldHVybiBhZGRyZXNzIGFuZAorICogdXNlIHRoZSBMUgorICovCisJ
c3RyCWxyLCBbc3AsICMtNF0hCQlAIDEKKwltb3YJaXAsIHIyCQkJQCAxCisJbW92CWxyLCBy
MgkJCUAgMQorCiszOglzdWJzCXIxLCByMSwgIzY0CQlAIDEgd3JpdGUgMzIgYnl0ZXMgb3V0
IHBlciBsb29wCisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2Vp
YQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlw
LCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJYmd0CTNi
CQkJQCAxCisJbGRtZXFmZCBzcCEsIHtwY30JQCAxLzIgcXVpY2sgZXhpdAorLyoKKyAqIE5v
IG5lZWQgdG8gY29ycmVjdCB0aGUgY291bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZy
b20gbm93IG9uCisgKi8KKwl0c3QJcjEsICMzMgkJCUAgMQorCXN0bW5laWEJcjAhLCB7cjIs
IHIzLCBpcCwgbHJ9CUAgNAorCXN0bW5laWEJcjAhLCB7cjIsIHIzLCBpcCwgbHJ9CUAgNAor
CXRzdAlyMSwgIzE2CQkJQCAxIDE2IGJ5dGVzIG9yIG1vcmU/CisJc3RtbmVpYQlyMCEsIHty
MiwgcjMsIGlwLCBscn0JQCA0CisJbGRyCWxyLCBbc3BdLCAjNAkJQCAxCisKKzQ6CXRzdAly
MSwgIzgJCQlAIDEgOCBieXRlcyBvciBtb3JlPworCXN0bW5laWEJcjAhLCB7cjIsIHIzfQkJ
QCAyCisJdHN0CXIxLCAjNAkJCUAgMSA0IGJ5dGVzIG9yIG1vcmU/CisJc3RybmUJcjIsIFty
MF0sICM0CQlAIDEKKy8qCisgKiBXaGVuIHdlIGdldCBoZXJlLCB3ZSd2ZSBnb3QgbGVzcyB0
aGFuIDQgYnl0ZXMgdG8gemVyby4gIFdlCisgKiBtYXkgaGF2ZSBhbiB1bmFsaWduZWQgcG9p
bnRlciBhcyB3ZWxsLgorICovCis1Ogl0c3QJcjEsICMyCQkJQCAxIDIgYnl0ZXMgb3IgbW9y
ZT8KKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlA
IDEKKwl0c3QJcjEsICMxCQkJQCAxIGEgYnl0ZSBsZWZ0IG92ZXIKKwlzdHJuZWIJcjIsIFty
MF0sICMxCQlAIDEKKwltb3YJcGMsbHIJCUAgMQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0vbGliL21lbXNldC5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvbWVtc2V0LlMJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjkgQEAKKyNpbmNsdWRlIDx4ZW4v
Y29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworCS50ZXh0CisJLmFs
aWduCTUKKwkud29yZAkwCisKKzE6CXN1YnMJcjIsIHIyLCAjNAkJQCAxIGRvIHdlIGhhdmUg
ZW5vdWdoCisJYmx0CTVmCQkJQCAxIGJ5dGVzIHRvIGFsaWduIHdpdGg/CisJY21wCXIzLCAj
MgkJCUAgMQorCXN0cmx0YglyMSwgW3IwXSwgIzEJCUAgMQorCXN0cmxlYglyMSwgW3IwXSwg
IzEJCUAgMQorCXN0cmIJcjEsIFtyMF0sICMxCQlAIDEKKwlhZGQJcjIsIHIyLCByMwkJQCAx
IChyMiA9IHIyIC0gKDQgLSByMykpCisvKgorICogVGhlIHBvaW50ZXIgaXMgbm93IGFsaWdu
ZWQgYW5kIHRoZSBsZW5ndGggaXMgYWRqdXN0ZWQuICBUcnkgZG9pbmcgdGhlCisgKiBtZW16
ZXJvIGFnYWluLgorICovCisKK0VOVFJZKG1lbXNldCkKKwlhbmRzCXIzLCByMCwgIzMJCUAg
MSB1bmFsaWduZWQ/CisJYm5lCTFiCQkJQCAxCisvKgorICogd2Uga25vdyB0aGF0IHRoZSBw
b2ludGVyIGluIHIwIGlzIGFsaWduZWQgdG8gYSB3b3JkIGJvdW5kYXJ5LgorICovCisJb3Jy
CXIxLCByMSwgcjEsIGxzbCAjOAorCW9ycglyMSwgcjEsIHIxLCBsc2wgIzE2CisJbW92CXIz
LCByMQorCWNtcAlyMiwgIzE2CisJYmx0CTRmCisvKgorICogV2UgbmVlZCBhbiBleHRyYSBy
ZWdpc3RlciBmb3IgdGhpcyBsb29wIC0gc2F2ZSB0aGUgcmV0dXJuIGFkZHJlc3MgYW5kCisg
KiB1c2UgdGhlIExSCisgKi8KKwlzdHIJbHIsIFtzcCwgIy00XSEKKwltb3YJaXAsIHIxCisJ
bW92CWxyLCByMQorCisyOglzdWJzCXIyLCByMiwgIzY0CisJc3RtZ2VpYQlyMCEsIHtyMSwg
cjMsIGlwLCBscn0JQCA2NCBieXRlcyBhdCBhIHRpbWUuCisJc3RtZ2VpYQlyMCEsIHtyMSwg
cjMsIGlwLCBscn0KKwlzdG1nZWlhCXIwISwge3IxLCByMywgaXAsIGxyfQorCXN0bWdlaWEJ
cjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJYmd0CTJiCisJbGRtZXFmZCBzcCEsIHtwY30JQCBO
b3cgPDY0IGJ5dGVzIHRvIGdvLgorLyoKKyAqIE5vIG5lZWQgdG8gY29ycmVjdCB0aGUgY291
bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZyb20gbm93IG9uCisgKi8KKwl0c3QJcjIs
ICMzMgorCXN0bW5laWEJcjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJc3RtbmVpYQlyMCEsIHty
MSwgcjMsIGlwLCBscn0KKwl0c3QJcjIsICMxNgorCXN0bW5laWEJcjAhLCB7cjEsIHIzLCBp
cCwgbHJ9CisJbGRyCWxyLCBbc3BdLCAjNAorCis0Ogl0c3QJcjIsICM4CisJc3RtbmVpYQly
MCEsIHtyMSwgcjN9CisJdHN0CXIyLCAjNAorCXN0cm5lCXIxLCBbcjBdLCAjNAorLyoKKyAq
IFdoZW4gd2UgZ2V0IGhlcmUsIHdlJ3ZlIGdvdCBsZXNzIHRoYW4gNCBieXRlcyB0byB6ZXJv
LiAgV2UKKyAqIG1heSBoYXZlIGFuIHVuYWxpZ25lZCBwb2ludGVyIGFzIHdlbGwuCisgKi8K
KzU6CXRzdAlyMiwgIzIKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJc3RybmViCXIxLCBbcjBd
LCAjMQorCXRzdAlyMiwgIzEKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJbW92CXBjLGxyCmRp
ZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvbWVtemVyby5TCi0tLSAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2Fy
bS9saWIvbWVtemVyby5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCww
ICsxLDcxIEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9hc20t
bWFjcm9zLmg+CisKKwkudGV4dAorCS5hbGlnbgk1CisJLndvcmQJMAorLyoKKyAqIEFsaWdu
IHRoZSBwb2ludGVyIGluIHIwLiAgcjMgY29udGFpbnMgdGhlIG51bWJlciBvZiBieXRlcyB0
aGF0IHdlIGFyZQorICogbWlzLWFsaWduZWQgYnksIGFuZCByMSBpcyB0aGUgbnVtYmVyIG9m
IGJ5dGVzLiAgSWYgcjEgPCA0LCB0aGVuIHdlCisgKiBkb24ndCBib3RoZXI7IHdlIHVzZSBi
eXRlIHN0b3JlcyBpbnN0ZWFkLgorICovCisxOglzdWJzCXIxLCByMSwgIzQJCUAgMSBkbyB3
ZSBoYXZlIGVub3VnaAorCWJsdAk1ZgkJCUAgMSBieXRlcyB0byBhbGlnbiB3aXRoPworCWNt
cAlyMywgIzIJCQlAIDEKKwlzdHJsdGIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJsZWIJcjIs
IFtyMF0sICMxCQlAIDEKKwlzdHJiCXIyLCBbcjBdLCAjMQkJQCAxCisJYWRkCXIxLCByMSwg
cjMJCUAgMSAocjEgPSByMSAtICg0IC0gcjMpKQorLyoKKyAqIFRoZSBwb2ludGVyIGlzIG5v
dyBhbGlnbmVkIGFuZCB0aGUgbGVuZ3RoIGlzIGFkanVzdGVkLiAgVHJ5IGRvaW5nIHRoZQor
ICogbWVtemVybyBhZ2Fpbi4KKyAqLworCitFTlRSWShfX21lbXplcm8pCisJbW92CXIyLCAj
MAkJCUAgMQorCWFuZHMJcjMsIHIwLCAjMwkJQCAxIHVuYWxpZ25lZD8KKwlibmUJMWIJCQlA
IDEKKy8qCisgKiByMyA9IDAsIGFuZCB3ZSBrbm93IHRoYXQgdGhlIHBvaW50ZXIgaW4gcjAg
aXMgYWxpZ25lZCB0byBhIHdvcmQgYm91bmRhcnkuCisgKi8KKwljbXAJcjEsICMxNgkJCUAg
MSB3ZSBjYW4gc2tpcCB0aGlzIGNodW5rIGlmIHdlCisJYmx0CTRmCQkJQCAxIGhhdmUgPCAx
NiBieXRlcworLyoKKyAqIFdlIG5lZWQgYW4gZXh0cmEgcmVnaXN0ZXIgZm9yIHRoaXMgbG9v
cCAtIHNhdmUgdGhlIHJldHVybiBhZGRyZXNzIGFuZAorICogdXNlIHRoZSBMUgorICovCisJ
c3RyCWxyLCBbc3AsICMtNF0hCQlAIDEKKwltb3YJaXAsIHIyCQkJQCAxCisJbW92CWxyLCBy
MgkJCUAgMQorCiszOglzdWJzCXIxLCByMSwgIzY0CQlAIDEgd3JpdGUgMzIgYnl0ZXMgb3V0
IHBlciBsb29wCisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2Vp
YQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlw
LCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJYmd0CTNi
CQkJQCAxCisJbGRtZXFmZCBzcCEsIHtwY30JQCAxLzIgcXVpY2sgZXhpdAorLyoKKyAqIE5v
IG5lZWQgdG8gY29ycmVjdCB0aGUgY291bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZy
b20gbm93IG9uCisgKi8KKwl0c3QJcjEsICMzMgkJCUAgMQorCXN0bW5laWEJcjAhLCB7cjIs
IHIzLCBpcCwgbHJ9CUAgNAorCXN0bW5laWEJcjAhLCB7cjIsIHIzLCBpcCwgbHJ9CUAgNAor
CXRzdAlyMSwgIzE2CQkJQCAxIDE2IGJ5dGVzIG9yIG1vcmU/CisJc3RtbmVpYQlyMCEsIHty
MiwgcjMsIGlwLCBscn0JQCA0CisJbGRyCWxyLCBbc3BdLCAjNAkJQCAxCisKKzQ6CXRzdAly
MSwgIzgJCQlAIDEgOCBieXRlcyBvciBtb3JlPworCXN0bW5laWEJcjAhLCB7cjIsIHIzfQkJ
QCAyCisJdHN0CXIxLCAjNAkJCUAgMSA0IGJ5dGVzIG9yIG1vcmU/CisJc3RybmUJcjIsIFty
MF0sICM0CQlAIDEKKy8qCisgKiBXaGVuIHdlIGdldCBoZXJlLCB3ZSd2ZSBnb3QgbGVzcyB0
aGFuIDQgYnl0ZXMgdG8gemVyby4gIFdlCisgKiBtYXkgaGF2ZSBhbiB1bmFsaWduZWQgcG9p
bnRlciBhcyB3ZWxsLgorICovCis1Ogl0c3QJcjEsICMyCQkJQCAxIDIgYnl0ZXMgb3IgbW9y
ZT8KKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlA
IDEKKwl0c3QJcjEsICMxCQkJQCAxIGEgYnl0ZSBsZWZ0IG92ZXIKKwlzdHJuZWIJcjIsIFty
MF0sICMxCQlAIDEKKwltb3YJcGMsbHIJCUAgMQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0vbGliL211bGRpMy5jCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvbXVsZGkzLmMJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsODYgQEAKKy8qIE1vcmUgc3Vicm91
dGluZXMgbmVlZGVkIGJ5IEdDQyBvdXRwdXQgY29kZSBvbiBzb21lIG1hY2hpbmVzLiAgKi8K
Ky8qIENvbXBpbGUgdGhpcyBvbmUgd2l0aCBnY2MuICAqLworLyogQ29weXJpZ2h0IChDKSAx
OTg5LCA5Mi05OCwgMTk5OSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhp
cyBmaWxlIGlzIHBhcnQgb2YgR05VIENDLgorCitHTlUgQ0MgaXMgZnJlZSBzb2Z0d2FyZTsg
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQoraXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkK
K3RoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9yIChh
dCB5b3VyIG9wdGlvbikKK2FueSBsYXRlciB2ZXJzaW9uLgorCitHTlUgQ0MgaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKK2J1dCBXSVRIT1VU
IEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCitN
RVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlCitHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgor
CitZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQ
dWJsaWMgTGljZW5zZQorYWxvbmcgd2l0aCBHTlUgQ0M7IHNlZSB0aGUgZmlsZSBDT1BZSU5H
LiAgSWYgbm90LCB3cml0ZSB0bwordGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgNTkg
VGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLAorQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0Eu
ICAqLworCisvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCBpZiB5b3UgbGluayB0aGlzIGxp
YnJhcnkgd2l0aCBvdGhlciBmaWxlcywKKyAgIHNvbWUgb2Ygd2hpY2ggYXJlIGNvbXBpbGVk
IHdpdGggR0NDLCB0byBwcm9kdWNlIGFuIGV4ZWN1dGFibGUsCisgICB0aGlzIGxpYnJhcnkg
ZG9lcyBub3QgYnkgaXRzZWxmIGNhdXNlIHRoZSByZXN1bHRpbmcgZXhlY3V0YWJsZQorICAg
dG8gYmUgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UuCisgICBU
aGlzIGV4Y2VwdGlvbiBkb2VzIG5vdCBob3dldmVyIGludmFsaWRhdGUgYW55IG90aGVyIHJl
YXNvbnMgd2h5CisgICB0aGUgZXhlY3V0YWJsZSBmaWxlIG1pZ2h0IGJlIGNvdmVyZWQgYnkg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLgorICovCisvKiBzdXBwb3J0IGZ1bmN0
aW9ucyByZXF1aXJlZCBieSB0aGUga2VybmVsLiBiYXNlZCBvbiBjb2RlIGZyb20gZ2NjLTIu
OTUuMyAqLworLyogSSBNb2x0b24gICAgIDI5LzA3LzAxICovCisKKyNpbmNsdWRlICJnY2Ns
aWIuaCIKKworI2RlZmluZSB1bXVsX3BwbW0oeGgsIHhsLCBhLCBiKSBcCit7cmVnaXN0ZXIg
VVNJdHlwZSBfX3QwLCBfX3QxLCBfX3QyOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCisgIF9fYXNtX18gKCIlQCBJbmxpbmVkIHVtdWxfcHBtbQkJCQkJXG5cCisg
ICAgICAgIG1vdiAgICAgJTIsICU1LCBsc3IgIzE2CQkJCQkJXG5cCisgICAgICAgIG1vdiAg
ICAgJTAsICU2LCBsc3IgIzE2CQkJCQkJXG5cCisgICAgICAgIGJpYyAgICAgJTMsICU1LCAl
MiwgbHNsICMxNgkJCQkJXG5cCisgICAgICAgIGJpYyAgICAgJTQsICU2LCAlMCwgbHNsICMx
NgkJCQkJXG5cCisgICAgICAgIG11bCAgICAgJTEsICUzLCAlNAkJCQkJCVxuXAorICAgICAg
ICBtdWwgICAgICU0LCAlMiwgJTQJCQkJCQlcblwKKyAgICAgICAgbXVsICAgICAlMywgJTAs
ICUzCQkJCQkJXG5cCisgICAgICAgIG11bCAgICAgJTAsICUyLCAlMAkJCQkJCVxuXAorICAg
ICAgICBhZGRzICAgICUzLCAlNCwgJTMJCQkJCQlcblwKKyAgICAgICAgYWRkY3MgICAlMCwg
JTAsICM2NTUzNgkJCQkJCVxuXAorICAgICAgICBhZGRzICAgICUxLCAlMSwgJTMsIGxzbCAj
MTYJCQkJCVxuXAorICAgICAgICBhZGMgICAgICUwLCAlMCwgJTMsIGxzciAjMTYiICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICA6ICI9JnIiICgo
VVNJdHlwZSkgKHhoKSksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgICI9ciIgKChVU0l0eXBlKSAoeGwpKSwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICI9JnIiIChfX3QwKSwgIj0mciIg
KF9fdDEpLCAiPXIiIChfX3QyKSAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICA6
ICJyIiAoKFVTSXR5cGUpIChhKSksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXAorICAgICAgICAgICAgICJyIiAoKFVTSXR5cGUpIChiKSkpO30KKworCisjZGVm
aW5lIF9fdW11bHNpZGkzKHUsIHYpIFwKKyAgKHtESXVuaW9uIF9fdzsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB1bXVs
X3BwbW0gKF9fdy5zLmhpZ2gsIF9fdy5zLmxvdywgdSwgdik7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICBfX3cubGw7IH0pCisKKworREl0eXBlCitfX211bGRpMyAoREl0
eXBlIHUsIERJdHlwZSB2KQoreworICBESXVuaW9uIHc7CisgIERJdW5pb24gdXUsIHZ2Owor
CisgIHV1LmxsID0gdSwKKyAgdnYubGwgPSB2OworCisgIHcubGwgPSBfX3VtdWxzaWRpMyAo
dXUucy5sb3csIHZ2LnMubG93KTsKKyAgdy5zLmhpZ2ggKz0gKChVU0l0eXBlKSB1dS5zLmxv
dyAqIChVU0l0eXBlKSB2di5zLmhpZ2gKKyAgICAgICAgICAgICAgICsgKFVTSXR5cGUpIHV1
LnMuaGlnaCAqIChVU0l0eXBlKSB2di5zLmxvdyk7CisKKyAgcmV0dXJuIHcubGw7Cit9CisK
KyNpZiAwCitsbGRpdl90X3JyIF9fYWVhYmlfbGRpdm1vZCAobG9uZyBsb25nIGEsIGxvbmcg
bG9uZyBiKSAKK3sgCisJbGxkaXZfdF9yciByOyAKKwlyLnF1b3QgPV9fZGl2ZGkzIChhLCBi
KTsgCisJci5yZW0gPSBhIC0gYiAqIHIucXVvdDsgCisJcmV0dXJuIHI7IAorfQorI2VuZGlm
CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvcHV0dXNlci5TCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNo
L2FybS9saWIvcHV0dXNlci5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAt
MCwwICsxLDc1IEBACisvKgorICogIGxpbnV4L2FyY2gvYXJtL2xpYi9wdXR1c2VyLlMKKyAq
CisgKiAgQ29weXJpZ2h0IChDKSAyMDAxIFJ1c3NlbGwgS2luZworICoKKyAqIFRoaXMgcHJv
Z3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIHZlcnNpb24gMiBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uCisgKgorICogIElkZWEgZnJvbSB4ODYgdmVyc2lvbiwgKEMpIENv
cHlyaWdodCAxOTk4IExpbnVzIFRvcnZhbGRzCisgKgorICogVGhlc2UgZnVuY3Rpb25zIGhh
dmUgYSBub24tc3RhbmRhcmQgY2FsbCBpbnRlcmZhY2UgdG8gbWFrZQorICogdGhlbSBtb3Jl
IGVmZmljaWVudCwgZXNwZWNpYWxseSBhcyB0aGV5IHJldHVybiBhbiBlcnJvcgorICogdmFs
dWUgaW4gYWRkaXRpb24gdG8gdGhlICJyZWFsIiByZXR1cm4gdmFsdWUuCisgKgorICogX19w
dXRfdXNlcl9YCisgKgorICogSW5wdXRzOglyMCBjb250YWlucyB0aGUgYWRkcmVzcworICoJ
CXIyLCByMyBjb250YWlucyB0aGUgdmFsdWUKKyAqIE91dHB1dHM6CXIwIGlzIHRoZSBlcnJv
ciBjb2RlCisgKgkJbHIgY29ycnVwdGVkCisgKgorICogTm8gb3RoZXIgcmVnaXN0ZXJzIG11
c3QgYmUgYWx0ZXJlZC4gIChzZWUgaW5jbHVkZS9hc20tYXJtL3VhY2Nlc3MuaAorICogZm9y
IHNwZWNpZmljIEFTTSByZWdpc3RlciB1c2FnZSkuCisgKgorICogTm90ZSB0aGF0IEFERFJf
TElNSVQgaXMgZWl0aGVyIDAgb3IgMHhjMDAwMDAwMAorICogTm90ZSBhbHNvIHRoYXQgaXQg
aXMgaW50ZW5kZWQgdGhhdCBfX3B1dF91c2VyX2JhZCBpcyBub3QgZ2xvYmFsLgorICovCisj
aW5jbHVkZSA8eGVuL2Vycm5vLmg+CisKKwkuZ2xvYmFsCV9fcHV0X3VzZXJfMQorX19wdXRf
dXNlcl8xOgorMToJc3RyYnQJcjIsIFtyMF0KKwltb3YJcjAsICMwCisJbW92CXBjLCBscgor
CisJLmdsb2JhbAlfX3B1dF91c2VyXzIKK19fcHV0X3VzZXJfMjoKKwltb3YJaXAsIHIyLCBs
c3IgIzgKKyNpZm5kZWYgX19BUk1FQl9fCisyOglzdHJidAlyMiwgW3IwXSwgIzEKKzM6CXN0
cmJ0CWlwLCBbcjBdCisjZWxzZQorMjoJc3RyYnQJaXAsIFtyMF0sICMxCiszOglzdHJidAly
MiwgW3IwXQorI2VuZGlmCisJbW92CXIwLCAjMAorCW1vdglwYywgbHIKKworCS5nbG9iYWwJ
X19wdXRfdXNlcl80CitfX3B1dF91c2VyXzQ6Cis0OglzdHJ0CXIyLCBbcjBdCisJbW92CXIw
LCAjMAorCW1vdglwYywgbHIKKworCS5nbG9iYWwJX19wdXRfdXNlcl84CitfX3B1dF91c2Vy
Xzg6Cis1OglzdHJ0CXIyLCBbcjBdLCAjNAorNjoJc3RydAlyMywgW3IwXQorCW1vdglyMCwg
IzAKKwltb3YJcGMsIGxyCisKKwkuZ2xvYmFsIF9fcHV0X3VzZXJfYmFkCitfX3B1dF91c2Vy
X2JhZDoKKwltb3YJcjAsICMtRUZBVUxUCisJbW92CXBjLCBscgorCisuc2VjdGlvbiAuZXh0
YWJsZSwgImEiCisJLmxvbmcJMWIsIF9fcHV0X3VzZXJfYmFkCisJLmxvbmcJMmIsIF9fcHV0
X3VzZXJfYmFkCisJLmxvbmcJM2IsIF9fcHV0X3VzZXJfYmFkCisJLmxvbmcJNGIsIF9fcHV0
X3VzZXJfYmFkCisJLmxvbmcJNWIsIF9fcHV0X3VzZXJfYmFkCisJLmxvbmcJNmIsIF9fcHV0
X3VzZXJfYmFkCisucHJldmlvdXMKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJt
L2xpYi9zZXRiaXQuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL3NldGJpdC5TCUZyaSBGZWIgMDMgMTY6MDc6
MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDIyIEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5o
PgorI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jv
cy5oPgorCisJCS50ZXh0CisKKy8qCisgKiBQdXJwb3NlICA6IEZ1bmN0aW9uIHRvIHNldCBh
IGJpdAorICogUHJvdG90eXBlOiBpbnQgc2V0X2JpdChpbnQgYml0LCB2b2lkICphZGRyKQor
ICovCitFTlRSWShfc2V0X2JpdF9iZSkKKwllb3IJcjAsIHIwLCAjMHgxOAkJQCBiaWcgZW5k
aWFuIGJ5dGUgb3JkZXJpbmcKK0VOVFJZKF9zZXRfYml0X2xlKQorCWFuZAlyMiwgcjAsICM3
CisJbW92CXIzLCAjMQorCW1vdglyMywgcjMsIGxzbCByMgorCXNhdmVfYW5kX2Rpc2FibGVf
aXJxcyBpcCwgcjIKKwlsZHJiCXIyLCBbcjEsIHIwLCBsc3IgIzNdCisJb3JyCXIyLCByMiwg
cjMKKwlzdHJiCXIyLCBbcjEsIHIwLCBsc3IgIzNdCisJcmVzdG9yZV9pcnFzIGlwCisJbW92
CXBjLCBscgpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL3N0cmNoci5T
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hl
bi9hcmNoL2FybS9saWIvc3RyY2hyLlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAw
CkBAIC0wLDAgKzEsMTUgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8
YXNtL2FzbS1tYWNyb3MuaD4KKworCQkudGV4dAorCQkuYWxpZ24JNQorRU5UUlkoc3RyY2hy
KQorCQlhbmQJcjEsIHIxLCAjMHhmZgorMToJCWxkcmIJcjIsIFtyMF0sICMxCisJCXRlcQly
MiwgcjEKKwkJdGVxbmUJcjIsICMwCisJCWJuZQkxYgorCQl0ZXEJcjIsIHIxCisJCW1vdm5l
CXIwLCAjMAorCQlzdWJlcQlyMCwgcjAsICMxCisJCW1vdglwYyxscgpkaWZmIC1yIGU3MDE0
NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL3Rlc3RjaGFuZ2ViaXQuUwotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGli
L3Rlc3RjaGFuZ2ViaXQuUwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAs
MCArMSwyMiBAQAorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vcHJv
Y2Vzc29yLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworICAgICAgICAgICAg
ICAgIC50ZXh0CisKK0VOVFJZKF90ZXN0X2FuZF9jaGFuZ2VfYml0X2JlKQorCQllb3IJcjAs
IHIwLCAjMHgxOAkJQCBiaWcgZW5kaWFuIGJ5dGUgb3JkZXJpbmcKK0VOVFJZKF90ZXN0X2Fu
ZF9jaGFuZ2VfYml0X2xlKQorCQlhZGQJcjEsIHIxLCByMCwgbHNyICMzCisJCWFuZAlyMywg
cjAsICM3CisJCW1vdglyMCwgIzEKKwkJc2F2ZV9hbmRfZGlzYWJsZV9pcnFzIGlwLCByMgor
CQlsZHJiCXIyLCBbcjFdCisJCXRzdAlyMiwgcjAsIGxzbCByMworCQllb3IJcjIsIHIyLCBy
MCwgbHNsIHIzCisJCXN0cmIJcjIsIFtyMV0KKwkJcmVzdG9yZV9pcnFzIGlwCisJCW1vdmVx
CXIwLCAjMAorCQltb3YJcGMsbHIKKworCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNo
L2FybS9saWIvdGVzdGNsZWFyYml0LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi90ZXN0Y2xlYXJiaXQuUwlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyMiBAQAorI2luY2x1
ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vcHJvY2Vzc29yLmg+CisjaW5jbHVk
ZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworICAgICAgICAgICAgICAgIC50ZXh0CisKK0VOVFJZ
KF90ZXN0X2FuZF9jbGVhcl9iaXRfYmUpCisJCWVvcglyMCwgcjAsICMweDE4CQlAIGJpZyBl
bmRpYW4gYnl0ZSBvcmRlcmluZworRU5UUlkoX3Rlc3RfYW5kX2NsZWFyX2JpdF9sZSkKKwkJ
YWRkCXIxLCByMSwgcjAsIGxzciAjMwlAIEdldCBieXRlIG9mZnNldAorCQlhbmQJcjMsIHIw
LCAjNwkJQCBHZXQgYml0IG9mZnNldAorCQltb3YJcjAsICMxCisJCXNhdmVfYW5kX2Rpc2Fi
bGVfaXJxcyBpcCwgcjIKKwkJbGRyYglyMiwgW3IxXQorCQl0c3QJcjIsIHIwLCBsc2wgcjMK
KwkJYmljbmUJcjIsIHIyLCByMCwgbHNsIHIzCisJCXN0cm5lYglyMiwgW3IxXQorCQlyZXN0
b3JlX2lycXMgaXAKKwkJbW92ZXEJcjAsICMwCisJCW1vdglwYyxscgorCisKZGlmZiAtciBl
NzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL2xpYi90ZXN0c2V0Yml0LlMKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xp
Yi90ZXN0c2V0Yml0LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAg
KzEsMjAgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL3Byb2Nl
c3Nvci5oPgorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisKKyAgICAgICAgICAgICAg
ICAudGV4dAorCitFTlRSWShfdGVzdF9hbmRfc2V0X2JpdF9sZSkKKwkJYWRkCXIxLCByMSwg
cjAsIGxzciAjMwlAIEdldCBieXRlIG9mZnNldAorCQlhbmQJcjMsIHIwLCAjNwkJQCBHZXQg
Yml0IG9mZnNldAorCQltb3YJcjAsICMxCisJCXNhdmVfYW5kX2Rpc2FibGVfaXJxcyBpcCwg
cjIKKwkJbGRyYglyMiwgW3IxXQorCQl0c3QJcjIsIHIwLCBsc2wgcjMKKwkJb3JyZXEJcjIs
IHIyLCByMCwgbHNsIHIzCisJCXN0cmVxYglyMiwgW3IxXQorCQlyZXN0b3JlX2lycXMgaXAK
KwkJbW92ZXEJcjAsICMwCisJCW1vdglwYyxscgorCisKZGlmZiAtciBlNzAxNDYxYjEyNTEg
eGVuL2FyY2gvYXJtL2xpYi91YWNjZXNzLlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi91YWNjZXNzLlMJRnJp
IEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjg0IEBACisjaW5jbHVk
ZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPGFz
bS9hc20tbWFjcm9zLmg+CisKKwkJLnRleHQKKworI2RlZmluZSBQQUdFX1NISUZUIDEyCisK
Ky8qIFByb3RvdHlwZTogaW50IF9fYXJjaF9jb3B5X3RvX3VzZXIodm9pZCAqdG8sIGNvbnN0
IGNoYXIgKmZyb20sIHNpemVfdCBuKQorICogUHVycG9zZSAgOiBjb3B5IGEgYmxvY2sgdG8g
dXNlciBtZW1vcnkgZnJvbSBrZXJuZWwgbWVtb3J5CisgKiBQYXJhbXMgICA6IHRvICAgLSB1
c2VyIG1lbW9yeQorICogICAgICAgICAgOiBmcm9tIC0ga2VybmVsIG1lbW9yeQorICogICAg
ICAgICAgOiBuICAgIC0gbnVtYmVyIG9mIGJ5dGVzIHRvIGNvcHkKKyAqIFJldHVybnMgIDog
TnVtYmVyIG9mIGJ5dGVzIE5PVCBjb3BpZWQuCisgKi8KKworLmMydV9kZXN0X25vdF9hbGln
bmVkOgorCQlyc2IJaXAsIGlwLCAjNAorCQljbXAJaXAsICMyCisJCWxkcmIJcjMsIFtyMV0s
ICMxCitVU0VSKAkJc3RyYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCWxkcmdl
YglyMywgW3IxXSwgIzEKK1VTRVIoCQlzdHJnZWJ0CXIzLCBbcjBdLCAjMSkJCQlAIE1heSBm
YXVsdAorCQlsZHJndGIJcjMsIFtyMV0sICMxCitVU0VSKAkJc3RyZ3RidAlyMywgW3IwXSwg
IzEpCQkJQCBNYXkgZmF1bHQKKwkJc3ViCXIyLCByMiwgaXAKKwkJYgkuYzJ1X2Rlc3RfYWxp
Z25lZAorCitFTlRSWShfX2FyY2hfY29weV90b191c2VyKQorCQlzdG1mZAlzcCEsIHtyMiwg
cjQgLSByNywgbHJ9CisJCWNtcAlyMiwgIzQKKwkJYmx0CS5jMnVfbm90X2Vub3VnaAorCVBM
RCgJcGxkCVtyMSwgIzBdCQkpCisJUExEKAlwbGQJW3IwLCAjMF0JCSkKKwkJYW5kcwlpcCwg
cjAsICMzCisJCWJuZQkuYzJ1X2Rlc3Rfbm90X2FsaWduZWQKKy5jMnVfZGVzdF9hbGlnbmVk
OgorCisJCWFuZHMJaXAsIHIxLCAjMworCQlibmUJLmMydV9zcmNfbm90X2FsaWduZWQKKy8q
CisgKiBTZWVpbmcgYXMgdGhlcmUgaGFzIHRvIGJlIGF0IGxlYXN0IDggYnl0ZXMgdG8gY29w
eSwgd2UgY2FuCisgKiBjb3B5IG9uZSB3b3JkLCBhbmQgZm9yY2UgYSB1c2VyLW1vZGUgcGFn
ZSBmYXVsdC4uLgorICovCisKKy5jMnVfMGZ1cGk6CXN1YnMJcjIsIHIyLCAjNAorCQlhZGRt
aQlpcCwgcjIsICM0CisJCWJtaQkuYzJ1XzBub3dvcmRzCisJCWxkcglyMywgW3IxXSwgIzQK
K1VTRVIoCQlzdHJ0CXIzLCBbcjBdLCAjNCkJCQlAIE1heSBmYXVsdAorCQltb3YJaXAsIHIw
LCBsc2wgIzMyIC0gUEFHRV9TSElGVAlAIE9uIGVhY2ggcGFnZSwgdXNlIGEgbGQvc3Q/P3Qg
aW5zdHJ1Y3Rpb24KKwkJcnNiCWlwLCBpcCwgIzAKKwkJbW92cwlpcCwgaXAsIGxzciAjMzIg
LSBQQUdFX1NISUZUCisJCWJlcQkuYzJ1XzBmdXBpCisvKgorICogaXAgPSBtYXggbm8uIG9m
IGJ5dGVzIHRvIGNvcHkgYmVmb3JlIG5lZWRpbmcgYW5vdGhlciAic3RydCIgaW5zbgorICov
CisJCWNtcAlyMiwgaXAKKwkJbW92bHQJaXAsIHIyCisJCXN1YglyMiwgcjIsIGlwCisJCXN1
YnMJaXAsIGlwLCAjMzIKKwkJYmx0CS5jMnVfMHJlbThscAorCVBMRCgJcGxkCVtyMSwgIzI4
XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCVBMRCgJc3VicwlpcCwgaXAsICM2NAkJ
CSkKKwlQTEQoCWJsdAkuYzJ1XzBjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzYwXQkJ
KQorCVBMRCgJcGxkCVtyMCwgIzYwXQkJKQorCisuYzJ1XzBjcHk4bHA6CisJUExEKAlwbGQJ
W3IxLCAjOTJdCQkpCisJUExEKAlwbGQJW3IwLCAjOTJdCQkpCisuYzJ1XzBjcHlub3BsZDoJ
bGRtaWEJcjEhLCB7cjMgLSByNn0KKwkJc3RtaWEJcjAhLCB7cjMgLSByNn0JCQlAIFNob3Vs
ZG50IGZhdWx0CisJCWxkbWlhCXIxISwge3IzIC0gcjZ9CisJCXN1YnMJaXAsIGlwLCAjMzIK
KwkJc3RtaWEJcjAhLCB7cjMgLSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJCWJwbAkuYzJ1
XzBjcHk4bHAKKwlQTEQoCWNtbglpcCwgIzY0CQkJKQorCVBMRCgJYmdlCS5jMnVfMGNweW5v
cGxkCQkpCisJUExEKAlhZGQJaXAsIGlwLCAjNjQJCSkKKworLmMydV8wcmVtOGxwOgljbW4J
aXAsICMxNgorCQlsZG1nZWlhCXIxISwge3IzIC0gcjZ9CisJCXN0bWdlaWEJcjAhLCB7cjMg
LSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJCXRzdAlpcCwgIzgKKwkJbGRtbmVpYQlyMSEs
IHtyMyAtIHI0fQorCQlzdG1uZWlhCXIwISwge3IzIC0gcjR9CQkJQCBTaG91bGRudCBmYXVs
dAorCQl0c3QJaXAsICM0CisJCWxkcm5lCXIzLCBbcjFdLCAjNAorCQlzdHJuZXQJcjMsIFty
MF0sICM0CQkJQCBTaG91bGRudCBmYXVsdAorCQlhbmRzCWlwLCBpcCwgIzMKKwkJYmVxCS5j
MnVfMGZ1cGkKKy5jMnVfMG5vd29yZHM6CXRlcQlpcCwgIzAKKwkJYmVxCS5jMnVfZmluaXNo
ZWQKKy5jMnVfbm93b3JkczoJY21wCWlwLCAjMgorCQlsZHJiCXIzLCBbcjFdLCAjMQorVVNF
UigJCXN0cmJ0CXIzLCBbcjBdLCAjMSkJCQlAIE1heSBmYXVsdAorCQlsZHJnZWIJcjMsIFty
MV0sICMxCitVU0VSKAkJc3RyZ2VidAlyMywgW3IwXSwgIzEpCQkJQCBNYXkgZmF1bHQKKwkJ
bGRyZ3RiCXIzLCBbcjFdLCAjMQorVVNFUigJCXN0cmd0YnQJcjMsIFtyMF0sICMxKQkJCUAg
TWF5IGZhdWx0CisJCWIJLmMydV9maW5pc2hlZAorCisuYzJ1X25vdF9lbm91Z2g6CisJCW1v
dnMJaXAsIHIyCisJCWJuZQkuYzJ1X25vd29yZHMKKy5jMnVfZmluaXNoZWQ6CW1vdglyMCwg
IzAKKwkJbGRtZmQJc3AhLHtyMiwgcjQgLSByNywgcGN9CisKKy5jMnVfc3JjX25vdF9hbGln
bmVkOgorCQliaWMJcjEsIHIxLCAjMworCQlsZHIJcjcsIFtyMV0sICM0CisJCWNtcAlpcCwg
IzIKKwkJYmd0CS5jMnVfM2Z1cGkKKwkJYmVxCS5jMnVfMmZ1cGkKKy5jMnVfMWZ1cGk6CXN1
YnMJcjIsIHIyLCAjNAorCQlhZGRtaQlpcCwgcjIsICM0CisJCWJtaQkuYzJ1XzFub3dvcmRz
CisJCW1vdglyMywgcjcsIHB1bGwgIzgKKwkJbGRyCXI3LCBbcjFdLCAjNAorCQlvcnIJcjMs
IHIzLCByNywgcHVzaCAjMjQKK1VTRVIoCQlzdHJ0CXIzLCBbcjBdLCAjNCkJCQlAIE1heSBm
YXVsdAorCQltb3YJaXAsIHIwLCBsc2wgIzMyIC0gUEFHRV9TSElGVAorCQlyc2IJaXAsIGlw
LCAjMAorCQltb3ZzCWlwLCBpcCwgbHNyICMzMiAtIFBBR0VfU0hJRlQKKwkJYmVxCS5jMnVf
MWZ1cGkKKwkJY21wCXIyLCBpcAorCQltb3ZsdAlpcCwgcjIKKwkJc3ViCXIyLCByMiwgaXAK
KwkJc3VicwlpcCwgaXAsICMxNgorCQlibHQJLmMydV8xcmVtOGxwCisJUExEKAlwbGQJW3Ix
LCAjMTJdCQkpCisJUExEKAlwbGQJW3IwLCAjMTJdCQkpCisJUExEKAlzdWJzCWlwLCBpcCwg
IzMyCQkpCisJUExEKAlibHQJLmMydV8xY3B5bm9wbGQJCSkKKwlQTEQoCXBsZAlbcjEsICMy
OF0JCSkKKwlQTEQoCXBsZAlbcjAsICMyOF0JCSkKKworLmMydV8xY3B5OGxwOgorCVBMRCgJ
cGxkCVtyMSwgIzQ0XQkJKQorCVBMRCgJcGxkCVtyMCwgIzQ0XQkJKQorLmMydV8xY3B5bm9w
bGQ6CW1vdglyMywgcjcsIHB1bGwgIzgKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30KKwkJc3Vi
cwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjMjQKKwkJbW92CXI0LCBy
NCwgcHVsbCAjOAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjMjQKKwkJbW92CXI1LCByNSwg
cHVsbCAjOAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjMjQKKwkJbW92CXI2LCByNiwgcHVs
bCAjOAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjMjQKKwkJc3RtaWEJcjAhLCB7cjMgLSBy
Nn0JCQlAIFNob3VsZG50IGZhdWx0CisJCWJwbAkuYzJ1XzFjcHk4bHAKKwlQTEQoCWNtbglp
cCwgIzMyCQkJKQorCVBMRCgJYmdlCS5jMnVfMWNweW5vcGxkCQkpCisJUExEKAlhZGQJaXAs
IGlwLCAjMzIJCSkKKworLmMydV8xcmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIzLCBy
NywgcHVsbCAjOAorCQlsZG1uZWlhCXIxISwge3I0LCByN30KKwkJb3JybmUJcjMsIHIzLCBy
NCwgcHVzaCAjMjQKKwkJbW92bmUJcjQsIHI0LCBwdWxsICM4CisJCW9ycm5lCXI0LCByNCwg
cjcsIHB1c2ggIzI0CisJCXN0bW5laWEJcjAhLCB7cjMgLSByNH0JCQlAIFNob3VsZG50IGZh
dWx0CisJCXRzdAlpcCwgIzQKKwkJbW92bmUJcjMsIHI3LCBwdWxsICM4CisJCWxkcm5lCXI3
LCBbcjFdLCAjNAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICMyNAorCQlzdHJuZXQJcjMs
IFtyMF0sICM0CQkJQCBTaG91bGRudCBmYXVsdAorCQlhbmRzCWlwLCBpcCwgIzMKKwkJYmVx
CS5jMnVfMWZ1cGkKKy5jMnVfMW5vd29yZHM6CW1vdglyMywgcjcsIGdldF9ieXRlXzEKKwkJ
dGVxCWlwLCAjMAorCQliZXEJLmMydV9maW5pc2hlZAorCQljbXAJaXAsICMyCitVU0VSKAkJ
c3RyYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCW1vdmdlCXIzLCByNywgZ2V0
X2J5dGVfMgorVVNFUigJCXN0cmdlYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJ
CW1vdmd0CXIzLCByNywgZ2V0X2J5dGVfMworVVNFUigJCXN0cmd0YnQJcjMsIFtyMF0sICMx
KQkJCUAgTWF5IGZhdWx0CisJCWIJLmMydV9maW5pc2hlZAorCisuYzJ1XzJmdXBpOglzdWJz
CXIyLCByMiwgIzQKKwkJYWRkbWkJaXAsIHIyLCAjNAorCQlibWkJLmMydV8ybm93b3Jkcwor
CQltb3YJcjMsIHI3LCBwdWxsICMxNgorCQlsZHIJcjcsIFtyMV0sICM0CisJCW9ycglyMywg
cjMsIHI3LCBwdXNoICMxNgorVVNFUigJCXN0cnQJcjMsIFtyMF0sICM0KQkJCUAgTWF5IGZh
dWx0CisJCW1vdglpcCwgcjAsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAs
ICMwCisJCW1vdnMJaXAsIGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmMydV8y
ZnVwaQorCQljbXAJcjIsIGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAor
CQlzdWJzCWlwLCBpcCwgIzE2CisJCWJsdAkuYzJ1XzJyZW04bHAKKwlQTEQoCXBsZAlbcjEs
ICMxMl0JCSkKKwlQTEQoCXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAj
MzIJCSkKKwlQTEQoCWJsdAkuYzJ1XzJjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4
XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCisuYzJ1XzJjcHk4bHA6CisJUExEKAlw
bGQJW3IxLCAjNDRdCQkpCisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuYzJ1XzJjcHlub3Bs
ZDoJbW92CXIzLCByNywgcHVsbCAjMTYKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30KKwkJc3Vi
cwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjMTYKKwkJbW92CXI0LCBy
NCwgcHVsbCAjMTYKKwkJb3JyCXI0LCByNCwgcjUsIHB1c2ggIzE2CisJCW1vdglyNSwgcjUs
IHB1bGwgIzE2CisJCW9ycglyNSwgcjUsIHI2LCBwdXNoICMxNgorCQltb3YJcjYsIHI2LCBw
dWxsICMxNgorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjMTYKKwkJc3RtaWEJcjAhLCB7cjMg
LSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJCWJwbAkuYzJ1XzJjcHk4bHAKKwlQTEQoCWNt
bglpcCwgIzMyCQkJKQorCVBMRCgJYmdlCS5jMnVfMmNweW5vcGxkCQkpCisJUExEKAlhZGQJ
aXAsIGlwLCAjMzIJCSkKKworLmMydV8ycmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIz
LCByNywgcHVsbCAjMTYKKwkJbGRtbmVpYQlyMSEsIHtyNCwgcjd9CisJCW9ycm5lCXIzLCBy
MywgcjQsIHB1c2ggIzE2CisJCW1vdm5lCXI0LCByNCwgcHVsbCAjMTYKKwkJb3JybmUJcjQs
IHI0LCByNywgcHVzaCAjMTYKKwkJc3RtbmVpYQlyMCEsIHtyMyAtIHI0fQkJCUAgU2hvdWxk
bnQgZmF1bHQKKwkJdHN0CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzE2CisJCWxk
cm5lCXI3LCBbcjFdLCAjNAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICMxNgorCQlzdHJu
ZXQJcjMsIFtyMF0sICM0CQkJQCBTaG91bGRudCBmYXVsdAorCQlhbmRzCWlwLCBpcCwgIzMK
KwkJYmVxCS5jMnVfMmZ1cGkKKy5jMnVfMm5vd29yZHM6CW1vdglyMywgcjcsIGdldF9ieXRl
XzIKKwkJdGVxCWlwLCAjMAorCQliZXEJLmMydV9maW5pc2hlZAorCQljbXAJaXAsICMyCitV
U0VSKAkJc3RyYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCW1vdmdlCXIzLCBy
NywgZ2V0X2J5dGVfMworVVNFUigJCXN0cmdlYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZh
dWx0CisJCWxkcmd0YglyMywgW3IxXSwgIzAKK1VTRVIoCQlzdHJndGJ0CXIzLCBbcjBdLCAj
MSkJCQlAIE1heSBmYXVsdAorCQliCS5jMnVfZmluaXNoZWQKKworLmMydV8zZnVwaToJc3Vi
cwlyMiwgcjIsICM0CisJCWFkZG1pCWlwLCByMiwgIzQKKwkJYm1pCS5jMnVfM25vd29yZHMK
KwkJbW92CXIzLCByNywgcHVsbCAjMjQKKwkJbGRyCXI3LCBbcjFdLCAjNAorCQlvcnIJcjMs
IHIzLCByNywgcHVzaCAjOAorVVNFUigJCXN0cnQJcjMsIFtyMF0sICM0KQkJCUAgTWF5IGZh
dWx0CisJCW1vdglpcCwgcjAsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAs
ICMwCisJCW1vdnMJaXAsIGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmMydV8z
ZnVwaQorCQljbXAJcjIsIGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAor
CQlzdWJzCWlwLCBpcCwgIzE2CisJCWJsdAkuYzJ1XzNyZW04bHAKKwlQTEQoCXBsZAlbcjEs
ICMxMl0JCSkKKwlQTEQoCXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAj
MzIJCSkKKwlQTEQoCWJsdAkuYzJ1XzNjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4
XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCisuYzJ1XzNjcHk4bHA6CisJUExEKAlw
bGQJW3IxLCAjNDRdCQkpCisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuYzJ1XzNjcHlub3Bs
ZDoJbW92CXIzLCByNywgcHVsbCAjMjQKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30KKwkJc3Vi
cwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjOAorCQltb3YJcjQsIHI0
LCBwdWxsICMyNAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjOAorCQltb3YJcjUsIHI1LCBw
dWxsICMyNAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjOAorCQltb3YJcjYsIHI2LCBwdWxs
ICMyNAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjOAorCQlzdG1pYQlyMCEsIHtyMyAtIHI2
fQkJCUAgU2hvdWxkbnQgZmF1bHQKKwkJYnBsCS5jMnVfM2NweThscAorCVBMRCgJY21uCWlw
LCAjMzIJCQkpCisJUExEKAliZ2UJLmMydV8zY3B5bm9wbGQJCSkKKwlQTEQoCWFkZAlpcCwg
aXAsICMzMgkJKQorCisuYzJ1XzNyZW04bHA6CXRzdAlpcCwgIzgKKwkJbW92bmUJcjMsIHI3
LCBwdWxsICMyNAorCQlsZG1uZWlhCXIxISwge3I0LCByN30KKwkJb3JybmUJcjMsIHIzLCBy
NCwgcHVzaCAjOAorCQltb3ZuZQlyNCwgcjQsIHB1bGwgIzI0CisJCW9ycm5lCXI0LCByNCwg
cjcsIHB1c2ggIzgKKwkJc3RtbmVpYQlyMCEsIHtyMyAtIHI0fQkJCUAgU2hvdWxkbnQgZmF1
bHQKKwkJdHN0CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzI0CisJCWxkcm5lCXI3
LCBbcjFdLCAjNAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICM4CisJCXN0cm5ldAlyMywg
W3IwXSwgIzQJCQlAIFNob3VsZG50IGZhdWx0CisJCWFuZHMJaXAsIGlwLCAjMworCQliZXEJ
LmMydV8zZnVwaQorLmMydV8zbm93b3JkczoJbW92CXIzLCByNywgZ2V0X2J5dGVfMworCQl0
ZXEJaXAsICMwCisJCWJlcQkuYzJ1X2ZpbmlzaGVkCisJCWNtcAlpcCwgIzIKK1VTRVIoCQlz
dHJidAlyMywgW3IwXSwgIzEpCQkJQCBNYXkgZmF1bHQKKwkJbGRyZ2ViCXIzLCBbcjFdLCAj
MQorVVNFUigJCXN0cmdlYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCWxkcmd0
YglyMywgW3IxXSwgIzAKK1VTRVIoCQlzdHJndGJ0CXIzLCBbcjBdLCAjMSkJCQlAIE1heSBm
YXVsdAorCQliCS5jMnVfZmluaXNoZWQKKworCQkuc2VjdGlvbiAuZml4dXAsImF4IgorCQku
YWxpZ24JMAorOTAwMToJCWxkbWZkCXNwISwge3IwLCByNCAtIHI3LCBwY30KKwkJLnByZXZp
b3VzCisKKy8qIFByb3RvdHlwZTogdW5zaWduZWQgbG9uZyBfX2FyY2hfY29weV9mcm9tX3Vz
ZXIodm9pZCAqdG8sY29uc3Qgdm9pZCAqZnJvbSx1bnNpZ25lZCBsb25nIG4pOworICogUHVy
cG9zZSAgOiBjb3B5IGEgYmxvY2sgZnJvbSB1c2VyIG1lbW9yeSB0byBrZXJuZWwgbWVtb3J5
CisgKiBQYXJhbXMgICA6IHRvICAgLSBrZXJuZWwgbWVtb3J5CisgKiAgICAgICAgICA6IGZy
b20gLSB1c2VyIG1lbW9yeQorICogICAgICAgICAgOiBuICAgIC0gbnVtYmVyIG9mIGJ5dGVz
IHRvIGNvcHkKKyAqIFJldHVybnMgIDogTnVtYmVyIG9mIGJ5dGVzIE5PVCBjb3BpZWQuCisg
Ki8KKy5jZnVfZGVzdF9ub3RfYWxpZ25lZDoKKwkJcnNiCWlwLCBpcCwgIzQKKwkJY21wCWlw
LCAjMgorVVNFUigJCWxkcmJ0CXIzLCBbcjFdLCAjMSkJCQlAIE1heSBmYXVsdAorCQlzdHJi
CXIzLCBbcjBdLCAjMQorVVNFUigJCWxkcmdlYnQJcjMsIFtyMV0sICMxKQkJCUAgTWF5IGZh
dWx0CisJCXN0cmdlYglyMywgW3IwXSwgIzEKK1VTRVIoCQlsZHJndGJ0CXIzLCBbcjFdLCAj
MSkJCQlAIE1heSBmYXVsdAorCQlzdHJndGIJcjMsIFtyMF0sICMxCisJCXN1YglyMiwgcjIs
IGlwCisJCWIJLmNmdV9kZXN0X2FsaWduZWQKKworRU5UUlkoX19hcmNoX2NvcHlfZnJvbV91
c2VyKQorCQlzdG1mZAlzcCEsIHtyMCwgcjIsIHI0IC0gcjcsIGxyfQorCQljbXAJcjIsICM0
CisJCWJsdAkuY2Z1X25vdF9lbm91Z2gKKwlQTEQoCXBsZAlbcjEsICMwXQkJKQorCVBMRCgJ
cGxkCVtyMCwgIzBdCQkpCisJCWFuZHMJaXAsIHIwLCAjMworCQlibmUJLmNmdV9kZXN0X25v
dF9hbGlnbmVkCisuY2Z1X2Rlc3RfYWxpZ25lZDoKKwkJYW5kcwlpcCwgcjEsICMzCisJCWJu
ZQkuY2Z1X3NyY19ub3RfYWxpZ25lZAorLyoKKyAqIFNlZWluZyBhcyB0aGVyZSBoYXMgdG8g
YmUgYXQgbGVhc3QgOCBieXRlcyB0byBjb3B5LCB3ZSBjYW4KKyAqIGNvcHkgb25lIHdvcmQs
IGFuZCBmb3JjZSBhIHVzZXItbW9kZSBwYWdlIGZhdWx0Li4uCisgKi8KKworLmNmdV8wZnVw
aToJc3VicwlyMiwgcjIsICM0CisJCWFkZG1pCWlwLCByMiwgIzQKKwkJYm1pCS5jZnVfMG5v
d29yZHMKK1VTRVIoCQlsZHJ0CXIzLCBbcjFdLCAjNCkKKwkJc3RyCXIzLCBbcjBdLCAjNAor
CQltb3YJaXAsIHIxLCBsc2wgIzMyIC0gUEFHRV9TSElGVAlAIE9uIGVhY2ggcGFnZSwgdXNl
IGEgbGQvc3Q/P3QgaW5zdHJ1Y3Rpb24KKwkJcnNiCWlwLCBpcCwgIzAKKwkJbW92cwlpcCwg
aXAsIGxzciAjMzIgLSBQQUdFX1NISUZUCisJCWJlcQkuY2Z1XzBmdXBpCisvKgorICogaXAg
PSBtYXggbm8uIG9mIGJ5dGVzIHRvIGNvcHkgYmVmb3JlIG5lZWRpbmcgYW5vdGhlciAic3Ry
dCIgaW5zbgorICovCisJCWNtcAlyMiwgaXAKKwkJbW92bHQJaXAsIHIyCisJCXN1YglyMiwg
cjIsIGlwCisJCXN1YnMJaXAsIGlwLCAjMzIKKwkJYmx0CS5jZnVfMHJlbThscAorCVBMRCgJ
cGxkCVtyMSwgIzI4XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCVBMRCgJc3Vicwlp
cCwgaXAsICM2NAkJCSkKKwlQTEQoCWJsdAkuY2Z1XzBjcHlub3BsZAkJKQorCVBMRCgJcGxk
CVtyMSwgIzYwXQkJKQorCVBMRCgJcGxkCVtyMCwgIzYwXQkJKQorCisuY2Z1XzBjcHk4bHA6
CisJUExEKAlwbGQJW3IxLCAjOTJdCQkpCisJUExEKAlwbGQJW3IwLCAjOTJdCQkpCisuY2Z1
XzBjcHlub3BsZDoJbGRtaWEJcjEhLCB7cjMgLSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJ
CXN0bWlhCXIwISwge3IzIC0gcjZ9CisJCWxkbWlhCXIxISwge3IzIC0gcjZ9CQkJQCBTaG91
bGRudCBmYXVsdAorCQlzdWJzCWlwLCBpcCwgIzMyCisJCXN0bWlhCXIwISwge3IzIC0gcjZ9
CisJCWJwbAkuY2Z1XzBjcHk4bHAKKwlQTEQoCWNtbglpcCwgIzY0CQkJKQorCVBMRCgJYmdl
CS5jZnVfMGNweW5vcGxkCQkpCisJUExEKAlhZGQJaXAsIGlwLCAjNjQJCSkKKworLmNmdV8w
cmVtOGxwOgljbW4JaXAsICMxNgorCQlsZG1nZWlhCXIxISwge3IzIC0gcjZ9CQkJQCBTaG91
bGRudCBmYXVsdAorCQlzdG1nZWlhCXIwISwge3IzIC0gcjZ9CisJCXRzdAlpcCwgIzgKKwkJ
bGRtbmVpYQlyMSEsIHtyMyAtIHI0fQkJCUAgU2hvdWxkbnQgZmF1bHQKKwkJc3RtbmVpYQly
MCEsIHtyMyAtIHI0fQorCQl0c3QJaXAsICM0CisJCWxkcm5ldAlyMywgW3IxXSwgIzQJCQlA
IFNob3VsZG50IGZhdWx0CisJCXN0cm5lCXIzLCBbcjBdLCAjNAorCQlhbmRzCWlwLCBpcCwg
IzMKKwkJYmVxCS5jZnVfMGZ1cGkKKy5jZnVfMG5vd29yZHM6CXRlcQlpcCwgIzAKKwkJYmVx
CS5jZnVfZmluaXNoZWQKKy5jZnVfbm93b3JkczoJY21wCWlwLCAjMgorVVNFUigJCWxkcmJ0
CXIzLCBbcjFdLCAjMSkJCQlAIE1heSBmYXVsdAorCQlzdHJiCXIzLCBbcjBdLCAjMQorVVNF
UigJCWxkcmdlYnQJcjMsIFtyMV0sICMxKQkJCUAgTWF5IGZhdWx0CisJCXN0cmdlYglyMywg
W3IwXSwgIzEKK1VTRVIoCQlsZHJndGJ0CXIzLCBbcjFdLCAjMSkJCQlAIE1heSBmYXVsdAor
CQlzdHJndGIJcjMsIFtyMF0sICMxCisJCWIJLmNmdV9maW5pc2hlZAorCisuY2Z1X25vdF9l
bm91Z2g6CisJCW1vdnMJaXAsIHIyCisJCWJuZQkuY2Z1X25vd29yZHMKKy5jZnVfZmluaXNo
ZWQ6CW1vdglyMCwgIzAKKwkJYWRkCXNwLCBzcCwgIzgKKwkJbGRtZmQJc3AhLHtyNCAtIHI3
LCBwY30KKworLmNmdV9zcmNfbm90X2FsaWduZWQ6CisJCWJpYwlyMSwgcjEsICMzCitVU0VS
KAkJbGRydAlyNywgW3IxXSwgIzQpCQkJQCBNYXkgZmF1bHQKKwkJY21wCWlwLCAjMgorCQli
Z3QJLmNmdV8zZnVwaQorCQliZXEJLmNmdV8yZnVwaQorLmNmdV8xZnVwaToJc3VicwlyMiwg
cjIsICM0CisJCWFkZG1pCWlwLCByMiwgIzQKKwkJYm1pCS5jZnVfMW5vd29yZHMKKwkJbW92
CXIzLCByNywgcHVsbCAjOAorVVNFUigJCWxkcnQJcjcsIFtyMV0sICM0KQkJCUAgTWF5IGZh
dWx0CisJCW9ycglyMywgcjMsIHI3LCBwdXNoICMyNAorCQlzdHIJcjMsIFtyMF0sICM0CisJ
CW1vdglpcCwgcjEsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAsICMwCisJ
CW1vdnMJaXAsIGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmNmdV8xZnVwaQor
CQljbXAJcjIsIGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAorCQlzdWJz
CWlwLCBpcCwgIzE2CisJCWJsdAkuY2Z1XzFyZW04bHAKKwlQTEQoCXBsZAlbcjEsICMxMl0J
CSkKKwlQTEQoCXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAjMzIJCSkK
KwlQTEQoCWJsdAkuY2Z1XzFjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4XQkJKQor
CVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCisuY2Z1XzFjcHk4bHA6CisJUExEKAlwbGQJW3Ix
LCAjNDRdCQkpCisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuY2Z1XzFjcHlub3BsZDoJbW92
CXIzLCByNywgcHVsbCAjOAorCQlsZG1pYQlyMSEsIHtyNCAtIHI3fQkJCUAgU2hvdWxkbnQg
ZmF1bHQKKwkJc3VicwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjMjQK
KwkJbW92CXI0LCByNCwgcHVsbCAjOAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjMjQKKwkJ
bW92CXI1LCByNSwgcHVsbCAjOAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjMjQKKwkJbW92
CXI2LCByNiwgcHVsbCAjOAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjMjQKKwkJc3RtaWEJ
cjAhLCB7cjMgLSByNn0KKwkJYnBsCS5jZnVfMWNweThscAorCVBMRCgJY21uCWlwLCAjMzIJ
CQkpCisJUExEKAliZ2UJLmNmdV8xY3B5bm9wbGQJCSkKKwlQTEQoCWFkZAlpcCwgaXAsICMz
MgkJKQorCisuY2Z1XzFyZW04bHA6CXRzdAlpcCwgIzgKKwkJbW92bmUJcjMsIHI3LCBwdWxs
ICM4CisJCWxkbW5laWEJcjEhLCB7cjQsIHI3fQkJCUAgU2hvdWxkbnQgZmF1bHQKKwkJb3Jy
bmUJcjMsIHIzLCByNCwgcHVzaCAjMjQKKwkJbW92bmUJcjQsIHI0LCBwdWxsICM4CisJCW9y
cm5lCXI0LCByNCwgcjcsIHB1c2ggIzI0CisJCXN0bW5laWEJcjAhLCB7cjMgLSByNH0KKwkJ
dHN0CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzgKK1VTRVIoCQlsZHJuZXQJcjcs
IFtyMV0sICM0KQkJCUAgTWF5IGZhdWx0CisJCW9ycm5lCXIzLCByMywgcjcsIHB1c2ggIzI0
CisJCXN0cm5lCXIzLCBbcjBdLCAjNAorCQlhbmRzCWlwLCBpcCwgIzMKKwkJYmVxCS5jZnVf
MWZ1cGkKKy5jZnVfMW5vd29yZHM6CW1vdglyMywgcjcsIGdldF9ieXRlXzEKKwkJdGVxCWlw
LCAjMAorCQliZXEJLmNmdV9maW5pc2hlZAorCQljbXAJaXAsICMyCisJCXN0cmIJcjMsIFty
MF0sICMxCisJCW1vdmdlCXIzLCByNywgZ2V0X2J5dGVfMgorCQlzdHJnZWIJcjMsIFtyMF0s
ICMxCisJCW1vdmd0CXIzLCByNywgZ2V0X2J5dGVfMworCQlzdHJndGIJcjMsIFtyMF0sICMx
CisJCWIJLmNmdV9maW5pc2hlZAorCisuY2Z1XzJmdXBpOglzdWJzCXIyLCByMiwgIzQKKwkJ
YWRkbWkJaXAsIHIyLCAjNAorCQlibWkJLmNmdV8ybm93b3JkcworCQltb3YJcjMsIHI3LCBw
dWxsICMxNgorVVNFUigJCWxkcnQJcjcsIFtyMV0sICM0KQkJCUAgTWF5IGZhdWx0CisJCW9y
cglyMywgcjMsIHI3LCBwdXNoICMxNgorCQlzdHIJcjMsIFtyMF0sICM0CisJCW1vdglpcCwg
cjEsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAsICMwCisJCW1vdnMJaXAs
IGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmNmdV8yZnVwaQorCQljbXAJcjIs
IGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAorCQlzdWJzCWlwLCBpcCwg
IzE2CisJCWJsdAkuY2Z1XzJyZW04bHAKKwlQTEQoCXBsZAlbcjEsICMxMl0JCSkKKwlQTEQo
CXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAjMzIJCSkKKwlQTEQoCWJs
dAkuY2Z1XzJjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4XQkJKQorCVBMRCgJcGxk
CVtyMCwgIzI4XQkJKQorCisuY2Z1XzJjcHk4bHA6CisJUExEKAlwbGQJW3IxLCAjNDRdCQkp
CisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuY2Z1XzJjcHlub3BsZDoJbW92CXIzLCByNywg
cHVsbCAjMTYKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30JCQlAIFNob3VsZG50IGZhdWx0CisJ
CXN1YnMJaXAsIGlwLCAjMTYKKwkJb3JyCXIzLCByMywgcjQsIHB1c2ggIzE2CisJCW1vdgly
NCwgcjQsIHB1bGwgIzE2CisJCW9ycglyNCwgcjQsIHI1LCBwdXNoICMxNgorCQltb3YJcjUs
IHI1LCBwdWxsICMxNgorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjMTYKKwkJbW92CXI2LCBy
NiwgcHVsbCAjMTYKKwkJb3JyCXI2LCByNiwgcjcsIHB1c2ggIzE2CisJCXN0bWlhCXIwISwg
e3IzIC0gcjZ9CisJCWJwbAkuY2Z1XzJjcHk4bHAKKwlQTEQoCWNtbglpcCwgIzMyCQkJKQor
CVBMRCgJYmdlCS5jZnVfMmNweW5vcGxkCQkpCisJUExEKAlhZGQJaXAsIGlwLCAjMzIJCSkK
KworLmNmdV8ycmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIzLCByNywgcHVsbCAjMTYK
KwkJbGRtbmVpYQlyMSEsIHtyNCwgcjd9CQkJQCBTaG91bGRudCBmYXVsdAorCQlvcnJuZQly
MywgcjMsIHI0LCBwdXNoICMxNgorCQltb3ZuZQlyNCwgcjQsIHB1bGwgIzE2CisJCW9ycm5l
CXI0LCByNCwgcjcsIHB1c2ggIzE2CisJCXN0bW5laWEJcjAhLCB7cjMgLSByNH0KKwkJdHN0
CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzE2CitVU0VSKAkJbGRybmV0CXI3LCBb
cjFdLCAjNCkJCQlAIE1heSBmYXVsdAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICMxNgor
CQlzdHJuZQlyMywgW3IwXSwgIzQKKwkJYW5kcwlpcCwgaXAsICMzCisJCWJlcQkuY2Z1XzJm
dXBpCisuY2Z1XzJub3dvcmRzOgltb3YJcjMsIHI3LCBnZXRfYnl0ZV8yCisJCXRlcQlpcCwg
IzAKKwkJYmVxCS5jZnVfZmluaXNoZWQKKwkJY21wCWlwLCAjMgorCQlzdHJiCXIzLCBbcjBd
LCAjMQorCQltb3ZnZQlyMywgcjcsIGdldF9ieXRlXzMKKwkJc3RyZ2ViCXIzLCBbcjBdLCAj
MQorVVNFUigJCWxkcmd0YnQJcjMsIFtyMV0sICMwKQkJCUAgTWF5IGZhdWx0CisJCXN0cmd0
YglyMywgW3IwXSwgIzEKKwkJYgkuY2Z1X2ZpbmlzaGVkCisKKy5jZnVfM2Z1cGk6CXN1YnMJ
cjIsIHIyLCAjNAorCQlhZGRtaQlpcCwgcjIsICM0CisJCWJtaQkuY2Z1XzNub3dvcmRzCisJ
CW1vdglyMywgcjcsIHB1bGwgIzI0CitVU0VSKAkJbGRydAlyNywgW3IxXSwgIzQpCQkJQCBN
YXkgZmF1bHQKKwkJb3JyCXIzLCByMywgcjcsIHB1c2ggIzgKKwkJc3RyCXIzLCBbcjBdLCAj
NAorCQltb3YJaXAsIHIxLCBsc2wgIzMyIC0gUEFHRV9TSElGVAorCQlyc2IJaXAsIGlwLCAj
MAorCQltb3ZzCWlwLCBpcCwgbHNyICMzMiAtIFBBR0VfU0hJRlQKKwkJYmVxCS5jZnVfM2Z1
cGkKKwkJY21wCXIyLCBpcAorCQltb3ZsdAlpcCwgcjIKKwkJc3ViCXIyLCByMiwgaXAKKwkJ
c3VicwlpcCwgaXAsICMxNgorCQlibHQJLmNmdV8zcmVtOGxwCisJUExEKAlwbGQJW3IxLCAj
MTJdCQkpCisJUExEKAlwbGQJW3IwLCAjMTJdCQkpCisJUExEKAlzdWJzCWlwLCBpcCwgIzMy
CQkpCisJUExEKAlibHQJLmNmdV8zY3B5bm9wbGQJCSkKKwlQTEQoCXBsZAlbcjEsICMyOF0J
CSkKKwlQTEQoCXBsZAlbcjAsICMyOF0JCSkKKworLmNmdV8zY3B5OGxwOgorCVBMRCgJcGxk
CVtyMSwgIzQ0XQkJKQorCVBMRCgJcGxkCVtyMCwgIzQ0XQkJKQorLmNmdV8zY3B5bm9wbGQ6
CW1vdglyMywgcjcsIHB1bGwgIzI0CisJCWxkbWlhCXIxISwge3I0IC0gcjd9CQkJQCBTaG91
bGRudCBmYXVsdAorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjOAorCQltb3YJcjQsIHI0LCBw
dWxsICMyNAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjOAorCQltb3YJcjUsIHI1LCBwdWxs
ICMyNAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjOAorCQltb3YJcjYsIHI2LCBwdWxsICMy
NAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjOAorCQlzdG1pYQlyMCEsIHtyMyAtIHI2fQor
CQlzdWJzCWlwLCBpcCwgIzE2CisJCWJwbAkuY2Z1XzNjcHk4bHAKKwlQTEQoCWNtbglpcCwg
IzMyCQkJKQorCVBMRCgJYmdlCS5jZnVfM2NweW5vcGxkCQkpCisJUExEKAlhZGQJaXAsIGlw
LCAjMzIJCSkKKworLmNmdV8zcmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIzLCByNywg
cHVsbCAjMjQKKwkJbGRtbmVpYQlyMSEsIHtyNCwgcjd9CQkJQCBTaG91bGRudCBmYXVsdAor
CQlvcnJuZQlyMywgcjMsIHI0LCBwdXNoICM4CisJCW1vdm5lCXI0LCByNCwgcHVsbCAjMjQK
KwkJb3JybmUJcjQsIHI0LCByNywgcHVzaCAjOAorCQlzdG1uZWlhCXIwISwge3IzIC0gcjR9
CisJCXRzdAlpcCwgIzQKKwkJbW92bmUJcjMsIHI3LCBwdWxsICMyNAorVVNFUigJCWxkcm5l
dAlyNywgW3IxXSwgIzQpCQkJQCBNYXkgZmF1bHQKKwkJb3JybmUJcjMsIHIzLCByNywgcHVz
aCAjOAorCQlzdHJuZQlyMywgW3IwXSwgIzQKKwkJYW5kcwlpcCwgaXAsICMzCisJCWJlcQku
Y2Z1XzNmdXBpCisuY2Z1XzNub3dvcmRzOgltb3YJcjMsIHI3LCBnZXRfYnl0ZV8zCisJCXRl
cQlpcCwgIzAKKwkJYmVxCS5jZnVfZmluaXNoZWQKKwkJY21wCWlwLCAjMgorCQlzdHJiCXIz
LCBbcjBdLCAjMQorVVNFUigJCWxkcmdlYnQJcjMsIFtyMV0sICMxKQkJCUAgTWF5IGZhdWx0
CisJCXN0cmdlYglyMywgW3IwXSwgIzEKK1VTRVIoCQlsZHJndGJ0CXIzLCBbcjFdLCAjMSkJ
CQlAIE1heSBmYXVsdAorCQlzdHJndGIJcjMsIFtyMF0sICMxCisJCWIJLmNmdV9maW5pc2hl
ZAorCisJCS5zZWN0aW9uIC5maXh1cCwiYXgiCisJCS5hbGlnbgkwCisJCS8qCisJCSAqIFdl
IHRvb2sgYW4gZXhjZXB0aW9uLiAgcjAgY29udGFpbnMgYSBwb2ludGVyIHRvCisJCSAqIHRo
ZSBieXRlIG5vdCBjb3BpZWQuCisJCSAqLworOTAwMToJCWxkcglyMiwgW3NwXSwgIzQJCQlA
IHZvaWQgKnRvCisJCXN1YglyMiwgcjAsIHIyCQkJQCBieXRlcyBjb3BpZWQKKwkJbGRyCXIx
LCBbc3BdLCAjNAkJCUAgdW5zaWduZWQgbG9uZyBjb3VudAorCQlzdWJzCXI0LCByMSwgcjIJ
CQlAIGJ5dGVzIGxlZnQgdG8gY29weQorCQltb3ZuZQlyMSwgcjQKKwkJYmxuZQlfX21lbXpl
cm8KKwkJbW92CXIwLCByNAorCQlsZG1mZAlzcCEsIHtyNCAtIHI3LCBwY30KKwkJLnByZXZp
b3VzCisKKy8qIFByb3RvdHlwZTogaW50IF9fYXJjaF9jbGVhcl91c2VyKHZvaWQgKmFkZHIs
IHNpemVfdCBzeikKKyAqIFB1cnBvc2UgIDogY2xlYXIgc29tZSB1c2VyIG1lbW9yeQorICog
UGFyYW1zICAgOiBhZGRyIC0gdXNlciBtZW1vcnkgYWRkcmVzcyB0byBjbGVhcgorICogICAg
ICAgICAgOiBzeiAgIC0gbnVtYmVyIG9mIGJ5dGVzIHRvIGNsZWFyCisgKiBSZXR1cm5zICA6
IG51bWJlciBvZiBieXRlcyBOT1QgY2xlYXJlZAorICovCitFTlRSWShfX2FyY2hfY2xlYXJf
dXNlcikKKwkJc3RtZmQJc3AhLCB7cjEsIGxyfQorCQltb3YJcjIsICMwCisJCWNtcAlyMSwg
IzQKKwkJYmx0CTJmCisJCWFuZHMJaXAsIHIwLCAjMworCQliZXEJMWYKKwkJY21wCWlwLCAj
MgorVVNFUigJCXN0cmJ0CXIyLCBbcjBdLCAjMSkKK1VTRVIoCQlzdHJsZWJ0CXIyLCBbcjBd
LCAjMSkKK1VTRVIoCQlzdHJsdGJ0CXIyLCBbcjBdLCAjMSkKKwkJcnNiCWlwLCBpcCwgIzQK
KwkJc3ViCXIxLCByMSwgaXAJCUAgIDcgIDYgIDUgIDQgIDMgIDIgIDEKKzE6CQlzdWJzCXIx
LCByMSwgIzgJCUAgLTEgLTIgLTMgLTQgLTUgLTYgLTcKK1VTRVIoCQlzdHJwbHQJcjIsIFty
MF0sICM0KQorVVNFUigJCXN0cnBsdAlyMiwgW3IwXSwgIzQpCisJCWJwbAkxYgorCQlhZGRz
CXIxLCByMSwgIzQJCUAgIDMgIDIgIDEgIDAgLTEgLTIgLTMKK1VTRVIoCQlzdHJwbHQJcjIs
IFtyMF0sICM0KQorMjoJCXRzdAlyMSwgIzIJCQlAIDF4IDF4IDB4IDB4IDF4IDF4IDB4CitV
U0VSKAkJc3RybmVidAlyMiwgW3IwXSwgIzEpCitVU0VSKAkJc3RybmVidAlyMiwgW3IwXSwg
IzEpCisJCXRzdAlyMSwgIzEJCQlAIHgxIHgwIHgxIHgwIHgxIHgwIHgxCitVU0VSKAkJc3Ry
bmVidAlyMiwgW3IwXSwgIzEpCisJCW1vdglyMCwgIzAKKwkJbGRtZmQJc3AhLCB7cjEsIHBj
fQorCisJCS5zZWN0aW9uIC5maXh1cCwiYXgiCisJCS5hbGlnbgkwCis5MDAxOgkJbGRtZmQJ
c3AhLCB7cjAsIHBjfQorCQkucHJldmlvdXMKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0vbGliL3VkaXZkaTMuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL3VkaXZkaTMuYwlGcmkgRmVi
IDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyNDIgQEAKKy8qIE1vcmUgc3Vi
cm91dGluZXMgbmVlZGVkIGJ5IEdDQyBvdXRwdXQgY29kZSBvbiBzb21lIG1hY2hpbmVzLiAg
Ki8KKy8qIENvbXBpbGUgdGhpcyBvbmUgd2l0aCBnY2MuICAqLworLyogQ29weXJpZ2h0IChD
KSAxOTg5LCA5Mi05OCwgMTk5OSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKwor
VGhpcyBmaWxlIGlzIHBhcnQgb2YgR05VIENDLgorCitHTlUgQ0MgaXMgZnJlZSBzb2Z0d2Fy
ZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQoraXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg
YnkKK3RoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9y
IChhdCB5b3VyIG9wdGlvbikKK2FueSBsYXRlciB2ZXJzaW9uLgorCitHTlUgQ0MgaXMgZGlz
dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKK2J1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9m
CitNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Uu
ICBTZWUgdGhlCitHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxz
LgorCitZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZQorYWxvbmcgd2l0aCBHTlUgQ0M7IHNlZSB0aGUgZmlsZSBDT1BZ
SU5HLiAgSWYgbm90LCB3cml0ZSB0bwordGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwg
NTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLAorQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBV
U0EuICAqLworCisvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCBpZiB5b3UgbGluayB0aGlz
IGxpYnJhcnkgd2l0aCBvdGhlciBmaWxlcywKKyAgIHNvbWUgb2Ygd2hpY2ggYXJlIGNvbXBp
bGVkIHdpdGggR0NDLCB0byBwcm9kdWNlIGFuIGV4ZWN1dGFibGUsCisgICB0aGlzIGxpYnJh
cnkgZG9lcyBub3QgYnkgaXRzZWxmIGNhdXNlIHRoZSByZXN1bHRpbmcgZXhlY3V0YWJsZQor
ICAgdG8gYmUgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UuCisg
ICBUaGlzIGV4Y2VwdGlvbiBkb2VzIG5vdCBob3dldmVyIGludmFsaWRhdGUgYW55IG90aGVy
IHJlYXNvbnMgd2h5CisgICB0aGUgZXhlY3V0YWJsZSBmaWxlIG1pZ2h0IGJlIGNvdmVyZWQg
YnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLgorICovCisvKiBzdXBwb3J0IGZ1
bmN0aW9ucyByZXF1aXJlZCBieSB0aGUga2VybmVsLiBiYXNlZCBvbiBjb2RlIGZyb20gZ2Nj
LTIuOTUuMyAqLworLyogSSBNb2x0b24gICAgIDI5LzA3LzAxICovCisKKyNpbmNsdWRlICJn
Y2NsaWIuaCIKKyNpbmNsdWRlICJsb25nbG9uZy5oIgorCitzdGF0aWMgY29uc3QgVVFJdHlw
ZSBfX2Nsel90YWJbXSA9Cit7CisgIDAsMSwyLDIsMywzLDMsMyw0LDQsNCw0LDQsNCw0LDQs
NSw1LDUsNSw1LDUsNSw1LDUsNSw1LDUsNSw1LDUsNSwKKyAgNiw2LDYsNiw2LDYsNiw2LDYs
Niw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LAorICA3LDcs
Nyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcs
Nyw3LDcsCisgIDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcs
Nyw3LDcsNyw3LDcsNyw3LDcsNywKKyAgOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LAorICA4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsCisgIDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCwKKyAgOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LAorfTsKKworVURJdHlwZQorX191ZGl2bW9kZGk0IChV
REl0eXBlIG4sIFVESXR5cGUgZCwgVURJdHlwZSAqcnApCit7CisgIERJdW5pb24gd3c7Cisg
IERJdW5pb24gbm4sIGRkOworICBESXVuaW9uIHJyOworICBVU0l0eXBlIGQwLCBkMSwgbjAs
IG4xLCBuMjsKKyAgVVNJdHlwZSBxMCwgcTE7CisgIFVTSXR5cGUgYiwgYm07CisKKyAgbm4u
bGwgPSBuOworICBkZC5sbCA9IGQ7CisKKyAgZDAgPSBkZC5zLmxvdzsKKyAgZDEgPSBkZC5z
LmhpZ2g7CisgIG4wID0gbm4ucy5sb3c7CisgIG4xID0gbm4ucy5oaWdoOworCisgIGlmIChk
MSA9PSAwKQorICAgIHsKKyAgICAgIGlmIChkMCA+IG4xKQorICAgICAgICB7CisgICAgICAg
ICAgLyogMHEgPSBubiAvIDBEICovCisKKyAgICAgICAgICBjb3VudF9sZWFkaW5nX3plcm9z
IChibSwgZDApOworCisgICAgICAgICAgaWYgKGJtICE9IDApCisgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgIC8qIE5vcm1hbGl6ZSwgaS5lLiBtYWtlIHRoZSBtb3N0IHNpZ25pZmlj
YW50IGJpdCBvZiB0aGUKKyAgICAgICAgICAgICAgICAgZGVub21pbmF0b3Igc2V0LiAgKi8K
KworICAgICAgICAgICAgICBkMCA9IGQwIDw8IGJtOworICAgICAgICAgICAgICBuMSA9IChu
MSA8PCBibSkgfCAobjAgPj4gKFNJX1RZUEVfU0laRSAtIGJtKSk7CisgICAgICAgICAgICAg
IG4wID0gbjAgPDwgYm07CisgICAgICAgICAgICB9CisKKyAgICAgICAgICB1ZGl2X3Fybm5k
IChxMCwgbjAsIG4xLCBuMCwgZDApOworICAgICAgICAgIHExID0gMDsKKworICAgICAgICAg
IC8qIFJlbWFpbmRlciBpbiBuMCA+PiBibS4gICovCisgICAgICAgIH0KKyAgICAgIGVsc2UK
KyAgICAgICAgeworICAgICAgICAgIC8qIHFxID0gTk4gLyAwZCAqLworCisgICAgICAgICAg
aWYgKGQwID09IDApCisgICAgICAgICAgICBkMCA9IDEgLyBkMDsgICAgICAgIC8qIERpdmlk
ZSBpbnRlbnRpb25hbGx5IGJ5IHplcm8uICAqLworCisgICAgICAgICAgY291bnRfbGVhZGlu
Z196ZXJvcyAoYm0sIGQwKTsKKworICAgICAgICAgIGlmIChibSA9PSAwKQorICAgICAgICAg
ICAgeworICAgICAgICAgICAgICAvKiBGcm9tIChuMSA+PSBkMCkgL1wgKHRoZSBtb3N0IHNp
Z25pZmljYW50IGJpdCBvZiBkMCBpcyBzZXQpLAorICAgICAgICAgICAgICAgICBjb25jbHVk
ZSAodGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0IG9mIG4xIGlzIHNldCkgL1wgKHRoZQorICAg
ICAgICAgICAgICAgICBsZWFkaW5nIHF1b3RpZW50IGRpZ2l0IHExID0gMSkuCisKKyAgICAg
ICAgICAgICAgICAgVGhpcyBzcGVjaWFsIGNhc2UgaXMgbmVjZXNzYXJ5LCBub3QgYW4gb3B0
aW1pemF0aW9uLgorICAgICAgICAgICAgICAgICAoU2hpZnRzIGNvdW50cyBvZiBTSV9UWVBF
X1NJWkUgYXJlIHVuZGVmaW5lZC4pICAqLworCisgICAgICAgICAgICAgIG4xIC09IGQwOwor
ICAgICAgICAgICAgICBxMSA9IDE7CisgICAgICAgICAgICB9CisgICAgICAgICAgZWxzZQor
ICAgICAgICAgICAgeworICAgICAgICAgICAgICAvKiBOb3JtYWxpemUuICAqLworCisgICAg
ICAgICAgICAgIGIgPSBTSV9UWVBFX1NJWkUgLSBibTsKKworICAgICAgICAgICAgICBkMCA9
IGQwIDw8IGJtOworICAgICAgICAgICAgICBuMiA9IG4xID4+IGI7CisgICAgICAgICAgICAg
IG4xID0gKG4xIDw8IGJtKSB8IChuMCA+PiBiKTsKKyAgICAgICAgICAgICAgbjAgPSBuMCA8
PCBibTsKKworICAgICAgICAgICAgICB1ZGl2X3Fybm5kIChxMSwgbjEsIG4yLCBuMSwgZDAp
OworICAgICAgICAgICAgfQorCisgICAgICAgICAgLyogbjEgIT0gZDAuLi4gICovCisKKyAg
ICAgICAgICB1ZGl2X3Fybm5kIChxMCwgbjAsIG4xLCBuMCwgZDApOworCisgICAgICAgICAg
LyogUmVtYWluZGVyIGluIG4wID4+IGJtLiAgKi8KKyAgICAgICAgfQorCisgICAgICBpZiAo
cnAgIT0gMCkKKyAgICAgICAgeworICAgICAgICAgIHJyLnMubG93ID0gbjAgPj4gYm07Cisg
ICAgICAgICAgcnIucy5oaWdoID0gMDsKKyAgICAgICAgICAqcnAgPSByci5sbDsKKyAgICAg
ICAgfQorICAgIH0KKyAgZWxzZQorICAgIHsKKyAgICAgIGlmIChkMSA+IG4xKQorICAgICAg
ICB7CisgICAgICAgICAgLyogMDAgPSBubiAvIEREICovCisKKyAgICAgICAgICBxMCA9IDA7
CisgICAgICAgICAgcTEgPSAwOworCisgICAgICAgICAgLyogUmVtYWluZGVyIGluIG4xbjAu
ICAqLworICAgICAgICAgIGlmIChycCAhPSAwKQorICAgICAgICAgICAgeworICAgICAgICAg
ICAgICByci5zLmxvdyA9IG4wOworICAgICAgICAgICAgICByci5zLmhpZ2ggPSBuMTsKKyAg
ICAgICAgICAgICAgKnJwID0gcnIubGw7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAg
ICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAgIC8qIDBxID0gTk4gLyBkZCAqLworCisg
ICAgICAgICAgY291bnRfbGVhZGluZ196ZXJvcyAoYm0sIGQxKTsKKyAgICAgICAgICBpZiAo
Ym0gPT0gMCkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgLyogRnJvbSAobjEgPj0g
ZDEpIC9cICh0aGUgbW9zdCBzaWduaWZpY2FudCBiaXQgb2YgZDEgaXMgc2V0KSwKKyAgICAg
ICAgICAgICAgICAgY29uY2x1ZGUgKHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCBvZiBuMSBp
cyBzZXQpIC9cICh0aGUKKyAgICAgICAgICAgICAgICAgcXVvdGllbnQgZGlnaXQgcTAgPSAw
IG9yIDEpLgorCisgICAgICAgICAgICAgICAgIFRoaXMgc3BlY2lhbCBjYXNlIGlzIG5lY2Vz
c2FyeSwgbm90IGFuIG9wdGltaXphdGlvbi4gICovCisKKyAgICAgICAgICAgICAgLyogVGhl
IGNvbmRpdGlvbiBvbiB0aGUgbmV4dCBsaW5lIHRha2VzIGFkdmFudGFnZSBvZiB0aGF0Cisg
ICAgICAgICAgICAgICAgIG4xID49IGQxICh0cnVlIGR1ZSB0byBwcm9ncmFtIGZsb3cpLiAg
Ki8KKyAgICAgICAgICAgICAgaWYgKG4xID4gZDEgfHwgbjAgPj0gZDApCisgICAgICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgICAgcTAgPSAxOworICAgICAgICAgICAgICAgICAg
c3ViX2RkbW1zcyAobjEsIG4wLCBuMSwgbjAsIGQxLCBkMCk7CisgICAgICAgICAgICAgICAg
fQorICAgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgcTAgPSAwOworCisgICAg
ICAgICAgICAgIHExID0gMDsKKworICAgICAgICAgICAgICBpZiAocnAgIT0gMCkKKyAgICAg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICByci5zLmxvdyA9IG4wOworICAgICAg
ICAgICAgICAgICAgcnIucy5oaWdoID0gbjE7CisgICAgICAgICAgICAgICAgICAqcnAgPSBy
ci5sbDsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgZWxz
ZQorICAgICAgICAgICAgeworICAgICAgICAgICAgICBVU0l0eXBlIG0xLCBtMDsKKyAgICAg
ICAgICAgICAgLyogTm9ybWFsaXplLiAgKi8KKworICAgICAgICAgICAgICBiID0gU0lfVFlQ
RV9TSVpFIC0gYm07CisKKyAgICAgICAgICAgICAgZDEgPSAoZDEgPDwgYm0pIHwgKGQwID4+
IGIpOworICAgICAgICAgICAgICBkMCA9IGQwIDw8IGJtOworICAgICAgICAgICAgICBuMiA9
IG4xID4+IGI7CisgICAgICAgICAgICAgIG4xID0gKG4xIDw8IGJtKSB8IChuMCA+PiBiKTsK
KyAgICAgICAgICAgICAgbjAgPSBuMCA8PCBibTsKKworICAgICAgICAgICAgICB1ZGl2X3Fy
bm5kIChxMCwgbjEsIG4yLCBuMSwgZDEpOworICAgICAgICAgICAgICB1bXVsX3BwbW0gKG0x
LCBtMCwgcTAsIGQwKTsKKworICAgICAgICAgICAgICBpZiAobTEgPiBuMSB8fCAobTEgPT0g
bjEgJiYgbTAgPiBuMCkpCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
cTAtLTsKKyAgICAgICAgICAgICAgICAgIHN1Yl9kZG1tc3MgKG0xLCBtMCwgbTEsIG0wLCBk
MSwgZDApOworICAgICAgICAgICAgICAgIH0KKworICAgICAgICAgICAgICBxMSA9IDA7CisK
KyAgICAgICAgICAgICAgLyogUmVtYWluZGVyIGluIChuMW4wIC0gbTFtMCkgPj4gYm0uICAq
LworICAgICAgICAgICAgICBpZiAocnAgIT0gMCkKKyAgICAgICAgICAgICAgICB7CisgICAg
ICAgICAgICAgICAgICBzdWJfZGRtbXNzIChuMSwgbjAsIG4xLCBuMCwgbTEsIG0wKTsKKyAg
ICAgICAgICAgICAgICAgIHJyLnMubG93ID0gKG4xIDw8IGIpIHwgKG4wID4+IGJtKTsKKyAg
ICAgICAgICAgICAgICAgIHJyLnMuaGlnaCA9IG4xID4+IGJtOworICAgICAgICAgICAgICAg
ICAgKnJwID0gcnIubGw7CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgfQorICAg
ICAgICB9CisgICAgfQorCisgIHd3LnMubG93ID0gcTA7CisgIHd3LnMuaGlnaCA9IHExOwor
ICByZXR1cm4gd3cubGw7Cit9CisKK1VESXR5cGUKK19fdWRpdmRpMyAoVURJdHlwZSBuLCBV
REl0eXBlIGQpCit7CisgIHJldHVybiBfX3VkaXZtb2RkaTQgKG4sIGQsIChVREl0eXBlICop
IDApOworfQorCitVREl0eXBlCitfX3Vtb2RkaTMgKFVESXR5cGUgdSwgVURJdHlwZSB2KQor
eworICBVREl0eXBlIHc7CisKKyAgKHZvaWQpIF9fdWRpdm1vZGRpNCAodSAsdiwgJncpOwor
CisgIHJldHVybiB3OworfQorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9s
aWIvdWxkaXZtb2QuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL3VsZGl2bW9kLlMJRnJpIEZlYiAwMyAxNjow
NzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTQ4IEBACisvKgorKiBBLCBRID0gcjAgKyAo
cjEgPDwgMzIpCisqIEIsIFIgPSByMiArIChyMyA8PCAzMikKKyogQSAvIEIgPSBRIC4uLiBS
CisqLworIAorLnRleHQKKy5nbG9iYWwJX19hZWFiaV91bGRpdm1vZAorLnR5cGUJX19hZWFi
aV91bGRpdm1vZCwgZnVuY3Rpb24KKy5hbGlnbgkwCitBXzAJLnJlcQlyMAorQV8xCS5yZXEJ
cjEKK0JfMAkucmVxCXIyCitCXzEJLnJlcQlyMworQ18wCS5yZXEJcjQKK0NfMQkucmVxCXI1
CitEXzAJLnJlcQlyNgorRF8xCS5yZXEJcjcKK1FfMAkucmVxCXIwCitRXzEJLnJlcQlyMQor
Ul8wCS5yZXEJcjIKK1JfMQkucmVxCXIzCisgCitfX2FlYWJpX3VsZGl2bW9kOgorCXN0bWZk
CXNwISwge3I0LCByNSwgcjYsIHI3LCBscn0KKyAKKwlAIFRlc3QgaWYgQiA9PSAwCisJb3Jy
cwlpcCwgQl8wLCBCXzEJCUAgWiBzZXQgLT4gQiA9PSAwCisJYmVxCUxfZGl2X2J5XzAKKwlA
IFRlc3QgaWYgQiBpcyBwb3dlciBvZiAyOiAoQiAmIChCIC0gMSkpID09IDAKKwlzdWJzCUNf
MCwgQl8wLCAjMQorCXNiYwlDXzEsIEJfMSwgIzAKKwl0c3QJQ18wLCBCXzAKKwl0c3RlcQlC
XzEsIENfMQorCWJlcQlMX3BvdzIKKwlAIFRlc3QgaWYgQV8xID09IEJfMSA9PSAwCisJb3Jy
cwlpcCwgQV8xLCBCXzEKKwliZXEJTF9kaXZfMzJfMzIKKworTF9kaXZfNjRfNjQ6CisJbW92
CUNfMCwgIzEKKwltb3YJQ18xLCAjMAorCUAgRF8wID0gY2x6IEEKKwl0ZXEJQV8xLCAjMAor
CWNseglEXzAsIEFfMQorCWNsemVxCWlwLCBBXzAKKwlhZGRlcQlEXzAsIERfMCwgaXAKKwlA
IERfMSA9IGNseiBCCisJdGVxCUJfMSwgIzAKKwljbHoJRF8xLCBCXzEKKwljbHplcQlpcCwg
Ql8wCisJYWRkZXEJRF8xLCBEXzEsIGlwCisJQCBpZiBjbHogQiAtIGNseiBBID4gMAorCXN1
YnMJRF8wLCBEXzEsIERfMAorCWJscwlMX2RvbmVfc2hpZnQKKwlAIEIgPDw9IChjbHogQiAt
IGNseiBBKQorCXN1YnMJRF8xLCBEXzAsICMzMgorCXJzYglpcCwgRF8wLCAjMzIKKwltb3Zt
aQlCXzEsIEJfMSwgbHNsIERfMAorCW9ycm1pCUJfMSwgQl8xLCBCXzAsIGxzciBpcAorCW1v
dnBsCUJfMSwgQl8wLCBsc2wgRF8xCisJbW92CUJfMCwgQl8wLCBsc2wgRF8wCisJQCBDID0g
MSA8PCAoY2x6IEIgLSBjbHogQSkKKwltb3ZtaQlDXzEsIENfMSwgbHNsIERfMAorCW9ycm1p
CUNfMSwgQ18xLCBDXzAsIGxzciBpcAorCW1vdnBsCUNfMSwgQ18wLCBsc2wgRF8xCisJbW92
CUNfMCwgQ18wLCBsc2wgRF8wCitMX2RvbmVfc2hpZnQ6CisJbW92CURfMCwgIzAKKwltb3YJ
RF8xLCAjMAorCUAgQzogY3VycmVudCBiaXQ7IEQ6IHJlc3VsdAorTF9zdWJ0cmFjdDoKKwlA
IGlmIEEgPj0gQgorCWNtcAlBXzEsIEJfMQorCWNtcGVxCUFfMCwgQl8wCisJYmNjCUxfdXBk
YXRlCisJQCBBIC09IEIKKwlzdWJzCUFfMCwgQV8wLCBCXzAKKwlzYmMJQV8xLCBBXzEsIEJf
MQorCUAgRCB8PSBDCisJb3JyCURfMCwgRF8wLCBDXzAKKwlvcnIJRF8xLCBEXzEsIENfMQor
TF91cGRhdGU6CisJQCBpZiBBID09IDA6IGJyZWFrCisJb3JycwlpcCwgQV8xLCBBXzAKKwli
ZXEJTF9leGl0CisJQCBDID4+PSAxCisJbW92cwlDXzEsIENfMSwgbHNyICMxCisJbW92cwlD
XzAsIENfMCwgcnJ4CisJQCBpZiBDID09IDA6IGJyZWFrCisJb3JycwlpcCwgQ18xLCBDXzAK
KwliZXEJTF9leGl0CisJQCBCID4+PSAxCisJbW92cwlCXzEsIEJfMSwgbHNyICMxCisJbW92
CUJfMCwgQl8wLCBycngKKwliCUxfc3VidHJhY3QKK0xfZXhpdDoKKwlAIE5vdGU6IEEsIEIg
JiBRLCBSIGFyZSBhbGlhc2VzCisJbW92CVJfMCwgQV8wCisJbW92CVJfMSwgQV8xCisJbW92
CVFfMCwgRF8wCisJbW92CVFfMSwgRF8xCisJbGRtZmQJc3AhLCB7cjQsIHI1LCByNiwgcjcs
IHBjfQorCitMX2Rpdl8zMl8zMjoKKwlAIE5vdGU6CUFfMCAmCXIwIGFyZSBhbGlhc2VzCisJ
QAlRXzEJcjEKKwltb3YJcjEsIEJfMAorCWJsCV9fYWVhYmlfdWlkaXZtb2QKKwltb3YJUl8w
LCByMQorCW1vdglSXzEsICMwCisJbW92CVFfMSwgIzAKKwlsZG1mZAlzcCEsIHtyNCwgcjUs
IHI2LCByNywgcGN9CisgCitMX3BvdzI6CisJQCBOb3RlOiBBLCBCIGFuZCBRLCBSIGFyZSBh
bGlhc2VzCisJQCBSID0gQSAmIChCIC0gMSkKKwlhbmQJQ18wLCBBXzAsIENfMAorCWFuZAlD
XzEsIEFfMSwgQ18xCisJQCBRID0gQSA+PiBsb2cyKEIpCisJQCBOb3RlOiBCIG11c3Qgbm90
IGJlIDAgaGVyZSEKKwljbHoJRF8wLCBCXzAKKwlhZGQJRF8xLCBEXzAsICMxCisJcnNicwlE
XzAsIERfMCwgIzMxCisJYnBsCUxfMQorCWNseglEXzAsIEJfMQorCXJzYglEXzAsIERfMCwg
IzMxCisJbW92CUFfMCwgQV8xLCBsc3IgRF8wCisJYWRkCURfMCwgRF8wLCAjMzIKK0xfMToK
Kwltb3ZwbAlBXzAsIEFfMCwgbHNyIERfMAorCW9ycnBsCUFfMCwgQV8wLCBBXzEsIGxzbCBE
XzEKKwltb3YJQV8xLCBBXzEsIGxzciBEXzAKKwlAIE1vdiBiYWNrIEMgdG8gUgorCW1vdglS
XzAsIENfMAorCW1vdglSXzEsIENfMQorCWxkbWZkCXNwISwge3I0LCByNSwgcjYsIHI3LCBw
Y30KKworTF9kaXZfYnlfMDoKKwlibAlfX2RpdjAKKwlAIEFzIHdyb25nIGFzIGl0IGNvdWxk
IGJlCisJbW92CVFfMCwgIzAKKwltb3YJUV8xLCAjMAorCW1vdglSXzAsICMwCisJbW92CVJf
MSwgIzAKKwlsZG1mZAlzcCEsIHtyNCwgcjUsIHI2LCByNywgcGN9CisgCisKZGlmZiAtciBl
NzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3RlZ3JhL01ha2VmaWxlCi0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS90ZWdy
YS9NYWtlZmlsZQlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwx
IEBACitvYmoteSArPSBkdW1teS5vCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2Fy
bS90ZWdyYS9SdWxlcy5tawotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvUnVsZXMubWsJRnJpIEZlYiAwMyAx
NjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMSBAQAorQ0ZMQUdTLXkgKz0gLW1hcmNo
PWFybXY3LWEKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3RlZ3JhL2R1bW15
LmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
eGVuL2FyY2gvYXJtL3RlZ3JhL2R1bW15LmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsMyBAQAordm9pZCBkdW1teSh2b2lkKQoreworfQpkaWZmIC1yIGU3
MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCi0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vTWFr
ZWZpbGUJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTkgQEAK
K29iai15ICs9IHNldHVwLm8KK29iai15ICs9IG1tLm8KK29iai15ICs9IGlycS5vCitvYmot
eSArPSBhcmNoX2RvbWFpbi5vCitvYmoteSArPSB0aW1lLm8KK29iai15ICs9IGRvbWFpbl9i
dWlsZC5vCitvYmoteSArPSBmYXVsdC5vCitvYmoteSArPSB0bGIubworb2JqLXkgKz0gc2h1
dGRvd24ubworb2JqLXkgKz0gYXJjaF9kb21jdGwubworb2JqLXkgKz0gY3B1Lm8KK29iai15
ICs9IGlvbW11Lm8KK29iai15ICs9IGdyYW50X3RhYmxlLm8KK29iai15ICs9IGFyY2hfc3lz
Y3RsLm8KK29iai15ICs9IG1hY2hpbmVfa2V4ZWMubworb2JqLXkgKz0gY3Jhc2gubworb2Jq
LXkgKz0gcDJtLm8KK29iai15ICs9IHBlcmZtb24ubworb2JqLXkgKz0gcGNpLm8KZGlmZiAt
ciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jCi0tLSAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2Fy
bS94ZW4vYXJjaF9kb21haW4uYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAg
LTAsMCArMSwyMTIgQEAKKy8qCisgKiBhcmNoX2RvbWFpbi5jCisgKgorICogQ29weXJpZ2h0
IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgU2FuZy1i
dW0gU3VoICAgIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEphZW1pbiBS
eXUgICAgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBKb29Zb3VuZyBI
d2FuZyAgPGpvb3lvdW5nLmh3YW5nQHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2
ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkg
V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl
IHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4K
KyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5v
dCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5
IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EK
KyAqLworCisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgor
I2luY2x1ZGUgPHhlbi9saWIuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNsdWRl
IDx4ZW4vbW0uaD4KKyNpbmNsdWRlIDx4ZW4vZG9tYWluLmg+CisjaW5jbHVkZSA8eGVuL2Vy
cm5vLmg+CisjaW5jbHVkZSA8eGVuL3NtcC5oPgorI2luY2x1ZGUgPHhlbi9pcnEuaD4KKyNp
bmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4KKyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgor
Cit2b2lkIGFyY2hfZHVtcF9kb21haW5faW5mbyhzdHJ1Y3QgZG9tYWluICpkKQoreworCU5P
VF9ZRVQoKTsKK30KKwordm9pZCBhcmNoX2R1bXBfdmNwdV9pbmZvKHN0cnVjdCB2Y3B1ICp2
KQoreworCU5PVF9ZRVQoKTsKK30KKwordW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRl
X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgb3AsCisgICAgICAgIGNvbnN0IGNoYXIgKmZv
cm1hdCwgLi4uKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAwOworfQorCitpbnQgYXJj
aF9kb21haW5fY3JlYXRlKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBkb21jcl9m
bGFncykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKwordm9pZCBh
cmNoX2RvbWFpbl9kZXN0cm95KHN0cnVjdCBkb21haW4gKmQpCit7CisJTk9UX1lFVCgpOwor
fQorCitzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICphbGxvY192Y3B1X2d1ZXN0X2NvbnRl
eHQodm9pZCkKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gTlVMTDsKK30KKwordm9pZCBm
cmVlX3ZjcHVfZ3Vlc3RfY29udGV4dChzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICpjb250
ZXh0KQoreworCU5PVF9ZRVQoKTsKK30KKworCitzdHJ1Y3QgdmNwdSAqYWxsb2NfdmNwdV9z
dHJ1Y3Qodm9pZCkKK3sKKwlOT1RfWUVUKCk7CisJcmV0dXJuIE5VTEw7Cit9CisKK3ZvaWQg
YXJjaF92Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKwor
aW50IHZjcHVfaW5pdGlhbGlzZShzdHJ1Y3QgdmNwdSAqdikKK3sKKwlOT1RfWUVUKCk7CisJ
cmV0dXJuIDA7Cit9CisKK3ZvaWQgdmNwdV9kZXN0cm95KHN0cnVjdCB2Y3B1ICp2KQorewor
CU5PVF9ZRVQoKTsKK30KKwordm9pZCBmcmVlX3ZjcHVfc3RydWN0KHN0cnVjdCB2Y3B1ICp2
KQoreworCU5PVF9ZRVQoKTsKK30KKworc3RydWN0IGRvbWFpbiAqYWxsb2NfZG9tYWluX3N0
cnVjdCh2b2lkKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiBOVUxMOworfQorCisKK3Zv
aWQgZnJlZV9kb21haW5fc3RydWN0KHN0cnVjdCBkb21haW4gKmQpCit7CisJTk9UX1lFVCgp
OworfQorCitpbnQgYXJjaF9zZXRfaW5mb19ndWVzdChzdHJ1Y3QgdmNwdSAqdiwgdmNwdV9n
dWVzdF9jb250ZXh0X3QgKmN0eCkKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKKwor
fQorCit2b2lkIGRvbWFpbl9yZWxpbnF1aXNoX21lbW9yeShzdHJ1Y3QgZG9tYWluICpkKQor
eworCU5PVF9ZRVQoKTsKK30KKwordm9pZCBkdW1wX3BhZ2VmcmFtZV9pbmZvKHN0cnVjdCBk
b21haW4gKmQpCit7CisJTk9UX1lFVCgpOworfQorCit2b2lkIGNvbnRleHRfc3dpdGNoKHN0
cnVjdCB2Y3B1ICpwcmV2LCBzdHJ1Y3QgdmNwdSAqbmV4dCkKK3sKKwlOT1RfWUVUKCk7Cit9
CisKK3ZvaWQgY29udGludWVfcnVubmluZyhzdHJ1Y3QgdmNwdSAqc2FtZSkKK3sKKwlOT1Rf
WUVUKCk7Cit9CisKK3ZvaWQgc3luY19sYXp5X2V4ZWNzdGF0ZV9jcHUodW5zaWduZWQgaW50
IGNwdSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgc3luY19sYXp5X2V4ZWNzdGF0ZV9t
YXNrKGNwdW1hc2tfdCBtYXNrKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9pZCBzeW5jX3Zj
cHVfZXhlY3N0YXRlKHN0cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKwordm9p
ZCBzeW5jX2xvY2FsX2V4ZWNzdGF0ZSh2b2lkKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9p
ZCByZWxpbnF1aXNoX21lbW9yeShzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgbGlzdF9oZWFk
ICpsaXN0KQoreworCU5PVF9ZRVQoKTsKK30KKworaW50IGRvbWFpbl9yZWxpbnF1aXNoX3Jl
c291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAt
RUlOVkFMOworfQorCit2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKQoreworCU5P
VF9ZRVQoKTsKK30KKworbG9uZyBhcmNoX2RvX3ZjcHVfb3AoaW50IGNtZCwgc3RydWN0IHZj
cHUgKnYsIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKQoreworCU5PVF9ZRVQoKTsKKwor
CXJldHVybiAtRU5PU1lTOworfQorCit2b2lkIHZjcHVfa2ljayhzdHJ1Y3QgdmNwdSAqdikK
K3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgdmNwdV9tYXJrX2V2ZW50c19wZW5kaW5nKHN0
cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKworc3RhdGljIHZvaWQgdmNwdV9r
aWNrX3NvZnRpcnEodm9pZCkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3N0YXRpYyBpbnQgX19p
bml0IHZjcHVfa2lja19zb2Z0aXJxX2luaXQodm9pZCkKK3sKKwlOT1RfWUVUKCk7CisKKwly
ZXR1cm4gMDsKK30KKworX19pbml0Y2FsbCh2Y3B1X2tpY2tfc29mdGlycV9pbml0KTsKZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWN0bC5jCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNo
L2FybS94ZW4vYXJjaF9kb21jdGwuYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAK
QEAgLTAsMCArMSw0MyBAQAorLyoKKyAqIGFyY2hfZG9tY3RsLmMKKyAqCisgKiBDb3B5cmln
aHQgKEMpIDIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgSmFlbWluIFJ5
dSAgICAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQor
ICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lv
biAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUg
aG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJB
TlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5U
QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUK
KyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgor
ICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwg
UHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy
aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1w
bGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8K
KworI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNs
dWRlIDx4ZW4vbGliLmg+CisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVu
L21tLmg+CisjaW5jbHVkZSA8eGVuL2RvbWFpbi5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5o
PgorI2luY2x1ZGUgPHhlbi9zbXAuaD4KKyNpbmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4K
KyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgorCisKK3ZvaWQgYXJjaF9nZXRfaW5mb19ndWVz
dChzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCAqY3R4KQorewor
CU5PVF9ZRVQoKTsKK30KKworbG9uZyBhcmNoX2RvX2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0
bCAqZG9tY3RsLCBYRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdClyX2RvbWN0bCkKK3sK
KwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KZGlmZiAtciBlNzAxNDYxYjEy
NTEgeGVuL2FyY2gvYXJtL3hlbi9hcmNoX3N5c2N0bC5jCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9z
eXNjdGwuYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwzOCBA
QAorLyoKKyAqIGFyY2hfc3lzY3RsLmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAx
MSBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsu
c3VoQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlbWluIFJ5dSAgIDxqbTc3LnJ5dUBz
YW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91
IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g
dGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAq
IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNv
ZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMz
MCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHN0ZGFy
Zy5oPgorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+Cisj
aW5jbHVkZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8
eGVuL2RvbWFpbi5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPHhlbi9z
bXAuaD4KKyNpbmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4KKyNpbmNsdWRlIDx4ZW4vc29m
dGlycS5oPgorCitsb25nIGFyY2hfZG9fc3lzY3RsKHN0cnVjdCB4ZW5fc3lzY3RsICpzeXNj
dGwsIFhFTl9HVUVTVF9IQU5ETEUoeGVuX3N5c2N0bF90KXVfc3lzY3RsKQoreworCU5PVF9Z
RVQoKTsKKworCXJldHVybiAtRUlOVkFMOworfQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0veGVuL2FzbS1vZmZzZXRzLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9hc20tb2Zmc2V0cy5j
CUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQwIEBACisjaW5j
bHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2luY2x1ZGUgPHhl
bi9wZXJmYy5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPGFzbS9oYXJk
aXJxLmg+CisjaW5jbHVkZSA8YXNtL2N1cnJlbnQuaD4KKworI2lmIGRlZmluZWQoX19BUENT
XzI2X18pCisjZXJyb3IgU29ycnksIHlvdXIgY29tcGlsZXIgdGFyZ2V0cyBBUENTLTI2IGJ1
dCB0aGlzIGtlcm5lbCByZXF1aXJlcyBBUENTLTMyCisjZW5kaWYKKy8qCisgKiBHQ0MgMi45
NS4xLCAyLjk1LjI6IGlnbm9yZXMgcmVnaXN0ZXIgY2xvYmJlciBsaXN0IGluIGFzbSgpLgor
ICogR0NDIDMuMCwgMy4xOiBnZW5lcmFsIGJhZCBjb2RlIGdlbmVyYXRpb24uCisgKiBHQ0Mg
My4yLjA6IGluY29ycmVjdCBmdW5jdGlvbiBhcmd1bWVudCBvZmZzZXQgY2FsY3VsYXRpb24u
CisgKiBHQ0MgMy4yLng6IG1pc2NvbXBpbGVzIE5FV19BVVhfRU5UIGluIGZzL2JpbmZtdF9l
bGYuYworICogICAgICAgICAgICAoaHR0cDovL2djYy5nbnUub3JnL1BSODg5NikgYW5kIGlu
Y29ycmVjdCBzdHJ1Y3R1cmUKKyAqCSAgICAgIGluaXRpYWxpc2F0aW9uIGluIGZzL2pmZnMy
L2VyYXNlLmMKKyAqLworI2lmIF9fR05VQ19fIDwgMiB8fCBcCisgICAoX19HTlVDX18gPT0g
MiAmJiBfX0dOVUNfTUlOT1JfXyA8IDk1KSB8fCBcCisgICAoX19HTlVDX18gPT0gMiAmJiBf
X0dOVUNfTUlOT1JfXyA9PSA5NSAmJiBfX0dOVUNfUEFUQ0hMRVZFTF9fICE9IDAgJiYgXAor
CQkJCQkgICAgIF9fR05VQ19QQVRDSExFVkVMX18gPCAzKSB8fCBcCisgICAoX19HTlVDX18g
PT0gMyAmJiBfX0dOVUNfTUlOT1JfXyA8IDMpCisjZXJyb3IgWW91ciBjb21waWxlciBpcyB0
b28gYnVnZ3k7IGl0IGlzIGtub3duIHRvIG1pc2NvbXBpbGUga2VybmVscy4KKyNlcnJvciAg
ICBLbm93biBnb29kIGNvbXBpbGVyczogMi45NS4zLCAyLjk1LjQsIDIuOTYsIDMuMworI2Vu
ZGlmCisKKy8qIFVzZSBtYXJrZXIgaWYgeW91IG5lZWQgdG8gc2VwYXJhdGUgdGhlIHZhbHVl
cyBsYXRlciAqLworCisjZGVmaW5lIERFRklORShzeW0sIHZhbCkgXAorICAgICAgICBhc20g
dm9sYXRpbGUoIlxuLT4iICNzeW0gIiAlMCAiICN2YWwgOiA6ICJpIiAodmFsKSkKKworI2Rl
ZmluZSBCTEFOSygpIGFzbSB2b2xhdGlsZSgiXG4tPiIgOiA6ICkKKworaW50IG1haW4odm9p
ZCkKK3sKKwlCTEFOSygpOworCisJcmV0dXJuIDA7IAorfQpkaWZmIC1yIGU3MDE0NjFiMTI1
MSB4ZW4vYXJjaC9hcm0veGVuL2J1Zy5jCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vYnVnLmMJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzIgQEAKKyNpbmNsdWRlIDx4ZW4v
c3RkYXJnLmg+CisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi92ZXJz
aW9uLmg+CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+Cisj
aW5jbHVkZSA8eGVuL2Vycm5vLmg+CisjaW5jbHVkZSA8eGVuL2V2ZW50Lmg+CisjaW5jbHVk
ZSA8eGVuL3NwaW5sb2NrLmg+CisjaW5jbHVkZSA8eGVuL2NvbnNvbGUuaD4KKyNpbmNsdWRl
IDx4ZW4vc2VyaWFsLmg+CisjaW5jbHVkZSA8eGVuL3NvZnRpcnEuaD4KKyNpbmNsdWRlIDx4
ZW4va2V5aGFuZGxlci5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2luY2x1ZGUgPHhlbi9k
ZWxheS5oPgorI2luY2x1ZGUgPHhlbi9ndWVzdF9hY2Nlc3MuaD4KKyNpbmNsdWRlIDx4ZW4v
c2h1dGRvd24uaD4KKyNpbmNsdWRlIDxhc20vY3VycmVudC5oPgorI2luY2x1ZGUgPGFzbS9k
ZWJ1Z2dlci5oPgorCit2b2lkIGJ1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSkKK3sKKwlwYW5p
YygiWGVuIEJVRyBhdCAlczolZFxuIiwgZmlsZSwgbGluZSk7CisKKwl3aGlsZSgxKTsKK30K
Kwordm9pZCB3YXJuKGNoYXIgKmZpbGUsIGludCBsaW5lKQoreworCXByaW50aygiWGVuIFdB
Uk4gYXQgJXM6JWRcbiIsIGZpbGUsIGxpbmUpOworCit9CisKZGlmZiAtciBlNzAxNDYxYjEy
NTEgeGVuL2FyY2gvYXJtL3hlbi9jcHUuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NwdS5jCUZyaSBGZWIg
MDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDk3IEBACisvKgorICogY3B1LmMK
KyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAg
ICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAg
IEphZU1pbiBSeXUgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhpcyBwcm9n
cmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBt
b2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzIAorICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVk
IGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICog
TUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg
U2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWls
cy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlm
IG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4s
IDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBV
U0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9zcGlu
bG9jay5oPgorI2luY2x1ZGUgPHhlbi9jcHVtYXNrLmg+CisjaW5jbHVkZSA8eGVuL3NtcC5o
PgorI2luY2x1ZGUgPHhlbi9pcnEuaD4KKyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgorI2lu
Y2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9wcmVlbXB0Lmg+CisjaW5jbHVk
ZSA8eGVuL3BlcmNwdS5oPgorCitjcHVtYXNrX3QgY3B1X29ubGluZV9tYXA7CitjcHVtYXNr
X3QgY3B1X3ByZXNlbnRfbWFwOworY3B1bWFza190IGNwdV9wb3NzaWJsZV9tYXA7CisKK25v
ZGVtYXNrX3Qgbm9kZV9vbmxpbmVfbWFwID0ge3sgWzBdID0gMVVMIH19OworCit1bnNpZ25l
ZCBjaGFyIGNwdV90b19ub2RlW05SX0NQVVNdIF9fcmVhZF9tb3N0bHkgPSB7CisgICAgICAg
IFswIC4uLiBOUl9DUFVTLTFdID0gTlVNQV9OT19OT0RFCit9OworCitjcHVtYXNrX3Qgbm9k
ZV90b19jcHVtYXNrW01BWF9OVU1OT0RFU10gX19yZWFkX21vc3RseTsKKworREVGSU5FX1BF
Ul9DUFVfUkVBRF9NT1NUTFkoY3B1bWFza192YXJfdCxjcHVfc2libGluZ19tYXNrKTsKK0RF
RklORV9QRVJfQ1BVX1JFQURfTU9TVExZKGNwdW1hc2tfdmFyX3QsY3B1X2NvcmVfbWFzayk7
CisKK2ludCBfX2NwdV91cCh1bnNpZ25lZCBpbnQgY3B1KQoreworCU5PVF9ZRVQoKTsKKwor
CXJldHVybiAwOworfQorCit2b2lkIF9fY3B1X2Rpc2FibGUodm9pZCkKK3sKKwlOT1RfWUVU
KCk7Cit9CisKK3ZvaWQgX19jcHVfZGllKHVuc2lnbmVkIGludCBjcHUpCit7CisJTk9UX1lF
VCgpOworfQorCit2b2lkIHNldF9jcHVfc2libGluZ19tYXAodW5zaWduZWQgaW50IGNwdSkK
K3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgc21wX3ByZXBhcmVfY3B1cyh1bnNpZ25lZCBp
bnQgbWF4X2NwdXMpCit7CisJTk9UX1lFVCgpOworfQorCit2b2lkIHNtcF9wcmVwYXJlX2Jv
b3RfY3B1KHZvaWQpCit7CisJTk9UX1lFVCgpOworfQorCithc21saW5rYWdlIHZvaWQgc3Rh
cnRfeGVuX29uX3NsYXZlX2NwdSh2b2lkKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9pZCBz
bXBfc2VuZF9ldmVudF9jaGVja19tYXNrKGNvbnN0IGNwdW1hc2tfdCAqbWFzaykKK3sKKwlO
T1RfWUVUKCk7Cit9CisKK3ZvaWQgc21wX2NhbGxfZnVuY3Rpb24odm9pZCAoKmYpKHZvaWQg
KnBhcmFtKSwgdm9pZCAqcGFyYW0sIGludCB3YWl0KQoreworCU5PVF9ZRVQoKTsKK30KKwor
dm9pZCBzbXBfc2VuZF9zdGF0ZV9kdW1wKHVuc2lnbmVkIGludCBjcHUpCit7CisJTk9UX1lF
VCgpOworfQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL2NyYXNoLmMK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2FyY2gvYXJtL3hlbi9jcmFzaC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApA
QCAtMCwwICsxLDI1IEBACisvKgorICogY3Jhc2guYworICoKKyAqIENvcHlyaWdodCAoQykg
MjAwOCBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNi
dWsuc3VoQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5
dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsg
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2Ug
YXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoK
KyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdp
bGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2
ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBo
YXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK
KyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVl
IFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRl
IDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKwordm9pZCBtYWNoaW5l
X2NyYXNoX3NodXRkb3duKHZvaWQpCit7Cit9CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVu
L2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWls
ZC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQ3IEBACisv
KgorICogZG9tYWluX2J1aWxkLmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBT
YW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsuc3Vo
QHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBzYW1z
dW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVi
bGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRo
aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUg
dXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJl
Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFs
b25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3
YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwg
Qm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKyNpbmNsdWRlIDx4ZW4vY29uZmln
Lmg+CisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+Cisj
aW5jbHVkZSA8eGVuL2NvbXBpbGUuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNs
dWRlIDx4ZW4vZWxmLmg+CisjaW5jbHVkZSA8eGVuL2RvbWFpbi5oPgorI2luY2x1ZGUgPHhl
bi9tbS5oPgorI2luY2x1ZGUgPHhlbi9pb2NhcC5oPgorI2luY2x1ZGUgPHhlbi94bWFsbG9j
Lmg+CisjaW5jbHVkZSA8eGVuL3ByZWVtcHQuaD4KKyNpbmNsdWRlIDx4ZW4vbGliZWxmLmg+
CisjaW5jbHVkZSA8cHVibGljL3hlbi5oPgorI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+
CisKKy8qCisgKiBkb21haW5fY29uc3RydWN0KCkgc2hvdWxkIGJlIGFsd2F5cyBpbnZva2Vk
IGluIGlkbGUgZG9tYWluCisgKi8KK2ludCBkb21haW5fY29uc3RydWN0KHN0cnVjdCBkb21h
aW4gKmQsIAorCQkgICAgIHVuc2lnbmVkIGxvbmcgaW1nX3N0YXJ0LCB1bnNpZ25lZCBsb25n
IGltZ19sZW4sIAorCQkgICAgIHVuc2lnbmVkIGxvbmcgZG9tX3NpemUsIHVuc2lnbmVkIGlu
dCB2Y3B1cykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKwpkaWZm
IC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9wYWdlLmMKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9kb21haW5fcGFnZS5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApA
QCAtMCwwICsxLDIyIEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhl
bi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL2xpYi5oPgorI2luY2x1ZGUgPHhlbi9wZXJmYy5o
PgorI2luY2x1ZGUgPHhlbi9kb21haW5fcGFnZS5oPgorCisjaWZkZWYgQ09ORklHX0RPTUFJ
Tl9QQUdFCisKK3ZvaWQgKm1hcF9kb21haW5fcGFnZSh1bnNpZ25lZCBsb25nIHBmbikKK3sK
KwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gTlVMTDsKK30KKwordm9pZCB1bm1hcF9kb21haW5f
cGFnZSh2b2lkICp2YSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKKyNlbmRpZgorCmRpZmYgLXIg
ZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYwotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2Zh
dWx0LmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTIzIEBA
CisvKg0KKyAqIHRyYXBzLmMNCisgKg0KKyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNh
bXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsuc3Vo
QHNhbXN1bmcuY29tPg0KKyAqICAgICAgICAgIEphZU1pbiBSeXUgICA8am03Ny5yeXVAc2Ft
c3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91
IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAqIGl0IHVuZGVyIHRoZSB0
ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFz
IHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uDQorICoN
CisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3
aWxsIGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBG
SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNo
b3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UNCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0
aGUgRnJlZSBTb2Z0d2FyZQ0KKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFj
ZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisj
aW5jbHVkZSA8eGVuL2NvbmZpZy5oPg0KKyNpbmNsdWRlIDx4ZW4vY29tcGlsZS5oPg0KKyNp
bmNsdWRlIDx4ZW4vZG9tYWluX3BhZ2UuaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisj
aW5jbHVkZSA8eGVuL3NjaGVkLmg+DQorI2luY2x1ZGUgPHhlbi9saWIuaD4NCisjaW5jbHVk
ZSA8eGVuL2NvbnNvbGUuaD4NCisjaW5jbHVkZSA8eGVuL21tLmg+DQorI2luY2x1ZGUgPHhl
bi9pcnEuaD4NCisjaW5jbHVkZSA8eGVuL3N5bWJvbHMuaD4NCisjaW5jbHVkZSA8YXNtL2N1
cnJlbnQuaD4NCisjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPg0KKyNpbmNsdWRlIDxhc20v
Z3Vlc3RfYWNjZXNzLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8
YXNtL21lbW9yeS5oPg0KKw0KK2FzbWxpbmthZ2Ugdm9pZCBfX2RpdjAodm9pZCkNCit7DQor
ICAgICAgICBwcmludGsoIkRpdmlzaW9uIGJ5IHplcm8gaW4ga2VybmVsLlxuIik7DQorfQ0K
Kw0KK2ludCBmaXh1cF9leGNlcHRpb24oc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQor
ew0KKwlyZXR1cm4gLUVJTlZBTDsNCit9DQorDQordm9pZCBzaG93X3JlZ2lzdGVycyhzdHJ1
Y3QgY3B1X3VzZXJfcmVncyAqY3R4KQ0KK3sNCit9DQorDQordm9pZCBkdW1wX2V4ZWN1dGlv
bl9zdGF0ZSh2b2lkKQ0KK3sNCit9DQorDQordm9pZCBzaG93X2V4ZWN1dGlvbl9zdGF0ZShz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCit7DQorCXByaW50aygiTm90IGltcGxlbWVu
dGVkXG4iKTsNCit9DQorDQorc3RhdGljIGludCB2ZXJpZnlfc3RhY2sodW5zaWduZWQgbG9u
ZyBzcCkNCit7DQorCXJldHVybiAwOw0KK30NCisNCitzdGF0aWMgdm9pZCBiYWNrdHJhY2Uo
c3RydWN0IGNwdV91c2VyX3JlZ3MgKmN0eCkNCit7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIHVu
cmVjb3ZlcmFibGVfZmF1bHQoY29uc3QgY2hhciAqc3RyLCBpbnQgZXJyLCBzdHJ1Y3QgdmNw
dSAqdiwgc3RydWN0IGNwdV9jdHggKmN0eCkNCit7DQorCXByaW50aygiVW5yZWNvdmVyYWJs
ZSBGYXVsdCA6ICVzXG4iLCBzdHIpOw0KKw0KKwl3aGlsZSgxKTsNCisNCit9DQorDQorbG9u
ZyBkb19zZXRfY2FsbGJhY2tzKHVuc2lnbmVkIGxvbmcgZXZlbnQsIHVuc2lnbmVkIGxvbmcg
ZmFpbHNhZmUpDQorew0KKwlyZXR1cm4gLUVJTlZBTDsNCisNCit9DQorDQorYXNtbGlua2Fn
ZSB2b2lkIGRvX3ByZWZldGNoX2Fib3J0KHVuc2lnbmVkIGxvbmcgcGMsIHN0cnVjdCBjcHVf
Y3R4ICpjdHgpDQorew0KKwl3aGlsZSgxKTsNCisJdW5yZWNvdmVyYWJsZV9mYXVsdCgicHJl
ZmV0Y2ggYWJvcnQiLCAwLCBjdXJyZW50LCBjdHgpOw0KK30NCisNCithc21saW5rYWdlIHZv
aWQgZG9fZGF0YV9hYm9ydCh1bnNpZ25lZCBsb25nIGZzciwgdW5zaWduZWQgbG9uZyBmYXIs
IHN0cnVjdCBjcHVfY3R4ICpjdHgpDQorew0KKwl3aGlsZSgxKTsNCisJdW5yZWNvdmVyYWJs
ZV9mYXVsdCgiZGF0YSBhYm9ydCIsIDAsIGN1cnJlbnQsIGN0eCk7DQorfQ0KKw0KK2FzbWxp
bmthZ2Ugdm9pZCBkb191bmRlZmluZWRfaW5zdHJ1Y3Rpb24odW5zaWduZWQgbG9uZyBwYywg
c3RydWN0IGNwdV9jdHggKmN0eCkNCit7DQorCXdoaWxlKDEpOw0KKwl1bnJlY292ZXJhYmxl
X2ZhdWx0KCJ1bmRlZmluZWQgaW5zdHJ1Y3Rpb24iLCAwLCBjdXJyZW50LCBjdHgpOw0KK30N
CisNCit2b2lkIHZjcHVfc2hvd19leGVjdXRpb25fc3RhdGUoc3RydWN0IHZjcHUgKnYpDQor
ew0KKwlwcmludGsoIk5vdCBpbXBsZW1lbnRlZFxuIik7DQorfQ0KKw0KK2xvbmcgcmVnaXN0
ZXJfZ3Vlc3Rfbm1pX2NhbGxiYWNrKHVuc2lnbmVkIGxvbmcgYWRkcmVzcykNCit7DQorCXBy
aW50aygiTm90IGltcGxlbWVudGVkIHlldFxuIik7DQorDQorCXJldHVybiAtMTsNCit9DQor
DQordm9pZCB1bnJlZ2lzdGVyX2d1ZXN0X25taV9jYWxsYmFjayh2b2lkKQ0KK3sNCisJcHJp
bnRrKCJOb3QgaW1wbGVtZW50ZWQgeWV0XG4iKTsNCit9DQorDQorbG9uZyBkb19zZXRfdHJh
cF90YWJsZShYRU5fR1VFU1RfSEFORExFKHRyYXBfaW5mb190KSB0cmFwcykNCit7DQorCXJl
dHVybiAtRUZBVUxUOw0KK30NCisNCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2Fy
bS94ZW4vZ3JhbnRfdGFibGUuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2dyYW50X3RhYmxlLmMJRnJpIEZl
YiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTMgQEAKKy8qCisgKiBncmFu
dF90YWJsZS5jCisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVj
dHJvbmljcworICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNv
bT4KKyAqICAgICAgICAgIFN1bmdLd2FuIEhlbyA8c2suaGVvQHNhbXN1bmcuY29tPgorICog
ICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBU
aGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUg
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0
cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJ
VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkg
b2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS
UE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3Jl
IGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9n
cmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9u
LCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEt
MTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9saWIuaD4KKyNpbmNsdWRlIDx4ZW4v
dHlwZXMuaD4KKyNpbmNsdWRlIDx4ZW4vY3B1bWFzay5oPgorI2luY2x1ZGUgPHhlbi9saXN0
Lmg+CisjaW5jbHVkZSA8eGVuL2tlcm5lbC5oPgorI2luY2x1ZGUgPHhlbi9zdHJpbmcuaD4K
KyNpbmNsdWRlIDx4ZW4vZXJybm8uaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNs
dWRlIDx4ZW4vbW0uaD4KKyNpbmNsdWRlIDx4ZW4vZG9tYWluX3BhZ2UuaD4KKyNpbmNsdWRl
IDx4ZW4vaXJxX2NwdXN0YXQuaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnQuaD4KKyNpbmNsdWRl
IDx4ZW4vaW9jYXAuaD4KKyNpbmNsdWRlIDx4ZW4vcGVyZmMuaD4KKyNpbmNsdWRlIDx4ZW4v
Z3Vlc3RfYWNjZXNzLmg+CisKKworaW50IGNyZWF0ZV9ncmFudF9ob3N0X21hcHBpbmcodWlu
dDY0X3QgYWRkciwgdW5zaWduZWQgbG9uZyBmcmFtZSwgdW5zaWduZWQgaW50IGZsYWdzLCB1
bnNpZ25lZCBpbnQgY2FjaGVfZmxhZ3MpCit7CisJTk9UX1lFVCgpOworCQorCXJldHVybiAt
RUlOVkFMOworfQorCitpbnQgcmVwbGFjZV9ncmFudF9ob3N0X21hcHBpbmcodWludDY0X3Qg
YWRkciwgdW5zaWduZWQgbG9uZyBmcmFtZSwgdWludDY0X3QgbmV3X2FkZHIsIHVuc2lnbmVk
IGludCBmbGFncykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gR05UU1RfZ2VuZXJhbF9l
cnJvcjsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL2lvbW11
LmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
eGVuL2FyY2gvYXJtL3hlbi9pb21tdS5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDI0IEBACisKKyNpbmNsdWRlIDx4ZW4vbGliLmg+CisjaW5jbHVkZSA8
eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2xpc3QuaD4KKyNpbmNsdWRlIDx4ZW4vc3Ry
aW5nLmg+CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+
CisjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8eGVuL2lvY2FwLmg+CisjaW5jbHVk
ZSA8YXNtL2lvbW11Lmg+CisKK2ludCBpb21tdV9tYXBfcGFnZShzdHJ1Y3QgZG9tYWluICpk
LCB1bnNpZ25lZCBsb25nIGdmbiwgdW5zaWduZWQgbG9uZyBtZm4sIHVuc2lnbmVkIGludCBm
bGFncykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKworaW50IGlv
bW11X3VubWFwX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgbG9uZyBnZm4pCit7
CisJTk9UX1lFVCgpOworCisJcmV0dXJuIC1FSU5WQUw7Cit9CmRpZmYgLXIgZTcwMTQ2MWIx
MjUxIHhlbi9hcmNoL2FybS94ZW4vaXJxLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9pcnEuYwlGcmkgRmVi
IDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw4NCBAQAorLyoKKyAqIGlycS5j
CisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcwor
ICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAg
ICAgICAgIEphZU1pbiBSeXUgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhp
cyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu
ZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwg
UHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICogdGhlIEZy
ZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9m
CisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UuICBTZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBk
ZXRhaWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3Jh
bTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwg
SW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEz
MDcgIFVTQQorICovCisKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8eGVu
L3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+
CisjaW5jbHVkZSA8eGVuL2lycS5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1
ZGUgPHhlbi9zcGlubG9jay5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUg
PHhlbi9ldmVudC5oPgorI2luY2x1ZGUgPHB1YmxpYy9ldmVudF9jaGFubmVsLmg+CisjaW5j
bHVkZSA8cHVibGljL3BoeXNkZXYuaD4KKyNpbmNsdWRlIDxwdWJsaWMvYXJjaC1hcm0uaD4K
KworaHdfaXJxX2NvbnRyb2xsZXIgbm9faXJxX3R5cGUgPSB7CisJLnR5cGVuYW1lID0gIm5v
bmUiLAorCS5zdGFydHVwICA9IGlycV9zdGFydHVwX25vbmUsCisJLnNodXRkb3duID0gaXJx
X3NodXRkb3duX25vbmUsCisJLmVuYWJsZSAgID0gaXJxX2VuYWJsZV9ub25lLAorCS5kaXNh
YmxlICA9IGlycV9kaXNhYmxlX25vbmUsCit9OworCitzdHJ1Y3QgaXJxX2Rlc2MgKmlycV9k
ZXNjOworCitpbnQgcGlycV9ndWVzdF91bm1hc2soc3RydWN0IGRvbWFpbiAqZCkKK3sKKwlO
T1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKK30KKworaW50IHBpcnFfZ3Vlc3RfYmluZChzdHJ1
Y3QgdmNwdSAqdiwgc3RydWN0IHBpcnEgKnBpcnEsIGludCB3aWxsX3NoYXJlKQoreworCU5P
VF9ZRVQoKTsKKworCXJldHVybiAwOworfQorCit2b2lkIHBpcnFfZ3Vlc3RfdW5iaW5kKHN0
cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwaXJxICpwaXJxKQoreworCU5PVF9ZRVQoKTsKK30K
KworCit2b2lkIHBpcnFfc2V0X2FmZmluaXR5KHN0cnVjdCBkb21haW4gKmQsIGludCBwaXJx
LCBjb25zdCBjcHVtYXNrX3QgKm1hc2spCit7CisJTk9UX1lFVCgpOworfQorCisKK3N0cnVj
dCBwaXJxICphbGxvY19waXJxX3N0cnVjdChzdHJ1Y3QgZG9tYWluICpkKQoreworCU5PVF9Z
RVQoKTsKKworCXJldHVybiBOVUxMOworfQorCitpbnQgYXJjaF9pbml0X29uZV9pcnFfZGVz
YyhzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7
Cit9CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3hlbi9tYWNoaW5lX2tl
eGVjLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIveGVuL2FyY2gvYXJtL3hlbi9tYWNoaW5lX2tleGVjLmMJRnJpIEZlYiAwMyAxNjowNzow
MyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+
CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CisjaW5jbHVkZSA8eGVuL2xpYi5oPgorI2luY2x1
ZGUgPHhlbi9zbXAuaD4KKyNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4KKyNpbmNsdWRlIDx4ZW4v
Y29uc29sZS5oPgorI2luY2x1ZGUgPHhlbi9rZXhlYy5oPgorI2luY2x1ZGUgPHhlbi9kb21h
aW5fcGFnZS5oPgorCitpbnQgbWFjaGluZV9rZXhlY19sb2FkKGludCB0eXBlLCBpbnQgc2xv
dCwgeGVuX2tleGVjX2ltYWdlX3QgKmltYWdlKQoreworICAgIHJldHVybiAtRUlOVkFMOwor
fQorCit2b2lkIG1hY2hpbmVfa2V4ZWNfdW5sb2FkKGludCB0eXBlLCBpbnQgc2xvdCwgeGVu
X2tleGVjX2ltYWdlX3QgKmltYWdlKQoreworfQorCit2b2lkIG1hY2hpbmVfcmVib290X2tl
eGVjKHhlbl9rZXhlY19pbWFnZV90ICppbWFnZSkKK3sKK30KKwordm9pZCBtYWNoaW5lX2tl
eGVjKHhlbl9rZXhlY19pbWFnZV90ICppbWFnZSkKK3sKK30KKworaW50IG1hY2hpbmVfa2V4
ZWNfZ2V0KHhlbl9rZXhlY19yYW5nZV90ICpyYW5nZSkKK3sKKwlyZXR1cm4gLUVJTlZBTDsK
K30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL21tLmMKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9tbS5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsx
LDE5NCBAQAorLyoKKyAqIG1tLmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBT
YW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggIDxzYnVrLnN1
aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEphZU1pbiBSeXUgICAgPGptNzcucnl1QHNh
bXN1bmcuY29tPgorICogICAgICAgICAgU3VuZ0t3YW4gSGVvICA8c2suaGVvQHNhbXN1bmcu
Y29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNo
ZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2Vm
dWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1w
bGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2
ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcg
d2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUK
KyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0
b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2xpYi5oPgor
I2luY2x1ZGUgPHhlbi90eXBlcy5oPgorI2luY2x1ZGUgPHhlbi9jcHVtYXNrLmg+CisjaW5j
bHVkZSA8eGVuL2xpc3QuaD4KKyNpbmNsdWRlIDx4ZW4va2VybmVsLmg+CisjaW5jbHVkZSA8
eGVuL3N0cmluZy5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPHhlbi9z
Y2hlZC5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2luY2x1ZGUgPHhlbi9kb21haW5fcGFn
ZS5oPgorI2luY2x1ZGUgPHhlbi9pcnFfY3B1c3RhdC5oPgorI2luY2x1ZGUgPHhlbi9ldmVu
dC5oPgorI2luY2x1ZGUgPHhlbi9pb2NhcC5oPgorI2luY2x1ZGUgPHhlbi9wZXJmYy5oPgor
I2luY2x1ZGUgPHhlbi9ndWVzdF9hY2Nlc3MuaD4KKworI2RlZmluZSBWRVJCT1NFIDEKKwor
I2RlZmluZSBNTVVfVVBEQVRFX1BSRUVNUFRFRCAgICAgICAgICAofih+MFUgPj4gMSkpCisK
K3N0YXRpYyB1bnNpZ25lZCBsb25nIG1wdF9zaXplOworCisvKiBGcmFtZSB0YWJsZSBhbmQg
aXRzIHNpemUgaW4gcGFnZXMuICovCitzdHJ1Y3QgcGFnZV9pbmZvICpmcmFtZV90YWJsZTsK
K3Vuc2lnbmVkIGxvbmcgbWluX3BhZ2UgPSB+MFVMOzsKK3Vuc2lnbmVkIGxvbmcgbWF4X3Bh
Z2UgPSAwVUw7CisKK3Vuc2lnbmVkIGxvbmcgeGVuaGVhcF9waHlzX3N0YXJ0ID0gfjBVTDsK
K3Vuc2lnbmVkIGxvbmcgeGVuaGVhcF9waHlzX2VuZCA9IDBVTDsKKwordW5zaWduZWQgbG9u
ZyB4ZW5fcGh5c19zdGFydCA9IH4wVUw7Cit1bnNpZ25lZCBsb25nIHhlbl9waHlzX2VuZCA9
IDBVTDsKKworI2lmZGVmIE1FTU9SWV9HVUFSRAordm9pZCBtZW1ndWFyZF9pbml0KHZvaWQp
Cit7CisJTk9UX1lFVCgpOworfQorCit2b2lkIG1lbWd1YXJkX2d1YXJkX3JhbmdlKHZvaWQg
KnAsIHVuc2lnbmVkIGxvbmcgbCkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgbWVtZ3Vh
cmRfdW5ndWFyZF9yYW5nZSh2b2lkICpwLCB1bnNpZ25lZCBsb25nIGwpCit7CisJTk9UX1lF
VCgpOworfQorCisjZW5kaWYKKwordm9pZCBwdXRfcGFnZShzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlKQoreworCU5PVF9ZRVQoKTsKK30KKworc3RydWN0IGRvbWFpbiAqcGFnZV9nZXRfb3du
ZXJfYW5kX3JlZmVyZW5jZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQoreworCU5PVF9ZRVQo
KTsKK30KKworaW50IGdldF9wYWdlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHN0cnVjdCBk
b21haW4gKmRvbWFpbikKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKK30KKwordm9p
ZCBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHN0
cnVjdCBkb21haW4gKmQsIGludCByZWFkb25seSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3Zv
aWQgc2hhcmVfeGVuX3BhZ2Vfd2l0aF9wcml2aWxlZ2VkX2d1ZXN0cyhzdHJ1Y3QgcGFnZV9p
bmZvICpwYWdlLCBpbnQgcmVhZG9ubHkpCit7CisJTk9UX1lFVCgpOworfQorCitzdGF0aWMg
aW50IHBpbl9wYWdlX3RhYmxlKHUzMiBtZm4sIHN0cnVjdCBkb21haW4gKmQpCit7CisJTk9U
X1lFVCgpOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgdW5waW5fcGFnZV90YWJs
ZSh1MzIgbWZuLCBzdHJ1Y3QgZG9tYWluICpkKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVy
biAwOworfQorCit2b2lkIGZyZWVfcGFnZV90eXBlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2Us
IHVuc2lnbmVkIGxvbmcgdHlwZSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgcHV0X3Bh
Z2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQoreworCU5PVF9ZRVQoKTsKK30KKwor
CitpbnQgZ2V0X3BhZ2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCB1bnNpZ25lZCBs
b25nIHR5cGUpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7Cit9CisKK2ludCBkb19t
bXVleHRfb3AoWEVOX0dVRVNUX0hBTkRMRShtbXVleHRfb3BfdCkgdW9wcywgdW5zaWduZWQg
aW50IGNvdW50LAorCQkgWEVOX0dVRVNUX0hBTkRMRSh1aW50KSBwZG9uZSwgdW5zaWduZWQg
aW50IGZvcmVpZ25kb20pCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIC1FSU5WQUw7Cit9
CisKK2ludCBkb19tbXVfdXBkYXRlKFhFTl9HVUVTVF9IQU5ETEUobW11X3VwZGF0ZV90KSB1
cmVxcywKKwkJICB1bnNpZ25lZCBpbnQgY291bnQsIAorCQkgIFhFTl9HVUVTVF9IQU5ETEUo
dWludCkgcGRvbmUsCisJCSAgdW5zaWduZWQgaW50IGZvcmVpZ25kb20pCit7CisJTk9UX1lF
VCgpOworCisgICAgICAgIHJldHVybiAtRUlOVkFMOworfQorCitpbnQgZG9fdXBkYXRlX3Zh
X21hcHBpbmcodTMyIHZhLCB1MzIgZmxhZ3MsIHU2NCB2YWw2NCkKK3sKKwlOT1RfWUVUKCk7
CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKworbG9uZyBhcmNoX21lbW9yeV9vcChpbnQgb3As
IFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVy
biAtRUlOVkFMOworfQorCisKKworaW50IHN0ZWFsX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwg
c3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgdW5zaWduZWQgaW50IG1lbWZsYWdzKQoreworCU5P
VF9ZRVQoKTsKKworCXJldHVybiAtRUlOVkFMOworfQorCitpbnQgZG9uYXRlX3BhZ2Uoc3Ry
dWN0IGRvbWFpbiAqZCwgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgdW5zaWduZWQgaW50IG1l
bWZsYWdzKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAtRUlOVkFMOworfQorCisKK3Vu
c2lnbmVkIGxvbmcgZG9tYWluX2dldF9tYXhpbXVtX2dwZm4oc3RydWN0IGRvbWFpbiAqZCkK
K3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMHhGRkZGRkZGRjsKK30KKworaW50IHBhZ2Vf
aXNfcmFtX3R5cGUodW5zaWduZWQgbG9uZyBtZm4sIHVuc2lnbmVkIGxvbmcgbWVtX3R5cGUp
Cit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIC1FSU5WQUw7Cit9CmRpZmYgLXIgZTcwMTQ2
MWIxMjUxIHhlbi9hcmNoL2FybS94ZW4vcDJtLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9wMm0uYwlGcmkg
RmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw0NCBAQAorLyoKKyAqIHAy
bS5jCisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmlj
cworICogICAgICAgICAgU2FuZy1idW0gU3VoICA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+Cisg
KiAgICAgICAgICBKYWVNaW4gUnl1ICAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqICAg
ICAgICAgIFN1bmdLd2FuIEhlbyAgPHNrLmhlb0BzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlz
IHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5k
L29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQ
dWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmli
dXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhP
VVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YK
KyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T
RS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFt
OyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJ
bmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMw
NyAgVVNBCisgKi8KKworI2luY2x1ZGUgPGFzbS9kb21haW4uaD4KKyNpbmNsdWRlIDxhc20v
cGFnZS5oPgorI2luY2x1ZGUgPGFzbS9wYWdpbmcuaD4KKyNpbmNsdWRlIDxhc20vcDJtLmg+
CisjaW5jbHVkZSA8eGVuL2V2ZW50Lmg+CisKK2ludCBwMm1fcG9kX2RlY3JlYXNlX3Jlc2Vy
dmF0aW9uKHN0cnVjdCBkb21haW4gKmQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHhlbl9wZm5fdCBncGZuLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25l
ZCBpbnQgb3JkZXIpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7Cit9CisKK2ludCBn
dWVzdF9waHlzbWFwX21hcmtfcG9wdWxhdGVfb25fZGVtYW5kKHN0cnVjdCBkb21haW4gKmQs
IHVuc2lnbmVkIGxvbmcgZ2ZuLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB1bnNpZ25lZCBpbnQgb3JkZXIpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7
Cit9CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS94ZW4vcGNpLmMKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9wY2kuYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCAr
MSw3NCBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogcGNpLmMKKyAqIAorICog
QXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBQQ0kgYWNjZXNzIGZ1bmN0aW9ucy4KKyAqLworCisj
aW5jbHVkZSA8eGVuL3NwaW5sb2NrLmg+CisjaW5jbHVkZSA8eGVuL3BjaS5oPgorI2luY2x1
ZGUgPGFzbS9pby5oPgorCitzdGF0aWMgREVGSU5FX1NQSU5MT0NLKHBjaV9jb25maWdfbG9j
ayk7CisKK3VpbnQzMl90IHBjaV9jb25mX3JlYWQodWludDMyX3QgY2Y4LCB1aW50OF90IG9m
ZnNldCwgdWludDhfdCBieXRlcykKK3sKKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOworICAg
IHVpbnQzMl90IHZhbHVlOworCisgICAgQlVHX09OKChvZmZzZXQgKyBieXRlcykgPiA0KTsK
KworICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwY2lfY29uZmlnX2xvY2ssIGZsYWdzKTsKKwor
ICAgIG91dGwoY2Y4LCAweGNmOCk7CisKKyAgICBzd2l0Y2ggKCBieXRlcyApCisgICAgewor
ICAgIGNhc2UgMToKKyAgICAgICAgdmFsdWUgPSBpbmIoMHhjZmMgKyBvZmZzZXQpOworICAg
ICAgICBicmVhazsKKyAgICBjYXNlIDI6CisgICAgICAgIHZhbHVlID0gaW53KDB4Y2ZjICsg
b2Zmc2V0KTsKKyAgICAgICAgYnJlYWs7CisgICAgY2FzZSA0OgorICAgICAgICB2YWx1ZSA9
IGlubCgweGNmYyArIG9mZnNldCk7CisgICAgICAgIGJyZWFrOworICAgIGRlZmF1bHQ6Cisg
ICAgICAgIHZhbHVlID0gMDsKKyAgICAgICAgQlVHKCk7CisgICAgfQorCisgICAgc3Bpbl91
bmxvY2tfaXJxcmVzdG9yZSgmcGNpX2NvbmZpZ19sb2NrLCBmbGFncyk7CisKKyAgICByZXR1
cm4gdmFsdWU7Cit9CisKK3ZvaWQgcGNpX2NvbmZfd3JpdGUodWludDMyX3QgY2Y4LCB1aW50
OF90IG9mZnNldCwgdWludDhfdCBieXRlcywgdWludDMyX3QgZGF0YSkKK3sKKyAgICB1bnNp
Z25lZCBsb25nIGZsYWdzOworCisgICAgQlVHX09OKChvZmZzZXQgKyBieXRlcykgPiA0KTsK
KworICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwY2lfY29uZmlnX2xvY2ssIGZsYWdzKTsKKwor
ICAgIG91dGwoY2Y4LCAweGNmOCk7CisKKyAgICBzd2l0Y2ggKCBieXRlcyApCisgICAgewor
ICAgIGNhc2UgMToKKyAgICAgICAgb3V0YigodWludDhfdClkYXRhLCAweGNmYyArIG9mZnNl
dCk7CisgICAgICAgIGJyZWFrOworICAgIGNhc2UgMjoKKyAgICAgICAgb3V0dygodWludDE2
X3QpZGF0YSwgMHhjZmMgKyBvZmZzZXQpOworICAgICAgICBicmVhazsKKyAgICBjYXNlIDQ6
CisgICAgICAgIG91dGwoZGF0YSwgMHhjZmMgKyBvZmZzZXQpOworICAgICAgICBicmVhazsK
KyAgICB9CisKKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwY2lfY29uZmlnX2xvY2ss
IGZsYWdzKTsKK30KKworCisjZGVmaW5lIFBDSV9DT05GX0FERFJFU1MoYnVzLCBkZXYsIGZ1
bmMsIHJlZykgXAorICAgICgweDgwMDAwMDAwIHwgKGJ1cyA8PCAxNikgfCAoZGV2IDw8IDEx
KSB8IChmdW5jIDw8IDgpIHwgKHJlZyAmIH4zKSkKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4
ZW4vYXJjaC9hcm0veGVuL3BlcmZtb24uYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3BlcmZtb24uYwlGcmkg
RmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyNiBAQAorI2luY2x1ZGUg
PHhlbi9ldmVudC5oPgorI2luY2x1ZGUgPHhlbi90eXBlcy5oPgorI2luY2x1ZGUgPHhlbi9l
cnJuby5oPgorI2luY2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL25taS5oPgor
I2luY2x1ZGUgPHhlbi9zdHJpbmcuaD4KKyNpbmNsdWRlIDx4ZW4vZGVsYXkuaD4KKyNpbmNs
dWRlIDx4ZW4veGVub3Byb2YuaD4KKyNpbmNsdWRlIDxwdWJsaWMveGVuLmg+CisKKworaW50
IHhlbm9wcm9mX2FyY2hfY291bnRlcihYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKK3sK
KwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKK30KKworCitpbnQgeGVub3Byb2ZfYXJjaF9p
YnNfY291bnRlcihYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKK3sKKwlOT1RfWUVUKCk7
CisKKwlyZXR1cm4gMDsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0v
eGVuL3NldHVwLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMg
MjAxMiArMDkwMApAQCAtMCwwICsxLDY0IEBACisvKgorICogc2V0dXAuYworICoKKyAqIENv
cHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAg
IFNhbmctYnVtIFN1aCAgIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAJICAgIEph
ZW1pbiBSeXUgICAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEpvb1lv
dW5nIEh3YW5nIDxqb295b3VuZy5od2FuZ0BzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29y
IG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMKKyAqIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBT
b2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRl
ZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQg
QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAq
IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g
IFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFp
bHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBp
ZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMu
LCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAg
VVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vaW5p
dC5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2lu
Y2x1ZGUgPHhlbi9jb21waWxlLmg+CisjaW5jbHVkZSA8eGVuL3N0cmluZy5oPgorI2luY2x1
ZGUgPHhlbi9saWIuaD4KKyNpbmNsdWRlIDx4ZW4vcHJlZW1wdC5oPgorI2luY2x1ZGUgPHB1
YmxpYy92ZXJzaW9uLmg+CisjaW5jbHVkZSA8cHVibGljL3NjaGVkLmg+CisKKworc3RydWN0
IGRvbWFpbiBfZG9tX3hlbiA9IHsKKyAgICAgICAgLnJlZmNudCA9IEFUT01JQ19JTklUKDEp
LAorICAgICAgICAuZG9tYWluX2lkID0gRE9NSURfWEVOLAorICAgICAgICAuZG9tYWluX2xv
Y2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsCit9OworCitzdHJ1Y3QgZG9tYWluIF9kb21faW8g
PSB7CisgICAgICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwKKyAgICAgICAgLmRvbWFp
bl9pZCA9IERPTUlEX0lPLAorICAgICAgICAuZG9tYWluX2xvY2sgPSBTUElOX0xPQ0tfVU5M
T0NLRUQsCit9OworCitzdHJ1Y3QgZG9tYWluIF9kb21fY293ID0geworICAgICAgICAucmVm
Y250ID0gQVRPTUlDX0lOSVQoMSksCisgICAgICAgIC5kb21haW5faWQgPSBET01JRF9DT1cs
CisgICAgICAgIC5kb21haW5fbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRCwKK307CisKK3N0
cnVjdCBkb21haW4gKmRvbV94ZW4gPSAmX2RvbV94ZW47CitzdHJ1Y3QgZG9tYWluICpkb21f
aW8gPSAmX2RvbV9pbzsKK3N0cnVjdCBkb21haW4gKmRvbV9jb3cgPSAmX2RvbV9jb3c7CisK
K3ZvaWQgYXJjaF9nZXRfeGVuX2NhcHMoeGVuX2NhcGFiaWxpdGllc19pbmZvX3QgKmluZm8p
Cit7Cit9CisKK2FzbWxpbmthZ2Ugdm9pZCBzdGFydF94ZW4odm9pZCkKK3sKK30KKwpkaWZm
IC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL3NodXRkb3duLmMKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJt
L3hlbi9zaHV0ZG93bi5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCww
ICsxLDM4IEBACisvKgorICogc2h1dGRvd24uYworICoKKyAqIENvcHlyaWdodCAoQykgMjAw
OC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAgIFNhbmctYnVtIFN1aCA8
c2J1ay5zdWhAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBKYWVNaW4gUnl1ICAgPGptNzcu
cnl1QHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5z
ZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJ
VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVy
YWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxk
IGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZy
ZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3Vp
dGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8
eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vbGli
Lmg+CisjaW5jbHVkZSA8eGVuL3NodXRkb3duLmg+CisKK3ZvaWQgbWFjaGluZV9oYWx0KHZv
aWQpCit7CisJcHJpbnRrKCJtYWNoaW5lX2hhbHQgY2FsbGVkOiBzcGlubmluZy4uLi5cbiIp
OworCXdoaWxlKDEpOworfQorCit2b2lkIG1hY2hpbmVfcmVzdGFydCh1bnNpZ25lZCBpbnQg
ZGVsYXlfbWlsbGlzZWNzKQoreworCXByaW50aygibWFjaGluZV9yZXN0YXJ0IGNhbGxlZDog
c3Bpbm5pbmcuLi4uXG4iKTsKKwl3aGlsZSgxKTsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1
MSB4ZW4vYXJjaC9hcm0veGVuL3RpbWUuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3RpbWUuYwlGcmkgRmVi
IDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw4MyBAQAorLyoKKyAqIHRpbWUu
YyAKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBTYW1zdW5nIEVsZWN0cm9uaWNz
IAorICogICAgICAgICAgU2FuZy1idW0gU3VoICAgIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4K
KyAqICAgICAgICAgIEpvb1lvdW5nIEh3YW5nICA8am9veW91bmcuaHdhbmdAc2Ftc3VuZy5j
b20+CisgKiAgICAgICAgICBKYWVtaW4gUnl1ICAgICAgPGptNzcucnl1QHNhbXN1bmcuY29t
PgorICogCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVk
IGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJv
Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVs
LAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxp
ZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBB
UlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVk
IGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdp
dGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisg
KiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9u
LCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9pbml0Lmg+Cisj
aW5jbHVkZSA8eGVuL3RpbWUuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNsdWRl
IDx4ZW4vZXZlbnQuaD4KKyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgorI2luY2x1ZGUgPGFz
bS90eXBlcy5oPgorI2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+CisjaW5jbHVkZSA8YXNtL2Rp
djY0Lmg+CisjaW5jbHVkZSA8YXNtL3RpbWUuaD4KKwordm9pZCBzZW5kX3RpbWVyX2V2ZW50
KHN0cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKworaW50IHJlcHJvZ3JhbV90
aW1lcihzX3RpbWVfdCB0aW1lb3V0KQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAxOwor
fQorCit2b2lkIHNtcF9icm9hZGNhc3RfdGltZXIodm9pZCkKK3sKKwlOT1RfWUVUKCk7Cit9
CisKK3ZvaWQgdXBkYXRlX3ZjcHVfc3lzdGVtX3RpbWUoc3RydWN0IHZjcHUgKnYpCit7CisJ
Tk9UX1lFVCgpOworCisJcmV0dXJuOworfQorCit2b2lkIGRvX3NldHRpbWUodW5zaWduZWQg
bG9uZyBzZWNzLCB1bnNpZ25lZCBsb25nIG5zZWNzLCB1NjQgc3lzdGVtX3RpbWVfYmFzZSkK
K3sKKwlOT1RfWUVUKCk7Cit9CisKK3N0cnVjdCB0bSB3YWxsY2xvY2tfdGltZSh2b2lkKQor
eworCXJldHVybiBnbXRpbWUoMCk7Cit9CisKKworc190aW1lX3QgZ2V0X3NfdGltZSh2b2lk
KQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAwOworfQorCit2b2lkIGRvbWFpbl9zZXRf
dGltZV9vZmZzZXQoc3RydWN0IGRvbWFpbiAqZCwgaW50MzJfdCB0aW1lX29mZnNldF9zZWNv
bmRzKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9pZCB0aW1la2VlcGluZ19pbml0KHZvaWQp
Cit7CisJTk9UX1lFVCgpOworfQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0v
eGVuL3RsYi5jCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3hlbi9hcmNoL2FybS94ZW4vdGxiLmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEy
ICswOTAwCkBAIC0wLDAgKzEsMjYgQEAKKy8qCisgKiB0bGIuYworICoKKyAqIENvcHlyaWdo
dCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAgIFNhbmct
YnVtIFN1aCA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBKYWVNaW4gUnl1
ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBp
dCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIg
b2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5k
YXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl
IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7
IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklM
SVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICog
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUg
dG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ
bGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworI2lu
Y2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vaW5pdC5oPgorI2luY2x1ZGUg
PHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9zb2Z0aXJxLmg+CisKK3UzMiB0bGJmbHVz
aF9jbG9jayA9IDFVOwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL3hl
bi5sZHMuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi94ZW4vYXJjaC9hcm0veGVuL3hlbi5sZHMuUwlGcmkgRmViIDAzIDE2OjA3OjAzIDIw
MTIgKzA5MDAKQEAgLTAsMCArMSwxNTkgQEAKKy8qCisgKiB4ZW4ubGRzLlMKKyAqCisgKiBD
b3B5cmlnaHQgKEMpIDIwMDggU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgU2Fu
Zy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIENoYW5KdSBQ
YXJrICA8YmVzdHdvcmxkQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAg
IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9m
IExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0
aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3
aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElU
WSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91
IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRv
IHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxh
Y2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2lu
Y2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vcGFnZS5oPgorCitPVVRQVVRf
QVJDSChhcm0pCitFTlRSWShzdGFydCkKKworU0VDVElPTlMKK3sKKwkuID0gMHhGRjAwODAw
MDsKKwlfc3RhcnQgPSAuOworCS50ZXh0IDogeworCQlfc3RleHQgPSAuOworCQkqKC5oZWFk
KQorCQkqKC50ZXh0KQorCQkqKC5maXh1cCkKKwkJKiguZ251Lndhcm5pbmcpCisJCV9ldGV4
dCA9IC47CisJfQorCisJLnJvZGF0YSA6IHsKKwkJKigucm9kYXRhKQorCQkqKC5yb2RhdGEu
KikKKwl9CisKKwkuID0gQUxJR04oMzIpOworCS5kYXRhLnJlYWRfbW9zdGx5IDogeworCQkv
KiBFeGNlcHRpb24gdGFibGUgKi8KKwkJX3NleHRhYmxlID0gLjsKKwkJX19zdGFydF9fX2V4
X3RhYmxlID0gLjsKKwkJKiguZXhfdGFibGUpCisJCV9fc3RvcF9fX2V4X3RhYmxlID0gLjsK
KworCQkvKiBQcmUtZXhjZXB0aW9uIHRhYmxlICovCisJCV9fc3RhcnRfX19wcmVfZXhfdGFi
bGUgPSAuOworCQkqKC5leF90YWJsZS5wcmUpCisJCV9fc3RvcF9fX3ByZV9leF90YWJsZSA9
IC47CisJCV9lZXh0YWJsZSA9IC47CisJCSooLmRhdGEucmVhZF9tb3N0bHkpCisJCSooLmRh
dGEucmVsLnJvKQorCQkqKC5kYXRhLnJlbC5yby4qKQorCX0gCisKKwkuID0gQUxJR04oUEFH
RV9TSVpFKTsKKwkuZGF0YSA6IHsKKwkJX3NkYXRhID0gLjsKKwkJKiguZGF0YSkKKwkJKigu
ZGF0YS5yZWwpCisJCSooLmRhdGEucmVsLiopCisJCV9lZGF0YSA9IC47CisJfQorCisJLiA9
IEFMSUdOKFBBR0VfU0laRSk7ICAgICAgICAgICAgIC8qIEluaXQgY29kZSBhbmQgZGF0YSAq
LworCV9faW5pdF9iZWdpbiA9IC47CisKKwkuaW5pdC50ZXh0IDogeworCQlfc2luaXR0ZXh0
ID0gLjsKKwkJKiguaW5pdC50ZXh0KSAKKwkJX2Vpbml0dGV4dCA9IC47CisJfQorCisJLmlu
aXQuZGF0YSA6IHsKKwkJX3Npbml0ZGF0YSA9IC47CisJCSooLmluaXQucm9kYXRhKQorCQkq
KC5pbml0LnJvZGFhdGEuc3RyKikKKwkJKiguaW5pdC5kYXRhKQorCQkqKC5pbml0LmRhdGEu
cmVsKQorCQkqKC5pbml0LmRhdGEucmVsLiopCisJCV9laW5pdGRhdGEgPSAuOworCX0KKwor
CS4gPSBBTElHTigzMik7CisJLmluaXQubWVtdGFibGUgOiB7CisJCV9zbWVtdGFibGUgPSAu
OworCQkqKC5pbml0Lm1lbXRhYmxlKQorCQkqKC5pbml0Lm1lbXRhYmxlLiopCisJCV9lbWVt
dGFibGUgPSAuOworCX0KKworCS4gPSBBTElHTigzMik7CisJLmluaXQuc2V0dXAgOiB7CisJ
CV9zaW5pdHNldHVwID0gLjsKKwkJX19zZXR1cF9zdGFydCA9IC47CisJCSooLmluaXQuc2V0
dXApIAorCQlfX3NldHVwX2VuZCA9IC47CisJCV9laW5pdHNldHVwID0gLjsKKwl9CisKKwku
aW5pdGNhbGwuaW5pdCA6IHsKKwkJX3Npbml0Y2FsbCA9IC47CisJCV9faW5pdGNhbGxfc3Rh
cnQgPSAuOworCQkqKC5pbml0Y2FsbHByZXNtcC5pbml0KQorCQlfX3ByZXNtcF9pbml0Y2Fs
bF9lbmQgPSAuOworCQkqKC5pbml0Y2FsbDEuaW5pdCkgCisJCV9faW5pdGNhbGxfZW5kID0g
LjsKKwkJX2Vpbml0Y2FsbCA9IC47CisJfQorCisJLnhzbV9pbml0Y2FsbC5pbml0IDogewor
CQlfc3hzbV9pbml0Y2FsbCA9IC47CisJCV9feHNtX2luaXRjYWxsX3N0YXJ0ID0gLjsKKwkJ
KigueHNtX2luaXRjYWxsLmluaXQpCisJCV9feHNtX2luaXRjYWxsX2VuZCA9IC47CisJCV9l
eHNtX2luaXRjYWxsID0gLjsKKwl9CisJX19pbml0X2VuZCA9IC47CisKKwkuID0gQUxJR04o
UEFHRV9TSVpFKTsKKworCS5ic3MgOiB7CisJCV9zYnNzID0gLjsJCS8qIEJTUyAqLworCQlf
X2Jzc19zdGFydCA9IC47CisJCSooLmJzcy5wYWdlX2FsaWduZWQpCisJCSooLmJzcy5zdGFj
a19hbGlnbmVkKQorCQkqKC5ic3MucGVyY3B1KQorCQkqKC5ic3MpCisJCV9fYnNzX2VuZCA9
IC47CisJCV9lYnNzID0gLjsKKwl9CisJX2VuZCA9IC4gOworCS8qIFNlY3Rpb25zIHRvIGJl
IGRpc2NhcmRlZCAqLworCisgIAkvRElTQ0FSRC8gOiB7CisgIAkJKigudGV4dC5leGl0KQor
CQkqKC5kYXRhLmV4aXQpCisJCSooLmV4aXRjYWxsLmV4aXQpCisJfQorCS8qIFN0YWJzIGRl
YnVnZ2luZyBzZWN0aW9ucy4gICovCisJLnN0YWIgMCA6IHsgKiguc3RhYikgfQorCS5zdGFi
c3RyIDAgOiB7ICooLnN0YWJzdHIpIH0KKwkuc3RhYi5leGNsIDAgOiB7ICooLnN0YWIuZXhj
bCkgfQorCS5zdGFiLmV4Y2xzdHIgMCA6IHsgKiguc3RhYi5leGNsc3RyKSB9CisJLnN0YWIu
aW5kZXggMCA6IHsgKiguc3RhYi5pbmRleCkgfQorCS5zdGFiLmluZGV4c3RyIDAgOiB7ICoo
LnN0YWIuaW5kZXhzdHIpIH0KKwkuY29tbWVudCAwIDogeyAqKC5jb21tZW50KSB9CisJCit9
CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9hY3BpLmgKLS0t
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2lu
Y2x1ZGUvYXNtLWFybS9hY3BpLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBA
IC0wLDAgKzEsOCBAQAorI2lmbmRlZiBfX0FSTV9BQ1BJX0hfXworI2RlZmluZSBfX0FSTV9B
Q1BJX0hfXworCisjZGVmaW5lIENPTVBJTEVSX0RFUEVOREVOVF9JTlQ2NCAgIGxvbmcgbG9u
ZworI2RlZmluZSBDT01QSUxFUl9ERVBFTkRFTlRfVUlOVDY0ICB1bnNpZ25lZCBsb25nIGxv
bmcKKworI2VuZGlmIC8qIV9fQVJNX0FDUElfSF9fICovCisKZGlmZiAtciBlNzAxNDYxYjEy
NTEgeGVuL2luY2x1ZGUvYXNtLWFybS9hc20tbWFjcm9zLmgKLS0tIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9h
c20tbWFjcm9zLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEs
MTA2IEBACisjaWZuZGVmIF9fQVJNX0FTTV9NQUNST1NfSF9fCisjZGVmaW5lIF9fQVJNX0FT
TV9NQUNST1NfSF9fCisKKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CisKKyNpZmRlZiBfX0FT
U0VNQkxZX18KKy8qCisgKiBFbmRpYW4gaW5kZXBlbmRlbnQgbWFjcm9zIGZvciBzaGlmdGlu
ZyBieXRlcyB3aXRoaW4gcmVnaXN0ZXJzLgorICovCisjaWZuZGVmIF9fQVJNRUJfXworI2Rl
ZmluZSBwdWxsICAgICAgICAgICAgbHNyCisjZGVmaW5lIHB1c2ggICAgICAgICAgICBsc2wK
KyNkZWZpbmUgZ2V0X2J5dGVfMCAgICAgIGxzbCAjMAorI2RlZmluZSBnZXRfYnl0ZV8xICAg
ICAgbHNyICM4CisjZGVmaW5lIGdldF9ieXRlXzIgICAgICBsc3IgIzE2CisjZGVmaW5lIGdl
dF9ieXRlXzMgICAgICBsc3IgIzI0CisjZGVmaW5lIHB1dF9ieXRlXzAgICAgICBsc2wgIzAK
KyNkZWZpbmUgcHV0X2J5dGVfMSAgICAgIGxzbCAjOAorI2RlZmluZSBwdXRfYnl0ZV8yICAg
ICAgbHNsICMxNgorI2RlZmluZSBwdXRfYnl0ZV8zICAgICAgbHNsICMyNAorI2Vsc2UKKyNk
ZWZpbmUgcHVsbCAgICAgICAgICAgIGxzbAorI2RlZmluZSBwdXNoICAgICAgICAgICAgbHNy
CisjZGVmaW5lIGdldF9ieXRlXzAgICAgICBsc3IgIzI0CisjZGVmaW5lIGdldF9ieXRlXzEg
ICAgICBsc3IgIzE2CisjZGVmaW5lIGdldF9ieXRlXzIgICAgICBsc3IgIzgKKyNkZWZpbmUg
Z2V0X2J5dGVfMyAgICAgIGxzbCAjMAorI2RlZmluZSBwdXRfYnl0ZV8wICAgICAgbHNsICMy
NAorI2RlZmluZSBwdXRfYnl0ZV8xICAgICAgbHNsICMxNgorI2RlZmluZSBwdXRfYnl0ZV8y
ICAgICAgbHNsICM4CisjZGVmaW5lIHB1dF9ieXRlXzMgICAgICBsc2wgIzAKKyNlbmRpZgor
CisjZGVmaW5lIFBMRChjb2RlLi4uKQljb2RlCisKKyNkZWZpbmUgQ1RYVF9SMAkJMAorI2Rl
ZmluZSBDVFhUX1IxCQk0CisjZGVmaW5lIENUWFRfUjIJCTgKKyNkZWZpbmUgQ1RYVF9SMwkJ
MTIKKyNkZWZpbmUgQ1RYVF9SNAkJMTYKKyNkZWZpbmUgQ1RYVF9SNQkJMjAKKyNkZWZpbmUg
Q1RYVF9SNgkJMjQKKyNkZWZpbmUgQ1RYVF9SNwkJMjgKKyNkZWZpbmUgQ1RYVF9SOAkJMzIK
KyNkZWZpbmUgQ1RYVF9SOQkJMzYKKyNkZWZpbmUgQ1RYVF9SMTAJNDAKKyNkZWZpbmUgQ1RY
VF9SMTEJNDQKKyNkZWZpbmUgQ1RYVF9SMTIJNDgKKyNkZWZpbmUgQ1RYVF9VU1AJNTIKKyNk
ZWZpbmUgQ1RYVF9VTFIJNTYKKyNkZWZpbmUgQ1RYVF9TU1AJNjAKKyNkZWZpbmUgQ1RYVF9T
TFIJNjQKKyNkZWZpbmUgQ1RYVF9QQwkJNjgKKyNkZWZpbmUgQ1RYVF9TUFNSCTcyCisjZGVm
aW5lIENUWFRfRVhUUkEJNzYKKyNkZWZpbmUgQ1RYVF9GUkFNRV9TSVpFCTgwCisKKyNkZWZp
bmUgU1BGSVgoY29kZS4uLikJY29kZQorCisubWFjcm8gIGRpc2FibGVfaXJxLCB0ZW1wCisJ
bXNyCWNwc3JfYywgI1BTUl9JX0JJVCB8IFBTUl9NT0RFX1NWQworLmVuZG0KKworLm1hY3Jv
CWNjaQlyZAorCW1vdglccmQsICNTVEFDS19TSVpFCisJc3ViCVxyZCwgXHJkLCAjMQorCWJp
YwlccmQsIHIxMywgXHJkCisuZW5kbQorCisvKgorICogU2F2ZSB0aGUgY3VycmVudCBJUlEg
c3RhdGUgYW5kIGRpc2FibGUgSVJRcy4gIE5vdGUgdGhhdCB0aGlzIG1hY3JvCisgKiBhc3N1
bWVzIEZJUXMgYXJlIGVuYWJsZWQsIGFuZCB0aGF0IHRoZSBwcm9jZXNzb3IgaXMgaW4gU1ZD
IG1vZGUuCisgKi8KKy5tYWNybwlzYXZlX2FuZF9kaXNhYmxlX2lycXMsIG9sZGNwc3IsIHRl
bXAKKwltcnMJXG9sZGNwc3IsIGNwc3IKKwltb3YJXHRlbXAsICNQU1JfSV9CSVQgfCBQU1Jf
TU9ERV9TVkMKKwltc3IJY3Bzcl9jLCBcdGVtcAorLmVuZG0KKworLyoKKyAqIFJlc3RvcmUg
aW50ZXJydXB0IHN0YXRlIHByZXZpb3VzbHkgc3RvcmVkIGluIGEgcmVnaXN0ZXIuICBXZSBk
b24ndAorICogZ3VhcmFudGVlIHRoYXQgdGhpcyB3aWxsIHByZXNlcnZlIHRoZSBmbGFncy4K
KyAqLworLm1hY3JvCXJlc3RvcmVfaXJxcywgb2xkY3BzcgorCW1zcgljcHNyX2MsIFxvbGRj
cHNyCisuZW5kbQorCisjZGVmaW5lIFVTRVIoeC4uLikJCQkJXAorOTk5OToJeDsJCQkJCVwK
Kwkuc2VjdGlvbiAuZXh0YWJsZSwiYSI7CQlcCisJLmFsaWduCTM7CQkJCVwKKwkubG9uZwk5
OTk5Yiw5MDAxZjsJCQlcCisJLnByZXZpb3VzCisKKyNkZWZpbmUgX19BTElHTiAgICAgICAg
IC5hbGlnbiAwCisjZGVmaW5lIF9fQUxJR05fU1RSICAgICAiLmFsaWduIDAsIDB4OTAiCisK
KyNkZWZpbmUgQUxJR04gICAgICAgICAgIF9fQUxJR04KKyNkZWZpbmUgQUxJR05fU1RSICAg
ICAgIF9fQUxJR05fU1RSCisKKyNkZWZpbmUgRU5UUlkobmFtZSkgXAorICAuZ2xvYmFsIG5h
bWU7IFwKKyAgQUxJR047IFwKKyAgbmFtZToKKyNlbmRpZgorI2VuZGlmIC8qIF9fQVJNX0FT
TV9NQUNST1NfSF9fICovCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1h
cm0vYXRvbWljLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9hdG9taWMuaAlGcmkgRmViIDAzIDE2OjA3
OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxNzkgQEAKKyNpZm5kZWYgX19BUk1fQVRPTUlD
X0hfXworI2RlZmluZSBfX0FSTV9BVE9NSUNfSF9fCisKKyNpZm5kZWYgX19BU1NFTUJMWV9f
CisjZGVmaW5lIHJlYWRfYXRvbWljKHApIAkJCQkJCQlcCisoewkJCQkJCQkJCVwKKwl0eXBl
b2YoKnApIF9feDsJCQkJCQkJXAorCXN3aXRjaCAoIHNpemVvZigqcCkgKSB7CQkJCQkJXAor
CWNhc2UgMTogX194ID0gKHR5cGVvZigqcCkpYXRvbWljX3JlYWQ4KCh1aW50OF90ICopcCk7
IGJyZWFrOwlcCisJY2FzZSAyOiBfX3ggPSAodHlwZW9mKCpwKSlhdG9taWNfcmVhZDE2KCh1
aW50MTZfdCAqKXApOyBicmVhazsJXAorCWNhc2UgNDogX194ID0gKHR5cGVvZigqcCkpYXRv
bWljX3JlYWQzMigodWludDMyX3QgKilwKTsgYnJlYWs7CVwKKwljYXNlIDg6IF9feCA9ICh0
eXBlb2YoKnApKWF0b21pY19yZWFkNjQoKHVpbnQ2NF90ICopcCk7IGJyZWFrOwlcCisJZGVm
YXVsdDogX194ID0gMDsgX19iYWRfYXRvbWljX3NpemUoKTsgYnJlYWs7CQkJXAorCX0JCQkJ
CQkJCVwKKwlfX3g7CQkJCQkJCQlcCit9KQorCisjZGVmaW5lIHdyaXRlX2F0b21pYyhwLCB4
KSAJCQkJCQlcCisoewkJCQkJCQkJCVwKKwl0eXBlb2YoKnApIF9feCA9ICh4KTsJCQkJCQlc
CisJc3dpdGNoICggc2l6ZW9mKCpwKSApIHsJCQkJCQlcCisJY2FzZSAxOiBhdG9taWNfd3Jp
dGU4KCh1aW50OF90ICopcCwgKHVpbnQ4X3QpX194KTsgYnJlYWs7CVwKKwljYXNlIDI6IGF0
b21pY193cml0ZTE2KCh1aW50MTZfdCAqKXAsICh1aW50MTZfdClfX3gpOyBicmVhazsJXAor
CWNhc2UgNDogYXRvbWljX3dyaXRlMzIoKHVpbnQzMl90ICopcCwgKHVpbnQzMl90KV9feCk7
IGJyZWFrOwlcCisJY2FzZSA4OiBhdG9taWNfd3JpdGU2NCgodWludDY0X3QgKilwLCAodWlu
dDY0X3QpX194KTsgYnJlYWs7CVwKKwlkZWZhdWx0OiBfX2JhZF9hdG9taWNfc2l6ZSgpOyBi
cmVhazsJCQkJXAorCX0JCQkJCQkJCVwKKwlfX3g7CQkJCQkJCQlcCit9KQorCisKK3N0YXRp
YyBpbmxpbmUgdWludDhfdCBhdG9taWNfcmVhZDgoY29uc3Qgdm9sYXRpbGUgdWludDhfdCAq
YWRkcikKK3sKKwlyZXR1cm4gKCphZGRyKTsKK30KKworCitzdGF0aWMgaW5saW5lIHVpbnQx
Nl90IGF0b21pY19yZWFkMTYoY29uc3Qgdm9sYXRpbGUgdWludDE2X3QgKmFkZHIpCit7CisJ
cmV0dXJuICgqYWRkcik7Cit9CisKK3N0YXRpYyBpbmxpbmUgdWludDMyX3QgYXRvbWljX3Jl
YWQzMihjb25zdCB2b2xhdGlsZSB1aW50MzJfdCAqYWRkcikKK3sKKwlyZXR1cm4gKCphZGRy
KTsKK30KKworc3RhdGljIGlubGluZSB2b2lkIGF0b21pY193cml0ZTgodm9sYXRpbGUgdWlu
dDhfdCAqYWRkciwgdWludDhfdCB2YWwpCit7CisJKCphZGRyKSA9IHZhbDsKK30KKworc3Rh
dGljIGlubGluZSB2b2lkIGF0b21pY193cml0ZTE2KHZvbGF0aWxlIHVpbnQxNl90ICphZGRy
LCB1aW50MTZfdCB2YWwpCit7CisJKCphZGRyKSA9IHZhbDsKK30KKworc3RhdGljIGlubGlu
ZSB2b2lkIGF0b21pY193cml0ZTMyKHZvbGF0aWxlIHVpbnQzMl90ICphZGRyLCB1aW50MzJf
dCB2YWwpCit7CisJKCphZGRyKSA9IHZhbDsKK30KKworCit0eXBlZGVmIHN0cnVjdCB7CisJ
dm9sYXRpbGUgaW50IGNvdW50ZXI7Cit9IGF0b21pY190OworCisKKyNkZWZpbmUgQVRPTUlD
X0lOSVQoaSkJCXsgKGkpIH0KKworI2RlZmluZSBhdG9taWNfcmVhZCh2KQkJKCh2KS0+Y291
bnRlcikKKworc3RhdGljIGlubGluZSB2b2lkIGF0b21pY19zZXQoYXRvbWljX3QgKnYsIGlu
dCBpKQoreworCXVuc2lnbmVkIGxvbmcgdG1wOworCisJX19hc21fXyBfX3ZvbGF0aWxlX18o
IkAgYXRvbWljX3NldFxuIgorIjE6ICAgICBsZHJleCAgICUwLCBbJTFdXG4iCisiICAgICAg
IHN0cmV4ICAgJTAsICUyLCBbJTFdXG4iCisiICAgICAgIHRlcSAgICAgJTAsICMwXG4iCisi
ICAgICAgIGJuZSAgICAgMWIiCisJOiAiPSZyIiAodG1wKQorCTogInIiICgmdi0+Y291bnRl
ciksICJyIiAoaSkKKwk6ICJjYyIpOworfQorCitzdGF0aWMgaW5saW5lIGludCBhdG9taWNf
YWRkX3JldHVybihpbnQgaSwgYXRvbWljX3QgKnYpCit7CisJdW5zaWduZWQgbG9uZyB0bXA7
CisJaW50IHJlc3VsdDsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKCJAIGF0b21pY19hZGRf
cmV0dXJuXG4iCisiMTogICAgIGxkcmV4ICAgJTAsIFslMl1cbiIKKyIgICAgICAgYWRkICAg
ICAlMCwgJTAsICUzXG4iCisiICAgICAgIHN0cmV4ICAgJTEsICUwLCBbJTJdXG4iCisiICAg
ICAgIHRlcSAgICAgJTEsICMwXG4iCisiICAgICAgIGJuZSAgICAgMWIiCisJOiAiPSZyIiAo
cmVzdWx0KSwgIj0mciIgKHRtcCkKKwk6ICJyIiAoJnYtPmNvdW50ZXIpLCAiSXIiIChpKQor
CTogImNjIik7CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW5saW5lIGludCBh
dG9taWNfc3ViX3JldHVybihpbnQgaSwgYXRvbWljX3QgKnYpCit7CisJdW5zaWduZWQgbG9u
ZyB0bXA7CisJaW50IHJlc3VsdDsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKCJAIGF0b21p
Y19zdWJfcmV0dXJuXG4iCisiMTogICAgIGxkcmV4ICAgJTAsIFslMl1cbiIKKyIgICAgICAg
c3ViICAgICAlMCwgJTAsICUzXG4iCisiICAgICAgIHN0cmV4ICAgJTEsICUwLCBbJTJdXG4i
CisiICAgICAgIHRlcSAgICAgJTEsICMwXG4iCisiICAgICAgIGJuZSAgICAgMWIiCisJOiAi
PSZyIiAocmVzdWx0KSwgIj0mciIgKHRtcCkKKwk6ICJyIiAoJnYtPmNvdW50ZXIpLCAiSXIi
IChpKQorCTogImNjIik7CisKKwlyZXR1cm4gcmVzdWx0OworfQorCisKK3N0YXRpYyBpbmxp
bmUgdm9pZCBhdG9taWNfY2xlYXJfbWFzayh1bnNpZ25lZCBsb25nIG1hc2ssIHVuc2lnbmVk
IGxvbmcgKmFkZHIpCit7CisJdW5zaWduZWQgbG9uZyB0bXAsIHRtcDI7CisKKwlfX2FzbV9f
IF9fdm9sYXRpbGVfXygiQCBhdG9taWNfY2xlYXJfbWFza1xuIgorIjE6ICAgICBsZHJleCAg
ICUwLCBbJTJdXG4iCisiICAgICAgIGJpYyAgICAgJTAsICUwLCAlM1xuIgorIiAgICAgICBz
dHJleCAgICUxLCAlMCwgWyUyXVxuIgorIiAgICAgICB0ZXEgICAgICUxLCAjMFxuIgorIiAg
ICAgICBibmUgICAgIDFiIgorCTogIj0mciIgKHRtcCksICI9JnIiICh0bXAyKQorCTogInIi
IChhZGRyKSwgIklyIiAobWFzaykKKwk6ICJjYyIpOworfQorCitzdGF0aWMgaW5saW5lIGF0
b21pY190IGF0b21pY19jbXB4Y2hnKGF0b21pY190ICpwdHIsIGF0b21pY190IG9sZCwgYXRv
bWljX3QgbmV3KQoreworCWF0b21pY190IG9sZHZhbCwgcmVzOworCisJZG8geworCQlfX2Fz
bV9fIF9fdm9sYXRpbGVfXygiQCBhdG9taWNfY21weGNoZ1xuIgorCQkibGRyZXggICUxLCBb
JTJdXG4iCisJCSJtb3YgICAgJTAsICMwXG4iCisJCSJ0ZXEgICAgJTEsICUzXG4iCisJCSJz
dHJleGVxICUwLCAlNCwgWyUyXVxuIgorCQk6ICI9JnIiIChyZXMuY291bnRlciksICI9JnIi
IChvbGR2YWwuY291bnRlcikKKwkJOiAiciIgKCZwdHItPmNvdW50ZXIpLCAiSXIiIChvbGQu
Y291bnRlciksICJyIiAobmV3LmNvdW50ZXIpCisJCTogImNjIik7CisJfSB3aGlsZSAocmVz
LmNvdW50ZXIpOworCisJcmV0dXJuIG9sZHZhbDsKK30KKworI2RlZmluZSBfYXRvbWljX3Jl
YWQodikJCWF0b21pY19yZWFkKCZ2KQorI2RlZmluZSBfYXRvbWljX3NldCh2LGkpCWF0b21p
Y19zZXQoJnYsaSkKKworI2RlZmluZSBhdG9taWNfYWRkKGksIHYpCSh2b2lkKSBhdG9taWNf
YWRkX3JldHVybihpLCB2KQorI2RlZmluZSBhdG9taWNfaW5jKHYpCQkodm9pZCkgYXRvbWlj
X2FkZF9yZXR1cm4oMSwgdikKKyNkZWZpbmUgYXRvbWljX3N1YihpLCB2KQkodm9pZCkgYXRv
bWljX3N1Yl9yZXR1cm4oaSwgdikKKyNkZWZpbmUgYXRvbWljX2RlYyh2KQkJKHZvaWQpIGF0
b21pY19zdWJfcmV0dXJuKDEsIHYpCisKKyNkZWZpbmUgYXRvbWljX2luY19hbmRfdGVzdCh2
KQkoYXRvbWljX2FkZF9yZXR1cm4oMSwgdikgPT0gMCkKKyNkZWZpbmUgYXRvbWljX2RlY19h
bmRfdGVzdCh2KQkoYXRvbWljX3N1Yl9yZXR1cm4oMSwgdikgPT0gMCkKKyNkZWZpbmUgYXRv
bWljX2luY19yZXR1cm4odikgICAgKGF0b21pY19hZGRfcmV0dXJuKDEsIHYpKQorI2RlZmlu
ZSBhdG9taWNfZGVjX3JldHVybih2KSAgICAoYXRvbWljX3N1Yl9yZXR1cm4oMSwgdikpCisK
KyNkZWZpbmUgYXRvbWljX2FkZF9uZWdhdGl2ZShpLHYpIChhdG9taWNfYWRkX3JldHVybihp
LCB2KSA8IDApCisKK3N0YXRpYyBpbmxpbmUgYXRvbWljX3QgYXRvbWljX2NvbXBhcmVhbmRz
d2FwKGF0b21pY190IG9sZCwgYXRvbWljX3QgbmV3LCBhdG9taWNfdCAqdikKK3sKKyAgICAg
ICAgYXRvbWljX3QgcmM7CisgICAgICAgIHJjID0gYXRvbWljX2NtcHhjaGcoIChhdG9taWNf
dCAqKXYsIG9sZCwgbmV3KTsKKyAgICAgICAgcmV0dXJuIHJjOworfQorI2VuZGlmIC8qIV9f
QVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIV9fQVJNX0FUT01JQ19IX18gKi8KZGlmZiAtciBl
NzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9iaXRvcHMuaAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
YXJtL2JpdG9wcy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsx
LDE5MyBAQAorI2lmbmRlZiBfX0FSTV9CSVRPUFNfSF9fCisjZGVmaW5lIF9fQVJNX0JJVE9Q
U19IX18KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vc3lzdGVt
Lmg+CisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCitzdGF0aWMgaW5saW5lIHZvaWQgYXRvbWlj
X3NldF9iaXQodW5zaWduZWQgaW50IGJpdCwgdm9sYXRpbGUgdW5zaWduZWQgbG9uZyAqcCkK
K3sKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCXVuc2lnbmVkIGxvbmcgbWFzayA9IDFVTCA8
PCAoYml0ICYgMzEpOworCisJcCArPSBiaXQgPj4gNTsKKworCWxvY2FsX2lycV9zYXZlKGZs
YWdzKTsKKwkqcCB8PSBtYXNrOworCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKK30KKwor
c3RhdGljIGlubGluZSB2b2lkIGF0b21pY19jbGVhcl9iaXQodW5zaWduZWQgaW50IGJpdCwg
dm9sYXRpbGUgdW5zaWduZWQgbG9uZyAqcCkKK3sKKwl1bnNpZ25lZCBsb25nIGZsYWdzOwor
CXVuc2lnbmVkIGxvbmcgbWFzayA9IDFVTCA8PCAoYml0ICYgMzEpOworCisJcCArPSBiaXQg
Pj4gNTsKKworCWxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKwkqcCAmPSB+bWFzazsKKwlsb2Nh
bF9pcnFfcmVzdG9yZShmbGFncyk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBhdG9taWNf
Y2hhbmdlX2JpdCh1bnNpZ25lZCBpbnQgYml0LCB2b2xhdGlsZSB1bnNpZ25lZCBsb25nICpw
KQoreworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisJdW5zaWduZWQgbG9uZyBtYXNrID0gMVVM
IDw8IChiaXQgJiAzMSk7CisKKwlwICs9IGJpdCA+PiA1OworCisJbG9jYWxfaXJxX3NhdmUo
ZmxhZ3MpOworCSpwIF49IG1hc2s7CisJbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOworfQor
CitzdGF0aWMgaW5saW5lIGludCBhdG9taWNfdGVzdF9hbmRfc2V0X2JpdCh1bnNpZ25lZCBp
bnQgYml0LCB2b2xhdGlsZSB1bnNpZ25lZCBsb25nICpwKQoreworCXVuc2lnbmVkIGxvbmcg
ZmxhZ3M7CisJdW5zaWduZWQgaW50IHJlczsKKwl1bnNpZ25lZCBsb25nIG1hc2sgPSAxVUwg
PDwgKGJpdCAmIDMxKTsKKworCXAgKz0gYml0ID4+IDU7CisKKwlsb2NhbF9pcnFfc2F2ZShm
bGFncyk7CisJcmVzID0gKnA7CisJKnAgPSByZXMgfCBtYXNrOworCWxvY2FsX2lycV9yZXN0
b3JlKGZsYWdzKTsKKworCXJldHVybiByZXMgJiBtYXNrOworfQorCitzdGF0aWMgaW5saW5l
IGludCBhdG9taWNfdGVzdF9hbmRfY2xlYXJfYml0KHVuc2lnbmVkIGludCBiaXQsIHZvbGF0
aWxlIHVuc2lnbmVkIGxvbmcgKnApCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwl1bnNp
Z25lZCBpbnQgcmVzOworCXVuc2lnbmVkIGxvbmcgbWFzayA9IDFVTCA8PCAoYml0ICYgMzEp
OworCisJcCArPSBiaXQgPj4gNTsKKworCWxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKwlyZXMg
PSAqcDsKKwkqcCA9IHJlcyAmIH5tYXNrOworCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsK
KworCXJldHVybiByZXMgJiBtYXNrOworfQorCitzdGF0aWMgaW5saW5lIGludCBhdG9taWNf
dGVzdF9hbmRfY2hhbmdlX2JpdCh1bnNpZ25lZCBpbnQgYml0LCB2b2xhdGlsZSB1bnNpZ25l
ZCBsb25nICpwKQoreworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisJdW5zaWduZWQgaW50IHJl
czsKKwl1bnNpZ25lZCBsb25nIG1hc2sgPSAxVUwgPDwgKGJpdCAmIDMxKTsKKworCXAgKz0g
Yml0ID4+IDU7CisKKwlsb2NhbF9pcnFfc2F2ZShmbGFncyk7CisJcmVzID0gKnA7CisJKnAg
PSByZXMgXiBtYXNrOworCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKKworCXJldHVybiBy
ZXMgJiBtYXNrOworfQorCisvKgorICogTm93IHRoZSBub24tYXRvbWljIHZhcmlhbnRzLiAg
V2UgbGV0IHRoZSBjb21waWxlciBoYW5kbGUgYWxsCisgKiBvcHRpbWlzYXRpb25zIGZvciB0
aGVzZS4gIFRoZXNlIGFyZSBhbGwgX25hdGl2ZV8gZW5kaWFuLgorICovCitzdGF0aWMgaW5s
aW5lIHZvaWQgc2V0X2JpdChpbnQgbnIsIHZvbGF0aWxlIHZvaWQgKnApCit7CisJdm9sYXRp
bGUgdW5zaWduZWQgbG9uZyAqbSA9ICh1bnNpZ25lZCBsb25nICopcDsKKworCW1bbnIgPj4g
NV0gfD0gKDFVTCA8PCAobnIgJiAzMSkpOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgY2xl
YXJfYml0KGludCBuciwgdm9sYXRpbGUgdm9pZCAqcCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25l
ZCBsb25nICptID0gKHVuc2lnbmVkIGxvbmcgKilwOworCisJbVtuciA+PiA1XSAmPSB+KDFV
TCA8PCAobnIgJiAzMSkpOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgY2hhbmdlX2JpdChp
bnQgbnIsIHZvbGF0aWxlIHZvaWQgKnApCit7CisJdm9sYXRpbGUgdW5zaWduZWQgbG9uZyAq
bSA9ICh1bnNpZ25lZCBsb25nICopcDsKKworCW1bbnIgPj4gNV0gXj0gKDFVTCA8PCAobnIg
JiAzMSkpOworfQorCitzdGF0aWMgaW5saW5lIGludCB0ZXN0X2FuZF9zZXRfYml0KGludCBu
ciwgdm9sYXRpbGUgdm9pZCAqcCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25lZCBsb25nICptID0g
KHVuc2lnbmVkIGxvbmcgKilwOworCXVuc2lnbmVkIGxvbmcgb2xkdmFsLCBtYXNrID0gMVVM
IDw8IChuciAmIDMxKTsKKworCW0gKz0gbnIgPj4gNTsKKworCW9sZHZhbCA9ICptOworCSpt
ID0gb2xkdmFsIHwgbWFzazsKKwlyZXR1cm4gb2xkdmFsICYgbWFzazsKK30KKworc3RhdGlj
IGlubGluZSBpbnQgdGVzdF9hbmRfY2xlYXJfYml0KGludCBuciwgdm9sYXRpbGUgdm9pZCAq
cCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25lZCBsb25nICptID0gKHVuc2lnbmVkIGxvbmcgKilw
OworCXVuc2lnbmVkIGxvbmcgb2xkdmFsLCBtYXNrID0gMVVMIDw8IChuciAmIDMxKTsKKwor
CW0gKz0gbnIgPj4gNTsKKworCW9sZHZhbCA9ICptOworCSptID0gb2xkdmFsICYgfm1hc2s7
CisJcmV0dXJuIG9sZHZhbCAmIG1hc2s7Cit9CisKK3N0YXRpYyBpbmxpbmUgaW50IHRlc3Rf
YW5kX2NoYW5nZV9iaXQoaW50IG5yLCB2b2xhdGlsZSB2b2lkICpwKQoreworCXZvbGF0aWxl
IHVuc2lnbmVkIGxvbmcgKm0gPSAodW5zaWduZWQgbG9uZyAqKXA7CisJdW5zaWduZWQgbG9u
ZyBvbGR2YWwsIG1hc2sgPSAxVUwgPDwgKG5yICYgMzEpOworCisJbSArPSBuciA+PiA1Owor
CisJb2xkdmFsID0gKm07CisJKm0gPSBvbGR2YWwgXiBtYXNrOworCXJldHVybiBvbGR2YWwg
JiBtYXNrOworfQorCisvKgorICogVGhpcyByb3V0aW5lIGRvZXNuJ3QgbmVlZCB0byBiZSBh
dG9taWMuCisgKi8KK3N0YXRpYyBpbmxpbmUgaW50IHRlc3RfYml0KGludCBuciwgY29uc3Qg
dm9sYXRpbGUgdm9pZCAqcCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25lZCBsb25nICptID0gKHVu
c2lnbmVkIGxvbmcgKilwOworCisJcmV0dXJuIChtW25yID4+IDVdID4+IChuciAmIDMxKSkg
JiAxVUw7Cit9CisKK2V4dGVybiBpbnQgX2ZpbmRfZmlyc3RfemVyb19iaXQoY29uc3Qgdm9p
ZCAqcCwgaW50IHN6KTsKK2V4dGVybiBpbnQgX2ZpbmRfbmV4dF96ZXJvX2JpdChjb25zdCB2
b2lkICpwLCBpbnQgc3osIGludCBvZmZzZXQpOworZXh0ZXJuIGludCBfZmluZF9maXJzdF9i
aXQoY29uc3Qgdm9pZCAqcCwgaW50IHN6KTsKK2V4dGVybiBpbnQgX2ZpbmRfbmV4dF9iaXQo
Y29uc3Qgdm9pZCAqcCwgaW50IHN6LCBpbnQgb2Zmc2V0KTsKKworI2RlZmluZSBmaW5kX2Zp
cnN0X3plcm9fYml0KHAsc3opCV9maW5kX2ZpcnN0X3plcm9fYml0KHAsc3opCisjZGVmaW5l
IGZpbmRfbmV4dF96ZXJvX2JpdChwLHN6LG9mZikJX2ZpbmRfbmV4dF96ZXJvX2JpdChwLHN6
LG9mZikKKyNkZWZpbmUgZmluZF9maXJzdF9iaXQocCxzeikJCV9maW5kX2ZpcnN0X2JpdChw
LHN6KQorI2RlZmluZSBmaW5kX25leHRfYml0KHAsc3osb2ZmKQkJX2ZpbmRfbmV4dF9iaXQo
cCxzeixvZmYpCisjZGVmaW5lIGZpbmRfZmlyc3Rfc2V0X2JpdCh3b3JkKQkoZmZzKHdvcmQp
LTEpCisjZGVmaW5lIFdPUkRfQklUT0ZGX1RPX0xFKHgpCQkoKHgpKQorCisjZGVmaW5lIF9f
dGVzdF9hbmRfc2V0X2JpdChuciwgYWRkcikJdGVzdF9hbmRfc2V0X2JpdChuciwgYWRkcikK
Kworc3RhdGljIF9faW5saW5lX18gaW50IGdlbmVyaWNfZmxzKGludCB4KTsKKyNkZWZpbmUg
ZmxzKHgpIFwKKwkoIF9fYnVpbHRpbl9jb25zdGFudF9wKHgpID8gZ2VuZXJpY19mbHMoeCkg
OiBcCisJICAoeyBpbnQgX19yOyBhc20oImNselx0JTAsICUxIiA6ICI9ciIoX19yKSA6ICJy
Iih4KSA6ICJjYyIpOyAzMi1fX3I7IH0pICkKKyNkZWZpbmUgZmZzKHgpCQkoeyB1bnNpZ25l
ZCBsb25nIF9fdCA9ICh4KTsgZmxzKF9fdCAmIC1fX3QpOyB9KQorI2RlZmluZSBfX2Zmcyh4
KQkoZmZzKHgpIC0gMSkKKyNkZWZpbmUgZmZ6KHgpCQlfX2Zmcyggfih4KSApCisvKgorICog
aHdlaWdodE46IHJldHVybnMgdGhlIGhhbW1pbmcgd2VpZ2h0IChpLmUuIHRoZSBudW1iZXIK
KyAqIG9mIGJpdHMgc2V0KSBvZiBhIE4tYml0IHdvcmQKKyAqLworCisjZGVmaW5lIGh3ZWln
aHQzMih4KSBnZW5lcmljX2h3ZWlnaHQzMih4KQorI2RlZmluZSBod2VpZ2h0MTYoeCkgZ2Vu
ZXJpY19od2VpZ2h0MTYoeCkKKyNkZWZpbmUgaHdlaWdodDgoeCkgZ2VuZXJpY19od2VpZ2h0
OCh4KQorI2VuZGlmIC8qIV9fQVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIV9fQVJNX0JJVE9Q
U19IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9idWcu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL2J1Zy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDMyIEBACisjaWZuZGVmIF9fQVJNX0JVR19IX18KKyNkZWZpbmUgX19B
Uk1fQlVHX0hfXworCisjaWZuZGVmIF9fQVNTRU1CTFlfXworI2RlZmluZSBCVUcoKQkJCQkJ
CQlcCisJZG8gewkJCQkJCQlcCisJCXByaW50aygiQlVHIGF0ICVzOiVkXG4iLCBfX0ZJTEVf
XywgX19MSU5FX18pOwlcCisJCXdoaWxlKDEpOwkJCQkJXAorCX0gd2hpbGUgKCAwICkKKwor
I2RlZmluZSBQQU5JQyhtc2cpCQkJCQkJXAorCWRvIHsJCQkJCQkJXAorCQlwcmludGsoIlBh
bmljIGF0ICVzOiVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18pOyBcCisJCXdoaWxlKDEpOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKwl9d2hpbGUgKDApCisKKyNkZWZp
bmUgV0FSTigpCQkJCQkJCVwKKwlkbyB7CQkJCQkJCVwKKwkJcHJpbnRrKCJXQVJOSU5HIGF0
ICVzOiVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18pOwlcCisJCXdoaWxlKDEpOwkJCQkJXAor
CX0gd2hpbGUgKCAwICkKKworCisjZGVmaW5lIE5PVF9ZRVQoKQkJCQkJCVwKKwlkbyB7CQkJ
CQkJCVwKKwkJcHJpbnRrKCJOT1QgWUVUICVzOiVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18p
OwlcCisJfSB3aGlsZSAoMCkKKwordm9pZCBkdW1wX2V4ZWN1dGlvbl9zdGF0ZSh2b2lkKTsK
KyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLworI2VuZGlmIC8qIV9fQVJNX0JVR19IX18qLwor
CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vYnl0ZW9yZGVyLmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9ieXRlb3JkZXIuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSw5IEBACisjaWZuZGVmIF9fQVJNX0JZVEVPUkRFUl9IX18KKyNk
ZWZpbmUgX19BUk1fQllURU9SREVSX0hfXworCisjZGVmaW5lIF9fQllURU9SREVSX0hBU19V
NjRfXworCisjaW5jbHVkZSA8eGVuL2J5dGVvcmRlci9saXR0bGVfZW5kaWFuLmg+CisKKwor
I2VuZGlmIC8qIF9fQVJNX0JZVEVPUkRFUl9IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEg
eGVuL2luY2x1ZGUvYXNtLWFybS9jYWNoZS5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vY2FjaGUuaAlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMSBAQAorI2lmbmRl
ZiBfX0FSTV9DQUNIRV9IX18KKyNkZWZpbmUgX19BUk1fQ0FDSEVfSF9fCisKKyNpZm5kZWYg
TDFfQ0FDSEVfQllURVMKKyNkZWZpbmUgTDFfQ0FDSEVfQllURVMgICAgICAgICAgMzIKKyNl
bmRpZgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworI2RlZmluZSBfX3JlYWRfbW9zdGx5IF9f
YXR0cmlidXRlX18oKF9fc2VjdGlvbl9fKCIuZGF0YS5yZWFkX21vc3RseSIpKSkKKyNlbmRp
ZiAvKiFfX0FTU0VNQkxZX18gKi8KKyNlbmRpZiAvKiFfX0FSTV9DQUNIRV9IX18gKi8KZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9jb25maWcuaAotLS0gL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVk
ZS9hc20tYXJtL2NvbmZpZy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAt
MCwwICsxLDYxIEBACisjaWZuZGVmIF9fQVJNX0NPTkZJR19IX18KKyNkZWZpbmUgX19BUk1f
Q09ORklHX0hfXworCisjaW5jbHVkZSA8YXNtL2FyY2gvY29uZmlnLmg+CisKKyNpZm5kZWYg
TUFYX0hWTV9WQ1BVUworI2RlZmluZSBNQVhfSFZNX1ZDUFVTCQkxCisjZW5kaWYKKworI2Rl
ZmluZSBNQVhfVklSVF9DUFVTCQlYRU5fTEVHQUNZX01BWF9WQ1BVUworI2RlZmluZSBDT01Q
QVRfTEVHQUNZX01BWF9WQ1BVUyBYRU5fTEVHQUNZX01BWF9WQ1BVUworCisjaWZuZGVmIE1B
WF9QSFlTX0NQVVMKKyNkZWZpbmUgTUFYX1BIWVNfQ1BVUwkJMQorI2VuZGlmCisKKyNkZWZp
bmUgTlJfQ1BVUwkJCU1BWF9QSFlTX0NQVVMKKworI2RlZmluZSBFTEZTSVpFCQkJMzIKKwor
I2lmbmRlZiBYRU5fUEhZU19TSVpFCisjZGVmaW5lIFhFTl9QSFlTX1NJWkUJCSgweEYwMDAw
MCkKKyNlbmRpZgorCisKKyNpZiAoTUFYX1BIWVNfQ1BVUyA+IDEpCisjZGVmaW5lIENPTkZJ
R19TTVAJCTEKKyNkZWZpbmUgU01QCQkJMQorI2VuZGlmCisKKyNkZWZpbmUgU1RBQ0tfT1JE
RVIJCTAKKyNkZWZpbmUgU1RBQ0tfU0laRQkJKFBBR0VfU0laRSA8PCBTVEFDS19PUkRFUikK
KworI2lmbmRlZiBOREVCVUcKKyMgZGVmaW5lIE1FTU9SWV9HVUFSRAorI2VuZGlmCisKKwor
I2RlZmluZSBzdXBlcnZpc29yX21vZGVfa2VybmVsCSgwKQorCisjZGVmaW5lIEhZUEVSVklT
T1JfVklSVF9TVEFSVAkoMHhGQzAwMDAwMCkKKyNkZWZpbmUgWEVOX1ZJUlRfU1RBUlQJCSgw
eEZGMDAwMDAwKQorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworCisjZGVmaW5lIE9QVF9DT05T
T0xFX1NUUgkJImNvbTEiCisKKyNpZmRlZiBfX2NwbHVzcGx1cworI2RlZmluZSBDUFBfQVNN
TElOS0FHRSBleHRlcm4gIkMiCisjZWxzZQorI2RlZmluZSBDUFBfQVNNTElOS0FHRQorI2Vu
ZGlmCisKKyNpZm5kZWYgYXNtbGlua2FnZQorI2RlZmluZSBhc21saW5rYWdlIENQUF9BU01M
SU5LQUdFCisjZW5kaWYKKyNlbmRpZiAvKiAhX19BU1NFTUJMWV9fICovCisjZW5kaWYgLyog
IV9fQVJNX0NPTkZJR19IX18qLworCisKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5j
bHVkZS9hc20tYXJtL2NwdS1kb21haW4uaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2NwdS1kb21haW4u
aAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwzOSBAQAorI2lm
bmRlZiBfX0FSTV9DUFVfRE9NQUlOX0hfXworI2RlZmluZSBfX0FSTV9DUFVfRE9NQUlOX0hf
XworCisvKgorICogRG9tYWluIElECisgKi8KKyNkZWZpbmUgRE9NQUlOX1NWQwkJMAorI2Rl
ZmluZSBET01BSU5fSU8JCTIKKyNkZWZpbmUgRE9NQUlOX1VTUgkJMQorI2RlZmluZSBET01B
SU5fSFlQCQkxNQorCisvKgorICogRG9tYWluIHR5cGVzCisgKi8KKyNkZWZpbmUgRE9NQUlO
X05PQUNDRVNTCQkwCisjZGVmaW5lIERPTUFJTl9DTElFTlQJCTEKKyNkZWZpbmUgRE9NQUlO
X01BTkFHRVIJCTMKKworI2RlZmluZSBET01BSU5fVkFMVUUoZG9tLHR5cGUpCSgodHlwZSkg
PDwgKDIgKiAoZG9tKSkpCisKKyNkZWZpbmUgREFDUl9TVEFUX0hZUAkJCQkJXAorCShET01B
SU5fVkFMVUUoRE9NQUlOX0hZUCwgRE9NQUlOX0NMSUVOVCkgfAlcCisJIERPTUFJTl9WQUxV
RShET01BSU5fU1ZDLCBET01BSU5fQ0xJRU5UKSB8CVwKKwkgRE9NQUlOX1ZBTFVFKERPTUFJ
Tl9JTywgIERPTUFJTl9DTElFTlQpIHwJXAorCSBET01BSU5fVkFMVUUoRE9NQUlOX1VTUiwg
RE9NQUlOX0NMSUVOVCkpCisKKyNkZWZpbmUgREFDUl9TVEFUX1NWQwkJCQkJXAorCShET01B
SU5fVkFMVUUoRE9NQUlOX0hZUCwgRE9NQUlOX0NMSUVOVCkgfAlcCisJIERPTUFJTl9WQUxV
RShET01BSU5fU1ZDLCBET01BSU5fTUFOQUdFUikgfAlcCisJIERPTUFJTl9WQUxVRShET01B
SU5fSU8sICBET01BSU5fTUFOQUdFUikgfAlcCisJIERPTUFJTl9WQUxVRShET01BSU5fVVNS
LCBET01BSU5fQ0xJRU5UKSkJXAorCisjZGVmaW5lIERBQ1JfU1RBVF9VU1IJCQkJCVwKKwko
RE9NQUlOX1ZBTFVFKERPTUFJTl9IWVAsIERPTUFJTl9DTElFTlQpIHwJXAorCSBET01BSU5f
VkFMVUUoRE9NQUlOX1NWQywgRE9NQUlOX0NMSUVOVCkgfAlcCisJIERPTUFJTl9WQUxVRShE
T01BSU5fSU8sICBET01BSU5fQ0xJRU5UKSB8CVwKKwkgRE9NQUlOX1ZBTFVFKERPTUFJTl9V
U1IsIERPTUFJTl9DTElFTlQpKQorCisjZW5kaWYgLyogX19BUk1fQ1BVX0RPTUFJTl9IX18g
Ki8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsNzMgQEAKKy8qCisgKiAgY3VycmVudC5oCisgKgorICogQ29weXJp
Z2h0IChDKSAyMDA4IFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqCUNoYW5KdSBQYXJrIDxiZWFz
dHdvcmxkQHNhbXN1bmcuY29tPgorICoJSmFlTWluIFJ5dSAgPGptNzcucnl1QHNhbXN1bmcu
Y29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNo
ZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2Vm
dWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1w
bGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2
ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcg
d2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUK
KyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0
b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworI2lmbmRlZiBfX0FSTV9DVVJSRU5UX0hf
XworI2RlZmluZSBfX0FSTV9DVVJSRU5UX0hfXworCisjaW5jbHVkZSA8cHVibGljL3hlbi5o
PgorI2luY2x1ZGUgPGFzbS9wYWdlLmg+CisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCitzdHJ1
Y3QgdmNwdTsKKworc3RydWN0IGNwdV9pbmZvIHsKKwlzdHJ1Y3QgdmNwdQkqdmNwdTsKKwl1
bnNpZ25lZCBsb25nCXZzcHNyOworCXVuc2lnbmVkIGxvbmcJdnNwOworCXVuc2lnbmVkIGxv
bmcJdmxyOworCXVuc2lnbmVkIGxvbmcJdmRhY3I7CisJc3RydWN0IGNwdV91c2VyX3JlZ3Mg
Z3Vlc3RfY3B1X3VzZXJfcmVnczsKK307CisKK3N0YXRpYyBpbmxpbmUgc3RydWN0IGNwdV9p
bmZvICogZ2V0X2NwdV9pbmZvKHZvaWQpCit7CisJcmVnaXN0ZXIgdW5zaWduZWQgbG9uZyBz
cCBhc20oInIxMyIpOworCXJldHVybiAoc3RydWN0IGNwdV9pbmZvICopICggc3AgJiB+KFNU
QUNLX1NJWkUgLTEpICApOyAKK30KKworc3RhdGljIGlubGluZSBzdHJ1Y3QgdmNwdSAqZ2V0
X2N1cnJlbnQodm9pZCkKK3sKKyAgICAgICAgcmV0dXJuIGdldF9jcHVfaW5mbygpLT52Y3B1
OworfQorCisjZGVmaW5lIGN1cnJlbnQgZ2V0X2N1cnJlbnQoKQorCitzdGF0aWMgaW5saW5l
IHZvaWQgc2V0X2N1cnJlbnQoc3RydWN0IHZjcHUgKnYpCit7ICAgCisJZ2V0X2NwdV9pbmZv
KCktPnZjcHUgPSB2OworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgc2V0X2N1cnJlbnRfdmNw
dShzdHJ1Y3QgdmNwdSAqdikKK3sKKyAgICAgICAgc3RydWN0IGNwdV9pbmZvICpjaTsKKwor
ICAgICAgICBjaSA9IGdldF9jcHVfaW5mbygpOworICAgICAgICBjaS0+dmNwdSA9IHY7Cit9
CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBjcHVfaW5mb19pbml0KHN0cnVjdCBjcHVfaW5mbyAq
Y3B1X2luZm8pCit7CisgICAgICAgIGNwdV9pbmZvLT52Y3B1ID0gTlVMTDsKK30KKworI2Rl
ZmluZSBndWVzdF9jcHVfdXNlcl9yZWdzKCkJKCYoZ2V0X2NwdV9pbmZvKCktPmd1ZXN0X2Nw
dV91c2VyX3JlZ3MpKQorI2VuZGlmCisKKyNlbmRpZiAvKiBfX0FSTV9DVVJSRU5UX0hfXyAq
LwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2RlYnVnZ2VyLmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9kZWJ1Z2dlci5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiAr
MDkwMApAQCAtMCwwICsxLDI0IEBACisjaWZuZGVmIF9fQVJNX0RFQlVHR0VSX0hfXworI2Rl
ZmluZSBfX0FSTV9ERUJVR0dFUl9IX18KKworI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorCisj
aWZuZGVmIF9fQVNTRU1CTFlfXworI2RlZmluZSBkZWJ1Z2dlcl90cmFwX2ltbWVkaWF0ZSgp
CXs7fQorCitzdGF0aWMgaW5saW5lIGludCBkZWJ1Z2dlcl90cmFwX2ZhdGFsKHVuc2lnbmVk
IGludCB2ZWN0b3IsIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQoreworCXByaW50aygi
Tm90IGltcGxlbWVudGVkIHlldFxuIik7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKworCit2
b2lkIHNob3dfc3RhY2soc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpOwordm9pZCBzaG93
X3N0YWNrX292ZXJmbG93KHVuc2lnbmVkIGludCBjcHUsIHVuc2lnbmVkIGxvbmcgZXNwKTsK
K3ZvaWQgc2hvd19yZWdpc3RlcnMoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpOwordm9p
ZCBzaG93X2V4ZWN1dGlvbl9zdGF0ZShzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncyk7Cisj
ZW5kaWYgLyohX19BU1NFTUJMWV9fKi8KKworI2VuZGlmIC8qIV9fQVJNX0RFQlVHR0VSX0hf
XyAqLworCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vZGVsYXku
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL2RlbGF5LmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsNiBAQAorI2lmbmRlZiBfX0FSTV9ERUxBWV9IX18KKyNkZWZpbmUg
X19BUk1fREVMQVlfSF9fCisKKyNkZWZpbmUgdWRlbGF5KG4pIAlfdWRlbGF5KG4pCisjZW5k
aWYKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2RpdjY0LmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9kaXY2NC5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDQzIEBACisjaWZuZGVmIF9fQVJNX0RJVjY0X18KKyNkZWZpbmUgX19B
Uk1fRElWNjRfXworCisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgorCisjaWZuZGVmIF9fQVNT
RU1CTFlfXworLyoKKyAqIFRoZSBzZW1hbnRpY3Mgb2YgZG9fZGl2KCkgYXJlOgorICoKKyAq
IHVpbnQzMl90IGRvX2Rpdih1aW50NjRfdCAqbiwgdWludDMyX3QgYmFzZSkKKyAqIHsKKyAq
IAl1aW50MzJfdCByZW1haW5kZXIgPSAqbiAlIGJhc2U7CisgKiAJKm4gPSAqbiAvIGJhc2U7
CisgKiAJcmV0dXJuIHJlbWFpbmRlcjsKKyAqIH0KKyAqCisgKiBJbiBvdGhlciB3b3Jkcywg
YSA2NC1iaXQgZGl2aWRlbmQgd2l0aCBhIDMyLWJpdCBkaXZpc29yIHByb2R1Y2luZworICog
YSA2NC1iaXQgcmVzdWx0IGFuZCBhIDMyLWJpdCByZW1haW5kZXIuICBUbyBhY2NvbXBsaXNo
IHRoaXMgb3B0aW1hbGx5CisgKiB3ZSBjYWxsIGEgc3BlY2lhbCBfX2RvX2RpdjY0IGhlbHBl
ciB3aXRoIGNvbXBsZXRlbHkgbm9uIHN0YW5kYXJkCisgKiBjYWxsaW5nIGNvbnZlbnRpb24g
Zm9yIGFyZ3VtZW50cyBhbmQgcmVzdWx0cyAoYmV3YXJlKS4KKyAqLworI2RlZmluZSBfX3hs
ICJyMCIKKyNkZWZpbmUgX194aCAicjEiCisKKyNkZWZpbmUgZG9fZGl2KG4sYmFzZSkJCQkJ
CQlcCisoewkJCQkJCQkJXAorCXJlZ2lzdGVyIHVuc2lnbmVkIGludCBfX2Jhc2UgICAgICBh
c20oInI0IikgPSBiYXNlOwlcCisJcmVnaXN0ZXIgdW5zaWduZWQgbG9uZyBsb25nIF9fbiAg
IGFzbSgicjAiKSA9IG47CVwKKwlyZWdpc3RlciB1bnNpZ25lZCBsb25nIGxvbmcgX19yZXMg
YXNtKCJyMiIpOwkJXAorCXJlZ2lzdGVyIHVuc2lnbmVkIGludCBfX3JlbSAgICAgICBhc20o
X194aCk7CQlcCisJYXNtKAlfX2FzbWVxKCIlMCIsIF9feGgpCQkJCVwKKwkJX19hc21lcSgi
JTEiLCAicjIiKQkJCQlcCisJCV9fYXNtZXEoIiUyIiwgInIwIikJCQkJXAorCQlfX2FzbWVx
KCIlMyIsICJyNCIpCQkJCVwKKwkJImJsCV9fZG9fZGl2NjQiCQkJCVwKKwkJOiAiPXIiIChf
X3JlbSksICI9ciIgKF9fcmVzKQkJCVwKKwkJOiAiciIgKF9fbiksICJyIiAoX19iYXNlKQkJ
CVwKKwkJOiAiaXAiLCAibHIiLCAiY2MiKTsJCQkJXAorCW4gPSBfX3JlczsJCQkJCQlcCisJ
X19yZW07CQkJCQkJCVwKK30pCisjZW5kaWYgLyohX19BU1NFTUJMWV9fKi8KKyNlbmRpZiAv
KiFfX0FSTV9ESVY2NF9IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUv
YXNtLWFybS9kb21haW4uaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2RvbWFpbi5oCUZyaSBGZWIgMDMg
MTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDc5IEBACisjaWZuZGVmIF9fQVJNX0RP
TUFJTl9IX18KKyNkZWZpbmUgX19BUk1fRE9NQUlOX0hfXworI2luY2x1ZGUgPHhlbi9pbml0
Lmg+CisjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8eGVuL3NwaW5sb2NrLmg+Cisj
aW5jbHVkZSA8eGVuL3Rhc2tsZXQuaD4KKyNpbmNsdWRlIDxhc20vbnVtYS5oPgorI2luY2x1
ZGUgPGFzbS9pb21tdS5oPgorI2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5oPgorCisjaWYg
MAorI2RlZmluZSBNQVBIQVNIX0VOVFJJRVMJCQk4CisjZGVmaW5lIE1BUEhBU0hfSEFTSEZO
KHBmbikJCSgocGZuKSAmIChNQVBIQVNIX0VOVFJJRVMtMSkpCisjZGVmaW5lIE1BUEhBU0hF
TlRfTk9USU5VU0UJCSgodTE2KX4wVSkKKworc3RydWN0IHZjcHVfbWFwaGFzaCB7CisgICAg
c3RydWN0IHZjcHVfbWFwaGFzaF9lbnRyeSB7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZu
OworICAgICAgICB1aW50MTZfdCAgICAgIGlkeDsKKyAgICAgICAgdWludDE2X3QgICAgICBy
ZWZjbnQ7CisgICAgfSBoYXNoW01BUEhBU0hfRU5UUklFU107Cit9X19jYWNoZWxpbmVfYWxp
Z25lZDsKKworCisjZGVmaW5lIE1BUENBQ0hFX09SREVSICAgOAorI2RlZmluZSBNQVBDQUNI
RV9FTlRSSUVTICgxIDw8IE1BUENBQ0hFX09SREVSKQorCitzdHJ1Y3QgbWFwY2FjaGUgewor
ICAgIC8qIFRoZSBQVEVzIHRoYXQgcHJvdmlkZSB0aGUgbWFwcGluZ3MsIGFuZCBhIGN1cnNv
ciBpbnRvIHRoZSBhcnJheS4gKi8KKyAgICBsMmVfdAkqdGFibGU7CisgICAgdW5zaWduZWQg
aW50IGN1cnNvcjsKKworICAgIC8qIFByb3RlY3RzIG1hcF9kb21haW5fcGFnZSgpLiAqLwor
ICAgIHNwaW5sb2NrX3QgbG9jazsKKworICAgIC8qIFdoaWNoIG1hcHBpbmdzIGFyZSBpbiB1
c2UsIGFuZCB3aGljaCBhcmUgZ2FyYmFnZSB0byByZWFwIG5leHQgZXBvY2g/ICovCisgICAg
dW5zaWduZWQgbG9uZyBpbnVzZVtCSVRTX1RPX0xPTkdTKE1BUENBQ0hFX0VOVFJJRVMpXTsK
KyAgICB1bnNpZ25lZCBsb25nIGdhcmJhZ2VbQklUU19UT19MT05HUyhNQVBDQUNIRV9FTlRS
SUVTKV07CisKKyAgICAvKiBMb2NrLWZyZWUgcGVyLVZDUFUgaGFzaCBvZiByZWNlbnRseS11
c2VkIG1hcHBpbmdzLiAqLworICAgIHN0cnVjdCB2Y3B1X21hcGhhc2ggdmNwdV9tYXBoYXNo
W01BWF9WSVJUX0NQVVNdOworfV9fY2FjaGVsaW5lX2FsaWduZWQ7CisjZW5kaWYKK3N0cnVj
dCBhcmNoX2RvbWFpbgoreworI2lmIDAKKyAgICAvKiBJL08tcG9ydCBhZG1pbi1zcGVjaWZp
ZWQgYWNjZXNzIGNhcGFiaWxpdGllcy4gKi8KKyAgICBzdHJ1Y3QgcmFuZ2VzZXQJKmlvcG9y
dF9jYXBzOworCisgICAgaW50ICppcnFfcGlycTsKKyAgICBpbnQgKnBpcnFfaXJxOworCisg
ICAgdW5zaWduZWQgbG9uZyAqcGlycV9lb2lfbWFwOworICAgIHVuc2lnbmVkIGxvbmcgcGly
cV9lb2lfbWFwX21mbjsKKyNlbmRpZgorICAgIHN0cnVjdCBwYWdlX2xpc3RfaGVhZCByZWxt
ZW1fbGlzdDsKK307CisKK3N0cnVjdCBhcmNoX3ZjcHUKK3sKKwlzdHJ1Y3QgdmNwdV9ndWVz
dF9jb250ZXh0IGN0eDsKK30gX19jYWNoZWxpbmVfYWxpZ25lZDsKKworLy8jZGVmaW5lIFZD
UFVfUkVHKHYsIHJlZykJdi0+YXJjaC5jdHgucmVnCisKKyNkZWZpbmUgcmV0dXJuX3JlZyh2
KQkJKCh2KS0+YXJjaC5jdHgucjApCisKK3ZvaWQgdmNwdV9zaG93X2V4ZWN1dGlvbl9zdGF0
ZShzdHJ1Y3QgdmNwdSAqdik7Cit2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKTsK
KworZXh0ZXJuIHN0cnVjdCB2Y3B1ICppZGxlX3ZjcHVbXTsKKworc3RhdGljIGlubGluZSBz
dHJ1Y3QgdmNwdSAqZ2V0X2lkbGVfdmNwdSh1bnNpZ25lZCBpbnQgY3B1KQoreworICAgICAg
ICByZXR1cm4gaWRsZV92Y3B1W2NwdV07Cit9CisKKyNlbmRpZiAKKwpkaWZmIC1yIGU3MDE0
NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2VsZi5oCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vZWxm
LmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTMgQEAKKy8q
CisgKiBlbGYuaAorICoKKyAqIENvcHlyaWdodCAoQykgMjAwOCBTYW1zdW5nIEVsZWN0cm9u
aWNzCisgKiAgICAgICAgICBKYWVtaW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAq
CisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5Cisg
KiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICog
YnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2Fy
cmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM
QVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv
ciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29w
eSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhp
cyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3Vu
ZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAg
MDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2lmbmRlZiBfX0FSTV9FTEZfSF9fCisjZGVmaW5l
IF9fQVJNX0VMRl9IX18KKwordHlwZWRlZiBzdHJ1Y3QgeworCXVuc2lnbmVkIGxvbmcJY3I7
Cit9IGNyYXNoX3hlbl9jb3JlX3Q7CisKK3R5cGVkZWYgc3RydWN0IHsKKwl1bnNpZ25lZCBs
b25nCXIwOworCXVuc2lnbmVkIGxvbmcJcjE7CisJdW5zaWduZWQgbG9uZwlyMjsKKwl1bnNp
Z25lZCBsb25nCXIzOworCXVuc2lnbmVkIGxvbmcJcjQ7CisJdW5zaWduZWQgbG9uZwlyNTsK
Kwl1bnNpZ25lZCBsb25nCXI2OworCXVuc2lnbmVkIGxvbmcJcjc7CisJdW5zaWduZWQgbG9u
ZwlyODsKKwl1bnNpZ25lZCBsb25nCXI5OworCXVuc2lnbmVkIGxvbmcJcjEwOworCXVuc2ln
bmVkIGxvbmcJcjExOworCXVuc2lnbmVkIGxvbmcJcjEyOworCXVuc2lnbmVkIGxvbmcJcjEz
OworCXVuc2lnbmVkIGxvbmcJcjE0OworCXVuc2lnbmVkIGxvbmcJcjE1OworfSBFTEZfR3Jl
Z3NldDsKKworc3RhdGljIGlubGluZSB2b2lkIGVsZl9jb3JlX3NhdmVfcmVncyhFTEZfR3Jl
Z3NldCAqY29yZV9yZWdzLAorCQkJCSAgICAgIGNyYXNoX3hlbl9jb3JlX3QgKnhlbl9jb3Jl
X3JlZ3MpCit7Cit9CisKKyNlbmRpZgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNs
dWRlL2FzbS1hcm0vZXZlbnQuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2V2ZW50LmgJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzkgQEAKKyNpZm5kZWYgX19BUk1f
RVZFTlRfSF9fCisjZGVmaW5lIF9fQVJNX0VWRU5UX0hfXworCisjaW5jbHVkZSA8eGVuL3No
YXJlZC5oPgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXwordm9pZCB2Y3B1X2tpY2soc3RydWN0
IHZjcHUgKnYpOwordm9pZCB2Y3B1X21hcmtfZXZlbnRzX3BlbmRpbmcoc3RydWN0IHZjcHUg
KnYpOworCitpbnQgaHZtX2xvY2FsX2V2ZW50c19uZWVkX2RlbGl2ZXJ5KHN0cnVjdCB2Y3B1
ICp2KTsKK3N0YXRpYyBpbmxpbmUgaW50IGxvY2FsX2V2ZW50c19uZWVkX2RlbGl2ZXJ5KHZv
aWQpCit7CisJc3RydWN0IHZjcHUgKnYgPSBjdXJyZW50OworCXJldHVybiAoKHZjcHVfaW5m
byh2LCBldnRjaG5fdXBjYWxsX3BlbmRpbmcpICYmIAorCQkhdmNwdV9pbmZvKHYsIGV2dGNo
bl91cGNhbGxfbWFzaykpKTsKK30KKworc3RhdGljIGlubGluZSBpbnQgbG9jYWxfZXZlbnRf
ZGVsaXZlcnlfaXNfZW5hYmxlZCh2b2lkKQoreworCXJldHVybiAhdmNwdV9pbmZvKGN1cnJl
bnQsIGV2dGNobl91cGNhbGxfbWFzayk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBsb2Nh
bF9ldmVudF9kZWxpdmVyeV9kaXNhYmxlKHZvaWQpCit7CisJdmNwdV9pbmZvKGN1cnJlbnQs
IGV2dGNobl91cGNhbGxfbWFzaykgPSAxOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgbG9j
YWxfZXZlbnRfZGVsaXZlcnlfZW5hYmxlKHZvaWQpCit7CisJdmNwdV9pbmZvKGN1cnJlbnQs
IGV2dGNobl91cGNhbGxfbWFzaykgPSAwOworfQorCisvKiBObyBhcmNoIHNwZWNpZmljIHZp
cnEgZGVmaW5pdGlvbiBub3cuIERlZmF1bHQgdG8gZ2xvYmFsLiAqLworc3RhdGljIGlubGlu
ZSBpbnQgYXJjaF92aXJxX2lzX2dsb2JhbChpbnQgdmlycSkKK3sKKwlyZXR1cm4gMTsKK30K
KyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLworI2VuZGlmIC8qIV9fQVJNX0VWRU5UX0hfXyAq
LwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2ZsdXNodGxiLmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9mbHVzaHRsYi5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiAr
MDkwMApAQCAtMCwwICsxLDI1IEBACisjaWZuZGVmIF9fQVJNX0ZMVVNIVExCX0hfXworI2Rl
ZmluZSBfX0FSTV9GTFVTSFRMQl9IX18KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNp
bmNsdWRlIDx4ZW4vcGVyY3B1Lmg+CisjaW5jbHVkZSA8eGVuL3NtcC5oPgorCisjaWZuZGVm
IF9fQVNTRU1CTFlfXworI2RlZmluZSBsb2NhbF9mbHVzaF90bGIobWFzaykKKyNkZWZpbmUg
Zmx1c2hfdGxiX21hc2sobWFzaykJbG9jYWxfZmx1c2hfdGxiKCkKKworI2RlZmluZSB0bGJm
bHVzaF9maWx0ZXIobWFzayxwYWdlX3RpbWVzdGFtcCkJXAorZG8gewkJCQkJCVwKKwlwcmlu
dGsoIk5vdCBpbXBsZW1lbnRlZCB5ZXQuXG4iKTsJXAorfSB3aGlsZSgwKQorCisjZGVmaW5l
IHRsYmZsdXNoX2N1cnJlbnRfdGltZSgpCXRsYmZsdXNoX2Nsb2NrCisKK0RFQ0xBUkVfUEVS
X0NQVSh1MzIsIHRsYl9jYXBzKTsKK0RFQ0xBUkVfUEVSX0NQVSh1MzIsIHRsYmZsdXNoX3Rp
bWUpOworCitleHRlcm4gdTMyIHRsYmZsdXNoX2Nsb2NrOworCisjZW5kaWYKKyNlbmRpZiAv
KiBfX0FSTV9UTEJfSF9fICovCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vZ3JhbnRfdGFibGUuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2dyYW50X3RhYmxlLmgJRnJp
IEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjIgQEAKKyNpZm5kZWYg
X19BU01fR1JBTlRfVEFCTEVfSF9fCisjZGVmaW5lIF9fQVNNX0dSQU5UX1RBQkxFX0hfXwor
CisjZGVmaW5lIElOSVRJQUxfTlJfR1JBTlRfRlJBTUVTIDQKKworLyoKKyAqIENhbGxlciBt
dXN0IG93biBjYWxsZXIncyBCSUdMT0NLLCBpcyByZXNwb25zaWJsZSBmb3IgZmx1c2hpbmcg
dGhlIFRMQiwgYW5kCisgKiBtdXN0IGhvbGQgYSByZWZlcmVuY2UgdG8gdGhlIHBhZ2UuCisg
Ki8KK2ludCBjcmVhdGVfZ3JhbnRfaG9zdF9tYXBwaW5nKHVpbnQ2NF90IGFkZHIsIHVuc2ln
bmVkIGxvbmcgZnJhbWUsCisJCQkgICAgICB1bnNpZ25lZCBpbnQgZmxhZ3MsIHVuc2lnbmVk
IGludCBjYWNoZV9mbGFncyk7CitpbnQgcmVwbGFjZV9ncmFudF9ob3N0X21hcHBpbmcoCisg
ICAgdWludDY0X3QgYWRkciwgdW5zaWduZWQgbG9uZyBmcmFtZSwgdWludDY0X3QgbmV3X2Fk
ZHIsIHVuc2lnbmVkIGludCBmbGFncyk7CisKKyNkZWZpbmUgZ250dGFiX2NyZWF0ZV9zaGFy
ZWRfcGFnZShkLCB0LCBpKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg
ZG8geyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAorICAgICAgICBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIHZp
cnRfdG9fcGFnZSgoY2hhciAqKSh0KS0+c2hhcmVkX3Jhd1tpXSksICAgICAgICAgICAgICAg
ICAgICBcCisgICAgICAgICAgICAoZCksIFhFTlNIQVJFX3dyaXRhYmxlKTsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIH0gd2hpbGUgKCAwICkKKworI2Rl
ZmluZSBnbnR0YWJfY3JlYXRlX3N0YXR1c19wYWdlKGQsIHQsIGkpICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKyAgICBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIHNoYXJl
X3hlbl9wYWdlX3dpdGhfZ3Vlc3QoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXAorICAgICAgICAgICB2aXJ0X3RvX3BhZ2UoKGNoYXIgKikodCktPnN0YXR1c1tp
XSksICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIChkKSwgWEVOU0hB
UkVfd3JpdGFibGUpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgfSB3aGlsZSAoIDAgKQorCisKKyNkZWZpbmUgZ250dGFiX3NoYXJlZF9tZm4oZCwgdCwg
aSkgICAgICAgICAgICAgICAgICAgICAgXAorICAgICgodmlydF90b19tYWRkcigodCktPnNo
YXJlZF9yYXdbaV0pID4+IFBBR0VfU0hJRlQpKQorCisjZGVmaW5lIGdudHRhYl9zaGFyZWRf
Z21mbihkLCB0LCBpKSAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAobWZuX3RvX2dtZm4o
ZCwgZ250dGFiX3NoYXJlZF9tZm4oZCwgdCwgaSkpKQorCisKKyNkZWZpbmUgZ250dGFiX3N0
YXR1c19tZm4odCwgaSkgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICgodmlydF90
b19tYWRkcigodCktPnN0YXR1c1tpXSkgPj4gUEFHRV9TSElGVCkpCisKKyNkZWZpbmUgZ250
dGFiX3N0YXR1c19nbWZuKGQsIHQsIGkpICAgICAgICAgICAgICAgICAgICAgXAorICAgICht
Zm5fdG9fZ21mbihkLCBnbnR0YWJfc3RhdHVzX21mbih0LCBpKSkpCisKKyNkZWZpbmUgZ250
dGFiX21hcmtfZGlydHkoZCwgZikgKCh2b2lkKWYpCisKK3N0YXRpYyBpbmxpbmUgdm9pZCBn
bnR0YWJfY2xlYXJfZmxhZyh1bnNpZ25lZCBsb25nIG5yLCB1aW50MTZfdCAqYWRkcikKK3sK
KyAgICBjbGVhcl9iaXQobnIsICh1bnNpZ25lZCBsb25nICopYWRkcik7Cit9CisKKy8qIEZv
cmVpZ24gbWFwcGluZ3Mgb2YgSEhWTS1ndWVzdCBwYWdlcyBkbyBub3QgbW9kaWZ5IHRoZSB0
eXBlIGNvdW50LiAqLworI2RlZmluZSBnbnR0YWJfaG9zdF9tYXBwaW5nX2dldF9wYWdlX3R5
cGUob3AsIGxkLCByZCkgICBcCisgICAgKCEoKG9wKS0+ZmxhZ3MgJiBHTlRNQVBfcmVhZG9u
bHkpICYmICAgICAgICAgICAgICAgIFwKKyAgICAgKCgobGQpID09IChyZCkpIHx8ICFwYWdp
bmdfbW9kZV9leHRlcm5hbChyZCkpKQorCisvKiBEb25lIGltcGxpY2l0bHkgd2hlbiBwYWdl
IHRhYmxlcyBhcmUgZGVzdHJveWVkLiAqLworI2RlZmluZSBnbnR0YWJfcmVsZWFzZV9ob3N0
X21hcHBpbmdzKGRvbWFpbikgKCBwYWdpbmdfbW9kZV9leHRlcm5hbChkb21haW4pICkKKwor
c3RhdGljIGlubGluZSBpbnQgcmVwbGFjZV9ncmFudF9zdXBwb3J0ZWQodm9pZCkKK3sKKyAg
ICByZXR1cm4gMTsKK30KKyNlbmRpZiAvKiBfX0FTTV9HUkFOVF9UQUJMRV9IX18gKi8KZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9ndWVzdF9hY2Nlc3MuaAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
aW5jbHVkZS9hc20tYXJtL2d1ZXN0X2FjY2Vzcy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAx
MiArMDkwMApAQCAtMCwwICsxLDEzNiBAQAorLyoKKyAqLworCisjaWZuZGVmIF9fQVJNX0dV
RVNUX0FDQ0VTU19IX18KKyNkZWZpbmUgX19BUk1fR1VFU1RfQUNDRVNTX0hfXworCisjZGVm
aW5lIF9fcmFuZ2Vfb2soYWRkciwgc2l6ZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJdW5zaWduZWQgbG9uZyBm
bGFncywgc3VtOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKwlf
X2FzbV9fKCJhZGRzICAgJTEsICUyLCAlM1xuXHQiICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorCQkic2JjY2NzICUxLCAlMSwgJTBcblx0IiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKwkJIm1vdmNjICAlMCwgIzAiICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBcCisJCTogIj0mciIoZmxhZ3MpLCAiPSZyIihzdW0p
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorCQk6ICJyIihhZGRyKSwgIklyIihz
aXplKSwgIjAiKEhZUEVSVklTT1JfVklSVF9TVEFSVCkgICAgIFwKKwkJOiAiY2MiKTsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJZmxhZ3M7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKK30pCisKKyNkZWZpbmUgYWNjZXNzX29rKGFkZHIsc2l6ZSkgICAgKF9fcmFuZ2Vf
b2soYWRkcixzaXplKSA9PSAwKQorCisjZGVmaW5lIGFycmF5X2FjY2Vzc19vayhhZGRyLGNv
dW50LHNpemUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJKGxpa2VseShj
b3VudCA8ICh+MFVML3NpemUpKSAmJiBhY2Nlc3Nfb2soYWRkcixjb3VudCpzaXplKSkKKwor
LyogUmF3IGFjY2VzcyBmdW5jdGlvbnM6IG5vIHR5cGUgY2hlY2tpbmcuICovCisjZGVmaW5l
IHJhd19jb3B5X3RvX2d1ZXN0KGRzdCwgc3JjLCBsZW4pICAgICAgICBcCisgICAgIF9fY29w
eV90b191c2VyKChkc3QpLCAoc3JjKSwgKGxlbikpCisjZGVmaW5lIHJhd19jb3B5X2Zyb21f
Z3Vlc3QoZHN0LCBzcmMsIGxlbikgICAgICBcCisgICAgIF9fY29weV9mcm9tX3VzZXIoKGRz
dCksIChzcmMpLCAobGVuKSkKKyNkZWZpbmUgcmF3X2NsZWFyX2d1ZXN0KGRzdCwgIGxlbikg
ICAgICAgICAgICAgIFwKKyAgICAgX19jbGVhcl91c2VyKChkc3QpLCAobGVuKSkKKyNkZWZp
bmUgX19yYXdfY29weV90b19ndWVzdChkc3QsIHNyYywgbGVuKSAgICAgIFwKKyAgICAgX19j
b3B5X3RvX3VzZXIoKGRzdCksIChzcmMpLCAobGVuKSkKKyNkZWZpbmUgX19yYXdfY29weV9m
cm9tX2d1ZXN0KGRzdCwgc3JjLCBsZW4pICAgIFwKKyAgICAgX19jb3B5X2Zyb21fdXNlcigo
ZHN0KSwgKHNyYyksIChsZW4pKQorI2RlZmluZSBfX3Jhd19jbGVhcl9ndWVzdChkc3QsICBs
ZW4pICAgICAgICAgICAgXAorICAgICBfX2NsZWFyX3VzZXIoKGRzdCksIChsZW4pKQorCisK
KworLyogSXMgdGhlIGd1ZXN0IGhhbmRsZSBhIE5VTEwgcmVmZXJlbmNlPyAqLworI2RlZmlu
ZSBndWVzdF9oYW5kbGVfaXNfbnVsbChobmQpCQlcCisJKChobmQpLnAgPT0gTlVMTCkKKwor
LyogT2Zmc2V0IHRoZSBnaXZlbiBndWVzdCBoYW5kbGUgaW50byB0aGUgYXJyYXkgaXQgcmVm
ZXJzIHRvLiAqLworI2RlZmluZSBndWVzdF9oYW5kbGVfYWRkX29mZnNldChobmQsIG5yKQlc
CisJKChobmQpLnAgKz0gKG5yKSkKKworLyogQ2FzdCBhIGd1ZXN0IGhhbmRsZSB0byB0aGUg
c3BlY2lmaWVkIHR5cGUgb2YgaGFuZGxlLiAqLworI2RlZmluZSBndWVzdF9oYW5kbGVfY2Fz
dChobmQsIHR5cGUpCQlcCisoewkJCQkJCVwKKyAgICB0eXBlICpfeCA9IChobmQpLnA7CQkJ
CVwKKyAgICAoWEVOX0dVRVNUX0hBTkRMRSh0eXBlKSkgeyBfeCB9OwkJXAorfSkKKworCisv
KgorICogUHJlLXZhbGlkYXRlIGEgZ3Vlc3QgaGFuZGxlLgorICogQWxsb3dzIHVzZSBvZiBm
YXN0ZXIgX19jb3B5XyogZnVuY3Rpb25zLgorICovCisjZGVmaW5lIGd1ZXN0X2hhbmRsZV9v
a2F5KGhuZCwgbnIpICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBhcnJheV9hY2Nlc3Nf
b2soKGhuZCkucCwgKG5yKSwgc2l6ZW9mKCooaG5kKS5wKSkKKyAgICAKKyNkZWZpbmUgZ3Vl
c3RfaGFuZGxlX3N1YnJhbmdlX29rYXkoaG5kLCBmaXJzdCwgbGFzdCkJXAorICAgKGFycmF5
X2FjY2Vzc19vaygoaG5kKS5wICsgKGZpcnN0KSwJCQlcCisJCSAgIChsYXN0KSAtIChmaXJz
dCkgKyAxLAkJXAorCQkgICBzaXplb2YoKihobmQpLnApKSkKKy8qCisgKiBDb3B5IGFuIGFy
cmF5IG9mIG9iamVjdHMgdG8gZ3Vlc3QgY29udGV4dCB2aWEgYSBndWVzdCBoYW5kbGUuCisg
KiBPcHRpb25hbGx5IHNwZWNpZnkgYW4gb2Zmc2V0IGludG8gdGhlIGd1ZXN0IGFycmF5Lgor
ICovCisjZGVmaW5lIGNvcHlfdG9fZ3Vlc3Rfb2Zmc2V0KGhuZCwgaWR4LCBwdHIsIG5yKSBc
CisgICAgX19jb3B5X3RvX2d1ZXN0X29mZnNldChobmQsIGlkeCwgcHRyLCBucikKKworICAK
Ky8qCisgKiBDb3B5IGFuIGFycmF5IG9mIG9iamVjdHMgZnJvbSBndWVzdCBjb250ZXh0IHZp
YSBhIGd1ZXN0IGhhbmRsZS4KKyAqIE9wdGlvbmFsbHkgc3BlY2lmeSBhbiBvZmZzZXQgaW50
byB0aGUgZ3Vlc3QgYXJyYXkuCisgKi8KKyNkZWZpbmUgY29weV9mcm9tX2d1ZXN0X29mZnNl
dChwdHIsIGhuZCwgaWR4LCBucikgXAorICAgIF9fY29weV9mcm9tX2d1ZXN0X29mZnNldChw
dHIsIGhuZCwgaWR4LCBucikKKyAgICAKKyAgICAKKy8qIENvcHkgc3ViLWZpZWxkIG9mIGEg
c3RydWN0dXJlIHRvIGd1ZXN0IGNvbnRleHQgdmlhIGEgZ3Vlc3QgaGFuZGxlLiAqLworI2Rl
ZmluZSBjb3B5X2ZpZWxkX3RvX2d1ZXN0KGhuZCwgcHRyLCBmaWVsZCkgXAorICAgIF9fY29w
eV9maWVsZF90b19ndWVzdChobmQsIHB0ciwgZmllbGQpCisKKy8qIENvcHkgc3ViLWZpZWxk
IG9mIGEgc3RydWN0dXJlIGZyb20gZ3Vlc3QgY29udGV4dCB2aWEgYSBndWVzdCBoYW5kbGUu
ICovCisjZGVmaW5lIGNvcHlfZmllbGRfZnJvbV9ndWVzdChwdHIsIGhuZCwgZmllbGQpIFwK
KyAgICBfX2NvcHlfZmllbGRfZnJvbV9ndWVzdChwdHIsIGhuZCwgZmllbGQpCisgICAgCisj
ZGVmaW5lIF9fY29weV90b19ndWVzdF9vZmZzZXQoaG5kLCBvZmYsIHB0ciwgbnIpICh7ICAg
IFwKKyAgICBjb25zdCB0eXBlb2YoKihwdHIpKSAqX3MgPSAocHRyKTsgICAgICAgICAgICAg
ICAgICAgXAorICAgIGNoYXIgKCpfZClbc2l6ZW9mKCpfcyldID0gKHZvaWQgKikoaG5kKS5w
OyAgICAgICAgICBcCisgICAgKCh2b2lkKSgoaG5kKS5wID09IChwdHIpKSk7ICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKyAgICBfX2NvcHlfdG9fdXNlcihfZCsob2ZmKSwgX3MsIHNp
emVvZigqX3MpKihucikpOyAgICAgXAorfSkKKworI2RlZmluZSBfX2NvcHlfZnJvbV9ndWVz
dF9vZmZzZXQocHRyLCBobmQsIG9mZiwgbnIpICh7ICBcCisgICAgY29uc3QgdHlwZW9mKCoo
cHRyKSkgKl9zID0gKGhuZCkucDsgICAgICAgICAgICAgICAgIFwKKyAgICB0eXBlb2YoKihw
dHIpKSAqX2QgPSAocHRyKTsgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIF9fY29w
eV9mcm9tX3VzZXIoX2QsIF9zKyhvZmYpLCBzaXplb2YoKl9kKSoobnIpKTsgICBcCit9KQor
CisjZGVmaW5lIF9fY29weV9maWVsZF90b19ndWVzdChobmQsIHB0ciwgZmllbGQpICh7ICAg
ICAgIFwKKyAgICBjb25zdCB0eXBlb2YoJihwdHIpLT5maWVsZCkgX3ggPSAmKGhuZCkucC0+
ZmllbGQ7ICAgXAorICAgIGNvbnN0IHR5cGVvZigmKHB0ciktPmZpZWxkKSBfeSA9ICYocHRy
KS0+ZmllbGQ7ICAgICBcCisgICAgX19jb3B5X3RvX3VzZXIoX3gsIF95LCBzaXplb2YoKl94
KSk7ICAgICAgICAgICAgICAgIFwKK30pCisKKyNkZWZpbmUgX19jb3B5X2ZpZWxkX2Zyb21f
Z3Vlc3QocHRyLCBobmQsIGZpZWxkKSAoeyAgICAgXAorICAgIGNvbnN0IHR5cGVvZigmKHB0
ciktPmZpZWxkKSBfeCA9ICYoaG5kKS5wLT5maWVsZDsgICBcCisgICAgY29uc3QgdHlwZW9m
KCYocHRyKS0+ZmllbGQpIF95ID0gJihwdHIpLT5maWVsZDsgICAgIFwKKyAgICBfX2NvcHlf
ZnJvbV91c2VyKF95LCBfeCwgc2l6ZW9mKCpfeCkpOyAgICAgICAgICAgICAgXAorfSkKKwor
CitleHRlcm4gdW5zaWduZWQgbG9uZyBfX2FyY2hfY29weV9mcm9tX3VzZXIodm9pZCAqdG8s
IGNvbnN0IHZvaWQgKmZyb20sIHVuc2lnbmVkIGxvbmcgbik7CitleHRlcm4gdW5zaWduZWQg
bG9uZyBfX2FyY2hfY29weV90b191c2VyKHZvaWQgKnRvLCBjb25zdCB2b2lkICpmcm9tLCB1
bnNpZ25lZCBsb25nIG4pOworZXh0ZXJuIHVuc2lnbmVkIGxvbmcgX19hcmNoX2NsZWFyX3Vz
ZXIodm9pZCAqdG8sIHVuc2lnbmVkIGxvbmcgbik7CisKK3N0YXRpYyBpbmxpbmUgdW5zaWdu
ZWQgbG9uZyBfX2NvcHlfZnJvbV91c2VyKHZvaWQgKnRvLCBjb25zdCB2b2lkICpmcm9tLCB1
bnNpZ25lZCBsb25nIG4pCit7CisgICAgICAgIHJldHVybiBfX2FyY2hfY29weV9mcm9tX3Vz
ZXIodG8sIGZyb20sIG4pOworfQorCisKK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBf
X2NvcHlfdG9fdXNlcih2b2lkICp0bywgY29uc3Qgdm9pZCAqZnJvbSwgdW5zaWduZWQgbG9u
ZyBuKQoreworICAgICAgICByZXR1cm4gX19hcmNoX2NvcHlfdG9fdXNlcih0bywgZnJvbSwg
bik7Cit9CisKK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBfX2NsZWFyX3VzZXIodm9p
ZCAqdG8sIHVuc2lnbmVkIGxvbmcgbikKK3sKKwlyZXR1cm4gX19hcmNoX2NsZWFyX3VzZXIo
dG8sIG4pOworfQorI2VuZGlmCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vaGFyZGlycS5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vaGFyZGlycS5oCUZyaSBGZWIgMDMg
MTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDIxIEBACisjaWZuZGVmIF9fQVJNX0hB
UkRJUlFfSF9fCisjZGVmaW5lIF9fQVJNX0hBUkRJUlFfSF9fCisKKyNpbmNsdWRlIDx4ZW4v
Y29uZmlnLmg+CisjaW5jbHVkZSA8eGVuL2NhY2hlLmg+CisKKyNpZm5kZWYgX19BU1NFTUJM
WV9fCit0eXBlZGVmIHN0cnVjdCBpcnFfY3B1c3RhdCB7CisJdW5zaWduZWQgbG9uZyBfX3Nv
ZnRpcnFfcGVuZGluZzsKKwl1bnNpZ25lZCBsb25nIF9fbG9jYWxfaXJxX2NvdW50OworCXVu
c2lnbmVkIGxvbmcgX19ubWlfY291bnQ7Cit9IF9fY2FjaGVsaW5lX2FsaWduZWQgaXJxX2Nw
dXN0YXRfdDsKKworI2luY2x1ZGUgPHhlbi9pcnFfY3B1c3RhdC5oPiAgICAvKiBTdGFuZGFy
ZCBtYXBwaW5ncyBmb3IgaXJxX2NwdXN0YXRfdCBhYm92ZSAqLworCisjZGVmaW5lIGluX2ly
cSgpIAkobG9jYWxfaXJxX2NvdW50KHNtcF9wcm9jZXNzb3JfaWQoKSkgIT0gMCkKKworI2Rl
ZmluZSBpcnFfZW50ZXIoKSAgICAgKGxvY2FsX2lycV9jb3VudChzbXBfcHJvY2Vzc29yX2lk
KCkpKyspCisjZGVmaW5lIGlycV9leGl0KCkgICAgICAobG9jYWxfaXJxX2NvdW50KHNtcF9w
cm9jZXNzb3JfaWQoKSktLSkKKyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLworI2VuZGlmIC8q
IV9fQVJNX0hBUkRJUlFfSF9fKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUv
YXNtLWFybS9oeXBlcmNhbGwuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2h5cGVyY2FsbC5oCUZyaSBG
ZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDY4IEBACisvKgorICogaHlw
ZXJjYWxsLmgKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDggU2Ftc3VuZyBFbGVjdHJvbmlj
cworICogICAgICAgICAgSm9vWW91bmcgSHdhbmcgPGpvb3lvdW5nLmh3YW5nQHNhbXN1bmcu
Y29tPgorICogICAgICAgICAgSmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+Cisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQor
ICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0g
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAq
IGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdh
cnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBm
b3IgbW9yZSBkZXRhaWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv
cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRo
aXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91
bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEg
IDAyMTExLTEzMDcgIFVTQQorICovCisKKyNpZm5kZWYgX19BUk1fSFlQRVJDQUxMX0hfXwor
I2RlZmluZSBfX0FSTV9IWVBFUkNBTExfSF9fCisjaW5jbHVkZSA8cHVibGljL3BoeXNkZXYu
aD4KKworI2lmbmRlZiBfX0FTU0VNQkxZX18KK2V4dGVybiBsb25nIGRvX3NldF90cmFwX3Rh
YmxlKFhFTl9HVUVTVF9IQU5ETEUodHJhcF9pbmZvX3QpIHRyYXBzKTsKKworZXh0ZXJuIGlu
dCBkb19tbXVfdXBkYXRlKFhFTl9HVUVTVF9IQU5ETEUobW11X3VwZGF0ZV90KSB1cmVxcywK
KwkJCSB1bnNpZ25lZCBpbnQgY291bnQsCisJCQkgWEVOX0dVRVNUX0hBTkRMRSh1aW50KSBw
ZG9uZSwKKwkJCSB1bnNpZ25lZCBpbnQgZm9yZWlnbmRvbSk7CisKK2V4dGVybiBsb25nIGRv
X3NldF9nZHQoWEVOX0dVRVNUX0hBTkRMRSh1bG9uZykgZnJhbWVfbGlzdCwKKwkJICAgICAg
IHVuc2lnbmVkIGludCBlbnRyaWVzKTsKKworZXh0ZXJuIGxvbmcgZG9fc3RhY2tfc3dpdGNo
KHVuc2lnbmVkIGxvbmcgc3MsIHVuc2lnbmVkIGxvbmcgZXNwKTsKKworZXh0ZXJuIGxvbmcg
ZG9fZnB1X3Rhc2tzd2l0Y2goaW50IHNldCk7CisKK2V4dGVybiBsb25nIGRvX3NldF9kZWJ1
Z3JlZyhpbnQgcmVnLCB1bnNpZ25lZCBsb25nIHZhbHVlKTsKKworZXh0ZXJuIHVuc2lnbmVk
IGxvbmcgZG9fZ2V0X2RlYnVncmVnKGludCByZWcpOworCitleHRlcm4gbG9uZyBkb191cGRh
dGVfZGVzY3JpcHRvcih1NjQgcGEsIHU2NCBkZXNjKTsKKworZXh0ZXJuIGludCBkb191cGRh
dGVfdmFfbWFwcGluZyh1MzIgdmEsIHUzMiBmbGFncywgdTY0IHZhbDY0KTsKKworZXh0ZXJu
IGxvbmcgZG9fcGh5c2Rldl9vcChYRU5fR1VFU1RfSEFORExFKHBoeXNkZXZfb3BfdCkgdW9w
KTsKKworZXh0ZXJuIGludCBkb191cGRhdGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbih1bnNp
Z25lZCBsb25nIHZhLAorCQkJCQkgICAgdTY0IHZhbDY0LAorCQkJCQkgICAgdW5zaWduZWQg
bG9uZyBmbGFncywKKwkJCQkJICAgIGRvbWlkX3QgZG9taWQpOworCitleHRlcm4gaW50IGRv
X21tdWV4dF9vcChYRU5fR1VFU1RfSEFORExFKG1tdWV4dF9vcF90KSB1b3BzLAorCQkJdW5z
aWduZWQgaW50IGNvdW50LAorCQkJWEVOX0dVRVNUX0hBTkRMRSh1aW50KSBwZG9uZSwKKwkJ
CXVuc2lnbmVkIGludCBmb3JlaWduZG9tKTsKKworZXh0ZXJuIHVuc2lnbmVkIGxvbmcgZG9f
aXJldCh2b2lkKTsKKworc3RydWN0IHZjcHU7CitleHRlcm4gbG9uZyBhcmNoX2RvX3ZjcHVf
b3AoaW50IGNtZCwgc3RydWN0IHZjcHUgKnYsIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJn
KTsKKworZXh0ZXJuIGxvbmcgZG9fc2V0X2NhbGxiYWNrcyh1bnNpZ25lZCBsb25nIGV2ZW50
LCB1bnNpZ25lZCBsb25nIGZhaWxzYWZlKTsKKyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLwor
I2VuZGlmIC8qIV9fQVJNX0hZUEVSQ0FMTF9IX18qLwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4
ZW4vaW5jbHVkZS9hc20tYXJtL2luaXQuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2luaXQuaAlGcmkg
RmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw0IEBACisjaWZuZGVmIF9f
QVJNX0lOSVRfSF9fCisjZGVmaW5lIF9fQVJNX0lOSVRfSF9fCisKKyNlbmRpZiAvKiBfWEVO
X0FTTV9JTklUX0ggKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFy
bS9pby5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vaW8uaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSwzMiBAQAorI2lmbmRlZiBfX0FSTV9JT19IX18KKyNkZWZpbmUg
X19BUk1fSU9fSF9fCisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisKKyNkZWZpbmUgbW1pb193
cml0ZWIodixhKQkoKih2b2xhdGlsZSB1bnNpZ25lZCBjaGFyICopKGEpID0gKHYpKQorI2Rl
ZmluZSBtbWlvX3dyaXRldyh2LGEpCSgqKHZvbGF0aWxlIHVuc2lnbmVkIHNob3J0ICopKGEp
ID0gKHYpKQorI2RlZmluZSBtbWlvX3dyaXRlbCh2LGEpCSgqKHZvbGF0aWxlIHVuc2lnbmVk
IGludCAqKShhKSA9ICh2KSkKKworI2RlZmluZSBtbWlvX3JlYWRiKGEpCQkoKih2b2xhdGls
ZSB1bnNpZ25lZCBjaGFyICopKGEpKQorI2RlZmluZSBtbWlvX3JlYWR3KGEpCQkoKih2b2xh
dGlsZSB1bnNpZ25lZCBzaG9ydCAqKShhKSkKKyNkZWZpbmUgbW1pb19yZWFkbChhKQkJKCoo
dm9sYXRpbGUgdW5zaWduZWQgaW50ICopKGEpKQorCisjZGVmaW5lIHdyaXRlYih2LGEpCQlt
bWlvX3dyaXRlYih2LGEpCisjZGVmaW5lIHdyaXRldyh2LGEpCQltbWlvX3dyaXRldyh2LGEp
CisKKyNkZWZpbmUgd3JpdGVsKHYsYSkJCW1taW9fd3JpdGVsKHYsYSkKKyNkZWZpbmUgcmVh
ZGIoYSkJCW1taW9fcmVhZGIoYSkKKyNkZWZpbmUgcmVhZHcoYSkJCW1taW9fcmVhZHcoYSkK
KyNkZWZpbmUgcmVhZGwoYSkJCW1taW9fcmVhZGwoYSkKKworI2RlZmluZSBpb3JlbWFwKHgs
bCkJCShfX3ZhKHgpKQorI2RlZmluZSBpb3VubWFwKHApCQkoKHZvaWQpMCkKKworI2RlZmlu
ZSBpbmIoYSkJCQltbWlvX3JlYWRiKGEpCisjZGVmaW5lIGludyhhKQkJCW1taW9fcmVhZHco
YSkKKyNkZWZpbmUgaW5sKGEpCQkJbW1pb19yZWFkbChhKQorCisjZGVmaW5lIG91dGIodixh
KQkJbW1pb193cml0ZWIodixhKQorI2RlZmluZSBvdXR3KHYsYSkJCW1taW9fd3JpdGV3KHYs
YSkKKyNkZWZpbmUgb3V0bCh2LGEpCQltbWlvX3dyaXRlbCh2LGEpCisKKyNlbmRpZgkvKiBf
X0FSTV9JT19IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFy
bS9pb2NhcC5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vaW9jYXAuaAlGcmkgRmViIDAzIDE2OjA3OjAz
IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxNSBAQAorI2lmbmRlZiBfX0FSTV9JT0NBUF9IX18K
KyNkZWZpbmUgX19BUk1fSU9DQVBfSF9fCisKKyNkZWZpbmUgaW9wb3J0c19wZXJtaXRfYWNj
ZXNzKGQsIHMsIGUpICAgICAgICAgICAgICAgICAgXAorICAgIHJhbmdlc2V0X2FkZF9yYW5n
ZSgoZCktPmFyY2guaW9wb3J0X2NhcHMsIHMsIGUpCisKKyNkZWZpbmUgaW9wb3J0c19kZW55
X2FjY2VzcyhkLCBzLCBlKSAgICAgICAgICAgICAgICAgICAgXAorICAgIHJhbmdlc2V0X3Jl
bW92ZV9yYW5nZSgoZCktPmFyY2guaW9wb3J0X2NhcHMsIHMsIGUpCisKKyNkZWZpbmUgaW9w
b3J0c19hY2Nlc3NfcGVybWl0dGVkKGQsIHMsIGUpICAgICAgICAgICAgICAgXAorICAgIHJh
bmdlc2V0X2NvbnRhaW5zX3JhbmdlKChkKS0+YXJjaC5pb3BvcnRfY2FwcywgcywgZSkKKwor
I2RlZmluZSBtdWx0aXBhZ2VfYWxsb2NhdGlvbl9wZXJtaXR0ZWQoZCwgb3JkZXIpCSgwKQor
CisjZW5kaWYKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9pb21t
dS5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3hlbi9pbmNsdWRlL2FzbS1hcm0vaW9tbXUuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSwxNCBAQAorI2lmbmRlZiBfX0FSTV9JT01NVV9IX18KKyNkZWZp
bmUgX19BUk1fSU9NTVVfSF9fCisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCitzdGF0aWMgaW5s
aW5lIGludCBpc19pb21lbV9wYWdlKHVuc2lnbmVkIGxvbmcgbWZuKQoreworCXJldHVybiAw
OworfQorCitpbnQgaW9tbXVfbWFwX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQg
bG9uZyBnZm4sIHVuc2lnbmVkIGxvbmcgbWZuLCB1bnNpZ25lZCBpbnQgZmxhZ3MpOworaW50
IGlvbW11X3VubWFwX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgbG9uZyBnZm4p
OworI2VuZGlmIC8qIV9fQVNTRU1CTFlfXyovCisjZW5kaWYgLyohX19BUk1fSU9NTVVfSF9f
Ki8KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2lycS5oCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9p
bmNsdWRlL2FzbS1hcm0vaXJxLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBA
IC0wLDAgKzEsNTAgQEAKKyNpZm5kZWYgX19BUk1fSVJRX0hfXworI2RlZmluZSBfX0FSTV9J
UlFfSF9fCisKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8eGVuL2NwdW1h
c2suaD4KKworI2lmbmRlZiBOUl9JUlFTCisjZGVmaW5lIE5SX0lSUVMJMjU2CisjZW5kaWYK
KworI2RlZmluZSBkb21haW5fcGlycV90b19pcnEoZCwgcGlycSkJKHBpcnEpCisjZGVmaW5l
IGRvbWFpbl9pcnFfdG9fcGlycShkLCBpcnEpCShpcnEpICAgICAgICAgICAgICAgICAgICAg
ICAKKyNkZWZpbmUgZG9tYWluX3BpcnFfdG9fZW11aXJxKGQsIHBpcnEpCShwaXJxKQorI2Rl
ZmluZSBkb21haW5fZW11aXJxX3RvX3BpcnEoZCwgaXJxKQkoaXJxKQorCisjZGVmaW5lIGly
cV9jZmcoaXJxKQkJKCZpcnFfY2ZnW2lycV0pCisjZGVmaW5lIGlycV90b19kZXNjKGlycSkJ
KCZpcnFfZGVzY1tpcnFdKQkKKworI2RlZmluZSBJUlFfTUFYX0dVRVNUUwkJNwordHlwZWRl
ZiBzdHJ1Y3QgeworCXVuc2lnbmVkIGludCBhY2tfdHlwZTsKKyAgICAgICAgdW5zaWduZWQg
Y2hhciBucl9ndWVzdHM7CisgICAgICAgIHVuc2lnbmVkIGNoYXIgaW5fZmxpZ2h0OworICAg
ICAgICB1bnNpZ25lZCBjaGFyIHNoYXJlYWJsZTsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
Z3Vlc3RbSVJRX01BWF9HVUVTVFNdOworfSBpcnFfZ3Vlc3RfYWN0aW9uX3Q7CisKK3N0cnVj
dCBpcnFfY2ZnIHsKKwlpbnQgaXJxOworfTsKKworc3RydWN0IGFyY2hfaXJxX2Rlc2Mgewor
fTsKKworc3RydWN0IGFyY2hfcGlycSB7CisJaW50IGlycTsKK307CisKK3R5cGVkZWYgc3Ry
dWN0IHsKKyAgICBERUNMQVJFX0JJVE1BUChfYml0cyxOUl9JUlFTKTsKK30gdm1hc2tfdDsK
KworZXh0ZXJuIHN0cnVjdCBpcnFfZGVzYyAqaXJxX2Rlc2M7CisKK3N0YXRpYyBpbmxpbmUg
aW50IGlycV9kZXNjX2luaXRpYWxpemVkKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykKK3sKKwly
ZXR1cm4gMDsKK30KKworI2VuZGlmIC8qIF9fQVJNX0lSUV9IX18gKi8KZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9tbS5oCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW0u
aAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyMzcgQEAKKyNp
Zm5kZWYgX19BUk1fTU1fSF9fCisjZGVmaW5lIF9fQVJNX01NX0hfXworCisjaW5jbHVkZSA8
eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9saXN0Lmg+CisjaW5jbHVkZSA8YXNtL3Ay
bS5oPgorI2luY2x1ZGUgPGFzbS9pb21tdS5oPgorI2luY2x1ZGUgPGFzbS9tbXUuaD4KKyNp
bmNsdWRlIDxhc20vaW8uaD4KKyNpbmNsdWRlIDxhc20vZmx1c2h0bGIuaD4KKworI2RlZmlu
ZSBJTlZBTElEX0dGTgkJKH4wVUwpCisjZGVmaW5lIElOVkFMSURfTUZOICAgICAgICAgICAg
ICh+MFVMKQorI2RlZmluZSBJTlZBTElEX00yUF9FTlRSWQkofjBVTCkKKworI2RlZmluZSBW
QUxJRF9NMlAoX2UpICAgICAgICAgICAgKCEoKF9lKSAmICgxVUw8PChCSVRTX1BFUl9MT05H
LTEpKSkpCisjZGVmaW5lIFNIQVJFRF9NMlBfRU5UUlkgICAgICAgICAofjBVTCAtIDFVTCkK
KyNkZWZpbmUgU0hBUkVEX00yUChfZSkgICAgICAgICAgICgoX2UpID09IFNIQVJFRF9NMlBf
RU5UUlkpCisKKyNkZWZpbmUgUEZOX09SREVSKF9wZm4pCQkoKF9wZm4pLT52LmZyZWUub3Jk
ZXIpCisKKyNkZWZpbmUgUEFHRV9UWVBFKHBhZ2UpCQkoKChwYWdlKS0+dS5pbnVzZS50eXBl
X2luZm8pICYgUEdUX3R5cGVfbWFzayApCisKKyNkZWZpbmUgcGlja2xlX2RvbXB0cihfZCkJ
KCh1MzIpKHVuc2lnbmVkIGxvbmcpKF9kKSkKKyNkZWZpbmUgdW5waWNrbGVfZG9tcHRyKF9k
KQkoKHN0cnVjdCBkb21haW4gKikodW5zaWduZWQgbG9uZykoX2QpKQorCisjZGVmaW5lIFBS
dHlwZV9pbmZvCQkiMDhseCIKKworI2RlZmluZSBwYWdlX2dldF9vd25lcihfcCkJKHVucGlj
a2xlX2RvbXB0cigoX3ApLT52LmludXNlLl9kb21haW4pKQorI2RlZmluZSBwYWdlX3NldF9v
d25lcihfcCxfZCkJKChfcCktPnYuaW51c2UuX2RvbWFpbiA9IHBpY2tsZV9kb21wdHIoX2Qp
KQorCisjZGVmaW5lIFhFTlNIQVJFX3dyaXRhYmxlIAkwCisjZGVmaW5lIFhFTlNIQVJFX3Jl
YWRvbmx5IAkxCisKKworI2RlZmluZSBQR19zaGlmdChpZHgpCQkoQklUU19QRVJfTE9ORyAt
IChpZHgpKQorI2RlZmluZSBQR19tYXNrKHgsIGlkeCkJCSh4ICMjIFVMIDw8IFBHX3NoaWZ0
KGlkeCkpCisKKyNkZWZpbmUgUEdUX25vbmUJCVBHX21hc2soMCwgNCkgIC8qIG5vIHNwZWNp
YWwgdXNlcyBvZiB0aGlzIHBhZ2UgICAqLworI2RlZmluZSBQR1RfbDFfcGFnZV90YWJsZQlQ
R19tYXNrKDEsIDQpICAvKiB1c2luZyBhcyBhbiBMMSBwYWdlIHRhYmxlPyAgICAgKi8KKyNk
ZWZpbmUgUEdUX2wyX3BhZ2VfdGFibGUJUEdfbWFzaygyLCA0KSAgLyogdXNpbmcgYXMgYW4g
TDIgcGFnZSB0YWJsZT8gICAgICovCisjZGVmaW5lIFBHVF9sM19wYWdlX3RhYmxlCVBHX21h
c2soMywgNCkgIC8qIHVzaW5nIGFzIGFuIEwzIHBhZ2UgdGFibGU/ICAgICAqLworI2RlZmlu
ZSBQR1Rfd3JpdGFibGVfcGFnZQlQR19tYXNrKDcsIDQpICAvKiBoYXMgd3JpdGFibGUgbWFw
cGluZ3M/ICAgICAgICAgKi8KKyNkZWZpbmUgUEdUX3NoYXJlZF9wYWdlCQlQR19tYXNrKDgs
IDQpICAvKiBDb1cgc2hhcmFibGUgcGFnZSAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgUEdU
X3R5cGVfbWFzawkJUEdfbWFzaygxNSwgNCkgLyogQml0cyAyOC0zMSBvciA2MC02My4gICAg
ICAgICAgICovCisKKyAvKiBPd25pbmcgZ3Vlc3QgaGFzIHBpbm5lZCB0aGlzIHBhZ2UgdG8g
aXRzIGN1cnJlbnQgdHlwZT8gKi8KKyNkZWZpbmUgX1BHVF9waW5uZWQJCVBHX3NoaWZ0KDUp
CisjZGVmaW5lIFBHVF9waW5uZWQJCVBHX21hc2soMSwgNSkKKworIC8qIEhhcyB0aGlzIHBh
Z2UgYmVlbiB2YWxpZGF0ZWQgZm9yIHVzZSBhcyBpdHMgY3VycmVudCB0eXBlPyAqLworI2Rl
ZmluZSBfUEdUX3ZhbGlkYXRlZAkJUEdfc2hpZnQoNikKKyNkZWZpbmUgUEdUX3ZhbGlkYXRl
ZAkJUEdfbWFzaygxLCA2KQorCisvKiBIYXMgdGhpcyBwYWdlIGJlZW4gKnBhcnRpYWxseSog
dmFsaWRhdGVkIGZvciB1c2UgYXMgaXRzIGN1cnJlbnQgdHlwZT8gKi8KKyNkZWZpbmUgX1BH
VF9wYXJ0aWFsCQlQR19zaGlmdCg4KQorI2RlZmluZSBQR1RfcGFydGlhbAkJUEdfbWFzaygx
LCA4KQorCisgLyogUGFnZSBpcyBsb2NrZWQ/ICovCisjZGVmaW5lIF9QR1RfbG9ja2VkCQlQ
R19zaGlmdCg5KQorI2RlZmluZSBQR1RfbG9ja2VkCQlQR19tYXNrKDEsIDkpCisKKyAvKiBD
b3VudCBvZiB1c2VzIG9mIHRoaXMgZnJhbWUgYXMgaXRzIGN1cnJlbnQgdHlwZS4gKi8KKyNk
ZWZpbmUgUEdUX2NvdW50X3dpZHRoCQlQR19zaGlmdCg5KQorI2RlZmluZSBQR1RfY291bnRf
bWFzawkJKCgxVUw8PFBHVF9jb3VudF93aWR0aCktMSkKKworIC8qIENsZWFyZWQgd2hlbiB0
aGUgb3duaW5nIGd1ZXN0ICdmcmVlcycgdGhpcyBwYWdlLiAqLworI2RlZmluZSBfUEdDX2Fs
bG9jYXRlZAkJUEdfc2hpZnQoMSkKKyNkZWZpbmUgUEdDX2FsbG9jYXRlZAkJUEdfbWFzaygx
LCAxKQorCisgLyogUGFnZSBpcyBYZW4gaGVhcD8gKi8KKyNkZWZpbmUgX1BHQ194ZW5faGVh
cAkJUEdfc2hpZnQoMikKKyNkZWZpbmUgUEdDX3hlbl9oZWFwCQlQR19tYXNrKDEsIDIpCisK
KyAvKiBTZXQgd2hlbiBpcyB1c2luZyBhIHBhZ2UgYXMgYSBwYWdlIHRhYmxlICovCisjZGVm
aW5lIF9QR0NfcGFnZV90YWJsZQkJUEdfc2hpZnQoMykKKyNkZWZpbmUgUEdDX3BhZ2VfdGFi
bGUJCVBHX21hc2soMSwgMykKKworIC8qIFBhZ2UgaXMgYnJva2VuPyAqLworI2RlZmluZSBf
UEdDX2Jyb2tlbgkJUEdfc2hpZnQoNykKKyNkZWZpbmUgUEdDX2Jyb2tlbgkJUEdfbWFzaygx
LCA3KQorCisgLyogTXV0dWFsbHktZXhjbHVzaXZlIHBhZ2Ugc3RhdGVzOiB7IGludXNlLCBv
ZmZsaW5pbmcsIG9mZmxpbmVkLCBmcmVlIH0uICovCisjZGVmaW5lIFBHQ19zdGF0ZQkJUEdf
bWFzaygzLCA5KQorI2RlZmluZSBQR0Nfc3RhdGVfaW51c2UJCVBHX21hc2soMCwgOSkKKyNk
ZWZpbmUgUEdDX3N0YXRlX29mZmxpbmluZwlQR19tYXNrKDEsIDkpCisjZGVmaW5lIFBHQ19z
dGF0ZV9vZmZsaW5lZAlQR19tYXNrKDIsIDkpCisjZGVmaW5lIFBHQ19zdGF0ZV9mcmVlCQlQ
R19tYXNrKDMsIDkpCisKKyNkZWZpbmUgcGFnZV9zdGF0ZV9pcyhwZywgc3QpCVwKKwkoKChw
ZyktPmNvdW50X2luZm8mUEdDX3N0YXRlKSA9PSBQR0Nfc3RhdGVfIyNzdCkKKworIC8qIENv
dW50IG9mIHJlZmVyZW5jZXMgdG8gdGhpcyBmcmFtZS4gKi8KKyNkZWZpbmUgUEdDX2NvdW50
X3dpZHRoCQlQR19zaGlmdCg5KQorI2RlZmluZSBQR0NfY291bnRfbWFzawkJKCgxVUw8PFBH
Q19jb3VudF93aWR0aCktMSkKKworI2RlZmluZSBzZXRfZ3Bmbl9mcm9tX21mbihtZm4sIHBm
bikgXAorCWRvIHsgfSB3aGlsZSgwKQorCisjZGVmaW5lIGdldF9ncGZuX2Zyb21fbWZuKG1m
bikJKChtZm4pKQorCisjZGVmaW5lIG1mbl90b19nbWZuKF9kLCBtZm4pCShtZm4pCisKKyNk
ZWZpbmUgZ21mbl90b19tZm4oX2QsIGdwZm4pCShncGZuKQorCisjZGVmaW5lIGRvbWFpbl9z
ZXRfYWxsb2NfYml0c2l6ZShkKQkoKHZvaWQpMCkKKyNkZWZpbmUgZG9tYWluX2NsYW1wX2Fs
bG9jX2JpdHNpemUoZCxiKQkoYikKKworI2RlZmluZSB3cml0ZV9wdGJhc2UodikJY3B1X3N3
aXRjaF90dGIoKHYpLT5hcmNoLmN0eC50dGJyMCkKKworc3RydWN0IHBhZ2VfaW5mbworewor
CXN0cnVjdCBwYWdlX2xpc3RfZW50cnkgbGlzdDsKKworCS8qIFJlZmVyZW5jZSBjb3VudCBh
bmQgdmFyaW91cyBQR0NfeHh4IGZsYWdzIGFuZCBmaWVsZHMuICovCisJdW5zaWduZWQgbG9u
ZyBjb3VudF9pbmZvOworCisJLyogQ29udGV4dC1kZXBlbmRlbnQgZmllbGRzIGZvbGxvdy4u
LiAqLworCXVuaW9uIHsKKwkJLyogUGFnZSBpcyBpbiB1c2U6ICgoY291bnRfaW5mbyAmIFBH
Q19jb3VudF9tYXNrKSAhPSAwKS4gKi8KKwkJc3RydWN0IHsKKwkJCS8qIFR5cGUgcmVmZXJl
bmNlIGNvdW50IGFuZCB2YXJpb3VzIFBHVF94eHggZmxhZ3MgYW5kIGZpZWxkcy4gKi8KKwkJ
CXVuc2lnbmVkIGxvbmcgdHlwZV9pbmZvOworCQl9IGludXNlOworCisJCS8qIFBhZ2UgaXMg
b24gYSBmcmVlIGxpc3Q6ICgoY291bnRfaW5mbyAmIFBHQ19jb3VudF9tYXNrKSA9PSAwKS4g
Ki8KKwkJc3RydWN0IHsKKwkJCS8qIERvIFRMQnMgbmVlZCBmbHVzaGluZyBmb3Igc2FmZXR5
IGJlZm9yZSBuZXh0IHBhZ2UgdXNlPyAqLworCQkJYm9vbF90IG5lZWRfdGxiZmx1c2g7CisJ
CX0gZnJlZTsKKwl9IHU7CisKKwl1bmlvbiB7CisJCS8qIFBhZ2UgaXMgaW4gdXNlLCBidXQg
bm90IGFzIGEgc2hhZG93LiAqLworCQlzdHJ1Y3QgeworCQkJLyogT3duZXIgb2YgdGhpcyBw
YWdlICh6ZXJvIGlmIHBhZ2UgaXMgYW5vbnltb3VzKS4gKi8KKwkJCXVuc2lnbmVkIGxvbmcg
X2RvbWFpbjsKKwkJfSBpbnVzZTsKKworCQkvKiBQYWdlIGlzIG9uIGEgZnJlZSBsaXN0LiAq
LworCQlzdHJ1Y3QgeworCQkJLyogT3JkZXItc2l6ZSBvZiB0aGUgZnJlZSBjaHVuayB0aGlz
IHBhZ2UgaXMgdGhlIGhlYWQgb2YuICovCisJCQl1bnNpZ25lZCBpbnQgb3JkZXI7CisJCX0g
ZnJlZTsKKwl9IHY7CisKKwkvKgorCSAqIFRpbWVzdGFtcCBmcm9tICdUTEIgY2xvY2snLCB1
c2VkIHRvIGF2b2lkIGV4dHJhIHNhZmV0eSBmbHVzaGVzLgorCSAqIE9ubHkgdmFsaWQgZm9y
OiBhKSBmcmVlIHBhZ2VzLCBhbmQgYikgcGFnZXMgd2l0aCB6ZXJvIHR5cGUgY291bnQKKwkg
KiAoZXhjZXB0IHBhZ2UgdGFibGUgcGFnZXMgd2hlbiB0aGUgZ3Vlc3QgaXMgaW4gc2hhZG93
IG1vZGUpLgorCSAqLworCXUzMiB0bGJmbHVzaF90aW1lc3RhbXA7Cit9OworCisjaWZuZGVm
IE5ERUJVRworI2RlZmluZSBUWVBFX1NBRkVUWSAxCisjZW5kaWYKKworI2lmZGVmIFRZUEVf
U0FGRVRZCisjZGVmaW5lIFRZUEVfU0FGRShfdHlwZSxfbmFtZSkJCQkJCQlcCit0eXBlZGVm
IHN0cnVjdCB7IF90eXBlIF9uYW1lOyB9IF9uYW1lIyNfdDsJCQkJXAorc3RhdGljIGlubGlu
ZSBfbmFtZSMjX3QgXyMjX25hbWUoX3R5cGUgbikgeyByZXR1cm4gKF9uYW1lIyNfdCkgeyBu
IH07IH0gXAorc3RhdGljIGlubGluZSBfdHlwZSBfbmFtZSMjX3goX25hbWUjI190IG4pIHsg
cmV0dXJuIG4uX25hbWU7IH0KKyNlbHNlCisjZGVmaW5lIFRZUEVfU0FGRShfdHlwZSxfbmFt
ZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCit0eXBlZGVm
IF90eXBlIF9uYW1lIyNfdDsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCitzdGF0aWMgaW5saW5lIF9uYW1lIyNfdCBfIyNfbmFtZShfdHlwZSBu
KSB7IHJldHVybiBuOyB9ICAgICAgICAgICAgICAgICBcCitzdGF0aWMgaW5saW5lIF90eXBl
IF9uYW1lIyNfeChfbmFtZSMjX3QgbikgeyByZXR1cm4gbjsgfQorI2VuZGlmCisKK1RZUEVf
U0FGRSh1bnNpZ25lZCBsb25nLG1mbik7CisKKyNpZmRlZiBNRU1PUllfR1VBUkQKK3ZvaWQg
bWVtZ3VhcmRfaW5pdCh2b2lkKTsKK3ZvaWQgbWVtZ3VhcmRfZ3VhcmRfcmFuZ2Uodm9pZCAq
cCwgdW5zaWduZWQgbG9uZyBsKTsKK3ZvaWQgbWVtZ3VhcmRfdW5ndWFyZF9yYW5nZSh2b2lk
ICpwLCB1bnNpZ25lZCBsb25nIGwpOworI2Vsc2UKKyNkZWZpbmUgbWVtZ3VhcmRfaW5pdCgp
ICAgICAgICAgICAgICAgICgodm9pZCkwKQorI2RlZmluZSBtZW1ndWFyZF9ndWFyZF9yYW5n
ZShfcCxfbCkgICAgKCh2b2lkKTApCisjZGVmaW5lIG1lbWd1YXJkX3VuZ3VhcmRfcmFuZ2Uo
X3AsX2wpICAoKHZvaWQpMCkKKyNlbmRpZiAvKiBNRU1PUllfR1VBUkQgKi8KKworZXh0ZXJu
IHVuc2lnbmVkIGxvbmcgeGVuaGVhcF9waHlzX3N0YXJ0LCB4ZW5oZWFwX3BoeXNfZW5kOwor
ZXh0ZXJuIHVuc2lnbmVkIGxvbmcgeGVuX3BoeXNfc3RhcnQsIHhlbl9waHlzX2VuZDsKK2V4
dGVybiB1bnNpZ25lZCBsb25nIG1pbl9wYWdlLCBtYXhfcGFnZTsKKworZXh0ZXJuIHN0cnVj
dCBkb21haW4gKmRvbV94ZW4sICpkb21faW8sICpkb21fY293OworZXh0ZXJuIHN0cnVjdCBw
YWdlX2luZm8gKmZyYW1lX3RhYmxlOworCit2b2lkIG1lbWd1YXJkX2d1YXJkX3N0YWNrKHZv
aWQgKnApOworCit2b2lkIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2Vf
aW5mbyAqcGFnZSwgc3RydWN0IGRvbWFpbiAqZCwgaW50IHJlYWRvbmx5KTsKK3ZvaWQgc2hh
cmVfeGVuX3BhZ2Vfd2l0aF9wcml2aWxlZ2VkX2d1ZXN0cyhzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlLCBpbnQgcmVhZG9ubHkpOworCitpbnQgYWxsb2NfcGFnZV90eXBlKHN0cnVjdCBwYWdl
X2luZm8gKnBhZ2UsIHVuc2lnbmVkIGxvbmcgdHlwZSk7Cit2b2lkIGZyZWVfcGFnZV90eXBl
KHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHVuc2lnbmVkIGxvbmcgdHlwZSk7CisKK3ZvaWQg
cHV0X3BhZ2Uoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSk7CitpbnQgIGdldF9wYWdlKHN0cnVj
dCBwYWdlX2luZm8gKnBhZ2UsIHN0cnVjdCBkb21haW4gKmRvbWFpbik7CisKK3ZvaWQgcHV0
X3BhZ2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKK2ludCAgZ2V0X3BhZ2VfdHlw
ZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCB1bnNpZ25lZCBsb25nIHR5cGUpOworCitzdHJ1
Y3QgZG9tYWluICpwYWdlX2dldF9vd25lcl9hbmRfcmVmZXJlbmNlKHN0cnVjdCBwYWdlX2lu
Zm8gKnBhZ2UpOworCitpbnQgaXNfaW9tZW1fcGFnZSh1bnNpZ25lZCBsb25nIG1mbik7CisK
K2ludCBzdGVhbF9wYWdlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwYWdlX2luZm8gKnBh
Z2UsIHVuc2lnbmVkIGludCBtZW1mbGFncyk7CitpbnQgZG9uYXRlX3BhZ2Uoc3RydWN0IGRv
bWFpbiAqZCwgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgdW5zaWduZWQgaW50IG1lbWZsYWdz
KTsKKwordW5zaWduZWQgbG9uZyBkb21haW5fZ2V0X21heGltdW1fZ3BmbihzdHJ1Y3QgZG9t
YWluICpkKTsKKworbG9uZyBhcmNoX21lbW9yeV9vcChpbnQgb3AsIFhFTl9HVUVTVF9IQU5E
TEUodm9pZCkgYXJnKTsKKworaW50IG1hcF9wYWdlc190b194ZW4odW5zaWduZWQgbG9uZyB2
aXJ0LCB1bnNpZ25lZCBsb25nIG1mbiwgaW50IG5yLCB1bnNpZ25lZCBsb25nIGZsYWdzKTsK
Kworc3RhdGljIGlubGluZSB2b2lkIHB1dF9wYWdlX2FuZF90eXBlKHN0cnVjdCBwYWdlX2lu
Zm8gKnBhZ2UpCit7CisJcHV0X3BhZ2VfdHlwZShwYWdlKTsKKwlwdXRfcGFnZShwYWdlKTsK
K30KKworc3RhdGljIGlubGluZSBpbnQgZ2V0X3BhZ2VfYW5kX3R5cGUoc3RydWN0IHBhZ2Vf
aW5mbyAqcGFnZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVj
dCBkb21haW4gKmRvbWFpbiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHVuc2lnbmVkIGxvbmcgdHlwZSkKK3sKKwlpbnQgcmMgPSBnZXRfcGFnZShwYWdlLCBkb21h
aW4pOworCisJaWYgKCBsaWtlbHkocmMpICYmIHVubGlrZWx5KCFnZXRfcGFnZV90eXBlKHBh
Z2UsIHR5cGUpKSApIHsKKwkJcHV0X3BhZ2UocGFnZSk7CisJCXJjID0gMDsKKwl9CisKKwly
ZXR1cm4gcmM7Cit9CisKKyNlbmRpZiAvKiBfX0FSTV9NTV9IX18gKi8KZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaAotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL21t
dS5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDExIEBACisj
aWZuZGVmIF9fQVJNX01NVV9IX18KKyNkZWZpbmUgX19BUk1fTU1VX0hfXworCisjZGVmaW5l
IFBBRERSX0JJVFMgICAgICAgICAgICAgIDMyCisjZGVmaW5lIFBBRERSX01BU0sgICAgICAg
ICAgICAgICgoMVVMIDw8IFBBRERSX0JJVFMpIC0gMSkKKworI2RlZmluZSBWQUREUl9CSVRT
ICAgICAgICAgICAgICAzMgorI2RlZmluZSBWQUREUl9NQVNLICAgICAgICAgICAgICAoKDFV
TCA8PCBWQUREUl9CSVRTKSAtIDEpCisKKyNlbmRpZgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUx
IHhlbi9pbmNsdWRlL2FzbS1hcm0vbXVsdGljYWxsLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9tdWx0
aWNhbGwuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw5IEBA
CisKKyNpZm5kZWYgX19BUk1fTVVMVElDQUxMX0hfXworI2RlZmluZSBfX0FSTV9NVUxUSUNB
TExfSF9fCisKKyNpbmNsdWRlIDx4ZW4vZXJybm8uaD4KKworI2RlZmluZSBkb19tdWx0aWNh
bGxfY2FsbChfY2FsbCkKKworI2VuZGlmIC8qIF9fQVJNX01VTFRJQ0FMTF9IX18gKi8KZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9udW1hLmgKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUv
YXNtLWFybS9udW1hLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAg
KzEsMjEgQEAKKyNpZm5kZWYgX19BUk1fTlVNQV9IX18gCisjZGVmaW5lIF9fQVJNX05VTUFf
SF9fCisKKyNpbmNsdWRlIDx4ZW4vY3B1bWFzay5oPgorCisjZGVmaW5lIE5PREVTX1NISUZU
IAkwCisjZGVmaW5lIE1BWF9OVU1OT0RFUwkoMSA8PCBOT0RFU19TSElGVCkKKworCisjZGVm
aW5lIE5VTUFfTk9fTk9ERQkweEZGCisKK2V4dGVybiB1bnNpZ25lZCBjaGFyIGNwdV90b19u
b2RlW107CitleHRlcm4gY3B1bWFza190ICAgICBub2RlX3RvX2NwdW1hc2tbXTsKKworI2Rl
ZmluZSBjcHVfdG9fbm9kZShjcHUpCShjcHVfdG9fbm9kZVtjcHVdKQorI2RlZmluZSBwYXJl
bnRfbm9kZShub2RlKQkobm9kZSkKKyNkZWZpbmUgbm9kZV90b19maXJzdF9jcHUobm9kZSkJ
KF9fZmZzKG5vZGVfdG9fY3B1bWFza1tub2RlXSkpCisjZGVmaW5lIG5vZGVfdG9fY3B1bWFz
ayhub2RlKQkobm9kZV90b19jcHVtYXNrW25vZGVdKQorCisjZGVmaW5lIHBoeXNfdG9fbmlk
KGFkZHIpCSgwKQorI2VuZGlmCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vcDJtLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9wMm0uaAlGcmkgRmViIDAzIDE2OjA3OjAz
IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMCBAQAorI2lmbmRlZiBfX0FSTV9QMk1fSF9fCisj
ZGVmaW5lIF9fQVJNX1AyTV9IX18KKworI2RlZmluZSBnZm5fdG9fbWZuKGQsIGcsIHQpCQko
ZykKKyNkZWZpbmUgZ2ZuX3RvX21mbl9xdWVyeShkLCBnLCB0KQkoZykKKyNkZWZpbmUgZ2Zu
X3RvX21mbl9ndWVzdChkLCBnLCB0KQkoZykKKyNkZWZpbmUgZ2ZuX3RvX21mbl91bnNoYXJl
KGQsIGcsIHQpCShnKQorCisjZGVmaW5lIHB1dF9nZm4oZCwgZ2ZuKQorI2VuZGlmCmRpZmYg
LXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vcGFnZS5oCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS1hcm0vcGFnZS5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsx
LDk1IEBACisjaWZuZGVmIF9fQVJNX1BBR0VfSF9fCisjZGVmaW5lIF9fQVJNX1BBR0VfSF9f
CisKKyNpbmNsdWRlIDxhc20vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL3R5cGVzLmg+CisK
KyNkZWZpbmUgUEFHRV9TSElGVAkJMTIKKyNkZWZpbmUgUEFHRV9TSVpFCQkoMSA8PCBQQUdF
X1NISUZUKQorI2RlZmluZSBQQUdFX01BU0sJCSh+KFBBR0VfU0laRSAtIDEpKQorCisjZGVm
aW5lIFBBR0VfQUxJR04oeCkJCSgoKHgpICsgUEFHRV9TSVpFIC0gMSkgJiBQQUdFX01BU0sp
CisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCisjaW5jbHVkZSA8eGVuL2xpYi5oPgorCisjZGVm
aW5lIGNsZWFyX3BhZ2UoX3ApCQltZW1zZXQoKHZvaWQgKikoX3ApLCAwLCBQQUdFX1NJWkUp
CisjZGVmaW5lIGNvcHlfcGFnZShfdCwgX2YpCW1lbWNweSgodm9pZCAqKShfdCksICh2b2lk
ICopKF9mKSwgUEFHRV9TSVpFKTsKKworc3RhdGljIGlubGluZSBpbnQgZ2V0X29yZGVyX2Zy
b21fYnl0ZXModW5zaWduZWQgbG9uZyBzaXplKQoreworCWludCBvcmRlcjsKKworCXNpemUg
PSAoc2l6ZSAtIDEpID4+IFBBR0VfU0hJRlQ7CisJZm9yICggb3JkZXIgPSAwOyBzaXplOyBv
cmRlcisrICkKKwkJc2l6ZSA+Pj0gMTsKKworCXJldHVybiBvcmRlcjsKK30KKworc3RhdGlj
IGlubGluZSBpbnQgZ2V0X29yZGVyX2Zyb21fcGFnZXModW5zaWduZWQgbG9uZyBucl9wYWdl
cykKK3sKKwlpbnQgb3JkZXI7CisKKwlucl9wYWdlcy0tOworCWZvciAoIG9yZGVyID0gMDsg
bnJfcGFnZXM7IG9yZGVyKysgKQorCQlucl9wYWdlcyA+Pj0gMTsKKworCXJldHVybiBvcmRl
cjsKK30KKworLyogQ29udmVydCBiZXR3ZWVuIFhlbi1oZWFwIHZpcnR1YWwgYWRkcmVzc2Vz
IGFuZCBtYWNoaW5lIGFkZHJlc3Nlcy4gKi8KKworI2RlZmluZSB2aXJ0X3RvX21hZGRyKGFk
ZHIpCV9fdmlydF90b19tYWRkcigodm9pZCAqKShhZGRyKSkKKyNkZWZpbmUgbWFkZHJfdG9f
dmlydChhZGRyKQlfX21hZGRyX3RvX3ZpcnQoKHBhZGRyX3QpKGFkZHIpKQorCisjZGVmaW5l
IHZpcnRfdG9fbWZuKGFkZHIpCSh2aXJ0X3RvX21hZGRyKGFkZHIpID4+IFBBR0VfU0hJRlQp
CisKKyNkZWZpbmUgdmlydF90b19wYWdlKGFkZHIpCShtZm5fdG9fcGFnZSh2aXJ0X3RvX21h
ZGRyKGFkZHIpID4+IFBBR0VfU0hJRlQpKQorI2RlZmluZSBwYWdlX3RvX3ZpcnQoX3BhZ2Up
CW1hZGRyX3RvX3ZpcnQocGFnZV90b19tZm4oX3BhZ2UpIDw8IFBBR0VfU0hJRlQpCisKKyNk
ZWZpbmUgX19wYShhZGRyKQkJKHZpcnRfdG9fbWFkZHIoYWRkcikpCisjZGVmaW5lIF9fdmEo
YWRkcikJCShtYWRkcl90b192aXJ0KGFkZHIpKQorCisKKyNkZWZpbmUgbWZuX3ZhbGlkKF9w
Zm4pCQkoKChfcGZuKSA+PSBtaW5fcGFnZSkgJiYgKChfcGZuKSA8PSBtYXhfcGFnZSkpCisK
KyNkZWZpbmUgbWZuX3RvX3BhZ2UoX3BmbikJKChzdHJ1Y3QgcGFnZV9pbmZvICopKGZyYW1l
X3RhYmxlICsgKChfcGZuKSAtIG1pbl9wYWdlKSkpCisjZGVmaW5lIHBhZ2VfdG9fbWZuKF9w
YWdlKQkoKHVuc2lnbmVkIGxvbmcpKChfcGFnZSArIG1pbl9wYWdlKSAtIGZyYW1lX3RhYmxl
ICkpCisjZGVmaW5lIHBhZ2VfdG9fbWFkZHIoX3BhZ2UpCShwYWdlX3RvX21mbihfcGFnZSkg
PDwgUEFHRV9TSElGVCkKKyNkZWZpbmUgbWFkZHJfdG9fcGFnZShhZGRyKQltZm5fdG9fcGFn
ZSgoYWRkciA+PiBQQUdFX1NISUZUKSkKKworI2RlZmluZSBtZm5fdG9fdmlydChfbWZuKQko
bWFkZHJfdG9fdmlydCgoKF9tZm4pIDw8IFBBR0VfU0hJRlQpKSkKKworI2RlZmluZSBwYWRk
cl90b19wZm4oYWRkcikJKCh1bnNpZ25lZCBsb25nKSgoYWRkcikgPj4gUEFHRV9TSElGVCkp
CisKKyNkZWZpbmUgaXNfeGVuX2hlYXBfbWZuKF9wZm4pCQkJXAorKHsJCQkJCQlcCisJdW5z
aWduZWQgbG9uZyBwaHlzOwkJCVwKKwlwaHlzID0gKF9wZm4pIDw8IFBBR0VfU0hJRlQ7CQlc
CisJKChwaHlzID49IHhlbmhlYXBfcGh5c19zdGFydCkgJiYJXAorCSAocGh5cyA8IHhlbmhl
YXBfcGh5c19lbmQpKTsJCVwKK30pCisKKyNkZWZpbmUgaXNfeGVuX2hlYXBfcGFnZShwYWdl
KSAgICAgICAgICAgICAgICAgIFwKKwlpc194ZW5faGVhcF9tZm4ocGFnZV90b19tZm4ocGFn
ZSkpCisKKyNkZWZpbmUgaXNfeGVuX2ZpeGVkX21mbihfbWZuKQkJCVwKKwlpc194ZW5faGVh
cF9tZm4oX21mbikKKworZXh0ZXJuIHVuc2lnbmVkIGxvbmcgeGVuX3BoeXNfc3RhcnQ7Citz
dGF0aWMgaW5saW5lIHBhZGRyX3QgX192aXJ0X3RvX21hZGRyKHZvaWQgKmFkZHIpCit7CisJ
cmV0dXJuIChwYWRkcl90KShhZGRyKSAtIFhFTl9WSVJUX1NUQVJUICsgeGVuX3BoeXNfc3Rh
cnQ7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCAqX19tYWRkcl90b192aXJ0KHVuc2lnbmVk
IGxvbmcgYWRkcikKK3sKKwlyZXR1cm4gKHZvaWQgKikoKGFkZHIpICsgWEVOX1ZJUlRfU1RB
UlQgLSB4ZW5fcGh5c19zdGFydCk7Cit9CisKKyNkZWZpbmUgX19wYWdlX2FsaWduZWRfXyBc
CisgICAgX19hdHRyaWJ1dGVfdXNlZF9fIF9fYXR0cmlidXRlX18gKChfX3NlY3Rpb25fXyAo
Ii5ic3MucGFnZV9hbGlnbmVkIikpKQorCisjZW5kaWYgLyogIV9fQVNTRU1CTFlfXyAqLwor
I2VuZGlmIC8qIF9fQVJNX1BBR0VfSF9fICovCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9p
bmNsdWRlL2FzbS1hcm0vcGNpLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9wY2kuaAlGcmkgRmViIDAz
IDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw5IEBACisjaWZuZGVmIF9fQVNNX1BD
SV9IX18KKyNkZWZpbmUgX19BU01fUENJX0hfXworCitzdHJ1Y3QgYXJjaF9wY2lfZGV2IHsK
K307CisKKworI2VuZGlmCisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNt
LWFybS9wZXJjcHUuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3BlcmNwdS5oCUZyaSBGZWIgMDMgMTY6
MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDE2IEBACisjaWZuZGVmIF9fQVJNX1BFUkNQ
VV9IX18KKyNkZWZpbmUgX19BUk1fUEVSQ1BVX0hfXworCisjaWZuZGVmIF9fQVNTRU1CTFlf
XworI2RlZmluZSBfX0RFRklORV9QRVJfQ1BVKHR5cGUsIG5hbWUsIHN1ZmZpeCkgXAorCV9f
dHlwZW9mX18odHlwZSkgcGVyX2NwdV8jI25hbWVbTlJfQ1BVU10gPSB7MCx9CisKKyNkZWZp
bmUgREVDTEFSRV9QRVJfQ1BVKHR5cGUsIG5hbWUpIFwKKwlleHRlcm4gX190eXBlb2ZfXyh0
eXBlKSBwZXJfY3B1X18jI25hbWVbTlJfQ1BVU10KKworI2RlZmluZSBwZXJfY3B1KHZhciwg
Y3B1KQkocGVyX2NwdV9fIyN2YXJbY3B1XSkKKworI2RlZmluZSBfX2dldF9jcHVfdmFyKHZh
cikJcGVyX2NwdSh2YXIsIHNtcF9wcm9jZXNzb3JfaWQoKSkKKworI2VuZGlmIC8qICFfX0FT
U0VNQkxZICovCisjZW5kaWYgLyogIV9fQVJNX1BFUkNQVV9IX18gKi8KZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
YXJtL3Byb2Nlc3Nvci5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCww
ICsxLDIxOSBAQAorLyoKKyAqICBwcm9jZXNzb3IuaAorICoKKyAqIENvcHlyaWdodCAoQykg
MjAwOCBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBKYWVNaW4gUnl1ICA8am03
Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNl
bnNlIGFzIHB1Ymxpc2hlZCBieQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4K
KyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBp
dCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91
dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorICoKKyAqIFlvdSBzaG91
bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUg
RnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBT
dWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQorICovCisjaWZuZGVmIF9f
QVJNX1BST0NFU1NPUl9IX18KKyNkZWZpbmUgX19BUk1fUFJPQ0VTU09SX0hfXworCisvKgor
ICogUFNSIGJpdHMKKyAqLworI2RlZmluZSBQU1JfTU9ERV9VU1IgICAgICAgICAgICAweDAw
MDAwMDEwCisjZGVmaW5lIFBTUl9NT0RFX0ZJUSAgICAgICAgICAgIDB4MDAwMDAwMTEKKyNk
ZWZpbmUgUFNSX01PREVfSVJRICAgICAgICAgICAgMHgwMDAwMDAxMgorI2RlZmluZSBQU1Jf
TU9ERV9TVkMgICAgICAgICAgICAweDAwMDAwMDEzCisjZGVmaW5lIFBTUl9NT0RFX0FCVCAg
ICAgICAgICAgIDB4MDAwMDAwMTcKKyNkZWZpbmUgUFNSX01PREVfVU5EICAgICAgICAgICAg
MHgwMDAwMDAxYgorI2RlZmluZSBQU1JfTU9ERV9TWVMgICAgICAgICAgICAweDAwMDAwMDFm
CisjZGVmaW5lIFBTUl9NT0RFX01BU0sgICAgICAgICAgIDB4MDAwMDAwMWYKKyNkZWZpbmUg
UFNSX1RfQklUICAgICAgICAgICAgICAgMHgwMDAwMDAyMAorI2RlZmluZSBQU1JfRl9CSVQg
ICAgICAgICAgICAgICAweDAwMDAwMDQwCisjZGVmaW5lIFBTUl9JX0JJVCAgICAgICAgICAg
ICAgIDB4MDAwMDAwODAKKyNkZWZpbmUgUFNSX0pfQklUICAgICAgICAgICAgICAgMHgwMTAw
MDAwMAorI2RlZmluZSBQU1JfUV9CSVQgICAgICAgICAgICAgICAweDA4MDAwMDAwCisjZGVm
aW5lIFBTUl9WX0JJVCAgICAgICAgICAgICAgIDB4MTAwMDAwMDAKKyNkZWZpbmUgUFNSX0Nf
QklUICAgICAgICAgICAgICAgMHgyMDAwMDAwMAorI2RlZmluZSBQU1JfWl9CSVQgICAgICAg
ICAgICAgICAweDQwMDAwMDAwCisjZGVmaW5lIFBTUl9OX0JJVCAgICAgICAgICAgICAgIDB4
ODAwMDAwMDAKKworLyoKKworICogR3JvdXBzIG9mIFBTUiBiaXRzCisgKi8KKyNkZWZpbmUg
UFNSX01BU0tfRkxBR1MgICAgICAgICAgMHhmZjAwMDAwMCAgICAgIC8qIEZsYWdzICAgICAg
ICAgICAgICAgICovCisjZGVmaW5lIFBTUl9NQVNLX1NUQVRVUyAgICAgICAgIDB4MDBmZjAw
MDAgICAgICAvKiBTdGF0dXMgICAgICAgICAgICAgICAqLworI2RlZmluZSBQU1JfTUFTS19F
WFRFTlNJT04gICAgICAweDAwMDBmZjAwICAgICAgLyogRXh0ZW5zaW9uICAgICAgICAgICAg
Ki8KKyNkZWZpbmUgUFNSX01BU0tfQ09OVFJPTCAgICAgICAgMHgwMDAwMDBmZiAgICAgIC8q
IENvbnRyb2wgICAgICAgICAgICAgICovCisKKworI2RlZmluZSBNSURSKHIpCQlwMTUsIDAs
IHIsICBjMCwgYzAsIDAKKyNkZWZpbmUgQ1RSKHIpCQlwMTUsIDAsIHIsICBjMCwgYzAsIDEK
KyNkZWZpbmUgVENNVFIocikJcDE1LCAwLCByLCAgYzAsIGMwLCAyCisjZGVmaW5lIFRMQlRS
KHIpCXAxNSwgMCwgciwgIGMwLCBjMCwgMworI2RlZmluZSBNUElEUihyKQlwMTUsIDAsIHIs
ICBjMCwgYzAsIDUKKyNkZWZpbmUgU0NUTFIocikJcDE1LCAwLCByLCAgYzEsIGMwLCAwCisj
ZGVmaW5lIEFDVExSKHIpCXAxNSwgMCwgciwgIGMxLCBjMCwgMQorI2RlZmluZSBTQ1IocikJ
CXAxNSwgMCwgciwgIGMxLCBjMSwgMAorI2RlZmluZSBTREVSKHIpCQlwMTUsIDAsIHIsICBj
MSwgYzEsIDEKKyNkZWZpbmUgTlNBQ1IocikJcDE1LCAwLCByLCAgYzEsIGMxLCAyCisjZGVm
aW5lIFRUQlIwKHIpCXAxNSwgMCwgciwgIGMyLCBjMCwgMAorI2RlZmluZSBUVEJSMShyKQlw
MTUsIDAsIHIsICBjMiwgYzAsIDEKKyNkZWZpbmUgVFRCQ1IocikJcDE1LCAwLCByLCAgYzIs
IGMwLCAyCisjZGVmaW5lIERBQ1IocikJCXAxNSwgMCwgciwgIGMzLCBjMCwgMAorI2RlZmlu
ZSBERlNSKHIpCQlwMTUsIDAsIHIsICBjNSwgYzAsIDAKKyNkZWZpbmUgSUZTUihyKQkJcDE1
LCAwLCByLCAgYzUsIGMwLCAxCisjZGVmaW5lIERGQVIocikJCXAxNSwgMCwgciwgIGM2LCBj
MCwgMAorI2RlZmluZSBJRkFSKHIpCQlwMTUsIDAsIHIsICBjNiwgYzAsIDIKKyNkZWZpbmUg
VkJBUihyKQkJcDE1LCAwLCByLCBjMTIsIGMwLCAwCisjZGVmaW5lIE1WQkFSKHIpCXAxNSwg
MCwgciwgYzEyLCBjMCwgMQorLyoKKyAqIFN5c3RlbSBDb250cm9sIFJlZ2lzdGVyCisgKi8K
KyNkZWZpbmUgU0NUTFJfTSAgICAgICAgICgxIDw8IDApICAvKiBNTVUgZW5hYmxlICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfQSAgICAgICAgICgxIDw8
IDEpICAvKiBBbGlnbm1lbnQgYWJvcnQgZW5hYmxlICAgICAgICAgICAgICAgKi8KKyNkZWZp
bmUgU0NUTFJfQyAgICAgICAgICgxIDw8IDIpICAvKiBEY2FjaGUgZW5hYmxlICAgICAgICAg
ICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfVyAgICAgICAgICgxIDw8IDMpICAv
KiBXcml0ZSBidWZmZXIgZW5hYmxlICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NU
TFJfUCAgICAgICAgICgxIDw8IDQpICAvKiAzMi1iaXQgZXhjZXB0aW9uIGhhbmRsZXIgICAg
ICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfRCAgICAgICAgICgxIDw8IDUpICAvKiAzMi1i
aXQgZGF0YSBhZGRyZXNzIHJhbmdlICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfTCAg
ICAgICAgICgxIDw8IDYpICAvKiBJbXBsZW1lbnRhdGlvbiBkZWZpbmVkICAgICAgICAgICAg
ICAgKi8KKyNkZWZpbmUgU0NUTFJfQiAgICAgICAgICgxIDw8IDcpICAvKiBCaWcgZW5kaWFu
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfUyAgICAgICAg
ICgxIDw8IDgpICAvKiBTeXN0ZW0gTU1VIHByb3RlY3Rpb24gICAgICAgICAgICAgICAgKi8K
KyNkZWZpbmUgU0NUTFJfUiAgICAgICAgICgxIDw8IDkpICAvKiBST00gTU1VIHByb3RlY3Rp
b24gICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfU1cgICAgICAgICgxIDw8
IDEwKSAvKiBJbXBsZW1lbnRhdGlvbiBkZWZpbmVkICAgICAgICAgICAgICAgKi8KKyNkZWZp
bmUgU0NUTFJfWiAgICAgICAgICgxIDw8IDExKSAvKiBJbXBsZW1lbnRhdGlvbiBkZWZpbmVk
ICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfSSAgICAgICAgICgxIDw8IDEyKSAv
KiBJY2FjaGUgZW5hYmxlICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NU
TFJfViAgICAgICAgICgxIDw8IDEzKSAvKiBWZWN0b3JzIHJlbG9jYXRlZCB0byAweGZmZmYw
MDAwICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfUlIgICAgICAgICgxIDw8IDE0KSAvKiBSb3Vu
ZCBSb2JpbiBjYWNoZSByZXBsYWNlbWVudCAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfTDQg
ICAgICAgICgxIDw8IDE1KSAvKiBMRFIgcGMgY2FuIHNldCBUIGJpdCAgICAgICAgICAgICAg
ICAgKi8KKyNkZWZpbmUgU0NUTFJfRFQgICAgICAgICgxIDw8IDE2KQorI2RlZmluZSBTQ1RM
Ul9JVCAgICAgICAgKDEgPDwgMTgpCisjZGVmaW5lIFNDVExSX1NUICAgICAgICAoMSA8PCAx
OSkKKyNkZWZpbmUgU0NUTFJfRkkgICAgICAgICgxIDw8IDIxKSAvKiBGYXN0IGludGVycnVw
dCAobG93ZXIgbGF0ZW5jeSBtb2RlKSAgKi8KKyNkZWZpbmUgU0NUTFJfVSAgICAgICAgICgx
IDw8IDIyKSAvKiBVbmFsaWduZWQgYWNjZXNzIG9wZXJhdGlvbiAgICAgICAgICAgKi8KKyNk
ZWZpbmUgU0NUTFJfWFAgICAgICAgICgxIDw8IDIzKSAvKiBFeHRlbmRlZCBwYWdlIHRhYmxl
cyAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfVkUgICAgICAgICgxIDw8IDI0
KSAvKiBWZWN0b3JlZCBpbnRlcnJ1cHRzICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUg
U0NUTFJfRUUgICAgICAgICgxIDw8IDI1KSAvKiBFeGNlcHRpb24gZW5kaWFuZXNzICAgICAg
ICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfTk1GSSAgICAgICgxIDw8IDI3KSAvKiBO
b25tYXNrYWJsZSBmYXN0IGludGVycnVwdCBlbmFibGUgICAgKi8KKyNkZWZpbmUgU0NUTFJf
VFJFICAgICAgICgxIDw8IDI4KSAvKiBURVggcmVtYXAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfQUZFICAgICAgICgxIDw8IDI5KSAvKiBBY2Nlc3Mg
ZmxhZyBlbmFibGUgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfVEUgICAg
ICAgICgxIDw8IDMwKSAvKiBUaHVtYiBleGNlcHRpb24gZW5hYmxlICAgICAgICAgICAgICAg
Ki8KKworLyoKKyAqIENvLVByb2Nlc3NvciBBY2Nlc3MgUmVnaXN0ZXIKKyAqLworI2RlZmlu
ZSBDUEFSX0JJVF9DUDAgICAgKDEgPDwgMCkKKyNkZWZpbmUgQ1BBUl9CSVRfQ1AxICAgICgx
IDw8IDEpCisjZGVmaW5lIENQQVJfQklUX0NQMiAgICAoMSA8PCAyKQorI2RlZmluZSBDUEFS
X0JJVF9DUDMgICAgKDEgPDwgMykKKyNkZWZpbmUgQ1BBUl9CSVRfQ1A0ICAgICgxIDw8IDQp
CisjZGVmaW5lIENQQVJfQklUX0NQNSAgICAoMSA8PCA1KQorI2RlZmluZSBDUEFSX0JJVF9D
UDYgICAgKDEgPDwgNikKKyNkZWZpbmUgQ1BBUl9CSVRfQ1A3ICAgICgxIDw8IDcpCisjZGVm
aW5lIENQQVJfQklUX0NQOCAgICAoMSA8PCA4KQorI2RlZmluZSBDUEFSX0JJVF9DUDkgICAg
KDEgPDwgOSkKKyNkZWZpbmUgQ1BBUl9CSVRfQ1AxMCAgICgxIDw8IDEwKQorI2RlZmluZSBD
UEFSX0JJVF9DUDExICAgKDEgPDwgMTEpCisjZGVmaW5lIENQQVJfQklUX0NQMTIgICAoMSA8
PCAxMikKKyNkZWZpbmUgQ1BBUl9CSVRfQ1AxMyAgICgxIDw8IDEzKQorCisvKgorICogQXV4
aWxpYXJ5IENvbnRyb2wgUmVnaXN0ZXIKKyAqLworI2RlZmluZSBBQ1RMUl9GVyAgICAgICAg
KDEgPDwgMCkgIC8qIENhY2hlIGFuZCBUTEIgbWFpbnRlbmFuY2UgYnJvYWRjYXN0ICAqLwor
I2RlZmluZSBBQ1RMUl9EUDIgICAgICAgKDEgPDwgMSkgIC8qIEwyIERzaWRlIHByZWZldGNo
ICAgICAgICAgICAgICAgICAgICAqLworI2RlZmluZSBBQ1RMUl9EUDEgICAgICAgKDEgPDwg
MikgIC8qIEwxIERzaWRlIHByZWZldGNoICAgICAgICAgICAgICAgICAgICAqLworI2RlZmlu
ZSBBQ1RMUl9GT1ogICAgICAgKDEgPDwgMykgIC8qIEZ1bGwgb2YgemVybyAgICAgICAgICAg
ICAgICAgICAgICAgICAqLworI2RlZmluZSBBQ1RMUl9TTVAgICAgICAgKDEgPDwgNikgIC8q
IFNNUC9uQU1QICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworI2RlZmluZSBBQ1RM
Ul9FWENMICAgICAgKDEgPDwgNykgIC8qIEV4Y2x1c2l2ZSBjYWNoZSBlbmFibGUgICAgICAg
ICAgICAgICAqLworI2RlZmluZSBBQ1RMUl9QQVJPTiAgICAgKDEgPDwgOSkgIC8qIFBhcml0
eSBvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworCisvKgorICogU2VjdXJlIENv
bmZpZ3VyYXRpb24gUmVnaXN0ZXIKKyAqLworI2RlZmluZSBTQ1JfTlMgICAgICAgICAgKDEg
PDwgMCkgIC8qIE5vbi1zZWN1cmUgbW9kZSAgICAgICAgICAgICAgICAgICAgICAqLworI2Rl
ZmluZSBTQ1JfSVJRICAgICAgICAgKDEgPDwgMSkgIC8qIElSUSBleGNlcHRpb24gaGFuZGxp
bmcgbW9kZSAgICAgICAgICAqLworI2RlZmluZSBTQ1JfRklRICAgICAgICAgKDEgPDwgMikg
IC8qIEZJUSBleGNlcHRpb24gaGFuZGxpbmcgbW9kZSAgICAgICAgICAqLworI2RlZmluZSBT
Q1JfRUEgICAgICAgICAgKDEgPDwgMykgIC8qIEV4dGVybmFsIGV4Y2VwdGlvbiBoYW5kbGlu
ZyBtb2RlICAgICAqLworI2RlZmluZSBTQ1JfRlcgICAgICAgICAgKDEgPDwgNCkgIC8qIEYg
Qml0IGFjY2VzcyBhbGxvdyBiaXQgICAgICAgICAgICAgICAqLworI2RlZmluZSBTQ1JfQVcg
ICAgICAgICAgKDEgPDwgNSkgIC8qIEEgYml0IGFjY2VzcyBhbGxvdyBiaXQgICAgICAgICAg
ICAgICAqLworCisjZGVmaW5lIE5TQUNSX05TU01QICAgICAoMSA8PCAxOCkKKyNkZWZpbmUg
TlNBQ1JfVEwgICAgICAgICgxIDw8IDE3KQorI2RlZmluZSBOU0FDUl9OU0FDRURJUyAgKDEg
PDwgMTUpCisjZGVmaW5lIE5TQUNSX05TRDMyRElTICAoMSA8PCAxNCkKKyNkZWZpbmUgTlNB
Q1JfQ1AxMSAgICAgICgxIDw8IDExKQorI2RlZmluZSBOU0FDUl9DUDEwICAgICAgKDEgPDwg
MTApCisKKworI2lmbmRlZiBfX0FTU0VNQkxZX18KKworI2RlZmluZSBjcHVfdG9fY29yZShj
cHUpICAgICAgICAoMCkKKyNkZWZpbmUgY3B1X3RvX3NvY2tldChjcHUpICAgICAgKDApCisK
KyNkZWZpbmUgcDE0ICAgICAxNAorI2RlZmluZSBwMTUgICAgIDE1CisjZGVmaW5lIGMwICAg
ICAgMAorI2RlZmluZSBjMSAgICAgIDEKKyNkZWZpbmUgYzIgICAgICAyCisjZGVmaW5lIGMz
ICAgICAgMworI2RlZmluZSBjNCAgICAgIDQKKyNkZWZpbmUgYzUgICAgICA1CisjZGVmaW5l
IGM2ICAgICAgNgorI2RlZmluZSBjNyAgICAgIDcKKyNkZWZpbmUgYzggICAgICA4CisjZGVm
aW5lIGM5ICAgICAgOQorI2RlZmluZSBjMTAgICAgIDEwCisjZGVmaW5lIGMxMSAgICAgMTEK
KyNkZWZpbmUgYzEyICAgICAxMgorI2RlZmluZSBjMTMgICAgIDEzCisjZGVmaW5lIGMxNCAg
ICAgMTQKKyNkZWZpbmUgYzE1ICAgICAxNQorCisjZGVmaW5lIE1DUihjcCxvcDEsUmQsQ1Ju
LENSbSxvcDIpICBcCisJX19hc21fXyBfX3ZvbGF0aWxlX18oIiBtY3IgIiAjY3AiLCUxLCUy
LCIjQ1JuIiwiI0NSbSAiLCU1IiBcCisJOiA6ICJpIiAoY3ApLCAiaSIgKG9wMSksICJyIiAo
UmQpLCAiaSIgKENSbiksICJpIiAoQ1JtKSwgImkiIChvcDIpKQorCisjZGVmaW5lIE1SQyhj
cCxvcDEsUmQsQ1JuLENSbSxvcDIpICBcCisJX19hc21fXyBfX3ZvbGF0aWxlX18oICIgbXJj
ICIgI2NwIiwlMiwlMCwiICNDUm4iLCIjQ1JtIiwlNSIgXAorCTogIj1yIiAoUmQpIDogImki
IChjcCksICJpIiAob3AxKSwgImkiIChDUm4pLCAiaSIgKENSbSksICJpIiAob3AyKSkKKwor
c3RhdGljIGlubGluZSB2b2lkIGNwdV93YWl0X2Zvcl9ldmVudCh2b2lkKQoreworICAgICAg
ICBfX2FzbV9fIF9fdm9sYXRpbGVfXygid2ZlIiA6IDogOiAibWVtb3J5Iik7Cit9CisKK3N0
YXRpYyBpbmxpbmUgdm9pZCBjcHVfd2FpdF9mb3JfaW50ZXJydXB0KHZvaWQpCit7CisgICAg
ICAgIF9fYXNtX18gX192b2xhdGlsZSgid2ZpIiA6IDogOiAibWVtb3J5Iik7Cit9CisKK3N0
YXRpYyBpbmxpbmUgdm9pZCBjcHVfc2VuZF9ldmVudCh2b2lkKQoreworICAgICAgICBfX2Fz
bV9fIF9fdm9sYXRpbGVfXygic2V2IiA6IDogOiAibWVtb3J5Iik7Cit9CisKKyNkZWZpbmUg
Q1BVX01PREVfU01QCTEKKyNkZWZpbmUgQ1BVX01PREVfQU1QCTAKKworc3RhdGljIGlubGlu
ZSB2b2lkIGNwdV9zZXRfY29oZXJlbmN5X21vZGUodW5zaWduZWQgaW50IG1vZGUpCit7CisJ
dW5zaWduZWQgbG9uZyBhdXg7CisKKwlNUkMocDE1LCAwLCBhdXgsIGMxLCBjMCwgMSk7CisK
KwlpZiAoKG1vZGUgPT0gQ1BVX01PREVfU01QKSkgeworCQlhdXggfD0gKEFDVExSX1NNUCB8
IEFDVExSX0ZXKTsKKwl9IGVsc2UgeworCQlhdXggJj0gfihBQ1RMUl9TTVAgfCBBQ1RMUl9G
Vyk7CisJfQorCisJTUNSKHAxNSwgMCwgYXV4LCBjMSwgYzAsIDEpOworfQorCisjZW5kaWYK
KyNlbmRpZgpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL3JlZ3Mu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL3JlZ3MuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5
MDAKQEAgLTAsMCArMSwxNyBAQAorI2lmbmRlZiBfX0FTTV9BUk1fUkVHU19IX18KKyNkZWZp
bmUgX19BU01fQVJNX1JFR1NfSF9fCisKKyNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4KKyNpbmNs
dWRlIDxhc20vY3VycmVudC5oPgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworc3RhdGljIGlu
bGluZSBpbnQgZ3Vlc3RfbW9kZShzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKK3sKKwl3
aGlsZSgxKTsKKworCXJldHVybiAwOworfQorI2VuZGlmCisKKyNlbmRpZgorCmRpZmYgLXIg
ZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vc21wLmgKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFy
bS9zbXAuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyOCBA
QAorI2lmbmRlZiBfX0FSTV9TTVBfSF9fCisjZGVmaW5lIF9fQVJNX1NNUF9IX18KKworI2lu
Y2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vc3BpbmxvY2suaD4KKyNpbmNs
dWRlIDx4ZW4vY3B1bWFzay5oPgorI2luY2x1ZGUgPHhlbi9wZXJjcHUuaD4KKyNpbmNsdWRl
IDxhc20vY3VycmVudC5oPgorCisjaWZuZGVmIF9BU1NFTUJMWV9fCisjZGVmaW5lIHJhd19z
bXBfcHJvY2Vzc29yX2lkKCkJCQlcCisoewkJCQkJCVwKKwl1bnNpZ25lZCBpbnQgaWQ7CQkJ
XAorCV9fYXNtX18oIm1yYyBwMTUsIDAsICUwLCBjMCwgYzAsIDUiCVwKKwkJOiAiPXIiIChp
ZCkpOwkJCVwKKwlpZCAmPSAweDBGOwkJCQlcCit9KQorCisjZGVmaW5lIGNwdV9pc19vZmZs
aW5lKGNwdSkJdW5saWtlbHkoIWNwdV9vbmxpbmUoY3B1KSkKKworREVDTEFSRV9QRVJfQ1BV
KGNwdW1hc2tfdmFyX3QsIGNwdV9zaWJsaW5nX21hc2spOworREVDTEFSRV9QRVJfQ1BVKGNw
dW1hc2tfdmFyX3QsIGNwdV9jb3JlX21hc2spOworCitERUNMQVJFX1BFUl9DUFUoY3B1bWFz
a190LCBjcHVfc2libGluZ19tYXApOworREVDTEFSRV9QRVJfQ1BVKGNwdW1hc2tfdCwgY3B1
X2NvcmVfbWFwKTsKKworI2VuZGlmIC8qICFfX0FTU0VNQkxZX18gKi8KKyNlbmRpZiAvKiAh
X19BUk1fU01QX0hfXyAqLwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20t
YXJtL3NvZnRpcnEuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3NvZnRpcnEuaAlGcmkgRmViIDAzIDE2
OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMSBAQAorI2lmbmRlZiBfX0FTTV9TT0ZU
SVJRX0hfXworI2RlZmluZSBfX0FTTV9TT0ZUSVJRX0hfXworCisjZGVmaW5lIFJFU0VSVkVE
X1NPRlRJUlEwCShOUl9DT01NT05fU09GVElSUVMgKyAwKQorI2RlZmluZSBSRVNFUlZFRF9T
T0ZUSVJRMQkoTlJfQ09NTU9OX1NPRlRJUlFTICsgMSkKKyNkZWZpbmUgVkNQVV9LSUNLX1NP
RlRJUlEJKE5SX0NPTU1PTl9TT0ZUSVJRUyArIDIpCisKKyNkZWZpbmUgTlJfQVJDSF9TT0ZU
SVJRUwkzCisKKyNlbmRpZiAvKiBfX0FTTV9TT0ZUSVJRX0hfXyAqLworCmRpZmYgLXIgZTcw
MTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vc3BpbmxvY2suaAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
YXJtL3NwaW5sb2NrLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAg
KzEsMjAwIEBACisjaWZuZGVmIF9fQVJNX1NQSU5MT0NLX0hfXworI2RlZmluZSBfX0FSTV9T
UElOTE9DS19IX18KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4v
bGliLmg+CisjaW5jbHVkZSA8YXNtL2F0b21pYy5oPgorCisvKgorICogVW5sb2NrZWQgdmFs
dWUgOiAwCisgKiBMb2NrZWQgdmFsdWUgICA6IDEKKyAqLworI2RlZmluZSBfUkFXX1NQSU5f
TE9DS19VTkxPQ0tFRAl7IDAgfQorI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5MT0NLRUQJeyAw
IH0KKwordHlwZWRlZiBzdHJ1Y3QgeworCXZvbGF0aWxlIHVuc2lnbmVkIGludCBsb2NrOwor
fXJhd19zcGlubG9ja190OworCit0eXBlZGVmIHN0cnVjdCByd2xvY2sgeworCXZvbGF0aWxl
IHVuc2lnbmVkIGludCBsb2NrOworfXJhd19yd2xvY2tfdDsKKworI2RlZmluZSBfcmF3X3Nw
aW5faXNfbG9ja2VkKHgpCSgoeCktPmxvY2sgIT0gMCkKKworc3RhdGljIGlubGluZSB2b2lk
IF9yYXdfc3Bpbl9sb2NrKHJhd19zcGlubG9ja190ICpsb2NrKQoreworCXVuc2lnbmVkIGxv
bmcgdG1wOworCisJX19hc21fXyBfX3ZvbGF0aWxlX18oCisiMToJbGRyZXgJJTAsIFslMV1c
biIKKyIJdGVxCSUwLCAjMFxuIgorIgl3ZmVuZVxuIgorIglzdHJleGVxCSUwLCAlMiwgWyUx
XVxuIgorIgl0ZXFlcQklMCwgIzBcbiIKKyIJYm5lCTFiIgorCTogIj0mciIgKHRtcCkKKwk6
ICJyIiAoJmxvY2stPmxvY2spLCAiciIgKDEpCisJOiAiY2MiKTsKKworCW1iKCk7Cit9CisK
K3N0YXRpYyBpbmxpbmUgaW50IF9yYXdfc3Bpbl90cnlsb2NrKHJhd19zcGlubG9ja190ICps
b2NrKQoreworCXVuc2lnbmVkIGxvbmcgdG1wOworCisJX19hc21fXyBfX3ZvbGF0aWxlX18o
CisiCWxkcmV4CSUwLCBbJTFdXG4iCisiCXRlcQklMCwgIzBcbiIKKyIJc3RyZXhlcQklMCwg
JTIsIFslMV0iCisJOiAiPSZyIiAodG1wKQorCTogInIiICgmbG9jay0+bG9jayksICJyIiAo
MSkKKwk6ICJjYyIpOworCisJaWYgKHRtcCA9PSAwKSB7CisJCW1iKCk7CisKKwkJcmV0dXJu
IDE7CisJfSBlbHNlIHsKKwkJcmV0dXJuIDA7CisJfQorfQorCitzdGF0aWMgaW5saW5lIHZv
aWQgX3Jhd19zcGluX3VubG9jayhyYXdfc3BpbmxvY2tfdCAqbG9jaykKK3sKKwltYigpOwor
CisJX19hc21fXyBfX3ZvbGF0aWxlX18oCisiCXN0cgklMSwgWyUwXVxuIgorIgltY3IJcDE1
LCAwLCAlMSwgYzcsIGMxMCwgNFxuIiAvKiBEU0IgKi8KKyIJc2V2IgorCToKKwk6ICJyIiAo
JmxvY2stPmxvY2spLCAiciIgKDApCisJOiAiY2MiKTsKK30KKworLyoKKyAqIFJXTE9DS1MK
KyAqCisgKgorICogV3JpdGUgbG9ja3MgYXJlIGVhc3kgLSB3ZSBqdXN0IHNldCBiaXQgMzEu
ICBXaGVuIHVubG9ja2luZywgd2UgY2FuCisgKiBqdXN0IHdyaXRlIHplcm8gc2luY2UgdGhl
IGxvY2sgaXMgZXhjbHVzaXZlbHkgaGVsZC4KKyAqLworCitzdGF0aWMgaW5saW5lIHZvaWQg
X3Jhd193cml0ZV9sb2NrKHJhd19yd2xvY2tfdCAqcncpCit7CisJdW5zaWduZWQgbG9uZyB0
bXA7CisKKwlfX2FzbV9fIF9fdm9sYXRpbGVfXygKKyIxOglsZHJleAklMCwgWyUxXVxuIgor
Igl0ZXEJJTAsICMwXG4iCisiCXdmZW5lXG4iCisiCXN0cmV4ZXEJJTAsICUyLCBbJTFdXG4i
CisiCXRlcQklMCwgIzBcbiIKKyIJYm5lCTFiIgorCTogIj0mciIgKHRtcCkKKwk6ICJyIiAo
JnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQorCTogImNjIik7CisKKwltYigpOworfQor
CitzdGF0aWMgaW5saW5lIGludCBfcmF3X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpy
dykKK3sKKwl1bnNpZ25lZCBsb25nIHRtcDsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKAor
IjE6CWxkcmV4CSUwLCBbJTFdXG4iCisiCXRlcQklMCwgIzBcbiIKKyIJc3RyZXhlcQklMCwg
JTIsIFslMV0iCisJOiAiPSZyIiAodG1wKQorCTogInIiICgmcnctPmxvY2spLCAiciIgKDB4
ODAwMDAwMDApCisJOiAiY2MiKTsKKworCWlmICh0bXAgPT0gMCkgeworCQltYigpOworCQly
ZXR1cm4gMTsKKwl9IGVsc2UgeworCQlyZXR1cm4gMDsKKwl9Cit9CisKK3N0YXRpYyBpbmxp
bmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQoreworCW1iKCk7
CisKKwlfX2FzbV9fIF9fdm9sYXRpbGVfXygKKwkic3RyCSUxLCBbJTBdXG4iCisiCW1jcglw
MTUsIDAsICUxLCBjNywgYzEwLCA0XG4iIC8qIERTQiAqLworIglzZXZcbiIKKwk6CisJOiAi
ciIgKCZydy0+bG9jayksICJyIiAoMCkKKwk6ICJjYyIpOworfQorCisjZGVmaW5lIF9yYXdf
cndfaXNfbG9ja2VkKHgpCQkoKHgpLT5sb2NrICE9IDApCisjZGVmaW5lIF9yYXdfcndfaXNf
d3JpdGVfbG9ja2VkKHgpCSgoeCktPmxvY2sgPD0gMCkKKyNkZWZpbmUgX3Jhd193cml0ZV9j
YW5fbG9jayh4KQkJKCh4KS0+bG9jayA9PSAwKQorCitzdGF0aWMgaW5saW5lIHZvaWQgX3Jh
d19yZWFkX2xvY2socmF3X3J3bG9ja190ICpydykKK3sKKwl1bnNpZ25lZCBsb25nIHRtcCwg
dG1wMjsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKAorIjE6CWxkcmV4CSUwLCBbJTJdXG4i
CisiCWFkZHMJJTAsICUwLCAjMVxuIgorIglzdHJleHBsCSUxLCAlMCwgWyUyXVxuIgorIgl3
ZmVtaVxuIgorIglyc2JwbHMJJTAsICUxLCAjMFxuIgorIglibWkJMWIiCisJOiAiPSZyIiAo
dG1wKSwgIj0mciIgKHRtcDIpCisJOiAiciIgKCZydy0+bG9jaykKKwk6ICJjYyIpOworCisJ
bWIoKTsKK30KKworc3RhdGljIGlubGluZSB2b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3
bG9ja190ICpydykKK3sKKwl1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKKworCW1iKCk7CisK
KwlfX2FzbV9fIF9fdm9sYXRpbGVfXygKKyIxOglsZHJleAklMCwgWyUyXVxuIgorIglzdWIJ
JTAsICUwLCAjMVxuIgorIglzdHJleAklMSwgJTAsIFslMl1cbiIKKyIJdGVxCSUxLCAjMFxu
IgorIglibmUJMWJcbiIKKyIJY21wCSUwLCAjMFxuIgorIgltY3JlcSAgIHAxNSwgMCwgJTAs
IGM3LCBjMTAsIDRcbiIKKyIJc2V2ZXEiCisJOiAiPSZyIiAodG1wKSwgIj0mciIgKHRtcDIp
CisJOiAiciIgKCZydy0+bG9jaykKKwk6ICJjYyIpOworfQorCitzdGF0aWMgaW5saW5lIGlu
dCBfcmF3X3JlYWRfdHJ5bG9jayhyYXdfcndsb2NrX3QgKnJ3KQoreworCXVuc2lnbmVkIGxv
bmcgdG1wLCB0bXAyID0gMTsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKAorIjE6CWxkcmV4
CSUwLCBbJTJdXG4iCisiCWFkZHMJJTAsICUwLCAjMVxuIgorIglzdHJleHBsCSUxLCAlMCwg
WyUyXVxuIgorCTogIj0mciIgKHRtcCksICIrciIgKHRtcDIpCisJOiAiciIgKCZydy0+bG9j
aykKKwk6ICJjYyIpOworCisJbWIoKTsKKwlyZXR1cm4gdG1wMiA9PSAwOworfQorCisjZGVm
aW5lIF9yYXdfcmVhZF9jYW5fbG9jayh4KQkoKHgpLT5sb2NrIDwgMHg4MDAwMDAwMCkKKwor
I2RlZmluZSBfcmF3X3NwaW5fcmVsYXgobG9jaykJY3B1X3JlbGF4KCkKKyNkZWZpbmUgX3Jh
d19yZWFkX3JlbGF4KGxvY2spCWNwdV9yZWxheCgpCisjZGVmaW5lIF9yYXdfd3JpdGVfcmVs
YXgobG9jaykJY3B1X3JlbGF4KCkKKworI2VuZGlmIC8qIF9fQVNNX1NQSU5MT0NLX0ggKi8K
ZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9zdHJpbmcuaAotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5j
bHVkZS9hc20tYXJtL3N0cmluZy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApA
QCAtMCwwICsxLDQ5IEBACisjaWZuZGVmIF9fQVNNX1NUUklOR19IX18KKyNkZWZpbmUgX19B
U01fU1RSSU5HX0hfXworCisvKgorICogV2UgZG9uJ3QgZG8gaW5saW5lIHN0cmluZyBmdW5j
dGlvbnMsIHNpbmNlIHRoZQorICogb3B0aW1pc2VkIGlubGluZSBhc20gdmVyc2lvbnMgYXJl
IG5vdCBzbWFsbC4KKyAqLworCisjZGVmaW5lIF9fSEFWRV9BUkNIX1NUUlJDSFIKK2V4dGVy
biBjaGFyICogc3RycmNocihjb25zdCBjaGFyICogcywgaW50IGMpOworCisjZGVmaW5lIF9f
SEFWRV9BUkNIX1NUUkNIUgorZXh0ZXJuIGNoYXIgKiBzdHJjaHIoY29uc3QgY2hhciAqIHMs
IGludCBjKTsKKworI2RlZmluZSBfX0hBVkVfQVJDSF9NRU1DUFkKK2V4dGVybiB2b2lkICog
bWVtY3B5KHZvaWQgKiwgY29uc3Qgdm9pZCAqLCBfX2tlcm5lbF9zaXplX3QpOworCisjZGVm
aW5lIF9fSEFWRV9BUkNIX01FTU1PVkUKK2V4dGVybiB2b2lkICogbWVtbW92ZSh2b2lkICos
IGNvbnN0IHZvaWQgKiwgX19rZXJuZWxfc2l6ZV90KTsKKworI2RlZmluZSBfX0hBVkVfQVJD
SF9NRU1DSFIKK2V4dGVybiB2b2lkICogbWVtY2hyKGNvbnN0IHZvaWQgKiwgaW50LCBfX2tl
cm5lbF9zaXplX3QpOworCisjZGVmaW5lIF9fSEFWRV9BUkNIX01FTVpFUk8KKyNkZWZpbmUg
X19IQVZFX0FSQ0hfTUVNU0VUCitleHRlcm4gdm9pZCAqIG1lbXNldCh2b2lkICosIGludCwg
X19rZXJuZWxfc2l6ZV90KTsKKworI2RlZmluZSBfX0hBVkVfQVJDSF9CQ09QWQorCitleHRl
cm4gdm9pZCBfX21lbXplcm8odm9pZCAqcHRyLCBfX2tlcm5lbF9zaXplX3Qgbik7CisKKyNk
ZWZpbmUgbWVtc2V0KHAsdixuKQkJCQkJCVwKKyh7CQkJCQkJCQlcCisJaWYgKChuKSAhPSAw
KSB7CQkJCQkJXAorCQlpZiAoX19idWlsdGluX2NvbnN0YW50X3AoKHYpKSAmJiAodikgPT0g
MCkJXAorCQkJX19tZW16ZXJvKChwKSwobikpOwkJCVwKKwkJZWxzZQkJCQkJCVwKKwkJCW1l
bXNldCgocCksKHYpLChuKSk7CQkJXAorCX0JCQkJCQkJXAorCShwKTsJCQkJCQkJXAorfSkK
KworI2RlZmluZSBtZW16ZXJvKHAsbikgCQkJCVwKKyh7IAkJCQkJCVwKKwlpZiAoKG4pICE9
IDApIAkJCQlcCisJCV9fbWVtemVybygocCksKG4pKTsgKHApOyAJXAorfSkKKworI2VuZGlm
CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vc3lzdGVtLmgKLS0t
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2lu
Y2x1ZGUvYXNtLWFybS9zeXN0ZW0uaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAK
QEAgLTAsMCArMSwxNDggQEAKKyNpZm5kZWYgX19BU01fU1lTVEVNX0gKKyNkZWZpbmUgX19B
U01fU1lTVEVNX0gKKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKworI2RlZmluZSBfX2Fz
bWVxKHgsIHkpICAiLmlmbmMgIiB4ICIsIiB5ICIgOyAuZXJyIDsgLmVuZGlmXG5cdCIKKwor
I2lmbmRlZiBfX0FTU0VNQkxZX18KKworLyoKKyAqIGRtYiA6IERhdGEgTWVtb3J5IEJhcnJp
ZXIKKyAqIGRzYiA6IERhdGEgU3luY2hyb25pemF0aW9uIEJhcnJpZXIKKyAqIAktPiBEcmFp
biBXcml0ZSBCdWZmZXIgaW4gZWFybGllciBvZiB0aGUgYXJjaGl0ZWN0dXJlCisgKiBpc2Ig
OiBJbnN0cnVjdGlvbiBTeW5jaHJvbml6YXRpb24gQmFycmllcgorICogCS0+IEZsdXNoIHBp
cGVsaW5lIGFuZCBicmFjaCB0YXJnZXQgYnVmZmVycy4KKyAqLworCisjZGVmaW5lIGlzYigp
IF9fYXNtX18gX192b2xhdGlsZV9fICgiaXNiIiA6IDogOiAibWVtb3J5IikKKyNkZWZpbmUg
ZHNiKCkgX19hc21fXyBfX3ZvbGF0aWxlX18gKCJkc2IiIDogOiA6ICJtZW1vcnkiKQorI2Rl
ZmluZSBkbWIoKSBfX2FzbV9fIF9fdm9sYXRpbGVfXyAoImRtYiIgOiA6IDogIm1lbW9yeSIp
CisKKyNkZWZpbmUgbWIoKQkJZG1iKCkKKyNkZWZpbmUgcm1iKCkgCQlkbWIoKQorI2RlZmlu
ZSB3bWIoKSAJCWRtYigpCisKKyNkZWZpbmUgY3B1X3JlbGF4KCkJZG1iKCkKKworI2RlZmlu
ZSBzbXBfcm1iKCkJcm1iKCkKKyNkZWZpbmUgc21wX3dtYigpCXdtYigpCisjZGVmaW5lIHNt
cF9tYigpCWRtYigpCisKKyNkZWZpbmUgbG9jYWxfaXJxX3NhdmUoeCkJCVwKKyh7CQkJCQlc
CisJX19hc21fXyBfX3ZvbGF0aWxlX18oCQlcCisJCSJtcnMgICAgJTAsIGNwc3IgXG4iCVwK
KwkJImNwc2lkICBpIgkJXAorCQk6ICI9ciIgKHgpCQlcCisJCToJCQlcCisJCTogIm1lbW9y
eSIsICJjYyIpOwlcCit9KQorCisjZGVmaW5lIGxvY2FsX2lycV9lbmFibGUoKSAgX19hc21f
XygiY3BzaWUgaSAgICBAIF9fc3RpIiA6IDogOiAibWVtb3J5IiwgImNjIikKKyNkZWZpbmUg
bG9jYWxfaXJxX2Rpc2FibGUoKSBfX2FzbV9fKCJjcHNpZCBpICAgIEAgX19jbGkiIDogOiA6
ICJtZW1vcnkiLCAiY2MiKQorI2RlZmluZSBsb2NhbF9maXFfZW5hYmxlKCkgIF9fYXNtX18o
ImNwc2llIGYgICAgQCBfX3N0ZiIgOiA6IDogIm1lbW9yeSIsICJjYyIpCisjZGVmaW5lIGxv
Y2FsX2ZpcV9kaXNhYmxlKCkgX19hc21fXygiY3BzaWQgZiAgICBAIF9fY2xmIiA6IDogOiAi
bWVtb3J5IiwgImNjIikKKworLyoKKyAqIFNhdmUgdGhlIGN1cnJlbnQgaW50ZXJydXB0IGVu
YWJsZSBzdGF0ZS4KKyAqLworI2RlZmluZSBsb2NhbF9zYXZlX2ZsYWdzKHgpCQlcCisoewkJ
CQkJXAorCV9fYXNtX18gX192b2xhdGlsZV9fKAkJXAorCSJtcnMJJTAsIGNwc3JcbiIJCVwK
Kwk6ICI9ciIgKHgpIDogOiAibWVtb3J5IiwgImNjIik7CVwKK30pCisKKy8qCisgKiByZXN0
b3JlIHNhdmVkIElSUSAmIEZJUSBzdGF0ZQorICovCisjZGVmaW5lIGxvY2FsX2lycV9yZXN0
b3JlKHgpCQlcCisoewkJCQkJXAorCV9fYXNtX18gX192b2xhdGlsZV9fKAkJXAorCSJtc3IJ
Y3Bzcl9jLCAlMFxuIgkJXAorCToJCQkJXAorCTogInIiICh4KQkJCVwKKwk6ICJtZW1vcnki
LCAiY2MiKTsJCVwKK30pCisKKyNkZWZpbmUgaXJxc19kaXNhYmxlZCgpCQkJCVwKKyh7CQkJ
CQlcCisJdW5zaWduZWQgbG9uZyBmbGFnczsJCVwKKwlsb2NhbF9zYXZlX2ZsYWdzKGZsYWdz
KTsJXAorCWZsYWdzICYgUFNSX0lfQklUOwkJXAorfSkKKworI2RlZmluZSBsb2NhbF9pcnFf
aXNfZW5hYmxlZCgpCSghaXJxc19kaXNhYmxlZCgpKQorCitzdGF0aWMgaW5saW5lIHZvaWQg
bm9wKHZvaWQpCit7CisJYXNtIHZvbGF0aWxlKCJub3AiKTsKK30KKworc3RhdGljIGlubGlu
ZSB1bnNpZ25lZCBpbnQgZ2V0X2NyKHZvaWQpCit7CisJdW5zaWduZWQgaW50IHZhbDsKKwlh
c20oIm1yYyBwMTUsIDAsICUwLCBjMSwgYzAsIDAiIDogIj1yIih2YWwpIDogOiAiY2MiKTsK
KworCXJldHVybiB2YWw7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfY3IodW5zaWdu
ZWQgaW50IHZhbCkKK3sKKwlhc20gdm9sYXRpbGUoIm1jciBwMTUsIDAsICUwLCBjMSwgYzAs
IDAiIDogOiAiciIodmFsKSA6ICJjYyIpOworCisJaXNiKCk7Cit9CisKK3N0YXRpYyBpbmxp
bmUgdW5zaWduZWQgbG9uZyBfeGNoZyh1bnNpZ25lZCBsb25nIHgsIHZvbGF0aWxlIHZvaWQg
KiBwdHIsIGludCBzaXplKQoreworCXVuc2lnbmVkIGxvbmcgcmV0OworCXVuc2lnbmVkIGlu
dCB0bXA7CisKKwlzd2l0Y2ggKHNpemUpIHsKKyAgICAgICAgY2FzZSAxOgorCQlfX2FzbV9f
IF9fdm9sYXRpbGVfXygKKwkJIjE6ICAgICBsZHJleGIgICUwLCBbJTNdXG4iCisJCSIgICAg
ICAgc3RyZXhiICAlMSwgJTIsIFslM11cbiIKKwkJIiAgICAgICB0ZXEgICAgICUxLCAjMFxu
IgorCQkiICAgICAgIGJuZSAgICAgMWIiCisJCTogIj0mciIgKHJldCksICI9JnIiICh0bXAp
CisJCTogInIiICh4KSwgInIiIChwdHIpCisJCTogIm1lbW9yeSIsICJjYyIpOworCQlicmVh
azsKKwljYXNlIDQ6CisJCV9fYXNtX18gX192b2xhdGlsZV9fKCJAIF9feGNoZzRcbiIKKwkJ
IjE6ICAgICBsZHJleCAgICUwLCBbJTNdXG4iCisJCSIgICAgICAgc3RyZXggICAlMSwgJTIs
IFslM11cbiIKKwkJIiAgICAgICB0ZXEgICAgICUxLCAjMFxuIgorCQkiICAgICAgIGJuZSAg
ICAgMWIiCisJCTogIj0mciIgKHJldCksICI9JnIiICh0bXApCisJCTogInIiICh4KSwgInIi
IChwdHIpCisJCTogIm1lbW9yeSIsICJjYyIpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQly
ZXQgPSAwOworCQlicmVhazsKKwl9CisKKwlyZXR1cm4gcmV0OworfQorCisjZGVmaW5lIGNt
cHhjaGcocHRyLCBvbGQsIG5ldykJCQkJCQlcCisoeyAJCQkJCQkJCQlcCisJX190eXBlb2Zf
XygqKHB0cikpIHByZXY7IAkJCQkJXAorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CQkJCQkJXAor
CWxvY2FsX2lycV9zYXZlKGZsYWdzKTsJCQkJCQlcCisJcHJldiA9ICooKF9fdHlwZW9mX18o
KihwdHIpKSAqKXB0cik7IAkJCQlcCisJaWYocHJldiA9PSBvbGQpIAkJCQkJCVwKKwkJKigo
X190eXBlb2ZfXygqKHB0cikpICopcHRyKSA9IChfX3R5cGVvZl9fKCoocHRyKSkpbmV3Owlc
CisJbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOwkJCQkJXAorCXByZXY7IAkJCQkJCQkJXAor
fSkKKworI2RlZmluZSB4Y2hnKHB0cix2KQlcCisJKChfX3R5cGVvZl9fKCoocHRyKSkpX3hj
aGcoKHVuc2lnbmVkIGxvbmcpKHYpLChwdHIpLHNpemVvZigqKHB0cikpKSkKKworI2VuZGlm
IC8qIF9fQVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIV9fU1lTVEVNX0hfXyAqLwpkaWZmIC1y
IGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2NvbmZpZy5oCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS1hcm0vdGVncmEvY29uZmlnLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsMTEgQEAKKyNpZm5kZWYgX19URUdSQV9DT05GSUdfSF9fCisjZGVm
aW5lIF9fVEVHUkFfQ09ORklHX0hfXworCisjZGVmaW5lIEhaCTEwMAorI2RlZmluZSBDTE9D
S19USUNLX1JBVEUJCTEwMDAwMDAKKworI2RlZmluZSBNQVhfUEhZU19DUFVTCQkyCisKKyNk
ZWZpbmUgQlVJTFRJTl9DT01NQU5EX0xJTkVfU0laRSAyNTYKKyNkZWZpbmUgQlVJTFRJTl9D
T01NQU5EX0xJTkUJIiIKKyNlbmRpZgpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVk
ZS9hc20tYXJtL3RpbWUuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3RpbWUuaAlGcmkgRmViIDAzIDE2
OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyNCBAQAorI2lmbmRlZiBfX0FTTV9USU1F
X0hfXworI2RlZmluZSBfX0FTTV9USU1FX0hfXworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5o
PgorI2luY2x1ZGUgPHhlbi90eXBlcy5oPgorI2luY2x1ZGUgPHhlbi9zb2Z0aXJxLmg+CisK
KyNpZm5kZWYgX19BU1NFTUJMWV9fCisjZGVmaW5lIHdhdGNoZG9nX2Rpc2FibGUoKSAoKHZv
aWQpMCkKKyNkZWZpbmUgd2F0Y2hkb2dfZW5hYmxlKCkgICgodm9pZCkwKQorCitzdHJ1Y3Qg
dG07CitzdHJ1Y3QgdG0gd2FsbGNsb2NrX3RpbWUodm9pZCk7CisKK3R5cGVkZWYgdTY0IGN5
Y2xlX3Q7CisKK3N0YXRpYyBpbmxpbmUgY3ljbGVfdCBnZXRfY3ljbGVzKHZvaWQpCit7CisJ
cmV0dXJuIDA7Cit9CisKK3ZvaWQgdGltZWtlZXBpbmdfaW5pdCh2b2lkKTsKKyNlbmRpZgor
I2VuZGlmCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vdHJhY2Uu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL3RyYWNlLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsNiBAQAorI2lmbmRlZiBfX0FSTV9UUkFDRV9IX18KKyNkZWZpbmUg
X19BUk1fVFJBQ0VfSF9fCisKKworI2VuZGlmIC8qIV9fQVJNX1RSQUNFX0hfXyovCisKZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS90eXBlcy5oCi0tLSAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS1hcm0vdHlwZXMuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAs
MCArMSw1OCBAQAorI2lmbmRlZiBfX0FSTV9UWVBFU19IX18KKyNkZWZpbmUgX19BUk1fVFlQ
RVNfSF9fCisKKyNkZWZpbmUgQklUU19QRVJfTE9ORwkzMgorI2RlZmluZSBCWVRFU19QRVJf
TE9ORwk0CisjZGVmaW5lIExPTkdfQllURU9SREVSCTIKKworI2lmbmRlZiBfX0FTU0VNQkxZ
X18KKy8qCisgKiBfX3h4IGlzIG9rOiBpdCBkb2Vzbid0IHBvbGx1dGUgdGhlIFBPU0lYIG5h
bWVzcGFjZS4gVXNlIHRoZXNlIGluIHRoZQorICogaGVhZGVyIGZpbGVzIGV4cG9ydGVkIHRv
IHVzZXIgc3BhY2UKKyAqLworCit0eXBlZGVmIF9fc2lnbmVkX18gY2hhciBfX3M4OwordHlw
ZWRlZiB1bnNpZ25lZCBjaGFyIF9fdTg7CisKK3R5cGVkZWYgX19zaWduZWRfXyBzaG9ydCBf
X3MxNjsKK3R5cGVkZWYgdW5zaWduZWQgc2hvcnQgX191MTY7CisKK3R5cGVkZWYgX19zaWdu
ZWRfXyBpbnQgX19zMzI7Cit0eXBlZGVmIHVuc2lnbmVkIGludCBfX3UzMjsKKworI2lmIGRl
ZmluZWQoX19HTlVDX18pICYmICFkZWZpbmVkKF9fU1RSSUNUX0FOU0lfXykKK3R5cGVkZWYg
X19zaWduZWRfXyBsb25nIGxvbmcgX19zNjQ7Cit0eXBlZGVmIHVuc2lnbmVkIGxvbmcgbG9u
ZyBfX3U2NDsKKyNlbmRpZgorCit0eXBlZGVmIHVuc2lnbmVkIGxvbmcgcGh5c2FkZHJfdDsK
KwordHlwZWRlZiBzaWduZWQgY2hhciBzODsKK3R5cGVkZWYgdW5zaWduZWQgY2hhciB1ODsK
KwordHlwZWRlZiBzaWduZWQgc2hvcnQgczE2OwordHlwZWRlZiB1bnNpZ25lZCBzaG9ydCB1
MTY7CisKK3R5cGVkZWYgc2lnbmVkIGludCBzMzI7Cit0eXBlZGVmIHVuc2lnbmVkIGludCB1
MzI7CisKK3R5cGVkZWYgc2lnbmVkIGxvbmcgbG9uZyBzNjQ7Cit0eXBlZGVmIHVuc2lnbmVk
IGxvbmcgbG9uZyB1NjQ7CisKK3R5cGVkZWYgdW5zaWduZWQgbG9uZyBwYWRkcl90OwordHlw
ZWRlZiB1bnNpZ25lZCBsb25nIHZhZGRyX3Q7CisKK3R5cGVkZWYgdW5zaWduZWQgbG9uZyBz
aXplX3Q7CisKK3R5cGVkZWYgY2hhciBib29sX3Q7CisKKyNkZWZpbmUgdGVzdF9hbmRfc2V0
X2Jvb2woYikJeGNoZygmKGIpLCAxKQorI2RlZmluZSB0ZXN0X2FuZF9jbGVhcl9ib29sKGIp
CXhjaGcoJihiKSwgMCkKKworI2RlZmluZSByb3VuZF91cChfcCwgX3MpICAgICAgICAoKCh1
bnNpZ25lZCBsb25nKShfcCkgKyAoKF9zKSAtIDEpKSAmIH4oKF9zKSAtIDEpKQorI2RlZmlu
ZSByb3VuZF9kb3duKF9wLCBfcykgICAgICAoKHVuc2lnbmVkIGxvbmcpKF9wKSAmIH4oKF9z
KSAtIDEpKQorCisjZGVmaW5lIHJvdW5kX3VwX2FuZF9kaXYoX3AsIF9zKSAocm91bmRfdXAo
X3AsIF9zKSAvIF9zKQorI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworCisjZW5kaWYKZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS94ZW5vcHJvZi5oCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS1hcm0veGVub3Byb2YuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAK
QEAgLTAsMCArMSw0MyBAQAorI2lmbmRlZiBfX0FTTV9YRU5PUFJPRl9IX18KKyNkZWZpbmUg
X19BU01fWEVOT1BST0ZfSF9fCisKKyNkZWZpbmUgeGVub3Byb2ZfYXJjaF9yZXNlcnZlX2Nv
dW50ZXJzKCkJKDApCisjZGVmaW5lIHhlbm9wcm9mX2FyY2hfc2V0dXBfZXZlbnRzKCkJCSgw
KQorI2RlZmluZSB4ZW5vcHJvZl9hcmNoX2VuYWJsZV92aXJxKCkJCSgwKQorI2RlZmluZSB4
ZW5vcHJvZl9hcmNoX3N0YXJ0KCkgCQkJKDApCisjZGVmaW5lIHhlbm9wcm9mX2FyY2hfc3Rv
cCgpCisjZGVmaW5lIHhlbm9wcm9mX2FyY2hfZGlzYWJsZV92aXJxKCkgCisjZGVmaW5lIHhl
bm9wcm9mX2FyY2hfcmVsZWFzZV9jb3VudGVycygpCisKKworI2RlZmluZSB4ZW5vcHJvZl9z
aGFyZWRfZ21mbihkLCBnbWFkZHIsIG1hZGRyKQlcCitkbyB7CQkJCQkJXAorCSh2b2lkKSht
YWRkcik7CQkJCVwKK30gd2hpbGUgKDApCisKKworc3RhdGljIGlubGluZSB2b2lkIGlic19p
bml0KHZvaWQpIHt9CisjZGVmaW5lIGlic19jYXBzIDAKKworc3RhdGljIGlubGluZSBpbnQg
eGVub3Byb2ZfYmFja3RyYWNlX3N1cHBvcnRlZCh2b2lkKQoreworCXJldHVybiAwOworfQor
CitzdHJ1Y3QgdmNwdTsKK3N0cnVjdCBjcHVfdXNlcl9yZWdzOworCitpbnQgeGVub3Byb2Zf
YXJjaF9jb3VudGVyKFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKTsKK2ludCBjb21wYXRf
b3Byb2ZfYXJjaF9jb3VudGVyKFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKTsKK2ludCB4
ZW5vcHJvZl9hcmNoX2lic19jb3VudGVyKFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKTsK
Kworc3RhdGljIGlubGluZSB2b2lkIHhlbm9wcm9mX2JhY2t0cmFjZSgKKyAgICBzdHJ1Y3Qg
ZG9tYWluICpkLCBzdHJ1Y3QgdmNwdSAqdmNwdSwKKyAgICBzdHJ1Y3QgY3B1X3VzZXJfcmVn
cyAqY29uc3QgcmVncywgdW5zaWduZWQgbG9uZyBkZXB0aCwgaW50IG1vZGUpIHt9CisKK3N0
YXRpYyBpbmxpbmUgaW50IHhlbm9wcm9mX2FyY2hfaW5pdChpbnQgKm51bV9ldmVudHMsIGNo
YXIgKmNwdV90eXBlKQoreworCXJldHVybiAwOworfQorCisjZW5kaWYKZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gtYXJtLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEs
MTgwIEBACisjaWZuZGVmIF9fWEVOX1BVQkxJQ19BUkNIX0FSTV8zMl9IX18KKyNkZWZpbmUg
X19YRU5fUFVCTElDX0FSQ0hfQVJNXzMyX0hfXworCisjZGVmaW5lIFZQU1JfTU9ERV9TVkMy
NiAgICAgICAgIDB4MDAwMDAwMDMKKyNkZWZpbmUgVlBTUl9NT0RFX1VTUiAgICAgICAgICAg
MHgwMDAwMDAxMAorI2RlZmluZSBWUFNSX01PREVfRklRICAgICAgICAgICAweDAwMDAwMDEx
CisjZGVmaW5lIFZQU1JfTU9ERV9JUlEgICAgICAgICAgIDB4MDAwMDAwMTIKKyNkZWZpbmUg
VlBTUl9NT0RFX1NWQyAgICAgICAgICAgMHgwMDAwMDAxMworI2RlZmluZSBWUFNSX01PREVf
QUJUICAgICAgICAgICAweDAwMDAwMDE3CisjZGVmaW5lIFZQU1JfTU9ERV9VTkQgICAgICAg
ICAgIDB4MDAwMDAwMWIKKyNkZWZpbmUgVlBTUl9NT0RFX1NZUyAgICAgICAgICAgMHgwMDAw
MDAxZgorI2RlZmluZSBWUFNSX01PREVfTUFTSyAgICAgICAgICAweDAwMDAwMDFmCisKKyNk
ZWZpbmUgVlBTUl9UX0JJVCAgICAgICAgICAgICAgMHgwMDAwMDAyMAorI2RlZmluZSBWUFNS
X0ZfQklUICAgICAgICAgICAgICAweDAwMDAwMDQwCisjZGVmaW5lIFZQU1JfSV9CSVQgICAg
ICAgICAgICAgIDB4MDAwMDAxMDAKKyNkZWZpbmUgVlBTUl9KX0JJVCAgICAgICAgICAgICAg
MHgwMTAwMDAwMAorI2RlZmluZSBWUFNSX1FfQklUICAgICAgICAgICAgICAweDA4MDAwMDAw
CisjZGVmaW5lIFZQU1JfVl9CSVQgICAgICAgICAgICAgIDB4MTAwMDAwMDAKKyNkZWZpbmUg
VlBTUl9DX0JJVCAgICAgICAgICAgICAgMHgyMDAwMDAwMAorI2RlZmluZSBWUFNSX1pfQklU
ICAgICAgICAgICAgICAweDQwMDAwMDAwCisjZGVmaW5lIFZQU1JfTl9CSVQgICAgICAgICAg
ICAgIDB4ODAwMDAwMDAKKworLyoKKyAqIEdyb3VwcyBvZiBQU1IgYml0cworICovCisjZGVm
aW5lIFZQU1JfTUFTS19JTlRSICAgICAgICAgIChWUFNSX0lfQklUIHwgVlBTUl9GX0JJVCkK
KyNkZWZpbmUgVlBTUl9NQVNLX01PREUgICAgICAgICAgMHgwMDAwMDFmCisjZGVmaW5lIFZQ
U1JfTUFTS19GTEFHUyAgICAgICAgIDB4ZmYwMDAwMDAgICAgICAvKiBGbGFncyAgICAgICAg
ICAgICAgICAqLworI2RlZmluZSBWUFNSX01BU0tfU1RBVFVTICAgICAgICAweDAwZmYwMDAw
ICAgICAgLyogU3RhdHVzICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgVlBTUl9NQVNLX0VY
VEVOU0lPTiAgICAgMHgwMDAwZmYwMCAgICAgIC8qIEV4dGVuc2lvbiAgICAgICAgICAgICov
CisjZGVmaW5lIFZQU1JfTUFTS19DT05UUk9MICAgICAgIDB4MDAwMDAwZmYgICAgICAvKiBD
b250cm9sICAgICAgICAgICAgICAqLworCisvKgorICogSFlQRVJDQUxMUyBmb3IgQVJNIGFy
Y2hpdGVjdHVyZQorICovCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9yZXN0b3JlX3RyYXBfZnJh
bWUgICAgICAgICAgICAyMworCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9zZXRfY3B1X2RvbWFp
biAgICAgICAgICAgICAgICA0OAorI2RlZmluZSBfX0hZUEVSVklTT1JfZG9fc2V0X2ZvcmVn
cm91bmRfZG9tYWluICAgICAgNDkKKyNkZWZpbmUgX19IWVBFUlZJU09SX2RvX2djb3Zfb3Ag
ICAgICAgICAgICAgICAgICAgIDQwCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9kb192ZnBfb3Ag
ICAgICAgICAgICAgICAgICAgICA1MQorI2RlZmluZSBfX0hZUEVSVklTT1JfZG9fc2V0X3Rs
cyAgICAgICAgICAgICAgICAgICAgNTIKKworI2RlZmluZSBUTEJGX0lUTEIgICAgICAgICAg
ICAgICAxCisjZGVmaW5lIFRMQkZfRFRMQiAgICAgICAgICAgICAgIDIKKyNkZWZpbmUgVExC
Rl9BU0lEICAgICAgICAgICAgICAgNAorCisKKyNkZWZpbmUgQ01EX0ZNUlggICAgICAgICAg
ICAgICAgMAorI2RlZmluZSBDTURfRk1YUiAgICAgICAgICAgICAgICAxCisKKyNkZWZpbmUg
RlBFWENfWEVOICAgICAgICAgICAgICAgMAorI2RlZmluZSBGUElOU1RfWEVOICAgICAgICAg
ICAgICAxCisjZGVmaW5lIEZQSU5TVDJfWEVOICAgICAgICAgICAgIDIKKyNkZWZpbmUgTVZG
UjBfWEVOICAgICAgICAgICAgICAgMworCisvKiBGUEVYQyBiaXRzICovCisjZGVmaW5lIEZQ
RVhDX0VYQ0VQVElPTiAgICAgICAgICgxPDwzMSkKKyNkZWZpbmUgRlBFWENfRU5BQkxFICAg
ICAgICAgICAgKDE8PDMwKQorCisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCisjaWZkZWYgX19Y
RU5fXworI2RlZmluZSBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShuYW1lLCB0eXBlKSBc
CisgICAgdHlwZWRlZiBzdHJ1Y3QgeyB0eXBlICpwOyB9IF9fZ3Vlc3RfaGFuZGxlXyAjIyBu
YW1lCisjZWxzZQorI2RlZmluZSBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShuYW1lLCB0
eXBlKSBcCisgICAgdHlwZWRlZiB0eXBlICogX19ndWVzdF9oYW5kbGVfICMjIG5hbWUKKyNl
bmRpZgorICAgIAorI2RlZmluZSBfX0RFRklORV9YRU5fR1VFU1RfSEFORExFKG5hbWUsIHR5
cGUpIFwKKyAgICBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShuYW1lLCB0eXBlKTsgICBc
CisgICAgX19fREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoY29uc3RfIyNuYW1lLCBjb25zdCB0
eXBlKQorCisjZGVmaW5lIERFRklORV9YRU5fR1VFU1RfSEFORExFKG5hbWUpIF9fREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUobmFtZSwgbmFtZSkKKyNkZWZpbmUgWEVOX0dVRVNUX0hBTkRM
RShuYW1lKSAgICAgICAgX19ndWVzdF9oYW5kbGVfICMjIG5hbWUKKyAgICAKKworLyoKKyAq
IFZpcnR1YWwgYWRkcmVzc2VzIGJleW9uZCB0aGlzIGFyZSBub3QgbW9kaWZpYWJsZSBieSBn
dWVzdCBPU2VzLiBUaGUgCisgKiBtYWNoaW5lLT5waHlzaWNhbCBtYXBwaW5nIHRhYmxlIHN0
YXJ0cyBhdCB0aGlzIGFkZHJlc3MsIHJlYWQtb25seS4KKyAqLworI2RlZmluZSBfX0hZUEVS
VklTT1JfVklSVF9TVEFSVCAweEZDMDAwMDAwCisKKyNpZm5kZWYgSFlQRVJWSVNPUl9WSVJU
X1NUQVJUCisjZGVmaW5lIEhZUEVSVklTT1JfVklSVF9TVEFSVCBta191bnNpZ25lZF9sb25n
KF9fSFlQRVJWSVNPUl9WSVJUX1NUQVJUKQorI2VuZGlmCisKKyNpZm5kZWYgbWFjaGluZV90
b19waHlzX21hcHBpbmcKKyNkZWZpbmUgbWFjaGluZV90b19waHlzX21hcHBpbmcgKCh1bnNp
Z25lZCBsb25nICopSFlQRVJWSVNPUl9WSVJUX1NUQVJUKQorI2VuZGlmCisKK3R5cGVkZWYg
dW5zaWduZWQgbG9uZyB4ZW5fcGZuX3Q7Cit0eXBlZGVmIHVuc2lnbmVkIGxvbmcgeGVuX3Vs
b25nX3Q7CisKK3R5cGVkZWYgc3RydWN0IHRyYXBfaW5mbyB7CisJdW5zaWduZWQgbG9uZyBp
bnN0cnVjdGlvbjsKK310cmFwX2luZm9fdDsKKworREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
dHJhcF9pbmZvX3QpOworCit0eXBlZGVmIHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgewor
CXVuc2lnbmVkIGxvbmcJcjA7CisJdW5zaWduZWQgbG9uZwlyMTsKKwl1bnNpZ25lZCBsb25n
CXIyOworCXVuc2lnbmVkIGxvbmcJcjM7CisJdW5zaWduZWQgbG9uZwlyNDsKKwl1bnNpZ25l
ZCBsb25nCXI1OworCXVuc2lnbmVkIGxvbmcJcjY7CisJdW5zaWduZWQgbG9uZwlyNzsKKwl1
bnNpZ25lZCBsb25nCXI4OworCXVuc2lnbmVkIGxvbmcJcjk7CisJdW5zaWduZWQgbG9uZwly
MTA7CisJdW5zaWduZWQgbG9uZwlyMTE7CisJdW5zaWduZWQgbG9uZwlyMTI7CisJdW5zaWdu
ZWQgbG9uZwlyMTM7CisJdW5zaWduZWQgbG9uZwlyMTQ7CisJdW5zaWduZWQgbG9uZwlyMTU7
CisJdW5zaWduZWQgbG9uZyAgIHZiYXI7CisJdW5zaWduZWQgbG9uZyAgIGRhY3I7CisJdW5z
aWduZWQgbG9uZyAgIGNvbnRleHRpZHI7CisJdW5zaWduZWQgbG9uZyAgIGZjc2VpZHI7CisJ
dW5zaWduZWQgbG9uZyAgIHR0YnIwOworCXVuc2lnbmVkIGxvbmcgICB0dGJyMTsKKwl1bnNp
Z25lZCBsb25nICAgdHRiY3I7CisJdW5zaWduZWQgbG9uZwljcGFyOworfSB2Y3B1X2d1ZXN0
X2NvbnRleHRfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHZjcHVfZ3Vlc3RfY29udGV4
dF90KTsKKwordHlwZWRlZiBzdHJ1Y3QgY3B1X3VzZXJfcmVncyB7CisgICAgICAgIHVuc2ln
bmVkIGxvbmcgICByMDsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxOworICAgICAgICB1
bnNpZ25lZCBsb25nICAgcjI7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByMzsKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHI0OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjU7Cisg
ICAgICAgIHVuc2lnbmVkIGxvbmcgICByNjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHI3
OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjg7CisgICAgICAgIHVuc2lnbmVkIGxvbmcg
ICByOTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMDsKKyAgICAgICAgdW5zaWduZWQg
bG9uZyAgIHIxMTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMjsKKyAgICAgICAgdW5z
aWduZWQgbG9uZyAgIHIxMzsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxNDsKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHIxNTsKKwl1bnNpZ25lZCBsb25nCXBzcjsKK30gY3B1X3Vz
ZXJfcmVnc190OworREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoY3B1X3VzZXJfcmVnc190KTsK
KwordHlwZWRlZiBzdHJ1Y3QgYXJjaF92Y3B1X2luZm8geworCXVuc2lnbmVkIGxvbmcJc3A7
CisJdW5zaWduZWQgbG9uZwlscjsKKwl1bnNpZ25lZCBsb25nCWNwc3I7CisJdW5zaWduZWQg
bG9uZwlzcHNyOworCXVuc2lnbmVkIGxvbmcJY3I7CisJdW5zaWduZWQgbG9uZwljcGFyOwor
CXVuc2lnbmVkIGxvbmcJZGFjcjsKKwl1bnNpZ25lZCBsb25nCXBpZHI7CisJdW5zaWduZWQg
bG9uZwlmYXI7CisJdW5zaWduZWQgbG9uZwlmc3I7CisJdW5zaWduZWQgbG9uZwlyZXNlcnZl
ZDEwOworCXVuc2lnbmVkIGxvbmcJcmVzZXJ2ZWQxMTsKKwl1bnNpZ25lZCBsb25nCXJlc2Vy
dmVkMTI7CisJdW5zaWduZWQgbG9uZwlyZXNlcnZlZDEzOworCXVuc2lnbmVkIGxvbmcJcmVz
ZXJ2ZWQxNDsKK30gYXJjaF92Y3B1X2luZm9fdDsKKworI2RlZmluZSBYRU5fTEVHQUNZX01B
WF9WQ1BVUwk0CisKK3R5cGVkZWYgc3RydWN0IGFyY2hfc2hhcmVkX2luZm8geworCXVuc2ln
bmVkIGxvbmcJcGxhdGZvcm07CisJdW5zaWduZWQgbG9uZwltYXhfcGZuOworCXVuc2lnbmVk
IGxvbmcJcGZuX3RvX21mbl9mcmFtZV9saXN0X2xpc3Q7Cit9IGFyY2hfc2hhcmVkX2luZm9f
dDsKKworI2RlZmluZSBFTEZfU0laRQkzMgorI2VuZGlmCisjZW5kaWYK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt12-0005uv-B5; Mon, 13 Feb 2012 10:20:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvoLn-0001cZ-RX
	for xen-devel@lists.xensource.com; Fri, 10 Feb 2012 11:09:12 +0000
Received: from [85.158.139.83:15024] by server-12.bemta-5.messagelabs.com id
	8F/A5-30830-6DAF43F4; Fri, 10 Feb 2012 11:09:10 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328872148!14511602!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MjU4Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10799 invoked from network); 10 Feb 2012 11:09:09 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Feb 2012 11:09:09 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RvoLh-0002mw-BY from Paul_Brook@mentor.com ;
	Fri, 10 Feb 2012 03:09:05 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2012 11:09:04 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 8AFCD6EE61;
	Fri, 10 Feb 2012 11:09:03 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 10 Feb 2012 11:09:02 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202100952.26104.paul@codesourcery.com>
	<4F34F567.3040309@redhat.com>
In-Reply-To: <4F34F567.3040309@redhat.com>
MIME-Version: 1.0
Message-Id: <201202101109.03374.paul@codesourcery.com>
X-OriginalArrivalTime: 10 Feb 2012 11:09:04.0309 (UTC)
	FILETIME=[6660EE50:01CCE7E4]
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: avi@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >> >  At least the floppy DMA engine is fine with it, it uses idle bottom
> >> >  halves (which are a hack and could be replaced by timers, but that's
> >> >  not relevant now).
> > 
> > I thought idle bottom halves were one of the things that made this timout
> > necessary.  How else are they going to get run?
> 
> The timeout is reduced to 10 ms when an idle bottom half is scheduled.
> See qemu_bh_update_timeout in async.c.

Ah, I see.  Idle BH are indeed a nasty hack that should be removed, but not 
directly relevant to this 1s timeout.

I don't think this changes my overall conlusion:  Either we need this timeout 
to poll below the user-thinks-qemu-died threshold, or we should be blocking 
indefinitely.

Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt14-0005vm-DJ; Mon, 13 Feb 2012 10:20:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqiv-00039v-GE
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:53:22 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329119591!14532228!2
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19414 invoked from network); 13 Feb 2012 07:53:14 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-8.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:53:14 -0000
Received: from epcpsbge7.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB0031FN7WRKB0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:10 +0900 (KST)
Message-id: <0LZB0032AN8MRKB0@mailout2.samsung.com>
X-AuditID: cbfee611-b7b12ae0000036c1-4c-4f38c1224dce
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge7.samsung.com (EPCPMTA) with SMTP id 5B.09.14017.221C83F4;
	Mon, 13 Feb 2012 16:52:02 +0900 (KST)
Date: Mon, 13 Feb 2012 07:53:10 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213074940046@jm77.ryu
Msgkey: 20120213074940046@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213074805604@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 02/14] arm: import the files required to "arm"
	port.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <23931488.69631329119586906.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBvcnQgdGhlIGZpbGVzIHJlcXVpcmVkIHRvICJhcm0iIHBvcnQuDQoNCmNvbmZpZy9h
cm0ubWsgICAgICAgICAgICAgICAgICAgICAgfCAgIDI4ICsrKw0KIHhlbi9hcmNoL2FybS9NYWtl
ZmlsZSAgICAgICAgICAgICAgfCAgIDQ3ICsrKysrDQogeGVuL2FyY2gvYXJtL1J1bGVzLm1rICAg
ICAgICAgICAgICB8ICAgMjUgKysrDQogeGVuL2FyY2gvYXJtL2xpYi9NYWtlZmlsZSAgICAgICAg
ICB8ICAgMTEgKw0KIHhlbi9hcmNoL2FybS9saWIvYXNobGRpMy5TICAgICAgICAgfCAgIDQ1ICsr
KysrDQogeGVuL2FyY2gvYXJtL2xpYi9hc2hyZGkzLlMgICAgICAgICB8ICAgNDYgKysrKysNCiB4
ZW4vYXJjaC9hcm0vbGliL2JwYWJpLWFzbS5TICAgICAgIHwgICA1NSArKysrKysNCiB4ZW4vYXJj
aC9hcm0vbGliL2JwYWJpLmMgICAgICAgICAgIHwgICA1MSArKysrKysNCiB4ZW4vYXJjaC9hcm0v
bGliL2NsZWFyYml0LlMgICAgICAgIHwgICAyNCArKw0KIHhlbi9hcmNoL2FybS9saWIvY29weV90
ZW1wbGF0ZS5TICAgfCAgMjU1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9h
cmNoL2FybS9saWIvZGVsYXkuUyAgICAgICAgICAgfCAgICA3ICsNCiB4ZW4vYXJjaC9hcm0vbGli
L2RpdjY0LlMgICAgICAgICAgIHwgIDE5OSArKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4v
YXJjaC9hcm0vbGliL2ZpbmRiaXQuUyAgICAgICAgIHwgICA4MSArKysrKysrKysNCiB4ZW4vYXJj
aC9hcm0vbGliL2djY2xpYi5oICAgICAgICAgIHwgICAzMyArKysrDQogeGVuL2FyY2gvYXJtL2xp
Yi9nZXR1c2VyLlMgICAgICAgICB8ICAgNzcgKysrKysrKysrDQogeGVuL2FyY2gvYXJtL2xpYi9s
aWIxZnVuY3MuUyAgICAgICB8ICAyNTYgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0K
IHhlbi9hcmNoL2FybS9saWIvbG9uZ2xvbmcuaCAgICAgICAgfCAgMTgzICsrKysrKysrKysrKysr
KysrKysrKysNCiB4ZW4vYXJjaC9hcm0vbGliL2xzaHJkaTMuUyAgICAgICAgIHwgICAxNyArKw0K
IHhlbi9hcmNoL2FybS9saWIvbWF0aC5jICAgICAgICAgICAgfCAgICAzICsNCiB4ZW4vYXJjaC9h
cm0vbGliL21lbWNoci5TICAgICAgICAgIHwgICAxNCArDQogeGVuL2FyY2gvYXJtL2xpYi9tZW1j
cHkuUyAgICAgICAgICB8ICAgNjAgKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvbWVtbW92ZS5T
ICAgICAgICAgfCAgMjA3ICsrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0v
bGliL21lbW9yeS5TICAgICAgICAgIHwgIDQyMSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vbGliL21lbXNldC5TICAgICAg
ICAgIHwgICA2OSArKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvbWVtemVyby5TICAgICAgICAg
fCAgIDcxICsrKysrKysrDQogeGVuL2FyY2gvYXJtL2xpYi9tdWxkaTMuYyAgICAgICAgICB8ICAg
ODYgKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvcHV0dXNlci5TICAgICAgICAgfCAgIDc1
ICsrKysrKysrKw0KIHhlbi9hcmNoL2FybS9saWIvc2V0Yml0LlMgICAgICAgICAgfCAgIDIyICsr
DQogeGVuL2FyY2gvYXJtL2xpYi9zdHJjaHIuUyAgICAgICAgICB8ICAgMTUgKw0KIHhlbi9hcmNo
L2FybS9saWIvdGVzdGNoYW5nZWJpdC5TICAgfCAgIDIyICsrDQogeGVuL2FyY2gvYXJtL2xpYi90
ZXN0Y2xlYXJiaXQuUyAgICB8ICAgMjIgKysNCiB4ZW4vYXJjaC9hcm0vbGliL3Rlc3RzZXRiaXQu
UyAgICAgIHwgICAyMCArKw0KIHhlbi9hcmNoL2FybS9saWIvdWFjY2Vzcy5TICAgICAgICAgfCAg
Njg0ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2FyY2gvYXJtL2xpYi91ZGl2ZGkz
LmMgICAgICAgICB8ICAyNDIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJj
aC9hcm0vbGliL3VsZGl2bW9kLlMgICAgICAgIHwgIDE0OCArKysrKysrKysrKysrKysrKw0KIHhl
bi9hcmNoL2FybS90ZWdyYS9NYWtlZmlsZSAgICAgICAgfCAgICAxICsNCiB4ZW4vYXJjaC9hcm0v
dGVncmEvUnVsZXMubWsgICAgICAgIHwgICAgMSArDQogeGVuL2FyY2gvYXJtL3RlZ3JhL2R1bW15
LmMgICAgICAgICB8ICAgIDMgKw0KIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUgICAgICAgICAg
fCAgIDE5ICsrDQogeGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jICAgICB8ICAyMTIgKysr
KysrKysrKysrKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vYXJjaF9kb21jdGwuYyAg
ICAgfCAgIDQzICsrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9hcmNoX3N5c2N0bC5jICAgICB8ICAg
MzggKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vYXNtLW9mZnNldHMuYyAgICAgfCAgIDQwICsrKysN
CiB4ZW4vYXJjaC9hcm0veGVuL2J1Zy5jICAgICAgICAgICAgIHwgICAzMiArKysNCiB4ZW4vYXJj
aC9hcm0veGVuL2NwdS5jICAgICAgICAgICAgIHwgICA5NyArKysrKysrKysrKw0KIHhlbi9hcmNo
L2FybS94ZW4vY3Jhc2guYyAgICAgICAgICAgfCAgIDI1ICsrKw0KIHhlbi9hcmNoL2FybS94ZW4v
ZG9tYWluX2J1aWxkLmMgICAgfCAgIDQ3ICsrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9kb21haW5f
cGFnZS5jICAgICB8ICAgMjIgKysNCiB4ZW4vYXJjaC9hcm0veGVuL2ZhdWx0LmMgICAgICAgICAg
IHwgIDEyMyArKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vZ3JhbnRfdGFibGUuYyAg
ICAgfCAgIDUzICsrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vaW9tbXUuYyAgICAgICAgICAgfCAg
IDI0ICsrDQogeGVuL2FyY2gvYXJtL3hlbi9pcnEuYyAgICAgICAgICAgICB8ICAgODQgKysrKysr
KysrKw0KIHhlbi9hcmNoL2FybS94ZW4vbWFjaGluZV9rZXhlYy5jICAgfCAgIDMxICsrKw0KIHhl
bi9hcmNoL2FybS94ZW4vbW0uYyAgICAgICAgICAgICAgfCAgMTk0ICsrKysrKysrKysrKysrKysr
KysrKysrDQogeGVuL2FyY2gvYXJtL3hlbi9wMm0uYyAgICAgICAgICAgICB8ICAgNDQgKysrKysN
CiB4ZW4vYXJjaC9hcm0veGVuL3BjaS5jICAgICAgICAgICAgIHwgICA3NCArKysrKysrKw0KIHhl
bi9hcmNoL2FybS94ZW4vcGVyZm1vbi5jICAgICAgICAgfCAgIDI2ICsrKw0KIHhlbi9hcmNoL2Fy
bS94ZW4vc2V0dXAuYyAgICAgICAgICAgfCAgIDY0ICsrKysrKysNCiB4ZW4vYXJjaC9hcm0veGVu
L3NodXRkb3duLmMgICAgICAgIHwgICAzOCArKysrDQogeGVuL2FyY2gvYXJtL3hlbi90aW1lLmMg
ICAgICAgICAgICB8ICAgODMgKysrKysrKysrKw0KIHhlbi9hcmNoL2FybS94ZW4vdGxiLmMgICAg
ICAgICAgICAgfCAgIDI2ICsrKw0KIHhlbi9hcmNoL2FybS94ZW4veGVuLmxkcy5TICAgICAgICAg
fCAgMTU5ICsrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2FjcGkuaCAg
ICAgICAgIHwgICAgOCArDQogeGVuL2luY2x1ZGUvYXNtLWFybS9hc20tbWFjcm9zLmggICB8ICAx
MDYgKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9hdG9taWMuaCAgICAgICB8ICAx
NzkgKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9iaXRvcHMuaCAg
ICAgICB8ICAxOTMgKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJt
L2J1Zy5oICAgICAgICAgIHwgICAzMiArKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2J5dGVvcmRl
ci5oICAgIHwgICAgOSArDQogeGVuL2luY2x1ZGUvYXNtLWFybS9jYWNoZS5oICAgICAgICB8ICAg
MTEgKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vY29uZmlnLmggICAgICAgfCAgIDYxICsrKysrKysN
CiB4ZW4vaW5jbHVkZS9hc20tYXJtL2NwdS1kb21haW4uaCAgIHwgICAzOSArKysrDQogeGVuL2lu
Y2x1ZGUvYXNtLWFybS9jdXJyZW50LmggICAgICB8ICAgNzMgKysrKysrKysNCiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL2RlYnVnZ2VyLmggICAgIHwgICAyNCArKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0v
ZGVsYXkuaCAgICAgICAgfCAgICA2ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RpdjY0LmggICAg
ICAgIHwgICA0MyArKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmggICAgICAgfCAg
IDc5ICsrKysrKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vZWxmLmggICAgICAgICAgfCAgIDUz
ICsrKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vZXZlbnQuaCAgICAgICAgfCAgIDM5ICsrKysN
CiB4ZW4vaW5jbHVkZS9hc20tYXJtL2ZsdXNodGxiLmggICAgIHwgICAyNSArKysNCiB4ZW4vaW5j
bHVkZS9hc20tYXJtL2dyYW50X3RhYmxlLmggIHwgICA2MiArKysrKysrDQogeGVuL2luY2x1ZGUv
YXNtLWFybS9ndWVzdF9hY2Nlc3MuaCB8ICAxMzYgKysrKysrKysrKysrKysrKw0KIHhlbi9pbmNs
dWRlL2FzbS1hcm0vaGFyZGlycS5oICAgICAgfCAgIDIxICsrDQogeGVuL2luY2x1ZGUvYXNtLWFy
bS9oeXBlcmNhbGwuaCAgICB8ICAgNjggKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2lu
aXQuaCAgICAgICAgIHwgICAgNCArDQogeGVuL2luY2x1ZGUvYXNtLWFybS9pby5oICAgICAgICAg
ICB8ICAgMzIgKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9pb2NhcC5oICAgICAgICB8ICAgMTUg
Kw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vaW9tbXUuaCAgICAgICAgfCAgIDE0ICsNCiB4ZW4vaW5j
bHVkZS9hc20tYXJtL2lycS5oICAgICAgICAgIHwgICA1MCArKysrKysNCiB4ZW4vaW5jbHVkZS9h
c20tYXJtL21tLmggICAgICAgICAgIHwgIDIzNyArKysrKysrKysrKysrKysrKysrKysrKysrKysr
DQogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCAgICAgICAgICB8ICAgMTEgKw0KIHhlbi9pbmNs
dWRlL2FzbS1hcm0vbXVsdGljYWxsLmggICAgfCAgICA5ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJt
L251bWEuaCAgICAgICAgIHwgICAyMSArKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vcDJtLmggICAg
ICAgICAgfCAgIDEwICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BhZ2UuaCAgICAgICAgIHwgICA5
NSArKysrKysrKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vcGNpLmggICAgICAgICAgfCAgICA5
ICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BlcmNwdS5oICAgICAgIHwgICAxNiArDQogeGVuL2lu
Y2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaCAgICB8ICAyMTkgKysrKysrKysrKysrKysrKysrKysr
KysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3JlZ3MuaCAgICAgICAgIHwgICAxNyArKw0KIHhl
bi9pbmNsdWRlL2FzbS1hcm0vc21wLmggICAgICAgICAgfCAgIDI4ICsrKw0KIHhlbi9pbmNsdWRl
L2FzbS1hcm0vc29mdGlycS5oICAgICAgfCAgIDExICsNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3Nw
aW5sb2NrLmggICAgIHwgIDIwMCArKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL3N0cmluZy5oICAgICAgIHwgICA0OSArKysrKw0KIHhlbi9pbmNsdWRlL2FzbS1h
cm0vc3lzdGVtLmggICAgICAgfCAgMTQ4ICsrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUv
YXNtLWFybS90ZWdyYS9jb25maWcuaCB8ICAgMTEgKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGlt
ZS5oICAgICAgICAgfCAgIDI0ICsrDQogeGVuL2luY2x1ZGUvYXNtLWFybS90cmFjZS5oICAgICAg
ICB8ICAgIDYgKw0KIHhlbi9pbmNsdWRlL2FzbS1hcm0vdHlwZXMuaCAgICAgICAgfCAgIDU4ICsr
KysrKysNCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3hlbm9wcm9mLmggICAgIHwgICA0MyArKysrKw0K
IHhlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oICAgICAgfCAgMTgwICsrKysrKysrKysrKysr
KysrKysrKw0KIDEwOSBmaWxlcyBjaGFuZ2VkLCA4MDA4IGluc2VydGlvbnMoKyksIDAgZGVsZXRp
b25zKC0pDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29t
Pg0KDQo=


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch02.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch02.diff"


YXJtOiBpbXBvcnQgdGhlIGZpbGVzIHJlcXVpcmVkIHRvICJhcm0iIHBvcnQuCgogY29uZmln
L2FybS5tayAgICAgICAgICAgICAgICAgICAgICB8ICAgMjggKysrCiB4ZW4vYXJjaC9hcm0v
TWFrZWZpbGUgICAgICAgICAgICAgIHwgICA0NyArKysrKwogeGVuL2FyY2gvYXJtL1J1bGVz
Lm1rICAgICAgICAgICAgICB8ICAgMjUgKysrCiB4ZW4vYXJjaC9hcm0vbGliL01ha2VmaWxl
ICAgICAgICAgIHwgICAxMSArCiB4ZW4vYXJjaC9hcm0vbGliL2FzaGxkaTMuUyAgICAgICAg
IHwgICA0NSArKysrKwogeGVuL2FyY2gvYXJtL2xpYi9hc2hyZGkzLlMgICAgICAgICB8ICAg
NDYgKysrKysKIHhlbi9hcmNoL2FybS9saWIvYnBhYmktYXNtLlMgICAgICAgfCAgIDU1ICsr
KysrKwogeGVuL2FyY2gvYXJtL2xpYi9icGFiaS5jICAgICAgICAgICB8ICAgNTEgKysrKysr
CiB4ZW4vYXJjaC9hcm0vbGliL2NsZWFyYml0LlMgICAgICAgIHwgICAyNCArKwogeGVuL2Fy
Y2gvYXJtL2xpYi9jb3B5X3RlbXBsYXRlLlMgICB8ICAyNTUgKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL2RlbGF5LlMgICAgICAgICAgIHwgICAg
NyArCiB4ZW4vYXJjaC9hcm0vbGliL2RpdjY0LlMgICAgICAgICAgIHwgIDE5OSArKysrKysr
KysrKysrKysrKysrKysrKysKIHhlbi9hcmNoL2FybS9saWIvZmluZGJpdC5TICAgICAgICAg
fCAgIDgxICsrKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9nY2NsaWIuaCAgICAgICAgICB8
ICAgMzMgKysrKwogeGVuL2FyY2gvYXJtL2xpYi9nZXR1c2VyLlMgICAgICAgICB8ICAgNzcg
KysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL2xpYjFmdW5jcy5TICAgICAgIHwgIDI1NiAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL2xvbmds
b25nLmggICAgICAgIHwgIDE4MyArKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9h
cm0vbGliL2xzaHJkaTMuUyAgICAgICAgIHwgICAxNyArKwogeGVuL2FyY2gvYXJtL2xpYi9t
YXRoLmMgICAgICAgICAgICB8ICAgIDMgKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1jaHIuUyAg
ICAgICAgICB8ICAgMTQgKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1jcHkuUyAgICAgICAgICB8
ICAgNjAgKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1tb3ZlLlMgICAgICAgICB8ICAy
MDcgKysrKysrKysrKysrKysrKysrKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9tZW1vcnku
UyAgICAgICAgICB8ICA0MjEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9hcm0vbGliL21lbXNldC5TICAgICAgICAgIHwg
ICA2OSArKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9tZW16ZXJvLlMgICAgICAgICB8ICAg
NzEgKysrKysrKysKIHhlbi9hcmNoL2FybS9saWIvbXVsZGkzLmMgICAgICAgICAgfCAgIDg2
ICsrKysrKysrKysKIHhlbi9hcmNoL2FybS9saWIvcHV0dXNlci5TICAgICAgICAgfCAgIDc1
ICsrKysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi9zZXRiaXQuUyAgICAgICAgICB8ICAgMjIg
KysKIHhlbi9hcmNoL2FybS9saWIvc3RyY2hyLlMgICAgICAgICAgfCAgIDE1ICsKIHhlbi9h
cmNoL2FybS9saWIvdGVzdGNoYW5nZWJpdC5TICAgfCAgIDIyICsrCiB4ZW4vYXJjaC9hcm0v
bGliL3Rlc3RjbGVhcmJpdC5TICAgIHwgICAyMiArKwogeGVuL2FyY2gvYXJtL2xpYi90ZXN0
c2V0Yml0LlMgICAgICB8ICAgMjAgKysKIHhlbi9hcmNoL2FybS9saWIvdWFjY2Vzcy5TICAg
ICAgICAgfCAgNjg0ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vYXJjaC9h
cm0vbGliL3VkaXZkaTMuYyAgICAgICAgIHwgIDI0MiArKysrKysrKysrKysrKysrKysrKysr
KysrKysrKwogeGVuL2FyY2gvYXJtL2xpYi91bGRpdm1vZC5TICAgICAgICB8ICAxNDggKysr
KysrKysrKysrKysrKysKIHhlbi9hcmNoL2FybS90ZWdyYS9NYWtlZmlsZSAgICAgICAgfCAg
ICAxICsKIHhlbi9hcmNoL2FybS90ZWdyYS9SdWxlcy5tayAgICAgICAgfCAgICAxICsKIHhl
bi9hcmNoL2FybS90ZWdyYS9kdW1teS5jICAgICAgICAgfCAgICAzICsKIHhlbi9hcmNoL2Fy
bS94ZW4vTWFrZWZpbGUgICAgICAgICAgfCAgIDE5ICsrCiB4ZW4vYXJjaC9hcm0veGVuL2Fy
Y2hfZG9tYWluLmMgICAgIHwgIDIxMiArKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4v
YXJjaC9hcm0veGVuL2FyY2hfZG9tY3RsLmMgICAgIHwgICA0MyArKysrKwogeGVuL2FyY2gv
YXJtL3hlbi9hcmNoX3N5c2N0bC5jICAgICB8ICAgMzggKysrKwogeGVuL2FyY2gvYXJtL3hl
bi9hc20tb2Zmc2V0cy5jICAgICB8ICAgNDAgKysrKwogeGVuL2FyY2gvYXJtL3hlbi9idWcu
YyAgICAgICAgICAgICB8ICAgMzIgKysrCiB4ZW4vYXJjaC9hcm0veGVuL2NwdS5jICAgICAg
ICAgICAgIHwgICA5NyArKysrKysrKysrKwogeGVuL2FyY2gvYXJtL3hlbi9jcmFzaC5jICAg
ICAgICAgICB8ICAgMjUgKysrCiB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jICAg
IHwgICA0NyArKysrKwogeGVuL2FyY2gvYXJtL3hlbi9kb21haW5fcGFnZS5jICAgICB8ICAg
MjIgKysKIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYyAgICAgICAgICAgfCAgMTIzICsrKysr
KysrKysrKysrCiB4ZW4vYXJjaC9hcm0veGVuL2dyYW50X3RhYmxlLmMgICAgIHwgICA1MyAr
KysrKysKIHhlbi9hcmNoL2FybS94ZW4vaW9tbXUuYyAgICAgICAgICAgfCAgIDI0ICsrCiB4
ZW4vYXJjaC9hcm0veGVuL2lycS5jICAgICAgICAgICAgIHwgICA4NCArKysrKysrKysrCiB4
ZW4vYXJjaC9hcm0veGVuL21hY2hpbmVfa2V4ZWMuYyAgIHwgICAzMSArKysKIHhlbi9hcmNo
L2FybS94ZW4vbW0uYyAgICAgICAgICAgICAgfCAgMTk0ICsrKysrKysrKysrKysrKysrKysr
KysrCiB4ZW4vYXJjaC9hcm0veGVuL3AybS5jICAgICAgICAgICAgIHwgICA0NCArKysrKwog
eGVuL2FyY2gvYXJtL3hlbi9wY2kuYyAgICAgICAgICAgICB8ICAgNzQgKysrKysrKysKIHhl
bi9hcmNoL2FybS94ZW4vcGVyZm1vbi5jICAgICAgICAgfCAgIDI2ICsrKwogeGVuL2FyY2gv
YXJtL3hlbi9zZXR1cC5jICAgICAgICAgICB8ICAgNjQgKysrKysrKwogeGVuL2FyY2gvYXJt
L3hlbi9zaHV0ZG93bi5jICAgICAgICB8ICAgMzggKysrKwogeGVuL2FyY2gvYXJtL3hlbi90
aW1lLmMgICAgICAgICAgICB8ICAgODMgKysrKysrKysrKwogeGVuL2FyY2gvYXJtL3hlbi90
bGIuYyAgICAgICAgICAgICB8ICAgMjYgKysrCiB4ZW4vYXJjaC9hcm0veGVuL3hlbi5sZHMu
UyAgICAgICAgIHwgIDE1OSArKysrKysrKysrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20t
YXJtL2FjcGkuaCAgICAgICAgIHwgICAgOCArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2FzbS1t
YWNyb3MuaCAgIHwgIDEwNiArKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vYXRv
bWljLmggICAgICAgfCAgMTc5ICsrKysrKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUv
YXNtLWFybS9iaXRvcHMuaCAgICAgICB8ICAxOTMgKysrKysrKysrKysrKysrKysrKysrKysK
IHhlbi9pbmNsdWRlL2FzbS1hcm0vYnVnLmggICAgICAgICAgfCAgIDMyICsrKwogeGVuL2lu
Y2x1ZGUvYXNtLWFybS9ieXRlb3JkZXIuaCAgICB8ICAgIDkgKwogeGVuL2luY2x1ZGUvYXNt
LWFybS9jYWNoZS5oICAgICAgICB8ICAgMTEgKwogeGVuL2luY2x1ZGUvYXNtLWFybS9jb25m
aWcuaCAgICAgICB8ICAgNjEgKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9jcHUtZG9t
YWluLmggICB8ICAgMzkgKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmggICAg
ICB8ICAgNzMgKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vZGVidWdnZXIuaCAgICAg
fCAgIDI0ICsrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RlbGF5LmggICAgICAgIHwgICAgNiAr
CiB4ZW4vaW5jbHVkZS9hc20tYXJtL2RpdjY0LmggICAgICAgIHwgICA0MyArKysrKwogeGVu
L2luY2x1ZGUvYXNtLWFybS9kb21haW4uaCAgICAgICB8ICAgNzkgKysrKysrKysrCiB4ZW4v
aW5jbHVkZS9hc20tYXJtL2VsZi5oICAgICAgICAgIHwgICA1MyArKysrKysKIHhlbi9pbmNs
dWRlL2FzbS1hcm0vZXZlbnQuaCAgICAgICAgfCAgIDM5ICsrKysKIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vZmx1c2h0bGIuaCAgICAgfCAgIDI1ICsrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9n
cmFudF90YWJsZS5oICB8ICAgNjIgKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9ndWVz
dF9hY2Nlc3MuaCB8ICAxMzYgKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFy
bS9oYXJkaXJxLmggICAgICB8ICAgMjEgKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vaHlwZXJj
YWxsLmggICAgfCAgIDY4ICsrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2luaXQuaCAg
ICAgICAgIHwgICAgNCArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL2lvLmggICAgICAgICAgIHwg
ICAzMiArKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vaW9jYXAuaCAgICAgICAgfCAgIDE1ICsK
IHhlbi9pbmNsdWRlL2FzbS1hcm0vaW9tbXUuaCAgICAgICAgfCAgIDE0ICsKIHhlbi9pbmNs
dWRlL2FzbS1hcm0vaXJxLmggICAgICAgICAgfCAgIDUwICsrKysrKwogeGVuL2luY2x1ZGUv
YXNtLWFybS9tbS5oICAgICAgICAgICB8ICAyMzcgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCAgICAgICAgICB8ICAgMTEgKwogeGVu
L2luY2x1ZGUvYXNtLWFybS9tdWx0aWNhbGwuaCAgICB8ICAgIDkgKwogeGVuL2luY2x1ZGUv
YXNtLWFybS9udW1hLmggICAgICAgICB8ICAgMjEgKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0v
cDJtLmggICAgICAgICAgfCAgIDEwICsKIHhlbi9pbmNsdWRlL2FzbS1hcm0vcGFnZS5oICAg
ICAgICAgfCAgIDk1ICsrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BjaS5oICAg
ICAgICAgIHwgICAgOSArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3BlcmNwdS5oICAgICAgIHwg
ICAxNiArCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3Byb2Nlc3Nvci5oICAgIHwgIDIxOSArKysr
KysrKysrKysrKysrKysrKysrKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9yZWdzLmggICAg
ICAgICB8ICAgMTcgKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vc21wLmggICAgICAgICAgfCAg
IDI4ICsrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9zb2Z0aXJxLmggICAgICB8ICAgMTEgKwog
eGVuL2luY2x1ZGUvYXNtLWFybS9zcGlubG9jay5oICAgICB8ICAyMDAgKysrKysrKysrKysr
KysrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL3N0cmluZy5oICAgICAgIHwgICA0
OSArKysrKwogeGVuL2luY2x1ZGUvYXNtLWFybS9zeXN0ZW0uaCAgICAgICB8ICAxNDggKysr
KysrKysrKysrKysrKysKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGVncmEvY29uZmlnLmggfCAg
IDExICsKIHhlbi9pbmNsdWRlL2FzbS1hcm0vdGltZS5oICAgICAgICAgfCAgIDI0ICsrCiB4
ZW4vaW5jbHVkZS9hc20tYXJtL3RyYWNlLmggICAgICAgIHwgICAgNiArCiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL3R5cGVzLmggICAgICAgIHwgICA1OCArKysrKysrCiB4ZW4vaW5jbHVkZS9h
c20tYXJtL3hlbm9wcm9mLmggICAgIHwgICA0MyArKysrKwogeGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gtYXJtLmggICAgICB8ICAxODAgKysrKysrKysrKysrKysrKysrKysrCiAxMDkgZmls
ZXMgY2hhbmdlZCwgODAwOCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQoKU2lnbmVk
LW9mZi1ieTogSmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CgpkaWZmIC1yIGU3
MDE0NjFiMTI1MSBjb25maWcvYXJtLm1rCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCisrKyBiL2NvbmZpZy9hcm0ubWsJRnJpIEZlYiAwMyAxNjowNzow
MyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMjggQEAKKyMKKyMgQ3Jvc3MgVG9vbCBjaGFpbiBj
b25maWd1cmF0aW9uCisjCitUT09MQ0hBSU5fUFJFRklYID0gL29wdC9hcm0tbm9uZS1saW51
eC1nbnVlYWJpLW9sZC9iaW4vYXJtLW5vbmUtbGludXgtZ251ZWFiaS0KKworIworIyBUb29s
Y2hhaW4gY29uZmlndXJhdGlvbgorIworQVMgICAgICAgICAgICAgID0gJChUT09MQ0hBSU5f
UFJFRklYKWFzCitMRCAgICAgICAgICAgICAgPSAkKFRPT0xDSEFJTl9QUkVGSVgpbGQKK0ND
ICAgICAgICAgICAgICA9ICQoVE9PTENIQUlOX1BSRUZJWClnY2MKK0NQUCAgICAgICAgICAg
ICA9ICQoVE9PTENIQUlOX1BSRUZJWClnY2MgLUUKK0FSICAgICAgICAgICAgICA9ICQoVE9P
TENIQUlOX1BSRUZJWClhcgorUkFOTElCICAgICAgICAgID0gJChUT09MQ0hBSU5fUFJFRklY
KXJhbmxpYgorTk0gICAgICAgICAgICAgID0gJChUT09MQ0hBSU5fUFJFRklYKW5tCitTVFJJ
UCAgICAgICAgICAgPSAkKFRPT0xDSEFJTl9QUkVGSVgpc3RyaXAKK09CSkNPUFkgICAgICAg
ICA9ICQoVE9PTENIQUlOX1BSRUZJWClvYmpjb3B5CitPQkpEVU1QICAgICAgICAgPSAkKFRP
T0xDSEFJTl9QUkVGSVgpb2JqZHVtcAorCitESVNURElSICAgICAgICAgPz0gJChYRU5fUk9P
VCkvZGlzdAorREVTVERJUiAgICAgICAgID89ICQoRElTVERJUikvaW5zdGFsbAorCitJTlNU
QUxMICAgICAgICAgPSBpbnN0YWxsCitJTlNUQUxMX0RJUiAgICAgPSAkKElOU1RBTEwpIC1k
IC1tMDc1NQorSU5TVEFMTF9EQVRBICAgID0gJChJTlNUQUxMKSAtbTA2NDQKK0lOU1RBTExf
UFJPRyAgICA9ICQoSU5TVEFMTCkgLW0wNzU1CisKK0NPTkZJR19BUk0JOj0geQpkaWZmIC1y
IGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vTWFrZWZpbGUKLS0tIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL01ha2VmaWxl
CUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQ3IEBACisjCisj
IHhlbi9hcmNoL2FybS9NYWtlZmlsZQorIworCitpZm5kZWYgVEFSR0VUX1NVQkFSQ0gKKyQo
ZXJyb3IgWEVOX1RBUkdFVF9TVUJBUkNIIG11c3QgYmUgc3VwcGxpZWQuIFNlZSBDb25maWcu
bWsgZmlsZSkKK2VuZGlmCisKK3N1YmRpci15ICs9ICQoVEFSR0VUX1NVQkFSQ0gpIHhlbiBs
aWIKKworT0JKQ09QWUZMQUdTICAgIDo9LU8gYmluYXJ5IC1SIC5ub3RlIC1SIC5jb21tZW50
IC1TCisKKyQoVEFSR0VUKTogJChUQVJHRVQpLXN5bXMKKwkkKE5NKSAtbiAkPCB8IGdyZXAg
LXYgJyBbYVV3XSAnID4gJChARCkvU3lzdGVtLm1hcAorCSQoT0JKQ09QWSkgLU8gYmluYXJ5
IC1SIC5ub3RlIC1SIC5jb21tZW50IC1TICQ8ICRACisKKyQoVEFSR0VUKS1zeW1zOiB4ZW4u
bGRzICQoQUxMX09CSlMpIAorCSQoTUFLRSkgLWYgJChCQVNFRElSKS9SdWxlcy5tayAkKEJB
U0VESVIpL2NvbW1vbi9zeW1ib2xzLWR1bW15Lm8KKwkkKExEKSAkKExERkxBR1MpIC1UIHhl
bi5sZHMgLU4gLU1hcCAkKEBEKS8uJChARikuMC5tYXAgJChBTExfT0JKUykgXAorCSQoQkFT
RURJUikvY29tbW9uL3N5bWJvbHMtZHVtbXkubyAtbyAkKEBEKS8uJChARikuMAorCSQoTk0p
IC1uICQoQEQpLy4kKEBGKS4wIHwgJChCQVNFRElSKS90b29scy9zeW1ib2xzID4kKEBEKS8u
JChARikuMC5TCisJJChNQUtFKSAtZiAkKEJBU0VESVIpL1J1bGVzLm1rICQoQEQpLy4kKEBG
KS4wLm8KKwkkKExEKSAkKExERkxBR1MpIC1UIHhlbi5sZHMgLU4gLU1hcCAkKEBEKS8uJChA
RikuMS5tYXAgJChBTExfT0JKUykgXAorCSQoQEQpLy4kKEBGKS4wLm8gLW8gJChARCkvLiQo
QEYpLjEKKwkkKE5NKSAtbiAkKEBEKS8uJChARikuMSB8ICQoQkFTRURJUikvdG9vbHMvc3lt
Ym9scyA+JChARCkvLiQoQEYpLjEuUworCSQoTUFLRSkgLWYgJChCQVNFRElSKS9SdWxlcy5t
ayAkKEBEKS8uJChARikuMS5vCisJJChMRCkgJChMREZMQUdTKSAtVCB4ZW4ubGRzIC1OIC1N
YXAgJEAubWFwICQoQUxMX09CSlMpIFwKKwkkKEBEKS8uJChARikuMS5vIC1vICRACisJcm0g
LWYgJChARCkvLiQoQEYpLlswLTldKgorCisKK3hlbi5sZHM6ICQoQkFTRURJUikvaW5jbHVk
ZS9hc20vYXJjaAorCSQoQ0MpIC1FICQoQ0ZMQUdTKSAtUCAkKEFGTEFHUykgLW8gJEAgeGVu
L3hlbi5sZHMuUworCitjbGVhbjo6IEZPUkNFCisJcm0gLWYgeGVuLWJpbiB4ZW4tc3ltcyB4
ZW4ubGRzIGFzbS1vZmZzZXRzLnMKKwlybSAtZiAqLm8gJChUQVJHRVRfU1VCQVJDSCkvKi5v
IGxpYi8qLm8geGVuLyoubyB4ZW4ubGRzCisJcm0gLWYgJChCQVNFRElSKS9pbmNsdWRlL2Fz
bS1hcm0vYXJjaAorCXJtIC1mICQoQkFTRURJUikvaW5jbHVkZS9hc20KKworYXNtLW9mZnNl
dHMuczogJChCQVNFRElSKS9pbmNsdWRlL2FzbS9hcmNoCisJJChDQykgJChDRkxBR1MpIC1T
IC1vICRAIHhlbi9hc20tb2Zmc2V0cy5jCisKKyQoQkFTRURJUikvaW5jbHVkZS9hc20vYXJj
aDoKKwlbIC1lICQoQkFTRURJUikvaW5jbHVkZS9hc20vYXJjaCBdIHx8IFwKKwlsbiAtc2Yg
JChCQVNFRElSKS9pbmNsdWRlL2FzbS8kKFRBUkdFVF9TVUJBUkNIKSAkKEJBU0VESVIpL2lu
Y2x1ZGUvYXNtL2FyY2gKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vUnVs
ZXMubWsKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIveGVuL2FyY2gvYXJtL1J1bGVzLm1rCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDI1IEBACisjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjCisjIGFybS1zcGVjaWZpYyBkZWZpbml0aW9ucworCisjCisjIElmIHlvdSBjaGFu
Z2UgYW55IG9mIHRoZXNlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyB0aGVuIHlvdSBtdXN0Cisj
ICdtYWtlIGNsZWFuJyBiZWZvcmUgcmVidWlsZGluZy4KKyMKKworaWZlcSAoJChUQVJHRVRf
U1VCQVJDSCksKQorJChlcnJvciAiWEVOX1RBUkdFVF9TVUJBUkNIIG11c3QgYmUgc3VwcGxp
ZWQuIikKK2VuZGlmCisKK3hlbm9wcm9mIDo9IHkKKworIyBFYWNoIFNvQyBtYXkgaGF2ZSBp
dHMgb3duIGJ1aWxkIHJ1bGVzCistaW5jbHVkZSAkKEJBU0VESVIpL2FyY2gvJChUQVJHRVRf
QVJDSCkvJChUQVJHRVRfU1VCQVJDSCkvUnVsZXMubWsKKworQ0ZMQUdTCSs9IC1tYWJpPWFh
cGNzLWxpbnV4IC1tbm8tdGh1bWItaW50ZXJ3b3JrIC1mbm8tYnVpbHRpbiAtZm5vLWNvbW1v
bgorQ0ZMQUdTICArPSAtbm9zdGRpbmMgLWZuby1zdHJpY3QtYWxpYXNpbmcgLW1uby10aHVt
Yi1pbnRlcndvcmsKK0NGTEFHUyAgKz0gLWl3aXRocHJlZml4IGluY2x1ZGUgLVduby1wb2lu
dGVyLWFyaXRoIC1waXBlCitDRkxBR1MgICs9IC1JJChCQVNFRElSKS9pbmNsdWRlIC1JJChC
QVNFRElSKS9pbmNsdWRlL3NlY3VyaXR5IC1JJChCQVNFRElSKS9pbmNsdWRlL3NlY3VyaXR5
L2NyeXB0bworQ0ZMQUdTCSs9ICQoQ0ZMQUdTLXkpCisKKworCmRpZmYgLXIgZTcwMTQ2MWIx
MjUxIHhlbi9hcmNoL2FybS9saWIvTWFrZWZpbGUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9NYWtlZmlsZQlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMSBAQAorb2JqLXkg
Kz0gZGl2NjQubworb2JqLXkgKz0gbWVtemVyby5vIG1lbXNldC5vIG1lbWNweS5vIG1lbWNo
ci5vIG1lbW1vdmUubworb2JqLXkgKz0gc3RyY2hyLm8gbGliMWZ1bmNzLm8gCitvYmoteSAr
PSBjbGVhcmJpdC5vIHRlc3RjaGFuZ2ViaXQubyB0ZXN0Y2xlYXJiaXQubyB0ZXN0c2V0Yml0
Lm8gc2V0Yml0Lm8gZmluZGJpdC5vCitvYmoteSArPSBnZXR1c2VyLm8gcHV0dXNlci5vIHVh
Y2Nlc3Mubworb2JqLXkgKz0gYXNobGRpMy5vIGFzaHJkaTMubworCitvYmoteSArPSBtdWxk
aTMubworb2JqLXkgKz0gZGVsYXkubworb2JqLXkgKz0gbHNocmRpMy5vIGJwYWJpLm8gYnBh
YmktYXNtLm8KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL2FzaGxk
aTMuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi94ZW4vYXJjaC9hcm0vbGliL2FzaGxkaTMuUwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSw0NSBAQAorLyogQ29weXJpZ2h0IDE5OTUsIDE5OTYsIDE5OTgs
IDE5OTksIDIwMDAsIDIwMDMsIDIwMDQsIDIwMDUKKyAgIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbiwgSW5jLgorCitUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAordW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBH
TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkgdGhlCitGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9yIChhdCB5b3VyIG9wdGlv
bikgYW55CitsYXRlciB2ZXJzaW9uLgorCitJbiBhZGRpdGlvbiB0byB0aGUgcGVybWlzc2lv
bnMgaW4gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCB0aGUKK0ZyZWUgU29mdHdh
cmUgRm91bmRhdGlvbiBnaXZlcyB5b3UgdW5saW1pdGVkIHBlcm1pc3Npb24gdG8gbGluayB0
aGUKK2NvbXBpbGVkIHZlcnNpb24gb2YgdGhpcyBmaWxlIGludG8gY29tYmluYXRpb25zIHdp
dGggb3RoZXIgcHJvZ3JhbXMsCithbmQgdG8gZGlzdHJpYnV0ZSB0aG9zZSBjb21iaW5hdGlv
bnMgd2l0aG91dCBhbnkgcmVzdHJpY3Rpb24gY29taW5nCitmcm9tIHRoZSB1c2Ugb2YgdGhp
cyBmaWxlLiAgKFRoZSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHJlc3RyaWN0aW9ucworZG8g
YXBwbHkgaW4gb3RoZXIgcmVzcGVjdHM7IGZvciBleGFtcGxlLCB0aGV5IGNvdmVyIG1vZGlm
aWNhdGlvbiBvZgordGhlIGZpbGUsIGFuZCBkaXN0cmlidXRpb24gd2hlbiBub3QgbGlua2Vk
IGludG8gYSBjb21iaW5lCitleGVjdXRhYmxlLikKKworVGhpcyBmaWxlIGlzIGRpc3RyaWJ1
dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dAorV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl
IHRoZSBHTlUKK0dlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKwor
WW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UKK2Fsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBzZWUgdGhlIGZpbGUgQ09Q
WUlORy4gIElmIG5vdCwgd3JpdGUgdG8KK3RoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24s
IDUxIEZyYW5rbGluIFN0cmVldCwgRmlmdGggRmxvb3IsCitCb3N0b24sIE1BIDAyMTEwLTEz
MDEsIFVTQS4gICovCisKKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxh
c20vYXNtLW1hY3Jvcy5oPgorCisjZGVmaW5lIGFsIHIwCisjZGVmaW5lIGFoIHIxCisKK0VO
VFJZKF9fYXNobGRpMykKK0VOVFJZKF9fYWVhYmlfbGxzbCkKKworCXN1YnMJcjMsIHIyLCAj
MzIKKwlyc2IJaXAsIHIyLCAjMzIKKwltb3ZtaQlhaCwgYWgsIGxzbCByMgorCW1vdnBsCWFo
LCBhbCwgbHNsIHIzCisJb3JybWkJYWgsIGFoLCBhbCwgbHNyIGlwCisJbW92CWFsLCBhbCwg
bHNsIHIyCisJbW92CXBjLCBscgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2Fy
bS9saWIvYXNocmRpMy5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvYXNocmRpMy5TCUZyaSBGZWIgMDMgMTY6
MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQ2IEBACisvKiBDb3B5cmlnaHQgMTk5NSwg
MTk5NiwgMTk5OCwgMTk5OSwgMjAwMCwgMjAwMywgMjAwNCwgMjAwNQorICAgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1RoaXMgZmlsZSBpcyBmcmVlIHNvZnR3YXJlOyB5
b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5IGl0Cit1bmRlciB0aGUgdGVy
bXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0
aGUKK0ZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0
IHlvdXIgb3B0aW9uKSBhbnkKK2xhdGVyIHZlcnNpb24uCisKK0luIGFkZGl0aW9uIHRvIHRo
ZSBwZXJtaXNzaW9ucyBpbiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIHRoZQor
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uIGdpdmVzIHlvdSB1bmxpbWl0ZWQgcGVybWlzc2lv
biB0byBsaW5rIHRoZQorY29tcGlsZWQgdmVyc2lvbiBvZiB0aGlzIGZpbGUgaW50byBjb21i
aW5hdGlvbnMgd2l0aCBvdGhlciBwcm9ncmFtcywKK2FuZCB0byBkaXN0cmlidXRlIHRob3Nl
IGNvbWJpbmF0aW9ucyB3aXRob3V0IGFueSByZXN0cmljdGlvbiBjb21pbmcKK2Zyb20gdGhl
IHVzZSBvZiB0aGlzIGZpbGUuICAoVGhlIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgcmVzdHJp
Y3Rpb25zCitkbyBhcHBseSBpbiBvdGhlciByZXNwZWN0czsgZm9yIGV4YW1wbGUsIHRoZXkg
Y292ZXIgbW9kaWZpY2F0aW9uIG9mCit0aGUgZmlsZSwgYW5kIGRpc3RyaWJ1dGlvbiB3aGVu
IG5vdCBsaW5rZWQgaW50byBhIGNvbWJpbmUKK2V4ZWN1dGFibGUuKQorCitUaGlzIGZpbGUg
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0
CitXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJh
bnR5IG9mCitNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV
UlBPU0UuICBTZWUgdGhlIEdOVQorR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBk
ZXRhaWxzLgorCitZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZQorYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IHNlZSB0
aGUgZmlsZSBDT1BZSU5HLiAgSWYgbm90LCB3cml0ZSB0bwordGhlIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbiwgNTEgRnJhbmtsaW4gU3RyZWV0LCBGaWZ0aCBGbG9vciwKK0Jvc3Rvbiwg
TUEgMDIxMTAtMTMwMSwgVVNBLiAgKi8KKworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgor
I2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisK
KyNkZWZpbmUgYWwgcjAKKyNkZWZpbmUgYWggcjEKKworRU5UUlkoX19hc2hyZGkzKQorRU5U
UlkoX19hZWFiaV9sYXNyKQorCisJc3VicwlyMywgcjIsICMzMgorCXJzYglpcCwgcjIsICMz
MgorCW1vdm1pCWFsLCBhbCwgbHNyIHIyCisJbW92cGwJYWwsIGFoLCBhc3IgcjMKKwlvcnJt
aQlhbCwgYWwsIGFoLCBsc2wgaXAKKwltb3YJYWgsIGFoLCBhc3IgcjIKKwltb3YJcGMsIGxy
CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL2xpYi9icGFiaS1hc20uUwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
YXJjaC9hcm0vbGliL2JwYWJpLWFzbS5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDU1IEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUg
PGFzbS9hc20tbWFjcm9zLmg+CisKKyNpZmRlZiBfX0FSTUVCX18KKyNkZWZpbmUgeHhoIHIw
CisjZGVmaW5lIHh4bCByMQorI2RlZmluZSB5eWggcjIKKyNkZWZpbmUgeXlsIHIzCisjZWxz
ZQorI2RlZmluZSB4eGggcjEKKyNkZWZpbmUgeHhsIHIwCisjZGVmaW5lIHl5aCByMworI2Rl
ZmluZSB5eWwgcjIKKyNlbmRpZgkKKwkKKyNpZiAwCitFTlRSWShfX2FlYWJpX2xkaXZtb2Qp
CisJc3RtZmQJc3AhLCB7cjQtcjcsIHIxMSwgcjE0fQorCW1vdglyNiwgcjAKKwltb3YJcjcs
IHIxCisJbW92CXI1LCByMgorCW1vdglyNCwgcjMKKworCWJsCV9fZGl2ZGkzCisKKwltdWwJ
cjQsIHIwLCByNAorCW1sYQlyMTIsIHI1LCByMSwgcjQKKworCXVtdWxsCXIyLCByMywgcjAs
IHI1CisJYWRkCXIzLCByMTIsIHIzCisJc3VicwlyMiwgcjUsIHIyCisJc2JjCXIzLCByNywg
cjMKKwlsZG1mZAlzcCEsIHtyNC1yNywgcjExLCByMTR9CisKKwlieAlyMTQKKyNlbmRpZgor
CitFTlRSWShfX2FlYWJpX2xkaXZtb2QpCisJc3ViCXNwLCBzcCwgIzgKKwlzdG1mZAlzcCEs
IHtzcCwgbHJ9CisJYmwJX19nbnVfbGRpdm1vZF9oZWxwZXIgKFBMVCkKKwlsZHIJbHIsIFtz
cCwgIzRdCisJYWRkCXNwLCBzcCwgIzgKKwlsZG1mZAlzcCEsIHtyMiwgcjN9CisJYngJbHIK
KwkKK0VOVFJZKF9fYWVhYmlfdWxkaXZtb2QpCisJc3ViCXNwLCBzcCwgIzgKKwlzdG1mZAlz
cCEsIHtzcCwgbHJ9CisJYmwJX19nbnVfdWxkaXZtb2RfaGVscGVyIChQTFQpCisJbGRyCWxy
LCBbc3AsICM0XQorCWFkZAlzcCwgc3AsICM4CisJbGRtZmQJc3AhLCB7cjIsIHIzfQorCWJ4
CWxyCisJCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvYnBhYmkuYwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
YXJjaC9hcm0vbGliL2JwYWJpLmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBA
IC0wLDAgKzEsNTEgQEAKKy8qIE1pc2NlbGxhbmVvdXMgQlBBQkkgZnVuY3Rpb25zLgorCisg
ICBDb3B5cmlnaHQgKEMpIDIwMDMsIDIwMDQgIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwg
SW5jLgorICAgQ29udHJpYnV0ZWQgYnkgQ29kZVNvdXJjZXJ5LCBMTEMuCisKKyAgIFRoaXMg
ZmlsZSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5IGl0CisgICB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0aGUKKyAgIEZyZWUgU29mdHdhcmUgRm91bmRh
dGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkKKyAgIGxh
dGVyIHZlcnNpb24uCisKKyAgIEluIGFkZGl0aW9uIHRvIHRoZSBwZXJtaXNzaW9ucyBpbiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIHRoZQorICAgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uIGdpdmVzIHlvdSB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0byBsaW5rIHRoZQor
ICAgY29tcGlsZWQgdmVyc2lvbiBvZiB0aGlzIGZpbGUgaW50byBjb21iaW5hdGlvbnMgd2l0
aCBvdGhlciBwcm9ncmFtcywKKyAgIGFuZCB0byBkaXN0cmlidXRlIHRob3NlIGNvbWJpbmF0
aW9ucyB3aXRob3V0IGFueSByZXN0cmljdGlvbiBjb21pbmcKKyAgIGZyb20gdGhlIHVzZSBv
ZiB0aGlzIGZpbGUuICAoVGhlIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgcmVzdHJpY3Rpb25z
CisgICBkbyBhcHBseSBpbiBvdGhlciByZXNwZWN0czsgZm9yIGV4YW1wbGUsIHRoZXkgY292
ZXIgbW9kaWZpY2F0aW9uIG9mCisgICB0aGUgZmlsZSwgYW5kIGRpc3RyaWJ1dGlvbiB3aGVu
IG5vdCBsaW5rZWQgaW50byBhIGNvbWJpbmUKKyAgIGV4ZWN1dGFibGUuKQorCisgICBUaGlz
IGZpbGUgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1
bCwgYnV0CisgICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs
aWVkIHdhcnJhbnR5IG9mCisgICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQ
QVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorICAgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorCisgICBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg
YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICAgYWxvbmcgd2l0
aCB0aGlzIHByb2dyYW07IHNlZSB0aGUgZmlsZSBDT1BZSU5HLiAgSWYgbm90LCB3cml0ZSB0
bworICAgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgNTkgVGVtcGxlIFBsYWNlIC0g
U3VpdGUgMzMwLAorICAgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuICAqLworCitleHRl
cm4gbG9uZyBsb25nIF9fZGl2ZGkzIChsb25nIGxvbmcsIGxvbmcgbG9uZyk7CitleHRlcm4g
dW5zaWduZWQgbG9uZyBsb25nIF9fdWRpdmRpMyAodW5zaWduZWQgbG9uZyBsb25nLCB1bnNp
Z25lZCBsb25nIGxvbmcpOworCitsb25nIGxvbmcgX19nbnVfbGRpdm1vZF9oZWxwZXIgKGxv
bmcgbG9uZyBhLCBsb25nIGxvbmcgYiwgbG9uZyBsb25nICpyZW1haW5kZXIpCit7CisJbG9u
ZyBsb25nIHF1b3RpZW50OworCisJcXVvdGllbnQgPSBfX2RpdmRpMyAoYSwgYik7CisJKnJl
bWFpbmRlciA9IGEgLSBiICogcXVvdGllbnQ7CisJcmV0dXJuIHF1b3RpZW50OworfQorCit1
bnNpZ25lZCBsb25nIGxvbmcgX19nbnVfdWxkaXZtb2RfaGVscGVyICh1bnNpZ25lZCBsb25n
IGxvbmcgYSwgdW5zaWduZWQgbG9uZyBsb25nIGIsIHVuc2lnbmVkIGxvbmcgbG9uZyAqcmVt
YWluZGVyKQoreworCXVuc2lnbmVkIGxvbmcgbG9uZyBxdW90aWVudDsKKworCXF1b3RpZW50
ID0gX191ZGl2ZGkzIChhLCBiKTsKKwkqcmVtYWluZGVyID0gYSAtIGIgKiBxdW90aWVudDsK
KworCXJldHVybiBxdW90aWVudDsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJj
aC9hcm0vbGliL2NsZWFyYml0LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9jbGVhcmJpdC5TCUZyaSBGZWIg
MDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDI0IEBACisjaW5jbHVkZSA8eGVu
L2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KKyNpbmNsdWRlIDxhc20v
YXNtLW1hY3Jvcy5oPgorCisgICAgICAgICAgICAgICAgLnRleHQKKworLyoKKyAqIFB1cnBv
c2UgIDogRnVuY3Rpb24gdG8gY2xlYXIgYSBiaXQKKyAqIFByb3RvdHlwZTogaW50IGNsZWFy
X2JpdChpbnQgYml0LCB2b2lkICphZGRyKQorICovCitFTlRSWShfY2xlYXJfYml0X2JlKQor
CQllb3IJcjAsIHIwLCAjMHgxOAkJQCBiaWcgZW5kaWFuIGJ5dGUgb3JkZXJpbmcKK0VOVFJZ
KF9jbGVhcl9iaXRfbGUpCisJCWFuZAlyMiwgcjAsICM3CisJCW1vdglyMywgIzEKKwkJbW92
CXIzLCByMywgbHNsIHIyCisJCXNhdmVfYW5kX2Rpc2FibGVfaXJxcyBpcCwgcjIKKwkJbGRy
YglyMiwgW3IxLCByMCwgbHNyICMzXQorCQliaWMJcjIsIHIyLCByMworCQlzdHJiCXIyLCBb
cjEsIHIwLCBsc3IgIzNdCisJCXJlc3RvcmVfaXJxcyBpcAorCQltb3YJcGMsbHIKKworCmRp
ZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvY29weV90ZW1wbGF0ZS5TCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9h
cmNoL2FybS9saWIvY29weV90ZW1wbGF0ZS5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiAr
MDkwMApAQCAtMCwwICsxLDI1NSBAQAorLyoKKyAqICBsaW51eC9hcmNoL2FybS9saWIvY29w
eV90ZW1wbGF0ZS5zCisgKgorICogIENvZGUgdGVtcGxhdGUgZm9yIG9wdGltaXplZCBtZW1v
cnkgY29weSBmdW5jdGlvbnMKKyAqCisgKiAgQXV0aG9yOglOaWNvbGFzIFBpdHJlCisgKiAg
Q3JlYXRlZDoJU2VwIDI4LCAyMDA1CisgKiAgQ29weXJpZ2h0OglNb250YVZpc3RhIFNvZnR3
YXJlLCBJbmMuCisgKgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIgYXMKKyAq
ICBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqLworCisv
KgorICogVGhpcyBjYW4gYmUgdXNlZCB0byBlbmFibGUgY29kZSB0byBjYWNoZWxpbmUgYWxp
Z24gdGhlIHNvdXJjZSBwb2ludGVyLgorICogRXhwZXJpbWVudHMgb24gdGVzdGVkIGFyY2hp
dGVjdHVyZXMgKFN0cm9uZ0FSTSBhbmQgWFNjYWxlKSBkaWRuJ3Qgc2hvdworICogdGhpcyBh
IHdvcnRod2hpbGUgdGhpbmcgdG8gZG8uICBUaGF0IG1pZ2h0IGJlIGRpZmZlcmVudCBpbiB0
aGUgZnV0dXJlLgorICovCisvLyNkZWZpbmUgQ0FMR04oY29kZS4uLikJY29kZQorI2RlZmlu
ZSBDQUxHTihjb2RlLi4uKQorCisvKgorICogVGhlb3J5IG9mIG9wZXJhdGlvbgorICogLS0t
LS0tLS0tLS0tLS0tLS0tLQorICoKKyAqIFRoaXMgZmlsZSBwcm92aWRlcyB0aGUgY29yZSBj
b2RlIGZvciBhIGZvcndhcmQgbWVtb3J5IGNvcHkgdXNlZCBpbgorICogdGhlIGltcGxlbWVu
dGF0aW9uIG9mIG1lbWNvcHkoKSwgY29weV90b191c2VyKCkgYW5kIGNvcHlfZnJvbV91c2Vy
KCkuCisgKgorICogVGhlIGluY2x1ZGluZyBmaWxlIG11c3QgZGVmaW5lIHRoZSBmb2xsb3dp
bmcgYWNjZXNzb3IgbWFjcm9zCisgKiBhY2NvcmRpbmcgdG8gdGhlIG5lZWQgb2YgdGhlIGdp
dmVuIGZ1bmN0aW9uOgorICoKKyAqIGxkcjF3IHB0ciByZWcgYWJvcnQKKyAqCisgKglUaGlz
IGxvYWRzIG9uZSB3b3JkIGZyb20gJ3B0cicsIHN0b3JlcyBpdCBpbiAncmVnJyBhbmQgaW5j
cmVtZW50cworICoJJ3B0cicgdG8gdGhlIG5leHQgd29yZC4gVGhlICdhYm9ydCcgYXJndW1l
bnQgaXMgdXNlZCBmb3IgZml4dXAgdGFibGVzLgorICoKKyAqIGxkcjR3IHB0ciByZWcxIHJl
ZzIgcmVnMyByZWc0IGFib3J0CisgKiBsZHI4dyBwdHIsIHJlZzEgcmVnMiByZWczIHJlZzQg
cmVnNSByZWc2IHJlZzcgcmVnOCBhYm9ydAorICoKKyAqCVRoaXMgbG9hZHMgZm91ciBvciBl
aWdodCB3b3JkcyBzdGFydGluZyBmcm9tICdwdHInLCBzdG9yZXMgdGhlbQorICoJaW4gcHJv
dmlkZWQgcmVnaXN0ZXJzIGFuZCBpbmNyZW1lbnRzICdwdHInIHBhc3QgdGhvc2Ugd29yZHMu
CisgKglUaGUnYWJvcnQnIGFyZ3VtZW50IGlzIHVzZWQgZm9yIGZpeHVwIHRhYmxlcy4KKyAq
CisgKiBsZHIxYiBwdHIgcmVnIGNvbmQgYWJvcnQKKyAqCisgKglTaW1pbGFyIHRvIGxkcjF3
LCBidXQgaXQgbG9hZHMgYSBieXRlIGFuZCBpbmNyZW1lbnRzICdwdHInIG9uZSBieXRlLgor
ICoJSXQgYWxzbyBtdXN0IGFwcGx5IHRoZSBjb25kaXRpb24gY29kZSBpZiBwcm92aWRlZCwg
b3RoZXJ3aXNlIHRoZQorICoJImFsIiBjb25kaXRpb24gaXMgYXNzdW1lZCBieSBkZWZhdWx0
LgorICoKKyAqIHN0cjF3IHB0ciByZWcgYWJvcnQKKyAqIHN0cjh3IHB0ciByZWcxIHJlZzIg
cmVnMyByZWc0IHJlZzUgcmVnNiByZWc3IHJlZzggYWJvcnQKKyAqIHN0cjFiIHB0ciByZWcg
Y29uZCBhYm9ydAorICoKKyAqCVNhbWUgYXMgdGhlaXIgbGRyKiBjb3VudGVycGFydHMsIGJ1
dCBkYXRhIGlzIHN0b3JlZCB0byAncHRyJyBsb2NhdGlvbgorICoJcmF0aGVyIHRoYW4gYmVp
bmcgbG9hZGVkLgorICoKKyAqIGVudGVyIHJlZzEgcmVnMgorICoKKyAqCVByZXNlcnZlIHRo
ZSBwcm92aWRlZCByZWdpc3RlcnMgb24gdGhlIHN0YWNrIHBsdXMgYW55IGFkZGl0aW9uYWwK
KyAqCWRhdGEgYXMgbmVlZGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbiBpbmNsdWRpbmcgdGhp
cyBjb2RlLiBDYWxsZWQKKyAqCXVwb24gY29kZSBlbnRyeS4KKyAqCisgKiBleGl0IHJlZzEg
cmVnMgorICoKKyAqCVJlc3RvcmUgcmVnaXN0ZXJzIHdpdGggdGhlIHZhbHVlcyBwcmV2aW91
c2x5IHNhdmVkIHdpdGggdGhlCisgKgkncHJlc2VydicgbWFjcm8uIENhbGxlZCB1cG9uIGNv
ZGUgdGVybWluYXRpb24uCisgKi8KKworCisJCWVudGVyCXI0LCBscgorCisJCXN1YnMJcjIs
IHIyLCAjNAorCQlibHQJOGYKKwkJYW5kcwlpcCwgcjAsICMzCisJCXBsZAlbcjEsICMwXQor
CQlibmUJOWYKKwkJYW5kcwlpcCwgcjEsICMzCisJCWJuZQkxMGYKKworMToJCXN1YnMJcjIs
IHIyLCAjKDI4KQorCQlzdG1mZAlzcCEsIHtyNSAtIHI4fQorCQlibHQJNWYKKworCUNBTEdO
KAlhbmRzCWlwLCByMSwgIzMxCQkpCisJQ0FMR04oCXJzYglyMywgaXAsICMzMgkJKQorCUNB
TEdOKAlzYmNuZXMJcjQsIHIzLCByMgkJKSAgQCBDIGlzIGFsd2F5cyBzZXQgaGVyZQorCUNB
TEdOKAliY3MJMmYJCQkpCisJQ0FMR04oCWFkcglyNCwgNmYJCQkpCisJQ0FMR04oCXN1YnMJ
cjIsIHIyLCByMwkJKSAgQCBDIGdldHMgc2V0CisJQ0FMR04oCWFkZAlwYywgcjQsIGlwCQkp
CisKKwkJcGxkCVtyMSwgIzBdCisyOgkJc3VicwlyMiwgcjIsICM5NgorCQlwbGQJW3IxLCAj
MjhdCisJCWJsdAk0ZgorCQlwbGQJW3IxLCAjNjBdCisJCXBsZAlbcjEsICM5Ml0KKworMzoJ
CXBsZAlbcjEsICMxMjRdCis0OgkJbGRyOHcJcjEsIHIzLCByNCwgcjUsIHI2LCByNywgcjgs
IGlwLCBsciwgYWJvcnQ9MjBmCisJCXN1YnMJcjIsIHIyLCAjMzIKKwkJc3RyOHcJcjAsIHIz
LCByNCwgcjUsIHI2LCByNywgcjgsIGlwLCBsciwgYWJvcnQ9MjBmCisJCWJnZQkzYgorCQlj
bW4JcjIsICM5NgkKKwkJYmdlCTRiCisKKzU6CQlhbmRzCWlwLCByMiwgIzI4CisJCXJzYglp
cCwgaXAsICMzMgorCQlhZGRuZQlwYywgcGMsIGlwCQlAIEMgaXMgYWx3YXlzIGNsZWFyIGhl
cmUKKwkJYgk3ZgorNjoJCW5vcAorCQlsZHIxdwlyMSwgcjMsIGFib3J0PTIwZgorCQlsZHIx
dwlyMSwgcjQsIGFib3J0PTIwZgorCQlsZHIxdwlyMSwgcjUsIGFib3J0PTIwZgorCQlsZHIx
dwlyMSwgcjYsIGFib3J0PTIwZgorCQlsZHIxdwlyMSwgcjcsIGFib3J0PTIwZgorCQlsZHIx
dwlyMSwgcjgsIGFib3J0PTIwZgorCQlsZHIxdwlyMSwgbHIsIGFib3J0PTIwZgorCisJCWFk
ZAlwYywgcGMsIGlwCisJCW5vcAorCQlub3AKKwkJc3RyMXcJcjAsIHIzLCBhYm9ydD0yMGYK
KwkJc3RyMXcJcjAsIHI0LCBhYm9ydD0yMGYKKwkJc3RyMXcJcjAsIHI1LCBhYm9ydD0yMGYK
KwkJc3RyMXcJcjAsIHI2LCBhYm9ydD0yMGYKKwkJc3RyMXcJcjAsIHI3LCBhYm9ydD0yMGYK
KwkJc3RyMXcJcjAsIHI4LCBhYm9ydD0yMGYKKwkJc3RyMXcJcjAsIGxyLCBhYm9ydD0yMGYK
KworCUNBTEdOKAliY3MJMmIJCQkpCisKKzc6CQlsZG1mZAlzcCEsIHtyNSAtIHI4fQorCis4
OgkJbW92cwlyMiwgcjIsIGxzbCAjMzEKKwkJbGRyMWIJcjEsIHIzLCBuZSwgYWJvcnQ9MjFm
CisJCWxkcjFiCXIxLCByNCwgY3MsIGFib3J0PTIxZgorCQlsZHIxYglyMSwgaXAsIGNzLCBh
Ym9ydD0yMWYKKwkJc3RyMWIJcjAsIHIzLCBuZSwgYWJvcnQ9MjFmCisJCXN0cjFiCXIwLCBy
NCwgY3MsIGFib3J0PTIxZgorCQlzdHIxYglyMCwgaXAsIGNzLCBhYm9ydD0yMWYKKworCQll
eGl0CXI0LCBwYworCis5OgkJcnNiCWlwLCBpcCwgIzQKKwkJY21wCWlwLCAjMgorCQlsZHIx
YglyMSwgcjMsIGd0LCBhYm9ydD0yMWYKKwkJbGRyMWIJcjEsIHI0LCBnZSwgYWJvcnQ9MjFm
CisJCWxkcjFiCXIxLCBsciwgYWJvcnQ9MjFmCisJCXN0cjFiCXIwLCByMywgZ3QsIGFib3J0
PTIxZgorCQlzdHIxYglyMCwgcjQsIGdlLCBhYm9ydD0yMWYKKwkJc3VicwlyMiwgcjIsIGlw
CisJCXN0cjFiCXIwLCBsciwgYWJvcnQ9MjFmCisJCWJsdAk4YgorCQlhbmRzCWlwLCByMSwg
IzMKKwkJYmVxCTFiCisKKzEwOgkJYmljCXIxLCByMSwgIzMKKwkJY21wCWlwLCAjMgorCQls
ZHIxdwlyMSwgbHIsIGFib3J0PTIxZgorCQliZXEJMTdmCisJCWJndAkxOGYKKworCisJCS5t
YWNybwlmb3J3YXJkX2NvcHlfc2hpZnQgcHVsbCBwdXNoCisKKwkJc3VicwlyMiwgcjIsICMy
OAorCQlibHQJMTRmCisKKwlDQUxHTigJYW5kcwlpcCwgcjEsICMzMQkJKQorCUNBTEdOKAly
c2IJaXAsIGlwLCAjMzIJCSkKKwlDQUxHTigJc2JjbmVzCXI0LCBpcCwgcjIJCSkgIEAgQyBp
cyBhbHdheXMgc2V0IGhlcmUKKwlDQUxHTigJc3ViY2MJcjIsIHIyLCBpcAkJKQorCUNBTEdO
KAliY2MJMTVmCQkJKQorCisxMToJCXN0bWZkCXNwISwge3I1IC0gcjl9CisKKwkJcGxkCVty
MSwgIzBdCisJCXN1YnMJcjIsIHIyLCAjOTYKKwkJcGxkCVtyMSwgIzI4XQorCQlibHQJMTNm
CisJCXBsZAlbcjEsICM2MF0KKwkJcGxkCVtyMSwgIzkyXQorCisxMjoJCXBsZAlbcjEsICMx
MjRdCisxMzoJCWxkcjR3CXIxLCByNCwgcjUsIHI2LCByNywgYWJvcnQ9MTlmCisJCW1vdgly
MywgbHIsIHB1bGwgI1xwdWxsCisJCXN1YnMJcjIsIHIyLCAjMzIKKwkJbGRyNHcJcjEsIHI4
LCByOSwgaXAsIGxyLCBhYm9ydD0xOWYKKwkJb3JyCXIzLCByMywgcjQsIHB1c2ggI1xwdXNo
CisJCW1vdglyNCwgcjQsIHB1bGwgI1xwdWxsCisJCW9ycglyNCwgcjQsIHI1LCBwdXNoICNc
cHVzaAorCQltb3YJcjUsIHI1LCBwdWxsICNccHVsbAorCQlvcnIJcjUsIHI1LCByNiwgcHVz
aCAjXHB1c2gKKwkJbW92CXI2LCByNiwgcHVsbCAjXHB1bGwKKwkJb3JyCXI2LCByNiwgcjcs
IHB1c2ggI1xwdXNoCisJCW1vdglyNywgcjcsIHB1bGwgI1xwdWxsCisJCW9ycglyNywgcjcs
IHI4LCBwdXNoICNccHVzaAorCQltb3YJcjgsIHI4LCBwdWxsICNccHVsbAorCQlvcnIJcjgs
IHI4LCByOSwgcHVzaCAjXHB1c2gKKwkJbW92CXI5LCByOSwgcHVsbCAjXHB1bGwKKwkJb3Jy
CXI5LCByOSwgaXAsIHB1c2ggI1xwdXNoCisJCW1vdglpcCwgaXAsIHB1bGwgI1xwdWxsCisJ
CW9ycglpcCwgaXAsIGxyLCBwdXNoICNccHVzaAorCQlzdHI4dwlyMCwgcjMsIHI0LCByNSwg
cjYsIHI3LCByOCwgcjksIGlwLCAsIGFib3J0PTE5ZgorCQliZ2UJMTJiCisJCWNtbglyMiwg
Izk2CQorCQliZ2UJMTNiCisKKwkJbGRtZmQJc3AhLCB7cjUgLSByOX0KKworMTQ6CQlhbmRz
CWlwLCByMiwgIzI4CisJCWJlcQkxNmYKKworMTU6CQltb3YJcjMsIGxyLCBwdWxsICNccHVs
bAorCQlsZHIxdwlyMSwgbHIsIGFib3J0PTIxZgorCQlzdWJzCWlwLCBpcCwgIzQKKwkJb3Jy
CXIzLCByMywgbHIsIHB1c2ggI1xwdXNoCisJCXN0cjF3CXIwLCByMywgYWJvcnQ9MjFmCisJ
CWJndAkxNWIKKwlDQUxHTigJY21wCXIyLCAjMAkJCSkKKwlDQUxHTigJYmdlCTExYgkJCSkK
KworMTY6CQlzdWIJcjEsIHIxLCAjKFxwdXNoIC8gOCkKKwkJYgk4YgorCisJCS5lbmRtCisK
KworCQlmb3J3YXJkX2NvcHlfc2hpZnQJcHVsbD04CXB1c2g9MjQKKworMTc6CQlmb3J3YXJk
X2NvcHlfc2hpZnQJcHVsbD0xNglwdXNoPTE2CisKKzE4OgkJZm9yd2FyZF9jb3B5X3NoaWZ0
CXB1bGw9MjQJcHVzaD04CisKKworLyoKKyAqIEFib3J0IHByZWFtYmxlIGFuZCBjb21wbGV0
aW9uIG1hY3Jvcy4KKyAqIElmIGEgZml4dXAgaGFuZGxlciBpcyByZXF1aXJlZCB0aGVuIHRo
b3NlIG1hY3JvcyBtdXN0IHN1cnJvdW5kIGl0LgorICogSXQgaXMgYXNzdW1lZCB0aGF0IHRo
ZSBmaXh1cCBjb2RlIHdpbGwgaGFuZGxlIHRoZSBwcml2YXRlIHBhcnQgb2YKKyAqIHRoZSBl
eGl0IG1hY3JvLgorICovCisKKwkubWFjcm8JY29weV9hYm9ydF9wcmVhbWJsZQorMTk6CWxk
bWZkCXNwISwge3I1IC0gcjl9CisJYgkyMWYKKzIwOglsZG1mZAlzcCEsIHtyNSAtIHI4fQor
MjE6CisJLmVuZG0KKworCS5tYWNybwljb3B5X2Fib3J0X2VuZAorCWxkbWZkCXNwISwge3I0
LCBwY30KKwkuZW5kbQorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIv
ZGVsYXkuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi94ZW4vYXJjaC9hcm0vbGliL2RlbGF5LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEy
ICswOTAwCkBAIC0wLDAgKzEsNyBAQAorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNs
dWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisJCS50ZXh0CisKK0VOVFJZKF91ZGVsYXkpCisJ
bW92CXBjLGxyCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvZGl2NjQu
UwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vYXJjaC9hcm0vbGliL2RpdjY0LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAw
CkBAIC0wLDAgKzEsMTk5IEBACisvKgorICogIGxpbnV4L2FyY2gvYXJtL2xpYi9kaXY2NC5T
CisgKgorICogIE9wdGltaXplZCBjb21wdXRhdGlvbiBvZiA2NC1iaXQgZGl2aWRlbmQgLyAz
Mi1iaXQgZGl2aXNvciAgCisgKgorICogIEF1dGhvcjoJTmljb2xhcyBQaXRyZQorICogIENy
ZWF0ZWQ6CU9jdCA1LCAyMDAzCisgKiAgQ29weXJpZ2h0OglNb250YSBWaXN0YSBTb2Z0d2Fy
ZSwgSW5jLgorICoKKyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0IHVuZGVyIHRoZSB0ZXJt
cyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzCisgKiAg
cHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKi8KKyNpbmNs
dWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKyNpZmRl
ZiBfX0FSTUVCX18KKyNkZWZpbmUgeGggcjAKKyNkZWZpbmUgeGwgcjEKKyNkZWZpbmUgeWgg
cjIKKyNkZWZpbmUgeWwgcjMKKyNlbHNlCisjZGVmaW5lIHhsIHIwCisjZGVmaW5lIHhoIHIx
CisjZGVmaW5lIHlsIHIyCisjZGVmaW5lIHloIHIzCisjZW5kaWYKKworLyoKKyAqIF9fZG9f
ZGl2NjQ6IHBlcmZvcm0gYSBkaXZpc2lvbiB3aXRoIDY0LWJpdCBkaXZpZGVuZCBhbmQgMzIt
Yml0IGRpdmlzb3IuCisgKgorICogTm90ZTogQ2FsbGluZyBjb252ZW50aW9uIGlzIHRvdGFs
bHkgbm9uIHN0YW5kYXJkIGZvciBvcHRpbWFsIGNvZGUuCisgKiAgICAgICBUaGlzIGlzIG1l
YW50IHRvIGJlIHVzZWQgYnkgZG9fZGl2KCkgZnJvbSBpbmNsdWRlL2FzbS9kaXY2NC5oIG9u
bHkuCisgKgorICogSW5wdXQgcGFyYW1ldGVyczoKKyAqIAl4aC14bAk9IGRpdmlkZW5kIChj
bG9iYmVyZWQpCisgKiAJcjQJPSBkaXZpc29yIChwcmVzZXJ2ZWQpCisgKgorICogT3V0cHV0
IHZhbHVlczoKKyAqIAl5aC15bAk9IHJlc3VsdAorICogCXhoCT0gcmVtYWluZGVyCisgKgor
ICogQ2xvYmJlcmVkIHJlZ3M6IHhsLCBpcAorICovCisKK0VOVFJZKF9fZG9fZGl2NjQpCisK
KwlAIFRlc3QgZm9yIGVhc3kgcGF0aHMgZmlyc3QuCisJc3VicwlpcCwgcjQsICMxCisJYmxz
CTlmCQkJQCBkaXZpc29yIGlzIDAgb3IgMQorCXRzdAlpcCwgcjQKKwliZXEJOGYJCQlAIGRp
dmlzb3IgaXMgcG93ZXIgb2YgMgorCisJQCBTZWUgaWYgd2UgbmVlZCB0byBoYW5kbGUgdXBw
ZXIgMzItYml0IHJlc3VsdC4KKwljbXAJeGgsIHI0CisJbW92CXloLCAjMAorCWJsbwkzZgor
CisJQCBBbGlnbiBkaXZpc29yIHdpdGggdXBwZXIgcGFydCBvZiBkaXZpZGVuZC4KKwlAIFRo
ZSBhbGlnbmVkIGRpdmlzb3IgaXMgc3RvcmVkIGluIHlsIHByZXNlcnZpbmcgdGhlIG9yaWdp
bmFsLgorCUAgVGhlIGJpdCBwb3NpdGlvbiBpcyBzdG9yZWQgaW4gaXAuCisKKyNpZiBfX0xJ
TlVYX0FSTV9BUkNIX18gPj0gNQorCisJY2x6CXlsLCByNAorCWNseglpcCwgeGgKKwlzdWIJ
eWwsIHlsLCBpcAorCW1vdglpcCwgIzEKKwltb3YJaXAsIGlwLCBsc2wgeWwKKwltb3YJeWws
IHI0LCBsc2wgeWwKKworI2Vsc2UKKworCW1vdgl5bCwgcjQKKwltb3YJaXAsICMxCisxOglj
bXAJeWwsICMweDgwMDAwMDAwCisJY21wY2MJeWwsIHhoCisJbW92Y2MJeWwsIHlsLCBsc2wg
IzEKKwltb3ZjYwlpcCwgaXAsIGxzbCAjMQorCWJjYwkxYgorCisjZW5kaWYKKworCUAgVGhl
IGRpdmlzaW9uIGxvb3AgZm9yIG5lZWRlZCB1cHBlciBiaXQgcG9zaXRpb25zLgorIAlAIEJy
ZWFrIG91dCBlYXJseSBpZiBkaXZpZGVuZCByZWFjaGVzIDAuCisyOgljbXAJeGgsIHlsCisJ
b3JyY3MJeWgsIHloLCBpcAorCXN1YmNzcwl4aCwgeGgsIHlsCisJbW92bmVzCWlwLCBpcCwg
bHNyICMxCisJbW92CXlsLCB5bCwgbHNyICMxCisJYm5lCTJiCisKKwlAIFNlZSBpZiB3ZSBu
ZWVkIHRvIGhhbmRsZSBsb3dlciAzMi1iaXQgcmVzdWx0LgorMzoJY21wCXhoLCAjMAorCW1v
dgl5bCwgIzAKKwljbXBlcQl4bCwgcjQKKwltb3Zsbwl4aCwgeGwKKwltb3ZsbwlwYywgbHIK
KworCUAgVGhlIGRpdmlzaW9uIGxvb3AgZm9yIGxvd2VyIGJpdCBwb3NpdGlvbnMuCisJQCBI
ZXJlIHdlIHNoaWZ0IHJlbWFpbmVyIGJpdHMgbGVmdHdhcmRzIHJhdGhlciB0aGFuIG1vdmlu
ZyB0aGUKKwlAIGRpdmlzb3IgZm9yIGNvbXBhcmlzb25zLCBjb25zaWRlcmluZyB0aGUgY2Fy
cnktb3V0IGJpdCBhcyB3ZWxsLgorCW1vdglpcCwgIzB4ODAwMDAwMDAKKzQ6CW1vdnMJeGws
IHhsLCBsc2wgIzEKKwlhZGNzCXhoLCB4aCwgeGgKKwliZXEJNmYKKwljbXBjYwl4aCwgcjQK
KzU6CW9ycmNzCXlsLCB5bCwgaXAKKwlzdWJjcwl4aCwgeGgsIHI0CisJbW92cwlpcCwgaXAs
IGxzciAjMQorCWJuZQk0YgorCW1vdglwYywgbHIKKworCUAgVGhlIHRvcCBwYXJ0IG9mIHJl
bWFpbmRlciBiZWNhbWUgemVyby4gIElmIGNhcnJ5IGlzIHNldAorCUAgKHRoZSAzM3RoIGJp
dCkgdGhpcyBpcyBhIGZhbHNlIHBvc2l0aXZlIHNvIHJlc3VtZSB0aGUgbG9vcC4KKwlAIE90
aGVyd2lzZSwgaWYgbG93ZXIgcGFydCBpcyBhbHNvIG51bGwgdGhlbiB3ZSBhcmUgZG9uZS4K
KzY6CWJjcwk1YgorCWNtcAl4bCwgIzAKKwltb3ZlcQlwYywgbHIKKworCUAgV2Ugc3RpbGwg
aGF2ZSByZW1haW5lciBiaXRzIGluIHRoZSBsb3cgcGFydC4gIEJyaW5nIHRoZW0gdXAuCisK
KyNpZiBfX0xJTlVYX0FSTV9BUkNIX18gPj0gNQorCisJY2x6CXhoLCB4bAkJCUAgd2Uga25v
dyB4aCBpcyB6ZXJvIGhlcmUgc28uLi4KKwlhZGQJeGgsIHhoLCAjMQorCW1vdgl4bCwgeGws
IGxzbCB4aAorCW1vdglpcCwgaXAsIGxzciB4aAorCisjZWxzZQorCis3Ogltb3ZzCXhsLCB4
bCwgbHNsICMxCisJbW92CWlwLCBpcCwgbHNyICMxCisJYmNjCTdiCisKKyNlbmRpZgorCisJ
QCBDdXJyZW50IHJlbWFpbmRlciBpcyBub3cgMS4gIEl0IGlzIHdvcnRobGVzcyB0byBjb21w
YXJlIHdpdGgKKwlAIGRpdmlzb3IgYXQgdGhpcyBwb2ludCBzaW5jZSBkaXZpc29yIGNhbiBu
b3QgYmUgc21hbGxlciB0aGFuIDMgaGVyZS4KKwlAIElmIHBvc3NpYmxlLCBicmFuY2ggZm9y
IGFub3RoZXIgc2hpZnQgaW4gdGhlIGRpdmlzaW9uIGxvb3AuCisJQCBJZiBubyBiaXQgcG9z
aXRpb24gbGVmdCB0aGVuIHdlIGFyZSBkb25lLgorCW1vdnMJaXAsIGlwLCBsc3IgIzEKKwlt
b3YJeGgsICMxCisJYm5lCTRiCisJbW92CXBjLCBscgorCis4OglAIERpdmlzaW9uIGJ5IGEg
cG93ZXIgb2YgMjogZGV0ZXJtaW5lIHdoYXQgdGhhdCBkaXZpc29yIG9yZGVyIGlzCisJQCB0
aGVuIHNpbXBseSBzaGlmdCB2YWx1ZXMgYXJvdW5kCisKKyNpZiBfX0xJTlVYX0FSTV9BUkNI
X18gPj0gNQorCisJY2x6CWlwLCByNAorCXJzYglpcCwgaXAsICMzMQorCisjZWxzZQorCisJ
bW92CXlsLCByNAorCWNtcAlyNCwgIygxIDw8IDE2KQorCW1vdglpcCwgIzAKKwltb3Zocwl5
bCwgeWwsIGxzciAjMTYKKwltb3ZocwlpcCwgIzE2CisKKwljbXAJeWwsICMoMSA8PCA4KQor
CW1vdmhzCXlsLCB5bCwgbHNyICM4CisJYWRkaHMJaXAsIGlwLCAjOAorCisJY21wCXlsLCAj
KDEgPDwgNCkKKwltb3Zocwl5bCwgeWwsIGxzciAjNAorCWFkZGhzCWlwLCBpcCwgIzQKKwor
CWNtcAl5bCwgIygxIDw8IDIpCisJYWRkaGkJaXAsIGlwLCAjMworCWFkZGxzCWlwLCBpcCwg
eWwsIGxzciAjMQorCisjZW5kaWYKKworCW1vdgl5aCwgeGgsIGxzciBpcAorCW1vdgl5bCwg
eGwsIGxzciBpcAorCXJzYglpcCwgaXAsICMzMgorCW9ycgl5bCwgeWwsIHhoLCBsc2wgaXAK
Kwltb3YJeGgsIHhsLCBsc2wgaXAKKwltb3YJeGgsIHhoLCBsc3IgaXAKKwltb3YJcGMsIGxy
CisKKwlAIGVxIC0+IGRpdmlzaW9uIGJ5IDE6IG9idmlvdXMgZW5vdWdoLi4uCis5Ogltb3Zl
cQl5bCwgeGwKKwltb3ZlcQl5aCwgeGgKKwltb3ZlcQl4aCwgIzAKKwltb3ZlcQlwYywgbHIK
KworCUAgRGl2aXNpb24gYnkgMDoKKwlzdHIJbHIsIFtzcCwgIy04XSEKKwlibAlfX2RpdjAK
KworCUAgYXMgd3JvbmcgYXMgaXQgY291bGQgYmUuLi4KKwltb3YJeWwsICMwCisJbW92CXlo
LCAjMAorCW1vdgl4aCwgIzAKKwlsZHIJcGMsIFtzcF0sICM4CisKZGlmZiAtciBlNzAxNDYx
YjEyNTEgeGVuL2FyY2gvYXJtL2xpYi9maW5kYml0LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9maW5kYml0
LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsODEgQEAKKyNp
bmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKwor
ICAgICAgICAgICAgICAgIC50ZXh0CisKKy8qCisgKiBQdXJwb3NlICA6IEZpbmQgYSAnemVy
bycgYml0CisgKiBQcm90b3R5cGU6IGludCBmaW5kX2ZpcnN0X3plcm9fYml0KHZvaWQgKmFk
ZHIsIHVuc2lnbmVkIGludCBtYXhiaXQpOworICovCitFTlRSWShfZmluZF9maXJzdF96ZXJv
X2JpdCkKKwkJdGVxCXIxLCAjMAkKKwkJYmVxCTNmCisJCW1vdglyMiwgIzAKKzE6CQlsZHJi
CXIzLCBbcjAsIHIyLCBsc3IgIzNdCisJCWVvcnMJcjMsIHIzLCAjMHhmZgkJQCBpbnZlcnQg
Yml0cworCQlibmUJLmZvdW5kCQkJQCBhbnkgbm93IHNldCAtIGZvdW5kIHplcm8gYml0CisJ
CWFkZAlyMiwgcjIsICM4CQlAIG5leHQgYml0IHBvaW50ZXIKKzI6CQljbXAJcjIsIHIxCQkJ
QCBhbnkgbW9yZT8KKwkJYmxvCTFiCiszOgkJbW92CXIwLCByMQkJCUAgbm8gZnJlZSBiaXRz
CisJCW1vdglwYyxscgorCisvKgorICogUHVycG9zZSAgOiBGaW5kIG5leHQgJ3plcm8nIGJp
dAorICogUHJvdG90eXBlOiBpbnQgZmluZF9uZXh0X3plcm9fYml0KHZvaWQgKmFkZHIsIHVu
c2lnbmVkIGludCBtYXhiaXQsIGludCBvZmZzZXQpCisgKi8KK0VOVFJZKF9maW5kX25leHRf
emVyb19iaXQpCisJCXRlcQlyMSwgIzAKKwkJYmVxCTNiCisJCWFuZHMJaXAsIHIyLCAjNwor
CQliZXEJMWIJCQlAIElmIG5ldyBieXRlLCBnb3RvIG9sZCByb3V0aW5lCisJCWxkcmIJcjMs
IFtyMCwgcjIsIGxzciAjM10KKwkJZW9yCXIzLCByMywgIzB4ZmYJCUAgbm93IGxvb2tpbmcg
Zm9yIGEgMSBiaXQKKwkJbW92cwlyMywgcjMsIGxzciBpcAkJQCBzaGlmdCBvZmYgdW51c2Vk
IGJpdHMKKwkJYm5lCS5mb3VuZAorCQlvcnIJcjIsIHIyLCAjNwkJQCBpZiB6ZXJvLCB0aGVu
IG5vIGJpdHMgaGVyZQorCQlhZGQJcjIsIHIyLCAjMQkJQCBhbGlnbiBiaXQgcG9pbnRlcgor
CQliCTJiCQkJQCBsb29wIGZvciBuZXh0IGJpdAorCisvKgorICogUHVycG9zZSAgOiBGaW5k
IGEgJ29uZScgYml0CisgKiBQcm90b3R5cGU6IGludCBmaW5kX2ZpcnN0X2JpdChjb25zdCB1
bnNpZ25lZCBsb25nICphZGRyLCB1bnNpZ25lZCBpbnQgbWF4Yml0KTsKKyAqLworRU5UUlko
X2ZpbmRfZmlyc3RfYml0KQorCQl0ZXEJcjEsICMwCQorCQliZXEJM2YKKwkJbW92CXIyLCAj
MAorMToJCWxkcmIJcjMsIFtyMCwgcjIsIGxzciAjM10KKwkJbW92cwlyMywgcjMKKwkJYm5l
CS5mb3VuZAkJCUAgYW55IG5vdyBzZXQgLSBmb3VuZCB6ZXJvIGJpdAorCQlhZGQJcjIsIHIy
LCAjOAkJQCBuZXh0IGJpdCBwb2ludGVyCisyOgkJY21wCXIyLCByMQkJCUAgYW55IG1vcmU/
CisJCWJsbwkxYgorMzoJCW1vdglyMCwgcjEJCQlAIG5vIGZyZWUgYml0cworCQltb3YJcGMs
bHIKKworLyoKKyAqIFB1cnBvc2UgIDogRmluZCBuZXh0ICdvbmUnIGJpdAorICogUHJvdG90
eXBlOiBpbnQgZmluZF9uZXh0X3plcm9fYml0KHZvaWQgKmFkZHIsIHVuc2lnbmVkIGludCBt
YXhiaXQsIGludCBvZmZzZXQpCisgKi8KK0VOVFJZKF9maW5kX25leHRfYml0KQorCQl0ZXEJ
cjEsICMwCisJCWJlcQkzYgorCQlhbmRzCWlwLCByMiwgIzcKKwkJYmVxCTFiCQkJQCBJZiBu
ZXcgYnl0ZSwgZ290byBvbGQgcm91dGluZQorCQlsZHJiCXIzLCBbcjAsIHIyLCBsc3IgIzNd
CisJCW1vdnMJcjMsIHIzLCBsc3IgaXAJCUAgc2hpZnQgb2ZmIHVudXNlZCBiaXRzCisJCWJu
ZQkuZm91bmQKKwkJb3JyCXIyLCByMiwgIzcJCUAgaWYgemVybywgdGhlbiBubyBiaXRzIGhl
cmUKKwkJYWRkCXIyLCByMiwgIzEJCUAgYWxpZ24gYml0IHBvaW50ZXIKKwkJYgkyYgkJCUAg
bG9vcCBmb3IgbmV4dCBiaXQKKworICAKKy5mb3VuZDoKKwkJcnNiCXIxLCByMywgIzAKKwkJ
YW5kCXIzLCByMywgcjEKKwkJY2x6CXIzLCByMworCQlyc2IJcjMsIHIzLCAjMzEKKwkJYWRk
CXIwLCByMiwgcjMKKwkJbW92CXBjLGxyCisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2Fy
Y2gvYXJtL2xpYi9nY2NsaWIuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL2djY2xpYi5oCUZyaSBGZWIgMDMg
MTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDMzIEBACisvKiBnY2NsaWIuaCAtLSBk
ZWZpbml0aW9ucyBmb3IgdmFyaW91cyBmdW5jdGlvbnMgJ2JvcnJvd2VkJyBmcm9tIGdjYy0y
Ljk1LjMgKi8KKy8qIEkgTW9sdG9uICAgICAyOS8wNy8wMSAqLworCisjaWZuZGVmIF9fR0ND
TElCX0hfXworI2RlZmluZSBfX0dDQ0xJQl9IX18KKyNkZWZpbmUgQklUU19QRVJfVU5JVCAg
OAorI2RlZmluZSBTSV9UWVBFX1NJWkUgKHNpemVvZiAoU0l0eXBlKSAqIEJJVFNfUEVSX1VO
SVQpCisKK3R5cGVkZWYgdW5zaWduZWQgaW50IFVRSXR5cGUgICAgX19hdHRyaWJ1dGVfXyAo
KG1vZGUgKFFJKSkpOwordHlwZWRlZiAgICAgICAgICBpbnQgU0l0eXBlICAgICBfX2F0dHJp
YnV0ZV9fICgobW9kZSAoU0kpKSk7Cit0eXBlZGVmIHVuc2lnbmVkIGludCBVU0l0eXBlICAg
IF9fYXR0cmlidXRlX18gKChtb2RlIChTSSkpKTsKK3R5cGVkZWYgICAgICAgICAgaW50IERJ
dHlwZSAgICAgX19hdHRyaWJ1dGVfXyAoKG1vZGUgKERJKSkpOwordHlwZWRlZiAgICAgICAg
ICBpbnQgd29yZF90eXBlIAlfX2F0dHJpYnV0ZV9fICgobW9kZSAoX193b3JkX18pKSk7Cit0
eXBlZGVmIHVuc2lnbmVkIGludCBVREl0eXBlICAgIF9fYXR0cmlidXRlX18gKChtb2RlIChE
SSkpKTsKKworI2lmZGVmIF9fQVJNRUJfXworICBzdHJ1Y3QgRElzdHJ1Y3Qge1NJdHlwZSBo
aWdoLCBsb3c7fTsKKyNlbHNlCisgIHN0cnVjdCBESXN0cnVjdCB7U0l0eXBlIGxvdywgaGln
aDt9OworI2VuZGlmCisKK3R5cGVkZWYgdW5pb24KK3sKKyAgc3RydWN0IERJc3RydWN0IHM7
CisgIERJdHlwZSBsbDsKK30gREl1bmlvbjsKKwordHlwZWRlZiBzdHJ1Y3QgX19hdHRyaWJ1
dGVfXygocmVnX3JldHVybikpCit7CisgICAgICAgIGxvbmcgbG9uZyBxdW90OworICAgICAg
ICBsb25nIGxvbmcgcmVtOworfSBsbGRpdl90X3JyOworI2VuZGlmCmRpZmYgLXIgZTcwMTQ2
MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvZ2V0dXNlci5TCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvZ2V0dXNl
ci5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDc3IEBACisv
KgorICogIGxpbnV4L2FyY2gvYXJtL2xpYi9nZXR1c2VyLlMKKyAqCisgKiAgQ29weXJpZ2h0
IChDKSAyMDAxIFJ1c3NlbGwgS2luZworICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv
ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1
bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNp
b24gMiBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24u
CisgKgorICogIElkZWEgZnJvbSB4ODYgdmVyc2lvbiwgKEMpIENvcHlyaWdodCAxOTk4IExp
bnVzIFRvcnZhbGRzCisgKgorICogVGhlc2UgZnVuY3Rpb25zIGhhdmUgYSBub24tc3RhbmRh
cmQgY2FsbCBpbnRlcmZhY2UgdG8gbWFrZSB0aGVtIG1vcmUKKyAqIGVmZmljaWVudCwgZXNw
ZWNpYWxseSBhcyB0aGV5IHJldHVybiBhbiBlcnJvciB2YWx1ZSBpbiBhZGRpdGlvbiB0bwor
ICogdGhlICJyZWFsIiByZXR1cm4gdmFsdWUuCisgKgorICogX19nZXRfdXNlcl9YCisgKgor
ICogSW5wdXRzOglyMCBjb250YWlucyB0aGUgYWRkcmVzcworICogT3V0cHV0czoJcjAgaXMg
dGhlIGVycm9yIGNvZGUKKyAqCQlyMiwgcjMgY29udGFpbnMgdGhlIHplcm8tZXh0ZW5kZWQg
dmFsdWUKKyAqCQlsciBjb3JydXB0ZWQKKyAqCisgKiBObyBvdGhlciByZWdpc3RlcnMgbXVz
dCBiZSBhbHRlcmVkLiAgKHNlZSBpbmNsdWRlL2FzbS1hcm0vdWFjY2Vzcy5oCisgKiBmb3Ig
c3BlY2lmaWMgQVNNIHJlZ2lzdGVyIHVzYWdlKS4KKyAqCisgKiBOb3RlIHRoYXQgQUREUl9M
SU1JVCBpcyBlaXRoZXIgMCBvciAweGMwMDAwMDAwLgorICogTm90ZSBhbHNvIHRoYXQgaXQg
aXMgaW50ZW5kZWQgdGhhdCBfX2dldF91c2VyX2JhZCBpcyBub3QgZ2xvYmFsLgorICovCisj
aW5jbHVkZSA8eGVuL2Vycm5vLmg+CisKKwkuZ2xvYmFsCV9fZ2V0X3VzZXJfMQorX19nZXRf
dXNlcl8xOgorMToJbGRyYnQJcjIsIFtyMF0KKwltb3YJcjAsICMwCisJbW92CXBjLCBscgor
CisJLmdsb2JhbAlfX2dldF91c2VyXzIKK19fZ2V0X3VzZXJfMjoKKzI6CWxkcmJ0CXIyLCBb
cjBdLCAjMQorMzoJbGRyYnQJcjMsIFtyMF0KKyNpZm5kZWYgX19BUk1FQl9fCisJb3JyCXIy
LCByMiwgcjMsIGxzbCAjOAorI2Vsc2UKKwlvcnIJcjIsIHIzLCByMiwgbHNsICM4CisjZW5k
aWYKKwltb3YJcjAsICMwCisJbW92CXBjLCBscgorCisJLmdsb2JhbAlfX2dldF91c2VyXzQK
K19fZ2V0X3VzZXJfNDoKKzQ6CWxkcnQJcjIsIFtyMF0KKwltb3YJcjAsICMwCisJbW92CXBj
LCBscgorCisJLmdsb2JhbAlfX2dldF91c2VyXzgKK19fZ2V0X3VzZXJfODoKKzU6CWxkcnQJ
cjIsIFtyMF0sICM0Cis2OglsZHJ0CXIzLCBbcjBdCisJbW92CXIwLCAjMAorCW1vdglwYywg
bHIKKworCS5nbG9iYWwgX19nZXRfdXNlcl9iYWQKK19fZ2V0X3VzZXJfYmFkXzg6CisJbW92
CXIzLCAjMAorX19nZXRfdXNlcl9iYWQ6CisJbW92CXIyLCAjMAorCW1vdglyMCwgIy1FRkFV
TFQKKwltb3YJcGMsIGxyCisKKy5zZWN0aW9uIF9fZXhfdGFibGUsICJhIgorCS5sb25nCTFi
LCBfX2dldF91c2VyX2JhZAorCS5sb25nCTJiLCBfX2dldF91c2VyX2JhZAorCS5sb25nCTNi
LCBfX2dldF91c2VyX2JhZAorCS5sb25nCTRiLCBfX2dldF91c2VyX2JhZAorCS5sb25nCTVi
LCBfX2dldF91c2VyX2JhZF84CisJLmxvbmcJNmIsIF9fZ2V0X3VzZXJfYmFkXzgKKy5wcmV2
aW91cwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL2xpYjFmdW5jcy5T
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hl
bi9hcmNoL2FybS9saWIvbGliMWZ1bmNzLlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsMjU2IEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1
ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisKKworLm1hY3JvIEFSTV9ESVZfQk9EWSBkaXZpZGVu
ZCwgZGl2aXNvciwgcmVzdWx0LCBjdXJiaXQKKworCUAgSW5pdGlhbGx5IHNoaWZ0IHRoZSBk
aXZpc29yIGxlZnQgMyBiaXRzIGlmIHBvc3NpYmxlLAorCUAgc2V0IGN1cmJpdCBhY2NvcmRp
bmdseS4gIFRoaXMgYWxsb3dzIGZvciBjdXJiaXQgdG8gYmUgbG9jYXRlZAorCUAgYXQgdGhl
IGxlZnQgZW5kIG9mIGVhY2ggNCBiaXQgbmliYmxlcyBpbiB0aGUgZGl2aXNpb24gbG9vcAor
CUAgdG8gc2F2ZSBvbmUgbG9vcCBpbiBtb3N0IGNhc2VzLgorCXRzdAlcZGl2aXNvciwgIzB4
ZTAwMDAwMDAKKwltb3ZlcQlcZGl2aXNvciwgXGRpdmlzb3IsIGxzbCAjMworCW1vdmVxCVxj
dXJiaXQsICM4CisJbW92bmUJXGN1cmJpdCwgIzEKKworCUAgVW5sZXNzIHRoZSBkaXZpc29y
IGlzIHZlcnkgYmlnLCBzaGlmdCBpdCB1cCBpbiBtdWx0aXBsZXMgb2YKKwlAIGZvdXIgYml0
cywgc2luY2UgdGhpcyBpcyB0aGUgYW1vdW50IG9mIHVud2luZGluZyBpbiB0aGUgbWFpbgor
CUAgZGl2aXNpb24gbG9vcC4gIENvbnRpbnVlIHNoaWZ0aW5nIHVudGlsIHRoZSBkaXZpc29y
IGlzIAorCUAgbGFyZ2VyIHRoYW4gdGhlIGRpdmlkZW5kLgorMToJY21wCVxkaXZpc29yLCAj
MHgxMDAwMDAwMAorCWNtcGxvCVxkaXZpc29yLCBcZGl2aWRlbmQKKwltb3ZsbwlcZGl2aXNv
ciwgXGRpdmlzb3IsIGxzbCAjNAorCW1vdmxvCVxjdXJiaXQsIFxjdXJiaXQsIGxzbCAjNAor
CWJsbwkxYgorCisJQCBGb3IgdmVyeSBiaWcgZGl2aXNvcnMsIHdlIG11c3Qgc2hpZnQgaXQg
YSBiaXQgYXQgYSB0aW1lLCBvcgorCUAgd2Ugd2lsbCBiZSBpbiBkYW5nZXIgb2Ygb3ZlcmZs
b3dpbmcuCisxOgljbXAJXGRpdmlzb3IsICMweDgwMDAwMDAwCisJY21wbG8JXGRpdmlzb3Is
IFxkaXZpZGVuZAorCW1vdmxvCVxkaXZpc29yLCBcZGl2aXNvciwgbHNsICMxCisJbW92bG8J
XGN1cmJpdCwgXGN1cmJpdCwgbHNsICMxCisJYmxvCTFiCisKKwltb3YJXHJlc3VsdCwgIzAK
KworCUAgRGl2aXNpb24gbG9vcAorMToJY21wCVxkaXZpZGVuZCwgXGRpdmlzb3IKKwlzdWJo
cwlcZGl2aWRlbmQsIFxkaXZpZGVuZCwgXGRpdmlzb3IKKwlvcnJocwlccmVzdWx0LCAgIFxy
ZXN1bHQsICAgXGN1cmJpdAorCWNtcAlcZGl2aWRlbmQsIFxkaXZpc29yLCAgbHNyICMxCisJ
c3ViaHMJXGRpdmlkZW5kLCBcZGl2aWRlbmQsIFxkaXZpc29yLCBsc3IgIzEKKwlvcnJocwlc
cmVzdWx0LCAgIFxyZXN1bHQsICAgXGN1cmJpdCwgIGxzciAjMQorCWNtcAlcZGl2aWRlbmQs
IFxkaXZpc29yLCAgbHNyICMyCisJc3ViaHMJXGRpdmlkZW5kLCBcZGl2aWRlbmQsIFxkaXZp
c29yLCBsc3IgIzIKKwlvcnJocwlccmVzdWx0LCAgIFxyZXN1bHQsICAgXGN1cmJpdCwgIGxz
ciAjMgorCWNtcAlcZGl2aWRlbmQsIFxkaXZpc29yLCAgbHNyICMzCisJc3ViaHMJXGRpdmlk
ZW5kLCBcZGl2aWRlbmQsIFxkaXZpc29yLCBsc3IgIzMKKwlvcnJocwlccmVzdWx0LCAgIFxy
ZXN1bHQsICAgXGN1cmJpdCwgIGxzciAjMworCWNtcAlcZGl2aWRlbmQsICMwCQkJQCBFYXJs
eSB0ZXJtaW5hdGlvbj8KKwltb3ZuZXMJXGN1cmJpdCwgICBcY3VyYml0LCAgbHNyICM0CUAg
Tm8sIGFueSBtb3JlIGJpdHMgdG8gZG8/CisJbW92bmUJXGRpdmlzb3IsICBcZGl2aXNvciwg
bHNyICM0CisJYm5lCTFiCisKKy5lbmRtCisKKworLm1hY3JvIEFSTV9ESVYyX09SREVSIGRp
dmlzb3IsIG9yZGVyCisJY21wCVxkaXZpc29yLCAjKDEgPDwgMTYpCisJbW92aHMJXGRpdmlz
b3IsIFxkaXZpc29yLCBsc3IgIzE2CisJbW92aHMJXG9yZGVyLCAjMTYKKwltb3Zsbwlcb3Jk
ZXIsICMwCisKKwljbXAJXGRpdmlzb3IsICMoMSA8PCA4KQorCW1vdmhzCVxkaXZpc29yLCBc
ZGl2aXNvciwgbHNyICM4CisJYWRkaHMJXG9yZGVyLCBcb3JkZXIsICM4CisKKwljbXAJXGRp
dmlzb3IsICMoMSA8PCA0KQorCW1vdmhzCVxkaXZpc29yLCBcZGl2aXNvciwgbHNyICM0CisJ
YWRkaHMJXG9yZGVyLCBcb3JkZXIsICM0CisKKwljbXAJXGRpdmlzb3IsICMoMSA8PCAyKQor
CWFkZGhpCVxvcmRlciwgXG9yZGVyLCAjMworCWFkZGxzCVxvcmRlciwgXG9yZGVyLCBcZGl2
aXNvciwgbHNyICMxCisuZW5kbQorCisKKy5tYWNybyBBUk1fTU9EX0JPRFkgZGl2aWRlbmQs
IGRpdmlzb3IsIG9yZGVyLCBzcGFyZQorCW1vdglcb3JkZXIsICMwCisKKwlAIFVubGVzcyB0
aGUgZGl2aXNvciBpcyB2ZXJ5IGJpZywgc2hpZnQgaXQgdXAgaW4gbXVsdGlwbGVzIG9mCisJ
QCBmb3VyIGJpdHMsIHNpbmNlIHRoaXMgaXMgdGhlIGFtb3VudCBvZiB1bndpbmRpbmcgaW4g
dGhlIG1haW4KKwlAIGRpdmlzaW9uIGxvb3AuICBDb250aW51ZSBzaGlmdGluZyB1bnRpbCB0
aGUgZGl2aXNvciBpcyAKKwlAIGxhcmdlciB0aGFuIHRoZSBkaXZpZGVuZC4KKzE6CWNtcAlc
ZGl2aXNvciwgIzB4MTAwMDAwMDAKKwljbXBsbwlcZGl2aXNvciwgXGRpdmlkZW5kCisJbW92
bG8JXGRpdmlzb3IsIFxkaXZpc29yLCBsc2wgIzQKKwlhZGRsbwlcb3JkZXIsIFxvcmRlciwg
IzQKKwlibG8JMWIKKworCUAgRm9yIHZlcnkgYmlnIGRpdmlzb3JzLCB3ZSBtdXN0IHNoaWZ0
IGl0IGEgYml0IGF0IGEgdGltZSwgb3IKKwlAIHdlIHdpbGwgYmUgaW4gZGFuZ2VyIG9mIG92
ZXJmbG93aW5nLgorMToJY21wCVxkaXZpc29yLCAjMHg4MDAwMDAwMAorCWNtcGxvCVxkaXZp
c29yLCBcZGl2aWRlbmQKKwltb3ZsbwlcZGl2aXNvciwgXGRpdmlzb3IsIGxzbCAjMQorCWFk
ZGxvCVxvcmRlciwgXG9yZGVyLCAjMQorCWJsbwkxYgorCisJQCBQZXJmb3JtIGFsbCBuZWVk
ZWQgc3Vic3RyYWN0aW9ucyB0byBrZWVwIG9ubHkgdGhlIHJlbWluZGVyLgorCUAgRG8gY29t
cGFyaXNvbnMgaW4gYmF0Y2ggb2YgNCBmaXJzdC4KKwlzdWJzCVxvcmRlciwgXG9yZGVyLCAj
MwkJQCB5ZXMsIDMgaXMgaW50ZW5kZWQgaGVyZQorCWJsdAkyZgorCisxOgljbXAJXGRpdmlk
ZW5kLCBcZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvcgor
CWNtcAlcZGl2aWRlbmQsIFxkaXZpc29yLCAgbHNyICMxCisJc3ViaHMJXGRpdmlkZW5kLCBc
ZGl2aWRlbmQsIFxkaXZpc29yLCBsc3IgIzEKKwljbXAJXGRpdmlkZW5kLCBcZGl2aXNvciwg
IGxzciAjMgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvciwgbHNyICMy
CisJY21wCVxkaXZpZGVuZCwgXGRpdmlzb3IsICBsc3IgIzMKKwlzdWJocwlcZGl2aWRlbmQs
IFxkaXZpZGVuZCwgXGRpdmlzb3IsIGxzciAjMworCWNtcAlcZGl2aWRlbmQsICMxCisJbW92
CVxkaXZpc29yLCBcZGl2aXNvciwgbHNyICM0CisJc3ViZ2VzCVxvcmRlciwgXG9yZGVyLCAj
NAorCWJnZQkxYgorCisJdHN0CVxvcmRlciwgIzMKKwl0ZXFuZQlcZGl2aWRlbmQsICMwCisJ
YmVxCTVmCisKKwlAIEVpdGhlciAxLCAyIG9yIDMgY29tcGFyaXNvbi9zdWJzdHJhY3Rpb25z
IGFyZSBsZWZ0LgorMjoJY21uCVxvcmRlciwgIzIKKwlibHQJNGYKKwliZXEJM2YKKwljbXAJ
XGRpdmlkZW5kLCBcZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2
aXNvcgorCW1vdglcZGl2aXNvciwgIFxkaXZpc29yLCAgbHNyICMxCiszOgljbXAJXGRpdmlk
ZW5kLCBcZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvcgor
CW1vdglcZGl2aXNvciwgIFxkaXZpc29yLCAgbHNyICMxCis0OgljbXAJXGRpdmlkZW5kLCBc
ZGl2aXNvcgorCXN1YmhzCVxkaXZpZGVuZCwgXGRpdmlkZW5kLCBcZGl2aXNvcgorNToKKy5l
bmRtCisKKworRU5UUlkoX191ZGl2c2kzKQorRU5UUlkoX19hZWFiaV91aWRpdikKKwlzdWJz
CXIyLCByMSwgIzEKKwltb3ZlcQlwYywgbHIKKwliY2MJTGRpdjAKKwljbXAJcjAsIHIxCisJ
YmxzCTExZgorCXRzdAlyMSwgcjIKKwliZXEJMTJmCisKKwlBUk1fRElWX0JPRFkgcjAsIHIx
LCByMiwgcjMKKworCW1vdglyMCwgcjIKKwltb3YJcGMsIGxyCisKKzExOgltb3ZlcQlyMCwg
IzEKKwltb3ZuZQlyMCwgIzAKKwltb3YJcGMsIGxyCisKKzEyOglBUk1fRElWMl9PUkRFUiBy
MSwgcjIKKworCW1vdglyMCwgcjAsIGxzciByMgorCW1vdglwYywgbHIKKworCitFTlRSWShf
X3Vtb2RzaTMpCisJc3VicwlyMiwgcjEsICMxCQkJQCBjb21wYXJlIGRpdmlzb3Igd2l0aCAx
CisJYmNjCUxkaXYwCisJY21wbmUJcjAsIHIxCQkJCUAgY29tcGFyZSBkaXZpZGVuZCB3aXRo
IGRpdmlzb3IKKwltb3ZlcSAgIHIwLCAjMAorCXRzdGhpCXIxLCByMgkJCQlAIHNlZSBpZiBk
aXZpc29yIGlzIHBvd2VyIG9mIDIKKwlhbmRlcQlyMCwgcjAsIHIyCisJbW92bHMJcGMsIGxy
CisKKwlBUk1fTU9EX0JPRFkgcjAsIHIxLCByMiwgcjMKKworCW1vdglwYywgbHIKKworCitF
TlRSWShfX2RpdnNpMykKK0VOVFJZKF9fYWVhYmlfaWRpdikKKwljbXAJcjEsICMwCisJZW9y
CWlwLCByMCwgcjEJCQlAIHNhdmUgdGhlIHNpZ24gb2YgdGhlIHJlc3VsdC4KKwliZXEJTGRp
djAKKwlyc2JtaQlyMSwgcjEsICMwCQkJQCBsb29wcyBiZWxvdyB1c2UgdW5zaWduZWQuCisJ
c3VicwlyMiwgcjEsICMxCQkJQCBkaXZpc2lvbiBieSAxIG9yIC0xID8KKwliZXEJMTBmCisJ
bW92cwlyMywgcjAKKwlyc2JtaQlyMywgcjAsICMwCQkJQCBwb3NpdGl2ZSBkaXZpZGVuZCB2
YWx1ZQorCWNtcAlyMywgcjEKKwlibHMJMTFmCisJdHN0CXIxLCByMgkJCQlAIGRpdmlzb3Ig
aXMgcG93ZXIgb2YgMiA/CisJYmVxCTEyZgorCisJQVJNX0RJVl9CT0RZIHIzLCByMSwgcjAs
IHIyCisKKwljbXAJaXAsICMwCisJcnNibWkJcjAsIHIwLCAjMAorCW1vdglwYywgbHIKKwor
MTA6CXRlcQlpcCwgcjAJCQkJQCBzYW1lIHNpZ24gPworCXJzYm1pCXIwLCByMCwgIzAKKwlt
b3YJcGMsIGxyCisKKzExOgltb3ZsbwlyMCwgIzAKKwltb3ZlcQlyMCwgaXAsIGFzciAjMzEK
KwlvcnJlcQlyMCwgcjAsICMxCisJbW92CXBjLCBscgorCisxMjoJQVJNX0RJVjJfT1JERVIg
cjEsIHIyCisKKwljbXAJaXAsICMwCisJbW92CXIwLCByMywgbHNyIHIyCisJcnNibWkJcjAs
IHIwLCAjMAorCW1vdglwYywgbHIKKworCitFTlRSWShfX21vZHNpMykKKworCWNtcAlyMSwg
IzAKKwliZXEJTGRpdjAKKwlyc2JtaQlyMSwgcjEsICMwCQkJQCBsb29wcyBiZWxvdyB1c2Ug
dW5zaWduZWQuCisJbW92cwlpcCwgcjAJCQkJQCBwcmVzZXJ2ZSBzaWduIG9mIGRpdmlkZW5k
CisJcnNibWkJcjAsIHIwLCAjMAkJCUAgaWYgbmVnYXRpdmUgbWFrZSBwb3NpdGl2ZQorCXN1
YnMJcjIsIHIxLCAjMQkJCUAgY29tcGFyZSBkaXZpc29yIHdpdGggMQorCWNtcG5lCXIwLCBy
MQkJCQlAIGNvbXBhcmUgZGl2aWRlbmQgd2l0aCBkaXZpc29yCisJbW92ZXEJcjAsICMwCisJ
dHN0aGkJcjEsIHIyCQkJCUAgc2VlIGlmIGRpdmlzb3IgaXMgcG93ZXIgb2YgMgorCWFuZGVx
CXIwLCByMCwgcjIKKwlibHMJMTBmCisKKwlBUk1fTU9EX0JPRFkgcjAsIHIxLCByMiwgcjMK
KworMTA6CWNtcAlpcCwgIzAKKwlyc2JtaQlyMCwgcjAsICMwCisJbW92CXBjLCBscgorCitF
TlRSWShfX2FlYWJpX3VpZGl2bW9kKQorCXN0bWZkICAgc3AhLCB7cjAsIHIxLCBpcCwgbHJ9
CisJYmwgICAgICBfX2FlYWJpX3VpZGl2CisJbGRtZmQgICBzcCEsIHtyMSwgcjIsIGlwLCBs
cn0KKwltdWwgICAgIHIzLCByMCwgcjIKKwlzdWIgICAgIHIxLCByMSwgcjMKKwltb3YgICAg
IHBjLCBscgorCitFTlRSWShfX2FlYWJpX2lkaXZtb2QpCisJc3RtZmQgICBzcCEsIHtyMCwg
cjEsIGlwLCBscn0KKwlibCAgICAgIF9fYWVhYmlfaWRpdgorCWxkbWZkICAgc3AhLCB7cjEs
IHIyLCBpcCwgbHJ9CisJbXVsICAgICByMywgcjAsIHIyCisJc3ViICAgICByMSwgcjEsIHIz
CisJbW92ICAgICBwYywgbHIKKworTGRpdjA6CisKKwlzdHIJbHIsIFtzcCwgIy04XSEKKwli
bAlfX2RpdjAKKwltb3YJcjAsICMwCQkJQCBBYm91dCBhcyB3cm9uZyBhcyBpdCBjb3VsZCBi
ZS4KKwlsZHIJcGMsIFtzcF0sICM4CisKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJj
aC9hcm0vbGliL2xvbmdsb25nLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9sb25nbG9uZy5oCUZyaSBGZWIg
MDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDE4MyBAQAorLyogbG9uZ2xvbmcu
aCAtLSBiYXNlZCBvbiBjb2RlIGZyb20gZ2NjLTIuOTUuMworCisgICBkZWZpbml0aW9ucyBm
b3IgbWl4ZWQgc2l6ZSAzMi82NCBiaXQgYXJpdGhtZXRpYy4KKyAgIENvcHlyaWdodCAoQykg
MTk5MSwgOTIsIDk0LCA5NSwgOTYsIDE5OTcsIDE5OTggRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uLCBJbmMuCisKKyAgIFRoaXMgZGVmaW5pdGlvbiBmaWxlIGlzIGZyZWUgc29mdHdhcmU7
IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0CisgICBhbmQvb3IgbW9kaWZ5IGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljCisgICBMaWNlbnNlIGFzIHB1Ymxp
c2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIKKyAgIHZlcnNp
b24gMiwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKworICAgVGhp
cyBkZWZpbml0aW9uIGZpbGUgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3
aWxsIGJlCisgICB1c2VmdWwsIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBl
dmVuIHRoZSBpbXBsaWVkCisgICB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IgRklU
TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCisgICBTZWUgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisKKyAgIFlvdSBzaG91bGQgaGF2
ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisg
ICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBT
b2Z0d2FyZQorICAgRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUg
MzMwLAorICAgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuICAqLworCisvKiBCb3Jyb3dl
ZCBmcm9tIEdDQyAyLjk1LjMsIEkgTW9sdG9uIDI5LzA3LzAxICovCisKKyNpZm5kZWYgU0lf
VFlQRV9TSVpFCisjZGVmaW5lIFNJX1RZUEVfU0laRSAzMgorI2VuZGlmCisKKyNkZWZpbmUg
X19CSVRTNCAoU0lfVFlQRV9TSVpFIC8gNCkKKyNkZWZpbmUgX19sbF9CICgxTCA8PCAoU0lf
VFlQRV9TSVpFIC8gMikpCisjZGVmaW5lIF9fbGxfbG93cGFydCh0KSAoKFVTSXR5cGUpICh0
KSAlIF9fbGxfQikKKyNkZWZpbmUgX19sbF9oaWdocGFydCh0KSAoKFVTSXR5cGUpICh0KSAv
IF9fbGxfQikKKworLyogRGVmaW5lIGF1eGlsaWFyeSBhc20gbWFjcm9zLgorCisgICAxKSB1
bXVsX3BwbW0oaGlnaF9wcm9kLCBsb3dfcHJvZCwgbXVsdGlwbGVyLCBtdWx0aXBsaWNhbmQp
CisgICBtdWx0aXBsaWVzIHR3byBVU0l0eXBlIGludGVnZXJzIE1VTFRJUExFUiBhbmQgTVVM
VElQTElDQU5ELAorICAgYW5kIGdlbmVyYXRlcyBhIHR3by1wYXJ0IFVTSXR5cGUgcHJvZHVj
dCBpbiBISUdIX1BST0QgYW5kCisgICBMT1dfUFJPRC4KKworICAgMikgX191bXVsc2lkaTMo
YSxiKSBtdWx0aXBsaWVzIHR3byBVU0l0eXBlIGludGVnZXJzIEEgYW5kIEIsCisgICBhbmQg
cmV0dXJucyBhIFVESXR5cGUgcHJvZHVjdC4gIFRoaXMgaXMganVzdCBhIHZhcmlhbnQgb2Yg
dW11bF9wcG1tLgorCisgICAzKSB1ZGl2X3Fybm5kKHF1b3RpZW50LCByZW1haW5kZXIsIGhp
Z2hfbnVtZXJhdG9yLCBsb3dfbnVtZXJhdG9yLAorICAgZGVub21pbmF0b3IpIGRpdmlkZXMg
YSB0d28td29yZCB1bnNpZ25lZCBpbnRlZ2VyLCBjb21wb3NlZCBieSB0aGUKKyAgIGludGVn
ZXJzIEhJR0hfTlVNRVJBVE9SIGFuZCBMT1dfTlVNRVJBVE9SLCBieSBERU5PTUlOQVRPUiBh
bmQKKyAgIHBsYWNlcyB0aGUgcXVvdGllbnQgaW4gUVVPVElFTlQgYW5kIHRoZSByZW1haW5k
ZXIgaW4gUkVNQUlOREVSLgorICAgSElHSF9OVU1FUkFUT1IgbXVzdCBiZSBsZXNzIHRoYW4g
REVOT01JTkFUT1IgZm9yIGNvcnJlY3Qgb3BlcmF0aW9uLgorICAgSWYsIGluIGFkZGl0aW9u
LCB0aGUgbW9zdCBzaWduaWZpY2FudCBiaXQgb2YgREVOT01JTkFUT1IgbXVzdCBiZSAxLAor
ICAgdGhlbiB0aGUgcHJlLXByb2Nlc3NvciBzeW1ib2wgVURJVl9ORUVEU19OT1JNQUxJWkFU
SU9OIGlzIGRlZmluZWQgdG8gMS4KKworICAgNCkgc2Rpdl9xcm5uZChxdW90aWVudCwgcmVt
YWluZGVyLCBoaWdoX251bWVyYXRvciwgbG93X251bWVyYXRvciwKKyAgIGRlbm9taW5hdG9y
KS4gIExpa2UgdWRpdl9xcm5uZCBidXQgdGhlIG51bWJlcnMgYXJlIHNpZ25lZC4gIFRoZQor
ICAgcXVvdGllbnQgaXMgcm91bmRlZCB0b3dhcmRzIDAuCisKKyAgIDUpIGNvdW50X2xlYWRp
bmdfemVyb3MoY291bnQsIHgpIGNvdW50cyB0aGUgbnVtYmVyIG9mIHplcm8tYml0cyBmcm9t
CisgICB0aGUgbXNiIHRvIHRoZSBmaXJzdCBub24temVybyBiaXQuICBUaGlzIGlzIHRoZSBu
dW1iZXIgb2Ygc3RlcHMgWAorICAgbmVlZHMgdG8gYmUgc2hpZnRlZCBsZWZ0IHRvIHNldCB0
aGUgbXNiLiAgVW5kZWZpbmVkIGZvciBYID09IDAuCisKKyAgIDYpIGFkZF9zc2FhYWEoaGln
aF9zdW0sIGxvd19zdW0sIGhpZ2hfYWRkZW5kXzEsIGxvd19hZGRlbmRfMSwKKyAgIGhpZ2hf
YWRkZW5kXzIsIGxvd19hZGRlbmRfMikgYWRkcyB0d28gdHdvLXdvcmQgdW5zaWduZWQgaW50
ZWdlcnMsCisgICBjb21wb3NlZCBieSBISUdIX0FEREVORF8xIGFuZCBMT1dfQURERU5EXzEs
IGFuZCBISUdIX0FEREVORF8yIGFuZAorICAgTE9XX0FEREVORF8yIHJlc3BlY3RpdmVseS4g
IFRoZSByZXN1bHQgaXMgcGxhY2VkIGluIEhJR0hfU1VNIGFuZAorICAgTE9XX1NVTS4gIE92
ZXJmbG93IChpLmUuIGNhcnJ5IG91dCkgaXMgbm90IHN0b3JlZCBhbnl3aGVyZSwgYW5kIGlz
CisgICBsb3N0LgorCisgICA3KSBzdWJfZGRtbXNzKGhpZ2hfZGlmZmVyZW5jZSwgbG93X2Rp
ZmZlcmVuY2UsIGhpZ2hfbWludWVuZCwKKyAgIGxvd19taW51ZW5kLCBoaWdoX3N1YnRyYWhl
bmQsIGxvd19zdWJ0cmFoZW5kKSBzdWJ0cmFjdHMgdHdvCisgICB0d28td29yZCB1bnNpZ25l
ZCBpbnRlZ2VycywgY29tcG9zZWQgYnkgSElHSF9NSU5VRU5EXzEgYW5kCisgICBMT1dfTUlO
VUVORF8xLCBhbmQgSElHSF9TVUJUUkFIRU5EXzIgYW5kIExPV19TVUJUUkFIRU5EXzIKKyAg
IHJlc3BlY3RpdmVseS4gIFRoZSByZXN1bHQgaXMgcGxhY2VkIGluIEhJR0hfRElGRkVSRU5D
RSBhbmQKKyAgIExPV19ESUZGRVJFTkNFLiAgT3ZlcmZsb3cgKGkuZS4gY2Fycnkgb3V0KSBp
cyBub3Qgc3RvcmVkIGFueXdoZXJlLAorICAgYW5kIGlzIGxvc3QuCisKKyAgIElmIGFueSBv
ZiB0aGVzZSBtYWNyb3MgYXJlIGxlZnQgdW5kZWZpbmVkIGZvciBhIHBhcnRpY3VsYXIgQ1BV
LAorICAgQyBtYWNyb3MgYXJlIHVzZWQuICAqLworCisjaWYgZGVmaW5lZCAoX19hcm1fXykK
KyNkZWZpbmUgYWRkX3NzYWFhYShzaCwgc2wsIGFoLCBhbCwgYmgsIGJsKSBcCisgIF9fYXNt
X18gKCJhZGRzCSUxLCAlNCwgJTUJCQkJCVxuXAorCWFkYwklMCwgJTIsICUzIgkJCQkJCVwK
KwkgICA6ICI9ciIgKChVU0l0eXBlKSAoc2gpKSwJCQkJCVwKKwkgICAgICI9JnIiICgoVVNJ
dHlwZSkgKHNsKSkJCQkJCVwKKwkgICA6ICIlciIgKChVU0l0eXBlKSAoYWgpKSwJCQkJCVwK
KwkgICAgICJySSIgKChVU0l0eXBlKSAoYmgpKSwJCQkJCVwKKwkgICAgICIlciIgKChVU0l0
eXBlKSAoYWwpKSwJCQkJCVwKKwkgICAgICJySSIgKChVU0l0eXBlKSAoYmwpKSkKKyNkZWZp
bmUgc3ViX2RkbW1zcyhzaCwgc2wsIGFoLCBhbCwgYmgsIGJsKSBcCisgIF9fYXNtX18gKCJz
dWJzCSUxLCAlNCwgJTUJCQkJCVxuXAorCXNiYwklMCwgJTIsICUzIgkJCQkJCVwKKwkgICA6
ICI9ciIgKChVU0l0eXBlKSAoc2gpKSwJCQkJCVwKKwkgICAgICI9JnIiICgoVVNJdHlwZSkg
KHNsKSkJCQkJCVwKKwkgICA6ICJyIiAoKFVTSXR5cGUpIChhaCkpLAkJCQkJXAorCSAgICAg
InJJIiAoKFVTSXR5cGUpIChiaCkpLAkJCQkJXAorCSAgICAgInIiICgoVVNJdHlwZSkgKGFs
KSksCQkJCQlcCisJICAgICAickkiICgoVVNJdHlwZSkgKGJsKSkpCisjZGVmaW5lIHVtdWxf
cHBtbSh4aCwgeGwsIGEsIGIpIFwKK3tyZWdpc3RlciBVU0l0eXBlIF9fdDAsIF9fdDEsIF9f
dDI7CQkJCQlcCisgIF9fYXNtX18gKCIlQCBJbmxpbmVkIHVtdWxfcHBtbQkJCQkJXG5cCisJ
bW92CSUyLCAlNSwgbHNyICMxNgkJCQkJCVxuXAorCW1vdgklMCwgJTYsIGxzciAjMTYJCQkJ
CQlcblwKKwliaWMJJTMsICU1LCAlMiwgbHNsICMxNgkJCQkJXG5cCisJYmljCSU0LCAlNiwg
JTAsIGxzbCAjMTYJCQkJCVxuXAorCW11bAklMSwgJTMsICU0CQkJCQkJXG5cCisJbXVsCSU0
LCAlMiwgJTQJCQkJCQlcblwKKwltdWwJJTMsICUwLCAlMwkJCQkJCVxuXAorCW11bAklMCwg
JTIsICUwCQkJCQkJXG5cCisJYWRkcwklMywgJTQsICUzCQkJCQkJXG5cCisJYWRkY3MJJTAs
ICUwLCAjNjU1MzYJCQkJCQlcblwKKwlhZGRzCSUxLCAlMSwgJTMsIGxzbCAjMTYJCQkJCVxu
XAorCWFkYwklMCwgJTAsICUzLCBsc3IgIzE2IgkJCQkJXAorCSAgIDogIj0mciIgKChVU0l0
eXBlKSAoeGgpKSwJCQkJCVwKKwkgICAgICI9ciIgKChVU0l0eXBlKSAoeGwpKSwJCQkJCVwK
KwkgICAgICI9JnIiIChfX3QwKSwgIj0mciIgKF9fdDEpLCAiPXIiIChfX3QyKQkJCVwKKwkg
ICA6ICJyIiAoKFVTSXR5cGUpIChhKSksCQkJCQlcCisJICAgICAiciIgKChVU0l0eXBlKSAo
YikpKTt9CisjZGVmaW5lIFVNVUxfVElNRSAyMAorI2RlZmluZSBVRElWX1RJTUUgMTAwCisj
ZW5kaWYgLyogX19hcm1fXyAqLworCisjZGVmaW5lIF9fdW11bHNpZGkzKHUsIHYpIFwKKyAg
KHtESXVuaW9uIF9fdzsJCQkJCQkJXAorICAgIHVtdWxfcHBtbSAoX193LnMuaGlnaCwgX193
LnMubG93LCB1LCB2KTsJCQkJXAorICAgIF9fdy5sbDsgfSkKKworI2RlZmluZSBfX3VkaXZf
cXJubmRfYyhxLCByLCBuMSwgbjAsIGQpIFwKKyAgZG8gewkJCQkJCQkJCVwKKyAgICBVU0l0
eXBlIF9fZDEsIF9fZDAsIF9fcTEsIF9fcTA7CQkJCQlcCisgICAgVVNJdHlwZSBfX3IxLCBf
X3IwLCBfX207CQkJCQkJXAorICAgIF9fZDEgPSBfX2xsX2hpZ2hwYXJ0IChkKTsJCQkJCQlc
CisgICAgX19kMCA9IF9fbGxfbG93cGFydCAoZCk7CQkJCQkJXAorCQkJCQkJCQkJXAorICAg
IF9fcjEgPSAobjEpICUgX19kMTsJCQkJCQkJXAorICAgIF9fcTEgPSAobjEpIC8gX19kMTsJ
CQkJCQkJXAorICAgIF9fbSA9IChVU0l0eXBlKSBfX3ExICogX19kMDsJCQkJCVwKKyAgICBf
X3IxID0gX19yMSAqIF9fbGxfQiB8IF9fbGxfaGlnaHBhcnQgKG4wKTsJCQkJXAorICAgIGlm
IChfX3IxIDwgX19tKQkJCQkJCQlcCisgICAgICB7CQkJCQkJCQkJXAorCV9fcTEtLSwgX19y
MSArPSAoZCk7CQkJCQkJXAorCWlmIChfX3IxID49IChkKSkgLyogaS5lLiB3ZSBkaWRuJ3Qg
Z2V0IGNhcnJ5IHdoZW4gYWRkaW5nIHRvIF9fcjEgKi9cCisJICBpZiAoX19yMSA8IF9fbSkJ
CQkJCQlcCisJICAgIF9fcTEtLSwgX19yMSArPSAoZCk7CQkJCQlcCisgICAgICB9CQkJCQkJ
CQkJXAorICAgIF9fcjEgLT0gX19tOwkJCQkJCQlcCisJCQkJCQkJCQlcCisgICAgX19yMCA9
IF9fcjEgJSBfX2QxOwkJCQkJCQlcCisgICAgX19xMCA9IF9fcjEgLyBfX2QxOwkJCQkJCQlc
CisgICAgX19tID0gKFVTSXR5cGUpIF9fcTAgKiBfX2QwOwkJCQkJXAorICAgIF9fcjAgPSBf
X3IwICogX19sbF9CIHwgX19sbF9sb3dwYXJ0IChuMCk7CQkJCVwKKyAgICBpZiAoX19yMCA8
IF9fbSkJCQkJCQkJXAorICAgICAgewkJCQkJCQkJCVwKKwlfX3EwLS0sIF9fcjAgKz0gKGQp
OwkJCQkJCVwKKwlpZiAoX19yMCA+PSAoZCkpCQkJCQkJXAorCSAgaWYgKF9fcjAgPCBfX20p
CQkJCQkJXAorCSAgICBfX3EwLS0sIF9fcjAgKz0gKGQpOwkJCQkJXAorICAgICAgfQkJCQkJ
CQkJCVwKKyAgICBfX3IwIC09IF9fbTsJCQkJCQkJXAorCQkJCQkJCQkJXAorICAgIChxKSA9
IChVU0l0eXBlKSBfX3ExICogX19sbF9CIHwgX19xMDsJCQkJXAorICAgIChyKSA9IF9fcjA7
CQkJCQkJCQlcCisgIH0gd2hpbGUgKDApCisKKyNkZWZpbmUgVURJVl9ORUVEU19OT1JNQUxJ
WkFUSU9OIDEKKyNkZWZpbmUgdWRpdl9xcm5uZCBfX3VkaXZfcXJubmRfYworCisjZGVmaW5l
IGNvdW50X2xlYWRpbmdfemVyb3MoY291bnQsIHgpIFwKKyAgZG8gewkJCQkJCQkJCVwKKyAg
ICBVU0l0eXBlIF9feHIgPSAoeCk7CQkJCQkJCVwKKyAgICBVU0l0eXBlIF9fYTsJCQkJCQkJ
XAorCQkJCQkJCQkJXAorICAgIGlmIChTSV9UWVBFX1NJWkUgPD0gMzIpCQkJCQkJXAorICAg
ICAgewkJCQkJCQkJCVwKKwlfX2EgPSBfX3hyIDwgKChVU0l0eXBlKTE8PDIqX19CSVRTNCkJ
CQkJXAorCSAgPyAoX194ciA8ICgoVVNJdHlwZSkxPDxfX0JJVFM0KSA/IDAgOiBfX0JJVFM0
KQkJXAorCSAgOiAoX194ciA8ICgoVVNJdHlwZSkxPDwzKl9fQklUUzQpID8gIDIqX19CSVRT
NCA6IDMqX19CSVRTNCk7CVwKKyAgICAgIH0JCQkJCQkJCQlcCisgICAgZWxzZQkJCQkJCQkJ
XAorICAgICAgewkJCQkJCQkJCVwKKwlmb3IgKF9fYSA9IFNJX1RZUEVfU0laRSAtIDg7IF9f
YSA+IDA7IF9fYSAtPSA4KQkJCVwKKwkgIGlmICgoKF9feHIgPj4gX19hKSAmIDB4ZmYpICE9
IDApCQkJCVwKKwkgICAgYnJlYWs7CQkJCQkJCVwKKyAgICAgIH0JCQkJCQkJCQlcCisJCQkJ
CQkJCQlcCisgICAgKGNvdW50KSA9IFNJX1RZUEVfU0laRSAtIChfX2Nsel90YWJbX194ciA+
PiBfX2FdICsgX19hKTsJCVwKKyAgfSB3aGlsZSAoMCkKZGlmZiAtciBlNzAxNDYxYjEyNTEg
eGVuL2FyY2gvYXJtL2xpYi9sc2hyZGkzLlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9sc2hyZGkzLlMJRnJp
IEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTcgQEAKKyNpbmNsdWRl
IDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworI2RlZmlu
ZSBhbCByMAorI2RlZmluZSBhaCByMQorCitFTlRSWShfX2xzaHJkaTMpCitFTlRSWShfX2Fl
YWJpX2xsc3IpCisKKyAgICAgICAgc3VicyAgICByMywgcjIsICMzMgorICAgICAgICByc2Ig
ICAgIGlwLCByMiwgIzMyCisgICAgICAgIG1vdm1pICAgYWwsIGFsLCBsc3IgcjIKKyAgICAg
ICAgbW92cGwgICBhbCwgYWgsIGxzciByMworIAlvcnJtaSAgIGFsLCBhbCwgYWgsIGxzbCBp
cCAKKyAgICAgICAgbW92ICAgICBhaCwgYWgsIGxzciByMgorICAgICAgICBtb3YgICAgIHBj
LCBscgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvbWF0aC5jCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9h
cmNoL2FybS9saWIvbWF0aC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAt
MCwwICsxLDMgQEAKK3ZvaWQgbWR1bW15KHZvaWQpCit7Cit9CmRpZmYgLXIgZTcwMTQ2MWIx
MjUxIHhlbi9hcmNoL2FybS9saWIvbWVtY2hyLlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9tZW1jaHIuUwlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxNCBAQAorI2luY2x1
ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisJLnRl
eHQKKwkuYWxpZ24JNQorRU5UUlkobWVtY2hyKQorMToJc3VicwlyMiwgcjIsICMxCisJYm1p
CTJmCisJbGRyYglyMywgW3IwXSwgIzEKKwl0ZXEJcjMsIHIxCisJYm5lCTFiCisJc3ViCXIw
LCByMCwgIzEKKzI6CW1vdm5lCXIwLCAjMAorCW1vdglwYyxscgpkaWZmIC1yIGU3MDE0NjFi
MTI1MSB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvbWVtY3B5LlMJ
RnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjAgQEAKKy8qCisg
KiAgbGludXgvYXJjaC9hcm0vbGliL21lbWNweS5TCisgKgorICogIEF1dGhvcjoJTmljb2xh
cyBQaXRyZQorICogIENyZWF0ZWQ6CVNlcCAyOCwgMjAwNQorICogIENvcHlyaWdodDoJTW9u
dGFWaXN0YSBTb2Z0d2FyZSwgSW5jLgorICoKKyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0
IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVy
c2lvbiAyIGFzCisgKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24uCisgKi8KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNt
LW1hY3Jvcy5oPgorCisKKwkubWFjcm8gbGRyMXcgcHRyIHJlZyBhYm9ydAorCWxkciBccmVn
LCBbXHB0cl0sICM0CisJLmVuZG0KKworCS5tYWNybyBsZHI0dyBwdHIgcmVnMSByZWcyIHJl
ZzMgcmVnNCBhYm9ydAorCWxkbWlhIFxwdHIhLCB7XHJlZzEsIFxyZWcyLCBccmVnMywgXHJl
ZzR9CisJLmVuZG0KKworCS5tYWNybyBsZHI4dyBwdHIgcmVnMSByZWcyIHJlZzMgcmVnNCBy
ZWc1IHJlZzYgcmVnNyByZWc4IGFib3J0CisJbGRtaWEgXHB0ciEsIHtccmVnMSwgXHJlZzIs
IFxyZWczLCBccmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywgXHJlZzh9CisJLmVuZG0KKwor
CS5tYWNybyBsZHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQKKwlsZHJcY29uZFwoKWIgXHJl
ZywgW1xwdHJdLCAjMQorCS5lbmRtCisKKwkubWFjcm8gc3RyMXcgcHRyIHJlZyBhYm9ydAor
CXN0ciBccmVnLCBbXHB0cl0sICM0CisJLmVuZG0KKworCS5tYWNybyBzdHI4dyBwdHIgcmVn
MSByZWcyIHJlZzMgcmVnNCByZWc1IHJlZzYgcmVnNyByZWc4IGFib3J0CisJc3RtaWEgXHB0
ciEsIHtccmVnMSwgXHJlZzIsIFxyZWczLCBccmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywg
XHJlZzh9CisJLmVuZG0KKworCS5tYWNybyBzdHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQK
KwlzdHJcY29uZFwoKWIgXHJlZywgW1xwdHJdLCAjMQorCS5lbmRtCisKKwkubWFjcm8gZW50
ZXIgcmVnMSByZWcyCisJc3RtZGIgc3AhLCB7cjAsIFxyZWcxLCBccmVnMn0KKwkuZW5kbQor
CisJLm1hY3JvIGV4aXQgcmVnMSByZWcyCisJbGRtZmQgc3AhLCB7cjAsIFxyZWcxLCBccmVn
Mn0KKwkuZW5kbQorCisJLnRleHQKKworLyogUHJvdG90eXBlOiB2b2lkICptZW1jcHkodm9p
ZCAqZGVzdCwgY29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgbik7ICovCisKK0VOVFJZKG1lbWNw
eSkKKworI2luY2x1ZGUgImNvcHlfdGVtcGxhdGUuUyIKKwpkaWZmIC1yIGU3MDE0NjFiMTI1
MSB4ZW4vYXJjaC9hcm0vbGliL21lbW1vdmUuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL21lbW1vdmUuUwlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyMDcgQEAKKy8qCisg
KiAgbGludXgvYXJjaC9hcm0vbGliL21lbW1vdmUuUworICoKKyAqICBBdXRob3I6CU5pY29s
YXMgUGl0cmUKKyAqICBDcmVhdGVkOglTZXAgMjgsIDIwMDUKKyAqICBDb3B5cmlnaHQ6CShD
KSBNb250YVZpc3RhIFNvZnR3YXJlIEluYy4KKyAqCisgKiAgVGhpcyBwcm9ncmFtIGlzIGZy
ZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAq
ICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IHZlcnNpb24gMiBhcworICogIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uLgorICovCisKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNt
L2FzbS1tYWNyb3MuaD4KKworCisvKgorICogVGhpcyBjYW4gYmUgdXNlZCB0byBlbmFibGUg
Y29kZSB0byBjYWNoZWxpbmUgYWxpZ24gdGhlIHNvdXJjZSBwb2ludGVyLgorICogRXhwZXJp
bWVudHMgb24gdGVzdGVkIGFyY2hpdGVjdHVyZXMgKFN0cm9uZ0FSTSBhbmQgWFNjYWxlKSBk
aWRuJ3Qgc2hvdworICogdGhpcyBhIHdvcnRod2hpbGUgdGhpbmcgdG8gZG8uICBUaGF0IG1p
Z2h0IGJlIGRpZmZlcmVudCBpbiB0aGUgZnV0dXJlLgorICovCisvLyNkZWZpbmUgQ0FMR04o
Y29kZS4uLikgICAgICAgIGNvZGUKKyNkZWZpbmUgQ0FMR04oY29kZS4uLikKKworCQkudGV4
dAorCisvKgorICogUHJvdG90eXBlOiB2b2lkICptZW1tb3ZlKHZvaWQgKmRlc3QsIGNvbnN0
IHZvaWQgKnNyYywgc2l6ZV90IG4pOworICoKKyAqIE5vdGU6CisgKgorICogSWYgdGhlIG1l
bW9yeSByZWdpb25zIGRvbid0IG92ZXJsYXAsIHdlIHNpbXBseSBicmFuY2ggdG8gbWVtY3B5
IHdoaWNoIGlzCisgKiBub3JtYWxseSBhIGJpdCBmYXN0ZXIuIE90aGVyd2lzZSB0aGUgY29w
eSBpcyBkb25lIGdvaW5nIGRvd253YXJkcy4gIFRoaXMKKyAqIGlzIGEgdHJhbnNwb3NpdGlv
biBvZiB0aGUgY29kZSBmcm9tIGNvcHlfdGVtcGxhdGUuUyBidXQgd2l0aCB0aGUgY29weQor
ICogb2NjdXJyaW5nIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24uCisgKi8KKworRU5UUlko
bWVtbW92ZSkKKworCQlzdWJzCWlwLCByMCwgcjEKKwkJY21waGkJcjIsIGlwCisJCWJscwlt
ZW1jcHkKKworCQlzdG1mZAlzcCEsIHtyMCwgcjQsIGxyfQorCQlhZGQJcjEsIHIxLCByMgor
CQlhZGQJcjAsIHIwLCByMgorCQlzdWJzCXIyLCByMiwgIzQKKwkJYmx0CThmCisJCWFuZHMJ
aXAsIHIwLCAjMworCVBMRCgJcGxkCVtyMSwgIy00XQkJKQorCQlibmUJOWYKKwkJYW5kcwlp
cCwgcjEsICMzCisJCWJuZQkxMGYKKworMToJCXN1YnMJcjIsIHIyLCAjKDI4KQorCQlzdG1m
ZAlzcCEsIHtyNSAtIHI4fQorCQlibHQJNWYKKworCUNBTEdOKAlhbmRzCWlwLCByMSwgIzMx
CQkpCisJQ0FMR04oCXNiY25lcwlyNCwgaXAsIHIyCQkpICBAIEMgaXMgYWx3YXlzIHNldCBo
ZXJlCisJQ0FMR04oCWJjcwkyZgkJCSkKKwlDQUxHTigJYWRyCXI0LCA2ZgkJCSkKKwlDQUxH
TigJc3VicwlyMiwgcjIsIGlwCQkpICBAIEMgaXMgc2V0IGhlcmUKKwlDQUxHTigJYWRkCXBj
LCByNCwgaXAJCSkKKworCVBMRCgJcGxkCVtyMSwgIy00XQkJKQorMjoJUExEKAlzdWJzCXIy
LCByMiwgIzk2CQkpCisJUExEKAlwbGQJW3IxLCAjLTMyXQkJKQorCVBMRCgJYmx0CTRmCQkJ
KQorCVBMRCgJcGxkCVtyMSwgIy02NF0JCSkKKwlQTEQoCXBsZAlbcjEsICMtOTZdCQkpCisK
KzM6CVBMRCgJcGxkCVtyMSwgIy0xMjhdCQkpCis0OgkJbGRtZGIJcjEhLCB7cjMsIHI0LCBy
NSwgcjYsIHI3LCByOCwgaXAsIGxyfQorCQlzdWJzCXIyLCByMiwgIzMyCisJCXN0bWRiCXIw
ISwge3IzLCByNCwgcjUsIHI2LCByNywgcjgsIGlwLCBscn0KKwkJYmdlCTNiCisJUExEKAlj
bW4JcjIsICM5NgkJCSkKKwlQTEQoCWJnZQk0YgkJCSkKKworNToJCWFuZHMJaXAsIHIyLCAj
MjgKKwkJcnNiCWlwLCBpcCwgIzMyCisJCWFkZG5lCXBjLCBwYywgaXAJCUAgQyBpcyBhbHdh
eXMgY2xlYXIgaGVyZQorCQliCTdmCis2OgkJbm9wCisJCWxkcglyMywgW3IxLCAjLTRdIQor
CQlsZHIJcjQsIFtyMSwgIy00XSEKKwkJbGRyCXI1LCBbcjEsICMtNF0hCisJCWxkcglyNiwg
W3IxLCAjLTRdIQorCQlsZHIJcjcsIFtyMSwgIy00XSEKKwkJbGRyCXI4LCBbcjEsICMtNF0h
CisJCWxkcglsciwgW3IxLCAjLTRdIQorCisJCWFkZAlwYywgcGMsIGlwCisJCW5vcAorCQlu
b3AKKwkJc3RyCXIzLCBbcjAsICMtNF0hCisJCXN0cglyNCwgW3IwLCAjLTRdIQorCQlzdHIJ
cjUsIFtyMCwgIy00XSEKKwkJc3RyCXI2LCBbcjAsICMtNF0hCisJCXN0cglyNywgW3IwLCAj
LTRdIQorCQlzdHIJcjgsIFtyMCwgIy00XSEKKwkJc3RyCWxyLCBbcjAsICMtNF0hCisKKwlD
QUxHTigJYmNzCTJiCQkJKQorCis3OgkJbGRtZmQJc3AhLCB7cjUgLSByOH0KKworODoJCW1v
dnMJcjIsIHIyLCBsc2wgIzMxCisJCWxkcm5lYglyMywgW3IxLCAjLTFdIQorCQlsZHJjc2IJ
cjQsIFtyMSwgIy0xXSEKKwkJbGRyY3NiCWlwLCBbcjEsICMtMV0KKwkJc3RybmViCXIzLCBb
cjAsICMtMV0hCisJCXN0cmNzYglyNCwgW3IwLCAjLTFdIQorCQlzdHJjc2IJaXAsIFtyMCwg
Iy0xXQorCQlsZG1mZAlzcCEsIHtyMCwgcjQsIHBjfQorCis5OgkJY21wCWlwLCAjMgorCQls
ZHJndGIJcjMsIFtyMSwgIy0xXSEKKwkJbGRyZ2ViCXI0LCBbcjEsICMtMV0hCisJCWxkcmIJ
bHIsIFtyMSwgIy0xXSEKKwkJc3RyZ3RiCXIzLCBbcjAsICMtMV0hCisJCXN0cmdlYglyNCwg
W3IwLCAjLTFdIQorCQlzdWJzCXIyLCByMiwgaXAKKwkJc3RyYglsciwgW3IwLCAjLTFdIQor
CQlibHQJOGIKKwkJYW5kcwlpcCwgcjEsICMzCisJCWJlcQkxYgorCisxMDoJCWJpYwlyMSwg
cjEsICMzCisJCWNtcAlpcCwgIzIKKwkJbGRyCXIzLCBbcjEsICMwXQorCQliZXEJMTdmCisJ
CWJsdAkxOGYKKworCisJCS5tYWNybwliYWNrd2FyZF9jb3B5X3NoaWZ0IHB1c2ggcHVsbAor
CisJCXN1YnMJcjIsIHIyLCAjMjgKKwkJYmx0CTE0ZgorCisJQ0FMR04oCWFuZHMJaXAsIHIx
LCAjMzEJCSkKKwlDQUxHTigJcnNiCWlwLCBpcCwgIzMyCQkpCisJQ0FMR04oCXNiY25lcwly
NCwgaXAsIHIyCQkpICBAIEMgaXMgYWx3YXlzIHNldCBoZXJlCisJQ0FMR04oCXN1YmNjCXIy
LCByMiwgaXAJCSkKKwlDQUxHTigJYmNjCTE1ZgkJCSkKKworMTE6CQlzdG1mZAlzcCEsIHty
NSAtIHI5fQorCisJUExEKAlwbGQJW3IxLCAjLTRdCQkpCisJUExEKAlzdWJzCXIyLCByMiwg
Izk2CQkpCisJUExEKAlwbGQJW3IxLCAjLTMyXQkJKQorCVBMRCgJYmx0CTEzZgkJCSkKKwlQ
TEQoCXBsZAlbcjEsICMtNjRdCQkpCisJUExEKAlwbGQJW3IxLCAjLTk2XQkJKQorCisxMjoJ
UExEKAlwbGQJW3IxLCAjLTEyOF0JCSkKKzEzOgkJbGRtZGIgICByMSEsIHtyNywgcjgsIHI5
LCBpcH0KKwkJbW92ICAgICBsciwgcjMsIHB1c2ggI1xwdXNoCisJCXN1YnMgICAgcjIsIHIy
LCAjMzIKKwkJbGRtZGIgICByMSEsIHtyMywgcjQsIHI1LCByNn0KKwkJb3JyICAgICBsciwg
bHIsIGlwLCBwdWxsICNccHVsbAorCQltb3YgICAgIGlwLCBpcCwgcHVzaCAjXHB1c2gKKwkJ
b3JyICAgICBpcCwgaXAsIHI5LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI5LCByOSwgcHVz
aCAjXHB1c2gKKwkJb3JyICAgICByOSwgcjksIHI4LCBwdWxsICNccHVsbAorCQltb3YgICAg
IHI4LCByOCwgcHVzaCAjXHB1c2gKKwkJb3JyICAgICByOCwgcjgsIHI3LCBwdWxsICNccHVs
bAorCQltb3YgICAgIHI3LCByNywgcHVzaCAjXHB1c2gKKwkJb3JyICAgICByNywgcjcsIHI2
LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI2LCByNiwgcHVzaCAjXHB1c2gKKwkJb3JyICAg
ICByNiwgcjYsIHI1LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI1LCByNSwgcHVzaCAjXHB1
c2gKKwkJb3JyICAgICByNSwgcjUsIHI0LCBwdWxsICNccHVsbAorCQltb3YgICAgIHI0LCBy
NCwgcHVzaCAjXHB1c2gKKwkJb3JyICAgICByNCwgcjQsIHIzLCBwdWxsICNccHVsbAorCQlz
dG1kYiAgIHIwISwge3I0IC0gcjksIGlwLCBscn0KKwkJYmdlCTEyYgorCVBMRCgJY21uCXIy
LCAjOTYJCQkpCisJUExEKAliZ2UJMTNiCQkJKQorCisJCWxkbWZkCXNwISwge3I1IC0gcjl9
CisKKzE0OgkJYW5kcwlpcCwgcjIsICMyOAorCQliZXEJMTZmCisKKzE1OgkJbW92ICAgICBs
ciwgcjMsIHB1c2ggI1xwdXNoCisJCWxkcglyMywgW3IxLCAjLTRdIQorCQlzdWJzCWlwLCBp
cCwgIzQKKwkJb3JyCWxyLCBsciwgcjMsIHB1bGwgI1xwdWxsCisJCXN0cglsciwgW3IwLCAj
LTRdIQorCQliZ3QJMTViCisJQ0FMR04oCWNtcAlyMiwgIzAJCQkpCisJQ0FMR04oCWJnZQkx
MWIJCQkpCisKKzE2OgkJYWRkCXIxLCByMSwgIyhccHVsbCAvIDgpCisJCWIJOGIKKworCQku
ZW5kbQorCisKKwkJYmFja3dhcmRfY29weV9zaGlmdAlwdXNoPTgJcHVsbD0yNAorCisxNzoJ
CWJhY2t3YXJkX2NvcHlfc2hpZnQJcHVzaD0xNglwdWxsPTE2CisKKzE4OgkJYmFja3dhcmRf
Y29weV9zaGlmdAlwdXNoPTI0CXB1bGw9OAorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9h
cmNoL2FybS9saWIvbWVtb3J5LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi9tZW1vcnkuUwlGcmkgRmViIDAz
IDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw0MjEgQEAKKy8qCisgKiAgbGludXgv
YXJjaC9hcm0vbGliL21lbWNweS5TCisgKgorICogIEF1dGhvcjoJTmljb2xhcyBQaXRyZQor
ICogIENyZWF0ZWQ6CVNlcCAyOCwgMjAwNQorICogIENvcHlyaWdodDoJTW9udGFWaXN0YSBT
b2Z0d2FyZSwgSW5jLgorICoKKyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsg
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFz
CisgKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKi8K
KworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5o
PgorCisKKwkubWFjcm8gbGRyMXcgcHRyIHJlZyBhYm9ydAorCWxkciBccmVnLCBbXHB0cl0s
ICM0CisJLmVuZG0KKworCS5tYWNybyBsZHI0dyBwdHIgcmVnMSByZWcyIHJlZzMgcmVnNCBh
Ym9ydAorCWxkbWlhIFxwdHIhLCB7XHJlZzEsIFxyZWcyLCBccmVnMywgXHJlZzR9CisJLmVu
ZG0KKworCS5tYWNybyBsZHI4dyBwdHIgcmVnMSByZWcyIHJlZzMgcmVnNCByZWc1IHJlZzYg
cmVnNyByZWc4IGFib3J0CisJbGRtaWEgXHB0ciEsIHtccmVnMSwgXHJlZzIsIFxyZWczLCBc
cmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywgXHJlZzh9CisJLmVuZG0KKworCS5tYWNybyBs
ZHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQKKwlsZHJcY29uZFwoKWIgXHJlZywgW1xwdHJd
LCAjMQorCS5lbmRtCisKKwkubWFjcm8gc3RyMXcgcHRyIHJlZyBhYm9ydAorCXN0ciBccmVn
LCBbXHB0cl0sICM0CisJLmVuZG0KKworCS5tYWNybyBzdHI4dyBwdHIgcmVnMSByZWcyIHJl
ZzMgcmVnNCByZWc1IHJlZzYgcmVnNyByZWc4IGFib3J0CisJc3RtaWEgXHB0ciEsIHtccmVn
MSwgXHJlZzIsIFxyZWczLCBccmVnNCwgXHJlZzUsIFxyZWc2LCBccmVnNywgXHJlZzh9CisJ
LmVuZG0KKworCS5tYWNybyBzdHIxYiBwdHIgcmVnIGNvbmQ9YWwgYWJvcnQKKwlzdHJcY29u
ZFwoKWIgXHJlZywgW1xwdHJdLCAjMQorCS5lbmRtCisKKwkubWFjcm8gZW50ZXIgcmVnMSBy
ZWcyCisJc3RtZGIgc3AhLCB7cjAsIFxyZWcxLCBccmVnMn0KKwkuZW5kbQorCisJLm1hY3Jv
IGV4aXQgcmVnMSByZWcyCisJbGRtZmQgc3AhLCB7cjAsIFxyZWcxLCBccmVnMn0KKwkuZW5k
bQorCisJLnRleHQKKworLyogUHJvdG90eXBlOiB2b2lkICptZW1jcHkodm9pZCAqZGVzdCwg
Y29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgbik7ICovCisKK0VOVFJZKG1lbWNweSkKKworI2lu
Y2x1ZGUgImNvcHlfdGVtcGxhdGUuUyIKKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNp
bmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisJLnRleHQKKwkuYWxpZ24JNQorRU5UUlko
bWVtY2hyKQorMToJc3VicwlyMiwgcjIsICMxCisJYm1pCTJmCisJbGRyYglyMywgW3IwXSwg
IzEKKwl0ZXEJcjMsIHIxCisJYm5lCTFiCisJc3ViCXIwLCByMCwgIzEKKzI6CW1vdm5lCXIw
LCAjMAorCW1vdglwYyxscgorLyoKKyAqICBsaW51eC9hcmNoL2FybS9saWIvbWVtbW92ZS5T
CisgKgorICogIEF1dGhvcjoJTmljb2xhcyBQaXRyZQorICogIENyZWF0ZWQ6CVNlcCAyOCwg
MjAwNQorICogIENvcHlyaWdodDoJKEMpIE1vbnRhVmlzdGEgU29mdHdhcmUgSW5jLgorICoK
KyAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQorICogIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzCisgKiAgcHVibGlzaGVkIGJ5
IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKi8KKworI2luY2x1ZGUgPHhlbi9j
b25maWcuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisKKy8qCisgKiBUaGlz
IGNhbiBiZSB1c2VkIHRvIGVuYWJsZSBjb2RlIHRvIGNhY2hlbGluZSBhbGlnbiB0aGUgc291
cmNlIHBvaW50ZXIuCisgKiBFeHBlcmltZW50cyBvbiB0ZXN0ZWQgYXJjaGl0ZWN0dXJlcyAo
U3Ryb25nQVJNIGFuZCBYU2NhbGUpIGRpZG4ndCBzaG93CisgKiB0aGlzIGEgd29ydGh3aGls
ZSB0aGluZyB0byBkby4gIFRoYXQgbWlnaHQgYmUgZGlmZmVyZW50IGluIHRoZSBmdXR1cmUu
CisgKi8KKy8vI2RlZmluZSBDQUxHTihjb2RlLi4uKSAgICAgICAgY29kZQorI2RlZmluZSBD
QUxHTihjb2RlLi4uKQorCisJCS50ZXh0CisKKy8qCisgKiBQcm90b3R5cGU6IHZvaWQgKm1l
bW1vdmUodm9pZCAqZGVzdCwgY29uc3Qgdm9pZCAqc3JjLCBzaXplX3Qgbik7CisgKgorICog
Tm90ZToKKyAqCisgKiBJZiB0aGUgbWVtb3J5IHJlZ2lvbnMgZG9uJ3Qgb3ZlcmxhcCwgd2Ug
c2ltcGx5IGJyYW5jaCB0byBtZW1jcHkgd2hpY2ggaXMKKyAqIG5vcm1hbGx5IGEgYml0IGZh
c3Rlci4gT3RoZXJ3aXNlIHRoZSBjb3B5IGlzIGRvbmUgZ29pbmcgZG93bndhcmRzLiAgVGhp
cworICogaXMgYSB0cmFuc3Bvc2l0aW9uIG9mIHRoZSBjb2RlIGZyb20gY29weV90ZW1wbGF0
ZS5TIGJ1dCB3aXRoIHRoZSBjb3B5CisgKiBvY2N1cnJpbmcgaW4gdGhlIG9wcG9zaXRlIGRp
cmVjdGlvbi4KKyAqLworCitFTlRSWShtZW1tb3ZlKQorCisJCXN1YnMJaXAsIHIwLCByMQor
CQljbXBoaQlyMiwgaXAKKwkJYmxzCW1lbWNweQorCisJCXN0bWZkCXNwISwge3IwLCByNCwg
bHJ9CisJCWFkZAlyMSwgcjEsIHIyCisJCWFkZAlyMCwgcjAsIHIyCisJCXN1YnMJcjIsIHIy
LCAjNAorCQlibHQJOGYKKwkJYW5kcwlpcCwgcjAsICMzCisJUExEKAlwbGQJW3IxLCAjLTRd
CQkpCisJCWJuZQk5ZgorCQlhbmRzCWlwLCByMSwgIzMKKwkJYm5lCTEwZgorCisxOgkJc3Vi
cwlyMiwgcjIsICMoMjgpCisJCXN0bWZkCXNwISwge3I1IC0gcjh9CisJCWJsdAk1ZgorCisJ
Q0FMR04oCWFuZHMJaXAsIHIxLCAjMzEJCSkKKwlDQUxHTigJc2JjbmVzCXI0LCBpcCwgcjIJ
CSkgIEAgQyBpcyBhbHdheXMgc2V0IGhlcmUKKwlDQUxHTigJYmNzCTJmCQkJKQorCUNBTEdO
KAlhZHIJcjQsIDZmCQkJKQorCUNBTEdOKAlzdWJzCXIyLCByMiwgaXAJCSkgIEAgQyBpcyBz
ZXQgaGVyZQorCUNBTEdOKAlhZGQJcGMsIHI0LCBpcAkJKQorCisJUExEKAlwbGQJW3IxLCAj
LTRdCQkpCisyOglQTEQoCXN1YnMJcjIsIHIyLCAjOTYJCSkKKwlQTEQoCXBsZAlbcjEsICMt
MzJdCQkpCisJUExEKAlibHQJNGYJCQkpCisJUExEKAlwbGQJW3IxLCAjLTY0XQkJKQorCVBM
RCgJcGxkCVtyMSwgIy05Nl0JCSkKKworMzoJUExEKAlwbGQJW3IxLCAjLTEyOF0JCSkKKzQ6
CQlsZG1kYglyMSEsIHtyMywgcjQsIHI1LCByNiwgcjcsIHI4LCBpcCwgbHJ9CisJCXN1YnMJ
cjIsIHIyLCAjMzIKKwkJc3RtZGIJcjAhLCB7cjMsIHI0LCByNSwgcjYsIHI3LCByOCwgaXAs
IGxyfQorCQliZ2UJM2IKKwlQTEQoCWNtbglyMiwgIzk2CQkJKQorCVBMRCgJYmdlCTRiCQkJ
KQorCis1OgkJYW5kcwlpcCwgcjIsICMyOAorCQlyc2IJaXAsIGlwLCAjMzIKKwkJYWRkbmUJ
cGMsIHBjLCBpcAkJQCBDIGlzIGFsd2F5cyBjbGVhciBoZXJlCisJCWIJN2YKKzY6CQlub3AK
KwkJbGRyCXIzLCBbcjEsICMtNF0hCisJCWxkcglyNCwgW3IxLCAjLTRdIQorCQlsZHIJcjUs
IFtyMSwgIy00XSEKKwkJbGRyCXI2LCBbcjEsICMtNF0hCisJCWxkcglyNywgW3IxLCAjLTRd
IQorCQlsZHIJcjgsIFtyMSwgIy00XSEKKwkJbGRyCWxyLCBbcjEsICMtNF0hCisKKwkJYWRk
CXBjLCBwYywgaXAKKwkJbm9wCisJCW5vcAorCQlzdHIJcjMsIFtyMCwgIy00XSEKKwkJc3Ry
CXI0LCBbcjAsICMtNF0hCisJCXN0cglyNSwgW3IwLCAjLTRdIQorCQlzdHIJcjYsIFtyMCwg
Iy00XSEKKwkJc3RyCXI3LCBbcjAsICMtNF0hCisJCXN0cglyOCwgW3IwLCAjLTRdIQorCQlz
dHIJbHIsIFtyMCwgIy00XSEKKworCUNBTEdOKAliY3MJMmIJCQkpCisKKzc6CQlsZG1mZAlz
cCEsIHtyNSAtIHI4fQorCis4OgkJbW92cwlyMiwgcjIsIGxzbCAjMzEKKwkJbGRybmViCXIz
LCBbcjEsICMtMV0hCisJCWxkcmNzYglyNCwgW3IxLCAjLTFdIQorCQlsZHJjc2IJaXAsIFty
MSwgIy0xXQorCQlzdHJuZWIJcjMsIFtyMCwgIy0xXSEKKwkJc3RyY3NiCXI0LCBbcjAsICMt
MV0hCisJCXN0cmNzYglpcCwgW3IwLCAjLTFdCisJCWxkbWZkCXNwISwge3IwLCByNCwgcGN9
CisKKzk6CQljbXAJaXAsICMyCisJCWxkcmd0YglyMywgW3IxLCAjLTFdIQorCQlsZHJnZWIJ
cjQsIFtyMSwgIy0xXSEKKwkJbGRyYglsciwgW3IxLCAjLTFdIQorCQlzdHJndGIJcjMsIFty
MCwgIy0xXSEKKwkJc3RyZ2ViCXI0LCBbcjAsICMtMV0hCisJCXN1YnMJcjIsIHIyLCBpcAor
CQlzdHJiCWxyLCBbcjAsICMtMV0hCisJCWJsdAk4YgorCQlhbmRzCWlwLCByMSwgIzMKKwkJ
YmVxCTFiCisKKzEwOgkJYmljCXIxLCByMSwgIzMKKwkJY21wCWlwLCAjMgorCQlsZHIJcjMs
IFtyMSwgIzBdCisJCWJlcQkxN2YKKwkJYmx0CTE4ZgorCisKKwkJLm1hY3JvCWJhY2t3YXJk
X2NvcHlfc2hpZnQgcHVzaCBwdWxsCisKKwkJc3VicwlyMiwgcjIsICMyOAorCQlibHQJMTRm
CisKKwlDQUxHTigJYW5kcwlpcCwgcjEsICMzMQkJKQorCUNBTEdOKAlyc2IJaXAsIGlwLCAj
MzIJCSkKKwlDQUxHTigJc2JjbmVzCXI0LCBpcCwgcjIJCSkgIEAgQyBpcyBhbHdheXMgc2V0
IGhlcmUKKwlDQUxHTigJc3ViY2MJcjIsIHIyLCBpcAkJKQorCUNBTEdOKAliY2MJMTVmCQkJ
KQorCisxMToJCXN0bWZkCXNwISwge3I1IC0gcjl9CisKKwlQTEQoCXBsZAlbcjEsICMtNF0J
CSkKKwlQTEQoCXN1YnMJcjIsIHIyLCAjOTYJCSkKKwlQTEQoCXBsZAlbcjEsICMtMzJdCQkp
CisJUExEKAlibHQJMTNmCQkJKQorCVBMRCgJcGxkCVtyMSwgIy02NF0JCSkKKwlQTEQoCXBs
ZAlbcjEsICMtOTZdCQkpCisKKzEyOglQTEQoCXBsZAlbcjEsICMtMTI4XQkJKQorMTM6CQls
ZG1kYiAgIHIxISwge3I3LCByOCwgcjksIGlwfQorCQltb3YgICAgIGxyLCByMywgcHVzaCAj
XHB1c2gKKwkJc3VicyAgICByMiwgcjIsICMzMgorCQlsZG1kYiAgIHIxISwge3IzLCByNCwg
cjUsIHI2fQorCQlvcnIgICAgIGxyLCBsciwgaXAsIHB1bGwgI1xwdWxsCisJCW1vdiAgICAg
aXAsIGlwLCBwdXNoICNccHVzaAorCQlvcnIgICAgIGlwLCBpcCwgcjksIHB1bGwgI1xwdWxs
CisJCW1vdiAgICAgcjksIHI5LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI5LCByOSwgcjgs
IHB1bGwgI1xwdWxsCisJCW1vdiAgICAgcjgsIHI4LCBwdXNoICNccHVzaAorCQlvcnIgICAg
IHI4LCByOCwgcjcsIHB1bGwgI1xwdWxsCisJCW1vdiAgICAgcjcsIHI3LCBwdXNoICNccHVz
aAorCQlvcnIgICAgIHI3LCByNywgcjYsIHB1bGwgI1xwdWxsCisJCW1vdiAgICAgcjYsIHI2
LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI2LCByNiwgcjUsIHB1bGwgI1xwdWxsCisJCW1v
diAgICAgcjUsIHI1LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI1LCByNSwgcjQsIHB1bGwg
I1xwdWxsCisJCW1vdiAgICAgcjQsIHI0LCBwdXNoICNccHVzaAorCQlvcnIgICAgIHI0LCBy
NCwgcjMsIHB1bGwgI1xwdWxsCisJCXN0bWRiICAgcjAhLCB7cjQgLSByOSwgaXAsIGxyfQor
CQliZ2UJMTJiCisJUExEKAljbW4JcjIsICM5NgkJCSkKKwlQTEQoCWJnZQkxM2IJCQkpCisK
KwkJbGRtZmQJc3AhLCB7cjUgLSByOX0KKworMTQ6CQlhbmRzCWlwLCByMiwgIzI4CisJCWJl
cQkxNmYKKworMTU6CQltb3YgICAgIGxyLCByMywgcHVzaCAjXHB1c2gKKwkJbGRyCXIzLCBb
cjEsICMtNF0hCisJCXN1YnMJaXAsIGlwLCAjNAorCQlvcnIJbHIsIGxyLCByMywgcHVsbCAj
XHB1bGwKKwkJc3RyCWxyLCBbcjAsICMtNF0hCisJCWJndAkxNWIKKwlDQUxHTigJY21wCXIy
LCAjMAkJCSkKKwlDQUxHTigJYmdlCTExYgkJCSkKKworMTY6CQlhZGQJcjEsIHIxLCAjKFxw
dWxsIC8gOCkKKwkJYgk4YgorCisJCS5lbmRtCisKKworCQliYWNrd2FyZF9jb3B5X3NoaWZ0
CXB1c2g9OAlwdWxsPTI0CisKKzE3OgkJYmFja3dhcmRfY29weV9zaGlmdAlwdXNoPTE2CXB1
bGw9MTYKKworMTg6CQliYWNrd2FyZF9jb3B5X3NoaWZ0CXB1c2g9MjQJcHVsbD04CisKKyNp
bmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKwor
CS50ZXh0CisJLmFsaWduCTUKKwkud29yZAkwCisKKzE6CXN1YnMJcjIsIHIyLCAjNAkJQCAx
IGRvIHdlIGhhdmUgZW5vdWdoCisJYmx0CTVmCQkJQCAxIGJ5dGVzIHRvIGFsaWduIHdpdGg/
CisJY21wCXIzLCAjMgkJCUAgMQorCXN0cmx0YglyMSwgW3IwXSwgIzEJCUAgMQorCXN0cmxl
YglyMSwgW3IwXSwgIzEJCUAgMQorCXN0cmIJcjEsIFtyMF0sICMxCQlAIDEKKwlhZGQJcjIs
IHIyLCByMwkJQCAxIChyMiA9IHIyIC0gKDQgLSByMykpCisvKgorICogVGhlIHBvaW50ZXIg
aXMgbm93IGFsaWduZWQgYW5kIHRoZSBsZW5ndGggaXMgYWRqdXN0ZWQuICBUcnkgZG9pbmcg
dGhlCisgKiBtZW16ZXJvIGFnYWluLgorICovCisKK0VOVFJZKG1lbXNldCkKKwlhbmRzCXIz
LCByMCwgIzMJCUAgMSB1bmFsaWduZWQ/CisJYm5lCTFiCQkJQCAxCisvKgorICogd2Uga25v
dyB0aGF0IHRoZSBwb2ludGVyIGluIHIwIGlzIGFsaWduZWQgdG8gYSB3b3JkIGJvdW5kYXJ5
LgorICovCisJb3JyCXIxLCByMSwgcjEsIGxzbCAjOAorCW9ycglyMSwgcjEsIHIxLCBsc2wg
IzE2CisJbW92CXIzLCByMQorCWNtcAlyMiwgIzE2CisJYmx0CTRmCisvKgorICogV2UgbmVl
ZCBhbiBleHRyYSByZWdpc3RlciBmb3IgdGhpcyBsb29wIC0gc2F2ZSB0aGUgcmV0dXJuIGFk
ZHJlc3MgYW5kCisgKiB1c2UgdGhlIExSCisgKi8KKwlzdHIJbHIsIFtzcCwgIy00XSEKKwlt
b3YJaXAsIHIxCisJbW92CWxyLCByMQorCisyOglzdWJzCXIyLCByMiwgIzY0CisJc3RtZ2Vp
YQlyMCEsIHtyMSwgcjMsIGlwLCBscn0JQCA2NCBieXRlcyBhdCBhIHRpbWUuCisJc3RtZ2Vp
YQlyMCEsIHtyMSwgcjMsIGlwLCBscn0KKwlzdG1nZWlhCXIwISwge3IxLCByMywgaXAsIGxy
fQorCXN0bWdlaWEJcjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJYmd0CTJiCisJbGRtZXFmZCBz
cCEsIHtwY30JQCBOb3cgPDY0IGJ5dGVzIHRvIGdvLgorLyoKKyAqIE5vIG5lZWQgdG8gY29y
cmVjdCB0aGUgY291bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZyb20gbm93IG9uCisg
Ki8KKwl0c3QJcjIsICMzMgorCXN0bW5laWEJcjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJc3Rt
bmVpYQlyMCEsIHtyMSwgcjMsIGlwLCBscn0KKwl0c3QJcjIsICMxNgorCXN0bW5laWEJcjAh
LCB7cjEsIHIzLCBpcCwgbHJ9CisJbGRyCWxyLCBbc3BdLCAjNAorCis0Ogl0c3QJcjIsICM4
CisJc3RtbmVpYQlyMCEsIHtyMSwgcjN9CisJdHN0CXIyLCAjNAorCXN0cm5lCXIxLCBbcjBd
LCAjNAorLyoKKyAqIFdoZW4gd2UgZ2V0IGhlcmUsIHdlJ3ZlIGdvdCBsZXNzIHRoYW4gNCBi
eXRlcyB0byB6ZXJvLiAgV2UKKyAqIG1heSBoYXZlIGFuIHVuYWxpZ25lZCBwb2ludGVyIGFz
IHdlbGwuCisgKi8KKzU6CXRzdAlyMiwgIzIKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJc3Ry
bmViCXIxLCBbcjBdLCAjMQorCXRzdAlyMiwgIzEKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJ
bW92CXBjLGxyCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9hc20t
bWFjcm9zLmg+CisKKwkudGV4dAorCS5hbGlnbgk1CisJLndvcmQJMAorLyoKKyAqIEFsaWdu
IHRoZSBwb2ludGVyIGluIHIwLiAgcjMgY29udGFpbnMgdGhlIG51bWJlciBvZiBieXRlcyB0
aGF0IHdlIGFyZQorICogbWlzLWFsaWduZWQgYnksIGFuZCByMSBpcyB0aGUgbnVtYmVyIG9m
IGJ5dGVzLiAgSWYgcjEgPCA0LCB0aGVuIHdlCisgKiBkb24ndCBib3RoZXI7IHdlIHVzZSBi
eXRlIHN0b3JlcyBpbnN0ZWFkLgorICovCisxOglzdWJzCXIxLCByMSwgIzQJCUAgMSBkbyB3
ZSBoYXZlIGVub3VnaAorCWJsdAk1ZgkJCUAgMSBieXRlcyB0byBhbGlnbiB3aXRoPworCWNt
cAlyMywgIzIJCQlAIDEKKwlzdHJsdGIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJsZWIJcjIs
IFtyMF0sICMxCQlAIDEKKwlzdHJiCXIyLCBbcjBdLCAjMQkJQCAxCisJYWRkCXIxLCByMSwg
cjMJCUAgMSAocjEgPSByMSAtICg0IC0gcjMpKQorLyoKKyAqIFRoZSBwb2ludGVyIGlzIG5v
dyBhbGlnbmVkIGFuZCB0aGUgbGVuZ3RoIGlzIGFkanVzdGVkLiAgVHJ5IGRvaW5nIHRoZQor
ICogbWVtemVybyBhZ2Fpbi4KKyAqLworCitFTlRSWShfX21lbXplcm8pCisJbW92CXIyLCAj
MAkJCUAgMQorCWFuZHMJcjMsIHIwLCAjMwkJQCAxIHVuYWxpZ25lZD8KKwlibmUJMWIJCQlA
IDEKKy8qCisgKiByMyA9IDAsIGFuZCB3ZSBrbm93IHRoYXQgdGhlIHBvaW50ZXIgaW4gcjAg
aXMgYWxpZ25lZCB0byBhIHdvcmQgYm91bmRhcnkuCisgKi8KKwljbXAJcjEsICMxNgkJCUAg
MSB3ZSBjYW4gc2tpcCB0aGlzIGNodW5rIGlmIHdlCisJYmx0CTRmCQkJQCAxIGhhdmUgPCAx
NiBieXRlcworLyoKKyAqIFdlIG5lZWQgYW4gZXh0cmEgcmVnaXN0ZXIgZm9yIHRoaXMgbG9v
cCAtIHNhdmUgdGhlIHJldHVybiBhZGRyZXNzIGFuZAorICogdXNlIHRoZSBMUgorICovCisJ
c3RyCWxyLCBbc3AsICMtNF0hCQlAIDEKKwltb3YJaXAsIHIyCQkJQCAxCisJbW92CWxyLCBy
MgkJCUAgMQorCiszOglzdWJzCXIxLCByMSwgIzY0CQlAIDEgd3JpdGUgMzIgYnl0ZXMgb3V0
IHBlciBsb29wCisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2Vp
YQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlw
LCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJYmd0CTNi
CQkJQCAxCisJbGRtZXFmZCBzcCEsIHtwY30JQCAxLzIgcXVpY2sgZXhpdAorLyoKKyAqIE5v
IG5lZWQgdG8gY29ycmVjdCB0aGUgY291bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZy
b20gbm93IG9uCisgKi8KKwl0c3QJcjEsICMzMgkJCUAgMQorCXN0bW5laWEJcjAhLCB7cjIs
IHIzLCBpcCwgbHJ9CUAgNAorCXN0bW5laWEJcjAhLCB7cjIsIHIzLCBpcCwgbHJ9CUAgNAor
CXRzdAlyMSwgIzE2CQkJQCAxIDE2IGJ5dGVzIG9yIG1vcmU/CisJc3RtbmVpYQlyMCEsIHty
MiwgcjMsIGlwLCBscn0JQCA0CisJbGRyCWxyLCBbc3BdLCAjNAkJQCAxCisKKzQ6CXRzdAly
MSwgIzgJCQlAIDEgOCBieXRlcyBvciBtb3JlPworCXN0bW5laWEJcjAhLCB7cjIsIHIzfQkJ
QCAyCisJdHN0CXIxLCAjNAkJCUAgMSA0IGJ5dGVzIG9yIG1vcmU/CisJc3RybmUJcjIsIFty
MF0sICM0CQlAIDEKKy8qCisgKiBXaGVuIHdlIGdldCBoZXJlLCB3ZSd2ZSBnb3QgbGVzcyB0
aGFuIDQgYnl0ZXMgdG8gemVyby4gIFdlCisgKiBtYXkgaGF2ZSBhbiB1bmFsaWduZWQgcG9p
bnRlciBhcyB3ZWxsLgorICovCis1Ogl0c3QJcjEsICMyCQkJQCAxIDIgYnl0ZXMgb3IgbW9y
ZT8KKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlA
IDEKKwl0c3QJcjEsICMxCQkJQCAxIGEgYnl0ZSBsZWZ0IG92ZXIKKwlzdHJuZWIJcjIsIFty
MF0sICMxCQlAIDEKKwltb3YJcGMsbHIJCUAgMQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0vbGliL21lbXNldC5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvbWVtc2V0LlMJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjkgQEAKKyNpbmNsdWRlIDx4ZW4v
Y29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworCS50ZXh0CisJLmFs
aWduCTUKKwkud29yZAkwCisKKzE6CXN1YnMJcjIsIHIyLCAjNAkJQCAxIGRvIHdlIGhhdmUg
ZW5vdWdoCisJYmx0CTVmCQkJQCAxIGJ5dGVzIHRvIGFsaWduIHdpdGg/CisJY21wCXIzLCAj
MgkJCUAgMQorCXN0cmx0YglyMSwgW3IwXSwgIzEJCUAgMQorCXN0cmxlYglyMSwgW3IwXSwg
IzEJCUAgMQorCXN0cmIJcjEsIFtyMF0sICMxCQlAIDEKKwlhZGQJcjIsIHIyLCByMwkJQCAx
IChyMiA9IHIyIC0gKDQgLSByMykpCisvKgorICogVGhlIHBvaW50ZXIgaXMgbm93IGFsaWdu
ZWQgYW5kIHRoZSBsZW5ndGggaXMgYWRqdXN0ZWQuICBUcnkgZG9pbmcgdGhlCisgKiBtZW16
ZXJvIGFnYWluLgorICovCisKK0VOVFJZKG1lbXNldCkKKwlhbmRzCXIzLCByMCwgIzMJCUAg
MSB1bmFsaWduZWQ/CisJYm5lCTFiCQkJQCAxCisvKgorICogd2Uga25vdyB0aGF0IHRoZSBw
b2ludGVyIGluIHIwIGlzIGFsaWduZWQgdG8gYSB3b3JkIGJvdW5kYXJ5LgorICovCisJb3Jy
CXIxLCByMSwgcjEsIGxzbCAjOAorCW9ycglyMSwgcjEsIHIxLCBsc2wgIzE2CisJbW92CXIz
LCByMQorCWNtcAlyMiwgIzE2CisJYmx0CTRmCisvKgorICogV2UgbmVlZCBhbiBleHRyYSBy
ZWdpc3RlciBmb3IgdGhpcyBsb29wIC0gc2F2ZSB0aGUgcmV0dXJuIGFkZHJlc3MgYW5kCisg
KiB1c2UgdGhlIExSCisgKi8KKwlzdHIJbHIsIFtzcCwgIy00XSEKKwltb3YJaXAsIHIxCisJ
bW92CWxyLCByMQorCisyOglzdWJzCXIyLCByMiwgIzY0CisJc3RtZ2VpYQlyMCEsIHtyMSwg
cjMsIGlwLCBscn0JQCA2NCBieXRlcyBhdCBhIHRpbWUuCisJc3RtZ2VpYQlyMCEsIHtyMSwg
cjMsIGlwLCBscn0KKwlzdG1nZWlhCXIwISwge3IxLCByMywgaXAsIGxyfQorCXN0bWdlaWEJ
cjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJYmd0CTJiCisJbGRtZXFmZCBzcCEsIHtwY30JQCBO
b3cgPDY0IGJ5dGVzIHRvIGdvLgorLyoKKyAqIE5vIG5lZWQgdG8gY29ycmVjdCB0aGUgY291
bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZyb20gbm93IG9uCisgKi8KKwl0c3QJcjIs
ICMzMgorCXN0bW5laWEJcjAhLCB7cjEsIHIzLCBpcCwgbHJ9CisJc3RtbmVpYQlyMCEsIHty
MSwgcjMsIGlwLCBscn0KKwl0c3QJcjIsICMxNgorCXN0bW5laWEJcjAhLCB7cjEsIHIzLCBp
cCwgbHJ9CisJbGRyCWxyLCBbc3BdLCAjNAorCis0Ogl0c3QJcjIsICM4CisJc3RtbmVpYQly
MCEsIHtyMSwgcjN9CisJdHN0CXIyLCAjNAorCXN0cm5lCXIxLCBbcjBdLCAjNAorLyoKKyAq
IFdoZW4gd2UgZ2V0IGhlcmUsIHdlJ3ZlIGdvdCBsZXNzIHRoYW4gNCBieXRlcyB0byB6ZXJv
LiAgV2UKKyAqIG1heSBoYXZlIGFuIHVuYWxpZ25lZCBwb2ludGVyIGFzIHdlbGwuCisgKi8K
KzU6CXRzdAlyMiwgIzIKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJc3RybmViCXIxLCBbcjBd
LCAjMQorCXRzdAlyMiwgIzEKKwlzdHJuZWIJcjEsIFtyMF0sICMxCisJbW92CXBjLGxyCmRp
ZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvbWVtemVyby5TCi0tLSAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2Fy
bS9saWIvbWVtemVyby5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCww
ICsxLDcxIEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9hc20t
bWFjcm9zLmg+CisKKwkudGV4dAorCS5hbGlnbgk1CisJLndvcmQJMAorLyoKKyAqIEFsaWdu
IHRoZSBwb2ludGVyIGluIHIwLiAgcjMgY29udGFpbnMgdGhlIG51bWJlciBvZiBieXRlcyB0
aGF0IHdlIGFyZQorICogbWlzLWFsaWduZWQgYnksIGFuZCByMSBpcyB0aGUgbnVtYmVyIG9m
IGJ5dGVzLiAgSWYgcjEgPCA0LCB0aGVuIHdlCisgKiBkb24ndCBib3RoZXI7IHdlIHVzZSBi
eXRlIHN0b3JlcyBpbnN0ZWFkLgorICovCisxOglzdWJzCXIxLCByMSwgIzQJCUAgMSBkbyB3
ZSBoYXZlIGVub3VnaAorCWJsdAk1ZgkJCUAgMSBieXRlcyB0byBhbGlnbiB3aXRoPworCWNt
cAlyMywgIzIJCQlAIDEKKwlzdHJsdGIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJsZWIJcjIs
IFtyMF0sICMxCQlAIDEKKwlzdHJiCXIyLCBbcjBdLCAjMQkJQCAxCisJYWRkCXIxLCByMSwg
cjMJCUAgMSAocjEgPSByMSAtICg0IC0gcjMpKQorLyoKKyAqIFRoZSBwb2ludGVyIGlzIG5v
dyBhbGlnbmVkIGFuZCB0aGUgbGVuZ3RoIGlzIGFkanVzdGVkLiAgVHJ5IGRvaW5nIHRoZQor
ICogbWVtemVybyBhZ2Fpbi4KKyAqLworCitFTlRSWShfX21lbXplcm8pCisJbW92CXIyLCAj
MAkJCUAgMQorCWFuZHMJcjMsIHIwLCAjMwkJQCAxIHVuYWxpZ25lZD8KKwlibmUJMWIJCQlA
IDEKKy8qCisgKiByMyA9IDAsIGFuZCB3ZSBrbm93IHRoYXQgdGhlIHBvaW50ZXIgaW4gcjAg
aXMgYWxpZ25lZCB0byBhIHdvcmQgYm91bmRhcnkuCisgKi8KKwljbXAJcjEsICMxNgkJCUAg
MSB3ZSBjYW4gc2tpcCB0aGlzIGNodW5rIGlmIHdlCisJYmx0CTRmCQkJQCAxIGhhdmUgPCAx
NiBieXRlcworLyoKKyAqIFdlIG5lZWQgYW4gZXh0cmEgcmVnaXN0ZXIgZm9yIHRoaXMgbG9v
cCAtIHNhdmUgdGhlIHJldHVybiBhZGRyZXNzIGFuZAorICogdXNlIHRoZSBMUgorICovCisJ
c3RyCWxyLCBbc3AsICMtNF0hCQlAIDEKKwltb3YJaXAsIHIyCQkJQCAxCisJbW92CWxyLCBy
MgkJCUAgMQorCiszOglzdWJzCXIxLCByMSwgIzY0CQlAIDEgd3JpdGUgMzIgYnl0ZXMgb3V0
IHBlciBsb29wCisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2Vp
YQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlw
LCBscn0JQCA0CisJc3RtZ2VpYQlyMCEsIHtyMiwgcjMsIGlwLCBscn0JQCA0CisJYmd0CTNi
CQkJQCAxCisJbGRtZXFmZCBzcCEsIHtwY30JQCAxLzIgcXVpY2sgZXhpdAorLyoKKyAqIE5v
IG5lZWQgdG8gY29ycmVjdCB0aGUgY291bnQ7IHdlJ3JlIG9ubHkgdGVzdGluZyBiaXRzIGZy
b20gbm93IG9uCisgKi8KKwl0c3QJcjEsICMzMgkJCUAgMQorCXN0bW5laWEJcjAhLCB7cjIs
IHIzLCBpcCwgbHJ9CUAgNAorCXN0bW5laWEJcjAhLCB7cjIsIHIzLCBpcCwgbHJ9CUAgNAor
CXRzdAlyMSwgIzE2CQkJQCAxIDE2IGJ5dGVzIG9yIG1vcmU/CisJc3RtbmVpYQlyMCEsIHty
MiwgcjMsIGlwLCBscn0JQCA0CisJbGRyCWxyLCBbc3BdLCAjNAkJQCAxCisKKzQ6CXRzdAly
MSwgIzgJCQlAIDEgOCBieXRlcyBvciBtb3JlPworCXN0bW5laWEJcjAhLCB7cjIsIHIzfQkJ
QCAyCisJdHN0CXIxLCAjNAkJCUAgMSA0IGJ5dGVzIG9yIG1vcmU/CisJc3RybmUJcjIsIFty
MF0sICM0CQlAIDEKKy8qCisgKiBXaGVuIHdlIGdldCBoZXJlLCB3ZSd2ZSBnb3QgbGVzcyB0
aGFuIDQgYnl0ZXMgdG8gemVyby4gIFdlCisgKiBtYXkgaGF2ZSBhbiB1bmFsaWduZWQgcG9p
bnRlciBhcyB3ZWxsLgorICovCis1Ogl0c3QJcjEsICMyCQkJQCAxIDIgYnl0ZXMgb3IgbW9y
ZT8KKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlAIDEKKwlzdHJuZWIJcjIsIFtyMF0sICMxCQlA
IDEKKwl0c3QJcjEsICMxCQkJQCAxIGEgYnl0ZSBsZWZ0IG92ZXIKKwlzdHJuZWIJcjIsIFty
MF0sICMxCQlAIDEKKwltb3YJcGMsbHIJCUAgMQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0vbGliL211bGRpMy5jCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS9saWIvbXVsZGkzLmMJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsODYgQEAKKy8qIE1vcmUgc3Vicm91
dGluZXMgbmVlZGVkIGJ5IEdDQyBvdXRwdXQgY29kZSBvbiBzb21lIG1hY2hpbmVzLiAgKi8K
Ky8qIENvbXBpbGUgdGhpcyBvbmUgd2l0aCBnY2MuICAqLworLyogQ29weXJpZ2h0IChDKSAx
OTg5LCA5Mi05OCwgMTk5OSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhp
cyBmaWxlIGlzIHBhcnQgb2YgR05VIENDLgorCitHTlUgQ0MgaXMgZnJlZSBzb2Z0d2FyZTsg
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQoraXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkK
K3RoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9yIChh
dCB5b3VyIG9wdGlvbikKK2FueSBsYXRlciB2ZXJzaW9uLgorCitHTlUgQ0MgaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKK2J1dCBXSVRIT1VU
IEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCitN
RVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlCitHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgor
CitZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQ
dWJsaWMgTGljZW5zZQorYWxvbmcgd2l0aCBHTlUgQ0M7IHNlZSB0aGUgZmlsZSBDT1BZSU5H
LiAgSWYgbm90LCB3cml0ZSB0bwordGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgNTkg
VGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLAorQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0Eu
ICAqLworCisvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCBpZiB5b3UgbGluayB0aGlzIGxp
YnJhcnkgd2l0aCBvdGhlciBmaWxlcywKKyAgIHNvbWUgb2Ygd2hpY2ggYXJlIGNvbXBpbGVk
IHdpdGggR0NDLCB0byBwcm9kdWNlIGFuIGV4ZWN1dGFibGUsCisgICB0aGlzIGxpYnJhcnkg
ZG9lcyBub3QgYnkgaXRzZWxmIGNhdXNlIHRoZSByZXN1bHRpbmcgZXhlY3V0YWJsZQorICAg
dG8gYmUgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UuCisgICBU
aGlzIGV4Y2VwdGlvbiBkb2VzIG5vdCBob3dldmVyIGludmFsaWRhdGUgYW55IG90aGVyIHJl
YXNvbnMgd2h5CisgICB0aGUgZXhlY3V0YWJsZSBmaWxlIG1pZ2h0IGJlIGNvdmVyZWQgYnkg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLgorICovCisvKiBzdXBwb3J0IGZ1bmN0
aW9ucyByZXF1aXJlZCBieSB0aGUga2VybmVsLiBiYXNlZCBvbiBjb2RlIGZyb20gZ2NjLTIu
OTUuMyAqLworLyogSSBNb2x0b24gICAgIDI5LzA3LzAxICovCisKKyNpbmNsdWRlICJnY2Ns
aWIuaCIKKworI2RlZmluZSB1bXVsX3BwbW0oeGgsIHhsLCBhLCBiKSBcCit7cmVnaXN0ZXIg
VVNJdHlwZSBfX3QwLCBfX3QxLCBfX3QyOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCisgIF9fYXNtX18gKCIlQCBJbmxpbmVkIHVtdWxfcHBtbQkJCQkJXG5cCisg
ICAgICAgIG1vdiAgICAgJTIsICU1LCBsc3IgIzE2CQkJCQkJXG5cCisgICAgICAgIG1vdiAg
ICAgJTAsICU2LCBsc3IgIzE2CQkJCQkJXG5cCisgICAgICAgIGJpYyAgICAgJTMsICU1LCAl
MiwgbHNsICMxNgkJCQkJXG5cCisgICAgICAgIGJpYyAgICAgJTQsICU2LCAlMCwgbHNsICMx
NgkJCQkJXG5cCisgICAgICAgIG11bCAgICAgJTEsICUzLCAlNAkJCQkJCVxuXAorICAgICAg
ICBtdWwgICAgICU0LCAlMiwgJTQJCQkJCQlcblwKKyAgICAgICAgbXVsICAgICAlMywgJTAs
ICUzCQkJCQkJXG5cCisgICAgICAgIG11bCAgICAgJTAsICUyLCAlMAkJCQkJCVxuXAorICAg
ICAgICBhZGRzICAgICUzLCAlNCwgJTMJCQkJCQlcblwKKyAgICAgICAgYWRkY3MgICAlMCwg
JTAsICM2NTUzNgkJCQkJCVxuXAorICAgICAgICBhZGRzICAgICUxLCAlMSwgJTMsIGxzbCAj
MTYJCQkJCVxuXAorICAgICAgICBhZGMgICAgICUwLCAlMCwgJTMsIGxzciAjMTYiICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICA6ICI9JnIiICgo
VVNJdHlwZSkgKHhoKSksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgICI9ciIgKChVU0l0eXBlKSAoeGwpKSwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICI9JnIiIChfX3QwKSwgIj0mciIg
KF9fdDEpLCAiPXIiIChfX3QyKSAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICA6
ICJyIiAoKFVTSXR5cGUpIChhKSksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXAorICAgICAgICAgICAgICJyIiAoKFVTSXR5cGUpIChiKSkpO30KKworCisjZGVm
aW5lIF9fdW11bHNpZGkzKHUsIHYpIFwKKyAgKHtESXVuaW9uIF9fdzsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB1bXVs
X3BwbW0gKF9fdy5zLmhpZ2gsIF9fdy5zLmxvdywgdSwgdik7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFwKKyAgICBfX3cubGw7IH0pCisKKworREl0eXBlCitfX211bGRpMyAoREl0
eXBlIHUsIERJdHlwZSB2KQoreworICBESXVuaW9uIHc7CisgIERJdW5pb24gdXUsIHZ2Owor
CisgIHV1LmxsID0gdSwKKyAgdnYubGwgPSB2OworCisgIHcubGwgPSBfX3VtdWxzaWRpMyAo
dXUucy5sb3csIHZ2LnMubG93KTsKKyAgdy5zLmhpZ2ggKz0gKChVU0l0eXBlKSB1dS5zLmxv
dyAqIChVU0l0eXBlKSB2di5zLmhpZ2gKKyAgICAgICAgICAgICAgICsgKFVTSXR5cGUpIHV1
LnMuaGlnaCAqIChVU0l0eXBlKSB2di5zLmxvdyk7CisKKyAgcmV0dXJuIHcubGw7Cit9CisK
KyNpZiAwCitsbGRpdl90X3JyIF9fYWVhYmlfbGRpdm1vZCAobG9uZyBsb25nIGEsIGxvbmcg
bG9uZyBiKSAKK3sgCisJbGxkaXZfdF9yciByOyAKKwlyLnF1b3QgPV9fZGl2ZGkzIChhLCBi
KTsgCisJci5yZW0gPSBhIC0gYiAqIHIucXVvdDsgCisJcmV0dXJuIHI7IAorfQorI2VuZGlm
CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9saWIvcHV0dXNlci5TCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNo
L2FybS9saWIvcHV0dXNlci5TCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAt
MCwwICsxLDc1IEBACisvKgorICogIGxpbnV4L2FyY2gvYXJtL2xpYi9wdXR1c2VyLlMKKyAq
CisgKiAgQ29weXJpZ2h0IChDKSAyMDAxIFJ1c3NlbGwgS2luZworICoKKyAqIFRoaXMgcHJv
Z3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIHZlcnNpb24gMiBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uCisgKgorICogIElkZWEgZnJvbSB4ODYgdmVyc2lvbiwgKEMpIENv
cHlyaWdodCAxOTk4IExpbnVzIFRvcnZhbGRzCisgKgorICogVGhlc2UgZnVuY3Rpb25zIGhh
dmUgYSBub24tc3RhbmRhcmQgY2FsbCBpbnRlcmZhY2UgdG8gbWFrZQorICogdGhlbSBtb3Jl
IGVmZmljaWVudCwgZXNwZWNpYWxseSBhcyB0aGV5IHJldHVybiBhbiBlcnJvcgorICogdmFs
dWUgaW4gYWRkaXRpb24gdG8gdGhlICJyZWFsIiByZXR1cm4gdmFsdWUuCisgKgorICogX19w
dXRfdXNlcl9YCisgKgorICogSW5wdXRzOglyMCBjb250YWlucyB0aGUgYWRkcmVzcworICoJ
CXIyLCByMyBjb250YWlucyB0aGUgdmFsdWUKKyAqIE91dHB1dHM6CXIwIGlzIHRoZSBlcnJv
ciBjb2RlCisgKgkJbHIgY29ycnVwdGVkCisgKgorICogTm8gb3RoZXIgcmVnaXN0ZXJzIG11
c3QgYmUgYWx0ZXJlZC4gIChzZWUgaW5jbHVkZS9hc20tYXJtL3VhY2Nlc3MuaAorICogZm9y
IHNwZWNpZmljIEFTTSByZWdpc3RlciB1c2FnZSkuCisgKgorICogTm90ZSB0aGF0IEFERFJf
TElNSVQgaXMgZWl0aGVyIDAgb3IgMHhjMDAwMDAwMAorICogTm90ZSBhbHNvIHRoYXQgaXQg
aXMgaW50ZW5kZWQgdGhhdCBfX3B1dF91c2VyX2JhZCBpcyBub3QgZ2xvYmFsLgorICovCisj
aW5jbHVkZSA8eGVuL2Vycm5vLmg+CisKKwkuZ2xvYmFsCV9fcHV0X3VzZXJfMQorX19wdXRf
dXNlcl8xOgorMToJc3RyYnQJcjIsIFtyMF0KKwltb3YJcjAsICMwCisJbW92CXBjLCBscgor
CisJLmdsb2JhbAlfX3B1dF91c2VyXzIKK19fcHV0X3VzZXJfMjoKKwltb3YJaXAsIHIyLCBs
c3IgIzgKKyNpZm5kZWYgX19BUk1FQl9fCisyOglzdHJidAlyMiwgW3IwXSwgIzEKKzM6CXN0
cmJ0CWlwLCBbcjBdCisjZWxzZQorMjoJc3RyYnQJaXAsIFtyMF0sICMxCiszOglzdHJidAly
MiwgW3IwXQorI2VuZGlmCisJbW92CXIwLCAjMAorCW1vdglwYywgbHIKKworCS5nbG9iYWwJ
X19wdXRfdXNlcl80CitfX3B1dF91c2VyXzQ6Cis0OglzdHJ0CXIyLCBbcjBdCisJbW92CXIw
LCAjMAorCW1vdglwYywgbHIKKworCS5nbG9iYWwJX19wdXRfdXNlcl84CitfX3B1dF91c2Vy
Xzg6Cis1OglzdHJ0CXIyLCBbcjBdLCAjNAorNjoJc3RydAlyMywgW3IwXQorCW1vdglyMCwg
IzAKKwltb3YJcGMsIGxyCisKKwkuZ2xvYmFsIF9fcHV0X3VzZXJfYmFkCitfX3B1dF91c2Vy
X2JhZDoKKwltb3YJcjAsICMtRUZBVUxUCisJbW92CXBjLCBscgorCisuc2VjdGlvbiAuZXh0
YWJsZSwgImEiCisJLmxvbmcJMWIsIF9fcHV0X3VzZXJfYmFkCisJLmxvbmcJMmIsIF9fcHV0
X3VzZXJfYmFkCisJLmxvbmcJM2IsIF9fcHV0X3VzZXJfYmFkCisJLmxvbmcJNGIsIF9fcHV0
X3VzZXJfYmFkCisJLmxvbmcJNWIsIF9fcHV0X3VzZXJfYmFkCisJLmxvbmcJNmIsIF9fcHV0
X3VzZXJfYmFkCisucHJldmlvdXMKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJt
L2xpYi9zZXRiaXQuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL3NldGJpdC5TCUZyaSBGZWIgMDMgMTY6MDc6
MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDIyIEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5o
PgorI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jv
cy5oPgorCisJCS50ZXh0CisKKy8qCisgKiBQdXJwb3NlICA6IEZ1bmN0aW9uIHRvIHNldCBh
IGJpdAorICogUHJvdG90eXBlOiBpbnQgc2V0X2JpdChpbnQgYml0LCB2b2lkICphZGRyKQor
ICovCitFTlRSWShfc2V0X2JpdF9iZSkKKwllb3IJcjAsIHIwLCAjMHgxOAkJQCBiaWcgZW5k
aWFuIGJ5dGUgb3JkZXJpbmcKK0VOVFJZKF9zZXRfYml0X2xlKQorCWFuZAlyMiwgcjAsICM3
CisJbW92CXIzLCAjMQorCW1vdglyMywgcjMsIGxzbCByMgorCXNhdmVfYW5kX2Rpc2FibGVf
aXJxcyBpcCwgcjIKKwlsZHJiCXIyLCBbcjEsIHIwLCBsc3IgIzNdCisJb3JyCXIyLCByMiwg
cjMKKwlzdHJiCXIyLCBbcjEsIHIwLCBsc3IgIzNdCisJcmVzdG9yZV9pcnFzIGlwCisJbW92
CXBjLCBscgpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL3N0cmNoci5T
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hl
bi9hcmNoL2FybS9saWIvc3RyY2hyLlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAw
CkBAIC0wLDAgKzEsMTUgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8
YXNtL2FzbS1tYWNyb3MuaD4KKworCQkudGV4dAorCQkuYWxpZ24JNQorRU5UUlkoc3RyY2hy
KQorCQlhbmQJcjEsIHIxLCAjMHhmZgorMToJCWxkcmIJcjIsIFtyMF0sICMxCisJCXRlcQly
MiwgcjEKKwkJdGVxbmUJcjIsICMwCisJCWJuZQkxYgorCQl0ZXEJcjIsIHIxCisJCW1vdm5l
CXIwLCAjMAorCQlzdWJlcQlyMCwgcjAsICMxCisJCW1vdglwYyxscgpkaWZmIC1yIGU3MDE0
NjFiMTI1MSB4ZW4vYXJjaC9hcm0vbGliL3Rlc3RjaGFuZ2ViaXQuUwotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGli
L3Rlc3RjaGFuZ2ViaXQuUwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAs
MCArMSwyMiBAQAorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vcHJv
Y2Vzc29yLmg+CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworICAgICAgICAgICAg
ICAgIC50ZXh0CisKK0VOVFJZKF90ZXN0X2FuZF9jaGFuZ2VfYml0X2JlKQorCQllb3IJcjAs
IHIwLCAjMHgxOAkJQCBiaWcgZW5kaWFuIGJ5dGUgb3JkZXJpbmcKK0VOVFJZKF90ZXN0X2Fu
ZF9jaGFuZ2VfYml0X2xlKQorCQlhZGQJcjEsIHIxLCByMCwgbHNyICMzCisJCWFuZAlyMywg
cjAsICM3CisJCW1vdglyMCwgIzEKKwkJc2F2ZV9hbmRfZGlzYWJsZV9pcnFzIGlwLCByMgor
CQlsZHJiCXIyLCBbcjFdCisJCXRzdAlyMiwgcjAsIGxzbCByMworCQllb3IJcjIsIHIyLCBy
MCwgbHNsIHIzCisJCXN0cmIJcjIsIFtyMV0KKwkJcmVzdG9yZV9pcnFzIGlwCisJCW1vdmVx
CXIwLCAjMAorCQltb3YJcGMsbHIKKworCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNo
L2FybS9saWIvdGVzdGNsZWFyYml0LlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi90ZXN0Y2xlYXJiaXQuUwlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyMiBAQAorI2luY2x1
ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vcHJvY2Vzc29yLmg+CisjaW5jbHVk
ZSA8YXNtL2FzbS1tYWNyb3MuaD4KKworICAgICAgICAgICAgICAgIC50ZXh0CisKK0VOVFJZ
KF90ZXN0X2FuZF9jbGVhcl9iaXRfYmUpCisJCWVvcglyMCwgcjAsICMweDE4CQlAIGJpZyBl
bmRpYW4gYnl0ZSBvcmRlcmluZworRU5UUlkoX3Rlc3RfYW5kX2NsZWFyX2JpdF9sZSkKKwkJ
YWRkCXIxLCByMSwgcjAsIGxzciAjMwlAIEdldCBieXRlIG9mZnNldAorCQlhbmQJcjMsIHIw
LCAjNwkJQCBHZXQgYml0IG9mZnNldAorCQltb3YJcjAsICMxCisJCXNhdmVfYW5kX2Rpc2Fi
bGVfaXJxcyBpcCwgcjIKKwkJbGRyYglyMiwgW3IxXQorCQl0c3QJcjIsIHIwLCBsc2wgcjMK
KwkJYmljbmUJcjIsIHIyLCByMCwgbHNsIHIzCisJCXN0cm5lYglyMiwgW3IxXQorCQlyZXN0
b3JlX2lycXMgaXAKKwkJbW92ZXEJcjAsICMwCisJCW1vdglwYyxscgorCisKZGlmZiAtciBl
NzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL2xpYi90ZXN0c2V0Yml0LlMKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xp
Yi90ZXN0c2V0Yml0LlMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAg
KzEsMjAgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL3Byb2Nl
c3Nvci5oPgorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+CisKKyAgICAgICAgICAgICAg
ICAudGV4dAorCitFTlRSWShfdGVzdF9hbmRfc2V0X2JpdF9sZSkKKwkJYWRkCXIxLCByMSwg
cjAsIGxzciAjMwlAIEdldCBieXRlIG9mZnNldAorCQlhbmQJcjMsIHIwLCAjNwkJQCBHZXQg
Yml0IG9mZnNldAorCQltb3YJcjAsICMxCisJCXNhdmVfYW5kX2Rpc2FibGVfaXJxcyBpcCwg
cjIKKwkJbGRyYglyMiwgW3IxXQorCQl0c3QJcjIsIHIwLCBsc2wgcjMKKwkJb3JyZXEJcjIs
IHIyLCByMCwgbHNsIHIzCisJCXN0cmVxYglyMiwgW3IxXQorCQlyZXN0b3JlX2lycXMgaXAK
KwkJbW92ZXEJcjAsICMwCisJCW1vdglwYyxscgorCisKZGlmZiAtciBlNzAxNDYxYjEyNTEg
eGVuL2FyY2gvYXJtL2xpYi91YWNjZXNzLlMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL2xpYi91YWNjZXNzLlMJRnJp
IEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjg0IEBACisjaW5jbHVk
ZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPGFz
bS9hc20tbWFjcm9zLmg+CisKKwkJLnRleHQKKworI2RlZmluZSBQQUdFX1NISUZUIDEyCisK
Ky8qIFByb3RvdHlwZTogaW50IF9fYXJjaF9jb3B5X3RvX3VzZXIodm9pZCAqdG8sIGNvbnN0
IGNoYXIgKmZyb20sIHNpemVfdCBuKQorICogUHVycG9zZSAgOiBjb3B5IGEgYmxvY2sgdG8g
dXNlciBtZW1vcnkgZnJvbSBrZXJuZWwgbWVtb3J5CisgKiBQYXJhbXMgICA6IHRvICAgLSB1
c2VyIG1lbW9yeQorICogICAgICAgICAgOiBmcm9tIC0ga2VybmVsIG1lbW9yeQorICogICAg
ICAgICAgOiBuICAgIC0gbnVtYmVyIG9mIGJ5dGVzIHRvIGNvcHkKKyAqIFJldHVybnMgIDog
TnVtYmVyIG9mIGJ5dGVzIE5PVCBjb3BpZWQuCisgKi8KKworLmMydV9kZXN0X25vdF9hbGln
bmVkOgorCQlyc2IJaXAsIGlwLCAjNAorCQljbXAJaXAsICMyCisJCWxkcmIJcjMsIFtyMV0s
ICMxCitVU0VSKAkJc3RyYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCWxkcmdl
YglyMywgW3IxXSwgIzEKK1VTRVIoCQlzdHJnZWJ0CXIzLCBbcjBdLCAjMSkJCQlAIE1heSBm
YXVsdAorCQlsZHJndGIJcjMsIFtyMV0sICMxCitVU0VSKAkJc3RyZ3RidAlyMywgW3IwXSwg
IzEpCQkJQCBNYXkgZmF1bHQKKwkJc3ViCXIyLCByMiwgaXAKKwkJYgkuYzJ1X2Rlc3RfYWxp
Z25lZAorCitFTlRSWShfX2FyY2hfY29weV90b191c2VyKQorCQlzdG1mZAlzcCEsIHtyMiwg
cjQgLSByNywgbHJ9CisJCWNtcAlyMiwgIzQKKwkJYmx0CS5jMnVfbm90X2Vub3VnaAorCVBM
RCgJcGxkCVtyMSwgIzBdCQkpCisJUExEKAlwbGQJW3IwLCAjMF0JCSkKKwkJYW5kcwlpcCwg
cjAsICMzCisJCWJuZQkuYzJ1X2Rlc3Rfbm90X2FsaWduZWQKKy5jMnVfZGVzdF9hbGlnbmVk
OgorCisJCWFuZHMJaXAsIHIxLCAjMworCQlibmUJLmMydV9zcmNfbm90X2FsaWduZWQKKy8q
CisgKiBTZWVpbmcgYXMgdGhlcmUgaGFzIHRvIGJlIGF0IGxlYXN0IDggYnl0ZXMgdG8gY29w
eSwgd2UgY2FuCisgKiBjb3B5IG9uZSB3b3JkLCBhbmQgZm9yY2UgYSB1c2VyLW1vZGUgcGFn
ZSBmYXVsdC4uLgorICovCisKKy5jMnVfMGZ1cGk6CXN1YnMJcjIsIHIyLCAjNAorCQlhZGRt
aQlpcCwgcjIsICM0CisJCWJtaQkuYzJ1XzBub3dvcmRzCisJCWxkcglyMywgW3IxXSwgIzQK
K1VTRVIoCQlzdHJ0CXIzLCBbcjBdLCAjNCkJCQlAIE1heSBmYXVsdAorCQltb3YJaXAsIHIw
LCBsc2wgIzMyIC0gUEFHRV9TSElGVAlAIE9uIGVhY2ggcGFnZSwgdXNlIGEgbGQvc3Q/P3Qg
aW5zdHJ1Y3Rpb24KKwkJcnNiCWlwLCBpcCwgIzAKKwkJbW92cwlpcCwgaXAsIGxzciAjMzIg
LSBQQUdFX1NISUZUCisJCWJlcQkuYzJ1XzBmdXBpCisvKgorICogaXAgPSBtYXggbm8uIG9m
IGJ5dGVzIHRvIGNvcHkgYmVmb3JlIG5lZWRpbmcgYW5vdGhlciAic3RydCIgaW5zbgorICov
CisJCWNtcAlyMiwgaXAKKwkJbW92bHQJaXAsIHIyCisJCXN1YglyMiwgcjIsIGlwCisJCXN1
YnMJaXAsIGlwLCAjMzIKKwkJYmx0CS5jMnVfMHJlbThscAorCVBMRCgJcGxkCVtyMSwgIzI4
XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCVBMRCgJc3VicwlpcCwgaXAsICM2NAkJ
CSkKKwlQTEQoCWJsdAkuYzJ1XzBjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzYwXQkJ
KQorCVBMRCgJcGxkCVtyMCwgIzYwXQkJKQorCisuYzJ1XzBjcHk4bHA6CisJUExEKAlwbGQJ
W3IxLCAjOTJdCQkpCisJUExEKAlwbGQJW3IwLCAjOTJdCQkpCisuYzJ1XzBjcHlub3BsZDoJ
bGRtaWEJcjEhLCB7cjMgLSByNn0KKwkJc3RtaWEJcjAhLCB7cjMgLSByNn0JCQlAIFNob3Vs
ZG50IGZhdWx0CisJCWxkbWlhCXIxISwge3IzIC0gcjZ9CisJCXN1YnMJaXAsIGlwLCAjMzIK
KwkJc3RtaWEJcjAhLCB7cjMgLSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJCWJwbAkuYzJ1
XzBjcHk4bHAKKwlQTEQoCWNtbglpcCwgIzY0CQkJKQorCVBMRCgJYmdlCS5jMnVfMGNweW5v
cGxkCQkpCisJUExEKAlhZGQJaXAsIGlwLCAjNjQJCSkKKworLmMydV8wcmVtOGxwOgljbW4J
aXAsICMxNgorCQlsZG1nZWlhCXIxISwge3IzIC0gcjZ9CisJCXN0bWdlaWEJcjAhLCB7cjMg
LSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJCXRzdAlpcCwgIzgKKwkJbGRtbmVpYQlyMSEs
IHtyMyAtIHI0fQorCQlzdG1uZWlhCXIwISwge3IzIC0gcjR9CQkJQCBTaG91bGRudCBmYXVs
dAorCQl0c3QJaXAsICM0CisJCWxkcm5lCXIzLCBbcjFdLCAjNAorCQlzdHJuZXQJcjMsIFty
MF0sICM0CQkJQCBTaG91bGRudCBmYXVsdAorCQlhbmRzCWlwLCBpcCwgIzMKKwkJYmVxCS5j
MnVfMGZ1cGkKKy5jMnVfMG5vd29yZHM6CXRlcQlpcCwgIzAKKwkJYmVxCS5jMnVfZmluaXNo
ZWQKKy5jMnVfbm93b3JkczoJY21wCWlwLCAjMgorCQlsZHJiCXIzLCBbcjFdLCAjMQorVVNF
UigJCXN0cmJ0CXIzLCBbcjBdLCAjMSkJCQlAIE1heSBmYXVsdAorCQlsZHJnZWIJcjMsIFty
MV0sICMxCitVU0VSKAkJc3RyZ2VidAlyMywgW3IwXSwgIzEpCQkJQCBNYXkgZmF1bHQKKwkJ
bGRyZ3RiCXIzLCBbcjFdLCAjMQorVVNFUigJCXN0cmd0YnQJcjMsIFtyMF0sICMxKQkJCUAg
TWF5IGZhdWx0CisJCWIJLmMydV9maW5pc2hlZAorCisuYzJ1X25vdF9lbm91Z2g6CisJCW1v
dnMJaXAsIHIyCisJCWJuZQkuYzJ1X25vd29yZHMKKy5jMnVfZmluaXNoZWQ6CW1vdglyMCwg
IzAKKwkJbGRtZmQJc3AhLHtyMiwgcjQgLSByNywgcGN9CisKKy5jMnVfc3JjX25vdF9hbGln
bmVkOgorCQliaWMJcjEsIHIxLCAjMworCQlsZHIJcjcsIFtyMV0sICM0CisJCWNtcAlpcCwg
IzIKKwkJYmd0CS5jMnVfM2Z1cGkKKwkJYmVxCS5jMnVfMmZ1cGkKKy5jMnVfMWZ1cGk6CXN1
YnMJcjIsIHIyLCAjNAorCQlhZGRtaQlpcCwgcjIsICM0CisJCWJtaQkuYzJ1XzFub3dvcmRz
CisJCW1vdglyMywgcjcsIHB1bGwgIzgKKwkJbGRyCXI3LCBbcjFdLCAjNAorCQlvcnIJcjMs
IHIzLCByNywgcHVzaCAjMjQKK1VTRVIoCQlzdHJ0CXIzLCBbcjBdLCAjNCkJCQlAIE1heSBm
YXVsdAorCQltb3YJaXAsIHIwLCBsc2wgIzMyIC0gUEFHRV9TSElGVAorCQlyc2IJaXAsIGlw
LCAjMAorCQltb3ZzCWlwLCBpcCwgbHNyICMzMiAtIFBBR0VfU0hJRlQKKwkJYmVxCS5jMnVf
MWZ1cGkKKwkJY21wCXIyLCBpcAorCQltb3ZsdAlpcCwgcjIKKwkJc3ViCXIyLCByMiwgaXAK
KwkJc3VicwlpcCwgaXAsICMxNgorCQlibHQJLmMydV8xcmVtOGxwCisJUExEKAlwbGQJW3Ix
LCAjMTJdCQkpCisJUExEKAlwbGQJW3IwLCAjMTJdCQkpCisJUExEKAlzdWJzCWlwLCBpcCwg
IzMyCQkpCisJUExEKAlibHQJLmMydV8xY3B5bm9wbGQJCSkKKwlQTEQoCXBsZAlbcjEsICMy
OF0JCSkKKwlQTEQoCXBsZAlbcjAsICMyOF0JCSkKKworLmMydV8xY3B5OGxwOgorCVBMRCgJ
cGxkCVtyMSwgIzQ0XQkJKQorCVBMRCgJcGxkCVtyMCwgIzQ0XQkJKQorLmMydV8xY3B5bm9w
bGQ6CW1vdglyMywgcjcsIHB1bGwgIzgKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30KKwkJc3Vi
cwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjMjQKKwkJbW92CXI0LCBy
NCwgcHVsbCAjOAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjMjQKKwkJbW92CXI1LCByNSwg
cHVsbCAjOAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjMjQKKwkJbW92CXI2LCByNiwgcHVs
bCAjOAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjMjQKKwkJc3RtaWEJcjAhLCB7cjMgLSBy
Nn0JCQlAIFNob3VsZG50IGZhdWx0CisJCWJwbAkuYzJ1XzFjcHk4bHAKKwlQTEQoCWNtbglp
cCwgIzMyCQkJKQorCVBMRCgJYmdlCS5jMnVfMWNweW5vcGxkCQkpCisJUExEKAlhZGQJaXAs
IGlwLCAjMzIJCSkKKworLmMydV8xcmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIzLCBy
NywgcHVsbCAjOAorCQlsZG1uZWlhCXIxISwge3I0LCByN30KKwkJb3JybmUJcjMsIHIzLCBy
NCwgcHVzaCAjMjQKKwkJbW92bmUJcjQsIHI0LCBwdWxsICM4CisJCW9ycm5lCXI0LCByNCwg
cjcsIHB1c2ggIzI0CisJCXN0bW5laWEJcjAhLCB7cjMgLSByNH0JCQlAIFNob3VsZG50IGZh
dWx0CisJCXRzdAlpcCwgIzQKKwkJbW92bmUJcjMsIHI3LCBwdWxsICM4CisJCWxkcm5lCXI3
LCBbcjFdLCAjNAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICMyNAorCQlzdHJuZXQJcjMs
IFtyMF0sICM0CQkJQCBTaG91bGRudCBmYXVsdAorCQlhbmRzCWlwLCBpcCwgIzMKKwkJYmVx
CS5jMnVfMWZ1cGkKKy5jMnVfMW5vd29yZHM6CW1vdglyMywgcjcsIGdldF9ieXRlXzEKKwkJ
dGVxCWlwLCAjMAorCQliZXEJLmMydV9maW5pc2hlZAorCQljbXAJaXAsICMyCitVU0VSKAkJ
c3RyYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCW1vdmdlCXIzLCByNywgZ2V0
X2J5dGVfMgorVVNFUigJCXN0cmdlYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJ
CW1vdmd0CXIzLCByNywgZ2V0X2J5dGVfMworVVNFUigJCXN0cmd0YnQJcjMsIFtyMF0sICMx
KQkJCUAgTWF5IGZhdWx0CisJCWIJLmMydV9maW5pc2hlZAorCisuYzJ1XzJmdXBpOglzdWJz
CXIyLCByMiwgIzQKKwkJYWRkbWkJaXAsIHIyLCAjNAorCQlibWkJLmMydV8ybm93b3Jkcwor
CQltb3YJcjMsIHI3LCBwdWxsICMxNgorCQlsZHIJcjcsIFtyMV0sICM0CisJCW9ycglyMywg
cjMsIHI3LCBwdXNoICMxNgorVVNFUigJCXN0cnQJcjMsIFtyMF0sICM0KQkJCUAgTWF5IGZh
dWx0CisJCW1vdglpcCwgcjAsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAs
ICMwCisJCW1vdnMJaXAsIGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmMydV8y
ZnVwaQorCQljbXAJcjIsIGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAor
CQlzdWJzCWlwLCBpcCwgIzE2CisJCWJsdAkuYzJ1XzJyZW04bHAKKwlQTEQoCXBsZAlbcjEs
ICMxMl0JCSkKKwlQTEQoCXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAj
MzIJCSkKKwlQTEQoCWJsdAkuYzJ1XzJjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4
XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCisuYzJ1XzJjcHk4bHA6CisJUExEKAlw
bGQJW3IxLCAjNDRdCQkpCisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuYzJ1XzJjcHlub3Bs
ZDoJbW92CXIzLCByNywgcHVsbCAjMTYKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30KKwkJc3Vi
cwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjMTYKKwkJbW92CXI0LCBy
NCwgcHVsbCAjMTYKKwkJb3JyCXI0LCByNCwgcjUsIHB1c2ggIzE2CisJCW1vdglyNSwgcjUs
IHB1bGwgIzE2CisJCW9ycglyNSwgcjUsIHI2LCBwdXNoICMxNgorCQltb3YJcjYsIHI2LCBw
dWxsICMxNgorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjMTYKKwkJc3RtaWEJcjAhLCB7cjMg
LSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJCWJwbAkuYzJ1XzJjcHk4bHAKKwlQTEQoCWNt
bglpcCwgIzMyCQkJKQorCVBMRCgJYmdlCS5jMnVfMmNweW5vcGxkCQkpCisJUExEKAlhZGQJ
aXAsIGlwLCAjMzIJCSkKKworLmMydV8ycmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIz
LCByNywgcHVsbCAjMTYKKwkJbGRtbmVpYQlyMSEsIHtyNCwgcjd9CisJCW9ycm5lCXIzLCBy
MywgcjQsIHB1c2ggIzE2CisJCW1vdm5lCXI0LCByNCwgcHVsbCAjMTYKKwkJb3JybmUJcjQs
IHI0LCByNywgcHVzaCAjMTYKKwkJc3RtbmVpYQlyMCEsIHtyMyAtIHI0fQkJCUAgU2hvdWxk
bnQgZmF1bHQKKwkJdHN0CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzE2CisJCWxk
cm5lCXI3LCBbcjFdLCAjNAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICMxNgorCQlzdHJu
ZXQJcjMsIFtyMF0sICM0CQkJQCBTaG91bGRudCBmYXVsdAorCQlhbmRzCWlwLCBpcCwgIzMK
KwkJYmVxCS5jMnVfMmZ1cGkKKy5jMnVfMm5vd29yZHM6CW1vdglyMywgcjcsIGdldF9ieXRl
XzIKKwkJdGVxCWlwLCAjMAorCQliZXEJLmMydV9maW5pc2hlZAorCQljbXAJaXAsICMyCitV
U0VSKAkJc3RyYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCW1vdmdlCXIzLCBy
NywgZ2V0X2J5dGVfMworVVNFUigJCXN0cmdlYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZh
dWx0CisJCWxkcmd0YglyMywgW3IxXSwgIzAKK1VTRVIoCQlzdHJndGJ0CXIzLCBbcjBdLCAj
MSkJCQlAIE1heSBmYXVsdAorCQliCS5jMnVfZmluaXNoZWQKKworLmMydV8zZnVwaToJc3Vi
cwlyMiwgcjIsICM0CisJCWFkZG1pCWlwLCByMiwgIzQKKwkJYm1pCS5jMnVfM25vd29yZHMK
KwkJbW92CXIzLCByNywgcHVsbCAjMjQKKwkJbGRyCXI3LCBbcjFdLCAjNAorCQlvcnIJcjMs
IHIzLCByNywgcHVzaCAjOAorVVNFUigJCXN0cnQJcjMsIFtyMF0sICM0KQkJCUAgTWF5IGZh
dWx0CisJCW1vdglpcCwgcjAsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAs
ICMwCisJCW1vdnMJaXAsIGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmMydV8z
ZnVwaQorCQljbXAJcjIsIGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAor
CQlzdWJzCWlwLCBpcCwgIzE2CisJCWJsdAkuYzJ1XzNyZW04bHAKKwlQTEQoCXBsZAlbcjEs
ICMxMl0JCSkKKwlQTEQoCXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAj
MzIJCSkKKwlQTEQoCWJsdAkuYzJ1XzNjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4
XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCisuYzJ1XzNjcHk4bHA6CisJUExEKAlw
bGQJW3IxLCAjNDRdCQkpCisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuYzJ1XzNjcHlub3Bs
ZDoJbW92CXIzLCByNywgcHVsbCAjMjQKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30KKwkJc3Vi
cwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjOAorCQltb3YJcjQsIHI0
LCBwdWxsICMyNAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjOAorCQltb3YJcjUsIHI1LCBw
dWxsICMyNAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjOAorCQltb3YJcjYsIHI2LCBwdWxs
ICMyNAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjOAorCQlzdG1pYQlyMCEsIHtyMyAtIHI2
fQkJCUAgU2hvdWxkbnQgZmF1bHQKKwkJYnBsCS5jMnVfM2NweThscAorCVBMRCgJY21uCWlw
LCAjMzIJCQkpCisJUExEKAliZ2UJLmMydV8zY3B5bm9wbGQJCSkKKwlQTEQoCWFkZAlpcCwg
aXAsICMzMgkJKQorCisuYzJ1XzNyZW04bHA6CXRzdAlpcCwgIzgKKwkJbW92bmUJcjMsIHI3
LCBwdWxsICMyNAorCQlsZG1uZWlhCXIxISwge3I0LCByN30KKwkJb3JybmUJcjMsIHIzLCBy
NCwgcHVzaCAjOAorCQltb3ZuZQlyNCwgcjQsIHB1bGwgIzI0CisJCW9ycm5lCXI0LCByNCwg
cjcsIHB1c2ggIzgKKwkJc3RtbmVpYQlyMCEsIHtyMyAtIHI0fQkJCUAgU2hvdWxkbnQgZmF1
bHQKKwkJdHN0CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzI0CisJCWxkcm5lCXI3
LCBbcjFdLCAjNAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICM4CisJCXN0cm5ldAlyMywg
W3IwXSwgIzQJCQlAIFNob3VsZG50IGZhdWx0CisJCWFuZHMJaXAsIGlwLCAjMworCQliZXEJ
LmMydV8zZnVwaQorLmMydV8zbm93b3JkczoJbW92CXIzLCByNywgZ2V0X2J5dGVfMworCQl0
ZXEJaXAsICMwCisJCWJlcQkuYzJ1X2ZpbmlzaGVkCisJCWNtcAlpcCwgIzIKK1VTRVIoCQlz
dHJidAlyMywgW3IwXSwgIzEpCQkJQCBNYXkgZmF1bHQKKwkJbGRyZ2ViCXIzLCBbcjFdLCAj
MQorVVNFUigJCXN0cmdlYnQJcjMsIFtyMF0sICMxKQkJCUAgTWF5IGZhdWx0CisJCWxkcmd0
YglyMywgW3IxXSwgIzAKK1VTRVIoCQlzdHJndGJ0CXIzLCBbcjBdLCAjMSkJCQlAIE1heSBm
YXVsdAorCQliCS5jMnVfZmluaXNoZWQKKworCQkuc2VjdGlvbiAuZml4dXAsImF4IgorCQku
YWxpZ24JMAorOTAwMToJCWxkbWZkCXNwISwge3IwLCByNCAtIHI3LCBwY30KKwkJLnByZXZp
b3VzCisKKy8qIFByb3RvdHlwZTogdW5zaWduZWQgbG9uZyBfX2FyY2hfY29weV9mcm9tX3Vz
ZXIodm9pZCAqdG8sY29uc3Qgdm9pZCAqZnJvbSx1bnNpZ25lZCBsb25nIG4pOworICogUHVy
cG9zZSAgOiBjb3B5IGEgYmxvY2sgZnJvbSB1c2VyIG1lbW9yeSB0byBrZXJuZWwgbWVtb3J5
CisgKiBQYXJhbXMgICA6IHRvICAgLSBrZXJuZWwgbWVtb3J5CisgKiAgICAgICAgICA6IGZy
b20gLSB1c2VyIG1lbW9yeQorICogICAgICAgICAgOiBuICAgIC0gbnVtYmVyIG9mIGJ5dGVz
IHRvIGNvcHkKKyAqIFJldHVybnMgIDogTnVtYmVyIG9mIGJ5dGVzIE5PVCBjb3BpZWQuCisg
Ki8KKy5jZnVfZGVzdF9ub3RfYWxpZ25lZDoKKwkJcnNiCWlwLCBpcCwgIzQKKwkJY21wCWlw
LCAjMgorVVNFUigJCWxkcmJ0CXIzLCBbcjFdLCAjMSkJCQlAIE1heSBmYXVsdAorCQlzdHJi
CXIzLCBbcjBdLCAjMQorVVNFUigJCWxkcmdlYnQJcjMsIFtyMV0sICMxKQkJCUAgTWF5IGZh
dWx0CisJCXN0cmdlYglyMywgW3IwXSwgIzEKK1VTRVIoCQlsZHJndGJ0CXIzLCBbcjFdLCAj
MSkJCQlAIE1heSBmYXVsdAorCQlzdHJndGIJcjMsIFtyMF0sICMxCisJCXN1YglyMiwgcjIs
IGlwCisJCWIJLmNmdV9kZXN0X2FsaWduZWQKKworRU5UUlkoX19hcmNoX2NvcHlfZnJvbV91
c2VyKQorCQlzdG1mZAlzcCEsIHtyMCwgcjIsIHI0IC0gcjcsIGxyfQorCQljbXAJcjIsICM0
CisJCWJsdAkuY2Z1X25vdF9lbm91Z2gKKwlQTEQoCXBsZAlbcjEsICMwXQkJKQorCVBMRCgJ
cGxkCVtyMCwgIzBdCQkpCisJCWFuZHMJaXAsIHIwLCAjMworCQlibmUJLmNmdV9kZXN0X25v
dF9hbGlnbmVkCisuY2Z1X2Rlc3RfYWxpZ25lZDoKKwkJYW5kcwlpcCwgcjEsICMzCisJCWJu
ZQkuY2Z1X3NyY19ub3RfYWxpZ25lZAorLyoKKyAqIFNlZWluZyBhcyB0aGVyZSBoYXMgdG8g
YmUgYXQgbGVhc3QgOCBieXRlcyB0byBjb3B5LCB3ZSBjYW4KKyAqIGNvcHkgb25lIHdvcmQs
IGFuZCBmb3JjZSBhIHVzZXItbW9kZSBwYWdlIGZhdWx0Li4uCisgKi8KKworLmNmdV8wZnVw
aToJc3VicwlyMiwgcjIsICM0CisJCWFkZG1pCWlwLCByMiwgIzQKKwkJYm1pCS5jZnVfMG5v
d29yZHMKK1VTRVIoCQlsZHJ0CXIzLCBbcjFdLCAjNCkKKwkJc3RyCXIzLCBbcjBdLCAjNAor
CQltb3YJaXAsIHIxLCBsc2wgIzMyIC0gUEFHRV9TSElGVAlAIE9uIGVhY2ggcGFnZSwgdXNl
IGEgbGQvc3Q/P3QgaW5zdHJ1Y3Rpb24KKwkJcnNiCWlwLCBpcCwgIzAKKwkJbW92cwlpcCwg
aXAsIGxzciAjMzIgLSBQQUdFX1NISUZUCisJCWJlcQkuY2Z1XzBmdXBpCisvKgorICogaXAg
PSBtYXggbm8uIG9mIGJ5dGVzIHRvIGNvcHkgYmVmb3JlIG5lZWRpbmcgYW5vdGhlciAic3Ry
dCIgaW5zbgorICovCisJCWNtcAlyMiwgaXAKKwkJbW92bHQJaXAsIHIyCisJCXN1YglyMiwg
cjIsIGlwCisJCXN1YnMJaXAsIGlwLCAjMzIKKwkJYmx0CS5jZnVfMHJlbThscAorCVBMRCgJ
cGxkCVtyMSwgIzI4XQkJKQorCVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCVBMRCgJc3Vicwlp
cCwgaXAsICM2NAkJCSkKKwlQTEQoCWJsdAkuY2Z1XzBjcHlub3BsZAkJKQorCVBMRCgJcGxk
CVtyMSwgIzYwXQkJKQorCVBMRCgJcGxkCVtyMCwgIzYwXQkJKQorCisuY2Z1XzBjcHk4bHA6
CisJUExEKAlwbGQJW3IxLCAjOTJdCQkpCisJUExEKAlwbGQJW3IwLCAjOTJdCQkpCisuY2Z1
XzBjcHlub3BsZDoJbGRtaWEJcjEhLCB7cjMgLSByNn0JCQlAIFNob3VsZG50IGZhdWx0CisJ
CXN0bWlhCXIwISwge3IzIC0gcjZ9CisJCWxkbWlhCXIxISwge3IzIC0gcjZ9CQkJQCBTaG91
bGRudCBmYXVsdAorCQlzdWJzCWlwLCBpcCwgIzMyCisJCXN0bWlhCXIwISwge3IzIC0gcjZ9
CisJCWJwbAkuY2Z1XzBjcHk4bHAKKwlQTEQoCWNtbglpcCwgIzY0CQkJKQorCVBMRCgJYmdl
CS5jZnVfMGNweW5vcGxkCQkpCisJUExEKAlhZGQJaXAsIGlwLCAjNjQJCSkKKworLmNmdV8w
cmVtOGxwOgljbW4JaXAsICMxNgorCQlsZG1nZWlhCXIxISwge3IzIC0gcjZ9CQkJQCBTaG91
bGRudCBmYXVsdAorCQlzdG1nZWlhCXIwISwge3IzIC0gcjZ9CisJCXRzdAlpcCwgIzgKKwkJ
bGRtbmVpYQlyMSEsIHtyMyAtIHI0fQkJCUAgU2hvdWxkbnQgZmF1bHQKKwkJc3RtbmVpYQly
MCEsIHtyMyAtIHI0fQorCQl0c3QJaXAsICM0CisJCWxkcm5ldAlyMywgW3IxXSwgIzQJCQlA
IFNob3VsZG50IGZhdWx0CisJCXN0cm5lCXIzLCBbcjBdLCAjNAorCQlhbmRzCWlwLCBpcCwg
IzMKKwkJYmVxCS5jZnVfMGZ1cGkKKy5jZnVfMG5vd29yZHM6CXRlcQlpcCwgIzAKKwkJYmVx
CS5jZnVfZmluaXNoZWQKKy5jZnVfbm93b3JkczoJY21wCWlwLCAjMgorVVNFUigJCWxkcmJ0
CXIzLCBbcjFdLCAjMSkJCQlAIE1heSBmYXVsdAorCQlzdHJiCXIzLCBbcjBdLCAjMQorVVNF
UigJCWxkcmdlYnQJcjMsIFtyMV0sICMxKQkJCUAgTWF5IGZhdWx0CisJCXN0cmdlYglyMywg
W3IwXSwgIzEKK1VTRVIoCQlsZHJndGJ0CXIzLCBbcjFdLCAjMSkJCQlAIE1heSBmYXVsdAor
CQlzdHJndGIJcjMsIFtyMF0sICMxCisJCWIJLmNmdV9maW5pc2hlZAorCisuY2Z1X25vdF9l
bm91Z2g6CisJCW1vdnMJaXAsIHIyCisJCWJuZQkuY2Z1X25vd29yZHMKKy5jZnVfZmluaXNo
ZWQ6CW1vdglyMCwgIzAKKwkJYWRkCXNwLCBzcCwgIzgKKwkJbGRtZmQJc3AhLHtyNCAtIHI3
LCBwY30KKworLmNmdV9zcmNfbm90X2FsaWduZWQ6CisJCWJpYwlyMSwgcjEsICMzCitVU0VS
KAkJbGRydAlyNywgW3IxXSwgIzQpCQkJQCBNYXkgZmF1bHQKKwkJY21wCWlwLCAjMgorCQli
Z3QJLmNmdV8zZnVwaQorCQliZXEJLmNmdV8yZnVwaQorLmNmdV8xZnVwaToJc3VicwlyMiwg
cjIsICM0CisJCWFkZG1pCWlwLCByMiwgIzQKKwkJYm1pCS5jZnVfMW5vd29yZHMKKwkJbW92
CXIzLCByNywgcHVsbCAjOAorVVNFUigJCWxkcnQJcjcsIFtyMV0sICM0KQkJCUAgTWF5IGZh
dWx0CisJCW9ycglyMywgcjMsIHI3LCBwdXNoICMyNAorCQlzdHIJcjMsIFtyMF0sICM0CisJ
CW1vdglpcCwgcjEsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAsICMwCisJ
CW1vdnMJaXAsIGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmNmdV8xZnVwaQor
CQljbXAJcjIsIGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAorCQlzdWJz
CWlwLCBpcCwgIzE2CisJCWJsdAkuY2Z1XzFyZW04bHAKKwlQTEQoCXBsZAlbcjEsICMxMl0J
CSkKKwlQTEQoCXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAjMzIJCSkK
KwlQTEQoCWJsdAkuY2Z1XzFjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4XQkJKQor
CVBMRCgJcGxkCVtyMCwgIzI4XQkJKQorCisuY2Z1XzFjcHk4bHA6CisJUExEKAlwbGQJW3Ix
LCAjNDRdCQkpCisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuY2Z1XzFjcHlub3BsZDoJbW92
CXIzLCByNywgcHVsbCAjOAorCQlsZG1pYQlyMSEsIHtyNCAtIHI3fQkJCUAgU2hvdWxkbnQg
ZmF1bHQKKwkJc3VicwlpcCwgaXAsICMxNgorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjMjQK
KwkJbW92CXI0LCByNCwgcHVsbCAjOAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjMjQKKwkJ
bW92CXI1LCByNSwgcHVsbCAjOAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjMjQKKwkJbW92
CXI2LCByNiwgcHVsbCAjOAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjMjQKKwkJc3RtaWEJ
cjAhLCB7cjMgLSByNn0KKwkJYnBsCS5jZnVfMWNweThscAorCVBMRCgJY21uCWlwLCAjMzIJ
CQkpCisJUExEKAliZ2UJLmNmdV8xY3B5bm9wbGQJCSkKKwlQTEQoCWFkZAlpcCwgaXAsICMz
MgkJKQorCisuY2Z1XzFyZW04bHA6CXRzdAlpcCwgIzgKKwkJbW92bmUJcjMsIHI3LCBwdWxs
ICM4CisJCWxkbW5laWEJcjEhLCB7cjQsIHI3fQkJCUAgU2hvdWxkbnQgZmF1bHQKKwkJb3Jy
bmUJcjMsIHIzLCByNCwgcHVzaCAjMjQKKwkJbW92bmUJcjQsIHI0LCBwdWxsICM4CisJCW9y
cm5lCXI0LCByNCwgcjcsIHB1c2ggIzI0CisJCXN0bW5laWEJcjAhLCB7cjMgLSByNH0KKwkJ
dHN0CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzgKK1VTRVIoCQlsZHJuZXQJcjcs
IFtyMV0sICM0KQkJCUAgTWF5IGZhdWx0CisJCW9ycm5lCXIzLCByMywgcjcsIHB1c2ggIzI0
CisJCXN0cm5lCXIzLCBbcjBdLCAjNAorCQlhbmRzCWlwLCBpcCwgIzMKKwkJYmVxCS5jZnVf
MWZ1cGkKKy5jZnVfMW5vd29yZHM6CW1vdglyMywgcjcsIGdldF9ieXRlXzEKKwkJdGVxCWlw
LCAjMAorCQliZXEJLmNmdV9maW5pc2hlZAorCQljbXAJaXAsICMyCisJCXN0cmIJcjMsIFty
MF0sICMxCisJCW1vdmdlCXIzLCByNywgZ2V0X2J5dGVfMgorCQlzdHJnZWIJcjMsIFtyMF0s
ICMxCisJCW1vdmd0CXIzLCByNywgZ2V0X2J5dGVfMworCQlzdHJndGIJcjMsIFtyMF0sICMx
CisJCWIJLmNmdV9maW5pc2hlZAorCisuY2Z1XzJmdXBpOglzdWJzCXIyLCByMiwgIzQKKwkJ
YWRkbWkJaXAsIHIyLCAjNAorCQlibWkJLmNmdV8ybm93b3JkcworCQltb3YJcjMsIHI3LCBw
dWxsICMxNgorVVNFUigJCWxkcnQJcjcsIFtyMV0sICM0KQkJCUAgTWF5IGZhdWx0CisJCW9y
cglyMywgcjMsIHI3LCBwdXNoICMxNgorCQlzdHIJcjMsIFtyMF0sICM0CisJCW1vdglpcCwg
cjEsIGxzbCAjMzIgLSBQQUdFX1NISUZUCisJCXJzYglpcCwgaXAsICMwCisJCW1vdnMJaXAs
IGlwLCBsc3IgIzMyIC0gUEFHRV9TSElGVAorCQliZXEJLmNmdV8yZnVwaQorCQljbXAJcjIs
IGlwCisJCW1vdmx0CWlwLCByMgorCQlzdWIJcjIsIHIyLCBpcAorCQlzdWJzCWlwLCBpcCwg
IzE2CisJCWJsdAkuY2Z1XzJyZW04bHAKKwlQTEQoCXBsZAlbcjEsICMxMl0JCSkKKwlQTEQo
CXBsZAlbcjAsICMxMl0JCSkKKwlQTEQoCXN1YnMJaXAsIGlwLCAjMzIJCSkKKwlQTEQoCWJs
dAkuY2Z1XzJjcHlub3BsZAkJKQorCVBMRCgJcGxkCVtyMSwgIzI4XQkJKQorCVBMRCgJcGxk
CVtyMCwgIzI4XQkJKQorCisuY2Z1XzJjcHk4bHA6CisJUExEKAlwbGQJW3IxLCAjNDRdCQkp
CisJUExEKAlwbGQJW3IwLCAjNDRdCQkpCisuY2Z1XzJjcHlub3BsZDoJbW92CXIzLCByNywg
cHVsbCAjMTYKKwkJbGRtaWEJcjEhLCB7cjQgLSByN30JCQlAIFNob3VsZG50IGZhdWx0CisJ
CXN1YnMJaXAsIGlwLCAjMTYKKwkJb3JyCXIzLCByMywgcjQsIHB1c2ggIzE2CisJCW1vdgly
NCwgcjQsIHB1bGwgIzE2CisJCW9ycglyNCwgcjQsIHI1LCBwdXNoICMxNgorCQltb3YJcjUs
IHI1LCBwdWxsICMxNgorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjMTYKKwkJbW92CXI2LCBy
NiwgcHVsbCAjMTYKKwkJb3JyCXI2LCByNiwgcjcsIHB1c2ggIzE2CisJCXN0bWlhCXIwISwg
e3IzIC0gcjZ9CisJCWJwbAkuY2Z1XzJjcHk4bHAKKwlQTEQoCWNtbglpcCwgIzMyCQkJKQor
CVBMRCgJYmdlCS5jZnVfMmNweW5vcGxkCQkpCisJUExEKAlhZGQJaXAsIGlwLCAjMzIJCSkK
KworLmNmdV8ycmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIzLCByNywgcHVsbCAjMTYK
KwkJbGRtbmVpYQlyMSEsIHtyNCwgcjd9CQkJQCBTaG91bGRudCBmYXVsdAorCQlvcnJuZQly
MywgcjMsIHI0LCBwdXNoICMxNgorCQltb3ZuZQlyNCwgcjQsIHB1bGwgIzE2CisJCW9ycm5l
CXI0LCByNCwgcjcsIHB1c2ggIzE2CisJCXN0bW5laWEJcjAhLCB7cjMgLSByNH0KKwkJdHN0
CWlwLCAjNAorCQltb3ZuZQlyMywgcjcsIHB1bGwgIzE2CitVU0VSKAkJbGRybmV0CXI3LCBb
cjFdLCAjNCkJCQlAIE1heSBmYXVsdAorCQlvcnJuZQlyMywgcjMsIHI3LCBwdXNoICMxNgor
CQlzdHJuZQlyMywgW3IwXSwgIzQKKwkJYW5kcwlpcCwgaXAsICMzCisJCWJlcQkuY2Z1XzJm
dXBpCisuY2Z1XzJub3dvcmRzOgltb3YJcjMsIHI3LCBnZXRfYnl0ZV8yCisJCXRlcQlpcCwg
IzAKKwkJYmVxCS5jZnVfZmluaXNoZWQKKwkJY21wCWlwLCAjMgorCQlzdHJiCXIzLCBbcjBd
LCAjMQorCQltb3ZnZQlyMywgcjcsIGdldF9ieXRlXzMKKwkJc3RyZ2ViCXIzLCBbcjBdLCAj
MQorVVNFUigJCWxkcmd0YnQJcjMsIFtyMV0sICMwKQkJCUAgTWF5IGZhdWx0CisJCXN0cmd0
YglyMywgW3IwXSwgIzEKKwkJYgkuY2Z1X2ZpbmlzaGVkCisKKy5jZnVfM2Z1cGk6CXN1YnMJ
cjIsIHIyLCAjNAorCQlhZGRtaQlpcCwgcjIsICM0CisJCWJtaQkuY2Z1XzNub3dvcmRzCisJ
CW1vdglyMywgcjcsIHB1bGwgIzI0CitVU0VSKAkJbGRydAlyNywgW3IxXSwgIzQpCQkJQCBN
YXkgZmF1bHQKKwkJb3JyCXIzLCByMywgcjcsIHB1c2ggIzgKKwkJc3RyCXIzLCBbcjBdLCAj
NAorCQltb3YJaXAsIHIxLCBsc2wgIzMyIC0gUEFHRV9TSElGVAorCQlyc2IJaXAsIGlwLCAj
MAorCQltb3ZzCWlwLCBpcCwgbHNyICMzMiAtIFBBR0VfU0hJRlQKKwkJYmVxCS5jZnVfM2Z1
cGkKKwkJY21wCXIyLCBpcAorCQltb3ZsdAlpcCwgcjIKKwkJc3ViCXIyLCByMiwgaXAKKwkJ
c3VicwlpcCwgaXAsICMxNgorCQlibHQJLmNmdV8zcmVtOGxwCisJUExEKAlwbGQJW3IxLCAj
MTJdCQkpCisJUExEKAlwbGQJW3IwLCAjMTJdCQkpCisJUExEKAlzdWJzCWlwLCBpcCwgIzMy
CQkpCisJUExEKAlibHQJLmNmdV8zY3B5bm9wbGQJCSkKKwlQTEQoCXBsZAlbcjEsICMyOF0J
CSkKKwlQTEQoCXBsZAlbcjAsICMyOF0JCSkKKworLmNmdV8zY3B5OGxwOgorCVBMRCgJcGxk
CVtyMSwgIzQ0XQkJKQorCVBMRCgJcGxkCVtyMCwgIzQ0XQkJKQorLmNmdV8zY3B5bm9wbGQ6
CW1vdglyMywgcjcsIHB1bGwgIzI0CisJCWxkbWlhCXIxISwge3I0IC0gcjd9CQkJQCBTaG91
bGRudCBmYXVsdAorCQlvcnIJcjMsIHIzLCByNCwgcHVzaCAjOAorCQltb3YJcjQsIHI0LCBw
dWxsICMyNAorCQlvcnIJcjQsIHI0LCByNSwgcHVzaCAjOAorCQltb3YJcjUsIHI1LCBwdWxs
ICMyNAorCQlvcnIJcjUsIHI1LCByNiwgcHVzaCAjOAorCQltb3YJcjYsIHI2LCBwdWxsICMy
NAorCQlvcnIJcjYsIHI2LCByNywgcHVzaCAjOAorCQlzdG1pYQlyMCEsIHtyMyAtIHI2fQor
CQlzdWJzCWlwLCBpcCwgIzE2CisJCWJwbAkuY2Z1XzNjcHk4bHAKKwlQTEQoCWNtbglpcCwg
IzMyCQkJKQorCVBMRCgJYmdlCS5jZnVfM2NweW5vcGxkCQkpCisJUExEKAlhZGQJaXAsIGlw
LCAjMzIJCSkKKworLmNmdV8zcmVtOGxwOgl0c3QJaXAsICM4CisJCW1vdm5lCXIzLCByNywg
cHVsbCAjMjQKKwkJbGRtbmVpYQlyMSEsIHtyNCwgcjd9CQkJQCBTaG91bGRudCBmYXVsdAor
CQlvcnJuZQlyMywgcjMsIHI0LCBwdXNoICM4CisJCW1vdm5lCXI0LCByNCwgcHVsbCAjMjQK
KwkJb3JybmUJcjQsIHI0LCByNywgcHVzaCAjOAorCQlzdG1uZWlhCXIwISwge3IzIC0gcjR9
CisJCXRzdAlpcCwgIzQKKwkJbW92bmUJcjMsIHI3LCBwdWxsICMyNAorVVNFUigJCWxkcm5l
dAlyNywgW3IxXSwgIzQpCQkJQCBNYXkgZmF1bHQKKwkJb3JybmUJcjMsIHIzLCByNywgcHVz
aCAjOAorCQlzdHJuZQlyMywgW3IwXSwgIzQKKwkJYW5kcwlpcCwgaXAsICMzCisJCWJlcQku
Y2Z1XzNmdXBpCisuY2Z1XzNub3dvcmRzOgltb3YJcjMsIHI3LCBnZXRfYnl0ZV8zCisJCXRl
cQlpcCwgIzAKKwkJYmVxCS5jZnVfZmluaXNoZWQKKwkJY21wCWlwLCAjMgorCQlzdHJiCXIz
LCBbcjBdLCAjMQorVVNFUigJCWxkcmdlYnQJcjMsIFtyMV0sICMxKQkJCUAgTWF5IGZhdWx0
CisJCXN0cmdlYglyMywgW3IwXSwgIzEKK1VTRVIoCQlsZHJndGJ0CXIzLCBbcjFdLCAjMSkJ
CQlAIE1heSBmYXVsdAorCQlzdHJndGIJcjMsIFtyMF0sICMxCisJCWIJLmNmdV9maW5pc2hl
ZAorCisJCS5zZWN0aW9uIC5maXh1cCwiYXgiCisJCS5hbGlnbgkwCisJCS8qCisJCSAqIFdl
IHRvb2sgYW4gZXhjZXB0aW9uLiAgcjAgY29udGFpbnMgYSBwb2ludGVyIHRvCisJCSAqIHRo
ZSBieXRlIG5vdCBjb3BpZWQuCisJCSAqLworOTAwMToJCWxkcglyMiwgW3NwXSwgIzQJCQlA
IHZvaWQgKnRvCisJCXN1YglyMiwgcjAsIHIyCQkJQCBieXRlcyBjb3BpZWQKKwkJbGRyCXIx
LCBbc3BdLCAjNAkJCUAgdW5zaWduZWQgbG9uZyBjb3VudAorCQlzdWJzCXI0LCByMSwgcjIJ
CQlAIGJ5dGVzIGxlZnQgdG8gY29weQorCQltb3ZuZQlyMSwgcjQKKwkJYmxuZQlfX21lbXpl
cm8KKwkJbW92CXIwLCByNAorCQlsZG1mZAlzcCEsIHtyNCAtIHI3LCBwY30KKwkJLnByZXZp
b3VzCisKKy8qIFByb3RvdHlwZTogaW50IF9fYXJjaF9jbGVhcl91c2VyKHZvaWQgKmFkZHIs
IHNpemVfdCBzeikKKyAqIFB1cnBvc2UgIDogY2xlYXIgc29tZSB1c2VyIG1lbW9yeQorICog
UGFyYW1zICAgOiBhZGRyIC0gdXNlciBtZW1vcnkgYWRkcmVzcyB0byBjbGVhcgorICogICAg
ICAgICAgOiBzeiAgIC0gbnVtYmVyIG9mIGJ5dGVzIHRvIGNsZWFyCisgKiBSZXR1cm5zICA6
IG51bWJlciBvZiBieXRlcyBOT1QgY2xlYXJlZAorICovCitFTlRSWShfX2FyY2hfY2xlYXJf
dXNlcikKKwkJc3RtZmQJc3AhLCB7cjEsIGxyfQorCQltb3YJcjIsICMwCisJCWNtcAlyMSwg
IzQKKwkJYmx0CTJmCisJCWFuZHMJaXAsIHIwLCAjMworCQliZXEJMWYKKwkJY21wCWlwLCAj
MgorVVNFUigJCXN0cmJ0CXIyLCBbcjBdLCAjMSkKK1VTRVIoCQlzdHJsZWJ0CXIyLCBbcjBd
LCAjMSkKK1VTRVIoCQlzdHJsdGJ0CXIyLCBbcjBdLCAjMSkKKwkJcnNiCWlwLCBpcCwgIzQK
KwkJc3ViCXIxLCByMSwgaXAJCUAgIDcgIDYgIDUgIDQgIDMgIDIgIDEKKzE6CQlzdWJzCXIx
LCByMSwgIzgJCUAgLTEgLTIgLTMgLTQgLTUgLTYgLTcKK1VTRVIoCQlzdHJwbHQJcjIsIFty
MF0sICM0KQorVVNFUigJCXN0cnBsdAlyMiwgW3IwXSwgIzQpCisJCWJwbAkxYgorCQlhZGRz
CXIxLCByMSwgIzQJCUAgIDMgIDIgIDEgIDAgLTEgLTIgLTMKK1VTRVIoCQlzdHJwbHQJcjIs
IFtyMF0sICM0KQorMjoJCXRzdAlyMSwgIzIJCQlAIDF4IDF4IDB4IDB4IDF4IDF4IDB4CitV
U0VSKAkJc3RybmVidAlyMiwgW3IwXSwgIzEpCitVU0VSKAkJc3RybmVidAlyMiwgW3IwXSwg
IzEpCisJCXRzdAlyMSwgIzEJCQlAIHgxIHgwIHgxIHgwIHgxIHgwIHgxCitVU0VSKAkJc3Ry
bmVidAlyMiwgW3IwXSwgIzEpCisJCW1vdglyMCwgIzAKKwkJbGRtZmQJc3AhLCB7cjEsIHBj
fQorCisJCS5zZWN0aW9uIC5maXh1cCwiYXgiCisJCS5hbGlnbgkwCis5MDAxOgkJbGRtZmQJ
c3AhLCB7cjAsIHBjfQorCQkucHJldmlvdXMKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0vbGliL3VkaXZkaTMuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL3VkaXZkaTMuYwlGcmkgRmVi
IDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyNDIgQEAKKy8qIE1vcmUgc3Vi
cm91dGluZXMgbmVlZGVkIGJ5IEdDQyBvdXRwdXQgY29kZSBvbiBzb21lIG1hY2hpbmVzLiAg
Ki8KKy8qIENvbXBpbGUgdGhpcyBvbmUgd2l0aCBnY2MuICAqLworLyogQ29weXJpZ2h0IChD
KSAxOTg5LCA5Mi05OCwgMTk5OSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKwor
VGhpcyBmaWxlIGlzIHBhcnQgb2YgR05VIENDLgorCitHTlUgQ0MgaXMgZnJlZSBzb2Z0d2Fy
ZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQoraXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg
YnkKK3RoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9y
IChhdCB5b3VyIG9wdGlvbikKK2FueSBsYXRlciB2ZXJzaW9uLgorCitHTlUgQ0MgaXMgZGlz
dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKK2J1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9m
CitNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Uu
ICBTZWUgdGhlCitHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxz
LgorCitZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZQorYWxvbmcgd2l0aCBHTlUgQ0M7IHNlZSB0aGUgZmlsZSBDT1BZ
SU5HLiAgSWYgbm90LCB3cml0ZSB0bwordGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwg
NTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLAorQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBV
U0EuICAqLworCisvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCBpZiB5b3UgbGluayB0aGlz
IGxpYnJhcnkgd2l0aCBvdGhlciBmaWxlcywKKyAgIHNvbWUgb2Ygd2hpY2ggYXJlIGNvbXBp
bGVkIHdpdGggR0NDLCB0byBwcm9kdWNlIGFuIGV4ZWN1dGFibGUsCisgICB0aGlzIGxpYnJh
cnkgZG9lcyBub3QgYnkgaXRzZWxmIGNhdXNlIHRoZSByZXN1bHRpbmcgZXhlY3V0YWJsZQor
ICAgdG8gYmUgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UuCisg
ICBUaGlzIGV4Y2VwdGlvbiBkb2VzIG5vdCBob3dldmVyIGludmFsaWRhdGUgYW55IG90aGVy
IHJlYXNvbnMgd2h5CisgICB0aGUgZXhlY3V0YWJsZSBmaWxlIG1pZ2h0IGJlIGNvdmVyZWQg
YnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLgorICovCisvKiBzdXBwb3J0IGZ1
bmN0aW9ucyByZXF1aXJlZCBieSB0aGUga2VybmVsLiBiYXNlZCBvbiBjb2RlIGZyb20gZ2Nj
LTIuOTUuMyAqLworLyogSSBNb2x0b24gICAgIDI5LzA3LzAxICovCisKKyNpbmNsdWRlICJn
Y2NsaWIuaCIKKyNpbmNsdWRlICJsb25nbG9uZy5oIgorCitzdGF0aWMgY29uc3QgVVFJdHlw
ZSBfX2Nsel90YWJbXSA9Cit7CisgIDAsMSwyLDIsMywzLDMsMyw0LDQsNCw0LDQsNCw0LDQs
NSw1LDUsNSw1LDUsNSw1LDUsNSw1LDUsNSw1LDUsNSwKKyAgNiw2LDYsNiw2LDYsNiw2LDYs
Niw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LDYsNiw2LAorICA3LDcs
Nyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcs
Nyw3LDcsCisgIDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcsNyw3LDcs
Nyw3LDcsNyw3LDcsNyw3LDcsNywKKyAgOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LAorICA4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsCisgIDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCwKKyAgOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgsOCw4LDgs
OCw4LDgsOCw4LDgsOCw4LDgsOCw4LAorfTsKKworVURJdHlwZQorX191ZGl2bW9kZGk0IChV
REl0eXBlIG4sIFVESXR5cGUgZCwgVURJdHlwZSAqcnApCit7CisgIERJdW5pb24gd3c7Cisg
IERJdW5pb24gbm4sIGRkOworICBESXVuaW9uIHJyOworICBVU0l0eXBlIGQwLCBkMSwgbjAs
IG4xLCBuMjsKKyAgVVNJdHlwZSBxMCwgcTE7CisgIFVTSXR5cGUgYiwgYm07CisKKyAgbm4u
bGwgPSBuOworICBkZC5sbCA9IGQ7CisKKyAgZDAgPSBkZC5zLmxvdzsKKyAgZDEgPSBkZC5z
LmhpZ2g7CisgIG4wID0gbm4ucy5sb3c7CisgIG4xID0gbm4ucy5oaWdoOworCisgIGlmIChk
MSA9PSAwKQorICAgIHsKKyAgICAgIGlmIChkMCA+IG4xKQorICAgICAgICB7CisgICAgICAg
ICAgLyogMHEgPSBubiAvIDBEICovCisKKyAgICAgICAgICBjb3VudF9sZWFkaW5nX3plcm9z
IChibSwgZDApOworCisgICAgICAgICAgaWYgKGJtICE9IDApCisgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgIC8qIE5vcm1hbGl6ZSwgaS5lLiBtYWtlIHRoZSBtb3N0IHNpZ25pZmlj
YW50IGJpdCBvZiB0aGUKKyAgICAgICAgICAgICAgICAgZGVub21pbmF0b3Igc2V0LiAgKi8K
KworICAgICAgICAgICAgICBkMCA9IGQwIDw8IGJtOworICAgICAgICAgICAgICBuMSA9IChu
MSA8PCBibSkgfCAobjAgPj4gKFNJX1RZUEVfU0laRSAtIGJtKSk7CisgICAgICAgICAgICAg
IG4wID0gbjAgPDwgYm07CisgICAgICAgICAgICB9CisKKyAgICAgICAgICB1ZGl2X3Fybm5k
IChxMCwgbjAsIG4xLCBuMCwgZDApOworICAgICAgICAgIHExID0gMDsKKworICAgICAgICAg
IC8qIFJlbWFpbmRlciBpbiBuMCA+PiBibS4gICovCisgICAgICAgIH0KKyAgICAgIGVsc2UK
KyAgICAgICAgeworICAgICAgICAgIC8qIHFxID0gTk4gLyAwZCAqLworCisgICAgICAgICAg
aWYgKGQwID09IDApCisgICAgICAgICAgICBkMCA9IDEgLyBkMDsgICAgICAgIC8qIERpdmlk
ZSBpbnRlbnRpb25hbGx5IGJ5IHplcm8uICAqLworCisgICAgICAgICAgY291bnRfbGVhZGlu
Z196ZXJvcyAoYm0sIGQwKTsKKworICAgICAgICAgIGlmIChibSA9PSAwKQorICAgICAgICAg
ICAgeworICAgICAgICAgICAgICAvKiBGcm9tIChuMSA+PSBkMCkgL1wgKHRoZSBtb3N0IHNp
Z25pZmljYW50IGJpdCBvZiBkMCBpcyBzZXQpLAorICAgICAgICAgICAgICAgICBjb25jbHVk
ZSAodGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0IG9mIG4xIGlzIHNldCkgL1wgKHRoZQorICAg
ICAgICAgICAgICAgICBsZWFkaW5nIHF1b3RpZW50IGRpZ2l0IHExID0gMSkuCisKKyAgICAg
ICAgICAgICAgICAgVGhpcyBzcGVjaWFsIGNhc2UgaXMgbmVjZXNzYXJ5LCBub3QgYW4gb3B0
aW1pemF0aW9uLgorICAgICAgICAgICAgICAgICAoU2hpZnRzIGNvdW50cyBvZiBTSV9UWVBF
X1NJWkUgYXJlIHVuZGVmaW5lZC4pICAqLworCisgICAgICAgICAgICAgIG4xIC09IGQwOwor
ICAgICAgICAgICAgICBxMSA9IDE7CisgICAgICAgICAgICB9CisgICAgICAgICAgZWxzZQor
ICAgICAgICAgICAgeworICAgICAgICAgICAgICAvKiBOb3JtYWxpemUuICAqLworCisgICAg
ICAgICAgICAgIGIgPSBTSV9UWVBFX1NJWkUgLSBibTsKKworICAgICAgICAgICAgICBkMCA9
IGQwIDw8IGJtOworICAgICAgICAgICAgICBuMiA9IG4xID4+IGI7CisgICAgICAgICAgICAg
IG4xID0gKG4xIDw8IGJtKSB8IChuMCA+PiBiKTsKKyAgICAgICAgICAgICAgbjAgPSBuMCA8
PCBibTsKKworICAgICAgICAgICAgICB1ZGl2X3Fybm5kIChxMSwgbjEsIG4yLCBuMSwgZDAp
OworICAgICAgICAgICAgfQorCisgICAgICAgICAgLyogbjEgIT0gZDAuLi4gICovCisKKyAg
ICAgICAgICB1ZGl2X3Fybm5kIChxMCwgbjAsIG4xLCBuMCwgZDApOworCisgICAgICAgICAg
LyogUmVtYWluZGVyIGluIG4wID4+IGJtLiAgKi8KKyAgICAgICAgfQorCisgICAgICBpZiAo
cnAgIT0gMCkKKyAgICAgICAgeworICAgICAgICAgIHJyLnMubG93ID0gbjAgPj4gYm07Cisg
ICAgICAgICAgcnIucy5oaWdoID0gMDsKKyAgICAgICAgICAqcnAgPSByci5sbDsKKyAgICAg
ICAgfQorICAgIH0KKyAgZWxzZQorICAgIHsKKyAgICAgIGlmIChkMSA+IG4xKQorICAgICAg
ICB7CisgICAgICAgICAgLyogMDAgPSBubiAvIEREICovCisKKyAgICAgICAgICBxMCA9IDA7
CisgICAgICAgICAgcTEgPSAwOworCisgICAgICAgICAgLyogUmVtYWluZGVyIGluIG4xbjAu
ICAqLworICAgICAgICAgIGlmIChycCAhPSAwKQorICAgICAgICAgICAgeworICAgICAgICAg
ICAgICByci5zLmxvdyA9IG4wOworICAgICAgICAgICAgICByci5zLmhpZ2ggPSBuMTsKKyAg
ICAgICAgICAgICAgKnJwID0gcnIubGw7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAg
ICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAgIC8qIDBxID0gTk4gLyBkZCAqLworCisg
ICAgICAgICAgY291bnRfbGVhZGluZ196ZXJvcyAoYm0sIGQxKTsKKyAgICAgICAgICBpZiAo
Ym0gPT0gMCkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgLyogRnJvbSAobjEgPj0g
ZDEpIC9cICh0aGUgbW9zdCBzaWduaWZpY2FudCBiaXQgb2YgZDEgaXMgc2V0KSwKKyAgICAg
ICAgICAgICAgICAgY29uY2x1ZGUgKHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCBvZiBuMSBp
cyBzZXQpIC9cICh0aGUKKyAgICAgICAgICAgICAgICAgcXVvdGllbnQgZGlnaXQgcTAgPSAw
IG9yIDEpLgorCisgICAgICAgICAgICAgICAgIFRoaXMgc3BlY2lhbCBjYXNlIGlzIG5lY2Vz
c2FyeSwgbm90IGFuIG9wdGltaXphdGlvbi4gICovCisKKyAgICAgICAgICAgICAgLyogVGhl
IGNvbmRpdGlvbiBvbiB0aGUgbmV4dCBsaW5lIHRha2VzIGFkdmFudGFnZSBvZiB0aGF0Cisg
ICAgICAgICAgICAgICAgIG4xID49IGQxICh0cnVlIGR1ZSB0byBwcm9ncmFtIGZsb3cpLiAg
Ki8KKyAgICAgICAgICAgICAgaWYgKG4xID4gZDEgfHwgbjAgPj0gZDApCisgICAgICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgICAgcTAgPSAxOworICAgICAgICAgICAgICAgICAg
c3ViX2RkbW1zcyAobjEsIG4wLCBuMSwgbjAsIGQxLCBkMCk7CisgICAgICAgICAgICAgICAg
fQorICAgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgcTAgPSAwOworCisgICAg
ICAgICAgICAgIHExID0gMDsKKworICAgICAgICAgICAgICBpZiAocnAgIT0gMCkKKyAgICAg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICByci5zLmxvdyA9IG4wOworICAgICAg
ICAgICAgICAgICAgcnIucy5oaWdoID0gbjE7CisgICAgICAgICAgICAgICAgICAqcnAgPSBy
ci5sbDsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICB9CisgICAgICAgICAgZWxz
ZQorICAgICAgICAgICAgeworICAgICAgICAgICAgICBVU0l0eXBlIG0xLCBtMDsKKyAgICAg
ICAgICAgICAgLyogTm9ybWFsaXplLiAgKi8KKworICAgICAgICAgICAgICBiID0gU0lfVFlQ
RV9TSVpFIC0gYm07CisKKyAgICAgICAgICAgICAgZDEgPSAoZDEgPDwgYm0pIHwgKGQwID4+
IGIpOworICAgICAgICAgICAgICBkMCA9IGQwIDw8IGJtOworICAgICAgICAgICAgICBuMiA9
IG4xID4+IGI7CisgICAgICAgICAgICAgIG4xID0gKG4xIDw8IGJtKSB8IChuMCA+PiBiKTsK
KyAgICAgICAgICAgICAgbjAgPSBuMCA8PCBibTsKKworICAgICAgICAgICAgICB1ZGl2X3Fy
bm5kIChxMCwgbjEsIG4yLCBuMSwgZDEpOworICAgICAgICAgICAgICB1bXVsX3BwbW0gKG0x
LCBtMCwgcTAsIGQwKTsKKworICAgICAgICAgICAgICBpZiAobTEgPiBuMSB8fCAobTEgPT0g
bjEgJiYgbTAgPiBuMCkpCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
cTAtLTsKKyAgICAgICAgICAgICAgICAgIHN1Yl9kZG1tc3MgKG0xLCBtMCwgbTEsIG0wLCBk
MSwgZDApOworICAgICAgICAgICAgICAgIH0KKworICAgICAgICAgICAgICBxMSA9IDA7CisK
KyAgICAgICAgICAgICAgLyogUmVtYWluZGVyIGluIChuMW4wIC0gbTFtMCkgPj4gYm0uICAq
LworICAgICAgICAgICAgICBpZiAocnAgIT0gMCkKKyAgICAgICAgICAgICAgICB7CisgICAg
ICAgICAgICAgICAgICBzdWJfZGRtbXNzIChuMSwgbjAsIG4xLCBuMCwgbTEsIG0wKTsKKyAg
ICAgICAgICAgICAgICAgIHJyLnMubG93ID0gKG4xIDw8IGIpIHwgKG4wID4+IGJtKTsKKyAg
ICAgICAgICAgICAgICAgIHJyLnMuaGlnaCA9IG4xID4+IGJtOworICAgICAgICAgICAgICAg
ICAgKnJwID0gcnIubGw7CisgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAgfQorICAg
ICAgICB9CisgICAgfQorCisgIHd3LnMubG93ID0gcTA7CisgIHd3LnMuaGlnaCA9IHExOwor
ICByZXR1cm4gd3cubGw7Cit9CisKK1VESXR5cGUKK19fdWRpdmRpMyAoVURJdHlwZSBuLCBV
REl0eXBlIGQpCit7CisgIHJldHVybiBfX3VkaXZtb2RkaTQgKG4sIGQsIChVREl0eXBlICop
IDApOworfQorCitVREl0eXBlCitfX3Vtb2RkaTMgKFVESXR5cGUgdSwgVURJdHlwZSB2KQor
eworICBVREl0eXBlIHc7CisKKyAgKHZvaWQpIF9fdWRpdm1vZGRpNCAodSAsdiwgJncpOwor
CisgIHJldHVybiB3OworfQorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS9s
aWIvdWxkaXZtb2QuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vYXJjaC9hcm0vbGliL3VsZGl2bW9kLlMJRnJpIEZlYiAwMyAxNjow
NzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTQ4IEBACisvKgorKiBBLCBRID0gcjAgKyAo
cjEgPDwgMzIpCisqIEIsIFIgPSByMiArIChyMyA8PCAzMikKKyogQSAvIEIgPSBRIC4uLiBS
CisqLworIAorLnRleHQKKy5nbG9iYWwJX19hZWFiaV91bGRpdm1vZAorLnR5cGUJX19hZWFi
aV91bGRpdm1vZCwgZnVuY3Rpb24KKy5hbGlnbgkwCitBXzAJLnJlcQlyMAorQV8xCS5yZXEJ
cjEKK0JfMAkucmVxCXIyCitCXzEJLnJlcQlyMworQ18wCS5yZXEJcjQKK0NfMQkucmVxCXI1
CitEXzAJLnJlcQlyNgorRF8xCS5yZXEJcjcKK1FfMAkucmVxCXIwCitRXzEJLnJlcQlyMQor
Ul8wCS5yZXEJcjIKK1JfMQkucmVxCXIzCisgCitfX2FlYWJpX3VsZGl2bW9kOgorCXN0bWZk
CXNwISwge3I0LCByNSwgcjYsIHI3LCBscn0KKyAKKwlAIFRlc3QgaWYgQiA9PSAwCisJb3Jy
cwlpcCwgQl8wLCBCXzEJCUAgWiBzZXQgLT4gQiA9PSAwCisJYmVxCUxfZGl2X2J5XzAKKwlA
IFRlc3QgaWYgQiBpcyBwb3dlciBvZiAyOiAoQiAmIChCIC0gMSkpID09IDAKKwlzdWJzCUNf
MCwgQl8wLCAjMQorCXNiYwlDXzEsIEJfMSwgIzAKKwl0c3QJQ18wLCBCXzAKKwl0c3RlcQlC
XzEsIENfMQorCWJlcQlMX3BvdzIKKwlAIFRlc3QgaWYgQV8xID09IEJfMSA9PSAwCisJb3Jy
cwlpcCwgQV8xLCBCXzEKKwliZXEJTF9kaXZfMzJfMzIKKworTF9kaXZfNjRfNjQ6CisJbW92
CUNfMCwgIzEKKwltb3YJQ18xLCAjMAorCUAgRF8wID0gY2x6IEEKKwl0ZXEJQV8xLCAjMAor
CWNseglEXzAsIEFfMQorCWNsemVxCWlwLCBBXzAKKwlhZGRlcQlEXzAsIERfMCwgaXAKKwlA
IERfMSA9IGNseiBCCisJdGVxCUJfMSwgIzAKKwljbHoJRF8xLCBCXzEKKwljbHplcQlpcCwg
Ql8wCisJYWRkZXEJRF8xLCBEXzEsIGlwCisJQCBpZiBjbHogQiAtIGNseiBBID4gMAorCXN1
YnMJRF8wLCBEXzEsIERfMAorCWJscwlMX2RvbmVfc2hpZnQKKwlAIEIgPDw9IChjbHogQiAt
IGNseiBBKQorCXN1YnMJRF8xLCBEXzAsICMzMgorCXJzYglpcCwgRF8wLCAjMzIKKwltb3Zt
aQlCXzEsIEJfMSwgbHNsIERfMAorCW9ycm1pCUJfMSwgQl8xLCBCXzAsIGxzciBpcAorCW1v
dnBsCUJfMSwgQl8wLCBsc2wgRF8xCisJbW92CUJfMCwgQl8wLCBsc2wgRF8wCisJQCBDID0g
MSA8PCAoY2x6IEIgLSBjbHogQSkKKwltb3ZtaQlDXzEsIENfMSwgbHNsIERfMAorCW9ycm1p
CUNfMSwgQ18xLCBDXzAsIGxzciBpcAorCW1vdnBsCUNfMSwgQ18wLCBsc2wgRF8xCisJbW92
CUNfMCwgQ18wLCBsc2wgRF8wCitMX2RvbmVfc2hpZnQ6CisJbW92CURfMCwgIzAKKwltb3YJ
RF8xLCAjMAorCUAgQzogY3VycmVudCBiaXQ7IEQ6IHJlc3VsdAorTF9zdWJ0cmFjdDoKKwlA
IGlmIEEgPj0gQgorCWNtcAlBXzEsIEJfMQorCWNtcGVxCUFfMCwgQl8wCisJYmNjCUxfdXBk
YXRlCisJQCBBIC09IEIKKwlzdWJzCUFfMCwgQV8wLCBCXzAKKwlzYmMJQV8xLCBBXzEsIEJf
MQorCUAgRCB8PSBDCisJb3JyCURfMCwgRF8wLCBDXzAKKwlvcnIJRF8xLCBEXzEsIENfMQor
TF91cGRhdGU6CisJQCBpZiBBID09IDA6IGJyZWFrCisJb3JycwlpcCwgQV8xLCBBXzAKKwli
ZXEJTF9leGl0CisJQCBDID4+PSAxCisJbW92cwlDXzEsIENfMSwgbHNyICMxCisJbW92cwlD
XzAsIENfMCwgcnJ4CisJQCBpZiBDID09IDA6IGJyZWFrCisJb3JycwlpcCwgQ18xLCBDXzAK
KwliZXEJTF9leGl0CisJQCBCID4+PSAxCisJbW92cwlCXzEsIEJfMSwgbHNyICMxCisJbW92
CUJfMCwgQl8wLCBycngKKwliCUxfc3VidHJhY3QKK0xfZXhpdDoKKwlAIE5vdGU6IEEsIEIg
JiBRLCBSIGFyZSBhbGlhc2VzCisJbW92CVJfMCwgQV8wCisJbW92CVJfMSwgQV8xCisJbW92
CVFfMCwgRF8wCisJbW92CVFfMSwgRF8xCisJbGRtZmQJc3AhLCB7cjQsIHI1LCByNiwgcjcs
IHBjfQorCitMX2Rpdl8zMl8zMjoKKwlAIE5vdGU6CUFfMCAmCXIwIGFyZSBhbGlhc2VzCisJ
QAlRXzEJcjEKKwltb3YJcjEsIEJfMAorCWJsCV9fYWVhYmlfdWlkaXZtb2QKKwltb3YJUl8w
LCByMQorCW1vdglSXzEsICMwCisJbW92CVFfMSwgIzAKKwlsZG1mZAlzcCEsIHtyNCwgcjUs
IHI2LCByNywgcGN9CisgCitMX3BvdzI6CisJQCBOb3RlOiBBLCBCIGFuZCBRLCBSIGFyZSBh
bGlhc2VzCisJQCBSID0gQSAmIChCIC0gMSkKKwlhbmQJQ18wLCBBXzAsIENfMAorCWFuZAlD
XzEsIEFfMSwgQ18xCisJQCBRID0gQSA+PiBsb2cyKEIpCisJQCBOb3RlOiBCIG11c3Qgbm90
IGJlIDAgaGVyZSEKKwljbHoJRF8wLCBCXzAKKwlhZGQJRF8xLCBEXzAsICMxCisJcnNicwlE
XzAsIERfMCwgIzMxCisJYnBsCUxfMQorCWNseglEXzAsIEJfMQorCXJzYglEXzAsIERfMCwg
IzMxCisJbW92CUFfMCwgQV8xLCBsc3IgRF8wCisJYWRkCURfMCwgRF8wLCAjMzIKK0xfMToK
Kwltb3ZwbAlBXzAsIEFfMCwgbHNyIERfMAorCW9ycnBsCUFfMCwgQV8wLCBBXzEsIGxzbCBE
XzEKKwltb3YJQV8xLCBBXzEsIGxzciBEXzAKKwlAIE1vdiBiYWNrIEMgdG8gUgorCW1vdglS
XzAsIENfMAorCW1vdglSXzEsIENfMQorCWxkbWZkCXNwISwge3I0LCByNSwgcjYsIHI3LCBw
Y30KKworTF9kaXZfYnlfMDoKKwlibAlfX2RpdjAKKwlAIEFzIHdyb25nIGFzIGl0IGNvdWxk
IGJlCisJbW92CVFfMCwgIzAKKwltb3YJUV8xLCAjMAorCW1vdglSXzAsICMwCisJbW92CVJf
MSwgIzAKKwlsZG1mZAlzcCEsIHtyNCwgcjUsIHI2LCByNywgcGN9CisgCisKZGlmZiAtciBl
NzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3RlZ3JhL01ha2VmaWxlCi0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS90ZWdy
YS9NYWtlZmlsZQlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwx
IEBACitvYmoteSArPSBkdW1teS5vCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2Fy
bS90ZWdyYS9SdWxlcy5tawotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0vdGVncmEvUnVsZXMubWsJRnJpIEZlYiAwMyAx
NjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMSBAQAorQ0ZMQUdTLXkgKz0gLW1hcmNo
PWFybXY3LWEKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3RlZ3JhL2R1bW15
LmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
eGVuL2FyY2gvYXJtL3RlZ3JhL2R1bW15LmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsMyBAQAordm9pZCBkdW1teSh2b2lkKQoreworfQpkaWZmIC1yIGU3
MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCi0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vTWFr
ZWZpbGUJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTkgQEAK
K29iai15ICs9IHNldHVwLm8KK29iai15ICs9IG1tLm8KK29iai15ICs9IGlycS5vCitvYmot
eSArPSBhcmNoX2RvbWFpbi5vCitvYmoteSArPSB0aW1lLm8KK29iai15ICs9IGRvbWFpbl9i
dWlsZC5vCitvYmoteSArPSBmYXVsdC5vCitvYmoteSArPSB0bGIubworb2JqLXkgKz0gc2h1
dGRvd24ubworb2JqLXkgKz0gYXJjaF9kb21jdGwubworb2JqLXkgKz0gY3B1Lm8KK29iai15
ICs9IGlvbW11Lm8KK29iai15ICs9IGdyYW50X3RhYmxlLm8KK29iai15ICs9IGFyY2hfc3lz
Y3RsLm8KK29iai15ICs9IG1hY2hpbmVfa2V4ZWMubworb2JqLXkgKz0gY3Jhc2gubworb2Jq
LXkgKz0gcDJtLm8KK29iai15ICs9IHBlcmZtb24ubworb2JqLXkgKz0gcGNpLm8KZGlmZiAt
ciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWFpbi5jCi0tLSAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2Fy
bS94ZW4vYXJjaF9kb21haW4uYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAg
LTAsMCArMSwyMTIgQEAKKy8qCisgKiBhcmNoX2RvbWFpbi5jCisgKgorICogQ29weXJpZ2h0
IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgU2FuZy1i
dW0gU3VoICAgIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEphZW1pbiBS
eXUgICAgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBKb29Zb3VuZyBI
d2FuZyAgPGpvb3lvdW5nLmh3YW5nQHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2
ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkg
V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVS
Q0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2Vl
IHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4K
KyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5v
dCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5
IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EK
KyAqLworCisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgor
I2luY2x1ZGUgPHhlbi9saWIuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNsdWRl
IDx4ZW4vbW0uaD4KKyNpbmNsdWRlIDx4ZW4vZG9tYWluLmg+CisjaW5jbHVkZSA8eGVuL2Vy
cm5vLmg+CisjaW5jbHVkZSA8eGVuL3NtcC5oPgorI2luY2x1ZGUgPHhlbi9pcnEuaD4KKyNp
bmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4KKyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgor
Cit2b2lkIGFyY2hfZHVtcF9kb21haW5faW5mbyhzdHJ1Y3QgZG9tYWluICpkKQoreworCU5P
VF9ZRVQoKTsKK30KKwordm9pZCBhcmNoX2R1bXBfdmNwdV9pbmZvKHN0cnVjdCB2Y3B1ICp2
KQoreworCU5PVF9ZRVQoKTsKK30KKwordW5zaWduZWQgbG9uZyBoeXBlcmNhbGxfY3JlYXRl
X2NvbnRpbnVhdGlvbih1bnNpZ25lZCBpbnQgb3AsCisgICAgICAgIGNvbnN0IGNoYXIgKmZv
cm1hdCwgLi4uKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAwOworfQorCitpbnQgYXJj
aF9kb21haW5fY3JlYXRlKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBkb21jcl9m
bGFncykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKwordm9pZCBh
cmNoX2RvbWFpbl9kZXN0cm95KHN0cnVjdCBkb21haW4gKmQpCit7CisJTk9UX1lFVCgpOwor
fQorCitzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICphbGxvY192Y3B1X2d1ZXN0X2NvbnRl
eHQodm9pZCkKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gTlVMTDsKK30KKwordm9pZCBm
cmVlX3ZjcHVfZ3Vlc3RfY29udGV4dChzdHJ1Y3QgdmNwdV9ndWVzdF9jb250ZXh0ICpjb250
ZXh0KQoreworCU5PVF9ZRVQoKTsKK30KKworCitzdHJ1Y3QgdmNwdSAqYWxsb2NfdmNwdV9z
dHJ1Y3Qodm9pZCkKK3sKKwlOT1RfWUVUKCk7CisJcmV0dXJuIE5VTEw7Cit9CisKK3ZvaWQg
YXJjaF92Y3B1X3Jlc2V0KHN0cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKwor
aW50IHZjcHVfaW5pdGlhbGlzZShzdHJ1Y3QgdmNwdSAqdikKK3sKKwlOT1RfWUVUKCk7CisJ
cmV0dXJuIDA7Cit9CisKK3ZvaWQgdmNwdV9kZXN0cm95KHN0cnVjdCB2Y3B1ICp2KQorewor
CU5PVF9ZRVQoKTsKK30KKwordm9pZCBmcmVlX3ZjcHVfc3RydWN0KHN0cnVjdCB2Y3B1ICp2
KQoreworCU5PVF9ZRVQoKTsKK30KKworc3RydWN0IGRvbWFpbiAqYWxsb2NfZG9tYWluX3N0
cnVjdCh2b2lkKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiBOVUxMOworfQorCisKK3Zv
aWQgZnJlZV9kb21haW5fc3RydWN0KHN0cnVjdCBkb21haW4gKmQpCit7CisJTk9UX1lFVCgp
OworfQorCitpbnQgYXJjaF9zZXRfaW5mb19ndWVzdChzdHJ1Y3QgdmNwdSAqdiwgdmNwdV9n
dWVzdF9jb250ZXh0X3QgKmN0eCkKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKKwor
fQorCit2b2lkIGRvbWFpbl9yZWxpbnF1aXNoX21lbW9yeShzdHJ1Y3QgZG9tYWluICpkKQor
eworCU5PVF9ZRVQoKTsKK30KKwordm9pZCBkdW1wX3BhZ2VmcmFtZV9pbmZvKHN0cnVjdCBk
b21haW4gKmQpCit7CisJTk9UX1lFVCgpOworfQorCit2b2lkIGNvbnRleHRfc3dpdGNoKHN0
cnVjdCB2Y3B1ICpwcmV2LCBzdHJ1Y3QgdmNwdSAqbmV4dCkKK3sKKwlOT1RfWUVUKCk7Cit9
CisKK3ZvaWQgY29udGludWVfcnVubmluZyhzdHJ1Y3QgdmNwdSAqc2FtZSkKK3sKKwlOT1Rf
WUVUKCk7Cit9CisKK3ZvaWQgc3luY19sYXp5X2V4ZWNzdGF0ZV9jcHUodW5zaWduZWQgaW50
IGNwdSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgc3luY19sYXp5X2V4ZWNzdGF0ZV9t
YXNrKGNwdW1hc2tfdCBtYXNrKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9pZCBzeW5jX3Zj
cHVfZXhlY3N0YXRlKHN0cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKwordm9p
ZCBzeW5jX2xvY2FsX2V4ZWNzdGF0ZSh2b2lkKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9p
ZCByZWxpbnF1aXNoX21lbW9yeShzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3QgbGlzdF9oZWFk
ICpsaXN0KQoreworCU5PVF9ZRVQoKTsKK30KKworaW50IGRvbWFpbl9yZWxpbnF1aXNoX3Jl
c291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAt
RUlOVkFMOworfQorCit2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKQoreworCU5P
VF9ZRVQoKTsKK30KKworbG9uZyBhcmNoX2RvX3ZjcHVfb3AoaW50IGNtZCwgc3RydWN0IHZj
cHUgKnYsIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKQoreworCU5PVF9ZRVQoKTsKKwor
CXJldHVybiAtRU5PU1lTOworfQorCit2b2lkIHZjcHVfa2ljayhzdHJ1Y3QgdmNwdSAqdikK
K3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgdmNwdV9tYXJrX2V2ZW50c19wZW5kaW5nKHN0
cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKworc3RhdGljIHZvaWQgdmNwdV9r
aWNrX3NvZnRpcnEodm9pZCkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3N0YXRpYyBpbnQgX19p
bml0IHZjcHVfa2lja19zb2Z0aXJxX2luaXQodm9pZCkKK3sKKwlOT1RfWUVUKCk7CisKKwly
ZXR1cm4gMDsKK30KKworX19pbml0Y2FsbCh2Y3B1X2tpY2tfc29mdGlycV9pbml0KTsKZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3hlbi9hcmNoX2RvbWN0bC5jCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNo
L2FybS94ZW4vYXJjaF9kb21jdGwuYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAK
QEAgLTAsMCArMSw0MyBAQAorLyoKKyAqIGFyY2hfZG9tY3RsLmMKKyAqCisgKiBDb3B5cmln
aHQgKEMpIDIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgSmFlbWluIFJ5
dSAgICAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMg
ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQor
ICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lv
biAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBG
b3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUg
aG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJB
TlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5U
QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUK
KyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgor
ICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwg
UHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy
aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1w
bGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8K
KworI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNs
dWRlIDx4ZW4vbGliLmg+CisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVu
L21tLmg+CisjaW5jbHVkZSA8eGVuL2RvbWFpbi5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5o
PgorI2luY2x1ZGUgPHhlbi9zbXAuaD4KKyNpbmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4K
KyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgorCisKK3ZvaWQgYXJjaF9nZXRfaW5mb19ndWVz
dChzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IHZjcHVfZ3Vlc3RfY29udGV4dCAqY3R4KQorewor
CU5PVF9ZRVQoKTsKK30KKworbG9uZyBhcmNoX2RvX2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0
bCAqZG9tY3RsLCBYRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdClyX2RvbWN0bCkKK3sK
KwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KZGlmZiAtciBlNzAxNDYxYjEy
NTEgeGVuL2FyY2gvYXJtL3hlbi9hcmNoX3N5c2N0bC5jCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vYXJjaF9z
eXNjdGwuYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwzOCBA
QAorLyoKKyAqIGFyY2hfc3lzY3RsLmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAx
MSBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsu
c3VoQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlbWluIFJ5dSAgIDxqbTc3LnJ5dUBz
YW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91
IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRl
cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg
YmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4g
dGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT
IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZl
IHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAq
IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNv
ZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMz
MCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHN0ZGFy
Zy5oPgorI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+Cisj
aW5jbHVkZSA8eGVuL3NjaGVkLmg+CisjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8
eGVuL2RvbWFpbi5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPHhlbi9z
bXAuaD4KKyNpbmNsdWRlIDx4ZW4vaXJxX2NwdXN0YXQuaD4KKyNpbmNsdWRlIDx4ZW4vc29m
dGlycS5oPgorCitsb25nIGFyY2hfZG9fc3lzY3RsKHN0cnVjdCB4ZW5fc3lzY3RsICpzeXNj
dGwsIFhFTl9HVUVTVF9IQU5ETEUoeGVuX3N5c2N0bF90KXVfc3lzY3RsKQoreworCU5PVF9Z
RVQoKTsKKworCXJldHVybiAtRUlOVkFMOworfQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4v
YXJjaC9hcm0veGVuL2FzbS1vZmZzZXRzLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9hc20tb2Zmc2V0cy5j
CUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQwIEBACisjaW5j
bHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2luY2x1ZGUgPHhl
bi9wZXJmYy5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPGFzbS9oYXJk
aXJxLmg+CisjaW5jbHVkZSA8YXNtL2N1cnJlbnQuaD4KKworI2lmIGRlZmluZWQoX19BUENT
XzI2X18pCisjZXJyb3IgU29ycnksIHlvdXIgY29tcGlsZXIgdGFyZ2V0cyBBUENTLTI2IGJ1
dCB0aGlzIGtlcm5lbCByZXF1aXJlcyBBUENTLTMyCisjZW5kaWYKKy8qCisgKiBHQ0MgMi45
NS4xLCAyLjk1LjI6IGlnbm9yZXMgcmVnaXN0ZXIgY2xvYmJlciBsaXN0IGluIGFzbSgpLgor
ICogR0NDIDMuMCwgMy4xOiBnZW5lcmFsIGJhZCBjb2RlIGdlbmVyYXRpb24uCisgKiBHQ0Mg
My4yLjA6IGluY29ycmVjdCBmdW5jdGlvbiBhcmd1bWVudCBvZmZzZXQgY2FsY3VsYXRpb24u
CisgKiBHQ0MgMy4yLng6IG1pc2NvbXBpbGVzIE5FV19BVVhfRU5UIGluIGZzL2JpbmZtdF9l
bGYuYworICogICAgICAgICAgICAoaHR0cDovL2djYy5nbnUub3JnL1BSODg5NikgYW5kIGlu
Y29ycmVjdCBzdHJ1Y3R1cmUKKyAqCSAgICAgIGluaXRpYWxpc2F0aW9uIGluIGZzL2pmZnMy
L2VyYXNlLmMKKyAqLworI2lmIF9fR05VQ19fIDwgMiB8fCBcCisgICAoX19HTlVDX18gPT0g
MiAmJiBfX0dOVUNfTUlOT1JfXyA8IDk1KSB8fCBcCisgICAoX19HTlVDX18gPT0gMiAmJiBf
X0dOVUNfTUlOT1JfXyA9PSA5NSAmJiBfX0dOVUNfUEFUQ0hMRVZFTF9fICE9IDAgJiYgXAor
CQkJCQkgICAgIF9fR05VQ19QQVRDSExFVkVMX18gPCAzKSB8fCBcCisgICAoX19HTlVDX18g
PT0gMyAmJiBfX0dOVUNfTUlOT1JfXyA8IDMpCisjZXJyb3IgWW91ciBjb21waWxlciBpcyB0
b28gYnVnZ3k7IGl0IGlzIGtub3duIHRvIG1pc2NvbXBpbGUga2VybmVscy4KKyNlcnJvciAg
ICBLbm93biBnb29kIGNvbXBpbGVyczogMi45NS4zLCAyLjk1LjQsIDIuOTYsIDMuMworI2Vu
ZGlmCisKKy8qIFVzZSBtYXJrZXIgaWYgeW91IG5lZWQgdG8gc2VwYXJhdGUgdGhlIHZhbHVl
cyBsYXRlciAqLworCisjZGVmaW5lIERFRklORShzeW0sIHZhbCkgXAorICAgICAgICBhc20g
dm9sYXRpbGUoIlxuLT4iICNzeW0gIiAlMCAiICN2YWwgOiA6ICJpIiAodmFsKSkKKworI2Rl
ZmluZSBCTEFOSygpIGFzbSB2b2xhdGlsZSgiXG4tPiIgOiA6ICkKKworaW50IG1haW4odm9p
ZCkKK3sKKwlCTEFOSygpOworCisJcmV0dXJuIDA7IAorfQpkaWZmIC1yIGU3MDE0NjFiMTI1
MSB4ZW4vYXJjaC9hcm0veGVuL2J1Zy5jCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vYnVnLmMJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzIgQEAKKyNpbmNsdWRlIDx4ZW4v
c3RkYXJnLmg+CisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi92ZXJz
aW9uLmg+CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+Cisj
aW5jbHVkZSA8eGVuL2Vycm5vLmg+CisjaW5jbHVkZSA8eGVuL2V2ZW50Lmg+CisjaW5jbHVk
ZSA8eGVuL3NwaW5sb2NrLmg+CisjaW5jbHVkZSA8eGVuL2NvbnNvbGUuaD4KKyNpbmNsdWRl
IDx4ZW4vc2VyaWFsLmg+CisjaW5jbHVkZSA8eGVuL3NvZnRpcnEuaD4KKyNpbmNsdWRlIDx4
ZW4va2V5aGFuZGxlci5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2luY2x1ZGUgPHhlbi9k
ZWxheS5oPgorI2luY2x1ZGUgPHhlbi9ndWVzdF9hY2Nlc3MuaD4KKyNpbmNsdWRlIDx4ZW4v
c2h1dGRvd24uaD4KKyNpbmNsdWRlIDxhc20vY3VycmVudC5oPgorI2luY2x1ZGUgPGFzbS9k
ZWJ1Z2dlci5oPgorCit2b2lkIGJ1ZyhjaGFyICpmaWxlLCBpbnQgbGluZSkKK3sKKwlwYW5p
YygiWGVuIEJVRyBhdCAlczolZFxuIiwgZmlsZSwgbGluZSk7CisKKwl3aGlsZSgxKTsKK30K
Kwordm9pZCB3YXJuKGNoYXIgKmZpbGUsIGludCBsaW5lKQoreworCXByaW50aygiWGVuIFdB
Uk4gYXQgJXM6JWRcbiIsIGZpbGUsIGxpbmUpOworCit9CisKZGlmZiAtciBlNzAxNDYxYjEy
NTEgeGVuL2FyY2gvYXJtL3hlbi9jcHUuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NwdS5jCUZyaSBGZWIg
MDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDk3IEBACisvKgorICogY3B1LmMK
KyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAg
ICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAg
IEphZU1pbiBSeXUgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhpcyBwcm9n
cmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBt
b2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzIAorICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVk
IGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBB
TlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICog
TUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg
U2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWls
cy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlm
IG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4s
IDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBV
U0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9zcGlu
bG9jay5oPgorI2luY2x1ZGUgPHhlbi9jcHVtYXNrLmg+CisjaW5jbHVkZSA8eGVuL3NtcC5o
PgorI2luY2x1ZGUgPHhlbi9pcnEuaD4KKyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgorI2lu
Y2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9wcmVlbXB0Lmg+CisjaW5jbHVk
ZSA8eGVuL3BlcmNwdS5oPgorCitjcHVtYXNrX3QgY3B1X29ubGluZV9tYXA7CitjcHVtYXNr
X3QgY3B1X3ByZXNlbnRfbWFwOworY3B1bWFza190IGNwdV9wb3NzaWJsZV9tYXA7CisKK25v
ZGVtYXNrX3Qgbm9kZV9vbmxpbmVfbWFwID0ge3sgWzBdID0gMVVMIH19OworCit1bnNpZ25l
ZCBjaGFyIGNwdV90b19ub2RlW05SX0NQVVNdIF9fcmVhZF9tb3N0bHkgPSB7CisgICAgICAg
IFswIC4uLiBOUl9DUFVTLTFdID0gTlVNQV9OT19OT0RFCit9OworCitjcHVtYXNrX3Qgbm9k
ZV90b19jcHVtYXNrW01BWF9OVU1OT0RFU10gX19yZWFkX21vc3RseTsKKworREVGSU5FX1BF
Ul9DUFVfUkVBRF9NT1NUTFkoY3B1bWFza192YXJfdCxjcHVfc2libGluZ19tYXNrKTsKK0RF
RklORV9QRVJfQ1BVX1JFQURfTU9TVExZKGNwdW1hc2tfdmFyX3QsY3B1X2NvcmVfbWFzayk7
CisKK2ludCBfX2NwdV91cCh1bnNpZ25lZCBpbnQgY3B1KQoreworCU5PVF9ZRVQoKTsKKwor
CXJldHVybiAwOworfQorCit2b2lkIF9fY3B1X2Rpc2FibGUodm9pZCkKK3sKKwlOT1RfWUVU
KCk7Cit9CisKK3ZvaWQgX19jcHVfZGllKHVuc2lnbmVkIGludCBjcHUpCit7CisJTk9UX1lF
VCgpOworfQorCit2b2lkIHNldF9jcHVfc2libGluZ19tYXAodW5zaWduZWQgaW50IGNwdSkK
K3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgc21wX3ByZXBhcmVfY3B1cyh1bnNpZ25lZCBp
bnQgbWF4X2NwdXMpCit7CisJTk9UX1lFVCgpOworfQorCit2b2lkIHNtcF9wcmVwYXJlX2Jv
b3RfY3B1KHZvaWQpCit7CisJTk9UX1lFVCgpOworfQorCithc21saW5rYWdlIHZvaWQgc3Rh
cnRfeGVuX29uX3NsYXZlX2NwdSh2b2lkKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9pZCBz
bXBfc2VuZF9ldmVudF9jaGVja19tYXNrKGNvbnN0IGNwdW1hc2tfdCAqbWFzaykKK3sKKwlO
T1RfWUVUKCk7Cit9CisKK3ZvaWQgc21wX2NhbGxfZnVuY3Rpb24odm9pZCAoKmYpKHZvaWQg
KnBhcmFtKSwgdm9pZCAqcGFyYW0sIGludCB3YWl0KQoreworCU5PVF9ZRVQoKTsKK30KKwor
dm9pZCBzbXBfc2VuZF9zdGF0ZV9kdW1wKHVuc2lnbmVkIGludCBjcHUpCit7CisJTk9UX1lF
VCgpOworfQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL2NyYXNoLmMK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2FyY2gvYXJtL3hlbi9jcmFzaC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApA
QCAtMCwwICsxLDI1IEBACisvKgorICogY3Jhc2guYworICoKKyAqIENvcHlyaWdodCAoQykg
MjAwOCBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNi
dWsuc3VoQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5
dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsg
eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2Ug
YXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoK
KyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdp
bGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2
ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBo
YXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK
KyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVl
IFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRl
IDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKwordm9pZCBtYWNoaW5l
X2NyYXNoX3NodXRkb3duKHZvaWQpCit7Cit9CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVu
L2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWls
ZC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDQ3IEBACisv
KgorICogZG9tYWluX2J1aWxkLmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBT
YW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsuc3Vo
QHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBzYW1z
dW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVi
bGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRo
aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUg
dXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl
IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJl
Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFs
b25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3
YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwg
Qm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKyNpbmNsdWRlIDx4ZW4vY29uZmln
Lmg+CisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+Cisj
aW5jbHVkZSA8eGVuL2NvbXBpbGUuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNs
dWRlIDx4ZW4vZWxmLmg+CisjaW5jbHVkZSA8eGVuL2RvbWFpbi5oPgorI2luY2x1ZGUgPHhl
bi9tbS5oPgorI2luY2x1ZGUgPHhlbi9pb2NhcC5oPgorI2luY2x1ZGUgPHhlbi94bWFsbG9j
Lmg+CisjaW5jbHVkZSA8eGVuL3ByZWVtcHQuaD4KKyNpbmNsdWRlIDx4ZW4vbGliZWxmLmg+
CisjaW5jbHVkZSA8cHVibGljL3hlbi5oPgorI2luY2x1ZGUgPHB1YmxpYy92ZXJzaW9uLmg+
CisKKy8qCisgKiBkb21haW5fY29uc3RydWN0KCkgc2hvdWxkIGJlIGFsd2F5cyBpbnZva2Vk
IGluIGlkbGUgZG9tYWluCisgKi8KK2ludCBkb21haW5fY29uc3RydWN0KHN0cnVjdCBkb21h
aW4gKmQsIAorCQkgICAgIHVuc2lnbmVkIGxvbmcgaW1nX3N0YXJ0LCB1bnNpZ25lZCBsb25n
IGltZ19sZW4sIAorCQkgICAgIHVuc2lnbmVkIGxvbmcgZG9tX3NpemUsIHVuc2lnbmVkIGlu
dCB2Y3B1cykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKwpkaWZm
IC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9wYWdlLmMKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9kb21haW5fcGFnZS5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApA
QCAtMCwwICsxLDIyIEBACisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhl
bi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL2xpYi5oPgorI2luY2x1ZGUgPHhlbi9wZXJmYy5o
PgorI2luY2x1ZGUgPHhlbi9kb21haW5fcGFnZS5oPgorCisjaWZkZWYgQ09ORklHX0RPTUFJ
Tl9QQUdFCisKK3ZvaWQgKm1hcF9kb21haW5fcGFnZSh1bnNpZ25lZCBsb25nIHBmbikKK3sK
KwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gTlVMTDsKK30KKwordm9pZCB1bm1hcF9kb21haW5f
cGFnZSh2b2lkICp2YSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKKyNlbmRpZgorCmRpZmYgLXIg
ZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS94ZW4vZmF1bHQuYwotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2Zh
dWx0LmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMTIzIEBA
CisvKg0KKyAqIHRyYXBzLmMNCisgKg0KKyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNh
bXN1bmcgRWxlY3Ryb25pY3MNCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggPHNidWsuc3Vo
QHNhbXN1bmcuY29tPg0KKyAqICAgICAgICAgIEphZU1pbiBSeXUgICA8am03Ny5yeXVAc2Ft
c3VuZy5jb20+DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91
IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyAqIGl0IHVuZGVyIHRoZSB0
ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFz
IHB1Ymxpc2hlZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uDQorICoN
CisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3
aWxsIGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNIQU5UQUJJTElUWSBvciBG
SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgKiBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyAqDQorICogWW91IHNo
b3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UNCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0
aGUgRnJlZSBTb2Z0d2FyZQ0KKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFj
ZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCisgKi8NCisNCisj
aW5jbHVkZSA8eGVuL2NvbmZpZy5oPg0KKyNpbmNsdWRlIDx4ZW4vY29tcGlsZS5oPg0KKyNp
bmNsdWRlIDx4ZW4vZG9tYWluX3BhZ2UuaD4NCisjaW5jbHVkZSA8eGVuL2luaXQuaD4NCisj
aW5jbHVkZSA8eGVuL3NjaGVkLmg+DQorI2luY2x1ZGUgPHhlbi9saWIuaD4NCisjaW5jbHVk
ZSA8eGVuL2NvbnNvbGUuaD4NCisjaW5jbHVkZSA8eGVuL21tLmg+DQorI2luY2x1ZGUgPHhl
bi9pcnEuaD4NCisjaW5jbHVkZSA8eGVuL3N5bWJvbHMuaD4NCisjaW5jbHVkZSA8YXNtL2N1
cnJlbnQuaD4NCisjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPg0KKyNpbmNsdWRlIDxhc20v
Z3Vlc3RfYWNjZXNzLmg+DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8
YXNtL21lbW9yeS5oPg0KKw0KK2FzbWxpbmthZ2Ugdm9pZCBfX2RpdjAodm9pZCkNCit7DQor
ICAgICAgICBwcmludGsoIkRpdmlzaW9uIGJ5IHplcm8gaW4ga2VybmVsLlxuIik7DQorfQ0K
Kw0KK2ludCBmaXh1cF9leGNlcHRpb24oc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQor
ew0KKwlyZXR1cm4gLUVJTlZBTDsNCit9DQorDQordm9pZCBzaG93X3JlZ2lzdGVycyhzdHJ1
Y3QgY3B1X3VzZXJfcmVncyAqY3R4KQ0KK3sNCit9DQorDQordm9pZCBkdW1wX2V4ZWN1dGlv
bl9zdGF0ZSh2b2lkKQ0KK3sNCit9DQorDQordm9pZCBzaG93X2V4ZWN1dGlvbl9zdGF0ZShz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCit7DQorCXByaW50aygiTm90IGltcGxlbWVu
dGVkXG4iKTsNCit9DQorDQorc3RhdGljIGludCB2ZXJpZnlfc3RhY2sodW5zaWduZWQgbG9u
ZyBzcCkNCit7DQorCXJldHVybiAwOw0KK30NCisNCitzdGF0aWMgdm9pZCBiYWNrdHJhY2Uo
c3RydWN0IGNwdV91c2VyX3JlZ3MgKmN0eCkNCit7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIHVu
cmVjb3ZlcmFibGVfZmF1bHQoY29uc3QgY2hhciAqc3RyLCBpbnQgZXJyLCBzdHJ1Y3QgdmNw
dSAqdiwgc3RydWN0IGNwdV9jdHggKmN0eCkNCit7DQorCXByaW50aygiVW5yZWNvdmVyYWJs
ZSBGYXVsdCA6ICVzXG4iLCBzdHIpOw0KKw0KKwl3aGlsZSgxKTsNCisNCit9DQorDQorbG9u
ZyBkb19zZXRfY2FsbGJhY2tzKHVuc2lnbmVkIGxvbmcgZXZlbnQsIHVuc2lnbmVkIGxvbmcg
ZmFpbHNhZmUpDQorew0KKwlyZXR1cm4gLUVJTlZBTDsNCisNCit9DQorDQorYXNtbGlua2Fn
ZSB2b2lkIGRvX3ByZWZldGNoX2Fib3J0KHVuc2lnbmVkIGxvbmcgcGMsIHN0cnVjdCBjcHVf
Y3R4ICpjdHgpDQorew0KKwl3aGlsZSgxKTsNCisJdW5yZWNvdmVyYWJsZV9mYXVsdCgicHJl
ZmV0Y2ggYWJvcnQiLCAwLCBjdXJyZW50LCBjdHgpOw0KK30NCisNCithc21saW5rYWdlIHZv
aWQgZG9fZGF0YV9hYm9ydCh1bnNpZ25lZCBsb25nIGZzciwgdW5zaWduZWQgbG9uZyBmYXIs
IHN0cnVjdCBjcHVfY3R4ICpjdHgpDQorew0KKwl3aGlsZSgxKTsNCisJdW5yZWNvdmVyYWJs
ZV9mYXVsdCgiZGF0YSBhYm9ydCIsIDAsIGN1cnJlbnQsIGN0eCk7DQorfQ0KKw0KK2FzbWxp
bmthZ2Ugdm9pZCBkb191bmRlZmluZWRfaW5zdHJ1Y3Rpb24odW5zaWduZWQgbG9uZyBwYywg
c3RydWN0IGNwdV9jdHggKmN0eCkNCit7DQorCXdoaWxlKDEpOw0KKwl1bnJlY292ZXJhYmxl
X2ZhdWx0KCJ1bmRlZmluZWQgaW5zdHJ1Y3Rpb24iLCAwLCBjdXJyZW50LCBjdHgpOw0KK30N
CisNCit2b2lkIHZjcHVfc2hvd19leGVjdXRpb25fc3RhdGUoc3RydWN0IHZjcHUgKnYpDQor
ew0KKwlwcmludGsoIk5vdCBpbXBsZW1lbnRlZFxuIik7DQorfQ0KKw0KK2xvbmcgcmVnaXN0
ZXJfZ3Vlc3Rfbm1pX2NhbGxiYWNrKHVuc2lnbmVkIGxvbmcgYWRkcmVzcykNCit7DQorCXBy
aW50aygiTm90IGltcGxlbWVudGVkIHlldFxuIik7DQorDQorCXJldHVybiAtMTsNCit9DQor
DQordm9pZCB1bnJlZ2lzdGVyX2d1ZXN0X25taV9jYWxsYmFjayh2b2lkKQ0KK3sNCisJcHJp
bnRrKCJOb3QgaW1wbGVtZW50ZWQgeWV0XG4iKTsNCit9DQorDQorbG9uZyBkb19zZXRfdHJh
cF90YWJsZShYRU5fR1VFU1RfSEFORExFKHRyYXBfaW5mb190KSB0cmFwcykNCit7DQorCXJl
dHVybiAtRUZBVUxUOw0KK30NCisNCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2Fy
bS94ZW4vZ3JhbnRfdGFibGUuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2dyYW50X3RhYmxlLmMJRnJpIEZl
YiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTMgQEAKKy8qCisgKiBncmFu
dF90YWJsZS5jCisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVj
dHJvbmljcworICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNv
bT4KKyAqICAgICAgICAgIFN1bmdLd2FuIEhlbyA8c2suaGVvQHNhbXN1bmcuY29tPgorICog
ICAgICAgICAgSmFlTWluIFJ5dSAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBU
aGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUg
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0
cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJ
VEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkg
b2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS
UE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3Jl
IGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9n
cmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9u
LCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEt
MTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9saWIuaD4KKyNpbmNsdWRlIDx4ZW4v
dHlwZXMuaD4KKyNpbmNsdWRlIDx4ZW4vY3B1bWFzay5oPgorI2luY2x1ZGUgPHhlbi9saXN0
Lmg+CisjaW5jbHVkZSA8eGVuL2tlcm5lbC5oPgorI2luY2x1ZGUgPHhlbi9zdHJpbmcuaD4K
KyNpbmNsdWRlIDx4ZW4vZXJybm8uaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNs
dWRlIDx4ZW4vbW0uaD4KKyNpbmNsdWRlIDx4ZW4vZG9tYWluX3BhZ2UuaD4KKyNpbmNsdWRl
IDx4ZW4vaXJxX2NwdXN0YXQuaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnQuaD4KKyNpbmNsdWRl
IDx4ZW4vaW9jYXAuaD4KKyNpbmNsdWRlIDx4ZW4vcGVyZmMuaD4KKyNpbmNsdWRlIDx4ZW4v
Z3Vlc3RfYWNjZXNzLmg+CisKKworaW50IGNyZWF0ZV9ncmFudF9ob3N0X21hcHBpbmcodWlu
dDY0X3QgYWRkciwgdW5zaWduZWQgbG9uZyBmcmFtZSwgdW5zaWduZWQgaW50IGZsYWdzLCB1
bnNpZ25lZCBpbnQgY2FjaGVfZmxhZ3MpCit7CisJTk9UX1lFVCgpOworCQorCXJldHVybiAt
RUlOVkFMOworfQorCitpbnQgcmVwbGFjZV9ncmFudF9ob3N0X21hcHBpbmcodWludDY0X3Qg
YWRkciwgdW5zaWduZWQgbG9uZyBmcmFtZSwgdWludDY0X3QgbmV3X2FkZHIsIHVuc2lnbmVk
IGludCBmbGFncykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gR05UU1RfZ2VuZXJhbF9l
cnJvcjsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL2lvbW11
LmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
eGVuL2FyY2gvYXJtL3hlbi9pb21tdS5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDI0IEBACisKKyNpbmNsdWRlIDx4ZW4vbGliLmg+CisjaW5jbHVkZSA8
eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2xpc3QuaD4KKyNpbmNsdWRlIDx4ZW4vc3Ry
aW5nLmg+CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CisjaW5jbHVkZSA8eGVuL3NjaGVkLmg+
CisjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8eGVuL2lvY2FwLmg+CisjaW5jbHVk
ZSA8YXNtL2lvbW11Lmg+CisKK2ludCBpb21tdV9tYXBfcGFnZShzdHJ1Y3QgZG9tYWluICpk
LCB1bnNpZ25lZCBsb25nIGdmbiwgdW5zaWduZWQgbG9uZyBtZm4sIHVuc2lnbmVkIGludCBm
bGFncykKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKworaW50IGlv
bW11X3VubWFwX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgbG9uZyBnZm4pCit7
CisJTk9UX1lFVCgpOworCisJcmV0dXJuIC1FSU5WQUw7Cit9CmRpZmYgLXIgZTcwMTQ2MWIx
MjUxIHhlbi9hcmNoL2FybS94ZW4vaXJxLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9pcnEuYwlGcmkgRmVi
IDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw4NCBAQAorLyoKKyAqIGlycS5j
CisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmljcwor
ICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAg
ICAgICAgIEphZU1pbiBSeXUgICA8am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhp
cyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu
ZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwg
UHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICogdGhlIEZy
ZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9m
CisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UuICBTZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBk
ZXRhaWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3Jh
bTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwg
SW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEz
MDcgIFVTQQorICovCisKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8eGVu
L3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vbGliLmg+
CisjaW5jbHVkZSA8eGVuL2lycS5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1
ZGUgPHhlbi9zcGlubG9jay5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUg
PHhlbi9ldmVudC5oPgorI2luY2x1ZGUgPHB1YmxpYy9ldmVudF9jaGFubmVsLmg+CisjaW5j
bHVkZSA8cHVibGljL3BoeXNkZXYuaD4KKyNpbmNsdWRlIDxwdWJsaWMvYXJjaC1hcm0uaD4K
KworaHdfaXJxX2NvbnRyb2xsZXIgbm9faXJxX3R5cGUgPSB7CisJLnR5cGVuYW1lID0gIm5v
bmUiLAorCS5zdGFydHVwICA9IGlycV9zdGFydHVwX25vbmUsCisJLnNodXRkb3duID0gaXJx
X3NodXRkb3duX25vbmUsCisJLmVuYWJsZSAgID0gaXJxX2VuYWJsZV9ub25lLAorCS5kaXNh
YmxlICA9IGlycV9kaXNhYmxlX25vbmUsCit9OworCitzdHJ1Y3QgaXJxX2Rlc2MgKmlycV9k
ZXNjOworCitpbnQgcGlycV9ndWVzdF91bm1hc2soc3RydWN0IGRvbWFpbiAqZCkKK3sKKwlO
T1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKK30KKworaW50IHBpcnFfZ3Vlc3RfYmluZChzdHJ1
Y3QgdmNwdSAqdiwgc3RydWN0IHBpcnEgKnBpcnEsIGludCB3aWxsX3NoYXJlKQoreworCU5P
VF9ZRVQoKTsKKworCXJldHVybiAwOworfQorCit2b2lkIHBpcnFfZ3Vlc3RfdW5iaW5kKHN0
cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwaXJxICpwaXJxKQoreworCU5PVF9ZRVQoKTsKK30K
KworCit2b2lkIHBpcnFfc2V0X2FmZmluaXR5KHN0cnVjdCBkb21haW4gKmQsIGludCBwaXJx
LCBjb25zdCBjcHVtYXNrX3QgKm1hc2spCit7CisJTk9UX1lFVCgpOworfQorCisKK3N0cnVj
dCBwaXJxICphbGxvY19waXJxX3N0cnVjdChzdHJ1Y3QgZG9tYWluICpkKQoreworCU5PVF9Z
RVQoKTsKKworCXJldHVybiBOVUxMOworfQorCitpbnQgYXJjaF9pbml0X29uZV9pcnFfZGVz
YyhzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7
Cit9CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2FyY2gvYXJtL3hlbi9tYWNoaW5lX2tl
eGVjLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIveGVuL2FyY2gvYXJtL3hlbi9tYWNoaW5lX2tleGVjLmMJRnJpIEZlYiAwMyAxNjowNzow
MyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzEgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+
CisjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CisjaW5jbHVkZSA8eGVuL2xpYi5oPgorI2luY2x1
ZGUgPHhlbi9zbXAuaD4KKyNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4KKyNpbmNsdWRlIDx4ZW4v
Y29uc29sZS5oPgorI2luY2x1ZGUgPHhlbi9rZXhlYy5oPgorI2luY2x1ZGUgPHhlbi9kb21h
aW5fcGFnZS5oPgorCitpbnQgbWFjaGluZV9rZXhlY19sb2FkKGludCB0eXBlLCBpbnQgc2xv
dCwgeGVuX2tleGVjX2ltYWdlX3QgKmltYWdlKQoreworICAgIHJldHVybiAtRUlOVkFMOwor
fQorCit2b2lkIG1hY2hpbmVfa2V4ZWNfdW5sb2FkKGludCB0eXBlLCBpbnQgc2xvdCwgeGVu
X2tleGVjX2ltYWdlX3QgKmltYWdlKQoreworfQorCit2b2lkIG1hY2hpbmVfcmVib290X2tl
eGVjKHhlbl9rZXhlY19pbWFnZV90ICppbWFnZSkKK3sKK30KKwordm9pZCBtYWNoaW5lX2tl
eGVjKHhlbl9rZXhlY19pbWFnZV90ICppbWFnZSkKK3sKK30KKworaW50IG1hY2hpbmVfa2V4
ZWNfZ2V0KHhlbl9rZXhlY19yYW5nZV90ICpyYW5nZSkKK3sKKwlyZXR1cm4gLUVJTlZBTDsK
K30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL21tLmMKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9tbS5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsx
LDE5NCBAQAorLyoKKyAqIG1tLmMKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBT
YW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBTYW5nLWJ1bSBTdWggIDxzYnVrLnN1
aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEphZU1pbiBSeXUgICAgPGptNzcucnl1QHNh
bXN1bmcuY29tPgorICogICAgICAgICAgU3VuZ0t3YW4gSGVvICA8c2suaGVvQHNhbXN1bmcu
Y29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNo
ZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2Vm
dWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1w
bGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2
ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcg
d2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUK
KyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0
b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2xpYi5oPgor
I2luY2x1ZGUgPHhlbi90eXBlcy5oPgorI2luY2x1ZGUgPHhlbi9jcHVtYXNrLmg+CisjaW5j
bHVkZSA8eGVuL2xpc3QuaD4KKyNpbmNsdWRlIDx4ZW4va2VybmVsLmg+CisjaW5jbHVkZSA8
eGVuL3N0cmluZy5oPgorI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorI2luY2x1ZGUgPHhlbi9z
Y2hlZC5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2luY2x1ZGUgPHhlbi9kb21haW5fcGFn
ZS5oPgorI2luY2x1ZGUgPHhlbi9pcnFfY3B1c3RhdC5oPgorI2luY2x1ZGUgPHhlbi9ldmVu
dC5oPgorI2luY2x1ZGUgPHhlbi9pb2NhcC5oPgorI2luY2x1ZGUgPHhlbi9wZXJmYy5oPgor
I2luY2x1ZGUgPHhlbi9ndWVzdF9hY2Nlc3MuaD4KKworI2RlZmluZSBWRVJCT1NFIDEKKwor
I2RlZmluZSBNTVVfVVBEQVRFX1BSRUVNUFRFRCAgICAgICAgICAofih+MFUgPj4gMSkpCisK
K3N0YXRpYyB1bnNpZ25lZCBsb25nIG1wdF9zaXplOworCisvKiBGcmFtZSB0YWJsZSBhbmQg
aXRzIHNpemUgaW4gcGFnZXMuICovCitzdHJ1Y3QgcGFnZV9pbmZvICpmcmFtZV90YWJsZTsK
K3Vuc2lnbmVkIGxvbmcgbWluX3BhZ2UgPSB+MFVMOzsKK3Vuc2lnbmVkIGxvbmcgbWF4X3Bh
Z2UgPSAwVUw7CisKK3Vuc2lnbmVkIGxvbmcgeGVuaGVhcF9waHlzX3N0YXJ0ID0gfjBVTDsK
K3Vuc2lnbmVkIGxvbmcgeGVuaGVhcF9waHlzX2VuZCA9IDBVTDsKKwordW5zaWduZWQgbG9u
ZyB4ZW5fcGh5c19zdGFydCA9IH4wVUw7Cit1bnNpZ25lZCBsb25nIHhlbl9waHlzX2VuZCA9
IDBVTDsKKworI2lmZGVmIE1FTU9SWV9HVUFSRAordm9pZCBtZW1ndWFyZF9pbml0KHZvaWQp
Cit7CisJTk9UX1lFVCgpOworfQorCit2b2lkIG1lbWd1YXJkX2d1YXJkX3JhbmdlKHZvaWQg
KnAsIHVuc2lnbmVkIGxvbmcgbCkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgbWVtZ3Vh
cmRfdW5ndWFyZF9yYW5nZSh2b2lkICpwLCB1bnNpZ25lZCBsb25nIGwpCit7CisJTk9UX1lF
VCgpOworfQorCisjZW5kaWYKKwordm9pZCBwdXRfcGFnZShzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlKQoreworCU5PVF9ZRVQoKTsKK30KKworc3RydWN0IGRvbWFpbiAqcGFnZV9nZXRfb3du
ZXJfYW5kX3JlZmVyZW5jZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQoreworCU5PVF9ZRVQo
KTsKK30KKworaW50IGdldF9wYWdlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHN0cnVjdCBk
b21haW4gKmRvbWFpbikKK3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKK30KKwordm9p
ZCBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHN0
cnVjdCBkb21haW4gKmQsIGludCByZWFkb25seSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3Zv
aWQgc2hhcmVfeGVuX3BhZ2Vfd2l0aF9wcml2aWxlZ2VkX2d1ZXN0cyhzdHJ1Y3QgcGFnZV9p
bmZvICpwYWdlLCBpbnQgcmVhZG9ubHkpCit7CisJTk9UX1lFVCgpOworfQorCitzdGF0aWMg
aW50IHBpbl9wYWdlX3RhYmxlKHUzMiBtZm4sIHN0cnVjdCBkb21haW4gKmQpCit7CisJTk9U
X1lFVCgpOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgdW5waW5fcGFnZV90YWJs
ZSh1MzIgbWZuLCBzdHJ1Y3QgZG9tYWluICpkKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVy
biAwOworfQorCit2b2lkIGZyZWVfcGFnZV90eXBlKHN0cnVjdCBwYWdlX2luZm8gKnBhZ2Us
IHVuc2lnbmVkIGxvbmcgdHlwZSkKK3sKKwlOT1RfWUVUKCk7Cit9CisKK3ZvaWQgcHV0X3Bh
Z2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKQoreworCU5PVF9ZRVQoKTsKK30KKwor
CitpbnQgZ2V0X3BhZ2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCB1bnNpZ25lZCBs
b25nIHR5cGUpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7Cit9CisKK2ludCBkb19t
bXVleHRfb3AoWEVOX0dVRVNUX0hBTkRMRShtbXVleHRfb3BfdCkgdW9wcywgdW5zaWduZWQg
aW50IGNvdW50LAorCQkgWEVOX0dVRVNUX0hBTkRMRSh1aW50KSBwZG9uZSwgdW5zaWduZWQg
aW50IGZvcmVpZ25kb20pCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIC1FSU5WQUw7Cit9
CisKK2ludCBkb19tbXVfdXBkYXRlKFhFTl9HVUVTVF9IQU5ETEUobW11X3VwZGF0ZV90KSB1
cmVxcywKKwkJICB1bnNpZ25lZCBpbnQgY291bnQsIAorCQkgIFhFTl9HVUVTVF9IQU5ETEUo
dWludCkgcGRvbmUsCisJCSAgdW5zaWduZWQgaW50IGZvcmVpZ25kb20pCit7CisJTk9UX1lF
VCgpOworCisgICAgICAgIHJldHVybiAtRUlOVkFMOworfQorCitpbnQgZG9fdXBkYXRlX3Zh
X21hcHBpbmcodTMyIHZhLCB1MzIgZmxhZ3MsIHU2NCB2YWw2NCkKK3sKKwlOT1RfWUVUKCk7
CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKworbG9uZyBhcmNoX21lbW9yeV9vcChpbnQgb3As
IFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVy
biAtRUlOVkFMOworfQorCisKKworaW50IHN0ZWFsX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwg
c3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgdW5zaWduZWQgaW50IG1lbWZsYWdzKQoreworCU5P
VF9ZRVQoKTsKKworCXJldHVybiAtRUlOVkFMOworfQorCitpbnQgZG9uYXRlX3BhZ2Uoc3Ry
dWN0IGRvbWFpbiAqZCwgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgdW5zaWduZWQgaW50IG1l
bWZsYWdzKQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAtRUlOVkFMOworfQorCisKK3Vu
c2lnbmVkIGxvbmcgZG9tYWluX2dldF9tYXhpbXVtX2dwZm4oc3RydWN0IGRvbWFpbiAqZCkK
K3sKKwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMHhGRkZGRkZGRjsKK30KKworaW50IHBhZ2Vf
aXNfcmFtX3R5cGUodW5zaWduZWQgbG9uZyBtZm4sIHVuc2lnbmVkIGxvbmcgbWVtX3R5cGUp
Cit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIC1FSU5WQUw7Cit9CmRpZmYgLXIgZTcwMTQ2
MWIxMjUxIHhlbi9hcmNoL2FybS94ZW4vcDJtLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9wMm0uYwlGcmkg
RmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw0NCBAQAorLyoKKyAqIHAy
bS5jCisgKgorICogQ29weXJpZ2h0IChDKSAyMDA4LTIwMTEgU2Ftc3VuZyBFbGVjdHJvbmlj
cworICogICAgICAgICAgU2FuZy1idW0gU3VoICA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+Cisg
KiAgICAgICAgICBKYWVNaW4gUnl1ICAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqICAg
ICAgICAgIFN1bmdLd2FuIEhlbyAgPHNrLmhlb0BzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlz
IHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5k
L29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQ
dWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmli
dXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhP
VVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YK
KyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T
RS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFt
OyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJ
bmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMw
NyAgVVNBCisgKi8KKworI2luY2x1ZGUgPGFzbS9kb21haW4uaD4KKyNpbmNsdWRlIDxhc20v
cGFnZS5oPgorI2luY2x1ZGUgPGFzbS9wYWdpbmcuaD4KKyNpbmNsdWRlIDxhc20vcDJtLmg+
CisjaW5jbHVkZSA8eGVuL2V2ZW50Lmg+CisKK2ludCBwMm1fcG9kX2RlY3JlYXNlX3Jlc2Vy
dmF0aW9uKHN0cnVjdCBkb21haW4gKmQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHhlbl9wZm5fdCBncGZuLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25l
ZCBpbnQgb3JkZXIpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7Cit9CisKK2ludCBn
dWVzdF9waHlzbWFwX21hcmtfcG9wdWxhdGVfb25fZGVtYW5kKHN0cnVjdCBkb21haW4gKmQs
IHVuc2lnbmVkIGxvbmcgZ2ZuLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB1bnNpZ25lZCBpbnQgb3JkZXIpCit7CisJTk9UX1lFVCgpOworCisJcmV0dXJuIDA7
Cit9CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9hcmNoL2FybS94ZW4vcGNpLmMKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gv
YXJtL3hlbi9wY2kuYwlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCAr
MSw3NCBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogcGNpLmMKKyAqIAorICog
QXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBQQ0kgYWNjZXNzIGZ1bmN0aW9ucy4KKyAqLworCisj
aW5jbHVkZSA8eGVuL3NwaW5sb2NrLmg+CisjaW5jbHVkZSA8eGVuL3BjaS5oPgorI2luY2x1
ZGUgPGFzbS9pby5oPgorCitzdGF0aWMgREVGSU5FX1NQSU5MT0NLKHBjaV9jb25maWdfbG9j
ayk7CisKK3VpbnQzMl90IHBjaV9jb25mX3JlYWQodWludDMyX3QgY2Y4LCB1aW50OF90IG9m
ZnNldCwgdWludDhfdCBieXRlcykKK3sKKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOworICAg
IHVpbnQzMl90IHZhbHVlOworCisgICAgQlVHX09OKChvZmZzZXQgKyBieXRlcykgPiA0KTsK
KworICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwY2lfY29uZmlnX2xvY2ssIGZsYWdzKTsKKwor
ICAgIG91dGwoY2Y4LCAweGNmOCk7CisKKyAgICBzd2l0Y2ggKCBieXRlcyApCisgICAgewor
ICAgIGNhc2UgMToKKyAgICAgICAgdmFsdWUgPSBpbmIoMHhjZmMgKyBvZmZzZXQpOworICAg
ICAgICBicmVhazsKKyAgICBjYXNlIDI6CisgICAgICAgIHZhbHVlID0gaW53KDB4Y2ZjICsg
b2Zmc2V0KTsKKyAgICAgICAgYnJlYWs7CisgICAgY2FzZSA0OgorICAgICAgICB2YWx1ZSA9
IGlubCgweGNmYyArIG9mZnNldCk7CisgICAgICAgIGJyZWFrOworICAgIGRlZmF1bHQ6Cisg
ICAgICAgIHZhbHVlID0gMDsKKyAgICAgICAgQlVHKCk7CisgICAgfQorCisgICAgc3Bpbl91
bmxvY2tfaXJxcmVzdG9yZSgmcGNpX2NvbmZpZ19sb2NrLCBmbGFncyk7CisKKyAgICByZXR1
cm4gdmFsdWU7Cit9CisKK3ZvaWQgcGNpX2NvbmZfd3JpdGUodWludDMyX3QgY2Y4LCB1aW50
OF90IG9mZnNldCwgdWludDhfdCBieXRlcywgdWludDMyX3QgZGF0YSkKK3sKKyAgICB1bnNp
Z25lZCBsb25nIGZsYWdzOworCisgICAgQlVHX09OKChvZmZzZXQgKyBieXRlcykgPiA0KTsK
KworICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwY2lfY29uZmlnX2xvY2ssIGZsYWdzKTsKKwor
ICAgIG91dGwoY2Y4LCAweGNmOCk7CisKKyAgICBzd2l0Y2ggKCBieXRlcyApCisgICAgewor
ICAgIGNhc2UgMToKKyAgICAgICAgb3V0YigodWludDhfdClkYXRhLCAweGNmYyArIG9mZnNl
dCk7CisgICAgICAgIGJyZWFrOworICAgIGNhc2UgMjoKKyAgICAgICAgb3V0dygodWludDE2
X3QpZGF0YSwgMHhjZmMgKyBvZmZzZXQpOworICAgICAgICBicmVhazsKKyAgICBjYXNlIDQ6
CisgICAgICAgIG91dGwoZGF0YSwgMHhjZmMgKyBvZmZzZXQpOworICAgICAgICBicmVhazsK
KyAgICB9CisKKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwY2lfY29uZmlnX2xvY2ss
IGZsYWdzKTsKK30KKworCisjZGVmaW5lIFBDSV9DT05GX0FERFJFU1MoYnVzLCBkZXYsIGZ1
bmMsIHJlZykgXAorICAgICgweDgwMDAwMDAwIHwgKGJ1cyA8PCAxNikgfCAoZGV2IDw8IDEx
KSB8IChmdW5jIDw8IDgpIHwgKHJlZyAmIH4zKSkKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4
ZW4vYXJjaC9hcm0veGVuL3BlcmZtb24uYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3BlcmZtb24uYwlGcmkg
RmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyNiBAQAorI2luY2x1ZGUg
PHhlbi9ldmVudC5oPgorI2luY2x1ZGUgPHhlbi90eXBlcy5oPgorI2luY2x1ZGUgPHhlbi9l
cnJuby5oPgorI2luY2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL25taS5oPgor
I2luY2x1ZGUgPHhlbi9zdHJpbmcuaD4KKyNpbmNsdWRlIDx4ZW4vZGVsYXkuaD4KKyNpbmNs
dWRlIDx4ZW4veGVub3Byb2YuaD4KKyNpbmNsdWRlIDxwdWJsaWMveGVuLmg+CisKKworaW50
IHhlbm9wcm9mX2FyY2hfY291bnRlcihYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKK3sK
KwlOT1RfWUVUKCk7CisKKwlyZXR1cm4gMDsKK30KKworCitpbnQgeGVub3Byb2ZfYXJjaF9p
YnNfY291bnRlcihYRU5fR1VFU1RfSEFORExFKHZvaWQpIGFyZykKK3sKKwlOT1RfWUVUKCk7
CisKKwlyZXR1cm4gMDsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0v
eGVuL3NldHVwLmMKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9zZXR1cC5jCUZyaSBGZWIgMDMgMTY6MDc6MDMg
MjAxMiArMDkwMApAQCAtMCwwICsxLDY0IEBACisvKgorICogc2V0dXAuYworICoKKyAqIENv
cHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAg
IFNhbmctYnVtIFN1aCAgIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAJICAgIEph
ZW1pbiBSeXUgICAgIDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEpvb1lv
dW5nIEh3YW5nIDxqb295b3VuZy5od2FuZ0BzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29y
IG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMKKyAqIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBT
b2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRl
ZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQg
QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAq
IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g
IFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFp
bHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBp
ZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMu
LCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAg
VVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vaW5p
dC5oPgorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9tbS5oPgorI2lu
Y2x1ZGUgPHhlbi9jb21waWxlLmg+CisjaW5jbHVkZSA8eGVuL3N0cmluZy5oPgorI2luY2x1
ZGUgPHhlbi9saWIuaD4KKyNpbmNsdWRlIDx4ZW4vcHJlZW1wdC5oPgorI2luY2x1ZGUgPHB1
YmxpYy92ZXJzaW9uLmg+CisjaW5jbHVkZSA8cHVibGljL3NjaGVkLmg+CisKKworc3RydWN0
IGRvbWFpbiBfZG9tX3hlbiA9IHsKKyAgICAgICAgLnJlZmNudCA9IEFUT01JQ19JTklUKDEp
LAorICAgICAgICAuZG9tYWluX2lkID0gRE9NSURfWEVOLAorICAgICAgICAuZG9tYWluX2xv
Y2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQsCit9OworCitzdHJ1Y3QgZG9tYWluIF9kb21faW8g
PSB7CisgICAgICAgIC5yZWZjbnQgPSBBVE9NSUNfSU5JVCgxKSwKKyAgICAgICAgLmRvbWFp
bl9pZCA9IERPTUlEX0lPLAorICAgICAgICAuZG9tYWluX2xvY2sgPSBTUElOX0xPQ0tfVU5M
T0NLRUQsCit9OworCitzdHJ1Y3QgZG9tYWluIF9kb21fY293ID0geworICAgICAgICAucmVm
Y250ID0gQVRPTUlDX0lOSVQoMSksCisgICAgICAgIC5kb21haW5faWQgPSBET01JRF9DT1cs
CisgICAgICAgIC5kb21haW5fbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRCwKK307CisKK3N0
cnVjdCBkb21haW4gKmRvbV94ZW4gPSAmX2RvbV94ZW47CitzdHJ1Y3QgZG9tYWluICpkb21f
aW8gPSAmX2RvbV9pbzsKK3N0cnVjdCBkb21haW4gKmRvbV9jb3cgPSAmX2RvbV9jb3c7CisK
K3ZvaWQgYXJjaF9nZXRfeGVuX2NhcHMoeGVuX2NhcGFiaWxpdGllc19pbmZvX3QgKmluZm8p
Cit7Cit9CisKK2FzbWxpbmthZ2Ugdm9pZCBzdGFydF94ZW4odm9pZCkKK3sKK30KKwpkaWZm
IC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL3NodXRkb3duLmMKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2FyY2gvYXJt
L3hlbi9zaHV0ZG93bi5jCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCww
ICsxLDM4IEBACisvKgorICogc2h1dGRvd24uYworICoKKyAqIENvcHlyaWdodCAoQykgMjAw
OC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAgIFNhbmctYnVtIFN1aCA8
c2J1ay5zdWhAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBKYWVNaW4gUnl1ICAgPGptNzcu
cnl1QHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0
aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5z
ZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg
d2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJ
VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVy
YWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxk
IGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZy
ZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3Vp
dGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworCisjaW5jbHVkZSA8
eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8eGVuL2luaXQuaD4KKyNpbmNsdWRlIDx4ZW4vbGli
Lmg+CisjaW5jbHVkZSA8eGVuL3NodXRkb3duLmg+CisKK3ZvaWQgbWFjaGluZV9oYWx0KHZv
aWQpCit7CisJcHJpbnRrKCJtYWNoaW5lX2hhbHQgY2FsbGVkOiBzcGlubmluZy4uLi5cbiIp
OworCXdoaWxlKDEpOworfQorCit2b2lkIG1hY2hpbmVfcmVzdGFydCh1bnNpZ25lZCBpbnQg
ZGVsYXlfbWlsbGlzZWNzKQoreworCXByaW50aygibWFjaGluZV9yZXN0YXJ0IGNhbGxlZDog
c3Bpbm5pbmcuLi4uXG4iKTsKKwl3aGlsZSgxKTsKK30KKwpkaWZmIC1yIGU3MDE0NjFiMTI1
MSB4ZW4vYXJjaC9hcm0veGVuL3RpbWUuYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL3RpbWUuYwlGcmkgRmVi
IDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw4MyBAQAorLyoKKyAqIHRpbWUu
YyAKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDgtMjAxMSBTYW1zdW5nIEVsZWN0cm9uaWNz
IAorICogICAgICAgICAgU2FuZy1idW0gU3VoICAgIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4K
KyAqICAgICAgICAgIEpvb1lvdW5nIEh3YW5nICA8am9veW91bmcuaHdhbmdAc2Ftc3VuZy5j
b20+CisgKiAgICAgICAgICBKYWVtaW4gUnl1ICAgICAgPGptNzcucnl1QHNhbXN1bmcuY29t
PgorICogCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVk
IGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJv
Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVs
LAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxp
ZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBB
UlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVk
IGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdp
dGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisg
KiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9u
LCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2luY2x1ZGUgPHhlbi9pbml0Lmg+Cisj
aW5jbHVkZSA8eGVuL3RpbWUuaD4KKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4KKyNpbmNsdWRl
IDx4ZW4vZXZlbnQuaD4KKyNpbmNsdWRlIDx4ZW4vc29mdGlycS5oPgorI2luY2x1ZGUgPGFz
bS90eXBlcy5oPgorI2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+CisjaW5jbHVkZSA8YXNtL2Rp
djY0Lmg+CisjaW5jbHVkZSA8YXNtL3RpbWUuaD4KKwordm9pZCBzZW5kX3RpbWVyX2V2ZW50
KHN0cnVjdCB2Y3B1ICp2KQoreworCU5PVF9ZRVQoKTsKK30KKworaW50IHJlcHJvZ3JhbV90
aW1lcihzX3RpbWVfdCB0aW1lb3V0KQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAxOwor
fQorCit2b2lkIHNtcF9icm9hZGNhc3RfdGltZXIodm9pZCkKK3sKKwlOT1RfWUVUKCk7Cit9
CisKK3ZvaWQgdXBkYXRlX3ZjcHVfc3lzdGVtX3RpbWUoc3RydWN0IHZjcHUgKnYpCit7CisJ
Tk9UX1lFVCgpOworCisJcmV0dXJuOworfQorCit2b2lkIGRvX3NldHRpbWUodW5zaWduZWQg
bG9uZyBzZWNzLCB1bnNpZ25lZCBsb25nIG5zZWNzLCB1NjQgc3lzdGVtX3RpbWVfYmFzZSkK
K3sKKwlOT1RfWUVUKCk7Cit9CisKK3N0cnVjdCB0bSB3YWxsY2xvY2tfdGltZSh2b2lkKQor
eworCXJldHVybiBnbXRpbWUoMCk7Cit9CisKKworc190aW1lX3QgZ2V0X3NfdGltZSh2b2lk
KQoreworCU5PVF9ZRVQoKTsKKworCXJldHVybiAwOworfQorCit2b2lkIGRvbWFpbl9zZXRf
dGltZV9vZmZzZXQoc3RydWN0IGRvbWFpbiAqZCwgaW50MzJfdCB0aW1lX29mZnNldF9zZWNv
bmRzKQoreworCU5PVF9ZRVQoKTsKK30KKwordm9pZCB0aW1la2VlcGluZ19pbml0KHZvaWQp
Cit7CisJTk9UX1lFVCgpOworfQpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0v
eGVuL3RsYi5jCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3hlbi9hcmNoL2FybS94ZW4vdGxiLmMJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEy
ICswOTAwCkBAIC0wLDAgKzEsMjYgQEAKKy8qCisgKiB0bGIuYworICoKKyAqIENvcHlyaWdo
dCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqICAgICAgICAgIFNhbmct
YnVtIFN1aCA8c2J1ay5zdWhAc2Ftc3VuZy5jb20+CisgKiAgICAgICAgICBKYWVNaW4gUnl1
ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBp
dCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIg
b2YgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5k
YXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3Bl
IHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7
IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklM
SVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICog
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZ
b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUg
dG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ
bGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworI2lu
Y2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vaW5pdC5oPgorI2luY2x1ZGUg
PHhlbi9zY2hlZC5oPgorI2luY2x1ZGUgPHhlbi9zb2Z0aXJxLmg+CisKK3UzMiB0bGJmbHVz
aF9jbG9jayA9IDFVOwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vYXJjaC9hcm0veGVuL3hl
bi5sZHMuUwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi94ZW4vYXJjaC9hcm0veGVuL3hlbi5sZHMuUwlGcmkgRmViIDAzIDE2OjA3OjAzIDIw
MTIgKzA5MDAKQEAgLTAsMCArMSwxNTkgQEAKKy8qCisgKiB4ZW4ubGRzLlMKKyAqCisgKiBD
b3B5cmlnaHQgKEMpIDIwMDggU2Ftc3VuZyBFbGVjdHJvbmljcworICogICAgICAgICAgU2Fu
Zy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIENoYW5KdSBQ
YXJrICA8YmVzdHdvcmxkQHNhbXN1bmcuY29tPgorICogICAgICAgICAgSmFlTWluIFJ5dSAg
IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9m
IExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0
aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3
aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElU
WSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91
IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRv
IHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxh
Y2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2lu
Y2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vcGFnZS5oPgorCitPVVRQVVRf
QVJDSChhcm0pCitFTlRSWShzdGFydCkKKworU0VDVElPTlMKK3sKKwkuID0gMHhGRjAwODAw
MDsKKwlfc3RhcnQgPSAuOworCS50ZXh0IDogeworCQlfc3RleHQgPSAuOworCQkqKC5oZWFk
KQorCQkqKC50ZXh0KQorCQkqKC5maXh1cCkKKwkJKiguZ251Lndhcm5pbmcpCisJCV9ldGV4
dCA9IC47CisJfQorCisJLnJvZGF0YSA6IHsKKwkJKigucm9kYXRhKQorCQkqKC5yb2RhdGEu
KikKKwl9CisKKwkuID0gQUxJR04oMzIpOworCS5kYXRhLnJlYWRfbW9zdGx5IDogeworCQkv
KiBFeGNlcHRpb24gdGFibGUgKi8KKwkJX3NleHRhYmxlID0gLjsKKwkJX19zdGFydF9fX2V4
X3RhYmxlID0gLjsKKwkJKiguZXhfdGFibGUpCisJCV9fc3RvcF9fX2V4X3RhYmxlID0gLjsK
KworCQkvKiBQcmUtZXhjZXB0aW9uIHRhYmxlICovCisJCV9fc3RhcnRfX19wcmVfZXhfdGFi
bGUgPSAuOworCQkqKC5leF90YWJsZS5wcmUpCisJCV9fc3RvcF9fX3ByZV9leF90YWJsZSA9
IC47CisJCV9lZXh0YWJsZSA9IC47CisJCSooLmRhdGEucmVhZF9tb3N0bHkpCisJCSooLmRh
dGEucmVsLnJvKQorCQkqKC5kYXRhLnJlbC5yby4qKQorCX0gCisKKwkuID0gQUxJR04oUEFH
RV9TSVpFKTsKKwkuZGF0YSA6IHsKKwkJX3NkYXRhID0gLjsKKwkJKiguZGF0YSkKKwkJKigu
ZGF0YS5yZWwpCisJCSooLmRhdGEucmVsLiopCisJCV9lZGF0YSA9IC47CisJfQorCisJLiA9
IEFMSUdOKFBBR0VfU0laRSk7ICAgICAgICAgICAgIC8qIEluaXQgY29kZSBhbmQgZGF0YSAq
LworCV9faW5pdF9iZWdpbiA9IC47CisKKwkuaW5pdC50ZXh0IDogeworCQlfc2luaXR0ZXh0
ID0gLjsKKwkJKiguaW5pdC50ZXh0KSAKKwkJX2Vpbml0dGV4dCA9IC47CisJfQorCisJLmlu
aXQuZGF0YSA6IHsKKwkJX3Npbml0ZGF0YSA9IC47CisJCSooLmluaXQucm9kYXRhKQorCQkq
KC5pbml0LnJvZGFhdGEuc3RyKikKKwkJKiguaW5pdC5kYXRhKQorCQkqKC5pbml0LmRhdGEu
cmVsKQorCQkqKC5pbml0LmRhdGEucmVsLiopCisJCV9laW5pdGRhdGEgPSAuOworCX0KKwor
CS4gPSBBTElHTigzMik7CisJLmluaXQubWVtdGFibGUgOiB7CisJCV9zbWVtdGFibGUgPSAu
OworCQkqKC5pbml0Lm1lbXRhYmxlKQorCQkqKC5pbml0Lm1lbXRhYmxlLiopCisJCV9lbWVt
dGFibGUgPSAuOworCX0KKworCS4gPSBBTElHTigzMik7CisJLmluaXQuc2V0dXAgOiB7CisJ
CV9zaW5pdHNldHVwID0gLjsKKwkJX19zZXR1cF9zdGFydCA9IC47CisJCSooLmluaXQuc2V0
dXApIAorCQlfX3NldHVwX2VuZCA9IC47CisJCV9laW5pdHNldHVwID0gLjsKKwl9CisKKwku
aW5pdGNhbGwuaW5pdCA6IHsKKwkJX3Npbml0Y2FsbCA9IC47CisJCV9faW5pdGNhbGxfc3Rh
cnQgPSAuOworCQkqKC5pbml0Y2FsbHByZXNtcC5pbml0KQorCQlfX3ByZXNtcF9pbml0Y2Fs
bF9lbmQgPSAuOworCQkqKC5pbml0Y2FsbDEuaW5pdCkgCisJCV9faW5pdGNhbGxfZW5kID0g
LjsKKwkJX2Vpbml0Y2FsbCA9IC47CisJfQorCisJLnhzbV9pbml0Y2FsbC5pbml0IDogewor
CQlfc3hzbV9pbml0Y2FsbCA9IC47CisJCV9feHNtX2luaXRjYWxsX3N0YXJ0ID0gLjsKKwkJ
KigueHNtX2luaXRjYWxsLmluaXQpCisJCV9feHNtX2luaXRjYWxsX2VuZCA9IC47CisJCV9l
eHNtX2luaXRjYWxsID0gLjsKKwl9CisJX19pbml0X2VuZCA9IC47CisKKwkuID0gQUxJR04o
UEFHRV9TSVpFKTsKKworCS5ic3MgOiB7CisJCV9zYnNzID0gLjsJCS8qIEJTUyAqLworCQlf
X2Jzc19zdGFydCA9IC47CisJCSooLmJzcy5wYWdlX2FsaWduZWQpCisJCSooLmJzcy5zdGFj
a19hbGlnbmVkKQorCQkqKC5ic3MucGVyY3B1KQorCQkqKC5ic3MpCisJCV9fYnNzX2VuZCA9
IC47CisJCV9lYnNzID0gLjsKKwl9CisJX2VuZCA9IC4gOworCS8qIFNlY3Rpb25zIHRvIGJl
IGRpc2NhcmRlZCAqLworCisgIAkvRElTQ0FSRC8gOiB7CisgIAkJKigudGV4dC5leGl0KQor
CQkqKC5kYXRhLmV4aXQpCisJCSooLmV4aXRjYWxsLmV4aXQpCisJfQorCS8qIFN0YWJzIGRl
YnVnZ2luZyBzZWN0aW9ucy4gICovCisJLnN0YWIgMCA6IHsgKiguc3RhYikgfQorCS5zdGFi
c3RyIDAgOiB7ICooLnN0YWJzdHIpIH0KKwkuc3RhYi5leGNsIDAgOiB7ICooLnN0YWIuZXhj
bCkgfQorCS5zdGFiLmV4Y2xzdHIgMCA6IHsgKiguc3RhYi5leGNsc3RyKSB9CisJLnN0YWIu
aW5kZXggMCA6IHsgKiguc3RhYi5pbmRleCkgfQorCS5zdGFiLmluZGV4c3RyIDAgOiB7ICoo
LnN0YWIuaW5kZXhzdHIpIH0KKwkuY29tbWVudCAwIDogeyAqKC5jb21tZW50KSB9CisJCit9
CisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9hY3BpLmgKLS0t
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2lu
Y2x1ZGUvYXNtLWFybS9hY3BpLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBA
IC0wLDAgKzEsOCBAQAorI2lmbmRlZiBfX0FSTV9BQ1BJX0hfXworI2RlZmluZSBfX0FSTV9B
Q1BJX0hfXworCisjZGVmaW5lIENPTVBJTEVSX0RFUEVOREVOVF9JTlQ2NCAgIGxvbmcgbG9u
ZworI2RlZmluZSBDT01QSUxFUl9ERVBFTkRFTlRfVUlOVDY0ICB1bnNpZ25lZCBsb25nIGxv
bmcKKworI2VuZGlmIC8qIV9fQVJNX0FDUElfSF9fICovCisKZGlmZiAtciBlNzAxNDYxYjEy
NTEgeGVuL2luY2x1ZGUvYXNtLWFybS9hc20tbWFjcm9zLmgKLS0tIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9h
c20tbWFjcm9zLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEs
MTA2IEBACisjaWZuZGVmIF9fQVJNX0FTTV9NQUNST1NfSF9fCisjZGVmaW5lIF9fQVJNX0FT
TV9NQUNST1NfSF9fCisKKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CisKKyNpZmRlZiBfX0FT
U0VNQkxZX18KKy8qCisgKiBFbmRpYW4gaW5kZXBlbmRlbnQgbWFjcm9zIGZvciBzaGlmdGlu
ZyBieXRlcyB3aXRoaW4gcmVnaXN0ZXJzLgorICovCisjaWZuZGVmIF9fQVJNRUJfXworI2Rl
ZmluZSBwdWxsICAgICAgICAgICAgbHNyCisjZGVmaW5lIHB1c2ggICAgICAgICAgICBsc2wK
KyNkZWZpbmUgZ2V0X2J5dGVfMCAgICAgIGxzbCAjMAorI2RlZmluZSBnZXRfYnl0ZV8xICAg
ICAgbHNyICM4CisjZGVmaW5lIGdldF9ieXRlXzIgICAgICBsc3IgIzE2CisjZGVmaW5lIGdl
dF9ieXRlXzMgICAgICBsc3IgIzI0CisjZGVmaW5lIHB1dF9ieXRlXzAgICAgICBsc2wgIzAK
KyNkZWZpbmUgcHV0X2J5dGVfMSAgICAgIGxzbCAjOAorI2RlZmluZSBwdXRfYnl0ZV8yICAg
ICAgbHNsICMxNgorI2RlZmluZSBwdXRfYnl0ZV8zICAgICAgbHNsICMyNAorI2Vsc2UKKyNk
ZWZpbmUgcHVsbCAgICAgICAgICAgIGxzbAorI2RlZmluZSBwdXNoICAgICAgICAgICAgbHNy
CisjZGVmaW5lIGdldF9ieXRlXzAgICAgICBsc3IgIzI0CisjZGVmaW5lIGdldF9ieXRlXzEg
ICAgICBsc3IgIzE2CisjZGVmaW5lIGdldF9ieXRlXzIgICAgICBsc3IgIzgKKyNkZWZpbmUg
Z2V0X2J5dGVfMyAgICAgIGxzbCAjMAorI2RlZmluZSBwdXRfYnl0ZV8wICAgICAgbHNsICMy
NAorI2RlZmluZSBwdXRfYnl0ZV8xICAgICAgbHNsICMxNgorI2RlZmluZSBwdXRfYnl0ZV8y
ICAgICAgbHNsICM4CisjZGVmaW5lIHB1dF9ieXRlXzMgICAgICBsc2wgIzAKKyNlbmRpZgor
CisjZGVmaW5lIFBMRChjb2RlLi4uKQljb2RlCisKKyNkZWZpbmUgQ1RYVF9SMAkJMAorI2Rl
ZmluZSBDVFhUX1IxCQk0CisjZGVmaW5lIENUWFRfUjIJCTgKKyNkZWZpbmUgQ1RYVF9SMwkJ
MTIKKyNkZWZpbmUgQ1RYVF9SNAkJMTYKKyNkZWZpbmUgQ1RYVF9SNQkJMjAKKyNkZWZpbmUg
Q1RYVF9SNgkJMjQKKyNkZWZpbmUgQ1RYVF9SNwkJMjgKKyNkZWZpbmUgQ1RYVF9SOAkJMzIK
KyNkZWZpbmUgQ1RYVF9SOQkJMzYKKyNkZWZpbmUgQ1RYVF9SMTAJNDAKKyNkZWZpbmUgQ1RY
VF9SMTEJNDQKKyNkZWZpbmUgQ1RYVF9SMTIJNDgKKyNkZWZpbmUgQ1RYVF9VU1AJNTIKKyNk
ZWZpbmUgQ1RYVF9VTFIJNTYKKyNkZWZpbmUgQ1RYVF9TU1AJNjAKKyNkZWZpbmUgQ1RYVF9T
TFIJNjQKKyNkZWZpbmUgQ1RYVF9QQwkJNjgKKyNkZWZpbmUgQ1RYVF9TUFNSCTcyCisjZGVm
aW5lIENUWFRfRVhUUkEJNzYKKyNkZWZpbmUgQ1RYVF9GUkFNRV9TSVpFCTgwCisKKyNkZWZp
bmUgU1BGSVgoY29kZS4uLikJY29kZQorCisubWFjcm8gIGRpc2FibGVfaXJxLCB0ZW1wCisJ
bXNyCWNwc3JfYywgI1BTUl9JX0JJVCB8IFBTUl9NT0RFX1NWQworLmVuZG0KKworLm1hY3Jv
CWNjaQlyZAorCW1vdglccmQsICNTVEFDS19TSVpFCisJc3ViCVxyZCwgXHJkLCAjMQorCWJp
YwlccmQsIHIxMywgXHJkCisuZW5kbQorCisvKgorICogU2F2ZSB0aGUgY3VycmVudCBJUlEg
c3RhdGUgYW5kIGRpc2FibGUgSVJRcy4gIE5vdGUgdGhhdCB0aGlzIG1hY3JvCisgKiBhc3N1
bWVzIEZJUXMgYXJlIGVuYWJsZWQsIGFuZCB0aGF0IHRoZSBwcm9jZXNzb3IgaXMgaW4gU1ZD
IG1vZGUuCisgKi8KKy5tYWNybwlzYXZlX2FuZF9kaXNhYmxlX2lycXMsIG9sZGNwc3IsIHRl
bXAKKwltcnMJXG9sZGNwc3IsIGNwc3IKKwltb3YJXHRlbXAsICNQU1JfSV9CSVQgfCBQU1Jf
TU9ERV9TVkMKKwltc3IJY3Bzcl9jLCBcdGVtcAorLmVuZG0KKworLyoKKyAqIFJlc3RvcmUg
aW50ZXJydXB0IHN0YXRlIHByZXZpb3VzbHkgc3RvcmVkIGluIGEgcmVnaXN0ZXIuICBXZSBk
b24ndAorICogZ3VhcmFudGVlIHRoYXQgdGhpcyB3aWxsIHByZXNlcnZlIHRoZSBmbGFncy4K
KyAqLworLm1hY3JvCXJlc3RvcmVfaXJxcywgb2xkY3BzcgorCW1zcgljcHNyX2MsIFxvbGRj
cHNyCisuZW5kbQorCisjZGVmaW5lIFVTRVIoeC4uLikJCQkJXAorOTk5OToJeDsJCQkJCVwK
Kwkuc2VjdGlvbiAuZXh0YWJsZSwiYSI7CQlcCisJLmFsaWduCTM7CQkJCVwKKwkubG9uZwk5
OTk5Yiw5MDAxZjsJCQlcCisJLnByZXZpb3VzCisKKyNkZWZpbmUgX19BTElHTiAgICAgICAg
IC5hbGlnbiAwCisjZGVmaW5lIF9fQUxJR05fU1RSICAgICAiLmFsaWduIDAsIDB4OTAiCisK
KyNkZWZpbmUgQUxJR04gICAgICAgICAgIF9fQUxJR04KKyNkZWZpbmUgQUxJR05fU1RSICAg
ICAgIF9fQUxJR05fU1RSCisKKyNkZWZpbmUgRU5UUlkobmFtZSkgXAorICAuZ2xvYmFsIG5h
bWU7IFwKKyAgQUxJR047IFwKKyAgbmFtZToKKyNlbmRpZgorI2VuZGlmIC8qIF9fQVJNX0FT
TV9NQUNST1NfSF9fICovCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1h
cm0vYXRvbWljLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9hdG9taWMuaAlGcmkgRmViIDAzIDE2OjA3
OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxNzkgQEAKKyNpZm5kZWYgX19BUk1fQVRPTUlD
X0hfXworI2RlZmluZSBfX0FSTV9BVE9NSUNfSF9fCisKKyNpZm5kZWYgX19BU1NFTUJMWV9f
CisjZGVmaW5lIHJlYWRfYXRvbWljKHApIAkJCQkJCQlcCisoewkJCQkJCQkJCVwKKwl0eXBl
b2YoKnApIF9feDsJCQkJCQkJXAorCXN3aXRjaCAoIHNpemVvZigqcCkgKSB7CQkJCQkJXAor
CWNhc2UgMTogX194ID0gKHR5cGVvZigqcCkpYXRvbWljX3JlYWQ4KCh1aW50OF90ICopcCk7
IGJyZWFrOwlcCisJY2FzZSAyOiBfX3ggPSAodHlwZW9mKCpwKSlhdG9taWNfcmVhZDE2KCh1
aW50MTZfdCAqKXApOyBicmVhazsJXAorCWNhc2UgNDogX194ID0gKHR5cGVvZigqcCkpYXRv
bWljX3JlYWQzMigodWludDMyX3QgKilwKTsgYnJlYWs7CVwKKwljYXNlIDg6IF9feCA9ICh0
eXBlb2YoKnApKWF0b21pY19yZWFkNjQoKHVpbnQ2NF90ICopcCk7IGJyZWFrOwlcCisJZGVm
YXVsdDogX194ID0gMDsgX19iYWRfYXRvbWljX3NpemUoKTsgYnJlYWs7CQkJXAorCX0JCQkJ
CQkJCVwKKwlfX3g7CQkJCQkJCQlcCit9KQorCisjZGVmaW5lIHdyaXRlX2F0b21pYyhwLCB4
KSAJCQkJCQlcCisoewkJCQkJCQkJCVwKKwl0eXBlb2YoKnApIF9feCA9ICh4KTsJCQkJCQlc
CisJc3dpdGNoICggc2l6ZW9mKCpwKSApIHsJCQkJCQlcCisJY2FzZSAxOiBhdG9taWNfd3Jp
dGU4KCh1aW50OF90ICopcCwgKHVpbnQ4X3QpX194KTsgYnJlYWs7CVwKKwljYXNlIDI6IGF0
b21pY193cml0ZTE2KCh1aW50MTZfdCAqKXAsICh1aW50MTZfdClfX3gpOyBicmVhazsJXAor
CWNhc2UgNDogYXRvbWljX3dyaXRlMzIoKHVpbnQzMl90ICopcCwgKHVpbnQzMl90KV9feCk7
IGJyZWFrOwlcCisJY2FzZSA4OiBhdG9taWNfd3JpdGU2NCgodWludDY0X3QgKilwLCAodWlu
dDY0X3QpX194KTsgYnJlYWs7CVwKKwlkZWZhdWx0OiBfX2JhZF9hdG9taWNfc2l6ZSgpOyBi
cmVhazsJCQkJXAorCX0JCQkJCQkJCVwKKwlfX3g7CQkJCQkJCQlcCit9KQorCisKK3N0YXRp
YyBpbmxpbmUgdWludDhfdCBhdG9taWNfcmVhZDgoY29uc3Qgdm9sYXRpbGUgdWludDhfdCAq
YWRkcikKK3sKKwlyZXR1cm4gKCphZGRyKTsKK30KKworCitzdGF0aWMgaW5saW5lIHVpbnQx
Nl90IGF0b21pY19yZWFkMTYoY29uc3Qgdm9sYXRpbGUgdWludDE2X3QgKmFkZHIpCit7CisJ
cmV0dXJuICgqYWRkcik7Cit9CisKK3N0YXRpYyBpbmxpbmUgdWludDMyX3QgYXRvbWljX3Jl
YWQzMihjb25zdCB2b2xhdGlsZSB1aW50MzJfdCAqYWRkcikKK3sKKwlyZXR1cm4gKCphZGRy
KTsKK30KKworc3RhdGljIGlubGluZSB2b2lkIGF0b21pY193cml0ZTgodm9sYXRpbGUgdWlu
dDhfdCAqYWRkciwgdWludDhfdCB2YWwpCit7CisJKCphZGRyKSA9IHZhbDsKK30KKworc3Rh
dGljIGlubGluZSB2b2lkIGF0b21pY193cml0ZTE2KHZvbGF0aWxlIHVpbnQxNl90ICphZGRy
LCB1aW50MTZfdCB2YWwpCit7CisJKCphZGRyKSA9IHZhbDsKK30KKworc3RhdGljIGlubGlu
ZSB2b2lkIGF0b21pY193cml0ZTMyKHZvbGF0aWxlIHVpbnQzMl90ICphZGRyLCB1aW50MzJf
dCB2YWwpCit7CisJKCphZGRyKSA9IHZhbDsKK30KKworCit0eXBlZGVmIHN0cnVjdCB7CisJ
dm9sYXRpbGUgaW50IGNvdW50ZXI7Cit9IGF0b21pY190OworCisKKyNkZWZpbmUgQVRPTUlD
X0lOSVQoaSkJCXsgKGkpIH0KKworI2RlZmluZSBhdG9taWNfcmVhZCh2KQkJKCh2KS0+Y291
bnRlcikKKworc3RhdGljIGlubGluZSB2b2lkIGF0b21pY19zZXQoYXRvbWljX3QgKnYsIGlu
dCBpKQoreworCXVuc2lnbmVkIGxvbmcgdG1wOworCisJX19hc21fXyBfX3ZvbGF0aWxlX18o
IkAgYXRvbWljX3NldFxuIgorIjE6ICAgICBsZHJleCAgICUwLCBbJTFdXG4iCisiICAgICAg
IHN0cmV4ICAgJTAsICUyLCBbJTFdXG4iCisiICAgICAgIHRlcSAgICAgJTAsICMwXG4iCisi
ICAgICAgIGJuZSAgICAgMWIiCisJOiAiPSZyIiAodG1wKQorCTogInIiICgmdi0+Y291bnRl
ciksICJyIiAoaSkKKwk6ICJjYyIpOworfQorCitzdGF0aWMgaW5saW5lIGludCBhdG9taWNf
YWRkX3JldHVybihpbnQgaSwgYXRvbWljX3QgKnYpCit7CisJdW5zaWduZWQgbG9uZyB0bXA7
CisJaW50IHJlc3VsdDsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKCJAIGF0b21pY19hZGRf
cmV0dXJuXG4iCisiMTogICAgIGxkcmV4ICAgJTAsIFslMl1cbiIKKyIgICAgICAgYWRkICAg
ICAlMCwgJTAsICUzXG4iCisiICAgICAgIHN0cmV4ICAgJTEsICUwLCBbJTJdXG4iCisiICAg
ICAgIHRlcSAgICAgJTEsICMwXG4iCisiICAgICAgIGJuZSAgICAgMWIiCisJOiAiPSZyIiAo
cmVzdWx0KSwgIj0mciIgKHRtcCkKKwk6ICJyIiAoJnYtPmNvdW50ZXIpLCAiSXIiIChpKQor
CTogImNjIik7CisKKwlyZXR1cm4gcmVzdWx0OworfQorCitzdGF0aWMgaW5saW5lIGludCBh
dG9taWNfc3ViX3JldHVybihpbnQgaSwgYXRvbWljX3QgKnYpCit7CisJdW5zaWduZWQgbG9u
ZyB0bXA7CisJaW50IHJlc3VsdDsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKCJAIGF0b21p
Y19zdWJfcmV0dXJuXG4iCisiMTogICAgIGxkcmV4ICAgJTAsIFslMl1cbiIKKyIgICAgICAg
c3ViICAgICAlMCwgJTAsICUzXG4iCisiICAgICAgIHN0cmV4ICAgJTEsICUwLCBbJTJdXG4i
CisiICAgICAgIHRlcSAgICAgJTEsICMwXG4iCisiICAgICAgIGJuZSAgICAgMWIiCisJOiAi
PSZyIiAocmVzdWx0KSwgIj0mciIgKHRtcCkKKwk6ICJyIiAoJnYtPmNvdW50ZXIpLCAiSXIi
IChpKQorCTogImNjIik7CisKKwlyZXR1cm4gcmVzdWx0OworfQorCisKK3N0YXRpYyBpbmxp
bmUgdm9pZCBhdG9taWNfY2xlYXJfbWFzayh1bnNpZ25lZCBsb25nIG1hc2ssIHVuc2lnbmVk
IGxvbmcgKmFkZHIpCit7CisJdW5zaWduZWQgbG9uZyB0bXAsIHRtcDI7CisKKwlfX2FzbV9f
IF9fdm9sYXRpbGVfXygiQCBhdG9taWNfY2xlYXJfbWFza1xuIgorIjE6ICAgICBsZHJleCAg
ICUwLCBbJTJdXG4iCisiICAgICAgIGJpYyAgICAgJTAsICUwLCAlM1xuIgorIiAgICAgICBz
dHJleCAgICUxLCAlMCwgWyUyXVxuIgorIiAgICAgICB0ZXEgICAgICUxLCAjMFxuIgorIiAg
ICAgICBibmUgICAgIDFiIgorCTogIj0mciIgKHRtcCksICI9JnIiICh0bXAyKQorCTogInIi
IChhZGRyKSwgIklyIiAobWFzaykKKwk6ICJjYyIpOworfQorCitzdGF0aWMgaW5saW5lIGF0
b21pY190IGF0b21pY19jbXB4Y2hnKGF0b21pY190ICpwdHIsIGF0b21pY190IG9sZCwgYXRv
bWljX3QgbmV3KQoreworCWF0b21pY190IG9sZHZhbCwgcmVzOworCisJZG8geworCQlfX2Fz
bV9fIF9fdm9sYXRpbGVfXygiQCBhdG9taWNfY21weGNoZ1xuIgorCQkibGRyZXggICUxLCBb
JTJdXG4iCisJCSJtb3YgICAgJTAsICMwXG4iCisJCSJ0ZXEgICAgJTEsICUzXG4iCisJCSJz
dHJleGVxICUwLCAlNCwgWyUyXVxuIgorCQk6ICI9JnIiIChyZXMuY291bnRlciksICI9JnIi
IChvbGR2YWwuY291bnRlcikKKwkJOiAiciIgKCZwdHItPmNvdW50ZXIpLCAiSXIiIChvbGQu
Y291bnRlciksICJyIiAobmV3LmNvdW50ZXIpCisJCTogImNjIik7CisJfSB3aGlsZSAocmVz
LmNvdW50ZXIpOworCisJcmV0dXJuIG9sZHZhbDsKK30KKworI2RlZmluZSBfYXRvbWljX3Jl
YWQodikJCWF0b21pY19yZWFkKCZ2KQorI2RlZmluZSBfYXRvbWljX3NldCh2LGkpCWF0b21p
Y19zZXQoJnYsaSkKKworI2RlZmluZSBhdG9taWNfYWRkKGksIHYpCSh2b2lkKSBhdG9taWNf
YWRkX3JldHVybihpLCB2KQorI2RlZmluZSBhdG9taWNfaW5jKHYpCQkodm9pZCkgYXRvbWlj
X2FkZF9yZXR1cm4oMSwgdikKKyNkZWZpbmUgYXRvbWljX3N1YihpLCB2KQkodm9pZCkgYXRv
bWljX3N1Yl9yZXR1cm4oaSwgdikKKyNkZWZpbmUgYXRvbWljX2RlYyh2KQkJKHZvaWQpIGF0
b21pY19zdWJfcmV0dXJuKDEsIHYpCisKKyNkZWZpbmUgYXRvbWljX2luY19hbmRfdGVzdCh2
KQkoYXRvbWljX2FkZF9yZXR1cm4oMSwgdikgPT0gMCkKKyNkZWZpbmUgYXRvbWljX2RlY19h
bmRfdGVzdCh2KQkoYXRvbWljX3N1Yl9yZXR1cm4oMSwgdikgPT0gMCkKKyNkZWZpbmUgYXRv
bWljX2luY19yZXR1cm4odikgICAgKGF0b21pY19hZGRfcmV0dXJuKDEsIHYpKQorI2RlZmlu
ZSBhdG9taWNfZGVjX3JldHVybih2KSAgICAoYXRvbWljX3N1Yl9yZXR1cm4oMSwgdikpCisK
KyNkZWZpbmUgYXRvbWljX2FkZF9uZWdhdGl2ZShpLHYpIChhdG9taWNfYWRkX3JldHVybihp
LCB2KSA8IDApCisKK3N0YXRpYyBpbmxpbmUgYXRvbWljX3QgYXRvbWljX2NvbXBhcmVhbmRz
d2FwKGF0b21pY190IG9sZCwgYXRvbWljX3QgbmV3LCBhdG9taWNfdCAqdikKK3sKKyAgICAg
ICAgYXRvbWljX3QgcmM7CisgICAgICAgIHJjID0gYXRvbWljX2NtcHhjaGcoIChhdG9taWNf
dCAqKXYsIG9sZCwgbmV3KTsKKyAgICAgICAgcmV0dXJuIHJjOworfQorI2VuZGlmIC8qIV9f
QVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIV9fQVJNX0FUT01JQ19IX18gKi8KZGlmZiAtciBl
NzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9iaXRvcHMuaAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
YXJtL2JpdG9wcy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsx
LDE5MyBAQAorI2lmbmRlZiBfX0FSTV9CSVRPUFNfSF9fCisjZGVmaW5lIF9fQVJNX0JJVE9Q
U19IX18KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDxhc20vc3lzdGVt
Lmg+CisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCitzdGF0aWMgaW5saW5lIHZvaWQgYXRvbWlj
X3NldF9iaXQodW5zaWduZWQgaW50IGJpdCwgdm9sYXRpbGUgdW5zaWduZWQgbG9uZyAqcCkK
K3sKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCXVuc2lnbmVkIGxvbmcgbWFzayA9IDFVTCA8
PCAoYml0ICYgMzEpOworCisJcCArPSBiaXQgPj4gNTsKKworCWxvY2FsX2lycV9zYXZlKGZs
YWdzKTsKKwkqcCB8PSBtYXNrOworCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKK30KKwor
c3RhdGljIGlubGluZSB2b2lkIGF0b21pY19jbGVhcl9iaXQodW5zaWduZWQgaW50IGJpdCwg
dm9sYXRpbGUgdW5zaWduZWQgbG9uZyAqcCkKK3sKKwl1bnNpZ25lZCBsb25nIGZsYWdzOwor
CXVuc2lnbmVkIGxvbmcgbWFzayA9IDFVTCA8PCAoYml0ICYgMzEpOworCisJcCArPSBiaXQg
Pj4gNTsKKworCWxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKwkqcCAmPSB+bWFzazsKKwlsb2Nh
bF9pcnFfcmVzdG9yZShmbGFncyk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBhdG9taWNf
Y2hhbmdlX2JpdCh1bnNpZ25lZCBpbnQgYml0LCB2b2xhdGlsZSB1bnNpZ25lZCBsb25nICpw
KQoreworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisJdW5zaWduZWQgbG9uZyBtYXNrID0gMVVM
IDw8IChiaXQgJiAzMSk7CisKKwlwICs9IGJpdCA+PiA1OworCisJbG9jYWxfaXJxX3NhdmUo
ZmxhZ3MpOworCSpwIF49IG1hc2s7CisJbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOworfQor
CitzdGF0aWMgaW5saW5lIGludCBhdG9taWNfdGVzdF9hbmRfc2V0X2JpdCh1bnNpZ25lZCBp
bnQgYml0LCB2b2xhdGlsZSB1bnNpZ25lZCBsb25nICpwKQoreworCXVuc2lnbmVkIGxvbmcg
ZmxhZ3M7CisJdW5zaWduZWQgaW50IHJlczsKKwl1bnNpZ25lZCBsb25nIG1hc2sgPSAxVUwg
PDwgKGJpdCAmIDMxKTsKKworCXAgKz0gYml0ID4+IDU7CisKKwlsb2NhbF9pcnFfc2F2ZShm
bGFncyk7CisJcmVzID0gKnA7CisJKnAgPSByZXMgfCBtYXNrOworCWxvY2FsX2lycV9yZXN0
b3JlKGZsYWdzKTsKKworCXJldHVybiByZXMgJiBtYXNrOworfQorCitzdGF0aWMgaW5saW5l
IGludCBhdG9taWNfdGVzdF9hbmRfY2xlYXJfYml0KHVuc2lnbmVkIGludCBiaXQsIHZvbGF0
aWxlIHVuc2lnbmVkIGxvbmcgKnApCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwl1bnNp
Z25lZCBpbnQgcmVzOworCXVuc2lnbmVkIGxvbmcgbWFzayA9IDFVTCA8PCAoYml0ICYgMzEp
OworCisJcCArPSBiaXQgPj4gNTsKKworCWxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKwlyZXMg
PSAqcDsKKwkqcCA9IHJlcyAmIH5tYXNrOworCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsK
KworCXJldHVybiByZXMgJiBtYXNrOworfQorCitzdGF0aWMgaW5saW5lIGludCBhdG9taWNf
dGVzdF9hbmRfY2hhbmdlX2JpdCh1bnNpZ25lZCBpbnQgYml0LCB2b2xhdGlsZSB1bnNpZ25l
ZCBsb25nICpwKQoreworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisJdW5zaWduZWQgaW50IHJl
czsKKwl1bnNpZ25lZCBsb25nIG1hc2sgPSAxVUwgPDwgKGJpdCAmIDMxKTsKKworCXAgKz0g
Yml0ID4+IDU7CisKKwlsb2NhbF9pcnFfc2F2ZShmbGFncyk7CisJcmVzID0gKnA7CisJKnAg
PSByZXMgXiBtYXNrOworCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKKworCXJldHVybiBy
ZXMgJiBtYXNrOworfQorCisvKgorICogTm93IHRoZSBub24tYXRvbWljIHZhcmlhbnRzLiAg
V2UgbGV0IHRoZSBjb21waWxlciBoYW5kbGUgYWxsCisgKiBvcHRpbWlzYXRpb25zIGZvciB0
aGVzZS4gIFRoZXNlIGFyZSBhbGwgX25hdGl2ZV8gZW5kaWFuLgorICovCitzdGF0aWMgaW5s
aW5lIHZvaWQgc2V0X2JpdChpbnQgbnIsIHZvbGF0aWxlIHZvaWQgKnApCit7CisJdm9sYXRp
bGUgdW5zaWduZWQgbG9uZyAqbSA9ICh1bnNpZ25lZCBsb25nICopcDsKKworCW1bbnIgPj4g
NV0gfD0gKDFVTCA8PCAobnIgJiAzMSkpOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgY2xl
YXJfYml0KGludCBuciwgdm9sYXRpbGUgdm9pZCAqcCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25l
ZCBsb25nICptID0gKHVuc2lnbmVkIGxvbmcgKilwOworCisJbVtuciA+PiA1XSAmPSB+KDFV
TCA8PCAobnIgJiAzMSkpOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgY2hhbmdlX2JpdChp
bnQgbnIsIHZvbGF0aWxlIHZvaWQgKnApCit7CisJdm9sYXRpbGUgdW5zaWduZWQgbG9uZyAq
bSA9ICh1bnNpZ25lZCBsb25nICopcDsKKworCW1bbnIgPj4gNV0gXj0gKDFVTCA8PCAobnIg
JiAzMSkpOworfQorCitzdGF0aWMgaW5saW5lIGludCB0ZXN0X2FuZF9zZXRfYml0KGludCBu
ciwgdm9sYXRpbGUgdm9pZCAqcCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25lZCBsb25nICptID0g
KHVuc2lnbmVkIGxvbmcgKilwOworCXVuc2lnbmVkIGxvbmcgb2xkdmFsLCBtYXNrID0gMVVM
IDw8IChuciAmIDMxKTsKKworCW0gKz0gbnIgPj4gNTsKKworCW9sZHZhbCA9ICptOworCSpt
ID0gb2xkdmFsIHwgbWFzazsKKwlyZXR1cm4gb2xkdmFsICYgbWFzazsKK30KKworc3RhdGlj
IGlubGluZSBpbnQgdGVzdF9hbmRfY2xlYXJfYml0KGludCBuciwgdm9sYXRpbGUgdm9pZCAq
cCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25lZCBsb25nICptID0gKHVuc2lnbmVkIGxvbmcgKilw
OworCXVuc2lnbmVkIGxvbmcgb2xkdmFsLCBtYXNrID0gMVVMIDw8IChuciAmIDMxKTsKKwor
CW0gKz0gbnIgPj4gNTsKKworCW9sZHZhbCA9ICptOworCSptID0gb2xkdmFsICYgfm1hc2s7
CisJcmV0dXJuIG9sZHZhbCAmIG1hc2s7Cit9CisKK3N0YXRpYyBpbmxpbmUgaW50IHRlc3Rf
YW5kX2NoYW5nZV9iaXQoaW50IG5yLCB2b2xhdGlsZSB2b2lkICpwKQoreworCXZvbGF0aWxl
IHVuc2lnbmVkIGxvbmcgKm0gPSAodW5zaWduZWQgbG9uZyAqKXA7CisJdW5zaWduZWQgbG9u
ZyBvbGR2YWwsIG1hc2sgPSAxVUwgPDwgKG5yICYgMzEpOworCisJbSArPSBuciA+PiA1Owor
CisJb2xkdmFsID0gKm07CisJKm0gPSBvbGR2YWwgXiBtYXNrOworCXJldHVybiBvbGR2YWwg
JiBtYXNrOworfQorCisvKgorICogVGhpcyByb3V0aW5lIGRvZXNuJ3QgbmVlZCB0byBiZSBh
dG9taWMuCisgKi8KK3N0YXRpYyBpbmxpbmUgaW50IHRlc3RfYml0KGludCBuciwgY29uc3Qg
dm9sYXRpbGUgdm9pZCAqcCkKK3sKKwl2b2xhdGlsZSB1bnNpZ25lZCBsb25nICptID0gKHVu
c2lnbmVkIGxvbmcgKilwOworCisJcmV0dXJuIChtW25yID4+IDVdID4+IChuciAmIDMxKSkg
JiAxVUw7Cit9CisKK2V4dGVybiBpbnQgX2ZpbmRfZmlyc3RfemVyb19iaXQoY29uc3Qgdm9p
ZCAqcCwgaW50IHN6KTsKK2V4dGVybiBpbnQgX2ZpbmRfbmV4dF96ZXJvX2JpdChjb25zdCB2
b2lkICpwLCBpbnQgc3osIGludCBvZmZzZXQpOworZXh0ZXJuIGludCBfZmluZF9maXJzdF9i
aXQoY29uc3Qgdm9pZCAqcCwgaW50IHN6KTsKK2V4dGVybiBpbnQgX2ZpbmRfbmV4dF9iaXQo
Y29uc3Qgdm9pZCAqcCwgaW50IHN6LCBpbnQgb2Zmc2V0KTsKKworI2RlZmluZSBmaW5kX2Zp
cnN0X3plcm9fYml0KHAsc3opCV9maW5kX2ZpcnN0X3plcm9fYml0KHAsc3opCisjZGVmaW5l
IGZpbmRfbmV4dF96ZXJvX2JpdChwLHN6LG9mZikJX2ZpbmRfbmV4dF96ZXJvX2JpdChwLHN6
LG9mZikKKyNkZWZpbmUgZmluZF9maXJzdF9iaXQocCxzeikJCV9maW5kX2ZpcnN0X2JpdChw
LHN6KQorI2RlZmluZSBmaW5kX25leHRfYml0KHAsc3osb2ZmKQkJX2ZpbmRfbmV4dF9iaXQo
cCxzeixvZmYpCisjZGVmaW5lIGZpbmRfZmlyc3Rfc2V0X2JpdCh3b3JkKQkoZmZzKHdvcmQp
LTEpCisjZGVmaW5lIFdPUkRfQklUT0ZGX1RPX0xFKHgpCQkoKHgpKQorCisjZGVmaW5lIF9f
dGVzdF9hbmRfc2V0X2JpdChuciwgYWRkcikJdGVzdF9hbmRfc2V0X2JpdChuciwgYWRkcikK
Kworc3RhdGljIF9faW5saW5lX18gaW50IGdlbmVyaWNfZmxzKGludCB4KTsKKyNkZWZpbmUg
ZmxzKHgpIFwKKwkoIF9fYnVpbHRpbl9jb25zdGFudF9wKHgpID8gZ2VuZXJpY19mbHMoeCkg
OiBcCisJICAoeyBpbnQgX19yOyBhc20oImNselx0JTAsICUxIiA6ICI9ciIoX19yKSA6ICJy
Iih4KSA6ICJjYyIpOyAzMi1fX3I7IH0pICkKKyNkZWZpbmUgZmZzKHgpCQkoeyB1bnNpZ25l
ZCBsb25nIF9fdCA9ICh4KTsgZmxzKF9fdCAmIC1fX3QpOyB9KQorI2RlZmluZSBfX2Zmcyh4
KQkoZmZzKHgpIC0gMSkKKyNkZWZpbmUgZmZ6KHgpCQlfX2Zmcyggfih4KSApCisvKgorICog
aHdlaWdodE46IHJldHVybnMgdGhlIGhhbW1pbmcgd2VpZ2h0IChpLmUuIHRoZSBudW1iZXIK
KyAqIG9mIGJpdHMgc2V0KSBvZiBhIE4tYml0IHdvcmQKKyAqLworCisjZGVmaW5lIGh3ZWln
aHQzMih4KSBnZW5lcmljX2h3ZWlnaHQzMih4KQorI2RlZmluZSBod2VpZ2h0MTYoeCkgZ2Vu
ZXJpY19od2VpZ2h0MTYoeCkKKyNkZWZpbmUgaHdlaWdodDgoeCkgZ2VuZXJpY19od2VpZ2h0
OCh4KQorI2VuZGlmIC8qIV9fQVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIV9fQVJNX0JJVE9Q
U19IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9idWcu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL2J1Zy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDMyIEBACisjaWZuZGVmIF9fQVJNX0JVR19IX18KKyNkZWZpbmUgX19B
Uk1fQlVHX0hfXworCisjaWZuZGVmIF9fQVNTRU1CTFlfXworI2RlZmluZSBCVUcoKQkJCQkJ
CQlcCisJZG8gewkJCQkJCQlcCisJCXByaW50aygiQlVHIGF0ICVzOiVkXG4iLCBfX0ZJTEVf
XywgX19MSU5FX18pOwlcCisJCXdoaWxlKDEpOwkJCQkJXAorCX0gd2hpbGUgKCAwICkKKwor
I2RlZmluZSBQQU5JQyhtc2cpCQkJCQkJXAorCWRvIHsJCQkJCQkJXAorCQlwcmludGsoIlBh
bmljIGF0ICVzOiVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18pOyBcCisJCXdoaWxlKDEpOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKwl9d2hpbGUgKDApCisKKyNkZWZp
bmUgV0FSTigpCQkJCQkJCVwKKwlkbyB7CQkJCQkJCVwKKwkJcHJpbnRrKCJXQVJOSU5HIGF0
ICVzOiVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18pOwlcCisJCXdoaWxlKDEpOwkJCQkJXAor
CX0gd2hpbGUgKCAwICkKKworCisjZGVmaW5lIE5PVF9ZRVQoKQkJCQkJCVwKKwlkbyB7CQkJ
CQkJCVwKKwkJcHJpbnRrKCJOT1QgWUVUICVzOiVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18p
OwlcCisJfSB3aGlsZSAoMCkKKwordm9pZCBkdW1wX2V4ZWN1dGlvbl9zdGF0ZSh2b2lkKTsK
KyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLworI2VuZGlmIC8qIV9fQVJNX0JVR19IX18qLwor
CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vYnl0ZW9yZGVyLmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9ieXRlb3JkZXIuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSw5IEBACisjaWZuZGVmIF9fQVJNX0JZVEVPUkRFUl9IX18KKyNk
ZWZpbmUgX19BUk1fQllURU9SREVSX0hfXworCisjZGVmaW5lIF9fQllURU9SREVSX0hBU19V
NjRfXworCisjaW5jbHVkZSA8eGVuL2J5dGVvcmRlci9saXR0bGVfZW5kaWFuLmg+CisKKwor
I2VuZGlmIC8qIF9fQVJNX0JZVEVPUkRFUl9IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEg
eGVuL2luY2x1ZGUvYXNtLWFybS9jYWNoZS5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vY2FjaGUuaAlG
cmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMSBAQAorI2lmbmRl
ZiBfX0FSTV9DQUNIRV9IX18KKyNkZWZpbmUgX19BUk1fQ0FDSEVfSF9fCisKKyNpZm5kZWYg
TDFfQ0FDSEVfQllURVMKKyNkZWZpbmUgTDFfQ0FDSEVfQllURVMgICAgICAgICAgMzIKKyNl
bmRpZgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworI2RlZmluZSBfX3JlYWRfbW9zdGx5IF9f
YXR0cmlidXRlX18oKF9fc2VjdGlvbl9fKCIuZGF0YS5yZWFkX21vc3RseSIpKSkKKyNlbmRp
ZiAvKiFfX0FTU0VNQkxZX18gKi8KKyNlbmRpZiAvKiFfX0FSTV9DQUNIRV9IX18gKi8KZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9jb25maWcuaAotLS0gL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVk
ZS9hc20tYXJtL2NvbmZpZy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAt
MCwwICsxLDYxIEBACisjaWZuZGVmIF9fQVJNX0NPTkZJR19IX18KKyNkZWZpbmUgX19BUk1f
Q09ORklHX0hfXworCisjaW5jbHVkZSA8YXNtL2FyY2gvY29uZmlnLmg+CisKKyNpZm5kZWYg
TUFYX0hWTV9WQ1BVUworI2RlZmluZSBNQVhfSFZNX1ZDUFVTCQkxCisjZW5kaWYKKworI2Rl
ZmluZSBNQVhfVklSVF9DUFVTCQlYRU5fTEVHQUNZX01BWF9WQ1BVUworI2RlZmluZSBDT01Q
QVRfTEVHQUNZX01BWF9WQ1BVUyBYRU5fTEVHQUNZX01BWF9WQ1BVUworCisjaWZuZGVmIE1B
WF9QSFlTX0NQVVMKKyNkZWZpbmUgTUFYX1BIWVNfQ1BVUwkJMQorI2VuZGlmCisKKyNkZWZp
bmUgTlJfQ1BVUwkJCU1BWF9QSFlTX0NQVVMKKworI2RlZmluZSBFTEZTSVpFCQkJMzIKKwor
I2lmbmRlZiBYRU5fUEhZU19TSVpFCisjZGVmaW5lIFhFTl9QSFlTX1NJWkUJCSgweEYwMDAw
MCkKKyNlbmRpZgorCisKKyNpZiAoTUFYX1BIWVNfQ1BVUyA+IDEpCisjZGVmaW5lIENPTkZJ
R19TTVAJCTEKKyNkZWZpbmUgU01QCQkJMQorI2VuZGlmCisKKyNkZWZpbmUgU1RBQ0tfT1JE
RVIJCTAKKyNkZWZpbmUgU1RBQ0tfU0laRQkJKFBBR0VfU0laRSA8PCBTVEFDS19PUkRFUikK
KworI2lmbmRlZiBOREVCVUcKKyMgZGVmaW5lIE1FTU9SWV9HVUFSRAorI2VuZGlmCisKKwor
I2RlZmluZSBzdXBlcnZpc29yX21vZGVfa2VybmVsCSgwKQorCisjZGVmaW5lIEhZUEVSVklT
T1JfVklSVF9TVEFSVAkoMHhGQzAwMDAwMCkKKyNkZWZpbmUgWEVOX1ZJUlRfU1RBUlQJCSgw
eEZGMDAwMDAwKQorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworCisjZGVmaW5lIE9QVF9DT05T
T0xFX1NUUgkJImNvbTEiCisKKyNpZmRlZiBfX2NwbHVzcGx1cworI2RlZmluZSBDUFBfQVNN
TElOS0FHRSBleHRlcm4gIkMiCisjZWxzZQorI2RlZmluZSBDUFBfQVNNTElOS0FHRQorI2Vu
ZGlmCisKKyNpZm5kZWYgYXNtbGlua2FnZQorI2RlZmluZSBhc21saW5rYWdlIENQUF9BU01M
SU5LQUdFCisjZW5kaWYKKyNlbmRpZiAvKiAhX19BU1NFTUJMWV9fICovCisjZW5kaWYgLyog
IV9fQVJNX0NPTkZJR19IX18qLworCisKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5j
bHVkZS9hc20tYXJtL2NwdS1kb21haW4uaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2NwdS1kb21haW4u
aAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwzOSBAQAorI2lm
bmRlZiBfX0FSTV9DUFVfRE9NQUlOX0hfXworI2RlZmluZSBfX0FSTV9DUFVfRE9NQUlOX0hf
XworCisvKgorICogRG9tYWluIElECisgKi8KKyNkZWZpbmUgRE9NQUlOX1NWQwkJMAorI2Rl
ZmluZSBET01BSU5fSU8JCTIKKyNkZWZpbmUgRE9NQUlOX1VTUgkJMQorI2RlZmluZSBET01B
SU5fSFlQCQkxNQorCisvKgorICogRG9tYWluIHR5cGVzCisgKi8KKyNkZWZpbmUgRE9NQUlO
X05PQUNDRVNTCQkwCisjZGVmaW5lIERPTUFJTl9DTElFTlQJCTEKKyNkZWZpbmUgRE9NQUlO
X01BTkFHRVIJCTMKKworI2RlZmluZSBET01BSU5fVkFMVUUoZG9tLHR5cGUpCSgodHlwZSkg
PDwgKDIgKiAoZG9tKSkpCisKKyNkZWZpbmUgREFDUl9TVEFUX0hZUAkJCQkJXAorCShET01B
SU5fVkFMVUUoRE9NQUlOX0hZUCwgRE9NQUlOX0NMSUVOVCkgfAlcCisJIERPTUFJTl9WQUxV
RShET01BSU5fU1ZDLCBET01BSU5fQ0xJRU5UKSB8CVwKKwkgRE9NQUlOX1ZBTFVFKERPTUFJ
Tl9JTywgIERPTUFJTl9DTElFTlQpIHwJXAorCSBET01BSU5fVkFMVUUoRE9NQUlOX1VTUiwg
RE9NQUlOX0NMSUVOVCkpCisKKyNkZWZpbmUgREFDUl9TVEFUX1NWQwkJCQkJXAorCShET01B
SU5fVkFMVUUoRE9NQUlOX0hZUCwgRE9NQUlOX0NMSUVOVCkgfAlcCisJIERPTUFJTl9WQUxV
RShET01BSU5fU1ZDLCBET01BSU5fTUFOQUdFUikgfAlcCisJIERPTUFJTl9WQUxVRShET01B
SU5fSU8sICBET01BSU5fTUFOQUdFUikgfAlcCisJIERPTUFJTl9WQUxVRShET01BSU5fVVNS
LCBET01BSU5fQ0xJRU5UKSkJXAorCisjZGVmaW5lIERBQ1JfU1RBVF9VU1IJCQkJCVwKKwko
RE9NQUlOX1ZBTFVFKERPTUFJTl9IWVAsIERPTUFJTl9DTElFTlQpIHwJXAorCSBET01BSU5f
VkFMVUUoRE9NQUlOX1NWQywgRE9NQUlOX0NMSUVOVCkgfAlcCisJIERPTUFJTl9WQUxVRShE
T01BSU5fSU8sICBET01BSU5fQ0xJRU5UKSB8CVwKKwkgRE9NQUlOX1ZBTFVFKERPTUFJTl9V
U1IsIERPTUFJTl9DTElFTlQpKQorCisjZW5kaWYgLyogX19BUk1fQ1BVX0RPTUFJTl9IX18g
Ki8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9jdXJyZW50LmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsNzMgQEAKKy8qCisgKiAgY3VycmVudC5oCisgKgorICogQ29weXJp
Z2h0IChDKSAyMDA4IFNhbXN1bmcgRWxlY3Ryb25pY3MKKyAqCUNoYW5KdSBQYXJrIDxiZWFz
dHdvcmxkQHNhbXN1bmcuY29tPgorICoJSmFlTWluIFJ5dSAgPGptNzcucnl1QHNhbXN1bmcu
Y29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcyBwdWJsaXNo
ZWQgYnkKKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2Vm
dWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1w
bGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2
ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcg
d2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUK
KyAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0
b24sIE1BICAwMjExMS0xMzA3ICBVU0EKKyAqLworI2lmbmRlZiBfX0FSTV9DVVJSRU5UX0hf
XworI2RlZmluZSBfX0FSTV9DVVJSRU5UX0hfXworCisjaW5jbHVkZSA8cHVibGljL3hlbi5o
PgorI2luY2x1ZGUgPGFzbS9wYWdlLmg+CisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCitzdHJ1
Y3QgdmNwdTsKKworc3RydWN0IGNwdV9pbmZvIHsKKwlzdHJ1Y3QgdmNwdQkqdmNwdTsKKwl1
bnNpZ25lZCBsb25nCXZzcHNyOworCXVuc2lnbmVkIGxvbmcJdnNwOworCXVuc2lnbmVkIGxv
bmcJdmxyOworCXVuc2lnbmVkIGxvbmcJdmRhY3I7CisJc3RydWN0IGNwdV91c2VyX3JlZ3Mg
Z3Vlc3RfY3B1X3VzZXJfcmVnczsKK307CisKK3N0YXRpYyBpbmxpbmUgc3RydWN0IGNwdV9p
bmZvICogZ2V0X2NwdV9pbmZvKHZvaWQpCit7CisJcmVnaXN0ZXIgdW5zaWduZWQgbG9uZyBz
cCBhc20oInIxMyIpOworCXJldHVybiAoc3RydWN0IGNwdV9pbmZvICopICggc3AgJiB+KFNU
QUNLX1NJWkUgLTEpICApOyAKK30KKworc3RhdGljIGlubGluZSBzdHJ1Y3QgdmNwdSAqZ2V0
X2N1cnJlbnQodm9pZCkKK3sKKyAgICAgICAgcmV0dXJuIGdldF9jcHVfaW5mbygpLT52Y3B1
OworfQorCisjZGVmaW5lIGN1cnJlbnQgZ2V0X2N1cnJlbnQoKQorCitzdGF0aWMgaW5saW5l
IHZvaWQgc2V0X2N1cnJlbnQoc3RydWN0IHZjcHUgKnYpCit7ICAgCisJZ2V0X2NwdV9pbmZv
KCktPnZjcHUgPSB2OworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgc2V0X2N1cnJlbnRfdmNw
dShzdHJ1Y3QgdmNwdSAqdikKK3sKKyAgICAgICAgc3RydWN0IGNwdV9pbmZvICpjaTsKKwor
ICAgICAgICBjaSA9IGdldF9jcHVfaW5mbygpOworICAgICAgICBjaS0+dmNwdSA9IHY7Cit9
CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBjcHVfaW5mb19pbml0KHN0cnVjdCBjcHVfaW5mbyAq
Y3B1X2luZm8pCit7CisgICAgICAgIGNwdV9pbmZvLT52Y3B1ID0gTlVMTDsKK30KKworI2Rl
ZmluZSBndWVzdF9jcHVfdXNlcl9yZWdzKCkJKCYoZ2V0X2NwdV9pbmZvKCktPmd1ZXN0X2Nw
dV91c2VyX3JlZ3MpKQorI2VuZGlmCisKKyNlbmRpZiAvKiBfX0FSTV9DVVJSRU5UX0hfXyAq
LwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2RlYnVnZ2VyLmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9kZWJ1Z2dlci5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiAr
MDkwMApAQCAtMCwwICsxLDI0IEBACisjaWZuZGVmIF9fQVJNX0RFQlVHR0VSX0hfXworI2Rl
ZmluZSBfX0FSTV9ERUJVR0dFUl9IX18KKworI2luY2x1ZGUgPHhlbi9lcnJuby5oPgorCisj
aWZuZGVmIF9fQVNTRU1CTFlfXworI2RlZmluZSBkZWJ1Z2dlcl90cmFwX2ltbWVkaWF0ZSgp
CXs7fQorCitzdGF0aWMgaW5saW5lIGludCBkZWJ1Z2dlcl90cmFwX2ZhdGFsKHVuc2lnbmVk
IGludCB2ZWN0b3IsIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQoreworCXByaW50aygi
Tm90IGltcGxlbWVudGVkIHlldFxuIik7CisKKwlyZXR1cm4gLUVJTlZBTDsKK30KKworCit2
b2lkIHNob3dfc3RhY2soc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpOwordm9pZCBzaG93
X3N0YWNrX292ZXJmbG93KHVuc2lnbmVkIGludCBjcHUsIHVuc2lnbmVkIGxvbmcgZXNwKTsK
K3ZvaWQgc2hvd19yZWdpc3RlcnMoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpOwordm9p
ZCBzaG93X2V4ZWN1dGlvbl9zdGF0ZShzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncyk7Cisj
ZW5kaWYgLyohX19BU1NFTUJMWV9fKi8KKworI2VuZGlmIC8qIV9fQVJNX0RFQlVHR0VSX0hf
XyAqLworCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vZGVsYXku
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL2RlbGF5LmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsNiBAQAorI2lmbmRlZiBfX0FSTV9ERUxBWV9IX18KKyNkZWZpbmUg
X19BUk1fREVMQVlfSF9fCisKKyNkZWZpbmUgdWRlbGF5KG4pIAlfdWRlbGF5KG4pCisjZW5k
aWYKKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2RpdjY0LmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9kaXY2NC5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkw
MApAQCAtMCwwICsxLDQzIEBACisjaWZuZGVmIF9fQVJNX0RJVjY0X18KKyNkZWZpbmUgX19B
Uk1fRElWNjRfXworCisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgorCisjaWZuZGVmIF9fQVNT
RU1CTFlfXworLyoKKyAqIFRoZSBzZW1hbnRpY3Mgb2YgZG9fZGl2KCkgYXJlOgorICoKKyAq
IHVpbnQzMl90IGRvX2Rpdih1aW50NjRfdCAqbiwgdWludDMyX3QgYmFzZSkKKyAqIHsKKyAq
IAl1aW50MzJfdCByZW1haW5kZXIgPSAqbiAlIGJhc2U7CisgKiAJKm4gPSAqbiAvIGJhc2U7
CisgKiAJcmV0dXJuIHJlbWFpbmRlcjsKKyAqIH0KKyAqCisgKiBJbiBvdGhlciB3b3Jkcywg
YSA2NC1iaXQgZGl2aWRlbmQgd2l0aCBhIDMyLWJpdCBkaXZpc29yIHByb2R1Y2luZworICog
YSA2NC1iaXQgcmVzdWx0IGFuZCBhIDMyLWJpdCByZW1haW5kZXIuICBUbyBhY2NvbXBsaXNo
IHRoaXMgb3B0aW1hbGx5CisgKiB3ZSBjYWxsIGEgc3BlY2lhbCBfX2RvX2RpdjY0IGhlbHBl
ciB3aXRoIGNvbXBsZXRlbHkgbm9uIHN0YW5kYXJkCisgKiBjYWxsaW5nIGNvbnZlbnRpb24g
Zm9yIGFyZ3VtZW50cyBhbmQgcmVzdWx0cyAoYmV3YXJlKS4KKyAqLworI2RlZmluZSBfX3hs
ICJyMCIKKyNkZWZpbmUgX194aCAicjEiCisKKyNkZWZpbmUgZG9fZGl2KG4sYmFzZSkJCQkJ
CQlcCisoewkJCQkJCQkJXAorCXJlZ2lzdGVyIHVuc2lnbmVkIGludCBfX2Jhc2UgICAgICBh
c20oInI0IikgPSBiYXNlOwlcCisJcmVnaXN0ZXIgdW5zaWduZWQgbG9uZyBsb25nIF9fbiAg
IGFzbSgicjAiKSA9IG47CVwKKwlyZWdpc3RlciB1bnNpZ25lZCBsb25nIGxvbmcgX19yZXMg
YXNtKCJyMiIpOwkJXAorCXJlZ2lzdGVyIHVuc2lnbmVkIGludCBfX3JlbSAgICAgICBhc20o
X194aCk7CQlcCisJYXNtKAlfX2FzbWVxKCIlMCIsIF9feGgpCQkJCVwKKwkJX19hc21lcSgi
JTEiLCAicjIiKQkJCQlcCisJCV9fYXNtZXEoIiUyIiwgInIwIikJCQkJXAorCQlfX2FzbWVx
KCIlMyIsICJyNCIpCQkJCVwKKwkJImJsCV9fZG9fZGl2NjQiCQkJCVwKKwkJOiAiPXIiIChf
X3JlbSksICI9ciIgKF9fcmVzKQkJCVwKKwkJOiAiciIgKF9fbiksICJyIiAoX19iYXNlKQkJ
CVwKKwkJOiAiaXAiLCAibHIiLCAiY2MiKTsJCQkJXAorCW4gPSBfX3JlczsJCQkJCQlcCisJ
X19yZW07CQkJCQkJCVwKK30pCisjZW5kaWYgLyohX19BU1NFTUJMWV9fKi8KKyNlbmRpZiAv
KiFfX0FSTV9ESVY2NF9IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUv
YXNtLWFybS9kb21haW4uaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2RvbWFpbi5oCUZyaSBGZWIgMDMg
MTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDc5IEBACisjaWZuZGVmIF9fQVJNX0RP
TUFJTl9IX18KKyNkZWZpbmUgX19BUk1fRE9NQUlOX0hfXworI2luY2x1ZGUgPHhlbi9pbml0
Lmg+CisjaW5jbHVkZSA8eGVuL21tLmg+CisjaW5jbHVkZSA8eGVuL3NwaW5sb2NrLmg+Cisj
aW5jbHVkZSA8eGVuL3Rhc2tsZXQuaD4KKyNpbmNsdWRlIDxhc20vbnVtYS5oPgorI2luY2x1
ZGUgPGFzbS9pb21tdS5oPgorI2luY2x1ZGUgPHB1YmxpYy9hcmNoLWFybS5oPgorCisjaWYg
MAorI2RlZmluZSBNQVBIQVNIX0VOVFJJRVMJCQk4CisjZGVmaW5lIE1BUEhBU0hfSEFTSEZO
KHBmbikJCSgocGZuKSAmIChNQVBIQVNIX0VOVFJJRVMtMSkpCisjZGVmaW5lIE1BUEhBU0hF
TlRfTk9USU5VU0UJCSgodTE2KX4wVSkKKworc3RydWN0IHZjcHVfbWFwaGFzaCB7CisgICAg
c3RydWN0IHZjcHVfbWFwaGFzaF9lbnRyeSB7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZu
OworICAgICAgICB1aW50MTZfdCAgICAgIGlkeDsKKyAgICAgICAgdWludDE2X3QgICAgICBy
ZWZjbnQ7CisgICAgfSBoYXNoW01BUEhBU0hfRU5UUklFU107Cit9X19jYWNoZWxpbmVfYWxp
Z25lZDsKKworCisjZGVmaW5lIE1BUENBQ0hFX09SREVSICAgOAorI2RlZmluZSBNQVBDQUNI
RV9FTlRSSUVTICgxIDw8IE1BUENBQ0hFX09SREVSKQorCitzdHJ1Y3QgbWFwY2FjaGUgewor
ICAgIC8qIFRoZSBQVEVzIHRoYXQgcHJvdmlkZSB0aGUgbWFwcGluZ3MsIGFuZCBhIGN1cnNv
ciBpbnRvIHRoZSBhcnJheS4gKi8KKyAgICBsMmVfdAkqdGFibGU7CisgICAgdW5zaWduZWQg
aW50IGN1cnNvcjsKKworICAgIC8qIFByb3RlY3RzIG1hcF9kb21haW5fcGFnZSgpLiAqLwor
ICAgIHNwaW5sb2NrX3QgbG9jazsKKworICAgIC8qIFdoaWNoIG1hcHBpbmdzIGFyZSBpbiB1
c2UsIGFuZCB3aGljaCBhcmUgZ2FyYmFnZSB0byByZWFwIG5leHQgZXBvY2g/ICovCisgICAg
dW5zaWduZWQgbG9uZyBpbnVzZVtCSVRTX1RPX0xPTkdTKE1BUENBQ0hFX0VOVFJJRVMpXTsK
KyAgICB1bnNpZ25lZCBsb25nIGdhcmJhZ2VbQklUU19UT19MT05HUyhNQVBDQUNIRV9FTlRS
SUVTKV07CisKKyAgICAvKiBMb2NrLWZyZWUgcGVyLVZDUFUgaGFzaCBvZiByZWNlbnRseS11
c2VkIG1hcHBpbmdzLiAqLworICAgIHN0cnVjdCB2Y3B1X21hcGhhc2ggdmNwdV9tYXBoYXNo
W01BWF9WSVJUX0NQVVNdOworfV9fY2FjaGVsaW5lX2FsaWduZWQ7CisjZW5kaWYKK3N0cnVj
dCBhcmNoX2RvbWFpbgoreworI2lmIDAKKyAgICAvKiBJL08tcG9ydCBhZG1pbi1zcGVjaWZp
ZWQgYWNjZXNzIGNhcGFiaWxpdGllcy4gKi8KKyAgICBzdHJ1Y3QgcmFuZ2VzZXQJKmlvcG9y
dF9jYXBzOworCisgICAgaW50ICppcnFfcGlycTsKKyAgICBpbnQgKnBpcnFfaXJxOworCisg
ICAgdW5zaWduZWQgbG9uZyAqcGlycV9lb2lfbWFwOworICAgIHVuc2lnbmVkIGxvbmcgcGly
cV9lb2lfbWFwX21mbjsKKyNlbmRpZgorICAgIHN0cnVjdCBwYWdlX2xpc3RfaGVhZCByZWxt
ZW1fbGlzdDsKK307CisKK3N0cnVjdCBhcmNoX3ZjcHUKK3sKKwlzdHJ1Y3QgdmNwdV9ndWVz
dF9jb250ZXh0IGN0eDsKK30gX19jYWNoZWxpbmVfYWxpZ25lZDsKKworLy8jZGVmaW5lIFZD
UFVfUkVHKHYsIHJlZykJdi0+YXJjaC5jdHgucmVnCisKKyNkZWZpbmUgcmV0dXJuX3JlZyh2
KQkJKCh2KS0+YXJjaC5jdHgucjApCisKK3ZvaWQgdmNwdV9zaG93X2V4ZWN1dGlvbl9zdGF0
ZShzdHJ1Y3QgdmNwdSAqdik7Cit2b2lkIHN0YXJ0dXBfY3B1X2lkbGVfbG9vcCh2b2lkKTsK
KworZXh0ZXJuIHN0cnVjdCB2Y3B1ICppZGxlX3ZjcHVbXTsKKworc3RhdGljIGlubGluZSBz
dHJ1Y3QgdmNwdSAqZ2V0X2lkbGVfdmNwdSh1bnNpZ25lZCBpbnQgY3B1KQoreworICAgICAg
ICByZXR1cm4gaWRsZV92Y3B1W2NwdV07Cit9CisKKyNlbmRpZiAKKwpkaWZmIC1yIGU3MDE0
NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2VsZi5oCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vZWxm
LmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTMgQEAKKy8q
CisgKiBlbGYuaAorICoKKyAqIENvcHlyaWdodCAoQykgMjAwOCBTYW1zdW5nIEVsZWN0cm9u
aWNzCisgKiAgICAgICAgICBKYWVtaW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4KKyAq
CisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQorICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5Cisg
KiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorICog
YnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2Fy
cmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM
QVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv
ciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29w
eSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhp
cyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3Vu
ZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAg
MDIxMTEtMTMwNyAgVVNBCisgKi8KKworI2lmbmRlZiBfX0FSTV9FTEZfSF9fCisjZGVmaW5l
IF9fQVJNX0VMRl9IX18KKwordHlwZWRlZiBzdHJ1Y3QgeworCXVuc2lnbmVkIGxvbmcJY3I7
Cit9IGNyYXNoX3hlbl9jb3JlX3Q7CisKK3R5cGVkZWYgc3RydWN0IHsKKwl1bnNpZ25lZCBs
b25nCXIwOworCXVuc2lnbmVkIGxvbmcJcjE7CisJdW5zaWduZWQgbG9uZwlyMjsKKwl1bnNp
Z25lZCBsb25nCXIzOworCXVuc2lnbmVkIGxvbmcJcjQ7CisJdW5zaWduZWQgbG9uZwlyNTsK
Kwl1bnNpZ25lZCBsb25nCXI2OworCXVuc2lnbmVkIGxvbmcJcjc7CisJdW5zaWduZWQgbG9u
ZwlyODsKKwl1bnNpZ25lZCBsb25nCXI5OworCXVuc2lnbmVkIGxvbmcJcjEwOworCXVuc2ln
bmVkIGxvbmcJcjExOworCXVuc2lnbmVkIGxvbmcJcjEyOworCXVuc2lnbmVkIGxvbmcJcjEz
OworCXVuc2lnbmVkIGxvbmcJcjE0OworCXVuc2lnbmVkIGxvbmcJcjE1OworfSBFTEZfR3Jl
Z3NldDsKKworc3RhdGljIGlubGluZSB2b2lkIGVsZl9jb3JlX3NhdmVfcmVncyhFTEZfR3Jl
Z3NldCAqY29yZV9yZWdzLAorCQkJCSAgICAgIGNyYXNoX3hlbl9jb3JlX3QgKnhlbl9jb3Jl
X3JlZ3MpCit7Cit9CisKKyNlbmRpZgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNs
dWRlL2FzbS1hcm0vZXZlbnQuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2V2ZW50LmgJRnJpIEZlYiAw
MyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsMzkgQEAKKyNpZm5kZWYgX19BUk1f
RVZFTlRfSF9fCisjZGVmaW5lIF9fQVJNX0VWRU5UX0hfXworCisjaW5jbHVkZSA8eGVuL3No
YXJlZC5oPgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXwordm9pZCB2Y3B1X2tpY2soc3RydWN0
IHZjcHUgKnYpOwordm9pZCB2Y3B1X21hcmtfZXZlbnRzX3BlbmRpbmcoc3RydWN0IHZjcHUg
KnYpOworCitpbnQgaHZtX2xvY2FsX2V2ZW50c19uZWVkX2RlbGl2ZXJ5KHN0cnVjdCB2Y3B1
ICp2KTsKK3N0YXRpYyBpbmxpbmUgaW50IGxvY2FsX2V2ZW50c19uZWVkX2RlbGl2ZXJ5KHZv
aWQpCit7CisJc3RydWN0IHZjcHUgKnYgPSBjdXJyZW50OworCXJldHVybiAoKHZjcHVfaW5m
byh2LCBldnRjaG5fdXBjYWxsX3BlbmRpbmcpICYmIAorCQkhdmNwdV9pbmZvKHYsIGV2dGNo
bl91cGNhbGxfbWFzaykpKTsKK30KKworc3RhdGljIGlubGluZSBpbnQgbG9jYWxfZXZlbnRf
ZGVsaXZlcnlfaXNfZW5hYmxlZCh2b2lkKQoreworCXJldHVybiAhdmNwdV9pbmZvKGN1cnJl
bnQsIGV2dGNobl91cGNhbGxfbWFzayk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBsb2Nh
bF9ldmVudF9kZWxpdmVyeV9kaXNhYmxlKHZvaWQpCit7CisJdmNwdV9pbmZvKGN1cnJlbnQs
IGV2dGNobl91cGNhbGxfbWFzaykgPSAxOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgbG9j
YWxfZXZlbnRfZGVsaXZlcnlfZW5hYmxlKHZvaWQpCit7CisJdmNwdV9pbmZvKGN1cnJlbnQs
IGV2dGNobl91cGNhbGxfbWFzaykgPSAwOworfQorCisvKiBObyBhcmNoIHNwZWNpZmljIHZp
cnEgZGVmaW5pdGlvbiBub3cuIERlZmF1bHQgdG8gZ2xvYmFsLiAqLworc3RhdGljIGlubGlu
ZSBpbnQgYXJjaF92aXJxX2lzX2dsb2JhbChpbnQgdmlycSkKK3sKKwlyZXR1cm4gMTsKK30K
KyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLworI2VuZGlmIC8qIV9fQVJNX0VWRU5UX0hfXyAq
LwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2ZsdXNodGxiLmgK
LS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVu
L2luY2x1ZGUvYXNtLWFybS9mbHVzaHRsYi5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiAr
MDkwMApAQCAtMCwwICsxLDI1IEBACisjaWZuZGVmIF9fQVJNX0ZMVVNIVExCX0hfXworI2Rl
ZmluZSBfX0FSTV9GTFVTSFRMQl9IX18KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNp
bmNsdWRlIDx4ZW4vcGVyY3B1Lmg+CisjaW5jbHVkZSA8eGVuL3NtcC5oPgorCisjaWZuZGVm
IF9fQVNTRU1CTFlfXworI2RlZmluZSBsb2NhbF9mbHVzaF90bGIobWFzaykKKyNkZWZpbmUg
Zmx1c2hfdGxiX21hc2sobWFzaykJbG9jYWxfZmx1c2hfdGxiKCkKKworI2RlZmluZSB0bGJm
bHVzaF9maWx0ZXIobWFzayxwYWdlX3RpbWVzdGFtcCkJXAorZG8gewkJCQkJCVwKKwlwcmlu
dGsoIk5vdCBpbXBsZW1lbnRlZCB5ZXQuXG4iKTsJXAorfSB3aGlsZSgwKQorCisjZGVmaW5l
IHRsYmZsdXNoX2N1cnJlbnRfdGltZSgpCXRsYmZsdXNoX2Nsb2NrCisKK0RFQ0xBUkVfUEVS
X0NQVSh1MzIsIHRsYl9jYXBzKTsKK0RFQ0xBUkVfUEVSX0NQVSh1MzIsIHRsYmZsdXNoX3Rp
bWUpOworCitleHRlcm4gdTMyIHRsYmZsdXNoX2Nsb2NrOworCisjZW5kaWYKKyNlbmRpZiAv
KiBfX0FSTV9UTEJfSF9fICovCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vZ3JhbnRfdGFibGUuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2dyYW50X3RhYmxlLmgJRnJp
IEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEsNjIgQEAKKyNpZm5kZWYg
X19BU01fR1JBTlRfVEFCTEVfSF9fCisjZGVmaW5lIF9fQVNNX0dSQU5UX1RBQkxFX0hfXwor
CisjZGVmaW5lIElOSVRJQUxfTlJfR1JBTlRfRlJBTUVTIDQKKworLyoKKyAqIENhbGxlciBt
dXN0IG93biBjYWxsZXIncyBCSUdMT0NLLCBpcyByZXNwb25zaWJsZSBmb3IgZmx1c2hpbmcg
dGhlIFRMQiwgYW5kCisgKiBtdXN0IGhvbGQgYSByZWZlcmVuY2UgdG8gdGhlIHBhZ2UuCisg
Ki8KK2ludCBjcmVhdGVfZ3JhbnRfaG9zdF9tYXBwaW5nKHVpbnQ2NF90IGFkZHIsIHVuc2ln
bmVkIGxvbmcgZnJhbWUsCisJCQkgICAgICB1bnNpZ25lZCBpbnQgZmxhZ3MsIHVuc2lnbmVk
IGludCBjYWNoZV9mbGFncyk7CitpbnQgcmVwbGFjZV9ncmFudF9ob3N0X21hcHBpbmcoCisg
ICAgdWludDY0X3QgYWRkciwgdW5zaWduZWQgbG9uZyBmcmFtZSwgdWludDY0X3QgbmV3X2Fk
ZHIsIHVuc2lnbmVkIGludCBmbGFncyk7CisKKyNkZWZpbmUgZ250dGFiX2NyZWF0ZV9zaGFy
ZWRfcGFnZShkLCB0LCBpKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg
ZG8geyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAorICAgICAgICBzaGFyZV94ZW5fcGFnZV93aXRoX2d1ZXN0KCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIHZp
cnRfdG9fcGFnZSgoY2hhciAqKSh0KS0+c2hhcmVkX3Jhd1tpXSksICAgICAgICAgICAgICAg
ICAgICBcCisgICAgICAgICAgICAoZCksIFhFTlNIQVJFX3dyaXRhYmxlKTsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIH0gd2hpbGUgKCAwICkKKworI2Rl
ZmluZSBnbnR0YWJfY3JlYXRlX3N0YXR1c19wYWdlKGQsIHQsIGkpICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKyAgICBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgIHNoYXJl
X3hlbl9wYWdlX3dpdGhfZ3Vlc3QoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXAorICAgICAgICAgICB2aXJ0X3RvX3BhZ2UoKGNoYXIgKikodCktPnN0YXR1c1tp
XSksICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIChkKSwgWEVOU0hB
UkVfd3JpdGFibGUpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgfSB3aGlsZSAoIDAgKQorCisKKyNkZWZpbmUgZ250dGFiX3NoYXJlZF9tZm4oZCwgdCwg
aSkgICAgICAgICAgICAgICAgICAgICAgXAorICAgICgodmlydF90b19tYWRkcigodCktPnNo
YXJlZF9yYXdbaV0pID4+IFBBR0VfU0hJRlQpKQorCisjZGVmaW5lIGdudHRhYl9zaGFyZWRf
Z21mbihkLCB0LCBpKSAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAobWZuX3RvX2dtZm4o
ZCwgZ250dGFiX3NoYXJlZF9tZm4oZCwgdCwgaSkpKQorCisKKyNkZWZpbmUgZ250dGFiX3N0
YXR1c19tZm4odCwgaSkgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICgodmlydF90
b19tYWRkcigodCktPnN0YXR1c1tpXSkgPj4gUEFHRV9TSElGVCkpCisKKyNkZWZpbmUgZ250
dGFiX3N0YXR1c19nbWZuKGQsIHQsIGkpICAgICAgICAgICAgICAgICAgICAgXAorICAgICht
Zm5fdG9fZ21mbihkLCBnbnR0YWJfc3RhdHVzX21mbih0LCBpKSkpCisKKyNkZWZpbmUgZ250
dGFiX21hcmtfZGlydHkoZCwgZikgKCh2b2lkKWYpCisKK3N0YXRpYyBpbmxpbmUgdm9pZCBn
bnR0YWJfY2xlYXJfZmxhZyh1bnNpZ25lZCBsb25nIG5yLCB1aW50MTZfdCAqYWRkcikKK3sK
KyAgICBjbGVhcl9iaXQobnIsICh1bnNpZ25lZCBsb25nICopYWRkcik7Cit9CisKKy8qIEZv
cmVpZ24gbWFwcGluZ3Mgb2YgSEhWTS1ndWVzdCBwYWdlcyBkbyBub3QgbW9kaWZ5IHRoZSB0
eXBlIGNvdW50LiAqLworI2RlZmluZSBnbnR0YWJfaG9zdF9tYXBwaW5nX2dldF9wYWdlX3R5
cGUob3AsIGxkLCByZCkgICBcCisgICAgKCEoKG9wKS0+ZmxhZ3MgJiBHTlRNQVBfcmVhZG9u
bHkpICYmICAgICAgICAgICAgICAgIFwKKyAgICAgKCgobGQpID09IChyZCkpIHx8ICFwYWdp
bmdfbW9kZV9leHRlcm5hbChyZCkpKQorCisvKiBEb25lIGltcGxpY2l0bHkgd2hlbiBwYWdl
IHRhYmxlcyBhcmUgZGVzdHJveWVkLiAqLworI2RlZmluZSBnbnR0YWJfcmVsZWFzZV9ob3N0
X21hcHBpbmdzKGRvbWFpbikgKCBwYWdpbmdfbW9kZV9leHRlcm5hbChkb21haW4pICkKKwor
c3RhdGljIGlubGluZSBpbnQgcmVwbGFjZV9ncmFudF9zdXBwb3J0ZWQodm9pZCkKK3sKKyAg
ICByZXR1cm4gMTsKK30KKyNlbmRpZiAvKiBfX0FTTV9HUkFOVF9UQUJMRV9IX18gKi8KZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9ndWVzdF9hY2Nlc3MuaAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
aW5jbHVkZS9hc20tYXJtL2d1ZXN0X2FjY2Vzcy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAx
MiArMDkwMApAQCAtMCwwICsxLDEzNiBAQAorLyoKKyAqLworCisjaWZuZGVmIF9fQVJNX0dV
RVNUX0FDQ0VTU19IX18KKyNkZWZpbmUgX19BUk1fR1VFU1RfQUNDRVNTX0hfXworCisjZGVm
aW5lIF9fcmFuZ2Vfb2soYWRkciwgc2l6ZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCisoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJdW5zaWduZWQgbG9uZyBm
bGFncywgc3VtOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKwlf
X2FzbV9fKCJhZGRzICAgJTEsICUyLCAlM1xuXHQiICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorCQkic2JjY2NzICUxLCAlMSwgJTBcblx0IiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKwkJIm1vdmNjICAlMCwgIzAiICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBcCisJCTogIj0mciIoZmxhZ3MpLCAiPSZyIihzdW0p
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorCQk6ICJyIihhZGRyKSwgIklyIihz
aXplKSwgIjAiKEhZUEVSVklTT1JfVklSVF9TVEFSVCkgICAgIFwKKwkJOiAiY2MiKTsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJZmxhZ3M7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKK30pCisKKyNkZWZpbmUgYWNjZXNzX29rKGFkZHIsc2l6ZSkgICAgKF9fcmFuZ2Vf
b2soYWRkcixzaXplKSA9PSAwKQorCisjZGVmaW5lIGFycmF5X2FjY2Vzc19vayhhZGRyLGNv
dW50LHNpemUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJKGxpa2VseShj
b3VudCA8ICh+MFVML3NpemUpKSAmJiBhY2Nlc3Nfb2soYWRkcixjb3VudCpzaXplKSkKKwor
LyogUmF3IGFjY2VzcyBmdW5jdGlvbnM6IG5vIHR5cGUgY2hlY2tpbmcuICovCisjZGVmaW5l
IHJhd19jb3B5X3RvX2d1ZXN0KGRzdCwgc3JjLCBsZW4pICAgICAgICBcCisgICAgIF9fY29w
eV90b191c2VyKChkc3QpLCAoc3JjKSwgKGxlbikpCisjZGVmaW5lIHJhd19jb3B5X2Zyb21f
Z3Vlc3QoZHN0LCBzcmMsIGxlbikgICAgICBcCisgICAgIF9fY29weV9mcm9tX3VzZXIoKGRz
dCksIChzcmMpLCAobGVuKSkKKyNkZWZpbmUgcmF3X2NsZWFyX2d1ZXN0KGRzdCwgIGxlbikg
ICAgICAgICAgICAgIFwKKyAgICAgX19jbGVhcl91c2VyKChkc3QpLCAobGVuKSkKKyNkZWZp
bmUgX19yYXdfY29weV90b19ndWVzdChkc3QsIHNyYywgbGVuKSAgICAgIFwKKyAgICAgX19j
b3B5X3RvX3VzZXIoKGRzdCksIChzcmMpLCAobGVuKSkKKyNkZWZpbmUgX19yYXdfY29weV9m
cm9tX2d1ZXN0KGRzdCwgc3JjLCBsZW4pICAgIFwKKyAgICAgX19jb3B5X2Zyb21fdXNlcigo
ZHN0KSwgKHNyYyksIChsZW4pKQorI2RlZmluZSBfX3Jhd19jbGVhcl9ndWVzdChkc3QsICBs
ZW4pICAgICAgICAgICAgXAorICAgICBfX2NsZWFyX3VzZXIoKGRzdCksIChsZW4pKQorCisK
KworLyogSXMgdGhlIGd1ZXN0IGhhbmRsZSBhIE5VTEwgcmVmZXJlbmNlPyAqLworI2RlZmlu
ZSBndWVzdF9oYW5kbGVfaXNfbnVsbChobmQpCQlcCisJKChobmQpLnAgPT0gTlVMTCkKKwor
LyogT2Zmc2V0IHRoZSBnaXZlbiBndWVzdCBoYW5kbGUgaW50byB0aGUgYXJyYXkgaXQgcmVm
ZXJzIHRvLiAqLworI2RlZmluZSBndWVzdF9oYW5kbGVfYWRkX29mZnNldChobmQsIG5yKQlc
CisJKChobmQpLnAgKz0gKG5yKSkKKworLyogQ2FzdCBhIGd1ZXN0IGhhbmRsZSB0byB0aGUg
c3BlY2lmaWVkIHR5cGUgb2YgaGFuZGxlLiAqLworI2RlZmluZSBndWVzdF9oYW5kbGVfY2Fz
dChobmQsIHR5cGUpCQlcCisoewkJCQkJCVwKKyAgICB0eXBlICpfeCA9IChobmQpLnA7CQkJ
CVwKKyAgICAoWEVOX0dVRVNUX0hBTkRMRSh0eXBlKSkgeyBfeCB9OwkJXAorfSkKKworCisv
KgorICogUHJlLXZhbGlkYXRlIGEgZ3Vlc3QgaGFuZGxlLgorICogQWxsb3dzIHVzZSBvZiBm
YXN0ZXIgX19jb3B5XyogZnVuY3Rpb25zLgorICovCisjZGVmaW5lIGd1ZXN0X2hhbmRsZV9v
a2F5KGhuZCwgbnIpICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBhcnJheV9hY2Nlc3Nf
b2soKGhuZCkucCwgKG5yKSwgc2l6ZW9mKCooaG5kKS5wKSkKKyAgICAKKyNkZWZpbmUgZ3Vl
c3RfaGFuZGxlX3N1YnJhbmdlX29rYXkoaG5kLCBmaXJzdCwgbGFzdCkJXAorICAgKGFycmF5
X2FjY2Vzc19vaygoaG5kKS5wICsgKGZpcnN0KSwJCQlcCisJCSAgIChsYXN0KSAtIChmaXJz
dCkgKyAxLAkJXAorCQkgICBzaXplb2YoKihobmQpLnApKSkKKy8qCisgKiBDb3B5IGFuIGFy
cmF5IG9mIG9iamVjdHMgdG8gZ3Vlc3QgY29udGV4dCB2aWEgYSBndWVzdCBoYW5kbGUuCisg
KiBPcHRpb25hbGx5IHNwZWNpZnkgYW4gb2Zmc2V0IGludG8gdGhlIGd1ZXN0IGFycmF5Lgor
ICovCisjZGVmaW5lIGNvcHlfdG9fZ3Vlc3Rfb2Zmc2V0KGhuZCwgaWR4LCBwdHIsIG5yKSBc
CisgICAgX19jb3B5X3RvX2d1ZXN0X29mZnNldChobmQsIGlkeCwgcHRyLCBucikKKworICAK
Ky8qCisgKiBDb3B5IGFuIGFycmF5IG9mIG9iamVjdHMgZnJvbSBndWVzdCBjb250ZXh0IHZp
YSBhIGd1ZXN0IGhhbmRsZS4KKyAqIE9wdGlvbmFsbHkgc3BlY2lmeSBhbiBvZmZzZXQgaW50
byB0aGUgZ3Vlc3QgYXJyYXkuCisgKi8KKyNkZWZpbmUgY29weV9mcm9tX2d1ZXN0X29mZnNl
dChwdHIsIGhuZCwgaWR4LCBucikgXAorICAgIF9fY29weV9mcm9tX2d1ZXN0X29mZnNldChw
dHIsIGhuZCwgaWR4LCBucikKKyAgICAKKyAgICAKKy8qIENvcHkgc3ViLWZpZWxkIG9mIGEg
c3RydWN0dXJlIHRvIGd1ZXN0IGNvbnRleHQgdmlhIGEgZ3Vlc3QgaGFuZGxlLiAqLworI2Rl
ZmluZSBjb3B5X2ZpZWxkX3RvX2d1ZXN0KGhuZCwgcHRyLCBmaWVsZCkgXAorICAgIF9fY29w
eV9maWVsZF90b19ndWVzdChobmQsIHB0ciwgZmllbGQpCisKKy8qIENvcHkgc3ViLWZpZWxk
IG9mIGEgc3RydWN0dXJlIGZyb20gZ3Vlc3QgY29udGV4dCB2aWEgYSBndWVzdCBoYW5kbGUu
ICovCisjZGVmaW5lIGNvcHlfZmllbGRfZnJvbV9ndWVzdChwdHIsIGhuZCwgZmllbGQpIFwK
KyAgICBfX2NvcHlfZmllbGRfZnJvbV9ndWVzdChwdHIsIGhuZCwgZmllbGQpCisgICAgCisj
ZGVmaW5lIF9fY29weV90b19ndWVzdF9vZmZzZXQoaG5kLCBvZmYsIHB0ciwgbnIpICh7ICAg
IFwKKyAgICBjb25zdCB0eXBlb2YoKihwdHIpKSAqX3MgPSAocHRyKTsgICAgICAgICAgICAg
ICAgICAgXAorICAgIGNoYXIgKCpfZClbc2l6ZW9mKCpfcyldID0gKHZvaWQgKikoaG5kKS5w
OyAgICAgICAgICBcCisgICAgKCh2b2lkKSgoaG5kKS5wID09IChwdHIpKSk7ICAgICAgICAg
ICAgICAgICAgICAgICAgIFwKKyAgICBfX2NvcHlfdG9fdXNlcihfZCsob2ZmKSwgX3MsIHNp
emVvZigqX3MpKihucikpOyAgICAgXAorfSkKKworI2RlZmluZSBfX2NvcHlfZnJvbV9ndWVz
dF9vZmZzZXQocHRyLCBobmQsIG9mZiwgbnIpICh7ICBcCisgICAgY29uc3QgdHlwZW9mKCoo
cHRyKSkgKl9zID0gKGhuZCkucDsgICAgICAgICAgICAgICAgIFwKKyAgICB0eXBlb2YoKihw
dHIpKSAqX2QgPSAocHRyKTsgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIF9fY29w
eV9mcm9tX3VzZXIoX2QsIF9zKyhvZmYpLCBzaXplb2YoKl9kKSoobnIpKTsgICBcCit9KQor
CisjZGVmaW5lIF9fY29weV9maWVsZF90b19ndWVzdChobmQsIHB0ciwgZmllbGQpICh7ICAg
ICAgIFwKKyAgICBjb25zdCB0eXBlb2YoJihwdHIpLT5maWVsZCkgX3ggPSAmKGhuZCkucC0+
ZmllbGQ7ICAgXAorICAgIGNvbnN0IHR5cGVvZigmKHB0ciktPmZpZWxkKSBfeSA9ICYocHRy
KS0+ZmllbGQ7ICAgICBcCisgICAgX19jb3B5X3RvX3VzZXIoX3gsIF95LCBzaXplb2YoKl94
KSk7ICAgICAgICAgICAgICAgIFwKK30pCisKKyNkZWZpbmUgX19jb3B5X2ZpZWxkX2Zyb21f
Z3Vlc3QocHRyLCBobmQsIGZpZWxkKSAoeyAgICAgXAorICAgIGNvbnN0IHR5cGVvZigmKHB0
ciktPmZpZWxkKSBfeCA9ICYoaG5kKS5wLT5maWVsZDsgICBcCisgICAgY29uc3QgdHlwZW9m
KCYocHRyKS0+ZmllbGQpIF95ID0gJihwdHIpLT5maWVsZDsgICAgIFwKKyAgICBfX2NvcHlf
ZnJvbV91c2VyKF95LCBfeCwgc2l6ZW9mKCpfeCkpOyAgICAgICAgICAgICAgXAorfSkKKwor
CitleHRlcm4gdW5zaWduZWQgbG9uZyBfX2FyY2hfY29weV9mcm9tX3VzZXIodm9pZCAqdG8s
IGNvbnN0IHZvaWQgKmZyb20sIHVuc2lnbmVkIGxvbmcgbik7CitleHRlcm4gdW5zaWduZWQg
bG9uZyBfX2FyY2hfY29weV90b191c2VyKHZvaWQgKnRvLCBjb25zdCB2b2lkICpmcm9tLCB1
bnNpZ25lZCBsb25nIG4pOworZXh0ZXJuIHVuc2lnbmVkIGxvbmcgX19hcmNoX2NsZWFyX3Vz
ZXIodm9pZCAqdG8sIHVuc2lnbmVkIGxvbmcgbik7CisKK3N0YXRpYyBpbmxpbmUgdW5zaWdu
ZWQgbG9uZyBfX2NvcHlfZnJvbV91c2VyKHZvaWQgKnRvLCBjb25zdCB2b2lkICpmcm9tLCB1
bnNpZ25lZCBsb25nIG4pCit7CisgICAgICAgIHJldHVybiBfX2FyY2hfY29weV9mcm9tX3Vz
ZXIodG8sIGZyb20sIG4pOworfQorCisKK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBf
X2NvcHlfdG9fdXNlcih2b2lkICp0bywgY29uc3Qgdm9pZCAqZnJvbSwgdW5zaWduZWQgbG9u
ZyBuKQoreworICAgICAgICByZXR1cm4gX19hcmNoX2NvcHlfdG9fdXNlcih0bywgZnJvbSwg
bik7Cit9CisKK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBfX2NsZWFyX3VzZXIodm9p
ZCAqdG8sIHVuc2lnbmVkIGxvbmcgbikKK3sKKwlyZXR1cm4gX19hcmNoX2NsZWFyX3VzZXIo
dG8sIG4pOworfQorI2VuZGlmCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vaGFyZGlycS5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vaGFyZGlycS5oCUZyaSBGZWIgMDMg
MTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDIxIEBACisjaWZuZGVmIF9fQVJNX0hB
UkRJUlFfSF9fCisjZGVmaW5lIF9fQVJNX0hBUkRJUlFfSF9fCisKKyNpbmNsdWRlIDx4ZW4v
Y29uZmlnLmg+CisjaW5jbHVkZSA8eGVuL2NhY2hlLmg+CisKKyNpZm5kZWYgX19BU1NFTUJM
WV9fCit0eXBlZGVmIHN0cnVjdCBpcnFfY3B1c3RhdCB7CisJdW5zaWduZWQgbG9uZyBfX3Nv
ZnRpcnFfcGVuZGluZzsKKwl1bnNpZ25lZCBsb25nIF9fbG9jYWxfaXJxX2NvdW50OworCXVu
c2lnbmVkIGxvbmcgX19ubWlfY291bnQ7Cit9IF9fY2FjaGVsaW5lX2FsaWduZWQgaXJxX2Nw
dXN0YXRfdDsKKworI2luY2x1ZGUgPHhlbi9pcnFfY3B1c3RhdC5oPiAgICAvKiBTdGFuZGFy
ZCBtYXBwaW5ncyBmb3IgaXJxX2NwdXN0YXRfdCBhYm92ZSAqLworCisjZGVmaW5lIGluX2ly
cSgpIAkobG9jYWxfaXJxX2NvdW50KHNtcF9wcm9jZXNzb3JfaWQoKSkgIT0gMCkKKworI2Rl
ZmluZSBpcnFfZW50ZXIoKSAgICAgKGxvY2FsX2lycV9jb3VudChzbXBfcHJvY2Vzc29yX2lk
KCkpKyspCisjZGVmaW5lIGlycV9leGl0KCkgICAgICAobG9jYWxfaXJxX2NvdW50KHNtcF9w
cm9jZXNzb3JfaWQoKSktLSkKKyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLworI2VuZGlmIC8q
IV9fQVJNX0hBUkRJUlFfSF9fKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUv
YXNtLWFybS9oeXBlcmNhbGwuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2h5cGVyY2FsbC5oCUZyaSBG
ZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDY4IEBACisvKgorICogaHlw
ZXJjYWxsLmgKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMDggU2Ftc3VuZyBFbGVjdHJvbmlj
cworICogICAgICAgICAgSm9vWW91bmcgSHdhbmcgPGpvb3lvdW5nLmh3YW5nQHNhbXN1bmcu
Y29tPgorICogICAgICAgICAgSmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+Cisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQor
ICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0g
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAq
IGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdh
cnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBm
b3IgbW9yZSBkZXRhaWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv
cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBhbG9uZyB3aXRoIHRo
aXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQorICogRm91
bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEg
IDAyMTExLTEzMDcgIFVTQQorICovCisKKyNpZm5kZWYgX19BUk1fSFlQRVJDQUxMX0hfXwor
I2RlZmluZSBfX0FSTV9IWVBFUkNBTExfSF9fCisjaW5jbHVkZSA8cHVibGljL3BoeXNkZXYu
aD4KKworI2lmbmRlZiBfX0FTU0VNQkxZX18KK2V4dGVybiBsb25nIGRvX3NldF90cmFwX3Rh
YmxlKFhFTl9HVUVTVF9IQU5ETEUodHJhcF9pbmZvX3QpIHRyYXBzKTsKKworZXh0ZXJuIGlu
dCBkb19tbXVfdXBkYXRlKFhFTl9HVUVTVF9IQU5ETEUobW11X3VwZGF0ZV90KSB1cmVxcywK
KwkJCSB1bnNpZ25lZCBpbnQgY291bnQsCisJCQkgWEVOX0dVRVNUX0hBTkRMRSh1aW50KSBw
ZG9uZSwKKwkJCSB1bnNpZ25lZCBpbnQgZm9yZWlnbmRvbSk7CisKK2V4dGVybiBsb25nIGRv
X3NldF9nZHQoWEVOX0dVRVNUX0hBTkRMRSh1bG9uZykgZnJhbWVfbGlzdCwKKwkJICAgICAg
IHVuc2lnbmVkIGludCBlbnRyaWVzKTsKKworZXh0ZXJuIGxvbmcgZG9fc3RhY2tfc3dpdGNo
KHVuc2lnbmVkIGxvbmcgc3MsIHVuc2lnbmVkIGxvbmcgZXNwKTsKKworZXh0ZXJuIGxvbmcg
ZG9fZnB1X3Rhc2tzd2l0Y2goaW50IHNldCk7CisKK2V4dGVybiBsb25nIGRvX3NldF9kZWJ1
Z3JlZyhpbnQgcmVnLCB1bnNpZ25lZCBsb25nIHZhbHVlKTsKKworZXh0ZXJuIHVuc2lnbmVk
IGxvbmcgZG9fZ2V0X2RlYnVncmVnKGludCByZWcpOworCitleHRlcm4gbG9uZyBkb191cGRh
dGVfZGVzY3JpcHRvcih1NjQgcGEsIHU2NCBkZXNjKTsKKworZXh0ZXJuIGludCBkb191cGRh
dGVfdmFfbWFwcGluZyh1MzIgdmEsIHUzMiBmbGFncywgdTY0IHZhbDY0KTsKKworZXh0ZXJu
IGxvbmcgZG9fcGh5c2Rldl9vcChYRU5fR1VFU1RfSEFORExFKHBoeXNkZXZfb3BfdCkgdW9w
KTsKKworZXh0ZXJuIGludCBkb191cGRhdGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbih1bnNp
Z25lZCBsb25nIHZhLAorCQkJCQkgICAgdTY0IHZhbDY0LAorCQkJCQkgICAgdW5zaWduZWQg
bG9uZyBmbGFncywKKwkJCQkJICAgIGRvbWlkX3QgZG9taWQpOworCitleHRlcm4gaW50IGRv
X21tdWV4dF9vcChYRU5fR1VFU1RfSEFORExFKG1tdWV4dF9vcF90KSB1b3BzLAorCQkJdW5z
aWduZWQgaW50IGNvdW50LAorCQkJWEVOX0dVRVNUX0hBTkRMRSh1aW50KSBwZG9uZSwKKwkJ
CXVuc2lnbmVkIGludCBmb3JlaWduZG9tKTsKKworZXh0ZXJuIHVuc2lnbmVkIGxvbmcgZG9f
aXJldCh2b2lkKTsKKworc3RydWN0IHZjcHU7CitleHRlcm4gbG9uZyBhcmNoX2RvX3ZjcHVf
b3AoaW50IGNtZCwgc3RydWN0IHZjcHUgKnYsIFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJn
KTsKKworZXh0ZXJuIGxvbmcgZG9fc2V0X2NhbGxiYWNrcyh1bnNpZ25lZCBsb25nIGV2ZW50
LCB1bnNpZ25lZCBsb25nIGZhaWxzYWZlKTsKKyNlbmRpZiAvKiFfX0FTU0VNQkxZX18qLwor
I2VuZGlmIC8qIV9fQVJNX0hZUEVSQ0FMTF9IX18qLwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4
ZW4vaW5jbHVkZS9hc20tYXJtL2luaXQuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2luaXQuaAlGcmkg
RmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw0IEBACisjaWZuZGVmIF9f
QVJNX0lOSVRfSF9fCisjZGVmaW5lIF9fQVJNX0lOSVRfSF9fCisKKyNlbmRpZiAvKiBfWEVO
X0FTTV9JTklUX0ggKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFy
bS9pby5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vaW8uaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSwzMiBAQAorI2lmbmRlZiBfX0FSTV9JT19IX18KKyNkZWZpbmUg
X19BUk1fSU9fSF9fCisjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisKKyNkZWZpbmUgbW1pb193
cml0ZWIodixhKQkoKih2b2xhdGlsZSB1bnNpZ25lZCBjaGFyICopKGEpID0gKHYpKQorI2Rl
ZmluZSBtbWlvX3dyaXRldyh2LGEpCSgqKHZvbGF0aWxlIHVuc2lnbmVkIHNob3J0ICopKGEp
ID0gKHYpKQorI2RlZmluZSBtbWlvX3dyaXRlbCh2LGEpCSgqKHZvbGF0aWxlIHVuc2lnbmVk
IGludCAqKShhKSA9ICh2KSkKKworI2RlZmluZSBtbWlvX3JlYWRiKGEpCQkoKih2b2xhdGls
ZSB1bnNpZ25lZCBjaGFyICopKGEpKQorI2RlZmluZSBtbWlvX3JlYWR3KGEpCQkoKih2b2xh
dGlsZSB1bnNpZ25lZCBzaG9ydCAqKShhKSkKKyNkZWZpbmUgbW1pb19yZWFkbChhKQkJKCoo
dm9sYXRpbGUgdW5zaWduZWQgaW50ICopKGEpKQorCisjZGVmaW5lIHdyaXRlYih2LGEpCQlt
bWlvX3dyaXRlYih2LGEpCisjZGVmaW5lIHdyaXRldyh2LGEpCQltbWlvX3dyaXRldyh2LGEp
CisKKyNkZWZpbmUgd3JpdGVsKHYsYSkJCW1taW9fd3JpdGVsKHYsYSkKKyNkZWZpbmUgcmVh
ZGIoYSkJCW1taW9fcmVhZGIoYSkKKyNkZWZpbmUgcmVhZHcoYSkJCW1taW9fcmVhZHcoYSkK
KyNkZWZpbmUgcmVhZGwoYSkJCW1taW9fcmVhZGwoYSkKKworI2RlZmluZSBpb3JlbWFwKHgs
bCkJCShfX3ZhKHgpKQorI2RlZmluZSBpb3VubWFwKHApCQkoKHZvaWQpMCkKKworI2RlZmlu
ZSBpbmIoYSkJCQltbWlvX3JlYWRiKGEpCisjZGVmaW5lIGludyhhKQkJCW1taW9fcmVhZHco
YSkKKyNkZWZpbmUgaW5sKGEpCQkJbW1pb19yZWFkbChhKQorCisjZGVmaW5lIG91dGIodixh
KQkJbW1pb193cml0ZWIodixhKQorI2RlZmluZSBvdXR3KHYsYSkJCW1taW9fd3JpdGV3KHYs
YSkKKyNkZWZpbmUgb3V0bCh2LGEpCQltbWlvX3dyaXRlbCh2LGEpCisKKyNlbmRpZgkvKiBf
X0FSTV9JT19IX18gKi8KZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFy
bS9pb2NhcC5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vaW9jYXAuaAlGcmkgRmViIDAzIDE2OjA3OjAz
IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxNSBAQAorI2lmbmRlZiBfX0FSTV9JT0NBUF9IX18K
KyNkZWZpbmUgX19BUk1fSU9DQVBfSF9fCisKKyNkZWZpbmUgaW9wb3J0c19wZXJtaXRfYWNj
ZXNzKGQsIHMsIGUpICAgICAgICAgICAgICAgICAgXAorICAgIHJhbmdlc2V0X2FkZF9yYW5n
ZSgoZCktPmFyY2guaW9wb3J0X2NhcHMsIHMsIGUpCisKKyNkZWZpbmUgaW9wb3J0c19kZW55
X2FjY2VzcyhkLCBzLCBlKSAgICAgICAgICAgICAgICAgICAgXAorICAgIHJhbmdlc2V0X3Jl
bW92ZV9yYW5nZSgoZCktPmFyY2guaW9wb3J0X2NhcHMsIHMsIGUpCisKKyNkZWZpbmUgaW9w
b3J0c19hY2Nlc3NfcGVybWl0dGVkKGQsIHMsIGUpICAgICAgICAgICAgICAgXAorICAgIHJh
bmdlc2V0X2NvbnRhaW5zX3JhbmdlKChkKS0+YXJjaC5pb3BvcnRfY2FwcywgcywgZSkKKwor
I2RlZmluZSBtdWx0aXBhZ2VfYWxsb2NhdGlvbl9wZXJtaXR0ZWQoZCwgb3JkZXIpCSgwKQor
CisjZW5kaWYKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9pb21t
dS5oCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3hlbi9pbmNsdWRlL2FzbS1hcm0vaW9tbXUuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIg
KzA5MDAKQEAgLTAsMCArMSwxNCBAQAorI2lmbmRlZiBfX0FSTV9JT01NVV9IX18KKyNkZWZp
bmUgX19BUk1fSU9NTVVfSF9fCisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCitzdGF0aWMgaW5s
aW5lIGludCBpc19pb21lbV9wYWdlKHVuc2lnbmVkIGxvbmcgbWZuKQoreworCXJldHVybiAw
OworfQorCitpbnQgaW9tbXVfbWFwX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQg
bG9uZyBnZm4sIHVuc2lnbmVkIGxvbmcgbWZuLCB1bnNpZ25lZCBpbnQgZmxhZ3MpOworaW50
IGlvbW11X3VubWFwX3BhZ2Uoc3RydWN0IGRvbWFpbiAqZCwgdW5zaWduZWQgbG9uZyBnZm4p
OworI2VuZGlmIC8qIV9fQVNTRU1CTFlfXyovCisjZW5kaWYgLyohX19BUk1fSU9NTVVfSF9f
Ki8KKwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL2lycS5oCi0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9p
bmNsdWRlL2FzbS1hcm0vaXJxLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBA
IC0wLDAgKzEsNTAgQEAKKyNpZm5kZWYgX19BUk1fSVJRX0hfXworI2RlZmluZSBfX0FSTV9J
UlFfSF9fCisKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CisjaW5jbHVkZSA8eGVuL2NwdW1h
c2suaD4KKworI2lmbmRlZiBOUl9JUlFTCisjZGVmaW5lIE5SX0lSUVMJMjU2CisjZW5kaWYK
KworI2RlZmluZSBkb21haW5fcGlycV90b19pcnEoZCwgcGlycSkJKHBpcnEpCisjZGVmaW5l
IGRvbWFpbl9pcnFfdG9fcGlycShkLCBpcnEpCShpcnEpICAgICAgICAgICAgICAgICAgICAg
ICAKKyNkZWZpbmUgZG9tYWluX3BpcnFfdG9fZW11aXJxKGQsIHBpcnEpCShwaXJxKQorI2Rl
ZmluZSBkb21haW5fZW11aXJxX3RvX3BpcnEoZCwgaXJxKQkoaXJxKQorCisjZGVmaW5lIGly
cV9jZmcoaXJxKQkJKCZpcnFfY2ZnW2lycV0pCisjZGVmaW5lIGlycV90b19kZXNjKGlycSkJ
KCZpcnFfZGVzY1tpcnFdKQkKKworI2RlZmluZSBJUlFfTUFYX0dVRVNUUwkJNwordHlwZWRl
ZiBzdHJ1Y3QgeworCXVuc2lnbmVkIGludCBhY2tfdHlwZTsKKyAgICAgICAgdW5zaWduZWQg
Y2hhciBucl9ndWVzdHM7CisgICAgICAgIHVuc2lnbmVkIGNoYXIgaW5fZmxpZ2h0OworICAg
ICAgICB1bnNpZ25lZCBjaGFyIHNoYXJlYWJsZTsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
Z3Vlc3RbSVJRX01BWF9HVUVTVFNdOworfSBpcnFfZ3Vlc3RfYWN0aW9uX3Q7CisKK3N0cnVj
dCBpcnFfY2ZnIHsKKwlpbnQgaXJxOworfTsKKworc3RydWN0IGFyY2hfaXJxX2Rlc2Mgewor
fTsKKworc3RydWN0IGFyY2hfcGlycSB7CisJaW50IGlycTsKK307CisKK3R5cGVkZWYgc3Ry
dWN0IHsKKyAgICBERUNMQVJFX0JJVE1BUChfYml0cyxOUl9JUlFTKTsKK30gdm1hc2tfdDsK
KworZXh0ZXJuIHN0cnVjdCBpcnFfZGVzYyAqaXJxX2Rlc2M7CisKK3N0YXRpYyBpbmxpbmUg
aW50IGlycV9kZXNjX2luaXRpYWxpemVkKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykKK3sKKwly
ZXR1cm4gMDsKK30KKworI2VuZGlmIC8qIF9fQVJNX0lSUV9IX18gKi8KZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9tbS5oCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW0u
aAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyMzcgQEAKKyNp
Zm5kZWYgX19BUk1fTU1fSF9fCisjZGVmaW5lIF9fQVJNX01NX0hfXworCisjaW5jbHVkZSA8
eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPHhlbi9saXN0Lmg+CisjaW5jbHVkZSA8YXNtL3Ay
bS5oPgorI2luY2x1ZGUgPGFzbS9pb21tdS5oPgorI2luY2x1ZGUgPGFzbS9tbXUuaD4KKyNp
bmNsdWRlIDxhc20vaW8uaD4KKyNpbmNsdWRlIDxhc20vZmx1c2h0bGIuaD4KKworI2RlZmlu
ZSBJTlZBTElEX0dGTgkJKH4wVUwpCisjZGVmaW5lIElOVkFMSURfTUZOICAgICAgICAgICAg
ICh+MFVMKQorI2RlZmluZSBJTlZBTElEX00yUF9FTlRSWQkofjBVTCkKKworI2RlZmluZSBW
QUxJRF9NMlAoX2UpICAgICAgICAgICAgKCEoKF9lKSAmICgxVUw8PChCSVRTX1BFUl9MT05H
LTEpKSkpCisjZGVmaW5lIFNIQVJFRF9NMlBfRU5UUlkgICAgICAgICAofjBVTCAtIDFVTCkK
KyNkZWZpbmUgU0hBUkVEX00yUChfZSkgICAgICAgICAgICgoX2UpID09IFNIQVJFRF9NMlBf
RU5UUlkpCisKKyNkZWZpbmUgUEZOX09SREVSKF9wZm4pCQkoKF9wZm4pLT52LmZyZWUub3Jk
ZXIpCisKKyNkZWZpbmUgUEFHRV9UWVBFKHBhZ2UpCQkoKChwYWdlKS0+dS5pbnVzZS50eXBl
X2luZm8pICYgUEdUX3R5cGVfbWFzayApCisKKyNkZWZpbmUgcGlja2xlX2RvbXB0cihfZCkJ
KCh1MzIpKHVuc2lnbmVkIGxvbmcpKF9kKSkKKyNkZWZpbmUgdW5waWNrbGVfZG9tcHRyKF9k
KQkoKHN0cnVjdCBkb21haW4gKikodW5zaWduZWQgbG9uZykoX2QpKQorCisjZGVmaW5lIFBS
dHlwZV9pbmZvCQkiMDhseCIKKworI2RlZmluZSBwYWdlX2dldF9vd25lcihfcCkJKHVucGlj
a2xlX2RvbXB0cigoX3ApLT52LmludXNlLl9kb21haW4pKQorI2RlZmluZSBwYWdlX3NldF9v
d25lcihfcCxfZCkJKChfcCktPnYuaW51c2UuX2RvbWFpbiA9IHBpY2tsZV9kb21wdHIoX2Qp
KQorCisjZGVmaW5lIFhFTlNIQVJFX3dyaXRhYmxlIAkwCisjZGVmaW5lIFhFTlNIQVJFX3Jl
YWRvbmx5IAkxCisKKworI2RlZmluZSBQR19zaGlmdChpZHgpCQkoQklUU19QRVJfTE9ORyAt
IChpZHgpKQorI2RlZmluZSBQR19tYXNrKHgsIGlkeCkJCSh4ICMjIFVMIDw8IFBHX3NoaWZ0
KGlkeCkpCisKKyNkZWZpbmUgUEdUX25vbmUJCVBHX21hc2soMCwgNCkgIC8qIG5vIHNwZWNp
YWwgdXNlcyBvZiB0aGlzIHBhZ2UgICAqLworI2RlZmluZSBQR1RfbDFfcGFnZV90YWJsZQlQ
R19tYXNrKDEsIDQpICAvKiB1c2luZyBhcyBhbiBMMSBwYWdlIHRhYmxlPyAgICAgKi8KKyNk
ZWZpbmUgUEdUX2wyX3BhZ2VfdGFibGUJUEdfbWFzaygyLCA0KSAgLyogdXNpbmcgYXMgYW4g
TDIgcGFnZSB0YWJsZT8gICAgICovCisjZGVmaW5lIFBHVF9sM19wYWdlX3RhYmxlCVBHX21h
c2soMywgNCkgIC8qIHVzaW5nIGFzIGFuIEwzIHBhZ2UgdGFibGU/ICAgICAqLworI2RlZmlu
ZSBQR1Rfd3JpdGFibGVfcGFnZQlQR19tYXNrKDcsIDQpICAvKiBoYXMgd3JpdGFibGUgbWFw
cGluZ3M/ICAgICAgICAgKi8KKyNkZWZpbmUgUEdUX3NoYXJlZF9wYWdlCQlQR19tYXNrKDgs
IDQpICAvKiBDb1cgc2hhcmFibGUgcGFnZSAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgUEdU
X3R5cGVfbWFzawkJUEdfbWFzaygxNSwgNCkgLyogQml0cyAyOC0zMSBvciA2MC02My4gICAg
ICAgICAgICovCisKKyAvKiBPd25pbmcgZ3Vlc3QgaGFzIHBpbm5lZCB0aGlzIHBhZ2UgdG8g
aXRzIGN1cnJlbnQgdHlwZT8gKi8KKyNkZWZpbmUgX1BHVF9waW5uZWQJCVBHX3NoaWZ0KDUp
CisjZGVmaW5lIFBHVF9waW5uZWQJCVBHX21hc2soMSwgNSkKKworIC8qIEhhcyB0aGlzIHBh
Z2UgYmVlbiB2YWxpZGF0ZWQgZm9yIHVzZSBhcyBpdHMgY3VycmVudCB0eXBlPyAqLworI2Rl
ZmluZSBfUEdUX3ZhbGlkYXRlZAkJUEdfc2hpZnQoNikKKyNkZWZpbmUgUEdUX3ZhbGlkYXRl
ZAkJUEdfbWFzaygxLCA2KQorCisvKiBIYXMgdGhpcyBwYWdlIGJlZW4gKnBhcnRpYWxseSog
dmFsaWRhdGVkIGZvciB1c2UgYXMgaXRzIGN1cnJlbnQgdHlwZT8gKi8KKyNkZWZpbmUgX1BH
VF9wYXJ0aWFsCQlQR19zaGlmdCg4KQorI2RlZmluZSBQR1RfcGFydGlhbAkJUEdfbWFzaygx
LCA4KQorCisgLyogUGFnZSBpcyBsb2NrZWQ/ICovCisjZGVmaW5lIF9QR1RfbG9ja2VkCQlQ
R19zaGlmdCg5KQorI2RlZmluZSBQR1RfbG9ja2VkCQlQR19tYXNrKDEsIDkpCisKKyAvKiBD
b3VudCBvZiB1c2VzIG9mIHRoaXMgZnJhbWUgYXMgaXRzIGN1cnJlbnQgdHlwZS4gKi8KKyNk
ZWZpbmUgUEdUX2NvdW50X3dpZHRoCQlQR19zaGlmdCg5KQorI2RlZmluZSBQR1RfY291bnRf
bWFzawkJKCgxVUw8PFBHVF9jb3VudF93aWR0aCktMSkKKworIC8qIENsZWFyZWQgd2hlbiB0
aGUgb3duaW5nIGd1ZXN0ICdmcmVlcycgdGhpcyBwYWdlLiAqLworI2RlZmluZSBfUEdDX2Fs
bG9jYXRlZAkJUEdfc2hpZnQoMSkKKyNkZWZpbmUgUEdDX2FsbG9jYXRlZAkJUEdfbWFzaygx
LCAxKQorCisgLyogUGFnZSBpcyBYZW4gaGVhcD8gKi8KKyNkZWZpbmUgX1BHQ194ZW5faGVh
cAkJUEdfc2hpZnQoMikKKyNkZWZpbmUgUEdDX3hlbl9oZWFwCQlQR19tYXNrKDEsIDIpCisK
KyAvKiBTZXQgd2hlbiBpcyB1c2luZyBhIHBhZ2UgYXMgYSBwYWdlIHRhYmxlICovCisjZGVm
aW5lIF9QR0NfcGFnZV90YWJsZQkJUEdfc2hpZnQoMykKKyNkZWZpbmUgUEdDX3BhZ2VfdGFi
bGUJCVBHX21hc2soMSwgMykKKworIC8qIFBhZ2UgaXMgYnJva2VuPyAqLworI2RlZmluZSBf
UEdDX2Jyb2tlbgkJUEdfc2hpZnQoNykKKyNkZWZpbmUgUEdDX2Jyb2tlbgkJUEdfbWFzaygx
LCA3KQorCisgLyogTXV0dWFsbHktZXhjbHVzaXZlIHBhZ2Ugc3RhdGVzOiB7IGludXNlLCBv
ZmZsaW5pbmcsIG9mZmxpbmVkLCBmcmVlIH0uICovCisjZGVmaW5lIFBHQ19zdGF0ZQkJUEdf
bWFzaygzLCA5KQorI2RlZmluZSBQR0Nfc3RhdGVfaW51c2UJCVBHX21hc2soMCwgOSkKKyNk
ZWZpbmUgUEdDX3N0YXRlX29mZmxpbmluZwlQR19tYXNrKDEsIDkpCisjZGVmaW5lIFBHQ19z
dGF0ZV9vZmZsaW5lZAlQR19tYXNrKDIsIDkpCisjZGVmaW5lIFBHQ19zdGF0ZV9mcmVlCQlQ
R19tYXNrKDMsIDkpCisKKyNkZWZpbmUgcGFnZV9zdGF0ZV9pcyhwZywgc3QpCVwKKwkoKChw
ZyktPmNvdW50X2luZm8mUEdDX3N0YXRlKSA9PSBQR0Nfc3RhdGVfIyNzdCkKKworIC8qIENv
dW50IG9mIHJlZmVyZW5jZXMgdG8gdGhpcyBmcmFtZS4gKi8KKyNkZWZpbmUgUEdDX2NvdW50
X3dpZHRoCQlQR19zaGlmdCg5KQorI2RlZmluZSBQR0NfY291bnRfbWFzawkJKCgxVUw8PFBH
Q19jb3VudF93aWR0aCktMSkKKworI2RlZmluZSBzZXRfZ3Bmbl9mcm9tX21mbihtZm4sIHBm
bikgXAorCWRvIHsgfSB3aGlsZSgwKQorCisjZGVmaW5lIGdldF9ncGZuX2Zyb21fbWZuKG1m
bikJKChtZm4pKQorCisjZGVmaW5lIG1mbl90b19nbWZuKF9kLCBtZm4pCShtZm4pCisKKyNk
ZWZpbmUgZ21mbl90b19tZm4oX2QsIGdwZm4pCShncGZuKQorCisjZGVmaW5lIGRvbWFpbl9z
ZXRfYWxsb2NfYml0c2l6ZShkKQkoKHZvaWQpMCkKKyNkZWZpbmUgZG9tYWluX2NsYW1wX2Fs
bG9jX2JpdHNpemUoZCxiKQkoYikKKworI2RlZmluZSB3cml0ZV9wdGJhc2UodikJY3B1X3N3
aXRjaF90dGIoKHYpLT5hcmNoLmN0eC50dGJyMCkKKworc3RydWN0IHBhZ2VfaW5mbworewor
CXN0cnVjdCBwYWdlX2xpc3RfZW50cnkgbGlzdDsKKworCS8qIFJlZmVyZW5jZSBjb3VudCBh
bmQgdmFyaW91cyBQR0NfeHh4IGZsYWdzIGFuZCBmaWVsZHMuICovCisJdW5zaWduZWQgbG9u
ZyBjb3VudF9pbmZvOworCisJLyogQ29udGV4dC1kZXBlbmRlbnQgZmllbGRzIGZvbGxvdy4u
LiAqLworCXVuaW9uIHsKKwkJLyogUGFnZSBpcyBpbiB1c2U6ICgoY291bnRfaW5mbyAmIFBH
Q19jb3VudF9tYXNrKSAhPSAwKS4gKi8KKwkJc3RydWN0IHsKKwkJCS8qIFR5cGUgcmVmZXJl
bmNlIGNvdW50IGFuZCB2YXJpb3VzIFBHVF94eHggZmxhZ3MgYW5kIGZpZWxkcy4gKi8KKwkJ
CXVuc2lnbmVkIGxvbmcgdHlwZV9pbmZvOworCQl9IGludXNlOworCisJCS8qIFBhZ2UgaXMg
b24gYSBmcmVlIGxpc3Q6ICgoY291bnRfaW5mbyAmIFBHQ19jb3VudF9tYXNrKSA9PSAwKS4g
Ki8KKwkJc3RydWN0IHsKKwkJCS8qIERvIFRMQnMgbmVlZCBmbHVzaGluZyBmb3Igc2FmZXR5
IGJlZm9yZSBuZXh0IHBhZ2UgdXNlPyAqLworCQkJYm9vbF90IG5lZWRfdGxiZmx1c2g7CisJ
CX0gZnJlZTsKKwl9IHU7CisKKwl1bmlvbiB7CisJCS8qIFBhZ2UgaXMgaW4gdXNlLCBidXQg
bm90IGFzIGEgc2hhZG93LiAqLworCQlzdHJ1Y3QgeworCQkJLyogT3duZXIgb2YgdGhpcyBw
YWdlICh6ZXJvIGlmIHBhZ2UgaXMgYW5vbnltb3VzKS4gKi8KKwkJCXVuc2lnbmVkIGxvbmcg
X2RvbWFpbjsKKwkJfSBpbnVzZTsKKworCQkvKiBQYWdlIGlzIG9uIGEgZnJlZSBsaXN0LiAq
LworCQlzdHJ1Y3QgeworCQkJLyogT3JkZXItc2l6ZSBvZiB0aGUgZnJlZSBjaHVuayB0aGlz
IHBhZ2UgaXMgdGhlIGhlYWQgb2YuICovCisJCQl1bnNpZ25lZCBpbnQgb3JkZXI7CisJCX0g
ZnJlZTsKKwl9IHY7CisKKwkvKgorCSAqIFRpbWVzdGFtcCBmcm9tICdUTEIgY2xvY2snLCB1
c2VkIHRvIGF2b2lkIGV4dHJhIHNhZmV0eSBmbHVzaGVzLgorCSAqIE9ubHkgdmFsaWQgZm9y
OiBhKSBmcmVlIHBhZ2VzLCBhbmQgYikgcGFnZXMgd2l0aCB6ZXJvIHR5cGUgY291bnQKKwkg
KiAoZXhjZXB0IHBhZ2UgdGFibGUgcGFnZXMgd2hlbiB0aGUgZ3Vlc3QgaXMgaW4gc2hhZG93
IG1vZGUpLgorCSAqLworCXUzMiB0bGJmbHVzaF90aW1lc3RhbXA7Cit9OworCisjaWZuZGVm
IE5ERUJVRworI2RlZmluZSBUWVBFX1NBRkVUWSAxCisjZW5kaWYKKworI2lmZGVmIFRZUEVf
U0FGRVRZCisjZGVmaW5lIFRZUEVfU0FGRShfdHlwZSxfbmFtZSkJCQkJCQlcCit0eXBlZGVm
IHN0cnVjdCB7IF90eXBlIF9uYW1lOyB9IF9uYW1lIyNfdDsJCQkJXAorc3RhdGljIGlubGlu
ZSBfbmFtZSMjX3QgXyMjX25hbWUoX3R5cGUgbikgeyByZXR1cm4gKF9uYW1lIyNfdCkgeyBu
IH07IH0gXAorc3RhdGljIGlubGluZSBfdHlwZSBfbmFtZSMjX3goX25hbWUjI190IG4pIHsg
cmV0dXJuIG4uX25hbWU7IH0KKyNlbHNlCisjZGVmaW5lIFRZUEVfU0FGRShfdHlwZSxfbmFt
ZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCit0eXBlZGVm
IF90eXBlIF9uYW1lIyNfdDsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCitzdGF0aWMgaW5saW5lIF9uYW1lIyNfdCBfIyNfbmFtZShfdHlwZSBu
KSB7IHJldHVybiBuOyB9ICAgICAgICAgICAgICAgICBcCitzdGF0aWMgaW5saW5lIF90eXBl
IF9uYW1lIyNfeChfbmFtZSMjX3QgbikgeyByZXR1cm4gbjsgfQorI2VuZGlmCisKK1RZUEVf
U0FGRSh1bnNpZ25lZCBsb25nLG1mbik7CisKKyNpZmRlZiBNRU1PUllfR1VBUkQKK3ZvaWQg
bWVtZ3VhcmRfaW5pdCh2b2lkKTsKK3ZvaWQgbWVtZ3VhcmRfZ3VhcmRfcmFuZ2Uodm9pZCAq
cCwgdW5zaWduZWQgbG9uZyBsKTsKK3ZvaWQgbWVtZ3VhcmRfdW5ndWFyZF9yYW5nZSh2b2lk
ICpwLCB1bnNpZ25lZCBsb25nIGwpOworI2Vsc2UKKyNkZWZpbmUgbWVtZ3VhcmRfaW5pdCgp
ICAgICAgICAgICAgICAgICgodm9pZCkwKQorI2RlZmluZSBtZW1ndWFyZF9ndWFyZF9yYW5n
ZShfcCxfbCkgICAgKCh2b2lkKTApCisjZGVmaW5lIG1lbWd1YXJkX3VuZ3VhcmRfcmFuZ2Uo
X3AsX2wpICAoKHZvaWQpMCkKKyNlbmRpZiAvKiBNRU1PUllfR1VBUkQgKi8KKworZXh0ZXJu
IHVuc2lnbmVkIGxvbmcgeGVuaGVhcF9waHlzX3N0YXJ0LCB4ZW5oZWFwX3BoeXNfZW5kOwor
ZXh0ZXJuIHVuc2lnbmVkIGxvbmcgeGVuX3BoeXNfc3RhcnQsIHhlbl9waHlzX2VuZDsKK2V4
dGVybiB1bnNpZ25lZCBsb25nIG1pbl9wYWdlLCBtYXhfcGFnZTsKKworZXh0ZXJuIHN0cnVj
dCBkb21haW4gKmRvbV94ZW4sICpkb21faW8sICpkb21fY293OworZXh0ZXJuIHN0cnVjdCBw
YWdlX2luZm8gKmZyYW1lX3RhYmxlOworCit2b2lkIG1lbWd1YXJkX2d1YXJkX3N0YWNrKHZv
aWQgKnApOworCit2b2lkIHNoYXJlX3hlbl9wYWdlX3dpdGhfZ3Vlc3Qoc3RydWN0IHBhZ2Vf
aW5mbyAqcGFnZSwgc3RydWN0IGRvbWFpbiAqZCwgaW50IHJlYWRvbmx5KTsKK3ZvaWQgc2hh
cmVfeGVuX3BhZ2Vfd2l0aF9wcml2aWxlZ2VkX2d1ZXN0cyhzdHJ1Y3QgcGFnZV9pbmZvICpw
YWdlLCBpbnQgcmVhZG9ubHkpOworCitpbnQgYWxsb2NfcGFnZV90eXBlKHN0cnVjdCBwYWdl
X2luZm8gKnBhZ2UsIHVuc2lnbmVkIGxvbmcgdHlwZSk7Cit2b2lkIGZyZWVfcGFnZV90eXBl
KHN0cnVjdCBwYWdlX2luZm8gKnBhZ2UsIHVuc2lnbmVkIGxvbmcgdHlwZSk7CisKK3ZvaWQg
cHV0X3BhZ2Uoc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSk7CitpbnQgIGdldF9wYWdlKHN0cnVj
dCBwYWdlX2luZm8gKnBhZ2UsIHN0cnVjdCBkb21haW4gKmRvbWFpbik7CisKK3ZvaWQgcHV0
X3BhZ2VfdHlwZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlKTsKK2ludCAgZ2V0X3BhZ2VfdHlw
ZShzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlLCB1bnNpZ25lZCBsb25nIHR5cGUpOworCitzdHJ1
Y3QgZG9tYWluICpwYWdlX2dldF9vd25lcl9hbmRfcmVmZXJlbmNlKHN0cnVjdCBwYWdlX2lu
Zm8gKnBhZ2UpOworCitpbnQgaXNfaW9tZW1fcGFnZSh1bnNpZ25lZCBsb25nIG1mbik7CisK
K2ludCBzdGVhbF9wYWdlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwYWdlX2luZm8gKnBh
Z2UsIHVuc2lnbmVkIGludCBtZW1mbGFncyk7CitpbnQgZG9uYXRlX3BhZ2Uoc3RydWN0IGRv
bWFpbiAqZCwgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZSwgdW5zaWduZWQgaW50IG1lbWZsYWdz
KTsKKwordW5zaWduZWQgbG9uZyBkb21haW5fZ2V0X21heGltdW1fZ3BmbihzdHJ1Y3QgZG9t
YWluICpkKTsKKworbG9uZyBhcmNoX21lbW9yeV9vcChpbnQgb3AsIFhFTl9HVUVTVF9IQU5E
TEUodm9pZCkgYXJnKTsKKworaW50IG1hcF9wYWdlc190b194ZW4odW5zaWduZWQgbG9uZyB2
aXJ0LCB1bnNpZ25lZCBsb25nIG1mbiwgaW50IG5yLCB1bnNpZ25lZCBsb25nIGZsYWdzKTsK
Kworc3RhdGljIGlubGluZSB2b2lkIHB1dF9wYWdlX2FuZF90eXBlKHN0cnVjdCBwYWdlX2lu
Zm8gKnBhZ2UpCit7CisJcHV0X3BhZ2VfdHlwZShwYWdlKTsKKwlwdXRfcGFnZShwYWdlKTsK
K30KKworc3RhdGljIGlubGluZSBpbnQgZ2V0X3BhZ2VfYW5kX3R5cGUoc3RydWN0IHBhZ2Vf
aW5mbyAqcGFnZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVj
dCBkb21haW4gKmRvbWFpbiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHVuc2lnbmVkIGxvbmcgdHlwZSkKK3sKKwlpbnQgcmMgPSBnZXRfcGFnZShwYWdlLCBkb21h
aW4pOworCisJaWYgKCBsaWtlbHkocmMpICYmIHVubGlrZWx5KCFnZXRfcGFnZV90eXBlKHBh
Z2UsIHR5cGUpKSApIHsKKwkJcHV0X3BhZ2UocGFnZSk7CisJCXJjID0gMDsKKwl9CisKKwly
ZXR1cm4gcmM7Cit9CisKKyNlbmRpZiAvKiBfX0FSTV9NTV9IX18gKi8KZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaAotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL21t
dS5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDExIEBACisj
aWZuZGVmIF9fQVJNX01NVV9IX18KKyNkZWZpbmUgX19BUk1fTU1VX0hfXworCisjZGVmaW5l
IFBBRERSX0JJVFMgICAgICAgICAgICAgIDMyCisjZGVmaW5lIFBBRERSX01BU0sgICAgICAg
ICAgICAgICgoMVVMIDw8IFBBRERSX0JJVFMpIC0gMSkKKworI2RlZmluZSBWQUREUl9CSVRT
ICAgICAgICAgICAgICAzMgorI2RlZmluZSBWQUREUl9NQVNLICAgICAgICAgICAgICAoKDFV
TCA8PCBWQUREUl9CSVRTKSAtIDEpCisKKyNlbmRpZgorCmRpZmYgLXIgZTcwMTQ2MWIxMjUx
IHhlbi9pbmNsdWRlL2FzbS1hcm0vbXVsdGljYWxsLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9tdWx0
aWNhbGwuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw5IEBA
CisKKyNpZm5kZWYgX19BUk1fTVVMVElDQUxMX0hfXworI2RlZmluZSBfX0FSTV9NVUxUSUNB
TExfSF9fCisKKyNpbmNsdWRlIDx4ZW4vZXJybm8uaD4KKworI2RlZmluZSBkb19tdWx0aWNh
bGxfY2FsbChfY2FsbCkKKworI2VuZGlmIC8qIF9fQVJNX01VTFRJQ0FMTF9IX18gKi8KZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9udW1hLmgKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUv
YXNtLWFybS9udW1hLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAg
KzEsMjEgQEAKKyNpZm5kZWYgX19BUk1fTlVNQV9IX18gCisjZGVmaW5lIF9fQVJNX05VTUFf
SF9fCisKKyNpbmNsdWRlIDx4ZW4vY3B1bWFzay5oPgorCisjZGVmaW5lIE5PREVTX1NISUZU
IAkwCisjZGVmaW5lIE1BWF9OVU1OT0RFUwkoMSA8PCBOT0RFU19TSElGVCkKKworCisjZGVm
aW5lIE5VTUFfTk9fTk9ERQkweEZGCisKK2V4dGVybiB1bnNpZ25lZCBjaGFyIGNwdV90b19u
b2RlW107CitleHRlcm4gY3B1bWFza190ICAgICBub2RlX3RvX2NwdW1hc2tbXTsKKworI2Rl
ZmluZSBjcHVfdG9fbm9kZShjcHUpCShjcHVfdG9fbm9kZVtjcHVdKQorI2RlZmluZSBwYXJl
bnRfbm9kZShub2RlKQkobm9kZSkKKyNkZWZpbmUgbm9kZV90b19maXJzdF9jcHUobm9kZSkJ
KF9fZmZzKG5vZGVfdG9fY3B1bWFza1tub2RlXSkpCisjZGVmaW5lIG5vZGVfdG9fY3B1bWFz
ayhub2RlKQkobm9kZV90b19jcHVtYXNrW25vZGVdKQorCisjZGVmaW5lIHBoeXNfdG9fbmlk
KGFkZHIpCSgwKQorI2VuZGlmCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2Fz
bS1hcm0vcDJtLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9wMm0uaAlGcmkgRmViIDAzIDE2OjA3OjAz
IDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMCBAQAorI2lmbmRlZiBfX0FSTV9QMk1fSF9fCisj
ZGVmaW5lIF9fQVJNX1AyTV9IX18KKworI2RlZmluZSBnZm5fdG9fbWZuKGQsIGcsIHQpCQko
ZykKKyNkZWZpbmUgZ2ZuX3RvX21mbl9xdWVyeShkLCBnLCB0KQkoZykKKyNkZWZpbmUgZ2Zu
X3RvX21mbl9ndWVzdChkLCBnLCB0KQkoZykKKyNkZWZpbmUgZ2ZuX3RvX21mbl91bnNoYXJl
KGQsIGcsIHQpCShnKQorCisjZGVmaW5lIHB1dF9nZm4oZCwgZ2ZuKQorI2VuZGlmCmRpZmYg
LXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vcGFnZS5oCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS1hcm0vcGFnZS5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsx
LDk1IEBACisjaWZuZGVmIF9fQVJNX1BBR0VfSF9fCisjZGVmaW5lIF9fQVJNX1BBR0VfSF9f
CisKKyNpbmNsdWRlIDxhc20vY29uZmlnLmg+CisjaW5jbHVkZSA8YXNtL3R5cGVzLmg+CisK
KyNkZWZpbmUgUEFHRV9TSElGVAkJMTIKKyNkZWZpbmUgUEFHRV9TSVpFCQkoMSA8PCBQQUdF
X1NISUZUKQorI2RlZmluZSBQQUdFX01BU0sJCSh+KFBBR0VfU0laRSAtIDEpKQorCisjZGVm
aW5lIFBBR0VfQUxJR04oeCkJCSgoKHgpICsgUEFHRV9TSVpFIC0gMSkgJiBQQUdFX01BU0sp
CisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCisjaW5jbHVkZSA8eGVuL2xpYi5oPgorCisjZGVm
aW5lIGNsZWFyX3BhZ2UoX3ApCQltZW1zZXQoKHZvaWQgKikoX3ApLCAwLCBQQUdFX1NJWkUp
CisjZGVmaW5lIGNvcHlfcGFnZShfdCwgX2YpCW1lbWNweSgodm9pZCAqKShfdCksICh2b2lk
ICopKF9mKSwgUEFHRV9TSVpFKTsKKworc3RhdGljIGlubGluZSBpbnQgZ2V0X29yZGVyX2Zy
b21fYnl0ZXModW5zaWduZWQgbG9uZyBzaXplKQoreworCWludCBvcmRlcjsKKworCXNpemUg
PSAoc2l6ZSAtIDEpID4+IFBBR0VfU0hJRlQ7CisJZm9yICggb3JkZXIgPSAwOyBzaXplOyBv
cmRlcisrICkKKwkJc2l6ZSA+Pj0gMTsKKworCXJldHVybiBvcmRlcjsKK30KKworc3RhdGlj
IGlubGluZSBpbnQgZ2V0X29yZGVyX2Zyb21fcGFnZXModW5zaWduZWQgbG9uZyBucl9wYWdl
cykKK3sKKwlpbnQgb3JkZXI7CisKKwlucl9wYWdlcy0tOworCWZvciAoIG9yZGVyID0gMDsg
bnJfcGFnZXM7IG9yZGVyKysgKQorCQlucl9wYWdlcyA+Pj0gMTsKKworCXJldHVybiBvcmRl
cjsKK30KKworLyogQ29udmVydCBiZXR3ZWVuIFhlbi1oZWFwIHZpcnR1YWwgYWRkcmVzc2Vz
IGFuZCBtYWNoaW5lIGFkZHJlc3Nlcy4gKi8KKworI2RlZmluZSB2aXJ0X3RvX21hZGRyKGFk
ZHIpCV9fdmlydF90b19tYWRkcigodm9pZCAqKShhZGRyKSkKKyNkZWZpbmUgbWFkZHJfdG9f
dmlydChhZGRyKQlfX21hZGRyX3RvX3ZpcnQoKHBhZGRyX3QpKGFkZHIpKQorCisjZGVmaW5l
IHZpcnRfdG9fbWZuKGFkZHIpCSh2aXJ0X3RvX21hZGRyKGFkZHIpID4+IFBBR0VfU0hJRlQp
CisKKyNkZWZpbmUgdmlydF90b19wYWdlKGFkZHIpCShtZm5fdG9fcGFnZSh2aXJ0X3RvX21h
ZGRyKGFkZHIpID4+IFBBR0VfU0hJRlQpKQorI2RlZmluZSBwYWdlX3RvX3ZpcnQoX3BhZ2Up
CW1hZGRyX3RvX3ZpcnQocGFnZV90b19tZm4oX3BhZ2UpIDw8IFBBR0VfU0hJRlQpCisKKyNk
ZWZpbmUgX19wYShhZGRyKQkJKHZpcnRfdG9fbWFkZHIoYWRkcikpCisjZGVmaW5lIF9fdmEo
YWRkcikJCShtYWRkcl90b192aXJ0KGFkZHIpKQorCisKKyNkZWZpbmUgbWZuX3ZhbGlkKF9w
Zm4pCQkoKChfcGZuKSA+PSBtaW5fcGFnZSkgJiYgKChfcGZuKSA8PSBtYXhfcGFnZSkpCisK
KyNkZWZpbmUgbWZuX3RvX3BhZ2UoX3BmbikJKChzdHJ1Y3QgcGFnZV9pbmZvICopKGZyYW1l
X3RhYmxlICsgKChfcGZuKSAtIG1pbl9wYWdlKSkpCisjZGVmaW5lIHBhZ2VfdG9fbWZuKF9w
YWdlKQkoKHVuc2lnbmVkIGxvbmcpKChfcGFnZSArIG1pbl9wYWdlKSAtIGZyYW1lX3RhYmxl
ICkpCisjZGVmaW5lIHBhZ2VfdG9fbWFkZHIoX3BhZ2UpCShwYWdlX3RvX21mbihfcGFnZSkg
PDwgUEFHRV9TSElGVCkKKyNkZWZpbmUgbWFkZHJfdG9fcGFnZShhZGRyKQltZm5fdG9fcGFn
ZSgoYWRkciA+PiBQQUdFX1NISUZUKSkKKworI2RlZmluZSBtZm5fdG9fdmlydChfbWZuKQko
bWFkZHJfdG9fdmlydCgoKF9tZm4pIDw8IFBBR0VfU0hJRlQpKSkKKworI2RlZmluZSBwYWRk
cl90b19wZm4oYWRkcikJKCh1bnNpZ25lZCBsb25nKSgoYWRkcikgPj4gUEFHRV9TSElGVCkp
CisKKyNkZWZpbmUgaXNfeGVuX2hlYXBfbWZuKF9wZm4pCQkJXAorKHsJCQkJCQlcCisJdW5z
aWduZWQgbG9uZyBwaHlzOwkJCVwKKwlwaHlzID0gKF9wZm4pIDw8IFBBR0VfU0hJRlQ7CQlc
CisJKChwaHlzID49IHhlbmhlYXBfcGh5c19zdGFydCkgJiYJXAorCSAocGh5cyA8IHhlbmhl
YXBfcGh5c19lbmQpKTsJCVwKK30pCisKKyNkZWZpbmUgaXNfeGVuX2hlYXBfcGFnZShwYWdl
KSAgICAgICAgICAgICAgICAgIFwKKwlpc194ZW5faGVhcF9tZm4ocGFnZV90b19tZm4ocGFn
ZSkpCisKKyNkZWZpbmUgaXNfeGVuX2ZpeGVkX21mbihfbWZuKQkJCVwKKwlpc194ZW5faGVh
cF9tZm4oX21mbikKKworZXh0ZXJuIHVuc2lnbmVkIGxvbmcgeGVuX3BoeXNfc3RhcnQ7Citz
dGF0aWMgaW5saW5lIHBhZGRyX3QgX192aXJ0X3RvX21hZGRyKHZvaWQgKmFkZHIpCit7CisJ
cmV0dXJuIChwYWRkcl90KShhZGRyKSAtIFhFTl9WSVJUX1NUQVJUICsgeGVuX3BoeXNfc3Rh
cnQ7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCAqX19tYWRkcl90b192aXJ0KHVuc2lnbmVk
IGxvbmcgYWRkcikKK3sKKwlyZXR1cm4gKHZvaWQgKikoKGFkZHIpICsgWEVOX1ZJUlRfU1RB
UlQgLSB4ZW5fcGh5c19zdGFydCk7Cit9CisKKyNkZWZpbmUgX19wYWdlX2FsaWduZWRfXyBc
CisgICAgX19hdHRyaWJ1dGVfdXNlZF9fIF9fYXR0cmlidXRlX18gKChfX3NlY3Rpb25fXyAo
Ii5ic3MucGFnZV9hbGlnbmVkIikpKQorCisjZW5kaWYgLyogIV9fQVNTRU1CTFlfXyAqLwor
I2VuZGlmIC8qIF9fQVJNX1BBR0VfSF9fICovCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9p
bmNsdWRlL2FzbS1hcm0vcGNpLmgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFybS9wY2kuaAlGcmkgRmViIDAz
IDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSw5IEBACisjaWZuZGVmIF9fQVNNX1BD
SV9IX18KKyNkZWZpbmUgX19BU01fUENJX0hfXworCitzdHJ1Y3QgYXJjaF9wY2lfZGV2IHsK
K307CisKKworI2VuZGlmCisKZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNt
LWFybS9wZXJjcHUuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3BlcmNwdS5oCUZyaSBGZWIgMDMgMTY6
MDc6MDMgMjAxMiArMDkwMApAQCAtMCwwICsxLDE2IEBACisjaWZuZGVmIF9fQVJNX1BFUkNQ
VV9IX18KKyNkZWZpbmUgX19BUk1fUEVSQ1BVX0hfXworCisjaWZuZGVmIF9fQVNTRU1CTFlf
XworI2RlZmluZSBfX0RFRklORV9QRVJfQ1BVKHR5cGUsIG5hbWUsIHN1ZmZpeCkgXAorCV9f
dHlwZW9mX18odHlwZSkgcGVyX2NwdV8jI25hbWVbTlJfQ1BVU10gPSB7MCx9CisKKyNkZWZp
bmUgREVDTEFSRV9QRVJfQ1BVKHR5cGUsIG5hbWUpIFwKKwlleHRlcm4gX190eXBlb2ZfXyh0
eXBlKSBwZXJfY3B1X18jI25hbWVbTlJfQ1BVU10KKworI2RlZmluZSBwZXJfY3B1KHZhciwg
Y3B1KQkocGVyX2NwdV9fIyN2YXJbY3B1XSkKKworI2RlZmluZSBfX2dldF9jcHVfdmFyKHZh
cikJcGVyX2NwdSh2YXIsIHNtcF9wcm9jZXNzb3JfaWQoKSkKKworI2VuZGlmIC8qICFfX0FT
U0VNQkxZICovCisjZW5kaWYgLyogIV9fQVJNX1BFUkNQVV9IX18gKi8KZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
YXJtL3Byb2Nlc3Nvci5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApAQCAtMCww
ICsxLDIxOSBAQAorLyoKKyAqICBwcm9jZXNzb3IuaAorICoKKyAqIENvcHlyaWdodCAoQykg
MjAwOCBTYW1zdW5nIEVsZWN0cm9uaWNzCisgKiAgICAgICAgICBKYWVNaW4gUnl1ICA8am03
Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIHZlcnNpb24gMiBvZiBMaWNl
bnNlIGFzIHB1Ymxpc2hlZCBieQorICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4K
KyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBp
dCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91
dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorICoKKyAqIFlvdSBzaG91
bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlCisgKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUg
RnJlZSBTb2Z0d2FyZQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBT
dWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQorICovCisjaWZuZGVmIF9f
QVJNX1BST0NFU1NPUl9IX18KKyNkZWZpbmUgX19BUk1fUFJPQ0VTU09SX0hfXworCisvKgor
ICogUFNSIGJpdHMKKyAqLworI2RlZmluZSBQU1JfTU9ERV9VU1IgICAgICAgICAgICAweDAw
MDAwMDEwCisjZGVmaW5lIFBTUl9NT0RFX0ZJUSAgICAgICAgICAgIDB4MDAwMDAwMTEKKyNk
ZWZpbmUgUFNSX01PREVfSVJRICAgICAgICAgICAgMHgwMDAwMDAxMgorI2RlZmluZSBQU1Jf
TU9ERV9TVkMgICAgICAgICAgICAweDAwMDAwMDEzCisjZGVmaW5lIFBTUl9NT0RFX0FCVCAg
ICAgICAgICAgIDB4MDAwMDAwMTcKKyNkZWZpbmUgUFNSX01PREVfVU5EICAgICAgICAgICAg
MHgwMDAwMDAxYgorI2RlZmluZSBQU1JfTU9ERV9TWVMgICAgICAgICAgICAweDAwMDAwMDFm
CisjZGVmaW5lIFBTUl9NT0RFX01BU0sgICAgICAgICAgIDB4MDAwMDAwMWYKKyNkZWZpbmUg
UFNSX1RfQklUICAgICAgICAgICAgICAgMHgwMDAwMDAyMAorI2RlZmluZSBQU1JfRl9CSVQg
ICAgICAgICAgICAgICAweDAwMDAwMDQwCisjZGVmaW5lIFBTUl9JX0JJVCAgICAgICAgICAg
ICAgIDB4MDAwMDAwODAKKyNkZWZpbmUgUFNSX0pfQklUICAgICAgICAgICAgICAgMHgwMTAw
MDAwMAorI2RlZmluZSBQU1JfUV9CSVQgICAgICAgICAgICAgICAweDA4MDAwMDAwCisjZGVm
aW5lIFBTUl9WX0JJVCAgICAgICAgICAgICAgIDB4MTAwMDAwMDAKKyNkZWZpbmUgUFNSX0Nf
QklUICAgICAgICAgICAgICAgMHgyMDAwMDAwMAorI2RlZmluZSBQU1JfWl9CSVQgICAgICAg
ICAgICAgICAweDQwMDAwMDAwCisjZGVmaW5lIFBTUl9OX0JJVCAgICAgICAgICAgICAgIDB4
ODAwMDAwMDAKKworLyoKKworICogR3JvdXBzIG9mIFBTUiBiaXRzCisgKi8KKyNkZWZpbmUg
UFNSX01BU0tfRkxBR1MgICAgICAgICAgMHhmZjAwMDAwMCAgICAgIC8qIEZsYWdzICAgICAg
ICAgICAgICAgICovCisjZGVmaW5lIFBTUl9NQVNLX1NUQVRVUyAgICAgICAgIDB4MDBmZjAw
MDAgICAgICAvKiBTdGF0dXMgICAgICAgICAgICAgICAqLworI2RlZmluZSBQU1JfTUFTS19F
WFRFTlNJT04gICAgICAweDAwMDBmZjAwICAgICAgLyogRXh0ZW5zaW9uICAgICAgICAgICAg
Ki8KKyNkZWZpbmUgUFNSX01BU0tfQ09OVFJPTCAgICAgICAgMHgwMDAwMDBmZiAgICAgIC8q
IENvbnRyb2wgICAgICAgICAgICAgICovCisKKworI2RlZmluZSBNSURSKHIpCQlwMTUsIDAs
IHIsICBjMCwgYzAsIDAKKyNkZWZpbmUgQ1RSKHIpCQlwMTUsIDAsIHIsICBjMCwgYzAsIDEK
KyNkZWZpbmUgVENNVFIocikJcDE1LCAwLCByLCAgYzAsIGMwLCAyCisjZGVmaW5lIFRMQlRS
KHIpCXAxNSwgMCwgciwgIGMwLCBjMCwgMworI2RlZmluZSBNUElEUihyKQlwMTUsIDAsIHIs
ICBjMCwgYzAsIDUKKyNkZWZpbmUgU0NUTFIocikJcDE1LCAwLCByLCAgYzEsIGMwLCAwCisj
ZGVmaW5lIEFDVExSKHIpCXAxNSwgMCwgciwgIGMxLCBjMCwgMQorI2RlZmluZSBTQ1IocikJ
CXAxNSwgMCwgciwgIGMxLCBjMSwgMAorI2RlZmluZSBTREVSKHIpCQlwMTUsIDAsIHIsICBj
MSwgYzEsIDEKKyNkZWZpbmUgTlNBQ1IocikJcDE1LCAwLCByLCAgYzEsIGMxLCAyCisjZGVm
aW5lIFRUQlIwKHIpCXAxNSwgMCwgciwgIGMyLCBjMCwgMAorI2RlZmluZSBUVEJSMShyKQlw
MTUsIDAsIHIsICBjMiwgYzAsIDEKKyNkZWZpbmUgVFRCQ1IocikJcDE1LCAwLCByLCAgYzIs
IGMwLCAyCisjZGVmaW5lIERBQ1IocikJCXAxNSwgMCwgciwgIGMzLCBjMCwgMAorI2RlZmlu
ZSBERlNSKHIpCQlwMTUsIDAsIHIsICBjNSwgYzAsIDAKKyNkZWZpbmUgSUZTUihyKQkJcDE1
LCAwLCByLCAgYzUsIGMwLCAxCisjZGVmaW5lIERGQVIocikJCXAxNSwgMCwgciwgIGM2LCBj
MCwgMAorI2RlZmluZSBJRkFSKHIpCQlwMTUsIDAsIHIsICBjNiwgYzAsIDIKKyNkZWZpbmUg
VkJBUihyKQkJcDE1LCAwLCByLCBjMTIsIGMwLCAwCisjZGVmaW5lIE1WQkFSKHIpCXAxNSwg
MCwgciwgYzEyLCBjMCwgMQorLyoKKyAqIFN5c3RlbSBDb250cm9sIFJlZ2lzdGVyCisgKi8K
KyNkZWZpbmUgU0NUTFJfTSAgICAgICAgICgxIDw8IDApICAvKiBNTVUgZW5hYmxlICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfQSAgICAgICAgICgxIDw8
IDEpICAvKiBBbGlnbm1lbnQgYWJvcnQgZW5hYmxlICAgICAgICAgICAgICAgKi8KKyNkZWZp
bmUgU0NUTFJfQyAgICAgICAgICgxIDw8IDIpICAvKiBEY2FjaGUgZW5hYmxlICAgICAgICAg
ICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfVyAgICAgICAgICgxIDw8IDMpICAv
KiBXcml0ZSBidWZmZXIgZW5hYmxlICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NU
TFJfUCAgICAgICAgICgxIDw8IDQpICAvKiAzMi1iaXQgZXhjZXB0aW9uIGhhbmRsZXIgICAg
ICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfRCAgICAgICAgICgxIDw8IDUpICAvKiAzMi1i
aXQgZGF0YSBhZGRyZXNzIHJhbmdlICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfTCAg
ICAgICAgICgxIDw8IDYpICAvKiBJbXBsZW1lbnRhdGlvbiBkZWZpbmVkICAgICAgICAgICAg
ICAgKi8KKyNkZWZpbmUgU0NUTFJfQiAgICAgICAgICgxIDw8IDcpICAvKiBCaWcgZW5kaWFu
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfUyAgICAgICAg
ICgxIDw8IDgpICAvKiBTeXN0ZW0gTU1VIHByb3RlY3Rpb24gICAgICAgICAgICAgICAgKi8K
KyNkZWZpbmUgU0NUTFJfUiAgICAgICAgICgxIDw8IDkpICAvKiBST00gTU1VIHByb3RlY3Rp
b24gICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfU1cgICAgICAgICgxIDw8
IDEwKSAvKiBJbXBsZW1lbnRhdGlvbiBkZWZpbmVkICAgICAgICAgICAgICAgKi8KKyNkZWZp
bmUgU0NUTFJfWiAgICAgICAgICgxIDw8IDExKSAvKiBJbXBsZW1lbnRhdGlvbiBkZWZpbmVk
ICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfSSAgICAgICAgICgxIDw8IDEyKSAv
KiBJY2FjaGUgZW5hYmxlICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NU
TFJfViAgICAgICAgICgxIDw8IDEzKSAvKiBWZWN0b3JzIHJlbG9jYXRlZCB0byAweGZmZmYw
MDAwICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfUlIgICAgICAgICgxIDw8IDE0KSAvKiBSb3Vu
ZCBSb2JpbiBjYWNoZSByZXBsYWNlbWVudCAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfTDQg
ICAgICAgICgxIDw8IDE1KSAvKiBMRFIgcGMgY2FuIHNldCBUIGJpdCAgICAgICAgICAgICAg
ICAgKi8KKyNkZWZpbmUgU0NUTFJfRFQgICAgICAgICgxIDw8IDE2KQorI2RlZmluZSBTQ1RM
Ul9JVCAgICAgICAgKDEgPDwgMTgpCisjZGVmaW5lIFNDVExSX1NUICAgICAgICAoMSA8PCAx
OSkKKyNkZWZpbmUgU0NUTFJfRkkgICAgICAgICgxIDw8IDIxKSAvKiBGYXN0IGludGVycnVw
dCAobG93ZXIgbGF0ZW5jeSBtb2RlKSAgKi8KKyNkZWZpbmUgU0NUTFJfVSAgICAgICAgICgx
IDw8IDIyKSAvKiBVbmFsaWduZWQgYWNjZXNzIG9wZXJhdGlvbiAgICAgICAgICAgKi8KKyNk
ZWZpbmUgU0NUTFJfWFAgICAgICAgICgxIDw8IDIzKSAvKiBFeHRlbmRlZCBwYWdlIHRhYmxl
cyAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfVkUgICAgICAgICgxIDw8IDI0
KSAvKiBWZWN0b3JlZCBpbnRlcnJ1cHRzICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUg
U0NUTFJfRUUgICAgICAgICgxIDw8IDI1KSAvKiBFeGNlcHRpb24gZW5kaWFuZXNzICAgICAg
ICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfTk1GSSAgICAgICgxIDw8IDI3KSAvKiBO
b25tYXNrYWJsZSBmYXN0IGludGVycnVwdCBlbmFibGUgICAgKi8KKyNkZWZpbmUgU0NUTFJf
VFJFICAgICAgICgxIDw8IDI4KSAvKiBURVggcmVtYXAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfQUZFICAgICAgICgxIDw8IDI5KSAvKiBBY2Nlc3Mg
ZmxhZyBlbmFibGUgICAgICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgU0NUTFJfVEUgICAg
ICAgICgxIDw8IDMwKSAvKiBUaHVtYiBleGNlcHRpb24gZW5hYmxlICAgICAgICAgICAgICAg
Ki8KKworLyoKKyAqIENvLVByb2Nlc3NvciBBY2Nlc3MgUmVnaXN0ZXIKKyAqLworI2RlZmlu
ZSBDUEFSX0JJVF9DUDAgICAgKDEgPDwgMCkKKyNkZWZpbmUgQ1BBUl9CSVRfQ1AxICAgICgx
IDw8IDEpCisjZGVmaW5lIENQQVJfQklUX0NQMiAgICAoMSA8PCAyKQorI2RlZmluZSBDUEFS
X0JJVF9DUDMgICAgKDEgPDwgMykKKyNkZWZpbmUgQ1BBUl9CSVRfQ1A0ICAgICgxIDw8IDQp
CisjZGVmaW5lIENQQVJfQklUX0NQNSAgICAoMSA8PCA1KQorI2RlZmluZSBDUEFSX0JJVF9D
UDYgICAgKDEgPDwgNikKKyNkZWZpbmUgQ1BBUl9CSVRfQ1A3ICAgICgxIDw8IDcpCisjZGVm
aW5lIENQQVJfQklUX0NQOCAgICAoMSA8PCA4KQorI2RlZmluZSBDUEFSX0JJVF9DUDkgICAg
KDEgPDwgOSkKKyNkZWZpbmUgQ1BBUl9CSVRfQ1AxMCAgICgxIDw8IDEwKQorI2RlZmluZSBD
UEFSX0JJVF9DUDExICAgKDEgPDwgMTEpCisjZGVmaW5lIENQQVJfQklUX0NQMTIgICAoMSA8
PCAxMikKKyNkZWZpbmUgQ1BBUl9CSVRfQ1AxMyAgICgxIDw8IDEzKQorCisvKgorICogQXV4
aWxpYXJ5IENvbnRyb2wgUmVnaXN0ZXIKKyAqLworI2RlZmluZSBBQ1RMUl9GVyAgICAgICAg
KDEgPDwgMCkgIC8qIENhY2hlIGFuZCBUTEIgbWFpbnRlbmFuY2UgYnJvYWRjYXN0ICAqLwor
I2RlZmluZSBBQ1RMUl9EUDIgICAgICAgKDEgPDwgMSkgIC8qIEwyIERzaWRlIHByZWZldGNo
ICAgICAgICAgICAgICAgICAgICAqLworI2RlZmluZSBBQ1RMUl9EUDEgICAgICAgKDEgPDwg
MikgIC8qIEwxIERzaWRlIHByZWZldGNoICAgICAgICAgICAgICAgICAgICAqLworI2RlZmlu
ZSBBQ1RMUl9GT1ogICAgICAgKDEgPDwgMykgIC8qIEZ1bGwgb2YgemVybyAgICAgICAgICAg
ICAgICAgICAgICAgICAqLworI2RlZmluZSBBQ1RMUl9TTVAgICAgICAgKDEgPDwgNikgIC8q
IFNNUC9uQU1QICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworI2RlZmluZSBBQ1RM
Ul9FWENMICAgICAgKDEgPDwgNykgIC8qIEV4Y2x1c2l2ZSBjYWNoZSBlbmFibGUgICAgICAg
ICAgICAgICAqLworI2RlZmluZSBBQ1RMUl9QQVJPTiAgICAgKDEgPDwgOSkgIC8qIFBhcml0
eSBvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworCisvKgorICogU2VjdXJlIENv
bmZpZ3VyYXRpb24gUmVnaXN0ZXIKKyAqLworI2RlZmluZSBTQ1JfTlMgICAgICAgICAgKDEg
PDwgMCkgIC8qIE5vbi1zZWN1cmUgbW9kZSAgICAgICAgICAgICAgICAgICAgICAqLworI2Rl
ZmluZSBTQ1JfSVJRICAgICAgICAgKDEgPDwgMSkgIC8qIElSUSBleGNlcHRpb24gaGFuZGxp
bmcgbW9kZSAgICAgICAgICAqLworI2RlZmluZSBTQ1JfRklRICAgICAgICAgKDEgPDwgMikg
IC8qIEZJUSBleGNlcHRpb24gaGFuZGxpbmcgbW9kZSAgICAgICAgICAqLworI2RlZmluZSBT
Q1JfRUEgICAgICAgICAgKDEgPDwgMykgIC8qIEV4dGVybmFsIGV4Y2VwdGlvbiBoYW5kbGlu
ZyBtb2RlICAgICAqLworI2RlZmluZSBTQ1JfRlcgICAgICAgICAgKDEgPDwgNCkgIC8qIEYg
Qml0IGFjY2VzcyBhbGxvdyBiaXQgICAgICAgICAgICAgICAqLworI2RlZmluZSBTQ1JfQVcg
ICAgICAgICAgKDEgPDwgNSkgIC8qIEEgYml0IGFjY2VzcyBhbGxvdyBiaXQgICAgICAgICAg
ICAgICAqLworCisjZGVmaW5lIE5TQUNSX05TU01QICAgICAoMSA8PCAxOCkKKyNkZWZpbmUg
TlNBQ1JfVEwgICAgICAgICgxIDw8IDE3KQorI2RlZmluZSBOU0FDUl9OU0FDRURJUyAgKDEg
PDwgMTUpCisjZGVmaW5lIE5TQUNSX05TRDMyRElTICAoMSA8PCAxNCkKKyNkZWZpbmUgTlNB
Q1JfQ1AxMSAgICAgICgxIDw8IDExKQorI2RlZmluZSBOU0FDUl9DUDEwICAgICAgKDEgPDwg
MTApCisKKworI2lmbmRlZiBfX0FTU0VNQkxZX18KKworI2RlZmluZSBjcHVfdG9fY29yZShj
cHUpICAgICAgICAoMCkKKyNkZWZpbmUgY3B1X3RvX3NvY2tldChjcHUpICAgICAgKDApCisK
KyNkZWZpbmUgcDE0ICAgICAxNAorI2RlZmluZSBwMTUgICAgIDE1CisjZGVmaW5lIGMwICAg
ICAgMAorI2RlZmluZSBjMSAgICAgIDEKKyNkZWZpbmUgYzIgICAgICAyCisjZGVmaW5lIGMz
ICAgICAgMworI2RlZmluZSBjNCAgICAgIDQKKyNkZWZpbmUgYzUgICAgICA1CisjZGVmaW5l
IGM2ICAgICAgNgorI2RlZmluZSBjNyAgICAgIDcKKyNkZWZpbmUgYzggICAgICA4CisjZGVm
aW5lIGM5ICAgICAgOQorI2RlZmluZSBjMTAgICAgIDEwCisjZGVmaW5lIGMxMSAgICAgMTEK
KyNkZWZpbmUgYzEyICAgICAxMgorI2RlZmluZSBjMTMgICAgIDEzCisjZGVmaW5lIGMxNCAg
ICAgMTQKKyNkZWZpbmUgYzE1ICAgICAxNQorCisjZGVmaW5lIE1DUihjcCxvcDEsUmQsQ1Ju
LENSbSxvcDIpICBcCisJX19hc21fXyBfX3ZvbGF0aWxlX18oIiBtY3IgIiAjY3AiLCUxLCUy
LCIjQ1JuIiwiI0NSbSAiLCU1IiBcCisJOiA6ICJpIiAoY3ApLCAiaSIgKG9wMSksICJyIiAo
UmQpLCAiaSIgKENSbiksICJpIiAoQ1JtKSwgImkiIChvcDIpKQorCisjZGVmaW5lIE1SQyhj
cCxvcDEsUmQsQ1JuLENSbSxvcDIpICBcCisJX19hc21fXyBfX3ZvbGF0aWxlX18oICIgbXJj
ICIgI2NwIiwlMiwlMCwiICNDUm4iLCIjQ1JtIiwlNSIgXAorCTogIj1yIiAoUmQpIDogImki
IChjcCksICJpIiAob3AxKSwgImkiIChDUm4pLCAiaSIgKENSbSksICJpIiAob3AyKSkKKwor
c3RhdGljIGlubGluZSB2b2lkIGNwdV93YWl0X2Zvcl9ldmVudCh2b2lkKQoreworICAgICAg
ICBfX2FzbV9fIF9fdm9sYXRpbGVfXygid2ZlIiA6IDogOiAibWVtb3J5Iik7Cit9CisKK3N0
YXRpYyBpbmxpbmUgdm9pZCBjcHVfd2FpdF9mb3JfaW50ZXJydXB0KHZvaWQpCit7CisgICAg
ICAgIF9fYXNtX18gX192b2xhdGlsZSgid2ZpIiA6IDogOiAibWVtb3J5Iik7Cit9CisKK3N0
YXRpYyBpbmxpbmUgdm9pZCBjcHVfc2VuZF9ldmVudCh2b2lkKQoreworICAgICAgICBfX2Fz
bV9fIF9fdm9sYXRpbGVfXygic2V2IiA6IDogOiAibWVtb3J5Iik7Cit9CisKKyNkZWZpbmUg
Q1BVX01PREVfU01QCTEKKyNkZWZpbmUgQ1BVX01PREVfQU1QCTAKKworc3RhdGljIGlubGlu
ZSB2b2lkIGNwdV9zZXRfY29oZXJlbmN5X21vZGUodW5zaWduZWQgaW50IG1vZGUpCit7CisJ
dW5zaWduZWQgbG9uZyBhdXg7CisKKwlNUkMocDE1LCAwLCBhdXgsIGMxLCBjMCwgMSk7CisK
KwlpZiAoKG1vZGUgPT0gQ1BVX01PREVfU01QKSkgeworCQlhdXggfD0gKEFDVExSX1NNUCB8
IEFDVExSX0ZXKTsKKwl9IGVsc2UgeworCQlhdXggJj0gfihBQ1RMUl9TTVAgfCBBQ1RMUl9G
Vyk7CisJfQorCisJTUNSKHAxNSwgMCwgYXV4LCBjMSwgYzAsIDEpOworfQorCisjZW5kaWYK
KyNlbmRpZgpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL3JlZ3Mu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL3JlZ3MuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5
MDAKQEAgLTAsMCArMSwxNyBAQAorI2lmbmRlZiBfX0FTTV9BUk1fUkVHU19IX18KKyNkZWZp
bmUgX19BU01fQVJNX1JFR1NfSF9fCisKKyNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4KKyNpbmNs
dWRlIDxhc20vY3VycmVudC5oPgorCisjaWZuZGVmIF9fQVNTRU1CTFlfXworc3RhdGljIGlu
bGluZSBpbnQgZ3Vlc3RfbW9kZShzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKK3sKKwl3
aGlsZSgxKTsKKworCXJldHVybiAwOworfQorI2VuZGlmCisKKyNlbmRpZgorCmRpZmYgLXIg
ZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vc21wLmgKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLWFy
bS9zbXAuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyOCBA
QAorI2lmbmRlZiBfX0FSTV9TTVBfSF9fCisjZGVmaW5lIF9fQVJNX1NNUF9IX18KKworI2lu
Y2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4vc3BpbmxvY2suaD4KKyNpbmNs
dWRlIDx4ZW4vY3B1bWFzay5oPgorI2luY2x1ZGUgPHhlbi9wZXJjcHUuaD4KKyNpbmNsdWRl
IDxhc20vY3VycmVudC5oPgorCisjaWZuZGVmIF9BU1NFTUJMWV9fCisjZGVmaW5lIHJhd19z
bXBfcHJvY2Vzc29yX2lkKCkJCQlcCisoewkJCQkJCVwKKwl1bnNpZ25lZCBpbnQgaWQ7CQkJ
XAorCV9fYXNtX18oIm1yYyBwMTUsIDAsICUwLCBjMCwgYzAsIDUiCVwKKwkJOiAiPXIiIChp
ZCkpOwkJCVwKKwlpZCAmPSAweDBGOwkJCQlcCit9KQorCisjZGVmaW5lIGNwdV9pc19vZmZs
aW5lKGNwdSkJdW5saWtlbHkoIWNwdV9vbmxpbmUoY3B1KSkKKworREVDTEFSRV9QRVJfQ1BV
KGNwdW1hc2tfdmFyX3QsIGNwdV9zaWJsaW5nX21hc2spOworREVDTEFSRV9QRVJfQ1BVKGNw
dW1hc2tfdmFyX3QsIGNwdV9jb3JlX21hc2spOworCitERUNMQVJFX1BFUl9DUFUoY3B1bWFz
a190LCBjcHVfc2libGluZ19tYXApOworREVDTEFSRV9QRVJfQ1BVKGNwdW1hc2tfdCwgY3B1
X2NvcmVfbWFwKTsKKworI2VuZGlmIC8qICFfX0FTU0VNQkxZX18gKi8KKyNlbmRpZiAvKiAh
X19BUk1fU01QX0hfXyAqLwpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20t
YXJtL3NvZnRpcnEuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3NvZnRpcnEuaAlGcmkgRmViIDAzIDE2
OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwxMSBAQAorI2lmbmRlZiBfX0FTTV9TT0ZU
SVJRX0hfXworI2RlZmluZSBfX0FTTV9TT0ZUSVJRX0hfXworCisjZGVmaW5lIFJFU0VSVkVE
X1NPRlRJUlEwCShOUl9DT01NT05fU09GVElSUVMgKyAwKQorI2RlZmluZSBSRVNFUlZFRF9T
T0ZUSVJRMQkoTlJfQ09NTU9OX1NPRlRJUlFTICsgMSkKKyNkZWZpbmUgVkNQVV9LSUNLX1NP
RlRJUlEJKE5SX0NPTU1PTl9TT0ZUSVJRUyArIDIpCisKKyNkZWZpbmUgTlJfQVJDSF9TT0ZU
SVJRUwkzCisKKyNlbmRpZiAvKiBfX0FTTV9TT0ZUSVJRX0hfXyAqLworCmRpZmYgLXIgZTcw
MTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vc3BpbmxvY2suaAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
YXJtL3NwaW5sb2NrLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAg
KzEsMjAwIEBACisjaWZuZGVmIF9fQVJNX1NQSU5MT0NLX0hfXworI2RlZmluZSBfX0FSTV9T
UElOTE9DS19IX18KKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKyNpbmNsdWRlIDx4ZW4v
bGliLmg+CisjaW5jbHVkZSA8YXNtL2F0b21pYy5oPgorCisvKgorICogVW5sb2NrZWQgdmFs
dWUgOiAwCisgKiBMb2NrZWQgdmFsdWUgICA6IDEKKyAqLworI2RlZmluZSBfUkFXX1NQSU5f
TE9DS19VTkxPQ0tFRAl7IDAgfQorI2RlZmluZSBfUkFXX1JXX0xPQ0tfVU5MT0NLRUQJeyAw
IH0KKwordHlwZWRlZiBzdHJ1Y3QgeworCXZvbGF0aWxlIHVuc2lnbmVkIGludCBsb2NrOwor
fXJhd19zcGlubG9ja190OworCit0eXBlZGVmIHN0cnVjdCByd2xvY2sgeworCXZvbGF0aWxl
IHVuc2lnbmVkIGludCBsb2NrOworfXJhd19yd2xvY2tfdDsKKworI2RlZmluZSBfcmF3X3Nw
aW5faXNfbG9ja2VkKHgpCSgoeCktPmxvY2sgIT0gMCkKKworc3RhdGljIGlubGluZSB2b2lk
IF9yYXdfc3Bpbl9sb2NrKHJhd19zcGlubG9ja190ICpsb2NrKQoreworCXVuc2lnbmVkIGxv
bmcgdG1wOworCisJX19hc21fXyBfX3ZvbGF0aWxlX18oCisiMToJbGRyZXgJJTAsIFslMV1c
biIKKyIJdGVxCSUwLCAjMFxuIgorIgl3ZmVuZVxuIgorIglzdHJleGVxCSUwLCAlMiwgWyUx
XVxuIgorIgl0ZXFlcQklMCwgIzBcbiIKKyIJYm5lCTFiIgorCTogIj0mciIgKHRtcCkKKwk6
ICJyIiAoJmxvY2stPmxvY2spLCAiciIgKDEpCisJOiAiY2MiKTsKKworCW1iKCk7Cit9CisK
K3N0YXRpYyBpbmxpbmUgaW50IF9yYXdfc3Bpbl90cnlsb2NrKHJhd19zcGlubG9ja190ICps
b2NrKQoreworCXVuc2lnbmVkIGxvbmcgdG1wOworCisJX19hc21fXyBfX3ZvbGF0aWxlX18o
CisiCWxkcmV4CSUwLCBbJTFdXG4iCisiCXRlcQklMCwgIzBcbiIKKyIJc3RyZXhlcQklMCwg
JTIsIFslMV0iCisJOiAiPSZyIiAodG1wKQorCTogInIiICgmbG9jay0+bG9jayksICJyIiAo
MSkKKwk6ICJjYyIpOworCisJaWYgKHRtcCA9PSAwKSB7CisJCW1iKCk7CisKKwkJcmV0dXJu
IDE7CisJfSBlbHNlIHsKKwkJcmV0dXJuIDA7CisJfQorfQorCitzdGF0aWMgaW5saW5lIHZv
aWQgX3Jhd19zcGluX3VubG9jayhyYXdfc3BpbmxvY2tfdCAqbG9jaykKK3sKKwltYigpOwor
CisJX19hc21fXyBfX3ZvbGF0aWxlX18oCisiCXN0cgklMSwgWyUwXVxuIgorIgltY3IJcDE1
LCAwLCAlMSwgYzcsIGMxMCwgNFxuIiAvKiBEU0IgKi8KKyIJc2V2IgorCToKKwk6ICJyIiAo
JmxvY2stPmxvY2spLCAiciIgKDApCisJOiAiY2MiKTsKK30KKworLyoKKyAqIFJXTE9DS1MK
KyAqCisgKgorICogV3JpdGUgbG9ja3MgYXJlIGVhc3kgLSB3ZSBqdXN0IHNldCBiaXQgMzEu
ICBXaGVuIHVubG9ja2luZywgd2UgY2FuCisgKiBqdXN0IHdyaXRlIHplcm8gc2luY2UgdGhl
IGxvY2sgaXMgZXhjbHVzaXZlbHkgaGVsZC4KKyAqLworCitzdGF0aWMgaW5saW5lIHZvaWQg
X3Jhd193cml0ZV9sb2NrKHJhd19yd2xvY2tfdCAqcncpCit7CisJdW5zaWduZWQgbG9uZyB0
bXA7CisKKwlfX2FzbV9fIF9fdm9sYXRpbGVfXygKKyIxOglsZHJleAklMCwgWyUxXVxuIgor
Igl0ZXEJJTAsICMwXG4iCisiCXdmZW5lXG4iCisiCXN0cmV4ZXEJJTAsICUyLCBbJTFdXG4i
CisiCXRlcQklMCwgIzBcbiIKKyIJYm5lCTFiIgorCTogIj0mciIgKHRtcCkKKwk6ICJyIiAo
JnJ3LT5sb2NrKSwgInIiICgweDgwMDAwMDAwKQorCTogImNjIik7CisKKwltYigpOworfQor
CitzdGF0aWMgaW5saW5lIGludCBfcmF3X3dyaXRlX3RyeWxvY2socmF3X3J3bG9ja190ICpy
dykKK3sKKwl1bnNpZ25lZCBsb25nIHRtcDsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKAor
IjE6CWxkcmV4CSUwLCBbJTFdXG4iCisiCXRlcQklMCwgIzBcbiIKKyIJc3RyZXhlcQklMCwg
JTIsIFslMV0iCisJOiAiPSZyIiAodG1wKQorCTogInIiICgmcnctPmxvY2spLCAiciIgKDB4
ODAwMDAwMDApCisJOiAiY2MiKTsKKworCWlmICh0bXAgPT0gMCkgeworCQltYigpOworCQly
ZXR1cm4gMTsKKwl9IGVsc2UgeworCQlyZXR1cm4gMDsKKwl9Cit9CisKK3N0YXRpYyBpbmxp
bmUgdm9pZCBfcmF3X3dyaXRlX3VubG9jayhyYXdfcndsb2NrX3QgKnJ3KQoreworCW1iKCk7
CisKKwlfX2FzbV9fIF9fdm9sYXRpbGVfXygKKwkic3RyCSUxLCBbJTBdXG4iCisiCW1jcglw
MTUsIDAsICUxLCBjNywgYzEwLCA0XG4iIC8qIERTQiAqLworIglzZXZcbiIKKwk6CisJOiAi
ciIgKCZydy0+bG9jayksICJyIiAoMCkKKwk6ICJjYyIpOworfQorCisjZGVmaW5lIF9yYXdf
cndfaXNfbG9ja2VkKHgpCQkoKHgpLT5sb2NrICE9IDApCisjZGVmaW5lIF9yYXdfcndfaXNf
d3JpdGVfbG9ja2VkKHgpCSgoeCktPmxvY2sgPD0gMCkKKyNkZWZpbmUgX3Jhd193cml0ZV9j
YW5fbG9jayh4KQkJKCh4KS0+bG9jayA9PSAwKQorCitzdGF0aWMgaW5saW5lIHZvaWQgX3Jh
d19yZWFkX2xvY2socmF3X3J3bG9ja190ICpydykKK3sKKwl1bnNpZ25lZCBsb25nIHRtcCwg
dG1wMjsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKAorIjE6CWxkcmV4CSUwLCBbJTJdXG4i
CisiCWFkZHMJJTAsICUwLCAjMVxuIgorIglzdHJleHBsCSUxLCAlMCwgWyUyXVxuIgorIgl3
ZmVtaVxuIgorIglyc2JwbHMJJTAsICUxLCAjMFxuIgorIglibWkJMWIiCisJOiAiPSZyIiAo
dG1wKSwgIj0mciIgKHRtcDIpCisJOiAiciIgKCZydy0+bG9jaykKKwk6ICJjYyIpOworCisJ
bWIoKTsKK30KKworc3RhdGljIGlubGluZSB2b2lkIF9yYXdfcmVhZF91bmxvY2socmF3X3J3
bG9ja190ICpydykKK3sKKwl1bnNpZ25lZCBsb25nIHRtcCwgdG1wMjsKKworCW1iKCk7CisK
KwlfX2FzbV9fIF9fdm9sYXRpbGVfXygKKyIxOglsZHJleAklMCwgWyUyXVxuIgorIglzdWIJ
JTAsICUwLCAjMVxuIgorIglzdHJleAklMSwgJTAsIFslMl1cbiIKKyIJdGVxCSUxLCAjMFxu
IgorIglibmUJMWJcbiIKKyIJY21wCSUwLCAjMFxuIgorIgltY3JlcSAgIHAxNSwgMCwgJTAs
IGM3LCBjMTAsIDRcbiIKKyIJc2V2ZXEiCisJOiAiPSZyIiAodG1wKSwgIj0mciIgKHRtcDIp
CisJOiAiciIgKCZydy0+bG9jaykKKwk6ICJjYyIpOworfQorCitzdGF0aWMgaW5saW5lIGlu
dCBfcmF3X3JlYWRfdHJ5bG9jayhyYXdfcndsb2NrX3QgKnJ3KQoreworCXVuc2lnbmVkIGxv
bmcgdG1wLCB0bXAyID0gMTsKKworCV9fYXNtX18gX192b2xhdGlsZV9fKAorIjE6CWxkcmV4
CSUwLCBbJTJdXG4iCisiCWFkZHMJJTAsICUwLCAjMVxuIgorIglzdHJleHBsCSUxLCAlMCwg
WyUyXVxuIgorCTogIj0mciIgKHRtcCksICIrciIgKHRtcDIpCisJOiAiciIgKCZydy0+bG9j
aykKKwk6ICJjYyIpOworCisJbWIoKTsKKwlyZXR1cm4gdG1wMiA9PSAwOworfQorCisjZGVm
aW5lIF9yYXdfcmVhZF9jYW5fbG9jayh4KQkoKHgpLT5sb2NrIDwgMHg4MDAwMDAwMCkKKwor
I2RlZmluZSBfcmF3X3NwaW5fcmVsYXgobG9jaykJY3B1X3JlbGF4KCkKKyNkZWZpbmUgX3Jh
d19yZWFkX3JlbGF4KGxvY2spCWNwdV9yZWxheCgpCisjZGVmaW5lIF9yYXdfd3JpdGVfcmVs
YXgobG9jaykJY3B1X3JlbGF4KCkKKworI2VuZGlmIC8qIF9fQVNNX1NQSU5MT0NLX0ggKi8K
ZGlmZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS9zdHJpbmcuaAotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vaW5j
bHVkZS9hc20tYXJtL3N0cmluZy5oCUZyaSBGZWIgMDMgMTY6MDc6MDMgMjAxMiArMDkwMApA
QCAtMCwwICsxLDQ5IEBACisjaWZuZGVmIF9fQVNNX1NUUklOR19IX18KKyNkZWZpbmUgX19B
U01fU1RSSU5HX0hfXworCisvKgorICogV2UgZG9uJ3QgZG8gaW5saW5lIHN0cmluZyBmdW5j
dGlvbnMsIHNpbmNlIHRoZQorICogb3B0aW1pc2VkIGlubGluZSBhc20gdmVyc2lvbnMgYXJl
IG5vdCBzbWFsbC4KKyAqLworCisjZGVmaW5lIF9fSEFWRV9BUkNIX1NUUlJDSFIKK2V4dGVy
biBjaGFyICogc3RycmNocihjb25zdCBjaGFyICogcywgaW50IGMpOworCisjZGVmaW5lIF9f
SEFWRV9BUkNIX1NUUkNIUgorZXh0ZXJuIGNoYXIgKiBzdHJjaHIoY29uc3QgY2hhciAqIHMs
IGludCBjKTsKKworI2RlZmluZSBfX0hBVkVfQVJDSF9NRU1DUFkKK2V4dGVybiB2b2lkICog
bWVtY3B5KHZvaWQgKiwgY29uc3Qgdm9pZCAqLCBfX2tlcm5lbF9zaXplX3QpOworCisjZGVm
aW5lIF9fSEFWRV9BUkNIX01FTU1PVkUKK2V4dGVybiB2b2lkICogbWVtbW92ZSh2b2lkICos
IGNvbnN0IHZvaWQgKiwgX19rZXJuZWxfc2l6ZV90KTsKKworI2RlZmluZSBfX0hBVkVfQVJD
SF9NRU1DSFIKK2V4dGVybiB2b2lkICogbWVtY2hyKGNvbnN0IHZvaWQgKiwgaW50LCBfX2tl
cm5lbF9zaXplX3QpOworCisjZGVmaW5lIF9fSEFWRV9BUkNIX01FTVpFUk8KKyNkZWZpbmUg
X19IQVZFX0FSQ0hfTUVNU0VUCitleHRlcm4gdm9pZCAqIG1lbXNldCh2b2lkICosIGludCwg
X19rZXJuZWxfc2l6ZV90KTsKKworI2RlZmluZSBfX0hBVkVfQVJDSF9CQ09QWQorCitleHRl
cm4gdm9pZCBfX21lbXplcm8odm9pZCAqcHRyLCBfX2tlcm5lbF9zaXplX3Qgbik7CisKKyNk
ZWZpbmUgbWVtc2V0KHAsdixuKQkJCQkJCVwKKyh7CQkJCQkJCQlcCisJaWYgKChuKSAhPSAw
KSB7CQkJCQkJXAorCQlpZiAoX19idWlsdGluX2NvbnN0YW50X3AoKHYpKSAmJiAodikgPT0g
MCkJXAorCQkJX19tZW16ZXJvKChwKSwobikpOwkJCVwKKwkJZWxzZQkJCQkJCVwKKwkJCW1l
bXNldCgocCksKHYpLChuKSk7CQkJXAorCX0JCQkJCQkJXAorCShwKTsJCQkJCQkJXAorfSkK
KworI2RlZmluZSBtZW16ZXJvKHAsbikgCQkJCVwKKyh7IAkJCQkJCVwKKwlpZiAoKG4pICE9
IDApIAkJCQlcCisJCV9fbWVtemVybygocCksKG4pKTsgKHApOyAJXAorfSkKKworI2VuZGlm
CmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vc3lzdGVtLmgKLS0t
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2lu
Y2x1ZGUvYXNtLWFybS9zeXN0ZW0uaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAK
QEAgLTAsMCArMSwxNDggQEAKKyNpZm5kZWYgX19BU01fU1lTVEVNX0gKKyNkZWZpbmUgX19B
U01fU1lTVEVNX0gKKworI2luY2x1ZGUgPHhlbi9jb25maWcuaD4KKworI2RlZmluZSBfX2Fz
bWVxKHgsIHkpICAiLmlmbmMgIiB4ICIsIiB5ICIgOyAuZXJyIDsgLmVuZGlmXG5cdCIKKwor
I2lmbmRlZiBfX0FTU0VNQkxZX18KKworLyoKKyAqIGRtYiA6IERhdGEgTWVtb3J5IEJhcnJp
ZXIKKyAqIGRzYiA6IERhdGEgU3luY2hyb25pemF0aW9uIEJhcnJpZXIKKyAqIAktPiBEcmFp
biBXcml0ZSBCdWZmZXIgaW4gZWFybGllciBvZiB0aGUgYXJjaGl0ZWN0dXJlCisgKiBpc2Ig
OiBJbnN0cnVjdGlvbiBTeW5jaHJvbml6YXRpb24gQmFycmllcgorICogCS0+IEZsdXNoIHBp
cGVsaW5lIGFuZCBicmFjaCB0YXJnZXQgYnVmZmVycy4KKyAqLworCisjZGVmaW5lIGlzYigp
IF9fYXNtX18gX192b2xhdGlsZV9fICgiaXNiIiA6IDogOiAibWVtb3J5IikKKyNkZWZpbmUg
ZHNiKCkgX19hc21fXyBfX3ZvbGF0aWxlX18gKCJkc2IiIDogOiA6ICJtZW1vcnkiKQorI2Rl
ZmluZSBkbWIoKSBfX2FzbV9fIF9fdm9sYXRpbGVfXyAoImRtYiIgOiA6IDogIm1lbW9yeSIp
CisKKyNkZWZpbmUgbWIoKQkJZG1iKCkKKyNkZWZpbmUgcm1iKCkgCQlkbWIoKQorI2RlZmlu
ZSB3bWIoKSAJCWRtYigpCisKKyNkZWZpbmUgY3B1X3JlbGF4KCkJZG1iKCkKKworI2RlZmlu
ZSBzbXBfcm1iKCkJcm1iKCkKKyNkZWZpbmUgc21wX3dtYigpCXdtYigpCisjZGVmaW5lIHNt
cF9tYigpCWRtYigpCisKKyNkZWZpbmUgbG9jYWxfaXJxX3NhdmUoeCkJCVwKKyh7CQkJCQlc
CisJX19hc21fXyBfX3ZvbGF0aWxlX18oCQlcCisJCSJtcnMgICAgJTAsIGNwc3IgXG4iCVwK
KwkJImNwc2lkICBpIgkJXAorCQk6ICI9ciIgKHgpCQlcCisJCToJCQlcCisJCTogIm1lbW9y
eSIsICJjYyIpOwlcCit9KQorCisjZGVmaW5lIGxvY2FsX2lycV9lbmFibGUoKSAgX19hc21f
XygiY3BzaWUgaSAgICBAIF9fc3RpIiA6IDogOiAibWVtb3J5IiwgImNjIikKKyNkZWZpbmUg
bG9jYWxfaXJxX2Rpc2FibGUoKSBfX2FzbV9fKCJjcHNpZCBpICAgIEAgX19jbGkiIDogOiA6
ICJtZW1vcnkiLCAiY2MiKQorI2RlZmluZSBsb2NhbF9maXFfZW5hYmxlKCkgIF9fYXNtX18o
ImNwc2llIGYgICAgQCBfX3N0ZiIgOiA6IDogIm1lbW9yeSIsICJjYyIpCisjZGVmaW5lIGxv
Y2FsX2ZpcV9kaXNhYmxlKCkgX19hc21fXygiY3BzaWQgZiAgICBAIF9fY2xmIiA6IDogOiAi
bWVtb3J5IiwgImNjIikKKworLyoKKyAqIFNhdmUgdGhlIGN1cnJlbnQgaW50ZXJydXB0IGVu
YWJsZSBzdGF0ZS4KKyAqLworI2RlZmluZSBsb2NhbF9zYXZlX2ZsYWdzKHgpCQlcCisoewkJ
CQkJXAorCV9fYXNtX18gX192b2xhdGlsZV9fKAkJXAorCSJtcnMJJTAsIGNwc3JcbiIJCVwK
Kwk6ICI9ciIgKHgpIDogOiAibWVtb3J5IiwgImNjIik7CVwKK30pCisKKy8qCisgKiByZXN0
b3JlIHNhdmVkIElSUSAmIEZJUSBzdGF0ZQorICovCisjZGVmaW5lIGxvY2FsX2lycV9yZXN0
b3JlKHgpCQlcCisoewkJCQkJXAorCV9fYXNtX18gX192b2xhdGlsZV9fKAkJXAorCSJtc3IJ
Y3Bzcl9jLCAlMFxuIgkJXAorCToJCQkJXAorCTogInIiICh4KQkJCVwKKwk6ICJtZW1vcnki
LCAiY2MiKTsJCVwKK30pCisKKyNkZWZpbmUgaXJxc19kaXNhYmxlZCgpCQkJCVwKKyh7CQkJ
CQlcCisJdW5zaWduZWQgbG9uZyBmbGFnczsJCVwKKwlsb2NhbF9zYXZlX2ZsYWdzKGZsYWdz
KTsJXAorCWZsYWdzICYgUFNSX0lfQklUOwkJXAorfSkKKworI2RlZmluZSBsb2NhbF9pcnFf
aXNfZW5hYmxlZCgpCSghaXJxc19kaXNhYmxlZCgpKQorCitzdGF0aWMgaW5saW5lIHZvaWQg
bm9wKHZvaWQpCit7CisJYXNtIHZvbGF0aWxlKCJub3AiKTsKK30KKworc3RhdGljIGlubGlu
ZSB1bnNpZ25lZCBpbnQgZ2V0X2NyKHZvaWQpCit7CisJdW5zaWduZWQgaW50IHZhbDsKKwlh
c20oIm1yYyBwMTUsIDAsICUwLCBjMSwgYzAsIDAiIDogIj1yIih2YWwpIDogOiAiY2MiKTsK
KworCXJldHVybiB2YWw7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfY3IodW5zaWdu
ZWQgaW50IHZhbCkKK3sKKwlhc20gdm9sYXRpbGUoIm1jciBwMTUsIDAsICUwLCBjMSwgYzAs
IDAiIDogOiAiciIodmFsKSA6ICJjYyIpOworCisJaXNiKCk7Cit9CisKK3N0YXRpYyBpbmxp
bmUgdW5zaWduZWQgbG9uZyBfeGNoZyh1bnNpZ25lZCBsb25nIHgsIHZvbGF0aWxlIHZvaWQg
KiBwdHIsIGludCBzaXplKQoreworCXVuc2lnbmVkIGxvbmcgcmV0OworCXVuc2lnbmVkIGlu
dCB0bXA7CisKKwlzd2l0Y2ggKHNpemUpIHsKKyAgICAgICAgY2FzZSAxOgorCQlfX2FzbV9f
IF9fdm9sYXRpbGVfXygKKwkJIjE6ICAgICBsZHJleGIgICUwLCBbJTNdXG4iCisJCSIgICAg
ICAgc3RyZXhiICAlMSwgJTIsIFslM11cbiIKKwkJIiAgICAgICB0ZXEgICAgICUxLCAjMFxu
IgorCQkiICAgICAgIGJuZSAgICAgMWIiCisJCTogIj0mciIgKHJldCksICI9JnIiICh0bXAp
CisJCTogInIiICh4KSwgInIiIChwdHIpCisJCTogIm1lbW9yeSIsICJjYyIpOworCQlicmVh
azsKKwljYXNlIDQ6CisJCV9fYXNtX18gX192b2xhdGlsZV9fKCJAIF9feGNoZzRcbiIKKwkJ
IjE6ICAgICBsZHJleCAgICUwLCBbJTNdXG4iCisJCSIgICAgICAgc3RyZXggICAlMSwgJTIs
IFslM11cbiIKKwkJIiAgICAgICB0ZXEgICAgICUxLCAjMFxuIgorCQkiICAgICAgIGJuZSAg
ICAgMWIiCisJCTogIj0mciIgKHJldCksICI9JnIiICh0bXApCisJCTogInIiICh4KSwgInIi
IChwdHIpCisJCTogIm1lbW9yeSIsICJjYyIpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQly
ZXQgPSAwOworCQlicmVhazsKKwl9CisKKwlyZXR1cm4gcmV0OworfQorCisjZGVmaW5lIGNt
cHhjaGcocHRyLCBvbGQsIG5ldykJCQkJCQlcCisoeyAJCQkJCQkJCQlcCisJX190eXBlb2Zf
XygqKHB0cikpIHByZXY7IAkJCQkJXAorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CQkJCQkJXAor
CWxvY2FsX2lycV9zYXZlKGZsYWdzKTsJCQkJCQlcCisJcHJldiA9ICooKF9fdHlwZW9mX18o
KihwdHIpKSAqKXB0cik7IAkJCQlcCisJaWYocHJldiA9PSBvbGQpIAkJCQkJCVwKKwkJKigo
X190eXBlb2ZfXygqKHB0cikpICopcHRyKSA9IChfX3R5cGVvZl9fKCoocHRyKSkpbmV3Owlc
CisJbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOwkJCQkJXAorCXByZXY7IAkJCQkJCQkJXAor
fSkKKworI2RlZmluZSB4Y2hnKHB0cix2KQlcCisJKChfX3R5cGVvZl9fKCoocHRyKSkpX3hj
aGcoKHVuc2lnbmVkIGxvbmcpKHYpLChwdHIpLHNpemVvZigqKHB0cikpKSkKKworI2VuZGlm
IC8qIF9fQVNTRU1CTFlfXyAqLworI2VuZGlmIC8qIV9fU1lTVEVNX0hfXyAqLwpkaWZmIC1y
IGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVkZS9hc20tYXJtL3RlZ3JhL2NvbmZpZy5oCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS1hcm0vdGVncmEvY29uZmlnLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsMTEgQEAKKyNpZm5kZWYgX19URUdSQV9DT05GSUdfSF9fCisjZGVm
aW5lIF9fVEVHUkFfQ09ORklHX0hfXworCisjZGVmaW5lIEhaCTEwMAorI2RlZmluZSBDTE9D
S19USUNLX1JBVEUJCTEwMDAwMDAKKworI2RlZmluZSBNQVhfUEhZU19DUFVTCQkyCisKKyNk
ZWZpbmUgQlVJTFRJTl9DT01NQU5EX0xJTkVfU0laRSAyNTYKKyNkZWZpbmUgQlVJTFRJTl9D
T01NQU5EX0xJTkUJIiIKKyNlbmRpZgpkaWZmIC1yIGU3MDE0NjFiMTI1MSB4ZW4vaW5jbHVk
ZS9hc20tYXJtL3RpbWUuaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL3RpbWUuaAlGcmkgRmViIDAzIDE2
OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAsMCArMSwyNCBAQAorI2lmbmRlZiBfX0FTTV9USU1F
X0hfXworI2RlZmluZSBfX0FTTV9USU1FX0hfXworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5o
PgorI2luY2x1ZGUgPHhlbi90eXBlcy5oPgorI2luY2x1ZGUgPHhlbi9zb2Z0aXJxLmg+CisK
KyNpZm5kZWYgX19BU1NFTUJMWV9fCisjZGVmaW5lIHdhdGNoZG9nX2Rpc2FibGUoKSAoKHZv
aWQpMCkKKyNkZWZpbmUgd2F0Y2hkb2dfZW5hYmxlKCkgICgodm9pZCkwKQorCitzdHJ1Y3Qg
dG07CitzdHJ1Y3QgdG0gd2FsbGNsb2NrX3RpbWUodm9pZCk7CisKK3R5cGVkZWYgdTY0IGN5
Y2xlX3Q7CisKK3N0YXRpYyBpbmxpbmUgY3ljbGVfdCBnZXRfY3ljbGVzKHZvaWQpCit7CisJ
cmV0dXJuIDA7Cit9CisKK3ZvaWQgdGltZWtlZXBpbmdfaW5pdCh2b2lkKTsKKyNlbmRpZgor
I2VuZGlmCmRpZmYgLXIgZTcwMTQ2MWIxMjUxIHhlbi9pbmNsdWRlL2FzbS1hcm0vdHJhY2Uu
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94
ZW4vaW5jbHVkZS9hc20tYXJtL3RyYWNlLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICsw
OTAwCkBAIC0wLDAgKzEsNiBAQAorI2lmbmRlZiBfX0FSTV9UUkFDRV9IX18KKyNkZWZpbmUg
X19BUk1fVFJBQ0VfSF9fCisKKworI2VuZGlmIC8qIV9fQVJNX1RSQUNFX0hfXyovCisKZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS90eXBlcy5oCi0tLSAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS1hcm0vdHlwZXMuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAKQEAgLTAs
MCArMSw1OCBAQAorI2lmbmRlZiBfX0FSTV9UWVBFU19IX18KKyNkZWZpbmUgX19BUk1fVFlQ
RVNfSF9fCisKKyNkZWZpbmUgQklUU19QRVJfTE9ORwkzMgorI2RlZmluZSBCWVRFU19QRVJf
TE9ORwk0CisjZGVmaW5lIExPTkdfQllURU9SREVSCTIKKworI2lmbmRlZiBfX0FTU0VNQkxZ
X18KKy8qCisgKiBfX3h4IGlzIG9rOiBpdCBkb2Vzbid0IHBvbGx1dGUgdGhlIFBPU0lYIG5h
bWVzcGFjZS4gVXNlIHRoZXNlIGluIHRoZQorICogaGVhZGVyIGZpbGVzIGV4cG9ydGVkIHRv
IHVzZXIgc3BhY2UKKyAqLworCit0eXBlZGVmIF9fc2lnbmVkX18gY2hhciBfX3M4OwordHlw
ZWRlZiB1bnNpZ25lZCBjaGFyIF9fdTg7CisKK3R5cGVkZWYgX19zaWduZWRfXyBzaG9ydCBf
X3MxNjsKK3R5cGVkZWYgdW5zaWduZWQgc2hvcnQgX191MTY7CisKK3R5cGVkZWYgX19zaWdu
ZWRfXyBpbnQgX19zMzI7Cit0eXBlZGVmIHVuc2lnbmVkIGludCBfX3UzMjsKKworI2lmIGRl
ZmluZWQoX19HTlVDX18pICYmICFkZWZpbmVkKF9fU1RSSUNUX0FOU0lfXykKK3R5cGVkZWYg
X19zaWduZWRfXyBsb25nIGxvbmcgX19zNjQ7Cit0eXBlZGVmIHVuc2lnbmVkIGxvbmcgbG9u
ZyBfX3U2NDsKKyNlbmRpZgorCit0eXBlZGVmIHVuc2lnbmVkIGxvbmcgcGh5c2FkZHJfdDsK
KwordHlwZWRlZiBzaWduZWQgY2hhciBzODsKK3R5cGVkZWYgdW5zaWduZWQgY2hhciB1ODsK
KwordHlwZWRlZiBzaWduZWQgc2hvcnQgczE2OwordHlwZWRlZiB1bnNpZ25lZCBzaG9ydCB1
MTY7CisKK3R5cGVkZWYgc2lnbmVkIGludCBzMzI7Cit0eXBlZGVmIHVuc2lnbmVkIGludCB1
MzI7CisKK3R5cGVkZWYgc2lnbmVkIGxvbmcgbG9uZyBzNjQ7Cit0eXBlZGVmIHVuc2lnbmVk
IGxvbmcgbG9uZyB1NjQ7CisKK3R5cGVkZWYgdW5zaWduZWQgbG9uZyBwYWRkcl90OwordHlw
ZWRlZiB1bnNpZ25lZCBsb25nIHZhZGRyX3Q7CisKK3R5cGVkZWYgdW5zaWduZWQgbG9uZyBz
aXplX3Q7CisKK3R5cGVkZWYgY2hhciBib29sX3Q7CisKKyNkZWZpbmUgdGVzdF9hbmRfc2V0
X2Jvb2woYikJeGNoZygmKGIpLCAxKQorI2RlZmluZSB0ZXN0X2FuZF9jbGVhcl9ib29sKGIp
CXhjaGcoJihiKSwgMCkKKworI2RlZmluZSByb3VuZF91cChfcCwgX3MpICAgICAgICAoKCh1
bnNpZ25lZCBsb25nKShfcCkgKyAoKF9zKSAtIDEpKSAmIH4oKF9zKSAtIDEpKQorI2RlZmlu
ZSByb3VuZF9kb3duKF9wLCBfcykgICAgICAoKHVuc2lnbmVkIGxvbmcpKF9wKSAmIH4oKF9z
KSAtIDEpKQorCisjZGVmaW5lIHJvdW5kX3VwX2FuZF9kaXYoX3AsIF9zKSAocm91bmRfdXAo
X3AsIF9zKSAvIF9zKQorI2VuZGlmIC8qIF9fQVNTRU1CTFlfXyAqLworCisjZW5kaWYKZGlm
ZiAtciBlNzAxNDYxYjEyNTEgeGVuL2luY2x1ZGUvYXNtLWFybS94ZW5vcHJvZi5oCi0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS1hcm0veGVub3Byb2YuaAlGcmkgRmViIDAzIDE2OjA3OjAzIDIwMTIgKzA5MDAK
QEAgLTAsMCArMSw0MyBAQAorI2lmbmRlZiBfX0FTTV9YRU5PUFJPRl9IX18KKyNkZWZpbmUg
X19BU01fWEVOT1BST0ZfSF9fCisKKyNkZWZpbmUgeGVub3Byb2ZfYXJjaF9yZXNlcnZlX2Nv
dW50ZXJzKCkJKDApCisjZGVmaW5lIHhlbm9wcm9mX2FyY2hfc2V0dXBfZXZlbnRzKCkJCSgw
KQorI2RlZmluZSB4ZW5vcHJvZl9hcmNoX2VuYWJsZV92aXJxKCkJCSgwKQorI2RlZmluZSB4
ZW5vcHJvZl9hcmNoX3N0YXJ0KCkgCQkJKDApCisjZGVmaW5lIHhlbm9wcm9mX2FyY2hfc3Rv
cCgpCisjZGVmaW5lIHhlbm9wcm9mX2FyY2hfZGlzYWJsZV92aXJxKCkgCisjZGVmaW5lIHhl
bm9wcm9mX2FyY2hfcmVsZWFzZV9jb3VudGVycygpCisKKworI2RlZmluZSB4ZW5vcHJvZl9z
aGFyZWRfZ21mbihkLCBnbWFkZHIsIG1hZGRyKQlcCitkbyB7CQkJCQkJXAorCSh2b2lkKSht
YWRkcik7CQkJCVwKK30gd2hpbGUgKDApCisKKworc3RhdGljIGlubGluZSB2b2lkIGlic19p
bml0KHZvaWQpIHt9CisjZGVmaW5lIGlic19jYXBzIDAKKworc3RhdGljIGlubGluZSBpbnQg
eGVub3Byb2ZfYmFja3RyYWNlX3N1cHBvcnRlZCh2b2lkKQoreworCXJldHVybiAwOworfQor
CitzdHJ1Y3QgdmNwdTsKK3N0cnVjdCBjcHVfdXNlcl9yZWdzOworCitpbnQgeGVub3Byb2Zf
YXJjaF9jb3VudGVyKFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKTsKK2ludCBjb21wYXRf
b3Byb2ZfYXJjaF9jb3VudGVyKFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKTsKK2ludCB4
ZW5vcHJvZl9hcmNoX2lic19jb3VudGVyKFhFTl9HVUVTVF9IQU5ETEUodm9pZCkgYXJnKTsK
Kworc3RhdGljIGlubGluZSB2b2lkIHhlbm9wcm9mX2JhY2t0cmFjZSgKKyAgICBzdHJ1Y3Qg
ZG9tYWluICpkLCBzdHJ1Y3QgdmNwdSAqdmNwdSwKKyAgICBzdHJ1Y3QgY3B1X3VzZXJfcmVn
cyAqY29uc3QgcmVncywgdW5zaWduZWQgbG9uZyBkZXB0aCwgaW50IG1vZGUpIHt9CisKK3N0
YXRpYyBpbmxpbmUgaW50IHhlbm9wcm9mX2FyY2hfaW5pdChpbnQgKm51bV9ldmVudHMsIGNo
YXIgKmNwdV90eXBlKQoreworCXJldHVybiAwOworfQorCisjZW5kaWYKZGlmZiAtciBlNzAx
NDYxYjEyNTEgeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gtYXJtLmgJRnJpIEZlYiAwMyAxNjowNzowMyAyMDEyICswOTAwCkBAIC0wLDAgKzEs
MTgwIEBACisjaWZuZGVmIF9fWEVOX1BVQkxJQ19BUkNIX0FSTV8zMl9IX18KKyNkZWZpbmUg
X19YRU5fUFVCTElDX0FSQ0hfQVJNXzMyX0hfXworCisjZGVmaW5lIFZQU1JfTU9ERV9TVkMy
NiAgICAgICAgIDB4MDAwMDAwMDMKKyNkZWZpbmUgVlBTUl9NT0RFX1VTUiAgICAgICAgICAg
MHgwMDAwMDAxMAorI2RlZmluZSBWUFNSX01PREVfRklRICAgICAgICAgICAweDAwMDAwMDEx
CisjZGVmaW5lIFZQU1JfTU9ERV9JUlEgICAgICAgICAgIDB4MDAwMDAwMTIKKyNkZWZpbmUg
VlBTUl9NT0RFX1NWQyAgICAgICAgICAgMHgwMDAwMDAxMworI2RlZmluZSBWUFNSX01PREVf
QUJUICAgICAgICAgICAweDAwMDAwMDE3CisjZGVmaW5lIFZQU1JfTU9ERV9VTkQgICAgICAg
ICAgIDB4MDAwMDAwMWIKKyNkZWZpbmUgVlBTUl9NT0RFX1NZUyAgICAgICAgICAgMHgwMDAw
MDAxZgorI2RlZmluZSBWUFNSX01PREVfTUFTSyAgICAgICAgICAweDAwMDAwMDFmCisKKyNk
ZWZpbmUgVlBTUl9UX0JJVCAgICAgICAgICAgICAgMHgwMDAwMDAyMAorI2RlZmluZSBWUFNS
X0ZfQklUICAgICAgICAgICAgICAweDAwMDAwMDQwCisjZGVmaW5lIFZQU1JfSV9CSVQgICAg
ICAgICAgICAgIDB4MDAwMDAxMDAKKyNkZWZpbmUgVlBTUl9KX0JJVCAgICAgICAgICAgICAg
MHgwMTAwMDAwMAorI2RlZmluZSBWUFNSX1FfQklUICAgICAgICAgICAgICAweDA4MDAwMDAw
CisjZGVmaW5lIFZQU1JfVl9CSVQgICAgICAgICAgICAgIDB4MTAwMDAwMDAKKyNkZWZpbmUg
VlBTUl9DX0JJVCAgICAgICAgICAgICAgMHgyMDAwMDAwMAorI2RlZmluZSBWUFNSX1pfQklU
ICAgICAgICAgICAgICAweDQwMDAwMDAwCisjZGVmaW5lIFZQU1JfTl9CSVQgICAgICAgICAg
ICAgIDB4ODAwMDAwMDAKKworLyoKKyAqIEdyb3VwcyBvZiBQU1IgYml0cworICovCisjZGVm
aW5lIFZQU1JfTUFTS19JTlRSICAgICAgICAgIChWUFNSX0lfQklUIHwgVlBTUl9GX0JJVCkK
KyNkZWZpbmUgVlBTUl9NQVNLX01PREUgICAgICAgICAgMHgwMDAwMDFmCisjZGVmaW5lIFZQ
U1JfTUFTS19GTEFHUyAgICAgICAgIDB4ZmYwMDAwMDAgICAgICAvKiBGbGFncyAgICAgICAg
ICAgICAgICAqLworI2RlZmluZSBWUFNSX01BU0tfU1RBVFVTICAgICAgICAweDAwZmYwMDAw
ICAgICAgLyogU3RhdHVzICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgVlBTUl9NQVNLX0VY
VEVOU0lPTiAgICAgMHgwMDAwZmYwMCAgICAgIC8qIEV4dGVuc2lvbiAgICAgICAgICAgICov
CisjZGVmaW5lIFZQU1JfTUFTS19DT05UUk9MICAgICAgIDB4MDAwMDAwZmYgICAgICAvKiBD
b250cm9sICAgICAgICAgICAgICAqLworCisvKgorICogSFlQRVJDQUxMUyBmb3IgQVJNIGFy
Y2hpdGVjdHVyZQorICovCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9yZXN0b3JlX3RyYXBfZnJh
bWUgICAgICAgICAgICAyMworCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9zZXRfY3B1X2RvbWFp
biAgICAgICAgICAgICAgICA0OAorI2RlZmluZSBfX0hZUEVSVklTT1JfZG9fc2V0X2ZvcmVn
cm91bmRfZG9tYWluICAgICAgNDkKKyNkZWZpbmUgX19IWVBFUlZJU09SX2RvX2djb3Zfb3Ag
ICAgICAgICAgICAgICAgICAgIDQwCisjZGVmaW5lIF9fSFlQRVJWSVNPUl9kb192ZnBfb3Ag
ICAgICAgICAgICAgICAgICAgICA1MQorI2RlZmluZSBfX0hZUEVSVklTT1JfZG9fc2V0X3Rs
cyAgICAgICAgICAgICAgICAgICAgNTIKKworI2RlZmluZSBUTEJGX0lUTEIgICAgICAgICAg
ICAgICAxCisjZGVmaW5lIFRMQkZfRFRMQiAgICAgICAgICAgICAgIDIKKyNkZWZpbmUgVExC
Rl9BU0lEICAgICAgICAgICAgICAgNAorCisKKyNkZWZpbmUgQ01EX0ZNUlggICAgICAgICAg
ICAgICAgMAorI2RlZmluZSBDTURfRk1YUiAgICAgICAgICAgICAgICAxCisKKyNkZWZpbmUg
RlBFWENfWEVOICAgICAgICAgICAgICAgMAorI2RlZmluZSBGUElOU1RfWEVOICAgICAgICAg
ICAgICAxCisjZGVmaW5lIEZQSU5TVDJfWEVOICAgICAgICAgICAgIDIKKyNkZWZpbmUgTVZG
UjBfWEVOICAgICAgICAgICAgICAgMworCisvKiBGUEVYQyBiaXRzICovCisjZGVmaW5lIEZQ
RVhDX0VYQ0VQVElPTiAgICAgICAgICgxPDwzMSkKKyNkZWZpbmUgRlBFWENfRU5BQkxFICAg
ICAgICAgICAgKDE8PDMwKQorCisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCisjaWZkZWYgX19Y
RU5fXworI2RlZmluZSBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShuYW1lLCB0eXBlKSBc
CisgICAgdHlwZWRlZiBzdHJ1Y3QgeyB0eXBlICpwOyB9IF9fZ3Vlc3RfaGFuZGxlXyAjIyBu
YW1lCisjZWxzZQorI2RlZmluZSBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShuYW1lLCB0
eXBlKSBcCisgICAgdHlwZWRlZiB0eXBlICogX19ndWVzdF9oYW5kbGVfICMjIG5hbWUKKyNl
bmRpZgorICAgIAorI2RlZmluZSBfX0RFRklORV9YRU5fR1VFU1RfSEFORExFKG5hbWUsIHR5
cGUpIFwKKyAgICBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShuYW1lLCB0eXBlKTsgICBc
CisgICAgX19fREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoY29uc3RfIyNuYW1lLCBjb25zdCB0
eXBlKQorCisjZGVmaW5lIERFRklORV9YRU5fR1VFU1RfSEFORExFKG5hbWUpIF9fREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUobmFtZSwgbmFtZSkKKyNkZWZpbmUgWEVOX0dVRVNUX0hBTkRM
RShuYW1lKSAgICAgICAgX19ndWVzdF9oYW5kbGVfICMjIG5hbWUKKyAgICAKKworLyoKKyAq
IFZpcnR1YWwgYWRkcmVzc2VzIGJleW9uZCB0aGlzIGFyZSBub3QgbW9kaWZpYWJsZSBieSBn
dWVzdCBPU2VzLiBUaGUgCisgKiBtYWNoaW5lLT5waHlzaWNhbCBtYXBwaW5nIHRhYmxlIHN0
YXJ0cyBhdCB0aGlzIGFkZHJlc3MsIHJlYWQtb25seS4KKyAqLworI2RlZmluZSBfX0hZUEVS
VklTT1JfVklSVF9TVEFSVCAweEZDMDAwMDAwCisKKyNpZm5kZWYgSFlQRVJWSVNPUl9WSVJU
X1NUQVJUCisjZGVmaW5lIEhZUEVSVklTT1JfVklSVF9TVEFSVCBta191bnNpZ25lZF9sb25n
KF9fSFlQRVJWSVNPUl9WSVJUX1NUQVJUKQorI2VuZGlmCisKKyNpZm5kZWYgbWFjaGluZV90
b19waHlzX21hcHBpbmcKKyNkZWZpbmUgbWFjaGluZV90b19waHlzX21hcHBpbmcgKCh1bnNp
Z25lZCBsb25nICopSFlQRVJWSVNPUl9WSVJUX1NUQVJUKQorI2VuZGlmCisKK3R5cGVkZWYg
dW5zaWduZWQgbG9uZyB4ZW5fcGZuX3Q7Cit0eXBlZGVmIHVuc2lnbmVkIGxvbmcgeGVuX3Vs
b25nX3Q7CisKK3R5cGVkZWYgc3RydWN0IHRyYXBfaW5mbyB7CisJdW5zaWduZWQgbG9uZyBp
bnN0cnVjdGlvbjsKK310cmFwX2luZm9fdDsKKworREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
dHJhcF9pbmZvX3QpOworCit0eXBlZGVmIHN0cnVjdCB2Y3B1X2d1ZXN0X2NvbnRleHQgewor
CXVuc2lnbmVkIGxvbmcJcjA7CisJdW5zaWduZWQgbG9uZwlyMTsKKwl1bnNpZ25lZCBsb25n
CXIyOworCXVuc2lnbmVkIGxvbmcJcjM7CisJdW5zaWduZWQgbG9uZwlyNDsKKwl1bnNpZ25l
ZCBsb25nCXI1OworCXVuc2lnbmVkIGxvbmcJcjY7CisJdW5zaWduZWQgbG9uZwlyNzsKKwl1
bnNpZ25lZCBsb25nCXI4OworCXVuc2lnbmVkIGxvbmcJcjk7CisJdW5zaWduZWQgbG9uZwly
MTA7CisJdW5zaWduZWQgbG9uZwlyMTE7CisJdW5zaWduZWQgbG9uZwlyMTI7CisJdW5zaWdu
ZWQgbG9uZwlyMTM7CisJdW5zaWduZWQgbG9uZwlyMTQ7CisJdW5zaWduZWQgbG9uZwlyMTU7
CisJdW5zaWduZWQgbG9uZyAgIHZiYXI7CisJdW5zaWduZWQgbG9uZyAgIGRhY3I7CisJdW5z
aWduZWQgbG9uZyAgIGNvbnRleHRpZHI7CisJdW5zaWduZWQgbG9uZyAgIGZjc2VpZHI7CisJ
dW5zaWduZWQgbG9uZyAgIHR0YnIwOworCXVuc2lnbmVkIGxvbmcgICB0dGJyMTsKKwl1bnNp
Z25lZCBsb25nICAgdHRiY3I7CisJdW5zaWduZWQgbG9uZwljcGFyOworfSB2Y3B1X2d1ZXN0
X2NvbnRleHRfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHZjcHVfZ3Vlc3RfY29udGV4
dF90KTsKKwordHlwZWRlZiBzdHJ1Y3QgY3B1X3VzZXJfcmVncyB7CisgICAgICAgIHVuc2ln
bmVkIGxvbmcgICByMDsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxOworICAgICAgICB1
bnNpZ25lZCBsb25nICAgcjI7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgICByMzsKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHI0OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjU7Cisg
ICAgICAgIHVuc2lnbmVkIGxvbmcgICByNjsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHI3
OworICAgICAgICB1bnNpZ25lZCBsb25nICAgcjg7CisgICAgICAgIHVuc2lnbmVkIGxvbmcg
ICByOTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMDsKKyAgICAgICAgdW5zaWduZWQg
bG9uZyAgIHIxMTsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxMjsKKyAgICAgICAgdW5z
aWduZWQgbG9uZyAgIHIxMzsKKyAgICAgICAgdW5zaWduZWQgbG9uZyAgIHIxNDsKKyAgICAg
ICAgdW5zaWduZWQgbG9uZyAgIHIxNTsKKwl1bnNpZ25lZCBsb25nCXBzcjsKK30gY3B1X3Vz
ZXJfcmVnc190OworREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoY3B1X3VzZXJfcmVnc190KTsK
KwordHlwZWRlZiBzdHJ1Y3QgYXJjaF92Y3B1X2luZm8geworCXVuc2lnbmVkIGxvbmcJc3A7
CisJdW5zaWduZWQgbG9uZwlscjsKKwl1bnNpZ25lZCBsb25nCWNwc3I7CisJdW5zaWduZWQg
bG9uZwlzcHNyOworCXVuc2lnbmVkIGxvbmcJY3I7CisJdW5zaWduZWQgbG9uZwljcGFyOwor
CXVuc2lnbmVkIGxvbmcJZGFjcjsKKwl1bnNpZ25lZCBsb25nCXBpZHI7CisJdW5zaWduZWQg
bG9uZwlmYXI7CisJdW5zaWduZWQgbG9uZwlmc3I7CisJdW5zaWduZWQgbG9uZwlyZXNlcnZl
ZDEwOworCXVuc2lnbmVkIGxvbmcJcmVzZXJ2ZWQxMTsKKwl1bnNpZ25lZCBsb25nCXJlc2Vy
dmVkMTI7CisJdW5zaWduZWQgbG9uZwlyZXNlcnZlZDEzOworCXVuc2lnbmVkIGxvbmcJcmVz
ZXJ2ZWQxNDsKK30gYXJjaF92Y3B1X2luZm9fdDsKKworI2RlZmluZSBYRU5fTEVHQUNZX01B
WF9WQ1BVUwk0CisKK3R5cGVkZWYgc3RydWN0IGFyY2hfc2hhcmVkX2luZm8geworCXVuc2ln
bmVkIGxvbmcJcGxhdGZvcm07CisJdW5zaWduZWQgbG9uZwltYXhfcGZuOworCXVuc2lnbmVk
IGxvbmcJcGZuX3RvX21mbl9mcmFtZV9saXN0X2xpc3Q7Cit9IGFyY2hfc2hhcmVkX2luZm9f
dDsKKworI2RlZmluZSBFTEZfU0laRQkzMgorI2VuZGlmCisjZW5kaWYK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt15-0005wD-3h; Mon, 13 Feb 2012 10:20:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwql3-0003Ca-QK
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:55:34 +0000
Received: from [85.158.139.83:28573] by server-10.bemta-5.messagelabs.com id
	83/3E-26909-5F1C83F4; Mon, 13 Feb 2012 07:55:33 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329119729!14157873!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13101 invoked from network); 13 Feb 2012 07:55:31 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-9.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 07:55:31 -0000
Received: from epcpsbge6.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005YUNBBEV50@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:55:29 +0900 (KST)
Message-id: <0LZB0050CNCHEV60@mailout1.samsung.com>
X-AuditID: cbfee610-b7b53ae000003b1c-9f-4f38c1f108de
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge6.samsung.com (EPCPMTA) with SMTP id 79.04.15132.1F1C83F4;
	Mon, 13 Feb 2012 16:55:29 +0900 (KST)
Date: Mon, 13 Feb 2012 07:55:29 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: =?euc-kr?Q?=B7=F9=C0=E7=B9=CE?= <jm77.ryu@samsung.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075324312@jm77.ryu
Msgkey: 20120213075324312@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213074940046@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 03/14]  arm: implement startup code.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <33545724.69781329119725940.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgc3RhcnR1cCBjb2RlLg0KDQogeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmls
ZSB8ICAgIDEgKw0KIHhlbi9hcmNoL2FybS94ZW4vc3RhcnQuUyAgfCAgMjczICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCB8ICAx
OTggKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1
bmcuY29tPg0KDQpkaWZmIC1yIGU2YWM4YjY4NmFhNiB4ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxl
DQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCUZyaSBGZWIgMDMgMTY6MDc6MzMgMjAx
MiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQlGcmkgRmViIDAzIDE2OjI2
OjM0IDIwMTIgKzA5MDANCkBAIC0xLDMgKzEsNCBAQA0KK29iai15ICs9IHN0YXJ0Lm8NCiBvYmot
eSArPSBzZXR1cC5vDQogb2JqLXkgKz0gbW0ubw0KIG9iai15ICs9IGlycS5vDQpkaWZmIC1yIGU2
YWM4YjY4NmFhNiB4ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMNCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJ
RnJpIEZlYiAwMyAxNjoyNjozNCAyMDEyICswOTAwDQpAQCAtMCwwICsxLDI3MyBAQA0KKy8qDQor
ICogc3RhcnQuUyANCisgKg0KKyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxl
Y3Ryb25pY3MgDQorICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNv
bT4NCisgKiAgICAgICAgICBKYWVtaW4gUnl1ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPg0KKyAq
DQorICogU2VjdXJlIFhlbiBvbiBBUk0gYXJjaGl0ZWN0dXJlIGRlc2lnbmVkIGJ5IFNhbmctYnVt
IFN1aCBjb25zaXN0cyBvZg0KKyAqIFhlbiBvbiBBUk0gYW5kIHRoZSBhc3NvY2lhdGVkIGFjY2Vz
cyBjb250cm9sLg0KKyAqIA0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMNCisgKiBw
dWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCisgKg0KKyAqIFRoaXMg
cHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVs
LA0KKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVk
IHdhcnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv
ciBtb3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFsb25nIHdpdGggdGhpcyBw
cm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQorICogRm91bmRhdGlv
biwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEz
MDcgIFVTQQ0KKyAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+DQorI2luY2x1ZGUgPGFz
bS9jcHUtZG9tYWluLmg+DQorI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4NCisjaW5jbHVkZSA8
YXNtL3BhZ2UuaD4NCisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPg0KKyNpbmNsdWRlIDxhc20vbW11
Lmg+DQorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+DQorDQorLyoNCisgKiBJbml0aWFsIHN0
YWNrIGZvciBjb3JlIDANCisgKi8NCisjZGVmaW5lIFNWQ19TVEFDS19TSVpFCVNUQUNLX1NJWkUN
CisNCisubWFjcm8gcGEgcmQsIHJzDQorMToNCisJYWRyCVxycywgMWINCisJbHNyCVxycywgXHJz
LCAjMjANCisJc3ViCVxyZCwgXHJkLCAjWEVOX1ZJUlRfU1RBUlQNCisJYWRkCVxyZCwgXHJkLCBc
cnMsIGxzbCAjMjANCisuZW5kbQ0KKwkNCisJLnNlY3Rpb24gLmhlYWQNCitFTlRSWShzdGFydCkN
CisJbXNyICAgICBjcHNyX2MsICMoUFNSX0ZfQklUIHwgUFNSX0lfQklUIHwgUFNSX01PREVfU1ZD
KQ0KKw0KKyNpZmRlZiBTTVANCisJbXJjCUFDVExSKHIyKQ0KKwlvcnIJcjIsIHIyLCAjKEFDVExS
X1NNUCkgfCAoQUNUTFJfRlcpDQorCW1jcglBQ1RMUihyMikNCisjZW5kaWYNCisJDQorCWFkcgly
MCwgc3RhcnQNCisJbW92CXIxLCByMA0KKwlzdWIJcjAsIHIwLCAjMHg0MDAwCQ0KKwltb3YJcjIs
ICMwDQorMToJc3RyCXIyLCBbcjEsICMtNF0hDQorCXN0cglyMiwgW3IxLCAjLTRdIQ0KKwlzdHIJ
cjIsIFtyMSwgIy00XSENCisJc3RyCXIyLCBbcjEsICMtNF0hDQorCWNtcAlyMCwgcjENCisJYm5l
CTFiDQorDQorCWxkciAgICAgcjIsID0oWEVOX1ZJUlRfU1RBUlQgPj4gMjApDQorCWxkciAgICAg
cjcsID0oTDFFX1RZUEVfSFlQRVJWSVNPUikNCisNCisJQCBTdGFydCBzZWN0aW9uIG5vLg0KKwlt
b3YgICAgIHIzLCBwYw0KKwlsc3IgICAgIHIzLCByMywgIzIwDQorDQorCUAgSW5pdGlhbCBWTU0g
bWFwcGluZw0KKwlvcnIgICAgIHI0LCByNywgcjMsIGxzbCAjMjANCisJc3RyICAgICByNCwgW3Iw
LCByMiwgbHNsICMyXQ0KKwlAYWRkCXI0LCByNCwgIzB4MTAwMDAwDQorCUBhZGQJcjIsIHIyLCAj
MQ0KKwlAc3RyCXI0LCBbcjAsIHIyLCBsc2wgIzJdDQorDQorICAgICAgICBsZHIgICAgIHI1LCA9
X3NtZW10YWJsZQ0KKwlwYQlyNSwgcjYNCisJbGRyCXI2LCA9X2VtZW10YWJsZQ0KKwlwYQlyNiwg
cjcNCisNCisxOg0KKwljbXAJcjUsIHI2DQorCWJlcQkzZg0KKw0KKwlAIHIxIDogYmFzZQ0KKwlA
IHIyIDogc2l6ZQ0KKwlAIHIzIDogdHlwZQ0KKwlAIHI0IDogbW11X2ZsYWdzDQorDQorICAgICAg
ICBsZG1pYSAgIHI1ISwge3IxLCByMiwgcjMsIHI0fQ0KKwlsc3IJcjEsIHIxLCAjMjANCisJb3Jy
CXI0LCByNCwgcjEsIGxzbCAjMjANCisNCisJQCBSb3VuZCB1cA0KKwlhZGQJcjIsIHIyLCAjMHhG
RjAwDQorCWFkZAlyMiwgcjIsICMweDAwRkYNCisJbHNyCXIyLCByMiwgIzIwDQorMjoNCisgICAg
ICAgIHN0ciAgICAgcjQsIFtyMCwgcjEsIGxzbCAjMl0NCisgICAgICAgIGFkZCAgICAgcjEsIHIx
LCAjMQ0KKyAgICAgICAgYWRkICAgICByNCwgcjQsICMweDEwMDAwMA0KKyAgICAgICAgYWRkcyAg
ICByMiwgcjIsICMtMQ0KKyAgICAgICAgYmhpICAgICAyYg0KKwliCTFiDQorMzoNCisNCisJQCBM
b2FkIFRyYW5zbGF0aW9uIFRhYmxlIEJhc2UNCisJb3JyCXIwLCByMCwgIyhUVEJfRkxBR1MpDQor
CW1jcglUVEJSMChyMCkNCisJbWNyCVRUQlIxKHIwKQ0KKw0KKwlAIFRUQkNSIFNldHRpbmcNCisg
ICAgICAgIG1yYyAgICAgcDE1LCAwLCByNSwgYzEsIGMwLCAyDQorICAgICAgICBvcnIgICAgIHI1
LHI1LCAjKCgzIDw8ICgxMCAqIDIpKSB8KDMgPDwgKDExICogMikpKQ0KKyAgICAgICAgbWNyICAg
ICBwMTUsIDAsIHI1LCBjMSwgYzAsIDINCisNCisJQCBMb2FkIERBQw0KKwlsZHIJcjUsID0weDU1
NTU1NTU1DQorCW1jcglEQUNSKHI1KQ0KKw0KKwlsZHIJcjUsID0weEZGMEE4OUE4DQorCWxkcgly
NiwgPTB4NDBFMDQwRTANCisJbWNyCXAxNSwgMCwgcjUsIGMxMCwgYzIsIDANCisJbWNyCXAxNSwg
MCwgcjYsIGMxMCwgYzIsIDENCisNCisJQCBUdXJuIG9uIE1NVQ0KKwlsZHIJcjAsID0oU0NUTFJf
VFJFIHwgU0NUTFJfU1cgfCBTQ1RMUl9aIHwgU0NUTFJfSSB8IFNDVExSX0MgfCBTQ1RMUl9BIHwg
U0NUTFJfTSkNCisJbWNyCVNDVExSKHIwKQ0KKwltb3YJcjAsIHIwDQorCW1vdglyMCwgcjANCisJ
bW92CXIwLCByMA0KKw0KKwlAIEludmFsaWRhdGUgSS9EIFRMQnMNCisJbW92CWlwLCAjMA0KKwlt
Y3IJcDE1LCAwLCBpcCwgYzgsIGM3LCAwDQorCWRzYg0KKwlpc2INCisNCisJQCBDbGVhciBCU1Mg
c2VjdGlvbg0KKwlhZHIgICAgIHIwLCAyZg0KKwlsZG1pYSAgIHIwLCB7cjEsIHIyfQ0KKwltb3Yg
ICAgIHIwLCAjMA0KKzE6DQorCXN0ciAgICAgcjAsIFtyMV0sICM0IA0KKwljbXAgICAgIHIxLCBy
Mg0KKwlibG8gICAgIDFiDQorDQorICAgICAgICAvKiBTdGFjayBTZXR1cCAqLw0KKwlAIEdldCBw
cm9jZXNzb3IgSUQNCisgICAgICAgIG1yYyAgICAgTVBJRFIocjQpDQorICAgICAgICBhbmQgICAg
IHI0LCByNCwgIzE1DQorDQorCUAgcjAgPSByMCAqIFNUQUNLX1NJWkUNCisgICAgICAgIG1vdiAg
ICAgcjEsICNTVEFDS19TSVpFDQorICAgICAgICBtdWwgICAgIHI0LCByNCwgcjENCisNCisJbXNy
CWNwc3JfYywgI1BTUl9NT0RFX0lSUSB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVA0KKwlsZHIJc3As
ID0oaXJxX3N0YWNrcyArIFNUQUNLX1NJWkUpDQorCWFkZAlzcCwgc3AsIHI0DQorDQorCW1zcglj
cHNyX2MsICNQU1JfTU9ERV9BQlQgfCBQU1JfSV9CSVQgfCBQU1JfRl9CSVQNCisJbGRyCXNwLCA9
KGFidF9zdGFja3MgKyBTVEFDS19TSVpFKQ0KKwlhZGQJc3AsIHNwLCByNA0KKw0KKwltc3IJY3Bz
cl9jLCAjUFNSX01PREVfVU5EIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUDQorCWxkcglzcCwgPSh1
bmRfc3RhY2tzICsgU1RBQ0tfU0laRSkNCisJYWRkCXNwLCBzcCwgcjQNCisNCisJbXNyICAgICBj
cHNyX2MsICNQU1JfTU9ERV9TVkMgfCBQU1JfSV9CSVQgfCBQU1JfRl9CSVQNCisJbGRyICAgICBz
cCwgPShzdmNfc3RhY2tzICsgU1RBQ0tfU0laRSkNCisJYWRkCXNwLCBzcCwgcjQNCisNCisJYWRy
ICAgICByMTIsIDNmDQorCWxkcglwYywgW3IxMl0NCisNCisyOgkud29yZCAgIF9zYnNzDQorCS53
b3JkICAgX2Vic3MNCisNCiszOg0KKwkubG9uZyAgIHN0YXJ0X3hlbg0KKw0KKyNpZmRlZiBTTVAN
CisgICAgICAgIC8qDQorICAgICAgICAgKiBDb21tb24gZW50cnkgcG9pbnQgZm9yIHNlY29uZGFy
eSBDUFVzLg0KKyAgICAgICAgICoNCisgICAgICAgICAqIEVuc3VyZSB0aGF0IHdlJ3JlIGluIFNW
QyBtb2RlLCBhbmQgSVJRcyBhcmUgZGlzYWJsZWQuDQorICAgICAgICAgKi8NCisJLnNlY3Rpb24g
LmhlYWQNCitFTlRSWShzbGF2ZV9jcHVfc3RhcnQpDQorCW1zciAgICAgY3Bzcl9jLCAjUFNSX0Zf
QklUIHwgUFNSX0lfQklUIHwgUFNSX01PREVfU1ZDDQorDQorICAgICAgICBtcmMgICAgIEFDVExS
KHIyKQ0KKyAgICAgICAgb3JyICAgICByMiwgcjIsICMoQUNUTFJfU01QKSB8IChBQ1RMUl9GVykN
CisgICAgICAgIG1jciAgICAgQUNUTFIocjIpDQorDQorCUAgTG9hZCBUcmFuc2xhdGlvbiBUYWJs
ZSBCYXNlDQorCWFkcglyNCwgc3RhcnQNCisJc3ViCXI0LCByNCwgIzB4NDAwMA0KKwlvcnIgICAg
IHI0LCByNCwgIyhUVEJfRkxBR1MpDQorCW1jcglUVEJSMChyNCkNCisJbWNyCVRUQlIxKHI0KQ0K
Kw0KKwlAIFRUQkNSIFNldHRpbmcNCisgICAgICAgIG1yYyAgICAgcDE1LCAwLCByNSwgYzEsIGMw
LCAyDQorICAgICAgICBvcnIgICAgIHI1LHI1LCAjKCgzIDw8ICgxMCAqIDIpKSB8KDMgPDwgKDEx
ICogMikpKQ0KKyAgICAgICAgbWNyICAgICBwMTUsIDAsIHI1LCBjMSwgYzAsIDINCisNCisJQCBM
b2FkIERBQw0KKwlsZHIgICAgIHI1LCA9MHg1NTU1NTU1NQ0KKwltY3IgICAgIERBQ1IocjUpDQor
CQ0KKwlsZHIJcjUsID0weEZGMEE4OUE4DQorCWxkcglyNiwgPTB4NDBFMDQwRTANCisJbWNyCXAx
NSwgMCwgcjUsIGMxMCwgYzIsIDANCisJbWNyCXAxNSwgMCwgcjYsIGMxMCwgYzIsIDENCisNCisJ
QCBUdXJuIG9uIE1NVQ0KKwlsZHIJcjAsID0oU0NUTFJfVFJFIHwgU0NUTFJfU1cgfCBTQ1RMUl9a
IHwgU0NUTFJfSSB8IFNDVExSX0MgfCBTQ1RMUl9BIHwgU0NUTFJfTSkNCisJbWNyCVNDVExSKHIw
KQ0KKwltb3YgICAgIHIwLCByMA0KKwltb3YgICAgIHIwLCByMA0KKwltb3YgICAgIHIwLCByMA0K
Kw0KKyAgICAgICAgQCBJbnZhbGlkYXRlIEksIEQgVExCcw0KKwltb3YJaXAsICMwDQorCW1jciAg
ICAgcDE1LCAwLCBpcCwgYzgsIGM3LCAwDQorCWRzYg0KKwlpc2INCisNCisJLyogU3RhY2sgU2V0
dXAgKi8NCisgICAgICAgIEAgZ2V0IHByb2Nlc3NvciBpZA0KKwltcmMgICAgIE1QSURSKHI0KQ0K
KwlhbmQJcjQsIHI0LCAjMTUNCisJCQ0KKwlAIHIwID0gcjAgKiBTVEFDS19TSVpFDQorCW1vdgly
MSwgI1NUQUNLX1NJWkUNCisJbXVsCXI0LCByNCwgcjENCisJDQorCW1zcgljcHNyX2MsICNQU1Jf
TU9ERV9JUlEgfCBQU1JfSV9CSVQgfCBQU1JfRl9CSVQNCisJbGRyCXNwLCA9KGlycV9zdGFja3Mg
KyBTVEFDS19TSVpFKQ0KKwlhZGQJc3AsIHNwLCByNA0KKw0KKwltc3IJY3Bzcl9jLCAjUFNSX01P
REVfQUJUIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUDQorCWxkcglzcCwgPShhYnRfc3RhY2tzICsg
U1RBQ0tfU0laRSkNCisJYWRkCXNwLCBzcCwgcjQNCisNCisJbXNyCWNwc3JfYywgI1BTUl9NT0RF
X1VORCB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVA0KKwlsZHIJc3AsID0odW5kX3N0YWNrcyArIFNU
QUNLX1NJWkUpDQorCWFkZAlzcCwgc3AsIHI0DQorDQorCW1zciAgICAgY3Bzcl9jLCAjUFNSX01P
REVfU1ZDIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUDQorCWxkciAgICAgc3AsID0oc3ZjX3N0YWNr
cyArIFNUQUNLX1NJWkUpDQorCWFkZAlzcCwgc3AsIHI0DQorDQorCWFkciAgICAgcjEyLCAyZg0K
KwlsZG1pYSAgIHIxMiwge2xyLCBwY30NCisNCisyOg0KKwkubG9uZyAgIDJiDQorCS5sb25nCXN0
YXJ0X3hlbl9vbl9zbGF2ZV9jcHUNCisjZW5kaWYNCisNCisJLnNlY3Rpb24gLmJzcy5zdGFja19h
bGlnbmVkLCJ3Ig0KK3N2Y19zdGFja3M6IC5maWxsIFNWQ19TVEFDS19TSVpFLCBNQVhfUEhZU19D
UFVTLCAwDQoraXJxX3N0YWNrczogLmZpbGwgU1ZDX1NUQUNLX1NJWkUsIE1BWF9QSFlTX0NQVVMs
IDANCit1bmRfc3RhY2tzOiAuZmlsbCBTVkNfU1RBQ0tfU0laRSwgTUFYX1BIWVNfQ1BVUywgMA0K
K2FidF9zdGFja3M6IC5maWxsIFNWQ19TVEFDS19TSVpFLCBNQVhfUEhZU19DUFVTLCAwDQorZmlx
X3N0YWNrczogLmZpbGwgU1ZDX1NUQUNLX1NJWkUsIE1BWF9QSFlTX0NQVVMsIDANCmRpZmYgLXIg
ZTZhYzhiNjg2YWE2IHhlbi9pbmNsdWRlL2FzbS1hcm0vbW11LmgNCi0tLSBhL3hlbi9pbmNsdWRl
L2FzbS1hcm0vbW11LmgJRnJpIEZlYiAwMyAxNjowNzozMyAyMDEyICswOTAwDQorKysgYi94ZW4v
aW5jbHVkZS9hc20tYXJtL21tdS5oCUZyaSBGZWIgMDMgMTY6MjY6MzQgMjAxMiArMDkwMA0KQEAg
LTEsMTEgKzEsMjA5IEBADQogI2lmbmRlZiBfX0FSTV9NTVVfSF9fDQogI2RlZmluZSBfX0FSTV9N
TVVfSF9fDQogDQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1k
b21haW4uaD4NCisNCisjZGVmaW5lIEwxRV9GTEFHX01BU0sgICAgICAgICAgICgweDNGRikNCisN
CisjZGVmaW5lIEwxRV9UWVBFX0ZBVUxUICAgICAgICAgICgweDAwKQ0KKyNkZWZpbmUgTDFFX1RZ
UEVfVEFCTEUgICAgICAgICAgKDB4MDEpDQorI2RlZmluZSBMMUVfVFlQRV9TRUNUSU9OICAgICAg
ICAoMHgwMikNCisjZGVmaW5lIEwxRV9UWVBFX01BU0sgICAgICAgICAgICgweDAzKQ0KKw0KKyNk
ZWZpbmUgTDFFX0JJVDQJCSgxIDw8IDQpDQorDQorI2RlZmluZSBMMUVfQVBfU1JXX1VOTyAgICAg
ICAgICAoMHgwMSA8PCAxMCkNCisjZGVmaW5lIEwxRV9BUF9TUldfVVJPICAgICAgICAgICgweDAy
IDw8IDEwKQ0KKyNkZWZpbmUgTDFFX0FQX1NSV19VUlcgICAgICAgICAgKDB4MDMgPDwgMTApDQor
DQorI2RlZmluZSBMMUVfQlVGRkVSQUJMRSAgICAgICAgICAoMHgwNCkNCisjZGVmaW5lIEwxRV9D
QUNIRUFCTEUgICAgICAgICAgICgweDA4KQ0KKw0KKyNkZWZpbmUgTDFFX1RFWCh4KSAgICAgICAg
ICAgICAgKCh4KSA8PDEyKQ0KKyNkZWZpbmUgTDFFX0FQWCAgICAgICAgICAgICAgICAgKDEgPDwg
MTUpDQorI2RlZmluZSBMMUVfUyAgICAgICAgICAgICAgICAgICAoMSA8PCAxNikNCisjZGVmaW5l
IEwxRV9uRyAgICAgICAgICAgICAgICAgICgxIDw8IDE3KQ0KKw0KKyNkZWZpbmUgTDFFX1NUUk9O
R09SREVSRUQgICAgICAgKDApDQorI2RlZmluZSBMMUVfREVWSUNFICAgICAgICAgICAgICAoTDFF
X1RFWCgxKSkNCisjZGVmaW5lIEwxRV9XUklURUJBQ0sgICAgICAgICAgIChMMUVfQ0FDSEVBQkxF
IHwgTDFFX0JVRkZFUkFCTEUpDQorI2RlZmluZSBMMUVfV1JJVEVUSFJPVUdIICAgICAgICAoTDFF
X0NBQ0hFQUJMRSkNCisjZGVmaW5lIEwxRV9XUklURUFMTE9DICAgICAgICAgIChMMUVfVEVYKDEp
IHwgTDFFX0NBQ0hFQUJMRSB8IEwxRV9CVUZGRVJBQkxFKQ0KKyNkZWZpbmUgTDFFX1NIQVJFRCAg
ICAgICAgICAgICAgKDApDQorDQorI2RlZmluZSBMMUVfRE9NQUlOX0hZUAkJKERPTUFJTl9IWVAg
PDwgNSkNCisjZGVmaW5lIEwxRV9ET01BSU5fU1ZDCQkoRE9NQUlOX1NWQyA8PCA1KQ0KKyNkZWZp
bmUgTDFFX0RPTUFJTl9VU1IJCShET01BSU5fVVNSIDw8IDUpDQorI2RlZmluZSBMMUVfRE9NQUlO
X0lPICAgICAgICAgICAoRE9NQUlOX0lPIDw8IDUpDQorDQorI2RlZmluZSBMMUVfV0JXQSAgICAg
ICAgICAgICAgICAoTDFFX1RFWCgxKSB8IEwxRV9XUklURUJBQ0spDQorDQorI2RlZmluZSBTRUNU
SU9OX1NISUZUICAgICAgICAgICAoMjApDQorI2RlZmluZSBTRUNUSU9OX1NJWkUgICAgICAgICAg
ICAoMSA8PCBTRUNUSU9OX1NISUZUKQ0KKyNkZWZpbmUgU0VDVElPTl9NQVNLICAgICAgICAgICAg
KH4oU0VDVElPTl9TSVpFIC0gMSkpDQorDQorI2RlZmluZSBMMUVfVFlQRV9IWVBFUlZJU09SICAg
ICAoTDFFX1RZUEVfU0VDVElPTiB8IEwxRV9ET01BSU5fSFlQIHwgTDFFX1MgfCBMMUVfQVBfU1JX
X1VOTyB8IEwxRV9XUklURUFMTE9DKQ0KKyNkZWZpbmUgTDFFX1RZUEVfR1VFU1QJCShMMUVfVFlQ
RV9TRUNUSU9OIHwgTDFFX0RPTUFJTl9TVkMgfCBMMUVfUyB8IEwxRV9BUF9TUldfVVJXIHwgTDFF
X1dSSVRFQUxMT0MpDQorI2RlZmluZSBMMUVfVFlQRV9ERVZJQ0UJCShMMUVfVFlQRV9TRUNUSU9O
IHwgTDFFX0RPTUFJTl9JTyAgfCBMMUVfUyB8IEwxRV9BUF9TUldfVVJXIHwgTDFFX0RFVklDRSkN
CisNCisvKg0KKyAqIERlZmluaXRpb24gZm9yIFBhZ2UgVGFibGUgRW50cmllcw0KKyAqLw0KKw0K
KyNkZWZpbmUgTDJFX0ZMQUdfTUFTSyAgICAgICAgICAgKDB4RkZGKQ0KKw0KKyNkZWZpbmUgTDJF
X1RZUEVfRkFVTFQgICAgICAgICAgKDB4MDApDQorI2RlZmluZSBMMkVfVFlQRV9MQVJHRSAgICAg
ICAgICAoMHgwMSkNCisjZGVmaW5lIEwyRV9UWVBFX1NNQUxMICAgICAgICAgICgweDAyKQ0KKyNk
ZWZpbmUgTDJFX1RZUEVfVElOWSAgICAgICAgICAgKDB4MDMpDQorI2RlZmluZSBMMkVfVFlQRV9F
WFQgICAgICAgICAgICAoMHgwMikNCisNCisjZGVmaW5lIEwyRV9UWVBFX01BU0sgICAgICAgICAg
ICgweDAzKQ0KKw0KKyNkZWZpbmUgTDJFX0JVRkZFUkFCTEUgICAgICAgICAgKDB4MDQpDQorI2Rl
ZmluZSBMMkVfQ0FDSEVBQkxFICAgICAgICAgICAoMHgwOCkNCisNCisjZGVmaW5lIEwxRV9TSElG
VCAgICAgICAgICAgICAgICgyMCkNCisjZGVmaW5lIEwyRV9TSElGVAkJKDEyKQ0KKw0KKyNkZWZp
bmUgTDJFX0VYVF9YTiAgICAgICAgICAgICAgKDEgPDwgMCkNCisjZGVmaW5lIEwyRV9FWFRfQVBf
TUFTSyAgICAgICAgICgzIDw8IDQpDQorI2RlZmluZSBMMkVfRVhUX0FQMCAgICAgICAgICAgICAo
MSA8PCA0KQ0KKyNkZWZpbmUgTDJFX0VYVF9BUDEgICAgICAgICAgICAgKDIgPDwgNCkNCisjZGVm
aW5lIEwyRV9FWFRfQVBfVU5PX1NSTyAgICAgICgwIDw8IDQpDQorI2RlZmluZSBMMkVfRVhUX0FQ
X1VOT19TUlcgICAgICAoTDJFX0VYVF9BUDApDQorI2RlZmluZSBMMkVfRVhUX0FQX1VST19TUlcg
ICAgICAoTDJFX0VYVF9BUDEpDQorI2RlZmluZSBMMkVfRVhUX0FQX1VSV19TUlcgICAgICAoTDJF
X0VYVF9BUDF8TDJFX0VYVF9BUDApDQorI2RlZmluZSBMMkVfRVhUX1RFWCh4KSAgICAgICAgICAo
KHgpIDw8IDYpDQorI2RlZmluZSBMMkVfRVhUX0FQWCAgICAgICAgICAgICAoMSA8PCA5KQ0KKyNk
ZWZpbmUgTDJFX0VYVF9DT0hFUkVOVCAgICAgICAgKDEgPDwgOSkNCisjZGVmaW5lIEwyRV9FWFRf
U0hBUkVEICAgICAgICAgICgxIDw8IDEwKQ0KKyNkZWZpbmUgTDJFX0VYVF9ORyAgICAgICAgICAg
ICAgKDEgPDwgMTEpDQorDQorDQorI2RlZmluZSBMMV9UQUJMRV9FTlRSSUVTCSg0MDk2KQ0KKyNk
ZWZpbmUgTDJfVEFCTEVfRU5UUklFUwkoMjU2KQ0KKw0KKyNkZWZpbmUgTDFfVEFCTEVfU0laRQkJ
KDB4NDAwMCkNCisNCisjZGVmaW5lIEwyRV9HVUVTVF9BUF9NQVNLICAgICAgIEwyRV9FWFRfQVBf
TUFTSw0KKyNkZWZpbmUgTDJFX0dVRVNUX0FQX05PICAgICAgICAgTDJFX0VYVF9BUF9VTk9fU1JX
DQorI2RlZmluZSBMMkVfR1VFU1RfQVBfUk8gICAgICAgICBMMkVfRVhUX0FQX1VST19TUlcNCisj
ZGVmaW5lIEwyRV9HVUVTVF9BUF9SVyAgICAgICAgIEwyRV9FWFRfQVBfVVJXX1NSVw0KKw0KKyNk
ZWZpbmUgTDFFX0dVRVNUX1RBQkxFICAgICAgICAgKEwxRV9ET01BSU5fU1ZDIHwgTDFFX1RZUEVf
VEFCTEUpDQorI2RlZmluZSBMMUVfVkVDVE9SX1RBQkxFICAgICAgICAoTDFFX0RPTUFJTl9TVkMg
fCBMMUVfVFlQRV9UQUJMRSkNCisNCisjZGVmaW5lIEwyRV9HVUVTVF9QQUdFICAgICAgICAgIChM
MkVfRVhUX1NIQVJFRCB8IEwyRV9HVUVTVF9BUF9SVyB8IEwyRV9FWFRfVEVYKDEpIHwgTDJFX0JV
RkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX1RZUEVfRVhUKQ0KKw0KKyNkZWZpbmUgTDJF
X1ZFQ1RPUl9QQUdFICAgICAgICAgKEwyRV9HVUVTVF9BUF9STyB8IEwyRV9FWFRfVEVYKDEpIHwg
TDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX1RZUEVfRVhUKQ0KKyNkZWZpbmUg
TDJFX0dSQU5UX1BBR0UJCShMMkVfVFlQRV9FWFQgfCBMMkVfRVhUX1NIQVJFRCB8IEwyRV9FWFRf
VEVYKDEpIHwgTDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX0dVRVNUX0FQX1JX
KQ0KKyNkZWZpbmUgTDJFX1NIQVJFRF9JTkZPCQkoTDJFX1RZUEVfRVhUIHwgTDJFX0VYVF9URVgo
MSkgfCBMMkVfRVhUX1hOIHwgTDJFX0VYVF9TSEFSRUQgfCBMMkVfQlVGRkVSQUJMRSB8IEwyRV9D
QUNIRUFCTEUgfCBMMkVfR1VFU1RfQVBfUlcpDQorI2RlZmluZSBMMkVfREVWSUNFCQkoTDJFX1RZ
UEVfRVhUIHwgTDJFX0VYVF9URVgoMSkgfCBMMkVfRVhUX1hOIHwgTDJFX0VYVF9TSEFSRUQgfCBM
MkVfR1VFU1RfQVBfUlcpDQorDQogI2RlZmluZSBQQUREUl9CSVRTICAgICAgICAgICAgICAzMg0K
ICNkZWZpbmUgUEFERFJfTUFTSyAgICAgICAgICAgICAgKCgxVUwgPDwgUEFERFJfQklUUykgLSAx
KQ0KIA0KICNkZWZpbmUgVkFERFJfQklUUyAgICAgICAgICAgICAgMzINCiAjZGVmaW5lIFZBRERS
X01BU0sgICAgICAgICAgICAgICgoMVVMIDw8IFZBRERSX0JJVFMpIC0gMSkNCiANCisjZGVmaW5l
IFRUQl9TICAgICAgICAgICAoMSA8PCAxKQ0KKyNkZWZpbmUgVFRCX1JHTl9OQyAgICAgICgwIDw8
IDMpDQorI2RlZmluZSBUVEJfUkdOX09DX1dCV0EgKDEgPDwgMykNCisjZGVmaW5lIFRUQl9SR05f
T0NfV1QgICAoMiA8PCAzKQ0KKyNkZWZpbmUgVFRCX1JHTl9PQ19XQiAgICgzIDw8IDMpDQorI2Rl
ZmluZSBUVEJfTk9TICAgICAgICAgKDEgPDwgNSkNCisjZGVmaW5lIFRUQl9JUkdOX05DICAgICAo
KDAgPDwgMCkgfCAoMCA8PCA2KSkNCisjZGVmaW5lIFRUQl9JUkdOX1dCV0EgICAoKDAgPDwgMCkg
fCAoMSA8PCA2KSkNCisjZGVmaW5lIFRUQl9JUkdOX1dUICAgICAoKDEgPDwgMCkgfCAoMCA8PCA2
KSkNCisjZGVmaW5lIFRUQl9JUkdOX1dCICAgICAoKDEgPDwgMCkgfCAoMSA8PCA2KSkNCisNCisN
CisjZGVmaW5lIFRUQl9GTEFHUyAgICAgICAgICAgICAgIChUVEJfSVJHTl9XQldBIHwgVFRCX1Mg
fCBUVEJfTk9TIHwgVFRCX1JHTl9PQ19XQldBKQ0KKw0KKyNkZWZpbmUgVFRCX01BU0sJCSh+MHgz
RkZGKQ0KKw0KKyNpZm5kZWYgX19BU1NFTUJMWV9fDQorDQorI2luY2x1ZGUgPGFzbS90eXBlcy5o
Pg0KKw0KKyNkZWZpbmUgbDJlX3ZhbCh4KSAgICAgICAgICAgICAgKCh4KS5sMmUpDQorI2RlZmlu
ZSBsMWVfdmFsKHgpICAgICAgICAgICAgICAoKHgpLmwxZSkNCisNCisjZGVmaW5lIE1LX0wyRSh4
LCBmbGFncykJKChsMmVfdCkgeyAoKHVuc2lnbmVkIGxvbmcpKHgpICYgKH5MMkVfRkxBR19NQVNL
KSkgfCBmbGFncyB9ICkNCisjZGVmaW5lIE1LX0wxRSh4LCBmbGFncykJKChsMWVfdCkgeyAoKHVu
c2lnbmVkIGxvbmcpKHgpICYgKH5MMUVfRkxBR19NQVNLKSkgfCBmbGFncyB9ICkNCisNCisjZGVm
aW5lIGwxdF9pbmRleCh4KQkJKCgodW5zaWduZWQgbG9uZykoeCkgPj4gTDFFX1NISUZUKSAmIChM
MV9UQUJMRV9FTlRSSUVTIC0gMSkpDQorI2RlZmluZSBsMnRfaW5kZXgoeCkJCSgoKHVuc2lnbmVk
IGxvbmcpKHgpID4+IEwyRV9TSElGVCkgJiAoTDJfVEFCTEVfRU5UUklFUyAtIDEpKQ0KKw0KKyNk
ZWZpbmUgbDFfbGluZWFyX29mZnNldF94ZW4odmEpCVwNCisJKGwxX2xpbmVhcl9vZmZzZXQoKHhl
bl90cmFuc2xhdGlvbl90YWJsZSksIHZhKSkNCisNCit0eXBlZGVmIHN0cnVjdCB7IHVuc2lnbmVk
IGxvbmcgbDJlOyB9IGwyZV90Ow0KK3R5cGVkZWYgc3RydWN0IHsgdW5zaWduZWQgbG9uZyBsMWU7
IH0gbDFlX3Q7DQorDQorc3RhdGljIGlubGluZSBsMWVfdCAqbDFfbGluZWFyX29mZnNldChsMWVf
dCAqbDFlLCB1bnNpZ25lZCBsb25nIHZpcnQpDQorew0KKwlyZXR1cm4gbDFlICsgbDF0X2luZGV4
KHZpcnQpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIGwyZV90ICpsMl9saW5lYXJfb2Zmc2V0KGwx
ZV90ICpsMWUsIHVuc2lnbmVkIGxvbmcgdmlydCkNCit7DQorICAgICAgICBsMmVfdCAqbDJlOw0K
Kw0KKyAgICAgICAgbDJlID0gKGwyZV90ICopIChsMWVfdmFsKCpsMWUpICYgfkwxRV9GTEFHX01B
U0spOw0KKyAgICAgICAgbDJlID0gbDJlICsgbDJ0X2luZGV4KHZpcnQpOw0KKw0KKyAgICAgICAg
cmV0dXJuIGwyZTsNCit9DQorDQorc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQgZ2V0X2RhY3Io
dm9pZCkNCit7DQorCXVuc2lnbmVkIGludCB2YWw7DQorDQorCWFzbSgibXJjIHAxNSwgMCwgJTAs
IGMzLCBjMCwgMCIgOiAiPXIiICh2YWwpIDogOiAiY2MiKTsNCisNCisJcmV0dXJuIHZhbDsNCit9
DQorDQorDQorc3RhdGljIGlubGluZSB2b2lkIHNldF9kYWNyKHVuc2lnbmVkIGxvbmcgdmFsKQ0K
K3sNCisJYXNtKCJtcmMgcDE1LCAwLCAlMCwgYzMsIGMwLCAwIiA6ICI9ciIgKHZhbCkgOiA6ICJj
YyIpOw0KK30NCisNCisNCitzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGludCBnZXRfdHRicih2b2lk
KQ0KK3sNCisJdW5zaWduZWQgaW50IHZhbDsNCisJDQorCWFzbSgibXJjIHAxNSwgMCwgJTAsIGMy
LCBjMCwgMCIgOiAiPXIiICh2YWwpIDogOiAiY2MiKTsNCisNCisJcmV0dXJuIHZhbDsNCit9DQor
DQorc3RhdGljIGlubGluZSB2b2lkIHNldF90dGJyKHVuc2lnbmVkIGludCB0dGIpDQorew0KKwlh
c20gdm9sYXRpbGUoIm1jciBwMTUsIDAsICUwLCBjMiwgYzAsIDAiIDogOiAiciIgKHR0YikgOiAi
Y2MiKTsNCisNCisJaXNiKCk7DQorfQ0KKw0KK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfY29udGV4
dGlkcih1bnNpZ25lZCBsb25nIGlkKQ0KK3sNCisJYXNtKCJtY3IgICAgIHAxNSwgMCwgJTAsIGMx
MywgYzAsIDEiIDogOiAiciIgKGlkKSA6ICJjYyIpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBnZXRfY29udGV4dGlkcih2b2lkKQ0KK3sNCisJdW5zaWduZWQgaW50IHZhbDsN
CisJDQorCWFzbSgibXJjIHAxNSwgMCwgJTAsIGMxMywgYzAsIDEiIDogIj1yIiAodmFsKSA6IDog
ImNjIik7DQorDQorCXJldHVybiB2YWw7DQorfQ0KKw0KKyNlbmRpZg0KICNlbmRpZg0KIA0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch03.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch03.diff"


YXJtOiBpbXBsZW1lbnQgc3RhcnR1cCBjb2RlLgoKIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUgfCAgICAxICsKIHhlbi9hcmNoL2FybS94ZW4vc3RhcnQuUyAgfCAgMjczICsrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL21t
dS5oIHwgIDE5OCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGpt
Nzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciBlNmFjOGI2ODZhYTYgeGVuL2FyY2gvYXJt
L3hlbi9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCUZyaSBGZWIg
MDMgMTY6MDc6MzMgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxl
CUZyaSBGZWIgMDMgMTY6MjY6MzQgMjAxMiArMDkwMApAQCAtMSwzICsxLDQgQEAKK29iai15
ICs9IHN0YXJ0Lm8KIG9iai15ICs9IHNldHVwLm8KIG9iai15ICs9IG1tLm8KIG9iai15ICs9
IGlycS5vCmRpZmYgLXIgZTZhYzhiNjg2YWE2IHhlbi9hcmNoL2FybS94ZW4vc3RhcnQuUwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3N0YXJ0LlMJRnJpIEZlYiAwMyAxNjoyNjozNCAyMDEyICswOTAwCkBA
IC0wLDAgKzEsMjczIEBACisvKgorICogc3RhcnQuUyAKKyAqCisgKiBDb3B5cmlnaHQgKEMp
IDIwMDgtMjAxMSBTYW1zdW5nIEVsZWN0cm9uaWNzIAorICogICAgICAgICAgU2FuZy1idW0g
U3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEphZW1pbiBSeXUgICA8
am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogU2VjdXJlIFhlbiBvbiBBUk0gYXJjaGl0
ZWN0dXJlIGRlc2lnbmVkIGJ5IFNhbmctYnVtIFN1aCBjb25zaXN0cyBvZgorICogWGVuIG9u
IEFSTSBhbmQgdGhlIGFzc29jaWF0ZWQgYWNjZXNzIGNvbnRyb2wuCisgKiAKKyAqIFRoaXMg
cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQv
b3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1
dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9V
VCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgor
ICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF
LiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0
YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBH
TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07
IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIElu
Yy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3
ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9j
cHUtZG9tYWluLmg+CisjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgorI2luY2x1ZGUgPGFz
bS9wYWdlLmg+CisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgorI2luY2x1ZGUgPGFzbS9tbXUu
aD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisvKgorICogSW5pdGlhbCBzdGFj
ayBmb3IgY29yZSAwCisgKi8KKyNkZWZpbmUgU1ZDX1NUQUNLX1NJWkUJU1RBQ0tfU0laRQor
CisubWFjcm8gcGEgcmQsIHJzCisxOgorCWFkcglccnMsIDFiCisJbHNyCVxycywgXHJzLCAj
MjAKKwlzdWIJXHJkLCBccmQsICNYRU5fVklSVF9TVEFSVAorCWFkZAlccmQsIFxyZCwgXHJz
LCBsc2wgIzIwCisuZW5kbQorCQorCS5zZWN0aW9uIC5oZWFkCitFTlRSWShzdGFydCkKKwlt
c3IgICAgIGNwc3JfYywgIyhQU1JfRl9CSVQgfCBQU1JfSV9CSVQgfCBQU1JfTU9ERV9TVkMp
CisKKyNpZmRlZiBTTVAKKwltcmMJQUNUTFIocjIpCisJb3JyCXIyLCByMiwgIyhBQ1RMUl9T
TVApIHwgKEFDVExSX0ZXKQorCW1jcglBQ1RMUihyMikKKyNlbmRpZgorCQorCWFkcglyMCwg
c3RhcnQKKwltb3YJcjEsIHIwCisJc3ViCXIwLCByMCwgIzB4NDAwMAkKKwltb3YJcjIsICMw
CisxOglzdHIJcjIsIFtyMSwgIy00XSEKKwlzdHIJcjIsIFtyMSwgIy00XSEKKwlzdHIJcjIs
IFtyMSwgIy00XSEKKwlzdHIJcjIsIFtyMSwgIy00XSEKKwljbXAJcjAsIHIxCisJYm5lCTFi
CisKKwlsZHIgICAgIHIyLCA9KFhFTl9WSVJUX1NUQVJUID4+IDIwKQorCWxkciAgICAgcjcs
ID0oTDFFX1RZUEVfSFlQRVJWSVNPUikKKworCUAgU3RhcnQgc2VjdGlvbiBuby4KKwltb3Yg
ICAgIHIzLCBwYworCWxzciAgICAgcjMsIHIzLCAjMjAKKworCUAgSW5pdGlhbCBWTU0gbWFw
cGluZworCW9yciAgICAgcjQsIHI3LCByMywgbHNsICMyMAorCXN0ciAgICAgcjQsIFtyMCwg
cjIsIGxzbCAjMl0KKwlAYWRkCXI0LCByNCwgIzB4MTAwMDAwCisJQGFkZAlyMiwgcjIsICMx
CisJQHN0cglyNCwgW3IwLCByMiwgbHNsICMyXQorCisgICAgICAgIGxkciAgICAgcjUsID1f
c21lbXRhYmxlCisJcGEJcjUsIHI2CisJbGRyCXI2LCA9X2VtZW10YWJsZQorCXBhCXI2LCBy
NworCisxOgorCWNtcAlyNSwgcjYKKwliZXEJM2YKKworCUAgcjEgOiBiYXNlCisJQCByMiA6
IHNpemUKKwlAIHIzIDogdHlwZQorCUAgcjQgOiBtbXVfZmxhZ3MKKworICAgICAgICBsZG1p
YSAgIHI1ISwge3IxLCByMiwgcjMsIHI0fQorCWxzcglyMSwgcjEsICMyMAorCW9ycglyNCwg
cjQsIHIxLCBsc2wgIzIwCisKKwlAIFJvdW5kIHVwCisJYWRkCXIyLCByMiwgIzB4RkYwMAor
CWFkZAlyMiwgcjIsICMweDAwRkYKKwlsc3IJcjIsIHIyLCAjMjAKKzI6CisgICAgICAgIHN0
ciAgICAgcjQsIFtyMCwgcjEsIGxzbCAjMl0KKyAgICAgICAgYWRkICAgICByMSwgcjEsICMx
CisgICAgICAgIGFkZCAgICAgcjQsIHI0LCAjMHgxMDAwMDAKKyAgICAgICAgYWRkcyAgICBy
MiwgcjIsICMtMQorICAgICAgICBiaGkgICAgIDJiCisJYgkxYgorMzoKKworCUAgTG9hZCBU
cmFuc2xhdGlvbiBUYWJsZSBCYXNlCisJb3JyCXIwLCByMCwgIyhUVEJfRkxBR1MpCisJbWNy
CVRUQlIwKHIwKQorCW1jcglUVEJSMShyMCkKKworCUAgVFRCQ1IgU2V0dGluZworICAgICAg
ICBtcmMgICAgIHAxNSwgMCwgcjUsIGMxLCBjMCwgMgorICAgICAgICBvcnIgICAgIHI1LHI1
LCAjKCgzIDw8ICgxMCAqIDIpKSB8KDMgPDwgKDExICogMikpKQorICAgICAgICBtY3IgICAg
IHAxNSwgMCwgcjUsIGMxLCBjMCwgMgorCisJQCBMb2FkIERBQworCWxkcglyNSwgPTB4NTU1
NTU1NTUKKwltY3IJREFDUihyNSkKKworCWxkcglyNSwgPTB4RkYwQTg5QTgKKwlsZHIJcjYs
ID0weDQwRTA0MEUwCisJbWNyCXAxNSwgMCwgcjUsIGMxMCwgYzIsIDAKKwltY3IJcDE1LCAw
LCByNiwgYzEwLCBjMiwgMQorCisJQCBUdXJuIG9uIE1NVQorCWxkcglyMCwgPShTQ1RMUl9U
UkUgfCBTQ1RMUl9TVyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJfQyB8IFNDVExSX0Eg
fCBTQ1RMUl9NKQorCW1jcglTQ1RMUihyMCkKKwltb3YJcjAsIHIwCisJbW92CXIwLCByMAor
CW1vdglyMCwgcjAKKworCUAgSW52YWxpZGF0ZSBJL0QgVExCcworCW1vdglpcCwgIzAKKwlt
Y3IJcDE1LCAwLCBpcCwgYzgsIGM3LCAwCisJZHNiCisJaXNiCisKKwlAIENsZWFyIEJTUyBz
ZWN0aW9uCisJYWRyICAgICByMCwgMmYKKwlsZG1pYSAgIHIwLCB7cjEsIHIyfQorCW1vdiAg
ICAgcjAsICMwCisxOgorCXN0ciAgICAgcjAsIFtyMV0sICM0IAorCWNtcCAgICAgcjEsIHIy
CisJYmxvICAgICAxYgorCisgICAgICAgIC8qIFN0YWNrIFNldHVwICovCisJQCBHZXQgcHJv
Y2Vzc29yIElECisgICAgICAgIG1yYyAgICAgTVBJRFIocjQpCisgICAgICAgIGFuZCAgICAg
cjQsIHI0LCAjMTUKKworCUAgcjAgPSByMCAqIFNUQUNLX1NJWkUKKyAgICAgICAgbW92ICAg
ICByMSwgI1NUQUNLX1NJWkUKKyAgICAgICAgbXVsICAgICByNCwgcjQsIHIxCisKKwltc3IJ
Y3Bzcl9jLCAjUFNSX01PREVfSVJRIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRyCXNw
LCA9KGlycV9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwltc3IJ
Y3Bzcl9jLCAjUFNSX01PREVfQUJUIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRyCXNw
LCA9KGFidF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwltc3IJ
Y3Bzcl9jLCAjUFNSX01PREVfVU5EIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRyCXNw
LCA9KHVuZF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwltc3Ig
ICAgIGNwc3JfYywgI1BTUl9NT0RFX1NWQyB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVAorCWxk
ciAgICAgc3AsID0oc3ZjX3N0YWNrcyArIFNUQUNLX1NJWkUpCisJYWRkCXNwLCBzcCwgcjQK
KworCWFkciAgICAgcjEyLCAzZgorCWxkcglwYywgW3IxMl0KKworMjoJLndvcmQgICBfc2Jz
cworCS53b3JkICAgX2Vic3MKKworMzoKKwkubG9uZyAgIHN0YXJ0X3hlbgorCisjaWZkZWYg
U01QCisgICAgICAgIC8qCisgICAgICAgICAqIENvbW1vbiBlbnRyeSBwb2ludCBmb3Igc2Vj
b25kYXJ5IENQVXMuCisgICAgICAgICAqCisgICAgICAgICAqIEVuc3VyZSB0aGF0IHdlJ3Jl
IGluIFNWQyBtb2RlLCBhbmQgSVJRcyBhcmUgZGlzYWJsZWQuCisgICAgICAgICAqLworCS5z
ZWN0aW9uIC5oZWFkCitFTlRSWShzbGF2ZV9jcHVfc3RhcnQpCisJbXNyICAgICBjcHNyX2Ms
ICNQU1JfRl9CSVQgfCBQU1JfSV9CSVQgfCBQU1JfTU9ERV9TVkMKKworICAgICAgICBtcmMg
ICAgIEFDVExSKHIyKQorICAgICAgICBvcnIgICAgIHIyLCByMiwgIyhBQ1RMUl9TTVApIHwg
KEFDVExSX0ZXKQorICAgICAgICBtY3IgICAgIEFDVExSKHIyKQorCisJQCBMb2FkIFRyYW5z
bGF0aW9uIFRhYmxlIEJhc2UKKwlhZHIJcjQsIHN0YXJ0CisJc3ViCXI0LCByNCwgIzB4NDAw
MAorCW9yciAgICAgcjQsIHI0LCAjKFRUQl9GTEFHUykKKwltY3IJVFRCUjAocjQpCisJbWNy
CVRUQlIxKHI0KQorCisJQCBUVEJDUiBTZXR0aW5nCisgICAgICAgIG1yYyAgICAgcDE1LCAw
LCByNSwgYzEsIGMwLCAyCisgICAgICAgIG9yciAgICAgcjUscjUsICMoKDMgPDwgKDEwICog
MikpIHwoMyA8PCAoMTEgKiAyKSkpCisgICAgICAgIG1jciAgICAgcDE1LCAwLCByNSwgYzEs
IGMwLCAyCisKKwlAIExvYWQgREFDCisJbGRyICAgICByNSwgPTB4NTU1NTU1NTUKKwltY3Ig
ICAgIERBQ1IocjUpCisJCisJbGRyCXI1LCA9MHhGRjBBODlBOAorCWxkcglyNiwgPTB4NDBF
MDQwRTAKKwltY3IJcDE1LCAwLCByNSwgYzEwLCBjMiwgMAorCW1jcglwMTUsIDAsIHI2LCBj
MTAsIGMyLCAxCisKKwlAIFR1cm4gb24gTU1VCisJbGRyCXIwLCA9KFNDVExSX1RSRSB8IFND
VExSX1NXIHwgU0NUTFJfWiB8IFNDVExSX0kgfCBTQ1RMUl9DIHwgU0NUTFJfQSB8IFNDVExS
X00pCisJbWNyCVNDVExSKHIwKQorCW1vdiAgICAgcjAsIHIwCisJbW92ICAgICByMCwgcjAK
Kwltb3YgICAgIHIwLCByMAorCisgICAgICAgIEAgSW52YWxpZGF0ZSBJLCBEIFRMQnMKKwlt
b3YJaXAsICMwCisJbWNyICAgICBwMTUsIDAsIGlwLCBjOCwgYzcsIDAKKwlkc2IKKwlpc2IK
KworCS8qIFN0YWNrIFNldHVwICovCisgICAgICAgIEAgZ2V0IHByb2Nlc3NvciBpZAorCW1y
YyAgICAgTVBJRFIocjQpCisJYW5kCXI0LCByNCwgIzE1CisJCQorCUAgcjAgPSByMCAqIFNU
QUNLX1NJWkUKKwltb3YJcjEsICNTVEFDS19TSVpFCisJbXVsCXI0LCByNCwgcjEKKwkKKwlt
c3IJY3Bzcl9jLCAjUFNSX01PREVfSVJRIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRy
CXNwLCA9KGlycV9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwlt
c3IJY3Bzcl9jLCAjUFNSX01PREVfQUJUIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRy
CXNwLCA9KGFidF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwlt
c3IJY3Bzcl9jLCAjUFNSX01PREVfVU5EIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRy
CXNwLCA9KHVuZF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwlt
c3IgICAgIGNwc3JfYywgI1BTUl9NT0RFX1NWQyB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVAor
CWxkciAgICAgc3AsID0oc3ZjX3N0YWNrcyArIFNUQUNLX1NJWkUpCisJYWRkCXNwLCBzcCwg
cjQKKworCWFkciAgICAgcjEyLCAyZgorCWxkbWlhICAgcjEyLCB7bHIsIHBjfQorCisyOgor
CS5sb25nICAgMmIKKwkubG9uZwlzdGFydF94ZW5fb25fc2xhdmVfY3B1CisjZW5kaWYKKwor
CS5zZWN0aW9uIC5ic3Muc3RhY2tfYWxpZ25lZCwidyIKK3N2Y19zdGFja3M6IC5maWxsIFNW
Q19TVEFDS19TSVpFLCBNQVhfUEhZU19DUFVTLCAwCitpcnFfc3RhY2tzOiAuZmlsbCBTVkNf
U1RBQ0tfU0laRSwgTUFYX1BIWVNfQ1BVUywgMAordW5kX3N0YWNrczogLmZpbGwgU1ZDX1NU
QUNLX1NJWkUsIE1BWF9QSFlTX0NQVVMsIDAKK2FidF9zdGFja3M6IC5maWxsIFNWQ19TVEFD
S19TSVpFLCBNQVhfUEhZU19DUFVTLCAwCitmaXFfc3RhY2tzOiAuZmlsbCBTVkNfU1RBQ0tf
U0laRSwgTUFYX1BIWVNfQ1BVUywgMApkaWZmIC1yIGU2YWM4YjY4NmFhNiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL21tdS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW11LmgJRnJpIEZl
YiAwMyAxNjowNzozMyAyMDEyICswOTAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW11
LmgJRnJpIEZlYiAwMyAxNjoyNjozNCAyMDEyICswOTAwCkBAIC0xLDExICsxLDIwOSBAQAog
I2lmbmRlZiBfX0FSTV9NTVVfSF9fCiAjZGVmaW5lIF9fQVJNX01NVV9IX18KIAorI2luY2x1
ZGUgPGFzbS9zeXN0ZW0uaD4KKyNpbmNsdWRlIDxhc20vY3B1LWRvbWFpbi5oPgorCisjZGVm
aW5lIEwxRV9GTEFHX01BU0sgICAgICAgICAgICgweDNGRikKKworI2RlZmluZSBMMUVfVFlQ
RV9GQVVMVCAgICAgICAgICAoMHgwMCkKKyNkZWZpbmUgTDFFX1RZUEVfVEFCTEUgICAgICAg
ICAgKDB4MDEpCisjZGVmaW5lIEwxRV9UWVBFX1NFQ1RJT04gICAgICAgICgweDAyKQorI2Rl
ZmluZSBMMUVfVFlQRV9NQVNLICAgICAgICAgICAoMHgwMykKKworI2RlZmluZSBMMUVfQklU
NAkJKDEgPDwgNCkKKworI2RlZmluZSBMMUVfQVBfU1JXX1VOTyAgICAgICAgICAoMHgwMSA8
PCAxMCkKKyNkZWZpbmUgTDFFX0FQX1NSV19VUk8gICAgICAgICAgKDB4MDIgPDwgMTApCisj
ZGVmaW5lIEwxRV9BUF9TUldfVVJXICAgICAgICAgICgweDAzIDw8IDEwKQorCisjZGVmaW5l
IEwxRV9CVUZGRVJBQkxFICAgICAgICAgICgweDA0KQorI2RlZmluZSBMMUVfQ0FDSEVBQkxF
ICAgICAgICAgICAoMHgwOCkKKworI2RlZmluZSBMMUVfVEVYKHgpICAgICAgICAgICAgICAo
KHgpIDw8MTIpCisjZGVmaW5lIEwxRV9BUFggICAgICAgICAgICAgICAgICgxIDw8IDE1KQor
I2RlZmluZSBMMUVfUyAgICAgICAgICAgICAgICAgICAoMSA8PCAxNikKKyNkZWZpbmUgTDFF
X25HICAgICAgICAgICAgICAgICAgKDEgPDwgMTcpCisKKyNkZWZpbmUgTDFFX1NUUk9OR09S
REVSRUQgICAgICAgKDApCisjZGVmaW5lIEwxRV9ERVZJQ0UgICAgICAgICAgICAgIChMMUVf
VEVYKDEpKQorI2RlZmluZSBMMUVfV1JJVEVCQUNLICAgICAgICAgICAoTDFFX0NBQ0hFQUJM
RSB8IEwxRV9CVUZGRVJBQkxFKQorI2RlZmluZSBMMUVfV1JJVEVUSFJPVUdIICAgICAgICAo
TDFFX0NBQ0hFQUJMRSkKKyNkZWZpbmUgTDFFX1dSSVRFQUxMT0MgICAgICAgICAgKEwxRV9U
RVgoMSkgfCBMMUVfQ0FDSEVBQkxFIHwgTDFFX0JVRkZFUkFCTEUpCisjZGVmaW5lIEwxRV9T
SEFSRUQgICAgICAgICAgICAgICgwKQorCisjZGVmaW5lIEwxRV9ET01BSU5fSFlQCQkoRE9N
QUlOX0hZUCA8PCA1KQorI2RlZmluZSBMMUVfRE9NQUlOX1NWQwkJKERPTUFJTl9TVkMgPDwg
NSkKKyNkZWZpbmUgTDFFX0RPTUFJTl9VU1IJCShET01BSU5fVVNSIDw8IDUpCisjZGVmaW5l
IEwxRV9ET01BSU5fSU8gICAgICAgICAgIChET01BSU5fSU8gPDwgNSkKKworI2RlZmluZSBM
MUVfV0JXQSAgICAgICAgICAgICAgICAoTDFFX1RFWCgxKSB8IEwxRV9XUklURUJBQ0spCisK
KyNkZWZpbmUgU0VDVElPTl9TSElGVCAgICAgICAgICAgKDIwKQorI2RlZmluZSBTRUNUSU9O
X1NJWkUgICAgICAgICAgICAoMSA8PCBTRUNUSU9OX1NISUZUKQorI2RlZmluZSBTRUNUSU9O
X01BU0sgICAgICAgICAgICAofihTRUNUSU9OX1NJWkUgLSAxKSkKKworI2RlZmluZSBMMUVf
VFlQRV9IWVBFUlZJU09SICAgICAoTDFFX1RZUEVfU0VDVElPTiB8IEwxRV9ET01BSU5fSFlQ
IHwgTDFFX1MgfCBMMUVfQVBfU1JXX1VOTyB8IEwxRV9XUklURUFMTE9DKQorI2RlZmluZSBM
MUVfVFlQRV9HVUVTVAkJKEwxRV9UWVBFX1NFQ1RJT04gfCBMMUVfRE9NQUlOX1NWQyB8IEwx
RV9TIHwgTDFFX0FQX1NSV19VUlcgfCBMMUVfV1JJVEVBTExPQykKKyNkZWZpbmUgTDFFX1RZ
UEVfREVWSUNFCQkoTDFFX1RZUEVfU0VDVElPTiB8IEwxRV9ET01BSU5fSU8gIHwgTDFFX1Mg
fCBMMUVfQVBfU1JXX1VSVyB8IEwxRV9ERVZJQ0UpCisKKy8qCisgKiBEZWZpbml0aW9uIGZv
ciBQYWdlIFRhYmxlIEVudHJpZXMKKyAqLworCisjZGVmaW5lIEwyRV9GTEFHX01BU0sgICAg
ICAgICAgICgweEZGRikKKworI2RlZmluZSBMMkVfVFlQRV9GQVVMVCAgICAgICAgICAoMHgw
MCkKKyNkZWZpbmUgTDJFX1RZUEVfTEFSR0UgICAgICAgICAgKDB4MDEpCisjZGVmaW5lIEwy
RV9UWVBFX1NNQUxMICAgICAgICAgICgweDAyKQorI2RlZmluZSBMMkVfVFlQRV9USU5ZICAg
ICAgICAgICAoMHgwMykKKyNkZWZpbmUgTDJFX1RZUEVfRVhUICAgICAgICAgICAgKDB4MDIp
CisKKyNkZWZpbmUgTDJFX1RZUEVfTUFTSyAgICAgICAgICAgKDB4MDMpCisKKyNkZWZpbmUg
TDJFX0JVRkZFUkFCTEUgICAgICAgICAgKDB4MDQpCisjZGVmaW5lIEwyRV9DQUNIRUFCTEUg
ICAgICAgICAgICgweDA4KQorCisjZGVmaW5lIEwxRV9TSElGVCAgICAgICAgICAgICAgICgy
MCkKKyNkZWZpbmUgTDJFX1NISUZUCQkoMTIpCisKKyNkZWZpbmUgTDJFX0VYVF9YTiAgICAg
ICAgICAgICAgKDEgPDwgMCkKKyNkZWZpbmUgTDJFX0VYVF9BUF9NQVNLICAgICAgICAgKDMg
PDwgNCkKKyNkZWZpbmUgTDJFX0VYVF9BUDAgICAgICAgICAgICAgKDEgPDwgNCkKKyNkZWZp
bmUgTDJFX0VYVF9BUDEgICAgICAgICAgICAgKDIgPDwgNCkKKyNkZWZpbmUgTDJFX0VYVF9B
UF9VTk9fU1JPICAgICAgKDAgPDwgNCkKKyNkZWZpbmUgTDJFX0VYVF9BUF9VTk9fU1JXICAg
ICAgKEwyRV9FWFRfQVAwKQorI2RlZmluZSBMMkVfRVhUX0FQX1VST19TUlcgICAgICAoTDJF
X0VYVF9BUDEpCisjZGVmaW5lIEwyRV9FWFRfQVBfVVJXX1NSVyAgICAgIChMMkVfRVhUX0FQ
MXxMMkVfRVhUX0FQMCkKKyNkZWZpbmUgTDJFX0VYVF9URVgoeCkgICAgICAgICAgKCh4KSA8
PCA2KQorI2RlZmluZSBMMkVfRVhUX0FQWCAgICAgICAgICAgICAoMSA8PCA5KQorI2RlZmlu
ZSBMMkVfRVhUX0NPSEVSRU5UICAgICAgICAoMSA8PCA5KQorI2RlZmluZSBMMkVfRVhUX1NI
QVJFRCAgICAgICAgICAoMSA8PCAxMCkKKyNkZWZpbmUgTDJFX0VYVF9ORyAgICAgICAgICAg
ICAgKDEgPDwgMTEpCisKKworI2RlZmluZSBMMV9UQUJMRV9FTlRSSUVTCSg0MDk2KQorI2Rl
ZmluZSBMMl9UQUJMRV9FTlRSSUVTCSgyNTYpCisKKyNkZWZpbmUgTDFfVEFCTEVfU0laRQkJ
KDB4NDAwMCkKKworI2RlZmluZSBMMkVfR1VFU1RfQVBfTUFTSyAgICAgICBMMkVfRVhUX0FQ
X01BU0sKKyNkZWZpbmUgTDJFX0dVRVNUX0FQX05PICAgICAgICAgTDJFX0VYVF9BUF9VTk9f
U1JXCisjZGVmaW5lIEwyRV9HVUVTVF9BUF9STyAgICAgICAgIEwyRV9FWFRfQVBfVVJPX1NS
VworI2RlZmluZSBMMkVfR1VFU1RfQVBfUlcgICAgICAgICBMMkVfRVhUX0FQX1VSV19TUlcK
KworI2RlZmluZSBMMUVfR1VFU1RfVEFCTEUgICAgICAgICAoTDFFX0RPTUFJTl9TVkMgfCBM
MUVfVFlQRV9UQUJMRSkKKyNkZWZpbmUgTDFFX1ZFQ1RPUl9UQUJMRSAgICAgICAgKEwxRV9E
T01BSU5fU1ZDIHwgTDFFX1RZUEVfVEFCTEUpCisKKyNkZWZpbmUgTDJFX0dVRVNUX1BBR0Ug
ICAgICAgICAgKEwyRV9FWFRfU0hBUkVEIHwgTDJFX0dVRVNUX0FQX1JXIHwgTDJFX0VYVF9U
RVgoMSkgfCBMMkVfQlVGRkVSQUJMRSB8IEwyRV9DQUNIRUFCTEUgfCBMMkVfVFlQRV9FWFQp
CisKKyNkZWZpbmUgTDJFX1ZFQ1RPUl9QQUdFICAgICAgICAgKEwyRV9HVUVTVF9BUF9STyB8
IEwyRV9FWFRfVEVYKDEpIHwgTDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJF
X1RZUEVfRVhUKQorI2RlZmluZSBMMkVfR1JBTlRfUEFHRQkJKEwyRV9UWVBFX0VYVCB8IEwy
RV9FWFRfU0hBUkVEIHwgTDJFX0VYVF9URVgoMSkgfCBMMkVfQlVGRkVSQUJMRSB8IEwyRV9D
QUNIRUFCTEUgfCBMMkVfR1VFU1RfQVBfUlcpCisjZGVmaW5lIEwyRV9TSEFSRURfSU5GTwkJ
KEwyRV9UWVBFX0VYVCB8IEwyRV9FWFRfVEVYKDEpIHwgTDJFX0VYVF9YTiB8IEwyRV9FWFRf
U0hBUkVEIHwgTDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX0dVRVNUX0FQ
X1JXKQorI2RlZmluZSBMMkVfREVWSUNFCQkoTDJFX1RZUEVfRVhUIHwgTDJFX0VYVF9URVgo
MSkgfCBMMkVfRVhUX1hOIHwgTDJFX0VYVF9TSEFSRUQgfCBMMkVfR1VFU1RfQVBfUlcpCisK
ICNkZWZpbmUgUEFERFJfQklUUyAgICAgICAgICAgICAgMzIKICNkZWZpbmUgUEFERFJfTUFT
SyAgICAgICAgICAgICAgKCgxVUwgPDwgUEFERFJfQklUUykgLSAxKQogCiAjZGVmaW5lIFZB
RERSX0JJVFMgICAgICAgICAgICAgIDMyCiAjZGVmaW5lIFZBRERSX01BU0sgICAgICAgICAg
ICAgICgoMVVMIDw8IFZBRERSX0JJVFMpIC0gMSkKIAorI2RlZmluZSBUVEJfUyAgICAgICAg
ICAgKDEgPDwgMSkKKyNkZWZpbmUgVFRCX1JHTl9OQyAgICAgICgwIDw8IDMpCisjZGVmaW5l
IFRUQl9SR05fT0NfV0JXQSAoMSA8PCAzKQorI2RlZmluZSBUVEJfUkdOX09DX1dUICAgKDIg
PDwgMykKKyNkZWZpbmUgVFRCX1JHTl9PQ19XQiAgICgzIDw8IDMpCisjZGVmaW5lIFRUQl9O
T1MgICAgICAgICAoMSA8PCA1KQorI2RlZmluZSBUVEJfSVJHTl9OQyAgICAgKCgwIDw8IDAp
IHwgKDAgPDwgNikpCisjZGVmaW5lIFRUQl9JUkdOX1dCV0EgICAoKDAgPDwgMCkgfCAoMSA8
PCA2KSkKKyNkZWZpbmUgVFRCX0lSR05fV1QgICAgICgoMSA8PCAwKSB8ICgwIDw8IDYpKQor
I2RlZmluZSBUVEJfSVJHTl9XQiAgICAgKCgxIDw8IDApIHwgKDEgPDwgNikpCisKKworI2Rl
ZmluZSBUVEJfRkxBR1MgICAgICAgICAgICAgICAoVFRCX0lSR05fV0JXQSB8IFRUQl9TIHwg
VFRCX05PUyB8IFRUQl9SR05fT0NfV0JXQSkKKworI2RlZmluZSBUVEJfTUFTSwkJKH4weDNG
RkYpCisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCisKKyNpbmNsdWRlIDxhc20vdHlwZXMuaD4K
KworI2RlZmluZSBsMmVfdmFsKHgpICAgICAgICAgICAgICAoKHgpLmwyZSkKKyNkZWZpbmUg
bDFlX3ZhbCh4KSAgICAgICAgICAgICAgKCh4KS5sMWUpCisKKyNkZWZpbmUgTUtfTDJFKHgs
IGZsYWdzKQkoKGwyZV90KSB7ICgodW5zaWduZWQgbG9uZykoeCkgJiAofkwyRV9GTEFHX01B
U0spKSB8IGZsYWdzIH0gKQorI2RlZmluZSBNS19MMUUoeCwgZmxhZ3MpCSgobDFlX3QpIHsg
KCh1bnNpZ25lZCBsb25nKSh4KSAmICh+TDFFX0ZMQUdfTUFTSykpIHwgZmxhZ3MgfSApCisK
KyNkZWZpbmUgbDF0X2luZGV4KHgpCQkoKCh1bnNpZ25lZCBsb25nKSh4KSA+PiBMMUVfU0hJ
RlQpICYgKEwxX1RBQkxFX0VOVFJJRVMgLSAxKSkKKyNkZWZpbmUgbDJ0X2luZGV4KHgpCQko
KCh1bnNpZ25lZCBsb25nKSh4KSA+PiBMMkVfU0hJRlQpICYgKEwyX1RBQkxFX0VOVFJJRVMg
LSAxKSkKKworI2RlZmluZSBsMV9saW5lYXJfb2Zmc2V0X3hlbih2YSkJXAorCShsMV9saW5l
YXJfb2Zmc2V0KCh4ZW5fdHJhbnNsYXRpb25fdGFibGUpLCB2YSkpCisKK3R5cGVkZWYgc3Ry
dWN0IHsgdW5zaWduZWQgbG9uZyBsMmU7IH0gbDJlX3Q7Cit0eXBlZGVmIHN0cnVjdCB7IHVu
c2lnbmVkIGxvbmcgbDFlOyB9IGwxZV90OworCitzdGF0aWMgaW5saW5lIGwxZV90ICpsMV9s
aW5lYXJfb2Zmc2V0KGwxZV90ICpsMWUsIHVuc2lnbmVkIGxvbmcgdmlydCkKK3sKKwlyZXR1
cm4gbDFlICsgbDF0X2luZGV4KHZpcnQpOworfQorCitzdGF0aWMgaW5saW5lIGwyZV90ICps
Ml9saW5lYXJfb2Zmc2V0KGwxZV90ICpsMWUsIHVuc2lnbmVkIGxvbmcgdmlydCkKK3sKKyAg
ICAgICAgbDJlX3QgKmwyZTsKKworICAgICAgICBsMmUgPSAobDJlX3QgKikgKGwxZV92YWwo
KmwxZSkgJiB+TDFFX0ZMQUdfTUFTSyk7CisgICAgICAgIGwyZSA9IGwyZSArIGwydF9pbmRl
eCh2aXJ0KTsKKworICAgICAgICByZXR1cm4gbDJlOworfQorCitzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBnZXRfZGFjcih2b2lkKQoreworCXVuc2lnbmVkIGludCB2YWw7CisKKwlh
c20oIm1yYyBwMTUsIDAsICUwLCBjMywgYzAsIDAiIDogIj1yIiAodmFsKSA6IDogImNjIik7
CisKKwlyZXR1cm4gdmFsOworfQorCisKK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfZGFjcih1
bnNpZ25lZCBsb25nIHZhbCkKK3sKKwlhc20oIm1yYyBwMTUsIDAsICUwLCBjMywgYzAsIDAi
IDogIj1yIiAodmFsKSA6IDogImNjIik7Cit9CisKKworc3RhdGljIGlubGluZSB1bnNpZ25l
ZCBpbnQgZ2V0X3R0YnIodm9pZCkKK3sKKwl1bnNpZ25lZCBpbnQgdmFsOworCQorCWFzbSgi
bXJjIHAxNSwgMCwgJTAsIGMyLCBjMCwgMCIgOiAiPXIiICh2YWwpIDogOiAiY2MiKTsKKwor
CXJldHVybiB2YWw7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfdHRicih1bnNpZ25l
ZCBpbnQgdHRiKQoreworCWFzbSB2b2xhdGlsZSgibWNyIHAxNSwgMCwgJTAsIGMyLCBjMCwg
MCIgOiA6ICJyIiAodHRiKSA6ICJjYyIpOworCisJaXNiKCk7Cit9CisKK3N0YXRpYyBpbmxp
bmUgdm9pZCBzZXRfY29udGV4dGlkcih1bnNpZ25lZCBsb25nIGlkKQoreworCWFzbSgibWNy
ICAgICBwMTUsIDAsICUwLCBjMTMsIGMwLCAxIiA6IDogInIiIChpZCkgOiAiY2MiKTsKK30K
Kworc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQgZ2V0X2NvbnRleHRpZHIodm9pZCkKK3sK
Kwl1bnNpZ25lZCBpbnQgdmFsOworCQorCWFzbSgibXJjIHAxNSwgMCwgJTAsIGMxMywgYzAs
IDEiIDogIj1yIiAodmFsKSA6IDogImNjIik7CisKKwlyZXR1cm4gdmFsOworfQorCisjZW5k
aWYKICNlbmRpZgogCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt15-0005wD-3h; Mon, 13 Feb 2012 10:20:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwql3-0003Ca-QK
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:55:34 +0000
Received: from [85.158.139.83:28573] by server-10.bemta-5.messagelabs.com id
	83/3E-26909-5F1C83F4; Mon, 13 Feb 2012 07:55:33 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329119729!14157873!2
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13101 invoked from network); 13 Feb 2012 07:55:31 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-9.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 07:55:31 -0000
Received: from epcpsbge6.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB005YUNBBEV50@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:55:29 +0900 (KST)
Message-id: <0LZB0050CNCHEV60@mailout1.samsung.com>
X-AuditID: cbfee610-b7b53ae000003b1c-9f-4f38c1f108de
Received: from epextmailer01 ( [203.254.219.151])
	by epcpsbge6.samsung.com (EPCPMTA) with SMTP id 79.04.15132.1F1C83F4;
	Mon, 13 Feb 2012 16:55:29 +0900 (KST)
Date: Mon, 13 Feb 2012 07:55:29 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: =?euc-kr?Q?=B7=F9=C0=E7=B9=CE?= <jm77.ryu@samsung.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213075324312@jm77.ryu
Msgkey: 20120213075324312@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213074940046@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 03/14]  arm: implement startup code.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <33545724.69781329119725940.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgc3RhcnR1cCBjb2RlLg0KDQogeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmls
ZSB8ICAgIDEgKw0KIHhlbi9hcmNoL2FybS94ZW4vc3RhcnQuUyAgfCAgMjczICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2luY2x1ZGUvYXNtLWFybS9tbXUuaCB8ICAx
OTggKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrDQoNClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1
bmcuY29tPg0KDQpkaWZmIC1yIGU2YWM4YjY4NmFhNiB4ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxl
DQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCUZyaSBGZWIgMDMgMTY6MDc6MzMgMjAx
MiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQlGcmkgRmViIDAzIDE2OjI2
OjM0IDIwMTIgKzA5MDANCkBAIC0xLDMgKzEsNCBAQA0KK29iai15ICs9IHN0YXJ0Lm8NCiBvYmot
eSArPSBzZXR1cC5vDQogb2JqLXkgKz0gbW0ubw0KIG9iai15ICs9IGlycS5vDQpkaWZmIC1yIGU2
YWM4YjY4NmFhNiB4ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMNCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVuL3N0YXJ0LlMJ
RnJpIEZlYiAwMyAxNjoyNjozNCAyMDEyICswOTAwDQpAQCAtMCwwICsxLDI3MyBAQA0KKy8qDQor
ICogc3RhcnQuUyANCisgKg0KKyAqIENvcHlyaWdodCAoQykgMjAwOC0yMDExIFNhbXN1bmcgRWxl
Y3Ryb25pY3MgDQorICogICAgICAgICAgU2FuZy1idW0gU3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNv
bT4NCisgKiAgICAgICAgICBKYWVtaW4gUnl1ICAgPGptNzcucnl1QHNhbXN1bmcuY29tPg0KKyAq
DQorICogU2VjdXJlIFhlbiBvbiBBUk0gYXJjaGl0ZWN0dXJlIGRlc2lnbmVkIGJ5IFNhbmctYnVt
IFN1aCBjb25zaXN0cyBvZg0KKyAqIFhlbiBvbiBBUk0gYW5kIHRoZSBhc3NvY2lhdGVkIGFjY2Vz
cyBjb250cm9sLg0KKyAqIA0KKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug
Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQorICogaXQgdW5kZXIgdGhlIHRlcm1z
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgdmVyc2lvbiAyIG9mIExpY2Vuc2UgYXMNCisgKiBw
dWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCisgKg0KKyAqIFRoaXMg
cHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVs
LA0KKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVk
IHdhcnJhbnR5IG9mDQorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv
ciBtb3JlIGRldGFpbHMuDQorICoNCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5
IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKyAqIGFsb25nIHdpdGggdGhpcyBw
cm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlDQorICogRm91bmRhdGlv
biwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEz
MDcgIFVTQQ0KKyAqLw0KKw0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+DQorI2luY2x1ZGUgPGFz
bS9jcHUtZG9tYWluLmg+DQorI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4NCisjaW5jbHVkZSA8
YXNtL3BhZ2UuaD4NCisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPg0KKyNpbmNsdWRlIDxhc20vbW11
Lmg+DQorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+DQorDQorLyoNCisgKiBJbml0aWFsIHN0
YWNrIGZvciBjb3JlIDANCisgKi8NCisjZGVmaW5lIFNWQ19TVEFDS19TSVpFCVNUQUNLX1NJWkUN
CisNCisubWFjcm8gcGEgcmQsIHJzDQorMToNCisJYWRyCVxycywgMWINCisJbHNyCVxycywgXHJz
LCAjMjANCisJc3ViCVxyZCwgXHJkLCAjWEVOX1ZJUlRfU1RBUlQNCisJYWRkCVxyZCwgXHJkLCBc
cnMsIGxzbCAjMjANCisuZW5kbQ0KKwkNCisJLnNlY3Rpb24gLmhlYWQNCitFTlRSWShzdGFydCkN
CisJbXNyICAgICBjcHNyX2MsICMoUFNSX0ZfQklUIHwgUFNSX0lfQklUIHwgUFNSX01PREVfU1ZD
KQ0KKw0KKyNpZmRlZiBTTVANCisJbXJjCUFDVExSKHIyKQ0KKwlvcnIJcjIsIHIyLCAjKEFDVExS
X1NNUCkgfCAoQUNUTFJfRlcpDQorCW1jcglBQ1RMUihyMikNCisjZW5kaWYNCisJDQorCWFkcgly
MCwgc3RhcnQNCisJbW92CXIxLCByMA0KKwlzdWIJcjAsIHIwLCAjMHg0MDAwCQ0KKwltb3YJcjIs
ICMwDQorMToJc3RyCXIyLCBbcjEsICMtNF0hDQorCXN0cglyMiwgW3IxLCAjLTRdIQ0KKwlzdHIJ
cjIsIFtyMSwgIy00XSENCisJc3RyCXIyLCBbcjEsICMtNF0hDQorCWNtcAlyMCwgcjENCisJYm5l
CTFiDQorDQorCWxkciAgICAgcjIsID0oWEVOX1ZJUlRfU1RBUlQgPj4gMjApDQorCWxkciAgICAg
cjcsID0oTDFFX1RZUEVfSFlQRVJWSVNPUikNCisNCisJQCBTdGFydCBzZWN0aW9uIG5vLg0KKwlt
b3YgICAgIHIzLCBwYw0KKwlsc3IgICAgIHIzLCByMywgIzIwDQorDQorCUAgSW5pdGlhbCBWTU0g
bWFwcGluZw0KKwlvcnIgICAgIHI0LCByNywgcjMsIGxzbCAjMjANCisJc3RyICAgICByNCwgW3Iw
LCByMiwgbHNsICMyXQ0KKwlAYWRkCXI0LCByNCwgIzB4MTAwMDAwDQorCUBhZGQJcjIsIHIyLCAj
MQ0KKwlAc3RyCXI0LCBbcjAsIHIyLCBsc2wgIzJdDQorDQorICAgICAgICBsZHIgICAgIHI1LCA9
X3NtZW10YWJsZQ0KKwlwYQlyNSwgcjYNCisJbGRyCXI2LCA9X2VtZW10YWJsZQ0KKwlwYQlyNiwg
cjcNCisNCisxOg0KKwljbXAJcjUsIHI2DQorCWJlcQkzZg0KKw0KKwlAIHIxIDogYmFzZQ0KKwlA
IHIyIDogc2l6ZQ0KKwlAIHIzIDogdHlwZQ0KKwlAIHI0IDogbW11X2ZsYWdzDQorDQorICAgICAg
ICBsZG1pYSAgIHI1ISwge3IxLCByMiwgcjMsIHI0fQ0KKwlsc3IJcjEsIHIxLCAjMjANCisJb3Jy
CXI0LCByNCwgcjEsIGxzbCAjMjANCisNCisJQCBSb3VuZCB1cA0KKwlhZGQJcjIsIHIyLCAjMHhG
RjAwDQorCWFkZAlyMiwgcjIsICMweDAwRkYNCisJbHNyCXIyLCByMiwgIzIwDQorMjoNCisgICAg
ICAgIHN0ciAgICAgcjQsIFtyMCwgcjEsIGxzbCAjMl0NCisgICAgICAgIGFkZCAgICAgcjEsIHIx
LCAjMQ0KKyAgICAgICAgYWRkICAgICByNCwgcjQsICMweDEwMDAwMA0KKyAgICAgICAgYWRkcyAg
ICByMiwgcjIsICMtMQ0KKyAgICAgICAgYmhpICAgICAyYg0KKwliCTFiDQorMzoNCisNCisJQCBM
b2FkIFRyYW5zbGF0aW9uIFRhYmxlIEJhc2UNCisJb3JyCXIwLCByMCwgIyhUVEJfRkxBR1MpDQor
CW1jcglUVEJSMChyMCkNCisJbWNyCVRUQlIxKHIwKQ0KKw0KKwlAIFRUQkNSIFNldHRpbmcNCisg
ICAgICAgIG1yYyAgICAgcDE1LCAwLCByNSwgYzEsIGMwLCAyDQorICAgICAgICBvcnIgICAgIHI1
LHI1LCAjKCgzIDw8ICgxMCAqIDIpKSB8KDMgPDwgKDExICogMikpKQ0KKyAgICAgICAgbWNyICAg
ICBwMTUsIDAsIHI1LCBjMSwgYzAsIDINCisNCisJQCBMb2FkIERBQw0KKwlsZHIJcjUsID0weDU1
NTU1NTU1DQorCW1jcglEQUNSKHI1KQ0KKw0KKwlsZHIJcjUsID0weEZGMEE4OUE4DQorCWxkcgly
NiwgPTB4NDBFMDQwRTANCisJbWNyCXAxNSwgMCwgcjUsIGMxMCwgYzIsIDANCisJbWNyCXAxNSwg
MCwgcjYsIGMxMCwgYzIsIDENCisNCisJQCBUdXJuIG9uIE1NVQ0KKwlsZHIJcjAsID0oU0NUTFJf
VFJFIHwgU0NUTFJfU1cgfCBTQ1RMUl9aIHwgU0NUTFJfSSB8IFNDVExSX0MgfCBTQ1RMUl9BIHwg
U0NUTFJfTSkNCisJbWNyCVNDVExSKHIwKQ0KKwltb3YJcjAsIHIwDQorCW1vdglyMCwgcjANCisJ
bW92CXIwLCByMA0KKw0KKwlAIEludmFsaWRhdGUgSS9EIFRMQnMNCisJbW92CWlwLCAjMA0KKwlt
Y3IJcDE1LCAwLCBpcCwgYzgsIGM3LCAwDQorCWRzYg0KKwlpc2INCisNCisJQCBDbGVhciBCU1Mg
c2VjdGlvbg0KKwlhZHIgICAgIHIwLCAyZg0KKwlsZG1pYSAgIHIwLCB7cjEsIHIyfQ0KKwltb3Yg
ICAgIHIwLCAjMA0KKzE6DQorCXN0ciAgICAgcjAsIFtyMV0sICM0IA0KKwljbXAgICAgIHIxLCBy
Mg0KKwlibG8gICAgIDFiDQorDQorICAgICAgICAvKiBTdGFjayBTZXR1cCAqLw0KKwlAIEdldCBw
cm9jZXNzb3IgSUQNCisgICAgICAgIG1yYyAgICAgTVBJRFIocjQpDQorICAgICAgICBhbmQgICAg
IHI0LCByNCwgIzE1DQorDQorCUAgcjAgPSByMCAqIFNUQUNLX1NJWkUNCisgICAgICAgIG1vdiAg
ICAgcjEsICNTVEFDS19TSVpFDQorICAgICAgICBtdWwgICAgIHI0LCByNCwgcjENCisNCisJbXNy
CWNwc3JfYywgI1BTUl9NT0RFX0lSUSB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVA0KKwlsZHIJc3As
ID0oaXJxX3N0YWNrcyArIFNUQUNLX1NJWkUpDQorCWFkZAlzcCwgc3AsIHI0DQorDQorCW1zcglj
cHNyX2MsICNQU1JfTU9ERV9BQlQgfCBQU1JfSV9CSVQgfCBQU1JfRl9CSVQNCisJbGRyCXNwLCA9
KGFidF9zdGFja3MgKyBTVEFDS19TSVpFKQ0KKwlhZGQJc3AsIHNwLCByNA0KKw0KKwltc3IJY3Bz
cl9jLCAjUFNSX01PREVfVU5EIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUDQorCWxkcglzcCwgPSh1
bmRfc3RhY2tzICsgU1RBQ0tfU0laRSkNCisJYWRkCXNwLCBzcCwgcjQNCisNCisJbXNyICAgICBj
cHNyX2MsICNQU1JfTU9ERV9TVkMgfCBQU1JfSV9CSVQgfCBQU1JfRl9CSVQNCisJbGRyICAgICBz
cCwgPShzdmNfc3RhY2tzICsgU1RBQ0tfU0laRSkNCisJYWRkCXNwLCBzcCwgcjQNCisNCisJYWRy
ICAgICByMTIsIDNmDQorCWxkcglwYywgW3IxMl0NCisNCisyOgkud29yZCAgIF9zYnNzDQorCS53
b3JkICAgX2Vic3MNCisNCiszOg0KKwkubG9uZyAgIHN0YXJ0X3hlbg0KKw0KKyNpZmRlZiBTTVAN
CisgICAgICAgIC8qDQorICAgICAgICAgKiBDb21tb24gZW50cnkgcG9pbnQgZm9yIHNlY29uZGFy
eSBDUFVzLg0KKyAgICAgICAgICoNCisgICAgICAgICAqIEVuc3VyZSB0aGF0IHdlJ3JlIGluIFNW
QyBtb2RlLCBhbmQgSVJRcyBhcmUgZGlzYWJsZWQuDQorICAgICAgICAgKi8NCisJLnNlY3Rpb24g
LmhlYWQNCitFTlRSWShzbGF2ZV9jcHVfc3RhcnQpDQorCW1zciAgICAgY3Bzcl9jLCAjUFNSX0Zf
QklUIHwgUFNSX0lfQklUIHwgUFNSX01PREVfU1ZDDQorDQorICAgICAgICBtcmMgICAgIEFDVExS
KHIyKQ0KKyAgICAgICAgb3JyICAgICByMiwgcjIsICMoQUNUTFJfU01QKSB8IChBQ1RMUl9GVykN
CisgICAgICAgIG1jciAgICAgQUNUTFIocjIpDQorDQorCUAgTG9hZCBUcmFuc2xhdGlvbiBUYWJs
ZSBCYXNlDQorCWFkcglyNCwgc3RhcnQNCisJc3ViCXI0LCByNCwgIzB4NDAwMA0KKwlvcnIgICAg
IHI0LCByNCwgIyhUVEJfRkxBR1MpDQorCW1jcglUVEJSMChyNCkNCisJbWNyCVRUQlIxKHI0KQ0K
Kw0KKwlAIFRUQkNSIFNldHRpbmcNCisgICAgICAgIG1yYyAgICAgcDE1LCAwLCByNSwgYzEsIGMw
LCAyDQorICAgICAgICBvcnIgICAgIHI1LHI1LCAjKCgzIDw8ICgxMCAqIDIpKSB8KDMgPDwgKDEx
ICogMikpKQ0KKyAgICAgICAgbWNyICAgICBwMTUsIDAsIHI1LCBjMSwgYzAsIDINCisNCisJQCBM
b2FkIERBQw0KKwlsZHIgICAgIHI1LCA9MHg1NTU1NTU1NQ0KKwltY3IgICAgIERBQ1IocjUpDQor
CQ0KKwlsZHIJcjUsID0weEZGMEE4OUE4DQorCWxkcglyNiwgPTB4NDBFMDQwRTANCisJbWNyCXAx
NSwgMCwgcjUsIGMxMCwgYzIsIDANCisJbWNyCXAxNSwgMCwgcjYsIGMxMCwgYzIsIDENCisNCisJ
QCBUdXJuIG9uIE1NVQ0KKwlsZHIJcjAsID0oU0NUTFJfVFJFIHwgU0NUTFJfU1cgfCBTQ1RMUl9a
IHwgU0NUTFJfSSB8IFNDVExSX0MgfCBTQ1RMUl9BIHwgU0NUTFJfTSkNCisJbWNyCVNDVExSKHIw
KQ0KKwltb3YgICAgIHIwLCByMA0KKwltb3YgICAgIHIwLCByMA0KKwltb3YgICAgIHIwLCByMA0K
Kw0KKyAgICAgICAgQCBJbnZhbGlkYXRlIEksIEQgVExCcw0KKwltb3YJaXAsICMwDQorCW1jciAg
ICAgcDE1LCAwLCBpcCwgYzgsIGM3LCAwDQorCWRzYg0KKwlpc2INCisNCisJLyogU3RhY2sgU2V0
dXAgKi8NCisgICAgICAgIEAgZ2V0IHByb2Nlc3NvciBpZA0KKwltcmMgICAgIE1QSURSKHI0KQ0K
KwlhbmQJcjQsIHI0LCAjMTUNCisJCQ0KKwlAIHIwID0gcjAgKiBTVEFDS19TSVpFDQorCW1vdgly
MSwgI1NUQUNLX1NJWkUNCisJbXVsCXI0LCByNCwgcjENCisJDQorCW1zcgljcHNyX2MsICNQU1Jf
TU9ERV9JUlEgfCBQU1JfSV9CSVQgfCBQU1JfRl9CSVQNCisJbGRyCXNwLCA9KGlycV9zdGFja3Mg
KyBTVEFDS19TSVpFKQ0KKwlhZGQJc3AsIHNwLCByNA0KKw0KKwltc3IJY3Bzcl9jLCAjUFNSX01P
REVfQUJUIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUDQorCWxkcglzcCwgPShhYnRfc3RhY2tzICsg
U1RBQ0tfU0laRSkNCisJYWRkCXNwLCBzcCwgcjQNCisNCisJbXNyCWNwc3JfYywgI1BTUl9NT0RF
X1VORCB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVA0KKwlsZHIJc3AsID0odW5kX3N0YWNrcyArIFNU
QUNLX1NJWkUpDQorCWFkZAlzcCwgc3AsIHI0DQorDQorCW1zciAgICAgY3Bzcl9jLCAjUFNSX01P
REVfU1ZDIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUDQorCWxkciAgICAgc3AsID0oc3ZjX3N0YWNr
cyArIFNUQUNLX1NJWkUpDQorCWFkZAlzcCwgc3AsIHI0DQorDQorCWFkciAgICAgcjEyLCAyZg0K
KwlsZG1pYSAgIHIxMiwge2xyLCBwY30NCisNCisyOg0KKwkubG9uZyAgIDJiDQorCS5sb25nCXN0
YXJ0X3hlbl9vbl9zbGF2ZV9jcHUNCisjZW5kaWYNCisNCisJLnNlY3Rpb24gLmJzcy5zdGFja19h
bGlnbmVkLCJ3Ig0KK3N2Y19zdGFja3M6IC5maWxsIFNWQ19TVEFDS19TSVpFLCBNQVhfUEhZU19D
UFVTLCAwDQoraXJxX3N0YWNrczogLmZpbGwgU1ZDX1NUQUNLX1NJWkUsIE1BWF9QSFlTX0NQVVMs
IDANCit1bmRfc3RhY2tzOiAuZmlsbCBTVkNfU1RBQ0tfU0laRSwgTUFYX1BIWVNfQ1BVUywgMA0K
K2FidF9zdGFja3M6IC5maWxsIFNWQ19TVEFDS19TSVpFLCBNQVhfUEhZU19DUFVTLCAwDQorZmlx
X3N0YWNrczogLmZpbGwgU1ZDX1NUQUNLX1NJWkUsIE1BWF9QSFlTX0NQVVMsIDANCmRpZmYgLXIg
ZTZhYzhiNjg2YWE2IHhlbi9pbmNsdWRlL2FzbS1hcm0vbW11LmgNCi0tLSBhL3hlbi9pbmNsdWRl
L2FzbS1hcm0vbW11LmgJRnJpIEZlYiAwMyAxNjowNzozMyAyMDEyICswOTAwDQorKysgYi94ZW4v
aW5jbHVkZS9hc20tYXJtL21tdS5oCUZyaSBGZWIgMDMgMTY6MjY6MzQgMjAxMiArMDkwMA0KQEAg
LTEsMTEgKzEsMjA5IEBADQogI2lmbmRlZiBfX0FSTV9NTVVfSF9fDQogI2RlZmluZSBfX0FSTV9N
TVVfSF9fDQogDQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2NwdS1k
b21haW4uaD4NCisNCisjZGVmaW5lIEwxRV9GTEFHX01BU0sgICAgICAgICAgICgweDNGRikNCisN
CisjZGVmaW5lIEwxRV9UWVBFX0ZBVUxUICAgICAgICAgICgweDAwKQ0KKyNkZWZpbmUgTDFFX1RZ
UEVfVEFCTEUgICAgICAgICAgKDB4MDEpDQorI2RlZmluZSBMMUVfVFlQRV9TRUNUSU9OICAgICAg
ICAoMHgwMikNCisjZGVmaW5lIEwxRV9UWVBFX01BU0sgICAgICAgICAgICgweDAzKQ0KKw0KKyNk
ZWZpbmUgTDFFX0JJVDQJCSgxIDw8IDQpDQorDQorI2RlZmluZSBMMUVfQVBfU1JXX1VOTyAgICAg
ICAgICAoMHgwMSA8PCAxMCkNCisjZGVmaW5lIEwxRV9BUF9TUldfVVJPICAgICAgICAgICgweDAy
IDw8IDEwKQ0KKyNkZWZpbmUgTDFFX0FQX1NSV19VUlcgICAgICAgICAgKDB4MDMgPDwgMTApDQor
DQorI2RlZmluZSBMMUVfQlVGRkVSQUJMRSAgICAgICAgICAoMHgwNCkNCisjZGVmaW5lIEwxRV9D
QUNIRUFCTEUgICAgICAgICAgICgweDA4KQ0KKw0KKyNkZWZpbmUgTDFFX1RFWCh4KSAgICAgICAg
ICAgICAgKCh4KSA8PDEyKQ0KKyNkZWZpbmUgTDFFX0FQWCAgICAgICAgICAgICAgICAgKDEgPDwg
MTUpDQorI2RlZmluZSBMMUVfUyAgICAgICAgICAgICAgICAgICAoMSA8PCAxNikNCisjZGVmaW5l
IEwxRV9uRyAgICAgICAgICAgICAgICAgICgxIDw8IDE3KQ0KKw0KKyNkZWZpbmUgTDFFX1NUUk9O
R09SREVSRUQgICAgICAgKDApDQorI2RlZmluZSBMMUVfREVWSUNFICAgICAgICAgICAgICAoTDFF
X1RFWCgxKSkNCisjZGVmaW5lIEwxRV9XUklURUJBQ0sgICAgICAgICAgIChMMUVfQ0FDSEVBQkxF
IHwgTDFFX0JVRkZFUkFCTEUpDQorI2RlZmluZSBMMUVfV1JJVEVUSFJPVUdIICAgICAgICAoTDFF
X0NBQ0hFQUJMRSkNCisjZGVmaW5lIEwxRV9XUklURUFMTE9DICAgICAgICAgIChMMUVfVEVYKDEp
IHwgTDFFX0NBQ0hFQUJMRSB8IEwxRV9CVUZGRVJBQkxFKQ0KKyNkZWZpbmUgTDFFX1NIQVJFRCAg
ICAgICAgICAgICAgKDApDQorDQorI2RlZmluZSBMMUVfRE9NQUlOX0hZUAkJKERPTUFJTl9IWVAg
PDwgNSkNCisjZGVmaW5lIEwxRV9ET01BSU5fU1ZDCQkoRE9NQUlOX1NWQyA8PCA1KQ0KKyNkZWZp
bmUgTDFFX0RPTUFJTl9VU1IJCShET01BSU5fVVNSIDw8IDUpDQorI2RlZmluZSBMMUVfRE9NQUlO
X0lPICAgICAgICAgICAoRE9NQUlOX0lPIDw8IDUpDQorDQorI2RlZmluZSBMMUVfV0JXQSAgICAg
ICAgICAgICAgICAoTDFFX1RFWCgxKSB8IEwxRV9XUklURUJBQ0spDQorDQorI2RlZmluZSBTRUNU
SU9OX1NISUZUICAgICAgICAgICAoMjApDQorI2RlZmluZSBTRUNUSU9OX1NJWkUgICAgICAgICAg
ICAoMSA8PCBTRUNUSU9OX1NISUZUKQ0KKyNkZWZpbmUgU0VDVElPTl9NQVNLICAgICAgICAgICAg
KH4oU0VDVElPTl9TSVpFIC0gMSkpDQorDQorI2RlZmluZSBMMUVfVFlQRV9IWVBFUlZJU09SICAg
ICAoTDFFX1RZUEVfU0VDVElPTiB8IEwxRV9ET01BSU5fSFlQIHwgTDFFX1MgfCBMMUVfQVBfU1JX
X1VOTyB8IEwxRV9XUklURUFMTE9DKQ0KKyNkZWZpbmUgTDFFX1RZUEVfR1VFU1QJCShMMUVfVFlQ
RV9TRUNUSU9OIHwgTDFFX0RPTUFJTl9TVkMgfCBMMUVfUyB8IEwxRV9BUF9TUldfVVJXIHwgTDFF
X1dSSVRFQUxMT0MpDQorI2RlZmluZSBMMUVfVFlQRV9ERVZJQ0UJCShMMUVfVFlQRV9TRUNUSU9O
IHwgTDFFX0RPTUFJTl9JTyAgfCBMMUVfUyB8IEwxRV9BUF9TUldfVVJXIHwgTDFFX0RFVklDRSkN
CisNCisvKg0KKyAqIERlZmluaXRpb24gZm9yIFBhZ2UgVGFibGUgRW50cmllcw0KKyAqLw0KKw0K
KyNkZWZpbmUgTDJFX0ZMQUdfTUFTSyAgICAgICAgICAgKDB4RkZGKQ0KKw0KKyNkZWZpbmUgTDJF
X1RZUEVfRkFVTFQgICAgICAgICAgKDB4MDApDQorI2RlZmluZSBMMkVfVFlQRV9MQVJHRSAgICAg
ICAgICAoMHgwMSkNCisjZGVmaW5lIEwyRV9UWVBFX1NNQUxMICAgICAgICAgICgweDAyKQ0KKyNk
ZWZpbmUgTDJFX1RZUEVfVElOWSAgICAgICAgICAgKDB4MDMpDQorI2RlZmluZSBMMkVfVFlQRV9F
WFQgICAgICAgICAgICAoMHgwMikNCisNCisjZGVmaW5lIEwyRV9UWVBFX01BU0sgICAgICAgICAg
ICgweDAzKQ0KKw0KKyNkZWZpbmUgTDJFX0JVRkZFUkFCTEUgICAgICAgICAgKDB4MDQpDQorI2Rl
ZmluZSBMMkVfQ0FDSEVBQkxFICAgICAgICAgICAoMHgwOCkNCisNCisjZGVmaW5lIEwxRV9TSElG
VCAgICAgICAgICAgICAgICgyMCkNCisjZGVmaW5lIEwyRV9TSElGVAkJKDEyKQ0KKw0KKyNkZWZp
bmUgTDJFX0VYVF9YTiAgICAgICAgICAgICAgKDEgPDwgMCkNCisjZGVmaW5lIEwyRV9FWFRfQVBf
TUFTSyAgICAgICAgICgzIDw8IDQpDQorI2RlZmluZSBMMkVfRVhUX0FQMCAgICAgICAgICAgICAo
MSA8PCA0KQ0KKyNkZWZpbmUgTDJFX0VYVF9BUDEgICAgICAgICAgICAgKDIgPDwgNCkNCisjZGVm
aW5lIEwyRV9FWFRfQVBfVU5PX1NSTyAgICAgICgwIDw8IDQpDQorI2RlZmluZSBMMkVfRVhUX0FQ
X1VOT19TUlcgICAgICAoTDJFX0VYVF9BUDApDQorI2RlZmluZSBMMkVfRVhUX0FQX1VST19TUlcg
ICAgICAoTDJFX0VYVF9BUDEpDQorI2RlZmluZSBMMkVfRVhUX0FQX1VSV19TUlcgICAgICAoTDJF
X0VYVF9BUDF8TDJFX0VYVF9BUDApDQorI2RlZmluZSBMMkVfRVhUX1RFWCh4KSAgICAgICAgICAo
KHgpIDw8IDYpDQorI2RlZmluZSBMMkVfRVhUX0FQWCAgICAgICAgICAgICAoMSA8PCA5KQ0KKyNk
ZWZpbmUgTDJFX0VYVF9DT0hFUkVOVCAgICAgICAgKDEgPDwgOSkNCisjZGVmaW5lIEwyRV9FWFRf
U0hBUkVEICAgICAgICAgICgxIDw8IDEwKQ0KKyNkZWZpbmUgTDJFX0VYVF9ORyAgICAgICAgICAg
ICAgKDEgPDwgMTEpDQorDQorDQorI2RlZmluZSBMMV9UQUJMRV9FTlRSSUVTCSg0MDk2KQ0KKyNk
ZWZpbmUgTDJfVEFCTEVfRU5UUklFUwkoMjU2KQ0KKw0KKyNkZWZpbmUgTDFfVEFCTEVfU0laRQkJ
KDB4NDAwMCkNCisNCisjZGVmaW5lIEwyRV9HVUVTVF9BUF9NQVNLICAgICAgIEwyRV9FWFRfQVBf
TUFTSw0KKyNkZWZpbmUgTDJFX0dVRVNUX0FQX05PICAgICAgICAgTDJFX0VYVF9BUF9VTk9fU1JX
DQorI2RlZmluZSBMMkVfR1VFU1RfQVBfUk8gICAgICAgICBMMkVfRVhUX0FQX1VST19TUlcNCisj
ZGVmaW5lIEwyRV9HVUVTVF9BUF9SVyAgICAgICAgIEwyRV9FWFRfQVBfVVJXX1NSVw0KKw0KKyNk
ZWZpbmUgTDFFX0dVRVNUX1RBQkxFICAgICAgICAgKEwxRV9ET01BSU5fU1ZDIHwgTDFFX1RZUEVf
VEFCTEUpDQorI2RlZmluZSBMMUVfVkVDVE9SX1RBQkxFICAgICAgICAoTDFFX0RPTUFJTl9TVkMg
fCBMMUVfVFlQRV9UQUJMRSkNCisNCisjZGVmaW5lIEwyRV9HVUVTVF9QQUdFICAgICAgICAgIChM
MkVfRVhUX1NIQVJFRCB8IEwyRV9HVUVTVF9BUF9SVyB8IEwyRV9FWFRfVEVYKDEpIHwgTDJFX0JV
RkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX1RZUEVfRVhUKQ0KKw0KKyNkZWZpbmUgTDJF
X1ZFQ1RPUl9QQUdFICAgICAgICAgKEwyRV9HVUVTVF9BUF9STyB8IEwyRV9FWFRfVEVYKDEpIHwg
TDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX1RZUEVfRVhUKQ0KKyNkZWZpbmUg
TDJFX0dSQU5UX1BBR0UJCShMMkVfVFlQRV9FWFQgfCBMMkVfRVhUX1NIQVJFRCB8IEwyRV9FWFRf
VEVYKDEpIHwgTDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX0dVRVNUX0FQX1JX
KQ0KKyNkZWZpbmUgTDJFX1NIQVJFRF9JTkZPCQkoTDJFX1RZUEVfRVhUIHwgTDJFX0VYVF9URVgo
MSkgfCBMMkVfRVhUX1hOIHwgTDJFX0VYVF9TSEFSRUQgfCBMMkVfQlVGRkVSQUJMRSB8IEwyRV9D
QUNIRUFCTEUgfCBMMkVfR1VFU1RfQVBfUlcpDQorI2RlZmluZSBMMkVfREVWSUNFCQkoTDJFX1RZ
UEVfRVhUIHwgTDJFX0VYVF9URVgoMSkgfCBMMkVfRVhUX1hOIHwgTDJFX0VYVF9TSEFSRUQgfCBM
MkVfR1VFU1RfQVBfUlcpDQorDQogI2RlZmluZSBQQUREUl9CSVRTICAgICAgICAgICAgICAzMg0K
ICNkZWZpbmUgUEFERFJfTUFTSyAgICAgICAgICAgICAgKCgxVUwgPDwgUEFERFJfQklUUykgLSAx
KQ0KIA0KICNkZWZpbmUgVkFERFJfQklUUyAgICAgICAgICAgICAgMzINCiAjZGVmaW5lIFZBRERS
X01BU0sgICAgICAgICAgICAgICgoMVVMIDw8IFZBRERSX0JJVFMpIC0gMSkNCiANCisjZGVmaW5l
IFRUQl9TICAgICAgICAgICAoMSA8PCAxKQ0KKyNkZWZpbmUgVFRCX1JHTl9OQyAgICAgICgwIDw8
IDMpDQorI2RlZmluZSBUVEJfUkdOX09DX1dCV0EgKDEgPDwgMykNCisjZGVmaW5lIFRUQl9SR05f
T0NfV1QgICAoMiA8PCAzKQ0KKyNkZWZpbmUgVFRCX1JHTl9PQ19XQiAgICgzIDw8IDMpDQorI2Rl
ZmluZSBUVEJfTk9TICAgICAgICAgKDEgPDwgNSkNCisjZGVmaW5lIFRUQl9JUkdOX05DICAgICAo
KDAgPDwgMCkgfCAoMCA8PCA2KSkNCisjZGVmaW5lIFRUQl9JUkdOX1dCV0EgICAoKDAgPDwgMCkg
fCAoMSA8PCA2KSkNCisjZGVmaW5lIFRUQl9JUkdOX1dUICAgICAoKDEgPDwgMCkgfCAoMCA8PCA2
KSkNCisjZGVmaW5lIFRUQl9JUkdOX1dCICAgICAoKDEgPDwgMCkgfCAoMSA8PCA2KSkNCisNCisN
CisjZGVmaW5lIFRUQl9GTEFHUyAgICAgICAgICAgICAgIChUVEJfSVJHTl9XQldBIHwgVFRCX1Mg
fCBUVEJfTk9TIHwgVFRCX1JHTl9PQ19XQldBKQ0KKw0KKyNkZWZpbmUgVFRCX01BU0sJCSh+MHgz
RkZGKQ0KKw0KKyNpZm5kZWYgX19BU1NFTUJMWV9fDQorDQorI2luY2x1ZGUgPGFzbS90eXBlcy5o
Pg0KKw0KKyNkZWZpbmUgbDJlX3ZhbCh4KSAgICAgICAgICAgICAgKCh4KS5sMmUpDQorI2RlZmlu
ZSBsMWVfdmFsKHgpICAgICAgICAgICAgICAoKHgpLmwxZSkNCisNCisjZGVmaW5lIE1LX0wyRSh4
LCBmbGFncykJKChsMmVfdCkgeyAoKHVuc2lnbmVkIGxvbmcpKHgpICYgKH5MMkVfRkxBR19NQVNL
KSkgfCBmbGFncyB9ICkNCisjZGVmaW5lIE1LX0wxRSh4LCBmbGFncykJKChsMWVfdCkgeyAoKHVu
c2lnbmVkIGxvbmcpKHgpICYgKH5MMUVfRkxBR19NQVNLKSkgfCBmbGFncyB9ICkNCisNCisjZGVm
aW5lIGwxdF9pbmRleCh4KQkJKCgodW5zaWduZWQgbG9uZykoeCkgPj4gTDFFX1NISUZUKSAmIChM
MV9UQUJMRV9FTlRSSUVTIC0gMSkpDQorI2RlZmluZSBsMnRfaW5kZXgoeCkJCSgoKHVuc2lnbmVk
IGxvbmcpKHgpID4+IEwyRV9TSElGVCkgJiAoTDJfVEFCTEVfRU5UUklFUyAtIDEpKQ0KKw0KKyNk
ZWZpbmUgbDFfbGluZWFyX29mZnNldF94ZW4odmEpCVwNCisJKGwxX2xpbmVhcl9vZmZzZXQoKHhl
bl90cmFuc2xhdGlvbl90YWJsZSksIHZhKSkNCisNCit0eXBlZGVmIHN0cnVjdCB7IHVuc2lnbmVk
IGxvbmcgbDJlOyB9IGwyZV90Ow0KK3R5cGVkZWYgc3RydWN0IHsgdW5zaWduZWQgbG9uZyBsMWU7
IH0gbDFlX3Q7DQorDQorc3RhdGljIGlubGluZSBsMWVfdCAqbDFfbGluZWFyX29mZnNldChsMWVf
dCAqbDFlLCB1bnNpZ25lZCBsb25nIHZpcnQpDQorew0KKwlyZXR1cm4gbDFlICsgbDF0X2luZGV4
KHZpcnQpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIGwyZV90ICpsMl9saW5lYXJfb2Zmc2V0KGwx
ZV90ICpsMWUsIHVuc2lnbmVkIGxvbmcgdmlydCkNCit7DQorICAgICAgICBsMmVfdCAqbDJlOw0K
Kw0KKyAgICAgICAgbDJlID0gKGwyZV90ICopIChsMWVfdmFsKCpsMWUpICYgfkwxRV9GTEFHX01B
U0spOw0KKyAgICAgICAgbDJlID0gbDJlICsgbDJ0X2luZGV4KHZpcnQpOw0KKw0KKyAgICAgICAg
cmV0dXJuIGwyZTsNCit9DQorDQorc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQgZ2V0X2RhY3Io
dm9pZCkNCit7DQorCXVuc2lnbmVkIGludCB2YWw7DQorDQorCWFzbSgibXJjIHAxNSwgMCwgJTAs
IGMzLCBjMCwgMCIgOiAiPXIiICh2YWwpIDogOiAiY2MiKTsNCisNCisJcmV0dXJuIHZhbDsNCit9
DQorDQorDQorc3RhdGljIGlubGluZSB2b2lkIHNldF9kYWNyKHVuc2lnbmVkIGxvbmcgdmFsKQ0K
K3sNCisJYXNtKCJtcmMgcDE1LCAwLCAlMCwgYzMsIGMwLCAwIiA6ICI9ciIgKHZhbCkgOiA6ICJj
YyIpOw0KK30NCisNCisNCitzdGF0aWMgaW5saW5lIHVuc2lnbmVkIGludCBnZXRfdHRicih2b2lk
KQ0KK3sNCisJdW5zaWduZWQgaW50IHZhbDsNCisJDQorCWFzbSgibXJjIHAxNSwgMCwgJTAsIGMy
LCBjMCwgMCIgOiAiPXIiICh2YWwpIDogOiAiY2MiKTsNCisNCisJcmV0dXJuIHZhbDsNCit9DQor
DQorc3RhdGljIGlubGluZSB2b2lkIHNldF90dGJyKHVuc2lnbmVkIGludCB0dGIpDQorew0KKwlh
c20gdm9sYXRpbGUoIm1jciBwMTUsIDAsICUwLCBjMiwgYzAsIDAiIDogOiAiciIgKHR0YikgOiAi
Y2MiKTsNCisNCisJaXNiKCk7DQorfQ0KKw0KK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfY29udGV4
dGlkcih1bnNpZ25lZCBsb25nIGlkKQ0KK3sNCisJYXNtKCJtY3IgICAgIHAxNSwgMCwgJTAsIGMx
MywgYzAsIDEiIDogOiAiciIgKGlkKSA6ICJjYyIpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBnZXRfY29udGV4dGlkcih2b2lkKQ0KK3sNCisJdW5zaWduZWQgaW50IHZhbDsN
CisJDQorCWFzbSgibXJjIHAxNSwgMCwgJTAsIGMxMywgYzAsIDEiIDogIj1yIiAodmFsKSA6IDog
ImNjIik7DQorDQorCXJldHVybiB2YWw7DQorfQ0KKw0KKyNlbmRpZg0KICNlbmRpZg0KIA0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch03.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch03.diff"


YXJtOiBpbXBsZW1lbnQgc3RhcnR1cCBjb2RlLgoKIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUgfCAgICAxICsKIHhlbi9hcmNoL2FybS94ZW4vc3RhcnQuUyAgfCAgMjczICsrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiB4ZW4vaW5jbHVkZS9hc20tYXJtL21t
dS5oIHwgIDE5OCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysKClNpZ25lZC1vZmYtYnk6IEphZW1pbiBSeXUgPGpt
Nzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciBlNmFjOGI2ODZhYTYgeGVuL2FyY2gvYXJt
L3hlbi9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCUZyaSBGZWIg
MDMgMTY6MDc6MzMgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxl
CUZyaSBGZWIgMDMgMTY6MjY6MzQgMjAxMiArMDkwMApAQCAtMSwzICsxLDQgQEAKK29iai15
ICs9IHN0YXJ0Lm8KIG9iai15ICs9IHNldHVwLm8KIG9iai15ICs9IG1tLm8KIG9iai15ICs9
IGlycS5vCmRpZmYgLXIgZTZhYzhiNjg2YWE2IHhlbi9hcmNoL2FybS94ZW4vc3RhcnQuUwot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3N0YXJ0LlMJRnJpIEZlYiAwMyAxNjoyNjozNCAyMDEyICswOTAwCkBA
IC0wLDAgKzEsMjczIEBACisvKgorICogc3RhcnQuUyAKKyAqCisgKiBDb3B5cmlnaHQgKEMp
IDIwMDgtMjAxMSBTYW1zdW5nIEVsZWN0cm9uaWNzIAorICogICAgICAgICAgU2FuZy1idW0g
U3VoIDxzYnVrLnN1aEBzYW1zdW5nLmNvbT4KKyAqICAgICAgICAgIEphZW1pbiBSeXUgICA8
am03Ny5yeXVAc2Ftc3VuZy5jb20+CisgKgorICogU2VjdXJlIFhlbiBvbiBBUk0gYXJjaGl0
ZWN0dXJlIGRlc2lnbmVkIGJ5IFNhbmctYnVtIFN1aCBjb25zaXN0cyBvZgorICogWGVuIG9u
IEFSTSBhbmQgdGhlIGFzc29jaWF0ZWQgYWNjZXNzIGNvbnRyb2wuCisgKiAKKyAqIFRoaXMg
cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQv
b3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyB2ZXJzaW9uIDIgb2YgTGljZW5zZSBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1
dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9V
VCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgor
ICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF
LiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0
YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBH
TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07
IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRpb24sIElu
Yy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3
ICBVU0EKKyAqLworCisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9j
cHUtZG9tYWluLmg+CisjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5oPgorI2luY2x1ZGUgPGFz
bS9wYWdlLmg+CisjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgorI2luY2x1ZGUgPGFzbS9tbXUu
aD4KKyNpbmNsdWRlIDxhc20vYXNtLW1hY3Jvcy5oPgorCisvKgorICogSW5pdGlhbCBzdGFj
ayBmb3IgY29yZSAwCisgKi8KKyNkZWZpbmUgU1ZDX1NUQUNLX1NJWkUJU1RBQ0tfU0laRQor
CisubWFjcm8gcGEgcmQsIHJzCisxOgorCWFkcglccnMsIDFiCisJbHNyCVxycywgXHJzLCAj
MjAKKwlzdWIJXHJkLCBccmQsICNYRU5fVklSVF9TVEFSVAorCWFkZAlccmQsIFxyZCwgXHJz
LCBsc2wgIzIwCisuZW5kbQorCQorCS5zZWN0aW9uIC5oZWFkCitFTlRSWShzdGFydCkKKwlt
c3IgICAgIGNwc3JfYywgIyhQU1JfRl9CSVQgfCBQU1JfSV9CSVQgfCBQU1JfTU9ERV9TVkMp
CisKKyNpZmRlZiBTTVAKKwltcmMJQUNUTFIocjIpCisJb3JyCXIyLCByMiwgIyhBQ1RMUl9T
TVApIHwgKEFDVExSX0ZXKQorCW1jcglBQ1RMUihyMikKKyNlbmRpZgorCQorCWFkcglyMCwg
c3RhcnQKKwltb3YJcjEsIHIwCisJc3ViCXIwLCByMCwgIzB4NDAwMAkKKwltb3YJcjIsICMw
CisxOglzdHIJcjIsIFtyMSwgIy00XSEKKwlzdHIJcjIsIFtyMSwgIy00XSEKKwlzdHIJcjIs
IFtyMSwgIy00XSEKKwlzdHIJcjIsIFtyMSwgIy00XSEKKwljbXAJcjAsIHIxCisJYm5lCTFi
CisKKwlsZHIgICAgIHIyLCA9KFhFTl9WSVJUX1NUQVJUID4+IDIwKQorCWxkciAgICAgcjcs
ID0oTDFFX1RZUEVfSFlQRVJWSVNPUikKKworCUAgU3RhcnQgc2VjdGlvbiBuby4KKwltb3Yg
ICAgIHIzLCBwYworCWxzciAgICAgcjMsIHIzLCAjMjAKKworCUAgSW5pdGlhbCBWTU0gbWFw
cGluZworCW9yciAgICAgcjQsIHI3LCByMywgbHNsICMyMAorCXN0ciAgICAgcjQsIFtyMCwg
cjIsIGxzbCAjMl0KKwlAYWRkCXI0LCByNCwgIzB4MTAwMDAwCisJQGFkZAlyMiwgcjIsICMx
CisJQHN0cglyNCwgW3IwLCByMiwgbHNsICMyXQorCisgICAgICAgIGxkciAgICAgcjUsID1f
c21lbXRhYmxlCisJcGEJcjUsIHI2CisJbGRyCXI2LCA9X2VtZW10YWJsZQorCXBhCXI2LCBy
NworCisxOgorCWNtcAlyNSwgcjYKKwliZXEJM2YKKworCUAgcjEgOiBiYXNlCisJQCByMiA6
IHNpemUKKwlAIHIzIDogdHlwZQorCUAgcjQgOiBtbXVfZmxhZ3MKKworICAgICAgICBsZG1p
YSAgIHI1ISwge3IxLCByMiwgcjMsIHI0fQorCWxzcglyMSwgcjEsICMyMAorCW9ycglyNCwg
cjQsIHIxLCBsc2wgIzIwCisKKwlAIFJvdW5kIHVwCisJYWRkCXIyLCByMiwgIzB4RkYwMAor
CWFkZAlyMiwgcjIsICMweDAwRkYKKwlsc3IJcjIsIHIyLCAjMjAKKzI6CisgICAgICAgIHN0
ciAgICAgcjQsIFtyMCwgcjEsIGxzbCAjMl0KKyAgICAgICAgYWRkICAgICByMSwgcjEsICMx
CisgICAgICAgIGFkZCAgICAgcjQsIHI0LCAjMHgxMDAwMDAKKyAgICAgICAgYWRkcyAgICBy
MiwgcjIsICMtMQorICAgICAgICBiaGkgICAgIDJiCisJYgkxYgorMzoKKworCUAgTG9hZCBU
cmFuc2xhdGlvbiBUYWJsZSBCYXNlCisJb3JyCXIwLCByMCwgIyhUVEJfRkxBR1MpCisJbWNy
CVRUQlIwKHIwKQorCW1jcglUVEJSMShyMCkKKworCUAgVFRCQ1IgU2V0dGluZworICAgICAg
ICBtcmMgICAgIHAxNSwgMCwgcjUsIGMxLCBjMCwgMgorICAgICAgICBvcnIgICAgIHI1LHI1
LCAjKCgzIDw8ICgxMCAqIDIpKSB8KDMgPDwgKDExICogMikpKQorICAgICAgICBtY3IgICAg
IHAxNSwgMCwgcjUsIGMxLCBjMCwgMgorCisJQCBMb2FkIERBQworCWxkcglyNSwgPTB4NTU1
NTU1NTUKKwltY3IJREFDUihyNSkKKworCWxkcglyNSwgPTB4RkYwQTg5QTgKKwlsZHIJcjYs
ID0weDQwRTA0MEUwCisJbWNyCXAxNSwgMCwgcjUsIGMxMCwgYzIsIDAKKwltY3IJcDE1LCAw
LCByNiwgYzEwLCBjMiwgMQorCisJQCBUdXJuIG9uIE1NVQorCWxkcglyMCwgPShTQ1RMUl9U
UkUgfCBTQ1RMUl9TVyB8IFNDVExSX1ogfCBTQ1RMUl9JIHwgU0NUTFJfQyB8IFNDVExSX0Eg
fCBTQ1RMUl9NKQorCW1jcglTQ1RMUihyMCkKKwltb3YJcjAsIHIwCisJbW92CXIwLCByMAor
CW1vdglyMCwgcjAKKworCUAgSW52YWxpZGF0ZSBJL0QgVExCcworCW1vdglpcCwgIzAKKwlt
Y3IJcDE1LCAwLCBpcCwgYzgsIGM3LCAwCisJZHNiCisJaXNiCisKKwlAIENsZWFyIEJTUyBz
ZWN0aW9uCisJYWRyICAgICByMCwgMmYKKwlsZG1pYSAgIHIwLCB7cjEsIHIyfQorCW1vdiAg
ICAgcjAsICMwCisxOgorCXN0ciAgICAgcjAsIFtyMV0sICM0IAorCWNtcCAgICAgcjEsIHIy
CisJYmxvICAgICAxYgorCisgICAgICAgIC8qIFN0YWNrIFNldHVwICovCisJQCBHZXQgcHJv
Y2Vzc29yIElECisgICAgICAgIG1yYyAgICAgTVBJRFIocjQpCisgICAgICAgIGFuZCAgICAg
cjQsIHI0LCAjMTUKKworCUAgcjAgPSByMCAqIFNUQUNLX1NJWkUKKyAgICAgICAgbW92ICAg
ICByMSwgI1NUQUNLX1NJWkUKKyAgICAgICAgbXVsICAgICByNCwgcjQsIHIxCisKKwltc3IJ
Y3Bzcl9jLCAjUFNSX01PREVfSVJRIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRyCXNw
LCA9KGlycV9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwltc3IJ
Y3Bzcl9jLCAjUFNSX01PREVfQUJUIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRyCXNw
LCA9KGFidF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwltc3IJ
Y3Bzcl9jLCAjUFNSX01PREVfVU5EIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRyCXNw
LCA9KHVuZF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwltc3Ig
ICAgIGNwc3JfYywgI1BTUl9NT0RFX1NWQyB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVAorCWxk
ciAgICAgc3AsID0oc3ZjX3N0YWNrcyArIFNUQUNLX1NJWkUpCisJYWRkCXNwLCBzcCwgcjQK
KworCWFkciAgICAgcjEyLCAzZgorCWxkcglwYywgW3IxMl0KKworMjoJLndvcmQgICBfc2Jz
cworCS53b3JkICAgX2Vic3MKKworMzoKKwkubG9uZyAgIHN0YXJ0X3hlbgorCisjaWZkZWYg
U01QCisgICAgICAgIC8qCisgICAgICAgICAqIENvbW1vbiBlbnRyeSBwb2ludCBmb3Igc2Vj
b25kYXJ5IENQVXMuCisgICAgICAgICAqCisgICAgICAgICAqIEVuc3VyZSB0aGF0IHdlJ3Jl
IGluIFNWQyBtb2RlLCBhbmQgSVJRcyBhcmUgZGlzYWJsZWQuCisgICAgICAgICAqLworCS5z
ZWN0aW9uIC5oZWFkCitFTlRSWShzbGF2ZV9jcHVfc3RhcnQpCisJbXNyICAgICBjcHNyX2Ms
ICNQU1JfRl9CSVQgfCBQU1JfSV9CSVQgfCBQU1JfTU9ERV9TVkMKKworICAgICAgICBtcmMg
ICAgIEFDVExSKHIyKQorICAgICAgICBvcnIgICAgIHIyLCByMiwgIyhBQ1RMUl9TTVApIHwg
KEFDVExSX0ZXKQorICAgICAgICBtY3IgICAgIEFDVExSKHIyKQorCisJQCBMb2FkIFRyYW5z
bGF0aW9uIFRhYmxlIEJhc2UKKwlhZHIJcjQsIHN0YXJ0CisJc3ViCXI0LCByNCwgIzB4NDAw
MAorCW9yciAgICAgcjQsIHI0LCAjKFRUQl9GTEFHUykKKwltY3IJVFRCUjAocjQpCisJbWNy
CVRUQlIxKHI0KQorCisJQCBUVEJDUiBTZXR0aW5nCisgICAgICAgIG1yYyAgICAgcDE1LCAw
LCByNSwgYzEsIGMwLCAyCisgICAgICAgIG9yciAgICAgcjUscjUsICMoKDMgPDwgKDEwICog
MikpIHwoMyA8PCAoMTEgKiAyKSkpCisgICAgICAgIG1jciAgICAgcDE1LCAwLCByNSwgYzEs
IGMwLCAyCisKKwlAIExvYWQgREFDCisJbGRyICAgICByNSwgPTB4NTU1NTU1NTUKKwltY3Ig
ICAgIERBQ1IocjUpCisJCisJbGRyCXI1LCA9MHhGRjBBODlBOAorCWxkcglyNiwgPTB4NDBF
MDQwRTAKKwltY3IJcDE1LCAwLCByNSwgYzEwLCBjMiwgMAorCW1jcglwMTUsIDAsIHI2LCBj
MTAsIGMyLCAxCisKKwlAIFR1cm4gb24gTU1VCisJbGRyCXIwLCA9KFNDVExSX1RSRSB8IFND
VExSX1NXIHwgU0NUTFJfWiB8IFNDVExSX0kgfCBTQ1RMUl9DIHwgU0NUTFJfQSB8IFNDVExS
X00pCisJbWNyCVNDVExSKHIwKQorCW1vdiAgICAgcjAsIHIwCisJbW92ICAgICByMCwgcjAK
Kwltb3YgICAgIHIwLCByMAorCisgICAgICAgIEAgSW52YWxpZGF0ZSBJLCBEIFRMQnMKKwlt
b3YJaXAsICMwCisJbWNyICAgICBwMTUsIDAsIGlwLCBjOCwgYzcsIDAKKwlkc2IKKwlpc2IK
KworCS8qIFN0YWNrIFNldHVwICovCisgICAgICAgIEAgZ2V0IHByb2Nlc3NvciBpZAorCW1y
YyAgICAgTVBJRFIocjQpCisJYW5kCXI0LCByNCwgIzE1CisJCQorCUAgcjAgPSByMCAqIFNU
QUNLX1NJWkUKKwltb3YJcjEsICNTVEFDS19TSVpFCisJbXVsCXI0LCByNCwgcjEKKwkKKwlt
c3IJY3Bzcl9jLCAjUFNSX01PREVfSVJRIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRy
CXNwLCA9KGlycV9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwlt
c3IJY3Bzcl9jLCAjUFNSX01PREVfQUJUIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRy
CXNwLCA9KGFidF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwlt
c3IJY3Bzcl9jLCAjUFNSX01PREVfVU5EIHwgUFNSX0lfQklUIHwgUFNSX0ZfQklUCisJbGRy
CXNwLCA9KHVuZF9zdGFja3MgKyBTVEFDS19TSVpFKQorCWFkZAlzcCwgc3AsIHI0CisKKwlt
c3IgICAgIGNwc3JfYywgI1BTUl9NT0RFX1NWQyB8IFBTUl9JX0JJVCB8IFBTUl9GX0JJVAor
CWxkciAgICAgc3AsID0oc3ZjX3N0YWNrcyArIFNUQUNLX1NJWkUpCisJYWRkCXNwLCBzcCwg
cjQKKworCWFkciAgICAgcjEyLCAyZgorCWxkbWlhICAgcjEyLCB7bHIsIHBjfQorCisyOgor
CS5sb25nICAgMmIKKwkubG9uZwlzdGFydF94ZW5fb25fc2xhdmVfY3B1CisjZW5kaWYKKwor
CS5zZWN0aW9uIC5ic3Muc3RhY2tfYWxpZ25lZCwidyIKK3N2Y19zdGFja3M6IC5maWxsIFNW
Q19TVEFDS19TSVpFLCBNQVhfUEhZU19DUFVTLCAwCitpcnFfc3RhY2tzOiAuZmlsbCBTVkNf
U1RBQ0tfU0laRSwgTUFYX1BIWVNfQ1BVUywgMAordW5kX3N0YWNrczogLmZpbGwgU1ZDX1NU
QUNLX1NJWkUsIE1BWF9QSFlTX0NQVVMsIDAKK2FidF9zdGFja3M6IC5maWxsIFNWQ19TVEFD
S19TSVpFLCBNQVhfUEhZU19DUFVTLCAwCitmaXFfc3RhY2tzOiAuZmlsbCBTVkNfU1RBQ0tf
U0laRSwgTUFYX1BIWVNfQ1BVUywgMApkaWZmIC1yIGU2YWM4YjY4NmFhNiB4ZW4vaW5jbHVk
ZS9hc20tYXJtL21tdS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW11LmgJRnJpIEZl
YiAwMyAxNjowNzozMyAyMDEyICswOTAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vbW11
LmgJRnJpIEZlYiAwMyAxNjoyNjozNCAyMDEyICswOTAwCkBAIC0xLDExICsxLDIwOSBAQAog
I2lmbmRlZiBfX0FSTV9NTVVfSF9fCiAjZGVmaW5lIF9fQVJNX01NVV9IX18KIAorI2luY2x1
ZGUgPGFzbS9zeXN0ZW0uaD4KKyNpbmNsdWRlIDxhc20vY3B1LWRvbWFpbi5oPgorCisjZGVm
aW5lIEwxRV9GTEFHX01BU0sgICAgICAgICAgICgweDNGRikKKworI2RlZmluZSBMMUVfVFlQ
RV9GQVVMVCAgICAgICAgICAoMHgwMCkKKyNkZWZpbmUgTDFFX1RZUEVfVEFCTEUgICAgICAg
ICAgKDB4MDEpCisjZGVmaW5lIEwxRV9UWVBFX1NFQ1RJT04gICAgICAgICgweDAyKQorI2Rl
ZmluZSBMMUVfVFlQRV9NQVNLICAgICAgICAgICAoMHgwMykKKworI2RlZmluZSBMMUVfQklU
NAkJKDEgPDwgNCkKKworI2RlZmluZSBMMUVfQVBfU1JXX1VOTyAgICAgICAgICAoMHgwMSA8
PCAxMCkKKyNkZWZpbmUgTDFFX0FQX1NSV19VUk8gICAgICAgICAgKDB4MDIgPDwgMTApCisj
ZGVmaW5lIEwxRV9BUF9TUldfVVJXICAgICAgICAgICgweDAzIDw8IDEwKQorCisjZGVmaW5l
IEwxRV9CVUZGRVJBQkxFICAgICAgICAgICgweDA0KQorI2RlZmluZSBMMUVfQ0FDSEVBQkxF
ICAgICAgICAgICAoMHgwOCkKKworI2RlZmluZSBMMUVfVEVYKHgpICAgICAgICAgICAgICAo
KHgpIDw8MTIpCisjZGVmaW5lIEwxRV9BUFggICAgICAgICAgICAgICAgICgxIDw8IDE1KQor
I2RlZmluZSBMMUVfUyAgICAgICAgICAgICAgICAgICAoMSA8PCAxNikKKyNkZWZpbmUgTDFF
X25HICAgICAgICAgICAgICAgICAgKDEgPDwgMTcpCisKKyNkZWZpbmUgTDFFX1NUUk9OR09S
REVSRUQgICAgICAgKDApCisjZGVmaW5lIEwxRV9ERVZJQ0UgICAgICAgICAgICAgIChMMUVf
VEVYKDEpKQorI2RlZmluZSBMMUVfV1JJVEVCQUNLICAgICAgICAgICAoTDFFX0NBQ0hFQUJM
RSB8IEwxRV9CVUZGRVJBQkxFKQorI2RlZmluZSBMMUVfV1JJVEVUSFJPVUdIICAgICAgICAo
TDFFX0NBQ0hFQUJMRSkKKyNkZWZpbmUgTDFFX1dSSVRFQUxMT0MgICAgICAgICAgKEwxRV9U
RVgoMSkgfCBMMUVfQ0FDSEVBQkxFIHwgTDFFX0JVRkZFUkFCTEUpCisjZGVmaW5lIEwxRV9T
SEFSRUQgICAgICAgICAgICAgICgwKQorCisjZGVmaW5lIEwxRV9ET01BSU5fSFlQCQkoRE9N
QUlOX0hZUCA8PCA1KQorI2RlZmluZSBMMUVfRE9NQUlOX1NWQwkJKERPTUFJTl9TVkMgPDwg
NSkKKyNkZWZpbmUgTDFFX0RPTUFJTl9VU1IJCShET01BSU5fVVNSIDw8IDUpCisjZGVmaW5l
IEwxRV9ET01BSU5fSU8gICAgICAgICAgIChET01BSU5fSU8gPDwgNSkKKworI2RlZmluZSBM
MUVfV0JXQSAgICAgICAgICAgICAgICAoTDFFX1RFWCgxKSB8IEwxRV9XUklURUJBQ0spCisK
KyNkZWZpbmUgU0VDVElPTl9TSElGVCAgICAgICAgICAgKDIwKQorI2RlZmluZSBTRUNUSU9O
X1NJWkUgICAgICAgICAgICAoMSA8PCBTRUNUSU9OX1NISUZUKQorI2RlZmluZSBTRUNUSU9O
X01BU0sgICAgICAgICAgICAofihTRUNUSU9OX1NJWkUgLSAxKSkKKworI2RlZmluZSBMMUVf
VFlQRV9IWVBFUlZJU09SICAgICAoTDFFX1RZUEVfU0VDVElPTiB8IEwxRV9ET01BSU5fSFlQ
IHwgTDFFX1MgfCBMMUVfQVBfU1JXX1VOTyB8IEwxRV9XUklURUFMTE9DKQorI2RlZmluZSBM
MUVfVFlQRV9HVUVTVAkJKEwxRV9UWVBFX1NFQ1RJT04gfCBMMUVfRE9NQUlOX1NWQyB8IEwx
RV9TIHwgTDFFX0FQX1NSV19VUlcgfCBMMUVfV1JJVEVBTExPQykKKyNkZWZpbmUgTDFFX1RZ
UEVfREVWSUNFCQkoTDFFX1RZUEVfU0VDVElPTiB8IEwxRV9ET01BSU5fSU8gIHwgTDFFX1Mg
fCBMMUVfQVBfU1JXX1VSVyB8IEwxRV9ERVZJQ0UpCisKKy8qCisgKiBEZWZpbml0aW9uIGZv
ciBQYWdlIFRhYmxlIEVudHJpZXMKKyAqLworCisjZGVmaW5lIEwyRV9GTEFHX01BU0sgICAg
ICAgICAgICgweEZGRikKKworI2RlZmluZSBMMkVfVFlQRV9GQVVMVCAgICAgICAgICAoMHgw
MCkKKyNkZWZpbmUgTDJFX1RZUEVfTEFSR0UgICAgICAgICAgKDB4MDEpCisjZGVmaW5lIEwy
RV9UWVBFX1NNQUxMICAgICAgICAgICgweDAyKQorI2RlZmluZSBMMkVfVFlQRV9USU5ZICAg
ICAgICAgICAoMHgwMykKKyNkZWZpbmUgTDJFX1RZUEVfRVhUICAgICAgICAgICAgKDB4MDIp
CisKKyNkZWZpbmUgTDJFX1RZUEVfTUFTSyAgICAgICAgICAgKDB4MDMpCisKKyNkZWZpbmUg
TDJFX0JVRkZFUkFCTEUgICAgICAgICAgKDB4MDQpCisjZGVmaW5lIEwyRV9DQUNIRUFCTEUg
ICAgICAgICAgICgweDA4KQorCisjZGVmaW5lIEwxRV9TSElGVCAgICAgICAgICAgICAgICgy
MCkKKyNkZWZpbmUgTDJFX1NISUZUCQkoMTIpCisKKyNkZWZpbmUgTDJFX0VYVF9YTiAgICAg
ICAgICAgICAgKDEgPDwgMCkKKyNkZWZpbmUgTDJFX0VYVF9BUF9NQVNLICAgICAgICAgKDMg
PDwgNCkKKyNkZWZpbmUgTDJFX0VYVF9BUDAgICAgICAgICAgICAgKDEgPDwgNCkKKyNkZWZp
bmUgTDJFX0VYVF9BUDEgICAgICAgICAgICAgKDIgPDwgNCkKKyNkZWZpbmUgTDJFX0VYVF9B
UF9VTk9fU1JPICAgICAgKDAgPDwgNCkKKyNkZWZpbmUgTDJFX0VYVF9BUF9VTk9fU1JXICAg
ICAgKEwyRV9FWFRfQVAwKQorI2RlZmluZSBMMkVfRVhUX0FQX1VST19TUlcgICAgICAoTDJF
X0VYVF9BUDEpCisjZGVmaW5lIEwyRV9FWFRfQVBfVVJXX1NSVyAgICAgIChMMkVfRVhUX0FQ
MXxMMkVfRVhUX0FQMCkKKyNkZWZpbmUgTDJFX0VYVF9URVgoeCkgICAgICAgICAgKCh4KSA8
PCA2KQorI2RlZmluZSBMMkVfRVhUX0FQWCAgICAgICAgICAgICAoMSA8PCA5KQorI2RlZmlu
ZSBMMkVfRVhUX0NPSEVSRU5UICAgICAgICAoMSA8PCA5KQorI2RlZmluZSBMMkVfRVhUX1NI
QVJFRCAgICAgICAgICAoMSA8PCAxMCkKKyNkZWZpbmUgTDJFX0VYVF9ORyAgICAgICAgICAg
ICAgKDEgPDwgMTEpCisKKworI2RlZmluZSBMMV9UQUJMRV9FTlRSSUVTCSg0MDk2KQorI2Rl
ZmluZSBMMl9UQUJMRV9FTlRSSUVTCSgyNTYpCisKKyNkZWZpbmUgTDFfVEFCTEVfU0laRQkJ
KDB4NDAwMCkKKworI2RlZmluZSBMMkVfR1VFU1RfQVBfTUFTSyAgICAgICBMMkVfRVhUX0FQ
X01BU0sKKyNkZWZpbmUgTDJFX0dVRVNUX0FQX05PICAgICAgICAgTDJFX0VYVF9BUF9VTk9f
U1JXCisjZGVmaW5lIEwyRV9HVUVTVF9BUF9STyAgICAgICAgIEwyRV9FWFRfQVBfVVJPX1NS
VworI2RlZmluZSBMMkVfR1VFU1RfQVBfUlcgICAgICAgICBMMkVfRVhUX0FQX1VSV19TUlcK
KworI2RlZmluZSBMMUVfR1VFU1RfVEFCTEUgICAgICAgICAoTDFFX0RPTUFJTl9TVkMgfCBM
MUVfVFlQRV9UQUJMRSkKKyNkZWZpbmUgTDFFX1ZFQ1RPUl9UQUJMRSAgICAgICAgKEwxRV9E
T01BSU5fU1ZDIHwgTDFFX1RZUEVfVEFCTEUpCisKKyNkZWZpbmUgTDJFX0dVRVNUX1BBR0Ug
ICAgICAgICAgKEwyRV9FWFRfU0hBUkVEIHwgTDJFX0dVRVNUX0FQX1JXIHwgTDJFX0VYVF9U
RVgoMSkgfCBMMkVfQlVGRkVSQUJMRSB8IEwyRV9DQUNIRUFCTEUgfCBMMkVfVFlQRV9FWFQp
CisKKyNkZWZpbmUgTDJFX1ZFQ1RPUl9QQUdFICAgICAgICAgKEwyRV9HVUVTVF9BUF9STyB8
IEwyRV9FWFRfVEVYKDEpIHwgTDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJF
X1RZUEVfRVhUKQorI2RlZmluZSBMMkVfR1JBTlRfUEFHRQkJKEwyRV9UWVBFX0VYVCB8IEwy
RV9FWFRfU0hBUkVEIHwgTDJFX0VYVF9URVgoMSkgfCBMMkVfQlVGRkVSQUJMRSB8IEwyRV9D
QUNIRUFCTEUgfCBMMkVfR1VFU1RfQVBfUlcpCisjZGVmaW5lIEwyRV9TSEFSRURfSU5GTwkJ
KEwyRV9UWVBFX0VYVCB8IEwyRV9FWFRfVEVYKDEpIHwgTDJFX0VYVF9YTiB8IEwyRV9FWFRf
U0hBUkVEIHwgTDJFX0JVRkZFUkFCTEUgfCBMMkVfQ0FDSEVBQkxFIHwgTDJFX0dVRVNUX0FQ
X1JXKQorI2RlZmluZSBMMkVfREVWSUNFCQkoTDJFX1RZUEVfRVhUIHwgTDJFX0VYVF9URVgo
MSkgfCBMMkVfRVhUX1hOIHwgTDJFX0VYVF9TSEFSRUQgfCBMMkVfR1VFU1RfQVBfUlcpCisK
ICNkZWZpbmUgUEFERFJfQklUUyAgICAgICAgICAgICAgMzIKICNkZWZpbmUgUEFERFJfTUFT
SyAgICAgICAgICAgICAgKCgxVUwgPDwgUEFERFJfQklUUykgLSAxKQogCiAjZGVmaW5lIFZB
RERSX0JJVFMgICAgICAgICAgICAgIDMyCiAjZGVmaW5lIFZBRERSX01BU0sgICAgICAgICAg
ICAgICgoMVVMIDw8IFZBRERSX0JJVFMpIC0gMSkKIAorI2RlZmluZSBUVEJfUyAgICAgICAg
ICAgKDEgPDwgMSkKKyNkZWZpbmUgVFRCX1JHTl9OQyAgICAgICgwIDw8IDMpCisjZGVmaW5l
IFRUQl9SR05fT0NfV0JXQSAoMSA8PCAzKQorI2RlZmluZSBUVEJfUkdOX09DX1dUICAgKDIg
PDwgMykKKyNkZWZpbmUgVFRCX1JHTl9PQ19XQiAgICgzIDw8IDMpCisjZGVmaW5lIFRUQl9O
T1MgICAgICAgICAoMSA8PCA1KQorI2RlZmluZSBUVEJfSVJHTl9OQyAgICAgKCgwIDw8IDAp
IHwgKDAgPDwgNikpCisjZGVmaW5lIFRUQl9JUkdOX1dCV0EgICAoKDAgPDwgMCkgfCAoMSA8
PCA2KSkKKyNkZWZpbmUgVFRCX0lSR05fV1QgICAgICgoMSA8PCAwKSB8ICgwIDw8IDYpKQor
I2RlZmluZSBUVEJfSVJHTl9XQiAgICAgKCgxIDw8IDApIHwgKDEgPDwgNikpCisKKworI2Rl
ZmluZSBUVEJfRkxBR1MgICAgICAgICAgICAgICAoVFRCX0lSR05fV0JXQSB8IFRUQl9TIHwg
VFRCX05PUyB8IFRUQl9SR05fT0NfV0JXQSkKKworI2RlZmluZSBUVEJfTUFTSwkJKH4weDNG
RkYpCisKKyNpZm5kZWYgX19BU1NFTUJMWV9fCisKKyNpbmNsdWRlIDxhc20vdHlwZXMuaD4K
KworI2RlZmluZSBsMmVfdmFsKHgpICAgICAgICAgICAgICAoKHgpLmwyZSkKKyNkZWZpbmUg
bDFlX3ZhbCh4KSAgICAgICAgICAgICAgKCh4KS5sMWUpCisKKyNkZWZpbmUgTUtfTDJFKHgs
IGZsYWdzKQkoKGwyZV90KSB7ICgodW5zaWduZWQgbG9uZykoeCkgJiAofkwyRV9GTEFHX01B
U0spKSB8IGZsYWdzIH0gKQorI2RlZmluZSBNS19MMUUoeCwgZmxhZ3MpCSgobDFlX3QpIHsg
KCh1bnNpZ25lZCBsb25nKSh4KSAmICh+TDFFX0ZMQUdfTUFTSykpIHwgZmxhZ3MgfSApCisK
KyNkZWZpbmUgbDF0X2luZGV4KHgpCQkoKCh1bnNpZ25lZCBsb25nKSh4KSA+PiBMMUVfU0hJ
RlQpICYgKEwxX1RBQkxFX0VOVFJJRVMgLSAxKSkKKyNkZWZpbmUgbDJ0X2luZGV4KHgpCQko
KCh1bnNpZ25lZCBsb25nKSh4KSA+PiBMMkVfU0hJRlQpICYgKEwyX1RBQkxFX0VOVFJJRVMg
LSAxKSkKKworI2RlZmluZSBsMV9saW5lYXJfb2Zmc2V0X3hlbih2YSkJXAorCShsMV9saW5l
YXJfb2Zmc2V0KCh4ZW5fdHJhbnNsYXRpb25fdGFibGUpLCB2YSkpCisKK3R5cGVkZWYgc3Ry
dWN0IHsgdW5zaWduZWQgbG9uZyBsMmU7IH0gbDJlX3Q7Cit0eXBlZGVmIHN0cnVjdCB7IHVu
c2lnbmVkIGxvbmcgbDFlOyB9IGwxZV90OworCitzdGF0aWMgaW5saW5lIGwxZV90ICpsMV9s
aW5lYXJfb2Zmc2V0KGwxZV90ICpsMWUsIHVuc2lnbmVkIGxvbmcgdmlydCkKK3sKKwlyZXR1
cm4gbDFlICsgbDF0X2luZGV4KHZpcnQpOworfQorCitzdGF0aWMgaW5saW5lIGwyZV90ICps
Ml9saW5lYXJfb2Zmc2V0KGwxZV90ICpsMWUsIHVuc2lnbmVkIGxvbmcgdmlydCkKK3sKKyAg
ICAgICAgbDJlX3QgKmwyZTsKKworICAgICAgICBsMmUgPSAobDJlX3QgKikgKGwxZV92YWwo
KmwxZSkgJiB+TDFFX0ZMQUdfTUFTSyk7CisgICAgICAgIGwyZSA9IGwyZSArIGwydF9pbmRl
eCh2aXJ0KTsKKworICAgICAgICByZXR1cm4gbDJlOworfQorCitzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBnZXRfZGFjcih2b2lkKQoreworCXVuc2lnbmVkIGludCB2YWw7CisKKwlh
c20oIm1yYyBwMTUsIDAsICUwLCBjMywgYzAsIDAiIDogIj1yIiAodmFsKSA6IDogImNjIik7
CisKKwlyZXR1cm4gdmFsOworfQorCisKK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfZGFjcih1
bnNpZ25lZCBsb25nIHZhbCkKK3sKKwlhc20oIm1yYyBwMTUsIDAsICUwLCBjMywgYzAsIDAi
IDogIj1yIiAodmFsKSA6IDogImNjIik7Cit9CisKKworc3RhdGljIGlubGluZSB1bnNpZ25l
ZCBpbnQgZ2V0X3R0YnIodm9pZCkKK3sKKwl1bnNpZ25lZCBpbnQgdmFsOworCQorCWFzbSgi
bXJjIHAxNSwgMCwgJTAsIGMyLCBjMCwgMCIgOiAiPXIiICh2YWwpIDogOiAiY2MiKTsKKwor
CXJldHVybiB2YWw7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfdHRicih1bnNpZ25l
ZCBpbnQgdHRiKQoreworCWFzbSB2b2xhdGlsZSgibWNyIHAxNSwgMCwgJTAsIGMyLCBjMCwg
MCIgOiA6ICJyIiAodHRiKSA6ICJjYyIpOworCisJaXNiKCk7Cit9CisKK3N0YXRpYyBpbmxp
bmUgdm9pZCBzZXRfY29udGV4dGlkcih1bnNpZ25lZCBsb25nIGlkKQoreworCWFzbSgibWNy
ICAgICBwMTUsIDAsICUwLCBjMTMsIGMwLCAxIiA6IDogInIiIChpZCkgOiAiY2MiKTsKK30K
Kworc3RhdGljIGlubGluZSB1bnNpZ25lZCBpbnQgZ2V0X2NvbnRleHRpZHIodm9pZCkKK3sK
Kwl1bnNpZ25lZCBpbnQgdmFsOworCQorCWFzbSgibXJjIHAxNSwgMCwgJTAsIGMxMywgYzAs
IDEiIDogIj1yIiAodmFsKSA6IDogImNjIik7CisKKwlyZXR1cm4gdmFsOworfQorCisjZW5k
aWYKICNlbmRpZgogCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt19-00060g-Le; Mon, 13 Feb 2012 10:20:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqvu-00045e-UX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:06:47 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329120397!13098982!1
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10304 invoked from network); 13 Feb 2012 08:06:39 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-5.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 08:06:39 -0000
Received: from epcpsbge1.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB0031NNPLNF70@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:06:36 +0900 (KST)
Message-id: <0LZB003ABNV0NF70@mailout1.samsung.com>
X-AuditID: cbfee60b-b7be6ae000004638-87-4f38c48c4e2f
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge1.samsung.com (EPCPMTA) with SMTP id D2.F6.17976.C84C83F4;
	Mon, 13 Feb 2012 17:06:36 +0900 (KST)
Date: Mon, 13 Feb 2012 08:06:36 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080544603@jm77.ryu
Msgkey: 20120213080544603@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080444730@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 14/14] arm: implement basic interrupt handling
	mechanism.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <22301297.70441329120392655.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgYmFzaWMgaW50ZXJydXB0IGhhbmRsaW5nIG1lY2hhbmlzbS4NCg0KIHhl
bi9hcmNoL2FybS90ZWdyYS90ZWdyYTI1MC5jIHwgICAgOSArKystDQogeGVuL2FyY2gvYXJtL3hl
bi9jcHUuYyAgICAgICAgfCAgICA0ICstDQogeGVuL2FyY2gvYXJtL3hlbi9pcnEuYyAgICAgICAg
fCAgMjAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLQ0KIDMgZmlsZXMgY2hhbmdlZCwg
MjA0IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQ0KDQpTaWduZWQtb2ZmLWJ5OiBKYWVt
aW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCg0KZGlmZiAtciAzZjFlNjRhOGY2MWEgeGVu
L2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMNCi0tLSBhL3hlbi9hcmNoL2FybS90ZWdyYS90ZWdy
YTI1MC5jCVN1biBGZWIgMTIgMTU6NDk6MTIgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJt
L3RlZ3JhL3RlZ3JhMjUwLmMJU3VuIEZlYiAxMiAxNjoxMjozOCAyMDEyICswOTAwDQpAQCAtMjQ1
LDEzICsyNDUsMjAgQEAgYXNtKA0KICIJLmxvbmcJdGVncmEyNTBfY29yZV9tYXAJCVxuIg0KICk7
DQogDQordm9pZCBtYWNoaW5lX3RyaWdnZXJfY3B1cyh1bnNpZ25lZCBsb25nIGNwdV9tYXAsIHVu
c2lnbmVkIGludCBldmVudCkNCit7DQorICAgICAgICBtbWlvX3dyaXRlbChjcHVfbWFwIDw8IDE2
IHwgZXZlbnQsIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNEU0dJUik7DQorfQ0KKw0KIGludCB3
YWtldXBfY3B1KHVuc2lnbmVkIGludCBjcHUpDQogew0KIAl0ZWdyYTI1MF9jb3JlX21hcCB8PSAx
IDw8ICBjcHU7DQogDQogCWNwdV9mbHVzaF9jYWNoZV9hbGwoKTsNCiANCi0JcmV0dXJuIDA7DQor
CW1hY2hpbmVfdHJpZ2dlcl9jcHVzKHRlZ3JhMjUwX2NvcmVfbWFwLCAxKTsNCisNCisJcmV0dXJu
IDE7DQogfQ0KIA0KIGV4dGVybiB2b2lkIHRlZ3JhMjUwX3NsYXZlX2NwdV9zdGFydCh2b2lkKTsN
CmRpZmYgLXIgM2YxZTY0YThmNjFhIHhlbi9hcmNoL2FybS94ZW4vY3B1LmMNCi0tLSBhL3hlbi9h
cmNoL2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxNTo0OToxMiAyMDEyICswOTAwDQorKysgYi94
ZW4vYXJjaC9hcm0veGVuL2NwdS5jCVN1biBGZWIgMTIgMTY6MTI6MzggMjAxMiArMDkwMA0KQEAg
LTExNiw2ICsxMTYsOCBAQCBhc21saW5rYWdlIHZvaWQgc3RhcnRfeGVuX29uX3NsYXZlX2NwdSh2
DQogICAgICAgICB2ID0gaWRsZV92Y3B1W2NwdV07DQogCXNldF9jdXJyZW50KGlkbGVfdmNwdVtj
cHVdKTsNCiANCisJVkNQVV9SRUcodiwgdHRicjApID0gZ2V0X3R0YnIoKTsNCisNCiAJc2V0X2Nw
dV9zaWJsaW5nX21hcChjcHUpOw0KIA0KIAlub3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7DQpAQCAt
MTM5LDcgKzE0MSw3IEBAIHZvaWQgc21wX3NlbmRfZXZlbnRfY2hlY2tfbWFzayhjb25zdCBjcHUN
CiAJCW1hcCB8PSAxIDw8IGNwdTsNCiAJfQ0KIA0KLQkvKiBUcmlnZ2VyIHJlbW90ZSBDUFUgKi8N
CisJbWFjaGluZV90cmlnZ2VyX2NwdXMobWFwLCAxKTsNCiB9DQogDQogdm9pZCBzbXBfY2FsbF9m
dW5jdGlvbih2b2lkICgqZikodm9pZCAqcGFyYW0pLCB2b2lkICpwYXJhbSwgaW50IHdhaXQpDQpk
aWZmIC1yIDNmMWU2NGE4ZjYxYSB4ZW4vYXJjaC9hcm0veGVuL2lycS5jDQotLS0gYS94ZW4vYXJj
aC9hcm0veGVuL2lycS5jCVN1biBGZWIgMTIgMTU6NDk6MTIgMjAxMiArMDkwMA0KKysrIGIveGVu
L2FyY2gvYXJtL3hlbi9pcnEuYwlTdW4gRmViIDEyIDE2OjEyOjM4IDIwMTIgKzA5MDANCkBAIC00
Miw4ICs0Miw2IEBAIGh3X2lycV9jb250cm9sbGVyIG5vX2lycV90eXBlID0gew0KIAkuYWNrCSAg
PSBpcnFfYWNrX25vbmUsDQogfTsNCiANCi0vL3N0cnVjdCBpcnFfZGVzYyAqaXJxX2Rlc2M7DQot
DQogaXJxX2Rlc2NfdCBpcnFfZGVzY1tOUl9JUlFTXSA9IHsNCiAgICAgICAgIFswIC4uLiBOUl9J
UlFTIC0gMV0gPSB7DQogICAgICAgICAgICAgICAgIC5zdGF0dXMgPSBJUlFfRElTQUJMRUQsDQpA
QCAtNjAsNiArNTgsMzggQEAgc3RydWN0IGlycV9jZmcgaXJxX2NmZ1tOUl9JUlFTXSA9IHsNCiB9
Ow0KIA0KIA0KK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfcGlycV9lb2koc3RydWN0IGRvbWFpbiAq
ZCwgdW5zaWduZWQgaW50IGlycSkNCit7DQorICAgICAgICBpZiAoZC0+YXJjaC5waXJxX2VvaV9t
YXApIHsNCisgICAgICAgICAgICAgICAgc2V0X2JpdChpcnEsIGQtPmFyY2gucGlycV9lb2lfbWFw
KTsNCisgICAgICAgIH0NCit9DQorDQorc3RhdGljIGlubGluZSB2b2lkIGNsZWFyX3BpcnFfZW9p
KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBpcnEpDQorew0KKyAgICAgICAgaWYgKGQt
PmFyY2gucGlycV9lb2lfbWFwKSB7DQorICAgICAgICAgICAgICAgIGNsZWFyX2JpdChpcnEsIGQt
PmFyY2gucGlycV9lb2lfbWFwKTsNCisgICAgICAgIH0NCit9DQorDQordm9pZCBwaXJxX2d1ZXN0
X2VvaShzdHJ1Y3QgcGlycSAqcGlycSkNCit7DQorICAgICAgICBzdHJ1Y3QgaXJxX2Rlc2MgKmRl
c2M7DQorICAgICAgICB1bnNpZ25lZCBpbnQgZmxhZ3M7DQorDQorICAgICAgICBpZiAocGlycS0+
cGlycSA+PSBOUl9JUlFTKSB7DQorICAgICAgICAgICAgICAgIHJldHVybjsNCisgICAgICAgIH0N
CisNCisgICAgICAgIGRlc2MgPSBpcnFfdG9fZGVzYyhwaXJxLT5waXJxKTsNCisgICAgICAgIHNw
aW5fbG9ja19pcnFzYXZlKCZkZXNjLT5sb2NrLCBmbGFncyk7DQorDQorICAgICAgICBkZXNjLT5o
YW5kbGVyLT5lbmQoZGVzYyk7DQorDQorICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZk
ZXNjLT5sb2NrLCBmbGFncyk7DQorfQ0KKw0KKw0KIGludCBwaXJxX2d1ZXN0X3VubWFzayhzdHJ1
Y3QgZG9tYWluICpkKQ0KIHsNCiAJTk9UX1lFVCgpOw0KQEAgLTY3LDE2ICs5NywxMDUgQEAgaW50
IHBpcnFfZ3Vlc3RfdW5tYXNrKHN0cnVjdCBkb21haW4gKmQpDQogCXJldHVybiAwOw0KIH0NCiAN
CisNCiBpbnQgcGlycV9ndWVzdF9iaW5kKHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgcGlycSAqcGly
cSwgaW50IHdpbGxfc2hhcmUpDQogew0KLQlOT1RfWUVUKCk7DQorICAgICAgICBpbnQgcmMgPSAw
Ow0KKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOw0KKyAgICAgICAgaXJxX2d1ZXN0X2Fj
dGlvbl90ICphY3Rpb247DQorICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyAgICAgICAg
dW5zaWduZWQgaW50IGlycTsNCiANCi0JcmV0dXJuIDA7DQorICAgICAgICBpcnEgPSBwaXJxLT5w
aXJxOw0KKw0KKyAgICAgICAgaWYgKGlycSA+PSBOUl9JUlFTKSB7DQorICAgICAgICAgICAgICAg
IHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgZGVzYyA9IGlycV90b19k
ZXNjKGlycSk7DQorDQorICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxh
Z3MpOw0KKw0KKyAgICAgICAgaWYgKCEoZGVzYy0+c3RhdHVzICYgSVJRX0dVRVNUKSkgew0KKyAg
ICAgICAgICAgICAgICBpZiAoZGVzYy0+YWN0aW9uICE9IE5VTEwpIHsNCisgICAgICAgICAgICAg
ICAgICAgICAgICByYyA9IC1FQlVTWTsNCisgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIG91
dDsNCisgICAgICAgICAgICAgICAgfQ0KKw0KKyAgICAgICAgICAgICAgICBhY3Rpb24gPSB4bWFs
bG9jKGlycV9ndWVzdF9hY3Rpb25fdCk7DQorICAgICAgICAgICAgICAgIGlmICgoZGVzYy0+YWN0
aW9uID0gKHN0cnVjdCBpcnFhY3Rpb24gKilhY3Rpb24pID09IE5VTEwgKSB7DQorICAgICAgICAg
ICAgICAgICAgICAgICAgcmMgPSAtRU5PTUVNOw0KKyAgICAgICAgICAgICAgICAgICAgICAgIGdv
dG8gb3V0Ow0KKyAgICAgICAgICAgICAgICB9DQorDQorICAgICAgICAgICAgICAgIGFjdGlvbi0+
c2hhcmVhYmxlID0gMTsNCisgICAgICAgICAgICAgICAgYWN0aW9uLT5ucl9ndWVzdHMgPSAwOw0K
KyAgICAgICAgICAgICAgICBhY3Rpb24tPmluX2ZsaWdodCA9IDA7DQorDQorICAgICAgICAgICAg
ICAgIGRlc2MtPnN0YXR1cyB8PSBJUlFfR1VFU1Q7DQorDQorICAgICAgICAgICAgICAgIGRlc2Mt
PmhhbmRsZXItPmVuYWJsZShkZXNjKTsNCisgICAgICAgIH0gZWxzZSBpZiAoIXdpbGxfc2hhcmUp
IHsNCisgICAgICAgICAgICAgICAgcmMgPSAtRUJVU1k7DQorICAgICAgICAgICAgICAgIGdvdG8g
b3V0Ow0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgaWYgKCBhY3Rpb24tPm5yX2d1ZXN0cyA9PSBJ
UlFfTUFYX0dVRVNUUyApIHsNCisgICAgICAgICAgICAgICAgcmMgPSAtRUJVU1k7DQorICAgICAg
ICAgICAgICAgIGdvdG8gb3V0Ow0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgYWN0aW9uLT5ndWVz
dFthY3Rpb24tPm5yX2d1ZXN0cysrXSA9IHYtPmRvbWFpbjsNCisNCitvdXQ6DQorICAgICAgICBz
cGluX3VubG9ja19pcnFyZXN0b3JlKCZkZXNjLT5sb2NrLCBmbGFncyk7DQorDQorICAgICAgICBy
ZXR1cm4gcmM7Ow0KIH0NCiANCiB2b2lkIHBpcnFfZ3Vlc3RfdW5iaW5kKHN0cnVjdCBkb21haW4g
KmQsIHN0cnVjdCBwaXJxICpwaXJxKQ0KIHsNCi0JTk9UX1lFVCgpOw0KKyAgICAgICAgc3RydWN0
IGlycV9kZXNjICpkZXNjOw0KKyAgICAgICAgdW5zaWduZWQgaW50IGZsYWdzLCBpcnEsIGk7DQor
ICAgICAgICBpcnFfZ3Vlc3RfYWN0aW9uX3QgKmFjdGlvbjsNCisNCisgICAgICAgIGlycSA9IHBp
cnEtPnBpcnE7DQorDQorICAgICAgICBpZiAoaXJxID49IE5SX0lSUVMpIHsNCisgICAgICAgICAg
ICAgICAgcmV0dXJuOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgZGVzYyA9IGlycV90b19kZXNj
KGlycSk7DQorDQorICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3Mp
Ow0KKw0KKyAgICAgICAgYWN0aW9uID0gKGlycV9ndWVzdF9hY3Rpb25fdCAqKWRlc2MtPmFjdGlv
bjsNCisNCisgICAgICAgIGlmICh1bmxpa2VseShhY3Rpb24gPT0gTlVMTCkpIHsNCisgICAgICAg
ICAgICAgICAgd2hpbGUoMSk7DQorICAgICAgICB9DQorDQorICAgICAgICBCVUdfT04oIShkZXNj
LT5zdGF0dXMgJiBJUlFfR1VFU1QpKTsNCisNCisNCisgICAgICAgIGlmICggYWN0aW9uLT5ucl9n
dWVzdHMgPT0gMSApIHsNCisgICAgICAgICAgICAgICAgZGVzYy0+YWN0aW9uID0gTlVMTDsNCisg
ICAgICAgICAgICAgICAgeGZyZWUoYWN0aW9uKTsNCisNCisgICAgICAgICAgICAgICAgZGVzYy0+
c3RhdHVzICY9IH5JUlFfR1VFU1Q7DQorICAgICAgICB9IGVsc2Ugew0KKyAgICAgICAgICAgICAg
ICBpID0gMDsNCisgICAgICAgICAgICAgICAgd2hpbGUgKCBhY3Rpb24tPmd1ZXN0W2ldICYmIChh
Y3Rpb24tPmd1ZXN0W2ldICE9IGQpICkNCisgICAgICAgICAgICAgICAgICAgICAgICBpKys7DQor
ICAgICAgICAgICAgICAgIG1lbW1vdmUoJmFjdGlvbi0+Z3Vlc3RbaV0sICZhY3Rpb24tPmd1ZXN0
W2krMV0sIChhY3Rpb24tPm5yX2d1ZXN0cyAtIGkgLSAxKSAqIHNpemVvZihhY3Rpb24tPmd1ZXN0
WzBdKSk7DQorICAgICAgICAgICAgICAgIGFjdGlvbi0+bnJfZ3Vlc3RzLS07DQorICAgICAgICB9
DQorDQorICAgICAgICBkZXNjLT5zdGF0dXMgfD0gSVJRX0RJU0FCTEVEOw0KKw0KKyAgICAgICAg
ZGVzYy0+aGFuZGxlci0+ZGlzYWJsZShkZXNjKTsNCisNCisgICAgICAgIHNwaW5fdW5sb2NrX2ly
cXJlc3RvcmUoJmRlc2MtPmxvY2ssIGZsYWdzKTsNCiB9DQogDQogDQpAQCAtODUsMTIgKzIwNCwx
NyBAQCB2b2lkIHBpcnFfc2V0X2FmZmluaXR5KHN0cnVjdCBkb21haW4gKmQsDQogCU5PVF9ZRVQo
KTsNCiB9DQogDQotDQogc3RydWN0IHBpcnEgKmFsbG9jX3BpcnFfc3RydWN0KHN0cnVjdCBkb21h
aW4gKmQpDQogew0KLQlOT1RfWUVUKCk7DQorICAgICAgICBzdHJ1Y3QgcGlycSAqcGlycTsNCiAN
Ci0JcmV0dXJuIE5VTEw7DQorICAgICAgICBwaXJxID0geG1hbGxvYyhzdHJ1Y3QgcGlycSk7DQor
DQorICAgICAgICBpZiAoIXBpcnEpIHsNCisgICAgICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQor
ICAgICAgICB9DQorDQorICAgICAgICByZXR1cm4gcGlycTsNCiB9DQogDQogaW50IHNldHVwX2ly
cSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1Y3QgaXJxYWN0aW9uICpuZXcpDQpAQCAtMTE5LDYgKzI0
Myw2NyBAQCBpbnQgc2V0dXBfaXJxKHVuc2lnbmVkIGludCBpcnEsIHN0cnVjdCBpDQogCXJldHVy
biAwOw0KIH0NCiANCit2b2lkIGRvX2d1ZXN0X2lycSh1bnNpZ25lZCBpbnQgaXJxKQ0KK3sNCisg
ICAgICAgIGludCBpOw0KKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOw0KKyAgICAgICAg
c3RydWN0IGRvbWFpbiAqZDsNCisgICAgICAgIHN0cnVjdCBwaXJxICpwaXJxOw0KKw0KKyAgICAg
ICAgaXJxX2d1ZXN0X2FjdGlvbl90ICphY3Rpb247DQorDQorICAgICAgICBkZXNjID0gaXJxX3Rv
X2Rlc2MoaXJxKTsNCisNCisgICAgICAgIGFjdGlvbiA9IChpcnFfZ3Vlc3RfYWN0aW9uX3QgKilk
ZXNjLT5hY3Rpb247DQorICAgICAgICBmb3IgKGkgPSAwOyBpIDwgYWN0aW9uLT5ucl9ndWVzdHM7
IGkrKykgew0KKyAgICAgICAgICAgICAgICBkID0gYWN0aW9uLT5ndWVzdFtpXTsNCisgICAgICAg
ICAgICAgICAgcGlycSA9IHBpcnFfaW5mbyhkLCBpcnEpOw0KKyAgICAgICAgICAgICAgICBhY3Rp
b24tPmluX2ZsaWdodCsrOw0KKyAgICAgICAgICAgICAgICBzZW5kX2d1ZXN0X3BpcnEoZCwgcGly
cSk7DQorICAgICAgICB9DQorDQorDQorfQ0KKw0KK2FzbWxpbmthZ2Ugdm9pZCBkb19pcGkodW5z
aWduZWQgaW50IGlwaSwgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQorew0KK30NCisNCith
c21saW5rYWdlIHZvaWQgZG9faXJxKHVuc2lnbmVkIGludCBpcnEsIHN0cnVjdCBjcHVfdXNlcl9y
ZWdzICpyZWdzKQ0KK3sNCisgICAgICAgIHN0cnVjdCBpcnFfZGVzYyAqZGVzYzsNCisgICAgICAg
IHN0cnVjdCBpcnFhY3Rpb24gKmFjdGlvbjsNCisNCisgICAgICAgIGlmIChpcnEgPj0gTlJfSVJR
Uykgew0KKyAgICAgICAgICAgICAgICBwcmludGsoIkJhZCBJUlEgPSAlZFxuIiwgaXJxKTsNCisg
ICAgICAgIH0NCisNCisgICAgICAgIGRlc2MgPSBpcnFfdG9fZGVzYyhpcnEpOw0KKw0KKyAgICAg
ICAgc3Bpbl9sb2NrKCZkZXNjLT5sb2NrKTsNCisNCisgICAgICAgIGRlc2MtPmhhbmRsZXItPmFj
ayhkZXNjKTsNCisNCisNCisgICAgICAgIGlmIChsaWtlbHkoZGVzYy0+c3RhdHVzICYgSVJRX0dV
RVNUKSkgew0KKyAgICAgICAgICAgICAgICBkb19ndWVzdF9pcnEoaXJxKTsNCisgICAgICAgICAg
ICAgICAgc3Bpbl91bmxvY2soJmRlc2MtPmxvY2spOw0KKw0KKyAgICAgICAgICAgICAgICByZXR1
cm47DQorICAgICAgICB9DQorDQorICAgICAgICBhY3Rpb24gPSBkZXNjLT5hY3Rpb247DQorDQor
ICAgICAgICBCVUdfT04oIWFjdGlvbik7DQorDQorICAgICAgICBzcGluX3VubG9jaygmZGVzYy0+
bG9jayk7DQorDQorICAgICAgICBhY3Rpb24tPmhhbmRsZXIoaXJxLCBhY3Rpb24tPmRldl9pZCwg
cmVncyk7DQorDQorICAgICAgICBkZXNjLT5oYW5kbGVyLT5lbmQoZGVzYyk7DQorfQ0KKw0KKw0K
IGludCBhcmNoX2luaXRfb25lX2lycV9kZXNjKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQog
CU5PVF9ZRVQoKTsNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch14.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch14.diff"


YXJtOiBpbXBsZW1lbnQgYmFzaWMgaW50ZXJydXB0IGhhbmRsaW5nIG1lY2hhbmlzbS4KCiB4
ZW4vYXJjaC9hcm0vdGVncmEvdGVncmEyNTAuYyB8ICAgIDkgKysrLQogeGVuL2FyY2gvYXJt
L3hlbi9jcHUuYyAgICAgICAgfCAgICA0ICstCiB4ZW4vYXJjaC9hcm0veGVuL2lycS5jICAg
ICAgICB8ICAyMDEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tCiAzIGZpbGVz
IGNoYW5nZWQsIDIwNCBpbnNlcnRpb25zKCspLCAxMCBkZWxldGlvbnMoLSkKClNpZ25lZC1v
ZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciAzZjFl
NjRhOGY2MWEgeGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMKLS0tIGEveGVuL2FyY2gv
YXJtL3RlZ3JhL3RlZ3JhMjUwLmMJU3VuIEZlYiAxMiAxNTo0OToxMiAyMDEyICswOTAwCisr
KyBiL3hlbi9hcmNoL2FybS90ZWdyYS90ZWdyYTI1MC5jCVN1biBGZWIgMTIgMTY6MTI6Mzgg
MjAxMiArMDkwMApAQCAtMjQ1LDEzICsyNDUsMjAgQEAgYXNtKAogIgkubG9uZwl0ZWdyYTI1
MF9jb3JlX21hcAkJXG4iCiApOwogCit2b2lkIG1hY2hpbmVfdHJpZ2dlcl9jcHVzKHVuc2ln
bmVkIGxvbmcgY3B1X21hcCwgdW5zaWduZWQgaW50IGV2ZW50KQoreworICAgICAgICBtbWlv
X3dyaXRlbChjcHVfbWFwIDw8IDE2IHwgZXZlbnQsIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBf
SUNEU0dJUik7Cit9CisKIGludCB3YWtldXBfY3B1KHVuc2lnbmVkIGludCBjcHUpCiB7CiAJ
dGVncmEyNTBfY29yZV9tYXAgfD0gMSA8PCAgY3B1OwogCiAJY3B1X2ZsdXNoX2NhY2hlX2Fs
bCgpOwogCi0JcmV0dXJuIDA7CisJbWFjaGluZV90cmlnZ2VyX2NwdXModGVncmEyNTBfY29y
ZV9tYXAsIDEpOworCisJcmV0dXJuIDE7CiB9CiAKIGV4dGVybiB2b2lkIHRlZ3JhMjUwX3Ns
YXZlX2NwdV9zdGFydCh2b2lkKTsKZGlmZiAtciAzZjFlNjRhOGY2MWEgeGVuL2FyY2gvYXJt
L3hlbi9jcHUuYwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2NwdS5jCVN1biBGZWIgMTIgMTU6
NDk6MTIgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NwdS5jCVN1biBGZWIg
MTIgMTY6MTI6MzggMjAxMiArMDkwMApAQCAtMTE2LDYgKzExNiw4IEBAIGFzbWxpbmthZ2Ug
dm9pZCBzdGFydF94ZW5fb25fc2xhdmVfY3B1KHYKICAgICAgICAgdiA9IGlkbGVfdmNwdVtj
cHVdOwogCXNldF9jdXJyZW50KGlkbGVfdmNwdVtjcHVdKTsKIAorCVZDUFVfUkVHKHYsIHR0
YnIwKSA9IGdldF90dGJyKCk7CisKIAlzZXRfY3B1X3NpYmxpbmdfbWFwKGNwdSk7CiAKIAlu
b3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7CkBAIC0xMzksNyArMTQxLDcgQEAgdm9pZCBzbXBf
c2VuZF9ldmVudF9jaGVja19tYXNrKGNvbnN0IGNwdQogCQltYXAgfD0gMSA8PCBjcHU7CiAJ
fQogCi0JLyogVHJpZ2dlciByZW1vdGUgQ1BVICovCisJbWFjaGluZV90cmlnZ2VyX2NwdXMo
bWFwLCAxKTsKIH0KIAogdm9pZCBzbXBfY2FsbF9mdW5jdGlvbih2b2lkICgqZikodm9pZCAq
cGFyYW0pLCB2b2lkICpwYXJhbSwgaW50IHdhaXQpCmRpZmYgLXIgM2YxZTY0YThmNjFhIHhl
bi9hcmNoL2FybS94ZW4vaXJxLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9pcnEuYwlTdW4g
RmViIDEyIDE1OjQ5OjEyIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9pcnEu
YwlTdW4gRmViIDEyIDE2OjEyOjM4IDIwMTIgKzA5MDAKQEAgLTQyLDggKzQyLDYgQEAgaHdf
aXJxX2NvbnRyb2xsZXIgbm9faXJxX3R5cGUgPSB7CiAJLmFjawkgID0gaXJxX2Fja19ub25l
LAogfTsKIAotLy9zdHJ1Y3QgaXJxX2Rlc2MgKmlycV9kZXNjOwotCiBpcnFfZGVzY190IGly
cV9kZXNjW05SX0lSUVNdID0gewogICAgICAgICBbMCAuLi4gTlJfSVJRUyAtIDFdID0gewog
ICAgICAgICAgICAgICAgIC5zdGF0dXMgPSBJUlFfRElTQUJMRUQsCkBAIC02MCw2ICs1OCwz
OCBAQCBzdHJ1Y3QgaXJxX2NmZyBpcnFfY2ZnW05SX0lSUVNdID0gewogfTsKIAogCitzdGF0
aWMgaW5saW5lIHZvaWQgc2V0X3BpcnFfZW9pKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVk
IGludCBpcnEpCit7CisgICAgICAgIGlmIChkLT5hcmNoLnBpcnFfZW9pX21hcCkgeworICAg
ICAgICAgICAgICAgIHNldF9iaXQoaXJxLCBkLT5hcmNoLnBpcnFfZW9pX21hcCk7CisgICAg
ICAgIH0KK30KKworc3RhdGljIGlubGluZSB2b2lkIGNsZWFyX3BpcnFfZW9pKHN0cnVjdCBk
b21haW4gKmQsIHVuc2lnbmVkIGludCBpcnEpCit7CisgICAgICAgIGlmIChkLT5hcmNoLnBp
cnFfZW9pX21hcCkgeworICAgICAgICAgICAgICAgIGNsZWFyX2JpdChpcnEsIGQtPmFyY2gu
cGlycV9lb2lfbWFwKTsKKyAgICAgICAgfQorfQorCit2b2lkIHBpcnFfZ3Vlc3RfZW9pKHN0
cnVjdCBwaXJxICpwaXJxKQoreworICAgICAgICBzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2M7Cisg
ICAgICAgIHVuc2lnbmVkIGludCBmbGFnczsKKworICAgICAgICBpZiAocGlycS0+cGlycSA+
PSBOUl9JUlFTKSB7CisgICAgICAgICAgICAgICAgcmV0dXJuOworICAgICAgICB9CisKKyAg
ICAgICAgZGVzYyA9IGlycV90b19kZXNjKHBpcnEtPnBpcnEpOworICAgICAgICBzcGluX2xv
Y2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3MpOworCisgICAgICAgIGRlc2MtPmhhbmRs
ZXItPmVuZChkZXNjKTsKKworICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZkZXNj
LT5sb2NrLCBmbGFncyk7Cit9CisKKwogaW50IHBpcnFfZ3Vlc3RfdW5tYXNrKHN0cnVjdCBk
b21haW4gKmQpCiB7CiAJTk9UX1lFVCgpOwpAQCAtNjcsMTYgKzk3LDEwNSBAQCBpbnQgcGly
cV9ndWVzdF91bm1hc2soc3RydWN0IGRvbWFpbiAqZCkKIAlyZXR1cm4gMDsKIH0KIAorCiBp
bnQgcGlycV9ndWVzdF9iaW5kKHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgcGlycSAqcGlycSwg
aW50IHdpbGxfc2hhcmUpCiB7Ci0JTk9UX1lFVCgpOworICAgICAgICBpbnQgcmMgPSAwOwor
ICAgICAgICBzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2M7CisgICAgICAgIGlycV9ndWVzdF9hY3Rp
b25fdCAqYWN0aW9uOworICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOworICAgICAgICB1
bnNpZ25lZCBpbnQgaXJxOwogCi0JcmV0dXJuIDA7CisgICAgICAgIGlycSA9IHBpcnEtPnBp
cnE7CisKKyAgICAgICAgaWYgKGlycSA+PSBOUl9JUlFTKSB7CisgICAgICAgICAgICAgICAg
cmV0dXJuIC1FSU5WQUw7CisgICAgICAgIH0KKworICAgICAgICBkZXNjID0gaXJxX3RvX2Rl
c2MoaXJxKTsKKworICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxh
Z3MpOworCisgICAgICAgIGlmICghKGRlc2MtPnN0YXR1cyAmIElSUV9HVUVTVCkpIHsKKyAg
ICAgICAgICAgICAgICBpZiAoZGVzYy0+YWN0aW9uICE9IE5VTEwpIHsKKyAgICAgICAgICAg
ICAgICAgICAgICAgIHJjID0gLUVCVVNZOworICAgICAgICAgICAgICAgICAgICAgICAgZ290
byBvdXQ7CisgICAgICAgICAgICAgICAgfQorCisgICAgICAgICAgICAgICAgYWN0aW9uID0g
eG1hbGxvYyhpcnFfZ3Vlc3RfYWN0aW9uX3QpOworICAgICAgICAgICAgICAgIGlmICgoZGVz
Yy0+YWN0aW9uID0gKHN0cnVjdCBpcnFhY3Rpb24gKilhY3Rpb24pID09IE5VTEwgKSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICByYyA9IC1FTk9NRU07CisgICAgICAgICAgICAgICAg
ICAgICAgICBnb3RvIG91dDsKKyAgICAgICAgICAgICAgICB9CisKKyAgICAgICAgICAgICAg
ICBhY3Rpb24tPnNoYXJlYWJsZSA9IDE7CisgICAgICAgICAgICAgICAgYWN0aW9uLT5ucl9n
dWVzdHMgPSAwOworICAgICAgICAgICAgICAgIGFjdGlvbi0+aW5fZmxpZ2h0ID0gMDsKKwor
ICAgICAgICAgICAgICAgIGRlc2MtPnN0YXR1cyB8PSBJUlFfR1VFU1Q7CisKKyAgICAgICAg
ICAgICAgICBkZXNjLT5oYW5kbGVyLT5lbmFibGUoZGVzYyk7CisgICAgICAgIH0gZWxzZSBp
ZiAoIXdpbGxfc2hhcmUpIHsKKyAgICAgICAgICAgICAgICByYyA9IC1FQlVTWTsKKyAgICAg
ICAgICAgICAgICBnb3RvIG91dDsKKyAgICAgICAgfQorCisgICAgICAgIGlmICggYWN0aW9u
LT5ucl9ndWVzdHMgPT0gSVJRX01BWF9HVUVTVFMgKSB7CisgICAgICAgICAgICAgICAgcmMg
PSAtRUJVU1k7CisgICAgICAgICAgICAgICAgZ290byBvdXQ7CisgICAgICAgIH0KKworICAg
ICAgICBhY3Rpb24tPmd1ZXN0W2FjdGlvbi0+bnJfZ3Vlc3RzKytdID0gdi0+ZG9tYWluOwor
CitvdXQ6CisgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ssIGZs
YWdzKTsKKworICAgICAgICByZXR1cm4gcmM7OwogfQogCiB2b2lkIHBpcnFfZ3Vlc3RfdW5i
aW5kKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwaXJxICpwaXJxKQogewotCU5PVF9ZRVQo
KTsKKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOworICAgICAgICB1bnNpZ25lZCBp
bnQgZmxhZ3MsIGlycSwgaTsKKyAgICAgICAgaXJxX2d1ZXN0X2FjdGlvbl90ICphY3Rpb247
CisKKyAgICAgICAgaXJxID0gcGlycS0+cGlycTsKKworICAgICAgICBpZiAoaXJxID49IE5S
X0lSUVMpIHsKKyAgICAgICAgICAgICAgICByZXR1cm47CisgICAgICAgIH0KKworICAgICAg
ICBkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsKKworICAgICAgICBzcGluX2xvY2tfaXJxc2F2
ZSgmZGVzYy0+bG9jaywgZmxhZ3MpOworCisgICAgICAgIGFjdGlvbiA9IChpcnFfZ3Vlc3Rf
YWN0aW9uX3QgKilkZXNjLT5hY3Rpb247CisKKyAgICAgICAgaWYgKHVubGlrZWx5KGFjdGlv
biA9PSBOVUxMKSkgeworICAgICAgICAgICAgICAgIHdoaWxlKDEpOworICAgICAgICB9CisK
KyAgICAgICAgQlVHX09OKCEoZGVzYy0+c3RhdHVzICYgSVJRX0dVRVNUKSk7CisKKworICAg
ICAgICBpZiAoIGFjdGlvbi0+bnJfZ3Vlc3RzID09IDEgKSB7CisgICAgICAgICAgICAgICAg
ZGVzYy0+YWN0aW9uID0gTlVMTDsKKyAgICAgICAgICAgICAgICB4ZnJlZShhY3Rpb24pOwor
CisgICAgICAgICAgICAgICAgZGVzYy0+c3RhdHVzICY9IH5JUlFfR1VFU1Q7CisgICAgICAg
IH0gZWxzZSB7CisgICAgICAgICAgICAgICAgaSA9IDA7CisgICAgICAgICAgICAgICAgd2hp
bGUgKCBhY3Rpb24tPmd1ZXN0W2ldICYmIChhY3Rpb24tPmd1ZXN0W2ldICE9IGQpICkKKyAg
ICAgICAgICAgICAgICAgICAgICAgIGkrKzsKKyAgICAgICAgICAgICAgICBtZW1tb3ZlKCZh
Y3Rpb24tPmd1ZXN0W2ldLCAmYWN0aW9uLT5ndWVzdFtpKzFdLCAoYWN0aW9uLT5ucl9ndWVz
dHMgLSBpIC0gMSkgKiBzaXplb2YoYWN0aW9uLT5ndWVzdFswXSkpOworICAgICAgICAgICAg
ICAgIGFjdGlvbi0+bnJfZ3Vlc3RzLS07CisgICAgICAgIH0KKworICAgICAgICBkZXNjLT5z
dGF0dXMgfD0gSVJRX0RJU0FCTEVEOworCisgICAgICAgIGRlc2MtPmhhbmRsZXItPmRpc2Fi
bGUoZGVzYyk7CisKKyAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZGVzYy0+bG9j
aywgZmxhZ3MpOwogfQogCiAKQEAgLTg1LDEyICsyMDQsMTcgQEAgdm9pZCBwaXJxX3NldF9h
ZmZpbml0eShzdHJ1Y3QgZG9tYWluICpkLAogCU5PVF9ZRVQoKTsKIH0KIAotCiBzdHJ1Y3Qg
cGlycSAqYWxsb2NfcGlycV9zdHJ1Y3Qoc3RydWN0IGRvbWFpbiAqZCkKIHsKLQlOT1RfWUVU
KCk7CisgICAgICAgIHN0cnVjdCBwaXJxICpwaXJxOwogCi0JcmV0dXJuIE5VTEw7CisgICAg
ICAgIHBpcnEgPSB4bWFsbG9jKHN0cnVjdCBwaXJxKTsKKworICAgICAgICBpZiAoIXBpcnEp
IHsKKyAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsKKyAgICAgICAgfQorCisgICAgICAg
IHJldHVybiBwaXJxOwogfQogCiBpbnQgc2V0dXBfaXJxKHVuc2lnbmVkIGludCBpcnEsIHN0
cnVjdCBpcnFhY3Rpb24gKm5ldykKQEAgLTExOSw2ICsyNDMsNjcgQEAgaW50IHNldHVwX2ly
cSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1Y3QgaQogCXJldHVybiAwOwogfQogCit2b2lkIGRv
X2d1ZXN0X2lycSh1bnNpZ25lZCBpbnQgaXJxKQoreworICAgICAgICBpbnQgaTsKKyAgICAg
ICAgc3RydWN0IGlycV9kZXNjICpkZXNjOworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOwor
ICAgICAgICBzdHJ1Y3QgcGlycSAqcGlycTsKKworICAgICAgICBpcnFfZ3Vlc3RfYWN0aW9u
X3QgKmFjdGlvbjsKKworICAgICAgICBkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsKKworICAg
ICAgICBhY3Rpb24gPSAoaXJxX2d1ZXN0X2FjdGlvbl90ICopZGVzYy0+YWN0aW9uOworICAg
ICAgICBmb3IgKGkgPSAwOyBpIDwgYWN0aW9uLT5ucl9ndWVzdHM7IGkrKykgeworICAgICAg
ICAgICAgICAgIGQgPSBhY3Rpb24tPmd1ZXN0W2ldOworICAgICAgICAgICAgICAgIHBpcnEg
PSBwaXJxX2luZm8oZCwgaXJxKTsKKyAgICAgICAgICAgICAgICBhY3Rpb24tPmluX2ZsaWdo
dCsrOworICAgICAgICAgICAgICAgIHNlbmRfZ3Vlc3RfcGlycShkLCBwaXJxKTsKKyAgICAg
ICAgfQorCisKK30KKworYXNtbGlua2FnZSB2b2lkIGRvX2lwaSh1bnNpZ25lZCBpbnQgaXBp
LCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKK3sKK30KKworYXNtbGlua2FnZSB2b2lk
IGRvX2lycSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykK
K3sKKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOworICAgICAgICBzdHJ1Y3QgaXJx
YWN0aW9uICphY3Rpb247CisKKyAgICAgICAgaWYgKGlycSA+PSBOUl9JUlFTKSB7CisgICAg
ICAgICAgICAgICAgcHJpbnRrKCJCYWQgSVJRID0gJWRcbiIsIGlycSk7CisgICAgICAgIH0K
KworICAgICAgICBkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsKKworICAgICAgICBzcGluX2xv
Y2soJmRlc2MtPmxvY2spOworCisgICAgICAgIGRlc2MtPmhhbmRsZXItPmFjayhkZXNjKTsK
KworCisgICAgICAgIGlmIChsaWtlbHkoZGVzYy0+c3RhdHVzICYgSVJRX0dVRVNUKSkgewor
ICAgICAgICAgICAgICAgIGRvX2d1ZXN0X2lycShpcnEpOworICAgICAgICAgICAgICAgIHNw
aW5fdW5sb2NrKCZkZXNjLT5sb2NrKTsKKworICAgICAgICAgICAgICAgIHJldHVybjsKKyAg
ICAgICAgfQorCisgICAgICAgIGFjdGlvbiA9IGRlc2MtPmFjdGlvbjsKKworICAgICAgICBC
VUdfT04oIWFjdGlvbik7CisKKyAgICAgICAgc3Bpbl91bmxvY2soJmRlc2MtPmxvY2spOwor
CisgICAgICAgIGFjdGlvbi0+aGFuZGxlcihpcnEsIGFjdGlvbi0+ZGV2X2lkLCByZWdzKTsK
KworICAgICAgICBkZXNjLT5oYW5kbGVyLT5lbmQoZGVzYyk7Cit9CisKKwogaW50IGFyY2hf
aW5pdF9vbmVfaXJxX2Rlc2Moc3RydWN0IGlycV9kZXNjICpkZXNjKQogewogCU5PVF9ZRVQo
KTsK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt18-0005z6-2x; Mon, 13 Feb 2012 10:20:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqre-0003vN-59
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:02:22 +0000
Received: from [85.158.139.83:57535] by server-3.bemta-5.messagelabs.com id
	7B/A1-25605-D83C83F4; Mon, 13 Feb 2012 08:02:21 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329120139!7453076!2
X-Originating-IP: [203.254.224.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzQgPT4gMjQwMTQ5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32110 invoked from network); 13 Feb 2012 08:02:20 -0000
Received: from mailout4.samsung.com (HELO mailout4.samsung.com)
	(203.254.224.34) by server-16.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 08:02:20 -0000
Received: from epcpsbge3.samsung.com (mailout4.samsung.com [203.254.224.34])
	by mailout4.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00149NNT2XB0@mailout4.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:02:19 +0900 (KST)
Message-id: <0LZB0014JNNV2XB0@mailout4.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-00-4f38c38ac9d5
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 60.FD.17710.A83C83F4;
	Mon, 13 Feb 2012 17:02:18 +0900 (KST)
Date: Mon, 13 Feb 2012 08:02:18 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080134863@jm77.ryu
Msgkey: 20120213080134863@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080044709@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 10/14]  arm: implement ARMv7 tlb ops.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <3414607.70211329120135179.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgQVJNdjcgdGxiIG9wcy4NCg0KIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUgICAgICAgfCAgIDEgKw0KIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUyAgICAgfCAgMTcg
KysrKystLS0tLS0tLS0tLS0NCiB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jIHwgICA2
ICsrKy0tLQ0KIHhlbi9hcmNoL2FybS94ZW4vdGxiLXY3LlMgICAgICAgfCAgNTEgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogNCBmaWxlcyBjaGFu
Z2VkLCA2MCBpbnNlcnRpb25zKCspLCAxNSBkZWxldGlvbnMoLSkNCg0KU2lnbmVkLW9mZi1ieTog
SmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgYzZhNDEyYWRmYWU3
IHhlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUJU3VuIEZlYiAxMiAxMjowNTozNiAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVu
L01ha2VmaWxlCVN1biBGZWIgMTIgMTI6MjQ6MDkgMjAxMiArMDkwMA0KQEAgLTIzLDMgKzIzLDQg
QEAgb2JqLXkgKz0gcGVyZm1vbi5vDQogb2JqLXkgKz0gcGNpLm8NCiBvYmoteSArPSBhcm12Ny5v
DQogb2JqLXkgKz0gY2FjaGUtdjcubw0KK29iai15ICs9IHRsYi12Ny5vDQpkaWZmIC1yIGM2YTQx
MmFkZmFlNyB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMNCi0tLSBhL3hlbi9hcmNoL2FybS94
ZW4vY2FjaGUtdjcuUwlTdW4gRmViIDEyIDEyOjA1OjM2IDIwMTIgKzA5MDANCisrKyBiL3hlbi9h
cmNoL2FybS94ZW4vY2FjaGUtdjcuUwlTdW4gRmViIDEyIDEyOjI0OjA5IDIwMTIgKzA5MDANCkBA
IC0xLDcgKzEsNiBAQA0KLSNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPg0KKyNpbmNsdWRlIDx4ZW4v
Y29uZmlnLmg+DQorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+DQogI2luY2x1ZGUgPGFzbS9w
YWdlLmg+DQotI2luY2x1ZGUgPGFzbS9jcHUtb3BzLmg+DQotI2luY2x1ZGUgPGFzbS9zeXN0ZW0u
aD4NCiAjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQogDQogCS5tYWNybyB2N193YXlfb3As
IG9wDQpAQCAtNDksNyArNDgsNyBAQCA1MDoNCiAJLmVuZG0NCiAJLnRleHQNCiANCi1QUklWQVRF
KHY3X2ZsdXNoX2NhY2hlX2FsbCkNCitFTlRSWShjcHVfZmx1c2hfY2FjaGVfYWxsKQ0KIAlzdG1m
ZAlzcCEsIHtyNC1yNSwgcjcsIHI5LXIxMSwgbHJ9DQogDQogCXY3X3dheV9vcCBjMTQNCkBAIC01
OSw5ICs1OCw3IEBAIFBSSVZBVEUodjdfZmx1c2hfY2FjaGVfYWxsKQ0KIAlsZG1mZAlzcCEsIHty
NC1yNSwgcjcsIHI5LXIxMSwgbHJ9DQogCW1vdglwYywgbHINCiANCi1ERUNMQVJFX0NQVV9PUChj
cHVfZmx1c2hfY2FjaGVfYWxsLCB2N19mbHVzaF9jYWNoZV9hbGwpDQotDQotUFJJVkFURSh2N19m
bHVzaF9jYWNoZV9yYW5nZSkNCitFTlRSWShjcHVfZmx1c2hfY2FjaGVfcmFuZ2UpDQogCW1yYyAg
ICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUg0KIAlhbmQgICAgIHIzLCByMywg
IzcJCUAgY2FjaGUgbGluZSBzaXplIGVuY29kaW5nDQogCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6
ZSBvZmZzZXQNCkBAIC03NCw5ICs3MSw3IEBAIDE6DQogCWRzYg0KIAltb3YJcGMsIGxyDQogDQot
REVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNoX2NhY2hlX3JhbmdlLCB2N19mbHVzaF9jYWNoZV9yYW5n
ZSkNCi0NCi1QUklWQVRFKHY3X2NsZWFuX2NhY2hlX3JhbmdlKQ0KK0VOVFJZKGNwdV9jbGVhbl9j
YWNoZV9yYW5nZSkNCiAJbXJjICAgICBwMTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFkIENTSURS
DQogCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcNCiAJbW92
ICAgICByMywgIzE2CQkJQCBzaXplIG9mZnNldA0KQEAgLTkwLDUgKzg1LDMgQEAgMToNCiAJZHNi
DQogCW1vdglwYywgbHINCiANCi1ERUNMQVJFX0NQVV9PUChjcHVfY2xlYW5fY2FjaGVfcmFuZ2Us
IHY3X2NsZWFuX2NhY2hlX3JhbmdlKQ0KLQ0KZGlmZiAtciBjNmE0MTJhZGZhZTcgeGVuL2FyY2gv
YXJtL3hlbi9kb21haW5fYnVpbGQuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9kb21haW5fYnVp
bGQuYwlTdW4gRmViIDEyIDEyOjA1OjM2IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94
ZW4vZG9tYWluX2J1aWxkLmMJU3VuIEZlYiAxMiAxMjoyNDowOSAyMDEyICswOTAwDQpAQCAtMTc2
LDcgKzE3Niw3IEBAIGludCBkb21haW5fY29uc3RydWN0KHN0cnVjdCBkb21haW4gKmQsDQogCX0g
d2hpbGUoZ3B0KyssIHBtYXAgPCBwZW5kKTsNCiAgDQogCS8qIEFjdGl2YXRlIGd1ZXN0IGFkZHJl
c3Mgc3BhY2UgdG8gcmVsb2NhdGUgZ3Vlc3QgaW1hZ2UgKi8NCi0JbW11X3N3aXRjaF90dGIoZ3B0
ICYgfigweDQwMDAgLSAxKSk7DQorCXNldF90dGJyKCh1bnNpZ25lZCBsb25nKShncHQpICYgfigw
eDQwMDAgLSAxKSk7DQogDQogCWVsZi5kZXN0ID0gKHZvaWQgKil2ZW50cnk7DQogCWVsZl9sb2Fk
X2JpbmFyeSgmZWxmKTsNCkBAIC0xOTIsNyArMTkyLDcgQEAgaW50IGRvbWFpbl9jb25zdHJ1Y3Qo
c3RydWN0IGRvbWFpbiAqZCwNCiAJc2ktPm1mbl9saXN0IAkgID0gMDsNCiAJc2ktPmZpcnN0X3Ay
bV9wZm4gPSBwc3RhcnQgPj4gUEFHRV9TSElGVDsNCiAJc2ktPmZsYWdzIAkgID0gMDsNCi0Jc2kt
Pm1pbl9tZm4JICA9IHBzdGFydCA+PiBQQUdFX1NISUZUOw0KKwkvL3NpLT5taW5fbWZuCSAgPSBw
c3RhcnQgPj4gUEFHRV9TSElGVDsNCiANCiAJaWYgKGQtPmRvbWFpbl9pZCA9PSAwKSB7DQogCQlz
aS0+ZmxhZ3MgPSBTSUZfUFJJVklMRUdFRCB8IFNJRl9JTklURE9NQUlOOw0KQEAgLTIwMiw3ICsy
MDIsNyBAQCBpbnQgZG9tYWluX2NvbnN0cnVjdChzdHJ1Y3QgZG9tYWluICpkLA0KIA0KIAlWQ1BV
X1JFRyh2LCB0dGJyMCkgPSAodW5zaWduZWQgbG9uZylncHQ7DQogDQotCW1tdV9zd2l0Y2hfdHRi
KFZDUFVfUkVHKGlkbGVfdmNwdVswXSwgdHRicjApKTsNCisJc2V0X3R0YnIoVkNQVV9SRUcoaWRs
ZV92Y3B1WzBdLCB0dGJyMCkpOw0KIA0KIAl2Y3B1X2NvbnRleHRfaW5pdCh2LCAwLCB2ZW50cnks
IHNpKTsNCiANCmRpZmYgLXIgYzZhNDEyYWRmYWU3IHhlbi9hcmNoL2FybS94ZW4vdGxiLXY3LlMN
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3RsYi12Ny5TCVN1biBGZWIgMTIgMTI6MjQ6MDkgMjAxMiArMDkwMA0KQEAg
LTAsMCArMSw1MSBAQA0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+DQorI2luY2x1ZGUgPGFzbS9h
c20tbWFjcm9zLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorDQorI2RlZmluZSBQQUdFX1Na
IDQwOTYgLyogUEFHRV9TSVpFCUAgKi8NCisNCitFTlRSWShjcHVfZmx1c2hfdGxiX2FsbCkNCisJ
ZHNiDQorCW1vdglpcCwJIzANCisjaWZuZGVmIFNNUA0KKwltY3IJcDE1LCAwLCBpcCwgYzgsIGM2
LCAgMAkJQCBpbnZhbGlkYXRlIEVudGlyZSBJIFRMQg0KKwltY3IJcDE1LCAwLCBpcCwgYzgsIGM1
LCAgMAkJQCBpbnZhbGlkYXRlIEVudGlyZSBEIFRMQg0KKyNlbHNlDQorCW1jcglwMTUsIDAsIGlw
LCBjOCwgYzMsIDANCisjZW5kaWYNCisJbWNyCXAxNSwgMCwgaXAsIGM3LCBjNSwgNgkJQCBmbHVz
aCBCVEFDL0JUQiAoc2hhcmVhYmxlKQ0KKwlkc2INCisJaXNiDQorCW1vdglwYywgbHINCisNCitF
TlRSWShjcHVfZmx1c2hfdGxiX2VudHJ5KQ0KKwlkc2INCisjaWZuZGVmIFNNUA0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGM2LCAxCQlAIFRMQiBpbnZhbGlkYXRlIEQgTVZBDQorCW1jcglwMTUsIDAs
IHIwLCBjOCwgYzUsIDEJCUAgVExCIGludmFsaWRhdGUgSSBNVkENCisjZWxzZQ0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGMzLCAxCQlAIFRMQiBpbnZhbGlkYXRlIFUgTVZBIChzaGFyZWFibGUpIA0K
KyNlbmRpZg0KKwltb3YJaXAsICMwDQorCW1jcglwMTUsIDAsIGlwLCBjNywgYzUsIDYJCUAgZmx1
c2ggQlRBQy9CVEIgKHNoYXJlYWJsZSkNCisJZHNiDQorCW1vdglwYywgbHINCisNCitFTlRSWShj
cHVfZmx1c2hfdGxiX3JhbmdlKQ0KKwlkc2IJDQorMToNCisjaWZuZGVmIFNNUA0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGM2LCAxCQlAIFRMQiBpbnZhbGlkYXRlIEQgTVZBDQorCW1jcglwMTUsIDAs
IHIwLCBjOCwgYzUsIDEJCUAgVExCIGludmFsaWRhdGUgSSBNVkENCisjZWxzZQ0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGMzLCAxCQlAIFRMQiBpbnZhbGlkYXRlIFUgTVZBIChzaGFyZWFibGUpIA0K
KyNlbmRpZg0KKwlhZGQJcjAsIHIwLCAjUEFHRV9TWg0KKwljbXAJcjAsIHIxDQorCWJsbwkxYg0K
Kwltb3YJaXAsICMwDQorCW1jcglwMTUsIDAsIGlwLCBjNywgYzUsIDYJCUAgZmx1c2ggQlRBQy9C
VEIgKHNoYXJlYWJsZSkNCisJZHNiDQorCWlzYg0KKwltb3YJcGMsIGxyDQorCQ0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch10.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch10.diff"


YXJtOiBpbXBsZW1lbnQgQVJNdjcgdGxiIG9wcy4KCiB4ZW4vYXJjaC9hcm0veGVuL01ha2Vm
aWxlICAgICAgIHwgICAxICsKIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUyAgICAgfCAg
MTcgKysrKystLS0tLS0tLS0tLS0KIHhlbi9hcmNoL2FybS94ZW4vZG9tYWluX2J1aWxkLmMg
fCAgIDYgKysrLS0tCiB4ZW4vYXJjaC9hcm0veGVuL3RsYi12Ny5TICAgICAgIHwgIDUxICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogNCBm
aWxlcyBjaGFuZ2VkLCA2MCBpbnNlcnRpb25zKCspLCAxNSBkZWxldGlvbnMoLSkKClNpZ25l
ZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciBj
NmE0MTJhZGZhZTcgeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC9h
cm0veGVuL01ha2VmaWxlCVN1biBGZWIgMTIgMTI6MDU6MzYgMjAxMiArMDkwMAorKysgYi94
ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCVN1biBGZWIgMTIgMTI6MjQ6MDkgMjAxMiArMDkw
MApAQCAtMjMsMyArMjMsNCBAQCBvYmoteSArPSBwZXJmbW9uLm8KIG9iai15ICs9IHBjaS5v
CiBvYmoteSArPSBhcm12Ny5vCiBvYmoteSArPSBjYWNoZS12Ny5vCitvYmoteSArPSB0bGIt
djcubwpkaWZmIC1yIGM2YTQxMmFkZmFlNyB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMK
LS0tIGEveGVuL2FyY2gvYXJtL3hlbi9jYWNoZS12Ny5TCVN1biBGZWIgMTIgMTI6MDU6MzYg
MjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMJU3VuIEZlYiAx
MiAxMjoyNDowOSAyMDEyICswOTAwCkBAIC0xLDcgKzEsNiBAQAotI2luY2x1ZGUgPHhlbi9s
aW5rYWdlLmg+CisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9hc20t
bWFjcm9zLmg+CiAjaW5jbHVkZSA8YXNtL3BhZ2UuaD4KLSNpbmNsdWRlIDxhc20vY3B1LW9w
cy5oPgotI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4KICNpbmNsdWRlIDxhc20vYXNtLW9mZnNl
dHMuaD4KIAogCS5tYWNybyB2N193YXlfb3AsIG9wCkBAIC00OSw3ICs0OCw3IEBAIDUwOgog
CS5lbmRtCiAJLnRleHQKIAotUFJJVkFURSh2N19mbHVzaF9jYWNoZV9hbGwpCitFTlRSWShj
cHVfZmx1c2hfY2FjaGVfYWxsKQogCXN0bWZkCXNwISwge3I0LXI1LCByNywgcjktcjExLCBs
cn0KIAogCXY3X3dheV9vcCBjMTQKQEAgLTU5LDkgKzU4LDcgQEAgUFJJVkFURSh2N19mbHVz
aF9jYWNoZV9hbGwpCiAJbGRtZmQJc3AhLCB7cjQtcjUsIHI3LCByOS1yMTEsIGxyfQogCW1v
dglwYywgbHIKIAotREVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNoX2NhY2hlX2FsbCwgdjdfZmx1
c2hfY2FjaGVfYWxsKQotCi1QUklWQVRFKHY3X2ZsdXNoX2NhY2hlX3JhbmdlKQorRU5UUlko
Y3B1X2ZsdXNoX2NhY2hlX3JhbmdlKQogCW1yYyAgICAgcDE1LCAxLCByMywgYzAsIGMwLCAw
CUAgcmVhZCBDU0lEUgogCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUg
ZW5jb2RpbmcKIAltb3YgICAgIHIzLCAjMTYJCQlAIHNpemUgb2Zmc2V0CkBAIC03NCw5ICs3
MSw3IEBAIDE6CiAJZHNiCiAJbW92CXBjLCBscgogCi1ERUNMQVJFX0NQVV9PUChjcHVfZmx1
c2hfY2FjaGVfcmFuZ2UsIHY3X2ZsdXNoX2NhY2hlX3JhbmdlKQotCi1QUklWQVRFKHY3X2Ns
ZWFuX2NhY2hlX3JhbmdlKQorRU5UUlkoY3B1X2NsZWFuX2NhY2hlX3JhbmdlKQogCW1yYyAg
ICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUgogCWFuZCAgICAgcjMsIHIz
LCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcKIAltb3YgICAgIHIzLCAjMTYJCQlA
IHNpemUgb2Zmc2V0CkBAIC05MCw1ICs4NSwzIEBAIDE6CiAJZHNiCiAJbW92CXBjLCBscgog
Ci1ERUNMQVJFX0NQVV9PUChjcHVfY2xlYW5fY2FjaGVfcmFuZ2UsIHY3X2NsZWFuX2NhY2hl
X3JhbmdlKQotCmRpZmYgLXIgYzZhNDEyYWRmYWU3IHhlbi9hcmNoL2FybS94ZW4vZG9tYWlu
X2J1aWxkLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwlTdW4gRmVi
IDEyIDEyOjA1OjM2IDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9kb21haW5f
YnVpbGQuYwlTdW4gRmViIDEyIDEyOjI0OjA5IDIwMTIgKzA5MDAKQEAgLTE3Niw3ICsxNzYs
NyBAQCBpbnQgZG9tYWluX2NvbnN0cnVjdChzdHJ1Y3QgZG9tYWluICpkLAogCX0gd2hpbGUo
Z3B0KyssIHBtYXAgPCBwZW5kKTsKICAKIAkvKiBBY3RpdmF0ZSBndWVzdCBhZGRyZXNzIHNw
YWNlIHRvIHJlbG9jYXRlIGd1ZXN0IGltYWdlICovCi0JbW11X3N3aXRjaF90dGIoZ3B0ICYg
figweDQwMDAgLSAxKSk7CisJc2V0X3R0YnIoKHVuc2lnbmVkIGxvbmcpKGdwdCkgJiB+KDB4
NDAwMCAtIDEpKTsKIAogCWVsZi5kZXN0ID0gKHZvaWQgKil2ZW50cnk7CiAJZWxmX2xvYWRf
YmluYXJ5KCZlbGYpOwpAQCAtMTkyLDcgKzE5Miw3IEBAIGludCBkb21haW5fY29uc3RydWN0
KHN0cnVjdCBkb21haW4gKmQsCiAJc2ktPm1mbl9saXN0IAkgID0gMDsKIAlzaS0+Zmlyc3Rf
cDJtX3BmbiA9IHBzdGFydCA+PiBQQUdFX1NISUZUOwogCXNpLT5mbGFncyAJICA9IDA7Ci0J
c2ktPm1pbl9tZm4JICA9IHBzdGFydCA+PiBQQUdFX1NISUZUOworCS8vc2ktPm1pbl9tZm4J
ICA9IHBzdGFydCA+PiBQQUdFX1NISUZUOwogCiAJaWYgKGQtPmRvbWFpbl9pZCA9PSAwKSB7
CiAJCXNpLT5mbGFncyA9IFNJRl9QUklWSUxFR0VEIHwgU0lGX0lOSVRET01BSU47CkBAIC0y
MDIsNyArMjAyLDcgQEAgaW50IGRvbWFpbl9jb25zdHJ1Y3Qoc3RydWN0IGRvbWFpbiAqZCwK
IAogCVZDUFVfUkVHKHYsIHR0YnIwKSA9ICh1bnNpZ25lZCBsb25nKWdwdDsKIAotCW1tdV9z
d2l0Y2hfdHRiKFZDUFVfUkVHKGlkbGVfdmNwdVswXSwgdHRicjApKTsKKwlzZXRfdHRicihW
Q1BVX1JFRyhpZGxlX3ZjcHVbMF0sIHR0YnIwKSk7CiAKIAl2Y3B1X2NvbnRleHRfaW5pdCh2
LCAwLCB2ZW50cnksIHNpKTsKIApkaWZmIC1yIGM2YTQxMmFkZmFlNyB4ZW4vYXJjaC9hcm0v
eGVuL3RsYi12Ny5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vdGxiLXY3LlMJU3VuIEZlYiAxMiAxMjoyNDow
OSAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTEgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+
CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKyNpbmNsdWRlIDxhc20vcGFnZS5oPgor
CisjZGVmaW5lIFBBR0VfU1ogNDA5NiAvKiBQQUdFX1NJWkUJQCAqLworCitFTlRSWShjcHVf
Zmx1c2hfdGxiX2FsbCkKKwlkc2IKKwltb3YJaXAsCSMwCisjaWZuZGVmIFNNUAorCW1jcglw
MTUsIDAsIGlwLCBjOCwgYzYsICAwCQlAIGludmFsaWRhdGUgRW50aXJlIEkgVExCCisJbWNy
CXAxNSwgMCwgaXAsIGM4LCBjNSwgIDAJCUAgaW52YWxpZGF0ZSBFbnRpcmUgRCBUTEIKKyNl
bHNlCisJbWNyCXAxNSwgMCwgaXAsIGM4LCBjMywgMAorI2VuZGlmCisJbWNyCXAxNSwgMCwg
aXAsIGM3LCBjNSwgNgkJQCBmbHVzaCBCVEFDL0JUQiAoc2hhcmVhYmxlKQorCWRzYgorCWlz
YgorCW1vdglwYywgbHIKKworRU5UUlkoY3B1X2ZsdXNoX3RsYl9lbnRyeSkKKwlkc2IKKyNp
Zm5kZWYgU01QCisJbWNyCXAxNSwgMCwgcjAsIGM4LCBjNiwgMQkJQCBUTEIgaW52YWxpZGF0
ZSBEIE1WQQorCW1jcglwMTUsIDAsIHIwLCBjOCwgYzUsIDEJCUAgVExCIGludmFsaWRhdGUg
SSBNVkEKKyNlbHNlCisJbWNyCXAxNSwgMCwgcjAsIGM4LCBjMywgMQkJQCBUTEIgaW52YWxp
ZGF0ZSBVIE1WQSAoc2hhcmVhYmxlKSAKKyNlbmRpZgorCW1vdglpcCwgIzAKKwltY3IJcDE1
LCAwLCBpcCwgYzcsIGM1LCA2CQlAIGZsdXNoIEJUQUMvQlRCIChzaGFyZWFibGUpCisJZHNi
CisJbW92CXBjLCBscgorCitFTlRSWShjcHVfZmx1c2hfdGxiX3JhbmdlKQorCWRzYgkKKzE6
CisjaWZuZGVmIFNNUAorCW1jcglwMTUsIDAsIHIwLCBjOCwgYzYsIDEJCUAgVExCIGludmFs
aWRhdGUgRCBNVkEKKwltY3IJcDE1LCAwLCByMCwgYzgsIGM1LCAxCQlAIFRMQiBpbnZhbGlk
YXRlIEkgTVZBCisjZWxzZQorCW1jcglwMTUsIDAsIHIwLCBjOCwgYzMsIDEJCUAgVExCIGlu
dmFsaWRhdGUgVSBNVkEgKHNoYXJlYWJsZSkgCisjZW5kaWYKKwlhZGQJcjAsIHIwLCAjUEFH
RV9TWgorCWNtcAlyMCwgcjEKKwlibG8JMWIKKwltb3YJaXAsICMwCisJbWNyCXAxNSwgMCwg
aXAsIGM3LCBjNSwgNgkJQCBmbHVzaCBCVEFDL0JUQiAoc2hhcmVhYmxlKQorCWRzYgorCWlz
YgorCW1vdglwYywgbHIKKwkK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt13-0005va-Uy; Mon, 13 Feb 2012 10:20:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqfD-00037U-I3
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:49:31 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329119363!14034346!2
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11582 invoked from network); 13 Feb 2012 07:49:25 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-11.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:49:25 -0000
Received: from epcpsbge5.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00GKYMYGR6D0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:49:23 +0900 (KST)
X-AuditID: cbfee60f-b7bd0ae00000422c-01-4f38c0838ac2
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge5.samsung.com (EPCPMTA) with SMTP id 08.E9.16940.380C83F4;
	Mon, 13 Feb 2012 16:49:23 +0900 (KST)
Date: Mon, 13 Feb 2012 07:49:23 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Lars Kurth <lars.kurth@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213074805604@jm77.ryu
Msgkey: 20120213074805604@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 
MIME-version: 1.0
Message-id: <24653710.69381329119360053.JavaMail.weblogic@epv6ml04>
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 01/14]  arm: start working on ARM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


arm: start working on ARM.

 Config.mk                 |  1 +
 xen/Rules.mk              |  2 +-
 xen/common/kexec.c        |  2 ++
 xen/common/sysctl.c       |  8 ++++++++
 xen/common/tmem_xen.c     |  2 +-
 xen/drivers/Makefile      |  2 ++
 xen/drivers/char/Makefile |  2 ++
 xen/include/public/xen.h  |  2 ++
 xen/include/xen/libelf.h  |  2 +-
 9 files changed, 20 insertions(+), 3 deletions(-)

Signed-off-by: Jaemin Ryu <jm77.ryu@samsung.com>

diff -r b3de82b35189 Config.mk
--- a/Config.mk Fri Feb 03 12:21:09 2012 +0900
+++ b/Config.mk Fri Feb 03 15:52:40 2012 +0900
@@ -15,6 +15,7 @@ debug ?= y
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
+XEN_TARGET_SUBARCH  ?= $(XEN_TARGET_ARCH)
 XEN_OS              ?= $(shell uname -s)

 CONFIG_$(XEN_OS) := y
diff -r b3de82b35189 xen/Rules.mk
--- a/xen/Rules.mk      Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/Rules.mk      Fri Feb 03 15:52:40 2012 +0900
@@ -26,9 +26,9 @@ perfc := y
 endif

 # Set ARCH/SUBARCH appropriately.
-override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
 override TARGET_ARCH     := $(shell echo $(XEN_TARGET_ARCH) | \
                               sed -e 's/x86.*/x86/')
+override TARGET_SUBARCH  := $(XEN_TARGET_SUBARCH)

 TARGET := $(BASEDIR)/xen

diff -r b3de82b35189 xen/common/kexec.c
--- a/xen/common/kexec.c        Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/common/kexec.c        Fri Feb 03 15:52:40 2012 +0900
@@ -211,7 +211,9 @@ static void kexec_common_shutdown(void)
     console_start_sync();
     spin_debug_disable();
     one_cpu_only();
+#if !defined(__arm__)
     acpi_dmar_reinstate();
+#endif
 }

 void kexec_crash(void)
diff -r b3de82b35189 xen/common/sysctl.c
--- a/xen/common/sysctl.c       Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/common/sysctl.c       Fri Feb 03 15:52:40 2012 +0900
@@ -226,6 +226,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc

     case XEN_SYSCTL_get_pmstat:
     {
+#if !defined(__arm__)
         ret = xsm_get_pmstat();
         if ( ret )
             break;
@@ -239,11 +240,15 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
             ret = -EFAULT;
             break;
         }
+#else
+       ret = -EINVAL;
+#endif
     }
     break;

     case XEN_SYSCTL_pm_op:
     {
+#if !defined(__arm__)
         ret = xsm_pm_op();
         if ( ret )
             break;
@@ -257,6 +262,9 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
             ret = -EFAULT;
             break;
         }
+#else
+       ret = -EINVAL;
+#endif
     }
     break;

diff -r b3de82b35189 xen/common/tmem_xen.c
--- a/xen/common/tmem_xen.c     Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/common/tmem_xen.c     Fri Feb 03 15:52:40 2012 +0900
@@ -87,7 +87,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }

-#ifdef __ia64__
+#if defined(__ia64__) || defined(__arm__)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
diff -r b3de82b35189 xen/drivers/Makefile
--- a/xen/drivers/Makefile      Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/drivers/Makefile      Fri Feb 03 15:52:40 2012 +0900
@@ -1,6 +1,8 @@
 subdir-y += char
+ifneq ($(TARGET_ARCH),arm)
 subdir-y += cpufreq
 subdir-y += pci
 subdir-y += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
+endif
diff -r b3de82b35189 xen/drivers/char/Makefile
--- a/xen/drivers/char/Makefile Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/drivers/char/Makefile Fri Feb 03 15:52:40 2012 +0900
@@ -1,3 +1,5 @@
 obj-y += console.o
+ifneq ($(TARGET_ARCH),arm)
 obj-y += ns16550.o
+endif
 obj-y += serial.o
diff -r b3de82b35189 xen/include/public/xen.h
--- a/xen/include/public/xen.h  Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/include/public/xen.h  Fri Feb 03 15:52:40 2012 +0900
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
diff -r b3de82b35189 xen/include/xen/libelf.h
--- a/xen/include/xen/libelf.h  Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/include/xen/libelf.h  Fri Feb 03 15:52:40 2012 +0900
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__

-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt13-0005va-Uy; Mon, 13 Feb 2012 10:20:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1RwqfD-00037U-I3
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:49:31 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329119363!14034346!2
X-Originating-IP: [203.254.224.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjUgPT4gMjQ2MTY1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11582 invoked from network); 13 Feb 2012 07:49:25 -0000
Received: from mailout2.samsung.com (HELO mailout2.samsung.com)
	(203.254.224.25) by server-11.tower-216.messagelabs.com with SMTP;
	13 Feb 2012 07:49:25 -0000
Received: from epcpsbge5.samsung.com (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00GKYMYGR6D0@mailout2.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:49:23 +0900 (KST)
X-AuditID: cbfee60f-b7bd0ae00000422c-01-4f38c0838ac2
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge5.samsung.com (EPCPMTA) with SMTP id 08.E9.16940.380C83F4;
	Mon, 13 Feb 2012 16:49:23 +0900 (KST)
Date: Mon, 13 Feb 2012 07:49:23 +0000 (GMT)
From: Jae-Min Ryu <jm77.ryu@samsung.com>
To: Lars Kurth <lars.kurth@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213074805604@jm77.ryu
Msgkey: 20120213074805604@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 
MIME-version: 1.0
Message-id: <24653710.69381329119360053.JavaMail.weblogic@epv6ml04>
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 01/14]  arm: start working on ARM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


arm: start working on ARM.

 Config.mk                 |  1 +
 xen/Rules.mk              |  2 +-
 xen/common/kexec.c        |  2 ++
 xen/common/sysctl.c       |  8 ++++++++
 xen/common/tmem_xen.c     |  2 +-
 xen/drivers/Makefile      |  2 ++
 xen/drivers/char/Makefile |  2 ++
 xen/include/public/xen.h  |  2 ++
 xen/include/xen/libelf.h  |  2 +-
 9 files changed, 20 insertions(+), 3 deletions(-)

Signed-off-by: Jaemin Ryu <jm77.ryu@samsung.com>

diff -r b3de82b35189 Config.mk
--- a/Config.mk Fri Feb 03 12:21:09 2012 +0900
+++ b/Config.mk Fri Feb 03 15:52:40 2012 +0900
@@ -15,6 +15,7 @@ debug ?= y
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
+XEN_TARGET_SUBARCH  ?= $(XEN_TARGET_ARCH)
 XEN_OS              ?= $(shell uname -s)

 CONFIG_$(XEN_OS) := y
diff -r b3de82b35189 xen/Rules.mk
--- a/xen/Rules.mk      Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/Rules.mk      Fri Feb 03 15:52:40 2012 +0900
@@ -26,9 +26,9 @@ perfc := y
 endif

 # Set ARCH/SUBARCH appropriately.
-override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
 override TARGET_ARCH     := $(shell echo $(XEN_TARGET_ARCH) | \
                               sed -e 's/x86.*/x86/')
+override TARGET_SUBARCH  := $(XEN_TARGET_SUBARCH)

 TARGET := $(BASEDIR)/xen

diff -r b3de82b35189 xen/common/kexec.c
--- a/xen/common/kexec.c        Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/common/kexec.c        Fri Feb 03 15:52:40 2012 +0900
@@ -211,7 +211,9 @@ static void kexec_common_shutdown(void)
     console_start_sync();
     spin_debug_disable();
     one_cpu_only();
+#if !defined(__arm__)
     acpi_dmar_reinstate();
+#endif
 }

 void kexec_crash(void)
diff -r b3de82b35189 xen/common/sysctl.c
--- a/xen/common/sysctl.c       Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/common/sysctl.c       Fri Feb 03 15:52:40 2012 +0900
@@ -226,6 +226,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc

     case XEN_SYSCTL_get_pmstat:
     {
+#if !defined(__arm__)
         ret = xsm_get_pmstat();
         if ( ret )
             break;
@@ -239,11 +240,15 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
             ret = -EFAULT;
             break;
         }
+#else
+       ret = -EINVAL;
+#endif
     }
     break;

     case XEN_SYSCTL_pm_op:
     {
+#if !defined(__arm__)
         ret = xsm_pm_op();
         if ( ret )
             break;
@@ -257,6 +262,9 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
             ret = -EFAULT;
             break;
         }
+#else
+       ret = -EINVAL;
+#endif
     }
     break;

diff -r b3de82b35189 xen/common/tmem_xen.c
--- a/xen/common/tmem_xen.c     Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/common/tmem_xen.c     Fri Feb 03 15:52:40 2012 +0900
@@ -87,7 +87,7 @@ void tmh_copy_page(char *to, char*from)
 #endif
 }

-#ifdef __ia64__
+#if defined(__ia64__) || defined(__arm__)
 static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn,
                                  pfp_t **pcli_pfp, bool_t cli_write)
 {
diff -r b3de82b35189 xen/drivers/Makefile
--- a/xen/drivers/Makefile      Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/drivers/Makefile      Fri Feb 03 15:52:40 2012 +0900
@@ -1,6 +1,8 @@
 subdir-y += char
+ifneq ($(TARGET_ARCH),arm)
 subdir-y += cpufreq
 subdir-y += pci
 subdir-y += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
+endif
diff -r b3de82b35189 xen/drivers/char/Makefile
--- a/xen/drivers/char/Makefile Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/drivers/char/Makefile Fri Feb 03 15:52:40 2012 +0900
@@ -1,3 +1,5 @@
 obj-y += console.o
+ifneq ($(TARGET_ARCH),arm)
 obj-y += ns16550.o
+endif
 obj-y += serial.o
diff -r b3de82b35189 xen/include/public/xen.h
--- a/xen/include/public/xen.h  Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/include/public/xen.h  Fri Feb 03 15:52:40 2012 +0900
@@ -33,6 +33,8 @@
 #include "arch-x86/xen.h"
 #elif defined(__ia64__)
 #include "arch-ia64.h"
+#elif defined(__arm__)
+#include "arch-arm.h"
 #else
 #error "Unsupported architecture"
 #endif
diff -r b3de82b35189 xen/include/xen/libelf.h
--- a/xen/include/xen/libelf.h  Fri Feb 03 12:21:09 2012 +0900
+++ b/xen/include/xen/libelf.h  Fri Feb 03 15:52:40 2012 +0900
@@ -23,7 +23,7 @@
 #ifndef __XEN_LIBELF_H__
 #define __XEN_LIBELF_H__

-#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__ia64__) || defined(__arm__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt19-00060g-Le; Mon, 13 Feb 2012 10:20:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqvu-00045e-UX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:06:47 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329120397!13098982!1
X-Originating-IP: [203.254.224.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMjQgPT4gMjQzMDY5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10304 invoked from network); 13 Feb 2012 08:06:39 -0000
Received: from mailout1.samsung.com (HELO mailout1.samsung.com)
	(203.254.224.24) by server-5.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 08:06:39 -0000
Received: from epcpsbge1.samsung.com (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB0031NNPLNF70@mailout1.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:06:36 +0900 (KST)
Message-id: <0LZB003ABNV0NF70@mailout1.samsung.com>
X-AuditID: cbfee60b-b7be6ae000004638-87-4f38c48c4e2f
Received: from epextmailer02 ( [203.254.219.152])
	by epcpsbge1.samsung.com (EPCPMTA) with SMTP id D2.F6.17976.C84C83F4;
	Mon, 13 Feb 2012 17:06:36 +0900 (KST)
Date: Mon, 13 Feb 2012 08:06:36 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080544603@jm77.ryu
Msgkey: 20120213080544603@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080444730@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 14/14] arm: implement basic interrupt handling
	mechanism.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <22301297.70441329120392655.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgYmFzaWMgaW50ZXJydXB0IGhhbmRsaW5nIG1lY2hhbmlzbS4NCg0KIHhl
bi9hcmNoL2FybS90ZWdyYS90ZWdyYTI1MC5jIHwgICAgOSArKystDQogeGVuL2FyY2gvYXJtL3hl
bi9jcHUuYyAgICAgICAgfCAgICA0ICstDQogeGVuL2FyY2gvYXJtL3hlbi9pcnEuYyAgICAgICAg
fCAgMjAxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLQ0KIDMgZmlsZXMgY2hhbmdlZCwg
MjA0IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQ0KDQpTaWduZWQtb2ZmLWJ5OiBKYWVt
aW4gUnl1IDxqbTc3LnJ5dUBzYW1zdW5nLmNvbT4NCg0KZGlmZiAtciAzZjFlNjRhOGY2MWEgeGVu
L2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMNCi0tLSBhL3hlbi9hcmNoL2FybS90ZWdyYS90ZWdy
YTI1MC5jCVN1biBGZWIgMTIgMTU6NDk6MTIgMjAxMiArMDkwMA0KKysrIGIveGVuL2FyY2gvYXJt
L3RlZ3JhL3RlZ3JhMjUwLmMJU3VuIEZlYiAxMiAxNjoxMjozOCAyMDEyICswOTAwDQpAQCAtMjQ1
LDEzICsyNDUsMjAgQEAgYXNtKA0KICIJLmxvbmcJdGVncmEyNTBfY29yZV9tYXAJCVxuIg0KICk7
DQogDQordm9pZCBtYWNoaW5lX3RyaWdnZXJfY3B1cyh1bnNpZ25lZCBsb25nIGNwdV9tYXAsIHVu
c2lnbmVkIGludCBldmVudCkNCit7DQorICAgICAgICBtbWlvX3dyaXRlbChjcHVfbWFwIDw8IDE2
IHwgZXZlbnQsIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBfSUNEU0dJUik7DQorfQ0KKw0KIGludCB3
YWtldXBfY3B1KHVuc2lnbmVkIGludCBjcHUpDQogew0KIAl0ZWdyYTI1MF9jb3JlX21hcCB8PSAx
IDw8ICBjcHU7DQogDQogCWNwdV9mbHVzaF9jYWNoZV9hbGwoKTsNCiANCi0JcmV0dXJuIDA7DQor
CW1hY2hpbmVfdHJpZ2dlcl9jcHVzKHRlZ3JhMjUwX2NvcmVfbWFwLCAxKTsNCisNCisJcmV0dXJu
IDE7DQogfQ0KIA0KIGV4dGVybiB2b2lkIHRlZ3JhMjUwX3NsYXZlX2NwdV9zdGFydCh2b2lkKTsN
CmRpZmYgLXIgM2YxZTY0YThmNjFhIHhlbi9hcmNoL2FybS94ZW4vY3B1LmMNCi0tLSBhL3hlbi9h
cmNoL2FybS94ZW4vY3B1LmMJU3VuIEZlYiAxMiAxNTo0OToxMiAyMDEyICswOTAwDQorKysgYi94
ZW4vYXJjaC9hcm0veGVuL2NwdS5jCVN1biBGZWIgMTIgMTY6MTI6MzggMjAxMiArMDkwMA0KQEAg
LTExNiw2ICsxMTYsOCBAQCBhc21saW5rYWdlIHZvaWQgc3RhcnRfeGVuX29uX3NsYXZlX2NwdSh2
DQogICAgICAgICB2ID0gaWRsZV92Y3B1W2NwdV07DQogCXNldF9jdXJyZW50KGlkbGVfdmNwdVtj
cHVdKTsNCiANCisJVkNQVV9SRUcodiwgdHRicjApID0gZ2V0X3R0YnIoKTsNCisNCiAJc2V0X2Nw
dV9zaWJsaW5nX21hcChjcHUpOw0KIA0KIAlub3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7DQpAQCAt
MTM5LDcgKzE0MSw3IEBAIHZvaWQgc21wX3NlbmRfZXZlbnRfY2hlY2tfbWFzayhjb25zdCBjcHUN
CiAJCW1hcCB8PSAxIDw8IGNwdTsNCiAJfQ0KIA0KLQkvKiBUcmlnZ2VyIHJlbW90ZSBDUFUgKi8N
CisJbWFjaGluZV90cmlnZ2VyX2NwdXMobWFwLCAxKTsNCiB9DQogDQogdm9pZCBzbXBfY2FsbF9m
dW5jdGlvbih2b2lkICgqZikodm9pZCAqcGFyYW0pLCB2b2lkICpwYXJhbSwgaW50IHdhaXQpDQpk
aWZmIC1yIDNmMWU2NGE4ZjYxYSB4ZW4vYXJjaC9hcm0veGVuL2lycS5jDQotLS0gYS94ZW4vYXJj
aC9hcm0veGVuL2lycS5jCVN1biBGZWIgMTIgMTU6NDk6MTIgMjAxMiArMDkwMA0KKysrIGIveGVu
L2FyY2gvYXJtL3hlbi9pcnEuYwlTdW4gRmViIDEyIDE2OjEyOjM4IDIwMTIgKzA5MDANCkBAIC00
Miw4ICs0Miw2IEBAIGh3X2lycV9jb250cm9sbGVyIG5vX2lycV90eXBlID0gew0KIAkuYWNrCSAg
PSBpcnFfYWNrX25vbmUsDQogfTsNCiANCi0vL3N0cnVjdCBpcnFfZGVzYyAqaXJxX2Rlc2M7DQot
DQogaXJxX2Rlc2NfdCBpcnFfZGVzY1tOUl9JUlFTXSA9IHsNCiAgICAgICAgIFswIC4uLiBOUl9J
UlFTIC0gMV0gPSB7DQogICAgICAgICAgICAgICAgIC5zdGF0dXMgPSBJUlFfRElTQUJMRUQsDQpA
QCAtNjAsNiArNTgsMzggQEAgc3RydWN0IGlycV9jZmcgaXJxX2NmZ1tOUl9JUlFTXSA9IHsNCiB9
Ow0KIA0KIA0KK3N0YXRpYyBpbmxpbmUgdm9pZCBzZXRfcGlycV9lb2koc3RydWN0IGRvbWFpbiAq
ZCwgdW5zaWduZWQgaW50IGlycSkNCit7DQorICAgICAgICBpZiAoZC0+YXJjaC5waXJxX2VvaV9t
YXApIHsNCisgICAgICAgICAgICAgICAgc2V0X2JpdChpcnEsIGQtPmFyY2gucGlycV9lb2lfbWFw
KTsNCisgICAgICAgIH0NCit9DQorDQorc3RhdGljIGlubGluZSB2b2lkIGNsZWFyX3BpcnFfZW9p
KHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBpcnEpDQorew0KKyAgICAgICAgaWYgKGQt
PmFyY2gucGlycV9lb2lfbWFwKSB7DQorICAgICAgICAgICAgICAgIGNsZWFyX2JpdChpcnEsIGQt
PmFyY2gucGlycV9lb2lfbWFwKTsNCisgICAgICAgIH0NCit9DQorDQordm9pZCBwaXJxX2d1ZXN0
X2VvaShzdHJ1Y3QgcGlycSAqcGlycSkNCit7DQorICAgICAgICBzdHJ1Y3QgaXJxX2Rlc2MgKmRl
c2M7DQorICAgICAgICB1bnNpZ25lZCBpbnQgZmxhZ3M7DQorDQorICAgICAgICBpZiAocGlycS0+
cGlycSA+PSBOUl9JUlFTKSB7DQorICAgICAgICAgICAgICAgIHJldHVybjsNCisgICAgICAgIH0N
CisNCisgICAgICAgIGRlc2MgPSBpcnFfdG9fZGVzYyhwaXJxLT5waXJxKTsNCisgICAgICAgIHNw
aW5fbG9ja19pcnFzYXZlKCZkZXNjLT5sb2NrLCBmbGFncyk7DQorDQorICAgICAgICBkZXNjLT5o
YW5kbGVyLT5lbmQoZGVzYyk7DQorDQorICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZk
ZXNjLT5sb2NrLCBmbGFncyk7DQorfQ0KKw0KKw0KIGludCBwaXJxX2d1ZXN0X3VubWFzayhzdHJ1
Y3QgZG9tYWluICpkKQ0KIHsNCiAJTk9UX1lFVCgpOw0KQEAgLTY3LDE2ICs5NywxMDUgQEAgaW50
IHBpcnFfZ3Vlc3RfdW5tYXNrKHN0cnVjdCBkb21haW4gKmQpDQogCXJldHVybiAwOw0KIH0NCiAN
CisNCiBpbnQgcGlycV9ndWVzdF9iaW5kKHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgcGlycSAqcGly
cSwgaW50IHdpbGxfc2hhcmUpDQogew0KLQlOT1RfWUVUKCk7DQorICAgICAgICBpbnQgcmMgPSAw
Ow0KKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOw0KKyAgICAgICAgaXJxX2d1ZXN0X2Fj
dGlvbl90ICphY3Rpb247DQorICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyAgICAgICAg
dW5zaWduZWQgaW50IGlycTsNCiANCi0JcmV0dXJuIDA7DQorICAgICAgICBpcnEgPSBwaXJxLT5w
aXJxOw0KKw0KKyAgICAgICAgaWYgKGlycSA+PSBOUl9JUlFTKSB7DQorICAgICAgICAgICAgICAg
IHJldHVybiAtRUlOVkFMOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgZGVzYyA9IGlycV90b19k
ZXNjKGlycSk7DQorDQorICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxh
Z3MpOw0KKw0KKyAgICAgICAgaWYgKCEoZGVzYy0+c3RhdHVzICYgSVJRX0dVRVNUKSkgew0KKyAg
ICAgICAgICAgICAgICBpZiAoZGVzYy0+YWN0aW9uICE9IE5VTEwpIHsNCisgICAgICAgICAgICAg
ICAgICAgICAgICByYyA9IC1FQlVTWTsNCisgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIG91
dDsNCisgICAgICAgICAgICAgICAgfQ0KKw0KKyAgICAgICAgICAgICAgICBhY3Rpb24gPSB4bWFs
bG9jKGlycV9ndWVzdF9hY3Rpb25fdCk7DQorICAgICAgICAgICAgICAgIGlmICgoZGVzYy0+YWN0
aW9uID0gKHN0cnVjdCBpcnFhY3Rpb24gKilhY3Rpb24pID09IE5VTEwgKSB7DQorICAgICAgICAg
ICAgICAgICAgICAgICAgcmMgPSAtRU5PTUVNOw0KKyAgICAgICAgICAgICAgICAgICAgICAgIGdv
dG8gb3V0Ow0KKyAgICAgICAgICAgICAgICB9DQorDQorICAgICAgICAgICAgICAgIGFjdGlvbi0+
c2hhcmVhYmxlID0gMTsNCisgICAgICAgICAgICAgICAgYWN0aW9uLT5ucl9ndWVzdHMgPSAwOw0K
KyAgICAgICAgICAgICAgICBhY3Rpb24tPmluX2ZsaWdodCA9IDA7DQorDQorICAgICAgICAgICAg
ICAgIGRlc2MtPnN0YXR1cyB8PSBJUlFfR1VFU1Q7DQorDQorICAgICAgICAgICAgICAgIGRlc2Mt
PmhhbmRsZXItPmVuYWJsZShkZXNjKTsNCisgICAgICAgIH0gZWxzZSBpZiAoIXdpbGxfc2hhcmUp
IHsNCisgICAgICAgICAgICAgICAgcmMgPSAtRUJVU1k7DQorICAgICAgICAgICAgICAgIGdvdG8g
b3V0Ow0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgaWYgKCBhY3Rpb24tPm5yX2d1ZXN0cyA9PSBJ
UlFfTUFYX0dVRVNUUyApIHsNCisgICAgICAgICAgICAgICAgcmMgPSAtRUJVU1k7DQorICAgICAg
ICAgICAgICAgIGdvdG8gb3V0Ow0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgYWN0aW9uLT5ndWVz
dFthY3Rpb24tPm5yX2d1ZXN0cysrXSA9IHYtPmRvbWFpbjsNCisNCitvdXQ6DQorICAgICAgICBz
cGluX3VubG9ja19pcnFyZXN0b3JlKCZkZXNjLT5sb2NrLCBmbGFncyk7DQorDQorICAgICAgICBy
ZXR1cm4gcmM7Ow0KIH0NCiANCiB2b2lkIHBpcnFfZ3Vlc3RfdW5iaW5kKHN0cnVjdCBkb21haW4g
KmQsIHN0cnVjdCBwaXJxICpwaXJxKQ0KIHsNCi0JTk9UX1lFVCgpOw0KKyAgICAgICAgc3RydWN0
IGlycV9kZXNjICpkZXNjOw0KKyAgICAgICAgdW5zaWduZWQgaW50IGZsYWdzLCBpcnEsIGk7DQor
ICAgICAgICBpcnFfZ3Vlc3RfYWN0aW9uX3QgKmFjdGlvbjsNCisNCisgICAgICAgIGlycSA9IHBp
cnEtPnBpcnE7DQorDQorICAgICAgICBpZiAoaXJxID49IE5SX0lSUVMpIHsNCisgICAgICAgICAg
ICAgICAgcmV0dXJuOw0KKyAgICAgICAgfQ0KKw0KKyAgICAgICAgZGVzYyA9IGlycV90b19kZXNj
KGlycSk7DQorDQorICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3Mp
Ow0KKw0KKyAgICAgICAgYWN0aW9uID0gKGlycV9ndWVzdF9hY3Rpb25fdCAqKWRlc2MtPmFjdGlv
bjsNCisNCisgICAgICAgIGlmICh1bmxpa2VseShhY3Rpb24gPT0gTlVMTCkpIHsNCisgICAgICAg
ICAgICAgICAgd2hpbGUoMSk7DQorICAgICAgICB9DQorDQorICAgICAgICBCVUdfT04oIShkZXNj
LT5zdGF0dXMgJiBJUlFfR1VFU1QpKTsNCisNCisNCisgICAgICAgIGlmICggYWN0aW9uLT5ucl9n
dWVzdHMgPT0gMSApIHsNCisgICAgICAgICAgICAgICAgZGVzYy0+YWN0aW9uID0gTlVMTDsNCisg
ICAgICAgICAgICAgICAgeGZyZWUoYWN0aW9uKTsNCisNCisgICAgICAgICAgICAgICAgZGVzYy0+
c3RhdHVzICY9IH5JUlFfR1VFU1Q7DQorICAgICAgICB9IGVsc2Ugew0KKyAgICAgICAgICAgICAg
ICBpID0gMDsNCisgICAgICAgICAgICAgICAgd2hpbGUgKCBhY3Rpb24tPmd1ZXN0W2ldICYmIChh
Y3Rpb24tPmd1ZXN0W2ldICE9IGQpICkNCisgICAgICAgICAgICAgICAgICAgICAgICBpKys7DQor
ICAgICAgICAgICAgICAgIG1lbW1vdmUoJmFjdGlvbi0+Z3Vlc3RbaV0sICZhY3Rpb24tPmd1ZXN0
W2krMV0sIChhY3Rpb24tPm5yX2d1ZXN0cyAtIGkgLSAxKSAqIHNpemVvZihhY3Rpb24tPmd1ZXN0
WzBdKSk7DQorICAgICAgICAgICAgICAgIGFjdGlvbi0+bnJfZ3Vlc3RzLS07DQorICAgICAgICB9
DQorDQorICAgICAgICBkZXNjLT5zdGF0dXMgfD0gSVJRX0RJU0FCTEVEOw0KKw0KKyAgICAgICAg
ZGVzYy0+aGFuZGxlci0+ZGlzYWJsZShkZXNjKTsNCisNCisgICAgICAgIHNwaW5fdW5sb2NrX2ly
cXJlc3RvcmUoJmRlc2MtPmxvY2ssIGZsYWdzKTsNCiB9DQogDQogDQpAQCAtODUsMTIgKzIwNCwx
NyBAQCB2b2lkIHBpcnFfc2V0X2FmZmluaXR5KHN0cnVjdCBkb21haW4gKmQsDQogCU5PVF9ZRVQo
KTsNCiB9DQogDQotDQogc3RydWN0IHBpcnEgKmFsbG9jX3BpcnFfc3RydWN0KHN0cnVjdCBkb21h
aW4gKmQpDQogew0KLQlOT1RfWUVUKCk7DQorICAgICAgICBzdHJ1Y3QgcGlycSAqcGlycTsNCiAN
Ci0JcmV0dXJuIE5VTEw7DQorICAgICAgICBwaXJxID0geG1hbGxvYyhzdHJ1Y3QgcGlycSk7DQor
DQorICAgICAgICBpZiAoIXBpcnEpIHsNCisgICAgICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQor
ICAgICAgICB9DQorDQorICAgICAgICByZXR1cm4gcGlycTsNCiB9DQogDQogaW50IHNldHVwX2ly
cSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1Y3QgaXJxYWN0aW9uICpuZXcpDQpAQCAtMTE5LDYgKzI0
Myw2NyBAQCBpbnQgc2V0dXBfaXJxKHVuc2lnbmVkIGludCBpcnEsIHN0cnVjdCBpDQogCXJldHVy
biAwOw0KIH0NCiANCit2b2lkIGRvX2d1ZXN0X2lycSh1bnNpZ25lZCBpbnQgaXJxKQ0KK3sNCisg
ICAgICAgIGludCBpOw0KKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOw0KKyAgICAgICAg
c3RydWN0IGRvbWFpbiAqZDsNCisgICAgICAgIHN0cnVjdCBwaXJxICpwaXJxOw0KKw0KKyAgICAg
ICAgaXJxX2d1ZXN0X2FjdGlvbl90ICphY3Rpb247DQorDQorICAgICAgICBkZXNjID0gaXJxX3Rv
X2Rlc2MoaXJxKTsNCisNCisgICAgICAgIGFjdGlvbiA9IChpcnFfZ3Vlc3RfYWN0aW9uX3QgKilk
ZXNjLT5hY3Rpb247DQorICAgICAgICBmb3IgKGkgPSAwOyBpIDwgYWN0aW9uLT5ucl9ndWVzdHM7
IGkrKykgew0KKyAgICAgICAgICAgICAgICBkID0gYWN0aW9uLT5ndWVzdFtpXTsNCisgICAgICAg
ICAgICAgICAgcGlycSA9IHBpcnFfaW5mbyhkLCBpcnEpOw0KKyAgICAgICAgICAgICAgICBhY3Rp
b24tPmluX2ZsaWdodCsrOw0KKyAgICAgICAgICAgICAgICBzZW5kX2d1ZXN0X3BpcnEoZCwgcGly
cSk7DQorICAgICAgICB9DQorDQorDQorfQ0KKw0KK2FzbWxpbmthZ2Ugdm9pZCBkb19pcGkodW5z
aWduZWQgaW50IGlwaSwgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQorew0KK30NCisNCith
c21saW5rYWdlIHZvaWQgZG9faXJxKHVuc2lnbmVkIGludCBpcnEsIHN0cnVjdCBjcHVfdXNlcl9y
ZWdzICpyZWdzKQ0KK3sNCisgICAgICAgIHN0cnVjdCBpcnFfZGVzYyAqZGVzYzsNCisgICAgICAg
IHN0cnVjdCBpcnFhY3Rpb24gKmFjdGlvbjsNCisNCisgICAgICAgIGlmIChpcnEgPj0gTlJfSVJR
Uykgew0KKyAgICAgICAgICAgICAgICBwcmludGsoIkJhZCBJUlEgPSAlZFxuIiwgaXJxKTsNCisg
ICAgICAgIH0NCisNCisgICAgICAgIGRlc2MgPSBpcnFfdG9fZGVzYyhpcnEpOw0KKw0KKyAgICAg
ICAgc3Bpbl9sb2NrKCZkZXNjLT5sb2NrKTsNCisNCisgICAgICAgIGRlc2MtPmhhbmRsZXItPmFj
ayhkZXNjKTsNCisNCisNCisgICAgICAgIGlmIChsaWtlbHkoZGVzYy0+c3RhdHVzICYgSVJRX0dV
RVNUKSkgew0KKyAgICAgICAgICAgICAgICBkb19ndWVzdF9pcnEoaXJxKTsNCisgICAgICAgICAg
ICAgICAgc3Bpbl91bmxvY2soJmRlc2MtPmxvY2spOw0KKw0KKyAgICAgICAgICAgICAgICByZXR1
cm47DQorICAgICAgICB9DQorDQorICAgICAgICBhY3Rpb24gPSBkZXNjLT5hY3Rpb247DQorDQor
ICAgICAgICBCVUdfT04oIWFjdGlvbik7DQorDQorICAgICAgICBzcGluX3VubG9jaygmZGVzYy0+
bG9jayk7DQorDQorICAgICAgICBhY3Rpb24tPmhhbmRsZXIoaXJxLCBhY3Rpb24tPmRldl9pZCwg
cmVncyk7DQorDQorICAgICAgICBkZXNjLT5oYW5kbGVyLT5lbmQoZGVzYyk7DQorfQ0KKw0KKw0K
IGludCBhcmNoX2luaXRfb25lX2lycV9kZXNjKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQog
CU5PVF9ZRVQoKTsNCg==


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch14.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch14.diff"


YXJtOiBpbXBsZW1lbnQgYmFzaWMgaW50ZXJydXB0IGhhbmRsaW5nIG1lY2hhbmlzbS4KCiB4
ZW4vYXJjaC9hcm0vdGVncmEvdGVncmEyNTAuYyB8ICAgIDkgKysrLQogeGVuL2FyY2gvYXJt
L3hlbi9jcHUuYyAgICAgICAgfCAgICA0ICstCiB4ZW4vYXJjaC9hcm0veGVuL2lycS5jICAg
ICAgICB8ICAyMDEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tCiAzIGZpbGVz
IGNoYW5nZWQsIDIwNCBpbnNlcnRpb25zKCspLCAxMCBkZWxldGlvbnMoLSkKClNpZ25lZC1v
ZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciAzZjFl
NjRhOGY2MWEgeGVuL2FyY2gvYXJtL3RlZ3JhL3RlZ3JhMjUwLmMKLS0tIGEveGVuL2FyY2gv
YXJtL3RlZ3JhL3RlZ3JhMjUwLmMJU3VuIEZlYiAxMiAxNTo0OToxMiAyMDEyICswOTAwCisr
KyBiL3hlbi9hcmNoL2FybS90ZWdyYS90ZWdyYTI1MC5jCVN1biBGZWIgMTIgMTY6MTI6Mzgg
MjAxMiArMDkwMApAQCAtMjQ1LDEzICsyNDUsMjAgQEAgYXNtKAogIgkubG9uZwl0ZWdyYTI1
MF9jb3JlX21hcAkJXG4iCiApOwogCit2b2lkIG1hY2hpbmVfdHJpZ2dlcl9jcHVzKHVuc2ln
bmVkIGxvbmcgY3B1X21hcCwgdW5zaWduZWQgaW50IGV2ZW50KQoreworICAgICAgICBtbWlv
X3dyaXRlbChjcHVfbWFwIDw8IDE2IHwgZXZlbnQsIHRlZ3JhX2dpY19kaXN0X2Jhc2UgKyBf
SUNEU0dJUik7Cit9CisKIGludCB3YWtldXBfY3B1KHVuc2lnbmVkIGludCBjcHUpCiB7CiAJ
dGVncmEyNTBfY29yZV9tYXAgfD0gMSA8PCAgY3B1OwogCiAJY3B1X2ZsdXNoX2NhY2hlX2Fs
bCgpOwogCi0JcmV0dXJuIDA7CisJbWFjaGluZV90cmlnZ2VyX2NwdXModGVncmEyNTBfY29y
ZV9tYXAsIDEpOworCisJcmV0dXJuIDE7CiB9CiAKIGV4dGVybiB2b2lkIHRlZ3JhMjUwX3Ns
YXZlX2NwdV9zdGFydCh2b2lkKTsKZGlmZiAtciAzZjFlNjRhOGY2MWEgeGVuL2FyY2gvYXJt
L3hlbi9jcHUuYwotLS0gYS94ZW4vYXJjaC9hcm0veGVuL2NwdS5jCVN1biBGZWIgMTIgMTU6
NDk6MTIgMjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NwdS5jCVN1biBGZWIg
MTIgMTY6MTI6MzggMjAxMiArMDkwMApAQCAtMTE2LDYgKzExNiw4IEBAIGFzbWxpbmthZ2Ug
dm9pZCBzdGFydF94ZW5fb25fc2xhdmVfY3B1KHYKICAgICAgICAgdiA9IGlkbGVfdmNwdVtj
cHVdOwogCXNldF9jdXJyZW50KGlkbGVfdmNwdVtjcHVdKTsKIAorCVZDUFVfUkVHKHYsIHR0
YnIwKSA9IGdldF90dGJyKCk7CisKIAlzZXRfY3B1X3NpYmxpbmdfbWFwKGNwdSk7CiAKIAlu
b3RpZnlfY3B1X3N0YXJ0aW5nKGNwdSk7CkBAIC0xMzksNyArMTQxLDcgQEAgdm9pZCBzbXBf
c2VuZF9ldmVudF9jaGVja19tYXNrKGNvbnN0IGNwdQogCQltYXAgfD0gMSA8PCBjcHU7CiAJ
fQogCi0JLyogVHJpZ2dlciByZW1vdGUgQ1BVICovCisJbWFjaGluZV90cmlnZ2VyX2NwdXMo
bWFwLCAxKTsKIH0KIAogdm9pZCBzbXBfY2FsbF9mdW5jdGlvbih2b2lkICgqZikodm9pZCAq
cGFyYW0pLCB2b2lkICpwYXJhbSwgaW50IHdhaXQpCmRpZmYgLXIgM2YxZTY0YThmNjFhIHhl
bi9hcmNoL2FybS94ZW4vaXJxLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9pcnEuYwlTdW4g
RmViIDEyIDE1OjQ5OjEyIDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9pcnEu
YwlTdW4gRmViIDEyIDE2OjEyOjM4IDIwMTIgKzA5MDAKQEAgLTQyLDggKzQyLDYgQEAgaHdf
aXJxX2NvbnRyb2xsZXIgbm9faXJxX3R5cGUgPSB7CiAJLmFjawkgID0gaXJxX2Fja19ub25l
LAogfTsKIAotLy9zdHJ1Y3QgaXJxX2Rlc2MgKmlycV9kZXNjOwotCiBpcnFfZGVzY190IGly
cV9kZXNjW05SX0lSUVNdID0gewogICAgICAgICBbMCAuLi4gTlJfSVJRUyAtIDFdID0gewog
ICAgICAgICAgICAgICAgIC5zdGF0dXMgPSBJUlFfRElTQUJMRUQsCkBAIC02MCw2ICs1OCwz
OCBAQCBzdHJ1Y3QgaXJxX2NmZyBpcnFfY2ZnW05SX0lSUVNdID0gewogfTsKIAogCitzdGF0
aWMgaW5saW5lIHZvaWQgc2V0X3BpcnFfZW9pKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVk
IGludCBpcnEpCit7CisgICAgICAgIGlmIChkLT5hcmNoLnBpcnFfZW9pX21hcCkgeworICAg
ICAgICAgICAgICAgIHNldF9iaXQoaXJxLCBkLT5hcmNoLnBpcnFfZW9pX21hcCk7CisgICAg
ICAgIH0KK30KKworc3RhdGljIGlubGluZSB2b2lkIGNsZWFyX3BpcnFfZW9pKHN0cnVjdCBk
b21haW4gKmQsIHVuc2lnbmVkIGludCBpcnEpCit7CisgICAgICAgIGlmIChkLT5hcmNoLnBp
cnFfZW9pX21hcCkgeworICAgICAgICAgICAgICAgIGNsZWFyX2JpdChpcnEsIGQtPmFyY2gu
cGlycV9lb2lfbWFwKTsKKyAgICAgICAgfQorfQorCit2b2lkIHBpcnFfZ3Vlc3RfZW9pKHN0
cnVjdCBwaXJxICpwaXJxKQoreworICAgICAgICBzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2M7Cisg
ICAgICAgIHVuc2lnbmVkIGludCBmbGFnczsKKworICAgICAgICBpZiAocGlycS0+cGlycSA+
PSBOUl9JUlFTKSB7CisgICAgICAgICAgICAgICAgcmV0dXJuOworICAgICAgICB9CisKKyAg
ICAgICAgZGVzYyA9IGlycV90b19kZXNjKHBpcnEtPnBpcnEpOworICAgICAgICBzcGluX2xv
Y2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3MpOworCisgICAgICAgIGRlc2MtPmhhbmRs
ZXItPmVuZChkZXNjKTsKKworICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZkZXNj
LT5sb2NrLCBmbGFncyk7Cit9CisKKwogaW50IHBpcnFfZ3Vlc3RfdW5tYXNrKHN0cnVjdCBk
b21haW4gKmQpCiB7CiAJTk9UX1lFVCgpOwpAQCAtNjcsMTYgKzk3LDEwNSBAQCBpbnQgcGly
cV9ndWVzdF91bm1hc2soc3RydWN0IGRvbWFpbiAqZCkKIAlyZXR1cm4gMDsKIH0KIAorCiBp
bnQgcGlycV9ndWVzdF9iaW5kKHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgcGlycSAqcGlycSwg
aW50IHdpbGxfc2hhcmUpCiB7Ci0JTk9UX1lFVCgpOworICAgICAgICBpbnQgcmMgPSAwOwor
ICAgICAgICBzdHJ1Y3QgaXJxX2Rlc2MgKmRlc2M7CisgICAgICAgIGlycV9ndWVzdF9hY3Rp
b25fdCAqYWN0aW9uOworICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOworICAgICAgICB1
bnNpZ25lZCBpbnQgaXJxOwogCi0JcmV0dXJuIDA7CisgICAgICAgIGlycSA9IHBpcnEtPnBp
cnE7CisKKyAgICAgICAgaWYgKGlycSA+PSBOUl9JUlFTKSB7CisgICAgICAgICAgICAgICAg
cmV0dXJuIC1FSU5WQUw7CisgICAgICAgIH0KKworICAgICAgICBkZXNjID0gaXJxX3RvX2Rl
c2MoaXJxKTsKKworICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxh
Z3MpOworCisgICAgICAgIGlmICghKGRlc2MtPnN0YXR1cyAmIElSUV9HVUVTVCkpIHsKKyAg
ICAgICAgICAgICAgICBpZiAoZGVzYy0+YWN0aW9uICE9IE5VTEwpIHsKKyAgICAgICAgICAg
ICAgICAgICAgICAgIHJjID0gLUVCVVNZOworICAgICAgICAgICAgICAgICAgICAgICAgZ290
byBvdXQ7CisgICAgICAgICAgICAgICAgfQorCisgICAgICAgICAgICAgICAgYWN0aW9uID0g
eG1hbGxvYyhpcnFfZ3Vlc3RfYWN0aW9uX3QpOworICAgICAgICAgICAgICAgIGlmICgoZGVz
Yy0+YWN0aW9uID0gKHN0cnVjdCBpcnFhY3Rpb24gKilhY3Rpb24pID09IE5VTEwgKSB7Cisg
ICAgICAgICAgICAgICAgICAgICAgICByYyA9IC1FTk9NRU07CisgICAgICAgICAgICAgICAg
ICAgICAgICBnb3RvIG91dDsKKyAgICAgICAgICAgICAgICB9CisKKyAgICAgICAgICAgICAg
ICBhY3Rpb24tPnNoYXJlYWJsZSA9IDE7CisgICAgICAgICAgICAgICAgYWN0aW9uLT5ucl9n
dWVzdHMgPSAwOworICAgICAgICAgICAgICAgIGFjdGlvbi0+aW5fZmxpZ2h0ID0gMDsKKwor
ICAgICAgICAgICAgICAgIGRlc2MtPnN0YXR1cyB8PSBJUlFfR1VFU1Q7CisKKyAgICAgICAg
ICAgICAgICBkZXNjLT5oYW5kbGVyLT5lbmFibGUoZGVzYyk7CisgICAgICAgIH0gZWxzZSBp
ZiAoIXdpbGxfc2hhcmUpIHsKKyAgICAgICAgICAgICAgICByYyA9IC1FQlVTWTsKKyAgICAg
ICAgICAgICAgICBnb3RvIG91dDsKKyAgICAgICAgfQorCisgICAgICAgIGlmICggYWN0aW9u
LT5ucl9ndWVzdHMgPT0gSVJRX01BWF9HVUVTVFMgKSB7CisgICAgICAgICAgICAgICAgcmMg
PSAtRUJVU1k7CisgICAgICAgICAgICAgICAgZ290byBvdXQ7CisgICAgICAgIH0KKworICAg
ICAgICBhY3Rpb24tPmd1ZXN0W2FjdGlvbi0+bnJfZ3Vlc3RzKytdID0gdi0+ZG9tYWluOwor
CitvdXQ6CisgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ssIGZs
YWdzKTsKKworICAgICAgICByZXR1cm4gcmM7OwogfQogCiB2b2lkIHBpcnFfZ3Vlc3RfdW5i
aW5kKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBwaXJxICpwaXJxKQogewotCU5PVF9ZRVQo
KTsKKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOworICAgICAgICB1bnNpZ25lZCBp
bnQgZmxhZ3MsIGlycSwgaTsKKyAgICAgICAgaXJxX2d1ZXN0X2FjdGlvbl90ICphY3Rpb247
CisKKyAgICAgICAgaXJxID0gcGlycS0+cGlycTsKKworICAgICAgICBpZiAoaXJxID49IE5S
X0lSUVMpIHsKKyAgICAgICAgICAgICAgICByZXR1cm47CisgICAgICAgIH0KKworICAgICAg
ICBkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsKKworICAgICAgICBzcGluX2xvY2tfaXJxc2F2
ZSgmZGVzYy0+bG9jaywgZmxhZ3MpOworCisgICAgICAgIGFjdGlvbiA9IChpcnFfZ3Vlc3Rf
YWN0aW9uX3QgKilkZXNjLT5hY3Rpb247CisKKyAgICAgICAgaWYgKHVubGlrZWx5KGFjdGlv
biA9PSBOVUxMKSkgeworICAgICAgICAgICAgICAgIHdoaWxlKDEpOworICAgICAgICB9CisK
KyAgICAgICAgQlVHX09OKCEoZGVzYy0+c3RhdHVzICYgSVJRX0dVRVNUKSk7CisKKworICAg
ICAgICBpZiAoIGFjdGlvbi0+bnJfZ3Vlc3RzID09IDEgKSB7CisgICAgICAgICAgICAgICAg
ZGVzYy0+YWN0aW9uID0gTlVMTDsKKyAgICAgICAgICAgICAgICB4ZnJlZShhY3Rpb24pOwor
CisgICAgICAgICAgICAgICAgZGVzYy0+c3RhdHVzICY9IH5JUlFfR1VFU1Q7CisgICAgICAg
IH0gZWxzZSB7CisgICAgICAgICAgICAgICAgaSA9IDA7CisgICAgICAgICAgICAgICAgd2hp
bGUgKCBhY3Rpb24tPmd1ZXN0W2ldICYmIChhY3Rpb24tPmd1ZXN0W2ldICE9IGQpICkKKyAg
ICAgICAgICAgICAgICAgICAgICAgIGkrKzsKKyAgICAgICAgICAgICAgICBtZW1tb3ZlKCZh
Y3Rpb24tPmd1ZXN0W2ldLCAmYWN0aW9uLT5ndWVzdFtpKzFdLCAoYWN0aW9uLT5ucl9ndWVz
dHMgLSBpIC0gMSkgKiBzaXplb2YoYWN0aW9uLT5ndWVzdFswXSkpOworICAgICAgICAgICAg
ICAgIGFjdGlvbi0+bnJfZ3Vlc3RzLS07CisgICAgICAgIH0KKworICAgICAgICBkZXNjLT5z
dGF0dXMgfD0gSVJRX0RJU0FCTEVEOworCisgICAgICAgIGRlc2MtPmhhbmRsZXItPmRpc2Fi
bGUoZGVzYyk7CisKKyAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZGVzYy0+bG9j
aywgZmxhZ3MpOwogfQogCiAKQEAgLTg1LDEyICsyMDQsMTcgQEAgdm9pZCBwaXJxX3NldF9h
ZmZpbml0eShzdHJ1Y3QgZG9tYWluICpkLAogCU5PVF9ZRVQoKTsKIH0KIAotCiBzdHJ1Y3Qg
cGlycSAqYWxsb2NfcGlycV9zdHJ1Y3Qoc3RydWN0IGRvbWFpbiAqZCkKIHsKLQlOT1RfWUVU
KCk7CisgICAgICAgIHN0cnVjdCBwaXJxICpwaXJxOwogCi0JcmV0dXJuIE5VTEw7CisgICAg
ICAgIHBpcnEgPSB4bWFsbG9jKHN0cnVjdCBwaXJxKTsKKworICAgICAgICBpZiAoIXBpcnEp
IHsKKyAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsKKyAgICAgICAgfQorCisgICAgICAg
IHJldHVybiBwaXJxOwogfQogCiBpbnQgc2V0dXBfaXJxKHVuc2lnbmVkIGludCBpcnEsIHN0
cnVjdCBpcnFhY3Rpb24gKm5ldykKQEAgLTExOSw2ICsyNDMsNjcgQEAgaW50IHNldHVwX2ly
cSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1Y3QgaQogCXJldHVybiAwOwogfQogCit2b2lkIGRv
X2d1ZXN0X2lycSh1bnNpZ25lZCBpbnQgaXJxKQoreworICAgICAgICBpbnQgaTsKKyAgICAg
ICAgc3RydWN0IGlycV9kZXNjICpkZXNjOworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOwor
ICAgICAgICBzdHJ1Y3QgcGlycSAqcGlycTsKKworICAgICAgICBpcnFfZ3Vlc3RfYWN0aW9u
X3QgKmFjdGlvbjsKKworICAgICAgICBkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsKKworICAg
ICAgICBhY3Rpb24gPSAoaXJxX2d1ZXN0X2FjdGlvbl90ICopZGVzYy0+YWN0aW9uOworICAg
ICAgICBmb3IgKGkgPSAwOyBpIDwgYWN0aW9uLT5ucl9ndWVzdHM7IGkrKykgeworICAgICAg
ICAgICAgICAgIGQgPSBhY3Rpb24tPmd1ZXN0W2ldOworICAgICAgICAgICAgICAgIHBpcnEg
PSBwaXJxX2luZm8oZCwgaXJxKTsKKyAgICAgICAgICAgICAgICBhY3Rpb24tPmluX2ZsaWdo
dCsrOworICAgICAgICAgICAgICAgIHNlbmRfZ3Vlc3RfcGlycShkLCBwaXJxKTsKKyAgICAg
ICAgfQorCisKK30KKworYXNtbGlua2FnZSB2b2lkIGRvX2lwaSh1bnNpZ25lZCBpbnQgaXBp
LCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykKK3sKK30KKworYXNtbGlua2FnZSB2b2lk
IGRvX2lycSh1bnNpZ25lZCBpbnQgaXJxLCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykK
K3sKKyAgICAgICAgc3RydWN0IGlycV9kZXNjICpkZXNjOworICAgICAgICBzdHJ1Y3QgaXJx
YWN0aW9uICphY3Rpb247CisKKyAgICAgICAgaWYgKGlycSA+PSBOUl9JUlFTKSB7CisgICAg
ICAgICAgICAgICAgcHJpbnRrKCJCYWQgSVJRID0gJWRcbiIsIGlycSk7CisgICAgICAgIH0K
KworICAgICAgICBkZXNjID0gaXJxX3RvX2Rlc2MoaXJxKTsKKworICAgICAgICBzcGluX2xv
Y2soJmRlc2MtPmxvY2spOworCisgICAgICAgIGRlc2MtPmhhbmRsZXItPmFjayhkZXNjKTsK
KworCisgICAgICAgIGlmIChsaWtlbHkoZGVzYy0+c3RhdHVzICYgSVJRX0dVRVNUKSkgewor
ICAgICAgICAgICAgICAgIGRvX2d1ZXN0X2lycShpcnEpOworICAgICAgICAgICAgICAgIHNw
aW5fdW5sb2NrKCZkZXNjLT5sb2NrKTsKKworICAgICAgICAgICAgICAgIHJldHVybjsKKyAg
ICAgICAgfQorCisgICAgICAgIGFjdGlvbiA9IGRlc2MtPmFjdGlvbjsKKworICAgICAgICBC
VUdfT04oIWFjdGlvbik7CisKKyAgICAgICAgc3Bpbl91bmxvY2soJmRlc2MtPmxvY2spOwor
CisgICAgICAgIGFjdGlvbi0+aGFuZGxlcihpcnEsIGFjdGlvbi0+ZGV2X2lkLCByZWdzKTsK
KworICAgICAgICBkZXNjLT5oYW5kbGVyLT5lbmQoZGVzYyk7Cit9CisKKwogaW50IGFyY2hf
aW5pdF9vbmVfaXJxX2Rlc2Moc3RydWN0IGlycV9kZXNjICpkZXNjKQogewogCU5PVF9ZRVQo
KTsK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt18-0005z6-2x; Mon, 13 Feb 2012 10:20:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jm77.ryu@samsung.com>) id 1Rwqre-0003vN-59
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 08:02:22 +0000
Received: from [85.158.139.83:57535] by server-3.bemta-5.messagelabs.com id
	7B/A1-25605-D83C83F4; Mon, 13 Feb 2012 08:02:21 +0000
X-Env-Sender: jm77.ryu@samsung.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329120139!7453076!2
X-Originating-IP: [203.254.224.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjI1NC4yMjQuMzQgPT4gMjQwMTQ5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32110 invoked from network); 13 Feb 2012 08:02:20 -0000
Received: from mailout4.samsung.com (HELO mailout4.samsung.com)
	(203.254.224.34) by server-16.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 08:02:20 -0000
Received: from epcpsbge3.samsung.com (mailout4.samsung.com [203.254.224.34])
	by mailout4.samsung.com
	(Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built
	Sep 7
	2010)) with ESMTP id <0LZB00149NNT2XB0@mailout4.samsung.com> for
	xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:02:19 +0900 (KST)
Message-id: <0LZB0014JNNV2XB0@mailout4.samsung.com>
X-AuditID: cbfee60d-b7cbaae00000452e-00-4f38c38ac9d5
Received: from epextmailer03 ( [203.254.219.153])
	by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 60.FD.17710.A83C83F4;
	Mon, 13 Feb 2012 17:02:18 +0900 (KST)
Date: Mon, 13 Feb 2012 08:02:18 +0000 (GMT)
From: =?euc-kr?B?t/nA57nO?= <jm77.ryu@samsung.com>
To: Jae-Min Ryu <jm77.ryu@samsung.com>, Lars Kurth <lars.kurth@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-version: 1.0
X-MTR: 20120213080134863@jm77.ryu
Msgkey: 20120213080134863@jm77.ryu
X-EPLocale: ko_KR.euc-kr
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20120213074805604@jm77.ryu
X-ParentMTR: 20120213080044709@jm77.ryu
Content-type: multipart/mixed;
	boundary="----=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY"
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 13 Feb 2012 10:20:11 +0000
Cc: =?euc-kr?Q?=BC=AD=BB=F3=B9=FC?= <sbuk.suh@samsung.com>
Subject: [Xen-devel] [PATCH 10/14]  arm: implement ARMv7 tlb ops.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: jm77.ryu@samsung.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="euc-kr"
MIME-Version: 1.0
Message-ID: <3414607.70211329120135179.JavaMail.weblogic@epv6ml04>

YXJtOiBpbXBsZW1lbnQgQVJNdjcgdGxiIG9wcy4NCg0KIHhlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUgICAgICAgfCAgIDEgKw0KIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUyAgICAgfCAgMTcg
KysrKystLS0tLS0tLS0tLS0NCiB4ZW4vYXJjaC9hcm0veGVuL2RvbWFpbl9idWlsZC5jIHwgICA2
ICsrKy0tLQ0KIHhlbi9hcmNoL2FybS94ZW4vdGxiLXY3LlMgICAgICAgfCAgNTEgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogNCBmaWxlcyBjaGFu
Z2VkLCA2MCBpbnNlcnRpb25zKCspLCAxNSBkZWxldGlvbnMoLSkNCg0KU2lnbmVkLW9mZi1ieTog
SmFlbWluIFJ5dSA8am03Ny5yeXVAc2Ftc3VuZy5jb20+DQoNCmRpZmYgLXIgYzZhNDEyYWRmYWU3
IHhlbi9hcmNoL2FybS94ZW4vTWFrZWZpbGUNCi0tLSBhL3hlbi9hcmNoL2FybS94ZW4vTWFrZWZp
bGUJU3VuIEZlYiAxMiAxMjowNTozNiAyMDEyICswOTAwDQorKysgYi94ZW4vYXJjaC9hcm0veGVu
L01ha2VmaWxlCVN1biBGZWIgMTIgMTI6MjQ6MDkgMjAxMiArMDkwMA0KQEAgLTIzLDMgKzIzLDQg
QEAgb2JqLXkgKz0gcGVyZm1vbi5vDQogb2JqLXkgKz0gcGNpLm8NCiBvYmoteSArPSBhcm12Ny5v
DQogb2JqLXkgKz0gY2FjaGUtdjcubw0KK29iai15ICs9IHRsYi12Ny5vDQpkaWZmIC1yIGM2YTQx
MmFkZmFlNyB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMNCi0tLSBhL3hlbi9hcmNoL2FybS94
ZW4vY2FjaGUtdjcuUwlTdW4gRmViIDEyIDEyOjA1OjM2IDIwMTIgKzA5MDANCisrKyBiL3hlbi9h
cmNoL2FybS94ZW4vY2FjaGUtdjcuUwlTdW4gRmViIDEyIDEyOjI0OjA5IDIwMTIgKzA5MDANCkBA
IC0xLDcgKzEsNiBAQA0KLSNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPg0KKyNpbmNsdWRlIDx4ZW4v
Y29uZmlnLmg+DQorI2luY2x1ZGUgPGFzbS9hc20tbWFjcm9zLmg+DQogI2luY2x1ZGUgPGFzbS9w
YWdlLmg+DQotI2luY2x1ZGUgPGFzbS9jcHUtb3BzLmg+DQotI2luY2x1ZGUgPGFzbS9zeXN0ZW0u
aD4NCiAjaW5jbHVkZSA8YXNtL2FzbS1vZmZzZXRzLmg+DQogDQogCS5tYWNybyB2N193YXlfb3As
IG9wDQpAQCAtNDksNyArNDgsNyBAQCA1MDoNCiAJLmVuZG0NCiAJLnRleHQNCiANCi1QUklWQVRF
KHY3X2ZsdXNoX2NhY2hlX2FsbCkNCitFTlRSWShjcHVfZmx1c2hfY2FjaGVfYWxsKQ0KIAlzdG1m
ZAlzcCEsIHtyNC1yNSwgcjcsIHI5LXIxMSwgbHJ9DQogDQogCXY3X3dheV9vcCBjMTQNCkBAIC01
OSw5ICs1OCw3IEBAIFBSSVZBVEUodjdfZmx1c2hfY2FjaGVfYWxsKQ0KIAlsZG1mZAlzcCEsIHty
NC1yNSwgcjcsIHI5LXIxMSwgbHJ9DQogCW1vdglwYywgbHINCiANCi1ERUNMQVJFX0NQVV9PUChj
cHVfZmx1c2hfY2FjaGVfYWxsLCB2N19mbHVzaF9jYWNoZV9hbGwpDQotDQotUFJJVkFURSh2N19m
bHVzaF9jYWNoZV9yYW5nZSkNCitFTlRSWShjcHVfZmx1c2hfY2FjaGVfcmFuZ2UpDQogCW1yYyAg
ICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUg0KIAlhbmQgICAgIHIzLCByMywg
IzcJCUAgY2FjaGUgbGluZSBzaXplIGVuY29kaW5nDQogCW1vdiAgICAgcjMsICMxNgkJCUAgc2l6
ZSBvZmZzZXQNCkBAIC03NCw5ICs3MSw3IEBAIDE6DQogCWRzYg0KIAltb3YJcGMsIGxyDQogDQot
REVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNoX2NhY2hlX3JhbmdlLCB2N19mbHVzaF9jYWNoZV9yYW5n
ZSkNCi0NCi1QUklWQVRFKHY3X2NsZWFuX2NhY2hlX3JhbmdlKQ0KK0VOVFJZKGNwdV9jbGVhbl9j
YWNoZV9yYW5nZSkNCiAJbXJjICAgICBwMTUsIDEsIHIzLCBjMCwgYzAsIDAJQCByZWFkIENTSURS
DQogCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcNCiAJbW92
ICAgICByMywgIzE2CQkJQCBzaXplIG9mZnNldA0KQEAgLTkwLDUgKzg1LDMgQEAgMToNCiAJZHNi
DQogCW1vdglwYywgbHINCiANCi1ERUNMQVJFX0NQVV9PUChjcHVfY2xlYW5fY2FjaGVfcmFuZ2Us
IHY3X2NsZWFuX2NhY2hlX3JhbmdlKQ0KLQ0KZGlmZiAtciBjNmE0MTJhZGZhZTcgeGVuL2FyY2gv
YXJtL3hlbi9kb21haW5fYnVpbGQuYw0KLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9kb21haW5fYnVp
bGQuYwlTdW4gRmViIDEyIDEyOjA1OjM2IDIwMTIgKzA5MDANCisrKyBiL3hlbi9hcmNoL2FybS94
ZW4vZG9tYWluX2J1aWxkLmMJU3VuIEZlYiAxMiAxMjoyNDowOSAyMDEyICswOTAwDQpAQCAtMTc2
LDcgKzE3Niw3IEBAIGludCBkb21haW5fY29uc3RydWN0KHN0cnVjdCBkb21haW4gKmQsDQogCX0g
d2hpbGUoZ3B0KyssIHBtYXAgPCBwZW5kKTsNCiAgDQogCS8qIEFjdGl2YXRlIGd1ZXN0IGFkZHJl
c3Mgc3BhY2UgdG8gcmVsb2NhdGUgZ3Vlc3QgaW1hZ2UgKi8NCi0JbW11X3N3aXRjaF90dGIoZ3B0
ICYgfigweDQwMDAgLSAxKSk7DQorCXNldF90dGJyKCh1bnNpZ25lZCBsb25nKShncHQpICYgfigw
eDQwMDAgLSAxKSk7DQogDQogCWVsZi5kZXN0ID0gKHZvaWQgKil2ZW50cnk7DQogCWVsZl9sb2Fk
X2JpbmFyeSgmZWxmKTsNCkBAIC0xOTIsNyArMTkyLDcgQEAgaW50IGRvbWFpbl9jb25zdHJ1Y3Qo
c3RydWN0IGRvbWFpbiAqZCwNCiAJc2ktPm1mbl9saXN0IAkgID0gMDsNCiAJc2ktPmZpcnN0X3Ay
bV9wZm4gPSBwc3RhcnQgPj4gUEFHRV9TSElGVDsNCiAJc2ktPmZsYWdzIAkgID0gMDsNCi0Jc2kt
Pm1pbl9tZm4JICA9IHBzdGFydCA+PiBQQUdFX1NISUZUOw0KKwkvL3NpLT5taW5fbWZuCSAgPSBw
c3RhcnQgPj4gUEFHRV9TSElGVDsNCiANCiAJaWYgKGQtPmRvbWFpbl9pZCA9PSAwKSB7DQogCQlz
aS0+ZmxhZ3MgPSBTSUZfUFJJVklMRUdFRCB8IFNJRl9JTklURE9NQUlOOw0KQEAgLTIwMiw3ICsy
MDIsNyBAQCBpbnQgZG9tYWluX2NvbnN0cnVjdChzdHJ1Y3QgZG9tYWluICpkLA0KIA0KIAlWQ1BV
X1JFRyh2LCB0dGJyMCkgPSAodW5zaWduZWQgbG9uZylncHQ7DQogDQotCW1tdV9zd2l0Y2hfdHRi
KFZDUFVfUkVHKGlkbGVfdmNwdVswXSwgdHRicjApKTsNCisJc2V0X3R0YnIoVkNQVV9SRUcoaWRs
ZV92Y3B1WzBdLCB0dGJyMCkpOw0KIA0KIAl2Y3B1X2NvbnRleHRfaW5pdCh2LCAwLCB2ZW50cnks
IHNpKTsNCiANCmRpZmYgLXIgYzZhNDEyYWRmYWU3IHhlbi9hcmNoL2FybS94ZW4vdGxiLXY3LlMN
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwDQorKysgYi94ZW4v
YXJjaC9hcm0veGVuL3RsYi12Ny5TCVN1biBGZWIgMTIgMTI6MjQ6MDkgMjAxMiArMDkwMA0KQEAg
LTAsMCArMSw1MSBAQA0KKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+DQorI2luY2x1ZGUgPGFzbS9h
c20tbWFjcm9zLmg+DQorI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQorDQorI2RlZmluZSBQQUdFX1Na
IDQwOTYgLyogUEFHRV9TSVpFCUAgKi8NCisNCitFTlRSWShjcHVfZmx1c2hfdGxiX2FsbCkNCisJ
ZHNiDQorCW1vdglpcCwJIzANCisjaWZuZGVmIFNNUA0KKwltY3IJcDE1LCAwLCBpcCwgYzgsIGM2
LCAgMAkJQCBpbnZhbGlkYXRlIEVudGlyZSBJIFRMQg0KKwltY3IJcDE1LCAwLCBpcCwgYzgsIGM1
LCAgMAkJQCBpbnZhbGlkYXRlIEVudGlyZSBEIFRMQg0KKyNlbHNlDQorCW1jcglwMTUsIDAsIGlw
LCBjOCwgYzMsIDANCisjZW5kaWYNCisJbWNyCXAxNSwgMCwgaXAsIGM3LCBjNSwgNgkJQCBmbHVz
aCBCVEFDL0JUQiAoc2hhcmVhYmxlKQ0KKwlkc2INCisJaXNiDQorCW1vdglwYywgbHINCisNCitF
TlRSWShjcHVfZmx1c2hfdGxiX2VudHJ5KQ0KKwlkc2INCisjaWZuZGVmIFNNUA0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGM2LCAxCQlAIFRMQiBpbnZhbGlkYXRlIEQgTVZBDQorCW1jcglwMTUsIDAs
IHIwLCBjOCwgYzUsIDEJCUAgVExCIGludmFsaWRhdGUgSSBNVkENCisjZWxzZQ0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGMzLCAxCQlAIFRMQiBpbnZhbGlkYXRlIFUgTVZBIChzaGFyZWFibGUpIA0K
KyNlbmRpZg0KKwltb3YJaXAsICMwDQorCW1jcglwMTUsIDAsIGlwLCBjNywgYzUsIDYJCUAgZmx1
c2ggQlRBQy9CVEIgKHNoYXJlYWJsZSkNCisJZHNiDQorCW1vdglwYywgbHINCisNCitFTlRSWShj
cHVfZmx1c2hfdGxiX3JhbmdlKQ0KKwlkc2IJDQorMToNCisjaWZuZGVmIFNNUA0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGM2LCAxCQlAIFRMQiBpbnZhbGlkYXRlIEQgTVZBDQorCW1jcglwMTUsIDAs
IHIwLCBjOCwgYzUsIDEJCUAgVExCIGludmFsaWRhdGUgSSBNVkENCisjZWxzZQ0KKwltY3IJcDE1
LCAwLCByMCwgYzgsIGMzLCAxCQlAIFRMQiBpbnZhbGlkYXRlIFUgTVZBIChzaGFyZWFibGUpIA0K
KyNlbmRpZg0KKwlhZGQJcjAsIHIwLCAjUEFHRV9TWg0KKwljbXAJcjAsIHIxDQorCWJsbwkxYg0K
Kwltb3YJaXAsICMwDQorCW1jcglwMTUsIDAsIGlwLCBjNywgYzUsIDYJCUAgZmx1c2ggQlRBQy9C
VEIgKHNoYXJlYWJsZSkNCisJZHNiDQorCWlzYg0KKwltb3YJcGMsIGxyDQorCQ0K


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: application/octet-stream;
 name="patch10.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="patch10.diff"


YXJtOiBpbXBsZW1lbnQgQVJNdjcgdGxiIG9wcy4KCiB4ZW4vYXJjaC9hcm0veGVuL01ha2Vm
aWxlICAgICAgIHwgICAxICsKIHhlbi9hcmNoL2FybS94ZW4vY2FjaGUtdjcuUyAgICAgfCAg
MTcgKysrKystLS0tLS0tLS0tLS0KIHhlbi9hcmNoL2FybS94ZW4vZG9tYWluX2J1aWxkLmMg
fCAgIDYgKysrLS0tCiB4ZW4vYXJjaC9hcm0veGVuL3RsYi12Ny5TICAgICAgIHwgIDUxICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogNCBm
aWxlcyBjaGFuZ2VkLCA2MCBpbnNlcnRpb25zKCspLCAxNSBkZWxldGlvbnMoLSkKClNpZ25l
ZC1vZmYtYnk6IEphZW1pbiBSeXUgPGptNzcucnl1QHNhbXN1bmcuY29tPgoKZGlmZiAtciBj
NmE0MTJhZGZhZTcgeGVuL2FyY2gvYXJtL3hlbi9NYWtlZmlsZQotLS0gYS94ZW4vYXJjaC9h
cm0veGVuL01ha2VmaWxlCVN1biBGZWIgMTIgMTI6MDU6MzYgMjAxMiArMDkwMAorKysgYi94
ZW4vYXJjaC9hcm0veGVuL01ha2VmaWxlCVN1biBGZWIgMTIgMTI6MjQ6MDkgMjAxMiArMDkw
MApAQCAtMjMsMyArMjMsNCBAQCBvYmoteSArPSBwZXJmbW9uLm8KIG9iai15ICs9IHBjaS5v
CiBvYmoteSArPSBhcm12Ny5vCiBvYmoteSArPSBjYWNoZS12Ny5vCitvYmoteSArPSB0bGIt
djcubwpkaWZmIC1yIGM2YTQxMmFkZmFlNyB4ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMK
LS0tIGEveGVuL2FyY2gvYXJtL3hlbi9jYWNoZS12Ny5TCVN1biBGZWIgMTIgMTI6MDU6MzYg
MjAxMiArMDkwMAorKysgYi94ZW4vYXJjaC9hcm0veGVuL2NhY2hlLXY3LlMJU3VuIEZlYiAx
MiAxMjoyNDowOSAyMDEyICswOTAwCkBAIC0xLDcgKzEsNiBAQAotI2luY2x1ZGUgPHhlbi9s
aW5rYWdlLmg+CisjaW5jbHVkZSA8eGVuL2NvbmZpZy5oPgorI2luY2x1ZGUgPGFzbS9hc20t
bWFjcm9zLmg+CiAjaW5jbHVkZSA8YXNtL3BhZ2UuaD4KLSNpbmNsdWRlIDxhc20vY3B1LW9w
cy5oPgotI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4KICNpbmNsdWRlIDxhc20vYXNtLW9mZnNl
dHMuaD4KIAogCS5tYWNybyB2N193YXlfb3AsIG9wCkBAIC00OSw3ICs0OCw3IEBAIDUwOgog
CS5lbmRtCiAJLnRleHQKIAotUFJJVkFURSh2N19mbHVzaF9jYWNoZV9hbGwpCitFTlRSWShj
cHVfZmx1c2hfY2FjaGVfYWxsKQogCXN0bWZkCXNwISwge3I0LXI1LCByNywgcjktcjExLCBs
cn0KIAogCXY3X3dheV9vcCBjMTQKQEAgLTU5LDkgKzU4LDcgQEAgUFJJVkFURSh2N19mbHVz
aF9jYWNoZV9hbGwpCiAJbGRtZmQJc3AhLCB7cjQtcjUsIHI3LCByOS1yMTEsIGxyfQogCW1v
dglwYywgbHIKIAotREVDTEFSRV9DUFVfT1AoY3B1X2ZsdXNoX2NhY2hlX2FsbCwgdjdfZmx1
c2hfY2FjaGVfYWxsKQotCi1QUklWQVRFKHY3X2ZsdXNoX2NhY2hlX3JhbmdlKQorRU5UUlko
Y3B1X2ZsdXNoX2NhY2hlX3JhbmdlKQogCW1yYyAgICAgcDE1LCAxLCByMywgYzAsIGMwLCAw
CUAgcmVhZCBDU0lEUgogCWFuZCAgICAgcjMsIHIzLCAjNwkJQCBjYWNoZSBsaW5lIHNpemUg
ZW5jb2RpbmcKIAltb3YgICAgIHIzLCAjMTYJCQlAIHNpemUgb2Zmc2V0CkBAIC03NCw5ICs3
MSw3IEBAIDE6CiAJZHNiCiAJbW92CXBjLCBscgogCi1ERUNMQVJFX0NQVV9PUChjcHVfZmx1
c2hfY2FjaGVfcmFuZ2UsIHY3X2ZsdXNoX2NhY2hlX3JhbmdlKQotCi1QUklWQVRFKHY3X2Ns
ZWFuX2NhY2hlX3JhbmdlKQorRU5UUlkoY3B1X2NsZWFuX2NhY2hlX3JhbmdlKQogCW1yYyAg
ICAgcDE1LCAxLCByMywgYzAsIGMwLCAwCUAgcmVhZCBDU0lEUgogCWFuZCAgICAgcjMsIHIz
LCAjNwkJQCBjYWNoZSBsaW5lIHNpemUgZW5jb2RpbmcKIAltb3YgICAgIHIzLCAjMTYJCQlA
IHNpemUgb2Zmc2V0CkBAIC05MCw1ICs4NSwzIEBAIDE6CiAJZHNiCiAJbW92CXBjLCBscgog
Ci1ERUNMQVJFX0NQVV9PUChjcHVfY2xlYW5fY2FjaGVfcmFuZ2UsIHY3X2NsZWFuX2NhY2hl
X3JhbmdlKQotCmRpZmYgLXIgYzZhNDEyYWRmYWU3IHhlbi9hcmNoL2FybS94ZW4vZG9tYWlu
X2J1aWxkLmMKLS0tIGEveGVuL2FyY2gvYXJtL3hlbi9kb21haW5fYnVpbGQuYwlTdW4gRmVi
IDEyIDEyOjA1OjM2IDIwMTIgKzA5MDAKKysrIGIveGVuL2FyY2gvYXJtL3hlbi9kb21haW5f
YnVpbGQuYwlTdW4gRmViIDEyIDEyOjI0OjA5IDIwMTIgKzA5MDAKQEAgLTE3Niw3ICsxNzYs
NyBAQCBpbnQgZG9tYWluX2NvbnN0cnVjdChzdHJ1Y3QgZG9tYWluICpkLAogCX0gd2hpbGUo
Z3B0KyssIHBtYXAgPCBwZW5kKTsKICAKIAkvKiBBY3RpdmF0ZSBndWVzdCBhZGRyZXNzIHNw
YWNlIHRvIHJlbG9jYXRlIGd1ZXN0IGltYWdlICovCi0JbW11X3N3aXRjaF90dGIoZ3B0ICYg
figweDQwMDAgLSAxKSk7CisJc2V0X3R0YnIoKHVuc2lnbmVkIGxvbmcpKGdwdCkgJiB+KDB4
NDAwMCAtIDEpKTsKIAogCWVsZi5kZXN0ID0gKHZvaWQgKil2ZW50cnk7CiAJZWxmX2xvYWRf
YmluYXJ5KCZlbGYpOwpAQCAtMTkyLDcgKzE5Miw3IEBAIGludCBkb21haW5fY29uc3RydWN0
KHN0cnVjdCBkb21haW4gKmQsCiAJc2ktPm1mbl9saXN0IAkgID0gMDsKIAlzaS0+Zmlyc3Rf
cDJtX3BmbiA9IHBzdGFydCA+PiBQQUdFX1NISUZUOwogCXNpLT5mbGFncyAJICA9IDA7Ci0J
c2ktPm1pbl9tZm4JICA9IHBzdGFydCA+PiBQQUdFX1NISUZUOworCS8vc2ktPm1pbl9tZm4J
ICA9IHBzdGFydCA+PiBQQUdFX1NISUZUOwogCiAJaWYgKGQtPmRvbWFpbl9pZCA9PSAwKSB7
CiAJCXNpLT5mbGFncyA9IFNJRl9QUklWSUxFR0VEIHwgU0lGX0lOSVRET01BSU47CkBAIC0y
MDIsNyArMjAyLDcgQEAgaW50IGRvbWFpbl9jb25zdHJ1Y3Qoc3RydWN0IGRvbWFpbiAqZCwK
IAogCVZDUFVfUkVHKHYsIHR0YnIwKSA9ICh1bnNpZ25lZCBsb25nKWdwdDsKIAotCW1tdV9z
d2l0Y2hfdHRiKFZDUFVfUkVHKGlkbGVfdmNwdVswXSwgdHRicjApKTsKKwlzZXRfdHRicihW
Q1BVX1JFRyhpZGxlX3ZjcHVbMF0sIHR0YnIwKSk7CiAKIAl2Y3B1X2NvbnRleHRfaW5pdCh2
LCAwLCB2ZW50cnksIHNpKTsKIApkaWZmIC1yIGM2YTQxMmFkZmFlNyB4ZW4vYXJjaC9hcm0v
eGVuL3RsYi12Ny5TCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3hlbi9hcmNoL2FybS94ZW4vdGxiLXY3LlMJU3VuIEZlYiAxMiAxMjoyNDow
OSAyMDEyICswOTAwCkBAIC0wLDAgKzEsNTEgQEAKKyNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+
CisjaW5jbHVkZSA8YXNtL2FzbS1tYWNyb3MuaD4KKyNpbmNsdWRlIDxhc20vcGFnZS5oPgor
CisjZGVmaW5lIFBBR0VfU1ogNDA5NiAvKiBQQUdFX1NJWkUJQCAqLworCitFTlRSWShjcHVf
Zmx1c2hfdGxiX2FsbCkKKwlkc2IKKwltb3YJaXAsCSMwCisjaWZuZGVmIFNNUAorCW1jcglw
MTUsIDAsIGlwLCBjOCwgYzYsICAwCQlAIGludmFsaWRhdGUgRW50aXJlIEkgVExCCisJbWNy
CXAxNSwgMCwgaXAsIGM4LCBjNSwgIDAJCUAgaW52YWxpZGF0ZSBFbnRpcmUgRCBUTEIKKyNl
bHNlCisJbWNyCXAxNSwgMCwgaXAsIGM4LCBjMywgMAorI2VuZGlmCisJbWNyCXAxNSwgMCwg
aXAsIGM3LCBjNSwgNgkJQCBmbHVzaCBCVEFDL0JUQiAoc2hhcmVhYmxlKQorCWRzYgorCWlz
YgorCW1vdglwYywgbHIKKworRU5UUlkoY3B1X2ZsdXNoX3RsYl9lbnRyeSkKKwlkc2IKKyNp
Zm5kZWYgU01QCisJbWNyCXAxNSwgMCwgcjAsIGM4LCBjNiwgMQkJQCBUTEIgaW52YWxpZGF0
ZSBEIE1WQQorCW1jcglwMTUsIDAsIHIwLCBjOCwgYzUsIDEJCUAgVExCIGludmFsaWRhdGUg
SSBNVkEKKyNlbHNlCisJbWNyCXAxNSwgMCwgcjAsIGM4LCBjMywgMQkJQCBUTEIgaW52YWxp
ZGF0ZSBVIE1WQSAoc2hhcmVhYmxlKSAKKyNlbmRpZgorCW1vdglpcCwgIzAKKwltY3IJcDE1
LCAwLCBpcCwgYzcsIGM1LCA2CQlAIGZsdXNoIEJUQUMvQlRCIChzaGFyZWFibGUpCisJZHNi
CisJbW92CXBjLCBscgorCitFTlRSWShjcHVfZmx1c2hfdGxiX3JhbmdlKQorCWRzYgkKKzE6
CisjaWZuZGVmIFNNUAorCW1jcglwMTUsIDAsIHIwLCBjOCwgYzYsIDEJCUAgVExCIGludmFs
aWRhdGUgRCBNVkEKKwltY3IJcDE1LCAwLCByMCwgYzgsIGM1LCAxCQlAIFRMQiBpbnZhbGlk
YXRlIEkgTVZBCisjZWxzZQorCW1jcglwMTUsIDAsIHIwLCBjOCwgYzMsIDEJCUAgVExCIGlu
dmFsaWRhdGUgVSBNVkEgKHNoYXJlYWJsZSkgCisjZW5kaWYKKwlhZGQJcjAsIHIwLCAjUEFH
RV9TWgorCWNtcAlyMCwgcjEKKwlibG8JMWIKKwltb3YJaXAsICMwCisJbWNyCXAxNSwgMCwg
aXAsIGM3LCBjNSwgNgkJQCBmbHVzaCBCVEFDL0JUQiAoc2hhcmVhYmxlKQorCWRzYgorCWlz
YgorCW1vdglwYywgbHIKKwkK


------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------=SAMSUNG_mySingle_MIME_MULTIPART_BOUNDARY--



From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:24:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt5H-0001GX-4a; Mon, 13 Feb 2012 10:24:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rwt5D-0001FE-7b
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:24:31 +0000
Received: from [85.158.139.83:29864] by server-11.bemta-5.messagelabs.com id
	51/25-13907-ED4E83F4; Mon, 13 Feb 2012 10:24:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329128669!14814199!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 988 invoked from network); 13 Feb 2012 10:24:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:24:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rwt5B-000NGY-7x; Mon, 13 Feb 2012 10:24:29 +0000
Date: Mon, 13 Feb 2012 10:24:29 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120213102429.GA88765@ocelot.phlegethon.org>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:17 +0000 on 13 Feb (1329128265), Ian Campbell wrote:
> This weeks update. I was away last Monday so this covers two weeks worth
> of updates. I have dropped things which were marked as DONE in the last
> update and added a bunch more DONE (so the list is shrinking!). Please
> send me corrections (especially "done").
> 
> hypervisor, blockers:
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich -- more fixes
>         required than first thought, patches posted)
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)
>       * get the interface changes for sharing/paging/mem-events done and
>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>         Andres Lagar-Cavilla et al)
>               * sharing patches posted

The hypervisor interface changes for sharing and events have gone in;
there's a libxc-level change (to do with mlock()ing buffers) that ought
to go in before 4.2, if at all. 

There's a paging+waitqueues patch that's been posted but needs a bit more
work still; I'll try and look at it on Thursday.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:24:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwt5H-0001GX-4a; Mon, 13 Feb 2012 10:24:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rwt5D-0001FE-7b
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:24:31 +0000
Received: from [85.158.139.83:29864] by server-11.bemta-5.messagelabs.com id
	51/25-13907-ED4E83F4; Mon, 13 Feb 2012 10:24:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329128669!14814199!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 988 invoked from network); 13 Feb 2012 10:24:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:24:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rwt5B-000NGY-7x; Mon, 13 Feb 2012 10:24:29 +0000
Date: Mon, 13 Feb 2012 10:24:29 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120213102429.GA88765@ocelot.phlegethon.org>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:17 +0000 on 13 Feb (1329128265), Ian Campbell wrote:
> This weeks update. I was away last Monday so this covers two weeks worth
> of updates. I have dropped things which were marked as DONE in the last
> update and added a bunch more DONE (so the list is shrinking!). Please
> send me corrections (especially "done").
> 
> hypervisor, blockers:
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich -- more fixes
>         required than first thought, patches posted)
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)
>       * get the interface changes for sharing/paging/mem-events done and
>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>         Andres Lagar-Cavilla et al)
>               * sharing patches posted

The hypervisor interface changes for sharing and events have gone in;
there's a libxc-level change (to do with mlock()ing buffers) that ought
to go in before 4.2, if at all. 

There's a paging+waitqueues patch that's been posted but needs a bit more
work still; I'll try and look at it on Thursday.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:35:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10: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.xensource.com>)
	id 1RwtFQ-0002LU-3M; Mon, 13 Feb 2012 10:35:04 +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 1RwtFN-0002L5-QW
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:35:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329129239!56449681!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24996 invoked from network); 13 Feb 2012 10:33:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:33:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwtFH-000NI5-19; Mon, 13 Feb 2012 10:34:55 +0000
Date: Mon, 13 Feb 2012 10:34:54 +0000
From: Tim Deegan <tim@xen.org>
To: X <studyxen@gmail.com>
Message-ID: <20120213103454.GB88765@ocelot.phlegethon.org>
References: <CAJEOSFtfnH+6wq519pZ4+9MyzR_jm73z9yp73=zYPU3p0o9WAg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJEOSFtfnH+6wq519pZ4+9MyzR_jm73z9yp73=zYPU3p0o9WAg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] exception interception
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:45 -0500 on 12 Feb (1329061516), X wrote:
> Hello,
> 
> Could someone kindly point me to the code in Xen for handling the
> exceptions intercepted from PV guest kernels?

Have a look at xen/arch/x86/traps.c

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:35:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10: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.xensource.com>)
	id 1RwtFQ-0002LU-3M; Mon, 13 Feb 2012 10:35:04 +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 1RwtFN-0002L5-QW
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:35:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329129239!56449681!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24996 invoked from network); 13 Feb 2012 10:33:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:33:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwtFH-000NI5-19; Mon, 13 Feb 2012 10:34:55 +0000
Date: Mon, 13 Feb 2012 10:34:54 +0000
From: Tim Deegan <tim@xen.org>
To: X <studyxen@gmail.com>
Message-ID: <20120213103454.GB88765@ocelot.phlegethon.org>
References: <CAJEOSFtfnH+6wq519pZ4+9MyzR_jm73z9yp73=zYPU3p0o9WAg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJEOSFtfnH+6wq519pZ4+9MyzR_jm73z9yp73=zYPU3p0o9WAg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] exception interception
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:45 -0500 on 12 Feb (1329061516), X wrote:
> Hello,
> 
> Could someone kindly point me to the code in Xen for handling the
> exceptions intercepted from PV guest kernels?

Have a look at xen/arch/x86/traps.c

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:36:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtGq-0002TI-Ji; Mon, 13 Feb 2012 10:36:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RwtGp-0002Sk-5h
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:36:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329129384!5709067!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14760 invoked from network); 13 Feb 2012 10:36:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:36:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwtGe-000NIb-Lm; Mon, 13 Feb 2012 10:36:20 +0000
Date: Mon, 13 Feb 2012 10:36:20 +0000
From: Tim Deegan <tim@xen.org>
To: yunjiedu <350608693@qq.com>
Message-ID: <20120213103620.GC88765@ocelot.phlegethon.org>
References: <1328880882031-5472445.post@n5.nabble.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328880882031-5472445.post@n5.nabble.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 05:34 -0800 on 10 Feb (1328852082), yunjiedu wrote:
> Hi,all,
> 
> today,i use function printk() in file xen/arch/x86/mm/paging.c,but Where the
> output of printk() is stored (which log files)?I try to find,but without
> results. Also is this output enabled by default ? If no, how to enable them?
> thanks

printk() prints to the console.  You can also read the buffer of recent
printk output from inside dom0 with 'xl dmesg'.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:36:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtGq-0002TI-Ji; Mon, 13 Feb 2012 10:36:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RwtGp-0002Sk-5h
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:36:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329129384!5709067!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14760 invoked from network); 13 Feb 2012 10:36:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:36:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwtGe-000NIb-Lm; Mon, 13 Feb 2012 10:36:20 +0000
Date: Mon, 13 Feb 2012 10:36:20 +0000
From: Tim Deegan <tim@xen.org>
To: yunjiedu <350608693@qq.com>
Message-ID: <20120213103620.GC88765@ocelot.phlegethon.org>
References: <1328880882031-5472445.post@n5.nabble.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328880882031-5472445.post@n5.nabble.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 05:34 -0800 on 10 Feb (1328852082), yunjiedu wrote:
> Hi,all,
> 
> today,i use function printk() in file xen/arch/x86/mm/paging.c,but Where the
> output of printk() is stored (which log files)?I try to find,but without
> results. Also is this output enabled by default ? If no, how to enable them?
> thanks

printk() prints to the console.  You can also read the buffer of recent
printk output from inside dom0 with 'xl dmesg'.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtHA-0002WR-19; Mon, 13 Feb 2012 10:36:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RwtH7-0002Uv-Qs
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:36:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329129339!60831304!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 962 invoked from network); 13 Feb 2012 10:35:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:35:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 10:36:42 +0000
Message-Id: <4F38F5C802000078000727AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 10:36:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
In-Reply-To: <20120210212846.GA31185@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part507E2AA8.3__="
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part507E2AA8.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
> These functions are called for dom0, but not for domU. And as a result
> arch.nr_vmce_banks remains zero. I assume the guest needs to be
> initialized in some way as well, and that does not happen?

Below/attached a fixed version of the patch.

Jan

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); =
break;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)
            sizeof(dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;
     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;
     dom_vmce(d)->nr_injection =3D 0;
=20
@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.mcg_cap =3D g_mcg_cap;
+}
+
+int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+{
+    if ( caps & ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    {
+        dprintk(XENLOG_G_ERR, "%s restore: unsupported MCA capabilities"
+                " %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",
+                is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=

+                v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);
+        return -EPERM;
+    }
+
+    v->arch.mcg_cap =3D caps;
+    return 0;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*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
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +146,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -162,39 +182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D vmce->mcg_cap;
+        *val =3D cur->arch.mcg_cap;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Always 0 if no CTL support */
-        *val =3D vmce->mcg_ctl & h_mcg_ctl;
+        if ( cur->arch.mcg_cap & MCG_CTL_P )
+            *val =3D vmce->mcg_ctl & h_mcg_ctl;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +221,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +247,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +285,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);
         /* For HVM guest, this is the point for deleting vMCE injection =
node */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +312,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : =
0;
         break;
     }
=20
@@ -301,6 +320,46 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .caps =3D v->arch.mcg_cap
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
+    {
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
+        err =3D -EINVAL;
+    }
+    else
+        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+
+    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
+    vmce_init_vcpu(v);
+
     if ( is_hvm_domain(d) )
     {
         rc =3D hvm_vcpu_initialise(v);
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->mcg_cap =3D v->arch.mcg_cap;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,10 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
+                              sizeof(evc->mcg_cap) )
+                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been =
used,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint64_t mcg_cap;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -16,7 +16,6 @@ struct bank_entry {
 struct domain_mca_msrs
 {
     /* Guest should not change below values after DOM boot up */
-    uint64_t mcg_cap;
     uint64_t mcg_ctl;
     uint64_t mcg_status;
     uint64_t *mci_ctl;
@@ -28,6 +27,8 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
+extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -575,9 +575,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint64_t caps;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint64_aligned_t mcg_cap;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;


--=__Part507E2AA8.3__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

--- a/tools/libxc/xc_domain_save.c=0A+++ b/tools/libxc/xc_domain_save.c=0A@=
@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in=0A =0A       =
  domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =
=3D dom;=0A+        memset(&domctl.u, 0, sizeof(domctl.u));=0A         =
domctl.u.ext_vcpucontext.vcpu =3D i;=0A         if ( xc_domctl(xch, =
&domctl) < 0 )=0A         {=0A--- a/tools/misc/xen-hvmctx.c=0A+++ =
b/tools/misc/xen-hvmctx.c=0A@@ -383,6 +383,13 @@ static void dump_viridian_=
vcpu(void)=0A            (unsigned long long) p.apic_assist);           =
=0A }=0A =0A+static void dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMC=
E_VCPU) p;=0A+    READ(p);=0A+    printf("    VMCE_VCPU: caps %" PRIx64 =
"\n", p.caps);=0A+}=0A+=0A int main(int argc, char **argv)=0A {=0A     int =
entry, domid;=0A@@ -449,6 +456,7 @@ int main(int argc, char **argv)=0A     =
    case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;=0A         case =
HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break;=0A         =
case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;=0A+        =
case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;=0A         case =
HVM_SAVE_CODE(END): break;=0A         default:=0A             printf(" ** =
Don't understand type %u: skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.=
h=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define =
_MCE_H=0A =0A #include <xen/init.h>=0A+#include <xen/sched.h>=0A #include =
<xen/smp.h>=0A #include <asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 =
+55,8 @@ int unmmap_broken_page(struct domain *d,=0A u64 mce_cap_init(void)=
;=0A extern int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, =
uint64_t *val);=0A-int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int =
intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);=0A+int =
intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct =
mcinfo_extended *intel_get_extended_msrs(=0A     struct mcinfo_global =
*mig, struct mc_info *mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(s=
truct mcinfo_ban=0A =0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =
=0A-static inline int mce_vendor_bank_msr(uint32_t msr)=0A+static inline =
int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)=0A {=0A     if =
( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+        =
 msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.=
mcg_cap & MCG_CAP_COUNT) )=0A           return 1;=0A     return 0;=0A }=0A =
=0A-static inline int mce_bank_msr(uint32_t msr)=0A+static inline int =
mce_bank_msr(const struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr =
>=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-      =
  mce_vendor_bank_msr(msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+ =
         msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||=0A+   =
      mce_vendor_bank_msr(v, msr) )=0A         return 1;=0A     return =
0;=0A }=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cp=
u/mcheck/mce_intel.c=0A@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mchec=
k_init(struc=0A }=0A =0A /* intel specific MCA MSR */=0A-int intel_mce_wrms=
r(uint32_t msr, uint64_t val)=0A+int intel_mce_wrmsr(struct vcpu *v, =
uint32_t msr, uint64_t val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr =
>=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    =
if ( msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->a=
rch.mcg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, =
"We have disabled CMCI capability, "=0A                  "Guest should not =
write this MSR!\n");=0A@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t=
 msr, uint64=0A     return ret;=0A }=0A =0A-int intel_mce_rdmsr(uint32_t =
msr, uint64_t *val)=0A+int intel_mce_rdmsr(const struct vcpu *v, uint32_t =
msr, uint64_t *val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch=
/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A #include <xen/delay.h>=0A =
#include <xen/smp.h>=0A #include <xen/mm.h>=0A+#include <xen/hvm/save.h>=0A=
 #include <asm/processor.h>=0A #include <public/sysctl.h>=0A #include =
<asm/system.h>=0A@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)=0A  =
          sizeof(dom_vmce(d)->mci_ctl));=0A =0A     dom_vmce(d)->mcg_status=
 =3D 0x0;=0A-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;=0A     dom_vmce(d)->mc=
g_ctl =3D ~(uint64_t)0x0;=0A     dom_vmce(d)->nr_injection =3D 0;=0A =0A@@ =
-61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)=0A     dom_vmce(d)=
 =3D NULL;=0A }=0A =0A-static int bank_mce_rdmsr(struct domain *d, =
uint32_t msr, uint64_t *val)=0A+void vmce_init_vcpu(struct vcpu *v)=0A =
{=0A-    int bank, ret =3D 1;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    v->arch.mcg_cap =3D g_mcg_cap;=0A+}=0A+=0A+int =
vmce_restore_vcpu(struct vcpu *v, uint64_t caps)=0A+{=0A+    if ( caps & =
~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )=0A+    {=0A+        dprintk(XENL=
OG_G_ERR, "%s restore: unsupported MCA capabilities"=0A+                " =
%#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",=0A+                =
is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=0A+             =
   v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);=0A+        return -EPERM;=0A+  =
  }=0A+=0A+    v->arch.mcg_cap =3D caps;=0A+    return 0;=0A+}=0A+=0A+stati=
c int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)=0A+{=0A+    int ret =3D 1;=0A+    unsigned int bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->=
domain);=0A     struct bank_entry *entry;=0A =0A-    bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        =
return -1;=0A+    *val =3D 0;=0A =0A     switch ( msr & (MSR_IA32_MC0_CTL =
| 3) )=0A     {=0A     case MSR_IA32_MC0_CTL:=0A-        *val =3D =
vmce->mci_ctl[bank] &=0A-            (h_mci_ctrl ? h_mci_ctrl[bank] : =
~0UL);=0A+        if ( bank < nr_mce_banks )=0A+            *val =3D =
vmce->mci_ctl[bank] &=0A+                   (h_mci_ctrl ? h_mci_ctrl[bank] =
: ~0UL);=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64=
"\n",=0A                    bank, *val);=0A         break;=0A@@ -126,7 =
+146,7 @@ static int bank_mce_rdmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_rdmsr(msr, val);=0A+            ret =3D =
intel_mce_rdmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(st=
ruct domain =0A  */=0A int vmce_rdmsr(uint32_t msr, uint64_t *val)=0A =
{=0A-    struct domain *d =3D current->domain;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    const struct vcpu *cur =3D current;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=0A     int ret =3D =
1;=0A =0A     *val =3D 0;=0A =0A-    spin_lock(&dom_vmce(d)->lock);=0A+    =
spin_lock(&vmce->lock);=0A =0A     switch ( msr )=0A     {=0A@@ -162,39 =
+182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A                     =
   "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);=0A         break;=0A     =
case MSR_IA32_MCG_CAP:=0A-        *val =3D vmce->mcg_cap;=0A+        *val =
=3D cur->arch.mcg_cap;=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr =
MCG_CAP 0x%"PRIx64"\n",=0A                    *val);=0A         break;=0A  =
   case MSR_IA32_MCG_CTL:=0A         /* Always 0 if no CTL support */=0A-  =
      *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A+        if ( cur->arch.mcg_cap=
 & MCG_CTL_P )=0A+            *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A       =
  mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",=0A           =
         *val);=0A         break;=0A     default:=0A-        ret =3D =
mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;=0A+        ret =3D =
mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;=0A         =
break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(d)->lock);=0A+    =
spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =0A-static int =
bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static int bank_mce_w=
rmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return -EINVAL;=0A-=0A  =
   switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case MSR_IA32_MC=
0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        if ( bank < =
nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A         =
break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the first entry =
of the list, it corresponds to current=0A@@ -202,9 +221,9 @@ static int =
bank_mce_wrmsr(struct domain =0A          * the guest, this node will be =
deleted.=0A          * Only error bank is written. Non-error banks simply =
return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d)->impact_hea=
der) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A         =
{=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.next,=0A+ =
           entry =3D list_entry(vmce->impact_header.next,=0A               =
                 struct bank_entry, list);=0A             if ( entry->bank =
=3D=3D bank )=0A                 entry->mci_status =3D val;=0A@@ -228,7 =
+247,7 @@ static int bank_mce_wrmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+            ret =3D =
intel_mce_wrmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(stru=
ct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 val)=0A {=0A-    struct =
domain *d =3D current->domain;=0A+    struct vcpu *cur =3D current;=0A     =
struct bank_entry *entry =3D NULL;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=
=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap )=0A@@ -266,7 +285,7 @@ =
int vmce_wrmsr(u32 msr, u64 val)=0A         vmce->mcg_status =3D val;=0A   =
      mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);=0A         /* For HVM guest, this is the point for deleting vMCE =
injection node */=0A-        if ( d->is_hvm && (vmce->nr_injection > 0) =
)=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )=0A        =
 {=0A             vmce->nr_injection--; /* Should be 0 */=0A             =
if ( !list_empty(&vmce->impact_header) )=0A@@ -293,7 +312,7 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D -1;=0A         break;=0A   =
  default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A@@ -301,6 +320,46 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A     return ret;=0A }=0A =0A+static int =
vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)=0A+{=0A+    =
struct vcpu *v;=0A+    int err =3D 0;=0A+=0A+    for_each_vcpu( d, v ) =
{=0A+        struct hvm_vmce_vcpu ctxt =3D {=0A+            .caps =3D =
v->arch.mcg_cap=0A+        };=0A+=0A+        err =3D hvm_save_entry(VMCE_VC=
PU, v->vcpu_id, h, &ctxt);=0A+        if ( err )=0A+            break;=0A+ =
   }=0A+=0A+    return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(stru=
ct domain *d, hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D =
hvm_load_instance(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu =
ctxt;=0A+    int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A+    {=0A+        dprintk(XENLOG_G_ERR, =
"HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_id, =
vcpuid);=0A+        err =3D -EINVAL;=0A+    }=0A+    else=0A+        err =
=3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+=0A+    return err ?: =
vmce_restore_vcpu(v, ctxt.caps);=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE=
_VCPU, vmce_save_vcpu_ctxt,=0A+                          vmce_load_vcpu_ctx=
t, 1, HVMSR_PER_VCPU);=0A+=0A int inject_vmce(struct domain *d)=0A {=0A    =
 int cpu =3D smp_processor_id();=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -422,6 +422,8 @@ int vcpu_initialise(struct =
vcpu *v)=0A     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )=0A         return =
rc;=0A =0A+    vmce_init_vcpu(v);=0A+=0A     if ( is_hvm_domain(d) )=0A    =
 {=0A         rc =3D hvm_vcpu_initialise(v);=0A--- a/xen/arch/x86/domctl.c=
=0A+++ b/xen/arch/x86/domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domct=
l(=0A                 evc->syscall32_callback_eip    =3D 0;=0A             =
    evc->syscall32_disables_events =3D 0;=0A             }=0A+            =
evc->mcg_cap =3D v->arch.mcg_cap;=0A         }=0A         else=0A         =
{=0A             ret =3D -EINVAL;=0A-            if ( evc->size !=3D =
sizeof(*evc) )=0A+            if ( evc->size < offsetof(typeof(*evc), =
mcg_cap) )=0A                 goto ext_vcpucontext_out;=0A #ifdef =
__x86_64__=0A             if ( !is_hvm_domain(d) )=0A@@ -1059,6 +1060,10 =
@@ long arch_do_domctl(=0A                  (evc->syscall32_callback_cs & =
~3) ||=0A                  evc->syscall32_callback_eip )=0A                =
 goto ext_vcpucontext_out;=0A+=0A+            if ( evc->size >=3D =
offsetof(typeof(*evc), mcg_cap) +=0A+                              =
sizeof(evc->mcg_cap) )=0A+                ret =3D vmce_restore_vcpu(v, =
evc->mcg_cap);=0A         }=0A =0A         ret =3D 0;=0A--- a/xen/include/a=
sm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ -488,6 +488,8 @@ =
struct arch_vcpu=0A     /* This variable determines whether nonlazy =
extended state has been used,=0A      * and thus should be saved/restored. =
*/=0A     bool_t nonlazy_xstate_used;=0A+=0A+    uint64_t mcg_cap;=0A     =
=0A     struct paging_vcpu paging;=0A =0A--- a/xen/include/asm-x86/mce.h=0A=
+++ b/xen/include/asm-x86/mce.h=0A@@ -16,7 +16,6 @@ struct bank_entry {=0A =
struct domain_mca_msrs=0A {=0A     /* Guest should not change below values =
after DOM boot up */=0A-    uint64_t mcg_cap;=0A     uint64_t mcg_ctl;=0A  =
   uint64_t mcg_status;=0A     uint64_t *mci_ctl;=0A@@ -28,6 +27,8 @@ =
struct domain_mca_msrs=0A /* Guest vMCE MSRs virtualization */=0A extern =
int vmce_init_msr(struct domain *d);=0A extern void vmce_destroy_msr(struct=
 domain *d);=0A+extern void vmce_init_vcpu(struct vcpu *);=0A+extern int =
vmce_restore_vcpu(struct vcpu *, uint64_t caps);=0A extern int vmce_wrmsr(u=
int32_t msr, uint64_t val);=0A extern int vmce_rdmsr(uint32_t msr, =
uint64_t *val);=0A =0A--- a/xen/include/public/arch-x86/hvm/save.h=0A+++ =
b/xen/include/public/arch-x86/hvm/save.h=0A@@ -575,9 +575,15 @@ struct =
hvm_viridian_vcpu_context {=0A =0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, =
17, struct hvm_viridian_vcpu_context);=0A =0A+struct hvm_vmce_vcpu {=0A+   =
 uint64_t caps;=0A+};=0A+=0A+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct =
hvm_vmce_vcpu);=0A+=0A /* =0A  * Largest type-code in use=0A  */=0A-#define=
 HVM_SAVE_CODE_MAX 17=0A+#define HVM_SAVE_CODE_MAX 18=0A =0A #endif /* =
__XEN_PUBLIC_HVM_SAVE_X86_H__ */=0A--- a/xen/include/public/domctl.h=0A+++ =
b/xen/include/public/domctl.h=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_v=
cpucontext {=0A     uint32_t         vcpu;=0A     /*=0A      * SET: Size =
of struct (IN)=0A-     * GET: Size of struct (OUT)=0A+     * GET: Size of =
struct (OUT, up to 128 bytes)=0A      */=0A     uint32_t         size;=0A =
#if defined(__i386__) || defined(__x86_64__)=0A@@ -571,6 +571,7 @@ struct =
xen_domctl_ext_vcpucontext {=0A     uint16_t         sysenter_callback_cs;=
=0A     uint8_t          syscall32_disables_events;=0A     uint8_t         =
 sysenter_disables_events;=0A+    uint64_aligned_t mcg_cap;=0A #endif=0A =
};=0A typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_=
t;=0A
--=__Part507E2AA8.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part507E2AA8.3__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtHA-0002WR-19; Mon, 13 Feb 2012 10:36:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RwtH7-0002Uv-Qs
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:36:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329129339!60831304!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 962 invoked from network); 13 Feb 2012 10:35:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:35:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 10:36:42 +0000
Message-Id: <4F38F5C802000078000727AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 10:36:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
In-Reply-To: <20120210212846.GA31185@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part507E2AA8.3__="
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part507E2AA8.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
> These functions are called for dom0, but not for domU. And as a result
> arch.nr_vmce_banks remains zero. I assume the guest needs to be
> initialized in some way as well, and that does not happen?

Below/attached a fixed version of the patch.

Jan

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); =
break;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)
            sizeof(dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;
     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;
     dom_vmce(d)->nr_injection =3D 0;
=20
@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.mcg_cap =3D g_mcg_cap;
+}
+
+int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+{
+    if ( caps & ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    {
+        dprintk(XENLOG_G_ERR, "%s restore: unsupported MCA capabilities"
+                " %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",
+                is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=

+                v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);
+        return -EPERM;
+    }
+
+    v->arch.mcg_cap =3D caps;
+    return 0;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*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
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +146,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -162,39 +182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D vmce->mcg_cap;
+        *val =3D cur->arch.mcg_cap;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Always 0 if no CTL support */
-        *val =3D vmce->mcg_ctl & h_mcg_ctl;
+        if ( cur->arch.mcg_cap & MCG_CTL_P )
+            *val =3D vmce->mcg_ctl & h_mcg_ctl;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +221,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +247,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +285,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);
         /* For HVM guest, this is the point for deleting vMCE injection =
node */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +312,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : =
0;
         break;
     }
=20
@@ -301,6 +320,46 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .caps =3D v->arch.mcg_cap
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
+    {
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
+        err =3D -EINVAL;
+    }
+    else
+        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+
+    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
+    vmce_init_vcpu(v);
+
     if ( is_hvm_domain(d) )
     {
         rc =3D hvm_vcpu_initialise(v);
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->mcg_cap =3D v->arch.mcg_cap;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,10 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
+                              sizeof(evc->mcg_cap) )
+                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been =
used,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint64_t mcg_cap;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -16,7 +16,6 @@ struct bank_entry {
 struct domain_mca_msrs
 {
     /* Guest should not change below values after DOM boot up */
-    uint64_t mcg_cap;
     uint64_t mcg_ctl;
     uint64_t mcg_status;
     uint64_t *mci_ctl;
@@ -28,6 +27,8 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
+extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -575,9 +575,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint64_t caps;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint64_aligned_t mcg_cap;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;


--=__Part507E2AA8.3__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

--- a/tools/libxc/xc_domain_save.c=0A+++ b/tools/libxc/xc_domain_save.c=0A@=
@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in=0A =0A       =
  domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =
=3D dom;=0A+        memset(&domctl.u, 0, sizeof(domctl.u));=0A         =
domctl.u.ext_vcpucontext.vcpu =3D i;=0A         if ( xc_domctl(xch, =
&domctl) < 0 )=0A         {=0A--- a/tools/misc/xen-hvmctx.c=0A+++ =
b/tools/misc/xen-hvmctx.c=0A@@ -383,6 +383,13 @@ static void dump_viridian_=
vcpu(void)=0A            (unsigned long long) p.apic_assist);           =
=0A }=0A =0A+static void dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMC=
E_VCPU) p;=0A+    READ(p);=0A+    printf("    VMCE_VCPU: caps %" PRIx64 =
"\n", p.caps);=0A+}=0A+=0A int main(int argc, char **argv)=0A {=0A     int =
entry, domid;=0A@@ -449,6 +456,7 @@ int main(int argc, char **argv)=0A     =
    case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;=0A         case =
HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break;=0A         =
case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;=0A+        =
case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;=0A         case =
HVM_SAVE_CODE(END): break;=0A         default:=0A             printf(" ** =
Don't understand type %u: skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.=
h=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define =
_MCE_H=0A =0A #include <xen/init.h>=0A+#include <xen/sched.h>=0A #include =
<xen/smp.h>=0A #include <asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 =
+55,8 @@ int unmmap_broken_page(struct domain *d,=0A u64 mce_cap_init(void)=
;=0A extern int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, =
uint64_t *val);=0A-int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int =
intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);=0A+int =
intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct =
mcinfo_extended *intel_get_extended_msrs(=0A     struct mcinfo_global =
*mig, struct mc_info *mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(s=
truct mcinfo_ban=0A =0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =
=0A-static inline int mce_vendor_bank_msr(uint32_t msr)=0A+static inline =
int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)=0A {=0A     if =
( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+        =
 msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.=
mcg_cap & MCG_CAP_COUNT) )=0A           return 1;=0A     return 0;=0A }=0A =
=0A-static inline int mce_bank_msr(uint32_t msr)=0A+static inline int =
mce_bank_msr(const struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr =
>=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-      =
  mce_vendor_bank_msr(msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+ =
         msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||=0A+   =
      mce_vendor_bank_msr(v, msr) )=0A         return 1;=0A     return =
0;=0A }=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cp=
u/mcheck/mce_intel.c=0A@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mchec=
k_init(struc=0A }=0A =0A /* intel specific MCA MSR */=0A-int intel_mce_wrms=
r(uint32_t msr, uint64_t val)=0A+int intel_mce_wrmsr(struct vcpu *v, =
uint32_t msr, uint64_t val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr =
>=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    =
if ( msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->a=
rch.mcg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, =
"We have disabled CMCI capability, "=0A                  "Guest should not =
write this MSR!\n");=0A@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t=
 msr, uint64=0A     return ret;=0A }=0A =0A-int intel_mce_rdmsr(uint32_t =
msr, uint64_t *val)=0A+int intel_mce_rdmsr(const struct vcpu *v, uint32_t =
msr, uint64_t *val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch=
/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A #include <xen/delay.h>=0A =
#include <xen/smp.h>=0A #include <xen/mm.h>=0A+#include <xen/hvm/save.h>=0A=
 #include <asm/processor.h>=0A #include <public/sysctl.h>=0A #include =
<asm/system.h>=0A@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)=0A  =
          sizeof(dom_vmce(d)->mci_ctl));=0A =0A     dom_vmce(d)->mcg_status=
 =3D 0x0;=0A-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;=0A     dom_vmce(d)->mc=
g_ctl =3D ~(uint64_t)0x0;=0A     dom_vmce(d)->nr_injection =3D 0;=0A =0A@@ =
-61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)=0A     dom_vmce(d)=
 =3D NULL;=0A }=0A =0A-static int bank_mce_rdmsr(struct domain *d, =
uint32_t msr, uint64_t *val)=0A+void vmce_init_vcpu(struct vcpu *v)=0A =
{=0A-    int bank, ret =3D 1;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    v->arch.mcg_cap =3D g_mcg_cap;=0A+}=0A+=0A+int =
vmce_restore_vcpu(struct vcpu *v, uint64_t caps)=0A+{=0A+    if ( caps & =
~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )=0A+    {=0A+        dprintk(XENL=
OG_G_ERR, "%s restore: unsupported MCA capabilities"=0A+                " =
%#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",=0A+                =
is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=0A+             =
   v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);=0A+        return -EPERM;=0A+  =
  }=0A+=0A+    v->arch.mcg_cap =3D caps;=0A+    return 0;=0A+}=0A+=0A+stati=
c int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)=0A+{=0A+    int ret =3D 1;=0A+    unsigned int bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->=
domain);=0A     struct bank_entry *entry;=0A =0A-    bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        =
return -1;=0A+    *val =3D 0;=0A =0A     switch ( msr & (MSR_IA32_MC0_CTL =
| 3) )=0A     {=0A     case MSR_IA32_MC0_CTL:=0A-        *val =3D =
vmce->mci_ctl[bank] &=0A-            (h_mci_ctrl ? h_mci_ctrl[bank] : =
~0UL);=0A+        if ( bank < nr_mce_banks )=0A+            *val =3D =
vmce->mci_ctl[bank] &=0A+                   (h_mci_ctrl ? h_mci_ctrl[bank] =
: ~0UL);=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64=
"\n",=0A                    bank, *val);=0A         break;=0A@@ -126,7 =
+146,7 @@ static int bank_mce_rdmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_rdmsr(msr, val);=0A+            ret =3D =
intel_mce_rdmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(st=
ruct domain =0A  */=0A int vmce_rdmsr(uint32_t msr, uint64_t *val)=0A =
{=0A-    struct domain *d =3D current->domain;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    const struct vcpu *cur =3D current;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=0A     int ret =3D =
1;=0A =0A     *val =3D 0;=0A =0A-    spin_lock(&dom_vmce(d)->lock);=0A+    =
spin_lock(&vmce->lock);=0A =0A     switch ( msr )=0A     {=0A@@ -162,39 =
+182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A                     =
   "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);=0A         break;=0A     =
case MSR_IA32_MCG_CAP:=0A-        *val =3D vmce->mcg_cap;=0A+        *val =
=3D cur->arch.mcg_cap;=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr =
MCG_CAP 0x%"PRIx64"\n",=0A                    *val);=0A         break;=0A  =
   case MSR_IA32_MCG_CTL:=0A         /* Always 0 if no CTL support */=0A-  =
      *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A+        if ( cur->arch.mcg_cap=
 & MCG_CTL_P )=0A+            *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A       =
  mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",=0A           =
         *val);=0A         break;=0A     default:=0A-        ret =3D =
mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;=0A+        ret =3D =
mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;=0A         =
break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(d)->lock);=0A+    =
spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =0A-static int =
bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static int bank_mce_w=
rmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return -EINVAL;=0A-=0A  =
   switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case MSR_IA32_MC=
0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        if ( bank < =
nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A         =
break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the first entry =
of the list, it corresponds to current=0A@@ -202,9 +221,9 @@ static int =
bank_mce_wrmsr(struct domain =0A          * the guest, this node will be =
deleted.=0A          * Only error bank is written. Non-error banks simply =
return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d)->impact_hea=
der) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A         =
{=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.next,=0A+ =
           entry =3D list_entry(vmce->impact_header.next,=0A               =
                 struct bank_entry, list);=0A             if ( entry->bank =
=3D=3D bank )=0A                 entry->mci_status =3D val;=0A@@ -228,7 =
+247,7 @@ static int bank_mce_wrmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+            ret =3D =
intel_mce_wrmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(stru=
ct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 val)=0A {=0A-    struct =
domain *d =3D current->domain;=0A+    struct vcpu *cur =3D current;=0A     =
struct bank_entry *entry =3D NULL;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=
=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap )=0A@@ -266,7 +285,7 @@ =
int vmce_wrmsr(u32 msr, u64 val)=0A         vmce->mcg_status =3D val;=0A   =
      mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);=0A         /* For HVM guest, this is the point for deleting vMCE =
injection node */=0A-        if ( d->is_hvm && (vmce->nr_injection > 0) =
)=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )=0A        =
 {=0A             vmce->nr_injection--; /* Should be 0 */=0A             =
if ( !list_empty(&vmce->impact_header) )=0A@@ -293,7 +312,7 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D -1;=0A         break;=0A   =
  default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A@@ -301,6 +320,46 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A     return ret;=0A }=0A =0A+static int =
vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)=0A+{=0A+    =
struct vcpu *v;=0A+    int err =3D 0;=0A+=0A+    for_each_vcpu( d, v ) =
{=0A+        struct hvm_vmce_vcpu ctxt =3D {=0A+            .caps =3D =
v->arch.mcg_cap=0A+        };=0A+=0A+        err =3D hvm_save_entry(VMCE_VC=
PU, v->vcpu_id, h, &ctxt);=0A+        if ( err )=0A+            break;=0A+ =
   }=0A+=0A+    return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(stru=
ct domain *d, hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D =
hvm_load_instance(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu =
ctxt;=0A+    int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A+    {=0A+        dprintk(XENLOG_G_ERR, =
"HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_id, =
vcpuid);=0A+        err =3D -EINVAL;=0A+    }=0A+    else=0A+        err =
=3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+=0A+    return err ?: =
vmce_restore_vcpu(v, ctxt.caps);=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE=
_VCPU, vmce_save_vcpu_ctxt,=0A+                          vmce_load_vcpu_ctx=
t, 1, HVMSR_PER_VCPU);=0A+=0A int inject_vmce(struct domain *d)=0A {=0A    =
 int cpu =3D smp_processor_id();=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -422,6 +422,8 @@ int vcpu_initialise(struct =
vcpu *v)=0A     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )=0A         return =
rc;=0A =0A+    vmce_init_vcpu(v);=0A+=0A     if ( is_hvm_domain(d) )=0A    =
 {=0A         rc =3D hvm_vcpu_initialise(v);=0A--- a/xen/arch/x86/domctl.c=
=0A+++ b/xen/arch/x86/domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domct=
l(=0A                 evc->syscall32_callback_eip    =3D 0;=0A             =
    evc->syscall32_disables_events =3D 0;=0A             }=0A+            =
evc->mcg_cap =3D v->arch.mcg_cap;=0A         }=0A         else=0A         =
{=0A             ret =3D -EINVAL;=0A-            if ( evc->size !=3D =
sizeof(*evc) )=0A+            if ( evc->size < offsetof(typeof(*evc), =
mcg_cap) )=0A                 goto ext_vcpucontext_out;=0A #ifdef =
__x86_64__=0A             if ( !is_hvm_domain(d) )=0A@@ -1059,6 +1060,10 =
@@ long arch_do_domctl(=0A                  (evc->syscall32_callback_cs & =
~3) ||=0A                  evc->syscall32_callback_eip )=0A                =
 goto ext_vcpucontext_out;=0A+=0A+            if ( evc->size >=3D =
offsetof(typeof(*evc), mcg_cap) +=0A+                              =
sizeof(evc->mcg_cap) )=0A+                ret =3D vmce_restore_vcpu(v, =
evc->mcg_cap);=0A         }=0A =0A         ret =3D 0;=0A--- a/xen/include/a=
sm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ -488,6 +488,8 @@ =
struct arch_vcpu=0A     /* This variable determines whether nonlazy =
extended state has been used,=0A      * and thus should be saved/restored. =
*/=0A     bool_t nonlazy_xstate_used;=0A+=0A+    uint64_t mcg_cap;=0A     =
=0A     struct paging_vcpu paging;=0A =0A--- a/xen/include/asm-x86/mce.h=0A=
+++ b/xen/include/asm-x86/mce.h=0A@@ -16,7 +16,6 @@ struct bank_entry {=0A =
struct domain_mca_msrs=0A {=0A     /* Guest should not change below values =
after DOM boot up */=0A-    uint64_t mcg_cap;=0A     uint64_t mcg_ctl;=0A  =
   uint64_t mcg_status;=0A     uint64_t *mci_ctl;=0A@@ -28,6 +27,8 @@ =
struct domain_mca_msrs=0A /* Guest vMCE MSRs virtualization */=0A extern =
int vmce_init_msr(struct domain *d);=0A extern void vmce_destroy_msr(struct=
 domain *d);=0A+extern void vmce_init_vcpu(struct vcpu *);=0A+extern int =
vmce_restore_vcpu(struct vcpu *, uint64_t caps);=0A extern int vmce_wrmsr(u=
int32_t msr, uint64_t val);=0A extern int vmce_rdmsr(uint32_t msr, =
uint64_t *val);=0A =0A--- a/xen/include/public/arch-x86/hvm/save.h=0A+++ =
b/xen/include/public/arch-x86/hvm/save.h=0A@@ -575,9 +575,15 @@ struct =
hvm_viridian_vcpu_context {=0A =0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, =
17, struct hvm_viridian_vcpu_context);=0A =0A+struct hvm_vmce_vcpu {=0A+   =
 uint64_t caps;=0A+};=0A+=0A+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct =
hvm_vmce_vcpu);=0A+=0A /* =0A  * Largest type-code in use=0A  */=0A-#define=
 HVM_SAVE_CODE_MAX 17=0A+#define HVM_SAVE_CODE_MAX 18=0A =0A #endif /* =
__XEN_PUBLIC_HVM_SAVE_X86_H__ */=0A--- a/xen/include/public/domctl.h=0A+++ =
b/xen/include/public/domctl.h=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_v=
cpucontext {=0A     uint32_t         vcpu;=0A     /*=0A      * SET: Size =
of struct (IN)=0A-     * GET: Size of struct (OUT)=0A+     * GET: Size of =
struct (OUT, up to 128 bytes)=0A      */=0A     uint32_t         size;=0A =
#if defined(__i386__) || defined(__x86_64__)=0A@@ -571,6 +571,7 @@ struct =
xen_domctl_ext_vcpucontext {=0A     uint16_t         sysenter_callback_cs;=
=0A     uint8_t          syscall32_disables_events;=0A     uint8_t         =
 sysenter_disables_events;=0A+    uint64_aligned_t mcg_cap;=0A #endif=0A =
};=0A typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_=
t;=0A
--=__Part507E2AA8.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part507E2AA8.3__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:44:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10: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.xensource.com>)
	id 1RwtO9-00031U-WB; Mon, 13 Feb 2012 10:44:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RwtO8-00030p-95
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:44:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329129837!7971860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19730 invoked from network); 13 Feb 2012 10:43:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:43:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 10:43:57 +0000
Message-Id: <4F38F77802000078000727B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 10:43:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
	<4F355B260200007800072704@nat28.tlf.novell.com>
	<20120213083057.GA4964@aepfle.de>
In-Reply-To: <20120213083057.GA4964@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 09:30, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 10, Jan Beulich wrote:
> 
>> > Regarding these messages, are they guest addresses?
>> > 
>> > (XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4
>> 
>> No, these are hypervisor ones.
> 
> These are the functions they belong to:
> 
> (XEN) traps.c:3131: GPF (0000): ffff82c4801d61ec -> ffff82c48022aa2e
> (XEN) do_general_protection: ffff82c4801d61ec vmx_msr_read_intercept+0x2d8/0x358
> (XEN) do_general_protection: ffff82c48022aa2e vmac+0x6c8/0x99a

This appears to be the rdmsr_safe() at the bottom of the default case
in vmx_msr_read_intercept(), and I would expect those to go away
once the vMCE save/restore patch is working properly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:44:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10: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.xensource.com>)
	id 1RwtO9-00031U-WB; Mon, 13 Feb 2012 10:44:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RwtO8-00030p-95
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:44:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329129837!7971860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19730 invoked from network); 13 Feb 2012 10:43:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 10:43:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 10:43:57 +0000
Message-Id: <4F38F77802000078000727B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 10:43:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210165338.GA23915@aepfle.de>
	<4F355B260200007800072704@nat28.tlf.novell.com>
	<20120213083057.GA4964@aepfle.de>
In-Reply-To: <20120213083057.GA4964@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 09:30, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 10, Jan Beulich wrote:
> 
>> > Regarding these messages, are they guest addresses?
>> > 
>> > (XEN) traps.c:3131: GPF (0000): ffff82c4801d4c6c -> ffff82c480226eb4
>> 
>> No, these are hypervisor ones.
> 
> These are the functions they belong to:
> 
> (XEN) traps.c:3131: GPF (0000): ffff82c4801d61ec -> ffff82c48022aa2e
> (XEN) do_general_protection: ffff82c4801d61ec vmx_msr_read_intercept+0x2d8/0x358
> (XEN) do_general_protection: ffff82c48022aa2e vmac+0x6c8/0x99a

This appears to be the rdmsr_safe() at the bottom of the default case
in vmx_msr_read_intercept(), and I would expect those to go away
once the vMCE save/restore patch is working properly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:46:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtQI-0003K8-HF; Mon, 13 Feb 2012 10:46:18 +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 1RwtQH-0003Jm-0V
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:46:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329129841!52465457!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20252 invoked from network); 13 Feb 2012 10:44:02 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 10:44:02 -0000
Received: by iaeh11 with SMTP id h11so26718966iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 02:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=0nV+QaH9cWRaQ2C7PE0kEJZUAHs28W2iPvcFVhS1Jfs=;
	b=wHdBg9r3d6L6maC88BDZU+/Lp+2OlKZiVVmGWgl/R2Hk20nLr0qmyBqPHIGLvLCwk0
	/f3Q6nmBfltztzsQAtvVJYxHACkvcWkp7xKk8MAQQsmoyS0MP7TOy8NAQ7Xt1R3ur9HC
	3brdn50io5Xh+XaG8BeILptZDe03Y1CNLP/5E=
MIME-Version: 1.0
Received: by 10.50.11.200 with SMTP id s8mr25970454igb.10.1329129974303; Mon,
	13 Feb 2012 02:46:14 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Mon, 13 Feb 2012 02:46:14 -0800 (PST)
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Date: Mon, 13 Feb 2012 10:46:14 +0000
X-Google-Sender-Auth: UTglByEMLpgSd0hntQPYEpM_F2s
Message-ID: <CAFLBxZYJsTjGtu0KcPQdd3uBpar5jVJs5WbzqiquazQ_JiexGA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 10:17 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> =A0 =A0 =A0* domctls / sysctls set up to modify scheduler parameters, like
> =A0 =A0 =A0 =A0the credit1 timeslice and schedule rate. (George Dunlap)

Not done; I'll try to get this fixed up this week.

> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl feature parity with xend wrt driver domai=
n support
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(George Dunlap)

I probably won't have time to start on this for another two weeks or
so; it's not clear ATM how long it might take to get working after
that (since I haven't even taken a cursory look at it).  If anyone is
sufficiently motivated to take a look, they're welcome to do so. :-)

Re blocker status: I think blockers aren't exactly binary, but more
like "How long can this reasonably block the release"?  I think this
should be probably allowed to delay the release for 1 month, but if
it's more than that (say, 6 months), it's probably best to release
without it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:46:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtQI-0003K8-HF; Mon, 13 Feb 2012 10:46:18 +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 1RwtQH-0003Jm-0V
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:46:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329129841!52465457!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20252 invoked from network); 13 Feb 2012 10:44:02 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 10:44:02 -0000
Received: by iaeh11 with SMTP id h11so26718966iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 02:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=0nV+QaH9cWRaQ2C7PE0kEJZUAHs28W2iPvcFVhS1Jfs=;
	b=wHdBg9r3d6L6maC88BDZU+/Lp+2OlKZiVVmGWgl/R2Hk20nLr0qmyBqPHIGLvLCwk0
	/f3Q6nmBfltztzsQAtvVJYxHACkvcWkp7xKk8MAQQsmoyS0MP7TOy8NAQ7Xt1R3ur9HC
	3brdn50io5Xh+XaG8BeILptZDe03Y1CNLP/5E=
MIME-Version: 1.0
Received: by 10.50.11.200 with SMTP id s8mr25970454igb.10.1329129974303; Mon,
	13 Feb 2012 02:46:14 -0800 (PST)
Received: by 10.231.208.1 with HTTP; Mon, 13 Feb 2012 02:46:14 -0800 (PST)
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Date: Mon, 13 Feb 2012 10:46:14 +0000
X-Google-Sender-Auth: UTglByEMLpgSd0hntQPYEpM_F2s
Message-ID: <CAFLBxZYJsTjGtu0KcPQdd3uBpar5jVJs5WbzqiquazQ_JiexGA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 10:17 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> =A0 =A0 =A0* domctls / sysctls set up to modify scheduler parameters, like
> =A0 =A0 =A0 =A0the credit1 timeslice and schedule rate. (George Dunlap)

Not done; I'll try to get this fixed up this week.

> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl feature parity with xend wrt driver domai=
n support
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(George Dunlap)

I probably won't have time to start on this for another two weeks or
so; it's not clear ATM how long it might take to get working after
that (since I haven't even taken a cursory look at it).  If anyone is
sufficiently motivated to take a look, they're welcome to do so. :-)

Re blocker status: I think blockers aren't exactly binary, but more
like "How long can this reasonably block the release"?  I think this
should be probably allowed to delay the release for 1 month, but if
it's more than that (say, 6 months), it's probably best to release
without it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:46:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtQW-0003Mu-Uz; Mon, 13 Feb 2012 10:46: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 1RwtQV-0003Lb-NX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:46:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329129914!62584837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15202 invoked from network); 13 Feb 2012 10:45:14 -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;
	13 Feb 2012 10:45:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10657375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10:46:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 10:46:25 +0000
Message-ID: <1329129984.31256.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Javanshir Farzin <j.farzin@yahoo.com>
Date: Mon, 13 Feb 2012 10:46:24 +0000
In-Reply-To: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
References: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] which linux distribution for XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 23:02 +0000, Javanshir Farzin wrote:
> I want to change XEN source code after that I will copile it, and I
> will survey change's effect. I have ubuntu 11.4 and centos 5.2. Which
> of the linux distributions is suitable for my job?
> thanks

If you are interested in developing Xen (as opposed to "just" using it)
then really any distro is fine since you aren't dependent on the
standard of their packaged support for Xen.

I suggest using the distro you are most familiar with, both Ubuntu and
CentOS are perfectly reasonable choices IMHO.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 10:46:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 10:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwtQW-0003Mu-Uz; Mon, 13 Feb 2012 10:46: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 1RwtQV-0003Lb-NX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 10:46:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329129914!62584837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15202 invoked from network); 13 Feb 2012 10:45:14 -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;
	13 Feb 2012 10:45:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10657375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10:46:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 10:46:25 +0000
Message-ID: <1329129984.31256.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Javanshir Farzin <j.farzin@yahoo.com>
Date: Mon, 13 Feb 2012 10:46:24 +0000
In-Reply-To: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
References: <1329001358.95462.YahooMailClassic@web161504.mail.bf1.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] which linux distribution for XEN
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 23:02 +0000, Javanshir Farzin wrote:
> I want to change XEN source code after that I will copile it, and I
> will survey change's effect. I have ubuntu 11.4 and centos 5.2. Which
> of the linux distributions is suitable for my job?
> thanks

If you are interested in developing Xen (as opposed to "just" using it)
then really any distro is fine since you aren't dependent on the
standard of their packaged support for Xen.

I suggest using the distro you are most familiar with, both Ubuntu and
CentOS are perfectly reasonable choices IMHO.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:05:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwtir-0003wj-U4; Mon, 13 Feb 2012 11:05:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwtiq-0003we-Am
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:05:28 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329131120!13127628!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4522 invoked from network); 13 Feb 2012 11:05:21 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2012 11:05:21 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwtih-0001GG-Vf
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 03:05:19 -0800
Date: Mon, 13 Feb 2012 03:05:19 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329131119975-5478798.post@n5.nabble.com>
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks to all developer for good work, I think it would be good to add these:

tools, nice to have: 
...
      * Add network script stuff for Open Vswitch support
      * Upstream qemu feature patches:
         ...
         * Spice full support and build enabled by default


About Spice support on qemu upstream, now is not built by default and on xl
configuration files is minimal. Probably there are also some required missed
options about qxl graphic needed by Spice on xl configuration files.
I search on tools/libxl/libxl_dm.c but I have found nothing about qxl now.

In these days I'll try to build and use Spice, and eventually I'll post
patches about to improve Spice support.

Anyone got the above stuff already working? Any patches out there?

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/4-2-TODO-update-tp5478696p5478798.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:05:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwtir-0003wj-U4; Mon, 13 Feb 2012 11:05:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwtiq-0003we-Am
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:05:28 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329131120!13127628!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4522 invoked from network); 13 Feb 2012 11:05:21 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2012 11:05:21 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwtih-0001GG-Vf
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 03:05:19 -0800
Date: Mon, 13 Feb 2012 03:05:19 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329131119975-5478798.post@n5.nabble.com>
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks to all developer for good work, I think it would be good to add these:

tools, nice to have: 
...
      * Add network script stuff for Open Vswitch support
      * Upstream qemu feature patches:
         ...
         * Spice full support and build enabled by default


About Spice support on qemu upstream, now is not built by default and on xl
configuration files is minimal. Probably there are also some required missed
options about qxl graphic needed by Spice on xl configuration files.
I search on tools/libxl/libxl_dm.c but I have found nothing about qxl now.

In these days I'll try to build and use Spice, and eventually I'll post
patches about to improve Spice support.

Anyone got the above stuff already working? Any patches out there?

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/4-2-TODO-update-tp5478696p5478798.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:11:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwtom-00046R-Rg; Mon, 13 Feb 2012 11:11: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 1Rwtom-00046K-5l
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:11:36 +0000
Received: from [85.158.139.83:8961] by server-1.bemta-5.messagelabs.com id
	E0/36-04285-7EFE83F4; Mon, 13 Feb 2012 11:11:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329131487!13979701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDI2MDQgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3300 invoked from network); 13 Feb 2012 11:11:27 -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;
	13 Feb 2012 11:11:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10658774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:11:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:11:27 +0000
Message-ID: <1329131485.31256.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Date: Mon, 13 Feb 2012 11:11:25 +0000
In-Reply-To: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
References: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Setting up an Event Channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 11:28 +0000, Nupur Ghatnekar wrote:
> I have been trying to setup an event channel. Following this blog
> http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/
> 
> But few of the functions used seem deprecated. 
> Any pointers as to how to progress?

I'm afraid that you haven't given enough information for anyone to be
able to offer effective guidance. I suggest you take a look at
http://wiki.xen.org/wiki/AskingXenDevelQuestions and consider expanding
your query with more background and detail (e.g. what is your goal, what
specific issues did you find etc).

Thanks,

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:11:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwtom-00046R-Rg; Mon, 13 Feb 2012 11:11: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 1Rwtom-00046K-5l
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:11:36 +0000
Received: from [85.158.139.83:8961] by server-1.bemta-5.messagelabs.com id
	E0/36-04285-7EFE83F4; Mon, 13 Feb 2012 11:11:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329131487!13979701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n,
	ML_RADAR_SPEW_LINKS_8, spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDI2MDQgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3300 invoked from network); 13 Feb 2012 11:11:27 -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;
	13 Feb 2012 11:11:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10658774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:11:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:11:27 +0000
Message-ID: <1329131485.31256.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Date: Mon, 13 Feb 2012 11:11:25 +0000
In-Reply-To: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
References: <CAO8_4VoVnmyt9SA9SnQ5GGnO+vE+eaP+YgyCtFm6Ve931-NxTA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Setting up an Event Channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 11:28 +0000, Nupur Ghatnekar wrote:
> I have been trying to setup an event channel. Following this blog
> http://aseemsethi.wordpress.com/article/learning-grant-tables-29fizhrip655z-5/
> 
> But few of the functions used seem deprecated. 
> Any pointers as to how to progress?

I'm afraid that you haven't given enough information for anyone to be
able to offer effective guidance. I suggest you take a look at
http://wiki.xen.org/wiki/AskingXenDevelQuestions and consider expanding
your query with more background and detail (e.g. what is your goal, what
specific issues did you find etc).

Thanks,

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:23:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwu03-0004RI-1j; Mon, 13 Feb 2012 11:23:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwu02-0004R8-2v
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:23:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329132187!4765061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31562 invoked from network); 13 Feb 2012 11:23:08 -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;
	13 Feb 2012 11:23:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:23:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:23:07 +0000
Message-ID: <1329132186.31256.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Mon, 13 Feb 2012 11:23:06 +0000
In-Reply-To: <1329131119975-5478798.post@n5.nabble.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 11:05 +0000, Fantu wrote:
> Thanks to all developer for good work, I think it would be good to add these:
> 
> tools, nice to have: 
> ...
>       * Add network script stuff for Open Vswitch support

I made a stab at this a way back but fell into the exact sorts of issues
that the "Hotplug script stuff" (already on the TODO) is supposed to
address (mainly the lack of a suitable teardown hook which vswitch
needs). However once that stuff is done I reckon vswitch support would
be reasonably easy to add.

>       * Upstream qemu feature patches:
>          ...
>          * Spice full support and build enabled by default
> 
> 
> About Spice support on qemu upstream, now is not built by default and on xl
> configuration files is minimal. Probably there are also some required missed
> options about qxl graphic needed by Spice on xl configuration files.
> I search on tools/libxl/libxl_dm.c but I have found nothing about qxl now.
> 
> In these days I'll try to build and use Spice, and eventually I'll post
> patches about to improve Spice support.

Thanks, I'm looking forward to your patches.

> Anyone got the above stuff already working? Any patches out there?

Presumably the contributor who added the spice support to libxl had but
they had probably built qemu upstream by hand with the appropriate
options. I'm not aware of any outstanding SPICE patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:23:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwu03-0004RI-1j; Mon, 13 Feb 2012 11:23:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwu02-0004R8-2v
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:23:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329132187!4765061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31562 invoked from network); 13 Feb 2012 11:23:08 -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;
	13 Feb 2012 11:23:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:23:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:23:07 +0000
Message-ID: <1329132186.31256.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Mon, 13 Feb 2012 11:23:06 +0000
In-Reply-To: <1329131119975-5478798.post@n5.nabble.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 11:05 +0000, Fantu wrote:
> Thanks to all developer for good work, I think it would be good to add these:
> 
> tools, nice to have: 
> ...
>       * Add network script stuff for Open Vswitch support

I made a stab at this a way back but fell into the exact sorts of issues
that the "Hotplug script stuff" (already on the TODO) is supposed to
address (mainly the lack of a suitable teardown hook which vswitch
needs). However once that stuff is done I reckon vswitch support would
be reasonably easy to add.

>       * Upstream qemu feature patches:
>          ...
>          * Spice full support and build enabled by default
> 
> 
> About Spice support on qemu upstream, now is not built by default and on xl
> configuration files is minimal. Probably there are also some required missed
> options about qxl graphic needed by Spice on xl configuration files.
> I search on tools/libxl/libxl_dm.c but I have found nothing about qxl now.
> 
> In these days I'll try to build and use Spice, and eventually I'll post
> patches about to improve Spice support.

Thanks, I'm looking forward to your patches.

> Anyone got the above stuff already working? Any patches out there?

Presumably the contributor who added the spice support to libxl had but
they had probably built qemu upstream by hand with the appropriate
options. I'm not aware of any outstanding SPICE patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:25:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwu1k-0004Wg-Hi; Mon, 13 Feb 2012 11:25:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwu1i-0004WZ-NZ
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:24:59 +0000
Received: from [193.109.254.147:38758] by server-5.bemta-14.messagelabs.com id
	2A/62-05697-903F83F4; Mon, 13 Feb 2012 11:24:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329132245!52495313!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6349 invoked from network); 13 Feb 2012 11:24:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:24:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 11:24:56 +0000
Message-Id: <4F3901130200007800072824@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 11:24:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFD18513.0__="
Subject: [Xen-devel] [PATCH] x86/vMCE: MC{G,i}_CTL handling adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFFD18513.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- g_mcg_cap was read to determine whether MCG_CTL exists before it got
  initialized
- h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via
  memset() with an inappropriate size (hence causing a [minor?]
  information leak)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -29,7 +29,7 @@ invbool_param("mce", mce_disabled);
 bool_t __read_mostly mce_broadcast =3D 0;
 bool_t is_mc_panic;
 unsigned int __read_mostly nr_mce_banks;
-int __read_mostly firstbank;
+unsigned int __read_mostly firstbank;
=20
 static void intpose_init(void);
 static void mcinfo_clear(struct mc_info *);
@@ -650,7 +650,7 @@ int mce_available(struct cpuinfo_x86 *c)
  * Check if bank 0 is usable for MCE. It isn't for AMD K7,
  * and Intel P6 family before model 0x1a.
  */
-int mce_firstbank(struct cpuinfo_x86 *c)
+unsigned int mce_firstbank(struct cpuinfo_x86 *c)
 {
     if (c->x86 =3D=3D 6) {
         if (c->x86_vendor =3D=3D X86_VENDOR_AMD)
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -52,7 +52,7 @@ int is_vmce_ready(struct mcinfo_bank *ba
 int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
=20
 u64 mce_cap_init(void);
-extern int firstbank;
+extern unsigned int firstbank;
=20
 int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
 int intel_mce_wrmsr(uint32_t msr, uint64_t val);
@@ -61,7 +61,7 @@ struct mcinfo_extended *intel_get_extend
     struct mcinfo_global *mig, struct mc_info *mi);
=20
 int mce_available(struct cpuinfo_x86 *c);
-int mce_firstbank(struct cpuinfo_x86 *c);
+unsigned int mce_firstbank(struct cpuinfo_x86 *c);
 /* Helper functions used for collecting error telemetry */
 struct mc_info *x86_mcinfo_getptr(void);
 void mc_panic(char *s);
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -39,7 +39,7 @@ int vmce_init_msr(struct domain *d)
         return -ENOMEM;
     }
     memset(dom_vmce(d)->mci_ctl, ~0,
-           sizeof(dom_vmce(d)->mci_ctl));
+           nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
     dom_vmce(d)->mcg_cap =3D g_mcg_cap;
@@ -438,7 +438,7 @@ int vmce_domain_inject(
 int vmce_init(struct cpuinfo_x86 *c)
 {
     u64 value;
-    int i;
+    unsigned int i;
=20
     if ( !h_mci_ctrl )
     {
@@ -449,17 +449,17 @@ int vmce_init(struct cpuinfo_x86 *c)
             return -ENOMEM;
         }
         /* Don't care banks before firstbank */
-        memset(h_mci_ctrl, 0xff, sizeof(h_mci_ctrl));
+        memset(h_mci_ctrl, ~0,
+               min(firstbank, nr_mce_banks) * sizeof(*h_mci_ctrl));
         for (i =3D firstbank; i < nr_mce_banks; i++)
             rdmsrl(MSR_IA32_MCx_CTL(i), h_mci_ctrl[i]);
     }
=20
-    if (g_mcg_cap & MCG_CTL_P)
-        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
-
     rdmsrl(MSR_IA32_MCG_CAP, value);
     /* For Guest vMCE usage */
     g_mcg_cap =3D value & ~MCG_CMCI_P;
+    if (value & MCG_CTL_P)
+        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
=20
     return 0;
 }




--=__PartFFD18513.0__=
Content-Type: text/plain; name="x86-vmce-mcg_ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-mcg_ctl.patch"

x86/vMCE: MC{G,i}_CTL handling adjustments=0A=0A- g_mcg_cap was read to =
determine whether MCG_CTL exists before it got=0A  initialized=0A- =
h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via=0A  =
memset() with an inappropriate size (hence causing a [minor?]=0A  =
information leak)=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/cpu/mcheck/mce.c=0A+++ b/xen/arch/x86/cpu/mcheck/mce.c=
=0A@@ -29,7 +29,7 @@ invbool_param("mce", mce_disabled);=0A bool_t =
__read_mostly mce_broadcast =3D 0;=0A bool_t is_mc_panic;=0A unsigned int =
__read_mostly nr_mce_banks;=0A-int __read_mostly firstbank;=0A+unsigned =
int __read_mostly firstbank;=0A =0A static void intpose_init(void);=0A =
static void mcinfo_clear(struct mc_info *);=0A@@ -650,7 +650,7 @@ int =
mce_available(struct cpuinfo_x86 *c)=0A  * Check if bank 0 is usable for =
MCE. It isn't for AMD K7,=0A  * and Intel P6 family before model 0x1a.=0A  =
*/=0A-int mce_firstbank(struct cpuinfo_x86 *c)=0A+unsigned int mce_firstban=
k(struct cpuinfo_x86 *c)=0A {=0A     if (c->x86 =3D=3D 6) {=0A         if =
(c->x86_vendor =3D=3D X86_VENDOR_AMD)=0A--- a/xen/arch/x86/cpu/mcheck/mce.h=
=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -52,7 +52,7 @@ int is_vmce_read=
y(struct mcinfo_bank *ba=0A int unmmap_broken_page(struct domain *d, mfn_t =
mfn, unsigned long gfn);=0A =0A u64 mce_cap_init(void);=0A-extern int =
firstbank;=0A+extern unsigned int firstbank;=0A =0A int intel_mce_rdmsr(uin=
t32_t msr, uint64_t *val);=0A int intel_mce_wrmsr(uint32_t msr, uint64_t =
val);=0A@@ -61,7 +61,7 @@ struct mcinfo_extended *intel_get_extend=0A     =
struct mcinfo_global *mig, struct mc_info *mi);=0A =0A int mce_available(st=
ruct cpuinfo_x86 *c);=0A-int mce_firstbank(struct cpuinfo_x86 *c);=0A+unsig=
ned int mce_firstbank(struct cpuinfo_x86 *c);=0A /* Helper functions used =
for collecting error telemetry */=0A struct mc_info *x86_mcinfo_getptr(void=
);=0A void mc_panic(char *s);=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ =
b/xen/arch/x86/cpu/mcheck/vmce.c=0A@@ -39,7 +39,7 @@ int vmce_init_msr(stru=
ct domain *d)=0A         return -ENOMEM;=0A     }=0A     memset(dom_vmce(d)=
->mci_ctl, ~0,=0A-           sizeof(dom_vmce(d)->mci_ctl));=0A+           =
nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));=0A =0A     dom_vmce(d)->mcg_=
status =3D 0x0;=0A     dom_vmce(d)->mcg_cap =3D g_mcg_cap;=0A@@ -438,7 =
+438,7 @@ int vmce_domain_inject(=0A int vmce_init(struct cpuinfo_x86 =
*c)=0A {=0A     u64 value;=0A-    int i;=0A+    unsigned int i;=0A =0A     =
if ( !h_mci_ctrl )=0A     {=0A@@ -449,17 +449,17 @@ int vmce_init(struct =
cpuinfo_x86 *c)=0A             return -ENOMEM;=0A         }=0A         /* =
Don't care banks before firstbank */=0A-        memset(h_mci_ctrl, 0xff, =
sizeof(h_mci_ctrl));=0A+        memset(h_mci_ctrl, ~0,=0A+               =
min(firstbank, nr_mce_banks) * sizeof(*h_mci_ctrl));=0A         for (i =3D =
firstbank; i < nr_mce_banks; i++)=0A             rdmsrl(MSR_IA32_MCx_CTL(i)=
, h_mci_ctrl[i]);=0A     }=0A =0A-    if (g_mcg_cap & MCG_CTL_P)=0A-       =
 rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);=0A-=0A     rdmsrl(MSR_IA32_MCG_CAP, =
value);=0A     /* For Guest vMCE usage */=0A     g_mcg_cap =3D value & =
~MCG_CMCI_P;=0A+    if (value & MCG_CTL_P)=0A+        rdmsrl(MSR_IA32_MCG_C=
TL, h_mcg_ctl);=0A =0A     return 0;=0A }=0A
--=__PartFFD18513.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartFFD18513.0__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:25:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwu1k-0004Wg-Hi; Mon, 13 Feb 2012 11:25:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwu1i-0004WZ-NZ
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:24:59 +0000
Received: from [193.109.254.147:38758] by server-5.bemta-14.messagelabs.com id
	2A/62-05697-903F83F4; Mon, 13 Feb 2012 11:24:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329132245!52495313!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6349 invoked from network); 13 Feb 2012 11:24:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:24:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 11:24:56 +0000
Message-Id: <4F3901130200007800072824@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 11:24:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFD18513.0__="
Subject: [Xen-devel] [PATCH] x86/vMCE: MC{G,i}_CTL handling adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFFD18513.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- g_mcg_cap was read to determine whether MCG_CTL exists before it got
  initialized
- h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via
  memset() with an inappropriate size (hence causing a [minor?]
  information leak)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -29,7 +29,7 @@ invbool_param("mce", mce_disabled);
 bool_t __read_mostly mce_broadcast =3D 0;
 bool_t is_mc_panic;
 unsigned int __read_mostly nr_mce_banks;
-int __read_mostly firstbank;
+unsigned int __read_mostly firstbank;
=20
 static void intpose_init(void);
 static void mcinfo_clear(struct mc_info *);
@@ -650,7 +650,7 @@ int mce_available(struct cpuinfo_x86 *c)
  * Check if bank 0 is usable for MCE. It isn't for AMD K7,
  * and Intel P6 family before model 0x1a.
  */
-int mce_firstbank(struct cpuinfo_x86 *c)
+unsigned int mce_firstbank(struct cpuinfo_x86 *c)
 {
     if (c->x86 =3D=3D 6) {
         if (c->x86_vendor =3D=3D X86_VENDOR_AMD)
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -52,7 +52,7 @@ int is_vmce_ready(struct mcinfo_bank *ba
 int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
=20
 u64 mce_cap_init(void);
-extern int firstbank;
+extern unsigned int firstbank;
=20
 int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
 int intel_mce_wrmsr(uint32_t msr, uint64_t val);
@@ -61,7 +61,7 @@ struct mcinfo_extended *intel_get_extend
     struct mcinfo_global *mig, struct mc_info *mi);
=20
 int mce_available(struct cpuinfo_x86 *c);
-int mce_firstbank(struct cpuinfo_x86 *c);
+unsigned int mce_firstbank(struct cpuinfo_x86 *c);
 /* Helper functions used for collecting error telemetry */
 struct mc_info *x86_mcinfo_getptr(void);
 void mc_panic(char *s);
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -39,7 +39,7 @@ int vmce_init_msr(struct domain *d)
         return -ENOMEM;
     }
     memset(dom_vmce(d)->mci_ctl, ~0,
-           sizeof(dom_vmce(d)->mci_ctl));
+           nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
     dom_vmce(d)->mcg_cap =3D g_mcg_cap;
@@ -438,7 +438,7 @@ int vmce_domain_inject(
 int vmce_init(struct cpuinfo_x86 *c)
 {
     u64 value;
-    int i;
+    unsigned int i;
=20
     if ( !h_mci_ctrl )
     {
@@ -449,17 +449,17 @@ int vmce_init(struct cpuinfo_x86 *c)
             return -ENOMEM;
         }
         /* Don't care banks before firstbank */
-        memset(h_mci_ctrl, 0xff, sizeof(h_mci_ctrl));
+        memset(h_mci_ctrl, ~0,
+               min(firstbank, nr_mce_banks) * sizeof(*h_mci_ctrl));
         for (i =3D firstbank; i < nr_mce_banks; i++)
             rdmsrl(MSR_IA32_MCx_CTL(i), h_mci_ctrl[i]);
     }
=20
-    if (g_mcg_cap & MCG_CTL_P)
-        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
-
     rdmsrl(MSR_IA32_MCG_CAP, value);
     /* For Guest vMCE usage */
     g_mcg_cap =3D value & ~MCG_CMCI_P;
+    if (value & MCG_CTL_P)
+        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
=20
     return 0;
 }




--=__PartFFD18513.0__=
Content-Type: text/plain; name="x86-vmce-mcg_ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-mcg_ctl.patch"

x86/vMCE: MC{G,i}_CTL handling adjustments=0A=0A- g_mcg_cap was read to =
determine whether MCG_CTL exists before it got=0A  initialized=0A- =
h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via=0A  =
memset() with an inappropriate size (hence causing a [minor?]=0A  =
information leak)=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/cpu/mcheck/mce.c=0A+++ b/xen/arch/x86/cpu/mcheck/mce.c=
=0A@@ -29,7 +29,7 @@ invbool_param("mce", mce_disabled);=0A bool_t =
__read_mostly mce_broadcast =3D 0;=0A bool_t is_mc_panic;=0A unsigned int =
__read_mostly nr_mce_banks;=0A-int __read_mostly firstbank;=0A+unsigned =
int __read_mostly firstbank;=0A =0A static void intpose_init(void);=0A =
static void mcinfo_clear(struct mc_info *);=0A@@ -650,7 +650,7 @@ int =
mce_available(struct cpuinfo_x86 *c)=0A  * Check if bank 0 is usable for =
MCE. It isn't for AMD K7,=0A  * and Intel P6 family before model 0x1a.=0A  =
*/=0A-int mce_firstbank(struct cpuinfo_x86 *c)=0A+unsigned int mce_firstban=
k(struct cpuinfo_x86 *c)=0A {=0A     if (c->x86 =3D=3D 6) {=0A         if =
(c->x86_vendor =3D=3D X86_VENDOR_AMD)=0A--- a/xen/arch/x86/cpu/mcheck/mce.h=
=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -52,7 +52,7 @@ int is_vmce_read=
y(struct mcinfo_bank *ba=0A int unmmap_broken_page(struct domain *d, mfn_t =
mfn, unsigned long gfn);=0A =0A u64 mce_cap_init(void);=0A-extern int =
firstbank;=0A+extern unsigned int firstbank;=0A =0A int intel_mce_rdmsr(uin=
t32_t msr, uint64_t *val);=0A int intel_mce_wrmsr(uint32_t msr, uint64_t =
val);=0A@@ -61,7 +61,7 @@ struct mcinfo_extended *intel_get_extend=0A     =
struct mcinfo_global *mig, struct mc_info *mi);=0A =0A int mce_available(st=
ruct cpuinfo_x86 *c);=0A-int mce_firstbank(struct cpuinfo_x86 *c);=0A+unsig=
ned int mce_firstbank(struct cpuinfo_x86 *c);=0A /* Helper functions used =
for collecting error telemetry */=0A struct mc_info *x86_mcinfo_getptr(void=
);=0A void mc_panic(char *s);=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ =
b/xen/arch/x86/cpu/mcheck/vmce.c=0A@@ -39,7 +39,7 @@ int vmce_init_msr(stru=
ct domain *d)=0A         return -ENOMEM;=0A     }=0A     memset(dom_vmce(d)=
->mci_ctl, ~0,=0A-           sizeof(dom_vmce(d)->mci_ctl));=0A+           =
nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));=0A =0A     dom_vmce(d)->mcg_=
status =3D 0x0;=0A     dom_vmce(d)->mcg_cap =3D g_mcg_cap;=0A@@ -438,7 =
+438,7 @@ int vmce_domain_inject(=0A int vmce_init(struct cpuinfo_x86 =
*c)=0A {=0A     u64 value;=0A-    int i;=0A+    unsigned int i;=0A =0A     =
if ( !h_mci_ctrl )=0A     {=0A@@ -449,17 +449,17 @@ int vmce_init(struct =
cpuinfo_x86 *c)=0A             return -ENOMEM;=0A         }=0A         /* =
Don't care banks before firstbank */=0A-        memset(h_mci_ctrl, 0xff, =
sizeof(h_mci_ctrl));=0A+        memset(h_mci_ctrl, ~0,=0A+               =
min(firstbank, nr_mce_banks) * sizeof(*h_mci_ctrl));=0A         for (i =3D =
firstbank; i < nr_mce_banks; i++)=0A             rdmsrl(MSR_IA32_MCx_CTL(i)=
, h_mci_ctrl[i]);=0A     }=0A =0A-    if (g_mcg_cap & MCG_CTL_P)=0A-       =
 rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);=0A-=0A     rdmsrl(MSR_IA32_MCG_CAP, =
value);=0A     /* For Guest vMCE usage */=0A     g_mcg_cap =3D value & =
~MCG_CMCI_P;=0A+    if (value & MCG_CTL_P)=0A+        rdmsrl(MSR_IA32_MCG_C=
TL, h_mcg_ctl);=0A =0A     return 0;=0A }=0A
--=__PartFFD18513.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartFFD18513.0__=--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:30:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwu6k-0004pT-43; Mon, 13 Feb 2012 11:30:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwu6f-0004pF-T3
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:30:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329132578!52655554!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3867 invoked from network); 13 Feb 2012 11:29:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:29:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 11:30:01 +0000
Message-Id: <4F390246020000780007285F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 11:29:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: anthony.perard@citrix.com, xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, blockers:
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich -- more fixes
>         required than first thought, patches posted)

The only one currently open is the one removing write permission for
Dom0. The intention was to get this in after the qemu usptream pass
through patch series got adjusted along the lines of what was done
to qemu traditional, and while this was promise to happen soon after
New Year I didn't hear back anything from Anthony or Stefano.

Question is whether, given that the patch series in question isn't in
anything that is or will soon be released, it makes sense to push the
hypervisor change without waiting for that fixup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:30:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwu6k-0004pT-43; Mon, 13 Feb 2012 11:30:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwu6f-0004pF-T3
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:30:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329132578!52655554!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3867 invoked from network); 13 Feb 2012 11:29:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:29:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 11:30:01 +0000
Message-Id: <4F390246020000780007285F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 11:29:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: anthony.perard@citrix.com, xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, blockers:
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich -- more fixes
>         required than first thought, patches posted)

The only one currently open is the one removing write permission for
Dom0. The intention was to get this in after the qemu usptream pass
through patch series got adjusted along the lines of what was done
to qemu traditional, and while this was promise to happen soon after
New Year I didn't hear back anything from Anthony or Stefano.

Question is whether, given that the patch series in question isn't in
anything that is or will soon be released, it makes sense to push the
hypervisor change without waiting for that fixup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:32:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1Rwu8o-0004yR-3z; Mon, 13 Feb 2012 11:32:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwu8m-0004yI-Mf
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:32:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329132712!65585724!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1985 invoked from network); 13 Feb 2012 11:31:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:31:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 11:32:15 +0000
Message-Id: <4F3902CD0200007800072881@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 11:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <4F300F55020000780007167D@nat28.tlf.novell.com>
In-Reply-To: <4F300F55020000780007167D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Ping: [PATCH] x86/paging: use clear_guest() for
 zero-filling guest buffers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 17:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> While static arrays of all zeros may be tolerable (but are simply
> inefficient now that we have the necessary infrastructure), using on-
> stack arrays for this purpose (particularly when their size doesn't
> have an upper limit enforced) is calling for eventual problems (even
> if the code can be reached via administrative interfaces only).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -21,11 +21,11 @@
>   */
>  
>  #include <xen/init.h>
> +#include <xen/guest_access.h>
>  #include <asm/paging.h>
>  #include <asm/shadow.h>
>  #include <asm/p2m.h>
>  #include <asm/hap.h>
> -#include <asm/guest_access.h>
>  #include <asm/hvm/nestedhvm.h>
>  #include <xen/numa.h>
>  #include <xsm/xsm.h>
> @@ -383,26 +383,30 @@ int paging_log_dirty_op(struct domain *d
>                    (pages < sc->pages) && (i2 < LOGDIRTY_NODE_ENTRIES);
>                    i2++ )
>              {
> -                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
>                  unsigned int bytes = PAGE_SIZE;
>                  l1 = ((l2 && mfn_valid(l2[i2])) ?
> -                      map_domain_page(mfn_x(l2[i2])) : zeroes);
> +                      map_domain_page(mfn_x(l2[i2])) : NULL);
>                  if ( unlikely(((sc->pages - pages + 7) >> 3) < bytes) )
>                      bytes = (unsigned int)((sc->pages - pages + 7) >> 3);
>                  if ( likely(peek) )
>                  {
> -                    if ( copy_to_guest_offset(sc->dirty_bitmap, pages >> 3,
> -                                              (uint8_t *)l1, bytes) != 0 )
> +                    if ( (l1 ? copy_to_guest_offset(sc->dirty_bitmap,
> +                                                    pages >> 3, (uint8_t 
> *)l1,
> +                                                    bytes)
> +                             : clear_guest_offset(sc->dirty_bitmap,
> +                                                  pages >> 3, bytes)) != 0 )
>                      {
>                          rv = -EFAULT;
>                          goto out;
>                      }
>                  }
> -                if ( clean && l1 != zeroes )
> -                    clear_page(l1);
>                  pages += bytes << 3;
> -                if ( l1 != zeroes )
> +                if ( l1 )
> +                {
> +                    if ( clean )
> +                        clear_page(l1);
>                      unmap_domain_page(l1);
> +                }
>              }
>              if ( l2 )
>                  unmap_domain_page(l2);
> @@ -462,12 +466,9 @@ int paging_log_dirty_range(struct domain
>  
>      if ( !d->arch.paging.log_dirty.fault_count &&
>           !d->arch.paging.log_dirty.dirty_count ) {
> -        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
> -        unsigned long zeroes[size];
> -        memset(zeroes, 0x00, size * BYTES_PER_LONG);
> -        rv = 0;
> -        if ( copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,
> -                                  size * BYTES_PER_LONG) != 0 )
> +        unsigned int size = BITS_TO_LONGS(nr);
> +
> +        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) != 0 )
>              rv = -EFAULT;
>          goto out;
>      }
> @@ -495,11 +496,10 @@ int paging_log_dirty_range(struct domain
>                    (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
>                    i2++ )
>              {
> -                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
>                  unsigned int bytes = PAGE_SIZE;
>                  uint8_t *s;
>                  l1 = ((l2 && mfn_valid(l2[i2])) ?
> -                      map_domain_page(mfn_x(l2[i2])) : zeroes);
> +                      map_domain_page(mfn_x(l2[i2])) : NULL);
>  
>                  s = ((uint8_t*)l1) + (b1 >> 3);
>                  bytes -= b1 >> 3;
> @@ -507,9 +507,18 @@ int paging_log_dirty_range(struct domain
>                  if ( likely(((nr - pages + 7) >> 3) < bytes) )
>                      bytes = (unsigned int)((nr - pages + 7) >> 3);
>  
> +                if ( !l1 )
> +                {
> +                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
> +                                            bytes) != 0 )
> +                    {
> +                        rv = -EFAULT;
> +                        goto out;
> +                    }
> +                }
>                  /* begin_pfn is not 32K aligned, hence we have to bit
>                   * shift the bitmap */
> -                if ( b1 & 0x7 )
> +                else if ( b1 & 0x7 )
>                  {
>                      int i, j;
>                      uint32_t *l = (uint32_t*) s;
> @@ -553,11 +562,12 @@ int paging_log_dirty_range(struct domain
>                      }
>                  }
>  
> -                if ( l1 != zeroes )
> -                    clear_page(l1);
>                  pages += bytes << 3;
> -                if ( l1 != zeroes )
> +                if ( l1 )
> +                {
> +                    clear_page(l1);
>                      unmap_domain_page(l1);
> +                }
>                  b1 = b1 & 0x7;
>              }
>              b2 = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:32:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1Rwu8o-0004yR-3z; Mon, 13 Feb 2012 11:32:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwu8m-0004yI-Mf
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:32:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329132712!65585724!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1985 invoked from network); 13 Feb 2012 11:31:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:31:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 11:32:15 +0000
Message-Id: <4F3902CD0200007800072881@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 11:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <4F300F55020000780007167D@nat28.tlf.novell.com>
In-Reply-To: <4F300F55020000780007167D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Ping: [PATCH] x86/paging: use clear_guest() for
 zero-filling guest buffers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.02.12 at 17:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> While static arrays of all zeros may be tolerable (but are simply
> inefficient now that we have the necessary infrastructure), using on-
> stack arrays for this purpose (particularly when their size doesn't
> have an upper limit enforced) is calling for eventual problems (even
> if the code can be reached via administrative interfaces only).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -21,11 +21,11 @@
>   */
>  
>  #include <xen/init.h>
> +#include <xen/guest_access.h>
>  #include <asm/paging.h>
>  #include <asm/shadow.h>
>  #include <asm/p2m.h>
>  #include <asm/hap.h>
> -#include <asm/guest_access.h>
>  #include <asm/hvm/nestedhvm.h>
>  #include <xen/numa.h>
>  #include <xsm/xsm.h>
> @@ -383,26 +383,30 @@ int paging_log_dirty_op(struct domain *d
>                    (pages < sc->pages) && (i2 < LOGDIRTY_NODE_ENTRIES);
>                    i2++ )
>              {
> -                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
>                  unsigned int bytes = PAGE_SIZE;
>                  l1 = ((l2 && mfn_valid(l2[i2])) ?
> -                      map_domain_page(mfn_x(l2[i2])) : zeroes);
> +                      map_domain_page(mfn_x(l2[i2])) : NULL);
>                  if ( unlikely(((sc->pages - pages + 7) >> 3) < bytes) )
>                      bytes = (unsigned int)((sc->pages - pages + 7) >> 3);
>                  if ( likely(peek) )
>                  {
> -                    if ( copy_to_guest_offset(sc->dirty_bitmap, pages >> 3,
> -                                              (uint8_t *)l1, bytes) != 0 )
> +                    if ( (l1 ? copy_to_guest_offset(sc->dirty_bitmap,
> +                                                    pages >> 3, (uint8_t 
> *)l1,
> +                                                    bytes)
> +                             : clear_guest_offset(sc->dirty_bitmap,
> +                                                  pages >> 3, bytes)) != 0 )
>                      {
>                          rv = -EFAULT;
>                          goto out;
>                      }
>                  }
> -                if ( clean && l1 != zeroes )
> -                    clear_page(l1);
>                  pages += bytes << 3;
> -                if ( l1 != zeroes )
> +                if ( l1 )
> +                {
> +                    if ( clean )
> +                        clear_page(l1);
>                      unmap_domain_page(l1);
> +                }
>              }
>              if ( l2 )
>                  unmap_domain_page(l2);
> @@ -462,12 +466,9 @@ int paging_log_dirty_range(struct domain
>  
>      if ( !d->arch.paging.log_dirty.fault_count &&
>           !d->arch.paging.log_dirty.dirty_count ) {
> -        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
> -        unsigned long zeroes[size];
> -        memset(zeroes, 0x00, size * BYTES_PER_LONG);
> -        rv = 0;
> -        if ( copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,
> -                                  size * BYTES_PER_LONG) != 0 )
> +        unsigned int size = BITS_TO_LONGS(nr);
> +
> +        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) != 0 )
>              rv = -EFAULT;
>          goto out;
>      }
> @@ -495,11 +496,10 @@ int paging_log_dirty_range(struct domain
>                    (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
>                    i2++ )
>              {
> -                static unsigned long zeroes[PAGE_SIZE/BYTES_PER_LONG];
>                  unsigned int bytes = PAGE_SIZE;
>                  uint8_t *s;
>                  l1 = ((l2 && mfn_valid(l2[i2])) ?
> -                      map_domain_page(mfn_x(l2[i2])) : zeroes);
> +                      map_domain_page(mfn_x(l2[i2])) : NULL);
>  
>                  s = ((uint8_t*)l1) + (b1 >> 3);
>                  bytes -= b1 >> 3;
> @@ -507,9 +507,18 @@ int paging_log_dirty_range(struct domain
>                  if ( likely(((nr - pages + 7) >> 3) < bytes) )
>                      bytes = (unsigned int)((nr - pages + 7) >> 3);
>  
> +                if ( !l1 )
> +                {
> +                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
> +                                            bytes) != 0 )
> +                    {
> +                        rv = -EFAULT;
> +                        goto out;
> +                    }
> +                }
>                  /* begin_pfn is not 32K aligned, hence we have to bit
>                   * shift the bitmap */
> -                if ( b1 & 0x7 )
> +                else if ( b1 & 0x7 )
>                  {
>                      int i, j;
>                      uint32_t *l = (uint32_t*) s;
> @@ -553,11 +562,12 @@ int paging_log_dirty_range(struct domain
>                      }
>                  }
>  
> -                if ( l1 != zeroes )
> -                    clear_page(l1);
>                  pages += bytes << 3;
> -                if ( l1 != zeroes )
> +                if ( l1 )
> +                {
> +                    clear_page(l1);
>                      unmap_domain_page(l1);
> +                }
>                  b1 = b1 & 0x7;
>              }
>              b2 = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:33:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwu9d-00052h-I7; Mon, 13 Feb 2012 11:33:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwu9b-00051y-SD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:33:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329132780!14558984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26161 invoked from network); 13 Feb 2012 11:33:01 -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;
	13 Feb 2012 11:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:32:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:32:59 +0000
Message-ID: <1329132778.31256.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 13 Feb 2012 11:32:58 +0000
In-Reply-To: <4F390246020000780007285F@nat28.tlf.novell.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 11:29 +0000, Jan Beulich wrote:
> >>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, blockers:
> >       * round-up of the closing of the security hole in MSI-X
> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
> >         access to MSI-X table pages). (Jan Beulich -- more fixes
> >         required than first thought, patches posted)
> 
> The only one currently open is the one removing write permission for
> Dom0.

Oh, I thought you had found another issue which required further
patches. Did I misunderstand or did they go in already?

>  The intention was to get this in after the qemu usptream pass
> through patch series got adjusted along the lines of what was done
> to qemu traditional, and while this was promise to happen soon after
> New Year I didn't hear back anything from Anthony or Stefano.
> 
> Question is whether, given that the patch series in question isn't in
> anything that is or will soon be released, it makes sense to push the
> hypervisor change without waiting for that fixup.

I don't think it is necessary to wait for the qemu-upstream patch series
to be updated for this, is it?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:33:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwu9d-00052h-I7; Mon, 13 Feb 2012 11:33:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwu9b-00051y-SD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:33:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329132780!14558984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26161 invoked from network); 13 Feb 2012 11:33:01 -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;
	13 Feb 2012 11:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:32:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:32:59 +0000
Message-ID: <1329132778.31256.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 13 Feb 2012 11:32:58 +0000
In-Reply-To: <4F390246020000780007285F@nat28.tlf.novell.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 11:29 +0000, Jan Beulich wrote:
> >>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, blockers:
> >       * round-up of the closing of the security hole in MSI-X
> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
> >         access to MSI-X table pages). (Jan Beulich -- more fixes
> >         required than first thought, patches posted)
> 
> The only one currently open is the one removing write permission for
> Dom0.

Oh, I thought you had found another issue which required further
patches. Did I misunderstand or did they go in already?

>  The intention was to get this in after the qemu usptream pass
> through patch series got adjusted along the lines of what was done
> to qemu traditional, and while this was promise to happen soon after
> New Year I didn't hear back anything from Anthony or Stefano.
> 
> Question is whether, given that the patch series in question isn't in
> anything that is or will soon be released, it makes sense to push the
> hypervisor change without waiting for that fixup.

I don't think it is necessary to wait for the qemu-upstream patch series
to be updated for this, is it?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:37:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1RwuDa-0005JP-7T; Mon, 13 Feb 2012 11:37:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RwuDY-0005J0-7m
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:37:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329132979!59877240!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 13 Feb 2012 11:36:22 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:36:22 -0000
Received: by werb14 with SMTP id b14so14680906wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=wuCKQl2oIKN2cfwMO6u8+jUuQ61qSgwKgEwhyXQLAYE=;
	b=vwGLF3FVwSZRUO/gdWOMA/6XFou55HRUco/Eikxi09j2J4XP/cMgX1IaLsO5yXTBss
	7I71JzTZRuWXjtrR2uocjThmAkzf46ZXRWtHy575ZcUguvJsIbp6UXEYM4vksUv7Zy/Y
	8XtFjdvy/qLxORwQN2AIZLDV1Wm0cLxb+g2BI=
MIME-Version: 1.0
Received: by 10.180.78.130 with SMTP id b2mr17856532wix.1.1329133023319; Mon,
	13 Feb 2012 03:37:03 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 13 Feb 2012 03:37:03 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
	<alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
Date: Mon, 13 Feb 2012 12:37:03 +0100
X-Google-Sender-Auth: cbYoNkNDejYzi9i7V93LJOxj4q0
Message-ID: <CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzEwIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIEZyaSwgMTAgRmViIDIwMTIsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IEhlbGxvLAo+Pgo+PiBJJ3ZlIHJlY2VudGx5IHNldHVwIGEgTGludXggRG9tMCB3aXRoIGEgMy4w
LjE3IGtlcm5lbCBhbmQgWGVuIDQuMS4yLAo+PiBhbmQgc2luY2UgdGhlIDMueCBzZXJpZXMgZG9l
c24ndCBoYXZlIGJsa3RhcCBzdXBwb3J0IEknbSB1c2luZyBxZGlzawo+PiB0byBhdHRhY2ggcmF3
IGltYWdlcy4gSSd2ZSBiZWVuIHBsYXlpbmcgd2l0aCBzbWFsbCBpbWFnZXMsIHNvbWV0aGluZwo+
PiBsaWtlIDFHQiwgYW5kIGV2ZXJ5dGhpbmcgc2VlbWVkIGZpbmUsIHNwZWVkIHdhcyBub3QgZmFu
dGFzdGljIGJ1dCBpdAo+PiB3YXMgb2suIFRvZGF5IEkndmUgc2V0IHVwIGEgYmlnZ2VyIG1hY2hp
bmUsIHdpdGggYSAyMEdCIHJhdyBoZGQgYW5kCj4+IHRoZSBkaXNrIHdyaXRlIHRocm91Z2hwdXQg
aXMgcmVhbGx5IHNsb3csIGluZmVyaW9yIHRvIDAuNU1CL3MuIEknbQo+PiB0cnlpbmcgdG8gaW5z
dGFsbCBhIERlYmlhbiBQViB0aGVyZSwgYW5kIGFmdGVyIG1vcmUgdGhhbiAzIGhvdXJzIGl0IGlz
Cj4+IHN0aWxsIGluc3RhbGxpbmcgdGhlIGJhc2Ugc3lzdGVtLgo+Pgo+PiBJJ3ZlIGxvb2tlZCBh
dCB0aGUgeGVuc3RvcmUgYmFja2VuZCBlbnRyaWVzLCBhbmQgZXZlcnl0aGluZyBsb29rcyBmaW5l
Ogo+Pgo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81MTcxMi9mcm9udGVuZCA9
Cj4+ICIvbG9jYWwvZG9tYWluLzIxL2RldmljZS92YmQvNTE3MTIiIMKgIChuMCxyMjEpCj4+IC9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzIxLzUxNzEyL3BhcmFtcyA9Cj4+ICJhaW86L2hk
ZC92bS9zZXJ2bGV0L3NlcnZsZXQuaW1nIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAv
YmFja2VuZC9xZGlzay8yMS81MTcxMi9mcm9udGVuZC1pZCA9ICIyMSIgwqAgKG4wLHIyMSkKPj4g
L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvb25saW5lID0gIjEiIMKgIChu
MCxyMjEpCj4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzIxLzUxNzEyL3JlbW92YWJs
ZSA9ICIwIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81
MTcxMi9ib290YWJsZSA9ICIxIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2Vu
ZC9xZGlzay8yMS81MTcxMi9zdGF0ZSA9ICI0IiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWlu
LzAvYmFja2VuZC9xZGlzay8yMS81MTcxMi9kZXYgPSAieHZkYSIgwqAgKG4wLHIyMSkKPj4gL2xv
Y2FsL2RvbWFpbi8wL2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvdHlwZSA9ICJ0YXAiIMKgIChuMCxy
MjEpCj4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzIxLzUxNzEyL21vZGUgPSAidyIg
wqAgKG4wLHIyMSkKPj4gL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvZmVh
dHVyZS1iYXJyaWVyID0gIjEiIMKgIChuMCxyMjEpCj4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5k
L3FkaXNrLzIxLzUxNzEyL2luZm8gPSAiMCIgwqAgKG4wLHIyMSkKPj4gL2xvY2FsL2RvbWFpbi8w
L2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvc2VjdG9yLXNpemUgPSAiNTEyIiDCoCAobjAscjIxKQo+
PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81MTcxMi9zZWN0b3JzID0gIjQwOTYw
MDAwIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81MTcx
Mi9ob3RwbHVnLXN0YXR1cyA9ICJjb25uZWN0ZWQiIMKgIChuMCxyMjEpCj4+Cj4+IEFsc28sIHRo
ZSByZWxhdGVkIHFlbXUtZG0gcHJvY2VzcyBkb2Vzbid0IHNlZW0gdG8gYmUgaHVuZyBieSBDUFUs
IGluCj4+IGZhY3QgaXQgaXMgcmVwb3J0aW5nIGEgQ1BVIHVzYWdlIG9mIDAlIGFsbW9zdCBhbGwg
dGhlIHRpbWUuIEkndmUKPj4gYXR0YWNoZWQgdG8gdGhlIHFlbXUtZG0gcHJvY2VzcyB3aXRoIHN0
cmFjZSwgYW5kIGl0IGlzIGRvaW5nIGxzZWVrcwo+PiBhbmQgd3JpdGVzIGxpa2UgY3JhenksIGlz
IHRoaXMgbm9ybWFsPyBJcyB0aGVyZSBhbnkgaW1wcm92ZW1lbnQgd2hlbgo+PiB1c2luZyBxZW11
LXVwc3RyZWFtPwo+Cj4gWWVzLCBncmVhdCBpbXByb3ZlbWVudHMuCj4gVGhlIG9sZCBxZW11LXhl
biB1c2VzIHRocmVhZHMgdG8gc2ltdWxhdGUgYXN5bmMgSU8gc28gaXQgaXMgdmVyeSBzbG93Owo+
IHVwc3RyZWFtIFFFTVUgdXNlcyBMaW51eCBBSU8gYW5kIGlzIG11Y2ggZmFzdGVyLgoKVGhhdCdz
IGdyZWF0IG5ld3MsIHNvIHFkaXNrIHBlcmZvcm1hbmNlIGluIHFlbXUtdXBzdHJlYW0gc2hvdWxk
IGJlCnNpbWlsYXIgdG8gYmxrdGFwPwoKPiBJIHdvdWxkbid0IGV4cGVjdCBpdCB0byBoYW5nIGNv
bXBsZXRlbHkgdGhvdWdoLCB0aGF0IG1pZ2h0IGJlIGEgYnVnLgoKTm8sIGl0IGRvZXNuJ3QgaGFu
ZyBjb21wbGV0ZWx5LCBqdXN0IHZlcnkgc2xvdy4KCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:37:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1RwuDa-0005JP-7T; Mon, 13 Feb 2012 11:37:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RwuDY-0005J0-7m
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:37:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329132979!59877240!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 13 Feb 2012 11:36:22 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:36:22 -0000
Received: by werb14 with SMTP id b14so14680906wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=wuCKQl2oIKN2cfwMO6u8+jUuQ61qSgwKgEwhyXQLAYE=;
	b=vwGLF3FVwSZRUO/gdWOMA/6XFou55HRUco/Eikxi09j2J4XP/cMgX1IaLsO5yXTBss
	7I71JzTZRuWXjtrR2uocjThmAkzf46ZXRWtHy575ZcUguvJsIbp6UXEYM4vksUv7Zy/Y
	8XtFjdvy/qLxORwQN2AIZLDV1Wm0cLxb+g2BI=
MIME-Version: 1.0
Received: by 10.180.78.130 with SMTP id b2mr17856532wix.1.1329133023319; Mon,
	13 Feb 2012 03:37:03 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 13 Feb 2012 03:37:03 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
	<alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
Date: Mon, 13 Feb 2012 12:37:03 +0100
X-Google-Sender-Auth: cbYoNkNDejYzi9i7V93LJOxj4q0
Message-ID: <CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzEwIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIEZyaSwgMTAgRmViIDIwMTIsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
IEhlbGxvLAo+Pgo+PiBJJ3ZlIHJlY2VudGx5IHNldHVwIGEgTGludXggRG9tMCB3aXRoIGEgMy4w
LjE3IGtlcm5lbCBhbmQgWGVuIDQuMS4yLAo+PiBhbmQgc2luY2UgdGhlIDMueCBzZXJpZXMgZG9l
c24ndCBoYXZlIGJsa3RhcCBzdXBwb3J0IEknbSB1c2luZyBxZGlzawo+PiB0byBhdHRhY2ggcmF3
IGltYWdlcy4gSSd2ZSBiZWVuIHBsYXlpbmcgd2l0aCBzbWFsbCBpbWFnZXMsIHNvbWV0aGluZwo+
PiBsaWtlIDFHQiwgYW5kIGV2ZXJ5dGhpbmcgc2VlbWVkIGZpbmUsIHNwZWVkIHdhcyBub3QgZmFu
dGFzdGljIGJ1dCBpdAo+PiB3YXMgb2suIFRvZGF5IEkndmUgc2V0IHVwIGEgYmlnZ2VyIG1hY2hp
bmUsIHdpdGggYSAyMEdCIHJhdyBoZGQgYW5kCj4+IHRoZSBkaXNrIHdyaXRlIHRocm91Z2hwdXQg
aXMgcmVhbGx5IHNsb3csIGluZmVyaW9yIHRvIDAuNU1CL3MuIEknbQo+PiB0cnlpbmcgdG8gaW5z
dGFsbCBhIERlYmlhbiBQViB0aGVyZSwgYW5kIGFmdGVyIG1vcmUgdGhhbiAzIGhvdXJzIGl0IGlz
Cj4+IHN0aWxsIGluc3RhbGxpbmcgdGhlIGJhc2Ugc3lzdGVtLgo+Pgo+PiBJJ3ZlIGxvb2tlZCBh
dCB0aGUgeGVuc3RvcmUgYmFja2VuZCBlbnRyaWVzLCBhbmQgZXZlcnl0aGluZyBsb29rcyBmaW5l
Ogo+Pgo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81MTcxMi9mcm9udGVuZCA9
Cj4+ICIvbG9jYWwvZG9tYWluLzIxL2RldmljZS92YmQvNTE3MTIiIMKgIChuMCxyMjEpCj4+IC9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzIxLzUxNzEyL3BhcmFtcyA9Cj4+ICJhaW86L2hk
ZC92bS9zZXJ2bGV0L3NlcnZsZXQuaW1nIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAv
YmFja2VuZC9xZGlzay8yMS81MTcxMi9mcm9udGVuZC1pZCA9ICIyMSIgwqAgKG4wLHIyMSkKPj4g
L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvb25saW5lID0gIjEiIMKgIChu
MCxyMjEpCj4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzIxLzUxNzEyL3JlbW92YWJs
ZSA9ICIwIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81
MTcxMi9ib290YWJsZSA9ICIxIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2Vu
ZC9xZGlzay8yMS81MTcxMi9zdGF0ZSA9ICI0IiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWlu
LzAvYmFja2VuZC9xZGlzay8yMS81MTcxMi9kZXYgPSAieHZkYSIgwqAgKG4wLHIyMSkKPj4gL2xv
Y2FsL2RvbWFpbi8wL2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvdHlwZSA9ICJ0YXAiIMKgIChuMCxy
MjEpCj4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3FkaXNrLzIxLzUxNzEyL21vZGUgPSAidyIg
wqAgKG4wLHIyMSkKPj4gL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvZmVh
dHVyZS1iYXJyaWVyID0gIjEiIMKgIChuMCxyMjEpCj4+IC9sb2NhbC9kb21haW4vMC9iYWNrZW5k
L3FkaXNrLzIxLzUxNzEyL2luZm8gPSAiMCIgwqAgKG4wLHIyMSkKPj4gL2xvY2FsL2RvbWFpbi8w
L2JhY2tlbmQvcWRpc2svMjEvNTE3MTIvc2VjdG9yLXNpemUgPSAiNTEyIiDCoCAobjAscjIxKQo+
PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81MTcxMi9zZWN0b3JzID0gIjQwOTYw
MDAwIiDCoCAobjAscjIxKQo+PiAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC9xZGlzay8yMS81MTcx
Mi9ob3RwbHVnLXN0YXR1cyA9ICJjb25uZWN0ZWQiIMKgIChuMCxyMjEpCj4+Cj4+IEFsc28sIHRo
ZSByZWxhdGVkIHFlbXUtZG0gcHJvY2VzcyBkb2Vzbid0IHNlZW0gdG8gYmUgaHVuZyBieSBDUFUs
IGluCj4+IGZhY3QgaXQgaXMgcmVwb3J0aW5nIGEgQ1BVIHVzYWdlIG9mIDAlIGFsbW9zdCBhbGwg
dGhlIHRpbWUuIEkndmUKPj4gYXR0YWNoZWQgdG8gdGhlIHFlbXUtZG0gcHJvY2VzcyB3aXRoIHN0
cmFjZSwgYW5kIGl0IGlzIGRvaW5nIGxzZWVrcwo+PiBhbmQgd3JpdGVzIGxpa2UgY3JhenksIGlz
IHRoaXMgbm9ybWFsPyBJcyB0aGVyZSBhbnkgaW1wcm92ZW1lbnQgd2hlbgo+PiB1c2luZyBxZW11
LXVwc3RyZWFtPwo+Cj4gWWVzLCBncmVhdCBpbXByb3ZlbWVudHMuCj4gVGhlIG9sZCBxZW11LXhl
biB1c2VzIHRocmVhZHMgdG8gc2ltdWxhdGUgYXN5bmMgSU8gc28gaXQgaXMgdmVyeSBzbG93Owo+
IHVwc3RyZWFtIFFFTVUgdXNlcyBMaW51eCBBSU8gYW5kIGlzIG11Y2ggZmFzdGVyLgoKVGhhdCdz
IGdyZWF0IG5ld3MsIHNvIHFkaXNrIHBlcmZvcm1hbmNlIGluIHFlbXUtdXBzdHJlYW0gc2hvdWxk
IGJlCnNpbWlsYXIgdG8gYmxrdGFwPwoKPiBJIHdvdWxkbid0IGV4cGVjdCBpdCB0byBoYW5nIGNv
bXBsZXRlbHkgdGhvdWdoLCB0aGF0IG1pZ2h0IGJlIGEgYnVnLgoKTm8sIGl0IGRvZXNuJ3QgaGFu
ZyBjb21wbGV0ZWx5LCBqdXN0IHZlcnkgc2xvdy4KCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuFt-0005Pt-PE; Mon, 13 Feb 2012 11:39:37 +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 1RwuFt-0005Pg-2d
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:39:37 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329133127!59877803!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25590 invoked from network); 13 Feb 2012 11:38:48 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:38:48 -0000
Received: by obcuy19 with SMTP id uy19so25349569obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:39:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=85T5iix7KpsiGDyyQlwNR9LxFa1Uh9LCSuHxCLNIMDo=;
	b=QI/NTa+WM2qFl5WWinNnAWu5/yMtOScR04MEi80VtQZLKZYPJAa7j5GZth86Bom8xt
	XSCFV8hlIP3LrBE/2qFD+SaMSmjcPbBPS+kLqemQRsac85LQBuhU2OVqXyh69XXZ2TmL
	VZI/4CdYNSB/ElJXJ5ecFsZrU/iXIe6ZTXhcs=
Received: by 10.60.3.104 with SMTP id b8mr3990452oeb.13.1329133171300; Mon, 13
	Feb 2012 03:39:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 13 Feb 2012 03:39:01 -0800 (PST)
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 13 Feb 2012 11:39:01 +0000
X-Google-Sender-Auth: CytPs9w7NtpaqL-RLeeiie6CaGk
Message-ID: <CAJJyHjKdGb6mHEbMu6gu2-717EUpjLHxiycd5q525uMJOaYnfA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCBGZWIgMTMsIDIwMTIgYXQgMTA6MTcsIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+IHdyb3RlOgo+IMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IGZlYXR1cmUgcGF0
Y2hlczoKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91
Z2ggc3VwcG9ydCAoQW50aG9ueSBQZXJhcmQpCgpJJ2xsIHNlbmQgYSBuZXcgcGF0Y2ggc2V0IHNv
b24sIGJ1dCB0aGUgcG93ZXIgbWFuYWdlbWVudCBjYXBhYmlsaXR5CndpbGwgYmUgbWlzc2luZyBh
cyBpdCdzIG5lZWQgYSBiaXQgbW9yZSB3b3JrLgpBbHNvLCB0aGlzIHBhdGNoIHNlcmllcyBkb2Vz
IG5vdCBsb25ndWVyIGluY2x1ZGUgdGhlIG1zaXRyYW5zbGF0ZSBjb2RlLgoKPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBzYXZlIHJlc3RvcmUgKEFudGhvbnkgUGVyYXJkLCBT
dGVmYW5vCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTdGFiZWxsaW5pKQoKU3RpbGwgbmVlZCBz
b21lIGFjayBmcm9tIHFlbXUncyBkZXZlbG9wcGVyLgoKLS0gCkFudGhvbnkgUEVSQVJECgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuFt-0005Pt-PE; Mon, 13 Feb 2012 11:39:37 +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 1RwuFt-0005Pg-2d
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:39:37 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329133127!59877803!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25590 invoked from network); 13 Feb 2012 11:38:48 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:38:48 -0000
Received: by obcuy19 with SMTP id uy19so25349569obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:39:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=85T5iix7KpsiGDyyQlwNR9LxFa1Uh9LCSuHxCLNIMDo=;
	b=QI/NTa+WM2qFl5WWinNnAWu5/yMtOScR04MEi80VtQZLKZYPJAa7j5GZth86Bom8xt
	XSCFV8hlIP3LrBE/2qFD+SaMSmjcPbBPS+kLqemQRsac85LQBuhU2OVqXyh69XXZ2TmL
	VZI/4CdYNSB/ElJXJ5ecFsZrU/iXIe6ZTXhcs=
Received: by 10.60.3.104 with SMTP id b8mr3990452oeb.13.1329133171300; Mon, 13
	Feb 2012 03:39:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 13 Feb 2012 03:39:01 -0800 (PST)
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 13 Feb 2012 11:39:01 +0000
X-Google-Sender-Auth: CytPs9w7NtpaqL-RLeeiie6CaGk
Message-ID: <CAJJyHjKdGb6mHEbMu6gu2-717EUpjLHxiycd5q525uMJOaYnfA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCBGZWIgMTMsIDIwMTIgYXQgMTA6MTcsIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+IHdyb3RlOgo+IMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IGZlYXR1cmUgcGF0
Y2hlczoKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91
Z2ggc3VwcG9ydCAoQW50aG9ueSBQZXJhcmQpCgpJJ2xsIHNlbmQgYSBuZXcgcGF0Y2ggc2V0IHNv
b24sIGJ1dCB0aGUgcG93ZXIgbWFuYWdlbWVudCBjYXBhYmlsaXR5CndpbGwgYmUgbWlzc2luZyBh
cyBpdCdzIG5lZWQgYSBiaXQgbW9yZSB3b3JrLgpBbHNvLCB0aGlzIHBhdGNoIHNlcmllcyBkb2Vz
IG5vdCBsb25ndWVyIGluY2x1ZGUgdGhlIG1zaXRyYW5zbGF0ZSBjb2RlLgoKPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBzYXZlIHJlc3RvcmUgKEFudGhvbnkgUGVyYXJkLCBT
dGVmYW5vCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTdGFiZWxsaW5pKQoKU3RpbGwgbmVlZCBz
b21lIGFjayBmcm9tIHFlbXUncyBkZXZlbG9wcGVyLgoKLS0gCkFudGhvbnkgUEVSQVJECgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:41:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuHt-0005Xi-9n; Mon, 13 Feb 2012 11:41:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RwuHr-0005XO-EA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:41:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329133292!8474151!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3856 invoked from network); 13 Feb 2012 11:41:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:41:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwuHh-000NUf-DL; Mon, 13 Feb 2012 11:41:29 +0000
Date: Mon, 13 Feb 2012 11:41:29 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120213114129.GD88765@ocelot.phlegethon.org>
References: <4F300F55020000780007167D@nat28.tlf.novell.com>
	<4F3902CD0200007800072881@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3902CD0200007800072881@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Ping: [PATCH] x86/paging: use clear_guest() for
	zero-filling guest buffers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 11:32 +0000 on 13 Feb (1329132733), Jan Beulich wrote:
> >>> On 06.02.12 at 17:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> > While static arrays of all zeros may be tolerable (but are simply
> > inefficient now that we have the necessary infrastructure), using on-
> > stack arrays for this purpose (particularly when their size doesn't
> > have an upper limit enforced) is calling for eventual problems (even
> > if the code can be reached via administrative interfaces only).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>

Sorry, I completely missed this the first time.

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:41:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuHt-0005Xi-9n; Mon, 13 Feb 2012 11:41:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RwuHr-0005XO-EA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:41:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329133292!8474151!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3856 invoked from network); 13 Feb 2012 11:41:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 11:41:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwuHh-000NUf-DL; Mon, 13 Feb 2012 11:41:29 +0000
Date: Mon, 13 Feb 2012 11:41:29 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120213114129.GD88765@ocelot.phlegethon.org>
References: <4F300F55020000780007167D@nat28.tlf.novell.com>
	<4F3902CD0200007800072881@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3902CD0200007800072881@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Ping: [PATCH] x86/paging: use clear_guest() for
	zero-filling guest buffers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 11:32 +0000 on 13 Feb (1329132733), Jan Beulich wrote:
> >>> On 06.02.12 at 17:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> > While static arrays of all zeros may be tolerable (but are simply
> > inefficient now that we have the necessary infrastructure), using on-
> > stack arrays for this purpose (particularly when their size doesn't
> > have an upper limit enforced) is calling for eventual problems (even
> > if the code can be reached via administrative interfaces only).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>

Sorry, I completely missed this the first time.

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:48:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1RwuOG-0005nj-6X; Mon, 13 Feb 2012 11:48:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwuOD-0005nX-L2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:48:14 +0000
Received: from [85.158.139.83:31894] by server-12.bemta-5.messagelabs.com id
	28/E0-30830-C78F83F4; Mon, 13 Feb 2012 11:48:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329133691!7494025!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30268 invoked from network); 13 Feb 2012 11:48:12 -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;
	13 Feb 2012 11:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:48:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:48:11 +0000
Date: Mon, 13 Feb 2012 11:52:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paul Brook <paul@codesourcery.com>
In-Reply-To: <201202102334.40125.paul@codesourcery.com>
Message-ID: <alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<4F350047.4030507@siemens.com>
	<alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
	<201202102334.40125.paul@codesourcery.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Paul Brook wrote:
> > +#ifdef CONFIG_SLIRP
> > +static inline void slirp_update_timeout(uint32_t *timeout)
> > +{
> > +    *timeout = MIN(1000, *timeout);
> > +}
> > +#else
> > +static inline void slirp_update_timeout(uint32_t *timeout) { }
> > +#endif
> 
> Shouldn't we be testing whether slirp is actually in use? I doubt many people 
> go to the effort of rebuilding without SLIRP support.
 
Yes, you are right. Also considering that we are only calling
slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
the !CONFIG_SLIRP dummy version of the function.

---

commit 3a89477edc7e551c93b016940d2fdad9ebc22a84
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Feb 13 11:25:03 2012 +0000

    main_loop_wait: block indefinitely
    
    - remove qemu_calculate_timeout;
    
    - explicitly size timeout to uint32_t;
    
    - introduce slirp_update_timeout;
    
    - pass NULL as timeout argument to select in case timeout is the maximum
    value;
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index 692381c..4a105e9 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -366,7 +366,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
     }
 }
 
-static void os_host_main_loop_wait(int *timeout)
+static void os_host_main_loop_wait(uint32_t *timeout)
 {
     int ret, ret2, i;
     PollingEntry *pe;
@@ -410,7 +410,7 @@ static void os_host_main_loop_wait(int *timeout)
     *timeout = 0;
 }
 #else
-static inline void os_host_main_loop_wait(int *timeout)
+static inline void os_host_main_loop_wait(uint32_t *timeout)
 {
 }
 #endif
@@ -419,21 +419,17 @@ int main_loop_wait(int nonblocking)
 {
     fd_set rfds, wfds, xfds;
     int ret, nfds;
-    struct timeval tv;
-    int timeout;
+    struct timeval tv, *tvarg = NULL;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
     os_host_main_loop_wait(&timeout);
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
@@ -442,16 +438,23 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
diff --git a/main-loop.h b/main-loop.h
index f971013..22c0dc9 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -352,6 +352,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..3e1ce08 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index de17f3b..f1386d5 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -62,7 +62,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/qemu-tool.c b/qemu-tool.c
index 6b69668..76830b7 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -90,6 +90,10 @@ static void __attribute__((constructor)) init_main_loop(void)
     qemu_clock_enable(vm_clock, false);
 }
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+}
+
 void slirp_select_fill(int *pnfds, fd_set *readfds,
                        fd_set *writefds, fd_set *xfds)
 {
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..77527ad 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -15,6 +15,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
                   struct in_addr vnameserver, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
+void slirp_update_timeout(uint32_t *timeout);
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds);
 
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 19d69eb..418f8d0 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -255,6 +255,13 @@ void slirp_cleanup(Slirp *slirp)
 #define CONN_CANFRCV(so) (((so)->so_state & (SS_FCANTRCVMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
 #define UPD_NFDS(x) if (nfds < (x)) nfds = (x)
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+    if (!QTAILQ_EMPTY(&slirp_instances)) {
+        *timeout = MIN(1000, *timeout);
+    }
+}
+
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:48:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1RwuOG-0005nj-6X; Mon, 13 Feb 2012 11:48:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwuOD-0005nX-L2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:48:14 +0000
Received: from [85.158.139.83:31894] by server-12.bemta-5.messagelabs.com id
	28/E0-30830-C78F83F4; Mon, 13 Feb 2012 11:48:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329133691!7494025!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30268 invoked from network); 13 Feb 2012 11:48:12 -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;
	13 Feb 2012 11:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:48:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:48:11 +0000
Date: Mon, 13 Feb 2012 11:52:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paul Brook <paul@codesourcery.com>
In-Reply-To: <201202102334.40125.paul@codesourcery.com>
Message-ID: <alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<4F350047.4030507@siemens.com>
	<alpine.DEB.2.00.1202101644250.7456@kaball-desktop>
	<201202102334.40125.paul@codesourcery.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Paul Brook wrote:
> > +#ifdef CONFIG_SLIRP
> > +static inline void slirp_update_timeout(uint32_t *timeout)
> > +{
> > +    *timeout = MIN(1000, *timeout);
> > +}
> > +#else
> > +static inline void slirp_update_timeout(uint32_t *timeout) { }
> > +#endif
> 
> Shouldn't we be testing whether slirp is actually in use? I doubt many people 
> go to the effort of rebuilding without SLIRP support.
 
Yes, you are right. Also considering that we are only calling
slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
the !CONFIG_SLIRP dummy version of the function.

---

commit 3a89477edc7e551c93b016940d2fdad9ebc22a84
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Feb 13 11:25:03 2012 +0000

    main_loop_wait: block indefinitely
    
    - remove qemu_calculate_timeout;
    
    - explicitly size timeout to uint32_t;
    
    - introduce slirp_update_timeout;
    
    - pass NULL as timeout argument to select in case timeout is the maximum
    value;
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index 692381c..4a105e9 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -366,7 +366,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
     }
 }
 
-static void os_host_main_loop_wait(int *timeout)
+static void os_host_main_loop_wait(uint32_t *timeout)
 {
     int ret, ret2, i;
     PollingEntry *pe;
@@ -410,7 +410,7 @@ static void os_host_main_loop_wait(int *timeout)
     *timeout = 0;
 }
 #else
-static inline void os_host_main_loop_wait(int *timeout)
+static inline void os_host_main_loop_wait(uint32_t *timeout)
 {
 }
 #endif
@@ -419,21 +419,17 @@ int main_loop_wait(int nonblocking)
 {
     fd_set rfds, wfds, xfds;
     int ret, nfds;
-    struct timeval tv;
-    int timeout;
+    struct timeval tv, *tvarg = NULL;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
     os_host_main_loop_wait(&timeout);
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
@@ -442,16 +438,23 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
diff --git a/main-loop.h b/main-loop.h
index f971013..22c0dc9 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -352,6 +352,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..3e1ce08 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index de17f3b..f1386d5 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -62,7 +62,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/qemu-tool.c b/qemu-tool.c
index 6b69668..76830b7 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -90,6 +90,10 @@ static void __attribute__((constructor)) init_main_loop(void)
     qemu_clock_enable(vm_clock, false);
 }
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+}
+
 void slirp_select_fill(int *pnfds, fd_set *readfds,
                        fd_set *writefds, fd_set *xfds)
 {
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..77527ad 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -15,6 +15,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
                   struct in_addr vnameserver, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
+void slirp_update_timeout(uint32_t *timeout);
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds);
 
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 19d69eb..418f8d0 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -255,6 +255,13 @@ void slirp_cleanup(Slirp *slirp)
 #define CONN_CANFRCV(so) (((so)->so_state & (SS_FCANTRCVMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
 #define UPD_NFDS(x) if (nfds < (x)) nfds = (x)
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+    if (!QTAILQ_EMPTY(&slirp_instances)) {
+        *timeout = MIN(1000, *timeout);
+    }
+}
+
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuR3-0005wa-Bz; Mon, 13 Feb 2012 11:51:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuR2-0005wP-Cn
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:51:08 +0000
Received: from [85.158.139.83:59420] by server-10.bemta-5.messagelabs.com id
	6F/F0-26909-B29F83F4; Mon, 13 Feb 2012 11:51:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329133866!14756876!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22505 invoked from network); 13 Feb 2012 11:51:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:51:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:51:06 +0000
Message-ID: <1329133865.31256.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:51:05 +0000
In-Reply-To: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 1/5] hvmloader: Only compile
 32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> 32bitbios_support.c only contains code specific to rombios, and should
> not be built-in when building hvmloader for SeaBIOS only (as for
> rombios.c).
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I acked this patch last time too -- please collate Acks in repostings
where no substantial change has been made to a patch so reviewers can
save the effort.

Ian.

> ---
>  tools/firmware/hvmloader/Makefile |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index 41a4369..e82146a 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -29,7 +29,7 @@ LOADADDR = 0x100000
>  CFLAGS += $(CFLAGS_xeninclude)
>  
>  OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
> -OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
> +OBJS += smp.o cacheattr.o xenbus.o
>  OBJS += e820.o pci.o pir.o ctype.o
>  ifeq ($(debug),y)
>  OBJS += tests.o
> @@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
>  
>  ROMBIOS_DIR := ../rombios
>  ifneq ($(ROMBIOS_DIR),)
> -OBJS += rombios.o
> +OBJS += 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuR3-0005wa-Bz; Mon, 13 Feb 2012 11:51:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuR2-0005wP-Cn
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:51:08 +0000
Received: from [85.158.139.83:59420] by server-10.bemta-5.messagelabs.com id
	6F/F0-26909-B29F83F4; Mon, 13 Feb 2012 11:51:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329133866!14756876!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22505 invoked from network); 13 Feb 2012 11:51:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:51:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:51:06 +0000
Message-ID: <1329133865.31256.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:51:05 +0000
In-Reply-To: <e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<e32c657bb173b59a4dd7e7e037d3e3c05b4c0fde.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 1/5] hvmloader: Only compile
 32bitbios_support.c when rombios is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> 32bitbios_support.c only contains code specific to rombios, and should
> not be built-in when building hvmloader for SeaBIOS only (as for
> rombios.c).
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I acked this patch last time too -- please collate Acks in repostings
where no substantial change has been made to a patch so reviewers can
save the effort.

Ian.

> ---
>  tools/firmware/hvmloader/Makefile |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index 41a4369..e82146a 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -29,7 +29,7 @@ LOADADDR = 0x100000
>  CFLAGS += $(CFLAGS_xeninclude)
>  
>  OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
> -OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
> +OBJS += smp.o cacheattr.o xenbus.o
>  OBJS += e820.o pci.o pir.o ctype.o
>  ifeq ($(debug),y)
>  OBJS += tests.o
> @@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
>  
>  ROMBIOS_DIR := ../rombios
>  ifneq ($(ROMBIOS_DIR),)
> -OBJS += rombios.o
> +OBJS += 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuQx-0005w8-VP; Mon, 13 Feb 2012 11:51:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RwuQw-0005vu-Dr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:51:02 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329133854!11281188!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28520 invoked from network); 13 Feb 2012 11:50:56 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:50:56 -0000
Received: by obcuy19 with SMTP id uy19so25396701obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:50:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=0KHW4fvyxIsmWzYFi3rXd3H931SgNWU+NElIHS2qFfQ=;
	b=SZc210sxqT/W03ruEfVG3dDCK5d8g/ytjAiaowHrR6f4APVzCLD32ZqM4qfH/Jv4lS
	y7HB+40/xFwkx+/YOzit/50Twzz1XULQe/ytFYwRfyn3aLByq8IgtnDYeu9HDemAC/Cm
	avbY5yokPgIrRDkz+6zW5camBjZ+cBgtimyOw=
Received: by 10.60.26.166 with SMTP id m6mr4003114oeg.45.1329133854253; Mon,
	13 Feb 2012 03:50:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 13 Feb 2012 03:50:24 -0800 (PST)
In-Reply-To: <1329131119975-5478798.post@n5.nabble.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 13 Feb 2012 11:50:24 +0000
X-Google-Sender-Auth: NpZunOHJG1A4BEHNMQzR1NjoZ0k
Message-ID: <CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
To: Fantu <fantonifabio@tiscali.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCBGZWIgMTMsIDIwMTIgYXQgMTE6MDUsIEZhbnR1IDxmYW50b25pZmFiaW9AdGlzY2Fs
aS5pdD4gd3JvdGU6Cj4gwqAgwqAgwqAgwqAgKiBTcGljZSBmdWxsIHN1cHBvcnQgYW5kIGJ1aWxk
IGVuYWJsZWQgYnkgZGVmYXVsdAo+Cj4gQWJvdXQgU3BpY2Ugc3VwcG9ydCBvbiBxZW11IHVwc3Ry
ZWFtLCBub3cgaXMgbm90IGJ1aWx0IGJ5IGRlZmF1bHQgYW5kIG9uIHhsCj4gY29uZmlndXJhdGlv
biBmaWxlcyBpcyBtaW5pbWFsLiBQcm9iYWJseSB0aGVyZSBhcmUgYWxzbyBzb21lIHJlcXVpcmVk
IG1pc3NlZAo+IG9wdGlvbnMgYWJvdXQgcXhsIGdyYXBoaWMgbmVlZGVkIGJ5IFNwaWNlIG9uIHhs
IGNvbmZpZ3VyYXRpb24gZmlsZXMuCj4gSSBzZWFyY2ggb24gdG9vbHMvbGlieGwvbGlieGxfZG0u
YyBidXQgSSBoYXZlIGZvdW5kIG5vdGhpbmcgYWJvdXQgcXhsIG5vdy4KCkFib3V0IHRoZSBidWls
ZCwgUUVNVSBzaG91bGQgaW5jbHVkZSBzcGljZSBzdXBwb3J0IGlmIHRoZSBuZWNlc3NhcnkKbGli
cmFyeSBhcmUgaW5zdGFsbGVkLiBCdXQgb24gRGViaWFuIHN0YWJsZSAoU3F1ZWV6ZSksIHRoZSBz
cGljZQpsaWJyYXJ5IGFyZSB0b28gb2xkLCBzbyBmb3JjaW5nIFFFTVUgdG8gaGF2ZSBzcGljZSBz
dXBwb3J0IHdpbGwganVzdApicmVhayB0aGUgYnVpbGQuCgpSZWdhcmRzLAoKLS0gCkFudGhvbnkg
UEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuQx-0005w8-VP; Mon, 13 Feb 2012 11:51:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RwuQw-0005vu-Dr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:51:02 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329133854!11281188!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28520 invoked from network); 13 Feb 2012 11:50:56 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:50:56 -0000
Received: by obcuy19 with SMTP id uy19so25396701obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:50:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=0KHW4fvyxIsmWzYFi3rXd3H931SgNWU+NElIHS2qFfQ=;
	b=SZc210sxqT/W03ruEfVG3dDCK5d8g/ytjAiaowHrR6f4APVzCLD32ZqM4qfH/Jv4lS
	y7HB+40/xFwkx+/YOzit/50Twzz1XULQe/ytFYwRfyn3aLByq8IgtnDYeu9HDemAC/Cm
	avbY5yokPgIrRDkz+6zW5camBjZ+cBgtimyOw=
Received: by 10.60.26.166 with SMTP id m6mr4003114oeg.45.1329133854253; Mon,
	13 Feb 2012 03:50:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 13 Feb 2012 03:50:24 -0800 (PST)
In-Reply-To: <1329131119975-5478798.post@n5.nabble.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 13 Feb 2012 11:50:24 +0000
X-Google-Sender-Auth: NpZunOHJG1A4BEHNMQzR1NjoZ0k
Message-ID: <CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
To: Fantu <fantonifabio@tiscali.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCBGZWIgMTMsIDIwMTIgYXQgMTE6MDUsIEZhbnR1IDxmYW50b25pZmFiaW9AdGlzY2Fs
aS5pdD4gd3JvdGU6Cj4gwqAgwqAgwqAgwqAgKiBTcGljZSBmdWxsIHN1cHBvcnQgYW5kIGJ1aWxk
IGVuYWJsZWQgYnkgZGVmYXVsdAo+Cj4gQWJvdXQgU3BpY2Ugc3VwcG9ydCBvbiBxZW11IHVwc3Ry
ZWFtLCBub3cgaXMgbm90IGJ1aWx0IGJ5IGRlZmF1bHQgYW5kIG9uIHhsCj4gY29uZmlndXJhdGlv
biBmaWxlcyBpcyBtaW5pbWFsLiBQcm9iYWJseSB0aGVyZSBhcmUgYWxzbyBzb21lIHJlcXVpcmVk
IG1pc3NlZAo+IG9wdGlvbnMgYWJvdXQgcXhsIGdyYXBoaWMgbmVlZGVkIGJ5IFNwaWNlIG9uIHhs
IGNvbmZpZ3VyYXRpb24gZmlsZXMuCj4gSSBzZWFyY2ggb24gdG9vbHMvbGlieGwvbGlieGxfZG0u
YyBidXQgSSBoYXZlIGZvdW5kIG5vdGhpbmcgYWJvdXQgcXhsIG5vdy4KCkFib3V0IHRoZSBidWls
ZCwgUUVNVSBzaG91bGQgaW5jbHVkZSBzcGljZSBzdXBwb3J0IGlmIHRoZSBuZWNlc3NhcnkKbGli
cmFyeSBhcmUgaW5zdGFsbGVkLiBCdXQgb24gRGViaWFuIHN0YWJsZSAoU3F1ZWV6ZSksIHRoZSBz
cGljZQpsaWJyYXJ5IGFyZSB0b28gb2xkLCBzbyBmb3JjaW5nIFFFTVUgdG8gaGF2ZSBzcGljZSBz
dXBwb3J0IHdpbGwganVzdApicmVhayB0aGUgYnVpbGQuCgpSZWdhcmRzLAoKLS0gCkFudGhvbnkg
UEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:51:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuRS-000608-QZ; Mon, 13 Feb 2012 11:51:34 +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 1RwuRR-0005zE-57
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:51:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329133836!54000462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8434 invoked from network); 13 Feb 2012 11:50:36 -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 Feb 2012 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:51:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:51:27 +0000
Message-ID: <1329133885.31256.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:51:25 +0000
In-Reply-To: <82d0187e1ef4edffc22f75131b03ca30492a388c.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<82d0187e1ef4edffc22f75131b03ca30492a388c.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 2/5] hvmloader: Allow the mkhex command
 to take several file arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/firmware/hvmloader/mkhex |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/mkhex b/tools/firmware/hvmloader/mkhex
> index 4517e36..cb21257 100755
> --- a/tools/firmware/hvmloader/mkhex
> +++ b/tools/firmware/hvmloader/mkhex
> @@ -21,6 +21,7 @@
>  #
>  
>  echo "unsigned $1[] = {"
> -od -v -t x $2 | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
> +shift
> +od -v -t x $@ | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
>  echo "};"
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:51:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuRS-000608-QZ; Mon, 13 Feb 2012 11:51:34 +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 1RwuRR-0005zE-57
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:51:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329133836!54000462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8434 invoked from network); 13 Feb 2012 11:50:36 -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 Feb 2012 11:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:51:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:51:27 +0000
Message-ID: <1329133885.31256.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:51:25 +0000
In-Reply-To: <82d0187e1ef4edffc22f75131b03ca30492a388c.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<82d0187e1ef4edffc22f75131b03ca30492a388c.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 2/5] hvmloader: Allow the mkhex command
 to take several file arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/firmware/hvmloader/mkhex |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/mkhex b/tools/firmware/hvmloader/mkhex
> index 4517e36..cb21257 100755
> --- a/tools/firmware/hvmloader/mkhex
> +++ b/tools/firmware/hvmloader/mkhex
> @@ -21,6 +21,7 @@
>  #
>  
>  echo "unsigned $1[] = {"
> -od -v -t x $2 | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
> +shift
> +od -v -t x $@ | sed 's/^[0-9]*  */0x/' | sed 's/  */, 0x/g' | sed 's/$/,/' | sed 's/0x,//' | sed 's/^[0-9]*,//'
>  echo "};"
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:52:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuS2-00066v-D2; Mon, 13 Feb 2012 11:52: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 1RwuS1-00066C-K0
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:52:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329133902!65589391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5525 invoked from network); 13 Feb 2012 11:51:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:51:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:52:05 +0000
Message-ID: <1329133923.31256.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:52:03 +0000
In-Reply-To: <68dc4b371841c649d1dcff9cca84295e9a24dc65.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<68dc4b371841c649d1dcff9cca84295e9a24dc65.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] firmware: Use mkhex from hvmloader
 directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> To remain consistent with how other ROMs are built into hvmloader,
> call mkhex on etherboot ROMs from the hvmloader directory, instead of
> the etherboot directory. In other words, eb-roms.h is not used any more.
> 
> Introduce ETHERBOOT_NICS config option to choose which ROMs should be
> built (kept rtl8139 and 8086100e per default as before).
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Config.mk                         |    2 ++
>  tools/firmware/etherboot/Config   |    2 --
>  tools/firmware/etherboot/Makefile |   13 +++----------
>  tools/firmware/hvmloader/Makefile |    9 ++++++---
>  4 files changed, 11 insertions(+), 15 deletions(-)
> 
> diff --git a/Config.mk b/Config.mk
> index e2dc4b9..42508b8 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -222,6 +222,8 @@ endif
>  QEMU_UPSTREAM_REVISION ?= master
>  SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
>  
> +ETHERBOOT_NICS ?= rtl8139 8086100e
> +
>  # Specify which qemu-dm to use. This may be `ioemu' to use the old
>  # Mercurial in-tree version, or a local directory, or a git URL.
>  # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
> diff --git a/tools/firmware/etherboot/Config b/tools/firmware/etherboot/Config
> index 143914f..69963b9 100644
> --- a/tools/firmware/etherboot/Config
> +++ b/tools/firmware/etherboot/Config
> @@ -1,6 +1,4 @@
>  
> -NICS = rtl8139 8086100e
> -
>  CFLAGS += -UPXE_DHCP_STRICT
>  CFLAGS += -DPXE_DHCP_STRICT
>  
> diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
> index c09140e..a195888 100644
> --- a/tools/firmware/etherboot/Makefile
> +++ b/tools/firmware/etherboot/Makefile
> @@ -17,23 +17,16 @@ IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
>  D=ipxe
>  T=ipxe.tar.gz
>  
> -ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(NICS)))
> +ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
>  
>  .NOTPARALLEL:
>  
>  .PHONY: all
> -all: eb-roms.h
> +all: $(ROMS)
>  
>  %.rom: $D/src/arch/i386/Makefile
>  	$(MAKE) -C $D/src bin/$(*F).rom
>  
> -eb-roms.h.new: $(ROMS)
> -	cat $^ | ../hvmloader/mkhex etherboot >$@
> -
> -eb-roms.h: Config
> -	$(MAKE) NO_WERROR=1 $@.new
> -	mv -f $@.new $@
> -
>  $T:
>  	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
>  		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
> @@ -56,7 +49,7 @@ $D/src/bin/NIC: $D/src/arch/i386/Makefile
>  
>  .PHONY: clean
>  clean:
> -	rm -rf $D $D.git *~ eb-roms.h _$T $T
> +	rm -rf $D $D.git *~ _$T $T
>  
>  .PHONY: distclean
>  distclean: clean
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index e82146a..1ea32db 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -58,6 +58,8 @@ else
>  CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
>  endif
>  
> +ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
> +
>  .PHONY: all
>  all: subdirs-all
>  	$(MAKE) hvmloader
> @@ -70,7 +72,7 @@ hvmloader: $(OBJS) acpi/acpi.a
>  	$(OBJCOPY) hvmloader.tmp hvmloader
>  	rm -f hvmloader.tmp
>  
> -roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
> +roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
>  	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
>  
>  ifneq ($(ROMBIOS_ROM),)
> @@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
>  	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
>  	echo "#endif" >> $@.new
>  endif
> -
> +ifneq ($(ETHERBOOT_ROMS),)
>  	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
> -	cat ../etherboot/eb-roms.h >> $@.new
> +	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
>  	echo "#endif" >> $@.new
> +endif
>  
>  	mv $@.new $@
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:52:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuS2-00066v-D2; Mon, 13 Feb 2012 11:52: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 1RwuS1-00066C-K0
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:52:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329133902!65589391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5525 invoked from network); 13 Feb 2012 11:51:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:51:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:52:05 +0000
Message-ID: <1329133923.31256.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:52:03 +0000
In-Reply-To: <68dc4b371841c649d1dcff9cca84295e9a24dc65.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<68dc4b371841c649d1dcff9cca84295e9a24dc65.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 3/5] firmware: Use mkhex from hvmloader
 directory for etherboot ROMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> To remain consistent with how other ROMs are built into hvmloader,
> call mkhex on etherboot ROMs from the hvmloader directory, instead of
> the etherboot directory. In other words, eb-roms.h is not used any more.
> 
> Introduce ETHERBOOT_NICS config option to choose which ROMs should be
> built (kept rtl8139 and 8086100e per default as before).
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  Config.mk                         |    2 ++
>  tools/firmware/etherboot/Config   |    2 --
>  tools/firmware/etherboot/Makefile |   13 +++----------
>  tools/firmware/hvmloader/Makefile |    9 ++++++---
>  4 files changed, 11 insertions(+), 15 deletions(-)
> 
> diff --git a/Config.mk b/Config.mk
> index e2dc4b9..42508b8 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -222,6 +222,8 @@ endif
>  QEMU_UPSTREAM_REVISION ?= master
>  SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
>  
> +ETHERBOOT_NICS ?= rtl8139 8086100e
> +
>  # Specify which qemu-dm to use. This may be `ioemu' to use the old
>  # Mercurial in-tree version, or a local directory, or a git URL.
>  # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
> diff --git a/tools/firmware/etherboot/Config b/tools/firmware/etherboot/Config
> index 143914f..69963b9 100644
> --- a/tools/firmware/etherboot/Config
> +++ b/tools/firmware/etherboot/Config
> @@ -1,6 +1,4 @@
>  
> -NICS = rtl8139 8086100e
> -
>  CFLAGS += -UPXE_DHCP_STRICT
>  CFLAGS += -DPXE_DHCP_STRICT
>  
> diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
> index c09140e..a195888 100644
> --- a/tools/firmware/etherboot/Makefile
> +++ b/tools/firmware/etherboot/Makefile
> @@ -17,23 +17,16 @@ IPXE_TARBALL_URL := $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
>  D=ipxe
>  T=ipxe.tar.gz
>  
> -ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(NICS)))
> +ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
>  
>  .NOTPARALLEL:
>  
>  .PHONY: all
> -all: eb-roms.h
> +all: $(ROMS)
>  
>  %.rom: $D/src/arch/i386/Makefile
>  	$(MAKE) -C $D/src bin/$(*F).rom
>  
> -eb-roms.h.new: $(ROMS)
> -	cat $^ | ../hvmloader/mkhex etherboot >$@
> -
> -eb-roms.h: Config
> -	$(MAKE) NO_WERROR=1 $@.new
> -	mv -f $@.new $@
> -
>  $T:
>  	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
>  		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
> @@ -56,7 +49,7 @@ $D/src/bin/NIC: $D/src/arch/i386/Makefile
>  
>  .PHONY: clean
>  clean:
> -	rm -rf $D $D.git *~ eb-roms.h _$T $T
> +	rm -rf $D $D.git *~ _$T $T
>  
>  .PHONY: distclean
>  distclean: clean
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index e82146a..1ea32db 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -58,6 +58,8 @@ else
>  CIRRUSVGA_ROM := ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
>  endif
>  
> +ETHERBOOT_ROMS := $(addprefix ../etherboot/ipxe/src/bin/, $(addsuffix .rom, $(ETHERBOOT_NICS)))
> +
>  .PHONY: all
>  all: subdirs-all
>  	$(MAKE) hvmloader
> @@ -70,7 +72,7 @@ hvmloader: $(OBJS) acpi/acpi.a
>  	$(OBJCOPY) hvmloader.tmp hvmloader
>  	rm -f hvmloader.tmp
>  
> -roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) ../etherboot/eb-roms.h
> +roms.inc: $(ROMBIOS_ROM) $(SEABIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
>  	echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
>  
>  ifneq ($(ROMBIOS_ROM),)
> @@ -95,10 +97,11 @@ ifneq ($(CIRRUSVGA_ROM),)
>  	sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
>  	echo "#endif" >> $@.new
>  endif
> -
> +ifneq ($(ETHERBOOT_ROMS),)
>  	echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
> -	cat ../etherboot/eb-roms.h >> $@.new
> +	sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
>  	echo "#endif" >> $@.new
> +endif
>  
>  	mv $@.new $@
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:53:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuSx-0006GI-5v; Mon, 13 Feb 2012 11:53: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 1RwuSs-0006Fi-L9
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:53:03 +0000
Received: from [85.158.139.83:13169] by server-5.bemta-5.messagelabs.com id
	9E/92-03847-D99F83F4; Mon, 13 Feb 2012 11:53:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329133981!12123319!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_FUTURE_06_12,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20890 invoked from network); 13 Feb 2012 11:53:01 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:53:01 -0000
Received: by werb14 with SMTP id b14so14711280wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YgVwlN0uh3CxIqg520+8KI9fn3biYjwoDG4KOiHRTQo=;
	b=RyDfVjbC6hGBmUde745/W+iBN4UorYjJ72Aq5eEswDFMBF8Yq/M2TLilRwzZwcchBx
	5AxaEYirHapADn+RbMdHIkiAlF2WoEGIKOO7RjYHUrah0OzE2XY4dDPWxRpbnhxSnblh
	2l+zdLBY7xfviHpdficXCzUQgMEZ7Yw0KY6OY=
Received: by 10.180.14.193 with SMTP id r1mr17693103wic.9.1329133980976;
	Mon, 13 Feb 2012 03:53:00 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id da8sm21071609wib.6.2012.02.13.03.52.58
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 03:53:00 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 11:52:57 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB5EAA19.2B18C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/vMCE: MC{G,i}_CTL handling adjustments
Thread-Index: AczqRgbSN3kBVz0Wo0W4lW3KjfSK/w==
In-Reply-To: <4F3901130200007800072824@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/vMCE: MC{G,i}_CTL handling adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/2012 03:24, "Jan Beulich" <JBeulich@suse.com> wrote:

> - g_mcg_cap was read to determine whether MCG_CTL exists before it got
>   initialized
> - h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via
>   memset() with an inappropriate size (hence causing a [minor?]
>   information leak)
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -29,7 +29,7 @@ invbool_param("mce", mce_disabled);
>  bool_t __read_mostly mce_broadcast = 0;
>  bool_t is_mc_panic;
>  unsigned int __read_mostly nr_mce_banks;
> -int __read_mostly firstbank;
> +unsigned int __read_mostly firstbank;
>  
>  static void intpose_init(void);
>  static void mcinfo_clear(struct mc_info *);
> @@ -650,7 +650,7 @@ int mce_available(struct cpuinfo_x86 *c)
>   * Check if bank 0 is usable for MCE. It isn't for AMD K7,
>   * and Intel P6 family before model 0x1a.
>   */
> -int mce_firstbank(struct cpuinfo_x86 *c)
> +unsigned int mce_firstbank(struct cpuinfo_x86 *c)
>  {
>      if (c->x86 == 6) {
>          if (c->x86_vendor == X86_VENDOR_AMD)
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -52,7 +52,7 @@ int is_vmce_ready(struct mcinfo_bank *ba
>  int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
>  
>  u64 mce_cap_init(void);
> -extern int firstbank;
> +extern unsigned int firstbank;
>  
>  int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
>  int intel_mce_wrmsr(uint32_t msr, uint64_t val);
> @@ -61,7 +61,7 @@ struct mcinfo_extended *intel_get_extend
>      struct mcinfo_global *mig, struct mc_info *mi);
>  
>  int mce_available(struct cpuinfo_x86 *c);
> -int mce_firstbank(struct cpuinfo_x86 *c);
> +unsigned int mce_firstbank(struct cpuinfo_x86 *c);
>  /* Helper functions used for collecting error telemetry */
>  struct mc_info *x86_mcinfo_getptr(void);
>  void mc_panic(char *s);
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -39,7 +39,7 @@ int vmce_init_msr(struct domain *d)
>          return -ENOMEM;
>      }
>      memset(dom_vmce(d)->mci_ctl, ~0,
> -           sizeof(dom_vmce(d)->mci_ctl));
> +           nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
>  
>      dom_vmce(d)->mcg_status = 0x0;
>      dom_vmce(d)->mcg_cap = g_mcg_cap;
> @@ -438,7 +438,7 @@ int vmce_domain_inject(
>  int vmce_init(struct cpuinfo_x86 *c)
>  {
>      u64 value;
> -    int i;
> +    unsigned int i;
>  
>      if ( !h_mci_ctrl )
>      {
> @@ -449,17 +449,17 @@ int vmce_init(struct cpuinfo_x86 *c)
>              return -ENOMEM;
>          }
>          /* Don't care banks before firstbank */
> -        memset(h_mci_ctrl, 0xff, sizeof(h_mci_ctrl));
> +        memset(h_mci_ctrl, ~0,
> +               min(firstbank, nr_mce_banks) * sizeof(*h_mci_ctrl));
>          for (i = firstbank; i < nr_mce_banks; i++)
>              rdmsrl(MSR_IA32_MCx_CTL(i), h_mci_ctrl[i]);
>      }
>  
> -    if (g_mcg_cap & MCG_CTL_P)
> -        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
> -
>      rdmsrl(MSR_IA32_MCG_CAP, value);
>      /* For Guest vMCE usage */
>      g_mcg_cap = value & ~MCG_CMCI_P;
> +    if (value & MCG_CTL_P)
> +        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
>  
>      return 0;
>  }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:53:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuSx-0006GI-5v; Mon, 13 Feb 2012 11:53: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 1RwuSs-0006Fi-L9
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:53:03 +0000
Received: from [85.158.139.83:13169] by server-5.bemta-5.messagelabs.com id
	9E/92-03847-D99F83F4; Mon, 13 Feb 2012 11:53:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329133981!12123319!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_FUTURE_06_12,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20890 invoked from network); 13 Feb 2012 11:53:01 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:53:01 -0000
Received: by werb14 with SMTP id b14so14711280wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 03:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YgVwlN0uh3CxIqg520+8KI9fn3biYjwoDG4KOiHRTQo=;
	b=RyDfVjbC6hGBmUde745/W+iBN4UorYjJ72Aq5eEswDFMBF8Yq/M2TLilRwzZwcchBx
	5AxaEYirHapADn+RbMdHIkiAlF2WoEGIKOO7RjYHUrah0OzE2XY4dDPWxRpbnhxSnblh
	2l+zdLBY7xfviHpdficXCzUQgMEZ7Yw0KY6OY=
Received: by 10.180.14.193 with SMTP id r1mr17693103wic.9.1329133980976;
	Mon, 13 Feb 2012 03:53:00 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id da8sm21071609wib.6.2012.02.13.03.52.58
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 03:53:00 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 11:52:57 -0800
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB5EAA19.2B18C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/vMCE: MC{G,i}_CTL handling adjustments
Thread-Index: AczqRgbSN3kBVz0Wo0W4lW3KjfSK/w==
In-Reply-To: <4F3901130200007800072824@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/vMCE: MC{G,i}_CTL handling adjustments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/2012 03:24, "Jan Beulich" <JBeulich@suse.com> wrote:

> - g_mcg_cap was read to determine whether MCG_CTL exists before it got
>   initialized
> - h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via
>   memset() with an inappropriate size (hence causing a [minor?]
>   information leak)
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -29,7 +29,7 @@ invbool_param("mce", mce_disabled);
>  bool_t __read_mostly mce_broadcast = 0;
>  bool_t is_mc_panic;
>  unsigned int __read_mostly nr_mce_banks;
> -int __read_mostly firstbank;
> +unsigned int __read_mostly firstbank;
>  
>  static void intpose_init(void);
>  static void mcinfo_clear(struct mc_info *);
> @@ -650,7 +650,7 @@ int mce_available(struct cpuinfo_x86 *c)
>   * Check if bank 0 is usable for MCE. It isn't for AMD K7,
>   * and Intel P6 family before model 0x1a.
>   */
> -int mce_firstbank(struct cpuinfo_x86 *c)
> +unsigned int mce_firstbank(struct cpuinfo_x86 *c)
>  {
>      if (c->x86 == 6) {
>          if (c->x86_vendor == X86_VENDOR_AMD)
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -52,7 +52,7 @@ int is_vmce_ready(struct mcinfo_bank *ba
>  int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
>  
>  u64 mce_cap_init(void);
> -extern int firstbank;
> +extern unsigned int firstbank;
>  
>  int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
>  int intel_mce_wrmsr(uint32_t msr, uint64_t val);
> @@ -61,7 +61,7 @@ struct mcinfo_extended *intel_get_extend
>      struct mcinfo_global *mig, struct mc_info *mi);
>  
>  int mce_available(struct cpuinfo_x86 *c);
> -int mce_firstbank(struct cpuinfo_x86 *c);
> +unsigned int mce_firstbank(struct cpuinfo_x86 *c);
>  /* Helper functions used for collecting error telemetry */
>  struct mc_info *x86_mcinfo_getptr(void);
>  void mc_panic(char *s);
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -39,7 +39,7 @@ int vmce_init_msr(struct domain *d)
>          return -ENOMEM;
>      }
>      memset(dom_vmce(d)->mci_ctl, ~0,
> -           sizeof(dom_vmce(d)->mci_ctl));
> +           nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
>  
>      dom_vmce(d)->mcg_status = 0x0;
>      dom_vmce(d)->mcg_cap = g_mcg_cap;
> @@ -438,7 +438,7 @@ int vmce_domain_inject(
>  int vmce_init(struct cpuinfo_x86 *c)
>  {
>      u64 value;
> -    int i;
> +    unsigned int i;
>  
>      if ( !h_mci_ctrl )
>      {
> @@ -449,17 +449,17 @@ int vmce_init(struct cpuinfo_x86 *c)
>              return -ENOMEM;
>          }
>          /* Don't care banks before firstbank */
> -        memset(h_mci_ctrl, 0xff, sizeof(h_mci_ctrl));
> +        memset(h_mci_ctrl, ~0,
> +               min(firstbank, nr_mce_banks) * sizeof(*h_mci_ctrl));
>          for (i = firstbank; i < nr_mce_banks; i++)
>              rdmsrl(MSR_IA32_MCx_CTL(i), h_mci_ctrl[i]);
>      }
>  
> -    if (g_mcg_cap & MCG_CTL_P)
> -        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
> -
>      rdmsrl(MSR_IA32_MCG_CAP, value);
>      /* For Guest vMCE usage */
>      g_mcg_cap = value & ~MCG_CMCI_P;
> +    if (value & MCG_CTL_P)
> +        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
>  
>      return 0;
>  }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:53:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuTK-0006LT-8H; Mon, 13 Feb 2012 11:53:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuTI-0006KZ-9u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:53:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329134002!14326143!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31353 invoked from network); 13 Feb 2012 11:53:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:53:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:53:22 +0000
Message-ID: <1329134000.31256.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:53:20 +0000
In-Reply-To: <bcc9b695f6ae5a4d915116f154d2b5e23fbf5865.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<bcc9b695f6ae5a4d915116f154d2b5e23fbf5865.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 4/5] hvmloader: Move option ROM loading
 into a separate optionnal file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> Make load_rom field in struct bios_config an optionnal callback rather
> than a boolean value. It allow BIOS specific code to implement it's own
> option ROM loading methods.
> 
> Facilities to scan PCI devices, extract an deploy ROMs are moved into
> a separate file that can be compiled optionnaly.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Presuming this to be mostly code motion I didn't review in depth but:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/firmware/hvmloader/Makefile     |    2 +-
>  tools/firmware/hvmloader/config.h     |    3 +-
>  tools/firmware/hvmloader/hvmloader.c  |  218 +--------------------------------
>  tools/firmware/hvmloader/option_rom.h |    7 +
>  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
>  tools/firmware/hvmloader/seabios.c    |    5 +-
>  7 files changed, 259 insertions(+), 228 deletions(-)
>  create mode 100644 tools/firmware/hvmloader/optionroms.c
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index 1ea32db..5a5ee41 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
> 
>  ROMBIOS_DIR := ../rombios
>  ifneq ($(ROMBIOS_DIR),)
> -OBJS += 32bitbios_support.o rombios.o
> +OBJS += optionroms.o 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif
> diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
> index 9cac9c1..1f80263 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -18,8 +18,7 @@ struct bios_config {
>      unsigned int bios_address;
> 
>      /* ROMS */
> -    int load_roms;
> -    unsigned int optionrom_start, optionrom_end;
> +    void (*load_roms)(void);
> 
>      void (*bios_load)(const struct bios_config *config);
> 
> diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
> index f120ffe..ad50189 100644
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -24,16 +24,11 @@
>  #include "hypercall.h"
>  #include "config.h"
>  #include "pci_regs.h"
> -#include "option_rom.h"
>  #include "apic_regs.h"
>  #include "acpi/acpi2_0.h"
>  #include <xen/version.h>
>  #include <xen/hvm/params.h>
> 
> -#define ROM_INCLUDE_VGABIOS
> -#define ROM_INCLUDE_ETHERBOOT
> -#include "roms.inc"
> -
>  asm (
>      "    .text                       \n"
>      "    .globl _start               \n"
> @@ -147,169 +142,6 @@ static void init_hypercalls(void)
>      printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0xffff, extraversion);
>  }
> 
> -/*
> - * Scan the list of Option ROMs at @roms for one which supports
> - * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
> - * copy it to @dest and return its size rounded up to a multiple 2kB. This
> - * function will not copy ROMs beyond address option_rom_end.
> - */
> -#define round_option_rom(x) (((x) + 2047) & ~2047)
> -static int scan_option_rom(
> -    unsigned int option_rom_end,
> -    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
> -    void *roms, uint32_t dest)
> -{
> -    struct option_rom_header *rom;
> -    struct option_rom_pnp_header *pnph;
> -    struct option_rom_pci_header *pcih;
> -    uint8_t csum;
> -    int i;
> -
> -    static uint32_t orom_ids[64];
> -    static int nr_roms;
> -
> -    /* Avoid duplicate ROMs. */
> -    for ( i = 0; i < nr_roms; i++ )
> -        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
> -            return 0;
> -
> -    rom = roms;
> -    for ( ; ; )
> -    {
> -        /* Invalid signature means we're out of option ROMs. */
> -        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
> -             (rom->rom_size == 0) )
> -            break;
> -
> -        /* Invalid checksum means we're out of option ROMs. */
> -        csum = 0;
> -        for ( i = 0; i < (rom->rom_size * 512); i++ )
> -            csum += ((uint8_t *)rom)[i];
> -        if ( csum != 0 )
> -            break;
> -
> -        /* Check the PCI PnP header (if any) for a match. */
> -        pcih = (struct option_rom_pci_header *)
> -            ((char *)rom + rom->pci_header_offset);
> -        if ( (rom->pci_header_offset != 0) &&
> -             !strncmp((char *)pcih->signature, "PCIR", 4) &&
> -             (pcih->vendor_id == vendor_id) &&
> -             (pcih->device_id == device_id) )
> -            goto found;
> -
> -        rom = (struct option_rom_header *)
> -            ((char *)rom + rom->rom_size * 512);
> -    }
> -
> -    return 0;
> -
> - found:
> -    /* Find the PnP expansion header (if any). */
> -    pnph = ((rom->expansion_header_offset != 0)
> -            ? ((struct option_rom_pnp_header *)
> -               ((char *)rom + rom->expansion_header_offset))
> -            : ((struct option_rom_pnp_header *)NULL));
> -    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
> -        pnph = ((pnph->next_header_offset != 0)
> -                ? ((struct option_rom_pnp_header *)
> -                   ((char *)rom + pnph->next_header_offset))
> -                : ((struct option_rom_pnp_header *)NULL));
> -
> -    printf("Loading PCI Option ROM ...\n");
> -    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
> -        printf(" - Manufacturer: %s\n",
> -               (char *)rom + pnph->manufacturer_name_offset);
> -    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
> -        printf(" - Product name: %s\n",
> -               (char *)rom + pnph->product_name_offset);
> -
> -    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
> -    {
> -        printf("Option ROM size %x exceeds available space\n",
> -               rom->rom_size * 512);
> -        return 0;
> -    }
> -
> -    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
> -    memcpy((void *)dest, rom, rom->rom_size * 512);
> -    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
> -    return round_option_rom(rom->rom_size * 512 + 1);
> -}
> -
> -/*
> - * Scan the PCI bus for the first NIC supported by etherboot, and copy
> - * the corresponding rom data to *copy_rom_dest. Returns the length of the
> - * selected rom, or 0 if no NIC found.
> - */
> -static int scan_etherboot_nic(unsigned int option_rom_end,
> -                              uint32_t copy_rom_dest)
> -{
> -    uint16_t class, vendor_id, device_id, devfn;
> -    int rom_size = 0;
> -
> -    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
> -    {
> -        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
> -        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> -        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> -
> -        /* We're only interested in NICs. */
> -        if ( (vendor_id != 0xffff) &&
> -             (device_id != 0xffff) &&
> -             (class == 0x0200) )
> -            rom_size = scan_option_rom(
> -                option_rom_end,
> -                devfn, vendor_id, device_id, etherboot, copy_rom_dest);
> -    }
> -
> -    return rom_size;
> -}
> -
> -/*
> - * Scan the PCI bus for the devices that have an option ROM, and copy
> - * the corresponding rom data to rom_phys_addr.
> - */
> -static int pci_load_option_roms(unsigned int option_rom_end,
> -                                uint32_t rom_base_addr)
> -{
> -    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
> -    uint16_t vendor_id, device_id, devfn, class;
> -
> -    for ( devfn = 0; devfn < 256; devfn++ )
> -    {
> -        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
> -        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> -        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> -
> -        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
> -            continue;
> -
> -        /*
> -         * Currently only scan options from mass storage devices and serial
> -         * bus controller (Fibre Channel included).
> -         */
> -        if ( (class != 0x1) && (class != 0xc) )
> -            continue;
> -
> -        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
> -        if ( !option_rom_addr )
> -            continue;
> -
> -        /* Ensure Expansion Bar is enabled before copying */
> -        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
> -
> -        rom_phys_addr += scan_option_rom(
> -            option_rom_end,
> -            devfn, vendor_id, device_id,
> -            (void *)(option_rom_addr & ~2047), rom_phys_addr);
> -
> -        /* Restore the default original value of Expansion Bar */
> -        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
> -    }
> -
> -    return rom_phys_addr - rom_base_addr;
> -}
> -
>  /* Replace possibly erroneous memory-size CMOS fields with correct values. */
>  static void cmos_write_memory_size(void)
>  {
> @@ -421,8 +253,6 @@ static void acpi_enable_sci(void)
>  int main(void)
>  {
>      const struct bios_config *bios;
> -    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
> -    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
>      int acpi_enabled;
> 
>      /* Initialise hypercall stubs with RET, rendering them no-ops. */
> @@ -471,41 +301,7 @@ int main(void)
>      }
> 
>      if ( bios->load_roms )
> -    {
> -        switch ( virtual_vga )
> -        {
> -        case VGA_cirrus:
> -            printf("Loading Cirrus VGABIOS ...\n");
> -            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> -                   vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
> -            vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
> -            break;
> -        case VGA_std:
> -            printf("Loading Standard VGABIOS ...\n");
> -            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> -                   vgabios_stdvga, sizeof(vgabios_stdvga));
> -            vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
> -            break;
> -        case VGA_pt:
> -            printf("Loading VGABIOS of passthroughed gfx ...\n");
> -            vgabios_sz = round_option_rom(
> -                (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
> -            break;
> -        default:
> -            printf("No emulated VGA adaptor ...\n");
> -            break;
> -        }
> -
> -        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> -        if ( etherboot_phys_addr < bios->optionrom_start )
> -            etherboot_phys_addr = bios->optionrom_start;
> -        etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
> -                                          etherboot_phys_addr);
> -
> -        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> -        option_rom_sz = pci_load_option_roms(bios->optionrom_end,
> -                                             option_rom_phys_addr);
> -    }
> +        bios->load_roms();
> 
>      acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
> 
> @@ -536,18 +332,6 @@ int main(void)
>      if ( SCRATCH_PHYSICAL_ADDRESS != scratch_start )
>          printf(" %05x-%05lx: Scratch space\n",
>                 SCRATCH_PHYSICAL_ADDRESS, scratch_start);
> -    if ( vgabios_sz )
> -        printf(" %05x-%05x: VGA BIOS\n",
> -               VGABIOS_PHYSICAL_ADDRESS,
> -               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
> -    if ( etherboot_sz )
> -        printf(" %05x-%05x: Etherboot ROM\n",
> -               etherboot_phys_addr,
> -               etherboot_phys_addr + etherboot_sz - 1);
> -    if ( option_rom_sz )
> -        printf(" %05x-%05x: PCI Option ROMs\n",
> -               option_rom_phys_addr,
> -               option_rom_phys_addr + option_rom_sz - 1);
>      printf(" %05x-%05x: Main BIOS\n",
>             bios->bios_address,
>             bios->bios_address + bios->image_size - 1);
> diff --git a/tools/firmware/hvmloader/option_rom.h b/tools/firmware/hvmloader/option_rom.h
> index f0c7ec4..1ada3e2 100644
> --- a/tools/firmware/hvmloader/option_rom.h
> +++ b/tools/firmware/hvmloader/option_rom.h
> @@ -47,6 +47,13 @@ struct option_rom_pci_header {
>      uint16_t reserved;
>  } __attribute__ ((packed));
> 
> +#define round_option_rom(x) (((x) + 2047) & ~2047)
> +int scan_etherboot_nic(unsigned int option_rom_end,
> +                       uint32_t copy_rom_dest,
> +                       void *etherboot_rom);
> +int pci_load_option_roms(unsigned int option_rom_end,
> +                         uint32_t rom_base_addr);
> +
>  #endif /* __HVMLOADER_OPTION_ROM_H__ */
> 
>  /*
> diff --git a/tools/firmware/hvmloader/optionroms.c b/tools/firmware/hvmloader/optionroms.c
> new file mode 100644
> index 0000000..e35aebc
> --- /dev/null
> +++ b/tools/firmware/hvmloader/optionroms.c
> @@ -0,0 +1,189 @@
> +/*
> + * optionroms.c: Option ROM loading support.
> + *
> + * Leendert van Doorn, leendert@watson.ibm.com
> + * Copyright (c) 2005, International Business Machines Corporation.
> + *
> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + */
> +
> +#include "config.h"
> +#include "option_rom.h"
> +#include "util.h"
> +#include "pci_regs.h"
> +
> +/*
> + * Scan the list of Option ROMs at @roms for one which supports
> + * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
> + * copy it to @dest and return its size rounded up to a multiple 2kB. This
> + * function will not copy ROMs beyond address option_rom_end.
> + */
> +static int scan_option_rom(
> +    unsigned int option_rom_end,
> +    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
> +    void *roms, uint32_t dest)
> +{
> +    struct option_rom_header *rom;
> +    struct option_rom_pnp_header *pnph;
> +    struct option_rom_pci_header *pcih;
> +    uint8_t csum;
> +    int i;
> +
> +    static uint32_t orom_ids[64];
> +    static int nr_roms;
> +
> +    /* Avoid duplicate ROMs. */
> +    for ( i = 0; i < nr_roms; i++ )
> +        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
> +            return 0;
> +
> +    rom = roms;
> +    for ( ; ; )
> +    {
> +        /* Invalid signature means we're out of option ROMs. */
> +        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
> +             (rom->rom_size == 0) )
> +            break;
> +
> +        /* Invalid checksum means we're out of option ROMs. */
> +        csum = 0;
> +        for ( i = 0; i < (rom->rom_size * 512); i++ )
> +            csum += ((uint8_t *)rom)[i];
> +        if ( csum != 0 )
> +            break;
> +
> +        /* Check the PCI PnP header (if any) for a match. */
> +        pcih = (struct option_rom_pci_header *)
> +            ((char *)rom + rom->pci_header_offset);
> +        if ( (rom->pci_header_offset != 0) &&
> +             !strncmp((char *)pcih->signature, "PCIR", 4) &&
> +             (pcih->vendor_id == vendor_id) &&
> +             (pcih->device_id == device_id) )
> +            goto found;
> +
> +        rom = (struct option_rom_header *)
> +            ((char *)rom + rom->rom_size * 512);
> +    }
> +
> +    return 0;
> +
> + found:
> +    /* Find the PnP expansion header (if any). */
> +    pnph = ((rom->expansion_header_offset != 0)
> +            ? ((struct option_rom_pnp_header *)
> +               ((char *)rom + rom->expansion_header_offset))
> +            : ((struct option_rom_pnp_header *)NULL));
> +    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
> +        pnph = ((pnph->next_header_offset != 0)
> +                ? ((struct option_rom_pnp_header *)
> +                   ((char *)rom + pnph->next_header_offset))
> +                : ((struct option_rom_pnp_header *)NULL));
> +
> +    printf("Loading PCI Option ROM ...\n");
> +    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
> +        printf(" - Manufacturer: %s\n",
> +               (char *)rom + pnph->manufacturer_name_offset);
> +    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
> +        printf(" - Product name: %s\n",
> +               (char *)rom + pnph->product_name_offset);
> +
> +    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
> +    {
> +        printf("Option ROM size %x exceeds available space\n",
> +               rom->rom_size * 512);
> +        return 0;
> +    }
> +
> +    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
> +    memcpy((void *)dest, rom, rom->rom_size * 512);
> +    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
> +    return round_option_rom(rom->rom_size * 512 + 1);
> +}
> +
> +/*
> + * Scan the PCI bus for the first NIC supported by etherboot, and copy
> + * the corresponding rom data to *copy_rom_dest. Returns the length of the
> + * selected rom, or 0 if no NIC found.
> + */
> +int scan_etherboot_nic(unsigned int option_rom_end,
> +                       uint32_t copy_rom_dest,
> +                       void *etherboot_rom)
> +{
> +    uint16_t class, vendor_id, device_id, devfn;
> +    int rom_size = 0;
> +
> +    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
> +    {
> +        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
> +        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> +        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> +
> +        /* We're only interested in NICs. */
> +        if ( (vendor_id != 0xffff) &&
> +             (device_id != 0xffff) &&
> +             (class == 0x0200) )
> +            rom_size = scan_option_rom(
> +                option_rom_end,
> +                devfn, vendor_id, device_id, etherboot_rom, copy_rom_dest);
> +    }
> +
> +    return rom_size;
> +}
> +
> +/*
> + * Scan the PCI bus for the devices that have an option ROM, and copy
> + * the corresponding rom data to rom_phys_addr.
> + */
> +int pci_load_option_roms(unsigned int option_rom_end,
> +                         uint32_t rom_base_addr)
> +{
> +    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
> +    uint16_t vendor_id, device_id, devfn, class;
> +
> +    for ( devfn = 0; devfn < 256; devfn++ )
> +    {
> +        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
> +        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> +        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> +
> +        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
> +            continue;
> +
> +        /*
> +         * Currently only scan options from mass storage devices and serial
> +         * bus controller (Fibre Channel included).
> +         */
> +        if ( (class != 0x1) && (class != 0xc) )
> +            continue;
> +
> +        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
> +        if ( !option_rom_addr )
> +            continue;
> +
> +        /* Ensure Expansion Bar is enabled before copying */
> +        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
> +
> +        rom_phys_addr += scan_option_rom(
> +            option_rom_end,
> +            devfn, vendor_id, device_id,
> +            (void *)(option_rom_addr & ~2047), rom_phys_addr);
> +
> +        /* Restore the default original value of Expansion Bar */
> +        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
> +    }
> +
> +    return rom_phys_addr - rom_base_addr;
> +}
> diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
> index d5831aa..e0d4182 100644
> --- a/tools/firmware/hvmloader/rombios.c
> +++ b/tools/firmware/hvmloader/rombios.c
> @@ -29,10 +29,13 @@
>  #include "pci_regs.h"
>  #include "util.h"
>  #include "hypercall.h"
> +#include "option_rom.h"
> 
>  #include <xen/hvm/params.h>
> 
>  #define ROM_INCLUDE_ROMBIOS
> +#define ROM_INCLUDE_VGABIOS
> +#define ROM_INCLUDE_ETHERBOOT
>  #include "roms.inc"
> 
>  #define ROMBIOS_BEGIN          0x000F0000
> @@ -64,6 +67,61 @@ static void rombios_setup_bios_info(void)
>      memset(info, 0, sizeof(*info));
>  }
> 
> +static void rombios_load_roms(void)
> +{
> +    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
> +    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
> +
> +    switch ( virtual_vga )
> +    {
> +    case VGA_cirrus:
> +        printf("Loading Cirrus VGABIOS ...\n");
> +        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> +               vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
> +        vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
> +        break;
> +    case VGA_std:
> +        printf("Loading Standard VGABIOS ...\n");
> +        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> +               vgabios_stdvga, sizeof(vgabios_stdvga));
> +        vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
> +        break;
> +    case VGA_pt:
> +        printf("Loading VGABIOS of passthroughed gfx ...\n");
> +        vgabios_sz = round_option_rom(
> +            (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
> +        break;
> +    default:
> +        printf("No emulated VGA adaptor ...\n");
> +        break;
> +    }
> +
> +    etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> +    if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
> +        etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
> +    etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
> +                                      etherboot_phys_addr,
> +                                      etherboot);
> +
> +    option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> +    option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
> +                                         option_rom_phys_addr);
> +
> +    printf("Option ROMs:\n");
> +    if ( vgabios_sz )
> +        printf(" %05x-%05x: VGA BIOS\n",
> +               VGABIOS_PHYSICAL_ADDRESS,
> +               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
> +    if ( etherboot_sz )
> +        printf(" %05x-%05x: Etherboot ROM\n",
> +               etherboot_phys_addr,
> +               etherboot_phys_addr + etherboot_sz - 1);
> +    if ( option_rom_sz )
> +        printf(" %05x-%05x: PCI Option ROMs\n",
> +               option_rom_phys_addr,
> +               option_rom_phys_addr + option_rom_sz - 1);
> +}
> +
>  static void rombios_load(const struct bios_config *config)
>  {
>      uint32_t bioshigh;
> @@ -158,10 +216,7 @@ struct bios_config rombios_config =  {
> 
>      .bios_address = ROMBIOS_PHYSICAL_ADDRESS,
> 
> -    .load_roms = 1,
> -
> -    .optionrom_start = OPTIONROM_PHYSICAL_ADDRESS,
> -    .optionrom_end = OPTIONROM_PHYSICAL_END,
> +    .load_roms = rombios_load_roms,
> 
>      .bios_load = rombios_load,
> 
> diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
> index 3045157..15ddf35 100644
> --- a/tools/firmware/hvmloader/seabios.c
> +++ b/tools/firmware/hvmloader/seabios.c
> @@ -143,10 +143,7 @@ struct bios_config seabios_config = {
> 
>      .bios_address = SEABIOS_PHYSICAL_ADDRESS,
> 
> -    .load_roms = 0,
> -
> -    .optionrom_start = 0,
> -    .optionrom_end = 0,
> +    .load_roms = NULL,
> 
>      .bios_load = NULL,
> 
> --
> Julian Pidancet
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:53:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuTK-0006LT-8H; Mon, 13 Feb 2012 11:53:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuTI-0006KZ-9u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:53:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329134002!14326143!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31353 invoked from network); 13 Feb 2012 11:53:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:53:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:53:22 +0000
Message-ID: <1329134000.31256.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:53:20 +0000
In-Reply-To: <bcc9b695f6ae5a4d915116f154d2b5e23fbf5865.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<bcc9b695f6ae5a4d915116f154d2b5e23fbf5865.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 4/5] hvmloader: Move option ROM loading
 into a separate optionnal file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> Make load_rom field in struct bios_config an optionnal callback rather
> than a boolean value. It allow BIOS specific code to implement it's own
> option ROM loading methods.
> 
> Facilities to scan PCI devices, extract an deploy ROMs are moved into
> a separate file that can be compiled optionnaly.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Presuming this to be mostly code motion I didn't review in depth but:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/firmware/hvmloader/Makefile     |    2 +-
>  tools/firmware/hvmloader/config.h     |    3 +-
>  tools/firmware/hvmloader/hvmloader.c  |  218 +--------------------------------
>  tools/firmware/hvmloader/option_rom.h |    7 +
>  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
>  tools/firmware/hvmloader/seabios.c    |    5 +-
>  7 files changed, 259 insertions(+), 228 deletions(-)
>  create mode 100644 tools/firmware/hvmloader/optionroms.c
> 
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index 1ea32db..5a5ee41 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -39,7 +39,7 @@ CIRRUSVGA_DEBUG ?= n
> 
>  ROMBIOS_DIR := ../rombios
>  ifneq ($(ROMBIOS_DIR),)
> -OBJS += 32bitbios_support.o rombios.o
> +OBJS += optionroms.o 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif
> diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
> index 9cac9c1..1f80263 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -18,8 +18,7 @@ struct bios_config {
>      unsigned int bios_address;
> 
>      /* ROMS */
> -    int load_roms;
> -    unsigned int optionrom_start, optionrom_end;
> +    void (*load_roms)(void);
> 
>      void (*bios_load)(const struct bios_config *config);
> 
> diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
> index f120ffe..ad50189 100644
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -24,16 +24,11 @@
>  #include "hypercall.h"
>  #include "config.h"
>  #include "pci_regs.h"
> -#include "option_rom.h"
>  #include "apic_regs.h"
>  #include "acpi/acpi2_0.h"
>  #include <xen/version.h>
>  #include <xen/hvm/params.h>
> 
> -#define ROM_INCLUDE_VGABIOS
> -#define ROM_INCLUDE_ETHERBOOT
> -#include "roms.inc"
> -
>  asm (
>      "    .text                       \n"
>      "    .globl _start               \n"
> @@ -147,169 +142,6 @@ static void init_hypercalls(void)
>      printf("Detected Xen v%u.%u%s\n", eax >> 16, eax & 0xffff, extraversion);
>  }
> 
> -/*
> - * Scan the list of Option ROMs at @roms for one which supports
> - * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
> - * copy it to @dest and return its size rounded up to a multiple 2kB. This
> - * function will not copy ROMs beyond address option_rom_end.
> - */
> -#define round_option_rom(x) (((x) + 2047) & ~2047)
> -static int scan_option_rom(
> -    unsigned int option_rom_end,
> -    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
> -    void *roms, uint32_t dest)
> -{
> -    struct option_rom_header *rom;
> -    struct option_rom_pnp_header *pnph;
> -    struct option_rom_pci_header *pcih;
> -    uint8_t csum;
> -    int i;
> -
> -    static uint32_t orom_ids[64];
> -    static int nr_roms;
> -
> -    /* Avoid duplicate ROMs. */
> -    for ( i = 0; i < nr_roms; i++ )
> -        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
> -            return 0;
> -
> -    rom = roms;
> -    for ( ; ; )
> -    {
> -        /* Invalid signature means we're out of option ROMs. */
> -        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
> -             (rom->rom_size == 0) )
> -            break;
> -
> -        /* Invalid checksum means we're out of option ROMs. */
> -        csum = 0;
> -        for ( i = 0; i < (rom->rom_size * 512); i++ )
> -            csum += ((uint8_t *)rom)[i];
> -        if ( csum != 0 )
> -            break;
> -
> -        /* Check the PCI PnP header (if any) for a match. */
> -        pcih = (struct option_rom_pci_header *)
> -            ((char *)rom + rom->pci_header_offset);
> -        if ( (rom->pci_header_offset != 0) &&
> -             !strncmp((char *)pcih->signature, "PCIR", 4) &&
> -             (pcih->vendor_id == vendor_id) &&
> -             (pcih->device_id == device_id) )
> -            goto found;
> -
> -        rom = (struct option_rom_header *)
> -            ((char *)rom + rom->rom_size * 512);
> -    }
> -
> -    return 0;
> -
> - found:
> -    /* Find the PnP expansion header (if any). */
> -    pnph = ((rom->expansion_header_offset != 0)
> -            ? ((struct option_rom_pnp_header *)
> -               ((char *)rom + rom->expansion_header_offset))
> -            : ((struct option_rom_pnp_header *)NULL));
> -    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
> -        pnph = ((pnph->next_header_offset != 0)
> -                ? ((struct option_rom_pnp_header *)
> -                   ((char *)rom + pnph->next_header_offset))
> -                : ((struct option_rom_pnp_header *)NULL));
> -
> -    printf("Loading PCI Option ROM ...\n");
> -    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
> -        printf(" - Manufacturer: %s\n",
> -               (char *)rom + pnph->manufacturer_name_offset);
> -    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
> -        printf(" - Product name: %s\n",
> -               (char *)rom + pnph->product_name_offset);
> -
> -    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
> -    {
> -        printf("Option ROM size %x exceeds available space\n",
> -               rom->rom_size * 512);
> -        return 0;
> -    }
> -
> -    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
> -    memcpy((void *)dest, rom, rom->rom_size * 512);
> -    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
> -    return round_option_rom(rom->rom_size * 512 + 1);
> -}
> -
> -/*
> - * Scan the PCI bus for the first NIC supported by etherboot, and copy
> - * the corresponding rom data to *copy_rom_dest. Returns the length of the
> - * selected rom, or 0 if no NIC found.
> - */
> -static int scan_etherboot_nic(unsigned int option_rom_end,
> -                              uint32_t copy_rom_dest)
> -{
> -    uint16_t class, vendor_id, device_id, devfn;
> -    int rom_size = 0;
> -
> -    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
> -    {
> -        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
> -        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> -        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> -
> -        /* We're only interested in NICs. */
> -        if ( (vendor_id != 0xffff) &&
> -             (device_id != 0xffff) &&
> -             (class == 0x0200) )
> -            rom_size = scan_option_rom(
> -                option_rom_end,
> -                devfn, vendor_id, device_id, etherboot, copy_rom_dest);
> -    }
> -
> -    return rom_size;
> -}
> -
> -/*
> - * Scan the PCI bus for the devices that have an option ROM, and copy
> - * the corresponding rom data to rom_phys_addr.
> - */
> -static int pci_load_option_roms(unsigned int option_rom_end,
> -                                uint32_t rom_base_addr)
> -{
> -    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
> -    uint16_t vendor_id, device_id, devfn, class;
> -
> -    for ( devfn = 0; devfn < 256; devfn++ )
> -    {
> -        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
> -        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> -        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> -
> -        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
> -            continue;
> -
> -        /*
> -         * Currently only scan options from mass storage devices and serial
> -         * bus controller (Fibre Channel included).
> -         */
> -        if ( (class != 0x1) && (class != 0xc) )
> -            continue;
> -
> -        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
> -        if ( !option_rom_addr )
> -            continue;
> -
> -        /* Ensure Expansion Bar is enabled before copying */
> -        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
> -
> -        rom_phys_addr += scan_option_rom(
> -            option_rom_end,
> -            devfn, vendor_id, device_id,
> -            (void *)(option_rom_addr & ~2047), rom_phys_addr);
> -
> -        /* Restore the default original value of Expansion Bar */
> -        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
> -    }
> -
> -    return rom_phys_addr - rom_base_addr;
> -}
> -
>  /* Replace possibly erroneous memory-size CMOS fields with correct values. */
>  static void cmos_write_memory_size(void)
>  {
> @@ -421,8 +253,6 @@ static void acpi_enable_sci(void)
>  int main(void)
>  {
>      const struct bios_config *bios;
> -    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
> -    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
>      int acpi_enabled;
> 
>      /* Initialise hypercall stubs with RET, rendering them no-ops. */
> @@ -471,41 +301,7 @@ int main(void)
>      }
> 
>      if ( bios->load_roms )
> -    {
> -        switch ( virtual_vga )
> -        {
> -        case VGA_cirrus:
> -            printf("Loading Cirrus VGABIOS ...\n");
> -            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> -                   vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
> -            vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
> -            break;
> -        case VGA_std:
> -            printf("Loading Standard VGABIOS ...\n");
> -            memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> -                   vgabios_stdvga, sizeof(vgabios_stdvga));
> -            vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
> -            break;
> -        case VGA_pt:
> -            printf("Loading VGABIOS of passthroughed gfx ...\n");
> -            vgabios_sz = round_option_rom(
> -                (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
> -            break;
> -        default:
> -            printf("No emulated VGA adaptor ...\n");
> -            break;
> -        }
> -
> -        etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> -        if ( etherboot_phys_addr < bios->optionrom_start )
> -            etherboot_phys_addr = bios->optionrom_start;
> -        etherboot_sz = scan_etherboot_nic(bios->optionrom_end,
> -                                          etherboot_phys_addr);
> -
> -        option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> -        option_rom_sz = pci_load_option_roms(bios->optionrom_end,
> -                                             option_rom_phys_addr);
> -    }
> +        bios->load_roms();
> 
>      acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
> 
> @@ -536,18 +332,6 @@ int main(void)
>      if ( SCRATCH_PHYSICAL_ADDRESS != scratch_start )
>          printf(" %05x-%05lx: Scratch space\n",
>                 SCRATCH_PHYSICAL_ADDRESS, scratch_start);
> -    if ( vgabios_sz )
> -        printf(" %05x-%05x: VGA BIOS\n",
> -               VGABIOS_PHYSICAL_ADDRESS,
> -               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
> -    if ( etherboot_sz )
> -        printf(" %05x-%05x: Etherboot ROM\n",
> -               etherboot_phys_addr,
> -               etherboot_phys_addr + etherboot_sz - 1);
> -    if ( option_rom_sz )
> -        printf(" %05x-%05x: PCI Option ROMs\n",
> -               option_rom_phys_addr,
> -               option_rom_phys_addr + option_rom_sz - 1);
>      printf(" %05x-%05x: Main BIOS\n",
>             bios->bios_address,
>             bios->bios_address + bios->image_size - 1);
> diff --git a/tools/firmware/hvmloader/option_rom.h b/tools/firmware/hvmloader/option_rom.h
> index f0c7ec4..1ada3e2 100644
> --- a/tools/firmware/hvmloader/option_rom.h
> +++ b/tools/firmware/hvmloader/option_rom.h
> @@ -47,6 +47,13 @@ struct option_rom_pci_header {
>      uint16_t reserved;
>  } __attribute__ ((packed));
> 
> +#define round_option_rom(x) (((x) + 2047) & ~2047)
> +int scan_etherboot_nic(unsigned int option_rom_end,
> +                       uint32_t copy_rom_dest,
> +                       void *etherboot_rom);
> +int pci_load_option_roms(unsigned int option_rom_end,
> +                         uint32_t rom_base_addr);
> +
>  #endif /* __HVMLOADER_OPTION_ROM_H__ */
> 
>  /*
> diff --git a/tools/firmware/hvmloader/optionroms.c b/tools/firmware/hvmloader/optionroms.c
> new file mode 100644
> index 0000000..e35aebc
> --- /dev/null
> +++ b/tools/firmware/hvmloader/optionroms.c
> @@ -0,0 +1,189 @@
> +/*
> + * optionroms.c: Option ROM loading support.
> + *
> + * Leendert van Doorn, leendert@watson.ibm.com
> + * Copyright (c) 2005, International Business Machines Corporation.
> + *
> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + */
> +
> +#include "config.h"
> +#include "option_rom.h"
> +#include "util.h"
> +#include "pci_regs.h"
> +
> +/*
> + * Scan the list of Option ROMs at @roms for one which supports
> + * PCI (@vendor_id, @device_id) found at slot @devfn. If one is found,
> + * copy it to @dest and return its size rounded up to a multiple 2kB. This
> + * function will not copy ROMs beyond address option_rom_end.
> + */
> +static int scan_option_rom(
> +    unsigned int option_rom_end,
> +    uint8_t devfn, uint16_t vendor_id, uint16_t device_id,
> +    void *roms, uint32_t dest)
> +{
> +    struct option_rom_header *rom;
> +    struct option_rom_pnp_header *pnph;
> +    struct option_rom_pci_header *pcih;
> +    uint8_t csum;
> +    int i;
> +
> +    static uint32_t orom_ids[64];
> +    static int nr_roms;
> +
> +    /* Avoid duplicate ROMs. */
> +    for ( i = 0; i < nr_roms; i++ )
> +        if ( orom_ids[i] == (vendor_id | ((uint32_t)device_id << 16)) )
> +            return 0;
> +
> +    rom = roms;
> +    for ( ; ; )
> +    {
> +        /* Invalid signature means we're out of option ROMs. */
> +        if ( strncmp((char *)rom->signature, "\x55\xaa", 2) ||
> +             (rom->rom_size == 0) )
> +            break;
> +
> +        /* Invalid checksum means we're out of option ROMs. */
> +        csum = 0;
> +        for ( i = 0; i < (rom->rom_size * 512); i++ )
> +            csum += ((uint8_t *)rom)[i];
> +        if ( csum != 0 )
> +            break;
> +
> +        /* Check the PCI PnP header (if any) for a match. */
> +        pcih = (struct option_rom_pci_header *)
> +            ((char *)rom + rom->pci_header_offset);
> +        if ( (rom->pci_header_offset != 0) &&
> +             !strncmp((char *)pcih->signature, "PCIR", 4) &&
> +             (pcih->vendor_id == vendor_id) &&
> +             (pcih->device_id == device_id) )
> +            goto found;
> +
> +        rom = (struct option_rom_header *)
> +            ((char *)rom + rom->rom_size * 512);
> +    }
> +
> +    return 0;
> +
> + found:
> +    /* Find the PnP expansion header (if any). */
> +    pnph = ((rom->expansion_header_offset != 0)
> +            ? ((struct option_rom_pnp_header *)
> +               ((char *)rom + rom->expansion_header_offset))
> +            : ((struct option_rom_pnp_header *)NULL));
> +    while ( (pnph != NULL) && strncmp((char *)pnph->signature, "$PnP", 4) )
> +        pnph = ((pnph->next_header_offset != 0)
> +                ? ((struct option_rom_pnp_header *)
> +                   ((char *)rom + pnph->next_header_offset))
> +                : ((struct option_rom_pnp_header *)NULL));
> +
> +    printf("Loading PCI Option ROM ...\n");
> +    if ( (pnph != NULL) && (pnph->manufacturer_name_offset != 0) )
> +        printf(" - Manufacturer: %s\n",
> +               (char *)rom + pnph->manufacturer_name_offset);
> +    if ( (pnph != NULL) && (pnph->product_name_offset != 0) )
> +        printf(" - Product name: %s\n",
> +               (char *)rom + pnph->product_name_offset);
> +
> +    if ( (dest + rom->rom_size * 512 + 1) > option_rom_end )
> +    {
> +        printf("Option ROM size %x exceeds available space\n",
> +               rom->rom_size * 512);
> +        return 0;
> +    }
> +
> +    orom_ids[nr_roms++] = vendor_id | ((uint32_t)device_id << 16);
> +    memcpy((void *)dest, rom, rom->rom_size * 512);
> +    *(uint8_t *)(dest + rom->rom_size * 512) = devfn;
> +    return round_option_rom(rom->rom_size * 512 + 1);
> +}
> +
> +/*
> + * Scan the PCI bus for the first NIC supported by etherboot, and copy
> + * the corresponding rom data to *copy_rom_dest. Returns the length of the
> + * selected rom, or 0 if no NIC found.
> + */
> +int scan_etherboot_nic(unsigned int option_rom_end,
> +                       uint32_t copy_rom_dest,
> +                       void *etherboot_rom)
> +{
> +    uint16_t class, vendor_id, device_id, devfn;
> +    int rom_size = 0;
> +
> +    for ( devfn = 0; (devfn < 256) && !rom_size; devfn++ )
> +    {
> +        class     = pci_readw(devfn, PCI_CLASS_DEVICE);
> +        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> +        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> +
> +        /* We're only interested in NICs. */
> +        if ( (vendor_id != 0xffff) &&
> +             (device_id != 0xffff) &&
> +             (class == 0x0200) )
> +            rom_size = scan_option_rom(
> +                option_rom_end,
> +                devfn, vendor_id, device_id, etherboot_rom, copy_rom_dest);
> +    }
> +
> +    return rom_size;
> +}
> +
> +/*
> + * Scan the PCI bus for the devices that have an option ROM, and copy
> + * the corresponding rom data to rom_phys_addr.
> + */
> +int pci_load_option_roms(unsigned int option_rom_end,
> +                         uint32_t rom_base_addr)
> +{
> +    uint32_t option_rom_addr, rom_phys_addr = rom_base_addr;
> +    uint16_t vendor_id, device_id, devfn, class;
> +
> +    for ( devfn = 0; devfn < 256; devfn++ )
> +    {
> +        class     = pci_readb(devfn, PCI_CLASS_DEVICE + 1);
> +        vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
> +        device_id = pci_readw(devfn, PCI_DEVICE_ID);
> +
> +        if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
> +            continue;
> +
> +        /*
> +         * Currently only scan options from mass storage devices and serial
> +         * bus controller (Fibre Channel included).
> +         */
> +        if ( (class != 0x1) && (class != 0xc) )
> +            continue;
> +
> +        option_rom_addr = pci_readl(devfn, PCI_ROM_ADDRESS);
> +        if ( !option_rom_addr )
> +            continue;
> +
> +        /* Ensure Expansion Bar is enabled before copying */
> +        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr | 0x1);
> +
> +        rom_phys_addr += scan_option_rom(
> +            option_rom_end,
> +            devfn, vendor_id, device_id,
> +            (void *)(option_rom_addr & ~2047), rom_phys_addr);
> +
> +        /* Restore the default original value of Expansion Bar */
> +        pci_writel(devfn, PCI_ROM_ADDRESS, option_rom_addr);
> +    }
> +
> +    return rom_phys_addr - rom_base_addr;
> +}
> diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
> index d5831aa..e0d4182 100644
> --- a/tools/firmware/hvmloader/rombios.c
> +++ b/tools/firmware/hvmloader/rombios.c
> @@ -29,10 +29,13 @@
>  #include "pci_regs.h"
>  #include "util.h"
>  #include "hypercall.h"
> +#include "option_rom.h"
> 
>  #include <xen/hvm/params.h>
> 
>  #define ROM_INCLUDE_ROMBIOS
> +#define ROM_INCLUDE_VGABIOS
> +#define ROM_INCLUDE_ETHERBOOT
>  #include "roms.inc"
> 
>  #define ROMBIOS_BEGIN          0x000F0000
> @@ -64,6 +67,61 @@ static void rombios_setup_bios_info(void)
>      memset(info, 0, sizeof(*info));
>  }
> 
> +static void rombios_load_roms(void)
> +{
> +    int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
> +    uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
> +
> +    switch ( virtual_vga )
> +    {
> +    case VGA_cirrus:
> +        printf("Loading Cirrus VGABIOS ...\n");
> +        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> +               vgabios_cirrusvga, sizeof(vgabios_cirrusvga));
> +        vgabios_sz = round_option_rom(sizeof(vgabios_cirrusvga));
> +        break;
> +    case VGA_std:
> +        printf("Loading Standard VGABIOS ...\n");
> +        memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
> +               vgabios_stdvga, sizeof(vgabios_stdvga));
> +        vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
> +        break;
> +    case VGA_pt:
> +        printf("Loading VGABIOS of passthroughed gfx ...\n");
> +        vgabios_sz = round_option_rom(
> +            (*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
> +        break;
> +    default:
> +        printf("No emulated VGA adaptor ...\n");
> +        break;
> +    }
> +
> +    etherboot_phys_addr = VGABIOS_PHYSICAL_ADDRESS + vgabios_sz;
> +    if ( etherboot_phys_addr < OPTIONROM_PHYSICAL_ADDRESS )
> +        etherboot_phys_addr = OPTIONROM_PHYSICAL_ADDRESS;
> +    etherboot_sz = scan_etherboot_nic(OPTIONROM_PHYSICAL_END,
> +                                      etherboot_phys_addr,
> +                                      etherboot);
> +
> +    option_rom_phys_addr = etherboot_phys_addr + etherboot_sz;
> +    option_rom_sz = pci_load_option_roms(OPTIONROM_PHYSICAL_END,
> +                                         option_rom_phys_addr);
> +
> +    printf("Option ROMs:\n");
> +    if ( vgabios_sz )
> +        printf(" %05x-%05x: VGA BIOS\n",
> +               VGABIOS_PHYSICAL_ADDRESS,
> +               VGABIOS_PHYSICAL_ADDRESS + vgabios_sz - 1);
> +    if ( etherboot_sz )
> +        printf(" %05x-%05x: Etherboot ROM\n",
> +               etherboot_phys_addr,
> +               etherboot_phys_addr + etherboot_sz - 1);
> +    if ( option_rom_sz )
> +        printf(" %05x-%05x: PCI Option ROMs\n",
> +               option_rom_phys_addr,
> +               option_rom_phys_addr + option_rom_sz - 1);
> +}
> +
>  static void rombios_load(const struct bios_config *config)
>  {
>      uint32_t bioshigh;
> @@ -158,10 +216,7 @@ struct bios_config rombios_config =  {
> 
>      .bios_address = ROMBIOS_PHYSICAL_ADDRESS,
> 
> -    .load_roms = 1,
> -
> -    .optionrom_start = OPTIONROM_PHYSICAL_ADDRESS,
> -    .optionrom_end = OPTIONROM_PHYSICAL_END,
> +    .load_roms = rombios_load_roms,
> 
>      .bios_load = rombios_load,
> 
> diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
> index 3045157..15ddf35 100644
> --- a/tools/firmware/hvmloader/seabios.c
> +++ b/tools/firmware/hvmloader/seabios.c
> @@ -143,10 +143,7 @@ struct bios_config seabios_config = {
> 
>      .bios_address = SEABIOS_PHYSICAL_ADDRESS,
> 
> -    .load_roms = 0,
> -
> -    .optionrom_start = 0,
> -    .optionrom_end = 0,
> +    .load_roms = NULL,
> 
>      .bios_load = NULL,
> 
> --
> Julian Pidancet
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:53:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuTN-0006Md-T2; Mon, 13 Feb 2012 11:53:33 +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 1RwuTL-0006Lu-TA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:53:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329133959!52485326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5536 invoked from network); 13 Feb 2012 11:52:39 -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;
	13 Feb 2012 11:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:30 +0000
Date: Mon, 13 Feb 2012 11:57:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202131155540.7456@kaball-desktop>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini)

I have sent patches for both QEMU and xl/libxl, I have addressed all
comments but I haven't received any acks yet. I'll ping the maintainers
again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:53:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuTN-0006Md-T2; Mon, 13 Feb 2012 11:53:33 +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 1RwuTL-0006Lu-TA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:53:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329133959!52485326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5536 invoked from network); 13 Feb 2012 11:52:39 -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;
	13 Feb 2012 11:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:30 +0000
Date: Mon, 13 Feb 2012 11:57:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202131155540.7456@kaball-desktop>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini)

I have sent patches for both QEMU and xl/libxl, I have addressed all
comments but I haven't received any acks yet. I'll ping the maintainers
again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:55:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuV0-0006m0-FP; Mon, 13 Feb 2012 11:55:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuUz-0006ld-3u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:55:13 +0000
Received: from [85.158.139.83:50827] by server-11.bemta-5.messagelabs.com id
	06/F7-13907-02AF83F4; Mon, 13 Feb 2012 11:55:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329134111!14830126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1663 invoked from network); 13 Feb 2012 11:55:11 -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;
	13 Feb 2012 11:55:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:55:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:55:07 +0000
Message-ID: <1329134105.31256.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:55:05 +0000
In-Reply-To: <0849e9a95e551e4c6f390774e68387b6ff6751fb.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<0849e9a95e551e4c6f390774e68387b6ff6751fb.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 5/5] firmware: Introduce CONFIG_ROMBIOS
 and CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> This patch introduces configuration options allowing to built either
> a rombios only or a seabios only hvmloader.
> 
> Building option ROMs like vgabios or etherboot is only enabled for
> a rombios hvmloader, since SeaBIOS takes care or extracting option
> ROMs itself from the PCI devices (these option ROMs are provided
> by the device model and do not need to be built in hvmloader).
> 
> The Makefile in tools/firmware/ now only checks for bcc if rombios
> is enabled.
> 
> These two configuration options are left on by default to remain
> compatible.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:55:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuV0-0006m0-FP; Mon, 13 Feb 2012 11:55:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuUz-0006ld-3u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:55:13 +0000
Received: from [85.158.139.83:50827] by server-11.bemta-5.messagelabs.com id
	06/F7-13907-02AF83F4; Mon, 13 Feb 2012 11:55:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329134111!14830126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1663 invoked from network); 13 Feb 2012 11:55:11 -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;
	13 Feb 2012 11:55:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:55:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:55:07 +0000
Message-ID: <1329134105.31256.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Date: Mon, 13 Feb 2012 11:55:05 +0000
In-Reply-To: <0849e9a95e551e4c6f390774e68387b6ff6751fb.1328991838.git.julian.pidancet@gmail.com>
References: <cover.1328991838.git.julian.pidancet@gmail.com>
	<0849e9a95e551e4c6f390774e68387b6ff6751fb.1328991838.git.julian.pidancet@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3 5/5] firmware: Introduce CONFIG_ROMBIOS
 and CONFIG_SEABIOS options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-11 at 20:39 +0000, Julian Pidancet wrote:
> This patch introduces configuration options allowing to built either
> a rombios only or a seabios only hvmloader.
> 
> Building option ROMs like vgabios or etherboot is only enabled for
> a rombios hvmloader, since SeaBIOS takes care or extracting option
> ROMs itself from the PCI devices (these option ROMs are provided
> by the device model and do not need to be built in hvmloader).
> 
> The Makefile in tools/firmware/ now only checks for bcc if rombios
> is enabled.
> 
> These two configuration options are left on by default to remain
> compatible.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:55:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuVN-0006rp-UR; Mon, 13 Feb 2012 11:55:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwuVL-0006px-TV
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:55:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329134129!14576852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30351 invoked from network); 13 Feb 2012 11:55:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:55:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:55:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:55:30 +0000
Date: Mon, 13 Feb 2012 11:59:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202131158480.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
	<alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
	<CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-47964083-1329134383=:7456"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-47964083-1329134383=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 13 Feb 2012, Roger Pau Monné wrote:
> > Yes, great improvements.
> > The old qemu-xen uses threads to simulate async IO so it is very slow;
> > upstream QEMU uses Linux AIO and is much faster.
> 
> That's great news, so qdisk performance in qemu-upstream should be
> similar to blktap?

Slightly better actually, from my very quick and dirty tests.
--8323329-47964083-1329134383=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-47964083-1329134383=:7456--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:55:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuVN-0006rp-UR; Mon, 13 Feb 2012 11:55:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwuVL-0006px-TV
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:55:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329134129!14576852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30351 invoked from network); 13 Feb 2012 11:55:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:55:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:55:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:55:30 +0000
Date: Mon, 13 Feb 2012 11:59:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202131158480.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
	<alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
	<CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-47964083-1329134383=:7456"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-47964083-1329134383=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 13 Feb 2012, Roger Pau Monné wrote:
> > Yes, great improvements.
> > The old qemu-xen uses threads to simulate async IO so it is very slow;
> > upstream QEMU uses Linux AIO and is much faster.
> 
> That's great news, so qdisk performance in qemu-upstream should be
> similar to blktap?

Slightly better actually, from my very quick and dirty tests.
--8323329-47964083-1329134383=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-47964083-1329134383=:7456--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:56:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuWN-00076I-Ek; Mon, 13 Feb 2012 11:56:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuWL-000755-Rr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:56:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329134191!14562592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20306 invoked from network); 13 Feb 2012 11:56:32 -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 Feb 2012 11:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:56:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:56:16 +0000
Message-ID: <1329134175.31256.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 13 Feb 2012 11:56:15 +0000
In-Reply-To: <CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
	<CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 11:50 +0000, Anthony PERARD wrote:
> On Mon, Feb 13, 2012 at 11:05, Fantu <fantonifabio@tiscali.it> wrote:
> >         * Spice full support and build enabled by default
> >
> > About Spice support on qemu upstream, now is not built by default and on xl
> > configuration files is minimal. Probably there are also some required missed
> > options about qxl graphic needed by Spice on xl configuration files.
> > I search on tools/libxl/libxl_dm.c but I have found nothing about qxl now.
> 
> About the build, QEMU should include spice support if the necessary
> library are installed. But on Debian stable (Squeeze), the spice
> library are too old, so forcing QEMU to have spice support will just
> break the build.

Agreed, spice support should be conditional on the necessary support
libraries being available. It would however be useful to document (e.g.
in the top-level README) exactly what those requirements are.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:56:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11: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.xensource.com>)
	id 1RwuWN-00076I-Ek; Mon, 13 Feb 2012 11:56:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuWL-000755-Rr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:56:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329134191!14562592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20306 invoked from network); 13 Feb 2012 11:56:32 -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 Feb 2012 11:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10659956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:56:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 11:56:16 +0000
Message-ID: <1329134175.31256.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 13 Feb 2012 11:56:15 +0000
In-Reply-To: <CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
	<CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 11:50 +0000, Anthony PERARD wrote:
> On Mon, Feb 13, 2012 at 11:05, Fantu <fantonifabio@tiscali.it> wrote:
> >         * Spice full support and build enabled by default
> >
> > About Spice support on qemu upstream, now is not built by default and on xl
> > configuration files is minimal. Probably there are also some required missed
> > options about qxl graphic needed by Spice on xl configuration files.
> > I search on tools/libxl/libxl_dm.c but I have found nothing about qxl now.
> 
> About the build, QEMU should include spice support if the necessary
> library are installed. But on Debian stable (Squeeze), the spice
> library are too old, so forcing QEMU to have spice support will just
> break the build.

Agreed, spice support should be conditional on the necessary support
libraries being available. It would however be useful to document (e.g.
in the top-level README) exactly what those requirements are.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:58:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuXb-0007Ij-0o; Mon, 13 Feb 2012 11:57:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuXZ-0007Hy-Qr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:57:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329134266!2532313!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8654 invoked from network); 13 Feb 2012 11:57:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:57:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181479634"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 06:57:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 06:57:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DBvXlv024041;	Mon, 13 Feb 2012 03:57:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3bb05b667dece86eff10635ab637e704812e5d77
Message-ID: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 11:57:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: tim@xen.org, stefano.stabellini@citrix.com
Subject: [Xen-devel] [PATCH] MAINTAINERS: Add entry for ARM w/ virt
	extensions port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329134225 0
# Node ID 3bb05b667dece86eff10635ab637e704812e5d77
# Parent  fb71a97fe339282965d584663236ce71a2400659
MAINTAINERS: Add entry for ARM w/ virt extensions port

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r fb71a97fe339 -r 3bb05b667dec MAINTAINERS
--- a/MAINTAINERS	Thu Feb 09 15:32:50 2012 +0000
+++ b/MAINTAINERS	Mon Feb 13 11:57:05 2012 +0000
@@ -97,6 +97,15 @@ M:	Wei Huang <wei.huang2@amd.com>
 S:	Supported
 F:	xen/arch/x86/hvm/svm/
 
+ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
+M:	Ian Campbell <ian.campbell@citrix.com>
+M:	Stefano Stabellini <stefano.stabellini@citrix.com>
+M:	Tim Deegan <tim@xen.org>
+S:	Supported
+L:	xen-devel@lists.xensource.com
+F:	xen/arch/arm/
+F:	xen/include/asm-arm/
+
 CPU POOLS
 M:	Juergen Gross <juergen.gross@ts.fujitsu.com>
 S:	Supported

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:58:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:58:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuXb-0007Ij-0o; Mon, 13 Feb 2012 11:57:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwuXZ-0007Hy-Qr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:57:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329134266!2532313!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8654 invoked from network); 13 Feb 2012 11:57:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 11:57:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181479634"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 06:57:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 06:57:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DBvXlv024041;	Mon, 13 Feb 2012 03:57:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3bb05b667dece86eff10635ab637e704812e5d77
Message-ID: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 11:57:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: tim@xen.org, stefano.stabellini@citrix.com
Subject: [Xen-devel] [PATCH] MAINTAINERS: Add entry for ARM w/ virt
	extensions port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329134225 0
# Node ID 3bb05b667dece86eff10635ab637e704812e5d77
# Parent  fb71a97fe339282965d584663236ce71a2400659
MAINTAINERS: Add entry for ARM w/ virt extensions port

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r fb71a97fe339 -r 3bb05b667dec MAINTAINERS
--- a/MAINTAINERS	Thu Feb 09 15:32:50 2012 +0000
+++ b/MAINTAINERS	Mon Feb 13 11:57:05 2012 +0000
@@ -97,6 +97,15 @@ M:	Wei Huang <wei.huang2@amd.com>
 S:	Supported
 F:	xen/arch/x86/hvm/svm/
 
+ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
+M:	Ian Campbell <ian.campbell@citrix.com>
+M:	Stefano Stabellini <stefano.stabellini@citrix.com>
+M:	Tim Deegan <tim@xen.org>
+S:	Supported
+L:	xen-devel@lists.xensource.com
+F:	xen/arch/arm/
+F:	xen/include/asm-arm/
+
 CPU POOLS
 M:	Juergen Gross <juergen.gross@ts.fujitsu.com>
 S:	Supported

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:59:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuZV-0007WF-Aa; Mon, 13 Feb 2012 11:59:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwuZQ-0007VX-PS
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:59:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329134382!8477555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21490 invoked from network); 13 Feb 2012 11:59:42 -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;
	13 Feb 2012 11:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10660049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:59:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:59:42 +0000
Date: Mon, 13 Feb 2012 12:03:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202131203340.7456@kaball-desktop>
References: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Add entry for ARM w/ virt
	extensions port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329134225 0
> # Node ID 3bb05b667dece86eff10635ab637e704812e5d77
> # Parent  fb71a97fe339282965d584663236ce71a2400659
> MAINTAINERS: Add entry for ARM w/ virt extensions port
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

ack

> diff -r fb71a97fe339 -r 3bb05b667dec MAINTAINERS
> --- a/MAINTAINERS	Thu Feb 09 15:32:50 2012 +0000
> +++ b/MAINTAINERS	Mon Feb 13 11:57:05 2012 +0000
> @@ -97,6 +97,15 @@ M:	Wei Huang <wei.huang2@amd.com>
>  S:	Supported
>  F:	xen/arch/x86/hvm/svm/
>  
> +ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
> +M:	Ian Campbell <ian.campbell@citrix.com>
> +M:	Stefano Stabellini <stefano.stabellini@citrix.com>
> +M:	Tim Deegan <tim@xen.org>
> +S:	Supported
> +L:	xen-devel@lists.xensource.com
> +F:	xen/arch/arm/
> +F:	xen/include/asm-arm/
> +
>  CPU POOLS
>  M:	Juergen Gross <juergen.gross@ts.fujitsu.com>
>  S:	Supported
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 11:59:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 11:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuZV-0007WF-Aa; Mon, 13 Feb 2012 11:59:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwuZQ-0007VX-PS
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 11:59:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329134382!8477555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21490 invoked from network); 13 Feb 2012 11:59:42 -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;
	13 Feb 2012 11:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="10660049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:59:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:59:42 +0000
Date: Mon, 13 Feb 2012 12:03:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202131203340.7456@kaball-desktop>
References: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Add entry for ARM w/ virt
	extensions port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329134225 0
> # Node ID 3bb05b667dece86eff10635ab637e704812e5d77
> # Parent  fb71a97fe339282965d584663236ce71a2400659
> MAINTAINERS: Add entry for ARM w/ virt extensions port
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

ack

> diff -r fb71a97fe339 -r 3bb05b667dec MAINTAINERS
> --- a/MAINTAINERS	Thu Feb 09 15:32:50 2012 +0000
> +++ b/MAINTAINERS	Mon Feb 13 11:57:05 2012 +0000
> @@ -97,6 +97,15 @@ M:	Wei Huang <wei.huang2@amd.com>
>  S:	Supported
>  F:	xen/arch/x86/hvm/svm/
>  
> +ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
> +M:	Ian Campbell <ian.campbell@citrix.com>
> +M:	Stefano Stabellini <stefano.stabellini@citrix.com>
> +M:	Tim Deegan <tim@xen.org>
> +S:	Supported
> +L:	xen-devel@lists.xensource.com
> +F:	xen/arch/arm/
> +F:	xen/include/asm-arm/
> +
>  CPU POOLS
>  M:	Juergen Gross <juergen.gross@ts.fujitsu.com>
>  S:	Supported
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:03:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwudI-00082q-5F; Mon, 13 Feb 2012 12:03:48 +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 1RwudG-00082b-NN
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:03:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329134601!52661467!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24305 invoked from network); 13 Feb 2012 12:03:22 -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; 13 Feb 2012 12:03:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwudE-000NZ3-Dr; Mon, 13 Feb 2012 12:03:44 +0000
Date: Mon, 13 Feb 2012 12:03:44 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120213120344.GE88765@ocelot.phlegethon.org>
References: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202131203340.7456@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202131203340.7456@kaball-desktop>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Add entry for ARM w/ virt
	extensions port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:03 +0000 on 13 Feb (1329134621), Stefano Stabellini wrote:
> On Mon, 13 Feb 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1329134225 0
> > # Node ID 3bb05b667dece86eff10635ab637e704812e5d77
> > # Parent  fb71a97fe339282965d584663236ce71a2400659
> > MAINTAINERS: Add entry for ARM w/ virt extensions port
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ack

ack too

> > diff -r fb71a97fe339 -r 3bb05b667dec MAINTAINERS
> > --- a/MAINTAINERS	Thu Feb 09 15:32:50 2012 +0000
> > +++ b/MAINTAINERS	Mon Feb 13 11:57:05 2012 +0000
> > @@ -97,6 +97,15 @@ M:	Wei Huang <wei.huang2@amd.com>
> >  S:	Supported
> >  F:	xen/arch/x86/hvm/svm/
> >  
> > +ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
> > +M:	Ian Campbell <ian.campbell@citrix.com>
> > +M:	Stefano Stabellini <stefano.stabellini@citrix.com>
> > +M:	Tim Deegan <tim@xen.org>
> > +S:	Supported
> > +L:	xen-devel@lists.xensource.com
> > +F:	xen/arch/arm/
> > +F:	xen/include/asm-arm/
> > +
> >  CPU POOLS
> >  M:	Juergen Gross <juergen.gross@ts.fujitsu.com>
> >  S:	Supported
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:03:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwudI-00082q-5F; Mon, 13 Feb 2012 12:03:48 +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 1RwudG-00082b-NN
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:03:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329134601!52661467!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24305 invoked from network); 13 Feb 2012 12:03:22 -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; 13 Feb 2012 12:03:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RwudE-000NZ3-Dr; Mon, 13 Feb 2012 12:03:44 +0000
Date: Mon, 13 Feb 2012 12:03:44 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120213120344.GE88765@ocelot.phlegethon.org>
References: <3bb05b667dece86eff10.1329134253@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1202131203340.7456@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202131203340.7456@kaball-desktop>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Add entry for ARM w/ virt
	extensions port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:03 +0000 on 13 Feb (1329134621), Stefano Stabellini wrote:
> On Mon, 13 Feb 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1329134225 0
> > # Node ID 3bb05b667dece86eff10635ab637e704812e5d77
> > # Parent  fb71a97fe339282965d584663236ce71a2400659
> > MAINTAINERS: Add entry for ARM w/ virt extensions port
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ack

ack too

> > diff -r fb71a97fe339 -r 3bb05b667dec MAINTAINERS
> > --- a/MAINTAINERS	Thu Feb 09 15:32:50 2012 +0000
> > +++ b/MAINTAINERS	Mon Feb 13 11:57:05 2012 +0000
> > @@ -97,6 +97,15 @@ M:	Wei Huang <wei.huang2@amd.com>
> >  S:	Supported
> >  F:	xen/arch/x86/hvm/svm/
> >  
> > +ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
> > +M:	Ian Campbell <ian.campbell@citrix.com>
> > +M:	Stefano Stabellini <stefano.stabellini@citrix.com>
> > +M:	Tim Deegan <tim@xen.org>
> > +S:	Supported
> > +L:	xen-devel@lists.xensource.com
> > +F:	xen/arch/arm/
> > +F:	xen/include/asm-arm/
> > +
> >  CPU POOLS
> >  M:	Juergen Gross <juergen.gross@ts.fujitsu.com>
> >  S:	Supported
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:04:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:04:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwue9-00089W-K4; Mon, 13 Feb 2012 12:04:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwue8-00088r-K1
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:04:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329134651!65592138!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27212 invoked from network); 13 Feb 2012 12:04: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 12:04:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 12:04:34 +0000
Message-Id: <4F390A5B02000078000728E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 12:04:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
	<1329132778.31256.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329132778.31256.61.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 12:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-13 at 11:29 +0000, Jan Beulich wrote:
>> >>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > hypervisor, blockers:
>> >       * round-up of the closing of the security hole in MSI-X
>> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>> >         access to MSI-X table pages). (Jan Beulich -- more fixes
>> >         required than first thought, patches posted)
>> 
>> The only one currently open is the one removing write permission for
>> Dom0.
> 
> Oh, I thought you had found another issue which required further
> patches. Did I misunderstand or did they go in already?

They went in already.

>>  The intention was to get this in after the qemu usptream pass
>> through patch series got adjusted along the lines of what was done
>> to qemu traditional, and while this was promise to happen soon after
>> New Year I didn't hear back anything from Anthony or Stefano.
>> 
>> Question is whether, given that the patch series in question isn't in
>> anything that is or will soon be released, it makes sense to push the
>> hypervisor change without waiting for that fixup.
> 
> I don't think it is necessary to wait for the qemu-upstream patch series
> to be updated for this, is it?

Let's wait at least a day or two to give Stefano and Anthony a chance
to respond.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:04:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:04:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwue9-00089W-K4; Mon, 13 Feb 2012 12:04:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rwue8-00088r-K1
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:04:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329134651!65592138!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27212 invoked from network); 13 Feb 2012 12:04: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 12:04:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 13 Feb 2012 12:04:34 +0000
Message-Id: <4F390A5B02000078000728E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 13 Feb 2012 12:04:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
	<1329132778.31256.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329132778.31256.61.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 12:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-13 at 11:29 +0000, Jan Beulich wrote:
>> >>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > hypervisor, blockers:
>> >       * round-up of the closing of the security hole in MSI-X
>> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>> >         access to MSI-X table pages). (Jan Beulich -- more fixes
>> >         required than first thought, patches posted)
>> 
>> The only one currently open is the one removing write permission for
>> Dom0.
> 
> Oh, I thought you had found another issue which required further
> patches. Did I misunderstand or did they go in already?

They went in already.

>>  The intention was to get this in after the qemu usptream pass
>> through patch series got adjusted along the lines of what was done
>> to qemu traditional, and while this was promise to happen soon after
>> New Year I didn't hear back anything from Anthony or Stefano.
>> 
>> Question is whether, given that the patch series in question isn't in
>> anything that is or will soon be released, it makes sense to push the
>> hypervisor change without waiting for that fixup.
> 
> I don't think it is necessary to wait for the qemu-upstream patch series
> to be updated for this, is it?

Let's wait at least a day or two to give Stefano and Anthony a chance
to respond.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:12:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwulG-00005a-Me; Mon, 13 Feb 2012 12:12:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwulE-00005T-Od
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:12:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329135114!12968279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16812 invoked from network); 13 Feb 2012 12:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:11:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:11:54 +0000
Message-ID: <1329135113.31256.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hongkaixing <hongkaixing@huawei.com>
Date: Mon, 13 Feb 2012 12:11:53 +0000
In-Reply-To: <002201ccea12$e83c0420$b8b40c60$@com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	'Olaf Hering' <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 05:47 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Sent: Saturday, February 11, 2012 12:40 AM
> > To: hongkaixing@huawei.com
> > Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> > hanweidong@huawei.com
> > Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> > 
> > On Thu, Feb 09, hongkaixing@huawei.com wrote:
> > 
> > > xenpaging:close domU's event channel and free port
> > >
> > > Every domain (X86 64 bit)has 4096 event channels.In source code,
> > > domU's event channel is allocated in mem_event_enable(),but just
> > > unbind dom0's event channel in xenpaging_teardown().This bug will
> > > result in that we can not use xenpaging after reopening it for 4096
> > > times.We should free domU's event channel in mem_event_disable().so
> > > that we can reuse the port.
> > 
> > Does that fix a real bug?
> > 
> > xenpaging_teardown() does both xc_mem_paging_disable() and
> > xc_evtchn_unbind(). The former fails often because the domain is gone
> > and so it doesnt even reach the function in mem_event.c.
> > The latter is called unconditionally.
> 
>    I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
> Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
> and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.

Perhaps I'm misunderstanding something and/or showing my ignorance about
how xenpaging works but why does paging need a domU event channel
anyway? Surely paging is transparent to the guest.

Or is this really a dom0<->Xen event channel which just appears to be
assigned to the guest?

Who assigns this remote domain port? Shouldn't it either be closed when
the dom0 end is closed or retained such that it can be reused each time
instead of leaking?

> so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
> (28 = No space left on device): Internal error".Because there is no available free port for this domU.
> Only the port's state is ECS_FREE,then it can be allocated by get_free_port();
> 
> 
> > 
> > Also I would expect that once xenpaging exits the kernel driver does a
> > cleanup of all used ports. I havent checked wether thats true.
> > 
> > Olaf
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:12:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwulG-00005a-Me; Mon, 13 Feb 2012 12:12:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwulE-00005T-Od
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:12:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329135114!12968279!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16812 invoked from network); 13 Feb 2012 12:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:11:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:11:54 +0000
Message-ID: <1329135113.31256.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hongkaixing <hongkaixing@huawei.com>
Date: Mon, 13 Feb 2012 12:11:53 +0000
In-Reply-To: <002201ccea12$e83c0420$b8b40c60$@com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	'Olaf Hering' <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 05:47 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Sent: Saturday, February 11, 2012 12:40 AM
> > To: hongkaixing@huawei.com
> > Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> > hanweidong@huawei.com
> > Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> > 
> > On Thu, Feb 09, hongkaixing@huawei.com wrote:
> > 
> > > xenpaging:close domU's event channel and free port
> > >
> > > Every domain (X86 64 bit)has 4096 event channels.In source code,
> > > domU's event channel is allocated in mem_event_enable(),but just
> > > unbind dom0's event channel in xenpaging_teardown().This bug will
> > > result in that we can not use xenpaging after reopening it for 4096
> > > times.We should free domU's event channel in mem_event_disable().so
> > > that we can reuse the port.
> > 
> > Does that fix a real bug?
> > 
> > xenpaging_teardown() does both xc_mem_paging_disable() and
> > xc_evtchn_unbind(). The former fails often because the domain is gone
> > and so it doesnt even reach the function in mem_event.c.
> > The latter is called unconditionally.
> 
>    I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
> Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
> and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.

Perhaps I'm misunderstanding something and/or showing my ignorance about
how xenpaging works but why does paging need a domU event channel
anyway? Surely paging is transparent to the guest.

Or is this really a dom0<->Xen event channel which just appears to be
assigned to the guest?

Who assigns this remote domain port? Shouldn't it either be closed when
the dom0 end is closed or retained such that it can be reused each time
instead of leaking?

> so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
> (28 = No space left on device): Internal error".Because there is no available free port for this domU.
> Only the port's state is ECS_FREE,then it can be allocated by get_free_port();
> 
> 
> > 
> > Also I would expect that once xenpaging exits the kernel driver does a
> > cleanup of all used ports. I havent checked wether thats true.
> > 
> > Olaf
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:14:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwunS-0000Cf-HE; Mon, 13 Feb 2012 12:14:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwunR-0000CV-Hy
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:14:17 +0000
Received: from [85.158.139.83:58515] by server-8.bemta-5.messagelabs.com id
	F0/5A-08951-89EF83F4; Mon, 13 Feb 2012 12:14:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329135255!14855777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30786 invoked from network); 13 Feb 2012 12:14:16 -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;
	13 Feb 2012 12:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:14:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 12:14:15 +0000
Date: Mon, 13 Feb 2012 12:18:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F390A5B02000078000728E9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1202131216060.7456@kaball-desktop>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
	<1329132778.31256.61.camel@zakaz.uk.xensource.com>
	<4F390A5B02000078000728E9@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Jan Beulich wrote:
> >>  The intention was to get this in after the qemu usptream pass
> >> through patch series got adjusted along the lines of what was done
> >> to qemu traditional, and while this was promise to happen soon after
> >> New Year I didn't hear back anything from Anthony or Stefano.
> >> 
> >> Question is whether, given that the patch series in question isn't in
> >> anything that is or will soon be released, it makes sense to push the
> >> hypervisor change without waiting for that fixup.
> > 
> > I don't think it is necessary to wait for the qemu-upstream patch series
> > to be updated for this, is it?
> 
> Let's wait at least a day or two to give Stefano and Anthony a chance
> to respond.

I don't think we need to wait for the upstream PCI passthrough series to
be accepted in order for the hypervisor changes to go in, however it
would be nice if you could point out what needs to be changed on the
QEMU side, when Anthony posts the next version of the series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:14:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwunS-0000Cf-HE; Mon, 13 Feb 2012 12:14:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RwunR-0000CV-Hy
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:14:17 +0000
Received: from [85.158.139.83:58515] by server-8.bemta-5.messagelabs.com id
	F0/5A-08951-89EF83F4; Mon, 13 Feb 2012 12:14:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329135255!14855777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30786 invoked from network); 13 Feb 2012 12:14:16 -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;
	13 Feb 2012 12:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:14:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 12:14:15 +0000
Date: Mon, 13 Feb 2012 12:18:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F390A5B02000078000728E9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1202131216060.7456@kaball-desktop>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
	<1329132778.31256.61.camel@zakaz.uk.xensource.com>
	<4F390A5B02000078000728E9@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Jan Beulich wrote:
> >>  The intention was to get this in after the qemu usptream pass
> >> through patch series got adjusted along the lines of what was done
> >> to qemu traditional, and while this was promise to happen soon after
> >> New Year I didn't hear back anything from Anthony or Stefano.
> >> 
> >> Question is whether, given that the patch series in question isn't in
> >> anything that is or will soon be released, it makes sense to push the
> >> hypervisor change without waiting for that fixup.
> > 
> > I don't think it is necessary to wait for the qemu-upstream patch series
> > to be updated for this, is it?
> 
> Let's wait at least a day or two to give Stefano and Anthony a chance
> to respond.

I don't think we need to wait for the upstream PCI passthrough series to
be accepted in order for the hypervisor changes to go in, however it
would be nice if you could point out what needs to be changed on the
QEMU side, when Anthony posts the next version of the series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:16:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwupu-0000OD-2q; Mon, 13 Feb 2012 12:16:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rwups-0000NC-8z
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:16:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329135398!11143362!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12679 invoked from network); 13 Feb 2012 12:16:38 -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;
	13 Feb 2012 12:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:16:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 12:16:38 +0000
Date: Mon, 13 Feb 2012 12:20:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1202131220310.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
	<alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Stefano Stabellini wrote:
> On Wed, 25 Jan 2012, Stefano Stabellini wrote:
> > Hi all,
> > this is the fourth version of the Xen save/restore patch series.
> > We have been discussing this issue for quite a while on #qemu and
> > qemu-devel:
> > 
> > 
> > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> > 
> > 
> > The principal changes in the this version are:
> > 
> > - Following Anthony's suggestion I have introduced a new monitor command
> > to save the non-ram device state to file.
> > 
> > - I have also removed the hack not to reset the cirrus videoram on
> > restore, because it turns out that the videoram doesn't need to be
> > reset in the reset handler at all (tested on Win2K, where the problem
> > was found in the first place).
> > 
> 
> Is everybody happy enough with this series?
> Do you have any additional comments?
> 

ping

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:16:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwupu-0000OD-2q; Mon, 13 Feb 2012 12:16:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rwups-0000NC-8z
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:16:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329135398!11143362!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12679 invoked from network); 13 Feb 2012 12:16:38 -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;
	13 Feb 2012 12:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:16:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 12:16:38 +0000
Date: Mon, 13 Feb 2012 12:20:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1202131220310.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
	<alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Stefano Stabellini wrote:
> On Wed, 25 Jan 2012, Stefano Stabellini wrote:
> > Hi all,
> > this is the fourth version of the Xen save/restore patch series.
> > We have been discussing this issue for quite a while on #qemu and
> > qemu-devel:
> > 
> > 
> > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> > 
> > 
> > The principal changes in the this version are:
> > 
> > - Following Anthony's suggestion I have introduced a new monitor command
> > to save the non-ram device state to file.
> > 
> > - I have also removed the hack not to reset the cirrus videoram on
> > restore, because it turns out that the videoram doesn't need to be
> > reset in the reset handler at all (tested on Win2K, where the problem
> > was found in the first place).
> > 
> 
> Is everybody happy enough with this series?
> Do you have any additional comments?
> 

ping

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwutS-0000g7-Qq; Mon, 13 Feb 2012 12:20:30 +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 1RwutQ-0000fq-U0
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:29 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16808 invoked from network); 13 Feb 2012 12:19:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482094"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:22 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGE024577;	Mon, 13 Feb 2012 04:20:21 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:03 +0000
Message-ID: <1329135613-26061-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 01/11] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..943106a 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwutS-0000g7-Qq; Mon, 13 Feb 2012 12:20:30 +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 1RwutQ-0000fq-U0
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:29 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16808 invoked from network); 13 Feb 2012 12:19:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482094"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:22 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGE024577;	Mon, 13 Feb 2012 04:20:21 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:03 +0000
Message-ID: <1329135613-26061-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 01/11] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..943106a 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutZ-0000i1-II; Mon, 13 Feb 2012 12:20:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwutV-0000fv-Bk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 13 Feb 2012 12:20:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891160"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:26 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGH024577;	Mon, 13 Feb 2012 04:20:25 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:06 +0000
Message-ID: <1329135613-26061-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 04/11] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 763db24..0787992 100755
--- a/configure
+++ b/configure
@@ -132,6 +132,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -657,6 +658,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1005,6 +1010,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1458,6 +1465,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3592,6 +3614,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutZ-0000i1-II; Mon, 13 Feb 2012 12:20:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwutV-0000fv-Bk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 13 Feb 2012 12:20:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891160"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:26 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGH024577;	Mon, 13 Feb 2012 04:20:25 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:06 +0000
Message-ID: <1329135613-26061-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 04/11] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 763db24..0787992 100755
--- a/configure
+++ b/configure
@@ -132,6 +132,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -657,6 +658,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1005,6 +1010,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1458,6 +1465,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3592,6 +3614,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutX-0000h7-3h; Mon, 13 Feb 2012 12:20:35 +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 1RwutS-0000fs-L1
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:30 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16906 invoked from network); 13 Feb 2012 12:19:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482100"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:25 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGG024577;	Mon, 13 Feb 2012 04:20:24 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:05 +0000
Message-ID: <1329135613-26061-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 03/11] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutX-0000hc-VS; Mon, 13 Feb 2012 12:20:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwutV-0000fu-5u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9939 invoked from network); 13 Feb 2012 12:20:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891159"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:24 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGF024577;	Mon, 13 Feb 2012 04:20:22 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:04 +0000
Message-ID: <1329135613-26061-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 02/11] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutX-0000h7-3h; Mon, 13 Feb 2012 12:20:35 +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 1RwutS-0000fs-L1
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:30 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16906 invoked from network); 13 Feb 2012 12:19:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482100"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:25 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGG024577;	Mon, 13 Feb 2012 04:20:24 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:05 +0000
Message-ID: <1329135613-26061-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 03/11] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutX-0000hc-VS; Mon, 13 Feb 2012 12:20:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwutV-0000fu-5u
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9939 invoked from network); 13 Feb 2012 12:20:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891159"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:24 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGF024577;	Mon, 13 Feb 2012 04:20:22 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:04 +0000
Message-ID: <1329135613-26061-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 02/11] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutU-0000gJ-5b; Mon, 13 Feb 2012 12:20:32 +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 1RwutR-0000g2-Qy
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:30 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17056 invoked from network); 13 Feb 2012 12:19:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482105"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:27 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGI024577;	Mon, 13 Feb 2012 04:20:26 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:07 +0000
Message-ID: <1329135613-26061-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 05/11] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 68481a3..92f375b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -216,6 +216,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 1);
+    if (rc == 0) {
+        *p = buf;
+    }
+    return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 2);
+    if (rc == 0) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 4);
+    if (rc == 0) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+    return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwutU-0000gJ-5b; Mon, 13 Feb 2012 12:20:32 +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 1RwutR-0000g2-Qy
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:30 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17056 invoked from network); 13 Feb 2012 12:19:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482105"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:27 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGI024577;	Mon, 13 Feb 2012 04:20:26 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:07 +0000
Message-ID: <1329135613-26061-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 05/11] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 68481a3..92f375b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -216,6 +216,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 1);
+    if (rc == 0) {
+        *p = buf;
+    }
+    return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 2);
+    if (rc == 0) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 4);
+    if (rc == 0) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+    return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwuta-0000iW-T9; Mon, 13 Feb 2012 12:20:39 +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 1RwutW-0000h1-UX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:35 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17310 invoked from network); 13 Feb 2012 12:19:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482124"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:31 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGK024577;	Mon, 13 Feb 2012 04:20:29 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:09 +0000
Message-ID: <1329135613-26061-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 07/11] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  814 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  263 +++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1105 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 92f375b..8fc2ca3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -218,6 +218,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..4ab1218
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,814 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+uint8_t mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0-Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (addr & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, addr, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#"PRIx64" maddr=%#"PRIx64
+           " len=%#"PRIx64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.maddr, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#04"PRIx64" pio_base=%#04"PRIx64
+           " len=%"PRId64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.pio_base, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_ADD_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &d->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+        return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = pci_get_bar_addr(d, bar);
+
+    /* need unmapping in case I/O Space or Memory Space is disabled */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    /* or ROM address is disabled. */
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(d, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as bar_read function */
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].e_physbase = r->base_addr;
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->flags & IORESOURCE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->flags & IORESOURCE_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]);
+
+        PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64" type: %#x)\n",
+               i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type & PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                          s->bases[i].e_physbase,
+                                          s->bases[i].access.pio_base,
+                                          e_size,
+                                          DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        } else {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, d->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+           bus, slot, func);
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            PT_ERR(d, "unbinding of interrupt INT%c failed."
+                   " (machine irq: %i, rc: %d)"
+                   " But bravely continuing on..\n",
+                   'a' + intx, rc, machine_irq);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                       " But bravely continuing on..\n",
+                       machine_irq, rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pt_initfn;
+    k->exit = pt_unregister_device;
+    k->config_read = pt_pci_read_config;
+    k->config_write = pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+device_init(xen_pci_passthrough_register);
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..7a609b5
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,263 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+typedef int (*conf_dword_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint32_t dev_value, uint32_t *val);
+typedef int (*conf_word_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint16_t dev_value, uint16_t *val);
+typedef int (*conf_byte_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint8_t dev_value, uint8_t *val);
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write/restore function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+            conf_dword_restore restore;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+            conf_word_restore restore;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+            conf_byte_restore restore;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index fd39168..e83ba2b 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1013,3 +1013,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwuta-0000iW-T9; Mon, 13 Feb 2012 12:20:39 +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 1RwutW-0000h1-UX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:35 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17310 invoked from network); 13 Feb 2012 12:19:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482124"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:31 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGK024577;	Mon, 13 Feb 2012 04:20:29 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:09 +0000
Message-ID: <1329135613-26061-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 07/11] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  814 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  263 +++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1105 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 92f375b..8fc2ca3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -218,6 +218,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..4ab1218
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,814 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+uint8_t mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0-Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (addr & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, addr, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#"PRIx64" maddr=%#"PRIx64
+           " len=%#"PRIx64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.maddr, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#04"PRIx64" pio_base=%#04"PRIx64
+           " len=%"PRId64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.pio_base, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_ADD_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &d->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+        return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = pci_get_bar_addr(d, bar);
+
+    /* need unmapping in case I/O Space or Memory Space is disabled */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    /* or ROM address is disabled. */
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(d, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as bar_read function */
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].e_physbase = r->base_addr;
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->flags & IORESOURCE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->flags & IORESOURCE_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]);
+
+        PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64" type: %#x)\n",
+               i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type & PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                          s->bases[i].e_physbase,
+                                          s->bases[i].access.pio_base,
+                                          e_size,
+                                          DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        } else {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, d->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+           bus, slot, func);
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            PT_ERR(d, "unbinding of interrupt INT%c failed."
+                   " (machine irq: %i, rc: %d)"
+                   " But bravely continuing on..\n",
+                   'a' + intx, rc, machine_irq);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                       " But bravely continuing on..\n",
+                       machine_irq, rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pt_initfn;
+    k->exit = pt_unregister_device;
+    k->config_read = pt_pci_read_config;
+    k->config_write = pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+device_init(xen_pci_passthrough_register);
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..7a609b5
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,263 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+typedef int (*conf_dword_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint32_t dev_value, uint32_t *val);
+typedef int (*conf_word_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint16_t dev_value, uint16_t *val);
+typedef int (*conf_byte_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint8_t dev_value, uint8_t *val);
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write/restore function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+            conf_dword_restore restore;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+            conf_word_restore restore;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+            conf_byte_restore restore;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index fd39168..e83ba2b 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1013,3 +1013,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwute-0000kJ-5N; Mon, 13 Feb 2012 12:20:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwutZ-0000gM-HS
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:37 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10498 invoked from network); 13 Feb 2012 12:20:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891161"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:29 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGJ024577;	Mon, 13 Feb 2012 04:20:27 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:08 +0000
Message-ID: <1329135613-26061-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 06/11] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function helps Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 5f4f80e..ebb5de9 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1985,6 +1985,53 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
     return dev->bus->address_space_io;
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type & PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type & PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
+
 static void pci_device_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/hw/pci.h b/hw/pci.h
index 33b0b18..f05fda5 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -566,4 +566,7 @@ extern const VMStateDescription vmstate_pci_device;
     .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwute-0000kJ-5N; Mon, 13 Feb 2012 12:20:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwutZ-0000gM-HS
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:37 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10498 invoked from network); 13 Feb 2012 12:20:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891161"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:29 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGJ024577;	Mon, 13 Feb 2012 04:20:27 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:08 +0000
Message-ID: <1329135613-26061-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 06/11] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function helps Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 5f4f80e..ebb5de9 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1985,6 +1985,53 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
     return dev->bus->address_space_io;
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type & PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type & PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
+
 static void pci_device_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/hw/pci.h b/hw/pci.h
index 33b0b18..f05fda5 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -566,4 +566,7 @@ extern const VMStateDescription vmstate_pci_device;
     .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwutf-0000ma-Q4; Mon, 13 Feb 2012 12:20:43 +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 1Rwutb-0000hQ-9O
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20843 invoked from network); 13 Feb 2012 12:19:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482125"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:33 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGL024577;	Mon, 13 Feb 2012 04:20:31 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:10 +0000
Message-ID: <1329135613-26061-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 08/11] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   10 +
 hw/xen_pci_passthrough.h             |    2 +
 hw/xen_pci_passthrough_config_init.c | 1481 ++++++++++++++++++++++++++++++++++
 3 files changed, 1493 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 4ab1218..bdc3690 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(d, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(d, "no pin interrupt\n");
@@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 7a609b5..0b9902d 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -70,6 +70,8 @@ typedef int (*conf_byte_restore)
 #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
 #define PT_PCI_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..2fb27ff 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,1492 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* common restore register fonctions */
+static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint8_t dev_value,
+                               uint8_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_byte(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint16_t dev_value,
+                               uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint16_t dev_value,
+                              uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t restorable_mask = 0;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring the I/O device register
+     * but do not include Fast Back-to-Back Enable bit.
+     */
+    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
+    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
+
+    if (!s->machine_irq) {
+        *value |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        *value &= ~PCI_COMMAND_INTX_DISABLE;
+    }
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint32_t dev_value,
+                              uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t bar_emu_mask = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use value from kernel sysfs */
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
+        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
+    } else {
+        *value = base_address_with_flags(&s->real_device->io_regions[index]);
+    }
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+/* restore ROM BAR */
+static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t real_offset,
+                                      uint32_t dev_value, uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t v;
+
+    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
+        return -1;
+    }
+    /* use value from kernel sysfs */
+    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+        .u.w.restore  = pt_cmd_reg_restore,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+        .u.dw.restore = pt_exp_rom_bar_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                int j = 0;
+                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwutf-0000ma-Q4; Mon, 13 Feb 2012 12:20:43 +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 1Rwutb-0000hQ-9O
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20843 invoked from network); 13 Feb 2012 12:19:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482125"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:33 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGL024577;	Mon, 13 Feb 2012 04:20:31 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:10 +0000
Message-ID: <1329135613-26061-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 08/11] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   10 +
 hw/xen_pci_passthrough.h             |    2 +
 hw/xen_pci_passthrough_config_init.c | 1481 ++++++++++++++++++++++++++++++++++
 3 files changed, 1493 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 4ab1218..bdc3690 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(d, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(d, "no pin interrupt\n");
@@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 7a609b5..0b9902d 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -70,6 +70,8 @@ typedef int (*conf_byte_restore)
 #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
 #define PT_PCI_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..2fb27ff 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,1492 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* common restore register fonctions */
+static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint8_t dev_value,
+                               uint8_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_byte(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint16_t dev_value,
+                               uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint16_t dev_value,
+                              uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t restorable_mask = 0;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring the I/O device register
+     * but do not include Fast Back-to-Back Enable bit.
+     */
+    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
+    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
+
+    if (!s->machine_irq) {
+        *value |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        *value &= ~PCI_COMMAND_INTX_DISABLE;
+    }
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint32_t dev_value,
+                              uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t bar_emu_mask = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use value from kernel sysfs */
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
+        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
+    } else {
+        *value = base_address_with_flags(&s->real_device->io_regions[index]);
+    }
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+/* restore ROM BAR */
+static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t real_offset,
+                                      uint32_t dev_value, uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t v;
+
+    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
+        return -1;
+    }
+    /* use value from kernel sysfs */
+    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+        .u.w.restore  = pt_cmd_reg_restore,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+        .u.dw.restore = pt_exp_rom_bar_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                int j = 0;
+                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwutn-0000t7-1T; Mon, 13 Feb 2012 12:20:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rwutl-0000mo-8E
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11205 invoked from network); 13 Feb 2012 12:20:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891165"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:38 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGO024577;	Mon, 13 Feb 2012 04:20:36 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:13 +0000
Message-ID: <1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 11/11] pci: Do not check if a bus exist in
	pci_parse_devaddr.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
this should be the jobs of a caller. In fact, the two callers of this function
will try to retrieve the PCIBus related to the devaddr and return an error if
they cannot.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index ebb5de9..da7cf79 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -529,10 +529,6 @@ int pci_parse_devaddr(const char *addr, int *domp, int *busp,
     if (*e)
 	return -1;
 
-    /* Note: QEMU doesn't implement domains other than 0 */
-    if (!pci_find_bus(pci_find_root_bus(dom), bus))
-	return -1;
-
     *domp = dom;
     *busp = bus;
     *slotp = slot;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwutn-0000t7-1T; Mon, 13 Feb 2012 12:20:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rwutl-0000mo-8E
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11205 invoked from network); 13 Feb 2012 12:20:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891165"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:38 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGO024577;	Mon, 13 Feb 2012 04:20:36 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:13 +0000
Message-ID: <1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 11/11] pci: Do not check if a bus exist in
	pci_parse_devaddr.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
this should be the jobs of a caller. In fact, the two callers of this function
will try to retrieve the PCIBus related to the devaddr and return an error if
they cannot.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index ebb5de9..da7cf79 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -529,10 +529,6 @@ int pci_parse_devaddr(const char *addr, int *domp, int *busp,
     if (*e)
 	return -1;
 
-    /* Note: QEMU doesn't implement domains other than 0 */
-    if (!pci_find_bus(pci_find_root_bus(dom), bus))
-	return -1;
-
     *domp = dom;
     *busp = bus;
     *slotp = slot;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwutm-0000s2-1y; Mon, 13 Feb 2012 12:20: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 1Rwutj-0000kC-0Q
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24318 invoked from network); 13 Feb 2012 12:19:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482149"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:36 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGN024577;	Mon, 13 Feb 2012 04:20:35 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:12 +0000
Message-ID: <1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 10/11] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   32 ++
 hw/xen_pci_passthrough.h             |   48 +++
 hw/xen_pci_passthrough_config_init.c |  480 ++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  667 ++++++++++++++++++++++++++++++++++
 6 files changed, 1230 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 8fc2ca3..3517cab 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,6 +220,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index bdc3690..1257ce2 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -362,6 +376,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         rc = xc_domain_memory_mapping(xen_xc, xen_domid,
                                old_ebase >> XC_PAGE_SHIFT,
@@ -386,6 +401,16 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (rc) {
             PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
         }
+
+        rc = pt_remove_msix_mapping(s, i);
+        if (rc != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
+                   rc);
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -766,6 +791,13 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 0b9902d..deeba89 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -174,6 +174,37 @@ typedef struct XenPTRegGroup {
 
 
 #define PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -186,6 +217,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 };
@@ -262,4 +296,18 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 2fb27ff..430c26a 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1125,6 +1125,419 @@ static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            PT_LOG(&s->dev, "setup MSI\n");
+            if (pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *value &= ~PCI_MSI_FLAGS_ENABLE;
+    *value |= val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev,
+               "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        PT_LOG(&s->dev, "%s MSI-X\n",
+               s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1218,6 +1631,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1250,6 +1706,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1294,6 +1758,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1478,6 +1950,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..0b81060
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,667 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    host_pci_set_word(s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int *ppirq,
+                           bool is_msix,
+                           int msix_entry,
+                           bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                   " (vec: %#x, entry: %#x)\n",
+                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                   is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: %#x)\n",
+           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+               is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                   is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+               is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+               is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        PT_ERR(&s->dev,
+               "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
+        + PCI_MSIX_ENTRY_VECTOR_CTRL;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                   "enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr,
+            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    return get_entry_value(&msix->msix_entry[entry_nr], offset);
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, false);
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+           >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+           >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(msix && msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, true);
+
+    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+             >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *hd = s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "passthrough-msix",
+                          total_entries * PCI_MSIX_ENTRY_SIZE);
+
+    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        close(fd);
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    close(fd);
+
+    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
+
+    memory_region_transaction_begin();
+    memory_region_add_subregion_overlap(&s->bar[bar_index], msix->table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+    memory_region_set_enabled(&msix->mmio, false);
+    memory_region_transaction_commit();
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+               msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwutm-0000s2-1y; Mon, 13 Feb 2012 12:20: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 1Rwutj-0000kC-0Q
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329135574!62607881!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24318 invoked from network); 13 Feb 2012 12:19:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181482149"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:36 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGN024577;	Mon, 13 Feb 2012 04:20:35 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:12 +0000
Message-ID: <1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 10/11] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   32 ++
 hw/xen_pci_passthrough.h             |   48 +++
 hw/xen_pci_passthrough_config_init.c |  480 ++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  667 ++++++++++++++++++++++++++++++++++
 6 files changed, 1230 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 8fc2ca3..3517cab 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,6 +220,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index bdc3690..1257ce2 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -362,6 +376,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         rc = xc_domain_memory_mapping(xen_xc, xen_domid,
                                old_ebase >> XC_PAGE_SHIFT,
@@ -386,6 +401,16 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (rc) {
             PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
         }
+
+        rc = pt_remove_msix_mapping(s, i);
+        if (rc != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
+                   rc);
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -766,6 +791,13 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 0b9902d..deeba89 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -174,6 +174,37 @@ typedef struct XenPTRegGroup {
 
 
 #define PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -186,6 +217,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 };
@@ -262,4 +296,18 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 2fb27ff..430c26a 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1125,6 +1125,419 @@ static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            PT_LOG(&s->dev, "setup MSI\n");
+            if (pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *value &= ~PCI_MSI_FLAGS_ENABLE;
+    *value |= val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev,
+               "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        PT_LOG(&s->dev, "%s MSI-X\n",
+               s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1218,6 +1631,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1250,6 +1706,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1294,6 +1758,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1478,6 +1950,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..0b81060
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,667 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    host_pci_set_word(s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int *ppirq,
+                           bool is_msix,
+                           int msix_entry,
+                           bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                   " (vec: %#x, entry: %#x)\n",
+                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                   is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: %#x)\n",
+           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+               is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                   is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+               is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+               is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        PT_ERR(&s->dev,
+               "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
+        + PCI_MSIX_ENTRY_VECTOR_CTRL;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                   "enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr,
+            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    return get_entry_value(&msix->msix_entry[entry_nr], offset);
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, false);
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+           >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+           >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(msix && msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, true);
+
+    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+             >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *hd = s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "passthrough-msix",
+                          total_entries * PCI_MSIX_ENTRY_SIZE);
+
+    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        close(fd);
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    close(fd);
+
+    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
+
+    memory_region_transaction_begin();
+    memory_region_add_subregion_overlap(&s->bar[bar_index], msix->table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+    memory_region_set_enabled(&msix->mmio, false);
+    memory_region_transaction_commit();
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+               msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwutm-0000sa-LI; Mon, 13 Feb 2012 12:20:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rwutl-0000mb-0O
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10952 invoked from network); 13 Feb 2012 12:20:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:35 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGM024577;	Mon, 13 Feb 2012 04:20:33 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:11 +0000
Message-ID: <1329135613-26061-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 09/11] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 086c544..4429927 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 static APICCommonState *local_apics[MAX_APICS + 1];
 
 static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:20:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwutm-0000sa-LI; Mon, 13 Feb 2012 12:20:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rwutl-0000mb-0O
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:20:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329135624!2536927!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10952 invoked from network); 13 Feb 2012 12:20:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:20:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:35 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGM024577;	Mon, 13 Feb 2012 04:20:33 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:11 +0000
Message-ID: <1329135613-26061-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 09/11] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 086c544..4429927 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 static APICCommonState *local_apics[MAX_APICS + 1];
 
 static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuuT-0001La-G8; Mon, 13 Feb 2012 12:21:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwuuS-0001IG-Ld
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:21:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329135685!14031639!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8048 invoked from network); 13 Feb 2012 12:21:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891158"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:21 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGD024577;	Mon, 13 Feb 2012 04:20:20 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:02 +0000
Message-ID: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change since last time:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.


Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property




Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (7):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h
  pci: Do not check if a bus exist in pci_parse_devaddr.

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 +++++
 hw/host-pci-device.h                 |   75 ++
 hw/pci.c                             |   51 +-
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  856 +++++++++++++++
 hw/xen_pci_passthrough.h             |  313 ++++++
 hw/xen_pci_passthrough_config_init.c | 1972 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  667 ++++++++++++
 xen-all.c                            |   12 +
 16 files changed, 4291 insertions(+), 15 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwuuT-0001La-G8; Mon, 13 Feb 2012 12:21:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RwuuS-0001IG-Ld
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:21:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329135685!14031639!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8048 invoked from network); 13 Feb 2012 12:21:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21891158"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 07:20:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 07:20:21 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id q1DCKJGD024577;	Mon, 13 Feb 2012 04:20:20 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Mon, 13 Feb 2012 12:20:02 +0000
Message-ID: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V6 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change since last time:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.


Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property




Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (7):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h
  pci: Do not check if a bus exist in pci_parse_devaddr.

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 +++++
 hw/host-pci-device.h                 |   75 ++
 hw/pci.c                             |   51 +-
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  856 +++++++++++++++
 hw/xen_pci_passthrough.h             |  313 ++++++
 hw/xen_pci_passthrough_config_init.c | 1972 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  667 ++++++++++++
 xen-all.c                            |   12 +
 16 files changed, 4291 insertions(+), 15 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:22:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwuuu-0001a0-UT; Mon, 13 Feb 2012 12:22:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwuut-0001XA-HX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:21:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329135713!13114453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16023 invoked from network); 13 Feb 2012 12:21:53 -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 Feb 2012 12:21:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:21:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:21:53 +0000
Message-ID: <1329135711.31256.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 12:21:51 +0000
In-Reply-To: <1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 02/10] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

When forwarding on other peoples patches please can you remember to
include your own explicit Signed-off-by or Acked-by (I think the former
is generally more appropriate per 2b or 2c of the DCO).

This is particularly important if I am the original author since I don't
want to act as both Ack-er and commit-er of my own patches.

Ian.

> ---
>  xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
>  xen/include/public/hvm/save.h          |    2 +
>  2 files changed, 41 insertions(+), 0 deletions(-)
>  create mode 100644 xen/include/public/arch-arm/hvm/save.h
> 
> diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
> new file mode 100644
> index 0000000..ec61298
> --- /dev/null
> +++ b/xen/include/public/arch-arm/hvm/save.h
> @@ -0,0 +1,39 @@
> +/*
> + * Structure definitions for HVM state that is held by Xen and must
> + * be saved along with the domain's memory and device-model state.
> + *
> + * Copyright (c) 2012 Citrix Systems Ltd.
> + *
> + * 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_HVM_SAVE_ARM_H__
> +#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
> +
> +#endif
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
> index d0f2661..58f8433 100644
> --- a/xen/include/public/hvm/save.h
> +++ b/xen/include/public/hvm/save.h
> @@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
>  #include "../arch-x86/hvm/save.h"
>  #elif defined(__ia64__)
>  #include "../arch-ia64/hvm/save.h"
> +#elif defined(__arm__)
> +#include "../arch-arm/hvm/save.h"
>  #else
>  #error "unsupported architecture"
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:22:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwuuu-0001a0-UT; Mon, 13 Feb 2012 12:22:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwuut-0001XA-HX
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:21:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329135713!13114453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16023 invoked from network); 13 Feb 2012 12:21:53 -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 Feb 2012 12:21:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660675"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:21:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:21:53 +0000
Message-ID: <1329135711.31256.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 12:21:51 +0000
In-Reply-To: <1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 02/10] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

When forwarding on other peoples patches please can you remember to
include your own explicit Signed-off-by or Acked-by (I think the former
is generally more appropriate per 2b or 2c of the DCO).

This is particularly important if I am the original author since I don't
want to act as both Ack-er and commit-er of my own patches.

Ian.

> ---
>  xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
>  xen/include/public/hvm/save.h          |    2 +
>  2 files changed, 41 insertions(+), 0 deletions(-)
>  create mode 100644 xen/include/public/arch-arm/hvm/save.h
> 
> diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
> new file mode 100644
> index 0000000..ec61298
> --- /dev/null
> +++ b/xen/include/public/arch-arm/hvm/save.h
> @@ -0,0 +1,39 @@
> +/*
> + * Structure definitions for HVM state that is held by Xen and must
> + * be saved along with the domain's memory and device-model state.
> + *
> + * Copyright (c) 2012 Citrix Systems Ltd.
> + *
> + * 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_HVM_SAVE_ARM_H__
> +#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
> +
> +#endif
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
> index d0f2661..58f8433 100644
> --- a/xen/include/public/hvm/save.h
> +++ b/xen/include/public/hvm/save.h
> @@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
>  #include "../arch-x86/hvm/save.h"
>  #elif defined(__ia64__)
>  #include "../arch-ia64/hvm/save.h"
> +#elif defined(__arm__)
> +#include "../arch-arm/hvm/save.h"
>  #else
>  #error "unsupported architecture"
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:36:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwv8L-0003P7-Vc; Mon, 13 Feb 2012 12:35: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 1Rwv8J-0003Ow-GH
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:35:52 +0000
Received: from [85.158.139.83:40407] by server-10.bemta-5.messagelabs.com id
	14/F4-26909-6A3093F4; Mon, 13 Feb 2012 12:35:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329136549!14781600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20592 invoked from network); 13 Feb 2012 12:35:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:35:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:35:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:35:49 +0000
Message-ID: <1329136547.31256.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Mon, 13 Feb 2012 12:35:47 +0000
In-Reply-To: <4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:12 +0000, Justin T. Gibbs wrote:
> On Feb 9, 2012, at 2:48 AM, Ian Campbell wrote:
> 
> > On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
> >> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> >> 
> >>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> >>>> @@ -187,6 +216,25 @@
> >>>> *      The machine ABI rules governing the format of all ring request and
> >>>> *      response structures.
> >>>> *
> >>>> + * ring-page-order
> >>>> + *      Values:         <uint32_t>
> >>>> + *      Default Value:  0
> >>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> >>> 
> >>> Why not just max-ring-page-order. After all, the value is meaningless
> >>> for a backend that only exposes max-ring-pages.
> >>> 
> >>>> + *      Notes:          1, 3
> >>>> + *
> >>>> + *      The size of the frontend allocated request ring buffer in units
> >>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> >>>> + *      etc.).
> >>>> + *
> >>>> + * ring-pages
> >>>> + *      Values:         <uint32_t>
> >>>> + *      Default Value:  1
> >>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> >>> 
> >>> Similarly here - just max-ring-pages should do.
> >> 
> >> This patch documents existing extensions.  For a new driver to properly negotiate a
> >> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
> >> you must use the XenBus node names as I've defined them here.
> > 
> > Can we pick one and mark it as preferred and the other deprecated or
> > similar? Perhaps backends will have to support both for the foreseeable
> > future but we should make it possible for frontends to just pick one if
> > that's what they want while nudging them in the direction of all picking
> > the same one.
> 
> History says that back-ends are updated more slowly than front-ends.  For
> example, my fixes to QEMU's serial port emulation that have been in Xen's
> mainline for ~2 years are still not widely deployed on EC2.  Folks running
> FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
> can get console output.
> 
> So, if you want your front-ends to have optimal performance regardless of
> what cloud or appliance they are running on, the two types will have to be
> supported for some time.  Neither is better than the other, just different.
> 
> The opposite is true for back-ends.  If your customer controls the guest
> environment and chooses not upgrade, you can't kill support for the
> variant they use.

I agree with all you say, the practicalities certainly mean we may well
be stuck with both forever. I don't think there is any harm in
documenting one of them as preferred though.

If someone has the freedom (or desire) to only implement one of the two
in their code base then that provides guidance as to which it should be,
at least then we will be encouraging the right trajectory. Also it gives
some small amount of ammunition to people who are stuck with a provider
(of either front or backend) of the wrong type for their environment and
helps break the stalemate as to who should fix their end (however
helpful that might be in practice).

> > I think the decision should made by the current state of mainline Linux
> > & BSD front and backends, i.e. we should prefer what has been upstreamed
> > rather than private forks if possible. Does anyone know what that state
> > is?
> 
> The state is a bit embarrassing on the BSD side.  FreeBSD has had a
> multi-page ring extension since October of 2010.  Unfortunately, I wrote
> this extension before stumbling upon the Citrix blkif patch or the
> extension being used on EC2.  It is closest to the EC2 implementation,
> but not quite compatible.  The saving grace is that I don't know of any
> deployments of this back-end outside of Spectra, and we have not shipped
> it to customers, so I plan to upstream block front and back drivers that
> only implement the Citrix and EC2 style extension once blkif.h settles.  A
> preliminary version of these changes went out for review a couple weeks
> ago.

Cool, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:36:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1Rwv8L-0003P7-Vc; Mon, 13 Feb 2012 12:35: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 1Rwv8J-0003Ow-GH
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:35:52 +0000
Received: from [85.158.139.83:40407] by server-10.bemta-5.messagelabs.com id
	14/F4-26909-6A3093F4; Mon, 13 Feb 2012 12:35:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329136549!14781600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20592 invoked from network); 13 Feb 2012 12:35:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:35:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10660990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:35:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:35:49 +0000
Message-ID: <1329136547.31256.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Mon, 13 Feb 2012 12:35:47 +0000
In-Reply-To: <4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 15:12 +0000, Justin T. Gibbs wrote:
> On Feb 9, 2012, at 2:48 AM, Ian Campbell wrote:
> 
> > On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
> >> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
> >> 
> >>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> >>>> @@ -187,6 +216,25 @@
> >>>> *      The machine ABI rules governing the format of all ring request and
> >>>> *      response structures.
> >>>> *
> >>>> + * ring-page-order
> >>>> + *      Values:         <uint32_t>
> >>>> + *      Default Value:  0
> >>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> >>> 
> >>> Why not just max-ring-page-order. After all, the value is meaningless
> >>> for a backend that only exposes max-ring-pages.
> >>> 
> >>>> + *      Notes:          1, 3
> >>>> + *
> >>>> + *      The size of the frontend allocated request ring buffer in units
> >>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> >>>> + *      etc.).
> >>>> + *
> >>>> + * ring-pages
> >>>> + *      Values:         <uint32_t>
> >>>> + *      Default Value:  1
> >>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> >>> 
> >>> Similarly here - just max-ring-pages should do.
> >> 
> >> This patch documents existing extensions.  For a new driver to properly negotiate a
> >> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
> >> you must use the XenBus node names as I've defined them here.
> > 
> > Can we pick one and mark it as preferred and the other deprecated or
> > similar? Perhaps backends will have to support both for the foreseeable
> > future but we should make it possible for frontends to just pick one if
> > that's what they want while nudging them in the direction of all picking
> > the same one.
> 
> History says that back-ends are updated more slowly than front-ends.  For
> example, my fixes to QEMU's serial port emulation that have been in Xen's
> mainline for ~2 years are still not widely deployed on EC2.  Folks running
> FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
> can get console output.
> 
> So, if you want your front-ends to have optimal performance regardless of
> what cloud or appliance they are running on, the two types will have to be
> supported for some time.  Neither is better than the other, just different.
> 
> The opposite is true for back-ends.  If your customer controls the guest
> environment and chooses not upgrade, you can't kill support for the
> variant they use.

I agree with all you say, the practicalities certainly mean we may well
be stuck with both forever. I don't think there is any harm in
documenting one of them as preferred though.

If someone has the freedom (or desire) to only implement one of the two
in their code base then that provides guidance as to which it should be,
at least then we will be encouraging the right trajectory. Also it gives
some small amount of ammunition to people who are stuck with a provider
(of either front or backend) of the wrong type for their environment and
helps break the stalemate as to who should fix their end (however
helpful that might be in practice).

> > I think the decision should made by the current state of mainline Linux
> > & BSD front and backends, i.e. we should prefer what has been upstreamed
> > rather than private forks if possible. Does anyone know what that state
> > is?
> 
> The state is a bit embarrassing on the BSD side.  FreeBSD has had a
> multi-page ring extension since October of 2010.  Unfortunately, I wrote
> this extension before stumbling upon the Citrix blkif patch or the
> extension being used on EC2.  It is closest to the EC2 implementation,
> but not quite compatible.  The saving grace is that I don't know of any
> deployments of this back-end outside of Spectra, and we have not shipped
> it to customers, so I plan to upstream block front and back drivers that
> only implement the Citrix and EC2 style extension once blkif.h settles.  A
> preliminary version of these changes went out for review a couple weeks
> ago.

Cool, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:43:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwvFQ-0003k2-NG; Mon, 13 Feb 2012 12:43: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 1RwvFP-0003jf-8c
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:43:11 +0000
Received: from [85.158.139.83:20615] by server-7.bemta-5.messagelabs.com id
	6B/0D-01252-E55093F4; Mon, 13 Feb 2012 12:43:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329136987!14293305!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17822 invoked from network); 13 Feb 2012 12:43:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:43:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10661155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:43:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:43:08 +0000
Message-ID: <1329136986.31256.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 12:43:06 +0000
In-Reply-To: <20276.105.622354.251001@mariner.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 17:20 +0000, Ian Jackson wrote:
> John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> > There is also an unused variable warning in xenbus/xenbus.c. I think the compiler should not be warning about this, as the reasonable definition of the local DEBUG macro is the cause? Anyways, here is an ugly fix that shows where the problem is raised. I tried the old trick of defining the variables as volatile, but the new gcc won't let it go by. It won't hurt my feelings if you don't use this patch.
> 
> Urgh, that "fix" really is very ugly as you say.  I think I'm sold on
> disable the warning.

Please see <1328778306.6133.102.camel@zakaz.uk.xensource.com> for that
patch. But:

In this case:

> @@ -327,13 +331,14 @@ static int allocate_xenbus_id(void)
>  /* Initialise xenbus. */
>  void init_xenbus(void)
>  {
> -    int err;
> +    COND(int err;)
>      printk("Initialising xenbus\n");
>      DEBUG("init_xenbus called.\n");
>      xenstore_buf = mfn_to_virt(start_info.store_mfn);
>      create_thread("xenstore", xenbus_thread_func, NULL);
>      DEBUG("buf at %p.\n", xenstore_buf);
> -    err = bind_evtchn(start_info.store_evtchn,
> +
> +    COND(err = ) bind_evtchn(start_info.store_evtchn,
>                       xenbus_evtchn_handler,
>                NULL);
>      unmask_evtchn(start_info.store_evtchn);

I'd be tempted to suggest that either the DEBUG becomes a normal printk
or is removed. I'd prefer the former since it is a useful init time
message which is only printed once (maybe move the "Initialsing xenbus"
printk to the end "Initialised xenbus on IRQ%d MFN %#lx" or something)

In this case:

> @@ -475,11 +480,17 @@ static void xenbus_debug_msg(const char 
>          { "print", sizeof("print") },
>          { msg, len },
>          { "", 1 }};
> +#ifdef XENBUS_DEBUG
>      struct xsd_sockmsg *reply;
> +#endif
>  
> +#ifdef XENBUS_DEBUG
>      reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
>      DEBUG("Got a reply, type %d, id %d, len %d.\n",
>              reply->type, reply->req_id, reply->len);
> +#else
> +    xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
> +#endif
>  }
>  
>  /* List the contents of a directory.  Returns a malloc()ed array of

I think all the DEBUG's reached from "test_xenbus()" can just become
printks -- the calls from test_xenbus don't serve any other purpose than
to print those messages. This includes the DEBUG message at stake here.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:43:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwvFQ-0003k2-NG; Mon, 13 Feb 2012 12:43: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 1RwvFP-0003jf-8c
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:43:11 +0000
Received: from [85.158.139.83:20615] by server-7.bemta-5.messagelabs.com id
	6B/0D-01252-E55093F4; Mon, 13 Feb 2012 12:43:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329136987!14293305!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17822 invoked from network); 13 Feb 2012 12:43:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:43:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10661155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:43:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:43:08 +0000
Message-ID: <1329136986.31256.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 12:43:06 +0000
In-Reply-To: <20276.105.622354.251001@mariner.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-09 at 17:20 +0000, Ian Jackson wrote:
> John McDermott CIV writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> > There is also an unused variable warning in xenbus/xenbus.c. I think the compiler should not be warning about this, as the reasonable definition of the local DEBUG macro is the cause? Anyways, here is an ugly fix that shows where the problem is raised. I tried the old trick of defining the variables as volatile, but the new gcc won't let it go by. It won't hurt my feelings if you don't use this patch.
> 
> Urgh, that "fix" really is very ugly as you say.  I think I'm sold on
> disable the warning.

Please see <1328778306.6133.102.camel@zakaz.uk.xensource.com> for that
patch. But:

In this case:

> @@ -327,13 +331,14 @@ static int allocate_xenbus_id(void)
>  /* Initialise xenbus. */
>  void init_xenbus(void)
>  {
> -    int err;
> +    COND(int err;)
>      printk("Initialising xenbus\n");
>      DEBUG("init_xenbus called.\n");
>      xenstore_buf = mfn_to_virt(start_info.store_mfn);
>      create_thread("xenstore", xenbus_thread_func, NULL);
>      DEBUG("buf at %p.\n", xenstore_buf);
> -    err = bind_evtchn(start_info.store_evtchn,
> +
> +    COND(err = ) bind_evtchn(start_info.store_evtchn,
>                       xenbus_evtchn_handler,
>                NULL);
>      unmask_evtchn(start_info.store_evtchn);

I'd be tempted to suggest that either the DEBUG becomes a normal printk
or is removed. I'd prefer the former since it is a useful init time
message which is only printed once (maybe move the "Initialsing xenbus"
printk to the end "Initialised xenbus on IRQ%d MFN %#lx" or something)

In this case:

> @@ -475,11 +480,17 @@ static void xenbus_debug_msg(const char 
>          { "print", sizeof("print") },
>          { msg, len },
>          { "", 1 }};
> +#ifdef XENBUS_DEBUG
>      struct xsd_sockmsg *reply;
> +#endif
>  
> +#ifdef XENBUS_DEBUG
>      reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
>      DEBUG("Got a reply, type %d, id %d, len %d.\n",
>              reply->type, reply->req_id, reply->len);
> +#else
> +    xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
> +#endif
>  }
>  
>  /* List the contents of a directory.  Returns a malloc()ed array of

I think all the DEBUG's reached from "test_xenbus()" can just become
printks -- the calls from test_xenbus don't serve any other purpose than
to print those messages. This includes the DEBUG message at stake here.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:52:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvO6-0004Q2-Qr; Mon, 13 Feb 2012 12:52: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 1RwvO5-0004PW-5E
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:52:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329137502!65600265!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19419 invoked from network); 13 Feb 2012 12:51:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:51:42 -0000
Received: by wibhm2 with SMTP id hm2so14720311wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 04:52:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=aF8RP4Tc4k88ZmhkQdOMU+fiY5MRidy/hKlA/0NqrEw=;
	b=vbXXbTdhuVTna8s2lKM/neB3cd5BBLaWKGAV2Wxb4oZBO1bHTbImFPjATsQCPf+EKs
	4TjhS566jhIHtd3hSGdoBGFbSVnFZRHc4GBwycZ6VSzl0fETzXD+OVPuEnO7KrC+q4g5
	+ylTpHRv8E3I5YLudceIyNEKp2qOXSk8LF1o8=
Received: by 10.181.12.106 with SMTP id ep10mr18045571wid.8.1329137524705;
	Mon, 13 Feb 2012 04:52:04 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr5sm46551365wib.0.2012.02.13.04.52.02
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 04:52:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 12:51:54 +0000
From: Keir Fraser <keir@xen.org>
To: Julian Pidancet <julian.pidancet@gmail.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB5EB7EA.3933E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
	optional
Thread-Index: AczqTkMKW4J0ZGAZJE6myHWr6HC8iQ==
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> This patch set mainly allows the user to build a seabios or rombios only
> version of hvmloader.
> In addition, when building a seabios only hvmloader, Option ROMs like
> vgabios and etherboot are no longer required, and therefore can be disabled
> from the build. Dependency on the bcc compiler can also be avoided the
> same way.

Applied, but I wonder why we still have the rombios support? Could we switch
over to seabios for 4.2 and get rid of the crufty old rombios code entirely?

 -- Keir

> v2: Separate patches for separate issues
>    Introduced config option to select which NIC to build ROM for
>    Fixed initial patch to build multiple etherboot ROMs in hvmloader
>    Option ROMs are keyed off wether or not rombios is enabled, rather than
> on an individual basis
>    Introduced config options to select support for rombios/seabios
> 
> v3: Fix mkhex script to take several file arguments on the command line
>     Reorganize hvmloader option ROM loading code to make it optionnal, and
> make bios->load_roms a callback that the BIOS support code has to implement
> if option ROM loading is desired.
>     Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
> created.
> 
> Julian Pidancet (5):
>   hvmloader: Only compile 32bitbios_support.c when rombios is enabled
>   hvmloader: Allow the mkhex command to take several file arguments
>   firmware: Use mkhex from hvmloader directory for etherboot ROMs
>   hvmloader: Move option ROM loading into a separate optionnal file
>   firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
> 
>  Config.mk                             |    5 +
>  tools/firmware/Makefile               |   18 ++--
>  tools/firmware/etherboot/Config       |    2 -
>  tools/firmware/etherboot/Makefile     |   13 +--
>  tools/firmware/hvmloader/Makefile     |   39 ++++---
>  tools/firmware/hvmloader/config.h     |    3 +-
>  tools/firmware/hvmloader/hvmloader.c  |  218
> +--------------------------------
>  tools/firmware/hvmloader/mkhex        |    3 +-
>  tools/firmware/hvmloader/option_rom.h |    7 +
>  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
>  tools/firmware/hvmloader/seabios.c    |    5 +-
>  12 files changed, 302 insertions(+), 263 deletions(-)
>  create mode 100644 tools/firmware/hvmloader/optionroms.c



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:52:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvO6-0004Q2-Qr; Mon, 13 Feb 2012 12:52: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 1RwvO5-0004PW-5E
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:52:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329137502!65600265!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19419 invoked from network); 13 Feb 2012 12:51:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 12:51:42 -0000
Received: by wibhm2 with SMTP id hm2so14720311wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 04:52:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=aF8RP4Tc4k88ZmhkQdOMU+fiY5MRidy/hKlA/0NqrEw=;
	b=vbXXbTdhuVTna8s2lKM/neB3cd5BBLaWKGAV2Wxb4oZBO1bHTbImFPjATsQCPf+EKs
	4TjhS566jhIHtd3hSGdoBGFbSVnFZRHc4GBwycZ6VSzl0fETzXD+OVPuEnO7KrC+q4g5
	+ylTpHRv8E3I5YLudceIyNEKp2qOXSk8LF1o8=
Received: by 10.181.12.106 with SMTP id ep10mr18045571wid.8.1329137524705;
	Mon, 13 Feb 2012 04:52:04 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr5sm46551365wib.0.2012.02.13.04.52.02
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 04:52:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 12:51:54 +0000
From: Keir Fraser <keir@xen.org>
To: Julian Pidancet <julian.pidancet@gmail.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB5EB7EA.3933E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
	optional
Thread-Index: AczqTkMKW4J0ZGAZJE6myHWr6HC8iQ==
In-Reply-To: <cover.1328991838.git.julian.pidancet@gmail.com>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> This patch set mainly allows the user to build a seabios or rombios only
> version of hvmloader.
> In addition, when building a seabios only hvmloader, Option ROMs like
> vgabios and etherboot are no longer required, and therefore can be disabled
> from the build. Dependency on the bcc compiler can also be avoided the
> same way.

Applied, but I wonder why we still have the rombios support? Could we switch
over to seabios for 4.2 and get rid of the crufty old rombios code entirely?

 -- Keir

> v2: Separate patches for separate issues
>    Introduced config option to select which NIC to build ROM for
>    Fixed initial patch to build multiple etherboot ROMs in hvmloader
>    Option ROMs are keyed off wether or not rombios is enabled, rather than
> on an individual basis
>    Introduced config options to select support for rombios/seabios
> 
> v3: Fix mkhex script to take several file arguments on the command line
>     Reorganize hvmloader option ROM loading code to make it optionnal, and
> make bios->load_roms a callback that the BIOS support code has to implement
> if option ROM loading is desired.
>     Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
> created.
> 
> Julian Pidancet (5):
>   hvmloader: Only compile 32bitbios_support.c when rombios is enabled
>   hvmloader: Allow the mkhex command to take several file arguments
>   firmware: Use mkhex from hvmloader directory for etherboot ROMs
>   hvmloader: Move option ROM loading into a separate optionnal file
>   firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
> 
>  Config.mk                             |    5 +
>  tools/firmware/Makefile               |   18 ++--
>  tools/firmware/etherboot/Config       |    2 -
>  tools/firmware/etherboot/Makefile     |   13 +--
>  tools/firmware/hvmloader/Makefile     |   39 ++++---
>  tools/firmware/hvmloader/config.h     |    3 +-
>  tools/firmware/hvmloader/hvmloader.c  |  218
> +--------------------------------
>  tools/firmware/hvmloader/mkhex        |    3 +-
>  tools/firmware/hvmloader/option_rom.h |    7 +
>  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
>  tools/firmware/hvmloader/seabios.c    |    5 +-
>  12 files changed, 302 insertions(+), 263 deletions(-)
>  create mode 100644 tools/firmware/hvmloader/optionroms.c



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:54:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwvPq-0004XO-O3; Mon, 13 Feb 2012 12:53:58 +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 1RwvPq-0004X8-40
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329137565!62609823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31302 invoked from network); 13 Feb 2012 12:52:45 -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;
	13 Feb 2012 12:52:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10661381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:53:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:53:56 +0000
Message-ID: <1329137635.31256.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Mon, 13 Feb 2012 12:53:55 +0000
In-Reply-To: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
> I get the backtrace below if I try to boot a PV guest running F17 Alpha 
> TC2 in graphical mode. Is this a known problem?

It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
got to the bottom of the root cause though.

That occasion was a suspend/resume thing so perhaps not really related
but it seems fishily similar.

I've not looked at the code recently but it seems that back then I was
of the opinion that info->update_wanted == 0 must remain true until the
irq etc was all fully setup, that might be relevant now?

Ian.

> 
>  	Michael Young
> 
> WARNING: at drivers/xen/events.c:209 evtchn_from_irq+0x41/0x50()
> Invalid irq -1!
> Modules linked in:
> Pid: 17, comm: xenbus Tainted: G        W 
> 3.3.0-0.rc3.git3.1.fc17.x86_64 #1
> Call Trace:
>   <IRQ>  [<ffffffff8106047f>] warn_slowpath_common+0x7f/0xc0
>   [<ffffffff81060576>] warn_slowpath_fmt+0x46/0x50
>   [<ffffffff8100f942>] ? check_events+0x12/0x20
>   [<ffffffff813c5bf1>] evtchn_from_irq+0x41/0x50
>   [<ffffffff813c6302>] notify_remote_via_irq+0x12/0x50
>   [<ffffffff8137e016>] xenfb_event_handler+0x26/0x50
>   [<ffffffff8110b0fc>] handle_irq_event_percpu+0x6c/0x390
>   [<ffffffff8110b468>] handle_irq_event+0x48/0x70
>   [<ffffffff8110e7b7>] handle_edge_irq+0x77/0x110
>   [<ffffffff813c56f3>] __xen_evtchn_do_upcall+0x1c3/0x290
>   [<ffffffff813c782f>] xen_evtchn_do_upcall+0x2f/0x50
>   [<ffffffff816a7a3e>] xen_do_hypervisor_callback+0x1e/0x30
>   <EOI>  [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
>   [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
>   [<ffffffff813c9ed7>] ? xb_read+0xd7/0x190
>   [<ffffffff811a2359>] ? kmem_cache_alloc_trace+0xd9/0x240
>   [<ffffffff813cb170>] ? unregister_xenbus_watch+0x1d0/0x1d0
>   [<ffffffff813cb1f9>] ? xenbus_thread+0x89/0x2b0
>   [<ffffffff81089ac7>] ? kthread+0xb7/0xc0
>   [<ffffffff810cd02d>] ? trace_hardirqs_on+0xd/0x10
>   [<ffffffff816a78f4>] ? kernel_thread_helper+0x4/0x10
>   [<ffffffff8169dcb4>] ? retint_restore_args+0x13/0x13
>   [<ffffffff816a78f0>] ? gs_change+0x13/0x13
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:54:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwvPq-0004XO-O3; Mon, 13 Feb 2012 12:53:58 +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 1RwvPq-0004X8-40
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329137565!62609823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31302 invoked from network); 13 Feb 2012 12:52:45 -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;
	13 Feb 2012 12:52:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10661381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:53:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:53:56 +0000
Message-ID: <1329137635.31256.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Mon, 13 Feb 2012 12:53:55 +0000
In-Reply-To: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
> I get the backtrace below if I try to boot a PV guest running F17 Alpha 
> TC2 in graphical mode. Is this a known problem?

It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
got to the bottom of the root cause though.

That occasion was a suspend/resume thing so perhaps not really related
but it seems fishily similar.

I've not looked at the code recently but it seems that back then I was
of the opinion that info->update_wanted == 0 must remain true until the
irq etc was all fully setup, that might be relevant now?

Ian.

> 
>  	Michael Young
> 
> WARNING: at drivers/xen/events.c:209 evtchn_from_irq+0x41/0x50()
> Invalid irq -1!
> Modules linked in:
> Pid: 17, comm: xenbus Tainted: G        W 
> 3.3.0-0.rc3.git3.1.fc17.x86_64 #1
> Call Trace:
>   <IRQ>  [<ffffffff8106047f>] warn_slowpath_common+0x7f/0xc0
>   [<ffffffff81060576>] warn_slowpath_fmt+0x46/0x50
>   [<ffffffff8100f942>] ? check_events+0x12/0x20
>   [<ffffffff813c5bf1>] evtchn_from_irq+0x41/0x50
>   [<ffffffff813c6302>] notify_remote_via_irq+0x12/0x50
>   [<ffffffff8137e016>] xenfb_event_handler+0x26/0x50
>   [<ffffffff8110b0fc>] handle_irq_event_percpu+0x6c/0x390
>   [<ffffffff8110b468>] handle_irq_event+0x48/0x70
>   [<ffffffff8110e7b7>] handle_edge_irq+0x77/0x110
>   [<ffffffff813c56f3>] __xen_evtchn_do_upcall+0x1c3/0x290
>   [<ffffffff813c782f>] xen_evtchn_do_upcall+0x2f/0x50
>   [<ffffffff816a7a3e>] xen_do_hypervisor_callback+0x1e/0x30
>   <EOI>  [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
>   [<ffffffff8100140a>] ? hypercall_page+0x40a/0x1000
>   [<ffffffff813c9ed7>] ? xb_read+0xd7/0x190
>   [<ffffffff811a2359>] ? kmem_cache_alloc_trace+0xd9/0x240
>   [<ffffffff813cb170>] ? unregister_xenbus_watch+0x1d0/0x1d0
>   [<ffffffff813cb1f9>] ? xenbus_thread+0x89/0x2b0
>   [<ffffffff81089ac7>] ? kthread+0xb7/0xc0
>   [<ffffffff810cd02d>] ? trace_hardirqs_on+0xd/0x10
>   [<ffffffff816a78f4>] ? kernel_thread_helper+0x4/0x10
>   [<ffffffff8169dcb4>] ? retint_restore_args+0x13/0x13
>   [<ffffffff816a78f0>] ? gs_change+0x13/0x13
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:54:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvPq-0004X9-B4; Mon, 13 Feb 2012 12:53:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RwvPo-0004X1-37
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:53:56 +0000
Received: from [85.158.139.83:15352] by server-5.bemta-5.messagelabs.com id
	77/B4-03847-3E7093F4; Mon, 13 Feb 2012 12:53:55 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329137634!14835036!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5NDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20695 invoked from network); 13 Feb 2012 12:53:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 12:53:54 -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 q1DCrn3U029502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 13 Feb 2012 07:53:49 -0500
Received: from redhat.com (vpn-203-220.tlv.redhat.com [10.35.203.220])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1DCrgOH010029; Mon, 13 Feb 2012 07:53:44 -0500
Date: Mon, 13 Feb 2012 14:53:50 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120213125348.GA26773@redhat.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V6 11/11] pci: Do not check if a bus exist
 in pci_parse_devaddr.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 12:20:13PM +0000, Anthony PERARD wrote:
> Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
> this should be the jobs of a caller. In fact, the two callers of this function
> will try to retrieve the PCIBus related to the devaddr and return an error if
> they cannot.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

I agree. It's a good patch. And this will help address the bridges.
Want me to queue this?

> ---
>  hw/pci.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index ebb5de9..da7cf79 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -529,10 +529,6 @@ int pci_parse_devaddr(const char *addr, int *domp, int *busp,
>      if (*e)
>  	return -1;
>  
> -    /* Note: QEMU doesn't implement domains other than 0 */
> -    if (!pci_find_bus(pci_find_root_bus(dom), bus))
> -	return -1;
> -
>      *domp = dom;
>      *busp = bus;
>      *slotp = slot;
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:54:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvPq-0004X9-B4; Mon, 13 Feb 2012 12:53:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RwvPo-0004X1-37
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:53:56 +0000
Received: from [85.158.139.83:15352] by server-5.bemta-5.messagelabs.com id
	77/B4-03847-3E7093F4; Mon, 13 Feb 2012 12:53:55 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329137634!14835036!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTI5NDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20695 invoked from network); 13 Feb 2012 12:53:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 12:53:54 -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 q1DCrn3U029502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 13 Feb 2012 07:53:49 -0500
Received: from redhat.com (vpn-203-220.tlv.redhat.com [10.35.203.220])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1DCrgOH010029; Mon, 13 Feb 2012 07:53:44 -0500
Date: Mon, 13 Feb 2012 14:53:50 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120213125348.GA26773@redhat.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V6 11/11] pci: Do not check if a bus exist
 in pci_parse_devaddr.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 12:20:13PM +0000, Anthony PERARD wrote:
> Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
> this should be the jobs of a caller. In fact, the two callers of this function
> will try to retrieve the PCIBus related to the devaddr and return an error if
> they cannot.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

I agree. It's a good patch. And this will help address the bridges.
Want me to queue this?

> ---
>  hw/pci.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index ebb5de9..da7cf79 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -529,10 +529,6 @@ int pci_parse_devaddr(const char *addr, int *domp, int *busp,
>      if (*e)
>  	return -1;
>  
> -    /* Note: QEMU doesn't implement domains other than 0 */
> -    if (!pci_find_bus(pci_find_root_bus(dom), bus))
> -	return -1;
> -
>      *domp = dom;
>      *busp = bus;
>      *slotp = slot;
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:56:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwvS1-0004tr-GW; Mon, 13 Feb 2012 12:56: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 1RwvS0-0004te-EC
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:56:12 +0000
Received: from [85.158.139.83:45238] by server-12.bemta-5.messagelabs.com id
	C6/13-30830-B68093F4; Mon, 13 Feb 2012 12:56:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329137771!14840570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28095 invoked from network); 13 Feb 2012 12:56:11 -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;
	13 Feb 2012 12:56:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10661440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:56:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:56:11 +0000
Message-ID: <1329137769.31256.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Mon, 13 Feb 2012 12:56:09 +0000
In-Reply-To: <CB5EB7EA.3933E%keir@xen.org>
References: <CB5EB7EA.3933E%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 12:51 +0000, Keir Fraser wrote:
> On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
> 
> > This patch set mainly allows the user to build a seabios or rombios only
> > version of hvmloader.
> > In addition, when building a seabios only hvmloader, Option ROMs like
> > vgabios and etherboot are no longer required, and therefore can be disabled
> > from the build. Dependency on the bcc compiler can also be avoided the
> > same way.
> 
> Applied, but I wonder why we still have the rombios support? Could we switch
> over to seabios for 4.2 and get rid of the crufty old rombios code entirely?

We still use ROMBIOS with the traditional qemu-xen tree, I think we have
to do that for compatibility with existing guests, for the same reason
as we need to continue to support that traditional qemu-xen tree.

Post 4.2 we will be switching the default qemu to the upstream tree
which uses SeaBIOS at which point the old-qemu+ROMBIOS combo becomes
legacy/frozen etc. We don't support new-qemu+ROMBIOS nor old-qemu
+SEABIOS.

Ian.

> 
>  -- Keir
> 
> > v2: Separate patches for separate issues
> >    Introduced config option to select which NIC to build ROM for
> >    Fixed initial patch to build multiple etherboot ROMs in hvmloader
> >    Option ROMs are keyed off wether or not rombios is enabled, rather than
> > on an individual basis
> >    Introduced config options to select support for rombios/seabios
> > 
> > v3: Fix mkhex script to take several file arguments on the command line
> >     Reorganize hvmloader option ROM loading code to make it optionnal, and
> > make bios->load_roms a callback that the BIOS support code has to implement
> > if option ROM loading is desired.
> >     Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
> > created.
> > 
> > Julian Pidancet (5):
> >   hvmloader: Only compile 32bitbios_support.c when rombios is enabled
> >   hvmloader: Allow the mkhex command to take several file arguments
> >   firmware: Use mkhex from hvmloader directory for etherboot ROMs
> >   hvmloader: Move option ROM loading into a separate optionnal file
> >   firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
> > 
> >  Config.mk                             |    5 +
> >  tools/firmware/Makefile               |   18 ++--
> >  tools/firmware/etherboot/Config       |    2 -
> >  tools/firmware/etherboot/Makefile     |   13 +--
> >  tools/firmware/hvmloader/Makefile     |   39 ++++---
> >  tools/firmware/hvmloader/config.h     |    3 +-
> >  tools/firmware/hvmloader/hvmloader.c  |  218
> > +--------------------------------
> >  tools/firmware/hvmloader/mkhex        |    3 +-
> >  tools/firmware/hvmloader/option_rom.h |    7 +
> >  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
> >  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
> >  tools/firmware/hvmloader/seabios.c    |    5 +-
> >  12 files changed, 302 insertions(+), 263 deletions(-)
> >  create mode 100644 tools/firmware/hvmloader/optionroms.c
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 12:56:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 12: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.xensource.com>)
	id 1RwvS1-0004tr-GW; Mon, 13 Feb 2012 12:56: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 1RwvS0-0004te-EC
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 12:56:12 +0000
Received: from [85.158.139.83:45238] by server-12.bemta-5.messagelabs.com id
	C6/13-30830-B68093F4; Mon, 13 Feb 2012 12:56:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329137771!14840570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28095 invoked from network); 13 Feb 2012 12:56:11 -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;
	13 Feb 2012 12:56:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10661440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 12:56:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 12:56:11 +0000
Message-ID: <1329137769.31256.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Mon, 13 Feb 2012 12:56:09 +0000
In-Reply-To: <CB5EB7EA.3933E%keir@xen.org>
References: <CB5EB7EA.3933E%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 12:51 +0000, Keir Fraser wrote:
> On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
> 
> > This patch set mainly allows the user to build a seabios or rombios only
> > version of hvmloader.
> > In addition, when building a seabios only hvmloader, Option ROMs like
> > vgabios and etherboot are no longer required, and therefore can be disabled
> > from the build. Dependency on the bcc compiler can also be avoided the
> > same way.
> 
> Applied, but I wonder why we still have the rombios support? Could we switch
> over to seabios for 4.2 and get rid of the crufty old rombios code entirely?

We still use ROMBIOS with the traditional qemu-xen tree, I think we have
to do that for compatibility with existing guests, for the same reason
as we need to continue to support that traditional qemu-xen tree.

Post 4.2 we will be switching the default qemu to the upstream tree
which uses SeaBIOS at which point the old-qemu+ROMBIOS combo becomes
legacy/frozen etc. We don't support new-qemu+ROMBIOS nor old-qemu
+SEABIOS.

Ian.

> 
>  -- Keir
> 
> > v2: Separate patches for separate issues
> >    Introduced config option to select which NIC to build ROM for
> >    Fixed initial patch to build multiple etherboot ROMs in hvmloader
> >    Option ROMs are keyed off wether or not rombios is enabled, rather than
> > on an individual basis
> >    Introduced config options to select support for rombios/seabios
> > 
> > v3: Fix mkhex script to take several file arguments on the command line
> >     Reorganize hvmloader option ROM loading code to make it optionnal, and
> > make bios->load_roms a callback that the BIOS support code has to implement
> > if option ROM loading is desired.
> >     Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
> > created.
> > 
> > Julian Pidancet (5):
> >   hvmloader: Only compile 32bitbios_support.c when rombios is enabled
> >   hvmloader: Allow the mkhex command to take several file arguments
> >   firmware: Use mkhex from hvmloader directory for etherboot ROMs
> >   hvmloader: Move option ROM loading into a separate optionnal file
> >   firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
> > 
> >  Config.mk                             |    5 +
> >  tools/firmware/Makefile               |   18 ++--
> >  tools/firmware/etherboot/Config       |    2 -
> >  tools/firmware/etherboot/Makefile     |   13 +--
> >  tools/firmware/hvmloader/Makefile     |   39 ++++---
> >  tools/firmware/hvmloader/config.h     |    3 +-
> >  tools/firmware/hvmloader/hvmloader.c  |  218
> > +--------------------------------
> >  tools/firmware/hvmloader/mkhex        |    3 +-
> >  tools/firmware/hvmloader/option_rom.h |    7 +
> >  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
> >  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
> >  tools/firmware/hvmloader/seabios.c    |    5 +-
> >  12 files changed, 302 insertions(+), 263 deletions(-)
> >  create mode 100644 tools/firmware/hvmloader/optionroms.c
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:02:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:02:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvXQ-0005DJ-OC; Mon, 13 Feb 2012 13:01:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RwvXP-0005D2-F0
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:01:47 +0000
Received: from [85.158.139.83:47036] by server-2.bemta-5.messagelabs.com id
	E0/00-20725-AB9093F4; Mon, 13 Feb 2012 13:01:46 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329138105!12135684!2
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0NzE0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25327 invoked from network); 13 Feb 2012 13:01:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:01:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=OFa7ZTB/MOOXyGQ1tUxO7n9RK8EjD01qPAbBN9QBL/gO+qsaN8oufF+4
	cN07f1dnF75gxe3Fie7xgnKC4+LHalPSrANMYZ+DvRdukIIesZXHl8nin
	PKQ6MNUGz4QnWn8OOX/Ywd7PXM0MgwKSjj+0S+G2nqrdbEYUi/ShF+8V6
	+xH8W3SRKAbl8MwH4HLtHBdKvEml2aKvikIrV824xJVXaLkYJXw/W83Wd
	NMQNJeELa/JwDdUdbP1VvhjFaM8Zl;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329138106; x=1360674106;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=Oz+E83CPt0ff/fbvEvlUumxY6jWj0LVeUQ4waFsdj9k=;
	b=hyTJVZMvv76brCbSr+A8WKBYPPTy/V1IXPVgPiI037BjygLCBRvqdHKm
	3gJI8aRqR1YOTrSsvVU2SEDGbpDQRzgx8TJEd+QpArFCIEy1EpkS466R3
	O0CxB1gYNMIrzRocFwfvge45TUhm6lJfyhnrpujwa3HvojhJOHCU6CgbL
	KNLsJ4ImSZ2LzlPUZmNc9tCDQAVU5dLjXcRd/tJGa8sbhIffnVAkOab8E
	hNYc5IPO/SjqakGAlfIrjTdNbUItW;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,411,1325458800"; d="scan'208";a="86265459"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:46 +0100
X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="129120241"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:41 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 3D7F076C0A4;
	Mon, 13 Feb 2012 14:01:41 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 14:01:40 +0100
Message-ID: <6587132.0KbvunDmjW@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Add the BTS functionality to the existing vpmu implementation for Intel cpus.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

 xen/arch/x86/hvm/vmx/vmx.c               |   12 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c        |  156 +++++++++++++++++++++++++-----
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |    1 +
 xen/include/asm-x86/hvm/vpmu.h           |    3 +
 xen/include/asm-x86/msr-index.h          |    5 +
 5 files changed, 148 insertions(+), 29 deletions(-)



diff -r 6c666c08cf0d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Mon Feb 13 13:51:51 2012 +0100
@@ -1823,6 +1823,9 @@ static int vmx_msr_read_intercept(unsign
         /* Debug Trace Store is not supported. */
         *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
                        MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
+        /* Perhaps vpmu will change some bits. */
+        if ( vpmu_do_rdmsr(msr, msr_content) )
+            goto done;
         break;
     default:
         if ( vpmu_do_rdmsr(msr, msr_content) )
@@ -1950,9 +1953,14 @@ static int vmx_msr_write_intercept(unsig
         int i, rc = 0;
         uint64_t supported = IA32_DEBUGCTLMSR_LBR | IA32_DEBUGCTLMSR_BTF;
 
-        if ( !msr_content || (msr_content & ~supported) )
+        if ( !msr_content )
             break;
-
+        if ( msr_content & ~supported )
+        {
+            /* Perhaps some other bits are supported in vpmu. */
+            if ( !vpmu_do_wrmsr(msr, msr_content) )
+                break;
+        }
         if ( msr_content & IA32_DEBUGCTLMSR_LBR )
         {
             const struct lbr_info *lbr = last_branch_msr_get();
diff -r 6c666c08cf0d xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 13 13:51:51 2012 +0100
@@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
     struct core2_vpmu_context *core2_vpmu_cxt = NULL;
 
     if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
+    {
+        /* Special handling for BTS */
+        if ( msr == MSR_IA32_DEBUGCTLMSR )
+        {
+            uint64_t supported = IA32_DEBUGCTLMSR_TR | IA32_DEBUGCTLMSR_BTS |
+                                 IA32_DEBUGCTLMSR_BTINT;
+
+            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
+            {
+                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
+                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
+            }
+            if ( msr_content & supported  )
+            {
+                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
+                {
+                    gdprintk(XENLOG_WARNING, "Debug Store is not supported on this cpu\n");
+                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
+                    return 0;
+                }
+                return 1;
+            }
+        }
         return 0;
+    }
 
     core2_vpmu_cxt = vpmu->context;
     switch ( msr )
@@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
                      "which is not supported.\n");
         return 1;
     case MSR_IA32_DS_AREA:
-        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
-        return 1;
+        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
+        {
+            if (!msr_content || !is_canonical_address(msr_content))
+            {
+                gdprintk(XENLOG_WARNING, "Illegal address for IA32_DS_AREA: 0x%lx\n",
+                                                            msr_content);
+                vmx_inject_hw_exception(TRAP_gp_fault, 0);
+                return 1;
+            }
+            else
+            {
+                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
+                break;
+            }
+        }
+        else
+        {
+            gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
+            return 1;
+        }
     case MSR_CORE_PERF_GLOBAL_CTRL:
         global_ctrl = msr_content;
         for ( i = 0; i < core2_get_pmc_count(); i++ )
@@ -466,6 +508,7 @@ static int core2_vpmu_do_wrmsr(unsigned 
         pmu_enable |= core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i];
     for ( i = 0; i < core2_get_pmc_count(); i++ )
         pmu_enable |= core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i];
+    pmu_enable |= core2_vpmu_cxt->pmu_enable->ds_area_enable;
     if ( pmu_enable )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
@@ -491,6 +534,8 @@ static int core2_vpmu_do_wrmsr(unsigned 
                 inject_gp = 1;
             break;
         case MSR_TYPE_CTRL:           /* IA32_FIXED_CTR_CTRL */
+            if  ( msr == MSR_IA32_DS_AREA )
+                break;
             /* 4 bits per counter, currently 3 fixed counters implemented. */
             mask = ~((1ull << (3 * 4)) - 1);
             if (msr_content & mask)
@@ -520,25 +565,35 @@ static int core2_vpmu_do_rdmsr(unsigned 
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct core2_vpmu_context *core2_vpmu_cxt = NULL;
 
-    if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
-        return 0;
-
-    core2_vpmu_cxt = vpmu->context;
-    switch ( msr )
+    if ( core2_vpmu_msr_common_check(msr, &type, &index) )
     {
-    case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
-        *msr_content = 0;
-        break;
-    case MSR_CORE_PERF_GLOBAL_STATUS:
-        *msr_content = core2_vpmu_cxt->global_ovf_status;
-        break;
-    case MSR_CORE_PERF_GLOBAL_CTRL:
-        vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
-        break;
-    default:
-        rdmsrl(msr, *msr_content);
+        core2_vpmu_cxt = vpmu->context;
+        switch ( msr )
+        {
+        case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+            *msr_content = 0;
+            break;
+        case MSR_CORE_PERF_GLOBAL_STATUS:
+            *msr_content = core2_vpmu_cxt->global_ovf_status;
+            break;
+        case MSR_CORE_PERF_GLOBAL_CTRL:
+            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+            break;
+        default:
+            rdmsrl(msr, *msr_content);
+        }
     }
-
+    else
+    {
+        /* Extension for BTS */
+        if ( msr == MSR_IA32_MISC_ENABLE)
+        {
+            if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
+                *msr_content &= ~MSR_IA32_MISC_ENABLE_BTS_UNAVAIL;
+        }
+        else
+            return 0;
+    }
     return 1;
 }
 
@@ -553,15 +608,24 @@ static int core2_vpmu_do_interrupt(struc
     struct vlapic *vlapic = vcpu_vlapic(v);
 
     rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content);
-    if ( !msr_content )
-        return 0;
+    if ( msr_content )
+    {
+        if ( is_pmc_quirk )
+            handle_pmc_quirk(msr_content);
 
-    if ( is_pmc_quirk )
-        handle_pmc_quirk(msr_content);
-
-    core2_vpmu_cxt->global_ovf_status |= msr_content;
-    msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count()) - 1);
-    wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
+        core2_vpmu_cxt->global_ovf_status |= msr_content;
+        msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count()) - 1);
+        wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
+    }
+    else
+    {
+        /* No PMC overflow but perhaps a Trace Message interrupt. */
+        msr_content = __vmread(GUEST_IA32_DEBUGCTL);
+        if ( !(msr_content & IA32_DEBUGCTLMSR_TR) )
+        {
+            return 0;
+        }
+    }
 
     apic_write_around(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
 
@@ -582,10 +646,48 @@ static void core2_vpmu_do_cpuid(unsigned
                                 unsigned int *eax, unsigned int *ebx,
                                 unsigned int *ecx, unsigned int *edx)
 {
+    if (input == 0x1)
+    {
+        struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
+        {
+            /* Switch on the 'Debug Store' feature in CPUID.EAX[1]:EDX[21] */
+            *edx |= cpufeat_mask(X86_FEATURE_DS);
+        }
+    }
 }
 
 static void core2_vpmu_initialise(struct vcpu *v)
 {
+    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    u64 msr_content;
+    struct cpuinfo_x86 *c = &current_cpu_data;
+
+    /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
+    if ( cpu_has(c, X86_FEATURE_DS) )
+    {
+        if ( !cpu_has(c, X86_FEATURE_DTES64) )
+        {
+            gdprintk(XENLOG_WARNING, "CPU doesn't support 64-bit DS Area - Debug Store disabled\n");
+            goto func_out;
+        }
+        vpmu_set(vpmu, VPMU_CPU_HAS_DS);
+        rdmsrl(MSR_IA32_MISC_ENABLE, msr_content);
+        if ( msr_content & MSR_IA32_MISC_ENABLE_BTS_UNAVAIL )
+        {
+            /* If BTS_UNAVAIL is set reset the DS feature. */
+            vpmu_reset(vpmu, VPMU_CPU_HAS_DS);
+            gdprintk(XENLOG_WARNING, "CPU has set BTS_UNAVAIL - Debug Store disabled\n");
+        }
+        else
+            vpmu_set(vpmu, VPMU_CPU_HAS_BTS);
+            if ( !cpu_has(c, X86_FEATURE_DSCPL) )
+            {
+                gdprintk(XENLOG_WARNING, "vpmu: cpu doesn't support CPL-Qualified BTS\n");
+            }
+    }
+func_out:
     check_pmc_quirk();
 }
 
diff -r 6c666c08cf0d xen/include/asm-x86/hvm/vmx/vpmu_core2.h
--- a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h	Mon Feb 13 13:51:51 2012 +0100
@@ -29,6 +29,7 @@ struct arch_msr_pair {
 };
 
 struct core2_pmu_enable {
+    char ds_area_enable;
     char fixed_ctr_enable[3];
     char arch_pmc_enable[1];
 };
diff -r 6c666c08cf0d xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 13 13:51:51 2012 +0100
@@ -72,6 +72,9 @@ struct vpmu_struct {
 #define VPMU_CONTEXT_LOADED                 0x2
 #define VPMU_RUNNING                        0x4
 #define VPMU_PASSIVE_DOMAIN_ALLOCATED       0x8
+#define VPMU_CPU_HAS_DS                     0x10 /* Has Debug Store */
+#define VPMU_CPU_HAS_BTS                    0x20 /* Has Branche Trace Store */
+
 
 #define vpmu_set(_vpmu, _x)    ((_vpmu)->flags |= (_x))
 #define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))
diff -r 6c666c08cf0d xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/include/asm-x86/msr-index.h	Mon Feb 13 13:51:51 2012 +0100
@@ -67,6 +67,11 @@
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
 #define IA32_DEBUGCTLMSR_LBR		(1<<0) /* Last Branch Record */
 #define IA32_DEBUGCTLMSR_BTF		(1<<1) /* Single Step on Branches */
+#define IA32_DEBUGCTLMSR_TR		(1<<6) /* Trace Message Enable */
+#define IA32_DEBUGCTLMSR_BTS		(1<<7) /* Branch Trace Store */
+#define IA32_DEBUGCTLMSR_BTINT		(1<<8) /* Branch Trace Interrupt */
+#define IA32_DEBUGCTLMSR_BTS_OFF_OS	(1<<9)  /* BTS off if CPL 0 */
+#define IA32_DEBUGCTLMSR_BTS_OFF_USR	(1<<10) /* BTS off if CPL > 0 */
 
 #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
 #define MSR_IA32_LASTBRANCHTOIP		0x000001dc

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:02:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:02:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvXQ-0005DJ-OC; Mon, 13 Feb 2012 13:01:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RwvXP-0005D2-F0
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:01:47 +0000
Received: from [85.158.139.83:47036] by server-2.bemta-5.messagelabs.com id
	E0/00-20725-AB9093F4; Mon, 13 Feb 2012 13:01:46 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329138105!12135684!2
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0NzE0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25327 invoked from network); 13 Feb 2012 13:01:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:01:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=OFa7ZTB/MOOXyGQ1tUxO7n9RK8EjD01qPAbBN9QBL/gO+qsaN8oufF+4
	cN07f1dnF75gxe3Fie7xgnKC4+LHalPSrANMYZ+DvRdukIIesZXHl8nin
	PKQ6MNUGz4QnWn8OOX/Ywd7PXM0MgwKSjj+0S+G2nqrdbEYUi/ShF+8V6
	+xH8W3SRKAbl8MwH4HLtHBdKvEml2aKvikIrV824xJVXaLkYJXw/W83Wd
	NMQNJeELa/JwDdUdbP1VvhjFaM8Zl;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329138106; x=1360674106;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=Oz+E83CPt0ff/fbvEvlUumxY6jWj0LVeUQ4waFsdj9k=;
	b=hyTJVZMvv76brCbSr+A8WKBYPPTy/V1IXPVgPiI037BjygLCBRvqdHKm
	3gJI8aRqR1YOTrSsvVU2SEDGbpDQRzgx8TJEd+QpArFCIEy1EpkS466R3
	O0CxB1gYNMIrzRocFwfvge45TUhm6lJfyhnrpujwa3HvojhJOHCU6CgbL
	KNLsJ4ImSZ2LzlPUZmNc9tCDQAVU5dLjXcRd/tJGa8sbhIffnVAkOab8E
	hNYc5IPO/SjqakGAlfIrjTdNbUItW;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,411,1325458800"; d="scan'208";a="86265459"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:46 +0100
X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="129120241"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:41 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 3D7F076C0A4;
	Mon, 13 Feb 2012 14:01:41 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 14:01:40 +0100
Message-ID: <6587132.0KbvunDmjW@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Add the BTS functionality to the existing vpmu implementation for Intel cpus.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

 xen/arch/x86/hvm/vmx/vmx.c               |   12 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c        |  156 +++++++++++++++++++++++++-----
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |    1 +
 xen/include/asm-x86/hvm/vpmu.h           |    3 +
 xen/include/asm-x86/msr-index.h          |    5 +
 5 files changed, 148 insertions(+), 29 deletions(-)



diff -r 6c666c08cf0d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Mon Feb 13 13:51:51 2012 +0100
@@ -1823,6 +1823,9 @@ static int vmx_msr_read_intercept(unsign
         /* Debug Trace Store is not supported. */
         *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
                        MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
+        /* Perhaps vpmu will change some bits. */
+        if ( vpmu_do_rdmsr(msr, msr_content) )
+            goto done;
         break;
     default:
         if ( vpmu_do_rdmsr(msr, msr_content) )
@@ -1950,9 +1953,14 @@ static int vmx_msr_write_intercept(unsig
         int i, rc = 0;
         uint64_t supported = IA32_DEBUGCTLMSR_LBR | IA32_DEBUGCTLMSR_BTF;
 
-        if ( !msr_content || (msr_content & ~supported) )
+        if ( !msr_content )
             break;
-
+        if ( msr_content & ~supported )
+        {
+            /* Perhaps some other bits are supported in vpmu. */
+            if ( !vpmu_do_wrmsr(msr, msr_content) )
+                break;
+        }
         if ( msr_content & IA32_DEBUGCTLMSR_LBR )
         {
             const struct lbr_info *lbr = last_branch_msr_get();
diff -r 6c666c08cf0d xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 13 13:51:51 2012 +0100
@@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
     struct core2_vpmu_context *core2_vpmu_cxt = NULL;
 
     if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
+    {
+        /* Special handling for BTS */
+        if ( msr == MSR_IA32_DEBUGCTLMSR )
+        {
+            uint64_t supported = IA32_DEBUGCTLMSR_TR | IA32_DEBUGCTLMSR_BTS |
+                                 IA32_DEBUGCTLMSR_BTINT;
+
+            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
+            {
+                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
+                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
+            }
+            if ( msr_content & supported  )
+            {
+                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
+                {
+                    gdprintk(XENLOG_WARNING, "Debug Store is not supported on this cpu\n");
+                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
+                    return 0;
+                }
+                return 1;
+            }
+        }
         return 0;
+    }
 
     core2_vpmu_cxt = vpmu->context;
     switch ( msr )
@@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
                      "which is not supported.\n");
         return 1;
     case MSR_IA32_DS_AREA:
-        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
-        return 1;
+        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
+        {
+            if (!msr_content || !is_canonical_address(msr_content))
+            {
+                gdprintk(XENLOG_WARNING, "Illegal address for IA32_DS_AREA: 0x%lx\n",
+                                                            msr_content);
+                vmx_inject_hw_exception(TRAP_gp_fault, 0);
+                return 1;
+            }
+            else
+            {
+                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
+                break;
+            }
+        }
+        else
+        {
+            gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
+            return 1;
+        }
     case MSR_CORE_PERF_GLOBAL_CTRL:
         global_ctrl = msr_content;
         for ( i = 0; i < core2_get_pmc_count(); i++ )
@@ -466,6 +508,7 @@ static int core2_vpmu_do_wrmsr(unsigned 
         pmu_enable |= core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i];
     for ( i = 0; i < core2_get_pmc_count(); i++ )
         pmu_enable |= core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i];
+    pmu_enable |= core2_vpmu_cxt->pmu_enable->ds_area_enable;
     if ( pmu_enable )
         vpmu_set(vpmu, VPMU_RUNNING);
     else
@@ -491,6 +534,8 @@ static int core2_vpmu_do_wrmsr(unsigned 
                 inject_gp = 1;
             break;
         case MSR_TYPE_CTRL:           /* IA32_FIXED_CTR_CTRL */
+            if  ( msr == MSR_IA32_DS_AREA )
+                break;
             /* 4 bits per counter, currently 3 fixed counters implemented. */
             mask = ~((1ull << (3 * 4)) - 1);
             if (msr_content & mask)
@@ -520,25 +565,35 @@ static int core2_vpmu_do_rdmsr(unsigned 
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     struct core2_vpmu_context *core2_vpmu_cxt = NULL;
 
-    if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
-        return 0;
-
-    core2_vpmu_cxt = vpmu->context;
-    switch ( msr )
+    if ( core2_vpmu_msr_common_check(msr, &type, &index) )
     {
-    case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
-        *msr_content = 0;
-        break;
-    case MSR_CORE_PERF_GLOBAL_STATUS:
-        *msr_content = core2_vpmu_cxt->global_ovf_status;
-        break;
-    case MSR_CORE_PERF_GLOBAL_CTRL:
-        vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
-        break;
-    default:
-        rdmsrl(msr, *msr_content);
+        core2_vpmu_cxt = vpmu->context;
+        switch ( msr )
+        {
+        case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+            *msr_content = 0;
+            break;
+        case MSR_CORE_PERF_GLOBAL_STATUS:
+            *msr_content = core2_vpmu_cxt->global_ovf_status;
+            break;
+        case MSR_CORE_PERF_GLOBAL_CTRL:
+            vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, msr_content);
+            break;
+        default:
+            rdmsrl(msr, *msr_content);
+        }
     }
-
+    else
+    {
+        /* Extension for BTS */
+        if ( msr == MSR_IA32_MISC_ENABLE)
+        {
+            if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
+                *msr_content &= ~MSR_IA32_MISC_ENABLE_BTS_UNAVAIL;
+        }
+        else
+            return 0;
+    }
     return 1;
 }
 
@@ -553,15 +608,24 @@ static int core2_vpmu_do_interrupt(struc
     struct vlapic *vlapic = vcpu_vlapic(v);
 
     rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content);
-    if ( !msr_content )
-        return 0;
+    if ( msr_content )
+    {
+        if ( is_pmc_quirk )
+            handle_pmc_quirk(msr_content);
 
-    if ( is_pmc_quirk )
-        handle_pmc_quirk(msr_content);
-
-    core2_vpmu_cxt->global_ovf_status |= msr_content;
-    msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count()) - 1);
-    wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
+        core2_vpmu_cxt->global_ovf_status |= msr_content;
+        msr_content = 0xC000000700000000 | ((1 << core2_get_pmc_count()) - 1);
+        wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
+    }
+    else
+    {
+        /* No PMC overflow but perhaps a Trace Message interrupt. */
+        msr_content = __vmread(GUEST_IA32_DEBUGCTL);
+        if ( !(msr_content & IA32_DEBUGCTLMSR_TR) )
+        {
+            return 0;
+        }
+    }
 
     apic_write_around(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
 
@@ -582,10 +646,48 @@ static void core2_vpmu_do_cpuid(unsigned
                                 unsigned int *eax, unsigned int *ebx,
                                 unsigned int *ecx, unsigned int *edx)
 {
+    if (input == 0x1)
+    {
+        struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
+        {
+            /* Switch on the 'Debug Store' feature in CPUID.EAX[1]:EDX[21] */
+            *edx |= cpufeat_mask(X86_FEATURE_DS);
+        }
+    }
 }
 
 static void core2_vpmu_initialise(struct vcpu *v)
 {
+    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    u64 msr_content;
+    struct cpuinfo_x86 *c = &current_cpu_data;
+
+    /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
+    if ( cpu_has(c, X86_FEATURE_DS) )
+    {
+        if ( !cpu_has(c, X86_FEATURE_DTES64) )
+        {
+            gdprintk(XENLOG_WARNING, "CPU doesn't support 64-bit DS Area - Debug Store disabled\n");
+            goto func_out;
+        }
+        vpmu_set(vpmu, VPMU_CPU_HAS_DS);
+        rdmsrl(MSR_IA32_MISC_ENABLE, msr_content);
+        if ( msr_content & MSR_IA32_MISC_ENABLE_BTS_UNAVAIL )
+        {
+            /* If BTS_UNAVAIL is set reset the DS feature. */
+            vpmu_reset(vpmu, VPMU_CPU_HAS_DS);
+            gdprintk(XENLOG_WARNING, "CPU has set BTS_UNAVAIL - Debug Store disabled\n");
+        }
+        else
+            vpmu_set(vpmu, VPMU_CPU_HAS_BTS);
+            if ( !cpu_has(c, X86_FEATURE_DSCPL) )
+            {
+                gdprintk(XENLOG_WARNING, "vpmu: cpu doesn't support CPL-Qualified BTS\n");
+            }
+    }
+func_out:
     check_pmc_quirk();
 }
 
diff -r 6c666c08cf0d xen/include/asm-x86/hvm/vmx/vpmu_core2.h
--- a/xen/include/asm-x86/hvm/vmx/vpmu_core2.h	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/include/asm-x86/hvm/vmx/vpmu_core2.h	Mon Feb 13 13:51:51 2012 +0100
@@ -29,6 +29,7 @@ struct arch_msr_pair {
 };
 
 struct core2_pmu_enable {
+    char ds_area_enable;
     char fixed_ctr_enable[3];
     char arch_pmc_enable[1];
 };
diff -r 6c666c08cf0d xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 13 13:51:51 2012 +0100
@@ -72,6 +72,9 @@ struct vpmu_struct {
 #define VPMU_CONTEXT_LOADED                 0x2
 #define VPMU_RUNNING                        0x4
 #define VPMU_PASSIVE_DOMAIN_ALLOCATED       0x8
+#define VPMU_CPU_HAS_DS                     0x10 /* Has Debug Store */
+#define VPMU_CPU_HAS_BTS                    0x20 /* Has Branche Trace Store */
+
 
 #define vpmu_set(_vpmu, _x)    ((_vpmu)->flags |= (_x))
 #define vpmu_reset(_vpmu, _x)  ((_vpmu)->flags &= ~(_x))
diff -r 6c666c08cf0d xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Mon Feb 13 12:36:09 2012 +0100
+++ b/xen/include/asm-x86/msr-index.h	Mon Feb 13 13:51:51 2012 +0100
@@ -67,6 +67,11 @@
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
 #define IA32_DEBUGCTLMSR_LBR		(1<<0) /* Last Branch Record */
 #define IA32_DEBUGCTLMSR_BTF		(1<<1) /* Single Step on Branches */
+#define IA32_DEBUGCTLMSR_TR		(1<<6) /* Trace Message Enable */
+#define IA32_DEBUGCTLMSR_BTS		(1<<7) /* Branch Trace Store */
+#define IA32_DEBUGCTLMSR_BTINT		(1<<8) /* Branch Trace Interrupt */
+#define IA32_DEBUGCTLMSR_BTS_OFF_OS	(1<<9)  /* BTS off if CPL 0 */
+#define IA32_DEBUGCTLMSR_BTS_OFF_USR	(1<<10) /* BTS off if CPL > 0 */
 
 #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
 #define MSR_IA32_LASTBRANCHTOIP		0x000001dc

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:02:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:02:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvXQ-0005DC-BN; Mon, 13 Feb 2012 13:01:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RwvXO-0005Cz-Qj
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:01:47 +0000
Received: from [85.158.139.83:50943] by server-9.bemta-5.messagelabs.com id
	DD/E3-23757-AB9093F4; Mon, 13 Feb 2012 13:01:46 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329138105!12135684!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0NzE0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25305 invoked from network); 13 Feb 2012 13:01:45 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:01:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=tN8U2wHvs7stweGLAToWKNFfd2rrP+pvg10/OIWuGLjNKqwtOtvt6gXS
	Vf1H+OTkZeNAD0UlxVE74VXmVFniRhHU/8G240vsj7G0iWx18nsaJPQUQ
	LwXnlUWPoqEpVunuUbaLCdB9mY9b2D+/22d5e1E95sWSMte3tOK4HMRVY
	02kVaqd2b95KGNTFq2VViSJq/EHSuCdCiVl3gft97X7vXksXF07gB6pEu
	Ie5MC30Tu1jmYuKsEzJX59iih3BUM;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329138106; x=1360674106;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=v5VGWhGKh/8DkjaU4T7uvOzqpy8Tg51/8OIfJnELu9A=;
	b=hehLJmbz8U4CnH59/ImXZ83045jvQ8UHduKuebLGZBCRWMFYZrnPuHSN
	fnsjLDFh90oNU2HtjkPge7BFLaiZ7lPwx4PxcWupJdkoF+3RtU0bxNwog
	NSZ2ItGg/n0qlh4MW76seHuek4nhNW9TdJfBCSxmBl/W7CIgutPU3xTtk
	DKyxLj0B2CTm1hOR2jjg3Gx8GanDCAR7z1GhPuifNKzRhgq+iIWpHtfHa
	2l410sOW62V2+WXI6yXVF0v38g6D9;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,411,1325458800"; d="scan'208";a="86265454"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:45 +0100
X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="129120227"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:35 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 070FE95B855;
	Mon, 13 Feb 2012 14:01:35 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan,
	Haitao" <haitao.shan@intel.com>
Date: Mon, 13 Feb 2012 14:01:34 +0100
Message-ID: <6490841.m6xpzEUAzL@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 1 of 2]  vpmu: Add a cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Add a new function - do_cpuid - to the vpmu struct arch_vpmu_ops.
This permits the vpmu to set specific bits in the cpuid for the hvm guest.


Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


 xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |   7 +++++++
 xen/arch/x86/hvm/vpmu.c           |  10 ++++++++++
 xen/include/asm-x86/hvm/vpmu.h    |   5 +++++
 4 files changed, 24 insertions(+), 0 deletions(-)


diff -r 9ad1e42c341b xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Mon Feb 13 12:36:09 2012 +0100
@@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
             break;
     }
 
+    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
+
     HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
diff -r 9ad1e42c341b xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 13 12:36:09 2012 +0100
@@ -578,6 +578,12 @@ static int core2_vpmu_do_interrupt(struc
     return 1;
 }
 
+static void core2_vpmu_do_cpuid(unsigned int input,
+                                unsigned int *eax, unsigned int *ebx,
+                                unsigned int *ecx, unsigned int *edx)
+{
+}
+
 static void core2_vpmu_initialise(struct vcpu *v)
 {
     check_pmc_quirk();
@@ -602,6 +608,7 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .do_wrmsr = core2_vpmu_do_wrmsr,
     .do_rdmsr = core2_vpmu_do_rdmsr,
     .do_interrupt = core2_vpmu_do_interrupt,
+    .do_cpuid = core2_vpmu_do_cpuid,
     .arch_vpmu_initialise = core2_vpmu_initialise,
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
diff -r 9ad1e42c341b xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/hvm/vpmu.c	Mon Feb 13 12:36:09 2012 +0100
@@ -62,6 +62,16 @@ int vpmu_do_interrupt(struct cpu_user_re
     return 0;
 }
 
+void vpmu_do_cpuid(unsigned int input,
+                   unsigned int *eax, unsigned int *ebx,
+                   unsigned int *ecx, unsigned int *edx)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_cpuid)
+        vpmu->arch_vpmu_ops->do_cpuid(input, eax, ebx, ecx, edx);
+}
+
 void vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
diff -r 9ad1e42c341b xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 13 12:36:09 2012 +0100
@@ -50,6 +50,9 @@ struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content);
     int (*do_rdmsr)(unsigned int msr, uint64_t *msr_content);
     int (*do_interrupt)(struct cpu_user_regs *regs);
+    void (*do_cpuid)(unsigned int input,
+                     unsigned int *eax, unsigned int *ebx,
+                     unsigned int *ecx, unsigned int *edx);
     void (*arch_vpmu_initialise)(struct vcpu *v);
     void (*arch_vpmu_destroy)(struct vcpu *v);
     void (*arch_vpmu_save)(struct vcpu *v);
@@ -78,6 +81,8 @@ struct vpmu_struct {
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 int vpmu_do_interrupt(struct cpu_user_regs *regs);
+void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
+                                       unsigned int *ecx, unsigned int *edx);
 void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
 void vpmu_save(struct vcpu *v);

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:02:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:02:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvXQ-0005DC-BN; Mon, 13 Feb 2012 13:01:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RwvXO-0005Cz-Qj
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:01:47 +0000
Received: from [85.158.139.83:50943] by server-9.bemta-5.messagelabs.com id
	DD/E3-23757-AB9093F4; Mon, 13 Feb 2012 13:01:46 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329138105!12135684!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0NzE0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25305 invoked from network); 13 Feb 2012 13:01:45 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:01:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=tN8U2wHvs7stweGLAToWKNFfd2rrP+pvg10/OIWuGLjNKqwtOtvt6gXS
	Vf1H+OTkZeNAD0UlxVE74VXmVFniRhHU/8G240vsj7G0iWx18nsaJPQUQ
	LwXnlUWPoqEpVunuUbaLCdB9mY9b2D+/22d5e1E95sWSMte3tOK4HMRVY
	02kVaqd2b95KGNTFq2VViSJq/EHSuCdCiVl3gft97X7vXksXF07gB6pEu
	Ie5MC30Tu1jmYuKsEzJX59iih3BUM;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329138106; x=1360674106;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=v5VGWhGKh/8DkjaU4T7uvOzqpy8Tg51/8OIfJnELu9A=;
	b=hehLJmbz8U4CnH59/ImXZ83045jvQ8UHduKuebLGZBCRWMFYZrnPuHSN
	fnsjLDFh90oNU2HtjkPge7BFLaiZ7lPwx4PxcWupJdkoF+3RtU0bxNwog
	NSZ2ItGg/n0qlh4MW76seHuek4nhNW9TdJfBCSxmBl/W7CIgutPU3xTtk
	DKyxLj0B2CTm1hOR2jjg3Gx8GanDCAR7z1GhPuifNKzRhgq+iIWpHtfHa
	2l410sOW62V2+WXI6yXVF0v38g6D9;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,411,1325458800"; d="scan'208";a="86265454"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:45 +0100
X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="129120227"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:35 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 070FE95B855;
	Mon, 13 Feb 2012 14:01:35 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Shan,
	Haitao" <haitao.shan@intel.com>
Date: Mon, 13 Feb 2012 14:01:34 +0100
Message-ID: <6490841.m6xpzEUAzL@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 1 of 2]  vpmu: Add a cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Add a new function - do_cpuid - to the vpmu struct arch_vpmu_ops.
This permits the vpmu to set specific bits in the cpuid for the hvm guest.


Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


 xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |   7 +++++++
 xen/arch/x86/hvm/vpmu.c           |  10 ++++++++++
 xen/include/asm-x86/hvm/vpmu.h    |   5 +++++
 4 files changed, 24 insertions(+), 0 deletions(-)


diff -r 9ad1e42c341b xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Mon Feb 13 12:36:09 2012 +0100
@@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
             break;
     }
 
+    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
+
     HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
diff -r 9ad1e42c341b xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 13 12:36:09 2012 +0100
@@ -578,6 +578,12 @@ static int core2_vpmu_do_interrupt(struc
     return 1;
 }
 
+static void core2_vpmu_do_cpuid(unsigned int input,
+                                unsigned int *eax, unsigned int *ebx,
+                                unsigned int *ecx, unsigned int *edx)
+{
+}
+
 static void core2_vpmu_initialise(struct vcpu *v)
 {
     check_pmc_quirk();
@@ -602,6 +608,7 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .do_wrmsr = core2_vpmu_do_wrmsr,
     .do_rdmsr = core2_vpmu_do_rdmsr,
     .do_interrupt = core2_vpmu_do_interrupt,
+    .do_cpuid = core2_vpmu_do_cpuid,
     .arch_vpmu_initialise = core2_vpmu_initialise,
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
diff -r 9ad1e42c341b xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/hvm/vpmu.c	Mon Feb 13 12:36:09 2012 +0100
@@ -62,6 +62,16 @@ int vpmu_do_interrupt(struct cpu_user_re
     return 0;
 }
 
+void vpmu_do_cpuid(unsigned int input,
+                   unsigned int *eax, unsigned int *ebx,
+                   unsigned int *ecx, unsigned int *edx)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_cpuid)
+        vpmu->arch_vpmu_ops->do_cpuid(input, eax, ebx, ecx, edx);
+}
+
 void vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
diff -r 9ad1e42c341b xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 13 12:36:09 2012 +0100
@@ -50,6 +50,9 @@ struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content);
     int (*do_rdmsr)(unsigned int msr, uint64_t *msr_content);
     int (*do_interrupt)(struct cpu_user_regs *regs);
+    void (*do_cpuid)(unsigned int input,
+                     unsigned int *eax, unsigned int *ebx,
+                     unsigned int *ecx, unsigned int *edx);
     void (*arch_vpmu_initialise)(struct vcpu *v);
     void (*arch_vpmu_destroy)(struct vcpu *v);
     void (*arch_vpmu_save)(struct vcpu *v);
@@ -78,6 +81,8 @@ struct vpmu_struct {
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 int vpmu_do_interrupt(struct cpu_user_regs *regs);
+void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
+                                       unsigned int *ecx, unsigned int *edx);
 void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
 void vpmu_save(struct vcpu *v);

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:03:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvYQ-0005Ky-BW; Mon, 13 Feb 2012 13:02:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RwvYO-0005Kh-TY
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:02:49 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329138118!62615181!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0NzE0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22391 invoked from network); 13 Feb 2012 13:01:58 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:01:58 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=iKF6mPF1FqjhLGMcGk/ZiOiQpk2aPcOzUYeSbnpf/9iZxPs9PCG2Xsk8
	zBIz53U/Swv6SO273WX4dB7jwb70cNswVZ45HgoZEgekMXeCCYRtVhgxX
	NqH6/IzxooYBIOf+I26k7Oz0iYjvU5dK+ELNQ2KRtxw+5qFvhK/PJV7YB
	oGCVsZFrJGqeSYPD6x0M6sSuoD6+GiQpk6rL4HBrlfDbucG51yzfPmkcO
	41zbFpDaE5qdRO6l+8RtIH23DmvmI;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329138168; x=1360674168;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=dozKdCXACBcEHWNHemBZ9xFH1l+XAwD9vJAhCzcymuw=;
	b=KCSW1GTgrNqpIj4kCMkoTPOTj+vT3uxQgkYBdyD/C2FXewpOeWBQTx54
	UvRP7wNk3f2ubaU8f/Hic5nlurZhVjuCZC5mh0fWcjSfJE5ASrv/G7r7B
	g6FAgx1m03/8I3xzjJOf7HYxbeMDBdNTrn/WsGKgC/MK+/Uv4B9fFgkRy
	Mf3u7hQx5gCZ4fp1/VI1Dt5awZ41Uu1qaCo8d3rTacY4B6DqDeqxT6I/O
	qObGv+jabaRgOQH+SKST6BPSxZv2c;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,411,1325458800"; d="scan'208";a="86265453"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:45 +0100
X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="129120215"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:29 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 0B72F95B855;
	Mon, 13 Feb 2012 14:01:29 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 14:01:28 +0100
Message-ID: <2237338.fmj3s7t1UQ@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 0 of 2] vpmu: Add Intel BTS functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

these 2 patches add BTS (Branch Trace Store) functionality of Intel Core2
cpus to the vpmu.

This feature gets switched on if the cpu is generally supported from the vpmu
and if the cpu supports the DS (Debug Store) bit in the cpuid.eax[0x1].edx[21]
and if BTS is supported in the MSR_IA32_MISC_ENABLE.
If the cpu supports CPL-qualified BTS in the cpuid, this is also supported
here.

The interface of the struct arch_vpmu_ops was extended with a new function
pointer do_cpuid. The function gets called in vmx_cpuid_intercept() allowing
the vpmu handling to switch on the DS bit in the guest. If this is not
wanted the user must configure this bit in the guest configuration file with
the command "cpuid=..."

xen/arch/x86/hvm/vmx/vmx.c               |    2 +
 xen/arch/x86/hvm/vmx/vpmu_core2.c        |    7 +
 xen/arch/x86/hvm/vpmu.c                  |   10 +
 xen/include/asm-x86/hvm/vpmu.h           |    5 +
 xen/arch/x86/hvm/vmx/vmx.c               |   12 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c        |  156 +++++++++++++++++++++++++-----
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |    1 +
 xen/include/asm-x86/hvm/vpmu.h           |    3 +
 xen/include/asm-x86/msr-index.h          |    5 +
 9 files changed, 172 insertions(+), 29 deletions(-)

Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:03:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvYQ-0005Ky-BW; Mon, 13 Feb 2012 13:02:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RwvYO-0005Kh-TY
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:02:49 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329138118!62615181!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0NzE0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22391 invoked from network); 13 Feb 2012 13:01:58 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:01:58 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=iKF6mPF1FqjhLGMcGk/ZiOiQpk2aPcOzUYeSbnpf/9iZxPs9PCG2Xsk8
	zBIz53U/Swv6SO273WX4dB7jwb70cNswVZ45HgoZEgekMXeCCYRtVhgxX
	NqH6/IzxooYBIOf+I26k7Oz0iYjvU5dK+ELNQ2KRtxw+5qFvhK/PJV7YB
	oGCVsZFrJGqeSYPD6x0M6sSuoD6+GiQpk6rL4HBrlfDbucG51yzfPmkcO
	41zbFpDaE5qdRO6l+8RtIH23DmvmI;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329138168; x=1360674168;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=dozKdCXACBcEHWNHemBZ9xFH1l+XAwD9vJAhCzcymuw=;
	b=KCSW1GTgrNqpIj4kCMkoTPOTj+vT3uxQgkYBdyD/C2FXewpOeWBQTx54
	UvRP7wNk3f2ubaU8f/Hic5nlurZhVjuCZC5mh0fWcjSfJE5ASrv/G7r7B
	g6FAgx1m03/8I3xzjJOf7HYxbeMDBdNTrn/WsGKgC/MK+/Uv4B9fFgkRy
	Mf3u7hQx5gCZ4fp1/VI1Dt5awZ41Uu1qaCo8d3rTacY4B6DqDeqxT6I/O
	qObGv+jabaRgOQH+SKST6BPSxZv2c;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,411,1325458800"; d="scan'208";a="86265453"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:45 +0100
X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="129120215"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 13 Feb 2012 14:01:29 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 0B72F95B855;
	Mon, 13 Feb 2012 14:01:29 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 14:01:28 +0100
Message-ID: <2237338.fmj3s7t1UQ@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: "Shan, Haitao" <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 0 of 2] vpmu: Add Intel BTS functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

these 2 patches add BTS (Branch Trace Store) functionality of Intel Core2
cpus to the vpmu.

This feature gets switched on if the cpu is generally supported from the vpmu
and if the cpu supports the DS (Debug Store) bit in the cpuid.eax[0x1].edx[21]
and if BTS is supported in the MSR_IA32_MISC_ENABLE.
If the cpu supports CPL-qualified BTS in the cpuid, this is also supported
here.

The interface of the struct arch_vpmu_ops was extended with a new function
pointer do_cpuid. The function gets called in vmx_cpuid_intercept() allowing
the vpmu handling to switch on the DS bit in the guest. If this is not
wanted the user must configure this bit in the guest configuration file with
the command "cpuid=..."

xen/arch/x86/hvm/vmx/vmx.c               |    2 +
 xen/arch/x86/hvm/vmx/vpmu_core2.c        |    7 +
 xen/arch/x86/hvm/vpmu.c                  |   10 +
 xen/include/asm-x86/hvm/vpmu.h           |    5 +
 xen/arch/x86/hvm/vmx/vmx.c               |   12 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c        |  156 +++++++++++++++++++++++++-----
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |    1 +
 xen/include/asm-x86/hvm/vpmu.h           |    3 +
 xen/include/asm-x86/msr-index.h          |    5 +
 9 files changed, 172 insertions(+), 29 deletions(-)

Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:10:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvfC-0005gv-9i; Mon, 13 Feb 2012 13:09: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 1RwvfA-0005gp-Dl
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:09:48 +0000
Received: from [85.158.139.83:21049] by server-12.bemta-5.messagelabs.com id
	6B/F2-30830-A9B093F4; Mon, 13 Feb 2012 13:09:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329138585!12137268!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24334 invoked from network); 13 Feb 2012 13:09:46 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:09:46 -0000
Received: by wgbdr13 with SMTP id dr13so4336815wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 05:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=qyoKSBmsxWICWVhdkZnxlXtzY1QadvjgySIHtfMknAo=;
	b=SC8ri5CO4snrv9p7pYKExPmcx/39cXWo6OnGWPdXr7fCp1Zr5i3pODclzpH8pgvkIs
	mVDPKF2tEBC5Esk8VTcRtus1On/e3S9j+R664pSdXlKRS/wPFEz+sfFXMpslIgfdiZyA
	QRug1cZOKA0uCpjaFuxIwNQc8UxNeN+//CIac=
Received: by 10.216.131.215 with SMTP id m65mr6049830wei.54.1329138585494;
	Mon, 13 Feb 2012 05:09:45 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m8sm46585301wia.11.2012.02.13.05.09.43
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 05:09:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 13:09:39 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB5EBC13.3935F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
	optional
Thread-Index: AczqUL3UG+yOmrMOBkqEIZqI00+ghQ==
In-Reply-To: <1329137769.31256.102.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/2012 12:56, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-02-13 at 12:51 +0000, Keir Fraser wrote:
>> On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>> 
>>> This patch set mainly allows the user to build a seabios or rombios only
>>> version of hvmloader.
>>> In addition, when building a seabios only hvmloader, Option ROMs like
>>> vgabios and etherboot are no longer required, and therefore can be disabled
>>> from the build. Dependency on the bcc compiler can also be avoided the
>>> same way.
>> 
>> Applied, but I wonder why we still have the rombios support? Could we switch
>> over to seabios for 4.2 and get rid of the crufty old rombios code entirely?
> 
> We still use ROMBIOS with the traditional qemu-xen tree, I think we have
> to do that for compatibility with existing guests, for the same reason
> as we need to continue to support that traditional qemu-xen tree.

So guests that were installed with old qemu need to always boot with old
qemu? Because if the compatibility issue is only with saved guests, then we
don't need to keep old ROMBIOS around as it lives in saved-guest memory.

 -- Keir

> Post 4.2 we will be switching the default qemu to the upstream tree
> which uses SeaBIOS at which point the old-qemu+ROMBIOS combo becomes
> legacy/frozen etc. We don't support new-qemu+ROMBIOS nor old-qemu
> +SEABIOS.
> 
> Ian.
> 
>> 
>>  -- Keir
>> 
>>> v2: Separate patches for separate issues
>>>    Introduced config option to select which NIC to build ROM for
>>>    Fixed initial patch to build multiple etherboot ROMs in hvmloader
>>>    Option ROMs are keyed off wether or not rombios is enabled, rather than
>>> on an individual basis
>>>    Introduced config options to select support for rombios/seabios
>>> 
>>> v3: Fix mkhex script to take several file arguments on the command line
>>>     Reorganize hvmloader option ROM loading code to make it optionnal, and
>>> make bios->load_roms a callback that the BIOS support code has to implement
>>> if option ROM loading is desired.
>>>     Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
>>> created.
>>> 
>>> Julian Pidancet (5):
>>>   hvmloader: Only compile 32bitbios_support.c when rombios is enabled
>>>   hvmloader: Allow the mkhex command to take several file arguments
>>>   firmware: Use mkhex from hvmloader directory for etherboot ROMs
>>>   hvmloader: Move option ROM loading into a separate optionnal file
>>>   firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
>>> 
>>>  Config.mk                             |    5 +
>>>  tools/firmware/Makefile               |   18 ++--
>>>  tools/firmware/etherboot/Config       |    2 -
>>>  tools/firmware/etherboot/Makefile     |   13 +--
>>>  tools/firmware/hvmloader/Makefile     |   39 ++++---
>>>  tools/firmware/hvmloader/config.h     |    3 +-
>>>  tools/firmware/hvmloader/hvmloader.c  |  218
>>> +--------------------------------
>>>  tools/firmware/hvmloader/mkhex        |    3 +-
>>>  tools/firmware/hvmloader/option_rom.h |    7 +
>>>  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
>>>  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
>>>  tools/firmware/hvmloader/seabios.c    |    5 +-
>>>  12 files changed, 302 insertions(+), 263 deletions(-)
>>>  create mode 100644 tools/firmware/hvmloader/optionroms.c
>> 
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:10:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvfC-0005gv-9i; Mon, 13 Feb 2012 13:09: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 1RwvfA-0005gp-Dl
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:09:48 +0000
Received: from [85.158.139.83:21049] by server-12.bemta-5.messagelabs.com id
	6B/F2-30830-A9B093F4; Mon, 13 Feb 2012 13:09:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329138585!12137268!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24334 invoked from network); 13 Feb 2012 13:09:46 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:09:46 -0000
Received: by wgbdr13 with SMTP id dr13so4336815wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 05:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=qyoKSBmsxWICWVhdkZnxlXtzY1QadvjgySIHtfMknAo=;
	b=SC8ri5CO4snrv9p7pYKExPmcx/39cXWo6OnGWPdXr7fCp1Zr5i3pODclzpH8pgvkIs
	mVDPKF2tEBC5Esk8VTcRtus1On/e3S9j+R664pSdXlKRS/wPFEz+sfFXMpslIgfdiZyA
	QRug1cZOKA0uCpjaFuxIwNQc8UxNeN+//CIac=
Received: by 10.216.131.215 with SMTP id m65mr6049830wei.54.1329138585494;
	Mon, 13 Feb 2012 05:09:45 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m8sm46585301wia.11.2012.02.13.05.09.43
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 05:09:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 13:09:39 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB5EBC13.3935F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
	optional
Thread-Index: AczqUL3UG+yOmrMOBkqEIZqI00+ghQ==
In-Reply-To: <1329137769.31256.102.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/2012 12:56, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-02-13 at 12:51 +0000, Keir Fraser wrote:
>> On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>> 
>>> This patch set mainly allows the user to build a seabios or rombios only
>>> version of hvmloader.
>>> In addition, when building a seabios only hvmloader, Option ROMs like
>>> vgabios and etherboot are no longer required, and therefore can be disabled
>>> from the build. Dependency on the bcc compiler can also be avoided the
>>> same way.
>> 
>> Applied, but I wonder why we still have the rombios support? Could we switch
>> over to seabios for 4.2 and get rid of the crufty old rombios code entirely?
> 
> We still use ROMBIOS with the traditional qemu-xen tree, I think we have
> to do that for compatibility with existing guests, for the same reason
> as we need to continue to support that traditional qemu-xen tree.

So guests that were installed with old qemu need to always boot with old
qemu? Because if the compatibility issue is only with saved guests, then we
don't need to keep old ROMBIOS around as it lives in saved-guest memory.

 -- Keir

> Post 4.2 we will be switching the default qemu to the upstream tree
> which uses SeaBIOS at which point the old-qemu+ROMBIOS combo becomes
> legacy/frozen etc. We don't support new-qemu+ROMBIOS nor old-qemu
> +SEABIOS.
> 
> Ian.
> 
>> 
>>  -- Keir
>> 
>>> v2: Separate patches for separate issues
>>>    Introduced config option to select which NIC to build ROM for
>>>    Fixed initial patch to build multiple etherboot ROMs in hvmloader
>>>    Option ROMs are keyed off wether or not rombios is enabled, rather than
>>> on an individual basis
>>>    Introduced config options to select support for rombios/seabios
>>> 
>>> v3: Fix mkhex script to take several file arguments on the command line
>>>     Reorganize hvmloader option ROM loading code to make it optionnal, and
>>> make bios->load_roms a callback that the BIOS support code has to implement
>>> if option ROM loading is desired.
>>>     Cosmetic change in tools/firmware/Makefile in the way seabios-dir is
>>> created.
>>> 
>>> Julian Pidancet (5):
>>>   hvmloader: Only compile 32bitbios_support.c when rombios is enabled
>>>   hvmloader: Allow the mkhex command to take several file arguments
>>>   firmware: Use mkhex from hvmloader directory for etherboot ROMs
>>>   hvmloader: Move option ROM loading into a separate optionnal file
>>>   firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
>>> 
>>>  Config.mk                             |    5 +
>>>  tools/firmware/Makefile               |   18 ++--
>>>  tools/firmware/etherboot/Config       |    2 -
>>>  tools/firmware/etherboot/Makefile     |   13 +--
>>>  tools/firmware/hvmloader/Makefile     |   39 ++++---
>>>  tools/firmware/hvmloader/config.h     |    3 +-
>>>  tools/firmware/hvmloader/hvmloader.c  |  218
>>> +--------------------------------
>>>  tools/firmware/hvmloader/mkhex        |    3 +-
>>>  tools/firmware/hvmloader/option_rom.h |    7 +
>>>  tools/firmware/hvmloader/optionroms.c |  189 ++++++++++++++++++++++++++++
>>>  tools/firmware/hvmloader/rombios.c    |   63 +++++++++-
>>>  tools/firmware/hvmloader/seabios.c    |    5 +-
>>>  12 files changed, 302 insertions(+), 263 deletions(-)
>>>  create mode 100644 tools/firmware/hvmloader/optionroms.c
>> 
>> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoD-00069l-Ea; Mon, 13 Feb 2012 13:19:09 +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 1RwvoB-00069V-TD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329139008!52493123!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32605 invoked from network); 13 Feb 2012 13:16:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:16:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488132"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:01 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujA024703;
	Mon, 13 Feb 2012 05:19:00 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 13:18:46 +0000
Message-ID: <1329139131-27554-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] libfdt: add to build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>
---
 xen/arch/arm/Rules.mk      |    2 ++
 xen/common/Makefile        |    1 +
 xen/common/libfdt/Makefile |    5 +++++
 3 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 336e209..14082dd 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,6 +6,8 @@
 # 'make clean' before rebuilding.
 #
 
+HAS_DEVICE_TREE := y
+
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
 CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
 CFLAGS += -I$(BASEDIR)/include
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..4b1e6f2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,3 +59,4 @@ subdir-$(x86_64) += hvm
 subdir-$(ia64) += hvm
 
 subdir-y += libelf
+subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
new file mode 100644
index 0000000..0e65bc0
--- /dev/null
+++ b/xen/common/libfdt/Makefile
@@ -0,0 +1,5 @@
+include Makefile.libfdt
+
+obj-y += $(LIBFDT_OBJS)
+
+CFLAGS += -I.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoD-00069l-Ea; Mon, 13 Feb 2012 13:19:09 +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 1RwvoB-00069V-TD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329139008!52493123!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32605 invoked from network); 13 Feb 2012 13:16:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:16:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488132"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:01 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujA024703;
	Mon, 13 Feb 2012 05:19:00 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 13:18:46 +0000
Message-ID: <1329139131-27554-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] libfdt: add to build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>
---
 xen/arch/arm/Rules.mk      |    2 ++
 xen/common/Makefile        |    1 +
 xen/common/libfdt/Makefile |    5 +++++
 3 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 336e209..14082dd 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,6 +6,8 @@
 # 'make clean' before rebuilding.
 #
 
+HAS_DEVICE_TREE := y
+
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
 CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
 CFLAGS += -I$(BASEDIR)/include
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..4b1e6f2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,3 +59,4 @@ subdir-$(x86_64) += hvm
 subdir-$(ia64) += hvm
 
 subdir-y += libelf
+subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
new file mode 100644
index 0000000..0e65bc0
--- /dev/null
+++ b/xen/common/libfdt/Makefile
@@ -0,0 +1,5 @@
+include Makefile.libfdt
+
+obj-y += $(LIBFDT_OBJS)
+
+CFLAGS += -I.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoD-00069s-Si; Mon, 13 Feb 2012 13:19:09 +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 1RwvoC-00069W-Gu
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329139008!52493123!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32676 invoked from network); 13 Feb 2012 13:16:50 -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;
	13 Feb 2012 13:16:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488136"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:02 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujC024703;
	Mon, 13 Feb 2012 05:19:01 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:48 +0000
Message-ID: <1329139131-27554-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] arm: map device tree blob in initial page
	tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add a mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

It is mapped into the first L2 slot after the fixmap.  When this slot
is reused in setup_pagetables(), flush the TLB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/head.S          |    9 +++++++++
 xen/arch/arm/mm.c            |    5 +++--
 xen/include/asm-arm/config.h |    6 ++++++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index ea557c2..8b23424 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -202,7 +202,16 @@ hyp:
        orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
        add   r4, r4, #8
        strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#else
+       add   r4, r4, #8             /* Skip over unused fixmap slot */
 #endif
+       mov   r3, #0x0
+       lsr   r2, r8, #21
+       lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+       orr   r2, r2, #0xf00
+       orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+       add   r4, r4, #8
+       strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
        PRINT("- Turning on paging -\r\n")
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c863507..f1fe4ba 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -161,10 +161,11 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
 
     xen_paddr = XEN_PADDR;
 
-    /* Map the destination in the empty L2 above the fixmap */
-    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    /* Map the destination in the boot misc area. */
+    dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
     write_pte(xen_second + second_table_offset(dest_va), pte);
+    flush_xen_data_tlb_va(dest_va);
 
     /* Calculate virt-to-phys offset for the new location */
     phys_offset = xen_paddr - (unsigned long) _start;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 9294f8f..c2ab0a2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -55,15 +55,21 @@
  *  0  -   2M   Unmapped
  *  2M -   4M   Xen text, data, bss
  *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *  6M  -  8M   Early boot misc (see below)
  *
  * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  *
  *  1G -   2G   Xenheap: always-mapped memory
  *  2G -   4G   Domheap: on-demand-mapped
+ *
+ * The early boot misc area is used:
+ *   - in head.S for the DTB for device_tree_early_init().
+ *   - 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
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoD-00069s-Si; Mon, 13 Feb 2012 13:19:09 +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 1RwvoC-00069W-Gu
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329139008!52493123!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32676 invoked from network); 13 Feb 2012 13:16:50 -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;
	13 Feb 2012 13:16:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488136"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:02 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujC024703;
	Mon, 13 Feb 2012 05:19:01 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:48 +0000
Message-ID: <1329139131-27554-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] arm: map device tree blob in initial page
	tables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add a mapping for the device tree blob in the initial page tables.
This will allow the DTB to be parsed for memory information prior to
setting up the real page tables.

It is mapped into the first L2 slot after the fixmap.  When this slot
is reused in setup_pagetables(), flush the TLB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/head.S          |    9 +++++++++
 xen/arch/arm/mm.c            |    5 +++--
 xen/include/asm-arm/config.h |    6 ++++++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index ea557c2..8b23424 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -202,7 +202,16 @@ hyp:
        orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
        add   r4, r4, #8
        strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+#else
+       add   r4, r4, #8             /* Skip over unused fixmap slot */
 #endif
+       mov   r3, #0x0
+       lsr   r2, r8, #21
+       lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+       orr   r2, r2, #0xf00
+       orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+       add   r4, r4, #8
+       strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
        PRINT("- Turning on paging -\r\n")
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c863507..f1fe4ba 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -161,10 +161,11 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
 
     xen_paddr = XEN_PADDR;
 
-    /* Map the destination in the empty L2 above the fixmap */
-    dest_va = FIXMAP_ADDR(0) + (1u << SECOND_SHIFT);
+    /* Map the destination in the boot misc area. */
+    dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
     write_pte(xen_second + second_table_offset(dest_va), pte);
+    flush_xen_data_tlb_va(dest_va);
 
     /* Calculate virt-to-phys offset for the new location */
     phys_offset = xen_paddr - (unsigned long) _start;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 9294f8f..c2ab0a2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -55,15 +55,21 @@
  *  0  -   2M   Unmapped
  *  2M -   4M   Xen text, data, bss
  *  4M -   6M   Fixmap: special-purpose 4K mapping slots
+ *  6M  -  8M   Early boot misc (see below)
  *
  * 32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  *
  *  1G -   2G   Xenheap: always-mapped memory
  *  2G -   4G   Domheap: on-demand-mapped
+ *
+ * The early boot misc area is used:
+ *   - in head.S for the DTB for device_tree_early_init().
+ *   - 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
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoH-0006AN-AY; Mon, 13 Feb 2012 13:19:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RwvoE-00069Y-S5
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329139140!11154918!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28385 invoked from network); 13 Feb 2012 13:19:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:19:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488128"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:18:59 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIuj8024703;
	Mon, 13 Feb 2012 05:18:57 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 13:18:44 +0000
Message-ID: <1329139131-27554-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git

This will be used by Xen to parse the DTBs provided by bootloaders on
ARM platforms.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/libfdt/Makefile.libfdt   |   10 +
 xen/common/libfdt/TODO              |    3 +
 xen/common/libfdt/fdt.c             |  222 +++++++
 xen/common/libfdt/fdt.h             |   60 ++
 xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
 xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
 xen/common/libfdt/fdt_strerror.c    |   96 +++
 xen/common/libfdt/fdt_sw.c          |  256 ++++++++
 xen/common/libfdt/fdt_wip.c         |  118 ++++
 xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
 xen/common/libfdt/libfdt_env.h      |   23 +
 xen/common/libfdt/libfdt_internal.h |   95 +++
 xen/common/libfdt/version.lds       |   54 ++
 13 files changed, 3211 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile.libfdt
 create mode 100644 xen/common/libfdt/TODO
 create mode 100644 xen/common/libfdt/fdt.c
 create mode 100644 xen/common/libfdt/fdt.h
 create mode 100644 xen/common/libfdt/fdt_ro.c
 create mode 100644 xen/common/libfdt/fdt_rw.c
 create mode 100644 xen/common/libfdt/fdt_strerror.c
 create mode 100644 xen/common/libfdt/fdt_sw.c
 create mode 100644 xen/common/libfdt/fdt_wip.c
 create mode 100644 xen/common/libfdt/libfdt.h
 create mode 100644 xen/common/libfdt/libfdt_env.h
 create mode 100644 xen/common/libfdt/libfdt_internal.h
 create mode 100644 xen/common/libfdt/version.lds

diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
new file mode 100644
index 0000000..d55a6f8
--- /dev/null
+++ b/xen/common/libfdt/Makefile.libfdt
@@ -0,0 +1,10 @@
+# Makefile.libfdt
+#
+# This is not a complete Makefile of itself.  Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_VERSION = version.lds
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
new file mode 100644
index 0000000..288437e
--- /dev/null
+++ b/xen/common/libfdt/TODO
@@ -0,0 +1,3 @@
+- Tree traversal functions
+- Graft function
+- Complete libfdt.h documenting comments
diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
new file mode 100644
index 0000000..e56833a
--- /dev/null
+++ b/xen/common/libfdt/fdt.c
@@ -0,0 +1,222 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_check_header(const void *fdt)
+{
+	if (fdt_magic(fdt) == FDT_MAGIC) {
+		/* Complete tree */
+		if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+		if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+	} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+		/* Unfinished sequential-write blob */
+		if (fdt_size_dt_struct(fdt) == 0)
+			return -FDT_ERR_BADSTATE;
+	} else {
+		return -FDT_ERR_BADMAGIC;
+	}
+
+	return 0;
+}
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
+{
+	const char *p;
+
+	if (fdt_version(fdt) >= 0x11)
+		if (((offset + len) < offset)
+		    || ((offset + len) > fdt_size_dt_struct(fdt)))
+			return NULL;
+
+	p = _fdt_offset_ptr(fdt, offset);
+
+	if (p + len < p)
+		return NULL;
+	return p;
+}
+
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+	const uint32_t *tagp, *lenp;
+	uint32_t tag;
+	int offset = startoffset;
+	const char *p;
+
+	*nextoffset = -FDT_ERR_TRUNCATED;
+	tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
+	if (!tagp)
+		return FDT_END; /* premature end */
+	tag = fdt32_to_cpu(*tagp);
+	offset += FDT_TAGSIZE;
+
+	*nextoffset = -FDT_ERR_BADSTRUCTURE;
+	switch (tag) {
+	case FDT_BEGIN_NODE:
+		/* skip name */
+		do {
+			p = fdt_offset_ptr(fdt, offset++, 1);
+		} while (p && (*p != '\0'));
+		if (!p)
+			return FDT_END; /* premature end */
+		break;
+
+	case FDT_PROP:
+		lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
+		if (!lenp)
+			return FDT_END; /* premature end */
+		/* skip-name offset, length and value */
+		offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+			+ fdt32_to_cpu(*lenp);
+		break;
+
+	case FDT_END:
+	case FDT_END_NODE:
+	case FDT_NOP:
+		break;
+
+	default:
+		return FDT_END;
+	}
+
+	if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
+		return FDT_END; /* premature end */
+
+	*nextoffset = FDT_TAGALIGN(offset);
+	return tag;
+}
+
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int _fdt_check_prop_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int fdt_next_node(const void *fdt, int offset, int *depth)
+{
+	int nextoffset = 0;
+	uint32_t tag;
+
+	if (offset >= 0)
+		if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+			return nextoffset;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_PROP:
+		case FDT_NOP:
+			break;
+
+		case FDT_BEGIN_NODE:
+			if (depth)
+				(*depth)++;
+			break;
+
+		case FDT_END_NODE:
+			if (depth && ((--(*depth)) < 0))
+				return nextoffset;
+			break;
+
+		case FDT_END:
+			if ((nextoffset >= 0)
+			    || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
+				return -FDT_ERR_NOTFOUND;
+			else
+				return nextoffset;
+		}
+	} while (tag != FDT_BEGIN_NODE);
+
+	return offset;
+}
+
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+{
+	int len = strlen(s) + 1;
+	const char *last = strtab + tabsize - len;
+	const char *p;
+
+	for (p = strtab; p <= last; p++)
+		if (memcmp(p, s, len) == 0)
+			return p;
+	return NULL;
+}
+
+int fdt_move(const void *fdt, void *buf, int bufsize)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_totalsize(fdt) > bufsize)
+		return -FDT_ERR_NOSPACE;
+
+	memmove(buf, fdt, fdt_totalsize(fdt));
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
new file mode 100644
index 0000000..48ccfd9
--- /dev/null
+++ b/xen/common/libfdt/fdt.h
@@ -0,0 +1,60 @@
+#ifndef _FDT_H
+#define _FDT_H
+
+#ifndef __ASSEMBLY__
+
+struct fdt_header {
+	uint32_t magic;			 /* magic word FDT_MAGIC */
+	uint32_t totalsize;		 /* total size of DT block */
+	uint32_t off_dt_struct;		 /* offset to structure */
+	uint32_t off_dt_strings;	 /* offset to strings */
+	uint32_t off_mem_rsvmap;	 /* offset to memory reserve map */
+	uint32_t version;		 /* format version */
+	uint32_t last_comp_version;	 /* last compatible version */
+
+	/* version 2 fields below */
+	uint32_t boot_cpuid_phys;	 /* Which physical CPU id we're
+					    booting on */
+	/* version 3 fields below */
+	uint32_t size_dt_strings;	 /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;	 /* size of the structure block */
+};
+
+struct fdt_reserve_entry {
+	uint64_t address;
+	uint64_t size;
+};
+
+struct fdt_node_header {
+	uint32_t tag;
+	char name[0];
+};
+
+struct fdt_property {
+	uint32_t tag;
+	uint32_t len;
+	uint32_t nameoff;
+	char data[0];
+};
+
+#endif /* !__ASSEMBLY */
+
+#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_TAGSIZE	sizeof(uint32_t)
+
+#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
+#define FDT_END_NODE	0x2		/* End node */
+#define FDT_PROP	0x3		/* Property: name off,
+					   size, content */
+#define FDT_NOP		0x4		/* nop */
+#define FDT_END		0x9
+
+#define FDT_V1_SIZE	(7*sizeof(uint32_t))
+#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(uint32_t))
+#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V16_SIZE	FDT_V3_SIZE
+#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(uint32_t))
+
+#endif /* _FDT_H */
diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
new file mode 100644
index 0000000..02b6d68
--- /dev/null
+++ b/xen/common/libfdt/fdt_ro.c
@@ -0,0 +1,574 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_nodename_eq(const void *fdt, int offset,
+			    const char *s, int len)
+{
+	const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+
+	if (! p)
+		/* short match */
+		return 0;
+
+	if (memcmp(p, s, len) != 0)
+		return 0;
+
+	if (p[len] == '\0')
+		return 1;
+	else if (!memchr(s, '@', len) && (p[len] == '@'))
+		return 1;
+	else
+		return 0;
+}
+
+const char *fdt_string(const void *fdt, int stroffset)
+{
+	return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+}
+
+static int _fdt_string_eq(const void *fdt, int stroffset,
+			  const char *s, int len)
+{
+	const char *p = fdt_string(fdt, stroffset);
+
+	return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+}
+
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
+{
+	FDT_CHECK_HEADER(fdt);
+	*address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
+	*size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+	return 0;
+}
+
+int fdt_num_mem_rsv(const void *fdt)
+{
+	int i = 0;
+
+	while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+		i++;
+	return i;
+}
+
+static int _nextprop(const void *fdt, int offset)
+{
+	uint32_t tag;
+	int nextoffset;
+
+	do {
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_END:
+			if (nextoffset >= 0)
+				return -FDT_ERR_BADSTRUCTURE;
+			else
+				return nextoffset;
+
+		case FDT_PROP:
+			return offset;
+		}
+		offset = nextoffset;
+	} while (tag == FDT_NOP);
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
+			       const char *name, int namelen)
+{
+	int depth;
+
+	FDT_CHECK_HEADER(fdt);
+
+	for (depth = 0;
+	     (offset >= 0) && (depth >= 0);
+	     offset = fdt_next_node(fdt, offset, &depth))
+		if ((depth == 1)
+		    && _fdt_nodename_eq(fdt, offset, name, namelen))
+			return offset;
+
+	if (depth < 0)
+		return -FDT_ERR_NOTFOUND;
+	return offset; /* error */
+}
+
+int fdt_subnode_offset(const void *fdt, int parentoffset,
+		       const char *name)
+{
+	return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_path_offset(const void *fdt, const char *path)
+{
+	const char *end = path + strlen(path);
+	const char *p = path;
+	int offset = 0;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* see if we have an alias */
+	if (*path != '/') {
+		const char *q = strchr(path, '/');
+
+		if (!q)
+			q = end;
+
+		p = fdt_get_alias_namelen(fdt, p, q - p);
+		if (!p)
+			return -FDT_ERR_BADPATH;
+		offset = fdt_path_offset(fdt, p);
+
+		p = q;
+	}
+
+	while (*p) {
+		const char *q;
+
+		while (*p == '/')
+			p++;
+		if (! *p)
+			return offset;
+		q = strchr(p, '/');
+		if (! q)
+			q = end;
+
+		offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
+		if (offset < 0)
+			return offset;
+
+		p = q;
+	}
+
+	return offset;
+}
+
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+	const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
+	int err;
+
+	if (((err = fdt_check_header(fdt)) != 0)
+	    || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+			goto fail;
+
+	if (len)
+		*len = strlen(nh->name);
+
+	return nh->name;
+
+ fail:
+	if (len)
+		*len = err;
+	return NULL;
+}
+
+int fdt_first_property_offset(const void *fdt, int nodeoffset)
+{
+	int offset;
+
+	if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+int fdt_next_property_offset(const void *fdt, int offset)
+{
+	if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp)
+{
+	int err;
+	const struct fdt_property *prop;
+
+	if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
+		if (lenp)
+			*lenp = err;
+		return NULL;
+	}
+
+	prop = _fdt_offset_ptr(fdt, offset);
+
+	if (lenp)
+		*lenp = fdt32_to_cpu(prop->len);
+
+	return prop;
+}
+
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int offset,
+						    const char *name,
+						    int namelen, int *lenp)
+{
+	for (offset = fdt_first_property_offset(fdt, offset);
+	     (offset >= 0);
+	     (offset = fdt_next_property_offset(fdt, offset))) {
+		const struct fdt_property *prop;
+
+		if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
+			offset = -FDT_ERR_INTERNAL;
+			break;
+		}
+		if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
+				   name, namelen))
+			return prop;
+	}
+
+	if (lenp)
+		*lenp = offset;
+	return NULL;
+}
+
+const struct fdt_property *fdt_get_property(const void *fdt,
+					    int nodeoffset,
+					    const char *name, int *lenp)
+{
+	return fdt_get_property_namelen(fdt, nodeoffset, name,
+					strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
+	if (! prop)
+		return NULL;
+
+	return prop->data;
+}
+
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_by_offset(fdt, offset, lenp);
+	if (!prop)
+		return NULL;
+	if (namep)
+		*namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+	return prop->data;
+}
+
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp)
+{
+	return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
+{
+	const uint32_t *php;
+	int len;
+
+	/* FIXME: This is a bit sub-optimal, since we potentially scan
+	 * over all the properties twice. */
+	php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
+	if (!php || (len != sizeof(*php))) {
+		php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
+		if (!php || (len != sizeof(*php)))
+			return 0;
+	}
+
+	return fdt32_to_cpu(*php);
+}
+
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen)
+{
+	int aliasoffset;
+
+	aliasoffset = fdt_path_offset(fdt, "/aliases");
+	if (aliasoffset < 0)
+		return NULL;
+
+	return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+	return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+	int pdepth = 0, p = 0;
+	int offset, depth, namelen;
+	const char *name;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (buflen < 2)
+		return -FDT_ERR_NOSPACE;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		while (pdepth > depth) {
+			do {
+				p--;
+			} while (buf[p-1] != '/');
+			pdepth--;
+		}
+
+		if (pdepth >= depth) {
+			name = fdt_get_name(fdt, offset, &namelen);
+			if (!name)
+				return namelen;
+			if ((p + namelen + 1) <= buflen) {
+				memcpy(buf + p, name, namelen);
+				p += namelen;
+				buf[p++] = '/';
+				pdepth++;
+			}
+		}
+
+		if (offset == nodeoffset) {
+			if (pdepth < (depth + 1))
+				return -FDT_ERR_NOSPACE;
+
+			if (p > 1) /* special case so that root path is "/", not "" */
+				p--;
+			buf[p] = '\0';
+			return 0;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth)
+{
+	int offset, depth;
+	int supernodeoffset = -FDT_ERR_INTERNAL;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (supernodedepth < 0)
+		return -FDT_ERR_NOTFOUND;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		if (depth == supernodedepth)
+			supernodeoffset = offset;
+
+		if (offset == nodeoffset) {
+			if (nodedepth)
+				*nodedepth = depth;
+
+			if (supernodedepth > depth)
+				return -FDT_ERR_NOTFOUND;
+			else
+				return supernodeoffset;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+	int nodedepth;
+	int err;
+
+	err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+	if (err)
+		return (err < 0) ? err : -FDT_ERR_INTERNAL;
+	return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+	int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+	if (nodedepth < 0)
+		return nodedepth;
+	return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+					    nodedepth - 1, NULL);
+}
+
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen)
+{
+	int offset;
+	const void *val;
+	int len;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_getprop(), then if that didn't
+	 * find what we want, we scan over them again making our way
+	 * to the next node.  Still it's the easiest to implement
+	 * approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		val = fdt_getprop(fdt, offset, propname, &len);
+		if (val && (len == proplen)
+		    && (memcmp(val, propval, len) == 0))
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
+{
+	int offset;
+
+	if ((phandle == 0) || (phandle == -1))
+		return -FDT_ERR_BADPHANDLE;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we
+	 * potentially scan each property of a node in
+	 * fdt_get_phandle(), then if that didn't find what
+	 * we want, we scan over them again making our way to the next
+	 * node.  Still it's the easiest to implement approach;
+	 * performance can come later. */
+	for (offset = fdt_next_node(fdt, -1, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		if (fdt_get_phandle(fdt, offset) == phandle)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+				    const char *str)
+{
+	int len = strlen(str);
+	const char *p;
+
+	while (listlen >= len) {
+		if (memcmp(str, strlist, len+1) == 0)
+			return 1;
+		p = memchr(strlist, '\0', listlen);
+		if (!p)
+			return 0; /* malformed strlist.. */
+		listlen -= (p-strlist) + 1;
+		strlist = p + 1;
+	}
+	return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible)
+{
+	const void *prop;
+	int len;
+
+	prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+	if (!prop)
+		return len;
+	if (_fdt_stringlist_contains(prop, len, compatible))
+		return 0;
+	else
+		return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible)
+{
+	int offset, err;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_node_check_compatible(), then if
+	 * that didn't find what we want, we scan over them again
+	 * making our way to the next node.  Still it's the easiest to
+	 * implement approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		err = fdt_node_check_compatible(fdt, offset, compatible);
+		if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
+			return err;
+		else if (err == 0)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
new file mode 100644
index 0000000..994037b
--- /dev/null
+++ b/xen/common/libfdt/fdt_rw.c
@@ -0,0 +1,465 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_blocks_misordered(const void *fdt,
+			      int mem_rsv_size, int struct_size)
+{
+	return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
+		|| (fdt_off_dt_struct(fdt) <
+		    (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
+		|| (fdt_off_dt_strings(fdt) <
+		    (fdt_off_dt_struct(fdt) + struct_size))
+		|| (fdt_totalsize(fdt) <
+		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
+}
+
+static int _fdt_rw_check_header(void *fdt)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_version(fdt) < 17)
+		return -FDT_ERR_BADVERSION;
+	if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
+				   fdt_size_dt_struct(fdt)))
+		return -FDT_ERR_BADLAYOUT;
+	if (fdt_version(fdt) > 17)
+		fdt_set_version(fdt, 17);
+
+	return 0;
+}
+
+#define FDT_RW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_rw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static inline int _fdt_data_size(void *fdt)
+{
+	return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+}
+
+static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
+{
+	char *p = splicepoint;
+	char *end = (char *)fdt + _fdt_data_size(fdt);
+
+	if (((p + oldlen) < p) || ((p + oldlen) > end))
+		return -FDT_ERR_BADOFFSET;
+	if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
+		return -FDT_ERR_NOSPACE;
+	memmove(p + newlen, p + oldlen, end - p - oldlen);
+	return 0;
+}
+
+static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
+			       int oldn, int newn)
+{
+	int delta = (newn - oldn) * sizeof(*p);
+	int err;
+	err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
+	if (err)
+		return err;
+	fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_struct(void *fdt, void *p,
+			      int oldlen, int newlen)
+{
+	int delta = newlen - oldlen;
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
+		return err;
+
+	fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_string(void *fdt, int newlen)
+{
+	void *p = (char *)fdt
+		+ fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, 0, newlen)))
+		return err;
+
+	fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
+	const char *p;
+	char *new;
+	int len = strlen(s) + 1;
+	int err;
+
+	p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
+	if (p)
+		/* found it */
+		return (p - strtab);
+
+	new = strtab + fdt_size_dt_strings(fdt);
+	err = _fdt_splice_string(fdt, len);
+	if (err)
+		return err;
+
+	memcpy(new, s, len);
+	return (new - strtab);
+}
+
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
+	err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
+	if (err)
+		return err;
+
+	re->address = cpu_to_fdt64(address);
+	re->size = cpu_to_fdt64(size);
+	return 0;
+}
+
+int fdt_del_mem_rsv(void *fdt, int n)
+{
+	struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	if (n >= fdt_num_mem_rsv(fdt))
+		return -FDT_ERR_NOTFOUND;
+
+	err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
+	if (err)
+		return err;
+	return 0;
+}
+
+static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
+				int len, struct fdt_property **prop)
+{
+	int oldlen;
+	int err;
+
+	*prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
+	if (! (*prop))
+		return oldlen;
+
+	if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
+				      FDT_TAGALIGN(len))))
+		return err;
+
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
+			     int len, struct fdt_property **prop)
+{
+	int proplen;
+	int nextoffset;
+	int namestroff;
+	int err;
+
+	if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return nextoffset;
+
+	namestroff = _fdt_find_add_string(fdt, name);
+	if (namestroff < 0)
+		return namestroff;
+
+	*prop = _fdt_offset_ptr_w(fdt, nextoffset);
+	proplen = sizeof(**prop) + FDT_TAGALIGN(len);
+
+	err = _fdt_splice_struct(fdt, *prop, 0, proplen);
+	if (err)
+		return err;
+
+	(*prop)->tag = cpu_to_fdt32(FDT_PROP);
+	(*prop)->nameoff = cpu_to_fdt32(namestroff);
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+	char *namep;
+	int oldlen, newlen;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
+	if (!namep)
+		return oldlen;
+
+	newlen = strlen(name);
+
+	err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
+				 FDT_TAGALIGN(newlen+1));
+	if (err)
+		return err;
+
+	memcpy(namep, name, newlen+1);
+	return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len)
+{
+	struct fdt_property *prop;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
+	if (err == -FDT_ERR_NOTFOUND)
+		err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
+	if (err)
+		return err;
+
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_delprop(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len, proplen;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	proplen = sizeof(*prop) + FDT_TAGALIGN(len);
+	return _fdt_splice_struct(fdt, prop, proplen, 0);
+}
+
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen)
+{
+	struct fdt_node_header *nh;
+	int offset, nextoffset;
+	int nodelen;
+	int err;
+	uint32_t tag;
+	uint32_t *endtag;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
+	if (offset >= 0)
+		return -FDT_ERR_EXISTS;
+	else if (offset != -FDT_ERR_NOTFOUND)
+		return offset;
+
+	/* Try to place the new node after the parent's properties */
+	fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+	} while ((tag == FDT_PROP) || (tag == FDT_NOP));
+
+	nh = _fdt_offset_ptr_w(fdt, offset);
+	nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
+
+	err = _fdt_splice_struct(fdt, nh, 0, nodelen);
+	if (err)
+		return err;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
+	memcpy(nh->name, name, namelen);
+	endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
+	*endtag = cpu_to_fdt32(FDT_END_NODE);
+
+	return offset;
+}
+
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
+{
+	return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_del_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
+				  endoffset - nodeoffset, 0);
+}
+
+static void _fdt_packblocks(const char *old, char *new,
+			    int mem_rsv_size, int struct_size)
+{
+	int mem_rsv_off, struct_off, strings_off;
+
+	mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
+	struct_off = mem_rsv_off + mem_rsv_size;
+	strings_off = struct_off + struct_size;
+
+	memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
+	fdt_set_off_mem_rsvmap(new, mem_rsv_off);
+
+	memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
+	fdt_set_off_dt_struct(new, struct_off);
+	fdt_set_size_dt_struct(new, struct_size);
+
+	memmove(new + strings_off, old + fdt_off_dt_strings(old),
+		fdt_size_dt_strings(old));
+	fdt_set_off_dt_strings(new, strings_off);
+	fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
+}
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize)
+{
+	int err;
+	int mem_rsv_size, struct_size;
+	int newsize;
+	const char *fdtstart = fdt;
+	const char *fdtend = fdtstart + fdt_totalsize(fdt);
+	char *tmp;
+
+	FDT_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+
+	if (fdt_version(fdt) >= 17) {
+		struct_size = fdt_size_dt_struct(fdt);
+	} else {
+		struct_size = 0;
+		while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
+			;
+		if (struct_size < 0)
+			return struct_size;
+	}
+
+	if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
+		/* no further work necessary */
+		err = fdt_move(fdt, buf, bufsize);
+		if (err)
+			return err;
+		fdt_set_version(buf, 17);
+		fdt_set_size_dt_struct(buf, struct_size);
+		fdt_set_totalsize(buf, bufsize);
+		return 0;
+	}
+
+	/* Need to reorder */
+	newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
+		+ struct_size + fdt_size_dt_strings(fdt);
+
+	if (bufsize < newsize)
+		return -FDT_ERR_NOSPACE;
+
+	/* First attempt to build converted tree at beginning of buffer */
+	tmp = buf;
+	/* But if that overlaps with the old tree... */
+	if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
+		/* Try right after the old tree instead */
+		tmp = (char *)(uintptr_t)fdtend;
+		if ((tmp + newsize) > ((char *)buf + bufsize))
+			return -FDT_ERR_NOSPACE;
+	}
+
+	_fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
+	memmove(buf, tmp, newsize);
+
+	fdt_set_magic(buf, FDT_MAGIC);
+	fdt_set_totalsize(buf, bufsize);
+	fdt_set_version(buf, 17);
+	fdt_set_last_comp_version(buf, 16);
+	fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
+
+	return 0;
+}
+
+int fdt_pack(void *fdt)
+{
+	int mem_rsv_size;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+	_fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
+	fdt_set_totalsize(fdt, _fdt_data_size(fdt));
+
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
new file mode 100644
index 0000000..e6c3cee
--- /dev/null
+++ b/xen/common/libfdt/fdt_strerror.c
@@ -0,0 +1,96 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+struct fdt_errtabent {
+	const char *str;
+};
+
+#define FDT_ERRTABENT(val) \
+	[(val)] = { .str = #val, }
+
+static struct fdt_errtabent fdt_errtable[] = {
+	FDT_ERRTABENT(FDT_ERR_NOTFOUND),
+	FDT_ERRTABENT(FDT_ERR_EXISTS),
+	FDT_ERRTABENT(FDT_ERR_NOSPACE),
+
+	FDT_ERRTABENT(FDT_ERR_BADOFFSET),
+	FDT_ERRTABENT(FDT_ERR_BADPATH),
+	FDT_ERRTABENT(FDT_ERR_BADSTATE),
+
+	FDT_ERRTABENT(FDT_ERR_TRUNCATED),
+	FDT_ERRTABENT(FDT_ERR_BADMAGIC),
+	FDT_ERRTABENT(FDT_ERR_BADVERSION),
+	FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
+	FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+};
+#define FDT_ERRTABSIZE	(sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
+
+const char *fdt_strerror(int errval)
+{
+	if (errval > 0)
+		return "<valid offset/length>";
+	else if (errval == 0)
+		return "<no error>";
+	else if (errval > -FDT_ERRTABSIZE) {
+		const char *s = fdt_errtable[-errval].str;
+
+		if (s)
+			return s;
+	}
+
+	return "<unknown error>";
+}
diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
new file mode 100644
index 0000000..55ebebf
--- /dev/null
+++ b/xen/common/libfdt/fdt_sw.c
@@ -0,0 +1,256 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_sw_check_header(void *fdt)
+{
+	if (fdt_magic(fdt) != FDT_SW_MAGIC)
+		return -FDT_ERR_BADMAGIC;
+	/* FIXME: should check more details about the header state */
+	return 0;
+}
+
+#define FDT_SW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_sw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static void *_fdt_grab_space(void *fdt, size_t len)
+{
+	int offset = fdt_size_dt_struct(fdt);
+	int spaceleft;
+
+	spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
+		- fdt_size_dt_strings(fdt);
+
+	if ((offset + len < offset) || (offset + len > spaceleft))
+		return NULL;
+
+	fdt_set_size_dt_struct(fdt, offset + len);
+	return _fdt_offset_ptr_w(fdt, offset);
+}
+
+int fdt_create(void *buf, int bufsize)
+{
+	void *fdt = buf;
+
+	if (bufsize < sizeof(struct fdt_header))
+		return -FDT_ERR_NOSPACE;
+
+	memset(buf, 0, bufsize);
+
+	fdt_set_magic(fdt, FDT_SW_MAGIC);
+	fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+	fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+	fdt_set_totalsize(fdt,  bufsize);
+
+	fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
+					      sizeof(struct fdt_reserve_entry)));
+	fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
+	fdt_set_off_dt_strings(fdt, bufsize);
+
+	return 0;
+}
+
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int offset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	if (fdt_size_dt_struct(fdt))
+		return -FDT_ERR_BADSTATE;
+
+	offset = fdt_off_dt_struct(fdt);
+	if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
+		return -FDT_ERR_NOSPACE;
+
+	re = (struct fdt_reserve_entry *)((char *)fdt + offset);
+	re->address = cpu_to_fdt64(addr);
+	re->size = cpu_to_fdt64(size);
+
+	fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
+
+	return 0;
+}
+
+int fdt_finish_reservemap(void *fdt)
+{
+	return fdt_add_reservemap_entry(fdt, 0, 0);
+}
+
+int fdt_begin_node(void *fdt, const char *name)
+{
+	struct fdt_node_header *nh;
+	int namelen = strlen(name) + 1;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
+	if (! nh)
+		return -FDT_ERR_NOSPACE;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memcpy(nh->name, name, namelen);
+	return 0;
+}
+
+int fdt_end_node(void *fdt)
+{
+	uint32_t *en;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	en = _fdt_grab_space(fdt, FDT_TAGSIZE);
+	if (! en)
+		return -FDT_ERR_NOSPACE;
+
+	*en = cpu_to_fdt32(FDT_END_NODE);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_totalsize(fdt);
+	const char *p;
+	int strtabsize = fdt_size_dt_strings(fdt);
+	int len = strlen(s) + 1;
+	int struct_top, offset;
+
+	p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
+	if (p)
+		return p - strtab;
+
+	/* Add it */
+	offset = -strtabsize - len;
+	struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	if (fdt_totalsize(fdt) + offset < struct_top)
+		return 0; /* no more room :( */
+
+	memcpy(strtab + offset, s, len);
+	fdt_set_size_dt_strings(fdt, strtabsize + len);
+	return offset;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+	struct fdt_property *prop;
+	int nameoff;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nameoff = _fdt_find_add_string(fdt, name);
+	if (nameoff == 0)
+		return -FDT_ERR_NOSPACE;
+
+	prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
+	if (! prop)
+		return -FDT_ERR_NOSPACE;
+
+	prop->tag = cpu_to_fdt32(FDT_PROP);
+	prop->nameoff = cpu_to_fdt32(nameoff);
+	prop->len = cpu_to_fdt32(len);
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_finish(void *fdt)
+{
+	char *p = (char *)fdt;
+	uint32_t *end;
+	int oldstroffset, newstroffset;
+	uint32_t tag;
+	int offset, nextoffset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	/* Add terminator */
+	end = _fdt_grab_space(fdt, sizeof(*end));
+	if (! end)
+		return -FDT_ERR_NOSPACE;
+	*end = cpu_to_fdt32(FDT_END);
+
+	/* Relocate the string table */
+	oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
+	newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
+	fdt_set_off_dt_strings(fdt, newstroffset);
+
+	/* Walk the structure, correcting string offsets */
+	offset = 0;
+	while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
+		if (tag == FDT_PROP) {
+			struct fdt_property *prop =
+				_fdt_offset_ptr_w(fdt, offset);
+			int nameoff;
+
+			nameoff = fdt32_to_cpu(prop->nameoff);
+			nameoff += fdt_size_dt_strings(fdt);
+			prop->nameoff = cpu_to_fdt32(nameoff);
+		}
+		offset = nextoffset;
+	}
+	if (nextoffset < 0)
+		return nextoffset;
+
+	/* Finally, adjust the header */
+	fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
+	fdt_set_magic(fdt, FDT_MAGIC);
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
new file mode 100644
index 0000000..6025fa1
--- /dev/null
+++ b/xen/common/libfdt/fdt_wip.c
@@ -0,0 +1,118 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len)
+{
+	void *propval;
+	int proplen;
+
+	propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
+	if (! propval)
+		return proplen;
+
+	if (proplen != len)
+		return -FDT_ERR_NOSPACE;
+
+	memcpy(propval, val, len);
+	return 0;
+}
+
+static void _fdt_nop_region(void *start, int len)
+{
+	uint32_t *p;
+
+	for (p = start; (char *)p < ((char *)start + len); p++)
+		*p = cpu_to_fdt32(FDT_NOP);
+}
+
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len;
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	_fdt_nop_region(prop, len + sizeof(*prop));
+
+	return 0;
+}
+
+int _fdt_node_end_offset(void *fdt, int offset)
+{
+	int depth = 0;
+
+	while ((offset >= 0) && (depth >= 0))
+		offset = fdt_next_node(fdt, offset, &depth);
+
+	return offset;
+}
+
+int fdt_nop_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	_fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
+			endoffset - nodeoffset);
+	return 0;
+}
diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
new file mode 100644
index 0000000..55f3eb3
--- /dev/null
+++ b/xen/common/libfdt/libfdt.h
@@ -0,0 +1,1235 @@
+#ifndef _LIBFDT_H
+#define _LIBFDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <libfdt_env.h>
+#include <fdt.h>
+
+#define FDT_FIRST_SUPPORTED_VERSION	0x10
+#define FDT_LAST_SUPPORTED_VERSION	0x11
+
+/* Error codes: informative error codes */
+#define FDT_ERR_NOTFOUND	1
+	/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
+#define FDT_ERR_EXISTS		2
+	/* FDT_ERR_EXISTS: Attemped to create a node or property which
+	 * already exists */
+#define FDT_ERR_NOSPACE		3
+	/* FDT_ERR_NOSPACE: Operation needed to expand the device
+	 * tree, but its buffer did not have sufficient space to
+	 * contain the expanded tree. Use fdt_open_into() to move the
+	 * device tree to a buffer with more space. */
+
+/* Error codes: codes for bad parameters */
+#define FDT_ERR_BADOFFSET	4
+	/* FDT_ERR_BADOFFSET: Function was passed a structure block
+	 * offset which is out-of-bounds, or which points to an
+	 * unsuitable part of the structure for the operation. */
+#define FDT_ERR_BADPATH		5
+	/* FDT_ERR_BADPATH: Function was passed a badly formatted path
+	 * (e.g. missing a leading / for a function which requires an
+	 * absolute path) */
+#define FDT_ERR_BADPHANDLE	6
+	/* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
+	 * value.  phandle values of 0 and -1 are not permitted. */
+#define FDT_ERR_BADSTATE	7
+	/* FDT_ERR_BADSTATE: Function was passed an incomplete device
+	 * tree created by the sequential-write functions, which is
+	 * not sufficiently complete for the requested operation. */
+
+/* Error codes: codes for bad device tree blobs */
+#define FDT_ERR_TRUNCATED	8
+	/* FDT_ERR_TRUNCATED: Structure block of the given device tree
+	 * ends without an FDT_END tag. */
+#define FDT_ERR_BADMAGIC	9
+	/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+	 * device tree at all - it is missing the flattened device
+	 * tree magic number. */
+#define FDT_ERR_BADVERSION	10
+	/* FDT_ERR_BADVERSION: Given device tree has a version which
+	 * can't be handled by the requested operation.  For
+	 * read-write functions, this may mean that fdt_open_into() is
+	 * required to convert the tree to the expected version. */
+#define FDT_ERR_BADSTRUCTURE	11
+	/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+	 * structure block or other serious error (e.g. misnested
+	 * nodes, or subnodes preceding properties). */
+#define FDT_ERR_BADLAYOUT	12
+	/* FDT_ERR_BADLAYOUT: For read-write functions, the given
+	 * device tree has it's sub-blocks in an order that the
+	 * function can't handle (memory reserve map, then structure,
+	 * then strings).  Use fdt_open_into() to reorganize the tree
+	 * into a form suitable for the read-write operations. */
+
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL	13
+	/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+	 * Should never be returned, if it is, it indicates a bug in
+	 * libfdt itself. */
+
+#define FDT_ERR_MAX		13
+
+/**********************************************************************/
+/* Low-level functions (you probably don't need these)                */
+/**********************************************************************/
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
+{
+	return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
+}
+
+uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+
+/**********************************************************************/
+/* Traversal functions                                                */
+/**********************************************************************/
+
+int fdt_next_node(const void *fdt, int offset, int *depth);
+
+/**********************************************************************/
+/* General functions                                                  */
+/**********************************************************************/
+
+#define fdt_get_header(fdt, field) \
+	(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
+#define fdt_magic(fdt) 			(fdt_get_header(fdt, magic))
+#define fdt_totalsize(fdt)		(fdt_get_header(fdt, totalsize))
+#define fdt_off_dt_struct(fdt)		(fdt_get_header(fdt, off_dt_struct))
+#define fdt_off_dt_strings(fdt)		(fdt_get_header(fdt, off_dt_strings))
+#define fdt_off_mem_rsvmap(fdt)		(fdt_get_header(fdt, off_mem_rsvmap))
+#define fdt_version(fdt)		(fdt_get_header(fdt, version))
+#define fdt_last_comp_version(fdt) 	(fdt_get_header(fdt, last_comp_version))
+#define fdt_boot_cpuid_phys(fdt) 	(fdt_get_header(fdt, boot_cpuid_phys))
+#define fdt_size_dt_strings(fdt) 	(fdt_get_header(fdt, size_dt_strings))
+#define fdt_size_dt_struct(fdt)		(fdt_get_header(fdt, size_dt_struct))
+
+#define __fdt_set_hdr(name) \
+	static inline void fdt_set_##name(void *fdt, uint32_t val) \
+	{ \
+		struct fdt_header *fdth = (struct fdt_header*)fdt; \
+		fdth->name = cpu_to_fdt32(val); \
+	}
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
+
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ *     0, if the buffer appears to contain a valid device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings, as above
+ */
+int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize.  The buffer may overlap
+ * with the existing device tree blob at fdt.  Therefore,
+ *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_move(const void *fdt, void *buf, int bufsize);
+
+/**********************************************************************/
+/* Read-only functions                                                */
+/**********************************************************************/
+
+/**
+ * fdt_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ *     a pointer to the string, on success
+ *     NULL, if stroffset is out of bounds
+ */
+const char *fdt_string(const void *fdt, int stroffset);
+
+/**
+ * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map.  This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ *     the number of entries
+ */
+int fdt_num_mem_rsv(const void *fdt);
+
+/**
+ * fdt_get_mem_rsv - retrieve one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
+/**
+ * fdt_subnode_offset_namelen - find a subnode based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_subnode_offset(), but only examine the first
+ * namelen characters of name for matching the subnode name.  This is
+ * useful for finding subnodes based on a portion of a larger string,
+ * such as a full path.
+ */
+int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+			       const char *name, int namelen);
+/**
+ * fdt_subnode_offset - find a subnode of a given node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_subnode_offset() finds a subnode of the node at structure block
+ * offset parentoffset with the given name.  name may include a unit
+ * address, in which case fdt_subnode_offset() will find the subnode
+ * with that unit address, or the unit address may be omitted, in
+ * which case fdt_subnode_offset() will find an arbitrary subnode
+ * whose name excluding unit address matches the given name.
+ *
+ * returns:
+ *	structure block offset of the requested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_path_offset - find a tree node by its full path
+ * @fdt: pointer to the device tree blob
+ * @path: full path of the node to locate
+ *
+ * fdt_path_offset() finds a node of a given path in the device tree.
+ * Each path component may omit the unit address portion, but the
+ * results of this are undefined if any such path component is
+ * ambiguous (that is if there are multiple nodes at the relevant
+ * level matching the given component, differentiated only by unit
+ * address).
+ *
+ * returns:
+ *	structure block offset of the node with the requested path (>=0), on success
+ *	-FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
+ *	-FDT_ERR_NOTFOUND, if the requested node does not exist
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_path_offset(const void *fdt, const char *path);
+
+/**
+ * fdt_get_name - retrieve the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the starting node
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_name() retrieves the name (including unit address) of the
+ * device tree node at structure block offset nodeoffset.  If lenp is
+ * non-NULL, the length of this name is also returned, in the integer
+ * pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the node's name, on success
+ *		If lenp is non-NULL, *lenp contains the length of that name (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE, standard meanings
+ */
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+
+/**
+ * fdt_first_property_offset - find the offset of a node's first property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ *
+ * fdt_first_property_offset() finds the first property of the node at
+ * the given structure block offset.
+ *
+ * returns:
+ *	structure block offset of the property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested node has no properties
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_first_property_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_next_property_offset - step through a node's properties
+ * @fdt: pointer to the device tree blob
+ * @offset: structure block offset of a property
+ *
+ * fdt_next_property_offset() finds the property immediately after the
+ * one at the given structure block offset.  This will be a property
+ * of the same node as the given property.
+ *
+ * returns:
+ *	structure block offset of the next property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the given property is the last in its node
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_next_property_offset(const void *fdt, int offset);
+
+/**
+ * fdt_get_property_by_offset - retrieve the property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @offset: offset of the property to retrieve
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property_by_offset() retrieves a pointer to the
+ * fdt_property structure within the device tree blob at the given
+ * offset.  If lenp is non-NULL, the length of the property value is
+ * also returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp);
+
+/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int nodeoffset,
+						    const char *name,
+						    int namelen, int *lenp);
+
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset.  If lenp is
+ * non-NULL, the length of the property value is also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
+					    const char *name, int *lenp);
+static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
+						      const char *name,
+						      int *lenp)
+{
+	return (struct fdt_property *)(uintptr_t)
+		fdt_get_property(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_getprop_by_offset - retrieve the value of a property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @ffset: offset of the property to read
+ * @namep: pointer to a string variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop_by_offset() retrieves a pointer to the value of the
+ * property at structure block offset 'offset' (this will be a pointer
+ * to within the device blob itself, not a copy of the value).  If
+ * lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.  If namep is non-NULL,
+ * the property's namne will also be returned in the char * pointed to
+ * by namep (this will be a pointer to within the device tree's string
+ * block, not a new copy of the name).
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *		if namep is non-NULL *namep contiains a pointer to the property
+ *		name.
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp);
+
+/**
+ * fdt_getprop_namelen - get property value based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_getprop(), but only examine the first namelen
+ * characters of name for matching the property name.
+ */
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp);
+
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp);
+static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
+				  const char *name, int *lenp)
+{
+	return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_get_phandle - retrieve the phandle of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the node
+ *
+ * fdt_get_phandle() retrieves the phandle of the device tree node at
+ * structure block offset nodeoffset.
+ *
+ * returns:
+ *	the phandle of the node at nodeoffset, on success (!= 0, != -1)
+ *	0, if the node has no phandle, or another error occurs
+ */
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_get_alias_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias.  That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ *	a pointer to the expansion of the alias named 'name', of it exists
+ *	NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	0, on success
+ *		buf contains the absolute path of the node at
+ *		nodeoffset, as a NUL-terminated string.
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ *		characters and will not fit in the given buffer.
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth).  So
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node.  If the node at
+ * nodeoffset has depth D, then:
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ *	structure block offset of the node at node offset's ancestor
+ *		of depth supernodedepth (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+*	-FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node.  The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	depth of the node at nodeoffset (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ *	structure block offset of the parent of the node at nodeoffset
+ *		(>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_node_offset_by_prop_value - find nodes with a given property value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @propname: property name to check
+ * @propval: property value to search for
+ * @proplen: length of the value in propval
+ *
+ * fdt_node_offset_by_prop_value() returns the offset of the first
+ * node after startoffset, which has a property named propname whose
+ * value is of length proplen and has value equal to propval; or if
+ * startoffset is -1, the very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
+ *					       propval, proplen);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
+ *						       propval, proplen);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen);
+
+/**
+ * fdt_node_offset_by_phandle - find the node with a given phandle
+ * @fdt: pointer to the device tree blob
+ * @phandle: phandle value
+ *
+ * fdt_node_offset_by_phandle() returns the offset of the node
+ * which has the given phandle value.  If there is more than one node
+ * in the tree with the given phandle (an invalid tree), results are
+ * undefined.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0), on success
+ *	-FDT_ERR_NOTFOUND, no node with that phandle exists
+ *	-FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
+
+/**
+ * fdt_node_check_compatible: check a node's compatible property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ *	0, if the node has a 'compatible' property listing the given string
+ *	1, if the node has a 'compatible' property, but it does not list
+ *		the given string
+ *	-FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * 	-FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible);
+
+/**
+ * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @compatible: 'compatible' string to match against
+ *
+ * fdt_node_offset_by_compatible() returns the offset of the first
+ * node after startoffset, which has a 'compatible' property which
+ * lists the given compatible string; or if startoffset is -1, the
+ * very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible);
+
+/**********************************************************************/
+/* Write-in-place functions                                           */
+/**********************************************************************/
+
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+					   const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Sequential write functions                                         */
+/**********************************************************************/
+
+int fdt_create(void *buf, int bufsize);
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
+int fdt_finish_reservemap(void *fdt);
+int fdt_begin_node(void *fdt, const char *name);
+int fdt_property(void *fdt, const char *name, const void *val, int len);
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_property(fdt, name, &val, sizeof(val));
+}
+#define fdt_property_string(fdt, name, str) \
+	fdt_property(fdt, name, str, strlen(str)+1)
+int fdt_end_node(void *fdt);
+int fdt_finish(void *fdt);
+
+/**********************************************************************/
+/* Read-write functions                                               */
+/**********************************************************************/
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize);
+int fdt_pack(void *fdt);
+
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_mem_rsv(void *fdt, int n);
+
+/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string.  NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ *		to contain the new name
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+				   uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_string(fdt, nodeoffset, name, str) \
+	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Debugging / informational functions                                */
+/**********************************************************************/
+
+const char *fdt_strerror(int errval);
+
+#endif /* _LIBFDT_H */
diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
new file mode 100644
index 0000000..449bf60
--- /dev/null
+++ b/xen/common/libfdt/libfdt_env.h
@@ -0,0 +1,23 @@
+#ifndef _LIBFDT_ENV_H
+#define _LIBFDT_ENV_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <string.h>
+
+#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
+static inline uint32_t fdt32_to_cpu(uint32_t x)
+{
+	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
+}
+#define cpu_to_fdt32(x) fdt32_to_cpu(x)
+
+static inline uint64_t fdt64_to_cpu(uint64_t x)
+{
+	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
+		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
+}
+#define cpu_to_fdt64(x) fdt64_to_cpu(x)
+#undef _B
+
+#endif /* _LIBFDT_ENV_H */
diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
new file mode 100644
index 0000000..381133b
--- /dev/null
+++ b/xen/common/libfdt/libfdt_internal.h
@@ -0,0 +1,95 @@
+#ifndef _LIBFDT_INTERNAL_H
+#define _LIBFDT_INTERNAL_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include <fdt.h>
+
+#define FDT_ALIGN(x, a)		(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)		(FDT_ALIGN((x), FDT_TAGSIZE))
+
+#define FDT_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = fdt_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+int _fdt_check_node_offset(const void *fdt, int offset);
+int _fdt_check_prop_offset(const void *fdt, int offset);
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
+int _fdt_node_end_offset(void *fdt, int nodeoffset);
+
+static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
+{
+	return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
+}
+
+static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
+{
+	return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
+}
+
+static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
+{
+	const struct fdt_reserve_entry *rsv_table =
+		(const struct fdt_reserve_entry *)
+		((const char *)fdt + fdt_off_mem_rsvmap(fdt));
+
+	return rsv_table + n;
+}
+static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
+{
+	return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
+}
+
+#define FDT_SW_MAGIC		(~FDT_MAGIC)
+
+#endif /* _LIBFDT_INTERNAL_H */
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
new file mode 100644
index 0000000..3c3994e
--- /dev/null
+++ b/xen/common/libfdt/version.lds
@@ -0,0 +1,54 @@
+LIBFDT_1.2 {
+	global:
+		fdt_next_node;
+		fdt_check_header;
+		fdt_move;
+		fdt_string;
+		fdt_num_mem_rsv;
+		fdt_get_mem_rsv;
+		fdt_subnode_offset_namelen;
+		fdt_subnode_offset;
+		fdt_path_offset;
+		fdt_get_name;
+		fdt_get_property_namelen;
+		fdt_get_property;
+		fdt_getprop_namelen;
+		fdt_getprop;
+		fdt_get_phandle;
+		fdt_get_alias_namelen;
+		fdt_get_alias;
+		fdt_get_path;
+		fdt_supernode_atdepth_offset;
+		fdt_node_depth;
+		fdt_parent_offset;
+		fdt_node_offset_by_prop_value;
+		fdt_node_offset_by_phandle;
+		fdt_node_check_compatible;
+		fdt_node_offset_by_compatible;
+		fdt_setprop_inplace;
+		fdt_nop_property;
+		fdt_nop_node;
+		fdt_create;
+		fdt_add_reservemap_entry;
+		fdt_finish_reservemap;
+		fdt_begin_node;
+		fdt_property;
+		fdt_end_node;
+		fdt_finish;
+		fdt_open_into;
+		fdt_pack;
+		fdt_add_mem_rsv;
+		fdt_del_mem_rsv;
+		fdt_set_name;
+		fdt_setprop;
+		fdt_delprop;
+		fdt_add_subnode_namelen;
+		fdt_add_subnode;
+		fdt_del_node;
+		fdt_strerror;
+		fdt_offset_ptr;
+		fdt_next_tag;
+
+	local:
+		*;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoH-0006AN-AY; Mon, 13 Feb 2012 13:19:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RwvoE-00069Y-S5
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:11 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329139140!11154918!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28385 invoked from network); 13 Feb 2012 13:19:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:19:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488128"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:18:59 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIuj8024703;
	Mon, 13 Feb 2012 05:18:57 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 13:18:44 +0000
Message-ID: <1329139131-27554-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] libfdt: add version 1.3.0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git

This will be used by Xen to parse the DTBs provided by bootloaders on
ARM platforms.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/libfdt/Makefile.libfdt   |   10 +
 xen/common/libfdt/TODO              |    3 +
 xen/common/libfdt/fdt.c             |  222 +++++++
 xen/common/libfdt/fdt.h             |   60 ++
 xen/common/libfdt/fdt_ro.c          |  574 ++++++++++++++++
 xen/common/libfdt/fdt_rw.c          |  465 +++++++++++++
 xen/common/libfdt/fdt_strerror.c    |   96 +++
 xen/common/libfdt/fdt_sw.c          |  256 ++++++++
 xen/common/libfdt/fdt_wip.c         |  118 ++++
 xen/common/libfdt/libfdt.h          | 1235 +++++++++++++++++++++++++++++++++++
 xen/common/libfdt/libfdt_env.h      |   23 +
 xen/common/libfdt/libfdt_internal.h |   95 +++
 xen/common/libfdt/version.lds       |   54 ++
 13 files changed, 3211 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/libfdt/Makefile.libfdt
 create mode 100644 xen/common/libfdt/TODO
 create mode 100644 xen/common/libfdt/fdt.c
 create mode 100644 xen/common/libfdt/fdt.h
 create mode 100644 xen/common/libfdt/fdt_ro.c
 create mode 100644 xen/common/libfdt/fdt_rw.c
 create mode 100644 xen/common/libfdt/fdt_strerror.c
 create mode 100644 xen/common/libfdt/fdt_sw.c
 create mode 100644 xen/common/libfdt/fdt_wip.c
 create mode 100644 xen/common/libfdt/libfdt.h
 create mode 100644 xen/common/libfdt/libfdt_env.h
 create mode 100644 xen/common/libfdt/libfdt_internal.h
 create mode 100644 xen/common/libfdt/version.lds

diff --git a/xen/common/libfdt/Makefile.libfdt b/xen/common/libfdt/Makefile.libfdt
new file mode 100644
index 0000000..d55a6f8
--- /dev/null
+++ b/xen/common/libfdt/Makefile.libfdt
@@ -0,0 +1,10 @@
+# Makefile.libfdt
+#
+# This is not a complete Makefile of itself.  Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_VERSION = version.lds
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/xen/common/libfdt/TODO b/xen/common/libfdt/TODO
new file mode 100644
index 0000000..288437e
--- /dev/null
+++ b/xen/common/libfdt/TODO
@@ -0,0 +1,3 @@
+- Tree traversal functions
+- Graft function
+- Complete libfdt.h documenting comments
diff --git a/xen/common/libfdt/fdt.c b/xen/common/libfdt/fdt.c
new file mode 100644
index 0000000..e56833a
--- /dev/null
+++ b/xen/common/libfdt/fdt.c
@@ -0,0 +1,222 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_check_header(const void *fdt)
+{
+	if (fdt_magic(fdt) == FDT_MAGIC) {
+		/* Complete tree */
+		if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+		if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+			return -FDT_ERR_BADVERSION;
+	} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+		/* Unfinished sequential-write blob */
+		if (fdt_size_dt_struct(fdt) == 0)
+			return -FDT_ERR_BADSTATE;
+	} else {
+		return -FDT_ERR_BADMAGIC;
+	}
+
+	return 0;
+}
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
+{
+	const char *p;
+
+	if (fdt_version(fdt) >= 0x11)
+		if (((offset + len) < offset)
+		    || ((offset + len) > fdt_size_dt_struct(fdt)))
+			return NULL;
+
+	p = _fdt_offset_ptr(fdt, offset);
+
+	if (p + len < p)
+		return NULL;
+	return p;
+}
+
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+	const uint32_t *tagp, *lenp;
+	uint32_t tag;
+	int offset = startoffset;
+	const char *p;
+
+	*nextoffset = -FDT_ERR_TRUNCATED;
+	tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
+	if (!tagp)
+		return FDT_END; /* premature end */
+	tag = fdt32_to_cpu(*tagp);
+	offset += FDT_TAGSIZE;
+
+	*nextoffset = -FDT_ERR_BADSTRUCTURE;
+	switch (tag) {
+	case FDT_BEGIN_NODE:
+		/* skip name */
+		do {
+			p = fdt_offset_ptr(fdt, offset++, 1);
+		} while (p && (*p != '\0'));
+		if (!p)
+			return FDT_END; /* premature end */
+		break;
+
+	case FDT_PROP:
+		lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
+		if (!lenp)
+			return FDT_END; /* premature end */
+		/* skip-name offset, length and value */
+		offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+			+ fdt32_to_cpu(*lenp);
+		break;
+
+	case FDT_END:
+	case FDT_END_NODE:
+	case FDT_NOP:
+		break;
+
+	default:
+		return FDT_END;
+	}
+
+	if (!fdt_offset_ptr(fdt, startoffset, offset - startoffset))
+		return FDT_END; /* premature end */
+
+	*nextoffset = FDT_TAGALIGN(offset);
+	return tag;
+}
+
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int _fdt_check_prop_offset(const void *fdt, int offset)
+{
+	if ((offset < 0) || (offset % FDT_TAGSIZE)
+	    || (fdt_next_tag(fdt, offset, &offset) != FDT_PROP))
+		return -FDT_ERR_BADOFFSET;
+
+	return offset;
+}
+
+int fdt_next_node(const void *fdt, int offset, int *depth)
+{
+	int nextoffset = 0;
+	uint32_t tag;
+
+	if (offset >= 0)
+		if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+			return nextoffset;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_PROP:
+		case FDT_NOP:
+			break;
+
+		case FDT_BEGIN_NODE:
+			if (depth)
+				(*depth)++;
+			break;
+
+		case FDT_END_NODE:
+			if (depth && ((--(*depth)) < 0))
+				return nextoffset;
+			break;
+
+		case FDT_END:
+			if ((nextoffset >= 0)
+			    || ((nextoffset == -FDT_ERR_TRUNCATED) && !depth))
+				return -FDT_ERR_NOTFOUND;
+			else
+				return nextoffset;
+		}
+	} while (tag != FDT_BEGIN_NODE);
+
+	return offset;
+}
+
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+{
+	int len = strlen(s) + 1;
+	const char *last = strtab + tabsize - len;
+	const char *p;
+
+	for (p = strtab; p <= last; p++)
+		if (memcmp(p, s, len) == 0)
+			return p;
+	return NULL;
+}
+
+int fdt_move(const void *fdt, void *buf, int bufsize)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_totalsize(fdt) > bufsize)
+		return -FDT_ERR_NOSPACE;
+
+	memmove(buf, fdt, fdt_totalsize(fdt));
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt.h b/xen/common/libfdt/fdt.h
new file mode 100644
index 0000000..48ccfd9
--- /dev/null
+++ b/xen/common/libfdt/fdt.h
@@ -0,0 +1,60 @@
+#ifndef _FDT_H
+#define _FDT_H
+
+#ifndef __ASSEMBLY__
+
+struct fdt_header {
+	uint32_t magic;			 /* magic word FDT_MAGIC */
+	uint32_t totalsize;		 /* total size of DT block */
+	uint32_t off_dt_struct;		 /* offset to structure */
+	uint32_t off_dt_strings;	 /* offset to strings */
+	uint32_t off_mem_rsvmap;	 /* offset to memory reserve map */
+	uint32_t version;		 /* format version */
+	uint32_t last_comp_version;	 /* last compatible version */
+
+	/* version 2 fields below */
+	uint32_t boot_cpuid_phys;	 /* Which physical CPU id we're
+					    booting on */
+	/* version 3 fields below */
+	uint32_t size_dt_strings;	 /* size of the strings block */
+
+	/* version 17 fields below */
+	uint32_t size_dt_struct;	 /* size of the structure block */
+};
+
+struct fdt_reserve_entry {
+	uint64_t address;
+	uint64_t size;
+};
+
+struct fdt_node_header {
+	uint32_t tag;
+	char name[0];
+};
+
+struct fdt_property {
+	uint32_t tag;
+	uint32_t len;
+	uint32_t nameoff;
+	char data[0];
+};
+
+#endif /* !__ASSEMBLY */
+
+#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_TAGSIZE	sizeof(uint32_t)
+
+#define FDT_BEGIN_NODE	0x1		/* Start node: full name */
+#define FDT_END_NODE	0x2		/* End node */
+#define FDT_PROP	0x3		/* Property: name off,
+					   size, content */
+#define FDT_NOP		0x4		/* nop */
+#define FDT_END		0x9
+
+#define FDT_V1_SIZE	(7*sizeof(uint32_t))
+#define FDT_V2_SIZE	(FDT_V1_SIZE + sizeof(uint32_t))
+#define FDT_V3_SIZE	(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V16_SIZE	FDT_V3_SIZE
+#define FDT_V17_SIZE	(FDT_V16_SIZE + sizeof(uint32_t))
+
+#endif /* _FDT_H */
diff --git a/xen/common/libfdt/fdt_ro.c b/xen/common/libfdt/fdt_ro.c
new file mode 100644
index 0000000..02b6d68
--- /dev/null
+++ b/xen/common/libfdt/fdt_ro.c
@@ -0,0 +1,574 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_nodename_eq(const void *fdt, int offset,
+			    const char *s, int len)
+{
+	const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+
+	if (! p)
+		/* short match */
+		return 0;
+
+	if (memcmp(p, s, len) != 0)
+		return 0;
+
+	if (p[len] == '\0')
+		return 1;
+	else if (!memchr(s, '@', len) && (p[len] == '@'))
+		return 1;
+	else
+		return 0;
+}
+
+const char *fdt_string(const void *fdt, int stroffset)
+{
+	return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+}
+
+static int _fdt_string_eq(const void *fdt, int stroffset,
+			  const char *s, int len)
+{
+	const char *p = fdt_string(fdt, stroffset);
+
+	return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+}
+
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
+{
+	FDT_CHECK_HEADER(fdt);
+	*address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
+	*size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+	return 0;
+}
+
+int fdt_num_mem_rsv(const void *fdt)
+{
+	int i = 0;
+
+	while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+		i++;
+	return i;
+}
+
+static int _nextprop(const void *fdt, int offset)
+{
+	uint32_t tag;
+	int nextoffset;
+
+	do {
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+		switch (tag) {
+		case FDT_END:
+			if (nextoffset >= 0)
+				return -FDT_ERR_BADSTRUCTURE;
+			else
+				return nextoffset;
+
+		case FDT_PROP:
+			return offset;
+		}
+		offset = nextoffset;
+	} while (tag == FDT_NOP);
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
+			       const char *name, int namelen)
+{
+	int depth;
+
+	FDT_CHECK_HEADER(fdt);
+
+	for (depth = 0;
+	     (offset >= 0) && (depth >= 0);
+	     offset = fdt_next_node(fdt, offset, &depth))
+		if ((depth == 1)
+		    && _fdt_nodename_eq(fdt, offset, name, namelen))
+			return offset;
+
+	if (depth < 0)
+		return -FDT_ERR_NOTFOUND;
+	return offset; /* error */
+}
+
+int fdt_subnode_offset(const void *fdt, int parentoffset,
+		       const char *name)
+{
+	return fdt_subnode_offset_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_path_offset(const void *fdt, const char *path)
+{
+	const char *end = path + strlen(path);
+	const char *p = path;
+	int offset = 0;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* see if we have an alias */
+	if (*path != '/') {
+		const char *q = strchr(path, '/');
+
+		if (!q)
+			q = end;
+
+		p = fdt_get_alias_namelen(fdt, p, q - p);
+		if (!p)
+			return -FDT_ERR_BADPATH;
+		offset = fdt_path_offset(fdt, p);
+
+		p = q;
+	}
+
+	while (*p) {
+		const char *q;
+
+		while (*p == '/')
+			p++;
+		if (! *p)
+			return offset;
+		q = strchr(p, '/');
+		if (! q)
+			q = end;
+
+		offset = fdt_subnode_offset_namelen(fdt, offset, p, q-p);
+		if (offset < 0)
+			return offset;
+
+		p = q;
+	}
+
+	return offset;
+}
+
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
+{
+	const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
+	int err;
+
+	if (((err = fdt_check_header(fdt)) != 0)
+	    || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+			goto fail;
+
+	if (len)
+		*len = strlen(nh->name);
+
+	return nh->name;
+
+ fail:
+	if (len)
+		*len = err;
+	return NULL;
+}
+
+int fdt_first_property_offset(const void *fdt, int nodeoffset)
+{
+	int offset;
+
+	if ((offset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+int fdt_next_property_offset(const void *fdt, int offset)
+{
+	if ((offset = _fdt_check_prop_offset(fdt, offset)) < 0)
+		return offset;
+
+	return _nextprop(fdt, offset);
+}
+
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp)
+{
+	int err;
+	const struct fdt_property *prop;
+
+	if ((err = _fdt_check_prop_offset(fdt, offset)) < 0) {
+		if (lenp)
+			*lenp = err;
+		return NULL;
+	}
+
+	prop = _fdt_offset_ptr(fdt, offset);
+
+	if (lenp)
+		*lenp = fdt32_to_cpu(prop->len);
+
+	return prop;
+}
+
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int offset,
+						    const char *name,
+						    int namelen, int *lenp)
+{
+	for (offset = fdt_first_property_offset(fdt, offset);
+	     (offset >= 0);
+	     (offset = fdt_next_property_offset(fdt, offset))) {
+		const struct fdt_property *prop;
+
+		if (!(prop = fdt_get_property_by_offset(fdt, offset, lenp))) {
+			offset = -FDT_ERR_INTERNAL;
+			break;
+		}
+		if (_fdt_string_eq(fdt, fdt32_to_cpu(prop->nameoff),
+				   name, namelen))
+			return prop;
+	}
+
+	if (lenp)
+		*lenp = offset;
+	return NULL;
+}
+
+const struct fdt_property *fdt_get_property(const void *fdt,
+					    int nodeoffset,
+					    const char *name, int *lenp)
+{
+	return fdt_get_property_namelen(fdt, nodeoffset, name,
+					strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
+	if (! prop)
+		return NULL;
+
+	return prop->data;
+}
+
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp)
+{
+	const struct fdt_property *prop;
+
+	prop = fdt_get_property_by_offset(fdt, offset, lenp);
+	if (!prop)
+		return NULL;
+	if (namep)
+		*namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+	return prop->data;
+}
+
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp)
+{
+	return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
+{
+	const uint32_t *php;
+	int len;
+
+	/* FIXME: This is a bit sub-optimal, since we potentially scan
+	 * over all the properties twice. */
+	php = fdt_getprop(fdt, nodeoffset, "phandle", &len);
+	if (!php || (len != sizeof(*php))) {
+		php = fdt_getprop(fdt, nodeoffset, "linux,phandle", &len);
+		if (!php || (len != sizeof(*php)))
+			return 0;
+	}
+
+	return fdt32_to_cpu(*php);
+}
+
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen)
+{
+	int aliasoffset;
+
+	aliasoffset = fdt_path_offset(fdt, "/aliases");
+	if (aliasoffset < 0)
+		return NULL;
+
+	return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+	return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
+{
+	int pdepth = 0, p = 0;
+	int offset, depth, namelen;
+	const char *name;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (buflen < 2)
+		return -FDT_ERR_NOSPACE;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		while (pdepth > depth) {
+			do {
+				p--;
+			} while (buf[p-1] != '/');
+			pdepth--;
+		}
+
+		if (pdepth >= depth) {
+			name = fdt_get_name(fdt, offset, &namelen);
+			if (!name)
+				return namelen;
+			if ((p + namelen + 1) <= buflen) {
+				memcpy(buf + p, name, namelen);
+				p += namelen;
+				buf[p++] = '/';
+				pdepth++;
+			}
+		}
+
+		if (offset == nodeoffset) {
+			if (pdepth < (depth + 1))
+				return -FDT_ERR_NOSPACE;
+
+			if (p > 1) /* special case so that root path is "/", not "" */
+				p--;
+			buf[p] = '\0';
+			return 0;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth)
+{
+	int offset, depth;
+	int supernodeoffset = -FDT_ERR_INTERNAL;
+
+	FDT_CHECK_HEADER(fdt);
+
+	if (supernodedepth < 0)
+		return -FDT_ERR_NOTFOUND;
+
+	for (offset = 0, depth = 0;
+	     (offset >= 0) && (offset <= nodeoffset);
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		if (depth == supernodedepth)
+			supernodeoffset = offset;
+
+		if (offset == nodeoffset) {
+			if (nodedepth)
+				*nodedepth = depth;
+
+			if (supernodedepth > depth)
+				return -FDT_ERR_NOTFOUND;
+			else
+				return supernodeoffset;
+		}
+	}
+
+	if ((offset == -FDT_ERR_NOTFOUND) || (offset >= 0))
+		return -FDT_ERR_BADOFFSET;
+	else if (offset == -FDT_ERR_BADOFFSET)
+		return -FDT_ERR_BADSTRUCTURE;
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_depth(const void *fdt, int nodeoffset)
+{
+	int nodedepth;
+	int err;
+
+	err = fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, &nodedepth);
+	if (err)
+		return (err < 0) ? err : -FDT_ERR_INTERNAL;
+	return nodedepth;
+}
+
+int fdt_parent_offset(const void *fdt, int nodeoffset)
+{
+	int nodedepth = fdt_node_depth(fdt, nodeoffset);
+
+	if (nodedepth < 0)
+		return nodedepth;
+	return fdt_supernode_atdepth_offset(fdt, nodeoffset,
+					    nodedepth - 1, NULL);
+}
+
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen)
+{
+	int offset;
+	const void *val;
+	int len;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_getprop(), then if that didn't
+	 * find what we want, we scan over them again making our way
+	 * to the next node.  Still it's the easiest to implement
+	 * approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		val = fdt_getprop(fdt, offset, propname, &len);
+		if (val && (len == proplen)
+		    && (memcmp(val, propval, len) == 0))
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
+{
+	int offset;
+
+	if ((phandle == 0) || (phandle == -1))
+		return -FDT_ERR_BADPHANDLE;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we
+	 * potentially scan each property of a node in
+	 * fdt_get_phandle(), then if that didn't find what
+	 * we want, we scan over them again making our way to the next
+	 * node.  Still it's the easiest to implement approach;
+	 * performance can come later. */
+	for (offset = fdt_next_node(fdt, -1, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		if (fdt_get_phandle(fdt, offset) == phandle)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
+
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+				    const char *str)
+{
+	int len = strlen(str);
+	const char *p;
+
+	while (listlen >= len) {
+		if (memcmp(str, strlist, len+1) == 0)
+			return 1;
+		p = memchr(strlist, '\0', listlen);
+		if (!p)
+			return 0; /* malformed strlist.. */
+		listlen -= (p-strlist) + 1;
+		strlist = p + 1;
+	}
+	return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible)
+{
+	const void *prop;
+	int len;
+
+	prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+	if (!prop)
+		return len;
+	if (_fdt_stringlist_contains(prop, len, compatible))
+		return 0;
+	else
+		return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible)
+{
+	int offset, err;
+
+	FDT_CHECK_HEADER(fdt);
+
+	/* FIXME: The algorithm here is pretty horrible: we scan each
+	 * property of a node in fdt_node_check_compatible(), then if
+	 * that didn't find what we want, we scan over them again
+	 * making our way to the next node.  Still it's the easiest to
+	 * implement approach; performance can come later. */
+	for (offset = fdt_next_node(fdt, startoffset, NULL);
+	     offset >= 0;
+	     offset = fdt_next_node(fdt, offset, NULL)) {
+		err = fdt_node_check_compatible(fdt, offset, compatible);
+		if ((err < 0) && (err != -FDT_ERR_NOTFOUND))
+			return err;
+		else if (err == 0)
+			return offset;
+	}
+
+	return offset; /* error from fdt_next_node() */
+}
diff --git a/xen/common/libfdt/fdt_rw.c b/xen/common/libfdt/fdt_rw.c
new file mode 100644
index 0000000..994037b
--- /dev/null
+++ b/xen/common/libfdt/fdt_rw.c
@@ -0,0 +1,465 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_blocks_misordered(const void *fdt,
+			      int mem_rsv_size, int struct_size)
+{
+	return (fdt_off_mem_rsvmap(fdt) < FDT_ALIGN(sizeof(struct fdt_header), 8))
+		|| (fdt_off_dt_struct(fdt) <
+		    (fdt_off_mem_rsvmap(fdt) + mem_rsv_size))
+		|| (fdt_off_dt_strings(fdt) <
+		    (fdt_off_dt_struct(fdt) + struct_size))
+		|| (fdt_totalsize(fdt) <
+		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
+}
+
+static int _fdt_rw_check_header(void *fdt)
+{
+	FDT_CHECK_HEADER(fdt);
+
+	if (fdt_version(fdt) < 17)
+		return -FDT_ERR_BADVERSION;
+	if (_fdt_blocks_misordered(fdt, sizeof(struct fdt_reserve_entry),
+				   fdt_size_dt_struct(fdt)))
+		return -FDT_ERR_BADLAYOUT;
+	if (fdt_version(fdt) > 17)
+		fdt_set_version(fdt, 17);
+
+	return 0;
+}
+
+#define FDT_RW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_rw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static inline int _fdt_data_size(void *fdt)
+{
+	return fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+}
+
+static int _fdt_splice(void *fdt, void *splicepoint, int oldlen, int newlen)
+{
+	char *p = splicepoint;
+	char *end = (char *)fdt + _fdt_data_size(fdt);
+
+	if (((p + oldlen) < p) || ((p + oldlen) > end))
+		return -FDT_ERR_BADOFFSET;
+	if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
+		return -FDT_ERR_NOSPACE;
+	memmove(p + newlen, p + oldlen, end - p - oldlen);
+	return 0;
+}
+
+static int _fdt_splice_mem_rsv(void *fdt, struct fdt_reserve_entry *p,
+			       int oldn, int newn)
+{
+	int delta = (newn - oldn) * sizeof(*p);
+	int err;
+	err = _fdt_splice(fdt, p, oldn * sizeof(*p), newn * sizeof(*p));
+	if (err)
+		return err;
+	fdt_set_off_dt_struct(fdt, fdt_off_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_struct(void *fdt, void *p,
+			      int oldlen, int newlen)
+{
+	int delta = newlen - oldlen;
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, oldlen, newlen)))
+		return err;
+
+	fdt_set_size_dt_struct(fdt, fdt_size_dt_struct(fdt) + delta);
+	fdt_set_off_dt_strings(fdt, fdt_off_dt_strings(fdt) + delta);
+	return 0;
+}
+
+static int _fdt_splice_string(void *fdt, int newlen)
+{
+	void *p = (char *)fdt
+		+ fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt);
+	int err;
+
+	if ((err = _fdt_splice(fdt, p, 0, newlen)))
+		return err;
+
+	fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) + newlen);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
+	const char *p;
+	char *new;
+	int len = strlen(s) + 1;
+	int err;
+
+	p = _fdt_find_string(strtab, fdt_size_dt_strings(fdt), s);
+	if (p)
+		/* found it */
+		return (p - strtab);
+
+	new = strtab + fdt_size_dt_strings(fdt);
+	err = _fdt_splice_string(fdt, len);
+	if (err)
+		return err;
+
+	memcpy(new, s, len);
+	return (new - strtab);
+}
+
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
+	err = _fdt_splice_mem_rsv(fdt, re, 0, 1);
+	if (err)
+		return err;
+
+	re->address = cpu_to_fdt64(address);
+	re->size = cpu_to_fdt64(size);
+	return 0;
+}
+
+int fdt_del_mem_rsv(void *fdt, int n)
+{
+	struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	if (n >= fdt_num_mem_rsv(fdt))
+		return -FDT_ERR_NOTFOUND;
+
+	err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
+	if (err)
+		return err;
+	return 0;
+}
+
+static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
+				int len, struct fdt_property **prop)
+{
+	int oldlen;
+	int err;
+
+	*prop = fdt_get_property_w(fdt, nodeoffset, name, &oldlen);
+	if (! (*prop))
+		return oldlen;
+
+	if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
+				      FDT_TAGALIGN(len))))
+		return err;
+
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+static int _fdt_add_property(void *fdt, int nodeoffset, const char *name,
+			     int len, struct fdt_property **prop)
+{
+	int proplen;
+	int nextoffset;
+	int namestroff;
+	int err;
+
+	if ((nextoffset = _fdt_check_node_offset(fdt, nodeoffset)) < 0)
+		return nextoffset;
+
+	namestroff = _fdt_find_add_string(fdt, name);
+	if (namestroff < 0)
+		return namestroff;
+
+	*prop = _fdt_offset_ptr_w(fdt, nextoffset);
+	proplen = sizeof(**prop) + FDT_TAGALIGN(len);
+
+	err = _fdt_splice_struct(fdt, *prop, 0, proplen);
+	if (err)
+		return err;
+
+	(*prop)->tag = cpu_to_fdt32(FDT_PROP);
+	(*prop)->nameoff = cpu_to_fdt32(namestroff);
+	(*prop)->len = cpu_to_fdt32(len);
+	return 0;
+}
+
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+	char *namep;
+	int oldlen, newlen;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	namep = (char *)(uintptr_t)fdt_get_name(fdt, nodeoffset, &oldlen);
+	if (!namep)
+		return oldlen;
+
+	newlen = strlen(name);
+
+	err = _fdt_splice_struct(fdt, namep, FDT_TAGALIGN(oldlen+1),
+				 FDT_TAGALIGN(newlen+1));
+	if (err)
+		return err;
+
+	memcpy(namep, name, newlen+1);
+	return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len)
+{
+	struct fdt_property *prop;
+	int err;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	err = _fdt_resize_property(fdt, nodeoffset, name, len, &prop);
+	if (err == -FDT_ERR_NOTFOUND)
+		err = _fdt_add_property(fdt, nodeoffset, name, len, &prop);
+	if (err)
+		return err;
+
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_delprop(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len, proplen;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	proplen = sizeof(*prop) + FDT_TAGALIGN(len);
+	return _fdt_splice_struct(fdt, prop, proplen, 0);
+}
+
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen)
+{
+	struct fdt_node_header *nh;
+	int offset, nextoffset;
+	int nodelen;
+	int err;
+	uint32_t tag;
+	uint32_t *endtag;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	offset = fdt_subnode_offset_namelen(fdt, parentoffset, name, namelen);
+	if (offset >= 0)
+		return -FDT_ERR_EXISTS;
+	else if (offset != -FDT_ERR_NOTFOUND)
+		return offset;
+
+	/* Try to place the new node after the parent's properties */
+	fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+	} while ((tag == FDT_PROP) || (tag == FDT_NOP));
+
+	nh = _fdt_offset_ptr_w(fdt, offset);
+	nodelen = sizeof(*nh) + FDT_TAGALIGN(namelen+1) + FDT_TAGSIZE;
+
+	err = _fdt_splice_struct(fdt, nh, 0, nodelen);
+	if (err)
+		return err;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memset(nh->name, 0, FDT_TAGALIGN(namelen+1));
+	memcpy(nh->name, name, namelen);
+	endtag = (uint32_t *)((char *)nh + nodelen - FDT_TAGSIZE);
+	*endtag = cpu_to_fdt32(FDT_END_NODE);
+
+	return offset;
+}
+
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name)
+{
+	return fdt_add_subnode_namelen(fdt, parentoffset, name, strlen(name));
+}
+
+int fdt_del_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	return _fdt_splice_struct(fdt, _fdt_offset_ptr_w(fdt, nodeoffset),
+				  endoffset - nodeoffset, 0);
+}
+
+static void _fdt_packblocks(const char *old, char *new,
+			    int mem_rsv_size, int struct_size)
+{
+	int mem_rsv_off, struct_off, strings_off;
+
+	mem_rsv_off = FDT_ALIGN(sizeof(struct fdt_header), 8);
+	struct_off = mem_rsv_off + mem_rsv_size;
+	strings_off = struct_off + struct_size;
+
+	memmove(new + mem_rsv_off, old + fdt_off_mem_rsvmap(old), mem_rsv_size);
+	fdt_set_off_mem_rsvmap(new, mem_rsv_off);
+
+	memmove(new + struct_off, old + fdt_off_dt_struct(old), struct_size);
+	fdt_set_off_dt_struct(new, struct_off);
+	fdt_set_size_dt_struct(new, struct_size);
+
+	memmove(new + strings_off, old + fdt_off_dt_strings(old),
+		fdt_size_dt_strings(old));
+	fdt_set_off_dt_strings(new, strings_off);
+	fdt_set_size_dt_strings(new, fdt_size_dt_strings(old));
+}
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize)
+{
+	int err;
+	int mem_rsv_size, struct_size;
+	int newsize;
+	const char *fdtstart = fdt;
+	const char *fdtend = fdtstart + fdt_totalsize(fdt);
+	char *tmp;
+
+	FDT_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+
+	if (fdt_version(fdt) >= 17) {
+		struct_size = fdt_size_dt_struct(fdt);
+	} else {
+		struct_size = 0;
+		while (fdt_next_tag(fdt, struct_size, &struct_size) != FDT_END)
+			;
+		if (struct_size < 0)
+			return struct_size;
+	}
+
+	if (!_fdt_blocks_misordered(fdt, mem_rsv_size, struct_size)) {
+		/* no further work necessary */
+		err = fdt_move(fdt, buf, bufsize);
+		if (err)
+			return err;
+		fdt_set_version(buf, 17);
+		fdt_set_size_dt_struct(buf, struct_size);
+		fdt_set_totalsize(buf, bufsize);
+		return 0;
+	}
+
+	/* Need to reorder */
+	newsize = FDT_ALIGN(sizeof(struct fdt_header), 8) + mem_rsv_size
+		+ struct_size + fdt_size_dt_strings(fdt);
+
+	if (bufsize < newsize)
+		return -FDT_ERR_NOSPACE;
+
+	/* First attempt to build converted tree at beginning of buffer */
+	tmp = buf;
+	/* But if that overlaps with the old tree... */
+	if (((tmp + newsize) > fdtstart) && (tmp < fdtend)) {
+		/* Try right after the old tree instead */
+		tmp = (char *)(uintptr_t)fdtend;
+		if ((tmp + newsize) > ((char *)buf + bufsize))
+			return -FDT_ERR_NOSPACE;
+	}
+
+	_fdt_packblocks(fdt, tmp, mem_rsv_size, struct_size);
+	memmove(buf, tmp, newsize);
+
+	fdt_set_magic(buf, FDT_MAGIC);
+	fdt_set_totalsize(buf, bufsize);
+	fdt_set_version(buf, 17);
+	fdt_set_last_comp_version(buf, 16);
+	fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
+
+	return 0;
+}
+
+int fdt_pack(void *fdt)
+{
+	int mem_rsv_size;
+
+	FDT_RW_CHECK_HEADER(fdt);
+
+	mem_rsv_size = (fdt_num_mem_rsv(fdt)+1)
+		* sizeof(struct fdt_reserve_entry);
+	_fdt_packblocks(fdt, fdt, mem_rsv_size, fdt_size_dt_struct(fdt));
+	fdt_set_totalsize(fdt, _fdt_data_size(fdt));
+
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_strerror.c b/xen/common/libfdt/fdt_strerror.c
new file mode 100644
index 0000000..e6c3cee
--- /dev/null
+++ b/xen/common/libfdt/fdt_strerror.c
@@ -0,0 +1,96 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+struct fdt_errtabent {
+	const char *str;
+};
+
+#define FDT_ERRTABENT(val) \
+	[(val)] = { .str = #val, }
+
+static struct fdt_errtabent fdt_errtable[] = {
+	FDT_ERRTABENT(FDT_ERR_NOTFOUND),
+	FDT_ERRTABENT(FDT_ERR_EXISTS),
+	FDT_ERRTABENT(FDT_ERR_NOSPACE),
+
+	FDT_ERRTABENT(FDT_ERR_BADOFFSET),
+	FDT_ERRTABENT(FDT_ERR_BADPATH),
+	FDT_ERRTABENT(FDT_ERR_BADSTATE),
+
+	FDT_ERRTABENT(FDT_ERR_TRUNCATED),
+	FDT_ERRTABENT(FDT_ERR_BADMAGIC),
+	FDT_ERRTABENT(FDT_ERR_BADVERSION),
+	FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
+	FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+};
+#define FDT_ERRTABSIZE	(sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
+
+const char *fdt_strerror(int errval)
+{
+	if (errval > 0)
+		return "<valid offset/length>";
+	else if (errval == 0)
+		return "<no error>";
+	else if (errval > -FDT_ERRTABSIZE) {
+		const char *s = fdt_errtable[-errval].str;
+
+		if (s)
+			return s;
+	}
+
+	return "<unknown error>";
+}
diff --git a/xen/common/libfdt/fdt_sw.c b/xen/common/libfdt/fdt_sw.c
new file mode 100644
index 0000000..55ebebf
--- /dev/null
+++ b/xen/common/libfdt/fdt_sw.c
@@ -0,0 +1,256 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+static int _fdt_sw_check_header(void *fdt)
+{
+	if (fdt_magic(fdt) != FDT_SW_MAGIC)
+		return -FDT_ERR_BADMAGIC;
+	/* FIXME: should check more details about the header state */
+	return 0;
+}
+
+#define FDT_SW_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = _fdt_sw_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+static void *_fdt_grab_space(void *fdt, size_t len)
+{
+	int offset = fdt_size_dt_struct(fdt);
+	int spaceleft;
+
+	spaceleft = fdt_totalsize(fdt) - fdt_off_dt_struct(fdt)
+		- fdt_size_dt_strings(fdt);
+
+	if ((offset + len < offset) || (offset + len > spaceleft))
+		return NULL;
+
+	fdt_set_size_dt_struct(fdt, offset + len);
+	return _fdt_offset_ptr_w(fdt, offset);
+}
+
+int fdt_create(void *buf, int bufsize)
+{
+	void *fdt = buf;
+
+	if (bufsize < sizeof(struct fdt_header))
+		return -FDT_ERR_NOSPACE;
+
+	memset(buf, 0, bufsize);
+
+	fdt_set_magic(fdt, FDT_SW_MAGIC);
+	fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+	fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
+	fdt_set_totalsize(fdt,  bufsize);
+
+	fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
+					      sizeof(struct fdt_reserve_entry)));
+	fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
+	fdt_set_off_dt_strings(fdt, bufsize);
+
+	return 0;
+}
+
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size)
+{
+	struct fdt_reserve_entry *re;
+	int offset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	if (fdt_size_dt_struct(fdt))
+		return -FDT_ERR_BADSTATE;
+
+	offset = fdt_off_dt_struct(fdt);
+	if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
+		return -FDT_ERR_NOSPACE;
+
+	re = (struct fdt_reserve_entry *)((char *)fdt + offset);
+	re->address = cpu_to_fdt64(addr);
+	re->size = cpu_to_fdt64(size);
+
+	fdt_set_off_dt_struct(fdt, offset + sizeof(*re));
+
+	return 0;
+}
+
+int fdt_finish_reservemap(void *fdt)
+{
+	return fdt_add_reservemap_entry(fdt, 0, 0);
+}
+
+int fdt_begin_node(void *fdt, const char *name)
+{
+	struct fdt_node_header *nh;
+	int namelen = strlen(name) + 1;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nh = _fdt_grab_space(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
+	if (! nh)
+		return -FDT_ERR_NOSPACE;
+
+	nh->tag = cpu_to_fdt32(FDT_BEGIN_NODE);
+	memcpy(nh->name, name, namelen);
+	return 0;
+}
+
+int fdt_end_node(void *fdt)
+{
+	uint32_t *en;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	en = _fdt_grab_space(fdt, FDT_TAGSIZE);
+	if (! en)
+		return -FDT_ERR_NOSPACE;
+
+	*en = cpu_to_fdt32(FDT_END_NODE);
+	return 0;
+}
+
+static int _fdt_find_add_string(void *fdt, const char *s)
+{
+	char *strtab = (char *)fdt + fdt_totalsize(fdt);
+	const char *p;
+	int strtabsize = fdt_size_dt_strings(fdt);
+	int len = strlen(s) + 1;
+	int struct_top, offset;
+
+	p = _fdt_find_string(strtab - strtabsize, strtabsize, s);
+	if (p)
+		return p - strtab;
+
+	/* Add it */
+	offset = -strtabsize - len;
+	struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	if (fdt_totalsize(fdt) + offset < struct_top)
+		return 0; /* no more room :( */
+
+	memcpy(strtab + offset, s, len);
+	fdt_set_size_dt_strings(fdt, strtabsize + len);
+	return offset;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+	struct fdt_property *prop;
+	int nameoff;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	nameoff = _fdt_find_add_string(fdt, name);
+	if (nameoff == 0)
+		return -FDT_ERR_NOSPACE;
+
+	prop = _fdt_grab_space(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
+	if (! prop)
+		return -FDT_ERR_NOSPACE;
+
+	prop->tag = cpu_to_fdt32(FDT_PROP);
+	prop->nameoff = cpu_to_fdt32(nameoff);
+	prop->len = cpu_to_fdt32(len);
+	memcpy(prop->data, val, len);
+	return 0;
+}
+
+int fdt_finish(void *fdt)
+{
+	char *p = (char *)fdt;
+	uint32_t *end;
+	int oldstroffset, newstroffset;
+	uint32_t tag;
+	int offset, nextoffset;
+
+	FDT_SW_CHECK_HEADER(fdt);
+
+	/* Add terminator */
+	end = _fdt_grab_space(fdt, sizeof(*end));
+	if (! end)
+		return -FDT_ERR_NOSPACE;
+	*end = cpu_to_fdt32(FDT_END);
+
+	/* Relocate the string table */
+	oldstroffset = fdt_totalsize(fdt) - fdt_size_dt_strings(fdt);
+	newstroffset = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+	memmove(p + newstroffset, p + oldstroffset, fdt_size_dt_strings(fdt));
+	fdt_set_off_dt_strings(fdt, newstroffset);
+
+	/* Walk the structure, correcting string offsets */
+	offset = 0;
+	while ((tag = fdt_next_tag(fdt, offset, &nextoffset)) != FDT_END) {
+		if (tag == FDT_PROP) {
+			struct fdt_property *prop =
+				_fdt_offset_ptr_w(fdt, offset);
+			int nameoff;
+
+			nameoff = fdt32_to_cpu(prop->nameoff);
+			nameoff += fdt_size_dt_strings(fdt);
+			prop->nameoff = cpu_to_fdt32(nameoff);
+		}
+		offset = nextoffset;
+	}
+	if (nextoffset < 0)
+		return nextoffset;
+
+	/* Finally, adjust the header */
+	fdt_set_totalsize(fdt, newstroffset + fdt_size_dt_strings(fdt));
+	fdt_set_magic(fdt, FDT_MAGIC);
+	return 0;
+}
diff --git a/xen/common/libfdt/fdt_wip.c b/xen/common/libfdt/fdt_wip.c
new file mode 100644
index 0000000..6025fa1
--- /dev/null
+++ b/xen/common/libfdt/fdt_wip.c
@@ -0,0 +1,118 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include "libfdt_env.h"
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "libfdt_internal.h"
+
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len)
+{
+	void *propval;
+	int proplen;
+
+	propval = fdt_getprop_w(fdt, nodeoffset, name, &proplen);
+	if (! propval)
+		return proplen;
+
+	if (proplen != len)
+		return -FDT_ERR_NOSPACE;
+
+	memcpy(propval, val, len);
+	return 0;
+}
+
+static void _fdt_nop_region(void *start, int len)
+{
+	uint32_t *p;
+
+	for (p = start; (char *)p < ((char *)start + len); p++)
+		*p = cpu_to_fdt32(FDT_NOP);
+}
+
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name)
+{
+	struct fdt_property *prop;
+	int len;
+
+	prop = fdt_get_property_w(fdt, nodeoffset, name, &len);
+	if (! prop)
+		return len;
+
+	_fdt_nop_region(prop, len + sizeof(*prop));
+
+	return 0;
+}
+
+int _fdt_node_end_offset(void *fdt, int offset)
+{
+	int depth = 0;
+
+	while ((offset >= 0) && (depth >= 0))
+		offset = fdt_next_node(fdt, offset, &depth);
+
+	return offset;
+}
+
+int fdt_nop_node(void *fdt, int nodeoffset)
+{
+	int endoffset;
+
+	endoffset = _fdt_node_end_offset(fdt, nodeoffset);
+	if (endoffset < 0)
+		return endoffset;
+
+	_fdt_nop_region(fdt_offset_ptr_w(fdt, nodeoffset, 0),
+			endoffset - nodeoffset);
+	return 0;
+}
diff --git a/xen/common/libfdt/libfdt.h b/xen/common/libfdt/libfdt.h
new file mode 100644
index 0000000..55f3eb3
--- /dev/null
+++ b/xen/common/libfdt/libfdt.h
@@ -0,0 +1,1235 @@
+#ifndef _LIBFDT_H
+#define _LIBFDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <libfdt_env.h>
+#include <fdt.h>
+
+#define FDT_FIRST_SUPPORTED_VERSION	0x10
+#define FDT_LAST_SUPPORTED_VERSION	0x11
+
+/* Error codes: informative error codes */
+#define FDT_ERR_NOTFOUND	1
+	/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
+#define FDT_ERR_EXISTS		2
+	/* FDT_ERR_EXISTS: Attemped to create a node or property which
+	 * already exists */
+#define FDT_ERR_NOSPACE		3
+	/* FDT_ERR_NOSPACE: Operation needed to expand the device
+	 * tree, but its buffer did not have sufficient space to
+	 * contain the expanded tree. Use fdt_open_into() to move the
+	 * device tree to a buffer with more space. */
+
+/* Error codes: codes for bad parameters */
+#define FDT_ERR_BADOFFSET	4
+	/* FDT_ERR_BADOFFSET: Function was passed a structure block
+	 * offset which is out-of-bounds, or which points to an
+	 * unsuitable part of the structure for the operation. */
+#define FDT_ERR_BADPATH		5
+	/* FDT_ERR_BADPATH: Function was passed a badly formatted path
+	 * (e.g. missing a leading / for a function which requires an
+	 * absolute path) */
+#define FDT_ERR_BADPHANDLE	6
+	/* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
+	 * value.  phandle values of 0 and -1 are not permitted. */
+#define FDT_ERR_BADSTATE	7
+	/* FDT_ERR_BADSTATE: Function was passed an incomplete device
+	 * tree created by the sequential-write functions, which is
+	 * not sufficiently complete for the requested operation. */
+
+/* Error codes: codes for bad device tree blobs */
+#define FDT_ERR_TRUNCATED	8
+	/* FDT_ERR_TRUNCATED: Structure block of the given device tree
+	 * ends without an FDT_END tag. */
+#define FDT_ERR_BADMAGIC	9
+	/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+	 * device tree at all - it is missing the flattened device
+	 * tree magic number. */
+#define FDT_ERR_BADVERSION	10
+	/* FDT_ERR_BADVERSION: Given device tree has a version which
+	 * can't be handled by the requested operation.  For
+	 * read-write functions, this may mean that fdt_open_into() is
+	 * required to convert the tree to the expected version. */
+#define FDT_ERR_BADSTRUCTURE	11
+	/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+	 * structure block or other serious error (e.g. misnested
+	 * nodes, or subnodes preceding properties). */
+#define FDT_ERR_BADLAYOUT	12
+	/* FDT_ERR_BADLAYOUT: For read-write functions, the given
+	 * device tree has it's sub-blocks in an order that the
+	 * function can't handle (memory reserve map, then structure,
+	 * then strings).  Use fdt_open_into() to reorganize the tree
+	 * into a form suitable for the read-write operations. */
+
+/* "Can't happen" error indicating a bug in libfdt */
+#define FDT_ERR_INTERNAL	13
+	/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+	 * Should never be returned, if it is, it indicates a bug in
+	 * libfdt itself. */
+
+#define FDT_ERR_MAX		13
+
+/**********************************************************************/
+/* Low-level functions (you probably don't need these)                */
+/**********************************************************************/
+
+const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
+{
+	return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
+}
+
+uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+
+/**********************************************************************/
+/* Traversal functions                                                */
+/**********************************************************************/
+
+int fdt_next_node(const void *fdt, int offset, int *depth);
+
+/**********************************************************************/
+/* General functions                                                  */
+/**********************************************************************/
+
+#define fdt_get_header(fdt, field) \
+	(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
+#define fdt_magic(fdt) 			(fdt_get_header(fdt, magic))
+#define fdt_totalsize(fdt)		(fdt_get_header(fdt, totalsize))
+#define fdt_off_dt_struct(fdt)		(fdt_get_header(fdt, off_dt_struct))
+#define fdt_off_dt_strings(fdt)		(fdt_get_header(fdt, off_dt_strings))
+#define fdt_off_mem_rsvmap(fdt)		(fdt_get_header(fdt, off_mem_rsvmap))
+#define fdt_version(fdt)		(fdt_get_header(fdt, version))
+#define fdt_last_comp_version(fdt) 	(fdt_get_header(fdt, last_comp_version))
+#define fdt_boot_cpuid_phys(fdt) 	(fdt_get_header(fdt, boot_cpuid_phys))
+#define fdt_size_dt_strings(fdt) 	(fdt_get_header(fdt, size_dt_strings))
+#define fdt_size_dt_struct(fdt)		(fdt_get_header(fdt, size_dt_struct))
+
+#define __fdt_set_hdr(name) \
+	static inline void fdt_set_##name(void *fdt, uint32_t val) \
+	{ \
+		struct fdt_header *fdth = (struct fdt_header*)fdt; \
+		fdth->name = cpu_to_fdt32(val); \
+	}
+__fdt_set_hdr(magic);
+__fdt_set_hdr(totalsize);
+__fdt_set_hdr(off_dt_struct);
+__fdt_set_hdr(off_dt_strings);
+__fdt_set_hdr(off_mem_rsvmap);
+__fdt_set_hdr(version);
+__fdt_set_hdr(last_comp_version);
+__fdt_set_hdr(boot_cpuid_phys);
+__fdt_set_hdr(size_dt_strings);
+__fdt_set_hdr(size_dt_struct);
+#undef __fdt_set_hdr
+
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ *     0, if the buffer appears to contain a valid device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings, as above
+ */
+int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize.  The buffer may overlap
+ * with the existing device tree blob at fdt.  Therefore,
+ *     fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_move(const void *fdt, void *buf, int bufsize);
+
+/**********************************************************************/
+/* Read-only functions                                                */
+/**********************************************************************/
+
+/**
+ * fdt_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ *     a pointer to the string, on success
+ *     NULL, if stroffset is out of bounds
+ */
+const char *fdt_string(const void *fdt, int stroffset);
+
+/**
+ * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map.  This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ *     the number of entries
+ */
+int fdt_num_mem_rsv(const void *fdt);
+
+/**
+ * fdt_get_mem_rsv - retrieve one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ *     0, on success
+ *     -FDT_ERR_BADMAGIC,
+ *     -FDT_ERR_BADVERSION,
+ *     -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
+/**
+ * fdt_subnode_offset_namelen - find a subnode based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_subnode_offset(), but only examine the first
+ * namelen characters of name for matching the subnode name.  This is
+ * useful for finding subnodes based on a portion of a larger string,
+ * such as a full path.
+ */
+int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+			       const char *name, int namelen);
+/**
+ * fdt_subnode_offset - find a subnode of a given node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_subnode_offset() finds a subnode of the node at structure block
+ * offset parentoffset with the given name.  name may include a unit
+ * address, in which case fdt_subnode_offset() will find the subnode
+ * with that unit address, or the unit address may be omitted, in
+ * which case fdt_subnode_offset() will find an arbitrary subnode
+ * whose name excluding unit address matches the given name.
+ *
+ * returns:
+ *	structure block offset of the requested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_path_offset - find a tree node by its full path
+ * @fdt: pointer to the device tree blob
+ * @path: full path of the node to locate
+ *
+ * fdt_path_offset() finds a node of a given path in the device tree.
+ * Each path component may omit the unit address portion, but the
+ * results of this are undefined if any such path component is
+ * ambiguous (that is if there are multiple nodes at the relevant
+ * level matching the given component, differentiated only by unit
+ * address).
+ *
+ * returns:
+ *	structure block offset of the node with the requested path (>=0), on success
+ *	-FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
+ *	-FDT_ERR_NOTFOUND, if the requested node does not exist
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_path_offset(const void *fdt, const char *path);
+
+/**
+ * fdt_get_name - retrieve the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the starting node
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_name() retrieves the name (including unit address) of the
+ * device tree node at structure block offset nodeoffset.  If lenp is
+ * non-NULL, the length of this name is also returned, in the integer
+ * pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the node's name, on success
+ *		If lenp is non-NULL, *lenp contains the length of that name (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE, standard meanings
+ */
+const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
+
+/**
+ * fdt_first_property_offset - find the offset of a node's first property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ *
+ * fdt_first_property_offset() finds the first property of the node at
+ * the given structure block offset.
+ *
+ * returns:
+ *	structure block offset of the property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested node has no properties
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_BEGIN_NODE tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_first_property_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_next_property_offset - step through a node's properties
+ * @fdt: pointer to the device tree blob
+ * @offset: structure block offset of a property
+ *
+ * fdt_next_property_offset() finds the property immediately after the
+ * one at the given structure block offset.  This will be a property
+ * of the same node as the given property.
+ *
+ * returns:
+ *	structure block offset of the next property (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the given property is the last in its node
+ *	-FDT_ERR_BADOFFSET, if nodeoffset did not point to an FDT_PROP tag
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_next_property_offset(const void *fdt, int offset);
+
+/**
+ * fdt_get_property_by_offset - retrieve the property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @offset: offset of the property to retrieve
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property_by_offset() retrieves a pointer to the
+ * fdt_property structure within the device tree blob at the given
+ * offset.  If lenp is non-NULL, the length of the property value is
+ * also returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+						      int offset,
+						      int *lenp);
+
+/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+						    int nodeoffset,
+						    const char *name,
+						    int namelen, int *lenp);
+
+/**
+ * fdt_get_property - find a given property in a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_get_property() retrieves a pointer to the fdt_property
+ * structure within the device tree blob corresponding to the property
+ * named 'name' of the node at offset nodeoffset.  If lenp is
+ * non-NULL, the length of the property value is also returned, in the
+ * integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the structure representing the property
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const struct fdt_property *fdt_get_property(const void *fdt, int nodeoffset,
+					    const char *name, int *lenp);
+static inline struct fdt_property *fdt_get_property_w(void *fdt, int nodeoffset,
+						      const char *name,
+						      int *lenp)
+{
+	return (struct fdt_property *)(uintptr_t)
+		fdt_get_property(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_getprop_by_offset - retrieve the value of a property at a given offset
+ * @fdt: pointer to the device tree blob
+ * @ffset: offset of the property to read
+ * @namep: pointer to a string variable (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop_by_offset() retrieves a pointer to the value of the
+ * property at structure block offset 'offset' (this will be a pointer
+ * to within the device blob itself, not a copy of the value).  If
+ * lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.  If namep is non-NULL,
+ * the property's namne will also be returned in the char * pointed to
+ * by namep (this will be a pointer to within the device tree's string
+ * block, not a new copy of the name).
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *		if namep is non-NULL *namep contiains a pointer to the property
+ *		name.
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_PROP tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_by_offset(const void *fdt, int offset,
+				  const char **namep, int *lenp);
+
+/**
+ * fdt_getprop_namelen - get property value based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_getprop(), but only examine the first namelen
+ * characters of name for matching the property name.
+ */
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+				const char *name, int namelen, int *lenp);
+
+/**
+ * fdt_getprop - retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value is also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ *	pointer to the property's value
+ *		if lenp is non-NULL, *lenp contains the length of the property
+ *		value (>=0)
+ *	NULL, on error
+ *		if lenp is non-NULL, *lenp contains an error code (<0):
+ *		-FDT_ERR_NOTFOUND, node does not have named property
+ *		-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *		-FDT_ERR_BADMAGIC,
+ *		-FDT_ERR_BADVERSION,
+ *		-FDT_ERR_BADSTATE,
+ *		-FDT_ERR_BADSTRUCTURE,
+ *		-FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+			const char *name, int *lenp);
+static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
+				  const char *name, int *lenp)
+{
+	return (void *)(uintptr_t)fdt_getprop(fdt, nodeoffset, name, lenp);
+}
+
+/**
+ * fdt_get_phandle - retrieve the phandle of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of the node
+ *
+ * fdt_get_phandle() retrieves the phandle of the device tree node at
+ * structure block offset nodeoffset.
+ *
+ * returns:
+ *	the phandle of the node at nodeoffset, on success (!= 0, != -1)
+ *	0, if the node has no phandle, or another error occurs
+ */
+uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_get_alias_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+				  const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias.  That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ *	a pointer to the expansion of the alias named 'name', of it exists
+ *	NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
+ * fdt_get_path - determine the full path of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose path to find
+ * @buf: character buffer to contain the returned path (will be overwritten)
+ * @buflen: size of the character buffer at buf
+ *
+ * fdt_get_path() computes the full path of the node at offset
+ * nodeoffset, and records that path in the buffer at buf.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	0, on success
+ *		buf contains the absolute path of the node at
+ *		nodeoffset, as a NUL-terminated string.
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_NOSPACE, the path of the given node is longer than (bufsize-1)
+ *		characters and will not fit in the given buffer.
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen);
+
+/**
+ * fdt_supernode_atdepth_offset - find a specific ancestor of a node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ * @supernodedepth: depth of the ancestor to find
+ * @nodedepth: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_supernode_atdepth_offset() finds an ancestor of the given node
+ * at a specific depth from the root (where the root itself has depth
+ * 0, its immediate subnodes depth 1 and so forth).  So
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, 0, NULL);
+ * will always return 0, the offset of the root node.  If the node at
+ * nodeoffset has depth D, then:
+ *	fdt_supernode_atdepth_offset(fdt, nodeoffset, D, NULL);
+ * will return nodeoffset itself.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+
+ *	structure block offset of the node at node offset's ancestor
+ *		of depth supernodedepth (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+*	-FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of nodeoffset
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_supernode_atdepth_offset(const void *fdt, int nodeoffset,
+				 int supernodedepth, int *nodedepth);
+
+/**
+ * fdt_node_depth - find the depth of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_node_depth() finds the depth of a given node.  The root node
+ * has depth 0, its immediate subnodes depth 1 and so forth.
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset.
+ *
+ * returns:
+ *	depth of the node at nodeoffset (>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_depth(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_parent_offset - find the parent of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose parent to find
+ *
+ * fdt_parent_offset() locates the parent node of a given node (that
+ * is, it finds the offset of the node which contains the node at
+ * nodeoffset as a subnode).
+ *
+ * NOTE: This function is expensive, as it must scan the device tree
+ * structure from the start to nodeoffset, *twice*.
+ *
+ * returns:
+ *	structure block offset of the parent of the node at nodeoffset
+ *		(>=0), on success
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_parent_offset(const void *fdt, int nodeoffset);
+
+/**
+ * fdt_node_offset_by_prop_value - find nodes with a given property value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @propname: property name to check
+ * @propval: property value to search for
+ * @proplen: length of the value in propval
+ *
+ * fdt_node_offset_by_prop_value() returns the offset of the first
+ * node after startoffset, which has a property named propname whose
+ * value is of length proplen and has value equal to propval; or if
+ * startoffset is -1, the very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_prop_value(fdt, -1, propname,
+ *					       propval, proplen);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_prop_value(fdt, offset, propname,
+ *						       propval, proplen);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_prop_value(const void *fdt, int startoffset,
+				  const char *propname,
+				  const void *propval, int proplen);
+
+/**
+ * fdt_node_offset_by_phandle - find the node with a given phandle
+ * @fdt: pointer to the device tree blob
+ * @phandle: phandle value
+ *
+ * fdt_node_offset_by_phandle() returns the offset of the node
+ * which has the given phandle value.  If there is more than one node
+ * in the tree with the given phandle (an invalid tree), results are
+ * undefined.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0), on success
+ *	-FDT_ERR_NOTFOUND, no node with that phandle exists
+ *	-FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle);
+
+/**
+ * fdt_node_check_compatible: check a node's compatible property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of a tree node
+ * @compatible: string to match against
+ *
+ *
+ * fdt_node_check_compatible() returns 0 if the given node contains a
+ * 'compatible' property with the given string as one of its elements,
+ * it returns non-zero otherwise, or on error.
+ *
+ * returns:
+ *	0, if the node has a 'compatible' property listing the given string
+ *	1, if the node has a 'compatible' property, but it does not list
+ *		the given string
+ *	-FDT_ERR_NOTFOUND, if the given node has no 'compatible' property
+ * 	-FDT_ERR_BADOFFSET, if nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+			      const char *compatible);
+
+/**
+ * fdt_node_offset_by_compatible - find nodes with a given 'compatible' value
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @compatible: 'compatible' string to match against
+ *
+ * fdt_node_offset_by_compatible() returns the offset of the first
+ * node after startoffset, which has a 'compatible' property which
+ * lists the given compatible string; or if startoffset is -1, the
+ * very first such node in the tree.
+ *
+ * To iterate through all nodes matching the criterion, the following
+ * idiom can be used:
+ *	offset = fdt_node_offset_by_compatible(fdt, -1, compatible);
+ *	while (offset != -FDT_ERR_NOTFOUND) {
+ *		// other code here
+ *		offset = fdt_node_offset_by_compatible(fdt, offset, compatible);
+ *	}
+ *
+ * Note the -1 in the first call to the function, if 0 is used here
+ * instead, the function will never locate the root node, even if it
+ * matches the criterion.
+ *
+ * returns:
+ *	structure block offset of the located node (>= 0, >startoffset),
+ *		 on success
+ *	-FDT_ERR_NOTFOUND, no node matching the criterion exists in the
+ *		tree after startoffset
+ * 	-FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+				  const char *compatible);
+
+/**********************************************************************/
+/* Write-in-place functions                                           */
+/**********************************************************************/
+
+/**
+ * fdt_setprop_inplace - change a property's value, but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * fdt_setprop_inplace() replaces the value of a given property with
+ * the data in val, of length len.  This function cannot change the
+ * size of a property, and so will only work if len is equal to the
+ * current length of the property.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if len is not equal to the property's current length
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
+			const void *val, int len);
+
+/**
+ * fdt_setprop_inplace_cell - change the value of a single-cell property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: cell (32-bit integer) value to replace the property with
+ *
+ * fdt_setprop_inplace_cell() replaces the value of a given property
+ * with the 32-bit integer cell value in val, converting val to
+ * big-endian if necessary.  This function cannot change the size of a
+ * property, and so will only work if the property already exists and
+ * has length 4.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the given property value, and will not alter or move any other part
+ * of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, if the property's length is not equal to 4
+  *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+					   const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_nop_property - replace a property with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_nop_property() will replace a given property's representation
+ * in the blob with FDT_NOP tags, effectively removing it from the
+ * tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the property, and will not alter or move any other part of the
+ * tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_nop_node - replace a node (subtree) with nop tags
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_nop_node() will replace a given node's representation in the
+ * blob, including all its subnodes, if any, with FDT_NOP tags,
+ * effectively removing it from the tree.
+ *
+ * This function will alter only the bytes in the blob which contain
+ * the node and its properties and subnodes, and will not alter or
+ * move any other part of the tree.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_nop_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Sequential write functions                                         */
+/**********************************************************************/
+
+int fdt_create(void *buf, int bufsize);
+int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
+int fdt_finish_reservemap(void *fdt);
+int fdt_begin_node(void *fdt, const char *name);
+int fdt_property(void *fdt, const char *name, const void *val, int len);
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_property(fdt, name, &val, sizeof(val));
+}
+#define fdt_property_string(fdt, name, str) \
+	fdt_property(fdt, name, str, strlen(str)+1)
+int fdt_end_node(void *fdt);
+int fdt_finish(void *fdt);
+
+/**********************************************************************/
+/* Read-write functions                                               */
+/**********************************************************************/
+
+int fdt_open_into(const void *fdt, void *buf, int bufsize);
+int fdt_pack(void *fdt);
+
+/**
+ * fdt_add_mem_rsv - add one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: 64-bit values (native endian)
+ *
+ * Adds a reserve map entry to the given blob reserving a region at
+ * address address of length size.
+ *
+ * This function will insert data into the reserve map and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new reservation entry
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
+
+/**
+ * fdt_del_mem_rsv - remove a memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @n: entry to remove
+ *
+ * fdt_del_mem_rsv() removes the n-th memory reserve map entry from
+ * the blob.
+ *
+ * This function will delete data from the reservation table and will
+ * therefore change the indexes of some entries in the table.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, there is no entry of the given index (i.e. there
+ *		are less than n+1 reserve map entries)
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_mem_rsv(void *fdt, int n);
+
+/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string.  NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ *		to contain the new name
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_setprop - create or change a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: pointer to data to set the property value to
+ * @len: length of the property value
+ *
+ * fdt_setprop() sets the value of the named property in the given
+ * node to the given value and length, creating the property if it
+ * does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+		const void *val, int len);
+
+/**
+ * fdt_setprop_cell - set a property to a single cell value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @val: 32-bit integer value for the property (native endian)
+ *
+ * fdt_setprop_cell() sets the value of the named property in the
+ * given node to the given cell value (converting to big-endian if
+ * necessary), or creates a new property with that value if it does
+ * not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+				   uint32_t val)
+{
+	val = cpu_to_fdt32(val);
+	return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
+
+/**
+ * fdt_setprop_string - set a property to a string value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @str: string value for the property
+ *
+ * fdt_setprop_string() sets the value of the named property in the
+ * given node to the given string value (using the length of the
+ * string to determine the new length of the property), or creates a
+ * new property with that value if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ *		contain the new property value
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_string(fdt, nodeoffset, name, str) \
+	fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
+
+/**
+ * fdt_delprop - delete a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to nop
+ * @name: name of the property to nop
+ *
+ * fdt_del_property() will delete the given property.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_NOTFOUND, node does not have the named property
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_delprop(void *fdt, int nodeoffset, const char *name);
+
+/**
+ * fdt_add_subnode_namelen - creates a new node based on substring
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_add_subnode(), but use only the first namelen
+ * characters of name as the name of the new node.  This is useful for
+ * creating subnodes based on a portion of a larger string, such as a
+ * full path.
+ */
+int fdt_add_subnode_namelen(void *fdt, int parentoffset,
+			    const char *name, int namelen);
+
+/**
+ * fdt_add_subnode - creates a new node
+ * @fdt: pointer to the device tree blob
+ * @parentoffset: structure block offset of a node
+ * @name: name of the subnode to locate
+ *
+ * fdt_add_subnode() creates a new node as a subnode of the node at
+ * structure block offset parentoffset, with the given name (which
+ * should include the unit address, if any).
+ *
+ * This function will insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+
+ * returns:
+ *	structure block offset of the created nodeequested subnode (>=0), on success
+ *	-FDT_ERR_NOTFOUND, if the requested subnode does not exist
+ *	-FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE tag
+ *	-FDT_ERR_EXISTS, if the node at parentoffset already has a subnode of
+ *		the given name
+ *	-FDT_ERR_NOSPACE, if there is insufficient free space in the
+ *		blob to contain the new node
+ *	-FDT_ERR_NOSPACE
+ *	-FDT_ERR_BADLAYOUT
+ *      -FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings.
+ */
+int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
+
+/**
+ * fdt_del_node - delete a node (subtree)
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node to nop
+ *
+ * fdt_del_node() will remove the given node, including all its
+ * subnodes if any, from the blob.
+ *
+ * This function will delete data from the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ *	0, on success
+ *	-FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ *	-FDT_ERR_BADLAYOUT,
+ *	-FDT_ERR_BADMAGIC,
+ *	-FDT_ERR_BADVERSION,
+ *	-FDT_ERR_BADSTATE,
+ *	-FDT_ERR_BADSTRUCTURE,
+ *	-FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_del_node(void *fdt, int nodeoffset);
+
+/**********************************************************************/
+/* Debugging / informational functions                                */
+/**********************************************************************/
+
+const char *fdt_strerror(int errval);
+
+#endif /* _LIBFDT_H */
diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
new file mode 100644
index 0000000..449bf60
--- /dev/null
+++ b/xen/common/libfdt/libfdt_env.h
@@ -0,0 +1,23 @@
+#ifndef _LIBFDT_ENV_H
+#define _LIBFDT_ENV_H
+
+#include <stddef.h>
+#include <stdint.h>
+#include <string.h>
+
+#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
+static inline uint32_t fdt32_to_cpu(uint32_t x)
+{
+	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
+}
+#define cpu_to_fdt32(x) fdt32_to_cpu(x)
+
+static inline uint64_t fdt64_to_cpu(uint64_t x)
+{
+	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
+		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
+}
+#define cpu_to_fdt64(x) fdt64_to_cpu(x)
+#undef _B
+
+#endif /* _LIBFDT_ENV_H */
diff --git a/xen/common/libfdt/libfdt_internal.h b/xen/common/libfdt/libfdt_internal.h
new file mode 100644
index 0000000..381133b
--- /dev/null
+++ b/xen/common/libfdt/libfdt_internal.h
@@ -0,0 +1,95 @@
+#ifndef _LIBFDT_INTERNAL_H
+#define _LIBFDT_INTERNAL_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library 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 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 General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *     1. Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *     2. Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ *     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ *     CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ *     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ *     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ *     DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ *     CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *     NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ *     LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ *     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ *     CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ *     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include <fdt.h>
+
+#define FDT_ALIGN(x, a)		(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)		(FDT_ALIGN((x), FDT_TAGSIZE))
+
+#define FDT_CHECK_HEADER(fdt) \
+	{ \
+		int err; \
+		if ((err = fdt_check_header(fdt)) != 0) \
+			return err; \
+	}
+
+int _fdt_check_node_offset(const void *fdt, int offset);
+int _fdt_check_prop_offset(const void *fdt, int offset);
+const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
+int _fdt_node_end_offset(void *fdt, int nodeoffset);
+
+static inline const void *_fdt_offset_ptr(const void *fdt, int offset)
+{
+	return (const char *)fdt + fdt_off_dt_struct(fdt) + offset;
+}
+
+static inline void *_fdt_offset_ptr_w(void *fdt, int offset)
+{
+	return (void *)(uintptr_t)_fdt_offset_ptr(fdt, offset);
+}
+
+static inline const struct fdt_reserve_entry *_fdt_mem_rsv(const void *fdt, int n)
+{
+	const struct fdt_reserve_entry *rsv_table =
+		(const struct fdt_reserve_entry *)
+		((const char *)fdt + fdt_off_mem_rsvmap(fdt));
+
+	return rsv_table + n;
+}
+static inline struct fdt_reserve_entry *_fdt_mem_rsv_w(void *fdt, int n)
+{
+	return (void *)(uintptr_t)_fdt_mem_rsv(fdt, n);
+}
+
+#define FDT_SW_MAGIC		(~FDT_MAGIC)
+
+#endif /* _LIBFDT_INTERNAL_H */
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
new file mode 100644
index 0000000..3c3994e
--- /dev/null
+++ b/xen/common/libfdt/version.lds
@@ -0,0 +1,54 @@
+LIBFDT_1.2 {
+	global:
+		fdt_next_node;
+		fdt_check_header;
+		fdt_move;
+		fdt_string;
+		fdt_num_mem_rsv;
+		fdt_get_mem_rsv;
+		fdt_subnode_offset_namelen;
+		fdt_subnode_offset;
+		fdt_path_offset;
+		fdt_get_name;
+		fdt_get_property_namelen;
+		fdt_get_property;
+		fdt_getprop_namelen;
+		fdt_getprop;
+		fdt_get_phandle;
+		fdt_get_alias_namelen;
+		fdt_get_alias;
+		fdt_get_path;
+		fdt_supernode_atdepth_offset;
+		fdt_node_depth;
+		fdt_parent_offset;
+		fdt_node_offset_by_prop_value;
+		fdt_node_offset_by_phandle;
+		fdt_node_check_compatible;
+		fdt_node_offset_by_compatible;
+		fdt_setprop_inplace;
+		fdt_nop_property;
+		fdt_nop_node;
+		fdt_create;
+		fdt_add_reservemap_entry;
+		fdt_finish_reservemap;
+		fdt_begin_node;
+		fdt_property;
+		fdt_end_node;
+		fdt_finish;
+		fdt_open_into;
+		fdt_pack;
+		fdt_add_mem_rsv;
+		fdt_del_mem_rsv;
+		fdt_set_name;
+		fdt_setprop;
+		fdt_delprop;
+		fdt_add_subnode_namelen;
+		fdt_add_subnode;
+		fdt_del_node;
+		fdt_strerror;
+		fdt_offset_ptr;
+		fdt_next_tag;
+
+	local:
+		*;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoL-0006Bu-EY; Mon, 13 Feb 2012 13:19:17 +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 1RwvoJ-0006B4-Po
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1108 invoked from network); 13 Feb 2012 13:18:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892166"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:00 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIuj9024703;
	Mon, 13 Feb 2012 05:18:59 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 13:18:45 +0000
Message-ID: <1329139131-27554-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] libfdt: fixup libfdt_env.h for xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/libfdt/libfdt_env.h |   27 ++++++++++-----------------
 xen/include/xen/types.h        |    2 ++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
index 449bf60..8c0c030 100644
--- a/xen/common/libfdt/libfdt_env.h
+++ b/xen/common/libfdt/libfdt_env.h
@@ -1,23 +1,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <stdint.h>
-#include <string.h>
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <asm/byteorder.h>
 
-#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
-static inline uint32_t fdt32_to_cpu(uint32_t x)
-{
-	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
-}
-#define cpu_to_fdt32(x) fdt32_to_cpu(x)
-
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
-	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
-		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
-}
-#define cpu_to_fdt64(x) fdt64_to_cpu(x)
-#undef _B
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
 
 #endif /* _LIBFDT_ENV_H */
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index ac96647..8596ded 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -57,4 +57,6 @@ typedef __u32 __be32;
 typedef __u64 __le64;
 typedef __u64 __be64;
 
+typedef unsigned long uintptr_t;
+
 #endif /* __TYPES_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoL-0006Bu-EY; Mon, 13 Feb 2012 13:19:17 +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 1RwvoJ-0006B4-Po
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1108 invoked from network); 13 Feb 2012 13:18:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892166"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:00 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIuj9024703;
	Mon, 13 Feb 2012 05:18:59 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 13 Feb 2012 13:18:45 +0000
Message-ID: <1329139131-27554-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] libfdt: fixup libfdt_env.h for xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/libfdt/libfdt_env.h |   27 ++++++++++-----------------
 xen/include/xen/types.h        |    2 ++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/libfdt/libfdt_env.h b/xen/common/libfdt/libfdt_env.h
index 449bf60..8c0c030 100644
--- a/xen/common/libfdt/libfdt_env.h
+++ b/xen/common/libfdt/libfdt_env.h
@@ -1,23 +1,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <stdint.h>
-#include <string.h>
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/string.h>
+#include <asm/byteorder.h>
 
-#define _B(n)	((unsigned long long)((uint8_t *)&x)[n])
-static inline uint32_t fdt32_to_cpu(uint32_t x)
-{
-	return (_B(0) << 24) | (_B(1) << 16) | (_B(2) << 8) | _B(3);
-}
-#define cpu_to_fdt32(x) fdt32_to_cpu(x)
-
-static inline uint64_t fdt64_to_cpu(uint64_t x)
-{
-	return (_B(0) << 56) | (_B(1) << 48) | (_B(2) << 40) | (_B(3) << 32)
-		| (_B(4) << 24) | (_B(5) << 16) | (_B(6) << 8) | _B(7);
-}
-#define cpu_to_fdt64(x) fdt64_to_cpu(x)
-#undef _B
+#define fdt16_to_cpu(x) be16_to_cpu(x)
+#define cpu_to_fdt16(x) cpu_to_be16(x)
+#define fdt32_to_cpu(x) be32_to_cpu(x)
+#define cpu_to_fdt32(x) cpu_to_be32(x)
+#define fdt64_to_cpu(x) be64_to_cpu(x)
+#define cpu_to_fdt64(x) cpu_to_be64(x)
 
 #endif /* _LIBFDT_ENV_H */
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index ac96647..8596ded 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -57,4 +57,6 @@ typedef __u32 __be32;
 typedef __u64 __le64;
 typedef __u64 __be64;
 
+typedef unsigned long uintptr_t;
+
 #endif /* __TYPES_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoL-0006C7-RL; Mon, 13 Feb 2012 13:19:17 +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 1RwvoK-0006BJ-AD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1142 invoked from network); 13 Feb 2012 13:18:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892171"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:03 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujD024703;
	Mon, 13 Feb 2012 05:19:02 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:49 +0000
Message-ID: <1329139131-27554-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] arm: add early_printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add early_printk() which can be used before setup_pagetables().  This
will be used when doing the early parsing of the DTB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/early_printk.c        |   72 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/early_printk.h |   27 +++++++++++++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/early_printk.c
 create mode 100644 xen/include/asm-arm/early_printk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b4dd3b1..168716e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,6 +1,7 @@
 subdir-y += lib
 
 obj-y += dummy.o
+obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
new file mode 100644
index 0000000..3e51252
--- /dev/null
+++ b/xen/arch/arm/early_printk.c
@@ -0,0 +1,72 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+static void __init early_putch(char c)
+{
+    volatile uint32_t *r;
+
+    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
+                     + XEN_VIRT_START + (1 << 21));
+
+    /* XXX: assuming a PL011 UART. */
+    while(*(r + 0x6) & 0x8)
+        ;
+    *r = c;
+}
+
+static void __init early_puts(const char *s)
+{
+    while (*s != '\0') {
+        if (*s == '\n')
+            early_putch('\r');
+        early_putch(*s);
+        s++;
+    }
+}
+
+static void __init early_vprintk(const char *fmt, va_list args)
+{
+    char buf[80];
+
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    early_puts(buf);
+}
+
+void __init early_printk(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+}
+
+void __attribute__((noreturn)) __init
+early_panic(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+
+    while(1);
+}
+
+#endif /* #ifdef EARLY_UART_ADDRESS */
diff --git a/xen/include/asm-arm/early_printk.h b/xen/include/asm-arm/early_printk.h
new file mode 100644
index 0000000..f45f21e
--- /dev/null
+++ b/xen/include/asm-arm/early_printk.h
@@ -0,0 +1,27 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARM_EARLY_PRINTK_H__
+#define __ARM_EARLY_PRINTK_H__
+
+#include <xen/config.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+void early_printk(const char *fmt, ...);
+void early_panic(const char *fmt, ...);
+
+#else
+
+static inline void early_printk(const char *fmt, ...) {}
+static inline void early_panic(const char *fmt, ...) {}
+
+#endif
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoL-0006C7-RL; Mon, 13 Feb 2012 13:19:17 +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 1RwvoK-0006BJ-AD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:16 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1142 invoked from network); 13 Feb 2012 13:18:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892171"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:03 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujD024703;
	Mon, 13 Feb 2012 05:19:02 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:49 +0000
Message-ID: <1329139131-27554-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] arm: add early_printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Add early_printk() which can be used before setup_pagetables().  This
will be used when doing the early parsing of the DTB.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/Makefile              |    1 +
 xen/arch/arm/early_printk.c        |   72 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/early_printk.h |   27 +++++++++++++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/early_printk.c
 create mode 100644 xen/include/asm-arm/early_printk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b4dd3b1..168716e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,6 +1,7 @@
 subdir-y += lib
 
 obj-y += dummy.o
+obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
 obj-y += domain_build.o
diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
new file mode 100644
index 0000000..3e51252
--- /dev/null
+++ b/xen/arch/arm/early_printk.c
@@ -0,0 +1,72 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+static void __init early_putch(char c)
+{
+    volatile uint32_t *r;
+
+    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
+                     + XEN_VIRT_START + (1 << 21));
+
+    /* XXX: assuming a PL011 UART. */
+    while(*(r + 0x6) & 0x8)
+        ;
+    *r = c;
+}
+
+static void __init early_puts(const char *s)
+{
+    while (*s != '\0') {
+        if (*s == '\n')
+            early_putch('\r');
+        early_putch(*s);
+        s++;
+    }
+}
+
+static void __init early_vprintk(const char *fmt, va_list args)
+{
+    char buf[80];
+
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    early_puts(buf);
+}
+
+void __init early_printk(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+}
+
+void __attribute__((noreturn)) __init
+early_panic(const char *fmt, ...)
+{
+    va_list args;
+
+    va_start(args, fmt);
+    early_vprintk(fmt, args);
+    va_end(args);
+
+    while(1);
+}
+
+#endif /* #ifdef EARLY_UART_ADDRESS */
diff --git a/xen/include/asm-arm/early_printk.h b/xen/include/asm-arm/early_printk.h
new file mode 100644
index 0000000..f45f21e
--- /dev/null
+++ b/xen/include/asm-arm/early_printk.h
@@ -0,0 +1,27 @@
+/*
+ * printk() for use before the final page tables are setup.
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ARM_EARLY_PRINTK_H__
+#define __ARM_EARLY_PRINTK_H__
+
+#include <xen/config.h>
+
+#ifdef EARLY_UART_ADDRESS
+
+void early_printk(const char *fmt, ...);
+void early_panic(const char *fmt, ...);
+
+#else
+
+static inline void early_printk(const char *fmt, ...) {}
+static inline void early_panic(const char *fmt, ...) {}
+
+#endif
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoK-0006BM-2B; Mon, 13 Feb 2012 13:19:16 +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 1RwvoJ-0006Au-5a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1017 invoked from network); 13 Feb 2012 13:18:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892168"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:02 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujB024703;
	Mon, 13 Feb 2012 05:19:01 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:47 +0000
Message-ID: <1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the xen
	image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Link a device tree blob (DTB) into the xen image.  This is loaded
immediately after Xen and xen_start() is called with the correct
address in atag_paddr.

The DTB file must be supplied by setting the CONFIG_DTB_FILE variable
in .config or on the make command line.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 config/arm.mk          |    6 ++++++
 xen/arch/arm/Makefile  |    9 ++++++++-
 xen/arch/arm/dtb.S     |    2 ++
 xen/arch/arm/head.S    |    6 ++++++
 xen/arch/arm/xen.lds.S |    4 ++++
 5 files changed, 26 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/dtb.S

diff --git a/config/arm.mk b/config/arm.mk
index f64f0c1..f20fd2d 100644
--- a/config/arm.mk
+++ b/config/arm.mk
@@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
 LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
 
 CONFIG_LOAD_ADDRESS ?= 0x80000000
+
+# XXX: When running on the model there is no bootloader to provide a
+# device tree.  It must be linked into Xen.
+ifndef CONFIG_DTB_FILE
+$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
+endif
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..b4dd3b1 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -22,12 +22,17 @@ obj-y += vtimer.o
 
 #obj-bin-y += ....o
 
+ifdef CONFIG_DTB_FILE
+obj-y += dtb.o
+AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
+endif
+
 ALL_OBJS := head.o $(ALL_OBJS)
 
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
-	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	# XXX strip it
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
@@ -71,6 +76,8 @@ xen.lds: xen.lds.S
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
+dtb.o: $(CONFIG_DTB_FILE)
+
 .PHONY: clean
 clean::
 	rm -f asm-offsets.s xen.lds
diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
new file mode 100644
index 0000000..c703aef
--- /dev/null
+++ b/xen/arch/arm/dtb.S
@@ -0,0 +1,2 @@
+        .section .dtb,#alloc
+        .incbin CONFIG_DTB_FILE
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 57b990d..ea557c2 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -55,6 +55,12 @@ start:
        adr   r9, start              /* r9  := paddr (start) */
        sub   r10, r9, r0            /* r10 := phys-offset */
 
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   r8, =_sdtb
+        add   r8, r10                /* r8 := paddr(DTB) */
+#endif
+
 #ifdef EARLY_UART_ADDRESS
        /* Say hello */
        ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5a62e2c..6fb7662 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -122,6 +122,10 @@ SECTIONS
   } :text
   _end = . ;
 
+  /* Section for the device tree blob (if any). */
+  _sdtb = .;
+  .dtb : { *(.dtb) } :text
+
   /* Sections to be discarded */
   /DISCARD/ : {
        *(.exit.text)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoK-0006BM-2B; Mon, 13 Feb 2012 13:19:16 +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 1RwvoJ-0006Au-5a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1017 invoked from network); 13 Feb 2012 13:18:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892168"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:02 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujB024703;
	Mon, 13 Feb 2012 05:19:01 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:47 +0000
Message-ID: <1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the xen
	image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Link a device tree blob (DTB) into the xen image.  This is loaded
immediately after Xen and xen_start() is called with the correct
address in atag_paddr.

The DTB file must be supplied by setting the CONFIG_DTB_FILE variable
in .config or on the make command line.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 config/arm.mk          |    6 ++++++
 xen/arch/arm/Makefile  |    9 ++++++++-
 xen/arch/arm/dtb.S     |    2 ++
 xen/arch/arm/head.S    |    6 ++++++
 xen/arch/arm/xen.lds.S |    4 ++++
 5 files changed, 26 insertions(+), 1 deletions(-)
 create mode 100644 xen/arch/arm/dtb.S

diff --git a/config/arm.mk b/config/arm.mk
index f64f0c1..f20fd2d 100644
--- a/config/arm.mk
+++ b/config/arm.mk
@@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
 LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
 
 CONFIG_LOAD_ADDRESS ?= 0x80000000
+
+# XXX: When running on the model there is no bootloader to provide a
+# device tree.  It must be linked into Xen.
+ifndef CONFIG_DTB_FILE
+$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
+endif
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..b4dd3b1 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -22,12 +22,17 @@ obj-y += vtimer.o
 
 #obj-bin-y += ....o
 
+ifdef CONFIG_DTB_FILE
+obj-y += dtb.o
+AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
+endif
+
 ALL_OBJS := head.o $(ALL_OBJS)
 
 $(TARGET): $(TARGET)-syms
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
-	$(OBJCOPY) --change-addresses +0x7fe00000 $< $@
+	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	# XXX strip it
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
@@ -71,6 +76,8 @@ xen.lds: xen.lds.S
 	sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
 	mv -f .xen.lds.d.new .xen.lds.d
 
+dtb.o: $(CONFIG_DTB_FILE)
+
 .PHONY: clean
 clean::
 	rm -f asm-offsets.s xen.lds
diff --git a/xen/arch/arm/dtb.S b/xen/arch/arm/dtb.S
new file mode 100644
index 0000000..c703aef
--- /dev/null
+++ b/xen/arch/arm/dtb.S
@@ -0,0 +1,2 @@
+        .section .dtb,#alloc
+        .incbin CONFIG_DTB_FILE
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 57b990d..ea557c2 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -55,6 +55,12 @@ start:
        adr   r9, start              /* r9  := paddr (start) */
        sub   r10, r9, r0            /* r10 := phys-offset */
 
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   r8, =_sdtb
+        add   r8, r10                /* r8 := paddr(DTB) */
+#endif
+
 #ifdef EARLY_UART_ADDRESS
        /* Say hello */
        ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5a62e2c..6fb7662 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -122,6 +122,10 @@ SECTIONS
   } :text
   _end = . ;
 
+  /* Section for the device tree blob (if any). */
+  _sdtb = .;
+  .dtb : { *(.dtb) } :text
+
   /* Sections to be discarded */
   /DISCARD/ : {
        *(.exit.text)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoO-0006Cz-8N; Mon, 13 Feb 2012 13:19:20 +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 1RwvoN-0006Ac-7a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 948 invoked from network); 13 Feb 2012 13:18:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:18:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:18:57 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DDIuj7024703	for
	<xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 05:18:57 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:43 +0000
Message-ID: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series adds preliminary device tree support to Xen for ARM.

libfdt for parsing a device tree in flattened device tree (fdt) format
and added and used to find the location and size of RAM.  This info is
then used when relocating Xen and setting up the mm and heaps.

Since we don't have a bootloader when using the model the device tree
blob (DTB) is linked into .dtb section of the Xen image.  The
CONFIG_DTB_FILE make variable (set in .config or on the make command
line) gives the name of the DTB file to use.  See the wiki[1] for a
device tree for the model.

This series is also available in the device-tree-v3 branch of
git://xenbits.xen.org/people/dvrabel/xen-unstable.git

Changes since v2:

- use the CONFIG_DTB_FILE variable instead of a hardcoded path for the
  DTB file.

Changes since v1:

- map DTB in head.S using the L2 slot after the fixmap.
- new patch 8 for setting up mm/heaps.

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwvoO-0006Cz-8N; Mon, 13 Feb 2012 13:19:20 +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 1RwvoN-0006Ac-7a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329139080!62614840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 948 invoked from network); 13 Feb 2012 13:18:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:18:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:18:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:18:57 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DDIuj7024703	for
	<xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 05:18:57 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:43 +0000
Message-ID: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series adds preliminary device tree support to Xen for ARM.

libfdt for parsing a device tree in flattened device tree (fdt) format
and added and used to find the location and size of RAM.  This info is
then used when relocating Xen and setting up the mm and heaps.

Since we don't have a bootloader when using the model the device tree
blob (DTB) is linked into .dtb section of the Xen image.  The
CONFIG_DTB_FILE make variable (set in .config or on the make command
line) gives the name of the DTB file to use.  See the wiki[1] for a
device tree for the model.

This series is also available in the device-tree-v3 branch of
git://xenbits.xen.org/people/dvrabel/xen-unstable.git

Changes since v2:

- use the CONFIG_DTB_FILE variable instead of a hardcoded path for the
  DTB file.

Changes since v1:

- map DTB in head.S using the L2 slot after the fixmap.
- new patch 8 for setting up mm/heaps.

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13: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.xensource.com>)
	id 1RwvoQ-0006Ee-L3; Mon, 13 Feb 2012 13:19:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RwvoP-0006BK-BT
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329139153!8492078!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2714 invoked from network); 13 Feb 2012 13:19:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892172"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:05 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujF024703;
	Mon, 13 Feb 2012 05:19:04 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:51 +0000
Message-ID: <1329139131-27554-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] arm: setup MM using information from the
	device tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Setup memory management, heaps etc. using the location and size of the
first memory bank given in the device tree.

The DTB is also copied so it can be used afterwards.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/kernel.c         |   22 +++++----
 xen/arch/arm/mm.c             |    3 +
 xen/arch/arm/setup.c          |   98 +++++++++++++++++++++++++++++++----------
 xen/common/device_tree.c      |    7 +++-
 xen/include/asm-arm/mm.h      |   11 +++--
 xen/include/asm-arm/setup.h   |    2 +
 xen/include/xen/device_tree.h |    3 +-
 7 files changed, 107 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d4ffa4f..f2339fa 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -11,6 +11,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/byteorder.h>
+#include <asm/setup.h>
 
 #include "kernel.h"
 
@@ -32,25 +33,28 @@ struct minimal_dtb_header {
 
 #define DTB_MAGIC 0xd00dfeed
 
-static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+/**
+ * copy_from_paddr - copy data from a physical address
+ * @dst: destination virtual address
+ * @paddr: source physical address
+ * @len: length to copy
+ */
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
-    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
-           len, flash, dst);
-
     while (len) {
         paddr_t p;
         unsigned long l, s;
 
-        p = flash >> PAGE_SHIFT;
-        s = flash & (PAGE_SIZE-1);
+        p = paddr >> PAGE_SHIFT;
+        s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
         set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
         memcpy(dst, src + s, l);
 
-        flash += l;
+        paddr += l;
         dst += l;
         len -= l;
     }
@@ -108,7 +112,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -150,7 +154,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 24f977c..0d6c0ca 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,7 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
 
+unsigned long frametable_base_mfn;
 unsigned long frametable_virt_end;
 
 /* Map a 4k page in a fixmap entry */
@@ -301,6 +302,8 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     unsigned long frametable_size = nr_pages * sizeof(struct page_info);
     unsigned long base_mfn;
 
+    frametable_base_mfn = ps >> PAGE_SHIFT;
+
     /* Round up to 32M boundary */
     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
     base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 01d2668..de7d5f2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,17 +64,90 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+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;
+    unsigned long ram_pages;
+    unsigned long heap_pages, xenheap_pages, domheap_pages;
+    unsigned long dtb_pages;
+    unsigned long boot_mfn_start, boot_mfn_end;
+
+    /*
+     * TODO: only using the first RAM bank for now.  The heaps and the
+     * frame table assume RAM is physically contiguous.
+     */
+    ram_start = early_info.mem.bank[0].start;
+    ram_size  = early_info.mem.bank[0].size;
+    ram_end = ram_start + ram_size;
+    ram_pages = ram_size >> PAGE_SHIFT;
+
+    /*
+     * Calculate the sizes for the heaps using these constraints:
+     *
+     *  - heaps must be 32 MiB aligned
+     *  - must not include Xen itself
+     *  - xen heap must be at most 1 GiB
+     *
+     * XXX: needs a platform with at least 1GiB of RAM or the dom
+     * heap will be empty and no domains can be created.
+     */
+    heap_pages = (ram_size >> PAGE_SHIFT) - (32 << (20 - PAGE_SHIFT));
+    xenheap_pages = min(1ul << (30 - PAGE_SHIFT), heap_pages);
+    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);
+
+    /*
+     * Need a single mapped page for populating bootmem_region_list
+     * and enough mapped pages for copying the DTB.
+     *
+     * TODO: The DTB (and other payloads) are assumed to be towards
+     * the start of RAM.
+     */
+    dtb_pages = (dtb_size + PAGE_SIZE-1) >> PAGE_SHIFT;
+    boot_mfn_start = xenheap_mfn_end - dtb_pages - 1;
+    boot_mfn_end = xenheap_mfn_end;
+
+    init_boot_pages(pfn_to_paddr(boot_mfn_start), pfn_to_paddr(boot_mfn_end));
+
+    /*
+     * Copy the DTB.
+     *
+     * TODO: handle other payloads too.
+     */
+    device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+
+    /* 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));
+
+    setup_frametable_mappings(ram_start, ram_end);
+
+    /* Add xenheap memory that was not already added to the boot
+       allocator. */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
+                       pfn_to_paddr(boot_mfn_start));
+
+    end_boot_allocator();
+}
+
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
                       unsigned long atag_paddr)
 
 {
     void *fdt;
+    size_t fdt_size;
     int i;
 
     fdt = (void *)BOOT_MISC_VIRT_START
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
-    device_tree_early_init(fdt);
+    fdt_size = device_tree_early_init(fdt);
 
     setup_pagetables(boot_phys_offset);
 
@@ -98,28 +171,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     init_xen_time();
 
-    /* TODO: This needs some thought, as well as device-tree mapping.
-     * For testing, assume that the whole xenheap is contiguous in RAM */
-    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
-    /* Must pass a single mapped page for populating bootmem_region_list. */
-    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
-                    pfn_to_paddr(xenheap_mfn_start+1));
-
-    /* Add non-xenheap memory */
-    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
-
-    /* TODO Make sure Xen's own pages aren't added
-     *     -- the memory above doesn't include our relocation target.  */
-    /* TODO Handle payloads too */
-
-    /* TODO Need to find actual memory, for now use 4GB at 512GB */
-    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
-
-    /* Add xenheap memory */
-    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
-                       pfn_to_paddr(xenheap_mfn_end));
-
-    end_boot_allocator();
+    setup_mm(atag_paddr, fdt_size);
 
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 7d7514d..d50cb9c 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -22,6 +22,7 @@
 #include <libfdt.h>
 
 struct dt_early_info __initdata early_info;
+void *device_tree_flattened;
 
 static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
@@ -126,8 +127,10 @@ static void __init early_print_info(void)
 /**
  * device_tree_early_init - initialize early info from a DTB
  * @fdt: flattened device tree binary
+ *
+ * Returns the size of the DTB.
  */
-void __init device_tree_early_init(const void *fdt)
+size_t __init device_tree_early_init(const void *fdt)
 {
     int ret;
 
@@ -137,6 +140,8 @@ void __init device_tree_early_init(const void *fdt)
 
     early_scan(fdt);
     early_print_info();
+
+    return fdt_totalsize(fdt);
 }
 
 /**
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 8efa63b..bfc0f76 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -128,6 +128,8 @@ extern void share_xen_page_with_privileged_guests(
     struct page_info *page, int readonly);
 
 #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+/* MFN of the first page in the frame table. */
+extern unsigned long frametable_base_mfn;
 
 extern unsigned long max_page;
 extern unsigned long total_pages;
@@ -151,15 +153,14 @@ extern void clear_fixmap(unsigned map);
 })
 
 #define max_pdx                 max_page
-/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
-#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
-#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define pfn_to_pdx(pfn)         (pfn)
+#define pdx_to_pfn(pdx)         (pdx)
 #define virt_to_pdx(va)         virt_to_mfn(va)
 #define pdx_to_virt(pdx)        mfn_to_virt(pdx)
 
 /* Convert between machine frame numbers and page-info structures. */
-#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
-#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define mfn_to_page(mfn)  (frame_table + (pfn_to_pdx(mfn) - frametable_base_mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table) + frametable_base_mfn)
 #define __page_to_mfn(pg)  page_to_mfn(pg)
 #define __mfn_to_page(mfn) mfn_to_page(mfn)
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 2041f06..05ff89e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,8 @@
 
 #include <public/version.h>
 
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index ae3e344..28a3dee 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -29,8 +29,9 @@ struct dt_early_info {
 };
 
 extern struct dt_early_info early_info;
+extern void *device_tree_flattened;
 
-void device_tree_early_init(const void *fdt);
+size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13: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.xensource.com>)
	id 1RwvoQ-0006Ee-L3; Mon, 13 Feb 2012 13:19:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RwvoP-0006BK-BT
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329139153!8492078!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2714 invoked from network); 13 Feb 2012 13:19:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 13:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21892172"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:05 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujF024703;
	Mon, 13 Feb 2012 05:19:04 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:51 +0000
Message-ID: <1329139131-27554-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] arm: setup MM using information from the
	device tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Setup memory management, heaps etc. using the location and size of the
first memory bank given in the device tree.

The DTB is also copied so it can be used afterwards.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/kernel.c         |   22 +++++----
 xen/arch/arm/mm.c             |    3 +
 xen/arch/arm/setup.c          |   98 +++++++++++++++++++++++++++++++----------
 xen/common/device_tree.c      |    7 +++-
 xen/include/asm-arm/mm.h      |   11 +++--
 xen/include/asm-arm/setup.h   |    2 +
 xen/include/xen/device_tree.h |    3 +-
 7 files changed, 107 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d4ffa4f..f2339fa 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -11,6 +11,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/byteorder.h>
+#include <asm/setup.h>
 
 #include "kernel.h"
 
@@ -32,25 +33,28 @@ struct minimal_dtb_header {
 
 #define DTB_MAGIC 0xd00dfeed
 
-static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+/**
+ * copy_from_paddr - copy data from a physical address
+ * @dst: destination virtual address
+ * @paddr: source physical address
+ * @len: length to copy
+ */
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
 {
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
 
-    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
-           len, flash, dst);
-
     while (len) {
         paddr_t p;
         unsigned long l, s;
 
-        p = flash >> PAGE_SHIFT;
-        s = flash & (PAGE_SIZE-1);
+        p = paddr >> PAGE_SHIFT;
+        s = paddr & (PAGE_SIZE-1);
         l = min(PAGE_SIZE - s, len);
 
         set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
         memcpy(dst, src + s, l);
 
-        flash += l;
+        paddr += l;
         dst += l;
         len -= l;
     }
@@ -108,7 +112,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     /*
      * Check for an appended DTB.
      */
-    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
     }
@@ -150,7 +154,7 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     if ( info->kernel_img == NULL )
         panic("Cannot allocate temporary buffer for kernel.\n");
 
-    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    copy_from_paddr(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
 
     if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
         return rc;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 24f977c..0d6c0ca 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,7 @@ static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
 
+unsigned long frametable_base_mfn;
 unsigned long frametable_virt_end;
 
 /* Map a 4k page in a fixmap entry */
@@ -301,6 +302,8 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     unsigned long frametable_size = nr_pages * sizeof(struct page_info);
     unsigned long base_mfn;
 
+    frametable_base_mfn = ps >> PAGE_SHIFT;
+
     /* Round up to 32M boundary */
     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
     base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 01d2668..de7d5f2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,17 +64,90 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+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;
+    unsigned long ram_pages;
+    unsigned long heap_pages, xenheap_pages, domheap_pages;
+    unsigned long dtb_pages;
+    unsigned long boot_mfn_start, boot_mfn_end;
+
+    /*
+     * TODO: only using the first RAM bank for now.  The heaps and the
+     * frame table assume RAM is physically contiguous.
+     */
+    ram_start = early_info.mem.bank[0].start;
+    ram_size  = early_info.mem.bank[0].size;
+    ram_end = ram_start + ram_size;
+    ram_pages = ram_size >> PAGE_SHIFT;
+
+    /*
+     * Calculate the sizes for the heaps using these constraints:
+     *
+     *  - heaps must be 32 MiB aligned
+     *  - must not include Xen itself
+     *  - xen heap must be at most 1 GiB
+     *
+     * XXX: needs a platform with at least 1GiB of RAM or the dom
+     * heap will be empty and no domains can be created.
+     */
+    heap_pages = (ram_size >> PAGE_SHIFT) - (32 << (20 - PAGE_SHIFT));
+    xenheap_pages = min(1ul << (30 - PAGE_SHIFT), heap_pages);
+    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);
+
+    /*
+     * Need a single mapped page for populating bootmem_region_list
+     * and enough mapped pages for copying the DTB.
+     *
+     * TODO: The DTB (and other payloads) are assumed to be towards
+     * the start of RAM.
+     */
+    dtb_pages = (dtb_size + PAGE_SIZE-1) >> PAGE_SHIFT;
+    boot_mfn_start = xenheap_mfn_end - dtb_pages - 1;
+    boot_mfn_end = xenheap_mfn_end;
+
+    init_boot_pages(pfn_to_paddr(boot_mfn_start), pfn_to_paddr(boot_mfn_end));
+
+    /*
+     * Copy the DTB.
+     *
+     * TODO: handle other payloads too.
+     */
+    device_tree_flattened = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
+    copy_from_paddr(device_tree_flattened, dtb_paddr, dtb_size);
+
+    /* 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));
+
+    setup_frametable_mappings(ram_start, ram_end);
+
+    /* Add xenheap memory that was not already added to the boot
+       allocator. */
+    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
+                       pfn_to_paddr(boot_mfn_start));
+
+    end_boot_allocator();
+}
+
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
                       unsigned long atag_paddr)
 
 {
     void *fdt;
+    size_t fdt_size;
     int i;
 
     fdt = (void *)BOOT_MISC_VIRT_START
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
-    device_tree_early_init(fdt);
+    fdt_size = device_tree_early_init(fdt);
 
     setup_pagetables(boot_phys_offset);
 
@@ -98,28 +171,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     init_xen_time();
 
-    /* TODO: This needs some thought, as well as device-tree mapping.
-     * For testing, assume that the whole xenheap is contiguous in RAM */
-    setup_xenheap_mappings(0x8000000, 0x40000); /* 1 GB @ 512GB */
-    /* Must pass a single mapped page for populating bootmem_region_list. */
-    init_boot_pages(pfn_to_paddr(xenheap_mfn_start),
-                    pfn_to_paddr(xenheap_mfn_start+1));
-
-    /* Add non-xenheap memory */
-    init_boot_pages(0x8040000000, 0x80c0000000); /* 2 GB @513GB */
-
-    /* TODO Make sure Xen's own pages aren't added
-     *     -- the memory above doesn't include our relocation target.  */
-    /* TODO Handle payloads too */
-
-    /* TODO Need to find actual memory, for now use 4GB at 512GB */
-    setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
-
-    /* Add xenheap memory */
-    init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
-                       pfn_to_paddr(xenheap_mfn_end));
-
-    end_boot_allocator();
+    setup_mm(atag_paddr, fdt_size);
 
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 7d7514d..d50cb9c 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -22,6 +22,7 @@
 #include <libfdt.h>
 
 struct dt_early_info __initdata early_info;
+void *device_tree_flattened;
 
 static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
@@ -126,8 +127,10 @@ static void __init early_print_info(void)
 /**
  * device_tree_early_init - initialize early info from a DTB
  * @fdt: flattened device tree binary
+ *
+ * Returns the size of the DTB.
  */
-void __init device_tree_early_init(const void *fdt)
+size_t __init device_tree_early_init(const void *fdt)
 {
     int ret;
 
@@ -137,6 +140,8 @@ void __init device_tree_early_init(const void *fdt)
 
     early_scan(fdt);
     early_print_info();
+
+    return fdt_totalsize(fdt);
 }
 
 /**
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 8efa63b..bfc0f76 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -128,6 +128,8 @@ extern void share_xen_page_with_privileged_guests(
     struct page_info *page, int readonly);
 
 #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
+/* MFN of the first page in the frame table. */
+extern unsigned long frametable_base_mfn;
 
 extern unsigned long max_page;
 extern unsigned long total_pages;
@@ -151,15 +153,14 @@ extern void clear_fixmap(unsigned map);
 })
 
 #define max_pdx                 max_page
-/* XXX Assume everything in the 40-bit physical alias 0x8000000000 for now */
-#define pfn_to_pdx(pfn)         ((pfn) - 0x8000000UL)
-#define pdx_to_pfn(pdx)         ((pdx) + 0x8000000UL)
+#define pfn_to_pdx(pfn)         (pfn)
+#define pdx_to_pfn(pdx)         (pdx)
 #define virt_to_pdx(va)         virt_to_mfn(va)
 #define pdx_to_virt(pdx)        mfn_to_virt(pdx)
 
 /* Convert between machine frame numbers and page-info structures. */
-#define mfn_to_page(mfn)  (frame_table + pfn_to_pdx(mfn))
-#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table))
+#define mfn_to_page(mfn)  (frame_table + (pfn_to_pdx(mfn) - frametable_base_mfn))
+#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table) + frametable_base_mfn)
 #define __page_to_mfn(pg)  page_to_mfn(pg)
 #define __mfn_to_page(mfn) mfn_to_page(mfn)
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 2041f06..05ff89e 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,8 @@
 
 #include <public/version.h>
 
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+
 void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index ae3e344..28a3dee 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -29,8 +29,9 @@ struct dt_early_info {
 };
 
 extern struct dt_early_info early_info;
+extern void *device_tree_flattened;
 
-void device_tree_early_init(const void *fdt);
+size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwvoj-0006RO-AF; Mon, 13 Feb 2012 13:19:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rwvog-0006Mo-ST
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329139171!13151401!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18574 invoked from network); 13 Feb 2012 13:19:32 -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;
	13 Feb 2012 13:19:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488138"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:04 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujE024703;
	Mon, 13 Feb 2012 05:19:03 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:50 +0000
Message-ID: <1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Prior to setting up the page tables, parse the DTB for the location
and size of RAM.

Use this information to get the physical address to relocate Xen to in
setup_pagetables().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/mm.c             |    3 +-
 xen/arch/arm/setup.c          |    6 ++
 xen/common/Makefile           |    3 +
 xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/mm.h      |    5 +-
 xen/include/xen/device_tree.h |   36 ++++++++
 6 files changed, 228 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/device_tree.c
 create mode 100644 xen/include/xen/device_tree.h

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f1fe4ba..24f977c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -20,6 +20,7 @@
 #include <xen/config.h>
 #include <xen/compile.h>
 #include <xen/types.h>
+#include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
@@ -159,7 +160,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
         write_pte(xen_second + second_linear_offset(dest_va), pte);
     }
 
-    xen_paddr = XEN_PADDR;
+    xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 51afb31..01d2668 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -19,6 +19,7 @@
 
 #include <xen/config.h>
 #include <xen/compile.h>
+#include <xen/device_tree.h>
 #include <xen/domain_page.h>
 #include <xen/types.h>
 #include <xen/string.h>
@@ -68,8 +69,13 @@ void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long atag_paddr)
 
 {
+    void *fdt;
     int i;
 
+    fdt = (void *)BOOT_MISC_VIRT_START
+        + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
+    device_tree_early_init(fdt);
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 4b1e6f2..372b259 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-y += bitmap.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-$(HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
@@ -60,3 +61,5 @@ subdir-$(ia64) += hvm
 
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
+
+CFLAGS += -Ilibfdt
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
new file mode 100644
index 0000000..7d7514d
--- /dev/null
+++ b/xen/common/device_tree.c
@@ -0,0 +1,179 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/device_tree.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#include <libfdt.h>
+
+struct dt_early_info __initdata early_info;
+
+static void __init get_val(const u32 **cell, u32 cells, u64 *val)
+{
+    *val = 0;
+
+    while (cells--) {
+        *val <<= 32;
+        *val |= fdt32_to_cpu(*(*cell)++);
+    }
+}
+
+static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
+                                u64 *start, u64 *size)
+{
+    get_val(cell, address_cells, start);
+    get_val(cell, size_cells, size);
+}
+
+static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if (!prop || prop->len < sizeof(u32))
+        return 0; /* default to 0 */
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+static void __init process_memory_node(const void *fdt, int node,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    size_t reg_cells;
+    int i;
+    int banks;
+    const u32 *cell;
+    paddr_t start, size;
+
+    if (address_cells < 1 || size_cells < 1) {
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if (!prop) {
+        early_printk("fdt: node `%s': missing `reg' property\n",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    reg_cells = address_cells + size_cells;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
+
+    for (i = 0; i < banks && early_info.mem.nr_banks < NR_MEM_BANKS; i++) {
+        get_register(&cell, address_cells, size_cells, &start, &size);
+        early_info.mem.bank[early_info.mem.nr_banks].start = start;
+        early_info.mem.bank[early_info.mem.nr_banks].size = size;
+        early_info.mem.nr_banks++;
+    }
+}
+
+#define MAX_DEPTH 16
+
+static void __init early_scan(const void *fdt)
+{
+    int node;
+    int depth;
+    const char *name;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+
+    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= MAX_DEPTH) {
+            early_printk("fdt: node '%s': nested too deep\n",
+                         fdt_get_name(fdt, node, NULL));
+            continue;
+        }
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        if (strncmp(name, "memory", 6) == 0)
+            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
+    }
+}
+
+static void __init early_print_info(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    int i;
+
+    for (i = 0; i < mi->nr_banks; i++)
+        early_printk("RAM: %016llx - %016llx\n",
+                     mi->bank[i].start, mi->bank[i].start + mi->bank[i].size - 1);
+}
+
+/**
+ * device_tree_early_init - initialize early info from a DTB
+ * @fdt: flattened device tree binary
+ */
+void __init device_tree_early_init(const void *fdt)
+{
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if (ret < 0)
+        early_panic("No valid device tree\n");
+
+    early_scan(fdt);
+    early_print_info();
+}
+
+/**
+ * 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
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..8efa63b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -6,9 +6,8 @@
 #include <asm/page.h>
 #include <public/xen.h>
 
-/* Find a suitable place at the top of memory for Xen to live */
-/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
-#define XEN_PADDR 0x80ffe00000ull
+/* Align Xen to a 2 MiB boundary. */
+#define XEN_PADDR_ALIGN (1 << 21)
 
 /*
  * Per-page-frame information.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
new file mode 100644
index 0000000..ae3e344
--- /dev/null
+++ b/xen/include/xen/device_tree.h
@@ -0,0 +1,36 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __XEN_DEVICE_TREE_H__
+#define __XEN_DEVICE_TREE_H__
+
+#include <xen/types.h>
+
+#define NR_MEM_BANKS 8
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+};
+
+struct dt_mem_info {
+    int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct dt_early_info {
+    struct dt_mem_info mem;
+};
+
+extern struct dt_early_info early_info;
+
+void device_tree_early_init(const void *fdt);
+paddr_t device_tree_get_xen_paddr(void);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:19:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwvoj-0006RO-AF; Mon, 13 Feb 2012 13:19:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rwvog-0006Mo-ST
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:19:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329139171!13151401!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18574 invoked from network); 13 Feb 2012 13:19:32 -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;
	13 Feb 2012 13:19:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181488138"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 08:19:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 08:19:04 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1DDIujE024703;
	Mon, 13 Feb 2012 05:19:03 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 13 Feb 2012 13:18:50 +0000
Message-ID: <1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] arm,
	device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Prior to setting up the page tables, parse the DTB for the location
and size of RAM.

Use this information to get the physical address to relocate Xen to in
setup_pagetables().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/mm.c             |    3 +-
 xen/arch/arm/setup.c          |    6 ++
 xen/common/Makefile           |    3 +
 xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/mm.h      |    5 +-
 xen/include/xen/device_tree.h |   36 ++++++++
 6 files changed, 228 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/device_tree.c
 create mode 100644 xen/include/xen/device_tree.h

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f1fe4ba..24f977c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -20,6 +20,7 @@
 #include <xen/config.h>
 #include <xen/compile.h>
 #include <xen/types.h>
+#include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
@@ -159,7 +160,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
         write_pte(xen_second + second_linear_offset(dest_va), pte);
     }
 
-    xen_paddr = XEN_PADDR;
+    xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 51afb31..01d2668 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -19,6 +19,7 @@
 
 #include <xen/config.h>
 #include <xen/compile.h>
+#include <xen/device_tree.h>
 #include <xen/domain_page.h>
 #include <xen/types.h>
 #include <xen/string.h>
@@ -68,8 +69,13 @@ void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long atag_paddr)
 
 {
+    void *fdt;
     int i;
 
+    fdt = (void *)BOOT_MISC_VIRT_START
+        + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
+    device_tree_early_init(fdt);
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 4b1e6f2..372b259 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-y += bitmap.o
 obj-y += cpu.o
 obj-y += cpupool.o
+obj-$(HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_channel.o
@@ -60,3 +61,5 @@ subdir-$(ia64) += hvm
 
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
+
+CFLAGS += -Ilibfdt
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
new file mode 100644
index 0000000..7d7514d
--- /dev/null
+++ b/xen/common/device_tree.c
@@ -0,0 +1,179 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * 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/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/device_tree.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/stdarg.h>
+#include <xen/string.h>
+#include <asm/early_printk.h>
+
+#include <libfdt.h>
+
+struct dt_early_info __initdata early_info;
+
+static void __init get_val(const u32 **cell, u32 cells, u64 *val)
+{
+    *val = 0;
+
+    while (cells--) {
+        *val <<= 32;
+        *val |= fdt32_to_cpu(*(*cell)++);
+    }
+}
+
+static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
+                                u64 *start, u64 *size)
+{
+    get_val(cell, address_cells, start);
+    get_val(cell, size_cells, size);
+}
+
+static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if (!prop || prop->len < sizeof(u32))
+        return 0; /* default to 0 */
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+static void __init process_memory_node(const void *fdt, int node,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    size_t reg_cells;
+    int i;
+    int banks;
+    const u32 *cell;
+    paddr_t start, size;
+
+    if (address_cells < 1 || size_cells < 1) {
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if (!prop) {
+        early_printk("fdt: node `%s': missing `reg' property\n",
+                     fdt_get_name(fdt, node, NULL));
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    reg_cells = address_cells + size_cells;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
+
+    for (i = 0; i < banks && early_info.mem.nr_banks < NR_MEM_BANKS; i++) {
+        get_register(&cell, address_cells, size_cells, &start, &size);
+        early_info.mem.bank[early_info.mem.nr_banks].start = start;
+        early_info.mem.bank[early_info.mem.nr_banks].size = size;
+        early_info.mem.nr_banks++;
+    }
+}
+
+#define MAX_DEPTH 16
+
+static void __init early_scan(const void *fdt)
+{
+    int node;
+    int depth;
+    const char *name;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+
+    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= MAX_DEPTH) {
+            early_printk("fdt: node '%s': nested too deep\n",
+                         fdt_get_name(fdt, node, NULL));
+            continue;
+        }
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        if (strncmp(name, "memory", 6) == 0)
+            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
+    }
+}
+
+static void __init early_print_info(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    int i;
+
+    for (i = 0; i < mi->nr_banks; i++)
+        early_printk("RAM: %016llx - %016llx\n",
+                     mi->bank[i].start, mi->bank[i].start + mi->bank[i].size - 1);
+}
+
+/**
+ * device_tree_early_init - initialize early info from a DTB
+ * @fdt: flattened device tree binary
+ */
+void __init device_tree_early_init(const void *fdt)
+{
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if (ret < 0)
+        early_panic("No valid device tree\n");
+
+    early_scan(fdt);
+    early_print_info();
+}
+
+/**
+ * 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
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..8efa63b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -6,9 +6,8 @@
 #include <asm/page.h>
 #include <public/xen.h>
 
-/* Find a suitable place at the top of memory for Xen to live */
-/* XXX For now, use the top of the VE's 4GB RAM, at a 40-bit alias */
-#define XEN_PADDR 0x80ffe00000ull
+/* Align Xen to a 2 MiB boundary. */
+#define XEN_PADDR_ALIGN (1 << 21)
 
 /*
  * Per-page-frame information.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
new file mode 100644
index 0000000..ae3e344
--- /dev/null
+++ b/xen/include/xen/device_tree.h
@@ -0,0 +1,36 @@
+/*
+ * Device Tree
+ *
+ * Copyright (C) 2012 Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __XEN_DEVICE_TREE_H__
+#define __XEN_DEVICE_TREE_H__
+
+#include <xen/types.h>
+
+#define NR_MEM_BANKS 8
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+};
+
+struct dt_mem_info {
+    int nr_banks;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct dt_early_info {
+    struct dt_mem_info mem;
+};
+
+extern struct dt_early_info early_info;
+
+void device_tree_early_init(const void *fdt);
+paddr_t device_tree_get_xen_paddr(void);
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rww45-0000fM-L0; Mon, 13 Feb 2012 13:35:33 +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 1Rww43-0000f9-2G
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:35:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329140058!62617863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31601 invoked from network); 13 Feb 2012 13:34: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;
	13 Feb 2012 13:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10662354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:35:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 13:35:30 +0000
Message-ID: <1329140128.31256.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Mon, 13 Feb 2012 13:35:28 +0000
In-Reply-To: <CB5EBC13.3935F%keir@xen.org>
References: <CB5EBC13.3935F%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:09 +0000, Keir Fraser wrote:
> On 13/02/2012 12:56, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-02-13 at 12:51 +0000, Keir Fraser wrote:
> >> On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
> >> 
> >>> This patch set mainly allows the user to build a seabios or rombios only
> >>> version of hvmloader.
> >>> In addition, when building a seabios only hvmloader, Option ROMs like
> >>> vgabios and etherboot are no longer required, and therefore can be disabled
> >>> from the build. Dependency on the bcc compiler can also be avoided the
> >>> same way.
> >> 
> >> Applied, but I wonder why we still have the rombios support? Could we switch
> >> over to seabios for 4.2 and get rid of the crufty old rombios code entirely?
> > 
> > We still use ROMBIOS with the traditional qemu-xen tree, I think we have
> > to do that for compatibility with existing guests, for the same reason
> > as we need to continue to support that traditional qemu-xen tree.
> 
> So guests that were installed with old qemu need to always boot with old
> qemu?

That's the claim at least WRT guests like Windows where we aren't
confident in the ability to change "motherboard" under its feet.

I think we've basically just taken the conservative decision to put
qemu-xen-traditional+ROMBIOS into "deep freeze" and keep supporting them
due to lack of concrete evidence and because "deep freeze" means (or
should mean) very low effort.

If there were evidence that this kind of BIOS+motherboard upgrade
doesn't make guests unhappy then it's an easy position to undo.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rww45-0000fM-L0; Mon, 13 Feb 2012 13:35:33 +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 1Rww43-0000f9-2G
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:35:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329140058!62617863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31601 invoked from network); 13 Feb 2012 13:34: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;
	13 Feb 2012 13:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10662354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:35:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 13:35:30 +0000
Message-ID: <1329140128.31256.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Mon, 13 Feb 2012 13:35:28 +0000
In-Reply-To: <CB5EBC13.3935F%keir@xen.org>
References: <CB5EBC13.3935F%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Julian Pidancet <julian.pidancet@gmail.com>
Subject: Re: [Xen-devel] [PATCH v3 0/5] hvmloader: Make ROM dependencies
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:09 +0000, Keir Fraser wrote:
> On 13/02/2012 12:56, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-02-13 at 12:51 +0000, Keir Fraser wrote:
> >> On 11/02/2012 20:39, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
> >> 
> >>> This patch set mainly allows the user to build a seabios or rombios only
> >>> version of hvmloader.
> >>> In addition, when building a seabios only hvmloader, Option ROMs like
> >>> vgabios and etherboot are no longer required, and therefore can be disabled
> >>> from the build. Dependency on the bcc compiler can also be avoided the
> >>> same way.
> >> 
> >> Applied, but I wonder why we still have the rombios support? Could we switch
> >> over to seabios for 4.2 and get rid of the crufty old rombios code entirely?
> > 
> > We still use ROMBIOS with the traditional qemu-xen tree, I think we have
> > to do that for compatibility with existing guests, for the same reason
> > as we need to continue to support that traditional qemu-xen tree.
> 
> So guests that were installed with old qemu need to always boot with old
> qemu?

That's the claim at least WRT guests like Windows where we aren't
confident in the ability to change "motherboard" under its feet.

I think we've basically just taken the conservative decision to put
qemu-xen-traditional+ROMBIOS into "deep freeze" and keep supporting them
due to lack of concrete evidence and because "deep freeze" means (or
should mean) very low effort.

If there were evidence that this kind of BIOS+motherboard upgrade
doesn't make guests unhappy then it's an easy position to undo.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:50:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwwIB-0001Bm-F4; Mon, 13 Feb 2012 13:50: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 1RwwIA-0001Bh-GT
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:50:06 +0000
Received: from [85.158.139.83:40192] by server-8.bemta-5.messagelabs.com id
	11/D9-08951-D05193F4; Mon, 13 Feb 2012 13:50:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329141000!14872825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11262 invoked from network); 13 Feb 2012 13:50:00 -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;
	13 Feb 2012 13:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10662722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:49:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 13:49:26 +0000
Message-ID: <1329140965.31256.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 13:49:25 +0000
In-Reply-To: <1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Few missing #define are the cause of a compile failure with
> XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> native compilation).

Have you tried native compilation? I get:
        $ make -C xen
        make: Entering directory `/local/scratch/ianc/devel/xen-unstable/xen'
        make -f Rules.mk _build
        make[1]: Entering directory `/local/scratch/ianc/devel/xen-unstable/xen'
        /local/scratch/ianc/devel/xen-unstable/xen/../Config.mk:45: /local/scratch/ianc/devel/xen-unstable/xen/../config/armv7l.mk: No such file or directory
        Rules.mk:35: /local/scratch/ianc/devel/xen-unstable/xen/arch/armv7l/Rules.mk: No such file or directory
        make[1]: *** No rule to make target `/local/scratch/ianc/devel/xen-unstable/xen/arch/armv7l/Rules.mk'.  Stop.

I presume this is because of:
        $ uname -m
        armv7l

The following fixes it for me and matches what Linux does.

8<---------------------------------------------------------------

>From 810e27651f0f883bab01f55e804fe733b92dd824 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 13 Feb 2012 13:46:53 +0000
Subject: [PATCH] arm: Set XEN_COMPILE_ARCH correctly from "umame -m" on ARM

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Config.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Config.mk b/Config.mk
index e2dc4b9..df34718 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
-                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
+                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
 
-- 
1.7.8.3




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 13:50:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 13:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwwIB-0001Bm-F4; Mon, 13 Feb 2012 13:50: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 1RwwIA-0001Bh-GT
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 13:50:06 +0000
Received: from [85.158.139.83:40192] by server-8.bemta-5.messagelabs.com id
	11/D9-08951-D05193F4; Mon, 13 Feb 2012 13:50:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329141000!14872825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11262 invoked from network); 13 Feb 2012 13:50:00 -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;
	13 Feb 2012 13:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10662722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:49:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 13:49:26 +0000
Message-ID: <1329140965.31256.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 13:49:25 +0000
In-Reply-To: <1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Few missing #define are the cause of a compile failure with
> XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> native compilation).

Have you tried native compilation? I get:
        $ make -C xen
        make: Entering directory `/local/scratch/ianc/devel/xen-unstable/xen'
        make -f Rules.mk _build
        make[1]: Entering directory `/local/scratch/ianc/devel/xen-unstable/xen'
        /local/scratch/ianc/devel/xen-unstable/xen/../Config.mk:45: /local/scratch/ianc/devel/xen-unstable/xen/../config/armv7l.mk: No such file or directory
        Rules.mk:35: /local/scratch/ianc/devel/xen-unstable/xen/arch/armv7l/Rules.mk: No such file or directory
        make[1]: *** No rule to make target `/local/scratch/ianc/devel/xen-unstable/xen/arch/armv7l/Rules.mk'.  Stop.

I presume this is because of:
        $ uname -m
        armv7l

The following fixes it for me and matches what Linux does.

8<---------------------------------------------------------------

>From 810e27651f0f883bab01f55e804fe733b92dd824 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 13 Feb 2012 13:46:53 +0000
Subject: [PATCH] arm: Set XEN_COMPILE_ARCH correctly from "umame -m" on ARM

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Config.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Config.mk b/Config.mk
index e2dc4b9..df34718 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
-                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
+                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
 
-- 
1.7.8.3




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:13:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwweD-0002NU-8D; Mon, 13 Feb 2012 14:12:53 +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 1RwweB-0002N6-VF
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:12:52 +0000
Received: from [85.158.139.83:36209] by server-7.bemta-5.messagelabs.com id
	E9/2B-01252-36A193F4; Mon, 13 Feb 2012 14:12:51 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329142370!14309171!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA4OTE4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28254 invoked from network); 13 Feb 2012 14:12:50 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 14:12:50 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1DECRPk001999;
	Mon, 13 Feb 2012 14:12:32 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1DEC96T021072
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 13 Feb 2012 14:12:09 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q1DEC9rO024516;
	Mon, 13 Feb 2012 14:12:09 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q1DEC8pp024513; Mon, 13 Feb 2012 14:12:08 GMT
Date: Mon, 13 Feb 2012 14:12:08 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329137635.31256.100.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q1DECRPk001999
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:

> On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
>> I get the backtrace below if I try to boot a PV guest running F17 Alpha
>> TC2 in graphical mode. Is this a known problem?
>
> It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
> the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
> got to the bottom of the root cause though.
>
> That occasion was a suspend/resume thing so perhaps not really related
> but it seems fishily similar.
>
> I've not looked at the code recently but it seems that back then I was
> of the opinion that info->update_wanted == 0 must remain true until the
> irq etc was all fully setup, that might be relevant now?

Yes, it does sound fishily similar. I didn't mention that it does work if 
I do a text boot and then switch to a graphical runlevel, so it could be 
somthing happening in the wrong order, such as the framebuffer starting 
before the irq is properly set up.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:13:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:13:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwweD-0002NU-8D; Mon, 13 Feb 2012 14:12:53 +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 1RwweB-0002N6-VF
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:12:52 +0000
Received: from [85.158.139.83:36209] by server-7.bemta-5.messagelabs.com id
	E9/2B-01252-36A193F4; Mon, 13 Feb 2012 14:12:51 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329142370!14309171!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA4OTE4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28254 invoked from network); 13 Feb 2012 14:12:50 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 14:12:50 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1DECRPk001999;
	Mon, 13 Feb 2012 14:12:32 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1DEC96T021072
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 13 Feb 2012 14:12:09 GMT
Received: from algedi.dur.ac.uk (localhost [127.0.0.1])
	by algedi.dur.ac.uk (8.14.4+Sun/8.11.1) with ESMTP id q1DEC9rO024516;
	Mon, 13 Feb 2012 14:12:09 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	q1DEC8pp024513; Mon, 13 Feb 2012 14:12:08 GMT
Date: Mon, 13 Feb 2012 14:12:08 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329137635.31256.100.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q1DECRPk001999
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:

> On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
>> I get the backtrace below if I try to boot a PV guest running F17 Alpha
>> TC2 in graphical mode. Is this a known problem?
>
> It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
> the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
> got to the bottom of the root cause though.
>
> That occasion was a suspend/resume thing so perhaps not really related
> but it seems fishily similar.
>
> I've not looked at the code recently but it seems that back then I was
> of the opinion that info->update_wanted == 0 must remain true until the
> irq etc was all fully setup, that might be relevant now?

Yes, it does sound fishily similar. I didn't mention that it does work if 
I do a text boot and then switch to a graphical runlevel, so it could be 
somthing happening in the wrong order, such as the framebuffer starting 
before the irq is properly set up.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:21:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwwlk-0003Nj-HT; Mon, 13 Feb 2012 14:20:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rwwli-0003NL-6q
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:20:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329142830!4798324!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTg3Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTg3Mjk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2733 invoked from network); 13 Feb 2012 14:20:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 13 Feb 2012 14:20:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329142830; l=6265;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ZZc1KRS4xiszJsym7OJlZyh2Lns=;
	b=Zt891rseTuFhXKS9KoBOi9MpdJ0jiVD1PdpfxHkqsVzymMSBxmXiAaTo1dMlnk4NPge
	OYqEeYb7p4w9hn8Oa3313PBxanz0qOff7gZPlcSugWDj8ts0ggXVFEfanb7KotQnQDUXC
	QkDTBfz6pa4hGN19wcmpp4MSoKYZdElI4/k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7tEHQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-062.pools.arcor-ip.net [84.57.87.62])
	by smtp.strato.de (klopstock mo2) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Z004d2o1DDbPX3 ;
	Mon, 13 Feb 2012 15:20:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2E44A18637; Mon, 13 Feb 2012 15:20:17 +0100 (CET)
Date: Mon, 13 Feb 2012 15:20:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120213142016.GA7108@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F38F5C802000078000727AD@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, Jan Beulich wrote:

> >>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
> > These functions are called for dom0, but not for domU. And as a result
> > arch.nr_vmce_banks remains zero. I assume the guest needs to be
> > initialized in some way as well, and that does not happen?
> 
> Below/attached a fixed version of the patch.

I get some mismatch after migration, both hosts run the same xen binary.
The small debug patch I use is attached.


Also: The tools do not catch the restore error so that the guest continues to
run on the source host.

Olaf

nicolai login: (XEN) vmce_init_vcpu 0 o 0 n 806
(XEN) vmce_init_vcpu 1 o 0 n 806
(XEN) vmce_init_vcpu 2 o 0 n 806
(XEN) vmce_init_vcpu 3 o 0 n 806
(XEN) save.c:62:d0 HVM restore (1): VM saved on one CPU (0x206c2) and restored on another (0x10676).
(XEN) save.c:234:d0 HVM restore: CPU 0
(XEN) save.c:234:d0 HVM restore: CPU 1
(XEN) save.c:234:d0 HVM restore: CPU 2
(XEN) save.c:234:d0 HVM restore: CPU 3
(XEN) save.c:234:d0 HVM restore: PIC 0
(XEN) save.c:234:d0 HVM restore: PIC 1
(XEN) save.c:234:d0 HVM restore: IOAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 1
(XEN) save.c:234:d0 HVM restore: LAPIC 2
(XEN) save.c:234:d0 HVM restore: LAPIC 3
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
(XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
(XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
(XEN) save.c:234:d0 HVM restore: PCI_LINK 0
(XEN) save.c:234:d0 HVM restore: PIT 0
(XEN) save.c:234:d0 HVM restore: RTC 0
(XEN) save.c:234:d0 HVM restore: HPET 0
(XEN) save.c:234:d0 HVM restore: PMTIMER 0
(XEN) save.c:234:d0 HVM restore: MTRR 0
(XEN) save.c:234:d0 HVM restore: MTRR 1
(XEN) save.c:234:d0 HVM restore: MTRR 2
(XEN) save.c:234:d0 HVM restore: MTRR 3
(XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
(XEN) save.c:291:d0 HVM restore mismatch: expected type 18 length 8, saw type 18 length 1
(XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff82c4802c7d28 ffffffff -1 o 806 n ea
(XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
(XEN) vmce_init_vcpu 0 o 0 n 806
(XEN) vmce_init_vcpu 1 o 0 n 806
(XEN) vmce_init_vcpu 2 o 0 n 806
(XEN) vmce_init_vcpu 3 o 0 n 806
(XEN) save.c:62:d0 HVM restore (2): VM saved on one CPU (0x206c2) and restored on another (0x10676).
(XEN) save.c:234:d0 HVM restore: CPU 0
(XEN) save.c:234:d0 HVM restore: CPU 1
(XEN) save.c:234:d0 HVM restore: CPU 2
(XEN) save.c:234:d0 HVM restore: CPU 3
(XEN) save.c:234:d0 HVM restore: PIC 0
(XEN) save.c:234:d0 HVM restore: PIC 1
(XEN) save.c:234:d0 HVM restore: IOAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 1
(XEN) save.c:234:d0 HVM restore: LAPIC 2
(XEN) save.c:234:d0 HVM restore: LAPIC 3
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
(XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
(XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
(XEN) save.c:234:d0 HVM restore: PCI_LINK 0
(XEN) save.c:234:d0 HVM restore: PIT 0
(XEN) save.c:234:d0 HVM restore: RTC 0
(XEN) save.c:234:d0 HVM restore: HPET 0
(XEN) save.c:234:d0 HVM restore: PMTIMER 0
(XEN) save.c:234:d0 HVM restore: MTRR 0
(XEN) save.c:234:d0 HVM restore: MTRR 1
(XEN) save.c:234:d0 HVM restore: MTRR 2
(XEN) save.c:234:d0 HVM restore: MTRR 3
(XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
(XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
(XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 (supported: 0x800)
(XEN) save.c:239:d0 HVM restore: failed to load entry 18/0



diff -r cbb1cce5fac0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -743,6 +743,7 @@ int mca_cap_init(void)
     {
         int i;
 
+        printk("%s: nr_mce_banks %x\n", __func__, nr_mce_banks);
         mca_allbanks = mcabanks_alloc();
         for ( i = 0; i < nr_mce_banks; i++)
             mcabanks_set(i, mca_allbanks);
diff -r cbb1cce5fac0 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -63,6 +63,7 @@ void vmce_destroy_msr(struct domain *d)
 
 void vmce_init_vcpu(struct vcpu *v)
 {
+    printk("%s %u o %lx n %lx\n", __func__, v->vcpu_id, v->arch.mcg_cap, g_mcg_cap);
     v->arch.mcg_cap = g_mcg_cap;
 }
 
@@ -331,6 +332,7 @@ static int vmce_save_vcpu_ctxt(struct do
         };
 
         err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        gdprintk(XENLOG_ERR, "%s %p %u %x %d o %lx\n", __func__, h, v->vcpu_id, err, err, ctxt.caps);
         if ( err )
             break;
     }
@@ -352,8 +354,11 @@ static int vmce_load_vcpu_ctxt(struct do
         err = -EINVAL;
     }
     else
+    {
         err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
 
+    gdprintk(XENLOG_ERR, "%s %p %x %d o %lx n %lx\n", __func__, h, err, err, v->arch.mcg_cap, ctxt.caps);
+    }
     return err ?: vmce_restore_vcpu(v, ctxt.caps);
 }
 
diff -r cbb1cce5fac0 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,6 +1027,7 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    = 0;
                 evc->syscall32_disables_events = 0;
             }
+            gdprintk(XENLOG_ERR, "%s %u n %lx o %lx\n", __func__, v->vcpu_id, v->arch.mcg_cap, evc->mcg_cap);
             evc->mcg_cap = v->arch.mcg_cap;
         }
         else
@@ -1061,6 +1062,7 @@ long arch_do_domctl(
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
 
+            gdprintk(XENLOG_ERR, "%s %u n %lx o %lx\n", __func__, v->vcpu_id, v->arch.mcg_cap, evc->mcg_cap);
             if ( evc->size >= offsetof(typeof(*evc), mcg_cap) +
                               sizeof(evc->mcg_cap) )
                 ret = vmce_restore_vcpu(v, evc->mcg_cap);
diff -r cbb1cce5fac0 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3129,6 +3129,8 @@ void do_general_protection(struct cpu_us
     {
         dprintk(XENLOG_INFO, "GPF (%04x): %p -> %p\n",
                 regs->error_code, _p(regs->eip), _p(fixup));
+ printk ("%s: %p ", __func__, _p(regs->eip)); print_symbol("%s\n", regs->eip);
+ printk ("%s: %p ", __func__, _p(fixup)); print_symbol("%s\n", fixup);
         regs->eip = fixup;
         return;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:21:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwwlk-0003Nj-HT; Mon, 13 Feb 2012 14:20:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rwwli-0003NL-6q
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:20:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329142830!4798324!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTg3Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTg3Mjk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2733 invoked from network); 13 Feb 2012 14:20:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 13 Feb 2012 14:20:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329142830; l=6265;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ZZc1KRS4xiszJsym7OJlZyh2Lns=;
	b=Zt891rseTuFhXKS9KoBOi9MpdJ0jiVD1PdpfxHkqsVzymMSBxmXiAaTo1dMlnk4NPge
	OYqEeYb7p4w9hn8Oa3313PBxanz0qOff7gZPlcSugWDj8ts0ggXVFEfanb7KotQnQDUXC
	QkDTBfz6pa4hGN19wcmpp4MSoKYZdElI4/k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7tEHQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-062.pools.arcor-ip.net [84.57.87.62])
	by smtp.strato.de (klopstock mo2) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Z004d2o1DDbPX3 ;
	Mon, 13 Feb 2012 15:20:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2E44A18637; Mon, 13 Feb 2012 15:20:17 +0100 (CET)
Date: Mon, 13 Feb 2012 15:20:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120213142016.GA7108@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F38F5C802000078000727AD@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, Jan Beulich wrote:

> >>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
> > These functions are called for dom0, but not for domU. And as a result
> > arch.nr_vmce_banks remains zero. I assume the guest needs to be
> > initialized in some way as well, and that does not happen?
> 
> Below/attached a fixed version of the patch.

I get some mismatch after migration, both hosts run the same xen binary.
The small debug patch I use is attached.


Also: The tools do not catch the restore error so that the guest continues to
run on the source host.

Olaf

nicolai login: (XEN) vmce_init_vcpu 0 o 0 n 806
(XEN) vmce_init_vcpu 1 o 0 n 806
(XEN) vmce_init_vcpu 2 o 0 n 806
(XEN) vmce_init_vcpu 3 o 0 n 806
(XEN) save.c:62:d0 HVM restore (1): VM saved on one CPU (0x206c2) and restored on another (0x10676).
(XEN) save.c:234:d0 HVM restore: CPU 0
(XEN) save.c:234:d0 HVM restore: CPU 1
(XEN) save.c:234:d0 HVM restore: CPU 2
(XEN) save.c:234:d0 HVM restore: CPU 3
(XEN) save.c:234:d0 HVM restore: PIC 0
(XEN) save.c:234:d0 HVM restore: PIC 1
(XEN) save.c:234:d0 HVM restore: IOAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 1
(XEN) save.c:234:d0 HVM restore: LAPIC 2
(XEN) save.c:234:d0 HVM restore: LAPIC 3
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
(XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
(XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
(XEN) save.c:234:d0 HVM restore: PCI_LINK 0
(XEN) save.c:234:d0 HVM restore: PIT 0
(XEN) save.c:234:d0 HVM restore: RTC 0
(XEN) save.c:234:d0 HVM restore: HPET 0
(XEN) save.c:234:d0 HVM restore: PMTIMER 0
(XEN) save.c:234:d0 HVM restore: MTRR 0
(XEN) save.c:234:d0 HVM restore: MTRR 1
(XEN) save.c:234:d0 HVM restore: MTRR 2
(XEN) save.c:234:d0 HVM restore: MTRR 3
(XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
(XEN) save.c:291:d0 HVM restore mismatch: expected type 18 length 8, saw type 18 length 1
(XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff82c4802c7d28 ffffffff -1 o 806 n ea
(XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
(XEN) vmce_init_vcpu 0 o 0 n 806
(XEN) vmce_init_vcpu 1 o 0 n 806
(XEN) vmce_init_vcpu 2 o 0 n 806
(XEN) vmce_init_vcpu 3 o 0 n 806
(XEN) save.c:62:d0 HVM restore (2): VM saved on one CPU (0x206c2) and restored on another (0x10676).
(XEN) save.c:234:d0 HVM restore: CPU 0
(XEN) save.c:234:d0 HVM restore: CPU 1
(XEN) save.c:234:d0 HVM restore: CPU 2
(XEN) save.c:234:d0 HVM restore: CPU 3
(XEN) save.c:234:d0 HVM restore: PIC 0
(XEN) save.c:234:d0 HVM restore: PIC 1
(XEN) save.c:234:d0 HVM restore: IOAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 0
(XEN) save.c:234:d0 HVM restore: LAPIC 1
(XEN) save.c:234:d0 HVM restore: LAPIC 2
(XEN) save.c:234:d0 HVM restore: LAPIC 3
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
(XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
(XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
(XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
(XEN) save.c:234:d0 HVM restore: PCI_LINK 0
(XEN) save.c:234:d0 HVM restore: PIT 0
(XEN) save.c:234:d0 HVM restore: RTC 0
(XEN) save.c:234:d0 HVM restore: HPET 0
(XEN) save.c:234:d0 HVM restore: PMTIMER 0
(XEN) save.c:234:d0 HVM restore: MTRR 0
(XEN) save.c:234:d0 HVM restore: MTRR 1
(XEN) save.c:234:d0 HVM restore: MTRR 2
(XEN) save.c:234:d0 HVM restore: MTRR 3
(XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
(XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
(XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 (supported: 0x800)
(XEN) save.c:239:d0 HVM restore: failed to load entry 18/0



diff -r cbb1cce5fac0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -743,6 +743,7 @@ int mca_cap_init(void)
     {
         int i;
 
+        printk("%s: nr_mce_banks %x\n", __func__, nr_mce_banks);
         mca_allbanks = mcabanks_alloc();
         for ( i = 0; i < nr_mce_banks; i++)
             mcabanks_set(i, mca_allbanks);
diff -r cbb1cce5fac0 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -63,6 +63,7 @@ void vmce_destroy_msr(struct domain *d)
 
 void vmce_init_vcpu(struct vcpu *v)
 {
+    printk("%s %u o %lx n %lx\n", __func__, v->vcpu_id, v->arch.mcg_cap, g_mcg_cap);
     v->arch.mcg_cap = g_mcg_cap;
 }
 
@@ -331,6 +332,7 @@ static int vmce_save_vcpu_ctxt(struct do
         };
 
         err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        gdprintk(XENLOG_ERR, "%s %p %u %x %d o %lx\n", __func__, h, v->vcpu_id, err, err, ctxt.caps);
         if ( err )
             break;
     }
@@ -352,8 +354,11 @@ static int vmce_load_vcpu_ctxt(struct do
         err = -EINVAL;
     }
     else
+    {
         err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
 
+    gdprintk(XENLOG_ERR, "%s %p %x %d o %lx n %lx\n", __func__, h, err, err, v->arch.mcg_cap, ctxt.caps);
+    }
     return err ?: vmce_restore_vcpu(v, ctxt.caps);
 }
 
diff -r cbb1cce5fac0 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,6 +1027,7 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    = 0;
                 evc->syscall32_disables_events = 0;
             }
+            gdprintk(XENLOG_ERR, "%s %u n %lx o %lx\n", __func__, v->vcpu_id, v->arch.mcg_cap, evc->mcg_cap);
             evc->mcg_cap = v->arch.mcg_cap;
         }
         else
@@ -1061,6 +1062,7 @@ long arch_do_domctl(
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
 
+            gdprintk(XENLOG_ERR, "%s %u n %lx o %lx\n", __func__, v->vcpu_id, v->arch.mcg_cap, evc->mcg_cap);
             if ( evc->size >= offsetof(typeof(*evc), mcg_cap) +
                               sizeof(evc->mcg_cap) )
                 ret = vmce_restore_vcpu(v, evc->mcg_cap);
diff -r cbb1cce5fac0 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3129,6 +3129,8 @@ void do_general_protection(struct cpu_us
     {
         dprintk(XENLOG_INFO, "GPF (%04x): %p -> %p\n",
                 regs->error_code, _p(regs->eip), _p(fixup));
+ printk ("%s: %p ", __func__, _p(regs->eip)); print_symbol("%s\n", regs->eip);
+ printk ("%s: %p ", __func__, _p(fixup)); print_symbol("%s\n", fixup);
         regs->eip = fixup;
         return;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:27:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwwro-0003iG-I6; Mon, 13 Feb 2012 14:26:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rwwrn-0003i7-2s
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:26:55 +0000
Received: from [85.158.139.83:22065] by server-7.bemta-5.messagelabs.com id
	0D/90-01252-EAD193F4; Mon, 13 Feb 2012 14:26:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329143213!14851713!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17972 invoked from network); 13 Feb 2012 14:26:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 14:26:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10663740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 14:26:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 14:26:53 +0000
Date: Mon, 13 Feb 2012 14:30:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1328911300080-5473881.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202131429550.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
	<alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
	<1328911300080-5473881.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Fantu wrote:
> I have redo...
> 
> Install precise daily build 64 bit with this config:
> ------------------------------------------------------------------------------
> name='PRECISEHVM'

I take you are talking about Ubuntu 12.04?

> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/scd0,raw,hdb,ro,cdrom']
> boot='d'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> stdvga=0
> sdl=0
> ------------------------------------------------------------------------------
> Vnc is working but have refresh heavy lag and and some partial refresh
> problem (I not know good english for explain good), , is near unusable,
> network now seem to be working.
> 
> After I change boot to 'c', vnc same problem.

Try to disable Compiz in the guest and/or set stdvga=1 in the config
file. Does it help?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:27:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwwro-0003iG-I6; Mon, 13 Feb 2012 14:26:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rwwrn-0003i7-2s
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:26:55 +0000
Received: from [85.158.139.83:22065] by server-7.bemta-5.messagelabs.com id
	0D/90-01252-EAD193F4; Mon, 13 Feb 2012 14:26:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329143213!14851713!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17972 invoked from network); 13 Feb 2012 14:26:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 14:26:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10663740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 14:26:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 14:26:53 +0000
Date: Mon, 13 Feb 2012 14:30:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1328911300080-5473881.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202131429550.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
	<alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
	<1328911300080-5473881.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 10 Feb 2012, Fantu wrote:
> I have redo...
> 
> Install precise daily build 64 bit with this config:
> ------------------------------------------------------------------------------
> name='PRECISEHVM'

I take you are talking about Ubuntu 12.04?

> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/scd0,raw,hdb,ro,cdrom']
> boot='d'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> stdvga=0
> sdl=0
> ------------------------------------------------------------------------------
> Vnc is working but have refresh heavy lag and and some partial refresh
> problem (I not know good english for explain good), , is near unusable,
> network now seem to be working.
> 
> After I change boot to 'c', vnc same problem.

Try to disable Compiz in the guest and/or set stdvga=1 in the config
file. Does it help?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:28:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwwsY-0003kg-05; Mon, 13 Feb 2012 14:27:42 +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 1RwwsW-0003kZ-Vw
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:27:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329143187!62628400!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27809 invoked from network); 13 Feb 2012 14:26: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; 13 Feb 2012 14:26: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 024E81BC7;
	Mon, 13 Feb 2012 16:27:38 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 83C6020056; Mon, 13 Feb 2012 16:27:38 +0200 (EET)
Date: Mon, 13 Feb 2012 16:27:38 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120213142738.GE12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208182233.GB12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > Hi,
> > > > > > =

> > > > > > I am wondering how GPU sharing could/should be implemented for =
the Xen Hypervisor.
> > > > > > =

> > > > > > I have come across several papers that explain many possibiliti=
es on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > one would be the best solution for Xen.
> > > > > > =

> > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > Mediated passthrough (Multiplexing the GPU while maintaining th=
e different contexts.)
> > > > > > =

> > > > > > Can you guys give me your idea on the matter?
> > > > > > Please also mention any existing projects you know that are rel=
ated to this problem.
> > > > > =

> > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > remoting. Gallium remoting could also be OK but considering that =
many
> > > > > cards don't have Gallium drivers we would probably end up doing t=
wo
> > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > Gallium->OpenGL in dom0).
> > > > > Mediated passthrough is very card specific so I am afraid you wou=
ld end
> > > > > up writing virtualization specific drivers for all the cards you =
want to
> > > > > support. Not to mention that you might need to access some videoc=
ard
> > > > > interfaces that on Nvidia are not discosed.
> > > > > =

> > > > > I believe that virtualbox already supports OpenGL remoting in a d=
ecent
> > > > > way, so I would start from there, port what they have to Xen, and
> > > > > improve it.
> > > > > =

> > > > =

> > > > I wonder if SPICE already supports OpenGL stuff..
> > > > I think it's at least supposed to be able to support OpenGL.
> > > > =

> > > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/00=
6018.html)
> > >  =

> > > Not yet, but I think that they are working on it. Still very early da=
ys
> > > though.
> > > Also it would only work with HVM guests, while having a proper xen
> > > frontend/backend OpenGL remoting driver pair would work for both.
> > =

> > Yep.
> > =

> > There's also: http://sourceforge.net/projects/vmgl/
> > =

> > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware a=
cceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-b=
ased OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel G=
PUs. "
> > =

> =

> And Chromium might have something related aswell:
> http://chromium.sourceforge.net/doc/index.html
> =


And one more related interesting link:

"VMware's Virtual GPU Driver Is Running Fast":
http://www.phoronix.com/scan.php?page=3Darticle&item=3Dvmware_vmwgfx_g3d&nu=
m=3D1

So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to work pre=
tty nicely these days!
That might be worth a look.. and to get it running with Xen.

I think SPICE is going to use Gallium3D aswell.

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:28:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwwsY-0003kg-05; Mon, 13 Feb 2012 14:27:42 +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 1RwwsW-0003kZ-Vw
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:27:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329143187!62628400!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27809 invoked from network); 13 Feb 2012 14:26: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; 13 Feb 2012 14:26: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 024E81BC7;
	Mon, 13 Feb 2012 16:27:38 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 83C6020056; Mon, 13 Feb 2012 16:27:38 +0200 (EET)
Date: Mon, 13 Feb 2012 16:27:38 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120213142738.GE12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120208182233.GB12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > Hi,
> > > > > > =

> > > > > > I am wondering how GPU sharing could/should be implemented for =
the Xen Hypervisor.
> > > > > > =

> > > > > > I have come across several papers that explain many possibiliti=
es on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > one would be the best solution for Xen.
> > > > > > =

> > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > Mediated passthrough (Multiplexing the GPU while maintaining th=
e different contexts.)
> > > > > > =

> > > > > > Can you guys give me your idea on the matter?
> > > > > > Please also mention any existing projects you know that are rel=
ated to this problem.
> > > > > =

> > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > remoting. Gallium remoting could also be OK but considering that =
many
> > > > > cards don't have Gallium drivers we would probably end up doing t=
wo
> > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > Gallium->OpenGL in dom0).
> > > > > Mediated passthrough is very card specific so I am afraid you wou=
ld end
> > > > > up writing virtualization specific drivers for all the cards you =
want to
> > > > > support. Not to mention that you might need to access some videoc=
ard
> > > > > interfaces that on Nvidia are not discosed.
> > > > > =

> > > > > I believe that virtualbox already supports OpenGL remoting in a d=
ecent
> > > > > way, so I would start from there, port what they have to Xen, and
> > > > > improve it.
> > > > > =

> > > > =

> > > > I wonder if SPICE already supports OpenGL stuff..
> > > > I think it's at least supposed to be able to support OpenGL.
> > > > =

> > > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/00=
6018.html)
> > >  =

> > > Not yet, but I think that they are working on it. Still very early da=
ys
> > > though.
> > > Also it would only work with HVM guests, while having a proper xen
> > > frontend/backend OpenGL remoting driver pair would work for both.
> > =

> > Yep.
> > =

> > There's also: http://sourceforge.net/projects/vmgl/
> > =

> > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware a=
cceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-b=
ased OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel G=
PUs. "
> > =

> =

> And Chromium might have something related aswell:
> http://chromium.sourceforge.net/doc/index.html
> =


And one more related interesting link:

"VMware's Virtual GPU Driver Is Running Fast":
http://www.phoronix.com/scan.php?page=3Darticle&item=3Dvmware_vmwgfx_g3d&nu=
m=3D1

So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to work pre=
tty nicely these days!
That might be worth a look.. and to get it running with Xen.

I think SPICE is going to use Gallium3D aswell.

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:37:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwx1d-00047a-5Y; Mon, 13 Feb 2012 14:37:05 +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 1Rwx1b-00047R-5c
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:37:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329143772!62630924!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8777 invoked from network); 13 Feb 2012 14:36:13 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 14:36: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 DBD362D66;
	Mon, 13 Feb 2012 16:37:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B975220056; Mon, 13 Feb 2012 16:37:00 +0200 (EET)
Date: Mon, 13 Feb 2012 16:37:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120213143700.GF12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<20120213142738.GE12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120213142738.GE12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 04:27:38PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrot=
e:
> > > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > > Hi,
> > > > > > > =

> > > > > > > I am wondering how GPU sharing could/should be implemented fo=
r the Xen Hypervisor.
> > > > > > > =

> > > > > > > I have come across several papers that explain many possibili=
ties on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > > one would be the best solution for Xen.
> > > > > > > =

> > > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > > Mediated passthrough (Multiplexing the GPU while maintaining =
the different contexts.)
> > > > > > > =

> > > > > > > Can you guys give me your idea on the matter?
> > > > > > > Please also mention any existing projects you know that are r=
elated to this problem.
> > > > > > =

> > > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > > remoting. Gallium remoting could also be OK but considering tha=
t many
> > > > > > cards don't have Gallium drivers we would probably end up doing=
 two
> > > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > > Gallium->OpenGL in dom0).
> > > > > > Mediated passthrough is very card specific so I am afraid you w=
ould end
> > > > > > up writing virtualization specific drivers for all the cards yo=
u want to
> > > > > > support. Not to mention that you might need to access some vide=
ocard
> > > > > > interfaces that on Nvidia are not discosed.
> > > > > > =

> > > > > > I believe that virtualbox already supports OpenGL remoting in a=
 decent
> > > > > > way, so I would start from there, port what they have to Xen, a=
nd
> > > > > > improve it.
> > > > > > =

> > > > > =

> > > > > I wonder if SPICE already supports OpenGL stuff..
> > > > > I think it's at least supposed to be able to support OpenGL.
> > > > > =

> > > > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/=
006018.html)
> > > >  =

> > > > Not yet, but I think that they are working on it. Still very early =
days
> > > > though.
> > > > Also it would only work with HVM guests, while having a proper xen
> > > > frontend/backend OpenGL remoting driver pair would work for both.
> > > =

> > > Yep.
> > > =

> > > There's also: http://sourceforge.net/projects/vmgl/
> > > =

> > > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware=
 acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11=
-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel=
 GPUs. "
> > > =

> > =

> > And Chromium might have something related aswell:
> > http://chromium.sourceforge.net/doc/index.html
> > =

> =

> And one more related interesting link:
> =

> "VMware's Virtual GPU Driver Is Running Fast":
> http://www.phoronix.com/scan.php?page=3Darticle&item=3Dvmware_vmwgfx_g3d&=
num=3D1
> =

> So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to work p=
retty nicely these days!
> That might be worth a look.. and to get it running with Xen.
> =

> I think SPICE is going to use Gallium3D aswell.
> =


I thought i'd already stop spamming but here's more relevant links:

"SPICE On KVM/QEMU Works Towards Gallium3D":
http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTA1NTQ

And even more interesting!:

"The Gallium3D Driver That Few Know About / Xen vGallium":
http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DODE2NQ


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:37:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwx1d-00047a-5Y; Mon, 13 Feb 2012 14:37:05 +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 1Rwx1b-00047R-5c
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:37:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329143772!62630924!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8777 invoked from network); 13 Feb 2012 14:36:13 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 14:36: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 DBD362D66;
	Mon, 13 Feb 2012 16:37:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B975220056; Mon, 13 Feb 2012 16:37:00 +0200 (EET)
Date: Mon, 13 Feb 2012 16:37:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120213143700.GF12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<20120213142738.GE12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120213142738.GE12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 04:27:38PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrot=
e:
> > > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > > Hi,
> > > > > > > =

> > > > > > > I am wondering how GPU sharing could/should be implemented fo=
r the Xen Hypervisor.
> > > > > > > =

> > > > > > > I have come across several papers that explain many possibili=
ties on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > > one would be the best solution for Xen.
> > > > > > > =

> > > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > > Mediated passthrough (Multiplexing the GPU while maintaining =
the different contexts.)
> > > > > > > =

> > > > > > > Can you guys give me your idea on the matter?
> > > > > > > Please also mention any existing projects you know that are r=
elated to this problem.
> > > > > > =

> > > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > > remoting. Gallium remoting could also be OK but considering tha=
t many
> > > > > > cards don't have Gallium drivers we would probably end up doing=
 two
> > > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > > Gallium->OpenGL in dom0).
> > > > > > Mediated passthrough is very card specific so I am afraid you w=
ould end
> > > > > > up writing virtualization specific drivers for all the cards yo=
u want to
> > > > > > support. Not to mention that you might need to access some vide=
ocard
> > > > > > interfaces that on Nvidia are not discosed.
> > > > > > =

> > > > > > I believe that virtualbox already supports OpenGL remoting in a=
 decent
> > > > > > way, so I would start from there, port what they have to Xen, a=
nd
> > > > > > improve it.
> > > > > > =

> > > > > =

> > > > > I wonder if SPICE already supports OpenGL stuff..
> > > > > I think it's at least supposed to be able to support OpenGL.
> > > > > =

> > > > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/=
006018.html)
> > > >  =

> > > > Not yet, but I think that they are working on it. Still very early =
days
> > > > though.
> > > > Also it would only work with HVM guests, while having a proper xen
> > > > frontend/backend OpenGL remoting driver pair would work for both.
> > > =

> > > Yep.
> > > =

> > > There's also: http://sourceforge.net/projects/vmgl/
> > > =

> > > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware=
 acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11=
-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel=
 GPUs. "
> > > =

> > =

> > And Chromium might have something related aswell:
> > http://chromium.sourceforge.net/doc/index.html
> > =

> =

> And one more related interesting link:
> =

> "VMware's Virtual GPU Driver Is Running Fast":
> http://www.phoronix.com/scan.php?page=3Darticle&item=3Dvmware_vmwgfx_g3d&=
num=3D1
> =

> So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to work p=
retty nicely these days!
> That might be worth a look.. and to get it running with Xen.
> =

> I think SPICE is going to use Gallium3D aswell.
> =


I thought i'd already stop spamming but here's more relevant links:

"SPICE On KVM/QEMU Works Towards Gallium3D":
http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTA1NTQ

And even more interesting!:

"The Gallium3D Driver That Few Know About / Xen vGallium":
http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DODE2NQ


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwx3b-0004Jo-Qa; Mon, 13 Feb 2012 14:39:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwx3a-0004JJ-Cf
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:39:06 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329143938!14110082!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28957 invoked from network); 13 Feb 2012 14:38:59 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2012 14:38:59 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwx3R-0005hm-JR
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 06:38:57 -0800
Date: Mon, 13 Feb 2012 06:38:57 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329143937594-5479428.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Unable to start Precise domU PV on xen-unstable with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have create PRECISE domU PV on production system with Squeeze, Xen 4.0 and
using xm, the "only problem" is occasional critical on disk:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913760

Copying the domU on test server not start, seem to be malconfiguration of
grub but it isn't (tried grub1 minimal working on production system and its
grub2 full)

Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b

DomU is Precise created today:
http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/

DomU xl configuration files:
--------------------------------------------------
name='PRECISE'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',
'/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader='/usr/bin/pygrub'
--------------------------------------------------

And the full screen log on this attachment: 
http://xen.1045712.n5.nabble.com/file/n5479428/PRECISE.txt PRECISE.txt 

If you need more test and data ask me and I do and post.

Thanks for any reply and sorry for bad english.


--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479428.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwx3b-0004Jo-Qa; Mon, 13 Feb 2012 14:39:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwx3a-0004JJ-Cf
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:39:06 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329143938!14110082!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28957 invoked from network); 13 Feb 2012 14:38:59 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2012 14:38:59 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwx3R-0005hm-JR
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 06:38:57 -0800
Date: Mon, 13 Feb 2012 06:38:57 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329143937594-5479428.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Unable to start Precise domU PV on xen-unstable with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have create PRECISE domU PV on production system with Squeeze, Xen 4.0 and
using xm, the "only problem" is occasional critical on disk:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913760

Copying the domU on test server not start, seem to be malconfiguration of
grub but it isn't (tried grub1 minimal working on production system and its
grub2 full)

Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b

DomU is Precise created today:
http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/

DomU xl configuration files:
--------------------------------------------------
name='PRECISE'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',
'/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader='/usr/bin/pygrub'
--------------------------------------------------

And the full screen log on this attachment: 
http://xen.1045712.n5.nabble.com/file/n5479428/PRECISE.txt PRECISE.txt 

If you need more test and data ask me and I do and post.

Thanks for any reply and sorry for bad english.


--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479428.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:42:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwx60-0004aN-HI; Mon, 13 Feb 2012 14:41:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rwx5z-0004a0-Ra
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:41:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329144089!14676488!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12926 invoked from network); 13 Feb 2012 14:41:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 14:41:29 -0000
Received: by wibhm2 with SMTP id hm2so14934585wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 06:41:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=8hI3VrWh0CLjhGwqK3mLiFHSYA2Wft1T26BomfnU3jc=;
	b=woitVQfo3d0YwrndZQz8ZsCOBfTGqakQvIcTe/wIJOwVz/WC1SynACZ9/31duOzwR4
	9vqrJTq+UBwXyI4n67N/WgaxAIvWPLdXyTTJn2jdIUAkUlF+ehmgErFMV7HT6Hwui7j/
	sGOxeYokjwIo+h4hPmFQp+naLgJHXpj6JPy6A=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr24900974wiy.1.1329144089592; Mon,
	13 Feb 2012 06:41:29 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 13 Feb 2012 06:41:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202131158480.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
	<alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
	<CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
	<alpine.DEB.2.00.1202131158480.7456@kaball-desktop>
Date: Mon, 13 Feb 2012 15:41:29 +0100
X-Google-Sender-Auth: cFSQz0XOLp-zOuu8qfDkBjcXdaY
Message-ID: <CAPLaKK6tBjBOAWgOBUK4hLCvJnhnZLoOu0qN9PRq0-3cw4A+fw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzEzIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIE1vbiwgMTMgRmViIDIwMTIsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
ID4gWWVzLCBncmVhdCBpbXByb3ZlbWVudHMuCj4+ID4gVGhlIG9sZCBxZW11LXhlbiB1c2VzIHRo
cmVhZHMgdG8gc2ltdWxhdGUgYXN5bmMgSU8gc28gaXQgaXMgdmVyeSBzbG93Owo+PiA+IHVwc3Ry
ZWFtIFFFTVUgdXNlcyBMaW51eCBBSU8gYW5kIGlzIG11Y2ggZmFzdGVyLgo+Pgo+PiBUaGF0J3Mg
Z3JlYXQgbmV3cywgc28gcWRpc2sgcGVyZm9ybWFuY2UgaW4gcWVtdS11cHN0cmVhbSBzaG91bGQg
YmUKPj4gc2ltaWxhciB0byBibGt0YXA/Cj4KPiBTbGlnaHRseSBiZXR0ZXIgYWN0dWFsbHksIGZy
b20gbXkgdmVyeSBxdWljayBhbmQgZGlydHkgdGVzdHMuCgpJJ20gc3VyZSBibGt0YXAgaGFkIHNv
bWUgY29udGV4dCBzd2l0Y2hlcyAoZnJvbSBrZXJuZWwgdG8gdXNlcnNwYWNlKQp0aGF0IHFkaXNr
IGRvZXNuJ3QgaGF2ZSwgc2luY2UgaXQncyBhIHB1cmUgdXNlcmxhbmQgaW1wbGVtZW50YXRpb24s
IHNvCml0J3MgcGxhdXNpYmxlIGZvciBpdCB0byBiZSBmYXN0ZXIuCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:42:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwx60-0004aN-HI; Mon, 13 Feb 2012 14:41:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rwx5z-0004a0-Ra
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:41:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329144089!14676488!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12926 invoked from network); 13 Feb 2012 14:41:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 14:41:29 -0000
Received: by wibhm2 with SMTP id hm2so14934585wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 06:41:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=8hI3VrWh0CLjhGwqK3mLiFHSYA2Wft1T26BomfnU3jc=;
	b=woitVQfo3d0YwrndZQz8ZsCOBfTGqakQvIcTe/wIJOwVz/WC1SynACZ9/31duOzwR4
	9vqrJTq+UBwXyI4n67N/WgaxAIvWPLdXyTTJn2jdIUAkUlF+ehmgErFMV7HT6Hwui7j/
	sGOxeYokjwIo+h4hPmFQp+naLgJHXpj6JPy6A=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr24900974wiy.1.1329144089592; Mon,
	13 Feb 2012 06:41:29 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 13 Feb 2012 06:41:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1202131158480.7456@kaball-desktop>
References: <CAPLaKK7AErbZP8TgsUbyDAp6r5emsj1XbiEp7=6jd_kO2qyjKw@mail.gmail.com>
	<alpine.DEB.2.00.1202101550540.7456@kaball-desktop>
	<CAPLaKK7dimHzig_s-_9gmpV5soWe9DhVfNtDFzquFpRg7V2ZhA@mail.gmail.com>
	<alpine.DEB.2.00.1202131158480.7456@kaball-desktop>
Date: Mon, 13 Feb 2012 15:41:29 +0100
X-Google-Sender-Auth: cFSQz0XOLp-zOuu8qfDkBjcXdaY
Message-ID: <CAPLaKK6tBjBOAWgOBUK4hLCvJnhnZLoOu0qN9PRq0-3cw4A+fw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] qemu-xen qdisk performance
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzEzIFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIE1vbiwgMTMgRmViIDIwMTIsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
ID4gWWVzLCBncmVhdCBpbXByb3ZlbWVudHMuCj4+ID4gVGhlIG9sZCBxZW11LXhlbiB1c2VzIHRo
cmVhZHMgdG8gc2ltdWxhdGUgYXN5bmMgSU8gc28gaXQgaXMgdmVyeSBzbG93Owo+PiA+IHVwc3Ry
ZWFtIFFFTVUgdXNlcyBMaW51eCBBSU8gYW5kIGlzIG11Y2ggZmFzdGVyLgo+Pgo+PiBUaGF0J3Mg
Z3JlYXQgbmV3cywgc28gcWRpc2sgcGVyZm9ybWFuY2UgaW4gcWVtdS11cHN0cmVhbSBzaG91bGQg
YmUKPj4gc2ltaWxhciB0byBibGt0YXA/Cj4KPiBTbGlnaHRseSBiZXR0ZXIgYWN0dWFsbHksIGZy
b20gbXkgdmVyeSBxdWljayBhbmQgZGlydHkgdGVzdHMuCgpJJ20gc3VyZSBibGt0YXAgaGFkIHNv
bWUgY29udGV4dCBzd2l0Y2hlcyAoZnJvbSBrZXJuZWwgdG8gdXNlcnNwYWNlKQp0aGF0IHFkaXNr
IGRvZXNuJ3QgaGF2ZSwgc2luY2UgaXQncyBhIHB1cmUgdXNlcmxhbmQgaW1wbGVtZW50YXRpb24s
IHNvCml0J3MgcGxhdXNpYmxlIGZvciBpdCB0byBiZSBmYXN0ZXIuCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:52:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxFs-00056z-KJ; Mon, 13 Feb 2012 14:51: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 1RwxFr-00056r-8V
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:51:47 +0000
Received: from [85.158.139.83:30404] by server-2.bemta-5.messagelabs.com id
	C9/E4-20725-283293F4; Mon, 13 Feb 2012 14:51:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329144705!14867955!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14050 invoked from network); 13 Feb 2012 14:51:46 -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;
	13 Feb 2012 14:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10664392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 14:51:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 14:51:46 +0000
Message-ID: <1329144704.31256.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 14:51:44 +0000
In-Reply-To: <1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Prior to setting up the page tables, parse the DTB for the location
> and size of RAM.
> 
> Use this information to get the physical address to relocate Xen to in
> setup_pagetables().
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>
> ---
[...]
>  xen/common/Makefile           |    3 +
>  xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
[...]
>  xen/include/xen/device_tree.h |   36 ++++++++

I'd have preferred these non-ARM bits in a separate patch if possible.
I'm going to commit them anyway though on the basis that they are in
reality ARM specific unless Keir (or someone else) objects quite soon.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:52:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxFs-00056z-KJ; Mon, 13 Feb 2012 14:51: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 1RwxFr-00056r-8V
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:51:47 +0000
Received: from [85.158.139.83:30404] by server-2.bemta-5.messagelabs.com id
	C9/E4-20725-283293F4; Mon, 13 Feb 2012 14:51:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329144705!14867955!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14050 invoked from network); 13 Feb 2012 14:51:46 -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;
	13 Feb 2012 14:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10664392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 14:51:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 14:51:46 +0000
Message-ID: <1329144704.31256.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 14:51:44 +0000
In-Reply-To: <1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Prior to setting up the page tables, parse the DTB for the location
> and size of RAM.
> 
> Use this information to get the physical address to relocate Xen to in
> setup_pagetables().
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>
> ---
[...]
>  xen/common/Makefile           |    3 +
>  xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
[...]
>  xen/include/xen/device_tree.h |   36 ++++++++

I'd have preferred these non-ARM bits in a separate patch if possible.
I'm going to commit them anyway though on the basis that they are in
reality ARM specific unless Keir (or someone else) objects quite soon.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:53:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:53:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxHM-0005D8-3S; Mon, 13 Feb 2012 14:53:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RwxHK-0005Cf-Qx
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:53:19 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329144792!13160631!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30132 invoked from network); 13 Feb 2012 14:53:12 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 14:53:12 -0000
Received: from p5b2e44ca.dip.t-dialin.net ([91.46.68.202] 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 1RwxHD-0001Wy-Q6; Mon, 13 Feb 2012 14:53:11 +0000
Message-ID: <4F3923D6.2000502@canonical.com>
Date: Mon, 13 Feb 2012 15:53:10 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Fantu <fantonifabio@tiscali.it>
References: <1329143937594-5479428.post@n5.nabble.com>
In-Reply-To: <1329143937594-5479428.post@n5.nabble.com>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
 with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.02.2012 15:38, Fantu wrote:
> I have create PRECISE domU PV on production system with Squeeze, Xen 4.0 and
> using xm, the "only problem" is occasional critical on disk:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913760
> 

As I tried to you in that bug, the problem is likely the code used in the host
(Debian/Xen 4.0). It will offer the barrier method to do syncs and there has
been a problem with empty barrier requests which also has a fix

# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

But that needs to be applied to the dom0.

> Copying the domU on test server not start, seem to be malconfiguration of
> grub but it isn't (tried grub1 minimal working on production system and its
> grub2 full)
> 
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b
> 
> DomU is Precise created today:
> http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/
> 
> DomU xl configuration files:
> --------------------------------------------------
> name='PRECISE'
> memory=1024
> vcpus=2
> disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',
> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
> vif=['bridge=xenbr0']
> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> bootloader='/usr/bin/pygrub'
> --------------------------------------------------
> 
> And the full screen log on this attachment: 
> http://xen.1045712.n5.nabble.com/file/n5479428/PRECISE.txt PRECISE.txt 
>

You boot looks like it does not find any filesystem (or at least no uuid in
xvda1. Have you checked the disk image with blkid?

-Stefan

> If you need more test and data ask me and I do and post.
> 
> Thanks for any reply and sorry for bad english.
> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479428.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:53:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:53:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxHM-0005D8-3S; Mon, 13 Feb 2012 14:53:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RwxHK-0005Cf-Qx
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:53:19 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329144792!13160631!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30132 invoked from network); 13 Feb 2012 14:53:12 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 14:53:12 -0000
Received: from p5b2e44ca.dip.t-dialin.net ([91.46.68.202] 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 1RwxHD-0001Wy-Q6; Mon, 13 Feb 2012 14:53:11 +0000
Message-ID: <4F3923D6.2000502@canonical.com>
Date: Mon, 13 Feb 2012 15:53:10 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Fantu <fantonifabio@tiscali.it>
References: <1329143937594-5479428.post@n5.nabble.com>
In-Reply-To: <1329143937594-5479428.post@n5.nabble.com>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
 with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.02.2012 15:38, Fantu wrote:
> I have create PRECISE domU PV on production system with Squeeze, Xen 4.0 and
> using xm, the "only problem" is occasional critical on disk:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913760
> 

As I tried to you in that bug, the problem is likely the code used in the host
(Debian/Xen 4.0). It will offer the barrier method to do syncs and there has
been a problem with empty barrier requests which also has a fix

# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

But that needs to be applied to the dom0.

> Copying the domU on test server not start, seem to be malconfiguration of
> grub but it isn't (tried grub1 minimal working on production system and its
> grub2 full)
> 
> Dom0 is Squeeze 6.0.4 64 bit with kernel 2.6.32-5-xen-amd64 version
> 2.6.32-41, xen from xen-unstable.hg changeset 24709:8ba7ae0b070b
> 
> DomU is Precise created today:
> http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/
> 
> DomU xl configuration files:
> --------------------------------------------------
> name='PRECISE'
> memory=1024
> vcpus=2
> disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',
> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
> vif=['bridge=xenbr0']
> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> bootloader='/usr/bin/pygrub'
> --------------------------------------------------
> 
> And the full screen log on this attachment: 
> http://xen.1045712.n5.nabble.com/file/n5479428/PRECISE.txt PRECISE.txt 
>

You boot looks like it does not find any filesystem (or at least no uuid in
xvda1. Have you checked the disk image with blkid?

-Stefan

> If you need more test and data ask me and I do and post.
> 
> Thanks for any reply and sorry for bad english.
> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479428.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:54:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxHu-0005Go-OJ; Mon, 13 Feb 2012 14:53:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RwxHt-0005Fv-37
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:53:53 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329144826!13103672!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27208 invoked from network); 13 Feb 2012 14:53:46 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-3.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 14:53:46 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q1DErfuP005726;
	Mon, 13 Feb 2012 09:53:41 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q1DEre5R010727;
	Mon, 13 Feb 2012 09:53:41 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012021309534006007 ; Mon, 13 Feb 2012 09:53:40 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1329136986.31256.96.camel@zakaz.uk.xensource.com>
Date: Mon, 13 Feb 2012 09:53:40 -0500
Message-Id: <DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

So like this? I took out the linefeed between the 2 printk in init_xenbus, to save a line of terminal output. (Mercurial foo is our internal number.)

Sincerely,

John
----

# HG changeset patch
# Parent 4b43dc4c31c3daa6ca2544af062044210f7ad189
mini-os: stop compiler complaint about unused variables

gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused variables
in mini-os drivers

Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

diff -r 4b43dc4c31c3 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Thu Feb 09 09:47:34 2012 -0500
+++ b/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 09:50:12 2012 -0500
@@ -328,16 +328,16 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
-    printk("Initialising xenbus\n");
-    DEBUG("init_xenbus called.\n");
+    printk("Initialising xenbus. ");
+    printk("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
     create_thread("xenstore", xenbus_thread_func, NULL);
-    DEBUG("buf at %p.\n", xenstore_buf);
+    printk("buf at %p.\n", xenstore_buf);
     err = bind_evtchn(start_info.store_evtchn,
 		      xenbus_evtchn_handler,
               NULL);
     unmask_evtchn(start_info.store_evtchn);
-    DEBUG("xenbus on irq %d\n", err);
+    printk("xenbus on irq %d\n", err);
 }
 
 void fini_xenbus(void)
@@ -478,7 +478,7 @@ static void xenbus_debug_msg(const char 
     struct xsd_sockmsg *reply;
 
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
-    DEBUG("Got a reply, type %d, id %d, len %d.\n",
+    printk("Got a reply, type %d, id %d, len %d.\n",
             reply->type, reply->req_id, reply->len);
 }
 


On Feb 13, 2012, at 7:43 AM, Ian Campbell wrote:

> I think all the DEBUG's reached from "test_xenbus()" can just become
> printks -- the calls from test_xenbus don't serve any other purpose than
> to print those messages. This includes the DEBUG message at stake here.
> 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:54:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxHu-0005Go-OJ; Mon, 13 Feb 2012 14:53:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RwxHt-0005Fv-37
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:53:53 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329144826!13103672!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27208 invoked from network); 13 Feb 2012 14:53:46 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-3.tower-174.messagelabs.com with SMTP;
	13 Feb 2012 14:53:46 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q1DErfuP005726;
	Mon, 13 Feb 2012 09:53:41 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q1DEre5R010727;
	Mon, 13 Feb 2012 09:53:41 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012021309534006007 ; Mon, 13 Feb 2012 09:53:40 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1329136986.31256.96.camel@zakaz.uk.xensource.com>
Date: Mon, 13 Feb 2012 09:53:40 -0500
Message-Id: <DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

So like this? I took out the linefeed between the 2 printk in init_xenbus, to save a line of terminal output. (Mercurial foo is our internal number.)

Sincerely,

John
----

# HG changeset patch
# Parent 4b43dc4c31c3daa6ca2544af062044210f7ad189
mini-os: stop compiler complaint about unused variables

gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) complains about unused variables
in mini-os drivers

Signed-off-by: John McDermott <john.mcdermott@nrl.navy.mil>

diff -r 4b43dc4c31c3 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Thu Feb 09 09:47:34 2012 -0500
+++ b/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 09:50:12 2012 -0500
@@ -328,16 +328,16 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
-    printk("Initialising xenbus\n");
-    DEBUG("init_xenbus called.\n");
+    printk("Initialising xenbus. ");
+    printk("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
     create_thread("xenstore", xenbus_thread_func, NULL);
-    DEBUG("buf at %p.\n", xenstore_buf);
+    printk("buf at %p.\n", xenstore_buf);
     err = bind_evtchn(start_info.store_evtchn,
 		      xenbus_evtchn_handler,
               NULL);
     unmask_evtchn(start_info.store_evtchn);
-    DEBUG("xenbus on irq %d\n", err);
+    printk("xenbus on irq %d\n", err);
 }
 
 void fini_xenbus(void)
@@ -478,7 +478,7 @@ static void xenbus_debug_msg(const char 
     struct xsd_sockmsg *reply;
 
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
-    DEBUG("Got a reply, type %d, id %d, len %d.\n",
+    printk("Got a reply, type %d, id %d, len %d.\n",
             reply->type, reply->req_id, reply->len);
 }
 


On Feb 13, 2012, at 7:43 AM, Ian Campbell wrote:

> I think all the DEBUG's reached from "test_xenbus()" can just become
> printks -- the calls from test_xenbus don't serve any other purpose than
> to print those messages. This includes the DEBUG message at stake here.
> 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxNG-0005f0-HN; Mon, 13 Feb 2012 14:59: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 1RwxNF-0005eu-1V
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:59:25 +0000
Received: from [85.158.139.83:29524] by server-8.bemta-5.messagelabs.com id
	A4/72-08951-C45293F4; Mon, 13 Feb 2012 14:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329145163!14836445!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21864 invoked from network); 13 Feb 2012 14:59:23 -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 Feb 2012 14:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10664658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 14:59:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 14:59:23 +0000
Date: Mon, 13 Feb 2012 15:03:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
In-Reply-To: <20120213143700.GF12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1202131449330.7456@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<20120213142738.GE12984@reaktio.net>
	<20120213143700.GF12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1951216686-1329145418=:7456"
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1951216686-1329145418=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 13 Feb 2012, Pasi Kärkkäinen wrote:
> On Mon, Feb 13, 2012 at 04:27:38PM +0200, Pasi Kärkkäinen wrote:
> > On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi Kärkkäinen wrote:
> > > On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi Kärkkäinen wrote:
> > > > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > > > On Wed, 8 Feb 2012, Pasi K�rkk�inen wrote:
> > > > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> > > > > > > > 
> > > > > > > > I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > > > one would be the best solution for Xen.
> > > > > > > > 
> > > > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > > > Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> > > > > > > > 
> > > > > > > > Can you guys give me your idea on the matter?
> > > > > > > > Please also mention any existing projects you know that are related to this problem.
> > > > > > > 
> > > > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > > > remoting. Gallium remoting could also be OK but considering that many
> > > > > > > cards don't have Gallium drivers we would probably end up doing two
> > > > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > > > Gallium->OpenGL in dom0).
> > > > > > > Mediated passthrough is very card specific so I am afraid you would end
> > > > > > > up writing virtualization specific drivers for all the cards you want to
> > > > > > > support. Not to mention that you might need to access some videocard
> > > > > > > interfaces that on Nvidia are not discosed.
> > > > > > > 
> > > > > > > I believe that virtualbox already supports OpenGL remoting in a decent
> > > > > > > way, so I would start from there, port what they have to Xen, and
> > > > > > > improve it.
> > > > > > > 
> > > > > > 
> > > > > > I wonder if SPICE already supports OpenGL stuff..
> > > > > > I think it's at least supposed to be able to support OpenGL.
> > > > > > 
> > > > > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html)
> > > > >  
> > > > > Not yet, but I think that they are working on it. Still very early days
> > > > > though.
> > > > > Also it would only work with HVM guests, while having a proper xen
> > > > > frontend/backend OpenGL remoting driver pair would work for both.
> > > > 
> > > > Yep.
> > > > 
> > > > There's also: http://sourceforge.net/projects/vmgl/
> > > > 
> > > > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel GPUs. "
> > > > 
> > > 
> > > And Chromium might have something related aswell:
> > > http://chromium.sourceforge.net/doc/index.html
> > > 
> > 
> > And one more related interesting link:
> > 
> > "VMware's Virtual GPU Driver Is Running Fast":
> > http://www.phoronix.com/scan.php?page=article&item=vmware_vmwgfx_g3d&num=1
> > 
> > So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to work pretty nicely these days!
> > That might be worth a look.. and to get it running with Xen.
> > 
> > I think SPICE is going to use Gallium3D aswell.
> > 
> 
> I thought i'd already stop spamming but here's more relevant links:
> 
> "SPICE On KVM/QEMU Works Towards Gallium3D":
> http://www.phoronix.com/scan.php?page=news_item&px=MTA1NTQ
> 
> And even more interesting!:
> 
> "The Gallium3D Driver That Few Know About / Xen vGallium":
> http://www.phoronix.com/scan.php?page=news_item&px=ODE2NQ
 
That's right: Xen had a Gallium3D based virtual GPU implementation
before anyone else, however it never went out of the prototype phase. It
would be great if a well motivated developer could get the sources
(https://github.com/smowton/vgallium,
http://www.cl.cam.ac.uk/~cs448/git/trunk/doc/Build-instructions) and
continue the work!
Ideally we would have a PV frontend/backend drivers pair that would work
for both PV and HVM guests. On the guest side the work would need to be
upstreamed to Mesa/DRM, on the host side we would need support in
QEMU/Linux.
--8323329-1951216686-1329145418=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1951216686-1329145418=:7456--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 14:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 14:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxNG-0005f0-HN; Mon, 13 Feb 2012 14:59: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 1RwxNF-0005eu-1V
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 14:59:25 +0000
Received: from [85.158.139.83:29524] by server-8.bemta-5.messagelabs.com id
	A4/72-08951-C45293F4; Mon, 13 Feb 2012 14:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329145163!14836445!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21864 invoked from network); 13 Feb 2012 14:59:23 -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 Feb 2012 14:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10664658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 14:59:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 14:59:23 +0000
Date: Mon, 13 Feb 2012 15:03:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
In-Reply-To: <20120213143700.GF12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1202131449330.7456@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<20120213142738.GE12984@reaktio.net>
	<20120213143700.GF12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1951216686-1329145418=:7456"
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1951216686-1329145418=:7456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 13 Feb 2012, Pasi Kärkkäinen wrote:
> On Mon, Feb 13, 2012 at 04:27:38PM +0200, Pasi Kärkkäinen wrote:
> > On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi Kärkkäinen wrote:
> > > On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi Kärkkäinen wrote:
> > > > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > > > On Wed, 8 Feb 2012, Pasi K�rkk�inen wrote:
> > > > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I am wondering how GPU sharing could/should be implemented for the Xen Hypervisor.
> > > > > > > > 
> > > > > > > > I have come across several papers that explain many possibilities on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > > > one would be the best solution for Xen.
> > > > > > > > 
> > > > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > > > Mediated passthrough (Multiplexing the GPU while maintaining the different contexts.)
> > > > > > > > 
> > > > > > > > Can you guys give me your idea on the matter?
> > > > > > > > Please also mention any existing projects you know that are related to this problem.
> > > > > > > 
> > > > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > > > remoting. Gallium remoting could also be OK but considering that many
> > > > > > > cards don't have Gallium drivers we would probably end up doing two
> > > > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > > > Gallium->OpenGL in dom0).
> > > > > > > Mediated passthrough is very card specific so I am afraid you would end
> > > > > > > up writing virtualization specific drivers for all the cards you want to
> > > > > > > support. Not to mention that you might need to access some videocard
> > > > > > > interfaces that on Nvidia are not discosed.
> > > > > > > 
> > > > > > > I believe that virtualbox already supports OpenGL remoting in a decent
> > > > > > > way, so I would start from there, port what they have to Xen, and
> > > > > > > improve it.
> > > > > > > 
> > > > > > 
> > > > > > I wonder if SPICE already supports OpenGL stuff..
> > > > > > I think it's at least supposed to be able to support OpenGL.
> > > > > > 
> > > > > > (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html)
> > > > >  
> > > > > Not yet, but I think that they are working on it. Still very early days
> > > > > though.
> > > > > Also it would only work with HVM guests, while having a proper xen
> > > > > frontend/backend OpenGL remoting driver pair would work for both.
> > > > 
> > > > Yep.
> > > > 
> > > > There's also: http://sourceforge.net/projects/vmgl/
> > > > 
> > > > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs; X11-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and Intel GPUs. "
> > > > 
> > > 
> > > And Chromium might have something related aswell:
> > > http://chromium.sourceforge.net/doc/index.html
> > > 
> > 
> > And one more related interesting link:
> > 
> > "VMware's Virtual GPU Driver Is Running Fast":
> > http://www.phoronix.com/scan.php?page=article&item=vmware_vmwgfx_g3d&num=1
> > 
> > So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to work pretty nicely these days!
> > That might be worth a look.. and to get it running with Xen.
> > 
> > I think SPICE is going to use Gallium3D aswell.
> > 
> 
> I thought i'd already stop spamming but here's more relevant links:
> 
> "SPICE On KVM/QEMU Works Towards Gallium3D":
> http://www.phoronix.com/scan.php?page=news_item&px=MTA1NTQ
> 
> And even more interesting!:
> 
> "The Gallium3D Driver That Few Know About / Xen vGallium":
> http://www.phoronix.com/scan.php?page=news_item&px=ODE2NQ
 
That's right: Xen had a Gallium3D based virtual GPU implementation
before anyone else, however it never went out of the prototype phase. It
would be great if a well motivated developer could get the sources
(https://github.com/smowton/vgallium,
http://www.cl.cam.ac.uk/~cs448/git/trunk/doc/Build-instructions) and
continue the work!
Ideally we would have a PV frontend/backend drivers pair that would work
for both PV and HVM guests. On the guest side the work would need to be
upstreamed to Mesa/DRM, on the host side we would need support in
QEMU/Linux.
--8323329-1951216686-1329145418=:7456
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1951216686-1329145418=:7456--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:06:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxU4-0005qV-EG; Mon, 13 Feb 2012 15:06:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwxU2-0005qQ-J6
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:06:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329145579!12664066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10958 invoked from network); 13 Feb 2012 15:06: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;
	13 Feb 2012 15:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10664886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:06:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:06:19 +0000
Message-ID: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Mon, 13 Feb 2012 15:06:17 +0000
In-Reply-To: <DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 14:53 +0000, John McDermott CIV wrote:
> Ian,
> 
> So like this?
I was thinking more like the following, e..g change all the test_* DEBUG
into print (for consistency) and make the init_xenbus messages more
useful while also using the unused var.

Only tested with my compiler which does not complain in the same way as
yours.

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329145492 0
# Node ID 858955a31cf51baef86c885af3db7fc85a04ec17
# Parent  4ed7fb2c7bd837a33ef7abbd5fbef6cc4c9992df
minios: Remove unused variables warnings

s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
and always print the IRQ and MFN used by the xenbus on init.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4ed7fb2c7bd8 -r 858955a31cf5 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 13:00:36 2012 +0000
+++ b/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 15:04:52 2012 +0000
@@ -328,7 +328,6 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
-    printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
     create_thread("xenstore", xenbus_thread_func, NULL);
@@ -337,7 +336,8 @@ void init_xenbus(void)
 		      xenbus_evtchn_handler,
               NULL);
     unmask_evtchn(start_info.store_evtchn);
-    DEBUG("xenbus on irq %d\n", err);
+    printk("xenbus initialised on irq %d mfn %#lx\n",
+	   err, start_info.store_mfn);
 }
 
 void fini_xenbus(void)
@@ -478,7 +478,7 @@ static void xenbus_debug_msg(const char 
     struct xsd_sockmsg *reply;
 
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
-    DEBUG("Got a reply, type %d, id %d, len %d.\n",
+    printk("Got a reply, type %d, id %d, len %d.\n",
             reply->type, reply->req_id, reply->len);
 }
 
@@ -752,16 +752,16 @@ static void do_ls_test(const char *pre)
     char **dirs, *msg;
     int x;
 
-    DEBUG("ls %s...\n", pre);
+    printk("ls %s...\n", pre);
     msg = xenbus_ls(XBT_NIL, pre, &dirs);
     if (msg) {
-	DEBUG("Error in xenbus ls: %s\n", msg);
+	printk("Error in xenbus ls: %s\n", msg);
 	free(msg);
 	return;
     }
     for (x = 0; dirs[x]; x++) 
     {
-        DEBUG("ls %s[%d] -> %s\n", pre, x, dirs[x]);
+        printk("ls %s[%d] -> %s\n", pre, x, dirs[x]);
         free(dirs[x]);
     }
     free(dirs);
@@ -770,68 +770,68 @@ static void do_ls_test(const char *pre)
 static void do_read_test(const char *path)
 {
     char *res, *msg;
-    DEBUG("Read %s...\n", path);
+    printk("Read %s...\n", path);
     msg = xenbus_read(XBT_NIL, path, &res);
     if (msg) {
-	DEBUG("Error in xenbus read: %s\n", msg);
+	printk("Error in xenbus read: %s\n", msg);
 	free(msg);
 	return;
     }
-    DEBUG("Read %s -> %s.\n", path, res);
+    printk("Read %s -> %s.\n", path, res);
     free(res);
 }
 
 static void do_write_test(const char *path, const char *val)
 {
     char *msg;
-    DEBUG("Write %s to %s...\n", val, path);
+    printk("Write %s to %s...\n", val, path);
     msg = xenbus_write(XBT_NIL, path, val);
     if (msg) {
-	DEBUG("Result %s\n", msg);
+	printk("Result %s\n", msg);
 	free(msg);
     } else {
-	DEBUG("Success.\n");
+	printk("Success.\n");
     }
 }
 
 static void do_rm_test(const char *path)
 {
     char *msg;
-    DEBUG("rm %s...\n", path);
+    printk("rm %s...\n", path);
     msg = xenbus_rm(XBT_NIL, path);
     if (msg) {
-	DEBUG("Result %s\n", msg);
+	printk("Result %s\n", msg);
 	free(msg);
     } else {
-	DEBUG("Success.\n");
+	printk("Success.\n");
     }
 }
 
 /* Simple testing thing */
 void test_xenbus(void)
 {
-    DEBUG("Doing xenbus test.\n");
+    printk("Doing xenbus test.\n");
     xenbus_debug_msg("Testing xenbus...\n");
 
-    DEBUG("Doing ls test.\n");
+    printk("Doing ls test.\n");
     do_ls_test("device");
     do_ls_test("device/vif");
     do_ls_test("device/vif/0");
 
-    DEBUG("Doing read test.\n");
+    printk("Doing read test.\n");
     do_read_test("device/vif/0/mac");
     do_read_test("device/vif/0/backend");
 
-    DEBUG("Doing write test.\n");
+    printk("Doing write test.\n");
     do_write_test("device/vif/0/flibble", "flobble");
     do_read_test("device/vif/0/flibble");
     do_write_test("device/vif/0/flibble", "widget");
     do_read_test("device/vif/0/flibble");
 
-    DEBUG("Doing rm test.\n");
+    printk("Doing rm test.\n");
     do_rm_test("device/vif/0/flibble");
     do_read_test("device/vif/0/flibble");
-    DEBUG("(Should have said ENOENT)\n");
+    printk("(Should have said ENOENT)\n");
 }
 
 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:06:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxU4-0005qV-EG; Mon, 13 Feb 2012 15:06:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwxU2-0005qQ-J6
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:06:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329145579!12664066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10958 invoked from network); 13 Feb 2012 15:06: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;
	13 Feb 2012 15:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10664886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:06:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:06:19 +0000
Message-ID: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Mon, 13 Feb 2012 15:06:17 +0000
In-Reply-To: <DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 14:53 +0000, John McDermott CIV wrote:
> Ian,
> 
> So like this?
I was thinking more like the following, e..g change all the test_* DEBUG
into print (for consistency) and make the init_xenbus messages more
useful while also using the unused var.

Only tested with my compiler which does not complain in the same way as
yours.

Ian.

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329145492 0
# Node ID 858955a31cf51baef86c885af3db7fc85a04ec17
# Parent  4ed7fb2c7bd837a33ef7abbd5fbef6cc4c9992df
minios: Remove unused variables warnings

s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
and always print the IRQ and MFN used by the xenbus on init.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4ed7fb2c7bd8 -r 858955a31cf5 extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 13:00:36 2012 +0000
+++ b/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 15:04:52 2012 +0000
@@ -328,7 +328,6 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
-    printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
     create_thread("xenstore", xenbus_thread_func, NULL);
@@ -337,7 +336,8 @@ void init_xenbus(void)
 		      xenbus_evtchn_handler,
               NULL);
     unmask_evtchn(start_info.store_evtchn);
-    DEBUG("xenbus on irq %d\n", err);
+    printk("xenbus initialised on irq %d mfn %#lx\n",
+	   err, start_info.store_mfn);
 }
 
 void fini_xenbus(void)
@@ -478,7 +478,7 @@ static void xenbus_debug_msg(const char 
     struct xsd_sockmsg *reply;
 
     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
-    DEBUG("Got a reply, type %d, id %d, len %d.\n",
+    printk("Got a reply, type %d, id %d, len %d.\n",
             reply->type, reply->req_id, reply->len);
 }
 
@@ -752,16 +752,16 @@ static void do_ls_test(const char *pre)
     char **dirs, *msg;
     int x;
 
-    DEBUG("ls %s...\n", pre);
+    printk("ls %s...\n", pre);
     msg = xenbus_ls(XBT_NIL, pre, &dirs);
     if (msg) {
-	DEBUG("Error in xenbus ls: %s\n", msg);
+	printk("Error in xenbus ls: %s\n", msg);
 	free(msg);
 	return;
     }
     for (x = 0; dirs[x]; x++) 
     {
-        DEBUG("ls %s[%d] -> %s\n", pre, x, dirs[x]);
+        printk("ls %s[%d] -> %s\n", pre, x, dirs[x]);
         free(dirs[x]);
     }
     free(dirs);
@@ -770,68 +770,68 @@ static void do_ls_test(const char *pre)
 static void do_read_test(const char *path)
 {
     char *res, *msg;
-    DEBUG("Read %s...\n", path);
+    printk("Read %s...\n", path);
     msg = xenbus_read(XBT_NIL, path, &res);
     if (msg) {
-	DEBUG("Error in xenbus read: %s\n", msg);
+	printk("Error in xenbus read: %s\n", msg);
 	free(msg);
 	return;
     }
-    DEBUG("Read %s -> %s.\n", path, res);
+    printk("Read %s -> %s.\n", path, res);
     free(res);
 }
 
 static void do_write_test(const char *path, const char *val)
 {
     char *msg;
-    DEBUG("Write %s to %s...\n", val, path);
+    printk("Write %s to %s...\n", val, path);
     msg = xenbus_write(XBT_NIL, path, val);
     if (msg) {
-	DEBUG("Result %s\n", msg);
+	printk("Result %s\n", msg);
 	free(msg);
     } else {
-	DEBUG("Success.\n");
+	printk("Success.\n");
     }
 }
 
 static void do_rm_test(const char *path)
 {
     char *msg;
-    DEBUG("rm %s...\n", path);
+    printk("rm %s...\n", path);
     msg = xenbus_rm(XBT_NIL, path);
     if (msg) {
-	DEBUG("Result %s\n", msg);
+	printk("Result %s\n", msg);
 	free(msg);
     } else {
-	DEBUG("Success.\n");
+	printk("Success.\n");
     }
 }
 
 /* Simple testing thing */
 void test_xenbus(void)
 {
-    DEBUG("Doing xenbus test.\n");
+    printk("Doing xenbus test.\n");
     xenbus_debug_msg("Testing xenbus...\n");
 
-    DEBUG("Doing ls test.\n");
+    printk("Doing ls test.\n");
     do_ls_test("device");
     do_ls_test("device/vif");
     do_ls_test("device/vif/0");
 
-    DEBUG("Doing read test.\n");
+    printk("Doing read test.\n");
     do_read_test("device/vif/0/mac");
     do_read_test("device/vif/0/backend");
 
-    DEBUG("Doing write test.\n");
+    printk("Doing write test.\n");
     do_write_test("device/vif/0/flibble", "flobble");
     do_read_test("device/vif/0/flibble");
     do_write_test("device/vif/0/flibble", "widget");
     do_read_test("device/vif/0/flibble");
 
-    DEBUG("Doing rm test.\n");
+    printk("Doing rm test.\n");
     do_rm_test("device/vif/0/flibble");
     do_read_test("device/vif/0/flibble");
-    DEBUG("(Should have said ENOENT)\n");
+    printk("(Should have said ENOENT)\n");
 }
 
 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:09:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxWP-0005wE-1j; Mon, 13 Feb 2012 15:08:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RwxWO-0005w5-1j
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:08:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329145725!9031661!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4557 invoked from network); 13 Feb 2012 15:08:46 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 15:08:46 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 184E8291D;
	Mon, 13 Feb 2012 17:08:45 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E8BDD20056; Mon, 13 Feb 2012 17:08:44 +0200 (EET)
Date: Mon, 13 Feb 2012 17:08:44 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120213150844.GG12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<20120213142738.GE12984@reaktio.net>
	<20120213143700.GF12984@reaktio.net>
	<alpine.DEB.2.00.1202131449330.7456@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202131449330.7456@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 03:03:23PM +0000, Stefano Stabellini wrote:
> On Mon, 13 Feb 2012, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Feb 13, 2012 at 04:27:38PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > > On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > > > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrot=
e:
> > > > > > On Wed, 8 Feb 2012, Pasi K=C3??=C2?rkk=C3??=C2?inen wrote:
> > > > > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini =
wrote:
> > > > > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > > > > Hi,
> > > > > > > > > =

> > > > > > > > > I am wondering how GPU sharing could/should be implemente=
d for the Xen Hypervisor.
> > > > > > > > > =

> > > > > > > > > I have come across several papers that explain many possi=
bilities on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > > > > one would be the best solution for Xen.
> > > > > > > > > =

> > > > > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > > > > Mediated passthrough (Multiplexing the GPU while maintain=
ing the different contexts.)
> > > > > > > > > =

> > > > > > > > > Can you guys give me your idea on the matter?
> > > > > > > > > Please also mention any existing projects you know that a=
re related to this problem.
> > > > > > > > =

> > > > > > > > My personal opinion is that the simplest thing to do is Ope=
nGL
> > > > > > > > remoting. Gallium remoting could also be OK but considering=
 that many
> > > > > > > > cards don't have Gallium drivers we would probably end up d=
oing two
> > > > > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > > > > Gallium->OpenGL in dom0).
> > > > > > > > Mediated passthrough is very card specific so I am afraid y=
ou would end
> > > > > > > > up writing virtualization specific drivers for all the card=
s you want to
> > > > > > > > support. Not to mention that you might need to access some =
videocard
> > > > > > > > interfaces that on Nvidia are not discosed.
> > > > > > > > =

> > > > > > > > I believe that virtualbox already supports OpenGL remoting =
in a decent
> > > > > > > > way, so I would start from there, port what they have to Xe=
n, and
> > > > > > > > improve it.
> > > > > > > > =

> > > > > > > =

> > > > > > > I wonder if SPICE already supports OpenGL stuff..
> > > > > > > I think it's at least supposed to be able to support OpenGL.
> > > > > > > =

> > > > > > > (http://lists.freedesktop.org/archives/spice-devel/2011-Novem=
ber/006018.html)
> > > > > >  =

> > > > > > Not yet, but I think that they are working on it. Still very ea=
rly days
> > > > > > though.
> > > > > > Also it would only work with HVM guests, while having a proper =
xen
> > > > > > frontend/backend OpenGL remoting driver pair would work for bot=
h.
> > > > > =

> > > > > Yep.
> > > > > =

> > > > > There's also: http://sourceforge.net/projects/vmgl/
> > > > > =

> > > > > "OpenGL apps running inside a VM use VMGL to obtain graphics hard=
ware acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs;=
 X11-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and I=
ntel GPUs. "
> > > > > =

> > > > =

> > > > And Chromium might have something related aswell:
> > > > http://chromium.sourceforge.net/doc/index.html
> > > > =

> > > =

> > > And one more related interesting link:
> > > =

> > > "VMware's Virtual GPU Driver Is Running Fast":
> > > http://www.phoronix.com/scan.php?page=3Darticle&item=3Dvmware_vmwgfx_=
g3d&num=3D1
> > > =

> > > So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to wo=
rk pretty nicely these days!
> > > That might be worth a look.. and to get it running with Xen.
> > > =

> > > I think SPICE is going to use Gallium3D aswell.
> > > =

> > =

> > I thought i'd already stop spamming but here's more relevant links:
> > =

> > "SPICE On KVM/QEMU Works Towards Gallium3D":
> > http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTA1NTQ
> > =

> > And even more interesting!:
> > =

> > "The Gallium3D Driver That Few Know About / Xen vGallium":
> > http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DODE2NQ
>  =

> That's right: Xen had a Gallium3D based virtual GPU implementation
> before anyone else, however it never went out of the prototype phase. It
> would be great if a well motivated developer could get the sources
> (https://github.com/smowton/vgallium,
> http://www.cl.cam.ac.uk/~cs448/git/trunk/doc/Build-instructions) and
> continue the work!
> Ideally we would have a PV frontend/backend drivers pair that would work
> for both PV and HVM guests. On the guest side the work would need to be
> upstreamed to Mesa/DRM, on the host side we would need support in
> QEMU/Linux.
>

And some more related info for the mailinglist archives:

OpenSuse has some rpms with the xen3d/vgallium patches:
https://build.opensuse.org/package/files?package=3Dxen-vgallium&project=3Ds=
ecurity%3AOpenTC

Research paper from XenSummit 2009:
"Flexible and Secure Hardware 3D Rendering on Xen":
http://www.xen.org/files/xensummit_oracle09/xensummit_chris.pdf


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:09:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxWP-0005wE-1j; Mon, 13 Feb 2012 15:08:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RwxWO-0005w5-1j
	for Xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:08:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329145725!9031661!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4557 invoked from network); 13 Feb 2012 15:08:46 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 15:08:46 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 184E8291D;
	Mon, 13 Feb 2012 17:08:45 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E8BDD20056; Mon, 13 Feb 2012 17:08:44 +0200 (EET)
Date: Mon, 13 Feb 2012 17:08:44 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120213150844.GG12984@reaktio.net>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<20120213142738.GE12984@reaktio.net>
	<20120213143700.GF12984@reaktio.net>
	<alpine.DEB.2.00.1202131449330.7456@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1202131449330.7456@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 03:03:23PM +0000, Stefano Stabellini wrote:
> On Mon, 13 Feb 2012, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Feb 13, 2012 at 04:27:38PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > On Wed, Feb 08, 2012 at 08:22:33PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > > On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > > > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrot=
e:
> > > > > > On Wed, 8 Feb 2012, Pasi K=C3??=C2?rkk=C3??=C2?inen wrote:
> > > > > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini =
wrote:
> > > > > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > > > > Hi,
> > > > > > > > > =

> > > > > > > > > I am wondering how GPU sharing could/should be implemente=
d for the Xen Hypervisor.
> > > > > > > > > =

> > > > > > > > > I have come across several papers that explain many possi=
bilities on GPU sharing for multiple VMs but I'm not sure wich
> > > > > > > > > one would be the best solution for Xen.
> > > > > > > > > =

> > > > > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > > > > Mediated passthrough (Multiplexing the GPU while maintain=
ing the different contexts.)
> > > > > > > > > =

> > > > > > > > > Can you guys give me your idea on the matter?
> > > > > > > > > Please also mention any existing projects you know that a=
re related to this problem.
> > > > > > > > =

> > > > > > > > My personal opinion is that the simplest thing to do is Ope=
nGL
> > > > > > > > remoting. Gallium remoting could also be OK but considering=
 that many
> > > > > > > > cards don't have Gallium drivers we would probably end up d=
oing two
> > > > > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > > > > Gallium->OpenGL in dom0).
> > > > > > > > Mediated passthrough is very card specific so I am afraid y=
ou would end
> > > > > > > > up writing virtualization specific drivers for all the card=
s you want to
> > > > > > > > support. Not to mention that you might need to access some =
videocard
> > > > > > > > interfaces that on Nvidia are not discosed.
> > > > > > > > =

> > > > > > > > I believe that virtualbox already supports OpenGL remoting =
in a decent
> > > > > > > > way, so I would start from there, port what they have to Xe=
n, and
> > > > > > > > improve it.
> > > > > > > > =

> > > > > > > =

> > > > > > > I wonder if SPICE already supports OpenGL stuff..
> > > > > > > I think it's at least supposed to be able to support OpenGL.
> > > > > > > =

> > > > > > > (http://lists.freedesktop.org/archives/spice-devel/2011-Novem=
ber/006018.html)
> > > > > >  =

> > > > > > Not yet, but I think that they are working on it. Still very ea=
rly days
> > > > > > though.
> > > > > > Also it would only work with HVM guests, while having a proper =
xen
> > > > > > frontend/backend OpenGL remoting driver pair would work for bot=
h.
> > > > > =

> > > > > Yep.
> > > > > =

> > > > > There's also: http://sourceforge.net/projects/vmgl/
> > > > > =

> > > > > "OpenGL apps running inside a VM use VMGL to obtain graphics hard=
ware acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs;=
 X11-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and I=
ntel GPUs. "
> > > > > =

> > > > =

> > > > And Chromium might have something related aswell:
> > > > http://chromium.sourceforge.net/doc/index.html
> > > > =

> > > =

> > > And one more related interesting link:
> > > =

> > > "VMware's Virtual GPU Driver Is Running Fast":
> > > http://www.phoronix.com/scan.php?page=3Darticle&item=3Dvmware_vmwgfx_=
g3d&num=3D1
> > > =

> > > So the Gallium3D virtual GPU/OpenGL stuff with VMware VMs seems to wo=
rk pretty nicely these days!
> > > That might be worth a look.. and to get it running with Xen.
> > > =

> > > I think SPICE is going to use Gallium3D aswell.
> > > =

> > =

> > I thought i'd already stop spamming but here's more relevant links:
> > =

> > "SPICE On KVM/QEMU Works Towards Gallium3D":
> > http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTA1NTQ
> > =

> > And even more interesting!:
> > =

> > "The Gallium3D Driver That Few Know About / Xen vGallium":
> > http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DODE2NQ
>  =

> That's right: Xen had a Gallium3D based virtual GPU implementation
> before anyone else, however it never went out of the prototype phase. It
> would be great if a well motivated developer could get the sources
> (https://github.com/smowton/vgallium,
> http://www.cl.cam.ac.uk/~cs448/git/trunk/doc/Build-instructions) and
> continue the work!
> Ideally we would have a PV frontend/backend drivers pair that would work
> for both PV and HVM guests. On the guest side the work would need to be
> upstreamed to Mesa/DRM, on the host side we would need support in
> QEMU/Linux.
>

And some more related info for the mailinglist archives:

OpenSuse has some rpms with the xen3d/vgallium patches:
https://build.opensuse.org/package/files?package=3Dxen-vgallium&project=3Ds=
ecurity%3AOpenTC

Research paper from XenSummit 2009:
"Flexible and Secure Hardware 3D Rendering on Xen":
http://www.xen.org/files/xensummit_oracle09/xensummit_chris.pdf


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:13:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwxay-000682-Oj; Mon, 13 Feb 2012 15:13:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwxax-00067u-1n
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:13:35 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329146007!13112112!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23190 invoked from network); 13 Feb 2012 15:13:28 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2012 15:13:28 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwxap-0002lc-2r
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:13:27 -0800
Date: Mon, 13 Feb 2012 07:13:27 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329146007080-5479529.post@n5.nabble.com>
In-Reply-To: <4F3923D6.2000502@canonical.com>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
	with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply, test system have already dom0 kernel with
bugfix...2.6.32-5-xen-amd64 version 2.6.32-41
linux-2.6 (2.6.32-40) stable; urgency=high
....
* xen: blkback: don't fail empty barrier requests (Closes: #637234)

http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-41/changelog

blkid is already on log file attached in first post

mounting image on dom0 is right uuid and working:
mount -o loop /mnt/vm/disks/PRECISE.disk1.xm /mnt/tmp/
mount
...
/dev/loop0 on /mnt/tmp type ext4 (rw)
blkid 
/dev/loop0: UUID="b58257ed-87ed-480f-86dc-9d06cefb2267" TYPE="ext4"

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479529.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:13:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwxay-000682-Oj; Mon, 13 Feb 2012 15:13:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwxax-00067u-1n
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:13:35 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329146007!13112112!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23190 invoked from network); 13 Feb 2012 15:13:28 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2012 15:13:28 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rwxap-0002lc-2r
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 07:13:27 -0800
Date: Mon, 13 Feb 2012 07:13:27 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329146007080-5479529.post@n5.nabble.com>
In-Reply-To: <4F3923D6.2000502@canonical.com>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
	with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply, test system have already dom0 kernel with
bugfix...2.6.32-5-xen-amd64 version 2.6.32-41
linux-2.6 (2.6.32-40) stable; urgency=high
....
* xen: blkback: don't fail empty barrier requests (Closes: #637234)

http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-41/changelog

blkid is already on log file attached in first post

mounting image on dom0 is right uuid and working:
mount -o loop /mnt/vm/disks/PRECISE.disk1.xm /mnt/tmp/
mount
...
/dev/loop0 on /mnt/tmp type ext4 (rw)
blkid 
/dev/loop0: UUID="b58257ed-87ed-480f-86dc-9d06cefb2267" TYPE="ext4"

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479529.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:28:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwxon-0006wB-55; Mon, 13 Feb 2012 15:27: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 1Rwxom-0006w6-Ir
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:27:52 +0000
Received: from [85.158.139.83:59520] by server-7.bemta-5.messagelabs.com id
	85/9B-01252-7FB293F4; Mon, 13 Feb 2012 15:27:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329146870!14239222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24938 invoked from network); 13 Feb 2012 15:27:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 15:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10665659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:27:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:27:50 +0000
Message-ID: <1329146868.31256.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 15:27:48 +0000
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> This series adds preliminary device tree support to Xen for ARM.

Keir applied #1-3 so I have gone ahead and applied #4-8, including the
xen/common/$devicetree bits as I mentioned.

Thanks David.

Does the wiki page need updating now?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:28:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 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.xensource.com>)
	id 1Rwxon-0006wB-55; Mon, 13 Feb 2012 15:27: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 1Rwxom-0006w6-Ir
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:27:52 +0000
Received: from [85.158.139.83:59520] by server-7.bemta-5.messagelabs.com id
	85/9B-01252-7FB293F4; Mon, 13 Feb 2012 15:27:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329146870!14239222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24938 invoked from network); 13 Feb 2012 15:27:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 15:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10665659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:27:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:27:50 +0000
Message-ID: <1329146868.31256.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 15:27:48 +0000
In-Reply-To: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> This series adds preliminary device tree support to Xen for ARM.

Keir applied #1-3 so I have gone ahead and applied #4-8, including the
xen/common/$devicetree bits as I mentioned.

Thanks David.

Does the wiki page need updating now?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:29:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxpX-0006yW-Is; Mon, 13 Feb 2012 15:28:39 +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 1RwxpV-0006yM-Tw
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:28:38 +0000
Received: from [85.158.139.83:64963] by server-6.bemta-5.messagelabs.com id
	52/59-04784-52C293F4; Mon, 13 Feb 2012 15:28:37 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329146916!7532683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5502 invoked from network); 13 Feb 2012 15:28:36 -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;
	13 Feb 2012 15:28:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10665672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:28:36 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 15:28:36 +0000
Date: Mon, 13 Feb 2012 15:24:42 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120213125348.GA26773@redhat.com>
Message-ID: <alpine.DEB.2.00.1202131523150.4334@perard.uk.xensource.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
	<20120213125348.GA26773@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V6 11/11] pci: Do not check if a bus exist
 in pci_parse_devaddr.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Michael S. Tsirkin wrote:

> On Mon, Feb 13, 2012 at 12:20:13PM +0000, Anthony PERARD wrote:
> > Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
> > this should be the jobs of a caller. In fact, the two callers of this function
> > will try to retrieve the PCIBus related to the devaddr and return an error if
> > they cannot.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>
> I agree. It's a good patch. And this will help address the bridges.
> Want me to queue this?

Yes, go ahead. Thanks you.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:29:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:29:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwxpX-0006yW-Is; Mon, 13 Feb 2012 15:28:39 +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 1RwxpV-0006yM-Tw
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:28:38 +0000
Received: from [85.158.139.83:64963] by server-6.bemta-5.messagelabs.com id
	52/59-04784-52C293F4; Mon, 13 Feb 2012 15:28:37 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329146916!7532683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5502 invoked from network); 13 Feb 2012 15:28:36 -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;
	13 Feb 2012 15:28:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10665672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:28:36 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 15:28:36 +0000
Date: Mon, 13 Feb 2012 15:24:42 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120213125348.GA26773@redhat.com>
Message-ID: <alpine.DEB.2.00.1202131523150.4334@perard.uk.xensource.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-12-git-send-email-anthony.perard@citrix.com>
	<20120213125348.GA26773@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V6 11/11] pci: Do not check if a bus exist
 in pci_parse_devaddr.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Michael S. Tsirkin wrote:

> On Mon, Feb 13, 2012 at 12:20:13PM +0000, Anthony PERARD wrote:
> > Actually, pci_parse_devaddr checks if the dom/bus of the PCI address exist. But
> > this should be the jobs of a caller. In fact, the two callers of this function
> > will try to retrieve the PCIBus related to the devaddr and return an error if
> > they cannot.
> >
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>
> I agree. It's a good patch. And this will help address the bridges.
> Want me to queue this?

Yes, go ahead. Thanks you.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:37:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwxxj-0007bW-Dx; Mon, 13 Feb 2012 15:37:07 +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 1Rwxxi-0007bP-B2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:37:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329147381!59921609!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30457 invoked from network); 13 Feb 2012 15:36:21 -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;
	13 Feb 2012 15:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10665879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:37:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:37:05 +0000
Message-ID: <1329147423.31256.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 15:37:03 +0000
In-Reply-To: <1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Few missing #define are the cause of a compile failure with
> XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> native compilation). This patch fill the gaps.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I committed this.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:37:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwxxj-0007bW-Dx; Mon, 13 Feb 2012 15:37:07 +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 1Rwxxi-0007bP-B2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:37:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329147381!59921609!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30457 invoked from network); 13 Feb 2012 15:36:21 -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;
	13 Feb 2012 15:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10665879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:37:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:37:05 +0000
Message-ID: <1329147423.31256.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 15:37:03 +0000
In-Reply-To: <1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Few missing #define are the cause of a compile failure with
> XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
> native compilation). This patch fill the gaps.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I committed this.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:42:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15: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.xensource.com>)
	id 1Rwy2X-0007nk-5F; Mon, 13 Feb 2012 15:42:05 +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 1Rwy2V-0007na-Px
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:42:04 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329147663!56508299!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30792 invoked from network); 13 Feb 2012 15:41:03 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-27.messagelabs.com with SMTP;
	13 Feb 2012 15:41:03 -0000
Received: from p5b2e44ca.dip.t-dialin.net ([91.46.68.202] 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 1Rwy2R-0005TQ-8x; Mon, 13 Feb 2012 15:41:59 +0000
Message-ID: <4F392F45.3000903@canonical.com>
Date: Mon, 13 Feb 2012 16:41:57 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Fantu <fantonifabio@tiscali.it>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
In-Reply-To: <1329146007080-5479529.post@n5.nabble.com>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
 with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.02.2012 16:13, Fantu wrote:
> Thanks for reply, test system have already dom0 kernel with
> bugfix...2.6.32-5-xen-amd64 version 2.6.32-41
> linux-2.6 (2.6.32-40) stable; urgency=high
> ....
> * xen: blkback: don't fail empty barrier requests (Closes: #637234)
> 
> http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-41/changelog
> 
> blkid is already on log file attached in first post
> 
> mounting image on dom0 is right uuid and working:
> mount -o loop /mnt/vm/disks/PRECISE.disk1.xm /mnt/tmp/
> mount
> ...
> /dev/loop0 on /mnt/tmp type ext4 (rw)
> blkid 
> /dev/loop0: UUID="b58257ed-87ed-480f-86dc-9d06cefb2267" TYPE="ext4"
> 

Ok, so that looks ok. The /proc/partitions output looks like xvda1 is present
(at least ot the kernel). When you fall into the emergency shell, is there a
/dev/xvda1, and then as the next piece in that chain an entry in
/dev/disk-by-uuid/ ?

-Stefan
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479529.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:42:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15: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.xensource.com>)
	id 1Rwy2X-0007nk-5F; Mon, 13 Feb 2012 15:42:05 +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 1Rwy2V-0007na-Px
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:42:04 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329147663!56508299!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30792 invoked from network); 13 Feb 2012 15:41:03 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-27.messagelabs.com with SMTP;
	13 Feb 2012 15:41:03 -0000
Received: from p5b2e44ca.dip.t-dialin.net ([91.46.68.202] 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 1Rwy2R-0005TQ-8x; Mon, 13 Feb 2012 15:41:59 +0000
Message-ID: <4F392F45.3000903@canonical.com>
Date: Mon, 13 Feb 2012 16:41:57 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Fantu <fantonifabio@tiscali.it>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
In-Reply-To: <1329146007080-5479529.post@n5.nabble.com>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
 with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13.02.2012 16:13, Fantu wrote:
> Thanks for reply, test system have already dom0 kernel with
> bugfix...2.6.32-5-xen-amd64 version 2.6.32-41
> linux-2.6 (2.6.32-40) stable; urgency=high
> ....
> * xen: blkback: don't fail empty barrier requests (Closes: #637234)
> 
> http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-41/changelog
> 
> blkid is already on log file attached in first post
> 
> mounting image on dom0 is right uuid and working:
> mount -o loop /mnt/vm/disks/PRECISE.disk1.xm /mnt/tmp/
> mount
> ...
> /dev/loop0 on /mnt/tmp type ext4 (rw)
> blkid 
> /dev/loop0: UUID="b58257ed-87ed-480f-86dc-9d06cefb2267" TYPE="ext4"
> 

Ok, so that looks ok. The /proc/partitions output looks like xvda1 is present
(at least ot the kernel). When you fall into the emergency shell, is there a
/dev/xvda1, and then as the next piece in that chain an entry in
/dev/disk-by-uuid/ ?

-Stefan
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5479529.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:47:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15: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.xensource.com>)
	id 1Rwy6y-00083A-VM; Mon, 13 Feb 2012 15:46:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rwy6w-00082z-Ts
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:46:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329147990!13169822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21770 invoked from network); 13 Feb 2012 15:46:32 -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;
	13 Feb 2012 15:46:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181512985"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10:46:29 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	10:46:29 -0500
Message-ID: <4F393053.80903@citrix.com>
Date: Mon, 13 Feb 2012 15:46:27 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>	
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
	<1329144704.31256.114.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329144704.31256.114.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/12 14:51, Ian Campbell wrote:
> On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Prior to setting up the page tables, parse the DTB for the location
>> and size of RAM.
>>
>> Use this information to get the physical address to relocate Xen to in
>> setup_pagetables().
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> Acked-by: Tim Deegan <tim@xen.org>
>> ---
> [...]
>>  xen/common/Makefile           |    3 +
>>  xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
> [...]
>>  xen/include/xen/device_tree.h |   36 ++++++++
> 
> I'd have preferred these non-ARM bits in a separate patch if possible.
> I'm going to commit them anyway though on the basis that they are in
> reality ARM specific unless Keir (or someone else) objects quite soon.

Dividing maintainer-ship by directory seems a little coarse grained.  It
may be more practical for you (Ian) to be the maintainer/committer for
the device tree related stuff even though they live under xen/common/.

Or, if you prefer, I can make sure to split the patches in common and
arch bits.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:47:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15: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.xensource.com>)
	id 1Rwy6y-00083A-VM; Mon, 13 Feb 2012 15:46:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rwy6w-00082z-Ts
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:46:39 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329147990!13169822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21770 invoked from network); 13 Feb 2012 15:46:32 -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;
	13 Feb 2012 15:46:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181512985"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10:46:29 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	10:46:29 -0500
Message-ID: <4F393053.80903@citrix.com>
Date: Mon, 13 Feb 2012 15:46:27 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>	
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
	<1329144704.31256.114.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329144704.31256.114.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/12 14:51, Ian Campbell wrote:
> On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Prior to setting up the page tables, parse the DTB for the location
>> and size of RAM.
>>
>> Use this information to get the physical address to relocate Xen to in
>> setup_pagetables().
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> Acked-by: Tim Deegan <tim@xen.org>
>> ---
> [...]
>>  xen/common/Makefile           |    3 +
>>  xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
> [...]
>>  xen/include/xen/device_tree.h |   36 ++++++++
> 
> I'd have preferred these non-ARM bits in a separate patch if possible.
> I'm going to commit them anyway though on the basis that they are in
> reality ARM specific unless Keir (or someone else) objects quite soon.

Dividing maintainer-ship by directory seems a little coarse grained.  It
may be more practical for you (Ian) to be the maintainer/committer for
the device tree related stuff even though they live under xen/common/.

Or, if you prefer, I can make sure to split the patches in common and
arch bits.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:50:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyA9-0008MD-L2; Mon, 13 Feb 2012 15:49:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RwyA8-0008M4-M9
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:49:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329148178!3806129!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1789 invoked from network); 13 Feb 2012 15:49:49 -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;
	13 Feb 2012 15:49:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21898593"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10:49:37 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	10:49:37 -0500
Message-ID: <4F393110.8070406@citrix.com>
Date: Mon, 13 Feb 2012 15:49:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329146868.31256.119.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329146868.31256.119.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/12 15:27, Ian Campbell wrote:
> On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
>> This series adds preliminary device tree support to Xen for ARM.
> 
> Keir applied #1-3 so I have gone ahead and applied #4-8, including the
> xen/common/$devicetree bits as I mentioned.
> 
> Thanks David.
> 
> Does the wiki page need updating now?

I've updated it somewhat.  That page doesn't really know who its
audience is so it more a collection of notes rather than something with
more structure/flow.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:50:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyA9-0008MD-L2; Mon, 13 Feb 2012 15:49:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RwyA8-0008M4-M9
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:49:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329148178!3806129!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1789 invoked from network); 13 Feb 2012 15:49:49 -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;
	13 Feb 2012 15:49:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21898593"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 10:49:37 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	10:49:37 -0500
Message-ID: <4F393110.8070406@citrix.com>
Date: Mon, 13 Feb 2012 15:49:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329146868.31256.119.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329146868.31256.119.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/8] arm: initial device tree support (#3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/12 15:27, Ian Campbell wrote:
> On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
>> This series adds preliminary device tree support to Xen for ARM.
> 
> Keir applied #1-3 so I have gone ahead and applied #4-8, including the
> xen/common/$devicetree bits as I mentioned.
> 
> Thanks David.
> 
> Does the wiki page need updating now?

I've updated it somewhat.  That page doesn't really know who its
audience is so it more a collection of notes rather than something with
more structure/flow.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:57:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyGq-0000Df-M6; Mon, 13 Feb 2012 15:56:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyGn-0000Da-TA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:56:50 +0000
Received: from [85.158.139.83:26956] by server-2.bemta-5.messagelabs.com id
	B6/0C-20725-1C2393F4; Mon, 13 Feb 2012 15:56:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329148608!14878973!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13455 invoked from network); 13 Feb 2012 15:56:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 15:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10666654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:56:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:56:48 +0000
Message-ID: <1329148607.31256.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 15:56:47 +0000
In-Reply-To: <1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 05/10] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_core_arm.c and xc_core_arm.h; define barriers on ARM.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxc/Makefile      |    1 +
>  tools/libxc/xc_core.h     |    2 +
>  tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
>  tools/libxc/xenctrl.h     |    4 ++
>  5 files changed, 173 insertions(+), 0 deletions(-)
>  create mode 100644 tools/libxc/xc_core_arm.c
>  create mode 100644 tools/libxc/xc_core_arm.h
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index b5e7022..f2e1ba7 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
>  CTRL_SRCS-y       += xc_core.c
>  CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
>  CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
> +CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
>  CTRL_SRCS-y       += xc_cpupool.c
>  CTRL_SRCS-y       += xc_domain.c
>  CTRL_SRCS-y       += xc_evtchn.c
> diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
> index 1e88a75..358a8c1 100644
> --- a/tools/libxc/xc_core.h
> +++ b/tools/libxc/xc_core.h
> @@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
>  # include "xc_core_x86.h"
>  #elif defined (__ia64__)
>  # include "xc_core_ia64.h"
> +#elif defined (__arm__)
> +# include "xc_core_arm.h"
>  #else
>  # error "unsupported architecture"
>  #endif
> diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
> new file mode 100644
> index 0000000..b1482ec
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.c
> @@ -0,0 +1,106 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011 Citrix Systems
> + *
> + */
> +
> +#include "xg_private.h"
> +#include "xc_core.h"
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn)
> +{
> +    /* TODO: memory from DT */
> +    if (pfn >= 0x80000 && pfn < 0x88000)
> +        return 1;
> +    return 0;
> +}
> +
> +
> +static int nr_gpfns(xc_interface *xch, domid_t domid)
> +{
> +    return xc_domain_maximum_gpfn(xch, domid) + 1;
> +}
> +
> +int
> +xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
> +{
> +    return 1;
> +}
> +
> +int
> +xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
> +                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
> +                            xc_core_memory_map_t **mapp,
> +                            unsigned int *nr_entries)
> +{
> +    unsigned long p2m_size = nr_gpfns(xch, info->domid);
> +    xc_core_memory_map_t *map;
> +
> +    map = malloc(sizeof(*map));
> +    if ( map == NULL )
> +    {
> +        PERROR("Could not allocate memory");
> +        return -1;
> +    }
> +
> +    map->addr = 0;
> +    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
> +
> +    *mapp = map;
> +    *nr_entries = 1;
> +    return 0;
> +}
> +
> +static int
> +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
> +                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                        unsigned long *pfnp, int rw)
> +{
> +    return -ENOSYS;
> +}
> +
> +int
> +xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
> +                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                        unsigned long *pfnp)
> +{
> +    struct domain_info_context _dinfo = { .guest_width = guest_width };
> +    struct domain_info_context *dinfo = &_dinfo;
> +    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
> +                                   live_shinfo, live_p2m, pfnp, 0);
> +}
> +
> +int
> +xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
> +                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                              unsigned long *pfnp)
> +{
> +    struct domain_info_context _dinfo = { .guest_width = guest_width };
> +    struct domain_info_context *dinfo = &_dinfo;
> +    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
> +                                   live_shinfo, live_p2m, pfnp, 1);
> +}
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
> new file mode 100644
> index 0000000..3a6be2a
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.h
> @@ -0,0 +1,60 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2012 Citrix Systems
> + *
> + */
> +
> +#ifndef XC_CORE_ARM_H
> +#define XC_CORE_ARM_H
> +
> +#define ELF_ARCH_DATA           ELFDATA2LSB
> +#define ELF_ARCH_MACHINE        EM_ARM
> +
> +struct xc_core_arch_context {
> +    /* nothing */
> +};
> +
> +#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
> +                                                                (0)
> +#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn);
> +static inline int
> +xc_core_arch_context_get_shdr(xc_interface *xch,
> +                              struct xc_core_arch_context *arch_ctxt, 
> +                              struct xc_core_section_headers *sheaders,
> +                              struct xc_core_strtab *strtab,
> +                              uint64_t *filesz, uint64_t offset)
> +{
> +    *filesz = 0;
> +    return 0;
> +}
> +
> +#endif /* XC_CORE_ARM_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> index e6fd488..3ee8c59 100644
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -83,6 +83,10 @@
>  #define xen_mb()   asm volatile ("mf" ::: "memory")
>  #define xen_rmb()  asm volatile ("mf" ::: "memory")
>  #define xen_wmb()  asm volatile ("mf" ::: "memory")
> +#elif defined(__arm__)
> +#define xen_mb()   asm volatile ("dmb" : : : "memory")
> +#define xen_rmb()  asm volatile ("dmb" : : : "memory")
> +#define xen_wmb()  asm volatile ("dmb" : : : "memory")
>  #else
>  #error "Define barriers"
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 15:57:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 15:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyGq-0000Df-M6; Mon, 13 Feb 2012 15:56:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyGn-0000Da-TA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 15:56:50 +0000
Received: from [85.158.139.83:26956] by server-2.bemta-5.messagelabs.com id
	B6/0C-20725-1C2393F4; Mon, 13 Feb 2012 15:56:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329148608!14878973!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13455 invoked from network); 13 Feb 2012 15:56:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 15:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10666654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 15:56:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 15:56:48 +0000
Message-ID: <1329148607.31256.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 15:56:47 +0000
In-Reply-To: <1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 05/10] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_core_arm.c and xc_core_arm.h; define barriers on ARM.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxc/Makefile      |    1 +
>  tools/libxc/xc_core.h     |    2 +
>  tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
>  tools/libxc/xenctrl.h     |    4 ++
>  5 files changed, 173 insertions(+), 0 deletions(-)
>  create mode 100644 tools/libxc/xc_core_arm.c
>  create mode 100644 tools/libxc/xc_core_arm.h
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index b5e7022..f2e1ba7 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
>  CTRL_SRCS-y       += xc_core.c
>  CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
>  CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
> +CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
>  CTRL_SRCS-y       += xc_cpupool.c
>  CTRL_SRCS-y       += xc_domain.c
>  CTRL_SRCS-y       += xc_evtchn.c
> diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
> index 1e88a75..358a8c1 100644
> --- a/tools/libxc/xc_core.h
> +++ b/tools/libxc/xc_core.h
> @@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
>  # include "xc_core_x86.h"
>  #elif defined (__ia64__)
>  # include "xc_core_ia64.h"
> +#elif defined (__arm__)
> +# include "xc_core_arm.h"
>  #else
>  # error "unsupported architecture"
>  #endif
> diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
> new file mode 100644
> index 0000000..b1482ec
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.c
> @@ -0,0 +1,106 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011 Citrix Systems
> + *
> + */
> +
> +#include "xg_private.h"
> +#include "xc_core.h"
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn)
> +{
> +    /* TODO: memory from DT */
> +    if (pfn >= 0x80000 && pfn < 0x88000)
> +        return 1;
> +    return 0;
> +}
> +
> +
> +static int nr_gpfns(xc_interface *xch, domid_t domid)
> +{
> +    return xc_domain_maximum_gpfn(xch, domid) + 1;
> +}
> +
> +int
> +xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
> +{
> +    return 1;
> +}
> +
> +int
> +xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
> +                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
> +                            xc_core_memory_map_t **mapp,
> +                            unsigned int *nr_entries)
> +{
> +    unsigned long p2m_size = nr_gpfns(xch, info->domid);
> +    xc_core_memory_map_t *map;
> +
> +    map = malloc(sizeof(*map));
> +    if ( map == NULL )
> +    {
> +        PERROR("Could not allocate memory");
> +        return -1;
> +    }
> +
> +    map->addr = 0;
> +    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
> +
> +    *mapp = map;
> +    *nr_entries = 1;
> +    return 0;
> +}
> +
> +static int
> +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
> +                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                        unsigned long *pfnp, int rw)
> +{
> +    return -ENOSYS;
> +}
> +
> +int
> +xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
> +                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                        unsigned long *pfnp)
> +{
> +    struct domain_info_context _dinfo = { .guest_width = guest_width };
> +    struct domain_info_context *dinfo = &_dinfo;
> +    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
> +                                   live_shinfo, live_p2m, pfnp, 0);
> +}
> +
> +int
> +xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
> +                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                              unsigned long *pfnp)
> +{
> +    struct domain_info_context _dinfo = { .guest_width = guest_width };
> +    struct domain_info_context *dinfo = &_dinfo;
> +    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
> +                                   live_shinfo, live_p2m, pfnp, 1);
> +}
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
> new file mode 100644
> index 0000000..3a6be2a
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.h
> @@ -0,0 +1,60 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2012 Citrix Systems
> + *
> + */
> +
> +#ifndef XC_CORE_ARM_H
> +#define XC_CORE_ARM_H
> +
> +#define ELF_ARCH_DATA           ELFDATA2LSB
> +#define ELF_ARCH_MACHINE        EM_ARM
> +
> +struct xc_core_arch_context {
> +    /* nothing */
> +};
> +
> +#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
> +                                                                (0)
> +#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn);
> +static inline int
> +xc_core_arch_context_get_shdr(xc_interface *xch,
> +                              struct xc_core_arch_context *arch_ctxt, 
> +                              struct xc_core_section_headers *sheaders,
> +                              struct xc_core_strtab *strtab,
> +                              uint64_t *filesz, uint64_t offset)
> +{
> +    *filesz = 0;
> +    return 0;
> +}
> +
> +#endif /* XC_CORE_ARM_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> index e6fd488..3ee8c59 100644
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -83,6 +83,10 @@
>  #define xen_mb()   asm volatile ("mf" ::: "memory")
>  #define xen_rmb()  asm volatile ("mf" ::: "memory")
>  #define xen_wmb()  asm volatile ("mf" ::: "memory")
> +#elif defined(__arm__)
> +#define xen_mb()   asm volatile ("dmb" : : : "memory")
> +#define xen_rmb()  asm volatile ("dmb" : : : "memory")
> +#define xen_wmb()  asm volatile ("dmb" : : : "memory")
>  #else
>  #error "Define barriers"
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:04:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyNd-0000v1-Lz; Mon, 13 Feb 2012 16:03:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RwyNc-0000uh-7F
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:03:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329149022!11324134!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23479 invoked from network); 13 Feb 2012 16:03:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:03:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181516309"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:03:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	11:03:25 -0500
Message-ID: <4F39344B.5070504@citrix.com>
Date: Mon, 13 Feb 2012 16:03:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Subject: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

XenServer6.0 (Xen 4.1.1) has had a support escalation against it for
Cisco C210 M2 servers.  I do not have access to any of these servers, so
cant debug the issue myself.

The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it. 
In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
directed EOI support must use the old IO-APIC ack method.

A hypervisor with this check disabled (i.e. never checking for, or
enabling directed EOI) seems to make the system stable again (5 days
stable now, as opposed to a hang due to lost interrupts once every few
hours before).

First of all, I have discovered that forcing "ioapic_ack=new" does not
have the indented effect, because verify_local_APIC trashes it, even if
the user has specified the ack method.  I intend to send a patch to fix
this in due course.

However, as for the main issue, I cant work out any logical reason why
directed EOI would not work with the new ack mode.  I am still trying to
work out the differences in the code path incase I have missed something
subtle, but I wondered if anyone on the list has more knowledge of these
intricacies than me?  Either way, it appears that there is a bug on the
codepath with directed EOI and old ack method.

Thanks in advance,

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:04:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:04:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyNd-0000v1-Lz; Mon, 13 Feb 2012 16:03:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RwyNc-0000uh-7F
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:03:52 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329149022!11324134!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23479 invoked from network); 13 Feb 2012 16:03:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:03:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181516309"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:03:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	11:03:25 -0500
Message-ID: <4F39344B.5070504@citrix.com>
Date: Mon, 13 Feb 2012 16:03:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Subject: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

XenServer6.0 (Xen 4.1.1) has had a support escalation against it for
Cisco C210 M2 servers.  I do not have access to any of these servers, so
cant debug the issue myself.

The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it. 
In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
directed EOI support must use the old IO-APIC ack method.

A hypervisor with this check disabled (i.e. never checking for, or
enabling directed EOI) seems to make the system stable again (5 days
stable now, as opposed to a hang due to lost interrupts once every few
hours before).

First of all, I have discovered that forcing "ioapic_ack=new" does not
have the indented effect, because verify_local_APIC trashes it, even if
the user has specified the ack method.  I intend to send a patch to fix
this in due course.

However, as for the main issue, I cant work out any logical reason why
directed EOI would not work with the new ack mode.  I am still trying to
work out the differences in the code path incase I have missed something
subtle, but I wondered if anyone on the list has more knowledge of these
intricacies than me?  Either way, it appears that there is a bug on the
codepath with directed EOI and old ack method.

Thanks in advance,

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:08:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwyRO-0001Ar-3y; Mon, 13 Feb 2012 16:07:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RwyRM-0001Af-6O
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:07:44 +0000
Received: from [85.158.139.83:26805] by server-6.bemta-5.messagelabs.com id
	AE/D7-04784-F45393F4; Mon, 13 Feb 2012 16:07:43 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329149261!14818379!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6187 invoked from network); 13 Feb 2012 16:07:42 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-15.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 16:07:42 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q1DG7YER013501;
	Mon, 13 Feb 2012 11:07:34 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q1DG7YrV018262;
	Mon, 13 Feb 2012 11:07:34 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012021311073306184 ; Mon, 13 Feb 2012 11:07:33 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
Date: Mon, 13 Feb 2012 11:07:33 -0500
Message-Id: <CD4F91FF-5855-4CD6-8CC6-22A279435754@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
	<1329145577.31256.116.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

My compiler (Fedora 16) is happy with that.


Sincerely,

John
----
On Feb 13, 2012, at 10:06 AM, Ian Campbell wrote:

> On Mon, 2012-02-13 at 14:53 +0000, John McDermott CIV wrote:
>> Ian,
>> 
>> So like this?
> I was thinking more like the following, e..g change all the test_* DEBUG
> into print (for consistency) and make the init_xenbus messages more
> useful while also using the unused var.
> 
> Only tested with my compiler which does not complain in the same way as
> yours.
> 
> Ian.
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329145492 0
> # Node ID 858955a31cf51baef86c885af3db7fc85a04ec17
> # Parent  4ed7fb2c7bd837a33ef7abbd5fbef6cc4c9992df
> minios: Remove unused variables warnings
> 
> s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
> and always print the IRQ and MFN used by the xenbus on init.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 4ed7fb2c7bd8 -r 858955a31cf5 extras/mini-os/xenbus/xenbus.c
> --- a/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 13:00:36 2012 +0000
> +++ b/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 15:04:52 2012 +0000
> @@ -328,7 +328,6 @@ static int allocate_xenbus_id(void)
> void init_xenbus(void)
> {
>     int err;
> -    printk("Initialising xenbus\n");
>     DEBUG("init_xenbus called.\n");
>     xenstore_buf = mfn_to_virt(start_info.store_mfn);
>     create_thread("xenstore", xenbus_thread_func, NULL);
> @@ -337,7 +336,8 @@ void init_xenbus(void)
> 		      xenbus_evtchn_handler,
>               NULL);
>     unmask_evtchn(start_info.store_evtchn);
> -    DEBUG("xenbus on irq %d\n", err);
> +    printk("xenbus initialised on irq %d mfn %#lx\n",
> +	   err, start_info.store_mfn);
> }
> 
> void fini_xenbus(void)
> @@ -478,7 +478,7 @@ static void xenbus_debug_msg(const char 
>     struct xsd_sockmsg *reply;
> 
>     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
> -    DEBUG("Got a reply, type %d, id %d, len %d.\n",
> +    printk("Got a reply, type %d, id %d, len %d.\n",
>             reply->type, reply->req_id, reply->len);
> }
> 
> @@ -752,16 +752,16 @@ static void do_ls_test(const char *pre)
>     char **dirs, *msg;
>     int x;
> 
> -    DEBUG("ls %s...\n", pre);
> +    printk("ls %s...\n", pre);
>     msg = xenbus_ls(XBT_NIL, pre, &dirs);
>     if (msg) {
> -	DEBUG("Error in xenbus ls: %s\n", msg);
> +	printk("Error in xenbus ls: %s\n", msg);
> 	free(msg);
> 	return;
>     }
>     for (x = 0; dirs[x]; x++) 
>     {
> -        DEBUG("ls %s[%d] -> %s\n", pre, x, dirs[x]);
> +        printk("ls %s[%d] -> %s\n", pre, x, dirs[x]);
>         free(dirs[x]);
>     }
>     free(dirs);
> @@ -770,68 +770,68 @@ static void do_ls_test(const char *pre)
> static void do_read_test(const char *path)
> {
>     char *res, *msg;
> -    DEBUG("Read %s...\n", path);
> +    printk("Read %s...\n", path);
>     msg = xenbus_read(XBT_NIL, path, &res);
>     if (msg) {
> -	DEBUG("Error in xenbus read: %s\n", msg);
> +	printk("Error in xenbus read: %s\n", msg);
> 	free(msg);
> 	return;
>     }
> -    DEBUG("Read %s -> %s.\n", path, res);
> +    printk("Read %s -> %s.\n", path, res);
>     free(res);
> }
> 
> static void do_write_test(const char *path, const char *val)
> {
>     char *msg;
> -    DEBUG("Write %s to %s...\n", val, path);
> +    printk("Write %s to %s...\n", val, path);
>     msg = xenbus_write(XBT_NIL, path, val);
>     if (msg) {
> -	DEBUG("Result %s\n", msg);
> +	printk("Result %s\n", msg);
> 	free(msg);
>     } else {
> -	DEBUG("Success.\n");
> +	printk("Success.\n");
>     }
> }
> 
> static void do_rm_test(const char *path)
> {
>     char *msg;
> -    DEBUG("rm %s...\n", path);
> +    printk("rm %s...\n", path);
>     msg = xenbus_rm(XBT_NIL, path);
>     if (msg) {
> -	DEBUG("Result %s\n", msg);
> +	printk("Result %s\n", msg);
> 	free(msg);
>     } else {
> -	DEBUG("Success.\n");
> +	printk("Success.\n");
>     }
> }
> 
> /* Simple testing thing */
> void test_xenbus(void)
> {
> -    DEBUG("Doing xenbus test.\n");
> +    printk("Doing xenbus test.\n");
>     xenbus_debug_msg("Testing xenbus...\n");
> 
> -    DEBUG("Doing ls test.\n");
> +    printk("Doing ls test.\n");
>     do_ls_test("device");
>     do_ls_test("device/vif");
>     do_ls_test("device/vif/0");
> 
> -    DEBUG("Doing read test.\n");
> +    printk("Doing read test.\n");
>     do_read_test("device/vif/0/mac");
>     do_read_test("device/vif/0/backend");
> 
> -    DEBUG("Doing write test.\n");
> +    printk("Doing write test.\n");
>     do_write_test("device/vif/0/flibble", "flobble");
>     do_read_test("device/vif/0/flibble");
>     do_write_test("device/vif/0/flibble", "widget");
>     do_read_test("device/vif/0/flibble");
> 
> -    DEBUG("Doing rm test.\n");
> +    printk("Doing rm test.\n");
>     do_rm_test("device/vif/0/flibble");
>     do_read_test("device/vif/0/flibble");
> -    DEBUG("(Should have said ENOENT)\n");
> +    printk("(Should have said ENOENT)\n");
> }
> 
> /*
> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:08:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwyRO-0001Ar-3y; Mon, 13 Feb 2012 16:07:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1RwyRM-0001Af-6O
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:07:44 +0000
Received: from [85.158.139.83:26805] by server-6.bemta-5.messagelabs.com id
	AE/D7-04784-F45393F4; Mon, 13 Feb 2012 16:07:43 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329149261!14818379!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6187 invoked from network); 13 Feb 2012 16:07:42 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-15.tower-182.messagelabs.com with SMTP;
	13 Feb 2012 16:07:42 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q1DG7YER013501;
	Mon, 13 Feb 2012 11:07:34 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q1DG7YrV018262;
	Mon, 13 Feb 2012 11:07:34 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012021311073306184 ; Mon, 13 Feb 2012 11:07:33 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
Date: Mon, 13 Feb 2012 11:07:33 -0500
Message-Id: <CD4F91FF-5855-4CD6-8CC6-22A279435754@nrl.navy.mil>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
	<1329145577.31256.116.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

My compiler (Fedora 16) is happy with that.


Sincerely,

John
----
On Feb 13, 2012, at 10:06 AM, Ian Campbell wrote:

> On Mon, 2012-02-13 at 14:53 +0000, John McDermott CIV wrote:
>> Ian,
>> 
>> So like this?
> I was thinking more like the following, e..g change all the test_* DEBUG
> into print (for consistency) and make the init_xenbus messages more
> useful while also using the unused var.
> 
> Only tested with my compiler which does not complain in the same way as
> yours.
> 
> Ian.
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329145492 0
> # Node ID 858955a31cf51baef86c885af3db7fc85a04ec17
> # Parent  4ed7fb2c7bd837a33ef7abbd5fbef6cc4c9992df
> minios: Remove unused variables warnings
> 
> s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
> and always print the IRQ and MFN used by the xenbus on init.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 4ed7fb2c7bd8 -r 858955a31cf5 extras/mini-os/xenbus/xenbus.c
> --- a/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 13:00:36 2012 +0000
> +++ b/extras/mini-os/xenbus/xenbus.c	Mon Feb 13 15:04:52 2012 +0000
> @@ -328,7 +328,6 @@ static int allocate_xenbus_id(void)
> void init_xenbus(void)
> {
>     int err;
> -    printk("Initialising xenbus\n");
>     DEBUG("init_xenbus called.\n");
>     xenstore_buf = mfn_to_virt(start_info.store_mfn);
>     create_thread("xenstore", xenbus_thread_func, NULL);
> @@ -337,7 +336,8 @@ void init_xenbus(void)
> 		      xenbus_evtchn_handler,
>               NULL);
>     unmask_evtchn(start_info.store_evtchn);
> -    DEBUG("xenbus on irq %d\n", err);
> +    printk("xenbus initialised on irq %d mfn %#lx\n",
> +	   err, start_info.store_mfn);
> }
> 
> void fini_xenbus(void)
> @@ -478,7 +478,7 @@ static void xenbus_debug_msg(const char 
>     struct xsd_sockmsg *reply;
> 
>     reply = xenbus_msg_reply(XS_DEBUG, 0, req, ARRAY_SIZE(req));
> -    DEBUG("Got a reply, type %d, id %d, len %d.\n",
> +    printk("Got a reply, type %d, id %d, len %d.\n",
>             reply->type, reply->req_id, reply->len);
> }
> 
> @@ -752,16 +752,16 @@ static void do_ls_test(const char *pre)
>     char **dirs, *msg;
>     int x;
> 
> -    DEBUG("ls %s...\n", pre);
> +    printk("ls %s...\n", pre);
>     msg = xenbus_ls(XBT_NIL, pre, &dirs);
>     if (msg) {
> -	DEBUG("Error in xenbus ls: %s\n", msg);
> +	printk("Error in xenbus ls: %s\n", msg);
> 	free(msg);
> 	return;
>     }
>     for (x = 0; dirs[x]; x++) 
>     {
> -        DEBUG("ls %s[%d] -> %s\n", pre, x, dirs[x]);
> +        printk("ls %s[%d] -> %s\n", pre, x, dirs[x]);
>         free(dirs[x]);
>     }
>     free(dirs);
> @@ -770,68 +770,68 @@ static void do_ls_test(const char *pre)
> static void do_read_test(const char *path)
> {
>     char *res, *msg;
> -    DEBUG("Read %s...\n", path);
> +    printk("Read %s...\n", path);
>     msg = xenbus_read(XBT_NIL, path, &res);
>     if (msg) {
> -	DEBUG("Error in xenbus read: %s\n", msg);
> +	printk("Error in xenbus read: %s\n", msg);
> 	free(msg);
> 	return;
>     }
> -    DEBUG("Read %s -> %s.\n", path, res);
> +    printk("Read %s -> %s.\n", path, res);
>     free(res);
> }
> 
> static void do_write_test(const char *path, const char *val)
> {
>     char *msg;
> -    DEBUG("Write %s to %s...\n", val, path);
> +    printk("Write %s to %s...\n", val, path);
>     msg = xenbus_write(XBT_NIL, path, val);
>     if (msg) {
> -	DEBUG("Result %s\n", msg);
> +	printk("Result %s\n", msg);
> 	free(msg);
>     } else {
> -	DEBUG("Success.\n");
> +	printk("Success.\n");
>     }
> }
> 
> static void do_rm_test(const char *path)
> {
>     char *msg;
> -    DEBUG("rm %s...\n", path);
> +    printk("rm %s...\n", path);
>     msg = xenbus_rm(XBT_NIL, path);
>     if (msg) {
> -	DEBUG("Result %s\n", msg);
> +	printk("Result %s\n", msg);
> 	free(msg);
>     } else {
> -	DEBUG("Success.\n");
> +	printk("Success.\n");
>     }
> }
> 
> /* Simple testing thing */
> void test_xenbus(void)
> {
> -    DEBUG("Doing xenbus test.\n");
> +    printk("Doing xenbus test.\n");
>     xenbus_debug_msg("Testing xenbus...\n");
> 
> -    DEBUG("Doing ls test.\n");
> +    printk("Doing ls test.\n");
>     do_ls_test("device");
>     do_ls_test("device/vif");
>     do_ls_test("device/vif/0");
> 
> -    DEBUG("Doing read test.\n");
> +    printk("Doing read test.\n");
>     do_read_test("device/vif/0/mac");
>     do_read_test("device/vif/0/backend");
> 
> -    DEBUG("Doing write test.\n");
> +    printk("Doing write test.\n");
>     do_write_test("device/vif/0/flibble", "flobble");
>     do_read_test("device/vif/0/flibble");
>     do_write_test("device/vif/0/flibble", "widget");
>     do_read_test("device/vif/0/flibble");
> 
> -    DEBUG("Doing rm test.\n");
> +    printk("Doing rm test.\n");
>     do_rm_test("device/vif/0/flibble");
>     do_read_test("device/vif/0/flibble");
> -    DEBUG("(Should have said ENOENT)\n");
> +    printk("(Should have said ENOENT)\n");
> }
> 
> /*
> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:11:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyUc-0001Mc-Pg; Mon, 13 Feb 2012 16:11:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyUb-0001MK-8G
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:11:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329149458!11703049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5847 invoked from network); 13 Feb 2012 16:10:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:10:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:10:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:10:58 +0000
Message-ID: <1329149456.31256.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:10:56 +0000
In-Reply-To: <1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/10] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_dom_arm.c.

This bit:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Also provide empty implementations of xc_domain_save, xc_domain_restore
> and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
> set.

Less sure about this bit.

Is the content of xc_hvm_build x86 specific? ia64 seems to have it's own
version in tools/libxc/ia64/xc_ia64_hvm_build.c. (I guess ia64 does not
define CONFG_HVM, despite apparently supporting HVM? Otherwise I don't
see how the tools/libxc/Makefile stuff could work)

Perhaps xc_hvm_build should go to xc_x86_hvm_build.c and
xc_x86_arm_build.c should have stubs?

Also xc_hvm_build.c has public functions other than the one you have
stubbed out in it. Should stub them too?

The migrate case seems more like a temporary band-aid since we will
eventually want to support that on ARM -- I guess there's no quick hack
to make it compile since we'd need to define all sorts of things we
aren't ready to define yet?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/Makefile       |   15 ++++++++++--
>  tools/libxc/xc_dom_arm.c   |   49 ++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_nohvm.c     |   31 +++++++++++++++++++++++++++
>  tools/libxc/xc_nomigrate.c |   40 +++++++++++++++++++++++++++++++++++
>  4 files changed, 132 insertions(+), 3 deletions(-)
>  create mode 100644 tools/libxc/xc_dom_arm.c
>  create mode 100644 tools/libxc/xc_nohvm.c
>  create mode 100644 tools/libxc/xc_nomigrate.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index f2e1ba7..57ceee6 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -42,9 +42,17 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
>  
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
> -GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
> +ifeq ($(CONFIG_MIGRATE),y)
> +GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
> +GUEST_SRCS-y += xc_offline_page.c xc_compression.c
> +else
> +GUEST_SRCS-y += xc_nomigrate.c
> +endif
> +ifeq ($(CONFIG_HVM),y)
> +GUEST_SRCS-y += xc_hvm_build.c
> +else
> +GUEST_SRCS-y += xc_nohvm.c
> +endif
>  
>  vpath %.c ../../xen/common/libelf
>  CFLAGS += -I../../xen/common/libelf
> @@ -62,6 +70,7 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
>  GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
> +GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
>  
>  OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
>  
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> new file mode 100644
> index 0000000..bdd28e1
> --- /dev/null
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -0,0 +1,49 @@
> +/*
> + * Xen domain builder -- ARM
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +#include <inttypes.h>
> +#include <xen/xen.h>
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +
> +int arch_setup_meminit(struct xc_dom_image *dom)
> +{
> +    return -ENOSYS;
> +}
> +
> +int arch_setup_bootearly(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +
> +int arch_setup_bootlate(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_nohvm.c b/tools/libxc/xc_nohvm.c
> new file mode 100644
> index 0000000..a899f7c
> --- /dev/null
> +++ b/tools/libxc/xc_nohvm.c
> @@ -0,0 +1,31 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_hvm_build_target_mem(xc_interface *xch,
> +                           uint32_t domid,
> +                           int memsize,
> +                           int target,
> +                           const char *image_name)
> +{
> +    return -ENOSYS;
> +}
> diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
> new file mode 100644
> index 0000000..63090e0
> --- /dev/null
> +++ b/tools/libxc/xc_nomigrate.c
> @@ -0,0 +1,40 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
> +                   uint32_t max_factor, uint32_t flags,
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_generationid_addr)
> +{
> +    return -ENOSYS;
> +}
> +
> +int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> +                      unsigned int store_evtchn, unsigned long *store_mfn,
> +                      unsigned int console_evtchn, unsigned long *console_mfn,
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int no_incr_generationid,
> +                      unsigned long *vm_generationid_addr)
> +{
> +    return -ENOSYS;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:11:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyUc-0001Mc-Pg; Mon, 13 Feb 2012 16:11:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyUb-0001MK-8G
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:11:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329149458!11703049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5847 invoked from network); 13 Feb 2012 16:10:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:10:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:10:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:10:58 +0000
Message-ID: <1329149456.31256.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:10:56 +0000
In-Reply-To: <1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/10] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_dom_arm.c.

This bit:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Also provide empty implementations of xc_domain_save, xc_domain_restore
> and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
> set.

Less sure about this bit.

Is the content of xc_hvm_build x86 specific? ia64 seems to have it's own
version in tools/libxc/ia64/xc_ia64_hvm_build.c. (I guess ia64 does not
define CONFG_HVM, despite apparently supporting HVM? Otherwise I don't
see how the tools/libxc/Makefile stuff could work)

Perhaps xc_hvm_build should go to xc_x86_hvm_build.c and
xc_x86_arm_build.c should have stubs?

Also xc_hvm_build.c has public functions other than the one you have
stubbed out in it. Should stub them too?

The migrate case seems more like a temporary band-aid since we will
eventually want to support that on ARM -- I guess there's no quick hack
to make it compile since we'd need to define all sorts of things we
aren't ready to define yet?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/Makefile       |   15 ++++++++++--
>  tools/libxc/xc_dom_arm.c   |   49 ++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_nohvm.c     |   31 +++++++++++++++++++++++++++
>  tools/libxc/xc_nomigrate.c |   40 +++++++++++++++++++++++++++++++++++
>  4 files changed, 132 insertions(+), 3 deletions(-)
>  create mode 100644 tools/libxc/xc_dom_arm.c
>  create mode 100644 tools/libxc/xc_nohvm.c
>  create mode 100644 tools/libxc/xc_nomigrate.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index f2e1ba7..57ceee6 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -42,9 +42,17 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
>  
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
> -GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
> +ifeq ($(CONFIG_MIGRATE),y)
> +GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
> +GUEST_SRCS-y += xc_offline_page.c xc_compression.c
> +else
> +GUEST_SRCS-y += xc_nomigrate.c
> +endif
> +ifeq ($(CONFIG_HVM),y)
> +GUEST_SRCS-y += xc_hvm_build.c
> +else
> +GUEST_SRCS-y += xc_nohvm.c
> +endif
>  
>  vpath %.c ../../xen/common/libelf
>  CFLAGS += -I../../xen/common/libelf
> @@ -62,6 +70,7 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
>  GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
> +GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
>  
>  OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
>  
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> new file mode 100644
> index 0000000..bdd28e1
> --- /dev/null
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -0,0 +1,49 @@
> +/*
> + * Xen domain builder -- ARM
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +#include <inttypes.h>
> +#include <xen/xen.h>
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +
> +int arch_setup_meminit(struct xc_dom_image *dom)
> +{
> +    return -ENOSYS;
> +}
> +
> +int arch_setup_bootearly(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +
> +int arch_setup_bootlate(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_nohvm.c b/tools/libxc/xc_nohvm.c
> new file mode 100644
> index 0000000..a899f7c
> --- /dev/null
> +++ b/tools/libxc/xc_nohvm.c
> @@ -0,0 +1,31 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_hvm_build_target_mem(xc_interface *xch,
> +                           uint32_t domid,
> +                           int memsize,
> +                           int target,
> +                           const char *image_name)
> +{
> +    return -ENOSYS;
> +}
> diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
> new file mode 100644
> index 0000000..63090e0
> --- /dev/null
> +++ b/tools/libxc/xc_nomigrate.c
> @@ -0,0 +1,40 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
> +                   uint32_t max_factor, uint32_t flags,
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_generationid_addr)
> +{
> +    return -ENOSYS;
> +}
> +
> +int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> +                      unsigned int store_evtchn, unsigned long *store_mfn,
> +                      unsigned int console_evtchn, unsigned long *console_mfn,
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int no_incr_generationid,
> +                      unsigned long *vm_generationid_addr)
> +{
> +    return -ENOSYS;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyV2-0001P2-6r; Mon, 13 Feb 2012 16:11:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyV0-0001OG-Rb
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:11:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329149483!10474931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31128 invoked from network); 13 Feb 2012 16:11:23 -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;
	13 Feb 2012 16:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:11:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:11:22 +0000
Message-ID: <1329149480.31256.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:11:20 +0000
In-Reply-To: <1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
> functions are only available on x86, so ifdef the new cpuid related
> function in libxl_json.c.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/Makefile        |    1 +
>  tools/libxl/libxl_json.c    |    8 ++++++++
>  tools/libxl/libxl_nocpuid.c |    2 +-
>  3 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 06764f2..41b6ac4 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
>  endif
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
>  LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
>  
>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_netbsd.o
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index 5418683..e48e83a 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -140,6 +140,7 @@ out:
>      return s;
>  }
>  
> +#if defined(__i386__) || defined(__x86_64__)
>  yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                  libxl_cpuid_policy_list *pcpuid)
>  {
> @@ -199,6 +200,13 @@ empty:
>  out:
>      return s;
>  }
> +#else
> +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> +                                libxl_cpuid_policy_list *pcpuid)
> +{
> +    return 0;
> +}
> +#endif
>  
>  yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
>  {
> diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
> index 9e52f8d..313d55b 100644
> --- a/tools/libxl/libxl_nocpuid.c
> +++ b/tools/libxl/libxl_nocpuid.c
> @@ -14,7 +14,7 @@
>  
>  #include "libxl_internal.h"
>  
> -void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
> +void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
>  {
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyV2-0001P2-6r; Mon, 13 Feb 2012 16:11:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyV0-0001OG-Rb
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:11:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329149483!10474931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31128 invoked from network); 13 Feb 2012 16:11:23 -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;
	13 Feb 2012 16:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:11:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:11:22 +0000
Message-ID: <1329149480.31256.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:11:20 +0000
In-Reply-To: <1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
> functions are only available on x86, so ifdef the new cpuid related
> function in libxl_json.c.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/Makefile        |    1 +
>  tools/libxl/libxl_json.c    |    8 ++++++++
>  tools/libxl/libxl_nocpuid.c |    2 +-
>  3 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 06764f2..41b6ac4 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
>  endif
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
>  LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
>  
>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_netbsd.o
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index 5418683..e48e83a 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -140,6 +140,7 @@ out:
>      return s;
>  }
>  
> +#if defined(__i386__) || defined(__x86_64__)
>  yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                  libxl_cpuid_policy_list *pcpuid)
>  {
> @@ -199,6 +200,13 @@ empty:
>  out:
>      return s;
>  }
> +#else
> +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> +                                libxl_cpuid_policy_list *pcpuid)
> +{
> +    return 0;
> +}
> +#endif
>  
>  yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
>  {
> diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
> index 9e52f8d..313d55b 100644
> --- a/tools/libxl/libxl_nocpuid.c
> +++ b/tools/libxl/libxl_nocpuid.c
> @@ -14,7 +14,7 @@
>  
>  #include "libxl_internal.h"
>  
> -void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
> +void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
>  {
>  }
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:16:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyZD-0001qv-Jn; Mon, 13 Feb 2012 16:15:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyZC-0001qR-TH
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:15:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329149744!11291513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14180 invoked from network); 13 Feb 2012 16:15:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:15:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:15:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:15:44 +0000
Message-ID: <1329149741.31256.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:15:41 +0000
In-Reply-To: <1328875368-9608-8-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-8-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 08/10] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I'm a little surprised we don't have some more "utils" type place to put
these but since it was already like this:

Acked-by: Ian Campbell <Ian.campbell@citrix.com>

> ---
>  tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
>  1 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
> index 6c0dc3d..45d473e 100644
> --- a/tools/memshr/bidir-hash.c
> +++ b/tools/memshr/bidir-hash.c
> @@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
>  } while (0)
>  static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
>  static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
> +#elif defined(__arm__)
> +static inline void atomic_inc(uint32_t *v)
> +{
> +        unsigned long tmp;
> +        int result;
> +
> +        __asm__ __volatile__("@ atomic_add\n"
> +"1:     ldrex   %0, [%3]\n"
> +"       add     %0, %0, #1\n"
> +"       strex   %1, %0, [%3]\n"
> +"       teq     %1, #0\n"
> +"       bne     1b"
> +        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
> +        : "r" (v)
> +        : "cc");
> +}
> +static inline void atomic_dec(uint32_t *v)
> +{
> +        unsigned long tmp;
> +        int result;
> +
> +        __asm__ __volatile__("@ atomic_sub\n"
> +"1:     ldrex   %0, [%3]\n"
> +"       sub     %0, %0, #1\n"
> +"       strex   %1, %0, [%3]\n"
> +"       teq     %1, #0\n"
> +"       bne     1b"
> +        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
> +        : "r" (v)
> +        : "cc");
> +}
>  #else /* __x86__ */
>  static inline void atomic_inc(uint32_t *v)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:16:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwyZD-0001qv-Jn; Mon, 13 Feb 2012 16:15:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyZC-0001qR-TH
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:15:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329149744!11291513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14180 invoked from network); 13 Feb 2012 16:15:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:15:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:15:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:15:44 +0000
Message-ID: <1329149741.31256.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:15:41 +0000
In-Reply-To: <1328875368-9608-8-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-8-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 08/10] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

I'm a little surprised we don't have some more "utils" type place to put
these but since it was already like this:

Acked-by: Ian Campbell <Ian.campbell@citrix.com>

> ---
>  tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
>  1 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
> index 6c0dc3d..45d473e 100644
> --- a/tools/memshr/bidir-hash.c
> +++ b/tools/memshr/bidir-hash.c
> @@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
>  } while (0)
>  static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
>  static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
> +#elif defined(__arm__)
> +static inline void atomic_inc(uint32_t *v)
> +{
> +        unsigned long tmp;
> +        int result;
> +
> +        __asm__ __volatile__("@ atomic_add\n"
> +"1:     ldrex   %0, [%3]\n"
> +"       add     %0, %0, #1\n"
> +"       strex   %1, %0, [%3]\n"
> +"       teq     %1, #0\n"
> +"       bne     1b"
> +        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
> +        : "r" (v)
> +        : "cc");
> +}
> +static inline void atomic_dec(uint32_t *v)
> +{
> +        unsigned long tmp;
> +        int result;
> +
> +        __asm__ __volatile__("@ atomic_sub\n"
> +"1:     ldrex   %0, [%3]\n"
> +"       sub     %0, %0, #1\n"
> +"       strex   %1, %0, [%3]\n"
> +"       teq     %1, #0\n"
> +"       bne     1b"
> +        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
> +        : "r" (v)
> +        : "cc");
> +}
>  #else /* __x86__ */
>  static inline void atomic_inc(uint32_t *v)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:16:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwyZt-0001xT-1q; Mon, 13 Feb 2012 16:16:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyZr-0001xB-7g
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:16:31 +0000
Received: from [85.158.139.83:34566] by server-10.bemta-5.messagelabs.com id
	61/67-26909-E57393F4; Mon, 13 Feb 2012 16:16:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329149788!14849294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31349 invoked from network); 13 Feb 2012 16:16:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:16:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:16:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:16:28 +0000
Message-ID: <1329149787.31256.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:16:27 +0000
In-Reply-To: <1328875368-9608-9-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-9-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 09/10] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xentrace/xenctx.c |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index a12cc21..530ef65 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -60,6 +60,12 @@ int disp_ar_regs;
>  int disp_br_regs;
>  int disp_bank_regs;
>  int disp_tlb;
> +
> +#elif defined(__arm__)
> +#define NO_TRANSLATION
> +typedef uint64_t guest_word_t;
> +#define FMT_32B_WORD "%08llx"
> +#define FMT_64B_WORD "%016llx"
>  #endif
>  
>  struct symbol {
> @@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
>              print_tr(i, &tr->dtrs[i]);
>      }
>  }
> +#elif defined(__arm__)
> +static void print_ctx(vcpu_guest_context_any_t *ctx)
> +{
> +    /* XXX: properly implement this */
> +    print_symbol(0);
> +}
>  #endif
>  
>  #ifndef NO_TRANSLATION



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:16:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwyZt-0001xT-1q; Mon, 13 Feb 2012 16:16:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwyZr-0001xB-7g
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:16:31 +0000
Received: from [85.158.139.83:34566] by server-10.bemta-5.messagelabs.com id
	61/67-26909-E57393F4; Mon, 13 Feb 2012 16:16:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329149788!14849294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31349 invoked from network); 13 Feb 2012 16:16:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:16:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:16:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:16:28 +0000
Message-ID: <1329149787.31256.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:16:27 +0000
In-Reply-To: <1328875368-9608-9-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-9-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 09/10] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xentrace/xenctx.c |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index a12cc21..530ef65 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -60,6 +60,12 @@ int disp_ar_regs;
>  int disp_br_regs;
>  int disp_bank_regs;
>  int disp_tlb;
> +
> +#elif defined(__arm__)
> +#define NO_TRANSLATION
> +typedef uint64_t guest_word_t;
> +#define FMT_32B_WORD "%08llx"
> +#define FMT_64B_WORD "%016llx"
>  #endif
>  
>  struct symbol {
> @@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
>              print_tr(i, &tr->dtrs[i]);
>      }
>  }
> +#elif defined(__arm__)
> +static void print_ctx(vcpu_guest_context_any_t *ctx)
> +{
> +    /* XXX: properly implement this */
> +    print_symbol(0);
> +}
>  #endif
>  
>  #ifndef NO_TRANSLATION



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:18:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwybw-0002Hw-Tt; Mon, 13 Feb 2012 16:18:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwybw-0002HL-70
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:18:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329149913!13170152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22383 invoked from network); 13 Feb 2012 16:18:34 -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;
	13 Feb 2012 16:18:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:18:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:18:33 +0000
Message-ID: <1329149911.31256.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:18:31 +0000
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:01 +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series allows tools/ to compile on ARM, mostly providing an
> empty implementation for all the arch specific functions that are needed.

#1 committed.

#2 I will commit if someone else acks (since I wrote it).

#3-4 are not arm specific and should be committed by IanJ, no need for
me to ack since I wrote them but it would be useful for you (or someone
else) to explicitly ack them for his benefit.

#5 is pretty arm specific, however I've only Acked and not committed
since it may as well go in with the rest.

#6 partially acked + commented upon

#7-9 acked but left for a more appropriate committer to pick up (ianj
mostly)

#10 I'm the author, also for IanJ to commit I think.

(For "Ian J to commit" read "... or I'll do it with his Ack+OK")

Ian.

> 
> 
> Changes in v2:
> 
> - rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;
> 
> - dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
> xen-unstable;
> 
> - define xen_callback_t as uint64_t;
> 
> - define guest_word_t as uint64_t.
> 
> 
> 
> Ian Campbell (4):
>       arm: add stub hvm/save.h
>       libxl: do not allocate e820 for non x86 guests.
>       blktap2/libvhd: Build shared objects using -fPIC.
>       tools: only compile libfsimage/xfs on X86
> 
> Stefano Stabellini (6):
>       arm: few missing #define
>       arm: compile libxc
>       arm: compile libxenguest
>       arm: compile libxl
>       arm: compile memshr
>       arm: compile xentrace
>       arm: compile xentrace
> 
>  tools/blktap2/vhd/lib/Makefile         |   13 +++-
>  tools/libfsimage/Makefile              |    3 +-
>  tools/libxc/Makefile                   |   16 ++++-
>  tools/libxc/xc_core.h                  |    2 +
>  tools/libxc/xc_core_arm.c              |  106 ++++++++++++++++++++++++++++++++
>  tools/libxc/xc_core_arm.h              |   60 ++++++++++++++++++
>  tools/libxc/xc_dom_arm.c               |   49 +++++++++++++++
>  tools/libxc/xc_nohvm.c                 |   31 +++++++++
>  tools/libxc/xc_nomigrate.c             |   40 ++++++++++++
>  tools/libxc/xenctrl.h                  |    4 +
>  tools/libxl/Makefile                   |    1 +
>  tools/libxl/libxl_create.c             |    3 +-
>  tools/libxl/libxl_json.c               |    8 +++
>  tools/libxl/libxl_nocpuid.c            |    2 +-
>  tools/libxl/libxl_pci.c                |    2 +
>  tools/memshr/bidir-hash.c              |   31 +++++++++
>  tools/xentrace/xenctx.c                |   12 ++++
>  xen/include/public/arch-arm.h          |    2 +
>  xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++
>  xen/include/public/hvm/save.h          |    2 +
>  xen/include/public/io/protocols.h      |    3 +
>  21 files changed, 419 insertions(+), 10 deletions(-)
> 
> A git tree based on a22587ae517170a7755d3a88611ae0e2d5bb555e, is available here:
> 
> git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-2
> 
> Cheers,
> 
> Stefano



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:18:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwybw-0002Hw-Tt; Mon, 13 Feb 2012 16:18:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwybw-0002HL-70
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:18:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329149913!13170152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22383 invoked from network); 13 Feb 2012 16:18:34 -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;
	13 Feb 2012 16:18:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10667499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:18:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:18:33 +0000
Message-ID: <1329149911.31256.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 13 Feb 2012 16:18:31 +0000
In-Reply-To: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-10 at 12:01 +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series allows tools/ to compile on ARM, mostly providing an
> empty implementation for all the arch specific functions that are needed.

#1 committed.

#2 I will commit if someone else acks (since I wrote it).

#3-4 are not arm specific and should be committed by IanJ, no need for
me to ack since I wrote them but it would be useful for you (or someone
else) to explicitly ack them for his benefit.

#5 is pretty arm specific, however I've only Acked and not committed
since it may as well go in with the rest.

#6 partially acked + commented upon

#7-9 acked but left for a more appropriate committer to pick up (ianj
mostly)

#10 I'm the author, also for IanJ to commit I think.

(For "Ian J to commit" read "... or I'll do it with his Ack+OK")

Ian.

> 
> 
> Changes in v2:
> 
> - rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;
> 
> - dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
> xen-unstable;
> 
> - define xen_callback_t as uint64_t;
> 
> - define guest_word_t as uint64_t.
> 
> 
> 
> Ian Campbell (4):
>       arm: add stub hvm/save.h
>       libxl: do not allocate e820 for non x86 guests.
>       blktap2/libvhd: Build shared objects using -fPIC.
>       tools: only compile libfsimage/xfs on X86
> 
> Stefano Stabellini (6):
>       arm: few missing #define
>       arm: compile libxc
>       arm: compile libxenguest
>       arm: compile libxl
>       arm: compile memshr
>       arm: compile xentrace
>       arm: compile xentrace
> 
>  tools/blktap2/vhd/lib/Makefile         |   13 +++-
>  tools/libfsimage/Makefile              |    3 +-
>  tools/libxc/Makefile                   |   16 ++++-
>  tools/libxc/xc_core.h                  |    2 +
>  tools/libxc/xc_core_arm.c              |  106 ++++++++++++++++++++++++++++++++
>  tools/libxc/xc_core_arm.h              |   60 ++++++++++++++++++
>  tools/libxc/xc_dom_arm.c               |   49 +++++++++++++++
>  tools/libxc/xc_nohvm.c                 |   31 +++++++++
>  tools/libxc/xc_nomigrate.c             |   40 ++++++++++++
>  tools/libxc/xenctrl.h                  |    4 +
>  tools/libxl/Makefile                   |    1 +
>  tools/libxl/libxl_create.c             |    3 +-
>  tools/libxl/libxl_json.c               |    8 +++
>  tools/libxl/libxl_nocpuid.c            |    2 +-
>  tools/libxl/libxl_pci.c                |    2 +
>  tools/memshr/bidir-hash.c              |   31 +++++++++
>  tools/xentrace/xenctx.c                |   12 ++++
>  xen/include/public/arch-arm.h          |    2 +
>  xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++
>  xen/include/public/hvm/save.h          |    2 +
>  xen/include/public/io/protocols.h      |    3 +
>  21 files changed, 419 insertions(+), 10 deletions(-)
> 
> A git tree based on a22587ae517170a7755d3a88611ae0e2d5bb555e, is available here:
> 
> git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-2
> 
> Cheers,
> 
> Stefano



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9H-0003V1-M5; Mon, 13 Feb 2012 16:53:07 +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 1Rwz9F-0003U9-Sw
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6833 invoked from network); 13 Feb 2012 16:50:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901523"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:02 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHn025169;	Mon, 13 Feb 2012 08:53:01 -0800
MIME-Version: 1.0
X-Mercurial-Node: 41738bf7d28dd74018a160712da69bfc02b7f4b5
Message-ID: <41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148133 0
# Node ID 41738bf7d28dd74018a160712da69bfc02b7f4b5
# Parent  cb563f911986275f93ea8dd003b69d44d8745adf
libxl: add new "defbool" built in type.

This type is a but like a "boolean" but with a third state "default" (so really
I suppose it's a tristate).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r cb563f911986 -r 41738bf7d28d tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:48:53 2012 +0000
@@ -20,7 +20,8 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
+             "libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
@@ -55,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    "
               ty.pass_arg(v, parent is None))
     elif ty.typename in ["bool"]:
         s += "%s = rand() %% 2;\n" % v
+    elif ty.typename in ["libxl_defbool"]:
+        s += "libxl_defbool_set(%s, !!rand() %% 1);\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
     elif ty.private:
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:53 2012 +0000
@@ -184,6 +184,47 @@ void libxl_key_value_list_dispose(libxl_
     free(kvl);
 }
 
+#define LIBXL__DEFBOOL_DEFAULT (0)
+#define LIBXL__DEFBOOL_FALSE (-1)
+#define LIBXL__DEFBOOL_TRUE (1)
+
+void libxl_defbool_set(libxl_defbool *db, bool b)
+{
+    db->val = b ? LIBXL__DEFBOOL_TRUE : LIBXL__DEFBOOL_FALSE;
+}
+
+void libxl_defbool_unset(libxl_defbool *db)
+{
+    db->val = LIBXL__DEFBOOL_DEFAULT;
+}
+
+bool libxl_defbool_is_default(libxl_defbool db)
+{
+    return !db.val;
+}
+
+void libxl_defbool_setdefault(libxl_defbool *db, bool b)
+{
+    if (libxl_defbool_is_default(*db))
+        libxl_defbool_set(db, b);
+}
+
+bool libxl_defbool_val(libxl_defbool db)
+{
+    assert(!libxl_defbool_is_default(db));
+    return db.val > 0;
+}
+
+const char *libxl_defbool_to_string(libxl_defbool b)
+{
+    if (b.val < 0)
+        return "False";
+    else if (b.val > 0)
+        return "True";
+    else
+        return "<default>";
+}
+
 /******************************************************************************/
 
 
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:53 2012 +0000
@@ -250,6 +250,30 @@ typedef struct {
 struct libxl_event;
 typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
 
+/*
+ * A boolean variable with an explicit default state.
+ *
+ * Users should treat this struct as opaque and use the following
+ * defined macros and accessor functions.
+ *
+ * To allow users of the library to naively select all defaults this
+ * state is represented as 0. False is < 0 and True is > 0.
+ */
+typedef struct {
+    int val;
+} libxl_defbool;
+
+void libxl_defbool_set(libxl_defbool *db, bool b);
+/* Resets to default */
+void libxl_defbool_unset(libxl_defbool *db);
+/* Sets db only if it is currently == default */
+void libxl_defbool_setdefault(libxl_defbool *db, bool b);
+bool libxl_defbool_is_default(libxl_defbool db);
+/* db must not be == default */
+bool libxl_defbool_val(libxl_defbool db);
+
+const char *libxl_defbool_to_string(libxl_defbool b);
+
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_json.c	Mon Feb 13 15:48:53 2012 +0000
@@ -85,6 +85,12 @@ yajl_gen_status libxl__yajl_gen_enum(yaj
 /*
  * YAJL generators for builtin libxl types.
  */
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
+                                       libxl_defbool *db)
+{
+    return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
+}
+
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:53 2012 +0000
@@ -5,6 +5,8 @@
 
 namespace("libxl_")
 
+libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
+
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxlu_cfg.c	Mon Feb 13 15:48:53 2012 +0000
@@ -237,6 +237,17 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b,
+                     int dont_warn)
+{
+    int ret;
+    long l;
+
+    ret = xlu_cfg_get_long(cfg, n, &l, dont_warn);
+    if (ret) return ret;
+    libxl_defbool_set(b, !!l);
+    return 0;
+}
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxlutil.h	Mon Feb 13 15:48:53 2012 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r cb563f911986 -r 41738bf7d28d tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
@@ -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_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),
     "libxl_mac":            ("int array",              "Mac_val(gc, lg, &%(c)s, %(o)s)",    "Val_mac(&%(c)s)"),
diff -r cb563f911986 -r 41738bf7d28d tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Mon Feb 13 15:48:53 2012 +0000
@@ -195,6 +195,33 @@ static int Uuid_val(caml_gc *gc, struct 
 	CAMLreturn(0);
 }
 
+static value Val_defbool(libxl_defbool c_val)
+{
+	CAMLparam0();
+	CAMLlocal1(v);
+
+	if (libxl_defbool_is_default(c_val))
+		v = Val_none;
+	else {
+		bool b = libxl_defbool_val(c_val);
+		v = Val_some(b ? Val_bool(true) : Val_bool(false));
+	}
+	CAMLreturn(v);
+}
+
+static libxl_defbool Defbool_val(value v)
+{
+	CAMLparam1(v);
+	libxl_defbool db;
+	if (v == Val_none)
+		libxl_defbool_unset(&db);
+	else {
+		bool b = Bool_val(Some_val(v));
+		libxl_defbool_set(&db, b);
+	}
+	return db;
+}
+
 static value Val_hwcap(libxl_hwcap *c_val)
 {
 	CAMLparam0();
diff -r cb563f911986 -r 41738bf7d28d tools/python/genwrap.py
--- a/tools/python/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/python/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
@@ -4,11 +4,13 @@ import sys,os
 
 import idl
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
 
 def py_type(ty):
     if ty == idl.bool:
         return TYPE_BOOL
+    if ty.typename == "libxl_defbool":
+        return TYPE_DEFBOOL
     if isinstance(ty, idl.Enumeration):
         return TYPE_UINT
     if isinstance(ty, idl.Number):
@@ -44,6 +46,8 @@ def py_decls(ty):
         for f in ty.fields:
             if py_type(f.type) is not None:
                 continue
+            if py_type(f.type) == TYPE_DEFBOOL:
+                continue
             if ty.marshal_out():
                 l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
                     fsanitize(f.type.typename), f.type.typename, f.name))
@@ -62,6 +66,8 @@ def py_attrib_get(ty, f):
         l.append('    ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
         l.append('    Py_INCREF(ret);')
         l.append('    return ret;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_get(&self->obj.%s);'%f.name)
     elif t == TYPE_INT:
         l.append('    return genwrap__ll_get(self->obj.%s);'%f.name)
     elif t == TYPE_UINT:
@@ -85,6 +91,8 @@ def py_attrib_set(ty, f):
     if t == TYPE_BOOL:
         l.append('    self->obj.%s = (NULL == v || Py_None == v || Py_False == v) ? 0 : 1;'%f.name)
         l.append('    return 0;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
     elif t == TYPE_UINT or t == TYPE_INT:
         l.append('    %slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
         l.append('    int ret;')
@@ -275,6 +283,8 @@ _hidden PyObject *genwrap__ull_get(unsig
 _hidden int genwrap__ull_set(PyObject *v, unsigned long long *val, unsigned long long mask);
 _hidden PyObject *genwrap__ll_get(long long val);
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
+_hidden PyObject *genwrap__defbool_get(libxl_defbool *db);
+_hidden int genwrap__defbool_set(PyObject *v, libxl_defbool *db);
 
 """ % " ".join(sys.argv))
     for ty in [ty for ty in types if isinstance(ty, idl.Aggregate)]:
diff -r cb563f911986 -r 41738bf7d28d tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Feb 13 15:48:53 2012 +0000
@@ -156,6 +156,21 @@ int genwrap__ll_set(PyObject *v, long lo
     return 0;
 }
 
+PyObject *genwrap__defbool_get(libxl_defbool *db)
+{
+    PyObject *ret;
+    ret = libxl_defbool_val(*db) ? Py_True : Py_False;
+    Py_INCREF(ret);
+    return ret;
+}
+
+int genwrap__defbool_set(PyObject *v, libxl_defbool *db)
+{
+    bool val = !(NULL == v || Py_None == v || Py_False == v);
+    libxl_defbool_set(db, val);
+    return 0;
+}
+
 static int fixed_bytearray_set(PyObject *v, uint8_t *ptr, size_t len)
 {
     char *tmp;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9J-0003Wf-W2; Mon, 13 Feb 2012 16:53:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9H-0003T2-TL
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329151980!14379488!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28903 invoked from network); 13 Feb 2012 16:53:01 -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;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901515"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:57 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHh025169;	Mon, 13 Feb 2012 08:52:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2fef3eddec04dd3a56d651d15adcd1f72a201a1e
Message-ID: <2fef3eddec04dd3a56d6.1329151973@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 23] libxl: introduce a descriminating
 default value for memkb fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 2fef3eddec04dd3a56d651d15adcd1f72a201a1e
# Parent  1ace05e41c39f3620b423056004b709965ff6d80
libxl: introduce a descriminating default value for memkb fields.

Consitently make such fields 64 bit values as used by dominfo.

It is not clear if ->video_memkb and/or shadow_memkb shouldn't be part of
->u.hvm but I have not changed that here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
@@ -197,6 +197,7 @@ static void libxl_string_list_rand_init(
 }
 """)
     for ty in builtins + types:
+        if isinstance(ty, idl.Number): continue
         if ty.typename not in handcoded:
             f.write("static void %s_rand_init(%s);\n" % \
                     (ty.typename,
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -253,6 +253,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
+#define LIBXL_MEMKB_DEFAULT ~0ULL
 
 #include "_libxl_types.h"
 
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -70,19 +70,20 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_memkb = 32 * 1024;
-    b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
-    b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
+    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
+
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
@@ -132,8 +133,17 @@ int libxl__domain_build_info_setdefault(
         libxl_cpumap_set_any(&b_info->cpumap);
     }
 
+    if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->max_memkb = 32 * 1024;
+    if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->target_memkb = b_info->max_memkb;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->video_memkb = 8 * 1024;
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
@@ -152,6 +162,10 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->u.pv.slack_memkb = 0;
         break;
     default:
         LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Feb 13 15:48:52 2012 +0000
@@ -129,11 +129,12 @@ int libxl__build_post(libxl__gc *gc, uin
 
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
-    ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
+    ents[1] = libxl__sprintf(gc, "%"PRId64, info->max_memkb);
     ents[2] = "memory/target";
-    ents[3] = libxl__sprintf(gc, "%d", info->target_memkb - info->video_memkb);
+    ents[3] = libxl__sprintf(gc, "%"PRId64,
+                             info->target_memkb - info->video_memkb);
     ents[4] = "memory/videoram";
-    ents[5] = libxl__sprintf(gc, "%d", info->video_memkb);
+    ents[5] = libxl__sprintf(gc, "%"PRId64, info->video_memkb);
     ents[6] = "domid";
     ents[7] = libxl__sprintf(gc, "%d", domid);
     ents[8] = "store/port";
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
@@ -18,6 +18,12 @@ libxl_file_reference = Builtin("file_ref
 libxl_hwcap = Builtin("hwcap", passby=PASS_BY_REFERENCE)
 
 #
+# Specific integer types
+#
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
+
+#
 # Constants / Enumerations
 #
 
@@ -147,9 +153,9 @@ libxl_dominfo = Struct("dominfo",[
     # Otherwise set to a value guaranteed not to clash with any valid
     # SHUTDOWN_* constant.
     ("shutdown_reason", uint8),
-    ("current_memkb",   uint64),
-    ("shared_memkb", uint64),
-    ("max_memkb",   uint64),
+    ("current_memkb",   MemKB),
+    ("shared_memkb", MemKB),
+    ("max_memkb",   MemKB),
     ("cpu_time",    uint64),
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
@@ -205,10 +211,10 @@ libxl_domain_build_info = Struct("domain
     ("cur_vcpus",       integer),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
-    ("max_memkb",       uint32),
-    ("target_memkb",    uint32),
-    ("video_memkb",     uint32),
-    ("shadow_memkb",    uint32),
+    ("max_memkb",       MemKB),
+    ("target_memkb",    MemKB),
+    ("video_memkb",     MemKB),
+    ("shadow_memkb",    MemKB),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
@@ -262,7 +268,7 @@ libxl_domain_build_info = Struct("domain
                                        ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
-                                      ("slack_memkb", uint32),
+                                      ("slack_memkb", MemKB),
                                       ("bootloader", string),
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 15:48:52 2012 +0000
@@ -21,6 +21,7 @@
 #include "libxl_osdeps.h"
 
 #include <stdlib.h>
+#include <inttypes.h>
 
 #include "libxl.h"
 #include "libxl_utils.h"
@@ -68,8 +69,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
+    printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
@@ -88,8 +89,8 @@ void printf_info_sexp(int domid, libxl_d
     case LIBXL_DOMAIN_TYPE_HVM:
         printf("\t\t(hvm\n");
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
         printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
         printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
         printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9H-0003V1-M5; Mon, 13 Feb 2012 16:53:07 +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 1Rwz9F-0003U9-Sw
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6833 invoked from network); 13 Feb 2012 16:50:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901523"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:02 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHn025169;	Mon, 13 Feb 2012 08:53:01 -0800
MIME-Version: 1.0
X-Mercurial-Node: 41738bf7d28dd74018a160712da69bfc02b7f4b5
Message-ID: <41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148133 0
# Node ID 41738bf7d28dd74018a160712da69bfc02b7f4b5
# Parent  cb563f911986275f93ea8dd003b69d44d8745adf
libxl: add new "defbool" built in type.

This type is a but like a "boolean" but with a third state "default" (so really
I suppose it's a tristate).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r cb563f911986 -r 41738bf7d28d tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:48:53 2012 +0000
@@ -20,7 +20,8 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
+             "libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
@@ -55,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    "
               ty.pass_arg(v, parent is None))
     elif ty.typename in ["bool"]:
         s += "%s = rand() %% 2;\n" % v
+    elif ty.typename in ["libxl_defbool"]:
+        s += "libxl_defbool_set(%s, !!rand() %% 1);\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
     elif ty.private:
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:53 2012 +0000
@@ -184,6 +184,47 @@ void libxl_key_value_list_dispose(libxl_
     free(kvl);
 }
 
+#define LIBXL__DEFBOOL_DEFAULT (0)
+#define LIBXL__DEFBOOL_FALSE (-1)
+#define LIBXL__DEFBOOL_TRUE (1)
+
+void libxl_defbool_set(libxl_defbool *db, bool b)
+{
+    db->val = b ? LIBXL__DEFBOOL_TRUE : LIBXL__DEFBOOL_FALSE;
+}
+
+void libxl_defbool_unset(libxl_defbool *db)
+{
+    db->val = LIBXL__DEFBOOL_DEFAULT;
+}
+
+bool libxl_defbool_is_default(libxl_defbool db)
+{
+    return !db.val;
+}
+
+void libxl_defbool_setdefault(libxl_defbool *db, bool b)
+{
+    if (libxl_defbool_is_default(*db))
+        libxl_defbool_set(db, b);
+}
+
+bool libxl_defbool_val(libxl_defbool db)
+{
+    assert(!libxl_defbool_is_default(db));
+    return db.val > 0;
+}
+
+const char *libxl_defbool_to_string(libxl_defbool b)
+{
+    if (b.val < 0)
+        return "False";
+    else if (b.val > 0)
+        return "True";
+    else
+        return "<default>";
+}
+
 /******************************************************************************/
 
 
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:53 2012 +0000
@@ -250,6 +250,30 @@ typedef struct {
 struct libxl_event;
 typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
 
+/*
+ * A boolean variable with an explicit default state.
+ *
+ * Users should treat this struct as opaque and use the following
+ * defined macros and accessor functions.
+ *
+ * To allow users of the library to naively select all defaults this
+ * state is represented as 0. False is < 0 and True is > 0.
+ */
+typedef struct {
+    int val;
+} libxl_defbool;
+
+void libxl_defbool_set(libxl_defbool *db, bool b);
+/* Resets to default */
+void libxl_defbool_unset(libxl_defbool *db);
+/* Sets db only if it is currently == default */
+void libxl_defbool_setdefault(libxl_defbool *db, bool b);
+bool libxl_defbool_is_default(libxl_defbool db);
+/* db must not be == default */
+bool libxl_defbool_val(libxl_defbool db);
+
+const char *libxl_defbool_to_string(libxl_defbool b);
+
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_json.c	Mon Feb 13 15:48:53 2012 +0000
@@ -85,6 +85,12 @@ yajl_gen_status libxl__yajl_gen_enum(yaj
 /*
  * YAJL generators for builtin libxl types.
  */
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
+                                       libxl_defbool *db)
+{
+    return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
+}
+
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:53 2012 +0000
@@ -5,6 +5,8 @@
 
 namespace("libxl_")
 
+libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
+
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxlu_cfg.c	Mon Feb 13 15:48:53 2012 +0000
@@ -237,6 +237,17 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b,
+                     int dont_warn)
+{
+    int ret;
+    long l;
+
+    ret = xlu_cfg_get_long(cfg, n, &l, dont_warn);
+    if (ret) return ret;
+    libxl_defbool_set(b, !!l);
+    return 0;
+}
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r cb563f911986 -r 41738bf7d28d tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxlutil.h	Mon Feb 13 15:48:53 2012 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r cb563f911986 -r 41738bf7d28d tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
@@ -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_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),
     "libxl_mac":            ("int array",              "Mac_val(gc, lg, &%(c)s, %(o)s)",    "Val_mac(&%(c)s)"),
diff -r cb563f911986 -r 41738bf7d28d tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Mon Feb 13 15:48:53 2012 +0000
@@ -195,6 +195,33 @@ static int Uuid_val(caml_gc *gc, struct 
 	CAMLreturn(0);
 }
 
+static value Val_defbool(libxl_defbool c_val)
+{
+	CAMLparam0();
+	CAMLlocal1(v);
+
+	if (libxl_defbool_is_default(c_val))
+		v = Val_none;
+	else {
+		bool b = libxl_defbool_val(c_val);
+		v = Val_some(b ? Val_bool(true) : Val_bool(false));
+	}
+	CAMLreturn(v);
+}
+
+static libxl_defbool Defbool_val(value v)
+{
+	CAMLparam1(v);
+	libxl_defbool db;
+	if (v == Val_none)
+		libxl_defbool_unset(&db);
+	else {
+		bool b = Bool_val(Some_val(v));
+		libxl_defbool_set(&db, b);
+	}
+	return db;
+}
+
 static value Val_hwcap(libxl_hwcap *c_val)
 {
 	CAMLparam0();
diff -r cb563f911986 -r 41738bf7d28d tools/python/genwrap.py
--- a/tools/python/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/python/genwrap.py	Mon Feb 13 15:48:53 2012 +0000
@@ -4,11 +4,13 @@ import sys,os
 
 import idl
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
 
 def py_type(ty):
     if ty == idl.bool:
         return TYPE_BOOL
+    if ty.typename == "libxl_defbool":
+        return TYPE_DEFBOOL
     if isinstance(ty, idl.Enumeration):
         return TYPE_UINT
     if isinstance(ty, idl.Number):
@@ -44,6 +46,8 @@ def py_decls(ty):
         for f in ty.fields:
             if py_type(f.type) is not None:
                 continue
+            if py_type(f.type) == TYPE_DEFBOOL:
+                continue
             if ty.marshal_out():
                 l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
                     fsanitize(f.type.typename), f.type.typename, f.name))
@@ -62,6 +66,8 @@ def py_attrib_get(ty, f):
         l.append('    ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
         l.append('    Py_INCREF(ret);')
         l.append('    return ret;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_get(&self->obj.%s);'%f.name)
     elif t == TYPE_INT:
         l.append('    return genwrap__ll_get(self->obj.%s);'%f.name)
     elif t == TYPE_UINT:
@@ -85,6 +91,8 @@ def py_attrib_set(ty, f):
     if t == TYPE_BOOL:
         l.append('    self->obj.%s = (NULL == v || Py_None == v || Py_False == v) ? 0 : 1;'%f.name)
         l.append('    return 0;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
     elif t == TYPE_UINT or t == TYPE_INT:
         l.append('    %slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
         l.append('    int ret;')
@@ -275,6 +283,8 @@ _hidden PyObject *genwrap__ull_get(unsig
 _hidden int genwrap__ull_set(PyObject *v, unsigned long long *val, unsigned long long mask);
 _hidden PyObject *genwrap__ll_get(long long val);
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
+_hidden PyObject *genwrap__defbool_get(libxl_defbool *db);
+_hidden int genwrap__defbool_set(PyObject *v, libxl_defbool *db);
 
 """ % " ".join(sys.argv))
     for ty in [ty for ty in types if isinstance(ty, idl.Aggregate)]:
diff -r cb563f911986 -r 41738bf7d28d tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Mon Feb 13 15:48:53 2012 +0000
@@ -156,6 +156,21 @@ int genwrap__ll_set(PyObject *v, long lo
     return 0;
 }
 
+PyObject *genwrap__defbool_get(libxl_defbool *db)
+{
+    PyObject *ret;
+    ret = libxl_defbool_val(*db) ? Py_True : Py_False;
+    Py_INCREF(ret);
+    return ret;
+}
+
+int genwrap__defbool_set(PyObject *v, libxl_defbool *db)
+{
+    bool val = !(NULL == v || Py_None == v || Py_False == v);
+    libxl_defbool_set(db, val);
+    return 0;
+}
+
 static int fixed_bytearray_set(PyObject *v, uint8_t *ptr, size_t len)
 {
     char *tmp;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9J-0003Wf-W2; Mon, 13 Feb 2012 16:53:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9H-0003T2-TL
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329151980!14379488!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28903 invoked from network); 13 Feb 2012 16:53:01 -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;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901515"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:57 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHh025169;	Mon, 13 Feb 2012 08:52:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2fef3eddec04dd3a56d651d15adcd1f72a201a1e
Message-ID: <2fef3eddec04dd3a56d6.1329151973@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 23] libxl: introduce a descriminating
 default value for memkb fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 2fef3eddec04dd3a56d651d15adcd1f72a201a1e
# Parent  1ace05e41c39f3620b423056004b709965ff6d80
libxl: introduce a descriminating default value for memkb fields.

Consitently make such fields 64 bit values as used by dominfo.

It is not clear if ->video_memkb and/or shadow_memkb shouldn't be part of
->u.hvm but I have not changed that here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
@@ -197,6 +197,7 @@ static void libxl_string_list_rand_init(
 }
 """)
     for ty in builtins + types:
+        if isinstance(ty, idl.Number): continue
         if ty.typename not in handcoded:
             f.write("static void %s_rand_init(%s);\n" % \
                     (ty.typename,
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -253,6 +253,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
+#define LIBXL_MEMKB_DEFAULT ~0ULL
 
 #include "_libxl_types.h"
 
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -70,19 +70,20 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_memkb = 32 * 1024;
-    b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
-    b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
+    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
+
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
@@ -132,8 +133,17 @@ int libxl__domain_build_info_setdefault(
         libxl_cpumap_set_any(&b_info->cpumap);
     }
 
+    if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->max_memkb = 32 * 1024;
+    if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->target_memkb = b_info->max_memkb;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->video_memkb = 8 * 1024;
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
@@ -152,6 +162,10 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->u.pv.slack_memkb = 0;
         break;
     default:
         LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Feb 13 15:48:52 2012 +0000
@@ -129,11 +129,12 @@ int libxl__build_post(libxl__gc *gc, uin
 
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
-    ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
+    ents[1] = libxl__sprintf(gc, "%"PRId64, info->max_memkb);
     ents[2] = "memory/target";
-    ents[3] = libxl__sprintf(gc, "%d", info->target_memkb - info->video_memkb);
+    ents[3] = libxl__sprintf(gc, "%"PRId64,
+                             info->target_memkb - info->video_memkb);
     ents[4] = "memory/videoram";
-    ents[5] = libxl__sprintf(gc, "%d", info->video_memkb);
+    ents[5] = libxl__sprintf(gc, "%"PRId64, info->video_memkb);
     ents[6] = "domid";
     ents[7] = libxl__sprintf(gc, "%d", domid);
     ents[8] = "store/port";
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
@@ -18,6 +18,12 @@ libxl_file_reference = Builtin("file_ref
 libxl_hwcap = Builtin("hwcap", passby=PASS_BY_REFERENCE)
 
 #
+# Specific integer types
+#
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
+
+#
 # Constants / Enumerations
 #
 
@@ -147,9 +153,9 @@ libxl_dominfo = Struct("dominfo",[
     # Otherwise set to a value guaranteed not to clash with any valid
     # SHUTDOWN_* constant.
     ("shutdown_reason", uint8),
-    ("current_memkb",   uint64),
-    ("shared_memkb", uint64),
-    ("max_memkb",   uint64),
+    ("current_memkb",   MemKB),
+    ("shared_memkb", MemKB),
+    ("max_memkb",   MemKB),
     ("cpu_time",    uint64),
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
@@ -205,10 +211,10 @@ libxl_domain_build_info = Struct("domain
     ("cur_vcpus",       integer),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
-    ("max_memkb",       uint32),
-    ("target_memkb",    uint32),
-    ("video_memkb",     uint32),
-    ("shadow_memkb",    uint32),
+    ("max_memkb",       MemKB),
+    ("target_memkb",    MemKB),
+    ("video_memkb",     MemKB),
+    ("shadow_memkb",    MemKB),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
@@ -262,7 +268,7 @@ libxl_domain_build_info = Struct("domain
                                        ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
-                                      ("slack_memkb", uint32),
+                                      ("slack_memkb", MemKB),
                                       ("bootloader", string),
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
diff -r 1ace05e41c39 -r 2fef3eddec04 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 15:48:52 2012 +0000
@@ -21,6 +21,7 @@
 #include "libxl_osdeps.h"
 
 #include <stdlib.h>
+#include <inttypes.h>
 
 #include "libxl.h"
 #include "libxl_utils.h"
@@ -68,8 +69,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
+    printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
@@ -88,8 +89,8 @@ void printf_info_sexp(int domid, libxl_d
     case LIBXL_DOMAIN_TYPE_HVM:
         printf("\t\t(hvm\n");
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
         printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
         printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
         printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9L-0003YQ-Cn; Mon, 13 Feb 2012 16:53:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9I-0003TM-Hk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329151980!14379488!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28929 invoked from network); 13 Feb 2012 16:53:02 -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;
	13 Feb 2012 16:53:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901517"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHk025169;	Mon, 13 Feb 2012 08:52:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: a72b3dca661fd1a0b40d8252d56017355afe3b38
Message-ID: <a72b3dca661fd1a0b40d.1329151976@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 23] libxl: vfb/vkb: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID a72b3dca661fd1a0b40d8252d56017355afe3b38
# Parent  69c16a2a8927d81acc0cf0e127a5a4b7a9a1a886
libxl: vfb/vkb: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -2100,9 +2100,13 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb)
+void libxl_device_vkb_init(libxl_device_vkb *vkb)
 {
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
+}
+
+int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
+{
     return 0;
 }
 
@@ -2128,6 +2132,9 @@ int libxl_device_vkb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vkb_setdefault(gc, vkb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
@@ -2205,12 +2212,11 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
+void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
-    vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
@@ -2218,6 +2224,15 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     vfb->sdl.opengl = 0;
     vfb->sdl.display = NULL;
     vfb->sdl.xauthority = NULL;
+}
+
+int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
+{
+    if (!vfb->vnc.listen) {
+        vfb->vnc.listen = strdup("127.0.0.1");
+        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    }
+
     return 0;
 }
 
@@ -2242,6 +2257,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vfb_setdefault(gc, vfb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -540,7 +540,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
+void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -548,7 +548,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
+void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -594,9 +594,7 @@ static int do_domain_create(libxl__gc *g
         libxl__device_console_add(gc, domid, &console, &state);
         libxl_device_console_dispose(&console);
 
-        ret = libxl_device_vkb_init(ctx, &vkb);
-        if ( ret )
-            goto error_out;
+        libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
@@ -610,8 +610,8 @@ static int libxl__vfb_and_vkb_from_hvm_g
     if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
         return ERROR_INVAL;
 
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
+    libxl_device_vfb_init(vfb);
+    libxl_device_vkb_init(vkb);
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -194,6 +194,8 @@ _hidden int libxl__domain_build_info_set
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
+_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
+_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -933,12 +933,12 @@ skip:
 
             d_config->vfbs = (libxl_device_vfb *) realloc(d_config->vfbs, sizeof(libxl_device_vfb) * (d_config->num_vfbs + 1));
             vfb = d_config->vfbs + d_config->num_vfbs;
-            libxl_device_vfb_init(ctx, vfb);
+            libxl_device_vfb_init(vfb);
             vfb->devid = d_config->num_vfbs;
 
             d_config->vkbs = (libxl_device_vkb *) realloc(d_config->vkbs, sizeof(libxl_device_vkb) * (d_config->num_vkbs + 1));
             vkb = d_config->vkbs + d_config->num_vkbs;
-            libxl_device_vkb_init(ctx, vkb);
+            libxl_device_vkb_init(vkb);
             vkb->devid = d_config->num_vkbs;
 
             p = strtok(buf2, ",");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9F-0003U3-8b; Mon, 13 Feb 2012 16:53:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9D-0003S4-0j
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28655 invoked from network); 13 Feb 2012 16:52:56 -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;
	13 Feb 2012 16:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526854"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:55 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHf025169;	Mon, 13 Feb 2012 08:52:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 192eefb9e00e048333b01ee732a1b07071b90e7e
Message-ID: <192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 192eefb9e00e048333b01ee732a1b07071b90e7e
# Parent  d50d692ae52bca2d409415245e2fcd909259461a
libxl: drop 8M slack for PV guests.

As far as I can tell this serves no purpose. I think it relates to the old
8M to "account for backend allocations" which we used to add. This leaves a bit
of unpopulated space in the Pseudo-physical address space which can be used by
backends when mapping foreign memory. However 8M is not representative of that
any more and modern kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets just set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d50d692ae52b -r 192eefb9e00e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -107,7 +107,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
+        b_info->u.pv.slack_memkb = 0;
         break;
     default:
         abort();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9B-0003Sf-Cv; Mon, 13 Feb 2012 16:53: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 1Rwz99-0003Rk-VK
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329151951!65643141!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8581 invoked from network); 13 Feb 2012 16:52:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:52:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526847"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHd025169;	Mon, 13 Feb 2012 08:52:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: af0d151cd2d524f13a13e2fb85e727e8733dcd81
Message-ID: <af0d151cd2d524f13a13.1329151969@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 23] libxl: provide _init and _setdefault
 for libxl_domain_build_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148126 0
# Node ID af0d151cd2d524f13a13e2fb85e727e8733dcd81
# Parent  53d4e198863a29e204186ab10c8950c3bd4235a8
libxl: provide _init and _setdefault for libxl_domain_build_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:46 2012 +0000
@@ -2624,7 +2624,11 @@ int libxl_domain_need_memory(libxl_ctx *
                              uint32_t *need_memkb)
 {
     GC_INIT(ctx);
-    int rc = ERROR_INVAL;
+    int rc;
+
+    rc = libxl__domain_build_info_setdefault(gc, b_info);
+    if (rc) goto out;
+
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -2636,6 +2640,7 @@ int libxl_domain_need_memory(libxl_ctx *
         *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
         break;
     default:
+        rc = ERROR_INVAL;
         goto out;
     }
     if (*need_memkb % (2 * 1024))
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:46 2012 +0000
@@ -364,9 +364,8 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                          const libxl_domain_create_info *c_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:48:46 2012 +0000
@@ -346,6 +346,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     struct stat st_buf;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:46 2012 +0000
@@ -66,16 +66,10 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                                  const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_vcpus = 1;
-    b_info->cur_vcpus = 1;
-    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
-        return ERROR_NOMEM;
-    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
@@ -83,8 +77,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
-    b_info->device_model_version =
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
@@ -107,15 +99,9 @@ int libxl_init_build_info(libxl_ctx *ctx
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
-        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
-        b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.sdl.enable = 0;
-        b_info->u.hvm.sdl.opengl = 0;
-        b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.boot = strdup("cda");
         b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
         b_info->u.hvm.xen_platform_pci = 1;
@@ -124,7 +110,47 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.pv.slack_memkb = 8 * 1024;
         break;
     default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+        abort();
+    }
+}
+
+int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info)
+{
+    if (!b_info->device_model_version)
+        b_info->device_model_version =
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+    if (!b_info->max_vcpus)
+        b_info->max_vcpus = 1;
+    if (!b_info->cur_vcpus)
+        b_info->cur_vcpus = 1;
+
+    if (!b_info->cpumap.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
+            return ERROR_NOMEM;
+        libxl_cpumap_set_any(&b_info->cpumap);
+    }
+
+    switch (b_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        if (!b_info->u.hvm.boot) {
+            b_info->u.hvm.boot = strdup("cda");
+            if (!b_info->u.hvm.boot) return ERROR_NOMEM;
+        }
+
+        if (b_info->u.hvm.vnc.enable) {
+            if (!b_info->u.hvm.vnc.listen) {
+                b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+                if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
+            }
+        }
+
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        break;
+    default:
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                    "invalid domain type %s in create info",
                    libxl_domain_type_to_string(b_info->type));
         return ERROR_INVAL;
@@ -487,6 +513,8 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
+    if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:46 2012 +0000
@@ -707,13 +707,12 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
-    dm_config.b_info.type = dm_config.c_info.type;
+    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
-    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
@@ -736,6 +735,8 @@ static int libxl__create_stubdom(libxl__
 
     ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
     if (ret) goto out;
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:46 2012 +0000
@@ -189,6 +189,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  */
 _hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                         libxl_domain_create_info *c_info);
+_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:46 2012 +0000
@@ -586,8 +586,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_build_info(ctx, b_info, c_info))
-        exit(1);
+    libxl_domain_build_info_init(b_info, c_info);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -601,6 +600,11 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
@@ -615,6 +619,11 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         if (vcpupin_parse(buf2, &b_info->cpumap))
             exit(1);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9K-0003XH-IE; Mon, 13 Feb 2012 16:53:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9I-0003TG-8U
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29076 invoked from network); 13 Feb 2012 16:53:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526868"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHl025169;	Mon, 13 Feb 2012 08:52:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: b2934eb211360cdc6f996940410fd82d435ca059
Message-ID: <b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console
	internal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID b2934eb211360cdc6f996940410fd82d435ca059
# Parent  a72b3dca661fd1a0b40d8252d56017355afe3b38
libxl: make libxl_device_console internal

consoles are not directly exposed to users of the library and there are no API
functions for manipluating them (only the console_exec function). Rather than
commit to a particular API now make the type internal.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -2022,7 +2022,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
 
 /******************************************************************************/
 int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                              libxl_device_console *console,
+                              libxl__device_console *console,
                               libxl__domain_build_state *state)
 {
     flexarray_t *front;
@@ -2069,7 +2069,7 @@ int libxl__device_console_add(libxl__gc 
     flexarray_append(front, "limit");
     flexarray_append(front, libxl__sprintf(gc, "%d", LIBXL_XENCONSOLE_LIMIT));
     flexarray_append(front, "type");
-    if (console->consback == LIBXL_CONSOLE_BACKEND_XENCONSOLED)
+    if (console->consback == LIBXL__CONSOLE_BACKEND_XENCONSOLED)
         flexarray_append(front, "xenconsoled");
     else
         flexarray_append(front, "ioemu");
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -176,17 +176,16 @@ int libxl__domain_build_info_setdefault(
     return 0;
 }
 
-static int init_console_info(libxl_device_console *console, int dev_num)
+static int init_console_info(libxl__device_console *console, int dev_num)
 {
-    memset(console, 0x00, sizeof(libxl_device_console));
+    memset(console, 0x00, sizeof(libxl__device_console));
     console->devid = dev_num;
-    console->consback = LIBXL_CONSOLE_BACKEND_XENCONSOLED;
+    console->consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
     console->output = strdup("pty");
-    if ( NULL == console->output )
+    if (!console->output)
         return ERROR_NOMEM;
     return 0;
 }
-
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
                         uint32_t domid,
@@ -585,14 +584,14 @@ static int do_domain_create(libxl__gc *g
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
-        libxl_device_console console;
+        libxl__device_console console;
         libxl_device_vkb vkb;
 
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
@@ -610,7 +609,7 @@ static int do_domain_create(libxl__gc *g
     case LIBXL_DOMAIN_TYPE_PV:
     {
         int need_qemu = 0;
-        libxl_device_console console;
+        libxl__device_console console;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -626,10 +625,10 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_disks, &d_config->disks[0]);
 
         if (need_qemu)
-             console.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         if (need_qemu) {
             libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
@@ -682,7 +682,7 @@ static int libxl__create_stubdom(libxl__
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
-    libxl_device_console *console;
+    libxl__device_console *console;
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
@@ -814,7 +814,7 @@ retry_transaction:
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
-    console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
+    console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
     if (!console) {
         ret = ERROR_NOMEM;
         goto out_free;
@@ -822,7 +822,7 @@ retry_transaction:
 
     for (i = 0; i < num_console; i++) {
         console[i].devid = i;
-        console[i].consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+        console[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
         /* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
          * STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
          * STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
@@ -1084,7 +1084,7 @@ out:
 }
 
 int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks)
 {
@@ -1096,7 +1096,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
     }
 
     for (i = 0; i < nr_consoles; i++) {
-        if (consoles[i].consback == LIBXL_CONSOLE_BACKEND_IOEMU) {
+        if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
             ret = 1;
             goto out;
         }
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -661,7 +661,7 @@ _hidden int libxl__device_disk_dev_numbe
                                           int *pdisk, int *ppartition);
 
 _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                                      libxl_device_console *console,
+                                      libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
@@ -904,7 +904,7 @@ _hidden int libxl__create_xenpv_qemu(lib
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks);
   /* Caller must either: pass starting_r==0, or on successful
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
@@ -42,11 +42,6 @@ libxl_console_type = Enumeration("consol
     (2, "PV"),
     ])
 
-libxl_console_backend = Enumeration("console_backend", [
-    (1, "XENCONSOLED"),
-    (2, "IOEMU"),
-    ])
-
 libxl_disk_format = Enumeration("disk_format", [
     (0, "UNKNOWN"),
     (1, "QCOW"),
@@ -295,13 +290,6 @@ libxl_device_vkb = Struct("device_vkb", 
     ("devid", integer),
     ])
 
-libxl_device_console = Struct("device_console", [
-    ("backend_domid", libxl_domid),
-    ("devid", integer),
-    ("consback", libxl_console_backend),
-    ("output", string),
-    ])
-
 libxl_device_disk = Struct("device_disk", [
     ("backend_domid", libxl_domid),
     ("pdev_path", string),
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_types_internal.idl	Mon Feb 13 15:48:52 2012 +0000
@@ -1,5 +1,7 @@
 namespace("libxl__")
 
+libxl_domid = Builtin("domid", namespace="libxl_", json_fn = "yajl_gen_integer")
+
 libxl__qmp_message_type = Enumeration("qmp_message_type", [
     (1, "QMP"),
     (2, "return"),
@@ -17,3 +19,15 @@ libxl__device_kind = Enumeration("device
     (6, "VKBD"),
     (7, "CONSOLE"),
     ])
+
+libxl__console_backend = Enumeration("console_backend", [
+    (1, "XENCONSOLED"),
+    (2, "IOEMU"),
+    ])
+
+libxl__device_console = Struct("device_console", [
+    ("backend_domid", libxl_domid),
+    ("devid", integer),
+    ("consback", libxl__console_backend),
+    ("output", string),
+    ])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9J-0003W0-3u; Mon, 13 Feb 2012 16:53:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9H-0003So-9X
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14096 invoked from network); 13 Feb 2012 16:53:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901513"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHg025169;	Mon, 13 Feb 2012 08:52:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1ace05e41c39f3620b423056004b709965ff6d80
Message-ID: <1ace05e41c39f3620b42.1329151972@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 23] libxl: allow specification of testidl
	random seed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 1ace05e41c39f3620b423056004b709965ff6d80
# Parent  192eefb9e00e048333b01ee732a1b07071b90e7e
libxl: allow specification of testidl random seed.

Useful if you are interested in before/after results of changing the IDL or
generator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 192eefb9e00e -r 1ace05e41c39 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
@@ -1,5 +1,6 @@
 #!/usr/bin/python
 
+import os
 import sys
 import re
 import random
@@ -72,7 +73,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: gentest.py <idl> <implementation>"
         sys.exit(1)
 
-    random.seed()
+    random.seed(os.getenv('LIBXL_TESTIDL_SEED'))
 
     (builtins,types) = idl.parse(sys.argv[1])
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9L-0003Yr-Pg; Mon, 13 Feb 2012 16:53:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9J-0003Vx-HS
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7048 invoked from network); 13 Feb 2012 16:50:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901529"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:07 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHs025169;	Mon, 13 Feb 2012 08:53:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: ba3ab3558a5d84fef2676b82d641a04615a9d786
Message-ID: <ba3ab3558a5d84fef267.1329151984@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 18 of 23] libxl: do not explicitly initialise
 members of build info to zero
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150453 0
# Node ID ba3ab3558a5d84fef2676b82d641a04615a9d786
# Parent  d27c92eeeddc5e4c190a88ce282fb0155405a65e
libxl: do not explicitly initialise members of build info to zero

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d27c92eeeddc -r ba3ab3558a5d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
@@ -86,12 +85,7 @@ void libxl_domain_build_info_init(libxl_
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-
-        b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usbdevice = NULL;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9F-0003U3-8b; Mon, 13 Feb 2012 16:53:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9D-0003S4-0j
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28655 invoked from network); 13 Feb 2012 16:52:56 -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;
	13 Feb 2012 16:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526854"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:55 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHf025169;	Mon, 13 Feb 2012 08:52:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 192eefb9e00e048333b01ee732a1b07071b90e7e
Message-ID: <192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 192eefb9e00e048333b01ee732a1b07071b90e7e
# Parent  d50d692ae52bca2d409415245e2fcd909259461a
libxl: drop 8M slack for PV guests.

As far as I can tell this serves no purpose. I think it relates to the old
8M to "account for backend allocations" which we used to add. This leaves a bit
of unpopulated space in the Pseudo-physical address space which can be used by
backends when mapping foreign memory. However 8M is not representative of that
any more and modern kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets just set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d50d692ae52b -r 192eefb9e00e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -107,7 +107,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
+        b_info->u.pv.slack_memkb = 0;
         break;
     default:
         abort();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9B-0003Sf-Cv; Mon, 13 Feb 2012 16:53: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 1Rwz99-0003Rk-VK
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329151951!65643141!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8581 invoked from network); 13 Feb 2012 16:52:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:52:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526847"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHd025169;	Mon, 13 Feb 2012 08:52:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: af0d151cd2d524f13a13e2fb85e727e8733dcd81
Message-ID: <af0d151cd2d524f13a13.1329151969@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 23] libxl: provide _init and _setdefault
 for libxl_domain_build_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148126 0
# Node ID af0d151cd2d524f13a13e2fb85e727e8733dcd81
# Parent  53d4e198863a29e204186ab10c8950c3bd4235a8
libxl: provide _init and _setdefault for libxl_domain_build_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:46 2012 +0000
@@ -2624,7 +2624,11 @@ int libxl_domain_need_memory(libxl_ctx *
                              uint32_t *need_memkb)
 {
     GC_INIT(ctx);
-    int rc = ERROR_INVAL;
+    int rc;
+
+    rc = libxl__domain_build_info_setdefault(gc, b_info);
+    if (rc) goto out;
+
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -2636,6 +2640,7 @@ int libxl_domain_need_memory(libxl_ctx *
         *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
         break;
     default:
+        rc = ERROR_INVAL;
         goto out;
     }
     if (*need_memkb % (2 * 1024))
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:46 2012 +0000
@@ -364,9 +364,8 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                          const libxl_domain_create_info *c_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:48:46 2012 +0000
@@ -346,6 +346,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     struct stat st_buf;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:46 2012 +0000
@@ -66,16 +66,10 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                                  const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_vcpus = 1;
-    b_info->cur_vcpus = 1;
-    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
-        return ERROR_NOMEM;
-    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
@@ -83,8 +77,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
-    b_info->device_model_version =
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
@@ -107,15 +99,9 @@ int libxl_init_build_info(libxl_ctx *ctx
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
-        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
-        b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.sdl.enable = 0;
-        b_info->u.hvm.sdl.opengl = 0;
-        b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.boot = strdup("cda");
         b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
         b_info->u.hvm.xen_platform_pci = 1;
@@ -124,7 +110,47 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.pv.slack_memkb = 8 * 1024;
         break;
     default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+        abort();
+    }
+}
+
+int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info)
+{
+    if (!b_info->device_model_version)
+        b_info->device_model_version =
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+    if (!b_info->max_vcpus)
+        b_info->max_vcpus = 1;
+    if (!b_info->cur_vcpus)
+        b_info->cur_vcpus = 1;
+
+    if (!b_info->cpumap.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
+            return ERROR_NOMEM;
+        libxl_cpumap_set_any(&b_info->cpumap);
+    }
+
+    switch (b_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        if (!b_info->u.hvm.boot) {
+            b_info->u.hvm.boot = strdup("cda");
+            if (!b_info->u.hvm.boot) return ERROR_NOMEM;
+        }
+
+        if (b_info->u.hvm.vnc.enable) {
+            if (!b_info->u.hvm.vnc.listen) {
+                b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+                if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
+            }
+        }
+
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        break;
+    default:
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                    "invalid domain type %s in create info",
                    libxl_domain_type_to_string(b_info->type));
         return ERROR_INVAL;
@@ -487,6 +513,8 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
+    if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:46 2012 +0000
@@ -707,13 +707,12 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
-    dm_config.b_info.type = dm_config.c_info.type;
+    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
-    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
@@ -736,6 +735,8 @@ static int libxl__create_stubdom(libxl__
 
     ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
     if (ret) goto out;
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:46 2012 +0000
@@ -189,6 +189,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  */
 _hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                         libxl_domain_create_info *c_info);
+_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 53d4e198863a -r af0d151cd2d5 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:39 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:46 2012 +0000
@@ -586,8 +586,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_build_info(ctx, b_info, c_info))
-        exit(1);
+    libxl_domain_build_info_init(b_info, c_info);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -601,6 +600,11 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
@@ -615,6 +619,11 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         if (vcpupin_parse(buf2, &b_info->cpumap))
             exit(1);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9J-0003W0-3u; Mon, 13 Feb 2012 16:53:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9H-0003So-9X
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14096 invoked from network); 13 Feb 2012 16:53:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901513"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHg025169;	Mon, 13 Feb 2012 08:52:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1ace05e41c39f3620b423056004b709965ff6d80
Message-ID: <1ace05e41c39f3620b42.1329151972@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 23] libxl: allow specification of testidl
	random seed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 1ace05e41c39f3620b423056004b709965ff6d80
# Parent  192eefb9e00e048333b01ee732a1b07071b90e7e
libxl: allow specification of testidl random seed.

Useful if you are interested in before/after results of changing the IDL or
generator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 192eefb9e00e -r 1ace05e41c39 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:48:52 2012 +0000
@@ -1,5 +1,6 @@
 #!/usr/bin/python
 
+import os
 import sys
 import re
 import random
@@ -72,7 +73,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: gentest.py <idl> <implementation>"
         sys.exit(1)
 
-    random.seed()
+    random.seed(os.getenv('LIBXL_TESTIDL_SEED'))
 
     (builtins,types) = idl.parse(sys.argv[1])
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9L-0003YQ-Cn; Mon, 13 Feb 2012 16:53:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9I-0003TM-Hk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329151980!14379488!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28929 invoked from network); 13 Feb 2012 16:53:02 -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;
	13 Feb 2012 16:53:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901517"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHk025169;	Mon, 13 Feb 2012 08:52:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: a72b3dca661fd1a0b40d8252d56017355afe3b38
Message-ID: <a72b3dca661fd1a0b40d.1329151976@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 23] libxl: vfb/vkb: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID a72b3dca661fd1a0b40d8252d56017355afe3b38
# Parent  69c16a2a8927d81acc0cf0e127a5a4b7a9a1a886
libxl: vfb/vkb: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -2100,9 +2100,13 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb)
+void libxl_device_vkb_init(libxl_device_vkb *vkb)
 {
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
+}
+
+int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
+{
     return 0;
 }
 
@@ -2128,6 +2132,9 @@ int libxl_device_vkb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vkb_setdefault(gc, vkb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
@@ -2205,12 +2212,11 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
+void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
-    vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
@@ -2218,6 +2224,15 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     vfb->sdl.opengl = 0;
     vfb->sdl.display = NULL;
     vfb->sdl.xauthority = NULL;
+}
+
+int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
+{
+    if (!vfb->vnc.listen) {
+        vfb->vnc.listen = strdup("127.0.0.1");
+        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    }
+
     return 0;
 }
 
@@ -2242,6 +2257,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vfb_setdefault(gc, vfb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -540,7 +540,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
+void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -548,7 +548,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
+void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -594,9 +594,7 @@ static int do_domain_create(libxl__gc *g
         libxl__device_console_add(gc, domid, &console, &state);
         libxl_device_console_dispose(&console);
 
-        ret = libxl_device_vkb_init(ctx, &vkb);
-        if ( ret )
-            goto error_out;
+        libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
@@ -610,8 +610,8 @@ static int libxl__vfb_and_vkb_from_hvm_g
     if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
         return ERROR_INVAL;
 
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
+    libxl_device_vfb_init(vfb);
+    libxl_device_vkb_init(vkb);
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -194,6 +194,8 @@ _hidden int libxl__domain_build_info_set
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
+_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
+_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 69c16a2a8927 -r a72b3dca661f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -933,12 +933,12 @@ skip:
 
             d_config->vfbs = (libxl_device_vfb *) realloc(d_config->vfbs, sizeof(libxl_device_vfb) * (d_config->num_vfbs + 1));
             vfb = d_config->vfbs + d_config->num_vfbs;
-            libxl_device_vfb_init(ctx, vfb);
+            libxl_device_vfb_init(vfb);
             vfb->devid = d_config->num_vfbs;
 
             d_config->vkbs = (libxl_device_vkb *) realloc(d_config->vkbs, sizeof(libxl_device_vkb) * (d_config->num_vkbs + 1));
             vkb = d_config->vkbs + d_config->num_vkbs;
-            libxl_device_vkb_init(ctx, vkb);
+            libxl_device_vkb_init(vkb);
             vkb->devid = d_config->num_vkbs;
 
             p = strtok(buf2, ",");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9K-0003XH-IE; Mon, 13 Feb 2012 16:53:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9I-0003TG-8U
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29076 invoked from network); 13 Feb 2012 16:53:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526868"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHl025169;	Mon, 13 Feb 2012 08:52:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: b2934eb211360cdc6f996940410fd82d435ca059
Message-ID: <b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console
	internal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID b2934eb211360cdc6f996940410fd82d435ca059
# Parent  a72b3dca661fd1a0b40d8252d56017355afe3b38
libxl: make libxl_device_console internal

consoles are not directly exposed to users of the library and there are no API
functions for manipluating them (only the console_exec function). Rather than
commit to a particular API now make the type internal.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -2022,7 +2022,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
 
 /******************************************************************************/
 int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                              libxl_device_console *console,
+                              libxl__device_console *console,
                               libxl__domain_build_state *state)
 {
     flexarray_t *front;
@@ -2069,7 +2069,7 @@ int libxl__device_console_add(libxl__gc 
     flexarray_append(front, "limit");
     flexarray_append(front, libxl__sprintf(gc, "%d", LIBXL_XENCONSOLE_LIMIT));
     flexarray_append(front, "type");
-    if (console->consback == LIBXL_CONSOLE_BACKEND_XENCONSOLED)
+    if (console->consback == LIBXL__CONSOLE_BACKEND_XENCONSOLED)
         flexarray_append(front, "xenconsoled");
     else
         flexarray_append(front, "ioemu");
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -176,17 +176,16 @@ int libxl__domain_build_info_setdefault(
     return 0;
 }
 
-static int init_console_info(libxl_device_console *console, int dev_num)
+static int init_console_info(libxl__device_console *console, int dev_num)
 {
-    memset(console, 0x00, sizeof(libxl_device_console));
+    memset(console, 0x00, sizeof(libxl__device_console));
     console->devid = dev_num;
-    console->consback = LIBXL_CONSOLE_BACKEND_XENCONSOLED;
+    console->consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
     console->output = strdup("pty");
-    if ( NULL == console->output )
+    if (!console->output)
         return ERROR_NOMEM;
     return 0;
 }
-
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
                         uint32_t domid,
@@ -585,14 +584,14 @@ static int do_domain_create(libxl__gc *g
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
-        libxl_device_console console;
+        libxl__device_console console;
         libxl_device_vkb vkb;
 
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
@@ -610,7 +609,7 @@ static int do_domain_create(libxl__gc *g
     case LIBXL_DOMAIN_TYPE_PV:
     {
         int need_qemu = 0;
-        libxl_device_console console;
+        libxl__device_console console;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -626,10 +625,10 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_disks, &d_config->disks[0]);
 
         if (need_qemu)
-             console.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         if (need_qemu) {
             libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:52 2012 +0000
@@ -682,7 +682,7 @@ static int libxl__create_stubdom(libxl__
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
-    libxl_device_console *console;
+    libxl__device_console *console;
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
@@ -814,7 +814,7 @@ retry_transaction:
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
-    console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
+    console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
     if (!console) {
         ret = ERROR_NOMEM;
         goto out_free;
@@ -822,7 +822,7 @@ retry_transaction:
 
     for (i = 0; i < num_console; i++) {
         console[i].devid = i;
-        console[i].consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+        console[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
         /* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
          * STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
          * STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
@@ -1084,7 +1084,7 @@ out:
 }
 
 int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks)
 {
@@ -1096,7 +1096,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
     }
 
     for (i = 0; i < nr_consoles; i++) {
-        if (consoles[i].consback == LIBXL_CONSOLE_BACKEND_IOEMU) {
+        if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
             ret = 1;
             goto out;
         }
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -661,7 +661,7 @@ _hidden int libxl__device_disk_dev_numbe
                                           int *pdisk, int *ppartition);
 
 _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                                      libxl_device_console *console,
+                                      libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
@@ -904,7 +904,7 @@ _hidden int libxl__create_xenpv_qemu(lib
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks);
   /* Caller must either: pass starting_r==0, or on successful
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:52 2012 +0000
@@ -42,11 +42,6 @@ libxl_console_type = Enumeration("consol
     (2, "PV"),
     ])
 
-libxl_console_backend = Enumeration("console_backend", [
-    (1, "XENCONSOLED"),
-    (2, "IOEMU"),
-    ])
-
 libxl_disk_format = Enumeration("disk_format", [
     (0, "UNKNOWN"),
     (1, "QCOW"),
@@ -295,13 +290,6 @@ libxl_device_vkb = Struct("device_vkb", 
     ("devid", integer),
     ])
 
-libxl_device_console = Struct("device_console", [
-    ("backend_domid", libxl_domid),
-    ("devid", integer),
-    ("consback", libxl_console_backend),
-    ("output", string),
-    ])
-
 libxl_device_disk = Struct("device_disk", [
     ("backend_domid", libxl_domid),
     ("pdev_path", string),
diff -r a72b3dca661f -r b2934eb21136 tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_types_internal.idl	Mon Feb 13 15:48:52 2012 +0000
@@ -1,5 +1,7 @@
 namespace("libxl__")
 
+libxl_domid = Builtin("domid", namespace="libxl_", json_fn = "yajl_gen_integer")
+
 libxl__qmp_message_type = Enumeration("qmp_message_type", [
     (1, "QMP"),
     (2, "return"),
@@ -17,3 +19,15 @@ libxl__device_kind = Enumeration("device
     (6, "VKBD"),
     (7, "CONSOLE"),
     ])
+
+libxl__console_backend = Enumeration("console_backend", [
+    (1, "XENCONSOLED"),
+    (2, "IOEMU"),
+    ])
+
+libxl__device_console = Struct("device_console", [
+    ("backend_domid", libxl_domid),
+    ("devid", integer),
+    ("consback", libxl__console_backend),
+    ("output", string),
+    ])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9M-0003a9-Pq; Mon, 13 Feb 2012 16:53: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 1Rwz9K-0003Uc-AL
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6957 invoked from network); 13 Feb 2012 16:50:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901527"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:05 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHq025169;	Mon, 13 Feb 2012 08:53:04 -0800
MIME-Version: 1.0
X-Mercurial-Node: 42c448aa641537798f4b09a6db55f3a5ee4082cd
Message-ID: <42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 16 of 23] libxl: switch generation id control to
	libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150447 0
# Node ID 42c448aa641537798f4b09a6db55f3a5ee4082cd
# Parent  ca432f4ad9f58b0a0a87045a680e37a123bbda11
libxl: switch generation id control to libxl_defbool.

This allows it to be set via the _init/_setdefault methods.

Also switch the sense of the variable in the libxl API, since once you add
defbool to the mix the double negatives become even more confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>

diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:27 2012 +0000
@@ -88,7 +88,6 @@ void libxl_domain_build_info_init(libxl_
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
@@ -150,6 +149,8 @@ int libxl__domain_build_info_setdefault(
         libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
         libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
         libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.incr_generationid, false);
+
         libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
 
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Feb 13 16:27:27 2012 +0000
@@ -406,7 +406,7 @@ int libxl__domain_restore_common(libxl__
         hvm = 1;
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = info->u.hvm.no_incr_generationid;
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:27 2012 +0000
@@ -243,7 +243,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
-                                       ("no_incr_generationid", bool),
+                                       ("incr_generationid",libxl_defbool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
                                        ("vnc",              libxl_vnc_info),
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:27 2012 +0000
@@ -1350,7 +1350,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
-    int no_incr_generationid;
+    int incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info)
@@ -1601,8 +1601,8 @@ static int create_domain(struct domain_c
     }
 
     if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        d_config.b_info.u.hvm.no_incr_generationid =
-            dom_info->no_incr_generationid;
+        libxl_defbool_set(&d_config.b_info.u.hvm.incr_generationid,
+                          dom_info->incr_generationid);
 
     if (debug || dom_info->dryrun)
         printf_info(default_output_format, -1, &d_config);
@@ -2877,7 +2877,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
-    dom_info.no_incr_generationid = 1;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
@@ -3002,6 +3002,7 @@ int main_restore(int argc, char **argv)
     dom_info.restore_file = checkpoint_file;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
@@ -3384,6 +3385,7 @@ int main_create(int argc, char **argv)
     dom_info.extra_config = extra_config;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:27 2012 +0000
@@ -108,8 +108,8 @@ void printf_info_sexp(int domid, libxl_d
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
+        printf("\t\t\t(no_incr_generationid %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
 
         printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
         printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9D-0003Ta-SH; Mon, 13 Feb 2012 16:53:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9C-0003Rt-6l
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13669 invoked from network); 13 Feb 2012 16:52:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:52:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901510"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHe025169;	Mon, 13 Feb 2012 08:52:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: d50d692ae52bca2d409415245e2fcd909259461a
Message-ID: <d50d692ae52bca2d4094.1329151970@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 23] libxl: use an explicit
	LIBXL_TIMER_MODE_DEFAULT value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID d50d692ae52bca2d409415245e2fcd909259461a
# Parent  af0d151cd2d524f13a13e2fb85e727e8733dcd81
libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r af0d151cd2d5 -r d50d692ae52b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:46 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -252,7 +252,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 
 typedef struct libxl__ctx libxl_ctx;
 
-#define LIBXL_TIMER_MODE_DEFAULT LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS
+#define LIBXL_TIMER_MODE_DEFAULT -1
 
 #include "_libxl_types.h"
 
diff -r af0d151cd2d5 -r d50d692ae52b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:46 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -93,7 +93,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
         b_info->u.hvm.vpt_align = 1;
-        b_info->u.hvm.timer_mode = 1;
+        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
@@ -134,6 +134,10 @@ int libxl__domain_build_info_setdefault(
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
+            b_info->u.hvm.timer_mode =
+                LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9L-0003Yr-Pg; Mon, 13 Feb 2012 16:53:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9J-0003Vx-HS
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7048 invoked from network); 13 Feb 2012 16:50:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901529"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:07 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHs025169;	Mon, 13 Feb 2012 08:53:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: ba3ab3558a5d84fef2676b82d641a04615a9d786
Message-ID: <ba3ab3558a5d84fef267.1329151984@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 18 of 23] libxl: do not explicitly initialise
 members of build info to zero
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150453 0
# Node ID ba3ab3558a5d84fef2676b82d641a04615a9d786
# Parent  d27c92eeeddc5e4c190a88ce282fb0155405a65e
libxl: do not explicitly initialise members of build info to zero

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d27c92eeeddc -r ba3ab3558a5d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
@@ -86,12 +85,7 @@ void libxl_domain_build_info_init(libxl_
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-
-        b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usbdevice = NULL;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz96-0003Rl-JN; Mon, 13 Feb 2012 16:52: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 1Rwz95-0003RV-2a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:52:55 +0000
Received: from [85.158.139.83:33195] by server-5.bemta-5.messagelabs.com id
	B0/6A-03847-6EF393F4; Mon, 13 Feb 2012 16:52:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329151972!14904637!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11653 invoked from network); 13 Feb 2012 16:52:53 -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;
	13 Feb 2012 16:52:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526840"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHa025169;	Mon, 13 Feb 2012 08:52:49 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 23] libxl: improved handling for default
	values in API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a mechanism for users of libxl to explicitly say "pick the
default for me".

To do this each field has a distinguished "init_val" and each struct
has a "_setdefault" method which sets (idempotently) the defaults for
fields which have not been set to an explicit value.

Previously I went through some contortions (with "timer_mode" in
particular but also with *_memkb fields) to try and arrange that this
distinguished value was the all zeroes bit pattern.

Instead of that pain this time I have arranged that the IDL supports
the specification the distinguished val for each type/field and we
autogenerate an _init function for each data type based on that.

Changes since last time:

* I have posted large parts of the previous series as
  * libxl: drop device_model_info
  * libxl: API updates + xl: JSON
  These have been committed thereby reducing the size of this series.
* _init function support as described above
* Dropped final patch to actually select stubdoms when possible --
  this needs more investigation/sanity checking.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9D-0003Ta-SH; Mon, 13 Feb 2012 16:53:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9C-0003Rt-6l
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13669 invoked from network); 13 Feb 2012 16:52:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:52:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901510"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHe025169;	Mon, 13 Feb 2012 08:52:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: d50d692ae52bca2d409415245e2fcd909259461a
Message-ID: <d50d692ae52bca2d4094.1329151970@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 23] libxl: use an explicit
	LIBXL_TIMER_MODE_DEFAULT value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID d50d692ae52bca2d409415245e2fcd909259461a
# Parent  af0d151cd2d524f13a13e2fb85e727e8733dcd81
libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r af0d151cd2d5 -r d50d692ae52b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:46 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -252,7 +252,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 
 typedef struct libxl__ctx libxl_ctx;
 
-#define LIBXL_TIMER_MODE_DEFAULT LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS
+#define LIBXL_TIMER_MODE_DEFAULT -1
 
 #include "_libxl_types.h"
 
diff -r af0d151cd2d5 -r d50d692ae52b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:46 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -93,7 +93,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
         b_info->u.hvm.vpt_align = 1;
-        b_info->u.hvm.timer_mode = 1;
+        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
@@ -134,6 +134,10 @@ int libxl__domain_build_info_setdefault(
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
+            b_info->u.hvm.timer_mode =
+                LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9M-0003a9-Pq; Mon, 13 Feb 2012 16:53: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 1Rwz9K-0003Uc-AL
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6957 invoked from network); 13 Feb 2012 16:50:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901527"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:05 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHq025169;	Mon, 13 Feb 2012 08:53:04 -0800
MIME-Version: 1.0
X-Mercurial-Node: 42c448aa641537798f4b09a6db55f3a5ee4082cd
Message-ID: <42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 16 of 23] libxl: switch generation id control to
	libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150447 0
# Node ID 42c448aa641537798f4b09a6db55f3a5ee4082cd
# Parent  ca432f4ad9f58b0a0a87045a680e37a123bbda11
libxl: switch generation id control to libxl_defbool.

This allows it to be set via the _init/_setdefault methods.

Also switch the sense of the variable in the libxl API, since once you add
defbool to the mix the double negatives become even more confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>

diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:27 2012 +0000
@@ -88,7 +88,6 @@ void libxl_domain_build_info_init(libxl_
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
@@ -150,6 +149,8 @@ int libxl__domain_build_info_setdefault(
         libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
         libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
         libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.incr_generationid, false);
+
         libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
 
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Feb 13 16:27:27 2012 +0000
@@ -406,7 +406,7 @@ int libxl__domain_restore_common(libxl__
         hvm = 1;
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = info->u.hvm.no_incr_generationid;
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:27 2012 +0000
@@ -243,7 +243,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
-                                       ("no_incr_generationid", bool),
+                                       ("incr_generationid",libxl_defbool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
                                        ("vnc",              libxl_vnc_info),
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:27 2012 +0000
@@ -1350,7 +1350,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
-    int no_incr_generationid;
+    int incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info)
@@ -1601,8 +1601,8 @@ static int create_domain(struct domain_c
     }
 
     if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        d_config.b_info.u.hvm.no_incr_generationid =
-            dom_info->no_incr_generationid;
+        libxl_defbool_set(&d_config.b_info.u.hvm.incr_generationid,
+                          dom_info->incr_generationid);
 
     if (debug || dom_info->dryrun)
         printf_info(default_output_format, -1, &d_config);
@@ -2877,7 +2877,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
-    dom_info.no_incr_generationid = 1;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
@@ -3002,6 +3002,7 @@ int main_restore(int argc, char **argv)
     dom_info.restore_file = checkpoint_file;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
@@ -3384,6 +3385,7 @@ int main_create(int argc, char **argv)
     dom_info.extra_config = extra_config;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:01 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:27 2012 +0000
@@ -108,8 +108,8 @@ void printf_info_sexp(int domid, libxl_d
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
+        printf("\t\t\t(no_incr_generationid %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
 
         printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
         printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz96-0003Rl-JN; Mon, 13 Feb 2012 16:52: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 1Rwz95-0003RV-2a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:52:55 +0000
Received: from [85.158.139.83:33195] by server-5.bemta-5.messagelabs.com id
	B0/6A-03847-6EF393F4; Mon, 13 Feb 2012 16:52:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329151972!14904637!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11653 invoked from network); 13 Feb 2012 16:52:53 -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;
	13 Feb 2012 16:52:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526840"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHa025169;	Mon, 13 Feb 2012 08:52:49 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 23] libxl: improved handling for default
	values in API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a mechanism for users of libxl to explicitly say "pick the
default for me".

To do this each field has a distinguished "init_val" and each struct
has a "_setdefault" method which sets (idempotently) the defaults for
fields which have not been set to an explicit value.

Previously I went through some contortions (with "timer_mode" in
particular but also with *_memkb fields) to try and arrange that this
distinguished value was the all zeroes bit pattern.

Instead of that pain this time I have arranged that the IDL supports
the specification the distinguished val for each type/field and we
autogenerate an _init function for each data type based on that.

Changes since last time:

* I have posted large parts of the previous series as
  * libxl: drop device_model_info
  * libxl: API updates + xl: JSON
  These have been committed thereby reducing the size of this series.
* _init function support as described above
* Dropped final patch to actually select stubdoms when possible --
  this needs more investigation/sanity checking.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz97-0003S9-Vx; Mon, 13 Feb 2012 16:52: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 1Rwz96-0003RV-E2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:52:56 +0000
Received: from [85.158.139.83:33270] by server-5.bemta-5.messagelabs.com id
	06/7A-03847-8EF393F4; Mon, 13 Feb 2012 16:52:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329151972!14904637!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11664 invoked from network); 13 Feb 2012 16:52:54 -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;
	13 Feb 2012 16:52:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526845"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHc025169;	Mon, 13 Feb 2012 08:52:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: 53d4e198863a29e204186ab10c8950c3bd4235a8
Message-ID: <53d4e198863a29e20418.1329151968@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 23] libxl: provide _init and _setdefault
 for libxl_domain_create_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148119 0
# Node ID 53d4e198863a29e204186ab10c8950c3bd4235a8
# Parent  d50c4dc752717e2742a7e9018fcbaffbfff9ea6c
libxl: provide _init and _setdefault for libxl_domain_create_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

It doesn't seem reasonable for the library to pick a default for the domain
type so reject as invalid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:39 2012 +0000
@@ -363,7 +363,7 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:39 2012 +0000
@@ -50,16 +50,19 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->xsdata = NULL;
-    c_info->platformdata = NULL;
     c_info->hap = 1;
-    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
     c_info->oos = 1;
-    c_info->ssidref = 0;
-    c_info->poolid = 0;
+}
+
+int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                         libxl_domain_create_info *c_info)
+{
+    if (!c_info->type)
+        return ERROR_INVAL;
+
     return 0;
 }
 
@@ -469,6 +472,9 @@ static int do_domain_create(libxl__gc *g
 
     domid = 0;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:39 2012 +0000
@@ -699,7 +699,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    libxl_domain_create_info_init(&dm_config.c_info);
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
@@ -734,6 +734,9 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    if (ret) goto out;
+
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:39 2012 +0000
@@ -187,6 +187,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  * version of the _evdisable_FOO function; the internal one is
  * used during cleanup.
  */
+_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_create_info *c_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:39 2012 +0000
@@ -537,8 +537,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_create_info(ctx, c_info))
-        exit(1);
+    libxl_domain_create_info_init(c_info);
 
     if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9C-0003St-8N; Mon, 13 Feb 2012 16:53:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9A-0003Rf-JP
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13475 invoked from network); 13 Feb 2012 16:52:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:52:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901507"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHb025169;	Mon, 13 Feb 2012 08:52:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: d50c4dc752717e2742a7e9018fcbaffbfff9ea6c
Message-ID: <d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 23] libxl: Document
	_init/_dispose/_setdefault functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329147318 0
# Node ID d50c4dc752717e2742a7e9018fcbaffbfff9ea6c
# Parent  1d0bcc8cafd5abd34da13ce32758c505c73cfa48
libxl: Document _init/_dispose/_setdefault functions.

Subsequent patches will transition to them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1d0bcc8cafd5 -r d50c4dc75271 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:35:18 2012 +0000
@@ -124,6 +124,54 @@
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
  */
+/*
+ * libxl types
+ *
+ * Most libxl types are defined by the libxl IDL (see
+ * libxl_types.idl). The library provides a common set of methods for
+ * initialising and freeing these types.
+ *
+ * void libxl_<type>_init(<type> *p):
+ *
+ *    Initialises the members of "p" to all defaults. These may either
+ *    be special value which indicates to the library that it should
+ *    select an appropriate default when using this field or actual
+ *    default values.
+ *
+ *    Some fields within a data type (e.g. unions) cannot be sensibly
+ *    initialised without further information. In these cases a
+ *    separate subfield initialisation function is provided (see
+ *    below).
+ *
+ *    An instance which has been initialised using this method can
+ *    always be safely passed to the dispose function (see
+ *    below). This is true even if the data type contains fields which
+ *    require a separate call to a subfield initialisation function.
+ *
+ *    This method is provided for any aggregate type which is used as
+ *    an input parameter.
+ *
+ * void libxl_<type>_init_<subfield>(<type> *p, subfield):
+ *
+ *    Initialise those parts of "p" which are not initialised by the
+ *    main init function due to the unknown value of "subfield". Sets
+ *    p->subfield as well as initialising any fields to their default
+ *    values.
+ *
+ *    p->subfield must not have been previously initialised.
+ *
+ *    This method is provided for any aggregate type which is used as
+ *    an input parameter.
+ *
+ * void libxl_<type>_dispose(instance *p):
+ *
+ *    Frees any dynamically allocated memory used by the members of
+ *    "p" but not the storage used by "p" itself (this allows for the
+ *    allocation of arrays of types and for the composition of types).
+ *
+ *    In general this method is only provided for types where memory
+ *    can be dynamically allocated as part of that type.
+ */
 #ifndef LIBXL_H
 #define LIBXL_H
 
@@ -405,8 +453,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  * additional data type libxl_device_<TYPE>_getinfo which contains
  * further runtime information about the device.
  *
- * A common set of methods are available for each device type. These
- * are described below.
+ * In addition to the general methods available for libxl types (see
+ * "libxl types" above) a common set of methods are available for each
+ * device type. These are described below.
  *
  * Querying
  * --------
@@ -424,10 +473,6 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  * Creation / Control
  * ------------------
  *
- * libxl_device_<type>_init(ctx, device):
- *
- *    Initalises device to a default configuration.
- *
  * libxl_device_<type>_add(ctx, domid, device):
  *
  *   Adds the given device to the specified domain. This can be called
diff -r 1d0bcc8cafd5 -r d50c4dc75271 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:35:18 2012 +0000
@@ -665,6 +665,19 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * For each aggregate type which can be used as an input we provide:
+ *
+ * int libxl__<type>_setdefault(gc, <type> *p):
+ *
+ *     Idempotently sets any members of "p" which is currently set to
+ *     a special value indicating that the defaults should be used
+ *     (per libxl_<type>_init) to a specific value.
+ *
+ *     All libxl API functions are expected to have arranged for this
+ *     to be called before using any values within these structures.
+ */
+
 /* Arranges that dev will be removed from its guest.  When
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9C-0003St-8N; Mon, 13 Feb 2012 16:53:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9A-0003Rf-JP
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13475 invoked from network); 13 Feb 2012 16:52:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:52:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901507"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHb025169;	Mon, 13 Feb 2012 08:52:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: d50c4dc752717e2742a7e9018fcbaffbfff9ea6c
Message-ID: <d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 23] libxl: Document
	_init/_dispose/_setdefault functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329147318 0
# Node ID d50c4dc752717e2742a7e9018fcbaffbfff9ea6c
# Parent  1d0bcc8cafd5abd34da13ce32758c505c73cfa48
libxl: Document _init/_dispose/_setdefault functions.

Subsequent patches will transition to them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1d0bcc8cafd5 -r d50c4dc75271 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:35:18 2012 +0000
@@ -124,6 +124,54 @@
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
  */
+/*
+ * libxl types
+ *
+ * Most libxl types are defined by the libxl IDL (see
+ * libxl_types.idl). The library provides a common set of methods for
+ * initialising and freeing these types.
+ *
+ * void libxl_<type>_init(<type> *p):
+ *
+ *    Initialises the members of "p" to all defaults. These may either
+ *    be special value which indicates to the library that it should
+ *    select an appropriate default when using this field or actual
+ *    default values.
+ *
+ *    Some fields within a data type (e.g. unions) cannot be sensibly
+ *    initialised without further information. In these cases a
+ *    separate subfield initialisation function is provided (see
+ *    below).
+ *
+ *    An instance which has been initialised using this method can
+ *    always be safely passed to the dispose function (see
+ *    below). This is true even if the data type contains fields which
+ *    require a separate call to a subfield initialisation function.
+ *
+ *    This method is provided for any aggregate type which is used as
+ *    an input parameter.
+ *
+ * void libxl_<type>_init_<subfield>(<type> *p, subfield):
+ *
+ *    Initialise those parts of "p" which are not initialised by the
+ *    main init function due to the unknown value of "subfield". Sets
+ *    p->subfield as well as initialising any fields to their default
+ *    values.
+ *
+ *    p->subfield must not have been previously initialised.
+ *
+ *    This method is provided for any aggregate type which is used as
+ *    an input parameter.
+ *
+ * void libxl_<type>_dispose(instance *p):
+ *
+ *    Frees any dynamically allocated memory used by the members of
+ *    "p" but not the storage used by "p" itself (this allows for the
+ *    allocation of arrays of types and for the composition of types).
+ *
+ *    In general this method is only provided for types where memory
+ *    can be dynamically allocated as part of that type.
+ */
 #ifndef LIBXL_H
 #define LIBXL_H
 
@@ -405,8 +453,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  * additional data type libxl_device_<TYPE>_getinfo which contains
  * further runtime information about the device.
  *
- * A common set of methods are available for each device type. These
- * are described below.
+ * In addition to the general methods available for libxl types (see
+ * "libxl types" above) a common set of methods are available for each
+ * device type. These are described below.
  *
  * Querying
  * --------
@@ -424,10 +473,6 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  * Creation / Control
  * ------------------
  *
- * libxl_device_<type>_init(ctx, device):
- *
- *    Initalises device to a default configuration.
- *
  * libxl_device_<type>_add(ctx, domid, device):
  *
  *   Adds the given device to the specified domain. This can be called
diff -r 1d0bcc8cafd5 -r d50c4dc75271 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:35:18 2012 +0000
@@ -665,6 +665,19 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * For each aggregate type which can be used as an input we provide:
+ *
+ * int libxl__<type>_setdefault(gc, <type> *p):
+ *
+ *     Idempotently sets any members of "p" which is currently set to
+ *     a special value indicating that the defaults should be used
+ *     (per libxl_<type>_init) to a specific value.
+ *
+ *     All libxl API functions are expected to have arranged for this
+ *     to be called before using any values within these structures.
+ */
+
 /* Arranges that dev will be removed from its guest.  When
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz97-0003S9-Vx; Mon, 13 Feb 2012 16:52: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 1Rwz96-0003RV-E2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:52:56 +0000
Received: from [85.158.139.83:33270] by server-5.bemta-5.messagelabs.com id
	06/7A-03847-8EF393F4; Mon, 13 Feb 2012 16:52:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329151972!14904637!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11664 invoked from network); 13 Feb 2012 16:52:54 -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;
	13 Feb 2012 16:52:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526845"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:52:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHc025169;	Mon, 13 Feb 2012 08:52:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: 53d4e198863a29e204186ab10c8950c3bd4235a8
Message-ID: <53d4e198863a29e20418.1329151968@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 23] libxl: provide _init and _setdefault
 for libxl_domain_create_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148119 0
# Node ID 53d4e198863a29e204186ab10c8950c3bd4235a8
# Parent  d50c4dc752717e2742a7e9018fcbaffbfff9ea6c
libxl: provide _init and _setdefault for libxl_domain_create_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

It doesn't seem reasonable for the library to pick a default for the domain
type so reject as invalid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:39 2012 +0000
@@ -363,7 +363,7 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:39 2012 +0000
@@ -50,16 +50,19 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->xsdata = NULL;
-    c_info->platformdata = NULL;
     c_info->hap = 1;
-    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
     c_info->oos = 1;
-    c_info->ssidref = 0;
-    c_info->poolid = 0;
+}
+
+int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                         libxl_domain_create_info *c_info)
+{
+    if (!c_info->type)
+        return ERROR_INVAL;
+
     return 0;
 }
 
@@ -469,6 +472,9 @@ static int do_domain_create(libxl__gc *g
 
     domid = 0;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:48:39 2012 +0000
@@ -699,7 +699,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    libxl_domain_create_info_init(&dm_config.c_info);
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
@@ -734,6 +734,9 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    if (ret) goto out;
+
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:39 2012 +0000
@@ -187,6 +187,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  * version of the _evdisable_FOO function; the internal one is
  * used during cleanup.
  */
+_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_create_info *c_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r d50c4dc75271 -r 53d4e198863a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:35:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:39 2012 +0000
@@ -537,8 +537,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_create_info(ctx, c_info))
-        exit(1);
+    libxl_domain_create_info_init(c_info);
 
     if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9M-0003Zm-DJ; Mon, 13 Feb 2012 16:53:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9J-0003Tl-P2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29139 invoked from network); 13 Feb 2012 16:53:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:01 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHm025169;	Mon, 13 Feb 2012 08:53:00 -0800
MIME-Version: 1.0
X-Mercurial-Node: cb563f911986275f93ea8dd003b69d44d8745adf
Message-ID: <cb563f911986275f93ea.1329151978@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 12 of 23] libxl: pci: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148133 0
# Node ID cb563f911986275f93ea8dd003b69d44d8745adf
# Parent  b2934eb211360cdc6f996940410fd82d435ca059
libxl: pci: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b2934eb21136 -r cb563f911986 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:53 2012 +0000
@@ -556,7 +556,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-int libxl_device_pci_init(libxl_ctx *ctx, libxl_device_pci *pci);
+void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r b2934eb21136 -r cb563f911986 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:53 2012 +0000
@@ -196,6 +196,7 @@ _hidden int libxl__device_disk_setdefaul
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
+_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r b2934eb21136 -r cb563f911986 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Feb 13 15:48:53 2012 +0000
@@ -765,6 +765,16 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
+void libxl_device_pci_init(libxl_device_pci *pci)
+{
+    memset(pci, '\0', sizeof(*pci));
+}
+
+int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
+{
+    return 0;
+}
+
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
     GC_INIT(ctx);
@@ -782,6 +792,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     int num_assigned, i, rc;
     int stubdomid = 0;
 
+    rc = libxl__device_pci_setdefault(gc, pcidev);
+    if (rc) goto out;
+
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
diff -r b2934eb21136 -r cb563f911986 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:53 2012 +0000
@@ -1014,7 +1014,7 @@ skip_vfb:
 
             d_config->pcidevs = (libxl_device_pci *) realloc(d_config->pcidevs, sizeof (libxl_device_pci) * (d_config->num_pcidevs + 1));
             pcidev = d_config->pcidevs + d_config->num_pcidevs;
-            memset(pcidev, 0x00, sizeof(libxl_device_pci));
+            libxl_device_pci_init(pcidev);
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9M-0003Zm-DJ; Mon, 13 Feb 2012 16:53:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9J-0003Tl-P2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29139 invoked from network); 13 Feb 2012 16:53:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:01 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHm025169;	Mon, 13 Feb 2012 08:53:00 -0800
MIME-Version: 1.0
X-Mercurial-Node: cb563f911986275f93ea8dd003b69d44d8745adf
Message-ID: <cb563f911986275f93ea.1329151978@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 12 of 23] libxl: pci: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148133 0
# Node ID cb563f911986275f93ea8dd003b69d44d8745adf
# Parent  b2934eb211360cdc6f996940410fd82d435ca059
libxl: pci: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b2934eb21136 -r cb563f911986 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:53 2012 +0000
@@ -556,7 +556,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-int libxl_device_pci_init(libxl_ctx *ctx, libxl_device_pci *pci);
+void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r b2934eb21136 -r cb563f911986 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:53 2012 +0000
@@ -196,6 +196,7 @@ _hidden int libxl__device_disk_setdefaul
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
+_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r b2934eb21136 -r cb563f911986 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Feb 13 15:48:53 2012 +0000
@@ -765,6 +765,16 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
+void libxl_device_pci_init(libxl_device_pci *pci)
+{
+    memset(pci, '\0', sizeof(*pci));
+}
+
+int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
+{
+    return 0;
+}
+
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
     GC_INIT(ctx);
@@ -782,6 +792,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     int num_assigned, i, rc;
     int stubdomid = 0;
 
+    rc = libxl__device_pci_setdefault(gc, pcidev);
+    if (rc) goto out;
+
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
diff -r b2934eb21136 -r cb563f911986 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:53 2012 +0000
@@ -1014,7 +1014,7 @@ skip_vfb:
 
             d_config->pcidevs = (libxl_device_pci *) realloc(d_config->pcidevs, sizeof (libxl_device_pci) * (d_config->num_pcidevs + 1));
             pcidev = d_config->pcidevs + d_config->num_pcidevs;
-            memset(pcidev, 0x00, sizeof(libxl_device_pci));
+            libxl_device_pci_init(pcidev);
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9K-0003Xk-V2; Mon, 13 Feb 2012 16:53:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9I-0003TL-Fm
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14244 invoked from network); 13 Feb 2012 16:53:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901516"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHj025169;	Mon, 13 Feb 2012 08:52:58 -0800
MIME-Version: 1.0
X-Mercurial-Node: 69c16a2a8927d81acc0cf0e127a5a4b7a9a1a886
Message-ID: <69c16a2a8927d81acc0c.1329151975@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 23] libxl: nic: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 69c16a2a8927d81acc0cf0e127a5a4b7a9a1a886
# Parent  575cccbd3dc1c74cafb319fe82998c5fa619b428
libxl: nic: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -1676,32 +1676,43 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic)
+void libxl_device_nic_init(libxl_device_nic *nic)
 {
-    const uint8_t *r;
-    libxl_uuid uuid;
-
-    libxl_uuid_generate(&uuid);
-    r = libxl_uuid_bytearray(&uuid);
     memset(nic, '\0', sizeof(*nic));
-
-    nic->backend_domid = 0;
-    nic->devid = -1;
-    nic->mtu = 1492;
-    nic->model = strdup("rtl8139");
-    nic->mac[0] = 0x00;
-    nic->mac[1] = 0x16;
-    nic->mac[2] = 0x3e;
-    nic->mac[3] = r[0] & 0x7f;
-    nic->mac[4] = r[1];
-    nic->mac[5] = r[2];
-    nic->ifname = NULL;
-    nic->bridge = strdup("xenbr0");
-    nic->ip = NULL;
-    if ( asprintf(&nic->script, "%s/vif-bridge",
-               libxl_xen_script_dir_path()) < 0 )
+}
+
+int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
+{
+    if (!nic->mtu)
+        nic->mtu = 1492;
+    if (!nic->model) {
+        nic->model = strdup("rtl8139");
+        if (!nic->model) return ERROR_NOMEM;
+    }
+    if (!nic->mac[0] && !nic->mac[1] && !nic->mac[2] &&
+        !nic->mac[3] && !nic->mac[4] && !nic->mac[5]) {
+        const uint8_t *r;
+        libxl_uuid uuid;
+
+        libxl_uuid_generate(&uuid);
+        r = libxl_uuid_bytearray(&uuid);
+
+        nic->mac[0] = 0x00;
+        nic->mac[1] = 0x16;
+        nic->mac[2] = 0x3e;
+        nic->mac[3] = r[0] & 0x7f;
+        nic->mac[4] = r[1];
+        nic->mac[5] = r[2];
+    }
+    if (!nic->bridge) {
+        nic->bridge = strdup("xenbr0");
+        if (!nic->bridge) return ERROR_NOMEM;
+    }
+    if ( !nic->script && asprintf(&nic->script, "%s/vif-bridge",
+                                  libxl_xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
-    nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+    if (!nic->nictype)
+        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
     return 0;
 }
 
@@ -1728,6 +1739,9 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     char *dompath, **l;
     unsigned int nb, rc;
 
+    rc = libxl__device_nic_setdefault(gc, nic);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -528,7 +528,7 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
+void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -193,6 +193,7 @@ _hidden int libxl__domain_build_info_set
                                         libxl_domain_build_info *b_info);
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
+_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -842,7 +842,7 @@ static void parse_config_data(const char
 
             d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1));
             nic = d_config->vifs + d_config->num_vifs;
-            CHK_ERRNO( libxl_device_nic_init(ctx, nic) );
+            libxl_device_nic_init(nic);
             nic->devid = d_config->num_vifs;
 
             if (default_vifscript) {
@@ -4602,7 +4602,7 @@ int main_networkattach(int argc, char **
         fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
         return 1;
     }
-    libxl_device_nic_init(ctx, &nic);
+    libxl_device_nic_init(&nic);
     for (argv += optind+1, argc -= optind+1; argc > 0; ++argv, --argc) {
         if (MATCH_OPTION("type", *argv, oparg)) {
             if (!strcmp("vif", oparg)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9K-0003Xk-V2; Mon, 13 Feb 2012 16:53:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9I-0003TL-Fm
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14244 invoked from network); 13 Feb 2012 16:53:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901516"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHj025169;	Mon, 13 Feb 2012 08:52:58 -0800
MIME-Version: 1.0
X-Mercurial-Node: 69c16a2a8927d81acc0cf0e127a5a4b7a9a1a886
Message-ID: <69c16a2a8927d81acc0c.1329151975@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 23] libxl: nic: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 69c16a2a8927d81acc0cf0e127a5a4b7a9a1a886
# Parent  575cccbd3dc1c74cafb319fe82998c5fa619b428
libxl: nic: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -1676,32 +1676,43 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic)
+void libxl_device_nic_init(libxl_device_nic *nic)
 {
-    const uint8_t *r;
-    libxl_uuid uuid;
-
-    libxl_uuid_generate(&uuid);
-    r = libxl_uuid_bytearray(&uuid);
     memset(nic, '\0', sizeof(*nic));
-
-    nic->backend_domid = 0;
-    nic->devid = -1;
-    nic->mtu = 1492;
-    nic->model = strdup("rtl8139");
-    nic->mac[0] = 0x00;
-    nic->mac[1] = 0x16;
-    nic->mac[2] = 0x3e;
-    nic->mac[3] = r[0] & 0x7f;
-    nic->mac[4] = r[1];
-    nic->mac[5] = r[2];
-    nic->ifname = NULL;
-    nic->bridge = strdup("xenbr0");
-    nic->ip = NULL;
-    if ( asprintf(&nic->script, "%s/vif-bridge",
-               libxl_xen_script_dir_path()) < 0 )
+}
+
+int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
+{
+    if (!nic->mtu)
+        nic->mtu = 1492;
+    if (!nic->model) {
+        nic->model = strdup("rtl8139");
+        if (!nic->model) return ERROR_NOMEM;
+    }
+    if (!nic->mac[0] && !nic->mac[1] && !nic->mac[2] &&
+        !nic->mac[3] && !nic->mac[4] && !nic->mac[5]) {
+        const uint8_t *r;
+        libxl_uuid uuid;
+
+        libxl_uuid_generate(&uuid);
+        r = libxl_uuid_bytearray(&uuid);
+
+        nic->mac[0] = 0x00;
+        nic->mac[1] = 0x16;
+        nic->mac[2] = 0x3e;
+        nic->mac[3] = r[0] & 0x7f;
+        nic->mac[4] = r[1];
+        nic->mac[5] = r[2];
+    }
+    if (!nic->bridge) {
+        nic->bridge = strdup("xenbr0");
+        if (!nic->bridge) return ERROR_NOMEM;
+    }
+    if ( !nic->script && asprintf(&nic->script, "%s/vif-bridge",
+                                  libxl_xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
-    nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+    if (!nic->nictype)
+        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
     return 0;
 }
 
@@ -1728,6 +1739,9 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     char *dompath, **l;
     unsigned int nb, rc;
 
+    rc = libxl__device_nic_setdefault(gc, nic);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -528,7 +528,7 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
+void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -193,6 +193,7 @@ _hidden int libxl__domain_build_info_set
                                         libxl_domain_build_info *b_info);
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
+_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 575cccbd3dc1 -r 69c16a2a8927 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -842,7 +842,7 @@ static void parse_config_data(const char
 
             d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1));
             nic = d_config->vifs + d_config->num_vifs;
-            CHK_ERRNO( libxl_device_nic_init(ctx, nic) );
+            libxl_device_nic_init(nic);
             nic->devid = d_config->num_vifs;
 
             if (default_vifscript) {
@@ -4602,7 +4602,7 @@ int main_networkattach(int argc, char **
         fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
         return 1;
     }
-    libxl_device_nic_init(ctx, &nic);
+    libxl_device_nic_init(&nic);
     for (argv += optind+1, argc -= optind+1; argc > 0; ++argv, --argc) {
         if (MATCH_OPTION("type", *argv, oparg)) {
             if (!strcmp("vif", oparg)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9J-0003WH-GL; Mon, 13 Feb 2012 16:53:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9H-0003Sr-KL
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14161 invoked from network); 13 Feb 2012 16:53:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901514"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHi025169;	Mon, 13 Feb 2012 08:52:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: 575cccbd3dc1c74cafb319fe82998c5fa619b428
Message-ID: <575cccbd3dc1c74cafb3.1329151974@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 23] libxl: disk: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 575cccbd3dc1c74cafb319fe82998c5fa619b428
# Parent  2fef3eddec04dd3a56d651d15adcd1f72a201a1e
libxl: disk: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -1185,10 +1185,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
+void libxl_device_disk_init(libxl_device_disk *disk)
 {
     memset(disk, 0x00, sizeof(libxl_device_disk));
-    return 0;
+}
+
+int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
+{
+    int rc;
+
+    rc = libxl__device_disk_set_backend(gc, disk);
+    if (rc) return rc;
+
+    return rc;
 }
 
 static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
@@ -1240,10 +1249,7 @@ int libxl_device_disk_add(libxl_ctx *ctx
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
-    if (rc) goto out;
-
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1395,7 +1401,7 @@ static void libxl__device_disk_from_xs_b
     unsigned int len;
     char *tmp;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     tmp = xs_read(ctx->xsh, XBT_NULL,
                   libxl__sprintf(gc, "%s/params", be_path), &len);
@@ -1439,7 +1445,7 @@ int libxl_devid_to_device_disk(libxl_ctx
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
@@ -1603,7 +1609,7 @@ char * libxl_device_disk_local_attach(li
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -502,7 +502,7 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  */
 
 /* Disks */
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
+void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -535,7 +535,7 @@ static int do_domain_create(libxl__gc *g
     if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
+        ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
         if (ret) goto error_out;
     }
 
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -191,6 +191,8 @@ _hidden int libxl__domain_create_info_se
                                         libxl_domain_create_info *c_info);
 _hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info);
+_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
+                                          libxl_device_disk *disk);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -384,7 +384,7 @@ static void parse_disk_config_multistrin
 {
     int e;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     if (!*config) {
         *config = xlu_cfg_init(stderr, "command line");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9J-0003WH-GL; Mon, 13 Feb 2012 16:53:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9H-0003Sr-KL
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329151972!13199120!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14161 invoked from network); 13 Feb 2012 16:53:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901514"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:52:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHi025169;	Mon, 13 Feb 2012 08:52:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: 575cccbd3dc1c74cafb319fe82998c5fa619b428
Message-ID: <575cccbd3dc1c74cafb3.1329151974@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:52:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 23] libxl: disk: use _init/_setdefault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148132 0
# Node ID 575cccbd3dc1c74cafb319fe82998c5fa619b428
# Parent  2fef3eddec04dd3a56d651d15adcd1f72a201a1e
libxl: disk: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -1185,10 +1185,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
+void libxl_device_disk_init(libxl_device_disk *disk)
 {
     memset(disk, 0x00, sizeof(libxl_device_disk));
-    return 0;
+}
+
+int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
+{
+    int rc;
+
+    rc = libxl__device_disk_set_backend(gc, disk);
+    if (rc) return rc;
+
+    return rc;
 }
 
 static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
@@ -1240,10 +1249,7 @@ int libxl_device_disk_add(libxl_ctx *ctx
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
-    if (rc) goto out;
-
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1395,7 +1401,7 @@ static void libxl__device_disk_from_xs_b
     unsigned int len;
     char *tmp;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     tmp = xs_read(ctx->xsh, XBT_NULL,
                   libxl__sprintf(gc, "%s/params", be_path), &len);
@@ -1439,7 +1445,7 @@ int libxl_devid_to_device_disk(libxl_ctx
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
@@ -1603,7 +1609,7 @@ char * libxl_device_disk_local_attach(li
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 15:48:52 2012 +0000
@@ -502,7 +502,7 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  */
 
 /* Disks */
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
+void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:48:52 2012 +0000
@@ -535,7 +535,7 @@ static int do_domain_create(libxl__gc *g
     if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
+        ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
         if (ret) goto error_out;
     }
 
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Feb 13 15:48:52 2012 +0000
@@ -191,6 +191,8 @@ _hidden int libxl__domain_create_info_se
                                         libxl_domain_create_info *c_info);
 _hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info);
+_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
+                                          libxl_device_disk *disk);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 2fef3eddec04 -r 575cccbd3dc1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:52 2012 +0000
@@ -384,7 +384,7 @@ static void parse_disk_config_multistrin
 {
     int e;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     if (!*config) {
         *config = xlu_cfg_init(stderr, "command line");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9S-0003ai-D2; Mon, 13 Feb 2012 16:53:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9K-0003UC-Rc
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29228 invoked from network); 13 Feb 2012 16:53:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526882"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHo025169;	Mon, 13 Feb 2012 08:53:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: a20f15f1889ba1dda88d64509694818a0793cf8a
Message-ID: <a20f15f1889ba1dda88d.1329151980@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 14 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148140 0
# Node ID a20f15f1889ba1dda88d64509694818a0793cf8a
# Parent  41738bf7d28dd74018a160712da69bfc02b7f4b5
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:49:00 2012 +0000
@@ -20,8 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
-             "libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:49:00 2012 +0000
@@ -53,8 +53,6 @@ void libxl_domain_config_dispose(libxl_d
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->hap = 1;
-    c_info->oos = 1;
 }
 
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
@@ -63,6 +61,11 @@ int libxl__domain_create_info_setdefault
     if (!c_info->type)
         return ERROR_INVAL;
 
+    if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&c_info->hap, true);
+        libxl_defbool_setdefault(&c_info->oos, true);
+    }
+
     return 0;
 }
 
@@ -365,8 +368,8 @@ int libxl__domain_make(libxl__gc *gc, li
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
-        flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
-        flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
+        flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+        flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
     *domid = -1;
 
@@ -518,6 +521,9 @@ static int do_domain_create(libxl__gc *g
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:00 2012 +0000
@@ -188,8 +188,8 @@ libxl_version_info = Struct("version_inf
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
-    ("hap",          bool),
-    ("oos",          bool),
+    ("hap",          libxl_defbool),
+    ("oos",          libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:00 2012 +0000
@@ -557,8 +557,7 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l, 0))
-        c_info->hap = l;
+    xlu_cfg_get_defbool(config, "hap", &c_info->hap, 0);
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.\n");
@@ -574,8 +573,7 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l, 0))
-        c_info->oos = l;
+    xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:00 2012 +0000
@@ -41,8 +41,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
+    printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9S-0003ai-D2; Mon, 13 Feb 2012 16:53:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9K-0003UC-Rc
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29228 invoked from network); 13 Feb 2012 16:53:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526882"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHo025169;	Mon, 13 Feb 2012 08:53:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: a20f15f1889ba1dda88d64509694818a0793cf8a
Message-ID: <a20f15f1889ba1dda88d.1329151980@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 14 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148140 0
# Node ID a20f15f1889ba1dda88d64509694818a0793cf8a
# Parent  41738bf7d28dd74018a160712da69bfc02b7f4b5
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 15:49:00 2012 +0000
@@ -20,8 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
-             "libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:49:00 2012 +0000
@@ -53,8 +53,6 @@ void libxl_domain_config_dispose(libxl_d
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->hap = 1;
-    c_info->oos = 1;
 }
 
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
@@ -63,6 +61,11 @@ int libxl__domain_create_info_setdefault
     if (!c_info->type)
         return ERROR_INVAL;
 
+    if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&c_info->hap, true);
+        libxl_defbool_setdefault(&c_info->oos, true);
+    }
+
     return 0;
 }
 
@@ -365,8 +368,8 @@ int libxl__domain_make(libxl__gc *gc, li
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
-        flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
-        flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
+        flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+        flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
     *domid = -1;
 
@@ -518,6 +521,9 @@ static int do_domain_create(libxl__gc *g
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:00 2012 +0000
@@ -188,8 +188,8 @@ libxl_version_info = Struct("version_inf
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
-    ("hap",          bool),
-    ("oos",          bool),
+    ("hap",          libxl_defbool),
+    ("oos",          libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:00 2012 +0000
@@ -557,8 +557,7 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l, 0))
-        c_info->hap = l;
+    xlu_cfg_get_defbool(config, "hap", &c_info->hap, 0);
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.\n");
@@ -574,8 +573,7 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l, 0))
-        c_info->oos = l;
+    xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
diff -r 41738bf7d28d -r a20f15f1889b tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:48:53 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:00 2012 +0000
@@ -41,8 +41,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
+    printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9T-0003l4-Uw; Mon, 13 Feb 2012 16:53: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 1Rwz9L-0003Xd-Ah
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7120 invoked from network); 13 Feb 2012 16:50:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901530"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:09 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHu025169;	Mon, 13 Feb 2012 08:53:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1adeebf9e6bd3d74a2f6e35937d4c6ada4212ccd
Message-ID: <1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 20 of 23] libxl: add
	libxl_domain_build_info_init_type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 1adeebf9e6bd3d74a2f6e35937d4c6ada4212ccd
# Parent  871a9c864b558f554f6d72cef59cfc8e6af2d81a
libxl: add libxl_domain_build_info_init_type

Use instead of parameterising libxl_domain_build_info_init. This allows callers
to initialise a libxl_domain_build_info but not to commit to a particular type
later on (e.g. after they've parsed the domain config)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
@@ -389,8 +389,9 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                          const libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
@@ -69,23 +69,29 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                                  const libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = c_info->type;
+    b_info->type = -1;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
+}
+
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type)
+{
+    assert(b_info->type == -1);
+    b_info->type = type;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 0;
+        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
         break;
     default:
         abort();
diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:34 2012 +0000
@@ -707,7 +707,8 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+    libxl_domain_build_info_init(&dm_config.b_info);
+    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
 
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -584,7 +584,8 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_build_info_init(b_info, c_info);
+    libxl_domain_build_info_init(b_info);
+    libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -701,7 +702,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    switch(c_info->type) {
+    switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9T-0003l4-Uw; Mon, 13 Feb 2012 16:53: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 1Rwz9L-0003Xd-Ah
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7120 invoked from network); 13 Feb 2012 16:50:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901530"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:09 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHu025169;	Mon, 13 Feb 2012 08:53:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1adeebf9e6bd3d74a2f6e35937d4c6ada4212ccd
Message-ID: <1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 20 of 23] libxl: add
	libxl_domain_build_info_init_type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 1adeebf9e6bd3d74a2f6e35937d4c6ada4212ccd
# Parent  871a9c864b558f554f6d72cef59cfc8e6af2d81a
libxl: add libxl_domain_build_info_init_type

Use instead of parameterising libxl_domain_build_info_init. This allows callers
to initialise a libxl_domain_build_info but not to commit to a particular type
later on (e.g. after they've parsed the domain config)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
@@ -389,8 +389,9 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                          const libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
@@ -69,23 +69,29 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                                  const libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = c_info->type;
+    b_info->type = -1;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
+}
+
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type)
+{
+    assert(b_info->type == -1);
+    b_info->type = type;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 0;
+        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
         break;
     default:
         abort();
diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:34 2012 +0000
@@ -707,7 +707,8 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+    libxl_domain_build_info_init(&dm_config.b_info);
+    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
 
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
diff -r 871a9c864b55 -r 1adeebf9e6bd tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -584,7 +584,8 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_build_info_init(b_info, c_info);
+    libxl_domain_build_info_init(b_info);
+    libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -701,7 +702,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    switch(c_info->type) {
+    switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9V-0003oP-ND; Mon, 13 Feb 2012 16:53: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 1Rwz9N-0003aJ-CF
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7277 invoked from network); 13 Feb 2012 16:50:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901532"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:11 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHw025169;	Mon, 13 Feb 2012 08:53:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: ba485f9fce317ba31a96b407f5712ba62239e223
Message-ID: <ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion key
 member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID ba485f9fce317ba31a96b407f5712ba62239e223
# Parent  0751a69b3ef2264844500c47151b5e16a358e02d
libxl: idl: generate KeyedUnion key member as part of the KeyedUnion

Rather than specifying it twice in the IDL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar.type, ty.keyvar.name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
@@ -214,7 +214,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    MemKB),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
@@ -421,7 +420,6 @@ libxl_event = Struct("event",[
     ("domid",    libxl_domid),
     ("domuuid",  libxl_uuid),
     ("for_user", libxl_ev_user),
-    ("type",     libxl_event_type),
     ("u", KeyedUnion(None, libxl_event_type, "type",
           [("domain_shutdown", Struct(None, [
                                              ("shutdown_reason", uint8),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9V-0003oP-ND; Mon, 13 Feb 2012 16:53: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 1Rwz9N-0003aJ-CF
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329151850!52531776!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7277 invoked from network); 13 Feb 2012 16:50:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:50:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21901532"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:11 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHw025169;	Mon, 13 Feb 2012 08:53:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: ba485f9fce317ba31a96b407f5712ba62239e223
Message-ID: <ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion key
 member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID ba485f9fce317ba31a96b407f5712ba62239e223
# Parent  0751a69b3ef2264844500c47151b5e16a358e02d
libxl: idl: generate KeyedUnion key member as part of the KeyedUnion

Rather than specifying it twice in the IDL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar.type, ty.keyvar.name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
@@ -214,7 +214,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    MemKB),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
@@ -421,7 +420,6 @@ libxl_event = Struct("event",[
     ("domid",    libxl_domid),
     ("domuuid",  libxl_uuid),
     ("for_user", libxl_ev_user),
-    ("type",     libxl_event_type),
     ("u", KeyedUnion(None, libxl_event_type, "type",
           [("domain_shutdown", Struct(None, [
                                              ("shutdown_reason", uint8),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9V-0003nG-3v; Mon, 13 Feb 2012 16:53:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9N-0003V2-1w
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29341 invoked from network); 13 Feb 2012 16:53:06 -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;
	13 Feb 2012 16:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526884"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:04 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHp025169;	Mon, 13 Feb 2012 08:53:03 -0800
MIME-Version: 1.0
X-Mercurial-Node: ca432f4ad9f58b0a0a87045a680e37a123bbda11
Message-ID: <ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 15 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148141 0
# Node ID ca432f4ad9f58b0a0a87045a680e37a123bbda11
# Parent  a20f15f1889ba1dda88d64509694818a0793cf8a
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

This just covers the obvious ones.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:49:01 2012 +0000
@@ -352,6 +352,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     rc = ERROR_INVAL;
     if (!disk)
         goto out;
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:49:01 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
@@ -88,17 +87,7 @@ void libxl_domain_build_info_init(libxl_
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
-        b_info->u.hvm.pae = 1;
-        b_info->u.hvm.apic = 1;
-        b_info->u.hvm.acpi = 1;
-        b_info->u.hvm.acpi_s3 = 1;
-        b_info->u.hvm.acpi_s4 = 1;
-        b_info->u.hvm.nx = 1;
-        b_info->u.hvm.viridian = 0;
-        b_info->u.hvm.hpet = 1;
-        b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
@@ -106,9 +95,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
-        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;
@@ -141,6 +128,8 @@ int libxl__domain_build_info_setdefault(
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->target_memkb = b_info->max_memkb;
 
+    libxl_defbool_setdefault(&b_info->disable_migrate, false);
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
@@ -151,6 +140,19 @@ int libxl__domain_build_info_setdefault(
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
 
+        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
@@ -165,6 +167,7 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
         if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
@@ -220,11 +223,11 @@ int libxl__domain_build(libxl__gc *gc,
 
         localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
-        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[1] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
-        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[3] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
-        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[5] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -426,7 +429,6 @@ retry_transaction:
     xs_rm(ctx->xsh, t, dom_path);
     libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
 
-
     xs_rm(ctx->xsh, t, vm_path);
     libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
@@ -673,7 +675,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
+        libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         int rc;
         rc = libxl__e820_alloc(gc, domid, d_config);
         if (rc)
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:49:01 2012 +0000
@@ -192,7 +192,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.boot) {
             flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -202,7 +202,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (b_info->u.hvm.acpi) {
+        if (libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -427,7 +427,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-boot",
                     libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -437,7 +437,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (!b_info->u.hvm.acpi) {
+        if (!libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-no-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -939,7 +939,7 @@ int libxl__create_device_model(libxl__gc
         b_info->device_model_version
         == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
         libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                        "%d", !b_info->u.hvm.xen_platform_pci);
+                    "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:01 2012 +0000
@@ -88,7 +88,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         abort();
     }
     xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if ( info->disable_migrate )
+    if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -292,7 +292,7 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->apic_mode = info->u.hvm.apic;
+    va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
@@ -302,14 +302,19 @@ static int hvm_build_set_params(xc_inter
 
     xc_get_hvm_param(handle, domid, HVM_PARAM_STORE_PFN, store_mfn);
     xc_get_hvm_param(handle, domid, HVM_PARAM_CONSOLE_PFN, console_mfn);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED, info->u.hvm.pae);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED,
+                     libxl_defbool_val(info->u.hvm.pae));
 #if defined(__i386__) || defined(__x86_64__)
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN,
+                     libxl_defbool_val(info->u.hvm.viridian));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
+                     libxl_defbool_val(info->u.hvm.hpet));
 #endif
     xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
+                     libxl_defbool_val(info->u.hvm.vpt_align));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
+                     libxl_defbool_val(info->u.hvm.nested_hvm));
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
 
@@ -400,7 +405,7 @@ int libxl__domain_restore_common(libxl__
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
-        pae = info->u.hvm.pae;
+        pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Feb 13 15:49:01 2012 +0000
@@ -1378,7 +1378,7 @@ int libxl__e820_alloc(libxl__gc *gc, uin
         return ERROR_INVAL;
 
     b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
+    if (!libxl_defbool_val(b_info->u.pv.e820_host))
         return ERROR_INVAL;
 
     rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:01 2012 +0000
@@ -212,7 +212,7 @@ libxl_domain_build_info = Struct("domain
     ("target_memkb",    MemKB),
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
-    ("disable_migrate", bool),
+    ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     
@@ -230,19 +230,19 @@ libxl_domain_build_info = Struct("domain
     ("extra_hvm",        libxl_string_list),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
-                [("hvm", Struct(None, [("firmware", string),
-                                       ("pae", bool),
-                                       ("apic", bool),
-                                       ("acpi", bool),
-                                       ("acpi_s3", bool),
-                                       ("acpi_s4", bool),
-                                       ("nx", bool),
-                                       ("viridian", bool),
-                                       ("timeoffset", string),
-                                       ("hpet", bool),
-                                       ("vpt_align", bool),
-                                       ("timer_mode", libxl_timer_mode),
-                                       ("nested_hvm", bool),
+                [("hvm", Struct(None, [("firmware",         string),
+                                       ("pae",              libxl_defbool),
+                                       ("apic",             libxl_defbool),
+                                       ("acpi",             libxl_defbool),
+                                       ("acpi_s3",          libxl_defbool),
+                                       ("acpi_s4",          libxl_defbool),
+                                       ("nx",               libxl_defbool),
+                                       ("viridian",         libxl_defbool),
+                                       ("timeoffset",       string),
+                                       ("hpet",             libxl_defbool),
+                                       ("vpt_align",        libxl_defbool),
+                                       ("timer_mode",       libxl_timer_mode),
+                                       ("nested_hvm",       libxl_defbool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
@@ -256,13 +256,13 @@ libxl_domain_build_info = Struct("domain
                                        
                                        ("serial",           string),
                                        ("boot",             string),
-                                       ("usb",              bool),
+                                       ("usb",              libxl_defbool),
                                        # usbdevice:
                                        # - "tablet" for absolute mouse,
                                        # - "mouse" for PS/2 protocol relative mouse
                                        ("usbdevice",        string),
                                        ("soundhw",          string),
-                                       ("xen_platform_pci", bool),
+                                       ("xen_platform_pci", libxl_defbool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", MemKB),
@@ -272,7 +272,7 @@ libxl_domain_build_info = Struct("domain
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
-                                      ("e820_host", bool),
+                                      ("e820_host", libxl_defbool),
                                       ])),
                  ])),
     ],
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:01 2012 +0000
@@ -673,8 +673,7 @@ static void parse_config_data(const char
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
-        b_info->disable_migrate = l;
+    xlu_cfg_get_defbool(config, "nomigrate", &b_info->disable_migrate, 0);
 
     if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
         const char *s = libxl_tsc_mode_to_string(l);
@@ -710,24 +709,16 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
-        if (!xlu_cfg_get_long (config, "pae", &l, 0))
-            b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l, 0))
-            b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
-            b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
-            b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
-            b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l, 0))
-            b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
-            b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
-            b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
-            b_info->u.hvm.vpt_align = l;
+
+        xlu_cfg_get_defbool(config, "pae", &b_info->u.hvm.pae, 0);
+        xlu_cfg_get_defbool(config, "apic", &b_info->u.hvm.apic, 0);
+        xlu_cfg_get_defbool(config, "acpi", &b_info->u.hvm.acpi, 0);
+        xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
+        xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
+        xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
+        xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
+        xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
+        xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
 
         if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
             const char *s = libxl_timer_mode_to_string(l);
@@ -752,8 +743,7 @@ static void parse_config_data(const char
             }
         }
 
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
-            b_info->u.hvm.nested_hvm = l;
+        xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -990,19 +980,10 @@ skip_vfb:
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
-        switch (c_info->type) {
-        case LIBXL_DOMAIN_TYPE_HVM:
-            fprintf(stderr, "Can't do e820_host in HVM mode!");
-            break;
-        case LIBXL_DOMAIN_TYPE_PV:
-            if (l)
-                b_info->u.pv.e820_host = true;
-            break;
-        default:
-            abort();
-        }
-    }
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
+        xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
+    }
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -1020,7 +1001,7 @@ skip_vfb:
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
-            b_info->u.pv.e820_host = true;
+            libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
@@ -1212,12 +1193,12 @@ skip_vfb:
             b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
-        if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            b_info->u.hvm.usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
+        xlu_cfg_replace_string (config, "usbdevice",
+                                &b_info->u.hvm.usbdevice, 0);
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            b_info->u.hvm.xen_platform_pci = l;
+        xlu_cfg_get_defbool(config, "xen_platform_pci",
+                            &b_info->u.hvm.xen_platform_pci, 0);
     }
 
     xlu_cfg_destroy(config);
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:01 2012 +0000
@@ -71,7 +71,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
     printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+    printf("\t(nomigrate %s)\n",
+           libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
         int i;
@@ -91,16 +92,22 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
         printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
         printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
+        printf("\t\t\t(apic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.apic));
+        printf("\t\t\t(acpi %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.acpi));
+        printf("\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
+        printf("\t\t\t(viridian %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.viridian));
+        printf("\t\t\t(hpet %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.hpet));
+        printf("\t\t\t(vpt_align %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vpt_align));
         printf("\t\t\t(timer_mode %s)\n",
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(nestedhvm %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
 
@@ -125,7 +132,7 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
         printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
@@ -134,7 +141,8 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t\t(e820_host %s)\n",
+               libxl_defbool_to_string(b_info->u.pv.e820_host));
         printf("\t\t)\n");
         break;
     default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9V-0003nG-3v; Mon, 13 Feb 2012 16:53:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9N-0003V2-1w
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29341 invoked from network); 13 Feb 2012 16:53:06 -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;
	13 Feb 2012 16:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526884"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:04 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHp025169;	Mon, 13 Feb 2012 08:53:03 -0800
MIME-Version: 1.0
X-Mercurial-Node: ca432f4ad9f58b0a0a87045a680e37a123bbda11
Message-ID: <ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 15 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329148141 0
# Node ID ca432f4ad9f58b0a0a87045a680e37a123bbda11
# Parent  a20f15f1889ba1dda88d64509694818a0793cf8a
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

This just covers the obvious ones.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Mon Feb 13 15:49:01 2012 +0000
@@ -352,6 +352,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     rc = ERROR_INVAL;
     if (!disk)
         goto out;
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 15:49:01 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
@@ -88,17 +87,7 @@ void libxl_domain_build_info_init(libxl_
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
-        b_info->u.hvm.pae = 1;
-        b_info->u.hvm.apic = 1;
-        b_info->u.hvm.acpi = 1;
-        b_info->u.hvm.acpi_s3 = 1;
-        b_info->u.hvm.acpi_s4 = 1;
-        b_info->u.hvm.nx = 1;
-        b_info->u.hvm.viridian = 0;
-        b_info->u.hvm.hpet = 1;
-        b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
@@ -106,9 +95,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
-        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;
@@ -141,6 +128,8 @@ int libxl__domain_build_info_setdefault(
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->target_memkb = b_info->max_memkb;
 
+    libxl_defbool_setdefault(&b_info->disable_migrate, false);
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
@@ -151,6 +140,19 @@ int libxl__domain_build_info_setdefault(
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
 
+        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
@@ -165,6 +167,7 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
         if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
@@ -220,11 +223,11 @@ int libxl__domain_build(libxl__gc *gc,
 
         localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
-        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[1] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
-        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[3] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
-        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[5] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -426,7 +429,6 @@ retry_transaction:
     xs_rm(ctx->xsh, t, dom_path);
     libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
 
-
     xs_rm(ctx->xsh, t, vm_path);
     libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
@@ -673,7 +675,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
+        libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         int rc;
         rc = libxl__e820_alloc(gc, domid, d_config);
         if (rc)
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 15:49:01 2012 +0000
@@ -192,7 +192,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.boot) {
             flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -202,7 +202,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (b_info->u.hvm.acpi) {
+        if (libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -427,7 +427,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-boot",
                     libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -437,7 +437,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (!b_info->u.hvm.acpi) {
+        if (!libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-no-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -939,7 +939,7 @@ int libxl__create_device_model(libxl__gc
         b_info->device_model_version
         == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
         libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                        "%d", !b_info->u.hvm.xen_platform_pci);
+                    "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:01 2012 +0000
@@ -88,7 +88,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         abort();
     }
     xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if ( info->disable_migrate )
+    if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -292,7 +292,7 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->apic_mode = info->u.hvm.apic;
+    va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
@@ -302,14 +302,19 @@ static int hvm_build_set_params(xc_inter
 
     xc_get_hvm_param(handle, domid, HVM_PARAM_STORE_PFN, store_mfn);
     xc_get_hvm_param(handle, domid, HVM_PARAM_CONSOLE_PFN, console_mfn);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED, info->u.hvm.pae);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED,
+                     libxl_defbool_val(info->u.hvm.pae));
 #if defined(__i386__) || defined(__x86_64__)
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN,
+                     libxl_defbool_val(info->u.hvm.viridian));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
+                     libxl_defbool_val(info->u.hvm.hpet));
 #endif
     xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
+                     libxl_defbool_val(info->u.hvm.vpt_align));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
+                     libxl_defbool_val(info->u.hvm.nested_hvm));
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
 
@@ -400,7 +405,7 @@ int libxl__domain_restore_common(libxl__
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
-        pae = info->u.hvm.pae;
+        pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Feb 13 15:49:01 2012 +0000
@@ -1378,7 +1378,7 @@ int libxl__e820_alloc(libxl__gc *gc, uin
         return ERROR_INVAL;
 
     b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
+    if (!libxl_defbool_val(b_info->u.pv.e820_host))
         return ERROR_INVAL;
 
     rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:01 2012 +0000
@@ -212,7 +212,7 @@ libxl_domain_build_info = Struct("domain
     ("target_memkb",    MemKB),
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
-    ("disable_migrate", bool),
+    ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     
@@ -230,19 +230,19 @@ libxl_domain_build_info = Struct("domain
     ("extra_hvm",        libxl_string_list),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
-                [("hvm", Struct(None, [("firmware", string),
-                                       ("pae", bool),
-                                       ("apic", bool),
-                                       ("acpi", bool),
-                                       ("acpi_s3", bool),
-                                       ("acpi_s4", bool),
-                                       ("nx", bool),
-                                       ("viridian", bool),
-                                       ("timeoffset", string),
-                                       ("hpet", bool),
-                                       ("vpt_align", bool),
-                                       ("timer_mode", libxl_timer_mode),
-                                       ("nested_hvm", bool),
+                [("hvm", Struct(None, [("firmware",         string),
+                                       ("pae",              libxl_defbool),
+                                       ("apic",             libxl_defbool),
+                                       ("acpi",             libxl_defbool),
+                                       ("acpi_s3",          libxl_defbool),
+                                       ("acpi_s4",          libxl_defbool),
+                                       ("nx",               libxl_defbool),
+                                       ("viridian",         libxl_defbool),
+                                       ("timeoffset",       string),
+                                       ("hpet",             libxl_defbool),
+                                       ("vpt_align",        libxl_defbool),
+                                       ("timer_mode",       libxl_timer_mode),
+                                       ("nested_hvm",       libxl_defbool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
@@ -256,13 +256,13 @@ libxl_domain_build_info = Struct("domain
                                        
                                        ("serial",           string),
                                        ("boot",             string),
-                                       ("usb",              bool),
+                                       ("usb",              libxl_defbool),
                                        # usbdevice:
                                        # - "tablet" for absolute mouse,
                                        # - "mouse" for PS/2 protocol relative mouse
                                        ("usbdevice",        string),
                                        ("soundhw",          string),
-                                       ("xen_platform_pci", bool),
+                                       ("xen_platform_pci", libxl_defbool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", MemKB),
@@ -272,7 +272,7 @@ libxl_domain_build_info = Struct("domain
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
-                                      ("e820_host", bool),
+                                      ("e820_host", libxl_defbool),
                                       ])),
                  ])),
     ],
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:01 2012 +0000
@@ -673,8 +673,7 @@ static void parse_config_data(const char
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
-        b_info->disable_migrate = l;
+    xlu_cfg_get_defbool(config, "nomigrate", &b_info->disable_migrate, 0);
 
     if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
         const char *s = libxl_tsc_mode_to_string(l);
@@ -710,24 +709,16 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
-        if (!xlu_cfg_get_long (config, "pae", &l, 0))
-            b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l, 0))
-            b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
-            b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
-            b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
-            b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l, 0))
-            b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
-            b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
-            b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
-            b_info->u.hvm.vpt_align = l;
+
+        xlu_cfg_get_defbool(config, "pae", &b_info->u.hvm.pae, 0);
+        xlu_cfg_get_defbool(config, "apic", &b_info->u.hvm.apic, 0);
+        xlu_cfg_get_defbool(config, "acpi", &b_info->u.hvm.acpi, 0);
+        xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
+        xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
+        xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
+        xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
+        xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
+        xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
 
         if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
             const char *s = libxl_timer_mode_to_string(l);
@@ -752,8 +743,7 @@ static void parse_config_data(const char
             }
         }
 
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
-            b_info->u.hvm.nested_hvm = l;
+        xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -990,19 +980,10 @@ skip_vfb:
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
-        switch (c_info->type) {
-        case LIBXL_DOMAIN_TYPE_HVM:
-            fprintf(stderr, "Can't do e820_host in HVM mode!");
-            break;
-        case LIBXL_DOMAIN_TYPE_PV:
-            if (l)
-                b_info->u.pv.e820_host = true;
-            break;
-        default:
-            abort();
-        }
-    }
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
+        xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
+    }
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -1020,7 +1001,7 @@ skip_vfb:
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
-            b_info->u.pv.e820_host = true;
+            libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
@@ -1212,12 +1193,12 @@ skip_vfb:
             b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
-        if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            b_info->u.hvm.usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
+        xlu_cfg_replace_string (config, "usbdevice",
+                                &b_info->u.hvm.usbdevice, 0);
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            b_info->u.hvm.xen_platform_pci = l;
+        xlu_cfg_get_defbool(config, "xen_platform_pci",
+                            &b_info->u.hvm.xen_platform_pci, 0);
     }
 
     xlu_cfg_destroy(config);
diff -r a20f15f1889b -r ca432f4ad9f5 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:00 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:01 2012 +0000
@@ -71,7 +71,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
     printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+    printf("\t(nomigrate %s)\n",
+           libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
         int i;
@@ -91,16 +92,22 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
         printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
         printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
+        printf("\t\t\t(apic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.apic));
+        printf("\t\t\t(acpi %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.acpi));
+        printf("\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
+        printf("\t\t\t(viridian %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.viridian));
+        printf("\t\t\t(hpet %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.hpet));
+        printf("\t\t\t(vpt_align %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vpt_align));
         printf("\t\t\t(timer_mode %s)\n",
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(nestedhvm %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
 
@@ -125,7 +132,7 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
         printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
@@ -134,7 +141,8 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t\t(e820_host %s)\n",
+               libxl_defbool_to_string(b_info->u.pv.e820_host));
         printf("\t\t)\n");
         break;
     default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9X-0003sl-Od; Mon, 13 Feb 2012 16:53:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9R-0003Yn-49
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329151988!8965519!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5114 invoked from network); 13 Feb 2012 16:53:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526906"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:08 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHt025169;	Mon, 13 Feb 2012 08:53:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: 871a9c864b558f554f6d72cef59cfc8e6af2d81a
Message-ID: <871a9c864b558f554f6d.1329151985@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 19 of 23] libxl: switch device model selection
 over to libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 871a9c864b558f554f6d72cef59cfc8e6af2d81a
# Parent  ba3ab3558a5d84fef2676b82d641a04615a9d786
libxl: switch device model selection over to libxl_defbool

This allows it to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[since last v -- ERROR_INVAL on stubdomains + !traditional qemu]

diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -2713,7 +2713,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (b_info->device_model_stubdomain)
+        if (libxl_defbool_val(b_info->device_model_stubdomain))
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
@@ -80,9 +80,6 @@ void libxl_domain_build_info_init(libxl_
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
-    b_info->device_model_stubdomain = false;
-    b_info->device_model = NULL;
-
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
@@ -102,6 +99,17 @@ int libxl__domain_build_info_setdefault(
         b_info->device_model_version =
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version !=
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+        libxl_defbool_val(b_info->device_model_stubdomain)) {
+        LIBXL__LOG(CTX, XTL_ERROR,
+            "device model stubdomains require \"qemu-xen-traditional\"");
+        return ERROR_INVAL;
+    }
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:34 2012 +0000
@@ -39,7 +39,7 @@ const char *libxl__domain_device_model(l
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
 
-    if (info->device_model_stubdomain)
+    if (libxl_defbool_val(info->device_model_stubdomain))
         return NULL;
 
     if (info->device_model) {
@@ -905,7 +905,7 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (b_info->device_model_stubdomain) {
+    if (libxl_defbool_val(b_info->device_model_stubdomain)) {
         rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
@@ -217,8 +217,8 @@ libxl_domain_build_info = Struct("domain
     ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
+    ("device_model_stubdomain", libxl_defbool),
+    # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
 
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -1118,8 +1118,8 @@ skip_vfb:
         }
     } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        b_info->device_model_stubdomain = l;
+    xlu_cfg_get_defbool (config, "device_model_stubdomain_override",
+                         &b_info->device_model_stubdomain, 0);
 
     if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel",
                              &buf, 0)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1Rwz9X-0003sl-Od; Mon, 13 Feb 2012 16:53:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9R-0003Yn-49
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329151988!8965519!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5114 invoked from network); 13 Feb 2012 16:53:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526906"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:08 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHt025169;	Mon, 13 Feb 2012 08:53:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: 871a9c864b558f554f6d72cef59cfc8e6af2d81a
Message-ID: <871a9c864b558f554f6d.1329151985@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 19 of 23] libxl: switch device model selection
 over to libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 871a9c864b558f554f6d72cef59cfc8e6af2d81a
# Parent  ba3ab3558a5d84fef2676b82d641a04615a9d786
libxl: switch device model selection over to libxl_defbool

This allows it to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[since last v -- ERROR_INVAL on stubdomains + !traditional qemu]

diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -2713,7 +2713,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (b_info->device_model_stubdomain)
+        if (libxl_defbool_val(b_info->device_model_stubdomain))
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
@@ -80,9 +80,6 @@ void libxl_domain_build_info_init(libxl_
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
-    b_info->device_model_stubdomain = false;
-    b_info->device_model = NULL;
-
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
@@ -102,6 +99,17 @@ int libxl__domain_build_info_setdefault(
         b_info->device_model_version =
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version !=
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+        libxl_defbool_val(b_info->device_model_stubdomain)) {
+        LIBXL__LOG(CTX, XTL_ERROR,
+            "device model stubdomains require \"qemu-xen-traditional\"");
+        return ERROR_INVAL;
+    }
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:34 2012 +0000
@@ -39,7 +39,7 @@ const char *libxl__domain_device_model(l
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
 
-    if (info->device_model_stubdomain)
+    if (libxl_defbool_val(info->device_model_stubdomain))
         return NULL;
 
     if (info->device_model) {
@@ -905,7 +905,7 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (b_info->device_model_stubdomain) {
+    if (libxl_defbool_val(b_info->device_model_stubdomain)) {
         rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
@@ -217,8 +217,8 @@ libxl_domain_build_info = Struct("domain
     ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
+    ("device_model_stubdomain", libxl_defbool),
+    # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
 
diff -r ba3ab3558a5d -r 871a9c864b55 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:33 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -1118,8 +1118,8 @@ skip_vfb:
         }
     } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        b_info->device_model_stubdomain = l;
+    xlu_cfg_get_defbool (config, "device_model_stubdomain_override",
+                         &b_info->device_model_stubdomain, 0);
 
     if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel",
                              &buf, 0)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9Z-0003vA-C7; Mon, 13 Feb 2012 16:53:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9S-0003aD-7C
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329151988!8965519!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5152 invoked from network); 13 Feb 2012 16:53:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526912"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:10 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHv025169;	Mon, 13 Feb 2012 08:53:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0751a69b3ef2264844500c47151b5e16a358e02d
Message-ID: <0751a69b3ef226484450.1329151987@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 21 of 23] libxl: Make IDL KeyedUnion keyvar an
	idl.Field
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 0751a69b3ef2264844500c47151b5e16a358e02d
# Parent  1adeebf9e6bd3d74a2f6e35937d4c6ada4212ccd
libxl: Make IDL KeyedUnion keyvar an idl.Field

This is more logical than having keyvar_name and keyvar_type members.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 16:27:34 2012 +0000
@@ -31,7 +31,7 @@ def gen_rand_init(ty, v, indent = "    "
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
@@ -56,7 +56,7 @@ def libxl_C_type_dispose(ty, v, indent =
     if isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
@@ -86,7 +86,7 @@ def libxl_C_type_gen_json(ty, v, indent 
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
@@ -206,8 +206,9 @@ class KeyedUnion(Aggregate):
         if not isinstance(keyvar_type, Enumeration):
             raise ValueError
 
-        self.keyvar_name = keyvar_name
-        self.keyvar_type = keyvar_type
+        kv_kwargs = dict([(x.lstrip('keyvar_'),y) for (x,y) in kwargs.items() if x.startswith('keyvar_')])
+        
+        self.keyvar = Field(keyvar_type, keyvar_name, **kv_kwargs)
 
         for f in fields:
             # (name, enum, type)
diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
@@ -128,10 +128,9 @@ idl.KeyedUnion
  where the currently valid member of the union can be determined based
  upon another member in the containing type.
 
- The KeyedUnion.keyvar_name must contain the name of the member of the
+ The KeyedUnion.keyvar contains an idl.type the member of the
  containing type which determines the valid member of the union. The
- member referenced by KeyedUnion.keyvar_name has type
- KeyedUnion.keyvar_type which must be an instance of the Enumeration type.
+ must be an instance of the Enumeration type.
 
 Standard Types
 --------------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9Z-0003vA-C7; Mon, 13 Feb 2012 16:53:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9S-0003aD-7C
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329151988!8965519!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5152 invoked from network); 13 Feb 2012 16:53:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526912"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:10 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHv025169;	Mon, 13 Feb 2012 08:53:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0751a69b3ef2264844500c47151b5e16a358e02d
Message-ID: <0751a69b3ef226484450.1329151987@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 21 of 23] libxl: Make IDL KeyedUnion keyvar an
	idl.Field
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 0751a69b3ef2264844500c47151b5e16a358e02d
# Parent  1adeebf9e6bd3d74a2f6e35937d4c6ada4212ccd
libxl: Make IDL KeyedUnion keyvar an idl.Field

This is more logical than having keyvar_name and keyvar_type members.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentest.py	Mon Feb 13 16:27:34 2012 +0000
@@ -31,7 +31,7 @@ def gen_rand_init(ty, v, indent = "    "
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
@@ -56,7 +56,7 @@ def libxl_C_type_dispose(ty, v, indent =
     if isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
@@ -86,7 +86,7 @@ def libxl_C_type_gen_json(ty, v, indent 
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
@@ -206,8 +206,9 @@ class KeyedUnion(Aggregate):
         if not isinstance(keyvar_type, Enumeration):
             raise ValueError
 
-        self.keyvar_name = keyvar_name
-        self.keyvar_type = keyvar_type
+        kv_kwargs = dict([(x.lstrip('keyvar_'),y) for (x,y) in kwargs.items() if x.startswith('keyvar_')])
+        
+        self.keyvar = Field(keyvar_type, keyvar_name, **kv_kwargs)
 
         for f in fields:
             # (name, enum, type)
diff -r 1adeebf9e6bd -r 0751a69b3ef2 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
@@ -128,10 +128,9 @@ idl.KeyedUnion
  where the currently valid member of the union can be determined based
  upon another member in the containing type.
 
- The KeyedUnion.keyvar_name must contain the name of the member of the
+ The KeyedUnion.keyvar contains an idl.type the member of the
  containing type which determines the valid member of the union. The
- member referenced by KeyedUnion.keyvar_name has type
- KeyedUnion.keyvar_type which must be an instance of the Enumeration type.
+ must be an instance of the Enumeration type.
 
 Standard Types
 --------------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9a-0003wS-0p; Mon, 13 Feb 2012 16:53:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9U-0003ci-6Z
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329151988!8965519!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5229 invoked from network); 13 Feb 2012 16:53:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526918"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:12 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHx025169;	Mon, 13 Feb 2012 08:53:11 -0800
MIME-Version: 1.0
X-Mercurial-Node: 50c87c40031ca91265812881b18cecae7cdde138
Message-ID: <50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init and
 libxl_FOO_init_FIELD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 50c87c40031ca91265812881b18cecae7cdde138
# Parent  ba485f9fce317ba31a96b407f5712ba62239e223
libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
@@ -78,6 +78,88 @@ def libxl_C_type_dispose(ty, v, indent =
         s = indent + s
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
+def libxl_init_members(ty, nesting = 0):
+    """Returns a list of members of ty which require a separate init"""
+
+    if isinstance(ty, idl.Aggregate):
+        return [f for f in ty.fields if not f.const and isinstance(f.type,idl.KeyedUnion)]
+    else:
+        return []
+    
+def _libxl_C_type_init(ty, v, indent = "    ", parent = None, subinit=False):
+    s = ""
+    if isinstance(ty, idl.KeyedUnion):
+        if parent is None:
+            raise Exception("KeyedUnion type must have a parent")
+        if subinit:
+            s += "switch (%s) {\n" % (parent + ty.keyvar.name)
+            for f in ty.fields:
+                (nparent,fexpr) = ty.member(v, f, parent is None)
+                s += "case %s:\n" % f.enumname
+                s += _libxl_C_type_init(f.type, fexpr, "    ", nparent)
+                s += "    break;\n"
+            s += "}\n"
+        else:
+            if ty.keyvar.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.init_val)
+            elif ty.keyvar.type.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.type.init_val)
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.init_fn is None):
+        for f in [f for f in ty.fields if not f.const]:
+            (nparent,fexpr) = ty.member(v, f, parent is None)
+            if f.init_val is not None:
+                s += "%s = %s;\n" % (fexpr, f.init_val)
+            else:
+                s += _libxl_C_type_init(f.type, fexpr, "", nparent)
+    else:
+        if ty.init_val is not None:
+            s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), ty.init_val)
+        elif ty.init_fn is not None:
+            s += "%s(%s);\n" % (ty.init_fn, ty.pass_arg(v, parent is None))
+
+    if s != "":
+        s = indent + s
+    return s.replace("\n", "\n%s" % indent).rstrip(indent)
+
+def libxl_C_type_init(ty):
+    s = ""
+    s += "void %s(%s)\n" % (ty.init_fn, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))
+    s += "{\n"
+    s += "    memset(p, '\\0', sizeof(*p));\n"
+    s += _libxl_C_type_init(ty, "p")
+    s += "}\n"
+    s += "\n"
+    return s
+
+def libxl_C_type_member_init(ty, field):
+    if not isinstance(field.type, idl.KeyedUnion):
+        raise Exception("Only KeyedUnion is supported for member init")
+
+    ku = field.type
+    
+    s = ""
+    s += "void %s(%s, %s)\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                ty.make_arg("p", passby=idl.PASS_BY_REFERENCE),
+                                ku.keyvar.type.make_arg(ku.keyvar.name))
+    s += "{\n"
+    
+    if ku.keyvar.init_val:
+        init_val = ku.keyvar.init_val
+    elif ku.keyvar.type.init_val:
+        init_val = ku.keyvar.type.init_val
+    else:
+        init_val = None
+        
+    if init_val is not None:
+        (nparent,fexpr) = ty.member(ty.pass_arg("p"), ku.keyvar, isref=True)
+        s += "    assert(%s == %s);\n" % (fexpr, init_val)
+        s += "    %s = %s;\n" % (fexpr, ku.keyvar.name)
+    (nparent,fexpr) = ty.member(ty.pass_arg("p"), field, isref=True)
+    s += _libxl_C_type_init(ku, fexpr, parent=nparent, subinit=True)
+    s += "}\n"
+    s += "\n"
+    return s
+
 def libxl_C_type_gen_json(ty, v, indent = "    ", parent = None):
     s = ""
     if parent is None:
@@ -199,6 +281,15 @@ if __name__ == '__main__':
         f.write(libxl_C_type_define(ty) + ";\n")
         if ty.dispose_fn is not None:
             f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
+        if ty.init_fn is not None:
+            f.write("void %s(%s);\n" % (ty.init_fn, ty.make_arg("p")))
+            for field in libxl_init_members(ty):
+                if not isinstance(field.type, idl.KeyedUnion):
+                    raise Exception("Only KeyedUnion is supported for member init")
+                ku = field.type
+                f.write("void %s(%s, %s);\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                               ty.make_arg("p"),
+                                               ku.keyvar.type.make_arg(ku.keyvar.name)))
         if ty.json_fn is not None:
             f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
         if isinstance(ty, idl.Enumeration):
@@ -227,7 +318,7 @@ if __name__ == '__main__':
 
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
-    for ty in [ty for ty in types+builtins if ty.json_fn is not None]:
+    for ty in [ty for ty in types if ty.json_fn is not None]:
         f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
@@ -264,6 +355,11 @@ if __name__ == '__main__':
         f.write("    memset(p, LIBXL_DTOR_POISON, sizeof(*p));\n")
         f.write("}\n")
         f.write("\n")
+        
+    for ty in [t for t in types if t.init_fn is not None and t.autogenerate_init_fn]:
+        f.write(libxl_C_type_init(ty))
+        for field in libxl_init_members(ty):
+            f.write(libxl_C_type_member_init(ty, field))
 
     for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("const char *%s_to_string(%s e)\n" % (ty.typename, ty.typename))
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/idl.py
--- a/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
@@ -51,6 +51,10 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
+        self.init_fn = kwargs.setdefault('init_fn', None)
+        self.init_val = kwargs.setdefault('init_val', None)
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', False)
+
         if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
@@ -144,12 +148,20 @@ class Field(object):
         self.name = name
         self.const = kwargs.setdefault('const', False)
         self.enumname = kwargs.setdefault('enumname', None)
+        self.init_val = kwargs.setdefault('init_val', None)
 
 class Aggregate(Type):
     """A type containing a collection of other types"""
     def __init__(self, kind, typename, fields, **kwargs):
         Type.__init__(self, typename, **kwargs)
 
+        if self.typename is not None and self.dir in [DIR_IN, DIR_BOTH]:
+            self.init_fn = kwargs.setdefault('init_fn', self.typename + "_init")
+        else:
+            self.init_fn = kwargs.setdefault('init_fn', None)
+
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', True)
+
         self.kind = kind
 
         self.fields = []
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
@@ -44,6 +44,22 @@ Type.autogenerate_dispose_fn: (default: 
  Indicates if the above named Type.dispose_fn should be
  autogenerated.
 
+Type.init_val: (default: None)
+
+ C expression for the value to initialise instances of this type to.
+
+ If present takes precendence over init_fn (see below).
+
+Type.init_fn: (default: typename + "_init" if dir in [IN, BOTH] and
+                        type != None)
+
+ The name of the C function which will initialist Type.
+
+Type.autogenerate_init_fn: (default: True if dir in [IN, BOTH])
+
+ Indicates if the above named Type.init_fn should be
+ autogenerated.
+
 Type.json_fn: (default: typename + "_gen_json" or None if type == None)
 
  The name of the C function which will generate a YAJL data structure
@@ -105,10 +121,13 @@ idl.Aggregate
 
  Each field has the following properties:
 
-  Field.type    The type of the member (a idl.Type).
-  Field.name    The name of the member (can be None for anonymous
-                fields).
-  Field.const   Boolean, true if the member is const.
+  Field.type     The type of the member (a idl.Type).
+  Field.name     The name of the member (can be None for anonymous
+                 fields).
+  Field.const    Boolean, true if the member is const.
+  Field.init_val The initialisation value for this field. Takes
+                 precendence over both Field.type.init_val and
+                 Field.type.init_fn.
 
 idl.Struct
 
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -1226,11 +1226,6 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-void libxl_device_disk_init(libxl_device_disk *disk)
-{
-    memset(disk, 0x00, sizeof(libxl_device_disk));
-}
-
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
     int rc;
@@ -1717,10 +1712,6 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-void libxl_device_nic_init(libxl_device_nic *nic)
-{
-    memset(nic, '\0', sizeof(*nic));
-}
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
 {
@@ -2141,10 +2132,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vkb_init(libxl_device_vkb *vkb)
-{
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
-}
 
 int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
 {
@@ -2253,10 +2240,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vfb_init(libxl_device_vfb *vfb)
-{
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-}
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
@@ -388,10 +388,6 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -527,7 +523,6 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  */
 
 /* Disks */
-void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
@@ -553,7 +548,6 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
@@ -565,7 +559,6 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -573,7 +566,6 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
@@ -581,7 +573,6 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
@@ -50,11 +50,6 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
-{
-    memset(c_info, '\0', sizeof(*c_info));
-}
-
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -69,35 +64,6 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
-{
-    memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = -1;
-
-    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
-
-}
-
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type)
-{
-    assert(b_info->type == -1);
-    b_info->type = type;
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
-        break;
-    default:
-        abort();
-    }
-}
-
 int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info)
 {
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_json.h	Mon Feb 13 16:27:34 2012 +0000
@@ -22,6 +22,20 @@
 #  include <yajl/yajl_version.h>
 #endif
 
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
+yajl_gen_status libxl_domid_gen_json(yajl_gen hand, libxl_domid *p);
+yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
+yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
+yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                                 libxl_cpuid_policy_list *p);
+yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
+yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
+                                              libxl_key_value_list *p);
+yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand,
+                                              libxl_file_reference *p);
+yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
+
 #include <_libxl_types_json.h>
 
 /* YAJL version check */
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Feb 13 16:27:34 2012 +0000
@@ -765,11 +765,6 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
-void libxl_device_pci_init(libxl_device_pci *pci)
-{
-    memset(pci, '\0', sizeof(*pci));
-}
-
 int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
 {
     return 0;
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
@@ -100,7 +100,7 @@ libxl_timer_mode = Enumeration("timer_mo
     (1, "no_delay_for_missed_ticks"),
     (2, "no_missed_ticks_pending"),
     (3, "one_missed_tick_pending"),
-    ])
+    ], init_val = "LIBXL_TIMER_MODE_DEFAULT")
 
 #
 # Complex libxl types
@@ -157,19 +157,19 @@ libxl_dominfo = Struct("dominfo",[
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
     ("cpupool",     uint32),
-    ], dispose_fn=None)
+    ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
     ("sched_id",    uint32),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vminfo = Struct("vminfo", [
     ("uuid", libxl_uuid),
     ("domid", libxl_domid),
-    ], dispose_fn=None)
+    ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_version_info = Struct("version_info", [
     ("xen_version_major", integer),
@@ -184,7 +184,7 @@ libxl_version_info = Struct("version_inf
     ("virt_start",        uint64),
     ("pagesize",          integer),
     ("commandline",       string),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
@@ -196,7 +196,9 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ])
+    ], dir=DIR_IN)
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
@@ -273,8 +275,8 @@ libxl_domain_build_info = Struct("domain
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", libxl_defbool),
                                       ])),
-                 ])),
-    ],
+                 ], keyvar_init_val = "-1")),
+    ], dir=DIR_IN
 )
 
 libxl_device_vfb = Struct("device_vfb", [
@@ -336,7 +338,7 @@ libxl_diskinfo = Struct("diskinfo", [
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_nicinfo = Struct("nicinfo", [
     ("backend", string),
@@ -348,7 +350,7 @@ libxl_nicinfo = Struct("nicinfo", [
     ("evtch", integer),
     ("rref_tx", integer),
     ("rref_rx", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
     ("vcpuid", uint32),
@@ -358,7 +360,7 @@ libxl_vcpuinfo = Struct("vcpuinfo", [
     ("running", bool),
     ("vcpu_time", uint64), # total vcpu time ran (ns)
     ("cpumap", libxl_cpumap), # current cpu's affinities
-    ])
+    ], dir=DIR_OUT)
 
 libxl_physinfo = Struct("physinfo", [
     ("threads_per_core", uint32),
@@ -383,16 +385,16 @@ libxl_cputopology = Struct("cputopology"
     ("core", uint32),
     ("socket", uint32),
     ("node", uint32),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
-    ], dispose_fn=None)
+    ], dispose_fn=None, init_fn=None)
 
 libxl_sched_credit2 = Struct("sched_credit2", [
     ("weight", integer),
-    ], dispose_fn=None)
+    ], dispose_fn=None, init_fn=None)
 
 libxl_sched_sedf = Struct("sched_sedf", [
     ("period", integer),
@@ -400,7 +402,7 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("latency", integer),
     ("extratime", integer),
     ("weight", integer),
-    ], dispose_fn=None)
+    ], dispose_fn=None, init_fn=None)
 
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9a-0003wS-0p; Mon, 13 Feb 2012 16:53:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9U-0003ci-6Z
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329151988!8965519!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5229 invoked from network); 13 Feb 2012 16:53:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526918"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:12 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHx025169;	Mon, 13 Feb 2012 08:53:11 -0800
MIME-Version: 1.0
X-Mercurial-Node: 50c87c40031ca91265812881b18cecae7cdde138
Message-ID: <50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init and
 libxl_FOO_init_FIELD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150454 0
# Node ID 50c87c40031ca91265812881b18cecae7cdde138
# Parent  ba485f9fce317ba31a96b407f5712ba62239e223
libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Feb 13 16:27:34 2012 +0000
@@ -78,6 +78,88 @@ def libxl_C_type_dispose(ty, v, indent =
         s = indent + s
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
+def libxl_init_members(ty, nesting = 0):
+    """Returns a list of members of ty which require a separate init"""
+
+    if isinstance(ty, idl.Aggregate):
+        return [f for f in ty.fields if not f.const and isinstance(f.type,idl.KeyedUnion)]
+    else:
+        return []
+    
+def _libxl_C_type_init(ty, v, indent = "    ", parent = None, subinit=False):
+    s = ""
+    if isinstance(ty, idl.KeyedUnion):
+        if parent is None:
+            raise Exception("KeyedUnion type must have a parent")
+        if subinit:
+            s += "switch (%s) {\n" % (parent + ty.keyvar.name)
+            for f in ty.fields:
+                (nparent,fexpr) = ty.member(v, f, parent is None)
+                s += "case %s:\n" % f.enumname
+                s += _libxl_C_type_init(f.type, fexpr, "    ", nparent)
+                s += "    break;\n"
+            s += "}\n"
+        else:
+            if ty.keyvar.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.init_val)
+            elif ty.keyvar.type.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.type.init_val)
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.init_fn is None):
+        for f in [f for f in ty.fields if not f.const]:
+            (nparent,fexpr) = ty.member(v, f, parent is None)
+            if f.init_val is not None:
+                s += "%s = %s;\n" % (fexpr, f.init_val)
+            else:
+                s += _libxl_C_type_init(f.type, fexpr, "", nparent)
+    else:
+        if ty.init_val is not None:
+            s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), ty.init_val)
+        elif ty.init_fn is not None:
+            s += "%s(%s);\n" % (ty.init_fn, ty.pass_arg(v, parent is None))
+
+    if s != "":
+        s = indent + s
+    return s.replace("\n", "\n%s" % indent).rstrip(indent)
+
+def libxl_C_type_init(ty):
+    s = ""
+    s += "void %s(%s)\n" % (ty.init_fn, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))
+    s += "{\n"
+    s += "    memset(p, '\\0', sizeof(*p));\n"
+    s += _libxl_C_type_init(ty, "p")
+    s += "}\n"
+    s += "\n"
+    return s
+
+def libxl_C_type_member_init(ty, field):
+    if not isinstance(field.type, idl.KeyedUnion):
+        raise Exception("Only KeyedUnion is supported for member init")
+
+    ku = field.type
+    
+    s = ""
+    s += "void %s(%s, %s)\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                ty.make_arg("p", passby=idl.PASS_BY_REFERENCE),
+                                ku.keyvar.type.make_arg(ku.keyvar.name))
+    s += "{\n"
+    
+    if ku.keyvar.init_val:
+        init_val = ku.keyvar.init_val
+    elif ku.keyvar.type.init_val:
+        init_val = ku.keyvar.type.init_val
+    else:
+        init_val = None
+        
+    if init_val is not None:
+        (nparent,fexpr) = ty.member(ty.pass_arg("p"), ku.keyvar, isref=True)
+        s += "    assert(%s == %s);\n" % (fexpr, init_val)
+        s += "    %s = %s;\n" % (fexpr, ku.keyvar.name)
+    (nparent,fexpr) = ty.member(ty.pass_arg("p"), field, isref=True)
+    s += _libxl_C_type_init(ku, fexpr, parent=nparent, subinit=True)
+    s += "}\n"
+    s += "\n"
+    return s
+
 def libxl_C_type_gen_json(ty, v, indent = "    ", parent = None):
     s = ""
     if parent is None:
@@ -199,6 +281,15 @@ if __name__ == '__main__':
         f.write(libxl_C_type_define(ty) + ";\n")
         if ty.dispose_fn is not None:
             f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
+        if ty.init_fn is not None:
+            f.write("void %s(%s);\n" % (ty.init_fn, ty.make_arg("p")))
+            for field in libxl_init_members(ty):
+                if not isinstance(field.type, idl.KeyedUnion):
+                    raise Exception("Only KeyedUnion is supported for member init")
+                ku = field.type
+                f.write("void %s(%s, %s);\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                               ty.make_arg("p"),
+                                               ku.keyvar.type.make_arg(ku.keyvar.name)))
         if ty.json_fn is not None:
             f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
         if isinstance(ty, idl.Enumeration):
@@ -227,7 +318,7 @@ if __name__ == '__main__':
 
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
-    for ty in [ty for ty in types+builtins if ty.json_fn is not None]:
+    for ty in [ty for ty in types if ty.json_fn is not None]:
         f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
@@ -264,6 +355,11 @@ if __name__ == '__main__':
         f.write("    memset(p, LIBXL_DTOR_POISON, sizeof(*p));\n")
         f.write("}\n")
         f.write("\n")
+        
+    for ty in [t for t in types if t.init_fn is not None and t.autogenerate_init_fn]:
+        f.write(libxl_C_type_init(ty))
+        for field in libxl_init_members(ty):
+            f.write(libxl_C_type_member_init(ty, field))
 
     for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("const char *%s_to_string(%s e)\n" % (ty.typename, ty.typename))
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/idl.py
--- a/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.py	Mon Feb 13 16:27:34 2012 +0000
@@ -51,6 +51,10 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
+        self.init_fn = kwargs.setdefault('init_fn', None)
+        self.init_val = kwargs.setdefault('init_val', None)
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', False)
+
         if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
@@ -144,12 +148,20 @@ class Field(object):
         self.name = name
         self.const = kwargs.setdefault('const', False)
         self.enumname = kwargs.setdefault('enumname', None)
+        self.init_val = kwargs.setdefault('init_val', None)
 
 class Aggregate(Type):
     """A type containing a collection of other types"""
     def __init__(self, kind, typename, fields, **kwargs):
         Type.__init__(self, typename, **kwargs)
 
+        if self.typename is not None and self.dir in [DIR_IN, DIR_BOTH]:
+            self.init_fn = kwargs.setdefault('init_fn', self.typename + "_init")
+        else:
+            self.init_fn = kwargs.setdefault('init_fn', None)
+
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', True)
+
         self.kind = kind
 
         self.fields = []
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/idl.txt	Mon Feb 13 16:27:34 2012 +0000
@@ -44,6 +44,22 @@ Type.autogenerate_dispose_fn: (default: 
  Indicates if the above named Type.dispose_fn should be
  autogenerated.
 
+Type.init_val: (default: None)
+
+ C expression for the value to initialise instances of this type to.
+
+ If present takes precendence over init_fn (see below).
+
+Type.init_fn: (default: typename + "_init" if dir in [IN, BOTH] and
+                        type != None)
+
+ The name of the C function which will initialist Type.
+
+Type.autogenerate_init_fn: (default: True if dir in [IN, BOTH])
+
+ Indicates if the above named Type.init_fn should be
+ autogenerated.
+
 Type.json_fn: (default: typename + "_gen_json" or None if type == None)
 
  The name of the C function which will generate a YAJL data structure
@@ -105,10 +121,13 @@ idl.Aggregate
 
  Each field has the following properties:
 
-  Field.type    The type of the member (a idl.Type).
-  Field.name    The name of the member (can be None for anonymous
-                fields).
-  Field.const   Boolean, true if the member is const.
+  Field.type     The type of the member (a idl.Type).
+  Field.name     The name of the member (can be None for anonymous
+                 fields).
+  Field.const    Boolean, true if the member is const.
+  Field.init_val The initialisation value for this field. Takes
+                 precendence over both Field.type.init_val and
+                 Field.type.init_fn.
 
 idl.Struct
 
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 16:27:34 2012 +0000
@@ -1226,11 +1226,6 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-void libxl_device_disk_init(libxl_device_disk *disk)
-{
-    memset(disk, 0x00, sizeof(libxl_device_disk));
-}
-
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
     int rc;
@@ -1717,10 +1712,6 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-void libxl_device_nic_init(libxl_device_nic *nic)
-{
-    memset(nic, '\0', sizeof(*nic));
-}
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
 {
@@ -2141,10 +2132,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vkb_init(libxl_device_vkb *vkb)
-{
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
-}
 
 int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
 {
@@ -2253,10 +2240,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vfb_init(libxl_device_vfb *vfb)
-{
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-}
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Feb 13 16:27:34 2012 +0000
@@ -388,10 +388,6 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -527,7 +523,6 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
  */
 
 /* Disks */
-void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
@@ -553,7 +548,6 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
@@ -565,7 +559,6 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -573,7 +566,6 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
@@ -581,7 +573,6 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:34 2012 +0000
@@ -50,11 +50,6 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
-{
-    memset(c_info, '\0', sizeof(*c_info));
-}
-
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -69,35 +64,6 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
-{
-    memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = -1;
-
-    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
-
-}
-
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type)
-{
-    assert(b_info->type == -1);
-    b_info->type = type;
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
-        break;
-    default:
-        abort();
-    }
-}
-
 int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info)
 {
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_json.h	Mon Feb 13 16:27:34 2012 +0000
@@ -22,6 +22,20 @@
 #  include <yajl/yajl_version.h>
 #endif
 
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
+yajl_gen_status libxl_domid_gen_json(yajl_gen hand, libxl_domid *p);
+yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
+yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
+yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                                 libxl_cpuid_policy_list *p);
+yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
+yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
+                                              libxl_key_value_list *p);
+yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand,
+                                              libxl_file_reference *p);
+yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
+
 #include <_libxl_types_json.h>
 
 /* YAJL version check */
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Feb 13 16:27:34 2012 +0000
@@ -765,11 +765,6 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
-void libxl_device_pci_init(libxl_device_pci *pci)
-{
-    memset(pci, '\0', sizeof(*pci));
-}
-
 int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
 {
     return 0;
diff -r ba485f9fce31 -r 50c87c40031c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
@@ -100,7 +100,7 @@ libxl_timer_mode = Enumeration("timer_mo
     (1, "no_delay_for_missed_ticks"),
     (2, "no_missed_ticks_pending"),
     (3, "one_missed_tick_pending"),
-    ])
+    ], init_val = "LIBXL_TIMER_MODE_DEFAULT")
 
 #
 # Complex libxl types
@@ -157,19 +157,19 @@ libxl_dominfo = Struct("dominfo",[
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
     ("cpupool",     uint32),
-    ], dispose_fn=None)
+    ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
     ("sched_id",    uint32),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vminfo = Struct("vminfo", [
     ("uuid", libxl_uuid),
     ("domid", libxl_domid),
-    ], dispose_fn=None)
+    ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_version_info = Struct("version_info", [
     ("xen_version_major", integer),
@@ -184,7 +184,7 @@ libxl_version_info = Struct("version_inf
     ("virt_start",        uint64),
     ("pagesize",          integer),
     ("commandline",       string),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
@@ -196,7 +196,9 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ])
+    ], dir=DIR_IN)
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
@@ -273,8 +275,8 @@ libxl_domain_build_info = Struct("domain
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", libxl_defbool),
                                       ])),
-                 ])),
-    ],
+                 ], keyvar_init_val = "-1")),
+    ], dir=DIR_IN
 )
 
 libxl_device_vfb = Struct("device_vfb", [
@@ -336,7 +338,7 @@ libxl_diskinfo = Struct("diskinfo", [
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_nicinfo = Struct("nicinfo", [
     ("backend", string),
@@ -348,7 +350,7 @@ libxl_nicinfo = Struct("nicinfo", [
     ("evtch", integer),
     ("rref_tx", integer),
     ("rref_rx", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
     ("vcpuid", uint32),
@@ -358,7 +360,7 @@ libxl_vcpuinfo = Struct("vcpuinfo", [
     ("running", bool),
     ("vcpu_time", uint64), # total vcpu time ran (ns)
     ("cpumap", libxl_cpumap), # current cpu's affinities
-    ])
+    ], dir=DIR_OUT)
 
 libxl_physinfo = Struct("physinfo", [
     ("threads_per_core", uint32),
@@ -383,16 +385,16 @@ libxl_cputopology = Struct("cputopology"
     ("core", uint32),
     ("socket", uint32),
     ("node", uint32),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
-    ], dispose_fn=None)
+    ], dispose_fn=None, init_fn=None)
 
 libxl_sched_credit2 = Struct("sched_credit2", [
     ("weight", integer),
-    ], dispose_fn=None)
+    ], dispose_fn=None, init_fn=None)
 
 libxl_sched_sedf = Struct("sched_sedf", [
     ("period", integer),
@@ -400,7 +402,7 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("latency", integer),
     ("extratime", integer),
     ("weight", integer),
-    ], dispose_fn=None)
+    ], dispose_fn=None, init_fn=None)
 
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9X-0003rE-17; Mon, 13 Feb 2012 16:53:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9O-0003Vh-7a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29372 invoked from network); 13 Feb 2012 16:53:07 -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;
	13 Feb 2012 16:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526887"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:06 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHr025169;	Mon, 13 Feb 2012 08:53:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: d27c92eeeddc5e4c190a88ce282fb0155405a65e
Message-ID: <d27c92eeeddc5e4c190a.1329151983@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 17 of 23] libxl: use defbool for graphics
	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150453 0
# Node ID d27c92eeeddc5e4c190a88ce282fb0155405a65e
# Parent  42c448aa641537798f4b09a6db55f3a5ee4082cd
libxl: use defbool for graphics related options

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 16:27:33 2012 +0000
@@ -2256,22 +2256,23 @@ out:
 void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->vnc.enable = 1;
-    vfb->vnc.passwd = NULL;
-    vfb->vnc.display = 0;
-    vfb->vnc.findunused = 1;
-    vfb->keymap = NULL;
-    vfb->sdl.enable = 0;
-    vfb->sdl.opengl = 0;
-    vfb->sdl.display = NULL;
-    vfb->sdl.xauthority = NULL;
 }
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
-    if (!vfb->vnc.listen) {
-        vfb->vnc.listen = strdup("127.0.0.1");
-        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    libxl_defbool_setdefault(&vfb->vnc.enable, true);
+    if (libxl_defbool_val(vfb->vnc.enable)) {
+        if (!vfb->vnc.listen) {
+            vfb->vnc.listen = strdup("127.0.0.1");
+            if (!vfb->vnc.listen) return ERROR_NOMEM;
+        }
+
+        libxl_defbool_setdefault(&vfb->vnc.findunused, true);
+    }
+
+    libxl_defbool_setdefault(&vfb->sdl.enable, false);
+    if (libxl_defbool_val(vfb->sdl.enable)) {
+        libxl_defbool_setdefault(&vfb->sdl.opengl, false);
     }
 
     return 0;
@@ -2320,17 +2321,17 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
     flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
     flexarray_append_pair(back, "vnc",
-                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+                          libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
     flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
     flexarray_append_pair(back, "vncdisplay",
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
-                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
+                          libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0");
     flexarray_append_pair(back, "sdl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+                          libxl_defbool_val(vfb->sdl.enable) ? "1" : "0");
     flexarray_append_pair(back, "opengl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+                          libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0");
     if (vfb->sdl.xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
@@ -89,10 +89,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
 
-        b_info->u.hvm.stdvga = 0;
-        b_info->u.hvm.vnc.enable = 1;
         b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.usbdevice = NULL;
         break;
@@ -159,13 +156,32 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }
 
-        if (b_info->u.hvm.vnc.enable) {
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
+        if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
             if (!b_info->u.hvm.vnc.listen) {
                 b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
                 if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
             }
         }
 
+        libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.sdl.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.sdl.opengl, false);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.disable_ticketing,
+                                     false);
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.agent_mouse, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.nographic, false);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false);
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:33 2012 +0000
@@ -81,7 +81,7 @@ static const libxl_vnc_info *dm_vnc(cons
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
-    return vnc && vnc->enable ? vnc : NULL;
+    return vnc && libxl_defbool_val(vnc->enable) ? vnc : NULL;
 }
 
 static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
@@ -92,7 +92,7 @@ static const libxl_sdl_info *dm_sdl(cons
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
-    return sdl && sdl->enable ? sdl : NULL;
+    return sdl && libxl_defbool_val(sdl->enable) ? sdl : NULL;
 }
 
 static const char *dm_keymap(const libxl_domain_config *guest_config)
@@ -154,13 +154,13 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!sdl->opengl) {
+        if (!libxl_defbool_val(sdl->opengl)) {
             flexarray_append(dm_args, "-disable-opengl");
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
@@ -175,7 +175,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
@@ -185,7 +185,7 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -238,7 +238,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -291,7 +291,7 @@ static char *dm_spice_options(libxl__gc 
         return NULL;
     }
 
-    if (!spice->disable_ticketing) {
+    if (!libxl_defbool_val(spice->disable_ticketing)) {
         if (!spice->passwd) {
             LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                        "spice ticketing is enabled but missing password");
@@ -307,12 +307,12 @@ static char *dm_spice_options(libxl__gc 
                          spice->port, spice->tls_port);
     if (spice->host)
         opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
-    if (spice->disable_ticketing)
+    if (libxl_defbool_val(spice->disable_ticketing))
         opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
     else
         opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
     opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
-                         spice->agent_mouse ? "on" : "off");
+                         libxl_defbool_val(spice->agent_mouse) ? "on" : "off");
     return opt;
 }
 
@@ -379,11 +379,11 @@ static char ** libxl__build_device_model
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -405,11 +405,11 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (b_info->u.hvm.spice.enable) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -419,7 +419,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }
 
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -479,7 +479,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:33 2012 +0000
@@ -106,31 +106,31 @@ libxl_timer_mode = Enumeration("timer_mo
 # Complex libxl types
 #
 libxl_vnc_info = Struct("vnc_info", [
-    ("enable",        bool),
+    ("enable",        libxl_defbool),
     # "address:port" that should be listened on
     ("listen",        string),
     ("passwd",        string),
     ("display",       integer),
     # If set then try to find an unused port
-    ("findunused",    bool),
+    ("findunused",    libxl_defbool),
     ])
 
 libxl_spice_info = Struct("spice_info", [
-    ("enable",            bool),
+    ("enable",      libxl_defbool),
     # At least one of spice port or spicetls_post must be given
     ("port",        integer),
     ("tls_port",    integer),
     # Interface to bind to
     ("host",        string),
     # enable client connection with no password
-    ("disable_ticketing", bool),
+    ("disable_ticketing", libxl_defbool),
     ("passwd",      string),
-    ("agent_mouse", bool),
+    ("agent_mouse", libxl_defbool),
     ])
 
 libxl_sdl_info = Struct("sdl_info", [
-    ("enable",        bool),
-    ("opengl",        bool),
+    ("enable",        libxl_defbool),
+    ("opengl",        libxl_defbool),
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -244,15 +244,15 @@ libxl_domain_build_info = Struct("domain
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
                                        ("incr_generationid",libxl_defbool),
-                                       ("nographic",        bool),
-                                       ("stdvga",           bool),
+                                       ("nographic",        libxl_defbool),
+                                       ("stdvga",           libxl_defbool),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is en-us keyboard
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
-                                       ("gfx_passthru",     bool),
+                                       ("gfx_passthru",     libxl_defbool),
                                        
                                        ("serial",           string),
                                        ("boot",             string),
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:33 2012 +0000
@@ -939,7 +939,7 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "vnclisten")) {
                     free(vfb->vnc.listen);
                     vfb->vnc.listen = strdup(p2 + 1);
@@ -949,14 +949,14 @@ skip:
                 } else if (!strcmp(p, "vncdisplay")) {
                     vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vnc.findunused = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.findunused, atoi(p2 + 1));
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->sdl.opengl = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.opengl, atoi(p2 + 1));
                 } else if (!strcmp(p, "display")) {
                     free(vfb->sdl.display);
                     vfb->sdl.display = strdup(p2 + 1);
@@ -1156,41 +1156,35 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            b_info->u.hvm.stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            b_info->u.hvm.vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
+        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
+        xlu_cfg_replace_string (config, "vnclisten",
+                                &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd",
+                                &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             b_info->u.hvm.vnc.display = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_get_defbool(config, "vncunused",
+                            &b_info->u.hvm.vnc.findunused, 0);
         xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
-        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            b_info->u.hvm.sdl.enable = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            b_info->u.hvm.sdl.opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            b_info->u.hvm.spice.enable = l;
+        xlu_cfg_get_defbool(config, "sdl", &b_info->u.hvm.sdl.enable, 0);
+        xlu_cfg_get_defbool(config, "opengl", &b_info->u.hvm.sdl.opengl, 0);
+        xlu_cfg_get_defbool (config, "spice", &b_info->u.hvm.spice.enable, 0);
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             b_info->u.hvm.spice.tls_port = l;
         xlu_cfg_replace_string (config, "spicehost",
                                 &b_info->u.hvm.spice.host, 0);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            b_info->u.hvm.spice.disable_ticketing = l;
+        xlu_cfg_get_defbool(config, "spicedisable_ticketing",
+                            &b_info->u.hvm.spice.disable_ticketing, 0);
         xlu_cfg_replace_string (config, "spicepasswd",
                                 &b_info->u.hvm.spice.passwd, 0);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            b_info->u.hvm.spice.agent_mouse = l;
-        else
-            b_info->u.hvm.spice.agent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            b_info->u.hvm.nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            b_info->u.hvm.gfx_passthru = l;
+        xlu_cfg_get_defbool(config, "spiceagent_mouse",
+                            &b_info->u.hvm.spice.agent_mouse, 0);
+        xlu_cfg_get_defbool(config, "nographic", &b_info->u.hvm.nographic, 0);
+        xlu_cfg_get_defbool(config, "gfx_passthru", 
+                            &b_info->u.hvm.gfx_passthru, 0);
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:33 2012 +0000
@@ -110,26 +110,34 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(stdvga %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.findunused));
         printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
+        printf("\t\t\t(nographic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nographic));
+        printf("\t\t\t(spice %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.enable));
         printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
         printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
         printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+        printf("\t\t\t(spicedisable_ticketing %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.disable_ticketing));
+        printf("\t\t\t(spiceagent_mouse %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.agent_mouse));
 
         printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(gfx_passthru %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.gfx_passthru));
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
@@ -204,13 +212,17 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.findunused));
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.opengl));
         printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
         printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9X-0003rE-17; Mon, 13 Feb 2012 16:53:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9O-0003Vh-7a
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329151975!13187236!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29372 invoked from network); 13 Feb 2012 16:53:07 -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;
	13 Feb 2012 16:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181526887"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 11:53:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 11:53:06 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DGqmHr025169;	Mon, 13 Feb 2012 08:53:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: d27c92eeeddc5e4c190a88ce282fb0155405a65e
Message-ID: <d27c92eeeddc5e4c190a.1329151983@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1329151966@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 16:53:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 17 of 23] libxl: use defbool for graphics
	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329150453 0
# Node ID d27c92eeeddc5e4c190a88ce282fb0155405a65e
# Parent  42c448aa641537798f4b09a6db55f3a5ee4082cd
libxl: use defbool for graphics related options

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Feb 13 16:27:33 2012 +0000
@@ -2256,22 +2256,23 @@ out:
 void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->vnc.enable = 1;
-    vfb->vnc.passwd = NULL;
-    vfb->vnc.display = 0;
-    vfb->vnc.findunused = 1;
-    vfb->keymap = NULL;
-    vfb->sdl.enable = 0;
-    vfb->sdl.opengl = 0;
-    vfb->sdl.display = NULL;
-    vfb->sdl.xauthority = NULL;
 }
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
-    if (!vfb->vnc.listen) {
-        vfb->vnc.listen = strdup("127.0.0.1");
-        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    libxl_defbool_setdefault(&vfb->vnc.enable, true);
+    if (libxl_defbool_val(vfb->vnc.enable)) {
+        if (!vfb->vnc.listen) {
+            vfb->vnc.listen = strdup("127.0.0.1");
+            if (!vfb->vnc.listen) return ERROR_NOMEM;
+        }
+
+        libxl_defbool_setdefault(&vfb->vnc.findunused, true);
+    }
+
+    libxl_defbool_setdefault(&vfb->sdl.enable, false);
+    if (libxl_defbool_val(vfb->sdl.enable)) {
+        libxl_defbool_setdefault(&vfb->sdl.opengl, false);
     }
 
     return 0;
@@ -2320,17 +2321,17 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
     flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
     flexarray_append_pair(back, "vnc",
-                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+                          libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
     flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
     flexarray_append_pair(back, "vncdisplay",
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
-                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
+                          libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0");
     flexarray_append_pair(back, "sdl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+                          libxl_defbool_val(vfb->sdl.enable) ? "1" : "0");
     flexarray_append_pair(back, "opengl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+                          libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0");
     if (vfb->sdl.xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:33 2012 +0000
@@ -89,10 +89,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
 
-        b_info->u.hvm.stdvga = 0;
-        b_info->u.hvm.vnc.enable = 1;
         b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.usbdevice = NULL;
         break;
@@ -159,13 +156,32 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }
 
-        if (b_info->u.hvm.vnc.enable) {
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
+        if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
             if (!b_info->u.hvm.vnc.listen) {
                 b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
                 if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
             }
         }
 
+        libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.sdl.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.sdl.opengl, false);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.disable_ticketing,
+                                     false);
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.agent_mouse, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.nographic, false);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false);
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Feb 13 16:27:33 2012 +0000
@@ -81,7 +81,7 @@ static const libxl_vnc_info *dm_vnc(cons
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
-    return vnc && vnc->enable ? vnc : NULL;
+    return vnc && libxl_defbool_val(vnc->enable) ? vnc : NULL;
 }
 
 static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
@@ -92,7 +92,7 @@ static const libxl_sdl_info *dm_sdl(cons
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
-    return sdl && sdl->enable ? sdl : NULL;
+    return sdl && libxl_defbool_val(sdl->enable) ? sdl : NULL;
 }
 
 static const char *dm_keymap(const libxl_domain_config *guest_config)
@@ -154,13 +154,13 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!sdl->opengl) {
+        if (!libxl_defbool_val(sdl->opengl)) {
             flexarray_append(dm_args, "-disable-opengl");
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
@@ -175,7 +175,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
@@ -185,7 +185,7 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -238,7 +238,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -291,7 +291,7 @@ static char *dm_spice_options(libxl__gc 
         return NULL;
     }
 
-    if (!spice->disable_ticketing) {
+    if (!libxl_defbool_val(spice->disable_ticketing)) {
         if (!spice->passwd) {
             LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                        "spice ticketing is enabled but missing password");
@@ -307,12 +307,12 @@ static char *dm_spice_options(libxl__gc 
                          spice->port, spice->tls_port);
     if (spice->host)
         opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
-    if (spice->disable_ticketing)
+    if (libxl_defbool_val(spice->disable_ticketing))
         opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
     else
         opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
     opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
-                         spice->agent_mouse ? "on" : "off");
+                         libxl_defbool_val(spice->agent_mouse) ? "on" : "off");
     return opt;
 }
 
@@ -379,11 +379,11 @@ static char ** libxl__build_device_model
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -405,11 +405,11 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (b_info->u.hvm.spice.enable) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -419,7 +419,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }
 
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -479,7 +479,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:33 2012 +0000
@@ -106,31 +106,31 @@ libxl_timer_mode = Enumeration("timer_mo
 # Complex libxl types
 #
 libxl_vnc_info = Struct("vnc_info", [
-    ("enable",        bool),
+    ("enable",        libxl_defbool),
     # "address:port" that should be listened on
     ("listen",        string),
     ("passwd",        string),
     ("display",       integer),
     # If set then try to find an unused port
-    ("findunused",    bool),
+    ("findunused",    libxl_defbool),
     ])
 
 libxl_spice_info = Struct("spice_info", [
-    ("enable",            bool),
+    ("enable",      libxl_defbool),
     # At least one of spice port or spicetls_post must be given
     ("port",        integer),
     ("tls_port",    integer),
     # Interface to bind to
     ("host",        string),
     # enable client connection with no password
-    ("disable_ticketing", bool),
+    ("disable_ticketing", libxl_defbool),
     ("passwd",      string),
-    ("agent_mouse", bool),
+    ("agent_mouse", libxl_defbool),
     ])
 
 libxl_sdl_info = Struct("sdl_info", [
-    ("enable",        bool),
-    ("opengl",        bool),
+    ("enable",        libxl_defbool),
+    ("opengl",        libxl_defbool),
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -244,15 +244,15 @@ libxl_domain_build_info = Struct("domain
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
                                        ("incr_generationid",libxl_defbool),
-                                       ("nographic",        bool),
-                                       ("stdvga",           bool),
+                                       ("nographic",        libxl_defbool),
+                                       ("stdvga",           libxl_defbool),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is en-us keyboard
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
-                                       ("gfx_passthru",     bool),
+                                       ("gfx_passthru",     libxl_defbool),
                                        
                                        ("serial",           string),
                                        ("boot",             string),
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:33 2012 +0000
@@ -939,7 +939,7 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "vnclisten")) {
                     free(vfb->vnc.listen);
                     vfb->vnc.listen = strdup(p2 + 1);
@@ -949,14 +949,14 @@ skip:
                 } else if (!strcmp(p, "vncdisplay")) {
                     vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vnc.findunused = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.findunused, atoi(p2 + 1));
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->sdl.opengl = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.opengl, atoi(p2 + 1));
                 } else if (!strcmp(p, "display")) {
                     free(vfb->sdl.display);
                     vfb->sdl.display = strdup(p2 + 1);
@@ -1156,41 +1156,35 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            b_info->u.hvm.stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            b_info->u.hvm.vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
+        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
+        xlu_cfg_replace_string (config, "vnclisten",
+                                &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd",
+                                &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             b_info->u.hvm.vnc.display = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_get_defbool(config, "vncunused",
+                            &b_info->u.hvm.vnc.findunused, 0);
         xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
-        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            b_info->u.hvm.sdl.enable = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            b_info->u.hvm.sdl.opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            b_info->u.hvm.spice.enable = l;
+        xlu_cfg_get_defbool(config, "sdl", &b_info->u.hvm.sdl.enable, 0);
+        xlu_cfg_get_defbool(config, "opengl", &b_info->u.hvm.sdl.opengl, 0);
+        xlu_cfg_get_defbool (config, "spice", &b_info->u.hvm.spice.enable, 0);
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             b_info->u.hvm.spice.tls_port = l;
         xlu_cfg_replace_string (config, "spicehost",
                                 &b_info->u.hvm.spice.host, 0);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            b_info->u.hvm.spice.disable_ticketing = l;
+        xlu_cfg_get_defbool(config, "spicedisable_ticketing",
+                            &b_info->u.hvm.spice.disable_ticketing, 0);
         xlu_cfg_replace_string (config, "spicepasswd",
                                 &b_info->u.hvm.spice.passwd, 0);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            b_info->u.hvm.spice.agent_mouse = l;
-        else
-            b_info->u.hvm.spice.agent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            b_info->u.hvm.nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            b_info->u.hvm.gfx_passthru = l;
+        xlu_cfg_get_defbool(config, "spiceagent_mouse",
+                            &b_info->u.hvm.spice.agent_mouse, 0);
+        xlu_cfg_get_defbool(config, "nographic", &b_info->u.hvm.nographic, 0);
+        xlu_cfg_get_defbool(config, "gfx_passthru", 
+                            &b_info->u.hvm.gfx_passthru, 0);
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
diff -r 42c448aa6415 -r d27c92eeeddc tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:27 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:33 2012 +0000
@@ -110,26 +110,34 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(stdvga %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.findunused));
         printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
+        printf("\t\t\t(nographic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nographic));
+        printf("\t\t\t(spice %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.enable));
         printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
         printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
         printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+        printf("\t\t\t(spicedisable_ticketing %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.disable_ticketing));
+        printf("\t\t\t(spiceagent_mouse %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.agent_mouse));
 
         printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(gfx_passthru %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.gfx_passthru));
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
@@ -204,13 +212,17 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.findunused));
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.opengl));
         printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
         printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9s-0004Ny-Ly; Mon, 13 Feb 2012 16:53:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9q-0004D3-Ez
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329152015!11709841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19275 invoked from network); 13 Feb 2012 16:53:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:53:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:53:28 +0000
Message-ID: <1329152007.31256.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 16:53:27 +0000
In-Reply-To: <4F393053.80903@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
	<1329144704.31256.114.camel@zakaz.uk.xensource.com>
	<4F393053.80903@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 15:46 +0000, David Vrabel wrote:
> On 13/02/12 14:51, Ian Campbell wrote:
> > On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> Prior to setting up the page tables, parse the DTB for the location
> >> and size of RAM.
> >>
> >> Use this information to get the physical address to relocate Xen to in
> >> setup_pagetables().
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> Acked-by: Tim Deegan <tim@xen.org>
> >> ---
> > [...]
> >>  xen/common/Makefile           |    3 +
> >>  xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
> > [...]
> >>  xen/include/xen/device_tree.h |   36 ++++++++
> > 
> > I'd have preferred these non-ARM bits in a separate patch if possible.
> > I'm going to commit them anyway though on the basis that they are in
> > reality ARM specific unless Keir (or someone else) objects quite soon.
> 
> Dividing maintainer-ship by directory seems a little coarse grained.  It
> may be more practical for you (Ian) to be the maintainer/committer for
> the device tree related stuff even though they live under xen/common/.

I'd be happy to do that if there is agreement among the other
maintainers.

Of course as soon as some joker ports x86 to use DT we are back where we
started ;-)

> Or, if you prefer, I can make sure to split the patches in common and
> arch bits.
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:53:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwz9s-0004Ny-Ly; Mon, 13 Feb 2012 16:53:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rwz9q-0004D3-Ez
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329152015!11709841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19275 invoked from network); 13 Feb 2012 16:53:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:53:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 16:53:28 +0000
Message-ID: <1329152007.31256.155.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 16:53:27 +0000
In-Reply-To: <4F393053.80903@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
	<1329144704.31256.114.camel@zakaz.uk.xensource.com>
	<4F393053.80903@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 15:46 +0000, David Vrabel wrote:
> On 13/02/12 14:51, Ian Campbell wrote:
> > On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> Prior to setting up the page tables, parse the DTB for the location
> >> and size of RAM.
> >>
> >> Use this information to get the physical address to relocate Xen to in
> >> setup_pagetables().
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >> Acked-by: Tim Deegan <tim@xen.org>
> >> ---
> > [...]
> >>  xen/common/Makefile           |    3 +
> >>  xen/common/device_tree.c      |  179 +++++++++++++++++++++++++++++++++++++++++
> > [...]
> >>  xen/include/xen/device_tree.h |   36 ++++++++
> > 
> > I'd have preferred these non-ARM bits in a separate patch if possible.
> > I'm going to commit them anyway though on the basis that they are in
> > reality ARM specific unless Keir (or someone else) objects quite soon.
> 
> Dividing maintainer-ship by directory seems a little coarse grained.  It
> may be more practical for you (Ian) to be the maintainer/committer for
> the device tree related stuff even though they live under xen/common/.

I'd be happy to do that if there is agreement among the other
maintainers.

Of course as soon as some joker ports x86 to use DT we are back where we
started ;-)

> Or, if you prefer, I can make sure to split the patches in common and
> arch bits.
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:54:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzA8-0004hi-EP; Mon, 13 Feb 2012 16:54:00 +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 1RwzA6-0004fR-IE
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329151998!52236118!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32308 invoked from network); 13 Feb 2012 16:53:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:18 -0000
Received: by wgbdr13 with SMTP id dr13so4524998wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 08:53:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=FHBO3SVETVgS0/cqQSgh8M7n1H28T2ES+cADAh9bEjw=;
	b=Wt/YT/MTaQCEMIgqPy+COBawH3KAUpPEJlUadqJJyoycqUTl6ryv2l5SExbYycoz8G
	a70iELVa4UDlyNkN+TzDqNikbWD1rvnxra80W3hhrvLZd+ElDYCJyMqt8gggvPpYV+q5
	XNqPNqH7EriqZzP+eEiO8TjMIU5u9fluuWhm4=
Received: by 10.180.92.227 with SMTP id cp3mr25540556wib.13.1329152037276;
	Mon, 13 Feb 2012 08:53:57 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id s2sm48338488wix.3.2012.02.13.08.53.50
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 08:53:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 16:53:48 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB5EF09C.396C6%keir@xen.org>
Thread-Topic: IRQ: issues with directed EOI and IO-APIC ack methods
Thread-Index: AczqcA4OYI/NfE1aokeUD8HZV5Mfig==
In-Reply-To: <4F39344B.5070504@citrix.com>
Mime-version: 1.0
Cc: edwin.zhai@intel.com
Subject: Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack
	methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> XenServer6.0 (Xen 4.1.1) has had a support escalation against it for
> Cisco C210 M2 servers.  I do not have access to any of these servers, so
> cant debug the issue myself.
> 
> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
> directed EOI support must use the old IO-APIC ack method.

Well, it's not surprising that some systems won't like this method. Firstly,
calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
operation.

Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
-- if the IO-APIC does not have an EOI register, then an EOI is forced in a
slightly gross way. I wonder how reliable that is across a broad range of
chipsets; reliable enough to rely on it for *every* interrupt? ;-)

Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
personally quite happy to see the original patch reverted.

 -- Keir

> A hypervisor with this check disabled (i.e. never checking for, or
> enabling directed EOI) seems to make the system stable again (5 days
> stable now, as opposed to a hang due to lost interrupts once every few
> hours before).
> 
> First of all, I have discovered that forcing "ioapic_ack=new" does not
> have the indented effect, because verify_local_APIC trashes it, even if
> the user has specified the ack method.  I intend to send a patch to fix
> this in due course.
> 
> However, as for the main issue, I cant work out any logical reason why
> directed EOI would not work with the new ack mode.  I am still trying to
> work out the differences in the code path incase I have missed something
> subtle, but I wondered if anyone on the list has more knowledge of these
> intricacies than me?  Either way, it appears that there is a bug on the
> codepath with directed EOI and old ack method.
> 
> Thanks in advance,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:54:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzA8-0004hi-EP; Mon, 13 Feb 2012 16:54:00 +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 1RwzA6-0004fR-IE
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:53:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329151998!52236118!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32308 invoked from network); 13 Feb 2012 16:53:18 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:53:18 -0000
Received: by wgbdr13 with SMTP id dr13so4524998wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 08:53:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=FHBO3SVETVgS0/cqQSgh8M7n1H28T2ES+cADAh9bEjw=;
	b=Wt/YT/MTaQCEMIgqPy+COBawH3KAUpPEJlUadqJJyoycqUTl6ryv2l5SExbYycoz8G
	a70iELVa4UDlyNkN+TzDqNikbWD1rvnxra80W3hhrvLZd+ElDYCJyMqt8gggvPpYV+q5
	XNqPNqH7EriqZzP+eEiO8TjMIU5u9fluuWhm4=
Received: by 10.180.92.227 with SMTP id cp3mr25540556wib.13.1329152037276;
	Mon, 13 Feb 2012 08:53:57 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id s2sm48338488wix.3.2012.02.13.08.53.50
	(version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 08:53:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 13 Feb 2012 16:53:48 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB5EF09C.396C6%keir@xen.org>
Thread-Topic: IRQ: issues with directed EOI and IO-APIC ack methods
Thread-Index: AczqcA4OYI/NfE1aokeUD8HZV5Mfig==
In-Reply-To: <4F39344B.5070504@citrix.com>
Mime-version: 1.0
Cc: edwin.zhai@intel.com
Subject: Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack
	methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> XenServer6.0 (Xen 4.1.1) has had a support escalation against it for
> Cisco C210 M2 servers.  I do not have access to any of these servers, so
> cant debug the issue myself.
> 
> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
> directed EOI support must use the old IO-APIC ack method.

Well, it's not surprising that some systems won't like this method. Firstly,
calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
operation.

Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
-- if the IO-APIC does not have an EOI register, then an EOI is forced in a
slightly gross way. I wonder how reliable that is across a broad range of
chipsets; reliable enough to rely on it for *every* interrupt? ;-)

Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
personally quite happy to see the original patch reverted.

 -- Keir

> A hypervisor with this check disabled (i.e. never checking for, or
> enabling directed EOI) seems to make the system stable again (5 days
> stable now, as opposed to a hang due to lost interrupts once every few
> hours before).
> 
> First of all, I have discovered that forcing "ioapic_ack=new" does not
> have the indented effect, because verify_local_APIC trashes it, even if
> the user has specified the ack method.  I intend to send a patch to fix
> this in due course.
> 
> However, as for the main issue, I cant work out any logical reason why
> directed EOI would not work with the new ack mode.  I am still trying to
> work out the differences in the code path incase I have missed something
> subtle, but I wondered if anyone on the list has more knowledge of these
> intricacies than me?  Either way, it appears that there is a bug on the
> codepath with directed EOI and old ack method.
> 
> Thanks in advance,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:54:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwzAe-0005L4-TE; Mon, 13 Feb 2012 16:54: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 1RwzAc-0005IM-Sr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:54:31 +0000
Received: from [85.158.139.83:18642] by server-1.bemta-5.messagelabs.com id
	34/85-04285-640493F4; Mon, 13 Feb 2012 16:54:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329152069!14877562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9202 invoked from network); 13 Feb 2012 16:54:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:54:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:54:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 16:54:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzAY-0001GX-65; Mon, 13 Feb 2012 16:54:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzAY-0001BV-05;
	Mon, 13 Feb 2012 16:54:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16449.975551.528254@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 16:54:25 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 0 of 6 V5] amd iommu: support ats/gpgpu
 passthru on iommuv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Wang writes ("[PATCH 0 of 6 V5] amd iommu: support ats/gpgpu passthru on iommuv2 systems"):
> This is patch set v5. It includes all pending patches that are needed to enable gpgpu passthrough and heterogeneous computing in guest OSes. Basically, this patch set gives guest VM the same capability of running openCL applications on amd platforms as native OSes. Upstream Linux 3.3 rc2 with amd iommuv2 kernel driver has been tested well as guest OS, and since last submission, lots of regression tests have been done to make sure this does not break non-iommuv2 systems. Please review it, feedbacks are appreciated.

Thanks.  I'm not qualified to review the hypervisor parts, but the
explanation seems to make sense and the tools parts look OK.

So as for these three:

 [PATCH 4 of 6 V5] libxc: add wrappers for new hypercalls
 [PATCH 5 of 6 V5] libxl: bind virtual bdf to physical bdf ...
 [PATCH 6 of 6 V5] libxl: Introduce a new guest config file parameter

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


I do have a couple of minor niggles which you might like to address if
you repost:

> libxl: Introduce a new guest config file parameter
> Use guest_iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0. Regression tests have been done to make sure
> it does not break non-iommuv2 systems.

It's conventional to leave a blank line between the summary line and
the bulk of the description.

> diff -r c39f5736e364 -r 09721a5ff844 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:19 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:20 2012 +0100
> @@ -820,6 +820,10 @@ certainly belong in a more appropriate s
...
> +=item B<guest_iommu=BOOLEAN>
> +
> +Enable virtual iommu device for hvm guest. It should be enabled to passthrough AMD GPGPU.
> +

It would be nice for that line to be wrapped to fit within 75-80
columns.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:54:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwzAe-0005L4-TE; Mon, 13 Feb 2012 16:54: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 1RwzAc-0005IM-Sr
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:54:31 +0000
Received: from [85.158.139.83:18642] by server-1.bemta-5.messagelabs.com id
	34/85-04285-640493F4; Mon, 13 Feb 2012 16:54:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329152069!14877562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9202 invoked from network); 13 Feb 2012 16:54:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:54:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:54:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 16:54:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzAY-0001GX-65; Mon, 13 Feb 2012 16:54:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzAY-0001BV-05;
	Mon, 13 Feb 2012 16:54:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16449.975551.528254@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 16:54:25 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <patchbomb.1328886425@gran.amd.com>
References: <patchbomb.1328886425@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 0 of 6 V5] amd iommu: support ats/gpgpu
 passthru on iommuv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Wei Wang writes ("[PATCH 0 of 6 V5] amd iommu: support ats/gpgpu passthru on iommuv2 systems"):
> This is patch set v5. It includes all pending patches that are needed to enable gpgpu passthrough and heterogeneous computing in guest OSes. Basically, this patch set gives guest VM the same capability of running openCL applications on amd platforms as native OSes. Upstream Linux 3.3 rc2 with amd iommuv2 kernel driver has been tested well as guest OS, and since last submission, lots of regression tests have been done to make sure this does not break non-iommuv2 systems. Please review it, feedbacks are appreciated.

Thanks.  I'm not qualified to review the hypervisor parts, but the
explanation seems to make sense and the tools parts look OK.

So as for these three:

 [PATCH 4 of 6 V5] libxc: add wrappers for new hypercalls
 [PATCH 5 of 6 V5] libxl: bind virtual bdf to physical bdf ...
 [PATCH 6 of 6 V5] libxl: Introduce a new guest config file parameter

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>


I do have a couple of minor niggles which you might like to address if
you repost:

> libxl: Introduce a new guest config file parameter
> Use guest_iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0. Regression tests have been done to make sure
> it does not break non-iommuv2 systems.

It's conventional to leave a blank line between the summary line and
the bulk of the description.

> diff -r c39f5736e364 -r 09721a5ff844 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:19 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:20 2012 +0100
> @@ -820,6 +820,10 @@ certainly belong in a more appropriate s
...
> +=item B<guest_iommu=BOOLEAN>
> +
> +Enable virtual iommu device for hvm guest. It should be enabled to passthrough AMD GPGPU.
> +

It would be nice for that line to be wrapped to fit within 75-80
columns.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwzCY-0006mP-Jj; Mon, 13 Feb 2012 16:56:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzCX-0006iU-CA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:56:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329152182!14379993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8657 invoked from network); 13 Feb 2012 16:56:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:56:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:56:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 16:56:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzCQ-0001J3-5q; Mon, 13 Feb 2012 16:56:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzCQ-0001Di-50;
	Mon, 13 Feb 2012 16:56:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16566.141930.561973@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 16:56:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327336647.24561.160.camel@zakaz.uk.xensource.com>
References: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
	<1327336647.24561.160.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: remove duplicate line
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] xl: remove duplicate line"):
> > xl: remove duplicate line

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwzCY-0006mP-Jj; Mon, 13 Feb 2012 16:56:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzCX-0006iU-CA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:56:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329152182!14379993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8657 invoked from network); 13 Feb 2012 16:56:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 16:56:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:56:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 16:56:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzCQ-0001J3-5q; Mon, 13 Feb 2012 16:56:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzCQ-0001Di-50;
	Mon, 13 Feb 2012 16:56:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16566.141930.561973@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 16:56:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327336647.24561.160.camel@zakaz.uk.xensource.com>
References: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
	<1327336647.24561.160.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: remove duplicate line
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] xl: remove duplicate line"):
> > xl: remove duplicate line

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:58:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwzE7-0007Wz-4b; Mon, 13 Feb 2012 16:58: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 1RwzE6-0007VZ-1M
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:58:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329152218!60897745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14672 invoked from network); 13 Feb 2012 16:56: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;
	13 Feb 2012 16:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:58:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 16:58:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzE1-0001Ns-Oy; Mon, 13 Feb 2012 16:58:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzE1-0001Fz-O9;
	Mon, 13 Feb 2012 16:58:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16665.675298.809442@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 16:58:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <cc609327d4fba381388b.1328879091@cosworth.uk.xensource.com>
References: <cc609327d4fba381388b.1328879091@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Add -F to usage for xl shutdown/reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH] xl: Add -F to usage for xl shutdown/reboot"):
> xl: Add -F to usage for xl shutdown/reboot

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 16:58:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 16: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.xensource.com>)
	id 1RwzE7-0007Wz-4b; Mon, 13 Feb 2012 16:58: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 1RwzE6-0007VZ-1M
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 16:58:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329152218!60897745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14672 invoked from network); 13 Feb 2012 16:56: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;
	13 Feb 2012 16:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 16:58:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 16:58:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzE1-0001Ns-Oy; Mon, 13 Feb 2012 16:58:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzE1-0001Fz-O9;
	Mon, 13 Feb 2012 16:58:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16665.675298.809442@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 16:58:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <cc609327d4fba381388b.1328879091@cosworth.uk.xensource.com>
References: <cc609327d4fba381388b.1328879091@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Add -F to usage for xl shutdown/reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH] xl: Add -F to usage for xl shutdown/reboot"):
> xl: Add -F to usage for xl shutdown/reboot

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:01:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1RwzH3-00081a-OH; Mon, 13 Feb 2012 17:01:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzH2-00081L-GM
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:01:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329152457!11296535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21181 invoked from network); 13 Feb 2012 17:00:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:00:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:00:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:00:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzGr-0001Rm-94; Mon, 13 Feb 2012 17:00:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzGr-000289-8L;
	Mon, 13 Feb 2012 17:00:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16841.112747.928769@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:00:57 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1202101713500.7456@kaball-desktop>
References: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
	<alpine.DEB.2.00.1202101713500.7456@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	"stefano.stabellni@citrix.com" <stefano.stabellni@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled"):
> On Fri, 10 Feb 2012, George Dunlap wrote:
> > qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:01:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1RwzH3-00081a-OH; Mon, 13 Feb 2012 17:01:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzH2-00081L-GM
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:01:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329152457!11296535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21181 invoked from network); 13 Feb 2012 17:00:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:00:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:00:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:00:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzGr-0001Rm-94; Mon, 13 Feb 2012 17:00:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzGr-000289-8L;
	Mon, 13 Feb 2012 17:00:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16841.112747.928769@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:00:57 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1202101713500.7456@kaball-desktop>
References: <e4a4e4f4156dcdffb8e8.1328889378@drall.uk.xensource.com>
	<alpine.DEB.2.00.1202101713500.7456@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	"stefano.stabellni@citrix.com" <stefano.stabellni@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless
 graphics pass-thru is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled"):
> On Fri, 10 Feb 2012, George Dunlap wrote:
> > qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:08:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzO6-0008O3-QE; Mon, 13 Feb 2012 17:08:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzO4-0008Nj-JJ
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:08:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329152898!12684271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6177 invoked from network); 13 Feb 2012 17:08:18 -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;
	13 Feb 2012 17:08:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:08:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:08:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzIN-0001St-PO; Mon, 13 Feb 2012 17:02:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzIN-0002AA-ON;
	Mon, 13 Feb 2012 17:02:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16935.621954.836041@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:02:31 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
	<1329145577.31256.116.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
> and always print the IRQ and MFN used by the xenbus on init.

This looks plausible to me.  Anyone else have any comments ?

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:08:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzO6-0008O3-QE; Mon, 13 Feb 2012 17:08:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzO4-0008Nj-JJ
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:08:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329152898!12684271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6177 invoked from network); 13 Feb 2012 17:08:18 -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;
	13 Feb 2012 17:08:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:08:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:08:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzIN-0001St-PO; Mon, 13 Feb 2012 17:02:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzIN-0002AA-ON;
	Mon, 13 Feb 2012 17:02:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.16935.621954.836041@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:02:31 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
	<1329145577.31256.116.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] Mini-os fbfront.c unused variable complaint"):
> s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
> and always print the IRQ and MFN used by the xenbus on init.

This looks plausible to me.  Anyone else have any comments ?

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:09:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzOe-0008Rk-Uk; Mon, 13 Feb 2012 17:09:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzOd-0008R2-2T
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:08:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329152908!8532075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 13 Feb 2012 17:08:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:08:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:08:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:08:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzO8-0001YV-EO; Mon, 13 Feb 2012 17:08:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzO8-0002Gh-DM;
	Mon, 13 Feb 2012 17:08:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.17292.230677.21066@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:08:28 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion
 key member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion key member as part of the KeyedUnion"):
> libxl: idl: generate KeyedUnion key member as part of the KeyedUnion
> 
> Rather than specifying it twice in the IDL.
...        else:
> diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> @@ -214,7 +214,6 @@ libxl_domain_build_info = Struct("domain
>      ("shadow_memkb",    MemKB),
>      ("disable_migrate", libxl_defbool),
>      ("cpuid",           libxl_cpuid_policy_list),
> -    ("type",            libxl_domain_type),
>      
>      ("device_model_version", libxl_device_model_version),

If I'm not mistaken, an effect of this is to move the type field
around in the C structure - ie, it's not ABI compatible.  This is OK
at this stage, I think, but I just wanted to check that that was what
you meant.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:09:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:09:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzOe-0008Rk-Uk; Mon, 13 Feb 2012 17:09:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzOd-0008R2-2T
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:08:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329152908!8532075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 13 Feb 2012 17:08:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:08:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:08:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:08:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzO8-0001YV-EO; Mon, 13 Feb 2012 17:08:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzO8-0002Gh-DM;
	Mon, 13 Feb 2012 17:08:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.17292.230677.21066@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:08:28 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion
 key member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion key member as part of the KeyedUnion"):
> libxl: idl: generate KeyedUnion key member as part of the KeyedUnion
> 
> Rather than specifying it twice in the IDL.
...        else:
> diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> @@ -214,7 +214,6 @@ libxl_domain_build_info = Struct("domain
>      ("shadow_memkb",    MemKB),
>      ("disable_migrate", libxl_defbool),
>      ("cpuid",           libxl_cpuid_policy_list),
> -    ("type",            libxl_domain_type),
>      
>      ("device_model_version", libxl_device_model_version),

If I'm not mistaken, an effect of this is to move the type field
around in the C structure - ie, it's not ABI compatible.  This is OK
at this stage, I think, but I just wanted to check that that was what
you meant.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:13:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzTB-0000Lk-9k; Mon, 13 Feb 2012 17:13:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwzT8-0000LJ-UD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:13:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329153213!15172515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1364 invoked from network); 13 Feb 2012 17:13:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:13:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:13:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 17:13:32 +0000
Message-ID: <1329153211.31256.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 17:13:31 +0000
In-Reply-To: <20281.17292.230677.21066@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
	<20281.17292.230677.21066@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion
 key member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 17:08 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion key member as part of the KeyedUnion"):
> > libxl: idl: generate KeyedUnion key member as part of the KeyedUnion
> > 
> > Rather than specifying it twice in the IDL.
> ...        else:
> > diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> > +++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> > @@ -214,7 +214,6 @@ libxl_domain_build_info = Struct("domain
> >      ("shadow_memkb",    MemKB),
> >      ("disable_migrate", libxl_defbool),
> >      ("cpuid",           libxl_cpuid_policy_list),
> > -    ("type",            libxl_domain_type),
> >      
> >      ("device_model_version", libxl_device_model_version),
> 
> If I'm not mistaken, an effect of this is to move the type field
> around in the C structure - ie, it's not ABI compatible.  This is OK
> at this stage, I think, but I just wanted to check that that was what
> you meant.

It was.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:13:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzTB-0000Lk-9k; Mon, 13 Feb 2012 17:13:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RwzT8-0000LJ-UD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:13:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329153213!15172515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1364 invoked from network); 13 Feb 2012 17:13:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:13:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10668874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:13:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 17:13:32 +0000
Message-ID: <1329153211.31256.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 17:13:31 +0000
In-Reply-To: <20281.17292.230677.21066@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ba485f9fce317ba31a96.1329151988@cosworth.uk.xensource.com>
	<20281.17292.230677.21066@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion
 key member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 17:08 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 22 of 23] libxl: idl: generate KeyedUnion key member as part of the KeyedUnion"):
> > libxl: idl: generate KeyedUnion key member as part of the KeyedUnion
> > 
> > Rather than specifying it twice in the IDL.
> ...        else:
> > diff -r 0751a69b3ef2 -r ba485f9fce31 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> > +++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:34 2012 +0000
> > @@ -214,7 +214,6 @@ libxl_domain_build_info = Struct("domain
> >      ("shadow_memkb",    MemKB),
> >      ("disable_migrate", libxl_defbool),
> >      ("cpuid",           libxl_cpuid_policy_list),
> > -    ("type",            libxl_domain_type),
> >      
> >      ("device_model_version", libxl_device_model_version),
> 
> If I'm not mistaken, an effect of this is to move the type field
> around in the C structure - ie, it's not ABI compatible.  This is OK
> at this stage, I think, but I just wanted to check that that was what
> you meant.

It was.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:28:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1RwzhW-0000xX-8P; Mon, 13 Feb 2012 17:28:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzhT-0000x4-FA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:28:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329154101!14138078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9087 invoked from network); 13 Feb 2012 17:28: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;
	13 Feb 2012 17:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:28:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:28:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzhM-0001ws-VW; Mon, 13 Feb 2012 17:28:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzhM-0002dl-Uc;
	Mon, 13 Feb 2012 17:28:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18481.118310.621941@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:28:17 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for
	non	x86 guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for non x86 guests."):
...
> -
> +#if defined(__i386__) || defined(__x86_64__)

I would prefer to avoid these kind of platform-specific ifdefs in
libxl if possible.  I think we may need to invent libxl_x86.c or
something.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:28:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1RwzhW-0000xX-8P; Mon, 13 Feb 2012 17:28:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzhT-0000x4-FA
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:28:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329154101!14138078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9087 invoked from network); 13 Feb 2012 17:28: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;
	13 Feb 2012 17:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:28:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:28:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzhM-0001ws-VW; Mon, 13 Feb 2012 17:28:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzhM-0002dl-Uc;
	Mon, 13 Feb 2012 17:28:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18481.118310.621941@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:28:17 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for
	non	x86 guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for non x86 guests."):
...
> -
> +#if defined(__i386__) || defined(__x86_64__)

I would prefer to avoid these kind of platform-specific ifdefs in
libxl if possible.  I think we may need to invent libxl_x86.c or
something.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:30:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzjN-00018v-UI; Mon, 13 Feb 2012 17:30: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 1RwzjM-00018T-7A
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:30:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329154084!52537012!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12927 invoked from network); 13 Feb 2012 17:28: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 Feb 2012 17:28:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:29:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:29:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzix-0001xT-M7; Mon, 13 Feb 2012 17:29:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzix-0002u1-LE;
	Mon, 13 Feb 2012 17:29:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18583.636230.572721@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:29:59 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 04/10] blktap2/libvhd: Build shared
	objects	using -fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 04/10] blktap2/libvhd: Build shared objects using -fPIC."):
> diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:30:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzjN-00018v-UI; Mon, 13 Feb 2012 17:30: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 1RwzjM-00018T-7A
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:30:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329154084!52537012!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12927 invoked from network); 13 Feb 2012 17:28: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 Feb 2012 17:28:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:29:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:29:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzix-0001xT-M7; Mon, 13 Feb 2012 17:29:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzix-0002u1-LE;
	Mon, 13 Feb 2012 17:29:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18583.636230.572721@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:29:59 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 04/10] blktap2/libvhd: Build shared
	objects	using -fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 04/10] blktap2/libvhd: Build shared objects using -fPIC."):
> diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:32:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwzlb-0001OW-Tl; Mon, 13 Feb 2012 17:32:44 +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 1Rwzla-0001Nu-Du
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:32:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329154314!59939130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19122 invoked from network); 13 Feb 2012 17:31: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;
	13 Feb 2012 17:31:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:32:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:32:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzlV-0001yc-Tx; Mon, 13 Feb 2012 17:32:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzlV-0002xE-Sy;
	Mon, 13 Feb 2012 17:32:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18741.881905.765341@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:32:37 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-10-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 10/10] tools: only compile libfsimage/xfs
	on	X86
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 10/10] tools: only compile libfsimage/xfs on X86"):
> xfs is not portable, only compile it on X86

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:32:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwzlb-0001OW-Tl; Mon, 13 Feb 2012 17:32:44 +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 1Rwzla-0001Nu-Du
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:32:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329154314!59939130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19122 invoked from network); 13 Feb 2012 17:31: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;
	13 Feb 2012 17:31:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:32:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:32:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzlV-0001yc-Tx; Mon, 13 Feb 2012 17:32:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzlV-0002xE-Sy;
	Mon, 13 Feb 2012 17:32:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18741.881905.765341@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:32:37 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-10-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 10/10] tools: only compile libfsimage/xfs
	on	X86
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 10/10] tools: only compile libfsimage/xfs on X86"):
> xfs is not portable, only compile it on X86

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:35:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1Rwzob-0001lI-0h; Mon, 13 Feb 2012 17:35:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzoZ-0001ko-3p
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:35:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329154540!14085089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11360 invoked from network); 13 Feb 2012 17:35:41 -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;
	13 Feb 2012 17:35:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:35:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:35:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzoR-00021e-Vf; Mon, 13 Feb 2012 17:35:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzoR-00030p-UX;
	Mon, 13 Feb 2012 17:35:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18923.933271.305391@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:35:39 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 07/10] arm: compile libxl"):
> libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
> functions are only available on x86, so ifdef the new cpuid related
> function in libxl_json.c.
...
> +#if defined(__i386__) || defined(__x86_64__)
>  yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                  libxl_cpuid_policy_list *pcpuid)
>  {
> @@ -199,6 +200,13 @@ empty:
>  out:
>      return s;
>  }
> +#else
> +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> +                                libxl_cpuid_policy_list *pcpuid)
> +{
> +    return 0;
> +}
> +#endif

Again, can't this be moved to libxl_{no,}cpuid.c ?

If we really do have to have #ifdefs (eg, if we have code that needs
to be controlled by several different conditions at once) we should
invent a suitable single #define for each feature, eg LIBXL_HAVE_CPUID
or something rather than spreading "defined(__i386__) || defined(__x86_64__)"
all over the place.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:35:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1Rwzob-0001lI-0h; Mon, 13 Feb 2012 17:35:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzoZ-0001ko-3p
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:35:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329154540!14085089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11360 invoked from network); 13 Feb 2012 17:35:41 -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;
	13 Feb 2012 17:35:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:35:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:35:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RwzoR-00021e-Vf; Mon, 13 Feb 2012 17:35:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RwzoR-00030p-UX;
	Mon, 13 Feb 2012 17:35:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.18923.933271.305391@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:35:39 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 07/10] arm: compile libxl"):
> libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
> functions are only available on x86, so ifdef the new cpuid related
> function in libxl_json.c.
...
> +#if defined(__i386__) || defined(__x86_64__)
>  yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                  libxl_cpuid_policy_list *pcpuid)
>  {
> @@ -199,6 +200,13 @@ empty:
>  out:
>      return s;
>  }
> +#else
> +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> +                                libxl_cpuid_policy_list *pcpuid)
> +{
> +    return 0;
> +}
> +#endif

Again, can't this be moved to libxl_{no,}cpuid.c ?

If we really do have to have #ifdefs (eg, if we have code that needs
to be controlled by several different conditions at once) we should
invent a suitable single #define for each feature, eg LIBXL_HAVE_CPUID
or something rather than spreading "defined(__i386__) || defined(__x86_64__)"
all over the place.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:38:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzrC-0001xN-JP; Mon, 13 Feb 2012 17:38:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzrB-0001xH-PD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:38:29 +0000
Received: from [85.158.139.83:7950] by server-2.bemta-5.messagelabs.com id
	57/11-20725-59A493F4; Mon, 13 Feb 2012 17:38:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329154708!14910477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30294 invoked from network); 13 Feb 2012 17:38:28 -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;
	13 Feb 2012 17:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:38:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:38:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzr9-00022Y-Ic; Mon, 13 Feb 2012 17:38:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzr9-00034M-HX;
	Mon, 13 Feb 2012 17:38:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19091.530418.668676@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:38:27 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 05/10] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 05/10] arm: compile libxc"):
> Introduce an empty implementation of the arch specific ARM functions in
> xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:38:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RwzrC-0001xN-JP; Mon, 13 Feb 2012 17:38:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RwzrB-0001xH-PD
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:38:29 +0000
Received: from [85.158.139.83:7950] by server-2.bemta-5.messagelabs.com id
	57/11-20725-59A493F4; Mon, 13 Feb 2012 17:38:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329154708!14910477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30294 invoked from network); 13 Feb 2012 17:38:28 -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;
	13 Feb 2012 17:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:38:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:38:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzr9-00022Y-Ic; Mon, 13 Feb 2012 17:38:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzr9-00034M-HX;
	Mon, 13 Feb 2012 17:38:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19091.530418.668676@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:38:27 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Tim.Deegan@citrix.com, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 05/10] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH v2 05/10] arm: compile libxc"):
> Introduce an empty implementation of the arch specific ARM functions in
> xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:39:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwzs7-000239-26; Mon, 13 Feb 2012 17:39: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 1Rwzs5-00022t-Vb
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:39:26 +0000
Received: from [85.158.139.83:56747] by server-10.bemta-5.messagelabs.com id
	B5/79-26909-DCA493F4; Mon, 13 Feb 2012 17:39:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329154764!14899041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22984 invoked from network); 13 Feb 2012 17:39:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669260"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:39:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:39:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzs4-000234-4I; Mon, 13 Feb 2012 17:39:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzs4-00035h-3X;
	Mon, 13 Feb 2012 17:39:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19148.96744.840804@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:39:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329149911.31256.141.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1329149911.31256.141.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools"):
> #1 committed.

Thanks for this series, Stefano.  I have applied a couple that were
obviously good to go standalone.  For the others which had a tools
part I have either acked or commented and I think it might be best if
they all went in together ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:39:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwzs7-000239-26; Mon, 13 Feb 2012 17:39: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 1Rwzs5-00022t-Vb
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:39:26 +0000
Received: from [85.158.139.83:56747] by server-10.bemta-5.messagelabs.com id
	B5/79-26909-DCA493F4; Mon, 13 Feb 2012 17:39:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329154764!14899041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22984 invoked from network); 13 Feb 2012 17:39:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 17:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669260"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:39:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:39:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzs4-000234-4I; Mon, 13 Feb 2012 17:39:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzs4-00035h-3X;
	Mon, 13 Feb 2012 17:39:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19148.96744.840804@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:39:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329149911.31256.141.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1329149911.31256.141.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools"):
> #1 committed.

Thanks for this series, Stefano.  I have applied a couple that were
obviously good to go standalone.  For the others which had a tools
part I have either acked or commented and I think it might be best if
they all went in together ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:41:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1Rwzto-0002FP-Jg; Mon, 13 Feb 2012 17:41: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 1Rwztn-0002Ea-3Z
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329154801!60902985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15289 invoked from network); 13 Feb 2012 17:40: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;
	13 Feb 2012 17:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:41:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:41:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwztg-00023i-Kl; Mon, 13 Feb 2012 17:41:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwztg-00037X-Jj;
	Mon, 13 Feb 2012 17:41:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19248.598751.534875@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:41:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329152007.31256.155.camel@zakaz.uk.xensource.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
	<1329144704.31256.114.camel@zakaz.uk.xensource.com>
	<4F393053.80903@citrix.com>
	<1329152007.31256.155.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 7/8] arm, device tree: parse the DTB for RAM location and size"):
> On Mon, 2012-02-13 at 15:46 +0000, David Vrabel wrote:
> > Dividing maintainer-ship by directory seems a little coarse grained.  It
> > may be more practical for you (Ian) to be the maintainer/committer for
> > the device tree related stuff even though they live under xen/common/.
> 
> I'd be happy to do that if there is agreement among the other
> maintainers.

That would seem sensible to me.  For now at least.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:41:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17: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.xensource.com>)
	id 1Rwzto-0002FP-Jg; Mon, 13 Feb 2012 17:41: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 1Rwztn-0002Ea-3Z
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329154801!60902985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15289 invoked from network); 13 Feb 2012 17:40: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;
	13 Feb 2012 17:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:41:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:41:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwztg-00023i-Kl; Mon, 13 Feb 2012 17:41:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwztg-00037X-Jj;
	Mon, 13 Feb 2012 17:41:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19248.598751.534875@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:41:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329152007.31256.155.camel@zakaz.uk.xensource.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-8-git-send-email-david.vrabel@citrix.com>
	<1329144704.31256.114.camel@zakaz.uk.xensource.com>
	<4F393053.80903@citrix.com>
	<1329152007.31256.155.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/8] arm,
 device tree: parse the DTB for RAM location and size
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 7/8] arm, device tree: parse the DTB for RAM location and size"):
> On Mon, 2012-02-13 at 15:46 +0000, David Vrabel wrote:
> > Dividing maintainer-ship by directory seems a little coarse grained.  It
> > may be more practical for you (Ian) to be the maintainer/committer for
> > the device tree related stuff even though they live under xen/common/.
> 
> I'd be happy to do that if there is agreement among the other
> maintainers.

That would seem sensible to me.  For now at least.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwzy9-0002bR-9r; Mon, 13 Feb 2012 17:45:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rwzy7-0002b6-Gk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:45:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329155133!14706422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14876 invoked from network); 13 Feb 2012 17:45:33 -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;
	13 Feb 2012 17:45:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:45:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:45:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzy1-000261-2g; Mon, 13 Feb 2012 17:45:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzy1-0003Ea-1k;
	Mon, 13 Feb 2012 17:45:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19517.41180.525295@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:45:33 +0000
To: Stefan Bader <stefan.bader@canonical.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F355621.7050900@canonical.com>
References: <4F353B73.1050309@canonical.com>
	<1328889108.6133.272.camel@zakaz.uk.xensource.com>
	<4F355621.7050900@canonical.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefan Bader writes ("Re: [Xen-devel] Default bridge for xl"):
> So maybe the following is good. Hopefully not introduced any stupid
> typos while moving it from the version where it was tested to HEAD.

Looks good to me.

> Subject: [PATCH] Add defaultbridge config option for xl.conf

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rwzy9-0002bR-9r; Mon, 13 Feb 2012 17:45:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rwzy7-0002b6-Gk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:45:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329155133!14706422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14876 invoked from network); 13 Feb 2012 17:45:33 -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;
	13 Feb 2012 17:45:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 17:45:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 17:45:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rwzy1-000261-2g; Mon, 13 Feb 2012 17:45:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rwzy1-0003Ea-1k;
	Mon, 13 Feb 2012 17:45:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.19517.41180.525295@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:45:33 +0000
To: Stefan Bader <stefan.bader@canonical.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F355621.7050900@canonical.com>
References: <4F353B73.1050309@canonical.com>
	<1328889108.6133.272.camel@zakaz.uk.xensource.com>
	<4F355621.7050900@canonical.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Default bridge for xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefan Bader writes ("Re: [Xen-devel] Default bridge for xl"):
> So maybe the following is good. Hopefully not introduced any stupid
> typos while moving it from the version where it was tested to HEAD.

Looks good to me.

> Subject: [PATCH] Add defaultbridge config option for xl.conf

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx04i-0002xg-6u; Mon, 13 Feb 2012 17:52:28 +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 1Rx04g-0002wy-Qp
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:52:27 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329155491!62662310!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24962 invoked from network); 13 Feb 2012 17:51:32 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 17:51: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 23BBA245C;
	Mon, 13 Feb 2012 19:52:16 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C75A020056; Mon, 13 Feb 2012 19:52:16 +0200 (EET)
Date: Mon, 13 Feb 2012 19:52:16 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120213175216.GH12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
	<20120106153714.GA21220@andromeda.dapyr.net>
	<20120206175755.GS12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120206175755.GS12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Wei Huang <wei.huang2@amd.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Extracting ATI/AMD Radeon VBIOS ROM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 07:57:55PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > >>>- Also there's a bunch of VGA passthru related patches,
> > > >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> > > >>>but I still haven't had time for that :(
> > > >>Since there were quite a lot of interest on this subject, should we
> > > >>document it in a separate wiki for working combinations (like
> > > >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> > > >>
> > > >I actually once started writing down that kind of stuff:
> > > >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> > > >
> > > >Feel free to contribute :)
> > > >
> > > >There's also:
> > > >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> > > Thanks for sharing. I will contribute my findings as needed. BTW, do =
you =

> > > need my VBIOS loading patches (sent long time ago) for AMD GPU? It is=
 a =

> > =

> > Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> > from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> > guest and it works nicely.. the first time. After I shut down the guest
> > it just never works again :-(
> > =

> =

> Hmm.. I wonder if this would work:
> =

> cd /sys/bus/pci/devices/0000:01:05.0
> sudo sh -c "echo 1 > rom"
> sudo sh -c "cat rom > ~/bios.rom"
> =


Extracting Radeon Mobility HD3650 VBIOS ROM as above works on my laptop.. =

(on baremetal Linux)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 17:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 17:52:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx04i-0002xg-6u; Mon, 13 Feb 2012 17:52:28 +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 1Rx04g-0002wy-Qp
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:52:27 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329155491!62662310!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODYyODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24962 invoked from network); 13 Feb 2012 17:51:32 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 17:51: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 23BBA245C;
	Mon, 13 Feb 2012 19:52:16 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C75A020056; Mon, 13 Feb 2012 19:52:16 +0200 (EET)
Date: Mon, 13 Feb 2012 19:52:16 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120213175216.GH12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
	<20120106153714.GA21220@andromeda.dapyr.net>
	<20120206175755.GS12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120206175755.GS12984@reaktio.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Wei Huang <wei.huang2@amd.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Extracting ATI/AMD Radeon VBIOS ROM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 06, 2012 at 07:57:55PM +0200, Pasi K=E4rkk=E4inen wrote:
> > > >>>- Also there's a bunch of VGA passthru related patches,
> > > >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> > > >>>but I still haven't had time for that :(
> > > >>Since there were quite a lot of interest on this subject, should we
> > > >>document it in a separate wiki for working combinations (like
> > > >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> > > >>
> > > >I actually once started writing down that kind of stuff:
> > > >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> > > >
> > > >Feel free to contribute :)
> > > >
> > > >There's also:
> > > >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> > > Thanks for sharing. I will contribute my findings as needed. BTW, do =
you =

> > > need my VBIOS loading patches (sent long time ago) for AMD GPU? It is=
 a =

> > =

> > Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> > from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> > guest and it works nicely.. the first time. After I shut down the guest
> > it just never works again :-(
> > =

> =

> Hmm.. I wonder if this would work:
> =

> cd /sys/bus/pci/devices/0000:01:05.0
> sudo sh -c "echo 1 > rom"
> sudo sh -c "cat rom > ~/bios.rom"
> =


Extracting Radeon Mobility HD3650 VBIOS ROM as above works on my laptop.. =

(on baremetal Linux)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0EX-0003OO-7D; Mon, 13 Feb 2012 18:02: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 1Rx0EW-0003O1-0k
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:02:36 +0000
Received: from [85.158.139.83:48412] by server-4.bemta-5.messagelabs.com id
	2C/C9-28576-B30593F4; Mon, 13 Feb 2012 18:02:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329156154!7471287!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25338 invoked from network); 13 Feb 2012 18:02:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 18:02:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 18:02:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rx0Aa-0002Db-IM; Mon, 13 Feb 2012 17:58:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rx0Aa-0003WE-HF;
	Mon, 13 Feb 2012 17:58:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.20296.521432.971229@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:58:32 +0000
To: John McDermott <segfaultreloaded@gmail.com>, Andre Przywara
	<andre.przywara@amd.com>, Juergen Gross <juergen.gross@ts.fujitsu.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20273.29183.676730.626806@mariner.uk.xensource.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
	<4F2A20FF.90607@ts.fujitsu.com>
	<20273.22113.279050.476505@mariner.uk.xensource.com>
	<20273.29183.676730.626806@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> Ian Jackson writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> > Juergen Gross writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> > > On 02/01/2012 03:48 PM, Ian Campbell wrote:
> > > > xl: Drop -l option to xl cpupool-list
> > ...
> > > > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > > 
> > > Acked-by: juergen.gross@ts.fujitsu.com
> > 
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> For the avoidance of doubt, I have applied this to xen-unstable, not
> 4.1.  I don't think it will cause anything to go wrong in -unstable
> but as a rule we should let patches sit there for a bit before
> backporting them.

I have now pushed this into 4.1-testing.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0EX-0003OO-7D; Mon, 13 Feb 2012 18:02: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 1Rx0EW-0003O1-0k
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:02:36 +0000
Received: from [85.158.139.83:48412] by server-4.bemta-5.messagelabs.com id
	2C/C9-28576-B30593F4; Mon, 13 Feb 2012 18:02:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329156154!7471287!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25338 invoked from network); 13 Feb 2012 18:02:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 18:02:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 18:02:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rx0Aa-0002Db-IM; Mon, 13 Feb 2012 17:58:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rx0Aa-0003WE-HF;
	Mon, 13 Feb 2012 17:58:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.20296.521432.971229@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:58:32 +0000
To: John McDermott <segfaultreloaded@gmail.com>, Andre Przywara
	<andre.przywara@amd.com>, Juergen Gross <juergen.gross@ts.fujitsu.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20273.29183.676730.626806@mariner.uk.xensource.com>
References: <17723C07-9B25-4C6C-A5F7-609545EDB856@gmail.com>
	<1328107728.17444.81.camel@zakaz.uk.xensource.com>
	<4F2A20FF.90607@ts.fujitsu.com>
	<20273.22113.279050.476505@mariner.uk.xensource.com>
	<20273.29183.676730.626806@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Unused Variable in xl code for CPU Pool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> Ian Jackson writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> > Juergen Gross writes ("Re: [Xen-devel] Unused Variable in xl code for CPU Pool"):
> > > On 02/01/2012 03:48 PM, Ian Campbell wrote:
> > > > xl: Drop -l option to xl cpupool-list
> > ...
> > > > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> > > 
> > > Acked-by: juergen.gross@ts.fujitsu.com
> > 
> > Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> For the avoidance of doubt, I have applied this to xen-unstable, not
> 4.1.  I don't think it will cause anything to go wrong in -unstable
> but as a rule we should let patches sit there for a bit before
> backporting them.

I have now pushed this into 4.1-testing.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:02:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0EX-0003OW-QE; Mon, 13 Feb 2012 18:02: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 1Rx0EW-0003O0-25
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:02:36 +0000
Received: from [85.158.139.83:48407] by server-5.bemta-5.messagelabs.com id
	71/88-03847-B30593F4; Mon, 13 Feb 2012 18:02:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329156154!7471287!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25350 invoked from network); 13 Feb 2012 18:02:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 18:02:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 18:02:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rx08O-0002CW-LU; Mon, 13 Feb 2012 17:56:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rx08O-0003Qv-Ke;
	Mon, 13 Feb 2012 17:56:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.20160.628074.801720@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:56:16 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <837570e539a114f47d8a.1326258829@build.localdomain>
References: <837570e539a114f47d8a.1326258829@build.localdomain>
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 v4 RESEND] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace custom checks in tools/check"):
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script, config/Tools.mk
> and config.h.

Thanks for this work.  I'm just replying to give a status update: I
haven't forgotten this.

It depends on a new feature in the autotest machinery - which would
involve it automatically running "./configure" as well as just "make".
I have a number of other test system changes which are queued up
beforehand, but this is on my list.

Last time you posted this there was an objection that autoconf 2.67
isn't necessarily that widely available.  Did you deliberately use any
2.67 features or can we have a less aggressive PREREQ ?

Also, of course, this patch has rotted slightly and no longer applies
to xen-unstable tip.  When the test system is ready I'll email again
and ask you to rebase.

Does anyone else have any comments ? 

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:02:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0EX-0003OW-QE; Mon, 13 Feb 2012 18:02: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 1Rx0EW-0003O0-25
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:02:36 +0000
Received: from [85.158.139.83:48407] by server-5.bemta-5.messagelabs.com id
	71/88-03847-B30593F4; Mon, 13 Feb 2012 18:02:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329156154!7471287!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25350 invoked from network); 13 Feb 2012 18:02:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10669857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 18:02:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 18:02:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rx08O-0002CW-LU; Mon, 13 Feb 2012 17:56:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rx08O-0003Qv-Ke;
	Mon, 13 Feb 2012 17:56:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.20160.628074.801720@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 17:56:16 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <837570e539a114f47d8a.1326258829@build.localdomain>
References: <837570e539a114f47d8a.1326258829@build.localdomain>
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 v4 RESEND] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace custom checks in tools/check"):
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script, config/Tools.mk
> and config.h.

Thanks for this work.  I'm just replying to give a status update: I
haven't forgotten this.

It depends on a new feature in the autotest machinery - which would
involve it automatically running "./configure" as well as just "make".
I have a number of other test system changes which are queued up
beforehand, but this is on my list.

Last time you posted this there was an objection that autoconf 2.67
isn't necessarily that widely available.  Did you deliberately use any
2.67 features or can we have a less aggressive PREREQ ?

Also, of course, this patch has rotted slightly and no longer applies
to xen-unstable tip.  When the test system is ready I'll email again
and ask you to rebase.

Does anyone else have any comments ? 

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:02:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx0EW-0003OH-PV; Mon, 13 Feb 2012 18:02:36 +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 1Rx0EV-0003Nn-79
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:02:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329156096!54064686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20644 invoked from network); 13 Feb 2012 18:01:38 -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;
	13 Feb 2012 18:01:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21904373"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:02:27 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	13:02:26 -0500
Message-ID: <4F395031.7000805@citrix.com>
Date: Mon, 13 Feb 2012 18:02:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Keir Fraser <keir@xen.org>
References: <CB5EF09C.396C6%keir@xen.org>
In-Reply-To: <CB5EF09C.396C6%keir@xen.org>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050109000100080801060503"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"edwin.zhai@intel.com" <edwin.zhai@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack
	methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050109000100080801060503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 13/02/12 16:53, Keir Fraser wrote:
> On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> Hello,
>>
>> XenServer6.0 (Xen 4.1.1) has had a support escalation against it for
>> Cisco C210 M2 servers.  I do not have access to any of these servers, so
>> cant debug the issue myself.
>>
>> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
>> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
>> directed EOI support must use the old IO-APIC ack method.
> Well, it's not surprising that some systems won't like this method. Firstly,
> calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
> broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
> to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
> operation.

Yes - I had noticed the naming discrepancy but decided that fixing the
issue was more important than arguing over naming at this point.

> Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
> -- if the IO-APIC does not have an EOI register, then an EOI is forced in a
> slightly gross way. I wonder how reliable that is across a broad range of
> chipsets; reliable enough to rely on it for *every* interrupt? ;-)

When I wrote __io_apic_eoi(), it was based on the comment about an
erratum on the 82093AA chipset.  The comment appears in
io_apic.c:mask_and_ack_level_ioapic_irq and end_level_ioapic_irq. 
Before my patch, Xen assumed that every IOAPIC had an EOI register which
was causing issues on older chipsets.  However, it was still using this
hack about flipping the trigger mode because of the erratum, which is
why Xen was only encountering problems as a race condition when
migrating pirqs.

The IO-APICs in question advertise their version as 0x20 so should an
EOI register.  However, I can't find a chip number reference so I cant
find a definite specification for the chip in question.

It appears that Citrix does have an almost identical server so I am
currently negotiating for access to it so I can debug this issue properly.

I have attached a patch which prevents the advertisement of EOI
Broadcast Suppression from overriding what the user specifies on the
command line.

~Andrew

> Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
> personally quite happy to see the original patch reverted.
>
>  -- Keir
>
>> A hypervisor with this check disabled (i.e. never checking for, or
>> enabling directed EOI) seems to make the system stable again (5 days
>> stable now, as opposed to a hang due to lost interrupts once every few
>> hours before).
>>
>> First of all, I have discovered that forcing "ioapic_ack=new" does not
>> have the indented effect, because verify_local_APIC trashes it, even if
>> the user has specified the ack method.  I intend to send a patch to fix
>> this in due course.
>>
>> However, as for the main issue, I cant work out any logical reason why
>> directed EOI would not work with the new ack mode.  I am still trying to
>> work out the differences in the code path incase I have missed something
>> subtle, but I wondered if anyone on the list has more knowledge of these
>> intricacies than me?  Either way, it appears that there is a bug on the
>> codepath with directed EOI and old ack method.
>>
>> Thanks in advance,
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050109000100080801060503
Content-Type: text/x-patch; name="ioapic-ack-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ioapic-ack-fix.patch"

# HG changeset patch
# Parent 9ad1e42c341bc78463b6f6610a6300f75b535fbb
IO-APIC: Prevent using EOI broadcast suppression if user specified
ioapic_ack=new on the command line.

Currently, if EOI broadcast suppression is advertised on the BSP LAPIC, Xen will
discard any user specified option regarding IO-APIC ack mode.

This patch introduces a check which prevents EOI Broadcast suppression from
forcing the IO-APIC ack mode to old if the user has explicitly asked for the new
ack mode on the command line.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 9ad1e42c341b xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -424,9 +424,15 @@ int __init verify_local_APIC(void)
      */
     if ( reg0 & APIC_LVR_DIRECTED_EOI )
     {
-        ioapic_ack_new = 0;
-        directed_eoi_enabled = 1;
-        printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        if ( ioapic_ack_new == 1 && ioapic_ack_forced == 1 )
+            printk("Not enabling directed EOI because ioapic_ack_new has been "
+                   "forced on the command line\n");
+        else
+        {
+            ioapic_ack_new = 0;
+            directed_eoi_enabled = 1;
+            printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        }
     }
 
     /*
diff -r 9ad1e42c341b xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -44,6 +44,7 @@ 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;
 
 #ifndef sis_apic_bug
 /*
@@ -1543,9 +1544,15 @@ static unsigned int startup_level_ioapic
 static void __init setup_ioapic_ack(char *s)
 {
     if ( !strcmp(s, "old") )
+    {
         ioapic_ack_new = 0;
+        ioapic_ack_forced = 1;
+    }
     else if ( !strcmp(s, "new") )
+    {
         ioapic_ack_new = 1;
+        ioapic_ack_forced = 1;
+    }
     else
         printk("Unknown ioapic_ack value specified: '%s'\n", s);
 }
diff -r 9ad1e42c341b xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -180,6 +180,7 @@ static inline void io_apic_modify(unsign
 /* 1 if "noapic" boot option passed */
 extern bool_t skip_ioapic_setup;
 extern bool_t ioapic_ack_new;
+extern bool_t ioapic_ack_forced;
 
 #ifdef CONFIG_ACPI_BOOT
 extern int io_apic_get_unique_id (int ioapic, int apic_id);

--------------050109000100080801060503
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050109000100080801060503--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:02:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx0EW-0003OH-PV; Mon, 13 Feb 2012 18:02:36 +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 1Rx0EV-0003Nn-79
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:02:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329156096!54064686!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkzMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20644 invoked from network); 13 Feb 2012 18:01:38 -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;
	13 Feb 2012 18:01:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="21904373"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:02:27 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	13:02:26 -0500
Message-ID: <4F395031.7000805@citrix.com>
Date: Mon, 13 Feb 2012 18:02:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Keir Fraser <keir@xen.org>
References: <CB5EF09C.396C6%keir@xen.org>
In-Reply-To: <CB5EF09C.396C6%keir@xen.org>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050109000100080801060503"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"edwin.zhai@intel.com" <edwin.zhai@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack
	methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------050109000100080801060503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 13/02/12 16:53, Keir Fraser wrote:
> On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> Hello,
>>
>> XenServer6.0 (Xen 4.1.1) has had a support escalation against it for
>> Cisco C210 M2 servers.  I do not have access to any of these servers, so
>> cant debug the issue myself.
>>
>> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
>> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
>> directed EOI support must use the old IO-APIC ack method.
> Well, it's not surprising that some systems won't like this method. Firstly,
> calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
> broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
> to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
> operation.

Yes - I had noticed the naming discrepancy but decided that fixing the
issue was more important than arguing over naming at this point.

> Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
> -- if the IO-APIC does not have an EOI register, then an EOI is forced in a
> slightly gross way. I wonder how reliable that is across a broad range of
> chipsets; reliable enough to rely on it for *every* interrupt? ;-)

When I wrote __io_apic_eoi(), it was based on the comment about an
erratum on the 82093AA chipset.  The comment appears in
io_apic.c:mask_and_ack_level_ioapic_irq and end_level_ioapic_irq. 
Before my patch, Xen assumed that every IOAPIC had an EOI register which
was causing issues on older chipsets.  However, it was still using this
hack about flipping the trigger mode because of the erratum, which is
why Xen was only encountering problems as a race condition when
migrating pirqs.

The IO-APICs in question advertise their version as 0x20 so should an
EOI register.  However, I can't find a chip number reference so I cant
find a definite specification for the chip in question.

It appears that Citrix does have an almost identical server so I am
currently negotiating for access to it so I can debug this issue properly.

I have attached a patch which prevents the advertisement of EOI
Broadcast Suppression from overriding what the user specifies on the
command line.

~Andrew

> Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
> personally quite happy to see the original patch reverted.
>
>  -- Keir
>
>> A hypervisor with this check disabled (i.e. never checking for, or
>> enabling directed EOI) seems to make the system stable again (5 days
>> stable now, as opposed to a hang due to lost interrupts once every few
>> hours before).
>>
>> First of all, I have discovered that forcing "ioapic_ack=new" does not
>> have the indented effect, because verify_local_APIC trashes it, even if
>> the user has specified the ack method.  I intend to send a patch to fix
>> this in due course.
>>
>> However, as for the main issue, I cant work out any logical reason why
>> directed EOI would not work with the new ack mode.  I am still trying to
>> work out the differences in the code path incase I have missed something
>> subtle, but I wondered if anyone on the list has more knowledge of these
>> intricacies than me?  Either way, it appears that there is a bug on the
>> codepath with directed EOI and old ack method.
>>
>> Thanks in advance,
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050109000100080801060503
Content-Type: text/x-patch; name="ioapic-ack-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ioapic-ack-fix.patch"

# HG changeset patch
# Parent 9ad1e42c341bc78463b6f6610a6300f75b535fbb
IO-APIC: Prevent using EOI broadcast suppression if user specified
ioapic_ack=new on the command line.

Currently, if EOI broadcast suppression is advertised on the BSP LAPIC, Xen will
discard any user specified option regarding IO-APIC ack mode.

This patch introduces a check which prevents EOI Broadcast suppression from
forcing the IO-APIC ack mode to old if the user has explicitly asked for the new
ack mode on the command line.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 9ad1e42c341b xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -424,9 +424,15 @@ int __init verify_local_APIC(void)
      */
     if ( reg0 & APIC_LVR_DIRECTED_EOI )
     {
-        ioapic_ack_new = 0;
-        directed_eoi_enabled = 1;
-        printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        if ( ioapic_ack_new == 1 && ioapic_ack_forced == 1 )
+            printk("Not enabling directed EOI because ioapic_ack_new has been "
+                   "forced on the command line\n");
+        else
+        {
+            ioapic_ack_new = 0;
+            directed_eoi_enabled = 1;
+            printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        }
     }
 
     /*
diff -r 9ad1e42c341b xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -44,6 +44,7 @@ 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;
 
 #ifndef sis_apic_bug
 /*
@@ -1543,9 +1544,15 @@ static unsigned int startup_level_ioapic
 static void __init setup_ioapic_ack(char *s)
 {
     if ( !strcmp(s, "old") )
+    {
         ioapic_ack_new = 0;
+        ioapic_ack_forced = 1;
+    }
     else if ( !strcmp(s, "new") )
+    {
         ioapic_ack_new = 1;
+        ioapic_ack_forced = 1;
+    }
     else
         printk("Unknown ioapic_ack value specified: '%s'\n", s);
 }
diff -r 9ad1e42c341b xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -180,6 +180,7 @@ static inline void io_apic_modify(unsign
 /* 1 if "noapic" boot option passed */
 extern bool_t skip_ioapic_setup;
 extern bool_t ioapic_ack_new;
+extern bool_t ioapic_ack_forced;
 
 #ifdef CONFIG_ACPI_BOOT
 extern int io_apic_get_unique_id (int ioapic, int apic_id);

--------------050109000100080801060503
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050109000100080801060503--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:04:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0G5-0003f2-B0; Mon, 13 Feb 2012 18:04:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rx0G2-0003e0-LG
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:04:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329156234!10489572!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20680 invoked from network); 13 Feb 2012 18:04:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181540398"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:03:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 13:03:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DI3o2b025360;	Mon, 13 Feb 2012 10:03:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
Message-ID: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 18:03:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: stefano.stabellini@citrix.com, tim@xen.org, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329153968 0
# Node ID 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
# Parent  7fd8f10cfd3eaf9f0982eb6fd49334a1e229ba98
arm: fixup hard tabs

Unfortunately the tool I was using to apply patches mangles hard tabs. This
patch corrects this in the effected files (which is fortunately only a subset
of .S or files imported from Linux)

"git diff" and "git diff -b" vs. Stefano's v6 branch now contain the same
output -- i.e. only the intervening development

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/dtb.S
--- a/xen/arch/arm/dtb.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/dtb.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,2 +1,2 @@
-        .section .dtb,#alloc
-        .incbin CONFIG_DTB_FILE
+	.section .dtb,#alloc
+	.incbin CONFIG_DTB_FILE
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/dummy.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,13 +1,13 @@
 /* Nothing is mapped at 1G, for the moment */
 #define DUMMY(x) \
-       .globl x; \
-x:     .word 0xe7f000f0
-/* x:  mov r0, #0x40000000 ; str r0, [r0]; b x */
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
 
 #define  NOP(x) \
-       .globl x; \
-x:     mov pc, lr
-
+	.globl x; \
+x:	mov pc, lr
+	
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_do_domctl);
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/entry.S
--- a/xen/arch/arm/entry.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/entry.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,69 +1,69 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
 
-#define SAVE_ONE_BANKED(reg)   mrs r11, reg; str r11, [sp, #UREGS_##reg]
-#define RESTORE_ONE_BANKED(reg)        ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
 
 #define SAVE_BANKED(mode) \
-       SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
 
 #define RESTORE_BANKED(mode) \
-       RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
 
-#define SAVE_ALL                                                                                       \
-       sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */                                      \
-       push {r0-r12}; /* Save R0-R12 */                                                                \
-                                                                                                       \
-       mrs r11, ELR_hyp;               /* ELR_hyp is return address. */                                \
-       str r11, [sp, #UREGS_pc];                                                                       \
-                                                                                                       \
-       str lr, [sp, #UREGS_lr];                                                                        \
-                                                                                                       \
-       add r11, sp, #UREGS_kernel_sizeof+4;                                                            \
-       str r11, [sp, #UREGS_sp];                                                                       \
-                                                                                                       \
-       mrs r11, SPSR_hyp;                                                                              \
-       str r11, [sp, #UREGS_cpsr];                                                                     \
-       and r11, #PSR_MODE_MASK;                                                                        \
-       cmp r11, #PSR_MODE_HYP;                                                                         \
-       blne save_guest_regs
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
 
 save_guest_regs:
-       ldr r11, [sp, #UREGS_lr]
-       str r11, [sp, #UREGS_LR_usr]
-       ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
-       str r11, [sp, #UREGS_sp]
-       SAVE_ONE_BANKED(SP_usr)
-       SAVE_BANKED(svc)
-       SAVE_BANKED(abt)
-       SAVE_BANKED(und)
-       SAVE_BANKED(irq)
-       SAVE_BANKED(fiq)
-       SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
-       SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
-       mov pc, lr
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
 
-#define DEFINE_TRAP_ENTRY(trap)                                                                                \
-       ALIGN;                                                                                          \
-trap_##trap:                                                                                           \
-       SAVE_ALL;                                                                                       \
-       adr lr, return_from_trap;                                                                       \
-       mov r0, sp;                                                                                     \
-       mov r11, sp;                                                                                    \
-       bic sp, #7; /* Align the stack pointer (noop on guest trap) */                                  \
-       b do_trap_##trap
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
 
 .globl hyp_traps_vector
-       .align 5
+	.align 5
 hyp_traps_vector:
-       .word 0                         /* 0x00 - Reset */
-       b trap_undefined_instruction    /* 0x04 - Undefined Instruction */
-       b trap_supervisor_call          /* 0x08 - Supervisor Call */
-       b trap_prefetch_abort           /* 0x0c - Prefetch Abort */
-       b trap_data_abort               /* 0x10 - Data Abort */
-       b trap_hypervisor               /* 0x14 - Hypervisor */
-       b trap_irq                      /* 0x18 - IRQ */
-       b trap_fiq                      /* 0x1c - FIQ */
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
 
 DEFINE_TRAP_ENTRY(undefined_instruction)
 DEFINE_TRAP_ENTRY(supervisor_call)
@@ -74,34 +74,34 @@ DEFINE_TRAP_ENTRY(irq)
 DEFINE_TRAP_ENTRY(fiq)
 
 ENTRY(return_from_trap)
-       ldr r11, [sp, #UREGS_cpsr]
-       and r11, #PSR_MODE_MASK
-       cmp r11, #PSR_MODE_HYP
-       beq return_to_hypervisor
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
 
 ENTRY(return_to_guest)
-       mov r11, sp
-       bic sp, #7 /* Align the stack pointer */
-       bl leave_hypervisor_tail
-       ldr r11, [sp, #UREGS_pc]
-       msr ELR_hyp, r11
-       ldr r11, [sp, #UREGS_cpsr]
-       msr SPSR_hyp, r11
-       RESTORE_ONE_BANKED(SP_usr)
-       RESTORE_BANKED(svc)
-       RESTORE_BANKED(abt)
-       RESTORE_BANKED(und)
-       RESTORE_BANKED(irq)
-       RESTORE_BANKED(fiq)
-       RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
-       RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
-       ldr lr, [sp, #UREGS_LR_usr]
-       pop {r0-r12}
-       add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
-       eret
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
 
 ENTRY(return_to_hypervisor)
-       ldr lr, [sp, #UREGS_lr]
-       pop {r0-r12}
-       add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
-       eret
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/head.S	Mon Feb 13 17:26:08 2012 +0000
@@ -26,281 +26,281 @@
  * Clobbers r0-r3. */
 #ifdef EARLY_UART_ADDRESS
 #define PRINT(_s)       \
-       adr   r0, 98f ; \
-       bl    puts    ; \
-       b     99f     ; \
-98:    .asciz _s     ; \
-       .align 2      ; \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
 99:
 #else
 #define PRINT(s)
 #endif
 
-       .arm
+	.arm
 
-       /* This must be the very first address in the loaded image.
-        * It should be linked at XEN_VIRT_START, and loaded at any
-        * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
-        * or the initial pagetable code below will need adjustment. */
-       .global start
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
 start:
-       cpsid aif                    /* Disable all interrupts */
+	cpsid aif                    /* Disable all interrupts */
 
-       /* Save the bootloader arguments in less-clobberable registers */
-       mov   r7, r1                 /* r7 := ARM-linux machine type */
-       mov   r8, r2                 /* r8 := ATAG base address */
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
 
-       /* Find out where we are */
-       ldr   r0, =start
-       adr   r9, start              /* r9  := paddr (start) */
-       sub   r10, r9, r0            /* r10 := phys-offset */
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
 
-        /* Using the DTB in the .dtb section? */
+	/* Using the DTB in the .dtb section? */
 #ifdef CONFIG_DTB_FILE
-        ldr   r8, =_sdtb
-        add   r8, r10                /* r8 := paddr(DTB) */
+	ldr   r8, =_sdtb
+	add   r8, r10                /* r8 := paddr(DTB) */
 #endif
 
 #ifdef EARLY_UART_ADDRESS
-       /* Say hello */
-       ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
-       bl    init_uart
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
 #endif
 
-       /* Check that this CPU has Hyp mode */
-       mrc   CP32(r0, ID_PFR1)
-       and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
-       teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
-       beq   1f
-       bl    putn
-       PRINT("- CPU doesn't support the virtualization extensions -\r\n")
-       b     fail
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
 1:
-       /* Check if we're already in it */
-       mrs   r0, cpsr
-       and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
-       teq   r0, #0x1a              /* Hyp Mode? */
-       bne   1f
-       PRINT("- Started in Hyp mode -\r\n")
-       b     hyp
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
 1:
-       /* Otherwise, it must have been Secure Supervisor mode */
-       mrc   CP32(r0, SCR)
-       tst   r0, #0x1               /* Not-Secure bit set? */
-       beq   1f
-       PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
-       b     fail
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
 1:
-       /* OK, we're in Secure state. */
-       PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
 
-       /* Dance into Hyp mode */
-       cpsid aif, #0x16             /* Enter Monitor mode */
-       mrc   CP32(r0, SCR)
-       orr   r0, r0, #0x100         /* Set HCE */
-       orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
-       bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
-       mcr   CP32(r0, SCR)
-       /* Ugly: the system timer's frequency register is only
-        * programmable in Secure state.  Since we don't know where its
-        * memory-mapped control registers live, we can't find out the
-        * right frequency.  Use the VE model's default frequency here. */
-       ldr   r0, =0x5f5e100         /* 100 MHz */
-       mcr   CP32(r0, CNTFRQ)
-       ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
-       mcr   CP32(r0, NSACR)
-       /* Continuing ugliness: Set up the GIC so NS state owns interrupts */
-       mov   r0, #GIC_BASE_ADDRESS
-       add   r0, r0, #GIC_DR_OFFSET
-       mov   r1, #0
-       str   r1, [r0]               /* Disable delivery in the distributor */
-       add   r0, r0, #0x80          /* GICD_IGROUP0 */
-       mov   r2, #0xffffffff        /* All interrupts to group 1 */
-       str   r2, [r0]
-       str   r2, [r0, #4]
-       str   r2, [r0, #8]
-       /* Must drop priority mask below 0x80 before entering NS state */
-       mov   r0, #GIC_BASE_ADDRESS
-       add   r0, r0, #GIC_CR_OFFSET
-       ldr   r1, =0xff
-       str   r1, [r0, #0x4]         /* -> GICC_PMR */
-       /* Reset a few config registers */
-       mov   r0, #0
-       mcr   CP32(r0, FCSEIDR)
-       mcr   CP32(r0, CONTEXTIDR)
-       /* FIXME: ought to reset some other NS control regs here */
-       adr   r1, 1f
-       adr   r0, hyp                /* Store paddr (hyp entry point) */
-       str   r0, [r1]               /* where we can use it for RFE */
-       isb                          /* Ensure we see the stored target address */
-       rfeia r1                     /* Enter Hyp mode */
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
 
-1:     .word 0                      /* PC to enter Hyp mode at */
-       .word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
 
 hyp:
-       PRINT("- Setting up control registers -\r\n")
+	PRINT("- Setting up control registers -\r\n")
 
-       /* Set up memory attribute type tables */
-       ldr   r0, =MAIR0VAL
-       ldr   r1, =MAIR1VAL
-       mcr   CP32(r0, MAIR0)
-       mcr   CP32(r1, MAIR1)
-       mcr   CP32(r0, HMAIR0)
-       mcr   CP32(r1, HMAIR1)
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
 
-       /* Set up the HTCR:
-        * PT walks use Outer-Shareable accesses,
-        * PT walks are write-back, no-write-allocate in both cache levels,
-        * Full 32-bit address space goes through this table. */
-       ldr   r0, =0x80002500
-       mcr   CP32(r0, HTCR)
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
 
-       /* Set up the HSCTLR:
-        * Exceptions in LE ARM,
-        * Low-latency IRQs disabled,
-        * Write-implies-XN disabled (for now),
-        * I-cache and d-cache enabled,
-        * Alignment checking enabled,
-        * MMU translation disabled (for now). */
-       ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
-       mcr   CP32(r0, HSCTLR)
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
 
-       /* Write Xen's PT's paddr into the HTTBR */
-       ldr   r4, =xen_pgtable
-       add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
-       mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
-       mcrr  CP64(r4, r5, HTTBR)
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
 
-       /* Build the baseline idle pagetable's first-level entries */
-       ldr   r1, =xen_second
-       add   r1, r1, r10            /* r1 := paddr (xen_second) */
-       mov   r3, #0x0
-       orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
-       orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
-       strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
-       add   r2, r2, #0x1000
-       strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
-       add   r2, r2, #0x1000
-       strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
-       add   r2, r2, #0x1000
-       strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
 
-       /* Now set up the second-level entries */
-       orr   r2, r9, #0xe00
-       orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
-       mov   r4, r9, lsr #18        /* Slot for paddr(start) */
-       strd  r2, r3, [r1, r4]       /* Map Xen there */
-       ldr   r4, =start
-       lsr   r4, #18                /* Slot for vaddr(start) */
-       strd  r2, r3, [r1, r4]       /* Map Xen there too */
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
 #ifdef EARLY_UART_ADDRESS
-       ldr   r3, =(1<<(54-32))      /* NS for device mapping */
-       lsr   r2, r11, #21
-       lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
-       orr   r2, r2, #0xe00
-       orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
-       add   r4, r4, #8
-       strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #else
-       add   r4, r4, #8             /* Skip over unused fixmap slot */
+	add   r4, r4, #8             /* Skip over unused fixmap slot */
 #endif
-       mov   r3, #0x0
-       lsr   r2, r8, #21
-       lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
-       orr   r2, r2, #0xf00
-       orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
-       add   r4, r4, #8
-       strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
+	mov   r3, #0x0
+	lsr   r2, r8, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+	orr   r2, r2, #0xf00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
-       PRINT("- Turning on paging -\r\n")
+	PRINT("- Turning on paging -\r\n")
 
-       ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
-       mrc   CP32(r0, HSCTLR)
-       orr   r0, r0, #0x1           /* Add in the MMU enable bit */
-       dsb                          /* Flush PTE writes and finish reads */
-       mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
-       isb                          /* Now, flush the icache */
-       mov   pc, r1                 /* Get a proper vaddr into PC */
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
 #ifdef EARLY_UART_ADDRESS
-       /* Recover the UART address in the new address space */
-       lsl   r11, #11
-       lsr   r11, #11               /* UART base's offset from 2MB base */
-       adr   r0, start
-       add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
-       add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
 #endif
 
-       PRINT("- Entering C -\r\n")
+	PRINT("- Entering C -\r\n")
 
-       ldr   sp, =init_stack        /* Supply a stack */
-       add   sp, #STACK_SIZE        /* (which grows down from the top). */
-       sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
-       mov   r0, r10                /* Marshal args: - phys_offset */
-       mov   r1, r7                 /*               - machine type */
-       mov   r2, r8                 /*               - ATAG address */
-       b     start_xen              /* and disappear into the land of C */
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
 
 /* Fail-stop
  * r0: string explaining why */
-fail:  PRINT("- Boot failed -\r\n")
-1:     wfe
-       b     1b
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
 
 #ifdef EARLY_UART_ADDRESS
 
 /* Bring up the UART. Specific to the PL011 UART.
  * Clobbers r0-r2 */
 init_uart:
-       mov   r1, #0x0
-       str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
-       mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
-       str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
-       mov   r1, #0x60              /* 8n1 */
-       str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
-       ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
-       str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
-       adr   r0, 1f
-       b     puts
-1:     .asciz "- UART enabled -\r\n"
-       .align 4
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
 
 /* Print early debug messages.  Specific to the PL011 UART.
  * r0: Nul-terminated string to print.
  * Clobbers r0-r2 */
 puts:
-       ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
-       tst   r2, #0x8               /* Check BUSY bit */
-       bne   puts                   /* Wait for the UART to be ready */
-       ldrb  r2, [r0], #1           /* Load next char */
-       teq   r2, #0                 /* Exit on nul*/
-       moveq pc, lr
-       str   r2, [r11]              /* -> UARTDR (Data Register) */
-       b     puts
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
 
 /* Print a 32-bit number in hex.  Specific to the PL011 UART.
  * r0: Number to print.
  * clobbers r0-r3 */
 putn:
-       adr   r1, hex
-       mov   r3, #8
-1:     ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
-       tst   r2, #0x8               /* Check BUSY bit */
-       bne   1b                     /* Wait for the UART to be ready */
-       and   r2, r0, #0xf0000000    /* Mask off the top nybble */
-       ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
-       str   r2, [r11]              /* -> UARTDR (Data Register) */
-       lsl   r0, #4                 /* Roll it through one nybble at a time */
-       subs  r3, r3, #1
-       bne   1b
-       adr   r0, crlf               /* Finish with a newline */
-       b     puts
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
 
-crlf:  .asciz "\r\n"
-hex:   .ascii "0123456789abcdef"
-       .align 2
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
 
 #else  /* EARLY_UART_ADDRESS */
 
@@ -308,6 +308,6 @@ init_uart:
 .global early_puts
 early_puts:
 puts:
-putn:  mov   pc, lr
+putn:	mov   pc, lr
 
 #endif /* EARLY_UART_ADDRESS */
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/bitops.h
--- a/xen/arch/arm/lib/bitops.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/bitops.h	Mon Feb 13 17:26:08 2012 +0000
@@ -1,61 +1,61 @@
 #include <xen/config.h>
 
 #if __LINUX_ARM_ARCH__ >= 6
-       .macro  bitop, instr
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       mov     r2, #1
-       and     r3, r0, #31             @ Get bit offset
-       mov     r0, r0, lsr #5
-       add     r1, r1, r0, lsl #2      @ Get word offset
-       mov     r3, r2, lsl r3
-1:     ldrex   r2, [r1]
-       \instr  r2, r2, r3
-       strex   r0, r2, [r1]
-       cmp     r0, #0
-       bne     1b
-       bx      lr
-       .endm
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
 
-       .macro  testop, instr, store
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       mov     r2, #1
-       and     r3, r0, #31             @ Get bit offset
-       mov     r0, r0, lsr #5
-       add     r1, r1, r0, lsl #2      @ Get word offset
-       mov     r3, r2, lsl r3          @ create mask
-       smp_dmb
-1:     ldrex   r2, [r1]
-       ands    r0, r2, r3              @ save old value of bit
-       \instr  r2, r2, r3              @ toggle bit
-       strex   ip, r2, [r1]
-       cmp     ip, #0
-       bne     1b
-       smp_dmb
-       cmp     r0, #0
-       movne   r0, #1
-2:     bx      lr
-       .endm
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
 #else
-       .macro  bitop, name, instr
-ENTRY( \name           )
-UNWIND(        .fnstart        )
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       and     r2, r0, #31
-       mov     r0, r0, lsr #5
-       mov     r3, #1
-       mov     r3, r3, lsl r2
-       save_and_disable_irqs ip
-       ldr     r2, [r1, r0, lsl #2]
-       \instr  r2, r2, r3
-       str     r2, [r1, r0, lsl #2]
-       restore_irqs ip
-       mov     pc, lr
-UNWIND(        .fnend          )
-ENDPROC(\name          )
-       .endm
+	.macro	bitop, name, instr
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
+	mov	r3, #1
+	mov	r3, r3, lsl r2
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]
+	\instr	r2, r2, r3
+	str	r2, [r1, r0, lsl #2]
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
 
 /**
  * testop - implement a test_and_xxx_bit operation.
@@ -65,23 +65,23 @@ ENDPROC(\name          )
  * Note: we can trivially conditionalise the store instruction
  * to avoid dirtying the data cache.
  */
-       .macro  testop, name, instr, store
-ENTRY( \name           )
-UNWIND(        .fnstart        )
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       and     r3, r0, #31
-       mov     r0, r0, lsr #5
-       save_and_disable_irqs ip
-       ldr     r2, [r1, r0, lsl #2]!
-       mov     r0, #1
-       tst     r2, r0, lsl r3
-       \instr  r2, r2, r0, lsl r3
-       \store  r2, [r1]
-       moveq   r0, #0
-       restore_irqs ip
-       mov     pc, lr
-UNWIND(        .fnend          )
-ENDPROC(\name          )
-       .endm
+	.macro	testop, name, instr, store
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
+	tst	r2, r0, lsl r3
+	\instr	r2, r2, r0, lsl r3
+	\store	r2, [r1]
+	moveq	r0, #0
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
 #endif
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/changebit.S
--- a/xen/arch/arm/lib/changebit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/changebit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_change_bit)
-       bitop   eor
+	bitop	eor
 ENDPROC(_change_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/clearbit.S
--- a/xen/arch/arm/lib/clearbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/clearbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -15,5 +15,5 @@
                 .text
 
 ENTRY(_clear_bit)
-       bitop   bic
+	bitop	bic
 ENDPROC(_clear_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/copy_template.S
--- a/xen/arch/arm/lib/copy_template.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/copy_template.S	Mon Feb 13 17:26:08 2012 +0000
@@ -3,9 +3,9 @@
  *
  *  Code template for optimized memory copy functions
  *
- *  Author:    Nicolas Pitre
- *  Created:   Sep 28, 2005
- *  Copyright: MontaVista Software, Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
  *
  *  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
@@ -24,227 +24,227 @@
  *
  * ldr1w ptr reg abort
  *
- *     This loads one word from 'ptr', stores it in 'reg' and increments
- *     'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
  *
  * ldr4w ptr reg1 reg2 reg3 reg4 abort
  * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
  *
- *     This loads four or eight words starting from 'ptr', stores them
- *     in provided registers and increments 'ptr' past those words.
- *     The'abort' argument is used for fixup tables.
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
  *
  * ldr1b ptr reg cond abort
  *
- *     Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
- *     It also must apply the condition code if provided, otherwise the
- *     "al" condition is assumed by default.
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
  *
  * str1w ptr reg abort
  * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
  * str1b ptr reg cond abort
  *
- *     Same as their ldr* counterparts, but data is stored to 'ptr' location
- *     rather than being loaded.
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
  *
  * enter reg1 reg2
  *
- *     Preserve the provided registers on the stack plus any additional
- *     data as needed by the implementation including this code. Called
- *     upon code entry.
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
  *
  * exit reg1 reg2
  *
- *     Restore registers with the values previously saved with the
- *     'preserv' macro. Called upon code termination.
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
  *
  * LDR1W_SHIFT
  * STR1W_SHIFT
  *
- *     Correction to be applied to the "ip" register when branching into
- *     the ldr1w or str1w instructions (some of these macros may expand to
- *     than one 32bit instruction in Thumb-2)
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
  */
 
 
-               enter   r4, lr
+		enter	r4, lr
 
-               subs    r2, r2, #4
-               blt     8f
-               ands    ip, r0, #3
-       PLD(    pld     [r1, #0]                )
-               bne     9f
-               ands    ip, r1, #3
-               bne     10f
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
 
-1:             subs    r2, r2, #(28)
-               stmfd   sp!, {r5 - r8}
-               blt     5f
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  rsb     r3, ip, #32             )
-       CALGN(  sbcnes  r4, r3, r2              )  @ C is always set here
-       CALGN(  bcs     2f                      )
-       CALGN(  adr     r4, 6f                  )
-       CALGN(  subs    r2, r2, r3              )  @ C gets set
-       CALGN(  add     pc, r4, ip              )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
 
-       PLD(    pld     [r1, #0]                )
-2:     PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #28]               )
-       PLD(    blt     4f                      )
-       PLD(    pld     [r1, #60]               )
-       PLD(    pld     [r1, #92]               )
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
 
-3:     PLD(    pld     [r1, #124]              )
-4:             ldr8w   r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
-               subs    r2, r2, #32
-               str8w   r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
-               bge     3b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     4b                      )
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
 
-5:             ands    ip, r2, #28
-               rsb     ip, ip, #32
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
 #if LDR1W_SHIFT > 0
-               lsl     ip, ip, #LDR1W_SHIFT
+		lsl	ip, ip, #LDR1W_SHIFT
 #endif
-               addne   pc, pc, ip              @ C is always clear here
-               b       7f
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
 6:
-               .rept   (1 << LDR1W_SHIFT)
-               W(nop)
-               .endr
-               ldr1w   r1, r3, abort=20f
-               ldr1w   r1, r4, abort=20f
-               ldr1w   r1, r5, abort=20f
-               ldr1w   r1, r6, abort=20f
-               ldr1w   r1, r7, abort=20f
-               ldr1w   r1, r8, abort=20f
-               ldr1w   r1, lr, abort=20f
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
 
 #if LDR1W_SHIFT < STR1W_SHIFT
-               lsl     ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
 #elif LDR1W_SHIFT > STR1W_SHIFT
-               lsr     ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
 #endif
-               add     pc, pc, ip
-               nop
-               .rept   (1 << STR1W_SHIFT)
-               W(nop)
-               .endr
-               str1w   r0, r3, abort=20f
-               str1w   r0, r4, abort=20f
-               str1w   r0, r5, abort=20f
-               str1w   r0, r6, abort=20f
-               str1w   r0, r7, abort=20f
-               str1w   r0, r8, abort=20f
-               str1w   r0, lr, abort=20f
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
 
-       CALGN(  bcs     2b                      )
+	CALGN(	bcs	2b			)
 
-7:             ldmfd   sp!, {r5 - r8}
+7:		ldmfd	sp!, {r5 - r8}
 
-8:             movs    r2, r2, lsl #31
-               ldr1b   r1, r3, ne, abort=21f
-               ldr1b   r1, r4, cs, abort=21f
-               ldr1b   r1, ip, cs, abort=21f
-               str1b   r0, r3, ne, abort=21f
-               str1b   r0, r4, cs, abort=21f
-               str1b   r0, ip, cs, abort=21f
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
 
-               exit    r4, pc
+		exit	r4, pc
 
-9:             rsb     ip, ip, #4
-               cmp     ip, #2
-               ldr1b   r1, r3, gt, abort=21f
-               ldr1b   r1, r4, ge, abort=21f
-               ldr1b   r1, lr, abort=21f
-               str1b   r0, r3, gt, abort=21f
-               str1b   r0, r4, ge, abort=21f
-               subs    r2, r2, ip
-               str1b   r0, lr, abort=21f
-               blt     8b
-               ands    ip, r1, #3
-               beq     1b
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
 
-10:            bic     r1, r1, #3
-               cmp     ip, #2
-               ldr1w   r1, lr, abort=21f
-               beq     17f
-               bgt     18f
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
 
 
-               .macro  forward_copy_shift pull push
+		.macro	forward_copy_shift pull push
 
-               subs    r2, r2, #28
-               blt     14f
+		subs	r2, r2, #28
+		blt	14f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  rsb     ip, ip, #32             )
-       CALGN(  sbcnes  r4, ip, r2              )  @ C is always set here
-       CALGN(  subcc   r2, r2, ip              )
-       CALGN(  bcc     15f                     )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
 
-11:            stmfd   sp!, {r5 - r9}
+11:		stmfd	sp!, {r5 - r9}
 
-       PLD(    pld     [r1, #0]                )
-       PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #28]               )
-       PLD(    blt     13f                     )
-       PLD(    pld     [r1, #60]               )
-       PLD(    pld     [r1, #92]               )
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
 
-12:    PLD(    pld     [r1, #124]              )
-13:            ldr4w   r1, r4, r5, r6, r7, abort=19f
-               mov     r3, lr, pull #\pull
-               subs    r2, r2, #32
-               ldr4w   r1, r8, r9, ip, lr, abort=19f
-               orr     r3, r3, r4, push #\push
-               mov     r4, r4, pull #\pull
-               orr     r4, r4, r5, push #\push
-               mov     r5, r5, pull #\pull
-               orr     r5, r5, r6, push #\push
-               mov     r6, r6, pull #\pull
-               orr     r6, r6, r7, push #\push
-               mov     r7, r7, pull #\pull
-               orr     r7, r7, r8, push #\push
-               mov     r8, r8, pull #\pull
-               orr     r8, r8, r9, push #\push
-               mov     r9, r9, pull #\pull
-               orr     r9, r9, ip, push #\push
-               mov     ip, ip, pull #\pull
-               orr     ip, ip, lr, push #\push
-               str8w   r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
-               bge     12b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     13b                     )
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
 
-               ldmfd   sp!, {r5 - r9}
+		ldmfd	sp!, {r5 - r9}
 
-14:            ands    ip, r2, #28
-               beq     16f
+14:		ands	ip, r2, #28
+		beq	16f
 
-15:            mov     r3, lr, pull #\pull
-               ldr1w   r1, lr, abort=21f
-               subs    ip, ip, #4
-               orr     r3, r3, lr, push #\push
-               str1w   r0, r3, abort=21f
-               bgt     15b
-       CALGN(  cmp     r2, #0                  )
-       CALGN(  bge     11b                     )
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
 
-16:            sub     r1, r1, #(\push / 8)
-               b       8b
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
 
-               .endm
+		.endm
 
 
-               forward_copy_shift      pull=8  push=24
+		forward_copy_shift	pull=8	push=24
 
-17:            forward_copy_shift      pull=16 push=16
+17:		forward_copy_shift	pull=16	push=16
 
-18:            forward_copy_shift      pull=24 push=8
+18:		forward_copy_shift	pull=24	push=8
 
 
 /*
@@ -254,14 +254,14 @@ 18:            forward_copy_shift      p
  * the exit macro.
  */
 
-       .macro  copy_abort_preamble
-19:    ldmfd   sp!, {r5 - r9}
-       b       21f
-20:    ldmfd   sp!, {r5 - r8}
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
 21:
-       .endm
+	.endm
 
-       .macro  copy_abort_end
-       ldmfd   sp!, {r4, pc}
-       .endm
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/div64.S
--- a/xen/arch/arm/lib/div64.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/div64.S	Mon Feb 13 17:26:08 2012 +0000
@@ -3,9 +3,9 @@
  *
  *  Optimized computation of 64-bit dividend / 32-bit divisor
  *
- *  Author:    Nicolas Pitre
- *  Created:   Oct 5, 2003
- *  Copyright: Monta Vista Software, Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
  *
  *  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
@@ -14,7 +14,7 @@
 
 #include <xen/config.h>
 #include "assembler.h"
-
+	
 #ifdef __ARMEB__
 #define xh r0
 #define xl r1
@@ -34,12 +34,12 @@
  *       This is meant to be used by do_div() from include/asm/div64.h only.
  *
  * Input parameters:
- *     xh-xl   = dividend (clobbered)
- *     r4      = divisor (preserved)
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
  *
  * Output values:
- *     yh-yl   = result
- *     xh      = remainder
+ * 	yh-yl	= result
+ * 	xh	= remainder
  *
  * Clobbered regs: xl, ip
  */
@@ -47,165 +47,165 @@
 ENTRY(__do_div64)
 UNWIND(.fnstart)
 
-       @ Test for easy paths first.
-       subs    ip, r4, #1
-       bls     9f                      @ divisor is 0 or 1
-       tst     ip, r4
-       beq     8f                      @ divisor is power of 2
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
 
-       @ See if we need to handle upper 32-bit result.
-       cmp     xh, r4
-       mov     yh, #0
-       blo     3f
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
 
-       @ Align divisor with upper part of dividend.
-       @ The aligned divisor is stored in yl preserving the original.
-       @ The bit position is stored in ip.
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     yl, r4
-       clz     ip, xh
-       sub     yl, yl, ip
-       mov     ip, #1
-       mov     ip, ip, lsl yl
-       mov     yl, r4, lsl yl
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
 
 #else
 
-       mov     yl, r4
-       mov     ip, #1
-1:     cmp     yl, #0x80000000
-       cmpcc   yl, xh
-       movcc   yl, yl, lsl #1
-       movcc   ip, ip, lsl #1
-       bcc     1b
+	mov	yl, r4
+	mov	ip, #1
+1:	cmp	yl, #0x80000000
+	cmpcc	yl, xh
+	movcc	yl, yl, lsl #1
+	movcc	ip, ip, lsl #1
+	bcc	1b
 
 #endif
 
-       @ The division loop for needed upper bit positions.
-       @ Break out early if dividend reaches 0.
-2:     cmp     xh, yl
-       orrcs   yh, yh, ip
-       subcss  xh, xh, yl
-       movnes  ip, ip, lsr #1
-       mov     yl, yl, lsr #1
-       bne     2b
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
 
-       @ See if we need to handle lower 32-bit result.
-3:     cmp     xh, #0
-       mov     yl, #0
-       cmpeq   xl, r4
-       movlo   xh, xl
-       movlo   pc, lr
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
 
-       @ The division loop for lower bit positions.
-       @ Here we shift remainer bits leftwards rather than moving the
-       @ divisor for comparisons, considering the carry-out bit as well.
-       mov     ip, #0x80000000
-4:     movs    xl, xl, lsl #1
-       adcs    xh, xh, xh
-       beq     6f
-       cmpcc   xh, r4
-5:     orrcs   yl, yl, ip
-       subcs   xh, xh, r4
-       movs    ip, ip, lsr #1
-       bne     4b
-       mov     pc, lr
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
 
-       @ The top part of remainder became zero.  If carry is set
-       @ (the 33th bit) this is a false positive so resume the loop.
-       @ Otherwise, if lower part is also null then we are done.
-6:     bcs     5b
-       cmp     xl, #0
-       moveq   pc, lr
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
 
-       @ We still have remainer bits in the low part.  Bring them up.
+	@ We still have remainer bits in the low part.  Bring them up.
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     xh, xl                  @ we know xh is zero here so...
-       add     xh, xh, #1
-       mov     xl, xl, lsl xh
-       mov     ip, ip, lsr xh
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
 
 #else
 
-7:     movs    xl, xl, lsl #1
-       mov     ip, ip, lsr #1
-       bcc     7b
+7:	movs	xl, xl, lsl #1
+	mov	ip, ip, lsr #1
+	bcc	7b
 
 #endif
 
-       @ Current remainder is now 1.  It is worthless to compare with
-       @ divisor at this point since divisor can not be smaller than 3 here.
-       @ If possible, branch for another shift in the division loop.
-       @ If no bit position left then we are done.
-       movs    ip, ip, lsr #1
-       mov     xh, #1
-       bne     4b
-       mov     pc, lr
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
 
-8:     @ Division by a power of 2: determine what that divisor order is
-       @ then simply shift values around
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     ip, r4
-       rsb     ip, ip, #31
+	clz	ip, r4
+	rsb	ip, ip, #31
 
 #else
 
-       mov     yl, r4
-       cmp     r4, #(1 << 16)
-       mov     ip, #0
-       movhs   yl, yl, lsr #16
-       movhs   ip, #16
+	mov	yl, r4
+	cmp	r4, #(1 << 16)
+	mov	ip, #0
+	movhs	yl, yl, lsr #16
+	movhs	ip, #16
 
-       cmp     yl, #(1 << 8)
-       movhs   yl, yl, lsr #8
-       addhs   ip, ip, #8
+	cmp	yl, #(1 << 8)
+	movhs	yl, yl, lsr #8
+	addhs	ip, ip, #8
 
-       cmp     yl, #(1 << 4)
-       movhs   yl, yl, lsr #4
-       addhs   ip, ip, #4
+	cmp	yl, #(1 << 4)
+	movhs	yl, yl, lsr #4
+	addhs	ip, ip, #4
 
-       cmp     yl, #(1 << 2)
-       addhi   ip, ip, #3
-       addls   ip, ip, yl, lsr #1
+	cmp	yl, #(1 << 2)
+	addhi	ip, ip, #3
+	addls	ip, ip, yl, lsr #1
 
 #endif
 
-       mov     yh, xh, lsr ip
-       mov     yl, xl, lsr ip
-       rsb     ip, ip, #32
- ARM(  orr     yl, yl, xh, lsl ip      )
- THUMB(        lsl     xh, xh, ip              )
- THUMB(        orr     yl, yl, xh              )
-       mov     xh, xl, lsl ip
-       mov     xh, xh, lsr ip
-       mov     pc, lr
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
 
-       @ eq -> division by 1: obvious enough...
-9:     moveq   yl, xl
-       moveq   yh, xh
-       moveq   xh, #0
-       moveq   pc, lr
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
 UNWIND(.fnend)
 
 UNWIND(.fnstart)
 UNWIND(.pad #4)
 UNWIND(.save {lr})
 Ldiv0_64:
-       @ Division by 0:
-       str     lr, [sp, #-8]!
-       bl      __div0
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
 
-       @ as wrong as it could be...
-       mov     yl, #0
-       mov     yh, #0
-       mov     xh, #0
-       ldr     pc, [sp], #8
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
 
 UNWIND(.fnend)
 ENDPROC(__do_div64)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/findbit.S
--- a/xen/arch/arm/lib/findbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/findbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -24,20 +24,20 @@
  * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
  */
 ENTRY(_find_first_zero_bit_le)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
 1:
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eors    r3, r3, #0xff           @ invert bits
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_zero_bit_le)
 
 /*
@@ -45,19 +45,19 @@ ENDPROC(_find_first_zero_bit_le)
  * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
  */
 ENTRY(_find_next_zero_bit_le)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eor     r3, r3, #0xff           @ now looking for a 1 bit
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_zero_bit_le)
 
 /*
@@ -65,20 +65,20 @@ ENDPROC(_find_next_zero_bit_le)
  * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
  */
 ENTRY(_find_first_bit_le)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
 1:
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_bit_le)
 
 /*
@@ -86,87 +86,87 @@ ENDPROC(_find_first_bit_le)
  * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
  */
 ENTRY(_find_next_bit_le)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_bit_le)
 
 #ifdef __ARMEB__
 
 ENTRY(_find_first_zero_bit_be)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
-1:             eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eors    r3, r3, #0xff           @ invert bits
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_zero_bit_be)
 
 ENTRY(_find_next_zero_bit_be)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
-               eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eor     r3, r3, #0xff           @ now looking for a 1 bit
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_zero_bit_be)
 
 ENTRY(_find_first_bit_be)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
-1:             eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_bit_be)
 
 ENTRY(_find_next_bit_be)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
-               eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_bit_be)
 
 #endif
@@ -176,23 +176,23 @@ ENDPROC(_find_next_bit_be)
  */
 .L_found:
 #if __LINUX_ARM_ARCH__ >= 5
-               rsb     r0, r3, #0
-               and     r3, r3, r0
-               clz     r3, r3
-               rsb     r3, r3, #31
-               add     r0, r2, r3
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
 #else
-               tst     r3, #0x0f
-               addeq   r2, r2, #4
-               movne   r3, r3, lsl #4
-               tst     r3, #0x30
-               addeq   r2, r2, #2
-               movne   r3, r3, lsl #2
-               tst     r3, #0x40
-               addeq   r2, r2, #1
-               mov     r0, r2
+		tst	r3, #0x0f
+		addeq	r2, r2, #4
+		movne	r3, r3, lsl #4
+		tst	r3, #0x30
+		addeq	r2, r2, #2
+		movne	r3, r3, lsl #2
+		tst	r3, #0x40
+		addeq	r2, r2, #1
+		mov	r0, r2
 #endif
-               cmp     r1, r0                  @ Clamp to maxbit
-               movlo   r0, r1
-               mov     pc, lr
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/lib1funcs.S
--- a/xen/arch/arm/lib/lib1funcs.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/lib1funcs.S	Mon Feb 13 17:26:08 2012 +0000
@@ -40,64 +40,64 @@ Boston, MA 02111-1307, USA.  */
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     \curbit, \divisor
-       clz     \result, \dividend
-       sub     \result, \curbit, \result
-       mov     \curbit, #1
-       mov     \divisor, \divisor, lsl \result
-       mov     \curbit, \curbit, lsl \result
-       mov     \result, #0
-
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
 #else
 
-       @ Initially shift the divisor left 3 bits if possible,
-       @ set curbit accordingly.  This allows for curbit to be located
-       @ at the left end of each 4 bit nibbles in the division loop
-       @ to save one loop in most cases.
-       tst     \divisor, #0xe0000000
-       moveq   \divisor, \divisor, lsl #3
-       moveq   \curbit, #8
-       movne   \curbit, #1
+	@ Initially shift the divisor left 3 bits if possible,
+	@ set curbit accordingly.  This allows for curbit to be located
+	@ at the left end of each 4 bit nibbles in the division loop
+	@ to save one loop in most cases.
+	tst	\divisor, #0xe0000000
+	moveq	\divisor, \divisor, lsl #3
+	moveq	\curbit, #8
+	movne	\curbit, #1
 
-       @ Unless the divisor is very big, shift it up in multiples of
-       @ four bits, since this is the amount of unwinding in the main
-       @ division loop.  Continue shifting until the divisor is
-       @ larger than the dividend.
-1:     cmp     \divisor, #0x10000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #4
-       movlo   \curbit, \curbit, lsl #4
-       blo     1b
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	movlo	\curbit, \curbit, lsl #4
+	blo	1b
 
-       @ For very big divisors, we must shift it a bit at a time, or
-       @ we will be in danger of overflowing.
-1:     cmp     \divisor, #0x80000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #1
-       movlo   \curbit, \curbit, lsl #1
-       blo     1b
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	movlo	\curbit, \curbit, lsl #1
+	blo	1b
 
-       mov     \result, #0
+	mov	\result, #0
 
 #endif
 
-       @ Division loop
-1:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       orrhs   \result,   \result,   \curbit
-       cmp     \dividend, \divisor,  lsr #1
-       subhs   \dividend, \dividend, \divisor, lsr #1
-       orrhs   \result,   \result,   \curbit,  lsr #1
-       cmp     \dividend, \divisor,  lsr #2
-       subhs   \dividend, \dividend, \divisor, lsr #2
-       orrhs   \result,   \result,   \curbit,  lsr #2
-       cmp     \dividend, \divisor,  lsr #3
-       subhs   \dividend, \dividend, \divisor, lsr #3
-       orrhs   \result,   \result,   \curbit,  lsr #3
-       cmp     \dividend, #0                   @ Early termination?
-       movnes  \curbit,   \curbit,  lsr #4     @ No, any more bits to do?
-       movne   \divisor,  \divisor, lsr #4
-       bne     1b
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
 
 .endm
 
@@ -106,27 +106,27 @@ 1:     cmp     \dividend, \divisor
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     \order, \divisor
-       rsb     \order, \order, #31
+	clz	\order, \divisor
+	rsb	\order, \order, #31
 
 #else
 
-       cmp     \divisor, #(1 << 16)
-       movhs   \divisor, \divisor, lsr #16
-       movhs   \order, #16
-       movlo   \order, #0
+	cmp	\divisor, #(1 << 16)
+	movhs	\divisor, \divisor, lsr #16
+	movhs	\order, #16
+	movlo	\order, #0
 
-       cmp     \divisor, #(1 << 8)
-       movhs   \divisor, \divisor, lsr #8
-       addhs   \order, \order, #8
+	cmp	\divisor, #(1 << 8)
+	movhs	\divisor, \divisor, lsr #8
+	addhs	\order, \order, #8
 
-       cmp     \divisor, #(1 << 4)
-       movhs   \divisor, \divisor, lsr #4
-       addhs   \order, \order, #4
+	cmp	\divisor, #(1 << 4)
+	movhs	\divisor, \divisor, lsr #4
+	addhs	\order, \order, #4
 
-       cmp     \divisor, #(1 << 2)
-       addhi   \order, \order, #3
-       addls   \order, \order, \divisor, lsr #1
+	cmp	\divisor, #(1 << 2)
+	addhi	\order, \order, #3
+	addls	\order, \order, \divisor, lsr #1
 
 #endif
 
@@ -137,69 +137,69 @@ 1:     cmp     \dividend, \divisor
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     \order, \divisor
-       clz     \spare, \dividend
-       sub     \order, \order, \spare
-       mov     \divisor, \divisor, lsl \order
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
 
 #else
 
-       mov     \order, #0
+	mov	\order, #0
 
-       @ Unless the divisor is very big, shift it up in multiples of
-       @ four bits, since this is the amount of unwinding in the main
-       @ division loop.  Continue shifting until the divisor is
-       @ larger than the dividend.
-1:     cmp     \divisor, #0x10000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #4
-       addlo   \order, \order, #4
-       blo     1b
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	addlo	\order, \order, #4
+	blo	1b
 
-       @ For very big divisors, we must shift it a bit at a time, or
-       @ we will be in danger of overflowing.
-1:     cmp     \divisor, #0x80000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #1
-       addlo   \order, \order, #1
-       blo     1b
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	addlo	\order, \order, #1
+	blo	1b
 
 #endif
 
-       @ Perform all needed substractions to keep only the reminder.
-       @ Do comparisons in batch of 4 first.
-       subs    \order, \order, #3              @ yes, 3 is intended here
-       blt     2f
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
 
-1:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       cmp     \dividend, \divisor,  lsr #1
-       subhs   \dividend, \dividend, \divisor, lsr #1
-       cmp     \dividend, \divisor,  lsr #2
-       subhs   \dividend, \dividend, \divisor, lsr #2
-       cmp     \dividend, \divisor,  lsr #3
-       subhs   \dividend, \dividend, \divisor, lsr #3
-       cmp     \dividend, #1
-       mov     \divisor, \divisor, lsr #4
-       subges  \order, \order, #4
-       bge     1b
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
 
-       tst     \order, #3
-       teqne   \dividend, #0
-       beq     5f
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
 
-       @ Either 1, 2 or 3 comparison/substractions are left.
-2:     cmn     \order, #2
-       blt     4f
-       beq     3f
-       cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       mov     \divisor,  \divisor,  lsr #1
-3:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       mov     \divisor,  \divisor,  lsr #1
-4:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
 5:
 .endm
 
@@ -208,27 +208,27 @@ ENTRY(__udivsi3)
 ENTRY(__aeabi_uidiv)
 UNWIND(.fnstart)
 
-       subs    r2, r1, #1
-       moveq   pc, lr
-       bcc     Ldiv0
-       cmp     r0, r1
-       bls     11f
-       tst     r1, r2
-       beq     12f
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
 
-       ARM_DIV_BODY r0, r1, r2, r3
+	ARM_DIV_BODY r0, r1, r2, r3
 
-       mov     r0, r2
-       mov     pc, lr
+	mov	r0, r2
+	mov	pc, lr
 
-11:    moveq   r0, #1
-       movne   r0, #0
-       mov     pc, lr
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
 
-12:    ARM_DIV2_ORDER r1, r2
+12:	ARM_DIV2_ORDER r1, r2
 
-       mov     r0, r0, lsr r2
-       mov     pc, lr
+	mov	r0, r0, lsr r2
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__udivsi3)
@@ -237,17 +237,17 @@ ENDPROC(__aeabi_uidiv)
 ENTRY(__umodsi3)
 UNWIND(.fnstart)
 
-       subs    r2, r1, #1                      @ compare divisor with 1
-       bcc     Ldiv0
-       cmpne   r0, r1                          @ compare dividend with divisor
-       moveq   r0, #0
-       tsthi   r1, r2                          @ see if divisor is power of 2
-       andeq   r0, r0, r2
-       movls   pc, lr
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
 
-       ARM_MOD_BODY r0, r1, r2, r3
+	ARM_MOD_BODY r0, r1, r2, r3
 
-       mov     pc, lr
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__umodsi3)
@@ -256,40 +256,40 @@ ENTRY(__divsi3)
 ENTRY(__aeabi_idiv)
 UNWIND(.fnstart)
 
-       cmp     r1, #0
-       eor     ip, r0, r1                      @ save the sign of the result.
-       beq     Ldiv0
-       rsbmi   r1, r1, #0                      @ loops below use unsigned.
-       subs    r2, r1, #1                      @ division by 1 or -1 ?
-       beq     10f
-       movs    r3, r0
-       rsbmi   r3, r0, #0                      @ positive dividend value
-       cmp     r3, r1
-       bls     11f
-       tst     r1, r2                          @ divisor is power of 2 ?
-       beq     12f
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
 
-       ARM_DIV_BODY r3, r1, r0, r2
+	ARM_DIV_BODY r3, r1, r0, r2
 
-       cmp     ip, #0
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
-10:    teq     ip, r0                          @ same sign ?
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
-11:    movlo   r0, #0
-       moveq   r0, ip, asr #31
-       orreq   r0, r0, #1
-       mov     pc, lr
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
 
-12:    ARM_DIV2_ORDER r1, r2
+12:	ARM_DIV2_ORDER r1, r2
 
-       cmp     ip, #0
-       mov     r0, r3, lsr r2
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__divsi3)
@@ -298,23 +298,23 @@ ENDPROC(__aeabi_idiv)
 ENTRY(__modsi3)
 UNWIND(.fnstart)
 
-       cmp     r1, #0
-       beq     Ldiv0
-       rsbmi   r1, r1, #0                      @ loops below use unsigned.
-       movs    ip, r0                          @ preserve sign of dividend
-       rsbmi   r0, r0, #0                      @ if negative make positive
-       subs    r2, r1, #1                      @ compare divisor with 1
-       cmpne   r0, r1                          @ compare dividend with divisor
-       moveq   r0, #0
-       tsthi   r1, r2                          @ see if divisor is power of 2
-       andeq   r0, r0, r2
-       bls     10f
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
 
-       ARM_MOD_BODY r0, r1, r2, r3
+	ARM_MOD_BODY r0, r1, r2, r3
 
-10:    cmp     ip, #0
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__modsi3)
@@ -323,56 +323,56 @@ ENDPROC(__modsi3)
 
 ENTRY(__aeabi_uidivmod)
 UNWIND(.fnstart)
-UNWIND(.save {r0, r1, ip, lr}  )
+UNWIND(.save {r0, r1, ip, lr}	)
 
-       stmfd   sp!, {r0, r1, ip, lr}
-       bl      __aeabi_uidiv
-       ldmfd   sp!, {r1, r2, ip, lr}
-       mul     r3, r0, r2
-       sub     r1, r1, r3
-       mov     pc, lr
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__aeabi_uidivmod)
 
 ENTRY(__aeabi_idivmod)
 UNWIND(.fnstart)
-UNWIND(.save {r0, r1, ip, lr}  )
-       stmfd   sp!, {r0, r1, ip, lr}
-       bl      __aeabi_idiv
-       ldmfd   sp!, {r1, r2, ip, lr}
-       mul     r3, r0, r2
-       sub     r1, r1, r3
-       mov     pc, lr
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__aeabi_idivmod)
 
 ENTRY(__aeabi_uldivmod)
 UNWIND(.fnstart)
-UNWIND(.save {lr}      )
-       sub sp, sp, #8
-       stmfd   sp!, {sp, lr}
-       bl __qdivrem
-       ldr lr, [sp, #4]
-       add sp, sp, #8
-       ldmfd sp!, {r2, r3}
-       mov     pc, lr
+UNWIND(.save {lr}	)
+	sub sp, sp, #8
+	stmfd   sp!, {sp, lr}
+	bl __qdivrem
+	ldr lr, [sp, #4]
+	add sp, sp, #8
+	ldmfd sp!, {r2, r3}
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__aeabi_uldivmod)
 
 ENTRY(__aeabi_ldivmod)
 UNWIND(.fnstart)
-UNWIND(.save {lr}      )
-       sub sp, sp, #16
-       stmfd   sp!, {sp, lr}
-       bl __ldivmod_helper
-       ldr lr, [sp, #4]
-       add sp, sp, #16
-       ldmfd   sp!, {r2, r3}
-       mov     pc, lr
-
+UNWIND(.save {lr}	)
+	sub sp, sp, #16
+	stmfd   sp!, {sp, lr}
+	bl __ldivmod_helper
+	ldr lr, [sp, #4]
+	add sp, sp, #16
+	ldmfd	sp!, {r2, r3}
+	mov	pc, lr
+	
 UNWIND(.fnend)
 ENDPROC(__aeabi_ldivmod)
 #endif
@@ -381,9 +381,9 @@ Ldiv0:
 UNWIND(.fnstart)
 UNWIND(.pad #4)
 UNWIND(.save {lr})
-       str     lr, [sp, #-8]!
-       bl      __div0
-       mov     r0, #0                  @ About as wrong as it could be.
-       ldr     pc, [sp], #8
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
 UNWIND(.fnend)
 ENDPROC(Ldiv0)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memcpy.S
--- a/xen/arch/arm/lib/memcpy.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memcpy.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,9 +1,9 @@
 /*
  *  linux/arch/arm/lib/memcpy.S
  *
- *  Author:    Nicolas Pitre
- *  Created:   Sep 28, 2005
- *  Copyright: MontaVista Software, Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
  *
  *  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
@@ -13,46 +13,46 @@
 #include <xen/config.h>
 #include "assembler.h"
 
-#define LDR1W_SHIFT    0
-#define STR1W_SHIFT    0
+#define LDR1W_SHIFT	0
+#define STR1W_SHIFT	0
 
-       .macro ldr1w ptr reg abort
-       W(ldr) \reg, [\ptr], #4
-       .endm
+	.macro ldr1w ptr reg abort
+	W(ldr) \reg, [\ptr], #4
+	.endm
 
-       .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
-       ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
-       .endm
+	.macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+	ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+	.endm
 
-       .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
-       ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
-       .endm
+	.macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+	ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+	.endm
 
-       .macro ldr1b ptr reg cond=al abort
-       ldr\cond\()b \reg, [\ptr], #1
-       .endm
+	.macro ldr1b ptr reg cond=al abort
+	ldr\cond\()b \reg, [\ptr], #1
+	.endm
 
-       .macro str1w ptr reg abort
-       W(str) \reg, [\ptr], #4
-       .endm
+	.macro str1w ptr reg abort
+	W(str) \reg, [\ptr], #4
+	.endm
 
-       .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
-       stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
-       .endm
+	.macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+	stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+	.endm
 
-       .macro str1b ptr reg cond=al abort
-       str\cond\()b \reg, [\ptr], #1
-       .endm
+	.macro str1b ptr reg cond=al abort
+	str\cond\()b \reg, [\ptr], #1
+	.endm
 
-       .macro enter reg1 reg2
-       stmdb sp!, {r0, \reg1, \reg2}
-       .endm
+	.macro enter reg1 reg2
+	stmdb sp!, {r0, \reg1, \reg2}
+	.endm
 
-       .macro exit reg1 reg2
-       ldmfd sp!, {r0, \reg1, \reg2}
-       .endm
+	.macro exit reg1 reg2
+	ldmfd sp!, {r0, \reg1, \reg2}
+	.endm
 
-       .text
+	.text
 
 /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memmove.S
--- a/xen/arch/arm/lib/memmove.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memmove.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,9 +1,9 @@
 /*
  *  linux/arch/arm/lib/memmove.S
  *
- *  Author:    Nicolas Pitre
- *  Created:   Sep 28, 2005
- *  Copyright: (C) MontaVista Software Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
  *
  *  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
@@ -14,7 +14,7 @@
 
 #include "assembler.h"
 
-               .text
+		.text
 
 /*
  * Prototype: void *memmove(void *dest, const void *src, size_t n);
@@ -29,172 +29,172 @@
 
 ENTRY(memmove)
 
-               subs    ip, r0, r1
-               cmphi   r2, ip
-               bls     memcpy
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
 
-               stmfd   sp!, {r0, r4, lr}
-               add     r1, r1, r2
-               add     r0, r0, r2
-               subs    r2, r2, #4
-               blt     8f
-               ands    ip, r0, #3
-       PLD(    pld     [r1, #-4]               )
-               bne     9f
-               ands    ip, r1, #3
-               bne     10f
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
 
-1:             subs    r2, r2, #(28)
-               stmfd   sp!, {r5 - r8}
-               blt     5f
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  sbcnes  r4, ip, r2              )  @ C is always set here
-       CALGN(  bcs     2f                      )
-       CALGN(  adr     r4, 6f                  )
-       CALGN(  subs    r2, r2, ip              )  @ C is set here
-       CALGN(  rsb     ip, ip, #32             )
-       CALGN(  add     pc, r4, ip              )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
 
-       PLD(    pld     [r1, #-4]               )
-2:     PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #-32]              )
-       PLD(    blt     4f                      )
-       PLD(    pld     [r1, #-64]              )
-       PLD(    pld     [r1, #-96]              )
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
 
-3:     PLD(    pld     [r1, #-128]             )
-4:             ldmdb   r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
-               subs    r2, r2, #32
-               stmdb   r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
-               bge     3b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     4b                      )
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
 
-5:             ands    ip, r2, #28
-               rsb     ip, ip, #32
-               addne   pc, pc, ip              @ C is always clear here
-               b       7f
-6:             W(nop)
-               W(ldr)  r3, [r1, #-4]!
-               W(ldr)  r4, [r1, #-4]!
-               W(ldr)  r5, [r1, #-4]!
-               W(ldr)  r6, [r1, #-4]!
-               W(ldr)  r7, [r1, #-4]!
-               W(ldr)  r8, [r1, #-4]!
-               W(ldr)  lr, [r1, #-4]!
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
 
-               add     pc, pc, ip
-               nop
-               W(nop)
-               W(str)  r3, [r0, #-4]!
-               W(str)  r4, [r0, #-4]!
-               W(str)  r5, [r0, #-4]!
-               W(str)  r6, [r0, #-4]!
-               W(str)  r7, [r0, #-4]!
-               W(str)  r8, [r0, #-4]!
-               W(str)  lr, [r0, #-4]!
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
 
-       CALGN(  bcs     2b                      )
+	CALGN(	bcs	2b			)
 
-7:             ldmfd   sp!, {r5 - r8}
+7:		ldmfd	sp!, {r5 - r8}
 
-8:             movs    r2, r2, lsl #31
-               ldrneb  r3, [r1, #-1]!
-               ldrcsb  r4, [r1, #-1]!
-               ldrcsb  ip, [r1, #-1]
-               strneb  r3, [r0, #-1]!
-               strcsb  r4, [r0, #-1]!
-               strcsb  ip, [r0, #-1]
-               ldmfd   sp!, {r0, r4, pc}
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
 
-9:             cmp     ip, #2
-               ldrgtb  r3, [r1, #-1]!
-               ldrgeb  r4, [r1, #-1]!
-               ldrb    lr, [r1, #-1]!
-               strgtb  r3, [r0, #-1]!
-               strgeb  r4, [r0, #-1]!
-               subs    r2, r2, ip
-               strb    lr, [r0, #-1]!
-               blt     8b
-               ands    ip, r1, #3
-               beq     1b
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
 
-10:            bic     r1, r1, #3
-               cmp     ip, #2
-               ldr     r3, [r1, #0]
-               beq     17f
-               blt     18f
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
 
 
-               .macro  backward_copy_shift push pull
+		.macro	backward_copy_shift push pull
 
-               subs    r2, r2, #28
-               blt     14f
+		subs	r2, r2, #28
+		blt	14f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  sbcnes  r4, ip, r2              )  @ C is always set here
-       CALGN(  subcc   r2, r2, ip              )
-       CALGN(  bcc     15f                     )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
 
-11:            stmfd   sp!, {r5 - r9}
+11:		stmfd	sp!, {r5 - r9}
 
-       PLD(    pld     [r1, #-4]               )
-       PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #-32]              )
-       PLD(    blt     13f                     )
-       PLD(    pld     [r1, #-64]              )
-       PLD(    pld     [r1, #-96]              )
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
 
-12:    PLD(    pld     [r1, #-128]             )
-13:            ldmdb   r1!, {r7, r8, r9, ip}
-               mov     lr, r3, push #\push
-               subs    r2, r2, #32
-               ldmdb   r1!, {r3, r4, r5, r6}
-               orr     lr, lr, ip, pull #\pull
-               mov     ip, ip, push #\push
-               orr     ip, ip, r9, pull #\pull
-               mov     r9, r9, push #\push
-               orr     r9, r9, r8, pull #\pull
-               mov     r8, r8, push #\push
-               orr     r8, r8, r7, pull #\pull
-               mov     r7, r7, push #\push
-               orr     r7, r7, r6, pull #\pull
-               mov     r6, r6, push #\push
-               orr     r6, r6, r5, pull #\pull
-               mov     r5, r5, push #\push
-               orr     r5, r5, r4, pull #\pull
-               mov     r4, r4, push #\push
-               orr     r4, r4, r3, pull #\pull
-               stmdb   r0!, {r4 - r9, ip, lr}
-               bge     12b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     13b                     )
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
 
-               ldmfd   sp!, {r5 - r9}
+		ldmfd	sp!, {r5 - r9}
 
-14:            ands    ip, r2, #28
-               beq     16f
+14:		ands	ip, r2, #28
+		beq	16f
 
-15:            mov     lr, r3, push #\push
-               ldr     r3, [r1, #-4]!
-               subs    ip, ip, #4
-               orr     lr, lr, r3, pull #\pull
-               str     lr, [r0, #-4]!
-               bgt     15b
-       CALGN(  cmp     r2, #0                  )
-       CALGN(  bge     11b                     )
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
 
-16:            add     r1, r1, #(\pull / 8)
-               b       8b
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
 
-               .endm
+		.endm
 
 
-               backward_copy_shift     push=8  pull=24
+		backward_copy_shift	push=8	pull=24
 
-17:            backward_copy_shift     push=16 pull=16
+17:		backward_copy_shift	push=16	pull=16
 
-18:            backward_copy_shift     push=24 pull=8
+18:		backward_copy_shift	push=24	pull=8
 
 ENDPROC(memmove)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memset.S
--- a/xen/arch/arm/lib/memset.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memset.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,33 +14,33 @@
 
 #include "assembler.h"
 
-       .text
-       .align  5
-       .word   0
+	.text
+	.align	5
+	.word	0
 
-1:     subs    r2, r2, #4              @ 1 do we have enough
-       blt     5f                      @ 1 bytes to align with?
-       cmp     r3, #2                  @ 1
-       strltb  r1, [r0], #1            @ 1
-       strleb  r1, [r0], #1            @ 1
-       strb    r1, [r0], #1            @ 1
-       add     r2, r2, r3              @ 1 (r2 = r2 - (4 - r3))
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
 /*
  * The pointer is now aligned and the length is adjusted.  Try doing the
  * memset again.
  */
 
 ENTRY(memset)
-       ands    r3, r0, #3              @ 1 unaligned?
-       bne     1b                      @ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
 /*
  * we know that the pointer in r0 is aligned to a word boundary.
  */
-       orr     r1, r1, r1, lsl #8
-       orr     r1, r1, r1, lsl #16
-       mov     r3, r1
-       cmp     r2, #16
-       blt     4f
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
 
 #if ! CALGN(1)+0
 
@@ -48,26 +48,26 @@ ENTRY(memset)
  * We need an extra register for this loop - save the return address and
  * use the LR
  */
-       str     lr, [sp, #-4]!
-       mov     ip, r1
-       mov     lr, r1
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
 
-2:     subs    r2, r2, #64
-       stmgeia r0!, {r1, r3, ip, lr}   @ 64 bytes at a time.
-       stmgeia r0!, {r1, r3, ip, lr}
-       stmgeia r0!, {r1, r3, ip, lr}
-       stmgeia r0!, {r1, r3, ip, lr}
-       bgt     2b
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
 /*
  * No need to correct the count; we're only testing bits from now on
  */
-       tst     r2, #32
-       stmneia r0!, {r1, r3, ip, lr}
-       stmneia r0!, {r1, r3, ip, lr}
-       tst     r2, #16
-       stmneia r0!, {r1, r3, ip, lr}
-       ldr     lr, [sp], #4
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
 
 #else
 
@@ -76,54 +76,54 @@ 2:     subs    r2, r2, #64
  * whole cache lines at once.
  */
 
-       stmfd   sp!, {r4-r7, lr}
-       mov     r4, r1
-       mov     r5, r1
-       mov     r6, r1
-       mov     r7, r1
-       mov     ip, r1
-       mov     lr, r1
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
 
-       cmp     r2, #96
-       tstgt   r0, #31
-       ble     3f
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
 
-       and     ip, r0, #31
-       rsb     ip, ip, #32
-       sub     r2, r2, ip
-       movs    ip, ip, lsl #(32 - 4)
-       stmcsia r0!, {r4, r5, r6, r7}
-       stmmiia r0!, {r4, r5}
-       tst     ip, #(1 << 30)
-       mov     ip, r1
-       strne   r1, [r0], #4
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
 
-3:     subs    r2, r2, #64
-       stmgeia r0!, {r1, r3-r7, ip, lr}
-       stmgeia r0!, {r1, r3-r7, ip, lr}
-       bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
 
-       tst     r2, #32
-       stmneia r0!, {r1, r3-r7, ip, lr}
-       tst     r2, #16
-       stmneia r0!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
 
 #endif
 
-4:     tst     r2, #8
-       stmneia r0!, {r1, r3}
-       tst     r2, #4
-       strne   r1, [r0], #4
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
 /*
  * When we get here, we've got less than 4 bytes to zero.  We
  * may have an unaligned pointer as well.
  */
-5:     tst     r2, #2
-       strneb  r1, [r0], #1
-       strneb  r1, [r0], #1
-       tst     r2, #1
-       strneb  r1, [r0], #1
-       mov     pc, lr
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
 ENDPROC(memset)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memzero.S
--- a/xen/arch/arm/lib/memzero.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memzero.S	Mon Feb 13 17:26:08 2012 +0000
@@ -12,35 +12,35 @@
 
 #include "assembler.h"
 
-       .text
-       .align  5
-       .word   0
+	.text
+	.align	5
+	.word	0
 /*
  * Align the pointer in r0.  r3 contains the number of bytes that we are
  * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
  * don't bother; we use byte stores instead.
  */
-1:     subs    r1, r1, #4              @ 1 do we have enough
-       blt     5f                      @ 1 bytes to align with?
-       cmp     r3, #2                  @ 1
-       strltb  r2, [r0], #1            @ 1
-       strleb  r2, [r0], #1            @ 1
-       strb    r2, [r0], #1            @ 1
-       add     r1, r1, r3              @ 1 (r1 = r1 - (4 - r3))
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
 /*
  * The pointer is now aligned and the length is adjusted.  Try doing the
  * memzero again.
  */
 
 ENTRY(__memzero)
-       mov     r2, #0                  @ 1
-       ands    r3, r0, #3              @ 1 unaligned?
-       bne     1b                      @ 1
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
 /*
  * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
  */
-       cmp     r1, #16                 @ 1 we can skip this chunk if we
-       blt     4f                      @ 1 have < 16 bytes
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
 
 #if ! CALGN(1)+0
 
@@ -48,26 +48,26 @@ ENTRY(__memzero)
  * We need an extra register for this loop - save the return address and
  * use the LR
  */
-       str     lr, [sp, #-4]!          @ 1
-       mov     ip, r2                  @ 1
-       mov     lr, r2                  @ 1
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
 
-3:     subs    r1, r1, #64             @ 1 write 32 bytes out per loop
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       bgt     3b                      @ 1
-       ldmeqfd sp!, {pc}               @ 1/2 quick exit
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
 /*
  * No need to correct the count; we're only testing bits from now on
  */
-       tst     r1, #32                 @ 1
-       stmneia r0!, {r2, r3, ip, lr}   @ 4
-       stmneia r0!, {r2, r3, ip, lr}   @ 4
-       tst     r1, #16                 @ 1 16 bytes or more?
-       stmneia r0!, {r2, r3, ip, lr}   @ 4
-       ldr     lr, [sp], #4            @ 1
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
 
 #else
 
@@ -76,52 +76,52 @@ 3:     subs    r1, r1, #64             @
  * whole cache lines at once.
  */
 
-       stmfd   sp!, {r4-r7, lr}
-       mov     r4, r2
-       mov     r5, r2
-       mov     r6, r2
-       mov     r7, r2
-       mov     ip, r2
-       mov     lr, r2
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
 
-       cmp     r1, #96
-       andgts  ip, r0, #31
-       ble     3f
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
 
-       rsb     ip, ip, #32
-       sub     r1, r1, ip
-       movs    ip, ip, lsl #(32 - 4)
-       stmcsia r0!, {r4, r5, r6, r7}
-       stmmiia r0!, {r4, r5}
-       movs    ip, ip, lsl #2
-       strcs   r2, [r0], #4
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
 
-3:     subs    r1, r1, #64
-       stmgeia r0!, {r2-r7, ip, lr}
-       stmgeia r0!, {r2-r7, ip, lr}
-       bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
 
-       tst     r1, #32
-       stmneia r0!, {r2-r7, ip, lr}
-       tst     r1, #16
-       stmneia r0!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
 
 #endif
 
-4:     tst     r1, #8                  @ 1 8 bytes or more?
-       stmneia r0!, {r2, r3}           @ 2
-       tst     r1, #4                  @ 1 4 bytes or more?
-       strne   r2, [r0], #4            @ 1
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
 /*
  * When we get here, we've got less than 4 bytes to zero.  We
  * may have an unaligned pointer as well.
  */
-5:     tst     r1, #2                  @ 1 2 bytes or more?
-       strneb  r2, [r0], #1            @ 1
-       strneb  r2, [r0], #1            @ 1
-       tst     r1, #1                  @ 1 a byte left over
-       strneb  r2, [r0], #1            @ 1
-       mov     pc, lr                  @ 1
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
 ENDPROC(__memzero)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/setbit.S
--- a/xen/arch/arm/lib/setbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/setbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -11,8 +11,8 @@
 
 #include "assembler.h"
 #include "bitops.h"
-       .text
+	.text
 
 ENTRY(_set_bit)
-       bitop   orr
+	bitop	orr
 ENDPROC(_set_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/testchangebit.S
--- a/xen/arch/arm/lib/testchangebit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/testchangebit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_test_and_change_bit)
-       testop  eor, str
+	testop	eor, str
 ENDPROC(_test_and_change_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/testclearbit.S
--- a/xen/arch/arm/lib/testclearbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/testclearbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_test_and_clear_bit)
-       testop  bicne, strne
+	testop	bicne, strne
 ENDPROC(_test_and_clear_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/testsetbit.S
--- a/xen/arch/arm/lib/testsetbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/testsetbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_test_and_set_bit)
-       testop  orreq, streq
+	testop	orreq, streq
 ENDPROC(_test_and_set_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/include/asm-arm/bitops.h
--- a/xen/include/asm-arm/bitops.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/include/asm-arm/bitops.h	Mon Feb 13 17:26:08 2012 +0000
@@ -115,19 +115,19 @@ extern int _find_next_bit_be(const unsig
 /*
  * These are the little endian, atomic definitions.
  */
-#define find_first_zero_bit(p,sz)      _find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off)   _find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz)           _find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off)                _find_next_bit_le(p,sz,off)
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
 
 #else
 /*
  * These are the big endian, atomic definitions.
  */
-#define find_first_zero_bit(p,sz)      _find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off)   _find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz)           _find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off)                _find_next_bit_be(p,sz,off)
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
 
 #endif
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/include/asm-arm/div64.h
--- a/xen/include/asm-arm/div64.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/include/asm-arm/div64.h	Mon Feb 13 17:26:08 2012 +0000
@@ -10,9 +10,9 @@
  *
  * uint32_t do_div(uint64_t *n, uint32_t base)
  * {
- *     uint32_t remainder = *n % base;
- *     *n = *n / base;
- *     return remainder;
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
  * }
  *
  * In other words, a 64-bit dividend with a 32-bit divisor producing
@@ -29,22 +29,22 @@
 #define __xh "r1"
 #endif
 
-#define __do_div_asm(n, base)                                  \
-({                                                             \
-       register unsigned int __base      asm("r4") = base;     \
-       register unsigned long long __n   asm("r0") = n;        \
-       register unsigned long long __res asm("r2");            \
-       register unsigned int __rem       asm(__xh);            \
-       asm(    __asmeq("%0", __xh)                             \
-               __asmeq("%1", "r2")                             \
-               __asmeq("%2", "r0")                             \
-               __asmeq("%3", "r4")                             \
-               "bl     __do_div64"                             \
-               : "=r" (__rem), "=r" (__res)                    \
-               : "r" (__n), "r" (__base)                       \
-               : "ip", "lr", "cc");                            \
-       n = __res;                                              \
-       __rem;                                                  \
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
 })
 
 #if __GNUC__ < 4
@@ -71,155 +71,155 @@
  * sufficiently recent to perform proper long long constant propagation.
  * (It is unfortunate that gcc doesn't perform all this internally.)
  */
-#define do_div(n, base)                                                        \
-({                                                                     \
-       unsigned int __r, __b = (base);                                 \
-       if (!__builtin_constant_p(__b) || __b == 0) {                   \
-               /* non-constant divisor (or zero): slow path */         \
-               __r = __do_div_asm(n, __b);                             \
-       } else if ((__b & (__b - 1)) == 0) {                            \
-               /* Trivial: __b is constant and a power of 2 */         \
-               /* gcc does the right thing with this code.  */         \
-               __r = n;                                                \
-               __r &= (__b - 1);                                       \
-               n /= __b;                                               \
-       } else {                                                        \
-               /* Multiply by inverse of __b: n/b = n*(p/b)/p       */ \
-               /* We rely on the fact that most of this code gets   */ \
-               /* optimized away at compile time due to constant    */ \
-               /* propagation and only a couple inline assembly     */ \
-               /* instructions should remain. Better avoid any      */ \
-               /* code construct that might prevent that.           */ \
-               unsigned long long __res, __x, __t, __m, __n = n;       \
-               unsigned int __c, __p, __z = 0;                         \
-               /* preserve low part of n for reminder computation */   \
-               __r = __n;                                              \
-               /* determine number of bits to represent __b */         \
-               __p = 1 << __div64_fls(__b);                            \
-               /* compute __m = ((__p << 64) + __b - 1) / __b */       \
-               __m = (~0ULL / __b) * __p;                              \
-               __m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;     \
-               /* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */ \
-               __x = ~0ULL / __b * __b - 1;                            \
-               __res = (__m & 0xffffffff) * (__x & 0xffffffff);        \
-               __res >>= 32;                                           \
-               __res += (__m & 0xffffffff) * (__x >> 32);              \
-               __t = __res;                                            \
-               __res += (__x & 0xffffffff) * (__m >> 32);              \
-               __t = (__res < __t) ? (1ULL << 32) : 0;                 \
-               __res = (__res >> 32) + __t;                            \
-               __res += (__m >> 32) * (__x >> 32);                     \
-               __res /= __p;                                           \
-               /* Now sanitize and optimize what we've got. */         \
-               if (~0ULL % (__b / (__b & -__b)) == 0) {                \
-                       /* those cases can be simplified with: */       \
-                       __n /= (__b & -__b);                            \
-                       __m = ~0ULL / (__b / (__b & -__b));             \
-                       __p = 1;                                        \
-                       __c = 1;                                        \
-               } else if (__res != __x / __b) {                        \
-                       /* We can't get away without a correction    */ \
-                       /* to compensate for bit truncation errors.  */ \
-                       /* To avoid it we'd need an additional bit   */ \
-                       /* to represent __m which would overflow it. */ \
-                       /* Instead we do m=p/b and n/b=(n*m+m)/p.    */ \
-                       __c = 1;                                        \
-                       /* Compute __m = (__p << 64) / __b */           \
-                       __m = (~0ULL / __b) * __p;                      \
-                       __m += ((~0ULL % __b + 1) * __p) / __b;         \
-               } else {                                                \
-                       /* Reduce __m/__p, and try to clear bit 31   */ \
-                       /* of __m when possible otherwise that'll    */ \
-                       /* need extra overflow handling later.       */ \
-                       unsigned int __bits = -(__m & -__m);            \
-                       __bits |= __m >> 32;                            \
-                       __bits = (~__bits) << 1;                        \
-                       /* If __bits == 0 then setting bit 31 is     */ \
-                       /* unavoidable.  Simply apply the maximum    */ \
-                       /* possible reduction in that case.          */ \
-                       /* Otherwise the MSB of __bits indicates the */ \
-                       /* best reduction we should apply.           */ \
-                       if (!__bits) {                                  \
-                               __p /= (__m & -__m);                    \
-                               __m /= (__m & -__m);                    \
-                       } else {                                        \
-                               __p >>= __div64_fls(__bits);            \
-                               __m >>= __div64_fls(__bits);            \
-                       }                                               \
-                       /* No correction needed. */                     \
-                       __c = 0;                                        \
-               }                                                       \
-               /* Now we have a combination of 2 conditions:        */ \
-               /* 1) whether or not we need a correction (__c), and */ \
-               /* 2) whether or not there might be an overflow in   */ \
-               /*    the cross product (__m & ((1<<63) | (1<<31)))  */ \
-               /* Select the best insn combination to perform the   */ \
-               /* actual __m * __n / (__p << 64) operation.         */ \
-               if (!__c) {                                             \
-                       asm (   "umull  %Q0, %R0, %1, %Q2\n\t"          \
-                               "mov    %Q0, #0"                        \
-                               : "=&r" (__res)                         \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               } else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {    \
-                       __res = __m;                                    \
-                       asm (   "umlal  %Q0, %R0, %Q1, %Q2\n\t"         \
-                               "mov    %Q0, #0"                        \
-                               : "+&r" (__res)                         \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               } else {                                                \
-                       asm (   "umull  %Q0, %R0, %Q1, %Q2\n\t"         \
-                               "cmn    %Q0, %Q1\n\t"                   \
-                               "adcs   %R0, %R0, %R1\n\t"              \
-                               "adc    %Q0, %3, #0"                    \
-                               : "=&r" (__res)                         \
-                               : "r" (__m), "r" (__n), "r" (__z)       \
-                               : "cc" );                               \
-               }                                                       \
-               if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {           \
-                       asm (   "umlal  %R0, %Q0, %R1, %Q2\n\t"         \
-                               "umlal  %R0, %Q0, %Q1, %R2\n\t"         \
-                               "mov    %R0, #0\n\t"                    \
-                               "umlal  %Q0, %R0, %R1, %R2"             \
-                               : "+&r" (__res)                         \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               } else {                                                \
-                       asm (   "umlal  %R0, %Q0, %R2, %Q3\n\t"         \
-                               "umlal  %R0, %1, %Q2, %R3\n\t"          \
-                               "mov    %R0, #0\n\t"                    \
-                               "adds   %Q0, %1, %Q0\n\t"               \
-                               "adc    %R0, %R0, #0\n\t"               \
-                               "umlal  %Q0, %R0, %R2, %R3"             \
-                               : "+&r" (__res), "+&r" (__z)            \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               }                                                       \
-               __res /= __p;                                           \
-               /* The reminder can be computed with 32-bit regs     */ \
-               /* only, and gcc is good at that.                    */ \
-               {                                                       \
-                       unsigned int __res0 = __res;                    \
-                       unsigned int __b0 = __b;                        \
-                       __r -= __res0 * __b0;                           \
-               }                                                       \
-               /* BUG_ON(__r >= __b || __res * __b + __r != n); */     \
-               n = __res;                                              \
-       }                                                               \
-       __r;                                                            \
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
 })
 
 /* our own fls implementation to make sure constant propagation is fine */
-#define __div64_fls(bits)                                              \
-({                                                                     \
-       unsigned int __left = (bits), __nr = 0;                         \
-       if (__left & 0xffff0000) __nr += 16, __left >>= 16;             \
-       if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;             \
-       if (__left & 0x000000f0) __nr +=  4, __left >>=  4;             \
-       if (__left & 0x0000000c) __nr +=  2, __left >>=  2;             \
-       if (__left & 0x00000002) __nr +=  1;                            \
-       __nr;                                                           \
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
 })
 
 #endif
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/include/asm-arm/numa.h
--- a/xen/include/asm-arm/numa.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/include/asm-arm/numa.h	Mon Feb 13 17:26:08 2012 +0000
@@ -3,7 +3,7 @@
 
 /* Fake one node for now... */
 #define cpu_to_node(cpu) 0
-#define node_to_cpumask(node)  (cpu_online_map)
+#define node_to_cpumask(node)	(cpu_online_map)
 
 static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:04:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0G5-0003f2-B0; Mon, 13 Feb 2012 18:04:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rx0G2-0003e0-LG
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:04:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329156234!10489572!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20680 invoked from network); 13 Feb 2012 18:04:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181540398"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:03:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 13:03:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1DI3o2b025360;	Mon, 13 Feb 2012 10:03:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
Message-ID: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 13 Feb 2012 18:03:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: stefano.stabellini@citrix.com, tim@xen.org, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329153968 0
# Node ID 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
# Parent  7fd8f10cfd3eaf9f0982eb6fd49334a1e229ba98
arm: fixup hard tabs

Unfortunately the tool I was using to apply patches mangles hard tabs. This
patch corrects this in the effected files (which is fortunately only a subset
of .S or files imported from Linux)

"git diff" and "git diff -b" vs. Stefano's v6 branch now contain the same
output -- i.e. only the intervening development

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/dtb.S
--- a/xen/arch/arm/dtb.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/dtb.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,2 +1,2 @@
-        .section .dtb,#alloc
-        .incbin CONFIG_DTB_FILE
+	.section .dtb,#alloc
+	.incbin CONFIG_DTB_FILE
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/dummy.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,13 +1,13 @@
 /* Nothing is mapped at 1G, for the moment */
 #define DUMMY(x) \
-       .globl x; \
-x:     .word 0xe7f000f0
-/* x:  mov r0, #0x40000000 ; str r0, [r0]; b x */
+	.globl x; \
+x:	.word 0xe7f000f0
+/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
 
 #define  NOP(x) \
-       .globl x; \
-x:     mov pc, lr
-
+	.globl x; \
+x:	mov pc, lr
+	
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_do_domctl);
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/entry.S
--- a/xen/arch/arm/entry.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/entry.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,69 +1,69 @@
 #include <xen/config.h>
 #include <asm/asm_defns.h>
 
-#define SAVE_ONE_BANKED(reg)   mrs r11, reg; str r11, [sp, #UREGS_##reg]
-#define RESTORE_ONE_BANKED(reg)        ldr r11, [sp, #UREGS_##reg]; msr reg, r11
+#define SAVE_ONE_BANKED(reg)	mrs r11, reg; str r11, [sp, #UREGS_##reg]
+#define RESTORE_ONE_BANKED(reg)	ldr r11, [sp, #UREGS_##reg]; msr reg, r11
 
 #define SAVE_BANKED(mode) \
-       SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
+	SAVE_ONE_BANKED(SP_##mode) ; SAVE_ONE_BANKED(LR_##mode) ; SAVE_ONE_BANKED(SPSR_##mode)
 
 #define RESTORE_BANKED(mode) \
-       RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
+	RESTORE_ONE_BANKED(SP_##mode) ; RESTORE_ONE_BANKED(LR_##mode) ; RESTORE_ONE_BANKED(SPSR_##mode)
 
-#define SAVE_ALL                                                                                       \
-       sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */                                      \
-       push {r0-r12}; /* Save R0-R12 */                                                                \
-                                                                                                       \
-       mrs r11, ELR_hyp;               /* ELR_hyp is return address. */                                \
-       str r11, [sp, #UREGS_pc];                                                                       \
-                                                                                                       \
-       str lr, [sp, #UREGS_lr];                                                                        \
-                                                                                                       \
-       add r11, sp, #UREGS_kernel_sizeof+4;                                                            \
-       str r11, [sp, #UREGS_sp];                                                                       \
-                                                                                                       \
-       mrs r11, SPSR_hyp;                                                                              \
-       str r11, [sp, #UREGS_cpsr];                                                                     \
-       and r11, #PSR_MODE_MASK;                                                                        \
-       cmp r11, #PSR_MODE_HYP;                                                                         \
-       blne save_guest_regs
+#define SAVE_ALL											\
+	sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */					\
+	push {r0-r12}; /* Save R0-R12 */								\
+													\
+	mrs r11, ELR_hyp;		/* ELR_hyp is return address. */				\
+	str r11, [sp, #UREGS_pc];									\
+													\
+	str lr, [sp, #UREGS_lr];									\
+													\
+	add r11, sp, #UREGS_kernel_sizeof+4;								\
+	str r11, [sp, #UREGS_sp];									\
+													\
+	mrs r11, SPSR_hyp;										\
+	str r11, [sp, #UREGS_cpsr];									\
+	and r11, #PSR_MODE_MASK;									\
+	cmp r11, #PSR_MODE_HYP;										\
+	blne save_guest_regs
 
 save_guest_regs:
-       ldr r11, [sp, #UREGS_lr]
-       str r11, [sp, #UREGS_LR_usr]
-       ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
-       str r11, [sp, #UREGS_sp]
-       SAVE_ONE_BANKED(SP_usr)
-       SAVE_BANKED(svc)
-       SAVE_BANKED(abt)
-       SAVE_BANKED(und)
-       SAVE_BANKED(irq)
-       SAVE_BANKED(fiq)
-       SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
-       SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
-       mov pc, lr
+	ldr r11, [sp, #UREGS_lr]
+	str r11, [sp, #UREGS_LR_usr]
+	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
+	str r11, [sp, #UREGS_sp]
+	SAVE_ONE_BANKED(SP_usr)
+	SAVE_BANKED(svc)
+	SAVE_BANKED(abt)
+	SAVE_BANKED(und)
+	SAVE_BANKED(irq)
+	SAVE_BANKED(fiq)
+	SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); SAVE_ONE_BANKED(R10_fiq)
+	SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+	mov pc, lr
 
-#define DEFINE_TRAP_ENTRY(trap)                                                                                \
-       ALIGN;                                                                                          \
-trap_##trap:                                                                                           \
-       SAVE_ALL;                                                                                       \
-       adr lr, return_from_trap;                                                                       \
-       mov r0, sp;                                                                                     \
-       mov r11, sp;                                                                                    \
-       bic sp, #7; /* Align the stack pointer (noop on guest trap) */                                  \
-       b do_trap_##trap
+#define DEFINE_TRAP_ENTRY(trap)										\
+	ALIGN;												\
+trap_##trap:												\
+	SAVE_ALL;											\
+	adr lr, return_from_trap;									\
+	mov r0, sp;											\
+	mov r11, sp;											\
+	bic sp, #7; /* Align the stack pointer (noop on guest trap) */					\
+	b do_trap_##trap
 
 .globl hyp_traps_vector
-       .align 5
+	.align 5
 hyp_traps_vector:
-       .word 0                         /* 0x00 - Reset */
-       b trap_undefined_instruction    /* 0x04 - Undefined Instruction */
-       b trap_supervisor_call          /* 0x08 - Supervisor Call */
-       b trap_prefetch_abort           /* 0x0c - Prefetch Abort */
-       b trap_data_abort               /* 0x10 - Data Abort */
-       b trap_hypervisor               /* 0x14 - Hypervisor */
-       b trap_irq                      /* 0x18 - IRQ */
-       b trap_fiq                      /* 0x1c - FIQ */
+	.word 0				/* 0x00 - Reset */
+	b trap_undefined_instruction	/* 0x04 - Undefined Instruction */
+	b trap_supervisor_call		/* 0x08 - Supervisor Call */
+	b trap_prefetch_abort		/* 0x0c - Prefetch Abort */
+	b trap_data_abort		/* 0x10 - Data Abort */
+	b trap_hypervisor		/* 0x14 - Hypervisor */
+	b trap_irq			/* 0x18 - IRQ */
+	b trap_fiq			/* 0x1c - FIQ */
 
 DEFINE_TRAP_ENTRY(undefined_instruction)
 DEFINE_TRAP_ENTRY(supervisor_call)
@@ -74,34 +74,34 @@ DEFINE_TRAP_ENTRY(irq)
 DEFINE_TRAP_ENTRY(fiq)
 
 ENTRY(return_from_trap)
-       ldr r11, [sp, #UREGS_cpsr]
-       and r11, #PSR_MODE_MASK
-       cmp r11, #PSR_MODE_HYP
-       beq return_to_hypervisor
+	ldr r11, [sp, #UREGS_cpsr]
+	and r11, #PSR_MODE_MASK
+	cmp r11, #PSR_MODE_HYP
+	beq return_to_hypervisor
 
 ENTRY(return_to_guest)
-       mov r11, sp
-       bic sp, #7 /* Align the stack pointer */
-       bl leave_hypervisor_tail
-       ldr r11, [sp, #UREGS_pc]
-       msr ELR_hyp, r11
-       ldr r11, [sp, #UREGS_cpsr]
-       msr SPSR_hyp, r11
-       RESTORE_ONE_BANKED(SP_usr)
-       RESTORE_BANKED(svc)
-       RESTORE_BANKED(abt)
-       RESTORE_BANKED(und)
-       RESTORE_BANKED(irq)
-       RESTORE_BANKED(fiq)
-       RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
-       RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
-       ldr lr, [sp, #UREGS_LR_usr]
-       pop {r0-r12}
-       add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
-       eret
+	mov r11, sp
+	bic sp, #7 /* Align the stack pointer */
+	bl leave_hypervisor_tail
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
+	RESTORE_ONE_BANKED(SP_usr)
+	RESTORE_BANKED(svc)
+	RESTORE_BANKED(abt)
+	RESTORE_BANKED(und)
+	RESTORE_BANKED(irq)
+	RESTORE_BANKED(fiq)
+	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
+	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
+	ldr lr, [sp, #UREGS_LR_usr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
 
 ENTRY(return_to_hypervisor)
-       ldr lr, [sp, #UREGS_lr]
-       pop {r0-r12}
-       add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
-       eret
+	ldr lr, [sp, #UREGS_lr]
+	pop {r0-r12}
+	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
+	eret
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/head.S	Mon Feb 13 17:26:08 2012 +0000
@@ -26,281 +26,281 @@
  * Clobbers r0-r3. */
 #ifdef EARLY_UART_ADDRESS
 #define PRINT(_s)       \
-       adr   r0, 98f ; \
-       bl    puts    ; \
-       b     99f     ; \
-98:    .asciz _s     ; \
-       .align 2      ; \
+	adr   r0, 98f ; \
+	bl    puts    ; \
+	b     99f     ; \
+98:	.asciz _s     ; \
+	.align 2      ; \
 99:
 #else
 #define PRINT(s)
 #endif
 
-       .arm
+	.arm
 
-       /* This must be the very first address in the loaded image.
-        * It should be linked at XEN_VIRT_START, and loaded at any
-        * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
-        * or the initial pagetable code below will need adjustment. */
-       .global start
+	/* This must be the very first address in the loaded image.
+	 * It should be linked at XEN_VIRT_START, and loaded at any
+	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+	 * or the initial pagetable code below will need adjustment. */
+	.global start
 start:
-       cpsid aif                    /* Disable all interrupts */
+	cpsid aif                    /* Disable all interrupts */
 
-       /* Save the bootloader arguments in less-clobberable registers */
-       mov   r7, r1                 /* r7 := ARM-linux machine type */
-       mov   r8, r2                 /* r8 := ATAG base address */
+	/* Save the bootloader arguments in less-clobberable registers */
+	mov   r7, r1                 /* r7 := ARM-linux machine type */
+	mov   r8, r2                 /* r8 := ATAG base address */
 
-       /* Find out where we are */
-       ldr   r0, =start
-       adr   r9, start              /* r9  := paddr (start) */
-       sub   r10, r9, r0            /* r10 := phys-offset */
+	/* Find out where we are */
+	ldr   r0, =start
+	adr   r9, start              /* r9  := paddr (start) */
+	sub   r10, r9, r0            /* r10 := phys-offset */
 
-        /* Using the DTB in the .dtb section? */
+	/* Using the DTB in the .dtb section? */
 #ifdef CONFIG_DTB_FILE
-        ldr   r8, =_sdtb
-        add   r8, r10                /* r8 := paddr(DTB) */
+	ldr   r8, =_sdtb
+	add   r8, r10                /* r8 := paddr(DTB) */
 #endif
 
 #ifdef EARLY_UART_ADDRESS
-       /* Say hello */
-       ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
-       bl    init_uart
+	/* Say hello */
+	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
+	bl    init_uart
 #endif
 
-       /* Check that this CPU has Hyp mode */
-       mrc   CP32(r0, ID_PFR1)
-       and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
-       teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
-       beq   1f
-       bl    putn
-       PRINT("- CPU doesn't support the virtualization extensions -\r\n")
-       b     fail
+	/* Check that this CPU has Hyp mode */
+	mrc   CP32(r0, ID_PFR1)
+	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
+	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
+	beq   1f
+	bl    putn
+	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
+	b     fail
 1:
-       /* Check if we're already in it */
-       mrs   r0, cpsr
-       and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
-       teq   r0, #0x1a              /* Hyp Mode? */
-       bne   1f
-       PRINT("- Started in Hyp mode -\r\n")
-       b     hyp
+	/* Check if we're already in it */
+	mrs   r0, cpsr
+	and   r0, r0, #0x1f          /* Mode is in the low 5 bits of CPSR */
+	teq   r0, #0x1a              /* Hyp Mode? */
+	bne   1f
+	PRINT("- Started in Hyp mode -\r\n")
+	b     hyp
 1:
-       /* Otherwise, it must have been Secure Supervisor mode */
-       mrc   CP32(r0, SCR)
-       tst   r0, #0x1               /* Not-Secure bit set? */
-       beq   1f
-       PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
-       b     fail
+	/* Otherwise, it must have been Secure Supervisor mode */
+	mrc   CP32(r0, SCR)
+	tst   r0, #0x1               /* Not-Secure bit set? */
+	beq   1f
+	PRINT("- CPU is not in Hyp mode or Secure state -\r\n")
+	b     fail
 1:
-       /* OK, we're in Secure state. */
-       PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
+	/* OK, we're in Secure state. */
+	PRINT("- Started in Secure state -\r\n- Entering Hyp mode -\r\n")
 
-       /* Dance into Hyp mode */
-       cpsid aif, #0x16             /* Enter Monitor mode */
-       mrc   CP32(r0, SCR)
-       orr   r0, r0, #0x100         /* Set HCE */
-       orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
-       bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
-       mcr   CP32(r0, SCR)
-       /* Ugly: the system timer's frequency register is only
-        * programmable in Secure state.  Since we don't know where its
-        * memory-mapped control registers live, we can't find out the
-        * right frequency.  Use the VE model's default frequency here. */
-       ldr   r0, =0x5f5e100         /* 100 MHz */
-       mcr   CP32(r0, CNTFRQ)
-       ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
-       mcr   CP32(r0, NSACR)
-       /* Continuing ugliness: Set up the GIC so NS state owns interrupts */
-       mov   r0, #GIC_BASE_ADDRESS
-       add   r0, r0, #GIC_DR_OFFSET
-       mov   r1, #0
-       str   r1, [r0]               /* Disable delivery in the distributor */
-       add   r0, r0, #0x80          /* GICD_IGROUP0 */
-       mov   r2, #0xffffffff        /* All interrupts to group 1 */
-       str   r2, [r0]
-       str   r2, [r0, #4]
-       str   r2, [r0, #8]
-       /* Must drop priority mask below 0x80 before entering NS state */
-       mov   r0, #GIC_BASE_ADDRESS
-       add   r0, r0, #GIC_CR_OFFSET
-       ldr   r1, =0xff
-       str   r1, [r0, #0x4]         /* -> GICC_PMR */
-       /* Reset a few config registers */
-       mov   r0, #0
-       mcr   CP32(r0, FCSEIDR)
-       mcr   CP32(r0, CONTEXTIDR)
-       /* FIXME: ought to reset some other NS control regs here */
-       adr   r1, 1f
-       adr   r0, hyp                /* Store paddr (hyp entry point) */
-       str   r0, [r1]               /* where we can use it for RFE */
-       isb                          /* Ensure we see the stored target address */
-       rfeia r1                     /* Enter Hyp mode */
+	/* Dance into Hyp mode */
+	cpsid aif, #0x16             /* Enter Monitor mode */
+	mrc   CP32(r0, SCR)
+	orr   r0, r0, #0x100         /* Set HCE */
+	orr   r0, r0, #0xb1          /* Set SCD, AW, FW and NS */
+	bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
+	mcr   CP32(r0, SCR)
+	/* Ugly: the system timer's frequency register is only
+	 * programmable in Secure state.  Since we don't know where its
+	 * memory-mapped control registers live, we can't find out the
+	 * right frequency.  Use the VE model's default frequency here. */
+	ldr   r0, =0x5f5e100         /* 100 MHz */
+	mcr   CP32(r0, CNTFRQ)
+	ldr   r0, =0x40c00           /* SMP, c11, c10 in non-secure mode */
+	mcr   CP32(r0, NSACR)
+	/* Continuing ugliness: Set up the GIC so NS state owns interrupts */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_DR_OFFSET
+	mov   r1, #0
+	str   r1, [r0]               /* Disable delivery in the distributor */
+	add   r0, r0, #0x80          /* GICD_IGROUP0 */
+	mov   r2, #0xffffffff        /* All interrupts to group 1 */
+	str   r2, [r0]
+	str   r2, [r0, #4]
+	str   r2, [r0, #8]
+	/* Must drop priority mask below 0x80 before entering NS state */
+	mov   r0, #GIC_BASE_ADDRESS
+	add   r0, r0, #GIC_CR_OFFSET
+	ldr   r1, =0xff
+	str   r1, [r0, #0x4]         /* -> GICC_PMR */
+	/* Reset a few config registers */
+	mov   r0, #0
+	mcr   CP32(r0, FCSEIDR)
+	mcr   CP32(r0, CONTEXTIDR)
+	/* FIXME: ought to reset some other NS control regs here */
+	adr   r1, 1f
+	adr   r0, hyp                /* Store paddr (hyp entry point) */
+	str   r0, [r1]               /* where we can use it for RFE */
+	isb                          /* Ensure we see the stored target address */
+	rfeia r1                     /* Enter Hyp mode */
 
-1:     .word 0                      /* PC to enter Hyp mode at */
-       .word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
+1:	.word 0                      /* PC to enter Hyp mode at */
+	.word 0x000001da             /* CPSR: LE, Abort/IRQ/FIQ off, Hyp */
 
 hyp:
-       PRINT("- Setting up control registers -\r\n")
+	PRINT("- Setting up control registers -\r\n")
 
-       /* Set up memory attribute type tables */
-       ldr   r0, =MAIR0VAL
-       ldr   r1, =MAIR1VAL
-       mcr   CP32(r0, MAIR0)
-       mcr   CP32(r1, MAIR1)
-       mcr   CP32(r0, HMAIR0)
-       mcr   CP32(r1, HMAIR1)
+	/* Set up memory attribute type tables */
+	ldr   r0, =MAIR0VAL
+	ldr   r1, =MAIR1VAL
+	mcr   CP32(r0, MAIR0)
+	mcr   CP32(r1, MAIR1)
+	mcr   CP32(r0, HMAIR0)
+	mcr   CP32(r1, HMAIR1)
 
-       /* Set up the HTCR:
-        * PT walks use Outer-Shareable accesses,
-        * PT walks are write-back, no-write-allocate in both cache levels,
-        * Full 32-bit address space goes through this table. */
-       ldr   r0, =0x80002500
-       mcr   CP32(r0, HTCR)
+	/* Set up the HTCR:
+	 * PT walks use Outer-Shareable accesses,
+	 * PT walks are write-back, no-write-allocate in both cache levels,
+	 * Full 32-bit address space goes through this table. */
+	ldr   r0, =0x80002500
+	mcr   CP32(r0, HTCR)
 
-       /* Set up the HSCTLR:
-        * Exceptions in LE ARM,
-        * Low-latency IRQs disabled,
-        * Write-implies-XN disabled (for now),
-        * I-cache and d-cache enabled,
-        * Alignment checking enabled,
-        * MMU translation disabled (for now). */
-       ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
-       mcr   CP32(r0, HSCTLR)
+	/* Set up the HSCTLR:
+	 * Exceptions in LE ARM,
+	 * Low-latency IRQs disabled,
+	 * Write-implies-XN disabled (for now),
+	 * I-cache and d-cache enabled,
+	 * Alignment checking enabled,
+	 * MMU translation disabled (for now). */
+	ldr   r0, =(HSCTLR_BASE|SCTLR_A|SCTLR_C)
+	mcr   CP32(r0, HSCTLR)
 
-       /* Write Xen's PT's paddr into the HTTBR */
-       ldr   r4, =xen_pgtable
-       add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
-       mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
-       mcrr  CP64(r4, r5, HTTBR)
+	/* Write Xen's PT's paddr into the HTTBR */
+	ldr   r4, =xen_pgtable
+	add   r4, r4, r10            /* r4 := paddr (xen_pagetable) */
+	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
+	mcrr  CP64(r4, r5, HTTBR)
 
-       /* Build the baseline idle pagetable's first-level entries */
-       ldr   r1, =xen_second
-       add   r1, r1, r10            /* r1 := paddr (xen_second) */
-       mov   r3, #0x0
-       orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
-       orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
-       strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
-       add   r2, r2, #0x1000
-       strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
-       add   r2, r2, #0x1000
-       strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
-       add   r2, r2, #0x1000
-       strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
+	/* Build the baseline idle pagetable's first-level entries */
+	ldr   r1, =xen_second
+	add   r1, r1, r10            /* r1 := paddr (xen_second) */
+	mov   r3, #0x0
+	orr   r2, r1, #0xe00         /* r2:r3 := table map of xen_second */
+	orr   r2, r2, #0x07f         /* (+ rights for linear PT) */
+	strd  r2, r3, [r4, #0]       /* Map it in slot 0 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #8]       /* Map 2nd page in slot 1 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #16]      /* Map 3rd page in slot 2 */
+	add   r2, r2, #0x1000
+	strd  r2, r3, [r4, #24]      /* Map 4th page in slot 3 */
 
-       /* Now set up the second-level entries */
-       orr   r2, r9, #0xe00
-       orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
-       mov   r4, r9, lsr #18        /* Slot for paddr(start) */
-       strd  r2, r3, [r1, r4]       /* Map Xen there */
-       ldr   r4, =start
-       lsr   r4, #18                /* Slot for vaddr(start) */
-       strd  r2, r3, [r1, r4]       /* Map Xen there too */
+	/* Now set up the second-level entries */
+	orr   r2, r9, #0xe00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB normal map of Xen */
+	mov   r4, r9, lsr #18        /* Slot for paddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there */
+	ldr   r4, =start
+	lsr   r4, #18                /* Slot for vaddr(start) */
+	strd  r2, r3, [r1, r4]       /* Map Xen there too */
 #ifdef EARLY_UART_ADDRESS
-       ldr   r3, =(1<<(54-32))      /* NS for device mapping */
-       lsr   r2, r11, #21
-       lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
-       orr   r2, r2, #0xe00
-       orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
-       add   r4, r4, #8
-       strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
+	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
+	lsr   r2, r11, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
+	orr   r2, r2, #0xe00
+	orr   r2, r2, #0x071         /* r2:r3 := 2MB dev map including UART */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #else
-       add   r4, r4, #8             /* Skip over unused fixmap slot */
+	add   r4, r4, #8             /* Skip over unused fixmap slot */
 #endif
-       mov   r3, #0x0
-       lsr   r2, r8, #21
-       lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
-       orr   r2, r2, #0xf00
-       orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
-       add   r4, r4, #8
-       strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
+	mov   r3, #0x0
+	lsr   r2, r8, #21
+	lsl   r2, r2, #21            /* 2MB-aligned paddr of DTB */
+	orr   r2, r2, #0xf00
+	orr   r2, r2, #0x07d         /* r2:r3 := 2MB RAM incl. DTB */
+	add   r4, r4, #8
+	strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
-       PRINT("- Turning on paging -\r\n")
+	PRINT("- Turning on paging -\r\n")
 
-       ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
-       mrc   CP32(r0, HSCTLR)
-       orr   r0, r0, #0x1           /* Add in the MMU enable bit */
-       dsb                          /* Flush PTE writes and finish reads */
-       mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
-       isb                          /* Now, flush the icache */
-       mov   pc, r1                 /* Get a proper vaddr into PC */
+	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
+	mrc   CP32(r0, HSCTLR)
+	orr   r0, r0, #0x1           /* Add in the MMU enable bit */
+	dsb                          /* Flush PTE writes and finish reads */
+	mcr   CP32(r0, HSCTLR)       /* now paging is enabled */
+	isb                          /* Now, flush the icache */
+	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
 #ifdef EARLY_UART_ADDRESS
-       /* Recover the UART address in the new address space */
-       lsl   r11, #11
-       lsr   r11, #11               /* UART base's offset from 2MB base */
-       adr   r0, start
-       add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
-       add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+	/* Recover the UART address in the new address space */
+	lsl   r11, #11
+	lsr   r11, #11               /* UART base's offset from 2MB base */
+	adr   r0, start
+	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
+	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
 #endif
 
-       PRINT("- Entering C -\r\n")
+	PRINT("- Entering C -\r\n")
 
-       ldr   sp, =init_stack        /* Supply a stack */
-       add   sp, #STACK_SIZE        /* (which grows down from the top). */
-       sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
-       mov   r0, r10                /* Marshal args: - phys_offset */
-       mov   r1, r7                 /*               - machine type */
-       mov   r2, r8                 /*               - ATAG address */
-       b     start_xen              /* and disappear into the land of C */
+	ldr   sp, =init_stack        /* Supply a stack */
+	add   sp, #STACK_SIZE        /* (which grows down from the top). */
+	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
+	mov   r0, r10                /* Marshal args: - phys_offset */
+	mov   r1, r7                 /*               - machine type */
+	mov   r2, r8                 /*               - ATAG address */
+	b     start_xen              /* and disappear into the land of C */
 
 /* Fail-stop
  * r0: string explaining why */
-fail:  PRINT("- Boot failed -\r\n")
-1:     wfe
-       b     1b
+fail:	PRINT("- Boot failed -\r\n")
+1:	wfe
+	b     1b
 
 #ifdef EARLY_UART_ADDRESS
 
 /* Bring up the UART. Specific to the PL011 UART.
  * Clobbers r0-r2 */
 init_uart:
-       mov   r1, #0x0
-       str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
-       mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
-       str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
-       mov   r1, #0x60              /* 8n1 */
-       str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
-       ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
-       str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
-       adr   r0, 1f
-       b     puts
-1:     .asciz "- UART enabled -\r\n"
-       .align 4
+	mov   r1, #0x0
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+	mov   r1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+	str   r1, [r11, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+	mov   r1, #0x60              /* 8n1 */
+	str   r1, [r11, #0x24]       /* -> UARTLCR_H (Line control) */
+	ldr   r1, =0x00000301        /* RXE | TXE | UARTEN */
+	str   r1, [r11, #0x30]       /* -> UARTCR (Control Register) */
+	adr   r0, 1f
+	b     puts
+1:	.asciz "- UART enabled -\r\n"
+	.align 4
 
 /* Print early debug messages.  Specific to the PL011 UART.
  * r0: Nul-terminated string to print.
  * Clobbers r0-r2 */
 puts:
-       ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
-       tst   r2, #0x8               /* Check BUSY bit */
-       bne   puts                   /* Wait for the UART to be ready */
-       ldrb  r2, [r0], #1           /* Load next char */
-       teq   r2, #0                 /* Exit on nul*/
-       moveq pc, lr
-       str   r2, [r11]              /* -> UARTDR (Data Register) */
-       b     puts
+	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   puts                   /* Wait for the UART to be ready */
+	ldrb  r2, [r0], #1           /* Load next char */
+	teq   r2, #0                 /* Exit on nul*/
+	moveq pc, lr
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	b     puts
 
 /* Print a 32-bit number in hex.  Specific to the PL011 UART.
  * r0: Number to print.
  * clobbers r0-r3 */
 putn:
-       adr   r1, hex
-       mov   r3, #8
-1:     ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
-       tst   r2, #0x8               /* Check BUSY bit */
-       bne   1b                     /* Wait for the UART to be ready */
-       and   r2, r0, #0xf0000000    /* Mask off the top nybble */
-       ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
-       str   r2, [r11]              /* -> UARTDR (Data Register) */
-       lsl   r0, #4                 /* Roll it through one nybble at a time */
-       subs  r3, r3, #1
-       bne   1b
-       adr   r0, crlf               /* Finish with a newline */
-       b     puts
+	adr   r1, hex
+	mov   r3, #8
+1:	ldr   r2, [r11, #0x18]       /* <- UARTFR (Flag register) */
+	tst   r2, #0x8               /* Check BUSY bit */
+	bne   1b                     /* Wait for the UART to be ready */
+	and   r2, r0, #0xf0000000    /* Mask off the top nybble */
+	ldrb  r2, [r1, r2, lsr #28]  /* Convert to a char */
+	str   r2, [r11]              /* -> UARTDR (Data Register) */
+	lsl   r0, #4                 /* Roll it through one nybble at a time */
+	subs  r3, r3, #1
+	bne   1b
+	adr   r0, crlf               /* Finish with a newline */
+	b     puts
 
-crlf:  .asciz "\r\n"
-hex:   .ascii "0123456789abcdef"
-       .align 2
+crlf:	.asciz "\r\n"
+hex:	.ascii "0123456789abcdef"
+	.align 2
 
 #else  /* EARLY_UART_ADDRESS */
 
@@ -308,6 +308,6 @@ init_uart:
 .global early_puts
 early_puts:
 puts:
-putn:  mov   pc, lr
+putn:	mov   pc, lr
 
 #endif /* EARLY_UART_ADDRESS */
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/bitops.h
--- a/xen/arch/arm/lib/bitops.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/bitops.h	Mon Feb 13 17:26:08 2012 +0000
@@ -1,61 +1,61 @@
 #include <xen/config.h>
 
 #if __LINUX_ARM_ARCH__ >= 6
-       .macro  bitop, instr
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       mov     r2, #1
-       and     r3, r0, #31             @ Get bit offset
-       mov     r0, r0, lsr #5
-       add     r1, r1, r0, lsl #2      @ Get word offset
-       mov     r3, r2, lsl r3
-1:     ldrex   r2, [r1]
-       \instr  r2, r2, r3
-       strex   r0, r2, [r1]
-       cmp     r0, #0
-       bne     1b
-       bx      lr
-       .endm
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
 
-       .macro  testop, instr, store
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       mov     r2, #1
-       and     r3, r0, #31             @ Get bit offset
-       mov     r0, r0, lsr #5
-       add     r1, r1, r0, lsl #2      @ Get word offset
-       mov     r3, r2, lsl r3          @ create mask
-       smp_dmb
-1:     ldrex   r2, [r1]
-       ands    r0, r2, r3              @ save old value of bit
-       \instr  r2, r2, r3              @ toggle bit
-       strex   ip, r2, [r1]
-       cmp     ip, #0
-       bne     1b
-       smp_dmb
-       cmp     r0, #0
-       movne   r0, #1
-2:     bx      lr
-       .endm
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
 #else
-       .macro  bitop, name, instr
-ENTRY( \name           )
-UNWIND(        .fnstart        )
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       and     r2, r0, #31
-       mov     r0, r0, lsr #5
-       mov     r3, #1
-       mov     r3, r3, lsl r2
-       save_and_disable_irqs ip
-       ldr     r2, [r1, r0, lsl #2]
-       \instr  r2, r2, r3
-       str     r2, [r1, r0, lsl #2]
-       restore_irqs ip
-       mov     pc, lr
-UNWIND(        .fnend          )
-ENDPROC(\name          )
-       .endm
+	.macro	bitop, name, instr
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
+	mov	r3, #1
+	mov	r3, r3, lsl r2
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]
+	\instr	r2, r2, r3
+	str	r2, [r1, r0, lsl #2]
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
 
 /**
  * testop - implement a test_and_xxx_bit operation.
@@ -65,23 +65,23 @@ ENDPROC(\name          )
  * Note: we can trivially conditionalise the store instruction
  * to avoid dirtying the data cache.
  */
-       .macro  testop, name, instr, store
-ENTRY( \name           )
-UNWIND(        .fnstart        )
-       ands    ip, r1, #3
-       strneb  r1, [ip]                @ assert word-aligned
-       and     r3, r0, #31
-       mov     r0, r0, lsr #5
-       save_and_disable_irqs ip
-       ldr     r2, [r1, r0, lsl #2]!
-       mov     r0, #1
-       tst     r2, r0, lsl r3
-       \instr  r2, r2, r0, lsl r3
-       \store  r2, [r1]
-       moveq   r0, #0
-       restore_irqs ip
-       mov     pc, lr
-UNWIND(        .fnend          )
-ENDPROC(\name          )
-       .endm
+	.macro	testop, name, instr, store
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
+	tst	r2, r0, lsl r3
+	\instr	r2, r2, r0, lsl r3
+	\store	r2, [r1]
+	moveq	r0, #0
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
 #endif
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/changebit.S
--- a/xen/arch/arm/lib/changebit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/changebit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_change_bit)
-       bitop   eor
+	bitop	eor
 ENDPROC(_change_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/clearbit.S
--- a/xen/arch/arm/lib/clearbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/clearbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -15,5 +15,5 @@
                 .text
 
 ENTRY(_clear_bit)
-       bitop   bic
+	bitop	bic
 ENDPROC(_clear_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/copy_template.S
--- a/xen/arch/arm/lib/copy_template.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/copy_template.S	Mon Feb 13 17:26:08 2012 +0000
@@ -3,9 +3,9 @@
  *
  *  Code template for optimized memory copy functions
  *
- *  Author:    Nicolas Pitre
- *  Created:   Sep 28, 2005
- *  Copyright: MontaVista Software, Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
  *
  *  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
@@ -24,227 +24,227 @@
  *
  * ldr1w ptr reg abort
  *
- *     This loads one word from 'ptr', stores it in 'reg' and increments
- *     'ptr' to the next word. The 'abort' argument is used for fixup tables.
+ *	This loads one word from 'ptr', stores it in 'reg' and increments
+ *	'ptr' to the next word. The 'abort' argument is used for fixup tables.
  *
  * ldr4w ptr reg1 reg2 reg3 reg4 abort
  * ldr8w ptr, reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
  *
- *     This loads four or eight words starting from 'ptr', stores them
- *     in provided registers and increments 'ptr' past those words.
- *     The'abort' argument is used for fixup tables.
+ *	This loads four or eight words starting from 'ptr', stores them
+ *	in provided registers and increments 'ptr' past those words.
+ *	The'abort' argument is used for fixup tables.
  *
  * ldr1b ptr reg cond abort
  *
- *     Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
- *     It also must apply the condition code if provided, otherwise the
- *     "al" condition is assumed by default.
+ *	Similar to ldr1w, but it loads a byte and increments 'ptr' one byte.
+ *	It also must apply the condition code if provided, otherwise the
+ *	"al" condition is assumed by default.
  *
  * str1w ptr reg abort
  * str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
  * str1b ptr reg cond abort
  *
- *     Same as their ldr* counterparts, but data is stored to 'ptr' location
- *     rather than being loaded.
+ *	Same as their ldr* counterparts, but data is stored to 'ptr' location
+ *	rather than being loaded.
  *
  * enter reg1 reg2
  *
- *     Preserve the provided registers on the stack plus any additional
- *     data as needed by the implementation including this code. Called
- *     upon code entry.
+ *	Preserve the provided registers on the stack plus any additional
+ *	data as needed by the implementation including this code. Called
+ *	upon code entry.
  *
  * exit reg1 reg2
  *
- *     Restore registers with the values previously saved with the
- *     'preserv' macro. Called upon code termination.
+ *	Restore registers with the values previously saved with the
+ *	'preserv' macro. Called upon code termination.
  *
  * LDR1W_SHIFT
  * STR1W_SHIFT
  *
- *     Correction to be applied to the "ip" register when branching into
- *     the ldr1w or str1w instructions (some of these macros may expand to
- *     than one 32bit instruction in Thumb-2)
+ *	Correction to be applied to the "ip" register when branching into
+ *	the ldr1w or str1w instructions (some of these macros may expand to
+ *	than one 32bit instruction in Thumb-2)
  */
 
 
-               enter   r4, lr
+		enter	r4, lr
 
-               subs    r2, r2, #4
-               blt     8f
-               ands    ip, r0, #3
-       PLD(    pld     [r1, #0]                )
-               bne     9f
-               ands    ip, r1, #3
-               bne     10f
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #0]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
 
-1:             subs    r2, r2, #(28)
-               stmfd   sp!, {r5 - r8}
-               blt     5f
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  rsb     r3, ip, #32             )
-       CALGN(  sbcnes  r4, r3, r2              )  @ C is always set here
-       CALGN(  bcs     2f                      )
-       CALGN(  adr     r4, 6f                  )
-       CALGN(  subs    r2, r2, r3              )  @ C gets set
-       CALGN(  add     pc, r4, ip              )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	r3, ip, #32		)
+	CALGN(	sbcnes	r4, r3, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, r3		)  @ C gets set
+	CALGN(	add	pc, r4, ip		)
 
-       PLD(    pld     [r1, #0]                )
-2:     PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #28]               )
-       PLD(    blt     4f                      )
-       PLD(    pld     [r1, #60]               )
-       PLD(    pld     [r1, #92]               )
+	PLD(	pld	[r1, #0]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
 
-3:     PLD(    pld     [r1, #124]              )
-4:             ldr8w   r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
-               subs    r2, r2, #32
-               str8w   r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
-               bge     3b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     4b                      )
+3:	PLD(	pld	[r1, #124]		)
+4:		ldr8w	r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		subs	r2, r2, #32
+		str8w	r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
 
-5:             ands    ip, r2, #28
-               rsb     ip, ip, #32
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
 #if LDR1W_SHIFT > 0
-               lsl     ip, ip, #LDR1W_SHIFT
+		lsl	ip, ip, #LDR1W_SHIFT
 #endif
-               addne   pc, pc, ip              @ C is always clear here
-               b       7f
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
 6:
-               .rept   (1 << LDR1W_SHIFT)
-               W(nop)
-               .endr
-               ldr1w   r1, r3, abort=20f
-               ldr1w   r1, r4, abort=20f
-               ldr1w   r1, r5, abort=20f
-               ldr1w   r1, r6, abort=20f
-               ldr1w   r1, r7, abort=20f
-               ldr1w   r1, r8, abort=20f
-               ldr1w   r1, lr, abort=20f
+		.rept	(1 << LDR1W_SHIFT)
+		W(nop)
+		.endr
+		ldr1w	r1, r3, abort=20f
+		ldr1w	r1, r4, abort=20f
+		ldr1w	r1, r5, abort=20f
+		ldr1w	r1, r6, abort=20f
+		ldr1w	r1, r7, abort=20f
+		ldr1w	r1, r8, abort=20f
+		ldr1w	r1, lr, abort=20f
 
 #if LDR1W_SHIFT < STR1W_SHIFT
-               lsl     ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
+		lsl	ip, ip, #STR1W_SHIFT - LDR1W_SHIFT
 #elif LDR1W_SHIFT > STR1W_SHIFT
-               lsr     ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
+		lsr	ip, ip, #LDR1W_SHIFT - STR1W_SHIFT
 #endif
-               add     pc, pc, ip
-               nop
-               .rept   (1 << STR1W_SHIFT)
-               W(nop)
-               .endr
-               str1w   r0, r3, abort=20f
-               str1w   r0, r4, abort=20f
-               str1w   r0, r5, abort=20f
-               str1w   r0, r6, abort=20f
-               str1w   r0, r7, abort=20f
-               str1w   r0, r8, abort=20f
-               str1w   r0, lr, abort=20f
+		add	pc, pc, ip
+		nop
+		.rept	(1 << STR1W_SHIFT)
+		W(nop)
+		.endr
+		str1w	r0, r3, abort=20f
+		str1w	r0, r4, abort=20f
+		str1w	r0, r5, abort=20f
+		str1w	r0, r6, abort=20f
+		str1w	r0, r7, abort=20f
+		str1w	r0, r8, abort=20f
+		str1w	r0, lr, abort=20f
 
-       CALGN(  bcs     2b                      )
+	CALGN(	bcs	2b			)
 
-7:             ldmfd   sp!, {r5 - r8}
+7:		ldmfd	sp!, {r5 - r8}
 
-8:             movs    r2, r2, lsl #31
-               ldr1b   r1, r3, ne, abort=21f
-               ldr1b   r1, r4, cs, abort=21f
-               ldr1b   r1, ip, cs, abort=21f
-               str1b   r0, r3, ne, abort=21f
-               str1b   r0, r4, cs, abort=21f
-               str1b   r0, ip, cs, abort=21f
+8:		movs	r2, r2, lsl #31
+		ldr1b	r1, r3, ne, abort=21f
+		ldr1b	r1, r4, cs, abort=21f
+		ldr1b	r1, ip, cs, abort=21f
+		str1b	r0, r3, ne, abort=21f
+		str1b	r0, r4, cs, abort=21f
+		str1b	r0, ip, cs, abort=21f
 
-               exit    r4, pc
+		exit	r4, pc
 
-9:             rsb     ip, ip, #4
-               cmp     ip, #2
-               ldr1b   r1, r3, gt, abort=21f
-               ldr1b   r1, r4, ge, abort=21f
-               ldr1b   r1, lr, abort=21f
-               str1b   r0, r3, gt, abort=21f
-               str1b   r0, r4, ge, abort=21f
-               subs    r2, r2, ip
-               str1b   r0, lr, abort=21f
-               blt     8b
-               ands    ip, r1, #3
-               beq     1b
+9:		rsb	ip, ip, #4
+		cmp	ip, #2
+		ldr1b	r1, r3, gt, abort=21f
+		ldr1b	r1, r4, ge, abort=21f
+		ldr1b	r1, lr, abort=21f
+		str1b	r0, r3, gt, abort=21f
+		str1b	r0, r4, ge, abort=21f
+		subs	r2, r2, ip
+		str1b	r0, lr, abort=21f
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
 
-10:            bic     r1, r1, #3
-               cmp     ip, #2
-               ldr1w   r1, lr, abort=21f
-               beq     17f
-               bgt     18f
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr1w	r1, lr, abort=21f
+		beq	17f
+		bgt	18f
 
 
-               .macro  forward_copy_shift pull push
+		.macro	forward_copy_shift pull push
 
-               subs    r2, r2, #28
-               blt     14f
+		subs	r2, r2, #28
+		blt	14f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  rsb     ip, ip, #32             )
-       CALGN(  sbcnes  r4, ip, r2              )  @ C is always set here
-       CALGN(  subcc   r2, r2, ip              )
-       CALGN(  bcc     15f                     )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
 
-11:            stmfd   sp!, {r5 - r9}
+11:		stmfd	sp!, {r5 - r9}
 
-       PLD(    pld     [r1, #0]                )
-       PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #28]               )
-       PLD(    blt     13f                     )
-       PLD(    pld     [r1, #60]               )
-       PLD(    pld     [r1, #92]               )
+	PLD(	pld	[r1, #0]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #28]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #60]		)
+	PLD(	pld	[r1, #92]		)
 
-12:    PLD(    pld     [r1, #124]              )
-13:            ldr4w   r1, r4, r5, r6, r7, abort=19f
-               mov     r3, lr, pull #\pull
-               subs    r2, r2, #32
-               ldr4w   r1, r8, r9, ip, lr, abort=19f
-               orr     r3, r3, r4, push #\push
-               mov     r4, r4, pull #\pull
-               orr     r4, r4, r5, push #\push
-               mov     r5, r5, pull #\pull
-               orr     r5, r5, r6, push #\push
-               mov     r6, r6, pull #\pull
-               orr     r6, r6, r7, push #\push
-               mov     r7, r7, pull #\pull
-               orr     r7, r7, r8, push #\push
-               mov     r8, r8, pull #\pull
-               orr     r8, r8, r9, push #\push
-               mov     r9, r9, pull #\pull
-               orr     r9, r9, ip, push #\push
-               mov     ip, ip, pull #\pull
-               orr     ip, ip, lr, push #\push
-               str8w   r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
-               bge     12b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     13b                     )
+12:	PLD(	pld	[r1, #124]		)
+13:		ldr4w	r1, r4, r5, r6, r7, abort=19f
+		mov	r3, lr, pull #\pull
+		subs	r2, r2, #32
+		ldr4w	r1, r8, r9, ip, lr, abort=19f
+		orr	r3, r3, r4, push #\push
+		mov	r4, r4, pull #\pull
+		orr	r4, r4, r5, push #\push
+		mov	r5, r5, pull #\pull
+		orr	r5, r5, r6, push #\push
+		mov	r6, r6, pull #\pull
+		orr	r6, r6, r7, push #\push
+		mov	r7, r7, pull #\pull
+		orr	r7, r7, r8, push #\push
+		mov	r8, r8, pull #\pull
+		orr	r8, r8, r9, push #\push
+		mov	r9, r9, pull #\pull
+		orr	r9, r9, ip, push #\push
+		mov	ip, ip, pull #\pull
+		orr	ip, ip, lr, push #\push
+		str8w	r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
 
-               ldmfd   sp!, {r5 - r9}
+		ldmfd	sp!, {r5 - r9}
 
-14:            ands    ip, r2, #28
-               beq     16f
+14:		ands	ip, r2, #28
+		beq	16f
 
-15:            mov     r3, lr, pull #\pull
-               ldr1w   r1, lr, abort=21f
-               subs    ip, ip, #4
-               orr     r3, r3, lr, push #\push
-               str1w   r0, r3, abort=21f
-               bgt     15b
-       CALGN(  cmp     r2, #0                  )
-       CALGN(  bge     11b                     )
+15:		mov	r3, lr, pull #\pull
+		ldr1w	r1, lr, abort=21f
+		subs	ip, ip, #4
+		orr	r3, r3, lr, push #\push
+		str1w	r0, r3, abort=21f
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
 
-16:            sub     r1, r1, #(\push / 8)
-               b       8b
+16:		sub	r1, r1, #(\push / 8)
+		b	8b
 
-               .endm
+		.endm
 
 
-               forward_copy_shift      pull=8  push=24
+		forward_copy_shift	pull=8	push=24
 
-17:            forward_copy_shift      pull=16 push=16
+17:		forward_copy_shift	pull=16	push=16
 
-18:            forward_copy_shift      pull=24 push=8
+18:		forward_copy_shift	pull=24	push=8
 
 
 /*
@@ -254,14 +254,14 @@ 18:            forward_copy_shift      p
  * the exit macro.
  */
 
-       .macro  copy_abort_preamble
-19:    ldmfd   sp!, {r5 - r9}
-       b       21f
-20:    ldmfd   sp!, {r5 - r8}
+	.macro	copy_abort_preamble
+19:	ldmfd	sp!, {r5 - r9}
+	b	21f
+20:	ldmfd	sp!, {r5 - r8}
 21:
-       .endm
+	.endm
 
-       .macro  copy_abort_end
-       ldmfd   sp!, {r4, pc}
-       .endm
+	.macro	copy_abort_end
+	ldmfd	sp!, {r4, pc}
+	.endm
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/div64.S
--- a/xen/arch/arm/lib/div64.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/div64.S	Mon Feb 13 17:26:08 2012 +0000
@@ -3,9 +3,9 @@
  *
  *  Optimized computation of 64-bit dividend / 32-bit divisor
  *
- *  Author:    Nicolas Pitre
- *  Created:   Oct 5, 2003
- *  Copyright: Monta Vista Software, Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Oct 5, 2003
+ *  Copyright:	Monta Vista Software, Inc.
  *
  *  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
@@ -14,7 +14,7 @@
 
 #include <xen/config.h>
 #include "assembler.h"
-
+	
 #ifdef __ARMEB__
 #define xh r0
 #define xl r1
@@ -34,12 +34,12 @@
  *       This is meant to be used by do_div() from include/asm/div64.h only.
  *
  * Input parameters:
- *     xh-xl   = dividend (clobbered)
- *     r4      = divisor (preserved)
+ * 	xh-xl	= dividend (clobbered)
+ * 	r4	= divisor (preserved)
  *
  * Output values:
- *     yh-yl   = result
- *     xh      = remainder
+ * 	yh-yl	= result
+ * 	xh	= remainder
  *
  * Clobbered regs: xl, ip
  */
@@ -47,165 +47,165 @@
 ENTRY(__do_div64)
 UNWIND(.fnstart)
 
-       @ Test for easy paths first.
-       subs    ip, r4, #1
-       bls     9f                      @ divisor is 0 or 1
-       tst     ip, r4
-       beq     8f                      @ divisor is power of 2
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
 
-       @ See if we need to handle upper 32-bit result.
-       cmp     xh, r4
-       mov     yh, #0
-       blo     3f
+	@ See if we need to handle upper 32-bit result.
+	cmp	xh, r4
+	mov	yh, #0
+	blo	3f
 
-       @ Align divisor with upper part of dividend.
-       @ The aligned divisor is stored in yl preserving the original.
-       @ The bit position is stored in ip.
+	@ Align divisor with upper part of dividend.
+	@ The aligned divisor is stored in yl preserving the original.
+	@ The bit position is stored in ip.
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     yl, r4
-       clz     ip, xh
-       sub     yl, yl, ip
-       mov     ip, #1
-       mov     ip, ip, lsl yl
-       mov     yl, r4, lsl yl
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
 
 #else
 
-       mov     yl, r4
-       mov     ip, #1
-1:     cmp     yl, #0x80000000
-       cmpcc   yl, xh
-       movcc   yl, yl, lsl #1
-       movcc   ip, ip, lsl #1
-       bcc     1b
+	mov	yl, r4
+	mov	ip, #1
+1:	cmp	yl, #0x80000000
+	cmpcc	yl, xh
+	movcc	yl, yl, lsl #1
+	movcc	ip, ip, lsl #1
+	bcc	1b
 
 #endif
 
-       @ The division loop for needed upper bit positions.
-       @ Break out early if dividend reaches 0.
-2:     cmp     xh, yl
-       orrcs   yh, yh, ip
-       subcss  xh, xh, yl
-       movnes  ip, ip, lsr #1
-       mov     yl, yl, lsr #1
-       bne     2b
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
 
-       @ See if we need to handle lower 32-bit result.
-3:     cmp     xh, #0
-       mov     yl, #0
-       cmpeq   xl, r4
-       movlo   xh, xl
-       movlo   pc, lr
+	@ See if we need to handle lower 32-bit result.
+3:	cmp	xh, #0
+	mov	yl, #0
+	cmpeq	xl, r4
+	movlo	xh, xl
+	movlo	pc, lr
 
-       @ The division loop for lower bit positions.
-       @ Here we shift remainer bits leftwards rather than moving the
-       @ divisor for comparisons, considering the carry-out bit as well.
-       mov     ip, #0x80000000
-4:     movs    xl, xl, lsl #1
-       adcs    xh, xh, xh
-       beq     6f
-       cmpcc   xh, r4
-5:     orrcs   yl, yl, ip
-       subcs   xh, xh, r4
-       movs    ip, ip, lsr #1
-       bne     4b
-       mov     pc, lr
+	@ The division loop for lower bit positions.
+	@ Here we shift remainer bits leftwards rather than moving the
+	@ divisor for comparisons, considering the carry-out bit as well.
+	mov	ip, #0x80000000
+4:	movs	xl, xl, lsl #1
+	adcs	xh, xh, xh
+	beq	6f
+	cmpcc	xh, r4
+5:	orrcs	yl, yl, ip
+	subcs	xh, xh, r4
+	movs	ip, ip, lsr #1
+	bne	4b
+	mov	pc, lr
 
-       @ The top part of remainder became zero.  If carry is set
-       @ (the 33th bit) this is a false positive so resume the loop.
-       @ Otherwise, if lower part is also null then we are done.
-6:     bcs     5b
-       cmp     xl, #0
-       moveq   pc, lr
+	@ The top part of remainder became zero.  If carry is set
+	@ (the 33th bit) this is a false positive so resume the loop.
+	@ Otherwise, if lower part is also null then we are done.
+6:	bcs	5b
+	cmp	xl, #0
+	moveq	pc, lr
 
-       @ We still have remainer bits in the low part.  Bring them up.
+	@ We still have remainer bits in the low part.  Bring them up.
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     xh, xl                  @ we know xh is zero here so...
-       add     xh, xh, #1
-       mov     xl, xl, lsl xh
-       mov     ip, ip, lsr xh
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
 
 #else
 
-7:     movs    xl, xl, lsl #1
-       mov     ip, ip, lsr #1
-       bcc     7b
+7:	movs	xl, xl, lsl #1
+	mov	ip, ip, lsr #1
+	bcc	7b
 
 #endif
 
-       @ Current remainder is now 1.  It is worthless to compare with
-       @ divisor at this point since divisor can not be smaller than 3 here.
-       @ If possible, branch for another shift in the division loop.
-       @ If no bit position left then we are done.
-       movs    ip, ip, lsr #1
-       mov     xh, #1
-       bne     4b
-       mov     pc, lr
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
 
-8:     @ Division by a power of 2: determine what that divisor order is
-       @ then simply shift values around
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     ip, r4
-       rsb     ip, ip, #31
+	clz	ip, r4
+	rsb	ip, ip, #31
 
 #else
 
-       mov     yl, r4
-       cmp     r4, #(1 << 16)
-       mov     ip, #0
-       movhs   yl, yl, lsr #16
-       movhs   ip, #16
+	mov	yl, r4
+	cmp	r4, #(1 << 16)
+	mov	ip, #0
+	movhs	yl, yl, lsr #16
+	movhs	ip, #16
 
-       cmp     yl, #(1 << 8)
-       movhs   yl, yl, lsr #8
-       addhs   ip, ip, #8
+	cmp	yl, #(1 << 8)
+	movhs	yl, yl, lsr #8
+	addhs	ip, ip, #8
 
-       cmp     yl, #(1 << 4)
-       movhs   yl, yl, lsr #4
-       addhs   ip, ip, #4
+	cmp	yl, #(1 << 4)
+	movhs	yl, yl, lsr #4
+	addhs	ip, ip, #4
 
-       cmp     yl, #(1 << 2)
-       addhi   ip, ip, #3
-       addls   ip, ip, yl, lsr #1
+	cmp	yl, #(1 << 2)
+	addhi	ip, ip, #3
+	addls	ip, ip, yl, lsr #1
 
 #endif
 
-       mov     yh, xh, lsr ip
-       mov     yl, xl, lsr ip
-       rsb     ip, ip, #32
- ARM(  orr     yl, yl, xh, lsl ip      )
- THUMB(        lsl     xh, xh, ip              )
- THUMB(        orr     yl, yl, xh              )
-       mov     xh, xl, lsl ip
-       mov     xh, xh, lsr ip
-       mov     pc, lr
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
 
-       @ eq -> division by 1: obvious enough...
-9:     moveq   yl, xl
-       moveq   yh, xh
-       moveq   xh, #0
-       moveq   pc, lr
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
 UNWIND(.fnend)
 
 UNWIND(.fnstart)
 UNWIND(.pad #4)
 UNWIND(.save {lr})
 Ldiv0_64:
-       @ Division by 0:
-       str     lr, [sp, #-8]!
-       bl      __div0
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
 
-       @ as wrong as it could be...
-       mov     yl, #0
-       mov     yh, #0
-       mov     xh, #0
-       ldr     pc, [sp], #8
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
 
 UNWIND(.fnend)
 ENDPROC(__do_div64)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/findbit.S
--- a/xen/arch/arm/lib/findbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/findbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -24,20 +24,20 @@
  * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
  */
 ENTRY(_find_first_zero_bit_le)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
 1:
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eors    r3, r3, #0xff           @ invert bits
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_zero_bit_le)
 
 /*
@@ -45,19 +45,19 @@ ENDPROC(_find_first_zero_bit_le)
  * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
  */
 ENTRY(_find_next_zero_bit_le)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eor     r3, r3, #0xff           @ now looking for a 1 bit
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_zero_bit_le)
 
 /*
@@ -65,20 +65,20 @@ ENDPROC(_find_next_zero_bit_le)
  * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
  */
 ENTRY(_find_first_bit_le)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
 1:
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_bit_le)
 
 /*
@@ -86,87 +86,87 @@ ENDPROC(_find_first_bit_le)
  * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
  */
 ENTRY(_find_next_bit_le)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
- ARM(          ldrb    r3, [r0, r2, lsr #3]    )
- THUMB(                lsr     r3, r2, #3              )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_bit_le)
 
 #ifdef __ARMEB__
 
 ENTRY(_find_first_zero_bit_be)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
-1:             eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eors    r3, r3, #0xff           @ invert bits
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_zero_bit_be)
 
 ENTRY(_find_next_zero_bit_be)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
-               eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               eor     r3, r3, #0xff           @ now looking for a 1 bit
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_zero_bit_be)
 
 ENTRY(_find_first_bit_be)
-               teq     r1, #0
-               beq     3f
-               mov     r2, #0
-1:             eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3
-               bne     .L_found                @ any now set - found zero bit
-               add     r2, r2, #8              @ next bit pointer
-2:             cmp     r2, r1                  @ any more?
-               blo     1b
-3:             mov     r0, r1                  @ no free bits
-               mov     pc, lr
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
 ENDPROC(_find_first_bit_be)
 
 ENTRY(_find_next_bit_be)
-               teq     r1, #0
-               beq     3b
-               ands    ip, r2, #7
-               beq     1b                      @ If new byte, goto old routine
-               eor     r3, r2, #0x18           @ big endian byte ordering
- ARM(          ldrb    r3, [r0, r3, lsr #3]    )
- THUMB(                lsr     r3, #3                  )
- THUMB(                ldrb    r3, [r0, r3]            )
-               movs    r3, r3, lsr ip          @ shift off unused bits
-               bne     .L_found
-               orr     r2, r2, #7              @ if zero, then no bits here
-               add     r2, r2, #1              @ align bit pointer
-               b       2b                      @ loop for next bit
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
 ENDPROC(_find_next_bit_be)
 
 #endif
@@ -176,23 +176,23 @@ ENDPROC(_find_next_bit_be)
  */
 .L_found:
 #if __LINUX_ARM_ARCH__ >= 5
-               rsb     r0, r3, #0
-               and     r3, r3, r0
-               clz     r3, r3
-               rsb     r3, r3, #31
-               add     r0, r2, r3
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
 #else
-               tst     r3, #0x0f
-               addeq   r2, r2, #4
-               movne   r3, r3, lsl #4
-               tst     r3, #0x30
-               addeq   r2, r2, #2
-               movne   r3, r3, lsl #2
-               tst     r3, #0x40
-               addeq   r2, r2, #1
-               mov     r0, r2
+		tst	r3, #0x0f
+		addeq	r2, r2, #4
+		movne	r3, r3, lsl #4
+		tst	r3, #0x30
+		addeq	r2, r2, #2
+		movne	r3, r3, lsl #2
+		tst	r3, #0x40
+		addeq	r2, r2, #1
+		mov	r0, r2
 #endif
-               cmp     r1, r0                  @ Clamp to maxbit
-               movlo   r0, r1
-               mov     pc, lr
+		cmp	r1, r0			@ Clamp to maxbit
+		movlo	r0, r1
+		mov	pc, lr
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/lib1funcs.S
--- a/xen/arch/arm/lib/lib1funcs.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/lib1funcs.S	Mon Feb 13 17:26:08 2012 +0000
@@ -40,64 +40,64 @@ Boston, MA 02111-1307, USA.  */
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     \curbit, \divisor
-       clz     \result, \dividend
-       sub     \result, \curbit, \result
-       mov     \curbit, #1
-       mov     \divisor, \divisor, lsl \result
-       mov     \curbit, \curbit, lsl \result
-       mov     \result, #0
-
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
 #else
 
-       @ Initially shift the divisor left 3 bits if possible,
-       @ set curbit accordingly.  This allows for curbit to be located
-       @ at the left end of each 4 bit nibbles in the division loop
-       @ to save one loop in most cases.
-       tst     \divisor, #0xe0000000
-       moveq   \divisor, \divisor, lsl #3
-       moveq   \curbit, #8
-       movne   \curbit, #1
+	@ Initially shift the divisor left 3 bits if possible,
+	@ set curbit accordingly.  This allows for curbit to be located
+	@ at the left end of each 4 bit nibbles in the division loop
+	@ to save one loop in most cases.
+	tst	\divisor, #0xe0000000
+	moveq	\divisor, \divisor, lsl #3
+	moveq	\curbit, #8
+	movne	\curbit, #1
 
-       @ Unless the divisor is very big, shift it up in multiples of
-       @ four bits, since this is the amount of unwinding in the main
-       @ division loop.  Continue shifting until the divisor is
-       @ larger than the dividend.
-1:     cmp     \divisor, #0x10000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #4
-       movlo   \curbit, \curbit, lsl #4
-       blo     1b
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	movlo	\curbit, \curbit, lsl #4
+	blo	1b
 
-       @ For very big divisors, we must shift it a bit at a time, or
-       @ we will be in danger of overflowing.
-1:     cmp     \divisor, #0x80000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #1
-       movlo   \curbit, \curbit, lsl #1
-       blo     1b
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	movlo	\curbit, \curbit, lsl #1
+	blo	1b
 
-       mov     \result, #0
+	mov	\result, #0
 
 #endif
 
-       @ Division loop
-1:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       orrhs   \result,   \result,   \curbit
-       cmp     \dividend, \divisor,  lsr #1
-       subhs   \dividend, \dividend, \divisor, lsr #1
-       orrhs   \result,   \result,   \curbit,  lsr #1
-       cmp     \dividend, \divisor,  lsr #2
-       subhs   \dividend, \dividend, \divisor, lsr #2
-       orrhs   \result,   \result,   \curbit,  lsr #2
-       cmp     \dividend, \divisor,  lsr #3
-       subhs   \dividend, \dividend, \divisor, lsr #3
-       orrhs   \result,   \result,   \curbit,  lsr #3
-       cmp     \dividend, #0                   @ Early termination?
-       movnes  \curbit,   \curbit,  lsr #4     @ No, any more bits to do?
-       movne   \divisor,  \divisor, lsr #4
-       bne     1b
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
 
 .endm
 
@@ -106,27 +106,27 @@ 1:     cmp     \dividend, \divisor
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     \order, \divisor
-       rsb     \order, \order, #31
+	clz	\order, \divisor
+	rsb	\order, \order, #31
 
 #else
 
-       cmp     \divisor, #(1 << 16)
-       movhs   \divisor, \divisor, lsr #16
-       movhs   \order, #16
-       movlo   \order, #0
+	cmp	\divisor, #(1 << 16)
+	movhs	\divisor, \divisor, lsr #16
+	movhs	\order, #16
+	movlo	\order, #0
 
-       cmp     \divisor, #(1 << 8)
-       movhs   \divisor, \divisor, lsr #8
-       addhs   \order, \order, #8
+	cmp	\divisor, #(1 << 8)
+	movhs	\divisor, \divisor, lsr #8
+	addhs	\order, \order, #8
 
-       cmp     \divisor, #(1 << 4)
-       movhs   \divisor, \divisor, lsr #4
-       addhs   \order, \order, #4
+	cmp	\divisor, #(1 << 4)
+	movhs	\divisor, \divisor, lsr #4
+	addhs	\order, \order, #4
 
-       cmp     \divisor, #(1 << 2)
-       addhi   \order, \order, #3
-       addls   \order, \order, \divisor, lsr #1
+	cmp	\divisor, #(1 << 2)
+	addhi	\order, \order, #3
+	addls	\order, \order, \divisor, lsr #1
 
 #endif
 
@@ -137,69 +137,69 @@ 1:     cmp     \dividend, \divisor
 
 #if __LINUX_ARM_ARCH__ >= 5
 
-       clz     \order, \divisor
-       clz     \spare, \dividend
-       sub     \order, \order, \spare
-       mov     \divisor, \divisor, lsl \order
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
 
 #else
 
-       mov     \order, #0
+	mov	\order, #0
 
-       @ Unless the divisor is very big, shift it up in multiples of
-       @ four bits, since this is the amount of unwinding in the main
-       @ division loop.  Continue shifting until the divisor is
-       @ larger than the dividend.
-1:     cmp     \divisor, #0x10000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #4
-       addlo   \order, \order, #4
-       blo     1b
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	addlo	\order, \order, #4
+	blo	1b
 
-       @ For very big divisors, we must shift it a bit at a time, or
-       @ we will be in danger of overflowing.
-1:     cmp     \divisor, #0x80000000
-       cmplo   \divisor, \dividend
-       movlo   \divisor, \divisor, lsl #1
-       addlo   \order, \order, #1
-       blo     1b
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	addlo	\order, \order, #1
+	blo	1b
 
 #endif
 
-       @ Perform all needed substractions to keep only the reminder.
-       @ Do comparisons in batch of 4 first.
-       subs    \order, \order, #3              @ yes, 3 is intended here
-       blt     2f
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
 
-1:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       cmp     \dividend, \divisor,  lsr #1
-       subhs   \dividend, \dividend, \divisor, lsr #1
-       cmp     \dividend, \divisor,  lsr #2
-       subhs   \dividend, \dividend, \divisor, lsr #2
-       cmp     \dividend, \divisor,  lsr #3
-       subhs   \dividend, \dividend, \divisor, lsr #3
-       cmp     \dividend, #1
-       mov     \divisor, \divisor, lsr #4
-       subges  \order, \order, #4
-       bge     1b
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	cmp	\dividend, #1
+	mov	\divisor, \divisor, lsr #4
+	subges	\order, \order, #4
+	bge	1b
 
-       tst     \order, #3
-       teqne   \dividend, #0
-       beq     5f
+	tst	\order, #3
+	teqne	\dividend, #0
+	beq	5f
 
-       @ Either 1, 2 or 3 comparison/substractions are left.
-2:     cmn     \order, #2
-       blt     4f
-       beq     3f
-       cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       mov     \divisor,  \divisor,  lsr #1
-3:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
-       mov     \divisor,  \divisor,  lsr #1
-4:     cmp     \dividend, \divisor
-       subhs   \dividend, \dividend, \divisor
+	@ Either 1, 2 or 3 comparison/substractions are left.
+2:	cmn	\order, #2
+	blt	4f
+	beq	3f
+	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+3:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	mov	\divisor,  \divisor,  lsr #1
+4:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
 5:
 .endm
 
@@ -208,27 +208,27 @@ ENTRY(__udivsi3)
 ENTRY(__aeabi_uidiv)
 UNWIND(.fnstart)
 
-       subs    r2, r1, #1
-       moveq   pc, lr
-       bcc     Ldiv0
-       cmp     r0, r1
-       bls     11f
-       tst     r1, r2
-       beq     12f
+	subs	r2, r1, #1
+	moveq	pc, lr
+	bcc	Ldiv0
+	cmp	r0, r1
+	bls	11f
+	tst	r1, r2
+	beq	12f
 
-       ARM_DIV_BODY r0, r1, r2, r3
+	ARM_DIV_BODY r0, r1, r2, r3
 
-       mov     r0, r2
-       mov     pc, lr
+	mov	r0, r2
+	mov	pc, lr
 
-11:    moveq   r0, #1
-       movne   r0, #0
-       mov     pc, lr
+11:	moveq	r0, #1
+	movne	r0, #0
+	mov	pc, lr
 
-12:    ARM_DIV2_ORDER r1, r2
+12:	ARM_DIV2_ORDER r1, r2
 
-       mov     r0, r0, lsr r2
-       mov     pc, lr
+	mov	r0, r0, lsr r2
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__udivsi3)
@@ -237,17 +237,17 @@ ENDPROC(__aeabi_uidiv)
 ENTRY(__umodsi3)
 UNWIND(.fnstart)
 
-       subs    r2, r1, #1                      @ compare divisor with 1
-       bcc     Ldiv0
-       cmpne   r0, r1                          @ compare dividend with divisor
-       moveq   r0, #0
-       tsthi   r1, r2                          @ see if divisor is power of 2
-       andeq   r0, r0, r2
-       movls   pc, lr
+	subs	r2, r1, #1			@ compare divisor with 1
+	bcc	Ldiv0
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq   r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	movls	pc, lr
 
-       ARM_MOD_BODY r0, r1, r2, r3
+	ARM_MOD_BODY r0, r1, r2, r3
 
-       mov     pc, lr
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__umodsi3)
@@ -256,40 +256,40 @@ ENTRY(__divsi3)
 ENTRY(__aeabi_idiv)
 UNWIND(.fnstart)
 
-       cmp     r1, #0
-       eor     ip, r0, r1                      @ save the sign of the result.
-       beq     Ldiv0
-       rsbmi   r1, r1, #0                      @ loops below use unsigned.
-       subs    r2, r1, #1                      @ division by 1 or -1 ?
-       beq     10f
-       movs    r3, r0
-       rsbmi   r3, r0, #0                      @ positive dividend value
-       cmp     r3, r1
-       bls     11f
-       tst     r1, r2                          @ divisor is power of 2 ?
-       beq     12f
+	cmp	r1, #0
+	eor	ip, r0, r1			@ save the sign of the result.
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	subs	r2, r1, #1			@ division by 1 or -1 ?
+	beq	10f
+	movs	r3, r0
+	rsbmi	r3, r0, #0			@ positive dividend value
+	cmp	r3, r1
+	bls	11f
+	tst	r1, r2				@ divisor is power of 2 ?
+	beq	12f
 
-       ARM_DIV_BODY r3, r1, r0, r2
+	ARM_DIV_BODY r3, r1, r0, r2
 
-       cmp     ip, #0
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
-10:    teq     ip, r0                          @ same sign ?
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+10:	teq	ip, r0				@ same sign ?
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
-11:    movlo   r0, #0
-       moveq   r0, ip, asr #31
-       orreq   r0, r0, #1
-       mov     pc, lr
+11:	movlo	r0, #0
+	moveq	r0, ip, asr #31
+	orreq	r0, r0, #1
+	mov	pc, lr
 
-12:    ARM_DIV2_ORDER r1, r2
+12:	ARM_DIV2_ORDER r1, r2
 
-       cmp     ip, #0
-       mov     r0, r3, lsr r2
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+	cmp	ip, #0
+	mov	r0, r3, lsr r2
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__divsi3)
@@ -298,23 +298,23 @@ ENDPROC(__aeabi_idiv)
 ENTRY(__modsi3)
 UNWIND(.fnstart)
 
-       cmp     r1, #0
-       beq     Ldiv0
-       rsbmi   r1, r1, #0                      @ loops below use unsigned.
-       movs    ip, r0                          @ preserve sign of dividend
-       rsbmi   r0, r0, #0                      @ if negative make positive
-       subs    r2, r1, #1                      @ compare divisor with 1
-       cmpne   r0, r1                          @ compare dividend with divisor
-       moveq   r0, #0
-       tsthi   r1, r2                          @ see if divisor is power of 2
-       andeq   r0, r0, r2
-       bls     10f
+	cmp	r1, #0
+	beq	Ldiv0
+	rsbmi	r1, r1, #0			@ loops below use unsigned.
+	movs	ip, r0				@ preserve sign of dividend
+	rsbmi	r0, r0, #0			@ if negative make positive
+	subs	r2, r1, #1			@ compare divisor with 1
+	cmpne	r0, r1				@ compare dividend with divisor
+	moveq	r0, #0
+	tsthi	r1, r2				@ see if divisor is power of 2
+	andeq	r0, r0, r2
+	bls	10f
 
-       ARM_MOD_BODY r0, r1, r2, r3
+	ARM_MOD_BODY r0, r1, r2, r3
 
-10:    cmp     ip, #0
-       rsbmi   r0, r0, #0
-       mov     pc, lr
+10:	cmp	ip, #0
+	rsbmi	r0, r0, #0
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__modsi3)
@@ -323,56 +323,56 @@ ENDPROC(__modsi3)
 
 ENTRY(__aeabi_uidivmod)
 UNWIND(.fnstart)
-UNWIND(.save {r0, r1, ip, lr}  )
+UNWIND(.save {r0, r1, ip, lr}	)
 
-       stmfd   sp!, {r0, r1, ip, lr}
-       bl      __aeabi_uidiv
-       ldmfd   sp!, {r1, r2, ip, lr}
-       mul     r3, r0, r2
-       sub     r1, r1, r3
-       mov     pc, lr
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_uidiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__aeabi_uidivmod)
 
 ENTRY(__aeabi_idivmod)
 UNWIND(.fnstart)
-UNWIND(.save {r0, r1, ip, lr}  )
-       stmfd   sp!, {r0, r1, ip, lr}
-       bl      __aeabi_idiv
-       ldmfd   sp!, {r1, r2, ip, lr}
-       mul     r3, r0, r2
-       sub     r1, r1, r3
-       mov     pc, lr
+UNWIND(.save {r0, r1, ip, lr}	)
+	stmfd	sp!, {r0, r1, ip, lr}
+	bl	__aeabi_idiv
+	ldmfd	sp!, {r1, r2, ip, lr}
+	mul	r3, r0, r2
+	sub	r1, r1, r3
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__aeabi_idivmod)
 
 ENTRY(__aeabi_uldivmod)
 UNWIND(.fnstart)
-UNWIND(.save {lr}      )
-       sub sp, sp, #8
-       stmfd   sp!, {sp, lr}
-       bl __qdivrem
-       ldr lr, [sp, #4]
-       add sp, sp, #8
-       ldmfd sp!, {r2, r3}
-       mov     pc, lr
+UNWIND(.save {lr}	)
+	sub sp, sp, #8
+	stmfd   sp!, {sp, lr}
+	bl __qdivrem
+	ldr lr, [sp, #4]
+	add sp, sp, #8
+	ldmfd sp!, {r2, r3}
+	mov	pc, lr
 
 UNWIND(.fnend)
 ENDPROC(__aeabi_uldivmod)
 
 ENTRY(__aeabi_ldivmod)
 UNWIND(.fnstart)
-UNWIND(.save {lr}      )
-       sub sp, sp, #16
-       stmfd   sp!, {sp, lr}
-       bl __ldivmod_helper
-       ldr lr, [sp, #4]
-       add sp, sp, #16
-       ldmfd   sp!, {r2, r3}
-       mov     pc, lr
-
+UNWIND(.save {lr}	)
+	sub sp, sp, #16
+	stmfd   sp!, {sp, lr}
+	bl __ldivmod_helper
+	ldr lr, [sp, #4]
+	add sp, sp, #16
+	ldmfd	sp!, {r2, r3}
+	mov	pc, lr
+	
 UNWIND(.fnend)
 ENDPROC(__aeabi_ldivmod)
 #endif
@@ -381,9 +381,9 @@ Ldiv0:
 UNWIND(.fnstart)
 UNWIND(.pad #4)
 UNWIND(.save {lr})
-       str     lr, [sp, #-8]!
-       bl      __div0
-       mov     r0, #0                  @ About as wrong as it could be.
-       ldr     pc, [sp], #8
+	str	lr, [sp, #-8]!
+	bl	__div0
+	mov	r0, #0			@ About as wrong as it could be.
+	ldr	pc, [sp], #8
 UNWIND(.fnend)
 ENDPROC(Ldiv0)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memcpy.S
--- a/xen/arch/arm/lib/memcpy.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memcpy.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,9 +1,9 @@
 /*
  *  linux/arch/arm/lib/memcpy.S
  *
- *  Author:    Nicolas Pitre
- *  Created:   Sep 28, 2005
- *  Copyright: MontaVista Software, Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	MontaVista Software, Inc.
  *
  *  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
@@ -13,46 +13,46 @@
 #include <xen/config.h>
 #include "assembler.h"
 
-#define LDR1W_SHIFT    0
-#define STR1W_SHIFT    0
+#define LDR1W_SHIFT	0
+#define STR1W_SHIFT	0
 
-       .macro ldr1w ptr reg abort
-       W(ldr) \reg, [\ptr], #4
-       .endm
+	.macro ldr1w ptr reg abort
+	W(ldr) \reg, [\ptr], #4
+	.endm
 
-       .macro ldr4w ptr reg1 reg2 reg3 reg4 abort
-       ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
-       .endm
+	.macro ldr4w ptr reg1 reg2 reg3 reg4 abort
+	ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4}
+	.endm
 
-       .macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
-       ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
-       .endm
+	.macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+	ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+	.endm
 
-       .macro ldr1b ptr reg cond=al abort
-       ldr\cond\()b \reg, [\ptr], #1
-       .endm
+	.macro ldr1b ptr reg cond=al abort
+	ldr\cond\()b \reg, [\ptr], #1
+	.endm
 
-       .macro str1w ptr reg abort
-       W(str) \reg, [\ptr], #4
-       .endm
+	.macro str1w ptr reg abort
+	W(str) \reg, [\ptr], #4
+	.endm
 
-       .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
-       stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
-       .endm
+	.macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
+	stmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8}
+	.endm
 
-       .macro str1b ptr reg cond=al abort
-       str\cond\()b \reg, [\ptr], #1
-       .endm
+	.macro str1b ptr reg cond=al abort
+	str\cond\()b \reg, [\ptr], #1
+	.endm
 
-       .macro enter reg1 reg2
-       stmdb sp!, {r0, \reg1, \reg2}
-       .endm
+	.macro enter reg1 reg2
+	stmdb sp!, {r0, \reg1, \reg2}
+	.endm
 
-       .macro exit reg1 reg2
-       ldmfd sp!, {r0, \reg1, \reg2}
-       .endm
+	.macro exit reg1 reg2
+	ldmfd sp!, {r0, \reg1, \reg2}
+	.endm
 
-       .text
+	.text
 
 /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memmove.S
--- a/xen/arch/arm/lib/memmove.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memmove.S	Mon Feb 13 17:26:08 2012 +0000
@@ -1,9 +1,9 @@
 /*
  *  linux/arch/arm/lib/memmove.S
  *
- *  Author:    Nicolas Pitre
- *  Created:   Sep 28, 2005
- *  Copyright: (C) MontaVista Software Inc.
+ *  Author:	Nicolas Pitre
+ *  Created:	Sep 28, 2005
+ *  Copyright:	(C) MontaVista Software Inc.
  *
  *  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
@@ -14,7 +14,7 @@
 
 #include "assembler.h"
 
-               .text
+		.text
 
 /*
  * Prototype: void *memmove(void *dest, const void *src, size_t n);
@@ -29,172 +29,172 @@
 
 ENTRY(memmove)
 
-               subs    ip, r0, r1
-               cmphi   r2, ip
-               bls     memcpy
+		subs	ip, r0, r1
+		cmphi	r2, ip
+		bls	memcpy
 
-               stmfd   sp!, {r0, r4, lr}
-               add     r1, r1, r2
-               add     r0, r0, r2
-               subs    r2, r2, #4
-               blt     8f
-               ands    ip, r0, #3
-       PLD(    pld     [r1, #-4]               )
-               bne     9f
-               ands    ip, r1, #3
-               bne     10f
+		stmfd	sp!, {r0, r4, lr}
+		add	r1, r1, r2
+		add	r0, r0, r2
+		subs	r2, r2, #4
+		blt	8f
+		ands	ip, r0, #3
+	PLD(	pld	[r1, #-4]		)
+		bne	9f
+		ands	ip, r1, #3
+		bne	10f
 
-1:             subs    r2, r2, #(28)
-               stmfd   sp!, {r5 - r8}
-               blt     5f
+1:		subs	r2, r2, #(28)
+		stmfd	sp!, {r5 - r8}
+		blt	5f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  sbcnes  r4, ip, r2              )  @ C is always set here
-       CALGN(  bcs     2f                      )
-       CALGN(  adr     r4, 6f                  )
-       CALGN(  subs    r2, r2, ip              )  @ C is set here
-       CALGN(  rsb     ip, ip, #32             )
-       CALGN(  add     pc, r4, ip              )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	bcs	2f			)
+	CALGN(	adr	r4, 6f			)
+	CALGN(	subs	r2, r2, ip		)  @ C is set here
+	CALGN(	rsb	ip, ip, #32		)
+	CALGN(	add	pc, r4, ip		)
 
-       PLD(    pld     [r1, #-4]               )
-2:     PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #-32]              )
-       PLD(    blt     4f                      )
-       PLD(    pld     [r1, #-64]              )
-       PLD(    pld     [r1, #-96]              )
+	PLD(	pld	[r1, #-4]		)
+2:	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	4f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
 
-3:     PLD(    pld     [r1, #-128]             )
-4:             ldmdb   r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
-               subs    r2, r2, #32
-               stmdb   r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
-               bge     3b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     4b                      )
+3:	PLD(	pld	[r1, #-128]		)
+4:		ldmdb	r1!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		subs	r2, r2, #32
+		stmdb	r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
+		bge	3b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	4b			)
 
-5:             ands    ip, r2, #28
-               rsb     ip, ip, #32
-               addne   pc, pc, ip              @ C is always clear here
-               b       7f
-6:             W(nop)
-               W(ldr)  r3, [r1, #-4]!
-               W(ldr)  r4, [r1, #-4]!
-               W(ldr)  r5, [r1, #-4]!
-               W(ldr)  r6, [r1, #-4]!
-               W(ldr)  r7, [r1, #-4]!
-               W(ldr)  r8, [r1, #-4]!
-               W(ldr)  lr, [r1, #-4]!
+5:		ands	ip, r2, #28
+		rsb	ip, ip, #32
+		addne	pc, pc, ip		@ C is always clear here
+		b	7f
+6:		W(nop)
+		W(ldr)	r3, [r1, #-4]!
+		W(ldr)	r4, [r1, #-4]!
+		W(ldr)	r5, [r1, #-4]!
+		W(ldr)	r6, [r1, #-4]!
+		W(ldr)	r7, [r1, #-4]!
+		W(ldr)	r8, [r1, #-4]!
+		W(ldr)	lr, [r1, #-4]!
 
-               add     pc, pc, ip
-               nop
-               W(nop)
-               W(str)  r3, [r0, #-4]!
-               W(str)  r4, [r0, #-4]!
-               W(str)  r5, [r0, #-4]!
-               W(str)  r6, [r0, #-4]!
-               W(str)  r7, [r0, #-4]!
-               W(str)  r8, [r0, #-4]!
-               W(str)  lr, [r0, #-4]!
+		add	pc, pc, ip
+		nop
+		W(nop)
+		W(str)	r3, [r0, #-4]!
+		W(str)	r4, [r0, #-4]!
+		W(str)	r5, [r0, #-4]!
+		W(str)	r6, [r0, #-4]!
+		W(str)	r7, [r0, #-4]!
+		W(str)	r8, [r0, #-4]!
+		W(str)	lr, [r0, #-4]!
 
-       CALGN(  bcs     2b                      )
+	CALGN(	bcs	2b			)
 
-7:             ldmfd   sp!, {r5 - r8}
+7:		ldmfd	sp!, {r5 - r8}
 
-8:             movs    r2, r2, lsl #31
-               ldrneb  r3, [r1, #-1]!
-               ldrcsb  r4, [r1, #-1]!
-               ldrcsb  ip, [r1, #-1]
-               strneb  r3, [r0, #-1]!
-               strcsb  r4, [r0, #-1]!
-               strcsb  ip, [r0, #-1]
-               ldmfd   sp!, {r0, r4, pc}
+8:		movs	r2, r2, lsl #31
+		ldrneb	r3, [r1, #-1]!
+		ldrcsb	r4, [r1, #-1]!
+		ldrcsb	ip, [r1, #-1]
+		strneb	r3, [r0, #-1]!
+		strcsb	r4, [r0, #-1]!
+		strcsb	ip, [r0, #-1]
+		ldmfd	sp!, {r0, r4, pc}
 
-9:             cmp     ip, #2
-               ldrgtb  r3, [r1, #-1]!
-               ldrgeb  r4, [r1, #-1]!
-               ldrb    lr, [r1, #-1]!
-               strgtb  r3, [r0, #-1]!
-               strgeb  r4, [r0, #-1]!
-               subs    r2, r2, ip
-               strb    lr, [r0, #-1]!
-               blt     8b
-               ands    ip, r1, #3
-               beq     1b
+9:		cmp	ip, #2
+		ldrgtb	r3, [r1, #-1]!
+		ldrgeb	r4, [r1, #-1]!
+		ldrb	lr, [r1, #-1]!
+		strgtb	r3, [r0, #-1]!
+		strgeb	r4, [r0, #-1]!
+		subs	r2, r2, ip
+		strb	lr, [r0, #-1]!
+		blt	8b
+		ands	ip, r1, #3
+		beq	1b
 
-10:            bic     r1, r1, #3
-               cmp     ip, #2
-               ldr     r3, [r1, #0]
-               beq     17f
-               blt     18f
+10:		bic	r1, r1, #3
+		cmp	ip, #2
+		ldr	r3, [r1, #0]
+		beq	17f
+		blt	18f
 
 
-               .macro  backward_copy_shift push pull
+		.macro	backward_copy_shift push pull
 
-               subs    r2, r2, #28
-               blt     14f
+		subs	r2, r2, #28
+		blt	14f
 
-       CALGN(  ands    ip, r0, #31             )
-       CALGN(  sbcnes  r4, ip, r2              )  @ C is always set here
-       CALGN(  subcc   r2, r2, ip              )
-       CALGN(  bcc     15f                     )
+	CALGN(	ands	ip, r0, #31		)
+	CALGN(	sbcnes	r4, ip, r2		)  @ C is always set here
+	CALGN(	subcc	r2, r2, ip		)
+	CALGN(	bcc	15f			)
 
-11:            stmfd   sp!, {r5 - r9}
+11:		stmfd	sp!, {r5 - r9}
 
-       PLD(    pld     [r1, #-4]               )
-       PLD(    subs    r2, r2, #96             )
-       PLD(    pld     [r1, #-32]              )
-       PLD(    blt     13f                     )
-       PLD(    pld     [r1, #-64]              )
-       PLD(    pld     [r1, #-96]              )
+	PLD(	pld	[r1, #-4]		)
+	PLD(	subs	r2, r2, #96		)
+	PLD(	pld	[r1, #-32]		)
+	PLD(	blt	13f			)
+	PLD(	pld	[r1, #-64]		)
+	PLD(	pld	[r1, #-96]		)
 
-12:    PLD(    pld     [r1, #-128]             )
-13:            ldmdb   r1!, {r7, r8, r9, ip}
-               mov     lr, r3, push #\push
-               subs    r2, r2, #32
-               ldmdb   r1!, {r3, r4, r5, r6}
-               orr     lr, lr, ip, pull #\pull
-               mov     ip, ip, push #\push
-               orr     ip, ip, r9, pull #\pull
-               mov     r9, r9, push #\push
-               orr     r9, r9, r8, pull #\pull
-               mov     r8, r8, push #\push
-               orr     r8, r8, r7, pull #\pull
-               mov     r7, r7, push #\push
-               orr     r7, r7, r6, pull #\pull
-               mov     r6, r6, push #\push
-               orr     r6, r6, r5, pull #\pull
-               mov     r5, r5, push #\push
-               orr     r5, r5, r4, pull #\pull
-               mov     r4, r4, push #\push
-               orr     r4, r4, r3, pull #\pull
-               stmdb   r0!, {r4 - r9, ip, lr}
-               bge     12b
-       PLD(    cmn     r2, #96                 )
-       PLD(    bge     13b                     )
+12:	PLD(	pld	[r1, #-128]		)
+13:		ldmdb   r1!, {r7, r8, r9, ip}
+		mov     lr, r3, push #\push
+		subs    r2, r2, #32
+		ldmdb   r1!, {r3, r4, r5, r6}
+		orr     lr, lr, ip, pull #\pull
+		mov     ip, ip, push #\push
+		orr     ip, ip, r9, pull #\pull
+		mov     r9, r9, push #\push
+		orr     r9, r9, r8, pull #\pull
+		mov     r8, r8, push #\push
+		orr     r8, r8, r7, pull #\pull
+		mov     r7, r7, push #\push
+		orr     r7, r7, r6, pull #\pull
+		mov     r6, r6, push #\push
+		orr     r6, r6, r5, pull #\pull
+		mov     r5, r5, push #\push
+		orr     r5, r5, r4, pull #\pull
+		mov     r4, r4, push #\push
+		orr     r4, r4, r3, pull #\pull
+		stmdb   r0!, {r4 - r9, ip, lr}
+		bge	12b
+	PLD(	cmn	r2, #96			)
+	PLD(	bge	13b			)
 
-               ldmfd   sp!, {r5 - r9}
+		ldmfd	sp!, {r5 - r9}
 
-14:            ands    ip, r2, #28
-               beq     16f
+14:		ands	ip, r2, #28
+		beq	16f
 
-15:            mov     lr, r3, push #\push
-               ldr     r3, [r1, #-4]!
-               subs    ip, ip, #4
-               orr     lr, lr, r3, pull #\pull
-               str     lr, [r0, #-4]!
-               bgt     15b
-       CALGN(  cmp     r2, #0                  )
-       CALGN(  bge     11b                     )
+15:		mov     lr, r3, push #\push
+		ldr	r3, [r1, #-4]!
+		subs	ip, ip, #4
+		orr	lr, lr, r3, pull #\pull
+		str	lr, [r0, #-4]!
+		bgt	15b
+	CALGN(	cmp	r2, #0			)
+	CALGN(	bge	11b			)
 
-16:            add     r1, r1, #(\pull / 8)
-               b       8b
+16:		add	r1, r1, #(\pull / 8)
+		b	8b
 
-               .endm
+		.endm
 
 
-               backward_copy_shift     push=8  pull=24
+		backward_copy_shift	push=8	pull=24
 
-17:            backward_copy_shift     push=16 pull=16
+17:		backward_copy_shift	push=16	pull=16
 
-18:            backward_copy_shift     push=24 pull=8
+18:		backward_copy_shift	push=24	pull=8
 
 ENDPROC(memmove)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memset.S
--- a/xen/arch/arm/lib/memset.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memset.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,33 +14,33 @@
 
 #include "assembler.h"
 
-       .text
-       .align  5
-       .word   0
+	.text
+	.align	5
+	.word	0
 
-1:     subs    r2, r2, #4              @ 1 do we have enough
-       blt     5f                      @ 1 bytes to align with?
-       cmp     r3, #2                  @ 1
-       strltb  r1, [r0], #1            @ 1
-       strleb  r1, [r0], #1            @ 1
-       strb    r1, [r0], #1            @ 1
-       add     r2, r2, r3              @ 1 (r2 = r2 - (4 - r3))
+1:	subs	r2, r2, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r1, [r0], #1		@ 1
+	strleb	r1, [r0], #1		@ 1
+	strb	r1, [r0], #1		@ 1
+	add	r2, r2, r3		@ 1 (r2 = r2 - (4 - r3))
 /*
  * The pointer is now aligned and the length is adjusted.  Try doing the
  * memset again.
  */
 
 ENTRY(memset)
-       ands    r3, r0, #3              @ 1 unaligned?
-       bne     1b                      @ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
 /*
  * we know that the pointer in r0 is aligned to a word boundary.
  */
-       orr     r1, r1, r1, lsl #8
-       orr     r1, r1, r1, lsl #16
-       mov     r3, r1
-       cmp     r2, #16
-       blt     4f
+	orr	r1, r1, r1, lsl #8
+	orr	r1, r1, r1, lsl #16
+	mov	r3, r1
+	cmp	r2, #16
+	blt	4f
 
 #if ! CALGN(1)+0
 
@@ -48,26 +48,26 @@ ENTRY(memset)
  * We need an extra register for this loop - save the return address and
  * use the LR
  */
-       str     lr, [sp, #-4]!
-       mov     ip, r1
-       mov     lr, r1
+	str	lr, [sp, #-4]!
+	mov	ip, r1
+	mov	lr, r1
 
-2:     subs    r2, r2, #64
-       stmgeia r0!, {r1, r3, ip, lr}   @ 64 bytes at a time.
-       stmgeia r0!, {r1, r3, ip, lr}
-       stmgeia r0!, {r1, r3, ip, lr}
-       stmgeia r0!, {r1, r3, ip, lr}
-       bgt     2b
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+2:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3, ip, lr}	@ 64 bytes at a time.
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	stmgeia	r0!, {r1, r3, ip, lr}
+	bgt	2b
+	ldmeqfd	sp!, {pc}		@ Now <64 bytes to go.
 /*
  * No need to correct the count; we're only testing bits from now on
  */
-       tst     r2, #32
-       stmneia r0!, {r1, r3, ip, lr}
-       stmneia r0!, {r1, r3, ip, lr}
-       tst     r2, #16
-       stmneia r0!, {r1, r3, ip, lr}
-       ldr     lr, [sp], #4
+	tst	r2, #32
+	stmneia	r0!, {r1, r3, ip, lr}
+	stmneia	r0!, {r1, r3, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r1, r3, ip, lr}
+	ldr	lr, [sp], #4
 
 #else
 
@@ -76,54 +76,54 @@ 2:     subs    r2, r2, #64
  * whole cache lines at once.
  */
 
-       stmfd   sp!, {r4-r7, lr}
-       mov     r4, r1
-       mov     r5, r1
-       mov     r6, r1
-       mov     r7, r1
-       mov     ip, r1
-       mov     lr, r1
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r1
+	mov	r5, r1
+	mov	r6, r1
+	mov	r7, r1
+	mov	ip, r1
+	mov	lr, r1
 
-       cmp     r2, #96
-       tstgt   r0, #31
-       ble     3f
+	cmp	r2, #96
+	tstgt	r0, #31
+	ble	3f
 
-       and     ip, r0, #31
-       rsb     ip, ip, #32
-       sub     r2, r2, ip
-       movs    ip, ip, lsl #(32 - 4)
-       stmcsia r0!, {r4, r5, r6, r7}
-       stmmiia r0!, {r4, r5}
-       tst     ip, #(1 << 30)
-       mov     ip, r1
-       strne   r1, [r0], #4
+	and	ip, r0, #31
+	rsb	ip, ip, #32
+	sub	r2, r2, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	tst	ip, #(1 << 30)
+	mov	ip, r1
+	strne	r1, [r0], #4
 
-3:     subs    r2, r2, #64
-       stmgeia r0!, {r1, r3-r7, ip, lr}
-       stmgeia r0!, {r1, r3-r7, ip, lr}
-       bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+3:	subs	r2, r2, #64
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	stmgeia	r0!, {r1, r3-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
 
-       tst     r2, #32
-       stmneia r0!, {r1, r3-r7, ip, lr}
-       tst     r2, #16
-       stmneia r0!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+	tst	r2, #32
+	stmneia	r0!, {r1, r3-r7, ip, lr}
+	tst	r2, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
 
 #endif
 
-4:     tst     r2, #8
-       stmneia r0!, {r1, r3}
-       tst     r2, #4
-       strne   r1, [r0], #4
+4:	tst	r2, #8
+	stmneia	r0!, {r1, r3}
+	tst	r2, #4
+	strne	r1, [r0], #4
 /*
  * When we get here, we've got less than 4 bytes to zero.  We
  * may have an unaligned pointer as well.
  */
-5:     tst     r2, #2
-       strneb  r1, [r0], #1
-       strneb  r1, [r0], #1
-       tst     r2, #1
-       strneb  r1, [r0], #1
-       mov     pc, lr
+5:	tst	r2, #2
+	strneb	r1, [r0], #1
+	strneb	r1, [r0], #1
+	tst	r2, #1
+	strneb	r1, [r0], #1
+	mov	pc, lr
 ENDPROC(memset)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/memzero.S
--- a/xen/arch/arm/lib/memzero.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/memzero.S	Mon Feb 13 17:26:08 2012 +0000
@@ -12,35 +12,35 @@
 
 #include "assembler.h"
 
-       .text
-       .align  5
-       .word   0
+	.text
+	.align	5
+	.word	0
 /*
  * Align the pointer in r0.  r3 contains the number of bytes that we are
  * mis-aligned by, and r1 is the number of bytes.  If r1 < 4, then we
  * don't bother; we use byte stores instead.
  */
-1:     subs    r1, r1, #4              @ 1 do we have enough
-       blt     5f                      @ 1 bytes to align with?
-       cmp     r3, #2                  @ 1
-       strltb  r2, [r0], #1            @ 1
-       strleb  r2, [r0], #1            @ 1
-       strb    r2, [r0], #1            @ 1
-       add     r1, r1, r3              @ 1 (r1 = r1 - (4 - r3))
+1:	subs	r1, r1, #4		@ 1 do we have enough
+	blt	5f			@ 1 bytes to align with?
+	cmp	r3, #2			@ 1
+	strltb	r2, [r0], #1		@ 1
+	strleb	r2, [r0], #1		@ 1
+	strb	r2, [r0], #1		@ 1
+	add	r1, r1, r3		@ 1 (r1 = r1 - (4 - r3))
 /*
  * The pointer is now aligned and the length is adjusted.  Try doing the
  * memzero again.
  */
 
 ENTRY(__memzero)
-       mov     r2, #0                  @ 1
-       ands    r3, r0, #3              @ 1 unaligned?
-       bne     1b                      @ 1
+	mov	r2, #0			@ 1
+	ands	r3, r0, #3		@ 1 unaligned?
+	bne	1b			@ 1
 /*
  * r3 = 0, and we know that the pointer in r0 is aligned to a word boundary.
  */
-       cmp     r1, #16                 @ 1 we can skip this chunk if we
-       blt     4f                      @ 1 have < 16 bytes
+	cmp	r1, #16			@ 1 we can skip this chunk if we
+	blt	4f			@ 1 have < 16 bytes
 
 #if ! CALGN(1)+0
 
@@ -48,26 +48,26 @@ ENTRY(__memzero)
  * We need an extra register for this loop - save the return address and
  * use the LR
  */
-       str     lr, [sp, #-4]!          @ 1
-       mov     ip, r2                  @ 1
-       mov     lr, r2                  @ 1
+	str	lr, [sp, #-4]!		@ 1
+	mov	ip, r2			@ 1
+	mov	lr, r2			@ 1
 
-3:     subs    r1, r1, #64             @ 1 write 32 bytes out per loop
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       stmgeia r0!, {r2, r3, ip, lr}   @ 4
-       bgt     3b                      @ 1
-       ldmeqfd sp!, {pc}               @ 1/2 quick exit
+3:	subs	r1, r1, #64		@ 1 write 32 bytes out per loop
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	stmgeia	r0!, {r2, r3, ip, lr}	@ 4
+	bgt	3b			@ 1
+	ldmeqfd	sp!, {pc}		@ 1/2 quick exit
 /*
  * No need to correct the count; we're only testing bits from now on
  */
-       tst     r1, #32                 @ 1
-       stmneia r0!, {r2, r3, ip, lr}   @ 4
-       stmneia r0!, {r2, r3, ip, lr}   @ 4
-       tst     r1, #16                 @ 1 16 bytes or more?
-       stmneia r0!, {r2, r3, ip, lr}   @ 4
-       ldr     lr, [sp], #4            @ 1
+	tst	r1, #32			@ 1
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	tst	r1, #16			@ 1 16 bytes or more?
+	stmneia	r0!, {r2, r3, ip, lr}	@ 4
+	ldr	lr, [sp], #4		@ 1
 
 #else
 
@@ -76,52 +76,52 @@ 3:     subs    r1, r1, #64             @
  * whole cache lines at once.
  */
 
-       stmfd   sp!, {r4-r7, lr}
-       mov     r4, r2
-       mov     r5, r2
-       mov     r6, r2
-       mov     r7, r2
-       mov     ip, r2
-       mov     lr, r2
+	stmfd	sp!, {r4-r7, lr}
+	mov	r4, r2
+	mov	r5, r2
+	mov	r6, r2
+	mov	r7, r2
+	mov	ip, r2
+	mov	lr, r2
 
-       cmp     r1, #96
-       andgts  ip, r0, #31
-       ble     3f
+	cmp	r1, #96
+	andgts	ip, r0, #31
+	ble	3f
 
-       rsb     ip, ip, #32
-       sub     r1, r1, ip
-       movs    ip, ip, lsl #(32 - 4)
-       stmcsia r0!, {r4, r5, r6, r7}
-       stmmiia r0!, {r4, r5}
-       movs    ip, ip, lsl #2
-       strcs   r2, [r0], #4
+	rsb	ip, ip, #32
+	sub	r1, r1, ip
+	movs	ip, ip, lsl #(32 - 4)
+	stmcsia	r0!, {r4, r5, r6, r7}
+	stmmiia	r0!, {r4, r5}
+	movs	ip, ip, lsl #2
+	strcs	r2, [r0], #4
 
-3:     subs    r1, r1, #64
-       stmgeia r0!, {r2-r7, ip, lr}
-       stmgeia r0!, {r2-r7, ip, lr}
-       bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+3:	subs	r1, r1, #64
+	stmgeia	r0!, {r2-r7, ip, lr}
+	stmgeia	r0!, {r2-r7, ip, lr}
+	bgt	3b
+	ldmeqfd	sp!, {r4-r7, pc}
 
-       tst     r1, #32
-       stmneia r0!, {r2-r7, ip, lr}
-       tst     r1, #16
-       stmneia r0!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+	tst	r1, #32
+	stmneia	r0!, {r2-r7, ip, lr}
+	tst	r1, #16
+	stmneia	r0!, {r4-r7}
+	ldmfd	sp!, {r4-r7, lr}
 
 #endif
 
-4:     tst     r1, #8                  @ 1 8 bytes or more?
-       stmneia r0!, {r2, r3}           @ 2
-       tst     r1, #4                  @ 1 4 bytes or more?
-       strne   r2, [r0], #4            @ 1
+4:	tst	r1, #8			@ 1 8 bytes or more?
+	stmneia	r0!, {r2, r3}		@ 2
+	tst	r1, #4			@ 1 4 bytes or more?
+	strne	r2, [r0], #4		@ 1
 /*
  * When we get here, we've got less than 4 bytes to zero.  We
  * may have an unaligned pointer as well.
  */
-5:     tst     r1, #2                  @ 1 2 bytes or more?
-       strneb  r2, [r0], #1            @ 1
-       strneb  r2, [r0], #1            @ 1
-       tst     r1, #1                  @ 1 a byte left over
-       strneb  r2, [r0], #1            @ 1
-       mov     pc, lr                  @ 1
+5:	tst	r1, #2			@ 1 2 bytes or more?
+	strneb	r2, [r0], #1		@ 1
+	strneb	r2, [r0], #1		@ 1
+	tst	r1, #1			@ 1 a byte left over
+	strneb	r2, [r0], #1		@ 1
+	mov	pc, lr			@ 1
 ENDPROC(__memzero)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/setbit.S
--- a/xen/arch/arm/lib/setbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/setbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -11,8 +11,8 @@
 
 #include "assembler.h"
 #include "bitops.h"
-       .text
+	.text
 
 ENTRY(_set_bit)
-       bitop   orr
+	bitop	orr
 ENDPROC(_set_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/testchangebit.S
--- a/xen/arch/arm/lib/testchangebit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/testchangebit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_test_and_change_bit)
-       testop  eor, str
+	testop	eor, str
 ENDPROC(_test_and_change_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/testclearbit.S
--- a/xen/arch/arm/lib/testclearbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/testclearbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_test_and_clear_bit)
-       testop  bicne, strne
+	testop	bicne, strne
 ENDPROC(_test_and_clear_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/lib/testsetbit.S
--- a/xen/arch/arm/lib/testsetbit.S	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/arch/arm/lib/testsetbit.S	Mon Feb 13 17:26:08 2012 +0000
@@ -14,5 +14,5 @@
                 .text
 
 ENTRY(_test_and_set_bit)
-       testop  orreq, streq
+	testop	orreq, streq
 ENDPROC(_test_and_set_bit)
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/include/asm-arm/bitops.h
--- a/xen/include/asm-arm/bitops.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/include/asm-arm/bitops.h	Mon Feb 13 17:26:08 2012 +0000
@@ -115,19 +115,19 @@ extern int _find_next_bit_be(const unsig
 /*
  * These are the little endian, atomic definitions.
  */
-#define find_first_zero_bit(p,sz)      _find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off)   _find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz)           _find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off)                _find_next_bit_le(p,sz,off)
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
 
 #else
 /*
  * These are the big endian, atomic definitions.
  */
-#define find_first_zero_bit(p,sz)      _find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off)   _find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz)           _find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off)                _find_next_bit_be(p,sz,off)
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
 
 #endif
 
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/include/asm-arm/div64.h
--- a/xen/include/asm-arm/div64.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/include/asm-arm/div64.h	Mon Feb 13 17:26:08 2012 +0000
@@ -10,9 +10,9 @@
  *
  * uint32_t do_div(uint64_t *n, uint32_t base)
  * {
- *     uint32_t remainder = *n % base;
- *     *n = *n / base;
- *     return remainder;
+ * 	uint32_t remainder = *n % base;
+ * 	*n = *n / base;
+ * 	return remainder;
  * }
  *
  * In other words, a 64-bit dividend with a 32-bit divisor producing
@@ -29,22 +29,22 @@
 #define __xh "r1"
 #endif
 
-#define __do_div_asm(n, base)                                  \
-({                                                             \
-       register unsigned int __base      asm("r4") = base;     \
-       register unsigned long long __n   asm("r0") = n;        \
-       register unsigned long long __res asm("r2");            \
-       register unsigned int __rem       asm(__xh);            \
-       asm(    __asmeq("%0", __xh)                             \
-               __asmeq("%1", "r2")                             \
-               __asmeq("%2", "r0")                             \
-               __asmeq("%3", "r4")                             \
-               "bl     __do_div64"                             \
-               : "=r" (__rem), "=r" (__res)                    \
-               : "r" (__n), "r" (__base)                       \
-               : "ip", "lr", "cc");                            \
-       n = __res;                                              \
-       __rem;                                                  \
+#define __do_div_asm(n, base)					\
+({								\
+	register unsigned int __base      asm("r4") = base;	\
+	register unsigned long long __n   asm("r0") = n;	\
+	register unsigned long long __res asm("r2");		\
+	register unsigned int __rem       asm(__xh);		\
+	asm(	__asmeq("%0", __xh)				\
+		__asmeq("%1", "r2")				\
+		__asmeq("%2", "r0")				\
+		__asmeq("%3", "r4")				\
+		"bl	__do_div64"				\
+		: "=r" (__rem), "=r" (__res)			\
+		: "r" (__n), "r" (__base)			\
+		: "ip", "lr", "cc");				\
+	n = __res;						\
+	__rem;							\
 })
 
 #if __GNUC__ < 4
@@ -71,155 +71,155 @@
  * sufficiently recent to perform proper long long constant propagation.
  * (It is unfortunate that gcc doesn't perform all this internally.)
  */
-#define do_div(n, base)                                                        \
-({                                                                     \
-       unsigned int __r, __b = (base);                                 \
-       if (!__builtin_constant_p(__b) || __b == 0) {                   \
-               /* non-constant divisor (or zero): slow path */         \
-               __r = __do_div_asm(n, __b);                             \
-       } else if ((__b & (__b - 1)) == 0) {                            \
-               /* Trivial: __b is constant and a power of 2 */         \
-               /* gcc does the right thing with this code.  */         \
-               __r = n;                                                \
-               __r &= (__b - 1);                                       \
-               n /= __b;                                               \
-       } else {                                                        \
-               /* Multiply by inverse of __b: n/b = n*(p/b)/p       */ \
-               /* We rely on the fact that most of this code gets   */ \
-               /* optimized away at compile time due to constant    */ \
-               /* propagation and only a couple inline assembly     */ \
-               /* instructions should remain. Better avoid any      */ \
-               /* code construct that might prevent that.           */ \
-               unsigned long long __res, __x, __t, __m, __n = n;       \
-               unsigned int __c, __p, __z = 0;                         \
-               /* preserve low part of n for reminder computation */   \
-               __r = __n;                                              \
-               /* determine number of bits to represent __b */         \
-               __p = 1 << __div64_fls(__b);                            \
-               /* compute __m = ((__p << 64) + __b - 1) / __b */       \
-               __m = (~0ULL / __b) * __p;                              \
-               __m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;     \
-               /* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */ \
-               __x = ~0ULL / __b * __b - 1;                            \
-               __res = (__m & 0xffffffff) * (__x & 0xffffffff);        \
-               __res >>= 32;                                           \
-               __res += (__m & 0xffffffff) * (__x >> 32);              \
-               __t = __res;                                            \
-               __res += (__x & 0xffffffff) * (__m >> 32);              \
-               __t = (__res < __t) ? (1ULL << 32) : 0;                 \
-               __res = (__res >> 32) + __t;                            \
-               __res += (__m >> 32) * (__x >> 32);                     \
-               __res /= __p;                                           \
-               /* Now sanitize and optimize what we've got. */         \
-               if (~0ULL % (__b / (__b & -__b)) == 0) {                \
-                       /* those cases can be simplified with: */       \
-                       __n /= (__b & -__b);                            \
-                       __m = ~0ULL / (__b / (__b & -__b));             \
-                       __p = 1;                                        \
-                       __c = 1;                                        \
-               } else if (__res != __x / __b) {                        \
-                       /* We can't get away without a correction    */ \
-                       /* to compensate for bit truncation errors.  */ \
-                       /* To avoid it we'd need an additional bit   */ \
-                       /* to represent __m which would overflow it. */ \
-                       /* Instead we do m=p/b and n/b=(n*m+m)/p.    */ \
-                       __c = 1;                                        \
-                       /* Compute __m = (__p << 64) / __b */           \
-                       __m = (~0ULL / __b) * __p;                      \
-                       __m += ((~0ULL % __b + 1) * __p) / __b;         \
-               } else {                                                \
-                       /* Reduce __m/__p, and try to clear bit 31   */ \
-                       /* of __m when possible otherwise that'll    */ \
-                       /* need extra overflow handling later.       */ \
-                       unsigned int __bits = -(__m & -__m);            \
-                       __bits |= __m >> 32;                            \
-                       __bits = (~__bits) << 1;                        \
-                       /* If __bits == 0 then setting bit 31 is     */ \
-                       /* unavoidable.  Simply apply the maximum    */ \
-                       /* possible reduction in that case.          */ \
-                       /* Otherwise the MSB of __bits indicates the */ \
-                       /* best reduction we should apply.           */ \
-                       if (!__bits) {                                  \
-                               __p /= (__m & -__m);                    \
-                               __m /= (__m & -__m);                    \
-                       } else {                                        \
-                               __p >>= __div64_fls(__bits);            \
-                               __m >>= __div64_fls(__bits);            \
-                       }                                               \
-                       /* No correction needed. */                     \
-                       __c = 0;                                        \
-               }                                                       \
-               /* Now we have a combination of 2 conditions:        */ \
-               /* 1) whether or not we need a correction (__c), and */ \
-               /* 2) whether or not there might be an overflow in   */ \
-               /*    the cross product (__m & ((1<<63) | (1<<31)))  */ \
-               /* Select the best insn combination to perform the   */ \
-               /* actual __m * __n / (__p << 64) operation.         */ \
-               if (!__c) {                                             \
-                       asm (   "umull  %Q0, %R0, %1, %Q2\n\t"          \
-                               "mov    %Q0, #0"                        \
-                               : "=&r" (__res)                         \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               } else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {    \
-                       __res = __m;                                    \
-                       asm (   "umlal  %Q0, %R0, %Q1, %Q2\n\t"         \
-                               "mov    %Q0, #0"                        \
-                               : "+&r" (__res)                         \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               } else {                                                \
-                       asm (   "umull  %Q0, %R0, %Q1, %Q2\n\t"         \
-                               "cmn    %Q0, %Q1\n\t"                   \
-                               "adcs   %R0, %R0, %R1\n\t"              \
-                               "adc    %Q0, %3, #0"                    \
-                               : "=&r" (__res)                         \
-                               : "r" (__m), "r" (__n), "r" (__z)       \
-                               : "cc" );                               \
-               }                                                       \
-               if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {           \
-                       asm (   "umlal  %R0, %Q0, %R1, %Q2\n\t"         \
-                               "umlal  %R0, %Q0, %Q1, %R2\n\t"         \
-                               "mov    %R0, #0\n\t"                    \
-                               "umlal  %Q0, %R0, %R1, %R2"             \
-                               : "+&r" (__res)                         \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               } else {                                                \
-                       asm (   "umlal  %R0, %Q0, %R2, %Q3\n\t"         \
-                               "umlal  %R0, %1, %Q2, %R3\n\t"          \
-                               "mov    %R0, #0\n\t"                    \
-                               "adds   %Q0, %1, %Q0\n\t"               \
-                               "adc    %R0, %R0, #0\n\t"               \
-                               "umlal  %Q0, %R0, %R2, %R3"             \
-                               : "+&r" (__res), "+&r" (__z)            \
-                               : "r" (__m), "r" (__n)                  \
-                               : "cc" );                               \
-               }                                                       \
-               __res /= __p;                                           \
-               /* The reminder can be computed with 32-bit regs     */ \
-               /* only, and gcc is good at that.                    */ \
-               {                                                       \
-                       unsigned int __res0 = __res;                    \
-                       unsigned int __b0 = __b;                        \
-                       __r -= __res0 * __b0;                           \
-               }                                                       \
-               /* BUG_ON(__r >= __b || __res * __b + __r != n); */     \
-               n = __res;                                              \
-       }                                                               \
-       __r;                                                            \
+#define do_div(n, base)							\
+({									\
+	unsigned int __r, __b = (base);					\
+	if (!__builtin_constant_p(__b) || __b == 0) {			\
+		/* non-constant divisor (or zero): slow path */		\
+		__r = __do_div_asm(n, __b);				\
+	} else if ((__b & (__b - 1)) == 0) {				\
+		/* Trivial: __b is constant and a power of 2 */		\
+		/* gcc does the right thing with this code.  */		\
+		__r = n;						\
+		__r &= (__b - 1);					\
+		n /= __b;						\
+	} else {							\
+		/* Multiply by inverse of __b: n/b = n*(p/b)/p       */	\
+		/* We rely on the fact that most of this code gets   */	\
+		/* optimized away at compile time due to constant    */	\
+		/* propagation and only a couple inline assembly     */	\
+		/* instructions should remain. Better avoid any      */	\
+		/* code construct that might prevent that.           */	\
+		unsigned long long __res, __x, __t, __m, __n = n;	\
+		unsigned int __c, __p, __z = 0;				\
+		/* preserve low part of n for reminder computation */	\
+		__r = __n;						\
+		/* determine number of bits to represent __b */		\
+		__p = 1 << __div64_fls(__b);				\
+		/* compute __m = ((__p << 64) + __b - 1) / __b */	\
+		__m = (~0ULL / __b) * __p;				\
+		__m += (((~0ULL % __b + 1) * __p) + __b - 1) / __b;	\
+		/* compute __res = __m*(~0ULL/__b*__b-1)/(__p << 64) */	\
+		__x = ~0ULL / __b * __b - 1;				\
+		__res = (__m & 0xffffffff) * (__x & 0xffffffff);	\
+		__res >>= 32;						\
+		__res += (__m & 0xffffffff) * (__x >> 32);		\
+		__t = __res;						\
+		__res += (__x & 0xffffffff) * (__m >> 32);		\
+		__t = (__res < __t) ? (1ULL << 32) : 0;			\
+		__res = (__res >> 32) + __t;				\
+		__res += (__m >> 32) * (__x >> 32);			\
+		__res /= __p;						\
+		/* Now sanitize and optimize what we've got. */		\
+		if (~0ULL % (__b / (__b & -__b)) == 0) {		\
+			/* those cases can be simplified with: */	\
+			__n /= (__b & -__b);				\
+			__m = ~0ULL / (__b / (__b & -__b));		\
+			__p = 1;					\
+			__c = 1;					\
+		} else if (__res != __x / __b) {			\
+			/* We can't get away without a correction    */	\
+			/* to compensate for bit truncation errors.  */	\
+			/* To avoid it we'd need an additional bit   */	\
+			/* to represent __m which would overflow it. */	\
+			/* Instead we do m=p/b and n/b=(n*m+m)/p.    */	\
+			__c = 1;					\
+			/* Compute __m = (__p << 64) / __b */		\
+			__m = (~0ULL / __b) * __p;			\
+			__m += ((~0ULL % __b + 1) * __p) / __b;		\
+		} else {						\
+			/* Reduce __m/__p, and try to clear bit 31   */	\
+			/* of __m when possible otherwise that'll    */	\
+			/* need extra overflow handling later.       */	\
+			unsigned int __bits = -(__m & -__m);		\
+			__bits |= __m >> 32;				\
+			__bits = (~__bits) << 1;			\
+			/* If __bits == 0 then setting bit 31 is     */	\
+			/* unavoidable.  Simply apply the maximum    */	\
+			/* possible reduction in that case.          */	\
+			/* Otherwise the MSB of __bits indicates the */	\
+			/* best reduction we should apply.           */	\
+			if (!__bits) {					\
+				__p /= (__m & -__m);			\
+				__m /= (__m & -__m);			\
+			} else {					\
+				__p >>= __div64_fls(__bits);		\
+				__m >>= __div64_fls(__bits);		\
+			}						\
+			/* No correction needed. */			\
+			__c = 0;					\
+		}							\
+		/* Now we have a combination of 2 conditions:        */	\
+		/* 1) whether or not we need a correction (__c), and */	\
+		/* 2) whether or not there might be an overflow in   */	\
+		/*    the cross product (__m & ((1<<63) | (1<<31)))  */	\
+		/* Select the best insn combination to perform the   */	\
+		/* actual __m * __n / (__p << 64) operation.         */	\
+		if (!__c) {						\
+			asm (	"umull	%Q0, %R0, %1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {	\
+			__res = __m;					\
+			asm (	"umlal	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"mov	%Q0, #0"			\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umull	%Q0, %R0, %Q1, %Q2\n\t"		\
+				"cmn	%Q0, %Q1\n\t"			\
+				"adcs	%R0, %R0, %R1\n\t"		\
+				"adc	%Q0, %3, #0"			\
+				: "=&r" (__res)				\
+				: "r" (__m), "r" (__n), "r" (__z)	\
+				: "cc" );				\
+		}							\
+		if (!(__m & ((1ULL << 63) | (1ULL << 31)))) {		\
+			asm (	"umlal	%R0, %Q0, %R1, %Q2\n\t"		\
+				"umlal	%R0, %Q0, %Q1, %R2\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"umlal	%Q0, %R0, %R1, %R2"		\
+				: "+&r" (__res)				\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		} else {						\
+			asm (	"umlal	%R0, %Q0, %R2, %Q3\n\t"		\
+				"umlal	%R0, %1, %Q2, %R3\n\t"		\
+				"mov	%R0, #0\n\t"			\
+				"adds	%Q0, %1, %Q0\n\t"		\
+				"adc	%R0, %R0, #0\n\t"		\
+				"umlal	%Q0, %R0, %R2, %R3"		\
+				: "+&r" (__res), "+&r" (__z)		\
+				: "r" (__m), "r" (__n)			\
+				: "cc" );				\
+		}							\
+		__res /= __p;						\
+		/* The reminder can be computed with 32-bit regs     */	\
+		/* only, and gcc is good at that.                    */	\
+		{							\
+			unsigned int __res0 = __res;			\
+			unsigned int __b0 = __b;			\
+			__r -= __res0 * __b0;				\
+		}							\
+		/* BUG_ON(__r >= __b || __res * __b + __r != n); */	\
+		n = __res;						\
+	}								\
+	__r;								\
 })
 
 /* our own fls implementation to make sure constant propagation is fine */
-#define __div64_fls(bits)                                              \
-({                                                                     \
-       unsigned int __left = (bits), __nr = 0;                         \
-       if (__left & 0xffff0000) __nr += 16, __left >>= 16;             \
-       if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;             \
-       if (__left & 0x000000f0) __nr +=  4, __left >>=  4;             \
-       if (__left & 0x0000000c) __nr +=  2, __left >>=  2;             \
-       if (__left & 0x00000002) __nr +=  1;                            \
-       __nr;                                                           \
+#define __div64_fls(bits)						\
+({									\
+	unsigned int __left = (bits), __nr = 0;				\
+	if (__left & 0xffff0000) __nr += 16, __left >>= 16;		\
+	if (__left & 0x0000ff00) __nr +=  8, __left >>=  8;		\
+	if (__left & 0x000000f0) __nr +=  4, __left >>=  4;		\
+	if (__left & 0x0000000c) __nr +=  2, __left >>=  2;		\
+	if (__left & 0x00000002) __nr +=  1;				\
+	__nr;								\
 })
 
 #endif
diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/include/asm-arm/numa.h
--- a/xen/include/asm-arm/numa.h	Mon Feb 13 17:03:44 2012 +0000
+++ b/xen/include/asm-arm/numa.h	Mon Feb 13 17:26:08 2012 +0000
@@ -3,7 +3,7 @@
 
 /* Fake one node for now... */
 #define cpu_to_node(cpu) 0
-#define node_to_cpumask(node)  (cpu_online_map)
+#define node_to_cpumask(node)	(cpu_online_map)
 
 static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:18:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0TR-0004Qg-68; Mon, 13 Feb 2012 18:18:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rx0TQ-0004QF-1G
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:18:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329157074!14524247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1612 invoked from network); 13 Feb 2012 18:17:54 -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;
	13 Feb 2012 18:17:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10670035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 18:17:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 18:17:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rx0TJ-0002Nj-3u; Mon, 13 Feb 2012 18:17:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rx0TI-0002bY-It;
	Mon, 13 Feb 2012 18:17:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.21455.961953.271488@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 18:17:51 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F33A97C.3000500@amd.com>
References: <4F33A97C.3000500@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: fix qemu build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("[Xen-devel] [PATCH] tools: fix qemu build"):
> 
> Pass --python=$(PYTHON) to qemu's configure.
> Fixes error:
> Python not found. Use --python=/path/to/python
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:18:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18: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.xensource.com>)
	id 1Rx0TR-0004Qg-68; Mon, 13 Feb 2012 18:18:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rx0TQ-0004QF-1G
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:18:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329157074!14524247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1612 invoked from network); 13 Feb 2012 18:17:54 -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;
	13 Feb 2012 18:17:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="10670035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 18:17:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 18:17:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rx0TJ-0002Nj-3u; Mon, 13 Feb 2012 18:17:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rx0TI-0002bY-It;
	Mon, 13 Feb 2012 18:17:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20281.21455.961953.271488@mariner.uk.xensource.com>
Date: Mon, 13 Feb 2012 18:17:51 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F33A97C.3000500@amd.com>
References: <4F33A97C.3000500@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools: fix qemu build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("[Xen-devel] [PATCH] tools: fix qemu build"):
> 
> Pass --python=$(PYTHON) to qemu's configure.
> Fixes error:
> Python not found. Use --python=/path/to/python
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:26:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx0bs-00054B-7O; Mon, 13 Feb 2012 18:26:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rx0bq-000546-R2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:26:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329157595!14626552!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32155 invoked from network); 13 Feb 2012 18:26:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:26:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181544401"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:26:34 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	13:26:34 -0500
Message-ID: <4F3955D9.2020900@citrix.com>
Date: Mon, 13 Feb 2012 18:26:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
In-Reply-To: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
Cc: tim@xen.org, xen-devel@lists.xensource.com, stefano.stabellini@citrix.com,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/12 18:03, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329153968 0
> # Node ID 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
> # Parent  7fd8f10cfd3eaf9f0982eb6fd49334a1e229ba98
> arm: fixup hard tabs
> 
> Unfortunately the tool I was using to apply patches mangles hard tabs. This
> patch corrects this in the effected files (which is fortunately only a subset
> of .S or files imported from Linux)

No other file in the tree has tabs why should these?

Nak, unless your intention is to immediately apply a patch converting
tabs to 8 spaces.

Interestingly, the citrix email server apears to mangle tabs and replace
them with spaces (which made the copy of these patch I received via Cc
appear to do nothing at all). Perhaps this is where it went wrong
originally?

> "git diff" and "git diff -b" vs. Stefano's v6 branch now contain the same
> output -- i.e. only the intervening development

I don't think this is particularly useful long term.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/dtb.S
> --- a/xen/arch/arm/dtb.S	Mon Feb 13 17:03:44 2012 +0000
> +++ b/xen/arch/arm/dtb.S	Mon Feb 13 17:26:08 2012 +0000
> @@ -1,2 +1,2 @@
> -        .section .dtb,#alloc
> -        .incbin CONFIG_DTB_FILE
> +	.section .dtb,#alloc
> +	.incbin CONFIG_DTB_FILE

This was a new file that never had tabs anywhere. No need to mess about
with it.

> diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/entry.S
> --- a/xen/arch/arm/entry.S	Mon Feb 13 17:03:44 2012 +0000
> +++ b/xen/arch/arm/entry.S	Mon Feb 13 17:26:08 2012 +0000
[...
> -#define SAVE_ALL                                                                                       \
> -       sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */                                      \
> -       push {r0-r12}; /* Save R0-R12 */                                                                \
> -                                                                                                       \
> -       mrs r11, ELR_hyp;               /* ELR_hyp is return address. */                                \

While your messing with whitespace. How about moving that \ to below 80
columns.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:26:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18:26:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx0bs-00054B-7O; Mon, 13 Feb 2012 18:26:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Rx0bq-000546-R2
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:26:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329157595!14626552!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjM5NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32155 invoked from network); 13 Feb 2012 18:26:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 18:26:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,412,1325480400"; d="scan'208";a="181544401"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 13:26:34 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012
	13:26:34 -0500
Message-ID: <4F3955D9.2020900@citrix.com>
Date: Mon, 13 Feb 2012 18:26:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
In-Reply-To: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
Cc: tim@xen.org, xen-devel@lists.xensource.com, stefano.stabellini@citrix.com,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/02/12 18:03, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329153968 0
> # Node ID 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
> # Parent  7fd8f10cfd3eaf9f0982eb6fd49334a1e229ba98
> arm: fixup hard tabs
> 
> Unfortunately the tool I was using to apply patches mangles hard tabs. This
> patch corrects this in the effected files (which is fortunately only a subset
> of .S or files imported from Linux)

No other file in the tree has tabs why should these?

Nak, unless your intention is to immediately apply a patch converting
tabs to 8 spaces.

Interestingly, the citrix email server apears to mangle tabs and replace
them with spaces (which made the copy of these patch I received via Cc
appear to do nothing at all). Perhaps this is where it went wrong
originally?

> "git diff" and "git diff -b" vs. Stefano's v6 branch now contain the same
> output -- i.e. only the intervening development

I don't think this is particularly useful long term.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/dtb.S
> --- a/xen/arch/arm/dtb.S	Mon Feb 13 17:03:44 2012 +0000
> +++ b/xen/arch/arm/dtb.S	Mon Feb 13 17:26:08 2012 +0000
> @@ -1,2 +1,2 @@
> -        .section .dtb,#alloc
> -        .incbin CONFIG_DTB_FILE
> +	.section .dtb,#alloc
> +	.incbin CONFIG_DTB_FILE

This was a new file that never had tabs anywhere. No need to mess about
with it.

> diff -r 7fd8f10cfd3e -r 63e88a26e1ef xen/arch/arm/entry.S
> --- a/xen/arch/arm/entry.S	Mon Feb 13 17:03:44 2012 +0000
> +++ b/xen/arch/arm/entry.S	Mon Feb 13 17:26:08 2012 +0000
[...
> -#define SAVE_ALL                                                                                       \
> -       sub sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */                                      \
> -       push {r0-r12}; /* Save R0-R12 */                                                                \
> -                                                                                                       \
> -       mrs r11, ELR_hyp;               /* ELR_hyp is return address. */                                \

While your messing with whitespace. How about moving that \ to below 80
columns.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx0zv-0005OI-Dk; Mon, 13 Feb 2012 18:51: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 1Rx0zt-0005OD-3V
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:51:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329159039!54068974!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMzNTY2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17225 invoked from network); 13 Feb 2012 18:50:41 -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; 13 Feb 2012 18:50: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 q1DIpRDs018884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 13 Feb 2012 18:51:29 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
	q1DIpQu1001917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 13 Feb 2012 18:51:27 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1DIpQ4e015394; Mon, 13 Feb 2012 12:51:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 10:51:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D0EA4171F; Mon, 13 Feb 2012 13:48:27 -0500 (EST)
Date: Mon, 13 Feb 2012 13:48:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: yunjiedu <350608693@qq.com>
Message-ID: <20120213184827.GC29286@phenom.dumpdata.com>
References: <1328880882031-5472445.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328880882031-5472445.post@n5.nabble.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F395BB1.008C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, 2012 at 05:34:42AM -0800, yunjiedu wrote:
> Hi,all,
> 
> today,i use function printk() in file xen/arch/x86/mm/paging.c,but Where the
> output of printk() is stored (which log files)?I try to find,but without

xl dmesg

> results. Also is this output enabled by default ? If no, how to enable them?
> thanks
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/where-printk-output-tp5472445p5472445.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 18:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 18:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx0zv-0005OI-Dk; Mon, 13 Feb 2012 18:51: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 1Rx0zt-0005OD-3V
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 18:51:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329159039!54068974!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMzNTY2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17225 invoked from network); 13 Feb 2012 18:50:41 -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; 13 Feb 2012 18:50: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 q1DIpRDs018884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 13 Feb 2012 18:51:29 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
	q1DIpQu1001917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 13 Feb 2012 18:51:27 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1DIpQ4e015394; Mon, 13 Feb 2012 12:51:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 10:51:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D0EA4171F; Mon, 13 Feb 2012 13:48:27 -0500 (EST)
Date: Mon, 13 Feb 2012 13:48:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: yunjiedu <350608693@qq.com>
Message-ID: <20120213184827.GC29286@phenom.dumpdata.com>
References: <1328880882031-5472445.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328880882031-5472445.post@n5.nabble.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F395BB1.008C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 10, 2012 at 05:34:42AM -0800, yunjiedu wrote:
> Hi,all,
> 
> today,i use function printk() in file xen/arch/x86/mm/paging.c,but Where the
> output of printk() is stored (which log files)?I try to find,but without

xl dmesg

> results. Also is this output enabled by default ? If no, how to enable them?
> thanks
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/where-printk-output-tp5472445p5472445.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:10:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx1Hn-00063V-57; Mon, 13 Feb 2012 19:10:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rx1Hl-00063M-Vk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:10:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329160195!13791565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9857 invoked from network); 13 Feb 2012 19:09:55 -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;
	13 Feb 2012 19:09:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10670622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 19:09:55 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 19:09:54 +0000
Message-ID: <1329160194.8906.11.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 19:09:54 +0000
In-Reply-To: <4F3955D9.2020900@citrix.com>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
	<4F3955D9.2020900@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 18:26 +0000, David Vrabel wrote:
> On 13/02/12 18:03, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1329153968 0
> > # Node ID 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
> > # Parent  7fd8f10cfd3eaf9f0982eb6fd49334a1e229ba98
> > arm: fixup hard tabs
> > 
> > Unfortunately the tool I was using to apply patches mangles hard tabs. This
> > patch corrects this in the effected files (which is fortunately only a subset
> > of .S or files imported from Linux)

(note that the mangling resulted in _7_ space indentation, which is
worse than just about anything)

> 
> No other file in the tree has tabs why should these?
> 
> Nak, unless your intention is to immediately apply a patch converting
> tabs to 8 spaces.

My intention is to put the tree back into the state which reflects what
the original authors intended, that is what I was sent and what I would
have committed if my tools had not let me down. I am not going to do any
more or less than that.

I'm not really interested in debating the right style of indentation to
use in the context of this fixup patch. If you feel strongly about it
please follow up with a patch with the explicit purpose of changing the
_intended_ indentation.

> Interestingly, the citrix email server apears to mangle tabs and replace
> them with spaces (which made the copy of these patch I received via Cc
> appear to do nothing at all). Perhaps this is where it went wrong
> originally?

Quite possibly. I may need to investigate alternative ways of receiving
patches which I intend to apply if that turns out to be the case.

> > @@ -1,2 +1,2 @@
> > -        .section .dtb,#alloc
> > -        .incbin CONFIG_DTB_FILE
> > +	.section .dtb,#alloc
> > +	.incbin CONFIG_DTB_FILE
> 
> This was a new file that never had tabs anywhere. No need to mess about
> with it.

That being the case I'll drop this hunk.

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:10:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx1Hn-00063V-57; Mon, 13 Feb 2012 19:10:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rx1Hl-00063M-Vk
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:10:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329160195!13791565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9857 invoked from network); 13 Feb 2012 19:09:55 -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;
	13 Feb 2012 19:09:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10670622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 19:09:55 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 19:09:54 +0000
Message-ID: <1329160194.8906.11.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 13 Feb 2012 19:09:54 +0000
In-Reply-To: <4F3955D9.2020900@citrix.com>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
	<4F3955D9.2020900@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 18:26 +0000, David Vrabel wrote:
> On 13/02/12 18:03, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1329153968 0
> > # Node ID 63e88a26e1ef58c8e5a2b30a003ab7c3bc9c6b54
> > # Parent  7fd8f10cfd3eaf9f0982eb6fd49334a1e229ba98
> > arm: fixup hard tabs
> > 
> > Unfortunately the tool I was using to apply patches mangles hard tabs. This
> > patch corrects this in the effected files (which is fortunately only a subset
> > of .S or files imported from Linux)

(note that the mangling resulted in _7_ space indentation, which is
worse than just about anything)

> 
> No other file in the tree has tabs why should these?
> 
> Nak, unless your intention is to immediately apply a patch converting
> tabs to 8 spaces.

My intention is to put the tree back into the state which reflects what
the original authors intended, that is what I was sent and what I would
have committed if my tools had not let me down. I am not going to do any
more or less than that.

I'm not really interested in debating the right style of indentation to
use in the context of this fixup patch. If you feel strongly about it
please follow up with a patch with the explicit purpose of changing the
_intended_ indentation.

> Interestingly, the citrix email server apears to mangle tabs and replace
> them with spaces (which made the copy of these patch I received via Cc
> appear to do nothing at all). Perhaps this is where it went wrong
> originally?

Quite possibly. I may need to investigate alternative ways of receiving
patches which I intend to apply if that turns out to be the case.

> > @@ -1,2 +1,2 @@
> > -        .section .dtb,#alloc
> > -        .incbin CONFIG_DTB_FILE
> > +	.section .dtb,#alloc
> > +	.incbin CONFIG_DTB_FILE
> 
> This was a new file that never had tabs anywhere. No need to mess about
> with it.

That being the case I'll drop this hunk.

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:12:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx1Jo-00068D-UH; Mon, 13 Feb 2012 19:12:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rx1Jn-000684-5y
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:12:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329160318!13138620!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28582 invoked from network); 13 Feb 2012 19:12:00 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 19:12:00 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1DJBue7019197
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 11:11:57 -0800
Received: by bkcjg15 with SMTP id jg15so9351134bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 11:11:54 -0800 (PST)
Received: by 10.204.145.82 with SMTP id c18mr7397699bkv.121.1329160314431;
	Mon, 13 Feb 2012 11:11:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 13 Feb 2012 11:11:14 -0800 (PST)
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 13 Feb 2012 11:11:14 -0800
Message-ID: <CAP8mzPNoK+vvDUfz3Te5Xhj4JWk08aOUwTSjdieR+qDXHPMbjA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7049186934252878488=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7049186934252878488==
Content-Type: multipart/alternative; boundary=000e0cdfc7bc64276f04b8dd40cc

--000e0cdfc7bc64276f04b8dd40cc
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 13, 2012 at 2:17 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

>
> tools, nice to have:
>
>      * Hotplug script stuff -- internal to libxl (I think, therefore I
>        didn't put this under stable API above) but still good to have
>        for 4.2? (Roger Pau Monet, patches posted)
>      * Block script support -- follows on from hotplug script (Roger
>        Pau Monet)
>      * libyajl v2 support (Roger Pau Monet, DONE)
>      * Configure/control paging via xl/libxl (Olaf Herring)
>      * Upstream qemu feature patches:
>              * Upstream qemu PCI passthrough support (Anthony Perard)
>              * Upstream qemu save restore (Anthony Perard, Stefano
>                Stabellini)
>      * Nested-virtualisation (currently should be marked
>        experimental,likely to release that way? Consider nested-svm
>        separate to nested-vmx. Nested-svm is in better shape)
>      * Initial xl support for Remus (memory checkpoint, blackholing)
>        (Shriram, patches posted)
>
>


FYI, the network buffering module which was part of 2.6.32 pvops tree has
been accepted into upstream net-next tree. I have also posted patches for
the
userspace libnl code that talks to the qdiscs via netlink.

I am just waiting for the initial xl patches to go in, after which I could
take a stab
at adding network buffering support. Depending on whether Roger's hotplug
patches
go in or not, I could add some rudimentary disk replication support, time
permitting.

shriram

--000e0cdfc7bc64276f04b8dd40cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 13, 2012 at 2:17 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
tools, nice to have:<br>
<br>
 =A0 =A0 =A0* Hotplug script stuff -- internal to libxl (I think, therefore=
 I<br>
 =A0 =A0 =A0 =A0didn&#39;t put this under stable API above) but still good =
to have<br>
 =A0 =A0 =A0 =A0for 4.2? (Roger Pau Monet, patches posted)<br>
 =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger=
<br>
 =A0 =A0 =A0 =A0Pau Monet)<br>
 =A0 =A0 =A0* libyajl v2 support (Roger Pau Monet, DONE)<br>
 =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring)<br>
 =A0 =A0 =A0* Upstream qemu feature patches:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Anthon=
y Perard)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, S=
tefano<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini)<br>
 =A0 =A0 =A0* Nested-virtualisation (currently should be marked<br>
 =A0 =A0 =A0 =A0experimental,likely to release that way? Consider nested-sv=
m<br>
 =A0 =A0 =A0 =A0separate to nested-vmx. Nested-svm is in better shape)<br>
 =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)=
<br>
 =A0 =A0 =A0 =A0(Shriram, patches posted)<br>
<br></blockquote><div><br><br>
<br>
FYI, the network buffering module which was part of 2.6.32 pvops tree has<b=
r>
been accepted into upstream net-next tree. I have also posted patches for t=
he<br>
userspace libnl code that talks to the qdiscs via netlink.<br>
<br>
I am just waiting for the initial xl patches to go in, after which I could =
take a stab<br>
at adding network buffering support. Depending on whether Roger&#39;s hotpl=
ug patches<br>
go in or not, I could add some rudimentary disk replication support, time p=
ermitting.<br>=A0<br></div></div>shriram<br>

--000e0cdfc7bc64276f04b8dd40cc--


--===============7049186934252878488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7049186934252878488==--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:12:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx1Jo-00068D-UH; Mon, 13 Feb 2012 19:12:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rx1Jn-000684-5y
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:12:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329160318!13138620!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28582 invoked from network); 13 Feb 2012 19:12:00 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2012 19:12:00 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1DJBue7019197
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 11:11:57 -0800
Received: by bkcjg15 with SMTP id jg15so9351134bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 11:11:54 -0800 (PST)
Received: by 10.204.145.82 with SMTP id c18mr7397699bkv.121.1329160314431;
	Mon, 13 Feb 2012 11:11:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 13 Feb 2012 11:11:14 -0800 (PST)
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 13 Feb 2012 11:11:14 -0800
Message-ID: <CAP8mzPNoK+vvDUfz3Te5Xhj4JWk08aOUwTSjdieR+qDXHPMbjA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7049186934252878488=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7049186934252878488==
Content-Type: multipart/alternative; boundary=000e0cdfc7bc64276f04b8dd40cc

--000e0cdfc7bc64276f04b8dd40cc
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 13, 2012 at 2:17 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

>
> tools, nice to have:
>
>      * Hotplug script stuff -- internal to libxl (I think, therefore I
>        didn't put this under stable API above) but still good to have
>        for 4.2? (Roger Pau Monet, patches posted)
>      * Block script support -- follows on from hotplug script (Roger
>        Pau Monet)
>      * libyajl v2 support (Roger Pau Monet, DONE)
>      * Configure/control paging via xl/libxl (Olaf Herring)
>      * Upstream qemu feature patches:
>              * Upstream qemu PCI passthrough support (Anthony Perard)
>              * Upstream qemu save restore (Anthony Perard, Stefano
>                Stabellini)
>      * Nested-virtualisation (currently should be marked
>        experimental,likely to release that way? Consider nested-svm
>        separate to nested-vmx. Nested-svm is in better shape)
>      * Initial xl support for Remus (memory checkpoint, blackholing)
>        (Shriram, patches posted)
>
>


FYI, the network buffering module which was part of 2.6.32 pvops tree has
been accepted into upstream net-next tree. I have also posted patches for
the
userspace libnl code that talks to the qdiscs via netlink.

I am just waiting for the initial xl patches to go in, after which I could
take a stab
at adding network buffering support. Depending on whether Roger's hotplug
patches
go in or not, I could add some rudimentary disk replication support, time
permitting.

shriram

--000e0cdfc7bc64276f04b8dd40cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 13, 2012 at 2:17 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
tools, nice to have:<br>
<br>
 =A0 =A0 =A0* Hotplug script stuff -- internal to libxl (I think, therefore=
 I<br>
 =A0 =A0 =A0 =A0didn&#39;t put this under stable API above) but still good =
to have<br>
 =A0 =A0 =A0 =A0for 4.2? (Roger Pau Monet, patches posted)<br>
 =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger=
<br>
 =A0 =A0 =A0 =A0Pau Monet)<br>
 =A0 =A0 =A0* libyajl v2 support (Roger Pau Monet, DONE)<br>
 =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring)<br>
 =A0 =A0 =A0* Upstream qemu feature patches:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Anthon=
y Perard)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, S=
tefano<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini)<br>
 =A0 =A0 =A0* Nested-virtualisation (currently should be marked<br>
 =A0 =A0 =A0 =A0experimental,likely to release that way? Consider nested-sv=
m<br>
 =A0 =A0 =A0 =A0separate to nested-vmx. Nested-svm is in better shape)<br>
 =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)=
<br>
 =A0 =A0 =A0 =A0(Shriram, patches posted)<br>
<br></blockquote><div><br><br>
<br>
FYI, the network buffering module which was part of 2.6.32 pvops tree has<b=
r>
been accepted into upstream net-next tree. I have also posted patches for t=
he<br>
userspace libnl code that talks to the qdiscs via netlink.<br>
<br>
I am just waiting for the initial xl patches to go in, after which I could =
take a stab<br>
at adding network buffering support. Depending on whether Roger&#39;s hotpl=
ug patches<br>
go in or not, I could add some rudimentary disk replication support, time p=
ermitting.<br>=A0<br></div></div>shriram<br>

--000e0cdfc7bc64276f04b8dd40cc--


--===============7049186934252878488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7049186934252878488==--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:40:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx1kR-0006oE-Rq; Mon, 13 Feb 2012 19:39:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rx1kQ-0006o8-1R
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:39:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329161971!2603290!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30554 invoked from network); 13 Feb 2012 19:39:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 19:39:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rx1kI-000P7N-Bv; Mon, 13 Feb 2012 19:39:30 +0000
Date: Mon, 13 Feb 2012 19:39:30 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120213193930.GA96441@ocelot.phlegethon.org>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
	<4F3955D9.2020900@citrix.com>
	<1329160194.8906.11.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329160194.8906.11.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:09 +0000 on 13 Feb (1329160194), Ian Campbell wrote:
> (note that the mangling resulted in _7_ space indentation, which is
> worse than just about anything)
> 
> > No other file in the tree has tabs why should these?
> > 
> > Nak, unless your intention is to immediately apply a patch converting
> > tabs to 8 spaces.

We really ought to take this - the current state is both accidental and
nonsensical. 

That said, for head.S, which is the only place I've introduced tabs, I'm
happy to have the whole file converted to (8) spaces if you also fix the
emacs runes at the foot of the file to DTRT.

For asm code taken from linux, have we already mangled them enough
that applying upstream fixes would be hard?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:40:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx1kR-0006oE-Rq; Mon, 13 Feb 2012 19:39:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rx1kQ-0006o8-1R
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:39:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329161971!2603290!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30554 invoked from network); 13 Feb 2012 19:39:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2012 19:39:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rx1kI-000P7N-Bv; Mon, 13 Feb 2012 19:39:30 +0000
Date: Mon, 13 Feb 2012 19:39:30 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120213193930.GA96441@ocelot.phlegethon.org>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
	<4F3955D9.2020900@citrix.com>
	<1329160194.8906.11.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329160194.8906.11.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:09 +0000 on 13 Feb (1329160194), Ian Campbell wrote:
> (note that the mangling resulted in _7_ space indentation, which is
> worse than just about anything)
> 
> > No other file in the tree has tabs why should these?
> > 
> > Nak, unless your intention is to immediately apply a patch converting
> > tabs to 8 spaces.

We really ought to take this - the current state is both accidental and
nonsensical. 

That said, for head.S, which is the only place I've introduced tabs, I'm
happy to have the whole file converted to (8) spaces if you also fix the
emacs runes at the foot of the file to DTRT.

For asm code taken from linux, have we already mangled them enough
that applying upstream fixes would be hard?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19: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.xensource.com>)
	id 1Rx1xD-0007GL-7D; Mon, 13 Feb 2012 19:52: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 1Rx1xA-0007G9-SF
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:52:49 +0000
Received: from [85.158.143.35:48211] by server-2.bemta-4.messagelabs.com id
	7C/F5-02822-01A693F4; Mon, 13 Feb 2012 19:52:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329162767!2689737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 13 Feb 2012 19:52:47 -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;
	13 Feb 2012 19:52:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10671180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 19:52: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.213.0;
	Mon, 13 Feb 2012 19:52:47 +0000
Message-ID: <1329162766.8906.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 13 Feb 2012 19:52:46 +0000
In-Reply-To: <20120213193930.GA96441@ocelot.phlegethon.org>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
	<4F3955D9.2020900@citrix.com>
	<1329160194.8906.11.camel@dagon.hellion.org.uk>
	<20120213193930.GA96441@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 19:39 +0000, Tim Deegan wrote:
> At 19:09 +0000 on 13 Feb (1329160194), Ian Campbell wrote:
> > (note that the mangling resulted in _7_ space indentation, which is
> > worse than just about anything)
> > 
> > > No other file in the tree has tabs why should these?
> > > 
> > > Nak, unless your intention is to immediately apply a patch converting
> > > tabs to 8 spaces.
> 
> We really ought to take this - the current state is both accidental and
> nonsensical.

Yes, that is my primary concern right now.

> That said, for head.S, which is the only place I've introduced tabs, I'm
> happy to have the whole file converted to (8) spaces if you also fix the
> emacs runes at the foot of the file to DTRT.

Similarly for entry.S which I think I just styled after head.S.

> For asm code taken from linux, have we already mangled them enough
> that applying upstream fixes would be hard?

I don't think so, once this fix is applied they will be back to being
pretty close.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19: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.xensource.com>)
	id 1Rx1xD-0007GL-7D; Mon, 13 Feb 2012 19:52: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 1Rx1xA-0007G9-SF
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:52:49 +0000
Received: from [85.158.143.35:48211] by server-2.bemta-4.messagelabs.com id
	7C/F5-02822-01A693F4; Mon, 13 Feb 2012 19:52:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329162767!2689737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 13 Feb 2012 19:52:47 -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;
	13 Feb 2012 19:52:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10671180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 19:52: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.213.0;
	Mon, 13 Feb 2012 19:52:47 +0000
Message-ID: <1329162766.8906.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 13 Feb 2012 19:52:46 +0000
In-Reply-To: <20120213193930.GA96441@ocelot.phlegethon.org>
References: <63e88a26e1ef58c8e5a2.1329156229@cosworth.uk.xensource.com>
	<4F3955D9.2020900@citrix.com>
	<1329160194.8906.11.camel@dagon.hellion.org.uk>
	<20120213193930.GA96441@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: fixup hard tabs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 19:39 +0000, Tim Deegan wrote:
> At 19:09 +0000 on 13 Feb (1329160194), Ian Campbell wrote:
> > (note that the mangling resulted in _7_ space indentation, which is
> > worse than just about anything)
> > 
> > > No other file in the tree has tabs why should these?
> > > 
> > > Nak, unless your intention is to immediately apply a patch converting
> > > tabs to 8 spaces.
> 
> We really ought to take this - the current state is both accidental and
> nonsensical.

Yes, that is my primary concern right now.

> That said, for head.S, which is the only place I've introduced tabs, I'm
> happy to have the whole file converted to (8) spaces if you also fix the
> emacs runes at the foot of the file to DTRT.

Similarly for entry.S which I think I just styled after head.S.

> For asm code taken from linux, have we already mangled them enough
> that applying upstream fixes would be hard?

I don't think so, once this fix is applied they will be back to being
pretty close.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:56:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx20q-0007ao-T7; Mon, 13 Feb 2012 19:56:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Rx20p-0007ZX-ND
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:56:35 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329162988!4844592!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMzNTY2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23958 invoked from network); 13 Feb 2012 19:56:29 -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; 13 Feb 2012 19:56:29 -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 q1DJuP5O029989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 19:56:27 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
	q1DJuPtq009424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 19:56:25 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
	q1DJuOB8014544
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 13:56:24 -0600
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 11:56:24 -0800
Message-ID: <4F396AE4.9090404@oracle.com>
Date: Mon, 13 Feb 2012 14:56:20 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------000200080209010503030602"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F396AEB.00EA,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] xl build failure: /usr/bin/ld: xl_cmdimpl.o: undefined
 reference to symbol 'yajl_gen_string'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------000200080209010503030602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

Anyone has this build issue?

$ make DESTDIR=/share/build/xen-unstable/dist/install verbose=y crash_debug=y
debug=y install-xen install-tools
...
gcc     -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o libxlutil.so
/share/build/xen-unstable/tools/libxl/../../tools/libxl/libxenlight.so
-Wl,-rpath-link=/share/build/xen-unstable/tools/libxl/../../tools/libxc
-Wl,-rpath-link=/share/build/xen-unstable/tools/libxl/../../tools/xenstore
-Wl,-rpath-link=/share/build/xen-unstable/tools/libxl/../../tools/blktap2/control /share/build/xen-unstable/tools/libxl/../../tools/libxc/libxenctrl.so
/usr/bin/ld: xl_cmdimpl.o: undefined reference to symbol 'yajl_gen_string'
/usr/bin/ld: note: 'yajl_gen_string' is defined in DSO /usr/lib64/libyajl.so.1
so try adding it to the linker command line
/usr/lib64/libyajl.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [xl] Error 1
make[3]: Leaving directory `/share/build/xen-unstable/tools/libxl'
make[2]: *** [subdir-install-libxl] Error 2
make[2]: Leaving directory `/share/build/xen-unstable/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/share/build/xen-unstable/tools'
make: *** [install-tools] Error 2

Attached patch is a simple fix, but maybe other better fixes.

Thanks,

Zhigang

--------------000200080209010503030602
Content-Type: text/x-patch;
 name="xen-unstable-xl-yajl.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xen-unstable-xl-yajl.patch"

diff -r 9ad1e42c341b tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Feb 10 17:24:50 2012 +0000
+++ b/tools/libxl/Makefile	Mon Feb 13 14:54:39 2012 -0500
@@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(LIBXL_LIBS) $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)

--------------000200080209010503030602
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000200080209010503030602--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 19:56:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 19:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx20q-0007ao-T7; Mon, 13 Feb 2012 19:56:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1Rx20p-0007ZX-ND
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 19:56:35 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329162988!4844592!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTMzNTY2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23958 invoked from network); 13 Feb 2012 19:56:29 -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; 13 Feb 2012 19:56:29 -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 q1DJuP5O029989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 19:56:27 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
	q1DJuPtq009424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 19:56:25 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
	q1DJuOB8014544
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 13:56:24 -0600
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 11:56:24 -0800
Message-ID: <4F396AE4.9090404@oracle.com>
Date: Mon, 13 Feb 2012 14:56:20 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------000200080209010503030602"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F396AEB.00EA,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] xl build failure: /usr/bin/ld: xl_cmdimpl.o: undefined
 reference to symbol 'yajl_gen_string'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------000200080209010503030602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

Anyone has this build issue?

$ make DESTDIR=/share/build/xen-unstable/dist/install verbose=y crash_debug=y
debug=y install-xen install-tools
...
gcc     -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o libxlutil.so
/share/build/xen-unstable/tools/libxl/../../tools/libxl/libxenlight.so
-Wl,-rpath-link=/share/build/xen-unstable/tools/libxl/../../tools/libxc
-Wl,-rpath-link=/share/build/xen-unstable/tools/libxl/../../tools/xenstore
-Wl,-rpath-link=/share/build/xen-unstable/tools/libxl/../../tools/blktap2/control /share/build/xen-unstable/tools/libxl/../../tools/libxc/libxenctrl.so
/usr/bin/ld: xl_cmdimpl.o: undefined reference to symbol 'yajl_gen_string'
/usr/bin/ld: note: 'yajl_gen_string' is defined in DSO /usr/lib64/libyajl.so.1
so try adding it to the linker command line
/usr/lib64/libyajl.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [xl] Error 1
make[3]: Leaving directory `/share/build/xen-unstable/tools/libxl'
make[2]: *** [subdir-install-libxl] Error 2
make[2]: Leaving directory `/share/build/xen-unstable/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/share/build/xen-unstable/tools'
make: *** [install-tools] Error 2

Attached patch is a simple fix, but maybe other better fixes.

Thanks,

Zhigang

--------------000200080209010503030602
Content-Type: text/x-patch;
 name="xen-unstable-xl-yajl.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xen-unstable-xl-yajl.patch"

diff -r 9ad1e42c341b tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Feb 10 17:24:50 2012 +0000
+++ b/tools/libxl/Makefile	Mon Feb 13 14:54:39 2012 -0500
@@ -142,7 +142,7 @@ libxlutil.a: $(LIBXLU_OBJS)
 	$(AR) rcs libxlutil.a $^
 
 xl: $(XL_OBJS) libxlutil.so libxenlight.so
-	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(LIBXL_LIBS) $(APPEND_LDFLAGS)
 
 testidl: testidl.o libxlutil.so libxenlight.so
 	$(CC) $(LDFLAGS) -o $@ testidl.o libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)

--------------000200080209010503030602
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000200080209010503030602--


From xen-devel-bounces@lists.xensource.com Mon Feb 13 20:07:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 20: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.xensource.com>)
	id 1Rx2BS-0007vr-AM; Mon, 13 Feb 2012 20:07:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rx2BQ-0007vm-QN
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 20:07:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329163646!13199232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22301 invoked from network); 13 Feb 2012 20:07:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 20:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10671468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 20:07:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 20:07:25 +0000
Message-ID: <1329163645.8906.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Mon, 13 Feb 2012 20:07:25 +0000
In-Reply-To: <4F396AE4.9090404@oracle.com>
References: <4F396AE4.9090404@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl build failure: /usr/bin/ld: xl_cmdimpl.o:
 undefined reference to symbol 'yajl_gen_string'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 19:56 +0000, Zhigang Wang wrote:
> Hi,
> 
> Anyone has this build issue?

Olaf Herring post a series which included a fix for this on Thursday,
see <patchbomb.1328791978@probook.site>.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 20:07:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 20: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.xensource.com>)
	id 1Rx2BS-0007vr-AM; Mon, 13 Feb 2012 20:07:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rx2BQ-0007vm-QN
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 20:07:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329163646!13199232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22301 invoked from network); 13 Feb 2012 20:07:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 20:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10671468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 20:07:26 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 13 Feb 2012 20:07:25 +0000
Message-ID: <1329163645.8906.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Mon, 13 Feb 2012 20:07:25 +0000
In-Reply-To: <4F396AE4.9090404@oracle.com>
References: <4F396AE4.9090404@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl build failure: /usr/bin/ld: xl_cmdimpl.o:
 undefined reference to symbol 'yajl_gen_string'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 19:56 +0000, Zhigang Wang wrote:
> Hi,
> 
> Anyone has this build issue?

Olaf Herring post a series which included a fix for this on Thursday,
see <patchbomb.1328791978@probook.site>.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 20:16:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 20: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.xensource.com>)
	id 1Rx2K2-000866-Cf; Mon, 13 Feb 2012 20:16:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rx2K0-00085r-G9
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 20:16:24 +0000
Received: from [85.158.139.83:45429] by server-12.bemta-5.messagelabs.com id
	38/F4-30830-79F693F4; Mon, 13 Feb 2012 20:16:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329164182!14912708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8362 invoked from network); 13 Feb 2012 20:16:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 20:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10671694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 20:16:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 20:16:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rx2Jx-0003Sh-6t;
	Mon, 13 Feb 2012 20:16:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rx2Jw-0008OV-Qp;
	Mon, 13 Feb 2012 20:16:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11946-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 20:16:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11946 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11944

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9207cc3a0862
baseline version:
 xen                  9ad1e42c341b

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julian Pidancet <julian.pidancet@gmail.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24790:9207cc3a0862
tag:         tip
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 13 13:34:47 2012 +0000
    
    libfdt: add to build
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24789:e060d1bd7b60
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 13 13:34:08 2012 +0000
    
    libfdt: fixup libfdt_env.h for xen
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24788:fcc188f21e47
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 13 13:33:26 2012 +0000
    
    libfdt: add version 1.3.0
    
    Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git
    
    This will be used by Xen to parse the DTBs provided by bootloaders on
    ARM platforms.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24787:bd0a11ed1a67
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 13 12:53:28 2012 +0000
    
    MAINTAINERS: Add entry for ARM w/ virt extensions port
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24786:79fe73117c12
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:50:46 2012 +0000
    
    firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
    
    This patch introduces configuration options allowing to built either a
    rombios only or a seabios only hvmloader.
    
    Building option ROMs like vgabios or etherboot is only enabled for a
    rombios hvmloader, since SeaBIOS takes care or extracting option ROMs
    itself from the PCI devices (these option ROMs are provided by the
    device model and do not need to be built in hvmloader).
    
    The Makefile in tools/firmware/ now only checks for bcc if rombios is
    enabled.
    
    These two configuration options are left on by default to remain
    compatible.
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24785:e4d8d2524407
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:50:04 2012 +0000
    
    hvmloader: Move option ROM loading into a separate optionnal file
    
    Make load_rom field in struct bios_config an optionnal callback rather
    than a boolean value. It allow BIOS specific code to implement it's
    own option ROM loading methods.
    
    Facilities to scan PCI devices, extract an deploy ROMs are moved into
    a separate file that can be compiled optionnaly.
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24784:ab47cfef2b0a
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:49:06 2012 +0000
    
    firmware: Use mkhex from hvmloader directory for etherboot ROMs
    
    To remain consistent with how other ROMs are built into hvmloader,
    call mkhex on etherboot ROMs from the hvmloader directory, instead of
    the etherboot directory. In other words, eb-roms.h is not used any
    more.
    
    Introduce ETHERBOOT_NICS config option to choose which ROMs should be
    built (kept rtl8139 and 8086100e per default as before).
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24783:0fe9e2556e20
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:48:20 2012 +0000
    
    hvmloader: Allow the mkhex command to take several file arguments
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24782:e1f10d12b9fe
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:47:46 2012 +0000
    
    hvmloader: Only compile 32bitbios_support.c when rombios is enabled
    
    32bitbios_support.c only contains code specific to rombios, and should
    not be built-in when building hvmloader for SeaBIOS only (as for
    rombios.c).
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24781:6ae5506e49ab
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 13 13:12:30 2012 +0100
    
    x86/vMCE: MC{G,i}_CTL handling adjustments
    
    - g_mcg_cap was read to determine whether MCG_CTL exists before it got
      initialized
    - h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via
      memset() with an inappropriate size (hence causing a [minor?]
      information leak)
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24780:e953d536d3c6
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 13 13:09:02 2012 +0100
    
    x86/paging: use clear_guest() for zero-filling guest buffers
    
    While static arrays of all zeros may be tolerable (but are simply
    inefficient now that we have the necessary infrastructure), using on-
    stack arrays for this purpose (particularly when their size doesn't
    have an upper limit enforced) is calling for eventual problems (even
    if the code can be reached via administrative interfaces only).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24779:9ad1e42c341b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Feb 10 17:24:50 2012 +0000
    
    xend: populate HVM guest grant table on boot
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387
Author: Jan Beulich <JBeulich@suse.com>
Date:   Tue Feb 7 18:42:56 2012 +0000

    qemu-dm: fix unregister_iomem()
    
    This function (introduced quite a long time ago in
    e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
    devices in HVM domains") appears to be completely broken, causing
    the regression reported in
    http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
    the newly added caller of it in
    56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
    MSI-X table handling"). It's unclear how the function can ever have
    fulfilled its purpose: the value returned by iomem_index() is *not* an
    index into mmio[].
    
    Additionally, fix two problems:
    - unregister_iomem() must not clear mmio[].start, otherwise
      cpu_register_physical_memory() won't be able to re-use the previous
      slot, thus causing a leak
    - cpu_unregister_io_memory() must not check mmio[].size, otherwise it
      won't properly clean up entries (temporarily) squashed through
      unregister_iomem()
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Tested-by: Yongjie Ren <yongjie.ren@intel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 20:16:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 20: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.xensource.com>)
	id 1Rx2K2-000866-Cf; Mon, 13 Feb 2012 20:16:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rx2K0-00085r-G9
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 20:16:24 +0000
Received: from [85.158.139.83:45429] by server-12.bemta-5.messagelabs.com id
	38/F4-30830-79F693F4; Mon, 13 Feb 2012 20:16:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329164182!14912708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTM4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8362 invoked from network); 13 Feb 2012 20:16:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2012 20:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="10671694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2012 20:16:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 13 Feb 2012 20:16:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rx2Jx-0003Sh-6t;
	Mon, 13 Feb 2012 20:16:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rx2Jw-0008OV-Qp;
	Mon, 13 Feb 2012 20:16:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11946-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 13 Feb 2012 20:16:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11946 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11944

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  9207cc3a0862
baseline version:
 xen                  9ad1e42c341b

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julian Pidancet <julian.pidancet@gmail.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24790:9207cc3a0862
tag:         tip
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 13 13:34:47 2012 +0000
    
    libfdt: add to build
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24789:e060d1bd7b60
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 13 13:34:08 2012 +0000
    
    libfdt: fixup libfdt_env.h for xen
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24788:fcc188f21e47
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 13 13:33:26 2012 +0000
    
    libfdt: add version 1.3.0
    
    Add libfdt 1.3.0 from http://git.jdl.com/gitweb/?p=dtc.git
    
    This will be used by Xen to parse the DTBs provided by bootloaders on
    ARM platforms.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24787:bd0a11ed1a67
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 13 12:53:28 2012 +0000
    
    MAINTAINERS: Add entry for ARM w/ virt extensions port
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24786:79fe73117c12
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:50:46 2012 +0000
    
    firmware: Introduce CONFIG_ROMBIOS and CONFIG_SEABIOS options
    
    This patch introduces configuration options allowing to built either a
    rombios only or a seabios only hvmloader.
    
    Building option ROMs like vgabios or etherboot is only enabled for a
    rombios hvmloader, since SeaBIOS takes care or extracting option ROMs
    itself from the PCI devices (these option ROMs are provided by the
    device model and do not need to be built in hvmloader).
    
    The Makefile in tools/firmware/ now only checks for bcc if rombios is
    enabled.
    
    These two configuration options are left on by default to remain
    compatible.
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24785:e4d8d2524407
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:50:04 2012 +0000
    
    hvmloader: Move option ROM loading into a separate optionnal file
    
    Make load_rom field in struct bios_config an optionnal callback rather
    than a boolean value. It allow BIOS specific code to implement it's
    own option ROM loading methods.
    
    Facilities to scan PCI devices, extract an deploy ROMs are moved into
    a separate file that can be compiled optionnaly.
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24784:ab47cfef2b0a
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:49:06 2012 +0000
    
    firmware: Use mkhex from hvmloader directory for etherboot ROMs
    
    To remain consistent with how other ROMs are built into hvmloader,
    call mkhex on etherboot ROMs from the hvmloader directory, instead of
    the etherboot directory. In other words, eb-roms.h is not used any
    more.
    
    Introduce ETHERBOOT_NICS config option to choose which ROMs should be
    built (kept rtl8139 and 8086100e per default as before).
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24783:0fe9e2556e20
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:48:20 2012 +0000
    
    hvmloader: Allow the mkhex command to take several file arguments
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24782:e1f10d12b9fe
user:        Julian Pidancet <julian.pidancet@gmail.com>
date:        Mon Feb 13 12:47:46 2012 +0000
    
    hvmloader: Only compile 32bitbios_support.c when rombios is enabled
    
    32bitbios_support.c only contains code specific to rombios, and should
    not be built-in when building hvmloader for SeaBIOS only (as for
    rombios.c).
    
    Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24781:6ae5506e49ab
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 13 13:12:30 2012 +0100
    
    x86/vMCE: MC{G,i}_CTL handling adjustments
    
    - g_mcg_cap was read to determine whether MCG_CTL exists before it got
      initialized
    - h_mci_ctrl[] and dom_vmce()->mci_ctl[] both got initialized via
      memset() with an inappropriate size (hence causing a [minor?]
      information leak)
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24780:e953d536d3c6
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 13 13:09:02 2012 +0100
    
    x86/paging: use clear_guest() for zero-filling guest buffers
    
    While static arrays of all zeros may be tolerable (but are simply
    inefficient now that we have the necessary infrastructure), using on-
    stack arrays for this purpose (particularly when their size doesn't
    have an upper limit enforced) is calling for eventual problems (even
    if the code can be reached via administrative interfaces only).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24779:9ad1e42c341b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Feb 10 17:24:50 2012 +0000
    
    xend: populate HVM guest grant table on boot
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 8cc8a3651c9c5bc2d0086d12f4b870fc525b9387
Author: Jan Beulich <JBeulich@suse.com>
Date:   Tue Feb 7 18:42:56 2012 +0000

    qemu-dm: fix unregister_iomem()
    
    This function (introduced quite a long time ago in
    e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
    devices in HVM domains") appears to be completely broken, causing
    the regression reported in
    http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
    the newly added caller of it in
    56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
    MSI-X table handling"). It's unclear how the function can ever have
    fulfilled its purpose: the value returned by iomem_index() is *not* an
    index into mmio[].
    
    Additionally, fix two problems:
    - unregister_iomem() must not clear mmio[].start, otherwise
      cpu_register_physical_memory() won't be able to re-use the previous
      slot, thus causing a leak
    - cpu_unregister_io_memory() must not check mmio[].size, otherwise it
      won't properly clean up entries (temporarily) squashed through
      unregister_iomem()
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Tested-by: Yongjie Ren <yongjie.ren@intel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 22:41:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 22: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.xensource.com>)
	id 1Rx4a5-0001oU-FW; Mon, 13 Feb 2012 22:41:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Rx4a4-0001oP-7e
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 22:41:08 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329172733!52561603!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22347 invoked from network); 13 Feb 2012 22:38:53 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-14.tower-27.messagelabs.com with SMTP;
	13 Feb 2012 22:38:53 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id q1DMf5x2018428
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 17:41:05 -0500
Message-ID: <4F399181.5060801@theshore.net>
Date: Mon, 13 Feb 2012 17:41:05 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] BUG: unable to handle kernel NULL pointer dereference -
	xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen: xen-4.1-testing @ cs 23224 64 bit
Dom0: 3.2.5 PAE *and* 3.0.4 PAE
Hardware: both IGB and e1000e NICed machines

Network stress testing (iperf, UDP, bidirectional) the above stack 
reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs 
with the following:

BUG: unable to handle kernel NULL pointer dereference at 00000474
IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
*pdpt = 00000000009f7027 *pde = 0000000000000000
Oops: 0002 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e
Pid: 0, comm: swapper/1 Not tainted 3.2.5-2 #3 Supermicro X8DT6/X8DT6
EIP: 0061:[<c100e967>] EFLAGS: 00010006 CPU: 1
EIP is at xen_spin_lock_flags+0x27/0x70
EAX: 00000400 EBX: 00000474 ECX: 00000001 EDX: 00000001
ESI: 00000200 EDI: 00000400 EBP: e84aff08 ESP: e84afef8
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
Process swapper/1 (pid: 0, ti=e84ae000 task=e84589c0 task.ti=e8470000)
Stack:
00000001 00000274 e6058400 e605848c e84aff1c c16688ba 00000000 e6058400
e605848c e84aff40 c149f1a0 c100828b c1668904 c184f880 00000474 00010f66
f38b4000 e6058454 e84aff50 c149f23d 000005e8 ffffffff e84aff60 c149f2c5
Call Trace:
[<c16688ba>] _raw_spin_lock_irqsave+0x2a/0x40
[<c149f1a0>] xen_netbk_schedule_xenvif+0x80/0xf0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c1668904>] ? _raw_spin_unlock_irqrestore+0x14/0x20
[<c149f23d>] xen_netbk_check_rx_xenvif+0x2d/0x70
[<c149f2c5>] tx_credit_callback+0x45/0x50
[<c1059f92>] run_timer_softirq+0x112/0x2d0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c10a072d>] ? check_for_new_grace_period+0x9d/0xc0
[<c10a062e>] ? rcu_process_gp_end+0x3e/0xa0
[<c149f280>] ? xen_netbk_check_rx_xenvif+0x70/0x70
[<c1052586>] __do_softirq+0x96/0x1b0
[<c10524f0>] ? irq_enter+0x70/0x70
<IRQ>
[<c10523e5>] ? irq_exit+0x95/0xb0
[<c13b2070>] ? xen_evtchn_do_upcall+0x20/0x30
[<c166f647>] ? xen_do_upcall+0x7/0xc
[<c106007b>] ? do_prlimit+0x5b/0x1b0
[<c10013a7>] ? hypercall_page+0x3a7/0x1000
[<c1007a42>] ? xen_safe_halt+0x12/0x20
[<c1016fac>] ? default_idle+0x6c/0x170
[<c100ef4e>] ? cpu_idle+0x5e/0x90
[<c165db1f>] ? cpu_bringup_and_idle+0xd/0xf
Code: 00 00 00 00 55 b9 01 00 00 00 89 e5 83 ec 10 89 75 f8 89 d6 89 5d 
f4 81 e6 00 02 00 00 89 c3 89 7d fc bf 00 04 00 00 89 f8 89 ca <86> 13 
84 d2 74 0a f3 90 80 3b 00 74 f3 48 75 f6 84 d2 75 0d 8b
EIP: [<c100e967>] xen_spin_lock_flags+0x27/0x70 SS:ESP 0069:e84afef8
CR2: 0000000000000474
---[ end trace 76e317879747e85d ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 0, comm: swapper/1 Tainted: G D 3.2.5-2 #3
Call Trace:
[<c166624a>] panic+0x57/0x15f
[<c16699b5>] oops_end+0xc5/0xd0
[<c1032dbe>] no_context+0xbe/0x190
[<c1032f28>] __bad_area_nosemaphore+0x98/0x140
[<c1621cd0>] ? br_flood_deliver+0x20/0x20
[<f2dcd0b7>] ? ebt_nat_out+0x27/0x34 [ebtable_nat]
[<c1621cd0>] ? br_flood_deliver+0x20/0x20
[<c1032fe2>] bad_area_nosemaphore+0x12/0x20
[<c166bad2>] do_page_fault+0x2d2/0x3f0
[<c15896ca>] ? nf_hook_slow+0x5a/0x110
[<c1621d21>] ? br_dev_queue_push_xmit+0x51/0x70
[<c1621f77>] ? br_forward_finish+0x57/0x60
[<c1621cd0>] ? br_flood_deliver+0x20/0x20
[<c1621df3>] ? __br_forward+0xb3/0xd0
[<c166b800>] ? spurious_fault+0x130/0x130
[<c16691ee>] error_code+0x5a/0x60
[<c166b800>] ? spurious_fault+0x130/0x130
[<c100e967>] ? xen_spin_lock_flags+0x27/0x70
[<c16688ba>] _raw_spin_lock_irqsave+0x2a/0x40
[<c149f1a0>] xen_netbk_schedule_xenvif+0x80/0xf0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c1668904>] ? _raw_spin_unlock_irqrestore+0x14/0x20
[<c149f23d>] xen_netbk_check_rx_xenvif+0x2d/0x70
[<c149f2c5>] tx_credit_callback+0x45/0x50
[<c1059f92>] run_timer_softirq+0x112/0x2d0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c10a072d>] ? check_for_new_grace_period+0x9d/0xc0
[<c10a062e>] ? rcu_process_gp_end+0x3e/0xa0
[<c149f280>] ? xen_netbk_check_rx_xenvif+0x70/0x70
[<c1052586>] __do_softirq+0x96/0x1b0
[<c10524f0>] ? irq_enter+0x70/0x70
<IRQ> [<c10523e5>] ? irq_exit+0x95/0xb0
[<c13b2070>] ? xen_evtchn_do_upcall+0x20/0x30
[<c166f647>] ? xen_do_upcall+0x7/0xc
[<c106007b>] ? do_prlimit+0x5b/0x1b0
[<c10013a7>] ? hypercall_page+0x3a7/0x1000
[<c1007a42>] ? xen_safe_halt+0x12/0x20
[<c1016fac>] ? default_idle+0x6c/0x170
[<c100ef4e>] ? cpu_idle+0x5e/0x90
[<c165db1f>] ? cpu_bringup_and_idle+0xd/0xf
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

Should we be pointing the finger at the Hypervisor, or a dom0 issue?

Thanks,
-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 13 22:41:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 13 Feb 2012 22: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.xensource.com>)
	id 1Rx4a5-0001oU-FW; Mon, 13 Feb 2012 22:41:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Rx4a4-0001oP-7e
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 22:41:08 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329172733!52561603!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22347 invoked from network); 13 Feb 2012 22:38:53 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-14.tower-27.messagelabs.com with SMTP;
	13 Feb 2012 22:38:53 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id q1DMf5x2018428
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 17:41:05 -0500
Message-ID: <4F399181.5060801@theshore.net>
Date: Mon, 13 Feb 2012 17:41:05 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] BUG: unable to handle kernel NULL pointer dereference -
	xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Xen: xen-4.1-testing @ cs 23224 64 bit
Dom0: 3.2.5 PAE *and* 3.0.4 PAE
Hardware: both IGB and e1000e NICed machines

Network stress testing (iperf, UDP, bidirectional) the above stack 
reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs 
with the following:

BUG: unable to handle kernel NULL pointer dereference at 00000474
IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
*pdpt = 00000000009f7027 *pde = 0000000000000000
Oops: 0002 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e
Pid: 0, comm: swapper/1 Not tainted 3.2.5-2 #3 Supermicro X8DT6/X8DT6
EIP: 0061:[<c100e967>] EFLAGS: 00010006 CPU: 1
EIP is at xen_spin_lock_flags+0x27/0x70
EAX: 00000400 EBX: 00000474 ECX: 00000001 EDX: 00000001
ESI: 00000200 EDI: 00000400 EBP: e84aff08 ESP: e84afef8
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
Process swapper/1 (pid: 0, ti=e84ae000 task=e84589c0 task.ti=e8470000)
Stack:
00000001 00000274 e6058400 e605848c e84aff1c c16688ba 00000000 e6058400
e605848c e84aff40 c149f1a0 c100828b c1668904 c184f880 00000474 00010f66
f38b4000 e6058454 e84aff50 c149f23d 000005e8 ffffffff e84aff60 c149f2c5
Call Trace:
[<c16688ba>] _raw_spin_lock_irqsave+0x2a/0x40
[<c149f1a0>] xen_netbk_schedule_xenvif+0x80/0xf0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c1668904>] ? _raw_spin_unlock_irqrestore+0x14/0x20
[<c149f23d>] xen_netbk_check_rx_xenvif+0x2d/0x70
[<c149f2c5>] tx_credit_callback+0x45/0x50
[<c1059f92>] run_timer_softirq+0x112/0x2d0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c10a072d>] ? check_for_new_grace_period+0x9d/0xc0
[<c10a062e>] ? rcu_process_gp_end+0x3e/0xa0
[<c149f280>] ? xen_netbk_check_rx_xenvif+0x70/0x70
[<c1052586>] __do_softirq+0x96/0x1b0
[<c10524f0>] ? irq_enter+0x70/0x70
<IRQ>
[<c10523e5>] ? irq_exit+0x95/0xb0
[<c13b2070>] ? xen_evtchn_do_upcall+0x20/0x30
[<c166f647>] ? xen_do_upcall+0x7/0xc
[<c106007b>] ? do_prlimit+0x5b/0x1b0
[<c10013a7>] ? hypercall_page+0x3a7/0x1000
[<c1007a42>] ? xen_safe_halt+0x12/0x20
[<c1016fac>] ? default_idle+0x6c/0x170
[<c100ef4e>] ? cpu_idle+0x5e/0x90
[<c165db1f>] ? cpu_bringup_and_idle+0xd/0xf
Code: 00 00 00 00 55 b9 01 00 00 00 89 e5 83 ec 10 89 75 f8 89 d6 89 5d 
f4 81 e6 00 02 00 00 89 c3 89 7d fc bf 00 04 00 00 89 f8 89 ca <86> 13 
84 d2 74 0a f3 90 80 3b 00 74 f3 48 75 f6 84 d2 75 0d 8b
EIP: [<c100e967>] xen_spin_lock_flags+0x27/0x70 SS:ESP 0069:e84afef8
CR2: 0000000000000474
---[ end trace 76e317879747e85d ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 0, comm: swapper/1 Tainted: G D 3.2.5-2 #3
Call Trace:
[<c166624a>] panic+0x57/0x15f
[<c16699b5>] oops_end+0xc5/0xd0
[<c1032dbe>] no_context+0xbe/0x190
[<c1032f28>] __bad_area_nosemaphore+0x98/0x140
[<c1621cd0>] ? br_flood_deliver+0x20/0x20
[<f2dcd0b7>] ? ebt_nat_out+0x27/0x34 [ebtable_nat]
[<c1621cd0>] ? br_flood_deliver+0x20/0x20
[<c1032fe2>] bad_area_nosemaphore+0x12/0x20
[<c166bad2>] do_page_fault+0x2d2/0x3f0
[<c15896ca>] ? nf_hook_slow+0x5a/0x110
[<c1621d21>] ? br_dev_queue_push_xmit+0x51/0x70
[<c1621f77>] ? br_forward_finish+0x57/0x60
[<c1621cd0>] ? br_flood_deliver+0x20/0x20
[<c1621df3>] ? __br_forward+0xb3/0xd0
[<c166b800>] ? spurious_fault+0x130/0x130
[<c16691ee>] error_code+0x5a/0x60
[<c166b800>] ? spurious_fault+0x130/0x130
[<c100e967>] ? xen_spin_lock_flags+0x27/0x70
[<c16688ba>] _raw_spin_lock_irqsave+0x2a/0x40
[<c149f1a0>] xen_netbk_schedule_xenvif+0x80/0xf0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c1668904>] ? _raw_spin_unlock_irqrestore+0x14/0x20
[<c149f23d>] xen_netbk_check_rx_xenvif+0x2d/0x70
[<c149f2c5>] tx_credit_callback+0x45/0x50
[<c1059f92>] run_timer_softirq+0x112/0x2d0
[<c100828b>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<c10a072d>] ? check_for_new_grace_period+0x9d/0xc0
[<c10a062e>] ? rcu_process_gp_end+0x3e/0xa0
[<c149f280>] ? xen_netbk_check_rx_xenvif+0x70/0x70
[<c1052586>] __do_softirq+0x96/0x1b0
[<c10524f0>] ? irq_enter+0x70/0x70
<IRQ> [<c10523e5>] ? irq_exit+0x95/0xb0
[<c13b2070>] ? xen_evtchn_do_upcall+0x20/0x30
[<c166f647>] ? xen_do_upcall+0x7/0xc
[<c106007b>] ? do_prlimit+0x5b/0x1b0
[<c10013a7>] ? hypercall_page+0x3a7/0x1000
[<c1007a42>] ? xen_safe_halt+0x12/0x20
[<c1016fac>] ? default_idle+0x6c/0x170
[<c100ef4e>] ? cpu_idle+0x5e/0x90
[<c165db1f>] ? cpu_bringup_and_idle+0xd/0xf
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

Should we be pointing the finger at the Hypervisor, or a dom0 issue?

Thanks,
-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 00:55:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 00: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.xensource.com>)
	id 1Rx6fg-0003JE-KO; Tue, 14 Feb 2012 00:55:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Rx6ff-0003J9-N4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 00:55:03 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329180896!12722910!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 14 Feb 2012 00:54:57 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-13.tower-21.messagelabs.com with SMTP;
	14 Feb 2012 00:54:57 -0000
Received: from [192.168.200.100] (c-69-248-252-23.hsd1.nj.comcast.net
	[69.248.252.23])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id q1E0stlF007050
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 19:54:55 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <4F399181.5060801@theshore.net>
Date: Mon, 13 Feb 2012 19:54:49 -0500
Message-Id: <37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
References: <4F399181.5060801@theshore.net>
To: xen devel <xen-devel@lists.xensource.com>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
	dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 13, 2012, at 5:41 PM, Christopher S. Aker wrote:
> Network stress testing (iperf, UDP, bidirectional) the above stack reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs with the following:
> 
> BUG: unable to handle kernel NULL pointer dereference at 00000474
> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70

This happens regardless of CONFIG_PARAVIRT_SPINLOCKS enabled or disabled.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 00:55:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 00: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.xensource.com>)
	id 1Rx6fg-0003JE-KO; Tue, 14 Feb 2012 00:55:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1Rx6ff-0003J9-N4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 00:55:03 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329180896!12722910!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 14 Feb 2012 00:54:57 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-13.tower-21.messagelabs.com with SMTP;
	14 Feb 2012 00:54:57 -0000
Received: from [192.168.200.100] (c-69-248-252-23.hsd1.nj.comcast.net
	[69.248.252.23])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id q1E0stlF007050
	for <xen-devel@lists.xensource.com>; Mon, 13 Feb 2012 19:54:55 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <4F399181.5060801@theshore.net>
Date: Mon, 13 Feb 2012 19:54:49 -0500
Message-Id: <37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
References: <4F399181.5060801@theshore.net>
To: xen devel <xen-devel@lists.xensource.com>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
	dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 13, 2012, at 5:41 PM, Christopher S. Aker wrote:
> Network stress testing (iperf, UDP, bidirectional) the above stack reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs with the following:
> 
> BUG: unable to handle kernel NULL pointer dereference at 00000474
> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70

This happens regardless of CONFIG_PARAVIRT_SPINLOCKS enabled or disabled.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 00:58:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 00:58:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx6iA-0003OO-7C; Tue, 14 Feb 2012 00:57:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rx6i8-0003OG-HH
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 00:57:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329181049!10520506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTYwMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3339 invoked from network); 14 Feb 2012 00:57:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 00:57:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,414,1325462400"; d="scan'208";a="10675088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 00:57:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 00:57:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rx6hz-0005GK-Rs;
	Tue, 14 Feb 2012 00:57:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rx6hz-00084q-Lv;
	Tue, 14 Feb 2012 00:57:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11948-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 00:57:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 11948: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11948 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11948/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 11830

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  f2543f449a49
baseline version:
 xen                  cccd6c68e1b9

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.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=f2543f449a49
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 f2543f449a49
+ branch=xen-4.1-testing
+ revision=f2543f449a49
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ . ap-common
++ : 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
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r f2543f449a49 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 00:58:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 00:58:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx6iA-0003OO-7C; Tue, 14 Feb 2012 00:57:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rx6i8-0003OG-HH
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 00:57:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329181049!10520506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTYwMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3339 invoked from network); 14 Feb 2012 00:57:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 00:57:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,414,1325462400"; d="scan'208";a="10675088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 00:57:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 00:57:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rx6hz-0005GK-Rs;
	Tue, 14 Feb 2012 00:57:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rx6hz-00084q-Lv;
	Tue, 14 Feb 2012 00:57:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11948-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 00:57:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 11948: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11948 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11948/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 11830

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  f2543f449a49
baseline version:
 xen                  cccd6c68e1b9

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.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=f2543f449a49
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 f2543f449a49
+ branch=xen-4.1-testing
+ revision=f2543f449a49
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ . ap-common
++ : 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
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r f2543f449a49 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 02:18:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 02:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx7y0-000096-AE; Tue, 14 Feb 2012 02:18:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qrux.qed@gmail.com>)
	id 1Rx7xz-00008y-MS; Tue, 14 Feb 2012 02:18:03 +0000
X-Env-Sender: qrux.qed@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329185875!13167810!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12253 invoked from network); 14 Feb 2012 02:17:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 02:17:57 -0000
Received: by iaeh11 with SMTP id h11so30596540iae.30
	for <multiple recipients>; Mon, 13 Feb 2012 18:17:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer;
	bh=42V/QLKaPTzZqeU570q+fgkdkC4cQ0jl8IiP3Ct+8Ro=;
	b=Y53VzqKi77rDSSmuLHiem4aG6h9BlYag96pA2MfrEZZWktxtaQEytwdPG9/fWdktpA
	4BP5h00xhEB8VDomnb+dtwuSkTLi96zHLJeCjs/sU9ulyaDSsx+8nr1MRBubQ4mUBJxF
	U5yItYxDsQGuHpL54W+99uQLoZaqDzdSbyEpM=
Received: by 10.42.147.134 with SMTP id n6mr24940414icv.55.1329185874996;
	Mon, 13 Feb 2012 18:17:54 -0800 (PST)
Received: from [192.168.0.4] (c-71-198-0-100.hsd1.ca.comcast.net.
	[71.198.0.100])
	by mx.google.com with ESMTPS id uy10sm23712062igc.1.2012.02.13.18.17.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 13 Feb 2012 18:17:54 -0800 (PST)
From: Qrux <qrux.qed@gmail.com>
Date: Mon, 13 Feb 2012 18:18:07 -0800
Message-Id: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
To: xen-users@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen domU Timekeeping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Howdy, all.

Is there definitive documentation about accurate timekeeping on Linux PV domUs (Xen-4.1.2, Linux-3.1-pvops)?

Specifically:

	* Is there a way to keep good time (i.e., bare-metal accuracy) on domU?

	* What's happened to /proc/sys/xen/independent_wallclock?

	* What should be done with /sbin/hwclock (if copied from a dom0)?

	* Does NTP on domU "work"?  Does adjtimex do anything?

	* Are there "bad side-effects" to "bad time" on domUs (see below)...?

I'd be happy for an: "RTFM @ http://...," response, if the docs were definitive.

===============================================================================

In addition, I'm having hard-to-track issues using ext4 on a domU, which I suspect may be related to the timekeeping issue(s).  When I boot this domU the first time, everything comes up nicely.  The kernel has ext2, ext3, and ext4 drivers built in.  I see this on the console:

	[ 0.283049] EXT3-fs (xvda1): error: couldn't mount...unsupported...features
	[ 0.288476] EXT2-fs (xvda1): error: couldn't mount...unsupported...features

which is expected--and makes perfect sense--because I expect the next line to be this:

	[ 0.318273] EXT4-fs (xvda1): mounted filesystem with ordered data mode...

And, that is what I observe.  At least, on the first boot...

But, upon reboot of the domU, I get stuck at the ext3/ext2 errors.  Guessing, I destroyed the nonfunctional domU, and reformatted its drive as ext3.  This worked.  I was able to reboot that domU without a problem.  Google didn't find too much information except this:

	http://lists.openwall.net/linux-ext4/2009/10/12/12

But this is from 2009.  And, I'm not sure how relevant it is, directly, but it did make me wonder...Does not having "good time" on domUs affect the ability of the kernel to mount filesystems?  Could that be breaking ext4 on a domU with NTP?  And, despite the article's age, is using ext4 with "barriers=0" still valid advice...?

Then...Accidentally, when I had the domU disk device mounted on dom0 (debugging, and forgot to umount before xl create), the domU came up fine--albeit slightly pissed off because it thought that the filesystem had errors.  But, it "repaired" the "errors" just fine (I assume they were related to the double-rw-mount), and booted.

I'm assuming all of this is documented somewhere; I just need a pointer to where to find this info.

===============================================================================

Thanks,
	Q


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 02:18:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 02:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rx7y0-000096-AE; Tue, 14 Feb 2012 02:18:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qrux.qed@gmail.com>)
	id 1Rx7xz-00008y-MS; Tue, 14 Feb 2012 02:18:03 +0000
X-Env-Sender: qrux.qed@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329185875!13167810!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12253 invoked from network); 14 Feb 2012 02:17:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 02:17:57 -0000
Received: by iaeh11 with SMTP id h11so30596540iae.30
	for <multiple recipients>; Mon, 13 Feb 2012 18:17:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer;
	bh=42V/QLKaPTzZqeU570q+fgkdkC4cQ0jl8IiP3Ct+8Ro=;
	b=Y53VzqKi77rDSSmuLHiem4aG6h9BlYag96pA2MfrEZZWktxtaQEytwdPG9/fWdktpA
	4BP5h00xhEB8VDomnb+dtwuSkTLi96zHLJeCjs/sU9ulyaDSsx+8nr1MRBubQ4mUBJxF
	U5yItYxDsQGuHpL54W+99uQLoZaqDzdSbyEpM=
Received: by 10.42.147.134 with SMTP id n6mr24940414icv.55.1329185874996;
	Mon, 13 Feb 2012 18:17:54 -0800 (PST)
Received: from [192.168.0.4] (c-71-198-0-100.hsd1.ca.comcast.net.
	[71.198.0.100])
	by mx.google.com with ESMTPS id uy10sm23712062igc.1.2012.02.13.18.17.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 13 Feb 2012 18:17:54 -0800 (PST)
From: Qrux <qrux.qed@gmail.com>
Date: Mon, 13 Feb 2012 18:18:07 -0800
Message-Id: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
To: xen-users@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen domU Timekeeping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Howdy, all.

Is there definitive documentation about accurate timekeeping on Linux PV domUs (Xen-4.1.2, Linux-3.1-pvops)?

Specifically:

	* Is there a way to keep good time (i.e., bare-metal accuracy) on domU?

	* What's happened to /proc/sys/xen/independent_wallclock?

	* What should be done with /sbin/hwclock (if copied from a dom0)?

	* Does NTP on domU "work"?  Does adjtimex do anything?

	* Are there "bad side-effects" to "bad time" on domUs (see below)...?

I'd be happy for an: "RTFM @ http://...," response, if the docs were definitive.

===============================================================================

In addition, I'm having hard-to-track issues using ext4 on a domU, which I suspect may be related to the timekeeping issue(s).  When I boot this domU the first time, everything comes up nicely.  The kernel has ext2, ext3, and ext4 drivers built in.  I see this on the console:

	[ 0.283049] EXT3-fs (xvda1): error: couldn't mount...unsupported...features
	[ 0.288476] EXT2-fs (xvda1): error: couldn't mount...unsupported...features

which is expected--and makes perfect sense--because I expect the next line to be this:

	[ 0.318273] EXT4-fs (xvda1): mounted filesystem with ordered data mode...

And, that is what I observe.  At least, on the first boot...

But, upon reboot of the domU, I get stuck at the ext3/ext2 errors.  Guessing, I destroyed the nonfunctional domU, and reformatted its drive as ext3.  This worked.  I was able to reboot that domU without a problem.  Google didn't find too much information except this:

	http://lists.openwall.net/linux-ext4/2009/10/12/12

But this is from 2009.  And, I'm not sure how relevant it is, directly, but it did make me wonder...Does not having "good time" on domUs affect the ability of the kernel to mount filesystems?  Could that be breaking ext4 on a domU with NTP?  And, despite the article's age, is using ext4 with "barriers=0" still valid advice...?

Then...Accidentally, when I had the domU disk device mounted on dom0 (debugging, and forgot to umount before xl create), the domU came up fine--albeit slightly pissed off because it thought that the filesystem had errors.  But, it "repaired" the "errors" just fine (I assume they were related to the double-rw-mount), and booted.

I'm assuming all of this is documented somewhere; I just need a pointer to where to find this info.

===============================================================================

Thanks,
	Q


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 04:44:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 04:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAFS-0002PJ-04; Tue, 14 Feb 2012 04:44:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAFQ-0002PE-Sy
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 04:44:13 +0000
Received: from [193.109.254.147:34241] by server-1.bemta-14.messagelabs.com id
	32/84-12485-C96E93F4; Tue, 14 Feb 2012 04:44:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329194598!52600212!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1NTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18902 invoked from network); 14 Feb 2012 04:43:19 -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; 14 Feb 2012 04:43:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1E4i4O9031216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 04:44:05 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
	q1E4i2aQ004316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 04:44:03 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1E4i2d0007366; Mon, 13 Feb 2012 22:44:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 20:44:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D7CB4031C; Mon, 13 Feb 2012 23:41:03 -0500 (EST)
Date: Mon, 13 Feb 2012 23:41:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <20120214044103.GA24072@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F39E696.0045,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-fixes-3.3 or
 stable/for-linus-fixes-3.3-rc3 (tag) for 3.3-rc3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3873653184300660970=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3873653184300660970==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-fixes-3.3-rc3

or if I screwed up the tagging, the following branch:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-fixes-3.3

which has two fixes for VCPU offlining; One to fix the string format exposed
by the xen-pci[front|back] to conform to the one used in majority of
PCI drivers; two fixes to make the code more resilient to invalid configurations.

Jan Beulich (1):
      xenbus_dev: add missing error check to watch handling

Konrad Rzeszutek Wilk (3):
      xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
      xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
      xen/pci[front|back]: Use %d instead of %1x for displaying PCI devfn.

Stefano Stabellini (1):
      xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback

 arch/x86/pci/xen.c                       |    2 +-
 arch/x86/xen/smp.c                       |    7 +++++++
 drivers/pci/xen-pcifront.c               |   10 +++++-----
 drivers/xen/cpu_hotplug.c                |    3 ++-
 drivers/xen/xen-pciback/pci_stub.c       |    8 ++++----
 drivers/xen/xen-pciback/xenbus.c         |    5 +++--
 drivers/xen/xenbus/xenbus_dev_frontend.c |    4 ++++
 7 files changed, 26 insertions(+), 13 deletions(-)

--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPOeXaAAoJEFjIrFwIi8fJYJYH/ibaujA2OsQR7XRdS8XCK9Kq
XynnOgv0qFWFu0anPpU8gbxNxps/2pVByeILdDeVUVbx1kNnwyYkGyWm5PiUBMcv
Za0W/vlcFm78FUBMp8r9jPfwLNagmuKw/Z53ad8ojnTsERcQ+Ca6KR4RIsVoVqoP
v1/F9a3bWrlWYP32qt3AOTibkoHn8jI25RqdSM5w53/ZosRBBLxMGV51bG2zN0v3
RCzkkYV3RJGPuad0hYHHrVTevrsDE3MXBArmwzu5JTmwwU0GpvnP0z3IMg4xrAN3
QYACMFpnWexZ/9dgP/tsfJlEbq41X3wl+TAg27QBS5JjhHidru2hCm8wj+X7R3I=
=V3bN
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--


--===============3873653184300660970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3873653184300660970==--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 04:44:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 04:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAFS-0002PJ-04; Tue, 14 Feb 2012 04:44:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAFQ-0002PE-Sy
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 04:44:13 +0000
Received: from [193.109.254.147:34241] by server-1.bemta-14.messagelabs.com id
	32/84-12485-C96E93F4; Tue, 14 Feb 2012 04:44:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329194598!52600212!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1NTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18902 invoked from network); 14 Feb 2012 04:43:19 -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; 14 Feb 2012 04:43:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1E4i4O9031216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 04:44:05 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
	q1E4i2aQ004316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 04:44:03 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1E4i2d0007366; Mon, 13 Feb 2012 22:44:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 20:44:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D7CB4031C; Mon, 13 Feb 2012 23:41:03 -0500 (EST)
Date: Mon, 13 Feb 2012 23:41:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <20120214044103.GA24072@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F39E696.0045,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-fixes-3.3 or
 stable/for-linus-fixes-3.3-rc3 (tag) for 3.3-rc3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3873653184300660970=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3873653184300660970==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-fixes-3.3-rc3

or if I screwed up the tagging, the following branch:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-fixes-3.3

which has two fixes for VCPU offlining; One to fix the string format exposed
by the xen-pci[front|back] to conform to the one used in majority of
PCI drivers; two fixes to make the code more resilient to invalid configurations.

Jan Beulich (1):
      xenbus_dev: add missing error check to watch handling

Konrad Rzeszutek Wilk (3):
      xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
      xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
      xen/pci[front|back]: Use %d instead of %1x for displaying PCI devfn.

Stefano Stabellini (1):
      xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback

 arch/x86/pci/xen.c                       |    2 +-
 arch/x86/xen/smp.c                       |    7 +++++++
 drivers/pci/xen-pcifront.c               |   10 +++++-----
 drivers/xen/cpu_hotplug.c                |    3 ++-
 drivers/xen/xen-pciback/pci_stub.c       |    8 ++++----
 drivers/xen/xen-pciback/xenbus.c         |    5 +++--
 drivers/xen/xenbus/xenbus_dev_frontend.c |    4 ++++
 7 files changed, 26 insertions(+), 13 deletions(-)

--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPOeXaAAoJEFjIrFwIi8fJYJYH/ibaujA2OsQR7XRdS8XCK9Kq
XynnOgv0qFWFu0anPpU8gbxNxps/2pVByeILdDeVUVbx1kNnwyYkGyWm5PiUBMcv
Za0W/vlcFm78FUBMp8r9jPfwLNagmuKw/Z53ad8ojnTsERcQ+Ca6KR4RIsVoVqoP
v1/F9a3bWrlWYP32qt3AOTibkoHn8jI25RqdSM5w53/ZosRBBLxMGV51bG2zN0v3
RCzkkYV3RJGPuad0hYHHrVTevrsDE3MXBArmwzu5JTmwwU0GpvnP0z3IMg4xrAN3
QYACMFpnWexZ/9dgP/tsfJlEbq41X3wl+TAg27QBS5JjhHidru2hCm8wj+X7R3I=
=V3bN
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--


--===============3873653184300660970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3873653184300660970==--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeT-00037c-Nl; Tue, 14 Feb 2012 05:10:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAeS-00036X-B3
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:10:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329196195!11352033!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1NTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30807 invoked from network); 14 Feb 2012 05:09:57 -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; 14 Feb 2012 05:09:57 -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 q1E59plM016371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1E59oWK003152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59o6k022981; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 15C6A4035B; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:47 -0500
Message-Id: <1329196009-25268-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F39ECA2.0031,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/3] xen/setup/pm/acpi: Remove the call to
	boot_option_idle_override.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We needed that call in the past to force the kernel to use
default_idle (which called safe_halt, which called xen_safe_halt).

But set_pm_idle_to_default() does now that, so there is no need
to use this boot option operand.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e03c636..1236623 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -420,7 +420,6 @@ void __init xen_arch_setup(void)
 	boot_cpu_data.hlt_works_ok = 1;
 #endif
 	disable_cpuidle();
-	boot_option_idle_override = IDLE_HALT;
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeT-00037c-Nl; Tue, 14 Feb 2012 05:10:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAeS-00036X-B3
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:10:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329196195!11352033!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1NTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30807 invoked from network); 14 Feb 2012 05:09:57 -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; 14 Feb 2012 05:09:57 -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 q1E59plM016371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1E59oWK003152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59o6k022981; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 15C6A4035B; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:47 -0500
Message-Id: <1329196009-25268-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F39ECA2.0031,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/3] xen/setup/pm/acpi: Remove the call to
	boot_option_idle_override.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We needed that call in the past to force the kernel to use
default_idle (which called safe_halt, which called xen_safe_halt).

But set_pm_idle_to_default() does now that, so there is no need
to use this boot option operand.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e03c636..1236623 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -420,7 +420,6 @@ void __init xen_arch_setup(void)
 	boot_cpu_data.hlt_works_ok = 1;
 #endif
 	disable_cpuidle();
-	boot_option_idle_override = IDLE_HALT;
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeT-00037S-Bk; Tue, 14 Feb 2012 05:10:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAeR-00036S-ME
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:10:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329196195!13242121!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzOTYyMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30867 invoked from network); 14 Feb 2012 05:09:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 05:09: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 q1E59ptM026170
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1E59otf009279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59omX004738; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1D3734035E; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:48 -0500
Message-Id: <1329196009-25268-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F39ECA2.004C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and MWAIT_LEAF
	if hypervisor OKs it.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.

For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.

The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.

Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".

With this in place, instead of
 C3 ACPI IOPORT 415
we get now
 C3:ACPI FFH INTEL MWAIT 0x20

Note: The cpu_idle which would be calling the mwait variants for idling
never gets set b/c we set the default pm_idle to be the hypercall variant.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c         |   92 +++++++++++++++++++++++++++++++++++++-
 include/xen/interface/platform.h |    4 +-
 2 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..4c82936 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -62,6 +62,14 @@
 #include <asm/reboot.h>
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
+#include <asm/mwait.h>
+
+#ifdef CONFIG_ACPI
+#include <asm/acpi.h>
+#include <acpi/pdc_intel.h>
+#include <acpi/processor.h>
+#include <xen/interface/platform.h>
+#endif
 
 #include "xen-ops.h"
 #include "mmu.h"
@@ -200,13 +208,17 @@ static void __init xen_banner(void)
 static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
 static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
 
+static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask;
+static __read_mostly unsigned int cpuid_leaf5_ecx_val;
+static __read_mostly unsigned int cpuid_leaf5_edx_val;
+
 static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		      unsigned int *cx, unsigned int *dx)
 {
 	unsigned maskebx = ~0;
 	unsigned maskecx = ~0;
 	unsigned maskedx = ~0;
-
+	unsigned setecx = 0;
 	/*
 	 * Mask out inconvenient features, to try and disable as many
 	 * unsupported kernel subsystems as possible.
@@ -214,9 +226,18 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 	switch (*ax) {
 	case 1:
 		maskecx = cpuid_leaf1_ecx_mask;
+		setecx = cpuid_leaf1_ecx_set_mask;
 		maskedx = cpuid_leaf1_edx_mask;
 		break;
 
+	case CPUID_MWAIT_LEAF:
+		/* Synthesize the values.. */
+		*ax = 0;
+		*bx = 0;
+		*cx = cpuid_leaf5_ecx_val;
+		*dx = cpuid_leaf5_edx_val;
+		return;
+
 	case 0xb:
 		/* Suppress extended topology stuff */
 		maskebx = 0;
@@ -232,9 +253,75 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 
 	*bx &= maskebx;
 	*cx &= maskecx;
+	*cx |= setecx;
 	*dx &= maskedx;
+
 }
 
+static bool __init xen_check_mwait(void)
+{
+#if CONFIG_ACPI
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.u.set_pminfo.id	= -1,
+		.u.set_pminfo.type	= XEN_PM_PDC,
+	};
+	uint32_t buf[3];
+	unsigned int ax, bx, cx, dx;
+	unsigned int mwait_mask;
+
+	/* We need to determine whether it is OK to expose the MWAIT
+	 * capability to the kernel to harvest deeper than C3 states from ACPI
+	 * _CST using the processor_harvest.c module. For this to work, we
+	 * need to gather the MWAIT_LEAF values (which the cstate.c code
+	 * checks against). The hypervisor won't expose the MWAIT flag because
+	 * it would break backwards compatibility; so we will find out directly
+	 * from the hardware and hypercall.
+	 */
+	if (!xen_initial_domain())
+		return false;
+
+	ax = 1;
+	cx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	mwait_mask = (1 << (X86_FEATURE_EST % 32)) |
+		     (1 << (X86_FEATURE_MWAIT % 32));
+
+	if ((cx & mwait_mask) != mwait_mask)
+		return false;
+
+	/* We need to emulate the MWAIT_LEAF and for that we need both
+	 * ecx and edx. The hypercall provides only partial information.
+	 */
+
+	ax = CPUID_MWAIT_LEAF;
+	bx = 0;
+	cx = 0;
+	dx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	/* Ask the Hypervisor whether to clear ACPI_PDC_C_C2C3_FFH. If so,
+	 * don't expose MWAIT_LEAF and let ACPI pick the IOPORT version of C3.
+	 */
+	buf[0] = ACPI_PDC_REVISION_ID;
+	buf[1] = 1;
+	buf[2] = (ACPI_PDC_C_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_SWSMP);
+
+	set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
+
+	if ((HYPERVISOR_dom0_op(&op) == 0) &&
+	    (buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
+		cpuid_leaf5_ecx_val = cx;
+		cpuid_leaf5_edx_val = dx;
+	}
+	return true;
+#else
+	return false;
+#endif
+}
 static void __init xen_init_cpuid_mask(void)
 {
 	unsigned int ax, bx, cx, dx;
@@ -261,6 +348,9 @@ static void __init xen_init_cpuid_mask(void)
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 	if ((cx & xsave_mask) != xsave_mask)
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
+
+	if (xen_check_mwait())
+		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
 }
 
 static void xen_set_debugreg(int reg, unsigned long val)
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..6220b98 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -200,7 +200,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PM_CX   0
 #define XEN_PM_PX   1
 #define XEN_PM_TX   2
-
+#define XEN_PM_PDC  3
 /* Px sub info type */
 #define XEN_PX_PCT   1
 #define XEN_PX_PSS   2
@@ -286,6 +286,7 @@ struct xen_processor_performance {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
 
+DEFINE_GUEST_HANDLE(uint32_t);
 struct xenpf_set_processor_pminfo {
 	/* IN variables */
 	uint32_t id;    /* ACPI CPU ID */
@@ -293,6 +294,7 @@ struct xenpf_set_processor_pminfo {
 	union {
 		struct xen_processor_power          power;/* Cx: _CST/_CSD */
 		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
+		GUEST_HANDLE(uint32_t)              pdc;
 	};
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeT-00037S-Bk; Tue, 14 Feb 2012 05:10:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAeR-00036S-ME
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:10:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329196195!13242121!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzOTYyMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30867 invoked from network); 14 Feb 2012 05:09:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 05:09: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 q1E59ptM026170
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1E59otf009279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59omX004738; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1D3734035E; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:48 -0500
Message-Id: <1329196009-25268-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F39ECA2.004C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and MWAIT_LEAF
	if hypervisor OKs it.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.

For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.

The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.

Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".

With this in place, instead of
 C3 ACPI IOPORT 415
we get now
 C3:ACPI FFH INTEL MWAIT 0x20

Note: The cpu_idle which would be calling the mwait variants for idling
never gets set b/c we set the default pm_idle to be the hypercall variant.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c         |   92 +++++++++++++++++++++++++++++++++++++-
 include/xen/interface/platform.h |    4 +-
 2 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..4c82936 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -62,6 +62,14 @@
 #include <asm/reboot.h>
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
+#include <asm/mwait.h>
+
+#ifdef CONFIG_ACPI
+#include <asm/acpi.h>
+#include <acpi/pdc_intel.h>
+#include <acpi/processor.h>
+#include <xen/interface/platform.h>
+#endif
 
 #include "xen-ops.h"
 #include "mmu.h"
@@ -200,13 +208,17 @@ static void __init xen_banner(void)
 static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
 static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
 
+static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask;
+static __read_mostly unsigned int cpuid_leaf5_ecx_val;
+static __read_mostly unsigned int cpuid_leaf5_edx_val;
+
 static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		      unsigned int *cx, unsigned int *dx)
 {
 	unsigned maskebx = ~0;
 	unsigned maskecx = ~0;
 	unsigned maskedx = ~0;
-
+	unsigned setecx = 0;
 	/*
 	 * Mask out inconvenient features, to try and disable as many
 	 * unsupported kernel subsystems as possible.
@@ -214,9 +226,18 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 	switch (*ax) {
 	case 1:
 		maskecx = cpuid_leaf1_ecx_mask;
+		setecx = cpuid_leaf1_ecx_set_mask;
 		maskedx = cpuid_leaf1_edx_mask;
 		break;
 
+	case CPUID_MWAIT_LEAF:
+		/* Synthesize the values.. */
+		*ax = 0;
+		*bx = 0;
+		*cx = cpuid_leaf5_ecx_val;
+		*dx = cpuid_leaf5_edx_val;
+		return;
+
 	case 0xb:
 		/* Suppress extended topology stuff */
 		maskebx = 0;
@@ -232,9 +253,75 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 
 	*bx &= maskebx;
 	*cx &= maskecx;
+	*cx |= setecx;
 	*dx &= maskedx;
+
 }
 
+static bool __init xen_check_mwait(void)
+{
+#if CONFIG_ACPI
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.u.set_pminfo.id	= -1,
+		.u.set_pminfo.type	= XEN_PM_PDC,
+	};
+	uint32_t buf[3];
+	unsigned int ax, bx, cx, dx;
+	unsigned int mwait_mask;
+
+	/* We need to determine whether it is OK to expose the MWAIT
+	 * capability to the kernel to harvest deeper than C3 states from ACPI
+	 * _CST using the processor_harvest.c module. For this to work, we
+	 * need to gather the MWAIT_LEAF values (which the cstate.c code
+	 * checks against). The hypervisor won't expose the MWAIT flag because
+	 * it would break backwards compatibility; so we will find out directly
+	 * from the hardware and hypercall.
+	 */
+	if (!xen_initial_domain())
+		return false;
+
+	ax = 1;
+	cx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	mwait_mask = (1 << (X86_FEATURE_EST % 32)) |
+		     (1 << (X86_FEATURE_MWAIT % 32));
+
+	if ((cx & mwait_mask) != mwait_mask)
+		return false;
+
+	/* We need to emulate the MWAIT_LEAF and for that we need both
+	 * ecx and edx. The hypercall provides only partial information.
+	 */
+
+	ax = CPUID_MWAIT_LEAF;
+	bx = 0;
+	cx = 0;
+	dx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	/* Ask the Hypervisor whether to clear ACPI_PDC_C_C2C3_FFH. If so,
+	 * don't expose MWAIT_LEAF and let ACPI pick the IOPORT version of C3.
+	 */
+	buf[0] = ACPI_PDC_REVISION_ID;
+	buf[1] = 1;
+	buf[2] = (ACPI_PDC_C_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_SWSMP);
+
+	set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
+
+	if ((HYPERVISOR_dom0_op(&op) == 0) &&
+	    (buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
+		cpuid_leaf5_ecx_val = cx;
+		cpuid_leaf5_edx_val = dx;
+	}
+	return true;
+#else
+	return false;
+#endif
+}
 static void __init xen_init_cpuid_mask(void)
 {
 	unsigned int ax, bx, cx, dx;
@@ -261,6 +348,9 @@ static void __init xen_init_cpuid_mask(void)
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 	if ((cx & xsave_mask) != xsave_mask)
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
+
+	if (xen_check_mwait())
+		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
 }
 
 static void xen_set_debugreg(int reg, unsigned long val)
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..6220b98 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -200,7 +200,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PM_CX   0
 #define XEN_PM_PX   1
 #define XEN_PM_TX   2
-
+#define XEN_PM_PDC  3
 /* Px sub info type */
 #define XEN_PX_PCT   1
 #define XEN_PX_PSS   2
@@ -286,6 +286,7 @@ struct xen_processor_performance {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
 
+DEFINE_GUEST_HANDLE(uint32_t);
 struct xenpf_set_processor_pminfo {
 	/* IN variables */
 	uint32_t id;    /* ACPI CPU ID */
@@ -293,6 +294,7 @@ struct xenpf_set_processor_pminfo {
 	union {
 		struct xen_processor_power          power;/* Cx: _CST/_CSD */
 		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
+		GUEST_HANDLE(uint32_t)              pdc;
 	};
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeQ-00036s-Ol; Tue, 14 Feb 2012 05:10: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 1RxAeN-00036c-Vm
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:10:00 +0000
Received: from [85.158.143.35:39322] by server-1.bemta-4.messagelabs.com id
	1C/0D-20925-7ACE93F4; Tue, 14 Feb 2012 05:09:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329196195!2727395!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1NTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 14 Feb 2012 05:09:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 05:09: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 q1E59qO9016376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:54 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
	q1E59p7U009287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59oJZ021803; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 27C7340434; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:49 -0500
Message-Id: <1329196009-25268-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F39ECA2.008D,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/3] xen/acpi/cpufreq: Provide an driver that
	passes struct acpi_processor data to the hypervisor.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'struct acpi_processor' per-cpu structure.
We read the contents of that structure and pass it up the Xen hypervisor.

The ACPI processor along with the CPU freq driver does all the heavy-lifting
for us (filtering, calling ACPI functions, etc) so that the contents is correct.
After we are done parsing the information, we wait in case of hotplug CPUs
get loaded and then pass that information to the hypervisor.

Note: There is no good way to deal with dom0_max_vcpus=X parameter where
the initial domain is limited to a smaller subset of CPUs.

A lot of the code to pass the information to the hypervisor was copied from
https://lkml.org/lkml/2011/11/30/245 so many thanks to

 Yu Ke <ke.yu@intel.com>
 Tian Kevin <kevin.tian@intel.com>

[TODO: Should their names be in the code as Authors? Or just have the
same comment as what I mentioned in the commit?]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig             |   14 ++
 drivers/xen/Makefile            |    2 +-
 drivers/xen/processor-harvest.c |  397 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 412 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/processor-harvest.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..126183f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,18 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
 
+config XEN_PROCESSOR_HARVEST
+	tristate "Processor passthrough driver for Xen"
+	depends on XEN
+	depends on ACPI_PROCESSOR
+	depends on X86
+	depends on CPU_FREQ
+	help
+	  This driver parses the processor structure and passes the information
+	  to the Xen hypervisor. It is used to allow the Xen hypervisor to have the
+	  full power management data and be able to select proper Cx and Pxx states.
+
+	  The driver should be loaded after acpi processor and cpufreq drivers have
+	  been loaded. If you do not know what to choose, select M here.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..856cfc6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-
+obj-$(CONFIG_XEN_PROCESSOR_HARVEST)	+= processor-harvest.o
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
diff --git a/drivers/xen/processor-harvest.c b/drivers/xen/processor-harvest.c
new file mode 100644
index 0000000..50681e2
--- /dev/null
+++ b/drivers/xen/processor-harvest.c
@@ -0,0 +1,397 @@
+/*
+ * Copyright 2012 by Oracle Inc
+ * Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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.
+ *
+ */
+
+/*
+ *  Known limitations
+ *
+ * The driver can only handle up to  for_each_possible_cpu().
+ * Meaning if you boot with dom0_max_cpus=X it will _only_ parse up to X
+ * processors.
+ */
+
+#include <linux/cpumask.h>
+#include <linux/cpufreq.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME "processor-passthrough-xen"
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
+MODULE_DESCRIPTION("ACPI Power Management driver to pass Cx and Pxx data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+
+MODULE_PARM_DESC(off, "Inhibit the hypercall.");
+static int no_hypercall;
+module_param_named(off, no_hypercall, int, 0400);
+
+static DEFINE_MUTEX(processors_done_mutex);
+static DECLARE_BITMAP(processors_done, NR_CPUS);
+
+#define POLL_TIMER msecs_to_jiffies(5000 /* 5 sec */)
+static struct task_struct *xen_processor_thread;
+
+static int xen_push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *xen_cx, *xen_cx_states = NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret = 0;
+
+	xen_cx_states = kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!xen_cx_states)
+		return -ENOMEM;
+
+	for (ok = 0, i = 1; i <= _pr->power.count; i++) {
+		cx = &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		xen_cx = &(xen_cx_states[ok++]);
+
+		xen_cx->reg.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) {
+			xen_cx->reg.bit_width = 8;
+			xen_cx->reg.bit_offset = 0;
+			xen_cx->reg.access_size = 1;
+		} else {
+			xen_cx->reg.space_id = ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method == ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				xen_cx->reg.bit_offset = 2;
+				xen_cx->reg.bit_width = 1; /* VENDOR_INTEL */
+			}
+			xen_cx->reg.access_size = 0;
+		}
+		xen_cx->reg.address = cx->address;
+
+		xen_cx->type = cx->type;
+		xen_cx->latency = cx->latency;
+		xen_cx->power = cx->power;
+
+		xen_cx->dpcnt = 0;
+		set_xen_guest_handle(xen_cx->dp, NULL);
+#ifdef DEBUG
+		pr_debug(DRV_NAME ": CX: ID:%d [C%d:%s] entry:%d\n", _pr->acpi_id,
+			 cx->type, cx->desc, cx->entry_method);
+#endif
+	}
+	if (!ok) {
+		pr_err(DRV_NAME ": No available Cx info for cpu %d\n", _pr->acpi_id);
+		kfree(xen_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count = ok;
+	op.u.set_pminfo.power.flags.bm_control = _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, xen_cx_states);
+
+	if (!no_hypercall && xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (ret) {
+		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
+		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
+				     sizeof(struct xen_platform_op));
+		print_hex_dump_bytes("Cx: ", DUMP_PREFIX_NONE, xen_cx_states,
+				     _pr->power.count *
+				     sizeof(struct xen_processor_cx));
+	}
+	kfree(xen_cx_states);
+
+	return ret;
+}
+
+
+
+static struct xen_processor_px *xen_copy_pss_data(struct acpi_processor *_pr,
+						  struct xen_processor_performance *xen_perf)
+{
+	struct xen_processor_px *xen_states = NULL;
+	int i;
+
+	xen_states = kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!xen_states)
+		return ERR_PTR(-ENOMEM);
+
+	xen_perf->state_count = _pr->performance->state_count;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=
+		     sizeof(struct acpi_processor_px));
+	for (i = 0; i < _pr->performance->state_count; i++) {
+
+		/* Fortunatly for us, they both have the same size */
+		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+	}
+	return xen_states;
+}
+static int xen_copy_psd_data(struct acpi_processor *_pr,
+			     struct xen_processor_performance *xen_perf)
+{
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=
+		     sizeof(struct acpi_psd_package));
+
+	if (_pr->performance->shared_type != CPUFREQ_SHARED_TYPE_NONE) {
+		xen_perf->shared_type = _pr->performance->shared_type;
+
+		memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
+		       sizeof(struct acpi_psd_package));
+	} else {
+		if ((&cpu_data(0))->x86_vendor != X86_VENDOR_AMD)
+			return -EINVAL;
+
+		/* On AMD, the powernow-k8 is loaded before acpi_cpufreq
+		 * meaning that acpi_processor_preregister_performance never
+		 * gets called which would parse the _CST.
+		 */
+		xen_perf->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+		xen_perf->domain_info.num_processors = num_online_cpus();
+	}
+	return 0;
+}
+static int xen_copy_pct_data(struct acpi_pct_register *pct,
+			     struct xen_pct_register *_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, _pct') but
+	 * sadly the Xen structure did not have the proper padding
+	 * so the descriptor field takes two (_pct) bytes instead of one (pct).
+	 */
+	_pct->descriptor = pct->descriptor;
+	_pct->length = pct->length;
+	_pct->space_id = pct->space_id;
+	_pct->bit_width = pct->bit_width;
+	_pct->bit_offset = pct->bit_offset;
+	_pct->reserved = pct->reserved;
+	_pct->address = pct->address;
+	return 0;
+}
+static int xen_push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret = 0;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *xen_perf;
+	struct xen_processor_px *xen_states = NULL;
+
+	xen_perf = &op.u.set_pminfo.perf;
+
+	xen_perf->platform_limit = _pr->performance_platform_limit;
+	xen_perf->flags |= XEN_PX_PPC;
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &xen_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &xen_perf->status_register);
+	xen_perf->flags |= XEN_PX_PCT;
+	xen_states = xen_copy_pss_data(_pr, xen_perf);
+	if (!IS_ERR_OR_NULL(xen_states)) {
+		set_xen_guest_handle(xen_perf->states, xen_states);
+		xen_perf->flags |= XEN_PX_PSS;
+	}
+	if (!xen_copy_psd_data(_pr, xen_perf))
+		xen_perf->flags |= XEN_PX_PSD;
+
+	if (!no_hypercall && xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (ret) {
+		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
+		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
+				     sizeof(struct xen_platform_op));
+		if (!IS_ERR_OR_NULL(xen_states))
+			print_hex_dump_bytes("Pxx:", DUMP_PREFIX_NONE, xen_states,
+				     _pr->performance->state_count *
+				     sizeof(struct xen_processor_px));
+	}
+	if (!IS_ERR_OR_NULL(xen_states))
+		kfree(xen_states);
+
+	return ret;
+}
+/*
+ * We read out the struct acpi_processor, and serialize access
+ * so that there is only one caller. This is so that we won't
+ * race with the CPU hotplug code.
+ */
+static int xen_process_data(struct acpi_processor *_pr, int cpu)
+{
+	int err = 0;
+
+	mutex_lock(&processors_done_mutex);
+	if (cpumask_test_cpu(cpu, to_cpumask(processors_done))) {
+		mutex_unlock(&processors_done_mutex);
+		return -EBUSY;
+	}
+	if (_pr->flags.power)
+		err = xen_push_cxx_to_hypervisor(_pr);
+
+	if (_pr->performance && _pr->performance->states)
+		err |= xen_push_pxx_to_hypervisor(_pr);
+
+	cpumask_set_cpu(cpu, to_cpumask(processors_done));
+	mutex_unlock(&processors_done_mutex);
+	return err;
+}
+
+static int xen_processor_check(void)
+{
+	struct cpufreq_policy *policy;
+	int cpu;
+
+	policy = cpufreq_cpu_get(smp_processor_id());
+	if (!policy)
+		return -EBUSY;
+
+	get_online_cpus();
+	for_each_online_cpu(cpu) {
+		struct acpi_processor *_pr;
+
+		_pr = per_cpu(processors, cpu);
+		if (!_pr)
+			continue;
+
+		(void)xen_process_data(_pr, cpu);
+	}
+	put_online_cpus();
+
+	cpufreq_cpu_put(policy);
+	return 0;
+}
+/*
+ * The purpose of this timer/thread is to wait for the ACPI processor
+ * and CPUfreq drivers to load up and parse the Pxx and Cxx information
+ * before we attempt to read it.
+ */
+static void xen_processor_timeout(unsigned long arg)
+{
+	wake_up_process((struct task_struct *)arg);
+}
+static int xen_processor_thread_func(void *dummy)
+{
+	struct timer_list timer;
+
+	setup_deferrable_timer_on_stack(&timer, xen_processor_timeout,
+					(unsigned long)current);
+
+	do {
+		__set_current_state(TASK_INTERRUPTIBLE);
+		mod_timer(&timer, jiffies + POLL_TIMER);
+		schedule();
+		if (xen_processor_check() != -EBUSY)
+			break;
+	} while (!kthread_should_stop());
+
+	del_timer_sync(&timer);
+	destroy_timer_on_stack(&timer);
+	return 0;
+}
+
+static int xen_cpu_soft_notify(struct notifier_block *nfb,
+			       unsigned long action, void *hcpu)
+{
+	unsigned int cpu = (unsigned long)hcpu;
+	struct acpi_processor *_pr = per_cpu(processors, cpu);
+
+	if (action == CPU_ONLINE && _pr)
+		(void)xen_process_data(_pr, cpu);
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block xen_cpu_notifier = {
+	.notifier_call = xen_cpu_soft_notify,
+	.priority = -1, /* Be the last one */
+};
+
+static int __init check_prereq(void)
+{
+	struct cpuinfo_x86 *c = &cpu_data(0);
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	if (!acpi_gbl_FADT.smi_command)
+		return -ENODEV;
+
+	if (c->x86_vendor == X86_VENDOR_INTEL) {
+		if (!cpu_has(c, X86_FEATURE_EST))
+			return -ENODEV;
+
+		return 0;
+	}
+	if (c->x86_vendor == X86_VENDOR_AMD) {
+		u32 hi = 0, lo = 0;
+		/* Copied from powernow-k8.h, can't include ../cpufreq/powernow
+		 * as we get compile warnings for the static functions.
+		 */
+#define MSR_PSTATE_CUR_LIMIT    0xc0010061 /* pstate current limit MSR */
+		rdmsr(MSR_PSTATE_CUR_LIMIT, lo, hi);
+
+		/* If the MSR cannot provide the data, the powernow-k8
+		 * won't process the data properly either.
+		 */
+		if (hi || lo)
+			return 0;
+	}
+	return -ENODEV;
+}
+
+static int __init xen_processor_passthrough_init(void)
+{
+	int rc = check_prereq();
+
+	if (rc)
+		return rc;
+
+	xen_processor_thread = kthread_run(xen_processor_thread_func, NULL, DRV_NAME);
+	if (IS_ERR(xen_processor_thread)) {
+		pr_err(DRV_NAME ": Failed to create thread. Aborting.\n");
+		return -ENOMEM;
+	}
+	register_hotcpu_notifier(&xen_cpu_notifier);
+	return 0;
+}
+static void __exit xen_processor_passthrough_exit(void)
+{
+	unregister_hotcpu_notifier(&xen_cpu_notifier);
+	if (xen_processor_thread)
+		kthread_stop(xen_processor_thread);
+}
+late_initcall(xen_processor_passthrough_init);
+module_exit(xen_processor_passthrough_exit);
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeQ-00036s-Ol; Tue, 14 Feb 2012 05:10: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 1RxAeN-00036c-Vm
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:10:00 +0000
Received: from [85.158.143.35:39322] by server-1.bemta-4.messagelabs.com id
	1C/0D-20925-7ACE93F4; Tue, 14 Feb 2012 05:09:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329196195!2727395!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTM1NTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 14 Feb 2012 05:09:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 05:09: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 q1E59qO9016376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:54 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
	q1E59p7U009287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59oJZ021803; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 27C7340434; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:49 -0500
Message-Id: <1329196009-25268-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F39ECA2.008D,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/3] xen/acpi/cpufreq: Provide an driver that
	passes struct acpi_processor data to the hypervisor.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'struct acpi_processor' per-cpu structure.
We read the contents of that structure and pass it up the Xen hypervisor.

The ACPI processor along with the CPU freq driver does all the heavy-lifting
for us (filtering, calling ACPI functions, etc) so that the contents is correct.
After we are done parsing the information, we wait in case of hotplug CPUs
get loaded and then pass that information to the hypervisor.

Note: There is no good way to deal with dom0_max_vcpus=X parameter where
the initial domain is limited to a smaller subset of CPUs.

A lot of the code to pass the information to the hypervisor was copied from
https://lkml.org/lkml/2011/11/30/245 so many thanks to

 Yu Ke <ke.yu@intel.com>
 Tian Kevin <kevin.tian@intel.com>

[TODO: Should their names be in the code as Authors? Or just have the
same comment as what I mentioned in the commit?]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig             |   14 ++
 drivers/xen/Makefile            |    2 +-
 drivers/xen/processor-harvest.c |  397 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 412 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/processor-harvest.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..126183f 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,18 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
 
+config XEN_PROCESSOR_HARVEST
+	tristate "Processor passthrough driver for Xen"
+	depends on XEN
+	depends on ACPI_PROCESSOR
+	depends on X86
+	depends on CPU_FREQ
+	help
+	  This driver parses the processor structure and passes the information
+	  to the Xen hypervisor. It is used to allow the Xen hypervisor to have the
+	  full power management data and be able to select proper Cx and Pxx states.
+
+	  The driver should be loaded after acpi processor and cpufreq drivers have
+	  been loaded. If you do not know what to choose, select M here.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..856cfc6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-
+obj-$(CONFIG_XEN_PROCESSOR_HARVEST)	+= processor-harvest.o
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
diff --git a/drivers/xen/processor-harvest.c b/drivers/xen/processor-harvest.c
new file mode 100644
index 0000000..50681e2
--- /dev/null
+++ b/drivers/xen/processor-harvest.c
@@ -0,0 +1,397 @@
+/*
+ * Copyright 2012 by Oracle Inc
+ * Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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.
+ *
+ */
+
+/*
+ *  Known limitations
+ *
+ * The driver can only handle up to  for_each_possible_cpu().
+ * Meaning if you boot with dom0_max_cpus=X it will _only_ parse up to X
+ * processors.
+ */
+
+#include <linux/cpumask.h>
+#include <linux/cpufreq.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME "processor-passthrough-xen"
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
+MODULE_DESCRIPTION("ACPI Power Management driver to pass Cx and Pxx data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+
+MODULE_PARM_DESC(off, "Inhibit the hypercall.");
+static int no_hypercall;
+module_param_named(off, no_hypercall, int, 0400);
+
+static DEFINE_MUTEX(processors_done_mutex);
+static DECLARE_BITMAP(processors_done, NR_CPUS);
+
+#define POLL_TIMER msecs_to_jiffies(5000 /* 5 sec */)
+static struct task_struct *xen_processor_thread;
+
+static int xen_push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *xen_cx, *xen_cx_states = NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret = 0;
+
+	xen_cx_states = kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!xen_cx_states)
+		return -ENOMEM;
+
+	for (ok = 0, i = 1; i <= _pr->power.count; i++) {
+		cx = &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		xen_cx = &(xen_cx_states[ok++]);
+
+		xen_cx->reg.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) {
+			xen_cx->reg.bit_width = 8;
+			xen_cx->reg.bit_offset = 0;
+			xen_cx->reg.access_size = 1;
+		} else {
+			xen_cx->reg.space_id = ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method == ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				xen_cx->reg.bit_offset = 2;
+				xen_cx->reg.bit_width = 1; /* VENDOR_INTEL */
+			}
+			xen_cx->reg.access_size = 0;
+		}
+		xen_cx->reg.address = cx->address;
+
+		xen_cx->type = cx->type;
+		xen_cx->latency = cx->latency;
+		xen_cx->power = cx->power;
+
+		xen_cx->dpcnt = 0;
+		set_xen_guest_handle(xen_cx->dp, NULL);
+#ifdef DEBUG
+		pr_debug(DRV_NAME ": CX: ID:%d [C%d:%s] entry:%d\n", _pr->acpi_id,
+			 cx->type, cx->desc, cx->entry_method);
+#endif
+	}
+	if (!ok) {
+		pr_err(DRV_NAME ": No available Cx info for cpu %d\n", _pr->acpi_id);
+		kfree(xen_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count = ok;
+	op.u.set_pminfo.power.flags.bm_control = _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, xen_cx_states);
+
+	if (!no_hypercall && xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (ret) {
+		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
+		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
+				     sizeof(struct xen_platform_op));
+		print_hex_dump_bytes("Cx: ", DUMP_PREFIX_NONE, xen_cx_states,
+				     _pr->power.count *
+				     sizeof(struct xen_processor_cx));
+	}
+	kfree(xen_cx_states);
+
+	return ret;
+}
+
+
+
+static struct xen_processor_px *xen_copy_pss_data(struct acpi_processor *_pr,
+						  struct xen_processor_performance *xen_perf)
+{
+	struct xen_processor_px *xen_states = NULL;
+	int i;
+
+	xen_states = kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!xen_states)
+		return ERR_PTR(-ENOMEM);
+
+	xen_perf->state_count = _pr->performance->state_count;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=
+		     sizeof(struct acpi_processor_px));
+	for (i = 0; i < _pr->performance->state_count; i++) {
+
+		/* Fortunatly for us, they both have the same size */
+		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+	}
+	return xen_states;
+}
+static int xen_copy_psd_data(struct acpi_processor *_pr,
+			     struct xen_processor_performance *xen_perf)
+{
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=
+		     sizeof(struct acpi_psd_package));
+
+	if (_pr->performance->shared_type != CPUFREQ_SHARED_TYPE_NONE) {
+		xen_perf->shared_type = _pr->performance->shared_type;
+
+		memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
+		       sizeof(struct acpi_psd_package));
+	} else {
+		if ((&cpu_data(0))->x86_vendor != X86_VENDOR_AMD)
+			return -EINVAL;
+
+		/* On AMD, the powernow-k8 is loaded before acpi_cpufreq
+		 * meaning that acpi_processor_preregister_performance never
+		 * gets called which would parse the _CST.
+		 */
+		xen_perf->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+		xen_perf->domain_info.num_processors = num_online_cpus();
+	}
+	return 0;
+}
+static int xen_copy_pct_data(struct acpi_pct_register *pct,
+			     struct xen_pct_register *_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, _pct') but
+	 * sadly the Xen structure did not have the proper padding
+	 * so the descriptor field takes two (_pct) bytes instead of one (pct).
+	 */
+	_pct->descriptor = pct->descriptor;
+	_pct->length = pct->length;
+	_pct->space_id = pct->space_id;
+	_pct->bit_width = pct->bit_width;
+	_pct->bit_offset = pct->bit_offset;
+	_pct->reserved = pct->reserved;
+	_pct->address = pct->address;
+	return 0;
+}
+static int xen_push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret = 0;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *xen_perf;
+	struct xen_processor_px *xen_states = NULL;
+
+	xen_perf = &op.u.set_pminfo.perf;
+
+	xen_perf->platform_limit = _pr->performance_platform_limit;
+	xen_perf->flags |= XEN_PX_PPC;
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &xen_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &xen_perf->status_register);
+	xen_perf->flags |= XEN_PX_PCT;
+	xen_states = xen_copy_pss_data(_pr, xen_perf);
+	if (!IS_ERR_OR_NULL(xen_states)) {
+		set_xen_guest_handle(xen_perf->states, xen_states);
+		xen_perf->flags |= XEN_PX_PSS;
+	}
+	if (!xen_copy_psd_data(_pr, xen_perf))
+		xen_perf->flags |= XEN_PX_PSD;
+
+	if (!no_hypercall && xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (ret) {
+		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
+		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
+				     sizeof(struct xen_platform_op));
+		if (!IS_ERR_OR_NULL(xen_states))
+			print_hex_dump_bytes("Pxx:", DUMP_PREFIX_NONE, xen_states,
+				     _pr->performance->state_count *
+				     sizeof(struct xen_processor_px));
+	}
+	if (!IS_ERR_OR_NULL(xen_states))
+		kfree(xen_states);
+
+	return ret;
+}
+/*
+ * We read out the struct acpi_processor, and serialize access
+ * so that there is only one caller. This is so that we won't
+ * race with the CPU hotplug code.
+ */
+static int xen_process_data(struct acpi_processor *_pr, int cpu)
+{
+	int err = 0;
+
+	mutex_lock(&processors_done_mutex);
+	if (cpumask_test_cpu(cpu, to_cpumask(processors_done))) {
+		mutex_unlock(&processors_done_mutex);
+		return -EBUSY;
+	}
+	if (_pr->flags.power)
+		err = xen_push_cxx_to_hypervisor(_pr);
+
+	if (_pr->performance && _pr->performance->states)
+		err |= xen_push_pxx_to_hypervisor(_pr);
+
+	cpumask_set_cpu(cpu, to_cpumask(processors_done));
+	mutex_unlock(&processors_done_mutex);
+	return err;
+}
+
+static int xen_processor_check(void)
+{
+	struct cpufreq_policy *policy;
+	int cpu;
+
+	policy = cpufreq_cpu_get(smp_processor_id());
+	if (!policy)
+		return -EBUSY;
+
+	get_online_cpus();
+	for_each_online_cpu(cpu) {
+		struct acpi_processor *_pr;
+
+		_pr = per_cpu(processors, cpu);
+		if (!_pr)
+			continue;
+
+		(void)xen_process_data(_pr, cpu);
+	}
+	put_online_cpus();
+
+	cpufreq_cpu_put(policy);
+	return 0;
+}
+/*
+ * The purpose of this timer/thread is to wait for the ACPI processor
+ * and CPUfreq drivers to load up and parse the Pxx and Cxx information
+ * before we attempt to read it.
+ */
+static void xen_processor_timeout(unsigned long arg)
+{
+	wake_up_process((struct task_struct *)arg);
+}
+static int xen_processor_thread_func(void *dummy)
+{
+	struct timer_list timer;
+
+	setup_deferrable_timer_on_stack(&timer, xen_processor_timeout,
+					(unsigned long)current);
+
+	do {
+		__set_current_state(TASK_INTERRUPTIBLE);
+		mod_timer(&timer, jiffies + POLL_TIMER);
+		schedule();
+		if (xen_processor_check() != -EBUSY)
+			break;
+	} while (!kthread_should_stop());
+
+	del_timer_sync(&timer);
+	destroy_timer_on_stack(&timer);
+	return 0;
+}
+
+static int xen_cpu_soft_notify(struct notifier_block *nfb,
+			       unsigned long action, void *hcpu)
+{
+	unsigned int cpu = (unsigned long)hcpu;
+	struct acpi_processor *_pr = per_cpu(processors, cpu);
+
+	if (action == CPU_ONLINE && _pr)
+		(void)xen_process_data(_pr, cpu);
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block xen_cpu_notifier = {
+	.notifier_call = xen_cpu_soft_notify,
+	.priority = -1, /* Be the last one */
+};
+
+static int __init check_prereq(void)
+{
+	struct cpuinfo_x86 *c = &cpu_data(0);
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	if (!acpi_gbl_FADT.smi_command)
+		return -ENODEV;
+
+	if (c->x86_vendor == X86_VENDOR_INTEL) {
+		if (!cpu_has(c, X86_FEATURE_EST))
+			return -ENODEV;
+
+		return 0;
+	}
+	if (c->x86_vendor == X86_VENDOR_AMD) {
+		u32 hi = 0, lo = 0;
+		/* Copied from powernow-k8.h, can't include ../cpufreq/powernow
+		 * as we get compile warnings for the static functions.
+		 */
+#define MSR_PSTATE_CUR_LIMIT    0xc0010061 /* pstate current limit MSR */
+		rdmsr(MSR_PSTATE_CUR_LIMIT, lo, hi);
+
+		/* If the MSR cannot provide the data, the powernow-k8
+		 * won't process the data properly either.
+		 */
+		if (hi || lo)
+			return 0;
+	}
+	return -ENODEV;
+}
+
+static int __init xen_processor_passthrough_init(void)
+{
+	int rc = check_prereq();
+
+	if (rc)
+		return rc;
+
+	xen_processor_thread = kthread_run(xen_processor_thread_func, NULL, DRV_NAME);
+	if (IS_ERR(xen_processor_thread)) {
+		pr_err(DRV_NAME ": Failed to create thread. Aborting.\n");
+		return -ENOMEM;
+	}
+	register_hotcpu_notifier(&xen_cpu_notifier);
+	return 0;
+}
+static void __exit xen_processor_passthrough_exit(void)
+{
+	unregister_hotcpu_notifier(&xen_cpu_notifier);
+	if (xen_processor_thread)
+		kthread_stop(xen_processor_thread);
+}
+late_initcall(xen_processor_passthrough_init);
+module_exit(xen_processor_passthrough_exit);
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeN-00036Y-BW; Tue, 14 Feb 2012 05:09:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAeL-00036R-RV
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:09:58 +0000
Received: from [85.158.139.83:44396] by server-9.bemta-5.messagelabs.com id
	60/42-30171-5ACE93F4; Tue, 14 Feb 2012 05:09:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329196195!14930951!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzOTYyMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 926 invoked from network); 14 Feb 2012 05:09:56 -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; 14 Feb 2012 05:09:56 -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 q1E59p39026167
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1E59oRl025034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59oud004739; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0DCA44031C; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:46 -0500
Message-Id: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F39ECA2.000A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [RFC] acpi processor and cpufreq harester - aka pipe
	all of that up to the hypervisor (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Changelog [v3:]
 - new name and decided to put it in drivers/xen since it uses APIs from both cpufreq and acpi.
 - updated to expose MWAIT capability
 - cleaned up the code a bit.
[since v2 - not posted]:
 - change the name to processor_passthrough_xen and move it to drivers/acpi
 - make it launch a thread, support CPU hotplug
[since v1: http://comments.gmane.org/gmane.linux.acpi.devel/51862]
 - initial posting.

The problem these three patches try to solve is to provide ACPI power management
information to the hypervisor. The hypervisor lacks the ACPI DSDT parser so it can't
get that data without some help - and the initial domain can provide that. One
approach (https://lkml.org/lkml/2011/11/30/245) augments the ACPI code to call
an external PM code - but there were no comments about it so I decided to see
if another approach could solve it.

This "harvester" (I am horrible with names, if you have any suggestions please
tell me them) collects the information that the cpufreq drivers and the
ACPI processor code save in the 'struct acpi_processor' and then sends it to
the hypervisor.

The driver can be either an module or compiled in. In either mode the driver
launches a thread that checks whether an cpufreq driver is registered. If so
it reads all the 'struct acpi_processor' data for all online CPUs and sends
it to hypervisor. The driver also register a CPU hotplug component - so if a new
CPU shows up - it would send the data to the hypervisor for it as well.

I've tested this with success on a variety of Intel and AMD hardware (need
a patch to the hypervisor to allow the rdmsr to be passed through). The one
caveat is that dom0_max_vcpus inhibits the driver from reading the vCPUs
that are not present in dom0. One solution is to boot without dom0_max_vcpus
and utilize the 'xl vcpu-set' command to offline the vCPUs. Other one that
Nakajima Jun suggested was to hotplug vCPUS in - so bootup dom0 and hotplug
the vCPUs in - but I am running in difficulties on how to do this in the hypervisor.

Konrad Rzeszutek Wilk (3):
      xen/setup/pm/acpi: Remove the call to boot_option_idle_override.
      xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
      xen/acpi/cpufreq: Provide an driver that passes struct acpi_processor data to the hypervisor.

 arch/x86/xen/enlighten.c         |   92 +++++++++-
 arch/x86/xen/setup.c             |    1 -
 drivers/xen/Kconfig              |   14 ++
 drivers/xen/Makefile             |    2 +-
 drivers/xen/processor-harvest.c  |  397 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h |    4 +-
 6 files changed, 506 insertions(+), 4 deletions(-)


Oh, and the hypervisor patch to make this work under AMD:
# HG changeset patch
# Parent 9ad1e42c341bc78463b6f6610a6300f75b535fbb
traps: AMD PM MSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

TODO: Have not tested on K7 machines.
TODO: Have not tested this with XenOLinux 2.6.32 dom0 on AMD machines.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 9ad1e42c341b xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/traps.c	Mon Feb 13 23:11:59 2012 -0500
@@ -2457,7 +2457,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_HWCR:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
                 break;
             if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
                 goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 05:10:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 05:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxAeN-00036Y-BW; Tue, 14 Feb 2012 05:09:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RxAeL-00036R-RV
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 05:09:58 +0000
Received: from [85.158.139.83:44396] by server-9.bemta-5.messagelabs.com id
	60/42-30171-5ACE93F4; Tue, 14 Feb 2012 05:09:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329196195!14930951!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUzOTYyMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 926 invoked from network); 14 Feb 2012 05:09:56 -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; 14 Feb 2012 05:09:56 -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 q1E59p39026167
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 05:09:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1E59oRl025034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 05:09:51 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
	q1E59oud004739; Mon, 13 Feb 2012 23:09:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 13 Feb 2012 21:09:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0DCA44031C; Tue, 14 Feb 2012 00:06:51 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Tue, 14 Feb 2012 00:06:46 -0500
Message-Id: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F39ECA2.000A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [RFC] acpi processor and cpufreq harester - aka pipe
	all of that up to the hypervisor (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Changelog [v3:]
 - new name and decided to put it in drivers/xen since it uses APIs from both cpufreq and acpi.
 - updated to expose MWAIT capability
 - cleaned up the code a bit.
[since v2 - not posted]:
 - change the name to processor_passthrough_xen and move it to drivers/acpi
 - make it launch a thread, support CPU hotplug
[since v1: http://comments.gmane.org/gmane.linux.acpi.devel/51862]
 - initial posting.

The problem these three patches try to solve is to provide ACPI power management
information to the hypervisor. The hypervisor lacks the ACPI DSDT parser so it can't
get that data without some help - and the initial domain can provide that. One
approach (https://lkml.org/lkml/2011/11/30/245) augments the ACPI code to call
an external PM code - but there were no comments about it so I decided to see
if another approach could solve it.

This "harvester" (I am horrible with names, if you have any suggestions please
tell me them) collects the information that the cpufreq drivers and the
ACPI processor code save in the 'struct acpi_processor' and then sends it to
the hypervisor.

The driver can be either an module or compiled in. In either mode the driver
launches a thread that checks whether an cpufreq driver is registered. If so
it reads all the 'struct acpi_processor' data for all online CPUs and sends
it to hypervisor. The driver also register a CPU hotplug component - so if a new
CPU shows up - it would send the data to the hypervisor for it as well.

I've tested this with success on a variety of Intel and AMD hardware (need
a patch to the hypervisor to allow the rdmsr to be passed through). The one
caveat is that dom0_max_vcpus inhibits the driver from reading the vCPUs
that are not present in dom0. One solution is to boot without dom0_max_vcpus
and utilize the 'xl vcpu-set' command to offline the vCPUs. Other one that
Nakajima Jun suggested was to hotplug vCPUS in - so bootup dom0 and hotplug
the vCPUs in - but I am running in difficulties on how to do this in the hypervisor.

Konrad Rzeszutek Wilk (3):
      xen/setup/pm/acpi: Remove the call to boot_option_idle_override.
      xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
      xen/acpi/cpufreq: Provide an driver that passes struct acpi_processor data to the hypervisor.

 arch/x86/xen/enlighten.c         |   92 +++++++++-
 arch/x86/xen/setup.c             |    1 -
 drivers/xen/Kconfig              |   14 ++
 drivers/xen/Makefile             |    2 +-
 drivers/xen/processor-harvest.c  |  397 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h |    4 +-
 6 files changed, 506 insertions(+), 4 deletions(-)


Oh, and the hypervisor patch to make this work under AMD:
# HG changeset patch
# Parent 9ad1e42c341bc78463b6f6610a6300f75b535fbb
traps: AMD PM MSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

TODO: Have not tested on K7 machines.
TODO: Have not tested this with XenOLinux 2.6.32 dom0 on AMD machines.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 9ad1e42c341b xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Fri Feb 10 17:24:50 2012 +0000
+++ b/xen/arch/x86/traps.c	Mon Feb 13 23:11:59 2012 -0500
@@ -2457,7 +2457,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_HWCR:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
                 break;
             if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
                 goto fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 07:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxCQJ-00068U-Py; Tue, 14 Feb 2012 07:03:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxCQH-00067p-Qs
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 07:03:34 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329203006!9674224!1
X-Originating-IP: [209.85.212.65]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16288 invoked from network); 14 Feb 2012 07:03:27 -0000
Received: from mail-vw0-f65.google.com (HELO mail-vw0-f65.google.com)
	(209.85.212.65)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 07:03:27 -0000
Received: by vbbez10 with SMTP id ez10so408253vbb.0
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 23:03:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=fCBX7vIJK+zdp6r2rfQkDU45pVKFmCUGsNdxWD0nwFY=;
	b=YrY0Hp1jWAjqMWfK1IR/6QPaix6LT3Yvq2AiMN6P6B0zZdakdlMYF0QFRvdCUcIfV9
	b9q2lbCqwatk7IOgcTJhr9n03iLtJLp8rpZ9YE2BKw7gFmKWlZlNzS4cDPINABswgUA0
	Mu6HACI8Y//TJLSGBz+efkjdVmp5jol8uM1cg=
MIME-Version: 1.0
Received: by 10.52.178.40 with SMTP id cv8mr8169323vdc.82.1329203006356; Mon,
	13 Feb 2012 23:03:26 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Mon, 13 Feb 2012 23:03:26 -0800 (PST)
Date: Tue, 14 Feb 2012 15:03:26 +0800
Message-ID: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1886411441754229119=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1886411441754229119==
Content-Type: multipart/alternative; boundary=20cf3071caf8073c0804b8e7316b

--20cf3071caf8073c0804b8e7316b
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
When I'm reading code of Xen and I can't find the exact LOG file written by
each log-writing code, so I have some trouble with debugging.

I have found 8 type of LOG managed by xen-4.0 or later,
#define LOG_EMERG 0
#define LOG_ALERT 1
#define LOG_CRIT 2
#define LOG_ERR 3
#define LOG_WARNING 4
#define LOG_NOTICE 5
#define LOG_INFO 6
#define LOG_DEBUG

and there are three frequently used macro for logging:
#define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)
#define EPRINTF(_f, _a...) syslog(LOG_ERR, "tap-err:%s: " _f, __func__,
##_a)
#define  PERROR(_f, _a...) syslog(LOG_ERR, "tap-err:%s: " _f ": %s",
__func__, ##_a, \
  strerror(errno)

Who can tell me which file match these log type above? Thank you.

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3071caf8073c0804b8e7316b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>When I&#39;m reading code of Xen and I can&#39;t find the exact=
 LOG file written by each log-writing code, so I have some trouble with deb=
ugging.</div><div><br></div><div>I have found 8 type of LOG managed by xen-=
4.0 or later,=A0</div>
<div><div>#define LOG_EMERG 0</div><div>#define LOG_ALERT 1</div><div>#defi=
ne LOG_CRIT 2</div><div>#define LOG_ERR 3</div><div>#define LOG_WARNING 4</=
div><div>#define LOG_NOTICE 5</div><div>#define LOG_INFO 6</div><div>#defin=
e LOG_DEBUG=A0</div>
<div><br></div><div>and there are three frequently used macro for logging:<=
/div><div><div>#define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)</div><=
div>#define EPRINTF(_f, _a...) syslog(LOG_ERR, &quot;tap-err:%s: &quot; _f,=
 __func__, ##_a)</div>
<div>#define =A0PERROR(_f, _a...) syslog(LOG_ERR, &quot;tap-err:%s: &quot; =
_f &quot;: %s&quot;, __func__, ##_a, \</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre">				</span> =A0strerror(errno)</div></div><d=
iv><br>
</div><div>Who can tell me which file match these log type above? Thank you=
.</div><div><br></div>-- <br>Chunqi Li<br>Department of Computer Science<br=
>School of EECS<br>Peking University<br>Beijing, China<br>
</div>

--20cf3071caf8073c0804b8e7316b--


--===============1886411441754229119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1886411441754229119==--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 07:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxCQJ-00068U-Py; Tue, 14 Feb 2012 07:03:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxCQH-00067p-Qs
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 07:03:34 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329203006!9674224!1
X-Originating-IP: [209.85.212.65]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16288 invoked from network); 14 Feb 2012 07:03:27 -0000
Received: from mail-vw0-f65.google.com (HELO mail-vw0-f65.google.com)
	(209.85.212.65)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 07:03:27 -0000
Received: by vbbez10 with SMTP id ez10so408253vbb.0
	for <xen-devel@lists.xensource.com>;
	Mon, 13 Feb 2012 23:03:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=fCBX7vIJK+zdp6r2rfQkDU45pVKFmCUGsNdxWD0nwFY=;
	b=YrY0Hp1jWAjqMWfK1IR/6QPaix6LT3Yvq2AiMN6P6B0zZdakdlMYF0QFRvdCUcIfV9
	b9q2lbCqwatk7IOgcTJhr9n03iLtJLp8rpZ9YE2BKw7gFmKWlZlNzS4cDPINABswgUA0
	Mu6HACI8Y//TJLSGBz+efkjdVmp5jol8uM1cg=
MIME-Version: 1.0
Received: by 10.52.178.40 with SMTP id cv8mr8169323vdc.82.1329203006356; Mon,
	13 Feb 2012 23:03:26 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Mon, 13 Feb 2012 23:03:26 -0800 (PST)
Date: Tue, 14 Feb 2012 15:03:26 +0800
Message-ID: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1886411441754229119=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1886411441754229119==
Content-Type: multipart/alternative; boundary=20cf3071caf8073c0804b8e7316b

--20cf3071caf8073c0804b8e7316b
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
When I'm reading code of Xen and I can't find the exact LOG file written by
each log-writing code, so I have some trouble with debugging.

I have found 8 type of LOG managed by xen-4.0 or later,
#define LOG_EMERG 0
#define LOG_ALERT 1
#define LOG_CRIT 2
#define LOG_ERR 3
#define LOG_WARNING 4
#define LOG_NOTICE 5
#define LOG_INFO 6
#define LOG_DEBUG

and there are three frequently used macro for logging:
#define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)
#define EPRINTF(_f, _a...) syslog(LOG_ERR, "tap-err:%s: " _f, __func__,
##_a)
#define  PERROR(_f, _a...) syslog(LOG_ERR, "tap-err:%s: " _f ": %s",
__func__, ##_a, \
  strerror(errno)

Who can tell me which file match these log type above? Thank you.

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3071caf8073c0804b8e7316b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>When I&#39;m reading code of Xen and I can&#39;t find the exact=
 LOG file written by each log-writing code, so I have some trouble with deb=
ugging.</div><div><br></div><div>I have found 8 type of LOG managed by xen-=
4.0 or later,=A0</div>
<div><div>#define LOG_EMERG 0</div><div>#define LOG_ALERT 1</div><div>#defi=
ne LOG_CRIT 2</div><div>#define LOG_ERR 3</div><div>#define LOG_WARNING 4</=
div><div>#define LOG_NOTICE 5</div><div>#define LOG_INFO 6</div><div>#defin=
e LOG_DEBUG=A0</div>
<div><br></div><div>and there are three frequently used macro for logging:<=
/div><div><div>#define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)</div><=
div>#define EPRINTF(_f, _a...) syslog(LOG_ERR, &quot;tap-err:%s: &quot; _f,=
 __func__, ##_a)</div>
<div>#define =A0PERROR(_f, _a...) syslog(LOG_ERR, &quot;tap-err:%s: &quot; =
_f &quot;: %s&quot;, __func__, ##_a, \</div><div><span class=3D"Apple-tab-s=
pan" style=3D"white-space:pre">				</span> =A0strerror(errno)</div></div><d=
iv><br>
</div><div>Who can tell me which file match these log type above? Thank you=
.</div><div><br></div>-- <br>Chunqi Li<br>Department of Computer Science<br=
>School of EECS<br>Peking University<br>Beijing, China<br>
</div>

--20cf3071caf8073c0804b8e7316b--


--===============1886411441754229119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1886411441754229119==--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 08:56:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 08: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.xensource.com>)
	id 1RxEBK-00010l-FI; Tue, 14 Feb 2012 08:56:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxEBJ-0000zS-RY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 08:56:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329209767!14220998!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12169 invoked from network); 14 Feb 2012 08:56:07 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 08:56:07 -0000
Received: by werb14 with SMTP id b14so16746608wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 00:56:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=iEjwvJTlNs5xU7dUU6ivC2puj+e+3flsICnCtjgFG/w=;
	b=FI7VmvldOw6P7SCt7Ne892IwQgcCPJbdpacsekyscKeYTKPafG6e1Z8Hfms0Hz9/gs
	sLwIlohlrEnCdHJjg9W2/lh+S3p1QY04UNDb7VfSpwwDeQZ7UQYepcLl6eBNbKWytjX5
	iXShxF8Qud9p7eaftbo9wjNHlCnOU7LmD1FqE=
MIME-Version: 1.0
Received: by 10.216.134.3 with SMTP id r3mr670942wei.40.1329209766835; Tue, 14
	Feb 2012 00:56:06 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 00:56:06 -0800 (PST)
In-Reply-To: <20281.20160.628074.801720@mariner.uk.xensource.com>
References: <837570e539a114f47d8a.1326258829@build.localdomain>
	<20281.20160.628074.801720@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 09:56:06 +0100
X-Google-Sender-Auth: -c3z-xeoWoBho8depeo5fKM9MD0
Message-ID: <CAPLaKK7tTbqKfozAFci3TXsUiSGi7ScqgETB6xGBj1aZ7240jg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzEzIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENIIHY0IFJFU0VORF0gYnVpbGQ6
IGFkZCBhdXRvY29uZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2siKToK
Pj4gQWRkZWQgYXV0b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrIHNjcmlwdHMu
IFRoZSBwcmV2aW91cwo+PiBjaGVja3MgaGF2ZSBiZWVuIHBvcnRlZCB0byBhdXRvY29uZiwgYW5k
IHNvbWUgYWRkaXRpb25hbCBvbmVzIGhhdmUKPj4gYmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2Vz
dGlvbnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4gVHdvIGZpbGVzIGFyZQo+PiBjcmVhdGVkIGFz
IGEgcmVzdWx0IGZyb20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQsIGNvbmZpZy9Ub29scy5t
awo+PiBhbmQgY29uZmlnLmguCj4KPiBUaGFua3MgZm9yIHRoaXMgd29yay4gwqBJJ20ganVzdCBy
ZXBseWluZyB0byBnaXZlIGEgc3RhdHVzIHVwZGF0ZTogSQo+IGhhdmVuJ3QgZm9yZ290dGVuIHRo
aXMuCgpObyBwcm9ibGVtLCBJJ3ZlIGJlZW4gYnVzeSB3aXRoIG90aGVyIHN0dWZmIHRvby4gSnVz
dCBhcyBhIHNpZGUgbm90ZSwKSSBoYXZlbid0IGZvcmdvdHRlbiBhYm91dCB0aGUgZHJpdmVyIGRv
bWFpbiBzZXJpZXMgdG9vLCBhbmQgSSB3aWxsIHRyeQp0byBhbnN3ZXIgdGhlIHF1ZXN0aW9ucy9z
dWdnZXN0aW9ucyBhcyBzb29uIGFzIEkgY2FuLgoKPiBJdCBkZXBlbmRzIG9uIGEgbmV3IGZlYXR1
cmUgaW4gdGhlIGF1dG90ZXN0IG1hY2hpbmVyeSAtIHdoaWNoIHdvdWxkCj4gaW52b2x2ZSBpdCBh
dXRvbWF0aWNhbGx5IHJ1bm5pbmcgIi4vY29uZmlndXJlIiBhcyB3ZWxsIGFzIGp1c3QgIm1ha2Ui
Lgo+IEkgaGF2ZSBhIG51bWJlciBvZiBvdGhlciB0ZXN0IHN5c3RlbSBjaGFuZ2VzIHdoaWNoIGFy
ZSBxdWV1ZWQgdXAKPiBiZWZvcmVoYW5kLCBidXQgdGhpcyBpcyBvbiBteSBsaXN0Lgo+Cj4gTGFz
dCB0aW1lIHlvdSBwb3N0ZWQgdGhpcyB0aGVyZSB3YXMgYW4gb2JqZWN0aW9uIHRoYXQgYXV0b2Nv
bmYgMi42Nwo+IGlzbid0IG5lY2Vzc2FyaWx5IHRoYXQgd2lkZWx5IGF2YWlsYWJsZS4gwqBEaWQg
eW91IGRlbGliZXJhdGVseSB1c2UgYW55Cj4gMi42NyBmZWF0dXJlcyBvciBjYW4gd2UgaGF2ZSBh
IGxlc3MgYWdncmVzc2l2ZSBQUkVSRVEgPwoKSSBkb24ndCB0aGluayBpdCBuZWVkcyBhdXRvY29u
ZiAyLjY3IChvciBhdCBsZWFzdCBJJ20gbm90IGF3YXJlIG9mCnVzaW5nIGFueSBzcGVjaWZpYyBt
YWNyb3MgdGhhdCByZXF1aXJlID4gMi42NyksIGJ1dCBzaW5jZSBhdXRvY29uZgpzaG91bGQgb25s
eSBiZSB1c2VkIGJ5IHRoZSBkZXZlbG9wZXJzLCBpZiBzb21lb25lIGhhcyB0byBnZW5lcmF0ZSBh
Cm5ldyBjb25maWd1cmUgd2l0aCBhIHByZXZpb3VzIHZlcnNpb24gd2UgY291bGQgYWx3YXlzIHRy
eSB0byBkb3duZ3JhZGUKdGhlIHByZXJlcSBhbmQgc2VlIGlmIGl0IHdvcmtzLgoKPiBBbHNvLCBv
ZiBjb3Vyc2UsIHRoaXMgcGF0Y2ggaGFzIHJvdHRlZCBzbGlnaHRseSBhbmQgbm8gbG9uZ2VyIGFw
cGxpZXMKPiB0byB4ZW4tdW5zdGFibGUgdGlwLiDCoFdoZW4gdGhlIHRlc3Qgc3lzdGVtIGlzIHJl
YWR5IEknbGwgZW1haWwgYWdhaW4KPiBhbmQgYXNrIHlvdSB0byByZWJhc2UuCgpJJ20gYXdhcmUs
IHNpbmNlIHRoZSB5YWpsIDIgc2VyaWVzIHdlbnQgaW4sIHRoaXMgcGF0Y2ggbmVlZHMgc29tZQph
ZGp1c3RtZW50cy4gSnVzdCBkcm9wIGEgbGluZSB3aGVuIHlvdSBhcmUgcmVhZHkgYW5kIEkgd2ls
bCB1cGRhdGUgaXQKdG8gbWF0Y2ggdGlwLgoKVGhhbmtzLCBSb2dlci4KCj4gRG9lcyBhbnlvbmUg
ZWxzZSBoYXZlIGFueSBjb21tZW50cyA/Cj4KPiBUaGFua3MsCj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Feb 14 08:56:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 08: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.xensource.com>)
	id 1RxEBK-00010l-FI; Tue, 14 Feb 2012 08:56:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxEBJ-0000zS-RY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 08:56:14 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329209767!14220998!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12169 invoked from network); 14 Feb 2012 08:56:07 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 08:56:07 -0000
Received: by werb14 with SMTP id b14so16746608wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 00:56:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=iEjwvJTlNs5xU7dUU6ivC2puj+e+3flsICnCtjgFG/w=;
	b=FI7VmvldOw6P7SCt7Ne892IwQgcCPJbdpacsekyscKeYTKPafG6e1Z8Hfms0Hz9/gs
	sLwIlohlrEnCdHJjg9W2/lh+S3p1QY04UNDb7VfSpwwDeQZ7UQYepcLl6eBNbKWytjX5
	iXShxF8Qud9p7eaftbo9wjNHlCnOU7LmD1FqE=
MIME-Version: 1.0
Received: by 10.216.134.3 with SMTP id r3mr670942wei.40.1329209766835; Tue, 14
	Feb 2012 00:56:06 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 00:56:06 -0800 (PST)
In-Reply-To: <20281.20160.628074.801720@mariner.uk.xensource.com>
References: <837570e539a114f47d8a.1326258829@build.localdomain>
	<20281.20160.628074.801720@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 09:56:06 +0100
X-Google-Sender-Auth: -c3z-xeoWoBho8depeo5fKM9MD0
Message-ID: <CAPLaKK7tTbqKfozAFci3TXsUiSGi7ScqgETB6xGBj1aZ7240jg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzEzIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENIIHY0IFJFU0VORF0gYnVpbGQ6
IGFkZCBhdXRvY29uZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2siKToK
Pj4gQWRkZWQgYXV0b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrIHNjcmlwdHMu
IFRoZSBwcmV2aW91cwo+PiBjaGVja3MgaGF2ZSBiZWVuIHBvcnRlZCB0byBhdXRvY29uZiwgYW5k
IHNvbWUgYWRkaXRpb25hbCBvbmVzIGhhdmUKPj4gYmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2Vz
dGlvbnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4gVHdvIGZpbGVzIGFyZQo+PiBjcmVhdGVkIGFz
IGEgcmVzdWx0IGZyb20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQsIGNvbmZpZy9Ub29scy5t
awo+PiBhbmQgY29uZmlnLmguCj4KPiBUaGFua3MgZm9yIHRoaXMgd29yay4gwqBJJ20ganVzdCBy
ZXBseWluZyB0byBnaXZlIGEgc3RhdHVzIHVwZGF0ZTogSQo+IGhhdmVuJ3QgZm9yZ290dGVuIHRo
aXMuCgpObyBwcm9ibGVtLCBJJ3ZlIGJlZW4gYnVzeSB3aXRoIG90aGVyIHN0dWZmIHRvby4gSnVz
dCBhcyBhIHNpZGUgbm90ZSwKSSBoYXZlbid0IGZvcmdvdHRlbiBhYm91dCB0aGUgZHJpdmVyIGRv
bWFpbiBzZXJpZXMgdG9vLCBhbmQgSSB3aWxsIHRyeQp0byBhbnN3ZXIgdGhlIHF1ZXN0aW9ucy9z
dWdnZXN0aW9ucyBhcyBzb29uIGFzIEkgY2FuLgoKPiBJdCBkZXBlbmRzIG9uIGEgbmV3IGZlYXR1
cmUgaW4gdGhlIGF1dG90ZXN0IG1hY2hpbmVyeSAtIHdoaWNoIHdvdWxkCj4gaW52b2x2ZSBpdCBh
dXRvbWF0aWNhbGx5IHJ1bm5pbmcgIi4vY29uZmlndXJlIiBhcyB3ZWxsIGFzIGp1c3QgIm1ha2Ui
Lgo+IEkgaGF2ZSBhIG51bWJlciBvZiBvdGhlciB0ZXN0IHN5c3RlbSBjaGFuZ2VzIHdoaWNoIGFy
ZSBxdWV1ZWQgdXAKPiBiZWZvcmVoYW5kLCBidXQgdGhpcyBpcyBvbiBteSBsaXN0Lgo+Cj4gTGFz
dCB0aW1lIHlvdSBwb3N0ZWQgdGhpcyB0aGVyZSB3YXMgYW4gb2JqZWN0aW9uIHRoYXQgYXV0b2Nv
bmYgMi42Nwo+IGlzbid0IG5lY2Vzc2FyaWx5IHRoYXQgd2lkZWx5IGF2YWlsYWJsZS4gwqBEaWQg
eW91IGRlbGliZXJhdGVseSB1c2UgYW55Cj4gMi42NyBmZWF0dXJlcyBvciBjYW4gd2UgaGF2ZSBh
IGxlc3MgYWdncmVzc2l2ZSBQUkVSRVEgPwoKSSBkb24ndCB0aGluayBpdCBuZWVkcyBhdXRvY29u
ZiAyLjY3IChvciBhdCBsZWFzdCBJJ20gbm90IGF3YXJlIG9mCnVzaW5nIGFueSBzcGVjaWZpYyBt
YWNyb3MgdGhhdCByZXF1aXJlID4gMi42NyksIGJ1dCBzaW5jZSBhdXRvY29uZgpzaG91bGQgb25s
eSBiZSB1c2VkIGJ5IHRoZSBkZXZlbG9wZXJzLCBpZiBzb21lb25lIGhhcyB0byBnZW5lcmF0ZSBh
Cm5ldyBjb25maWd1cmUgd2l0aCBhIHByZXZpb3VzIHZlcnNpb24gd2UgY291bGQgYWx3YXlzIHRy
eSB0byBkb3duZ3JhZGUKdGhlIHByZXJlcSBhbmQgc2VlIGlmIGl0IHdvcmtzLgoKPiBBbHNvLCBv
ZiBjb3Vyc2UsIHRoaXMgcGF0Y2ggaGFzIHJvdHRlZCBzbGlnaHRseSBhbmQgbm8gbG9uZ2VyIGFw
cGxpZXMKPiB0byB4ZW4tdW5zdGFibGUgdGlwLiDCoFdoZW4gdGhlIHRlc3Qgc3lzdGVtIGlzIHJl
YWR5IEknbGwgZW1haWwgYWdhaW4KPiBhbmQgYXNrIHlvdSB0byByZWJhc2UuCgpJJ20gYXdhcmUs
IHNpbmNlIHRoZSB5YWpsIDIgc2VyaWVzIHdlbnQgaW4sIHRoaXMgcGF0Y2ggbmVlZHMgc29tZQph
ZGp1c3RtZW50cy4gSnVzdCBkcm9wIGEgbGluZSB3aGVuIHlvdSBhcmUgcmVhZHkgYW5kIEkgd2ls
bCB1cGRhdGUgaXQKdG8gbWF0Y2ggdGlwLgoKVGhhbmtzLCBSb2dlci4KCj4gRG9lcyBhbnlvbmUg
ZWxzZSBoYXZlIGFueSBjb21tZW50cyA/Cj4KPiBUaGFua3MsCj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:19:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09: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.xensource.com>)
	id 1RxEXe-0001wF-9i; Tue, 14 Feb 2012 09:19:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEXb-0001wA-TC
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:19:16 +0000
Received: from [85.158.139.83:2101] by server-4.bemta-5.messagelabs.com id
	3C/AA-10788-3172A3F4; Tue, 14 Feb 2012 09:19:15 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329211153!14907452!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16146 invoked from network); 14 Feb 2012 09:19:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 09:19:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEXY-0003lZ-T0
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:19:12 -0800
Date: Tue, 14 Feb 2012 01:19:12 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329211152890-5481930.post@n5.nabble.com>
In-Reply-To: <4F392F45.3000903@canonical.com>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
	<4F392F45.3000903@canonical.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
	with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There are already some on attachment of first post...

...
(initramfs) cat /proc/partitions 
major minor  #blocks  name

 202        1   10240000 xvda1
 202        2    1024000 xvda2
 (initramfs) blkid 
/dev/xvda2: UUID="3a4d1b29-15b2-47b1-b97f-8c258a8b10d8" TYPE="swap"

And about /dev/disk-by-uuid/:
(initramfs) ls -al /dev/disk/by-uuid/
lrwxrwxrwx    1        11 3a4d1b29-15b2-47b1-b97f-8c258a8b10d8 ->
../../xvda2
drwxr-xr-x    4        80 ..
drwxr-xr-x    2        60 .

If can help also udev info:
(initramfs) udevadm info --query=all --path /block/xvda1
P: /devices/vbd-51713/block/xvda1
N: xvda1
S: disk/by-path/xen-vbd-51713
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51713
E: DEVNAME=/dev/xvda1
E: DEVPATH=/devices/vbd-51713/block/xvda1
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=xen-vbd-51713
E: ID_PATH_TAG=xen-vbd-51713
E: MAJOR=202
E: MINOR=1
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=282841
(initramfs) udevadm info --query=all --path /block/xvda2
P: /devices/vbd-51714/block/xvda2
N: xvda2
S: disk/by-path/xen-vbd-51714
S: disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51714
/dev/disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVNAME=/dev/xvda2
E: DEVPATH=/devices/vbd-51714/block/xvda2
E: DEVTYPE=disk
E: ID_FS_TYPE=swap
E: ID_FS_USAGE=other
E: ID_FS_UUID=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_UUID_ENC=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_VERSION=2
E: ID_PATH=xen-vbd-51714
E: ID_PATH_TAG=xen-vbd-51714
E: MAJOR=202
E: MINOR=2
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=283285

Only xvda2 (swap) seem to be full and correct, xvda1 not.
On production system the same domU work, differences in which there is very
likely the cause of the problem are then:
Xen 4.0 with xm on production system and xen-unstable with xl on test system
But I have no certainty that it is a problem of xen and/or xl.

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5481930.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:19:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09: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.xensource.com>)
	id 1RxEXe-0001wF-9i; Tue, 14 Feb 2012 09:19:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEXb-0001wA-TC
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:19:16 +0000
Received: from [85.158.139.83:2101] by server-4.bemta-5.messagelabs.com id
	3C/AA-10788-3172A3F4; Tue, 14 Feb 2012 09:19:15 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329211153!14907452!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16146 invoked from network); 14 Feb 2012 09:19:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 09:19:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEXY-0003lZ-T0
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:19:12 -0800
Date: Tue, 14 Feb 2012 01:19:12 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329211152890-5481930.post@n5.nabble.com>
In-Reply-To: <4F392F45.3000903@canonical.com>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
	<4F392F45.3000903@canonical.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
	with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There are already some on attachment of first post...

...
(initramfs) cat /proc/partitions 
major minor  #blocks  name

 202        1   10240000 xvda1
 202        2    1024000 xvda2
 (initramfs) blkid 
/dev/xvda2: UUID="3a4d1b29-15b2-47b1-b97f-8c258a8b10d8" TYPE="swap"

And about /dev/disk-by-uuid/:
(initramfs) ls -al /dev/disk/by-uuid/
lrwxrwxrwx    1        11 3a4d1b29-15b2-47b1-b97f-8c258a8b10d8 ->
../../xvda2
drwxr-xr-x    4        80 ..
drwxr-xr-x    2        60 .

If can help also udev info:
(initramfs) udevadm info --query=all --path /block/xvda1
P: /devices/vbd-51713/block/xvda1
N: xvda1
S: disk/by-path/xen-vbd-51713
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51713
E: DEVNAME=/dev/xvda1
E: DEVPATH=/devices/vbd-51713/block/xvda1
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=xen-vbd-51713
E: ID_PATH_TAG=xen-vbd-51713
E: MAJOR=202
E: MINOR=1
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=282841
(initramfs) udevadm info --query=all --path /block/xvda2
P: /devices/vbd-51714/block/xvda2
N: xvda2
S: disk/by-path/xen-vbd-51714
S: disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51714
/dev/disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVNAME=/dev/xvda2
E: DEVPATH=/devices/vbd-51714/block/xvda2
E: DEVTYPE=disk
E: ID_FS_TYPE=swap
E: ID_FS_USAGE=other
E: ID_FS_UUID=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_UUID_ENC=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_VERSION=2
E: ID_PATH=xen-vbd-51714
E: ID_PATH_TAG=xen-vbd-51714
E: MAJOR=202
E: MINOR=2
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=283285

Only xvda2 (swap) seem to be full and correct, xvda1 not.
On production system the same domU work, differences in which there is very
likely the cause of the problem are then:
Xen 4.0 with xm on production system and xen-unstable with xl on test system
But I have no certainty that it is a problem of xen and/or xl.

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5481930.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:21:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09: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.xensource.com>)
	id 1RxEZV-00024F-Qm; Tue, 14 Feb 2012 09:21:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEZV-00023z-1l
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:21:13 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329211265!15240770!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26283 invoked from network); 14 Feb 2012 09:21:06 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 09:21:06 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEZN-00044e-A7
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:21:05 -0800
Date: Tue, 14 Feb 2012 01:21:05 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329211265301-5481934.post@n5.nabble.com>
In-Reply-To: <4F392F45.3000903@canonical.com>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
	<4F392F45.3000903@canonical.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
	with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There are already some on attachment of first post...

...
(initramfs) cat /proc/partitions 
major minor  #blocks  name

 202        1   10240000 xvda1
 202        2    1024000 xvda2
 (initramfs) blkid 
/dev/xvda2: UUID="3a4d1b29-15b2-47b1-b97f-8c258a8b10d8" TYPE="swap"

And about /dev/disk-by-uuid/:
(initramfs) ls -al /dev/disk/by-uuid/
lrwxrwxrwx    1        11 3a4d1b29-15b2-47b1-b97f-8c258a8b10d8 ->
../../xvda2
drwxr-xr-x    4        80 ..
drwxr-xr-x    2        60 .

If can help also udev info:
(initramfs) udevadm info --query=all --path /block/xvda1
P: /devices/vbd-51713/block/xvda1
N: xvda1
S: disk/by-path/xen-vbd-51713
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51713
E: DEVNAME=/dev/xvda1
E: DEVPATH=/devices/vbd-51713/block/xvda1
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=xen-vbd-51713
E: ID_PATH_TAG=xen-vbd-51713
E: MAJOR=202
E: MINOR=1
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=282841
(initramfs) udevadm info --query=all --path /block/xvda2
P: /devices/vbd-51714/block/xvda2
N: xvda2
S: disk/by-path/xen-vbd-51714
S: disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51714
/dev/disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVNAME=/dev/xvda2
E: DEVPATH=/devices/vbd-51714/block/xvda2
E: DEVTYPE=disk
E: ID_FS_TYPE=swap
E: ID_FS_USAGE=other
E: ID_FS_UUID=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_UUID_ENC=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_VERSION=2
E: ID_PATH=xen-vbd-51714
E: ID_PATH_TAG=xen-vbd-51714
E: MAJOR=202
E: MINOR=2
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=283285

Only xvda2 (swap) seem to be full and correct, xvda1 not.
On production system the same domU work, differences in which there is very
likely the cause of the problem are then:
Xen 4.0 with xm on production system and xen-unstable with xl on test system
But I have no certainty that it is a problem of xen and/or xl.

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5481934.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:21:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09: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.xensource.com>)
	id 1RxEZV-00024F-Qm; Tue, 14 Feb 2012 09:21:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEZV-00023z-1l
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:21:13 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329211265!15240770!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26283 invoked from network); 14 Feb 2012 09:21:06 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 09:21:06 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEZN-00044e-A7
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:21:05 -0800
Date: Tue, 14 Feb 2012 01:21:05 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329211265301-5481934.post@n5.nabble.com>
In-Reply-To: <4F392F45.3000903@canonical.com>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
	<4F392F45.3000903@canonical.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
	with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There are already some on attachment of first post...

...
(initramfs) cat /proc/partitions 
major minor  #blocks  name

 202        1   10240000 xvda1
 202        2    1024000 xvda2
 (initramfs) blkid 
/dev/xvda2: UUID="3a4d1b29-15b2-47b1-b97f-8c258a8b10d8" TYPE="swap"

And about /dev/disk-by-uuid/:
(initramfs) ls -al /dev/disk/by-uuid/
lrwxrwxrwx    1        11 3a4d1b29-15b2-47b1-b97f-8c258a8b10d8 ->
../../xvda2
drwxr-xr-x    4        80 ..
drwxr-xr-x    2        60 .

If can help also udev info:
(initramfs) udevadm info --query=all --path /block/xvda1
P: /devices/vbd-51713/block/xvda1
N: xvda1
S: disk/by-path/xen-vbd-51713
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51713
E: DEVNAME=/dev/xvda1
E: DEVPATH=/devices/vbd-51713/block/xvda1
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=xen-vbd-51713
E: ID_PATH_TAG=xen-vbd-51713
E: MAJOR=202
E: MINOR=1
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=282841
(initramfs) udevadm info --query=all --path /block/xvda2
P: /devices/vbd-51714/block/xvda2
N: xvda2
S: disk/by-path/xen-vbd-51714
S: disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51714
/dev/disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: DEVNAME=/dev/xvda2
E: DEVPATH=/devices/vbd-51714/block/xvda2
E: DEVTYPE=disk
E: ID_FS_TYPE=swap
E: ID_FS_USAGE=other
E: ID_FS_UUID=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_UUID_ENC=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
E: ID_FS_VERSION=2
E: ID_PATH=xen-vbd-51714
E: ID_PATH_TAG=xen-vbd-51714
E: MAJOR=202
E: MINOR=2
E: SUBSYSTEM=block
E: UDEV_LOG=3
E: USEC_INITIALIZED=283285

Only xvda2 (swap) seem to be full and correct, xvda1 not.
On production system the same domU work, differences in which there is very
likely the cause of the problem are then:
Xen 4.0 with xm on production system and xen-unstable with xl on test system
But I have no certainty that it is a problem of xen and/or xl.

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5481934.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:25:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxEdV-0002K0-ML; Tue, 14 Feb 2012 09:25:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxEdU-0002Jt-Io
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:25:20 +0000
Received: from [193.109.254.147:21527] by server-1.bemta-14.messagelabs.com id
	1C/02-12485-F782A3F4; Tue, 14 Feb 2012 09:25:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329211467!52636678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 14 Feb 2012 09:24:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 09:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10679502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:25:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 09:25:19 +0000
Message-ID: <1329211517.31256.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "=?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <Chunqi Li>" <yzt356@gmail.com>
Date: Tue, 14 Feb 2012 09:25:17 +0000
In-Reply-To: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAyLTE0IGF0IDA3OjAzICswMDAwLCDmnY7mmKXlpYcgd3JvdGU6ClsuLi5d
Cj4gYW5kIHRoZXJlIGFyZSB0aHJlZSBmcmVxdWVudGx5IHVzZWQgbWFjcm8gZm9yIGxvZ2dpbmc6
Cj4gI2RlZmluZSBEUFJJTlRGKF9mLCBfYS4uLikgc3lzbG9nKExPR19JTkZPLCBfZiwgIyNfYSkK
ClN5c2xvZyBpcyBhIHN0YW5kYXJkIFVuaXggZnVuY3Rpb24gKFNVU3YyIGFuZC9vciBQT1NJWCBJ
SVJDKSBhbmQgbm90CnNvbWV0aGluZyBzcGVjaWZpYyB0byBYZW4uIEdvb2dsZSBvciAibWFuIC1r
IiBzaG91bGQgYmUgYWJsZSB0byBmaW5kIHlvdQptb3JlIGRldGFpbHMgb2YgdGhpcyBhbmQgcmVs
YXRlZCBmdW5jdGlvbnMuCgo+IFdobyBjYW4gdGVsbCBtZSB3aGljaCBmaWxlIG1hdGNoIHRoZXNl
IGxvZyB0eXBlIGFib3ZlPyBUaGFuayB5b3UuCgpUaGUgZmluYWwgbG9jYXRpb24gd2lsbCBkZXBl
bmQgc29tZXdoYXQgb24geW91ciBkaXN0cm8ncyBjb25maWd1cmF0aW9uLAppdCdzIGxpa2VseSB0
byBiZSBzb21ld2hlcmUgdW5kZXIgL3Zhci9sb2cuIEEgZGlzdHJvIHNwZWNpZmljIGxpc3Qgb3IK
Zm9ydW0gd291bGQgYmUgYSBtb3JlIGFwcHJvcHJpYXRlIHBsYWNlIHRvIHB1cnN1ZSB0aGlzLgoK
SWFuLgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:25:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxEdV-0002K0-ML; Tue, 14 Feb 2012 09:25:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxEdU-0002Jt-Io
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:25:20 +0000
Received: from [193.109.254.147:21527] by server-1.bemta-14.messagelabs.com id
	1C/02-12485-F782A3F4; Tue, 14 Feb 2012 09:25:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329211467!52636678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 14 Feb 2012 09:24:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 09:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10679502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:25:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 09:25:19 +0000
Message-ID: <1329211517.31256.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "=?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <Chunqi Li>" <yzt356@gmail.com>
Date: Tue, 14 Feb 2012 09:25:17 +0000
In-Reply-To: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAyLTE0IGF0IDA3OjAzICswMDAwLCDmnY7mmKXlpYcgd3JvdGU6ClsuLi5d
Cj4gYW5kIHRoZXJlIGFyZSB0aHJlZSBmcmVxdWVudGx5IHVzZWQgbWFjcm8gZm9yIGxvZ2dpbmc6
Cj4gI2RlZmluZSBEUFJJTlRGKF9mLCBfYS4uLikgc3lzbG9nKExPR19JTkZPLCBfZiwgIyNfYSkK
ClN5c2xvZyBpcyBhIHN0YW5kYXJkIFVuaXggZnVuY3Rpb24gKFNVU3YyIGFuZC9vciBQT1NJWCBJ
SVJDKSBhbmQgbm90CnNvbWV0aGluZyBzcGVjaWZpYyB0byBYZW4uIEdvb2dsZSBvciAibWFuIC1r
IiBzaG91bGQgYmUgYWJsZSB0byBmaW5kIHlvdQptb3JlIGRldGFpbHMgb2YgdGhpcyBhbmQgcmVs
YXRlZCBmdW5jdGlvbnMuCgo+IFdobyBjYW4gdGVsbCBtZSB3aGljaCBmaWxlIG1hdGNoIHRoZXNl
IGxvZyB0eXBlIGFib3ZlPyBUaGFuayB5b3UuCgpUaGUgZmluYWwgbG9jYXRpb24gd2lsbCBkZXBl
bmQgc29tZXdoYXQgb24geW91ciBkaXN0cm8ncyBjb25maWd1cmF0aW9uLAppdCdzIGxpa2VseSB0
byBiZSBzb21ld2hlcmUgdW5kZXIgL3Zhci9sb2cuIEEgZGlzdHJvIHNwZWNpZmljIGxpc3Qgb3IK
Zm9ydW0gd291bGQgYmUgYSBtb3JlIGFwcHJvcHJpYXRlIHBsYWNlIHRvIHB1cnN1ZSB0aGlzLgoK
SWFuLgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:41:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxEsY-0002g0-4o; Tue, 14 Feb 2012 09:40:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rx6xK-0007ak-D9
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:13:18 +0000
X-Env-Sender: 350608693@qq.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329181991!13228259!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=1.4 required=7.0 tests=FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2532 invoked from network); 14 Feb 2012 01:13:12 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 01:13:12 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rx6xC-0006FU-Cd
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:13:10 -0800
Date: Mon, 13 Feb 2012 17:13:10 -0800 (PST)
From: yunjiedu <350608693@qq.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329181990385-5481067.post@n5.nabble.com>
In-Reply-To: <20120213103620.GC88765@ocelot.phlegethon.org>
References: <1328880882031-5472445.post@n5.nabble.com>
	<20120213103620.GC88765@ocelot.phlegethon.org>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 14 Feb 2012 09:40:52 +0000
Subject: Re: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

OK,i got it.thanks~

--
View this message in context: http://xen.1045712.n5.nabble.com/where-printk-output-tp5472445p5481067.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:41:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxEsY-0002g0-4o; Tue, 14 Feb 2012 09:40:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rx6xK-0007ak-D9
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:13:18 +0000
X-Env-Sender: 350608693@qq.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329181991!13228259!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=1.4 required=7.0 tests=FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2532 invoked from network); 14 Feb 2012 01:13:12 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 01:13:12 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <350608693@qq.com>) id 1Rx6xC-0006FU-Cd
	for xen-devel@lists.xensource.com; Mon, 13 Feb 2012 17:13:10 -0800
Date: Mon, 13 Feb 2012 17:13:10 -0800 (PST)
From: yunjiedu <350608693@qq.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329181990385-5481067.post@n5.nabble.com>
In-Reply-To: <20120213103620.GC88765@ocelot.phlegethon.org>
References: <1328880882031-5472445.post@n5.nabble.com>
	<20120213103620.GC88765@ocelot.phlegethon.org>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 14 Feb 2012 09:40:52 +0000
Subject: Re: [Xen-devel] where printk() output?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

OK,i got it.thanks~

--
View this message in context: http://xen.1045712.n5.nabble.com/where-printk-output-tp5472445p5481067.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:48:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09: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.xensource.com>)
	id 1RxEzo-0003Oo-Mf; Tue, 14 Feb 2012 09:48:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEzn-0003OW-M9
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:48:23 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329212896!14230835!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13030 invoked from network); 14 Feb 2012 09:48:17 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 09:48:17 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEzg-0006pr-3a
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:48:16 -0800
Date: Tue, 14 Feb 2012 01:48:16 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329212896102-5481990.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202131429550.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
	<alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
	<1328911300080-5473881.post@n5.nabble.com>
	<alpine.DEB.2.00.1202131429550.7456@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply, stdvga=1 seem to solve some of the more important problem
but not all and not performance/refresh, also try with add videoram=16 but
not improve.
I tried also with compiz disabled and gnome classic instead of unity but
nothing changed.



--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5481990.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 09:48:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 09: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.xensource.com>)
	id 1RxEzo-0003Oo-Mf; Tue, 14 Feb 2012 09:48:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEzn-0003OW-M9
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 09:48:23 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329212896!14230835!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13030 invoked from network); 14 Feb 2012 09:48:17 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 09:48:17 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxEzg-0006pr-3a
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 01:48:16 -0800
Date: Tue, 14 Feb 2012 01:48:16 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329212896102-5481990.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202131429550.7456@kaball-desktop>
References: <1328739782447-5467907.post@n5.nabble.com>
	<CAMrPLWLVcCSQCgLOU3Gs719V5eiP0Xo8w0evPfctP23=B=ehLQ@mail.gmail.com>
	<1328777821.6133.99.camel@zakaz.uk.xensource.com>
	<1328881672637-5472477.post@n5.nabble.com>
	<alpine.DEB.2.00.1202101718450.7456@kaball-desktop>
	<1328911300080-5473881.post@n5.nabble.com>
	<alpine.DEB.2.00.1202131429550.7456@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Spice in unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply, stdvga=1 seem to solve some of the more important problem
but not all and not performance/refresh, also try with add videoram=16 but
not improve.
I tried also with compiz disabled and gnome classic instead of unity but
nothing changed.



--
View this message in context: http://xen.1045712.n5.nabble.com/Spice-in-unstable-tp5467907p5481990.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxFKO-0003nq-P4; Tue, 14 Feb 2012 10:09:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxFKN-0003nk-C2
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:09:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329214172!13281269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27170 invoked from network); 14 Feb 2012 10:09:33 -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;
	14 Feb 2012 10:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10680775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:09:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 10:09:33 +0000
Message-ID: <1329214171.31256.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Tue, 14 Feb 2012 10:09:31 +0000
In-Reply-To: <37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1On Tue, 2012-02-14 at 00:54 +0000, Christopher S. Aker wrote:
> On Feb 13, 2012, at 5:41 PM, Christopher S. Aker wrote:
> > Network stress testing (iperf, UDP, bidirectional) the above stack reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs with the following:
> > 
> > BUG: unable to handle kernel NULL pointer dereference at 00000474
> > IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
> 
> This happens regardless of CONFIG_PARAVIRT_SPINLOCKS enabled or disabled.

I think that rules out the recent pv spinlock bug (fixed by
7a7546b377bdaa25ac77f33d9433c59f259b9688, in various stable trees
AFAIK).

What line of code does that IP correspond to within xen_spin_lock_flags?
Likewise the one in xen_netbk_schedule_xenvif from the stack.

I suspect this must be &netbk->net_schedule_list_lock but I don't see
how that can ever be NULL nor does the offset appear to be 0x474, at
least in my tree -- although that may depend on debug options.

Are you rebooting guests or plug/unplugging vifs while this is going on?
What about hotplugging CPUs (dom0 in particular)?

Does this happen as soon as the test starts or does it work for a bit
before failing?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxFKO-0003nq-P4; Tue, 14 Feb 2012 10:09:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxFKN-0003nk-C2
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:09:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329214172!13281269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27170 invoked from network); 14 Feb 2012 10:09:33 -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;
	14 Feb 2012 10:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10680775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:09:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 10:09:33 +0000
Message-ID: <1329214171.31256.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Tue, 14 Feb 2012 10:09:31 +0000
In-Reply-To: <37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1On Tue, 2012-02-14 at 00:54 +0000, Christopher S. Aker wrote:
> On Feb 13, 2012, at 5:41 PM, Christopher S. Aker wrote:
> > Network stress testing (iperf, UDP, bidirectional) the above stack reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs with the following:
> > 
> > BUG: unable to handle kernel NULL pointer dereference at 00000474
> > IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
> 
> This happens regardless of CONFIG_PARAVIRT_SPINLOCKS enabled or disabled.

I think that rules out the recent pv spinlock bug (fixed by
7a7546b377bdaa25ac77f33d9433c59f259b9688, in various stable trees
AFAIK).

What line of code does that IP correspond to within xen_spin_lock_flags?
Likewise the one in xen_netbk_schedule_xenvif from the stack.

I suspect this must be &netbk->net_schedule_list_lock but I don't see
how that can ever be NULL nor does the offset appear to be 0x474, at
least in my tree -- although that may depend on debug options.

Are you rebooting guests or plug/unplugging vifs while this is going on?
What about hotplugging CPUs (dom0 in particular)?

Does this happen as soon as the test starts or does it work for a bit
before failing?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10: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.xensource.com>)
	id 1RxFss-000557-Bj; Tue, 14 Feb 2012 10:45:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxFsr-00054k-Ii
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329216310!14717463!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24994 invoked from network); 14 Feb 2012 10:45:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 10:45:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10682048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:44:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 10:44:53 +0000
Message-ID: <1329216291.31256.207.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 10:44:51 +0000
In-Reply-To: <osstest-11946-mainreport@xen.org>
References: <osstest-11946-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote:
> flight 11946 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944

Host crash:
http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log

This is the debug Andrew Cooper added recently to track down the IRQ
assertion we've been seeing, sadly it looks like the debug code tries to
call xfree from interrupt context and therefore doesn't produce full
output :-(

Or is 24675:d82a1e3d3c65 ("xsm: Add security label to IRQ debug output")
at fault for adding the xfree in what may be an IRQ context? (are
keyhandlers run in IRQ context?)

A skanky quick "fix" follows.

        Feb 13 17:17:29.777522 (XEN) *** IRQ BUG found ***
        Feb 13 17:19:32.594539 (XEN) CPU0 -Testing vector 229 from bitmap 34,48,57,64,72,75,80,83,88,97,104-105,113,120-121,129,136,144,152,160,168,176,184,192,202
        Feb 13 17:19:32.617515 (XEN) Guest interrupt information:
        Feb 13 17:19:32.617536 (XEN)    IRQ:   0 affinity:001 vec:f0 type=IO-APIC-edge    status=00000000 mapped, unbound
        Feb 13 17:19:32.617567 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
        Feb 13 17:19:32.626489 (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
        Feb 13 17:19:32.626512 (XEN) CPU:    0
        Feb 13 17:19:32.626525 (XEN) RIP:    e008:[<ffff82c48012c842>] xfree+0x33/0x121
        Feb 13 17:19:32.641496 (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
        Feb 13 17:19:32.641519 (XEN) rax: ffff82c4802d0800   rbx: ffff8301a7e00080   rcx: 0000000000000000
        Feb 13 17:19:32.650560 (XEN) rdx: 0000000000000000   rsi: 0000000000000083   rdi: 0000000000000000
        Feb 13 17:19:32.665510 (XEN) rbp: ffff82c4802afd18   rsp: ffff82c4802afcf8   r8:  0000000000000004
        Feb 13 17:19:32.665550 (XEN) r9:  0000000000000000   r10: 0000000000000006   r11: ffff82c480224aa0
        Feb 13 17:19:32.673509 (XEN) r12: ffff8301a7e00580   r13: 0000000000000005   r14: ffff82c4802aff18
        Feb 13 17:19:32.685503 (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
        Feb 13 17:19:32.685537 (XEN) cr3: 00000001a7f54000   cr2: 00000000c4b4ee84
        Feb 13 17:19:32.697505 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
        Feb 13 17:19:32.697540 (XEN) Xen stack trace from rsp=ffff82c4802afcf8:
        Feb 13 17:19:32.706513 (XEN)    ffff8301a7e00080 ffff8301a7e00580 0000000000000005 ffff82c4802aff18
        Feb 13 17:19:32.721495 (XEN)    ffff82c4802afd88 ffff82c4801658ee ffff82c4802afd38 ffff82c48010098a
        Feb 13 17:19:32.721531 (XEN)    00000400802afd68 0000000000000083 ffff8301a7e000a8 0000000000000000
        Feb 13 17:19:32.729495 (XEN)    00000000fffffffa 00000000000000e5 ffff8301a7e00580 0000000000000005
        Feb 13 17:19:32.738490 (XEN)    ffff82c4802aff18 ffff8301a7e005a8 ffff82c4802afe28 ffff82c480167781
        Feb 13 17:19:32.738515 (XEN)    ffff8301a7ece000 ffff82c4802afde8 0000000000000000 ffff82c4802aff18
        Feb 13 17:19:32.750497 (XEN)    ffff82c4802aff18 0000000000000002 ffff82c4802aff18 ffff82c4802fa060
        Feb 13 17:19:32.762568 (XEN)    000000e500000000 ffff82c4802fa060 ffff82c4802afe08 ffff82c48017bd51
        Feb 13 17:19:32.762596 (XEN)    ffff82c4802aff18 ffff82c4802aff18 ffff82c48025e380 ffff82c4802aff18
        Feb 13 17:19:32.773513 (XEN)    00000000ffffffff 0000000000000002 00007d3b7fd501a7 ffff82c4801525d0
        Feb 13 17:19:32.785503 (XEN)    0000000000000002 00000000ffffffff ffff82c4802aff18 ffff82c48025e380
        Feb 13 17:19:32.785539 (XEN)    ffff82c4802afee0 ffff82c4802aff18 0000001863058413 00000000000c0000
        Feb 13 17:19:32.794514 (XEN)    000000000e1ff99c 000000000000c701 ffff82c4802f9a90 0000000000000000
        Feb 13 17:19:32.809503 (XEN)    0000000000000000 ffff8301a7f5dc80 0000000000000000 0000002000000000
        Feb 13 17:19:32.809529 (XEN)    ffff82c4801581a9 000000000000e008 0000000000000246 ffff82c4802afee0
        Feb 13 17:19:32.814513 (XEN)    0000000000000000 ffff82c4802aff10 ffff82c48015a647 0000000000000000
        Feb 13 17:19:32.829506 (XEN)    ffff8300d7cfb000 ffff8300d7af9000 0000000000000000 ffff82c4802afd88
        Feb 13 17:19:32.829549 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
        Feb 13 17:19:32.841510 (XEN)    00000000dfc91f90 00000000deadbeef 0000000000000000 0000000000000000
        Feb 13 17:19:32.853508 (XEN)    0000000000000000 0000000000000000 0000000000000000 00000000deadbeef
        Feb 13 17:19:32.858496 (XEN) Xen call trace:
        Feb 13 17:19:32.858518 (XEN)    [<ffff82c48012c842>] xfree+0x33/0x121
        Feb 13 17:19:32.858547 (XEN)    [<ffff82c4801658ee>] dump_irqs+0x2a3/0x2ca
        Feb 13 17:19:32.870500 (XEN)    [<ffff82c480167781>] smp_irq_move_cleanup_interrupt+0x303/0x37b
        Feb 13 17:19:32.870554 (XEN)    [<ffff82c4801525d0>] irq_move_cleanup_interrupt+0x30/0x40
        Feb 13 17:19:32.885510 (XEN)    [<ffff82c4801581a9>] default_idle+0x99/0x9e
        Feb 13 17:19:32.885541 (XEN)    [<ffff82c48015a647>] idle_loop+0x6c/0x7c
        Feb 13 17:19:32.897496 (XEN)    
        Feb 13 17:19:32.897510 (XEN) 
        Feb 13 17:19:32.897520 (XEN) ****************************************
        Feb 13 17:19:32.897537 (XEN) Panic on CPU 0:
        Feb 13 17:19:32.905499 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
        Feb 13 17:19:32.905522 (XEN) ****************************************
        Feb 13 17:19:32.913488 (XEN) 
        Feb 13 17:19:32.913506 (XEN) Reboot in five seconds...

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329216241 0
# Node ID 738424a5e5a5053c75cfbe64f6675b5d756daf1b
# Parent  0ba87b95e80bae059fe70b4b117dcc409f2471ef
xen: don't try to print IRQ SSID in IRQ debug from irq context.

It is not possible to call xfree() in that context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0ba87b95e80b -r 738424a5e5a5 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Mon Feb 13 17:26:08 2012 +0000
+++ b/xen/arch/x86/irq.c	Tue Feb 14 10:44:01 2012 +0000
@@ -2026,7 +2026,7 @@ static void dump_irqs(unsigned char key)
         if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
             continue;
 
-        ssid = xsm_show_irq_sid(irq);
+        ssid = in_irq() ? NULL : xsm_show_irq_sid(irq);
 
         spin_lock_irqsave(&desc->lock, flags);
 
@@ -2073,7 +2073,8 @@ static void dump_irqs(unsigned char key)
 
         spin_unlock_irqrestore(&desc->lock, flags);
 
-        xfree(ssid);
+        if ( ssid )
+                xfree(ssid);
     }
 
     dump_ioapic_irq_info();




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10: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.xensource.com>)
	id 1RxFss-000557-Bj; Tue, 14 Feb 2012 10:45:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxFsr-00054k-Ii
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329216310!14717463!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24994 invoked from network); 14 Feb 2012 10:45:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 10:45:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10682048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:44:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 10:44:53 +0000
Message-ID: <1329216291.31256.207.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 10:44:51 +0000
In-Reply-To: <osstest-11946-mainreport@xen.org>
References: <osstest-11946-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote:
> flight 11946 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944

Host crash:
http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log

This is the debug Andrew Cooper added recently to track down the IRQ
assertion we've been seeing, sadly it looks like the debug code tries to
call xfree from interrupt context and therefore doesn't produce full
output :-(

Or is 24675:d82a1e3d3c65 ("xsm: Add security label to IRQ debug output")
at fault for adding the xfree in what may be an IRQ context? (are
keyhandlers run in IRQ context?)

A skanky quick "fix" follows.

        Feb 13 17:17:29.777522 (XEN) *** IRQ BUG found ***
        Feb 13 17:19:32.594539 (XEN) CPU0 -Testing vector 229 from bitmap 34,48,57,64,72,75,80,83,88,97,104-105,113,120-121,129,136,144,152,160,168,176,184,192,202
        Feb 13 17:19:32.617515 (XEN) Guest interrupt information:
        Feb 13 17:19:32.617536 (XEN)    IRQ:   0 affinity:001 vec:f0 type=IO-APIC-edge    status=00000000 mapped, unbound
        Feb 13 17:19:32.617567 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
        Feb 13 17:19:32.626489 (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
        Feb 13 17:19:32.626512 (XEN) CPU:    0
        Feb 13 17:19:32.626525 (XEN) RIP:    e008:[<ffff82c48012c842>] xfree+0x33/0x121
        Feb 13 17:19:32.641496 (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
        Feb 13 17:19:32.641519 (XEN) rax: ffff82c4802d0800   rbx: ffff8301a7e00080   rcx: 0000000000000000
        Feb 13 17:19:32.650560 (XEN) rdx: 0000000000000000   rsi: 0000000000000083   rdi: 0000000000000000
        Feb 13 17:19:32.665510 (XEN) rbp: ffff82c4802afd18   rsp: ffff82c4802afcf8   r8:  0000000000000004
        Feb 13 17:19:32.665550 (XEN) r9:  0000000000000000   r10: 0000000000000006   r11: ffff82c480224aa0
        Feb 13 17:19:32.673509 (XEN) r12: ffff8301a7e00580   r13: 0000000000000005   r14: ffff82c4802aff18
        Feb 13 17:19:32.685503 (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
        Feb 13 17:19:32.685537 (XEN) cr3: 00000001a7f54000   cr2: 00000000c4b4ee84
        Feb 13 17:19:32.697505 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
        Feb 13 17:19:32.697540 (XEN) Xen stack trace from rsp=ffff82c4802afcf8:
        Feb 13 17:19:32.706513 (XEN)    ffff8301a7e00080 ffff8301a7e00580 0000000000000005 ffff82c4802aff18
        Feb 13 17:19:32.721495 (XEN)    ffff82c4802afd88 ffff82c4801658ee ffff82c4802afd38 ffff82c48010098a
        Feb 13 17:19:32.721531 (XEN)    00000400802afd68 0000000000000083 ffff8301a7e000a8 0000000000000000
        Feb 13 17:19:32.729495 (XEN)    00000000fffffffa 00000000000000e5 ffff8301a7e00580 0000000000000005
        Feb 13 17:19:32.738490 (XEN)    ffff82c4802aff18 ffff8301a7e005a8 ffff82c4802afe28 ffff82c480167781
        Feb 13 17:19:32.738515 (XEN)    ffff8301a7ece000 ffff82c4802afde8 0000000000000000 ffff82c4802aff18
        Feb 13 17:19:32.750497 (XEN)    ffff82c4802aff18 0000000000000002 ffff82c4802aff18 ffff82c4802fa060
        Feb 13 17:19:32.762568 (XEN)    000000e500000000 ffff82c4802fa060 ffff82c4802afe08 ffff82c48017bd51
        Feb 13 17:19:32.762596 (XEN)    ffff82c4802aff18 ffff82c4802aff18 ffff82c48025e380 ffff82c4802aff18
        Feb 13 17:19:32.773513 (XEN)    00000000ffffffff 0000000000000002 00007d3b7fd501a7 ffff82c4801525d0
        Feb 13 17:19:32.785503 (XEN)    0000000000000002 00000000ffffffff ffff82c4802aff18 ffff82c48025e380
        Feb 13 17:19:32.785539 (XEN)    ffff82c4802afee0 ffff82c4802aff18 0000001863058413 00000000000c0000
        Feb 13 17:19:32.794514 (XEN)    000000000e1ff99c 000000000000c701 ffff82c4802f9a90 0000000000000000
        Feb 13 17:19:32.809503 (XEN)    0000000000000000 ffff8301a7f5dc80 0000000000000000 0000002000000000
        Feb 13 17:19:32.809529 (XEN)    ffff82c4801581a9 000000000000e008 0000000000000246 ffff82c4802afee0
        Feb 13 17:19:32.814513 (XEN)    0000000000000000 ffff82c4802aff10 ffff82c48015a647 0000000000000000
        Feb 13 17:19:32.829506 (XEN)    ffff8300d7cfb000 ffff8300d7af9000 0000000000000000 ffff82c4802afd88
        Feb 13 17:19:32.829549 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
        Feb 13 17:19:32.841510 (XEN)    00000000dfc91f90 00000000deadbeef 0000000000000000 0000000000000000
        Feb 13 17:19:32.853508 (XEN)    0000000000000000 0000000000000000 0000000000000000 00000000deadbeef
        Feb 13 17:19:32.858496 (XEN) Xen call trace:
        Feb 13 17:19:32.858518 (XEN)    [<ffff82c48012c842>] xfree+0x33/0x121
        Feb 13 17:19:32.858547 (XEN)    [<ffff82c4801658ee>] dump_irqs+0x2a3/0x2ca
        Feb 13 17:19:32.870500 (XEN)    [<ffff82c480167781>] smp_irq_move_cleanup_interrupt+0x303/0x37b
        Feb 13 17:19:32.870554 (XEN)    [<ffff82c4801525d0>] irq_move_cleanup_interrupt+0x30/0x40
        Feb 13 17:19:32.885510 (XEN)    [<ffff82c4801581a9>] default_idle+0x99/0x9e
        Feb 13 17:19:32.885541 (XEN)    [<ffff82c48015a647>] idle_loop+0x6c/0x7c
        Feb 13 17:19:32.897496 (XEN)    
        Feb 13 17:19:32.897510 (XEN) 
        Feb 13 17:19:32.897520 (XEN) ****************************************
        Feb 13 17:19:32.897537 (XEN) Panic on CPU 0:
        Feb 13 17:19:32.905499 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
        Feb 13 17:19:32.905522 (XEN) ****************************************
        Feb 13 17:19:32.913488 (XEN) 
        Feb 13 17:19:32.913506 (XEN) Reboot in five seconds...

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329216241 0
# Node ID 738424a5e5a5053c75cfbe64f6675b5d756daf1b
# Parent  0ba87b95e80bae059fe70b4b117dcc409f2471ef
xen: don't try to print IRQ SSID in IRQ debug from irq context.

It is not possible to call xfree() in that context.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0ba87b95e80b -r 738424a5e5a5 xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c	Mon Feb 13 17:26:08 2012 +0000
+++ b/xen/arch/x86/irq.c	Tue Feb 14 10:44:01 2012 +0000
@@ -2026,7 +2026,7 @@ static void dump_irqs(unsigned char key)
         if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
             continue;
 
-        ssid = xsm_show_irq_sid(irq);
+        ssid = in_irq() ? NULL : xsm_show_irq_sid(irq);
 
         spin_lock_irqsave(&desc->lock, flags);
 
@@ -2073,7 +2073,8 @@ static void dump_irqs(unsigned char key)
 
         spin_unlock_irqrestore(&desc->lock, flags);
 
-        xfree(ssid);
+        if ( ssid )
+                xfree(ssid);
     }
 
     dump_ioapic_irq_info();




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:46:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxFtT-00057W-PU; Tue, 14 Feb 2012 10:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxFtR-000573-VY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:45:54 +0000
Received: from [85.158.143.35:2113] by server-1.bemta-4.messagelabs.com id
	83/94-20925-16B3A3F4; Tue, 14 Feb 2012 10:45:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329216352!2776453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12268 invoked from network); 14 Feb 2012 10:45:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 10:45:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 10:45:51 +0000
Message-Id: <4F3A496D0200007800072D7D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 10:45:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Keir Fraser" <keir@xen.org>
References: <4F39344B.5070504@citrix.com> <CB5EF09C.396C6%keir@xen.org>
In-Reply-To: <CB5EF09C.396C6%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	edwin.zhai@intel.com
Subject: Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack
	methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 17:53, Keir Fraser <keir@xen.org> wrote:
> On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
>> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
>> directed EOI support must use the old IO-APIC ack method.

The reason is that with this LAPIC feature you want to send the ack
to the LAPIC immediately (mask_and_ack_level_ioapic_irq()), which
matched the old method.

With the various conditionals there and in end_level_ioapic_irq() it
may be a good first step to create three distinct hw_irq_controller
instances (old, new, and "directed EOI") for level triggered interrupts,
and have them do just what is needed for the specific case. Then it
may become easier to spot what's going wrong.

> Well, it's not surprising that some systems won't like this method. Firstly,
> calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
> broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
> to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
> operation.
> 
> Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
> -- if the IO-APIC does not have an EOI register, then an EOI is forced in a
> slightly gross way. I wonder how reliable that is across a broad range of
> chipsets; reliable enough to rely on it for *every* interrupt? ;-)

With the EOI register pre-dating this mis-named CPU feature, I
wouldn't expect anyone to have built a system with CPU(s) this new
but an old chipset. But it's certainly worth verifying the IO-APIC
version on the affected system(s).

> Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
> personally quite happy to see the original patch reverted.

Let's rather try understanding the issue than reverting something that
ought to help performance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:46:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxFtT-00057W-PU; Tue, 14 Feb 2012 10:45:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxFtR-000573-VY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:45:54 +0000
Received: from [85.158.143.35:2113] by server-1.bemta-4.messagelabs.com id
	83/94-20925-16B3A3F4; Tue, 14 Feb 2012 10:45:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329216352!2776453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12268 invoked from network); 14 Feb 2012 10:45:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 10:45:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 10:45:51 +0000
Message-Id: <4F3A496D0200007800072D7D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 10:45:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>, "Keir Fraser" <keir@xen.org>
References: <4F39344B.5070504@citrix.com> <CB5EF09C.396C6%keir@xen.org>
In-Reply-To: <CB5EF09C.396C6%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	edwin.zhai@intel.com
Subject: Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack
	methods
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 17:53, Keir Fraser <keir@xen.org> wrote:
> On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
>> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
>> directed EOI support must use the old IO-APIC ack method.

The reason is that with this LAPIC feature you want to send the ack
to the LAPIC immediately (mask_and_ack_level_ioapic_irq()), which
matched the old method.

With the various conditionals there and in end_level_ioapic_irq() it
may be a good first step to create three distinct hw_irq_controller
instances (old, new, and "directed EOI") for level triggered interrupts,
and have them do just what is needed for the specific case. Then it
may become easier to spot what's going wrong.

> Well, it's not surprising that some systems won't like this method. Firstly,
> calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
> broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
> to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
> operation.
> 
> Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
> -- if the IO-APIC does not have an EOI register, then an EOI is forced in a
> slightly gross way. I wonder how reliable that is across a broad range of
> chipsets; reliable enough to rely on it for *every* interrupt? ;-)

With the EOI register pre-dating this mis-named CPU feature, I
wouldn't expect anyone to have built a system with CPU(s) this new
but an old chipset. But it's certainly worth verifying the IO-APIC
version on the affected system(s).

> Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
> personally quite happy to see the original patch reverted.

Let's rather try understanding the issue than reverting something that
ought to help performance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:46:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10: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.xensource.com>)
	id 1RxFtm-00059k-6W; Tue, 14 Feb 2012 10:46:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RxFtk-00059S-Jy
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:46:12 +0000
Received: from [85.158.139.83:53828] by server-6.bemta-5.messagelabs.com id
	04/EB-27305-37B3A3F4; Tue, 14 Feb 2012 10:46:11 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329216370!15005423!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19202 invoked from network); 14 Feb 2012 10:46:11 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 10:46:11 -0000
Received: by vcbfo11 with SMTP id fo11so12940791vcb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 02:46:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=zbcmN9Nc6PhvJ2Ttwbp+VBXsCJSPrGMAhsAlsPyuuqo=;
	b=RKza8F0iSImhs1OM9/D2B+XrLL/Ch8n5+bE/geOIOPkiRmpNN4sxpJ7KUvZqsDh3BD
	k/STA2CPPFWbG7GiYrqRxzHAC84ptsh6ugmZHOLRDe1arDU1D7UFGGX9IzTyQ0HT9KWY
	VnoPwU1jrE6NrvFX/SeGjBUdpyyarYGhHhSr8=
MIME-Version: 1.0
Received: by 10.52.177.38 with SMTP id cn6mr8488417vdc.8.1329216369903; Tue,
	14 Feb 2012 02:46:09 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Tue, 14 Feb 2012 02:46:09 -0800 (PST)
Date: Tue, 14 Feb 2012 19:46:09 +0900
Message-ID: <CAP2B859gZ8AdL-CSHhX6Ms=_KN5o2A7JhGaM+sippe3NftrpxQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Cc: seabios@seabios.org
Subject: [Xen-devel] Relation between PCI device and Xenstore Device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello All,

I am writing some code to share some devices via the xenstore, yet I
found a small problem.

When I list the devices from the PCI I get the device id and the
vendor id. On the xenstore I get the virtual-device, yet I have no
apparent way to correctly map them, Do I need to enumerate the PCI
devices, ask the size and then compare to xenstore so I can map them?
but what if they have the same size?
For example on my test VM I have to vbd 832 and 768 first is cdrom the
second disk.
On the pci I have this:
Device Vendor
32902 4663
4115 184
22611 1

I am interested in 226611 that corresponds to XEN.

Some light on this small issue?

Thanks for the help.

Daniel

-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 10:46:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 10: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.xensource.com>)
	id 1RxFtm-00059k-6W; Tue, 14 Feb 2012 10:46:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RxFtk-00059S-Jy
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:46:12 +0000
Received: from [85.158.139.83:53828] by server-6.bemta-5.messagelabs.com id
	04/EB-27305-37B3A3F4; Tue, 14 Feb 2012 10:46:11 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329216370!15005423!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19202 invoked from network); 14 Feb 2012 10:46:11 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 10:46:11 -0000
Received: by vcbfo11 with SMTP id fo11so12940791vcb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 02:46:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=zbcmN9Nc6PhvJ2Ttwbp+VBXsCJSPrGMAhsAlsPyuuqo=;
	b=RKza8F0iSImhs1OM9/D2B+XrLL/Ch8n5+bE/geOIOPkiRmpNN4sxpJ7KUvZqsDh3BD
	k/STA2CPPFWbG7GiYrqRxzHAC84ptsh6ugmZHOLRDe1arDU1D7UFGGX9IzTyQ0HT9KWY
	VnoPwU1jrE6NrvFX/SeGjBUdpyyarYGhHhSr8=
MIME-Version: 1.0
Received: by 10.52.177.38 with SMTP id cn6mr8488417vdc.8.1329216369903; Tue,
	14 Feb 2012 02:46:09 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Tue, 14 Feb 2012 02:46:09 -0800 (PST)
Date: Tue, 14 Feb 2012 19:46:09 +0900
Message-ID: <CAP2B859gZ8AdL-CSHhX6Ms=_KN5o2A7JhGaM+sippe3NftrpxQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Cc: seabios@seabios.org
Subject: [Xen-devel] Relation between PCI device and Xenstore Device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello All,

I am writing some code to share some devices via the xenstore, yet I
found a small problem.

When I list the devices from the PCI I get the device id and the
vendor id. On the xenstore I get the virtual-device, yet I have no
apparent way to correctly map them, Do I need to enumerate the PCI
devices, ask the size and then compare to xenstore so I can map them?
but what if they have the same size?
For example on my test VM I have to vbd 832 and 768 first is cdrom the
second disk.
On the pci I have this:
Device Vendor
32902 4663
4115 184
22611 1

I am interested in 226611 that corresponds to XEN.

Some light on this small issue?

Thanks for the help.

Daniel

-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:17:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxGNW-00074V-Ay; Tue, 14 Feb 2012 11:16:58 +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 1RxGNS-00073w-3Y
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:16:54 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329218153!56628845!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13298 invoked from network); 14 Feb 2012 11:15:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-27.messagelabs.com with SMTP;
	14 Feb 2012 11:15:53 -0000
Received: from p5b2e4a77.dip.t-dialin.net ([91.46.74.119] 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 1RxGNN-000217-5H; Tue, 14 Feb 2012 11:16:49 +0000
Message-ID: <4F3A42A0.50405@canonical.com>
Date: Tue, 14 Feb 2012 12:16:48 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Fantu <fantonifabio@tiscali.it>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
	<4F392F45.3000903@canonical.com>
	<1329211152890-5481930.post@n5.nabble.com>
In-Reply-To: <1329211152890-5481930.post@n5.nabble.com>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
 with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.02.2012 10:19, Fantu wrote:
> There are already some on attachment of first post...
> 
> ...
> (initramfs) cat /proc/partitions 
> major minor  #blocks  name
> 
>  202        1   10240000 xvda1
>  202        2    1024000 xvda2
>  (initramfs) blkid 
> /dev/xvda2: UUID="3a4d1b29-15b2-47b1-b97f-8c258a8b10d8" TYPE="swap"

Right, saw that. This is what the kernel has. So internally xvda1 is there and
has a size. The uuid link is created (or should be) when the device becomes
ready. Interestingly I can see a capacity change message for xvda2 but not for
xvda1. Not sure why.
But then there is also the fact that when you do a blkid manually, you also do
not get any info there. Not sure there would be any errors anywhere about that
or you just get no data at all.
Of course this could be related to something xl in 4.0 does differently. Problem
is I have 4.1.2 and I cannot see the same issues.

-Stefan
> 
> And about /dev/disk-by-uuid/:
> (initramfs) ls -al /dev/disk/by-uuid/
> lrwxrwxrwx    1        11 3a4d1b29-15b2-47b1-b97f-8c258a8b10d8 ->
> ../../xvda2
> drwxr-xr-x    4        80 ..
> drwxr-xr-x    2        60 .
> 
> If can help also udev info:
> (initramfs) udevadm info --query=all --path /block/xvda1
> P: /devices/vbd-51713/block/xvda1
> N: xvda1
> S: disk/by-path/xen-vbd-51713
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51713
> E: DEVNAME=/dev/xvda1
> E: DEVPATH=/devices/vbd-51713/block/xvda1
> E: DEVTYPE=disk
> E: ID_PART_TABLE_TYPE=dos
> E: ID_PATH=xen-vbd-51713
> E: ID_PATH_TAG=xen-vbd-51713
> E: MAJOR=202
> E: MINOR=1
> E: SUBSYSTEM=block
> E: UDEV_LOG=3
> E: USEC_INITIALIZED=282841
> (initramfs) udevadm info --query=all --path /block/xvda2
> P: /devices/vbd-51714/block/xvda2
> N: xvda2
> S: disk/by-path/xen-vbd-51714
> S: disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51714
> /dev/disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: DEVNAME=/dev/xvda2
> E: DEVPATH=/devices/vbd-51714/block/xvda2
> E: DEVTYPE=disk
> E: ID_FS_TYPE=swap
> E: ID_FS_USAGE=other
> E: ID_FS_UUID=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: ID_FS_UUID_ENC=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: ID_FS_VERSION=2
> E: ID_PATH=xen-vbd-51714
> E: ID_PATH_TAG=xen-vbd-51714
> E: MAJOR=202
> E: MINOR=2
> E: SUBSYSTEM=block
> E: UDEV_LOG=3
> E: USEC_INITIALIZED=283285
> 
> Only xvda2 (swap) seem to be full and correct, xvda1 not.
> On production system the same domU work, differences in which there is very
> likely the cause of the problem are then:
> Xen 4.0 with xm on production system and xen-unstable with xl on test system
> But I have no certainty that it is a problem of xen and/or xl.
> 
> Thanks for any reply and sorry for bad english.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5481930.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:17:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11:17:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxGNW-00074V-Ay; Tue, 14 Feb 2012 11:16:58 +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 1RxGNS-00073w-3Y
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:16:54 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329218153!56628845!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13298 invoked from network); 14 Feb 2012 11:15:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-27.messagelabs.com with SMTP;
	14 Feb 2012 11:15:53 -0000
Received: from p5b2e4a77.dip.t-dialin.net ([91.46.74.119] 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 1RxGNN-000217-5H; Tue, 14 Feb 2012 11:16:49 +0000
Message-ID: <4F3A42A0.50405@canonical.com>
Date: Tue, 14 Feb 2012 12:16:48 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Fantu <fantonifabio@tiscali.it>
References: <1329143937594-5479428.post@n5.nabble.com>
	<4F3923D6.2000502@canonical.com>
	<1329146007080-5479529.post@n5.nabble.com>
	<4F392F45.3000903@canonical.com>
	<1329211152890-5481930.post@n5.nabble.com>
In-Reply-To: <1329211152890-5481930.post@n5.nabble.com>
X-Enigmail-Version: 1.3.5
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Unable to start Precise domU PV on xen-unstable
 with xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14.02.2012 10:19, Fantu wrote:
> There are already some on attachment of first post...
> 
> ...
> (initramfs) cat /proc/partitions 
> major minor  #blocks  name
> 
>  202        1   10240000 xvda1
>  202        2    1024000 xvda2
>  (initramfs) blkid 
> /dev/xvda2: UUID="3a4d1b29-15b2-47b1-b97f-8c258a8b10d8" TYPE="swap"

Right, saw that. This is what the kernel has. So internally xvda1 is there and
has a size. The uuid link is created (or should be) when the device becomes
ready. Interestingly I can see a capacity change message for xvda2 but not for
xvda1. Not sure why.
But then there is also the fact that when you do a blkid manually, you also do
not get any info there. Not sure there would be any errors anywhere about that
or you just get no data at all.
Of course this could be related to something xl in 4.0 does differently. Problem
is I have 4.1.2 and I cannot see the same issues.

-Stefan
> 
> And about /dev/disk-by-uuid/:
> (initramfs) ls -al /dev/disk/by-uuid/
> lrwxrwxrwx    1        11 3a4d1b29-15b2-47b1-b97f-8c258a8b10d8 ->
> ../../xvda2
> drwxr-xr-x    4        80 ..
> drwxr-xr-x    2        60 .
> 
> If can help also udev info:
> (initramfs) udevadm info --query=all --path /block/xvda1
> P: /devices/vbd-51713/block/xvda1
> N: xvda1
> S: disk/by-path/xen-vbd-51713
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51713
> E: DEVNAME=/dev/xvda1
> E: DEVPATH=/devices/vbd-51713/block/xvda1
> E: DEVTYPE=disk
> E: ID_PART_TABLE_TYPE=dos
> E: ID_PATH=xen-vbd-51713
> E: ID_PATH_TAG=xen-vbd-51713
> E: MAJOR=202
> E: MINOR=1
> E: SUBSYSTEM=block
> E: UDEV_LOG=3
> E: USEC_INITIALIZED=282841
> (initramfs) udevadm info --query=all --path /block/xvda2
> P: /devices/vbd-51714/block/xvda2
> N: xvda2
> S: disk/by-path/xen-vbd-51714
> S: disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: DEVLINKS=/dev/disk/by-path/xen-vbd-51714
> /dev/disk/by-uuid/3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: DEVNAME=/dev/xvda2
> E: DEVPATH=/devices/vbd-51714/block/xvda2
> E: DEVTYPE=disk
> E: ID_FS_TYPE=swap
> E: ID_FS_USAGE=other
> E: ID_FS_UUID=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: ID_FS_UUID_ENC=3a4d1b29-15b2-47b1-b97f-8c258a8b10d8
> E: ID_FS_VERSION=2
> E: ID_PATH=xen-vbd-51714
> E: ID_PATH_TAG=xen-vbd-51714
> E: MAJOR=202
> E: MINOR=2
> E: SUBSYSTEM=block
> E: UDEV_LOG=3
> E: USEC_INITIALIZED=283285
> 
> Only xvda2 (swap) seem to be full and correct, xvda1 not.
> On production system the same domU work, differences in which there is very
> likely the cause of the problem are then:
> Xen 4.0 with xm on production system and xen-unstable with xl on test system
> But I have no certainty that it is a problem of xen and/or xl.
> 
> Thanks for any reply and sorry for bad english.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-start-Precise-domU-PV-on-xen-unstable-with-xl-tp5479428p5481930.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:32:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11: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.xensource.com>)
	id 1RxGcP-00008B-KI; Tue, 14 Feb 2012 11:32:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxGcO-00007A-NO
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:32:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329219134!12799565!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5899 invoked from network); 14 Feb 2012 11:32:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 11:32:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 11:32:13 +0000
Message-Id: <4F3A544C0200007800072DC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 11:32:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part77590F2C.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blkfront: properly fail packet
	requests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part77590F2C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

c/s 1036:f5635e334aa5 ("blkfront: forward unknown IOCTLs to
scsi_cmd_ioctl() for /dev/sdX") uncovered a problem in blkfront's
request handling: blk_pc_request()-s, among other sources resulting
from the handling of the SG_IO ioctl in scsi_cmd_ioctl(), must not be
passed to end_request() without prior adjustment: Neither is their
->hard_cur_sectors necessarily correct (potentially resulting in an
infinite loop), nor is ->errors ever getting set properly to reflect
the failure (sg_io() intentionally ignores the return value from
blk_execute_rq()).

As blktap2's internally created devices have the same deficiency, fix
this there too.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blkfront/blkfront.c
+++ b/drivers/xen/blkfront/blkfront.c
@@ -709,6 +709,12 @@ void do_blkif_request(request_queue_t *r
 	while ((req =3D elv_next_request(rq)) !=3D NULL) {
 		info =3D req->rq_disk->private_data;
 		if (!blk_fs_request(req)) {
+			if (blk_pc_request(req)) {
+				req->errors =3D (DID_ERROR << 16)
+					      | (DRIVER_INVALID << 24);
+				req->hard_cur_sectors =3D (req->data_len
+							 + 511) >> 9;
+			}
 			end_request(req, 0);
 			continue;
 		}
--- a/drivers/xen/blktap2/device.c
+++ b/drivers/xen/blktap2/device.c
@@ -3,6 +3,7 @@
 #include <linux/cdrom.h>
 #include <linux/hdreg.h>
 #include <linux/module.h>
+#include <scsi/scsi.h>
 #include <asm/tlbflush.h>
=20
 #include <scsi/scsi.h>
@@ -825,6 +826,12 @@ blktap_device_run_queue(struct blktap *t
=20
 	while ((req =3D elv_next_request(rq)) !=3D NULL) {
 		if (!blk_fs_request(req)) {
+			if (blk_pc_request(req)) {
+				req->errors =3D (DID_ERROR << 16)
+					      | (DRIVER_INVALID << 24);
+				req->hard_cur_sectors =3D (req->data_len
+							 + 511) >> 9;
+			}
 			end_request(req, 0);
 			continue;
 		}
@@ -912,9 +919,16 @@ blktap_device_do_request(request_queue_t
=20
 fail:
 	while ((req =3D elv_next_request(rq))) {
-		BTERR("device closed: failing secs %llu - %llu\n",
-		      (unsigned long long)req->sector,
-		      (unsigned long long)req->sector + req->nr_sectors);
+		if (blk_fs_request(req)) {
+			unsigned long long sec =3D req->sector;
+
+			BTERR("device closed: failing secs %#Lx-%#Lx\n",
+			      sec, sec + req->nr_sectors - 1);
+		} else if (blk_pc_request(req)) {
+			req->errors =3D (DID_ERROR << 16)
+				      | (DRIVER_INVALID << 24);
+			req->hard_cur_sectors =3D (req->data_len + 511) >> =
9;
+		}
 		end_request(req, 0);
 	}
 }




--=__Part77590F2C.0__=
Content-Type: text/plain; name="xen-blkfront-sg_io.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blkfront-sg_io.patch"

blkfront: properly fail packet requests=0A=0Ac/s 1036:f5635e334aa5 =
("blkfront: forward unknown IOCTLs to=0Ascsi_cmd_ioctl() for /dev/sdX") =
uncovered a problem in blkfront's=0Arequest handling: blk_pc_request()-s, =
among other sources resulting=0Afrom the handling of the SG_IO ioctl in =
scsi_cmd_ioctl(), must not be=0Apassed to end_request() without prior =
adjustment: Neither is their=0A->hard_cur_sectors necessarily correct =
(potentially resulting in an=0Ainfinite loop), nor is ->errors ever =
getting set properly to reflect=0Athe failure (sg_io() intentionally =
ignores the return value from=0Ablk_execute_rq()).=0A=0AAs blktap2's =
internally created devices have the same deficiency, fix=0Athis there =
too.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/blkfront/blkfront.c=0A+++ b/drivers/xen/blkfront/blkfront.c=
=0A@@ -709,6 +709,12 @@ void do_blkif_request(request_queue_t *r=0A 	=
while ((req =3D elv_next_request(rq)) !=3D NULL) {=0A 		info =3D =
req->rq_disk->private_data;=0A 		if (!blk_fs_request(req)) {=0A+		=
	if (blk_pc_request(req)) {=0A+				req->errors=
 =3D (DID_ERROR << 16)=0A+					      | =
(DRIVER_INVALID << 24);=0A+				req->hard_cur_secto=
rs =3D (req->data_len=0A+							=
 + 511) >> 9;=0A+			}=0A 			end_request=
(req, 0);=0A 			continue;=0A 		}=0A--- a/drivers/x=
en/blktap2/device.c=0A+++ b/drivers/xen/blktap2/device.c=0A@@ -3,6 +3,7 =
@@=0A #include <linux/cdrom.h>=0A #include <linux/hdreg.h>=0A #include =
<linux/module.h>=0A+#include <scsi/scsi.h>=0A #include <asm/tlbflush.h>=0A =
=0A #include <scsi/scsi.h>=0A@@ -825,6 +826,12 @@ blktap_device_run_queue(s=
truct blktap *t=0A =0A 	while ((req =3D elv_next_request(rq)) !=3D NULL) =
{=0A 		if (!blk_fs_request(req)) {=0A+			if =
(blk_pc_request(req)) {=0A+				req->errors =3D =
(DID_ERROR << 16)=0A+					      | (DRIVER_INV=
ALID << 24);=0A+				req->hard_cur_sectors =3D =
(req->data_len=0A+							 + =
511) >> 9;=0A+			}=0A 			end_request(req, =
0);=0A 			continue;=0A 		}=0A@@ -912,9 +919,16 @@ =
blktap_device_do_request(request_queue_t=0A =0A fail:=0A 	while =
((req =3D elv_next_request(rq))) {=0A-		BTERR("device closed: =
failing secs %llu - %llu\n",=0A-		      (unsigned long =
long)req->sector,=0A-		      (unsigned long long)req->sector + =
req->nr_sectors);=0A+		if (blk_fs_request(req)) {=0A+			=
unsigned long long sec =3D req->sector;=0A+=0A+			BTERR("devi=
ce closed: failing secs %#Lx-%#Lx\n",=0A+			      sec, =
sec + req->nr_sectors - 1);=0A+		} else if (blk_pc_request(req)) =
{=0A+			req->errors =3D (DID_ERROR << 16)=0A+			=
	      | (DRIVER_INVALID << 24);=0A+			req->hard_c=
ur_sectors =3D (req->data_len + 511) >> 9;=0A+		}=0A 		=
end_request(req, 0);=0A 	}=0A }=0A
--=__Part77590F2C.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part77590F2C.0__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:32:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11: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.xensource.com>)
	id 1RxGcP-00008B-KI; Tue, 14 Feb 2012 11:32:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxGcO-00007A-NO
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:32:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329219134!12799565!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5899 invoked from network); 14 Feb 2012 11:32:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 11:32:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 11:32:13 +0000
Message-Id: <4F3A544C0200007800072DC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 11:32:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part77590F2C.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blkfront: properly fail packet
	requests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part77590F2C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

c/s 1036:f5635e334aa5 ("blkfront: forward unknown IOCTLs to
scsi_cmd_ioctl() for /dev/sdX") uncovered a problem in blkfront's
request handling: blk_pc_request()-s, among other sources resulting
from the handling of the SG_IO ioctl in scsi_cmd_ioctl(), must not be
passed to end_request() without prior adjustment: Neither is their
->hard_cur_sectors necessarily correct (potentially resulting in an
infinite loop), nor is ->errors ever getting set properly to reflect
the failure (sg_io() intentionally ignores the return value from
blk_execute_rq()).

As blktap2's internally created devices have the same deficiency, fix
this there too.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blkfront/blkfront.c
+++ b/drivers/xen/blkfront/blkfront.c
@@ -709,6 +709,12 @@ void do_blkif_request(request_queue_t *r
 	while ((req =3D elv_next_request(rq)) !=3D NULL) {
 		info =3D req->rq_disk->private_data;
 		if (!blk_fs_request(req)) {
+			if (blk_pc_request(req)) {
+				req->errors =3D (DID_ERROR << 16)
+					      | (DRIVER_INVALID << 24);
+				req->hard_cur_sectors =3D (req->data_len
+							 + 511) >> 9;
+			}
 			end_request(req, 0);
 			continue;
 		}
--- a/drivers/xen/blktap2/device.c
+++ b/drivers/xen/blktap2/device.c
@@ -3,6 +3,7 @@
 #include <linux/cdrom.h>
 #include <linux/hdreg.h>
 #include <linux/module.h>
+#include <scsi/scsi.h>
 #include <asm/tlbflush.h>
=20
 #include <scsi/scsi.h>
@@ -825,6 +826,12 @@ blktap_device_run_queue(struct blktap *t
=20
 	while ((req =3D elv_next_request(rq)) !=3D NULL) {
 		if (!blk_fs_request(req)) {
+			if (blk_pc_request(req)) {
+				req->errors =3D (DID_ERROR << 16)
+					      | (DRIVER_INVALID << 24);
+				req->hard_cur_sectors =3D (req->data_len
+							 + 511) >> 9;
+			}
 			end_request(req, 0);
 			continue;
 		}
@@ -912,9 +919,16 @@ blktap_device_do_request(request_queue_t
=20
 fail:
 	while ((req =3D elv_next_request(rq))) {
-		BTERR("device closed: failing secs %llu - %llu\n",
-		      (unsigned long long)req->sector,
-		      (unsigned long long)req->sector + req->nr_sectors);
+		if (blk_fs_request(req)) {
+			unsigned long long sec =3D req->sector;
+
+			BTERR("device closed: failing secs %#Lx-%#Lx\n",
+			      sec, sec + req->nr_sectors - 1);
+		} else if (blk_pc_request(req)) {
+			req->errors =3D (DID_ERROR << 16)
+				      | (DRIVER_INVALID << 24);
+			req->hard_cur_sectors =3D (req->data_len + 511) >> =
9;
+		}
 		end_request(req, 0);
 	}
 }




--=__Part77590F2C.0__=
Content-Type: text/plain; name="xen-blkfront-sg_io.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blkfront-sg_io.patch"

blkfront: properly fail packet requests=0A=0Ac/s 1036:f5635e334aa5 =
("blkfront: forward unknown IOCTLs to=0Ascsi_cmd_ioctl() for /dev/sdX") =
uncovered a problem in blkfront's=0Arequest handling: blk_pc_request()-s, =
among other sources resulting=0Afrom the handling of the SG_IO ioctl in =
scsi_cmd_ioctl(), must not be=0Apassed to end_request() without prior =
adjustment: Neither is their=0A->hard_cur_sectors necessarily correct =
(potentially resulting in an=0Ainfinite loop), nor is ->errors ever =
getting set properly to reflect=0Athe failure (sg_io() intentionally =
ignores the return value from=0Ablk_execute_rq()).=0A=0AAs blktap2's =
internally created devices have the same deficiency, fix=0Athis there =
too.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/blkfront/blkfront.c=0A+++ b/drivers/xen/blkfront/blkfront.c=
=0A@@ -709,6 +709,12 @@ void do_blkif_request(request_queue_t *r=0A 	=
while ((req =3D elv_next_request(rq)) !=3D NULL) {=0A 		info =3D =
req->rq_disk->private_data;=0A 		if (!blk_fs_request(req)) {=0A+		=
	if (blk_pc_request(req)) {=0A+				req->errors=
 =3D (DID_ERROR << 16)=0A+					      | =
(DRIVER_INVALID << 24);=0A+				req->hard_cur_secto=
rs =3D (req->data_len=0A+							=
 + 511) >> 9;=0A+			}=0A 			end_request=
(req, 0);=0A 			continue;=0A 		}=0A--- a/drivers/x=
en/blktap2/device.c=0A+++ b/drivers/xen/blktap2/device.c=0A@@ -3,6 +3,7 =
@@=0A #include <linux/cdrom.h>=0A #include <linux/hdreg.h>=0A #include =
<linux/module.h>=0A+#include <scsi/scsi.h>=0A #include <asm/tlbflush.h>=0A =
=0A #include <scsi/scsi.h>=0A@@ -825,6 +826,12 @@ blktap_device_run_queue(s=
truct blktap *t=0A =0A 	while ((req =3D elv_next_request(rq)) !=3D NULL) =
{=0A 		if (!blk_fs_request(req)) {=0A+			if =
(blk_pc_request(req)) {=0A+				req->errors =3D =
(DID_ERROR << 16)=0A+					      | (DRIVER_INV=
ALID << 24);=0A+				req->hard_cur_sectors =3D =
(req->data_len=0A+							 + =
511) >> 9;=0A+			}=0A 			end_request(req, =
0);=0A 			continue;=0A 		}=0A@@ -912,9 +919,16 @@ =
blktap_device_do_request(request_queue_t=0A =0A fail:=0A 	while =
((req =3D elv_next_request(rq))) {=0A-		BTERR("device closed: =
failing secs %llu - %llu\n",=0A-		      (unsigned long =
long)req->sector,=0A-		      (unsigned long long)req->sector + =
req->nr_sectors);=0A+		if (blk_fs_request(req)) {=0A+			=
unsigned long long sec =3D req->sector;=0A+=0A+			BTERR("devi=
ce closed: failing secs %#Lx-%#Lx\n",=0A+			      sec, =
sec + req->nr_sectors - 1);=0A+		} else if (blk_pc_request(req)) =
{=0A+			req->errors =3D (DID_ERROR << 16)=0A+			=
	      | (DRIVER_INVALID << 24);=0A+			req->hard_c=
ur_sectors =3D (req->data_len + 511) >> 9;=0A+		}=0A 		=
end_request(req, 0);=0A 	}=0A }=0A
--=__Part77590F2C.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part77590F2C.0__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:52:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11: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.xensource.com>)
	id 1RxGvK-0001P3-PD; Tue, 14 Feb 2012 11:51:54 +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 1RxGvJ-0001Oc-Ns
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:51:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329220265!60046967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1119 invoked from network); 14 Feb 2012 11:51:05 -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 Feb 2012 11:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10683997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 11:51:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 11:51:49 +0000
Date: Tue, 14 Feb 2012 11:55:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paul Brook <paul@codesourcery.com>
In-Reply-To: <201202141052.55100.paul@codesourcery.com>
Message-ID: <alpine.DEB.2.00.1202141155320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202102334.40125.paul@codesourcery.com>
	<alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
	<201202141052.55100.paul@codesourcery.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Paul Brook wrote:
> > Yes, you are right. Also considering that we are only calling
> > slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
> > the !CONFIG_SLIRP dummy version of the function.
> 
> Looks reasonable to me.  Unfortunately I can't remember which combination of 
> headless VM and timer configs caused hangs when this was originally added.
> 
> If anyone has a setup that suffered timeout-related hangs last time we made 
> this change, please retest with this patch.  Otherwise I guess we apply the 
> patch and hope we didn't miss anything.

OK, thanks. I'll resend the patch as part of the series and ask for
testing.

> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Mon Feb 13 11:25:03 2012 +0000
> > 
> >     main_loop_wait: block indefinitely
> >     
> >     - remove qemu_calculate_timeout;
> >     
> >     - explicitly size timeout to uint32_t;
> >     
> >     - introduce slirp_update_timeout;
> >     
> >     - pass NULL as timeout argument to select in case timeout is the
> >     maximum value;
> >     
> >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Paul Brook <paul@codesourcery.com>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:52:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11: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.xensource.com>)
	id 1RxGvK-0001P3-PD; Tue, 14 Feb 2012 11:51:54 +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 1RxGvJ-0001Oc-Ns
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:51:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329220265!60046967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1119 invoked from network); 14 Feb 2012 11:51:05 -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 Feb 2012 11:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10683997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 11:51:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 11:51:49 +0000
Date: Tue, 14 Feb 2012 11:55:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paul Brook <paul@codesourcery.com>
In-Reply-To: <201202141052.55100.paul@codesourcery.com>
Message-ID: <alpine.DEB.2.00.1202141155320.7456@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202102334.40125.paul@codesourcery.com>
	<alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
	<201202141052.55100.paul@codesourcery.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
 increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Paul Brook wrote:
> > Yes, you are right. Also considering that we are only calling
> > slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
> > the !CONFIG_SLIRP dummy version of the function.
> 
> Looks reasonable to me.  Unfortunately I can't remember which combination of 
> headless VM and timer configs caused hangs when this was originally added.
> 
> If anyone has a setup that suffered timeout-related hangs last time we made 
> this change, please retest with this patch.  Otherwise I guess we apply the 
> patch and hope we didn't miss anything.

OK, thanks. I'll resend the patch as part of the series and ask for
testing.

> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date:   Mon Feb 13 11:25:03 2012 +0000
> > 
> >     main_loop_wait: block indefinitely
> >     
> >     - remove qemu_calculate_timeout;
> >     
> >     - explicitly size timeout to uint32_t;
> >     
> >     - introduce slirp_update_timeout;
> >     
> >     - pass NULL as timeout argument to select in case timeout is the
> >     maximum value;
> >     
> >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Paul Brook <paul@codesourcery.com>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:52:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11: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.xensource.com>)
	id 1RxGvH-0001Og-Cy; Tue, 14 Feb 2012 11:51:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxGvF-0001OP-WC
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:51:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329220303!13236922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8287 invoked from network); 14 Feb 2012 11:51:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 11:51:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 11:51:43 +0000
Message-Id: <4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 11:51:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur>
In-Reply-To: <6587132.0KbvunDmjW@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
>      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
>  
>      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
> +    {
> +        /* Special handling for BTS */
> +        if ( msr == MSR_IA32_DEBUGCTLMSR )
> +        {
> +            uint64_t supported = IA32_DEBUGCTLMSR_TR | IA32_DEBUGCTLMSR_BTS |
> +                                 IA32_DEBUGCTLMSR_BTINT;

Was the code to make BTINT work magically in place already? I can't
spot anything to the effect in the patch...

> +
> +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
> +            {
> +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
> +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
> +            }
> +            if ( msr_content & supported  )
> +            {
> +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
> +                {
> +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported on this cpu\n");
> +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
> +                    return 0;
> +                }
> +                return 1;
> +            }
> +        }
>          return 0;
> +    }
>  
>      core2_vpmu_cxt = vpmu->context;
>      switch ( msr )
> @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
>                       "which is not supported.\n");
>          return 1;
>      case MSR_IA32_DS_AREA:
> -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> -        return 1;
> +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
> +        {
> +            if (!msr_content || !is_canonical_address(msr_content))
> +            {
> +                gdprintk(XENLOG_WARNING, "Illegal address for IA32_DS_AREA: 0x%lx\n",
> +                                                            msr_content);
> +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
> +                return 1;
> +            }
> +            else
> +            {
> +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
> +                break;

How do you manage to get away without storing the value the guest
attempted to write?

Jan

> +            }
> +        }
> +        else
> +        {
> +            gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> +            return 1;
> +        }
>      case MSR_CORE_PERF_GLOBAL_CTRL:
>          global_ctrl = msr_content;
>          for ( i = 0; i < core2_get_pmc_count(); i++ )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 11:52:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 11: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.xensource.com>)
	id 1RxGvH-0001Og-Cy; Tue, 14 Feb 2012 11:51:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxGvF-0001OP-WC
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 11:51:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329220303!13236922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8287 invoked from network); 14 Feb 2012 11:51:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 11:51:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 11:51:43 +0000
Message-Id: <4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 11:51:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur>
In-Reply-To: <6587132.0KbvunDmjW@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
>      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
>  
>      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
> +    {
> +        /* Special handling for BTS */
> +        if ( msr == MSR_IA32_DEBUGCTLMSR )
> +        {
> +            uint64_t supported = IA32_DEBUGCTLMSR_TR | IA32_DEBUGCTLMSR_BTS |
> +                                 IA32_DEBUGCTLMSR_BTINT;

Was the code to make BTINT work magically in place already? I can't
spot anything to the effect in the patch...

> +
> +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
> +            {
> +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
> +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
> +            }
> +            if ( msr_content & supported  )
> +            {
> +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
> +                {
> +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported on this cpu\n");
> +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
> +                    return 0;
> +                }
> +                return 1;
> +            }
> +        }
>          return 0;
> +    }
>  
>      core2_vpmu_cxt = vpmu->context;
>      switch ( msr )
> @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
>                       "which is not supported.\n");
>          return 1;
>      case MSR_IA32_DS_AREA:
> -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> -        return 1;
> +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
> +        {
> +            if (!msr_content || !is_canonical_address(msr_content))
> +            {
> +                gdprintk(XENLOG_WARNING, "Illegal address for IA32_DS_AREA: 0x%lx\n",
> +                                                            msr_content);
> +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
> +                return 1;
> +            }
> +            else
> +            {
> +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
> +                break;

How do you manage to get away without storing the value the guest
attempted to write?

Jan

> +            }
> +        }
> +        else
> +        {
> +            gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> +            return 1;
> +        }
>      case MSR_CORE_PERF_GLOBAL_CTRL:
>          global_ctrl = msr_content;
>          for ( i = 0; i < core2_get_pmc_count(); i++ )



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 12:44:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 12: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.xensource.com>)
	id 1RxHkD-0002hA-GD; Tue, 14 Feb 2012 12:44:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxHkC-0002h1-25
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:44:28 +0000
Received: from [193.109.254.147:20908] by server-4.bemta-14.messagelabs.com id
	A3/AD-08205-B275A3F4; Tue, 14 Feb 2012 12:44:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329223414!52678834!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7007 invoked from network); 14 Feb 2012 12:43:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 12:43:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10685225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 12:44:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 12:44:26 +0000
Message-ID: <1329223464.31256.234.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Tue, 14 Feb 2012 12:44:24 +0000
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
	,<1328107019.17444.74.camel@zakaz.uk.xensource.com>
	<5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please do not top post.

On Tue, 2012-02-14 at 12:30 +0000, Francisco Rocha wrote:
> I have set the noreboot option for Xen and it does not reboot but the machine freezes.
> I am unable to get output. Which logs should I check?

It might be that a serial console is needed to actually see anything.
"console=vga,keep" might also help.

However I just tried your test program and got:

(XEN) Assertion '!in_atomic()' failed at softirq.c:61
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82c4801254ff>] do_softirq+0xd/0x28
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: ffff8300dffb8000   rcx: ffff82c4802d0800
(XEN) rdx: 0000003c9f1bc680   rsi: 0000000000000000   rdi: 0000000000000001
(XEN) rbp: ffff83011f4aff08   rsp: ffff83011f4aff08   r8:  00000000deadbeef
(XEN) r9:  00000000deadbeef   r10: 00000000deadbeef   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000011f45e000   cr2: 00000000de567a64
(XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83011f4aff08:
(XEN)    00007cfee0b500c7 ffff82c480220f16 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 00000000dfc75f90 00000000deadbeef
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 00000000deadbeef 00000000c10082c0 0000000000000002
(XEN)    0000000000000000 0000010000000000 00000000c10023a7 0000000000000061
(XEN)    0000000000000246 00000000dfc75f80 0000000000000069 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 0000000000000002
(XEN)    ffff8300dffb8000 0000003c9f1bc680 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82c4801254ff>] do_softirq+0xd/0x28
(XEN)    
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 2:
(XEN) Assertion '!in_atomic()' failed at softirq.c:61
(XEN) ****************************************
(XEN) 
(XEN) Manual reset required ('noreboot' specified)

I've no idea where this might be coming from though.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 12:44:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 12: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.xensource.com>)
	id 1RxHkD-0002hA-GD; Tue, 14 Feb 2012 12:44:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxHkC-0002h1-25
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:44:28 +0000
Received: from [193.109.254.147:20908] by server-4.bemta-14.messagelabs.com id
	A3/AD-08205-B275A3F4; Tue, 14 Feb 2012 12:44:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329223414!52678834!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7007 invoked from network); 14 Feb 2012 12:43:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 12:43:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10685225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 12:44:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 12:44:26 +0000
Message-ID: <1329223464.31256.234.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Tue, 14 Feb 2012 12:44:24 +0000
In-Reply-To: <5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
	,<1328107019.17444.74.camel@zakaz.uk.xensource.com>
	<5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please do not top post.

On Tue, 2012-02-14 at 12:30 +0000, Francisco Rocha wrote:
> I have set the noreboot option for Xen and it does not reboot but the machine freezes.
> I am unable to get output. Which logs should I check?

It might be that a serial console is needed to actually see anything.
"console=vga,keep" might also help.

However I just tried your test program and got:

(XEN) Assertion '!in_atomic()' failed at softirq.c:61
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82c4801254ff>] do_softirq+0xd/0x28
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: ffff8300dffb8000   rcx: ffff82c4802d0800
(XEN) rdx: 0000003c9f1bc680   rsi: 0000000000000000   rdi: 0000000000000001
(XEN) rbp: ffff83011f4aff08   rsp: ffff83011f4aff08   r8:  00000000deadbeef
(XEN) r9:  00000000deadbeef   r10: 00000000deadbeef   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000011f45e000   cr2: 00000000de567a64
(XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83011f4aff08:
(XEN)    00007cfee0b500c7 ffff82c480220f16 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 00000000dfc75f90 00000000deadbeef
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 00000000deadbeef 00000000c10082c0 0000000000000002
(XEN)    0000000000000000 0000010000000000 00000000c10023a7 0000000000000061
(XEN)    0000000000000246 00000000dfc75f80 0000000000000069 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 0000000000000002
(XEN)    ffff8300dffb8000 0000003c9f1bc680 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82c4801254ff>] do_softirq+0xd/0x28
(XEN)    
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 2:
(XEN) Assertion '!in_atomic()' failed at softirq.c:61
(XEN) ****************************************
(XEN) 
(XEN) Manual reset required ('noreboot' specified)

I've no idea where this might be coming from though.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 12:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 12:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxHsF-00031e-Fq; Tue, 14 Feb 2012 12:52:47 +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 1RxHsD-00031W-NG
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:52:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329223941!52845739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28141 invoked from network); 14 Feb 2012 12:52:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 12:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10685420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 12:52:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 12:52:44 +0000
Message-ID: <1329223963.31256.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Tue, 14 Feb 2012 12:52:43 +0000
In-Reply-To: <1329223464.31256.234.camel@zakaz.uk.xensource.com>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
	,<1328107019.17444.74.camel@zakaz.uk.xensource.com>
	<5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
	<1329223464.31256.234.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 12:44 +0000, Ian Campbell wrote:
> I've no idea where this might be coming from though.

Turns out I do... The following fixes it for me. Ought to be backported
IMHO.

Ian.


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329223776 0
# Node ID 86ebf7589758da1d026175ac46b3f9bda75f0937
# Parent  43f94d0d384b1c00b5d8fc9a90d6d48165cd854d
xen: add missing unlock from gnttab_get_version

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>

diff -r 43f94d0d384b -r 86ebf7589758 xen/common/grant_table.c
--- a/xen/common/grant_table.c	Tue Feb 14 12:40:13 2012 +0000
+++ b/xen/common/grant_table.c	Tue Feb 14 12:49:36 2012 +0000
@@ -2321,6 +2321,8 @@ gnttab_get_version(XEN_GUEST_HANDLE(gntt
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);
 
+    rcu_unlock_domain(d);
+
     if ( copy_to_guest(uop, &op, 1) )
         return -EFAULT;
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 12:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 12:53:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxHsF-00031e-Fq; Tue, 14 Feb 2012 12:52:47 +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 1RxHsD-00031W-NG
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:52:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329223941!52845739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28141 invoked from network); 14 Feb 2012 12:52:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 12:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10685420"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 12:52:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 12:52:44 +0000
Message-ID: <1329223963.31256.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
Date: Tue, 14 Feb 2012 12:52:43 +0000
In-Reply-To: <1329223464.31256.234.camel@zakaz.uk.xensource.com>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
	,<1328107019.17444.74.camel@zakaz.uk.xensource.com>
	<5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
	<1329223464.31256.234.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 12:44 +0000, Ian Campbell wrote:
> I've no idea where this might be coming from though.

Turns out I do... The following fixes it for me. Ought to be backported
IMHO.

Ian.


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329223776 0
# Node ID 86ebf7589758da1d026175ac46b3f9bda75f0937
# Parent  43f94d0d384b1c00b5d8fc9a90d6d48165cd854d
xen: add missing unlock from gnttab_get_version

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>

diff -r 43f94d0d384b -r 86ebf7589758 xen/common/grant_table.c
--- a/xen/common/grant_table.c	Tue Feb 14 12:40:13 2012 +0000
+++ b/xen/common/grant_table.c	Tue Feb 14 12:49:36 2012 +0000
@@ -2321,6 +2321,8 @@ gnttab_get_version(XEN_GUEST_HANDLE(gntt
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);
 
+    rcu_unlock_domain(d);
+
     if ( copy_to_guest(uop, &op, 1) )
         return -EFAULT;
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:00:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxHzD-0003DI-Eq; Tue, 14 Feb 2012 12:59:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RxHzC-0003DC-8t
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:59:58 +0000
Received: from [85.158.139.83:44127] by server-11.bemta-5.messagelabs.com id
	2E/AF-14397-DCA5A3F4; Tue, 14 Feb 2012 12:59:57 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329224395!14379334!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIwNjUxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16028 invoked from network); 14 Feb 2012 12:59:55 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 12:59:55 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=cJJyXSsiCL44kWRy7en38JSstMzWHWMs6D9D4+PnO2xe1FMqh8uQehPQ
	m8IVX/6iPXCP5JBeUI0LpF2SMOePH8P+9b9qC7RkTnTafX8uQrW3IFSKX
	ZrbbapDgW5WNho896Ed+uZsyqPXFtg2WezQqexzRhoYf5RP6BGLWAtY5d
	+KHg0noxQX+IAV9WvLu1eoHVUZcTfmnOSa6/Nuknbd3G6IcEtErP7Kp8r
	kt9KsJtub+wQvncU5zmJkEUSaOYUo;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329224396; x=1360760396;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=rp8I6tNTYbJN8kbfYN238RmXZO4C9wIJgJcVqzPAgCw=;
	b=kbyYyk3fWkTCNnpEy/DKVIJUVBcsEAMlfHCLcCnylNz2m37UPx4e0XDh
	t8V4D6qqUSgp4wRdzIS5eZZ481diW1ycDFFbxejCQLvt6zMQGJzD4rPZA
	HY/amFLkQ1N+5NXCyV1pkkzSipMCw08f3FjnxfshgCwesxQKtKupZTi7n
	gOd5PxUF8/U/61lwUxZxjsBnNxeMMuDgAcTdA85WEID5jiPdxjFzb2CUh
	sqcszfvQAZwG+T6Avg0arsIbmw8X7;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="101908502"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 14 Feb 2012 13:59:55 +0100
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="129218838"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 14 Feb 2012 13:59:55 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 130B076B516;
	Tue, 14 Feb 2012 13:59:55 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 13:59:54 +0100
Message-ID: <1805920.cM9rJVskbD@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
References: <6587132.0KbvunDmjW@amur>
	<4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag 14 Februar 2012, 11:51:39 schrieb Jan Beulich:
> >>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
> >  
> >      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
> > +    {
> > +        /* Special handling for BTS */
> > +        if ( msr == MSR_IA32_DEBUGCTLMSR )
> > +        {
> > +            uint64_t supported = IA32_DEBUGCTLMSR_TR | IA32_DEBUGCTLMSR_BTS |
> > +                                 IA32_DEBUGCTLMSR_BTINT;
> 
> Was the code to make BTINT work magically in place already? I can't
> spot anything to the effect in the patch...

No, BTINT wasn't handled before.
The writing of the MSR's is done in the calling function
vmx_msr_write_intercept() in xen/arch/x86/hvm/vmx/vmx.c.
There I added the call of vpmu_do_wrmsr() in the case of MSR_IA32_DEBUGCTLMSR.
If vpmu_do_wrmsr() returns 1 the MSR gets written in the line
   __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);

Maybe I can change this and write the MSR here in this function.

> 
> > +
> > +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
> > +            {
> > +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
> > +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
> > +            }
> > +            if ( msr_content & supported  )
> > +            {
> > +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
> > +                {
> > +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported on this cpu\n");
> > +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
> > +                    return 0;
> > +                }
> > +                return 1;
> > +            }
> > +        }
> >          return 0;
> > +    }
> >  
> >      core2_vpmu_cxt = vpmu->context;
> >      switch ( msr )
> > @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >                       "which is not supported.\n");
> >          return 1;
> >      case MSR_IA32_DS_AREA:
> > -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> > -        return 1;
> > +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
> > +        {
> > +            if (!msr_content || !is_canonical_address(msr_content))
> > +            {
> > +                gdprintk(XENLOG_WARNING, "Illegal address for IA32_DS_AREA: 0x%lx\n",
> > +                                                            msr_content);
> > +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
> > +                return 1;
> > +            }
> > +            else
> > +            {
> > +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
> > +                break;
> 
> How do you manage to get away without storing the value the guest
> attempted to write?

In the case of MSR_IA32_DS_AREA the value is stored some lines later
core2_vpmu_save_msr_context(v, type, index, msr_content);
in an internal data structure.
The values of this structure are loaded - core2_vpmu_load() - and stored
- core2_vpmu_save() - on context switch.

Thanks.
Dietmar.

> 
> Jan
> 
> > +            }
> > +        }
> > +        else
> > +        {
> > +            gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> > +            return 1;
> > +        }
> >      case MSR_CORE_PERF_GLOBAL_CTRL:
> >          global_ctrl = msr_content;
> >          for ( i = 0; i < core2_get_pmc_count(); i++ )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:00:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxHzD-0003DI-Eq; Tue, 14 Feb 2012 12:59:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RxHzC-0003DC-8t
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:59:58 +0000
Received: from [85.158.139.83:44127] by server-11.bemta-5.messagelabs.com id
	2E/AF-14397-DCA5A3F4; Tue, 14 Feb 2012 12:59:57 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329224395!14379334!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIwNjUxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16028 invoked from network); 14 Feb 2012 12:59:55 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 12:59:55 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=cJJyXSsiCL44kWRy7en38JSstMzWHWMs6D9D4+PnO2xe1FMqh8uQehPQ
	m8IVX/6iPXCP5JBeUI0LpF2SMOePH8P+9b9qC7RkTnTafX8uQrW3IFSKX
	ZrbbapDgW5WNho896Ed+uZsyqPXFtg2WezQqexzRhoYf5RP6BGLWAtY5d
	+KHg0noxQX+IAV9WvLu1eoHVUZcTfmnOSa6/Nuknbd3G6IcEtErP7Kp8r
	kt9KsJtub+wQvncU5zmJkEUSaOYUo;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329224396; x=1360760396;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=rp8I6tNTYbJN8kbfYN238RmXZO4C9wIJgJcVqzPAgCw=;
	b=kbyYyk3fWkTCNnpEy/DKVIJUVBcsEAMlfHCLcCnylNz2m37UPx4e0XDh
	t8V4D6qqUSgp4wRdzIS5eZZ481diW1ycDFFbxejCQLvt6zMQGJzD4rPZA
	HY/amFLkQ1N+5NXCyV1pkkzSipMCw08f3FjnxfshgCwesxQKtKupZTi7n
	gOd5PxUF8/U/61lwUxZxjsBnNxeMMuDgAcTdA85WEID5jiPdxjFzb2CUh
	sqcszfvQAZwG+T6Avg0arsIbmw8X7;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="101908502"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 14 Feb 2012 13:59:55 +0100
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="129218838"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 14 Feb 2012 13:59:55 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 130B076B516;
	Tue, 14 Feb 2012 13:59:55 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 13:59:54 +0100
Message-ID: <1805920.cM9rJVskbD@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
References: <6587132.0KbvunDmjW@amur>
	<4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag 14 Februar 2012, 11:51:39 schrieb Jan Beulich:
> >>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
> >  
> >      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
> > +    {
> > +        /* Special handling for BTS */
> > +        if ( msr == MSR_IA32_DEBUGCTLMSR )
> > +        {
> > +            uint64_t supported = IA32_DEBUGCTLMSR_TR | IA32_DEBUGCTLMSR_BTS |
> > +                                 IA32_DEBUGCTLMSR_BTINT;
> 
> Was the code to make BTINT work magically in place already? I can't
> spot anything to the effect in the patch...

No, BTINT wasn't handled before.
The writing of the MSR's is done in the calling function
vmx_msr_write_intercept() in xen/arch/x86/hvm/vmx/vmx.c.
There I added the call of vpmu_do_wrmsr() in the case of MSR_IA32_DEBUGCTLMSR.
If vpmu_do_wrmsr() returns 1 the MSR gets written in the line
   __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);

Maybe I can change this and write the MSR here in this function.

> 
> > +
> > +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
> > +            {
> > +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
> > +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
> > +            }
> > +            if ( msr_content & supported  )
> > +            {
> > +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
> > +                {
> > +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported on this cpu\n");
> > +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
> > +                    return 0;
> > +                }
> > +                return 1;
> > +            }
> > +        }
> >          return 0;
> > +    }
> >  
> >      core2_vpmu_cxt = vpmu->context;
> >      switch ( msr )
> > @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >                       "which is not supported.\n");
> >          return 1;
> >      case MSR_IA32_DS_AREA:
> > -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> > -        return 1;
> > +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
> > +        {
> > +            if (!msr_content || !is_canonical_address(msr_content))
> > +            {
> > +                gdprintk(XENLOG_WARNING, "Illegal address for IA32_DS_AREA: 0x%lx\n",
> > +                                                            msr_content);
> > +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
> > +                return 1;
> > +            }
> > +            else
> > +            {
> > +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 0;
> > +                break;
> 
> How do you manage to get away without storing the value the guest
> attempted to write?

In the case of MSR_IA32_DS_AREA the value is stored some lines later
core2_vpmu_save_msr_context(v, type, index, msr_content);
in an internal data structure.
The values of this structure are loaded - core2_vpmu_load() - and stored
- core2_vpmu_save() - on context switch.

Thanks.
Dietmar.

> 
> Jan
> 
> > +            }
> > +        }
> > +        else
> > +        {
> > +            gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> > +            return 1;
> > +        }
> >      case MSR_CORE_PERF_GLOBAL_CTRL:
> >          global_ctrl = msr_content;
> >          for ( i = 0; i < core2_get_pmc_count(); i++ )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:04:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13: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.xensource.com>)
	id 1RxI2o-0003Lv-5u; Tue, 14 Feb 2012 13:03:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxI2m-0003Le-LG; Tue, 14 Feb 2012 13:03:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329224603!11326778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9967 invoked from network); 14 Feb 2012 13:03:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:03:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325480400"; d="scan'208";a="181669260"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 08:03:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 08:03:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ED3KMP028059;
	Tue, 14 Feb 2012 05:03:21 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 13:07:44 +0000
Message-ID: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-arm@lists.xensource.com, stefano.stabellini@eu.citrix.com,
	smithjenny183@gmail.com
Subject: [Xen-devel] [PATCH] arm: support fewer LRs register than virtual
	irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   46 +++++++++++++++++++++++++++++++++++++----
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..97c223c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,35 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+
+    spin_lock(&gic.lock);
+    for (i = 0; i < nr_lrs; i++) {
+        if (!test_and_set_bit(i, &gic.lr_mask))
+        {
+            gic_set_lr(i, virtual_irq, state, priority);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+    list_add_tail(&irq_to_pending(current, virtual_irq)->lr_link, &gic.lr_pending);
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -435,13 +459,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
+    for ( i = 0; i < nr_lrs; i++ ) {
         if ( eisr & ((uint64_t)1 << i) ) {
             struct pending_irq *p;
 
+            spin_lock(&gic.lock);
             lr = GICH[GICH_LR + i];
             virq = lr & GICH_LR_VIRTUAL_MASK;
             GICH[GICH_LR + i] = 0;
+            clear_bit(i, &gic.lr_mask);
+
+            if ( !list_empty(gic.lr_pending.next) ) {
+                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+                list_del(&p->lr_link);
+                INIT_LIST_HEAD(&p->lr_link);
+                set_bit(i, &gic.lr_mask);
+            } else {
+                gic_inject_irq_stop();
+            }
+            spin_unlock(&gic.lock);
 
             spin_lock(&current->arch.vgic.lock);
             p = irq_to_pending(current, virq);
@@ -449,7 +486,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            gic_inject_irq_stop();
             list_del(&p->link);
             INIT_LIST_HEAD(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:04:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13: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.xensource.com>)
	id 1RxI2o-0003Lv-5u; Tue, 14 Feb 2012 13:03:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxI2m-0003Le-LG; Tue, 14 Feb 2012 13:03:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329224603!11326778!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9967 invoked from network); 14 Feb 2012 13:03:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:03:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325480400"; d="scan'208";a="181669260"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 08:03:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 08:03:22 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1ED3KMP028059;
	Tue, 14 Feb 2012 05:03:21 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 13:07:44 +0000
Message-ID: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-arm@lists.xensource.com, stefano.stabellini@eu.citrix.com,
	smithjenny183@gmail.com
Subject: [Xen-devel] [PATCH] arm: support fewer LRs register than virtual
	irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   46 +++++++++++++++++++++++++++++++++++++----
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..97c223c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,35 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+
+    spin_lock(&gic.lock);
+    for (i = 0; i < nr_lrs; i++) {
+        if (!test_and_set_bit(i, &gic.lr_mask))
+        {
+            gic_set_lr(i, virtual_irq, state, priority);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+    list_add_tail(&irq_to_pending(current, virtual_irq)->lr_link, &gic.lr_pending);
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -435,13 +459,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
+    for ( i = 0; i < nr_lrs; i++ ) {
         if ( eisr & ((uint64_t)1 << i) ) {
             struct pending_irq *p;
 
+            spin_lock(&gic.lock);
             lr = GICH[GICH_LR + i];
             virq = lr & GICH_LR_VIRTUAL_MASK;
             GICH[GICH_LR + i] = 0;
+            clear_bit(i, &gic.lr_mask);
+
+            if ( !list_empty(gic.lr_pending.next) ) {
+                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+                list_del(&p->lr_link);
+                INIT_LIST_HEAD(&p->lr_link);
+                set_bit(i, &gic.lr_mask);
+            } else {
+                gic_inject_irq_stop();
+            }
+            spin_unlock(&gic.lock);
 
             spin_lock(&current->arch.vgic.lock);
             p = irq_to_pending(current, virq);
@@ -449,7 +486,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            gic_inject_irq_stop();
             list_del(&p->link);
             INIT_LIST_HEAD(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIAK-0003cg-C7; Tue, 14 Feb 2012 13:11:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RxIAI-0003cT-SE; Tue, 14 Feb 2012 13:11:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329225073!5912048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13360 invoked from network); 14 Feb 2012 13:11:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:11:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10685883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 13:11:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 13:11:13 +0000
Message-ID: <1329225071.31256.241.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 14 Feb 2012 13:11:11 +0000
In-Reply-To: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 13:07 +0000, Stefano Stabellini wrote:
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.
> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.

There's no need to order the IRQs by priority and ensure that the
highest priorities are in the LRs?

Ian.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   46 +++++++++++++++++++++++++++++++++++++----
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..97c223c 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;
> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,35 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +
> +    spin_lock(&gic.lock);
> +    for (i = 0; i < nr_lrs; i++) {
> +        if (!test_and_set_bit(i, &gic.lr_mask))
> +        {
> +            gic_set_lr(i, virtual_irq, state, priority);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }
> +    list_add_tail(&irq_to_pending(current, virtual_irq)->lr_link, &gic.lr_pending);
> +    spin_unlock(&gic.lock);
> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -435,13 +459,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> +    for ( i = 0; i < nr_lrs; i++ ) {
>          if ( eisr & ((uint64_t)1 << i) ) {
>              struct pending_irq *p;
>  
> +            spin_lock(&gic.lock);
>              lr = GICH[GICH_LR + i];
>              virq = lr & GICH_LR_VIRTUAL_MASK;
>              GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +
> +            if ( !list_empty(gic.lr_pending.next) ) {
> +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +                list_del(&p->lr_link);
> +                INIT_LIST_HEAD(&p->lr_link);
> +                set_bit(i, &gic.lr_mask);
> +            } else {
> +                gic_inject_irq_stop();
> +            }
> +            spin_unlock(&gic.lock);
>  
>              spin_lock(&current->arch.vgic.lock);
>              p = irq_to_pending(current, virq);
> @@ -449,7 +486,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            gic_inject_irq_stop();
>              list_del(&p->link);
>              INIT_LIST_HEAD(&p->link);
>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;
>  };
>  
>  struct arch_domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:11:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:11:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIAK-0003cg-C7; Tue, 14 Feb 2012 13:11:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RxIAI-0003cT-SE; Tue, 14 Feb 2012 13:11:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329225073!5912048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13360 invoked from network); 14 Feb 2012 13:11:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:11:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10685883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 13:11:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 13:11:13 +0000
Message-ID: <1329225071.31256.241.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 14 Feb 2012 13:11:11 +0000
In-Reply-To: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 13:07 +0000, Stefano Stabellini wrote:
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.
> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.

There's no need to order the IRQs by priority and ensure that the
highest priorities are in the LRs?

Ian.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   46 +++++++++++++++++++++++++++++++++++++----
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..97c223c 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;
> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,35 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +
> +    spin_lock(&gic.lock);
> +    for (i = 0; i < nr_lrs; i++) {
> +        if (!test_and_set_bit(i, &gic.lr_mask))
> +        {
> +            gic_set_lr(i, virtual_irq, state, priority);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }
> +    list_add_tail(&irq_to_pending(current, virtual_irq)->lr_link, &gic.lr_pending);
> +    spin_unlock(&gic.lock);
> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -435,13 +459,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> +    for ( i = 0; i < nr_lrs; i++ ) {
>          if ( eisr & ((uint64_t)1 << i) ) {
>              struct pending_irq *p;
>  
> +            spin_lock(&gic.lock);
>              lr = GICH[GICH_LR + i];
>              virq = lr & GICH_LR_VIRTUAL_MASK;
>              GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +
> +            if ( !list_empty(gic.lr_pending.next) ) {
> +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +                list_del(&p->lr_link);
> +                INIT_LIST_HEAD(&p->lr_link);
> +                set_bit(i, &gic.lr_mask);
> +            } else {
> +                gic_inject_irq_stop();
> +            }
> +            spin_unlock(&gic.lock);
>  
>              spin_lock(&current->arch.vgic.lock);
>              p = irq_to_pending(current, virq);
> @@ -449,7 +486,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            gic_inject_irq_stop();
>              list_del(&p->link);
>              INIT_LIST_HEAD(&p->link);
>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;
>  };
>  
>  struct arch_domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13: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.xensource.com>)
	id 1RxICF-0003kR-Vu; Tue, 14 Feb 2012 13:13:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxICE-0003kJ-3x
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:13:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329225152!52673360!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7742 invoked from network); 14 Feb 2012 13:12:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:12:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 13:13:24 +0000
Message-Id: <4F3A6C010200007800072E67@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 13:13:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: QEMU-devel <qemu-devel@nongnu.org>, Jiang Yunhong <yunhong.jiang@intel.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V6 10/11] Introduce Xen PCI Passthrough,
 MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 13:20, Anthony PERARD <anthony.perard@citrix.com> wrote:
> From: Jiang Yunhong <yunhong.jiang@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git

This needs to be updated to include the changes in
http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=bb36d632e4cabf47882adff07a45c6702c4a5b30
(and hopefully the broken function that got fixed in
http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=8cc8a3651c9c5bc2d0086d12f4b870fc525b9387
didn't even make it into this patch set). In particular it must be avoided
to map the MSI-X table with PROT_WRITE, and the respective MMIO
range should not get assigned to the guest at all.

Jan

> Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target                      |    1 +
>  hw/apic-msidef.h                     |    2 +
>  hw/xen_pci_passthrough.c             |   32 ++
>  hw/xen_pci_passthrough.h             |   48 +++
>  hw/xen_pci_passthrough_config_init.c |  480 ++++++++++++++++++++++++
>  hw/xen_pci_passthrough_msi.c         |  667 
> ++++++++++++++++++++++++++++++++++
>  6 files changed, 1230 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xen_pci_passthrough_msi.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index 8fc2ca3..3517cab 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -220,6 +220,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
> index 3182f0b..6e2eb71 100644
> --- a/hw/apic-msidef.h
> +++ b/hw/apic-msidef.h
> @@ -22,6 +22,8 @@
>  
>  #define MSI_ADDR_DEST_MODE_SHIFT        2
>  
> +#define MSI_ADDR_REDIRECTION_SHIFT      3
> +
>  #define MSI_ADDR_DEST_ID_SHIFT          12
>  #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
>  
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index bdc3690..1257ce2 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -36,6 +36,20 @@
>   *
>   *     Write '1'
>   *       - Set real bit to '1'.
> + *
> + * MSI interrupt:
> + *   Initialize MSI register(pt_msi_setup, pt_msi_update)
> + *     Bind MSI(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI.
> + *         - Set dev->msi->pirq to '-1'.
> + *
> + * MSI-X interrupt:
> + *   Initialize MSI-X register(pt_msix_update_one)
> + *     Bind MSI-X(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI-X.
> + *         - Set entry->pirq to '-1'.
>   */
>  
>  #include <sys/ioctl.h>
> @@ -362,6 +376,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>      }
>  
>      if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        pt_add_msix_mapping(s, i);
>          /* Remove old mapping */
>          rc = xc_domain_memory_mapping(xen_xc, xen_domid,
>                                 old_ebase >> XC_PAGE_SHIFT,
> @@ -386,6 +401,16 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>          if (rc) {
>              PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
>          }
> +
> +        rc = pt_remove_msix_mapping(s, i);
> +        if (rc != 0) {
> +            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
> +                   rc);
> +        }
> +
> +        if (old_ebase != e_phys && old_ebase != -1) {
> +            pt_msix_update_remap(s, i);
> +        }
>      }
>  }
>  
> @@ -766,6 +791,13 @@ static int pt_unregister_device(PCIDevice *d)
>          }
>      }
>  
> +    if (s->msi) {
> +        pt_msi_disable(s);
> +    }
> +    if (s->msix) {
> +        pt_msix_disable(s);
> +    }
> +
>      if (machine_irq) {
>          mapped_machine_irq[machine_irq]--;
>  
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index 0b9902d..deeba89 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -174,6 +174,37 @@ typedef struct XenPTRegGroup {
>  
>  
>  #define PT_UNASSIGNED_PIRQ (-1)
> +typedef struct XenPTMSI {
> +    uint16_t flags;
> +    uint32_t addr_lo;  /* guest message address */
> +    uint32_t addr_hi;  /* guest message upper address */
> +    uint16_t data;     /* guest message data */
> +    uint32_t ctrl_offset; /* saved control offset */
> +    int pirq;          /* guest pirq corresponding */
> +    bool initialized;  /* when guest MSI is initialized */
> +    bool mapped;       /* when pirq is mapped */
> +} XenPTMSI;
> +
> +typedef struct XenPTMSIXEntry {
> +    int pirq;
> +    uint64_t addr;
> +    uint32_t data;
> +    uint32_t vector_ctrl;
> +    bool updated; /* indicate whether MSI ADDR or DATA is updated */
> +} XenPTMSIXEntry;
> +typedef struct XenPTMSIX {
> +    uint32_t ctrl_offset;
> +    bool enabled;
> +    int total_entries;
> +    int bar_index;
> +    uint64_t table_base;
> +    uint32_t table_off;
> +    uint32_t table_offset_adjust; /* page align mmap */
> +    uint64_t mmio_base_addr;
> +    MemoryRegion mmio;
> +    void *phys_iomem_base;
> +    XenPTMSIXEntry msix_entry[0];
> +} XenPTMSIX;
>  
>  struct XenPCIPassthroughState {
>      PCIDevice dev;
> @@ -186,6 +217,9 @@ struct XenPCIPassthroughState {
>  
>      uint32_t machine_irq;
>  
> +    XenPTMSI *msi;
> +    XenPTMSIX *msix;
> +
>      MemoryRegion bar[PCI_NUM_REGIONS - 1];
>      MemoryRegion rom;
>  };
> @@ -262,4 +296,18 @@ static inline uint8_t pci_intx(XenPCIPassthroughState 
> *s)
>      return r_val;
>  }
>  
> +/* MSI/MSI-X */
> +int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
> +int pt_msi_setup(XenPCIPassthroughState *s);
> +int pt_msi_update(XenPCIPassthroughState *d);
> +void pt_msi_disable(XenPCIPassthroughState *s);
> +
> +int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
> +void pt_msix_delete(XenPCIPassthroughState *s);
> +int pt_msix_update(XenPCIPassthroughState *s);
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
> +void pt_msix_disable(XenPCIPassthroughState *s);
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +
>  #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_config_init.c 
> b/hw/xen_pci_passthrough_config_init.c
> index 2fb27ff..430c26a 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1125,6 +1125,419 @@ static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
>  };
>  
>  
> +/********************************
> + * MSI Capability
> + */
> +
> +/* Helper */
> +static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
> +{
> +    /* check the offset whether matches the type or not */
> +    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & 
> PCI_MSI_FLAGS_64BIT);
> +    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & 
> PCI_MSI_FLAGS_64BIT);
> +    return is_32 || is_64;
> +}
> +
> +/* Message Control register */
> +static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTMSI *msi = s->msi;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);
> +
> +    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
> +        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
> +    }
> +    msi->flags |= reg_field;
> +    msi->ctrl_offset = real_offset;
> +    msi->initialized = false;
> +    msi->mapped = false;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg 
> *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTMSI *msi = s->msi;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t val;
> +
> +    /* Currently no support for multi-vector */
> +    if (*value & PCI_MSI_FLAGS_QSIZE) {
> +        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
> +
> +    /* create value for writing to I/O device register */
> +    val = *value;
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (val & PCI_MSI_FLAGS_ENABLE) {
> +        /* setup MSI pirq for the first time */
> +        if (!msi->initialized) {
> +            /* Init physical one */
> +            PT_LOG(&s->dev, "setup MSI\n");
> +            if (pt_msi_setup(s)) {
> +                /* We do not broadcast the error to the framework code, so
> +                 * that MSI errors are contained in MSI emulation code and
> +                 * QEMU can go on running.
> +                 * Guest MSI would be actually not working.
> +                 */
> +                *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                PT_WARN(&s->dev, "Can not map MSI.\n");
> +                return 0;
> +            }
> +            if (pt_msi_update(s)) {
> +                *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                PT_WARN(&s->dev, "Can not bind MSI\n");
> +                return 0;
> +            }
> +            msi->initialized = true;
> +            msi->mapped = true;
> +        }
> +        msi->flags |= PCI_MSI_FLAGS_ENABLE;
> +    } else {
> +        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
> +    }
> +
> +    /* pass through MSI_ENABLE bit */
> +    *value &= ~PCI_MSI_FLAGS_ENABLE;
> +    *value |= val & PCI_MSI_FLAGS_ENABLE;
> +
> +    return 0;
> +}
> +
> +/* initialize Message Upper Address register */
> +static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    /* no need to initialize in case of 32 bit type */
> +    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        *data = PT_INVALID_REG;
> +    } else {
> +        *data = reg->init_val;
> +    }
> +
> +    return 0;
> +}
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* initialize Message Data register */
> +static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    uint32_t flags = s->msi->flags;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (pt_msgdata_check_type(offset, flags)) {
> +        *data = reg->init_val;
> +    } else {
> +        *data = PT_INVALID_REG;
> +    }
> +    return 0;
> +}
> +
> +/* write Message Address register */
> +static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    s->msi->addr_lo = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->mapped) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +/* write Message Upper Address register */
> +static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* check whether the type is 64 bit or not */
> +    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        PT_ERR(&s->dev,
> +               "Can't write to the upper address without 64 bit 
> support\n");
> +        return -1;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->addr_hi = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->mapped) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* write Message Data register */
> +static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg 
> *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTMSI *msi = s->msi;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t old_data = cfg_entry->data;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (!pt_msgdata_check_type(offset, msi->flags)) {
> +        /* exit I/O emulator */
> +        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
> +        return -1;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    msi->data = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_data) {
> +        if (msi->mapped) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* MSI Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFF8E,
> +        .emu_mask   = 0x007F,
> +        .init       = pt_msgctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Address reg */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_LO,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000003,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr32_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_HI,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000000,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgaddr64_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr64_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 32-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_32,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 64-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_64,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * MSI-X Capability
> + */
> +
> +/* Message Control register for MSI-X */
> +static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);
> +
> +    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
> +        PT_LOG(d, "MSIX already enabled, disabling it first\n");
> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
> +    }
> +
> +    s->msix->ctrl_offset = real_offset;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
> +                                 XenPTReg *cfg_entry, uint16_t *value,
> +                                 uint16_t dev_value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    int debug_msix_enabled_old;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI-X */
> +    if ((*value & PCI_MSIX_FLAGS_ENABLE)
> +        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
> +        pt_msix_update(s);
> +    }
> +
> +    debug_msix_enabled_old = s->msix->enabled;
> +    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
> +    if (s->msix->enabled != debug_msix_enabled_old) {
> +        PT_LOG(&s->dev, "%s MSI-X\n",
> +               s->msix->enabled ? "enable" : "disable");
> +    }
> +
> +    return 0;
> +}
> +
> +/* MSI-X Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x3FFF,
> +        .emu_mask   = 0x0000,
> +        .init       = pt_msixctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msixctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
>  /****************************
>   * Capabilities
>   */
> @@ -1218,6 +1631,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState 
> *s,
>      *size = pcie_size;
>      return 0;
>  }
> +/* get MSI Capability Structure register group size */
> +static int pt_msi_size_init(XenPCIPassthroughState *s,
> +                            const XenPTRegGroupInfo *grp_reg,
> +                            uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t msg_ctrl = 0;
> +    uint8_t msi_size = 0xa;
> +
> +    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
> +
> +    /* check if 64-bit address is capable of per-vector masking */
> +    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
> +        msi_size += 4;
> +    }
> +    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
> +        msi_size += 10;
> +    }
> +
> +    s->msi = g_new0(XenPTMSI, 1);
> +    s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +
> +    *size = msi_size;
> +    return 0;
> +}
> +/* get MSI-X Capability Structure register group size */
> +static int pt_msix_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    int rc = 0;
> +
> +    rc = pt_msix_init(s, base_offset);
> +
> +    if (rc < 0) {
> +        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
> +        return rc;
> +    }
> +
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +
>  
>  static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>      /* Header Type0 reg group */
> @@ -1250,6 +1706,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = 
> {
>          .grp_size   = 0x04,
>          .size_init  = pt_reg_grp_size_init,
>      },
> +    /* MSI Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSI,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_msi_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msi_tbl,
> +    },
>      /* PCI-X Capabilities List Item reg group */
>      {
>          .grp_id     = PCI_CAP_ID_PCIX,
> @@ -1294,6 +1758,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = 
> {
>          .size_init   = pt_pcie_size_init,
>          .emu_reg_tbl = pt_emu_reg_pcie_tbl,
>      },
> +    /* MSI-X Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSIX,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x0C,
> +        .size_init   = pt_msix_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msix_tbl,
> +    },
>      {
>          .grp_size = 0,
>      },
> @@ -1478,6 +1950,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
>      struct XenPTRegGroup *reg_group, *next_grp;
>      struct XenPTReg *reg, *next_reg;
>  
> +    /* free MSI/MSI-X info table */
> +    if (s->msix) {
> +        pt_msix_delete(s);
> +    }
> +    if (s->msi) {
> +        g_free(s->msi);
> +    }
> +
>      /* free all register group entry */
>      QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
>          /* free all register entry */
> diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
> new file mode 100644
> index 0000000..0b81060
> --- /dev/null
> +++ b/hw/xen_pci_passthrough_msi.c
> @@ -0,0 +1,667 @@
> +/*
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Jiang Yunhong <yunhong.jiang@intel.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include <sys/mman.h>
> +
> +#include "xen_backend.h"
> +#include "xen_pci_passthrough.h"
> +#include "apic-msidef.h"
> +
> +
> +#define AUTO_ASSIGN -1
> +
> +/* shift count for gflags */
> +#define GFLAGS_SHIFT_DEST_ID        0
> +#define GFLAGS_SHIFT_RH             8
> +#define GFLAGS_SHIFT_DM             9
> +#define GLFAGS_SHIFT_DELIV_MODE     12
> +#define GLFAGS_SHIFT_TRG_MODE       15
> +
> +
> +/*
> + * Helpers
> + */
> +
> +static inline uint8_t msi_vector(uint32_t data)
> +{
> +    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
> +}
> +
> +static inline uint8_t msi_dest_id(uint32_t addr)
> +{
> +    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
> +}
> +
> +static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
> +{
> +    return addr_hi & 0xffffff00;
> +}
> +
> +static uint32_t msi_gflags(uint32_t data, uint64_t addr)
> +{
> +    uint32_t result = 0;
> +    int rh, dm, dest_id, deliv_mode, trig_mode;
> +
> +    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
> +    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
> +    dest_id = msi_dest_id(addr);
> +    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
> +    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> +
> +    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
> +        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
> +        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
> +
> +    return result;
> +}
> +
> +static inline uint64_t msi_addr64(XenPTMSI *msi)
> +{
> +    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
> +}
> +
> +static int msi_msix_enable(XenPCIPassthroughState *s,
> +                           uint32_t address,
> +                           uint16_t flag,
> +                           bool enable)
> +{
> +    uint16_t val = 0;
> +
> +    if (!address) {
> +        return -1;
> +    }
> +
> +    host_pci_get_word(s->real_device, address, &val);
> +    if (enable) {
> +        val |= flag;
> +    } else {
> +        val &= ~flag;
> +    }
> +    host_pci_set_word(s->real_device, address, val);
> +    return 0;
> +}
> +
> +static int msi_msix_setup(XenPCIPassthroughState *s,
> +                           uint64_t addr,
> +                           uint32_t data,
> +                           int *ppirq,
> +                           bool is_msix,
> +                           int msix_entry,
> +                           bool is_not_mapped)
> +{
> +    uint8_t gvec = msi_vector(data);
> +    int rc = 0;
> +
> +    assert((!is_msix && msix_entry == 0) || is_msix);
> +
> +    if (gvec == 0) {
> +        /* if gvec is 0, the guest is asking for a particular pirq that
> +         * is passed as dest_id */
> +        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
> +        if (!*ppirq) {
> +            /* this probably identifies an misconfiguration of the guest,
> +             * try the emulated path */
> +            *ppirq = PT_UNASSIGNED_PIRQ;
> +        } else {
> +            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
> +                   " (vec: %#x, entry: %#x)\n",
> +                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
> +        }
> +    }
> +
> +    if (is_not_mapped) {
> +        uint64_t table_base = 0;
> +
> +        if (is_msix) {
> +            table_base = s->msix->table_base;
> +        }
> +
> +        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
> +                                     PCI_DEVFN(s->real_device->dev,
> +                                               s->real_device->func),
> +                                     s->real_device->bus,
> +                                     msix_entry, table_base);
> +        if (rc) {
> +            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry 
> %#x)\n",
> +                   is_msix ? "-X" : "", rc, gvec, msix_entry);
> +            return rc;
> +        }
> +    }
> +
> +    return 0;
> +}
> +static int msi_msix_update(XenPCIPassthroughState *s,
> +                           uint64_t addr,
> +                           uint32_t data,
> +                           int pirq,
> +                           bool is_msix,
> +                           int msix_entry,
> +                           int *old_pirq)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = msi_vector(data);
> +    uint32_t gflags = msi_gflags(data, addr);
> +    int rc = 0;
> +    uint64_t table_addr = 0;
> +
> +    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: 
> %#x)\n",
> +           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
> +
> +    if (is_msix) {
> +        table_addr = s->msix->mmio_base_addr;
> +    }
> +
> +    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
> +                                  pirq, gflags, table_addr);
> +
> +    if (rc) {
> +        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
> +               is_msix ? "-X" : "", rc);
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
> +            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
> +                   is_msix ? "-X" : "", *old_pirq);
> +        }
> +        *old_pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +    return rc;
> +}
> +
> +static int msi_msix_disable(XenPCIPassthroughState *s,
> +                            uint64_t addr,
> +                            uint32_t data,
> +                            int pirq,
> +                            bool is_msix,
> +                            bool is_binded)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = msi_vector(data);
> +    uint32_t gflags = msi_gflags(data, addr);
> +    int rc = 0;
> +
> +    if (pirq == PT_UNASSIGNED_PIRQ) {
> +        return 0;
> +    }
> +
> +    if (is_binded) {
> +        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
> +               is_msix ? "-X" : "", pirq, gvec);
> +        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, 
> gflags);
> +        if (rc) {
> +            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
> +                   is_msix ? "-X" : "", pirq, gvec);
> +            return rc;
> +        }
> +    }
> +
> +    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
> +    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
> +    if (rc) {
> +        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
> +               is_msix ? "-X" : "", pirq, rc);
> +        return rc;
> +    }
> +
> +    return 0;
> +}
> +
> +/*
> + * MSI virtualization functions
> + */
> +
> +int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
> +{
> +    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
> +
> +    if (!s->msi) {
> +        return -1;
> +    }
> +
> +    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
> +                           enable);
> +}
> +
> +/* setup physical msi, but don't enable it */
> +int pt_msi_setup(XenPCIPassthroughState *s)
> +{
> +    int pirq = PT_UNASSIGNED_PIRQ;
> +    int rc = 0;
> +    XenPTMSI *msi = s->msi;
> +
> +    if (msi->initialized) {
> +        PT_ERR(&s->dev,
> +               "Setup physical MSI when it has been properly 
> initialized.\n");
> +        return -1;
> +    }
> +
> +    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
> +    if (rc) {
> +        return rc;
> +    }
> +
> +    if (pirq < 0) {
> +        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
> +        return -1;
> +    }
> +
> +    msi->pirq = pirq;
> +    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
> +
> +    return 0;
> +}
> +
> +int pt_msi_update(XenPCIPassthroughState *s)
> +{
> +    XenPTMSI *msi = s->msi;
> +    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
> +                           false, 0, &msi->pirq);
> +}
> +
> +void pt_msi_disable(XenPCIPassthroughState *s)
> +{
> +    XenPTMSI *msi = s->msi;
> +
> +    if (!msi) {
> +        return;
> +    }
> +
> +    pt_msi_set_enable(s, false);
> +
> +    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
> +                     msi->initialized);
> +
> +    /* clear msi info */
> +    msi->flags = 0;
> +    msi->mapped = false;
> +    msi->pirq = PT_UNASSIGNED_PIRQ;
> +}
> +
> +/*
> + * MSI-X virtualization functions
> + */
> +
> +static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
> +{
> +    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
> +
> +    if (!s->msix) {
> +        return -1;
> +    }
> +
> +    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
> +                           enabled);
> +}
> +
> +static void mask_physical_msix_entry(XenPCIPassthroughState *s,
> +                                     int entry_nr, int mask)
> +{
> +    void *phys_off;
> +
> +    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
> +        + PCI_MSIX_ENTRY_VECTOR_CTRL;
> +    *(uint32_t *)phys_off = mask;
> +}
> +
> +static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
> +{
> +    XenPTMSIXEntry *entry = NULL;
> +    int pirq;
> +    int rc;
> +
> +    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
> +        return -EINVAL;
> +    }
> +
> +    entry = &s->msix->msix_entry[entry_nr];
> +
> +    if (!entry->updated) {
> +        return 0;
> +    }
> +
> +    pirq = entry->pirq;
> +
> +    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
> +                        entry->pirq == PT_UNASSIGNED_PIRQ);
> +    if (rc) {
> +        return rc;
> +    }
> +    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
> +        entry->pirq = pirq;
> +    }
> +
> +    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
> +                         entry_nr, &entry->pirq);
> +
> +    if (!rc) {
> +        entry->updated = false;
> +    }
> +
> +    return rc;
> +}
> +
> +int pt_msix_update(XenPCIPassthroughState *s)
> +{
> +    XenPTMSIX *msix = s->msix;
> +    int i;
> +
> +    for (i = 0; i < msix->total_entries; i++) {
> +        pt_msix_update_one(s, i);
> +    }
> +
> +    return 0;
> +}
> +
> +void pt_msix_disable(XenPCIPassthroughState *s)
> +{
> +    int i = 0;
> +
> +    msix_set_enable(s, false);
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
> +
> +        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
> +
> +        /* clear MSI-X info */
> +        entry->pirq = PT_UNASSIGNED_PIRQ;
> +        entry->updated = false;
> +    }
> +}
> +
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenPTMSIXEntry *entry;
> +    int i, ret;
> +
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        entry = &s->msix->msix_entry[i];
> +        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
> +            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
> +                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
> +            if (ret) {
> +                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
> +            }
> +            entry->updated = true;
> +        }
> +    }
> +    pt_msix_update(s);
> +
> +    return 0;
> +}
> +
> +static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
> +{
> +    switch (offset) {
> +    case PCI_MSIX_ENTRY_LOWER_ADDR:
> +        return e->addr & UINT32_MAX;
> +    case PCI_MSIX_ENTRY_UPPER_ADDR:
> +        return e->addr >> 32;
> +    case PCI_MSIX_ENTRY_DATA:
> +        return e->data;
> +    case PCI_MSIX_ENTRY_VECTOR_CTRL:
> +        return e->vector_ctrl;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
> +{
> +    switch (offset) {
> +    case PCI_MSIX_ENTRY_LOWER_ADDR:
> +        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
> +        break;
> +    case PCI_MSIX_ENTRY_UPPER_ADDR:
> +        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
> +        break;
> +    case PCI_MSIX_ENTRY_DATA:
> +        e->data = val;
> +        break;
> +    case PCI_MSIX_ENTRY_VECTOR_CTRL:
> +        e->vector_ctrl = val;
> +        break;
> +    }
> +}
> +
> +static void pci_msix_write(void *opaque, target_phys_addr_t addr,
> +                           uint64_t val, unsigned size)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    XenPTMSIXEntry *entry;
> +    int entry_nr, offset;
> +
> +    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
> +    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
> +        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
> +        return;
> +    }
> +    entry = &msix->msix_entry[entry_nr];
> +    offset = addr % PCI_MSIX_ENTRY_SIZE;
> +
> +    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
> +        const volatile uint32_t *vec_ctrl;
> +
> +        if (get_entry_value(entry, offset) == val) {
> +            return;
> +        }
> +
> +        /*
> +         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
> +         * up-to-date. Read from hardware directly.
> +         */
> +        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
> +            + PCI_MSIX_ENTRY_VECTOR_CTRL;
> +
> +        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
> +            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already 
> "
> +                   "enabled.\n", entry_nr);
> +            return;
> +        }
> +
> +        entry->updated = true;
> +    }
> +
> +    set_entry_value(entry, offset, val);
> +
> +    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
> +        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
> +            pt_msix_update_one(s, entry_nr);
> +        }
> +        mask_physical_msix_entry(s, entry_nr,
> +            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
> +    }
> +}
> +
> +static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
> +                              unsigned size)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    int entry_nr, offset;
> +
> +    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
> +    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
> +        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
> +        return 0;
> +    }
> +
> +    offset = addr % PCI_MSIX_ENTRY_SIZE;
> +
> +    return get_entry_value(&msix->msix_entry[entry_nr], offset);
> +}
> +
> +static const MemoryRegionOps pci_msix_ops = {
> +    .read = pci_msix_read,
> +    .write = pci_msix_write,
> +    .endianness = DEVICE_NATIVE_ENDIAN,
> +    .valid = {
> +        .min_access_size = 4,
> +        .max_access_size = 4,
> +        .unaligned = false,
> +    },
> +};
> +
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenPTMSIX *msix = s->msix;
> +
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    memory_region_set_enabled(&msix->mmio, false);
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +           >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> +           >> XC_PAGE_SHIFT,
> +         DPCI_ADD_MAPPING);
> +}
> +
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenPTMSIX *msix = s->msix;
> +
> +    if (!(msix && msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    memory_region_set_enabled(&msix->mmio, true);
> +
> +    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
> +
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +             >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> +             >> XC_PAGE_SHIFT,
> +         DPCI_REMOVE_MAPPING);
> +}
> +
> +int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
> +{
> +    uint8_t id = 0;
> +    uint16_t control = 0;
> +    uint32_t table_off = 0;
> +    int i, total_entries, bar_index;
> +    HostPCIDevice *hd = s->real_device;
> +    PCIDevice *d = &s->dev;
> +    int fd = -1;
> +    XenPTMSIX *msix = NULL;
> +    int rc = 0;
> +
> +    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
> +    if (rc) {
> +        return rc;
> +    }
> +
> +    if (id != PCI_CAP_ID_MSIX) {
> +        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
> +        return -1;
> +    }
> +
> +    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
> +    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
> +    total_entries += 1;
> +
> +    s->msix = g_malloc0(sizeof (XenPTMSIX)
> +                        + total_entries * sizeof (XenPTMSIXEntry));
> +    msix = s->msix;
> +
> +    msix->total_entries = total_entries;
> +    for (i = 0; i < total_entries; i++) {
> +        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +
> +    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "passthrough-msix",
> +                          total_entries * PCI_MSIX_ENTRY_SIZE);
> +
> +    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
> +    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
> +    table_off = msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
> +    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
> +    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
> +
> +    fd = open("/dev/mem", O_RDWR);
> +    if (fd == -1) {
> +        rc = -errno;
> +        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
> +        goto error_out;
> +    }
> +    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
> +           table_off, total_entries);
> +    msix->table_offset_adjust = table_off & 0x0fff;
> +    msix->phys_iomem_base =
> +        mmap(NULL,
> +             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
> +             PROT_WRITE | PROT_READ,
> +             MAP_SHARED | MAP_LOCKED,
> +             fd,
> +             msix->table_base + table_off - msix->table_offset_adjust);
> +
> +    if (msix->phys_iomem_base == MAP_FAILED) {
> +        rc = -errno;
> +        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
> +        close(fd);
> +        goto error_out;
> +    }
> +    msix->phys_iomem_base = (char *)msix->phys_iomem_base
> +        + msix->table_offset_adjust;
> +
> +    close(fd);
> +
> +    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
> +
> +    memory_region_transaction_begin();
> +    memory_region_add_subregion_overlap(&s->bar[bar_index], msix->table_off,
> +                                        &msix->mmio,
> +                                        2); /* Priority: pci default + 1 */
> +    memory_region_set_enabled(&msix->mmio, false);
> +    memory_region_transaction_commit();
> +
> +    return 0;
> +
> +error_out:
> +    memory_region_destroy(&msix->mmio);
> +    g_free(s->msix);
> +    s->msix = NULL;
> +    return rc;
> +}
> +
> +void pt_msix_delete(XenPCIPassthroughState *s)
> +{
> +    XenPTMSIX *msix = s->msix;
> +
> +    if (!msix) {
> +        return;
> +    }
> +
> +    /* unmap the MSI-X memory mapped register area */
> +    if (msix->phys_iomem_base) {
> +        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
> +               msix->phys_iomem_base);
> +        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
> +               + msix->table_offset_adjust);
> +    }
> +
> +    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
> +    memory_region_destroy(&msix->mmio);
> +
> +    g_free(s->msix);
> +    s->msix = NULL;
> +}
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13: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.xensource.com>)
	id 1RxICF-0003kR-Vu; Tue, 14 Feb 2012 13:13:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxICE-0003kJ-3x
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:13:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329225152!52673360!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7742 invoked from network); 14 Feb 2012 13:12:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:12:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 13:13:24 +0000
Message-Id: <4F3A6C010200007800072E67@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 13:13:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: QEMU-devel <qemu-devel@nongnu.org>, Jiang Yunhong <yunhong.jiang@intel.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V6 10/11] Introduce Xen PCI Passthrough,
 MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 13:20, Anthony PERARD <anthony.perard@citrix.com> wrote:
> From: Jiang Yunhong <yunhong.jiang@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git

This needs to be updated to include the changes in
http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=bb36d632e4cabf47882adff07a45c6702c4a5b30
(and hopefully the broken function that got fixed in
http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=8cc8a3651c9c5bc2d0086d12f4b870fc525b9387
didn't even make it into this patch set). In particular it must be avoided
to map the MSI-X table with PROT_WRITE, and the respective MMIO
range should not get assigned to the guest at all.

Jan

> Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target                      |    1 +
>  hw/apic-msidef.h                     |    2 +
>  hw/xen_pci_passthrough.c             |   32 ++
>  hw/xen_pci_passthrough.h             |   48 +++
>  hw/xen_pci_passthrough_config_init.c |  480 ++++++++++++++++++++++++
>  hw/xen_pci_passthrough_msi.c         |  667 
> ++++++++++++++++++++++++++++++++++
>  6 files changed, 1230 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xen_pci_passthrough_msi.c
> 
> diff --git a/Makefile.target b/Makefile.target
> index 8fc2ca3..3517cab 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -220,6 +220,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
>  obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
> index 3182f0b..6e2eb71 100644
> --- a/hw/apic-msidef.h
> +++ b/hw/apic-msidef.h
> @@ -22,6 +22,8 @@
>  
>  #define MSI_ADDR_DEST_MODE_SHIFT        2
>  
> +#define MSI_ADDR_REDIRECTION_SHIFT      3
> +
>  #define MSI_ADDR_DEST_ID_SHIFT          12
>  #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
>  
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index bdc3690..1257ce2 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -36,6 +36,20 @@
>   *
>   *     Write '1'
>   *       - Set real bit to '1'.
> + *
> + * MSI interrupt:
> + *   Initialize MSI register(pt_msi_setup, pt_msi_update)
> + *     Bind MSI(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI.
> + *         - Set dev->msi->pirq to '-1'.
> + *
> + * MSI-X interrupt:
> + *   Initialize MSI-X register(pt_msix_update_one)
> + *     Bind MSI-X(xc_domain_update_msi_irq)
> + *       <fail>
> + *         - Unmap MSI-X.
> + *         - Set entry->pirq to '-1'.
>   */
>  
>  #include <sys/ioctl.h>
> @@ -362,6 +376,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>      }
>  
>      if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> +        pt_add_msix_mapping(s, i);
>          /* Remove old mapping */
>          rc = xc_domain_memory_mapping(xen_xc, xen_domid,
>                                 old_ebase >> XC_PAGE_SHIFT,
> @@ -386,6 +401,16 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>          if (rc) {
>              PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
>          }
> +
> +        rc = pt_remove_msix_mapping(s, i);
> +        if (rc != 0) {
> +            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
> +                   rc);
> +        }
> +
> +        if (old_ebase != e_phys && old_ebase != -1) {
> +            pt_msix_update_remap(s, i);
> +        }
>      }
>  }
>  
> @@ -766,6 +791,13 @@ static int pt_unregister_device(PCIDevice *d)
>          }
>      }
>  
> +    if (s->msi) {
> +        pt_msi_disable(s);
> +    }
> +    if (s->msix) {
> +        pt_msix_disable(s);
> +    }
> +
>      if (machine_irq) {
>          mapped_machine_irq[machine_irq]--;
>  
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index 0b9902d..deeba89 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -174,6 +174,37 @@ typedef struct XenPTRegGroup {
>  
>  
>  #define PT_UNASSIGNED_PIRQ (-1)
> +typedef struct XenPTMSI {
> +    uint16_t flags;
> +    uint32_t addr_lo;  /* guest message address */
> +    uint32_t addr_hi;  /* guest message upper address */
> +    uint16_t data;     /* guest message data */
> +    uint32_t ctrl_offset; /* saved control offset */
> +    int pirq;          /* guest pirq corresponding */
> +    bool initialized;  /* when guest MSI is initialized */
> +    bool mapped;       /* when pirq is mapped */
> +} XenPTMSI;
> +
> +typedef struct XenPTMSIXEntry {
> +    int pirq;
> +    uint64_t addr;
> +    uint32_t data;
> +    uint32_t vector_ctrl;
> +    bool updated; /* indicate whether MSI ADDR or DATA is updated */
> +} XenPTMSIXEntry;
> +typedef struct XenPTMSIX {
> +    uint32_t ctrl_offset;
> +    bool enabled;
> +    int total_entries;
> +    int bar_index;
> +    uint64_t table_base;
> +    uint32_t table_off;
> +    uint32_t table_offset_adjust; /* page align mmap */
> +    uint64_t mmio_base_addr;
> +    MemoryRegion mmio;
> +    void *phys_iomem_base;
> +    XenPTMSIXEntry msix_entry[0];
> +} XenPTMSIX;
>  
>  struct XenPCIPassthroughState {
>      PCIDevice dev;
> @@ -186,6 +217,9 @@ struct XenPCIPassthroughState {
>  
>      uint32_t machine_irq;
>  
> +    XenPTMSI *msi;
> +    XenPTMSIX *msix;
> +
>      MemoryRegion bar[PCI_NUM_REGIONS - 1];
>      MemoryRegion rom;
>  };
> @@ -262,4 +296,18 @@ static inline uint8_t pci_intx(XenPCIPassthroughState 
> *s)
>      return r_val;
>  }
>  
> +/* MSI/MSI-X */
> +int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
> +int pt_msi_setup(XenPCIPassthroughState *s);
> +int pt_msi_update(XenPCIPassthroughState *d);
> +void pt_msi_disable(XenPCIPassthroughState *s);
> +
> +int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
> +void pt_msix_delete(XenPCIPassthroughState *s);
> +int pt_msix_update(XenPCIPassthroughState *s);
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
> +void pt_msix_disable(XenPCIPassthroughState *s);
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +
>  #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_config_init.c 
> b/hw/xen_pci_passthrough_config_init.c
> index 2fb27ff..430c26a 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1125,6 +1125,419 @@ static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
>  };
>  
>  
> +/********************************
> + * MSI Capability
> + */
> +
> +/* Helper */
> +static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
> +{
> +    /* check the offset whether matches the type or not */
> +    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & 
> PCI_MSI_FLAGS_64BIT);
> +    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & 
> PCI_MSI_FLAGS_64BIT);
> +    return is_32 || is_64;
> +}
> +
> +/* Message Control register */
> +static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTMSI *msi = s->msi;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);
> +
> +    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
> +        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
> +    }
> +    msi->flags |= reg_field;
> +    msi->ctrl_offset = real_offset;
> +    msi->initialized = false;
> +    msi->mapped = false;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg 
> *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTMSI *msi = s->msi;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t val;
> +
> +    /* Currently no support for multi-vector */
> +    if (*value & PCI_MSI_FLAGS_QSIZE) {
> +        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
> +
> +    /* create value for writing to I/O device register */
> +    val = *value;
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (val & PCI_MSI_FLAGS_ENABLE) {
> +        /* setup MSI pirq for the first time */
> +        if (!msi->initialized) {
> +            /* Init physical one */
> +            PT_LOG(&s->dev, "setup MSI\n");
> +            if (pt_msi_setup(s)) {
> +                /* We do not broadcast the error to the framework code, so
> +                 * that MSI errors are contained in MSI emulation code and
> +                 * QEMU can go on running.
> +                 * Guest MSI would be actually not working.
> +                 */
> +                *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                PT_WARN(&s->dev, "Can not map MSI.\n");
> +                return 0;
> +            }
> +            if (pt_msi_update(s)) {
> +                *value &= ~PCI_MSI_FLAGS_ENABLE;
> +                PT_WARN(&s->dev, "Can not bind MSI\n");
> +                return 0;
> +            }
> +            msi->initialized = true;
> +            msi->mapped = true;
> +        }
> +        msi->flags |= PCI_MSI_FLAGS_ENABLE;
> +    } else {
> +        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
> +    }
> +
> +    /* pass through MSI_ENABLE bit */
> +    *value &= ~PCI_MSI_FLAGS_ENABLE;
> +    *value |= val & PCI_MSI_FLAGS_ENABLE;
> +
> +    return 0;
> +}
> +
> +/* initialize Message Upper Address register */
> +static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    /* no need to initialize in case of 32 bit type */
> +    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        *data = PT_INVALID_REG;
> +    } else {
> +        *data = reg->init_val;
> +    }
> +
> +    return 0;
> +}
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* initialize Message Data register */
> +static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
> +                               XenPTRegInfo *reg, uint32_t real_offset,
> +                               uint32_t *data)
> +{
> +    uint32_t flags = s->msi->flags;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (pt_msgdata_check_type(offset, flags)) {
> +        *data = reg->init_val;
> +    } else {
> +        *data = PT_INVALID_REG;
> +    }
> +    return 0;
> +}
> +
> +/* write Message Address register */
> +static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    s->msi->addr_lo = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->mapped) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +/* write Message Upper Address register */
> +static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
> +                                  XenPTReg *cfg_entry, uint32_t *value,
> +                                  uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t old_addr = cfg_entry->data;
> +
> +    /* check whether the type is 64 bit or not */
> +    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
> +        PT_ERR(&s->dev,
> +               "Can't write to the upper address without 64 bit 
> support\n");
> +        return -1;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    s->msi->addr_hi = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_addr) {
> +        if (s->msi->mapped) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +
> +/* this function will be called twice (for 32 bit and 64 bit type) */
> +/* write Message Data register */
> +static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg 
> *cfg_entry,
> +                                uint16_t *value, uint16_t dev_value,
> +                                uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTMSI *msi = s->msi;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t old_data = cfg_entry->data;
> +    uint32_t offset = reg->offset;
> +
> +    /* check the offset whether matches the type or not */
> +    if (!pt_msgdata_check_type(offset, msi->flags)) {
> +        /* exit I/O emulator */
> +        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
> +        return -1;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +    /* update the msi_info too */
> +    msi->data = cfg_entry->data;
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI */
> +    if (cfg_entry->data != old_data) {
> +        if (msi->mapped) {
> +            pt_msi_update(s);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* MSI Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFF8E,
> +        .emu_mask   = 0x007F,
> +        .init       = pt_msgctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Address reg */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_LO,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000003,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr32_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
> +    {
> +        .offset     = PCI_MSI_ADDRESS_HI,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x00000000,
> +        .emu_mask   = 0xFFFFFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgaddr64_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_msgaddr64_reg_write,
> +        .u.dw.restore = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 32-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_32,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    /* Message Data reg (16 bits of data for 64-bit devices) */
> +    {
> +        .offset     = PCI_MSI_DATA_64,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x0000,
> +        .emu_mask   = 0xFFFF,
> +        .no_wb      = 1,
> +        .init       = pt_msgdata_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msgdata_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * MSI-X Capability
> + */
> +
> +/* Message Control register for MSI-X */
> +static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t reg_field = 0;
> +
> +    /* use I/O device register's value as initial value */
> +    reg_field = pci_get_word(d->config + real_offset);
> +
> +    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
> +        PT_LOG(d, "MSIX already enabled, disabling it first\n");
> +        host_pci_set_word(s->real_device, real_offset,
> +                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
> +    }
> +
> +    s->msix->ctrl_offset = real_offset;
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
> +                                 XenPTReg *cfg_entry, uint16_t *value,
> +                                 uint16_t dev_value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    int debug_msix_enabled_old;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* update MSI-X */
> +    if ((*value & PCI_MSIX_FLAGS_ENABLE)
> +        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
> +        pt_msix_update(s);
> +    }
> +
> +    debug_msix_enabled_old = s->msix->enabled;
> +    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
> +    if (s->msix->enabled != debug_msix_enabled_old) {
> +        PT_LOG(&s->dev, "%s MSI-X\n",
> +               s->msix->enabled ? "enable" : "disable");
> +    }
> +
> +    return 0;
> +}
> +
> +/* MSI-X Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +        .u.b.restore  = NULL,
> +    },
> +    /* Message Control reg */
> +    {
> +        .offset     = PCI_MSI_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x3FFF,
> +        .emu_mask   = 0x0000,
> +        .init       = pt_msixctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_msixctrl_reg_write,
> +        .u.w.restore  = NULL,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
>  /****************************
>   * Capabilities
>   */
> @@ -1218,6 +1631,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState 
> *s,
>      *size = pcie_size;
>      return 0;
>  }
> +/* get MSI Capability Structure register group size */
> +static int pt_msi_size_init(XenPCIPassthroughState *s,
> +                            const XenPTRegGroupInfo *grp_reg,
> +                            uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint16_t msg_ctrl = 0;
> +    uint8_t msi_size = 0xa;
> +
> +    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
> +
> +    /* check if 64-bit address is capable of per-vector masking */
> +    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
> +        msi_size += 4;
> +    }
> +    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
> +        msi_size += 10;
> +    }
> +
> +    s->msi = g_new0(XenPTMSI, 1);
> +    s->msi->pirq = PT_UNASSIGNED_PIRQ;
> +
> +    *size = msi_size;
> +    return 0;
> +}
> +/* get MSI-X Capability Structure register group size */
> +static int pt_msix_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    int rc = 0;
> +
> +    rc = pt_msix_init(s, base_offset);
> +
> +    if (rc < 0) {
> +        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
> +        return rc;
> +    }
> +
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +
>  
>  static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
>      /* Header Type0 reg group */
> @@ -1250,6 +1706,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = 
> {
>          .grp_size   = 0x04,
>          .size_init  = pt_reg_grp_size_init,
>      },
> +    /* MSI Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSI,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_msi_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msi_tbl,
> +    },
>      /* PCI-X Capabilities List Item reg group */
>      {
>          .grp_id     = PCI_CAP_ID_PCIX,
> @@ -1294,6 +1758,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = 
> {
>          .size_init   = pt_pcie_size_init,
>          .emu_reg_tbl = pt_emu_reg_pcie_tbl,
>      },
> +    /* MSI-X Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_MSIX,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x0C,
> +        .size_init   = pt_msix_size_init,
> +        .emu_reg_tbl = pt_emu_reg_msix_tbl,
> +    },
>      {
>          .grp_size = 0,
>      },
> @@ -1478,6 +1950,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
>      struct XenPTRegGroup *reg_group, *next_grp;
>      struct XenPTReg *reg, *next_reg;
>  
> +    /* free MSI/MSI-X info table */
> +    if (s->msix) {
> +        pt_msix_delete(s);
> +    }
> +    if (s->msi) {
> +        g_free(s->msi);
> +    }
> +
>      /* free all register group entry */
>      QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
>          /* free all register entry */
> diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
> new file mode 100644
> index 0000000..0b81060
> --- /dev/null
> +++ b/hw/xen_pci_passthrough_msi.c
> @@ -0,0 +1,667 @@
> +/*
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Jiang Yunhong <yunhong.jiang@intel.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include <sys/mman.h>
> +
> +#include "xen_backend.h"
> +#include "xen_pci_passthrough.h"
> +#include "apic-msidef.h"
> +
> +
> +#define AUTO_ASSIGN -1
> +
> +/* shift count for gflags */
> +#define GFLAGS_SHIFT_DEST_ID        0
> +#define GFLAGS_SHIFT_RH             8
> +#define GFLAGS_SHIFT_DM             9
> +#define GLFAGS_SHIFT_DELIV_MODE     12
> +#define GLFAGS_SHIFT_TRG_MODE       15
> +
> +
> +/*
> + * Helpers
> + */
> +
> +static inline uint8_t msi_vector(uint32_t data)
> +{
> +    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
> +}
> +
> +static inline uint8_t msi_dest_id(uint32_t addr)
> +{
> +    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
> +}
> +
> +static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
> +{
> +    return addr_hi & 0xffffff00;
> +}
> +
> +static uint32_t msi_gflags(uint32_t data, uint64_t addr)
> +{
> +    uint32_t result = 0;
> +    int rh, dm, dest_id, deliv_mode, trig_mode;
> +
> +    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
> +    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
> +    dest_id = msi_dest_id(addr);
> +    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
> +    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> +
> +    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
> +        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
> +        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
> +
> +    return result;
> +}
> +
> +static inline uint64_t msi_addr64(XenPTMSI *msi)
> +{
> +    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
> +}
> +
> +static int msi_msix_enable(XenPCIPassthroughState *s,
> +                           uint32_t address,
> +                           uint16_t flag,
> +                           bool enable)
> +{
> +    uint16_t val = 0;
> +
> +    if (!address) {
> +        return -1;
> +    }
> +
> +    host_pci_get_word(s->real_device, address, &val);
> +    if (enable) {
> +        val |= flag;
> +    } else {
> +        val &= ~flag;
> +    }
> +    host_pci_set_word(s->real_device, address, val);
> +    return 0;
> +}
> +
> +static int msi_msix_setup(XenPCIPassthroughState *s,
> +                           uint64_t addr,
> +                           uint32_t data,
> +                           int *ppirq,
> +                           bool is_msix,
> +                           int msix_entry,
> +                           bool is_not_mapped)
> +{
> +    uint8_t gvec = msi_vector(data);
> +    int rc = 0;
> +
> +    assert((!is_msix && msix_entry == 0) || is_msix);
> +
> +    if (gvec == 0) {
> +        /* if gvec is 0, the guest is asking for a particular pirq that
> +         * is passed as dest_id */
> +        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
> +        if (!*ppirq) {
> +            /* this probably identifies an misconfiguration of the guest,
> +             * try the emulated path */
> +            *ppirq = PT_UNASSIGNED_PIRQ;
> +        } else {
> +            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
> +                   " (vec: %#x, entry: %#x)\n",
> +                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
> +        }
> +    }
> +
> +    if (is_not_mapped) {
> +        uint64_t table_base = 0;
> +
> +        if (is_msix) {
> +            table_base = s->msix->table_base;
> +        }
> +
> +        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
> +                                     PCI_DEVFN(s->real_device->dev,
> +                                               s->real_device->func),
> +                                     s->real_device->bus,
> +                                     msix_entry, table_base);
> +        if (rc) {
> +            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry 
> %#x)\n",
> +                   is_msix ? "-X" : "", rc, gvec, msix_entry);
> +            return rc;
> +        }
> +    }
> +
> +    return 0;
> +}
> +static int msi_msix_update(XenPCIPassthroughState *s,
> +                           uint64_t addr,
> +                           uint32_t data,
> +                           int pirq,
> +                           bool is_msix,
> +                           int msix_entry,
> +                           int *old_pirq)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = msi_vector(data);
> +    uint32_t gflags = msi_gflags(data, addr);
> +    int rc = 0;
> +    uint64_t table_addr = 0;
> +
> +    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: 
> %#x)\n",
> +           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
> +
> +    if (is_msix) {
> +        table_addr = s->msix->mmio_base_addr;
> +    }
> +
> +    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
> +                                  pirq, gflags, table_addr);
> +
> +    if (rc) {
> +        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
> +               is_msix ? "-X" : "", rc);
> +
> +        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
> +            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
> +                   is_msix ? "-X" : "", *old_pirq);
> +        }
> +        *old_pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +    return rc;
> +}
> +
> +static int msi_msix_disable(XenPCIPassthroughState *s,
> +                            uint64_t addr,
> +                            uint32_t data,
> +                            int pirq,
> +                            bool is_msix,
> +                            bool is_binded)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t gvec = msi_vector(data);
> +    uint32_t gflags = msi_gflags(data, addr);
> +    int rc = 0;
> +
> +    if (pirq == PT_UNASSIGNED_PIRQ) {
> +        return 0;
> +    }
> +
> +    if (is_binded) {
> +        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
> +               is_msix ? "-X" : "", pirq, gvec);
> +        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, 
> gflags);
> +        if (rc) {
> +            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
> +                   is_msix ? "-X" : "", pirq, gvec);
> +            return rc;
> +        }
> +    }
> +
> +    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
> +    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
> +    if (rc) {
> +        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
> +               is_msix ? "-X" : "", pirq, rc);
> +        return rc;
> +    }
> +
> +    return 0;
> +}
> +
> +/*
> + * MSI virtualization functions
> + */
> +
> +int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
> +{
> +    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
> +
> +    if (!s->msi) {
> +        return -1;
> +    }
> +
> +    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
> +                           enable);
> +}
> +
> +/* setup physical msi, but don't enable it */
> +int pt_msi_setup(XenPCIPassthroughState *s)
> +{
> +    int pirq = PT_UNASSIGNED_PIRQ;
> +    int rc = 0;
> +    XenPTMSI *msi = s->msi;
> +
> +    if (msi->initialized) {
> +        PT_ERR(&s->dev,
> +               "Setup physical MSI when it has been properly 
> initialized.\n");
> +        return -1;
> +    }
> +
> +    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
> +    if (rc) {
> +        return rc;
> +    }
> +
> +    if (pirq < 0) {
> +        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
> +        return -1;
> +    }
> +
> +    msi->pirq = pirq;
> +    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
> +
> +    return 0;
> +}
> +
> +int pt_msi_update(XenPCIPassthroughState *s)
> +{
> +    XenPTMSI *msi = s->msi;
> +    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
> +                           false, 0, &msi->pirq);
> +}
> +
> +void pt_msi_disable(XenPCIPassthroughState *s)
> +{
> +    XenPTMSI *msi = s->msi;
> +
> +    if (!msi) {
> +        return;
> +    }
> +
> +    pt_msi_set_enable(s, false);
> +
> +    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
> +                     msi->initialized);
> +
> +    /* clear msi info */
> +    msi->flags = 0;
> +    msi->mapped = false;
> +    msi->pirq = PT_UNASSIGNED_PIRQ;
> +}
> +
> +/*
> + * MSI-X virtualization functions
> + */
> +
> +static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
> +{
> +    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
> +
> +    if (!s->msix) {
> +        return -1;
> +    }
> +
> +    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
> +                           enabled);
> +}
> +
> +static void mask_physical_msix_entry(XenPCIPassthroughState *s,
> +                                     int entry_nr, int mask)
> +{
> +    void *phys_off;
> +
> +    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
> +        + PCI_MSIX_ENTRY_VECTOR_CTRL;
> +    *(uint32_t *)phys_off = mask;
> +}
> +
> +static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
> +{
> +    XenPTMSIXEntry *entry = NULL;
> +    int pirq;
> +    int rc;
> +
> +    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
> +        return -EINVAL;
> +    }
> +
> +    entry = &s->msix->msix_entry[entry_nr];
> +
> +    if (!entry->updated) {
> +        return 0;
> +    }
> +
> +    pirq = entry->pirq;
> +
> +    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
> +                        entry->pirq == PT_UNASSIGNED_PIRQ);
> +    if (rc) {
> +        return rc;
> +    }
> +    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
> +        entry->pirq = pirq;
> +    }
> +
> +    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
> +                         entry_nr, &entry->pirq);
> +
> +    if (!rc) {
> +        entry->updated = false;
> +    }
> +
> +    return rc;
> +}
> +
> +int pt_msix_update(XenPCIPassthroughState *s)
> +{
> +    XenPTMSIX *msix = s->msix;
> +    int i;
> +
> +    for (i = 0; i < msix->total_entries; i++) {
> +        pt_msix_update_one(s, i);
> +    }
> +
> +    return 0;
> +}
> +
> +void pt_msix_disable(XenPCIPassthroughState *s)
> +{
> +    int i = 0;
> +
> +    msix_set_enable(s, false);
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
> +
> +        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
> +
> +        /* clear MSI-X info */
> +        entry->pirq = PT_UNASSIGNED_PIRQ;
> +        entry->updated = false;
> +    }
> +}
> +
> +int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenPTMSIXEntry *entry;
> +    int i, ret;
> +
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    for (i = 0; i < s->msix->total_entries; i++) {
> +        entry = &s->msix->msix_entry[i];
> +        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
> +            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
> +                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
> +            if (ret) {
> +                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
> +            }
> +            entry->updated = true;
> +        }
> +    }
> +    pt_msix_update(s);
> +
> +    return 0;
> +}
> +
> +static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
> +{
> +    switch (offset) {
> +    case PCI_MSIX_ENTRY_LOWER_ADDR:
> +        return e->addr & UINT32_MAX;
> +    case PCI_MSIX_ENTRY_UPPER_ADDR:
> +        return e->addr >> 32;
> +    case PCI_MSIX_ENTRY_DATA:
> +        return e->data;
> +    case PCI_MSIX_ENTRY_VECTOR_CTRL:
> +        return e->vector_ctrl;
> +    default:
> +        return 0;
> +    }
> +}
> +
> +static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
> +{
> +    switch (offset) {
> +    case PCI_MSIX_ENTRY_LOWER_ADDR:
> +        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
> +        break;
> +    case PCI_MSIX_ENTRY_UPPER_ADDR:
> +        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
> +        break;
> +    case PCI_MSIX_ENTRY_DATA:
> +        e->data = val;
> +        break;
> +    case PCI_MSIX_ENTRY_VECTOR_CTRL:
> +        e->vector_ctrl = val;
> +        break;
> +    }
> +}
> +
> +static void pci_msix_write(void *opaque, target_phys_addr_t addr,
> +                           uint64_t val, unsigned size)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    XenPTMSIXEntry *entry;
> +    int entry_nr, offset;
> +
> +    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
> +    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
> +        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
> +        return;
> +    }
> +    entry = &msix->msix_entry[entry_nr];
> +    offset = addr % PCI_MSIX_ENTRY_SIZE;
> +
> +    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
> +        const volatile uint32_t *vec_ctrl;
> +
> +        if (get_entry_value(entry, offset) == val) {
> +            return;
> +        }
> +
> +        /*
> +         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
> +         * up-to-date. Read from hardware directly.
> +         */
> +        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
> +            + PCI_MSIX_ENTRY_VECTOR_CTRL;
> +
> +        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
> +            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already 
> "
> +                   "enabled.\n", entry_nr);
> +            return;
> +        }
> +
> +        entry->updated = true;
> +    }
> +
> +    set_entry_value(entry, offset, val);
> +
> +    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
> +        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
> +            pt_msix_update_one(s, entry_nr);
> +        }
> +        mask_physical_msix_entry(s, entry_nr,
> +            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
> +    }
> +}
> +
> +static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
> +                              unsigned size)
> +{
> +    XenPCIPassthroughState *s = opaque;
> +    XenPTMSIX *msix = s->msix;
> +    int entry_nr, offset;
> +
> +    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
> +    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
> +        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
> +        return 0;
> +    }
> +
> +    offset = addr % PCI_MSIX_ENTRY_SIZE;
> +
> +    return get_entry_value(&msix->msix_entry[entry_nr], offset);
> +}
> +
> +static const MemoryRegionOps pci_msix_ops = {
> +    .read = pci_msix_read,
> +    .write = pci_msix_write,
> +    .endianness = DEVICE_NATIVE_ENDIAN,
> +    .valid = {
> +        .min_access_size = 4,
> +        .max_access_size = 4,
> +        .unaligned = false,
> +    },
> +};
> +
> +int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenPTMSIX *msix = s->msix;
> +
> +    if (!(s->msix && s->msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    memory_region_set_enabled(&msix->mmio, false);
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +           >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> +           >> XC_PAGE_SHIFT,
> +         DPCI_ADD_MAPPING);
> +}
> +
> +int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> +{
> +    XenPTMSIX *msix = s->msix;
> +
> +    if (!(msix && msix->bar_index == bar_index)) {
> +        return 0;
> +    }
> +
> +    memory_region_set_enabled(&msix->mmio, true);
> +
> +    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
> +
> +    return xc_domain_memory_mapping(xen_xc, xen_domid,
> +         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> +         (s->bases[bar_index].access.maddr + s->msix->table_off)
> +             >> XC_PAGE_SHIFT,
> +         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> +             >> XC_PAGE_SHIFT,
> +         DPCI_REMOVE_MAPPING);
> +}
> +
> +int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
> +{
> +    uint8_t id = 0;
> +    uint16_t control = 0;
> +    uint32_t table_off = 0;
> +    int i, total_entries, bar_index;
> +    HostPCIDevice *hd = s->real_device;
> +    PCIDevice *d = &s->dev;
> +    int fd = -1;
> +    XenPTMSIX *msix = NULL;
> +    int rc = 0;
> +
> +    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
> +    if (rc) {
> +        return rc;
> +    }
> +
> +    if (id != PCI_CAP_ID_MSIX) {
> +        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
> +        return -1;
> +    }
> +
> +    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
> +    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
> +    total_entries += 1;
> +
> +    s->msix = g_malloc0(sizeof (XenPTMSIX)
> +                        + total_entries * sizeof (XenPTMSIXEntry));
> +    msix = s->msix;
> +
> +    msix->total_entries = total_entries;
> +    for (i = 0; i < total_entries; i++) {
> +        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
> +    }
> +
> +    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "passthrough-msix",
> +                          total_entries * PCI_MSIX_ENTRY_SIZE);
> +
> +    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
> +    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
> +    table_off = msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
> +    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
> +    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
> +
> +    fd = open("/dev/mem", O_RDWR);
> +    if (fd == -1) {
> +        rc = -errno;
> +        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
> +        goto error_out;
> +    }
> +    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
> +           table_off, total_entries);
> +    msix->table_offset_adjust = table_off & 0x0fff;
> +    msix->phys_iomem_base =
> +        mmap(NULL,
> +             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
> +             PROT_WRITE | PROT_READ,
> +             MAP_SHARED | MAP_LOCKED,
> +             fd,
> +             msix->table_base + table_off - msix->table_offset_adjust);
> +
> +    if (msix->phys_iomem_base == MAP_FAILED) {
> +        rc = -errno;
> +        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
> +        close(fd);
> +        goto error_out;
> +    }
> +    msix->phys_iomem_base = (char *)msix->phys_iomem_base
> +        + msix->table_offset_adjust;
> +
> +    close(fd);
> +
> +    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
> +
> +    memory_region_transaction_begin();
> +    memory_region_add_subregion_overlap(&s->bar[bar_index], msix->table_off,
> +                                        &msix->mmio,
> +                                        2); /* Priority: pci default + 1 */
> +    memory_region_set_enabled(&msix->mmio, false);
> +    memory_region_transaction_commit();
> +
> +    return 0;
> +
> +error_out:
> +    memory_region_destroy(&msix->mmio);
> +    g_free(s->msix);
> +    s->msix = NULL;
> +    return rc;
> +}
> +
> +void pt_msix_delete(XenPCIPassthroughState *s)
> +{
> +    XenPTMSIX *msix = s->msix;
> +
> +    if (!msix) {
> +        return;
> +    }
> +
> +    /* unmap the MSI-X memory mapped register area */
> +    if (msix->phys_iomem_base) {
> +        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
> +               msix->phys_iomem_base);
> +        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
> +               + msix->table_offset_adjust);
> +    }
> +
> +    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
> +    memory_region_destroy(&msix->mmio);
> +
> +    g_free(s->msix);
> +    s->msix = NULL;
> +}
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:27:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIPe-000461-ST; Tue, 14 Feb 2012 13:27:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxIPd-00045h-C1
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:27:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329226031!14748622!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15123 invoked from network); 14 Feb 2012 13:27:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:27:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 13:27:11 +0000
Message-Id: <4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 13:27:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur>
	<4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
	<1805920.cM9rJVskbD@amur>
In-Reply-To: <1805920.cM9rJVskbD@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 13:59, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> Am Dienstag 14 Februar 2012, 11:51:39 schrieb Jan Beulich:
>> >>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
>> > @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
>> >      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
>> >  
>> >      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
>> > +    {
>> > +        /* Special handling for BTS */
>> > +        if ( msr == MSR_IA32_DEBUGCTLMSR )
>> > +        {
>> > +            uint64_t supported = IA32_DEBUGCTLMSR_TR | 
> IA32_DEBUGCTLMSR_BTS |
>> > +                                 IA32_DEBUGCTLMSR_BTINT;
>> 
>> Was the code to make BTINT work magically in place already? I can't
>> spot anything to the effect in the patch...
> 
> No, BTINT wasn't handled before.
> The writing of the MSR's is done in the calling function
> vmx_msr_write_intercept() in xen/arch/x86/hvm/vmx/vmx.c.
> There I added the call of vpmu_do_wrmsr() in the case of 
> MSR_IA32_DEBUGCTLMSR.
> If vpmu_do_wrmsr() returns 1 the MSR gets written in the line
>    __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);

The question was more towards what happens if a guest enables this
bit without first setting up the corresponding LVT.

Plus enforcing the buffer requirements to avoid CPU deadlock
(contiguous present pages, alignment). Failure to do so can hang the
CPU, and hence would represent a DoS vulnerability.

> Maybe I can change this and write the MSR here in this function.

That might still be good to do, so checks and actual writing are in one
place.

>> 
>> > +
>> > +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
>> > +            {
>> > +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
>> > +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
>> > +            }
>> > +            if ( msr_content & supported  )
>> > +            {
>> > +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
>> > +                {
>> > +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported 
> on this cpu\n");
>> > +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
>> > +                    return 0;
>> > +                }
>> > +                return 1;
>> > +            }
>> > +        }
>> >          return 0;
>> > +    }
>> >  
>> >      core2_vpmu_cxt = vpmu->context;
>> >      switch ( msr )
>> > @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
>> >                       "which is not supported.\n");
>> >          return 1;
>> >      case MSR_IA32_DS_AREA:
>> > -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
>> > -        return 1;
>> > +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
>> > +        {
>> > +            if (!msr_content || !is_canonical_address(msr_content))
>> > +            {
>> > +                gdprintk(XENLOG_WARNING, "Illegal address for 
> IA32_DS_AREA: 0x%lx\n",
>> > +                                                            msr_content);
>> > +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
>> > +                return 1;
>> > +            }
>> > +            else
>> > +            {
>> > +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 
> 0;
>> > +                break;
>> 
>> How do you manage to get away without storing the value the guest
>> attempted to write?
> 
> In the case of MSR_IA32_DS_AREA the value is stored some lines later
> core2_vpmu_save_msr_context(v, type, index, msr_content);
> in an internal data structure.
> The values of this structure are loaded - core2_vpmu_load() - and stored
> - core2_vpmu_save() - on context switch.

Okay, I must have missed that part then.

However, in the context of the above the simple is_canonical_address()
check here clearly isn't enough.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:27:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIPe-000461-ST; Tue, 14 Feb 2012 13:27:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxIPd-00045h-C1
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:27:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329226031!14748622!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15123 invoked from network); 14 Feb 2012 13:27:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:27:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 13:27:11 +0000
Message-Id: <4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 13:27:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur>
	<4F3A58DB0200007800072DE8@nat28.tlf.novell.com>
	<1805920.cM9rJVskbD@amur>
In-Reply-To: <1805920.cM9rJVskbD@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 13:59, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> Am Dienstag 14 Februar 2012, 11:51:39 schrieb Jan Beulich:
>> >>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
>> > @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
>> >      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
>> >  
>> >      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
>> > +    {
>> > +        /* Special handling for BTS */
>> > +        if ( msr == MSR_IA32_DEBUGCTLMSR )
>> > +        {
>> > +            uint64_t supported = IA32_DEBUGCTLMSR_TR | 
> IA32_DEBUGCTLMSR_BTS |
>> > +                                 IA32_DEBUGCTLMSR_BTINT;
>> 
>> Was the code to make BTINT work magically in place already? I can't
>> spot anything to the effect in the patch...
> 
> No, BTINT wasn't handled before.
> The writing of the MSR's is done in the calling function
> vmx_msr_write_intercept() in xen/arch/x86/hvm/vmx/vmx.c.
> There I added the call of vpmu_do_wrmsr() in the case of 
> MSR_IA32_DEBUGCTLMSR.
> If vpmu_do_wrmsr() returns 1 the MSR gets written in the line
>    __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);

The question was more towards what happens if a guest enables this
bit without first setting up the corresponding LVT.

Plus enforcing the buffer requirements to avoid CPU deadlock
(contiguous present pages, alignment). Failure to do so can hang the
CPU, and hence would represent a DoS vulnerability.

> Maybe I can change this and write the MSR here in this function.

That might still be good to do, so checks and actual writing are in one
place.

>> 
>> > +
>> > +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
>> > +            {
>> > +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
>> > +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
>> > +            }
>> > +            if ( msr_content & supported  )
>> > +            {
>> > +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
>> > +                {
>> > +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported 
> on this cpu\n");
>> > +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
>> > +                    return 0;
>> > +                }
>> > +                return 1;
>> > +            }
>> > +        }
>> >          return 0;
>> > +    }
>> >  
>> >      core2_vpmu_cxt = vpmu->context;
>> >      switch ( msr )
>> > @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
>> >                       "which is not supported.\n");
>> >          return 1;
>> >      case MSR_IA32_DS_AREA:
>> > -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
>> > -        return 1;
>> > +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
>> > +        {
>> > +            if (!msr_content || !is_canonical_address(msr_content))
>> > +            {
>> > +                gdprintk(XENLOG_WARNING, "Illegal address for 
> IA32_DS_AREA: 0x%lx\n",
>> > +                                                            msr_content);
>> > +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
>> > +                return 1;
>> > +            }
>> > +            else
>> > +            {
>> > +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 
> 0;
>> > +                break;
>> 
>> How do you manage to get away without storing the value the guest
>> attempted to write?
> 
> In the case of MSR_IA32_DS_AREA the value is stored some lines later
> core2_vpmu_save_msr_context(v, type, index, msr_content);
> in an internal data structure.
> The values of this structure are loaded - core2_vpmu_load() - and stored
> - core2_vpmu_save() - on context switch.

Okay, I must have missed that part then.

However, in the context of the above the simple is_canonical_address()
check here clearly isn't enough.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:30:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxISg-0004I1-LK; Tue, 14 Feb 2012 13:30:26 +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 1RxISe-0004Hk-7j; Tue, 14 Feb 2012 13:30:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329226167!54192673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21416 invoked from network); 14 Feb 2012 13:29:27 -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;
	14 Feb 2012 13:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10686438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 13:30:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 13:30:17 +0000
Date: Tue, 14 Feb 2012 13:34:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329225071.31256.241.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329225071.31256.241.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-14 at 13:07 +0000, Stefano Stabellini wrote:
> > If the vgic needs to inject a virtual irq into the guest, but no free
> > LR registers are available, add the irq to a list and return.
> > Whenever an LR register becomes available we add the queued irq to it
> > and remove it from the list.
> > We use the gic lock to protect the list and the bitmask.
> 
> There's no need to order the IRQs by priority and ensure that the
> highest priorities are in the LRs?

You are right, they need to be ordered by priority.

-->8--

>From 027ddc0a08c5608797b03e66b87178cd2522ad07 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 14 Feb 2012 13:23:56 +0000
Subject: [PATCH] arm: support fewer LR registers than virtual irqs

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   58 ++++++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..129b7ff 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,47 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+    struct pending_irq *iter, *n;
+
+    spin_lock(&gic.lock);
+    for (i = 0; i < nr_lrs; i++) {
+        if (!test_and_set_bit(i, &gic.lr_mask))
+        {
+            gic_set_lr(i, virtual_irq, state, priority);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+
+    n = irq_to_pending(current, virtual_irq);
+    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->lr_link, &iter->lr_link);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+    list_add(&n->lr_link, &gic.lr_pending);
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -435,13 +471,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
+    for ( i = 0; i < nr_lrs; i++ ) {
         if ( eisr & ((uint64_t)1 << i) ) {
             struct pending_irq *p;
 
+            spin_lock(&gic.lock);
             lr = GICH[GICH_LR + i];
             virq = lr & GICH_LR_VIRTUAL_MASK;
             GICH[GICH_LR + i] = 0;
+            clear_bit(i, &gic.lr_mask);
+
+            if ( !list_empty(gic.lr_pending.next) ) {
+                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+                list_del(&p->lr_link);
+                INIT_LIST_HEAD(&p->lr_link);
+                set_bit(i, &gic.lr_mask);
+            } else {
+                gic_inject_irq_stop();
+            }
+            spin_unlock(&gic.lock);
 
             spin_lock(&current->arch.vgic.lock);
             p = irq_to_pending(current, virq);
@@ -449,7 +498,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            gic_inject_irq_stop();
             list_del(&p->link);
             INIT_LIST_HEAD(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:30:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxISg-0004I1-LK; Tue, 14 Feb 2012 13:30:26 +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 1RxISe-0004Hk-7j; Tue, 14 Feb 2012 13:30:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329226167!54192673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21416 invoked from network); 14 Feb 2012 13:29:27 -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;
	14 Feb 2012 13:29:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325462400"; d="scan'208";a="10686438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 13:30:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 13:30:17 +0000
Date: Tue, 14 Feb 2012 13:34:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329225071.31256.241.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329225071.31256.241.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-14 at 13:07 +0000, Stefano Stabellini wrote:
> > If the vgic needs to inject a virtual irq into the guest, but no free
> > LR registers are available, add the irq to a list and return.
> > Whenever an LR register becomes available we add the queued irq to it
> > and remove it from the list.
> > We use the gic lock to protect the list and the bitmask.
> 
> There's no need to order the IRQs by priority and ensure that the
> highest priorities are in the LRs?

You are right, they need to be ordered by priority.

-->8--

>From 027ddc0a08c5608797b03e66b87178cd2522ad07 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 14 Feb 2012 13:23:56 +0000
Subject: [PATCH] arm: support fewer LR registers than virtual irqs

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   58 ++++++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..129b7ff 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,47 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+    struct pending_irq *iter, *n;
+
+    spin_lock(&gic.lock);
+    for (i = 0; i < nr_lrs; i++) {
+        if (!test_and_set_bit(i, &gic.lr_mask))
+        {
+            gic_set_lr(i, virtual_irq, state, priority);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+
+    n = irq_to_pending(current, virtual_irq);
+    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->lr_link, &iter->lr_link);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+    list_add(&n->lr_link, &gic.lr_pending);
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -435,13 +471,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
+    for ( i = 0; i < nr_lrs; i++ ) {
         if ( eisr & ((uint64_t)1 << i) ) {
             struct pending_irq *p;
 
+            spin_lock(&gic.lock);
             lr = GICH[GICH_LR + i];
             virq = lr & GICH_LR_VIRTUAL_MASK;
             GICH[GICH_LR + i] = 0;
+            clear_bit(i, &gic.lr_mask);
+
+            if ( !list_empty(gic.lr_pending.next) ) {
+                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+                list_del(&p->lr_link);
+                INIT_LIST_HEAD(&p->lr_link);
+                set_bit(i, &gic.lr_mask);
+            } else {
+                gic_inject_irq_stop();
+            }
+            spin_unlock(&gic.lock);
 
             spin_lock(&current->arch.vgic.lock);
             p = irq_to_pending(current, virq);
@@ -449,7 +498,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            gic_inject_irq_stop();
             list_del(&p->link);
             INIT_LIST_HEAD(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:37:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIZ2-0004fY-Mp; Tue, 14 Feb 2012 13:37:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxIZ1-0004fP-D7
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:36:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329226613!16643654!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24923 invoked from network); 14 Feb 2012 13:36:53 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:36:53 -0000
Received: by wibhm14 with SMTP id hm14so5111082wib.23
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 05:36:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=BmKOOrF4yh7G7TYecRxK7pppSqboXvJ+0HR7I6Cw+/M=;
	b=iuXMdReU8M/HSxDHuX/+eWH+JY7uCQYBwXtFHOuQUcX+9WA6+bcw3GrhSJtVd7LgtH
	JQiw+rklxTacdhi75KbK+9CmTTOiM+u0q6ATGz8kqcLxch30nStQwLL1P3/fUqjdHghe
	ITsrev+sd4myMgdNUCxaBgiQ6avV/GgLryK28=
MIME-Version: 1.0
Received: by 10.180.100.228 with SMTP id fb4mr30742428wib.1.1329226613089;
	Tue, 14 Feb 2012 05:36:53 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 05:36:53 -0800 (PST)
In-Reply-To: <20275.59617.15772.210387@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
	<20275.59617.15772.210387@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 14:36:53 +0100
X-Google-Sender-Auth: kQrqY0POtlbUYqGTarpNIshL6QM
Message-ID: <CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add
	libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/9 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev"):
>> libxl: add libxl__find_free_vdev
>>
>> Add a function that returns the first free xvd<x> device, used to
>> attach a DomU image and execute the bootloader against that.
>
> I'm afraid I don't understand the purpose of this at all.

The main purpose of this series is to separate the control code from
the device code (make xl able to plug devices from a domain different
than dom0). Since the root image might not be stored on the dom0, we
need to be able to make this image available to the dom0 somehow, to
extract the kernel and ramdisk. One option is to execute pygrub from
the device domain, the other option is to plug the domU hard drive to
the dom0, run the bootloader to extract the kernel/initrd and unplug
the hd.

The later is the one implemented here partially, since
libxl_device_disk_local_attach still doesn't call the driver domain to
attach the device, this is done on a later patch (yes, it's probably a
mess).

> Also the comment "add <some function>" is not accurate because the
> real change is to run the bootloader on some other disk.

Not really, the bootloader was currently run against the vbd/phy
partition currently (eg: pygrub /home/xen/disk.img), not against the
vdev of the hd, because the hd was never locally attached
(libxl_device_disk_local_attach just returned the path to the phy
partition or vbd image, but never attached it to the dom0).

Following changes in this series make libxl_device_disk_local_attach
honor it's name, and truly attach the device to the dom0, creating a
new vdev in the dom0. Since the user might be using vdevs (xvda,
xvdb...) for it's own purposes, we need to find a free vdev in the
dom0 and attach the vbd to that, that's why this function is needed.

Hope this is clarifies things a little bit, and sorry for the delay.

Regards, Roger.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:37:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIZ2-0004fY-Mp; Tue, 14 Feb 2012 13:37:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxIZ1-0004fP-D7
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:36:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329226613!16643654!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24923 invoked from network); 14 Feb 2012 13:36:53 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:36:53 -0000
Received: by wibhm14 with SMTP id hm14so5111082wib.23
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 05:36:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=BmKOOrF4yh7G7TYecRxK7pppSqboXvJ+0HR7I6Cw+/M=;
	b=iuXMdReU8M/HSxDHuX/+eWH+JY7uCQYBwXtFHOuQUcX+9WA6+bcw3GrhSJtVd7LgtH
	JQiw+rklxTacdhi75KbK+9CmTTOiM+u0q6ATGz8kqcLxch30nStQwLL1P3/fUqjdHghe
	ITsrev+sd4myMgdNUCxaBgiQ6avV/GgLryK28=
MIME-Version: 1.0
Received: by 10.180.100.228 with SMTP id fb4mr30742428wib.1.1329226613089;
	Tue, 14 Feb 2012 05:36:53 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 05:36:53 -0800 (PST)
In-Reply-To: <20275.59617.15772.210387@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
	<20275.59617.15772.210387@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 14:36:53 +0100
X-Google-Sender-Auth: kQrqY0POtlbUYqGTarpNIshL6QM
Message-ID: <CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add
	libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/9 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev"):
>> libxl: add libxl__find_free_vdev
>>
>> Add a function that returns the first free xvd<x> device, used to
>> attach a DomU image and execute the bootloader against that.
>
> I'm afraid I don't understand the purpose of this at all.

The main purpose of this series is to separate the control code from
the device code (make xl able to plug devices from a domain different
than dom0). Since the root image might not be stored on the dom0, we
need to be able to make this image available to the dom0 somehow, to
extract the kernel and ramdisk. One option is to execute pygrub from
the device domain, the other option is to plug the domU hard drive to
the dom0, run the bootloader to extract the kernel/initrd and unplug
the hd.

The later is the one implemented here partially, since
libxl_device_disk_local_attach still doesn't call the driver domain to
attach the device, this is done on a later patch (yes, it's probably a
mess).

> Also the comment "add <some function>" is not accurate because the
> real change is to run the bootloader on some other disk.

Not really, the bootloader was currently run against the vbd/phy
partition currently (eg: pygrub /home/xen/disk.img), not against the
vdev of the hd, because the hd was never locally attached
(libxl_device_disk_local_attach just returned the path to the phy
partition or vbd image, but never attached it to the dom0).

Following changes in this series make libxl_device_disk_local_attach
honor it's name, and truly attach the device to the dom0, creating a
new vdev in the dom0. Since the user might be using vdevs (xvda,
xvdb...) for it's own purposes, we need to find a free vdev in the
dom0 and attach the vbd to that, that's why this function is needed.

Hope this is clarifies things a little bit, and sorry for the delay.

Regards, Roger.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:47:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIjG-0004wG-PY; Tue, 14 Feb 2012 13:47:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RxIjF-0004vX-8L
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:47:33 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329227245!15305963!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18076 invoked from network); 14 Feb 2012 13:47:27 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:47:27 -0000
Received: by obcuy19 with SMTP id uy19so30874701obc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 05:47:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=qHmd3wexWliN1JWQTJGTcFJ3KLI1eYu3HLkWJOpHNPY=;
	b=tITFla9pk++dyZ+QgsuULVqFUSuU2d2Slg/qzbuZ6PAeoBNKhEEArCEQE1b4Ejb8M8
	GEGSFed2Qwf3Rid38QlJMdZjlxL3XKn2l/sAaSevMw5cafFEjEUmZx72NZdZt2x1t7HD
	PCOgjlG5Zp/4j9qkbZMx1AEGlu+sJW5fPPlZg=
Received: by 10.182.147.4 with SMTP id tg4mr14824275obb.65.1329227245217; Tue,
	14 Feb 2012 05:47:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 14 Feb 2012 05:46:55 -0800 (PST)
In-Reply-To: <4F3A6C010200007800072E67@nat28.tlf.novell.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
	<4F3A6C010200007800072E67@nat28.tlf.novell.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 14 Feb 2012 13:46:55 +0000
X-Google-Sender-Auth: R6xeKpDGg_komCqU0p9WllO1pBo
Message-ID: <CAJJyHj+TKcE6241itt9ECeraEOxSPvFVCZwAZABmc6x0ROADow@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V6 10/11] Introduce Xen PCI
 Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, 2012 at 13:13, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 13.02.12 at 13:20, Anthony PERARD <anthony.perard@citrix.com> wrote:
>> From: Jiang Yunhong <yunhong.jiang@intel.com>
>>
>> A more complete history can be found here:
>> git://xenbits.xensource.com/qemu-xen-unstable.git
>
> This needs to be updated to include the changes in
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=bb36d632e4cabf47882adff07a45c6702c4a5b30
> (and hopefully the broken function that got fixed in
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=8cc8a3651c9c5bc2d0086d12f4b870fc525b9387
> didn't even make it into this patch set).

For the first patch/link, the 'volatile' variable should already be in
the patch (without a separate patch :( ). For the second, yes,
unregister_iomem is done by other functions in QEMU.

> In particular it must be avoided
> to map the MSI-X table with PROT_WRITE, and the respective MMIO
> range should not get assigned to the guest at all.

I will check that.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:47:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIjG-0004wG-PY; Tue, 14 Feb 2012 13:47:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RxIjF-0004vX-8L
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:47:33 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329227245!15305963!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18076 invoked from network); 14 Feb 2012 13:47:27 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:47:27 -0000
Received: by obcuy19 with SMTP id uy19so30874701obc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 05:47:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=qHmd3wexWliN1JWQTJGTcFJ3KLI1eYu3HLkWJOpHNPY=;
	b=tITFla9pk++dyZ+QgsuULVqFUSuU2d2Slg/qzbuZ6PAeoBNKhEEArCEQE1b4Ejb8M8
	GEGSFed2Qwf3Rid38QlJMdZjlxL3XKn2l/sAaSevMw5cafFEjEUmZx72NZdZt2x1t7HD
	PCOgjlG5Zp/4j9qkbZMx1AEGlu+sJW5fPPlZg=
Received: by 10.182.147.4 with SMTP id tg4mr14824275obb.65.1329227245217; Tue,
	14 Feb 2012 05:47:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 14 Feb 2012 05:46:55 -0800 (PST)
In-Reply-To: <4F3A6C010200007800072E67@nat28.tlf.novell.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
	<4F3A6C010200007800072E67@nat28.tlf.novell.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 14 Feb 2012 13:46:55 +0000
X-Google-Sender-Auth: R6xeKpDGg_komCqU0p9WllO1pBo
Message-ID: <CAJJyHj+TKcE6241itt9ECeraEOxSPvFVCZwAZABmc6x0ROADow@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V6 10/11] Introduce Xen PCI
 Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, 2012 at 13:13, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 13.02.12 at 13:20, Anthony PERARD <anthony.perard@citrix.com> wrote:
>> From: Jiang Yunhong <yunhong.jiang@intel.com>
>>
>> A more complete history can be found here:
>> git://xenbits.xensource.com/qemu-xen-unstable.git
>
> This needs to be updated to include the changes in
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=bb36d632e4cabf47882adff07a45c6702c4a5b30
> (and hopefully the broken function that got fixed in
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=8cc8a3651c9c5bc2d0086d12f4b870fc525b9387
> didn't even make it into this patch set).

For the first patch/link, the 'volatile' variable should already be in
the patch (without a separate patch :( ). For the second, yes,
unregister_iomem is done by other functions in QEMU.

> In particular it must be avoided
> to map the MSI-X table with PROT_WRITE, and the respective MMIO
> range should not get assigned to the guest at all.

I will check that.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:56:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13: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.xensource.com>)
	id 1RxIrq-0005CV-Sn; Tue, 14 Feb 2012 13:56:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RxIrp-0005CN-Jj
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:56:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329227777!14652987!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27248 invoked from network); 14 Feb 2012 13:56:19 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:56:19 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1EDuCov021900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 14 Feb 2012 08:56:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1EDuCBP021898;
	Tue, 14 Feb 2012 08:56:12 -0500
Date: Tue, 14 Feb 2012 09:56:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120214135611.GA21610@andromeda.dapyr.net>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329136547.31256.89.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > The state is a bit embarrassing on the BSD side.  FreeBSD has had a
> > multi-page ring extension since October of 2010.  Unfortunately, I wrote
> > this extension before stumbling upon the Citrix blkif patch or the
> > extension being used on EC2.  It is closest to the EC2 implementation,
> > but not quite compatible.  The saving grace is that I don't know of any
> > deployments of this back-end outside of Spectra, and we have not shipped
> > it to customers, so I plan to upstream block front and back drivers that

Excellent <crosses out another TODO on the "get done at some point
list">

> > only implement the Citrix and EC2 style extension once blkif.h settles.  A

So what is the Red Hat version of this extension? Where can I find it?
Is it in the 2.6.18 hg tree?

> > preliminary version of these changes went out for review a couple weeks
> > ago.
> 
> Cool, thanks.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:56:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13: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.xensource.com>)
	id 1RxIrq-0005CV-Sn; Tue, 14 Feb 2012 13:56:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RxIrp-0005CN-Jj
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:56:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329227777!14652987!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27248 invoked from network); 14 Feb 2012 13:56:19 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:56:19 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1EDuCov021900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 14 Feb 2012 08:56:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1EDuCBP021898;
	Tue, 14 Feb 2012 08:56:12 -0500
Date: Tue, 14 Feb 2012 09:56:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120214135611.GA21610@andromeda.dapyr.net>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329136547.31256.89.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > The state is a bit embarrassing on the BSD side.  FreeBSD has had a
> > multi-page ring extension since October of 2010.  Unfortunately, I wrote
> > this extension before stumbling upon the Citrix blkif patch or the
> > extension being used on EC2.  It is closest to the EC2 implementation,
> > but not quite compatible.  The saving grace is that I don't know of any
> > deployments of this back-end outside of Spectra, and we have not shipped
> > it to customers, so I plan to upstream block front and back drivers that

Excellent <crosses out another TODO on the "get done at some point
list">

> > only implement the Citrix and EC2 style extension once blkif.h settles.  A

So what is the Red Hat version of this extension? Where can I find it?
Is it in the 2.6.18 hg tree?

> > preliminary version of these changes went out for review a couple weeks
> > ago.
> 
> Cool, thanks.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:58:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxItt-0005J8-Em; Tue, 14 Feb 2012 13:58:33 +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 1RxItr-0005Iw-Nc
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:58:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329227789!61349482!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26229 invoked from network); 14 Feb 2012 13:56:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:56:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325480400"; d="scan'208";a="181678531"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 08:58:28 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012
	08:58:28 -0500
Message-ID: <4F3A6883.4010204@citrix.com>
Date: Tue, 14 Feb 2012 13:58:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F399181.5060801@theshore.net>	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329214171.31256.198.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/12 10:09, Ian Campbell wrote:
> 1On Tue, 2012-02-14 at 00:54 +0000, Christopher S. Aker wrote:
>> On Feb 13, 2012, at 5:41 PM, Christopher S. Aker wrote:
>>> Network stress testing (iperf, UDP, bidirectional) the above stack reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs with the following:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 00000474
>>> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
>> This happens regardless of CONFIG_PARAVIRT_SPINLOCKS enabled or disabled.
> I think that rules out the recent pv spinlock bug (fixed by
> 7a7546b377bdaa25ac77f33d9433c59f259b9688, in various stable trees
> AFAIK).
>
> What line of code does that IP correspond to within xen_spin_lock_flags?
> Likewise the one in xen_netbk_schedule_xenvif from the stack.
>
> I suspect this must be &netbk->net_schedule_list_lock but I don't see
> how that can ever be NULL nor does the offset appear to be 0x474, at
> least in my tree -- although that may depend on debug options.
>
> Are you rebooting guests or plug/unplugging vifs while this is going on?
> What about hotplugging CPUs (dom0 in particular)?
>
> Does this happen as soon as the test starts or does it work for a bit
> before failing?
>
> Ian.

I dont know if this is related, but it looks very similar to a bug a
friend of mine encountered.  I tried to investigate but got nowhere.

Panic can be found: http://pastebin.com/ExCwhzpy

The panic looks as if it is on the same logical instruction.  (There is
a 32/64bit difference which would likely explain the out-by-one byte
reference for the dereference.)

The difference here is this bug is from the ext4 path, indicating that
it might be a spinlock problem rather than a network problem (of course,
assuming that this is infact the same bug)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 13:58:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 13:58:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxItt-0005J8-Em; Tue, 14 Feb 2012 13:58:33 +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 1RxItr-0005Iw-Nc
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:58:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329227789!61349482!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26229 invoked from network); 14 Feb 2012 13:56:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 13:56:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,416,1325480400"; d="scan'208";a="181678531"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 08:58:28 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012
	08:58:28 -0500
Message-ID: <4F3A6883.4010204@citrix.com>
Date: Tue, 14 Feb 2012 13:58:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F399181.5060801@theshore.net>	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329214171.31256.198.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/12 10:09, Ian Campbell wrote:
> 1On Tue, 2012-02-14 at 00:54 +0000, Christopher S. Aker wrote:
>> On Feb 13, 2012, at 5:41 PM, Christopher S. Aker wrote:
>>> Network stress testing (iperf, UDP, bidirectional) the above stack reliably BUGs on both 3.0.4 and 3.2.5, and on both IGB or e1000e NICs with the following:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 00000474
>>> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
>> This happens regardless of CONFIG_PARAVIRT_SPINLOCKS enabled or disabled.
> I think that rules out the recent pv spinlock bug (fixed by
> 7a7546b377bdaa25ac77f33d9433c59f259b9688, in various stable trees
> AFAIK).
>
> What line of code does that IP correspond to within xen_spin_lock_flags?
> Likewise the one in xen_netbk_schedule_xenvif from the stack.
>
> I suspect this must be &netbk->net_schedule_list_lock but I don't see
> how that can ever be NULL nor does the offset appear to be 0x474, at
> least in my tree -- although that may depend on debug options.
>
> Are you rebooting guests or plug/unplugging vifs while this is going on?
> What about hotplugging CPUs (dom0 in particular)?
>
> Does this happen as soon as the test starts or does it work for a bit
> before failing?
>
> Ian.

I dont know if this is related, but it looks very similar to a bug a
friend of mine encountered.  I tried to investigate but got nowhere.

Panic can be found: http://pastebin.com/ExCwhzpy

The panic looks as if it is on the same logical instruction.  (There is
a 32/64bit difference which would likely explain the out-by-one byte
reference for the dereference.)

The difference here is this bug is from the ext4 path, indicating that
it might be a spinlock problem rather than a network problem (of course,
assuming that this is infact the same bug)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:00:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIvw-0005Wk-A0; Tue, 14 Feb 2012 14:00:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RxIvu-0005WD-BP
	for Xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:00:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329228030!14653771!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12282 invoked from network); 14 Feb 2012 14:00:31 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:00:31 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1EE0KDU022271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 14 Feb 2012 09:00:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1EE0Kf2022269;
	Tue, 14 Feb 2012 09:00:20 -0500
Date: Tue, 14 Feb 2012 10:00:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120214140020.GB21610@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
User-Agent: Mutt/1.5.9i
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] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 02:12:08PM +0000, M A Young wrote:
> On Mon, 13 Feb 2012, Ian Campbell wrote:
> 
> >On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
> >>I get the backtrace below if I try to boot a PV guest running F17 Alpha
> >>TC2 in graphical mode. Is this a known problem?
> >
> >It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
> >the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
> >got to the bottom of the root cause though.
> >
> >That occasion was a suspend/resume thing so perhaps not really related
> >but it seems fishily similar.
> >
> >I've not looked at the code recently but it seems that back then I was
> >of the opinion that info->update_wanted == 0 must remain true until the
> >irq etc was all fully setup, that might be relevant now?
> 
> Yes, it does sound fishily similar. I didn't mention that it does work if 
> I do a text boot and then switch to a graphical runlevel, so it could be 

So how does F17 do it now? Is all in the graphical mode (KMS?) and it never
tries to hit text mode (so plymouth is on by default?)

> somthing happening in the wrong order, such as the framebuffer starting 
> before the irq is properly set up.

Hm, could you instrument xen-fbfront.c and see what the flow is during
bootup and compare that when running it under F16? That might shed some
light on this.
> 
> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:00:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIvw-0005Wk-A0; Tue, 14 Feb 2012 14:00:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RxIvu-0005WD-BP
	for Xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:00:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329228030!14653771!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12282 invoked from network); 14 Feb 2012 14:00:31 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:00:31 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1EE0KDU022271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 14 Feb 2012 09:00:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1EE0Kf2022269;
	Tue, 14 Feb 2012 09:00:20 -0500
Date: Tue, 14 Feb 2012 10:00:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120214140020.GB21610@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
User-Agent: Mutt/1.5.9i
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] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 02:12:08PM +0000, M A Young wrote:
> On Mon, 13 Feb 2012, Ian Campbell wrote:
> 
> >On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
> >>I get the backtrace below if I try to boot a PV guest running F17 Alpha
> >>TC2 in graphical mode. Is this a known problem?
> >
> >It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
> >the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
> >got to the bottom of the root cause though.
> >
> >That occasion was a suspend/resume thing so perhaps not really related
> >but it seems fishily similar.
> >
> >I've not looked at the code recently but it seems that back then I was
> >of the opinion that info->update_wanted == 0 must remain true until the
> >irq etc was all fully setup, that might be relevant now?
> 
> Yes, it does sound fishily similar. I didn't mention that it does work if 
> I do a text boot and then switch to a graphical runlevel, so it could be 

So how does F17 do it now? Is all in the graphical mode (KMS?) and it never
tries to hit text mode (so plymouth is on by default?)

> somthing happening in the wrong order, such as the framebuffer starting 
> before the irq is properly set up.

Hm, could you instrument xen-fbfront.c and see what the flow is during
bootup and compare that when running it under F16? That might shed some
light on this.
> 
> 	Michael Young
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:01:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIwD-0005Yo-NE; Tue, 14 Feb 2012 14:00:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxIwC-0005Xm-FA
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:00:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329228049!4977317!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14551 invoked from network); 14 Feb 2012 14:00: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:00:52 +0000
Message-Id: <4F3A771E0200007800072E95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:00:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
	<4F3A6C010200007800072E67@nat28.tlf.novell.com>
	<CAJJyHj+TKcE6241itt9ECeraEOxSPvFVCZwAZABmc6x0ROADow@mail.gmail.com>
In-Reply-To: <CAJJyHj+TKcE6241itt9ECeraEOxSPvFVCZwAZABmc6x0ROADow@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V6 10/11] Introduce Xen PCI
 Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 14:46, Anthony PERARD <anthony.perard@citrix.com> wrote:
> On Tue, Feb 14, 2012 at 13:13, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 13.02.12 at 13:20, Anthony PERARD <anthony.perard@citrix.com> wrote:
>>> From: Jiang Yunhong <yunhong.jiang@intel.com>
>>>
>>> A more complete history can be found here:
>>> git://xenbits.xensource.com/qemu-xen-unstable.git
>>
>> This needs to be updated to include the changes in
>> 
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=bb36d63 
> 2e4cabf47882adff07a45c6702c4a5b30
>> (and hopefully the broken function that got fixed in
>> 
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=8cc8a36 
> 51c9c5bc2d0086d12f4b870fc525b9387
>> didn't even make it into this patch set).
> 
> For the first patch/link, the 'volatile' variable should already be in
> the patch (without a separate patch :( ).

Good that you said "volatile" - that was the wrong link. The correct one
is
http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=56d7747a3cf811910c4cf865e1ebcb8b82502005

I'm sorry for that,
Jan

> For the second, yes,
> unregister_iomem is done by other functions in QEMU.
> 
>> In particular it must be avoided
>> to map the MSI-X table with PROT_WRITE, and the respective MMIO
>> range should not get assigned to the guest at all.
> 
> I will check that.
> 
> Regards,
> 
> -- 
> Anthony PERARD




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:01:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:01:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxIwD-0005Yo-NE; Tue, 14 Feb 2012 14:00:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxIwC-0005Xm-FA
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:00:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329228049!4977317!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14551 invoked from network); 14 Feb 2012 14:00: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:00:52 +0000
Message-Id: <4F3A771E0200007800072E95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:00:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1329135613-26061-1-git-send-email-anthony.perard@citrix.com>
	<1329135613-26061-11-git-send-email-anthony.perard@citrix.com>
	<4F3A6C010200007800072E67@nat28.tlf.novell.com>
	<CAJJyHj+TKcE6241itt9ECeraEOxSPvFVCZwAZABmc6x0ROADow@mail.gmail.com>
In-Reply-To: <CAJJyHj+TKcE6241itt9ECeraEOxSPvFVCZwAZABmc6x0ROADow@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V6 10/11] Introduce Xen PCI
 Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 14:46, Anthony PERARD <anthony.perard@citrix.com> wrote:
> On Tue, Feb 14, 2012 at 13:13, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 13.02.12 at 13:20, Anthony PERARD <anthony.perard@citrix.com> wrote:
>>> From: Jiang Yunhong <yunhong.jiang@intel.com>
>>>
>>> A more complete history can be found here:
>>> git://xenbits.xensource.com/qemu-xen-unstable.git
>>
>> This needs to be updated to include the changes in
>> 
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=bb36d63 
> 2e4cabf47882adff07a45c6702c4a5b30
>> (and hopefully the broken function that got fixed in
>> 
> http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=8cc8a36 
> 51c9c5bc2d0086d12f4b870fc525b9387
>> didn't even make it into this patch set).
> 
> For the first patch/link, the 'volatile' variable should already be in
> the patch (without a separate patch :( ).

Good that you said "volatile" - that was the wrong link. The correct one
is
http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=commitdiff;h=56d7747a3cf811910c4cf865e1ebcb8b82502005

I'm sorry for that,
Jan

> For the second, yes,
> unregister_iomem is done by other functions in QEMU.
> 
>> In particular it must be avoided
>> to map the MSI-X table with PROT_WRITE, and the respective MMIO
>> range should not get assigned to the guest at all.
> 
> I will check that.
> 
> Regards,
> 
> -- 
> Anthony PERARD




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:17:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJBz-0005yX-Fa; Tue, 14 Feb 2012 14:17:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxJBx-0005yP-Ti
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:17:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329229026!13339461!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3050 invoked from network); 14 Feb 2012 14:17:07 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 14:17:07 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxJBp-0003ii-Pe
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 06:17:05 -0800
Date: Tue, 14 Feb 2012 06:17:05 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329229025787-5482548.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] tools/examples: Add to makefile the xl
 configuration examples
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

tools/examples: Add to makefile the xl configuration examples

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/examples/Makefile |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index 1a3b049..8cea724 100644
--- a/tools/examples/Makefile
+++ b/tools/examples/Makefile
@@ -19,6 +19,8 @@ XEN_CONFIGS += xmexample.hvm-stubdom
 XEN_CONFIGS += xmexample.pv-grub
 XEN_CONFIGS += xmexample.nbd
 XEN_CONFIGS += xmexample.vti
+XEN_CONFIGS += xlexample.hvm
+XEN_CONFIGS += xlexample.pvlinux
 XEN_CONFIGS += xend-pci-quirks.sxp
 XEN_CONFIGS += xend-pci-permissive.sxp
 XEN_CONFIGS += xl.conf


--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-examples-Add-to-makefile-the-xl-configuration-examples-tp5482548p5482548.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:17:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJBz-0005yX-Fa; Tue, 14 Feb 2012 14:17:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxJBx-0005yP-Ti
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:17:14 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329229026!13339461!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3050 invoked from network); 14 Feb 2012 14:17:07 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 14:17:07 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxJBp-0003ii-Pe
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 06:17:05 -0800
Date: Tue, 14 Feb 2012 06:17:05 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329229025787-5482548.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] tools/examples: Add to makefile the xl
 configuration examples
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

tools/examples: Add to makefile the xl configuration examples

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/examples/Makefile |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index 1a3b049..8cea724 100644
--- a/tools/examples/Makefile
+++ b/tools/examples/Makefile
@@ -19,6 +19,8 @@ XEN_CONFIGS += xmexample.hvm-stubdom
 XEN_CONFIGS += xmexample.pv-grub
 XEN_CONFIGS += xmexample.nbd
 XEN_CONFIGS += xmexample.vti
+XEN_CONFIGS += xlexample.hvm
+XEN_CONFIGS += xlexample.pvlinux
 XEN_CONFIGS += xend-pci-quirks.sxp
 XEN_CONFIGS += xend-pci-permissive.sxp
 XEN_CONFIGS += xl.conf


--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-examples-Add-to-makefile-the-xl-configuration-examples-tp5482548p5482548.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:19:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJDk-00062w-Vg; Tue, 14 Feb 2012 14:19:04 +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 1RxJDj-00062h-3U
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:19:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329229080!56666452!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4125 invoked from network); 14 Feb 2012 14:18:02 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 14:18:02 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxJDd-0003uo-CP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 06:18:57 -0800
Date: Tue, 14 Feb 2012 06:18:57 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329229137377-5482553.post@n5.nabble.com>
In-Reply-To: <1329229025787-5482548.post@n5.nabble.com>
References: <1329229025787-5482548.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools/examples: Add to makefile the xl
 configuration examples
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I think it is good to also move all the readme and examples in a
subdirectory, for example docs, is a good idea or not?

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-examples-Add-to-makefile-the-xl-configuration-examples-tp5482548p5482553.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:19:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJDk-00062w-Vg; Tue, 14 Feb 2012 14:19:04 +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 1RxJDj-00062h-3U
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:19:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329229080!56666452!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4125 invoked from network); 14 Feb 2012 14:18:02 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 14:18:02 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RxJDd-0003uo-CP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 06:18:57 -0800
Date: Tue, 14 Feb 2012 06:18:57 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329229137377-5482553.post@n5.nabble.com>
In-Reply-To: <1329229025787-5482548.post@n5.nabble.com>
References: <1329229025787-5482548.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools/examples: Add to makefile the xl
 configuration examples
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I think it is good to also move all the readme and examples in a
subdirectory, for example docs, is a good idea or not?

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-examples-Add-to-makefile-the-xl-configuration-examples-tp5482548p5482553.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:25:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:25:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJJb-0006Rd-Tk; Tue, 14 Feb 2012 14:25:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJJa-0006RV-E2
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:25:06 +0000
Received: from [85.158.139.83:40017] by server-9.bemta-5.messagelabs.com id
	5E/30-30171-1CE6A3F4; Tue, 14 Feb 2012 14:25:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329229504!14966263!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30816 invoked from network); 14 Feb 2012 14:25:05 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:25:05 -0000
Received: by werb14 with SMTP id b14so2053wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=oYZOoWVhb7r9rKyA+JtMElqv3JSaAda+UfbCOOAFs88=;
	b=b2chR5VFwuK1MHdJsWwMcOAjgtS3zNozL/s6PQr72Gn1UN8eXEbQRR6HSoL/zp6c0E
	mviPrhsvspJhkJQHtHm8DP8xHS41LS6bYQ3T6uBIXnNeNqUnxXZF60YBM1LyB4dxUxjB
	0NEuHm5iPlLLVGJba58CI3qWR8C+BCp0KoJeg=
MIME-Version: 1.0
Received: by 10.180.100.228 with SMTP id fb4mr30978110wib.1.1329229504553;
	Tue, 14 Feb 2012 06:25:04 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:25:04 -0800 (PST)
In-Reply-To: <20274.42515.207448.987386@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42515.207448.987386@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:25:04 +0100
X-Google-Sender-Auth: Gksob_olNH9RYTgi0-0rVp48jqE
Message-ID: <CAPLaKK6uNH+2kUDQXEKEf4x7_r+35QYcY68FCT=sappyYOoSBg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/8 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
>>
>> This will allow us to pass the libxl_device_disk and libxl_device_nic
>> struct from Dom0 to driver domain, and execute the necessary backends
>> there.
>
> Also I think as you're inventing a new protocol we should have a
> protocol document which, unless I've missed it, doesn't appear in your
> series.

No, you are right, it's not documented anywhere, were is the best
place to put this? libxl.h?

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:25:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:25:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJJb-0006Rd-Tk; Tue, 14 Feb 2012 14:25:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJJa-0006RV-E2
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:25:06 +0000
Received: from [85.158.139.83:40017] by server-9.bemta-5.messagelabs.com id
	5E/30-30171-1CE6A3F4; Tue, 14 Feb 2012 14:25:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329229504!14966263!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30816 invoked from network); 14 Feb 2012 14:25:05 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:25:05 -0000
Received: by werb14 with SMTP id b14so2053wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=oYZOoWVhb7r9rKyA+JtMElqv3JSaAda+UfbCOOAFs88=;
	b=b2chR5VFwuK1MHdJsWwMcOAjgtS3zNozL/s6PQr72Gn1UN8eXEbQRR6HSoL/zp6c0E
	mviPrhsvspJhkJQHtHm8DP8xHS41LS6bYQ3T6uBIXnNeNqUnxXZF60YBM1LyB4dxUxjB
	0NEuHm5iPlLLVGJba58CI3qWR8C+BCp0KoJeg=
MIME-Version: 1.0
Received: by 10.180.100.228 with SMTP id fb4mr30978110wib.1.1329229504553;
	Tue, 14 Feb 2012 06:25:04 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:25:04 -0800 (PST)
In-Reply-To: <20274.42515.207448.987386@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42515.207448.987386@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:25:04 +0100
X-Google-Sender-Auth: Gksob_olNH9RYTgi0-0rVp48jqE
Message-ID: <CAPLaKK6uNH+2kUDQXEKEf4x7_r+35QYcY68FCT=sappyYOoSBg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/8 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
>> /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
>>
>> This will allow us to pass the libxl_device_disk and libxl_device_nic
>> struct from Dom0 to driver domain, and execute the necessary backends
>> there.
>
> Also I think as you're inventing a new protocol we should have a
> protocol document which, unless I've missed it, doesn't appear in your
> series.

No, you are right, it's not documented anywhere, were is the best
place to put this? libxl.h?

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:30:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJOd-0006b3-Ns; Tue, 14 Feb 2012 14:30:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RxJOc-0006ax-Cr
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:30:18 +0000
Received: from [85.158.139.83:18510] by server-9.bemta-5.messagelabs.com id
	47/30-30171-9FF6A3F4; Tue, 14 Feb 2012 14:30:17 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329229816!15023853!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIwNjUxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12362 invoked from network); 14 Feb 2012 14:30:17 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:30:17 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=gH0h4AqGnI10c2Bs/Qnjc6azpO5hXC4qtj/ctyOg20YMjAs5d7QJE79K
	3xX6anxfVNVNoqRRd1vuRzPY2rT9uII9/nZclitHFARvZhvQRYsPRqsUi
	urLGyiUXnRmYmrno/W31oeyep1X/F1QZyOr2XMyfI6Y1P3HqGxpU+YWZr
	q/9UWV0wocqIzgzt2J7tblafh07foRC4ZOKbdE/j+6/CMw4u4CJbOXR0v
	dZzRHT58ke5O2PGnFEA7VHC8kgJV1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329229817; x=1360765817;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=J7wy6iV69X6S9T/1jhQ5S8Z7V8aGtCJzCszoaPDOQY0=;
	b=rKCNFcgY6U9SJ7tLWvthFkXCUkGpl1Fv+NSRVVCLRIJD+rjtb93hUAEp
	eVL9jsOG98yVQ68U1uLzFWpNOEVQQYXMohFWKen/LZtxN/0i31N8nZM5L
	jyZmXo3CkHNYmF0BOm5ovQqdRcJecstS815nuB1hQZgLrdS84W22TApeP
	GuNO8GRYKBhOE3lnR3lKI+//jo67W/qEwTn/HmCNaGye9fqHXiNWozp41
	gRo1XOnfd3181qqnUv6HSgUUkcje8;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="101926054"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 14 Feb 2012 15:30:16 +0100
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="128897727"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 14 Feb 2012 15:30:15 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id CD36896101E;
	Tue, 14 Feb 2012 15:30:15 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 14 Feb 2012 15:30:15 +0100
Message-ID: <2263997.kVLThTfZaS@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
References: <6587132.0KbvunDmjW@amur> <1805920.cM9rJVskbD@amur>
	<4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
> >>> On 14.02.12 at 13:59, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > Am Dienstag 14 Februar 2012, 11:51:39 schrieb Jan Beulich:
> >> >>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> >> > @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >> >      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
> >> >  
> >> >      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
> >> > +    {
> >> > +        /* Special handling for BTS */
> >> > +        if ( msr == MSR_IA32_DEBUGCTLMSR )
> >> > +        {
> >> > +            uint64_t supported = IA32_DEBUGCTLMSR_TR | 
> > IA32_DEBUGCTLMSR_BTS |
> >> > +                                 IA32_DEBUGCTLMSR_BTINT;
> >> 
> >> Was the code to make BTINT work magically in place already? I can't
> >> spot anything to the effect in the patch...
> > 
> > No, BTINT wasn't handled before.
> > The writing of the MSR's is done in the calling function
> > vmx_msr_write_intercept() in xen/arch/x86/hvm/vmx/vmx.c.
> > There I added the call of vpmu_do_wrmsr() in the case of 
> > MSR_IA32_DEBUGCTLMSR.
> > If vpmu_do_wrmsr() returns 1 the MSR gets written in the line
> >    __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);
> 
> The question was more towards what happens if a guest enables this
> bit without first setting up the corresponding LVT.

The apic is checked and set, see apic_write_around() in vpmu_core2.c.

> 
> Plus enforcing the buffer requirements to avoid CPU deadlock
> (contiguous present pages, alignment). Failure to do so can hang the
> CPU, and hence would represent a DoS vulnerability.

I'm not sure what you mean here. Are you speaking about the DS buffer?
If yes, this is no problem, because the DS buffer addressm must be a domU
virtual address. The processor only writes data into the buffer, if the
domU is running so in the worst case the domU gets triggered a page fault
or what I testet a triple fault occurs and the domU gets rebootet.

> 
> > Maybe I can change this and write the MSR here in this function.
> 
> That might still be good to do, so checks and actual writing are in one
> place.

After thinking about this. The writing should better be in
vmx_msr_write_intercept() because vpmu_do_wrmsr() in this case does only a
check of illegal set bits in the vpmu environment. In such a case a
TRAP_gp_fault is initiated otherwise nothing is done.

> 
> >> 
> >> > +
> >> > +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
> >> > +            {
> >> > +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
> >> > +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
> >> > +            }
> >> > +            if ( msr_content & supported  )
> >> > +            {
> >> > +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
> >> > +                {
> >> > +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported 
> > on this cpu\n");
> >> > +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
> >> > +                    return 0;
> >> > +                }
> >> > +                return 1;
> >> > +            }
> >> > +        }
> >> >          return 0;
> >> > +    }
> >> >  
> >> >      core2_vpmu_cxt = vpmu->context;
> >> >      switch ( msr )
> >> > @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >> >                       "which is not supported.\n");
> >> >          return 1;
> >> >      case MSR_IA32_DS_AREA:
> >> > -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> >> > -        return 1;
> >> > +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
> >> > +        {
> >> > +            if (!msr_content || !is_canonical_address(msr_content))
> >> > +            {
> >> > +                gdprintk(XENLOG_WARNING, "Illegal address for 
> > IA32_DS_AREA: 0x%lx\n",
> >> > +                                                            msr_content);
> >> > +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
> >> > +                return 1;
> >> > +            }
> >> > +            else
> >> > +            {
> >> > +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 
> > 0;
> >> > +                break;
> >> 
> >> How do you manage to get away without storing the value the guest
> >> attempted to write?
> > 
> > In the case of MSR_IA32_DS_AREA the value is stored some lines later
> > core2_vpmu_save_msr_context(v, type, index, msr_content);
> > in an internal data structure.
> > The values of this structure are loaded - core2_vpmu_load() - and stored
> > - core2_vpmu_save() - on context switch.
> 
> Okay, I must have missed that part then.
> 
> However, in the context of the above the simple is_canonical_address()
> check here clearly isn't enough.

As described above, the access to this buffer is only done while running the domU.

Dietmar.

> 
> Jan
> 
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:30:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJOd-0006b3-Ns; Tue, 14 Feb 2012 14:30:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RxJOc-0006ax-Cr
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:30:18 +0000
Received: from [85.158.139.83:18510] by server-9.bemta-5.messagelabs.com id
	47/30-30171-9FF6A3F4; Tue, 14 Feb 2012 14:30:17 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329229816!15023853!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIwNjUxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12362 invoked from network); 14 Feb 2012 14:30:17 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:30:17 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=gH0h4AqGnI10c2Bs/Qnjc6azpO5hXC4qtj/ctyOg20YMjAs5d7QJE79K
	3xX6anxfVNVNoqRRd1vuRzPY2rT9uII9/nZclitHFARvZhvQRYsPRqsUi
	urLGyiUXnRmYmrno/W31oeyep1X/F1QZyOr2XMyfI6Y1P3HqGxpU+YWZr
	q/9UWV0wocqIzgzt2J7tblafh07foRC4ZOKbdE/j+6/CMw4u4CJbOXR0v
	dZzRHT58ke5O2PGnFEA7VHC8kgJV1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329229817; x=1360765817;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=J7wy6iV69X6S9T/1jhQ5S8Z7V8aGtCJzCszoaPDOQY0=;
	b=rKCNFcgY6U9SJ7tLWvthFkXCUkGpl1Fv+NSRVVCLRIJD+rjtb93hUAEp
	eVL9jsOG98yVQ68U1uLzFWpNOEVQQYXMohFWKen/LZtxN/0i31N8nZM5L
	jyZmXo3CkHNYmF0BOm5ovQqdRcJecstS815nuB1hQZgLrdS84W22TApeP
	GuNO8GRYKBhOE3lnR3lKI+//jo67W/qEwTn/HmCNaGye9fqHXiNWozp41
	gRo1XOnfd3181qqnUv6HSgUUkcje8;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="101926054"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 14 Feb 2012 15:30:16 +0100
X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="128897727"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 14 Feb 2012 15:30:15 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id CD36896101E;
	Tue, 14 Feb 2012 15:30:15 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 14 Feb 2012 15:30:15 +0100
Message-ID: <2263997.kVLThTfZaS@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
References: <6587132.0KbvunDmjW@amur> <1805920.cM9rJVskbD@amur>
	<4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
> >>> On 14.02.12 at 13:59, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > Am Dienstag 14 Februar 2012, 11:51:39 schrieb Jan Beulich:
> >> >>> On 13.02.12 at 14:01, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> >> > @@ -401,7 +401,31 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >> >      struct core2_vpmu_context *core2_vpmu_cxt = NULL;
> >> >  
> >> >      if ( !core2_vpmu_msr_common_check(msr, &type, &index) )
> >> > +    {
> >> > +        /* Special handling for BTS */
> >> > +        if ( msr == MSR_IA32_DEBUGCTLMSR )
> >> > +        {
> >> > +            uint64_t supported = IA32_DEBUGCTLMSR_TR | 
> > IA32_DEBUGCTLMSR_BTS |
> >> > +                                 IA32_DEBUGCTLMSR_BTINT;
> >> 
> >> Was the code to make BTINT work magically in place already? I can't
> >> spot anything to the effect in the patch...
> > 
> > No, BTINT wasn't handled before.
> > The writing of the MSR's is done in the calling function
> > vmx_msr_write_intercept() in xen/arch/x86/hvm/vmx/vmx.c.
> > There I added the call of vpmu_do_wrmsr() in the case of 
> > MSR_IA32_DEBUGCTLMSR.
> > If vpmu_do_wrmsr() returns 1 the MSR gets written in the line
> >    __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);
> 
> The question was more towards what happens if a guest enables this
> bit without first setting up the corresponding LVT.

The apic is checked and set, see apic_write_around() in vpmu_core2.c.

> 
> Plus enforcing the buffer requirements to avoid CPU deadlock
> (contiguous present pages, alignment). Failure to do so can hang the
> CPU, and hence would represent a DoS vulnerability.

I'm not sure what you mean here. Are you speaking about the DS buffer?
If yes, this is no problem, because the DS buffer addressm must be a domU
virtual address. The processor only writes data into the buffer, if the
domU is running so in the worst case the domU gets triggered a page fault
or what I testet a triple fault occurs and the domU gets rebootet.

> 
> > Maybe I can change this and write the MSR here in this function.
> 
> That might still be good to do, so checks and actual writing are in one
> place.

After thinking about this. The writing should better be in
vmx_msr_write_intercept() because vpmu_do_wrmsr() in this case does only a
check of illegal set bits in the vpmu environment. In such a case a
TRAP_gp_fault is initiated otherwise nothing is done.

> 
> >> 
> >> > +
> >> > +            if ( cpu_has(&current_cpu_data, X86_FEATURE_DSCPL) )
> >> > +            {
> >> > +                supported |= IA32_DEBUGCTLMSR_BTS_OFF_OS |
> >> > +                                 IA32_DEBUGCTLMSR_BTS_OFF_USR;
> >> > +            }
> >> > +            if ( msr_content & supported  )
> >> > +            {
> >> > +                if ( !vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
> >> > +                {
> >> > +                    gdprintk(XENLOG_WARNING, "Debug Store is not supported 
> > on this cpu\n");
> >> > +                    vmx_inject_hw_exception(TRAP_gp_fault, 0);
> >> > +                    return 0;
> >> > +                }
> >> > +                return 1;
> >> > +            }
> >> > +        }
> >> >          return 0;
> >> > +    }
> >> >  
> >> >      core2_vpmu_cxt = vpmu->context;
> >> >      switch ( msr )
> >> > @@ -420,8 +444,26 @@ static int core2_vpmu_do_wrmsr(unsigned 
> >> >                       "which is not supported.\n");
> >> >          return 1;
> >> >      case MSR_IA32_DS_AREA:
> >> > -        gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
> >> > -        return 1;
> >> > +        if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
> >> > +        {
> >> > +            if (!msr_content || !is_canonical_address(msr_content))
> >> > +            {
> >> > +                gdprintk(XENLOG_WARNING, "Illegal address for 
> > IA32_DS_AREA: 0x%lx\n",
> >> > +                                                            msr_content);
> >> > +                vmx_inject_hw_exception(TRAP_gp_fault, 0);
> >> > +                return 1;
> >> > +            }
> >> > +            else
> >> > +            {
> >> > +                core2_vpmu_cxt->pmu_enable->ds_area_enable = msr_content ? 1 : 
> > 0;
> >> > +                break;
> >> 
> >> How do you manage to get away without storing the value the guest
> >> attempted to write?
> > 
> > In the case of MSR_IA32_DS_AREA the value is stored some lines later
> > core2_vpmu_save_msr_context(v, type, index, msr_content);
> > in an internal data structure.
> > The values of this structure are loaded - core2_vpmu_load() - and stored
> > - core2_vpmu_save() - on context switch.
> 
> Okay, I must have missed that part then.
> 
> However, in the context of the above the simple is_canonical_address()
> check here clearly isn't enough.

As described above, the access to this buffer is only done while running the domU.

Dietmar.

> 
> Jan
> 
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:31:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxJPn-0006fu-6X; Tue, 14 Feb 2012 14:31:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJPm-0006fX-0M
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:31:30 +0000
Received: from [85.158.139.83:63349] by server-12.bemta-5.messagelabs.com id
	F3/5F-24595-1407A3F4; Tue, 14 Feb 2012 14:31:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329229888!15028616!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8351 invoked from network); 14 Feb 2012 14:31:28 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:31:28 -0000
Received: by wibhm2 with SMTP id hm2so90955wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=CRmQ7v64h1/WAziyHGLjV35nWGykt45ANCVpO0d178k=;
	b=oi0A4pQIGnp8zWsLOrToAPYQJewEk/MiST8Z/+M0kdnWFkyFhdGlyWJRrWcCYbn9iK
	J+1uGM+nww8fRZtqNh8F4rcFngykOajdVTCSTI7m7m2RPX88oEYGa4YGgvWrC1TCcOHO
	REYhbXlNmwWji9AFw4vzUwATJ87Ww1ZlWDr58=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr30961924wiy.1.1329229388710; Tue,
	14 Feb 2012 06:23:08 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:23:08 -0800 (PST)
In-Reply-To: <20274.42482.96188.319229@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:23:08 +0100
X-Google-Sender-Auth: FIrBF4BAF-Fjpgy8r9WvFrTQUvg
Message-ID: <CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzggSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IFJvZ2Vy
IFBhdSBNb25uZSB3cml0ZXMgKCJbWGVuLWRldmVsXSBbUEFUQ0ggMjAgb2YgMjkgUkZDXSBsaWJ4
bDogaW50cm9kdWNlIGxpYnhsIGhvdHBsdWcgcHVibGljIEFQSSBmdW5jdGlvbnMiKToKPj4gbGli
eGw6IGludHJvZHVjZSBsaWJ4bCBob3RwbHVnIHB1YmxpYyBBUEkgZnVuY3Rpb25zCj4+Cj4+IFRo
ZXNlIGZ1bmN0aW9ucyBtaW1pYyB0aGUgbmFtZSB1c2VkIGJ5IHRoZSBsb2NhbCBkZXZpY2UgZnVu
Y3Rpb25zLAo+PiBmb2xsb3dpbmcgdGhlIG5vbWVuY2xhdHVyZToKPgo+IEkgdGhpbmsgdGhlc2Ug
c2hvdWxkIGJlIHByaXZhdGUgZnVuY3Rpb25zLiDCoFlvdXIgbmV3IGRldmljZSBkYWVtb24gaXMs
Cj4gSSB0aGluaywgcGFydCBvZiB0aGUgaW1wbGVtZW50YXRpb24gb2YgbGlieGwsIG5vdCBzb21l
dGhpbmcgdGhhdAo+IGFub3RoZXIgdG9vbHN0YWNrIG9uIHRvcCBvZiBsaWJ4bCB3aWxsIHJlYXNv
bmFibHkgd2FudCB0byByZXBsYWNlLgo+Cj4gVGhpcyBpcyBhIG5ldyBkZXBhcnR1cmUgZm9yIGxp
YnhsLCB3aGljaCBkb2Vzbid0IGN1cnJlbnRseSBoYXZlIGFueQo+IGludGVybmFsIGV4ZWN1dGFi
bGVzLgoKTm90IHN1cmUgYWJvdXQgdGhlIGJlc3QgYXBwcm9hY2ggaGVyZSwgSSB0aG91Z2ggdGhh
dCB4bGRldmljZWQgd2lsbCBiZQpsaWtlIHhsLCBidXQgdGhhdCdzIHNvbWV0aGluZyB3ZSBjYW4g
ZGlzY3VzcyBhYm91dC4gQXMgeW91IGNhbiBzZWUsCnRoZSBjb2RlIGluIHhsZGV2aWNlZCBpcyBt
aW5pbWFsLCBhbmQgSSdtIG5vdCBzdXJlIGlmIHdlIHNob3VsZG4ndAphbGxvdyBwZW9wbGUgdG8g
bWFrZSB1c2Ugb2YgdGhpcyBuZXcgaW50ZXJmYWNlIHRvIGRldmVsb3AgYSBjdXN0b20KeGxkZXZp
Y2VkLiBJdCB3aWxsIHByb3ZpZGUgbXVjaCBtb3JlIGZsZXhpYmlsaXR5IHRoYW4gaG90cGx1ZyBz
Y3JpcHRzLgoKPgo+PiBUaGUgeGVuc3RvcmUgc3RydWN0dXJlIHVzZWQgYnkgdmJkIGRpc2sgZW50
cmllczoKPj4KPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJk
LzxkZXZpZD4KPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJk
LzxkZXZpZD4vcGRldl9wYXRoCj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlkPi88ZnJvbnRlbmRf
ZG9taWQ+L3ZiZC88ZGV2aWQ+L3ZkZXYKPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9u
dGVuZF9kb21pZD4vdmJkLzxkZXZpZD4vc2NyaXB0Cj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlk
Pi88ZnJvbnRlbmRfZG9taWQ+L3ZiZC88ZGV2aWQ+L3JlbW92YWJsZQo+PiAvaG90cGx1Zy88YmFj
a2VuZF9kb21pZD4vPGZyb250ZW5kX2RvbWlkPi92YmQvPGRldmlkPi9yZWFkd3JpdGUKPj4gL2hv
dHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJkLzxkZXZpZD4vaXNfY2Ry
b20KPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJkLzxkZXZp
ZD4vc3RhdGUKPj4KPj4gYW5kIHZpZiBkZXZpY2VzIHVzZSB0aGUgZm9sbG93aW5nOgo+Pgo+PiAv
aG90cGx1Zy88YmFja2VuZF9kb21pZD4vPGZyb250ZW5kX2RvbWlkPi92aWYvPGRldmlkPgo+PiAv
aG90cGx1Zy88YmFja2VuZF9kb21pZD4vPGZyb250ZW5kX2RvbWlkPi92aWYvPGRldmlkPi9tdHUK
Pj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmlmLzxkZXZpZD4v
bW9kZWwKPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmlmLzxk
ZXZpZD4vbWFjCj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlkPi88ZnJvbnRlbmRfZG9taWQ+L3Zp
Zi88ZGV2aWQ+L2lwCj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlkPi88ZnJvbnRlbmRfZG9taWQ+
L3ZpZi88ZGV2aWQ+L2JyaWRnZQo+PiAvaG90cGx1Zy88YmFja2VuZF9kb21pZD4vPGZyb250ZW5k
X2RvbWlkPi92aWYvPGRldmlkPi9pZm5hbWUKPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxm
cm9udGVuZF9kb21pZD4vdmlmLzxkZXZpZD4vc2NyaXB0Cj4+IC9ob3RwbHVnLzxiYWNrZW5kX2Rv
bWlkPi88ZnJvbnRlbmRfZG9taWQ+L3ZpZi88ZGV2aWQ+L25pY3R5cGUKPj4KPj4gVGhpcyB3aWxs
IGFsbG93IHVzIHRvIHBhc3MgdGhlIGxpYnhsX2RldmljZV9kaXNrIGFuZCBsaWJ4bF9kZXZpY2Vf
bmljCj4+IHN0cnVjdCBmcm9tIERvbTAgdG8gZHJpdmVyIGRvbWFpbiwgYW5kIGV4ZWN1dGUgdGhl
IG5lY2Vzc2FyeSBiYWNrZW5kcwo+PiB0aGVyZS4KPgo+IElzIHRoaXMgcmVhbGx5IHRoZSBiZXN0
IGVuY29kaW5nIG9mIHRoaXMgaW5mb3JtYXRpb24gaW4geGVuc3RvcmUgPwoKSSd2ZSBqdXN0IGNs
b25lZCB0aGUgY3VycmVudCBwcm90b2NvbCB1c2VkIGZvciB0aGUgYmFja2VuZC9mcm9udGVuZApk
ZXZpY2VzLCBJIGhhdmUgdG8gc2F5IEkgZG9uJ3QgZGlzbGlrZSBpdCAoYXBhcnQgZnJvbSB0aGUg
ZmFjdCB0aGF0IGl0CmlzIG5vdCBkb2N1bWVudGVkKSwgaXQncyBlYXN5IHRvIHZpZXcgd2hhdCB3
ZSBhcmUgZG9pbmcsIGFuZCB0byBkZWJ1ZwppdC4KCj4gSWYgd2UncmUgYWxsb3dlZCB0byBhc3N1
bWUgdGhhdCB0aGUgYmFja2VuZGQgaXMgYSBsaWJ4bCBwcm9ncmFtIHRvbywKPiBhbmQgb2YgYSBy
ZWFzb25hYmx5IHNpbWlsYXIgdmVyc2lvbiwgcGVyaGFwcyB3ZSBzaG91bGQgaGF2ZSBzb21lIGtp
bmQKPiBvZiBpZGwtZ2VuZXJhdGVkIG1hcHBpbmcgZnJvbSB4ZW5zdG9yZSBrZXlzIHRvIHN0cnVj
dCBtZW1iZXJzID8KCldpbGwgbG9vayBpbnRvIGl0LCBjdXJyZW50bHkgbmVpdGhlciBsaWJ4bF9k
ZXZpY2VfZGlzayBvcgpsaWJ4bF9kZXZpY2VfbmljIGRvbid0IGhhdmUgbWFwcGluZ3MgdG8gaXQn
cyByZWxhdGVkIHhlbnN0b3JlCmZyb250ZW5kL2JhY2tlbmQgZW50cmllcywgaXQgbWlnaHQgYmUg
Z29vZCB0byBhZGQgdGhvc2UgdG9vIGZpcnN0LgoKPiBJYW4uCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:31:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxJPn-0006fu-6X; Tue, 14 Feb 2012 14:31:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJPm-0006fX-0M
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:31:30 +0000
Received: from [85.158.139.83:63349] by server-12.bemta-5.messagelabs.com id
	F3/5F-24595-1407A3F4; Tue, 14 Feb 2012 14:31:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329229888!15028616!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8351 invoked from network); 14 Feb 2012 14:31:28 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:31:28 -0000
Received: by wibhm2 with SMTP id hm2so90955wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=CRmQ7v64h1/WAziyHGLjV35nWGykt45ANCVpO0d178k=;
	b=oi0A4pQIGnp8zWsLOrToAPYQJewEk/MiST8Z/+M0kdnWFkyFhdGlyWJRrWcCYbn9iK
	J+1uGM+nww8fRZtqNh8F4rcFngykOajdVTCSTI7m7m2RPX88oEYGa4YGgvWrC1TCcOHO
	REYhbXlNmwWji9AFw4vzUwATJ87Ww1ZlWDr58=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr30961924wiy.1.1329229388710; Tue,
	14 Feb 2012 06:23:08 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:23:08 -0800 (PST)
In-Reply-To: <20274.42482.96188.319229@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:23:08 +0100
X-Google-Sender-Auth: FIrBF4BAF-Fjpgy8r9WvFrTQUvg
Message-ID: <CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzggSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IFJvZ2Vy
IFBhdSBNb25uZSB3cml0ZXMgKCJbWGVuLWRldmVsXSBbUEFUQ0ggMjAgb2YgMjkgUkZDXSBsaWJ4
bDogaW50cm9kdWNlIGxpYnhsIGhvdHBsdWcgcHVibGljIEFQSSBmdW5jdGlvbnMiKToKPj4gbGli
eGw6IGludHJvZHVjZSBsaWJ4bCBob3RwbHVnIHB1YmxpYyBBUEkgZnVuY3Rpb25zCj4+Cj4+IFRo
ZXNlIGZ1bmN0aW9ucyBtaW1pYyB0aGUgbmFtZSB1c2VkIGJ5IHRoZSBsb2NhbCBkZXZpY2UgZnVu
Y3Rpb25zLAo+PiBmb2xsb3dpbmcgdGhlIG5vbWVuY2xhdHVyZToKPgo+IEkgdGhpbmsgdGhlc2Ug
c2hvdWxkIGJlIHByaXZhdGUgZnVuY3Rpb25zLiDCoFlvdXIgbmV3IGRldmljZSBkYWVtb24gaXMs
Cj4gSSB0aGluaywgcGFydCBvZiB0aGUgaW1wbGVtZW50YXRpb24gb2YgbGlieGwsIG5vdCBzb21l
dGhpbmcgdGhhdAo+IGFub3RoZXIgdG9vbHN0YWNrIG9uIHRvcCBvZiBsaWJ4bCB3aWxsIHJlYXNv
bmFibHkgd2FudCB0byByZXBsYWNlLgo+Cj4gVGhpcyBpcyBhIG5ldyBkZXBhcnR1cmUgZm9yIGxp
YnhsLCB3aGljaCBkb2Vzbid0IGN1cnJlbnRseSBoYXZlIGFueQo+IGludGVybmFsIGV4ZWN1dGFi
bGVzLgoKTm90IHN1cmUgYWJvdXQgdGhlIGJlc3QgYXBwcm9hY2ggaGVyZSwgSSB0aG91Z2ggdGhh
dCB4bGRldmljZWQgd2lsbCBiZQpsaWtlIHhsLCBidXQgdGhhdCdzIHNvbWV0aGluZyB3ZSBjYW4g
ZGlzY3VzcyBhYm91dC4gQXMgeW91IGNhbiBzZWUsCnRoZSBjb2RlIGluIHhsZGV2aWNlZCBpcyBt
aW5pbWFsLCBhbmQgSSdtIG5vdCBzdXJlIGlmIHdlIHNob3VsZG4ndAphbGxvdyBwZW9wbGUgdG8g
bWFrZSB1c2Ugb2YgdGhpcyBuZXcgaW50ZXJmYWNlIHRvIGRldmVsb3AgYSBjdXN0b20KeGxkZXZp
Y2VkLiBJdCB3aWxsIHByb3ZpZGUgbXVjaCBtb3JlIGZsZXhpYmlsaXR5IHRoYW4gaG90cGx1ZyBz
Y3JpcHRzLgoKPgo+PiBUaGUgeGVuc3RvcmUgc3RydWN0dXJlIHVzZWQgYnkgdmJkIGRpc2sgZW50
cmllczoKPj4KPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJk
LzxkZXZpZD4KPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJk
LzxkZXZpZD4vcGRldl9wYXRoCj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlkPi88ZnJvbnRlbmRf
ZG9taWQ+L3ZiZC88ZGV2aWQ+L3ZkZXYKPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9u
dGVuZF9kb21pZD4vdmJkLzxkZXZpZD4vc2NyaXB0Cj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlk
Pi88ZnJvbnRlbmRfZG9taWQ+L3ZiZC88ZGV2aWQ+L3JlbW92YWJsZQo+PiAvaG90cGx1Zy88YmFj
a2VuZF9kb21pZD4vPGZyb250ZW5kX2RvbWlkPi92YmQvPGRldmlkPi9yZWFkd3JpdGUKPj4gL2hv
dHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJkLzxkZXZpZD4vaXNfY2Ry
b20KPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmJkLzxkZXZp
ZD4vc3RhdGUKPj4KPj4gYW5kIHZpZiBkZXZpY2VzIHVzZSB0aGUgZm9sbG93aW5nOgo+Pgo+PiAv
aG90cGx1Zy88YmFja2VuZF9kb21pZD4vPGZyb250ZW5kX2RvbWlkPi92aWYvPGRldmlkPgo+PiAv
aG90cGx1Zy88YmFja2VuZF9kb21pZD4vPGZyb250ZW5kX2RvbWlkPi92aWYvPGRldmlkPi9tdHUK
Pj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmlmLzxkZXZpZD4v
bW9kZWwKPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxmcm9udGVuZF9kb21pZD4vdmlmLzxk
ZXZpZD4vbWFjCj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlkPi88ZnJvbnRlbmRfZG9taWQ+L3Zp
Zi88ZGV2aWQ+L2lwCj4+IC9ob3RwbHVnLzxiYWNrZW5kX2RvbWlkPi88ZnJvbnRlbmRfZG9taWQ+
L3ZpZi88ZGV2aWQ+L2JyaWRnZQo+PiAvaG90cGx1Zy88YmFja2VuZF9kb21pZD4vPGZyb250ZW5k
X2RvbWlkPi92aWYvPGRldmlkPi9pZm5hbWUKPj4gL2hvdHBsdWcvPGJhY2tlbmRfZG9taWQ+Lzxm
cm9udGVuZF9kb21pZD4vdmlmLzxkZXZpZD4vc2NyaXB0Cj4+IC9ob3RwbHVnLzxiYWNrZW5kX2Rv
bWlkPi88ZnJvbnRlbmRfZG9taWQ+L3ZpZi88ZGV2aWQ+L25pY3R5cGUKPj4KPj4gVGhpcyB3aWxs
IGFsbG93IHVzIHRvIHBhc3MgdGhlIGxpYnhsX2RldmljZV9kaXNrIGFuZCBsaWJ4bF9kZXZpY2Vf
bmljCj4+IHN0cnVjdCBmcm9tIERvbTAgdG8gZHJpdmVyIGRvbWFpbiwgYW5kIGV4ZWN1dGUgdGhl
IG5lY2Vzc2FyeSBiYWNrZW5kcwo+PiB0aGVyZS4KPgo+IElzIHRoaXMgcmVhbGx5IHRoZSBiZXN0
IGVuY29kaW5nIG9mIHRoaXMgaW5mb3JtYXRpb24gaW4geGVuc3RvcmUgPwoKSSd2ZSBqdXN0IGNs
b25lZCB0aGUgY3VycmVudCBwcm90b2NvbCB1c2VkIGZvciB0aGUgYmFja2VuZC9mcm9udGVuZApk
ZXZpY2VzLCBJIGhhdmUgdG8gc2F5IEkgZG9uJ3QgZGlzbGlrZSBpdCAoYXBhcnQgZnJvbSB0aGUg
ZmFjdCB0aGF0IGl0CmlzIG5vdCBkb2N1bWVudGVkKSwgaXQncyBlYXN5IHRvIHZpZXcgd2hhdCB3
ZSBhcmUgZG9pbmcsIGFuZCB0byBkZWJ1ZwppdC4KCj4gSWYgd2UncmUgYWxsb3dlZCB0byBhc3N1
bWUgdGhhdCB0aGUgYmFja2VuZGQgaXMgYSBsaWJ4bCBwcm9ncmFtIHRvbywKPiBhbmQgb2YgYSBy
ZWFzb25hYmx5IHNpbWlsYXIgdmVyc2lvbiwgcGVyaGFwcyB3ZSBzaG91bGQgaGF2ZSBzb21lIGtp
bmQKPiBvZiBpZGwtZ2VuZXJhdGVkIG1hcHBpbmcgZnJvbSB4ZW5zdG9yZSBrZXlzIHRvIHN0cnVj
dCBtZW1iZXJzID8KCldpbGwgbG9vayBpbnRvIGl0LCBjdXJyZW50bHkgbmVpdGhlciBsaWJ4bF9k
ZXZpY2VfZGlzayBvcgpsaWJ4bF9kZXZpY2VfbmljIGRvbid0IGhhdmUgbWFwcGluZ3MgdG8gaXQn
cyByZWxhdGVkIHhlbnN0b3JlCmZyb250ZW5kL2JhY2tlbmQgZW50cmllcywgaXQgbWlnaHQgYmUg
Z29vZCB0byBhZGQgdGhvc2UgdG9vIGZpcnN0LgoKPiBJYW4uCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:32:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJPz-0006i4-QY; Tue, 14 Feb 2012 14:31:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJPx-0006gs-Q1
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:31:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329229895!13329199!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26205 invoked from network); 14 Feb 2012 14:31:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:31:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:31:45 +0000
Message-Id: <4F3A7E540200007800072EB6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:31:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
In-Reply-To: <20120213142016.GA7108@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Feb 13, Jan Beulich wrote:
> 
>> >>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
>> > These functions are called for dom0, but not for domU. And as a result
>> > arch.nr_vmce_banks remains zero. I assume the guest needs to be
>> > initialized in some way as well, and that does not happen?
>> 
>> Below/attached a fixed version of the patch.
> 
> I get some mismatch after migration, both hosts run the same xen binary.

Are you sure about that? I'm asking because ...

> The small debug patch I use is attached.
> 
> 
> Also: The tools do not catch the restore error so that the guest continues 
> to
> run on the source host.
> 
> Olaf
> 
> nicolai login: (XEN) vmce_init_vcpu 0 o 0 n 806
> (XEN) vmce_init_vcpu 1 o 0 n 806
> (XEN) vmce_init_vcpu 2 o 0 n 806
> (XEN) vmce_init_vcpu 3 o 0 n 806
> (XEN) save.c:62:d0 HVM restore (1): VM saved on one CPU (0x206c2) and 
> restored on another (0x10676).
> (XEN) save.c:234:d0 HVM restore: CPU 0
> (XEN) save.c:234:d0 HVM restore: CPU 1
> (XEN) save.c:234:d0 HVM restore: CPU 2
> (XEN) save.c:234:d0 HVM restore: CPU 3
> (XEN) save.c:234:d0 HVM restore: PIC 0
> (XEN) save.c:234:d0 HVM restore: PIC 1
> (XEN) save.c:234:d0 HVM restore: IOAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 1
> (XEN) save.c:234:d0 HVM restore: LAPIC 2
> (XEN) save.c:234:d0 HVM restore: LAPIC 3
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
> (XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
> (XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
> (XEN) save.c:234:d0 HVM restore: PCI_LINK 0
> (XEN) save.c:234:d0 HVM restore: PIT 0
> (XEN) save.c:234:d0 HVM restore: RTC 0
> (XEN) save.c:234:d0 HVM restore: HPET 0
> (XEN) save.c:234:d0 HVM restore: PMTIMER 0
> (XEN) save.c:234:d0 HVM restore: MTRR 0
> (XEN) save.c:234:d0 HVM restore: MTRR 1
> (XEN) save.c:234:d0 HVM restore: MTRR 2
> (XEN) save.c:234:d0 HVM restore: MTRR 3
> (XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
> (XEN) save.c:291:d0 HVM restore mismatch: expected type 18 length 8, saw type 18 length 1

... this suggests the source host was still running with the old binary
(where the save record was indeed just 1 byte in size)...

> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff82c4802c7d28 ffffffff -1 o 806 n ea
> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
> (XEN) vmce_init_vcpu 0 o 0 n 806
> (XEN) vmce_init_vcpu 1 o 0 n 806
> (XEN) vmce_init_vcpu 2 o 0 n 806
> (XEN) vmce_init_vcpu 3 o 0 n 806
> (XEN) save.c:62:d0 HVM restore (2): VM saved on one CPU (0x206c2) and 
> restored on another (0x10676).
> (XEN) save.c:234:d0 HVM restore: CPU 0
> (XEN) save.c:234:d0 HVM restore: CPU 1
> (XEN) save.c:234:d0 HVM restore: CPU 2
> (XEN) save.c:234:d0 HVM restore: CPU 3
> (XEN) save.c:234:d0 HVM restore: PIC 0
> (XEN) save.c:234:d0 HVM restore: PIC 1
> (XEN) save.c:234:d0 HVM restore: IOAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 1
> (XEN) save.c:234:d0 HVM restore: LAPIC 2
> (XEN) save.c:234:d0 HVM restore: LAPIC 3
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
> (XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
> (XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
> (XEN) save.c:234:d0 HVM restore: PCI_LINK 0
> (XEN) save.c:234:d0 HVM restore: PIT 0
> (XEN) save.c:234:d0 HVM restore: RTC 0
> (XEN) save.c:234:d0 HVM restore: HPET 0
> (XEN) save.c:234:d0 HVM restore: PMTIMER 0
> (XEN) save.c:234:d0 HVM restore: MTRR 0
> (XEN) save.c:234:d0 HVM restore: MTRR 1
> (XEN) save.c:234:d0 HVM restore: MTRR 2
> (XEN) save.c:234:d0 HVM restore: MTRR 3
> (XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
> (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 (supported: 0x800)

... whereas this one suggests that the size check passed (same binary
on both ends) but the feature sets of the hosts are different (sorry,
I can't suggest a way around this, the hosts must be sufficiently
matching in MCA features - those differences that are tolerable are
already being handled). I'm confused as to what was running on the
source host.

Let me check what bit 12 is: The latest SDM considers this reserved,
so the only way I can see how to deal with this is to switch the
setting up of g_mcg_cap from a back-listing approach to a white-listing
one.

> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0

Bottom line - it appears to work as intended considering the second
attempt.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:32:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJPz-0006i4-QY; Tue, 14 Feb 2012 14:31:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJPx-0006gs-Q1
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:31:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329229895!13329199!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26205 invoked from network); 14 Feb 2012 14:31:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:31:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:31:45 +0000
Message-Id: <4F3A7E540200007800072EB6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:31:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
In-Reply-To: <20120213142016.GA7108@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Feb 13, Jan Beulich wrote:
> 
>> >>> On 10.02.12 at 22:28, Olaf Hering <olaf@aepfle.de> wrote:
>> > These functions are called for dom0, but not for domU. And as a result
>> > arch.nr_vmce_banks remains zero. I assume the guest needs to be
>> > initialized in some way as well, and that does not happen?
>> 
>> Below/attached a fixed version of the patch.
> 
> I get some mismatch after migration, both hosts run the same xen binary.

Are you sure about that? I'm asking because ...

> The small debug patch I use is attached.
> 
> 
> Also: The tools do not catch the restore error so that the guest continues 
> to
> run on the source host.
> 
> Olaf
> 
> nicolai login: (XEN) vmce_init_vcpu 0 o 0 n 806
> (XEN) vmce_init_vcpu 1 o 0 n 806
> (XEN) vmce_init_vcpu 2 o 0 n 806
> (XEN) vmce_init_vcpu 3 o 0 n 806
> (XEN) save.c:62:d0 HVM restore (1): VM saved on one CPU (0x206c2) and 
> restored on another (0x10676).
> (XEN) save.c:234:d0 HVM restore: CPU 0
> (XEN) save.c:234:d0 HVM restore: CPU 1
> (XEN) save.c:234:d0 HVM restore: CPU 2
> (XEN) save.c:234:d0 HVM restore: CPU 3
> (XEN) save.c:234:d0 HVM restore: PIC 0
> (XEN) save.c:234:d0 HVM restore: PIC 1
> (XEN) save.c:234:d0 HVM restore: IOAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 1
> (XEN) save.c:234:d0 HVM restore: LAPIC 2
> (XEN) save.c:234:d0 HVM restore: LAPIC 3
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
> (XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
> (XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
> (XEN) save.c:234:d0 HVM restore: PCI_LINK 0
> (XEN) save.c:234:d0 HVM restore: PIT 0
> (XEN) save.c:234:d0 HVM restore: RTC 0
> (XEN) save.c:234:d0 HVM restore: HPET 0
> (XEN) save.c:234:d0 HVM restore: PMTIMER 0
> (XEN) save.c:234:d0 HVM restore: MTRR 0
> (XEN) save.c:234:d0 HVM restore: MTRR 1
> (XEN) save.c:234:d0 HVM restore: MTRR 2
> (XEN) save.c:234:d0 HVM restore: MTRR 3
> (XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
> (XEN) save.c:291:d0 HVM restore mismatch: expected type 18 length 8, saw type 18 length 1

... this suggests the source host was still running with the old binary
(where the save record was indeed just 1 byte in size)...

> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff82c4802c7d28 ffffffff -1 o 806 n ea
> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
> (XEN) vmce_init_vcpu 0 o 0 n 806
> (XEN) vmce_init_vcpu 1 o 0 n 806
> (XEN) vmce_init_vcpu 2 o 0 n 806
> (XEN) vmce_init_vcpu 3 o 0 n 806
> (XEN) save.c:62:d0 HVM restore (2): VM saved on one CPU (0x206c2) and 
> restored on another (0x10676).
> (XEN) save.c:234:d0 HVM restore: CPU 0
> (XEN) save.c:234:d0 HVM restore: CPU 1
> (XEN) save.c:234:d0 HVM restore: CPU 2
> (XEN) save.c:234:d0 HVM restore: CPU 3
> (XEN) save.c:234:d0 HVM restore: PIC 0
> (XEN) save.c:234:d0 HVM restore: PIC 1
> (XEN) save.c:234:d0 HVM restore: IOAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 1
> (XEN) save.c:234:d0 HVM restore: LAPIC 2
> (XEN) save.c:234:d0 HVM restore: LAPIC 3
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
> (XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
> (XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
> (XEN) save.c:234:d0 HVM restore: PCI_LINK 0
> (XEN) save.c:234:d0 HVM restore: PIT 0
> (XEN) save.c:234:d0 HVM restore: RTC 0
> (XEN) save.c:234:d0 HVM restore: HPET 0
> (XEN) save.c:234:d0 HVM restore: PMTIMER 0
> (XEN) save.c:234:d0 HVM restore: MTRR 0
> (XEN) save.c:234:d0 HVM restore: MTRR 1
> (XEN) save.c:234:d0 HVM restore: MTRR 2
> (XEN) save.c:234:d0 HVM restore: MTRR 3
> (XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
> (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 (supported: 0x800)

... whereas this one suggests that the size check passed (same binary
on both ends) but the feature sets of the hosts are different (sorry,
I can't suggest a way around this, the hosts must be sufficiently
matching in MCA features - those differences that are tolerable are
already being handled). I'm confused as to what was running on the
source host.

Let me check what bit 12 is: The latest SDM considers this reserved,
so the only way I can see how to deal with this is to switch the
setting up of g_mcg_cap from a back-listing approach to a white-listing
one.

> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0

Bottom line - it appears to work as intended considering the second
attempt.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:39:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJWs-00079J-Np; Tue, 14 Feb 2012 14:38:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJWr-00079B-In
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:38:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329230322!10636850!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12006 invoked from network); 14 Feb 2012 14:38:43 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:38:43 -0000
Received: by werb14 with SMTP id b14so28060wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:38:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RVJMq76RHaI+wF1Z5cTqKV3Zrp2qQP1M3tJUsbcRwJ0=;
	b=s2BgOf82J0WSPcBhVE2/mxnWc1mLuqtmPyvSITZFy2Nj9xrw8pt7u+/e3rSPsgq+Cj
	HjtpBBZtyLe8GXCkYDNIzkGRJKA6GhsUgwMGH5JPwvMTw4mi1ILdJJU767g7qjoMqbKI
	4eq2ECoF5RMCVJCJExRdZOSsuYitmelito0j0=
MIME-Version: 1.0
Received: by 10.180.101.228 with SMTP id fj4mr3877978wib.4.1329230322776; Tue,
	14 Feb 2012 06:38:42 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:38:42 -0800 (PST)
In-Reply-To: <1328805627.6133.232.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
	<1328805627.6133.232.camel@zakaz.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:38:42 +0100
X-Google-Sender-Auth: bZml6VoI3Tw7yW9yF0HUp4yW6BI
Message-ID: <CAPLaKK5w1voA5HSo_ULEE4iTibuL9TScEov0z+ohJgOf_dYtcA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/9 Ian Campbell <Ian.Campbell@citrix.com>:
> On Thu, 2012-02-09 at 16:18 +0000, Stefano Stabellini wrote:
>> On Thu, 9 Feb 2012, Ian Campbell wrote:
>> > On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
>> > > On Thu, 9 Feb 2012, Ian Campbell wrote:
>> > > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
>> > > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
>> > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
>> > > > > > > - we can reuse the "state" based mechanism to establish a connection:
>> > > > > > > again not a great protocol, but very well known and understood.
>> > > > > >
>> > > > > > I don't think we have, in general, a good understanding of these
>> > > > > > "state" based protocols ...
>> > > > >
>> > > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
>> > > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
>> > > >
>> > > > And no one I know is able to describe, accurately, exactly what the
>> > > > state diagram for even one of those actually looks like or indeed should
>> > > > look like. It became quite evident in these threads about hotplug script
>> > > > handling etc that no one really knows for sure what (is supposed to)
>> > > > happens when.
>> > >
>> > > I thought that most of the thread was about the interface with the block
>> > > scripts, that is an entirely different matter and completely obscure.
>> > > If I am mistaken, please point me at the right email.
>> >
>> > We are talking about reusing the existing xenbus state machine schema
>> > for a new purpose. Ian J pointed out that these are not generally well
>> > understood, you replied that it was and cited some examples. I pointed
>> > out why these were not examples of why this stuff was well understood at
>> > all, in fact quite the opposite.
>>
>> Sorry but I don't understand how these examples are supposed to be
>> "quite the opposite".
>> I quite like the idea of being able to read a single source file of less
>> than 400 LOC to understand how a protocol works
>> (drivers/input/misc/xen-kbdfront.c).
>
> That is not a protocol specification, merely one implementation of it.
> What does the BSD driver do? Is it exactly the same as Linux? Should BSD
> driver authors be expected to reverse engineer the protocol from the
> Linux code? What/who arbitrates when the two behave differently?
>
>> In fact I don't think that understanding the protocol has been an issue
>> for the GSoC student that had to write a new one.
>
> Being able to reverse engineer something which works is not proof that
> these things are "well understood" in the general case.
>
>> I think we are under influence of a "reiventing the wheel" virus.
>
> I think we are in danger of making the same mistakes again as have been
> made with the device protocols and this is what I want to avoid.
>
> Now, perhaps this style of state machine protocol is a reasonable design
> choice in this case, but since we are starting afresh here this specific
> new instance should be well documented _up_front_ not left in the "oh,
> just read the Linux code" state we have now for many of our devices
> which has lead to multiple slightly divergent implementations of the
> same basic concept.

Yes, documentation about this protocol should go in together with the
protocol itself.

>
>> > > > Justin just posted a good description for blkif.h which included a state
>> > > > machine description. We need the same for pciif.h, netif.h etc etc.
>> > >
>> > > The state machine is the same for block and network.
>> >
>> > No, it's not. This is exactly what IanJ and I are talking about.
>>
>> Could you please elaborate?
>>
>> I am sure you know that the xenstore state machine is handled the same
>> way for all the backends in QEMU (see hw/xen_backend.c).
>> And the same thing is true for the frontends and the backends in Linux.
>
> A substantial proportion of the threads about this hotplug script stuff
> has been about the fact that no one is quite sure what really happens
> when for all implementations nor what the common semantics are.
>
> e.g. How do you ask a backend to shut down (do you set it to state 5?
> state 6? do you nuke the xenstore dir?). Neither is anyone sure when the
> correct point to call the hotplug scripts actually is, or even what
> actually happens with them right now across the different backend
> drivers or kernel types.


This is true, BSD, Linux and Qemu have slightly different
implementations of the backend protocol at least, BSD and qemu-xen
doesn't react when setting backend "state" to 5 or "online" to 0. This
gave me some headaches that could be solved if this was properly
documented/implemented.

> The actual state transitions which netback and blkback go through are
> not the same: The netback protocol uses InitWait, the blkback one does
> not or is it vice-versa? I can't remember and it isn't documented. Some
> Linux frontends handled the kexec reconnect sequencing differently, by
> disconnecting or reconnecting the actual underlying devices at subtly
> different times and/or handling the transition from Closing back to Init
> or InitWait differently.

On this implementation I wait for backend to switch to state 2
(XenbusStateInitWait) before executing hotplug scripts for both vifs
and vbds, and it seems like they work ok on both Linux and NetBSD, and
again, since it's not documented anywhere, I just guess it's the
correct way to do it, but I can't be sure.

> And this is just for Linux talking to Linux.
>
> I know for sure that the Windows frontends follow a different state
> transition path to Linux (and that it has interacted badly with the
> kexec differences in the Linux backends discussed above). I bet BSD has
> some subtle differences in behaviour too.
>
> The fact is that none of our device state machine protocols are not well
> documented (although blkif.h is about to be). If this stuff were well
> understood we would already have such documentation because it would be
> trivial to write -- but it is not. If you disagree then please document
> the netif state machine protocol in the form of a patch to netif.h.
>
> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:39:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJWs-00079J-Np; Tue, 14 Feb 2012 14:38:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJWr-00079B-In
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:38:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329230322!10636850!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12006 invoked from network); 14 Feb 2012 14:38:43 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:38:43 -0000
Received: by werb14 with SMTP id b14so28060wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:38:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RVJMq76RHaI+wF1Z5cTqKV3Zrp2qQP1M3tJUsbcRwJ0=;
	b=s2BgOf82J0WSPcBhVE2/mxnWc1mLuqtmPyvSITZFy2Nj9xrw8pt7u+/e3rSPsgq+Cj
	HjtpBBZtyLe8GXCkYDNIzkGRJKA6GhsUgwMGH5JPwvMTw4mi1ILdJJU767g7qjoMqbKI
	4eq2ECoF5RMCVJCJExRdZOSsuYitmelito0j0=
MIME-Version: 1.0
Received: by 10.180.101.228 with SMTP id fj4mr3877978wib.4.1329230322776; Tue,
	14 Feb 2012 06:38:42 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:38:42 -0800 (PST)
In-Reply-To: <1328805627.6133.232.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202090959340.3196@kaball-desktop>
	<20275.58558.925282.788540@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202091529560.22056@kaball-desktop>
	<1328802555.6133.204.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091556180.22056@kaball-desktop>
	<1328803264.6133.209.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202091605580.22056@kaball-desktop>
	<1328805627.6133.232.camel@zakaz.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:38:42 +0100
X-Google-Sender-Auth: bZml6VoI3Tw7yW9yF0HUp4yW6BI
Message-ID: <CAPLaKK5w1voA5HSo_ULEE4iTibuL9TScEov0z+ohJgOf_dYtcA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/9 Ian Campbell <Ian.Campbell@citrix.com>:
> On Thu, 2012-02-09 at 16:18 +0000, Stefano Stabellini wrote:
>> On Thu, 9 Feb 2012, Ian Campbell wrote:
>> > On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
>> > > On Thu, 9 Feb 2012, Ian Campbell wrote:
>> > > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
>> > > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
>> > > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
>> > > > > > > - we can reuse the "state" based mechanism to establish a connection:
>> > > > > > > again not a great protocol, but very well known and understood.
>> > > > > >
>> > > > > > I don't think we have, in general, a good understanding of these
>> > > > > > "state" based protocols ...
>> > > > >
>> > > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
>> > > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
>> > > >
>> > > > And no one I know is able to describe, accurately, exactly what the
>> > > > state diagram for even one of those actually looks like or indeed should
>> > > > look like. It became quite evident in these threads about hotplug script
>> > > > handling etc that no one really knows for sure what (is supposed to)
>> > > > happens when.
>> > >
>> > > I thought that most of the thread was about the interface with the block
>> > > scripts, that is an entirely different matter and completely obscure.
>> > > If I am mistaken, please point me at the right email.
>> >
>> > We are talking about reusing the existing xenbus state machine schema
>> > for a new purpose. Ian J pointed out that these are not generally well
>> > understood, you replied that it was and cited some examples. I pointed
>> > out why these were not examples of why this stuff was well understood at
>> > all, in fact quite the opposite.
>>
>> Sorry but I don't understand how these examples are supposed to be
>> "quite the opposite".
>> I quite like the idea of being able to read a single source file of less
>> than 400 LOC to understand how a protocol works
>> (drivers/input/misc/xen-kbdfront.c).
>
> That is not a protocol specification, merely one implementation of it.
> What does the BSD driver do? Is it exactly the same as Linux? Should BSD
> driver authors be expected to reverse engineer the protocol from the
> Linux code? What/who arbitrates when the two behave differently?
>
>> In fact I don't think that understanding the protocol has been an issue
>> for the GSoC student that had to write a new one.
>
> Being able to reverse engineer something which works is not proof that
> these things are "well understood" in the general case.
>
>> I think we are under influence of a "reiventing the wheel" virus.
>
> I think we are in danger of making the same mistakes again as have been
> made with the device protocols and this is what I want to avoid.
>
> Now, perhaps this style of state machine protocol is a reasonable design
> choice in this case, but since we are starting afresh here this specific
> new instance should be well documented _up_front_ not left in the "oh,
> just read the Linux code" state we have now for many of our devices
> which has lead to multiple slightly divergent implementations of the
> same basic concept.

Yes, documentation about this protocol should go in together with the
protocol itself.

>
>> > > > Justin just posted a good description for blkif.h which included a state
>> > > > machine description. We need the same for pciif.h, netif.h etc etc.
>> > >
>> > > The state machine is the same for block and network.
>> >
>> > No, it's not. This is exactly what IanJ and I are talking about.
>>
>> Could you please elaborate?
>>
>> I am sure you know that the xenstore state machine is handled the same
>> way for all the backends in QEMU (see hw/xen_backend.c).
>> And the same thing is true for the frontends and the backends in Linux.
>
> A substantial proportion of the threads about this hotplug script stuff
> has been about the fact that no one is quite sure what really happens
> when for all implementations nor what the common semantics are.
>
> e.g. How do you ask a backend to shut down (do you set it to state 5?
> state 6? do you nuke the xenstore dir?). Neither is anyone sure when the
> correct point to call the hotplug scripts actually is, or even what
> actually happens with them right now across the different backend
> drivers or kernel types.


This is true, BSD, Linux and Qemu have slightly different
implementations of the backend protocol at least, BSD and qemu-xen
doesn't react when setting backend "state" to 5 or "online" to 0. This
gave me some headaches that could be solved if this was properly
documented/implemented.

> The actual state transitions which netback and blkback go through are
> not the same: The netback protocol uses InitWait, the blkback one does
> not or is it vice-versa? I can't remember and it isn't documented. Some
> Linux frontends handled the kexec reconnect sequencing differently, by
> disconnecting or reconnecting the actual underlying devices at subtly
> different times and/or handling the transition from Closing back to Init
> or InitWait differently.

On this implementation I wait for backend to switch to state 2
(XenbusStateInitWait) before executing hotplug scripts for both vifs
and vbds, and it seems like they work ok on both Linux and NetBSD, and
again, since it's not documented anywhere, I just guess it's the
correct way to do it, but I can't be sure.

> And this is just for Linux talking to Linux.
>
> I know for sure that the Windows frontends follow a different state
> transition path to Linux (and that it has interacted badly with the
> kexec differences in the Linux backends discussed above). I bet BSD has
> some subtle differences in behaviour too.
>
> The fact is that none of our device state machine protocols are not well
> documented (although blkif.h is about to be). If this stuff were well
> understood we would already have such documentation because it would be
> trivial to write -- but it is not. If you disagree then please document
> the netif state machine protocol in the form of a patch to netif.h.
>
> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJXO-0007B7-5E; Tue, 14 Feb 2012 14:39:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJXM-0007Am-Lc
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:39:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329228346!12062344!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12912 invoked from network); 14 Feb 2012 14:05:47 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:05:47 -0000
Received: by wgbdr13 with SMTP id dr13so5292746wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ImjWEJO7tIcUMQg15xYcZAyWe8aCV6d+LbCrJoEarPs=;
	b=C8ysyJfOBzF6PsSi7qU/A/xiz6ISNpqI5YjGCtH2wZX/p/PIkk7SgZcOrAVHfh7nf2
	3rlIu3inrhTVsKONEuIphnyzD4a5dRYSoAVv9DS4SOlEEUKnKq5TIW3kd43O5BAkRAkT
	m3nFRg65mrRP4rx8hnM3t2AT/SS7OgoJ8wehM=
MIME-Version: 1.0
Received: by 10.216.138.234 with SMTP id a84mr10041063wej.40.1329228345903;
	Tue, 14 Feb 2012 06:05:45 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:05:45 -0800 (PST)
In-Reply-To: <20275.59790.700273.845107@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<7de94a26474f869177ce.1328189224@debian.localdomain>
	<20275.59790.700273.845107@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:05:45 +0100
X-Google-Sender-Auth: oxBPce14sHHTpck3FVsX31iN8iM
Message-ID: <CAPLaKK5QQidU4y7gA7j1--2c_T9LnyYd68Doy44-W6NJBEABSw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/9 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/u> libxl: delegate plug/unplug of disk and nic devices to xldeviced
>>
>> Change the calls to libxl_device_<type>_<action> to
>> libxl_device_<type>_hotplug_<action> for disk and nic device types.
>> Alsoe enables hotplug script calling from libxl itself, by disabling
>> some udev rules and removing the commented code in
>> libxl__device_hotplug.
>
> Again, I don't think this is the right way to organise the change to
> this behaviour.
>
> The right thing to do is probably to change individual device types
> one at a type,

True, will refactor this.

> and to make the new functionality have the same
> libxl_device_disk_add name (etc.) as before.

I would like to keep the original libxl_device_<type>_add functions,
since they are called from xldeviced and perform the actual plug of
the device. libxl_device_<type>_hotplug_add are called from xl to
trigger the plug (pass the command to xldeviced). Probably the names
should be changed to something more descriptive of what they actually
do, I'm open to suggestion there.

How does renaming libxl_device_<type>_add to
libxl_device_<type>_plug/unplug (which will be called from xldeviced)
and libxl_device_<type>_hotplug_add to libxl_device_<type>_add, this
will mean less modifications in xl code since it will call the same
functions?

Roger.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJXO-0007B7-5E; Tue, 14 Feb 2012 14:39:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxJXM-0007Am-Lc
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:39:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329228346!12062344!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12912 invoked from network); 14 Feb 2012 14:05:47 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:05:47 -0000
Received: by wgbdr13 with SMTP id dr13so5292746wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 06:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ImjWEJO7tIcUMQg15xYcZAyWe8aCV6d+LbCrJoEarPs=;
	b=C8ysyJfOBzF6PsSi7qU/A/xiz6ISNpqI5YjGCtH2wZX/p/PIkk7SgZcOrAVHfh7nf2
	3rlIu3inrhTVsKONEuIphnyzD4a5dRYSoAVv9DS4SOlEEUKnKq5TIW3kd43O5BAkRAkT
	m3nFRg65mrRP4rx8hnM3t2AT/SS7OgoJ8wehM=
MIME-Version: 1.0
Received: by 10.216.138.234 with SMTP id a84mr10041063wej.40.1329228345903;
	Tue, 14 Feb 2012 06:05:45 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 14 Feb 2012 06:05:45 -0800 (PST)
In-Reply-To: <20275.59790.700273.845107@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<7de94a26474f869177ce.1328189224@debian.localdomain>
	<20275.59790.700273.845107@mariner.uk.xensource.com>
Date: Tue, 14 Feb 2012 15:05:45 +0100
X-Google-Sender-Auth: oxBPce14sHHTpck3FVsX31iN8iM
Message-ID: <CAPLaKK5QQidU4y7gA7j1--2c_T9LnyYd68Doy44-W6NJBEABSw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/9 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/u> libxl: delegate plug/unplug of disk and nic devices to xldeviced
>>
>> Change the calls to libxl_device_<type>_<action> to
>> libxl_device_<type>_hotplug_<action> for disk and nic device types.
>> Alsoe enables hotplug script calling from libxl itself, by disabling
>> some udev rules and removing the commented code in
>> libxl__device_hotplug.
>
> Again, I don't think this is the right way to organise the change to
> this behaviour.
>
> The right thing to do is probably to change individual device types
> one at a type,

True, will refactor this.

> and to make the new functionality have the same
> libxl_device_disk_add name (etc.) as before.

I would like to keep the original libxl_device_<type>_add functions,
since they are called from xldeviced and perform the actual plug of
the device. libxl_device_<type>_hotplug_add are called from xl to
trigger the plug (pass the command to xldeviced). Probably the names
should be changed to something more descriptive of what they actually
do, I'm open to suggestion there.

How does renaming libxl_device_<type>_add to
libxl_device_<type>_plug/unplug (which will be called from xldeviced)
and libxl_device_<type>_hotplug_add to libxl_device_<type>_add, this
will mean less modifications in xl code since it will call the same
functions?

Roger.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:43:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJbY-0007PO-RT; Tue, 14 Feb 2012 14:43:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJbW-0007P9-VR
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:43:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329230612!13333478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24548 invoked from network); 14 Feb 2012 14:43:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:43:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10688396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:43:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 14:43:32 +0000
Message-ID: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 14:43:31 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Defines a few stubs and disables some as yet unsupported core features.

Early on there's a couple of unrelated cleanups.

Patch against current unstable. #6 and #9 touch common code.

Changes since v1:
 - make PoD stubs proper functions instead of #defines
 - define need_iommu as 0 instead of littering common code with #if
 - stub donate_page but leave tmem enabled.
 - rebased against latest unstable tree

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:43:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJbY-0007PO-RT; Tue, 14 Feb 2012 14:43:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJbW-0007P9-VR
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:43:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329230612!13333478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24548 invoked from network); 14 Feb 2012 14:43:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:43:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10688396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:43:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 14:43:32 +0000
Message-ID: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 14:43:31 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Defines a few stubs and disables some as yet unsupported core features.

Early on there's a couple of unrelated cleanups.

Patch against current unstable. #6 and #9 touch common code.

Changes since v1:
 - make PoD stubs proper functions instead of #defines
 - define need_iommu as 0 instead of littering common code with #if
 - stub donate_page but leave tmem enabled.
 - rebased against latest unstable tree

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:43:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJbb-0007Pi-7o; Tue, 14 Feb 2012 14:43:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJbZ-0007PD-Vi
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:43:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329230615!13123701!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2527 invoked from network); 14 Feb 2012 14:43:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:43:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:43:50 +0000
Message-Id: <4F3A81250200007800072EBE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:43:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
In-Reply-To: <20120213142016.GA7108@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6B451305.3__="
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6B451305.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n =
1809
> (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for =
d2:v0=20
> (supported: 0x800)
> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0

Attached an updated patch that sets up g_mcg_cap using a white-listing
bit mask, as mentioned in the previous response.

Note that this takes -unstable c/s 24781:6ae5506e49ab as prerequisite.

Jan


--=__Part6B451305.3__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

This requires setting up g_mcg_cap using a white-listing bit mask.=0A=0ASho=
uld we also save/restore MCG_CTL and MCi_CTL?=0A=0A--- a/tools/libxc/xc_dom=
ain_save.c=0A+++ b/tools/libxc/xc_domain_save.c=0A@@ -1879,6 +1879,7 @@ =
int xc_domain_save(xc_interface *xch, in=0A =0A         domctl.cmd =3D =
XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =3D dom;=0A+      =
  memset(&domctl.u, 0, sizeof(domctl.u));=0A         domctl.u.ext_vcpuconte=
xt.vcpu =3D i;=0A         if ( xc_domctl(xch, &domctl) < 0 )=0A         =
{=0A--- a/tools/misc/xen-hvmctx.c=0A+++ b/tools/misc/xen-hvmctx.c=0A@@ =
-383,6 +383,13 @@ static void dump_viridian_vcpu(void)=0A            =
(unsigned long long) p.apic_assist);           =0A }=0A =0A+static void =
dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMCE_VCPU) p;=0A+    =
READ(p);=0A+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);=0A+}=
=0A+=0A int main(int argc, char **argv)=0A {=0A     int entry, domid;=0A@@ =
-449,6 +456,7 @@ int main(int argc, char **argv)=0A         case HVM_SAVE_C=
ODE(MTRR): dump_mtrr(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_DOMAI=
N): dump_viridian_domain(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_V=
CPU): dump_viridian_vcpu(); break;=0A+        case HVM_SAVE_CODE(VMCE_VCPU)=
: dump_vmce_vcpu(); break;=0A         case HVM_SAVE_CODE(END): break;=0A   =
      default:=0A             printf(" ** Don't understand type %u: =
skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.h=0A+++ b/xen/arch/x86/cpu=
/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define _MCE_H=0A =0A #include =
<xen/init.h>=0A+#include <xen/sched.h>=0A #include <xen/smp.h>=0A #include =
<asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 +55,8 @@ int unmmap_brok=
en_page(struct domain *d,=0A u64 mce_cap_init(void);=0A extern unsigned =
int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);=0A-=
int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int intel_mce_rdmsr(con=
st struct vcpu *, uint32_t msr, uint64_t *val);=0A+int intel_mce_wrmsr(stru=
ct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct mcinfo_extended =
*intel_get_extended_msrs(=0A     struct mcinfo_global *mig, struct mc_info =
*mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban=0A =
=0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =0A-static inline int =
mce_vendor_bank_msr(uint32_t msr)=0A+static inline int mce_vendor_bank_msr(=
const struct vcpu *v, uint32_t msr)=0A {=0A     if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D MSR_IA32_MC0_CTL2 && =
msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+         msr >=3D MSR_IA32_MC=
0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COU=
NT) )=0A           return 1;=0A     return 0;=0A }=0A =0A-static inline =
int mce_bank_msr(uint32_t msr)=0A+static inline int mce_bank_msr(const =
struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr >=3D MSR_IA32_MC0_CTL =
&& msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-        mce_vendor_bank_msr(=
msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+          msr < =
MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||=0A+         =
mce_vendor_bank_msr(v, msr) )=0A         return 1;=0A     return 0;=0A =
}=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cpu/mche=
ck/mce_intel.c=0A@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init=
(struc=0A }=0A =0A /* intel specific MCA MSR */=0A-int intel_mce_wrmsr(uint=
32_t msr, uint64_t val)=0A+int intel_mce_wrmsr(struct vcpu *v, uint32_t =
msr, uint64_t val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
write this MSR!\n");=0A@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t=
 msr, uint64=0A     return ret;=0A }=0A =0A-int intel_mce_rdmsr(uint32_t =
msr, uint64_t *val)=0A+int intel_mce_rdmsr(const struct vcpu *v, uint32_t =
msr, uint64_t *val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch=
/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A #include <xen/delay.h>=0A =
#include <xen/smp.h>=0A #include <xen/mm.h>=0A+#include <xen/hvm/save.h>=0A=
 #include <asm/processor.h>=0A #include <public/sysctl.h>=0A #include =
<asm/system.h>=0A@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)=0A  =
          nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));=0A =0A     =
dom_vmce(d)->mcg_status =3D 0x0;=0A-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;=
=0A     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;=0A     dom_vmce(d)->nr_inj=
ection =3D 0;=0A =0A@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct =
domain *d)=0A     dom_vmce(d) =3D NULL;=0A }=0A =0A-static int bank_mce_rdm=
sr(struct domain *d, uint32_t msr, uint64_t *val)=0A+void vmce_init_vcpu(st=
ruct vcpu *v)=0A {=0A-    int bank, ret =3D 1;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    v->arch.mcg_cap =3D g_mcg_cap;=0A+}=0A+=0A+=
int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)=0A+{=0A+    if ( caps =
& ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )=0A+    {=0A+        dprintk(XE=
NLOG_G_ERR, "%s restore: unsupported MCA capabilities"=0A+                =
" %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",=0A+                =
is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=0A+             =
   v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);=0A+        return -EPERM;=0A+  =
  }=0A+=0A+    v->arch.mcg_cap =3D caps;=0A+    return 0;=0A+}=0A+=0A+stati=
c int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)=0A+{=0A+    int ret =3D 1;=0A+    unsigned int bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->=
domain);=0A     struct bank_entry *entry;=0A =0A-    bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        =
return -1;=0A+    *val =3D 0;=0A =0A     switch ( msr & (MSR_IA32_MC0_CTL =
| 3) )=0A     {=0A     case MSR_IA32_MC0_CTL:=0A-        *val =3D =
vmce->mci_ctl[bank] &=0A-            (h_mci_ctrl ? h_mci_ctrl[bank] : =
~0UL);=0A+        if ( bank < nr_mce_banks )=0A+            *val =3D =
vmce->mci_ctl[bank] &=0A+                   (h_mci_ctrl ? h_mci_ctrl[bank] =
: ~0UL);=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64=
"\n",=0A                    bank, *val);=0A         break;=0A@@ -126,7 =
+146,7 @@ static int bank_mce_rdmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_rdmsr(msr, val);=0A+            ret =3D =
intel_mce_rdmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(st=
ruct domain =0A  */=0A int vmce_rdmsr(uint32_t msr, uint64_t *val)=0A =
{=0A-    struct domain *d =3D current->domain;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    const struct vcpu *cur =3D current;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=0A     int ret =3D =
1;=0A =0A     *val =3D 0;=0A =0A-    spin_lock(&dom_vmce(d)->lock);=0A+    =
spin_lock(&vmce->lock);=0A =0A     switch ( msr )=0A     {=0A@@ -162,39 =
+182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A                     =
   "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);=0A         break;=0A     =
case MSR_IA32_MCG_CAP:=0A-        *val =3D vmce->mcg_cap;=0A+        *val =
=3D cur->arch.mcg_cap;=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr =
MCG_CAP 0x%"PRIx64"\n",=0A                    *val);=0A         break;=0A  =
   case MSR_IA32_MCG_CTL:=0A         /* Always 0 if no CTL support */=0A-  =
      *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A+        if ( cur->arch.mcg_cap=
 & MCG_CTL_P )=0A+            *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A       =
  mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",=0A           =
         *val);=0A         break;=0A     default:=0A-        ret =3D =
mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;=0A+        ret =3D =
mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;=0A         =
break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(d)->lock);=0A+    =
spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =0A-static int =
bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static int bank_mce_w=
rmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return -EINVAL;=0A-=0A  =
   switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case MSR_IA32_MC=
0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        if ( bank < =
nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A         =
break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the first entry =
of the list, it corresponds to current=0A@@ -202,9 +221,9 @@ static int =
bank_mce_wrmsr(struct domain =0A          * the guest, this node will be =
deleted.=0A          * Only error bank is written. Non-error banks simply =
return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d)->impact_hea=
der) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A         =
{=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.next,=0A+ =
           entry =3D list_entry(vmce->impact_header.next,=0A               =
                 struct bank_entry, list);=0A             if ( entry->bank =
=3D=3D bank )=0A                 entry->mci_status =3D val;=0A@@ -228,7 =
+247,7 @@ static int bank_mce_wrmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+            ret =3D =
intel_mce_wrmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(stru=
ct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 val)=0A {=0A-    struct =
domain *d =3D current->domain;=0A+    struct vcpu *cur =3D current;=0A     =
struct bank_entry *entry =3D NULL;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=
=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap )=0A@@ -266,7 +285,7 @@ =
int vmce_wrmsr(u32 msr, u64 val)=0A         vmce->mcg_status =3D val;=0A   =
      mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);=0A         /* For HVM guest, this is the point for deleting vMCE =
injection node */=0A-        if ( d->is_hvm && (vmce->nr_injection > 0) =
)=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )=0A        =
 {=0A             vmce->nr_injection--; /* Should be 0 */=0A             =
if ( !list_empty(&vmce->impact_header) )=0A@@ -293,7 +312,7 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D -1;=0A         break;=0A   =
  default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A@@ -301,6 +320,46 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A     return ret;=0A }=0A =0A+static int =
vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)=0A+{=0A+    =
struct vcpu *v;=0A+    int err =3D 0;=0A+=0A+    for_each_vcpu( d, v ) =
{=0A+        struct hvm_vmce_vcpu ctxt =3D {=0A+            .caps =3D =
v->arch.mcg_cap=0A+        };=0A+=0A+        err =3D hvm_save_entry(VMCE_VC=
PU, v->vcpu_id, h, &ctxt);=0A+        if ( err )=0A+            break;=0A+ =
   }=0A+=0A+    return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(stru=
ct domain *d, hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D =
hvm_load_instance(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu =
ctxt;=0A+    int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A+    {=0A+        dprintk(XENLOG_G_ERR, =
"HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_id, =
vcpuid);=0A+        err =3D -EINVAL;=0A+    }=0A+    else=0A+        err =
=3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+=0A+    return err ?: =
vmce_restore_vcpu(v, ctxt.caps);=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE=
_VCPU, vmce_save_vcpu_ctxt,=0A+                          vmce_load_vcpu_ctx=
t, 1, HVMSR_PER_VCPU);=0A+=0A int inject_vmce(struct domain *d)=0A {=0A    =
 int cpu =3D smp_processor_id();=0A@@ -457,7 +516,7 @@ int vmce_init(struct=
 cpuinfo_x86 *c)=0A =0A     rdmsrl(MSR_IA32_MCG_CAP, value);=0A     /* For =
Guest vMCE usage */=0A-    g_mcg_cap =3D value & ~MCG_CMCI_P;=0A+    =
g_mcg_cap =3D value & (MCG_CAP_COUNT | MCG_CTL_P | MCG_TES_P | MCG_SER_P);=
=0A     if (value & MCG_CTL_P)=0A         rdmsrl(MSR_IA32_MCG_CTL, =
h_mcg_ctl);=0A =0A--- a/xen/arch/x86/cpu/mcheck/x86_mca.h=0A+++ b/xen/arch/=
x86/cpu/mcheck/x86_mca.h=0A@@ -30,12 +30,13 @@=0A =0A =0A /* Bitfield of =
the MSR_IA32_MCG_CAP register */=0A-#define MCG_SER_P               =
(1UL<<24)=0A #define MCG_CAP_COUNT           0x00000000000000ffULL=0A-#defi=
ne MCG_CTL_P               0x0000000000000100ULL=0A-#define MCG_EXT_P		=
(1UL<<9)=0A-#define MCG_EXT_CNT		(16)=0A-#define MCG_CMCI_P		=
(1UL<<10)=0A+#define MCG_CTL_P               (1ULL<<8)=0A+#define =
MCG_EXT_P               (1ULL<<9)=0A+#define MCG_CMCI_P              =
(1ULL<<10)=0A+#define MCG_TES_P               (1ULL<<11)=0A+#define =
MCG_EXT_CNT             16=0A+#define MCG_SER_P               (1ULL<<24)=0A=
 /* Other bits are reserved */=0A =0A /* Bitfield of the MSR_IA32_MCG_STATU=
S register */=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=
=0A@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)=0A     if ( (rc =
=3D vcpu_init_fpu(v)) !=3D 0 )=0A         return rc;=0A =0A+    vmce_init_v=
cpu(v);=0A+=0A     if ( is_hvm_domain(d) )=0A     {=0A         rc =3D =
hvm_vcpu_initialise(v);=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/=
domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domctl(=0A                 =
evc->syscall32_callback_eip    =3D 0;=0A                 evc->syscall32_dis=
ables_events =3D 0;=0A             }=0A+            evc->mcg_cap =3D =
v->arch.mcg_cap;=0A         }=0A         else=0A         {=0A             =
ret =3D -EINVAL;=0A-            if ( evc->size !=3D sizeof(*evc) )=0A+     =
       if ( evc->size < offsetof(typeof(*evc), mcg_cap) )=0A               =
  goto ext_vcpucontext_out;=0A #ifdef __x86_64__=0A             if ( =
!is_hvm_domain(d) )=0A@@ -1059,6 +1060,10 @@ long arch_do_domctl(=0A       =
           (evc->syscall32_callback_cs & ~3) ||=0A                  =
evc->syscall32_callback_eip )=0A                 goto ext_vcpucontext_out;=
=0A+=0A+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) =
+=0A+                              sizeof(evc->mcg_cap) )=0A+              =
  ret =3D vmce_restore_vcpu(v, evc->mcg_cap);=0A         }=0A =0A         =
ret =3D 0;=0A--- a/xen/include/asm-x86/domain.h=0A+++ b/xen/include/asm-x86=
/domain.h=0A@@ -488,6 +488,8 @@ struct arch_vcpu=0A     /* This variable =
determines whether nonlazy extended state has been used,=0A      * and =
thus should be saved/restored. */=0A     bool_t nonlazy_xstate_used;=0A+=0A=
+    uint64_t mcg_cap;=0A     =0A     struct paging_vcpu paging;=0A =0A--- =
a/xen/include/asm-x86/mce.h=0A+++ b/xen/include/asm-x86/mce.h=0A@@ -16,7 =
+16,6 @@ struct bank_entry {=0A struct domain_mca_msrs=0A {=0A     /* =
Guest should not change below values after DOM boot up */=0A-    uint64_t =
mcg_cap;=0A     uint64_t mcg_ctl;=0A     uint64_t mcg_status;=0A     =
uint64_t *mci_ctl;=0A@@ -28,6 +27,8 @@ struct domain_mca_msrs=0A /* Guest =
vMCE MSRs virtualization */=0A extern int vmce_init_msr(struct domain =
*d);=0A extern void vmce_destroy_msr(struct domain *d);=0A+extern void =
vmce_init_vcpu(struct vcpu *);=0A+extern int vmce_restore_vcpu(struct vcpu =
*, uint64_t caps);=0A extern int vmce_wrmsr(uint32_t msr, uint64_t =
val);=0A extern int vmce_rdmsr(uint32_t msr, uint64_t *val);=0A =0A--- =
a/xen/include/public/arch-x86/hvm/save.h=0A+++ b/xen/include/public/arch-x8=
6/hvm/save.h=0A@@ -575,9 +575,15 @@ struct hvm_viridian_vcpu_context {=0A =
=0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_conte=
xt);=0A =0A+struct hvm_vmce_vcpu {=0A+    uint64_t caps;=0A+};=0A+=0A+DECLA=
RE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);=0A+=0A /* =0A  * =
Largest type-code in use=0A  */=0A-#define HVM_SAVE_CODE_MAX 17=0A+#define =
HVM_SAVE_CODE_MAX 18=0A =0A #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ =
*/=0A--- a/xen/include/public/domctl.h=0A+++ b/xen/include/public/domctl.h=
=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {=0A     uint32_t =
        vcpu;=0A     /*=0A      * SET: Size of struct (IN)=0A-     * GET: =
Size of struct (OUT)=0A+     * GET: Size of struct (OUT, up to 128 =
bytes)=0A      */=0A     uint32_t         size;=0A #if defined(__i386__) =
|| defined(__x86_64__)=0A@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucont=
ext {=0A     uint16_t         sysenter_callback_cs;=0A     uint8_t         =
 syscall32_disables_events;=0A     uint8_t          sysenter_disables_event=
s;=0A+    uint64_aligned_t mcg_cap;=0A #endif=0A };=0A typedef struct =
xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;=0A
--=__Part6B451305.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part6B451305.3__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:43:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJbb-0007Pi-7o; Tue, 14 Feb 2012 14:43:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJbZ-0007PD-Vi
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:43:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329230615!13123701!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2527 invoked from network); 14 Feb 2012 14:43:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:43:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:43:50 +0000
Message-Id: <4F3A81250200007800072EBE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:43:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
In-Reply-To: <20120213142016.GA7108@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6B451305.3__="
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6B451305.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n =
1809
> (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for =
d2:v0=20
> (supported: 0x800)
> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0

Attached an updated patch that sets up g_mcg_cap using a white-listing
bit mask, as mentioned in the previous response.

Note that this takes -unstable c/s 24781:6ae5506e49ab as prerequisite.

Jan


--=__Part6B451305.3__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

This requires setting up g_mcg_cap using a white-listing bit mask.=0A=0ASho=
uld we also save/restore MCG_CTL and MCi_CTL?=0A=0A--- a/tools/libxc/xc_dom=
ain_save.c=0A+++ b/tools/libxc/xc_domain_save.c=0A@@ -1879,6 +1879,7 @@ =
int xc_domain_save(xc_interface *xch, in=0A =0A         domctl.cmd =3D =
XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =3D dom;=0A+      =
  memset(&domctl.u, 0, sizeof(domctl.u));=0A         domctl.u.ext_vcpuconte=
xt.vcpu =3D i;=0A         if ( xc_domctl(xch, &domctl) < 0 )=0A         =
{=0A--- a/tools/misc/xen-hvmctx.c=0A+++ b/tools/misc/xen-hvmctx.c=0A@@ =
-383,6 +383,13 @@ static void dump_viridian_vcpu(void)=0A            =
(unsigned long long) p.apic_assist);           =0A }=0A =0A+static void =
dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMCE_VCPU) p;=0A+    =
READ(p);=0A+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);=0A+}=
=0A+=0A int main(int argc, char **argv)=0A {=0A     int entry, domid;=0A@@ =
-449,6 +456,7 @@ int main(int argc, char **argv)=0A         case HVM_SAVE_C=
ODE(MTRR): dump_mtrr(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_DOMAI=
N): dump_viridian_domain(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_V=
CPU): dump_viridian_vcpu(); break;=0A+        case HVM_SAVE_CODE(VMCE_VCPU)=
: dump_vmce_vcpu(); break;=0A         case HVM_SAVE_CODE(END): break;=0A   =
      default:=0A             printf(" ** Don't understand type %u: =
skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.h=0A+++ b/xen/arch/x86/cpu=
/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define _MCE_H=0A =0A #include =
<xen/init.h>=0A+#include <xen/sched.h>=0A #include <xen/smp.h>=0A #include =
<asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 +55,8 @@ int unmmap_brok=
en_page(struct domain *d,=0A u64 mce_cap_init(void);=0A extern unsigned =
int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);=0A-=
int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int intel_mce_rdmsr(con=
st struct vcpu *, uint32_t msr, uint64_t *val);=0A+int intel_mce_wrmsr(stru=
ct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct mcinfo_extended =
*intel_get_extended_msrs(=0A     struct mcinfo_global *mig, struct mc_info =
*mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban=0A =
=0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =0A-static inline int =
mce_vendor_bank_msr(uint32_t msr)=0A+static inline int mce_vendor_bank_msr(=
const struct vcpu *v, uint32_t msr)=0A {=0A     if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D MSR_IA32_MC0_CTL2 && =
msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+         msr >=3D MSR_IA32_MC=
0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COU=
NT) )=0A           return 1;=0A     return 0;=0A }=0A =0A-static inline =
int mce_bank_msr(uint32_t msr)=0A+static inline int mce_bank_msr(const =
struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr >=3D MSR_IA32_MC0_CTL =
&& msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-        mce_vendor_bank_msr(=
msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+          msr < =
MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||=0A+         =
mce_vendor_bank_msr(v, msr) )=0A         return 1;=0A     return 0;=0A =
}=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cpu/mche=
ck/mce_intel.c=0A@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init=
(struc=0A }=0A =0A /* intel specific MCA MSR */=0A-int intel_mce_wrmsr(uint=
32_t msr, uint64_t val)=0A+int intel_mce_wrmsr(struct vcpu *v, uint32_t =
msr, uint64_t val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
write this MSR!\n");=0A@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t=
 msr, uint64=0A     return ret;=0A }=0A =0A-int intel_mce_rdmsr(uint32_t =
msr, uint64_t *val)=0A+int intel_mce_rdmsr(const struct vcpu *v, uint32_t =
msr, uint64_t *val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch=
/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A #include <xen/delay.h>=0A =
#include <xen/smp.h>=0A #include <xen/mm.h>=0A+#include <xen/hvm/save.h>=0A=
 #include <asm/processor.h>=0A #include <public/sysctl.h>=0A #include =
<asm/system.h>=0A@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)=0A  =
          nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));=0A =0A     =
dom_vmce(d)->mcg_status =3D 0x0;=0A-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;=
=0A     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;=0A     dom_vmce(d)->nr_inj=
ection =3D 0;=0A =0A@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct =
domain *d)=0A     dom_vmce(d) =3D NULL;=0A }=0A =0A-static int bank_mce_rdm=
sr(struct domain *d, uint32_t msr, uint64_t *val)=0A+void vmce_init_vcpu(st=
ruct vcpu *v)=0A {=0A-    int bank, ret =3D 1;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    v->arch.mcg_cap =3D g_mcg_cap;=0A+}=0A+=0A+=
int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)=0A+{=0A+    if ( caps =
& ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )=0A+    {=0A+        dprintk(XE=
NLOG_G_ERR, "%s restore: unsupported MCA capabilities"=0A+                =
" %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",=0A+                =
is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=0A+             =
   v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);=0A+        return -EPERM;=0A+  =
  }=0A+=0A+    v->arch.mcg_cap =3D caps;=0A+    return 0;=0A+}=0A+=0A+stati=
c int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)=0A+{=0A+    int ret =3D 1;=0A+    unsigned int bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->=
domain);=0A     struct bank_entry *entry;=0A =0A-    bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        =
return -1;=0A+    *val =3D 0;=0A =0A     switch ( msr & (MSR_IA32_MC0_CTL =
| 3) )=0A     {=0A     case MSR_IA32_MC0_CTL:=0A-        *val =3D =
vmce->mci_ctl[bank] &=0A-            (h_mci_ctrl ? h_mci_ctrl[bank] : =
~0UL);=0A+        if ( bank < nr_mce_banks )=0A+            *val =3D =
vmce->mci_ctl[bank] &=0A+                   (h_mci_ctrl ? h_mci_ctrl[bank] =
: ~0UL);=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64=
"\n",=0A                    bank, *val);=0A         break;=0A@@ -126,7 =
+146,7 @@ static int bank_mce_rdmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_rdmsr(msr, val);=0A+            ret =3D =
intel_mce_rdmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(st=
ruct domain =0A  */=0A int vmce_rdmsr(uint32_t msr, uint64_t *val)=0A =
{=0A-    struct domain *d =3D current->domain;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    const struct vcpu *cur =3D current;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=0A     int ret =3D =
1;=0A =0A     *val =3D 0;=0A =0A-    spin_lock(&dom_vmce(d)->lock);=0A+    =
spin_lock(&vmce->lock);=0A =0A     switch ( msr )=0A     {=0A@@ -162,39 =
+182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A                     =
   "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);=0A         break;=0A     =
case MSR_IA32_MCG_CAP:=0A-        *val =3D vmce->mcg_cap;=0A+        *val =
=3D cur->arch.mcg_cap;=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr =
MCG_CAP 0x%"PRIx64"\n",=0A                    *val);=0A         break;=0A  =
   case MSR_IA32_MCG_CTL:=0A         /* Always 0 if no CTL support */=0A-  =
      *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A+        if ( cur->arch.mcg_cap=
 & MCG_CTL_P )=0A+            *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A       =
  mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",=0A           =
         *val);=0A         break;=0A     default:=0A-        ret =3D =
mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;=0A+        ret =3D =
mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;=0A         =
break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(d)->lock);=0A+    =
spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =0A-static int =
bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static int bank_mce_w=
rmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return -EINVAL;=0A-=0A  =
   switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case MSR_IA32_MC=
0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        if ( bank < =
nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A         =
break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the first entry =
of the list, it corresponds to current=0A@@ -202,9 +221,9 @@ static int =
bank_mce_wrmsr(struct domain =0A          * the guest, this node will be =
deleted.=0A          * Only error bank is written. Non-error banks simply =
return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d)->impact_hea=
der) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A         =
{=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.next,=0A+ =
           entry =3D list_entry(vmce->impact_header.next,=0A               =
                 struct bank_entry, list);=0A             if ( entry->bank =
=3D=3D bank )=0A                 entry->mci_status =3D val;=0A@@ -228,7 =
+247,7 @@ static int bank_mce_wrmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+            ret =3D =
intel_mce_wrmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(stru=
ct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 val)=0A {=0A-    struct =
domain *d =3D current->domain;=0A+    struct vcpu *cur =3D current;=0A     =
struct bank_entry *entry =3D NULL;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=
=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap )=0A@@ -266,7 +285,7 @@ =
int vmce_wrmsr(u32 msr, u64 val)=0A         vmce->mcg_status =3D val;=0A   =
      mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);=0A         /* For HVM guest, this is the point for deleting vMCE =
injection node */=0A-        if ( d->is_hvm && (vmce->nr_injection > 0) =
)=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )=0A        =
 {=0A             vmce->nr_injection--; /* Should be 0 */=0A             =
if ( !list_empty(&vmce->impact_header) )=0A@@ -293,7 +312,7 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D -1;=0A         break;=0A   =
  default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A@@ -301,6 +320,46 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A     return ret;=0A }=0A =0A+static int =
vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)=0A+{=0A+    =
struct vcpu *v;=0A+    int err =3D 0;=0A+=0A+    for_each_vcpu( d, v ) =
{=0A+        struct hvm_vmce_vcpu ctxt =3D {=0A+            .caps =3D =
v->arch.mcg_cap=0A+        };=0A+=0A+        err =3D hvm_save_entry(VMCE_VC=
PU, v->vcpu_id, h, &ctxt);=0A+        if ( err )=0A+            break;=0A+ =
   }=0A+=0A+    return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(stru=
ct domain *d, hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D =
hvm_load_instance(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu =
ctxt;=0A+    int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A+    {=0A+        dprintk(XENLOG_G_ERR, =
"HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_id, =
vcpuid);=0A+        err =3D -EINVAL;=0A+    }=0A+    else=0A+        err =
=3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+=0A+    return err ?: =
vmce_restore_vcpu(v, ctxt.caps);=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE=
_VCPU, vmce_save_vcpu_ctxt,=0A+                          vmce_load_vcpu_ctx=
t, 1, HVMSR_PER_VCPU);=0A+=0A int inject_vmce(struct domain *d)=0A {=0A    =
 int cpu =3D smp_processor_id();=0A@@ -457,7 +516,7 @@ int vmce_init(struct=
 cpuinfo_x86 *c)=0A =0A     rdmsrl(MSR_IA32_MCG_CAP, value);=0A     /* For =
Guest vMCE usage */=0A-    g_mcg_cap =3D value & ~MCG_CMCI_P;=0A+    =
g_mcg_cap =3D value & (MCG_CAP_COUNT | MCG_CTL_P | MCG_TES_P | MCG_SER_P);=
=0A     if (value & MCG_CTL_P)=0A         rdmsrl(MSR_IA32_MCG_CTL, =
h_mcg_ctl);=0A =0A--- a/xen/arch/x86/cpu/mcheck/x86_mca.h=0A+++ b/xen/arch/=
x86/cpu/mcheck/x86_mca.h=0A@@ -30,12 +30,13 @@=0A =0A =0A /* Bitfield of =
the MSR_IA32_MCG_CAP register */=0A-#define MCG_SER_P               =
(1UL<<24)=0A #define MCG_CAP_COUNT           0x00000000000000ffULL=0A-#defi=
ne MCG_CTL_P               0x0000000000000100ULL=0A-#define MCG_EXT_P		=
(1UL<<9)=0A-#define MCG_EXT_CNT		(16)=0A-#define MCG_CMCI_P		=
(1UL<<10)=0A+#define MCG_CTL_P               (1ULL<<8)=0A+#define =
MCG_EXT_P               (1ULL<<9)=0A+#define MCG_CMCI_P              =
(1ULL<<10)=0A+#define MCG_TES_P               (1ULL<<11)=0A+#define =
MCG_EXT_CNT             16=0A+#define MCG_SER_P               (1ULL<<24)=0A=
 /* Other bits are reserved */=0A =0A /* Bitfield of the MSR_IA32_MCG_STATU=
S register */=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=
=0A@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)=0A     if ( (rc =
=3D vcpu_init_fpu(v)) !=3D 0 )=0A         return rc;=0A =0A+    vmce_init_v=
cpu(v);=0A+=0A     if ( is_hvm_domain(d) )=0A     {=0A         rc =3D =
hvm_vcpu_initialise(v);=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/=
domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domctl(=0A                 =
evc->syscall32_callback_eip    =3D 0;=0A                 evc->syscall32_dis=
ables_events =3D 0;=0A             }=0A+            evc->mcg_cap =3D =
v->arch.mcg_cap;=0A         }=0A         else=0A         {=0A             =
ret =3D -EINVAL;=0A-            if ( evc->size !=3D sizeof(*evc) )=0A+     =
       if ( evc->size < offsetof(typeof(*evc), mcg_cap) )=0A               =
  goto ext_vcpucontext_out;=0A #ifdef __x86_64__=0A             if ( =
!is_hvm_domain(d) )=0A@@ -1059,6 +1060,10 @@ long arch_do_domctl(=0A       =
           (evc->syscall32_callback_cs & ~3) ||=0A                  =
evc->syscall32_callback_eip )=0A                 goto ext_vcpucontext_out;=
=0A+=0A+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) =
+=0A+                              sizeof(evc->mcg_cap) )=0A+              =
  ret =3D vmce_restore_vcpu(v, evc->mcg_cap);=0A         }=0A =0A         =
ret =3D 0;=0A--- a/xen/include/asm-x86/domain.h=0A+++ b/xen/include/asm-x86=
/domain.h=0A@@ -488,6 +488,8 @@ struct arch_vcpu=0A     /* This variable =
determines whether nonlazy extended state has been used,=0A      * and =
thus should be saved/restored. */=0A     bool_t nonlazy_xstate_used;=0A+=0A=
+    uint64_t mcg_cap;=0A     =0A     struct paging_vcpu paging;=0A =0A--- =
a/xen/include/asm-x86/mce.h=0A+++ b/xen/include/asm-x86/mce.h=0A@@ -16,7 =
+16,6 @@ struct bank_entry {=0A struct domain_mca_msrs=0A {=0A     /* =
Guest should not change below values after DOM boot up */=0A-    uint64_t =
mcg_cap;=0A     uint64_t mcg_ctl;=0A     uint64_t mcg_status;=0A     =
uint64_t *mci_ctl;=0A@@ -28,6 +27,8 @@ struct domain_mca_msrs=0A /* Guest =
vMCE MSRs virtualization */=0A extern int vmce_init_msr(struct domain =
*d);=0A extern void vmce_destroy_msr(struct domain *d);=0A+extern void =
vmce_init_vcpu(struct vcpu *);=0A+extern int vmce_restore_vcpu(struct vcpu =
*, uint64_t caps);=0A extern int vmce_wrmsr(uint32_t msr, uint64_t =
val);=0A extern int vmce_rdmsr(uint32_t msr, uint64_t *val);=0A =0A--- =
a/xen/include/public/arch-x86/hvm/save.h=0A+++ b/xen/include/public/arch-x8=
6/hvm/save.h=0A@@ -575,9 +575,15 @@ struct hvm_viridian_vcpu_context {=0A =
=0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_conte=
xt);=0A =0A+struct hvm_vmce_vcpu {=0A+    uint64_t caps;=0A+};=0A+=0A+DECLA=
RE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);=0A+=0A /* =0A  * =
Largest type-code in use=0A  */=0A-#define HVM_SAVE_CODE_MAX 17=0A+#define =
HVM_SAVE_CODE_MAX 18=0A =0A #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ =
*/=0A--- a/xen/include/public/domctl.h=0A+++ b/xen/include/public/domctl.h=
=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {=0A     uint32_t =
        vcpu;=0A     /*=0A      * SET: Size of struct (IN)=0A-     * GET: =
Size of struct (OUT)=0A+     * GET: Size of struct (OUT, up to 128 =
bytes)=0A      */=0A     uint32_t         size;=0A #if defined(__i386__) =
|| defined(__x86_64__)=0A@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucont=
ext {=0A     uint16_t         sysenter_callback_cs;=0A     uint8_t         =
 syscall32_disables_events;=0A     uint8_t          sysenter_disables_event=
s;=0A+    uint64_aligned_t mcg_cap;=0A #endif=0A };=0A typedef struct =
xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;=0A
--=__Part6B451305.3__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part6B451305.3__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJc1-0007U8-TX; Tue, 14 Feb 2012 14:44:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJc0-0007Tl-LP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:08 +0000
Received: from [85.158.139.83:11731] by server-11.bemta-5.messagelabs.com id
	15/5A-14397-7337A3F4; Tue, 14 Feb 2012 14:44:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329230645!12320649!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14383 invoked from network); 14 Feb 2012 14:44:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:04 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wb028250; Tue, 14 Feb 2012 06:44:03 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:51 +0000
Message-ID: <1329230641-18624-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/12] arm: define some more cp15 registers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Complete the set of cache flush and add processor feature registers. Print the
latter on boot for debug.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c         |   17 +++++++++++++++++
 xen/include/asm-arm/cpregs.h |   18 ++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index de7d5f2..ddc2392 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,6 +64,20 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+static void processor_id(void)
+{
+    printk("Processor Features: %08x %08x\n",
+           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
+    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
+    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
+    printk("Memory Model Features: %08x %08x %08x %08x\n",
+           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
+           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
+    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
+           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+}
+
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 {
     paddr_t ram_start;
@@ -185,7 +199,10 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_CP32(0x80002558, VTCR); isb();
 
+    processor_id();
+
     softirq_init();
+
     tasklet_subsys_init();
 
     init_IRQ();
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 3a4028d..d61ea88 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -93,6 +93,18 @@
 /* CP15 CR0: CPUID and Cache Type Registers */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */
+#define ID_AFR0         p15,0,c0,c1,3   /* Auxiliary Feature Register 0 */
+#define ID_MMFR0        p15,0,c0,c1,4   /* Memory Model Feature Register 0 */
+#define ID_MMFR1        p15,0,c0,c1,5   /* Memory Model Feature Register 1 */
+#define ID_MMFR2        p15,0,c0,c1,6   /* Memory Model Feature Register 2 */
+#define ID_MMFR3        p15,0,c0,c1,7   /* Memory Model Feature Register 3 */
+#define ID_ISAR0        p15,0,c0,c2,0   /* ISA Feature Register 0 */
+#define ID_ISAR1        p15,0,c0,c2,1   /* ISA Feature Register 1 */
+#define ID_ISAR2        p15,0,c0,c2,2   /* ISA Feature Register 2 */
+#define ID_ISAR3        p15,0,c0,c2,3   /* ISA Feature Register 3 */
+#define ID_ISAR4        p15,0,c0,c2,4   /* ISA Feature Register 4 */
+#define ID_ISAR5        p15,0,c0,c2,5   /* ISA Feature Register 5 */
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
@@ -134,7 +146,11 @@
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define ICIMVAU         p15,0,c7,c5,1   /* Invalidate instruction caches by MVA to PoU */
 #define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define BPIMVA          p15,0,c7,c5,7   /* Invalidate MVA from branch predictor array */
+#define DCIMVAC         p15,0,c7,c6,1   /* Invalidate data cache line by MVA to PoC */
+#define DCISW           p15,0,c7,c2,1   /* Invalidate data cache line by set/way */
 #define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
 #define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
 #define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
@@ -144,6 +160,8 @@
 #define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
 #define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
 #define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCSW           p15,0,c7,c10,2  /* Clean data cache line by set/way */
+#define DCCMVAU         p15,0,c7,c11,1  /* Clean data cache line by MVA to PoU */
 #define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
 #define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
 #define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJc1-0007U8-TX; Tue, 14 Feb 2012 14:44:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJc0-0007Tl-LP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:08 +0000
Received: from [85.158.139.83:11731] by server-11.bemta-5.messagelabs.com id
	15/5A-14397-7337A3F4; Tue, 14 Feb 2012 14:44:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329230645!12320649!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14383 invoked from network); 14 Feb 2012 14:44:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:04 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wb028250; Tue, 14 Feb 2012 06:44:03 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:51 +0000
Message-ID: <1329230641-18624-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/12] arm: define some more cp15 registers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Complete the set of cache flush and add processor feature registers. Print the
latter on boot for debug.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c         |   17 +++++++++++++++++
 xen/include/asm-arm/cpregs.h |   18 ++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index de7d5f2..ddc2392 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,6 +64,20 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+static void processor_id(void)
+{
+    printk("Processor Features: %08x %08x\n",
+           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
+    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
+    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
+    printk("Memory Model Features: %08x %08x %08x %08x\n",
+           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
+           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
+    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
+           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+}
+
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 {
     paddr_t ram_start;
@@ -185,7 +199,10 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_CP32(0x80002558, VTCR); isb();
 
+    processor_id();
+
     softirq_init();
+
     tasklet_subsys_init();
 
     init_IRQ();
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 3a4028d..d61ea88 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -93,6 +93,18 @@
 /* CP15 CR0: CPUID and Cache Type Registers */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */
+#define ID_AFR0         p15,0,c0,c1,3   /* Auxiliary Feature Register 0 */
+#define ID_MMFR0        p15,0,c0,c1,4   /* Memory Model Feature Register 0 */
+#define ID_MMFR1        p15,0,c0,c1,5   /* Memory Model Feature Register 1 */
+#define ID_MMFR2        p15,0,c0,c1,6   /* Memory Model Feature Register 2 */
+#define ID_MMFR3        p15,0,c0,c1,7   /* Memory Model Feature Register 3 */
+#define ID_ISAR0        p15,0,c0,c2,0   /* ISA Feature Register 0 */
+#define ID_ISAR1        p15,0,c0,c2,1   /* ISA Feature Register 1 */
+#define ID_ISAR2        p15,0,c0,c2,2   /* ISA Feature Register 2 */
+#define ID_ISAR3        p15,0,c0,c2,3   /* ISA Feature Register 3 */
+#define ID_ISAR4        p15,0,c0,c2,4   /* ISA Feature Register 4 */
+#define ID_ISAR5        p15,0,c0,c2,5   /* ISA Feature Register 5 */
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
@@ -134,7 +146,11 @@
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define ICIMVAU         p15,0,c7,c5,1   /* Invalidate instruction caches by MVA to PoU */
 #define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define BPIMVA          p15,0,c7,c5,7   /* Invalidate MVA from branch predictor array */
+#define DCIMVAC         p15,0,c7,c6,1   /* Invalidate data cache line by MVA to PoC */
+#define DCISW           p15,0,c7,c2,1   /* Invalidate data cache line by set/way */
 #define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
 #define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
 #define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
@@ -144,6 +160,8 @@
 #define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
 #define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
 #define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCSW           p15,0,c7,c10,2  /* Clean data cache line by set/way */
+#define DCCMVAU         p15,0,c7,c11,1  /* Clean data cache line by MVA to PoU */
 #define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
 #define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
 #define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJc7-0007VK-B1; Tue, 14 Feb 2012 14:44: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 1RxJc4-0007U2-KS
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:13 +0000
Received: from [85.158.139.83:11795] by server-6.bemta-5.messagelabs.com id
	F8/8B-27305-8337A3F4; Tue, 14 Feb 2012 14:44:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329230645!12320649!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14422 invoked from network); 14 Feb 2012 14:44:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687112"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:06 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wd028250; Tue, 14 Feb 2012 06:44:05 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:53 +0000
Message-ID: <1329230641-18624-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/12] arm: remove some unnecessary symbols from
	dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Correct the comment on the DUMMY macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5bc4f21..fff7d7e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -1,8 +1,6 @@
-/* Nothing is mapped at 1G, for the moment */
 #define DUMMY(x) \
 	.globl x; \
-x:	.word 0xe7f000f0
-/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+x:	.word 0xe7f000f0 /* Undefined instruction */
 
 #define  NOP(x) \
 	.globl x; \
@@ -35,15 +33,11 @@ DUMMY(get_page);
 DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_host_mapping_get_page_type);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(iommu_map_page);
 DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
-DUMMY(local_event_delivery_enable);
-DUMMY(local_events_need_delivery);
-DUMMY(machine_to_phys_mapping_valid);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJc7-0007VK-B1; Tue, 14 Feb 2012 14:44: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 1RxJc4-0007U2-KS
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:13 +0000
Received: from [85.158.139.83:11795] by server-6.bemta-5.messagelabs.com id
	F8/8B-27305-8337A3F4; Tue, 14 Feb 2012 14:44:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329230645!12320649!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14422 invoked from network); 14 Feb 2012 14:44:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687112"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:06 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wd028250; Tue, 14 Feb 2012 06:44:05 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:53 +0000
Message-ID: <1329230641-18624-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/12] arm: remove some unnecessary symbols from
	dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Correct the comment on the DUMMY macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5bc4f21..fff7d7e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -1,8 +1,6 @@
-/* Nothing is mapped at 1G, for the moment */
 #define DUMMY(x) \
 	.globl x; \
-x:	.word 0xe7f000f0
-/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+x:	.word 0xe7f000f0 /* Undefined instruction */
 
 #define  NOP(x) \
 	.globl x; \
@@ -35,15 +33,11 @@ DUMMY(get_page);
 DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_host_mapping_get_page_type);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(iommu_map_page);
 DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
-DUMMY(local_event_delivery_enable);
-DUMMY(local_events_need_delivery);
-DUMMY(machine_to_phys_mapping_valid);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJcC-0007X9-Ja; Tue, 14 Feb 2012 14:44:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcA-0007Ut-Lw
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329230650!13123809!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5178 invoked from network); 14 Feb 2012 14:44:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687121"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:11 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wi028250; Tue, 14 Feb 2012 06:44:10 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 14:43:58 +0000
Message-ID: <1329230641-18624-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/12] xen: make need_iommu == 0 if
	!HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
---
 xen/Rules.mk            |    1 +
 xen/arch/arm/dummy.S    |    2 --
 xen/include/xen/sched.h |    6 ++++++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index ee54179..6123835 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5010619..e858613 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(iommu_map_page);
-DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 567cd36..3699929 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -266,8 +266,10 @@ struct domain
 
     /* Is this an HVM guest? */
     bool_t           is_hvm;
+#ifdef HAS_PASSTHROUGH
     /* Does this guest need iommu mappings? */
     bool_t           need_iommu;
+#endif
     /* Is this guest fully privileged (aka dom0)? */
     bool_t           is_privileged;
     /* Which guest this guest has privileges on */
@@ -687,7 +689,11 @@ void watchdog_domain_destroy(struct domain *d);
 #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
 #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
                            cpumask_weight((v)->cpu_affinity) == 1)
+#ifdef HAS_PASSTHROUGH
 #define need_iommu(d)    ((d)->need_iommu)
+#else
+#define need_iommu(d)    (0)
+#endif
 
 void set_vcpu_migration_delay(unsigned int delay);
 unsigned int get_vcpu_migration_delay(void);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJcC-0007X9-Ja; Tue, 14 Feb 2012 14:44:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcA-0007Ut-Lw
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329230650!13123809!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5178 invoked from network); 14 Feb 2012 14:44:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687121"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:11 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wi028250; Tue, 14 Feb 2012 06:44:10 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 14:43:58 +0000
Message-ID: <1329230641-18624-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/12] xen: make need_iommu == 0 if
	!HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
---
 xen/Rules.mk            |    1 +
 xen/arch/arm/dummy.S    |    2 --
 xen/include/xen/sched.h |    6 ++++++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index ee54179..6123835 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5010619..e858613 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(iommu_map_page);
-DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 567cd36..3699929 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -266,8 +266,10 @@ struct domain
 
     /* Is this an HVM guest? */
     bool_t           is_hvm;
+#ifdef HAS_PASSTHROUGH
     /* Does this guest need iommu mappings? */
     bool_t           need_iommu;
+#endif
     /* Is this guest fully privileged (aka dom0)? */
     bool_t           is_privileged;
     /* Which guest this guest has privileges on */
@@ -687,7 +689,11 @@ void watchdog_domain_destroy(struct domain *d);
 #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
 #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
                            cpumask_weight((v)->cpu_affinity) == 1)
+#ifdef HAS_PASSTHROUGH
 #define need_iommu(d)    ((d)->need_iommu)
+#else
+#define need_iommu(d)    (0)
+#endif
 
 void set_vcpu_migration_delay(unsigned int delay);
 unsigned int get_vcpu_migration_delay(void);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJc7-0007VU-PG; Tue, 14 Feb 2012 14:44:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJc6-0007U5-T4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329230647!13922439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14894 invoked from network); 14 Feb 2012 14:44:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:07 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2We028250; Tue, 14 Feb 2012 06:44:06 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:54 +0000
Message-ID: <1329230641-18624-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/12] arm: Add stub functions instead of using
	DUMMY
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Adds stubs for arch domctl and sysctl plus vcpu_op and memory_op.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile |    2 ++
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/domctl.c |   27 +++++++++++++++++++++++++++
 xen/arch/arm/dummy.S  |    4 ----
 xen/arch/arm/mm.c     |    5 +++++
 xen/arch/arm/sysctl.c |   29 +++++++++++++++++++++++++++++
 6 files changed, 68 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/domctl.c
 create mode 100644 xen/arch/arm/sysctl.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 168716e..49b64fe 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,8 @@ obj-y += dummy.o
 obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
+obj-y += domctl.o
+obj-y += sysctl.o
 obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ada89af..5fe370b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -255,6 +255,11 @@ void arch_dump_domain_info(struct domain *d)
 {
 }
 
+long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
new file mode 100644
index 0000000..d957f21
--- /dev/null
+++ b/xen/arch/arm/domctl.c
@@ -0,0 +1,27 @@
+/******************************************************************************
+ * Arch-specific domctl.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/domctl.h>
+
+long arch_do_domctl(struct xen_domctl *domctl,
+                    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index fff7d7e..1287e0b 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -8,12 +8,8 @@ x:	mov pc, lr
 	
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
-DUMMY(arch_do_domctl);
-DUMMY(arch_do_sysctl);
-DUMMY(arch_do_vcpu_op);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_get_xen_caps);
-DUMMY(arch_memory_op);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0d6c0ca..fcab567 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -320,6 +320,11 @@ void arch_dump_shared_mem_info(void)
 {
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
new file mode 100644
index 0000000..50101c7
--- /dev/null
+++ b/xen/arch/arm/sysctl.c
@@ -0,0 +1,29 @@
+/******************************************************************************
+ * Arch-specific sysctl.c
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/sysctl.h>
+
+long arch_do_sysctl(struct xen_sysctl *sysctl,
+		    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJc7-0007VU-PG; Tue, 14 Feb 2012 14:44:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJc6-0007U5-T4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329230647!13922439!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14894 invoked from network); 14 Feb 2012 14:44:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:07 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2We028250; Tue, 14 Feb 2012 06:44:06 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:54 +0000
Message-ID: <1329230641-18624-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/12] arm: Add stub functions instead of using
	DUMMY
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Adds stubs for arch domctl and sysctl plus vcpu_op and memory_op.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile |    2 ++
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/domctl.c |   27 +++++++++++++++++++++++++++
 xen/arch/arm/dummy.S  |    4 ----
 xen/arch/arm/mm.c     |    5 +++++
 xen/arch/arm/sysctl.c |   29 +++++++++++++++++++++++++++++
 6 files changed, 68 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/domctl.c
 create mode 100644 xen/arch/arm/sysctl.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 168716e..49b64fe 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,8 @@ obj-y += dummy.o
 obj-y += early_printk.o
 obj-y += entry.o
 obj-y += domain.o
+obj-y += domctl.o
+obj-y += sysctl.o
 obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ada89af..5fe370b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -255,6 +255,11 @@ void arch_dump_domain_info(struct domain *d)
 {
 }
 
+long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
new file mode 100644
index 0000000..d957f21
--- /dev/null
+++ b/xen/arch/arm/domctl.c
@@ -0,0 +1,27 @@
+/******************************************************************************
+ * Arch-specific domctl.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/domctl.h>
+
+long arch_do_domctl(struct xen_domctl *domctl,
+                    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index fff7d7e..1287e0b 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -8,12 +8,8 @@ x:	mov pc, lr
 	
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
-DUMMY(arch_do_domctl);
-DUMMY(arch_do_sysctl);
-DUMMY(arch_do_vcpu_op);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_get_xen_caps);
-DUMMY(arch_memory_op);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0d6c0ca..fcab567 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -320,6 +320,11 @@ void arch_dump_shared_mem_info(void)
 {
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
new file mode 100644
index 0000000..50101c7
--- /dev/null
+++ b/xen/arch/arm/sysctl.c
@@ -0,0 +1,29 @@
+/******************************************************************************
+ * Arch-specific sysctl.c
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/sysctl.h>
+
+long arch_do_sysctl(struct xen_sysctl *sysctl,
+		    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcC-0007Wn-6v; Tue, 14 Feb 2012 14:44:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcA-0007Ur-7S
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329230650!13123809!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5138 invoked from network); 14 Feb 2012 14:44:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687119"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:09 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wg028250; Tue, 14 Feb 2012 06:44:08 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:56 +0000
Message-ID: <1329230641-18624-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/12] arm: provide dummy version of steal_page
	for tmem.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is how IA64 does it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    6 ++++++
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3bf5226..da0b906 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(donate_page);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index fcab567..2c905ed 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -325,6 +325,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
     return -ENOSYS;
 }
 
+int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
+{
+    ASSERT(0);
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcC-0007Wn-6v; Tue, 14 Feb 2012 14:44:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcA-0007Ur-7S
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329230650!13123809!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5138 invoked from network); 14 Feb 2012 14:44:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687119"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:09 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wg028250; Tue, 14 Feb 2012 06:44:08 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:56 +0000
Message-ID: <1329230641-18624-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/12] arm: provide dummy version of steal_page
	for tmem.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is how IA64 does it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    6 ++++++
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3bf5226..da0b906 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(donate_page);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index fcab567..2c905ed 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -325,6 +325,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
     return -ENOSYS;
 }
 
+int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
+{
+    ASSERT(0);
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcN-0007e2-HO; Tue, 14 Feb 2012 14:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcL-0007Z0-Mu
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3338 invoked from network); 14 Feb 2012 14:44:23 -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;
	14 Feb 2012 14:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933393"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:10 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wh028250; Tue, 14 Feb 2012 06:44:09 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:57 +0000
Message-ID: <1329230641-18624-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/12] arm: Implement arch_get_xen_caps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TBD: correct arch name for this string. Should be "xen-" / "hvm-" or something
else given the hybrid model we are using on ARM?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    1 +
 xen/arch/arm/setup.c |   12 ++++++++++++
 3 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index da0b906..5010619 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -9,7 +9,6 @@ x:	mov pc, lr
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_get_xen_caps);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 2c905ed..0cff726 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -24,6 +24,7 @@
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
+#include <xen/errno.h>
 #include <asm/page.h>
 #include <asm/current.h>
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ddc2392..7762166 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -271,6 +271,18 @@ void __init start_xen(unsigned long boot_phys_offset,
     reset_stack_and_jump(init_done);
 }
 
+void arch_get_xen_caps(xen_capabilities_info_t *info)
+{
+    /* Interface name is always xen-3.0-* for Xen-3.x. */
+    int major = 3, minor = 0;
+    char s[32];
+
+    (*info)[0] = '\0';
+
+    snprintf(s, sizeof(s), "xen-%d.%d-armv7l ", major, minor);
+    safe_strcat(*info, s);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcN-0007e2-HO; Tue, 14 Feb 2012 14:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcL-0007Z0-Mu
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3338 invoked from network); 14 Feb 2012 14:44:23 -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;
	14 Feb 2012 14:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933393"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:10 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wh028250; Tue, 14 Feb 2012 06:44:09 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:57 +0000
Message-ID: <1329230641-18624-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/12] arm: Implement arch_get_xen_caps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TBD: correct arch name for this string. Should be "xen-" / "hvm-" or something
else given the hybrid model we are using on ARM?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    1 +
 xen/arch/arm/setup.c |   12 ++++++++++++
 3 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index da0b906..5010619 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -9,7 +9,6 @@ x:	mov pc, lr
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_get_xen_caps);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 2c905ed..0cff726 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -24,6 +24,7 @@
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
+#include <xen/errno.h>
 #include <asm/page.h>
 #include <asm/current.h>
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ddc2392..7762166 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -271,6 +271,18 @@ void __init start_xen(unsigned long boot_phys_offset,
     reset_stack_and_jump(init_done);
 }
 
+void arch_get_xen_caps(xen_capabilities_info_t *info)
+{
+    /* Interface name is always xen-3.0-* for Xen-3.x. */
+    int major = 3, minor = 0;
+    char s[32];
+
+    (*info)[0] = '\0';
+
+    snprintf(s, sizeof(s), "xen-%d.%d-armv7l ", major, minor);
+    safe_strcat(*info, s);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcO-0007fE-HB; Tue, 14 Feb 2012 14:44:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcM-0007Za-Vs
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329230663!15299162!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17711 invoked from network); 14 Feb 2012 14:44:24 -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;
	14 Feb 2012 14:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933394"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:12 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wj028250; Tue, 14 Feb 2012 06:44:11 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:59 +0000
Message-ID: <1329230641-18624-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/12] arm: stub out PoD related p2m functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    2 --
 xen/arch/arm/p2m.c   |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index e858613..67edb35 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-DUMMY(p2m_pod_decrease_reservation);
-DUMMY(guest_physmap_mark_populate_on_demand);
 DUMMY(page_get_owner_and_reference);
 DUMMY(page_is_ram_type);
 DUMMY(per_cpu__cpu_core_mask);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a1d026d..14614fd 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -18,6 +18,20 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+int guest_physmap_mark_populate_on_demand(struct domain *d,
+                                          unsigned long gfn,
+                                          unsigned int order)
+{
+    return -ENOSYS;
+}
+
+int p2m_pod_decrease_reservation(struct domain *d,
+                                 xen_pfn_t gpfn,
+                                 unsigned int order)
+{
+    return -ENOSYS;
+}
+
 static int p2m_create_entry(struct domain *d,
                             lpae_t *entry)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcO-0007fE-HB; Tue, 14 Feb 2012 14:44:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcM-0007Za-Vs
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329230663!15299162!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17711 invoked from network); 14 Feb 2012 14:44:24 -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;
	14 Feb 2012 14:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933394"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:12 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wj028250; Tue, 14 Feb 2012 06:44:11 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:59 +0000
Message-ID: <1329230641-18624-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/12] arm: stub out PoD related p2m functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    2 --
 xen/arch/arm/p2m.c   |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index e858613..67edb35 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-DUMMY(p2m_pod_decrease_reservation);
-DUMMY(guest_physmap_mark_populate_on_demand);
 DUMMY(page_get_owner_and_reference);
 DUMMY(page_is_ram_type);
 DUMMY(per_cpu__cpu_core_mask);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a1d026d..14614fd 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -18,6 +18,20 @@ void p2m_load_VTTBR(struct domain *d)
     isb(); /* Ensure update is visible */
 }
 
+int guest_physmap_mark_populate_on_demand(struct domain *d,
+                                          unsigned long gfn,
+                                          unsigned int order)
+{
+    return -ENOSYS;
+}
+
+int p2m_pod_decrease_reservation(struct domain *d,
+                                 xen_pfn_t gpfn,
+                                 unsigned int order)
+{
+    return -ENOSYS;
+}
+
 static int p2m_create_entry(struct domain *d,
                             lpae_t *entry)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcP-0007fx-AP; Tue, 14 Feb 2012 14:44:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcN-0007a7-P5
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3436 invoked from network); 14 Feb 2012 14:44:25 -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;
	14 Feb 2012 14:44:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933395"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:13 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wl028250; Tue, 14 Feb 2012 06:44:13 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:44:01 +0000
Message-ID: <1329230641-18624-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/12] arm: Group remaining dummy symbols
	somewhat according to functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Makes it easier to see what needs to be done.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |   69 +++++++++++++++++++++++++++++--------------------
 1 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 295938e..3f2cc4b 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -6,48 +6,61 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 	.globl x; \
 x:	mov pc, lr
 	
+/* SMP support */
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(node_online_map);
+DUMMY(smp_send_state_dump);
+DUMMY(__per_cpu_offset);
+
+/* PIRQ support */
 DUMMY(alloc_pirq_struct);
+DUMMY(nr_irqs_gsi);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+
+/* VCPU */
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
+DUMMY(free_vcpu_guest_context);
+DUMMY(sync_vcpu_execstate);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+
+/* Page Reference & Type Maintenance */
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(page_get_owner_and_reference);
+DUMMY(put_page);
+DUMMY(put_page_type);
+
+/* Grant Tables */
 DUMMY(create_grant_host_mapping);
-DUMMY(__cpu_die);
-DUMMY(__cpu_disable);
-DUMMY(__cpu_up);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_mark_dirty);
+DUMMY(is_iomem_page);
+DUMMY(replace_grant_host_mapping);
+DUMMY(steal_page);
+
+/* Page Offlining */
+DUMMY(page_is_ram_type);
+
+/* Other */
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(flush_tlb_mask);
-DUMMY(free_vcpu_guest_context);
-DUMMY(get_page);
-DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
-DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(is_iomem_page);
-DUMMY(node_online_map);
-DUMMY(nr_irqs_gsi);
-DUMMY(page_get_owner_and_reference);
-DUMMY(page_is_ram_type);
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
-DUMMY(__per_cpu_offset);
-DUMMY(pirq_guest_bind);
-DUMMY(pirq_guest_unbind);
-DUMMY(pirq_set_affinity);
-DUMMY(put_page);
-DUMMY(put_page_type);
-DUMMY(replace_grant_host_mapping);
 DUMMY(send_timer_event);
 DUMMY(share_xen_page_with_privileged_guests);
-DUMMY(smp_send_state_dump);
-DUMMY(steal_page);
-DUMMY(sync_vcpu_execstate);
 DUMMY(__udelay);
-NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
-DUMMY(vcpu_show_execution_state);
 DUMMY(wallclock_time);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcN-0007eQ-TW; Tue, 14 Feb 2012 14:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcM-0007ZK-DY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3368 invoked from network); 14 Feb 2012 14:44:24 -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;
	14 Feb 2012 14:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933386"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:03 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wa028250; Tue, 14 Feb 2012 06:44:03 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:50 +0000
Message-ID: <1329230641-18624-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/12] arm: add a missing local-vars comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f2339fa..71a204d 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -194,3 +194,12 @@ void kernel_load(struct kernel_info *info)
 {
     info->load(info);
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcP-0007fx-AP; Tue, 14 Feb 2012 14:44:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcN-0007a7-P5
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3436 invoked from network); 14 Feb 2012 14:44:25 -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;
	14 Feb 2012 14:44:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933395"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:13 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wl028250; Tue, 14 Feb 2012 06:44:13 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:44:01 +0000
Message-ID: <1329230641-18624-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/12] arm: Group remaining dummy symbols
	somewhat according to functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Makes it easier to see what needs to be done.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |   69 +++++++++++++++++++++++++++++--------------------
 1 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 295938e..3f2cc4b 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -6,48 +6,61 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 	.globl x; \
 x:	mov pc, lr
 	
+/* SMP support */
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(node_online_map);
+DUMMY(smp_send_state_dump);
+DUMMY(__per_cpu_offset);
+
+/* PIRQ support */
 DUMMY(alloc_pirq_struct);
+DUMMY(nr_irqs_gsi);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+
+/* VCPU */
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
+DUMMY(free_vcpu_guest_context);
+DUMMY(sync_vcpu_execstate);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+
+/* Page Reference & Type Maintenance */
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(page_get_owner_and_reference);
+DUMMY(put_page);
+DUMMY(put_page_type);
+
+/* Grant Tables */
 DUMMY(create_grant_host_mapping);
-DUMMY(__cpu_die);
-DUMMY(__cpu_disable);
-DUMMY(__cpu_up);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_mark_dirty);
+DUMMY(is_iomem_page);
+DUMMY(replace_grant_host_mapping);
+DUMMY(steal_page);
+
+/* Page Offlining */
+DUMMY(page_is_ram_type);
+
+/* Other */
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(flush_tlb_mask);
-DUMMY(free_vcpu_guest_context);
-DUMMY(get_page);
-DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
-DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(is_iomem_page);
-DUMMY(node_online_map);
-DUMMY(nr_irqs_gsi);
-DUMMY(page_get_owner_and_reference);
-DUMMY(page_is_ram_type);
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
-DUMMY(__per_cpu_offset);
-DUMMY(pirq_guest_bind);
-DUMMY(pirq_guest_unbind);
-DUMMY(pirq_set_affinity);
-DUMMY(put_page);
-DUMMY(put_page_type);
-DUMMY(replace_grant_host_mapping);
 DUMMY(send_timer_event);
 DUMMY(share_xen_page_with_privileged_guests);
-DUMMY(smp_send_state_dump);
-DUMMY(steal_page);
-DUMMY(sync_vcpu_execstate);
 DUMMY(__udelay);
-NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
-DUMMY(vcpu_show_execution_state);
 DUMMY(wallclock_time);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcN-0007eQ-TW; Tue, 14 Feb 2012 14:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcM-0007ZK-DY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3368 invoked from network); 14 Feb 2012 14:44:24 -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;
	14 Feb 2012 14:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933386"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:03 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wa028250; Tue, 14 Feb 2012 06:44:03 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:50 +0000
Message-ID: <1329230641-18624-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/12] arm: add a missing local-vars comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f2339fa..71a204d 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -194,3 +194,12 @@ void kernel_load(struct kernel_info *info)
 {
     info->load(info);
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcO-0007fc-Up; Tue, 14 Feb 2012 14:44:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcN-0007Zb-73
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3394 invoked from network); 14 Feb 2012 14:44:24 -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;
	14 Feb 2012 14:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933392"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:08 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wf028250; Tue, 14 Feb 2012 06:44:07 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 14:43:55 +0000
Message-ID: <1329230641-18624-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/12] PM: only include XEN_SYSCTL_{get_pmstat,
	pm_op} if HAVE_ACPI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These hypercalls are currently ACPI specific and implemented in
xen/drivers/acpi which is not implemented on ARM.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
---
 xen/Rules.mk         |    1 +
 xen/arch/arm/dummy.S |    2 --
 xen/common/sysctl.c  |    2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 507e9ab..ee54179 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -50,6 +50,7 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
+CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 1287e0b..3bf5226 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -16,13 +16,11 @@ DUMMY(create_grant_host_mapping);
 DUMMY(__cpu_die);
 DUMMY(__cpu_disable);
 DUMMY(__cpu_up);
-DUMMY(do_get_pm_info);
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(donate_page);
-DUMMY(do_pm_op);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f8f7cf8..fef0589 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -224,6 +224,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     }
     break;
 
+#ifdef HAS_ACPI
     case XEN_SYSCTL_get_pmstat:
     {
         ret = xsm_get_pmstat();
@@ -259,6 +260,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
         }
     }
     break;
+#endif
 
     case XEN_SYSCTL_page_offline_op:
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcN-0007dY-0y; Tue, 14 Feb 2012 14:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcL-0007Yn-B4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 14 Feb 2012 14:44:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933387"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:05 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wc028250; Tue, 14 Feb 2012 06:44:04 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:52 +0000
Message-ID: <1329230641-18624-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/12] arm: align some register bit definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Probably got de-hard-tabbed at some point.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/processor.h |   80 +++++++++++++++++++-------------------
 1 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1f85d31..ec6fb48 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -17,12 +17,12 @@
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
-#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
-#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
-#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
-#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+#define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_N_MASK 0x07
@@ -35,56 +35,56 @@
 /* SCTLR System Control Register. */
 /* HSCTLR is a subset of this. */
 #define SCTLR_TE        (1<<30)
-#define SCTLR_AFE        (1<<29)
-#define SCTLR_TRE        (1<<28)
-#define SCTLR_NMFI        (1<<27)
+#define SCTLR_AFE       (1<<29)
+#define SCTLR_TRE       (1<<28)
+#define SCTLR_NMFI      (1<<27)
 #define SCTLR_EE        (1<<25)
 #define SCTLR_VE        (1<<24)
-#define SCTLR_U                (1<<22)
+#define SCTLR_U         (1<<22)
 #define SCTLR_FI        (1<<21)
-#define SCTLR_WXN        (1<<19)
+#define SCTLR_WXN       (1<<19)
 #define SCTLR_HA        (1<<17)
 #define SCTLR_RR        (1<<14)
-#define SCTLR_V                (1<<13)
-#define SCTLR_I                (1<<12)
-#define SCTLR_Z                (1<<11)
+#define SCTLR_V         (1<<13)
+#define SCTLR_I         (1<<12)
+#define SCTLR_Z         (1<<11)
 #define SCTLR_SW        (1<<10)
-#define SCTLR_B                (1<<7)
-#define SCTLR_C                (1<<2)
-#define SCTLR_A                (1<<1)
-#define SCTLR_M                (1<<0)
+#define SCTLR_B         (1<<7)
+#define SCTLR_C         (1<<2)
+#define SCTLR_A         (1<<1)
+#define SCTLR_M         (1<<0)
 
 #define SCTLR_BASE        0x00c50078
-#define HSCTLR_BASE        0x30c51878
+#define HSCTLR_BASE       0x30c51878
 
 /* HCR Hyp Configuration Register */
-#define HCR_TGE                (1<<27)
-#define HCR_TVM                (1<<26)
+#define HCR_TGE         (1<<27)
+#define HCR_TVM         (1<<26)
 #define HCR_TTLB        (1<<25)
-#define HCR_TPU                (1<<24)
-#define HCR_TPC                (1<<23)
-#define HCR_TSW                (1<<22)
-#define HCR_TAC                (1<<21)
-#define HCR_TIDCP        (1<<20)
-#define HCR_TSC                (1<<19)
+#define HCR_TPU         (1<<24)
+#define HCR_TPC         (1<<23)
+#define HCR_TSW         (1<<22)
+#define HCR_TAC         (1<<21)
+#define HCR_TIDCP       (1<<20)
+#define HCR_TSC         (1<<19)
 #define HCR_TID3        (1<<18)
 #define HCR_TID2        (1<<17)
 #define HCR_TID1        (1<<16)
 #define HCR_TID0        (1<<15)
-#define HCR_TWE                (1<<14)
-#define HCR_TWI                (1<<13)
-#define HCR_DC                (1<<12)
-#define HCR_BSU_MASK        (3<<10)
-#define HCR_FB                (1<<9)
-#define HCR_VA                (1<<8)
-#define HCR_VI                (1<<7)
-#define HCR_VF                (1<<6)
-#define HCR_AMO                (1<<5)
-#define HCR_IMO                (1<<4)
-#define HCR_FMO                (1<<3)
-#define HCR_PTW                (1<<2)
+#define HCR_TWE         (1<<14)
+#define HCR_TWI         (1<<13)
+#define HCR_DC          (1<<12)
+#define HCR_BSU_MASK    (3<<10)
+#define HCR_FB          (1<<9)
+#define HCR_VA          (1<<8)
+#define HCR_VI          (1<<7)
+#define HCR_VF          (1<<6)
+#define HCR_AMO         (1<<5)
+#define HCR_IMO         (1<<4)
+#define HCR_FMO         (1<<3)
+#define HCR_PTW         (1<<2)
 #define HCR_SWIO        (1<<1)
-#define HCR_VM                (1<<0)
+#define HCR_VM          (1<<0)
 
 #define HSR_EC_WFI_WFE              0x01
 #define HSR_EC_CP15_32              0x03
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcN-0007dY-0y; Tue, 14 Feb 2012 14:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcL-0007Yn-B4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3301 invoked from network); 14 Feb 2012 14:44:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933387"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:05 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wc028250; Tue, 14 Feb 2012 06:44:04 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:43:52 +0000
Message-ID: <1329230641-18624-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/12] arm: align some register bit definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Probably got de-hard-tabbed at some point.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/processor.h |   80 +++++++++++++++++++-------------------
 1 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1f85d31..ec6fb48 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -17,12 +17,12 @@
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
-#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
-#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
-#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
-#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+#define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_N_MASK 0x07
@@ -35,56 +35,56 @@
 /* SCTLR System Control Register. */
 /* HSCTLR is a subset of this. */
 #define SCTLR_TE        (1<<30)
-#define SCTLR_AFE        (1<<29)
-#define SCTLR_TRE        (1<<28)
-#define SCTLR_NMFI        (1<<27)
+#define SCTLR_AFE       (1<<29)
+#define SCTLR_TRE       (1<<28)
+#define SCTLR_NMFI      (1<<27)
 #define SCTLR_EE        (1<<25)
 #define SCTLR_VE        (1<<24)
-#define SCTLR_U                (1<<22)
+#define SCTLR_U         (1<<22)
 #define SCTLR_FI        (1<<21)
-#define SCTLR_WXN        (1<<19)
+#define SCTLR_WXN       (1<<19)
 #define SCTLR_HA        (1<<17)
 #define SCTLR_RR        (1<<14)
-#define SCTLR_V                (1<<13)
-#define SCTLR_I                (1<<12)
-#define SCTLR_Z                (1<<11)
+#define SCTLR_V         (1<<13)
+#define SCTLR_I         (1<<12)
+#define SCTLR_Z         (1<<11)
 #define SCTLR_SW        (1<<10)
-#define SCTLR_B                (1<<7)
-#define SCTLR_C                (1<<2)
-#define SCTLR_A                (1<<1)
-#define SCTLR_M                (1<<0)
+#define SCTLR_B         (1<<7)
+#define SCTLR_C         (1<<2)
+#define SCTLR_A         (1<<1)
+#define SCTLR_M         (1<<0)
 
 #define SCTLR_BASE        0x00c50078
-#define HSCTLR_BASE        0x30c51878
+#define HSCTLR_BASE       0x30c51878
 
 /* HCR Hyp Configuration Register */
-#define HCR_TGE                (1<<27)
-#define HCR_TVM                (1<<26)
+#define HCR_TGE         (1<<27)
+#define HCR_TVM         (1<<26)
 #define HCR_TTLB        (1<<25)
-#define HCR_TPU                (1<<24)
-#define HCR_TPC                (1<<23)
-#define HCR_TSW                (1<<22)
-#define HCR_TAC                (1<<21)
-#define HCR_TIDCP        (1<<20)
-#define HCR_TSC                (1<<19)
+#define HCR_TPU         (1<<24)
+#define HCR_TPC         (1<<23)
+#define HCR_TSW         (1<<22)
+#define HCR_TAC         (1<<21)
+#define HCR_TIDCP       (1<<20)
+#define HCR_TSC         (1<<19)
 #define HCR_TID3        (1<<18)
 #define HCR_TID2        (1<<17)
 #define HCR_TID1        (1<<16)
 #define HCR_TID0        (1<<15)
-#define HCR_TWE                (1<<14)
-#define HCR_TWI                (1<<13)
-#define HCR_DC                (1<<12)
-#define HCR_BSU_MASK        (3<<10)
-#define HCR_FB                (1<<9)
-#define HCR_VA                (1<<8)
-#define HCR_VI                (1<<7)
-#define HCR_VF                (1<<6)
-#define HCR_AMO                (1<<5)
-#define HCR_IMO                (1<<4)
-#define HCR_FMO                (1<<3)
-#define HCR_PTW                (1<<2)
+#define HCR_TWE         (1<<14)
+#define HCR_TWI         (1<<13)
+#define HCR_DC          (1<<12)
+#define HCR_BSU_MASK    (3<<10)
+#define HCR_FB          (1<<9)
+#define HCR_VA          (1<<8)
+#define HCR_VI          (1<<7)
+#define HCR_VF          (1<<6)
+#define HCR_AMO         (1<<5)
+#define HCR_IMO         (1<<4)
+#define HCR_FMO         (1<<3)
+#define HCR_PTW         (1<<2)
 #define HCR_SWIO        (1<<1)
-#define HCR_VM                (1<<0)
+#define HCR_VM          (1<<0)
 
 #define HSR_EC_WFI_WFE              0x01
 #define HSR_EC_CP15_32              0x03
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:44:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJcO-0007fc-Up; Tue, 14 Feb 2012 14:44:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJcN-0007Zb-73
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:44:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329230661!14762794!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3394 invoked from network); 14 Feb 2012 14:44:24 -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;
	14 Feb 2012 14:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21933392"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:08 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wf028250; Tue, 14 Feb 2012 06:44:07 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 14:43:55 +0000
Message-ID: <1329230641-18624-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/12] PM: only include XEN_SYSCTL_{get_pmstat,
	pm_op} if HAVE_ACPI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These hypercalls are currently ACPI specific and implemented in
xen/drivers/acpi which is not implemented on ARM.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
---
 xen/Rules.mk         |    1 +
 xen/arch/arm/dummy.S |    2 --
 xen/common/sysctl.c  |    2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 507e9ab..ee54179 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -50,6 +50,7 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
+CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 1287e0b..3bf5226 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -16,13 +16,11 @@ DUMMY(create_grant_host_mapping);
 DUMMY(__cpu_die);
 DUMMY(__cpu_disable);
 DUMMY(__cpu_up);
-DUMMY(do_get_pm_info);
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(donate_page);
-DUMMY(do_pm_op);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f8f7cf8..fef0589 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -224,6 +224,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     }
     break;
 
+#ifdef HAS_ACPI
     case XEN_SYSCTL_get_pmstat:
     {
         ret = xsm_get_pmstat();
@@ -259,6 +260,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
         }
     }
     break;
+#endif
 
     case XEN_SYSCTL_page_offline_op:
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxJdi-0008Uh-Sx; Tue, 14 Feb 2012 14:45:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJdh-0008Ra-Lv
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329230744!11434099!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13055 invoked from network); 14 Feb 2012 14:45:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:45:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687127"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:13 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wk028250; Tue, 14 Feb 2012 06:44:12 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:44:00 +0000
Message-ID: <1329230641-18624-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/12] arm: define max_page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    2 ++
 xen/arch/arm/setup.c |    2 ++
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 67edb35..295938e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -28,7 +28,6 @@ DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(is_iomem_page);
-DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
 DUMMY(page_get_owner_and_reference);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0cff726..a0f39eb 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -43,6 +43,8 @@ unsigned long xenheap_virt_end;
 unsigned long frametable_base_mfn;
 unsigned long frametable_virt_end;
 
+unsigned long max_page;
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7762166..4c1d89c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -32,6 +32,7 @@
 #include <xen/softirq.h>
 #include <xen/keyhandler.h>
 #include <xen/cpu.h>
+#include <xen/pfn.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>
@@ -141,6 +142,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
                     pfn_to_paddr(xenheap_mfn_start + xenheap_pages + domheap_pages));
 
     setup_frametable_mappings(ram_start, ram_end);
+    max_page = PFN_DOWN(ram_end);
 
     /* Add xenheap memory that was not already added to the boot
        allocator. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxJdi-0008Uh-Sx; Tue, 14 Feb 2012 14:45:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxJdh-0008Ra-Lv
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329230744!11434099!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13055 invoked from network); 14 Feb 2012 14:45:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 14:45:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181687127"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 09:44:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 09:44:13 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1EEi2Wk028250; Tue, 14 Feb 2012 06:44:12 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 14:44:00 +0000
Message-ID: <1329230641-18624-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/12] arm: define max_page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    2 ++
 xen/arch/arm/setup.c |    2 ++
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 67edb35..295938e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -28,7 +28,6 @@ DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(is_iomem_page);
-DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
 DUMMY(page_get_owner_and_reference);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0cff726..a0f39eb 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -43,6 +43,8 @@ unsigned long xenheap_virt_end;
 unsigned long frametable_base_mfn;
 unsigned long frametable_virt_end;
 
+unsigned long max_page;
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7762166..4c1d89c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -32,6 +32,7 @@
 #include <xen/softirq.h>
 #include <xen/keyhandler.h>
 #include <xen/cpu.h>
+#include <xen/pfn.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>
@@ -141,6 +142,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
                     pfn_to_paddr(xenheap_mfn_start + xenheap_pages + domheap_pages));
 
     setup_frametable_mappings(ram_start, ram_end);
+    max_page = PFN_DOWN(ram_end);
 
     /* Add xenheap memory that was not already added to the boot
        allocator. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:50:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJiK-0001ME-Qs; Tue, 14 Feb 2012 14:50:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJiI-0001M5-Mx
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:50:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329231032!13318310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23847 invoked from network); 14 Feb 2012 14:50:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:50:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:50:55 +0000
Message-Id: <4F3A82C60200007800072EC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:50:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur> <1805920.cM9rJVskbD@amur>
	<4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
	<2263997.kVLThTfZaS@amur>
In-Reply-To: <2263997.kVLThTfZaS@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 15:30, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
>> Plus enforcing the buffer requirements to avoid CPU deadlock
>> (contiguous present pages, alignment). Failure to do so can hang the
>> CPU, and hence would represent a DoS vulnerability.
> 
> I'm not sure what you mean here. Are you speaking about the DS buffer?
> If yes, this is no problem, because the DS buffer addressm must be a domU
> virtual address. The processor only writes data into the buffer, if the
> domU is running so in the worst case the domU gets triggered a page fault
> or what I testet a triple fault occurs and the domU gets rebootet.

This certainly can be CPU model dependent, but on raw hardware
I know that not meeting the buffer constraints can hang (not triple
fault, perhaps a live lock) a CPU. Therefore, unless you can prove
this is impossible when running in VMX non-root, you will have to add
provisions for this (and this was the major reason keeping me from
trying to add DS support a year or two ago). At the very minimum
the whole functionality would otherwise need to be disabled by
default, and when enabled a prominent warning be issued (along
the lines of that of sync_console).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:50:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJiK-0001ME-Qs; Tue, 14 Feb 2012 14:50:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJiI-0001M5-Mx
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:50:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329231032!13318310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23847 invoked from network); 14 Feb 2012 14:50:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:50:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:50:55 +0000
Message-Id: <4F3A82C60200007800072EC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:50:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur> <1805920.cM9rJVskbD@amur>
	<4F3A6F3C0200007800072E77@nat28.tlf.novell.com>
	<2263997.kVLThTfZaS@amur>
In-Reply-To: <2263997.kVLThTfZaS@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 15:30, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
>> Plus enforcing the buffer requirements to avoid CPU deadlock
>> (contiguous present pages, alignment). Failure to do so can hang the
>> CPU, and hence would represent a DoS vulnerability.
> 
> I'm not sure what you mean here. Are you speaking about the DS buffer?
> If yes, this is no problem, because the DS buffer addressm must be a domU
> virtual address. The processor only writes data into the buffer, if the
> domU is running so in the worst case the domU gets triggered a page fault
> or what I testet a triple fault occurs and the domU gets rebootet.

This certainly can be CPU model dependent, but on raw hardware
I know that not meeting the buffer constraints can hang (not triple
fault, perhaps a live lock) a CPU. Therefore, unless you can prove
this is impossible when running in VMX non-root, you will have to add
provisions for this (and this was the major reason keeping me from
trying to add DS support a year or two ago). At the very minimum
the whole functionality would otherwise need to be disabled by
default, and when enabled a prominent warning be issued (along
the lines of that of sync_console).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:55:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJmc-0001bG-L0; Tue, 14 Feb 2012 14:55:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJmb-0001b2-LN
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:55:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329231299!11350723!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13457 invoked from network); 14 Feb 2012 14:54:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:54:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:55:29 +0000
Message-Id: <4F3A83D20200007800072ED4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:54:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBA94C2D2.0__="
Subject: [Xen-devel] [PATCH] x86: don't allow Dom0 to map MSI-X table
	writably
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBA94C2D2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the traditional qemu tree fixed to not use PROT_WRITE anymore in
the mmap() call for this region, and with the upstream qemu tree not
being capable of handling passthrough, yet, there's no need to treat
Dom specially here anymore.

This continues to leave unaddressed the case where PV guests map the
MSI-X table page(s) before setting up the first MSI-X interrupt (see
the original c/s 22182:68cc3c514a0a description for options).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -869,7 +869,7 @@ get_page_from_l1e(
             return -EINVAL;
         }
=20
-        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
+        if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
         dprintk(XENLOG_G_WARNING,




--=__PartBA94C2D2.0__=
Content-Type: text/plain; name="x86-MSI-X-dom0-ro.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-MSI-X-dom0-ro.patch"

x86: don't allow Dom0 to map MSI-X table writably=0A=0AWith the traditional=
 qemu tree fixed to not use PROT_WRITE anymore in=0Athe mmap() call for =
this region, and with the upstream qemu tree not=0Abeing capable of =
handling passthrough, yet, there's no need to treat=0ADom specially here =
anymore.=0A=0AThis continues to leave unaddressed the case where PV guests =
map the=0AMSI-X table page(s) before setting up the first MSI-X interrupt =
(see=0Athe original c/s 22182:68cc3c514a0a description for options).=0A=0AS=
igned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mm.c=
=0A+++ b/xen/arch/x86/mm.c=0A@@ -869,7 +869,7 @@ get_page_from_l1e(=0A     =
        return -EINVAL;=0A         }=0A =0A-        if ( !(l1f & _PAGE_RW) =
|| IS_PRIV(pg_owner) ||=0A+        if ( !(l1f & _PAGE_RW) ||=0A            =
  !rangeset_contains_singleton(mmio_ro_ranges, mfn) )=0A             =
return 0;=0A         dprintk(XENLOG_G_WARNING,=0A
--=__PartBA94C2D2.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartBA94C2D2.0__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:55:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14: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.xensource.com>)
	id 1RxJmc-0001bG-L0; Tue, 14 Feb 2012 14:55:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxJmb-0001b2-LN
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:55:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329231299!11350723!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13457 invoked from network); 14 Feb 2012 14:54:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 14:54:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:55:29 +0000
Message-Id: <4F3A83D20200007800072ED4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:54:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBA94C2D2.0__="
Subject: [Xen-devel] [PATCH] x86: don't allow Dom0 to map MSI-X table
	writably
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBA94C2D2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With the traditional qemu tree fixed to not use PROT_WRITE anymore in
the mmap() call for this region, and with the upstream qemu tree not
being capable of handling passthrough, yet, there's no need to treat
Dom specially here anymore.

This continues to leave unaddressed the case where PV guests map the
MSI-X table page(s) before setting up the first MSI-X interrupt (see
the original c/s 22182:68cc3c514a0a description for options).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -869,7 +869,7 @@ get_page_from_l1e(
             return -EINVAL;
         }
=20
-        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
+        if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
         dprintk(XENLOG_G_WARNING,




--=__PartBA94C2D2.0__=
Content-Type: text/plain; name="x86-MSI-X-dom0-ro.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-MSI-X-dom0-ro.patch"

x86: don't allow Dom0 to map MSI-X table writably=0A=0AWith the traditional=
 qemu tree fixed to not use PROT_WRITE anymore in=0Athe mmap() call for =
this region, and with the upstream qemu tree not=0Abeing capable of =
handling passthrough, yet, there's no need to treat=0ADom specially here =
anymore.=0A=0AThis continues to leave unaddressed the case where PV guests =
map the=0AMSI-X table page(s) before setting up the first MSI-X interrupt =
(see=0Athe original c/s 22182:68cc3c514a0a description for options).=0A=0AS=
igned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mm.c=
=0A+++ b/xen/arch/x86/mm.c=0A@@ -869,7 +869,7 @@ get_page_from_l1e(=0A     =
        return -EINVAL;=0A         }=0A =0A-        if ( !(l1f & _PAGE_RW) =
|| IS_PRIV(pg_owner) ||=0A+        if ( !(l1f & _PAGE_RW) ||=0A            =
  !rangeset_contains_singleton(mmio_ro_ranges, mfn) )=0A             =
return 0;=0A         dprintk(XENLOG_G_WARNING,=0A
--=__PartBA94C2D2.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartBA94C2D2.0__=--


From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:59:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJqM-0001md-IV; Tue, 14 Feb 2012 14:58:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxJqL-0001mT-Da
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:58:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231530!14279388!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDcyNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30817 invoked from network); 14 Feb 2012 14:58:50 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 14:58:50 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 1B7724B0091;
	Tue, 14 Feb 2012 06:58:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AuoBYsNwJ6yKNpvUq+JMNrwEgrz48KQhPDEHI7aMiFyl
	W/mRV554Fklq5IIpidRMvSccNJPD2kQMEQRVeLbDkE9cwRMjs19GHSlv1812mhJ6
	nvTsu3ihWxyxwaouZ5l9jeq31MzNNVBvRTiRguEcE2+HTpgi5c/HfHComfDjrRc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=e3P20OedZgYdUE8SrYIlO8/yiMU=; b=EYHsxutW
	06Z0q4bwCiOWO+8e3CJ3ee1HMKx1mBSdcGLWuc9eJrT9wF6F3XbEozOAxPDcIjkt
	ex6jvze2c3T0xPM+6dTgTtmV6sWjV8U8Q7sT0zB/fn0uF7Ba6QAzrMRwuJ9TCtP4
	rS+YH92PAVQg15qwqBD06RPRlFfgmh7zbhs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 6F9D74B008F; 
	Tue, 14 Feb 2012 06:58:49 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 06:58:50 -0800
Message-ID: <f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 06:58:50 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Mon, 13 Feb 2012 10:24:29 +0000
> From: Tim Deegan <tim@xen.org>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: xen-devel <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] 4.2 TODO update
> Message-ID: <20120213102429.GA88765@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> At 10:17 +0000 on 13 Feb (1329128265), Ian Campbell wrote:
>> This weeks update. I was away last Monday so this covers two weeks worth
>> of updates. I have dropped things which were marked as DONE in the last
>> update and added a bunch more DONE (so the list is shrinking!). Please
>> send me corrections (especially "done").
>>
>> hypervisor, blockers:
>>       * round-up of the closing of the security hole in MSI-X
>>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>>         access to MSI-X table pages). (Jan Beulich -- more fixes
>>         required than first thought, patches posted)
>>       * domctls / sysctls set up to modify scheduler parameters, like
>>         the credit1 timeslice and schedule rate. (George Dunlap)
>>       * get the interface changes for sharing/paging/mem-events done and
>>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>>         Andres Lagar-Cavilla et al)
>>               * sharing patches posted
>
> The hypervisor interface changes for sharing and events have gone in;
> there's a libxc-level change (to do with mlock()ing buffers) that ought
> to go in before 4.2, if at all.

Ian, it's probably OK to mark the paging/sharing as DONE.

There is the outstanding issue of properly mapping the event rings, which
ties into the mlock()ing buffers bit Tim mentions. I think we all want it
Done Right for 4.2. And that will likely not be the patch I last posted.
Perhaps best to rename the bullet point?

In the "nice to have" category, "properly synchronized p2m lookups" have
also gone into the tree.

>
> There's a paging+waitqueues patch that's been posted but needs a bit more
> work still; I'll try and look at it on Thursday.
>

This one is thorny. Right now we seem to have fairly stable paging. (Dare
I say bug-free? I dare not, lest I be smitten) I surmise other consumers
of the interface would agree with this (Olaf? Huawei?)

Wait queues have a significant potential for damage, unless we use them in
very specific contexts. I worry we'll drop from A- to C in terms of
stability. And right now I have not crashed hosts with paging in a long
while, whereas wait queues will definitely introduce that.

Why? Because it's really really hard to guarantee we'll go to sleep in an
atomic context. The main use for wait queues (imho) is in hvm_copy, and
there's a zillion paths going into hvm_copy (copy_from/to_user!) with all
ways of bumping the preemption count.

I'm dealing with this at the moment in a different context: running out of
memory to unshare pages when writing to them in the hypervisor. And we
simply cannot throw a wait queue sleep in there carelessly.

I'm not saying this is impossible, I'm saying there's a long path ahead,
and since it's all *internal* to the hypervisor, my vote is to be very
conservative for the 4.2 window.

Thanks!
Andres

> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 14:59:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 14:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJqM-0001md-IV; Tue, 14 Feb 2012 14:58:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxJqL-0001mT-Da
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 14:58:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231530!14279388!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDcyNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30817 invoked from network); 14 Feb 2012 14:58:50 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 14:58:50 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 1B7724B0091;
	Tue, 14 Feb 2012 06:58:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AuoBYsNwJ6yKNpvUq+JMNrwEgrz48KQhPDEHI7aMiFyl
	W/mRV554Fklq5IIpidRMvSccNJPD2kQMEQRVeLbDkE9cwRMjs19GHSlv1812mhJ6
	nvTsu3ihWxyxwaouZ5l9jeq31MzNNVBvRTiRguEcE2+HTpgi5c/HfHComfDjrRc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=e3P20OedZgYdUE8SrYIlO8/yiMU=; b=EYHsxutW
	06Z0q4bwCiOWO+8e3CJ3ee1HMKx1mBSdcGLWuc9eJrT9wF6F3XbEozOAxPDcIjkt
	ex6jvze2c3T0xPM+6dTgTtmV6sWjV8U8Q7sT0zB/fn0uF7Ba6QAzrMRwuJ9TCtP4
	rS+YH92PAVQg15qwqBD06RPRlFfgmh7zbhs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 6F9D74B008F; 
	Tue, 14 Feb 2012 06:58:49 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 06:58:50 -0800
Message-ID: <f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 06:58:50 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Mon, 13 Feb 2012 10:24:29 +0000
> From: Tim Deegan <tim@xen.org>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: xen-devel <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] 4.2 TODO update
> Message-ID: <20120213102429.GA88765@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> At 10:17 +0000 on 13 Feb (1329128265), Ian Campbell wrote:
>> This weeks update. I was away last Monday so this covers two weeks worth
>> of updates. I have dropped things which were marked as DONE in the last
>> update and added a bunch more DONE (so the list is shrinking!). Please
>> send me corrections (especially "done").
>>
>> hypervisor, blockers:
>>       * round-up of the closing of the security hole in MSI-X
>>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>>         access to MSI-X table pages). (Jan Beulich -- more fixes
>>         required than first thought, patches posted)
>>       * domctls / sysctls set up to modify scheduler parameters, like
>>         the credit1 timeslice and schedule rate. (George Dunlap)
>>       * get the interface changes for sharing/paging/mem-events done and
>>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>>         Andres Lagar-Cavilla et al)
>>               * sharing patches posted
>
> The hypervisor interface changes for sharing and events have gone in;
> there's a libxc-level change (to do with mlock()ing buffers) that ought
> to go in before 4.2, if at all.

Ian, it's probably OK to mark the paging/sharing as DONE.

There is the outstanding issue of properly mapping the event rings, which
ties into the mlock()ing buffers bit Tim mentions. I think we all want it
Done Right for 4.2. And that will likely not be the patch I last posted.
Perhaps best to rename the bullet point?

In the "nice to have" category, "properly synchronized p2m lookups" have
also gone into the tree.

>
> There's a paging+waitqueues patch that's been posted but needs a bit more
> work still; I'll try and look at it on Thursday.
>

This one is thorny. Right now we seem to have fairly stable paging. (Dare
I say bug-free? I dare not, lest I be smitten) I surmise other consumers
of the interface would agree with this (Olaf? Huawei?)

Wait queues have a significant potential for damage, unless we use them in
very specific contexts. I worry we'll drop from A- to C in terms of
stability. And right now I have not crashed hosts with paging in a long
while, whereas wait queues will definitely introduce that.

Why? Because it's really really hard to guarantee we'll go to sleep in an
atomic context. The main use for wait queues (imho) is in hvm_copy, and
there's a zillion paths going into hvm_copy (copy_from/to_user!) with all
ways of bumping the preemption count.

I'm dealing with this at the moment in a different context: running out of
memory to unshare pages when writing to them in the hypervisor. And we
simply cannot throw a wait queue sleep in there carelessly.

I'm not saying this is impossible, I'm saying there's a long path ahead,
and since it's all *internal* to the hypervisor, my vote is to be very
conservative for the 4.2 window.

Thanks!
Andres

> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:01:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJso-0001w0-4b; Tue, 14 Feb 2012 15:01:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJsm-0001vo-0w
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:01:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329231681!13328290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32505 invoked from network); 14 Feb 2012 15:01:22 -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;
	14 Feb 2012 15:01:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10688963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:01:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 15:01:21 +0000
Date: Tue, 14 Feb 2012 15:05:32 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v5 0/6] prevent QEMU from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents QEMU from waking up needlessly on Xen
several times a second in order to check some timers.


I would like some comments (or some acks ;-) on patch #4 and #5.


The first patch stops QEMU from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that QEMU doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch makes main_loop_wait wait indefinitely on select
unless we actually need a timeout.



Changes in v5:

- remove the last patch to increase the timeout to 1h, replace it with a
patch to wait indefinitely on select unless we need a timeout.


Changes in v4:

- do not initialize pcspk on xen;

- disable rtc_clock only when it points to the host_clock (the default);

- make sure it compiles on older xen versions.


Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.



Shortlog and diffstat follow:

 async.c          |    2 +-
 hw/pc.c          |    9 ++++++---
 main-loop.c      |   21 ++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |   33 +++++++++++++++++----------------
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 xen-all.c        |   49 +++++++++++++++++++++++++++++++++++++++++++------
 10 files changed, 92 insertions(+), 37 deletions(-)


Stefano Stabellini (6):
      xen: do not initialize the interval timer and PCSPK emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      main_loop_wait: block indefinitely


A git tree, based on 9d4df9c02866f39d3eef105033091f367cc7c29e, is available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-5

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:01:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:01:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJso-0001w0-4b; Tue, 14 Feb 2012 15:01:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJsm-0001vo-0w
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:01:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329231681!13328290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32505 invoked from network); 14 Feb 2012 15:01:22 -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;
	14 Feb 2012 15:01:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10688963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:01:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 15:01:21 +0000
Date: Tue, 14 Feb 2012 15:05:32 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v5 0/6] prevent QEMU from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents QEMU from waking up needlessly on Xen
several times a second in order to check some timers.


I would like some comments (or some acks ;-) on patch #4 and #5.


The first patch stops QEMU from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that QEMU doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch makes main_loop_wait wait indefinitely on select
unless we actually need a timeout.



Changes in v5:

- remove the last patch to increase the timeout to 1h, replace it with a
patch to wait indefinitely on select unless we need a timeout.


Changes in v4:

- do not initialize pcspk on xen;

- disable rtc_clock only when it points to the host_clock (the default);

- make sure it compiles on older xen versions.


Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.



Shortlog and diffstat follow:

 async.c          |    2 +-
 hw/pc.c          |    9 ++++++---
 main-loop.c      |   21 ++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |   33 +++++++++++++++++----------------
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 xen-all.c        |   49 +++++++++++++++++++++++++++++++++++++++++++------
 10 files changed, 92 insertions(+), 37 deletions(-)


Stefano Stabellini (6):
      xen: do not initialize the interval timer and PCSPK emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      main_loop_wait: block indefinitely


A git tree, based on 9d4df9c02866f39d3eef105033091f367cc7c29e, is available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-5

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuS-00023F-Mk; Tue, 14 Feb 2012 15:03:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuR-00022d-QX
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329231783!13320895!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22992 invoked from network); 14 Feb 2012 15:03:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:03:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181690788"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:02 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxc028319;
	Tue, 14 Feb 2012 07:02:54 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:13 +0000
Message-ID: <1329232038-12349-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 1/6] xen: do not initialize the interval
	timer and PCSPK emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT and PCSPK are emulated by the hypervisor so we don't need to emulate
them in Qemu: this patch prevents Qemu from waking up needlessly at
PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 7f3aa65..ab9775e 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -44,6 +44,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1139,7 +1140,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1160,8 +1161,10 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
-    pcspk_init(pit);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+        pcspk_init(pit);
+    }
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
         if (serial_hds[i]) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuS-00023F-Mk; Tue, 14 Feb 2012 15:03:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuR-00022d-QX
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329231783!13320895!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22992 invoked from network); 14 Feb 2012 15:03:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:03:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181690788"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:02 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxc028319;
	Tue, 14 Feb 2012 07:02:54 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:13 +0000
Message-ID: <1329232038-12349-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 1/6] xen: do not initialize the interval
	timer and PCSPK emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT and PCSPK are emulated by the hypervisor so we don't need to emulate
them in Qemu: this patch prevents Qemu from waking up needlessly at
PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 7f3aa65..ab9775e 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -44,6 +44,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1139,7 +1140,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1160,8 +1161,10 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
-    pcspk_init(pit);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+        pcspk_init(pit);
+    }
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
         if (serial_hds[i]) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuZ-00024R-Rc; Tue, 14 Feb 2012 15:03:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuX-000238-U0
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231790!14280059!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15159 invoked from network); 14 Feb 2012 15:03:11 -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 Feb 2012 15:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21934451"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxe028319;
	Tue, 14 Feb 2012 07:02:59 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:15 +0000
Message-ID: <1329232038-12349-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 3/6] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   45 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 101c962..0ce8002 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -59,6 +59,9 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 }
 #  define FMT_ioreq_size "u"
 #endif
+#ifndef HVM_PARAM_BUFIOREQ_EVTCHN
+#define HVM_PARAM_BUFIOREQ_EVTCHN 26
+#endif
 
 #define BUFFER_IO_MAX_DELAY  100
 
@@ -77,6 +80,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -549,6 +554,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -697,16 +708,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -731,15 +744,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -869,7 +888,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -921,6 +939,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -970,6 +989,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuZ-00024R-Rc; Tue, 14 Feb 2012 15:03:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuX-000238-U0
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231790!14280059!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15159 invoked from network); 14 Feb 2012 15:03:11 -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 Feb 2012 15:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21934451"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:10 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxe028319;
	Tue, 14 Feb 2012 07:02:59 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:15 +0000
Message-ID: <1329232038-12349-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 3/6] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   45 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 101c962..0ce8002 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -59,6 +59,9 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 }
 #  define FMT_ioreq_size "u"
 #endif
+#ifndef HVM_PARAM_BUFIOREQ_EVTCHN
+#define HVM_PARAM_BUFIOREQ_EVTCHN 26
+#endif
 
 #define BUFFER_IO_MAX_DELAY  100
 
@@ -77,6 +80,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -549,6 +554,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -697,16 +708,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -731,15 +744,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -869,7 +888,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -921,6 +939,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -970,6 +989,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuc-00025q-Rt; Tue, 14 Feb 2012 15:03:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJub-00023b-IM
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231790!14280059!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15398 invoked from network); 14 Feb 2012 15:03:15 -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 Feb 2012 15:03:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21934454"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:14 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxg028319;
	Tue, 14 Feb 2012 07:03:02 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:17 +0000
Message-ID: <1329232038-12349-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 5/6] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 29410f1..de20852 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuY-000249-Ef; Tue, 14 Feb 2012 15:03:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuX-000230-72
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231790!14280059!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15116 invoked from network); 14 Feb 2012 15:03:11 -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 Feb 2012 15:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21934450"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxd028319;
	Tue, 14 Feb 2012 07:02:57 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:14 +0000
Message-ID: <1329232038-12349-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index fd39168..101c962 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -514,6 +514,10 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    /* if rtc_clock is left to default (host_clock), disable it */
+    if (rtc_clock == host_clock) {
+        qemu_clock_enable(rtc_clock, false);
+    }
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuY-000249-Ef; Tue, 14 Feb 2012 15:03:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuX-000230-72
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231790!14280059!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15116 invoked from network); 14 Feb 2012 15:03:11 -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 Feb 2012 15:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21934450"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxd028319;
	Tue, 14 Feb 2012 07:02:57 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:14 +0000
Message-ID: <1329232038-12349-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index fd39168..101c962 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -514,6 +514,10 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    /* if rtc_clock is left to default (host_clock), disable it */
+    if (rtc_clock == host_clock) {
+        qemu_clock_enable(rtc_clock, false);
+    }
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuc-00025q-Rt; Tue, 14 Feb 2012 15:03:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJub-00023b-IM
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329231790!14280059!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15398 invoked from network); 14 Feb 2012 15:03:15 -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 Feb 2012 15:03:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21934454"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:14 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxg028319;
	Tue, 14 Feb 2012 07:03:02 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:17 +0000
Message-ID: <1329232038-12349-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 5/6] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 29410f1..de20852 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuY-00023v-2w; Tue, 14 Feb 2012 15:03:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuW-00022y-LU
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329231783!13320895!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23267 invoked from network); 14 Feb 2012 15:03:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181690815"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxf028319;
	Tue, 14 Feb 2012 07:03:00 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:16 +0000
Message-ID: <1329232038-12349-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 4/6] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a22f27e..29410f1 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -696,13 +696,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -757,16 +761,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJuY-00023v-2w; Tue, 14 Feb 2012 15:03:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJuW-00022y-LU
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329231783!13320895!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23267 invoked from network); 14 Feb 2012 15:03:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181690815"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxf028319;
	Tue, 14 Feb 2012 07:03:00 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:16 +0000
Message-ID: <1329232038-12349-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 4/6] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a22f27e..29410f1 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -696,13 +696,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -757,16 +761,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJub-00025C-Cn; Tue, 14 Feb 2012 15:03:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJua-00024M-37
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:20 +0000
Received: from [85.158.139.83:42179] by server-2.bemta-5.messagelabs.com id
	E7/20-20263-7B77A3F4; Tue, 14 Feb 2012 15:03:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329231797!15041501!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6688 invoked from network); 14 Feb 2012 15:03:18 -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;
	14 Feb 2012 15:03:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181690848"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxh028319;
	Tue, 14 Feb 2012 07:03:04 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:18 +0000
Message-ID: <1329232038-12349-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 6/6] main_loop_wait: block indefinitely
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

- remove qemu_calculate_timeout;

- explicitly size timeout to uint32_t;

- introduce slirp_update_timeout;

- pass NULL as timeout argument to select in case timeout is the maximum
value;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paul Brook <paul@codesourcery.com>
---
 async.c          |    2 +-
 main-loop.c      |   21 ++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |    5 -----
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 8 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index db23de0..c8192fe 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -369,7 +369,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
     }
 }
 
-static void os_host_main_loop_wait(int *timeout)
+static void os_host_main_loop_wait(uint32_t *timeout)
 {
     int ret, ret2, i;
     PollingEntry *pe;
@@ -413,7 +413,7 @@ static void os_host_main_loop_wait(int *timeout)
     *timeout = 0;
 }
 #else
-static inline void os_host_main_loop_wait(int *timeout)
+static inline void os_host_main_loop_wait(uint32_t *timeout)
 {
 }
 #endif
@@ -422,21 +422,17 @@ int main_loop_wait(int nonblocking)
 {
     fd_set rfds, wfds, xfds;
     int ret, nfds;
-    struct timeval tv;
-    int timeout;
+    struct timeval tv, *tvarg = NULL;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
     os_host_main_loop_wait(&timeout);
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
@@ -445,16 +441,23 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
diff --git a/main-loop.h b/main-loop.h
index 4987041..e557a0a 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -364,6 +364,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..3e1ce08 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index de17f3b..f1386d5 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -62,7 +62,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/qemu-tool.c b/qemu-tool.c
index 183a583..470345e 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -91,6 +91,10 @@ int qemu_init_main_loop(void)
     return main_loop_init();
 }
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+}
+
 void slirp_select_fill(int *pnfds, fd_set *readfds,
                        fd_set *writefds, fd_set *xfds)
 {
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..77527ad 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -15,6 +15,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
                   struct in_addr vnameserver, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
+void slirp_update_timeout(uint32_t *timeout);
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds);
 
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 19d69eb..418f8d0 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -255,6 +255,13 @@ void slirp_cleanup(Slirp *slirp)
 #define CONN_CANFRCV(so) (((so)->so_state & (SS_FCANTRCVMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
 #define UPD_NFDS(x) if (nfds < (x)) nfds = (x)
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+    if (!QTAILQ_EMPTY(&slirp_instances)) {
+        *timeout = MIN(1000, *timeout);
+    }
+}
+
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJub-00025C-Cn; Tue, 14 Feb 2012 15:03:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJua-00024M-37
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:03:20 +0000
Received: from [85.158.139.83:42179] by server-2.bemta-5.messagelabs.com id
	E7/20-20263-7B77A3F4; Tue, 14 Feb 2012 15:03:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329231797!15041501!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6688 invoked from network); 14 Feb 2012 15:03:18 -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;
	14 Feb 2012 15:03:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="181690848"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:03:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 10:03:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EF2rxh028319;
	Tue, 14 Feb 2012 07:03:04 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 15:07:18 +0000
Message-ID: <1329232038-12349-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141455160.7456@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v5 6/6] main_loop_wait: block indefinitely
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

- remove qemu_calculate_timeout;

- explicitly size timeout to uint32_t;

- introduce slirp_update_timeout;

- pass NULL as timeout argument to select in case timeout is the maximum
value;

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Paul Brook <paul@codesourcery.com>
---
 async.c          |    2 +-
 main-loop.c      |   21 ++++++++++++---------
 main-loop.h      |    2 +-
 qemu-timer.c     |    5 -----
 qemu-timer.h     |    1 -
 qemu-tool.c      |    4 ++++
 slirp/libslirp.h |    1 +
 slirp/slirp.c    |    7 +++++++
 8 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/async.c b/async.c
index 332d511..ecdaf15 100644
--- a/async.c
+++ b/async.c
@@ -120,7 +120,7 @@ void qemu_bh_delete(QEMUBH *bh)
     bh->deleted = 1;
 }
 
-void qemu_bh_update_timeout(int *timeout)
+void qemu_bh_update_timeout(uint32_t *timeout)
 {
     QEMUBH *bh;
 
diff --git a/main-loop.c b/main-loop.c
index db23de0..c8192fe 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -369,7 +369,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
     }
 }
 
-static void os_host_main_loop_wait(int *timeout)
+static void os_host_main_loop_wait(uint32_t *timeout)
 {
     int ret, ret2, i;
     PollingEntry *pe;
@@ -413,7 +413,7 @@ static void os_host_main_loop_wait(int *timeout)
     *timeout = 0;
 }
 #else
-static inline void os_host_main_loop_wait(int *timeout)
+static inline void os_host_main_loop_wait(uint32_t *timeout)
 {
 }
 #endif
@@ -422,21 +422,17 @@ int main_loop_wait(int nonblocking)
 {
     fd_set rfds, wfds, xfds;
     int ret, nfds;
-    struct timeval tv;
-    int timeout;
+    struct timeval tv, *tvarg = NULL;
+    uint32_t timeout = UINT32_MAX;
 
     if (nonblocking) {
         timeout = 0;
     } else {
-        timeout = qemu_calculate_timeout();
         qemu_bh_update_timeout(&timeout);
     }
 
     os_host_main_loop_wait(&timeout);
 
-    tv.tv_sec = timeout / 1000;
-    tv.tv_usec = (timeout % 1000) * 1000;
-
     /* poll any events */
     /* XXX: separate device handlers from system ones */
     nfds = -1;
@@ -445,16 +441,23 @@ int main_loop_wait(int nonblocking)
     FD_ZERO(&xfds);
 
 #ifdef CONFIG_SLIRP
+    slirp_update_timeout(&timeout);
     slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
 #endif
     qemu_iohandler_fill(&nfds, &rfds, &wfds, &xfds);
     glib_select_fill(&nfds, &rfds, &wfds, &xfds, &tv);
 
+    if (timeout < UINT32_MAX) {
+        tvarg = &tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000;
+    }
+
     if (timeout > 0) {
         qemu_mutex_unlock_iothread();
     }
 
-    ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
+    ret = select(nfds + 1, &rfds, &wfds, &xfds, tvarg);
 
     if (timeout > 0) {
         qemu_mutex_lock_iothread();
diff --git a/main-loop.h b/main-loop.h
index 4987041..e557a0a 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -364,6 +364,6 @@ void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int rc
 
 void qemu_bh_schedule_idle(QEMUBH *bh);
 int qemu_bh_poll(void);
-void qemu_bh_update_timeout(int *timeout);
+void qemu_bh_update_timeout(uint32_t *timeout);
 
 #endif
diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..3e1ce08 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -821,8 +821,3 @@ fail:
     return err;
 }
 
-int qemu_calculate_timeout(void)
-{
-    return 1000;
-}
-
diff --git a/qemu-timer.h b/qemu-timer.h
index de17f3b..f1386d5 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -62,7 +62,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 void qemu_run_all_timers(void);
 int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
-int qemu_calculate_timeout(void);
 void init_clocks(void);
 int init_timer_alarm(void);
 
diff --git a/qemu-tool.c b/qemu-tool.c
index 183a583..470345e 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -91,6 +91,10 @@ int qemu_init_main_loop(void)
     return main_loop_init();
 }
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+}
+
 void slirp_select_fill(int *pnfds, fd_set *readfds,
                        fd_set *writefds, fd_set *xfds)
 {
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 890fd86..77527ad 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -15,6 +15,7 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
                   struct in_addr vnameserver, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
+void slirp_update_timeout(uint32_t *timeout);
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds);
 
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 19d69eb..418f8d0 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -255,6 +255,13 @@ void slirp_cleanup(Slirp *slirp)
 #define CONN_CANFRCV(so) (((so)->so_state & (SS_FCANTRCVMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
 #define UPD_NFDS(x) if (nfds < (x)) nfds = (x)
 
+void slirp_update_timeout(uint32_t *timeout)
+{
+    if (!QTAILQ_EMPTY(&slirp_instances)) {
+        *timeout = MIN(1000, *timeout);
+    }
+}
+
 void slirp_select_fill(int *pnfds,
                        fd_set *readfds, fd_set *writefds, fd_set *xfds)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:07:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJy2-0002vh-Ke; Tue, 14 Feb 2012 15:06:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxJy1-0002uo-Pw
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:06:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329232007!9115266!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23914 invoked from network); 14 Feb 2012 15:06:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:06:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxJxt-0002aR-Oe; Tue, 14 Feb 2012 15:06:45 +0000
Date: Tue, 14 Feb 2012 15:06:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120214150645.GA9818@ocelot.phlegethon.org>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:43 +0000 on 14 Feb (1329230611), Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against current unstable. #6 and #9 touch common code.

For the ARM parts: Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:07:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJy2-0002vh-Ke; Tue, 14 Feb 2012 15:06:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxJy1-0002uo-Pw
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:06:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329232007!9115266!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23914 invoked from network); 14 Feb 2012 15:06:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:06:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxJxt-0002aR-Oe; Tue, 14 Feb 2012 15:06:45 +0000
Date: Tue, 14 Feb 2012 15:06:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120214150645.GA9818@ocelot.phlegethon.org>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:43 +0000 on 14 Feb (1329230611), Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against current unstable. #6 and #9 touch common code.

For the ARM parts: Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:07:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJyk-00032h-2h; Tue, 14 Feb 2012 15:07:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJyi-00032U-GY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:07:36 +0000
Received: from [85.158.139.83:18398] by server-1.bemta-5.messagelabs.com id
	DF/74-28458-7B87A3F4; Tue, 14 Feb 2012 15:07:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329232055!15038498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23737 invoked from network); 14 Feb 2012 15:07:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10689177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:07:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 15:07:35 +0000
Date: Tue, 14 Feb 2012 15:11:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329140965.31256.109.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141511470.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329140965.31256.109.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> 8<---------------------------------------------------------------
> 
> From 810e27651f0f883bab01f55e804fe733b92dd824 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 13 Feb 2012 13:46:53 +0000
> Subject: [PATCH] arm: Set XEN_COMPILE_ARCH correctly from "umame -m" on ARM

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Config.mk |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Config.mk b/Config.mk
> index e2dc4b9..df34718 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
>  debug ?= y
>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
> -                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
> +                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
>  XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
>  XEN_OS              ?= $(shell uname -s)
>  
> -- 
> 1.7.8.3
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:07:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxJyk-00032h-2h; Tue, 14 Feb 2012 15:07:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxJyi-00032U-GY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:07:36 +0000
Received: from [85.158.139.83:18398] by server-1.bemta-5.messagelabs.com id
	DF/74-28458-7B87A3F4; Tue, 14 Feb 2012 15:07:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329232055!15038498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23737 invoked from network); 14 Feb 2012 15:07:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10689177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:07:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 15:07:35 +0000
Date: Tue, 14 Feb 2012 15:11:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329140965.31256.109.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141511470.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329140965.31256.109.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> 8<---------------------------------------------------------------
> 
> From 810e27651f0f883bab01f55e804fe733b92dd824 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 13 Feb 2012 13:46:53 +0000
> Subject: [PATCH] arm: Set XEN_COMPILE_ARCH correctly from "umame -m" on ARM

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Config.mk |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Config.mk b/Config.mk
> index e2dc4b9..df34718 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
>  debug ?= y
>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
> -                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
> +                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
>  XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
>  XEN_OS              ?= $(shell uname -s)
>  
> -- 
> 1.7.8.3
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxK65-0003QW-2v; Tue, 14 Feb 2012 15:15: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 1RxK63-0003QO-5I
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:15:11 +0000
Received: from [85.158.143.35:61848] by server-2.bemta-4.messagelabs.com id
	27/B3-17550-E7A7A3F4; Tue, 14 Feb 2012 15:15:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329232508!2833929!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10458 invoked from network); 14 Feb 2012 15:15:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:15:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:56:46 +0000
Message-Id: <4F3A841C0200007800072ED7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:56:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
	<1329132778.31256.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329132778.31256.61.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 12:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-13 at 11:29 +0000, Jan Beulich wrote:
>> >>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > hypervisor, blockers:
>> >       * round-up of the closing of the security hole in MSI-X
>> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>> >         access to MSI-X table pages). (Jan Beulich -- more fixes
>> >         required than first thought, patches posted)
>> 
>> The only one currently open is the one removing write permission for
>> Dom0.
> 
> Oh, I thought you had found another issue which required further
> patches. Did I misunderstand or did they go in already?
> 
>>  The intention was to get this in after the qemu usptream pass
>> through patch series got adjusted along the lines of what was done
>> to qemu traditional, and while this was promise to happen soon after
>> New Year I didn't hear back anything from Anthony or Stefano.
>> 
>> Question is whether, given that the patch series in question isn't in
>> anything that is or will soon be released, it makes sense to push the
>> hypervisor change without waiting for that fixup.
> 
> I don't think it is necessary to wait for the qemu-upstream patch series
> to be updated for this, is it?

Patch just sent out. Once that's in, the issue should be fully addressed
for HVM guests (the situation with PV guests is explained in the patch).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxK65-0003QW-2v; Tue, 14 Feb 2012 15:15: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 1RxK63-0003QO-5I
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:15:11 +0000
Received: from [85.158.143.35:61848] by server-2.bemta-4.messagelabs.com id
	27/B3-17550-E7A7A3F4; Tue, 14 Feb 2012 15:15:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329232508!2833929!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10458 invoked from network); 14 Feb 2012 15:15:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:15:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 14:56:46 +0000
Message-Id: <4F3A841C0200007800072ED7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 14:56:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<4F390246020000780007285F@nat28.tlf.novell.com>
	<1329132778.31256.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329132778.31256.61.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.02.12 at 12:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-13 at 11:29 +0000, Jan Beulich wrote:
>> >>> On 13.02.12 at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > hypervisor, blockers:
>> >       * round-up of the closing of the security hole in MSI-X
>> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>> >         access to MSI-X table pages). (Jan Beulich -- more fixes
>> >         required than first thought, patches posted)
>> 
>> The only one currently open is the one removing write permission for
>> Dom0.
> 
> Oh, I thought you had found another issue which required further
> patches. Did I misunderstand or did they go in already?
> 
>>  The intention was to get this in after the qemu usptream pass
>> through patch series got adjusted along the lines of what was done
>> to qemu traditional, and while this was promise to happen soon after
>> New Year I didn't hear back anything from Anthony or Stefano.
>> 
>> Question is whether, given that the patch series in question isn't in
>> anything that is or will soon be released, it makes sense to push the
>> hypervisor change without waiting for that fixup.
> 
> I don't think it is necessary to wait for the qemu-upstream patch series
> to be updated for this, is it?

Patch just sent out. Once that's in, the issue should be fully addressed
for HVM guests (the situation with PV guests is explained in the patch).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:18:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15: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.xensource.com>)
	id 1RxK8w-0003eR-OG; Tue, 14 Feb 2012 15:18:10 +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 1RxK8u-0003df-Ph
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:18:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329232610!62813989!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32338 invoked from network); 14 Feb 2012 15:16:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 15:16:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329232682; l=705;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ECSVpkeEOf5VlqsLfEgWCaLX3Dc=;
	b=enugasJiL1ws6rbh7Glu6VLTF3WHHvgVrEg7LLvbhXq9cnpnphsUk7aF06I/thNxeWb
	EhFVbD6hwtWTrMy8/BIElE86f6BrKoYbQyGuaAp0Ukf/l+m8P7WOnxhLWD3gBueYTIc5i
	6urMdym8dSp+gZkTilqVyf1S1trmSr3x8HE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (cohen mo48) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R056a0o1EFGAft ;
	Tue, 14 Feb 2012 16:17:56 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B0EB518637; Tue, 14 Feb 2012 16:18:03 +0100 (CET)
Date: Tue, 14 Feb 2012 16:18:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214151803.GA22116@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> Why? Because it's really really hard to guarantee we'll go to sleep in an
> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> there's a zillion paths going into hvm_copy (copy_from/to_user!) with all
> ways of bumping the preemption count.

If the guests pagetable is paged out this code path will trigger, then
one of the hypercalls returns an error and the guest runs into a BUG().
I think it was decrease_reservation, or similar.
Another thing reported by Huawei on this list was somewhere in the
emulation code where a gfn_to_mfn() failed.

What other way exist to make paging 100% transparent to the guest?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:18:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15: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.xensource.com>)
	id 1RxK8w-0003eR-OG; Tue, 14 Feb 2012 15:18:10 +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 1RxK8u-0003df-Ph
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:18:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329232610!62813989!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32338 invoked from network); 14 Feb 2012 15:16:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 15:16:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329232682; l=705;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ECSVpkeEOf5VlqsLfEgWCaLX3Dc=;
	b=enugasJiL1ws6rbh7Glu6VLTF3WHHvgVrEg7LLvbhXq9cnpnphsUk7aF06I/thNxeWb
	EhFVbD6hwtWTrMy8/BIElE86f6BrKoYbQyGuaAp0Ukf/l+m8P7WOnxhLWD3gBueYTIc5i
	6urMdym8dSp+gZkTilqVyf1S1trmSr3x8HE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (cohen mo48) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R056a0o1EFGAft ;
	Tue, 14 Feb 2012 16:17:56 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B0EB518637; Tue, 14 Feb 2012 16:18:03 +0100 (CET)
Date: Tue, 14 Feb 2012 16:18:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214151803.GA22116@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> Why? Because it's really really hard to guarantee we'll go to sleep in an
> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> there's a zillion paths going into hvm_copy (copy_from/to_user!) with all
> ways of bumping the preemption count.

If the guests pagetable is paged out this code path will trigger, then
one of the hypercalls returns an error and the guest runs into a BUG().
I think it was decrease_reservation, or similar.
Another thing reported by Huawei on this list was somewhere in the
emulation code where a gfn_to_mfn() failed.

What other way exist to make paging 100% transparent to the guest?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:21:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15: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.xensource.com>)
	id 1RxKCC-0003v9-SA; Tue, 14 Feb 2012 15:21:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxKCB-0003uX-I1
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:21:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329232884!14778593!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11024 invoked from network); 14 Feb 2012 15:21:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 15:21:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329232884; l=484;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=3CaAGgeh+tIZi5JJGZVE/xs6L1U=;
	b=kegsbX36piQclZ92CLgUBveJn3nh7F/aQLt++FreKf5ZhiaX2e+mFQeAwTUT/Ta49DH
	jsUCFvAgukFid2SW3cDR2+JosCnvzOzYP27DNCVHZ3LkYJUaE5KuetIM4BUV566rcm3MP
	4kclbLi6AWJyEnKTHFlFj7jrHnCzvAE7u+E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (fruni mo21) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6040a4o1EDxa2S ;
	Tue, 14 Feb 2012 16:21:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E555D18637; Tue, 14 Feb 2012 16:21:09 +0100 (CET)
Date: Tue, 14 Feb 2012 16:21:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120214152109.GB22116@aepfle.de>
References: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
	<4F3A7E540200007800072EB6@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3A7E540200007800072EB6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Jan Beulich wrote:

> >>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> >> Below/attached a fixed version of the patch.
> > 
> > I get some mismatch after migration, both hosts run the same xen binary.
> 
> Are you sure about that? I'm asking because ...

Yes.
But I will move to another source host since the current one has now
only a 10MBit/sec connection for some reason, so I will double check
that both run indeed the same code.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:21:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15: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.xensource.com>)
	id 1RxKCC-0003v9-SA; Tue, 14 Feb 2012 15:21:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxKCB-0003uX-I1
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:21:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329232884!14778593!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11024 invoked from network); 14 Feb 2012 15:21:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 15:21:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329232884; l=484;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=3CaAGgeh+tIZi5JJGZVE/xs6L1U=;
	b=kegsbX36piQclZ92CLgUBveJn3nh7F/aQLt++FreKf5ZhiaX2e+mFQeAwTUT/Ta49DH
	jsUCFvAgukFid2SW3cDR2+JosCnvzOzYP27DNCVHZ3LkYJUaE5KuetIM4BUV566rcm3MP
	4kclbLi6AWJyEnKTHFlFj7jrHnCzvAE7u+E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (fruni mo21) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6040a4o1EDxa2S ;
	Tue, 14 Feb 2012 16:21:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E555D18637; Tue, 14 Feb 2012 16:21:09 +0100 (CET)
Date: Tue, 14 Feb 2012 16:21:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120214152109.GB22116@aepfle.de>
References: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
	<4F3A7E540200007800072EB6@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3A7E540200007800072EB6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Jan Beulich wrote:

> >>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> >> Below/attached a fixed version of the patch.
> > 
> > I get some mismatch after migration, both hosts run the same xen binary.
> 
> Are you sure about that? I'm asking because ...

Yes.
But I will move to another source host since the current one has now
only a 10MBit/sec connection for some reason, so I will double check
that both run indeed the same code.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:25:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKG5-0004Aj-Jw; Tue, 14 Feb 2012 15:25:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>)
	id 1RxKG3-0004AQ-5F; Tue, 14 Feb 2012 15:25:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329233123!14232183!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27893 invoked from network); 14 Feb 2012 15:25:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21935799"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:25:23 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012
	10:25:22 -0500
Message-ID: <4F3A7CE1.3080307@citrix.com>
Date: Tue, 14 Feb 2012 15:25:21 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>	<1329225071.31256.241.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/12 13:34, Stefano Stabellini wrote:
> On Tue, 14 Feb 2012, Ian Campbell wrote:
>> On Tue, 2012-02-14 at 13:07 +0000, Stefano Stabellini wrote:
>>> If the vgic needs to inject a virtual irq into the guest, but no free
>>> LR registers are available, add the irq to a list and return.
>>> Whenever an LR register becomes available we add the queued irq to it
>>> and remove it from the list.
>>> We use the gic lock to protect the list and the bitmask.
>>
>> There's no need to order the IRQs by priority and ensure that the
>> highest priorities are in the LRs?
> 
> You are right, they need to be ordered by priority.
> 
> -->8--
> 
>>From 027ddc0a08c5608797b03e66b87178cd2522ad07 Mon Sep 17 00:00:00 2001
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Tue, 14 Feb 2012 13:23:56 +0000
> Subject: [PATCH] arm: support fewer LR registers than virtual irqs
> 
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.
> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   58 ++++++++++++++++++++++++++++++++++++++---
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 54 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..129b7ff 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;
> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,47 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +    struct pending_irq *iter, *n;
> +
> +    spin_lock(&gic.lock);
> +    for (i = 0; i < nr_lrs; i++) {
> +        if (!test_and_set_bit(i, &gic.lr_mask))
> +        {
> +            gic_set_lr(i, virtual_irq, state, priority);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }

You can skip this loop if gic.lr_pending is non-empty as there won't be
any spare bits in gic.lr_mask.

> +    n = irq_to_pending(current, virtual_irq);
> +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> +    {
> +        if ( iter->priority < priority )
> +        {
> +            list_add_tail(&n->lr_link, &iter->lr_link);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }

How many pending irqs are expected?  If it's lots then looping through a
simple list like this might be slow.   Something to keep in mind -- I
wouldn't try and fix it now.

> +    list_add(&n->lr_link, &gic.lr_pending);
> +    spin_unlock(&gic.lock);
> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -435,13 +471,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> +    for ( i = 0; i < nr_lrs; i++ ) {
>          if ( eisr & ((uint64_t)1 << i) ) {
>              struct pending_irq *p;
>  
> +            spin_lock(&gic.lock);
>              lr = GICH[GICH_LR + i];
>              virq = lr & GICH_LR_VIRTUAL_MASK;
>              GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +
> +            if ( !list_empty(gic.lr_pending.next) ) {
> +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +                list_del(&p->lr_link);
> +                INIT_LIST_HEAD(&p->lr_link);

I don't think you need the INIT_LIST_HEAD() here (and even if you did
you should use list_del_init()).  You only need to init nodes if you
need to test if they are in a list or not.

> +                set_bit(i, &gic.lr_mask);
> +            } else {
> +                gic_inject_irq_stop();
> +            }
> +            spin_unlock(&gic.lock);
>  
>              spin_lock(&current->arch.vgic.lock);
>              p = irq_to_pending(current, virq);
> @@ -449,7 +498,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            gic_inject_irq_stop();
>              list_del(&p->link);
>              INIT_LIST_HEAD(&p->link);

Similarly, here (but this should be fixed up in a separate patch).

>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;
>  };
>  
>  struct arch_domain


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:25:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKG5-0004Aj-Jw; Tue, 14 Feb 2012 15:25:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>)
	id 1RxKG3-0004AQ-5F; Tue, 14 Feb 2012 15:25:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329233123!14232183!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27893 invoked from network); 14 Feb 2012 15:25:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 15:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="21935799"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 10:25:23 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012
	10:25:22 -0500
Message-ID: <4F3A7CE1.3080307@citrix.com>
Date: Tue, 14 Feb 2012 15:25:21 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>	<1329225071.31256.241.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/12 13:34, Stefano Stabellini wrote:
> On Tue, 14 Feb 2012, Ian Campbell wrote:
>> On Tue, 2012-02-14 at 13:07 +0000, Stefano Stabellini wrote:
>>> If the vgic needs to inject a virtual irq into the guest, but no free
>>> LR registers are available, add the irq to a list and return.
>>> Whenever an LR register becomes available we add the queued irq to it
>>> and remove it from the list.
>>> We use the gic lock to protect the list and the bitmask.
>>
>> There's no need to order the IRQs by priority and ensure that the
>> highest priorities are in the LRs?
> 
> You are right, they need to be ordered by priority.
> 
> -->8--
> 
>>From 027ddc0a08c5608797b03e66b87178cd2522ad07 Mon Sep 17 00:00:00 2001
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Tue, 14 Feb 2012 13:23:56 +0000
> Subject: [PATCH] arm: support fewer LR registers than virtual irqs
> 
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.
> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   58 ++++++++++++++++++++++++++++++++++++++---
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 54 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..129b7ff 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;
> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,47 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +    struct pending_irq *iter, *n;
> +
> +    spin_lock(&gic.lock);
> +    for (i = 0; i < nr_lrs; i++) {
> +        if (!test_and_set_bit(i, &gic.lr_mask))
> +        {
> +            gic_set_lr(i, virtual_irq, state, priority);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }

You can skip this loop if gic.lr_pending is non-empty as there won't be
any spare bits in gic.lr_mask.

> +    n = irq_to_pending(current, virtual_irq);
> +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> +    {
> +        if ( iter->priority < priority )
> +        {
> +            list_add_tail(&n->lr_link, &iter->lr_link);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }

How many pending irqs are expected?  If it's lots then looping through a
simple list like this might be slow.   Something to keep in mind -- I
wouldn't try and fix it now.

> +    list_add(&n->lr_link, &gic.lr_pending);
> +    spin_unlock(&gic.lock);
> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -435,13 +471,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> +    for ( i = 0; i < nr_lrs; i++ ) {
>          if ( eisr & ((uint64_t)1 << i) ) {
>              struct pending_irq *p;
>  
> +            spin_lock(&gic.lock);
>              lr = GICH[GICH_LR + i];
>              virq = lr & GICH_LR_VIRTUAL_MASK;
>              GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +
> +            if ( !list_empty(gic.lr_pending.next) ) {
> +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +                list_del(&p->lr_link);
> +                INIT_LIST_HEAD(&p->lr_link);

I don't think you need the INIT_LIST_HEAD() here (and even if you did
you should use list_del_init()).  You only need to init nodes if you
need to test if they are in a list or not.

> +                set_bit(i, &gic.lr_mask);
> +            } else {
> +                gic_inject_irq_stop();
> +            }
> +            spin_unlock(&gic.lock);
>  
>              spin_lock(&current->arch.vgic.lock);
>              p = irq_to_pending(current, virq);
> @@ -449,7 +498,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            gic_inject_irq_stop();
>              list_del(&p->link);
>              INIT_LIST_HEAD(&p->link);

Similarly, here (but this should be fixed up in a separate patch).

>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;
>  };
>  
>  struct arch_domain


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:28:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKIw-0004OL-Dk; Tue, 14 Feb 2012 15:28:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1RxKIu-0004Na-NM
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:28:28 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329233302!13930687!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18752 invoked from network); 14 Feb 2012 15:28:22 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-13.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 15:28:22 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id q1EFSIYj015775;
	Tue, 14 Feb 2012 10:28:18 -0500
Message-ID: <4F3A7D92.8020504@theshore.net>
Date: Tue, 14 Feb 2012 10:28:18 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329214171.31256.198.camel@zakaz.uk.xensource.com>
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2/14/12 5:09 AM, Ian Campbell wrote:
> I suspect this must be&netbk->net_schedule_list_lock but I don't see
> how that can ever be NULL nor does the offset appear to be 0x474, at
> least in my tree -- although that may depend on debug options.
>
> Are you rebooting guests or plug/unplugging vifs while this is going on?

Sorry - I'm relaying some of this on behalf of another team member.

The dom0 insta-panics when running iperf and then bringing a vif down 
(for a network rules rebuild).  We've only been able to trigger it when 
the dom0 is dealing with a boatload of packets.  So, it smells like a 
race between the vif being marked down, and something thinking it can 
still deliver packets to it...

root@dom0# ip link set vif2.0 down (return = BOOM)
br0: port 4(vif2.0) entering forwarding state
BUG: unable to handle kernel NULL pointer dereference at 00000474
IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
...

-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:28:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKIw-0004OL-Dk; Tue, 14 Feb 2012 15:28:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1RxKIu-0004Na-NM
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:28:28 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329233302!13930687!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18752 invoked from network); 14 Feb 2012 15:28:22 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-13.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 15:28:22 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id q1EFSIYj015775;
	Tue, 14 Feb 2012 10:28:18 -0500
Message-ID: <4F3A7D92.8020504@theshore.net>
Date: Tue, 14 Feb 2012 10:28:18 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329214171.31256.198.camel@zakaz.uk.xensource.com>
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2/14/12 5:09 AM, Ian Campbell wrote:
> I suspect this must be&netbk->net_schedule_list_lock but I don't see
> how that can ever be NULL nor does the offset appear to be 0x474, at
> least in my tree -- although that may depend on debug options.
>
> Are you rebooting guests or plug/unplugging vifs while this is going on?

Sorry - I'm relaying some of this on behalf of another team member.

The dom0 insta-panics when running iperf and then bringing a vif down 
(for a network rules rebuild).  We've only been able to trigger it when 
the dom0 is dealing with a boatload of packets.  So, it smells like a 
race between the vif being marked down, and something thinking it can 
still deliver packets to it...

root@dom0# ip link set vif2.0 down (return = BOOM)
br0: port 4(vif2.0) entering forwarding state
BUG: unable to handle kernel NULL pointer dereference at 00000474
IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
...

-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:33:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKNQ-0004dI-9l; Tue, 14 Feb 2012 15:33: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 1RxKNP-0004cz-6C
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:33:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329233446!52692725!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MTQzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13270 invoked from network); 14 Feb 2012 15:30:47 -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; 14 Feb 2012 15:30: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 q1EFWuNn009202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 15:32:57 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
	q1EFWtew011283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 15:32:55 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
	q1EFWsOf024038; Tue, 14 Feb 2012 09:32:54 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 14 Feb 2012 07:32:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0A4C34035B; Tue, 14 Feb 2012 10:29:56 -0500 (EST)
Date: Tue, 14 Feb 2012 10:29:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rostedt@goodmis.org, linux-kernel@vger.kernel.org
Message-ID: <20120214152955.GA17671@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]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F3A7EAA.0032,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey,

I was running some benchmarks (netserver/netperf) where the init script just launched
the netserver and nothing else and was concerned to see the performance not up to par.
This was an HVM guest running with PV drivers.

If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better - but it was
my understanding that the tracing code does not impact the machine unless it is enabled.
And when I inserted a bunch of print_dump_bytes I do see instructions such as
e8 6a 90 60 e1 get replaced with 66 66 66 90 so I see the the instructions getting
patched over.

To get a better feel for this I tried this on baremetal, and (this is going
to sound a bit round-about way, but please bear with me), I was working on making
the pte_flags be paravirt (so it is a function instead of being a macro) and noticed
that on on an AMD A8-3850, with a CONFIG_PARAVIRT and CONFIG_FUNCTION_TRACER and
running kernelbench it would run slower than without CONFIG_FUNCTION_TRACER.

I am not really sure what the problem is, but based on those experiments
four things come to my mind:
 - Lots of nops and we choke the CPU instruction decoder with 20-30 bytes
   of 'nop', so the CPU is stalling waiting for some real instructions.
 - The compiler has choosen to compile most of the paravirt instructions as
   functions making the call to mcount (which gets patched over), but the
   end result is that we have an extra 'call' in the chain.
 - Somehow the low-level para-virt (like the assembler ones) calls don't get
   patched over and still end up calling mcount? (but I really doubt that is the
   case - but you never know).
 - Something else?

My thought was to crash the kernel as it is up and running and look at the
diassembled core to see what the instructions end up looking to get a further feel
for this.  But before I go with this are there some other ideas of what I should look
for?

Thanks!

Note: The "working on making the pte_flags be paravirt" patches are here:
http://darnok.org/results/baseline_pte_flags_pte_attrs/ if you are interested.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:33:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKNQ-0004dI-9l; Tue, 14 Feb 2012 15:33: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 1RxKNP-0004cz-6C
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:33:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329233446!52692725!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MTQzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13270 invoked from network); 14 Feb 2012 15:30:47 -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; 14 Feb 2012 15:30: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 q1EFWuNn009202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 14 Feb 2012 15:32:57 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
	q1EFWtew011283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 15:32:55 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
	q1EFWsOf024038; Tue, 14 Feb 2012 09:32:54 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 14 Feb 2012 07:32:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0A4C34035B; Tue, 14 Feb 2012 10:29:56 -0500 (EST)
Date: Tue, 14 Feb 2012 10:29:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rostedt@goodmis.org, linux-kernel@vger.kernel.org
Message-ID: <20120214152955.GA17671@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]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F3A7EAA.0032,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey,

I was running some benchmarks (netserver/netperf) where the init script just launched
the netserver and nothing else and was concerned to see the performance not up to par.
This was an HVM guest running with PV drivers.

If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better - but it was
my understanding that the tracing code does not impact the machine unless it is enabled.
And when I inserted a bunch of print_dump_bytes I do see instructions such as
e8 6a 90 60 e1 get replaced with 66 66 66 90 so I see the the instructions getting
patched over.

To get a better feel for this I tried this on baremetal, and (this is going
to sound a bit round-about way, but please bear with me), I was working on making
the pte_flags be paravirt (so it is a function instead of being a macro) and noticed
that on on an AMD A8-3850, with a CONFIG_PARAVIRT and CONFIG_FUNCTION_TRACER and
running kernelbench it would run slower than without CONFIG_FUNCTION_TRACER.

I am not really sure what the problem is, but based on those experiments
four things come to my mind:
 - Lots of nops and we choke the CPU instruction decoder with 20-30 bytes
   of 'nop', so the CPU is stalling waiting for some real instructions.
 - The compiler has choosen to compile most of the paravirt instructions as
   functions making the call to mcount (which gets patched over), but the
   end result is that we have an extra 'call' in the chain.
 - Somehow the low-level para-virt (like the assembler ones) calls don't get
   patched over and still end up calling mcount? (but I really doubt that is the
   case - but you never know).
 - Something else?

My thought was to crash the kernel as it is up and running and look at the
diassembled core to see what the instructions end up looking to get a further feel
for this.  But before I go with this are there some other ideas of what I should look
for?

Thanks!

Note: The "working on making the pte_flags be paravirt" patches are here:
http://darnok.org/results/baseline_pte_flags_pte_attrs/ if you are interested.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:38:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKSA-0004rx-0d; Tue, 14 Feb 2012 15:38: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 1RxKS8-0004rs-A5
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:38:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329233745!52693785!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9755 invoked from network); 14 Feb 2012 15:35:46 -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 Feb 2012 15:35:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10690093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:37:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 15:37:59 +0000
Message-ID: <1329233877.31256.258.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>, Jan Beulich <JBeulich@suse.com>
Date: Tue, 14 Feb 2012 15:37:57 +0000
In-Reply-To: <4F3A7D92.8020504@theshore.net>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
	<4F3A7D92.8020504@theshore.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 15:28 +0000, Christopher S. Aker wrote:
> On 2/14/12 5:09 AM, Ian Campbell wrote:
> > I suspect this must be&netbk->net_schedule_list_lock but I don't see
> > how that can ever be NULL nor does the offset appear to be 0x474, at
> > least in my tree -- although that may depend on debug options.
> >
> > Are you rebooting guests or plug/unplugging vifs while this is going on?
> 
> Sorry - I'm relaying some of this on behalf of another team member.
> 
> The dom0 insta-panics when running iperf and then bringing a vif down 
> (for a network rules rebuild).  We've only been able to trigger it when 
> the dom0 is dealing with a boatload of packets.  So, it smells like a 
> race between the vif being marked down, and something thinking it can 
> still deliver packets to it...
> 
> root@dom0# ip link set vif2.0 down (return = BOOM)
> br0: port 4(vif2.0) entering forwarding state
> BUG: unable to handle kernel NULL pointer dereference at 00000474
> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
> ...

I wonder if this is related to the discussion in
http://lists.xen.org/archives/html/xen-devel/2011-09/msg00981.html
http://lists.xen.org/archives/html/xen-devel/2011-09/msg00985.html

Jan, do you recall what you did about that issue?

Is it as simple as moving the call to netif_stop_queue(dev) in
xenvif_close before the carrier check?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:38:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKSA-0004rx-0d; Tue, 14 Feb 2012 15:38: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 1RxKS8-0004rs-A5
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:38:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329233745!52693785!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9755 invoked from network); 14 Feb 2012 15:35:46 -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 Feb 2012 15:35:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10690093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:37:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 15:37:59 +0000
Message-ID: <1329233877.31256.258.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>, Jan Beulich <JBeulich@suse.com>
Date: Tue, 14 Feb 2012 15:37:57 +0000
In-Reply-To: <4F3A7D92.8020504@theshore.net>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
	<4F3A7D92.8020504@theshore.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 15:28 +0000, Christopher S. Aker wrote:
> On 2/14/12 5:09 AM, Ian Campbell wrote:
> > I suspect this must be&netbk->net_schedule_list_lock but I don't see
> > how that can ever be NULL nor does the offset appear to be 0x474, at
> > least in my tree -- although that may depend on debug options.
> >
> > Are you rebooting guests or plug/unplugging vifs while this is going on?
> 
> Sorry - I'm relaying some of this on behalf of another team member.
> 
> The dom0 insta-panics when running iperf and then bringing a vif down 
> (for a network rules rebuild).  We've only been able to trigger it when 
> the dom0 is dealing with a boatload of packets.  So, it smells like a 
> race between the vif being marked down, and something thinking it can 
> still deliver packets to it...
> 
> root@dom0# ip link set vif2.0 down (return = BOOM)
> br0: port 4(vif2.0) entering forwarding state
> BUG: unable to handle kernel NULL pointer dereference at 00000474
> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
> ...

I wonder if this is related to the discussion in
http://lists.xen.org/archives/html/xen-devel/2011-09/msg00981.html
http://lists.xen.org/archives/html/xen-devel/2011-09/msg00985.html

Jan, do you recall what you did about that issue?

Is it as simple as moving the call to netif_stop_queue(dev) in
xenvif_close before the carrier check?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:49:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15: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.xensource.com>)
	id 1RxKcn-000581-7S; Tue, 14 Feb 2012 15:49:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxKcl-00057u-Rh
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:49:00 +0000
Received: from [85.158.139.83:24736] by server-4.bemta-5.messagelabs.com id
	B4/CA-10788-A628A3F4; Tue, 14 Feb 2012 15:48:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329234538!15037907!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 14 Feb 2012 15:48:58 -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;
	14 Feb 2012 15:48:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10690351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:48:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 15:48:58 +0000
Message-ID: <1329234536.31256.259.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 14 Feb 2012 15:48:56 +0000
In-Reply-To: <CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAyLTE0IGF0IDE0OjIzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi84IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiA+
IFJvZ2VyIFBhdSBNb25uZSB3cml0ZXMgKCJbWGVuLWRldmVsXSBbUEFUQ0ggMjAgb2YgMjkgUkZD
XSBsaWJ4bDogaW50cm9kdWNlIGxpYnhsIGhvdHBsdWcgcHVibGljIEFQSSBmdW5jdGlvbnMiKToK
PiA+PiBsaWJ4bDogaW50cm9kdWNlIGxpYnhsIGhvdHBsdWcgcHVibGljIEFQSSBmdW5jdGlvbnMK
PiA+Pgo+ID4+IFRoZXNlIGZ1bmN0aW9ucyBtaW1pYyB0aGUgbmFtZSB1c2VkIGJ5IHRoZSBsb2Nh
bCBkZXZpY2UgZnVuY3Rpb25zLAo+ID4+IGZvbGxvd2luZyB0aGUgbm9tZW5jbGF0dXJlOgo+ID4K
PiA+IEkgdGhpbmsgdGhlc2Ugc2hvdWxkIGJlIHByaXZhdGUgZnVuY3Rpb25zLiAgWW91ciBuZXcg
ZGV2aWNlIGRhZW1vbiBpcywKPiA+IEkgdGhpbmssIHBhcnQgb2YgdGhlIGltcGxlbWVudGF0aW9u
IG9mIGxpYnhsLCBub3Qgc29tZXRoaW5nIHRoYXQKPiA+IGFub3RoZXIgdG9vbHN0YWNrIG9uIHRv
cCBvZiBsaWJ4bCB3aWxsIHJlYXNvbmFibHkgd2FudCB0byByZXBsYWNlLgo+ID4KPiA+IFRoaXMg
aXMgYSBuZXcgZGVwYXJ0dXJlIGZvciBsaWJ4bCwgd2hpY2ggZG9lc24ndCBjdXJyZW50bHkgaGF2
ZSBhbnkKPiA+IGludGVybmFsIGV4ZWN1dGFibGVzLgo+IAo+IE5vdCBzdXJlIGFib3V0IHRoZSBi
ZXN0IGFwcHJvYWNoIGhlcmUsIEkgdGhvdWdoIHRoYXQgeGxkZXZpY2VkIHdpbGwgYmUKPiBsaWtl
IHhsLCBidXQgdGhhdCdzIHNvbWV0aGluZyB3ZSBjYW4gZGlzY3VzcyBhYm91dC4KCkkgd2FzIHdv
bmRlcmluZyBpZiBwZXJoYXBzIHhsL2xpYnhsIHNob3VsZCBoYW5kbGUgdGhlc2UgZXZlbnRzIGJ5
CmRlZmF1bHQgKHVzaW5nIHRoZSBzYW1lIEFQSXMgYXMgeGxkZXZpY2VkIHVzZXMpIHN1Y2ggdGhh
dCBpbiB0aGUgc2ltcGxlCmNhc2UgdXNlcnMgY2FuIGNvbnRpbnVlIHRvIGp1c3QgdXNlIHhsIHdp
dGhvdXQgd29ycnlpbmcgYWJvdXQKY29uZmlndXJpbmcgb3IgZW5hYmxpbmcgYWRkaXRpb25hbCBk
YWVtb25zLiBUaGVyZSB3b3VsZCB0aGVuIGJlIGFuCm9wdGlvbiB0byBkaXNhYmxlIHRoaXMgaWYg
eW91IHdlcmUgcnVubmluZyB4bGRldmljZWQgKGVpdGhlciBpbiBkb20wIG9yCmluIGEgZHJpdmVy
IGRvbSkuIFBlcmhhcHMgYSBtb3JlIERXSU0gZXh0ZW5zaW9uIHdvdWxkIGJlIHRvIGRlZmF1bHQg
dG8KcnVubmluZyB0aGluZ3Mgd2l0aGluIHhsL2xpYnhsIG9ubHkgaWYgdGhlIGJhY2tlbmQgaXMg
aW4gZG9tMCBhbmQgYXNzdSxlCnhsZGV2aWNlZCBpcyBydW5uaW5nIGluIGJhY2tlbmQgZG9tcyAh
PSAwLgoKRG8geW91IGludGVncmF0ZSB3aXRoIHRoZSBsaWJ4bCBldmVudCBsb29wPyBJZiB5b3Ug
ZGlkIHdvdWxkbid0IHRoaXMgYmUKdHJpdmlhbCB0byBoYW5kbGUgaW4geGwgYW5kIHdvdWxkbid0
IHRoZSB4bGRldmljZWQgYmVjb21lIHRoZSB0cml2aWFsCnNldHVwICsgcnVuIHRoZSBldmVudCBs
b29wIHByb2dyYW0/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:49:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15: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.xensource.com>)
	id 1RxKcn-000581-7S; Tue, 14 Feb 2012 15:49:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxKcl-00057u-Rh
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:49:00 +0000
Received: from [85.158.139.83:24736] by server-4.bemta-5.messagelabs.com id
	B4/CA-10788-A628A3F4; Tue, 14 Feb 2012 15:48:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329234538!15037907!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 14 Feb 2012 15:48:58 -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;
	14 Feb 2012 15:48:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10690351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 15:48:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 15:48:58 +0000
Message-ID: <1329234536.31256.259.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 14 Feb 2012 15:48:56 +0000
In-Reply-To: <CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAyLTE0IGF0IDE0OjIzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi84IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiA+
IFJvZ2VyIFBhdSBNb25uZSB3cml0ZXMgKCJbWGVuLWRldmVsXSBbUEFUQ0ggMjAgb2YgMjkgUkZD
XSBsaWJ4bDogaW50cm9kdWNlIGxpYnhsIGhvdHBsdWcgcHVibGljIEFQSSBmdW5jdGlvbnMiKToK
PiA+PiBsaWJ4bDogaW50cm9kdWNlIGxpYnhsIGhvdHBsdWcgcHVibGljIEFQSSBmdW5jdGlvbnMK
PiA+Pgo+ID4+IFRoZXNlIGZ1bmN0aW9ucyBtaW1pYyB0aGUgbmFtZSB1c2VkIGJ5IHRoZSBsb2Nh
bCBkZXZpY2UgZnVuY3Rpb25zLAo+ID4+IGZvbGxvd2luZyB0aGUgbm9tZW5jbGF0dXJlOgo+ID4K
PiA+IEkgdGhpbmsgdGhlc2Ugc2hvdWxkIGJlIHByaXZhdGUgZnVuY3Rpb25zLiAgWW91ciBuZXcg
ZGV2aWNlIGRhZW1vbiBpcywKPiA+IEkgdGhpbmssIHBhcnQgb2YgdGhlIGltcGxlbWVudGF0aW9u
IG9mIGxpYnhsLCBub3Qgc29tZXRoaW5nIHRoYXQKPiA+IGFub3RoZXIgdG9vbHN0YWNrIG9uIHRv
cCBvZiBsaWJ4bCB3aWxsIHJlYXNvbmFibHkgd2FudCB0byByZXBsYWNlLgo+ID4KPiA+IFRoaXMg
aXMgYSBuZXcgZGVwYXJ0dXJlIGZvciBsaWJ4bCwgd2hpY2ggZG9lc24ndCBjdXJyZW50bHkgaGF2
ZSBhbnkKPiA+IGludGVybmFsIGV4ZWN1dGFibGVzLgo+IAo+IE5vdCBzdXJlIGFib3V0IHRoZSBi
ZXN0IGFwcHJvYWNoIGhlcmUsIEkgdGhvdWdoIHRoYXQgeGxkZXZpY2VkIHdpbGwgYmUKPiBsaWtl
IHhsLCBidXQgdGhhdCdzIHNvbWV0aGluZyB3ZSBjYW4gZGlzY3VzcyBhYm91dC4KCkkgd2FzIHdv
bmRlcmluZyBpZiBwZXJoYXBzIHhsL2xpYnhsIHNob3VsZCBoYW5kbGUgdGhlc2UgZXZlbnRzIGJ5
CmRlZmF1bHQgKHVzaW5nIHRoZSBzYW1lIEFQSXMgYXMgeGxkZXZpY2VkIHVzZXMpIHN1Y2ggdGhh
dCBpbiB0aGUgc2ltcGxlCmNhc2UgdXNlcnMgY2FuIGNvbnRpbnVlIHRvIGp1c3QgdXNlIHhsIHdp
dGhvdXQgd29ycnlpbmcgYWJvdXQKY29uZmlndXJpbmcgb3IgZW5hYmxpbmcgYWRkaXRpb25hbCBk
YWVtb25zLiBUaGVyZSB3b3VsZCB0aGVuIGJlIGFuCm9wdGlvbiB0byBkaXNhYmxlIHRoaXMgaWYg
eW91IHdlcmUgcnVubmluZyB4bGRldmljZWQgKGVpdGhlciBpbiBkb20wIG9yCmluIGEgZHJpdmVy
IGRvbSkuIFBlcmhhcHMgYSBtb3JlIERXSU0gZXh0ZW5zaW9uIHdvdWxkIGJlIHRvIGRlZmF1bHQg
dG8KcnVubmluZyB0aGluZ3Mgd2l0aGluIHhsL2xpYnhsIG9ubHkgaWYgdGhlIGJhY2tlbmQgaXMg
aW4gZG9tMCBhbmQgYXNzdSxlCnhsZGV2aWNlZCBpcyBydW5uaW5nIGluIGJhY2tlbmQgZG9tcyAh
PSAwLgoKRG8geW91IGludGVncmF0ZSB3aXRoIHRoZSBsaWJ4bCBldmVudCBsb29wPyBJZiB5b3Ug
ZGlkIHdvdWxkbid0IHRoaXMgYmUKdHJpdmlhbCB0byBoYW5kbGUgaW4geGwgYW5kIHdvdWxkbid0
IHRoZSB4bGRldmljZWQgYmVjb21lIHRoZSB0cml2aWFsCnNldHVwICsgcnVuIHRoZSBldmVudCBs
b29wIHByb2dyYW0/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:53:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKga-0005LO-OJ; Tue, 14 Feb 2012 15:52:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxKgZ-0005Ke-VG
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:52:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329234769!16668488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19383 invoked from network); 14 Feb 2012 15:52:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:52:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 15:52:48 +0000
Message-Id: <4F3A915E0200007800072F14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 15:52:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Christopher S. Aker" <caker@theshore.net>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
	<4F3A7D92.8020504@theshore.net>
	<1329233877.31256.258.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329233877.31256.258.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-02-14 at 15:28 +0000, Christopher S. Aker wrote:
>> On 2/14/12 5:09 AM, Ian Campbell wrote:
>> > I suspect this must be&netbk->net_schedule_list_lock but I don't see
>> > how that can ever be NULL nor does the offset appear to be 0x474, at
>> > least in my tree -- although that may depend on debug options.
>> >
>> > Are you rebooting guests or plug/unplugging vifs while this is going on?
>> 
>> Sorry - I'm relaying some of this on behalf of another team member.
>> 
>> The dom0 insta-panics when running iperf and then bringing a vif down 
>> (for a network rules rebuild).  We've only been able to trigger it when 
>> the dom0 is dealing with a boatload of packets.  So, it smells like a 
>> race between the vif being marked down, and something thinking it can 
>> still deliver packets to it...
>> 
>> root@dom0# ip link set vif2.0 down (return = BOOM)
>> br0: port 4(vif2.0) entering forwarding state
>> BUG: unable to handle kernel NULL pointer dereference at 00000474
>> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
>> ...
> 
> I wonder if this is related to the discussion in
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00981.html 
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00985.html 
> 
> Jan, do you recall what you did about that issue?

I did what I indicated we were asked at that time - add a safety
check to start_xmit() (which xen-netback appears to have too,
albeit in a slightly different form). Also, start_xmit() doesn't
appear on the call stack Christopher sent.

> Is it as simple as moving the call to netif_stop_queue(dev) in
> xenvif_close before the carrier check?

As said back then, it would appear to be more consistent, but
you're much more of an expert here than I am. We continue
to have netif_stop_queue() after the carrier check in our trees,
without anyone having reported a problem like this since we
did the above adjustment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:53:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 15:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxKga-0005LO-OJ; Tue, 14 Feb 2012 15:52:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxKgZ-0005Ke-VG
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:52:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329234769!16668488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2NjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19383 invoked from network); 14 Feb 2012 15:52:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:52:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 14 Feb 2012 15:52:48 +0000
Message-Id: <4F3A915E0200007800072F14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 14 Feb 2012 15:52:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Christopher S. Aker" <caker@theshore.net>
References: <4F399181.5060801@theshore.net>
	<37EB35CA-3984-4C29-98F8-8258D68F9B13@theshore.net>
	<1329214171.31256.198.camel@zakaz.uk.xensource.com>
	<4F3A7D92.8020504@theshore.net>
	<1329233877.31256.258.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329233877.31256.258.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] BUG: unable to handle kernel NULL pointer
 dereference - xen_spin_lock_flags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 14.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-02-14 at 15:28 +0000, Christopher S. Aker wrote:
>> On 2/14/12 5:09 AM, Ian Campbell wrote:
>> > I suspect this must be&netbk->net_schedule_list_lock but I don't see
>> > how that can ever be NULL nor does the offset appear to be 0x474, at
>> > least in my tree -- although that may depend on debug options.
>> >
>> > Are you rebooting guests or plug/unplugging vifs while this is going on?
>> 
>> Sorry - I'm relaying some of this on behalf of another team member.
>> 
>> The dom0 insta-panics when running iperf and then bringing a vif down 
>> (for a network rules rebuild).  We've only been able to trigger it when 
>> the dom0 is dealing with a boatload of packets.  So, it smells like a 
>> race between the vif being marked down, and something thinking it can 
>> still deliver packets to it...
>> 
>> root@dom0# ip link set vif2.0 down (return = BOOM)
>> br0: port 4(vif2.0) entering forwarding state
>> BUG: unable to handle kernel NULL pointer dereference at 00000474
>> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
>> ...
> 
> I wonder if this is related to the discussion in
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00981.html 
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00985.html 
> 
> Jan, do you recall what you did about that issue?

I did what I indicated we were asked at that time - add a safety
check to start_xmit() (which xen-netback appears to have too,
albeit in a slightly different form). Also, start_xmit() doesn't
appear on the call stack Christopher sent.

> Is it as simple as moving the call to netif_stop_queue(dev) in
> xenvif_close before the carrier check?

As said back then, it would appear to be more consistent, but
you're much more of an expert here than I am. We continue
to have netif_stop_queue() after the carrier check in our trees,
without anyone having reported a problem like this since we
did the above adjustment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:58:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxKlK-0005fm-FW; Tue, 14 Feb 2012 15:57:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RxKlI-0005fZ-J7; Tue, 14 Feb 2012 15:57:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329235060!15329068!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16520 invoked from network); 14 Feb 2012 15:57:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:57:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1EFvdeN030320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 14 Feb 2012 10:57:39 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1EFvd9F030318;
	Tue, 14 Feb 2012 10:57:39 -0500
Date: Tue, 14 Feb 2012 11:57:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Qrux <qrux.qed@gmail.com>
Message-ID: <20120214155738.GC21610@andromeda.dapyr.net>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] Xen domU Timekeeping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 06:18:07PM -0800, Qrux wrote:
> Howdy, all.
> 
> Is there definitive documentation about accurate timekeeping on Linux PV domUs (Xen-4.1.2, Linux-3.1-pvops)?
> 
> Specifically:
> 
> 	* Is there a way to keep good time (i.e., bare-metal accuracy) on domU?

It does that now. It uses the same clock as the hypervisor does so there
is no "lost ticks" or such.

> 
> 	* What's happened to /proc/sys/xen/independent_wallclock?

No idea. What did that do?

> 
> 	* What should be done with /sbin/hwclock (if copied from a dom0)?

Well, nothing. Having a domU change the hardware time is a security
violation. It should not be able to change the hardware time.
> 
> 	* Does NTP on domU "work"?  Does adjtimex do anything?

It will fix whatever time issues (if any) of the guest. But it won't
adjust the hardware clock. That can only be done in dom0. So if you run
NTP in dom0 it will do it.
> 
> 	* Are there "bad side-effects" to "bad time" on domUs (see below)...?

Sure. If the time is skewed or off there are scheduling issues. Meaning
some applications will run longer (or shorter) than they are suppose to.

> 
> I'd be happy for an: "RTFM @ http://...," response, if the docs were definitive.
> 
> ===============================================================================
> 
> In addition, I'm having hard-to-track issues using ext4 on a domU, which I suspect may be related to the timekeeping issue(s).  When I boot this domU the first time, everything comes up nicely.  The kernel has ext2, ext3, and ext4 drivers built in.  I see this on the console:
> 
> 	[ 0.283049] EXT3-fs (xvda1): error: couldn't mount...unsupported...features
> 	[ 0.288476] EXT2-fs (xvda1): error: couldn't mount...unsupported...features
> 
> which is expected--and makes perfect sense--because I expect the next line to be this:
> 
> 	[ 0.318273] EXT4-fs (xvda1): mounted filesystem with ordered data mode...
> 
> And, that is what I observe.  At least, on the first boot...
> 
> But, upon reboot of the domU, I get stuck at the ext3/ext2 errors.  Guessing, I destroyed the nonfunctional domU, and reformatted its drive as ext3.  This worked.  I was able to reboot that domU without a problem.  Google didn't find too much information except this:
> 
> 	http://lists.openwall.net/linux-ext4/2009/10/12/12
> 
> But this is from 2009.  And, I'm not sure how relevant it is, directly, but it did make me wonder...Does not having "good time" on domUs affect the ability of the kernel to mount filesystems?  Could that be breaking ext4 on a domU with NTP?  And, despite the article's age, is using ext4 with "barriers=0" still valid advice...?

The issue you are hitting is probably based on what version of backend
you are using. Meaning what version of dom0 you have? It might be that
it needs :
http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg01784.html

> 
> Then...Accidentally, when I had the domU disk device mounted on dom0 (debugging, and forgot to umount before xl create), the domU came up fine--albeit slightly pissed off because it thought that the filesystem had errors.  But, it "repaired" the "errors" just fine (I assume they were related to the double-rw-mount), and booted.
> 
> I'm assuming all of this is documented somewhere; I just need a pointer to where to find this info.
> 
> ===============================================================================
> 
> Thanks,
> 	Q
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 15:58:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxKlK-0005fm-FW; Tue, 14 Feb 2012 15:57:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RxKlI-0005fZ-J7; Tue, 14 Feb 2012 15:57:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329235060!15329068!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16520 invoked from network); 14 Feb 2012 15:57:42 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:57:42 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1EFvdeN030320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 14 Feb 2012 10:57:39 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1EFvd9F030318;
	Tue, 14 Feb 2012 10:57:39 -0500
Date: Tue, 14 Feb 2012 11:57:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Qrux <qrux.qed@gmail.com>
Message-ID: <20120214155738.GC21610@andromeda.dapyr.net>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] Xen domU Timekeeping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, 2012 at 06:18:07PM -0800, Qrux wrote:
> Howdy, all.
> 
> Is there definitive documentation about accurate timekeeping on Linux PV domUs (Xen-4.1.2, Linux-3.1-pvops)?
> 
> Specifically:
> 
> 	* Is there a way to keep good time (i.e., bare-metal accuracy) on domU?

It does that now. It uses the same clock as the hypervisor does so there
is no "lost ticks" or such.

> 
> 	* What's happened to /proc/sys/xen/independent_wallclock?

No idea. What did that do?

> 
> 	* What should be done with /sbin/hwclock (if copied from a dom0)?

Well, nothing. Having a domU change the hardware time is a security
violation. It should not be able to change the hardware time.
> 
> 	* Does NTP on domU "work"?  Does adjtimex do anything?

It will fix whatever time issues (if any) of the guest. But it won't
adjust the hardware clock. That can only be done in dom0. So if you run
NTP in dom0 it will do it.
> 
> 	* Are there "bad side-effects" to "bad time" on domUs (see below)...?

Sure. If the time is skewed or off there are scheduling issues. Meaning
some applications will run longer (or shorter) than they are suppose to.

> 
> I'd be happy for an: "RTFM @ http://...," response, if the docs were definitive.
> 
> ===============================================================================
> 
> In addition, I'm having hard-to-track issues using ext4 on a domU, which I suspect may be related to the timekeeping issue(s).  When I boot this domU the first time, everything comes up nicely.  The kernel has ext2, ext3, and ext4 drivers built in.  I see this on the console:
> 
> 	[ 0.283049] EXT3-fs (xvda1): error: couldn't mount...unsupported...features
> 	[ 0.288476] EXT2-fs (xvda1): error: couldn't mount...unsupported...features
> 
> which is expected--and makes perfect sense--because I expect the next line to be this:
> 
> 	[ 0.318273] EXT4-fs (xvda1): mounted filesystem with ordered data mode...
> 
> And, that is what I observe.  At least, on the first boot...
> 
> But, upon reboot of the domU, I get stuck at the ext3/ext2 errors.  Guessing, I destroyed the nonfunctional domU, and reformatted its drive as ext3.  This worked.  I was able to reboot that domU without a problem.  Google didn't find too much information except this:
> 
> 	http://lists.openwall.net/linux-ext4/2009/10/12/12
> 
> But this is from 2009.  And, I'm not sure how relevant it is, directly, but it did make me wonder...Does not having "good time" on domUs affect the ability of the kernel to mount filesystems?  Could that be breaking ext4 on a domU with NTP?  And, despite the article's age, is using ext4 with "barriers=0" still valid advice...?

The issue you are hitting is probably based on what version of backend
you are using. Meaning what version of dom0 you have? It might be that
it needs :
http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg01784.html

> 
> Then...Accidentally, when I had the domU disk device mounted on dom0 (debugging, and forgot to umount before xl create), the domU came up fine--albeit slightly pissed off because it thought that the filesystem had errors.  But, it "repaired" the "errors" just fine (I assume they were related to the double-rw-mount), and booted.
> 
> I'm assuming all of this is documented somewhere; I just need a pointer to where to find this info.
> 
> ===============================================================================
> 
> Thanks,
> 	Q
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:00:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16: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.xensource.com>)
	id 1RxKnm-0006BJ-5X; Tue, 14 Feb 2012 16:00:22 +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 1RxKnk-0006Ay-6B
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 16:00:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329235094!61376163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3682 invoked from network); 14 Feb 2012 15:58:14 -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;
	14 Feb 2012 15:58:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10690588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 16:00:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 16:00:14 +0000
Date: Tue, 14 Feb 2012 16:04:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141604180.7456@kaball-desktop>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against current unstable. #6 and #9 touch common code.
> 
> Changes since v1:
>  - make PoD stubs proper functions instead of #defines
>  - define need_iommu as 0 instead of littering common code with #if
>  - stub donate_page but leave tmem enabled.
>  - rebased against latest unstable tree

ack

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:00:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16: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.xensource.com>)
	id 1RxKnm-0006BJ-5X; Tue, 14 Feb 2012 16:00:22 +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 1RxKnk-0006Ay-6B
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 16:00:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329235094!61376163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3682 invoked from network); 14 Feb 2012 15:58:14 -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;
	14 Feb 2012 15:58:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10690588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 16:00:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 16:00:14 +0000
Date: Tue, 14 Feb 2012 16:04:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141604180.7456@kaball-desktop>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against current unstable. #6 and #9 touch common code.
> 
> Changes since v1:
>  - make PoD stubs proper functions instead of #defines
>  - define need_iommu as 0 instead of littering common code with #if
>  - stub donate_page but leave tmem enabled.
>  - rebased against latest unstable tree

ack

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:02:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16: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.xensource.com>)
	id 1RxKpQ-0006IA-Lg; Tue, 14 Feb 2012 16:02:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1RxKpN-0006Hl-QU
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 16:02:02 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329235315!13285747!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16658 invoked from network); 14 Feb 2012 16:01:55 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 16:01:55 -0000
Received: by lbjn8 with SMTP id n8so5367052lbj.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 08:01:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=tCIQs6trBksjRlZfAioY/kpXgjc53DmPSiKoNMYM9SU=;
	b=Da2vtYZjpoAQBdJWjqhPiXisUtqqPUrRKqtJIy5oj+gwByq/W44+Xq5bPIo31mtRRF
	3CX9dGuDfgLvT8ruTvGR7eCLAiZKhewGhBOOYhFDwJdJDubtmdblCZgPp1db4a28cJG/
	yF+YTE9uq64xSK82Yn6QwtHHZ9zLKbE20bCtg=
Received: by 10.152.128.202 with SMTP id nq10mr14786296lab.11.1329235314877;
	Tue, 14 Feb 2012 08:01:54 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id mc3sm16462156lab.12.2012.02.14.08.01.52
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 08:01:53 -0800 (PST)
Message-ID: <4F3A8569.4000508@xen.org>
Date: Tue, 14 Feb 2012 16:01:45 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security Response Problem Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Done

On 08/02/2012 16:43, Ian Campbell wrote:
> Hi Lars,
>
> Please can we amend the Security Process [0] to add to the end of the
> section "5. Advisory public release:" text like:
>
>          Published advisories will be added to the Security
>          Announcements[1] wiki page.
>
> (with the link in the appropriate syntax/place)
>
> The reason is that this document also serves as our checklist for things
> to do when making a security announcement and this will serve to remind
> us to update that page.
>
> Thanks.
>
> [0] http://www.xen.org/projects/security_vulnerability_process.html
> [1] http://wiki.xen.org/wiki/Security_Announcements
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:02:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16: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.xensource.com>)
	id 1RxKpQ-0006IA-Lg; Tue, 14 Feb 2012 16:02:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1RxKpN-0006Hl-QU
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 16:02:02 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329235315!13285747!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16658 invoked from network); 14 Feb 2012 16:01:55 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 16:01:55 -0000
Received: by lbjn8 with SMTP id n8so5367052lbj.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 08:01:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=tCIQs6trBksjRlZfAioY/kpXgjc53DmPSiKoNMYM9SU=;
	b=Da2vtYZjpoAQBdJWjqhPiXisUtqqPUrRKqtJIy5oj+gwByq/W44+Xq5bPIo31mtRRF
	3CX9dGuDfgLvT8ruTvGR7eCLAiZKhewGhBOOYhFDwJdJDubtmdblCZgPp1db4a28cJG/
	yF+YTE9uq64xSK82Yn6QwtHHZ9zLKbE20bCtg=
Received: by 10.152.128.202 with SMTP id nq10mr14786296lab.11.1329235314877;
	Tue, 14 Feb 2012 08:01:54 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id mc3sm16462156lab.12.2012.02.14.08.01.52
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 08:01:53 -0800 (PST)
Message-ID: <4F3A8569.4000508@xen.org>
Date: Tue, 14 Feb 2012 16:01:45 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328719383.6133.68.camel@zakaz.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Security Response Problem Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Done

On 08/02/2012 16:43, Ian Campbell wrote:
> Hi Lars,
>
> Please can we amend the Security Process [0] to add to the end of the
> section "5. Advisory public release:" text like:
>
>          Published advisories will be added to the Security
>          Announcements[1] wiki page.
>
> (with the link in the appropriate syntax/place)
>
> The reason is that this document also serves as our checklist for things
> to do when making a security announcement and this will serve to remind
> us to update that page.
>
> Thanks.
>
> [0] http://www.xen.org/projects/security_vulnerability_process.html
> [1] http://wiki.xen.org/wiki/Security_Announcements
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:48:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxLXS-0007pN-3I; Tue, 14 Feb 2012 16:47:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxLXQ-0007pB-LV
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 16:47:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329238046!16677033!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTkxMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25368 invoked from network); 14 Feb 2012 16:47:26 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-2.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 16:47:26 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 798EC300074;
	Tue, 14 Feb 2012 08:47:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ZEDZfiVoVNxVnSamdLacjRh8wlaBCGLZfjzg4U/TIdPy
	vvioufmpQCZOXXHUv4tQL7lcY3WcbT/wX5RK20/w9ZYs4L+O3aaq/ZcwNr/TZLvR
	/q97S9b3FArF6WWLTL8FSZVUQKFKe92we2gDQThPSyttwE+YE3HaYWuwPDXm8Bw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xQ5ZYyPKKHtCkK/Bx88hhc4ZZPM=; b=I8YSbORy
	DkcXJOWa5odaYRXCNuvZjUP63hdWW0C6PPJSbt4BAaukkOhLMdryhiRME57Tfi2q
	z12DFUi821ThbqnqQHft3VpTwoK7V053em4Nnd/HPxjqAGBtzGAvzPZashBw0bQo
	UcQNXGdXCN5iqfTp0MOR5AOqK2qICSM3HLI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 9A4C1300079; 
	Tue, 14 Feb 2012 08:47:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 08:47:25 -0800
Message-ID: <d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214151803.GA22116@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
Date: Tue, 14 Feb 2012 08:47:25 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> Why? Because it's really really hard to guarantee we'll go to sleep in
>> an
>> atomic context. The main use for wait queues (imho) is in hvm_copy, and
>> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
>> all
>> ways of bumping the preemption count.
>
> If the guests pagetable is paged out this code path will trigger, then
> one of the hypercalls returns an error and the guest runs into a BUG().
> I think it was decrease_reservation, or similar.

Unlikely to be something specific about decrease_reservation. If the guest
page table is paged out, then copy_from_user for any hypercall, or,
"virtual address to gfn" for any emulation will run into this.

Now, even an innocent-looking rcu lock anywhere in this code path will
crash the host if we go into a wait queue. Hence my concern.

> Another thing reported by Huawei on this list was somewhere in the
> emulation code where a gfn_to_mfn() failed.

Can you point to the original report? Is there anything more specific?

>
> What other way exist to make paging 100% transparent to the guest?
>

Don't page out page table pages? I know you were not expecting that...

Andres

> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:48:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxLXS-0007pN-3I; Tue, 14 Feb 2012 16:47:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxLXQ-0007pB-LV
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 16:47:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329238046!16677033!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTkxMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25368 invoked from network); 14 Feb 2012 16:47:26 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-2.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 16:47:26 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 798EC300074;
	Tue, 14 Feb 2012 08:47:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ZEDZfiVoVNxVnSamdLacjRh8wlaBCGLZfjzg4U/TIdPy
	vvioufmpQCZOXXHUv4tQL7lcY3WcbT/wX5RK20/w9ZYs4L+O3aaq/ZcwNr/TZLvR
	/q97S9b3FArF6WWLTL8FSZVUQKFKe92we2gDQThPSyttwE+YE3HaYWuwPDXm8Bw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xQ5ZYyPKKHtCkK/Bx88hhc4ZZPM=; b=I8YSbORy
	DkcXJOWa5odaYRXCNuvZjUP63hdWW0C6PPJSbt4BAaukkOhLMdryhiRME57Tfi2q
	z12DFUi821ThbqnqQHft3VpTwoK7V053em4Nnd/HPxjqAGBtzGAvzPZashBw0bQo
	UcQNXGdXCN5iqfTp0MOR5AOqK2qICSM3HLI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 9A4C1300079; 
	Tue, 14 Feb 2012 08:47:24 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 08:47:25 -0800
Message-ID: <d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214151803.GA22116@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
Date: Tue, 14 Feb 2012 08:47:25 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> Why? Because it's really really hard to guarantee we'll go to sleep in
>> an
>> atomic context. The main use for wait queues (imho) is in hvm_copy, and
>> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
>> all
>> ways of bumping the preemption count.
>
> If the guests pagetable is paged out this code path will trigger, then
> one of the hypercalls returns an error and the guest runs into a BUG().
> I think it was decrease_reservation, or similar.

Unlikely to be something specific about decrease_reservation. If the guest
page table is paged out, then copy_from_user for any hypercall, or,
"virtual address to gfn" for any emulation will run into this.

Now, even an innocent-looking rcu lock anywhere in this code path will
crash the host if we go into a wait queue. Hence my concern.

> Another thing reported by Huawei on this list was somewhere in the
> emulation code where a gfn_to_mfn() failed.

Can you point to the original report? Is there anything more specific?

>
> What other way exist to make paging 100% transparent to the guest?
>

Don't page out page table pages? I know you were not expecting that...

Andres

> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:50:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxLZv-00081M-SZ; Tue, 14 Feb 2012 16:50:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RxLZt-00080k-P3; Tue, 14 Feb 2012 16:50:05 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329238198!13944056!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21601 invoked from network); 14 Feb 2012 16:49:59 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 16:49:59 -0000
Received: by lbjn8 with SMTP id n8so5418644lbj.30
	for <multiple recipients>; Tue, 14 Feb 2012 08:49:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=me0ygw6pL304I3UXeus4vOh0HjKsug0zi2JGfvnBOHg=;
	b=cDGe3iD2WiUJBAEFIoGNBqWFduYUJZbFICfbeYjT4KR9as2/55fkkJvPy+PELKxHhR
	3RgJf6bXuz+wkx9YtvwgJGvD3658qowtEcQW0mZpr3Ci2cZLgfJbWorP59zbFavmMRRP
	27sG9cTZof1ruYsrTJ2cfS/2fgjeS0SLhzORY=
Received: by 10.112.40.200 with SMTP id z8mr7826114lbk.93.1329238198592;
	Tue, 14 Feb 2012 08:49:58 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id m3sm17177671lbm.17.2012.02.14.08.49.56
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 08:49:57 -0800 (PST)
Message-ID: <4F3A90AD.50804@xen.org>
Date: Tue, 14 Feb 2012 16:49:49 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,

the planning for the Xen Hackathon is starting to shape up. All the 
logistics are in place and are shown on 
wiki.xen.org/wiki/Hackathon/March2012 - the event starts at 9AM and 
closes at 5PM. We will aim to have a social event most evenings

I would be good if the people who have signed up would let me know of:
- company they work for
- special dietary requirements (if applicable)
- T-shirt sizes
if not done yet.

People who have signed up as provisional, can you please update your 
entry: if you know you will come remove provisional, if you don't please 
remove yourself.

Also, it would be good if you could list the project/activity that you 
want to work on to 
http://wiki.xen.org/wiki/Hackathon/March2012#Topics_to_Discuss

I have made preparations to reach out to further groups in SIlicon 
valley, and want to ensure that the core people are signed up before I 
do this.

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 16:50:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 16:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxLZv-00081M-SZ; Tue, 14 Feb 2012 16:50:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RxLZt-00080k-P3; Tue, 14 Feb 2012 16:50:05 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329238198!13944056!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21601 invoked from network); 14 Feb 2012 16:49:59 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 16:49:59 -0000
Received: by lbjn8 with SMTP id n8so5418644lbj.30
	for <multiple recipients>; Tue, 14 Feb 2012 08:49:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=me0ygw6pL304I3UXeus4vOh0HjKsug0zi2JGfvnBOHg=;
	b=cDGe3iD2WiUJBAEFIoGNBqWFduYUJZbFICfbeYjT4KR9as2/55fkkJvPy+PELKxHhR
	3RgJf6bXuz+wkx9YtvwgJGvD3658qowtEcQW0mZpr3Ci2cZLgfJbWorP59zbFavmMRRP
	27sG9cTZof1ruYsrTJ2cfS/2fgjeS0SLhzORY=
Received: by 10.112.40.200 with SMTP id z8mr7826114lbk.93.1329238198592;
	Tue, 14 Feb 2012 08:49:58 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id m3sm17177671lbm.17.2012.02.14.08.49.56
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 08:49:57 -0800 (PST)
Message-ID: <4F3A90AD.50804@xen.org>
Date: Tue, 14 Feb 2012 16:49:49 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,

the planning for the Xen Hackathon is starting to shape up. All the 
logistics are in place and are shown on 
wiki.xen.org/wiki/Hackathon/March2012 - the event starts at 9AM and 
closes at 5PM. We will aim to have a social event most evenings

I would be good if the people who have signed up would let me know of:
- company they work for
- special dietary requirements (if applicable)
- T-shirt sizes
if not done yet.

People who have signed up as provisional, can you please update your 
entry: if you know you will come remove provisional, if you don't please 
remove yourself.

Also, it would be good if you could list the project/activity that you 
want to work on to 
http://wiki.xen.org/wiki/Hackathon/March2012#Topics_to_Discuss

I have made preparations to reach out to further groups in SIlicon 
valley, and want to ensure that the core people are signed up before I 
do this.

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxM0V-0000cB-Va; Tue, 14 Feb 2012 17:17:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxM0U-0000c6-7G
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:17:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329239847!9136674!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28622 invoked from network); 14 Feb 2012 17:17:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 17:17:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329239847; l=672;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=rdibJSX2l++TQRe5rbDYEIbT5yQ=;
	b=pjPZe85yjXkc1XQwwCtm1dHa3clY+C9ylNZ0INnT+Da6KbI+H4N/pEdl4rbILcFlp7I
	8pFlsMh57UXRGgsKPhW+7aethDM33LN45BCK2q1Bhb1liza0C4P5GvDeZy6XPyRtgAwz+
	UIxxIgxijPsSkP23G7T4NDL4vL1zsDTEK8g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (cohen mo24) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v044f6o1EFukTJ ;
	Tue, 14 Feb 2012 18:17:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A45CE18637; Tue, 14 Feb 2012 18:17:11 +0100 (CET)
Date: Tue, 14 Feb 2012 18:17:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120214171711.GA4761@aepfle.de>
References: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
	<4F3A81250200007800072EBE@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3A81250200007800072EBE@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Jan Beulich wrote:

> >>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> > (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
> > (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 
> > (supported: 0x800)
> > (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
> 
> Attached an updated patch that sets up g_mcg_cap using a white-listing
> bit mask, as mentioned in the previous response.
> 
> Note that this takes -unstable c/s 24781:6ae5506e49ab as prerequisite.

Thanks, this patch works ok for me, migrating from a host with 9 MCE
banks to a host with 6 MCE banks.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxM0V-0000cB-Va; Tue, 14 Feb 2012 17:17:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxM0U-0000c6-7G
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:17:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329239847!9136674!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28622 invoked from network); 14 Feb 2012 17:17:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 17:17:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329239847; l=672;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=rdibJSX2l++TQRe5rbDYEIbT5yQ=;
	b=pjPZe85yjXkc1XQwwCtm1dHa3clY+C9ylNZ0INnT+Da6KbI+H4N/pEdl4rbILcFlp7I
	8pFlsMh57UXRGgsKPhW+7aethDM33LN45BCK2q1Bhb1liza0C4P5GvDeZy6XPyRtgAwz+
	UIxxIgxijPsSkP23G7T4NDL4vL1zsDTEK8g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (cohen mo24) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v044f6o1EFukTJ ;
	Tue, 14 Feb 2012 18:17:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A45CE18637; Tue, 14 Feb 2012 18:17:11 +0100 (CET)
Date: Tue, 14 Feb 2012 18:17:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120214171711.GA4761@aepfle.de>
References: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<20120209180257.GA13025@aepfle.de>
	<4F34F96602000078000722DA@nat28.tlf.novell.com>
	<20120210212846.GA31185@aepfle.de>
	<4F38F5C802000078000727AD@nat28.tlf.novell.com>
	<20120213142016.GA7108@aepfle.de>
	<4F3A81250200007800072EBE@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3A81250200007800072EBE@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George.Dunlap@eu.citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Jan Beulich wrote:

> >>> On 13.02.12 at 15:20, Olaf Hering <olaf@aepfle.de> wrote:
> > (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
> > (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 
> > (supported: 0x800)
> > (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
> 
> Attached an updated patch that sets up g_mcg_cap using a white-listing
> bit mask, as mentioned in the previous response.
> 
> Note that this takes -unstable c/s 24781:6ae5506e49ab as prerequisite.

Thanks, this patch works ok for me, migrating from a host with 9 MCE
banks to a host with 6 MCE banks.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17: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.xensource.com>)
	id 1RxM2A-0000j4-FX; Tue, 14 Feb 2012 17:19:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxM28-0000ig-Fk
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:19:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329239949!11459891!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8984 invoked from network); 14 Feb 2012 17:19:10 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 17:19:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329239949; l=1786;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/Bf/shBtoZSEER2ayDbL1rvgZTs=;
	b=lYv5a0ZLDllmOAqjY2ywl8xNjCXr2kzJslMAagj0wmh0AOxAdqmglhrLrDuhqAubfAH
	e1rdNYXiUqNt0AzCDzsB1QneNwgqv1wasgJaqUzRFvWbn4phBlyEm735/bUWdncYQJoAM
	fIOUNT+4JG/MgfC9TfwsDFzxlTXSzgst5Kw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by post.strato.de (mrclete mo37) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 403cb0o1EGEvm3 ;
	Tue, 14 Feb 2012 18:18:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 71FEE18637; Tue, 14 Feb 2012 18:18:57 +0100 (CET)
Date: Tue, 14 Feb 2012 18:18:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214171857.GA4728@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Why? Because it's really really hard to guarantee we'll go to sleep in
> >> an
> >> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
> >> all
> >> ways of bumping the preemption count.
> >
> > If the guests pagetable is paged out this code path will trigger, then
> > one of the hypercalls returns an error and the guest runs into a BUG().
> > I think it was decrease_reservation, or similar.
> 
> Unlikely to be something specific about decrease_reservation. If the guest
> page table is paged out, then copy_from_user for any hypercall, or,
> "virtual address to gfn" for any emulation will run into this.
> 
> Now, even an innocent-looking rcu lock anywhere in this code path will
> crash the host if we go into a wait queue. Hence my concern.

The workaround for the guest crash I were seeing:
http://lists.xen.org/archives/html/xen-devel/2010-11/msg01609.html

I once modified xenpaging to keep the pagetables paged out as much as it
could (and still allowed the guest to make at least a little bit
progress) and run into no appearent issue.

> > Another thing reported by Huawei on this list was somewhere in the
> > emulation code where a gfn_to_mfn() failed.
> 
> Can you point to the original report? Is there anything more specific?

It was vmx_load_pdptrs().
http://lists.xen.org/archives/html/xen-devel/2011-09/msg01336.html

> > What other way exist to make paging 100% transparent to the guest?
> >
> 
> Don't page out page table pages? I know you were not expecting that...

How can xenpaging know what gfns are pagetables?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17: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.xensource.com>)
	id 1RxM2A-0000j4-FX; Tue, 14 Feb 2012 17:19:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxM28-0000ig-Fk
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:19:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329239949!11459891!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8984 invoked from network); 14 Feb 2012 17:19:10 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 17:19:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329239949; l=1786;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/Bf/shBtoZSEER2ayDbL1rvgZTs=;
	b=lYv5a0ZLDllmOAqjY2ywl8xNjCXr2kzJslMAagj0wmh0AOxAdqmglhrLrDuhqAubfAH
	e1rdNYXiUqNt0AzCDzsB1QneNwgqv1wasgJaqUzRFvWbn4phBlyEm735/bUWdncYQJoAM
	fIOUNT+4JG/MgfC9TfwsDFzxlTXSzgst5Kw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by post.strato.de (mrclete mo37) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 403cb0o1EGEvm3 ;
	Tue, 14 Feb 2012 18:18:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 71FEE18637; Tue, 14 Feb 2012 18:18:57 +0100 (CET)
Date: Tue, 14 Feb 2012 18:18:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214171857.GA4728@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Why? Because it's really really hard to guarantee we'll go to sleep in
> >> an
> >> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
> >> all
> >> ways of bumping the preemption count.
> >
> > If the guests pagetable is paged out this code path will trigger, then
> > one of the hypercalls returns an error and the guest runs into a BUG().
> > I think it was decrease_reservation, or similar.
> 
> Unlikely to be something specific about decrease_reservation. If the guest
> page table is paged out, then copy_from_user for any hypercall, or,
> "virtual address to gfn" for any emulation will run into this.
> 
> Now, even an innocent-looking rcu lock anywhere in this code path will
> crash the host if we go into a wait queue. Hence my concern.

The workaround for the guest crash I were seeing:
http://lists.xen.org/archives/html/xen-devel/2010-11/msg01609.html

I once modified xenpaging to keep the pagetables paged out as much as it
could (and still allowed the guest to make at least a little bit
progress) and run into no appearent issue.

> > Another thing reported by Huawei on this list was somewhere in the
> > emulation code where a gfn_to_mfn() failed.
> 
> Can you point to the original report? Is there anything more specific?

It was vmx_load_pdptrs().
http://lists.xen.org/archives/html/xen-devel/2011-09/msg01336.html

> > What other way exist to make paging 100% transparent to the guest?
> >
> 
> Don't page out page table pages? I know you were not expecting that...

How can xenpaging know what gfns are pagetables?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:34:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17:34:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxMGV-0001VO-IO; Tue, 14 Feb 2012 17:34: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.org>) id 1RxMGU-0001VI-HG
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:34:06 +0000
Received: from [85.158.139.83:2549] by server-10.bemta-5.messagelabs.com id
	3B/84-07861-D0B9A3F4; Tue, 14 Feb 2012 17:34:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329240844!14210735!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTYxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6558 invoked from network); 14 Feb 2012 17:34:04 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 17:34:04 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 8C7E6380078;
	Tue, 14 Feb 2012 09:34:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aSpi3i/+iYIXcMGHm136SciWk/kyyiB4CwiFESb+rx+8
	Rp3lWmyyZMwykI/MDyGHIXTWfx8BbUluL64dh7YGQFY9kQBi3xEqVTC7DA5NRjK7
	4IDdU2DydDKG8wJhU/O1WP1fGCk9hyaqZi4bPwImPHcvglEmsOPCbjcHd6m2hxg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=kguiOVKzybgXBPnxlaNbTSNl6EU=; b=VJm64c7M
	hfAP6rRwzGkeoCTlMSe/0XYcQgSlWKLD0fTiFDK3nSlHiHoos05INucAI7aFq4Qz
	aLPa/uEhWlhzqbHpt/xYkAfrfyb2K/88++p5zzd6I3scJyaB6tuKrPiSMuMPPNT1
	J29HQTuU/S9utwklhA13s6zkQUHhFCnR47A=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 30522380075; 
	Tue, 14 Feb 2012 09:34:03 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 09:34:03 -0800
Message-ID: <9a5b1cf737db23f8d735266e15747ed4.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214171857.GA4728@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
	<20120214171857.GA4728@aepfle.de>
Date: Tue, 14 Feb 2012 09:34:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>> >
>> >> Why? Because it's really really hard to guarantee we'll go to sleep
>> in
>> >> an
>> >> atomic context. The main use for wait queues (imho) is in hvm_copy,
>> and
>> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
>> >> all
>> >> ways of bumping the preemption count.
>> >
>> > If the guests pagetable is paged out this code path will trigger, then
>> > one of the hypercalls returns an error and the guest runs into a
>> BUG().
>> > I think it was decrease_reservation, or similar.
>>
>> Unlikely to be something specific about decrease_reservation. If the
>> guest
>> page table is paged out, then copy_from_user for any hypercall, or,
>> "virtual address to gfn" for any emulation will run into this.
>>
>> Now, even an innocent-looking rcu lock anywhere in this code path will
>> crash the host if we go into a wait queue. Hence my concern.
>
> The workaround for the guest crash I were seeing:
> http://lists.xen.org/archives/html/xen-devel/2010-11/msg01609.html

This makes sense. It's basically what emulation does (X86_EMUL_RETRY). Great!

>
> I once modified xenpaging to keep the pagetables paged out as much as it
> could (and still allowed the guest to make at least a little bit
> progress) and run into no appearent issue.
>
>> > Another thing reported by Huawei on this list was somewhere in the
>> > emulation code where a gfn_to_mfn() failed.
>>
>> Can you point to the original report? Is there anything more specific?
>
> It was vmx_load_pdptrs().
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg01336.html

I have a patch queued up for cleaning up vmx_load_pdptrs so that it
doesn't crash the host if the cr3 is paged out for a PAE guest.

You can't really do what they propose (mdelay, retry). You're in a
hypervisor context holding locks, nothing is getting scheduled!

One option worth considering is testing the cr3 "early enough", when it's
safe to sleep.

>
>> > What other way exist to make paging 100% transparent to the guest?
>> >
>>
>> Don't page out page table pages? I know you were not expecting that...
>
> How can xenpaging know what gfns are pagetables?

There's a bunch of heuristics one can try. It boils down to a lengthy
discussion about what the pager is trying to do. Say, you can
statistically sample cr3's, map candidates and look for page table-like
structures, exploit knowledge about the guest OS.

I'll agree though that the hypervisor support should be good enough that
the pager should not care. But it isn't and it won't get there quickly,
and I don't want us to be cavalier about these wait queues.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:34:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17:34:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxMGV-0001VO-IO; Tue, 14 Feb 2012 17:34: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.org>) id 1RxMGU-0001VI-HG
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:34:06 +0000
Received: from [85.158.139.83:2549] by server-10.bemta-5.messagelabs.com id
	3B/84-07861-D0B9A3F4; Tue, 14 Feb 2012 17:34:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329240844!14210735!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTYxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6558 invoked from network); 14 Feb 2012 17:34:04 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 17:34:04 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 8C7E6380078;
	Tue, 14 Feb 2012 09:34:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aSpi3i/+iYIXcMGHm136SciWk/kyyiB4CwiFESb+rx+8
	Rp3lWmyyZMwykI/MDyGHIXTWfx8BbUluL64dh7YGQFY9kQBi3xEqVTC7DA5NRjK7
	4IDdU2DydDKG8wJhU/O1WP1fGCk9hyaqZi4bPwImPHcvglEmsOPCbjcHd6m2hxg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=kguiOVKzybgXBPnxlaNbTSNl6EU=; b=VJm64c7M
	hfAP6rRwzGkeoCTlMSe/0XYcQgSlWKLD0fTiFDK3nSlHiHoos05INucAI7aFq4Qz
	aLPa/uEhWlhzqbHpt/xYkAfrfyb2K/88++p5zzd6I3scJyaB6tuKrPiSMuMPPNT1
	J29HQTuU/S9utwklhA13s6zkQUHhFCnR47A=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 30522380075; 
	Tue, 14 Feb 2012 09:34:03 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 09:34:03 -0800
Message-ID: <9a5b1cf737db23f8d735266e15747ed4.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214171857.GA4728@aepfle.de>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
	<20120214171857.GA4728@aepfle.de>
Date: Tue, 14 Feb 2012 09:34:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>> >
>> >> Why? Because it's really really hard to guarantee we'll go to sleep
>> in
>> >> an
>> >> atomic context. The main use for wait queues (imho) is in hvm_copy,
>> and
>> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
>> >> all
>> >> ways of bumping the preemption count.
>> >
>> > If the guests pagetable is paged out this code path will trigger, then
>> > one of the hypercalls returns an error and the guest runs into a
>> BUG().
>> > I think it was decrease_reservation, or similar.
>>
>> Unlikely to be something specific about decrease_reservation. If the
>> guest
>> page table is paged out, then copy_from_user for any hypercall, or,
>> "virtual address to gfn" for any emulation will run into this.
>>
>> Now, even an innocent-looking rcu lock anywhere in this code path will
>> crash the host if we go into a wait queue. Hence my concern.
>
> The workaround for the guest crash I were seeing:
> http://lists.xen.org/archives/html/xen-devel/2010-11/msg01609.html

This makes sense. It's basically what emulation does (X86_EMUL_RETRY). Great!

>
> I once modified xenpaging to keep the pagetables paged out as much as it
> could (and still allowed the guest to make at least a little bit
> progress) and run into no appearent issue.
>
>> > Another thing reported by Huawei on this list was somewhere in the
>> > emulation code where a gfn_to_mfn() failed.
>>
>> Can you point to the original report? Is there anything more specific?
>
> It was vmx_load_pdptrs().
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg01336.html

I have a patch queued up for cleaning up vmx_load_pdptrs so that it
doesn't crash the host if the cr3 is paged out for a PAE guest.

You can't really do what they propose (mdelay, retry). You're in a
hypervisor context holding locks, nothing is getting scheduled!

One option worth considering is testing the cr3 "early enough", when it's
safe to sleep.

>
>> > What other way exist to make paging 100% transparent to the guest?
>> >
>>
>> Don't page out page table pages? I know you were not expecting that...
>
> How can xenpaging know what gfns are pagetables?

There's a bunch of heuristics one can try. It boils down to a lengthy
discussion about what the pager is trying to do. Say, you can
statistically sample cr3's, map candidates and look for page table-like
structures, exploit knowledge about the guest OS.

I'll agree though that the hypervisor support should be good enough that
the pager should not care. But it isn't and it won't get there quickly,
and I don't want us to be cavalier about these wait queues.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:55:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxMb5-0002Dt-Bg; Tue, 14 Feb 2012 17:55:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RxMb4-0002Dj-7h
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:55:22 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329242114!13374182!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=RCVD_BY_IP,
  RCVD_NUMERIC_HELO
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13639 invoked from network); 14 Feb 2012 17:55:15 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 17:55:15 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RxMan-00083D-Bl
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:55:05 +0100
Received: from 76.14.48.202 ([76.14.48.202])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Tue, 14 Feb 2012 18:55:05 +0100
Received: from blp by 76.14.48.202 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Tue, 14 Feb 2012 18:55:05 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Ben Pfaff <blp@nicira.com>
Date: Tue, 14 Feb 2012 09:51:51 -0800
Lines: 12
Message-ID: <87r4xx9ubs.fsf@blp.benpfaff.org>
References: <4F3A90AD.50804@xen.org>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 76.14.48.202
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Cancel-Lock: sha1:iEMC+yf6UFlAVAEchpvRwSSKcP8=
Cc: xen-api@lists.xensource.com
Subject: Re: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ben Pfaff <blp@nicira.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Lars Kurth <lars.kurth@xen.org> writes:

> I have made preparations to reach out to further groups in SIlicon
> valley, and want to ensure that the core people are signed up before I
> do this.

Would it be helpful to have one of Nicira's Open vSwitch
developers come?  (Is anyone interested in discussing
networking-related topics?)  I've tentatively received permission
from management here to join for one or more days if it would be
useful.  We're in Silicon Valley anyway so it doesn't require
much planning on our end.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 17:55:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 17:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxMb5-0002Dt-Bg; Tue, 14 Feb 2012 17:55:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RxMb4-0002Dj-7h
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 17:55:22 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329242114!13374182!1
X-Originating-IP: [80.91.229.3]
X-SpamReason: No, hits=1.7 required=7.0 tests=RCVD_BY_IP,
  RCVD_NUMERIC_HELO
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13639 invoked from network); 14 Feb 2012 17:55:15 -0000
Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 17:55:15 -0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RxMan-00083D-Bl
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:55:05 +0100
Received: from 76.14.48.202 ([76.14.48.202])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Tue, 14 Feb 2012 18:55:05 +0100
Received: from blp by 76.14.48.202 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Tue, 14 Feb 2012 18:55:05 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Ben Pfaff <blp@nicira.com>
Date: Tue, 14 Feb 2012 09:51:51 -0800
Lines: 12
Message-ID: <87r4xx9ubs.fsf@blp.benpfaff.org>
References: <4F3A90AD.50804@xen.org>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 76.14.48.202
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Cancel-Lock: sha1:iEMC+yf6UFlAVAEchpvRwSSKcP8=
Cc: xen-api@lists.xensource.com
Subject: Re: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ben Pfaff <blp@nicira.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Lars Kurth <lars.kurth@xen.org> writes:

> I have made preparations to reach out to further groups in SIlicon
> valley, and want to ensure that the core people are signed up before I
> do this.

Would it be helpful to have one of Nicira's Open vSwitch
developers come?  (Is anyone interested in discussing
networking-related topics?)  I've tentatively received permission
from management here to join for one or more days if it would be
useful.  We're in Silicon Valley anyway so it doesn't require
much planning on our end.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:30:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18: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.xensource.com>)
	id 1RxN8s-0003ms-JA; Tue, 14 Feb 2012 18:30:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RxN8q-0003mk-JT
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:30:16 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329244208!8721047!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODg0OTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21123 invoked from network); 14 Feb 2012 18:30:09 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 18:30:09 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 34D1219CE;
	Tue, 14 Feb 2012 20:30:07 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BA9E82004A; Tue, 14 Feb 2012 20:30:06 +0200 (EET)
Date: Tue, 14 Feb 2012 20:30:06 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120214183006.GJ12984@reaktio.net>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: Re: [Xen-devel] [RFC] acpi processor and cpufreq harester -
	aka	pipe all of that up to the hypervisor (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, 2012 at 12:06:46AM -0500, Konrad Rzeszutek Wilk wrote:
> 
> This "harvester" (I am horrible with names, if you have any suggestions please
> tell me them) collects the information that the cpufreq drivers and the
> ACPI processor code save in the 'struct acpi_processor' and then sends it to
> the hypervisor.
> 

Btw there's a typo in the subject line.. "harester".

I'm not very good with names either: collector? passthru? 


> The driver can be either an module or compiled in. In either mode the driver
> launches a thread that checks whether an cpufreq driver is registered. If so
> it reads all the 'struct acpi_processor' data for all online CPUs and sends
> it to hypervisor. The driver also register a CPU hotplug component - so if a new
> CPU shows up - it would send the data to the hypervisor for it as well.
> 
> I've tested this with success on a variety of Intel and AMD hardware (need
> a patch to the hypervisor to allow the rdmsr to be passed through). The one
> caveat is that dom0_max_vcpus inhibits the driver from reading the vCPUs
> that are not present in dom0. One solution is to boot without dom0_max_vcpus
> and utilize the 'xl vcpu-set' command to offline the vCPUs. Other one that
> Nakajima Jun suggested was to hotplug vCPUS in - so bootup dom0 and hotplug
> the vCPUs in - but I am running in difficulties on how to do this in the hypervisor.
> 

When using this driver do you need to pass any options to Xen hypervisor? 
(cpufreq=something) ? 

It might be good to mention something about that in the patch comments.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:30:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18: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.xensource.com>)
	id 1RxN8s-0003ms-JA; Tue, 14 Feb 2012 18:30:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RxN8q-0003mk-JT
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:30:16 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329244208!8721047!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODg0OTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21123 invoked from network); 14 Feb 2012 18:30:09 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 18:30:09 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 34D1219CE;
	Tue, 14 Feb 2012 20:30:07 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BA9E82004A; Tue, 14 Feb 2012 20:30:06 +0200 (EET)
Date: Tue, 14 Feb 2012 20:30:06 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120214183006.GJ12984@reaktio.net>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: Re: [Xen-devel] [RFC] acpi processor and cpufreq harester -
	aka	pipe all of that up to the hypervisor (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, 2012 at 12:06:46AM -0500, Konrad Rzeszutek Wilk wrote:
> 
> This "harvester" (I am horrible with names, if you have any suggestions please
> tell me them) collects the information that the cpufreq drivers and the
> ACPI processor code save in the 'struct acpi_processor' and then sends it to
> the hypervisor.
> 

Btw there's a typo in the subject line.. "harester".

I'm not very good with names either: collector? passthru? 


> The driver can be either an module or compiled in. In either mode the driver
> launches a thread that checks whether an cpufreq driver is registered. If so
> it reads all the 'struct acpi_processor' data for all online CPUs and sends
> it to hypervisor. The driver also register a CPU hotplug component - so if a new
> CPU shows up - it would send the data to the hypervisor for it as well.
> 
> I've tested this with success on a variety of Intel and AMD hardware (need
> a patch to the hypervisor to allow the rdmsr to be passed through). The one
> caveat is that dom0_max_vcpus inhibits the driver from reading the vCPUs
> that are not present in dom0. One solution is to boot without dom0_max_vcpus
> and utilize the 'xl vcpu-set' command to offline the vCPUs. Other one that
> Nakajima Jun suggested was to hotplug vCPUS in - so bootup dom0 and hotplug
> the vCPUs in - but I am running in difficulties on how to do this in the hypervisor.
> 

When using this driver do you need to pass any options to Xen hypervisor? 
(cpufreq=something) ? 

It might be good to mention something about that in the patch comments.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:33:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxNBD-0003u5-AH; Tue, 14 Feb 2012 18:32:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RxNBC-0003to-3w
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:32:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329244354!2752845!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1088 invoked from network); 14 Feb 2012 18:32:35 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 18:32:35 -0000
Received: by bkcjg15 with SMTP id jg15so397766bkc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 10:32:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GFB61dEUK0nW+UDYOZwhEKnofmsT281zBLCrKTtf6UU=;
	b=AUqHzc03shg+fZqPcCz9luERK94nIl3y24hyBhhQ2OOA2tg7J8MG240LlG/3D1waN4
	uS52/mFOvBHLyAWaUa+sNvZckiC3eY9+1RXDS8mybf1lUj3j4K9dTvYGpQcm9sw3jOcQ
	6OUd3aDryfrKE9Z9e2ieyP3+VzBe9aMypwu2Q=
Received: by 10.204.150.78 with SMTP id x14mr10121137bkv.0.1329244354734;
	Tue, 14 Feb 2012 10:32:34 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id e17sm740787bkz.13.2012.02.14.10.32.33
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 10:32:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 14 Feb 2012 18:32:31 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB60593F.2B419%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: don't allow Dom0 to map MSI-X table
	writably
Thread-Index: AczrRwLa3nnGOSqMsk+N0Np/y8vPTg==
In-Reply-To: <4F3A83D20200007800072ED4@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: don't allow Dom0 to map MSI-X table
 writably
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/2012 14:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> With the traditional qemu tree fixed to not use PROT_WRITE anymore in
> the mmap() call for this region, and with the upstream qemu tree not
> being capable of handling passthrough, yet, there's no need to treat
> Dom specially here anymore.
> 
> This continues to leave unaddressed the case where PV guests map the
> MSI-X table page(s) before setting up the first MSI-X interrupt (see
> the original c/s 22182:68cc3c514a0a description for options).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -869,7 +869,7 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> -        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
> +        if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;
>          dprintk(XENLOG_G_WARNING,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:33:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 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.xensource.com>)
	id 1RxNBD-0003u5-AH; Tue, 14 Feb 2012 18:32:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RxNBC-0003to-3w
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:32:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329244354!2752845!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1088 invoked from network); 14 Feb 2012 18:32:35 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 18:32:35 -0000
Received: by bkcjg15 with SMTP id jg15so397766bkc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 10:32:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GFB61dEUK0nW+UDYOZwhEKnofmsT281zBLCrKTtf6UU=;
	b=AUqHzc03shg+fZqPcCz9luERK94nIl3y24hyBhhQ2OOA2tg7J8MG240LlG/3D1waN4
	uS52/mFOvBHLyAWaUa+sNvZckiC3eY9+1RXDS8mybf1lUj3j4K9dTvYGpQcm9sw3jOcQ
	6OUd3aDryfrKE9Z9e2ieyP3+VzBe9aMypwu2Q=
Received: by 10.204.150.78 with SMTP id x14mr10121137bkv.0.1329244354734;
	Tue, 14 Feb 2012 10:32:34 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id e17sm740787bkz.13.2012.02.14.10.32.33
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 10:32:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 14 Feb 2012 18:32:31 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB60593F.2B419%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: don't allow Dom0 to map MSI-X table
	writably
Thread-Index: AczrRwLa3nnGOSqMsk+N0Np/y8vPTg==
In-Reply-To: <4F3A83D20200007800072ED4@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: don't allow Dom0 to map MSI-X table
 writably
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/2012 14:54, "Jan Beulich" <JBeulich@suse.com> wrote:

> With the traditional qemu tree fixed to not use PROT_WRITE anymore in
> the mmap() call for this region, and with the upstream qemu tree not
> being capable of handling passthrough, yet, there's no need to treat
> Dom specially here anymore.
> 
> This continues to leave unaddressed the case where PV guests map the
> MSI-X table page(s) before setting up the first MSI-X interrupt (see
> the original c/s 22182:68cc3c514a0a description for options).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -869,7 +869,7 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> -        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
> +        if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;
>          dprintk(XENLOG_G_WARNING,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:33:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18:33:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNBd-0003w1-Nz; Tue, 14 Feb 2012 18:33:09 +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 1RxNBb-0003vs-UD
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:33:08 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329244335!62837762!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9208 invoked from network); 14 Feb 2012 18:32:16 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 18:32:16 -0000
Received: by lbjn8 with SMTP id n8so76927lbj.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 10:33:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1npn57DykO4jE813uqrTjMVTdCl6AQ3XpEVLOGonxMI=;
	b=V3Pe6l4PTICEHwxq+07JMjmysn6QN1JMmMBANUfUuPKjFbf2VNz0F6AT29LS6djtm9
	ZX/6UoKe9WWjgIHCdDLCFxEM9GskiCknkJFcrKCe/GAGE2tnVmmepgpBTvfsZiQdQbsa
	zl6+nKRpn1iLYCvIojn4TEq6so1P+DkH0LMVA=
Received: by 10.112.31.232 with SMTP id d8mr7562443lbi.96.1329244384351;
	Tue, 14 Feb 2012 10:33:04 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id kc10sm134851lbb.8.2012.02.14.10.33.00
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 10:33:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 14 Feb 2012 18:32:56 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB605958.2B41A%keir.xen@gmail.com>
Thread-Topic: [PATCH 06/12] PM: only include XEN_SYSCTL_{get_pmstat, pm_op} if
	HAVE_ACPI
Thread-Index: AczrRxHBNGyVkUVaqkaNkjzK3v5HyQ==
In-Reply-To: <1329230641-18624-6-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 06/12] PM: only include
 XEN_SYSCTL_{get_pmstat, pm_op} if HAVE_ACPI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/2012 14:43, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> These hypercalls are currently ACPI specific and implemented in
> xen/drivers/acpi which is not implemented on ARM.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> Cc: keir@xen.org
> ---
>  xen/Rules.mk         |    1 +
>  xen/arch/arm/dummy.S |    2 --
>  xen/common/sysctl.c  |    2 ++
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 507e9ab..ee54179 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -50,6 +50,7 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
>  CFLAGS-$(perfc)         += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> +CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 1287e0b..3bf5226 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -16,13 +16,11 @@ DUMMY(create_grant_host_mapping);
>  DUMMY(__cpu_die);
>  DUMMY(__cpu_disable);
>  DUMMY(__cpu_up);
> -DUMMY(do_get_pm_info);
>  DUMMY(domain_get_maximum_gpfn);
>  DUMMY(domain_relinquish_resources);
>  DUMMY(domain_set_time_offset);
>  DUMMY(dom_cow);
>  DUMMY(donate_page);
> -DUMMY(do_pm_op);
>  DUMMY(flush_tlb_mask);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(get_page);
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index f8f7cf8..fef0589 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -224,6 +224,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
>      }
>      break;
>  
> +#ifdef HAS_ACPI
>      case XEN_SYSCTL_get_pmstat:
>      {
>          ret = xsm_get_pmstat();
> @@ -259,6 +260,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
>          }
>      }
>      break;
> +#endif
>  
>      case XEN_SYSCTL_page_offline_op:
>      {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:33:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18:33:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNBd-0003w1-Nz; Tue, 14 Feb 2012 18:33:09 +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 1RxNBb-0003vs-UD
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:33:08 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329244335!62837762!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9208 invoked from network); 14 Feb 2012 18:32:16 -0000
Received: from mail-lpp01m020-f171.google.com (HELO
	mail-lpp01m020-f171.google.com) (209.85.217.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 18:32:16 -0000
Received: by lbjn8 with SMTP id n8so76927lbj.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 10:33:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1npn57DykO4jE813uqrTjMVTdCl6AQ3XpEVLOGonxMI=;
	b=V3Pe6l4PTICEHwxq+07JMjmysn6QN1JMmMBANUfUuPKjFbf2VNz0F6AT29LS6djtm9
	ZX/6UoKe9WWjgIHCdDLCFxEM9GskiCknkJFcrKCe/GAGE2tnVmmepgpBTvfsZiQdQbsa
	zl6+nKRpn1iLYCvIojn4TEq6so1P+DkH0LMVA=
Received: by 10.112.31.232 with SMTP id d8mr7562443lbi.96.1329244384351;
	Tue, 14 Feb 2012 10:33:04 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id kc10sm134851lbb.8.2012.02.14.10.33.00
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 10:33:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 14 Feb 2012 18:32:56 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB605958.2B41A%keir.xen@gmail.com>
Thread-Topic: [PATCH 06/12] PM: only include XEN_SYSCTL_{get_pmstat, pm_op} if
	HAVE_ACPI
Thread-Index: AczrRxHBNGyVkUVaqkaNkjzK3v5HyQ==
In-Reply-To: <1329230641-18624-6-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 06/12] PM: only include
 XEN_SYSCTL_{get_pmstat, pm_op} if HAVE_ACPI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/2012 14:43, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> These hypercalls are currently ACPI specific and implemented in
> xen/drivers/acpi which is not implemented on ARM.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> Cc: keir@xen.org
> ---
>  xen/Rules.mk         |    1 +
>  xen/arch/arm/dummy.S |    2 --
>  xen/common/sysctl.c  |    2 ++
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 507e9ab..ee54179 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -50,6 +50,7 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
>  CFLAGS-$(perfc)         += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> +CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 1287e0b..3bf5226 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -16,13 +16,11 @@ DUMMY(create_grant_host_mapping);
>  DUMMY(__cpu_die);
>  DUMMY(__cpu_disable);
>  DUMMY(__cpu_up);
> -DUMMY(do_get_pm_info);
>  DUMMY(domain_get_maximum_gpfn);
>  DUMMY(domain_relinquish_resources);
>  DUMMY(domain_set_time_offset);
>  DUMMY(dom_cow);
>  DUMMY(donate_page);
> -DUMMY(do_pm_op);
>  DUMMY(flush_tlb_mask);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(get_page);
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index f8f7cf8..fef0589 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -224,6 +224,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
>      }
>      break;
>  
> +#ifdef HAS_ACPI
>      case XEN_SYSCTL_get_pmstat:
>      {
>          ret = xsm_get_pmstat();
> @@ -259,6 +260,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
>          }
>      }
>      break;
> +#endif
>  
>      case XEN_SYSCTL_page_offline_op:
>      {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18: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.xensource.com>)
	id 1RxNHX-0004He-IB; Tue, 14 Feb 2012 18:39:15 +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 1RxNHV-0004HW-Km
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:39:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329244708!52426806!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10581 invoked from network); 14 Feb 2012 18:38:28 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 18:38:28 -0000
Received: by bkcjg15 with SMTP id jg15so407970bkc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 10:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Ly9ABdJfWBr0DA18F4fimrZIn0b1Orr38WUQqHcJ3oA=;
	b=HXeYwrJP/4F33teRWa5Q6lfSoNwfASEWCJMfQBysJVmihfiMs5obWHs+hTToAL5Yc9
	Y2RegdTtWtQpDpPb5Van6gvJbFHoGidso6S3POJN9SPvbhiEAISDtga0k7ax6hKfeXvl
	DE/cKFrzmTxaKHbzBtZMuwoZDhwp7IYuVKuvc=
Received: by 10.204.10.91 with SMTP id o27mr9822547bko.17.1329244401088;
	Tue, 14 Feb 2012 10:33:21 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id i2sm790324bkd.10.2012.02.14.10.33.15
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 10:33:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 14 Feb 2012 18:33:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB605969.2B41B%keir.xen@gmail.com>
Thread-Topic: [PATCH 09/12] xen: make need_iommu == 0 if !HAS_PASSTHROUGH
Thread-Index: AczrRxvj01MU5QawVk2bp0JDJbsi+g==
In-Reply-To: <1329230641-18624-9-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 09/12] xen: make need_iommu == 0 if
	!HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/2012 14:43, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> Cc: keir@xen.org
> ---
>  xen/Rules.mk            |    1 +
>  xen/arch/arm/dummy.S    |    2 --
>  xen/include/xen/sched.h |    6 ++++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index ee54179..6123835 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 5010619..e858613 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
>  DUMMY(gnttab_clear_flag);
>  DUMMY(gnttab_mark_dirty);
>  DUMMY(hypercall_create_continuation);
> -DUMMY(iommu_map_page);
> -DUMMY(iommu_unmap_page);
>  DUMMY(is_iomem_page);
>  DUMMY(max_page);
>  DUMMY(node_online_map);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 567cd36..3699929 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -266,8 +266,10 @@ struct domain
>  
>      /* Is this an HVM guest? */
>      bool_t           is_hvm;
> +#ifdef HAS_PASSTHROUGH
>      /* Does this guest need iommu mappings? */
>      bool_t           need_iommu;
> +#endif
>      /* Is this guest fully privileged (aka dom0)? */
>      bool_t           is_privileged;
>      /* Which guest this guest has privileges on */
> @@ -687,7 +689,11 @@ void watchdog_domain_destroy(struct domain *d);
>  #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
>  #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
>                             cpumask_weight((v)->cpu_affinity) == 1)
> +#ifdef HAS_PASSTHROUGH
>  #define need_iommu(d)    ((d)->need_iommu)
> +#else
> +#define need_iommu(d)    (0)
> +#endif
>  
>  void set_vcpu_migration_delay(unsigned int delay);
>  unsigned int get_vcpu_migration_delay(void);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18: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.xensource.com>)
	id 1RxNHX-0004He-IB; Tue, 14 Feb 2012 18:39:15 +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 1RxNHV-0004HW-Km
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:39:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329244708!52426806!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10581 invoked from network); 14 Feb 2012 18:38:28 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 18:38:28 -0000
Received: by bkcjg15 with SMTP id jg15so407970bkc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 10:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Ly9ABdJfWBr0DA18F4fimrZIn0b1Orr38WUQqHcJ3oA=;
	b=HXeYwrJP/4F33teRWa5Q6lfSoNwfASEWCJMfQBysJVmihfiMs5obWHs+hTToAL5Yc9
	Y2RegdTtWtQpDpPb5Van6gvJbFHoGidso6S3POJN9SPvbhiEAISDtga0k7ax6hKfeXvl
	DE/cKFrzmTxaKHbzBtZMuwoZDhwp7IYuVKuvc=
Received: by 10.204.10.91 with SMTP id o27mr9822547bko.17.1329244401088;
	Tue, 14 Feb 2012 10:33:21 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id i2sm790324bkd.10.2012.02.14.10.33.15
	(version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 10:33:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 14 Feb 2012 18:33:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB605969.2B41B%keir.xen@gmail.com>
Thread-Topic: [PATCH 09/12] xen: make need_iommu == 0 if !HAS_PASSTHROUGH
Thread-Index: AczrRxvj01MU5QawVk2bp0JDJbsi+g==
In-Reply-To: <1329230641-18624-9-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 09/12] xen: make need_iommu == 0 if
	!HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 14/02/2012 14:43, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> Cc: keir@xen.org
> ---
>  xen/Rules.mk            |    1 +
>  xen/arch/arm/dummy.S    |    2 --
>  xen/include/xen/sched.h |    6 ++++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index ee54179..6123835 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 5010619..e858613 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
>  DUMMY(gnttab_clear_flag);
>  DUMMY(gnttab_mark_dirty);
>  DUMMY(hypercall_create_continuation);
> -DUMMY(iommu_map_page);
> -DUMMY(iommu_unmap_page);
>  DUMMY(is_iomem_page);
>  DUMMY(max_page);
>  DUMMY(node_online_map);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 567cd36..3699929 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -266,8 +266,10 @@ struct domain
>  
>      /* Is this an HVM guest? */
>      bool_t           is_hvm;
> +#ifdef HAS_PASSTHROUGH
>      /* Does this guest need iommu mappings? */
>      bool_t           need_iommu;
> +#endif
>      /* Is this guest fully privileged (aka dom0)? */
>      bool_t           is_privileged;
>      /* Which guest this guest has privileges on */
> @@ -687,7 +689,11 @@ void watchdog_domain_destroy(struct domain *d);
>  #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
>  #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
>                             cpumask_weight((v)->cpu_affinity) == 1)
> +#ifdef HAS_PASSTHROUGH
>  #define need_iommu(d)    ((d)->need_iommu)
> +#else
> +#define need_iommu(d)    (0)
> +#endif
>  
>  void set_vcpu_migration_delay(unsigned int delay);
>  unsigned int get_vcpu_migration_delay(void);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:39:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18: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.xensource.com>)
	id 1RxNHt-0004Iw-Uy; Tue, 14 Feb 2012 18:39: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 1RxNHt-0004Ip-1L
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:39:37 +0000
Received: from [85.158.139.83:18013] by server-10.bemta-5.messagelabs.com id
	C5/DA-07861-86AAA3F4; Tue, 14 Feb 2012 18:39:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329244775!7729387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13898 invoked from network); 14 Feb 2012 18:39:35 -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;
	14 Feb 2012 18:39:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10693661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 18:39:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 18:39:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxNHq-0007fZ-SD;
	Tue, 14 Feb 2012 18:39:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxNHq-0003K8-DE;
	Tue, 14 Feb 2012 18:39:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11955-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 18:39:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11955 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11955/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11944

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0ba87b95e80b
baseline version:
 xen                  9ad1e42c341b

------------------------------------------------------------
People who touched revisions under test:
  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>
  Julian Pidancet <julian.pidancet@gmail.com>
  Keir Fraser <keir@xen.org>
  Stefan Bader <stefan.bader@canonical.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhigang Wang <zhigang.x.wang@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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 395 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 18:39:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 18: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.xensource.com>)
	id 1RxNHt-0004Iw-Uy; Tue, 14 Feb 2012 18:39: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 1RxNHt-0004Ip-1L
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 18:39:37 +0000
Received: from [85.158.139.83:18013] by server-10.bemta-5.messagelabs.com id
	C5/DA-07861-86AAA3F4; Tue, 14 Feb 2012 18:39:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329244775!7729387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13898 invoked from network); 14 Feb 2012 18:39:35 -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;
	14 Feb 2012 18:39:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10693661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 18:39:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 18:39:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxNHq-0007fZ-SD;
	Tue, 14 Feb 2012 18:39:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxNHq-0003K8-DE;
	Tue, 14 Feb 2012 18:39:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11955-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 18:39:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11955 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11955/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11944

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0ba87b95e80b
baseline version:
 xen                  9ad1e42c341b

------------------------------------------------------------
People who touched revisions under test:
  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>
  Julian Pidancet <julian.pidancet@gmail.com>
  Keir Fraser <keir@xen.org>
  Stefan Bader <stefan.bader@canonical.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhigang Wang <zhigang.x.wang@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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 395 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:05:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNga-0004yw-8B; Tue, 14 Feb 2012 19:05:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxNgY-0004yr-KH
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:05:07 +0000
Received: from [85.158.139.83:56513] by server-6.bemta-5.messagelabs.com id
	58/9B-27305-160BA3F4; Tue, 14 Feb 2012 19:05:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329246304!15006059!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTQ4Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9868 invoked from network); 14 Feb 2012 19:05:04 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 19:05:04 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id AA2E2604076;
	Tue, 14 Feb 2012 11:05:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=S5mbjG+r
	JZoeg8WkQkadIPlYxWlW+OT60Ph/gtA6AG8Y8yyqhYtpvaxZvWeb7ERx2cz41N1I
	MwAuSL2+Nm/HmbT/o87QxsoXqnoR2wk5Q6yBjmCsUIJxlXjOWEgtd3tOcqoiOKBE
	ZsBzYO0yK2Hx71pPIDiNCxmiINU+j/0hCgE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	auWFklCBb71GETmbrZ/ma8dl1eE=; b=QFkTUiL4lfC2X3mrYbu9GCmMG04qHz0N
	uwcv/Z4Lgg4O541k3UUl4/z/xjqfr1EsGNtx7qvte0fmbxu2vSAjd3MofNStInGP
	on5N3NdFsYQUfk62eJKALU7ySWT6LexZlW7/n/JPTS0tFUmTqcU+03xXTV0FnPJH
	awUFXLjZT8g=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 99E6E604061; 
	Tue, 14 Feb 2012 11:05:03 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 11:05:03 -0800
Message-ID: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
Date: Tue, 14 Feb 2012 11:05:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We started hashing out some AMD support for mem_paging and mem_access.
Right now my VMs boot, page out a bit, and then die on an HVM triple
fault.

Most importantly, I want to get somebody from AMD to comment/help out on
this. It feels like we're inches away from enabling support for this very
nice feature. I'm not sure who exactly on AMD monitors the list for these
kinds of things. It'd be great to have you on board!

For starters, the changes to the p2m code are relatively mild, but it'd be
great if somebody spots a red flag.

Another issue: comments indicate that bits 59-62 in NPT entries are used
for IOMMU flags but effectively bits 61-62 are. Repossessing one bit (59)
would give us enough space to support mem_access. Right now we only have 7
bits available for Xen flags and that is not enough for paging and access.
Is bit 59 effectively reserved?

Finally, the triple fault. Maybe I'm missing something obvious. Comments
welcome.

Patch inline below, thanks!
Andres

Enable AMD support for paging.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
             if ( !hap_enabled(d) )
                 break;

-            /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
-                break;
-
             rc = -EXDEV;
             /* Disallow paging in a PoD guest */
             if ( p2m->pod.entry_count )
diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -53,6 +53,20 @@
 #define P2M_BASE_FLAGS \
         (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)

+#ifdef __x86_64__
+/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
+ * value tramples over the higher-order bits used for flags (NX, p2mt,
+ * etc.) This happens for paging entries. Thus we do this clip/unclip
+ * juggle for l1 entries only (no paging superpages!) */
+#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
+#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
+#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
+                                INVALID_MFN : (mfn))
+#else
+#define clipped_mfn(mfn)    (mfn)
+#define unclip_mfn(mfn)     (mfn)
+#endif /* __x86_64__ */
+
 static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
 {
     unsigned long flags;
@@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
     case p2m_invalid:
     case p2m_mmio_dm:
     case p2m_populate_on_demand:
+    case p2m_ram_paging_out:
+    case p2m_ram_paged:
+    case p2m_ram_paging_in:
     default:
         return flags;
     case p2m_ram_ro:
@@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
                                       shift, max)) )
         return 0;

-    /* PoD: Not present doesn't imply empty. */
+    /* PoD/paging: Not present doesn't imply empty. */
     if ( !l1e_get_flags(*p2m_entry) )
     {
         struct page_info *pg;
@@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
                                    0, L1_PAGETABLE_ENTRIES);
         ASSERT(p2m_entry);

-        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
-            entry_content = l1e_from_pfn(mfn_x(mfn),
+        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
+             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
+            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
                                          p2m_type_to_flags(p2mt, mfn));
         else
             entry_content = l1e_empty();
@@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
         if ( entry_content.l1 != 0 )
         {
             p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
-            old_mfn = l1e_get_pfn(*p2m_entry);
+            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
         }
         /* level 1 entry */
         p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
entry_content, 1);
@@ -615,11 +633,12 @@ pod_retry_l1:
                            sizeof(l1e));

     if ( ret == 0 ) {
+        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
         p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
-        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
+        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
+                (l1e_mfn == INVALID_MFN && p2m_is_paging(p2mt)) );

-        if ( p2m_flags_to_type(l1e_get_flags(l1e))
-             == p2m_populate_on_demand )
+        if ( p2mt == p2m_populate_on_demand )
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
@@ -641,7 +660,7 @@ pod_retry_l1:
         }

         if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
-            mfn = _mfn(l1e_get_pfn(l1e));
+            mfn = _mfn(l1e_mfn);
         else
             /* XXX see above */
             p2mt = p2m_mmio_dm;
@@ -783,18 +802,26 @@ pod_retry_l2:
 pod_retry_l1:
     if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
     {
+        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
         /* PoD: Try to populate */
-        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
p2m_populate_on_demand )
+        if ( l1t == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
                 *t = p2m_populate_on_demand;
+        } else {
+            if ( p2m_is_paging(l1t) )
+            {
+                *t = l1t;
+                /* No need to unclip due to check below */
+                mfn = _mfn(l1e_get_pfn(*l1e));
+            }
         }

         unmap_domain_page(l1e);
-        return _mfn(INVALID_MFN);
+        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
     }
     mfn = _mfn(l1e_get_pfn(*l1e));
     *t = p2m_flags_to_type(l1e_get_flags(*l1e));
@@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
                     flags = l1e_get_flags(l1e[i1]);
                     if ( p2m_flags_to_type(flags) != ot )
                         continue;
-                    mfn = l1e_get_pfn(l1e[i1]);
+                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
                     gfn = i1 + (i2 + (i3
 #if CONFIG_PAGING_LEVELS >= 4
 					+ (i4 * L3_PAGETABLE_ENTRIES)
@@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
                            * L2_PAGETABLE_ENTRIES) * L1_PAGETABLE_ENTRIES;
                     /* create a new 1le entry with the new type */
                     flags = p2m_type_to_flags(nt, _mfn(mfn));
-                    l1e_content = l1e_from_pfn(mfn, flags);
+                    l1e_content = l1e_from_pfn(clipped_mfn(mfn), flags);
                     p2m->write_p2m_entry(p2m, gfn, &l1e[i1],
                                          l1mfn, l1e_content, 1);
                 }
@@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
                                 entry_count++;
                             continue;
                         }
-                        mfn = l1e_get_pfn(l1e[i1]);
+                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
                         ASSERT(mfn_valid(_mfn(mfn)));
                         m2pfn = get_gpfn_from_mfn(mfn);
                         if ( m2pfn != gfn &&


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:05:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNga-0004yw-8B; Tue, 14 Feb 2012 19:05:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxNgY-0004yr-KH
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:05:07 +0000
Received: from [85.158.139.83:56513] by server-6.bemta-5.messagelabs.com id
	58/9B-27305-160BA3F4; Tue, 14 Feb 2012 19:05:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329246304!15006059!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTQ4Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9868 invoked from network); 14 Feb 2012 19:05:04 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 19:05:04 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id AA2E2604076;
	Tue, 14 Feb 2012 11:05:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=S5mbjG+r
	JZoeg8WkQkadIPlYxWlW+OT60Ph/gtA6AG8Y8yyqhYtpvaxZvWeb7ERx2cz41N1I
	MwAuSL2+Nm/HmbT/o87QxsoXqnoR2wk5Q6yBjmCsUIJxlXjOWEgtd3tOcqoiOKBE
	ZsBzYO0yK2Hx71pPIDiNCxmiINU+j/0hCgE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	auWFklCBb71GETmbrZ/ma8dl1eE=; b=QFkTUiL4lfC2X3mrYbu9GCmMG04qHz0N
	uwcv/Z4Lgg4O541k3UUl4/z/xjqfr1EsGNtx7qvte0fmbxu2vSAjd3MofNStInGP
	on5N3NdFsYQUfk62eJKALU7ySWT6LexZlW7/n/JPTS0tFUmTqcU+03xXTV0FnPJH
	awUFXLjZT8g=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 99E6E604061; 
	Tue, 14 Feb 2012 11:05:03 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 11:05:03 -0800
Message-ID: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
Date: Tue, 14 Feb 2012 11:05:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We started hashing out some AMD support for mem_paging and mem_access.
Right now my VMs boot, page out a bit, and then die on an HVM triple
fault.

Most importantly, I want to get somebody from AMD to comment/help out on
this. It feels like we're inches away from enabling support for this very
nice feature. I'm not sure who exactly on AMD monitors the list for these
kinds of things. It'd be great to have you on board!

For starters, the changes to the p2m code are relatively mild, but it'd be
great if somebody spots a red flag.

Another issue: comments indicate that bits 59-62 in NPT entries are used
for IOMMU flags but effectively bits 61-62 are. Repossessing one bit (59)
would give us enough space to support mem_access. Right now we only have 7
bits available for Xen flags and that is not enough for paging and access.
Is bit 59 effectively reserved?

Finally, the triple fault. Maybe I'm missing something obvious. Comments
welcome.

Patch inline below, thanks!
Andres

Enable AMD support for paging.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
             if ( !hap_enabled(d) )
                 break;

-            /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
-                break;
-
             rc = -EXDEV;
             /* Disallow paging in a PoD guest */
             if ( p2m->pod.entry_count )
diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -53,6 +53,20 @@
 #define P2M_BASE_FLAGS \
         (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)

+#ifdef __x86_64__
+/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
+ * value tramples over the higher-order bits used for flags (NX, p2mt,
+ * etc.) This happens for paging entries. Thus we do this clip/unclip
+ * juggle for l1 entries only (no paging superpages!) */
+#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
+#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
+#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
+                                INVALID_MFN : (mfn))
+#else
+#define clipped_mfn(mfn)    (mfn)
+#define unclip_mfn(mfn)     (mfn)
+#endif /* __x86_64__ */
+
 static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
 {
     unsigned long flags;
@@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
     case p2m_invalid:
     case p2m_mmio_dm:
     case p2m_populate_on_demand:
+    case p2m_ram_paging_out:
+    case p2m_ram_paged:
+    case p2m_ram_paging_in:
     default:
         return flags;
     case p2m_ram_ro:
@@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
                                       shift, max)) )
         return 0;

-    /* PoD: Not present doesn't imply empty. */
+    /* PoD/paging: Not present doesn't imply empty. */
     if ( !l1e_get_flags(*p2m_entry) )
     {
         struct page_info *pg;
@@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
                                    0, L1_PAGETABLE_ENTRIES);
         ASSERT(p2m_entry);

-        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
-            entry_content = l1e_from_pfn(mfn_x(mfn),
+        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
+             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
+            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
                                          p2m_type_to_flags(p2mt, mfn));
         else
             entry_content = l1e_empty();
@@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
         if ( entry_content.l1 != 0 )
         {
             p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
-            old_mfn = l1e_get_pfn(*p2m_entry);
+            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
         }
         /* level 1 entry */
         p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
entry_content, 1);
@@ -615,11 +633,12 @@ pod_retry_l1:
                            sizeof(l1e));

     if ( ret == 0 ) {
+        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
         p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
-        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
+        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
+                (l1e_mfn == INVALID_MFN && p2m_is_paging(p2mt)) );

-        if ( p2m_flags_to_type(l1e_get_flags(l1e))
-             == p2m_populate_on_demand )
+        if ( p2mt == p2m_populate_on_demand )
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
@@ -641,7 +660,7 @@ pod_retry_l1:
         }

         if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
-            mfn = _mfn(l1e_get_pfn(l1e));
+            mfn = _mfn(l1e_mfn);
         else
             /* XXX see above */
             p2mt = p2m_mmio_dm;
@@ -783,18 +802,26 @@ pod_retry_l2:
 pod_retry_l1:
     if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
     {
+        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
         /* PoD: Try to populate */
-        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
p2m_populate_on_demand )
+        if ( l1t == p2m_populate_on_demand )
         {
             if ( q != p2m_query ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
                 *t = p2m_populate_on_demand;
+        } else {
+            if ( p2m_is_paging(l1t) )
+            {
+                *t = l1t;
+                /* No need to unclip due to check below */
+                mfn = _mfn(l1e_get_pfn(*l1e));
+            }
         }

         unmap_domain_page(l1e);
-        return _mfn(INVALID_MFN);
+        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
     }
     mfn = _mfn(l1e_get_pfn(*l1e));
     *t = p2m_flags_to_type(l1e_get_flags(*l1e));
@@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
                     flags = l1e_get_flags(l1e[i1]);
                     if ( p2m_flags_to_type(flags) != ot )
                         continue;
-                    mfn = l1e_get_pfn(l1e[i1]);
+                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
                     gfn = i1 + (i2 + (i3
 #if CONFIG_PAGING_LEVELS >= 4
 					+ (i4 * L3_PAGETABLE_ENTRIES)
@@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
                            * L2_PAGETABLE_ENTRIES) * L1_PAGETABLE_ENTRIES;
                     /* create a new 1le entry with the new type */
                     flags = p2m_type_to_flags(nt, _mfn(mfn));
-                    l1e_content = l1e_from_pfn(mfn, flags);
+                    l1e_content = l1e_from_pfn(clipped_mfn(mfn), flags);
                     p2m->write_p2m_entry(p2m, gfn, &l1e[i1],
                                          l1mfn, l1e_content, 1);
                 }
@@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
                                 entry_count++;
                             continue;
                         }
-                        mfn = l1e_get_pfn(l1e[i1]);
+                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
                         ASSERT(mfn_valid(_mfn(mfn)));
                         m2pfn = get_gpfn_from_mfn(mfn);
                         if ( m2pfn != gfn &&


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:07:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNiu-00056J-1H; Tue, 14 Feb 2012 19:07: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 1RxNir-00056D-UY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:07:30 +0000
Received: from [85.158.139.83:61170] by server-1.bemta-5.messagelabs.com id
	E7/97-28458-1F0BA3F4; Tue, 14 Feb 2012 19:07:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329246448!12358173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 14 Feb 2012 19:07:28 -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 Feb 2012 19:07:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694019"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:07:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:07:28 +0000
Date: Tue, 14 Feb 2012 19:11:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329149456.31256.133.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141909210.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329149456.31256.133.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/10] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> > Introduce an empty implementation of the arch specific ARM functions in
> > xc_dom_arm.c.
> 
> This bit:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > Also provide empty implementations of xc_domain_save, xc_domain_restore
> > and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
> > set.
> 
> Less sure about this bit.
> 
> Is the content of xc_hvm_build x86 specific? ia64 seems to have it's own
> version in tools/libxc/ia64/xc_ia64_hvm_build.c. (I guess ia64 does not
> define CONFG_HVM, despite apparently supporting HVM? Otherwise I don't
> see how the tools/libxc/Makefile stuff could work)
> 
> Perhaps xc_hvm_build should go to xc_x86_hvm_build.c and
> xc_x86_arm_build.c should have stubs?

Yes, good idea.

> Also xc_hvm_build.c has public functions other than the one you have
> stubbed out in it. Should stub them too?

Yes, they should.


> The migrate case seems more like a temporary band-aid since we will
> eventually want to support that on ARM -- I guess there's no quick hack
> to make it compile since we'd need to define all sorts of things we
> aren't ready to define yet?

I don't think quick hacks are possible here: give a look at
vcpu_guest_context_any_t: it contains two additional fields (x32 and
x64) that are x86_32/64 specific and they are referenced through all the
save/restore code without any ifdefs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:07:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNiu-00056J-1H; Tue, 14 Feb 2012 19:07: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 1RxNir-00056D-UY
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:07:30 +0000
Received: from [85.158.139.83:61170] by server-1.bemta-5.messagelabs.com id
	E7/97-28458-1F0BA3F4; Tue, 14 Feb 2012 19:07:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329246448!12358173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24585 invoked from network); 14 Feb 2012 19:07:28 -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 Feb 2012 19:07:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694019"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:07:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:07:28 +0000
Date: Tue, 14 Feb 2012 19:11:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329149456.31256.133.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141909210.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329149456.31256.133.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 06/10] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> > Introduce an empty implementation of the arch specific ARM functions in
> > xc_dom_arm.c.
> 
> This bit:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > Also provide empty implementations of xc_domain_save, xc_domain_restore
> > and xc_hvm_build_target_mem when CONFIG_HVM or CONFIG_MIGRATE are not
> > set.
> 
> Less sure about this bit.
> 
> Is the content of xc_hvm_build x86 specific? ia64 seems to have it's own
> version in tools/libxc/ia64/xc_ia64_hvm_build.c. (I guess ia64 does not
> define CONFG_HVM, despite apparently supporting HVM? Otherwise I don't
> see how the tools/libxc/Makefile stuff could work)
> 
> Perhaps xc_hvm_build should go to xc_x86_hvm_build.c and
> xc_x86_arm_build.c should have stubs?

Yes, good idea.

> Also xc_hvm_build.c has public functions other than the one you have
> stubbed out in it. Should stub them too?

Yes, they should.


> The migrate case seems more like a temporary band-aid since we will
> eventually want to support that on ARM -- I guess there's no quick hack
> to make it compile since we'd need to define all sorts of things we
> aren't ready to define yet?

I don't think quick hacks are possible here: give a look at
vcpu_guest_context_any_t: it contains two additional fields (x32 and
x64) that are x86_32/64 specific and they are referenced through all the
save/restore code without any ifdefs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:12:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNmw-0005II-Pt; Tue, 14 Feb 2012 19:11:42 +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 1RxNmv-0005I9-Du
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:11:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329246628!62849008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7314 invoked from network); 14 Feb 2012 19:10:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:11:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:11:40 +0000
Date: Tue, 14 Feb 2012 19:16:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20281.18481.118310.621941@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141915360.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20281.18481.118310.621941@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for
 non x86 guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for non x86 guests."):
> ...
> > -
> > +#if defined(__i386__) || defined(__x86_64__)
> 
> I would prefer to avoid these kind of platform-specific ifdefs in
> libxl if possible.  I think we may need to invent libxl_x86.c or
> something.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:12:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNmw-0005II-Pt; Tue, 14 Feb 2012 19:11:42 +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 1RxNmv-0005I9-Du
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:11:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329246628!62849008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7314 invoked from network); 14 Feb 2012 19:10:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:10:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:11:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:11:40 +0000
Date: Tue, 14 Feb 2012 19:16:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20281.18481.118310.621941@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141915360.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<20281.18481.118310.621941@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for
 non x86 guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v2 03/10] libxl: do not allocate e820 for non x86 guests."):
> ...
> > -
> > +#if defined(__i386__) || defined(__x86_64__)
> 
> I would prefer to avoid these kind of platform-specific ifdefs in
> libxl if possible.  I think we may need to invent libxl_x86.c or
> something.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:12:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNnO-0005KH-AH; Tue, 14 Feb 2012 19:12:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxNnM-0005Jt-Qq
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:12:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329246722!2757045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 14 Feb 2012 19:12:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:12:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:12:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:12:03 +0000
Date: Tue, 14 Feb 2012 19:16:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20281.18923.933271.305391@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141916120.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<20281.18923.933271.305391@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v2 07/10] arm: compile libxl"):
> > libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
> > functions are only available on x86, so ifdef the new cpuid related
> > function in libxl_json.c.
> ...
> > +#if defined(__i386__) || defined(__x86_64__)
> >  yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> >                                  libxl_cpuid_policy_list *pcpuid)
> >  {
> > @@ -199,6 +200,13 @@ empty:
> >  out:
> >      return s;
> >  }
> > +#else
> > +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> > +                                libxl_cpuid_policy_list *pcpuid)
> > +{
> > +    return 0;
> > +}
> > +#endif
> 
> Again, can't this be moved to libxl_{no,}cpuid.c ?

Yes, it can.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:12:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNnO-0005KH-AH; Tue, 14 Feb 2012 19:12:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxNnM-0005Jt-Qq
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:12:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329246722!2757045!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 14 Feb 2012 19:12:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:12:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:12:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:12:03 +0000
Date: Tue, 14 Feb 2012 19:16:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20281.18923.933271.305391@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141916120.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<20281.18923.933271.305391@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 07/10] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v2 07/10] arm: compile libxl"):
> > libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
> > functions are only available on x86, so ifdef the new cpuid related
> > function in libxl_json.c.
> ...
> > +#if defined(__i386__) || defined(__x86_64__)
> >  yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> >                                  libxl_cpuid_policy_list *pcpuid)
> >  {
> > @@ -199,6 +200,13 @@ empty:
> >  out:
> >      return s;
> >  }
> > +#else
> > +yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
> > +                                libxl_cpuid_policy_list *pcpuid)
> > +{
> > +    return 0;
> > +}
> > +#endif
> 
> Again, can't this be moved to libxl_{no,}cpuid.c ?

Yes, it can.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:13:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNo6-0005PW-OH; Tue, 14 Feb 2012 19:12:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxNo5-0005Om-1E
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:12:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329246766!13342440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9222 invoked from network); 14 Feb 2012 19:12:46 -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;
	14 Feb 2012 19:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19: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.213.0; Tue, 14 Feb 2012 19:12:45 +0000
Date: Tue, 14 Feb 2012 19:17:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20281.19148.96744.840804@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141916330.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1329149911.31256.141.camel@zakaz.uk.xensource.com>
	<20281.19148.96744.840804@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"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 v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools"):
> > #1 committed.
> 
> Thanks for this series, Stefano.  I have applied a couple that were
> obviously good to go standalone.  For the others which had a tools
> part I have either acked or commented and I think it might be best if
> they all went in together ?

Yes, it is easier for me to keep track of them this way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:13:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNo6-0005PW-OH; Tue, 14 Feb 2012 19:12:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxNo5-0005Om-1E
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:12:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329246766!13342440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9222 invoked from network); 14 Feb 2012 19:12:46 -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;
	14 Feb 2012 19:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19: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.213.0; Tue, 14 Feb 2012 19:12:45 +0000
Date: Tue, 14 Feb 2012 19:17:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20281.19148.96744.840804@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141916330.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1329149911.31256.141.camel@zakaz.uk.xensource.com>
	<20281.19148.96744.840804@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"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 v2 00/10] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2 00/10] arm: compile tools"):
> > #1 committed.
> 
> Thanks for this series, Stefano.  I have applied a couple that were
> obviously good to go standalone.  For the others which had a tools
> part I have either acked or commented and I think it might be best if
> they all went in together ?

Yes, it is easier for me to keep track of them this way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:17:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNsa-0005ls-Fj; Tue, 14 Feb 2012 19:17:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RxNsZ-0005lZ-6n
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:17:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329247043!11472017!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25503 invoked from network); 14 Feb 2012 19:17:24 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 19:17:24 -0000
X-TM-IMSS-Message-ID: <8ba38e4d0002fd79@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 8ba38e4d0002fd79 ;
	Tue, 14 Feb 2012 14:19:13 -0500
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 q1EJHKpN011132; 
	Tue, 14 Feb 2012 14:17:20 -0500
Message-ID: <4F3AB344.1020103@tycho.nsa.gov>
Date: Tue, 14 Feb 2012 14:17:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <osstest-11946-mainreport@xen.org>
	<1329216291.31256.207.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329216291.31256.207.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen.org" <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/14/2012 05:44 AM, Ian Campbell wrote:
> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote:
>> flight 11946 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944
> 
> Host crash:
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log
> 
> This is the debug Andrew Cooper added recently to track down the IRQ
> assertion we've been seeing, sadly it looks like the debug code tries to
> call xfree from interrupt context and therefore doesn't produce full
> output :-(
> 
> Or is 24675:d82a1e3d3c65 ("xsm: Add security label to IRQ debug output")
> at fault for adding the xfree in what may be an IRQ context? (are
> keyhandlers run in IRQ context?)

Keyhandlers are not run in IRQ context (or at least, the primary methods of
invoking them don't run there - serial keypress, xl debug-key). The placement
of the xsm call and xfree was to avoid a similar backtrace from attempting
allocation while holding the irq's spinlock.

> A skanky quick "fix" follows.
> 
>         Feb 13 17:17:29.777522 (XEN) *** IRQ BUG found ***
>         Feb 13 17:19:32.594539 (XEN) CPU0 -Testing vector 229 from bitmap 34,48,57,64,72,75,80,83,88,97,104-105,113,120-121,129,136,144,152,160,168,176,184,192,202
>         Feb 13 17:19:32.617515 (XEN) Guest interrupt information:
>         Feb 13 17:19:32.617536 (XEN)    IRQ:   0 affinity:001 vec:f0 type=IO-APIC-edge    status=00000000 mapped, unbound
>         Feb 13 17:19:32.617567 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
>         Feb 13 17:19:32.626489 (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
>         Feb 13 17:19:32.626512 (XEN) CPU:    0
>         Feb 13 17:19:32.626525 (XEN) RIP:    e008:[<ffff82c48012c842>] xfree+0x33/0x121
>         Feb 13 17:19:32.641496 (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
>         Feb 13 17:19:32.641519 (XEN) rax: ffff82c4802d0800   rbx: ffff8301a7e00080   rcx: 0000000000000000
>         Feb 13 17:19:32.650560 (XEN) rdx: 0000000000000000   rsi: 0000000000000083   rdi: 0000000000000000
>         Feb 13 17:19:32.665510 (XEN) rbp: ffff82c4802afd18   rsp: ffff82c4802afcf8   r8:  0000000000000004
>         Feb 13 17:19:32.665550 (XEN) r9:  0000000000000000   r10: 0000000000000006   r11: ffff82c480224aa0
>         Feb 13 17:19:32.673509 (XEN) r12: ffff8301a7e00580   r13: 0000000000000005   r14: ffff82c4802aff18
>         Feb 13 17:19:32.685503 (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
>         Feb 13 17:19:32.685537 (XEN) cr3: 00000001a7f54000   cr2: 00000000c4b4ee84
>         Feb 13 17:19:32.697505 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
>         Feb 13 17:19:32.697540 (XEN) Xen stack trace from rsp=ffff82c4802afcf8:
>         Feb 13 17:19:32.706513 (XEN)    ffff8301a7e00080 ffff8301a7e00580 0000000000000005 ffff82c4802aff18
>         Feb 13 17:19:32.721495 (XEN)    ffff82c4802afd88 ffff82c4801658ee ffff82c4802afd38 ffff82c48010098a
>         Feb 13 17:19:32.721531 (XEN)    00000400802afd68 0000000000000083 ffff8301a7e000a8 0000000000000000
>         Feb 13 17:19:32.729495 (XEN)    00000000fffffffa 00000000000000e5 ffff8301a7e00580 0000000000000005
>         Feb 13 17:19:32.738490 (XEN)    ffff82c4802aff18 ffff8301a7e005a8 ffff82c4802afe28 ffff82c480167781
>         Feb 13 17:19:32.738515 (XEN)    ffff8301a7ece000 ffff82c4802afde8 0000000000000000 ffff82c4802aff18
>         Feb 13 17:19:32.750497 (XEN)    ffff82c4802aff18 0000000000000002 ffff82c4802aff18 ffff82c4802fa060
>         Feb 13 17:19:32.762568 (XEN)    000000e500000000 ffff82c4802fa060 ffff82c4802afe08 ffff82c48017bd51
>         Feb 13 17:19:32.762596 (XEN)    ffff82c4802aff18 ffff82c4802aff18 ffff82c48025e380 ffff82c4802aff18
>         Feb 13 17:19:32.773513 (XEN)    00000000ffffffff 0000000000000002 00007d3b7fd501a7 ffff82c4801525d0
>         Feb 13 17:19:32.785503 (XEN)    0000000000000002 00000000ffffffff ffff82c4802aff18 ffff82c48025e380
>         Feb 13 17:19:32.785539 (XEN)    ffff82c4802afee0 ffff82c4802aff18 0000001863058413 00000000000c0000
>         Feb 13 17:19:32.794514 (XEN)    000000000e1ff99c 000000000000c701 ffff82c4802f9a90 0000000000000000
>         Feb 13 17:19:32.809503 (XEN)    0000000000000000 ffff8301a7f5dc80 0000000000000000 0000002000000000
>         Feb 13 17:19:32.809529 (XEN)    ffff82c4801581a9 000000000000e008 0000000000000246 ffff82c4802afee0
>         Feb 13 17:19:32.814513 (XEN)    0000000000000000 ffff82c4802aff10 ffff82c48015a647 0000000000000000
>         Feb 13 17:19:32.829506 (XEN)    ffff8300d7cfb000 ffff8300d7af9000 0000000000000000 ffff82c4802afd88
>         Feb 13 17:19:32.829549 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>         Feb 13 17:19:32.841510 (XEN)    00000000dfc91f90 00000000deadbeef 0000000000000000 0000000000000000
>         Feb 13 17:19:32.853508 (XEN)    0000000000000000 0000000000000000 0000000000000000 00000000deadbeef
>         Feb 13 17:19:32.858496 (XEN) Xen call trace:
>         Feb 13 17:19:32.858518 (XEN)    [<ffff82c48012c842>] xfree+0x33/0x121
>         Feb 13 17:19:32.858547 (XEN)    [<ffff82c4801658ee>] dump_irqs+0x2a3/0x2ca
>         Feb 13 17:19:32.870500 (XEN)    [<ffff82c480167781>] smp_irq_move_cleanup_interrupt+0x303/0x37b
>         Feb 13 17:19:32.870554 (XEN)    [<ffff82c4801525d0>] irq_move_cleanup_interrupt+0x30/0x40
>         Feb 13 17:19:32.885510 (XEN)    [<ffff82c4801581a9>] default_idle+0x99/0x9e
>         Feb 13 17:19:32.885541 (XEN)    [<ffff82c48015a647>] idle_loop+0x6c/0x7c
>         Feb 13 17:19:32.897496 (XEN)    
>         Feb 13 17:19:32.897510 (XEN) 
>         Feb 13 17:19:32.897520 (XEN) ****************************************
>         Feb 13 17:19:32.897537 (XEN) Panic on CPU 0:
>         Feb 13 17:19:32.905499 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
>         Feb 13 17:19:32.905522 (XEN) ****************************************
>         Feb 13 17:19:32.913488 (XEN) 
>         Feb 13 17:19:32.913506 (XEN) Reboot in five seconds...
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329216241 0
> # Node ID 738424a5e5a5053c75cfbe64f6675b5d756daf1b
> # Parent  0ba87b95e80bae059fe70b4b117dcc409f2471ef
> xen: don't try to print IRQ SSID in IRQ debug from irq context.
> 
> It is not possible to call xfree() in that context.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0ba87b95e80b -r 738424a5e5a5 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Mon Feb 13 17:26:08 2012 +0000
> +++ b/xen/arch/x86/irq.c	Tue Feb 14 10:44:01 2012 +0000
> @@ -2026,7 +2026,7 @@ static void dump_irqs(unsigned char key)
>          if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
>              continue;
>  
> -        ssid = xsm_show_irq_sid(irq);
> +        ssid = in_irq() ? NULL : xsm_show_irq_sid(irq);
>  
>          spin_lock_irqsave(&desc->lock, flags);
>  
> @@ -2073,7 +2073,8 @@ static void dump_irqs(unsigned char key)
>  
>          spin_unlock_irqrestore(&desc->lock, flags);
>  
> -        xfree(ssid);
> +        if ( ssid )
> +                xfree(ssid);
>      }
>  
>      dump_ioapic_irq_info();
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:17:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxNsa-0005ls-Fj; Tue, 14 Feb 2012 19:17:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RxNsZ-0005lZ-6n
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:17:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329247043!11472017!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25503 invoked from network); 14 Feb 2012 19:17:24 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-216.messagelabs.com with SMTP;
	14 Feb 2012 19:17:24 -0000
X-TM-IMSS-Message-ID: <8ba38e4d0002fd79@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 8ba38e4d0002fd79 ;
	Tue, 14 Feb 2012 14:19:13 -0500
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 q1EJHKpN011132; 
	Tue, 14 Feb 2012 14:17:20 -0500
Message-ID: <4F3AB344.1020103@tycho.nsa.gov>
Date: Tue, 14 Feb 2012 14:17:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <osstest-11946-mainreport@xen.org>
	<1329216291.31256.207.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329216291.31256.207.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen.org" <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/14/2012 05:44 AM, Ian Campbell wrote:
> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote:
>> flight 11946 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 11944
> 
> Host crash:
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log
> 
> This is the debug Andrew Cooper added recently to track down the IRQ
> assertion we've been seeing, sadly it looks like the debug code tries to
> call xfree from interrupt context and therefore doesn't produce full
> output :-(
> 
> Or is 24675:d82a1e3d3c65 ("xsm: Add security label to IRQ debug output")
> at fault for adding the xfree in what may be an IRQ context? (are
> keyhandlers run in IRQ context?)

Keyhandlers are not run in IRQ context (or at least, the primary methods of
invoking them don't run there - serial keypress, xl debug-key). The placement
of the xsm call and xfree was to avoid a similar backtrace from attempting
allocation while holding the irq's spinlock.

> A skanky quick "fix" follows.
> 
>         Feb 13 17:17:29.777522 (XEN) *** IRQ BUG found ***
>         Feb 13 17:19:32.594539 (XEN) CPU0 -Testing vector 229 from bitmap 34,48,57,64,72,75,80,83,88,97,104-105,113,120-121,129,136,144,152,160,168,176,184,192,202
>         Feb 13 17:19:32.617515 (XEN) Guest interrupt information:
>         Feb 13 17:19:32.617536 (XEN)    IRQ:   0 affinity:001 vec:f0 type=IO-APIC-edge    status=00000000 mapped, unbound
>         Feb 13 17:19:32.617567 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
>         Feb 13 17:19:32.626489 (XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
>         Feb 13 17:19:32.626512 (XEN) CPU:    0
>         Feb 13 17:19:32.626525 (XEN) RIP:    e008:[<ffff82c48012c842>] xfree+0x33/0x121
>         Feb 13 17:19:32.641496 (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
>         Feb 13 17:19:32.641519 (XEN) rax: ffff82c4802d0800   rbx: ffff8301a7e00080   rcx: 0000000000000000
>         Feb 13 17:19:32.650560 (XEN) rdx: 0000000000000000   rsi: 0000000000000083   rdi: 0000000000000000
>         Feb 13 17:19:32.665510 (XEN) rbp: ffff82c4802afd18   rsp: ffff82c4802afcf8   r8:  0000000000000004
>         Feb 13 17:19:32.665550 (XEN) r9:  0000000000000000   r10: 0000000000000006   r11: ffff82c480224aa0
>         Feb 13 17:19:32.673509 (XEN) r12: ffff8301a7e00580   r13: 0000000000000005   r14: ffff82c4802aff18
>         Feb 13 17:19:32.685503 (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
>         Feb 13 17:19:32.685537 (XEN) cr3: 00000001a7f54000   cr2: 00000000c4b4ee84
>         Feb 13 17:19:32.697505 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0000   ss: 0000   cs: e008
>         Feb 13 17:19:32.697540 (XEN) Xen stack trace from rsp=ffff82c4802afcf8:
>         Feb 13 17:19:32.706513 (XEN)    ffff8301a7e00080 ffff8301a7e00580 0000000000000005 ffff82c4802aff18
>         Feb 13 17:19:32.721495 (XEN)    ffff82c4802afd88 ffff82c4801658ee ffff82c4802afd38 ffff82c48010098a
>         Feb 13 17:19:32.721531 (XEN)    00000400802afd68 0000000000000083 ffff8301a7e000a8 0000000000000000
>         Feb 13 17:19:32.729495 (XEN)    00000000fffffffa 00000000000000e5 ffff8301a7e00580 0000000000000005
>         Feb 13 17:19:32.738490 (XEN)    ffff82c4802aff18 ffff8301a7e005a8 ffff82c4802afe28 ffff82c480167781
>         Feb 13 17:19:32.738515 (XEN)    ffff8301a7ece000 ffff82c4802afde8 0000000000000000 ffff82c4802aff18
>         Feb 13 17:19:32.750497 (XEN)    ffff82c4802aff18 0000000000000002 ffff82c4802aff18 ffff82c4802fa060
>         Feb 13 17:19:32.762568 (XEN)    000000e500000000 ffff82c4802fa060 ffff82c4802afe08 ffff82c48017bd51
>         Feb 13 17:19:32.762596 (XEN)    ffff82c4802aff18 ffff82c4802aff18 ffff82c48025e380 ffff82c4802aff18
>         Feb 13 17:19:32.773513 (XEN)    00000000ffffffff 0000000000000002 00007d3b7fd501a7 ffff82c4801525d0
>         Feb 13 17:19:32.785503 (XEN)    0000000000000002 00000000ffffffff ffff82c4802aff18 ffff82c48025e380
>         Feb 13 17:19:32.785539 (XEN)    ffff82c4802afee0 ffff82c4802aff18 0000001863058413 00000000000c0000
>         Feb 13 17:19:32.794514 (XEN)    000000000e1ff99c 000000000000c701 ffff82c4802f9a90 0000000000000000
>         Feb 13 17:19:32.809503 (XEN)    0000000000000000 ffff8301a7f5dc80 0000000000000000 0000002000000000
>         Feb 13 17:19:32.809529 (XEN)    ffff82c4801581a9 000000000000e008 0000000000000246 ffff82c4802afee0
>         Feb 13 17:19:32.814513 (XEN)    0000000000000000 ffff82c4802aff10 ffff82c48015a647 0000000000000000
>         Feb 13 17:19:32.829506 (XEN)    ffff8300d7cfb000 ffff8300d7af9000 0000000000000000 ffff82c4802afd88
>         Feb 13 17:19:32.829549 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>         Feb 13 17:19:32.841510 (XEN)    00000000dfc91f90 00000000deadbeef 0000000000000000 0000000000000000
>         Feb 13 17:19:32.853508 (XEN)    0000000000000000 0000000000000000 0000000000000000 00000000deadbeef
>         Feb 13 17:19:32.858496 (XEN) Xen call trace:
>         Feb 13 17:19:32.858518 (XEN)    [<ffff82c48012c842>] xfree+0x33/0x121
>         Feb 13 17:19:32.858547 (XEN)    [<ffff82c4801658ee>] dump_irqs+0x2a3/0x2ca
>         Feb 13 17:19:32.870500 (XEN)    [<ffff82c480167781>] smp_irq_move_cleanup_interrupt+0x303/0x37b
>         Feb 13 17:19:32.870554 (XEN)    [<ffff82c4801525d0>] irq_move_cleanup_interrupt+0x30/0x40
>         Feb 13 17:19:32.885510 (XEN)    [<ffff82c4801581a9>] default_idle+0x99/0x9e
>         Feb 13 17:19:32.885541 (XEN)    [<ffff82c48015a647>] idle_loop+0x6c/0x7c
>         Feb 13 17:19:32.897496 (XEN)    
>         Feb 13 17:19:32.897510 (XEN) 
>         Feb 13 17:19:32.897520 (XEN) ****************************************
>         Feb 13 17:19:32.897537 (XEN) Panic on CPU 0:
>         Feb 13 17:19:32.905499 (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607
>         Feb 13 17:19:32.905522 (XEN) ****************************************
>         Feb 13 17:19:32.913488 (XEN) 
>         Feb 13 17:19:32.913506 (XEN) Reboot in five seconds...
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329216241 0
> # Node ID 738424a5e5a5053c75cfbe64f6675b5d756daf1b
> # Parent  0ba87b95e80bae059fe70b4b117dcc409f2471ef
> xen: don't try to print IRQ SSID in IRQ debug from irq context.
> 
> It is not possible to call xfree() in that context.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0ba87b95e80b -r 738424a5e5a5 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Mon Feb 13 17:26:08 2012 +0000
> +++ b/xen/arch/x86/irq.c	Tue Feb 14 10:44:01 2012 +0000
> @@ -2026,7 +2026,7 @@ static void dump_irqs(unsigned char key)
>          if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
>              continue;
>  
> -        ssid = xsm_show_irq_sid(irq);
> +        ssid = in_irq() ? NULL : xsm_show_irq_sid(irq);
>  
>          spin_lock_irqsave(&desc->lock, flags);
>  
> @@ -2073,7 +2073,8 @@ static void dump_irqs(unsigned char key)
>  
>          spin_unlock_irqrestore(&desc->lock, flags);
>  
> -        xfree(ssid);
> +        if ( ssid )
> +                xfree(ssid);
>      }
>  
>      dump_ioapic_irq_info();
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:23:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNyA-0005wZ-Ay; Tue, 14 Feb 2012 19:23:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxNy9-0005wU-5t
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:23:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329247389!4017479!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15352 invoked from network); 14 Feb 2012 19:23:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 19:23:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329247389; l=142;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=QgjWFDo2blaqr2+B5AkMJTDpRaY=;
	b=vnKb/j0jbjqrW0Llg9V29XRvOuxsqSpxQ7zq9FJdR98+cJDjo8hA42pJicDjQOe1WW2
	ENLwFM9tBhAyvklBM91OnXoiUwtRO/oevTjGbmTEyGXgz2Wg2vYfZ+u1fSLEWYKqlfVmZ
	4843tfNHlpVPd6EPStTsLj7XuypGhdV2Ass=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (klopstock mo43) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q04492o1EIslKY ;
	Tue, 14 Feb 2012 20:22:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E8EDB18637; Tue, 14 Feb 2012 20:22:49 +0100 (CET)
Date: Tue, 14 Feb 2012 20:22:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214192249.GA10224@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> Finally, the triple fault.

"Me too!"
Thats how far I got as well in my attempt.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:23:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxNyA-0005wZ-Ay; Tue, 14 Feb 2012 19:23:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxNy9-0005wU-5t
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:23:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329247389!4017479!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNjI0NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15352 invoked from network); 14 Feb 2012 19:23:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 19:23:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329247389; l=142;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=QgjWFDo2blaqr2+B5AkMJTDpRaY=;
	b=vnKb/j0jbjqrW0Llg9V29XRvOuxsqSpxQ7zq9FJdR98+cJDjo8hA42pJicDjQOe1WW2
	ENLwFM9tBhAyvklBM91OnXoiUwtRO/oevTjGbmTEyGXgz2Wg2vYfZ+u1fSLEWYKqlfVmZ
	4843tfNHlpVPd6EPStTsLj7XuypGhdV2Ass=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (klopstock mo43) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q04492o1EIslKY ;
	Tue, 14 Feb 2012 20:22:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E8EDB18637; Tue, 14 Feb 2012 20:22:49 +0100 (CET)
Date: Tue, 14 Feb 2012 20:22:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214192249.GA10224@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> Finally, the triple fault.

"Me too!"
Thats how far I got as well in my attempt.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:36:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxOAA-0006QY-K6; Tue, 14 Feb 2012 19:35:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxOA8-0006QT-K3
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:35:40 +0000
Received: from [85.158.139.83:38591] by server-5.bemta-5.messagelabs.com id
	01/65-13566-B87BA3F4; Tue, 14 Feb 2012 19:35:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329248138!15078917!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTI4Njc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11087 invoked from network); 14 Feb 2012 19:35:39 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-2.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 19:35:39 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id E848D4B008F;
	Tue, 14 Feb 2012 11:35:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=jmUi1gzw1olNhDMP9AhGspzyOS0SNyH9NfSNkcoTBNLj
	LnlssFeH+aC/wk+5brxIcYzSOAJCltieO8keK9Xbvxbb6KQS5AUjE1oQYEfPM9i4
	Ecu2XQ12O+OZhVWyN8iOFE3dJ1pe4t1DRQI8MCpIXJmbp9bv05n4aTkiWQpWFeg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Umlu8amrcaLGQG+D4U2qLmxXPuU=; b=nzFpEGCr
	KHGFQYyzgs0eHBG5AUtA9O8VeCIRYCV5qiCjSuyYCKaxqbu7GhZL/anMGV8tUpb2
	S1vDsf6idKOpbWjmF72fq+g+bPHhy6/8IiqWycxoc+fN4jz++bo3bu/8o1U9hoWF
	r1SYuTnpFpl856ipakloWSuMf6HtYhYkucA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 6AC374B0091; 
	Tue, 14 Feb 2012 11:35:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 11:35:37 -0800
Message-ID: <2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214192249.GA10224@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
Date: Tue, 14 Feb 2012 11:35:37 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> Finally, the triple fault.
>
> "Me too!"
> Thats how far I got as well in my attempt.

Hey, awesome you're trying this out so quickly :)

I just realized the unclip_mfn macro in my patch is broken. It should
instead be

+#define unclip_mfn(mfn)     (((mfn) == clipped_mfn(INVALID_MFN)) ? \
+                                INVALID_MFN : (mfn))

If you have a couple cycles...

Thanks a lot!
Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:36:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxOAA-0006QY-K6; Tue, 14 Feb 2012 19:35:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxOA8-0006QT-K3
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:35:40 +0000
Received: from [85.158.139.83:38591] by server-5.bemta-5.messagelabs.com id
	01/65-13566-B87BA3F4; Tue, 14 Feb 2012 19:35:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329248138!15078917!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTI4Njc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11087 invoked from network); 14 Feb 2012 19:35:39 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.177) by server-2.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 19:35:39 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id E848D4B008F;
	Tue, 14 Feb 2012 11:35:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=jmUi1gzw1olNhDMP9AhGspzyOS0SNyH9NfSNkcoTBNLj
	LnlssFeH+aC/wk+5brxIcYzSOAJCltieO8keK9Xbvxbb6KQS5AUjE1oQYEfPM9i4
	Ecu2XQ12O+OZhVWyN8iOFE3dJ1pe4t1DRQI8MCpIXJmbp9bv05n4aTkiWQpWFeg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Umlu8amrcaLGQG+D4U2qLmxXPuU=; b=nzFpEGCr
	KHGFQYyzgs0eHBG5AUtA9O8VeCIRYCV5qiCjSuyYCKaxqbu7GhZL/anMGV8tUpb2
	S1vDsf6idKOpbWjmF72fq+g+bPHhy6/8IiqWycxoc+fN4jz++bo3bu/8o1U9hoWF
	r1SYuTnpFpl856ipakloWSuMf6HtYhYkucA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 6AC374B0091; 
	Tue, 14 Feb 2012 11:35:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 11:35:37 -0800
Message-ID: <2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214192249.GA10224@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
Date: Tue, 14 Feb 2012 11:35:37 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> Finally, the triple fault.
>
> "Me too!"
> Thats how far I got as well in my attempt.

Hey, awesome you're trying this out so quickly :)

I just realized the unclip_mfn macro in my patch is broken. It should
instead be

+#define unclip_mfn(mfn)     (((mfn) == clipped_mfn(INVALID_MFN)) ? \
+                                INVALID_MFN : (mfn))

If you have a couple cycles...

Thanks a lot!
Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:43:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOHa-0006cP-PE; Tue, 14 Feb 2012 19:43:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOHZ-0006cK-AW
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:43:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329248595!13962311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2530 invoked from network); 14 Feb 2012 19:43:15 -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 Feb 2012 19:43:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:43:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:43:15 +0000
Date: Tue, 14 Feb 2012 19:47:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329135711.31256.81.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141947310.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329135711.31256.81.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 02/10] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> > From: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> When forwarding on other peoples patches please can you remember to
> include your own explicit Signed-off-by or Acked-by (I think the former
> is generally more appropriate per 2b or 2c of the DCO).
> 
> This is particularly important if I am the original author since I don't
> want to act as both Ack-er and commit-er of my own patches.
> 

OK


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:43:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOHa-0006cP-PE; Tue, 14 Feb 2012 19:43:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOHZ-0006cK-AW
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:43:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329248595!13962311!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2530 invoked from network); 14 Feb 2012 19:43:15 -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 Feb 2012 19:43:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:43:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:43:15 +0000
Date: Tue, 14 Feb 2012 19:47:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329135711.31256.81.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141947310.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329135711.31256.81.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 02/10] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 13 Feb 2012, Ian Campbell wrote:
> On Fri, 2012-02-10 at 12:02 +0000, Stefano Stabellini wrote:
> > From: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> When forwarding on other peoples patches please can you remember to
> include your own explicit Signed-off-by or Acked-by (I think the former
> is generally more appropriate per 2b or 2c of the DCO).
> 
> This is particularly important if I am the original author since I don't
> want to act as both Ack-er and commit-er of my own patches.
> 

OK


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:49:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxON2-0006nU-JJ; Tue, 14 Feb 2012 19:49:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxON0-0006nF-Ud
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:48:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329248932!11393782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23762 invoked from network); 14 Feb 2012 19:48:53 -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 Feb 2012 19:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:48:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:48:52 +0000
Date: Tue, 14 Feb 2012 19:53:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v3 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;

- remove "libxl: do not allocate e820 for non x86 guests.";

- introduce libxl__arch_domain_create.



Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (1):
      arm: add stub hvm/save.h

Stefano Stabellini (6):
      arm: compile libxc
      arm: compile libxenguest
      arm: compile memshr
      arm: compile xentrace
      arm: compile libxl
      libxl: Introduce libxl__arch_domain_create

 tools/libxc/Makefile                   |   13 +-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 +++++++
 tools/libxc/xc_core_arm.h              |   60 ++++
 tools/libxc/xc_dom_arm.c               |   49 +++
 tools/libxc/xc_hvm_build.c             |  511 --------------------------------
 tools/libxc/xc_hvm_build_arm.c         |   48 +++
 tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c             |   41 +++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    5 +-
 tools/libxl/libxl_arch.h               |   22 ++
 tools/libxl/libxl_cpuid.c              |   62 ++++
 tools/libxl/libxl_create.c             |   12 +-
 tools/libxl/libxl_json.c               |   60 ----
 tools/libxl/libxl_noarch.c             |    8 +
 tools/libxl/libxl_nocpuid.c            |    8 +-
 tools/libxl/libxl_pci.c                |  242 ---------------
 tools/libxl/libxl_x86.c                |  258 ++++++++++++++++
 tools/memshr/bidir-hash.c              |   31 ++
 tools/xentrace/xenctx.c                |   12 +
 xen/include/public/arch-arm/hvm/save.h |   39 +++
 xen/include/public/hvm/save.h          |    2 +
 23 files changed, 1277 insertions(+), 829 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:49:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19: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.xensource.com>)
	id 1RxON2-0006nU-JJ; Tue, 14 Feb 2012 19:49:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxON0-0006nF-Ud
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:48:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329248932!11393782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23762 invoked from network); 14 Feb 2012 19:48:53 -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 Feb 2012 19:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 19:48:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 19:48:52 +0000
Date: Tue, 14 Feb 2012 19:53:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v3 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;

- remove "libxl: do not allocate e820 for non x86 guests.";

- introduce libxl__arch_domain_create.



Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (1):
      arm: add stub hvm/save.h

Stefano Stabellini (6):
      arm: compile libxc
      arm: compile libxenguest
      arm: compile memshr
      arm: compile xentrace
      arm: compile libxl
      libxl: Introduce libxl__arch_domain_create

 tools/libxc/Makefile                   |   13 +-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 +++++++
 tools/libxc/xc_core_arm.h              |   60 ++++
 tools/libxc/xc_dom_arm.c               |   49 +++
 tools/libxc/xc_hvm_build.c             |  511 --------------------------------
 tools/libxc/xc_hvm_build_arm.c         |   48 +++
 tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c             |   41 +++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    5 +-
 tools/libxl/libxl_arch.h               |   22 ++
 tools/libxl/libxl_cpuid.c              |   62 ++++
 tools/libxl/libxl_create.c             |   12 +-
 tools/libxl/libxl_json.c               |   60 ----
 tools/libxl/libxl_noarch.c             |    8 +
 tools/libxl/libxl_nocpuid.c            |    8 +-
 tools/libxl/libxl_pci.c                |  242 ---------------
 tools/libxl/libxl_x86.c                |  258 ++++++++++++++++
 tools/memshr/bidir-hash.c              |   31 ++
 tools/xentrace/xenctx.c                |   12 +
 xen/include/public/arch-arm/hvm/save.h |   39 +++
 xen/include/public/hvm/save.h          |    2 +
 23 files changed, 1277 insertions(+), 829 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOU-0006vI-G8; Tue, 14 Feb 2012 19:50:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOS-0006sN-EF
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329249020!13309728!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4529 invoked from network); 14 Feb 2012 19:50:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750326"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:19 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZN028922;
	Tue, 14 Feb 2012 11:50:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:31 +0000
Message-ID: <1329249275-18515-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Provide empty implementations of xc_domain_save and xc_domain_restore
when CONFIG_MIGRATE is not set.
Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
x86 specific, introduce xc_hvm_build_arm.c with empty stubs.


Changes in v3:

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;



Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile           |   12 +-
 tools/libxc/xc_dom_arm.c       |   49 ++++
 tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
 tools/libxc/xc_hvm_build_arm.c |   48 ++++
 tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c     |   41 ++++
 6 files changed, 658 insertions(+), 514 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build.c
 create mode 100644 tools/libxc/xc_hvm_build_arm.c
 create mode 100644 tools/libxc/xc_hvm_build_x86.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..02d39a3 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
deleted file mode 100644
index 1fa5658..0000000
--- a/tools/libxc/xc_hvm_build.c
+++ /dev/null
@@ -1,511 +0,0 @@
-/******************************************************************************
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <stddef.h>
-#include <inttypes.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <zlib.h>
-
-#include "xg_private.h"
-#include "xc_private.h"
-
-#include <xen/foreign/x86_32.h>
-#include <xen/foreign/x86_64.h>
-#include <xen/hvm/hvm_info_table.h>
-#include <xen/hvm/params.h>
-#include <xen/hvm/e820.h>
-
-#include <xen/libelf/libelf.h>
-
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
-
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
-{
-    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
-        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
-    uint64_t lowmem_end = mem_size, highmem_end = 0;
-    uint8_t sum;
-    int i;
-
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
-    {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
-    }
-
-    memset(hvm_info_page, 0, PAGE_SIZE);
-
-    /* Fill in the header. */
-    strncpy(hvm_info->signature, "HVM INFO", 8);
-    hvm_info->length = sizeof(struct hvm_info_table);
-
-    /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->apic_mode = 1;
-    hvm_info->nr_vcpus = 1;
-    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
-
-    /* Memory parameters. */
-    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
-    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
-    hvm_info->reserved_mem_pgstart = special_pfn(0);
-
-    /* Finish with the checksum. */
-    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
-        sum += ((uint8_t *)hvm_info)[i];
-    hvm_info->checksum = -sum;
-}
-
-static int loadelfimage(
-    xc_interface *xch,
-    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
-{
-    privcmd_mmap_entry_t *entries = NULL;
-    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
-    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
-    size_t pages = pfn_end - pfn_start;
-    int i, rc = -1;
-
-    /* Map address space for initial elf image. */
-    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-    if ( entries == NULL )
-        goto err;
-
-    for ( i = 0; i < pages; i++ )
-        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
-
-    elf->dest = xc_map_foreign_ranges(
-        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
-        entries, pages);
-    if ( elf->dest == NULL )
-        goto err;
-
-    elf->dest += elf->pstart & (PAGE_SIZE - 1);
-
-    /* Load the initial elf image. */
-    rc = elf_load_binary(elf);
-    if ( rc < 0 )
-        PERROR("Failed to load elf binary\n");
-
-    munmap(elf->dest, pages << PAGE_SHIFT);
-    elf->dest = NULL;
-
- err:
-    free(entries);
-
-    return rc;
-}
-
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
-{
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
-        return 0;
-    else
-        return 1;
-}
-
-static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
-                       char *image, unsigned long image_size)
-{
-    xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
-    unsigned long entry_eip, cur_pages, cur_pfn;
-    void *hvm_info_page;
-    uint32_t *ident_pt;
-    struct elf_binary elf;
-    uint64_t v_start, v_end;
-    int rc;
-    xen_capabilities_info_t caps;
-    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
-        stat_1gb_pages = 0;
-    int pod_mode = 0;
-
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
-        pod_mode = 1;
-
-    memset(&elf, 0, sizeof(elf));
-    if ( elf_init(&elf, image, image_size) != 0 )
-        goto error_out;
-
-    xc_elf_set_logfile(xch, &elf, 1);
-
-    elf_parse_binary(&elf);
-    v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
-
-    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
-    {
-        PERROR("Could not get Xen capabilities");
-        goto error_out;
-    }
-
-    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
-            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
-            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
-            "  ENTRY ADDRESS: %016"PRIx64"\n",
-            elf.pstart, elf.pend,
-            v_start, v_end,
-            elf_uval(&elf, elf.ehdr, e_entry));
-
-    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
-    {
-        PERROR("Could not allocate memory.");
-        goto error_out;
-    }
-
-    for ( i = 0; i < nr_pages; i++ )
-        page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
-
-    /*
-     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
-     *
-     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
-     * pages if 1GB allocation fails. 4KB pages will be used eventually if
-     * both fail.
-     * 
-     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
-     * ensure that we can be preempted and hence dom0 remains responsive.
-     */
-    rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
-    cur_pages = 0xc0;
-    stat_normal_pages = 0xc0;
-    while ( (rc == 0) && (nr_pages > cur_pages) )
-    {
-        /* Clip count to maximum 1GB extent. */
-        unsigned long count = nr_pages - cur_pages;
-        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-        if ( count > max_pages )
-            count = max_pages;
-
-        cur_pfn = page_array[cur_pages];
-
-        /* Take care the corner cases of super page tails */
-        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
-            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
-        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-                  (count > SUPERPAGE_1GB_NR_PFNS) )
-            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-        /* Attemp to allocate 1GB super page. Because in each pass we only
-         * allocate at most 1GB, we don't have to clip super page boundaries.
-         */
-        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
-             /* Check if there exists MMIO hole in the 1GB memory range */
-             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
-        {
-            long done;
-            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
-            xen_pfn_t sp_extents[nr_extents];
-
-            for ( i = 0; i < nr_extents; i++ )
-                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
-
-            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
-                                              pod_mode ? XENMEMF_populate_on_demand : 0,
-                                              sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
-        }
-
-        if ( count != 0 )
-        {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
-            if ( count > max_pages )
-                count = max_pages;
-            
-            /* Clip partial superpage extents to superpage boundaries. */
-            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
-                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
-            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                      (count > SUPERPAGE_2MB_NR_PFNS) )
-                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-            /* Attempt to allocate superpage extents. */
-            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
-            {
-                long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
-                xen_pfn_t sp_extents[nr_extents];
-
-                for ( i = 0; i < nr_extents; i++ )
-                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
-
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
-                                                  sp_extents);
-
-                if ( done > 0 )
-                {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
-                    cur_pages += done;
-                    count -= done;
-                }
-            }
-        }
-
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, 0, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
-        }
-    }
-
-    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
-     * adjust the PoD cache size so that domain tot_pages will be
-     * target_pages - 0x20 after this call. */
-    if ( pod_mode )
-        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
-                                      NULL, NULL, NULL);
-
-    if ( rc != 0 )
-    {
-        PERROR("Could not allocate memory for HVM guest.");
-        goto error_out;
-    }
-
-    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
-            "  4KB PAGES: 0x%016lx\n"
-            "  2MB PAGES: 0x%016lx\n"
-            "  1GB PAGES: 0x%016lx\n",
-            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
-    
-    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
-        goto error_out;
-
-    if ( (hvm_info_page = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              HVM_INFO_PFN)) == NULL )
-        goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
-    munmap(hvm_info_page, PAGE_SIZE);
-
-    /* Allocate and clear special pages. */
-    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-    {
-        xen_pfn_t pfn = special_pfn(i);
-        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
-        if ( rc != 0 )
-        {
-            PERROR("Could not allocate %d'th special page.", i);
-            goto error_out;
-        }
-        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
-            goto error_out;
-    }
-
-    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
-                     special_pfn(SPECIALPAGE_XENSTORE));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
-                     special_pfn(SPECIALPAGE_BUFIOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
-                     special_pfn(SPECIALPAGE_IOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
-                     special_pfn(SPECIALPAGE_CONSOLE));
-
-    /*
-     * Identity-map page table is required for running with CR0.PG=0 when
-     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
-     */
-    if ( (ident_pt = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
-        goto error_out;
-    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
-        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
-                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-    munmap(ident_pt, PAGE_SIZE);
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
-                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
-
-    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
-    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
-    if ( entry_eip != 0 )
-    {
-        char *page0 = xc_map_foreign_range(
-            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
-        if ( page0 == NULL )
-            goto error_out;
-        page0[0] = 0xe9;
-        *(uint32_t *)&page0[1] = entry_eip - 5;
-        munmap(page0, PAGE_SIZE);
-    }
-
-    free(page_array);
-    return 0;
-
- error_out:
-    free(page_array);
-    return -1;
-}
-
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
-/* xc_hvm_build:
- * Create a domain for a virtualized Linux, using files/filenames.
- */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_target_mem: 
- * Create a domain for a pre-ballooned virtualized Linux, using
- * files/filenames.  If target < memsize, domain is created with
- * memsize pages marked populate-on-demand, 
- * calculating pod cache size based on target.
- * If target == memsize, pages are populated normally.
- */
-int xc_hvm_build_target_mem(xc_interface *xch,
-                           uint32_t domid,
-                           int memsize,
-                           int target,
-                           const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
new file mode 100644
index 0000000..6cf65a1
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_arm.c
@@ -0,0 +1,48 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
new file mode 100644
index 0000000..1fa5658
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -0,0 +1,511 @@
+/******************************************************************************
+ * xc_hvm_build.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stddef.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <zlib.h>
+
+#include "xg_private.h"
+#include "xc_private.h"
+
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/params.h>
+#include <xen/hvm/e820.h>
+
+#include <xen/libelf/libelf.h>
+
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define SPECIALPAGE_BUFIOREQ 0
+#define SPECIALPAGE_XENSTORE 1
+#define SPECIALPAGE_IOREQ    2
+#define SPECIALPAGE_IDENT_PT 3
+#define SPECIALPAGE_CONSOLE  4
+#define NR_SPECIAL_PAGES     5
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+{
+    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+    uint64_t lowmem_end = mem_size, highmem_end = 0;
+    uint8_t sum;
+    int i;
+
+    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    {
+        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
+        lowmem_end = HVM_BELOW_4G_RAM_END;
+    }
+
+    memset(hvm_info_page, 0, PAGE_SIZE);
+
+    /* Fill in the header. */
+    strncpy(hvm_info->signature, "HVM INFO", 8);
+    hvm_info->length = sizeof(struct hvm_info_table);
+
+    /* Sensible defaults: these can be overridden by the caller. */
+    hvm_info->apic_mode = 1;
+    hvm_info->nr_vcpus = 1;
+    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+    /* Memory parameters. */
+    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
+    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
+    hvm_info->reserved_mem_pgstart = special_pfn(0);
+
+    /* Finish with the checksum. */
+    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+        sum += ((uint8_t *)hvm_info)[i];
+    hvm_info->checksum = -sum;
+}
+
+static int loadelfimage(
+    xc_interface *xch,
+    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
+{
+    privcmd_mmap_entry_t *entries = NULL;
+    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
+    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
+    size_t pages = pfn_end - pfn_start;
+    int i, rc = -1;
+
+    /* Map address space for initial elf image. */
+    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
+    if ( entries == NULL )
+        goto err;
+
+    for ( i = 0; i < pages; i++ )
+        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
+
+    elf->dest = xc_map_foreign_ranges(
+        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
+        entries, pages);
+    if ( elf->dest == NULL )
+        goto err;
+
+    elf->dest += elf->pstart & (PAGE_SIZE - 1);
+
+    /* Load the initial elf image. */
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
+
+    munmap(elf->dest, pages << PAGE_SHIFT);
+    elf->dest = NULL;
+
+ err:
+    free(entries);
+
+    return rc;
+}
+
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize)
+{
+    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
+         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+        return 0;
+    else
+        return 1;
+}
+
+static int setup_guest(xc_interface *xch,
+                       uint32_t dom, int memsize, int target,
+                       char *image, unsigned long image_size)
+{
+    xen_pfn_t *page_array = NULL;
+    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
+    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long entry_eip, cur_pages, cur_pfn;
+    void *hvm_info_page;
+    uint32_t *ident_pt;
+    struct elf_binary elf;
+    uint64_t v_start, v_end;
+    int rc;
+    xen_capabilities_info_t caps;
+    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
+        stat_1gb_pages = 0;
+    int pod_mode = 0;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( memsize < 2 || target < 2 )
+        goto error_out;
+
+    if ( memsize > target )
+        pod_mode = 1;
+
+    memset(&elf, 0, sizeof(elf));
+    if ( elf_init(&elf, image, image_size) != 0 )
+        goto error_out;
+
+    xc_elf_set_logfile(xch, &elf, 1);
+
+    elf_parse_binary(&elf);
+    v_start = 0;
+    v_end = (unsigned long long)memsize << 20;
+
+    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+    {
+        PERROR("Could not get Xen capabilities");
+        goto error_out;
+    }
+
+    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
+            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
+            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
+            "  ENTRY ADDRESS: %016"PRIx64"\n",
+            elf.pstart, elf.pend,
+            v_start, v_end,
+            elf_uval(&elf, elf.ehdr, e_entry));
+
+    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
+    {
+        PERROR("Could not allocate memory.");
+        goto error_out;
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+        page_array[i] = i;
+    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+
+    /*
+     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
+     *
+     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+     * pages if 1GB allocation fails. 4KB pages will be used eventually if
+     * both fail.
+     * 
+     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
+     * ensure that we can be preempted and hence dom0 remains responsive.
+     */
+    rc = xc_domain_populate_physmap_exact(
+        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
+    cur_pages = 0xc0;
+    stat_normal_pages = 0xc0;
+    while ( (rc == 0) && (nr_pages > cur_pages) )
+    {
+        /* Clip count to maximum 1GB extent. */
+        unsigned long count = nr_pages - cur_pages;
+        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+        if ( count > max_pages )
+            count = max_pages;
+
+        cur_pfn = page_array[cur_pages];
+
+        /* Take care the corner cases of super page tails */
+        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
+            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
+        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+                  (count > SUPERPAGE_1GB_NR_PFNS) )
+            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+        /* Attemp to allocate 1GB super page. Because in each pass we only
+         * allocate at most 1GB, we don't have to clip super page boundaries.
+         */
+        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
+             /* Check if there exists MMIO hole in the 1GB memory range */
+             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+        {
+            long done;
+            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
+            xen_pfn_t sp_extents[nr_extents];
+
+            for ( i = 0; i < nr_extents; i++ )
+                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
+
+            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                              pod_mode ? XENMEMF_populate_on_demand : 0,
+                                              sp_extents);
+
+            if ( done > 0 )
+            {
+                stat_1gb_pages += done;
+                done <<= SUPERPAGE_1GB_SHIFT;
+                cur_pages += done;
+                count -= done;
+            }
+        }
+
+        if ( count != 0 )
+        {
+            /* Clip count to maximum 8MB extent. */
+            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            if ( count > max_pages )
+                count = max_pages;
+            
+            /* Clip partial superpage extents to superpage boundaries. */
+            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
+                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
+            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                      (count > SUPERPAGE_2MB_NR_PFNS) )
+                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+            /* Attempt to allocate superpage extents. */
+            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+            {
+                long done;
+                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                xen_pfn_t sp_extents[nr_extents];
+
+                for ( i = 0; i < nr_extents; i++ )
+                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
+                                                  sp_extents);
+
+                if ( done > 0 )
+                {
+                    stat_2mb_pages += done;
+                    done <<= SUPERPAGE_2MB_SHIFT;
+                    cur_pages += done;
+                    count -= done;
+                }
+            }
+        }
+
+        /* Fall back to 4kB extents. */
+        if ( count != 0 )
+        {
+            rc = xc_domain_populate_physmap_exact(
+                xch, dom, count, 0, 0, &page_array[cur_pages]);
+            cur_pages += count;
+            stat_normal_pages += count;
+        }
+    }
+
+    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
+     * adjust the PoD cache size so that domain tot_pages will be
+     * target_pages - 0x20 after this call. */
+    if ( pod_mode )
+        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
+                                      NULL, NULL, NULL);
+
+    if ( rc != 0 )
+    {
+        PERROR("Could not allocate memory for HVM guest.");
+        goto error_out;
+    }
+
+    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+            "  4KB PAGES: 0x%016lx\n"
+            "  2MB PAGES: 0x%016lx\n"
+            "  1GB PAGES: 0x%016lx\n",
+            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+    
+    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
+        goto error_out;
+
+    if ( (hvm_info_page = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              HVM_INFO_PFN)) == NULL )
+        goto error_out;
+    build_hvm_info(hvm_info_page, v_end);
+    munmap(hvm_info_page, PAGE_SIZE);
+
+    /* Allocate and clear special pages. */
+    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+    {
+        xen_pfn_t pfn = special_pfn(i);
+        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Could not allocate %d'th special page.", i);
+            goto error_out;
+        }
+        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+            goto error_out;
+    }
+
+    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
+                     special_pfn(SPECIALPAGE_XENSTORE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
+                     special_pfn(SPECIALPAGE_BUFIOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
+                     special_pfn(SPECIALPAGE_IOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
+                     special_pfn(SPECIALPAGE_CONSOLE));
+
+    /*
+     * Identity-map page table is required for running with CR0.PG=0 when
+     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
+     */
+    if ( (ident_pt = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
+        goto error_out;
+    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
+        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+    munmap(ident_pt, PAGE_SIZE);
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
+                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
+
+    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
+    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
+    if ( entry_eip != 0 )
+    {
+        char *page0 = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+        if ( page0 == NULL )
+            goto error_out;
+        page0[0] = 0xe9;
+        *(uint32_t *)&page0[1] = entry_eip - 5;
+        munmap(page0, PAGE_SIZE);
+    }
+
+    free(page_array);
+    return 0;
+
+ error_out:
+    free(page_array);
+    return -1;
+}
+
+static int xc_hvm_build_internal(xc_interface *xch,
+                                 uint32_t domid,
+                                 int memsize,
+                                 int target,
+                                 char *image,
+                                 unsigned long image_size)
+{
+    if ( (image == NULL) || (image_size == 0) )
+    {
+        ERROR("Image required");
+        return -1;
+    }
+
+    return setup_guest(xch, domid, memsize, target, image, image_size);
+}
+
+/* xc_hvm_build:
+ * Create a domain for a virtualized Linux, using files/filenames.
+ */
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_target_mem: 
+ * Create a domain for a pre-ballooned virtualized Linux, using
+ * files/filenames.  If target < memsize, domain is created with
+ * memsize pages marked populate-on-demand, 
+ * calculating pod cache size based on target.
+ * If target == memsize, pages are populated normally.
+ */
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_mem:
+ * Create a domain for a virtualized Linux, using memory buffers.
+ */
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    int           sts;
+    unsigned long img_len;
+    char         *img;
+
+    /* Validate that there is a kernel buffer */
+
+    if ( (image_buffer == NULL) || (image_size == 0) )
+    {
+        ERROR("kernel image buffer not present");
+        return -1;
+    }
+
+    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
+    if ( img == NULL )
+    {
+        ERROR("unable to inflate ram disk buffer");
+        return -1;
+    }
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
+                                img, img_len);
+
+    /* xc_inflate_buffer may return the original buffer pointer (for
+       for already inflated buffers), so exercise some care in freeing */
+
+    if ( (img != NULL) && (img != image_buffer) )
+        free(img);
+
+    return sts;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..054b8e9
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOU-0006vI-G8; Tue, 14 Feb 2012 19:50:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOS-0006sN-EF
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329249020!13309728!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4529 invoked from network); 14 Feb 2012 19:50:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750326"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:19 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZN028922;
	Tue, 14 Feb 2012 11:50:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:31 +0000
Message-ID: <1329249275-18515-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Provide empty implementations of xc_domain_save and xc_domain_restore
when CONFIG_MIGRATE is not set.
Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
x86 specific, introduce xc_hvm_build_arm.c with empty stubs.


Changes in v3:

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;



Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile           |   12 +-
 tools/libxc/xc_dom_arm.c       |   49 ++++
 tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
 tools/libxc/xc_hvm_build_arm.c |   48 ++++
 tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c     |   41 ++++
 6 files changed, 658 insertions(+), 514 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build.c
 create mode 100644 tools/libxc/xc_hvm_build_arm.c
 create mode 100644 tools/libxc/xc_hvm_build_x86.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..02d39a3 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
deleted file mode 100644
index 1fa5658..0000000
--- a/tools/libxc/xc_hvm_build.c
+++ /dev/null
@@ -1,511 +0,0 @@
-/******************************************************************************
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <stddef.h>
-#include <inttypes.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <zlib.h>
-
-#include "xg_private.h"
-#include "xc_private.h"
-
-#include <xen/foreign/x86_32.h>
-#include <xen/foreign/x86_64.h>
-#include <xen/hvm/hvm_info_table.h>
-#include <xen/hvm/params.h>
-#include <xen/hvm/e820.h>
-
-#include <xen/libelf/libelf.h>
-
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
-
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
-{
-    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
-        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
-    uint64_t lowmem_end = mem_size, highmem_end = 0;
-    uint8_t sum;
-    int i;
-
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
-    {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
-    }
-
-    memset(hvm_info_page, 0, PAGE_SIZE);
-
-    /* Fill in the header. */
-    strncpy(hvm_info->signature, "HVM INFO", 8);
-    hvm_info->length = sizeof(struct hvm_info_table);
-
-    /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->apic_mode = 1;
-    hvm_info->nr_vcpus = 1;
-    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
-
-    /* Memory parameters. */
-    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
-    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
-    hvm_info->reserved_mem_pgstart = special_pfn(0);
-
-    /* Finish with the checksum. */
-    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
-        sum += ((uint8_t *)hvm_info)[i];
-    hvm_info->checksum = -sum;
-}
-
-static int loadelfimage(
-    xc_interface *xch,
-    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
-{
-    privcmd_mmap_entry_t *entries = NULL;
-    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
-    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
-    size_t pages = pfn_end - pfn_start;
-    int i, rc = -1;
-
-    /* Map address space for initial elf image. */
-    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-    if ( entries == NULL )
-        goto err;
-
-    for ( i = 0; i < pages; i++ )
-        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
-
-    elf->dest = xc_map_foreign_ranges(
-        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
-        entries, pages);
-    if ( elf->dest == NULL )
-        goto err;
-
-    elf->dest += elf->pstart & (PAGE_SIZE - 1);
-
-    /* Load the initial elf image. */
-    rc = elf_load_binary(elf);
-    if ( rc < 0 )
-        PERROR("Failed to load elf binary\n");
-
-    munmap(elf->dest, pages << PAGE_SHIFT);
-    elf->dest = NULL;
-
- err:
-    free(entries);
-
-    return rc;
-}
-
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
-{
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
-        return 0;
-    else
-        return 1;
-}
-
-static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
-                       char *image, unsigned long image_size)
-{
-    xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
-    unsigned long entry_eip, cur_pages, cur_pfn;
-    void *hvm_info_page;
-    uint32_t *ident_pt;
-    struct elf_binary elf;
-    uint64_t v_start, v_end;
-    int rc;
-    xen_capabilities_info_t caps;
-    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
-        stat_1gb_pages = 0;
-    int pod_mode = 0;
-
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
-        pod_mode = 1;
-
-    memset(&elf, 0, sizeof(elf));
-    if ( elf_init(&elf, image, image_size) != 0 )
-        goto error_out;
-
-    xc_elf_set_logfile(xch, &elf, 1);
-
-    elf_parse_binary(&elf);
-    v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
-
-    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
-    {
-        PERROR("Could not get Xen capabilities");
-        goto error_out;
-    }
-
-    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
-            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
-            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
-            "  ENTRY ADDRESS: %016"PRIx64"\n",
-            elf.pstart, elf.pend,
-            v_start, v_end,
-            elf_uval(&elf, elf.ehdr, e_entry));
-
-    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
-    {
-        PERROR("Could not allocate memory.");
-        goto error_out;
-    }
-
-    for ( i = 0; i < nr_pages; i++ )
-        page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
-
-    /*
-     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
-     *
-     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
-     * pages if 1GB allocation fails. 4KB pages will be used eventually if
-     * both fail.
-     * 
-     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
-     * ensure that we can be preempted and hence dom0 remains responsive.
-     */
-    rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
-    cur_pages = 0xc0;
-    stat_normal_pages = 0xc0;
-    while ( (rc == 0) && (nr_pages > cur_pages) )
-    {
-        /* Clip count to maximum 1GB extent. */
-        unsigned long count = nr_pages - cur_pages;
-        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-        if ( count > max_pages )
-            count = max_pages;
-
-        cur_pfn = page_array[cur_pages];
-
-        /* Take care the corner cases of super page tails */
-        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
-            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
-        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-                  (count > SUPERPAGE_1GB_NR_PFNS) )
-            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-        /* Attemp to allocate 1GB super page. Because in each pass we only
-         * allocate at most 1GB, we don't have to clip super page boundaries.
-         */
-        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
-             /* Check if there exists MMIO hole in the 1GB memory range */
-             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
-        {
-            long done;
-            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
-            xen_pfn_t sp_extents[nr_extents];
-
-            for ( i = 0; i < nr_extents; i++ )
-                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
-
-            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
-                                              pod_mode ? XENMEMF_populate_on_demand : 0,
-                                              sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
-        }
-
-        if ( count != 0 )
-        {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
-            if ( count > max_pages )
-                count = max_pages;
-            
-            /* Clip partial superpage extents to superpage boundaries. */
-            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
-                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
-            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                      (count > SUPERPAGE_2MB_NR_PFNS) )
-                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-            /* Attempt to allocate superpage extents. */
-            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
-            {
-                long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
-                xen_pfn_t sp_extents[nr_extents];
-
-                for ( i = 0; i < nr_extents; i++ )
-                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
-
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
-                                                  sp_extents);
-
-                if ( done > 0 )
-                {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
-                    cur_pages += done;
-                    count -= done;
-                }
-            }
-        }
-
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, 0, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
-        }
-    }
-
-    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
-     * adjust the PoD cache size so that domain tot_pages will be
-     * target_pages - 0x20 after this call. */
-    if ( pod_mode )
-        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
-                                      NULL, NULL, NULL);
-
-    if ( rc != 0 )
-    {
-        PERROR("Could not allocate memory for HVM guest.");
-        goto error_out;
-    }
-
-    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
-            "  4KB PAGES: 0x%016lx\n"
-            "  2MB PAGES: 0x%016lx\n"
-            "  1GB PAGES: 0x%016lx\n",
-            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
-    
-    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
-        goto error_out;
-
-    if ( (hvm_info_page = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              HVM_INFO_PFN)) == NULL )
-        goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
-    munmap(hvm_info_page, PAGE_SIZE);
-
-    /* Allocate and clear special pages. */
-    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-    {
-        xen_pfn_t pfn = special_pfn(i);
-        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
-        if ( rc != 0 )
-        {
-            PERROR("Could not allocate %d'th special page.", i);
-            goto error_out;
-        }
-        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
-            goto error_out;
-    }
-
-    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
-                     special_pfn(SPECIALPAGE_XENSTORE));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
-                     special_pfn(SPECIALPAGE_BUFIOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
-                     special_pfn(SPECIALPAGE_IOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
-                     special_pfn(SPECIALPAGE_CONSOLE));
-
-    /*
-     * Identity-map page table is required for running with CR0.PG=0 when
-     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
-     */
-    if ( (ident_pt = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
-        goto error_out;
-    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
-        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
-                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-    munmap(ident_pt, PAGE_SIZE);
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
-                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
-
-    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
-    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
-    if ( entry_eip != 0 )
-    {
-        char *page0 = xc_map_foreign_range(
-            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
-        if ( page0 == NULL )
-            goto error_out;
-        page0[0] = 0xe9;
-        *(uint32_t *)&page0[1] = entry_eip - 5;
-        munmap(page0, PAGE_SIZE);
-    }
-
-    free(page_array);
-    return 0;
-
- error_out:
-    free(page_array);
-    return -1;
-}
-
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
-/* xc_hvm_build:
- * Create a domain for a virtualized Linux, using files/filenames.
- */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_target_mem: 
- * Create a domain for a pre-ballooned virtualized Linux, using
- * files/filenames.  If target < memsize, domain is created with
- * memsize pages marked populate-on-demand, 
- * calculating pod cache size based on target.
- * If target == memsize, pages are populated normally.
- */
-int xc_hvm_build_target_mem(xc_interface *xch,
-                           uint32_t domid,
-                           int memsize,
-                           int target,
-                           const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
new file mode 100644
index 0000000..6cf65a1
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_arm.c
@@ -0,0 +1,48 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
new file mode 100644
index 0000000..1fa5658
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -0,0 +1,511 @@
+/******************************************************************************
+ * xc_hvm_build.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stddef.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <zlib.h>
+
+#include "xg_private.h"
+#include "xc_private.h"
+
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/params.h>
+#include <xen/hvm/e820.h>
+
+#include <xen/libelf/libelf.h>
+
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define SPECIALPAGE_BUFIOREQ 0
+#define SPECIALPAGE_XENSTORE 1
+#define SPECIALPAGE_IOREQ    2
+#define SPECIALPAGE_IDENT_PT 3
+#define SPECIALPAGE_CONSOLE  4
+#define NR_SPECIAL_PAGES     5
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+{
+    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+    uint64_t lowmem_end = mem_size, highmem_end = 0;
+    uint8_t sum;
+    int i;
+
+    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    {
+        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
+        lowmem_end = HVM_BELOW_4G_RAM_END;
+    }
+
+    memset(hvm_info_page, 0, PAGE_SIZE);
+
+    /* Fill in the header. */
+    strncpy(hvm_info->signature, "HVM INFO", 8);
+    hvm_info->length = sizeof(struct hvm_info_table);
+
+    /* Sensible defaults: these can be overridden by the caller. */
+    hvm_info->apic_mode = 1;
+    hvm_info->nr_vcpus = 1;
+    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+    /* Memory parameters. */
+    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
+    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
+    hvm_info->reserved_mem_pgstart = special_pfn(0);
+
+    /* Finish with the checksum. */
+    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+        sum += ((uint8_t *)hvm_info)[i];
+    hvm_info->checksum = -sum;
+}
+
+static int loadelfimage(
+    xc_interface *xch,
+    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
+{
+    privcmd_mmap_entry_t *entries = NULL;
+    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
+    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
+    size_t pages = pfn_end - pfn_start;
+    int i, rc = -1;
+
+    /* Map address space for initial elf image. */
+    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
+    if ( entries == NULL )
+        goto err;
+
+    for ( i = 0; i < pages; i++ )
+        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
+
+    elf->dest = xc_map_foreign_ranges(
+        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
+        entries, pages);
+    if ( elf->dest == NULL )
+        goto err;
+
+    elf->dest += elf->pstart & (PAGE_SIZE - 1);
+
+    /* Load the initial elf image. */
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
+
+    munmap(elf->dest, pages << PAGE_SHIFT);
+    elf->dest = NULL;
+
+ err:
+    free(entries);
+
+    return rc;
+}
+
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize)
+{
+    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
+         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+        return 0;
+    else
+        return 1;
+}
+
+static int setup_guest(xc_interface *xch,
+                       uint32_t dom, int memsize, int target,
+                       char *image, unsigned long image_size)
+{
+    xen_pfn_t *page_array = NULL;
+    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
+    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long entry_eip, cur_pages, cur_pfn;
+    void *hvm_info_page;
+    uint32_t *ident_pt;
+    struct elf_binary elf;
+    uint64_t v_start, v_end;
+    int rc;
+    xen_capabilities_info_t caps;
+    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
+        stat_1gb_pages = 0;
+    int pod_mode = 0;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( memsize < 2 || target < 2 )
+        goto error_out;
+
+    if ( memsize > target )
+        pod_mode = 1;
+
+    memset(&elf, 0, sizeof(elf));
+    if ( elf_init(&elf, image, image_size) != 0 )
+        goto error_out;
+
+    xc_elf_set_logfile(xch, &elf, 1);
+
+    elf_parse_binary(&elf);
+    v_start = 0;
+    v_end = (unsigned long long)memsize << 20;
+
+    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+    {
+        PERROR("Could not get Xen capabilities");
+        goto error_out;
+    }
+
+    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
+            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
+            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
+            "  ENTRY ADDRESS: %016"PRIx64"\n",
+            elf.pstart, elf.pend,
+            v_start, v_end,
+            elf_uval(&elf, elf.ehdr, e_entry));
+
+    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
+    {
+        PERROR("Could not allocate memory.");
+        goto error_out;
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+        page_array[i] = i;
+    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+
+    /*
+     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
+     *
+     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+     * pages if 1GB allocation fails. 4KB pages will be used eventually if
+     * both fail.
+     * 
+     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
+     * ensure that we can be preempted and hence dom0 remains responsive.
+     */
+    rc = xc_domain_populate_physmap_exact(
+        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
+    cur_pages = 0xc0;
+    stat_normal_pages = 0xc0;
+    while ( (rc == 0) && (nr_pages > cur_pages) )
+    {
+        /* Clip count to maximum 1GB extent. */
+        unsigned long count = nr_pages - cur_pages;
+        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+        if ( count > max_pages )
+            count = max_pages;
+
+        cur_pfn = page_array[cur_pages];
+
+        /* Take care the corner cases of super page tails */
+        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
+            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
+        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+                  (count > SUPERPAGE_1GB_NR_PFNS) )
+            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+        /* Attemp to allocate 1GB super page. Because in each pass we only
+         * allocate at most 1GB, we don't have to clip super page boundaries.
+         */
+        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
+             /* Check if there exists MMIO hole in the 1GB memory range */
+             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+        {
+            long done;
+            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
+            xen_pfn_t sp_extents[nr_extents];
+
+            for ( i = 0; i < nr_extents; i++ )
+                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
+
+            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                              pod_mode ? XENMEMF_populate_on_demand : 0,
+                                              sp_extents);
+
+            if ( done > 0 )
+            {
+                stat_1gb_pages += done;
+                done <<= SUPERPAGE_1GB_SHIFT;
+                cur_pages += done;
+                count -= done;
+            }
+        }
+
+        if ( count != 0 )
+        {
+            /* Clip count to maximum 8MB extent. */
+            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            if ( count > max_pages )
+                count = max_pages;
+            
+            /* Clip partial superpage extents to superpage boundaries. */
+            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
+                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
+            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                      (count > SUPERPAGE_2MB_NR_PFNS) )
+                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+            /* Attempt to allocate superpage extents. */
+            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+            {
+                long done;
+                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                xen_pfn_t sp_extents[nr_extents];
+
+                for ( i = 0; i < nr_extents; i++ )
+                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
+                                                  sp_extents);
+
+                if ( done > 0 )
+                {
+                    stat_2mb_pages += done;
+                    done <<= SUPERPAGE_2MB_SHIFT;
+                    cur_pages += done;
+                    count -= done;
+                }
+            }
+        }
+
+        /* Fall back to 4kB extents. */
+        if ( count != 0 )
+        {
+            rc = xc_domain_populate_physmap_exact(
+                xch, dom, count, 0, 0, &page_array[cur_pages]);
+            cur_pages += count;
+            stat_normal_pages += count;
+        }
+    }
+
+    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
+     * adjust the PoD cache size so that domain tot_pages will be
+     * target_pages - 0x20 after this call. */
+    if ( pod_mode )
+        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
+                                      NULL, NULL, NULL);
+
+    if ( rc != 0 )
+    {
+        PERROR("Could not allocate memory for HVM guest.");
+        goto error_out;
+    }
+
+    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+            "  4KB PAGES: 0x%016lx\n"
+            "  2MB PAGES: 0x%016lx\n"
+            "  1GB PAGES: 0x%016lx\n",
+            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+    
+    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
+        goto error_out;
+
+    if ( (hvm_info_page = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              HVM_INFO_PFN)) == NULL )
+        goto error_out;
+    build_hvm_info(hvm_info_page, v_end);
+    munmap(hvm_info_page, PAGE_SIZE);
+
+    /* Allocate and clear special pages. */
+    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+    {
+        xen_pfn_t pfn = special_pfn(i);
+        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Could not allocate %d'th special page.", i);
+            goto error_out;
+        }
+        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+            goto error_out;
+    }
+
+    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
+                     special_pfn(SPECIALPAGE_XENSTORE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
+                     special_pfn(SPECIALPAGE_BUFIOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
+                     special_pfn(SPECIALPAGE_IOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
+                     special_pfn(SPECIALPAGE_CONSOLE));
+
+    /*
+     * Identity-map page table is required for running with CR0.PG=0 when
+     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
+     */
+    if ( (ident_pt = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
+        goto error_out;
+    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
+        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+    munmap(ident_pt, PAGE_SIZE);
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
+                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
+
+    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
+    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
+    if ( entry_eip != 0 )
+    {
+        char *page0 = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+        if ( page0 == NULL )
+            goto error_out;
+        page0[0] = 0xe9;
+        *(uint32_t *)&page0[1] = entry_eip - 5;
+        munmap(page0, PAGE_SIZE);
+    }
+
+    free(page_array);
+    return 0;
+
+ error_out:
+    free(page_array);
+    return -1;
+}
+
+static int xc_hvm_build_internal(xc_interface *xch,
+                                 uint32_t domid,
+                                 int memsize,
+                                 int target,
+                                 char *image,
+                                 unsigned long image_size)
+{
+    if ( (image == NULL) || (image_size == 0) )
+    {
+        ERROR("Image required");
+        return -1;
+    }
+
+    return setup_guest(xch, domid, memsize, target, image, image_size);
+}
+
+/* xc_hvm_build:
+ * Create a domain for a virtualized Linux, using files/filenames.
+ */
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_target_mem: 
+ * Create a domain for a pre-ballooned virtualized Linux, using
+ * files/filenames.  If target < memsize, domain is created with
+ * memsize pages marked populate-on-demand, 
+ * calculating pod cache size based on target.
+ * If target == memsize, pages are populated normally.
+ */
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_mem:
+ * Create a domain for a virtualized Linux, using memory buffers.
+ */
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    int           sts;
+    unsigned long img_len;
+    char         *img;
+
+    /* Validate that there is a kernel buffer */
+
+    if ( (image_buffer == NULL) || (image_size == 0) )
+    {
+        ERROR("kernel image buffer not present");
+        return -1;
+    }
+
+    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
+    if ( img == NULL )
+    {
+        ERROR("unable to inflate ram disk buffer");
+        return -1;
+    }
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
+                                img, img_len);
+
+    /* xc_inflate_buffer may return the original buffer pointer (for
+       for already inflated buffers), so exercise some care in freeing */
+
+    if ( (img != NULL) && (img != image_buffer) )
+        free(img);
+
+    return sts;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..054b8e9
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOO-0006so-Gk; Tue, 14 Feb 2012 19:50:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOM-0006sL-Lo
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:23 +0000
Received: from [85.158.139.83:19441] by server-11.bemta-5.messagelabs.com id
	22/59-14397-DFABA3F4; Tue, 14 Feb 2012 19:50:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329249018!7648176!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5380 invoked from network); 14 Feb 2012 19:50:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750325"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:19 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZR028922;
	Tue, 14 Feb 2012 11:50:17 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:35 +0000
Message-ID: <1329249275-18515-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an arch specific internal domain creation function. At the
moment only x86 provides an implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile       |    6 +-
 tools/libxl/libxl_arch.h   |   22 ++++
 tools/libxl/libxl_create.c |   12 +--
 tools/libxl/libxl_noarch.c |    8 ++
 tools/libxl/libxl_pci.c    |  242 -----------------------------------------
 tools/libxl/libxl_x86.c    |  258 ++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 293 insertions(+), 255 deletions(-)
 create mode 100644 tools/libxl/libxl_arch.h
 create mode 100644 tools/libxl/libxl_noarch.c
 create mode 100644 tools/libxl/libxl_x86.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 41b6ac4..ba5852b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
 endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
-LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
+LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
new file mode 100644
index 0000000..d1bbdf7
--- /dev/null
+++ b/tools/libxl/libxl_arch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_ARCH_H
+#define LIBXL_ARCH_H
+
+/* arch specific internal domain creation function */
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+		uint32_t domid);
+
+#endif
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..ff589a8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -18,6 +18,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 
 #include <xc_dom.h>
 #include <xenguest.h>
@@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
-    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                      "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
-    }
+    libxl__arch_domain_create(gc, d_config, domid);
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
new file mode 100644
index 0000000..7893535
--- /dev/null
+++ b/tools/libxl/libxl_noarch.c
@@ -0,0 +1,8 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+                              uint32_t domid)
+{
+    return 0;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 33425f5..d960f4b 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static const char *e820_names(int type)
-{
-    switch (type) {
-        case E820_RAM: return "RAM";
-        case E820_RESERVED: return "Reserved";
-        case E820_ACPI: return "ACPI";
-        case E820_NVS: return "ACPI NVS";
-        case E820_UNUSABLE: return "Unusable";
-        default: break;
-    }
-    return "Unknown";
-}
-
-static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
-                         uint32_t *nr_entries,
-                         unsigned long map_limitkb,
-                         unsigned long balloon_kb)
-{
-    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
-    uint32_t i, idx = 0, nr;
-    struct e820entry e820[E820MAX];
-
-    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
-        return ERROR_INVAL;
-
-    nr = *nr_entries;
-    if (!nr)
-        return ERROR_INVAL;
-
-    if (nr > E820MAX)
-        return ERROR_NOMEM;
-
-    /* Weed out anything under 1MB */
-    for (i = 0; i < nr; i++) {
-        if (src[i].addr > 0x100000)
-            continue;
-
-        src[i].type = 0;
-        src[i].size = 0;
-        src[i].addr = -1ULL;
-    }
-
-    /* Find the lowest and highest entry in E820, skipping over
-     * undesired entries. */
-    start = -1ULL;
-    last = 0;
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == E820_UNUSABLE) ||
-            (src[i].type == 0))
-            continue;
-
-        start = src[i].addr < start ? src[i].addr : start;
-        last = src[i].addr + src[i].size > last ?
-               src[i].addr + src[i].size > last : last;
-    }
-    if (start > 1024)
-        start_kb = start >> 10;
-
-    /* Add the memory RAM region for the guest */
-    e820[idx].addr = 0;
-    e820[idx].size = (uint64_t)map_limitkb << 10;
-    e820[idx].type = E820_RAM;
-
-    /* .. and trim if neccessary */
-    if (start_kb && map_limitkb > start_kb) {
-        delta_kb = map_limitkb - start_kb;
-        if (delta_kb)
-            e820[idx].size -= (uint64_t)(delta_kb << 10);
-    }
-    /* Note: We don't touch balloon_kb here. Will add it at the end. */
-    ram_end = e820[idx].addr + e820[idx].size;
-    idx ++;
-
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
-               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
-               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
-               ram_end >> 12, delta_kb, start_kb ,start >> 12,
-               (uint64_t)balloon_kb);
-
-
-    /* This whole code below is to guard against if the Intel IGD is passed into
-     * the guest. If we don't pass in IGD, this whole code can be ignored.
-     *
-     * The reason for this code is that Intel boxes fill their E820 with
-     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
-     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
-     * Linux and it would be utilized by the Intel IGD as I/O space while
-     * in reality it was an RAM region.
-     *
-     * What this means is that we have to walk the E820 and for any region
-     * that is RAM and below 4GB and above ram_end, needs to change its type
-     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
-     * the overlap with ram_end. */
-    for (i = 0; i < nr; i++) {
-        uint64_t end = src[i].addr + src[i].size;
-
-        /* We don't care about E820_UNUSABLE, but we need to
-         * change the type to zero b/c the loop after this
-         * sticks E820_UNUSABLE on the guest's E820 but ignores
-         * the ones with type zero. */
-        if ((src[i].type == E820_UNUSABLE) ||
-            /* Any region that is within the "RAM region" can
-             * be safely ditched. */
-            (end < ram_end)) {
-                src[i].type = 0;
-                continue;
-        }
-
-        /* Look only at RAM regions. */
-        if (src[i].type != E820_RAM)
-            continue;
-
-        /* We only care about RAM regions below 4GB. */
-        if (src[i].addr >= (1ULL<<32))
-            continue;
-
-        /* E820_RAM overlaps with our RAM region. Move it */
-        if (src[i].addr < ram_end) {
-            uint64_t delta;
-
-            src[i].type = E820_UNUSABLE;
-            delta = ram_end - src[i].addr;
-            /* The end < ram_end should weed this out */
-            if (src[i].size - delta < 0)
-                src[i].type = 0;
-            else {
-                src[i].size -= delta;
-                src[i].addr = ram_end;
-            }
-            if (src[i].addr + src[i].size != end) {
-                /* We messed up somewhere */
-                src[i].type = 0;
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
-            }
-        }
-        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
-           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
-            "xen/setup: Inhibit resource API from using System RAM E820
-           gaps as PCI mem gaps" for full explanation. */
-        if (end > ram_end)
-            src[i].type = E820_UNUSABLE;
-    }
-
-    /* Check if there is a region between ram_end and start. */
-    if (start > ram_end) {
-        int add_unusable = 1;
-        for (i = 0; i < nr && add_unusable; i++) {
-            if (src[i].type != E820_UNUSABLE)
-                continue;
-            if (ram_end != src[i].addr)
-                continue;
-            if (start != src[i].addr + src[i].size) {
-                /* there is one, adjust it */
-                src[i].size = start - src[i].addr;
-            }
-            add_unusable = 0;
-        }
-        /* .. and if not present, add it in. This is to guard against
-           the Linux guest assuming that the gap between the end of
-           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-           is PCI I/O space. Which it certainly is _not_. */
-        if (add_unusable) {
-            e820[idx].type = E820_UNUSABLE;
-            e820[idx].addr = ram_end;
-            e820[idx].size = start - ram_end;
-            idx++;
-        }
-    }
-    /* Almost done: copy them over, ignoring the undesireable ones */
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == 0))
-            continue;
-
-        e820[idx].type = src[i].type;
-        e820[idx].addr = src[i].addr;
-        e820[idx].size = src[i].size;
-        idx++;
-    }
-    /* At this point we have the mapped RAM + E820 entries from src. */
-    if (balloon_kb) {
-        /* and if we truncated the RAM region, then add it to the end. */
-        e820[idx].type = E820_RAM;
-        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
-                         (uint64_t)(1ULL << 32) : last;
-        /* also add the balloon memory to the end. */
-        e820[idx].size = (uint64_t)(delta_kb << 10) +
-                         (uint64_t)(balloon_kb << 10);
-        idx++;
-
-    }
-    nr = idx;
-
-    for (i = 0; i < nr; i++) {
-      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
-                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
-                 e820_names(e820[i].type));
-    }
-
-    /* Done: copy the sanitized version. */
-    *nr_entries = nr;
-    memcpy(src, e820, nr * sizeof(struct e820entry));
-    return 0;
-}
-
-int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc;
-    uint32_t nr;
-    struct e820entry map[E820MAX];
-    libxl_domain_build_info *b_info;
-
-    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        return ERROR_INVAL;
-
-    b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
-        return ERROR_INVAL;
-
-    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
-    if (rc < 0) {
-        errno = rc;
-        return ERROR_FAIL;
-    }
-    nr = rc;
-    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
-                       (b_info->max_memkb - b_info->target_memkb) +
-                       b_info->u.pv.slack_memkb);
-    if (rc)
-        return ERROR_FAIL;
-
-    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
-
-    if (rc < 0) {
-        errno  = rc;
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
new file mode 100644
index 0000000..dd8eef9
--- /dev/null
+++ b/tools/libxl/libxl_x86.c
@@ -0,0 +1,258 @@
+#include "libxl_arch.h"
+#include "libxl_internal.h"
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+            continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+        uint64_t end = src[i].addr + src[i].size;
+
+        /* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+            /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+        if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+        /* E820_RAM overlaps with our RAM region. Move it */
+        if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
+        /* .. and if not present, add it in. This is to guard against
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == 0))
+            continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+        uint32_t domid)
+{
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
+        d_config->b_info.u.pv.e820_host) {
+        int rc;
+        rc = libxl__e820_alloc(gc, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
+}
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOO-0006so-Gk; Tue, 14 Feb 2012 19:50:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOM-0006sL-Lo
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:23 +0000
Received: from [85.158.139.83:19441] by server-11.bemta-5.messagelabs.com id
	22/59-14397-DFABA3F4; Tue, 14 Feb 2012 19:50:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329249018!7648176!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5380 invoked from network); 14 Feb 2012 19:50:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750325"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:19 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZR028922;
	Tue, 14 Feb 2012 11:50:17 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:35 +0000
Message-ID: <1329249275-18515-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an arch specific internal domain creation function. At the
moment only x86 provides an implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile       |    6 +-
 tools/libxl/libxl_arch.h   |   22 ++++
 tools/libxl/libxl_create.c |   12 +--
 tools/libxl/libxl_noarch.c |    8 ++
 tools/libxl/libxl_pci.c    |  242 -----------------------------------------
 tools/libxl/libxl_x86.c    |  258 ++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 293 insertions(+), 255 deletions(-)
 create mode 100644 tools/libxl/libxl_arch.h
 create mode 100644 tools/libxl/libxl_noarch.c
 create mode 100644 tools/libxl/libxl_x86.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 41b6ac4..ba5852b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
 endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
-LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
+LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
new file mode 100644
index 0000000..d1bbdf7
--- /dev/null
+++ b/tools/libxl/libxl_arch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_ARCH_H
+#define LIBXL_ARCH_H
+
+/* arch specific internal domain creation function */
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+		uint32_t domid);
+
+#endif
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..ff589a8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -18,6 +18,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 
 #include <xc_dom.h>
 #include <xenguest.h>
@@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
-    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                      "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
-    }
+    libxl__arch_domain_create(gc, d_config, domid);
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
new file mode 100644
index 0000000..7893535
--- /dev/null
+++ b/tools/libxl/libxl_noarch.c
@@ -0,0 +1,8 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+                              uint32_t domid)
+{
+    return 0;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 33425f5..d960f4b 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static const char *e820_names(int type)
-{
-    switch (type) {
-        case E820_RAM: return "RAM";
-        case E820_RESERVED: return "Reserved";
-        case E820_ACPI: return "ACPI";
-        case E820_NVS: return "ACPI NVS";
-        case E820_UNUSABLE: return "Unusable";
-        default: break;
-    }
-    return "Unknown";
-}
-
-static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
-                         uint32_t *nr_entries,
-                         unsigned long map_limitkb,
-                         unsigned long balloon_kb)
-{
-    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
-    uint32_t i, idx = 0, nr;
-    struct e820entry e820[E820MAX];
-
-    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
-        return ERROR_INVAL;
-
-    nr = *nr_entries;
-    if (!nr)
-        return ERROR_INVAL;
-
-    if (nr > E820MAX)
-        return ERROR_NOMEM;
-
-    /* Weed out anything under 1MB */
-    for (i = 0; i < nr; i++) {
-        if (src[i].addr > 0x100000)
-            continue;
-
-        src[i].type = 0;
-        src[i].size = 0;
-        src[i].addr = -1ULL;
-    }
-
-    /* Find the lowest and highest entry in E820, skipping over
-     * undesired entries. */
-    start = -1ULL;
-    last = 0;
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == E820_UNUSABLE) ||
-            (src[i].type == 0))
-            continue;
-
-        start = src[i].addr < start ? src[i].addr : start;
-        last = src[i].addr + src[i].size > last ?
-               src[i].addr + src[i].size > last : last;
-    }
-    if (start > 1024)
-        start_kb = start >> 10;
-
-    /* Add the memory RAM region for the guest */
-    e820[idx].addr = 0;
-    e820[idx].size = (uint64_t)map_limitkb << 10;
-    e820[idx].type = E820_RAM;
-
-    /* .. and trim if neccessary */
-    if (start_kb && map_limitkb > start_kb) {
-        delta_kb = map_limitkb - start_kb;
-        if (delta_kb)
-            e820[idx].size -= (uint64_t)(delta_kb << 10);
-    }
-    /* Note: We don't touch balloon_kb here. Will add it at the end. */
-    ram_end = e820[idx].addr + e820[idx].size;
-    idx ++;
-
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
-               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
-               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
-               ram_end >> 12, delta_kb, start_kb ,start >> 12,
-               (uint64_t)balloon_kb);
-
-
-    /* This whole code below is to guard against if the Intel IGD is passed into
-     * the guest. If we don't pass in IGD, this whole code can be ignored.
-     *
-     * The reason for this code is that Intel boxes fill their E820 with
-     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
-     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
-     * Linux and it would be utilized by the Intel IGD as I/O space while
-     * in reality it was an RAM region.
-     *
-     * What this means is that we have to walk the E820 and for any region
-     * that is RAM and below 4GB and above ram_end, needs to change its type
-     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
-     * the overlap with ram_end. */
-    for (i = 0; i < nr; i++) {
-        uint64_t end = src[i].addr + src[i].size;
-
-        /* We don't care about E820_UNUSABLE, but we need to
-         * change the type to zero b/c the loop after this
-         * sticks E820_UNUSABLE on the guest's E820 but ignores
-         * the ones with type zero. */
-        if ((src[i].type == E820_UNUSABLE) ||
-            /* Any region that is within the "RAM region" can
-             * be safely ditched. */
-            (end < ram_end)) {
-                src[i].type = 0;
-                continue;
-        }
-
-        /* Look only at RAM regions. */
-        if (src[i].type != E820_RAM)
-            continue;
-
-        /* We only care about RAM regions below 4GB. */
-        if (src[i].addr >= (1ULL<<32))
-            continue;
-
-        /* E820_RAM overlaps with our RAM region. Move it */
-        if (src[i].addr < ram_end) {
-            uint64_t delta;
-
-            src[i].type = E820_UNUSABLE;
-            delta = ram_end - src[i].addr;
-            /* The end < ram_end should weed this out */
-            if (src[i].size - delta < 0)
-                src[i].type = 0;
-            else {
-                src[i].size -= delta;
-                src[i].addr = ram_end;
-            }
-            if (src[i].addr + src[i].size != end) {
-                /* We messed up somewhere */
-                src[i].type = 0;
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
-            }
-        }
-        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
-           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
-            "xen/setup: Inhibit resource API from using System RAM E820
-           gaps as PCI mem gaps" for full explanation. */
-        if (end > ram_end)
-            src[i].type = E820_UNUSABLE;
-    }
-
-    /* Check if there is a region between ram_end and start. */
-    if (start > ram_end) {
-        int add_unusable = 1;
-        for (i = 0; i < nr && add_unusable; i++) {
-            if (src[i].type != E820_UNUSABLE)
-                continue;
-            if (ram_end != src[i].addr)
-                continue;
-            if (start != src[i].addr + src[i].size) {
-                /* there is one, adjust it */
-                src[i].size = start - src[i].addr;
-            }
-            add_unusable = 0;
-        }
-        /* .. and if not present, add it in. This is to guard against
-           the Linux guest assuming that the gap between the end of
-           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-           is PCI I/O space. Which it certainly is _not_. */
-        if (add_unusable) {
-            e820[idx].type = E820_UNUSABLE;
-            e820[idx].addr = ram_end;
-            e820[idx].size = start - ram_end;
-            idx++;
-        }
-    }
-    /* Almost done: copy them over, ignoring the undesireable ones */
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == 0))
-            continue;
-
-        e820[idx].type = src[i].type;
-        e820[idx].addr = src[i].addr;
-        e820[idx].size = src[i].size;
-        idx++;
-    }
-    /* At this point we have the mapped RAM + E820 entries from src. */
-    if (balloon_kb) {
-        /* and if we truncated the RAM region, then add it to the end. */
-        e820[idx].type = E820_RAM;
-        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
-                         (uint64_t)(1ULL << 32) : last;
-        /* also add the balloon memory to the end. */
-        e820[idx].size = (uint64_t)(delta_kb << 10) +
-                         (uint64_t)(balloon_kb << 10);
-        idx++;
-
-    }
-    nr = idx;
-
-    for (i = 0; i < nr; i++) {
-      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
-                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
-                 e820_names(e820[i].type));
-    }
-
-    /* Done: copy the sanitized version. */
-    *nr_entries = nr;
-    memcpy(src, e820, nr * sizeof(struct e820entry));
-    return 0;
-}
-
-int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc;
-    uint32_t nr;
-    struct e820entry map[E820MAX];
-    libxl_domain_build_info *b_info;
-
-    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        return ERROR_INVAL;
-
-    b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
-        return ERROR_INVAL;
-
-    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
-    if (rc < 0) {
-        errno = rc;
-        return ERROR_FAIL;
-    }
-    nr = rc;
-    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
-                       (b_info->max_memkb - b_info->target_memkb) +
-                       b_info->u.pv.slack_memkb);
-    if (rc)
-        return ERROR_FAIL;
-
-    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
-
-    if (rc < 0) {
-        errno  = rc;
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
new file mode 100644
index 0000000..dd8eef9
--- /dev/null
+++ b/tools/libxl/libxl_x86.c
@@ -0,0 +1,258 @@
+#include "libxl_arch.h"
+#include "libxl_internal.h"
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+            continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+        uint64_t end = src[i].addr + src[i].size;
+
+        /* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+            /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+        if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+        /* E820_RAM overlaps with our RAM region. Move it */
+        if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
+        /* .. and if not present, add it in. This is to guard against
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == 0))
+            continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+        uint32_t domid)
+{
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
+        d_config->b_info.u.pv.e820_host) {
+        int rc;
+        rc = libxl__e820_alloc(gc, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
+}
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOR-0006u3-0Q; Tue, 14 Feb 2012 19:50:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOP-0006s6-GI
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329249017!11519946!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12531 invoked from network); 14 Feb 2012 19:50:19 -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;
	14 Feb 2012 19:50:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="21945431"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZQ028922;
	Tue, 14 Feb 2012 11:50:16 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:34 +0000
Message-ID: <1329249275-18515-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 6/7] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_cpuid.c   |   62 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_json.c    |   60 -----------------------------------------
 tools/libxl/libxl_nocpuid.c |    8 +++++-
 4 files changed, 70 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index dcdb9d02..f709ad8 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -333,6 +333,68 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
                      (const char**)(cpuid[i].policy), cpuid_res);
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    libxl_cpuid_policy_list cpuid = *pcpuid;
+    yajl_gen_status s;
+    const char *input_names[2] = { "leaf", "subleaf" };
+    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
+    int i, j;
+    uint32_t unused;
+
+    /*
+     * Aiming for:
+     * [
+     *     { 'leaf':    'val-eax',
+     *       'subleaf': 'val-ecx',
+     *       'eax':     'filter',
+     *       'ebx':     'filter',
+     *       'ecx':     'filter',
+     *       'edx':     'filter' },
+     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
+     *     ... etc ...
+     * ]
+     */
+
+    libxl_cpuid_unused(ctx, 
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    if (cpuid == NULL) goto empty;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        s = yajl_gen_map_open(hand);
+        if (s != yajl_gen_status_ok) goto out;
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_integer(hand, cpuid[i].input[j]);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_string(hand,
+                               (const unsigned char *)cpuid[i].policy[j], 32);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+        s = yajl_gen_map_close(hand);
+        if (s != yajl_gen_status_ok) goto out;
+    }
+
+empty:
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 5418683..41a9523 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,66 +140,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                libxl_cpuid_policy_list *pcpuid)
-{
-    libxl_cpuid_policy_list cpuid = *pcpuid;
-    yajl_gen_status s;
-    const char *input_names[2] = { "leaf", "subleaf" };
-    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
-    int i, j;
-
-    /*
-     * Aiming for:
-     * [
-     *     { 'leaf':    'val-eax',
-     *       'subleaf': 'val-ecx',
-     *       'eax':     'filter',
-     *       'ebx':     'filter',
-     *       'ecx':     'filter',
-     *       'edx':     'filter' },
-     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
-     *     ... etc ...
-     * ]
-     */
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    if (cpuid == NULL) goto empty;
-
-    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-        s = yajl_gen_map_open(hand);
-        if (s != yajl_gen_status_ok) goto out;
-
-        for (j = 0; j < 2; j++) {
-            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
-                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_integer(hand, cpuid[i].input[j]);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-
-        for (j = 0; j < 4; j++) {
-            if (cpuid[i].policy[j] != NULL) {
-                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_string(hand,
-                               (const unsigned char *)cpuid[i].policy[j], 32);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-        s = yajl_gen_map_close(hand);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-
-empty:
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..5f7cb6a 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
@@ -38,6 +38,12 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
 {
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOON-0006sO-3J; Tue, 14 Feb 2012 19:50:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOL-0006sA-DP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:21 +0000
Received: from [85.158.139.83:19373] by server-9.bemta-5.messagelabs.com id
	33/F9-30171-CFABA3F4; Tue, 14 Feb 2012 19:50:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329249018!7648176!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5340 invoked from network); 14 Feb 2012 19:50:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750322"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZM028922;
	Tue, 14 Feb 2012 11:50:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:30 +0000
Message-ID: <1329249275-18515-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 2/7] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..29c13a7 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOR-0006u3-0Q; Tue, 14 Feb 2012 19:50:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOP-0006s6-GI
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329249017!11519946!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12531 invoked from network); 14 Feb 2012 19:50:19 -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;
	14 Feb 2012 19:50:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="21945431"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZQ028922;
	Tue, 14 Feb 2012 11:50:16 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:34 +0000
Message-ID: <1329249275-18515-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 6/7] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_cpuid.c   |   62 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_json.c    |   60 -----------------------------------------
 tools/libxl/libxl_nocpuid.c |    8 +++++-
 4 files changed, 70 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index dcdb9d02..f709ad8 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -333,6 +333,68 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
                      (const char**)(cpuid[i].policy), cpuid_res);
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    libxl_cpuid_policy_list cpuid = *pcpuid;
+    yajl_gen_status s;
+    const char *input_names[2] = { "leaf", "subleaf" };
+    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
+    int i, j;
+    uint32_t unused;
+
+    /*
+     * Aiming for:
+     * [
+     *     { 'leaf':    'val-eax',
+     *       'subleaf': 'val-ecx',
+     *       'eax':     'filter',
+     *       'ebx':     'filter',
+     *       'ecx':     'filter',
+     *       'edx':     'filter' },
+     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
+     *     ... etc ...
+     * ]
+     */
+
+    libxl_cpuid_unused(ctx, 
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    if (cpuid == NULL) goto empty;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        s = yajl_gen_map_open(hand);
+        if (s != yajl_gen_status_ok) goto out;
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_integer(hand, cpuid[i].input[j]);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_string(hand,
+                               (const unsigned char *)cpuid[i].policy[j], 32);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+        s = yajl_gen_map_close(hand);
+        if (s != yajl_gen_status_ok) goto out;
+    }
+
+empty:
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 5418683..41a9523 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,66 +140,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                libxl_cpuid_policy_list *pcpuid)
-{
-    libxl_cpuid_policy_list cpuid = *pcpuid;
-    yajl_gen_status s;
-    const char *input_names[2] = { "leaf", "subleaf" };
-    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
-    int i, j;
-
-    /*
-     * Aiming for:
-     * [
-     *     { 'leaf':    'val-eax',
-     *       'subleaf': 'val-ecx',
-     *       'eax':     'filter',
-     *       'ebx':     'filter',
-     *       'ecx':     'filter',
-     *       'edx':     'filter' },
-     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
-     *     ... etc ...
-     * ]
-     */
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    if (cpuid == NULL) goto empty;
-
-    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-        s = yajl_gen_map_open(hand);
-        if (s != yajl_gen_status_ok) goto out;
-
-        for (j = 0; j < 2; j++) {
-            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
-                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_integer(hand, cpuid[i].input[j]);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-
-        for (j = 0; j < 4; j++) {
-            if (cpuid[i].policy[j] != NULL) {
-                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_string(hand,
-                               (const unsigned char *)cpuid[i].policy[j], 32);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-        s = yajl_gen_map_close(hand);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-
-empty:
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..5f7cb6a 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
@@ -38,6 +38,12 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
 {
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOON-0006sO-3J; Tue, 14 Feb 2012 19:50:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOL-0006sA-DP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:21 +0000
Received: from [85.158.139.83:19373] by server-9.bemta-5.messagelabs.com id
	33/F9-30171-CFABA3F4; Tue, 14 Feb 2012 19:50:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329249018!7648176!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5340 invoked from network); 14 Feb 2012 19:50:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750322"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZM028922;
	Tue, 14 Feb 2012 11:50:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:30 +0000
Message-ID: <1329249275-18515-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 2/7] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..29c13a7 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOO-0006sx-To; Tue, 14 Feb 2012 19:50:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOON-0006sM-An
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:23 +0000
Received: from [85.158.139.83:19483] by server-4.bemta-5.messagelabs.com id
	56/A1-10788-EFABA3F4; Tue, 14 Feb 2012 19:50:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329249018!7648176!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5457 invoked from network); 14 Feb 2012 19:50:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750330"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:20 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZO028922;
	Tue, 14 Feb 2012 11:50:14 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:32 +0000
Message-ID: <1329249275-18515-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 4/7] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOP-0006tR-IZ; Tue, 14 Feb 2012 19:50:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOO-0006s1-U6
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329249017!11519946!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12488 invoked from network); 14 Feb 2012 19:50:18 -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;
	14 Feb 2012 19:50:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="21945430"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZL028922;
	Tue, 14 Feb 2012 11:50:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:29 +0000
Message-ID: <1329249275-18515-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 1/7] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOO-0006sx-To; Tue, 14 Feb 2012 19:50:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOON-0006sM-An
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:23 +0000
Received: from [85.158.139.83:19483] by server-4.bemta-5.messagelabs.com id
	56/A1-10788-EFABA3F4; Tue, 14 Feb 2012 19:50:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329249018!7648176!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzMTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5457 invoked from network); 14 Feb 2012 19:50:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 19:50:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="181750330"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:20 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZO028922;
	Tue, 14 Feb 2012 11:50:14 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:32 +0000
Message-ID: <1329249275-18515-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 4/7] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOP-0006tR-IZ; Tue, 14 Feb 2012 19:50:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOO-0006s1-U6
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329249017!11519946!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12488 invoked from network); 14 Feb 2012 19:50:18 -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;
	14 Feb 2012 19:50:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="21945430"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZL028922;
	Tue, 14 Feb 2012 11:50:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:29 +0000
Message-ID: <1329249275-18515-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 1/7] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOV-0006vt-5j; Tue, 14 Feb 2012 19:50:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOT-0006sn-RI
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329249022!9152280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29375 invoked from network); 14 Feb 2012 19:50:23 -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 Feb 2012 19:50:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="21945443"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZP028922;
	Tue, 14 Feb 2012 11:50:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:33 +0000
Message-ID: <1329249275-18515-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 5/7] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 19:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 19:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOOV-0006vt-5j; Tue, 14 Feb 2012 19:50:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOOT-0006sn-RI
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 19:50:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329249022!9152280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTk2OTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29375 invoked from network); 14 Feb 2012 19:50:23 -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 Feb 2012 19:50:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325480400"; d="scan'208";a="21945443"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 14:50:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 14:50:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1EJo9ZP028922;
	Tue, 14 Feb 2012 11:50:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 14 Feb 2012 19:54:33 +0000
Message-ID: <1329249275-18515-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v3 5/7] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 20:05:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 20: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.xensource.com>)
	id 1RxOd9-0008SQ-QB; Tue, 14 Feb 2012 20:05:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxOd8-0008SL-Do
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:05:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329249932!13314506!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13113 invoked from network); 14 Feb 2012 20:05:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 20:05:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxOcy-0003Vg-SL; Tue, 14 Feb 2012 20:05:28 +0000
Date: Tue, 14 Feb 2012 20:05:28 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214200528.GA13265@ocelot.phlegethon.org>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:47 -0800 on 14 Feb (1329209245), Andres Lagar-Cavilla wrote:
> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Why? Because it's really really hard to guarantee we'll go to sleep in
> >> an
> >> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
> >> all
> >> ways of bumping the preemption count.
> >
> > If the guests pagetable is paged out this code path will trigger, then
> > one of the hypercalls returns an error and the guest runs into a BUG().
> > I think it was decrease_reservation, or similar.
> 
> Unlikely to be something specific about decrease_reservation. If the guest
> page table is paged out, then copy_from_user for any hypercall, or,
> "virtual address to gfn" for any emulation will run into this.
> 
> Now, even an innocent-looking rcu lock anywhere in this code path will
> crash the host if we go into a wait queue. Hence my concern.

OK, so the current code breaks the guest and you're worried about it
crashing the host instead.   That seems fair.

Maybe we can arrange that instead of bugging out if the cpu is
in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
seems no worse than the current failure modes.

> > What other way exist to make paging 100% transparent to the guest?
> 
> Don't page out page table pages? I know you were not expecting that...

Sadly, it's not possible to reliably detect which pages are pagetables
(or the shadow pagetable code would be more straightforward!).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 20:05:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 20: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.xensource.com>)
	id 1RxOd9-0008SQ-QB; Tue, 14 Feb 2012 20:05:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxOd8-0008SL-Do
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:05:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329249932!13314506!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13113 invoked from network); 14 Feb 2012 20:05:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 20:05:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxOcy-0003Vg-SL; Tue, 14 Feb 2012 20:05:28 +0000
Date: Tue, 14 Feb 2012 20:05:28 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214200528.GA13265@ocelot.phlegethon.org>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:47 -0800 on 14 Feb (1329209245), Andres Lagar-Cavilla wrote:
> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Why? Because it's really really hard to guarantee we'll go to sleep in
> >> an
> >> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
> >> all
> >> ways of bumping the preemption count.
> >
> > If the guests pagetable is paged out this code path will trigger, then
> > one of the hypercalls returns an error and the guest runs into a BUG().
> > I think it was decrease_reservation, or similar.
> 
> Unlikely to be something specific about decrease_reservation. If the guest
> page table is paged out, then copy_from_user for any hypercall, or,
> "virtual address to gfn" for any emulation will run into this.
> 
> Now, even an innocent-looking rcu lock anywhere in this code path will
> crash the host if we go into a wait queue. Hence my concern.

OK, so the current code breaks the guest and you're worried about it
crashing the host instead.   That seems fair.

Maybe we can arrange that instead of bugging out if the cpu is
in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
seems no worse than the current failure modes.

> > What other way exist to make paging 100% transparent to the guest?
> 
> Don't page out page table pages? I know you were not expecting that...

Sadly, it's not possible to reliably detect which pages are pagetables
(or the shadow pagetable code would be more straightforward!).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 20:11:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 20:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOiF-00009F-IA; Tue, 14 Feb 2012 20:10:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOiE-000093-8r
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:10:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329250248!4021716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27722 invoked from network); 14 Feb 2012 20:10:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 20:10:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 20:10:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 20:10:47 +0000
Date: Tue, 14 Feb 2012 20:15:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1202142014060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please do NOT apply this series: I pushed the wrong branch and as I
consequence it contains few mistakes. I'll send an update tomorrow.

On Tue, 14 Feb 2012, Stefano Stabellini wrote:
> Hi all,
> this patch series allows tools/ to compile on ARM, mostly providing an
> empty implementation for all the arch specific functions that are needed.
> 
> 
> Changes in v3:
> 
> - move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;
> 
> - rename xc_hvm_build.c to xc_hvm_build_x86.c;
> 
> - remove xc_nohvm, introduce xc_hvm_build_arm.c instead;
> 
> - remove "libxl: do not allocate e820 for non x86 guests.";
> 
> - introduce libxl__arch_domain_create.
> 
> 
> 
> Changes in v2:
> 
> - rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;
> 
> - dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
> xen-unstable;
> 
> - define xen_callback_t as uint64_t;
> 
> - define guest_word_t as uint64_t.
> 
> 
> 
> Ian Campbell (1):
>       arm: add stub hvm/save.h
> 
> Stefano Stabellini (6):
>       arm: compile libxc
>       arm: compile libxenguest
>       arm: compile memshr
>       arm: compile xentrace
>       arm: compile libxl
>       libxl: Introduce libxl__arch_domain_create
> 
>  tools/libxc/Makefile                   |   13 +-
>  tools/libxc/xc_core.h                  |    2 +
>  tools/libxc/xc_core_arm.c              |  106 +++++++
>  tools/libxc/xc_core_arm.h              |   60 ++++
>  tools/libxc/xc_dom_arm.c               |   49 +++
>  tools/libxc/xc_hvm_build.c             |  511 --------------------------------
>  tools/libxc/xc_hvm_build_arm.c         |   48 +++
>  tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
>  tools/libxc/xc_nomigrate.c             |   41 +++
>  tools/libxc/xenctrl.h                  |    4 +
>  tools/libxl/Makefile                   |    5 +-
>  tools/libxl/libxl_arch.h               |   22 ++
>  tools/libxl/libxl_cpuid.c              |   62 ++++
>  tools/libxl/libxl_create.c             |   12 +-
>  tools/libxl/libxl_json.c               |   60 ----
>  tools/libxl/libxl_noarch.c             |    8 +
>  tools/libxl/libxl_nocpuid.c            |    8 +-
>  tools/libxl/libxl_pci.c                |  242 ---------------
>  tools/libxl/libxl_x86.c                |  258 ++++++++++++++++
>  tools/memshr/bidir-hash.c              |   31 ++
>  tools/xentrace/xenctx.c                |   12 +
>  xen/include/public/arch-arm/hvm/save.h |   39 +++
>  xen/include/public/hvm/save.h          |    2 +
>  23 files changed, 1277 insertions(+), 829 deletions(-)
> 
> 
> Cheers,
> 
> Stefano
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 20:11:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 20:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxOiF-00009F-IA; Tue, 14 Feb 2012 20:10:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxOiE-000093-8r
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:10:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329250248!4021716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27722 invoked from network); 14 Feb 2012 20:10:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 20:10:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="10694679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 20:10:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 20:10:47 +0000
Date: Tue, 14 Feb 2012 20:15:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1202142014060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202141917250.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please do NOT apply this series: I pushed the wrong branch and as I
consequence it contains few mistakes. I'll send an update tomorrow.

On Tue, 14 Feb 2012, Stefano Stabellini wrote:
> Hi all,
> this patch series allows tools/ to compile on ARM, mostly providing an
> empty implementation for all the arch specific functions that are needed.
> 
> 
> Changes in v3:
> 
> - move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;
> 
> - rename xc_hvm_build.c to xc_hvm_build_x86.c;
> 
> - remove xc_nohvm, introduce xc_hvm_build_arm.c instead;
> 
> - remove "libxl: do not allocate e820 for non x86 guests.";
> 
> - introduce libxl__arch_domain_create.
> 
> 
> 
> Changes in v2:
> 
> - rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;
> 
> - dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
> xen-unstable;
> 
> - define xen_callback_t as uint64_t;
> 
> - define guest_word_t as uint64_t.
> 
> 
> 
> Ian Campbell (1):
>       arm: add stub hvm/save.h
> 
> Stefano Stabellini (6):
>       arm: compile libxc
>       arm: compile libxenguest
>       arm: compile memshr
>       arm: compile xentrace
>       arm: compile libxl
>       libxl: Introduce libxl__arch_domain_create
> 
>  tools/libxc/Makefile                   |   13 +-
>  tools/libxc/xc_core.h                  |    2 +
>  tools/libxc/xc_core_arm.c              |  106 +++++++
>  tools/libxc/xc_core_arm.h              |   60 ++++
>  tools/libxc/xc_dom_arm.c               |   49 +++
>  tools/libxc/xc_hvm_build.c             |  511 --------------------------------
>  tools/libxc/xc_hvm_build_arm.c         |   48 +++
>  tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
>  tools/libxc/xc_nomigrate.c             |   41 +++
>  tools/libxc/xenctrl.h                  |    4 +
>  tools/libxl/Makefile                   |    5 +-
>  tools/libxl/libxl_arch.h               |   22 ++
>  tools/libxl/libxl_cpuid.c              |   62 ++++
>  tools/libxl/libxl_create.c             |   12 +-
>  tools/libxl/libxl_json.c               |   60 ----
>  tools/libxl/libxl_noarch.c             |    8 +
>  tools/libxl/libxl_nocpuid.c            |    8 +-
>  tools/libxl/libxl_pci.c                |  242 ---------------
>  tools/libxl/libxl_x86.c                |  258 ++++++++++++++++
>  tools/memshr/bidir-hash.c              |   31 ++
>  tools/xentrace/xenctx.c                |   12 +
>  xen/include/public/arch-arm/hvm/save.h |   39 +++
>  xen/include/public/hvm/save.h          |    2 +
>  23 files changed, 1277 insertions(+), 829 deletions(-)
> 
> 
> Cheers,
> 
> Stefano
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 20:24:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 20: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.xensource.com>)
	id 1RxOuq-0000O0-SR; Tue, 14 Feb 2012 20:23:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <k@itoc.dk>)
	id 1RxOup-0000Nv-4A
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:23:55 +0000
X-Env-Sender: k@itoc.dk
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329251027!14320127!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17572 invoked from network); 14 Feb 2012 20:23:48 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 20:23:48 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <k@itoc.dk>)
	id 1RxOug-0002jU-7Y
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:23:46 -0800
Date: Tue, 14 Feb 2012 12:23:46 -0800 (PST)
From: Kristoffer Harthing Egefelt <k@itoc.dk>
To: xen-devel@lists.xensource.com
Message-ID: <1329251026227-5483778.post@n5.nabble.com>
In-Reply-To: <alpine.LFD.2.00.1010151832560.16482@vega1.dur.ac.uk>
References: <alpine.LFD.2.00.1010072238110.13579@vega1.dur.ac.uk>
	<4CB4C162.1000705@goop.org>
	<alpine.LFD.2.00.1010122142270.544@vega4.dur.ac.uk>
	<alpine.DEB.2.00.1010141456070.2423@kaball-desktop>
	<alpine.LFD.2.00.1010151638090.18286@vega4.dur.ac.uk>
	<alpine.DEB.2.00.1010151734530.2423@kaball-desktop>
	<alpine.LFD.2.00.1010151832560.16482@vega1.dur.ac.uk>
MIME-Version: 1.0
Subject: Re: [Xen-devel] ext4 support on pvgrub
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After tuning the patch a little its working in our test setup with xen-4.1.2
(
https://raw.github.com/Kristoffer/Xen-4.1.2/master/stubdom/grub-upstream/stage2/fsys_ext2fs.c
link )


--
View this message in context: http://xen.1045712.n5.nabble.com/ext4-support-on-pvgrub-tp3203774p5483778.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 20:24:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 20: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.xensource.com>)
	id 1RxOuq-0000O0-SR; Tue, 14 Feb 2012 20:23:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <k@itoc.dk>)
	id 1RxOup-0000Nv-4A
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:23:55 +0000
X-Env-Sender: k@itoc.dk
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329251027!14320127!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17572 invoked from network); 14 Feb 2012 20:23:48 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2012 20:23:48 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72) (envelope-from <k@itoc.dk>)
	id 1RxOug-0002jU-7Y
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:23:46 -0800
Date: Tue, 14 Feb 2012 12:23:46 -0800 (PST)
From: Kristoffer Harthing Egefelt <k@itoc.dk>
To: xen-devel@lists.xensource.com
Message-ID: <1329251026227-5483778.post@n5.nabble.com>
In-Reply-To: <alpine.LFD.2.00.1010151832560.16482@vega1.dur.ac.uk>
References: <alpine.LFD.2.00.1010072238110.13579@vega1.dur.ac.uk>
	<4CB4C162.1000705@goop.org>
	<alpine.LFD.2.00.1010122142270.544@vega4.dur.ac.uk>
	<alpine.DEB.2.00.1010141456070.2423@kaball-desktop>
	<alpine.LFD.2.00.1010151638090.18286@vega4.dur.ac.uk>
	<alpine.DEB.2.00.1010151734530.2423@kaball-desktop>
	<alpine.LFD.2.00.1010151832560.16482@vega1.dur.ac.uk>
MIME-Version: 1.0
Subject: Re: [Xen-devel] ext4 support on pvgrub
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After tuning the patch a little its working in our test setup with xen-4.1.2
(
https://raw.github.com/Kristoffer/Xen-4.1.2/master/stubdom/grub-upstream/stage2/fsys_ext2fs.c
link )


--
View this message in context: http://xen.1045712.n5.nabble.com/ext4-support-on-pvgrub-tp3203774p5483778.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:00:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxPTf-0001KL-8y; Tue, 14 Feb 2012 20:59:55 +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 1RxPTe-0001KG-Ei
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:59:54 +0000
Received: from [85.158.139.83:43898] by server-2.bemta-5.messagelabs.com id
	3B/CD-20263-94BCA3F4; Tue, 14 Feb 2012 20:59:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329253192!7740851!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18573 invoked from network); 14 Feb 2012 20:59:53 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 20:59:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329253192; l=976;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mv0yuDH1OdGVJcTlW8n15CKwEXM=;
	b=IGoDFwJSLrlWxfn/S9gRcVzMhZTQLW6t2K/F+VB0sKn9yTMcLh1Yb5e+xThmdlP5eSv
	VvdgbDa/tWf3fg4Ub1274Zdc2WUdGoRXusLjCCondgZkIjX5wG/C6epx1+jNlW4cdB0np
	VZGmCC1ZZOecJy3Wt7jBDgb/3wbKtzC445o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (fruni mo32) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V04896o1EITnwN ;
	Tue, 14 Feb 2012 21:59:47 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C792518637; Tue, 14 Feb 2012 21:59:54 +0100 (CET)
Date: Tue, 14 Feb 2012 21:59:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120214205954.GA21776@aepfle.de>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <002201ccea12$e83c0420$b8b40c60$@com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, Hongkaixing wrote:

>    I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
> Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
> and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.
> so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
> (28 = No space left on device): Internal error".Because there is no available free port for this domU.
> Only the port's state is ECS_FREE,then it can be allocated by get_free_port();

Are you sure its the event channel?

I just tried to run xenpaging in a loop and after a while I got this
instead:

xc: detail: xenpaging init
xc: detail: watching '/local/domain/1/memory/target-tot_pages'
xc: error: Error initialising shared page (28 = No space left on device): Internal error

Is it that what you are seeing?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:00:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:00:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxPTf-0001KL-8y; Tue, 14 Feb 2012 20:59:55 +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 1RxPTe-0001KG-Ei
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 20:59:54 +0000
Received: from [85.158.139.83:43898] by server-2.bemta-5.messagelabs.com id
	3B/CD-20263-94BCA3F4; Tue, 14 Feb 2012 20:59:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329253192!7740851!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18573 invoked from network); 14 Feb 2012 20:59:53 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 20:59:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329253192; l=976;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mv0yuDH1OdGVJcTlW8n15CKwEXM=;
	b=IGoDFwJSLrlWxfn/S9gRcVzMhZTQLW6t2K/F+VB0sKn9yTMcLh1Yb5e+xThmdlP5eSv
	VvdgbDa/tWf3fg4Ub1274Zdc2WUdGoRXusLjCCondgZkIjX5wG/C6epx1+jNlW4cdB0np
	VZGmCC1ZZOecJy3Wt7jBDgb/3wbKtzC445o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (fruni mo32) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V04896o1EITnwN ;
	Tue, 14 Feb 2012 21:59:47 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C792518637; Tue, 14 Feb 2012 21:59:54 +0100 (CET)
Date: Tue, 14 Feb 2012 21:59:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120214205954.GA21776@aepfle.de>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <002201ccea12$e83c0420$b8b40c60$@com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 13, Hongkaixing wrote:

>    I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
> Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
> and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.
> so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
> (28 = No space left on device): Internal error".Because there is no available free port for this domU.
> Only the port's state is ECS_FREE,then it can be allocated by get_free_port();

Are you sure its the event channel?

I just tried to run xenpaging in a loop and after a while I got this
instead:

xc: detail: xenpaging init
xc: detail: watching '/local/domain/1/memory/target-tot_pages'
xc: error: Error initialising shared page (28 = No space left on device): Internal error

Is it that what you are seeing?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:09:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxPcf-0001WN-Ae; Tue, 14 Feb 2012 21:09:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxPcd-0001WF-KP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:09:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329253744!8224361!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDEwMDE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDEwMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14957 invoked from network); 14 Feb 2012 21:09:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 21:09:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329253744; l=548;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/YCaA3xzsmIyrsOe++eLSyAKqes=;
	b=few5SxiJsBHKu2JNU+EzrMmEwQHW7nyGggnrxFMMdYq3Xs74ej9UYL6sb8fcnVnyFhl
	2RpcxYntzrWAdORIUNdU+Ko02UCY9P0alBbmr2poXhtM0LnbSkaUnuVwCeGUl/vKyFVYU
	L4TFxFeBGCOBuo9d05mmFMlE0ZKJnL3YI+Q=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by post.strato.de (mrclete mo17) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w02f1do1EKUtzu
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 22:08:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C1F6918637; Tue, 14 Feb 2012 22:08:51 +0100 (CET)
Date: Tue, 14 Feb 2012 22:08:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120214210851.GA21988@aepfle.de>
References: <patchbomb.1327939163@probook.site>
	<b7906ad2815304272686.1327939169@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b7906ad2815304272686.1327939169@probook.site>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Olaf Hering wrote:

> +++ b/tools/xenpaging/policy_default.c
> @@ -80,33 +80,58 @@ int policy_init(struct xenpaging *paging
>  unsigned long policy_choose_victim(struct xenpaging *paging)

> +
> +        /* gfn busy */
> +        if ( test_bit(current_gfn, bitmap) )
> +            continue;
> +
> +        /* gfn already tested */
> +        if ( test_bit(current_gfn, bitmap) )
> +            continue;
> +
> +        /* gfn found */
> +        break;

The second one should be "unconsumed" instead of "bitmap", otherwise
wraparounds lead to endless loop in caller..

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:09:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxPcf-0001WN-Ae; Tue, 14 Feb 2012 21:09:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxPcd-0001WF-KP
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:09:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329253744!8224361!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDEwMDE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNDEwMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14957 invoked from network); 14 Feb 2012 21:09:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 21:09:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329253744; l=548;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/YCaA3xzsmIyrsOe++eLSyAKqes=;
	b=few5SxiJsBHKu2JNU+EzrMmEwQHW7nyGggnrxFMMdYq3Xs74ej9UYL6sb8fcnVnyFhl
	2RpcxYntzrWAdORIUNdU+Ko02UCY9P0alBbmr2poXhtM0LnbSkaUnuVwCeGUl/vKyFVYU
	L4TFxFeBGCOBuo9d05mmFMlE0ZKJnL3YI+Q=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by post.strato.de (mrclete mo17) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w02f1do1EKUtzu
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 22:08:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C1F6918637; Tue, 14 Feb 2012 22:08:51 +0100 (CET)
Date: Tue, 14 Feb 2012 22:08:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120214210851.GA21988@aepfle.de>
References: <patchbomb.1327939163@probook.site>
	<b7906ad2815304272686.1327939169@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b7906ad2815304272686.1327939169@probook.site>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Olaf Hering wrote:

> +++ b/tools/xenpaging/policy_default.c
> @@ -80,33 +80,58 @@ int policy_init(struct xenpaging *paging
>  unsigned long policy_choose_victim(struct xenpaging *paging)

> +
> +        /* gfn busy */
> +        if ( test_bit(current_gfn, bitmap) )
> +            continue;
> +
> +        /* gfn already tested */
> +        if ( test_bit(current_gfn, bitmap) )
> +            continue;
> +
> +        /* gfn found */
> +        break;

The second one should be "unconsumed" instead of "bitmap", otherwise
wraparounds lead to endless loop in caller..

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:19:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21: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.xensource.com>)
	id 1RxPmK-0001zc-De; Tue, 14 Feb 2012 21:19:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxPmI-0001zX-Jj
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:19:10 +0000
Received: from [193.109.254.147:13772] by server-1.bemta-14.messagelabs.com id
	12/5F-12485-DCFCA3F4; Tue, 14 Feb 2012 21:19:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329254297!52754123!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTM2MDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTM2MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32578 invoked from network); 14 Feb 2012 21:18:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 21:18:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329254348; l=388;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Ul9jL9CEeOZojGXKoyps8sGl0zM=;
	b=HAqzVd5Cd57oyA4c7y+EEGVJ/+1NLcAE4nUV10zldHIZKtmvfIBbG3ZlFh+rkjc28+A
	0zaA2d8mBYJGqldbVyV2D3nq0Snupi5/95h0nqL0Pgz3BBFDTj5u4iJxWPl7DaFyi8EBd
	wa7YkFlj7K7sWK0hkLm0tgBqcUviQFa5EAo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (cohen mo61) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id o0609bo1EKaKXj ;
	Tue, 14 Feb 2012 22:18:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B5EA518637; Tue, 14 Feb 2012 22:19:05 +0100 (CET)
Date: Tue, 14 Feb 2012 22:19:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120214211905.GA23069@aepfle.de>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<20120214205954.GA21776@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120214205954.GA21776@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Olaf Hering wrote:

> xc: error: Error initialising shared page (28 = No space left on device): Internal error

After reading the code more carefully I now see that mem_event_enable()
calls alloc_unbound_xen_event_channel() and stores it into
med->xen_port. As Tim suggested, your patch should use this value
instead of relying on the shared_page pointer.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:19:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21: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.xensource.com>)
	id 1RxPmK-0001zc-De; Tue, 14 Feb 2012 21:19:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxPmI-0001zX-Jj
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:19:10 +0000
Received: from [193.109.254.147:13772] by server-1.bemta-14.messagelabs.com id
	12/5F-12485-DCFCA3F4; Tue, 14 Feb 2012 21:19:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329254297!52754123!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTM2MDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTM2MDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32578 invoked from network); 14 Feb 2012 21:18:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2012 21:18:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329254348; l=388;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Ul9jL9CEeOZojGXKoyps8sGl0zM=;
	b=HAqzVd5Cd57oyA4c7y+EEGVJ/+1NLcAE4nUV10zldHIZKtmvfIBbG3ZlFh+rkjc28+A
	0zaA2d8mBYJGqldbVyV2D3nq0Snupi5/95h0nqL0Pgz3BBFDTj5u4iJxWPl7DaFyi8EBd
	wa7YkFlj7K7sWK0hkLm0tgBqcUviQFa5EAo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (cohen mo61) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id o0609bo1EKaKXj ;
	Tue, 14 Feb 2012 22:18:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B5EA518637; Tue, 14 Feb 2012 22:19:05 +0100 (CET)
Date: Tue, 14 Feb 2012 22:19:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120214211905.GA23069@aepfle.de>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<20120214205954.GA21776@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120214205954.GA21776@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Olaf Hering wrote:

> xc: error: Error initialising shared page (28 = No space left on device): Internal error

After reading the code more carefully I now see that mem_event_enable()
calls alloc_unbound_xen_event_channel() and stores it into
med->xen_port. As Tim suggested, your patch should use this value
instead of relying on the shared_page pointer.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:27:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21: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.xensource.com>)
	id 1RxPuD-00029O-BD; Tue, 14 Feb 2012 21:27:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxPuB-00029J-03
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:27:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329254832!14811013!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25672 invoked from network); 14 Feb 2012 21:27:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 21:27:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329254832; l=1404;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TpZxjQiFAuyVDqrKr8dAlekn9e0=;
	b=oYt3NdaMEVIMx3QlEiFSOdUCv0p36K7SZnXrU6MWtS1YMeP/ycczEDJa9Ukdg3xq8X+
	CoEsynk0/uNk1v0nI+h2iTWF8VWWGajqP7BWcbP6ht+h9ftxkbCGvHWS0dU2LmlkF79D9
	eEtP5vb3nCQUB2+u8GeWUfpbZ5g72TQ3nBM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (fruni mo50) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z0570ao1EKmNe0 ;
	Tue, 14 Feb 2012 22:26:48 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B5BCB18637; Tue, 14 Feb 2012 22:26:55 +0100 (CET)
Date: Tue, 14 Feb 2012 22:26:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214212655.GA23901@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Finally, the triple fault.
> >
> > "Me too!"
> > Thats how far I got as well in my attempt.
> 
> Hey, awesome you're trying this out so quickly :)

I meant my attempt a few weeks ago.
 
> If you have a couple cycles...

Does your pager do anything? I just get this:

xc: detail: xenpaging init
xc: detail: watching '/local/domain/1/memory/target-tot_pages'
xc: detail: max_pages = 263168
xc: detail: starting /usr/lib/xen/bin/xenpaging for domain_id 1 with pagefile /dev/shm/pagefile-sles11sp2_full_xenpaging
xc: detail: confirming startup in /local/domain/1/xenpaging/state
xc: detail: Got event from xenstore
xc: detail: path '@releaseDomain' token '1'
xc: detail: Got event from evtchn
xc: detail: Got event from xenstore
xc: detail: path '/local/domain/1/memory/target-tot_pages' token ''
xc: detail: new target_tot_pages 59904
xc: detail: Got event from Xen
xc: detail: Need to evict 202213 pages to reach 59904 target_tot_pages
xc: error: Error mapping page 20201 (22 = Invalid argument): Internal error
xc: debug: hypercall buffer: total allocations:9 total releases:9
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:7 misses:2 toobig:0


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:27:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21: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.xensource.com>)
	id 1RxPuD-00029O-BD; Tue, 14 Feb 2012 21:27:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxPuB-00029J-03
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:27:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329254832!14811013!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25672 invoked from network); 14 Feb 2012 21:27:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 21:27:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329254832; l=1404;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TpZxjQiFAuyVDqrKr8dAlekn9e0=;
	b=oYt3NdaMEVIMx3QlEiFSOdUCv0p36K7SZnXrU6MWtS1YMeP/ycczEDJa9Ukdg3xq8X+
	CoEsynk0/uNk1v0nI+h2iTWF8VWWGajqP7BWcbP6ht+h9ftxkbCGvHWS0dU2LmlkF79D9
	eEtP5vb3nCQUB2+u8GeWUfpbZ5g72TQ3nBM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by smtp.strato.de (fruni mo50) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z0570ao1EKmNe0 ;
	Tue, 14 Feb 2012 22:26:48 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B5BCB18637; Tue, 14 Feb 2012 22:26:55 +0100 (CET)
Date: Tue, 14 Feb 2012 22:26:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214212655.GA23901@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Finally, the triple fault.
> >
> > "Me too!"
> > Thats how far I got as well in my attempt.
> 
> Hey, awesome you're trying this out so quickly :)

I meant my attempt a few weeks ago.
 
> If you have a couple cycles...

Does your pager do anything? I just get this:

xc: detail: xenpaging init
xc: detail: watching '/local/domain/1/memory/target-tot_pages'
xc: detail: max_pages = 263168
xc: detail: starting /usr/lib/xen/bin/xenpaging for domain_id 1 with pagefile /dev/shm/pagefile-sles11sp2_full_xenpaging
xc: detail: confirming startup in /local/domain/1/xenpaging/state
xc: detail: Got event from xenstore
xc: detail: path '@releaseDomain' token '1'
xc: detail: Got event from evtchn
xc: detail: Got event from xenstore
xc: detail: path '/local/domain/1/memory/target-tot_pages' token ''
xc: detail: new target_tot_pages 59904
xc: detail: Got event from Xen
xc: detail: Need to evict 202213 pages to reach 59904 target_tot_pages
xc: error: Error mapping page 20201 (22 = Invalid argument): Internal error
xc: debug: hypercall buffer: total allocations:9 total releases:9
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:7 misses:2 toobig:0


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:33:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21: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.xensource.com>)
	id 1RxQ0G-0002Ik-5F; Tue, 14 Feb 2012 21:33:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxQ0F-0002Ib-4L
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:33:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329255208!11402314!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTYxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10797 invoked from network); 14 Feb 2012 21:33:28 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-7.tower-21.messagelabs.com with SMTP;
	14 Feb 2012 21:33:28 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id B8B04380073;
	Tue, 14 Feb 2012 13:33:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=glxwx/ixSqnH3zDt0PqqbXDsDCCOLPjutFHKMcVBpg26
	376cQqV2hlogogvORZKmdwFZ/GHVAViSO5VryDor84xmCoH+uLYDBjIbGbmVE1RB
	19t3cyszWcktA25Ll1eashvBINDUobp6IhqoIk4BhTw+iZ6xNR9XPxU07z1z27w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=9e3Iek3rvB0ZOuP1qlj4ILXBXPY=; b=o3TZj+nK
	hUyvFkLUcyD9MdCxVI3D7LAN6K8fqzR7wToMnSHwL8KUndsyWM/FpM2Bu4SpXo94
	dAbHXkg2b1jbZDqTfLk0PveHxTN7Z77yqM4Hn8b0P9NsxF9ig4pb6cP11dbyenAy
	VL1bAW2vFX3RuDqB1mEqP3fNHcvY2J0Hk00=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id BA48E38005F; 
	Tue, 14 Feb 2012 13:33:26 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 13:33:27 -0800
Message-ID: <d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214212655.GA23901@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
Date: Tue, 14 Feb 2012 13:33:27 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>> >
>> >> Finally, the triple fault.
>> >
>> > "Me too!"
>> > Thats how far I got as well in my attempt.
>>
>> Hey, awesome you're trying this out so quickly :)
>
> I meant my attempt a few weeks ago.
>
>> If you have a couple cycles...
>
> Does your pager do anything? I just get this:
>
> xc: detail: xenpaging init
> xc: detail: watching '/local/domain/1/memory/target-tot_pages'
> xc: detail: max_pages = 263168
> xc: detail: starting /usr/lib/xen/bin/xenpaging for domain_id 1 with
> pagefile /dev/shm/pagefile-sles11sp2_full_xenpaging
> xc: detail: confirming startup in /local/domain/1/xenpaging/state
> xc: detail: Got event from xenstore
> xc: detail: path '@releaseDomain' token '1'
> xc: detail: Got event from evtchn
> xc: detail: Got event from xenstore
> xc: detail: path '/local/domain/1/memory/target-tot_pages' token ''
> xc: detail: new target_tot_pages 59904
> xc: detail: Got event from Xen
> xc: detail: Need to evict 202213 pages to reach 59904 target_tot_pages
> xc: error: Error mapping page 20201 (22 = Invalid argument): Internal
> error

Those are the kinds of errors I was getting until I finished my patch.
Basically, the p2m gets confused and returns p2m_mmio_dm as the type for
anything it doesn't understand. If you end up giving my patch a spin, let
me know if it gets you past that hump.

Andres

> xc: debug: hypercall buffer: total allocations:9 total releases:9
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:7 misses:2 toobig:0
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:33:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21: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.xensource.com>)
	id 1RxQ0G-0002Ik-5F; Tue, 14 Feb 2012 21:33:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxQ0F-0002Ib-4L
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:33:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329255208!11402314!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTYxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10797 invoked from network); 14 Feb 2012 21:33:28 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-7.tower-21.messagelabs.com with SMTP;
	14 Feb 2012 21:33:28 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id B8B04380073;
	Tue, 14 Feb 2012 13:33:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=glxwx/ixSqnH3zDt0PqqbXDsDCCOLPjutFHKMcVBpg26
	376cQqV2hlogogvORZKmdwFZ/GHVAViSO5VryDor84xmCoH+uLYDBjIbGbmVE1RB
	19t3cyszWcktA25Ll1eashvBINDUobp6IhqoIk4BhTw+iZ6xNR9XPxU07z1z27w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=9e3Iek3rvB0ZOuP1qlj4ILXBXPY=; b=o3TZj+nK
	hUyvFkLUcyD9MdCxVI3D7LAN6K8fqzR7wToMnSHwL8KUndsyWM/FpM2Bu4SpXo94
	dAbHXkg2b1jbZDqTfLk0PveHxTN7Z77yqM4Hn8b0P9NsxF9ig4pb6cP11dbyenAy
	VL1bAW2vFX3RuDqB1mEqP3fNHcvY2J0Hk00=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id BA48E38005F; 
	Tue, 14 Feb 2012 13:33:26 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 14 Feb 2012 13:33:27 -0800
Message-ID: <d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214212655.GA23901@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
Date: Tue, 14 Feb 2012 13:33:27 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>
>> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>> >
>> >> Finally, the triple fault.
>> >
>> > "Me too!"
>> > Thats how far I got as well in my attempt.
>>
>> Hey, awesome you're trying this out so quickly :)
>
> I meant my attempt a few weeks ago.
>
>> If you have a couple cycles...
>
> Does your pager do anything? I just get this:
>
> xc: detail: xenpaging init
> xc: detail: watching '/local/domain/1/memory/target-tot_pages'
> xc: detail: max_pages = 263168
> xc: detail: starting /usr/lib/xen/bin/xenpaging for domain_id 1 with
> pagefile /dev/shm/pagefile-sles11sp2_full_xenpaging
> xc: detail: confirming startup in /local/domain/1/xenpaging/state
> xc: detail: Got event from xenstore
> xc: detail: path '@releaseDomain' token '1'
> xc: detail: Got event from evtchn
> xc: detail: Got event from xenstore
> xc: detail: path '/local/domain/1/memory/target-tot_pages' token ''
> xc: detail: new target_tot_pages 59904
> xc: detail: Got event from Xen
> xc: detail: Need to evict 202213 pages to reach 59904 target_tot_pages
> xc: error: Error mapping page 20201 (22 = Invalid argument): Internal
> error

Those are the kinds of errors I was getting until I finished my patch.
Basically, the p2m gets confused and returns p2m_mmio_dm as the type for
anything it doesn't understand. If you end up giving my patch a spin, let
me know if it gets you past that hump.

Andres

> xc: debug: hypercall buffer: total allocations:9 total releases:9
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:7 misses:2 toobig:0
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:43:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxQ9t-0002VB-EJ; Tue, 14 Feb 2012 21:43:33 +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 1RxQ9r-0002V6-Ot
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:43:31 +0000
Received: from [85.158.139.83:17736] by server-12.bemta-5.messagelabs.com id
	6A/EA-24595-285DA3F4; Tue, 14 Feb 2012 21:43:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329255809!15074840!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16338 invoked from network); 14 Feb 2012 21:43:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 21:43:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329255809; l=587;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fs9qGXD2IEMGVvO9//cqi9VOFtg=;
	b=EpBFLDvLbf6FnhkFk6r8zuveVBwibVz6NAJAYVvMDg5uxlA/S7xEHsoGAd/tpSgItrp
	HkdgNY6TLSsk1CcbTjJjO++6egrhNe48Z98y+6XG8MMfsqJvkyXUp7RF/YTE+QLnMyBr6
	qhfNJVa0gB/pF1nEhCfuhGrr4+SKpbCeXaY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by post.strato.de (mrclete mo30) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n038c9o1ELRSvZ ;
	Tue, 14 Feb 2012 22:43:06 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3452918637; Tue, 14 Feb 2012 22:43:13 +0100 (CET)
Date: Tue, 14 Feb 2012 22:43:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214214313.GA25605@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
	<d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> Those are the kinds of errors I was getting until I finished my patch.
> Basically, the p2m gets confused and returns p2m_mmio_dm as the type for
> anything it doesn't understand. If you end up giving my patch a spin, let
> me know if it gets you past that hump.

No, it does not work for me, still EINVAL during mapping.

Perhaps the cpu is not new enough?

processor       : 11
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 8
model name      : AMD Engineering Sample
stepping        : 0
cpu MHz         : 2400.204
cache size      : 512 KB

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:43:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:43:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxQ9t-0002VB-EJ; Tue, 14 Feb 2012 21:43:33 +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 1RxQ9r-0002V6-Ot
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:43:31 +0000
Received: from [85.158.139.83:17736] by server-12.bemta-5.messagelabs.com id
	6A/EA-24595-285DA3F4; Tue, 14 Feb 2012 21:43:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329255809!15074840!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjU5MjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16338 invoked from network); 14 Feb 2012 21:43:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 14 Feb 2012 21:43:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329255809; l=587;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fs9qGXD2IEMGVvO9//cqi9VOFtg=;
	b=EpBFLDvLbf6FnhkFk6r8zuveVBwibVz6NAJAYVvMDg5uxlA/S7xEHsoGAd/tpSgItrp
	HkdgNY6TLSsk1CcbTjJjO++6egrhNe48Z98y+6XG8MMfsqJvkyXUp7RF/YTE+QLnMyBr6
	qhfNJVa0gB/pF1nEhCfuhGrr4+SKpbCeXaY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2s7oGvk=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-093-038.pools.arcor-ip.net [84.57.93.38])
	by post.strato.de (mrclete mo30) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n038c9o1ELRSvZ ;
	Tue, 14 Feb 2012 22:43:06 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3452918637; Tue, 14 Feb 2012 22:43:13 +0100 (CET)
Date: Tue, 14 Feb 2012 22:43:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120214214313.GA25605@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
	<d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Andres Lagar-Cavilla wrote:

> Those are the kinds of errors I was getting until I finished my patch.
> Basically, the p2m gets confused and returns p2m_mmio_dm as the type for
> anything it doesn't understand. If you end up giving my patch a spin, let
> me know if it gets you past that hump.

No, it does not work for me, still EINVAL during mapping.

Perhaps the cpu is not new enough?

processor       : 11
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 8
model name      : AMD Engineering Sample
stepping        : 0
cpu MHz         : 2400.204
cache size      : 512 KB

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:50:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxQGO-0002x4-AR; Tue, 14 Feb 2012 21:50:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1RxQGM-0002wx-9p
	for Xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:50:14 +0000
Received: from [85.158.139.83:31725] by server-4.bemta-5.messagelabs.com id
	F7/2A-10788-517DA3F4; Tue, 14 Feb 2012 21:50:13 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329256211!14529535!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA4OTQxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15462 invoked from network); 14 Feb 2012 21:50:12 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 21:50:12 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1ELn1BL004643;
	Tue, 14 Feb 2012 21:49:05 GMT
Received: from vega-c.dur.ac.uk (vega-c.dur.ac.uk [129.234.250.135])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1ELmhMY000900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 21:48:43 GMT
Received: from vega-c.dur.ac.uk (localhost [127.0.0.1])
	by vega-c.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q1ELmhZa031833;
	Tue, 14 Feb 2012 21:48:43 GMT
Received: from localhost (dcl0may@localhost)
	by vega-c.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q1ELmfYH031817;
	Tue, 14 Feb 2012 21:48:42 GMT
Date: Tue, 14 Feb 2012 21:48:41 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120214140020.GB21610@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
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: q1ELn1BL004643
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] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 13, 2012 at 02:12:08PM +0000, M A Young wrote:
>> On Mon, 13 Feb 2012, Ian Campbell wrote:
>>
>>> On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
>>>> I get the backtrace below if I try to boot a PV guest running F17 Alpha
>>>> TC2 in graphical mode. Is this a known problem?
>>>
>>> It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
>>> the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
>>> got to the bottom of the root cause though.
>>>
>>> That occasion was a suspend/resume thing so perhaps not really related
>>> but it seems fishily similar.
>>>
>>> I've not looked at the code recently but it seems that back then I was
>>> of the opinion that info->update_wanted == 0 must remain true until the
>>> irq etc was all fully setup, that might be relevant now?
>>
>> Yes, it does sound fishily similar. I didn't mention that it does work if
>> I do a text boot and then switch to a graphical runlevel, so it could be
>
> So how does F17 do it now? Is all in the graphical mode (KMS?) and it never
> tries to hit text mode (so plymouth is on by default?)

I was probably wrong about that. It was a separate non-kernel bug that was 
stopping me getting a direct graphical boot. As the backtrace happens some 
time but not others I am not longer convinced about the graphical vs text 
boot link. The backtrace occurs before the line
Feb 14 20:26:31 localhost kernel: [    2.611366] Console: switching to 
colour frame buffer device 100x37
so it seems to be when the frame buffer first launches.

>> somthing happening in the wrong order, such as the framebuffer starting
>> before the irq is properly set up.
>
> Hm, could you instrument xen-fbfront.c and see what the flow is during
> bootup and compare that when running it under F16? That might shed some
> light on this.

I will have a look at what useful debugging I can put into xen-fbfront.c - 
it might be hard for me to compare it with F16 but the comparsion between 
a backtrace and non-backtrace boot might be useful.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 21:50:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 21:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxQGO-0002x4-AR; Tue, 14 Feb 2012 21:50:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1RxQGM-0002wx-9p
	for Xen-devel@lists.xensource.com; Tue, 14 Feb 2012 21:50:14 +0000
Received: from [85.158.139.83:31725] by server-4.bemta-5.messagelabs.com id
	F7/2A-10788-517DA3F4; Tue, 14 Feb 2012 21:50:13 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329256211!14529535!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA4OTQxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15462 invoked from network); 14 Feb 2012 21:50:12 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 21:50:12 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1ELn1BL004643;
	Tue, 14 Feb 2012 21:49:05 GMT
Received: from vega-c.dur.ac.uk (vega-c.dur.ac.uk [129.234.250.135])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1ELmhMY000900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 14 Feb 2012 21:48:43 GMT
Received: from vega-c.dur.ac.uk (localhost [127.0.0.1])
	by vega-c.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q1ELmhZa031833;
	Tue, 14 Feb 2012 21:48:43 GMT
Received: from localhost (dcl0may@localhost)
	by vega-c.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q1ELmfYH031817;
	Tue, 14 Feb 2012 21:48:42 GMT
Date: Tue, 14 Feb 2012 21:48:41 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120214140020.GB21610@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
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: q1ELn1BL004643
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] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 13, 2012 at 02:12:08PM +0000, M A Young wrote:
>> On Mon, 13 Feb 2012, Ian Campbell wrote:
>>
>>> On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
>>>> I get the backtrace below if I try to boot a PV guest running F17 Alpha
>>>> TC2 in graphical mode. Is this a known problem?
>>>
>>> It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
>>> the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
>>> got to the bottom of the root cause though.
>>>
>>> That occasion was a suspend/resume thing so perhaps not really related
>>> but it seems fishily similar.
>>>
>>> I've not looked at the code recently but it seems that back then I was
>>> of the opinion that info->update_wanted == 0 must remain true until the
>>> irq etc was all fully setup, that might be relevant now?
>>
>> Yes, it does sound fishily similar. I didn't mention that it does work if
>> I do a text boot and then switch to a graphical runlevel, so it could be
>
> So how does F17 do it now? Is all in the graphical mode (KMS?) and it never
> tries to hit text mode (so plymouth is on by default?)

I was probably wrong about that. It was a separate non-kernel bug that was 
stopping me getting a direct graphical boot. As the backtrace happens some 
time but not others I am not longer convinced about the graphical vs text 
boot link. The backtrace occurs before the line
Feb 14 20:26:31 localhost kernel: [    2.611366] Console: switching to 
colour frame buffer device 100x37
so it seems to be when the frame buffer first launches.

>> somthing happening in the wrong order, such as the framebuffer starting
>> before the irq is properly set up.
>
> Hm, could you instrument xen-fbfront.c and see what the flow is during
> bootup and compare that when running it under F16? That might shed some
> light on this.

I will have a look at what useful debugging I can put into xen-fbfront.c - 
it might be hard for me to compare it with F16 but the comparsion between 
a backtrace and non-backtrace boot might be useful.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 23:48:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 23:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxS6J-0004dB-V5; Tue, 14 Feb 2012 23:47:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhiyuan.lv@intel.com>) id 1RxS6J-0004d6-2T
	for Xen-devel@lists.xensource.com; Tue, 14 Feb 2012 23:47:59 +0000
Received: from [85.158.139.83:36675] by server-6.bemta-5.messagelabs.com id
	AD/25-27305-EA2FA3F4; Tue, 14 Feb 2012 23:47:58 +0000
X-Env-Sender: zhiyuan.lv@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329263275!15082794!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjMyMjMz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24500 invoked from network); 14 Feb 2012 23:47:57 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 23:47:57 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 14 Feb 2012 15:47:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106831955"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 14 Feb 2012 15:47:35 -0800
Received: from pgsmsx603.gar.corp.intel.com (10.221.43.87) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 15 Feb 2012 07:47:27 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 15 Feb 2012 07:47:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 15 Feb 2012 07:47:52 +0800
From: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>
To: =?utf-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] 1 GPU multiple VMs
Thread-Index: AcziEI9YhPf/uaMKQPWlLvKH91C0fwEMlf6AAAFEGgAAAIeZAAAAPT+AAAAhrYABSYTvYA==
Date: Tue, 14 Feb 2012 23:47:42 +0000
Message-ID: <90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
In-Reply-To: <20120208182233.GB12984@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zaborowski, Andrew" <andrew.zaborowski@intel.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0Bs
aXN0cy54ZW5zb3VyY2UuY29tDQo+IFttYWlsdG86eGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVu
c291cmNlLmNvbV0gT24gQmVoYWxmIE9mIFBhc2kgSz9ya2s/aW5lbg0KPiBTZW50OiBUaHVyc2Rh
eSwgRmVicnVhcnkgMDksIDIwMTIgMjoyMyBBTQ0KPiBUbzogU3RlZmFubyBTdGFiZWxsaW5pDQo+
IENjOiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTsgSmFjb2JzIEpvcmRpDQo+IFN1Ympl
Y3Q6IFJlOiBbWGVuLWRldmVsXSAxIEdQVSBtdWx0aXBsZSBWTXMNCj4gDQo+IE9uIFdlZCwgRmVi
IDA4LCAyMDEyIGF0IDA4OjE4OjQ3UE0gKzAyMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOg0K
PiA+IE9uIFdlZCwgRmViIDA4LCAyMDEyIGF0IDA2OjExOjU2UE0gKzAwMDAsIFN0ZWZhbm8gU3Rh
YmVsbGluaSB3cm90ZToNCj4gPiA+IE9uIFdlZCwgOCBGZWIgMjAxMiwgUGFzaSBLw4PGksOCP3Jr
a8ODxpLDgj9pbmVuIHdyb3RlOg0KPiA+ID4gPiBPbiBXZWQsIEZlYiAwOCwgMjAxMiBhdCAwNToy
MDozMVBNICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+ID4gPiA+ID4gT24gRnJp
LCAzIEZlYiAyMDEyLCBKYWNvYnMgSm9yZGkgd3JvdGU6DQo+ID4gPiA+ID4gPiBIaSwNCj4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiBJIGFtIHdvbmRlcmluZyBob3cgR1BVIHNoYXJpbmcgY291bGQv
c2hvdWxkIGJlIGltcGxlbWVudGVkIGZvciB0aGUNCj4gWGVuIEh5cGVydmlzb3IuDQo+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gSSBoYXZlIGNvbWUgYWNyb3NzIHNldmVyYWwgcGFwZXJzIHRoYXQg
ZXhwbGFpbiBtYW55IHBvc3NpYmlsaXRpZXMgb24NCj4gR1BVIHNoYXJpbmcgZm9yIG11bHRpcGxl
IFZNcyBidXQgSSdtIG5vdCBzdXJlIHdpY2gNCj4gPiA+ID4gPiA+IG9uZSB3b3VsZCBiZSB0aGUg
YmVzdCBzb2x1dGlvbiBmb3IgWGVuLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEFQSSByZW1v
dGluZyAoZ2FsbGl1bTNEKSAoZXguIFhlbjNEIHByb2plY3QpDQo+ID4gPiA+ID4gPiBNZWRpYXRl
ZCBwYXNzdGhyb3VnaCAoTXVsdGlwbGV4aW5nIHRoZSBHUFUgd2hpbGUgbWFpbnRhaW5pbmcgdGhl
DQo+IGRpZmZlcmVudCBjb250ZXh0cy4pDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ2FuIHlv
dSBndXlzIGdpdmUgbWUgeW91ciBpZGVhIG9uIHRoZSBtYXR0ZXI/DQo+ID4gPiA+ID4gPiBQbGVh
c2UgYWxzbyBtZW50aW9uIGFueSBleGlzdGluZyBwcm9qZWN0cyB5b3Uga25vdyB0aGF0IGFyZSBy
ZWxhdGVkIHRvDQo+IHRoaXMgcHJvYmxlbS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE15IHBlcnNv
bmFsIG9waW5pb24gaXMgdGhhdCB0aGUgc2ltcGxlc3QgdGhpbmcgdG8gZG8gaXMgT3BlbkdMDQo+
ID4gPiA+ID4gcmVtb3RpbmcuIEdhbGxpdW0gcmVtb3RpbmcgY291bGQgYWxzbyBiZSBPSyBidXQg
Y29uc2lkZXJpbmcgdGhhdCBtYW55DQo+ID4gPiA+ID4gY2FyZHMgZG9uJ3QgaGF2ZSBHYWxsaXVt
IGRyaXZlcnMgd2Ugd291bGQgcHJvYmFibHkgZW5kIHVwIGRvaW5nIHR3bw0KPiA+ID4gPiA+IGNv
bnZlcnNpb25zIGluc3RlYWQgb2Ygb25lIChEaXJlY3RYLT5HYWxsaXVtIGluIHRoZSBndWVzdCwN
Cj4gPiA+ID4gPiBHYWxsaXVtLT5PcGVuR0wgaW4gZG9tMCkuDQo+ID4gPiA+ID4gTWVkaWF0ZWQg
cGFzc3Rocm91Z2ggaXMgdmVyeSBjYXJkIHNwZWNpZmljIHNvIEkgYW0gYWZyYWlkIHlvdSB3b3Vs
ZCBlbmQNCj4gPiA+ID4gPiB1cCB3cml0aW5nIHZpcnR1YWxpemF0aW9uIHNwZWNpZmljIGRyaXZl
cnMgZm9yIGFsbCB0aGUgY2FyZHMgeW91IHdhbnQgdG8NCj4gPiA+ID4gPiBzdXBwb3J0LiBOb3Qg
dG8gbWVudGlvbiB0aGF0IHlvdSBtaWdodCBuZWVkIHRvIGFjY2VzcyBzb21lIHZpZGVvY2FyZA0K
PiA+ID4gPiA+IGludGVyZmFjZXMgdGhhdCBvbiBOdmlkaWEgYXJlIG5vdCBkaXNjb3NlZC4NCj4g
PiA+ID4gPg0KPiA+ID4gPiA+IEkgYmVsaWV2ZSB0aGF0IHZpcnR1YWxib3ggYWxyZWFkeSBzdXBw
b3J0cyBPcGVuR0wgcmVtb3RpbmcgaW4gYSBkZWNlbnQNCj4gPiA+ID4gPiB3YXksIHNvIEkgd291
bGQgc3RhcnQgZnJvbSB0aGVyZSwgcG9ydCB3aGF0IHRoZXkgaGF2ZSB0byBYZW4sIGFuZA0KPiA+
ID4gPiA+IGltcHJvdmUgaXQuDQo+ID4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gSSB3b25kZXIg
aWYgU1BJQ0UgYWxyZWFkeSBzdXBwb3J0cyBPcGVuR0wgc3R1ZmYuLg0KPiA+ID4gPiBJIHRoaW5r
IGl0J3MgYXQgbGVhc3Qgc3VwcG9zZWQgdG8gYmUgYWJsZSB0byBzdXBwb3J0IE9wZW5HTC4NCj4g
PiA+ID4NCj4gPiA+ID4NCj4gKGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvYXJjaGl2ZXMv
c3BpY2UtZGV2ZWwvMjAxMS1Ob3ZlbWJlci8wMDYwMTguaHQNCj4gbWwpDQo+ID4gPg0KPiA+ID4g
Tm90IHlldCwgYnV0IEkgdGhpbmsgdGhhdCB0aGV5IGFyZSB3b3JraW5nIG9uIGl0LiBTdGlsbCB2
ZXJ5IGVhcmx5IGRheXMNCj4gPiA+IHRob3VnaC4NCj4gPiA+IEFsc28gaXQgd291bGQgb25seSB3
b3JrIHdpdGggSFZNIGd1ZXN0cywgd2hpbGUgaGF2aW5nIGEgcHJvcGVyIHhlbg0KPiA+ID4gZnJv
bnRlbmQvYmFja2VuZCBPcGVuR0wgcmVtb3RpbmcgZHJpdmVyIHBhaXIgd291bGQgd29yayBmb3Ig
Ym90aC4NCj4gPg0KPiA+IFllcC4NCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbzogaHR0cDovL3NvdXJj
ZWZvcmdlLm5ldC9wcm9qZWN0cy92bWdsLw0KPiA+DQo+ID4gIk9wZW5HTCBhcHBzIHJ1bm5pbmcg
aW5zaWRlIGEgVk0gdXNlIFZNR0wgdG8gb2J0YWluIGdyYXBoaWNzIGhhcmR3YXJlDQo+IGFjY2Vs
ZXJhdGlvbi4gVk1HTCBzdXBwb3J0cyBWTXdhcmUsIFhlbiBQViBhbmQgSFZNLCBxZW11LCBhbmQg
S1ZNIFZNczsNCj4gWDExLWJhc2VkIE9TIHN1Y2ggYXMgTGludXgsIEZyZWVCU0QgYW5kIE9wZW5T
b2xhcmlzOyBhbmQgQVRJLCBOdmlkaWEgYW5kIEludGVsDQo+IEdQVXMuICINCj4gPg0KPiANCj4g
QW5kIENocm9taXVtIG1pZ2h0IGhhdmUgc29tZXRoaW5nIHJlbGF0ZWQgYXN3ZWxsOg0KPiBodHRw
Oi8vY2hyb21pdW0uc291cmNlZm9yZ2UubmV0L2RvYy9pbmRleC5odG1sDQo+IA0KSGVsbG8sDQoN
CkFub3RoZXIgcmVsYXRlZCB3b3JrIGlzIGFzIGJlbG93Og0KaHR0cDovL2xpc3RzLmdudS5vcmcv
YXJjaGl2ZS9odG1sL3FlbXUtZGV2ZWwvMjAxMi0wMS9tc2cwMTAyNy5odG1sDQoNClNpbWlsYXIg
dG8gVk1HTCwgaXQgaXMgYW4gQVBJIHJlbW90aW5nIGFwcHJvYWNoIGJ1dCBub3QgYmFzZWQgb24g
Y2hyb21pdW0uIEFub3RoZXIgZGlmZmVyZW5jZSBpcyB0aGF0IGl0IGRvZXMgbm90IHJlcXVpcmUg
WCBzZXJ2ZXIgZXh0ZW5zaW9ucy4gSnVzdCBmb3IgeW91ciByZWZlcmVuY2UuIFRoYW5rcyENCg0K
PiANCj4gLS0gUGFzaQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20NCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVs
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 14 23:48:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 23:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxS6J-0004dB-V5; Tue, 14 Feb 2012 23:47:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhiyuan.lv@intel.com>) id 1RxS6J-0004d6-2T
	for Xen-devel@lists.xensource.com; Tue, 14 Feb 2012 23:47:59 +0000
Received: from [85.158.139.83:36675] by server-6.bemta-5.messagelabs.com id
	AD/25-27305-EA2FA3F4; Tue, 14 Feb 2012 23:47:58 +0000
X-Env-Sender: zhiyuan.lv@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329263275!15082794!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjMyMjMz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24500 invoked from network); 14 Feb 2012 23:47:57 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-182.messagelabs.com with SMTP;
	14 Feb 2012 23:47:57 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 14 Feb 2012 15:47:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106831955"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 14 Feb 2012 15:47:35 -0800
Received: from pgsmsx603.gar.corp.intel.com (10.221.43.87) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 15 Feb 2012 07:47:27 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 15 Feb 2012 07:47:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 15 Feb 2012 07:47:52 +0800
From: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>
To: =?utf-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] 1 GPU multiple VMs
Thread-Index: AcziEI9YhPf/uaMKQPWlLvKH91C0fwEMlf6AAAFEGgAAAIeZAAAAPT+AAAAhrYABSYTvYA==
Date: Tue, 14 Feb 2012 23:47:42 +0000
Message-ID: <90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
In-Reply-To: <20120208182233.GB12984@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zaborowski, Andrew" <andrew.zaborowski@intel.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0Bs
aXN0cy54ZW5zb3VyY2UuY29tDQo+IFttYWlsdG86eGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVu
c291cmNlLmNvbV0gT24gQmVoYWxmIE9mIFBhc2kgSz9ya2s/aW5lbg0KPiBTZW50OiBUaHVyc2Rh
eSwgRmVicnVhcnkgMDksIDIwMTIgMjoyMyBBTQ0KPiBUbzogU3RlZmFubyBTdGFiZWxsaW5pDQo+
IENjOiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTsgSmFjb2JzIEpvcmRpDQo+IFN1Ympl
Y3Q6IFJlOiBbWGVuLWRldmVsXSAxIEdQVSBtdWx0aXBsZSBWTXMNCj4gDQo+IE9uIFdlZCwgRmVi
IDA4LCAyMDEyIGF0IDA4OjE4OjQ3UE0gKzAyMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOg0K
PiA+IE9uIFdlZCwgRmViIDA4LCAyMDEyIGF0IDA2OjExOjU2UE0gKzAwMDAsIFN0ZWZhbm8gU3Rh
YmVsbGluaSB3cm90ZToNCj4gPiA+IE9uIFdlZCwgOCBGZWIgMjAxMiwgUGFzaSBLw4PGksOCP3Jr
a8ODxpLDgj9pbmVuIHdyb3RlOg0KPiA+ID4gPiBPbiBXZWQsIEZlYiAwOCwgMjAxMiBhdCAwNToy
MDozMVBNICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+ID4gPiA+ID4gT24gRnJp
LCAzIEZlYiAyMDEyLCBKYWNvYnMgSm9yZGkgd3JvdGU6DQo+ID4gPiA+ID4gPiBIaSwNCj4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiBJIGFtIHdvbmRlcmluZyBob3cgR1BVIHNoYXJpbmcgY291bGQv
c2hvdWxkIGJlIGltcGxlbWVudGVkIGZvciB0aGUNCj4gWGVuIEh5cGVydmlzb3IuDQo+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gSSBoYXZlIGNvbWUgYWNyb3NzIHNldmVyYWwgcGFwZXJzIHRoYXQg
ZXhwbGFpbiBtYW55IHBvc3NpYmlsaXRpZXMgb24NCj4gR1BVIHNoYXJpbmcgZm9yIG11bHRpcGxl
IFZNcyBidXQgSSdtIG5vdCBzdXJlIHdpY2gNCj4gPiA+ID4gPiA+IG9uZSB3b3VsZCBiZSB0aGUg
YmVzdCBzb2x1dGlvbiBmb3IgWGVuLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEFQSSByZW1v
dGluZyAoZ2FsbGl1bTNEKSAoZXguIFhlbjNEIHByb2plY3QpDQo+ID4gPiA+ID4gPiBNZWRpYXRl
ZCBwYXNzdGhyb3VnaCAoTXVsdGlwbGV4aW5nIHRoZSBHUFUgd2hpbGUgbWFpbnRhaW5pbmcgdGhl
DQo+IGRpZmZlcmVudCBjb250ZXh0cy4pDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ2FuIHlv
dSBndXlzIGdpdmUgbWUgeW91ciBpZGVhIG9uIHRoZSBtYXR0ZXI/DQo+ID4gPiA+ID4gPiBQbGVh
c2UgYWxzbyBtZW50aW9uIGFueSBleGlzdGluZyBwcm9qZWN0cyB5b3Uga25vdyB0aGF0IGFyZSBy
ZWxhdGVkIHRvDQo+IHRoaXMgcHJvYmxlbS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE15IHBlcnNv
bmFsIG9waW5pb24gaXMgdGhhdCB0aGUgc2ltcGxlc3QgdGhpbmcgdG8gZG8gaXMgT3BlbkdMDQo+
ID4gPiA+ID4gcmVtb3RpbmcuIEdhbGxpdW0gcmVtb3RpbmcgY291bGQgYWxzbyBiZSBPSyBidXQg
Y29uc2lkZXJpbmcgdGhhdCBtYW55DQo+ID4gPiA+ID4gY2FyZHMgZG9uJ3QgaGF2ZSBHYWxsaXVt
IGRyaXZlcnMgd2Ugd291bGQgcHJvYmFibHkgZW5kIHVwIGRvaW5nIHR3bw0KPiA+ID4gPiA+IGNv
bnZlcnNpb25zIGluc3RlYWQgb2Ygb25lIChEaXJlY3RYLT5HYWxsaXVtIGluIHRoZSBndWVzdCwN
Cj4gPiA+ID4gPiBHYWxsaXVtLT5PcGVuR0wgaW4gZG9tMCkuDQo+ID4gPiA+ID4gTWVkaWF0ZWQg
cGFzc3Rocm91Z2ggaXMgdmVyeSBjYXJkIHNwZWNpZmljIHNvIEkgYW0gYWZyYWlkIHlvdSB3b3Vs
ZCBlbmQNCj4gPiA+ID4gPiB1cCB3cml0aW5nIHZpcnR1YWxpemF0aW9uIHNwZWNpZmljIGRyaXZl
cnMgZm9yIGFsbCB0aGUgY2FyZHMgeW91IHdhbnQgdG8NCj4gPiA+ID4gPiBzdXBwb3J0LiBOb3Qg
dG8gbWVudGlvbiB0aGF0IHlvdSBtaWdodCBuZWVkIHRvIGFjY2VzcyBzb21lIHZpZGVvY2FyZA0K
PiA+ID4gPiA+IGludGVyZmFjZXMgdGhhdCBvbiBOdmlkaWEgYXJlIG5vdCBkaXNjb3NlZC4NCj4g
PiA+ID4gPg0KPiA+ID4gPiA+IEkgYmVsaWV2ZSB0aGF0IHZpcnR1YWxib3ggYWxyZWFkeSBzdXBw
b3J0cyBPcGVuR0wgcmVtb3RpbmcgaW4gYSBkZWNlbnQNCj4gPiA+ID4gPiB3YXksIHNvIEkgd291
bGQgc3RhcnQgZnJvbSB0aGVyZSwgcG9ydCB3aGF0IHRoZXkgaGF2ZSB0byBYZW4sIGFuZA0KPiA+
ID4gPiA+IGltcHJvdmUgaXQuDQo+ID4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gSSB3b25kZXIg
aWYgU1BJQ0UgYWxyZWFkeSBzdXBwb3J0cyBPcGVuR0wgc3R1ZmYuLg0KPiA+ID4gPiBJIHRoaW5r
IGl0J3MgYXQgbGVhc3Qgc3VwcG9zZWQgdG8gYmUgYWJsZSB0byBzdXBwb3J0IE9wZW5HTC4NCj4g
PiA+ID4NCj4gPiA+ID4NCj4gKGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvYXJjaGl2ZXMv
c3BpY2UtZGV2ZWwvMjAxMS1Ob3ZlbWJlci8wMDYwMTguaHQNCj4gbWwpDQo+ID4gPg0KPiA+ID4g
Tm90IHlldCwgYnV0IEkgdGhpbmsgdGhhdCB0aGV5IGFyZSB3b3JraW5nIG9uIGl0LiBTdGlsbCB2
ZXJ5IGVhcmx5IGRheXMNCj4gPiA+IHRob3VnaC4NCj4gPiA+IEFsc28gaXQgd291bGQgb25seSB3
b3JrIHdpdGggSFZNIGd1ZXN0cywgd2hpbGUgaGF2aW5nIGEgcHJvcGVyIHhlbg0KPiA+ID4gZnJv
bnRlbmQvYmFja2VuZCBPcGVuR0wgcmVtb3RpbmcgZHJpdmVyIHBhaXIgd291bGQgd29yayBmb3Ig
Ym90aC4NCj4gPg0KPiA+IFllcC4NCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbzogaHR0cDovL3NvdXJj
ZWZvcmdlLm5ldC9wcm9qZWN0cy92bWdsLw0KPiA+DQo+ID4gIk9wZW5HTCBhcHBzIHJ1bm5pbmcg
aW5zaWRlIGEgVk0gdXNlIFZNR0wgdG8gb2J0YWluIGdyYXBoaWNzIGhhcmR3YXJlDQo+IGFjY2Vs
ZXJhdGlvbi4gVk1HTCBzdXBwb3J0cyBWTXdhcmUsIFhlbiBQViBhbmQgSFZNLCBxZW11LCBhbmQg
S1ZNIFZNczsNCj4gWDExLWJhc2VkIE9TIHN1Y2ggYXMgTGludXgsIEZyZWVCU0QgYW5kIE9wZW5T
b2xhcmlzOyBhbmQgQVRJLCBOdmlkaWEgYW5kIEludGVsDQo+IEdQVXMuICINCj4gPg0KPiANCj4g
QW5kIENocm9taXVtIG1pZ2h0IGhhdmUgc29tZXRoaW5nIHJlbGF0ZWQgYXN3ZWxsOg0KPiBodHRw
Oi8vY2hyb21pdW0uc291cmNlZm9yZ2UubmV0L2RvYy9pbmRleC5odG1sDQo+IA0KSGVsbG8sDQoN
CkFub3RoZXIgcmVsYXRlZCB3b3JrIGlzIGFzIGJlbG93Og0KaHR0cDovL2xpc3RzLmdudS5vcmcv
YXJjaGl2ZS9odG1sL3FlbXUtZGV2ZWwvMjAxMi0wMS9tc2cwMTAyNy5odG1sDQoNClNpbWlsYXIg
dG8gVk1HTCwgaXQgaXMgYW4gQVBJIHJlbW90aW5nIGFwcHJvYWNoIGJ1dCBub3QgYmFzZWQgb24g
Y2hyb21pdW0uIEFub3RoZXIgZGlmZmVyZW5jZSBpcyB0aGF0IGl0IGRvZXMgbm90IHJlcXVpcmUg
WCBzZXJ2ZXIgZXh0ZW5zaW9ucy4gSnVzdCBmb3IgeW91ciByZWZlcmVuY2UuIFRoYW5rcyENCg0K
PiANCj4gLS0gUGFzaQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20NCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVs
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Feb 14 23:52:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 23:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxS9v-0004kn-Jk; Tue, 14 Feb 2012 23:51:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxS9u-0004kg-HR
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 23:51:42 +0000
Received: from [85.158.139.83:42875] by server-6.bemta-5.messagelabs.com id
	83/57-27305-D83FA3F4; Tue, 14 Feb 2012 23:51:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329263500!15080725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTgwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 14 Feb 2012 23:51:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 23:51:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,420,1325462400"; d="scan'208";a="10696199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 23:50:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 23:50:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxS8r-00027F-C8;
	Tue, 14 Feb 2012 23:50:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxS8q-000178-S6;
	Tue, 14 Feb 2012 23:50:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11957-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 23:50:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11957: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11957 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11957/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 11955
 test-amd64-i386-xl-credit2    7 debian-install     fail in 11955 pass in 11957

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11944

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0ba87b95e80b
baseline version:
 xen                  9ad1e42c341b

------------------------------------------------------------
People who touched revisions under test:
  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>
  Julian Pidancet <julian.pidancet@gmail.com>
  Keir Fraser <keir@xen.org>
  Stefan Bader <stefan.bader@canonical.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhigang Wang <zhigang.x.wang@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                                 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=0ba87b95e80b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 0ba87b95e80b
+ branch=xen-unstable
+ revision=0ba87b95e80b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 0ba87b95e80b 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 25 changesets with 96 changes to 79 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Feb 14 23:52:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 14 Feb 2012 23:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxS9v-0004kn-Jk; Tue, 14 Feb 2012 23:51:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxS9u-0004kg-HR
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 23:51:42 +0000
Received: from [85.158.139.83:42875] by server-6.bemta-5.messagelabs.com id
	83/57-27305-D83FA3F4; Tue, 14 Feb 2012 23:51:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329263500!15080725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTgwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 14 Feb 2012 23:51:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2012 23:51:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,420,1325462400"; d="scan'208";a="10696199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 23:50:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 14 Feb 2012 23:50:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxS8r-00027F-C8;
	Tue, 14 Feb 2012 23:50:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxS8q-000178-S6;
	Tue, 14 Feb 2012 23:50:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11957-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 14 Feb 2012 23:50:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11957: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11957 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11957/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 11955
 test-amd64-i386-xl-credit2    7 debian-install     fail in 11955 pass in 11957

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11944

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-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-xl-win      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-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0ba87b95e80b
baseline version:
 xen                  9ad1e42c341b

------------------------------------------------------------
People who touched revisions under test:
  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>
  Julian Pidancet <julian.pidancet@gmail.com>
  Keir Fraser <keir@xen.org>
  Stefan Bader <stefan.bader@canonical.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhigang Wang <zhigang.x.wang@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                                 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=0ba87b95e80b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 0ba87b95e80b
+ branch=xen-unstable
+ revision=0ba87b95e80b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 0ba87b95e80b 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 25 changesets with 96 changes to 79 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 02:26:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 02:26: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.xensource.com>)
	id 1RxUZB-00049b-Pn; Wed, 15 Feb 2012 02:25:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RxUZA-00049W-H8
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 02:25:56 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329272696!56737862!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNTguMjUxLjE1Mi42NiA9PiA2MzUx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8048 invoked from network); 15 Feb 2012 02:24:56 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-3.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 02:24:56 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE00JNGXDR29@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:25:03 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE0021UXDFZW@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:25:03 +0800 (CST)
Received: from szxeml210-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHC78640; Wed,
	15 Feb 2012 10:25:01 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32)
	by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 10:24:56 +0800
Received: from h00166998 (10.166.80.196) by szxeml402-hub.china.huawei.com
	(10.82.67.32) with Microsoft SMTP Server id 14.1.323.3; Wed,
	15 Feb 2012 10:24:38 +0800
Date: Wed, 15 Feb 2012 10:24:37 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <1329135113.31256.77.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Message-id: <003001cceb88$f7302930$e5907b90$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczqSLOu+GXhqy2FQDaTjhFBiVJVSgBPpu0g
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Monday, February 13, 2012 8:12 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> 
> On Mon, 2012-02-13 at 05:47 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Olaf Hering [mailto:olaf@aepfle.de]
> > > Sent: Saturday, February 11, 2012 12:40 AM
> > > To: hongkaixing@huawei.com
> > > Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> > > hanweidong@huawei.com
> > > Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> > >
> > > On Thu, Feb 09, hongkaixing@huawei.com wrote:
> > >
> > > > xenpaging:close domU's event channel and free port
> > > >
> > > > Every domain (X86 64 bit)has 4096 event channels.In source code,
> > > > domU's event channel is allocated in mem_event_enable(),but just
> > > > unbind dom0's event channel in xenpaging_teardown().This bug will
> > > > result in that we can not use xenpaging after reopening it for 4096
> > > > times.We should free domU's event channel in mem_event_disable().so
> > > > that we can reuse the port.
> > >
> > > Does that fix a real bug?
> > >
> > > xenpaging_teardown() does both xc_mem_paging_disable() and
> > > xc_evtchn_unbind(). The former fails often because the domain is gone
> > > and so it doesnt even reach the function in mem_event.c.
> > > The latter is called unconditionally.
> >
> >    I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
> > Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
> > and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.
> 
> Perhaps I'm misunderstanding something and/or showing my ignorance about
> how xenpaging works but why does paging need a domU event channel
> anyway? Surely paging is transparent to the guest.
> 
> Or is this really a dom0<->Xen event channel which just appears to be
> assigned to the guest?

In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> 
> Who assigns this remote domain port? Shouldn't it either be closed when
> the dom0 end is closed or retained such that it can be reused each time
> instead of leaking?

  In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.

> 
> > so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
> > (28 = No space left on device): Internal error".Because there is no available free port for this domU.
> > Only the port's state is ECS_FREE,then it can be allocated by get_free_port();
> >
> >
> > >
> > > Also I would expect that once xenpaging exits the kernel driver does a
> > > cleanup of all used ports. I havent checked wether thats true.
> > >
> > > Olaf
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 02:26:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 02:26: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.xensource.com>)
	id 1RxUZB-00049b-Pn; Wed, 15 Feb 2012 02:25:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RxUZA-00049W-H8
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 02:25:56 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329272696!56737862!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNTguMjUxLjE1Mi42NiA9PiA2MzUx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8048 invoked from network); 15 Feb 2012 02:24:56 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-3.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 02:24:56 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE00JNGXDR29@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:25:03 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE0021UXDFZW@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:25:03 +0800 (CST)
Received: from szxeml210-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHC78640; Wed,
	15 Feb 2012 10:25:01 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32)
	by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 10:24:56 +0800
Received: from h00166998 (10.166.80.196) by szxeml402-hub.china.huawei.com
	(10.82.67.32) with Microsoft SMTP Server id 14.1.323.3; Wed,
	15 Feb 2012 10:24:38 +0800
Date: Wed, 15 Feb 2012 10:24:37 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <1329135113.31256.77.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Message-id: <003001cceb88$f7302930$e5907b90$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczqSLOu+GXhqy2FQDaTjhFBiVJVSgBPpu0g
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Monday, February 13, 2012 8:12 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> 
> On Mon, 2012-02-13 at 05:47 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Olaf Hering [mailto:olaf@aepfle.de]
> > > Sent: Saturday, February 11, 2012 12:40 AM
> > > To: hongkaixing@huawei.com
> > > Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> > > hanweidong@huawei.com
> > > Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> > >
> > > On Thu, Feb 09, hongkaixing@huawei.com wrote:
> > >
> > > > xenpaging:close domU's event channel and free port
> > > >
> > > > Every domain (X86 64 bit)has 4096 event channels.In source code,
> > > > domU's event channel is allocated in mem_event_enable(),but just
> > > > unbind dom0's event channel in xenpaging_teardown().This bug will
> > > > result in that we can not use xenpaging after reopening it for 4096
> > > > times.We should free domU's event channel in mem_event_disable().so
> > > > that we can reuse the port.
> > >
> > > Does that fix a real bug?
> > >
> > > xenpaging_teardown() does both xc_mem_paging_disable() and
> > > xc_evtchn_unbind(). The former fails often because the domain is gone
> > > and so it doesnt even reach the function in mem_event.c.
> > > The latter is called unconditionally.
> >
> >    I have tested whether the kernel driver does a cleanup of all used ports once xenpaging exits.
> > Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees dom0's event channel's port,
> > and changes its state to be ECS_FREE;but the remote domain(domU)'s port is still ECS_UNBOUND.
> 
> Perhaps I'm misunderstanding something and/or showing my ignorance about
> how xenpaging works but why does paging need a domU event channel
> anyway? Surely paging is transparent to the guest.
> 
> Or is this really a dom0<->Xen event channel which just appears to be
> assigned to the guest?

In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> 
> Who assigns this remote domain port? Shouldn't it either be closed when
> the dom0 end is closed or retained such that it can be reused each time
> instead of leaking?

  In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.

> 
> > so when each domU triggers 1024 times of xenpaging,it will fail of "Error initialising shared page
> > (28 = No space left on device): Internal error".Because there is no available free port for this domU.
> > Only the port's state is ECS_FREE,then it can be allocated by get_free_port();
> >
> >
> > >
> > > Also I would expect that once xenpaging exits the kernel driver does a
> > > cleanup of all used ports. I havent checked wether thats true.
> > >
> > > Olaf
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 02:35:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 02: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.xensource.com>)
	id 1RxUiI-0004K9-1I; Wed, 15 Feb 2012 02:35:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RxUiG-0004K0-0e
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 02:35:20 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329273218!5059328!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNTguMjUxLjE1Mi42NiA9PiA2MzUx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27195 invoked from network); 15 Feb 2012 02:34:00 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-16.tower-21.messagelabs.com with SMTP;
	15 Feb 2012 02:34:00 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE00JQWXS029@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:33:37 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE00CG8XS05T@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:33:36 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHC79374; Wed,
	15 Feb 2012 10:33:35 +0800
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 10:33:28 +0800
Received: from h00166998 (10.166.80.196) by szxeml419-hub.china.huawei.com
	(10.82.67.158) with Microsoft SMTP Server id 14.1.323.3; Wed,
	15 Feb 2012 10:33:36 +0800
Date: Wed, 15 Feb 2012 10:33:25 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120214211905.GA23069@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <003101cceb8a$318b9ff0$94a2dfd0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczrXk5MWmHpporoQXWxXJ8l+CFcDAAKrzPw
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<20120214205954.GA21776@aepfle.de> <20120214211905.GA23069@aepfle.de>
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, February 15, 2012 5:19 AM
> To: Hongkaixing
> Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> hanweidong@huawei.com
> Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> 
> On Tue, Feb 14, Olaf Hering wrote:
> 
> > xc: error: Error initialising shared page (28 = No space left on device): Internal error
> 
> After reading the code more carefully I now see that mem_event_enable()
> calls alloc_unbound_xen_event_channel() and stores it into
> med->xen_port. As Tim suggested, your patch should use this value
> instead of relying on the shared_page pointer.

Thanks for your advices.

And In your another mail, you have mentioned the problem like this:

xc: detail: xenpaging init
xc: detail: watching '/local/domain/1/memory/target-tot_pages'
xc: error: Error initialising shared page (28 = No space left on device): Internal error

Yes, I am sure it is the error we have met before!
> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 02:35:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 02: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.xensource.com>)
	id 1RxUiI-0004K9-1I; Wed, 15 Feb 2012 02:35:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RxUiG-0004K0-0e
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 02:35:20 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329273218!5059328!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNTguMjUxLjE1Mi42NiA9PiA2MzUx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27195 invoked from network); 15 Feb 2012 02:34:00 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-16.tower-21.messagelabs.com with SMTP;
	15 Feb 2012 02:34:00 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE00JQWXS029@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:33:37 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZE00CG8XS05T@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:33:36 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHC79374; Wed,
	15 Feb 2012 10:33:35 +0800
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 10:33:28 +0800
Received: from h00166998 (10.166.80.196) by szxeml419-hub.china.huawei.com
	(10.82.67.158) with Microsoft SMTP Server id 14.1.323.3; Wed,
	15 Feb 2012 10:33:36 +0800
Date: Wed, 15 Feb 2012 10:33:25 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120214211905.GA23069@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <003101cceb8a$318b9ff0$94a2dfd0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczrXk5MWmHpporoQXWxXJ8l+CFcDAAKrzPw
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<20120214205954.GA21776@aepfle.de> <20120214211905.GA23069@aepfle.de>
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
	free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, February 15, 2012 5:19 AM
> To: Hongkaixing
> Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> hanweidong@huawei.com
> Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> 
> On Tue, Feb 14, Olaf Hering wrote:
> 
> > xc: error: Error initialising shared page (28 = No space left on device): Internal error
> 
> After reading the code more carefully I now see that mem_event_enable()
> calls alloc_unbound_xen_event_channel() and stores it into
> med->xen_port. As Tim suggested, your patch should use this value
> instead of relying on the shared_page pointer.

Thanks for your advices.

And In your another mail, you have mentioned the problem like this:

xc: detail: xenpaging init
xc: detail: watching '/local/domain/1/memory/target-tot_pages'
xc: error: Error initialising shared page (28 = No space left on device): Internal error

Yes, I am sure it is the error we have met before!
> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 02:54:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 02: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.xensource.com>)
	id 1RxUzw-0004t0-PC; Wed, 15 Feb 2012 02:53:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RxUzv-0004sq-Gs
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 02:53:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329274407!14352653!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MzU4NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12999 invoked from network); 15 Feb 2012 02:53:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 02:53: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 q1F2rJ15008289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 02:53:21 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
	q1F2rIgU026637
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 02:53:19 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
	q1F2rIFL006346; Tue, 14 Feb 2012 20:53:18 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 14 Feb 2012 18:53:18 -0800
Date: Tue, 14 Feb 2012 18:53:14 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120214185314.5546a24e@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]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F3B1E21.0178,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] HYBRID: memory mapped IO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Guys,

ich_force_enable_hpet() in linux wants to do mmio. It calls ioremap_pte_range
to map phys addr to a VA. Xen then updates the PV dom0's L1 with
requested io attributes. I'm trying to figure how to do this for PV in
HVM container. I was hoping to update the EPT directly.

I was thinking of just doing guest_physmap_add_entry() but the mfn is not
going to be valid. Is there any other code path that will let me do this?

Another possiblity would be handle_mmio(). 

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 02:54:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 02: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.xensource.com>)
	id 1RxUzw-0004t0-PC; Wed, 15 Feb 2012 02:53:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RxUzv-0004sq-Gs
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 02:53:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329274407!14352653!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0MzU4NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12999 invoked from network); 15 Feb 2012 02:53:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 02:53: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 q1F2rJ15008289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 02:53:21 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
	q1F2rIgU026637
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 02:53:19 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
	q1F2rIFL006346; Tue, 14 Feb 2012 20:53:18 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 14 Feb 2012 18:53:18 -0800
Date: Tue, 14 Feb 2012 18:53:14 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120214185314.5546a24e@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]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F3B1E21.0178,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] HYBRID: memory mapped IO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Guys,

ich_force_enable_hpet() in linux wants to do mmio. It calls ioremap_pte_range
to map phys addr to a VA. Xen then updates the PV dom0's L1 with
requested io attributes. I'm trying to figure how to do this for PV in
HVM container. I was hoping to update the EPT directly.

I was thinking of just doing guest_physmap_add_entry() but the mfn is not
going to be valid. Is there any other code path that will let me do this?

Another possiblity would be handle_mmio(). 

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT9-0007Du-65; Wed, 15 Feb 2012 05:31:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT7-0007DY-Fb
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:53 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4429 invoked from network); 15 Feb 2012 05:30:39 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:39 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklW048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: adcb465964c5ea0f00077ce9837c633eca31ce2a
Message-Id: <adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:57 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0898 (UTC)
	FILETIME=[1C01D320:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 4 v2] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
      this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 321810c42d55 -r adcb465964c5 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -142,6 +142,32 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the backend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
@@ -239,6 +265,33 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the frontend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -400,11 +453,28 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00040201
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
+#else
+/*
+ * Maximum scatter/gather segments per request (header block only).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#endif
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -419,9 +489,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -429,11 +515,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -470,6 +567,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
diff -r 321810c42d55 -r adcb465964c5 xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT9-0007Du-65; Wed, 15 Feb 2012 05:31:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT7-0007DY-Fb
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:53 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4429 invoked from network); 15 Feb 2012 05:30:39 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:39 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklW048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: adcb465964c5ea0f00077ce9837c633eca31ce2a
Message-Id: <adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:57 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0898 (UTC)
	FILETIME=[1C01D320:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 4 v2] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
      this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 321810c42d55 -r adcb465964c5 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -142,6 +142,32 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the backend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
@@ -239,6 +265,33 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the frontend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -400,11 +453,28 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00040201
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
+#else
+/*
+ * Maximum scatter/gather segments per request (header block only).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#endif
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -419,9 +489,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -429,11 +515,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -470,6 +567,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
diff -r 321810c42d55 -r adcb465964c5 xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT7-0007Dd-PF; Wed, 15 Feb 2012 05:31:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT6-0007DX-O2
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:53 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4373 invoked from network); 15 Feb 2012 05:30:39 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:39 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklV048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 321810c42d556fb66e954a34c07fc28bae899918
Message-Id: <321810c42d556fb66e95.1329282416@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:56 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0882 (UTC)
	FILETIME=[1BFF6220:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 4 v2] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 2ecf6eaf5d86 -r 321810c42d55 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -123,12 +123,31 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -136,7 +155,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -180,10 +199,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "num-ring-pages" sized
+ *      list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -191,6 +220,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * num-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -208,12 +256,26 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     For full interoperability, block front and backends should publish
+ *     identical ring parameters, adjusted for unit differences, to the
+ *     XenStore nodes used in both schemes.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -231,20 +293,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -261,20 +329,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT7-0007Dd-PF; Wed, 15 Feb 2012 05:31:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT6-0007DX-O2
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:53 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4373 invoked from network); 15 Feb 2012 05:30:39 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:39 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklV048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 321810c42d556fb66e954a34c07fc28bae899918
Message-Id: <321810c42d556fb66e95.1329282416@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:56 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0882 (UTC)
	FILETIME=[1BFF6220:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 4 v2] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 2ecf6eaf5d86 -r 321810c42d55 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -123,12 +123,31 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -136,7 +155,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -180,10 +199,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "num-ring-pages" sized
+ *      list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -191,6 +220,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * num-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -208,12 +256,26 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     For full interoperability, block front and backends should publish
+ *     identical ring parameters, adjusted for unit differences, to the
+ *     XenStore nodes used in both schemes.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -231,20 +293,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -261,20 +329,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT5-0007DP-Cv; Wed, 15 Feb 2012 05:31:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT3-0007DK-OK
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:49 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4284 invoked from network); 15 Feb 2012 05:30:36 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:36 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklT048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 0e07382ca5fcaef46e962ee747dde2acc1a26a2d
Message-Id: <0e07382ca5fcaef46e96.1329282414@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:54 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0851 (UTC)
	FILETIME=[1BFAA730:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 4 v2] blkif.h: Miscelaneous style fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 0ba87b95e80b -r 0e07382ca5fc xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 13 17:26:08 2012 +0000
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXTB-0007ES-Lj; Wed, 15 Feb 2012 05:31:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT9-0007DW-Az
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:55 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4302 invoked from network); 15 Feb 2012 05:30:37 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:37 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklU048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 2ecf6eaf5d86d26b9f6f331a22f772bf12227dcb
Message-Id: <2ecf6eaf5d86d26b9f6f.1329282415@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:55 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0866 (UTC)
	FILETIME=[1BFCF120:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 4 v2] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  o Document the XenBus nodes used in this protocol.
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 0e07382ca5fc -r 2ecf6eaf5d86 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,253 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------ Backend Device Identification (PRIVATE) ------------------
+ *
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      A free formatted string providing sufficient information for the
+ *      backend driver to open the backing device.  (e.g. the path to the
+ *      file or block device representing the backing store.)
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-aligment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The native sector size, in bytes, of the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of its native
+ *      sector size ("sector-size").
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint32_t>
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ *      See docs/misc/vbd-interface.txt for details on the format of this
+ *      value.
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +304,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * command on a native device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +346,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +360,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT9-0007E1-Jf; Wed, 15 Feb 2012 05:31:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT8-0007DJ-2I
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:54 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4250 invoked from network); 15 Feb 2012 05:30:35 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:35 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklS048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:53 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0819 (UTC)
	FILETIME=[1BF5C530:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
	existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.

Changes in v2:

 patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
   o Mark backend device identification section as private to the
     backend driver.
   o Refer to docs/misc/vbd-interface.txt for the format of the
     virtual-device front-end node.
   o Correct field size for the virtual-device front-end node.

 patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
          ring extensions.):
   o Correct node names for the RedHat/Amazon multi-ring extension.  The
     previous patch mistakenly documented the now defunct FreeBSD extension.
   o Clarify the note on multi-page ring interoperability to indicate that
     identical ring parameters should be published to the XenStore for
     all supported schemes.

 v1 patch 4 (Deleted):
   o Remove patch that added the XEN_*_MAJOR definitions.

 patch 4 (blkif.h: Define and document the request number/size/segments
          extension.)
   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
     to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

--
Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXTB-0007ES-Lj; Wed, 15 Feb 2012 05:31:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT9-0007DW-Az
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:55 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4302 invoked from network); 15 Feb 2012 05:30:37 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:37 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklU048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 2ecf6eaf5d86d26b9f6f331a22f772bf12227dcb
Message-Id: <2ecf6eaf5d86d26b9f6f.1329282415@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:55 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0866 (UTC)
	FILETIME=[1BFCF120:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 4 v2] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  o Document the XenBus nodes used in this protocol.
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 0e07382ca5fc -r 2ecf6eaf5d86 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,253 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------ Backend Device Identification (PRIVATE) ------------------
+ *
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      A free formatted string providing sufficient information for the
+ *      backend driver to open the backing device.  (e.g. the path to the
+ *      file or block device representing the backing store.)
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-aligment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The native sector size, in bytes, of the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of its native
+ *      sector size ("sector-size").
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint32_t>
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ *      See docs/misc/vbd-interface.txt for details on the format of this
+ *      value.
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +304,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * command on a native device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +346,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +360,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT5-0007DP-Cv; Wed, 15 Feb 2012 05:31:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT3-0007DK-OK
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:49 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4284 invoked from network); 15 Feb 2012 05:30:36 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:36 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklT048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 0e07382ca5fcaef46e962ee747dde2acc1a26a2d
Message-Id: <0e07382ca5fcaef46e96.1329282414@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:54 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0851 (UTC)
	FILETIME=[1BFAA730:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 4 v2] blkif.h: Miscelaneous style fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 0ba87b95e80b -r 0e07382ca5fc xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 13 17:26:08 2012 +0000
+++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 05:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 05:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxXT9-0007E1-Jf; Wed, 15 Feb 2012 05:31:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxXT8-0007DJ-2I
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 05:31:54 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329283835!62887792!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4250 invoked from network); 15 Feb 2012 05:30:35 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 05:30:35 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 14 Feb 2012 22:31:46 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1F5VklS048474;
	Tue, 14 Feb 2012 22:31:46 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1329282413@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Tue, 14 Feb 2012 22:06:53 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 15 Feb 2012 05:31:46.0819 (UTC)
	FILETIME=[1BF5C530:01CCEBA3]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
	existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.

Changes in v2:

 patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
   o Mark backend device identification section as private to the
     backend driver.
   o Refer to docs/misc/vbd-interface.txt for the format of the
     virtual-device front-end node.
   o Correct field size for the virtual-device front-end node.

 patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
          ring extensions.):
   o Correct node names for the RedHat/Amazon multi-ring extension.  The
     previous patch mistakenly documented the now defunct FreeBSD extension.
   o Clarify the note on multi-page ring interoperability to indicate that
     identical ring parameters should be published to the XenStore for
     all supported schemes.

 v1 patch 4 (Deleted):
   o Remove patch that added the XEN_*_MAJOR definitions.

 patch 4 (blkif.h: Define and document the request number/size/segments
          extension.)
   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
     to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

--
Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 06:41:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 06: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.xensource.com>)
	id 1RxYXW-0000Kt-1C; Wed, 15 Feb 2012 06:40:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxYXU-0000Ko-Il
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 06:40:28 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329287958!61129059!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26534 invoked from network); 15 Feb 2012 06:39:19 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 06:39:19 -0000
Received: by vbbfq11 with SMTP id fq11so1228284vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 22:40:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=CYZ6hxqXPDY2PKKjAd5yffdkTG+iVBhaFT8PBZiJ2LY=;
	b=Psf9rJXeK+SpV45+GJ3dZvNAyZ7PkYca5O6wNMwXyFssNE2YEr6twiUfnX0UAkVOAo
	xLsP9LyykZaTs+3s5j9A8nLOViJXd3JqC1zV86TryC95ujp0pPtYoilDPmIBveVwstOB
	g2hAB+aRcSU9aBPZgtOcYW1eAW61LspyGY8Mo=
MIME-Version: 1.0
Received: by 10.52.176.104 with SMTP id ch8mr10382368vdc.99.1329288022885;
	Tue, 14 Feb 2012 22:40:22 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Tue, 14 Feb 2012 22:40:22 -0800 (PST)
In-Reply-To: <1329211517.31256.165.camel@zakaz.uk.xensource.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
Date: Wed, 15 Feb 2012 14:40:22 +0800
Message-ID: <CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5420820916944935237=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5420820916944935237==
Content-Type: multipart/alternative; boundary=20cf3071c7fa68849b04b8fafccc

--20cf3071c7fa68849b04b8fafccc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well, I have found the wrong code.
The macro DPRINTF  points to
#define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DETAIL,
0, _f, ## -a)
So is this Xen's private log system ? Where messages write via xc_report
and xc_report_error function?

Thank you.

On Tue, Feb 14, 2012 at 5:25 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

> On Tue, 2012-02-14 at 07:03 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:
> [...]
> > and there are three frequently used macro for logging:
> > #define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)
>
> Syslog is a standard Unix function (SUSv2 and/or POSIX IIRC) and not
> something specific to Xen. Google or "man -k" should be able to find you
> more details of this and related functions.
>
> > Who can tell me which file match these log type above? Thank you.
>
> The final location will depend somewhat on your distro's configuration,
> it's likely to be somewhere under /var/log. A distro specific list or
> forum would be a more appropriate place to pursue this.
>
> Ian.
>
>
>
>


--=20
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3071c7fa68849b04b8fafccc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well, I have found the wrong code.<div>The macro DPRINTF=C2=A0 points to</d=
iv><div>#define DPRINTF(_f, _a...) xc_report(xch, xch-&gt;error_handler, XT=
L_DETAIL, 0, _f, ## -a)</div><div>So is this Xen&#39;s private log system ?=
 Where messages write via xc_report and xc_report_error function?</div>
<div><br></div><div>Thank you.<br><br><div class=3D"gmail_quote">On Tue, Fe=
b 14, 2012 at 5:25 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto=
:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, 2012-02-14 at 07:03 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:<br>
[...]<br>
<div class=3D"im">&gt; and there are three frequently used macro for loggin=
g:<br>
&gt; #define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)<br>
<br>
</div>Syslog is a standard Unix function (SUSv2 and/or POSIX IIRC) and not<=
br>
something specific to Xen. Google or &quot;man -k&quot; should be able to f=
ind you<br>
more details of this and related functions.<br>
<div class=3D"im"><br>
&gt; Who can tell me which file match these log type above? Thank you.<br>
<br>
</div>The final location will depend somewhat on your distro&#39;s configur=
ation,<br>
it&#39;s likely to be somewhere under /var/log. A distro specific list or<b=
r>
forum would be a more appropriate place to pursue this.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Chunqi Li<br>Department of Computer Science<br>School of EECS<br>Peking U=
niversity<br>Beijing, China<br>
</div>

--20cf3071c7fa68849b04b8fafccc--


--===============5420820916944935237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5420820916944935237==--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 06:41:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 06: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.xensource.com>)
	id 1RxYXW-0000Kt-1C; Wed, 15 Feb 2012 06:40:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxYXU-0000Ko-Il
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 06:40:28 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329287958!61129059!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26534 invoked from network); 15 Feb 2012 06:39:19 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 06:39:19 -0000
Received: by vbbfq11 with SMTP id fq11so1228284vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 14 Feb 2012 22:40:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=CYZ6hxqXPDY2PKKjAd5yffdkTG+iVBhaFT8PBZiJ2LY=;
	b=Psf9rJXeK+SpV45+GJ3dZvNAyZ7PkYca5O6wNMwXyFssNE2YEr6twiUfnX0UAkVOAo
	xLsP9LyykZaTs+3s5j9A8nLOViJXd3JqC1zV86TryC95ujp0pPtYoilDPmIBveVwstOB
	g2hAB+aRcSU9aBPZgtOcYW1eAW61LspyGY8Mo=
MIME-Version: 1.0
Received: by 10.52.176.104 with SMTP id ch8mr10382368vdc.99.1329288022885;
	Tue, 14 Feb 2012 22:40:22 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Tue, 14 Feb 2012 22:40:22 -0800 (PST)
In-Reply-To: <1329211517.31256.165.camel@zakaz.uk.xensource.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
Date: Wed, 15 Feb 2012 14:40:22 +0800
Message-ID: <CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5420820916944935237=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5420820916944935237==
Content-Type: multipart/alternative; boundary=20cf3071c7fa68849b04b8fafccc

--20cf3071c7fa68849b04b8fafccc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well, I have found the wrong code.
The macro DPRINTF  points to
#define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DETAIL,
0, _f, ## -a)
So is this Xen's private log system ? Where messages write via xc_report
and xc_report_error function?

Thank you.

On Tue, Feb 14, 2012 at 5:25 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

> On Tue, 2012-02-14 at 07:03 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:
> [...]
> > and there are three frequently used macro for logging:
> > #define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)
>
> Syslog is a standard Unix function (SUSv2 and/or POSIX IIRC) and not
> something specific to Xen. Google or "man -k" should be able to find you
> more details of this and related functions.
>
> > Who can tell me which file match these log type above? Thank you.
>
> The final location will depend somewhat on your distro's configuration,
> it's likely to be somewhere under /var/log. A distro specific list or
> forum would be a more appropriate place to pursue this.
>
> Ian.
>
>
>
>


--=20
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3071c7fa68849b04b8fafccc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well, I have found the wrong code.<div>The macro DPRINTF=C2=A0 points to</d=
iv><div>#define DPRINTF(_f, _a...) xc_report(xch, xch-&gt;error_handler, XT=
L_DETAIL, 0, _f, ## -a)</div><div>So is this Xen&#39;s private log system ?=
 Where messages write via xc_report and xc_report_error function?</div>
<div><br></div><div>Thank you.<br><br><div class=3D"gmail_quote">On Tue, Fe=
b 14, 2012 at 5:25 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto=
:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, 2012-02-14 at 07:03 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:<br>
[...]<br>
<div class=3D"im">&gt; and there are three frequently used macro for loggin=
g:<br>
&gt; #define DPRINTF(_f, _a...) syslog(LOG_INFO, _f, ##_a)<br>
<br>
</div>Syslog is a standard Unix function (SUSv2 and/or POSIX IIRC) and not<=
br>
something specific to Xen. Google or &quot;man -k&quot; should be able to f=
ind you<br>
more details of this and related functions.<br>
<div class=3D"im"><br>
&gt; Who can tell me which file match these log type above? Thank you.<br>
<br>
</div>The final location will depend somewhat on your distro&#39;s configur=
ation,<br>
it&#39;s likely to be somewhere under /var/log. A distro specific list or<b=
r>
forum would be a more appropriate place to pursue this.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Chunqi Li<br>Department of Computer Science<br>School of EECS<br>Peking U=
niversity<br>Beijing, China<br>
</div>

--20cf3071c7fa68849b04b8fafccc--


--===============5420820916944935237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5420820916944935237==--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 06:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 06:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxYim-0000oH-8z; Wed, 15 Feb 2012 06:52:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxYik-0000oC-RD
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 06:52:07 +0000
Received: from [85.158.139.83:45528] by server-2.bemta-5.messagelabs.com id
	73/FC-20263-5165B3F4; Wed, 15 Feb 2012 06:52:05 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329288723!7691607!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9706 invoked from network); 15 Feb 2012 06:52:04 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 06:52:04 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1F6p7N9099876
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 14 Feb 2012 23:51:11 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120214135611.GA21610@andromeda.dapyr.net>
Date: Tue, 14 Feb 2012 23:51:15 -0700
Message-Id: <A613FAB3-22DF-458F-81D6-A6590900F538@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
	<20120214135611.GA21610@andromeda.dapyr.net>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 14 Feb 2012 23:51:14 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 14, 2012, at 6:56 AM, Konrad Rzeszutek Wilk wrote:

> > > The state is a bit embarrassing on the BSD side.  FreeBSD has had a
> > > multi-page ring extension since October of 2010.  Unfortunately, I wrote
> > > this extension before stumbling upon the Citrix blkif patch or the
> > > extension being used on EC2.  It is closest to the EC2 implementation,
> > > but not quite compatible.  The saving grace is that I don't know of any
> > > deployments of this back-end outside of Spectra, and we have not shipped
> > > it to customers, so I plan to upstream block front and back drivers that
>
> Excellent <crosses out another TODO on the "get done at some point list">
>
> > > only implement the Citrix and EC2 style extension once blkif.h settles.  A
>
> So what is the Red Hat version of this extension? Where can I find it?
> Is it in the 2.6.18 hg tree?

The RedHat distribution on EC2 seems to be running a derivation of
the patch described in this thread:

    http://xen.1045712.n5.nabble.com/PATCH-multi-page-blkfront-blkback-patch-td2527534.html

However, the EC2 backend additionally publishes "max-ring-pages"
as described in my changes to blkif.h.

You can review the FreeBSD implementation of both extensions in the
latest versions of blkfront and back here:

http://svnweb.freebsd.org/base/head/sys/dev/xen/

--
Justin





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 06:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 06:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxYim-0000oH-8z; Wed, 15 Feb 2012 06:52:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxYik-0000oC-RD
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 06:52:07 +0000
Received: from [85.158.139.83:45528] by server-2.bemta-5.messagelabs.com id
	73/FC-20263-5165B3F4; Wed, 15 Feb 2012 06:52:05 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329288723!7691607!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9706 invoked from network); 15 Feb 2012 06:52:04 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 06:52:04 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1F6p7N9099876
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 14 Feb 2012 23:51:11 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120214135611.GA21610@andromeda.dapyr.net>
Date: Tue, 14 Feb 2012 23:51:15 -0700
Message-Id: <A613FAB3-22DF-458F-81D6-A6590900F538@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
	<20120214135611.GA21610@andromeda.dapyr.net>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 14 Feb 2012 23:51:14 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 14, 2012, at 6:56 AM, Konrad Rzeszutek Wilk wrote:

> > > The state is a bit embarrassing on the BSD side.  FreeBSD has had a
> > > multi-page ring extension since October of 2010.  Unfortunately, I wrote
> > > this extension before stumbling upon the Citrix blkif patch or the
> > > extension being used on EC2.  It is closest to the EC2 implementation,
> > > but not quite compatible.  The saving grace is that I don't know of any
> > > deployments of this back-end outside of Spectra, and we have not shipped
> > > it to customers, so I plan to upstream block front and back drivers that
>
> Excellent <crosses out another TODO on the "get done at some point list">
>
> > > only implement the Citrix and EC2 style extension once blkif.h settles.  A
>
> So what is the Red Hat version of this extension? Where can I find it?
> Is it in the 2.6.18 hg tree?

The RedHat distribution on EC2 seems to be running a derivation of
the patch described in this thread:

    http://xen.1045712.n5.nabble.com/PATCH-multi-page-blkfront-blkback-patch-td2527534.html

However, the EC2 backend additionally publishes "max-ring-pages"
as described in my changes to blkif.h.

You can review the FreeBSD implementation of both extensions in the
latest versions of blkfront and back here:

http://svnweb.freebsd.org/base/head/sys/dev/xen/

--
Justin





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 07:23:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 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.xensource.com>)
	id 1RxZD4-0001oA-5H; Wed, 15 Feb 2012 07:23:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxZD2-0001nT-17
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 07:23:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329290596!13249202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTgwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14609 invoked from network); 15 Feb 2012 07:23:17 -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;
	15 Feb 2012 07:23:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10698773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:23:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:23:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxZCt-0005XR-UY;
	Wed, 15 Feb 2012 07:23:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxZCt-00037o-Hi;
	Wed, 15 Feb 2012 07:23:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11959-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 07:23:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11959: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11959 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11959/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 11955
 test-amd64-i386-xl-winxpsp3-vcpus1  9 guest-localmigrate    fail pass in 11957
 test-amd64-i386-xl-credit2    7 debian-install     fail in 11955 pass in 11959
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore  fail in 11957 pass in 11959

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11957

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 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
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11955 never pass

version targeted for testing:
 xen                  0ba87b95e80b
baseline version:
 xen                  0ba87b95e80b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 07:23:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 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.xensource.com>)
	id 1RxZD4-0001oA-5H; Wed, 15 Feb 2012 07:23:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxZD2-0001nT-17
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 07:23:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329290596!13249202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTgwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14609 invoked from network); 15 Feb 2012 07:23:17 -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;
	15 Feb 2012 07:23:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10698773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:23:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:23:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxZCt-0005XR-UY;
	Wed, 15 Feb 2012 07:23:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxZCt-00037o-Hi;
	Wed, 15 Feb 2012 07:23:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11959-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 07:23:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11959: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11959 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11959/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 11955
 test-amd64-i386-xl-winxpsp3-vcpus1  9 guest-localmigrate    fail pass in 11957
 test-amd64-i386-xl-credit2    7 debian-install     fail in 11955 pass in 11959
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore  fail in 11957 pass in 11959

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11957

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 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
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11955 never pass

version targeted for testing:
 xen                  0ba87b95e80b
baseline version:
 xen                  0ba87b95e80b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 08:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 08:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxa0A-0003qe-L7; Wed, 15 Feb 2012 08:14: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 1Rxa09-0003qZ-Dw
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 08:14:09 +0000
Received: from [85.158.139.83:65265] by server-2.bemta-5.messagelabs.com id
	11/D4-20263-0596B3F4; Wed, 15 Feb 2012 08:14:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329293647!15128218!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23138 invoked from network); 15 Feb 2012 08:14:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 08:14:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 08:14:06 +0000
Message-Id: <4F3B775B0200007800073180@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 08:14:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>  patch 4 (blkif.h: Define and document the request number/size/segments
>           extension.)
>    o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version

Why? It got bumped very recently to 0x040200, your change could
well go under that same version. (Which is not to say that I'm now
suddenly agreeing to stuff under io/ being controlled by this).

>      to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 08:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 08:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxa0A-0003qe-L7; Wed, 15 Feb 2012 08:14: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 1Rxa09-0003qZ-Dw
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 08:14:09 +0000
Received: from [85.158.139.83:65265] by server-2.bemta-5.messagelabs.com id
	11/D4-20263-0596B3F4; Wed, 15 Feb 2012 08:14:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329293647!15128218!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23138 invoked from network); 15 Feb 2012 08:14:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 08:14:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 08:14:06 +0000
Message-Id: <4F3B775B0200007800073180@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 08:14:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329282413@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>  patch 4 (blkif.h: Define and document the request number/size/segments
>           extension.)
>    o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version

Why? It got bumped very recently to 0x040200, your change could
well go under that same version. (Which is not to say that I'm now
suddenly agreeing to stuff under io/ being controlled by this).

>      to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 08:33:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 08:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxaIC-0004M3-Bk; Wed, 15 Feb 2012 08:32:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxaIB-0004Lv-Ro
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 08:32:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329294761!9872475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTgwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18843 invoked from network); 15 Feb 2012 08:32:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 08:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10700297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 08:32:38 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 08:32:38 +0000
Message-ID: <1329294758.26412.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= "<Chunqi Li>" <yzt356@gmail.com>
Date: Wed, 15 Feb 2012 08:32:38 +0000
In-Reply-To: <CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
	<CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

UGxlYXNlIGRvIG5vdCB0b3AgcG9zdC4gaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL0Fza2luZ1hl
bkRldmVsUXVlc3Rpb25zCgpPbiBXZWQsIDIwMTItMDItMTUgYXQgMDY6NDAgKzAwMDAsIOadjuaY
peWlhyB3cm90ZToKPiBXZWxsLCBJIGhhdmUgZm91bmQgdGhlIHdyb25nIGNvZGUuCj4gVGhlIG1h
Y3JvIERQUklOVEYgIHBvaW50cyB0bwo+ICNkZWZpbmUgRFBSSU5URihfZiwgX2EuLi4pIHhjX3Jl
cG9ydCh4Y2gsIHhjaC0+ZXJyb3JfaGFuZGxlciwKPiBYVExfREVUQUlMLCAwLCBfZiwgIyMgLWEp
Cj4gU28gaXMgdGhpcyBYZW4ncyBwcml2YXRlIGxvZyBzeXN0ZW0gPyBXaGVyZSBtZXNzYWdlcyB3
cml0ZSB2aWEKPiB4Y19yZXBvcnQgYW5kIHhjX3JlcG9ydF9lcnJvciBmdW5jdGlvbj8KCllvdSBz
aG91bGQgaGF2ZSBiZWVuIGFibGUgdG8gZmluZCB0aGVzZSBmdW5jdGlvbnMgYnkgdXNpbmcgImdy
ZXAiIG9yCm90aGVyIHNpbWlsYXIgdG9vbHMgKGhpbnQ6IGxvb2sgdW5kZXIgdG9vbHMvbGlieGMp
LgoKSGFkIHlvdSBkb25lIHNvIHlvdSB3b3VsZCBoYXZlIGZvdW5kIHRoYXQgdGhleSB1c2UgdGhl
IHh0bCBsb2dnZXIKaW5mcmFzdHJ1Y3R1cmUuIHhjaC0+ZXJyb3JfaGFuZGxlciBpcyB0aGUgbG9n
Z2VyIHBhc3NlZCB0bwp4Y19pbnRlcmZhY2Vfb3BlbigpLCB0aGUgYmVoYXZpb3VyIG9mIHdoaWNo
IGlzIGRvY3VtZW50ZWQgaW4gdGhlIGhlYWRlci4KCklhbi4KCgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 15 08:33:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 08:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxaIC-0004M3-Bk; Wed, 15 Feb 2012 08:32:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxaIB-0004Lv-Ro
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 08:32:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329294761!9872475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTgwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18843 invoked from network); 15 Feb 2012 08:32:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 08:32:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10700297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 08:32:38 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 08:32:38 +0000
Message-ID: <1329294758.26412.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: =?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= "<Chunqi Li>" <yzt356@gmail.com>
Date: Wed, 15 Feb 2012 08:32:38 +0000
In-Reply-To: <CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
	<CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

UGxlYXNlIGRvIG5vdCB0b3AgcG9zdC4gaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL0Fza2luZ1hl
bkRldmVsUXVlc3Rpb25zCgpPbiBXZWQsIDIwMTItMDItMTUgYXQgMDY6NDAgKzAwMDAsIOadjuaY
peWlhyB3cm90ZToKPiBXZWxsLCBJIGhhdmUgZm91bmQgdGhlIHdyb25nIGNvZGUuCj4gVGhlIG1h
Y3JvIERQUklOVEYgIHBvaW50cyB0bwo+ICNkZWZpbmUgRFBSSU5URihfZiwgX2EuLi4pIHhjX3Jl
cG9ydCh4Y2gsIHhjaC0+ZXJyb3JfaGFuZGxlciwKPiBYVExfREVUQUlMLCAwLCBfZiwgIyMgLWEp
Cj4gU28gaXMgdGhpcyBYZW4ncyBwcml2YXRlIGxvZyBzeXN0ZW0gPyBXaGVyZSBtZXNzYWdlcyB3
cml0ZSB2aWEKPiB4Y19yZXBvcnQgYW5kIHhjX3JlcG9ydF9lcnJvciBmdW5jdGlvbj8KCllvdSBz
aG91bGQgaGF2ZSBiZWVuIGFibGUgdG8gZmluZCB0aGVzZSBmdW5jdGlvbnMgYnkgdXNpbmcgImdy
ZXAiIG9yCm90aGVyIHNpbWlsYXIgdG9vbHMgKGhpbnQ6IGxvb2sgdW5kZXIgdG9vbHMvbGlieGMp
LgoKSGFkIHlvdSBkb25lIHNvIHlvdSB3b3VsZCBoYXZlIGZvdW5kIHRoYXQgdGhleSB1c2UgdGhl
IHh0bCBsb2dnZXIKaW5mcmFzdHJ1Y3R1cmUuIHhjaC0+ZXJyb3JfaGFuZGxlciBpcyB0aGUgbG9n
Z2VyIHBhc3NlZCB0bwp4Y19pbnRlcmZhY2Vfb3BlbigpLCB0aGUgYmVoYXZpb3VyIG9mIHdoaWNo
IGlzIGRvY3VtZW50ZWQgaW4gdGhlIGhlYWRlci4KCklhbi4KCgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:19:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09: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.xensource.com>)
	id 1Rxb0V-0005Dv-CN; Wed, 15 Feb 2012 09:18:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rxb0U-0005Ai-5T
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:18:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329297507!13377333!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28482 invoked from network); 15 Feb 2012 09:18:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 09:18:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329297506; l=650;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BZavXv85llqitJQFKWJcsvfRgR8=;
	b=ejl6/6dLEYyjd7XD3pwHTP1hV0fxr58Cxd9Psj7obDpQp1cCLVT8IaO5iLE5k87XGla
	+GcxAnnT1oDZSspdcop0cv5fZMs6uroMmgj5HHXo7KKNRQcTToYzH9/XebKX7E3QAcdR9
	thYo6sh0F4uVf4/mvRfFAC5/ldqULMak9b4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (jimi mo15) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U07189o1F8OZuG ;
	Wed, 15 Feb 2012 10:18:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 383F418637; Wed, 15 Feb 2012 10:18:07 +0100 (CET)
Date: Wed, 15 Feb 2012 10:18:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215091806.GA6646@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
	<d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
	<20120214214313.GA25605@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120214214313.GA25605@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Olaf Hering wrote:

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> 
> > Those are the kinds of errors I was getting until I finished my patch.
> > Basically, the p2m gets confused and returns p2m_mmio_dm as the type for
> > anything it doesn't understand. If you end up giving my patch a spin, let
> > me know if it gets you past that hump.
> 
> No, it does not work for me, still EINVAL during mapping.

And this also happens with a recent system:

processor       : 2
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 5
model name      : AMD Phenom(tm) II N830 Triple-Core Processor
stepping        : 3
cpu MHz         : 2094.846


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:19:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09: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.xensource.com>)
	id 1Rxb0V-0005Dv-CN; Wed, 15 Feb 2012 09:18:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rxb0U-0005Ai-5T
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:18:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329297507!13377333!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28482 invoked from network); 15 Feb 2012 09:18:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 09:18:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329297506; l=650;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BZavXv85llqitJQFKWJcsvfRgR8=;
	b=ejl6/6dLEYyjd7XD3pwHTP1hV0fxr58Cxd9Psj7obDpQp1cCLVT8IaO5iLE5k87XGla
	+GcxAnnT1oDZSspdcop0cv5fZMs6uroMmgj5HHXo7KKNRQcTToYzH9/XebKX7E3QAcdR9
	thYo6sh0F4uVf4/mvRfFAC5/ldqULMak9b4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (jimi mo15) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U07189o1F8OZuG ;
	Wed, 15 Feb 2012 10:18:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 383F418637; Wed, 15 Feb 2012 10:18:07 +0100 (CET)
Date: Wed, 15 Feb 2012 10:18:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215091806.GA6646@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
	<d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
	<20120214214313.GA25605@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120214214313.GA25605@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, Olaf Hering wrote:

> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> 
> > Those are the kinds of errors I was getting until I finished my patch.
> > Basically, the p2m gets confused and returns p2m_mmio_dm as the type for
> > anything it doesn't understand. If you end up giving my patch a spin, let
> > me know if it gets you past that hump.
> 
> No, it does not work for me, still EINVAL during mapping.

And this also happens with a recent system:

processor       : 2
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 5
model name      : AMD Phenom(tm) II N830 Triple-Core Processor
stepping        : 3
cpu MHz         : 2094.846


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:25:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxb6Y-0005Ol-79; Wed, 15 Feb 2012 09:24:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rxb6W-0005OZ-SW
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:24:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329297881!12359524!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6075 invoked from network); 15 Feb 2012 09:24:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 15 Feb 2012 09:24:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329297881; l=1398;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5uCEZMHU8rW/xLlX/iGi1BmJl68=;
	b=H5Bgwv9nCAaAe17V6mLIkA9vYIrTqNtA8Vtt6q0Dqo4w2Kr5oh0zoH/xPdUsOkFg4Gy
	8ehY4oBjw4WS4ih9nH+kxxy6VHUyuvyU5tXE7LwOG2BJEFsGYTSE7MhXwmt80TLF6rJPa
	4miU19hDXzgIgB5FD6493A8dFRTrzyqFBoE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (klopstock mo50) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z0492do1F8TkMA
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:24:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id BE92718632
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:24:14 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 07bc9ce2378e9271405b6a9f5088da63805bcd2a
Message-Id: <07bc9ce2378e9271405b.1329297853@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 15 Feb 2012 10:24:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl: fix xl create/cpupool-create -f help output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329297824 -3600
# Node ID 07bc9ce2378e9271405b6a9f5088da63805bcd2a
# Parent  9ad1e42c341bc78463b6f6610a6300f75b535fbb
xl: fix xl create/cpupool-create -f help output

xl create -f domU.cfg does not need an equal sign.
This applies also to xl cpupool-create.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9ad1e42c341b -r 07bc9ce2378e tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -25,7 +25,7 @@ struct cmd_spec cmd_table[] = {
       "-h                      Print this help.\n"
       "-p                      Leave the domain paused after it is created.\n"
       "-c                      Connect to the console after the domain is created.\n"
-      "-f=FILE, --defconfig=FILE\n                     Use the given configuration file.\n"
+      "-f FILE, --defconfig=FILE\n                     Use the given configuration file.\n"
       "-q, --quiet             Quiet.\n"
       "-n, --dryrun            Dry run - prints the resulting configuration\n"
       "                         (deprecated in favour of global -N option).\n"
@@ -357,7 +357,7 @@ struct cmd_spec cmd_table[] = {
       "Create a CPU pool based an ConfigFile",
       "[options] <ConfigFile> [vars]",
       "-h, --help                   Print this help.\n"
-      "-f=FILE, --defconfig=FILE    Use the given configuration file.\n"
+      "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
       "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
       "                              (deprecated in favour of global -N option)."
     },

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:25:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09:25:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxb6Y-0005Ol-79; Wed, 15 Feb 2012 09:24:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rxb6W-0005OZ-SW
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:24:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329297881!12359524!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6075 invoked from network); 15 Feb 2012 09:24:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 15 Feb 2012 09:24:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329297881; l=1398;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5uCEZMHU8rW/xLlX/iGi1BmJl68=;
	b=H5Bgwv9nCAaAe17V6mLIkA9vYIrTqNtA8Vtt6q0Dqo4w2Kr5oh0zoH/xPdUsOkFg4Gy
	8ehY4oBjw4WS4ih9nH+kxxy6VHUyuvyU5tXE7LwOG2BJEFsGYTSE7MhXwmt80TLF6rJPa
	4miU19hDXzgIgB5FD6493A8dFRTrzyqFBoE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (klopstock mo50) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z0492do1F8TkMA
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:24:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id BE92718632
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:24:14 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 07bc9ce2378e9271405b6a9f5088da63805bcd2a
Message-Id: <07bc9ce2378e9271405b.1329297853@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 15 Feb 2012 10:24:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl: fix xl create/cpupool-create -f help output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329297824 -3600
# Node ID 07bc9ce2378e9271405b6a9f5088da63805bcd2a
# Parent  9ad1e42c341bc78463b6f6610a6300f75b535fbb
xl: fix xl create/cpupool-create -f help output

xl create -f domU.cfg does not need an equal sign.
This applies also to xl cpupool-create.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9ad1e42c341b -r 07bc9ce2378e tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -25,7 +25,7 @@ struct cmd_spec cmd_table[] = {
       "-h                      Print this help.\n"
       "-p                      Leave the domain paused after it is created.\n"
       "-c                      Connect to the console after the domain is created.\n"
-      "-f=FILE, --defconfig=FILE\n                     Use the given configuration file.\n"
+      "-f FILE, --defconfig=FILE\n                     Use the given configuration file.\n"
       "-q, --quiet             Quiet.\n"
       "-n, --dryrun            Dry run - prints the resulting configuration\n"
       "                         (deprecated in favour of global -N option).\n"
@@ -357,7 +357,7 @@ struct cmd_spec cmd_table[] = {
       "Create a CPU pool based an ConfigFile",
       "[options] <ConfigFile> [vars]",
       "-h, --help                   Print this help.\n"
-      "-f=FILE, --defconfig=FILE    Use the given configuration file.\n"
+      "-f FILE, --defconfig=FILE    Use the given configuration file.\n"
       "-n, --dryrun                 Dry run - prints the resulting configuration.\n"
       "                              (deprecated in favour of global -N option)."
     },

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:28:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxb9G-0005Uy-P3; Wed, 15 Feb 2012 09:27:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxb9F-0005Uc-D3
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329298051!8798926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18459 invoked from network); 15 Feb 2012 09:27:31 -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;
	15 Feb 2012 09:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10703634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 09:27:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 09:27:31 +0000
Message-ID: <1329298049.31256.277.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hongkaixing <hongkaixing@huawei.com>
Date: Wed, 15 Feb 2012 09:27:29 +0000
In-Reply-To: <003001cceb88$f7302930$e5907b90$@com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	'Olaf Hering' <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > how xenpaging works but why does paging need a domU event channel
> > anyway? Surely paging is transparent to the guest.
> > 
> > Or is this really a dom0<->Xen event channel which just appears to be
> > assigned to the guest?
> 
> In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
[...]
> > Who assigns this remote domain port? Shouldn't it either be closed when
> > the dom0 end is closed or retained such that it can be reused each time
> > instead of leaking?
> 
>   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.

The two ends of that event channel are actually dom0 and Xen, because
chn->xen_consumer is not NULL, even though the Xen end does live in the
domU evtchn address space. It is not exactly dom0 and domU as you
suggest, which is where my confused question arose.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:28:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09:28:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxb9G-0005Uy-P3; Wed, 15 Feb 2012 09:27:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxb9F-0005Uc-D3
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329298051!8798926!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18459 invoked from network); 15 Feb 2012 09:27:31 -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;
	15 Feb 2012 09:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10703634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 09:27:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 09:27:31 +0000
Message-ID: <1329298049.31256.277.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hongkaixing <hongkaixing@huawei.com>
Date: Wed, 15 Feb 2012 09:27:29 +0000
In-Reply-To: <003001cceb88$f7302930$e5907b90$@com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	'Olaf Hering' <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > how xenpaging works but why does paging need a domU event channel
> > anyway? Surely paging is transparent to the guest.
> > 
> > Or is this really a dom0<->Xen event channel which just appears to be
> > assigned to the guest?
> 
> In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
[...]
> > Who assigns this remote domain port? Shouldn't it either be closed when
> > the dom0 end is closed or retained such that it can be reused each time
> > instead of leaking?
> 
>   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.

The two ends of that event channel are actually dom0 and Xen, because
chn->xen_consumer is not NULL, even though the Xen end does live in the
domU evtchn address space. It is not exactly dom0 and domU as you
suggest, which is where my confused question arose.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:43:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09:43:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxbNw-0005jo-9K; Wed, 15 Feb 2012 09:42:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxbNu-0005jg-LG
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:42:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329298959!13434238!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15358 invoked from network); 15 Feb 2012 09:42:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 09:42:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329298959; l=1151;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=m1eJRN6vmCO5DxTyzAI3JiZByLA=;
	b=TO0V5uOOpJSfojkjGUK/sPkaU3CD2Zft9wEZ2npsPzhs3NQzDw/2ZcsKCN7x9jqcw2p
	ZDOZqUmm5Djy/2cKHDYX71q1wM/F4bGcoJgxmNWiAuWVh63buMfO5zxDhOm9bkBzlYUKG
	uCp6wEL7BrE7TlAtRgOye4jzLlsX0v+22S8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (jimi mo7) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6023c2o1F8Rj9m
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:42:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4F23518632
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:42:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f
Message-Id: <5fb2aa61197db9676c11.1329298936@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 15 Feb 2012 10:42:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: fix gfx_passthru string
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329298895 -3600
# Node ID 5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f
# Parent  07bc9ce2378e9271405b6a9f5088da63805bcd2a
xl.cfg: fix gfx_passthru string

Use correct string for gfx_passthru, and fix comment typo in xmexample.hvm

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 07bc9ce2378e -r 5fb2aa61197d docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -820,7 +820,7 @@ certainly belong in a more appropriate s
 
 =over 4
 
-=item B<gfx_passthrough=BOOLEAN>
+=item B<gfx_passthru=BOOLEAN>
 
 Enable graphics device PCI passthrough. XXX which device is passed through ?
 
diff -r 07bc9ce2378e -r 5fb2aa61197d tools/examples/xmexample.hvm
--- a/tools/examples/xmexample.hvm
+++ b/tools/examples/xmexample.hvm
@@ -346,7 +346,7 @@ tsc_mode=0
 
 #   Enable graphics passthrough:
 #
-#   If it's set, and specify grapchis device BDF in pci passthrough option,
+#   If it's set, and specify graphics device BDF in pci passthrough option,
 # like pci=['xx:xx.x'], it enables graphics passthrough, default=0 (disabled)
 #gfx_passthru=0
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:43:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09:43:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxbNw-0005jo-9K; Wed, 15 Feb 2012 09:42:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RxbNu-0005jg-LG
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:42:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329298959!13434238!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNjM0ODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15358 invoked from network); 15 Feb 2012 09:42:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 09:42:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329298959; l=1151;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=m1eJRN6vmCO5DxTyzAI3JiZByLA=;
	b=TO0V5uOOpJSfojkjGUK/sPkaU3CD2Zft9wEZ2npsPzhs3NQzDw/2ZcsKCN7x9jqcw2p
	ZDOZqUmm5Djy/2cKHDYX71q1wM/F4bGcoJgxmNWiAuWVh63buMfO5zxDhOm9bkBzlYUKG
	uCp6wEL7BrE7TlAtRgOye4jzLlsX0v+22S8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (jimi mo7) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6023c2o1F8Rj9m
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:42:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4F23518632
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 10:42:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f
Message-Id: <5fb2aa61197db9676c11.1329298936@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 15 Feb 2012 10:42:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xl.cfg: fix gfx_passthru string
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329298895 -3600
# Node ID 5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f
# Parent  07bc9ce2378e9271405b6a9f5088da63805bcd2a
xl.cfg: fix gfx_passthru string

Use correct string for gfx_passthru, and fix comment typo in xmexample.hvm

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 07bc9ce2378e -r 5fb2aa61197d docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -820,7 +820,7 @@ certainly belong in a more appropriate s
 
 =over 4
 
-=item B<gfx_passthrough=BOOLEAN>
+=item B<gfx_passthru=BOOLEAN>
 
 Enable graphics device PCI passthrough. XXX which device is passed through ?
 
diff -r 07bc9ce2378e -r 5fb2aa61197d tools/examples/xmexample.hvm
--- a/tools/examples/xmexample.hvm
+++ b/tools/examples/xmexample.hvm
@@ -346,7 +346,7 @@ tsc_mode=0
 
 #   Enable graphics passthrough:
 #
-#   If it's set, and specify grapchis device BDF in pci passthrough option,
+#   If it's set, and specify graphics device BDF in pci passthrough option,
 # like pci=['xx:xx.x'], it enables graphics passthrough, default=0 (disabled)
 #gfx_passthru=0
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:44:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09: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.xensource.com>)
	id 1RxbOy-0005mr-P5; Wed, 15 Feb 2012 09:43:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RxbOx-0005mV-6j
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:43:51 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329299024!14939799!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4294 invoked from network); 15 Feb 2012 09:43:44 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.209)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Feb 2012 09:43:44 -0000
Received: from mail13-am1-R.bigfish.com (10.3.201.244) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 09:43:44 +0000
Received: from mail13-am1 (localhost [127.0.0.1])	by mail13-am1-R.bigfish.com
	(Postfix) with ESMTP id C54FC203BC;
	Wed, 15 Feb 2012 09:43:43 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1
	(MessageSwitch) id 1329299020855587_11672;
	Wed, 15 Feb 2012 09:43:40 +0000 (UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.254])	by
	mail13-am1.bigfish.com (Postfix) with ESMTP id C28B310004A;
	Wed, 15 Feb 2012 09:43:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 09:43:41 +0000
X-WSS-ID: 0LZFHOP-01-34R-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 287861028056;	Wed, 15 Feb 2012 03:43:37 -0600 (CST)
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, 15 Feb 2012 03:43:48 -0600
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.289.1;
	Wed, 15 Feb 2012 03:43:37 -0600
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, 15 Feb 2012
	04:43:37 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B55A149C305; Wed, 15 Feb 2012
	09:43:35 +0000 (GMT)
Message-ID: <4F3B7F90.9030308@amd.com>
Date: Wed, 15 Feb 2012 10:49:04 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1328886425@gran.amd.com>
	<20281.16449.975551.528254@mariner.uk.xensource.com>
In-Reply-To: <20281.16449.975551.528254@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 0 of 6 V5] amd iommu: support ats/gpgpu
 passthru on iommuv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/13/2012 05:54 PM, Ian Jackson wrote:
> Wei Wang writes ("[PATCH 0 of 6 V5] amd iommu: support ats/gpgpu passthru on iommuv2 systems"):
>> This is patch set v5. It includes all pending patches that are needed to enable gpgpu passthrough and heterogeneous computing in guest OSes. Basically, this patch set gives guest VM the same capability of running openCL applications on amd platforms as native OSes. Upstream Linux 3.3 rc2 with amd iommuv2 kernel driver has been tested well as guest OS, and since last submission, lots of regression tests have been done to make sure this does not break non-iommuv2 systems. Please review it, feedbacks are appreciated.
>
> Thanks.  I'm not qualified to review the hypervisor parts, but the
> explanation seems to make sense and the tools parts look OK.
>
> So as for these three:
>
>   [PATCH 4 of 6 V5] libxc: add wrappers for new hypercalls
>   [PATCH 5 of 6 V5] libxl: bind virtual bdf to physical bdf ...
>   [PATCH 6 of 6 V5] libxl: Introduce a new guest config file parameter
>
> Acked-by: Ian Jackson<ian.jackson@eu.citrix.com>
>

Cool! thanks a lot for reviewing it and moving this forward.
Issues you mentioned will be fixed in my next post.

Thanks,
Wei

> I do have a couple of minor niggles which you might like to address if
> you repost:
>
>> libxl: Introduce a new guest config file parameter
>> Use guest_iommu = {1,0} to enable or disable guest iommu emulation.
>> Default value is 0. Regression tests have been done to make sure
>> it does not break non-iommuv2 systems.
>
> It's conventional to leave a blank line between the summary line and
> the bulk of the description.
>
>> diff -r c39f5736e364 -r 09721a5ff844 docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:19 2012 +0100
>> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:20 2012 +0100
>> @@ -820,6 +820,10 @@ certainly belong in a more appropriate s
> ...
>> +=item B<guest_iommu=BOOLEAN>
>> +
>> +Enable virtual iommu device for hvm guest. It should be enabled to passthrough AMD GPGPU.
>> +
>
> It would be nice for that line to be wrapped to fit within 75-80
> columns.
>
> Thanks,
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:44:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09: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.xensource.com>)
	id 1RxbOy-0005mr-P5; Wed, 15 Feb 2012 09:43:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RxbOx-0005mV-6j
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:43:51 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329299024!14939799!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4294 invoked from network); 15 Feb 2012 09:43:44 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.209)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Feb 2012 09:43:44 -0000
Received: from mail13-am1-R.bigfish.com (10.3.201.244) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 09:43:44 +0000
Received: from mail13-am1 (localhost [127.0.0.1])	by mail13-am1-R.bigfish.com
	(Postfix) with ESMTP id C54FC203BC;
	Wed, 15 Feb 2012 09:43:43 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1
	(MessageSwitch) id 1329299020855587_11672;
	Wed, 15 Feb 2012 09:43:40 +0000 (UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.254])	by
	mail13-am1.bigfish.com (Postfix) with ESMTP id C28B310004A;
	Wed, 15 Feb 2012 09:43:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 09:43:41 +0000
X-WSS-ID: 0LZFHOP-01-34R-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 287861028056;	Wed, 15 Feb 2012 03:43:37 -0600 (CST)
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, 15 Feb 2012 03:43:48 -0600
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.289.1;
	Wed, 15 Feb 2012 03:43:37 -0600
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, 15 Feb 2012
	04:43:37 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B55A149C305; Wed, 15 Feb 2012
	09:43:35 +0000 (GMT)
Message-ID: <4F3B7F90.9030308@amd.com>
Date: Wed, 15 Feb 2012 10:49:04 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <patchbomb.1328886425@gran.amd.com>
	<20281.16449.975551.528254@mariner.uk.xensource.com>
In-Reply-To: <20281.16449.975551.528254@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 0 of 6 V5] amd iommu: support ats/gpgpu
 passthru on iommuv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/13/2012 05:54 PM, Ian Jackson wrote:
> Wei Wang writes ("[PATCH 0 of 6 V5] amd iommu: support ats/gpgpu passthru on iommuv2 systems"):
>> This is patch set v5. It includes all pending patches that are needed to enable gpgpu passthrough and heterogeneous computing in guest OSes. Basically, this patch set gives guest VM the same capability of running openCL applications on amd platforms as native OSes. Upstream Linux 3.3 rc2 with amd iommuv2 kernel driver has been tested well as guest OS, and since last submission, lots of regression tests have been done to make sure this does not break non-iommuv2 systems. Please review it, feedbacks are appreciated.
>
> Thanks.  I'm not qualified to review the hypervisor parts, but the
> explanation seems to make sense and the tools parts look OK.
>
> So as for these three:
>
>   [PATCH 4 of 6 V5] libxc: add wrappers for new hypercalls
>   [PATCH 5 of 6 V5] libxl: bind virtual bdf to physical bdf ...
>   [PATCH 6 of 6 V5] libxl: Introduce a new guest config file parameter
>
> Acked-by: Ian Jackson<ian.jackson@eu.citrix.com>
>

Cool! thanks a lot for reviewing it and moving this forward.
Issues you mentioned will be fixed in my next post.

Thanks,
Wei

> I do have a couple of minor niggles which you might like to address if
> you repost:
>
>> libxl: Introduce a new guest config file parameter
>> Use guest_iommu = {1,0} to enable or disable guest iommu emulation.
>> Default value is 0. Regression tests have been done to make sure
>> it does not break non-iommuv2 systems.
>
> It's conventional to leave a blank line between the summary line and
> the bulk of the description.
>
>> diff -r c39f5736e364 -r 09721a5ff844 docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:19 2012 +0100
>> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 10 15:49:20 2012 +0100
>> @@ -820,6 +820,10 @@ certainly belong in a more appropriate s
> ...
>> +=item B<guest_iommu=BOOLEAN>
>> +
>> +Enable virtual iommu device for hvm guest. It should be enabled to passthrough AMD GPGPU.
>> +
>
> It would be nice for that line to be wrapped to fit within 75-80
> columns.
>
> Thanks,
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:49:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09: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.xensource.com>)
	id 1RxbUX-0006Ob-SW; Wed, 15 Feb 2012 09:49:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxbUW-0006OR-GG
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:49:36 +0000
Received: from [85.158.139.83:63106] by server-8.bemta-5.messagelabs.com id
	5C/BA-09797-FAF7B3F4; Wed, 15 Feb 2012 09:49:35 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329299373!15081817!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29348 invoked from network); 15 Feb 2012 09:49:34 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 09:49:34 -0000
Received: by vbbfq11 with SMTP id fq11so1369117vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 01:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rCwAklyDZ+NwXEwpYcxokmiLw8jQzNE1s1PbHHlC5Uk=;
	b=ZTGqZ1qYfwmgbtpcTbzYAtqBgnNlkyS4c6dvvPEnXRcirxmfmNKGvc8nNf1GQRiPLY
	b7+0NKxKDY+gnpODmaiG1E1//wpKqq/T9cVuYuLhRKQdKoxiYHcAmy+3j8MeUXfvpflw
	w+SFZb4AwbH7OyFrsA3FBS26cYBf6ktWg/Kh8=
MIME-Version: 1.0
Received: by 10.220.107.212 with SMTP id c20mr6820600vcp.26.1329299371703;
	Wed, 15 Feb 2012 01:49:31 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Wed, 15 Feb 2012 01:49:31 -0800 (PST)
In-Reply-To: <1329294758.26412.13.camel@dagon.hellion.org.uk>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
	<CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
	<1329294758.26412.13.camel@dagon.hellion.org.uk>
Date: Wed, 15 Feb 2012 17:49:31 +0800
Message-ID: <CABpY8MKA5V3DZi0gf7zFTj0Ock0dr8nn2AkvbXzCAJw1NRzKTQ@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7602431998928484832=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7602431998928484832==
Content-Type: multipart/alternative; boundary=f46d0438ed1dd9bf3404b8fda01b

--f46d0438ed1dd9bf3404b8fda01b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 15, 2012 at 4:32 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

> Please do not top post. http://wiki.xen.org/wiki/AskingXenDevelQuestions
>
> On Wed, 2012-02-15 at 06:40 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:
> > Well, I have found the wrong code.
> > The macro DPRINTF  points to
> > #define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler,
> > XTL_DETAIL, 0, _f, ## -a)
> > So is this Xen's private log system ? Where messages write via
> > xc_report and xc_report_error function?
>
> You should have been able to find these functions by using "grep" or
> other similar tools (hint: look under tools/libxc).
>
> Had you done so you would have found that they use the xtl logger
> infrastructure. xch->error_handler is the logger passed to
> xc_interface_open(), the behaviour of which is documented in the header.
>
> Ian.
>
>
>
>
I have found these codes. Then how can I change the position of xen tool
log or change the log level? I found it may be separated with Xend log.

Thanks.

--=20
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--f46d0438ed1dd9bf3404b8fda01b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Feb 15, 2012 at 4:32 PM, Ian Cam=
pbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.=
Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Please do not top post. <a href=3D"http://wiki.xen.org/wiki/AskingXenDevelQ=
uestions" target=3D"_blank">http://wiki.xen.org/wiki/AskingXenDevelQuestion=
s</a><br>
<div class=3D"im"><br>
On Wed, 2012-02-15 at 06:40 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:<br>
&gt; Well, I have found the wrong code.<br>
&gt; The macro DPRINTF =C2=A0points to<br>
&gt; #define DPRINTF(_f, _a...) xc_report(xch, xch-&gt;error_handler,<br>
&gt; XTL_DETAIL, 0, _f, ## -a)<br>
&gt; So is this Xen&#39;s private log system ? Where messages write via<br>
&gt; xc_report and xc_report_error function?<br>
<br>
</div>You should have been able to find these functions by using &quot;grep=
&quot; or<br>
other similar tools (hint: look under tools/libxc).<br>
<br>
Had you done so you would have found that they use the xtl logger<br>
infrastructure. xch-&gt;error_handler is the logger passed to<br>
xc_interface_open(), the behaviour of which is documented in the header.<br=
>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br>I have found these codes. Then how can=
 I change the position of xen tool log or change the log level? I found it =
may be=C2=A0separated=C2=A0with Xend log.<div><br></div><div>Thanks.<br cle=
ar=3D"all">
<div><br></div>-- <br>Chunqi Li<br>Department of Computer Science<br>School=
 of EECS<br>Peking University<br>Beijing, China<br>
</div>

--f46d0438ed1dd9bf3404b8fda01b--


--===============7602431998928484832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7602431998928484832==--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 09:49:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 09: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.xensource.com>)
	id 1RxbUX-0006Ob-SW; Wed, 15 Feb 2012 09:49:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxbUW-0006OR-GG
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 09:49:36 +0000
Received: from [85.158.139.83:63106] by server-8.bemta-5.messagelabs.com id
	5C/BA-09797-FAF7B3F4; Wed, 15 Feb 2012 09:49:35 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329299373!15081817!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29348 invoked from network); 15 Feb 2012 09:49:34 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 09:49:34 -0000
Received: by vbbfq11 with SMTP id fq11so1369117vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 01:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rCwAklyDZ+NwXEwpYcxokmiLw8jQzNE1s1PbHHlC5Uk=;
	b=ZTGqZ1qYfwmgbtpcTbzYAtqBgnNlkyS4c6dvvPEnXRcirxmfmNKGvc8nNf1GQRiPLY
	b7+0NKxKDY+gnpODmaiG1E1//wpKqq/T9cVuYuLhRKQdKoxiYHcAmy+3j8MeUXfvpflw
	w+SFZb4AwbH7OyFrsA3FBS26cYBf6ktWg/Kh8=
MIME-Version: 1.0
Received: by 10.220.107.212 with SMTP id c20mr6820600vcp.26.1329299371703;
	Wed, 15 Feb 2012 01:49:31 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Wed, 15 Feb 2012 01:49:31 -0800 (PST)
In-Reply-To: <1329294758.26412.13.camel@dagon.hellion.org.uk>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
	<CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
	<1329294758.26412.13.camel@dagon.hellion.org.uk>
Date: Wed, 15 Feb 2012 17:49:31 +0800
Message-ID: <CABpY8MKA5V3DZi0gf7zFTj0Ock0dr8nn2AkvbXzCAJw1NRzKTQ@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7602431998928484832=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7602431998928484832==
Content-Type: multipart/alternative; boundary=f46d0438ed1dd9bf3404b8fda01b

--f46d0438ed1dd9bf3404b8fda01b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 15, 2012 at 4:32 PM, Ian Campbell <Ian.Campbell@citrix.com>wrot=
e:

> Please do not top post. http://wiki.xen.org/wiki/AskingXenDevelQuestions
>
> On Wed, 2012-02-15 at 06:40 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:
> > Well, I have found the wrong code.
> > The macro DPRINTF  points to
> > #define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler,
> > XTL_DETAIL, 0, _f, ## -a)
> > So is this Xen's private log system ? Where messages write via
> > xc_report and xc_report_error function?
>
> You should have been able to find these functions by using "grep" or
> other similar tools (hint: look under tools/libxc).
>
> Had you done so you would have found that they use the xtl logger
> infrastructure. xch->error_handler is the logger passed to
> xc_interface_open(), the behaviour of which is documented in the header.
>
> Ian.
>
>
>
>
I have found these codes. Then how can I change the position of xen tool
log or change the log level? I found it may be separated with Xend log.

Thanks.

--=20
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--f46d0438ed1dd9bf3404b8fda01b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Feb 15, 2012 at 4:32 PM, Ian Cam=
pbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.=
Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Please do not top post. <a href=3D"http://wiki.xen.org/wiki/AskingXenDevelQ=
uestions" target=3D"_blank">http://wiki.xen.org/wiki/AskingXenDevelQuestion=
s</a><br>
<div class=3D"im"><br>
On Wed, 2012-02-15 at 06:40 +0000, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote:<br>
&gt; Well, I have found the wrong code.<br>
&gt; The macro DPRINTF =C2=A0points to<br>
&gt; #define DPRINTF(_f, _a...) xc_report(xch, xch-&gt;error_handler,<br>
&gt; XTL_DETAIL, 0, _f, ## -a)<br>
&gt; So is this Xen&#39;s private log system ? Where messages write via<br>
&gt; xc_report and xc_report_error function?<br>
<br>
</div>You should have been able to find these functions by using &quot;grep=
&quot; or<br>
other similar tools (hint: look under tools/libxc).<br>
<br>
Had you done so you would have found that they use the xtl logger<br>
infrastructure. xch-&gt;error_handler is the logger passed to<br>
xc_interface_open(), the behaviour of which is documented in the header.<br=
>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br>I have found these codes. Then how can=
 I change the position of xen tool log or change the log level? I found it =
may be=C2=A0separated=C2=A0with Xend log.<div><br></div><div>Thanks.<br cle=
ar=3D"all">
<div><br></div>-- <br>Chunqi Li<br>Department of Computer Science<br>School=
 of EECS<br>Peking University<br>Beijing, China<br>
</div>

--f46d0438ed1dd9bf3404b8fda01b--


--===============7602431998928484832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7602431998928484832==--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:02:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxbgL-0006gz-AI; Wed, 15 Feb 2012 10:01:49 +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 1RxbgK-0006gu-0d
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:01:48 +0000
Received: from [85.158.139.83:49919] by server-3.bemta-5.messagelabs.com id
	4F/E8-06438-B828B3F4; Wed, 15 Feb 2012 10:01:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329300104!14295631!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=1.7 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTU0MjU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTU0MjU=\n,BODY_RANDOM_LONG,
	HOT_NASTY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19062 invoked from network); 15 Feb 2012 10:01:45 -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; 15 Feb 2012 10:01:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329300104; l=1138;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5fMe/8rg8cPYZXWmxIc3v6hCHIY=;
	b=pCGekckA1vjyR4oQoFsawLWqHBUE7R5AieSToWbamqScJkhP7j1qXqICr5mQfQWeOxp
	AAl2KC7St/9DAVfDrE3u+eIYz1KArc/PpHb9SlSYgJCbxOtVgA7X8b9qA3Vkcer5hdAqi
	RBWpOPvrjCmGqyvDxy2DxpthoePbsg2eInU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (jimi mo29) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u0068fo1F9XI7b
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 11:01:33 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 1F84118632
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 11:01:33 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5a1cbd1af275e6ed1ef673852f8ac5247c09669c
Message-Id: <5a1cbd1af275e6ed1ef6.1329300091@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 15 Feb 2012 11:01:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] man/xl.cfg: mention not yet documented options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329300057 -3600
# Node ID 5a1cbd1af275e6ed1ef673852f8ac5247c09669c
# Parent  5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f
man/xl.cfg: mention not yet documented options

Add dummy entries for parsed but undocumented cfg file options to xl.cfg:

for i in `
grep -Ew 'xlu_cfg_get_(long|string|list|list_as_string_list)' tools/libxl/xl_cmdimpl.c | cut -f 2 -d '"' | sort -u
`
do
	grep -wq $i docs/man/xl.cfg.pod.5 || echo $i
done

current output:
acpi_s3
acpi_s4
cpus
device_model
gfx_passthru
maxmem
nodes
sched
vif2

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 5fb2aa61197d -r 5a1cbd1af275 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -842,6 +842,38 @@ XXX
 
 XXX
 
+=item B<acpi_s3=BOOLEAN>
+
+XXX
+
+=item B<acpi_s3=BOOLEAN>
+
+XXX
+
+=item B<cpus=XXX>
+
+XXX
+
+=item B<maxmem=NUMBER>
+
+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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:02:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxbgL-0006gz-AI; Wed, 15 Feb 2012 10:01:49 +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 1RxbgK-0006gu-0d
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:01:48 +0000
Received: from [85.158.139.83:49919] by server-3.bemta-5.messagelabs.com id
	4F/E8-06438-B828B3F4; Wed, 15 Feb 2012 10:01:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329300104!14295631!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=1.7 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTU0MjU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTU0MjU=\n,BODY_RANDOM_LONG,
	HOT_NASTY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19062 invoked from network); 15 Feb 2012 10:01:45 -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; 15 Feb 2012 10:01:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329300104; l=1138;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5fMe/8rg8cPYZXWmxIc3v6hCHIY=;
	b=pCGekckA1vjyR4oQoFsawLWqHBUE7R5AieSToWbamqScJkhP7j1qXqICr5mQfQWeOxp
	AAl2KC7St/9DAVfDrE3u+eIYz1KArc/PpHb9SlSYgJCbxOtVgA7X8b9qA3Vkcer5hdAqi
	RBWpOPvrjCmGqyvDxy2DxpthoePbsg2eInU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll287qFz8T
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-082-151.pools.arcor-ip.net [84.57.82.151])
	by smtp.strato.de (jimi mo29) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u0068fo1F9XI7b
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 11:01:33 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 1F84118632
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 11:01:33 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5a1cbd1af275e6ed1ef673852f8ac5247c09669c
Message-Id: <5a1cbd1af275e6ed1ef6.1329300091@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 15 Feb 2012 11:01:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] man/xl.cfg: mention not yet documented options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329300057 -3600
# Node ID 5a1cbd1af275e6ed1ef673852f8ac5247c09669c
# Parent  5fb2aa61197db9676c11fbcf3ed24f30ac8fab9f
man/xl.cfg: mention not yet documented options

Add dummy entries for parsed but undocumented cfg file options to xl.cfg:

for i in `
grep -Ew 'xlu_cfg_get_(long|string|list|list_as_string_list)' tools/libxl/xl_cmdimpl.c | cut -f 2 -d '"' | sort -u
`
do
	grep -wq $i docs/man/xl.cfg.pod.5 || echo $i
done

current output:
acpi_s3
acpi_s4
cpus
device_model
gfx_passthru
maxmem
nodes
sched
vif2

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 5fb2aa61197d -r 5a1cbd1af275 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -842,6 +842,38 @@ XXX
 
 XXX
 
+=item B<acpi_s3=BOOLEAN>
+
+XXX
+
+=item B<acpi_s3=BOOLEAN>
+
+XXX
+
+=item B<cpus=XXX>
+
+XXX
+
+=item B<maxmem=NUMBER>
+
+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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxbmB-0006sV-4W; Wed, 15 Feb 2012 10:07:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxbm9-0006sL-EF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:07:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329300463!13445265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5676 invoked from network); 15 Feb 2012 10:07:43 -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;
	15 Feb 2012 10:07:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10705659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 10:07:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 10:07:43 +0000
Message-ID: <1329300460.31256.284.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "=?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <Chunqi Li>" <yzt356@gmail.com>
Date: Wed, 15 Feb 2012 10:07:40 +0000
In-Reply-To: <CABpY8MKA5V3DZi0gf7zFTj0Ock0dr8nn2AkvbXzCAJw1NRzKTQ@mail.gmail.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
	<CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
	<1329294758.26412.13.camel@dagon.hellion.org.uk>
	<CABpY8MKA5V3DZi0gf7zFTj0Ock0dr8nn2AkvbXzCAJw1NRzKTQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTE1IGF0IDA5OjQ5ICswMDAwLCDmnY7mmKXlpYcgd3JvdGU6Cj4gCj4g
Cj4gT24gV2VkLCBGZWIgMTUsIDIwMTIgYXQgNDozMiBQTSwgSWFuIENhbXBiZWxsCj4gPElhbi5D
YW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPiAgICAgICAgIFBsZWFzZSBkbyBub3QgdG9wIHBv
c3QuCj4gICAgICAgICBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQXNraW5nWGVuRGV2ZWxRdWVz
dGlvbnMKPiAgICAgICAgIAo+ICAgICAgICAgT24gV2VkLCAyMDEyLTAyLTE1IGF0IDA2OjQwICsw
MDAwLCDmnY7mmKXlpYcgd3JvdGU6Cj4gICAgICAgICA+IFdlbGwsIEkgaGF2ZSBmb3VuZCB0aGUg
d3JvbmcgY29kZS4KPiAgICAgICAgID4gVGhlIG1hY3JvIERQUklOVEYgIHBvaW50cyB0bwo+ICAg
ICAgICAgPiAjZGVmaW5lIERQUklOVEYoX2YsIF9hLi4uKSB4Y19yZXBvcnQoeGNoLAo+ICAgICAg
ICAgeGNoLT5lcnJvcl9oYW5kbGVyLAo+ICAgICAgICAgPiBYVExfREVUQUlMLCAwLCBfZiwgIyMg
LWEpCj4gICAgICAgICA+IFNvIGlzIHRoaXMgWGVuJ3MgcHJpdmF0ZSBsb2cgc3lzdGVtID8gV2hl
cmUgbWVzc2FnZXMgd3JpdGUKPiAgICAgICAgIHZpYQo+ICAgICAgICAgPiB4Y19yZXBvcnQgYW5k
IHhjX3JlcG9ydF9lcnJvciBmdW5jdGlvbj8KPiAgICAgICAgIAo+ICAgICAgICAgCj4gICAgICAg
ICBZb3Ugc2hvdWxkIGhhdmUgYmVlbiBhYmxlIHRvIGZpbmQgdGhlc2UgZnVuY3Rpb25zIGJ5IHVz
aW5nCj4gICAgICAgICAiZ3JlcCIgb3IKPiAgICAgICAgIG90aGVyIHNpbWlsYXIgdG9vbHMgKGhp
bnQ6IGxvb2sgdW5kZXIgdG9vbHMvbGlieGMpLgo+ICAgICAgICAgCj4gICAgICAgICBIYWQgeW91
IGRvbmUgc28geW91IHdvdWxkIGhhdmUgZm91bmQgdGhhdCB0aGV5IHVzZSB0aGUgeHRsCj4gICAg
ICAgICBsb2dnZXIKPiAgICAgICAgIGluZnJhc3RydWN0dXJlLiB4Y2gtPmVycm9yX2hhbmRsZXIg
aXMgdGhlIGxvZ2dlciBwYXNzZWQgdG8KPiAgICAgICAgIHhjX2ludGVyZmFjZV9vcGVuKCksIHRo
ZSBiZWhhdmlvdXIgb2Ygd2hpY2ggaXMgZG9jdW1lbnRlZCBpbgo+ICAgICAgICAgdGhlIGhlYWRl
ci4KPiAgICAgICAgIAo+ICAgICAgICAgSWFuLgo+ICAgICAgICAgCj4gICAgICAgICAKPiAgICAg
ICAgIAo+IAo+IEkgaGF2ZSBmb3VuZCB0aGVzZSBjb2Rlcy4gVGhlbiBob3cgY2FuIEkgY2hhbmdl
IHRoZSBwb3NpdGlvbiBvZiB4ZW4KPiB0b29sIGxvZyBvciBjaGFuZ2UgdGhlIGxvZyBsZXZlbD8g
SSBmb3VuZCBpdCBtYXkgYmUgc2VwYXJhdGVkIHdpdGgKPiBYZW5kIGxvZy4KCk5vdGUgdGhhdCB4
ZW5kIGlzIGRlcHJlY2F0ZWQuIEFsbCBuZXcgZGV2ZWxvcG1lbnQgc2hvdWxkIGJlIGJhc2VkIG9u
IHhsCmFuZCBsaWJ4bC4KCllvdSdkIGhhdmUgdG8gY2hhbmdlIHRoZSBjb2RlLiBJZiB4ZW5kIGlz
IGludm9sdmVkIHRoZW4gd2lsbCBsaWtlbHkKaW5jbHVkaW5nIGVuaGFuY2luZyB0aGUgcHl0aG9u
IGJpbmRpbmdzIGZvciBsaWJ4YyAodG9vbHMvcHl0aG9uLy4uLi94YykKdG8gc3VwcG9ydCBjaGFu
Z2luZyB0aGVzZSBvcHRpb25zLCBvciB5b3UgY291bGQganVzdCBoYWNrIHRoZSBvcHRpb25zCnlv
dSB3YW50IGludG8gdGhlIEMgcGFydCBvZiBiaW5kaW5ncyBhbmQgbm90IHdvcnJ5IGFib3V0IHRo
ZSBweXRob24Kc2lkZS4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxbmB-0006sV-4W; Wed, 15 Feb 2012 10:07:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxbm9-0006sL-EF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:07:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329300463!13445265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5676 invoked from network); 15 Feb 2012 10:07:43 -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;
	15 Feb 2012 10:07:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10705659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 10:07:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 10:07:43 +0000
Message-ID: <1329300460.31256.284.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "=?UTF-8?Q?=E6=9D=8E=E6=98=A5=E5=A5=87?= <Chunqi Li>" <yzt356@gmail.com>
Date: Wed, 15 Feb 2012 10:07:40 +0000
In-Reply-To: <CABpY8MKA5V3DZi0gf7zFTj0Ock0dr8nn2AkvbXzCAJw1NRzKTQ@mail.gmail.com>
References: <CABpY8MKQY+uV6tnT07aCSRu8zQFdwSQ=Q1KXKh1eMBrmbVkWZg@mail.gmail.com>
	<1329211517.31256.165.camel@zakaz.uk.xensource.com>
	<CABpY8MJ0w95QXSh=Yx29j28MqdnUVhNwBmkVN-w74sconr7J1A@mail.gmail.com>
	<1329294758.26412.13.camel@dagon.hellion.org.uk>
	<CABpY8MKA5V3DZi0gf7zFTj0Ock0dr8nn2AkvbXzCAJw1NRzKTQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Questions about LOG system
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAyLTE1IGF0IDA5OjQ5ICswMDAwLCDmnY7mmKXlpYcgd3JvdGU6Cj4gCj4g
Cj4gT24gV2VkLCBGZWIgMTUsIDIwMTIgYXQgNDozMiBQTSwgSWFuIENhbXBiZWxsCj4gPElhbi5D
YW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPiAgICAgICAgIFBsZWFzZSBkbyBub3QgdG9wIHBv
c3QuCj4gICAgICAgICBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvQXNraW5nWGVuRGV2ZWxRdWVz
dGlvbnMKPiAgICAgICAgIAo+ICAgICAgICAgT24gV2VkLCAyMDEyLTAyLTE1IGF0IDA2OjQwICsw
MDAwLCDmnY7mmKXlpYcgd3JvdGU6Cj4gICAgICAgICA+IFdlbGwsIEkgaGF2ZSBmb3VuZCB0aGUg
d3JvbmcgY29kZS4KPiAgICAgICAgID4gVGhlIG1hY3JvIERQUklOVEYgIHBvaW50cyB0bwo+ICAg
ICAgICAgPiAjZGVmaW5lIERQUklOVEYoX2YsIF9hLi4uKSB4Y19yZXBvcnQoeGNoLAo+ICAgICAg
ICAgeGNoLT5lcnJvcl9oYW5kbGVyLAo+ICAgICAgICAgPiBYVExfREVUQUlMLCAwLCBfZiwgIyMg
LWEpCj4gICAgICAgICA+IFNvIGlzIHRoaXMgWGVuJ3MgcHJpdmF0ZSBsb2cgc3lzdGVtID8gV2hl
cmUgbWVzc2FnZXMgd3JpdGUKPiAgICAgICAgIHZpYQo+ICAgICAgICAgPiB4Y19yZXBvcnQgYW5k
IHhjX3JlcG9ydF9lcnJvciBmdW5jdGlvbj8KPiAgICAgICAgIAo+ICAgICAgICAgCj4gICAgICAg
ICBZb3Ugc2hvdWxkIGhhdmUgYmVlbiBhYmxlIHRvIGZpbmQgdGhlc2UgZnVuY3Rpb25zIGJ5IHVz
aW5nCj4gICAgICAgICAiZ3JlcCIgb3IKPiAgICAgICAgIG90aGVyIHNpbWlsYXIgdG9vbHMgKGhp
bnQ6IGxvb2sgdW5kZXIgdG9vbHMvbGlieGMpLgo+ICAgICAgICAgCj4gICAgICAgICBIYWQgeW91
IGRvbmUgc28geW91IHdvdWxkIGhhdmUgZm91bmQgdGhhdCB0aGV5IHVzZSB0aGUgeHRsCj4gICAg
ICAgICBsb2dnZXIKPiAgICAgICAgIGluZnJhc3RydWN0dXJlLiB4Y2gtPmVycm9yX2hhbmRsZXIg
aXMgdGhlIGxvZ2dlciBwYXNzZWQgdG8KPiAgICAgICAgIHhjX2ludGVyZmFjZV9vcGVuKCksIHRo
ZSBiZWhhdmlvdXIgb2Ygd2hpY2ggaXMgZG9jdW1lbnRlZCBpbgo+ICAgICAgICAgdGhlIGhlYWRl
ci4KPiAgICAgICAgIAo+ICAgICAgICAgSWFuLgo+ICAgICAgICAgCj4gICAgICAgICAKPiAgICAg
ICAgIAo+IAo+IEkgaGF2ZSBmb3VuZCB0aGVzZSBjb2Rlcy4gVGhlbiBob3cgY2FuIEkgY2hhbmdl
IHRoZSBwb3NpdGlvbiBvZiB4ZW4KPiB0b29sIGxvZyBvciBjaGFuZ2UgdGhlIGxvZyBsZXZlbD8g
SSBmb3VuZCBpdCBtYXkgYmUgc2VwYXJhdGVkIHdpdGgKPiBYZW5kIGxvZy4KCk5vdGUgdGhhdCB4
ZW5kIGlzIGRlcHJlY2F0ZWQuIEFsbCBuZXcgZGV2ZWxvcG1lbnQgc2hvdWxkIGJlIGJhc2VkIG9u
IHhsCmFuZCBsaWJ4bC4KCllvdSdkIGhhdmUgdG8gY2hhbmdlIHRoZSBjb2RlLiBJZiB4ZW5kIGlz
IGludm9sdmVkIHRoZW4gd2lsbCBsaWtlbHkKaW5jbHVkaW5nIGVuaGFuY2luZyB0aGUgcHl0aG9u
IGJpbmRpbmdzIGZvciBsaWJ4YyAodG9vbHMvcHl0aG9uLy4uLi94YykKdG8gc3VwcG9ydCBjaGFu
Z2luZyB0aGVzZSBvcHRpb25zLCBvciB5b3UgY291bGQganVzdCBoYWNrIHRoZSBvcHRpb25zCnlv
dSB3YW50IGludG8gdGhlIEMgcGFydCBvZiBiaW5kaW5ncyBhbmQgbm90IHdvcnJ5IGFib3V0IHRo
ZSBweXRob24Kc2lkZS4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:19:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxbx1-0007OV-Au; Wed, 15 Feb 2012 10:19:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rxbwz-0007OJ-Ni
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:19:02 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329301135!13432700!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0ODA3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21427 invoked from network); 15 Feb 2012 10:18:55 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 10:18:55 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=SZQNEi3nZJDaj4cQumBmOvC2rwkbYhlKYTYP54wM6eLiwzQqLh8mkWzI
	3a+IjkQ6cywmktAmVjWyPBn+BQV1sL8Qan6RA7GqjnIDCN894vGea8oHb
	R7uDEL0JjuR+G0Ec1/p+aTdY9IzZxP8k2r+F9RNvKbB1iWHgqYZXOTBNQ
	GmkHVcSbrd4nmsBMkt6SWkdFECaVmmfN7oU331d6bmGVdKVPynO+JPg6s
	CY0GfcDvMjOcFuJg5D/pP7pMes/Sf;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329301135; x=1360837135;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=AY2f63H92yuPHMMENj3+umcteHkD05sg9xZh5qEmbCg=;
	b=kpcZRCyvNUOC7VogCmfdUOFo+s+fpUqVXhfNIKM4bvAXp14dtWRWyTtA
	dDYdg66FnACSlOlgRyHQihhUjmJtk/ge9fvLzZd644HI0dQFESYF3iDql
	iI3gWRo5Xqv5iI1eVjLJLvseDq879Q31dC9esvKvB4G/DcTkKfv9a9Glx
	hZQuv5QpS+CQvXqjqX5IzDF884H2KTlw4QuvIkuzRmSE9teWzAnYu1SCP
	eaSBfKOLnYbOfnUR3eN9mBcc7iWbf;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="86491712"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 15 Feb 2012 11:18:54 +0100
X-IronPort-AV: E=Sophos;i="4.73,420,1325458800"; d="scan'208";a="128956202"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 15 Feb 2012 11:18:54 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 7CC3977181A;
	Wed, 15 Feb 2012 11:18:54 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 11:18:53 +0100
Message-ID: <2372545.AjeFrRLSs5@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4F3A82C60200007800072EC5@nat28.tlf.novell.com>
References: <6587132.0KbvunDmjW@amur> <2263997.kVLThTfZaS@amur>
	<4F3A82C60200007800072EC5@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag 14 Februar 2012, 14:50:30 schrieb Jan Beulich:
> >>> On 14.02.12 at 15:30, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
> >> Plus enforcing the buffer requirements to avoid CPU deadlock
> >> (contiguous present pages, alignment). Failure to do so can hang the
> >> CPU, and hence would represent a DoS vulnerability.
> > 
> > I'm not sure what you mean here. Are you speaking about the DS buffer?
> > If yes, this is no problem, because the DS buffer addressm must be a domU
> > virtual address. The processor only writes data into the buffer, if the
> > domU is running so in the worst case the domU gets triggered a page fault
> > or what I testet a triple fault occurs and the domU gets rebootet.
> 
> This certainly can be CPU model dependent, but on raw hardware
> I know that not meeting the buffer constraints can hang (not triple
> fault, perhaps a live lock) a CPU. Therefore, unless you can prove
> this is impossible when running in VMX non-root, you will have to add
> provisions for this (and this was the major reason keeping me from
> trying to add DS support a year or two ago). At the very minimum
> the whole functionality would otherwise need to be disabled by
> default, and when enabled a prominent warning be issued (along
> the lines of that of sync_console).

Of course I can't prove anything.
While I experimented with this I couldn't find any statement in the cpu specs
about this buffer stuff and what the cpu does with wrong addresses. I found
that writing a non canonical address into the MSR_IA32_DS_AREA leads to a
general protection fault in the hypervisor. This was the cause for the check of
is_canonical_address(msr_content).
But with this check I tried different addresses, also wrong addresses within
the buffer and the hypervisor didn't crash anymore but the domU always failed
with the:
hvm.c:1141:d10 Triple fault on VCPU0 - invoking HVM system reset.
But of course there may be other critical pathes.

Currently we have the vpmu boot flag. So by default this is disabled.
The question is, should the BTS suff get an own flag or should we change the
vpmu flag to a string with multiple meanings? If the warning should be printed
only for the BTS stuff then an own BTS flag is needed.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:19:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxbx1-0007OV-Au; Wed, 15 Feb 2012 10:19:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rxbwz-0007OJ-Ni
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:19:02 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329301135!13432700!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE0ODA3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21427 invoked from network); 15 Feb 2012 10:18:55 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 10:18:55 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=SZQNEi3nZJDaj4cQumBmOvC2rwkbYhlKYTYP54wM6eLiwzQqLh8mkWzI
	3a+IjkQ6cywmktAmVjWyPBn+BQV1sL8Qan6RA7GqjnIDCN894vGea8oHb
	R7uDEL0JjuR+G0Ec1/p+aTdY9IzZxP8k2r+F9RNvKbB1iWHgqYZXOTBNQ
	GmkHVcSbrd4nmsBMkt6SWkdFECaVmmfN7oU331d6bmGVdKVPynO+JPg6s
	CY0GfcDvMjOcFuJg5D/pP7pMes/Sf;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329301135; x=1360837135;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=AY2f63H92yuPHMMENj3+umcteHkD05sg9xZh5qEmbCg=;
	b=kpcZRCyvNUOC7VogCmfdUOFo+s+fpUqVXhfNIKM4bvAXp14dtWRWyTtA
	dDYdg66FnACSlOlgRyHQihhUjmJtk/ge9fvLzZd644HI0dQFESYF3iDql
	iI3gWRo5Xqv5iI1eVjLJLvseDq879Q31dC9esvKvB4G/DcTkKfv9a9Glx
	hZQuv5QpS+CQvXqjqX5IzDF884H2KTlw4QuvIkuzRmSE9teWzAnYu1SCP
	eaSBfKOLnYbOfnUR3eN9mBcc7iWbf;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="86491712"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 15 Feb 2012 11:18:54 +0100
X-IronPort-AV: E=Sophos;i="4.73,420,1325458800"; d="scan'208";a="128956202"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 15 Feb 2012 11:18:54 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 7CC3977181A;
	Wed, 15 Feb 2012 11:18:54 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 11:18:53 +0100
Message-ID: <2372545.AjeFrRLSs5@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <4F3A82C60200007800072EC5@nat28.tlf.novell.com>
References: <6587132.0KbvunDmjW@amur> <2263997.kVLThTfZaS@amur>
	<4F3A82C60200007800072EC5@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag 14 Februar 2012, 14:50:30 schrieb Jan Beulich:
> >>> On 14.02.12 at 15:30, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
> >> Plus enforcing the buffer requirements to avoid CPU deadlock
> >> (contiguous present pages, alignment). Failure to do so can hang the
> >> CPU, and hence would represent a DoS vulnerability.
> > 
> > I'm not sure what you mean here. Are you speaking about the DS buffer?
> > If yes, this is no problem, because the DS buffer addressm must be a domU
> > virtual address. The processor only writes data into the buffer, if the
> > domU is running so in the worst case the domU gets triggered a page fault
> > or what I testet a triple fault occurs and the domU gets rebootet.
> 
> This certainly can be CPU model dependent, but on raw hardware
> I know that not meeting the buffer constraints can hang (not triple
> fault, perhaps a live lock) a CPU. Therefore, unless you can prove
> this is impossible when running in VMX non-root, you will have to add
> provisions for this (and this was the major reason keeping me from
> trying to add DS support a year or two ago). At the very minimum
> the whole functionality would otherwise need to be disabled by
> default, and when enabled a prominent warning be issued (along
> the lines of that of sync_console).

Of course I can't prove anything.
While I experimented with this I couldn't find any statement in the cpu specs
about this buffer stuff and what the cpu does with wrong addresses. I found
that writing a non canonical address into the MSR_IA32_DS_AREA leads to a
general protection fault in the hypervisor. This was the cause for the check of
is_canonical_address(msr_content).
But with this check I tried different addresses, also wrong addresses within
the buffer and the hypervisor didn't crash anymore but the domU always failed
with the:
hvm.c:1141:d10 Triple fault on VCPU0 - invoking HVM system reset.
But of course there may be other critical pathes.

Currently we have the vpmu boot flag. So by default this is disabled.
The question is, should the BTS suff get an own flag or should we change the
vpmu flag to a string with multiple meanings? If the warning should be printed
only for the BTS stuff then an own BTS flag is needed.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:29:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10: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.xensource.com>)
	id 1Rxc6v-0007Ym-FE; Wed, 15 Feb 2012 10:29: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 1Rxc6u-0007Yh-MY
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:29:16 +0000
Received: from [85.158.139.83:41725] by server-3.bemta-5.messagelabs.com id
	91/89-06438-BF88B3F4; Wed, 15 Feb 2012 10:29:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329301754!7813513!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 15 Feb 2012 10:29:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 10:29:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 10:29:15 +0000
Message-Id: <4F3B970A02000078000731E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 10:29:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur> <2263997.kVLThTfZaS@amur>
	<4F3A82C60200007800072EC5@nat28.tlf.novell.com>
	<2372545.AjeFrRLSs5@amur>
In-Reply-To: <2372545.AjeFrRLSs5@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 11:18, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> Currently we have the vpmu boot flag. So by default this is disabled.
> The question is, should the BTS suff get an own flag or should we change the
> vpmu flag to a string with multiple meanings? If the warning should be 
> printed only for the BTS stuff then an own BTS flag is needed.

I'd recommend "vpmu=bts" to enable vPMU including BTS, while the
normal boolean values (parse_bool()) would enable the "safe" parts
of vPMU code only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 10:29:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 10: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.xensource.com>)
	id 1Rxc6v-0007Ym-FE; Wed, 15 Feb 2012 10:29: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 1Rxc6u-0007Yh-MY
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:29:16 +0000
Received: from [85.158.139.83:41725] by server-3.bemta-5.messagelabs.com id
	91/89-06438-BF88B3F4; Wed, 15 Feb 2012 10:29:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329301754!7813513!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30391 invoked from network); 15 Feb 2012 10:29:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 10:29:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 10:29:15 +0000
Message-Id: <4F3B970A02000078000731E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 10:29:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <6587132.0KbvunDmjW@amur> <2263997.kVLThTfZaS@amur>
	<4F3A82C60200007800072EC5@nat28.tlf.novell.com>
	<2372545.AjeFrRLSs5@amur>
In-Reply-To: <2372545.AjeFrRLSs5@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2]  vpmu:  Add the BTS extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 11:18, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> Currently we have the vpmu boot flag. So by default this is disabled.
> The question is, should the BTS suff get an own flag or should we change the
> vpmu flag to a string with multiple meanings? If the warning should be 
> printed only for the BTS stuff then an own BTS flag is needed.

I'd recommend "vpmu=bts" to enable vPMU including BTS, while the
normal boolean values (parse_bool()) would enable the "safe" parts
of vPMU code only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:00:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxcaQ-000877-7S; Wed, 15 Feb 2012 10:59:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxcaO-00086y-Ui
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:59:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329303578!13392134!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3074 invoked from network); 15 Feb 2012 10:59:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 10:59:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 10:59:39 +0000
Message-Id: <4F3B9E2A0200007800073210@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 10:59:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 0/2] x86/vMCE: save/restore MCA capabilities
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When migrating to a host with less MCA banks than the source host
had, accesses to the extra banks' MCi_* MSRs caused #GP-s so far.
By making the bank count (and other MCA capabilities) available to
the destination host, it can properly ignore writes to extra banks the
guest may know of, and return appropriate default values for reads.

The two patches can be applied independently (the second patch
may need some refinement), but proper save/restore functionality
can only be expected with both applied.

1: don't advertise features we don't support
2: save/restore MCA capabilities

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:00:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxcaQ-000877-7S; Wed, 15 Feb 2012 10:59:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxcaO-00086y-Ui
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 10:59:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329303578!13392134!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3074 invoked from network); 15 Feb 2012 10:59:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 10:59:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 10:59:39 +0000
Message-Id: <4F3B9E2A0200007800073210@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 10:59:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 0/2] x86/vMCE: save/restore MCA capabilities
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When migrating to a host with less MCA banks than the source host
had, accesses to the extra banks' MCi_* MSRs caused #GP-s so far.
By making the bank count (and other MCA capabilities) available to
the destination host, it can properly ignore writes to extra banks the
guest may know of, and return appropriate default values for reads.

The two patches can be applied independently (the second patch
may need some refinement), but proper save/restore functionality
can only be expected with both applied.

1: don't advertise features we don't support
2: save/restore MCA capabilities

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:00:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxcbA-0008Az-LP; Wed, 15 Feb 2012 11:00:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxcb9-0008Ae-Cd
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:00:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329303624!13468455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 15 Feb 2012 11:00:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 11:00:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 11:00:25 +0000
Message-Id: <4F3B9E580200007800073214@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 11:00:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD4FAAD58.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 1/2] x86/vMCE: don't advertise features we don't
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD4FAAD58.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... or even know of. Apart from CMCI, which was masked off already,
this now also suppresses the advertising of extended state registers
(reading of which would likely be meaningless in a guest and represent
an information leak).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -457,7 +457,7 @@ int vmce_init(struct cpuinfo_x86 *c)
=20
     rdmsrl(MSR_IA32_MCG_CAP, value);
     /* For Guest vMCE usage */
-    g_mcg_cap =3D value & ~MCG_CMCI_P;
+    g_mcg_cap =3D value & (MCG_CAP_COUNT | MCG_CTL_P | MCG_TES_P | =
MCG_SER_P);
     if (value & MCG_CTL_P)
         rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
=20
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
@@ -30,12 +30,13 @@
=20
=20
 /* Bitfield of the MSR_IA32_MCG_CAP register */
-#define MCG_SER_P               (1UL<<24)
 #define MCG_CAP_COUNT           0x00000000000000ffULL
-#define MCG_CTL_P               0x0000000000000100ULL
-#define MCG_EXT_P		(1UL<<9)
-#define MCG_EXT_CNT		(16)
-#define MCG_CMCI_P		(1UL<<10)
+#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)
 /* Other bits are reserved */
=20
 /* Bitfield of the MSR_IA32_MCG_STATUS register */




--=__PartD4FAAD58.1__=
Content-Type: text/plain; name="x86-vmce-mcg_ctl-default.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-mcg_ctl-default.patch"

x86/vMCE: don't advertise features we don't support=0A=0A... or even know =
of. Apart from CMCI, which was masked off already,=0Athis now also =
suppresses the advertising of extended state registers=0A(reading of which =
would likely be meaningless in a guest and represent=0Aan information =
leak).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch/x86/cpu/mcheck/vmce.c=0A@=
@ -457,7 +457,7 @@ int vmce_init(struct cpuinfo_x86 *c)=0A =0A     =
rdmsrl(MSR_IA32_MCG_CAP, value);=0A     /* For Guest vMCE usage */=0A-    =
g_mcg_cap =3D value & ~MCG_CMCI_P;=0A+    g_mcg_cap =3D value & (MCG_CAP_CO=
UNT | MCG_CTL_P | MCG_TES_P | MCG_SER_P);=0A     if (value & MCG_CTL_P)=0A =
        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);=0A =0A--- a/xen/arch/x86/cpu/m=
check/x86_mca.h=0A+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h=0A@@ -30,12 =
+30,13 @@=0A =0A =0A /* Bitfield of the MSR_IA32_MCG_CAP register =
*/=0A-#define MCG_SER_P               (1UL<<24)=0A #define MCG_CAP_COUNT   =
        0x00000000000000ffULL=0A-#define MCG_CTL_P               0x00000000=
00000100ULL=0A-#define MCG_EXT_P		(1UL<<9)=0A-#define =
MCG_EXT_CNT		(16)=0A-#define MCG_CMCI_P		=
(1UL<<10)=0A+#define MCG_CTL_P               (1ULL<<8)=0A+#define =
MCG_EXT_P               (1ULL<<9)=0A+#define MCG_CMCI_P              =
(1ULL<<10)=0A+#define MCG_TES_P               (1ULL<<11)=0A+#define =
MCG_EXT_CNT             16=0A+#define MCG_SER_P               (1ULL<<24)=0A=
 /* Other bits are reserved */=0A =0A /* Bitfield of the MSR_IA32_MCG_STATU=
S register */=0A
--=__PartD4FAAD58.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartD4FAAD58.1__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:00:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxcbA-0008Az-LP; Wed, 15 Feb 2012 11:00:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxcb9-0008Ae-Cd
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:00:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329303624!13468455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 15 Feb 2012 11:00:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 11:00:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 11:00:25 +0000
Message-Id: <4F3B9E580200007800073214@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 11:00:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD4FAAD58.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 1/2] x86/vMCE: don't advertise features we don't
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD4FAAD58.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... or even know of. Apart from CMCI, which was masked off already,
this now also suppresses the advertising of extended state registers
(reading of which would likely be meaningless in a guest and represent
an information leak).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -457,7 +457,7 @@ int vmce_init(struct cpuinfo_x86 *c)
=20
     rdmsrl(MSR_IA32_MCG_CAP, value);
     /* For Guest vMCE usage */
-    g_mcg_cap =3D value & ~MCG_CMCI_P;
+    g_mcg_cap =3D value & (MCG_CAP_COUNT | MCG_CTL_P | MCG_TES_P | =
MCG_SER_P);
     if (value & MCG_CTL_P)
         rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);
=20
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
@@ -30,12 +30,13 @@
=20
=20
 /* Bitfield of the MSR_IA32_MCG_CAP register */
-#define MCG_SER_P               (1UL<<24)
 #define MCG_CAP_COUNT           0x00000000000000ffULL
-#define MCG_CTL_P               0x0000000000000100ULL
-#define MCG_EXT_P		(1UL<<9)
-#define MCG_EXT_CNT		(16)
-#define MCG_CMCI_P		(1UL<<10)
+#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)
 /* Other bits are reserved */
=20
 /* Bitfield of the MSR_IA32_MCG_STATUS register */




--=__PartD4FAAD58.1__=
Content-Type: text/plain; name="x86-vmce-mcg_ctl-default.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-mcg_ctl-default.patch"

x86/vMCE: don't advertise features we don't support=0A=0A... or even know =
of. Apart from CMCI, which was masked off already,=0Athis now also =
suppresses the advertising of extended state registers=0A(reading of which =
would likely be meaningless in a guest and represent=0Aan information =
leak).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch/x86/cpu/mcheck/vmce.c=0A@=
@ -457,7 +457,7 @@ int vmce_init(struct cpuinfo_x86 *c)=0A =0A     =
rdmsrl(MSR_IA32_MCG_CAP, value);=0A     /* For Guest vMCE usage */=0A-    =
g_mcg_cap =3D value & ~MCG_CMCI_P;=0A+    g_mcg_cap =3D value & (MCG_CAP_CO=
UNT | MCG_CTL_P | MCG_TES_P | MCG_SER_P);=0A     if (value & MCG_CTL_P)=0A =
        rdmsrl(MSR_IA32_MCG_CTL, h_mcg_ctl);=0A =0A--- a/xen/arch/x86/cpu/m=
check/x86_mca.h=0A+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h=0A@@ -30,12 =
+30,13 @@=0A =0A =0A /* Bitfield of the MSR_IA32_MCG_CAP register =
*/=0A-#define MCG_SER_P               (1UL<<24)=0A #define MCG_CAP_COUNT   =
        0x00000000000000ffULL=0A-#define MCG_CTL_P               0x00000000=
00000100ULL=0A-#define MCG_EXT_P		(1UL<<9)=0A-#define =
MCG_EXT_CNT		(16)=0A-#define MCG_CMCI_P		=
(1UL<<10)=0A+#define MCG_CTL_P               (1ULL<<8)=0A+#define =
MCG_EXT_P               (1ULL<<9)=0A+#define MCG_CMCI_P              =
(1ULL<<10)=0A+#define MCG_TES_P               (1ULL<<11)=0A+#define =
MCG_EXT_CNT             16=0A+#define MCG_SER_P               (1ULL<<24)=0A=
 /* Other bits are reserved */=0A =0A /* Bitfield of the MSR_IA32_MCG_STATU=
S register */=0A
--=__PartD4FAAD58.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartD4FAAD58.1__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:01:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxcbo-0008F8-7t; Wed, 15 Feb 2012 11:01:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxcbm-0008EN-Ur
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:01:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329303662!8301262!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24767 invoked from network); 15 Feb 2012 11:01:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 11:01:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 11:01:04 +0000
Message-Id: <4F3B9E7E0200007800073218@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 11:01:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF2DC8B7E.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF2DC8B7E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This allows migration to a host with less MCA banks than the source
host had, while without this patch accesses to the excess banks' MSRs
caused #GP-s in the guest after migration (and it depended on the guest
kernel whether this would be fatal).

A fundamental question is whether we should also save/restore MCG_CTL
and MCi_CTL, as the HVM save record would better be defined to the
complete state that needs saving from the beginning (I'm unsure whether
the save/restore logic allows for future extension of an existing
record).

Of course, this change is expected to make migration from new to older
Xen impossible (again I'm unsure what the save/restore logic does with
records it doesn't even know about).

The (trivial) tools side change may seem unrelated, but the code should
have been that way from the beginning to allow the hypervisor to look
at currently unused ext_vcpucontext fields without risking to read
garbage when those fields get a meaning assigned in the future. This
isn't being enforced here - should it be? (Obviously, for backwards
compatibility, the hypervisor must assume these fields to be clear only
when the extended context's size exceeds the old original one.)

A future addition to this change might be to allow configuration of the
number of banks and other MCA capabilities for a guest before it starts
(i.e. to not inherits the values seen on the first host it runs on).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); =
break;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern unsigned int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)
            nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;
     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;
     dom_vmce(d)->nr_injection =3D 0;
=20
@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.mcg_cap =3D g_mcg_cap;
+}
+
+int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+{
+    if ( caps & ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    {
+        dprintk(XENLOG_G_ERR, "%s restore: unsupported MCA capabilities"
+                " %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",
+                is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=

+                v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);
+        return -EPERM;
+    }
+
+    v->arch.mcg_cap =3D caps;
+    return 0;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*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
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +146,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -162,39 +182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D vmce->mcg_cap;
+        *val =3D cur->arch.mcg_cap;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Always 0 if no CTL support */
-        *val =3D vmce->mcg_ctl & h_mcg_ctl;
+        if ( cur->arch.mcg_cap & MCG_CTL_P )
+            *val =3D vmce->mcg_ctl & h_mcg_ctl;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +221,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +247,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +285,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);
         /* For HVM guest, this is the point for deleting vMCE injection =
node */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +312,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : =
0;
         break;
     }
=20
@@ -301,6 +320,46 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .caps =3D v->arch.mcg_cap
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
+    {
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
+        err =3D -EINVAL;
+    }
+    else
+        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+
+    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
+    vmce_init_vcpu(v);
+
     if ( is_hvm_domain(d) )
     {
         rc =3D hvm_vcpu_initialise(v);
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->mcg_cap =3D v->arch.mcg_cap;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,10 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
+                              sizeof(evc->mcg_cap) )
+                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been =
used,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint64_t mcg_cap;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -16,7 +16,6 @@ struct bank_entry {
 struct domain_mca_msrs
 {
     /* Guest should not change below values after DOM boot up */
-    uint64_t mcg_cap;
     uint64_t mcg_ctl;
     uint64_t mcg_status;
     uint64_t *mci_ctl;
@@ -28,6 +27,8 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
+extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint64_t caps;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint64_aligned_t mcg_cap;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;



--=__PartF2DC8B7E.1__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

x86/vMCE: save/restore MCA capabilities=0A=0AThis allows migration to a =
host with less MCA banks than the source=0Ahost had, while without this =
patch accesses to the excess banks' MSRs=0Acaused #GP-s in the guest after =
migration (and it depended on the guest=0Akernel whether this would be =
fatal).=0A=0AA fundamental question is whether we should also save/restore =
MCG_CTL=0Aand MCi_CTL, as the HVM save record would better be defined to =
the=0Acomplete state that needs saving from the beginning (I'm unsure =
whether=0Athe save/restore logic allows for future extension of an =
existing=0Arecord).=0A=0AOf course, this change is expected to make =
migration from new to older=0AXen impossible (again I'm unsure what the =
save/restore logic does with=0Arecords it doesn't even know about).=0A=0ATh=
e (trivial) tools side change may seem unrelated, but the code should=0Ahav=
e been that way from the beginning to allow the hypervisor to look=0Aat =
currently unused ext_vcpucontext fields without risking to read=0Agarbage =
when those fields get a meaning assigned in the future. This=0Aisn't being =
enforced here - should it be? (Obviously, for backwards=0Acompatibility, =
the hypervisor must assume these fields to be clear only=0Awhen the =
extended context's size exceeds the old original one.)=0A=0AA future =
addition to this change might be to allow configuration of the=0Anumber of =
banks and other MCA capabilities for a guest before it starts=0A(i.e. to =
not inherits the values seen on the first host it runs on).=0A=0ASigned-off=
-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/libxc/xc_domain_save.=
c=0A+++ b/tools/libxc/xc_domain_save.c=0A@@ -1879,6 +1879,7 @@ int =
xc_domain_save(xc_interface *xch, in=0A =0A         domctl.cmd =3D =
XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =3D dom;=0A+      =
  memset(&domctl.u, 0, sizeof(domctl.u));=0A         domctl.u.ext_vcpuconte=
xt.vcpu =3D i;=0A         if ( xc_domctl(xch, &domctl) < 0 )=0A         =
{=0A--- a/tools/misc/xen-hvmctx.c=0A+++ b/tools/misc/xen-hvmctx.c=0A@@ =
-383,6 +383,13 @@ static void dump_viridian_vcpu(void)=0A            =
(unsigned long long) p.apic_assist);           =0A }=0A =0A+static void =
dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMCE_VCPU) p;=0A+    =
READ(p);=0A+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);=0A+}=
=0A+=0A int main(int argc, char **argv)=0A {=0A     int entry, domid;=0A@@ =
-449,6 +456,7 @@ int main(int argc, char **argv)=0A         case HVM_SAVE_C=
ODE(MTRR): dump_mtrr(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_DOMAI=
N): dump_viridian_domain(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_V=
CPU): dump_viridian_vcpu(); break;=0A+        case HVM_SAVE_CODE(VMCE_VCPU)=
: dump_vmce_vcpu(); break;=0A         case HVM_SAVE_CODE(END): break;=0A   =
      default:=0A             printf(" ** Don't understand type %u: =
skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.h=0A+++ b/xen/arch/x86/cpu=
/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define _MCE_H=0A =0A #include =
<xen/init.h>=0A+#include <xen/sched.h>=0A #include <xen/smp.h>=0A #include =
<asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 +55,8 @@ int unmmap_brok=
en_page(struct domain *d,=0A u64 mce_cap_init(void);=0A extern unsigned =
int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);=0A-=
int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int intel_mce_rdmsr(con=
st struct vcpu *, uint32_t msr, uint64_t *val);=0A+int intel_mce_wrmsr(stru=
ct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct mcinfo_extended =
*intel_get_extended_msrs(=0A     struct mcinfo_global *mig, struct mc_info =
*mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban=0A =
=0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =0A-static inline int =
mce_vendor_bank_msr(uint32_t msr)=0A+static inline int mce_vendor_bank_msr(=
const struct vcpu *v, uint32_t msr)=0A {=0A     if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D MSR_IA32_MC0_CTL2 && =
msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+         msr >=3D MSR_IA32_MC=
0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COU=
NT) )=0A           return 1;=0A     return 0;=0A }=0A =0A-static inline =
int mce_bank_msr(uint32_t msr)=0A+static inline int mce_bank_msr(const =
struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr >=3D MSR_IA32_MC0_CTL =
&& msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-        mce_vendor_bank_msr(=
msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+          msr < =
MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||=0A+         =
mce_vendor_bank_msr(v, msr) )=0A         return 1;=0A     return 0;=0A =
}=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cpu/mche=
ck/mce_intel.c=0A@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init=
(struc=0A }=0A =0A /* intel specific MCA MSR */=0A-int intel_mce_wrmsr(uint=
32_t msr, uint64_t val)=0A+int intel_mce_wrmsr(struct vcpu *v, uint32_t =
msr, uint64_t val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
write this MSR!\n");=0A@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t=
 msr, uint64=0A     return ret;=0A }=0A =0A-int intel_mce_rdmsr(uint32_t =
msr, uint64_t *val)=0A+int intel_mce_rdmsr(const struct vcpu *v, uint32_t =
msr, uint64_t *val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch=
/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A #include <xen/delay.h>=0A =
#include <xen/smp.h>=0A #include <xen/mm.h>=0A+#include <xen/hvm/save.h>=0A=
 #include <asm/processor.h>=0A #include <public/sysctl.h>=0A #include =
<asm/system.h>=0A@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)=0A  =
          nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));=0A =0A     =
dom_vmce(d)->mcg_status =3D 0x0;=0A-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;=
=0A     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;=0A     dom_vmce(d)->nr_inj=
ection =3D 0;=0A =0A@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct =
domain *d)=0A     dom_vmce(d) =3D NULL;=0A }=0A =0A-static int bank_mce_rdm=
sr(struct domain *d, uint32_t msr, uint64_t *val)=0A+void vmce_init_vcpu(st=
ruct vcpu *v)=0A {=0A-    int bank, ret =3D 1;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    v->arch.mcg_cap =3D g_mcg_cap;=0A+}=0A+=0A+=
int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)=0A+{=0A+    if ( caps =
& ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )=0A+    {=0A+        dprintk(XE=
NLOG_G_ERR, "%s restore: unsupported MCA capabilities"=0A+                =
" %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",=0A+                =
is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=0A+             =
   v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);=0A+        return -EPERM;=0A+  =
  }=0A+=0A+    v->arch.mcg_cap =3D caps;=0A+    return 0;=0A+}=0A+=0A+stati=
c int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)=0A+{=0A+    int ret =3D 1;=0A+    unsigned int bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->=
domain);=0A     struct bank_entry *entry;=0A =0A-    bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        =
return -1;=0A+    *val =3D 0;=0A =0A     switch ( msr & (MSR_IA32_MC0_CTL =
| 3) )=0A     {=0A     case MSR_IA32_MC0_CTL:=0A-        *val =3D =
vmce->mci_ctl[bank] &=0A-            (h_mci_ctrl ? h_mci_ctrl[bank] : =
~0UL);=0A+        if ( bank < nr_mce_banks )=0A+            *val =3D =
vmce->mci_ctl[bank] &=0A+                   (h_mci_ctrl ? h_mci_ctrl[bank] =
: ~0UL);=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64=
"\n",=0A                    bank, *val);=0A         break;=0A@@ -126,7 =
+146,7 @@ static int bank_mce_rdmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_rdmsr(msr, val);=0A+            ret =3D =
intel_mce_rdmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(st=
ruct domain =0A  */=0A int vmce_rdmsr(uint32_t msr, uint64_t *val)=0A =
{=0A-    struct domain *d =3D current->domain;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    const struct vcpu *cur =3D current;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=0A     int ret =3D =
1;=0A =0A     *val =3D 0;=0A =0A-    spin_lock(&dom_vmce(d)->lock);=0A+    =
spin_lock(&vmce->lock);=0A =0A     switch ( msr )=0A     {=0A@@ -162,39 =
+182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A                     =
   "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);=0A         break;=0A     =
case MSR_IA32_MCG_CAP:=0A-        *val =3D vmce->mcg_cap;=0A+        *val =
=3D cur->arch.mcg_cap;=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr =
MCG_CAP 0x%"PRIx64"\n",=0A                    *val);=0A         break;=0A  =
   case MSR_IA32_MCG_CTL:=0A         /* Always 0 if no CTL support */=0A-  =
      *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A+        if ( cur->arch.mcg_cap=
 & MCG_CTL_P )=0A+            *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A       =
  mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",=0A           =
         *val);=0A         break;=0A     default:=0A-        ret =3D =
mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;=0A+        ret =3D =
mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;=0A         =
break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(d)->lock);=0A+    =
spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =0A-static int =
bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static int bank_mce_w=
rmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return -EINVAL;=0A-=0A  =
   switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case MSR_IA32_MC=
0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        if ( bank < =
nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A         =
break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the first entry =
of the list, it corresponds to current=0A@@ -202,9 +221,9 @@ static int =
bank_mce_wrmsr(struct domain =0A          * the guest, this node will be =
deleted.=0A          * Only error bank is written. Non-error banks simply =
return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d)->impact_hea=
der) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A         =
{=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.next,=0A+ =
           entry =3D list_entry(vmce->impact_header.next,=0A               =
                 struct bank_entry, list);=0A             if ( entry->bank =
=3D=3D bank )=0A                 entry->mci_status =3D val;=0A@@ -228,7 =
+247,7 @@ static int bank_mce_wrmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+            ret =3D =
intel_mce_wrmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(stru=
ct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 val)=0A {=0A-    struct =
domain *d =3D current->domain;=0A+    struct vcpu *cur =3D current;=0A     =
struct bank_entry *entry =3D NULL;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=
=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap )=0A@@ -266,7 +285,7 @@ =
int vmce_wrmsr(u32 msr, u64 val)=0A         vmce->mcg_status =3D val;=0A   =
      mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);=0A         /* For HVM guest, this is the point for deleting vMCE =
injection node */=0A-        if ( d->is_hvm && (vmce->nr_injection > 0) =
)=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )=0A        =
 {=0A             vmce->nr_injection--; /* Should be 0 */=0A             =
if ( !list_empty(&vmce->impact_header) )=0A@@ -293,7 +312,7 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D -1;=0A         break;=0A   =
  default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A@@ -301,6 +320,46 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A     return ret;=0A }=0A =0A+static int =
vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)=0A+{=0A+    =
struct vcpu *v;=0A+    int err =3D 0;=0A+=0A+    for_each_vcpu( d, v ) =
{=0A+        struct hvm_vmce_vcpu ctxt =3D {=0A+            .caps =3D =
v->arch.mcg_cap=0A+        };=0A+=0A+        err =3D hvm_save_entry(VMCE_VC=
PU, v->vcpu_id, h, &ctxt);=0A+        if ( err )=0A+            break;=0A+ =
   }=0A+=0A+    return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(stru=
ct domain *d, hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D =
hvm_load_instance(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu =
ctxt;=0A+    int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A+    {=0A+        dprintk(XENLOG_G_ERR, =
"HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_id, =
vcpuid);=0A+        err =3D -EINVAL;=0A+    }=0A+    else=0A+        err =
=3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+=0A+    return err ?: =
vmce_restore_vcpu(v, ctxt.caps);=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE=
_VCPU, vmce_save_vcpu_ctxt,=0A+                          vmce_load_vcpu_ctx=
t, 1, HVMSR_PER_VCPU);=0A+=0A int inject_vmce(struct domain *d)=0A {=0A    =
 int cpu =3D smp_processor_id();=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -422,6 +422,8 @@ int vcpu_initialise(struct =
vcpu *v)=0A     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )=0A         return =
rc;=0A =0A+    vmce_init_vcpu(v);=0A+=0A     if ( is_hvm_domain(d) )=0A    =
 {=0A         rc =3D hvm_vcpu_initialise(v);=0A--- a/xen/arch/x86/domctl.c=
=0A+++ b/xen/arch/x86/domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domct=
l(=0A                 evc->syscall32_callback_eip    =3D 0;=0A             =
    evc->syscall32_disables_events =3D 0;=0A             }=0A+            =
evc->mcg_cap =3D v->arch.mcg_cap;=0A         }=0A         else=0A         =
{=0A             ret =3D -EINVAL;=0A-            if ( evc->size !=3D =
sizeof(*evc) )=0A+            if ( evc->size < offsetof(typeof(*evc), =
mcg_cap) )=0A                 goto ext_vcpucontext_out;=0A #ifdef =
__x86_64__=0A             if ( !is_hvm_domain(d) )=0A@@ -1059,6 +1060,10 =
@@ long arch_do_domctl(=0A                  (evc->syscall32_callback_cs & =
~3) ||=0A                  evc->syscall32_callback_eip )=0A                =
 goto ext_vcpucontext_out;=0A+=0A+            if ( evc->size >=3D =
offsetof(typeof(*evc), mcg_cap) +=0A+                              =
sizeof(evc->mcg_cap) )=0A+                ret =3D vmce_restore_vcpu(v, =
evc->mcg_cap);=0A         }=0A =0A         ret =3D 0;=0A--- a/xen/include/a=
sm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ -488,6 +488,8 @@ =
struct arch_vcpu=0A     /* This variable determines whether nonlazy =
extended state has been used,=0A      * and thus should be saved/restored. =
*/=0A     bool_t nonlazy_xstate_used;=0A+=0A+    uint64_t mcg_cap;=0A     =
=0A     struct paging_vcpu paging;=0A =0A--- a/xen/include/asm-x86/mce.h=0A=
+++ b/xen/include/asm-x86/mce.h=0A@@ -16,7 +16,6 @@ struct bank_entry {=0A =
struct domain_mca_msrs=0A {=0A     /* Guest should not change below values =
after DOM boot up */=0A-    uint64_t mcg_cap;=0A     uint64_t mcg_ctl;=0A  =
   uint64_t mcg_status;=0A     uint64_t *mci_ctl;=0A@@ -28,6 +27,8 @@ =
struct domain_mca_msrs=0A /* Guest vMCE MSRs virtualization */=0A extern =
int vmce_init_msr(struct domain *d);=0A extern void vmce_destroy_msr(struct=
 domain *d);=0A+extern void vmce_init_vcpu(struct vcpu *);=0A+extern int =
vmce_restore_vcpu(struct vcpu *, uint64_t caps);=0A extern int vmce_wrmsr(u=
int32_t msr, uint64_t val);=0A extern int vmce_rdmsr(uint32_t msr, =
uint64_t *val);=0A =0A--- a/xen/include/public/arch-x86/hvm/save.h=0A+++ =
b/xen/include/public/arch-x86/hvm/save.h=0A@@ -585,9 +585,15 @@ struct =
hvm_viridian_vcpu_context {=0A =0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, =
17, struct hvm_viridian_vcpu_context);=0A =0A+struct hvm_vmce_vcpu {=0A+   =
 uint64_t caps;=0A+};=0A+=0A+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct =
hvm_vmce_vcpu);=0A+=0A /* =0A  * Largest type-code in use=0A  */=0A-#define=
 HVM_SAVE_CODE_MAX 17=0A+#define HVM_SAVE_CODE_MAX 18=0A =0A #endif /* =
__XEN_PUBLIC_HVM_SAVE_X86_H__ */=0A--- a/xen/include/public/domctl.h=0A+++ =
b/xen/include/public/domctl.h=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_v=
cpucontext {=0A     uint32_t         vcpu;=0A     /*=0A      * SET: Size =
of struct (IN)=0A-     * GET: Size of struct (OUT)=0A+     * GET: Size of =
struct (OUT, up to 128 bytes)=0A      */=0A     uint32_t         size;=0A =
#if defined(__i386__) || defined(__x86_64__)=0A@@ -571,6 +571,7 @@ struct =
xen_domctl_ext_vcpucontext {=0A     uint16_t         sysenter_callback_cs;=
=0A     uint8_t          syscall32_disables_events;=0A     uint8_t         =
 sysenter_disables_events;=0A+    uint64_aligned_t mcg_cap;=0A #endif=0A =
};=0A typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_=
t;=0A
--=__PartF2DC8B7E.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF2DC8B7E.1__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:01:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:01:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxcbo-0008F8-7t; Wed, 15 Feb 2012 11:01:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxcbm-0008EN-Ur
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:01:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329303662!8301262!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24767 invoked from network); 15 Feb 2012 11:01:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 11:01:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 11:01:04 +0000
Message-Id: <4F3B9E7E0200007800073218@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 11:01:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF2DC8B7E.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF2DC8B7E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This allows migration to a host with less MCA banks than the source
host had, while without this patch accesses to the excess banks' MSRs
caused #GP-s in the guest after migration (and it depended on the guest
kernel whether this would be fatal).

A fundamental question is whether we should also save/restore MCG_CTL
and MCi_CTL, as the HVM save record would better be defined to the
complete state that needs saving from the beginning (I'm unsure whether
the save/restore logic allows for future extension of an existing
record).

Of course, this change is expected to make migration from new to older
Xen impossible (again I'm unsure what the save/restore logic does with
records it doesn't even know about).

The (trivial) tools side change may seem unrelated, but the code should
have been that way from the beginning to allow the hypervisor to look
at currently unused ext_vcpucontext fields without risking to read
garbage when those fields get a meaning assigned in the future. This
isn't being enforced here - should it be? (Obviously, for backwards
compatibility, the hypervisor must assume these fields to be clear only
when the extended context's size exceeds the old original one.)

A future addition to this change might be to allow configuration of the
number of banks and other MCA capabilities for a guest before it starts
(i.e. to not inherits the values seen on the first host it runs on).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); =
break;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern unsigned int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)
            nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));
=20
     dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;
     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;
     dom_vmce(d)->nr_injection =3D 0;
=20
@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.mcg_cap =3D g_mcg_cap;
+}
+
+int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+{
+    if ( caps & ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    {
+        dprintk(XENLOG_G_ERR, "%s restore: unsupported MCA capabilities"
+                " %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",
+                is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=

+                v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);
+        return -EPERM;
+    }
+
+    v->arch.mcg_cap =3D caps;
+    return 0;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*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
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +146,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -162,39 +182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D vmce->mcg_cap;
+        *val =3D cur->arch.mcg_cap;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Always 0 if no CTL support */
-        *val =3D vmce->mcg_ctl & h_mcg_ctl;
+        if ( cur->arch.mcg_cap & MCG_CTL_P )
+            *val =3D vmce->mcg_ctl & h_mcg_ctl;
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +221,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +247,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +285,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);
         /* For HVM guest, this is the point for deleting vMCE injection =
node */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +312,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : =
0;
         break;
     }
=20
@@ -301,6 +320,46 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .caps =3D v->arch.mcg_cap
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
+    {
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
+        err =3D -EINVAL;
+    }
+    else
+        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+
+    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -422,6 +422,8 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
+    vmce_init_vcpu(v);
+
     if ( is_hvm_domain(d) )
     {
         rc =3D hvm_vcpu_initialise(v);
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->mcg_cap =3D v->arch.mcg_cap;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,10 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
+                              sizeof(evc->mcg_cap) )
+                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been =
used,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint64_t mcg_cap;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -16,7 +16,6 @@ struct bank_entry {
 struct domain_mca_msrs
 {
     /* Guest should not change below values after DOM boot up */
-    uint64_t mcg_cap;
     uint64_t mcg_ctl;
     uint64_t mcg_status;
     uint64_t *mci_ctl;
@@ -28,6 +27,8 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
+extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint64_t caps;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,7 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint64_aligned_t mcg_cap;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;



--=__PartF2DC8B7E.1__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

x86/vMCE: save/restore MCA capabilities=0A=0AThis allows migration to a =
host with less MCA banks than the source=0Ahost had, while without this =
patch accesses to the excess banks' MSRs=0Acaused #GP-s in the guest after =
migration (and it depended on the guest=0Akernel whether this would be =
fatal).=0A=0AA fundamental question is whether we should also save/restore =
MCG_CTL=0Aand MCi_CTL, as the HVM save record would better be defined to =
the=0Acomplete state that needs saving from the beginning (I'm unsure =
whether=0Athe save/restore logic allows for future extension of an =
existing=0Arecord).=0A=0AOf course, this change is expected to make =
migration from new to older=0AXen impossible (again I'm unsure what the =
save/restore logic does with=0Arecords it doesn't even know about).=0A=0ATh=
e (trivial) tools side change may seem unrelated, but the code should=0Ahav=
e been that way from the beginning to allow the hypervisor to look=0Aat =
currently unused ext_vcpucontext fields without risking to read=0Agarbage =
when those fields get a meaning assigned in the future. This=0Aisn't being =
enforced here - should it be? (Obviously, for backwards=0Acompatibility, =
the hypervisor must assume these fields to be clear only=0Awhen the =
extended context's size exceeds the old original one.)=0A=0AA future =
addition to this change might be to allow configuration of the=0Anumber of =
banks and other MCA capabilities for a guest before it starts=0A(i.e. to =
not inherits the values seen on the first host it runs on).=0A=0ASigned-off=
-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/libxc/xc_domain_save.=
c=0A+++ b/tools/libxc/xc_domain_save.c=0A@@ -1879,6 +1879,7 @@ int =
xc_domain_save(xc_interface *xch, in=0A =0A         domctl.cmd =3D =
XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =3D dom;=0A+      =
  memset(&domctl.u, 0, sizeof(domctl.u));=0A         domctl.u.ext_vcpuconte=
xt.vcpu =3D i;=0A         if ( xc_domctl(xch, &domctl) < 0 )=0A         =
{=0A--- a/tools/misc/xen-hvmctx.c=0A+++ b/tools/misc/xen-hvmctx.c=0A@@ =
-383,6 +383,13 @@ static void dump_viridian_vcpu(void)=0A            =
(unsigned long long) p.apic_assist);           =0A }=0A =0A+static void =
dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMCE_VCPU) p;=0A+    =
READ(p);=0A+    printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);=0A+}=
=0A+=0A int main(int argc, char **argv)=0A {=0A     int entry, domid;=0A@@ =
-449,6 +456,7 @@ int main(int argc, char **argv)=0A         case HVM_SAVE_C=
ODE(MTRR): dump_mtrr(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_DOMAI=
N): dump_viridian_domain(); break;=0A         case HVM_SAVE_CODE(VIRIDIAN_V=
CPU): dump_viridian_vcpu(); break;=0A+        case HVM_SAVE_CODE(VMCE_VCPU)=
: dump_vmce_vcpu(); break;=0A         case HVM_SAVE_CODE(END): break;=0A   =
      default:=0A             printf(" ** Don't understand type %u: =
skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.h=0A+++ b/xen/arch/x86/cpu=
/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define _MCE_H=0A =0A #include =
<xen/init.h>=0A+#include <xen/sched.h>=0A #include <xen/smp.h>=0A #include =
<asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 +55,8 @@ int unmmap_brok=
en_page(struct domain *d,=0A u64 mce_cap_init(void);=0A extern unsigned =
int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);=0A-=
int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int intel_mce_rdmsr(con=
st struct vcpu *, uint32_t msr, uint64_t *val);=0A+int intel_mce_wrmsr(stru=
ct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct mcinfo_extended =
*intel_get_extended_msrs(=0A     struct mcinfo_global *mig, struct mc_info =
*mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban=0A =
=0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =0A-static inline int =
mce_vendor_bank_msr(uint32_t msr)=0A+static inline int mce_vendor_bank_msr(=
const struct vcpu *v, uint32_t msr)=0A {=0A     if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D MSR_IA32_MC0_CTL2 && =
msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+         msr >=3D MSR_IA32_MC=
0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COU=
NT) )=0A           return 1;=0A     return 0;=0A }=0A =0A-static inline =
int mce_bank_msr(uint32_t msr)=0A+static inline int mce_bank_msr(const =
struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr >=3D MSR_IA32_MC0_CTL =
&& msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-        mce_vendor_bank_msr(=
msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+          msr < =
MSR_IA32_MCx_CTL(v->arch.mcg_cap & MCG_CAP_COUNT)) ||=0A+         =
mce_vendor_bank_msr(v, msr) )=0A         return 1;=0A     return 0;=0A =
}=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cpu/mche=
ck/mce_intel.c=0A@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init=
(struc=0A }=0A =0A /* intel specific MCA MSR */=0A-int intel_mce_wrmsr(uint=
32_t msr, uint64_t val)=0A+int intel_mce_wrmsr(struct vcpu *v, uint32_t =
msr, uint64_t val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
write this MSR!\n");=0A@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t=
 msr, uint64=0A     return ret;=0A }=0A =0A-int intel_mce_rdmsr(uint32_t =
msr, uint64_t *val)=0A+int intel_mce_rdmsr(const struct vcpu *v, uint32_t =
msr, uint64_t *val)=0A {=0A     int ret =3D 0;=0A =0A-    if (msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( =
msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.m=
cg_cap & MCG_CAP_COUNT) )=0A     {=0A         mce_printk(MCE_QUIET, "We =
have disabled CMCI capability, "=0A                  "Guest should not =
read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/vmce.c=0A+++ b/xen/arch=
/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A #include <xen/delay.h>=0A =
#include <xen/smp.h>=0A #include <xen/mm.h>=0A+#include <xen/hvm/save.h>=0A=
 #include <asm/processor.h>=0A #include <public/sysctl.h>=0A #include =
<asm/system.h>=0A@@ -42,7 +43,6 @@ int vmce_init_msr(struct domain *d)=0A  =
          nr_mce_banks * sizeof(*dom_vmce(d)->mci_ctl));=0A =0A     =
dom_vmce(d)->mcg_status =3D 0x0;=0A-    dom_vmce(d)->mcg_cap =3D g_mcg_cap;=
=0A     dom_vmce(d)->mcg_ctl =3D ~(uint64_t)0x0;=0A     dom_vmce(d)->nr_inj=
ection =3D 0;=0A =0A@@ -61,21 +61,41 @@ void vmce_destroy_msr(struct =
domain *d)=0A     dom_vmce(d) =3D NULL;=0A }=0A =0A-static int bank_mce_rdm=
sr(struct domain *d, uint32_t msr, uint64_t *val)=0A+void vmce_init_vcpu(st=
ruct vcpu *v)=0A {=0A-    int bank, ret =3D 1;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    v->arch.mcg_cap =3D g_mcg_cap;=0A+}=0A+=0A+=
int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)=0A+{=0A+    if ( caps =
& ~g_mcg_cap & ~MCG_CAP_COUNT & ~MCG_CTL_P )=0A+    {=0A+        dprintk(XE=
NLOG_G_ERR, "%s restore: unsupported MCA capabilities"=0A+                =
" %#" PRIx64 " for d%d:v%u (supported: %#Lx)\n",=0A+                =
is_hvm_vcpu(v) ? "HVM" : "PV", caps, v->domain->domain_id,=0A+             =
   v->vcpu_id, g_mcg_cap & ~MCG_CAP_COUNT);=0A+        return -EPERM;=0A+  =
  }=0A+=0A+    v->arch.mcg_cap =3D caps;=0A+    return 0;=0A+}=0A+=0A+stati=
c int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)=0A+{=0A+    int ret =3D 1;=0A+    unsigned int bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->=
domain);=0A     struct bank_entry *entry;=0A =0A-    bank =3D (msr - =
MSR_IA32_MC0_CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        =
return -1;=0A+    *val =3D 0;=0A =0A     switch ( msr & (MSR_IA32_MC0_CTL =
| 3) )=0A     {=0A     case MSR_IA32_MC0_CTL:=0A-        *val =3D =
vmce->mci_ctl[bank] &=0A-            (h_mci_ctrl ? h_mci_ctrl[bank] : =
~0UL);=0A+        if ( bank < nr_mce_banks )=0A+            *val =3D =
vmce->mci_ctl[bank] &=0A+                   (h_mci_ctrl ? h_mci_ctrl[bank] =
: ~0UL);=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64=
"\n",=0A                    bank, *val);=0A         break;=0A@@ -126,7 =
+146,7 @@ static int bank_mce_rdmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_rdmsr(msr, val);=0A+            ret =3D =
intel_mce_rdmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -145,13 +165,13 @@ static int bank_mce_rdmsr(st=
ruct domain =0A  */=0A int vmce_rdmsr(uint32_t msr, uint64_t *val)=0A =
{=0A-    struct domain *d =3D current->domain;=0A-    struct domain_mca_msr=
s *vmce =3D dom_vmce(d);=0A+    const struct vcpu *cur =3D current;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=0A     int ret =3D =
1;=0A =0A     *val =3D 0;=0A =0A-    spin_lock(&dom_vmce(d)->lock);=0A+    =
spin_lock(&vmce->lock);=0A =0A     switch ( msr )=0A     {=0A@@ -162,39 =
+182,38 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A                     =
   "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);=0A         break;=0A     =
case MSR_IA32_MCG_CAP:=0A-        *val =3D vmce->mcg_cap;=0A+        *val =
=3D cur->arch.mcg_cap;=0A         mce_printk(MCE_VERBOSE, "MCE: rdmsr =
MCG_CAP 0x%"PRIx64"\n",=0A                    *val);=0A         break;=0A  =
   case MSR_IA32_MCG_CTL:=0A         /* Always 0 if no CTL support */=0A-  =
      *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A+        if ( cur->arch.mcg_cap=
 & MCG_CTL_P )=0A+            *val =3D vmce->mcg_ctl & h_mcg_ctl;=0A       =
  mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",=0A           =
         *val);=0A         break;=0A     default:=0A-        ret =3D =
mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;=0A+        ret =3D =
mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;=0A         =
break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(d)->lock);=0A+    =
spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =0A-static int =
bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static int bank_mce_w=
rmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return -EINVAL;=0A-=0A  =
   switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case MSR_IA32_MC=
0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        if ( bank < =
nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A         =
break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the first entry =
of the list, it corresponds to current=0A@@ -202,9 +221,9 @@ static int =
bank_mce_wrmsr(struct domain =0A          * the guest, this node will be =
deleted.=0A          * Only error bank is written. Non-error banks simply =
return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d)->impact_hea=
der) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A         =
{=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.next,=0A+ =
           entry =3D list_entry(vmce->impact_header.next,=0A               =
                 struct bank_entry, list);=0A             if ( entry->bank =
=3D=3D bank )=0A                 entry->mci_status =3D val;=0A@@ -228,7 =
+247,7 @@ static int bank_mce_wrmsr(struct domain =0A         switch ( =
boot_cpu_data.x86_vendor )=0A         {=0A         case X86_VENDOR_INTEL:=
=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+            ret =3D =
intel_mce_wrmsr(v, msr, val);=0A             break;=0A         default:=0A =
            ret =3D 0;=0A@@ -247,9 +266,9 @@ static int bank_mce_wrmsr(stru=
ct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 val)=0A {=0A-    struct =
domain *d =3D current->domain;=0A+    struct vcpu *cur =3D current;=0A     =
struct bank_entry *entry =3D NULL;=0A-    struct domain_mca_msrs *vmce =3D =
dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);=
=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap )=0A@@ -266,7 +285,7 @@ =
int vmce_wrmsr(u32 msr, u64 val)=0A         vmce->mcg_status =3D val;=0A   =
      mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);=0A         /* For HVM guest, this is the point for deleting vMCE =
injection node */=0A-        if ( d->is_hvm && (vmce->nr_injection > 0) =
)=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )=0A        =
 {=0A             vmce->nr_injection--; /* Should be 0 */=0A             =
if ( !list_empty(&vmce->impact_header) )=0A@@ -293,7 +312,7 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D -1;=0A         break;=0A   =
  default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A@@ -301,6 +320,46 @@ int =
vmce_wrmsr(u32 msr, u64 val)=0A     return ret;=0A }=0A =0A+static int =
vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)=0A+{=0A+    =
struct vcpu *v;=0A+    int err =3D 0;=0A+=0A+    for_each_vcpu( d, v ) =
{=0A+        struct hvm_vmce_vcpu ctxt =3D {=0A+            .caps =3D =
v->arch.mcg_cap=0A+        };=0A+=0A+        err =3D hvm_save_entry(VMCE_VC=
PU, v->vcpu_id, h, &ctxt);=0A+        if ( err )=0A+            break;=0A+ =
   }=0A+=0A+    return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(stru=
ct domain *d, hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D =
hvm_load_instance(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu =
ctxt;=0A+    int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A+    {=0A+        dprintk(XENLOG_G_ERR, =
"HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_id, =
vcpuid);=0A+        err =3D -EINVAL;=0A+    }=0A+    else=0A+        err =
=3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+=0A+    return err ?: =
vmce_restore_vcpu(v, ctxt.caps);=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE=
_VCPU, vmce_save_vcpu_ctxt,=0A+                          vmce_load_vcpu_ctx=
t, 1, HVMSR_PER_VCPU);=0A+=0A int inject_vmce(struct domain *d)=0A {=0A    =
 int cpu =3D smp_processor_id();=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -422,6 +422,8 @@ int vcpu_initialise(struct =
vcpu *v)=0A     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )=0A         return =
rc;=0A =0A+    vmce_init_vcpu(v);=0A+=0A     if ( is_hvm_domain(d) )=0A    =
 {=0A         rc =3D hvm_vcpu_initialise(v);=0A--- a/xen/arch/x86/domctl.c=
=0A+++ b/xen/arch/x86/domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domct=
l(=0A                 evc->syscall32_callback_eip    =3D 0;=0A             =
    evc->syscall32_disables_events =3D 0;=0A             }=0A+            =
evc->mcg_cap =3D v->arch.mcg_cap;=0A         }=0A         else=0A         =
{=0A             ret =3D -EINVAL;=0A-            if ( evc->size !=3D =
sizeof(*evc) )=0A+            if ( evc->size < offsetof(typeof(*evc), =
mcg_cap) )=0A                 goto ext_vcpucontext_out;=0A #ifdef =
__x86_64__=0A             if ( !is_hvm_domain(d) )=0A@@ -1059,6 +1060,10 =
@@ long arch_do_domctl(=0A                  (evc->syscall32_callback_cs & =
~3) ||=0A                  evc->syscall32_callback_eip )=0A                =
 goto ext_vcpucontext_out;=0A+=0A+            if ( evc->size >=3D =
offsetof(typeof(*evc), mcg_cap) +=0A+                              =
sizeof(evc->mcg_cap) )=0A+                ret =3D vmce_restore_vcpu(v, =
evc->mcg_cap);=0A         }=0A =0A         ret =3D 0;=0A--- a/xen/include/a=
sm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ -488,6 +488,8 @@ =
struct arch_vcpu=0A     /* This variable determines whether nonlazy =
extended state has been used,=0A      * and thus should be saved/restored. =
*/=0A     bool_t nonlazy_xstate_used;=0A+=0A+    uint64_t mcg_cap;=0A     =
=0A     struct paging_vcpu paging;=0A =0A--- a/xen/include/asm-x86/mce.h=0A=
+++ b/xen/include/asm-x86/mce.h=0A@@ -16,7 +16,6 @@ struct bank_entry {=0A =
struct domain_mca_msrs=0A {=0A     /* Guest should not change below values =
after DOM boot up */=0A-    uint64_t mcg_cap;=0A     uint64_t mcg_ctl;=0A  =
   uint64_t mcg_status;=0A     uint64_t *mci_ctl;=0A@@ -28,6 +27,8 @@ =
struct domain_mca_msrs=0A /* Guest vMCE MSRs virtualization */=0A extern =
int vmce_init_msr(struct domain *d);=0A extern void vmce_destroy_msr(struct=
 domain *d);=0A+extern void vmce_init_vcpu(struct vcpu *);=0A+extern int =
vmce_restore_vcpu(struct vcpu *, uint64_t caps);=0A extern int vmce_wrmsr(u=
int32_t msr, uint64_t val);=0A extern int vmce_rdmsr(uint32_t msr, =
uint64_t *val);=0A =0A--- a/xen/include/public/arch-x86/hvm/save.h=0A+++ =
b/xen/include/public/arch-x86/hvm/save.h=0A@@ -585,9 +585,15 @@ struct =
hvm_viridian_vcpu_context {=0A =0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, =
17, struct hvm_viridian_vcpu_context);=0A =0A+struct hvm_vmce_vcpu {=0A+   =
 uint64_t caps;=0A+};=0A+=0A+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct =
hvm_vmce_vcpu);=0A+=0A /* =0A  * Largest type-code in use=0A  */=0A-#define=
 HVM_SAVE_CODE_MAX 17=0A+#define HVM_SAVE_CODE_MAX 18=0A =0A #endif /* =
__XEN_PUBLIC_HVM_SAVE_X86_H__ */=0A--- a/xen/include/public/domctl.h=0A+++ =
b/xen/include/public/domctl.h=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_v=
cpucontext {=0A     uint32_t         vcpu;=0A     /*=0A      * SET: Size =
of struct (IN)=0A-     * GET: Size of struct (OUT)=0A+     * GET: Size of =
struct (OUT, up to 128 bytes)=0A      */=0A     uint32_t         size;=0A =
#if defined(__i386__) || defined(__x86_64__)=0A@@ -571,6 +571,7 @@ struct =
xen_domctl_ext_vcpucontext {=0A     uint16_t         sysenter_callback_cs;=
=0A     uint8_t          syscall32_disables_events;=0A     uint8_t         =
 sysenter_disables_events;=0A+    uint64_aligned_t mcg_cap;=0A #endif=0A =
};=0A typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_=
t;=0A
--=__PartF2DC8B7E.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF2DC8B7E.1__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:14:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11: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.xensource.com>)
	id 1RxcoT-0000J1-6Y; Wed, 15 Feb 2012 11:14:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxcoR-0000Im-Oq
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:14:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329304449!12978079!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14347 invoked from network); 15 Feb 2012 11:14:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 11:14:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10709292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:14:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:14:09 +0000
Date: Wed, 15 Feb 2012 11:18:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>
In-Reply-To: <90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.00.1202151116130.7456@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Zaborowski, Andrew" <andrew.zaborowski@intel.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Lv, Zhiyuan wrote:
> Hello,
> 
> Another related work is as below:
> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01027.html
> 
> Similar to VMGL, it is an API remoting approach but not based on chromium. Another difference is that it does not require X server extensions. Just for your reference. Thanks!

Thanks for the very useful link.
Ideally instead of virtio it would be based on a Xen frontend/backend
pair of paravirtualized devices, so that it would work with PV guests
too (virtio only works with Xen HVM guests).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:14:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11: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.xensource.com>)
	id 1RxcoT-0000J1-6Y; Wed, 15 Feb 2012 11:14:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxcoR-0000Im-Oq
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:14:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329304449!12978079!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14347 invoked from network); 15 Feb 2012 11:14:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 11:14:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10709292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:14:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:14:09 +0000
Date: Wed, 15 Feb 2012 11:18:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>
In-Reply-To: <90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.00.1202151116130.7456@kaball-desktop>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>
	<90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Zaborowski, Andrew" <andrew.zaborowski@intel.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Jacobs Jordi <Jordi.Jacobs@howest.be>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, Lv, Zhiyuan wrote:
> Hello,
> 
> Another related work is as below:
> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01027.html
> 
> Similar to VMGL, it is an API remoting approach but not based on chromium. Another difference is that it does not require X server extensions. Just for your reference. Thanks!

Thanks for the very useful link.
Ideally instead of virtio it would be based on a Xen frontend/backend
pair of paravirtualized devices, so that it would work with PV guests
too (virtio only works with Xen HVM guests).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:46:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxdJ0-0001IB-03; Wed, 15 Feb 2012 11:45:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdIy-0001Hy-RG
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:45:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329306341!11594450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13222 invoked from network); 15 Feb 2012 11:45:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 11:45:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10711060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:45:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:45:41 +0000
Date: Wed, 15 Feb 2012 11:49:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Mukesh Rathor <mukesh.rathor@oracle.com>
In-Reply-To: <20120214185314.5546a24e@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.00.1202151129570.7456@kaball-desktop>
References: <20120214185314.5546a24e@mantra.us.oracle.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] HYBRID: memory mapped IO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 15 Feb 2012, Mukesh Rathor wrote:
> Hi Guys,
> 
> ich_force_enable_hpet() in linux wants to do mmio. It calls ioremap_pte_range
> to map phys addr to a VA. Xen then updates the PV dom0's L1 with
> requested io attributes. I'm trying to figure how to do this for PV in
> HVM container. I was hoping to update the EPT directly.

This issue is going to come up with all the PCI devices too, isn't it?
Dom0 is going to read/write the PCI config space and ioremap the memory
of the device, memory that is not part of the EPT pagetables yet.
This issue also happens every time an HVM guest tries to remap a memory
region of a passed through PCI device.
In this case QEMU calls xc_domain_memory_mapping, that in Xen becomes
XEN_DOMCTL_memory_mapping, that is implemented as set_mmio_p2m_entry.
So maybe you just need to call set_mmio_p2m_entry.



> I was thinking of just doing guest_physmap_add_entry() but the mfn is not
> going to be valid. Is there any other code path that will let me do this?

Why the mfn is not going to be valid?
Shouldn't dom0 be able to find out exactly where the hpet is?


> Another possiblity would be handle_mmio(). 

I would avoid that if possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 11:46:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 11:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxdJ0-0001IB-03; Wed, 15 Feb 2012 11:45:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdIy-0001Hy-RG
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 11:45:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329306341!11594450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13222 invoked from network); 15 Feb 2012 11:45:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 11:45:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="10711060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:45:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:45:41 +0000
Date: Wed, 15 Feb 2012 11:49:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Mukesh Rathor <mukesh.rathor@oracle.com>
In-Reply-To: <20120214185314.5546a24e@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.00.1202151129570.7456@kaball-desktop>
References: <20120214185314.5546a24e@mantra.us.oracle.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] HYBRID: memory mapped IO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 15 Feb 2012, Mukesh Rathor wrote:
> Hi Guys,
> 
> ich_force_enable_hpet() in linux wants to do mmio. It calls ioremap_pte_range
> to map phys addr to a VA. Xen then updates the PV dom0's L1 with
> requested io attributes. I'm trying to figure how to do this for PV in
> HVM container. I was hoping to update the EPT directly.

This issue is going to come up with all the PCI devices too, isn't it?
Dom0 is going to read/write the PCI config space and ioremap the memory
of the device, memory that is not part of the EPT pagetables yet.
This issue also happens every time an HVM guest tries to remap a memory
region of a passed through PCI device.
In this case QEMU calls xc_domain_memory_mapping, that in Xen becomes
XEN_DOMCTL_memory_mapping, that is implemented as set_mmio_p2m_entry.
So maybe you just need to call set_mmio_p2m_entry.



> I was thinking of just doing guest_physmap_add_entry() but the mfn is not
> going to be valid. Is there any other code path that will let me do this?

Why the mfn is not going to be valid?
Shouldn't dom0 be able to find out exactly where the hpet is?


> Another possiblity would be handle_mmio(). 

I would avoid that if possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:04:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdaZ-0001uP-Vg; Wed, 15 Feb 2012 12:03:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RxdaY-0001uK-OX
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:03:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329307431!13404107!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32736 invoked from network); 15 Feb 2012 12:03:51 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.207)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Feb 2012 12:03:51 -0000
Received: from mail107-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 12:03:51 +0000
Received: from mail107-am1 (localhost [127.0.0.1])	by
	mail107-am1-R.bigfish.com (Postfix) with ESMTP id A765246054A;
	Wed, 15 Feb 2012 12:03:50 +0000 (UTC)
X-SpamScore: -7
X-BigFish: VPS-7(zzbb2dI9371I103dK1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail107-am1 (localhost.localdomain [127.0.0.1]) by mail107-am1
	(MessageSwitch) id 132930742896622_23640;
	Wed, 15 Feb 2012 12:03:48 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.228])	by
	mail107-am1.bigfish.com (Postfix) with ESMTP id 129A5160045;
	Wed, 15 Feb 2012 12:03:48 +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, 15 Feb 2012 12:03:47 +0000
X-WSS-ID: 0LZFO65-02-70U-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 268F6C817C;	Wed, 15 Feb 2012 06:03:41 -0600 (CST)
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, 15 Feb 2012 06:03:55 -0600
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.289.1;
	Wed, 15 Feb 2012 06:03:44 -0600
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, 15 Feb 2012
	07:03:43 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C12BD49C305; Wed, 15 Feb 2012
	12:03:41 +0000 (GMT)
Message-ID: <4F3BA067.4010303@amd.com>
Date: Wed, 15 Feb 2012 13:09:11 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <andres@lagarcavilla.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
> We started hashing out some AMD support for mem_paging and mem_access.
> Right now my VMs boot, page out a bit, and then die on an HVM triple
> fault.
>
> Most importantly, I want to get somebody from AMD to comment/help out on
> this. It feels like we're inches away from enabling support for this very
> nice feature. I'm not sure who exactly on AMD monitors the list for these
> kinds of things. It'd be great to have you on board!
>
> For starters, the changes to the p2m code are relatively mild, but it'd be
> great if somebody spots a red flag.
>
> Another issue: comments indicate that bits 59-62 in NPT entries are used
> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit (59)
> would give us enough space to support mem_access. Right now we only have 7
> bits available for Xen flags and that is not enough for paging and access.
> Is bit 59 effectively reserved?

Hi
bit 59 is used by iommu hardware for ATS response. In most cases, for 
p2m_ram_rw pages, U bit must be 0. But maybe for other page types that 
are not potentially used by DMA, this bit could be non-zero. I could 
tested it on my iommu machines if you had some patches that use U bits.

Thanks,
Wei

>
> Finally, the triple fault. Maybe I'm missing something obvious. Comments
> welcome.
>
> Patch inline below, thanks!
> Andres
>
> Enable AMD support for paging.
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell<adin@scannell.ca>
>
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>               if ( !hap_enabled(d) )
>                   break;
>
> -            /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> -                break;
> -
>               rc = -EXDEV;
>               /* Disallow paging in a PoD guest */
>               if ( p2m->pod.entry_count )
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -53,6 +53,20 @@
>   #define P2M_BASE_FLAGS \
>           (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>
> +#ifdef __x86_64__
> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
> + * value tramples over the higher-order bits used for flags (NX, p2mt,
> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> + * juggle for l1 entries only (no paging superpages!) */
> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> +#define clipped_mfn(mfn)    ((mfn)&  ((1UL<<  EFF_MFN_WIDTH) - 1))
> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
> +                                INVALID_MFN : (mfn))
> +#else
> +#define clipped_mfn(mfn)    (mfn)
> +#define unclip_mfn(mfn)     (mfn)
> +#endif /* __x86_64__ */
> +
>   static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>   {
>       unsigned long flags;
> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>       case p2m_invalid:
>       case p2m_mmio_dm:
>       case p2m_populate_on_demand:
> +    case p2m_ram_paging_out:
> +    case p2m_ram_paged:
> +    case p2m_ram_paging_in:
>       default:
>           return flags;
>       case p2m_ram_ro:
> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>                                         shift, max)) )
>           return 0;
>
> -    /* PoD: Not present doesn't imply empty. */
> +    /* PoD/paging: Not present doesn't imply empty. */
>       if ( !l1e_get_flags(*p2m_entry) )
>       {
>           struct page_info *pg;
> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>                                      0, L1_PAGETABLE_ENTRIES);
>           ASSERT(p2m_entry);
>
> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
> -            entry_content = l1e_from_pfn(mfn_x(mfn),
> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>                                            p2m_type_to_flags(p2mt, mfn));
>           else
>               entry_content = l1e_empty();
> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>           if ( entry_content.l1 != 0 )
>           {
>               p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
> -            old_mfn = l1e_get_pfn(*p2m_entry);
> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>           }
>           /* level 1 entry */
>           p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
> entry_content, 1);
> @@ -615,11 +633,12 @@ pod_retry_l1:
>                              sizeof(l1e));
>
>       if ( ret == 0 ) {
> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>           p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
> +                (l1e_mfn == INVALID_MFN&&  p2m_is_paging(p2mt)) );
>
> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
> -             == p2m_populate_on_demand )
> +        if ( p2mt == p2m_populate_on_demand )
>           {
>               /* The read has succeeded, so we know that the mapping
>                * exits at this point.  */
> @@ -641,7 +660,7 @@ pod_retry_l1:
>           }
>
>           if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
> -            mfn = _mfn(l1e_get_pfn(l1e));
> +            mfn = _mfn(l1e_mfn);
>           else
>               /* XXX see above */
>               p2mt = p2m_mmio_dm;
> @@ -783,18 +802,26 @@ pod_retry_l2:
>   pod_retry_l1:
>       if ( (l1e_get_flags(*l1e)&  _PAGE_PRESENT) == 0 )
>       {
> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>           /* PoD: Try to populate */
> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
> +        if ( l1t == p2m_populate_on_demand )
>           {
>               if ( q != p2m_query ) {
>                   if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
>                       goto pod_retry_l1;
>               } else
>                   *t = p2m_populate_on_demand;
> +        } else {
> +            if ( p2m_is_paging(l1t) )
> +            {
> +                *t = l1t;
> +                /* No need to unclip due to check below */
> +                mfn = _mfn(l1e_get_pfn(*l1e));
> +            }
>           }
>
>           unmap_domain_page(l1e);
> -        return _mfn(INVALID_MFN);
> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>       }
>       mfn = _mfn(l1e_get_pfn(*l1e));
>       *t = p2m_flags_to_type(l1e_get_flags(*l1e));
> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>                       flags = l1e_get_flags(l1e[i1]);
>                       if ( p2m_flags_to_type(flags) != ot )
>                           continue;
> -                    mfn = l1e_get_pfn(l1e[i1]);
> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                       gfn = i1 + (i2 + (i3
>   #if CONFIG_PAGING_LEVELS>= 4
>   					+ (i4 * L3_PAGETABLE_ENTRIES)
> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>                              * L2_PAGETABLE_ENTRIES) * L1_PAGETABLE_ENTRIES;
>                       /* create a new 1le entry with the new type */
>                       flags = p2m_type_to_flags(nt, _mfn(mfn));
> -                    l1e_content = l1e_from_pfn(mfn, flags);
> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn), flags);
>                       p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>                                            l1mfn, l1e_content, 1);
>                   }
> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>                                   entry_count++;
>                               continue;
>                           }
> -                        mfn = l1e_get_pfn(l1e[i1]);
> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                           ASSERT(mfn_valid(_mfn(mfn)));
>                           m2pfn = get_gpfn_from_mfn(mfn);
>                           if ( m2pfn != gfn&&
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:04:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdaZ-0001uP-Vg; Wed, 15 Feb 2012 12:03:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RxdaY-0001uK-OX
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:03:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329307431!13404107!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32736 invoked from network); 15 Feb 2012 12:03:51 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.207)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Feb 2012 12:03:51 -0000
Received: from mail107-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 12:03:51 +0000
Received: from mail107-am1 (localhost [127.0.0.1])	by
	mail107-am1-R.bigfish.com (Postfix) with ESMTP id A765246054A;
	Wed, 15 Feb 2012 12:03:50 +0000 (UTC)
X-SpamScore: -7
X-BigFish: VPS-7(zzbb2dI9371I103dK1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail107-am1 (localhost.localdomain [127.0.0.1]) by mail107-am1
	(MessageSwitch) id 132930742896622_23640;
	Wed, 15 Feb 2012 12:03:48 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.228])	by
	mail107-am1.bigfish.com (Postfix) with ESMTP id 129A5160045;
	Wed, 15 Feb 2012 12:03:48 +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, 15 Feb 2012 12:03:47 +0000
X-WSS-ID: 0LZFO65-02-70U-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 268F6C817C;	Wed, 15 Feb 2012 06:03:41 -0600 (CST)
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, 15 Feb 2012 06:03:55 -0600
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.289.1;
	Wed, 15 Feb 2012 06:03:44 -0600
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, 15 Feb 2012
	07:03:43 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C12BD49C305; Wed, 15 Feb 2012
	12:03:41 +0000 (GMT)
Message-ID: <4F3BA067.4010303@amd.com>
Date: Wed, 15 Feb 2012 13:09:11 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <andres@lagarcavilla.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
> We started hashing out some AMD support for mem_paging and mem_access.
> Right now my VMs boot, page out a bit, and then die on an HVM triple
> fault.
>
> Most importantly, I want to get somebody from AMD to comment/help out on
> this. It feels like we're inches away from enabling support for this very
> nice feature. I'm not sure who exactly on AMD monitors the list for these
> kinds of things. It'd be great to have you on board!
>
> For starters, the changes to the p2m code are relatively mild, but it'd be
> great if somebody spots a red flag.
>
> Another issue: comments indicate that bits 59-62 in NPT entries are used
> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit (59)
> would give us enough space to support mem_access. Right now we only have 7
> bits available for Xen flags and that is not enough for paging and access.
> Is bit 59 effectively reserved?

Hi
bit 59 is used by iommu hardware for ATS response. In most cases, for 
p2m_ram_rw pages, U bit must be 0. But maybe for other page types that 
are not potentially used by DMA, this bit could be non-zero. I could 
tested it on my iommu machines if you had some patches that use U bits.

Thanks,
Wei

>
> Finally, the triple fault. Maybe I'm missing something obvious. Comments
> welcome.
>
> Patch inline below, thanks!
> Andres
>
> Enable AMD support for paging.
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell<adin@scannell.ca>
>
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>               if ( !hap_enabled(d) )
>                   break;
>
> -            /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> -                break;
> -
>               rc = -EXDEV;
>               /* Disallow paging in a PoD guest */
>               if ( p2m->pod.entry_count )
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -53,6 +53,20 @@
>   #define P2M_BASE_FLAGS \
>           (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>
> +#ifdef __x86_64__
> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
> + * value tramples over the higher-order bits used for flags (NX, p2mt,
> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> + * juggle for l1 entries only (no paging superpages!) */
> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> +#define clipped_mfn(mfn)    ((mfn)&  ((1UL<<  EFF_MFN_WIDTH) - 1))
> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
> +                                INVALID_MFN : (mfn))
> +#else
> +#define clipped_mfn(mfn)    (mfn)
> +#define unclip_mfn(mfn)     (mfn)
> +#endif /* __x86_64__ */
> +
>   static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>   {
>       unsigned long flags;
> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>       case p2m_invalid:
>       case p2m_mmio_dm:
>       case p2m_populate_on_demand:
> +    case p2m_ram_paging_out:
> +    case p2m_ram_paged:
> +    case p2m_ram_paging_in:
>       default:
>           return flags;
>       case p2m_ram_ro:
> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>                                         shift, max)) )
>           return 0;
>
> -    /* PoD: Not present doesn't imply empty. */
> +    /* PoD/paging: Not present doesn't imply empty. */
>       if ( !l1e_get_flags(*p2m_entry) )
>       {
>           struct page_info *pg;
> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>                                      0, L1_PAGETABLE_ENTRIES);
>           ASSERT(p2m_entry);
>
> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
> -            entry_content = l1e_from_pfn(mfn_x(mfn),
> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>                                            p2m_type_to_flags(p2mt, mfn));
>           else
>               entry_content = l1e_empty();
> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>           if ( entry_content.l1 != 0 )
>           {
>               p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
> -            old_mfn = l1e_get_pfn(*p2m_entry);
> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>           }
>           /* level 1 entry */
>           p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
> entry_content, 1);
> @@ -615,11 +633,12 @@ pod_retry_l1:
>                              sizeof(l1e));
>
>       if ( ret == 0 ) {
> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>           p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
> +                (l1e_mfn == INVALID_MFN&&  p2m_is_paging(p2mt)) );
>
> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
> -             == p2m_populate_on_demand )
> +        if ( p2mt == p2m_populate_on_demand )
>           {
>               /* The read has succeeded, so we know that the mapping
>                * exits at this point.  */
> @@ -641,7 +660,7 @@ pod_retry_l1:
>           }
>
>           if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
> -            mfn = _mfn(l1e_get_pfn(l1e));
> +            mfn = _mfn(l1e_mfn);
>           else
>               /* XXX see above */
>               p2mt = p2m_mmio_dm;
> @@ -783,18 +802,26 @@ pod_retry_l2:
>   pod_retry_l1:
>       if ( (l1e_get_flags(*l1e)&  _PAGE_PRESENT) == 0 )
>       {
> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>           /* PoD: Try to populate */
> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
> +        if ( l1t == p2m_populate_on_demand )
>           {
>               if ( q != p2m_query ) {
>                   if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
>                       goto pod_retry_l1;
>               } else
>                   *t = p2m_populate_on_demand;
> +        } else {
> +            if ( p2m_is_paging(l1t) )
> +            {
> +                *t = l1t;
> +                /* No need to unclip due to check below */
> +                mfn = _mfn(l1e_get_pfn(*l1e));
> +            }
>           }
>
>           unmap_domain_page(l1e);
> -        return _mfn(INVALID_MFN);
> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>       }
>       mfn = _mfn(l1e_get_pfn(*l1e));
>       *t = p2m_flags_to_type(l1e_get_flags(*l1e));
> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>                       flags = l1e_get_flags(l1e[i1]);
>                       if ( p2m_flags_to_type(flags) != ot )
>                           continue;
> -                    mfn = l1e_get_pfn(l1e[i1]);
> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                       gfn = i1 + (i2 + (i3
>   #if CONFIG_PAGING_LEVELS>= 4
>   					+ (i4 * L3_PAGETABLE_ENTRIES)
> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>                              * L2_PAGETABLE_ENTRIES) * L1_PAGETABLE_ENTRIES;
>                       /* create a new 1le entry with the new type */
>                       flags = p2m_type_to_flags(nt, _mfn(mfn));
> -                    l1e_content = l1e_from_pfn(mfn, flags);
> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn), flags);
>                       p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>                                            l1mfn, l1e_content, 1);
>                   }
> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>                                   entry_count++;
>                               continue;
>                           }
> -                        mfn = l1e_get_pfn(l1e[i1]);
> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                           ASSERT(mfn_valid(_mfn(mfn)));
>                           m2pfn = get_gpfn_from_mfn(mfn);
>                           if ( m2pfn != gfn&&
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdpg-0002QQ-Ud; Wed, 15 Feb 2012 12:19:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdpf-0002QL-Oc
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:19:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329308369!11497265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12410 invoked from network); 15 Feb 2012 12:19:29 -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;
	15 Feb 2012 12:19:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10713797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:19:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 12:19:29 +0000
Date: Wed, 15 Feb 2012 12:23:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v4 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v4:

- rebased on 55a36564fb4f85722c67f16fe508f3ecbd204549;

- minor compile fixes.



Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;

- remove "libxl: do not allocate e820 for non x86 guests.";

- introduce libxl__arch_domain_create.



Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (1):
      arm: add stub hvm/save.h

Stefano Stabellini (6):
      arm: compile libxc
      arm: compile libxenguest
      arm: compile memshr
      arm: compile xentrace
      arm: compile libxl
      libxl: Introduce libxl__arch_domain_create

 tools/libxc/Makefile                   |   13 +-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 +++++++
 tools/libxc/xc_core_arm.h              |   60 ++++
 tools/libxc/xc_dom_arm.c               |   49 +++
 tools/libxc/xc_hvm_build.c             |  511 --------------------------------
 tools/libxc/xc_hvm_build_arm.c         |   48 +++
 tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c             |   41 +++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    5 +-
 tools/libxl/libxl_arch.h               |   22 ++
 tools/libxl/libxl_cpuid.c              |   60 ++++
 tools/libxl/libxl_create.c             |   12 +-
 tools/libxl/libxl_internal.h           |    2 -
 tools/libxl/libxl_json.c               |   60 ----
 tools/libxl/libxl_noarch.c             |    8 +
 tools/libxl/libxl_nocpuid.c            |    8 +-
 tools/libxl/libxl_pci.c                |  242 ---------------
 tools/libxl/libxl_x86.c                |  259 ++++++++++++++++
 tools/memshr/bidir-hash.c              |   31 ++
 tools/xentrace/xenctx.c                |   12 +
 xen/include/public/arch-arm/hvm/save.h |   39 +++
 xen/include/public/hvm/save.h          |    2 +
 24 files changed, 1276 insertions(+), 831 deletions(-)


A git tree based on 55a36564fb4f85722c67f16fe508f3ecbd204549, is
available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-4


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdpg-0002QQ-Ud; Wed, 15 Feb 2012 12:19:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdpf-0002QL-Oc
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:19:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329308369!11497265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12410 invoked from network); 15 Feb 2012 12:19:29 -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;
	15 Feb 2012 12:19:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10713797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:19:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 12:19:29 +0000
Date: Wed, 15 Feb 2012 12:23:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v4 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v4:

- rebased on 55a36564fb4f85722c67f16fe508f3ecbd204549;

- minor compile fixes.



Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;

- remove "libxl: do not allocate e820 for non x86 guests.";

- introduce libxl__arch_domain_create.



Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (1):
      arm: add stub hvm/save.h

Stefano Stabellini (6):
      arm: compile libxc
      arm: compile libxenguest
      arm: compile memshr
      arm: compile xentrace
      arm: compile libxl
      libxl: Introduce libxl__arch_domain_create

 tools/libxc/Makefile                   |   13 +-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  106 +++++++
 tools/libxc/xc_core_arm.h              |   60 ++++
 tools/libxc/xc_dom_arm.c               |   49 +++
 tools/libxc/xc_hvm_build.c             |  511 --------------------------------
 tools/libxc/xc_hvm_build_arm.c         |   48 +++
 tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c             |   41 +++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    5 +-
 tools/libxl/libxl_arch.h               |   22 ++
 tools/libxl/libxl_cpuid.c              |   60 ++++
 tools/libxl/libxl_create.c             |   12 +-
 tools/libxl/libxl_internal.h           |    2 -
 tools/libxl/libxl_json.c               |   60 ----
 tools/libxl/libxl_noarch.c             |    8 +
 tools/libxl/libxl_nocpuid.c            |    8 +-
 tools/libxl/libxl_pci.c                |  242 ---------------
 tools/libxl/libxl_x86.c                |  259 ++++++++++++++++
 tools/memshr/bidir-hash.c              |   31 ++
 tools/xentrace/xenctx.c                |   12 +
 xen/include/public/arch-arm/hvm/save.h |   39 +++
 xen/include/public/hvm/save.h          |    2 +
 24 files changed, 1276 insertions(+), 831 deletions(-)


A git tree based on 55a36564fb4f85722c67f16fe508f3ecbd204549, is
available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-4


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdqV-0002Sq-OX; Wed, 15 Feb 2012 12:20:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqT-0002SL-HM
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5405 invoked from network); 15 Feb 2012 12:20:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018412"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24x000803;
	Wed, 15 Feb 2012 04:20:08 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:31 +0000
Message-ID: <1329308673-30175-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 5/7] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdqV-0002Sq-OX; Wed, 15 Feb 2012 12:20:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqT-0002SL-HM
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5405 invoked from network); 15 Feb 2012 12:20:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018412"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:15 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24x000803;
	Wed, 15 Feb 2012 04:20:08 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:31 +0000
Message-ID: <1329308673-30175-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 5/7] arm: compile xentrace
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqb-0002Tv-Hz; Wed, 15 Feb 2012 12:20:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqZ-0002SU-IP
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5822 invoked from network); 15 Feb 2012 12:20:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018428"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK250000803;
	Wed, 15 Feb 2012 04:20:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:32 +0000
Message-ID: <1329308673-30175-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 6/7] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_cpuid.c   |   60 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_json.c    |   60 -------------------------------------------
 tools/libxl/libxl_nocpuid.c |    8 +++++-
 4 files changed, 68 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index dcdb9d02..ff7531f 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -333,6 +333,66 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
                      (const char**)(cpuid[i].policy), cpuid_res);
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    libxl_cpuid_policy_list cpuid = *pcpuid;
+    yajl_gen_status s;
+    const char *input_names[2] = { "leaf", "subleaf" };
+    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
+    int i, j;
+
+    /*
+     * Aiming for:
+     * [
+     *     { 'leaf':    'val-eax',
+     *       'subleaf': 'val-ecx',
+     *       'eax':     'filter',
+     *       'ebx':     'filter',
+     *       'ecx':     'filter',
+     *       'edx':     'filter' },
+     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
+     *     ... etc ...
+     * ]
+     */
+
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    if (cpuid == NULL) goto empty;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        s = yajl_gen_map_open(hand);
+        if (s != yajl_gen_status_ok) goto out;
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_integer(hand, cpuid[i].input[j]);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_string(hand,
+                               (const unsigned char *)cpuid[i].policy[j], 32);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+        s = yajl_gen_map_close(hand);
+        if (s != yajl_gen_status_ok) goto out;
+    }
+
+empty:
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 5418683..41a9523 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,66 +140,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                libxl_cpuid_policy_list *pcpuid)
-{
-    libxl_cpuid_policy_list cpuid = *pcpuid;
-    yajl_gen_status s;
-    const char *input_names[2] = { "leaf", "subleaf" };
-    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
-    int i, j;
-
-    /*
-     * Aiming for:
-     * [
-     *     { 'leaf':    'val-eax',
-     *       'subleaf': 'val-ecx',
-     *       'eax':     'filter',
-     *       'ebx':     'filter',
-     *       'ecx':     'filter',
-     *       'edx':     'filter' },
-     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
-     *     ... etc ...
-     * ]
-     */
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    if (cpuid == NULL) goto empty;
-
-    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-        s = yajl_gen_map_open(hand);
-        if (s != yajl_gen_status_ok) goto out;
-
-        for (j = 0; j < 2; j++) {
-            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
-                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_integer(hand, cpuid[i].input[j]);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-
-        for (j = 0; j < 4; j++) {
-            if (cpuid[i].policy[j] != NULL) {
-                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_string(hand,
-                               (const unsigned char *)cpuid[i].policy[j], 32);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-        s = yajl_gen_map_close(hand);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-
-empty:
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..5f7cb6a 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
@@ -38,6 +38,12 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
 {
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqb-0002Tv-Hz; Wed, 15 Feb 2012 12:20:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqZ-0002SU-IP
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5822 invoked from network); 15 Feb 2012 12:20:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018428"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:21 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK250000803;
	Wed, 15 Feb 2012 04:20:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:32 +0000
Message-ID: <1329308673-30175-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 6/7] arm: compile libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_cpuid.c   |   60 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_json.c    |   60 -------------------------------------------
 tools/libxl/libxl_nocpuid.c |    8 +++++-
 4 files changed, 68 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index dcdb9d02..ff7531f 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -333,6 +333,66 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
                      (const char**)(cpuid[i].policy), cpuid_res);
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    libxl_cpuid_policy_list cpuid = *pcpuid;
+    yajl_gen_status s;
+    const char *input_names[2] = { "leaf", "subleaf" };
+    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
+    int i, j;
+
+    /*
+     * Aiming for:
+     * [
+     *     { 'leaf':    'val-eax',
+     *       'subleaf': 'val-ecx',
+     *       'eax':     'filter',
+     *       'ebx':     'filter',
+     *       'ecx':     'filter',
+     *       'edx':     'filter' },
+     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
+     *     ... etc ...
+     * ]
+     */
+
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    if (cpuid == NULL) goto empty;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        s = yajl_gen_map_open(hand);
+        if (s != yajl_gen_status_ok) goto out;
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_integer(hand, cpuid[i].input[j]);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_string(hand,
+                               (const unsigned char *)cpuid[i].policy[j], 32);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+        s = yajl_gen_map_close(hand);
+        if (s != yajl_gen_status_ok) goto out;
+    }
+
+empty:
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 5418683..41a9523 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,66 +140,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                libxl_cpuid_policy_list *pcpuid)
-{
-    libxl_cpuid_policy_list cpuid = *pcpuid;
-    yajl_gen_status s;
-    const char *input_names[2] = { "leaf", "subleaf" };
-    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
-    int i, j;
-
-    /*
-     * Aiming for:
-     * [
-     *     { 'leaf':    'val-eax',
-     *       'subleaf': 'val-ecx',
-     *       'eax':     'filter',
-     *       'ebx':     'filter',
-     *       'ecx':     'filter',
-     *       'edx':     'filter' },
-     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
-     *     ... etc ...
-     * ]
-     */
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    if (cpuid == NULL) goto empty;
-
-    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-        s = yajl_gen_map_open(hand);
-        if (s != yajl_gen_status_ok) goto out;
-
-        for (j = 0; j < 2; j++) {
-            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
-                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_integer(hand, cpuid[i].input[j]);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-
-        for (j = 0; j < 4; j++) {
-            if (cpuid[i].policy[j] != NULL) {
-                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_string(hand,
-                               (const unsigned char *)cpuid[i].policy[j], 32);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-        s = yajl_gen_map_close(hand);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-
-empty:
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..5f7cb6a 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
@@ -38,6 +38,12 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
 {
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqb-0002U2-Vr; Wed, 15 Feb 2012 12:20:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdqa-0002Sm-7o
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329308424!13410957!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1011 invoked from network); 15 Feb 2012 12:20:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="181898077"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK251000803;
	Wed, 15 Feb 2012 04:20:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:33 +0000
Message-ID: <1329308673-30175-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an arch specific internal domain creation function. At the
moment only x86 provides an implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile         |    6 +-
 tools/libxl/libxl_arch.h     |   22 ++++
 tools/libxl/libxl_create.c   |   12 +--
 tools/libxl/libxl_internal.h |    2 -
 tools/libxl/libxl_noarch.c   |    8 ++
 tools/libxl/libxl_pci.c      |  242 ---------------------------------------
 tools/libxl/libxl_x86.c      |  259 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 294 insertions(+), 257 deletions(-)
 create mode 100644 tools/libxl/libxl_arch.h
 create mode 100644 tools/libxl/libxl_noarch.c
 create mode 100644 tools/libxl/libxl_x86.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 41b6ac4..ba5852b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
 endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
-LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
+LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
new file mode 100644
index 0000000..d1bbdf7
--- /dev/null
+++ b/tools/libxl/libxl_arch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_ARCH_H
+#define LIBXL_ARCH_H
+
+/* arch specific internal domain creation function */
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+		uint32_t domid);
+
+#endif
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..ff589a8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -18,6 +18,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 
 #include <xc_dom.h>
 #include <xenguest.h>
@@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
-    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                      "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
-    }
+    libxl__arch_domain_create(gc, d_config, domid);
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8846c68..bd384e2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -975,8 +975,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
 
-_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
-
 /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
 _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
new file mode 100644
index 0000000..7893535
--- /dev/null
+++ b/tools/libxl/libxl_noarch.c
@@ -0,0 +1,8 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+                              uint32_t domid)
+{
+    return 0;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 33425f5..d960f4b 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static const char *e820_names(int type)
-{
-    switch (type) {
-        case E820_RAM: return "RAM";
-        case E820_RESERVED: return "Reserved";
-        case E820_ACPI: return "ACPI";
-        case E820_NVS: return "ACPI NVS";
-        case E820_UNUSABLE: return "Unusable";
-        default: break;
-    }
-    return "Unknown";
-}
-
-static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
-                         uint32_t *nr_entries,
-                         unsigned long map_limitkb,
-                         unsigned long balloon_kb)
-{
-    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
-    uint32_t i, idx = 0, nr;
-    struct e820entry e820[E820MAX];
-
-    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
-        return ERROR_INVAL;
-
-    nr = *nr_entries;
-    if (!nr)
-        return ERROR_INVAL;
-
-    if (nr > E820MAX)
-        return ERROR_NOMEM;
-
-    /* Weed out anything under 1MB */
-    for (i = 0; i < nr; i++) {
-        if (src[i].addr > 0x100000)
-            continue;
-
-        src[i].type = 0;
-        src[i].size = 0;
-        src[i].addr = -1ULL;
-    }
-
-    /* Find the lowest and highest entry in E820, skipping over
-     * undesired entries. */
-    start = -1ULL;
-    last = 0;
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == E820_UNUSABLE) ||
-            (src[i].type == 0))
-            continue;
-
-        start = src[i].addr < start ? src[i].addr : start;
-        last = src[i].addr + src[i].size > last ?
-               src[i].addr + src[i].size > last : last;
-    }
-    if (start > 1024)
-        start_kb = start >> 10;
-
-    /* Add the memory RAM region for the guest */
-    e820[idx].addr = 0;
-    e820[idx].size = (uint64_t)map_limitkb << 10;
-    e820[idx].type = E820_RAM;
-
-    /* .. and trim if neccessary */
-    if (start_kb && map_limitkb > start_kb) {
-        delta_kb = map_limitkb - start_kb;
-        if (delta_kb)
-            e820[idx].size -= (uint64_t)(delta_kb << 10);
-    }
-    /* Note: We don't touch balloon_kb here. Will add it at the end. */
-    ram_end = e820[idx].addr + e820[idx].size;
-    idx ++;
-
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
-               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
-               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
-               ram_end >> 12, delta_kb, start_kb ,start >> 12,
-               (uint64_t)balloon_kb);
-
-
-    /* This whole code below is to guard against if the Intel IGD is passed into
-     * the guest. If we don't pass in IGD, this whole code can be ignored.
-     *
-     * The reason for this code is that Intel boxes fill their E820 with
-     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
-     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
-     * Linux and it would be utilized by the Intel IGD as I/O space while
-     * in reality it was an RAM region.
-     *
-     * What this means is that we have to walk the E820 and for any region
-     * that is RAM and below 4GB and above ram_end, needs to change its type
-     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
-     * the overlap with ram_end. */
-    for (i = 0; i < nr; i++) {
-        uint64_t end = src[i].addr + src[i].size;
-
-        /* We don't care about E820_UNUSABLE, but we need to
-         * change the type to zero b/c the loop after this
-         * sticks E820_UNUSABLE on the guest's E820 but ignores
-         * the ones with type zero. */
-        if ((src[i].type == E820_UNUSABLE) ||
-            /* Any region that is within the "RAM region" can
-             * be safely ditched. */
-            (end < ram_end)) {
-                src[i].type = 0;
-                continue;
-        }
-
-        /* Look only at RAM regions. */
-        if (src[i].type != E820_RAM)
-            continue;
-
-        /* We only care about RAM regions below 4GB. */
-        if (src[i].addr >= (1ULL<<32))
-            continue;
-
-        /* E820_RAM overlaps with our RAM region. Move it */
-        if (src[i].addr < ram_end) {
-            uint64_t delta;
-
-            src[i].type = E820_UNUSABLE;
-            delta = ram_end - src[i].addr;
-            /* The end < ram_end should weed this out */
-            if (src[i].size - delta < 0)
-                src[i].type = 0;
-            else {
-                src[i].size -= delta;
-                src[i].addr = ram_end;
-            }
-            if (src[i].addr + src[i].size != end) {
-                /* We messed up somewhere */
-                src[i].type = 0;
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
-            }
-        }
-        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
-           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
-            "xen/setup: Inhibit resource API from using System RAM E820
-           gaps as PCI mem gaps" for full explanation. */
-        if (end > ram_end)
-            src[i].type = E820_UNUSABLE;
-    }
-
-    /* Check if there is a region between ram_end and start. */
-    if (start > ram_end) {
-        int add_unusable = 1;
-        for (i = 0; i < nr && add_unusable; i++) {
-            if (src[i].type != E820_UNUSABLE)
-                continue;
-            if (ram_end != src[i].addr)
-                continue;
-            if (start != src[i].addr + src[i].size) {
-                /* there is one, adjust it */
-                src[i].size = start - src[i].addr;
-            }
-            add_unusable = 0;
-        }
-        /* .. and if not present, add it in. This is to guard against
-           the Linux guest assuming that the gap between the end of
-           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-           is PCI I/O space. Which it certainly is _not_. */
-        if (add_unusable) {
-            e820[idx].type = E820_UNUSABLE;
-            e820[idx].addr = ram_end;
-            e820[idx].size = start - ram_end;
-            idx++;
-        }
-    }
-    /* Almost done: copy them over, ignoring the undesireable ones */
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == 0))
-            continue;
-
-        e820[idx].type = src[i].type;
-        e820[idx].addr = src[i].addr;
-        e820[idx].size = src[i].size;
-        idx++;
-    }
-    /* At this point we have the mapped RAM + E820 entries from src. */
-    if (balloon_kb) {
-        /* and if we truncated the RAM region, then add it to the end. */
-        e820[idx].type = E820_RAM;
-        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
-                         (uint64_t)(1ULL << 32) : last;
-        /* also add the balloon memory to the end. */
-        e820[idx].size = (uint64_t)(delta_kb << 10) +
-                         (uint64_t)(balloon_kb << 10);
-        idx++;
-
-    }
-    nr = idx;
-
-    for (i = 0; i < nr; i++) {
-      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
-                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
-                 e820_names(e820[i].type));
-    }
-
-    /* Done: copy the sanitized version. */
-    *nr_entries = nr;
-    memcpy(src, e820, nr * sizeof(struct e820entry));
-    return 0;
-}
-
-int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc;
-    uint32_t nr;
-    struct e820entry map[E820MAX];
-    libxl_domain_build_info *b_info;
-
-    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        return ERROR_INVAL;
-
-    b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
-        return ERROR_INVAL;
-
-    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
-    if (rc < 0) {
-        errno = rc;
-        return ERROR_FAIL;
-    }
-    nr = rc;
-    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
-                       (b_info->max_memkb - b_info->target_memkb) +
-                       b_info->u.pv.slack_memkb);
-    if (rc)
-        return ERROR_FAIL;
-
-    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
-
-    if (rc < 0) {
-        errno  = rc;
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
new file mode 100644
index 0000000..7e11f2d
--- /dev/null
+++ b/tools/libxl/libxl_x86.c
@@ -0,0 +1,259 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+            continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+        uint64_t end = src[i].addr + src[i].size;
+
+        /* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+            /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+        if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+        /* E820_RAM overlaps with our RAM region. Move it */
+        if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
+        /* .. and if not present, add it in. This is to guard against
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == 0))
+            continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+        uint32_t domid)
+{
+    int rc = 0;
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
+        d_config->b_info.u.pv.e820_host) {
+        rc = libxl__e820_alloc(gc, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
+    return rc;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqb-0002U2-Vr; Wed, 15 Feb 2012 12:20:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdqa-0002Sm-7o
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329308424!13410957!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1011 invoked from network); 15 Feb 2012 12:20:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="181898077"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK251000803;
	Wed, 15 Feb 2012 04:20:11 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:33 +0000
Message-ID: <1329308673-30175-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an arch specific internal domain creation function. At the
moment only x86 provides an implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile         |    6 +-
 tools/libxl/libxl_arch.h     |   22 ++++
 tools/libxl/libxl_create.c   |   12 +--
 tools/libxl/libxl_internal.h |    2 -
 tools/libxl/libxl_noarch.c   |    8 ++
 tools/libxl/libxl_pci.c      |  242 ---------------------------------------
 tools/libxl/libxl_x86.c      |  259 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 294 insertions(+), 257 deletions(-)
 create mode 100644 tools/libxl/libxl_arch.h
 create mode 100644 tools/libxl/libxl_noarch.c
 create mode 100644 tools/libxl/libxl_x86.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 41b6ac4..ba5852b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
 endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
-LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
+LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
new file mode 100644
index 0000000..d1bbdf7
--- /dev/null
+++ b/tools/libxl/libxl_arch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_ARCH_H
+#define LIBXL_ARCH_H
+
+/* arch specific internal domain creation function */
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+		uint32_t domid);
+
+#endif
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..ff589a8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -18,6 +18,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 
 #include <xc_dom.h>
 #include <xenguest.h>
@@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
-    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                      "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
-    }
+    libxl__arch_domain_create(gc, d_config, domid);
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8846c68..bd384e2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -975,8 +975,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
 
-_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
-
 /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
 _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
new file mode 100644
index 0000000..7893535
--- /dev/null
+++ b/tools/libxl/libxl_noarch.c
@@ -0,0 +1,8 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+                              uint32_t domid)
+{
+    return 0;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 33425f5..d960f4b 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static const char *e820_names(int type)
-{
-    switch (type) {
-        case E820_RAM: return "RAM";
-        case E820_RESERVED: return "Reserved";
-        case E820_ACPI: return "ACPI";
-        case E820_NVS: return "ACPI NVS";
-        case E820_UNUSABLE: return "Unusable";
-        default: break;
-    }
-    return "Unknown";
-}
-
-static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
-                         uint32_t *nr_entries,
-                         unsigned long map_limitkb,
-                         unsigned long balloon_kb)
-{
-    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
-    uint32_t i, idx = 0, nr;
-    struct e820entry e820[E820MAX];
-
-    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
-        return ERROR_INVAL;
-
-    nr = *nr_entries;
-    if (!nr)
-        return ERROR_INVAL;
-
-    if (nr > E820MAX)
-        return ERROR_NOMEM;
-
-    /* Weed out anything under 1MB */
-    for (i = 0; i < nr; i++) {
-        if (src[i].addr > 0x100000)
-            continue;
-
-        src[i].type = 0;
-        src[i].size = 0;
-        src[i].addr = -1ULL;
-    }
-
-    /* Find the lowest and highest entry in E820, skipping over
-     * undesired entries. */
-    start = -1ULL;
-    last = 0;
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == E820_UNUSABLE) ||
-            (src[i].type == 0))
-            continue;
-
-        start = src[i].addr < start ? src[i].addr : start;
-        last = src[i].addr + src[i].size > last ?
-               src[i].addr + src[i].size > last : last;
-    }
-    if (start > 1024)
-        start_kb = start >> 10;
-
-    /* Add the memory RAM region for the guest */
-    e820[idx].addr = 0;
-    e820[idx].size = (uint64_t)map_limitkb << 10;
-    e820[idx].type = E820_RAM;
-
-    /* .. and trim if neccessary */
-    if (start_kb && map_limitkb > start_kb) {
-        delta_kb = map_limitkb - start_kb;
-        if (delta_kb)
-            e820[idx].size -= (uint64_t)(delta_kb << 10);
-    }
-    /* Note: We don't touch balloon_kb here. Will add it at the end. */
-    ram_end = e820[idx].addr + e820[idx].size;
-    idx ++;
-
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
-               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
-               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
-               ram_end >> 12, delta_kb, start_kb ,start >> 12,
-               (uint64_t)balloon_kb);
-
-
-    /* This whole code below is to guard against if the Intel IGD is passed into
-     * the guest. If we don't pass in IGD, this whole code can be ignored.
-     *
-     * The reason for this code is that Intel boxes fill their E820 with
-     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
-     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
-     * Linux and it would be utilized by the Intel IGD as I/O space while
-     * in reality it was an RAM region.
-     *
-     * What this means is that we have to walk the E820 and for any region
-     * that is RAM and below 4GB and above ram_end, needs to change its type
-     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
-     * the overlap with ram_end. */
-    for (i = 0; i < nr; i++) {
-        uint64_t end = src[i].addr + src[i].size;
-
-        /* We don't care about E820_UNUSABLE, but we need to
-         * change the type to zero b/c the loop after this
-         * sticks E820_UNUSABLE on the guest's E820 but ignores
-         * the ones with type zero. */
-        if ((src[i].type == E820_UNUSABLE) ||
-            /* Any region that is within the "RAM region" can
-             * be safely ditched. */
-            (end < ram_end)) {
-                src[i].type = 0;
-                continue;
-        }
-
-        /* Look only at RAM regions. */
-        if (src[i].type != E820_RAM)
-            continue;
-
-        /* We only care about RAM regions below 4GB. */
-        if (src[i].addr >= (1ULL<<32))
-            continue;
-
-        /* E820_RAM overlaps with our RAM region. Move it */
-        if (src[i].addr < ram_end) {
-            uint64_t delta;
-
-            src[i].type = E820_UNUSABLE;
-            delta = ram_end - src[i].addr;
-            /* The end < ram_end should weed this out */
-            if (src[i].size - delta < 0)
-                src[i].type = 0;
-            else {
-                src[i].size -= delta;
-                src[i].addr = ram_end;
-            }
-            if (src[i].addr + src[i].size != end) {
-                /* We messed up somewhere */
-                src[i].type = 0;
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
-            }
-        }
-        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
-           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
-            "xen/setup: Inhibit resource API from using System RAM E820
-           gaps as PCI mem gaps" for full explanation. */
-        if (end > ram_end)
-            src[i].type = E820_UNUSABLE;
-    }
-
-    /* Check if there is a region between ram_end and start. */
-    if (start > ram_end) {
-        int add_unusable = 1;
-        for (i = 0; i < nr && add_unusable; i++) {
-            if (src[i].type != E820_UNUSABLE)
-                continue;
-            if (ram_end != src[i].addr)
-                continue;
-            if (start != src[i].addr + src[i].size) {
-                /* there is one, adjust it */
-                src[i].size = start - src[i].addr;
-            }
-            add_unusable = 0;
-        }
-        /* .. and if not present, add it in. This is to guard against
-           the Linux guest assuming that the gap between the end of
-           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-           is PCI I/O space. Which it certainly is _not_. */
-        if (add_unusable) {
-            e820[idx].type = E820_UNUSABLE;
-            e820[idx].addr = ram_end;
-            e820[idx].size = start - ram_end;
-            idx++;
-        }
-    }
-    /* Almost done: copy them over, ignoring the undesireable ones */
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == 0))
-            continue;
-
-        e820[idx].type = src[i].type;
-        e820[idx].addr = src[i].addr;
-        e820[idx].size = src[i].size;
-        idx++;
-    }
-    /* At this point we have the mapped RAM + E820 entries from src. */
-    if (balloon_kb) {
-        /* and if we truncated the RAM region, then add it to the end. */
-        e820[idx].type = E820_RAM;
-        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
-                         (uint64_t)(1ULL << 32) : last;
-        /* also add the balloon memory to the end. */
-        e820[idx].size = (uint64_t)(delta_kb << 10) +
-                         (uint64_t)(balloon_kb << 10);
-        idx++;
-
-    }
-    nr = idx;
-
-    for (i = 0; i < nr; i++) {
-      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
-                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
-                 e820_names(e820[i].type));
-    }
-
-    /* Done: copy the sanitized version. */
-    *nr_entries = nr;
-    memcpy(src, e820, nr * sizeof(struct e820entry));
-    return 0;
-}
-
-int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc;
-    uint32_t nr;
-    struct e820entry map[E820MAX];
-    libxl_domain_build_info *b_info;
-
-    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        return ERROR_INVAL;
-
-    b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
-        return ERROR_INVAL;
-
-    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
-    if (rc < 0) {
-        errno = rc;
-        return ERROR_FAIL;
-    }
-    nr = rc;
-    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
-                       (b_info->max_memkb - b_info->target_memkb) +
-                       b_info->u.pv.slack_memkb);
-    if (rc)
-        return ERROR_FAIL;
-
-    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
-
-    if (rc < 0) {
-        errno  = rc;
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
new file mode 100644
index 0000000..7e11f2d
--- /dev/null
+++ b/tools/libxl/libxl_x86.c
@@ -0,0 +1,259 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+            continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+        uint64_t end = src[i].addr + src[i].size;
+
+        /* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+            /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+        if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+        /* E820_RAM overlaps with our RAM region. Move it */
+        if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
+        /* .. and if not present, add it in. This is to guard against
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == 0))
+            continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+        uint32_t domid)
+{
+    int rc = 0;
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
+        d_config->b_info.u.pv.e820_host) {
+        rc = libxl__e820_alloc(gc, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
+    return rc;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdqY-0002TF-59; Wed, 15 Feb 2012 12:20:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqV-0002SO-Pc
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5713 invoked from network); 15 Feb 2012 12:20:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018416"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24w000803;
	Wed, 15 Feb 2012 04:20:07 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:30 +0000
Message-ID: <1329308673-30175-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 4/7] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdqY-0002TF-59; Wed, 15 Feb 2012 12:20:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqV-0002SO-Pc
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5713 invoked from network); 15 Feb 2012 12:20:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018416"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24w000803;
	Wed, 15 Feb 2012 04:20:07 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:30 +0000
Message-ID: <1329308673-30175-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 4/7] arm: compile memshr
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdqS-0002SW-CB; Wed, 15 Feb 2012 12:20:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqQ-0002SB-Vr
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5135 invoked from network); 15 Feb 2012 12:20:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018411"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24t000803;
	Wed, 15 Feb 2012 04:20:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:27 +0000
Message-ID: <1329308673-30175-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 1/7] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1RxdqS-0002SW-CB; Wed, 15 Feb 2012 12:20:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxdqQ-0002SB-Vr
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5135 invoked from network); 15 Feb 2012 12:20:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018411"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:09 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24t000803;
	Wed, 15 Feb 2012 04:20:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:27 +0000
Message-ID: <1329308673-30175-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 1/7] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqe-0002Uv-Lu; Wed, 15 Feb 2012 12:20:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdqa-0002SV-Lv
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5599 invoked from network); 15 Feb 2012 12:20:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24v000803;
	Wed, 15 Feb 2012 04:20:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:29 +0000
Message-ID: <1329308673-30175-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Provide empty implementations of xc_domain_save and xc_domain_restore
when CONFIG_MIGRATE is not set.
Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
x86 specific, introduce xc_hvm_build_arm.c with empty stubs.


Changes in v3:

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;



Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile           |   12 +-
 tools/libxc/xc_dom_arm.c       |   49 ++++
 tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
 tools/libxc/xc_hvm_build_arm.c |   48 ++++
 tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c     |   41 ++++
 6 files changed, 658 insertions(+), 514 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build.c
 create mode 100644 tools/libxc/xc_hvm_build_arm.c
 create mode 100644 tools/libxc/xc_hvm_build_x86.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..02d39a3 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
deleted file mode 100644
index 1fa5658..0000000
--- a/tools/libxc/xc_hvm_build.c
+++ /dev/null
@@ -1,511 +0,0 @@
-/******************************************************************************
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <stddef.h>
-#include <inttypes.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <zlib.h>
-
-#include "xg_private.h"
-#include "xc_private.h"
-
-#include <xen/foreign/x86_32.h>
-#include <xen/foreign/x86_64.h>
-#include <xen/hvm/hvm_info_table.h>
-#include <xen/hvm/params.h>
-#include <xen/hvm/e820.h>
-
-#include <xen/libelf/libelf.h>
-
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
-
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
-{
-    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
-        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
-    uint64_t lowmem_end = mem_size, highmem_end = 0;
-    uint8_t sum;
-    int i;
-
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
-    {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
-    }
-
-    memset(hvm_info_page, 0, PAGE_SIZE);
-
-    /* Fill in the header. */
-    strncpy(hvm_info->signature, "HVM INFO", 8);
-    hvm_info->length = sizeof(struct hvm_info_table);
-
-    /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->apic_mode = 1;
-    hvm_info->nr_vcpus = 1;
-    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
-
-    /* Memory parameters. */
-    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
-    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
-    hvm_info->reserved_mem_pgstart = special_pfn(0);
-
-    /* Finish with the checksum. */
-    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
-        sum += ((uint8_t *)hvm_info)[i];
-    hvm_info->checksum = -sum;
-}
-
-static int loadelfimage(
-    xc_interface *xch,
-    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
-{
-    privcmd_mmap_entry_t *entries = NULL;
-    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
-    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
-    size_t pages = pfn_end - pfn_start;
-    int i, rc = -1;
-
-    /* Map address space for initial elf image. */
-    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-    if ( entries == NULL )
-        goto err;
-
-    for ( i = 0; i < pages; i++ )
-        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
-
-    elf->dest = xc_map_foreign_ranges(
-        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
-        entries, pages);
-    if ( elf->dest == NULL )
-        goto err;
-
-    elf->dest += elf->pstart & (PAGE_SIZE - 1);
-
-    /* Load the initial elf image. */
-    rc = elf_load_binary(elf);
-    if ( rc < 0 )
-        PERROR("Failed to load elf binary\n");
-
-    munmap(elf->dest, pages << PAGE_SHIFT);
-    elf->dest = NULL;
-
- err:
-    free(entries);
-
-    return rc;
-}
-
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
-{
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
-        return 0;
-    else
-        return 1;
-}
-
-static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
-                       char *image, unsigned long image_size)
-{
-    xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
-    unsigned long entry_eip, cur_pages, cur_pfn;
-    void *hvm_info_page;
-    uint32_t *ident_pt;
-    struct elf_binary elf;
-    uint64_t v_start, v_end;
-    int rc;
-    xen_capabilities_info_t caps;
-    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
-        stat_1gb_pages = 0;
-    int pod_mode = 0;
-
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
-        pod_mode = 1;
-
-    memset(&elf, 0, sizeof(elf));
-    if ( elf_init(&elf, image, image_size) != 0 )
-        goto error_out;
-
-    xc_elf_set_logfile(xch, &elf, 1);
-
-    elf_parse_binary(&elf);
-    v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
-
-    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
-    {
-        PERROR("Could not get Xen capabilities");
-        goto error_out;
-    }
-
-    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
-            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
-            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
-            "  ENTRY ADDRESS: %016"PRIx64"\n",
-            elf.pstart, elf.pend,
-            v_start, v_end,
-            elf_uval(&elf, elf.ehdr, e_entry));
-
-    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
-    {
-        PERROR("Could not allocate memory.");
-        goto error_out;
-    }
-
-    for ( i = 0; i < nr_pages; i++ )
-        page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
-
-    /*
-     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
-     *
-     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
-     * pages if 1GB allocation fails. 4KB pages will be used eventually if
-     * both fail.
-     * 
-     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
-     * ensure that we can be preempted and hence dom0 remains responsive.
-     */
-    rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
-    cur_pages = 0xc0;
-    stat_normal_pages = 0xc0;
-    while ( (rc == 0) && (nr_pages > cur_pages) )
-    {
-        /* Clip count to maximum 1GB extent. */
-        unsigned long count = nr_pages - cur_pages;
-        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-        if ( count > max_pages )
-            count = max_pages;
-
-        cur_pfn = page_array[cur_pages];
-
-        /* Take care the corner cases of super page tails */
-        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
-            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
-        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-                  (count > SUPERPAGE_1GB_NR_PFNS) )
-            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-        /* Attemp to allocate 1GB super page. Because in each pass we only
-         * allocate at most 1GB, we don't have to clip super page boundaries.
-         */
-        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
-             /* Check if there exists MMIO hole in the 1GB memory range */
-             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
-        {
-            long done;
-            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
-            xen_pfn_t sp_extents[nr_extents];
-
-            for ( i = 0; i < nr_extents; i++ )
-                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
-
-            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
-                                              pod_mode ? XENMEMF_populate_on_demand : 0,
-                                              sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
-        }
-
-        if ( count != 0 )
-        {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
-            if ( count > max_pages )
-                count = max_pages;
-            
-            /* Clip partial superpage extents to superpage boundaries. */
-            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
-                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
-            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                      (count > SUPERPAGE_2MB_NR_PFNS) )
-                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-            /* Attempt to allocate superpage extents. */
-            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
-            {
-                long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
-                xen_pfn_t sp_extents[nr_extents];
-
-                for ( i = 0; i < nr_extents; i++ )
-                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
-
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
-                                                  sp_extents);
-
-                if ( done > 0 )
-                {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
-                    cur_pages += done;
-                    count -= done;
-                }
-            }
-        }
-
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, 0, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
-        }
-    }
-
-    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
-     * adjust the PoD cache size so that domain tot_pages will be
-     * target_pages - 0x20 after this call. */
-    if ( pod_mode )
-        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
-                                      NULL, NULL, NULL);
-
-    if ( rc != 0 )
-    {
-        PERROR("Could not allocate memory for HVM guest.");
-        goto error_out;
-    }
-
-    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
-            "  4KB PAGES: 0x%016lx\n"
-            "  2MB PAGES: 0x%016lx\n"
-            "  1GB PAGES: 0x%016lx\n",
-            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
-    
-    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
-        goto error_out;
-
-    if ( (hvm_info_page = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              HVM_INFO_PFN)) == NULL )
-        goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
-    munmap(hvm_info_page, PAGE_SIZE);
-
-    /* Allocate and clear special pages. */
-    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-    {
-        xen_pfn_t pfn = special_pfn(i);
-        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
-        if ( rc != 0 )
-        {
-            PERROR("Could not allocate %d'th special page.", i);
-            goto error_out;
-        }
-        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
-            goto error_out;
-    }
-
-    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
-                     special_pfn(SPECIALPAGE_XENSTORE));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
-                     special_pfn(SPECIALPAGE_BUFIOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
-                     special_pfn(SPECIALPAGE_IOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
-                     special_pfn(SPECIALPAGE_CONSOLE));
-
-    /*
-     * Identity-map page table is required for running with CR0.PG=0 when
-     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
-     */
-    if ( (ident_pt = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
-        goto error_out;
-    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
-        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
-                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-    munmap(ident_pt, PAGE_SIZE);
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
-                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
-
-    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
-    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
-    if ( entry_eip != 0 )
-    {
-        char *page0 = xc_map_foreign_range(
-            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
-        if ( page0 == NULL )
-            goto error_out;
-        page0[0] = 0xe9;
-        *(uint32_t *)&page0[1] = entry_eip - 5;
-        munmap(page0, PAGE_SIZE);
-    }
-
-    free(page_array);
-    return 0;
-
- error_out:
-    free(page_array);
-    return -1;
-}
-
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
-/* xc_hvm_build:
- * Create a domain for a virtualized Linux, using files/filenames.
- */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_target_mem: 
- * Create a domain for a pre-ballooned virtualized Linux, using
- * files/filenames.  If target < memsize, domain is created with
- * memsize pages marked populate-on-demand, 
- * calculating pod cache size based on target.
- * If target == memsize, pages are populated normally.
- */
-int xc_hvm_build_target_mem(xc_interface *xch,
-                           uint32_t domid,
-                           int memsize,
-                           int target,
-                           const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
new file mode 100644
index 0000000..6cf65a1
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_arm.c
@@ -0,0 +1,48 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
new file mode 100644
index 0000000..1fa5658
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -0,0 +1,511 @@
+/******************************************************************************
+ * xc_hvm_build.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stddef.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <zlib.h>
+
+#include "xg_private.h"
+#include "xc_private.h"
+
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/params.h>
+#include <xen/hvm/e820.h>
+
+#include <xen/libelf/libelf.h>
+
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define SPECIALPAGE_BUFIOREQ 0
+#define SPECIALPAGE_XENSTORE 1
+#define SPECIALPAGE_IOREQ    2
+#define SPECIALPAGE_IDENT_PT 3
+#define SPECIALPAGE_CONSOLE  4
+#define NR_SPECIAL_PAGES     5
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+{
+    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+    uint64_t lowmem_end = mem_size, highmem_end = 0;
+    uint8_t sum;
+    int i;
+
+    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    {
+        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
+        lowmem_end = HVM_BELOW_4G_RAM_END;
+    }
+
+    memset(hvm_info_page, 0, PAGE_SIZE);
+
+    /* Fill in the header. */
+    strncpy(hvm_info->signature, "HVM INFO", 8);
+    hvm_info->length = sizeof(struct hvm_info_table);
+
+    /* Sensible defaults: these can be overridden by the caller. */
+    hvm_info->apic_mode = 1;
+    hvm_info->nr_vcpus = 1;
+    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+    /* Memory parameters. */
+    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
+    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
+    hvm_info->reserved_mem_pgstart = special_pfn(0);
+
+    /* Finish with the checksum. */
+    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+        sum += ((uint8_t *)hvm_info)[i];
+    hvm_info->checksum = -sum;
+}
+
+static int loadelfimage(
+    xc_interface *xch,
+    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
+{
+    privcmd_mmap_entry_t *entries = NULL;
+    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
+    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
+    size_t pages = pfn_end - pfn_start;
+    int i, rc = -1;
+
+    /* Map address space for initial elf image. */
+    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
+    if ( entries == NULL )
+        goto err;
+
+    for ( i = 0; i < pages; i++ )
+        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
+
+    elf->dest = xc_map_foreign_ranges(
+        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
+        entries, pages);
+    if ( elf->dest == NULL )
+        goto err;
+
+    elf->dest += elf->pstart & (PAGE_SIZE - 1);
+
+    /* Load the initial elf image. */
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
+
+    munmap(elf->dest, pages << PAGE_SHIFT);
+    elf->dest = NULL;
+
+ err:
+    free(entries);
+
+    return rc;
+}
+
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize)
+{
+    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
+         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+        return 0;
+    else
+        return 1;
+}
+
+static int setup_guest(xc_interface *xch,
+                       uint32_t dom, int memsize, int target,
+                       char *image, unsigned long image_size)
+{
+    xen_pfn_t *page_array = NULL;
+    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
+    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long entry_eip, cur_pages, cur_pfn;
+    void *hvm_info_page;
+    uint32_t *ident_pt;
+    struct elf_binary elf;
+    uint64_t v_start, v_end;
+    int rc;
+    xen_capabilities_info_t caps;
+    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
+        stat_1gb_pages = 0;
+    int pod_mode = 0;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( memsize < 2 || target < 2 )
+        goto error_out;
+
+    if ( memsize > target )
+        pod_mode = 1;
+
+    memset(&elf, 0, sizeof(elf));
+    if ( elf_init(&elf, image, image_size) != 0 )
+        goto error_out;
+
+    xc_elf_set_logfile(xch, &elf, 1);
+
+    elf_parse_binary(&elf);
+    v_start = 0;
+    v_end = (unsigned long long)memsize << 20;
+
+    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+    {
+        PERROR("Could not get Xen capabilities");
+        goto error_out;
+    }
+
+    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
+            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
+            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
+            "  ENTRY ADDRESS: %016"PRIx64"\n",
+            elf.pstart, elf.pend,
+            v_start, v_end,
+            elf_uval(&elf, elf.ehdr, e_entry));
+
+    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
+    {
+        PERROR("Could not allocate memory.");
+        goto error_out;
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+        page_array[i] = i;
+    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+
+    /*
+     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
+     *
+     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+     * pages if 1GB allocation fails. 4KB pages will be used eventually if
+     * both fail.
+     * 
+     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
+     * ensure that we can be preempted and hence dom0 remains responsive.
+     */
+    rc = xc_domain_populate_physmap_exact(
+        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
+    cur_pages = 0xc0;
+    stat_normal_pages = 0xc0;
+    while ( (rc == 0) && (nr_pages > cur_pages) )
+    {
+        /* Clip count to maximum 1GB extent. */
+        unsigned long count = nr_pages - cur_pages;
+        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+        if ( count > max_pages )
+            count = max_pages;
+
+        cur_pfn = page_array[cur_pages];
+
+        /* Take care the corner cases of super page tails */
+        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
+            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
+        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+                  (count > SUPERPAGE_1GB_NR_PFNS) )
+            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+        /* Attemp to allocate 1GB super page. Because in each pass we only
+         * allocate at most 1GB, we don't have to clip super page boundaries.
+         */
+        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
+             /* Check if there exists MMIO hole in the 1GB memory range */
+             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+        {
+            long done;
+            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
+            xen_pfn_t sp_extents[nr_extents];
+
+            for ( i = 0; i < nr_extents; i++ )
+                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
+
+            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                              pod_mode ? XENMEMF_populate_on_demand : 0,
+                                              sp_extents);
+
+            if ( done > 0 )
+            {
+                stat_1gb_pages += done;
+                done <<= SUPERPAGE_1GB_SHIFT;
+                cur_pages += done;
+                count -= done;
+            }
+        }
+
+        if ( count != 0 )
+        {
+            /* Clip count to maximum 8MB extent. */
+            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            if ( count > max_pages )
+                count = max_pages;
+            
+            /* Clip partial superpage extents to superpage boundaries. */
+            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
+                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
+            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                      (count > SUPERPAGE_2MB_NR_PFNS) )
+                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+            /* Attempt to allocate superpage extents. */
+            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+            {
+                long done;
+                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                xen_pfn_t sp_extents[nr_extents];
+
+                for ( i = 0; i < nr_extents; i++ )
+                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
+                                                  sp_extents);
+
+                if ( done > 0 )
+                {
+                    stat_2mb_pages += done;
+                    done <<= SUPERPAGE_2MB_SHIFT;
+                    cur_pages += done;
+                    count -= done;
+                }
+            }
+        }
+
+        /* Fall back to 4kB extents. */
+        if ( count != 0 )
+        {
+            rc = xc_domain_populate_physmap_exact(
+                xch, dom, count, 0, 0, &page_array[cur_pages]);
+            cur_pages += count;
+            stat_normal_pages += count;
+        }
+    }
+
+    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
+     * adjust the PoD cache size so that domain tot_pages will be
+     * target_pages - 0x20 after this call. */
+    if ( pod_mode )
+        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
+                                      NULL, NULL, NULL);
+
+    if ( rc != 0 )
+    {
+        PERROR("Could not allocate memory for HVM guest.");
+        goto error_out;
+    }
+
+    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+            "  4KB PAGES: 0x%016lx\n"
+            "  2MB PAGES: 0x%016lx\n"
+            "  1GB PAGES: 0x%016lx\n",
+            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+    
+    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
+        goto error_out;
+
+    if ( (hvm_info_page = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              HVM_INFO_PFN)) == NULL )
+        goto error_out;
+    build_hvm_info(hvm_info_page, v_end);
+    munmap(hvm_info_page, PAGE_SIZE);
+
+    /* Allocate and clear special pages. */
+    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+    {
+        xen_pfn_t pfn = special_pfn(i);
+        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Could not allocate %d'th special page.", i);
+            goto error_out;
+        }
+        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+            goto error_out;
+    }
+
+    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
+                     special_pfn(SPECIALPAGE_XENSTORE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
+                     special_pfn(SPECIALPAGE_BUFIOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
+                     special_pfn(SPECIALPAGE_IOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
+                     special_pfn(SPECIALPAGE_CONSOLE));
+
+    /*
+     * Identity-map page table is required for running with CR0.PG=0 when
+     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
+     */
+    if ( (ident_pt = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
+        goto error_out;
+    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
+        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+    munmap(ident_pt, PAGE_SIZE);
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
+                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
+
+    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
+    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
+    if ( entry_eip != 0 )
+    {
+        char *page0 = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+        if ( page0 == NULL )
+            goto error_out;
+        page0[0] = 0xe9;
+        *(uint32_t *)&page0[1] = entry_eip - 5;
+        munmap(page0, PAGE_SIZE);
+    }
+
+    free(page_array);
+    return 0;
+
+ error_out:
+    free(page_array);
+    return -1;
+}
+
+static int xc_hvm_build_internal(xc_interface *xch,
+                                 uint32_t domid,
+                                 int memsize,
+                                 int target,
+                                 char *image,
+                                 unsigned long image_size)
+{
+    if ( (image == NULL) || (image_size == 0) )
+    {
+        ERROR("Image required");
+        return -1;
+    }
+
+    return setup_guest(xch, domid, memsize, target, image, image_size);
+}
+
+/* xc_hvm_build:
+ * Create a domain for a virtualized Linux, using files/filenames.
+ */
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_target_mem: 
+ * Create a domain for a pre-ballooned virtualized Linux, using
+ * files/filenames.  If target < memsize, domain is created with
+ * memsize pages marked populate-on-demand, 
+ * calculating pod cache size based on target.
+ * If target == memsize, pages are populated normally.
+ */
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_mem:
+ * Create a domain for a virtualized Linux, using memory buffers.
+ */
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    int           sts;
+    unsigned long img_len;
+    char         *img;
+
+    /* Validate that there is a kernel buffer */
+
+    if ( (image_buffer == NULL) || (image_size == 0) )
+    {
+        ERROR("kernel image buffer not present");
+        return -1;
+    }
+
+    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
+    if ( img == NULL )
+    {
+        ERROR("unable to inflate ram disk buffer");
+        return -1;
+    }
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
+                                img, img_len);
+
+    /* xc_inflate_buffer may return the original buffer pointer (for
+       for already inflated buffers), so exercise some care in freeing */
+
+    if ( (img != NULL) && (img != image_buffer) )
+        free(img);
+
+    return sts;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..054b8e9
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqe-0002Uv-Lu; Wed, 15 Feb 2012 12:20:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdqa-0002SV-Lv
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329308410!8339346!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5599 invoked from network); 15 Feb 2012 12:20:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22018413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24v000803;
	Wed, 15 Feb 2012 04:20:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:29 +0000
Message-ID: <1329308673-30175-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Provide empty implementations of xc_domain_save and xc_domain_restore
when CONFIG_MIGRATE is not set.
Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
x86 specific, introduce xc_hvm_build_arm.c with empty stubs.


Changes in v3:

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;



Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile           |   12 +-
 tools/libxc/xc_dom_arm.c       |   49 ++++
 tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
 tools/libxc/xc_hvm_build_arm.c |   48 ++++
 tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c     |   41 ++++
 6 files changed, 658 insertions(+), 514 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build.c
 create mode 100644 tools/libxc/xc_hvm_build_arm.c
 create mode 100644 tools/libxc/xc_hvm_build_x86.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..02d39a3 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..bdd28e1
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,49 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    return -ENOSYS;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
deleted file mode 100644
index 1fa5658..0000000
--- a/tools/libxc/xc_hvm_build.c
+++ /dev/null
@@ -1,511 +0,0 @@
-/******************************************************************************
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <stddef.h>
-#include <inttypes.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <zlib.h>
-
-#include "xg_private.h"
-#include "xc_private.h"
-
-#include <xen/foreign/x86_32.h>
-#include <xen/foreign/x86_64.h>
-#include <xen/hvm/hvm_info_table.h>
-#include <xen/hvm/params.h>
-#include <xen/hvm/e820.h>
-
-#include <xen/libelf/libelf.h>
-
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
-
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
-{
-    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
-        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
-    uint64_t lowmem_end = mem_size, highmem_end = 0;
-    uint8_t sum;
-    int i;
-
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
-    {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
-    }
-
-    memset(hvm_info_page, 0, PAGE_SIZE);
-
-    /* Fill in the header. */
-    strncpy(hvm_info->signature, "HVM INFO", 8);
-    hvm_info->length = sizeof(struct hvm_info_table);
-
-    /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->apic_mode = 1;
-    hvm_info->nr_vcpus = 1;
-    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
-
-    /* Memory parameters. */
-    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
-    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
-    hvm_info->reserved_mem_pgstart = special_pfn(0);
-
-    /* Finish with the checksum. */
-    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
-        sum += ((uint8_t *)hvm_info)[i];
-    hvm_info->checksum = -sum;
-}
-
-static int loadelfimage(
-    xc_interface *xch,
-    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
-{
-    privcmd_mmap_entry_t *entries = NULL;
-    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
-    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
-    size_t pages = pfn_end - pfn_start;
-    int i, rc = -1;
-
-    /* Map address space for initial elf image. */
-    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-    if ( entries == NULL )
-        goto err;
-
-    for ( i = 0; i < pages; i++ )
-        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
-
-    elf->dest = xc_map_foreign_ranges(
-        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
-        entries, pages);
-    if ( elf->dest == NULL )
-        goto err;
-
-    elf->dest += elf->pstart & (PAGE_SIZE - 1);
-
-    /* Load the initial elf image. */
-    rc = elf_load_binary(elf);
-    if ( rc < 0 )
-        PERROR("Failed to load elf binary\n");
-
-    munmap(elf->dest, pages << PAGE_SHIFT);
-    elf->dest = NULL;
-
- err:
-    free(entries);
-
-    return rc;
-}
-
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
-{
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
-        return 0;
-    else
-        return 1;
-}
-
-static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
-                       char *image, unsigned long image_size)
-{
-    xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
-    unsigned long entry_eip, cur_pages, cur_pfn;
-    void *hvm_info_page;
-    uint32_t *ident_pt;
-    struct elf_binary elf;
-    uint64_t v_start, v_end;
-    int rc;
-    xen_capabilities_info_t caps;
-    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
-        stat_1gb_pages = 0;
-    int pod_mode = 0;
-
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
-        pod_mode = 1;
-
-    memset(&elf, 0, sizeof(elf));
-    if ( elf_init(&elf, image, image_size) != 0 )
-        goto error_out;
-
-    xc_elf_set_logfile(xch, &elf, 1);
-
-    elf_parse_binary(&elf);
-    v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
-
-    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
-    {
-        PERROR("Could not get Xen capabilities");
-        goto error_out;
-    }
-
-    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
-            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
-            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
-            "  ENTRY ADDRESS: %016"PRIx64"\n",
-            elf.pstart, elf.pend,
-            v_start, v_end,
-            elf_uval(&elf, elf.ehdr, e_entry));
-
-    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
-    {
-        PERROR("Could not allocate memory.");
-        goto error_out;
-    }
-
-    for ( i = 0; i < nr_pages; i++ )
-        page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
-
-    /*
-     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
-     *
-     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
-     * pages if 1GB allocation fails. 4KB pages will be used eventually if
-     * both fail.
-     * 
-     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
-     * ensure that we can be preempted and hence dom0 remains responsive.
-     */
-    rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
-    cur_pages = 0xc0;
-    stat_normal_pages = 0xc0;
-    while ( (rc == 0) && (nr_pages > cur_pages) )
-    {
-        /* Clip count to maximum 1GB extent. */
-        unsigned long count = nr_pages - cur_pages;
-        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-        if ( count > max_pages )
-            count = max_pages;
-
-        cur_pfn = page_array[cur_pages];
-
-        /* Take care the corner cases of super page tails */
-        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
-            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
-        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-                  (count > SUPERPAGE_1GB_NR_PFNS) )
-            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-        /* Attemp to allocate 1GB super page. Because in each pass we only
-         * allocate at most 1GB, we don't have to clip super page boundaries.
-         */
-        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
-             /* Check if there exists MMIO hole in the 1GB memory range */
-             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
-        {
-            long done;
-            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
-            xen_pfn_t sp_extents[nr_extents];
-
-            for ( i = 0; i < nr_extents; i++ )
-                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
-
-            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
-                                              pod_mode ? XENMEMF_populate_on_demand : 0,
-                                              sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
-        }
-
-        if ( count != 0 )
-        {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
-            if ( count > max_pages )
-                count = max_pages;
-            
-            /* Clip partial superpage extents to superpage boundaries. */
-            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
-                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
-            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                      (count > SUPERPAGE_2MB_NR_PFNS) )
-                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-            /* Attempt to allocate superpage extents. */
-            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
-            {
-                long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
-                xen_pfn_t sp_extents[nr_extents];
-
-                for ( i = 0; i < nr_extents; i++ )
-                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
-
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
-                                                  sp_extents);
-
-                if ( done > 0 )
-                {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
-                    cur_pages += done;
-                    count -= done;
-                }
-            }
-        }
-
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, 0, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
-        }
-    }
-
-    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
-     * adjust the PoD cache size so that domain tot_pages will be
-     * target_pages - 0x20 after this call. */
-    if ( pod_mode )
-        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
-                                      NULL, NULL, NULL);
-
-    if ( rc != 0 )
-    {
-        PERROR("Could not allocate memory for HVM guest.");
-        goto error_out;
-    }
-
-    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
-            "  4KB PAGES: 0x%016lx\n"
-            "  2MB PAGES: 0x%016lx\n"
-            "  1GB PAGES: 0x%016lx\n",
-            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
-    
-    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
-        goto error_out;
-
-    if ( (hvm_info_page = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              HVM_INFO_PFN)) == NULL )
-        goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
-    munmap(hvm_info_page, PAGE_SIZE);
-
-    /* Allocate and clear special pages. */
-    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-    {
-        xen_pfn_t pfn = special_pfn(i);
-        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
-        if ( rc != 0 )
-        {
-            PERROR("Could not allocate %d'th special page.", i);
-            goto error_out;
-        }
-        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
-            goto error_out;
-    }
-
-    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
-                     special_pfn(SPECIALPAGE_XENSTORE));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
-                     special_pfn(SPECIALPAGE_BUFIOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
-                     special_pfn(SPECIALPAGE_IOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
-                     special_pfn(SPECIALPAGE_CONSOLE));
-
-    /*
-     * Identity-map page table is required for running with CR0.PG=0 when
-     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
-     */
-    if ( (ident_pt = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
-        goto error_out;
-    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
-        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
-                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-    munmap(ident_pt, PAGE_SIZE);
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
-                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
-
-    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
-    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
-    if ( entry_eip != 0 )
-    {
-        char *page0 = xc_map_foreign_range(
-            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
-        if ( page0 == NULL )
-            goto error_out;
-        page0[0] = 0xe9;
-        *(uint32_t *)&page0[1] = entry_eip - 5;
-        munmap(page0, PAGE_SIZE);
-    }
-
-    free(page_array);
-    return 0;
-
- error_out:
-    free(page_array);
-    return -1;
-}
-
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
-/* xc_hvm_build:
- * Create a domain for a virtualized Linux, using files/filenames.
- */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_target_mem: 
- * Create a domain for a pre-ballooned virtualized Linux, using
- * files/filenames.  If target < memsize, domain is created with
- * memsize pages marked populate-on-demand, 
- * calculating pod cache size based on target.
- * If target == memsize, pages are populated normally.
- */
-int xc_hvm_build_target_mem(xc_interface *xch,
-                           uint32_t domid,
-                           int memsize,
-                           int target,
-                           const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
new file mode 100644
index 0000000..6cf65a1
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_arm.c
@@ -0,0 +1,48 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    return -ENOSYS;
+}
+
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    return -ENOSYS;
+}
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
new file mode 100644
index 0000000..1fa5658
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -0,0 +1,511 @@
+/******************************************************************************
+ * xc_hvm_build.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stddef.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <zlib.h>
+
+#include "xg_private.h"
+#include "xc_private.h"
+
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/params.h>
+#include <xen/hvm/e820.h>
+
+#include <xen/libelf/libelf.h>
+
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define SPECIALPAGE_BUFIOREQ 0
+#define SPECIALPAGE_XENSTORE 1
+#define SPECIALPAGE_IOREQ    2
+#define SPECIALPAGE_IDENT_PT 3
+#define SPECIALPAGE_CONSOLE  4
+#define NR_SPECIAL_PAGES     5
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+{
+    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+    uint64_t lowmem_end = mem_size, highmem_end = 0;
+    uint8_t sum;
+    int i;
+
+    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    {
+        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
+        lowmem_end = HVM_BELOW_4G_RAM_END;
+    }
+
+    memset(hvm_info_page, 0, PAGE_SIZE);
+
+    /* Fill in the header. */
+    strncpy(hvm_info->signature, "HVM INFO", 8);
+    hvm_info->length = sizeof(struct hvm_info_table);
+
+    /* Sensible defaults: these can be overridden by the caller. */
+    hvm_info->apic_mode = 1;
+    hvm_info->nr_vcpus = 1;
+    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+    /* Memory parameters. */
+    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
+    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
+    hvm_info->reserved_mem_pgstart = special_pfn(0);
+
+    /* Finish with the checksum. */
+    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+        sum += ((uint8_t *)hvm_info)[i];
+    hvm_info->checksum = -sum;
+}
+
+static int loadelfimage(
+    xc_interface *xch,
+    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
+{
+    privcmd_mmap_entry_t *entries = NULL;
+    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
+    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
+    size_t pages = pfn_end - pfn_start;
+    int i, rc = -1;
+
+    /* Map address space for initial elf image. */
+    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
+    if ( entries == NULL )
+        goto err;
+
+    for ( i = 0; i < pages; i++ )
+        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
+
+    elf->dest = xc_map_foreign_ranges(
+        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
+        entries, pages);
+    if ( elf->dest == NULL )
+        goto err;
+
+    elf->dest += elf->pstart & (PAGE_SIZE - 1);
+
+    /* Load the initial elf image. */
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
+
+    munmap(elf->dest, pages << PAGE_SHIFT);
+    elf->dest = NULL;
+
+ err:
+    free(entries);
+
+    return rc;
+}
+
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize)
+{
+    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
+         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+        return 0;
+    else
+        return 1;
+}
+
+static int setup_guest(xc_interface *xch,
+                       uint32_t dom, int memsize, int target,
+                       char *image, unsigned long image_size)
+{
+    xen_pfn_t *page_array = NULL;
+    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
+    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long entry_eip, cur_pages, cur_pfn;
+    void *hvm_info_page;
+    uint32_t *ident_pt;
+    struct elf_binary elf;
+    uint64_t v_start, v_end;
+    int rc;
+    xen_capabilities_info_t caps;
+    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
+        stat_1gb_pages = 0;
+    int pod_mode = 0;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( memsize < 2 || target < 2 )
+        goto error_out;
+
+    if ( memsize > target )
+        pod_mode = 1;
+
+    memset(&elf, 0, sizeof(elf));
+    if ( elf_init(&elf, image, image_size) != 0 )
+        goto error_out;
+
+    xc_elf_set_logfile(xch, &elf, 1);
+
+    elf_parse_binary(&elf);
+    v_start = 0;
+    v_end = (unsigned long long)memsize << 20;
+
+    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+    {
+        PERROR("Could not get Xen capabilities");
+        goto error_out;
+    }
+
+    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
+            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
+            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
+            "  ENTRY ADDRESS: %016"PRIx64"\n",
+            elf.pstart, elf.pend,
+            v_start, v_end,
+            elf_uval(&elf, elf.ehdr, e_entry));
+
+    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
+    {
+        PERROR("Could not allocate memory.");
+        goto error_out;
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+        page_array[i] = i;
+    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+
+    /*
+     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
+     *
+     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+     * pages if 1GB allocation fails. 4KB pages will be used eventually if
+     * both fail.
+     * 
+     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
+     * ensure that we can be preempted and hence dom0 remains responsive.
+     */
+    rc = xc_domain_populate_physmap_exact(
+        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
+    cur_pages = 0xc0;
+    stat_normal_pages = 0xc0;
+    while ( (rc == 0) && (nr_pages > cur_pages) )
+    {
+        /* Clip count to maximum 1GB extent. */
+        unsigned long count = nr_pages - cur_pages;
+        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+        if ( count > max_pages )
+            count = max_pages;
+
+        cur_pfn = page_array[cur_pages];
+
+        /* Take care the corner cases of super page tails */
+        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
+            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
+        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+                  (count > SUPERPAGE_1GB_NR_PFNS) )
+            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+        /* Attemp to allocate 1GB super page. Because in each pass we only
+         * allocate at most 1GB, we don't have to clip super page boundaries.
+         */
+        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
+             /* Check if there exists MMIO hole in the 1GB memory range */
+             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+        {
+            long done;
+            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
+            xen_pfn_t sp_extents[nr_extents];
+
+            for ( i = 0; i < nr_extents; i++ )
+                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
+
+            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                              pod_mode ? XENMEMF_populate_on_demand : 0,
+                                              sp_extents);
+
+            if ( done > 0 )
+            {
+                stat_1gb_pages += done;
+                done <<= SUPERPAGE_1GB_SHIFT;
+                cur_pages += done;
+                count -= done;
+            }
+        }
+
+        if ( count != 0 )
+        {
+            /* Clip count to maximum 8MB extent. */
+            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            if ( count > max_pages )
+                count = max_pages;
+            
+            /* Clip partial superpage extents to superpage boundaries. */
+            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
+                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
+            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                      (count > SUPERPAGE_2MB_NR_PFNS) )
+                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+            /* Attempt to allocate superpage extents. */
+            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+            {
+                long done;
+                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                xen_pfn_t sp_extents[nr_extents];
+
+                for ( i = 0; i < nr_extents; i++ )
+                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
+                                                  sp_extents);
+
+                if ( done > 0 )
+                {
+                    stat_2mb_pages += done;
+                    done <<= SUPERPAGE_2MB_SHIFT;
+                    cur_pages += done;
+                    count -= done;
+                }
+            }
+        }
+
+        /* Fall back to 4kB extents. */
+        if ( count != 0 )
+        {
+            rc = xc_domain_populate_physmap_exact(
+                xch, dom, count, 0, 0, &page_array[cur_pages]);
+            cur_pages += count;
+            stat_normal_pages += count;
+        }
+    }
+
+    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
+     * adjust the PoD cache size so that domain tot_pages will be
+     * target_pages - 0x20 after this call. */
+    if ( pod_mode )
+        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
+                                      NULL, NULL, NULL);
+
+    if ( rc != 0 )
+    {
+        PERROR("Could not allocate memory for HVM guest.");
+        goto error_out;
+    }
+
+    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+            "  4KB PAGES: 0x%016lx\n"
+            "  2MB PAGES: 0x%016lx\n"
+            "  1GB PAGES: 0x%016lx\n",
+            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+    
+    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
+        goto error_out;
+
+    if ( (hvm_info_page = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              HVM_INFO_PFN)) == NULL )
+        goto error_out;
+    build_hvm_info(hvm_info_page, v_end);
+    munmap(hvm_info_page, PAGE_SIZE);
+
+    /* Allocate and clear special pages. */
+    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+    {
+        xen_pfn_t pfn = special_pfn(i);
+        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Could not allocate %d'th special page.", i);
+            goto error_out;
+        }
+        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+            goto error_out;
+    }
+
+    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
+                     special_pfn(SPECIALPAGE_XENSTORE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
+                     special_pfn(SPECIALPAGE_BUFIOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
+                     special_pfn(SPECIALPAGE_IOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
+                     special_pfn(SPECIALPAGE_CONSOLE));
+
+    /*
+     * Identity-map page table is required for running with CR0.PG=0 when
+     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
+     */
+    if ( (ident_pt = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
+        goto error_out;
+    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
+        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+    munmap(ident_pt, PAGE_SIZE);
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
+                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
+
+    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
+    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
+    if ( entry_eip != 0 )
+    {
+        char *page0 = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+        if ( page0 == NULL )
+            goto error_out;
+        page0[0] = 0xe9;
+        *(uint32_t *)&page0[1] = entry_eip - 5;
+        munmap(page0, PAGE_SIZE);
+    }
+
+    free(page_array);
+    return 0;
+
+ error_out:
+    free(page_array);
+    return -1;
+}
+
+static int xc_hvm_build_internal(xc_interface *xch,
+                                 uint32_t domid,
+                                 int memsize,
+                                 int target,
+                                 char *image,
+                                 unsigned long image_size)
+{
+    if ( (image == NULL) || (image_size == 0) )
+    {
+        ERROR("Image required");
+        return -1;
+    }
+
+    return setup_guest(xch, domid, memsize, target, image, image_size);
+}
+
+/* xc_hvm_build:
+ * Create a domain for a virtualized Linux, using files/filenames.
+ */
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_target_mem: 
+ * Create a domain for a pre-ballooned virtualized Linux, using
+ * files/filenames.  If target < memsize, domain is created with
+ * memsize pages marked populate-on-demand, 
+ * calculating pod cache size based on target.
+ * If target == memsize, pages are populated normally.
+ */
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_mem:
+ * Create a domain for a virtualized Linux, using memory buffers.
+ */
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    int           sts;
+    unsigned long img_len;
+    char         *img;
+
+    /* Validate that there is a kernel buffer */
+
+    if ( (image_buffer == NULL) || (image_size == 0) )
+    {
+        ERROR("kernel image buffer not present");
+        return -1;
+    }
+
+    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
+    if ( img == NULL )
+    {
+        ERROR("unable to inflate ram disk buffer");
+        return -1;
+    }
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
+                                img, img_len);
+
+    /* xc_inflate_buffer may return the original buffer pointer (for
+       for already inflated buffers), so exercise some care in freeing */
+
+    if ( (img != NULL) && (img != image_buffer) )
+        free(img);
+
+    return sts;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..054b8e9
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    return -ENOSYS;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    return -ENOSYS;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqt-0002bp-C9; Wed, 15 Feb 2012 12:20:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdqq-0002X7-I6
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329308417!14978274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26290 invoked from network); 15 Feb 2012 12:20:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="181898044"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24u000803;
	Wed, 15 Feb 2012 04:20:04 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:28 +0000
Message-ID: <1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 2/7] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..29c13a7 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:20:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxdqt-0002bp-C9; Wed, 15 Feb 2012 12:20:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxdqq-0002X7-I6
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:20:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329308417!14978274!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26290 invoked from network); 15 Feb 2012 12:20:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="181898044"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 07:20:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 07:20:16 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FCK24u000803;
	Wed, 15 Feb 2012 04:20:04 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 12:24:28 +0000
Message-ID: <1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v4 2/7] arm: compile libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  106 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..b1482ec
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,106 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    return -ENOSYS;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..29c13a7 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:25:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxdvY-0003Ym-5F; Wed, 15 Feb 2012 12:25:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxdvW-0003YM-DN
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:25:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329308730!11570983!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4081 invoked from network); 15 Feb 2012 12:25:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:25:31 -0000
Received: by wibhm2 with SMTP id hm2so1353353wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 04:25:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=BBsqaqHWO1BDzd6qW1WcAKVwiT5rKDEi7R7RjuinnbU=;
	b=ncxAvndWThsgB0wE1BHXexxyMcW5fFyeCDYVQsMnrXgJr2X00DCY+LYx6S6AYBPbN7
	8vI700FuO4cMwu9qBKgMeRLWsVvj5vdt6vAazWwH20JsAscvGfDLtyWa1Y6gGV0LyhB3
	zXcAZ+13KFy2Zj6Z+o0jzQ95DL9ZZVdgmo5rY=
MIME-Version: 1.0
Received: by 10.180.101.228 with SMTP id fj4mr8159623wib.4.1329308730374; Wed,
	15 Feb 2012 04:25:30 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 15 Feb 2012 04:25:30 -0800 (PST)
In-Reply-To: <1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 13:25:30 +0100
X-Google-Sender-Auth: ISLndlvRXLiAzZsrd3E_I9g9yb0
Message-ID: <CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI2IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPjoKPiBQcm92
aWRlIGEgbmV3IHNldCBvZiBtYWNoaW5lcnkgZm9yIHdyaXRpbmcgcHVibGljIGxpYnhsIGZ1bmN0
aW9ucwo+IHdoaWNoIG1heSB0YWtlIGEgbG9uZyB0aW1lLiDCoFRoZSBhcHBsaWNhdGlvbiBnZXRz
IHRvIGRlY2lkZSB3aGV0aGVyCj4gdGhleSB3YW50IHRoZSBmdW5jdGlvbiB0byBiZSBzeW5jaHJv
bm91cywgb3Igd2hldGhlciB0aGV5J2QgcHJlZmVyIHRvCj4gZ2V0IGEgY2FsbGJhY2ssIG9yIGFu
IGV2ZW50LCB3aGVuIHRoZSBvcGVyYXRpb24gaXMgY29tcGxldGUuCj4KPiBVc2VyKHMpIG9mIHRo
aXMgbWFjaGluZXJ5IHdpbGwgYmUgaW50cm9kdWNlZCBpbiBsYXRlciBwYXRjaChlcykuCj4KPiBT
aWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPiAt
LS0KPiDCoHRvb2xzL2xpYnhsL2xpYnhsLmggwqAgwqAgwqAgwqAgwqB8IMKgIDUzICsrKysrKysr
KysrKwo+IMKgdG9vbHMvbGlieGwvbGlieGxfZXZlbnQuYyDCoCDCoHwgwqAxODggKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gwqB0b29scy9saWJ4bC9saWJ4bF9p
bnRlcm5hbC5oIHwgwqAxMDcgKysrKysrKysrKysrKysrKysrKysrKysrCj4gwqB0b29scy9saWJ4
bC9saWJ4bF90eXBlcy5pZGwgwqB8IMKgIMKgNCArCj4gwqA0IGZpbGVzIGNoYW5nZWQsIDM1MiBp
bnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhs
L2xpYnhsLmggYi90b29scy9saWJ4bC9saWJ4bC5oCj4gaW5kZXggZTMyODgxYi4uZmE3OWMyNCAx
MDA2NDQKPiAtLS0gYS90b29scy9saWJ4bC9saWJ4bC5oCj4gKysrIGIvdG9vbHMvbGlieGwvbGli
eGwuaAo+IEBAIC0yMzcsNiArMjM3LDU5IEBAIGVudW0gewo+IMKgIMKgIEVSUk9SX0JVRkZFUkZV
TEwgPSAtMTMsCj4gwqB9Owo+Cj4gKwo+ICsvKgo+ICsgKiBTb21lIGxpYnhsIG9wZXJhdGlvbnMg
Y2FuIHRha2UgYSBsb25nIHRpbWUuIMKgVGhlc2UgZnVuY3Rpb25zIHRha2UgYQo+ICsgKiBwYXJh
bWV0ZXIgdG8gY29udHJvbCB0aGVpciBjb25jdXJyZW5jeToKPiArICogwqAgwqAgbGlieGxfYXN5
bmNvcF9ob3cgKmFvX2hvdwo+ICsgKgo+ICsgKiBJZiBhb19ob3c9PU5VTEwsIHRoZSBmdW5jdGlv
biB3aWxsIGJlIHN5bmNocm9ub3VzLgo+ICsgKgo+ICsgKiBJZiBhb19ob3chPU5VTEwsIHRoZSBm
dW5jdGlvbiB3aWxsIHNldCB0aGUgb3BlcmF0aW9uIGdvaW5nLCBhbmQgaWYKPiArICogdGhpcyBp
cyBzdWNjZXNzZnVsIHdpbGwgcmV0dXJuIDAuIMKgSW4gdGhpcyBjYXNlIHRoZSB6ZXJvIGVycm9y
Cj4gKyAqIHJlc3BvbnNlIGRvZXMgTk9UIG1lYW4gdGhhdCB0aGUgb3BlcmF0aW9uIHdhcyBzdWNj
ZXNzZnVsOyBpdCBqdXN0Cj4gKyAqIG1lYW5zIHRoYXQgaXQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5
IHN0YXJ0ZWQuIMKgSXQgd2lsbCBmaW5pc2ggbGF0ZXIsCj4gKyAqIHBlcmhhcHMgd2l0aCBhbiBl
cnJvci4KPiArICoKPiArICogSWYgYW9faG93LT5jYWxsYmFjayE9TlVMTCwgdGhlIGNhbGxiYWNr
IHdpbGwgYmUgY2FsbGVkIHdoZW4gdGhlCj4gKyAqIG9wZXJhdGlvbiBjb21wbGV0ZXMuIMKgVGhl
IHNhbWUgcnVsZXMgYXMgZm9yIGxpYnhsX2V2ZW50X2hvb2tzCj4gKyAqIGFwcGx5LCBpbmNsdWRp
bmcgdGhlIHJlZW50cmFuY3kgcnVsZXMgYW5kIHRoZSBwb3NzaWJpbGl0eSBvZgo+ICsgKiAiZGlz
YXN0ZXIiLCBleGNlcHQgdGhhdCBsaWJ4bCBjYWxscyBhb19ob3ctPmNhbGxiYWNrIGluc3RlYWQg
b2YKPiArICogbGlieGxfZXZlbnRfaG9va3MuZXZlbnRfb2NjdXJzLiDCoChTZWUgbGlieGxfZXZl
bnQuaC4pCj4gKyAqCj4gKyAqIElmIGFvX2hvdy0+Y2FsbGJhY2s9PU5VTEwsIGEgbGlieGxfZXZl
bnQgd2lsbCBiZSBnZW5lcmF0ZWQgd2hpY2gKPiArICogY2FuIGJlIG9idGFpbmVkIGZyb20gbGli
eGxfZXZlbnRfd2FpdCBvciBsaWJ4bF9ldmVudF9jaGVjay4gwqBUaGUKPiArICogZXZlbnQgd2ls
bCBoYXZlIHR5cGUgT1BFUkFUSU9OX0NPTVBMRVRFICh3aGljaCBpcyBub3QgdXNlZAo+ICsgKiBl
bHNld2hlcmUpLgo+ICsgKgo+ICsgKiBOb3RlIHRoYXQgaXQgaXMgcG9zc2libGUgZm9yIGFuIGFz
eW5jaHJvbm91cyBvcGVyYXRpb24gd2hpY2ggaXMgdG8KPiArICogcmVzdWx0IGluIGEgY2FsbGJh
Y2sgdG8gY29tcGxldGUgZHVyaW5nIGl0cyBpbml0aWF0aW5nIGZ1bmN0aW9uCj4gKyAqIGNhbGwu
IMKgSW4gdGhpcyBjYXNlIHRoZSBpbml0aWF0aW5nIGZ1bmN0aW9uIHdpbGwgcmV0dXJuIDAKPiAr
ICogaW5kaWNhdGluZyB0aGUgYXQgdGhlIG9wZXJhdGlvbiBpcyAiaW4gcHJvZ3Jlc3MiLCBldmVu
IHRob3VnaCBieQo+ICsgKiB0aGUgdGltZSBpdCByZXR1cm5zIHRoZSBvcGVyYXRpb24gaXMgY29t
cGxldGUgYW5kIHRoZSBjYWxsYmFjayBoYXMKPiArICogYWxyZWFkeSBoYXBwZW5lZC4KPiArICoK
PiArICogVGhlIGFwcGxpY2F0aW9uIG11c3Qgc2V0IGFuZCB1c2UgYW9faG93LT5mb3JfZXZlbnQg
KHdoaWNoIHdpbGwgYmUKPiArICogY29waWVkIGludG8gbGlieGxfZXZlbnQuZm9yX3VzZXIpIG9y
IGFvX2hvdy0+Zm9yX2NhbGxiYWNrIChwYXNzZWQKPiArICogdG8gdGhlIGNhbGxiYWNrKSB0byBk
ZXRlcm1pbmUgd2hpY2ggb3BlcmF0aW9uIGZpbmlzaGVkLCBhbmQgaXQgbXVzdAo+ICsgKiBvZiBj
b3Vyc2UgY2hlY2sgdGhlIHJjIHZhbHVlIGZvciBlcnJvcnMuCj4gKyAqCj4gKyAqICphb19ob3cg
ZG9lcyBub3QgbmVlZCB0byByZW1haW4gdmFsaWQgYWZ0ZXIgdGhlIGluaXRpYXRpbmcgZnVuY3Rp
b24KPiArICogcmV0dXJucy4KPiArICoKPiArICogQ2FsbGJhY2tzIG1heSBvY2N1ciBvbiBhbnkg
dGhyZWFkIGluIHdoaWNoIHRoZSBhcHBsaWNhdGlvbiBjYWxscwo+ICsgKiBsaWJ4bC4KPiArICov
Cj4gKwo+ICt0eXBlZGVmIHN0cnVjdCB7Cj4gKyDCoCDCoHZvaWQgKCpjYWxsYmFjaykobGlieGxf
Y3R4ICpjdHgsIGludCByYywgdm9pZCAqZm9yX2NhbGxiYWNrKTsKPiArIMKgIMKgdW5pb24gewo+
ICsgwqAgwqAgwqAgwqBsaWJ4bF9ldl91c2VyIGZvcl9ldmVudDsgLyogdXNlZCBpZiBjYWxsYmFj
az09TlVMTCAqLwo+ICsgwqAgwqAgwqAgwqB2b2lkICpmb3JfY2FsbGJhY2s7IC8qIHBhc3NlZCB0
byBjYWxsYmFjayAqLwo+ICsgwqAgwqB9IHU7Cj4gK30gbGlieGxfYXN5bmNvcF9ob3c7Cj4gKwo+
ICsKPiDCoCNkZWZpbmUgTElCWExfVkVSU0lPTiAwCj4KPiDCoHR5cGVkZWYgc3RydWN0IHsKPiBk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZXZlbnQuYyBiL3Rvb2xzL2xpYnhsL2xpYnhs
X2V2ZW50LmMKPiBpbmRleCA3M2RmZDlkLi45ZTFhYjU2IDEwMDY0NAo+IC0tLSBhL3Rvb2xzL2xp
YnhsL2xpYnhsX2V2ZW50LmMKPiArKysgYi90b29scy9saWJ4bC9saWJ4bF9ldmVudC5jCj4gQEAg
LTc3MSwxMCArNzcxLDIxIEBAIHN0YXRpYyB2b2lkIGVnY19ydW5fY2FsbGJhY2tzKGxpYnhsX19l
Z2MgKmVnYykKPiDCoHsKPiDCoCDCoCBFR0NfR0M7Cj4gwqAgwqAgbGlieGxfZXZlbnQgKmV2LCAq
ZXZfdG1wOwo+ICsKPiDCoCDCoCBMSUJYTF9UQUlMUV9GT1JFQUNIX1NBRkUoZXYsICZlZ2MtPm9j
Y3VycmVkX2Zvcl9jYWxsYmFjaywgbGluaywgZXZfdG1wKSB7Cj4gwqAgwqAgwqAgwqAgTElCWExf
VEFJTFFfUkVNT1ZFKCZlZ2MtPm9jY3VycmVkX2Zvcl9jYWxsYmFjaywgZXYsIGxpbmspOwo+IMKg
IMKgIMKgIMKgIENUWC0+ZXZlbnRfaG9va3MtPmV2ZW50X29jY3VycyhDVFgtPmV2ZW50X2hvb2tz
X3VzZXIsIGV2KTsKPiDCoCDCoCB9Cj4gKwo+ICsgwqAgwqBsaWJ4bF9fYW8gKmFvLCAqYW9fdG1w
Owo+ICsgwqAgwqBMSUJYTF9UQUlMUV9GT1JFQUNIX1NBRkUoYW8sICZlZ2MtPmFvc19mb3JfY2Fs
bGJhY2ssCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbnRy
eV9mb3JfY2FsbGJhY2ssIGFvX3RtcCkgewo+ICsgwqAgwqAgwqAgwqBMSUJYTF9UQUlMUV9SRU1P
VkUoJmVnYy0+YW9zX2Zvcl9jYWxsYmFjaywgYW8sIGVudHJ5X2Zvcl9jYWxsYmFjayk7Cj4gKyDC
oCDCoCDCoCDCoGFvLT5ob3cuY2FsbGJhY2soQ1RYLCBhby0+cmMsIGFvLT5ob3cudS5mb3JfY2Fs
bGJhY2spOwo+ICsgwqAgwqAgwqAgwqBhby0+bm90aWZpZWQgPSAxOwo+ICsgwqAgwqAgwqAgwqBp
ZiAoIWFvLT5pbl9pbml0aWF0b3IpCj4gKyDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19hb19fZGVz
dHJveShDVFgsIGFvKTsKPiArIMKgIMKgfQo+IMKgfQo+Cj4gwqB2b2lkIGxpYnhsX19lZ2NfY2xl
YW51cChsaWJ4bF9fZWdjICplZ2MpCj4gQEAgLTEwNjEsNiArMTA3MiwxODMgQEAgaW50IGxpYnhs
X2V2ZW50X3dhaXQobGlieGxfY3R4ICpjdHgsIGxpYnhsX2V2ZW50ICoqZXZlbnRfciwKPiDCoCDC
oCByZXR1cm4gcmM7Cj4gwqB9Cj4KPiArCj4gKwo+ICsvKgo+ICsgKiBUaGUgdHdvIHBvc3NpYmxl
IHN0YXRlIGZsb3cgb2YgYW4gYW86Cj4gKyAqCj4gKyAqIENvbXBsZXRpb24gYmVmb3JlIGluaXRp
YXRvciByZXR1cm46Cj4gKyAqCj4gKyAqIMKgIMKgIEluaXRpYXRvciB0aHJlYWQgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUG9zc2libGUgb3RoZXIgdGhyZWFkcwo+ICsgKgo+ICsg
KiDCoCAqIGFvX2NyZWF0ZSBhbGxvY2F0ZXMgbWVtb3J5IGFuZAo+ICsgKiDCoCDCoCBpbml0aWFs
aXNlcyB0aGUgc3RydWN0Cj4gKyAqCj4gKyAqIMKgICogdGhlIGluaXRpYXRvciBmdW5jdGlvbiBk
b2VzIGl0cwo+ICsgKiDCoCDCoCB3b3JrLCBzZXR0aW5nIHVwIHZhcmlvdXMgaW50ZXJuYWwKPiAr
ICogwqAgwqAgYXN5bmNocm9ub3VzIG9wZXJhdGlvbnMgLS0tLS0tLS0tLS0+ICogYXN5bmNocm9u
b3VzIG9wZXJhdGlvbnMKPiArICogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdGFydCB0byB0YWtlIHBsYWNlIGFuZAo+ICsg
KiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoG1pZ2h0IGNhdXNlIGFvIGNvbXBsZXRpb24KPiArICogwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8
Cj4gKyAqIMKgICogaW5pdGlhdG9yIGNhbGxzIGFvX2lucHJvZ3Jlc3MgwqAgwqAgwqAgwqAgwqAg
wqAgwqB8Cj4gKyAqIMKgIMKgIC0gaWYgc3luY2hyb25vdXMsIHJ1biBldmVudCBsb29wIMKgIMKg
IMKgIMKgIMKgIHwKPiArICogwqAgwqAgwqAgdW50aWwgdGhlIGFvIGNvbXBsZXRlcyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCB8Cj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgLSBhbyBjb21wbGV0ZXMgb24gc29tZSB0aHJlYWQKPiArICogwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtIGNvbXBsZXRpbmcgdGhyZWFk
IHJlbGVhc2VzIHRoZSBsb2NrCj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDwt
LS0tLS0tLS0tLS0tLScKPiArICogwqAgwqAgLSBhb19pbnByb2dyZXNzIHRha2VzIHRoZSBsb2Nr
Cj4gKyAqIMKgIMKgIC0gZGVzdHJveSB0aGUgYW8KPiArICoKPiArICoKPiArICogQ29tcGxldGlv
biBhZnRlciBpbml0aWF0b3IgcmV0dXJuIChhc3luY2guIG9ubHkpOgo+ICsgKgo+ICsgKgo+ICsg
KiDCoCDCoCBJbml0aWF0b3IgdGhyZWFkIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IFBvc3NpYmxlIG90aGVyIHRocmVhZHMKPiArICoKPiArICogwqAgKiBhb19jcmVhdGUgYWxsb2Nh
dGVzIG1lbW9yeSBhbmQKPiArICogwqAgwqAgaW5pdGlhbGlzZXMgdGhlIHN0cnVjdAo+ICsgKgo+
ICsgKiDCoCAqIHRoZSBpbml0aWF0b3IgZnVuY3Rpb24gZG9lcyBpdHMKPiArICogwqAgwqAgd29y
aywgc2V0dGluZyB1cCB2YXJpb3VzIGludGVybmFsCj4gKyAqIMKgIMKgIGFzeW5jaHJvbm91cyBv
cGVyYXRpb25zIC0tLS0tLS0tLS0tPiAqIGFzeW5jaHJvbm91cyBvcGVyYXRpb25zCj4gKyAqIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgc3RhcnQgdG8gdGFrZSBwbGFjZSBhbmQKPiArICogwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtaWdodCBjYXVzZSBh
byBjb21wbGV0aW9uCj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfAo+ICsgKiDCoCAqIGluaXRpYXRvciBj
YWxscyBhb19pbnByb2dyZXNzIMKgIMKgIMKgIMKgIMKgIMKgIMKgfAo+ICsgKiDCoCDCoCAtIG9i
c2VydmVzIGV2ZW50IG5vdCB5ZXQgZG9uZSwgwqAgwqAgwqAgwqAgwqAgwqAgfAo+ICsgKiDCoCDC
oCAtIHJldHVybnMgdG8gY2FsbGVyIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
fAo+ICsgKiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwKPiArICogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAtIGFvIGNvbXBsZXRlcyBvbiBzb21lIHRocmVhZAo+ICsgKiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0gZ2VuZXJhdGUgdGhlIGV2
ZW50IG9yIGNhbGwgdGhlIGNhbGxiYWNrCj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgLSBkZXN0cm95IHRoZSBhbwo+ICsgKi8KPiArCj4gK3ZvaWQgbGli
eGxfX2FvX19kZXN0cm95KGxpYnhsX2N0eCAqY3R4LCBsaWJ4bF9fYW8gKmFvKQo+ICt7Cj4gKyDC
oCDCoGlmICghYW8pIHJldHVybjsKPiArIMKgIMKgaWYgKGFvLT5wb2xsZXIpIGxpYnhsX19wb2xs
ZXJfcHV0KGN0eCwgYW8tPnBvbGxlcik7Cj4gKyDCoCDCoGFvLT5tYWdpYyA9IExJQlhMX19BT19N
QUdJQ19ERVNUUk9ZRUQ7Cj4gKyDCoCDCoGxpYnhsX19mcmVlX2FsbCgmYW8tPmdjKTsKPiArIMKg
IMKgZnJlZShhbyk7Cj4gK30KPiArCj4gK3ZvaWQgbGlieGxfX2FvX2Fib3J0KGxpYnhsX19hbyAq
YW8pCj4gK3sKPiArIMKgIMKgQU9fR0M7Cj4gKyDCoCDCoGFzc2VydChhby0+bWFnaWMgPT0gTElC
WExfX0FPX01BR0lDKTsKPiArIMKgIMKgYXNzZXJ0KGFvLT5pbl9pbml0aWF0b3IpOwo+ICsgwqAg
wqBhc3NlcnQoIWFvLT5jb21wbGV0ZSk7Cj4gKyDCoCDCoGxpYnhsX19hb19fZGVzdHJveShDVFgs
IGFvKTsKPiArfQo+ICsKPiArdm9pZCBsaWJ4bF9fYW9fY29tcGxldGUobGlieGxfX2VnYyAqZWdj
LCBsaWJ4bF9fYW8gKmFvLCBpbnQgcmMpCj4gK3sKPiArIMKgIMKgYXNzZXJ0KGFvLT5tYWdpYyA9
PSBMSUJYTF9fQU9fTUFHSUMpOwo+ICsgwqAgwqBhc3NlcnQoIWFvLT5jb21wbGV0ZSk7Cj4gKyDC
oCDCoGFvLT5jb21wbGV0ZSA9IDE7Cj4gKyDCoCDCoGFvLT5yYyA9IHJjOwo+ICsKPiArIMKgIMKg
aWYgKGFvLT5wb2xsZXIpIHsKPiArIMKgIMKgIMKgIMKgYXNzZXJ0KGFvLT5pbl9pbml0aWF0b3Ip
Owo+ICsgwqAgwqAgwqAgwqBsaWJ4bF9fcG9sbGVyX3dha2V1cChlZ2MsIGFvLT5wb2xsZXIpOwo+
ICsgwqAgwqB9IGVsc2UgaWYgKGFvLT5ob3cuY2FsbGJhY2spIHsKPiArIMKgIMKgIMKgIMKgTElC
WExfVEFJTFFfSU5TRVJUX1RBSUwoJmVnYy0+YW9zX2Zvcl9jYWxsYmFjaywgYW8sIGVudHJ5X2Zv
cl9jYWxsYmFjayk7Cj4gKyDCoCDCoH0gZWxzZSB7Cj4gKyDCoCDCoCDCoCDCoGxpYnhsX2V2ZW50
ICpldjsKPiArIMKgIMKgIMKgIMKgZXYgPSBORVdfRVZFTlQoZWdjLCBPUEVSQVRJT05fQ09NUExF
VEUsIGFvLT5kb21pZCk7Cj4gKyDCoCDCoCDCoCDCoGlmIChldikgewo+ICsgwqAgwqAgwqAgwqAg
wqAgwqBldi0+Zm9yX3VzZXIgPSBhby0+aG93LnUuZm9yX2V2ZW50Owo+ICsgwqAgwqAgwqAgwqAg
wqAgwqBldi0+dS5vcGVyYXRpb25fY29tcGxldGUucmMgPSBhby0+cmM7Cj4gKyDCoCDCoCDCoCDC
oCDCoCDCoGxpYnhsX19ldmVudF9vY2N1cnJlZChlZ2MsIGV2KTsKPiArIMKgIMKgIMKgIMKgfQo+
ICsgwqAgwqAgwqAgwqBhby0+bm90aWZpZWQgPSAxOwo+ICsgwqAgwqB9Cj4gKyDCoCDCoGlmICgh
YW8tPmluX2luaXRpYXRvciAmJiBhby0+bm90aWZpZWQpCj4gKyDCoCDCoCDCoCDCoGxpYnhsX19h
b19fZGVzdHJveShsaWJ4bF9fZ2Nfb3duZXIoJmVnYy0+Z2MpLCBhbyk7Cj4gK30KPiArCj4gK2xp
YnhsX19hbyAqbGlieGxfX2FvX2NyZWF0ZShsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQs
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbnN0IGxpYnhs
X2FzeW5jb3BfaG93ICpob3cpCj4gK3sKPiArIMKgIMKgbGlieGxfX2FvICphbzsKPiArCj4gKyDC
oCDCoGFvID0gY2FsbG9jKDEsIHNpemVvZigqYW8pKTsKPiArIMKgIMKgaWYgKCFhbykgZ290byBv
dXQ7Cj4gKwo+ICsgwqAgwqBhby0+bWFnaWMgPSBMSUJYTF9fQU9fTUFHSUM7Cj4gKyDCoCDCoGFv
LT5pbl9pbml0aWF0b3IgPSAxOwo+ICsgwqAgwqBhby0+cG9sbGVyID0gMDsKPiArIMKgIMKgYW8t
PmRvbWlkID0gZG9taWQ7Cj4gKyDCoCDCoExJQlhMX0lOSVRfR0MoYW8tPmdjLCBjdHgpOwo+ICsK
PiArIMKgIMKgaWYgKGhvdykgewo+ICsgwqAgwqAgwqAgwqBhby0+aG93ID0gKmhvdzsKPiArIMKg
IMKgfSBlbHNlIHsKPiArIMKgIMKgIMKgIMKgYW8tPnBvbGxlciA9IGxpYnhsX19wb2xsZXJfZ2V0
KGN0eCk7Cj4gKyDCoCDCoCDCoCDCoGlmICghYW8tPnBvbGxlcikgZ290byBvdXQ7Cj4gKyDCoCDC
oH0KPiArIMKgIMKgcmV0dXJuIGFvOwo+ICsKPiArIG91dDoKPiArIMKgIMKgaWYgKGFvKSBsaWJ4
bF9fYW9fX2Rlc3Ryb3koY3R4LCBhbyk7Cj4gKyDCoCDCoHJldHVybiBOVUxMOwo+ICt9Cj4gKwo+
ICtpbnQgbGlieGxfX2FvX2lucHJvZ3Jlc3MobGlieGxfX2FvICphbykKPiArewo+ICsgwqAgwqBB
T19HQzsKPiArIMKgIMKgaW50IHJjOwoKSSd2ZSBqdXN0IHN0YXJ0ZWQgcGxheWluZyB3aXRoIHRo
aXMsIGJ1dCBJJ3ZlIGZvdW5kIHRoYXQgaWYgeW91IGNhbGwKQU9fSU5QUk9HUkVTUyB3aXRob3V0
IGFkZGluZyBhbnkgZXZlbnQgaXQgYmxvY2tzIGZvcmV2ZXIsIGFuZCBJJ20gbm90CnN1cmUgaWYg
dGhhdCBpcyBhIGRlc2lnbiBkZWNpc2lvbiBvciBhIGJ1Zy4gQW55d2F5LCBzb21ldGltZXMgbGlr
ZSBpbgpsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSB5b3UgbWlnaHQgY2FsbCBBT19JTlBS
T0dSRVNTIHdpdGhvdXQKYWRkaW5nIGFueSBldmVudCwgc28gSSB0aGluayBpdCB3aWxsIGJlIHNh
ZmUgdG8gYWRkIHNvbWV0aGluZyBsaWtlOgoKaWYgKCFDVFgtPndhdGNoX2NvdW50ZXIpCiAgICBy
ZXR1cm4gMDsKClRvIHByZXZlbnQgd2FpdGluZyBmb3JldmVyLCBpZiBub3Qgd2UgbmVlZCB0byBi
ZSBzdXJlIHdlIG9ubHkgY2FsbApBT19JTlBST0dSRVNTIHdoZW4gd2UgaGF2ZSBhZGRlZCBzb21l
IGV2ZW50cyAod2hpY2ggaXMgbm90IGFzCnByYWN0aWNhbCBhcyB0aGlzIHNpbXBsZSBmaXgpLiBT
aW5jZSBJJ3ZlIGp1c3Qgc3RhcnRlZCBwbGF5aW5nIHdpdGgKdGhlIGV2ZW50cyBBUEksIEkgbWln
aHQgYmUgZG9pbmcgYW4gaW5jb3JyZWN0IHVzYWdlIG9mIHRoaXMsIGlmIHRoaXMKc291bmRzIG9r
IHBsZWFzZSBkcm9wIGEgbGluZSBhbmQgSSB3aWxsIHNlbmQgYSBmb3JtYWwgcGF0Y2guCgpUaGFu
a3MsIFJvZ2VyLgoKPiArCj4gKyDCoCDCoGFzc2VydChhby0+bWFnaWMgPT0gTElCWExfX0FPX01B
R0lDKTsKPiArIMKgIMKgYXNzZXJ0KGFvLT5pbl9pbml0aWF0b3IpOwo+ICsKPiArIMKgIMKgaWYg
KGFvLT5wb2xsZXIpIHsKPiArIMKgIMKgIMKgIMKgLyogQ2FsbGVyIHdhbnRzIGl0IGRvbmUgc3lu
Y2hyb25vdXNseS4gKi8KPiArIMKgIMKgIMKgIMKgLyogV2UgdXNlIGEgZnJlc2ggZ2MsIHNvIHRo
YXQgd2UgY2FuIGZyZWUgdGhpbmdzCj4gKyDCoCDCoCDCoCDCoCAqIGVhY2ggdGltZSByb3VuZCB0
aGUgbG9vcC4gKi8KPiArIMKgIMKgIMKgIMKgbGlieGxfX2VnYyBlZ2M7Cj4gKyDCoCDCoCDCoCDC
oExJQlhMX0lOSVRfRUdDKGVnYyxDVFgpOwo+ICsKPiArIMKgIMKgIMKgIMKgZm9yICg7Oykgewo+
ICsgwqAgwqAgwqAgwqAgwqAgwqBhc3NlcnQoYW8tPm1hZ2ljID09IExJQlhMX19BT19NQUdJQyk7
Cj4gKwo+ICsgwqAgwqAgwqAgwqAgwqAgwqBpZiAoYW8tPmNvbXBsZXRlKSB7Cj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoHJjID0gYW8tPnJjOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBh
by0+bm90aWZpZWQgPSAxOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPiArIMKg
IMKgIMKgIMKgIMKgIMKgfQo+ICsKPiArIMKgIMKgIMKgIMKgIMKgIMKgcmMgPSBldmVudGxvb3Bf
aXRlcmF0aW9uKCZlZ2MsYW8tPnBvbGxlcik7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoGlmIChyYykg
ewo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAvKiBPaCBkZWFyLCB0aGlzIGlzIHF1aXRlIHVu
Zm9ydHVuYXRlLiAqLwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBMSUJYTF9fTE9HKENUWCwg
TElCWExfX0xPR19FUlJPUiwgIkVycm9yIHdhaXRpbmcgZm9yIgo+ICsgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgIiBldmVudCBkdXJpbmcgbG9uZy1ydW5uaW5nIG9wZXJh
dGlvbiAocmM9JWQpIiwgcmMpOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzbGVlcCgxKTsK
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLyogSXQncyBlaXRoZXIgdGhpcyBvciByZXR1cm4g
RVJST1JfSV9ET05UX0tOT1dfV0hFVEhFUgo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBf
VEhFX1RISU5HX1lPVV9BU0tFRF9GT1JfV0lMTF9CRV9ET05FX0xBVEVSX1dIRU4KPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgICogX1lPVV9ESUROVF9FWFBFQ1RfSVQsIHNpbmNlIHdlIGRvbid0
IGhhdmUgYW55IGtpbmQgb2YKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogY2FuY2VsbGF0
aW9uIGFiaWxpdHkuICovCj4gKyDCoCDCoCDCoCDCoCDCoCDCoH0KPiArCj4gKyDCoCDCoCDCoCDC
oCDCoCDCoENUWF9VTkxPQ0s7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19lZ2NfY2xlYW51
cCgmZWdjKTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgQ1RYX0xPQ0s7Cj4gKyDCoCDCoCDCoCDCoH0K
PiArIMKgIMKgfSBlbHNlIHsKPiArIMKgIMKgIMKgIMKgcmMgPSAwOwo+ICsgwqAgwqB9Cj4gKwo+
ICsgwqAgwqBhby0+aW5faW5pdGlhdG9yID0gMDsKPiArCj4gKyDCoCDCoGlmIChhby0+bm90aWZp
ZWQpIHsKPiArIMKgIMKgIMKgIMKgYXNzZXJ0KGFvLT5jb21wbGV0ZSk7Cj4gKyDCoCDCoCDCoCDC
oGxpYnhsX19hb19fZGVzdHJveShDVFgsYW8pOwo+ICsgwqAgwqB9Cj4gKwo+ICsgwqAgwqByZXR1
cm4gcmM7Cj4gK30KPiArCj4gKwo+IMKgLyoKPiDCoCogTG9jYWwgdmFyaWFibGVzOgo+IMKgKiBt
b2RlOiBDCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVybmFsLmggYi90b29s
cy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oCj4gaW5kZXggZDFiOTZjMS4uMDQ0ZWViNCAxMDA2NDQK
PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oCj4gKysrIGIvdG9vbHMvbGlieGwv
bGlieGxfaW50ZXJuYWwuaAo+IEBAIC0xMTQsNiArMTE0LDcgQEAgX2hpZGRlbiB2b2lkIGxpYnhs
X19sb2cobGlieGxfY3R4ICpjdHgsIHhlbnRvb2xsb2dfbGV2ZWwgbXNnbGV2ZWwsIGludCBlcnJu
b3ZhbCwKPgo+IMKgdHlwZWRlZiBzdHJ1Y3QgbGlieGxfX2djIGxpYnhsX19nYzsKPiDCoHR5cGVk
ZWYgc3RydWN0IGxpYnhsX19lZ2MgbGlieGxfX2VnYzsKPiArdHlwZWRlZiBzdHJ1Y3QgbGlieGxf
X2FvIGxpYnhsX19hbzsKPgo+IMKgdHlwZWRlZiBzdHJ1Y3QgbGlieGxfX2V2X2ZkIGxpYnhsX19l
dl9mZDsKPiDCoHR5cGVkZWYgdm9pZCBsaWJ4bF9fZXZfZmRfY2FsbGJhY2sobGlieGxfX2VnYyAq
ZWdjLCBsaWJ4bF9fZXZfZmQgKmV2LAo+IEBAIC0yMTgsNiArMjE5LDEwIEBAIHN0cnVjdCBsaWJ4
bF9fcG9sbGVyIHsKPiDCoCDCoCDCoCogcmVsZWFzaW5nIHRoZSBjdHggbG9jayBhbmQgZ29pbmcg
aW50byBwb2xsOyB3aGVuIGl0IGNvbWVzIG91dAo+IMKgIMKgIMKgKiBvZiBwb2xsIGl0IHdpbGwg
dGFrZSB0aGUgcG9sbGVyIG9mZiB0aGUgcG9sbGVyc19ldmVudCBsaXN0Lgo+IMKgIMKgIMKgKgo+
ICsgwqAgwqAgKiBBIHRocmVhZCB3aGljaCBpcyB3YWl0aW5nIGZvciBjb21wbGV0aW9uIG9mIGEg
c3luY2hyb25vdXMgYW8KPiArIMKgIMKgICogd2lsbCBhbGxvY2F0ZSBhIHBvbGxlciBhbmQgcmVj
b3JkIGl0IGluIHRoZSBhbywgc28gdGhhdCBvdGhlcgo+ICsgwqAgwqAgKiB0aHJlYWRzIGNhbiB3
YWtlIGl0IHVwLgo+ICsgwqAgwqAgKgo+IMKgIMKgIMKgKiBXaGVuIGEgdGhyZWFkIGlzIGRvbmUg
d2l0aCBhIHBvbGxlciBpdCBzaG91bGQgcHV0IGl0IG9udG8KPiDCoCDCoCDCoCogcG9sbGVyc19p
ZGxlLCB3aGVyZSBpdCBjYW4gYmUgcmV1c2VkIGxhdGVyLgo+IMKgIMKgIMKgKgo+IEBAIC0zMjQs
NiArMzI5LDIxIEBAIHN0cnVjdCBsaWJ4bF9fZWdjIHsKPiDCoCDCoCAvKiBmb3IgZXZlbnQtZ2Vu
ZXJhdGluZyBmdW5jdGlvbnMgb25seSAqLwo+IMKgIMKgIHN0cnVjdCBsaWJ4bF9fZ2MgZ2M7Cj4g
wqAgwqAgc3RydWN0IGxpYnhsX19ldmVudF9saXN0IG9jY3VycmVkX2Zvcl9jYWxsYmFjazsKPiAr
IMKgIMKgTElCWExfVEFJTFFfSEVBRCgsIGxpYnhsX19hbykgYW9zX2Zvcl9jYWxsYmFjazsKPiAr
fTsKPiArCj4gKyNkZWZpbmUgTElCWExfX0FPX01BR0lDIMKgIMKgIMKgIMKgIMKgIMKgIMKgMHhB
MEZBQ0UwMHVsCj4gKyNkZWZpbmUgTElCWExfX0FPX01BR0lDX0RFU1RST1lFRCDCoCDCoDB4QTBE
RUFEMDB1bAo+ICsKPiArc3RydWN0IGxpYnhsX19hbyB7Cj4gKyDCoCDCoHVpbnQzMl90IG1hZ2lj
Owo+ICsgwqAgwqB1bnNpZ25lZCBpbl9pbml0aWF0b3I6MSwgY29tcGxldGU6MSwgbm90aWZpZWQ6
MTsKPiArIMKgIMKgaW50IHJjOwo+ICsgwqAgwqBsaWJ4bF9fZ2MgZ2M7Cj4gKyDCoCDCoGxpYnhs
X2FzeW5jb3BfaG93IGhvdzsKPiArIMKgIMKgbGlieGxfX3BvbGxlciAqcG9sbGVyOwo+ICsgwqAg
wqB1aW50MzJfdCBkb21pZDsKPiArIMKgIMKgTElCWExfVEFJTFFfRU5UUlkobGlieGxfX2FvKSBl
bnRyeV9mb3JfY2FsbGJhY2s7Cj4gwqB9Owo+Cj4gwqAjZGVmaW5lIExJQlhMX0lOSVRfR0MoZ2Ms
Y3R4KSBkb3sgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+IEBAIC0xMTA4LDYgKzExMjgsNyBAQCBs
aWJ4bF9fZGV2aWNlX21vZGVsX3ZlcnNpb25fcnVubmluZyhsaWJ4bF9fZ2MgKmdjLCB1aW50MzJf
dCBkb21pZCk7Cj4gwqAjZGVmaW5lIExJQlhMX0lOSVRfRUdDKGVnYyxjdHgpIGRveyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBcCj4gwqAgwqAgwqAgwqAgTElCWExfSU5JVF9HQygoZWdj
KS5nYyxjdHgpOyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFwKPiDCoCDCoCDCoCDCoCBM
SUJYTF9UQUlMUV9JTklUKCYoZWdjKS5vY2N1cnJlZF9mb3JfY2FsbGJhY2spOyBcCj4gKyDCoCDC
oCDCoCDCoExJQlhMX1RBSUxRX0lOSVQoJihlZ2MpLmFvc19mb3JfY2FsbGJhY2spOyDCoCDCoCDC
oFwKPiDCoCDCoCB9IHdoaWxlKDApCj4KPiDCoF9oaWRkZW4gdm9pZCBsaWJ4bF9fZWdjX2NsZWFu
dXAobGlieGxfX2VnYyAqZWdjKTsKPiBAQCAtMTEyNSw2ICsxMTQ2LDkyIEBAIF9oaWRkZW4gdm9p
ZCBsaWJ4bF9fZWdjX2NsZWFudXAobGlieGxfX2VnYyAqZWdjKTsKPgo+Cj4gwqAvKgo+ICsgKiBN
YWNoaW5lcnkgZm9yIGFzeW5jaHJvbm91cyBvcGVyYXRpb25zICgiYW8iKQo+ICsgKgo+ICsgKiBB
bGwgInNsb3ciIGZ1bmN0aW9ucyAoaW5jbHVkZXMgYW55dGhpbmcgdGhhdCBtaWdodCBibG9jayBv
biBhCj4gKyAqIGd1ZXN0IG9yIGFuIGV4dGVybmFsIHNjcmlwdCkgbmVlZCB0byB1c2UgdGhlIGFz
eW5jaHJvbm91cwo+ICsgKiBvcGVyYXRpb24gKCJhbyIpIG1hY2hpbmVyeS4gwqBUaGUgZnVuY3Rp
b24gc2hvdWxkIHRha2UgYSBwYXJhbWV0ZXIKPiArICogY29uc3QgbGlieGxfYXN5bmNvcF9ob3cg
KmFvX2hvdyBhbmQgbXVzdCBzdGFydCB3aXRoIGEgY2FsbCB0bwo+ICsgKiBBT19JTklUSUFUT1Jf
RU5UUlkuIMKgVGhlc2UgZnVuY3Rpb25zIE1BWSBOT1QgYmUgY2FsbGVkIGZyb20KPiArICogb3V0
c2lkZSBsaWJ4bCwgYmVjYXVzZSB0aGV5IGNhbiBjYXVzZSByZWVudHJhbmN5IGNhbGxiYWNrcy4K
PiArICoKPiArICogTGlmZWN5Y2xlIG9mIGFuIGFvOgo+ICsgKgo+ICsgKiAtIENyZWF0ZWQgYnkg
bGlieGxfX2FvX2NyZWF0ZSAob3IgdGhlIEFPX0NSRUFURSBjb252ZW5pZW5jZSBtYWNybykuCj4g
KyAqCj4gKyAqIC0gQWZ0ZXIgY3JlYXRpb24sIGNhbiBiZSB1c2VkIGJ5IGNvZGUgd2hpY2ggaW1w
bGVtZW50cwo+ICsgKiDCoCB0aGUgb3BlcmF0aW9uIGFzIGZvbGxvd3M6Cj4gKyAqIMKgIMKgIMKg
LSB0aGUgYW8ncyBnYywgZm9yIGFsbG9jYXRpbmcgbWVtb3J5IGZvciB0aGUgbGlmZXRpbWUKPiAr
ICogwqAgwqAgwqAgwqBvZiB0aGUgb3BlcmF0aW9uIChwb3NzaWJseSB3aXRoIHRoZSBoZWxwIG9m
IHRoZSBBT19HQwo+ICsgKiDCoCDCoCDCoCDCoG1hY3JvIHRvIGludHJvZHVjZSB0aGUgZ2MgaW50
byBzY29wZSkKPiArICogwqAgwqAgwqAtIHRoZSBhbyBpdHNlbGYgbWF5IGJlIHBhc3NlZCBhYm91
dCB0byBzdWItZnVuY3Rpb25zCj4gKyAqIMKgIMKgIMKgIMKgc28gdGhhdCB0aGV5IGNhbiBzdGFz
aCBpdCBhd2F5IGV0Yy4KPiArICogwqAgwqAgwqAtIGluIHBhcnRpY3VsYXIsIHRoZSBhbyBwb2lu
dGVyIG11c3QgYmUgc3Rhc2hlZCBpbiBzb21lCj4gKyAqIMKgIMKgIMKgIMKgcGVyLW9wZXJhdGlv
biBzdHJ1Y3R1cmUgd2hpY2ggaXMgYWxzbyBwYXNzZWQgYXMgYSB1c2VyCj4gKyAqIMKgIMKgIMKg
IMKgcG9pbnRlciB0byB0aGUgaW50ZXJuYWwgZXZlbnQgZ2VuZXJhdGlvbiByZXF1ZXN0IHJvdXRp
bmVzCj4gKyAqIMKgIMKgIMKgIMKgbGlieGxfX2V2Z2VuX0ZPTywgc28gdGhhdCBhdCBzb21lIHBv
aW50IGEgQ0FMTEJBQ0sgd2lsbCBiZQo+ICsgKiDCoCDCoCDCoCDCoG1hZGUgd2hlbiB0aGUgb3Bl
cmF0aW9uIGlzIGNvbXBsZXRlLgo+ICsgKgo+ICsgKiAtIElmIGluaXRpYXRpb24gaXMgc3VjY2Vz
c2Z1bCwgdGhlIGluaXRpYXRpbmcgZnVuY3Rpb24gbmVlZHMKPiArICogwqAgdG8gcnVuIGxpYnhs
X19hb19pbnByb2dyZXNzIHJpZ2h0IGJlZm9yZSB1bmxvY2tpbmcgYW5kCj4gKyAqIMKgIHJldHVy
bmluZywgYW5kIHJldHVybiB3aGF0ZXZlciBpdCByZXR1cm5zIChBT19JTlBST0dSRVNTIG1hY3Jv
KS4KPiArICoKPiArICogLSBJZiB0aGUgaW5pdGlhdGlvbiBpcyB1bnN1Y2Nlc3NmdWwsIHRoZSBp
bml0aWF0aW5nIGZ1bmN0aW9uIG11c3QKPiArICogwqAgY2FsbCBsaWJ4bF9fYW9fYWJvcnQgYmVm
b3JlIHVubG9ja2luZyBhbmQgcmV0dXJuaW5nIHdoYXRldmVyCj4gKyAqIMKgIGVycm9yIGNvZGUg
aXMgYXBwcm9wcmlhdGUgKEFPX0FCT1JUIG1hY3JvKS4KPiArICoKPiArICogLSBMYXRlciwgc29t
ZSBjYWxsYmFjayBmdW5jdGlvbiwgd2hvc2UgY2FsbGJhY2sgaGFzIGJlZW4gcmVxdWVzdGVkCj4g
KyAqIMKgIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIHNob3VsZCBjYWxsIGxpYnhsX19hb19jb21w
bGV0ZSAod2l0aCB0aGUKPiArICogwqAgY3R4IGxvY2tlZCwgYXMgaXQgd2lsbCBnZW5lcmFsbHkg
YWxyZWFkeSBiZSBpbiBhbnkgZXZlbnQgY2FsbGJhY2sKPiArICogwqAgZnVuY3Rpb24pLiDCoFRo
aXMgbXVzdCBoYXBwZW4gZXhhY3RseSBvbmNlIGZvciBlYWNoIGFvIChhbmQgbm90IGlmCj4gKyAq
IMKgIHRoZSBhbyBoYXMgYmVlbiBkZXN0cm95ZWQsIG9idmlvdXNseSksIGFuZCBpdCBtYXkgbm90
IGhhcHBlbgo+ICsgKiDCoCB1bnRpbCBsaWJ4bF9fYW9faW5wcm9ncmVzcyBoYXMgYmVlbiBjYWxs
ZWQgb24gdGhlIGFvLgo+ICsgKgo+ICsgKiAtIE5vdGUgdGhhdCBkdXJpbmcgY2FsbGJhY2sgZnVu
Y3Rpb25zLCB0d28gZ2NzIGFyZSBhdmFpbGFibGU6Cj4gKyAqIMKgIMKgLSBUaGUgb25lIGluIGVn
Yywgd2hvc2UgbGlmZXRpbWUgaXMgb25seSB0aGlzIGNhbGxiYWNrCj4gKyAqIMKgIMKgLSBUaGUg
b25lIGluIGFvLCB3aG9zZSBsaWZldGltZSBpcyB0aGUgYXN5bmNocm9ub3VzIG9wZXJhdGlvbgo+
ICsgKiDCoCBVc3VhbGx5IGNhbGxiYWNrIGZ1bmN0aW9uIHNob3VsZCB1c2UgQ09OVEFJTkVSX09G
Cj4gKyAqIMKgIHRvIG9idGFpbiBpdHMgb3duIHN0cnVjdHVyZSwgY29udGFpbmluZyBhIHBvaW50
ZXIgdG8gdGhlIGFvLAo+ICsgKiDCoCBhbmQgdGhlbiB1c2UgdGhlIGdjIGZyb20gdGhhdCBhby4K
PiArICovCj4gKwo+ICsjZGVmaW5lIEFPX0NSRUFURShjdHgsIGRvbWlkLCBhb19ob3cpIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFwKPiArIMKgIMKgbGlieGxfX2N0eF9s
b2NrKGN0eCk7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIFwKPiArIMKgIMKgbGlieGxfX2FvICphbyA9IGxpYnhsX19hb19jcmVhdGUoY3R4
LCBkb21pZCwgYW9faG93KTsgwqAgwqAgwqAgXAo+ICsgwqAgwqBpZiAoIWFvKSB7IGxpYnhsX19j
dHhfdW5sb2NrKGN0eCk7IHJldHVybiBFUlJPUl9OT01FTTsgfSDCoCDCoFwKPiArIMKgIMKgQU9f
R0M7Cj4gKwo+ICsjZGVmaW5lIEFPX0lOUFJPR1JFU1MgKHsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBcCj4gKyDCoCDCoCDCoCDCoGxp
YnhsX2N0eCAqYW9fX2N0eCA9IGxpYnhsX19nY19vd25lcigmYW8tPmdjKTsgwqAgwqAgwqAgwqAg
wqBcCj4gKyDCoCDCoCDCoCDCoGludCBhb19fcmMgPSBsaWJ4bF9fYW9faW5wcm9ncmVzcyhhbyk7
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgXAo+ICsgwqAgwqAgwqAgwqBsaWJ4bF9fY3R4X3Vu
bG9jayhhb19fY3R4KTsgLyogZ2MgaXMgbm93IGludmFsaWQgKi8gwqAgwqAgXAo+ICsgwqAgwqAg
wqAgwqAoYW9fX3JjKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+ICsgwqAgfSkKPiArCj4gKyNkZWZpbmUgQU9f
QUJPUlQocmMpICh7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIFwKPiArIMKgIMKgIMKgIMKgbGlieGxfY3R4ICphb19fY3R4ID0gbGli
eGxfX2djX293bmVyKCZhby0+Z2MpOyDCoCDCoCDCoCDCoCDCoFwKPiArIMKgIMKgIMKgIMKgYXNz
ZXJ0KHJjKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgXAo+ICsgwqAgwqAgwqAgwqBsaWJ4bF9fYW9fYWJvcnQoYW8pOyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFwKPiAr
IMKgIMKgIMKgIMKgbGlieGxfX2N0eF91bmxvY2soYW9fX2N0eCk7IC8qIGdjIGlzIG5vdyBpbnZh
bGlkICovIMKgIMKgIFwKPiArIMKgIMKgIMKgIMKgKHJjKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+
ICsgwqAgwqB9KQo+ICsKPiArI2RlZmluZSBBT19HQyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBcCj4gKyDCoCDCoGxpYnhsX19nYyAqY29uc3QgZ2Mg
PSAmYW8tPmdjCj4gKwo+ICsKPiArLyogQWxsIG9mIHRoZXNlIE1VU1QgYmUgY2FsbGVkIHdpdGgg
dGhlIGN0eCBsb2NrZWQuCj4gKyAqIGxpYnhsX19hb19pbnByb2dyZXNzIE1VU1QgYmUgY2FsbGVk
IHdpdGggdGhlIGN0eCBsb2NrZWQgZXhhY3RseSBvbmNlLiAqLwo+ICtfaGlkZGVuIGxpYnhsX19h
byAqbGlieGxfX2FvX2NyZWF0ZShsaWJ4bF9jdHgqLCB1aW50MzJfdCBkb21pZCwKPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29uc3QgbGli
eGxfYXN5bmNvcF9ob3cqKTsKPiArX2hpZGRlbiBpbnQgbGlieGxfX2FvX2lucHJvZ3Jlc3MobGli
eGxfX2FvICphbyk7Cj4gK19oaWRkZW4gdm9pZCBsaWJ4bF9fYW9fYWJvcnQobGlieGxfX2FvICph
byk7Cj4gK19oaWRkZW4gdm9pZCBsaWJ4bF9fYW9fY29tcGxldGUobGlieGxfX2VnYyAqZWdjLCBs
aWJ4bF9fYW8gKmFvLCBpbnQgcmMpOwo+ICsKPiArLyogRm9yIHVzZSBieSBhbyBtYWNoaW5lcnkg
T05MWSAqLwo+ICtfaGlkZGVuIHZvaWQgbGlieGxfX2FvX19kZXN0cm95KGxpYnhsX2N0eCosIGxp
YnhsX19hbyAqYW8pOwo+ICsKPiArLyoKPiDCoCogQ29udmVuaWVuY2UgbWFjcm9zLgo+IMKgKi8K
Pgo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwgYi90b29scy9saWJ4
bC9saWJ4bF90eXBlcy5pZGwKPiBpbmRleCAzNWI1M2Q2Li44ODcxYzE3IDEwMDY0NAo+IC0tLSBh
L3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5
cGVzLmlkbAo+IEBAIC0zOTUsNiArMzk1LDcgQEAgbGlieGxfZXZlbnRfdHlwZSA9IEVudW1lcmF0
aW9uKCJldmVudF90eXBlIiwgWwo+IMKgIMKgICgxLCAiRE9NQUlOX1NIVVRET1dOIiksCj4gwqAg
wqAgKDIsICJET01BSU5fREVTVFJPWSIpLAo+IMKgIMKgICgzLCAiRElTS19FSkVDVCIpLAo+ICsg
wqAgwqAoNCwgIk9QRVJBVElPTl9DT01QTEVURSIpLAo+IMKgIMKgIF0pCj4KPiDCoGxpYnhsX2V2
X3VzZXIgPSBVSW50KDY0KQo+IEBAIC00MTgsNCArNDE5LDcgQEAgbGlieGxfZXZlbnQgPSBTdHJ1
Y3QoImV2ZW50IixbCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgKCJ2ZGV2Iiwgc3RyaW5nKSwKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoImRpc2siLCBsaWJ4bF9k
ZXZpY2VfZGlzayksCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBdKSksCj4gKyDCoCDCoCDCoCDCoCDCoCAoIm9wZXJhdGlvbl9jb21wbGV0ZSIsIFN0
cnVjdChOb25lLCBbCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCgicmMiLCBpbnRlZ2VyKSwKPiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIF0pKSwKPiDCoCDCoCDCoCDCoCDCoCDCoF0p
KV0pCj4gLS0KPiAxLjcuMi41Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:25:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxdvY-0003Ym-5F; Wed, 15 Feb 2012 12:25:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxdvW-0003YM-DN
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:25:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329308730!11570983!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4081 invoked from network); 15 Feb 2012 12:25:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:25:31 -0000
Received: by wibhm2 with SMTP id hm2so1353353wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 04:25:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=BBsqaqHWO1BDzd6qW1WcAKVwiT5rKDEi7R7RjuinnbU=;
	b=ncxAvndWThsgB0wE1BHXexxyMcW5fFyeCDYVQsMnrXgJr2X00DCY+LYx6S6AYBPbN7
	8vI700FuO4cMwu9qBKgMeRLWsVvj5vdt6vAazWwH20JsAscvGfDLtyWa1Y6gGV0LyhB3
	zXcAZ+13KFy2Zj6Z+o0jzQ95DL9ZZVdgmo5rY=
MIME-Version: 1.0
Received: by 10.180.101.228 with SMTP id fj4mr8159623wib.4.1329308730374; Wed,
	15 Feb 2012 04:25:30 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 15 Feb 2012 04:25:30 -0800 (PST)
In-Reply-To: <1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 13:25:30 +0100
X-Google-Sender-Auth: ISLndlvRXLiAzZsrd3E_I9g9yb0
Message-ID: <CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI2IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPjoKPiBQcm92
aWRlIGEgbmV3IHNldCBvZiBtYWNoaW5lcnkgZm9yIHdyaXRpbmcgcHVibGljIGxpYnhsIGZ1bmN0
aW9ucwo+IHdoaWNoIG1heSB0YWtlIGEgbG9uZyB0aW1lLiDCoFRoZSBhcHBsaWNhdGlvbiBnZXRz
IHRvIGRlY2lkZSB3aGV0aGVyCj4gdGhleSB3YW50IHRoZSBmdW5jdGlvbiB0byBiZSBzeW5jaHJv
bm91cywgb3Igd2hldGhlciB0aGV5J2QgcHJlZmVyIHRvCj4gZ2V0IGEgY2FsbGJhY2ssIG9yIGFu
IGV2ZW50LCB3aGVuIHRoZSBvcGVyYXRpb24gaXMgY29tcGxldGUuCj4KPiBVc2VyKHMpIG9mIHRo
aXMgbWFjaGluZXJ5IHdpbGwgYmUgaW50cm9kdWNlZCBpbiBsYXRlciBwYXRjaChlcykuCj4KPiBT
aWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPiAt
LS0KPiDCoHRvb2xzL2xpYnhsL2xpYnhsLmggwqAgwqAgwqAgwqAgwqB8IMKgIDUzICsrKysrKysr
KysrKwo+IMKgdG9vbHMvbGlieGwvbGlieGxfZXZlbnQuYyDCoCDCoHwgwqAxODggKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gwqB0b29scy9saWJ4bC9saWJ4bF9p
bnRlcm5hbC5oIHwgwqAxMDcgKysrKysrKysrKysrKysrKysrKysrKysrCj4gwqB0b29scy9saWJ4
bC9saWJ4bF90eXBlcy5pZGwgwqB8IMKgIMKgNCArCj4gwqA0IGZpbGVzIGNoYW5nZWQsIDM1MiBp
bnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhs
L2xpYnhsLmggYi90b29scy9saWJ4bC9saWJ4bC5oCj4gaW5kZXggZTMyODgxYi4uZmE3OWMyNCAx
MDA2NDQKPiAtLS0gYS90b29scy9saWJ4bC9saWJ4bC5oCj4gKysrIGIvdG9vbHMvbGlieGwvbGli
eGwuaAo+IEBAIC0yMzcsNiArMjM3LDU5IEBAIGVudW0gewo+IMKgIMKgIEVSUk9SX0JVRkZFUkZV
TEwgPSAtMTMsCj4gwqB9Owo+Cj4gKwo+ICsvKgo+ICsgKiBTb21lIGxpYnhsIG9wZXJhdGlvbnMg
Y2FuIHRha2UgYSBsb25nIHRpbWUuIMKgVGhlc2UgZnVuY3Rpb25zIHRha2UgYQo+ICsgKiBwYXJh
bWV0ZXIgdG8gY29udHJvbCB0aGVpciBjb25jdXJyZW5jeToKPiArICogwqAgwqAgbGlieGxfYXN5
bmNvcF9ob3cgKmFvX2hvdwo+ICsgKgo+ICsgKiBJZiBhb19ob3c9PU5VTEwsIHRoZSBmdW5jdGlv
biB3aWxsIGJlIHN5bmNocm9ub3VzLgo+ICsgKgo+ICsgKiBJZiBhb19ob3chPU5VTEwsIHRoZSBm
dW5jdGlvbiB3aWxsIHNldCB0aGUgb3BlcmF0aW9uIGdvaW5nLCBhbmQgaWYKPiArICogdGhpcyBp
cyBzdWNjZXNzZnVsIHdpbGwgcmV0dXJuIDAuIMKgSW4gdGhpcyBjYXNlIHRoZSB6ZXJvIGVycm9y
Cj4gKyAqIHJlc3BvbnNlIGRvZXMgTk9UIG1lYW4gdGhhdCB0aGUgb3BlcmF0aW9uIHdhcyBzdWNj
ZXNzZnVsOyBpdCBqdXN0Cj4gKyAqIG1lYW5zIHRoYXQgaXQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5
IHN0YXJ0ZWQuIMKgSXQgd2lsbCBmaW5pc2ggbGF0ZXIsCj4gKyAqIHBlcmhhcHMgd2l0aCBhbiBl
cnJvci4KPiArICoKPiArICogSWYgYW9faG93LT5jYWxsYmFjayE9TlVMTCwgdGhlIGNhbGxiYWNr
IHdpbGwgYmUgY2FsbGVkIHdoZW4gdGhlCj4gKyAqIG9wZXJhdGlvbiBjb21wbGV0ZXMuIMKgVGhl
IHNhbWUgcnVsZXMgYXMgZm9yIGxpYnhsX2V2ZW50X2hvb2tzCj4gKyAqIGFwcGx5LCBpbmNsdWRp
bmcgdGhlIHJlZW50cmFuY3kgcnVsZXMgYW5kIHRoZSBwb3NzaWJpbGl0eSBvZgo+ICsgKiAiZGlz
YXN0ZXIiLCBleGNlcHQgdGhhdCBsaWJ4bCBjYWxscyBhb19ob3ctPmNhbGxiYWNrIGluc3RlYWQg
b2YKPiArICogbGlieGxfZXZlbnRfaG9va3MuZXZlbnRfb2NjdXJzLiDCoChTZWUgbGlieGxfZXZl
bnQuaC4pCj4gKyAqCj4gKyAqIElmIGFvX2hvdy0+Y2FsbGJhY2s9PU5VTEwsIGEgbGlieGxfZXZl
bnQgd2lsbCBiZSBnZW5lcmF0ZWQgd2hpY2gKPiArICogY2FuIGJlIG9idGFpbmVkIGZyb20gbGli
eGxfZXZlbnRfd2FpdCBvciBsaWJ4bF9ldmVudF9jaGVjay4gwqBUaGUKPiArICogZXZlbnQgd2ls
bCBoYXZlIHR5cGUgT1BFUkFUSU9OX0NPTVBMRVRFICh3aGljaCBpcyBub3QgdXNlZAo+ICsgKiBl
bHNld2hlcmUpLgo+ICsgKgo+ICsgKiBOb3RlIHRoYXQgaXQgaXMgcG9zc2libGUgZm9yIGFuIGFz
eW5jaHJvbm91cyBvcGVyYXRpb24gd2hpY2ggaXMgdG8KPiArICogcmVzdWx0IGluIGEgY2FsbGJh
Y2sgdG8gY29tcGxldGUgZHVyaW5nIGl0cyBpbml0aWF0aW5nIGZ1bmN0aW9uCj4gKyAqIGNhbGwu
IMKgSW4gdGhpcyBjYXNlIHRoZSBpbml0aWF0aW5nIGZ1bmN0aW9uIHdpbGwgcmV0dXJuIDAKPiAr
ICogaW5kaWNhdGluZyB0aGUgYXQgdGhlIG9wZXJhdGlvbiBpcyAiaW4gcHJvZ3Jlc3MiLCBldmVu
IHRob3VnaCBieQo+ICsgKiB0aGUgdGltZSBpdCByZXR1cm5zIHRoZSBvcGVyYXRpb24gaXMgY29t
cGxldGUgYW5kIHRoZSBjYWxsYmFjayBoYXMKPiArICogYWxyZWFkeSBoYXBwZW5lZC4KPiArICoK
PiArICogVGhlIGFwcGxpY2F0aW9uIG11c3Qgc2V0IGFuZCB1c2UgYW9faG93LT5mb3JfZXZlbnQg
KHdoaWNoIHdpbGwgYmUKPiArICogY29waWVkIGludG8gbGlieGxfZXZlbnQuZm9yX3VzZXIpIG9y
IGFvX2hvdy0+Zm9yX2NhbGxiYWNrIChwYXNzZWQKPiArICogdG8gdGhlIGNhbGxiYWNrKSB0byBk
ZXRlcm1pbmUgd2hpY2ggb3BlcmF0aW9uIGZpbmlzaGVkLCBhbmQgaXQgbXVzdAo+ICsgKiBvZiBj
b3Vyc2UgY2hlY2sgdGhlIHJjIHZhbHVlIGZvciBlcnJvcnMuCj4gKyAqCj4gKyAqICphb19ob3cg
ZG9lcyBub3QgbmVlZCB0byByZW1haW4gdmFsaWQgYWZ0ZXIgdGhlIGluaXRpYXRpbmcgZnVuY3Rp
b24KPiArICogcmV0dXJucy4KPiArICoKPiArICogQ2FsbGJhY2tzIG1heSBvY2N1ciBvbiBhbnkg
dGhyZWFkIGluIHdoaWNoIHRoZSBhcHBsaWNhdGlvbiBjYWxscwo+ICsgKiBsaWJ4bC4KPiArICov
Cj4gKwo+ICt0eXBlZGVmIHN0cnVjdCB7Cj4gKyDCoCDCoHZvaWQgKCpjYWxsYmFjaykobGlieGxf
Y3R4ICpjdHgsIGludCByYywgdm9pZCAqZm9yX2NhbGxiYWNrKTsKPiArIMKgIMKgdW5pb24gewo+
ICsgwqAgwqAgwqAgwqBsaWJ4bF9ldl91c2VyIGZvcl9ldmVudDsgLyogdXNlZCBpZiBjYWxsYmFj
az09TlVMTCAqLwo+ICsgwqAgwqAgwqAgwqB2b2lkICpmb3JfY2FsbGJhY2s7IC8qIHBhc3NlZCB0
byBjYWxsYmFjayAqLwo+ICsgwqAgwqB9IHU7Cj4gK30gbGlieGxfYXN5bmNvcF9ob3c7Cj4gKwo+
ICsKPiDCoCNkZWZpbmUgTElCWExfVkVSU0lPTiAwCj4KPiDCoHR5cGVkZWYgc3RydWN0IHsKPiBk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZXZlbnQuYyBiL3Rvb2xzL2xpYnhsL2xpYnhs
X2V2ZW50LmMKPiBpbmRleCA3M2RmZDlkLi45ZTFhYjU2IDEwMDY0NAo+IC0tLSBhL3Rvb2xzL2xp
YnhsL2xpYnhsX2V2ZW50LmMKPiArKysgYi90b29scy9saWJ4bC9saWJ4bF9ldmVudC5jCj4gQEAg
LTc3MSwxMCArNzcxLDIxIEBAIHN0YXRpYyB2b2lkIGVnY19ydW5fY2FsbGJhY2tzKGxpYnhsX19l
Z2MgKmVnYykKPiDCoHsKPiDCoCDCoCBFR0NfR0M7Cj4gwqAgwqAgbGlieGxfZXZlbnQgKmV2LCAq
ZXZfdG1wOwo+ICsKPiDCoCDCoCBMSUJYTF9UQUlMUV9GT1JFQUNIX1NBRkUoZXYsICZlZ2MtPm9j
Y3VycmVkX2Zvcl9jYWxsYmFjaywgbGluaywgZXZfdG1wKSB7Cj4gwqAgwqAgwqAgwqAgTElCWExf
VEFJTFFfUkVNT1ZFKCZlZ2MtPm9jY3VycmVkX2Zvcl9jYWxsYmFjaywgZXYsIGxpbmspOwo+IMKg
IMKgIMKgIMKgIENUWC0+ZXZlbnRfaG9va3MtPmV2ZW50X29jY3VycyhDVFgtPmV2ZW50X2hvb2tz
X3VzZXIsIGV2KTsKPiDCoCDCoCB9Cj4gKwo+ICsgwqAgwqBsaWJ4bF9fYW8gKmFvLCAqYW9fdG1w
Owo+ICsgwqAgwqBMSUJYTF9UQUlMUV9GT1JFQUNIX1NBRkUoYW8sICZlZ2MtPmFvc19mb3JfY2Fs
bGJhY2ssCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbnRy
eV9mb3JfY2FsbGJhY2ssIGFvX3RtcCkgewo+ICsgwqAgwqAgwqAgwqBMSUJYTF9UQUlMUV9SRU1P
VkUoJmVnYy0+YW9zX2Zvcl9jYWxsYmFjaywgYW8sIGVudHJ5X2Zvcl9jYWxsYmFjayk7Cj4gKyDC
oCDCoCDCoCDCoGFvLT5ob3cuY2FsbGJhY2soQ1RYLCBhby0+cmMsIGFvLT5ob3cudS5mb3JfY2Fs
bGJhY2spOwo+ICsgwqAgwqAgwqAgwqBhby0+bm90aWZpZWQgPSAxOwo+ICsgwqAgwqAgwqAgwqBp
ZiAoIWFvLT5pbl9pbml0aWF0b3IpCj4gKyDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19hb19fZGVz
dHJveShDVFgsIGFvKTsKPiArIMKgIMKgfQo+IMKgfQo+Cj4gwqB2b2lkIGxpYnhsX19lZ2NfY2xl
YW51cChsaWJ4bF9fZWdjICplZ2MpCj4gQEAgLTEwNjEsNiArMTA3MiwxODMgQEAgaW50IGxpYnhs
X2V2ZW50X3dhaXQobGlieGxfY3R4ICpjdHgsIGxpYnhsX2V2ZW50ICoqZXZlbnRfciwKPiDCoCDC
oCByZXR1cm4gcmM7Cj4gwqB9Cj4KPiArCj4gKwo+ICsvKgo+ICsgKiBUaGUgdHdvIHBvc3NpYmxl
IHN0YXRlIGZsb3cgb2YgYW4gYW86Cj4gKyAqCj4gKyAqIENvbXBsZXRpb24gYmVmb3JlIGluaXRp
YXRvciByZXR1cm46Cj4gKyAqCj4gKyAqIMKgIMKgIEluaXRpYXRvciB0aHJlYWQgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUG9zc2libGUgb3RoZXIgdGhyZWFkcwo+ICsgKgo+ICsg
KiDCoCAqIGFvX2NyZWF0ZSBhbGxvY2F0ZXMgbWVtb3J5IGFuZAo+ICsgKiDCoCDCoCBpbml0aWFs
aXNlcyB0aGUgc3RydWN0Cj4gKyAqCj4gKyAqIMKgICogdGhlIGluaXRpYXRvciBmdW5jdGlvbiBk
b2VzIGl0cwo+ICsgKiDCoCDCoCB3b3JrLCBzZXR0aW5nIHVwIHZhcmlvdXMgaW50ZXJuYWwKPiAr
ICogwqAgwqAgYXN5bmNocm9ub3VzIG9wZXJhdGlvbnMgLS0tLS0tLS0tLS0+ICogYXN5bmNocm9u
b3VzIG9wZXJhdGlvbnMKPiArICogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdGFydCB0byB0YWtlIHBsYWNlIGFuZAo+ICsg
KiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoG1pZ2h0IGNhdXNlIGFvIGNvbXBsZXRpb24KPiArICogwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8
Cj4gKyAqIMKgICogaW5pdGlhdG9yIGNhbGxzIGFvX2lucHJvZ3Jlc3MgwqAgwqAgwqAgwqAgwqAg
wqAgwqB8Cj4gKyAqIMKgIMKgIC0gaWYgc3luY2hyb25vdXMsIHJ1biBldmVudCBsb29wIMKgIMKg
IMKgIMKgIMKgIHwKPiArICogwqAgwqAgwqAgdW50aWwgdGhlIGFvIGNvbXBsZXRlcyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCB8Cj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgLSBhbyBjb21wbGV0ZXMgb24gc29tZSB0aHJlYWQKPiArICogwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtIGNvbXBsZXRpbmcgdGhyZWFk
IHJlbGVhc2VzIHRoZSBsb2NrCj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDwt
LS0tLS0tLS0tLS0tLScKPiArICogwqAgwqAgLSBhb19pbnByb2dyZXNzIHRha2VzIHRoZSBsb2Nr
Cj4gKyAqIMKgIMKgIC0gZGVzdHJveSB0aGUgYW8KPiArICoKPiArICoKPiArICogQ29tcGxldGlv
biBhZnRlciBpbml0aWF0b3IgcmV0dXJuIChhc3luY2guIG9ubHkpOgo+ICsgKgo+ICsgKgo+ICsg
KiDCoCDCoCBJbml0aWF0b3IgdGhyZWFkIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IFBvc3NpYmxlIG90aGVyIHRocmVhZHMKPiArICoKPiArICogwqAgKiBhb19jcmVhdGUgYWxsb2Nh
dGVzIG1lbW9yeSBhbmQKPiArICogwqAgwqAgaW5pdGlhbGlzZXMgdGhlIHN0cnVjdAo+ICsgKgo+
ICsgKiDCoCAqIHRoZSBpbml0aWF0b3IgZnVuY3Rpb24gZG9lcyBpdHMKPiArICogwqAgwqAgd29y
aywgc2V0dGluZyB1cCB2YXJpb3VzIGludGVybmFsCj4gKyAqIMKgIMKgIGFzeW5jaHJvbm91cyBv
cGVyYXRpb25zIC0tLS0tLS0tLS0tPiAqIGFzeW5jaHJvbm91cyBvcGVyYXRpb25zCj4gKyAqIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgc3RhcnQgdG8gdGFrZSBwbGFjZSBhbmQKPiArICogwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtaWdodCBjYXVzZSBh
byBjb21wbGV0aW9uCj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfAo+ICsgKiDCoCAqIGluaXRpYXRvciBj
YWxscyBhb19pbnByb2dyZXNzIMKgIMKgIMKgIMKgIMKgIMKgIMKgfAo+ICsgKiDCoCDCoCAtIG9i
c2VydmVzIGV2ZW50IG5vdCB5ZXQgZG9uZSwgwqAgwqAgwqAgwqAgwqAgwqAgfAo+ICsgKiDCoCDC
oCAtIHJldHVybnMgdG8gY2FsbGVyIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
fAo+ICsgKiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwKPiArICogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAtIGFvIGNvbXBsZXRlcyBvbiBzb21lIHRocmVhZAo+ICsgKiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0gZ2VuZXJhdGUgdGhlIGV2
ZW50IG9yIGNhbGwgdGhlIGNhbGxiYWNrCj4gKyAqIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgLSBkZXN0cm95IHRoZSBhbwo+ICsgKi8KPiArCj4gK3ZvaWQgbGli
eGxfX2FvX19kZXN0cm95KGxpYnhsX2N0eCAqY3R4LCBsaWJ4bF9fYW8gKmFvKQo+ICt7Cj4gKyDC
oCDCoGlmICghYW8pIHJldHVybjsKPiArIMKgIMKgaWYgKGFvLT5wb2xsZXIpIGxpYnhsX19wb2xs
ZXJfcHV0KGN0eCwgYW8tPnBvbGxlcik7Cj4gKyDCoCDCoGFvLT5tYWdpYyA9IExJQlhMX19BT19N
QUdJQ19ERVNUUk9ZRUQ7Cj4gKyDCoCDCoGxpYnhsX19mcmVlX2FsbCgmYW8tPmdjKTsKPiArIMKg
IMKgZnJlZShhbyk7Cj4gK30KPiArCj4gK3ZvaWQgbGlieGxfX2FvX2Fib3J0KGxpYnhsX19hbyAq
YW8pCj4gK3sKPiArIMKgIMKgQU9fR0M7Cj4gKyDCoCDCoGFzc2VydChhby0+bWFnaWMgPT0gTElC
WExfX0FPX01BR0lDKTsKPiArIMKgIMKgYXNzZXJ0KGFvLT5pbl9pbml0aWF0b3IpOwo+ICsgwqAg
wqBhc3NlcnQoIWFvLT5jb21wbGV0ZSk7Cj4gKyDCoCDCoGxpYnhsX19hb19fZGVzdHJveShDVFgs
IGFvKTsKPiArfQo+ICsKPiArdm9pZCBsaWJ4bF9fYW9fY29tcGxldGUobGlieGxfX2VnYyAqZWdj
LCBsaWJ4bF9fYW8gKmFvLCBpbnQgcmMpCj4gK3sKPiArIMKgIMKgYXNzZXJ0KGFvLT5tYWdpYyA9
PSBMSUJYTF9fQU9fTUFHSUMpOwo+ICsgwqAgwqBhc3NlcnQoIWFvLT5jb21wbGV0ZSk7Cj4gKyDC
oCDCoGFvLT5jb21wbGV0ZSA9IDE7Cj4gKyDCoCDCoGFvLT5yYyA9IHJjOwo+ICsKPiArIMKgIMKg
aWYgKGFvLT5wb2xsZXIpIHsKPiArIMKgIMKgIMKgIMKgYXNzZXJ0KGFvLT5pbl9pbml0aWF0b3Ip
Owo+ICsgwqAgwqAgwqAgwqBsaWJ4bF9fcG9sbGVyX3dha2V1cChlZ2MsIGFvLT5wb2xsZXIpOwo+
ICsgwqAgwqB9IGVsc2UgaWYgKGFvLT5ob3cuY2FsbGJhY2spIHsKPiArIMKgIMKgIMKgIMKgTElC
WExfVEFJTFFfSU5TRVJUX1RBSUwoJmVnYy0+YW9zX2Zvcl9jYWxsYmFjaywgYW8sIGVudHJ5X2Zv
cl9jYWxsYmFjayk7Cj4gKyDCoCDCoH0gZWxzZSB7Cj4gKyDCoCDCoCDCoCDCoGxpYnhsX2V2ZW50
ICpldjsKPiArIMKgIMKgIMKgIMKgZXYgPSBORVdfRVZFTlQoZWdjLCBPUEVSQVRJT05fQ09NUExF
VEUsIGFvLT5kb21pZCk7Cj4gKyDCoCDCoCDCoCDCoGlmIChldikgewo+ICsgwqAgwqAgwqAgwqAg
wqAgwqBldi0+Zm9yX3VzZXIgPSBhby0+aG93LnUuZm9yX2V2ZW50Owo+ICsgwqAgwqAgwqAgwqAg
wqAgwqBldi0+dS5vcGVyYXRpb25fY29tcGxldGUucmMgPSBhby0+cmM7Cj4gKyDCoCDCoCDCoCDC
oCDCoCDCoGxpYnhsX19ldmVudF9vY2N1cnJlZChlZ2MsIGV2KTsKPiArIMKgIMKgIMKgIMKgfQo+
ICsgwqAgwqAgwqAgwqBhby0+bm90aWZpZWQgPSAxOwo+ICsgwqAgwqB9Cj4gKyDCoCDCoGlmICgh
YW8tPmluX2luaXRpYXRvciAmJiBhby0+bm90aWZpZWQpCj4gKyDCoCDCoCDCoCDCoGxpYnhsX19h
b19fZGVzdHJveShsaWJ4bF9fZ2Nfb3duZXIoJmVnYy0+Z2MpLCBhbyk7Cj4gK30KPiArCj4gK2xp
YnhsX19hbyAqbGlieGxfX2FvX2NyZWF0ZShsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQs
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbnN0IGxpYnhs
X2FzeW5jb3BfaG93ICpob3cpCj4gK3sKPiArIMKgIMKgbGlieGxfX2FvICphbzsKPiArCj4gKyDC
oCDCoGFvID0gY2FsbG9jKDEsIHNpemVvZigqYW8pKTsKPiArIMKgIMKgaWYgKCFhbykgZ290byBv
dXQ7Cj4gKwo+ICsgwqAgwqBhby0+bWFnaWMgPSBMSUJYTF9fQU9fTUFHSUM7Cj4gKyDCoCDCoGFv
LT5pbl9pbml0aWF0b3IgPSAxOwo+ICsgwqAgwqBhby0+cG9sbGVyID0gMDsKPiArIMKgIMKgYW8t
PmRvbWlkID0gZG9taWQ7Cj4gKyDCoCDCoExJQlhMX0lOSVRfR0MoYW8tPmdjLCBjdHgpOwo+ICsK
PiArIMKgIMKgaWYgKGhvdykgewo+ICsgwqAgwqAgwqAgwqBhby0+aG93ID0gKmhvdzsKPiArIMKg
IMKgfSBlbHNlIHsKPiArIMKgIMKgIMKgIMKgYW8tPnBvbGxlciA9IGxpYnhsX19wb2xsZXJfZ2V0
KGN0eCk7Cj4gKyDCoCDCoCDCoCDCoGlmICghYW8tPnBvbGxlcikgZ290byBvdXQ7Cj4gKyDCoCDC
oH0KPiArIMKgIMKgcmV0dXJuIGFvOwo+ICsKPiArIG91dDoKPiArIMKgIMKgaWYgKGFvKSBsaWJ4
bF9fYW9fX2Rlc3Ryb3koY3R4LCBhbyk7Cj4gKyDCoCDCoHJldHVybiBOVUxMOwo+ICt9Cj4gKwo+
ICtpbnQgbGlieGxfX2FvX2lucHJvZ3Jlc3MobGlieGxfX2FvICphbykKPiArewo+ICsgwqAgwqBB
T19HQzsKPiArIMKgIMKgaW50IHJjOwoKSSd2ZSBqdXN0IHN0YXJ0ZWQgcGxheWluZyB3aXRoIHRo
aXMsIGJ1dCBJJ3ZlIGZvdW5kIHRoYXQgaWYgeW91IGNhbGwKQU9fSU5QUk9HUkVTUyB3aXRob3V0
IGFkZGluZyBhbnkgZXZlbnQgaXQgYmxvY2tzIGZvcmV2ZXIsIGFuZCBJJ20gbm90CnN1cmUgaWYg
dGhhdCBpcyBhIGRlc2lnbiBkZWNpc2lvbiBvciBhIGJ1Zy4gQW55d2F5LCBzb21ldGltZXMgbGlr
ZSBpbgpsaWJ4bF9faW5pdGlhdGVfZGV2aWNlX3JlbW92ZSB5b3UgbWlnaHQgY2FsbCBBT19JTlBS
T0dSRVNTIHdpdGhvdXQKYWRkaW5nIGFueSBldmVudCwgc28gSSB0aGluayBpdCB3aWxsIGJlIHNh
ZmUgdG8gYWRkIHNvbWV0aGluZyBsaWtlOgoKaWYgKCFDVFgtPndhdGNoX2NvdW50ZXIpCiAgICBy
ZXR1cm4gMDsKClRvIHByZXZlbnQgd2FpdGluZyBmb3JldmVyLCBpZiBub3Qgd2UgbmVlZCB0byBi
ZSBzdXJlIHdlIG9ubHkgY2FsbApBT19JTlBST0dSRVNTIHdoZW4gd2UgaGF2ZSBhZGRlZCBzb21l
IGV2ZW50cyAod2hpY2ggaXMgbm90IGFzCnByYWN0aWNhbCBhcyB0aGlzIHNpbXBsZSBmaXgpLiBT
aW5jZSBJJ3ZlIGp1c3Qgc3RhcnRlZCBwbGF5aW5nIHdpdGgKdGhlIGV2ZW50cyBBUEksIEkgbWln
aHQgYmUgZG9pbmcgYW4gaW5jb3JyZWN0IHVzYWdlIG9mIHRoaXMsIGlmIHRoaXMKc291bmRzIG9r
IHBsZWFzZSBkcm9wIGEgbGluZSBhbmQgSSB3aWxsIHNlbmQgYSBmb3JtYWwgcGF0Y2guCgpUaGFu
a3MsIFJvZ2VyLgoKPiArCj4gKyDCoCDCoGFzc2VydChhby0+bWFnaWMgPT0gTElCWExfX0FPX01B
R0lDKTsKPiArIMKgIMKgYXNzZXJ0KGFvLT5pbl9pbml0aWF0b3IpOwo+ICsKPiArIMKgIMKgaWYg
KGFvLT5wb2xsZXIpIHsKPiArIMKgIMKgIMKgIMKgLyogQ2FsbGVyIHdhbnRzIGl0IGRvbmUgc3lu
Y2hyb25vdXNseS4gKi8KPiArIMKgIMKgIMKgIMKgLyogV2UgdXNlIGEgZnJlc2ggZ2MsIHNvIHRo
YXQgd2UgY2FuIGZyZWUgdGhpbmdzCj4gKyDCoCDCoCDCoCDCoCAqIGVhY2ggdGltZSByb3VuZCB0
aGUgbG9vcC4gKi8KPiArIMKgIMKgIMKgIMKgbGlieGxfX2VnYyBlZ2M7Cj4gKyDCoCDCoCDCoCDC
oExJQlhMX0lOSVRfRUdDKGVnYyxDVFgpOwo+ICsKPiArIMKgIMKgIMKgIMKgZm9yICg7Oykgewo+
ICsgwqAgwqAgwqAgwqAgwqAgwqBhc3NlcnQoYW8tPm1hZ2ljID09IExJQlhMX19BT19NQUdJQyk7
Cj4gKwo+ICsgwqAgwqAgwqAgwqAgwqAgwqBpZiAoYW8tPmNvbXBsZXRlKSB7Cj4gKyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoHJjID0gYW8tPnJjOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBh
by0+bm90aWZpZWQgPSAxOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBicmVhazsKPiArIMKg
IMKgIMKgIMKgIMKgIMKgfQo+ICsKPiArIMKgIMKgIMKgIMKgIMKgIMKgcmMgPSBldmVudGxvb3Bf
aXRlcmF0aW9uKCZlZ2MsYW8tPnBvbGxlcik7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoGlmIChyYykg
ewo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAvKiBPaCBkZWFyLCB0aGlzIGlzIHF1aXRlIHVu
Zm9ydHVuYXRlLiAqLwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBMSUJYTF9fTE9HKENUWCwg
TElCWExfX0xPR19FUlJPUiwgIkVycm9yIHdhaXRpbmcgZm9yIgo+ICsgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgIiBldmVudCBkdXJpbmcgbG9uZy1ydW5uaW5nIG9wZXJh
dGlvbiAocmM9JWQpIiwgcmMpOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzbGVlcCgxKTsK
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLyogSXQncyBlaXRoZXIgdGhpcyBvciByZXR1cm4g
RVJST1JfSV9ET05UX0tOT1dfV0hFVEhFUgo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBf
VEhFX1RISU5HX1lPVV9BU0tFRF9GT1JfV0lMTF9CRV9ET05FX0xBVEVSX1dIRU4KPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgICogX1lPVV9ESUROVF9FWFBFQ1RfSVQsIHNpbmNlIHdlIGRvbid0
IGhhdmUgYW55IGtpbmQgb2YKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogY2FuY2VsbGF0
aW9uIGFiaWxpdHkuICovCj4gKyDCoCDCoCDCoCDCoCDCoCDCoH0KPiArCj4gKyDCoCDCoCDCoCDC
oCDCoCDCoENUWF9VTkxPQ0s7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoGxpYnhsX19lZ2NfY2xlYW51
cCgmZWdjKTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgQ1RYX0xPQ0s7Cj4gKyDCoCDCoCDCoCDCoH0K
PiArIMKgIMKgfSBlbHNlIHsKPiArIMKgIMKgIMKgIMKgcmMgPSAwOwo+ICsgwqAgwqB9Cj4gKwo+
ICsgwqAgwqBhby0+aW5faW5pdGlhdG9yID0gMDsKPiArCj4gKyDCoCDCoGlmIChhby0+bm90aWZp
ZWQpIHsKPiArIMKgIMKgIMKgIMKgYXNzZXJ0KGFvLT5jb21wbGV0ZSk7Cj4gKyDCoCDCoCDCoCDC
oGxpYnhsX19hb19fZGVzdHJveShDVFgsYW8pOwo+ICsgwqAgwqB9Cj4gKwo+ICsgwqAgwqByZXR1
cm4gcmM7Cj4gK30KPiArCj4gKwo+IMKgLyoKPiDCoCogTG9jYWwgdmFyaWFibGVzOgo+IMKgKiBt
b2RlOiBDCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVybmFsLmggYi90b29s
cy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oCj4gaW5kZXggZDFiOTZjMS4uMDQ0ZWViNCAxMDA2NDQK
PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9pbnRlcm5hbC5oCj4gKysrIGIvdG9vbHMvbGlieGwv
bGlieGxfaW50ZXJuYWwuaAo+IEBAIC0xMTQsNiArMTE0LDcgQEAgX2hpZGRlbiB2b2lkIGxpYnhs
X19sb2cobGlieGxfY3R4ICpjdHgsIHhlbnRvb2xsb2dfbGV2ZWwgbXNnbGV2ZWwsIGludCBlcnJu
b3ZhbCwKPgo+IMKgdHlwZWRlZiBzdHJ1Y3QgbGlieGxfX2djIGxpYnhsX19nYzsKPiDCoHR5cGVk
ZWYgc3RydWN0IGxpYnhsX19lZ2MgbGlieGxfX2VnYzsKPiArdHlwZWRlZiBzdHJ1Y3QgbGlieGxf
X2FvIGxpYnhsX19hbzsKPgo+IMKgdHlwZWRlZiBzdHJ1Y3QgbGlieGxfX2V2X2ZkIGxpYnhsX19l
dl9mZDsKPiDCoHR5cGVkZWYgdm9pZCBsaWJ4bF9fZXZfZmRfY2FsbGJhY2sobGlieGxfX2VnYyAq
ZWdjLCBsaWJ4bF9fZXZfZmQgKmV2LAo+IEBAIC0yMTgsNiArMjE5LDEwIEBAIHN0cnVjdCBsaWJ4
bF9fcG9sbGVyIHsKPiDCoCDCoCDCoCogcmVsZWFzaW5nIHRoZSBjdHggbG9jayBhbmQgZ29pbmcg
aW50byBwb2xsOyB3aGVuIGl0IGNvbWVzIG91dAo+IMKgIMKgIMKgKiBvZiBwb2xsIGl0IHdpbGwg
dGFrZSB0aGUgcG9sbGVyIG9mZiB0aGUgcG9sbGVyc19ldmVudCBsaXN0Lgo+IMKgIMKgIMKgKgo+
ICsgwqAgwqAgKiBBIHRocmVhZCB3aGljaCBpcyB3YWl0aW5nIGZvciBjb21wbGV0aW9uIG9mIGEg
c3luY2hyb25vdXMgYW8KPiArIMKgIMKgICogd2lsbCBhbGxvY2F0ZSBhIHBvbGxlciBhbmQgcmVj
b3JkIGl0IGluIHRoZSBhbywgc28gdGhhdCBvdGhlcgo+ICsgwqAgwqAgKiB0aHJlYWRzIGNhbiB3
YWtlIGl0IHVwLgo+ICsgwqAgwqAgKgo+IMKgIMKgIMKgKiBXaGVuIGEgdGhyZWFkIGlzIGRvbmUg
d2l0aCBhIHBvbGxlciBpdCBzaG91bGQgcHV0IGl0IG9udG8KPiDCoCDCoCDCoCogcG9sbGVyc19p
ZGxlLCB3aGVyZSBpdCBjYW4gYmUgcmV1c2VkIGxhdGVyLgo+IMKgIMKgIMKgKgo+IEBAIC0zMjQs
NiArMzI5LDIxIEBAIHN0cnVjdCBsaWJ4bF9fZWdjIHsKPiDCoCDCoCAvKiBmb3IgZXZlbnQtZ2Vu
ZXJhdGluZyBmdW5jdGlvbnMgb25seSAqLwo+IMKgIMKgIHN0cnVjdCBsaWJ4bF9fZ2MgZ2M7Cj4g
wqAgwqAgc3RydWN0IGxpYnhsX19ldmVudF9saXN0IG9jY3VycmVkX2Zvcl9jYWxsYmFjazsKPiAr
IMKgIMKgTElCWExfVEFJTFFfSEVBRCgsIGxpYnhsX19hbykgYW9zX2Zvcl9jYWxsYmFjazsKPiAr
fTsKPiArCj4gKyNkZWZpbmUgTElCWExfX0FPX01BR0lDIMKgIMKgIMKgIMKgIMKgIMKgIMKgMHhB
MEZBQ0UwMHVsCj4gKyNkZWZpbmUgTElCWExfX0FPX01BR0lDX0RFU1RST1lFRCDCoCDCoDB4QTBE
RUFEMDB1bAo+ICsKPiArc3RydWN0IGxpYnhsX19hbyB7Cj4gKyDCoCDCoHVpbnQzMl90IG1hZ2lj
Owo+ICsgwqAgwqB1bnNpZ25lZCBpbl9pbml0aWF0b3I6MSwgY29tcGxldGU6MSwgbm90aWZpZWQ6
MTsKPiArIMKgIMKgaW50IHJjOwo+ICsgwqAgwqBsaWJ4bF9fZ2MgZ2M7Cj4gKyDCoCDCoGxpYnhs
X2FzeW5jb3BfaG93IGhvdzsKPiArIMKgIMKgbGlieGxfX3BvbGxlciAqcG9sbGVyOwo+ICsgwqAg
wqB1aW50MzJfdCBkb21pZDsKPiArIMKgIMKgTElCWExfVEFJTFFfRU5UUlkobGlieGxfX2FvKSBl
bnRyeV9mb3JfY2FsbGJhY2s7Cj4gwqB9Owo+Cj4gwqAjZGVmaW5lIExJQlhMX0lOSVRfR0MoZ2Ms
Y3R4KSBkb3sgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+IEBAIC0xMTA4LDYgKzExMjgsNyBAQCBs
aWJ4bF9fZGV2aWNlX21vZGVsX3ZlcnNpb25fcnVubmluZyhsaWJ4bF9fZ2MgKmdjLCB1aW50MzJf
dCBkb21pZCk7Cj4gwqAjZGVmaW5lIExJQlhMX0lOSVRfRUdDKGVnYyxjdHgpIGRveyDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBcCj4gwqAgwqAgwqAgwqAgTElCWExfSU5JVF9HQygoZWdj
KS5nYyxjdHgpOyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFwKPiDCoCDCoCDCoCDCoCBM
SUJYTF9UQUlMUV9JTklUKCYoZWdjKS5vY2N1cnJlZF9mb3JfY2FsbGJhY2spOyBcCj4gKyDCoCDC
oCDCoCDCoExJQlhMX1RBSUxRX0lOSVQoJihlZ2MpLmFvc19mb3JfY2FsbGJhY2spOyDCoCDCoCDC
oFwKPiDCoCDCoCB9IHdoaWxlKDApCj4KPiDCoF9oaWRkZW4gdm9pZCBsaWJ4bF9fZWdjX2NsZWFu
dXAobGlieGxfX2VnYyAqZWdjKTsKPiBAQCAtMTEyNSw2ICsxMTQ2LDkyIEBAIF9oaWRkZW4gdm9p
ZCBsaWJ4bF9fZWdjX2NsZWFudXAobGlieGxfX2VnYyAqZWdjKTsKPgo+Cj4gwqAvKgo+ICsgKiBN
YWNoaW5lcnkgZm9yIGFzeW5jaHJvbm91cyBvcGVyYXRpb25zICgiYW8iKQo+ICsgKgo+ICsgKiBB
bGwgInNsb3ciIGZ1bmN0aW9ucyAoaW5jbHVkZXMgYW55dGhpbmcgdGhhdCBtaWdodCBibG9jayBv
biBhCj4gKyAqIGd1ZXN0IG9yIGFuIGV4dGVybmFsIHNjcmlwdCkgbmVlZCB0byB1c2UgdGhlIGFz
eW5jaHJvbm91cwo+ICsgKiBvcGVyYXRpb24gKCJhbyIpIG1hY2hpbmVyeS4gwqBUaGUgZnVuY3Rp
b24gc2hvdWxkIHRha2UgYSBwYXJhbWV0ZXIKPiArICogY29uc3QgbGlieGxfYXN5bmNvcF9ob3cg
KmFvX2hvdyBhbmQgbXVzdCBzdGFydCB3aXRoIGEgY2FsbCB0bwo+ICsgKiBBT19JTklUSUFUT1Jf
RU5UUlkuIMKgVGhlc2UgZnVuY3Rpb25zIE1BWSBOT1QgYmUgY2FsbGVkIGZyb20KPiArICogb3V0
c2lkZSBsaWJ4bCwgYmVjYXVzZSB0aGV5IGNhbiBjYXVzZSByZWVudHJhbmN5IGNhbGxiYWNrcy4K
PiArICoKPiArICogTGlmZWN5Y2xlIG9mIGFuIGFvOgo+ICsgKgo+ICsgKiAtIENyZWF0ZWQgYnkg
bGlieGxfX2FvX2NyZWF0ZSAob3IgdGhlIEFPX0NSRUFURSBjb252ZW5pZW5jZSBtYWNybykuCj4g
KyAqCj4gKyAqIC0gQWZ0ZXIgY3JlYXRpb24sIGNhbiBiZSB1c2VkIGJ5IGNvZGUgd2hpY2ggaW1w
bGVtZW50cwo+ICsgKiDCoCB0aGUgb3BlcmF0aW9uIGFzIGZvbGxvd3M6Cj4gKyAqIMKgIMKgIMKg
LSB0aGUgYW8ncyBnYywgZm9yIGFsbG9jYXRpbmcgbWVtb3J5IGZvciB0aGUgbGlmZXRpbWUKPiAr
ICogwqAgwqAgwqAgwqBvZiB0aGUgb3BlcmF0aW9uIChwb3NzaWJseSB3aXRoIHRoZSBoZWxwIG9m
IHRoZSBBT19HQwo+ICsgKiDCoCDCoCDCoCDCoG1hY3JvIHRvIGludHJvZHVjZSB0aGUgZ2MgaW50
byBzY29wZSkKPiArICogwqAgwqAgwqAtIHRoZSBhbyBpdHNlbGYgbWF5IGJlIHBhc3NlZCBhYm91
dCB0byBzdWItZnVuY3Rpb25zCj4gKyAqIMKgIMKgIMKgIMKgc28gdGhhdCB0aGV5IGNhbiBzdGFz
aCBpdCBhd2F5IGV0Yy4KPiArICogwqAgwqAgwqAtIGluIHBhcnRpY3VsYXIsIHRoZSBhbyBwb2lu
dGVyIG11c3QgYmUgc3Rhc2hlZCBpbiBzb21lCj4gKyAqIMKgIMKgIMKgIMKgcGVyLW9wZXJhdGlv
biBzdHJ1Y3R1cmUgd2hpY2ggaXMgYWxzbyBwYXNzZWQgYXMgYSB1c2VyCj4gKyAqIMKgIMKgIMKg
IMKgcG9pbnRlciB0byB0aGUgaW50ZXJuYWwgZXZlbnQgZ2VuZXJhdGlvbiByZXF1ZXN0IHJvdXRp
bmVzCj4gKyAqIMKgIMKgIMKgIMKgbGlieGxfX2V2Z2VuX0ZPTywgc28gdGhhdCBhdCBzb21lIHBv
aW50IGEgQ0FMTEJBQ0sgd2lsbCBiZQo+ICsgKiDCoCDCoCDCoCDCoG1hZGUgd2hlbiB0aGUgb3Bl
cmF0aW9uIGlzIGNvbXBsZXRlLgo+ICsgKgo+ICsgKiAtIElmIGluaXRpYXRpb24gaXMgc3VjY2Vz
c2Z1bCwgdGhlIGluaXRpYXRpbmcgZnVuY3Rpb24gbmVlZHMKPiArICogwqAgdG8gcnVuIGxpYnhs
X19hb19pbnByb2dyZXNzIHJpZ2h0IGJlZm9yZSB1bmxvY2tpbmcgYW5kCj4gKyAqIMKgIHJldHVy
bmluZywgYW5kIHJldHVybiB3aGF0ZXZlciBpdCByZXR1cm5zIChBT19JTlBST0dSRVNTIG1hY3Jv
KS4KPiArICoKPiArICogLSBJZiB0aGUgaW5pdGlhdGlvbiBpcyB1bnN1Y2Nlc3NmdWwsIHRoZSBp
bml0aWF0aW5nIGZ1bmN0aW9uIG11c3QKPiArICogwqAgY2FsbCBsaWJ4bF9fYW9fYWJvcnQgYmVm
b3JlIHVubG9ja2luZyBhbmQgcmV0dXJuaW5nIHdoYXRldmVyCj4gKyAqIMKgIGVycm9yIGNvZGUg
aXMgYXBwcm9wcmlhdGUgKEFPX0FCT1JUIG1hY3JvKS4KPiArICoKPiArICogLSBMYXRlciwgc29t
ZSBjYWxsYmFjayBmdW5jdGlvbiwgd2hvc2UgY2FsbGJhY2sgaGFzIGJlZW4gcmVxdWVzdGVkCj4g
KyAqIMKgIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIHNob3VsZCBjYWxsIGxpYnhsX19hb19jb21w
bGV0ZSAod2l0aCB0aGUKPiArICogwqAgY3R4IGxvY2tlZCwgYXMgaXQgd2lsbCBnZW5lcmFsbHkg
YWxyZWFkeSBiZSBpbiBhbnkgZXZlbnQgY2FsbGJhY2sKPiArICogwqAgZnVuY3Rpb24pLiDCoFRo
aXMgbXVzdCBoYXBwZW4gZXhhY3RseSBvbmNlIGZvciBlYWNoIGFvIChhbmQgbm90IGlmCj4gKyAq
IMKgIHRoZSBhbyBoYXMgYmVlbiBkZXN0cm95ZWQsIG9idmlvdXNseSksIGFuZCBpdCBtYXkgbm90
IGhhcHBlbgo+ICsgKiDCoCB1bnRpbCBsaWJ4bF9fYW9faW5wcm9ncmVzcyBoYXMgYmVlbiBjYWxs
ZWQgb24gdGhlIGFvLgo+ICsgKgo+ICsgKiAtIE5vdGUgdGhhdCBkdXJpbmcgY2FsbGJhY2sgZnVu
Y3Rpb25zLCB0d28gZ2NzIGFyZSBhdmFpbGFibGU6Cj4gKyAqIMKgIMKgLSBUaGUgb25lIGluIGVn
Yywgd2hvc2UgbGlmZXRpbWUgaXMgb25seSB0aGlzIGNhbGxiYWNrCj4gKyAqIMKgIMKgLSBUaGUg
b25lIGluIGFvLCB3aG9zZSBsaWZldGltZSBpcyB0aGUgYXN5bmNocm9ub3VzIG9wZXJhdGlvbgo+
ICsgKiDCoCBVc3VhbGx5IGNhbGxiYWNrIGZ1bmN0aW9uIHNob3VsZCB1c2UgQ09OVEFJTkVSX09G
Cj4gKyAqIMKgIHRvIG9idGFpbiBpdHMgb3duIHN0cnVjdHVyZSwgY29udGFpbmluZyBhIHBvaW50
ZXIgdG8gdGhlIGFvLAo+ICsgKiDCoCBhbmQgdGhlbiB1c2UgdGhlIGdjIGZyb20gdGhhdCBhby4K
PiArICovCj4gKwo+ICsjZGVmaW5lIEFPX0NSRUFURShjdHgsIGRvbWlkLCBhb19ob3cpIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFwKPiArIMKgIMKgbGlieGxfX2N0eF9s
b2NrKGN0eCk7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIFwKPiArIMKgIMKgbGlieGxfX2FvICphbyA9IGxpYnhsX19hb19jcmVhdGUoY3R4
LCBkb21pZCwgYW9faG93KTsgwqAgwqAgwqAgXAo+ICsgwqAgwqBpZiAoIWFvKSB7IGxpYnhsX19j
dHhfdW5sb2NrKGN0eCk7IHJldHVybiBFUlJPUl9OT01FTTsgfSDCoCDCoFwKPiArIMKgIMKgQU9f
R0M7Cj4gKwo+ICsjZGVmaW5lIEFPX0lOUFJPR1JFU1MgKHsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBcCj4gKyDCoCDCoCDCoCDCoGxp
YnhsX2N0eCAqYW9fX2N0eCA9IGxpYnhsX19nY19vd25lcigmYW8tPmdjKTsgwqAgwqAgwqAgwqAg
wqBcCj4gKyDCoCDCoCDCoCDCoGludCBhb19fcmMgPSBsaWJ4bF9fYW9faW5wcm9ncmVzcyhhbyk7
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgXAo+ICsgwqAgwqAgwqAgwqBsaWJ4bF9fY3R4X3Vu
bG9jayhhb19fY3R4KTsgLyogZ2MgaXMgbm93IGludmFsaWQgKi8gwqAgwqAgXAo+ICsgwqAgwqAg
wqAgwqAoYW9fX3JjKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+ICsgwqAgfSkKPiArCj4gKyNkZWZpbmUgQU9f
QUJPUlQocmMpICh7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIFwKPiArIMKgIMKgIMKgIMKgbGlieGxfY3R4ICphb19fY3R4ID0gbGli
eGxfX2djX293bmVyKCZhby0+Z2MpOyDCoCDCoCDCoCDCoCDCoFwKPiArIMKgIMKgIMKgIMKgYXNz
ZXJ0KHJjKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgXAo+ICsgwqAgwqAgwqAgwqBsaWJ4bF9fYW9fYWJvcnQoYW8pOyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFwKPiAr
IMKgIMKgIMKgIMKgbGlieGxfX2N0eF91bmxvY2soYW9fX2N0eCk7IC8qIGdjIGlzIG5vdyBpbnZh
bGlkICovIMKgIMKgIFwKPiArIMKgIMKgIMKgIMKgKHJjKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+
ICsgwqAgwqB9KQo+ICsKPiArI2RlZmluZSBBT19HQyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBcCj4gKyDCoCDCoGxpYnhsX19nYyAqY29uc3QgZ2Mg
PSAmYW8tPmdjCj4gKwo+ICsKPiArLyogQWxsIG9mIHRoZXNlIE1VU1QgYmUgY2FsbGVkIHdpdGgg
dGhlIGN0eCBsb2NrZWQuCj4gKyAqIGxpYnhsX19hb19pbnByb2dyZXNzIE1VU1QgYmUgY2FsbGVk
IHdpdGggdGhlIGN0eCBsb2NrZWQgZXhhY3RseSBvbmNlLiAqLwo+ICtfaGlkZGVuIGxpYnhsX19h
byAqbGlieGxfX2FvX2NyZWF0ZShsaWJ4bF9jdHgqLCB1aW50MzJfdCBkb21pZCwKPiArIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29uc3QgbGli
eGxfYXN5bmNvcF9ob3cqKTsKPiArX2hpZGRlbiBpbnQgbGlieGxfX2FvX2lucHJvZ3Jlc3MobGli
eGxfX2FvICphbyk7Cj4gK19oaWRkZW4gdm9pZCBsaWJ4bF9fYW9fYWJvcnQobGlieGxfX2FvICph
byk7Cj4gK19oaWRkZW4gdm9pZCBsaWJ4bF9fYW9fY29tcGxldGUobGlieGxfX2VnYyAqZWdjLCBs
aWJ4bF9fYW8gKmFvLCBpbnQgcmMpOwo+ICsKPiArLyogRm9yIHVzZSBieSBhbyBtYWNoaW5lcnkg
T05MWSAqLwo+ICtfaGlkZGVuIHZvaWQgbGlieGxfX2FvX19kZXN0cm95KGxpYnhsX2N0eCosIGxp
YnhsX19hbyAqYW8pOwo+ICsKPiArLyoKPiDCoCogQ29udmVuaWVuY2UgbWFjcm9zLgo+IMKgKi8K
Pgo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwgYi90b29scy9saWJ4
bC9saWJ4bF90eXBlcy5pZGwKPiBpbmRleCAzNWI1M2Q2Li44ODcxYzE3IDEwMDY0NAo+IC0tLSBh
L3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5
cGVzLmlkbAo+IEBAIC0zOTUsNiArMzk1LDcgQEAgbGlieGxfZXZlbnRfdHlwZSA9IEVudW1lcmF0
aW9uKCJldmVudF90eXBlIiwgWwo+IMKgIMKgICgxLCAiRE9NQUlOX1NIVVRET1dOIiksCj4gwqAg
wqAgKDIsICJET01BSU5fREVTVFJPWSIpLAo+IMKgIMKgICgzLCAiRElTS19FSkVDVCIpLAo+ICsg
wqAgwqAoNCwgIk9QRVJBVElPTl9DT01QTEVURSIpLAo+IMKgIMKgIF0pCj4KPiDCoGxpYnhsX2V2
X3VzZXIgPSBVSW50KDY0KQo+IEBAIC00MTgsNCArNDE5LDcgQEAgbGlieGxfZXZlbnQgPSBTdHJ1
Y3QoImV2ZW50IixbCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgKCJ2ZGV2Iiwgc3RyaW5nKSwKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoImRpc2siLCBsaWJ4bF9k
ZXZpY2VfZGlzayksCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBdKSksCj4gKyDCoCDCoCDCoCDCoCDCoCAoIm9wZXJhdGlvbl9jb21wbGV0ZSIsIFN0
cnVjdChOb25lLCBbCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCgicmMiLCBpbnRlZ2VyKSwKPiArIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIF0pKSwKPiDCoCDCoCDCoCDCoCDCoCDCoF0p
KV0pCj4gLS0KPiAxLjcuMi41Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:26:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxdw7-0003ed-QZ; Wed, 15 Feb 2012 12:26:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxdw6-0003dK-4K
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:26:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329308767!11571097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6701 invoked from network); 15 Feb 2012 12:26:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:26:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10714075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:26:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 12:26:07 +0000
Message-ID: <1329308758.31256.314.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 15 Feb 2012 12:25:58 +0000
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 14:43 +0000, Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against current unstable. #6 and #9 touch common code.
> 
> Changes since v1:
>  - make PoD stubs proper functions instead of #defines
>  - define need_iommu as 0 instead of littering common code with #if
>  - stub donate_page but leave tmem enabled.
>  - rebased against latest unstable tree

Committed with Acks from Tim & Stefano dfor the ARM bits and Keir for
the non-ARM bits.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:26:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxdw7-0003ed-QZ; Wed, 15 Feb 2012 12:26:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxdw6-0003dK-4K
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:26:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329308767!11571097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6701 invoked from network); 15 Feb 2012 12:26:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:26:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10714075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:26:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 12:26:07 +0000
Message-ID: <1329308758.31256.314.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 15 Feb 2012 12:25:58 +0000
In-Reply-To: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
References: <1329230611.31256.248.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 00/12 v2] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 14:43 +0000, Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against current unstable. #6 and #9 touch common code.
> 
> Changes since v1:
>  - make PoD stubs proper functions instead of #defines
>  - define need_iommu as 0 instead of littering common code with #if
>  - stub donate_page but leave tmem enabled.
>  - rebased against latest unstable tree

Committed with Acks from Tim & Stefano dfor the ARM bits and Keir for
the non-ARM bits.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:28:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxdxj-0003sJ-AA; Wed, 15 Feb 2012 12:27:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxdxi-0003s8-TP
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:27:55 +0000
Received: from [193.109.254.147:59049] by server-8.bemta-14.messagelabs.com id
	BA/00-04087-AC4AB3F4; Wed, 15 Feb 2012 12:27:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329308821!52844981!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1062 invoked from network); 15 Feb 2012 12:27:01 -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;
	15 Feb 2012 12:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10714123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12: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.213.0;
	Wed, 15 Feb 2012 12:27:53 +0000
Message-ID: <1329308871.31256.316.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 15 Feb 2012 12:27:51 +0000
In-Reply-To: <alpine.DEB.2.00.1202141511470.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329140965.31256.109.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202141511470.7456@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Tue, 2012-02-14 at 15:11 +0000, Stefano Stabellini wrote:
> On Mon, 13 Feb 2012, Ian Campbell wrote:
> > 8<---------------------------------------------------------------
> > 
> > From 810e27651f0f883bab01f55e804fe733b92dd824 Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Mon, 13 Feb 2012 13:46:53 +0000
> > Subject: [PATCH] arm: Set XEN_COMPILE_ARCH correctly from "umame -m" on ARM
> 
> ack

Thanks, committed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:28:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxdxj-0003sJ-AA; Wed, 15 Feb 2012 12:27:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxdxi-0003s8-TP
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:27:55 +0000
Received: from [193.109.254.147:59049] by server-8.bemta-14.messagelabs.com id
	BA/00-04087-AC4AB3F4; Wed, 15 Feb 2012 12:27:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329308821!52844981!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1062 invoked from network); 15 Feb 2012 12:27:01 -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;
	15 Feb 2012 12:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10714123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12: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.213.0;
	Wed, 15 Feb 2012 12:27:53 +0000
Message-ID: <1329308871.31256.316.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 15 Feb 2012 12:27:51 +0000
In-Reply-To: <alpine.DEB.2.00.1202141511470.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202101154320.7456@kaball-desktop>
	<1328875368-9608-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329140965.31256.109.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202141511470.7456@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 01/10] arm: few missing #define
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Tue, 2012-02-14 at 15:11 +0000, Stefano Stabellini wrote:
> On Mon, 13 Feb 2012, Ian Campbell wrote:
> > 8<---------------------------------------------------------------
> > 
> > From 810e27651f0f883bab01f55e804fe733b92dd824 Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Mon, 13 Feb 2012 13:46:53 +0000
> > Subject: [PATCH] arm: Set XEN_COMPILE_ARCH correctly from "umame -m" on ARM
> 
> ack

Thanks, committed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:31:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxe0i-00046n-2T; Wed, 15 Feb 2012 12:31:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxe0g-00046J-UK; Wed, 15 Feb 2012 12:30:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329309052!13442752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 520 invoked from network); 15 Feb 2012 12:30:52 -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;
	15 Feb 2012 12:30:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10714620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:30:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 12:30:52 +0000
Date: Wed, 15 Feb 2012 12:35:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F3A7CE1.3080307@citrix.com>
Message-ID: <alpine.DEB.2.00.1202151233430.7456@kaball-desktop>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329225071.31256.241.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
	<4F3A7CE1.3080307@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"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] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, David Vrabel wrote:
> > +void gic_set_guest_irq(unsigned int virtual_irq,
> > +        unsigned int state, unsigned int priority)
> > +{
> > +    int i;
> > +    struct pending_irq *iter, *n;
> > +
> > +    spin_lock(&gic.lock);
> > +    for (i = 0; i < nr_lrs; i++) {
> > +        if (!test_and_set_bit(i, &gic.lr_mask))
> > +        {
> > +            gic_set_lr(i, virtual_irq, state, priority);
> > +            spin_unlock(&gic.lock);
> > +            return;
> > +        }
> > +    }
> 
> You can skip this loop if gic.lr_pending is non-empty as there won't be
> any spare bits in gic.lr_mask.

Right


> > +    n = irq_to_pending(current, virtual_irq);
> > +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> > +    {
> > +        if ( iter->priority < priority )
> > +        {
> > +            list_add_tail(&n->lr_link, &iter->lr_link);
> > +            spin_unlock(&gic.lock);
> > +            return;
> > +        }
> > +    }
> 
> How many pending irqs are expected?  If it's lots then looping through a
> simple list like this might be slow.   Something to keep in mind -- I
> wouldn't try and fix it now.

How many interrupts are the guests going to receive while 4 are already
in service? I am not sure yet.


> > +    list_add(&n->lr_link, &gic.lr_pending);
> > +    spin_unlock(&gic.lock);
> > +    return;
> > +}
> > +
> >  void gic_inject_irq_start(void)
> >  {
> >      uint32_t hcr;
> > @@ -435,13 +471,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >      uint32_t lr;
> >      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
> >  
> > -    for ( i = 0; i < 64; i++ ) {
> > +    for ( i = 0; i < nr_lrs; i++ ) {
> >          if ( eisr & ((uint64_t)1 << i) ) {
> >              struct pending_irq *p;
> >  
> > +            spin_lock(&gic.lock);
> >              lr = GICH[GICH_LR + i];
> >              virq = lr & GICH_LR_VIRTUAL_MASK;
> >              GICH[GICH_LR + i] = 0;
> > +            clear_bit(i, &gic.lr_mask);
> > +
> > +            if ( !list_empty(gic.lr_pending.next) ) {
> > +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> > +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +                list_del(&p->lr_link);
> > +                INIT_LIST_HEAD(&p->lr_link);
> 
> I don't think you need the INIT_LIST_HEAD() here (and even if you did
> you should use list_del_init()).  You only need to init nodes if you
> need to test if they are in a list or not.

OK


> > +                set_bit(i, &gic.lr_mask);
> > +            } else {
> > +                gic_inject_irq_stop();
> > +            }
> > +            spin_unlock(&gic.lock);
> >  
> >              spin_lock(&current->arch.vgic.lock);
> >              p = irq_to_pending(current, virq);
> > @@ -449,7 +498,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >                  p->desc->status &= ~IRQ_INPROGRESS;
> >                  GICC[GICC_DIR] = virq;
> >              }
> > -            gic_inject_irq_stop();
> >              list_del(&p->link);
> >              INIT_LIST_HEAD(&p->link);
> 
> Similarly, here (but this should be fixed up in a separate patch).

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:31:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxe0i-00046n-2T; Wed, 15 Feb 2012 12:31:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxe0g-00046J-UK; Wed, 15 Feb 2012 12:30:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329309052!13442752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 520 invoked from network); 15 Feb 2012 12:30:52 -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;
	15 Feb 2012 12:30:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10714620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:30:52 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 12:30:52 +0000
Date: Wed, 15 Feb 2012 12:35:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F3A7CE1.3080307@citrix.com>
Message-ID: <alpine.DEB.2.00.1202151233430.7456@kaball-desktop>
References: <1329224864-10235-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329225071.31256.241.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202141319540.7456@kaball-desktop>
	<4F3A7CE1.3080307@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"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] [XenARM] [PATCH] arm: support fewer LRs register
 than virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, David Vrabel wrote:
> > +void gic_set_guest_irq(unsigned int virtual_irq,
> > +        unsigned int state, unsigned int priority)
> > +{
> > +    int i;
> > +    struct pending_irq *iter, *n;
> > +
> > +    spin_lock(&gic.lock);
> > +    for (i = 0; i < nr_lrs; i++) {
> > +        if (!test_and_set_bit(i, &gic.lr_mask))
> > +        {
> > +            gic_set_lr(i, virtual_irq, state, priority);
> > +            spin_unlock(&gic.lock);
> > +            return;
> > +        }
> > +    }
> 
> You can skip this loop if gic.lr_pending is non-empty as there won't be
> any spare bits in gic.lr_mask.

Right


> > +    n = irq_to_pending(current, virtual_irq);
> > +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> > +    {
> > +        if ( iter->priority < priority )
> > +        {
> > +            list_add_tail(&n->lr_link, &iter->lr_link);
> > +            spin_unlock(&gic.lock);
> > +            return;
> > +        }
> > +    }
> 
> How many pending irqs are expected?  If it's lots then looping through a
> simple list like this might be slow.   Something to keep in mind -- I
> wouldn't try and fix it now.

How many interrupts are the guests going to receive while 4 are already
in service? I am not sure yet.


> > +    list_add(&n->lr_link, &gic.lr_pending);
> > +    spin_unlock(&gic.lock);
> > +    return;
> > +}
> > +
> >  void gic_inject_irq_start(void)
> >  {
> >      uint32_t hcr;
> > @@ -435,13 +471,26 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >      uint32_t lr;
> >      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
> >  
> > -    for ( i = 0; i < 64; i++ ) {
> > +    for ( i = 0; i < nr_lrs; i++ ) {
> >          if ( eisr & ((uint64_t)1 << i) ) {
> >              struct pending_irq *p;
> >  
> > +            spin_lock(&gic.lock);
> >              lr = GICH[GICH_LR + i];
> >              virq = lr & GICH_LR_VIRTUAL_MASK;
> >              GICH[GICH_LR + i] = 0;
> > +            clear_bit(i, &gic.lr_mask);
> > +
> > +            if ( !list_empty(gic.lr_pending.next) ) {
> > +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> > +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +                list_del(&p->lr_link);
> > +                INIT_LIST_HEAD(&p->lr_link);
> 
> I don't think you need the INIT_LIST_HEAD() here (and even if you did
> you should use list_del_init()).  You only need to init nodes if you
> need to test if they are in a list or not.

OK


> > +                set_bit(i, &gic.lr_mask);
> > +            } else {
> > +                gic_inject_irq_stop();
> > +            }
> > +            spin_unlock(&gic.lock);
> >  
> >              spin_lock(&current->arch.vgic.lock);
> >              p = irq_to_pending(current, virq);
> > @@ -449,7 +498,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >                  p->desc->status &= ~IRQ_INPROGRESS;
> >                  GICC[GICC_DIR] = virq;
> >              }
> > -            gic_inject_irq_stop();
> >              list_del(&p->link);
> >              INIT_LIST_HEAD(&p->link);
> 
> Similarly, here (but this should be fixed up in a separate patch).

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:32:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxe1q-0004DJ-IS; Wed, 15 Feb 2012 12:32:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxe1o-0004Co-Hn
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329309122!8318002!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32376 invoked from network); 15 Feb 2012 12:32:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 12:32:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 12:33:40 +0000
Message-Id: <4F3BB3D00200007800073290@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 12:32:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] pci_release_devices() call site
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Is there a particular reason why currently this is being called from
arch_domain_destroy() (i.e. the asynchronous part of domain teardown)
instead of from domain_relinquish_resources() (running synchronously)?

While xl appears to actually make use of XEN_DOMCTL_deassign_device
when shutting down a domain, xend doesn't, thus making a successful
immediate restart of a domain with assigned devices a matter of luck.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:32:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12: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.xensource.com>)
	id 1Rxe1q-0004DJ-IS; Wed, 15 Feb 2012 12:32:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxe1o-0004Co-Hn
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:32:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329309122!8318002!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32376 invoked from network); 15 Feb 2012 12:32:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 12:32:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 12:33:40 +0000
Message-Id: <4F3BB3D00200007800073290@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 12:32:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] pci_release_devices() call site
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Is there a particular reason why currently this is being called from
arch_domain_destroy() (i.e. the asynchronous part of domain teardown)
instead of from domain_relinquish_resources() (running synchronously)?

While xl appears to actually make use of XEN_DOMCTL_deassign_device
when shutting down a domain, xend doesn't, thus making a successful
immediate restart of a domain with assigned devices a matter of luck.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:52:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxeKl-0004d8-UJ; Wed, 15 Feb 2012 12:51:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxeKk-0004d3-MI
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:51:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329310296!14983261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25217 invoked from network); 15 Feb 2012 12:51:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10715249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:51:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 12:51:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxeKd-0008N4-Jp; Wed, 15 Feb 2012 12:51:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxeKd-0005RR-Ir;
	Wed, 15 Feb 2012 12:51:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.43607.571172.475948@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 12:51:35 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronou=
s/long-running operation infrastructure"):
> 2012/1/26 Ian Jackson <ian.jackson@eu.citrix.com>:
> > +int libxl__ao_inprogress(libxl__ao *ao)
> > +{
> > +    AO_GC;
> > +    int rc;
> =

> I've just started playing with this, but I've found that if you call
> AO_INPROGRESS without adding any event it blocks forever, and I'm not
> sure if that is a design decision or a bug. Anyway, sometimes like in
> libxl__initiate_device_remove you might call AO_INPROGRESS without
> adding any event, so I think it will be safe to add something like:

How are you expecting this ao to complete ?  If you haven't asked for
an event callback then presumably libxl__ao_complete will never be
called.

> if (!CTX->watch_counter)
>     return 0;

This is definitely wrong.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 12:52:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 12:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxeKl-0004d8-UJ; Wed, 15 Feb 2012 12:51:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxeKk-0004d3-MI
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 12:51:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329310296!14983261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25217 invoked from network); 15 Feb 2012 12:51:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 12:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10715249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 12:51:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 12:51:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxeKd-0008N4-Jp; Wed, 15 Feb 2012 12:51:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxeKd-0005RR-Ir;
	Wed, 15 Feb 2012 12:51:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.43607.571172.475948@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 12:51:35 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronou=
s/long-running operation infrastructure"):
> 2012/1/26 Ian Jackson <ian.jackson@eu.citrix.com>:
> > +int libxl__ao_inprogress(libxl__ao *ao)
> > +{
> > +    AO_GC;
> > +    int rc;
> =

> I've just started playing with this, but I've found that if you call
> AO_INPROGRESS without adding any event it blocks forever, and I'm not
> sure if that is a design decision or a bug. Anyway, sometimes like in
> libxl__initiate_device_remove you might call AO_INPROGRESS without
> adding any event, so I think it will be safe to add something like:

How are you expecting this ao to complete ?  If you haven't asked for
an event callback then presumably libxl__ao_complete will never be
called.

> if (!CTX->watch_counter)
>     return 0;

This is definitely wrong.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:04:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxeWK-0005C2-4E; Wed, 15 Feb 2012 13:03:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxeWI-0005Bx-MZ
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:03:38 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329311011!14367010!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8046 invoked from network); 15 Feb 2012 13:03:32 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 13:03:32 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1FD3T1a005226
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 15 Feb 2012 06:03:29 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F3B775B0200007800073180@nat28.tlf.novell.com>
Date: Wed, 15 Feb 2012 06:03:29 -0700
Message-Id: <66E3111A-6F09-4FBF-A6C7-F1B99943ED49@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<4F3B775B0200007800073180@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Wed, 15 Feb 2012 06:03:30 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
	existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 15, 2012, at 1:14 AM, Jan Beulich wrote:

>>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> patch 4 (blkif.h: Define and document the request number/size/segments
>>          extension.)
>>   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
> 
> Why? It got bumped very recently to 0x040200, your change could
> well go under that same version.

When reviewing the history of xen-compat.h, it appeared that the version was bumped
for each incompatible change.  Considering there are 8 bits of sub-minor space, why
wouldn't it be bumped?  It allows an integrator of new headers to review all change sets
associated with this one header file to understand the work required for an import.
 
> (Which is not to say that I'm now
> suddenly agreeing to stuff under io/ being controlled by this).

:-)

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:04:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:04:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxeWK-0005C2-4E; Wed, 15 Feb 2012 13:03:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxeWI-0005Bx-MZ
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:03:38 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329311011!14367010!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8046 invoked from network); 15 Feb 2012 13:03:32 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 13:03:32 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1FD3T1a005226
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 15 Feb 2012 06:03:29 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F3B775B0200007800073180@nat28.tlf.novell.com>
Date: Wed, 15 Feb 2012 06:03:29 -0700
Message-Id: <66E3111A-6F09-4FBF-A6C7-F1B99943ED49@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<4F3B775B0200007800073180@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Wed, 15 Feb 2012 06:03:30 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
	existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Feb 15, 2012, at 1:14 AM, Jan Beulich wrote:

>>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> patch 4 (blkif.h: Define and document the request number/size/segments
>>          extension.)
>>   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
> 
> Why? It got bumped very recently to 0x040200, your change could
> well go under that same version.

When reviewing the history of xen-compat.h, it appeared that the version was bumped
for each incompatible change.  Considering there are 8 bits of sub-minor space, why
wouldn't it be bumped?  It allows an integrator of new headers to review all change sets
associated with this one header file to understand the work required for an import.
 
> (Which is not to say that I'm now
> suddenly agreeing to stuff under io/ being controlled by this).

:-)

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:06:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13: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.xensource.com>)
	id 1RxeZE-0005I4-NG; Wed, 15 Feb 2012 13:06:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxeZD-0005Hv-EF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:06:39 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329311193!14067098!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13147 invoked from network); 15 Feb 2012 13:06:33 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 13:06:33 -0000
Received: by wgbdr13 with SMTP id dr13so811560wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 05:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=/in1zEIcNYk5/+F+Josq95+3Iv/nUjuHTjyOvutGuZg=;
	b=vi4kPTWx51rZ6CmwCTBX2zMVsjCm9kiyzCDn+Utf4MZxTnd6mUYYM0IYYeGO/Oj83s
	dY3FJnKCSJkwpTnU7nLaYTiYFSROIE1vIUkN4Ez4Ylh4MNarZi6O1MCivCgvNfUhPPZ5
	tbvGS7nCgmKhZ81TOWd0EaPpJLcQ4P53XymGk=
MIME-Version: 1.0
Received: by 10.216.134.3 with SMTP id r3mr3157218wei.40.1329311192962; Wed,
	15 Feb 2012 05:06:32 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 15 Feb 2012 05:06:32 -0800 (PST)
In-Reply-To: <20283.43607.571172.475948@mariner.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 14:06:32 +0100
X-Google-Sender-Auth: N7T6_kSG4OLJ-jL3RuisJXPo8QE
Message-ID: <CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE1IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggMDgvMTFdIGxpYnhs
OiBBc3luY2hyb25vdXMvbG9uZy1ydW5uaW5nIG9wZXJhdGlvbiBpbmZyYXN0cnVjdHVyZSIpOgo+
PiAyMDEyLzEvMjYgSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+
ICtpbnQgbGlieGxfX2FvX2lucHJvZ3Jlc3MobGlieGxfX2FvICphbykKPj4gPiArewo+PiA+ICsg
wqAgwqBBT19HQzsKPj4gPiArIMKgIMKgaW50IHJjOwo+Pgo+PiBJJ3ZlIGp1c3Qgc3RhcnRlZCBw
bGF5aW5nIHdpdGggdGhpcywgYnV0IEkndmUgZm91bmQgdGhhdCBpZiB5b3UgY2FsbAo+PiBBT19J
TlBST0dSRVNTIHdpdGhvdXQgYWRkaW5nIGFueSBldmVudCBpdCBibG9ja3MgZm9yZXZlciwgYW5k
IEknbSBub3QKPj4gc3VyZSBpZiB0aGF0IGlzIGEgZGVzaWduIGRlY2lzaW9uIG9yIGEgYnVnLiBB
bnl3YXksIHNvbWV0aW1lcyBsaWtlIGluCj4+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3Zl
IHlvdSBtaWdodCBjYWxsIEFPX0lOUFJPR1JFU1Mgd2l0aG91dAo+PiBhZGRpbmcgYW55IGV2ZW50
LCBzbyBJIHRoaW5rIGl0IHdpbGwgYmUgc2FmZSB0byBhZGQgc29tZXRoaW5nIGxpa2U6Cj4KPiBI
b3cgYXJlIHlvdSBleHBlY3RpbmcgdGhpcyBhbyB0byBjb21wbGV0ZSA/CgpJIHdhcyBleHBlY3Rp
bmcgdGhhdCBBT19JTlBST0dSRVNTIHJldHVybnMgMCBpZiBubyBldmVudHMgaGF2ZSBiZWVuCmFk
ZGVkLCBzbyBJIGRvbid0IG5lZWQgdG8ga25vdyB3aGV0aGVyIEkgaGF2ZSBhZGRlZCBldmVudHMg
b3Igbm90IHRvCmNhbGwgQU9fSU5QUk9HUkVTUy4KCj4gSWYgeW91IGhhdmVuJ3QgYXNrZWQgZm9y
Cj4gYW4gZXZlbnQgY2FsbGJhY2sgdGhlbiBwcmVzdW1hYmx5IGxpYnhsX19hb19jb21wbGV0ZSB3
aWxsIG5ldmVyIGJlCj4gY2FsbGVkLgoKSSdtIHRhbGtpbmcgYWJvdXQgbGlieGxfX2FvX2lucHJv
Z3Jlc3MsIHdoaWNoIGlzIGNhbGxlZCBmcm9tCkFPX0lOUFJPR1JFU1MgbWFjcm8uIFdpdGggdGhl
IGN1cnJlbnQgY29kZSB0aGlzIG1hY3JvIG1pZ2h0IGJlIGNhbGxlZApmcm9tIGxpYnhsX2Rldmlj
ZV9kaXNrX3JlbW92ZSBmb3IgZXhhbXBsZSB3aXRob3V0IGFkZGluZyBhbnkgZXZlbnRzLApiZWNh
dXNlIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlIGNhbiByZXR1cm4gc3VjY2Vzc2Z1bGx5
IHdpdGhvdXQKYWRkaW5nIGFuIGV2ZW50LCBhbmQgQU9fSU5QUk9HUkVTUyBpcyBjYWxsZWQgdW5j
b25kaXRpb25hbGx5LgoKPj4gaWYgKCFDVFgtPndhdGNoX2NvdW50ZXIpCj4+IMKgIMKgIHJldHVy
biAwOwo+Cj4gVGhpcyBpcyBkZWZpbml0ZWx5IHdyb25nLgo+Cj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:06:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13: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.xensource.com>)
	id 1RxeZE-0005I4-NG; Wed, 15 Feb 2012 13:06:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RxeZD-0005Hv-EF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:06:39 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329311193!14067098!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13147 invoked from network); 15 Feb 2012 13:06:33 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 13:06:33 -0000
Received: by wgbdr13 with SMTP id dr13so811560wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 05:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=/in1zEIcNYk5/+F+Josq95+3Iv/nUjuHTjyOvutGuZg=;
	b=vi4kPTWx51rZ6CmwCTBX2zMVsjCm9kiyzCDn+Utf4MZxTnd6mUYYM0IYYeGO/Oj83s
	dY3FJnKCSJkwpTnU7nLaYTiYFSROIE1vIUkN4Ez4Ylh4MNarZi6O1MCivCgvNfUhPPZ5
	tbvGS7nCgmKhZ81TOWd0EaPpJLcQ4P53XymGk=
MIME-Version: 1.0
Received: by 10.216.134.3 with SMTP id r3mr3157218wei.40.1329311192962; Wed,
	15 Feb 2012 05:06:32 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 15 Feb 2012 05:06:32 -0800 (PST)
In-Reply-To: <20283.43607.571172.475948@mariner.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 14:06:32 +0100
X-Google-Sender-Auth: N7T6_kSG4OLJ-jL3RuisJXPo8QE
Message-ID: <CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE1IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggMDgvMTFdIGxpYnhs
OiBBc3luY2hyb25vdXMvbG9uZy1ydW5uaW5nIG9wZXJhdGlvbiBpbmZyYXN0cnVjdHVyZSIpOgo+
PiAyMDEyLzEvMjYgSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+
ICtpbnQgbGlieGxfX2FvX2lucHJvZ3Jlc3MobGlieGxfX2FvICphbykKPj4gPiArewo+PiA+ICsg
wqAgwqBBT19HQzsKPj4gPiArIMKgIMKgaW50IHJjOwo+Pgo+PiBJJ3ZlIGp1c3Qgc3RhcnRlZCBw
bGF5aW5nIHdpdGggdGhpcywgYnV0IEkndmUgZm91bmQgdGhhdCBpZiB5b3UgY2FsbAo+PiBBT19J
TlBST0dSRVNTIHdpdGhvdXQgYWRkaW5nIGFueSBldmVudCBpdCBibG9ja3MgZm9yZXZlciwgYW5k
IEknbSBub3QKPj4gc3VyZSBpZiB0aGF0IGlzIGEgZGVzaWduIGRlY2lzaW9uIG9yIGEgYnVnLiBB
bnl3YXksIHNvbWV0aW1lcyBsaWtlIGluCj4+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3Zl
IHlvdSBtaWdodCBjYWxsIEFPX0lOUFJPR1JFU1Mgd2l0aG91dAo+PiBhZGRpbmcgYW55IGV2ZW50
LCBzbyBJIHRoaW5rIGl0IHdpbGwgYmUgc2FmZSB0byBhZGQgc29tZXRoaW5nIGxpa2U6Cj4KPiBI
b3cgYXJlIHlvdSBleHBlY3RpbmcgdGhpcyBhbyB0byBjb21wbGV0ZSA/CgpJIHdhcyBleHBlY3Rp
bmcgdGhhdCBBT19JTlBST0dSRVNTIHJldHVybnMgMCBpZiBubyBldmVudHMgaGF2ZSBiZWVuCmFk
ZGVkLCBzbyBJIGRvbid0IG5lZWQgdG8ga25vdyB3aGV0aGVyIEkgaGF2ZSBhZGRlZCBldmVudHMg
b3Igbm90IHRvCmNhbGwgQU9fSU5QUk9HUkVTUy4KCj4gSWYgeW91IGhhdmVuJ3QgYXNrZWQgZm9y
Cj4gYW4gZXZlbnQgY2FsbGJhY2sgdGhlbiBwcmVzdW1hYmx5IGxpYnhsX19hb19jb21wbGV0ZSB3
aWxsIG5ldmVyIGJlCj4gY2FsbGVkLgoKSSdtIHRhbGtpbmcgYWJvdXQgbGlieGxfX2FvX2lucHJv
Z3Jlc3MsIHdoaWNoIGlzIGNhbGxlZCBmcm9tCkFPX0lOUFJPR1JFU1MgbWFjcm8uIFdpdGggdGhl
IGN1cnJlbnQgY29kZSB0aGlzIG1hY3JvIG1pZ2h0IGJlIGNhbGxlZApmcm9tIGxpYnhsX2Rldmlj
ZV9kaXNrX3JlbW92ZSBmb3IgZXhhbXBsZSB3aXRob3V0IGFkZGluZyBhbnkgZXZlbnRzLApiZWNh
dXNlIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3ZlIGNhbiByZXR1cm4gc3VjY2Vzc2Z1bGx5
IHdpdGhvdXQKYWRkaW5nIGFuIGV2ZW50LCBhbmQgQU9fSU5QUk9HUkVTUyBpcyBjYWxsZWQgdW5j
b25kaXRpb25hbGx5LgoKPj4gaWYgKCFDVFgtPndhdGNoX2NvdW50ZXIpCj4+IMKgIMKgIHJldHVy
biAwOwo+Cj4gVGhpcyBpcyBkZWZpbml0ZWx5IHdyb25nLgo+Cj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13: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.xensource.com>)
	id 1RxeZm-0005KR-3c; Wed, 15 Feb 2012 13:07:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxeZl-0005K2-Ja
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:07:13 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329311225!13477149!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26367 invoked from network); 15 Feb 2012 13:07:06 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 13:07:06 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1FD71en005243
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 15 Feb 2012 06:07:01 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1329136547.31256.89.camel@zakaz.uk.xensource.com>
Date: Wed, 15 Feb 2012 06:07:02 -0700
Message-Id: <87D72459-4CF3-4942-9243-484F5E7780EF@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Wed, 15 Feb 2012 06:07:02 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 13, 2012, at 5:35 AM, Ian Campbell wrote:

> On Thu, 2012-02-09 at 15:12 +0000, Justin T. Gibbs wrote:
>> On Feb 9, 2012, at 2:48 AM, Ian Campbell wrote:
>> 
>>> On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
>>>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>>>> 
>>>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>>>>> @@ -187,6 +216,25 @@
>>>>>> *      The machine ABI rules governing the format of all ring request and
>>>>>> *      response structures.
>>>>>> *
>>>>>> + * ring-page-order
>>>>>> + *      Values:         <uint32_t>
>>>>>> + *      Default Value:  0
>>>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>>>> 
>>>>> Why not just max-ring-page-order. After all, the value is meaningless
>>>>> for a backend that only exposes max-ring-pages.
>>>>> 
>>>>>> + *      Notes:          1, 3
>>>>>> + *
>>>>>> + *      The size of the frontend allocated request ring buffer in units
>>>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>>>>> + *      etc.).
>>>>>> + *
>>>>>> + * ring-pages
>>>>>> + *      Values:         <uint32_t>
>>>>>> + *      Default Value:  1
>>>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>>>> 
>>>>> Similarly here - just max-ring-pages should do.
>>>> 
>>>> This patch documents existing extensions.  For a new driver to properly negotiate a
>>>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
>>>> you must use the XenBus node names as I've defined them here.
>>> 
>>> Can we pick one and mark it as preferred and the other deprecated or
>>> similar? Perhaps backends will have to support both for the foreseeable
>>> future but we should make it possible for frontends to just pick one if
>>> that's what they want while nudging them in the direction of all picking
>>> the same one.
>> 
>> History says that back-ends are updated more slowly than front-ends.  For
>> example, my fixes to QEMU's serial port emulation that have been in Xen's
>> mainline for ~2 years are still not widely deployed on EC2.  Folks running
>> FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
>> can get console output.
>> 
>> So, if you want your front-ends to have optimal performance regardless of
>> what cloud or appliance they are running on, the two types will have to be
>> supported for some time.  Neither is better than the other, just different.
>> 
>> The opposite is true for back-ends.  If your customer controls the guest
>> environment and chooses not upgrade, you can't kill support for the
>> variant they use.
> 
> I agree with all you say, the practicalities certainly mean we may well
> be stuck with both forever. I don't think there is any harm in
> documenting one of them as preferred though.
> 
> If someone has the freedom (or desire) to only implement one of the two
> in their code base then that provides guidance as to which it should be,
> at least then we will be encouraging the right trajectory. Also it gives
> some small amount of ammunition to people who are stuck with a provider
> (of either front or backend) of the wrong type for their environment and
> helps break the stalemate as to who should fix their end (however
> helpful that might be in practice).

Anyone care to flip a coin?

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13: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.xensource.com>)
	id 1RxeZm-0005KR-3c; Wed, 15 Feb 2012 13:07:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RxeZl-0005K2-Ja
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:07:13 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329311225!13477149!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26367 invoked from network); 15 Feb 2012 13:07:06 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 13:07:06 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1FD71en005243
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 15 Feb 2012 06:07:01 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1329136547.31256.89.camel@zakaz.uk.xensource.com>
Date: Wed, 15 Feb 2012 06:07:02 -0700
Message-Id: <87D72459-4CF3-4942-9243-484F5E7780EF@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Wed, 15 Feb 2012 06:07:02 -0700 (MST)
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
	Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 13, 2012, at 5:35 AM, Ian Campbell wrote:

> On Thu, 2012-02-09 at 15:12 +0000, Justin T. Gibbs wrote:
>> On Feb 9, 2012, at 2:48 AM, Ian Campbell wrote:
>> 
>>> On Fri, 2012-02-03 at 14:58 +0000, Justin Gibbs wrote:
>>>> On Feb 3, 2012, at 6:33 AM, Jan Beulich wrote:
>>>> 
>>>>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>>>>> @@ -187,6 +216,25 @@
>>>>>> *      The machine ABI rules governing the format of all ring request and
>>>>>> *      response structures.
>>>>>> *
>>>>>> + * ring-page-order
>>>>>> + *      Values:         <uint32_t>
>>>>>> + *      Default Value:  0
>>>>>> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
>>>>> 
>>>>> Why not just max-ring-page-order. After all, the value is meaningless
>>>>> for a backend that only exposes max-ring-pages.
>>>>> 
>>>>>> + *      Notes:          1, 3
>>>>>> + *
>>>>>> + *      The size of the frontend allocated request ring buffer in units
>>>>>> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
>>>>>> + *      etc.).
>>>>>> + *
>>>>>> + * ring-pages
>>>>>> + *      Values:         <uint32_t>
>>>>>> + *      Default Value:  1
>>>>>> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
>>>>> 
>>>>> Similarly here - just max-ring-pages should do.
>>>> 
>>>> This patch documents existing extensions.  For a new driver to properly negotiate a
>>>> multi-page ring with a Dom0 on EC2 (ring-pages) or a Citrix Dom0/guest (ring-page-order),
>>>> you must use the XenBus node names as I've defined them here.
>>> 
>>> Can we pick one and mark it as preferred and the other deprecated or
>>> similar? Perhaps backends will have to support both for the foreseeable
>>> future but we should make it possible for frontends to just pick one if
>>> that's what they want while nudging them in the direction of all picking
>>> the same one.
>> 
>> History says that back-ends are updated more slowly than front-ends.  For
>> example, my fixes to QEMU's serial port emulation that have been in Xen's
>> mainline for ~2 years are still not widely deployed on EC2.  Folks running
>> FreeBSD there are using an ugly hack to FreeBSD's serial driver so they
>> can get console output.
>> 
>> So, if you want your front-ends to have optimal performance regardless of
>> what cloud or appliance they are running on, the two types will have to be
>> supported for some time.  Neither is better than the other, just different.
>> 
>> The opposite is true for back-ends.  If your customer controls the guest
>> environment and chooses not upgrade, you can't kill support for the
>> variant they use.
> 
> I agree with all you say, the practicalities certainly mean we may well
> be stuck with both forever. I don't think there is any harm in
> documenting one of them as preferred though.
> 
> If someone has the freedom (or desire) to only implement one of the two
> in their code base then that provides guidance as to which it should be,
> at least then we will be encouraging the right trajectory. Also it gives
> some small amount of ammunition to people who are stuck with a provider
> (of either front or backend) of the wrong type for their environment and
> helps break the stalemate as to who should fix their end (however
> helpful that might be in practice).

Anyone care to flip a coin?

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:16:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13: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.xensource.com>)
	id 1Rxeiq-0005jR-DR; Wed, 15 Feb 2012 13:16:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxeio-0005jM-TA
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:16:35 +0000
Received: from [85.158.139.83:44272] by server-3.bemta-5.messagelabs.com id
	29/F7-06438-130BB3F4; Wed, 15 Feb 2012 13:16:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329311792!15152463!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21282 invoked from network); 15 Feb 2012 13:16:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 13:16:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 13:16:32 +0000
Message-Id: <4F3BBE3F02000078000732C6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 13:16:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<4F3B775B0200007800073180@nat28.tlf.novell.com>
	<66E3111A-6F09-4FBF-A6C7-F1B99943ED49@spectralogic.com>
In-Reply-To: <66E3111A-6F09-4FBF-A6C7-F1B99943ED49@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 14:03, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> On Feb 15, 2012, at 1:14 AM, Jan Beulich wrote:
> 
>>>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>> patch 4 (blkif.h: Define and document the request number/size/segments
>>>          extension.)
>>>   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
>> 
>> Why? It got bumped very recently to 0x040200, your change could
>> well go under that same version.
> 
> When reviewing the history of xen-compat.h, it appeared that the version was 
> bumped
> for each incompatible change.  Considering there are 8 bits of sub-minor 
> space, why
> wouldn't it be bumped?  It allows an integrator of new headers to review all 
> change sets
> associated with this one header file to understand the work required for an 
> import.

Then be it that way if it is to Keir's liking.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:16:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13: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.xensource.com>)
	id 1Rxeiq-0005jR-DR; Wed, 15 Feb 2012 13:16:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxeio-0005jM-TA
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:16:35 +0000
Received: from [85.158.139.83:44272] by server-3.bemta-5.messagelabs.com id
	29/F7-06438-130BB3F4; Wed, 15 Feb 2012 13:16:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329311792!15152463!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21282 invoked from network); 15 Feb 2012 13:16:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 13:16:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 13:16:32 +0000
Message-Id: <4F3BBE3F02000078000732C6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 13:16:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<4F3B775B0200007800073180@nat28.tlf.novell.com>
	<66E3111A-6F09-4FBF-A6C7-F1B99943ED49@spectralogic.com>
In-Reply-To: <66E3111A-6F09-4FBF-A6C7-F1B99943ED49@spectralogic.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 14:03, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> On Feb 15, 2012, at 1:14 AM, Jan Beulich wrote:
> 
>>>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>>> patch 4 (blkif.h: Define and document the request number/size/segments
>>>          extension.)
>>>   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
>> 
>> Why? It got bumped very recently to 0x040200, your change could
>> well go under that same version.
> 
> When reviewing the history of xen-compat.h, it appeared that the version was 
> bumped
> for each incompatible change.  Considering there are 8 bits of sub-minor 
> space, why
> wouldn't it be bumped?  It allows an integrator of new headers to review all 
> change sets
> associated with this one header file to understand the work required for an 
> import.

Then be it that way if it is to Keir's liking.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:17:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxejX-0005lq-RG; Wed, 15 Feb 2012 13:17:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RxejV-0005lZ-R4
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:17:18 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329311831!14919553!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIwNzQyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3950 invoked from network); 15 Feb 2012 13:17:11 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 13:17:11 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=jMn5k5j1UjGn0hzzcIGkihS9zIZahKlch4xdVAwlCUQlqytiSyKnf32z
	un3rPoBkjeHQC6UP0AcPDdvUfukqZSX+AhFPIs70zuwWeKsXsJVdsf+7F
	zHoUXlmbZmcrIqZz/kjHQuvSzjPO53oskvCOtTMTfkjcvNoiFZTd7bdt0
	32wvL7JWSkzgn0I7ZEQBQMmblBwsPChOmQ/BtqTd8GOVSoSV4O19aiG1m
	D6IajAJCIup75/BUq3W0Frr2jqQG4;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329311832; x=1360847832;
	h=mime-version:subject:message-id:date:from:to;
	bh=clbyaCb8EknlUHE4u+62DH/vsU6iTTj5v8wD2EzgKHM=;
	b=E9GE5q1jYOIyeGjJtQJQ5O4Zm07zJErPPA9QHCIpkZTvJCnF1cys6eFH
	ld0jS4eTcbtM43SiQ4q0UelgbEUzMOaqM7W9lywLxDy1X0kQmjFLLAyiK
	sVqtpBcvUW3MCG53R0gTMip1/0y9pS0yahIH8LIN/ytTvLDg5JUZO0ROJ
	bUi8lUbpVoR6jUYk92jOIdIvnZuNYAqK7cDXlFT9mY+87ZjjIw+8jb6ne
	UhYjh1CmVEkdBdic9tBGqBs/jz1qq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="102055863"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 15 Feb 2012 14:17:12 +0100
X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="129302350"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 15 Feb 2012 14:17:11 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 265E6961027;
	Wed, 15 Feb 2012 14:17:11 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============8128120816759880489=="
MIME-Version: 1.0
X-Mercurial-Node: 1bdc49548c4f6ef4bff1e726a3045a74450be3d5
Message-Id: <1bdc49548c4f6ef4bff1.1329311512@nehalem1>
Date: Wed, 15 Feb 2012 14:11:52 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Add xlcpupool.cfg man page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8128120816759880489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Add a man page describing the configuration file for creating cpupools
via xl cpupool-create.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


1 file changed, 117 insertions(+)
docs/man/xlcpupool.cfg.pod.5 |  117 ++++++++++++++++++++++++++++++++++++++++++



--===============8128120816759880489==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1329311497 -3600
# Node ID 1bdc49548c4f6ef4bff1e726a3045a74450be3d5
# Parent  0ba87b95e80bae059fe70b4b117dcc409f2471ef
Add xlcpupool.cfg man page

Add a man page describing the configuration file for creating cpupools
via xl cpupool-create.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 0ba87b95e80b -r 1bdc49548c4f docs/man/xlcpupool.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xlcpupool.cfg.pod.5	Wed Feb 15 14:11:37 2012 +0100
@@ -0,0 +1,117 @@
+=head1 NAME
+
+xlcpupool.cfg - XL Cpupool Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xlcpupool
+
+=head1 DESCRIPTION
+
+To create a Cpupool with xl requires the provision of a cpupool config
+file.  Typically these live in `/etc/xen/CPUPOOL.cfg` where CPUPOOL is
+the name of the cpupool.
+
+=head1 SYNTAX
+
+A cpupool config file consists of a series of C<KEY=VALUE> pairs.
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any cpupool:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the cpupool.  Names of cpupools existing on a
+single host must be unique.
+
+=back
+
+=head2 Optional Configuration Items
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<sched="SCHED">
+
+Specifies the scheduler which is used for the cpupool. Valid
+values for C<SCHED> are:
+
+=over 4
+
+=item B<credit>
+
+the credit scheduler
+
+=item B<credit2>
+
+the credit2 scheduler
+
+=item B<sedf>
+
+the SEDF scheduler
+
+=back
+
+The default scheduler is the one used for C<Pool-0> specified as
+boot parameter of the hypervisor.
+
+=item B<nodes="NODES">
+
+Specifies the cpus of the NUMA-nodes given in C<NODES> (an integer or
+a list of integers) to be member of the cpupool. The free cpus in the
+specified nodes are allocated in the new cpupool.
+
+=item B<cpus="CPUS">
+
+The specified C<CPUS> are allocated in the new cpupool. All cpus must
+be free. Must not be specified together with B<nodes>.
+
+If neither B<nodes> nor B<cpus> are specified only the first free cpu
+found will be allocated in the new cpupool.
+
+=back
+
+=head1 FILES
+
+F</etc/xen/CPUPOOL.cfg>
+
+=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
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+

--===============8128120816759880489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8128120816759880489==--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:17:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxejX-0005lq-RG; Wed, 15 Feb 2012 13:17:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RxejV-0005lZ-R4
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:17:18 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329311831!14919553!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIwNzQyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3950 invoked from network); 15 Feb 2012 13:17:11 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 13:17:11 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=jMn5k5j1UjGn0hzzcIGkihS9zIZahKlch4xdVAwlCUQlqytiSyKnf32z
	un3rPoBkjeHQC6UP0AcPDdvUfukqZSX+AhFPIs70zuwWeKsXsJVdsf+7F
	zHoUXlmbZmcrIqZz/kjHQuvSzjPO53oskvCOtTMTfkjcvNoiFZTd7bdt0
	32wvL7JWSkzgn0I7ZEQBQMmblBwsPChOmQ/BtqTd8GOVSoSV4O19aiG1m
	D6IajAJCIup75/BUq3W0Frr2jqQG4;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1329311832; x=1360847832;
	h=mime-version:subject:message-id:date:from:to;
	bh=clbyaCb8EknlUHE4u+62DH/vsU6iTTj5v8wD2EzgKHM=;
	b=E9GE5q1jYOIyeGjJtQJQ5O4Zm07zJErPPA9QHCIpkZTvJCnF1cys6eFH
	ld0jS4eTcbtM43SiQ4q0UelgbEUzMOaqM7W9lywLxDy1X0kQmjFLLAyiK
	sVqtpBcvUW3MCG53R0gTMip1/0y9pS0yahIH8LIN/ytTvLDg5JUZO0ROJ
	bUi8lUbpVoR6jUYk92jOIdIvnZuNYAqK7cDXlFT9mY+87ZjjIw+8jb6ne
	UhYjh1CmVEkdBdic9tBGqBs/jz1qq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="102055863"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 15 Feb 2012 14:17:12 +0100
X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="129302350"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 15 Feb 2012 14:17:11 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 265E6961027;
	Wed, 15 Feb 2012 14:17:11 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============8128120816759880489=="
MIME-Version: 1.0
X-Mercurial-Node: 1bdc49548c4f6ef4bff1e726a3045a74450be3d5
Message-Id: <1bdc49548c4f6ef4bff1.1329311512@nehalem1>
Date: Wed, 15 Feb 2012 14:11:52 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Add xlcpupool.cfg man page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8128120816759880489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Add a man page describing the configuration file for creating cpupools
via xl cpupool-create.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


1 file changed, 117 insertions(+)
docs/man/xlcpupool.cfg.pod.5 |  117 ++++++++++++++++++++++++++++++++++++++++++



--===============8128120816759880489==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1329311497 -3600
# Node ID 1bdc49548c4f6ef4bff1e726a3045a74450be3d5
# Parent  0ba87b95e80bae059fe70b4b117dcc409f2471ef
Add xlcpupool.cfg man page

Add a man page describing the configuration file for creating cpupools
via xl cpupool-create.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 0ba87b95e80b -r 1bdc49548c4f docs/man/xlcpupool.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xlcpupool.cfg.pod.5	Wed Feb 15 14:11:37 2012 +0100
@@ -0,0 +1,117 @@
+=head1 NAME
+
+xlcpupool.cfg - XL Cpupool Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xlcpupool
+
+=head1 DESCRIPTION
+
+To create a Cpupool with xl requires the provision of a cpupool config
+file.  Typically these live in `/etc/xen/CPUPOOL.cfg` where CPUPOOL is
+the name of the cpupool.
+
+=head1 SYNTAX
+
+A cpupool config file consists of a series of C<KEY=VALUE> pairs.
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any cpupool:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the cpupool.  Names of cpupools existing on a
+single host must be unique.
+
+=back
+
+=head2 Optional Configuration Items
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<sched="SCHED">
+
+Specifies the scheduler which is used for the cpupool. Valid
+values for C<SCHED> are:
+
+=over 4
+
+=item B<credit>
+
+the credit scheduler
+
+=item B<credit2>
+
+the credit2 scheduler
+
+=item B<sedf>
+
+the SEDF scheduler
+
+=back
+
+The default scheduler is the one used for C<Pool-0> specified as
+boot parameter of the hypervisor.
+
+=item B<nodes="NODES">
+
+Specifies the cpus of the NUMA-nodes given in C<NODES> (an integer or
+a list of integers) to be member of the cpupool. The free cpus in the
+specified nodes are allocated in the new cpupool.
+
+=item B<cpus="CPUS">
+
+The specified C<CPUS> are allocated in the new cpupool. All cpus must
+be free. Must not be specified together with B<nodes>.
+
+If neither B<nodes> nor B<cpus> are specified only the first free cpu
+found will be allocated in the new cpupool.
+
+=back
+
+=head1 FILES
+
+F</etc/xen/CPUPOOL.cfg>
+
+=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
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+

--===============8128120816759880489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8128120816759880489==--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:33:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxeyK-0006Oj-KH; Wed, 15 Feb 2012 13:32:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxeyI-0006Oe-Ou
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:32:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329312748!16803297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16954 invoked from network); 15 Feb 2012 13:32:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 13:32:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10716148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 13: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.213.0;
	Wed, 15 Feb 2012 13:32:29 +0000
Message-ID: <1329312746.31256.317.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Wed, 15 Feb 2012 13:32:26 +0000
In-Reply-To: <87D72459-4CF3-4942-9243-484F5E7780EF@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
	<87D72459-4CF3-4942-9243-484F5E7780EF@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 13:07 +0000, Justin T. Gibbs wrote:
> On Feb 13, 2012, at 5:35 AM, Ian Campbell wrote:
> > If someone has the freedom (or desire) to only implement one of the two
> > in their code base then that provides guidance as to which it should be,
> > at least then we will be encouraging the right trajectory. Also it gives
> > some small amount of ammunition to people who are stuck with a provider
> > (of either front or backend) of the wrong type for their environment and
> > helps break the stalemate as to who should fix their end (however
> > helpful that might be in practice).
> 
> Anyone care to flip a coin?

I think as the one who bothered to write things down you get that
honour ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:33:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxeyK-0006Oj-KH; Wed, 15 Feb 2012 13:32:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxeyI-0006Oe-Ou
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:32:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329312748!16803297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16954 invoked from network); 15 Feb 2012 13:32:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 13:32:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="10716148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 13: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.213.0;
	Wed, 15 Feb 2012 13:32:29 +0000
Message-ID: <1329312746.31256.317.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Wed, 15 Feb 2012 13:32:26 +0000
In-Reply-To: <87D72459-4CF3-4942-9243-484F5E7780EF@spectralogic.com>
References: <patchbomb.1328246658@ns1.eng.sldomain.com>
	<c3609ad53946fb9131d8.1328246662@ns1.eng.sldomain.com>
	<4F2BF04D0200007800070EA3@nat28.tlf.novell.com>
	<08A8A4D7-F18B-4218-B4C5-4B6CE99586B1@spectralogic.com>
	<1328780895.6133.134.camel@zakaz.uk.xensource.com>
	<4DD9249E-6A5D-4D7A-A011-EEAD65B530A7@spectralogic.com>
	<1329136547.31256.89.camel@zakaz.uk.xensource.com>
	<87D72459-4CF3-4942-9243-484F5E7780EF@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "<xen-devel@lists.xensource.com>" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 13:07 +0000, Justin T. Gibbs wrote:
> On Feb 13, 2012, at 5:35 AM, Ian Campbell wrote:
> > If someone has the freedom (or desire) to only implement one of the two
> > in their code base then that provides guidance as to which it should be,
> > at least then we will be encouraging the right trajectory. Also it gives
> > some small amount of ammunition to people who are stuck with a provider
> > (of either front or backend) of the wrong type for their environment and
> > helps break the stalemate as to who should fix their end (however
> > helpful that might be in practice).
> 
> Anyone care to flip a coin?

I think as the one who bothered to write things down you get that
honour ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:59:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxfOQ-0006zK-VN; Wed, 15 Feb 2012 13:59:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxfOQ-0006zA-Db
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:59:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329314367!14438131!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9025 invoked from network); 15 Feb 2012 13:59:28 -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;
	15 Feb 2012 13:59:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22030748"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 08:59:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 08:59:01 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FDwsue001016;
	Wed, 15 Feb 2012 05:58:55 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 14:03:28 +0000
Message-ID: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v3] arm: support fewer LR registers than virtual
	irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   61 ++++++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..520a400 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,51 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+    struct pending_irq *iter, *n;
+
+    spin_lock(&gic.lock);
+
+    if ( list_empty(&gic.lr_pending) )
+    {
+        for (i = 0; i < nr_lrs; i++) {
+            if (!test_and_set_bit(i, &gic.lr_mask))
+            {
+                gic_set_lr(i, virtual_irq, state, priority);
+                spin_unlock(&gic.lock);
+                return;
+            }
+        }
+    }
+
+    n = irq_to_pending(current, virtual_irq);
+    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->lr_link, &iter->lr_link);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+    list_add(&n->lr_link, &gic.lr_pending);
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -435,13 +475,25 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
+    for ( i = 0; i < nr_lrs; i++ ) {
         if ( eisr & ((uint64_t)1 << i) ) {
             struct pending_irq *p;
 
+            spin_lock(&gic.lock);
             lr = GICH[GICH_LR + i];
             virq = lr & GICH_LR_VIRTUAL_MASK;
             GICH[GICH_LR + i] = 0;
+            clear_bit(i, &gic.lr_mask);
+
+            if ( !list_empty(gic.lr_pending.next) ) {
+                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+                list_del_init(&p->lr_link);
+                set_bit(i, &gic.lr_mask);
+            } else {
+                gic_inject_irq_stop();
+            }
+            spin_unlock(&gic.lock);
 
             spin_lock(&current->arch.vgic.lock);
             p = irq_to_pending(current, virq);
@@ -449,7 +501,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            gic_inject_irq_stop();
             list_del(&p->link);
             INIT_LIST_HEAD(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:59:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxfOQ-0006zK-VN; Wed, 15 Feb 2012 13:59:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxfOQ-0006zA-Db
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:59:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329314367!14438131!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9025 invoked from network); 15 Feb 2012 13:59:28 -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;
	15 Feb 2012 13:59:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22030748"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 08:59:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 08:59:01 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FDwsue001016;
	Wed, 15 Feb 2012 05:58:55 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 14:03:28 +0000
Message-ID: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v3] arm: support fewer LR registers than virtual
	irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   61 ++++++++++++++++++++++++++++++++++++++---
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..520a400 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,51 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+    struct pending_irq *iter, *n;
+
+    spin_lock(&gic.lock);
+
+    if ( list_empty(&gic.lr_pending) )
+    {
+        for (i = 0; i < nr_lrs; i++) {
+            if (!test_and_set_bit(i, &gic.lr_mask))
+            {
+                gic_set_lr(i, virtual_irq, state, priority);
+                spin_unlock(&gic.lock);
+                return;
+            }
+        }
+    }
+
+    n = irq_to_pending(current, virtual_irq);
+    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->lr_link, &iter->lr_link);
+            spin_unlock(&gic.lock);
+            return;
+        }
+    }
+    list_add(&n->lr_link, &gic.lr_pending);
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -435,13 +475,25 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
+    for ( i = 0; i < nr_lrs; i++ ) {
         if ( eisr & ((uint64_t)1 << i) ) {
             struct pending_irq *p;
 
+            spin_lock(&gic.lock);
             lr = GICH[GICH_LR + i];
             virq = lr & GICH_LR_VIRTUAL_MASK;
             GICH[GICH_LR + i] = 0;
+            clear_bit(i, &gic.lr_mask);
+
+            if ( !list_empty(gic.lr_pending.next) ) {
+                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+                list_del_init(&p->lr_link);
+                set_bit(i, &gic.lr_mask);
+            } else {
+                gic_inject_irq_stop();
+            }
+            spin_unlock(&gic.lock);
 
             spin_lock(&current->arch.vgic.lock);
             p = irq_to_pending(current, virq);
@@ -449,7 +501,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            gic_inject_irq_stop();
             list_del(&p->link);
             INIT_LIST_HEAD(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:59:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxfOS-0006zZ-Cb; Wed, 15 Feb 2012 13:59:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxfOR-0006zB-3g
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:59:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329314367!14438131!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9051 invoked from network); 15 Feb 2012 13:59:29 -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;
	15 Feb 2012 13:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22030756"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 08:59:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 08:59:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FDwsuf001016;
	Wed, 15 Feb 2012 05:58:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 14:03:29 +0000
Message-ID: <1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH] arm: replace list_del and INIT_LIST_HEAD with
	list_del_init
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 520a400..c34661b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -501,8 +501,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            list_del(&p->link);
-            INIT_LIST_HEAD(&p->link);
+            list_del_init(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
             spin_unlock(&current->arch.vgic.lock);
         }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 13:59:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxfOS-0006zZ-Cb; Wed, 15 Feb 2012 13:59:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RxfOR-0006zB-3g
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 13:59:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329314367!14438131!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9051 invoked from network); 15 Feb 2012 13:59:29 -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;
	15 Feb 2012 13:59:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,423,1325480400"; d="scan'208";a="22030756"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 08:59:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 08:59:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FDwsuf001016;
	Wed, 15 Feb 2012 05:58:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 14:03:29 +0000
Message-ID: <1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH] arm: replace list_del and INIT_LIST_HEAD with
	list_del_init
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 520a400..c34661b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -501,8 +501,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
                 p->desc->status &= ~IRQ_INPROGRESS;
                 GICC[GICC_DIR] = virq;
             }
-            list_del(&p->link);
-            INIT_LIST_HEAD(&p->link);
+            list_del_init(&p->link);
             cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
             spin_unlock(&current->arch.vgic.lock);
         }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 14:59:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 14: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.xensource.com>)
	id 1RxgJl-0000jl-Bw; Wed, 15 Feb 2012 14:58: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 1RxgJi-0000jd-Q5
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 14:58:47 +0000
Received: from [85.158.139.83:13716] by server-5.bemta-5.messagelabs.com id
	8F/C3-13566-528CB3F4; Wed, 15 Feb 2012 14:58:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329317922!14566812!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25789 invoked from network); 15 Feb 2012 14:58:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 14:58:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 14:58:41 +0000
Message-Id: <4F3BD630020000780007330D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 14:58:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE4CA9D30.0__="
Subject: [Xen-devel] [PATCH] replace bogus gdprintk() uses with {, d}printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE4CA9D30.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When the subject domain is not the current one (e.g. during domctl or
HVM save/restore handling), use of gdprintk() is questionable at best,
as it won't give the intended information on what domain is affected.
Use plain printk() or dprintk() instead, but keep things (mostly) as
guest messages by using XENLOG_G_*.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -783,7 +783,8 @@ long arch_do_domctl(
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
-            gdprintk(XENLOG_ERR, "pt_irq_create_bind failed!\n");
+            printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for =
dom%d\n",
+                   ret, d->domain_id);
=20
     bind_out:
         rcu_unlock_domain(d);
@@ -812,7 +813,8 @@ long arch_do_domctl(
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
-            gdprintk(XENLOG_ERR, "pt_irq_destroy_bind failed!\n");
+            printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for =
dom%d\n",
+                   ret, d->domain_id);
=20
     unbind_out:
         rcu_unlock_domain(d);
@@ -849,9 +851,9 @@ long arch_do_domctl(
=20
         if ( add )
         {
-            gdprintk(XENLOG_INFO,
-                "memory_map:add: gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",
-                gfn, mfn, nr_mfns);
+            printk(XENLOG_G_INFO
+                   "memory_map:add: dom%d gfn=3D%lx mfn=3D%lx nr=3D%lx\n",=

+                   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++ )
@@ -859,9 +861,9 @@ long arch_do_domctl(
         }
         else
         {
-            gdprintk(XENLOG_INFO,
-                "memory_map:remove: gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",
-                 gfn, mfn, nr_mfns);
+            printk(XENLOG_G_INFO
+                   "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);
@@ -888,9 +890,9 @@ long arch_do_domctl(
         if ( (np =3D=3D 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) =
||
             ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
         {
-            gdprintk(XENLOG_ERR,
-                "ioport_map:invalid:gport=3D%x mport=3D%x nr_ports=3D%x\n"=
,
-                fgp, fmp, np);
+            printk(XENLOG_G_ERR
+                   "ioport_map:invalid:dom%d gport=3D%x mport=3D%x =
nr=3D%x\n",
+                   domctl->domain, fgp, fmp, np);
             break;
         }
=20
@@ -912,9 +914,9 @@ long arch_do_domctl(
         hd =3D domain_hvm_iommu(d);
         if ( add )
         {
-            gdprintk(XENLOG_INFO,
-                "ioport_map:add f_gport=3D%x f_mport=3D%x np=3D%x\n",
-                fgp, fmp, np);
+            printk(XENLOG_G_INFO
+                   "ioport_map:add: dom%d gport=3D%x mport=3D%x nr=3D%x\n"=
,
+                   d->domain_id, fgp, fmp, np);
=20
             list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
                 if (g2m_ioport->mport =3D=3D fmp )
@@ -936,9 +938,9 @@ long arch_do_domctl(
         }
         else
         {
-            gdprintk(XENLOG_INFO,
-                "ioport_map:remove f_gport=3D%x f_mport=3D%x np=3D%x\n",
-                fgp, fmp, np);
+            printk(XENLOG_G_INFO
+                   "ioport_map:remove: dom%d gport=3D%x mport=3D%x =
nr=3D%x\n",
+                   d->domain_id, fgp, fmp, np);
             list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
                 if ( g2m_ioport->mport =3D=3D fmp )
                 {
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -681,7 +681,8 @@ static int hvm_load_cpu_ctxt(struct doma
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%u has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
@@ -693,15 +694,15 @@ static int hvm_load_cpu_ctxt(struct doma
          !(ctxt.cr0 & X86_CR0_ET) ||
          ((ctxt.cr0 & (X86_CR0_PE|X86_CR0_PG)) =3D=3D X86_CR0_PG) )
     {
-        gdprintk(XENLOG_ERR, "HVM restore: bad CR0 0x%"PRIx64"\n",
-                 ctxt.cr0);
+        printk(XENLOG_G_ERR "HVM%d restore: bad CR0 %#" PRIx64 "\n",
+               d->domain_id, ctxt.cr0);
         return -EINVAL;
     }
=20
     if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS(v) )
     {
-        gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
-                 ctxt.cr4);
+        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" PRIx64 "\n",
+               d->domain_id, ctxt.cr4);
         return -EINVAL;
     }
=20
@@ -709,8 +710,8 @@ static int hvm_load_cpu_ctxt(struct doma
                    | EFER_NX | EFER_SCE;
     if ( !hvm_efer_valid(d, ctxt.msr_efer, efer_validbits) )
     {
-        gdprintk(XENLOG_ERR, "HVM restore: bad EFER 0x%"PRIx64"\n",
-                 ctxt.msr_efer);
+        printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
+               d->domain_id, ctxt.msr_efer);
         return -EINVAL;
     }
=20
@@ -889,7 +890,8 @@ static int hvm_load_cpu_xsave_states(str
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
@@ -901,25 +903,25 @@ static int hvm_load_cpu_xsave_states(str
     desc =3D (struct hvm_save_descriptor *)&h->data[h->cur];
     if ( sizeof (*desc) > h->size - h->cur)
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM restore: not enough data left to read descriptpr"
-                 "for type %u\n", CPU_XSAVE_CODE);
+        printk(XENLOG_G_WARNING
+               "HVM%d restore: not enough data left to read descriptor"
+               "for type %u\n", d->domain_id, CPU_XSAVE_CODE);
         return -1;
     }
     if ( desc->length + sizeof (*desc) > h->size - h->cur)
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM restore: not enough data left to read %u bytes "
-                 "for type %u\n", desc->length, CPU_XSAVE_CODE);
+        printk(XENLOG_G_WARNING
+               "HVM%d restore: not enough data left to read %u bytes "
+               "for type %u\n", d->domain_id, desc->length, CPU_XSAVE_CODE=
);
         return -1;
     }
     if ( CPU_XSAVE_CODE !=3D desc->typecode || (desc->length > HVM_CPU_XSA=
VE_SIZE) )
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM restore mismatch: expected type %u with max length =
%u, "
-                 "saw type %u length %u\n", CPU_XSAVE_CODE,
-                 (uint32_t)HVM_CPU_XSAVE_SIZE,
-                 desc->typecode, desc->length);
+        printk(XENLOG_G_WARNING
+               "HVM%d restore mismatch: expected type %u with max length =
%u, "
+               "saw type %u length %u\n", d->domain_id, CPU_XSAVE_CODE,
+               (unsigned int)HVM_CPU_XSAVE_SIZE,
+               desc->typecode, desc->length);
         return -1;
     }
     h->cur +=3D sizeof (*desc);
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -667,7 +667,8 @@ static int hvm_load_mtrr_msr(struct doma
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
--- a/xen/arch/x86/hvm/save.c
+++ b/xen/arch/x86/hvm/save.c
@@ -42,24 +42,24 @@ int arch_hvm_load(struct domain *d, stru
=20
     if ( hdr->magic !=3D HVM_FILE_MAGIC )
     {
-        gdprintk(XENLOG_ERR,=20
-                 "HVM restore: bad magic number %#"PRIx32"\n", hdr->magic)=
;
+        printk(XENLOG_G_ERR "HVM%d restore: bad magic number %#"PRIx32"\n"=
,
+               d->domain_id, hdr->magic);
         return -1;
     }
=20
     if ( hdr->version !=3D HVM_FILE_VERSION )
     {
-        gdprintk(XENLOG_ERR,=20
-                 "HVM restore: unsupported version %u\n", hdr->version);
+        printk(XENLOG_G_ERR "HVM%d restore: unsupported version %u\n",
+               d->domain_id, hdr->version);
         return -1;
     }
=20
     cpuid(1, &eax, &ebx, &ecx, &edx);
     /* CPUs ought to match but with feature-masking they might not */
     if ( (hdr->cpuid & ~0x0fUL) !=3D (eax & ~0x0fUL) )
-        gdprintk(XENLOG_INFO, "HVM restore (%u): VM saved on one CPU "
-                 "(%#"PRIx32") and restored on another (%#"PRIx32").\n",=
=20
-                 d->domain_id, hdr->cpuid, eax);
+        printk(XENLOG_G_INFO "HVM%d restore: VM saved on one CPU "
+               "(%#"PRIx32") and restored on another (%#"PRIx32").\n",
+               d->domain_id, hdr->cpuid, eax);
=20
     /* Restore guest's preferred TSC frequency. */
     if ( hdr->gtsc_khz )
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -448,7 +448,8 @@ static int viridian_load_vcpu_ctxt(struc
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1136,7 +1136,8 @@ static int lapic_load_hidden(struct doma
     vcpuid =3D hvm_load_instance(h);=20
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
     s =3D vcpu_vlapic(v);
@@ -1159,7 +1160,8 @@ static int lapic_load_regs(struct domain
     vcpuid =3D hvm_load_instance(h);=20
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
     s =3D vcpu_vlapic(v);
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1517,9 +1517,9 @@ int pirq_guest_bind(struct vcpu *v, stru
     {
         if ( desc->action !=3D NULL )
         {
-            gdprintk(XENLOG_INFO,
-                    "Cannot bind IRQ %d to guest. In use by '%s'.\n",
-                    pirq->pirq, desc->action->name);
+            printk(XENLOG_G_INFO
+                   "Cannot bind IRQ%d to dom%d. In use by '%s'.\n",
+                   pirq->pirq, v->domain->domain_id, desc->action->name);
             rc =3D -EBUSY;
             goto unlock_out;
         }
@@ -1531,9 +1531,9 @@ int pirq_guest_bind(struct vcpu *v, stru
                  zalloc_cpumask_var(&newaction->cpu_eoi_map) )
                 goto retry;
             xfree(newaction);
-            gdprintk(XENLOG_INFO,
-                     "Cannot bind IRQ %d to guest. Out of memory.\n",
-                     pirq->pirq);
+            printk(XENLOG_G_INFO
+                   "Cannot bind IRQ%d to dom%d. Out of memory.\n",
+                   pirq->pirq, v->domain->domain_id);
             rc =3D -ENOMEM;
             goto out;
         }
@@ -1558,11 +1558,10 @@ int pirq_guest_bind(struct vcpu *v, stru
     }
     else if ( !will_share || !action->shareable )
     {
-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. %s.\n",
-                 pirq->pirq,
-                 will_share ?
-                 "Others do not share" :
-                 "Will not share with others");
+        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. %s.\n",
+               pirq->pirq, v->domain->domain_id,
+               will_share ? "Others do not share"
+                          : "Will not share with others");
         rc =3D -EBUSY;
         goto unlock_out;
     }
@@ -1581,8 +1580,9 @@ int pirq_guest_bind(struct vcpu *v, stru
=20
     if ( action->nr_guests =3D=3D IRQ_MAX_GUESTS )
     {
-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. "
-               "Already at max share.\n", pirq->pirq);
+        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. "
+               "Already at max share.\n",
+               pirq->pirq, v->domain->domain_id);
         rc =3D -EBUSY;
         goto unlock_out;
     }
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -235,10 +235,10 @@ static int ppro_allocate_msr(struct vcpu
 	vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
 	return 1;
 out:
-        gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, =
oprofile is "
-                 "unavailable on domain %d vcpu %d.\n",
-                 v->vcpu_id, v->domain->domain_id);
-        return 0;
+	printk(XENLOG_G_WARNING "Insufficient memory for oprofile,"
+	       " oprofile is unavailable on dom%d vcpu%d\n",
+	       v->vcpu_id, v->domain->domain_id);
+	return 0;
 }
=20
 static void ppro_free_msr(struct vcpu *v)
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -945,8 +945,8 @@ int cpu_frequency_change(u64 freq)
     /* Sanity check: CPU frequency allegedly dropping below 1MHz? */
     if ( freq < 1000000u )
     {
-        gdprintk(XENLOG_WARNING, "Rejecting CPU frequency change "
-                 "to %"PRIu64" Hz.\n", freq);
+        printk(XENLOG_WARNING "Rejecting CPU frequency change "
+               "to %"PRIu64" Hz\n", freq);
         return -EINVAL;
     }
=20
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -108,8 +108,8 @@ int hvm_save_one(struct domain *d, uint1
=20
     if ( hvm_sr_handlers[typecode].save(d, &ctxt) !=3D 0 )
     {
-        gdprintk(XENLOG_ERR,=20
-                 "HVM save: failed to save type %"PRIu16"\n", typecode);
+        printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16"\n",=

+               d->domain_id, typecode);
         rv =3D -EFAULT;
     }
     else if ( copy_to_guest(handle,
@@ -149,7 +149,8 @@ int hvm_save(struct domain *d, hvm_domai
=20
     if ( hvm_save_entry(HEADER, 0, h, &hdr) !=3D 0 )
     {
-        gdprintk(XENLOG_ERR, "HVM save: failed to write header\n");
+        printk(XENLOG_G_ERR "HVM%d save: failed to write header\n",
+               d->domain_id);
         return -EFAULT;
     }=20
=20
@@ -159,11 +160,13 @@ int hvm_save(struct domain *d, hvm_domai
         handler =3D hvm_sr_handlers[i].save;
         if ( handler !=3D NULL )=20
         {
-            gdprintk(XENLOG_INFO, "HVM save: %s\n",  hvm_sr_handlers[i].na=
me);
+            printk(XENLOG_G_INFO "HVM%d save: %s\n",
+                   d->domain_id, hvm_sr_handlers[i].name);
             if ( handler(d, h) !=3D 0 )=20
             {
-                gdprintk(XENLOG_ERR,=20
-                         "HVM save: failed to save type %"PRIu16"\n", i);
+                printk(XENLOG_G_ERR
+                       "HVM%d save: failed to save type %"PRIu16"\n",
+                       d->domain_id, i);
                 return -EFAULT;
             }=20
         }
@@ -173,7 +176,8 @@ int hvm_save(struct domain *d, hvm_domai
     if ( hvm_save_entry(END, 0, h, &end) !=3D 0 )
     {
         /* Run out of data */
-        gdprintk(XENLOG_ERR, "HVM save: no room for end marker.\n");
+        printk(XENLOG_G_ERR "HVM%d save: no room for end marker\n",
+               d->domain_id);
         return -EFAULT;
     }
=20
@@ -209,8 +213,9 @@ int hvm_load(struct domain *d, hvm_domai
         if ( h->size - h->cur < sizeof(struct hvm_save_descriptor) )
         {
             /* Run out of data */
-            gdprintk(XENLOG_ERR,=20
-                     "HVM restore: save did not end with a null entry\n");=

+            printk(XENLOG_G_ERR
+                   "HVM%d restore: save did not end with a null entry\n",
+                   d->domain_id);
             return -1;
         }
        =20
@@ -223,20 +228,18 @@ int hvm_load(struct domain *d, hvm_domai
         if ( (desc->typecode > HVM_SAVE_CODE_MAX) ||
              ((handler =3D hvm_sr_handlers[desc->typecode].load) =3D=3D =
NULL) )
         {
-            gdprintk(XENLOG_ERR,=20
-                     "HVM restore: unknown entry typecode %u\n",=20
-                     desc->typecode);
+            printk(XENLOG_G_ERR "HVM%d restore: unknown entry typecode =
%u\n",
+                   d->domain_id, desc->typecode);
             return -1;
         }
=20
         /* Load the entry */
-        gdprintk(XENLOG_INFO, "HVM restore: %s %"PRIu16"\n", =20
-                 hvm_sr_handlers[desc->typecode].name, desc->instance);
+        printk(XENLOG_G_INFO "HVM%d restore: %s %"PRIu16"\n", d->domain_id=
,
+               hvm_sr_handlers[desc->typecode].name, desc->instance);
         if ( handler(d, h) !=3D 0 )=20
         {
-            gdprintk(XENLOG_ERR,=20
-                     "HVM restore: failed to load entry %u/%u\n",=20
-                     desc->typecode, desc->instance);
+            printk(XENLOG_G_ERR "HVM%d restore: failed to load entry =
%u/%u\n",
+                   d->domain_id, desc->typecode, desc->instance);
             return -1;
         }
     }
@@ -251,10 +254,9 @@ int _hvm_init_entry(struct hvm_domain_co
         =3D (struct hvm_save_descriptor *)&h->data[h->cur];
     if ( h->size - h->cur < len + sizeof (*d) )
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM save: no room for %"PRIu32" + %u bytes "
-                 "for typecode %"PRIu16"\n",
-                 len, (unsigned) sizeof (*d), tc);
+        printk(XENLOG_G_WARNING "HVM save: no room for"
+               " %"PRIu32" + %zu bytes for typecode %"PRIu16"\n",
+               len, sizeof(*d), tc);
         return -1;
     }
     d->typecode =3D tc;
@@ -278,17 +280,17 @@ int _hvm_check_entry(struct hvm_domain_c
         =3D (struct hvm_save_descriptor *)&h->data[h->cur];
     if ( len + sizeof (*d) > h->size - h->cur)
     {
-        gdprintk(XENLOG_WARNING,=20
-                 "HVM restore: not enough data left to read %u bytes "
-                 "for type %u\n", len, type);
+        printk(XENLOG_G_WARNING
+               "HVM restore: not enough data left to read %u bytes "
+               "for type %u\n", len, type);
         return -1;
     }   =20
     if ( (type !=3D d->typecode) || (len < d->length) ||
          (strict_length && (len !=3D d->length)) )
     {
-        gdprintk(XENLOG_WARNING,=20
-                 "HVM restore mismatch: expected type %u length %u, "
-                 "saw type %u length %u\n", type, len, d->typecode, =
d->length);
+        printk(XENLOG_G_WARNING
+               "HVM restore mismatch: expected type %u length %u, "
+               "saw type %u length %u\n", type, len, d->typecode, =
d->length);
         return -1;
     }
     h->cur +=3D sizeof(*d);
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -299,8 +299,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
                     ret =3D query_page_offline(pfn, ptr++);
                     break;
                 default:
-                    gdprintk(XENLOG_WARNING, "invalid page offline op =
%x\n",
-                            op->u.page_offline.cmd);
                     ret =3D -EINVAL;
                     break;
             }
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -144,8 +144,8 @@ share_xenoprof_page_with_guest(struct do
         struct page_info *page =3D mfn_to_page(mfn + i);
         if ( (page->count_info & (PGC_allocated|PGC_count_mask)) !=3D 0 )
         {
-            gdprintk(XENLOG_INFO, "mfn 0x%lx page->count_info 0x%lx\n",
-                     mfn + i, (unsigned long)page->count_info);
+            printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info =
%#lx\n",
+                   d->domain_id, mfn + i, page->count_info);
             return -EBUSY;
         }
         page_set_owner(page, NULL);
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -566,9 +566,9 @@ int iommu_do_domctl(
=20
         if ( device_assigned(seg, bus, devfn) )
         {
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: "
-                     "%04x:%02x:%02x.%u already assigned, or non-existent\=
n",
-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_INFO
+                   "%04x:%02x:%02x.%u already assigned, or non-existent\n"=
,
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
             ret =3D -EINVAL;
         }
         break;
@@ -576,8 +576,8 @@ int iommu_do_domctl(
     case XEN_DOMCTL_assign_device:
         if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) )
         {
-            gdprintk(XENLOG_ERR,
-                "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
+            printk(XENLOG_G_ERR
+                   "XEN_DOMCTL_assign_device: get_domain_by_id() =
failed\n");
             ret =3D -EINVAL;
             break;
         }
@@ -593,9 +593,9 @@ int iommu_do_domctl(
 #ifdef __ia64__ /* XXX Is this really needed? */
         if ( device_assigned(seg, bus, devfn) )
         {
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
-                     "%x:%x.%x already assigned, or non-existent\n",
-                     bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
+                   "%04x:%02x:%02x.%u already assigned, or non-existent\n"=
,
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
             ret =3D -EINVAL;
             goto assign_device_out;
         }
@@ -603,9 +603,10 @@ int iommu_do_domctl(
=20
         ret =3D assign_device(d, seg, bus, devfn);
         if ( ret )
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
-                     "assign device (%04x:%02x:%02x.%u) failed\n",
-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
+                   "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+                   d->domain_id, ret);
=20
     assign_device_out:
         put_domain(d);
@@ -614,8 +615,8 @@ int iommu_do_domctl(
     case XEN_DOMCTL_deassign_device:
         if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) )
         {
-            gdprintk(XENLOG_ERR,
-                "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n")=
;
+            printk(XENLOG_G_ERR
+                   "XEN_DOMCTL_deassign_device: get_domain_by_id() =
failed\n");
             ret =3D -EINVAL;
             break;
         }
@@ -640,9 +641,10 @@ int iommu_do_domctl(
         ret =3D deassign_device(d, seg, bus, devfn);
         spin_unlock(&pcidevs_lock);
         if ( ret )
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: "
-                     "deassign device (%04x:%02x:%02x.%u) failed\n",
-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_ERR
+                   "deassign %04x:%02x:%02x.%u from dom%d failed (%d)\n",
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+                   d->domain_id, ret);
=20
     deassign_device_out:
         put_domain(d);



--=__PartE4CA9D30.0__=
Content-Type: text/plain; name="gdprintk-bogus.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gdprintk-bogus.patch"

replace bogus gdprintk() uses with {,d}printk()=0A=0AWhen the subject =
domain is not the current one (e.g. during domctl or=0AHVM save/restore =
handling), use of gdprintk() is questionable at best,=0Aas it won't give =
the intended information on what domain is affected.=0AUse plain printk() =
or dprintk() instead, but keep things (mostly) as=0Aguest messages by =
using XENLOG_G_*.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/domctl.c=0A@@ -783,7 =
+783,8 @@ long arch_do_domctl(=0A             spin_unlock(&pcidevs_lock);=
=0A         }=0A         if ( ret < 0 )=0A-            gdprintk(XENLOG_ERR,=
 "pt_irq_create_bind failed!\n");=0A+            printk(XENLOG_G_ERR =
"pt_irq_create_bind failed (%ld) for dom%d\n",=0A+                   ret, =
d->domain_id);=0A =0A     bind_out:=0A         rcu_unlock_domain(d);=0A@@ =
-812,7 +813,8 @@ long arch_do_domctl(=0A             spin_unlock(&pcidevs_l=
ock);=0A         }=0A         if ( ret < 0 )=0A-            gdprintk(XENLOG=
_ERR, "pt_irq_destroy_bind failed!\n");=0A+            printk(XENLOG_G_ERR =
"pt_irq_destroy_bind failed (%ld) for dom%d\n",=0A+                   ret, =
d->domain_id);=0A =0A     unbind_out:=0A         rcu_unlock_domain(d);=0A@@=
 -849,9 +851,9 @@ long arch_do_domctl(=0A =0A         if ( add )=0A        =
 {=0A-            gdprintk(XENLOG_INFO,=0A-                "memory_map:add:=
 gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",=0A-                gfn, mfn, =
nr_mfns);=0A+            printk(XENLOG_G_INFO=0A+                   =
"memory_map:add: dom%d gfn=3D%lx mfn=3D%lx nr=3D%lx\n",=0A+                =
   d->domain_id, gfn, mfn, nr_mfns);=0A =0A             ret =3D iomem_permi=
t_access(d, mfn, mfn + nr_mfns - 1);=0A             for ( i =3D 0; i < =
nr_mfns; i++ )=0A@@ -859,9 +861,9 @@ long arch_do_domctl(=0A         }=0A  =
       else=0A         {=0A-            gdprintk(XENLOG_INFO,=0A-          =
      "memory_map:remove: gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",=0A-        =
         gfn, mfn, nr_mfns);=0A+            printk(XENLOG_G_INFO=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@@ -888,9 +890,9 @@ long arch_do_domctl(=0A         if ( (np =
=3D=3D 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||=0A             =
((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )=0A         =
{=0A-            gdprintk(XENLOG_ERR,=0A-                "ioport_map:invali=
d:gport=3D%x mport=3D%x nr_ports=3D%x\n",=0A-                fgp, fmp, =
np);=0A+            printk(XENLOG_G_ERR=0A+                   "ioport_map:i=
nvalid:dom%d gport=3D%x mport=3D%x nr=3D%x\n",=0A+                   =
domctl->domain, fgp, fmp, np);=0A             break;=0A         }=0A =0A@@ =
-912,9 +914,9 @@ long arch_do_domctl(=0A         hd =3D domain_hvm_iommu(d)=
;=0A         if ( add )=0A         {=0A-            gdprintk(XENLOG_INFO,=
=0A-                "ioport_map:add f_gport=3D%x f_mport=3D%x np=3D%x\n",=
=0A-                fgp, fmp, np);=0A+            printk(XENLOG_G_INFO=0A+ =
                  "ioport_map:add: dom%d gport=3D%x mport=3D%x nr=3D%x\n",=
=0A+                   d->domain_id, fgp, fmp, np);=0A =0A             =
list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)=0A             =
    if (g2m_ioport->mport =3D=3D fmp )=0A@@ -936,9 +938,9 @@ long =
arch_do_domctl(=0A         }=0A         else=0A         {=0A-            =
gdprintk(XENLOG_INFO,=0A-                "ioport_map:remove f_gport=3D%x =
f_mport=3D%x np=3D%x\n",=0A-                fgp, fmp, np);=0A+            =
printk(XENLOG_G_INFO=0A+                   "ioport_map:remove: dom%d =
gport=3D%x mport=3D%x nr=3D%x\n",=0A+                   d->domain_id, fgp, =
fmp, np);=0A             list_for_each_entry(g2m_ioport, &hd->g2m_ioport_li=
st, list)=0A                 if ( g2m_ioport->mport =3D=3D fmp )=0A        =
         {=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c=0A=
@@ -681,7 +681,8 @@ static int hvm_load_cpu_ctxt(struct doma=0A     vcpuid =
=3D hvm_load_instance(h);=0A     if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_ERR, =
"HVM restore: domain has no vcpu %u\n", vcpuid);=0A+        dprintk(XENLOG_=
G_ERR, "HVM restore: dom%u has no vcpu%u\n",=0A+                d->domain_i=
d, vcpuid);=0A         return -EINVAL;=0A     }=0A =0A@@ -693,15 +694,15 =
@@ static int hvm_load_cpu_ctxt(struct doma=0A          !(ctxt.cr0 & =
X86_CR0_ET) ||=0A          ((ctxt.cr0 & (X86_CR0_PE|X86_CR0_PG)) =3D=3D =
X86_CR0_PG) )=0A     {=0A-        gdprintk(XENLOG_ERR, "HVM restore: bad =
CR0 0x%"PRIx64"\n",=0A-                 ctxt.cr0);=0A+        printk(XENLOG=
_G_ERR "HVM%d restore: bad CR0 %#" PRIx64 "\n",=0A+               =
d->domain_id, ctxt.cr0);=0A         return -EINVAL;=0A     }=0A =0A     if =
( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS(v) )=0A     {=0A-        =
gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",=0A-             =
    ctxt.cr4);=0A+        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" =
PRIx64 "\n",=0A+               d->domain_id, ctxt.cr4);=0A         return =
-EINVAL;=0A     }=0A =0A@@ -709,8 +710,8 @@ static int hvm_load_cpu_ctxt(st=
ruct doma=0A                    | EFER_NX | EFER_SCE;=0A     if ( =
!hvm_efer_valid(d, ctxt.msr_efer, efer_validbits) )=0A     {=0A-        =
gdprintk(XENLOG_ERR, "HVM restore: bad EFER 0x%"PRIx64"\n",=0A-            =
     ctxt.msr_efer);=0A+        printk(XENLOG_G_ERR "HVM%d restore: bad =
EFER %#" PRIx64 "\n",=0A+               d->domain_id, ctxt.msr_efer);=0A   =
      return -EINVAL;=0A     }=0A =0A@@ -889,7 +890,8 @@ static int =
hvm_load_cpu_xsave_states(str=0A     vcpuid =3D hvm_load_instance(h);=0A   =
  if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)=0A     {=0A-        gdprintk(XENLOG_ERR, "HVM restore: domain has no =
vcpu %u\n", vcpuid);=0A+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d =
has no vcpu%u\n",=0A+                d->domain_id, vcpuid);=0A         =
return -EINVAL;=0A     }=0A =0A@@ -901,25 +903,25 @@ static int hvm_load_cp=
u_xsave_states(str=0A     desc =3D (struct hvm_save_descriptor *)&h->data[h=
->cur];=0A     if ( sizeof (*desc) > h->size - h->cur)=0A     {=0A-        =
gdprintk(XENLOG_WARNING,=0A-                 "HVM restore: not enough data =
left to read descriptpr"=0A-                 "for type %u\n", CPU_XSAVE_COD=
E);=0A+        printk(XENLOG_G_WARNING=0A+               "HVM%d restore: =
not enough data left to read descriptor"=0A+               "for type =
%u\n", d->domain_id, CPU_XSAVE_CODE);=0A         return -1;=0A     }=0A    =
 if ( desc->length + sizeof (*desc) > h->size - h->cur)=0A     {=0A-       =
 gdprintk(XENLOG_WARNING,=0A-                 "HVM restore: not enough =
data left to read %u bytes "=0A-                 "for type %u\n", =
desc->length, CPU_XSAVE_CODE);=0A+        printk(XENLOG_G_WARNING=0A+      =
         "HVM%d restore: not enough data left to read %u bytes "=0A+       =
        "for type %u\n", d->domain_id, desc->length, CPU_XSAVE_CODE);=0A   =
      return -1;=0A     }=0A     if ( CPU_XSAVE_CODE !=3D desc->typecode =
|| (desc->length > HVM_CPU_XSAVE_SIZE) )=0A     {=0A-        gdprintk(XENLO=
G_WARNING,=0A-                 "HVM restore mismatch: expected type %u =
with max length %u, "=0A-                 "saw type %u length %u\n", =
CPU_XSAVE_CODE,=0A-                 (uint32_t)HVM_CPU_XSAVE_SIZE,=0A-      =
           desc->typecode, desc->length);=0A+        printk(XENLOG_G_WARNIN=
G=0A+               "HVM%d restore mismatch: expected type %u with max =
length %u, "=0A+               "saw type %u length %u\n", d->domain_id, =
CPU_XSAVE_CODE,=0A+               (unsigned int)HVM_CPU_XSAVE_SIZE,=0A+    =
           desc->typecode, desc->length);=0A         return -1;=0A     =
}=0A     h->cur +=3D sizeof (*desc);=0A--- a/xen/arch/x86/hvm/mtrr.c=0A+++ =
b/xen/arch/x86/hvm/mtrr.c=0A@@ -667,7 +667,8 @@ static int hvm_load_mtrr_ms=
r(struct doma=0A     vcpuid =3D hvm_load_instance(h);=0A     if ( vcpuid =
>=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-    =
    gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);=0A+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no =
vcpu%u\n",=0A+                d->domain_id, vcpuid);=0A         return =
-EINVAL;=0A     }=0A =0A--- a/xen/arch/x86/hvm/save.c=0A+++ b/xen/arch/x86/=
hvm/save.c=0A@@ -42,24 +42,24 @@ int arch_hvm_load(struct domain *d, =
stru=0A =0A     if ( hdr->magic !=3D HVM_FILE_MAGIC )=0A     {=0A-        =
gdprintk(XENLOG_ERR, =0A-                 "HVM restore: bad magic number =
%#"PRIx32"\n", hdr->magic);=0A+        printk(XENLOG_G_ERR "HVM%d restore: =
bad magic number %#"PRIx32"\n",=0A+               d->domain_id, hdr->magic)=
;=0A         return -1;=0A     }=0A =0A     if ( hdr->version !=3D =
HVM_FILE_VERSION )=0A     {=0A-        gdprintk(XENLOG_ERR, =0A-           =
      "HVM restore: unsupported version %u\n", hdr->version);=0A+        =
printk(XENLOG_G_ERR "HVM%d restore: unsupported version %u\n",=0A+         =
      d->domain_id, hdr->version);=0A         return -1;=0A     }=0A =0A   =
  cpuid(1, &eax, &ebx, &ecx, &edx);=0A     /* CPUs ought to match but with =
feature-masking they might not */=0A     if ( (hdr->cpuid & ~0x0fUL) !=3D =
(eax & ~0x0fUL) )=0A-        gdprintk(XENLOG_INFO, "HVM restore (%u): VM =
saved on one CPU "=0A-                 "(%#"PRIx32") and restored on =
another (%#"PRIx32").\n", =0A-                 d->domain_id, hdr->cpuid, =
eax);=0A+        printk(XENLOG_G_INFO "HVM%d restore: VM saved on one CPU =
"=0A+               "(%#"PRIx32") and restored on another (%#"PRIx32").\n",=
=0A+               d->domain_id, hdr->cpuid, eax);=0A =0A     /* Restore =
guest's preferred TSC frequency. */=0A     if ( hdr->gtsc_khz )=0A--- =
a/xen/arch/x86/hvm/viridian.c=0A+++ b/xen/arch/x86/hvm/viridian.c=0A@@ =
-448,7 +448,8 @@ static int viridian_load_vcpu_ctxt(struc=0A     vcpuid =
=3D hvm_load_instance(h);=0A     if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_ERR, =
"HVM restore: domain has no vcpu %u\n", vcpuid);=0A+        dprintk(XENLOG_=
G_ERR, "HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_i=
d, vcpuid);=0A         return -EINVAL;=0A     }=0A =0A--- a/xen/arch/x86/hv=
m/vlapic.c=0A+++ b/xen/arch/x86/hvm/vlapic.c=0A@@ -1136,7 +1136,8 @@ =
static int lapic_load_hidden(struct doma=0A     vcpuid =3D hvm_load_instanc=
e(h); =0A     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =
=3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_ERR, "HVM restore: =
domain has no vlapic %u\n", vcpuid);=0A+        dprintk(XENLOG_G_ERR, "HVM =
restore: dom%d has no apic%u\n",=0A+                d->domain_id, =
vcpuid);=0A         return -EINVAL;=0A     }=0A     s =3D vcpu_vlapic(v);=
=0A@@ -1159,7 +1160,8 @@ static int lapic_load_regs(struct domain=0A     =
vcpuid =3D hvm_load_instance(h); =0A     if ( vcpuid >=3D d->max_vcpus || =
(v =3D d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_E=
RR, "HVM restore: domain has no vlapic %u\n", vcpuid);=0A+        =
dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",=0A+            =
    d->domain_id, vcpuid);=0A         return -EINVAL;=0A     }=0A     s =
=3D vcpu_vlapic(v);=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=
=0A@@ -1517,9 +1517,9 @@ int pirq_guest_bind(struct vcpu *v, stru=0A     =
{=0A         if ( desc->action !=3D NULL )=0A         {=0A-            =
gdprintk(XENLOG_INFO,=0A-                    "Cannot bind IRQ %d to guest. =
In use by '%s'.\n",=0A-                    pirq->pirq, desc->action->name);=
=0A+            printk(XENLOG_G_INFO=0A+                   "Cannot bind =
IRQ%d to dom%d. In use by '%s'.\n",=0A+                   pirq->pirq, =
v->domain->domain_id, desc->action->name);=0A             rc =3D -EBUSY;=0A=
             goto unlock_out;=0A         }=0A@@ -1531,9 +1531,9 @@ int =
pirq_guest_bind(struct vcpu *v, stru=0A                  zalloc_cpumask_var=
(&newaction->cpu_eoi_map) )=0A                 goto retry;=0A             =
xfree(newaction);=0A-            gdprintk(XENLOG_INFO,=0A-                 =
    "Cannot bind IRQ %d to guest. Out of memory.\n",=0A-                   =
  pirq->pirq);=0A+            printk(XENLOG_G_INFO=0A+                   =
"Cannot bind IRQ%d to dom%d. Out of memory.\n",=0A+                   =
pirq->pirq, v->domain->domain_id);=0A             rc =3D -ENOMEM;=0A       =
      goto out;=0A         }=0A@@ -1558,11 +1558,10 @@ int pirq_guest_bind(=
struct vcpu *v, stru=0A     }=0A     else if ( !will_share || !action->shar=
eable )=0A     {=0A-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to =
guest. %s.\n",=0A-                 pirq->pirq,=0A-                 =
will_share ?=0A-                 "Others do not share" :=0A-               =
  "Will not share with others");=0A+        printk(XENLOG_G_INFO "Cannot =
bind IRQ%d to dom%d. %s.\n",=0A+               pirq->pirq, v->domain->domai=
n_id,=0A+               will_share ? "Others do not share"=0A+             =
             : "Will not share with others");=0A         rc =3D -EBUSY;=0A =
        goto unlock_out;=0A     }=0A@@ -1581,8 +1580,9 @@ int pirq_guest_bi=
nd(struct vcpu *v, stru=0A =0A     if ( action->nr_guests =3D=3D IRQ_MAX_GU=
ESTS )=0A     {=0A-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to =
guest. "=0A-               "Already at max share.\n", pirq->pirq);=0A+     =
   printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. "=0A+               =
"Already at max share.\n",=0A+               pirq->pirq, v->domain->domain_=
id);=0A         rc =3D -EBUSY;=0A         goto unlock_out;=0A     }=0A--- =
a/xen/arch/x86/oprofile/op_model_ppro.c=0A+++ b/xen/arch/x86/oprofile/op_mo=
del_ppro.c=0A@@ -235,10 +235,10 @@ static int ppro_allocate_msr(struct =
vcpu=0A 	vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);=0A 	=
return 1;=0A out:=0A-        gdprintk(XENLOG_WARNING, "Insufficient memory =
for oprofile, oprofile is "=0A-                 "unavailable on domain %d =
vcpu %d.\n",=0A-                 v->vcpu_id, v->domain->domain_id);=0A-    =
    return 0;=0A+	printk(XENLOG_G_WARNING "Insufficient memory for =
oprofile,"=0A+	       " oprofile is unavailable on dom%d vcpu%d\n",=0A+	=
       v->vcpu_id, v->domain->domain_id);=0A+	return 0;=0A }=0A =0A =
static void ppro_free_msr(struct vcpu *v)=0A--- a/xen/arch/x86/time.c=0A+++=
 b/xen/arch/x86/time.c=0A@@ -945,8 +945,8 @@ int cpu_frequency_change(u64 =
freq)=0A     /* Sanity check: CPU frequency allegedly dropping below 1MHz? =
*/=0A     if ( freq < 1000000u )=0A     {=0A-        gdprintk(XENLOG_WARNIN=
G, "Rejecting CPU frequency change "=0A-                 "to %"PRIu64" =
Hz.\n", freq);=0A+        printk(XENLOG_WARNING "Rejecting CPU frequency =
change "=0A+               "to %"PRIu64" Hz\n", freq);=0A         return =
-EINVAL;=0A     }=0A =0A--- a/xen/common/hvm/save.c=0A+++ b/xen/common/hvm/=
save.c=0A@@ -108,8 +108,8 @@ int hvm_save_one(struct domain *d, uint1=0A =
=0A     if ( hvm_sr_handlers[typecode].save(d, &ctxt) !=3D 0 )=0A     =
{=0A-        gdprintk(XENLOG_ERR, =0A-                 "HVM save: failed =
to save type %"PRIu16"\n", typecode);=0A+        printk(XENLOG_G_ERR =
"HVM%d save: failed to save type %"PRIu16"\n",=0A+               d->domain_=
id, typecode);=0A         rv =3D -EFAULT;=0A     }=0A     else if ( =
copy_to_guest(handle,=0A@@ -149,7 +149,8 @@ int hvm_save(struct domain *d, =
hvm_domai=0A =0A     if ( hvm_save_entry(HEADER, 0, h, &hdr) !=3D 0 )=0A   =
  {=0A-        gdprintk(XENLOG_ERR, "HVM save: failed to write header\n");=
=0A+        printk(XENLOG_G_ERR "HVM%d save: failed to write header\n",=0A+=
               d->domain_id);=0A         return -EFAULT;=0A     } =0A =
=0A@@ -159,11 +160,13 @@ int hvm_save(struct domain *d, hvm_domai=0A       =
  handler =3D hvm_sr_handlers[i].save;=0A         if ( handler !=3D NULL ) =
=0A         {=0A-            gdprintk(XENLOG_INFO, "HVM save: %s\n",  =
hvm_sr_handlers[i].name);=0A+            printk(XENLOG_G_INFO "HVM%d save: =
%s\n",=0A+                   d->domain_id, hvm_sr_handlers[i].name);=0A    =
         if ( handler(d, h) !=3D 0 ) =0A             {=0A-                =
gdprintk(XENLOG_ERR, =0A-                         "HVM save: failed to =
save type %"PRIu16"\n", i);=0A+                printk(XENLOG_G_ERR=0A+     =
                  "HVM%d save: failed to save type %"PRIu16"\n",=0A+       =
                d->domain_id, i);=0A                 return -EFAULT;=0A    =
         } =0A         }=0A@@ -173,7 +176,8 @@ int hvm_save(struct domain =
*d, hvm_domai=0A     if ( hvm_save_entry(END, 0, h, &end) !=3D 0 )=0A     =
{=0A         /* Run out of data */=0A-        gdprintk(XENLOG_ERR, "HVM =
save: no room for end marker.\n");=0A+        printk(XENLOG_G_ERR "HVM%d =
save: no room for end marker\n",=0A+               d->domain_id);=0A       =
  return -EFAULT;=0A     }=0A =0A@@ -209,8 +213,9 @@ int hvm_load(struct =
domain *d, hvm_domai=0A         if ( h->size - h->cur < sizeof(struct =
hvm_save_descriptor) )=0A         {=0A             /* Run out of data =
*/=0A-            gdprintk(XENLOG_ERR, =0A-                     "HVM =
restore: save did not end with a null entry\n");=0A+            printk(XENL=
OG_G_ERR=0A+                   "HVM%d restore: save did not end with a =
null entry\n",=0A+                   d->domain_id);=0A             return =
-1;=0A         }=0A         =0A@@ -223,20 +228,18 @@ int hvm_load(struct =
domain *d, hvm_domai=0A         if ( (desc->typecode > HVM_SAVE_CODE_MAX) =
||=0A              ((handler =3D hvm_sr_handlers[desc->typecode].load) =
=3D=3D NULL) )=0A         {=0A-            gdprintk(XENLOG_ERR, =0A-       =
              "HVM restore: unknown entry typecode %u\n", =0A-             =
        desc->typecode);=0A+            printk(XENLOG_G_ERR "HVM%d =
restore: unknown entry typecode %u\n",=0A+                   d->domain_id, =
desc->typecode);=0A             return -1;=0A         }=0A =0A         /* =
Load the entry */=0A-        gdprintk(XENLOG_INFO, "HVM restore: %s =
%"PRIu16"\n",  =0A-                 hvm_sr_handlers[desc->typecode].name, =
desc->instance);=0A+        printk(XENLOG_G_INFO "HVM%d restore: %s =
%"PRIu16"\n", d->domain_id,=0A+               hvm_sr_handlers[desc->typecod=
e].name, desc->instance);=0A         if ( handler(d, h) !=3D 0 ) =0A       =
  {=0A-            gdprintk(XENLOG_ERR, =0A-                     "HVM =
restore: failed to load entry %u/%u\n", =0A-                     desc->type=
code, desc->instance);=0A+            printk(XENLOG_G_ERR "HVM%d restore: =
failed to load entry %u/%u\n",=0A+                   d->domain_id, =
desc->typecode, desc->instance);=0A             return -1;=0A         }=0A =
    }=0A@@ -251,10 +254,9 @@ int _hvm_init_entry(struct hvm_domain_co=0A   =
      =3D (struct hvm_save_descriptor *)&h->data[h->cur];=0A     if ( =
h->size - h->cur < len + sizeof (*d) )=0A     {=0A-        gdprintk(XENLOG_=
WARNING,=0A-                 "HVM save: no room for %"PRIu32" + %u bytes =
"=0A-                 "for typecode %"PRIu16"\n",=0A-                 len, =
(unsigned) sizeof (*d), tc);=0A+        printk(XENLOG_G_WARNING "HVM save: =
no room for"=0A+               " %"PRIu32" + %zu bytes for typecode =
%"PRIu16"\n",=0A+               len, sizeof(*d), tc);=0A         return =
-1;=0A     }=0A     d->typecode =3D tc;=0A@@ -278,17 +280,17 @@ int =
_hvm_check_entry(struct hvm_domain_c=0A         =3D (struct hvm_save_descri=
ptor *)&h->data[h->cur];=0A     if ( len + sizeof (*d) > h->size - =
h->cur)=0A     {=0A-        gdprintk(XENLOG_WARNING, =0A-                 =
"HVM restore: not enough data left to read %u bytes "=0A-                 =
"for type %u\n", len, type);=0A+        printk(XENLOG_G_WARNING=0A+        =
       "HVM restore: not enough data left to read %u bytes "=0A+           =
    "for type %u\n", len, type);=0A         return -1;=0A     }    =0A     =
if ( (type !=3D d->typecode) || (len < d->length) ||=0A          (strict_le=
ngth && (len !=3D d->length)) )=0A     {=0A-        gdprintk(XENLOG_WARNING=
, =0A-                 "HVM restore mismatch: expected type %u length %u, =
"=0A-                 "saw type %u length %u\n", type, len, d->typecode, =
d->length);=0A+        printk(XENLOG_G_WARNING=0A+               "HVM =
restore mismatch: expected type %u length %u, "=0A+               "saw =
type %u length %u\n", type, len, d->typecode, d->length);=0A         =
return -1;=0A     }=0A     h->cur +=3D sizeof(*d);=0A--- a/xen/common/sysct=
l.c=0A+++ b/xen/common/sysctl.c=0A@@ -299,8 +299,6 @@ long do_sysctl(XEN_GU=
EST_HANDLE(xen_sysc=0A                     ret =3D query_page_offline(pfn, =
ptr++);=0A                     break;=0A                 default:=0A-      =
              gdprintk(XENLOG_WARNING, "invalid page offline op %x\n",=0A- =
                           op->u.page_offline.cmd);=0A                     =
ret =3D -EINVAL;=0A                     break;=0A             }=0A--- =
a/xen/common/xenoprof.c=0A+++ b/xen/common/xenoprof.c=0A@@ -144,8 +144,8 =
@@ share_xenoprof_page_with_guest(struct do=0A         struct page_info =
*page =3D mfn_to_page(mfn + i);=0A         if ( (page->count_info & =
(PGC_allocated|PGC_count_mask)) !=3D 0 )=0A         {=0A-            =
gdprintk(XENLOG_INFO, "mfn 0x%lx page->count_info 0x%lx\n",=0A-            =
         mfn + i, (unsigned long)page->count_info);=0A+            =
printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n",=0A+         =
          d->domain_id, mfn + i, page->count_info);=0A             return =
-EBUSY;=0A         }=0A         page_set_owner(page, NULL);=0A--- =
a/xen/drivers/passthrough/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=
=0A@@ -566,9 +566,9 @@ int iommu_do_domctl(=0A =0A         if ( device_assi=
gned(seg, bus, devfn) )=0A         {=0A-            gdprintk(XENLOG_ERR, =
"XEN_DOMCTL_test_assign_device: "=0A-                     "%04x:%02x:%02x.%=
u already assigned, or non-existent\n",=0A-                     seg, bus, =
PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+            printk(XENLOG_G_INFO=0A+ =
                  "%04x:%02x:%02x.%u already assigned, or non-existent\n",=
=0A+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A     =
        ret =3D -EINVAL;=0A         }=0A         break;=0A@@ -576,8 +576,8 =
@@ int iommu_do_domctl(=0A     case XEN_DOMCTL_assign_device:=0A         =
if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A   =
      {=0A-            gdprintk(XENLOG_ERR,=0A-                "XEN_DOMCTL_=
assign_device: get_domain_by_id() failed\n");=0A+            printk(XENLOG_=
G_ERR=0A+                   "XEN_DOMCTL_assign_device: get_domain_by_id() =
failed\n");=0A             ret =3D -EINVAL;=0A             break;=0A       =
  }=0A@@ -593,9 +593,9 @@ int iommu_do_domctl(=0A #ifdef __ia64__ /* XXX =
Is this really needed? */=0A         if ( device_assigned(seg, bus, devfn) =
)=0A         {=0A-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_devic=
e: "=0A-                     "%x:%x.%x already assigned, or non-existent\n"=
,=0A-                     bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+      =
      printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "=0A+                 =
  "%04x:%02x:%02x.%u already assigned, or non-existent\n",=0A+             =
      seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A             ret =3D =
-EINVAL;=0A             goto assign_device_out;=0A         }=0A@@ -603,9 =
+603,10 @@ int iommu_do_domctl(=0A =0A         ret =3D assign_device(d, =
seg, bus, devfn);=0A         if ( ret )=0A-            gdprintk(XENLOG_ERR,=
 "XEN_DOMCTL_assign_device: "=0A-                     "assign device =
(%04x:%02x:%02x.%u) failed\n",=0A-                     seg, bus, PCI_SLOT(d=
evfn), PCI_FUNC(devfn));=0A+            printk(XENLOG_G_ERR "XEN_DOMCTL_ass=
ign_device: "=0A+                   "assign %04x:%02x:%02x.%u to dom%d =
failed (%d)\n",=0A+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(d=
evfn),=0A+                   d->domain_id, ret);=0A =0A     assign_device_o=
ut:=0A         put_domain(d);=0A@@ -614,8 +615,8 @@ int iommu_do_domctl(=0A=
     case XEN_DOMCTL_deassign_device:=0A         if ( unlikely((d =3D =
get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A         {=0A-          =
  gdprintk(XENLOG_ERR,=0A-                "XEN_DOMCTL_deassign_device: =
get_domain_by_id() failed\n");=0A+            printk(XENLOG_G_ERR=0A+      =
             "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");=0A=
             ret =3D -EINVAL;=0A             break;=0A         }=0A@@ =
-640,9 +641,10 @@ int iommu_do_domctl(=0A         ret =3D deassign_device(d=
, seg, bus, devfn);=0A         spin_unlock(&pcidevs_lock);=0A         if ( =
ret )=0A-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: =
"=0A-                     "deassign device (%04x:%02x:%02x.%u) failed\n",=
=0A-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+  =
          printk(XENLOG_G_ERR=0A+                   "deassign %04x:%02x:%02=
x.%u from dom%d failed (%d)\n",=0A+                   seg, bus, PCI_SLOT(de=
vfn), PCI_FUNC(devfn),=0A+                   d->domain_id, ret);=0A =0A    =
 deassign_device_out:=0A         put_domain(d);=0A
--=__PartE4CA9D30.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartE4CA9D30.0__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 14:59:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 14: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.xensource.com>)
	id 1RxgJl-0000jl-Bw; Wed, 15 Feb 2012 14:58: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 1RxgJi-0000jd-Q5
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 14:58:47 +0000
Received: from [85.158.139.83:13716] by server-5.bemta-5.messagelabs.com id
	8F/C3-13566-528CB3F4; Wed, 15 Feb 2012 14:58:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329317922!14566812!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25789 invoked from network); 15 Feb 2012 14:58:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 14:58:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 14:58:41 +0000
Message-Id: <4F3BD630020000780007330D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 14:58:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE4CA9D30.0__="
Subject: [Xen-devel] [PATCH] replace bogus gdprintk() uses with {, d}printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE4CA9D30.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When the subject domain is not the current one (e.g. during domctl or
HVM save/restore handling), use of gdprintk() is questionable at best,
as it won't give the intended information on what domain is affected.
Use plain printk() or dprintk() instead, but keep things (mostly) as
guest messages by using XENLOG_G_*.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -783,7 +783,8 @@ long arch_do_domctl(
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
-            gdprintk(XENLOG_ERR, "pt_irq_create_bind failed!\n");
+            printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for =
dom%d\n",
+                   ret, d->domain_id);
=20
     bind_out:
         rcu_unlock_domain(d);
@@ -812,7 +813,8 @@ long arch_do_domctl(
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
-            gdprintk(XENLOG_ERR, "pt_irq_destroy_bind failed!\n");
+            printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for =
dom%d\n",
+                   ret, d->domain_id);
=20
     unbind_out:
         rcu_unlock_domain(d);
@@ -849,9 +851,9 @@ long arch_do_domctl(
=20
         if ( add )
         {
-            gdprintk(XENLOG_INFO,
-                "memory_map:add: gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",
-                gfn, mfn, nr_mfns);
+            printk(XENLOG_G_INFO
+                   "memory_map:add: dom%d gfn=3D%lx mfn=3D%lx nr=3D%lx\n",=

+                   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++ )
@@ -859,9 +861,9 @@ long arch_do_domctl(
         }
         else
         {
-            gdprintk(XENLOG_INFO,
-                "memory_map:remove: gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",
-                 gfn, mfn, nr_mfns);
+            printk(XENLOG_G_INFO
+                   "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);
@@ -888,9 +890,9 @@ long arch_do_domctl(
         if ( (np =3D=3D 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) =
||
             ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
         {
-            gdprintk(XENLOG_ERR,
-                "ioport_map:invalid:gport=3D%x mport=3D%x nr_ports=3D%x\n"=
,
-                fgp, fmp, np);
+            printk(XENLOG_G_ERR
+                   "ioport_map:invalid:dom%d gport=3D%x mport=3D%x =
nr=3D%x\n",
+                   domctl->domain, fgp, fmp, np);
             break;
         }
=20
@@ -912,9 +914,9 @@ long arch_do_domctl(
         hd =3D domain_hvm_iommu(d);
         if ( add )
         {
-            gdprintk(XENLOG_INFO,
-                "ioport_map:add f_gport=3D%x f_mport=3D%x np=3D%x\n",
-                fgp, fmp, np);
+            printk(XENLOG_G_INFO
+                   "ioport_map:add: dom%d gport=3D%x mport=3D%x nr=3D%x\n"=
,
+                   d->domain_id, fgp, fmp, np);
=20
             list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
                 if (g2m_ioport->mport =3D=3D fmp )
@@ -936,9 +938,9 @@ long arch_do_domctl(
         }
         else
         {
-            gdprintk(XENLOG_INFO,
-                "ioport_map:remove f_gport=3D%x f_mport=3D%x np=3D%x\n",
-                fgp, fmp, np);
+            printk(XENLOG_G_INFO
+                   "ioport_map:remove: dom%d gport=3D%x mport=3D%x =
nr=3D%x\n",
+                   d->domain_id, fgp, fmp, np);
             list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
                 if ( g2m_ioport->mport =3D=3D fmp )
                 {
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -681,7 +681,8 @@ static int hvm_load_cpu_ctxt(struct doma
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%u has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
@@ -693,15 +694,15 @@ static int hvm_load_cpu_ctxt(struct doma
          !(ctxt.cr0 & X86_CR0_ET) ||
          ((ctxt.cr0 & (X86_CR0_PE|X86_CR0_PG)) =3D=3D X86_CR0_PG) )
     {
-        gdprintk(XENLOG_ERR, "HVM restore: bad CR0 0x%"PRIx64"\n",
-                 ctxt.cr0);
+        printk(XENLOG_G_ERR "HVM%d restore: bad CR0 %#" PRIx64 "\n",
+               d->domain_id, ctxt.cr0);
         return -EINVAL;
     }
=20
     if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS(v) )
     {
-        gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
-                 ctxt.cr4);
+        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" PRIx64 "\n",
+               d->domain_id, ctxt.cr4);
         return -EINVAL;
     }
=20
@@ -709,8 +710,8 @@ static int hvm_load_cpu_ctxt(struct doma
                    | EFER_NX | EFER_SCE;
     if ( !hvm_efer_valid(d, ctxt.msr_efer, efer_validbits) )
     {
-        gdprintk(XENLOG_ERR, "HVM restore: bad EFER 0x%"PRIx64"\n",
-                 ctxt.msr_efer);
+        printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
+               d->domain_id, ctxt.msr_efer);
         return -EINVAL;
     }
=20
@@ -889,7 +890,8 @@ static int hvm_load_cpu_xsave_states(str
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
@@ -901,25 +903,25 @@ static int hvm_load_cpu_xsave_states(str
     desc =3D (struct hvm_save_descriptor *)&h->data[h->cur];
     if ( sizeof (*desc) > h->size - h->cur)
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM restore: not enough data left to read descriptpr"
-                 "for type %u\n", CPU_XSAVE_CODE);
+        printk(XENLOG_G_WARNING
+               "HVM%d restore: not enough data left to read descriptor"
+               "for type %u\n", d->domain_id, CPU_XSAVE_CODE);
         return -1;
     }
     if ( desc->length + sizeof (*desc) > h->size - h->cur)
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM restore: not enough data left to read %u bytes "
-                 "for type %u\n", desc->length, CPU_XSAVE_CODE);
+        printk(XENLOG_G_WARNING
+               "HVM%d restore: not enough data left to read %u bytes "
+               "for type %u\n", d->domain_id, desc->length, CPU_XSAVE_CODE=
);
         return -1;
     }
     if ( CPU_XSAVE_CODE !=3D desc->typecode || (desc->length > HVM_CPU_XSA=
VE_SIZE) )
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM restore mismatch: expected type %u with max length =
%u, "
-                 "saw type %u length %u\n", CPU_XSAVE_CODE,
-                 (uint32_t)HVM_CPU_XSAVE_SIZE,
-                 desc->typecode, desc->length);
+        printk(XENLOG_G_WARNING
+               "HVM%d restore mismatch: expected type %u with max length =
%u, "
+               "saw type %u length %u\n", d->domain_id, CPU_XSAVE_CODE,
+               (unsigned int)HVM_CPU_XSAVE_SIZE,
+               desc->typecode, desc->length);
         return -1;
     }
     h->cur +=3D sizeof (*desc);
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -667,7 +667,8 @@ static int hvm_load_mtrr_msr(struct doma
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
--- a/xen/arch/x86/hvm/save.c
+++ b/xen/arch/x86/hvm/save.c
@@ -42,24 +42,24 @@ int arch_hvm_load(struct domain *d, stru
=20
     if ( hdr->magic !=3D HVM_FILE_MAGIC )
     {
-        gdprintk(XENLOG_ERR,=20
-                 "HVM restore: bad magic number %#"PRIx32"\n", hdr->magic)=
;
+        printk(XENLOG_G_ERR "HVM%d restore: bad magic number %#"PRIx32"\n"=
,
+               d->domain_id, hdr->magic);
         return -1;
     }
=20
     if ( hdr->version !=3D HVM_FILE_VERSION )
     {
-        gdprintk(XENLOG_ERR,=20
-                 "HVM restore: unsupported version %u\n", hdr->version);
+        printk(XENLOG_G_ERR "HVM%d restore: unsupported version %u\n",
+               d->domain_id, hdr->version);
         return -1;
     }
=20
     cpuid(1, &eax, &ebx, &ecx, &edx);
     /* CPUs ought to match but with feature-masking they might not */
     if ( (hdr->cpuid & ~0x0fUL) !=3D (eax & ~0x0fUL) )
-        gdprintk(XENLOG_INFO, "HVM restore (%u): VM saved on one CPU "
-                 "(%#"PRIx32") and restored on another (%#"PRIx32").\n",=
=20
-                 d->domain_id, hdr->cpuid, eax);
+        printk(XENLOG_G_INFO "HVM%d restore: VM saved on one CPU "
+               "(%#"PRIx32") and restored on another (%#"PRIx32").\n",
+               d->domain_id, hdr->cpuid, eax);
=20
     /* Restore guest's preferred TSC frequency. */
     if ( hdr->gtsc_khz )
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -448,7 +448,8 @@ static int viridian_load_vcpu_ctxt(struc
     vcpuid =3D hvm_load_instance(h);
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
=20
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1136,7 +1136,8 @@ static int lapic_load_hidden(struct doma
     vcpuid =3D hvm_load_instance(h);=20
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
     s =3D vcpu_vlapic(v);
@@ -1159,7 +1160,8 @@ static int lapic_load_regs(struct domain
     vcpuid =3D hvm_load_instance(h);=20
     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
     {
-        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n", =
vcpuid);
+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
+                d->domain_id, vcpuid);
         return -EINVAL;
     }
     s =3D vcpu_vlapic(v);
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1517,9 +1517,9 @@ int pirq_guest_bind(struct vcpu *v, stru
     {
         if ( desc->action !=3D NULL )
         {
-            gdprintk(XENLOG_INFO,
-                    "Cannot bind IRQ %d to guest. In use by '%s'.\n",
-                    pirq->pirq, desc->action->name);
+            printk(XENLOG_G_INFO
+                   "Cannot bind IRQ%d to dom%d. In use by '%s'.\n",
+                   pirq->pirq, v->domain->domain_id, desc->action->name);
             rc =3D -EBUSY;
             goto unlock_out;
         }
@@ -1531,9 +1531,9 @@ int pirq_guest_bind(struct vcpu *v, stru
                  zalloc_cpumask_var(&newaction->cpu_eoi_map) )
                 goto retry;
             xfree(newaction);
-            gdprintk(XENLOG_INFO,
-                     "Cannot bind IRQ %d to guest. Out of memory.\n",
-                     pirq->pirq);
+            printk(XENLOG_G_INFO
+                   "Cannot bind IRQ%d to dom%d. Out of memory.\n",
+                   pirq->pirq, v->domain->domain_id);
             rc =3D -ENOMEM;
             goto out;
         }
@@ -1558,11 +1558,10 @@ int pirq_guest_bind(struct vcpu *v, stru
     }
     else if ( !will_share || !action->shareable )
     {
-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. %s.\n",
-                 pirq->pirq,
-                 will_share ?
-                 "Others do not share" :
-                 "Will not share with others");
+        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. %s.\n",
+               pirq->pirq, v->domain->domain_id,
+               will_share ? "Others do not share"
+                          : "Will not share with others");
         rc =3D -EBUSY;
         goto unlock_out;
     }
@@ -1581,8 +1580,9 @@ int pirq_guest_bind(struct vcpu *v, stru
=20
     if ( action->nr_guests =3D=3D IRQ_MAX_GUESTS )
     {
-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. "
-               "Already at max share.\n", pirq->pirq);
+        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. "
+               "Already at max share.\n",
+               pirq->pirq, v->domain->domain_id);
         rc =3D -EBUSY;
         goto unlock_out;
     }
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -235,10 +235,10 @@ static int ppro_allocate_msr(struct vcpu
 	vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
 	return 1;
 out:
-        gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, =
oprofile is "
-                 "unavailable on domain %d vcpu %d.\n",
-                 v->vcpu_id, v->domain->domain_id);
-        return 0;
+	printk(XENLOG_G_WARNING "Insufficient memory for oprofile,"
+	       " oprofile is unavailable on dom%d vcpu%d\n",
+	       v->vcpu_id, v->domain->domain_id);
+	return 0;
 }
=20
 static void ppro_free_msr(struct vcpu *v)
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -945,8 +945,8 @@ int cpu_frequency_change(u64 freq)
     /* Sanity check: CPU frequency allegedly dropping below 1MHz? */
     if ( freq < 1000000u )
     {
-        gdprintk(XENLOG_WARNING, "Rejecting CPU frequency change "
-                 "to %"PRIu64" Hz.\n", freq);
+        printk(XENLOG_WARNING "Rejecting CPU frequency change "
+               "to %"PRIu64" Hz\n", freq);
         return -EINVAL;
     }
=20
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -108,8 +108,8 @@ int hvm_save_one(struct domain *d, uint1
=20
     if ( hvm_sr_handlers[typecode].save(d, &ctxt) !=3D 0 )
     {
-        gdprintk(XENLOG_ERR,=20
-                 "HVM save: failed to save type %"PRIu16"\n", typecode);
+        printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16"\n",=

+               d->domain_id, typecode);
         rv =3D -EFAULT;
     }
     else if ( copy_to_guest(handle,
@@ -149,7 +149,8 @@ int hvm_save(struct domain *d, hvm_domai
=20
     if ( hvm_save_entry(HEADER, 0, h, &hdr) !=3D 0 )
     {
-        gdprintk(XENLOG_ERR, "HVM save: failed to write header\n");
+        printk(XENLOG_G_ERR "HVM%d save: failed to write header\n",
+               d->domain_id);
         return -EFAULT;
     }=20
=20
@@ -159,11 +160,13 @@ int hvm_save(struct domain *d, hvm_domai
         handler =3D hvm_sr_handlers[i].save;
         if ( handler !=3D NULL )=20
         {
-            gdprintk(XENLOG_INFO, "HVM save: %s\n",  hvm_sr_handlers[i].na=
me);
+            printk(XENLOG_G_INFO "HVM%d save: %s\n",
+                   d->domain_id, hvm_sr_handlers[i].name);
             if ( handler(d, h) !=3D 0 )=20
             {
-                gdprintk(XENLOG_ERR,=20
-                         "HVM save: failed to save type %"PRIu16"\n", i);
+                printk(XENLOG_G_ERR
+                       "HVM%d save: failed to save type %"PRIu16"\n",
+                       d->domain_id, i);
                 return -EFAULT;
             }=20
         }
@@ -173,7 +176,8 @@ int hvm_save(struct domain *d, hvm_domai
     if ( hvm_save_entry(END, 0, h, &end) !=3D 0 )
     {
         /* Run out of data */
-        gdprintk(XENLOG_ERR, "HVM save: no room for end marker.\n");
+        printk(XENLOG_G_ERR "HVM%d save: no room for end marker\n",
+               d->domain_id);
         return -EFAULT;
     }
=20
@@ -209,8 +213,9 @@ int hvm_load(struct domain *d, hvm_domai
         if ( h->size - h->cur < sizeof(struct hvm_save_descriptor) )
         {
             /* Run out of data */
-            gdprintk(XENLOG_ERR,=20
-                     "HVM restore: save did not end with a null entry\n");=

+            printk(XENLOG_G_ERR
+                   "HVM%d restore: save did not end with a null entry\n",
+                   d->domain_id);
             return -1;
         }
        =20
@@ -223,20 +228,18 @@ int hvm_load(struct domain *d, hvm_domai
         if ( (desc->typecode > HVM_SAVE_CODE_MAX) ||
              ((handler =3D hvm_sr_handlers[desc->typecode].load) =3D=3D =
NULL) )
         {
-            gdprintk(XENLOG_ERR,=20
-                     "HVM restore: unknown entry typecode %u\n",=20
-                     desc->typecode);
+            printk(XENLOG_G_ERR "HVM%d restore: unknown entry typecode =
%u\n",
+                   d->domain_id, desc->typecode);
             return -1;
         }
=20
         /* Load the entry */
-        gdprintk(XENLOG_INFO, "HVM restore: %s %"PRIu16"\n", =20
-                 hvm_sr_handlers[desc->typecode].name, desc->instance);
+        printk(XENLOG_G_INFO "HVM%d restore: %s %"PRIu16"\n", d->domain_id=
,
+               hvm_sr_handlers[desc->typecode].name, desc->instance);
         if ( handler(d, h) !=3D 0 )=20
         {
-            gdprintk(XENLOG_ERR,=20
-                     "HVM restore: failed to load entry %u/%u\n",=20
-                     desc->typecode, desc->instance);
+            printk(XENLOG_G_ERR "HVM%d restore: failed to load entry =
%u/%u\n",
+                   d->domain_id, desc->typecode, desc->instance);
             return -1;
         }
     }
@@ -251,10 +254,9 @@ int _hvm_init_entry(struct hvm_domain_co
         =3D (struct hvm_save_descriptor *)&h->data[h->cur];
     if ( h->size - h->cur < len + sizeof (*d) )
     {
-        gdprintk(XENLOG_WARNING,
-                 "HVM save: no room for %"PRIu32" + %u bytes "
-                 "for typecode %"PRIu16"\n",
-                 len, (unsigned) sizeof (*d), tc);
+        printk(XENLOG_G_WARNING "HVM save: no room for"
+               " %"PRIu32" + %zu bytes for typecode %"PRIu16"\n",
+               len, sizeof(*d), tc);
         return -1;
     }
     d->typecode =3D tc;
@@ -278,17 +280,17 @@ int _hvm_check_entry(struct hvm_domain_c
         =3D (struct hvm_save_descriptor *)&h->data[h->cur];
     if ( len + sizeof (*d) > h->size - h->cur)
     {
-        gdprintk(XENLOG_WARNING,=20
-                 "HVM restore: not enough data left to read %u bytes "
-                 "for type %u\n", len, type);
+        printk(XENLOG_G_WARNING
+               "HVM restore: not enough data left to read %u bytes "
+               "for type %u\n", len, type);
         return -1;
     }   =20
     if ( (type !=3D d->typecode) || (len < d->length) ||
          (strict_length && (len !=3D d->length)) )
     {
-        gdprintk(XENLOG_WARNING,=20
-                 "HVM restore mismatch: expected type %u length %u, "
-                 "saw type %u length %u\n", type, len, d->typecode, =
d->length);
+        printk(XENLOG_G_WARNING
+               "HVM restore mismatch: expected type %u length %u, "
+               "saw type %u length %u\n", type, len, d->typecode, =
d->length);
         return -1;
     }
     h->cur +=3D sizeof(*d);
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -299,8 +299,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
                     ret =3D query_page_offline(pfn, ptr++);
                     break;
                 default:
-                    gdprintk(XENLOG_WARNING, "invalid page offline op =
%x\n",
-                            op->u.page_offline.cmd);
                     ret =3D -EINVAL;
                     break;
             }
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -144,8 +144,8 @@ share_xenoprof_page_with_guest(struct do
         struct page_info *page =3D mfn_to_page(mfn + i);
         if ( (page->count_info & (PGC_allocated|PGC_count_mask)) !=3D 0 )
         {
-            gdprintk(XENLOG_INFO, "mfn 0x%lx page->count_info 0x%lx\n",
-                     mfn + i, (unsigned long)page->count_info);
+            printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info =
%#lx\n",
+                   d->domain_id, mfn + i, page->count_info);
             return -EBUSY;
         }
         page_set_owner(page, NULL);
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -566,9 +566,9 @@ int iommu_do_domctl(
=20
         if ( device_assigned(seg, bus, devfn) )
         {
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: "
-                     "%04x:%02x:%02x.%u already assigned, or non-existent\=
n",
-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_INFO
+                   "%04x:%02x:%02x.%u already assigned, or non-existent\n"=
,
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
             ret =3D -EINVAL;
         }
         break;
@@ -576,8 +576,8 @@ int iommu_do_domctl(
     case XEN_DOMCTL_assign_device:
         if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) )
         {
-            gdprintk(XENLOG_ERR,
-                "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
+            printk(XENLOG_G_ERR
+                   "XEN_DOMCTL_assign_device: get_domain_by_id() =
failed\n");
             ret =3D -EINVAL;
             break;
         }
@@ -593,9 +593,9 @@ int iommu_do_domctl(
 #ifdef __ia64__ /* XXX Is this really needed? */
         if ( device_assigned(seg, bus, devfn) )
         {
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
-                     "%x:%x.%x already assigned, or non-existent\n",
-                     bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
+                   "%04x:%02x:%02x.%u already assigned, or non-existent\n"=
,
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
             ret =3D -EINVAL;
             goto assign_device_out;
         }
@@ -603,9 +603,10 @@ int iommu_do_domctl(
=20
         ret =3D assign_device(d, seg, bus, devfn);
         if ( ret )
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
-                     "assign device (%04x:%02x:%02x.%u) failed\n",
-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
+                   "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+                   d->domain_id, ret);
=20
     assign_device_out:
         put_domain(d);
@@ -614,8 +615,8 @@ int iommu_do_domctl(
     case XEN_DOMCTL_deassign_device:
         if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) )
         {
-            gdprintk(XENLOG_ERR,
-                "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n")=
;
+            printk(XENLOG_G_ERR
+                   "XEN_DOMCTL_deassign_device: get_domain_by_id() =
failed\n");
             ret =3D -EINVAL;
             break;
         }
@@ -640,9 +641,10 @@ int iommu_do_domctl(
         ret =3D deassign_device(d, seg, bus, devfn);
         spin_unlock(&pcidevs_lock);
         if ( ret )
-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: "
-                     "deassign device (%04x:%02x:%02x.%u) failed\n",
-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+            printk(XENLOG_G_ERR
+                   "deassign %04x:%02x:%02x.%u from dom%d failed (%d)\n",
+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+                   d->domain_id, ret);
=20
     deassign_device_out:
         put_domain(d);



--=__PartE4CA9D30.0__=
Content-Type: text/plain; name="gdprintk-bogus.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gdprintk-bogus.patch"

replace bogus gdprintk() uses with {,d}printk()=0A=0AWhen the subject =
domain is not the current one (e.g. during domctl or=0AHVM save/restore =
handling), use of gdprintk() is questionable at best,=0Aas it won't give =
the intended information on what domain is affected.=0AUse plain printk() =
or dprintk() instead, but keep things (mostly) as=0Aguest messages by =
using XENLOG_G_*.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/domctl.c=0A@@ -783,7 =
+783,8 @@ long arch_do_domctl(=0A             spin_unlock(&pcidevs_lock);=
=0A         }=0A         if ( ret < 0 )=0A-            gdprintk(XENLOG_ERR,=
 "pt_irq_create_bind failed!\n");=0A+            printk(XENLOG_G_ERR =
"pt_irq_create_bind failed (%ld) for dom%d\n",=0A+                   ret, =
d->domain_id);=0A =0A     bind_out:=0A         rcu_unlock_domain(d);=0A@@ =
-812,7 +813,8 @@ long arch_do_domctl(=0A             spin_unlock(&pcidevs_l=
ock);=0A         }=0A         if ( ret < 0 )=0A-            gdprintk(XENLOG=
_ERR, "pt_irq_destroy_bind failed!\n");=0A+            printk(XENLOG_G_ERR =
"pt_irq_destroy_bind failed (%ld) for dom%d\n",=0A+                   ret, =
d->domain_id);=0A =0A     unbind_out:=0A         rcu_unlock_domain(d);=0A@@=
 -849,9 +851,9 @@ long arch_do_domctl(=0A =0A         if ( add )=0A        =
 {=0A-            gdprintk(XENLOG_INFO,=0A-                "memory_map:add:=
 gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",=0A-                gfn, mfn, =
nr_mfns);=0A+            printk(XENLOG_G_INFO=0A+                   =
"memory_map:add: dom%d gfn=3D%lx mfn=3D%lx nr=3D%lx\n",=0A+                =
   d->domain_id, gfn, mfn, nr_mfns);=0A =0A             ret =3D iomem_permi=
t_access(d, mfn, mfn + nr_mfns - 1);=0A             for ( i =3D 0; i < =
nr_mfns; i++ )=0A@@ -859,9 +861,9 @@ long arch_do_domctl(=0A         }=0A  =
       else=0A         {=0A-            gdprintk(XENLOG_INFO,=0A-          =
      "memory_map:remove: gfn=3D%lx mfn=3D%lx nr_mfns=3D%lx\n",=0A-        =
         gfn, mfn, nr_mfns);=0A+            printk(XENLOG_G_INFO=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@@ -888,9 +890,9 @@ long arch_do_domctl(=0A         if ( (np =
=3D=3D 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||=0A             =
((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )=0A         =
{=0A-            gdprintk(XENLOG_ERR,=0A-                "ioport_map:invali=
d:gport=3D%x mport=3D%x nr_ports=3D%x\n",=0A-                fgp, fmp, =
np);=0A+            printk(XENLOG_G_ERR=0A+                   "ioport_map:i=
nvalid:dom%d gport=3D%x mport=3D%x nr=3D%x\n",=0A+                   =
domctl->domain, fgp, fmp, np);=0A             break;=0A         }=0A =0A@@ =
-912,9 +914,9 @@ long arch_do_domctl(=0A         hd =3D domain_hvm_iommu(d)=
;=0A         if ( add )=0A         {=0A-            gdprintk(XENLOG_INFO,=
=0A-                "ioport_map:add f_gport=3D%x f_mport=3D%x np=3D%x\n",=
=0A-                fgp, fmp, np);=0A+            printk(XENLOG_G_INFO=0A+ =
                  "ioport_map:add: dom%d gport=3D%x mport=3D%x nr=3D%x\n",=
=0A+                   d->domain_id, fgp, fmp, np);=0A =0A             =
list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)=0A             =
    if (g2m_ioport->mport =3D=3D fmp )=0A@@ -936,9 +938,9 @@ long =
arch_do_domctl(=0A         }=0A         else=0A         {=0A-            =
gdprintk(XENLOG_INFO,=0A-                "ioport_map:remove f_gport=3D%x =
f_mport=3D%x np=3D%x\n",=0A-                fgp, fmp, np);=0A+            =
printk(XENLOG_G_INFO=0A+                   "ioport_map:remove: dom%d =
gport=3D%x mport=3D%x nr=3D%x\n",=0A+                   d->domain_id, fgp, =
fmp, np);=0A             list_for_each_entry(g2m_ioport, &hd->g2m_ioport_li=
st, list)=0A                 if ( g2m_ioport->mport =3D=3D fmp )=0A        =
         {=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c=0A=
@@ -681,7 +681,8 @@ static int hvm_load_cpu_ctxt(struct doma=0A     vcpuid =
=3D hvm_load_instance(h);=0A     if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_ERR, =
"HVM restore: domain has no vcpu %u\n", vcpuid);=0A+        dprintk(XENLOG_=
G_ERR, "HVM restore: dom%u has no vcpu%u\n",=0A+                d->domain_i=
d, vcpuid);=0A         return -EINVAL;=0A     }=0A =0A@@ -693,15 +694,15 =
@@ static int hvm_load_cpu_ctxt(struct doma=0A          !(ctxt.cr0 & =
X86_CR0_ET) ||=0A          ((ctxt.cr0 & (X86_CR0_PE|X86_CR0_PG)) =3D=3D =
X86_CR0_PG) )=0A     {=0A-        gdprintk(XENLOG_ERR, "HVM restore: bad =
CR0 0x%"PRIx64"\n",=0A-                 ctxt.cr0);=0A+        printk(XENLOG=
_G_ERR "HVM%d restore: bad CR0 %#" PRIx64 "\n",=0A+               =
d->domain_id, ctxt.cr0);=0A         return -EINVAL;=0A     }=0A =0A     if =
( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS(v) )=0A     {=0A-        =
gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",=0A-             =
    ctxt.cr4);=0A+        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" =
PRIx64 "\n",=0A+               d->domain_id, ctxt.cr4);=0A         return =
-EINVAL;=0A     }=0A =0A@@ -709,8 +710,8 @@ static int hvm_load_cpu_ctxt(st=
ruct doma=0A                    | EFER_NX | EFER_SCE;=0A     if ( =
!hvm_efer_valid(d, ctxt.msr_efer, efer_validbits) )=0A     {=0A-        =
gdprintk(XENLOG_ERR, "HVM restore: bad EFER 0x%"PRIx64"\n",=0A-            =
     ctxt.msr_efer);=0A+        printk(XENLOG_G_ERR "HVM%d restore: bad =
EFER %#" PRIx64 "\n",=0A+               d->domain_id, ctxt.msr_efer);=0A   =
      return -EINVAL;=0A     }=0A =0A@@ -889,7 +890,8 @@ static int =
hvm_load_cpu_xsave_states(str=0A     vcpuid =3D hvm_load_instance(h);=0A   =
  if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)=0A     {=0A-        gdprintk(XENLOG_ERR, "HVM restore: domain has no =
vcpu %u\n", vcpuid);=0A+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d =
has no vcpu%u\n",=0A+                d->domain_id, vcpuid);=0A         =
return -EINVAL;=0A     }=0A =0A@@ -901,25 +903,25 @@ static int hvm_load_cp=
u_xsave_states(str=0A     desc =3D (struct hvm_save_descriptor *)&h->data[h=
->cur];=0A     if ( sizeof (*desc) > h->size - h->cur)=0A     {=0A-        =
gdprintk(XENLOG_WARNING,=0A-                 "HVM restore: not enough data =
left to read descriptpr"=0A-                 "for type %u\n", CPU_XSAVE_COD=
E);=0A+        printk(XENLOG_G_WARNING=0A+               "HVM%d restore: =
not enough data left to read descriptor"=0A+               "for type =
%u\n", d->domain_id, CPU_XSAVE_CODE);=0A         return -1;=0A     }=0A    =
 if ( desc->length + sizeof (*desc) > h->size - h->cur)=0A     {=0A-       =
 gdprintk(XENLOG_WARNING,=0A-                 "HVM restore: not enough =
data left to read %u bytes "=0A-                 "for type %u\n", =
desc->length, CPU_XSAVE_CODE);=0A+        printk(XENLOG_G_WARNING=0A+      =
         "HVM%d restore: not enough data left to read %u bytes "=0A+       =
        "for type %u\n", d->domain_id, desc->length, CPU_XSAVE_CODE);=0A   =
      return -1;=0A     }=0A     if ( CPU_XSAVE_CODE !=3D desc->typecode =
|| (desc->length > HVM_CPU_XSAVE_SIZE) )=0A     {=0A-        gdprintk(XENLO=
G_WARNING,=0A-                 "HVM restore mismatch: expected type %u =
with max length %u, "=0A-                 "saw type %u length %u\n", =
CPU_XSAVE_CODE,=0A-                 (uint32_t)HVM_CPU_XSAVE_SIZE,=0A-      =
           desc->typecode, desc->length);=0A+        printk(XENLOG_G_WARNIN=
G=0A+               "HVM%d restore mismatch: expected type %u with max =
length %u, "=0A+               "saw type %u length %u\n", d->domain_id, =
CPU_XSAVE_CODE,=0A+               (unsigned int)HVM_CPU_XSAVE_SIZE,=0A+    =
           desc->typecode, desc->length);=0A         return -1;=0A     =
}=0A     h->cur +=3D sizeof (*desc);=0A--- a/xen/arch/x86/hvm/mtrr.c=0A+++ =
b/xen/arch/x86/hvm/mtrr.c=0A@@ -667,7 +667,8 @@ static int hvm_load_mtrr_ms=
r(struct doma=0A     vcpuid =3D hvm_load_instance(h);=0A     if ( vcpuid =
>=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-    =
    gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);=0A+        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no =
vcpu%u\n",=0A+                d->domain_id, vcpuid);=0A         return =
-EINVAL;=0A     }=0A =0A--- a/xen/arch/x86/hvm/save.c=0A+++ b/xen/arch/x86/=
hvm/save.c=0A@@ -42,24 +42,24 @@ int arch_hvm_load(struct domain *d, =
stru=0A =0A     if ( hdr->magic !=3D HVM_FILE_MAGIC )=0A     {=0A-        =
gdprintk(XENLOG_ERR, =0A-                 "HVM restore: bad magic number =
%#"PRIx32"\n", hdr->magic);=0A+        printk(XENLOG_G_ERR "HVM%d restore: =
bad magic number %#"PRIx32"\n",=0A+               d->domain_id, hdr->magic)=
;=0A         return -1;=0A     }=0A =0A     if ( hdr->version !=3D =
HVM_FILE_VERSION )=0A     {=0A-        gdprintk(XENLOG_ERR, =0A-           =
      "HVM restore: unsupported version %u\n", hdr->version);=0A+        =
printk(XENLOG_G_ERR "HVM%d restore: unsupported version %u\n",=0A+         =
      d->domain_id, hdr->version);=0A         return -1;=0A     }=0A =0A   =
  cpuid(1, &eax, &ebx, &ecx, &edx);=0A     /* CPUs ought to match but with =
feature-masking they might not */=0A     if ( (hdr->cpuid & ~0x0fUL) !=3D =
(eax & ~0x0fUL) )=0A-        gdprintk(XENLOG_INFO, "HVM restore (%u): VM =
saved on one CPU "=0A-                 "(%#"PRIx32") and restored on =
another (%#"PRIx32").\n", =0A-                 d->domain_id, hdr->cpuid, =
eax);=0A+        printk(XENLOG_G_INFO "HVM%d restore: VM saved on one CPU =
"=0A+               "(%#"PRIx32") and restored on another (%#"PRIx32").\n",=
=0A+               d->domain_id, hdr->cpuid, eax);=0A =0A     /* Restore =
guest's preferred TSC frequency. */=0A     if ( hdr->gtsc_khz )=0A--- =
a/xen/arch/x86/hvm/viridian.c=0A+++ b/xen/arch/x86/hvm/viridian.c=0A@@ =
-448,7 +448,8 @@ static int viridian_load_vcpu_ctxt(struc=0A     vcpuid =
=3D hvm_load_instance(h);=0A     if ( vcpuid >=3D d->max_vcpus || (v =3D =
d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_ERR, =
"HVM restore: domain has no vcpu %u\n", vcpuid);=0A+        dprintk(XENLOG_=
G_ERR, "HVM restore: dom%d has no vcpu%u\n",=0A+                d->domain_i=
d, vcpuid);=0A         return -EINVAL;=0A     }=0A =0A--- a/xen/arch/x86/hv=
m/vlapic.c=0A+++ b/xen/arch/x86/hvm/vlapic.c=0A@@ -1136,7 +1136,8 @@ =
static int lapic_load_hidden(struct doma=0A     vcpuid =3D hvm_load_instanc=
e(h); =0A     if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =
=3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_ERR, "HVM restore: =
domain has no vlapic %u\n", vcpuid);=0A+        dprintk(XENLOG_G_ERR, "HVM =
restore: dom%d has no apic%u\n",=0A+                d->domain_id, =
vcpuid);=0A         return -EINVAL;=0A     }=0A     s =3D vcpu_vlapic(v);=
=0A@@ -1159,7 +1160,8 @@ static int lapic_load_regs(struct domain=0A     =
vcpuid =3D hvm_load_instance(h); =0A     if ( vcpuid >=3D d->max_vcpus || =
(v =3D d->vcpu[vcpuid]) =3D=3D NULL )=0A     {=0A-        gdprintk(XENLOG_E=
RR, "HVM restore: domain has no vlapic %u\n", vcpuid);=0A+        =
dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",=0A+            =
    d->domain_id, vcpuid);=0A         return -EINVAL;=0A     }=0A     s =
=3D vcpu_vlapic(v);=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=
=0A@@ -1517,9 +1517,9 @@ int pirq_guest_bind(struct vcpu *v, stru=0A     =
{=0A         if ( desc->action !=3D NULL )=0A         {=0A-            =
gdprintk(XENLOG_INFO,=0A-                    "Cannot bind IRQ %d to guest. =
In use by '%s'.\n",=0A-                    pirq->pirq, desc->action->name);=
=0A+            printk(XENLOG_G_INFO=0A+                   "Cannot bind =
IRQ%d to dom%d. In use by '%s'.\n",=0A+                   pirq->pirq, =
v->domain->domain_id, desc->action->name);=0A             rc =3D -EBUSY;=0A=
             goto unlock_out;=0A         }=0A@@ -1531,9 +1531,9 @@ int =
pirq_guest_bind(struct vcpu *v, stru=0A                  zalloc_cpumask_var=
(&newaction->cpu_eoi_map) )=0A                 goto retry;=0A             =
xfree(newaction);=0A-            gdprintk(XENLOG_INFO,=0A-                 =
    "Cannot bind IRQ %d to guest. Out of memory.\n",=0A-                   =
  pirq->pirq);=0A+            printk(XENLOG_G_INFO=0A+                   =
"Cannot bind IRQ%d to dom%d. Out of memory.\n",=0A+                   =
pirq->pirq, v->domain->domain_id);=0A             rc =3D -ENOMEM;=0A       =
      goto out;=0A         }=0A@@ -1558,11 +1558,10 @@ int pirq_guest_bind(=
struct vcpu *v, stru=0A     }=0A     else if ( !will_share || !action->shar=
eable )=0A     {=0A-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to =
guest. %s.\n",=0A-                 pirq->pirq,=0A-                 =
will_share ?=0A-                 "Others do not share" :=0A-               =
  "Will not share with others");=0A+        printk(XENLOG_G_INFO "Cannot =
bind IRQ%d to dom%d. %s.\n",=0A+               pirq->pirq, v->domain->domai=
n_id,=0A+               will_share ? "Others do not share"=0A+             =
             : "Will not share with others");=0A         rc =3D -EBUSY;=0A =
        goto unlock_out;=0A     }=0A@@ -1581,8 +1580,9 @@ int pirq_guest_bi=
nd(struct vcpu *v, stru=0A =0A     if ( action->nr_guests =3D=3D IRQ_MAX_GU=
ESTS )=0A     {=0A-        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to =
guest. "=0A-               "Already at max share.\n", pirq->pirq);=0A+     =
   printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. "=0A+               =
"Already at max share.\n",=0A+               pirq->pirq, v->domain->domain_=
id);=0A         rc =3D -EBUSY;=0A         goto unlock_out;=0A     }=0A--- =
a/xen/arch/x86/oprofile/op_model_ppro.c=0A+++ b/xen/arch/x86/oprofile/op_mo=
del_ppro.c=0A@@ -235,10 +235,10 @@ static int ppro_allocate_msr(struct =
vcpu=0A 	vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);=0A 	=
return 1;=0A out:=0A-        gdprintk(XENLOG_WARNING, "Insufficient memory =
for oprofile, oprofile is "=0A-                 "unavailable on domain %d =
vcpu %d.\n",=0A-                 v->vcpu_id, v->domain->domain_id);=0A-    =
    return 0;=0A+	printk(XENLOG_G_WARNING "Insufficient memory for =
oprofile,"=0A+	       " oprofile is unavailable on dom%d vcpu%d\n",=0A+	=
       v->vcpu_id, v->domain->domain_id);=0A+	return 0;=0A }=0A =0A =
static void ppro_free_msr(struct vcpu *v)=0A--- a/xen/arch/x86/time.c=0A+++=
 b/xen/arch/x86/time.c=0A@@ -945,8 +945,8 @@ int cpu_frequency_change(u64 =
freq)=0A     /* Sanity check: CPU frequency allegedly dropping below 1MHz? =
*/=0A     if ( freq < 1000000u )=0A     {=0A-        gdprintk(XENLOG_WARNIN=
G, "Rejecting CPU frequency change "=0A-                 "to %"PRIu64" =
Hz.\n", freq);=0A+        printk(XENLOG_WARNING "Rejecting CPU frequency =
change "=0A+               "to %"PRIu64" Hz\n", freq);=0A         return =
-EINVAL;=0A     }=0A =0A--- a/xen/common/hvm/save.c=0A+++ b/xen/common/hvm/=
save.c=0A@@ -108,8 +108,8 @@ int hvm_save_one(struct domain *d, uint1=0A =
=0A     if ( hvm_sr_handlers[typecode].save(d, &ctxt) !=3D 0 )=0A     =
{=0A-        gdprintk(XENLOG_ERR, =0A-                 "HVM save: failed =
to save type %"PRIu16"\n", typecode);=0A+        printk(XENLOG_G_ERR =
"HVM%d save: failed to save type %"PRIu16"\n",=0A+               d->domain_=
id, typecode);=0A         rv =3D -EFAULT;=0A     }=0A     else if ( =
copy_to_guest(handle,=0A@@ -149,7 +149,8 @@ int hvm_save(struct domain *d, =
hvm_domai=0A =0A     if ( hvm_save_entry(HEADER, 0, h, &hdr) !=3D 0 )=0A   =
  {=0A-        gdprintk(XENLOG_ERR, "HVM save: failed to write header\n");=
=0A+        printk(XENLOG_G_ERR "HVM%d save: failed to write header\n",=0A+=
               d->domain_id);=0A         return -EFAULT;=0A     } =0A =
=0A@@ -159,11 +160,13 @@ int hvm_save(struct domain *d, hvm_domai=0A       =
  handler =3D hvm_sr_handlers[i].save;=0A         if ( handler !=3D NULL ) =
=0A         {=0A-            gdprintk(XENLOG_INFO, "HVM save: %s\n",  =
hvm_sr_handlers[i].name);=0A+            printk(XENLOG_G_INFO "HVM%d save: =
%s\n",=0A+                   d->domain_id, hvm_sr_handlers[i].name);=0A    =
         if ( handler(d, h) !=3D 0 ) =0A             {=0A-                =
gdprintk(XENLOG_ERR, =0A-                         "HVM save: failed to =
save type %"PRIu16"\n", i);=0A+                printk(XENLOG_G_ERR=0A+     =
                  "HVM%d save: failed to save type %"PRIu16"\n",=0A+       =
                d->domain_id, i);=0A                 return -EFAULT;=0A    =
         } =0A         }=0A@@ -173,7 +176,8 @@ int hvm_save(struct domain =
*d, hvm_domai=0A     if ( hvm_save_entry(END, 0, h, &end) !=3D 0 )=0A     =
{=0A         /* Run out of data */=0A-        gdprintk(XENLOG_ERR, "HVM =
save: no room for end marker.\n");=0A+        printk(XENLOG_G_ERR "HVM%d =
save: no room for end marker\n",=0A+               d->domain_id);=0A       =
  return -EFAULT;=0A     }=0A =0A@@ -209,8 +213,9 @@ int hvm_load(struct =
domain *d, hvm_domai=0A         if ( h->size - h->cur < sizeof(struct =
hvm_save_descriptor) )=0A         {=0A             /* Run out of data =
*/=0A-            gdprintk(XENLOG_ERR, =0A-                     "HVM =
restore: save did not end with a null entry\n");=0A+            printk(XENL=
OG_G_ERR=0A+                   "HVM%d restore: save did not end with a =
null entry\n",=0A+                   d->domain_id);=0A             return =
-1;=0A         }=0A         =0A@@ -223,20 +228,18 @@ int hvm_load(struct =
domain *d, hvm_domai=0A         if ( (desc->typecode > HVM_SAVE_CODE_MAX) =
||=0A              ((handler =3D hvm_sr_handlers[desc->typecode].load) =
=3D=3D NULL) )=0A         {=0A-            gdprintk(XENLOG_ERR, =0A-       =
              "HVM restore: unknown entry typecode %u\n", =0A-             =
        desc->typecode);=0A+            printk(XENLOG_G_ERR "HVM%d =
restore: unknown entry typecode %u\n",=0A+                   d->domain_id, =
desc->typecode);=0A             return -1;=0A         }=0A =0A         /* =
Load the entry */=0A-        gdprintk(XENLOG_INFO, "HVM restore: %s =
%"PRIu16"\n",  =0A-                 hvm_sr_handlers[desc->typecode].name, =
desc->instance);=0A+        printk(XENLOG_G_INFO "HVM%d restore: %s =
%"PRIu16"\n", d->domain_id,=0A+               hvm_sr_handlers[desc->typecod=
e].name, desc->instance);=0A         if ( handler(d, h) !=3D 0 ) =0A       =
  {=0A-            gdprintk(XENLOG_ERR, =0A-                     "HVM =
restore: failed to load entry %u/%u\n", =0A-                     desc->type=
code, desc->instance);=0A+            printk(XENLOG_G_ERR "HVM%d restore: =
failed to load entry %u/%u\n",=0A+                   d->domain_id, =
desc->typecode, desc->instance);=0A             return -1;=0A         }=0A =
    }=0A@@ -251,10 +254,9 @@ int _hvm_init_entry(struct hvm_domain_co=0A   =
      =3D (struct hvm_save_descriptor *)&h->data[h->cur];=0A     if ( =
h->size - h->cur < len + sizeof (*d) )=0A     {=0A-        gdprintk(XENLOG_=
WARNING,=0A-                 "HVM save: no room for %"PRIu32" + %u bytes =
"=0A-                 "for typecode %"PRIu16"\n",=0A-                 len, =
(unsigned) sizeof (*d), tc);=0A+        printk(XENLOG_G_WARNING "HVM save: =
no room for"=0A+               " %"PRIu32" + %zu bytes for typecode =
%"PRIu16"\n",=0A+               len, sizeof(*d), tc);=0A         return =
-1;=0A     }=0A     d->typecode =3D tc;=0A@@ -278,17 +280,17 @@ int =
_hvm_check_entry(struct hvm_domain_c=0A         =3D (struct hvm_save_descri=
ptor *)&h->data[h->cur];=0A     if ( len + sizeof (*d) > h->size - =
h->cur)=0A     {=0A-        gdprintk(XENLOG_WARNING, =0A-                 =
"HVM restore: not enough data left to read %u bytes "=0A-                 =
"for type %u\n", len, type);=0A+        printk(XENLOG_G_WARNING=0A+        =
       "HVM restore: not enough data left to read %u bytes "=0A+           =
    "for type %u\n", len, type);=0A         return -1;=0A     }    =0A     =
if ( (type !=3D d->typecode) || (len < d->length) ||=0A          (strict_le=
ngth && (len !=3D d->length)) )=0A     {=0A-        gdprintk(XENLOG_WARNING=
, =0A-                 "HVM restore mismatch: expected type %u length %u, =
"=0A-                 "saw type %u length %u\n", type, len, d->typecode, =
d->length);=0A+        printk(XENLOG_G_WARNING=0A+               "HVM =
restore mismatch: expected type %u length %u, "=0A+               "saw =
type %u length %u\n", type, len, d->typecode, d->length);=0A         =
return -1;=0A     }=0A     h->cur +=3D sizeof(*d);=0A--- a/xen/common/sysct=
l.c=0A+++ b/xen/common/sysctl.c=0A@@ -299,8 +299,6 @@ long do_sysctl(XEN_GU=
EST_HANDLE(xen_sysc=0A                     ret =3D query_page_offline(pfn, =
ptr++);=0A                     break;=0A                 default:=0A-      =
              gdprintk(XENLOG_WARNING, "invalid page offline op %x\n",=0A- =
                           op->u.page_offline.cmd);=0A                     =
ret =3D -EINVAL;=0A                     break;=0A             }=0A--- =
a/xen/common/xenoprof.c=0A+++ b/xen/common/xenoprof.c=0A@@ -144,8 +144,8 =
@@ share_xenoprof_page_with_guest(struct do=0A         struct page_info =
*page =3D mfn_to_page(mfn + i);=0A         if ( (page->count_info & =
(PGC_allocated|PGC_count_mask)) !=3D 0 )=0A         {=0A-            =
gdprintk(XENLOG_INFO, "mfn 0x%lx page->count_info 0x%lx\n",=0A-            =
         mfn + i, (unsigned long)page->count_info);=0A+            =
printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n",=0A+         =
          d->domain_id, mfn + i, page->count_info);=0A             return =
-EBUSY;=0A         }=0A         page_set_owner(page, NULL);=0A--- =
a/xen/drivers/passthrough/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=
=0A@@ -566,9 +566,9 @@ int iommu_do_domctl(=0A =0A         if ( device_assi=
gned(seg, bus, devfn) )=0A         {=0A-            gdprintk(XENLOG_ERR, =
"XEN_DOMCTL_test_assign_device: "=0A-                     "%04x:%02x:%02x.%=
u already assigned, or non-existent\n",=0A-                     seg, bus, =
PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+            printk(XENLOG_G_INFO=0A+ =
                  "%04x:%02x:%02x.%u already assigned, or non-existent\n",=
=0A+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A     =
        ret =3D -EINVAL;=0A         }=0A         break;=0A@@ -576,8 +576,8 =
@@ int iommu_do_domctl(=0A     case XEN_DOMCTL_assign_device:=0A         =
if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A   =
      {=0A-            gdprintk(XENLOG_ERR,=0A-                "XEN_DOMCTL_=
assign_device: get_domain_by_id() failed\n");=0A+            printk(XENLOG_=
G_ERR=0A+                   "XEN_DOMCTL_assign_device: get_domain_by_id() =
failed\n");=0A             ret =3D -EINVAL;=0A             break;=0A       =
  }=0A@@ -593,9 +593,9 @@ int iommu_do_domctl(=0A #ifdef __ia64__ /* XXX =
Is this really needed? */=0A         if ( device_assigned(seg, bus, devfn) =
)=0A         {=0A-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_devic=
e: "=0A-                     "%x:%x.%x already assigned, or non-existent\n"=
,=0A-                     bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+      =
      printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "=0A+                 =
  "%04x:%02x:%02x.%u already assigned, or non-existent\n",=0A+             =
      seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A             ret =3D =
-EINVAL;=0A             goto assign_device_out;=0A         }=0A@@ -603,9 =
+603,10 @@ int iommu_do_domctl(=0A =0A         ret =3D assign_device(d, =
seg, bus, devfn);=0A         if ( ret )=0A-            gdprintk(XENLOG_ERR,=
 "XEN_DOMCTL_assign_device: "=0A-                     "assign device =
(%04x:%02x:%02x.%u) failed\n",=0A-                     seg, bus, PCI_SLOT(d=
evfn), PCI_FUNC(devfn));=0A+            printk(XENLOG_G_ERR "XEN_DOMCTL_ass=
ign_device: "=0A+                   "assign %04x:%02x:%02x.%u to dom%d =
failed (%d)\n",=0A+                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(d=
evfn),=0A+                   d->domain_id, ret);=0A =0A     assign_device_o=
ut:=0A         put_domain(d);=0A@@ -614,8 +615,8 @@ int iommu_do_domctl(=0A=
     case XEN_DOMCTL_deassign_device:=0A         if ( unlikely((d =3D =
get_domain_by_id(domctl->domain)) =3D=3D NULL) )=0A         {=0A-          =
  gdprintk(XENLOG_ERR,=0A-                "XEN_DOMCTL_deassign_device: =
get_domain_by_id() failed\n");=0A+            printk(XENLOG_G_ERR=0A+      =
             "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");=0A=
             ret =3D -EINVAL;=0A             break;=0A         }=0A@@ =
-640,9 +641,10 @@ int iommu_do_domctl(=0A         ret =3D deassign_device(d=
, seg, bus, devfn);=0A         spin_unlock(&pcidevs_lock);=0A         if ( =
ret )=0A-            gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: =
"=0A-                     "deassign device (%04x:%02x:%02x.%u) failed\n",=
=0A-                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A+  =
          printk(XENLOG_G_ERR=0A+                   "deassign %04x:%02x:%02=
x.%u from dom%d failed (%d)\n",=0A+                   seg, bus, PCI_SLOT(de=
vfn), PCI_FUNC(devfn),=0A+                   d->domain_id, ret);=0A =0A    =
 deassign_device_out:=0A         put_domain(d);=0A
--=__PartE4CA9D30.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.xensource.com
http://lists.xensource.com/xen-devel

--=__PartE4CA9D30.0__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 14:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 14:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxgKB-0000lb-1k; Wed, 15 Feb 2012 14:59:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxgK9-0000lC-E3
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 14:59:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329317947!9304426!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTQ2MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32727 invoked from network); 15 Feb 2012 14:59:07 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-10.tower-21.messagelabs.com with SMTP;
	15 Feb 2012 14:59:07 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 9E7F8604079;
	Wed, 15 Feb 2012 06:59:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=pMI2T8fIC0gwVpWXx8cGYSCcFV931/heqC6NTvdl6fGI
	MpM5BqWHBdfGxw98RWSLAPTab4jaiYeIMjhA7B5m7qq6i1HJb2xU8wz21R0P68zp
	9XVRaJvLfznfyxOvdkulvu5LzutsmWPgF67zqEytcXS4Y7V3zNJPe91TXAIUt6g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=CBH9bpaEGJKBTiXE/jGDIx+Y6hk=; b=ao7T5DwG
	nKxAYHZYkeBE+n0bZIa+kO9OFFNAUM3UEBDo43LShDII0nJNlMF/nCcDcwVhD+5u
	A3bbnkJjleTNl3XGdDQRjlRR1RL+IjwmWO/+quxMpk1HTcdL19WmQiUgdYJ4CG2M
	0/D//4F2XX4OwTlHkqDf1UDsucVHBtyYAHg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 4506B604084; 
	Wed, 15 Feb 2012 06:59:06 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 06:59:06 -0800
Message-ID: <b681d3c1957c0f2662fe994c99513340.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120215091806.GA6646@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
	<d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
	<20120214214313.GA25605@aepfle.de> <20120215091806.GA6646@aepfle.de>
Date: Wed, 15 Feb 2012 06:59:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Olaf Hering wrote:
>
>> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>>
>> > Those are the kinds of errors I was getting until I finished my patch.
>> > Basically, the p2m gets confused and returns p2m_mmio_dm as the type
>> for
>> > anything it doesn't understand. If you end up giving my patch a spin,
>> let
>> > me know if it gets you past that hump.
>>
>> No, it does not work for me, still EINVAL during mapping.
>
> And this also happens with a recent system:

Ok, most likely the p2m is not returning the proper values for entries
that are p2m_ram_paging_out. Although eviction after nominate does work.
Ummhhh. I'll look into it. Thanks Olaf for the report

Andres

>
> processor       : 2
> vendor_id       : AuthenticAMD
> cpu family      : 16
> model           : 5
> model name      : AMD Phenom(tm) II N830 Triple-Core Processor
> stepping        : 3
> cpu MHz         : 2094.846
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 14:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 14:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxgKB-0000lb-1k; Wed, 15 Feb 2012 14:59:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxgK9-0000lC-E3
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 14:59:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329317947!9304426!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTQ2MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32727 invoked from network); 15 Feb 2012 14:59:07 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.202) by server-10.tower-21.messagelabs.com with SMTP;
	15 Feb 2012 14:59:07 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 9E7F8604079;
	Wed, 15 Feb 2012 06:59:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=pMI2T8fIC0gwVpWXx8cGYSCcFV931/heqC6NTvdl6fGI
	MpM5BqWHBdfGxw98RWSLAPTab4jaiYeIMjhA7B5m7qq6i1HJb2xU8wz21R0P68zp
	9XVRaJvLfznfyxOvdkulvu5LzutsmWPgF67zqEytcXS4Y7V3zNJPe91TXAIUt6g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=CBH9bpaEGJKBTiXE/jGDIx+Y6hk=; b=ao7T5DwG
	nKxAYHZYkeBE+n0bZIa+kO9OFFNAUM3UEBDo43LShDII0nJNlMF/nCcDcwVhD+5u
	A3bbnkJjleTNl3XGdDQRjlRR1RL+IjwmWO/+quxMpk1HTcdL19WmQiUgdYJ4CG2M
	0/D//4F2XX4OwTlHkqDf1UDsucVHBtyYAHg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 4506B604084; 
	Wed, 15 Feb 2012 06:59:06 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 06:59:06 -0800
Message-ID: <b681d3c1957c0f2662fe994c99513340.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120215091806.GA6646@aepfle.de>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<20120214192249.GA10224@aepfle.de>
	<2aee3454239cd9f663b5c8ee43b2e2bc.squirrel@webmail.lagarcavilla.org>
	<20120214212655.GA23901@aepfle.de>
	<d9040b615b8e9eb4f7c68dd35709a090.squirrel@webmail.lagarcavilla.org>
	<20120214214313.GA25605@aepfle.de> <20120215091806.GA6646@aepfle.de>
Date: Wed, 15 Feb 2012 06:59:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Feb 14, Olaf Hering wrote:
>
>> On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>>
>> > Those are the kinds of errors I was getting until I finished my patch.
>> > Basically, the p2m gets confused and returns p2m_mmio_dm as the type
>> for
>> > anything it doesn't understand. If you end up giving my patch a spin,
>> let
>> > me know if it gets you past that hump.
>>
>> No, it does not work for me, still EINVAL during mapping.
>
> And this also happens with a recent system:

Ok, most likely the p2m is not returning the proper values for entries
that are p2m_ram_paging_out. Although eviction after nominate does work.
Ummhhh. I'll look into it. Thanks Olaf for the report

Andres

>
> processor       : 2
> vendor_id       : AuthenticAMD
> cpu family      : 16
> model           : 5
> model name      : AMD Phenom(tm) II N830 Triple-Core Processor
> stepping        : 3
> cpu MHz         : 2094.846
>
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 15:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 15:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxgZM-0001CS-Q8; Wed, 15 Feb 2012 15:14:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxgZK-0001CN-SZ
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 15:14:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329318888!14442214!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0Mjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13962 invoked from network); 15 Feb 2012 15:14:48 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-216.messagelabs.com with SMTP;
	15 Feb 2012 15:14:48 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 60B7438006F;
	Wed, 15 Feb 2012 07:14:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AA3RL2r0EkceCySVWwXRBVTGXyH81apar5Cz9vUedSYy
	x/OL5QNg2/O59T80aj65odKku/npMSA616hP26WNQSuxqq6ew/XrW+xX+261otNr
	TaGo5LNT6fcSCkfF+2eiYyagyHTyQggkdzUylV1uxtoqoJ7Xh9P2Q2rW6MpH07k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=QWL1uvTdG9j6h7byO9AhQbKPYG0=; b=iJmTrjmL
	o52ww9uQ8WtDftjcRc4Pu7Dx/IlbXlfWQUYnmoTZ4DqXDnI3LgMoBvgHWWJ/RWui
	t2MHga86AwaOUwZjoog8tSo67yXkGGIaqULCdjzk1Z2LbchhiWaRKBHK1ANjc9wk
	S/wojfISn/LiNLXvCpjSsGEAQNPSbt61A1k=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 1326A38005F; 
	Wed, 15 Feb 2012 07:14:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 07:14:47 -0800
Message-ID: <21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3BA067.4010303@amd.com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
Date: Wed, 15 Feb 2012 07:14:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Wei Wang" <wei.wang2@amd.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>> We started hashing out some AMD support for mem_paging and mem_access.
>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>> fault.
>>
>> Most importantly, I want to get somebody from AMD to comment/help out on
>> this. It feels like we're inches away from enabling support for this
>> very
>> nice feature. I'm not sure who exactly on AMD monitors the list for
>> these
>> kinds of things. It'd be great to have you on board!
>>
>> For starters, the changes to the p2m code are relatively mild, but it'd
>> be
>> great if somebody spots a red flag.
>>
>> Another issue: comments indicate that bits 59-62 in NPT entries are used
>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>> (59)
>> would give us enough space to support mem_access. Right now we only have
>> 7
>> bits available for Xen flags and that is not enough for paging and
>> access.
>> Is bit 59 effectively reserved?
>
> Hi
> bit 59 is used by iommu hardware for ATS response. In most cases, for
> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
> are not potentially used by DMA, this bit could be non-zero. I could
> tested it on my iommu machines if you had some patches that use U bits.

Hi Wei, thanks for pitching in! I assume you're talking about table 14
(and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf

I don't think this will work. The p2m access value is arbitrary, and
independent of the p2m type. So bit 59 is out of reach and we're stuck
with 7 bits for Xen use. Thanks for the clarification.

An alternative to enabling mem_access on AMD processors will be to limit
the access types to 3 bits. This would force disabling support for two
modes. I'm inclined to disable two out of X, W and WX. I don't think they
make sense without R permissions.

Thanks!
Andres

>
> Thanks,
> Wei
>
>>
>> Finally, the triple fault. Maybe I'm missing something obvious. Comments
>> welcome.
>>
>> Patch inline below, thanks!
>> Andres
>>
>> Enable AMD support for paging.
>>
>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>               if ( !hap_enabled(d) )
>>                   break;
>>
>> -            /* Currently only EPT is supported */
>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> -                break;
>> -
>>               rc = -EXDEV;
>>               /* Disallow paging in a PoD guest */
>>               if ( p2m->pod.entry_count )
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -53,6 +53,20 @@
>>   #define P2M_BASE_FLAGS \
>>           (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>
>> +#ifdef __x86_64__
>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>> 0xff..ff
>> + * value tramples over the higher-order bits used for flags (NX, p2mt,
>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>> + * juggle for l1 entries only (no paging superpages!) */
>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>> +#define clipped_mfn(mfn)    ((mfn)&  ((1UL<<  EFF_MFN_WIDTH) - 1))
>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>> +                                INVALID_MFN : (mfn))
>> +#else
>> +#define clipped_mfn(mfn)    (mfn)
>> +#define unclip_mfn(mfn)     (mfn)
>> +#endif /* __x86_64__ */
>> +
>>   static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>   {
>>       unsigned long flags;
>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>       case p2m_invalid:
>>       case p2m_mmio_dm:
>>       case p2m_populate_on_demand:
>> +    case p2m_ram_paging_out:
>> +    case p2m_ram_paged:
>> +    case p2m_ram_paging_in:
>>       default:
>>           return flags;
>>       case p2m_ram_ro:
>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>                                         shift, max)) )
>>           return 0;
>>
>> -    /* PoD: Not present doesn't imply empty. */
>> +    /* PoD/paging: Not present doesn't imply empty. */
>>       if ( !l1e_get_flags(*p2m_entry) )
>>       {
>>           struct page_info *pg;
>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>                                      0, L1_PAGETABLE_ENTRIES);
>>           ASSERT(p2m_entry);
>>
>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>                                            p2m_type_to_flags(p2mt,
>> mfn));
>>           else
>>               entry_content = l1e_empty();
>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>           if ( entry_content.l1 != 0 )
>>           {
>>               p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>           }
>>           /* level 1 entry */
>>           p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>> entry_content, 1);
>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>                              sizeof(l1e));
>>
>>       if ( ret == 0 ) {
>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>           p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>> +                (l1e_mfn == INVALID_MFN&&  p2m_is_paging(p2mt)) );
>>
>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>> -             == p2m_populate_on_demand )
>> +        if ( p2mt == p2m_populate_on_demand )
>>           {
>>               /* The read has succeeded, so we know that the mapping
>>                * exits at this point.  */
>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>           }
>>
>>           if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>> -            mfn = _mfn(l1e_get_pfn(l1e));
>> +            mfn = _mfn(l1e_mfn);
>>           else
>>               /* XXX see above */
>>               p2mt = p2m_mmio_dm;
>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>   pod_retry_l1:
>>       if ( (l1e_get_flags(*l1e)&  _PAGE_PRESENT) == 0 )
>>       {
>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>           /* PoD: Try to populate */
>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>> p2m_populate_on_demand )
>> +        if ( l1t == p2m_populate_on_demand )
>>           {
>>               if ( q != p2m_query ) {
>>                   if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K,
>> q) )
>>                       goto pod_retry_l1;
>>               } else
>>                   *t = p2m_populate_on_demand;
>> +        } else {
>> +            if ( p2m_is_paging(l1t) )
>> +            {
>> +                *t = l1t;
>> +                /* No need to unclip due to check below */
>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>> +            }
>>           }
>>
>>           unmap_domain_page(l1e);
>> -        return _mfn(INVALID_MFN);
>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>       }
>>       mfn = _mfn(l1e_get_pfn(*l1e));
>>       *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>                       flags = l1e_get_flags(l1e[i1]);
>>                       if ( p2m_flags_to_type(flags) != ot )
>>                           continue;
>> -                    mfn = l1e_get_pfn(l1e[i1]);
>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                       gfn = i1 + (i2 + (i3
>>   #if CONFIG_PAGING_LEVELS>= 4
>>   					+ (i4 * L3_PAGETABLE_ENTRIES)
>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>                              * L2_PAGETABLE_ENTRIES) *
>> L1_PAGETABLE_ENTRIES;
>>                       /* create a new 1le entry with the new type */
>>                       flags = p2m_type_to_flags(nt, _mfn(mfn));
>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>> flags);
>>                       p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>                                            l1mfn, l1e_content, 1);
>>                   }
>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>                                   entry_count++;
>>                               continue;
>>                           }
>> -                        mfn = l1e_get_pfn(l1e[i1]);
>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                           ASSERT(mfn_valid(_mfn(mfn)));
>>                           m2pfn = get_gpfn_from_mfn(mfn);
>>                           if ( m2pfn != gfn&&
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 15:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 15:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxgZM-0001CS-Q8; Wed, 15 Feb 2012 15:14:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxgZK-0001CN-SZ
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 15:14:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329318888!14442214!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY0Mjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13962 invoked from network); 15 Feb 2012 15:14:48 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-11.tower-216.messagelabs.com with SMTP;
	15 Feb 2012 15:14:48 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 60B7438006F;
	Wed, 15 Feb 2012 07:14:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AA3RL2r0EkceCySVWwXRBVTGXyH81apar5Cz9vUedSYy
	x/OL5QNg2/O59T80aj65odKku/npMSA616hP26WNQSuxqq6ew/XrW+xX+261otNr
	TaGo5LNT6fcSCkfF+2eiYyagyHTyQggkdzUylV1uxtoqoJ7Xh9P2Q2rW6MpH07k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=QWL1uvTdG9j6h7byO9AhQbKPYG0=; b=iJmTrjmL
	o52ww9uQ8WtDftjcRc4Pu7Dx/IlbXlfWQUYnmoTZ4DqXDnI3LgMoBvgHWWJ/RWui
	t2MHga86AwaOUwZjoog8tSo67yXkGGIaqULCdjzk1Z2LbchhiWaRKBHK1ANjc9wk
	S/wojfISn/LiNLXvCpjSsGEAQNPSbt61A1k=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 1326A38005F; 
	Wed, 15 Feb 2012 07:14:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 07:14:47 -0800
Message-ID: <21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3BA067.4010303@amd.com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
Date: Wed, 15 Feb 2012 07:14:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Wei Wang" <wei.wang2@amd.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>> We started hashing out some AMD support for mem_paging and mem_access.
>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>> fault.
>>
>> Most importantly, I want to get somebody from AMD to comment/help out on
>> this. It feels like we're inches away from enabling support for this
>> very
>> nice feature. I'm not sure who exactly on AMD monitors the list for
>> these
>> kinds of things. It'd be great to have you on board!
>>
>> For starters, the changes to the p2m code are relatively mild, but it'd
>> be
>> great if somebody spots a red flag.
>>
>> Another issue: comments indicate that bits 59-62 in NPT entries are used
>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>> (59)
>> would give us enough space to support mem_access. Right now we only have
>> 7
>> bits available for Xen flags and that is not enough for paging and
>> access.
>> Is bit 59 effectively reserved?
>
> Hi
> bit 59 is used by iommu hardware for ATS response. In most cases, for
> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
> are not potentially used by DMA, this bit could be non-zero. I could
> tested it on my iommu machines if you had some patches that use U bits.

Hi Wei, thanks for pitching in! I assume you're talking about table 14
(and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf

I don't think this will work. The p2m access value is arbitrary, and
independent of the p2m type. So bit 59 is out of reach and we're stuck
with 7 bits for Xen use. Thanks for the clarification.

An alternative to enabling mem_access on AMD processors will be to limit
the access types to 3 bits. This would force disabling support for two
modes. I'm inclined to disable two out of X, W and WX. I don't think they
make sense without R permissions.

Thanks!
Andres

>
> Thanks,
> Wei
>
>>
>> Finally, the triple fault. Maybe I'm missing something obvious. Comments
>> welcome.
>>
>> Patch inline below, thanks!
>> Andres
>>
>> Enable AMD support for paging.
>>
>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>               if ( !hap_enabled(d) )
>>                   break;
>>
>> -            /* Currently only EPT is supported */
>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> -                break;
>> -
>>               rc = -EXDEV;
>>               /* Disallow paging in a PoD guest */
>>               if ( p2m->pod.entry_count )
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -53,6 +53,20 @@
>>   #define P2M_BASE_FLAGS \
>>           (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>
>> +#ifdef __x86_64__
>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>> 0xff..ff
>> + * value tramples over the higher-order bits used for flags (NX, p2mt,
>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>> + * juggle for l1 entries only (no paging superpages!) */
>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>> +#define clipped_mfn(mfn)    ((mfn)&  ((1UL<<  EFF_MFN_WIDTH) - 1))
>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>> +                                INVALID_MFN : (mfn))
>> +#else
>> +#define clipped_mfn(mfn)    (mfn)
>> +#define unclip_mfn(mfn)     (mfn)
>> +#endif /* __x86_64__ */
>> +
>>   static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>   {
>>       unsigned long flags;
>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>       case p2m_invalid:
>>       case p2m_mmio_dm:
>>       case p2m_populate_on_demand:
>> +    case p2m_ram_paging_out:
>> +    case p2m_ram_paged:
>> +    case p2m_ram_paging_in:
>>       default:
>>           return flags;
>>       case p2m_ram_ro:
>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>                                         shift, max)) )
>>           return 0;
>>
>> -    /* PoD: Not present doesn't imply empty. */
>> +    /* PoD/paging: Not present doesn't imply empty. */
>>       if ( !l1e_get_flags(*p2m_entry) )
>>       {
>>           struct page_info *pg;
>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>                                      0, L1_PAGETABLE_ENTRIES);
>>           ASSERT(p2m_entry);
>>
>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>                                            p2m_type_to_flags(p2mt,
>> mfn));
>>           else
>>               entry_content = l1e_empty();
>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>           if ( entry_content.l1 != 0 )
>>           {
>>               p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>           }
>>           /* level 1 entry */
>>           p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>> entry_content, 1);
>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>                              sizeof(l1e));
>>
>>       if ( ret == 0 ) {
>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>           p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>> +                (l1e_mfn == INVALID_MFN&&  p2m_is_paging(p2mt)) );
>>
>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>> -             == p2m_populate_on_demand )
>> +        if ( p2mt == p2m_populate_on_demand )
>>           {
>>               /* The read has succeeded, so we know that the mapping
>>                * exits at this point.  */
>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>           }
>>
>>           if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>> -            mfn = _mfn(l1e_get_pfn(l1e));
>> +            mfn = _mfn(l1e_mfn);
>>           else
>>               /* XXX see above */
>>               p2mt = p2m_mmio_dm;
>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>   pod_retry_l1:
>>       if ( (l1e_get_flags(*l1e)&  _PAGE_PRESENT) == 0 )
>>       {
>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>           /* PoD: Try to populate */
>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>> p2m_populate_on_demand )
>> +        if ( l1t == p2m_populate_on_demand )
>>           {
>>               if ( q != p2m_query ) {
>>                   if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K,
>> q) )
>>                       goto pod_retry_l1;
>>               } else
>>                   *t = p2m_populate_on_demand;
>> +        } else {
>> +            if ( p2m_is_paging(l1t) )
>> +            {
>> +                *t = l1t;
>> +                /* No need to unclip due to check below */
>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>> +            }
>>           }
>>
>>           unmap_domain_page(l1e);
>> -        return _mfn(INVALID_MFN);
>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>       }
>>       mfn = _mfn(l1e_get_pfn(*l1e));
>>       *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>                       flags = l1e_get_flags(l1e[i1]);
>>                       if ( p2m_flags_to_type(flags) != ot )
>>                           continue;
>> -                    mfn = l1e_get_pfn(l1e[i1]);
>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                       gfn = i1 + (i2 + (i3
>>   #if CONFIG_PAGING_LEVELS>= 4
>>   					+ (i4 * L3_PAGETABLE_ENTRIES)
>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>                              * L2_PAGETABLE_ENTRIES) *
>> L1_PAGETABLE_ENTRIES;
>>                       /* create a new 1le entry with the new type */
>>                       flags = p2m_type_to_flags(nt, _mfn(mfn));
>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>> flags);
>>                       p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>                                            l1mfn, l1e_content, 1);
>>                   }
>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>                                   entry_count++;
>>                               continue;
>>                           }
>> -                        mfn = l1e_get_pfn(l1e[i1]);
>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                           ASSERT(mfn_valid(_mfn(mfn)));
>>                           m2pfn = get_gpfn_from_mfn(mfn);
>>                           if ( m2pfn != gfn&&
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 15:28:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 15:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxgmO-0001lz-4b; Wed, 15 Feb 2012 15:28:24 +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 1RxgmM-0001lu-Bj
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 15:28:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329319649!62978701!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11058 invoked from network); 15 Feb 2012 15:27:31 -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;
	15 Feb 2012 15:27:31 -0000
Received: from mail94-ch1-R.bigfish.com (10.43.68.227) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 15:28:19 +0000
Received: from mail94-ch1 (localhost [127.0.0.1])	by mail94-ch1-R.bigfish.com
	(Postfix) with ESMTP id DA06EE0298;
	Wed, 15 Feb 2012 15:28:18 +0000 (UTC)
X-SpamScore: -20
X-BigFish: VPS-20(zzbb2dI9371I103dK148cM1447M1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dh5eeeKz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail94-ch1 (localhost.localdomain [127.0.0.1]) by mail94-ch1
	(MessageSwitch) id 1329319695961139_3132;
	Wed, 15 Feb 2012 15:28:15 +0000 (UTC)
Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.225])	by mail94-ch1.bigfish.com (Postfix) with ESMTP id
	CD5F716004E;	Wed, 15 Feb 2012 15:28:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 15:28:15 +0000
X-WSS-ID: 0LZFXMW-02-09E-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 2E681C817F;	Wed, 15 Feb 2012 09:28:08 -0600 (CST)
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, 15 Feb 2012 09:28:23 -0600
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.289.1;
	Wed, 15 Feb 2012 09:28:11 -0600
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, 15 Feb 2012
	10:28:10 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2267B49C305; Wed, 15 Feb 2012
	15:28:09 +0000 (GMT)
Message-ID: <4F3BD053.5070404@amd.com>
Date: Wed, 15 Feb 2012 16:33:39 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <andres@lagarcavilla.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>> We started hashing out some AMD support for mem_paging and mem_access.
>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>> fault.
>>>
>>> Most importantly, I want to get somebody from AMD to comment/help out on
>>> this. It feels like we're inches away from enabling support for this
>>> very
>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>> these
>>> kinds of things. It'd be great to have you on board!
>>>
>>> For starters, the changes to the p2m code are relatively mild, but it'd
>>> be
>>> great if somebody spots a red flag.
>>>
>>> Another issue: comments indicate that bits 59-62 in NPT entries are used
>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>> (59)
>>> would give us enough space to support mem_access. Right now we only have
>>> 7
>>> bits available for Xen flags and that is not enough for paging and
>>> access.
>>> Is bit 59 effectively reserved?
>>
>> Hi
>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
>> are not potentially used by DMA, this bit could be non-zero. I could
>> tested it on my iommu machines if you had some patches that use U bits.
>
> Hi Wei, thanks for pitching in! I assume you're talking about table 14
> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf

Yes, indeed.

> I don't think this will work. The p2m access value is arbitrary, and
> independent of the p2m type. So bit 59 is out of reach and we're stuck
> with 7 bits for Xen use. Thanks for the clarification.

Where will p2m access bit be stored? Please note that bit 52 - bit 58 
for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63 
and bit 1 - bit 8 are free to use if PR bit = 1.

Thanks,
Wei

> An alternative to enabling mem_access on AMD processors will be to limit
> the access types to 3 bits. This would force disabling support for two
> modes. I'm inclined to disable two out of X, W and WX. I don't think they
> make sense without R permissions.
> Thanks!
> Andres
>
>>
>> Thanks,
>> Wei
>>
>>>
>>> Finally, the triple fault. Maybe I'm missing something obvious. Comments
>>> welcome.
>>>
>>> Patch inline below, thanks!
>>> Andres
>>>
>>> Enable AMD support for paging.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>
>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>> --- a/xen/arch/x86/mm/mem_event.c
>>> +++ b/xen/arch/x86/mm/mem_event.c
>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>                if ( !hap_enabled(d) )
>>>                    break;
>>>
>>> -            /* Currently only EPT is supported */
>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>> -                break;
>>> -
>>>                rc = -EXDEV;
>>>                /* Disallow paging in a PoD guest */
>>>                if ( p2m->pod.entry_count )
>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>> @@ -53,6 +53,20 @@
>>>    #define P2M_BASE_FLAGS \
>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>
>>> +#ifdef __x86_64__
>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>> 0xff..ff
>>> + * value tramples over the higher-order bits used for flags (NX, p2mt,
>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>> + * juggle for l1 entries only (no paging superpages!) */
>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) - 1))
>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>> +                                INVALID_MFN : (mfn))
>>> +#else
>>> +#define clipped_mfn(mfn)    (mfn)
>>> +#define unclip_mfn(mfn)     (mfn)
>>> +#endif /* __x86_64__ */
>>> +
>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>    {
>>>        unsigned long flags;
>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>        case p2m_invalid:
>>>        case p2m_mmio_dm:
>>>        case p2m_populate_on_demand:
>>> +    case p2m_ram_paging_out:
>>> +    case p2m_ram_paged:
>>> +    case p2m_ram_paging_in:
>>>        default:
>>>            return flags;
>>>        case p2m_ram_ro:
>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>                                          shift, max)) )
>>>            return 0;
>>>
>>> -    /* PoD: Not present doesn't imply empty. */
>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>        if ( !l1e_get_flags(*p2m_entry) )
>>>        {
>>>            struct page_info *pg;
>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>                                       0, L1_PAGETABLE_ENTRIES);
>>>            ASSERT(p2m_entry);
>>>
>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>                                             p2m_type_to_flags(p2mt,
>>> mfn));
>>>            else
>>>                entry_content = l1e_empty();
>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>            if ( entry_content.l1 != 0 )
>>>            {
>>>                p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>            }
>>>            /* level 1 entry */
>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>> entry_content, 1);
>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>                               sizeof(l1e));
>>>
>>>        if ( ret == 0 ) {
>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt)) );
>>>
>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>> -             == p2m_populate_on_demand )
>>> +        if ( p2mt == p2m_populate_on_demand )
>>>            {
>>>                /* The read has succeeded, so we know that the mapping
>>>                 * exits at this point.  */
>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>            }
>>>
>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>> +            mfn = _mfn(l1e_mfn);
>>>            else
>>>                /* XXX see above */
>>>                p2mt = p2m_mmio_dm;
>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>    pod_retry_l1:
>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
>>>        {
>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>            /* PoD: Try to populate */
>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>> p2m_populate_on_demand )
>>> +        if ( l1t == p2m_populate_on_demand )
>>>            {
>>>                if ( q != p2m_query ) {
>>>                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K,
>>> q) )
>>>                        goto pod_retry_l1;
>>>                } else
>>>                    *t = p2m_populate_on_demand;
>>> +        } else {
>>> +            if ( p2m_is_paging(l1t) )
>>> +            {
>>> +                *t = l1t;
>>> +                /* No need to unclip due to check below */
>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>> +            }
>>>            }
>>>
>>>            unmap_domain_page(l1e);
>>> -        return _mfn(INVALID_MFN);
>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>        }
>>>        mfn = _mfn(l1e_get_pfn(*l1e));
>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>                        flags = l1e_get_flags(l1e[i1]);
>>>                        if ( p2m_flags_to_type(flags) != ot )
>>>                            continue;
>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>                        gfn = i1 + (i2 + (i3
>>>    #if CONFIG_PAGING_LEVELS>= 4
>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>                               * L2_PAGETABLE_ENTRIES) *
>>> L1_PAGETABLE_ENTRIES;
>>>                        /* create a new 1le entry with the new type */
>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>> flags);
>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>                                             l1mfn, l1e_content, 1);
>>>                    }
>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>                                    entry_count++;
>>>                                continue;
>>>                            }
>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>                            ASSERT(mfn_valid(_mfn(mfn)));
>>>                            m2pfn = get_gpfn_from_mfn(mfn);
>>>                            if ( m2pfn != gfn&&
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 15:28:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 15:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxgmO-0001lz-4b; Wed, 15 Feb 2012 15:28:24 +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 1RxgmM-0001lu-Bj
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 15:28:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329319649!62978701!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11058 invoked from network); 15 Feb 2012 15:27:31 -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;
	15 Feb 2012 15:27:31 -0000
Received: from mail94-ch1-R.bigfish.com (10.43.68.227) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 15:28:19 +0000
Received: from mail94-ch1 (localhost [127.0.0.1])	by mail94-ch1-R.bigfish.com
	(Postfix) with ESMTP id DA06EE0298;
	Wed, 15 Feb 2012 15:28:18 +0000 (UTC)
X-SpamScore: -20
X-BigFish: VPS-20(zzbb2dI9371I103dK148cM1447M1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dh5eeeKz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail94-ch1 (localhost.localdomain [127.0.0.1]) by mail94-ch1
	(MessageSwitch) id 1329319695961139_3132;
	Wed, 15 Feb 2012 15:28:15 +0000 (UTC)
Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.225])	by mail94-ch1.bigfish.com (Postfix) with ESMTP id
	CD5F716004E;	Wed, 15 Feb 2012 15:28:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 15 Feb 2012 15:28:15 +0000
X-WSS-ID: 0LZFXMW-02-09E-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 2E681C817F;	Wed, 15 Feb 2012 09:28:08 -0600 (CST)
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, 15 Feb 2012 09:28:23 -0600
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.289.1;
	Wed, 15 Feb 2012 09:28:11 -0600
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, 15 Feb 2012
	10:28:10 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2267B49C305; Wed, 15 Feb 2012
	15:28:09 +0000 (GMT)
Message-ID: <4F3BD053.5070404@amd.com>
Date: Wed, 15 Feb 2012 16:33:39 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <andres@lagarcavilla.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>> We started hashing out some AMD support for mem_paging and mem_access.
>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>> fault.
>>>
>>> Most importantly, I want to get somebody from AMD to comment/help out on
>>> this. It feels like we're inches away from enabling support for this
>>> very
>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>> these
>>> kinds of things. It'd be great to have you on board!
>>>
>>> For starters, the changes to the p2m code are relatively mild, but it'd
>>> be
>>> great if somebody spots a red flag.
>>>
>>> Another issue: comments indicate that bits 59-62 in NPT entries are used
>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>> (59)
>>> would give us enough space to support mem_access. Right now we only have
>>> 7
>>> bits available for Xen flags and that is not enough for paging and
>>> access.
>>> Is bit 59 effectively reserved?
>>
>> Hi
>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
>> are not potentially used by DMA, this bit could be non-zero. I could
>> tested it on my iommu machines if you had some patches that use U bits.
>
> Hi Wei, thanks for pitching in! I assume you're talking about table 14
> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf

Yes, indeed.

> I don't think this will work. The p2m access value is arbitrary, and
> independent of the p2m type. So bit 59 is out of reach and we're stuck
> with 7 bits for Xen use. Thanks for the clarification.

Where will p2m access bit be stored? Please note that bit 52 - bit 58 
for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63 
and bit 1 - bit 8 are free to use if PR bit = 1.

Thanks,
Wei

> An alternative to enabling mem_access on AMD processors will be to limit
> the access types to 3 bits. This would force disabling support for two
> modes. I'm inclined to disable two out of X, W and WX. I don't think they
> make sense without R permissions.
> Thanks!
> Andres
>
>>
>> Thanks,
>> Wei
>>
>>>
>>> Finally, the triple fault. Maybe I'm missing something obvious. Comments
>>> welcome.
>>>
>>> Patch inline below, thanks!
>>> Andres
>>>
>>> Enable AMD support for paging.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>
>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>> --- a/xen/arch/x86/mm/mem_event.c
>>> +++ b/xen/arch/x86/mm/mem_event.c
>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>                if ( !hap_enabled(d) )
>>>                    break;
>>>
>>> -            /* Currently only EPT is supported */
>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>> -                break;
>>> -
>>>                rc = -EXDEV;
>>>                /* Disallow paging in a PoD guest */
>>>                if ( p2m->pod.entry_count )
>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>> @@ -53,6 +53,20 @@
>>>    #define P2M_BASE_FLAGS \
>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>
>>> +#ifdef __x86_64__
>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>> 0xff..ff
>>> + * value tramples over the higher-order bits used for flags (NX, p2mt,
>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>> + * juggle for l1 entries only (no paging superpages!) */
>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) - 1))
>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>> +                                INVALID_MFN : (mfn))
>>> +#else
>>> +#define clipped_mfn(mfn)    (mfn)
>>> +#define unclip_mfn(mfn)     (mfn)
>>> +#endif /* __x86_64__ */
>>> +
>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>    {
>>>        unsigned long flags;
>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>        case p2m_invalid:
>>>        case p2m_mmio_dm:
>>>        case p2m_populate_on_demand:
>>> +    case p2m_ram_paging_out:
>>> +    case p2m_ram_paged:
>>> +    case p2m_ram_paging_in:
>>>        default:
>>>            return flags;
>>>        case p2m_ram_ro:
>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>                                          shift, max)) )
>>>            return 0;
>>>
>>> -    /* PoD: Not present doesn't imply empty. */
>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>        if ( !l1e_get_flags(*p2m_entry) )
>>>        {
>>>            struct page_info *pg;
>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>                                       0, L1_PAGETABLE_ENTRIES);
>>>            ASSERT(p2m_entry);
>>>
>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>                                             p2m_type_to_flags(p2mt,
>>> mfn));
>>>            else
>>>                entry_content = l1e_empty();
>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>            if ( entry_content.l1 != 0 )
>>>            {
>>>                p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>            }
>>>            /* level 1 entry */
>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>> entry_content, 1);
>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>                               sizeof(l1e));
>>>
>>>        if ( ret == 0 ) {
>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt)) );
>>>
>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>> -             == p2m_populate_on_demand )
>>> +        if ( p2mt == p2m_populate_on_demand )
>>>            {
>>>                /* The read has succeeded, so we know that the mapping
>>>                 * exits at this point.  */
>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>            }
>>>
>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>> +            mfn = _mfn(l1e_mfn);
>>>            else
>>>                /* XXX see above */
>>>                p2mt = p2m_mmio_dm;
>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>    pod_retry_l1:
>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
>>>        {
>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>            /* PoD: Try to populate */
>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>> p2m_populate_on_demand )
>>> +        if ( l1t == p2m_populate_on_demand )
>>>            {
>>>                if ( q != p2m_query ) {
>>>                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K,
>>> q) )
>>>                        goto pod_retry_l1;
>>>                } else
>>>                    *t = p2m_populate_on_demand;
>>> +        } else {
>>> +            if ( p2m_is_paging(l1t) )
>>> +            {
>>> +                *t = l1t;
>>> +                /* No need to unclip due to check below */
>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>> +            }
>>>            }
>>>
>>>            unmap_domain_page(l1e);
>>> -        return _mfn(INVALID_MFN);
>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>        }
>>>        mfn = _mfn(l1e_get_pfn(*l1e));
>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>                        flags = l1e_get_flags(l1e[i1]);
>>>                        if ( p2m_flags_to_type(flags) != ot )
>>>                            continue;
>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>                        gfn = i1 + (i2 + (i3
>>>    #if CONFIG_PAGING_LEVELS>= 4
>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>                               * L2_PAGETABLE_ENTRIES) *
>>> L1_PAGETABLE_ENTRIES;
>>>                        /* create a new 1le entry with the new type */
>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>> flags);
>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>                                             l1mfn, l1e_content, 1);
>>>                    }
>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>                                    entry_count++;
>>>                                continue;
>>>                            }
>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>                            ASSERT(mfn_valid(_mfn(mfn)));
>>>                            m2pfn = get_gpfn_from_mfn(mfn);
>>>                            if ( m2pfn != gfn&&
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:01:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhIL-0003Co-CR; Wed, 15 Feb 2012 16: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 1RxhIK-0003Cg-K1; Wed, 15 Feb 2012 16:01:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329321654!53051759!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21458 invoked from network); 15 Feb 2012 16:00:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10720813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:01:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 16:01:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxhID-0001eH-FE; Wed, 15 Feb 2012 16:01:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxhID-0000NA-EM;
	Wed, 15 Feb 2012 16:01:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.54989.228411.19425@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 16:01:17 +0000
To: xen-users@lists.xen.org,
    xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen mailing lists, hostname change to xen.org
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These mailing lists, and the other Open Source Xen mailing lists, have
for a long time used the domain name "xensource.com".  This is rather
out of date now :-) and also it makes the listserver produce links to
some old list archives.

So we are going to change the hostname which is used by the mailing
list software in its outgoing messages, for example in the various
headers like List-Id etc., and the mailing list footer.

If you are filtering your list email you will probably need to update
your filters.

This change will take place some time in the next few days.

NB this change affects only the contents of outgoing email headers,
links, etc.; the mechanisms for subscribing/unsubscribing, and for
posting to the list, will remain unchanged.  But we would encourage
people who want to post to the lists to use the address @xen.org
rather the old one @xensource.com.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:01:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:01:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhIL-0003Co-CR; Wed, 15 Feb 2012 16: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 1RxhIK-0003Cg-K1; Wed, 15 Feb 2012 16:01:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329321654!53051759!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21458 invoked from network); 15 Feb 2012 16:00:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10720813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:01:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 16:01:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxhID-0001eH-FE; Wed, 15 Feb 2012 16:01:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxhID-0000NA-EM;
	Wed, 15 Feb 2012 16:01:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.54989.228411.19425@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 16:01:17 +0000
To: xen-users@lists.xen.org,
    xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Xen mailing lists, hostname change to xen.org
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These mailing lists, and the other Open Source Xen mailing lists, have
for a long time used the domain name "xensource.com".  This is rather
out of date now :-) and also it makes the listserver produce links to
some old list archives.

So we are going to change the hostname which is used by the mailing
list software in its outgoing messages, for example in the various
headers like List-Id etc., and the mailing list footer.

If you are filtering your list email you will probably need to update
your filters.

This change will take place some time in the next few days.

NB this change affects only the contents of outgoing email headers,
links, etc.; the mechanisms for subscribing/unsubscribing, and for
posting to the list, will remain unchanged.  But we would encourage
people who want to post to the lists to use the address @xen.org
rather the old one @xensource.com.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:02:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhIc-0003Dg-G1; Wed, 15 Feb 2012 16:01:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxhIZ-0003DB-Vf
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:01:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329321692!13298991!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16603 invoked from network); 15 Feb 2012 16:01:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 16:01:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 16:01:31 +0000
Message-Id: <4F3BE4EB020000780007333A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 16:01:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part012F78CB.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenoprof: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part012F78CB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- frame Xen-specific additions with CONFIG_XEN conditionals
- use per-CPU data

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/oprofile/buffer_sync.c
+++ b/drivers/oprofile/buffer_sync.c
@@ -42,7 +42,10 @@ static cpumask_t marked_cpus =3D CPU_MASK_
 static DEFINE_SPINLOCK(task_mortuary);
 static void process_task_mortuary(void);
=20
+#ifdef CONFIG_XEN
-static int cpu_current_domain[NR_CPUS];
+#include <linux/percpu.h>
+static DEFINE_PER_CPU(int, current_domain) =3D COORDINATOR_DOMAIN;
+#endif
=20
 /* Take ownership of the task struct and place it on the
  * list for processing. Only after two full buffer syncs
@@ -151,11 +154,12 @@ static void end_sync(void)
 int sync_start(void)
 {
 	int err;
-	int i;
+#ifdef CONFIG_XEN
+	unsigned int cpu;
=20
-	for (i =3D 0; i < NR_CPUS; i++) {
-		cpu_current_domain[i] =3D COORDINATOR_DOMAIN;
-	}
+	for_each_online_cpu(cpu)
+		per_cpu(current_domain, cpu) =3D COORDINATOR_DOMAIN;
+#endif
=20
 	start_cpu_work();
=20
@@ -303,12 +307,14 @@ static void add_cpu_mode_switch(unsigned
 	}
 }
=20
+#ifdef CONFIG_XEN
 static void add_domain_switch(unsigned long domain_id)
 {
 	add_event_entry(ESCAPE_CODE);
 	add_event_entry(DOMAIN_SWITCH_CODE);
 	add_event_entry(domain_id);
 }
+#endif
=20
 static void
 add_user_ctx_switch(struct task_struct const * task, unsigned long =
cookie)
@@ -498,6 +504,7 @@ static void mark_done(int cpu)
 	cpus_clear(marked_cpus);
 }
=20
+#ifdef CONFIG_XEN
 /* Add IBS samples into event buffer */
 #define IBS_FETCH_SIZE	8
 #define IBS_OP_SIZE		14
@@ -559,6 +566,9 @@ static int add_ibs_data(int cpu, struct=20
=20
 	return size;
 }
+#else
+#define add_ibs_data(cpu, mm, cpu_mode) 0
+#endif
=20
 /* FIXME: this is not sufficient if we implement syscall barrier =
backtrace
  * traversal, the code switch to sb_sample_start at first kernel =
enter/exit
@@ -594,11 +604,12 @@ void sync_buffer(int cpu)
 =20
 	add_cpu_switch(cpu);
=20
+#ifdef CONFIG_XEN
 	/* We need to assign the first samples in this CPU buffer to the
 	   same domain that we were processing at the last sync_buffer */
-	if (cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {
-		add_domain_switch(cpu_current_domain[cpu]);
-	}
+	if (per_cpu(current_domain, cpu) !=3D COORDINATOR_DOMAIN)
+		add_domain_switch(per_cpu(current_domain, cpu));
+#endif
 	/* Remember, only we can modify tail_pos */
=20
 	available =3D get_slots(cpu_buf);
@@ -616,8 +627,10 @@ void sync_buffer(int cpu)
 			} else if (s->event =3D=3D CPU_TRACE_BEGIN) {
 				state =3D sb_bt_start;
 				add_trace_begin();
+#ifdef CONFIG_XEN
 			} else if (s->event =3D=3D CPU_DOMAIN_SWITCH) {
-					domain_switch =3D 1;			=
=09
+				domain_switch =3D 1;
+#endif
 			} else {
 				struct mm_struct * oldmm =3D mm;
=20
@@ -633,21 +646,23 @@ void sync_buffer(int cpu)
 			is_ibs_sample =3D add_ibs_data(cpu, mm, cpu_mode);
=20
 		} else {
+#ifdef CONFIG_XEN
 			if (domain_switch) {
-				cpu_current_domain[cpu] =3D s->eip;
+				per_cpu(current_domain, cpu) =3D s->eip;
 				add_domain_switch(s->eip);
 				domain_switch =3D 0;
-			} else if (!is_ibs_sample) {
-				if (cpu_current_domain[cpu] !=3D
-				    COORDINATOR_DOMAIN) {
-					add_sample_entry(s->eip, s->event);=

-				}
-				else  if (state >=3D sb_bt_start &&
-				    !add_sample(mm, s, cpu_mode)) {
-					if (state =3D=3D sb_bt_start) {
-						state =3D sb_bt_ignore;
-						atomic_inc(&oprofile_stats.=
bt_lost_no_mapping);
-					}
+			} else if (is_ibs_sample)
+				;
+			else if (per_cpu(current_domain, cpu) !=3D
+				 COORDINATOR_DOMAIN) {
+				add_sample_entry(s->eip, s->event);
+			} else
+#endif
+			if (state >=3D sb_bt_start &&
+			    !add_sample(mm, s, cpu_mode)) {
+				if (state =3D=3D sb_bt_start) {
+					state =3D sb_bt_ignore;
+					atomic_inc(&oprofile_stats.bt_lost_=
no_mapping);
 				}
 			}
 		}
@@ -656,10 +671,11 @@ void sync_buffer(int cpu)
 	}
 	release_mm(mm);
=20
+#ifdef CONFIG_XEN
 	/* We reset domain to COORDINATOR at each CPU switch */
-	if (cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {
+	if (per_cpu(current_domain, cpu) !=3D COORDINATOR_DOMAIN)
 		add_domain_switch(COORDINATOR_DOMAIN);
-	}
+#endif
=20
 	mark_done(cpu);
=20
--- a/drivers/oprofile/cpu_buffer.c
+++ b/drivers/oprofile/cpu_buffer.c
@@ -38,7 +38,11 @@ static void wq_sync_buffer(void *);
 #define DEFAULT_TIMER_EXPIRE (HZ / 10)
 static int work_enabled;
=20
+#ifndef CONFIG_XEN
+#define current_domain COORDINATOR_DOMAIN
+#else
 static int32_t current_domain =3D COORDINATOR_DOMAIN;
+#endif
=20
 void free_cpu_buffers(void)
 {
@@ -202,8 +206,10 @@ static int log_sample(struct oprofile_cp
 		add_code(cpu_buf, (unsigned long)task);
 	}
=20
+#ifdef CONFIG_XEN
 	if (pc =3D=3D IBS_FETCH_CODE || pc =3D=3D IBS_OP_CODE)
 		add_code(cpu_buf, cpu_mode);
+#endif
=20
 	add_sample(cpu_buf, pc, event);
 	return 1;
@@ -284,6 +290,7 @@ void oprofile_add_trace(unsigned long pc
 	add_sample(cpu_buf, pc, 0);
 }
=20
+#ifdef CONFIG_XEN
 int oprofile_add_domain_switch(int32_t domain_id)
 {
 	struct oprofile_cpu_buffer * cpu_buf =3D &cpu_buffer[smp_processor_=
id()];
@@ -302,6 +309,7 @@ int oprofile_add_domain_switch(int32_t d
=20
 	return 1;
 }
+#endif
=20
 /*
  * This serves to avoid cpu buffer overflow, and makes sure
--- a/drivers/oprofile/oprof.c
+++ b/drivers/oprofile/oprof.c
@@ -37,6 +37,7 @@ static DECLARE_MUTEX(start_sem);
  */
 static int timer =3D 0;
=20
+#ifdef CONFIG_XEN
 int oprofile_set_active(int active_domains[], unsigned int adomains)
 {
 	int err;
@@ -62,6 +63,7 @@ int oprofile_set_passive(int passive_dom
 	mutex_unlock(&start_mutex);
 	return err;
 }
+#endif
=20
 int oprofile_setup(void)
 {
--- a/drivers/oprofile/oprofile_files.c
+++ b/drivers/oprofile/oprofile_files.c
@@ -21,7 +21,11 @@
 #include "oprof.h"
=20
 unsigned long fs_buffer_size =3D 131072;
-unsigned long fs_cpu_buffer_size =3D 131072;
+#ifndef CONFIG_XEN
+unsigned long fs_cpu_buffer_size =3D 8192;
+#else
+unsigned long fs_cpu_buffer_size =3D 32768;
+#endif
 unsigned long fs_buffer_watershed =3D 32768; /* FIXME: tune */
=20
 static ssize_t depth_read(struct file * file, char __user * buf, size_t =
count, loff_t * offset)
@@ -124,6 +128,8 @@ static struct file_operations dump_fops=20
 	.write		=3D dump_write,
 };
=20
+#ifdef CONFIG_XEN
+
 #define TMPBUFSIZE 512
=20
 struct domain_data {
@@ -228,8 +234,8 @@ static DEFINE_DOMAIN_DATA(active);
=20
 static int adomain_open(struct inode *inode, struct file *filp)
 {
-    filp->private_data =3D &active_domains;
-    return 0;
+	filp->private_data =3D &active_domains;
+	return 0;
 }
=20
 static const struct file_operations active_domain_ops =3D {
@@ -242,8 +248,8 @@ static const struct file_operations acti
=20
 static int pdomain_open(struct inode *inode, struct file *filp)
 {
-    filp->private_data =3D &passive_domains;
-    return 0;
+	filp->private_data =3D &passive_domains;
+	return 0;
 }
=20
 static const struct file_operations passive_domain_ops =3D {
@@ -252,12 +258,16 @@ static const struct file_operations pass
 	.write		=3D domain_write,
 };
=20
+#endif /* CONFIG_XEN */
+
 void oprofile_create_files(struct super_block * sb, struct dentry * root)
 {
 	oprofilefs_create_file(sb, root, "enable", &enable_fops);
 	oprofilefs_create_file_perm(sb, root, "dump", &dump_fops, 0666);
+#ifdef CONFIG_XEN
 	oprofilefs_create_file(sb, root, "active_domains", &active_domain_o=
ps);
 	oprofilefs_create_file(sb, root, "passive_domains", &passive_domain=
_ops);
+#endif
 	oprofilefs_create_file(sb, root, "buffer", &event_buffer_fops);
 	oprofilefs_create_ulong(sb, root, "buffer_size", &fs_buffer_size);
 	oprofilefs_create_ulong(sb, root, "buffer_watershed", &fs_buffer_wa=
tershed);
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -16,8 +16,9 @@
 #include <linux/types.h>
 #include <linux/spinlock.h>
 #include <asm/atomic.h>
-
+#ifdef CONFIG_XEN
 #include <xen/interface/xenoprof.h>
+#endif
 =20
 struct super_block;
 struct dentry;
@@ -29,11 +30,12 @@ struct oprofile_operations {
 	/* create any necessary configuration files in the oprofile fs.
 	 * Optional. */
 	int (*create_files)(struct super_block * sb, struct dentry * =
root);
+#ifdef CONFIG_XEN
 	/* setup active domains with Xen */
 	int (*set_active)(int *active_domains, unsigned int adomains);
-        /* setup passive domains with Xen */
-        int (*set_passive)(int *passive_domains, unsigned int pdomains);
-=09
+	/* setup passive domains with Xen */
+	int (*set_passive)(int *passive_domains, unsigned int pdomains);
+#endif
 	/* Do any necessary interrupt setup. Optional. */
 	int (*setup)(void);
 	/* Do any necessary interrupt shutdown. Optional. */



--=__Part012F78CB.0__=
Content-Type: text/plain; name="xen-oprofile-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-oprofile-cleanup.patch"

xenoprof: cleanup=0A=0A- frame Xen-specific additions with CONFIG_XEN =
conditionals=0A- use per-CPU data=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/drivers/oprofile/buffer_sync.c=0A+++ =
b/drivers/oprofile/buffer_sync.c=0A@@ -42,7 +42,10 @@ static cpumask_t =
marked_cpus =3D CPU_MASK_=0A static DEFINE_SPINLOCK(task_mortuary);=0A =
static void process_task_mortuary(void);=0A =0A+#ifdef CONFIG_XEN=0A-static=
 int cpu_current_domain[NR_CPUS];=0A+#include <linux/percpu.h>=0A+static =
DEFINE_PER_CPU(int, current_domain) =3D COORDINATOR_DOMAIN;=0A+#endif=0A =
=0A /* Take ownership of the task struct and place it on the=0A  * list =
for processing. Only after two full buffer syncs=0A@@ -151,11 +154,12 @@ =
static void end_sync(void)=0A int sync_start(void)=0A {=0A 	int =
err;=0A-	int i;=0A+#ifdef CONFIG_XEN=0A+	unsigned int cpu;=0A =0A-	=
for (i =3D 0; i < NR_CPUS; i++) {=0A-		cpu_current_domain[i] =3D =
COORDINATOR_DOMAIN;=0A-	}=0A+	for_each_online_cpu(cpu)=0A+		=
per_cpu(current_domain, cpu) =3D COORDINATOR_DOMAIN;=0A+#endif=0A =0A 	=
start_cpu_work();=0A =0A@@ -303,12 +307,14 @@ static void add_cpu_mode_swit=
ch(unsigned=0A 	}=0A }=0A =0A+#ifdef CONFIG_XEN=0A static void add_domain_s=
witch(unsigned long domain_id)=0A {=0A 	add_event_entry(ESCAPE_CODE);=0A 	=
add_event_entry(DOMAIN_SWITCH_CODE);=0A 	add_event_entry(domain_id);=
=0A }=0A+#endif=0A =0A static void=0A add_user_ctx_switch(struct task_struc=
t const * task, unsigned long cookie)=0A@@ -498,6 +504,7 @@ static void =
mark_done(int cpu)=0A 	cpus_clear(marked_cpus);=0A }=0A =0A+#ifdef =
CONFIG_XEN=0A /* Add IBS samples into event buffer */=0A #define IBS_FETCH_=
SIZE	8=0A #define IBS_OP_SIZE		14=0A@@ -559,6 +566,9 @@ =
static int add_ibs_data(int cpu, struct =0A =0A 	return size;=0A =
}=0A+#else=0A+#define add_ibs_data(cpu, mm, cpu_mode) 0=0A+#endif=0A =0A =
/* FIXME: this is not sufficient if we implement syscall barrier =
backtrace=0A  * traversal, the code switch to sb_sample_start at first =
kernel enter/exit=0A@@ -594,11 +604,12 @@ void sync_buffer(int cpu)=0A  =
=0A 	add_cpu_switch(cpu);=0A =0A+#ifdef CONFIG_XEN=0A 	/* We need =
to assign the first samples in this CPU buffer to the=0A 	   same =
domain that we were processing at the last sync_buffer */=0A-	if =
(cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {=0A-		add_domain_=
switch(cpu_current_domain[cpu]);=0A-	}=0A+	if (per_cpu(current_domain,=
 cpu) !=3D COORDINATOR_DOMAIN)=0A+		add_domain_switch(per_cpu(c=
urrent_domain, cpu));=0A+#endif=0A 	/* Remember, only we can modify =
tail_pos */=0A =0A 	available =3D get_slots(cpu_buf);=0A@@ -616,8 =
+627,10 @@ void sync_buffer(int cpu)=0A 			} else if =
(s->event =3D=3D CPU_TRACE_BEGIN) {=0A 				state =3D =
sb_bt_start;=0A 				add_trace_begin();=0A+#ifde=
f CONFIG_XEN=0A 			} else if (s->event =3D=3D =
CPU_DOMAIN_SWITCH) {=0A-					domain_swit=
ch =3D 1;				=0A+				=
domain_switch =3D 1;=0A+#endif=0A 			} else {=0A 		=
		struct mm_struct * oldmm =3D mm;=0A =0A@@ -633,21 +646,23 =
@@ void sync_buffer(int cpu)=0A 			is_ibs_sample =3D =
add_ibs_data(cpu, mm, cpu_mode);=0A =0A 		} else {=0A+#ifdef =
CONFIG_XEN=0A 			if (domain_switch) {=0A-			=
	cpu_current_domain[cpu] =3D s->eip;=0A+				=
per_cpu(current_domain, cpu) =3D s->eip;=0A 				=
add_domain_switch(s->eip);=0A 				domain_switch =3D =
0;=0A-			} else if (!is_ibs_sample) {=0A-			=
	if (cpu_current_domain[cpu] !=3D=0A-				   =
 COORDINATOR_DOMAIN) {=0A-					add_sample_=
entry(s->eip, s->event);=0A-				}=0A-			=
	else  if (state >=3D sb_bt_start &&=0A-				   =
 !add_sample(mm, s, cpu_mode)) {=0A-					if =
(state =3D=3D sb_bt_start) {=0A-						=
state =3D sb_bt_ignore;=0A-						=
atomic_inc(&oprofile_stats.bt_lost_no_mapping);=0A-				=
	}=0A+			} else if (is_ibs_sample)=0A+			=
	;=0A+			else if (per_cpu(current_domain, cpu) =
!=3D=0A+				 COORDINATOR_DOMAIN) {=0A+		=
		add_sample_entry(s->eip, s->event);=0A+			} =
else=0A+#endif=0A+			if (state >=3D sb_bt_start &&=0A+	=
		    !add_sample(mm, s, cpu_mode)) {=0A+				=
if (state =3D=3D sb_bt_start) {=0A+					=
state =3D sb_bt_ignore;=0A+					atomic_inc(=
&oprofile_stats.bt_lost_no_mapping);=0A 				=
}=0A 			}=0A 		}=0A@@ -656,10 +671,11 @@ void =
sync_buffer(int cpu)=0A 	}=0A 	release_mm(mm);=0A =0A+#ifdef =
CONFIG_XEN=0A 	/* We reset domain to COORDINATOR at each CPU switch =
*/=0A-	if (cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {=0A+	if =
(per_cpu(current_domain, cpu) !=3D COORDINATOR_DOMAIN)=0A 		=
add_domain_switch(COORDINATOR_DOMAIN);=0A-	}=0A+#endif=0A =0A 	=
mark_done(cpu);=0A =0A--- a/drivers/oprofile/cpu_buffer.c=0A+++ b/drivers/o=
profile/cpu_buffer.c=0A@@ -38,7 +38,11 @@ static void wq_sync_buffer(void =
*);=0A #define DEFAULT_TIMER_EXPIRE (HZ / 10)=0A static int work_enabled;=
=0A =0A+#ifndef CONFIG_XEN=0A+#define current_domain COORDINATOR_DOMAIN=0A+=
#else=0A static int32_t current_domain =3D COORDINATOR_DOMAIN;=0A+#endif=0A=
 =0A void free_cpu_buffers(void)=0A {=0A@@ -202,8 +206,10 @@ static int =
log_sample(struct oprofile_cp=0A 		add_code(cpu_buf, =
(unsigned long)task);=0A 	}=0A =0A+#ifdef CONFIG_XEN=0A 	if (pc =
=3D=3D IBS_FETCH_CODE || pc =3D=3D IBS_OP_CODE)=0A 		add_code(cp=
u_buf, cpu_mode);=0A+#endif=0A =0A 	add_sample(cpu_buf, pc, event);=0A =
	return 1;=0A@@ -284,6 +290,7 @@ void oprofile_add_trace(unsigned =
long pc=0A 	add_sample(cpu_buf, pc, 0);=0A }=0A =0A+#ifdef CONFIG_XEN=
=0A int oprofile_add_domain_switch(int32_t domain_id)=0A {=0A 	struct =
oprofile_cpu_buffer * cpu_buf =3D &cpu_buffer[smp_processor_id()];=0A@@ =
-302,6 +309,7 @@ int oprofile_add_domain_switch(int32_t d=0A =0A 	=
return 1;=0A }=0A+#endif=0A =0A /*=0A  * This serves to avoid cpu buffer =
overflow, and makes sure=0A--- a/drivers/oprofile/oprof.c=0A+++ b/drivers/o=
profile/oprof.c=0A@@ -37,6 +37,7 @@ static DECLARE_MUTEX(start_sem);=0A  =
*/=0A static int timer =3D 0;=0A =0A+#ifdef CONFIG_XEN=0A int oprofile_set_=
active(int active_domains[], unsigned int adomains)=0A {=0A 	int =
err;=0A@@ -62,6 +63,7 @@ int oprofile_set_passive(int passive_dom=0A 	=
mutex_unlock(&start_mutex);=0A 	return err;=0A }=0A+#endif=0A =0A int =
oprofile_setup(void)=0A {=0A--- a/drivers/oprofile/oprofile_files.c=0A+++ =
b/drivers/oprofile/oprofile_files.c=0A@@ -21,7 +21,11 @@=0A #include =
"oprof.h"=0A =0A unsigned long fs_buffer_size =3D 131072;=0A-unsigned long =
fs_cpu_buffer_size =3D 131072;=0A+#ifndef CONFIG_XEN=0A+unsigned long =
fs_cpu_buffer_size =3D 8192;=0A+#else=0A+unsigned long fs_cpu_buffer_size =
=3D 32768;=0A+#endif=0A unsigned long fs_buffer_watershed =3D 32768; /* =
FIXME: tune */=0A =0A static ssize_t depth_read(struct file * file, char =
__user * buf, size_t count, loff_t * offset)=0A@@ -124,6 +128,8 @@ static =
struct file_operations dump_fops =0A 	.write		=3D dump_write,=0A =
};=0A =0A+#ifdef CONFIG_XEN=0A+=0A #define TMPBUFSIZE 512=0A =0A struct =
domain_data {=0A@@ -228,8 +234,8 @@ static DEFINE_DOMAIN_DATA(active);=0A =
=0A static int adomain_open(struct inode *inode, struct file *filp)=0A =
{=0A-    filp->private_data =3D &active_domains;=0A-    return 0;=0A+	=
filp->private_data =3D &active_domains;=0A+	return 0;=0A }=0A =0A =
static const struct file_operations active_domain_ops =3D {=0A@@ -242,8 =
+248,8 @@ static const struct file_operations acti=0A =0A static int =
pdomain_open(struct inode *inode, struct file *filp)=0A {=0A-    filp->priv=
ate_data =3D &passive_domains;=0A-    return 0;=0A+	filp->private_data =
=3D &passive_domains;=0A+	return 0;=0A }=0A =0A static const struct =
file_operations passive_domain_ops =3D {=0A@@ -252,12 +258,16 @@ static =
const struct file_operations pass=0A 	.write		=3D domain_write,=
=0A };=0A =0A+#endif /* CONFIG_XEN */=0A+=0A void oprofile_create_files(str=
uct super_block * sb, struct dentry * root)=0A {=0A 	oprofilefs_create_f=
ile(sb, root, "enable", &enable_fops);=0A 	oprofilefs_create_file_perm=
(sb, root, "dump", &dump_fops, 0666);=0A+#ifdef CONFIG_XEN=0A 	oprofilefs_=
create_file(sb, root, "active_domains", &active_domain_ops);=0A 	=
oprofilefs_create_file(sb, root, "passive_domains", &passive_domain_ops);=
=0A+#endif=0A 	oprofilefs_create_file(sb, root, "buffer", &event_buffer_fo=
ps);=0A 	oprofilefs_create_ulong(sb, root, "buffer_size", &fs_buffer=
_size);=0A 	oprofilefs_create_ulong(sb, root, "buffer_watershed", =
&fs_buffer_watershed);=0A--- a/include/linux/oprofile.h=0A+++ b/include/lin=
ux/oprofile.h=0A@@ -16,8 +16,9 @@=0A #include <linux/types.h>=0A #include =
<linux/spinlock.h>=0A #include <asm/atomic.h>=0A-=0A+#ifdef CONFIG_XEN=0A =
#include <xen/interface/xenoprof.h>=0A+#endif=0A  =0A struct super_block;=
=0A struct dentry;=0A@@ -29,11 +30,12 @@ struct oprofile_operations {=0A 	=
/* create any necessary configuration files in the oprofile fs.=0A 	 * =
Optional. */=0A 	int (*create_files)(struct super_block * sb, =
struct dentry * root);=0A+#ifdef CONFIG_XEN=0A 	/* setup active domains =
with Xen */=0A 	int (*set_active)(int *active_domains, unsigned int =
adomains);=0A-        /* setup passive domains with Xen */=0A-        int =
(*set_passive)(int *passive_domains, unsigned int pdomains);=0A-	=
=0A+	/* setup passive domains with Xen */=0A+	int (*set_passive)(=
int *passive_domains, unsigned int pdomains);=0A+#endif=0A 	/* Do any =
necessary interrupt setup. Optional. */=0A 	int (*setup)(void);=0A 	/* =
Do any necessary interrupt shutdown. Optional. */=0A
--=__Part012F78CB.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part012F78CB.0__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:02:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhIc-0003Dg-G1; Wed, 15 Feb 2012 16:01:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxhIZ-0003DB-Vf
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:01:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329321692!13298991!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16603 invoked from network); 15 Feb 2012 16:01:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 16:01:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 15 Feb 2012 16:01:31 +0000
Message-Id: <4F3BE4EB020000780007333A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 15 Feb 2012 16:01:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part012F78CB.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenoprof: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part012F78CB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- frame Xen-specific additions with CONFIG_XEN conditionals
- use per-CPU data

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/oprofile/buffer_sync.c
+++ b/drivers/oprofile/buffer_sync.c
@@ -42,7 +42,10 @@ static cpumask_t marked_cpus =3D CPU_MASK_
 static DEFINE_SPINLOCK(task_mortuary);
 static void process_task_mortuary(void);
=20
+#ifdef CONFIG_XEN
-static int cpu_current_domain[NR_CPUS];
+#include <linux/percpu.h>
+static DEFINE_PER_CPU(int, current_domain) =3D COORDINATOR_DOMAIN;
+#endif
=20
 /* Take ownership of the task struct and place it on the
  * list for processing. Only after two full buffer syncs
@@ -151,11 +154,12 @@ static void end_sync(void)
 int sync_start(void)
 {
 	int err;
-	int i;
+#ifdef CONFIG_XEN
+	unsigned int cpu;
=20
-	for (i =3D 0; i < NR_CPUS; i++) {
-		cpu_current_domain[i] =3D COORDINATOR_DOMAIN;
-	}
+	for_each_online_cpu(cpu)
+		per_cpu(current_domain, cpu) =3D COORDINATOR_DOMAIN;
+#endif
=20
 	start_cpu_work();
=20
@@ -303,12 +307,14 @@ static void add_cpu_mode_switch(unsigned
 	}
 }
=20
+#ifdef CONFIG_XEN
 static void add_domain_switch(unsigned long domain_id)
 {
 	add_event_entry(ESCAPE_CODE);
 	add_event_entry(DOMAIN_SWITCH_CODE);
 	add_event_entry(domain_id);
 }
+#endif
=20
 static void
 add_user_ctx_switch(struct task_struct const * task, unsigned long =
cookie)
@@ -498,6 +504,7 @@ static void mark_done(int cpu)
 	cpus_clear(marked_cpus);
 }
=20
+#ifdef CONFIG_XEN
 /* Add IBS samples into event buffer */
 #define IBS_FETCH_SIZE	8
 #define IBS_OP_SIZE		14
@@ -559,6 +566,9 @@ static int add_ibs_data(int cpu, struct=20
=20
 	return size;
 }
+#else
+#define add_ibs_data(cpu, mm, cpu_mode) 0
+#endif
=20
 /* FIXME: this is not sufficient if we implement syscall barrier =
backtrace
  * traversal, the code switch to sb_sample_start at first kernel =
enter/exit
@@ -594,11 +604,12 @@ void sync_buffer(int cpu)
 =20
 	add_cpu_switch(cpu);
=20
+#ifdef CONFIG_XEN
 	/* We need to assign the first samples in this CPU buffer to the
 	   same domain that we were processing at the last sync_buffer */
-	if (cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {
-		add_domain_switch(cpu_current_domain[cpu]);
-	}
+	if (per_cpu(current_domain, cpu) !=3D COORDINATOR_DOMAIN)
+		add_domain_switch(per_cpu(current_domain, cpu));
+#endif
 	/* Remember, only we can modify tail_pos */
=20
 	available =3D get_slots(cpu_buf);
@@ -616,8 +627,10 @@ void sync_buffer(int cpu)
 			} else if (s->event =3D=3D CPU_TRACE_BEGIN) {
 				state =3D sb_bt_start;
 				add_trace_begin();
+#ifdef CONFIG_XEN
 			} else if (s->event =3D=3D CPU_DOMAIN_SWITCH) {
-					domain_switch =3D 1;			=
=09
+				domain_switch =3D 1;
+#endif
 			} else {
 				struct mm_struct * oldmm =3D mm;
=20
@@ -633,21 +646,23 @@ void sync_buffer(int cpu)
 			is_ibs_sample =3D add_ibs_data(cpu, mm, cpu_mode);
=20
 		} else {
+#ifdef CONFIG_XEN
 			if (domain_switch) {
-				cpu_current_domain[cpu] =3D s->eip;
+				per_cpu(current_domain, cpu) =3D s->eip;
 				add_domain_switch(s->eip);
 				domain_switch =3D 0;
-			} else if (!is_ibs_sample) {
-				if (cpu_current_domain[cpu] !=3D
-				    COORDINATOR_DOMAIN) {
-					add_sample_entry(s->eip, s->event);=

-				}
-				else  if (state >=3D sb_bt_start &&
-				    !add_sample(mm, s, cpu_mode)) {
-					if (state =3D=3D sb_bt_start) {
-						state =3D sb_bt_ignore;
-						atomic_inc(&oprofile_stats.=
bt_lost_no_mapping);
-					}
+			} else if (is_ibs_sample)
+				;
+			else if (per_cpu(current_domain, cpu) !=3D
+				 COORDINATOR_DOMAIN) {
+				add_sample_entry(s->eip, s->event);
+			} else
+#endif
+			if (state >=3D sb_bt_start &&
+			    !add_sample(mm, s, cpu_mode)) {
+				if (state =3D=3D sb_bt_start) {
+					state =3D sb_bt_ignore;
+					atomic_inc(&oprofile_stats.bt_lost_=
no_mapping);
 				}
 			}
 		}
@@ -656,10 +671,11 @@ void sync_buffer(int cpu)
 	}
 	release_mm(mm);
=20
+#ifdef CONFIG_XEN
 	/* We reset domain to COORDINATOR at each CPU switch */
-	if (cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {
+	if (per_cpu(current_domain, cpu) !=3D COORDINATOR_DOMAIN)
 		add_domain_switch(COORDINATOR_DOMAIN);
-	}
+#endif
=20
 	mark_done(cpu);
=20
--- a/drivers/oprofile/cpu_buffer.c
+++ b/drivers/oprofile/cpu_buffer.c
@@ -38,7 +38,11 @@ static void wq_sync_buffer(void *);
 #define DEFAULT_TIMER_EXPIRE (HZ / 10)
 static int work_enabled;
=20
+#ifndef CONFIG_XEN
+#define current_domain COORDINATOR_DOMAIN
+#else
 static int32_t current_domain =3D COORDINATOR_DOMAIN;
+#endif
=20
 void free_cpu_buffers(void)
 {
@@ -202,8 +206,10 @@ static int log_sample(struct oprofile_cp
 		add_code(cpu_buf, (unsigned long)task);
 	}
=20
+#ifdef CONFIG_XEN
 	if (pc =3D=3D IBS_FETCH_CODE || pc =3D=3D IBS_OP_CODE)
 		add_code(cpu_buf, cpu_mode);
+#endif
=20
 	add_sample(cpu_buf, pc, event);
 	return 1;
@@ -284,6 +290,7 @@ void oprofile_add_trace(unsigned long pc
 	add_sample(cpu_buf, pc, 0);
 }
=20
+#ifdef CONFIG_XEN
 int oprofile_add_domain_switch(int32_t domain_id)
 {
 	struct oprofile_cpu_buffer * cpu_buf =3D &cpu_buffer[smp_processor_=
id()];
@@ -302,6 +309,7 @@ int oprofile_add_domain_switch(int32_t d
=20
 	return 1;
 }
+#endif
=20
 /*
  * This serves to avoid cpu buffer overflow, and makes sure
--- a/drivers/oprofile/oprof.c
+++ b/drivers/oprofile/oprof.c
@@ -37,6 +37,7 @@ static DECLARE_MUTEX(start_sem);
  */
 static int timer =3D 0;
=20
+#ifdef CONFIG_XEN
 int oprofile_set_active(int active_domains[], unsigned int adomains)
 {
 	int err;
@@ -62,6 +63,7 @@ int oprofile_set_passive(int passive_dom
 	mutex_unlock(&start_mutex);
 	return err;
 }
+#endif
=20
 int oprofile_setup(void)
 {
--- a/drivers/oprofile/oprofile_files.c
+++ b/drivers/oprofile/oprofile_files.c
@@ -21,7 +21,11 @@
 #include "oprof.h"
=20
 unsigned long fs_buffer_size =3D 131072;
-unsigned long fs_cpu_buffer_size =3D 131072;
+#ifndef CONFIG_XEN
+unsigned long fs_cpu_buffer_size =3D 8192;
+#else
+unsigned long fs_cpu_buffer_size =3D 32768;
+#endif
 unsigned long fs_buffer_watershed =3D 32768; /* FIXME: tune */
=20
 static ssize_t depth_read(struct file * file, char __user * buf, size_t =
count, loff_t * offset)
@@ -124,6 +128,8 @@ static struct file_operations dump_fops=20
 	.write		=3D dump_write,
 };
=20
+#ifdef CONFIG_XEN
+
 #define TMPBUFSIZE 512
=20
 struct domain_data {
@@ -228,8 +234,8 @@ static DEFINE_DOMAIN_DATA(active);
=20
 static int adomain_open(struct inode *inode, struct file *filp)
 {
-    filp->private_data =3D &active_domains;
-    return 0;
+	filp->private_data =3D &active_domains;
+	return 0;
 }
=20
 static const struct file_operations active_domain_ops =3D {
@@ -242,8 +248,8 @@ static const struct file_operations acti
=20
 static int pdomain_open(struct inode *inode, struct file *filp)
 {
-    filp->private_data =3D &passive_domains;
-    return 0;
+	filp->private_data =3D &passive_domains;
+	return 0;
 }
=20
 static const struct file_operations passive_domain_ops =3D {
@@ -252,12 +258,16 @@ static const struct file_operations pass
 	.write		=3D domain_write,
 };
=20
+#endif /* CONFIG_XEN */
+
 void oprofile_create_files(struct super_block * sb, struct dentry * root)
 {
 	oprofilefs_create_file(sb, root, "enable", &enable_fops);
 	oprofilefs_create_file_perm(sb, root, "dump", &dump_fops, 0666);
+#ifdef CONFIG_XEN
 	oprofilefs_create_file(sb, root, "active_domains", &active_domain_o=
ps);
 	oprofilefs_create_file(sb, root, "passive_domains", &passive_domain=
_ops);
+#endif
 	oprofilefs_create_file(sb, root, "buffer", &event_buffer_fops);
 	oprofilefs_create_ulong(sb, root, "buffer_size", &fs_buffer_size);
 	oprofilefs_create_ulong(sb, root, "buffer_watershed", &fs_buffer_wa=
tershed);
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -16,8 +16,9 @@
 #include <linux/types.h>
 #include <linux/spinlock.h>
 #include <asm/atomic.h>
-
+#ifdef CONFIG_XEN
 #include <xen/interface/xenoprof.h>
+#endif
 =20
 struct super_block;
 struct dentry;
@@ -29,11 +30,12 @@ struct oprofile_operations {
 	/* create any necessary configuration files in the oprofile fs.
 	 * Optional. */
 	int (*create_files)(struct super_block * sb, struct dentry * =
root);
+#ifdef CONFIG_XEN
 	/* setup active domains with Xen */
 	int (*set_active)(int *active_domains, unsigned int adomains);
-        /* setup passive domains with Xen */
-        int (*set_passive)(int *passive_domains, unsigned int pdomains);
-=09
+	/* setup passive domains with Xen */
+	int (*set_passive)(int *passive_domains, unsigned int pdomains);
+#endif
 	/* Do any necessary interrupt setup. Optional. */
 	int (*setup)(void);
 	/* Do any necessary interrupt shutdown. Optional. */



--=__Part012F78CB.0__=
Content-Type: text/plain; name="xen-oprofile-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-oprofile-cleanup.patch"

xenoprof: cleanup=0A=0A- frame Xen-specific additions with CONFIG_XEN =
conditionals=0A- use per-CPU data=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/drivers/oprofile/buffer_sync.c=0A+++ =
b/drivers/oprofile/buffer_sync.c=0A@@ -42,7 +42,10 @@ static cpumask_t =
marked_cpus =3D CPU_MASK_=0A static DEFINE_SPINLOCK(task_mortuary);=0A =
static void process_task_mortuary(void);=0A =0A+#ifdef CONFIG_XEN=0A-static=
 int cpu_current_domain[NR_CPUS];=0A+#include <linux/percpu.h>=0A+static =
DEFINE_PER_CPU(int, current_domain) =3D COORDINATOR_DOMAIN;=0A+#endif=0A =
=0A /* Take ownership of the task struct and place it on the=0A  * list =
for processing. Only after two full buffer syncs=0A@@ -151,11 +154,12 @@ =
static void end_sync(void)=0A int sync_start(void)=0A {=0A 	int =
err;=0A-	int i;=0A+#ifdef CONFIG_XEN=0A+	unsigned int cpu;=0A =0A-	=
for (i =3D 0; i < NR_CPUS; i++) {=0A-		cpu_current_domain[i] =3D =
COORDINATOR_DOMAIN;=0A-	}=0A+	for_each_online_cpu(cpu)=0A+		=
per_cpu(current_domain, cpu) =3D COORDINATOR_DOMAIN;=0A+#endif=0A =0A 	=
start_cpu_work();=0A =0A@@ -303,12 +307,14 @@ static void add_cpu_mode_swit=
ch(unsigned=0A 	}=0A }=0A =0A+#ifdef CONFIG_XEN=0A static void add_domain_s=
witch(unsigned long domain_id)=0A {=0A 	add_event_entry(ESCAPE_CODE);=0A 	=
add_event_entry(DOMAIN_SWITCH_CODE);=0A 	add_event_entry(domain_id);=
=0A }=0A+#endif=0A =0A static void=0A add_user_ctx_switch(struct task_struc=
t const * task, unsigned long cookie)=0A@@ -498,6 +504,7 @@ static void =
mark_done(int cpu)=0A 	cpus_clear(marked_cpus);=0A }=0A =0A+#ifdef =
CONFIG_XEN=0A /* Add IBS samples into event buffer */=0A #define IBS_FETCH_=
SIZE	8=0A #define IBS_OP_SIZE		14=0A@@ -559,6 +566,9 @@ =
static int add_ibs_data(int cpu, struct =0A =0A 	return size;=0A =
}=0A+#else=0A+#define add_ibs_data(cpu, mm, cpu_mode) 0=0A+#endif=0A =0A =
/* FIXME: this is not sufficient if we implement syscall barrier =
backtrace=0A  * traversal, the code switch to sb_sample_start at first =
kernel enter/exit=0A@@ -594,11 +604,12 @@ void sync_buffer(int cpu)=0A  =
=0A 	add_cpu_switch(cpu);=0A =0A+#ifdef CONFIG_XEN=0A 	/* We need =
to assign the first samples in this CPU buffer to the=0A 	   same =
domain that we were processing at the last sync_buffer */=0A-	if =
(cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {=0A-		add_domain_=
switch(cpu_current_domain[cpu]);=0A-	}=0A+	if (per_cpu(current_domain,=
 cpu) !=3D COORDINATOR_DOMAIN)=0A+		add_domain_switch(per_cpu(c=
urrent_domain, cpu));=0A+#endif=0A 	/* Remember, only we can modify =
tail_pos */=0A =0A 	available =3D get_slots(cpu_buf);=0A@@ -616,8 =
+627,10 @@ void sync_buffer(int cpu)=0A 			} else if =
(s->event =3D=3D CPU_TRACE_BEGIN) {=0A 				state =3D =
sb_bt_start;=0A 				add_trace_begin();=0A+#ifde=
f CONFIG_XEN=0A 			} else if (s->event =3D=3D =
CPU_DOMAIN_SWITCH) {=0A-					domain_swit=
ch =3D 1;				=0A+				=
domain_switch =3D 1;=0A+#endif=0A 			} else {=0A 		=
		struct mm_struct * oldmm =3D mm;=0A =0A@@ -633,21 +646,23 =
@@ void sync_buffer(int cpu)=0A 			is_ibs_sample =3D =
add_ibs_data(cpu, mm, cpu_mode);=0A =0A 		} else {=0A+#ifdef =
CONFIG_XEN=0A 			if (domain_switch) {=0A-			=
	cpu_current_domain[cpu] =3D s->eip;=0A+				=
per_cpu(current_domain, cpu) =3D s->eip;=0A 				=
add_domain_switch(s->eip);=0A 				domain_switch =3D =
0;=0A-			} else if (!is_ibs_sample) {=0A-			=
	if (cpu_current_domain[cpu] !=3D=0A-				   =
 COORDINATOR_DOMAIN) {=0A-					add_sample_=
entry(s->eip, s->event);=0A-				}=0A-			=
	else  if (state >=3D sb_bt_start &&=0A-				   =
 !add_sample(mm, s, cpu_mode)) {=0A-					if =
(state =3D=3D sb_bt_start) {=0A-						=
state =3D sb_bt_ignore;=0A-						=
atomic_inc(&oprofile_stats.bt_lost_no_mapping);=0A-				=
	}=0A+			} else if (is_ibs_sample)=0A+			=
	;=0A+			else if (per_cpu(current_domain, cpu) =
!=3D=0A+				 COORDINATOR_DOMAIN) {=0A+		=
		add_sample_entry(s->eip, s->event);=0A+			} =
else=0A+#endif=0A+			if (state >=3D sb_bt_start &&=0A+	=
		    !add_sample(mm, s, cpu_mode)) {=0A+				=
if (state =3D=3D sb_bt_start) {=0A+					=
state =3D sb_bt_ignore;=0A+					atomic_inc(=
&oprofile_stats.bt_lost_no_mapping);=0A 				=
}=0A 			}=0A 		}=0A@@ -656,10 +671,11 @@ void =
sync_buffer(int cpu)=0A 	}=0A 	release_mm(mm);=0A =0A+#ifdef =
CONFIG_XEN=0A 	/* We reset domain to COORDINATOR at each CPU switch =
*/=0A-	if (cpu_current_domain[cpu] !=3D COORDINATOR_DOMAIN) {=0A+	if =
(per_cpu(current_domain, cpu) !=3D COORDINATOR_DOMAIN)=0A 		=
add_domain_switch(COORDINATOR_DOMAIN);=0A-	}=0A+#endif=0A =0A 	=
mark_done(cpu);=0A =0A--- a/drivers/oprofile/cpu_buffer.c=0A+++ b/drivers/o=
profile/cpu_buffer.c=0A@@ -38,7 +38,11 @@ static void wq_sync_buffer(void =
*);=0A #define DEFAULT_TIMER_EXPIRE (HZ / 10)=0A static int work_enabled;=
=0A =0A+#ifndef CONFIG_XEN=0A+#define current_domain COORDINATOR_DOMAIN=0A+=
#else=0A static int32_t current_domain =3D COORDINATOR_DOMAIN;=0A+#endif=0A=
 =0A void free_cpu_buffers(void)=0A {=0A@@ -202,8 +206,10 @@ static int =
log_sample(struct oprofile_cp=0A 		add_code(cpu_buf, =
(unsigned long)task);=0A 	}=0A =0A+#ifdef CONFIG_XEN=0A 	if (pc =
=3D=3D IBS_FETCH_CODE || pc =3D=3D IBS_OP_CODE)=0A 		add_code(cp=
u_buf, cpu_mode);=0A+#endif=0A =0A 	add_sample(cpu_buf, pc, event);=0A =
	return 1;=0A@@ -284,6 +290,7 @@ void oprofile_add_trace(unsigned =
long pc=0A 	add_sample(cpu_buf, pc, 0);=0A }=0A =0A+#ifdef CONFIG_XEN=
=0A int oprofile_add_domain_switch(int32_t domain_id)=0A {=0A 	struct =
oprofile_cpu_buffer * cpu_buf =3D &cpu_buffer[smp_processor_id()];=0A@@ =
-302,6 +309,7 @@ int oprofile_add_domain_switch(int32_t d=0A =0A 	=
return 1;=0A }=0A+#endif=0A =0A /*=0A  * This serves to avoid cpu buffer =
overflow, and makes sure=0A--- a/drivers/oprofile/oprof.c=0A+++ b/drivers/o=
profile/oprof.c=0A@@ -37,6 +37,7 @@ static DECLARE_MUTEX(start_sem);=0A  =
*/=0A static int timer =3D 0;=0A =0A+#ifdef CONFIG_XEN=0A int oprofile_set_=
active(int active_domains[], unsigned int adomains)=0A {=0A 	int =
err;=0A@@ -62,6 +63,7 @@ int oprofile_set_passive(int passive_dom=0A 	=
mutex_unlock(&start_mutex);=0A 	return err;=0A }=0A+#endif=0A =0A int =
oprofile_setup(void)=0A {=0A--- a/drivers/oprofile/oprofile_files.c=0A+++ =
b/drivers/oprofile/oprofile_files.c=0A@@ -21,7 +21,11 @@=0A #include =
"oprof.h"=0A =0A unsigned long fs_buffer_size =3D 131072;=0A-unsigned long =
fs_cpu_buffer_size =3D 131072;=0A+#ifndef CONFIG_XEN=0A+unsigned long =
fs_cpu_buffer_size =3D 8192;=0A+#else=0A+unsigned long fs_cpu_buffer_size =
=3D 32768;=0A+#endif=0A unsigned long fs_buffer_watershed =3D 32768; /* =
FIXME: tune */=0A =0A static ssize_t depth_read(struct file * file, char =
__user * buf, size_t count, loff_t * offset)=0A@@ -124,6 +128,8 @@ static =
struct file_operations dump_fops =0A 	.write		=3D dump_write,=0A =
};=0A =0A+#ifdef CONFIG_XEN=0A+=0A #define TMPBUFSIZE 512=0A =0A struct =
domain_data {=0A@@ -228,8 +234,8 @@ static DEFINE_DOMAIN_DATA(active);=0A =
=0A static int adomain_open(struct inode *inode, struct file *filp)=0A =
{=0A-    filp->private_data =3D &active_domains;=0A-    return 0;=0A+	=
filp->private_data =3D &active_domains;=0A+	return 0;=0A }=0A =0A =
static const struct file_operations active_domain_ops =3D {=0A@@ -242,8 =
+248,8 @@ static const struct file_operations acti=0A =0A static int =
pdomain_open(struct inode *inode, struct file *filp)=0A {=0A-    filp->priv=
ate_data =3D &passive_domains;=0A-    return 0;=0A+	filp->private_data =
=3D &passive_domains;=0A+	return 0;=0A }=0A =0A static const struct =
file_operations passive_domain_ops =3D {=0A@@ -252,12 +258,16 @@ static =
const struct file_operations pass=0A 	.write		=3D domain_write,=
=0A };=0A =0A+#endif /* CONFIG_XEN */=0A+=0A void oprofile_create_files(str=
uct super_block * sb, struct dentry * root)=0A {=0A 	oprofilefs_create_f=
ile(sb, root, "enable", &enable_fops);=0A 	oprofilefs_create_file_perm=
(sb, root, "dump", &dump_fops, 0666);=0A+#ifdef CONFIG_XEN=0A 	oprofilefs_=
create_file(sb, root, "active_domains", &active_domain_ops);=0A 	=
oprofilefs_create_file(sb, root, "passive_domains", &passive_domain_ops);=
=0A+#endif=0A 	oprofilefs_create_file(sb, root, "buffer", &event_buffer_fo=
ps);=0A 	oprofilefs_create_ulong(sb, root, "buffer_size", &fs_buffer=
_size);=0A 	oprofilefs_create_ulong(sb, root, "buffer_watershed", =
&fs_buffer_watershed);=0A--- a/include/linux/oprofile.h=0A+++ b/include/lin=
ux/oprofile.h=0A@@ -16,8 +16,9 @@=0A #include <linux/types.h>=0A #include =
<linux/spinlock.h>=0A #include <asm/atomic.h>=0A-=0A+#ifdef CONFIG_XEN=0A =
#include <xen/interface/xenoprof.h>=0A+#endif=0A  =0A struct super_block;=
=0A struct dentry;=0A@@ -29,11 +30,12 @@ struct oprofile_operations {=0A 	=
/* create any necessary configuration files in the oprofile fs.=0A 	 * =
Optional. */=0A 	int (*create_files)(struct super_block * sb, =
struct dentry * root);=0A+#ifdef CONFIG_XEN=0A 	/* setup active domains =
with Xen */=0A 	int (*set_active)(int *active_domains, unsigned int =
adomains);=0A-        /* setup passive domains with Xen */=0A-        int =
(*set_passive)(int *passive_domains, unsigned int pdomains);=0A-	=
=0A+	/* setup passive domains with Xen */=0A+	int (*set_passive)(=
int *passive_domains, unsigned int pdomains);=0A+#endif=0A 	/* Do any =
necessary interrupt setup. Optional. */=0A 	int (*setup)(void);=0A 	/* =
Do any necessary interrupt shutdown. Optional. */=0A
--=__Part012F78CB.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part012F78CB.0__=--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16: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.xensource.com>)
	id 1RxhNa-0003gi-7p; Wed, 15 Feb 2012 16:06:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxhNY-0003gZ-QF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:06:49 +0000
Received: from [193.109.254.147:16075] by server-2.bemta-14.messagelabs.com id
	6E/3E-11301-818DB3F4; Wed, 15 Feb 2012 16:06:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329321954!52886389!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxMzY3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4556 invoked from network); 15 Feb 2012 16:05:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-5.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 16:05:55 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1561A76C06E;
	Wed, 15 Feb 2012 08:06:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tf/LQN35zWqGUm1B/cpvUxZ/wT3eiUnUzaEfB/Gof1cg
	odzkhJXQjefpxqQCJmuG5BdmGxXZdbbgt4eulhNd3BG2NQQHmXWEAj6kOQFzx3ce
	isVNC9yWWw7+gu+zRisMVHtHwd4QtmXYlznEweIhMUP5Jb3gBMFYLU+brHo9ugM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Dno23Agm1nKIFsGBFMLgjibvHsw=; b=CItkIR17
	QxtLtm9nXTL9Od+2rJt4KnKHM37/QbFlKsfslabkgJ8z14RXMqd3ze0qbw8tO1BP
	7q1LVJ3vRckP2GnjjNd9uhp2TMh5cEEcUvz4ALR3c+MJFObMO6MCONyWfUa1QWKz
	sbwylW6cQdVX4HuhLYa657B4/WzF3RyQi5E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 30EC676C065; 
	Wed, 15 Feb 2012 08:06:45 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 08:06:45 -0800
Message-ID: <eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3BD053.5070404@amd.com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
Date: Wed, 15 Feb 2012 08:06:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Wei Wang" <wei.wang2@amd.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>>> We started hashing out some AMD support for mem_paging and mem_access.
>>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>>> fault.
>>>>
>>>> Most importantly, I want to get somebody from AMD to comment/help out
>>>> on
>>>> this. It feels like we're inches away from enabling support for this
>>>> very
>>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>>> these
>>>> kinds of things. It'd be great to have you on board!
>>>>
>>>> For starters, the changes to the p2m code are relatively mild, but
>>>> it'd
>>>> be
>>>> great if somebody spots a red flag.
>>>>
>>>> Another issue: comments indicate that bits 59-62 in NPT entries are
>>>> used
>>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>>> (59)
>>>> would give us enough space to support mem_access. Right now we only
>>>> have
>>>> 7
>>>> bits available for Xen flags and that is not enough for paging and
>>>> access.
>>>> Is bit 59 effectively reserved?
>>>
>>> Hi
>>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
>>> are not potentially used by DMA, this bit could be non-zero. I could
>>> tested it on my iommu machines if you had some patches that use U bits.
>>
>> Hi Wei, thanks for pitching in! I assume you're talking about table 14
>> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf
>
> Yes, indeed.
>
>> I don't think this will work. The p2m access value is arbitrary, and
>> independent of the p2m type. So bit 59 is out of reach and we're stuck
>> with 7 bits for Xen use. Thanks for the clarification.
>
> Where will p2m access bit be stored? Please note that bit 52 - bit 58
> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
> and bit 1 - bit 8 are free to use if PR bit = 1.

Wei,

Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
current convention?

I propose limiting p2m type to bits 52-55, and storing p2m access on bits
56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
be zero" requirement/convention.

Right now, without any considerations for paging, we're storing the p2m
type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
course. Given your statement above, and table 14 in the IOMMU manual, how
is this even working? Or is it not working?

Would a violation of these rules cause a VMEXIT_SHUTDOWN?

Thanks a lot for the info!
Andres
>
> Thanks,
> Wei
>
>> An alternative to enabling mem_access on AMD processors will be to limit
>> the access types to 3 bits. This would force disabling support for two
>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>> they
>> make sense without R permissions.
>> Thanks!
>> Andres
>>
>>>
>>> Thanks,
>>> Wei
>>>
>>>>
>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>> Comments
>>>> welcome.
>>>>
>>>> Patch inline below, thanks!
>>>> Andres
>>>>
>>>> Enable AMD support for paging.
>>>>
>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>
>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>                if ( !hap_enabled(d) )
>>>>                    break;
>>>>
>>>> -            /* Currently only EPT is supported */
>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>> -                break;
>>>> -
>>>>                rc = -EXDEV;
>>>>                /* Disallow paging in a PoD guest */
>>>>                if ( p2m->pod.entry_count )
>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>> @@ -53,6 +53,20 @@
>>>>    #define P2M_BASE_FLAGS \
>>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>
>>>> +#ifdef __x86_64__
>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>> 0xff..ff
>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>> p2mt,
>>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) - 1))
>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>>> +                                INVALID_MFN : (mfn))
>>>> +#else
>>>> +#define clipped_mfn(mfn)    (mfn)
>>>> +#define unclip_mfn(mfn)     (mfn)
>>>> +#endif /* __x86_64__ */
>>>> +
>>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>    {
>>>>        unsigned long flags;
>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>        case p2m_invalid:
>>>>        case p2m_mmio_dm:
>>>>        case p2m_populate_on_demand:
>>>> +    case p2m_ram_paging_out:
>>>> +    case p2m_ram_paged:
>>>> +    case p2m_ram_paging_in:
>>>>        default:
>>>>            return flags;
>>>>        case p2m_ram_ro:
>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>                                          shift, max)) )
>>>>            return 0;
>>>>
>>>> -    /* PoD: Not present doesn't imply empty. */
>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>        if ( !l1e_get_flags(*p2m_entry) )
>>>>        {
>>>>            struct page_info *pg;
>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>                                       0, L1_PAGETABLE_ENTRIES);
>>>>            ASSERT(p2m_entry);
>>>>
>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>                                             p2m_type_to_flags(p2mt,
>>>> mfn));
>>>>            else
>>>>                entry_content = l1e_empty();
>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>            if ( entry_content.l1 != 0 )
>>>>            {
>>>>                p2m_add_iommu_flags(&entry_content, 0,
>>>> iommu_pte_flags);
>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>            }
>>>>            /* level 1 entry */
>>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>> entry_content, 1);
>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>                               sizeof(l1e));
>>>>
>>>>        if ( ret == 0 ) {
>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt)) );
>>>>
>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>> -             == p2m_populate_on_demand )
>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>            {
>>>>                /* The read has succeeded, so we know that the mapping
>>>>                 * exits at this point.  */
>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>            }
>>>>
>>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>> +            mfn = _mfn(l1e_mfn);
>>>>            else
>>>>                /* XXX see above */
>>>>                p2mt = p2m_mmio_dm;
>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>    pod_retry_l1:
>>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
>>>>        {
>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>            /* PoD: Try to populate */
>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>> p2m_populate_on_demand )
>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>            {
>>>>                if ( q != p2m_query ) {
>>>>                    if ( !p2m_pod_demand_populate(p2m, gfn,
>>>> PAGE_ORDER_4K,
>>>> q) )
>>>>                        goto pod_retry_l1;
>>>>                } else
>>>>                    *t = p2m_populate_on_demand;
>>>> +        } else {
>>>> +            if ( p2m_is_paging(l1t) )
>>>> +            {
>>>> +                *t = l1t;
>>>> +                /* No need to unclip due to check below */
>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>> +            }
>>>>            }
>>>>
>>>>            unmap_domain_page(l1e);
>>>> -        return _mfn(INVALID_MFN);
>>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>>        }
>>>>        mfn = _mfn(l1e_get_pfn(*l1e));
>>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>                        flags = l1e_get_flags(l1e[i1]);
>>>>                        if ( p2m_flags_to_type(flags) != ot )
>>>>                            continue;
>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>                        gfn = i1 + (i2 + (i3
>>>>    #if CONFIG_PAGING_LEVELS>= 4
>>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>                               * L2_PAGETABLE_ENTRIES) *
>>>> L1_PAGETABLE_ENTRIES;
>>>>                        /* create a new 1le entry with the new type */
>>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>> flags);
>>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>                                             l1mfn, l1e_content, 1);
>>>>                    }
>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>                                    entry_count++;
>>>>                                continue;
>>>>                            }
>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>                            ASSERT(mfn_valid(_mfn(mfn)));
>>>>                            m2pfn = get_gpfn_from_mfn(mfn);
>>>>                            if ( m2pfn != gfn&&
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16: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.xensource.com>)
	id 1RxhNa-0003gi-7p; Wed, 15 Feb 2012 16:06:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxhNY-0003gZ-QF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:06:49 +0000
Received: from [193.109.254.147:16075] by server-2.bemta-14.messagelabs.com id
	6E/3E-11301-818DB3F4; Wed, 15 Feb 2012 16:06:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329321954!52886389!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxMzY3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4556 invoked from network); 15 Feb 2012 16:05:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-5.tower-27.messagelabs.com with SMTP;
	15 Feb 2012 16:05:55 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1561A76C06E;
	Wed, 15 Feb 2012 08:06:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tf/LQN35zWqGUm1B/cpvUxZ/wT3eiUnUzaEfB/Gof1cg
	odzkhJXQjefpxqQCJmuG5BdmGxXZdbbgt4eulhNd3BG2NQQHmXWEAj6kOQFzx3ce
	isVNC9yWWw7+gu+zRisMVHtHwd4QtmXYlznEweIhMUP5Jb3gBMFYLU+brHo9ugM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Dno23Agm1nKIFsGBFMLgjibvHsw=; b=CItkIR17
	QxtLtm9nXTL9Od+2rJt4KnKHM37/QbFlKsfslabkgJ8z14RXMqd3ze0qbw8tO1BP
	7q1LVJ3vRckP2GnjjNd9uhp2TMh5cEEcUvz4ALR3c+MJFObMO6MCONyWfUa1QWKz
	sbwylW6cQdVX4HuhLYa657B4/WzF3RyQi5E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 30EC676C065; 
	Wed, 15 Feb 2012 08:06:45 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 08:06:45 -0800
Message-ID: <eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3BD053.5070404@amd.com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
Date: Wed, 15 Feb 2012 08:06:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Wei Wang" <wei.wang2@amd.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>>> We started hashing out some AMD support for mem_paging and mem_access.
>>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>>> fault.
>>>>
>>>> Most importantly, I want to get somebody from AMD to comment/help out
>>>> on
>>>> this. It feels like we're inches away from enabling support for this
>>>> very
>>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>>> these
>>>> kinds of things. It'd be great to have you on board!
>>>>
>>>> For starters, the changes to the p2m code are relatively mild, but
>>>> it'd
>>>> be
>>>> great if somebody spots a red flag.
>>>>
>>>> Another issue: comments indicate that bits 59-62 in NPT entries are
>>>> used
>>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>>> (59)
>>>> would give us enough space to support mem_access. Right now we only
>>>> have
>>>> 7
>>>> bits available for Xen flags and that is not enough for paging and
>>>> access.
>>>> Is bit 59 effectively reserved?
>>>
>>> Hi
>>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
>>> are not potentially used by DMA, this bit could be non-zero. I could
>>> tested it on my iommu machines if you had some patches that use U bits.
>>
>> Hi Wei, thanks for pitching in! I assume you're talking about table 14
>> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf
>
> Yes, indeed.
>
>> I don't think this will work. The p2m access value is arbitrary, and
>> independent of the p2m type. So bit 59 is out of reach and we're stuck
>> with 7 bits for Xen use. Thanks for the clarification.
>
> Where will p2m access bit be stored? Please note that bit 52 - bit 58
> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
> and bit 1 - bit 8 are free to use if PR bit = 1.

Wei,

Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
current convention?

I propose limiting p2m type to bits 52-55, and storing p2m access on bits
56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
be zero" requirement/convention.

Right now, without any considerations for paging, we're storing the p2m
type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
course. Given your statement above, and table 14 in the IOMMU manual, how
is this even working? Or is it not working?

Would a violation of these rules cause a VMEXIT_SHUTDOWN?

Thanks a lot for the info!
Andres
>
> Thanks,
> Wei
>
>> An alternative to enabling mem_access on AMD processors will be to limit
>> the access types to 3 bits. This would force disabling support for two
>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>> they
>> make sense without R permissions.
>> Thanks!
>> Andres
>>
>>>
>>> Thanks,
>>> Wei
>>>
>>>>
>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>> Comments
>>>> welcome.
>>>>
>>>> Patch inline below, thanks!
>>>> Andres
>>>>
>>>> Enable AMD support for paging.
>>>>
>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>
>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>                if ( !hap_enabled(d) )
>>>>                    break;
>>>>
>>>> -            /* Currently only EPT is supported */
>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>> -                break;
>>>> -
>>>>                rc = -EXDEV;
>>>>                /* Disallow paging in a PoD guest */
>>>>                if ( p2m->pod.entry_count )
>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>> @@ -53,6 +53,20 @@
>>>>    #define P2M_BASE_FLAGS \
>>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>
>>>> +#ifdef __x86_64__
>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>> 0xff..ff
>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>> p2mt,
>>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) - 1))
>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>>> +                                INVALID_MFN : (mfn))
>>>> +#else
>>>> +#define clipped_mfn(mfn)    (mfn)
>>>> +#define unclip_mfn(mfn)     (mfn)
>>>> +#endif /* __x86_64__ */
>>>> +
>>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>    {
>>>>        unsigned long flags;
>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>        case p2m_invalid:
>>>>        case p2m_mmio_dm:
>>>>        case p2m_populate_on_demand:
>>>> +    case p2m_ram_paging_out:
>>>> +    case p2m_ram_paged:
>>>> +    case p2m_ram_paging_in:
>>>>        default:
>>>>            return flags;
>>>>        case p2m_ram_ro:
>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>                                          shift, max)) )
>>>>            return 0;
>>>>
>>>> -    /* PoD: Not present doesn't imply empty. */
>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>        if ( !l1e_get_flags(*p2m_entry) )
>>>>        {
>>>>            struct page_info *pg;
>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>                                       0, L1_PAGETABLE_ENTRIES);
>>>>            ASSERT(p2m_entry);
>>>>
>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>                                             p2m_type_to_flags(p2mt,
>>>> mfn));
>>>>            else
>>>>                entry_content = l1e_empty();
>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>            if ( entry_content.l1 != 0 )
>>>>            {
>>>>                p2m_add_iommu_flags(&entry_content, 0,
>>>> iommu_pte_flags);
>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>            }
>>>>            /* level 1 entry */
>>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>> entry_content, 1);
>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>                               sizeof(l1e));
>>>>
>>>>        if ( ret == 0 ) {
>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt)) );
>>>>
>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>> -             == p2m_populate_on_demand )
>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>            {
>>>>                /* The read has succeeded, so we know that the mapping
>>>>                 * exits at this point.  */
>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>            }
>>>>
>>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>> +            mfn = _mfn(l1e_mfn);
>>>>            else
>>>>                /* XXX see above */
>>>>                p2mt = p2m_mmio_dm;
>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>    pod_retry_l1:
>>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
>>>>        {
>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>            /* PoD: Try to populate */
>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>> p2m_populate_on_demand )
>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>            {
>>>>                if ( q != p2m_query ) {
>>>>                    if ( !p2m_pod_demand_populate(p2m, gfn,
>>>> PAGE_ORDER_4K,
>>>> q) )
>>>>                        goto pod_retry_l1;
>>>>                } else
>>>>                    *t = p2m_populate_on_demand;
>>>> +        } else {
>>>> +            if ( p2m_is_paging(l1t) )
>>>> +            {
>>>> +                *t = l1t;
>>>> +                /* No need to unclip due to check below */
>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>> +            }
>>>>            }
>>>>
>>>>            unmap_domain_page(l1e);
>>>> -        return _mfn(INVALID_MFN);
>>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>>        }
>>>>        mfn = _mfn(l1e_get_pfn(*l1e));
>>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>                        flags = l1e_get_flags(l1e[i1]);
>>>>                        if ( p2m_flags_to_type(flags) != ot )
>>>>                            continue;
>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>                        gfn = i1 + (i2 + (i3
>>>>    #if CONFIG_PAGING_LEVELS>= 4
>>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>                               * L2_PAGETABLE_ENTRIES) *
>>>> L1_PAGETABLE_ENTRIES;
>>>>                        /* create a new 1le entry with the new type */
>>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>> flags);
>>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>                                             l1mfn, l1e_content, 1);
>>>>                    }
>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>                                    entry_count++;
>>>>                                continue;
>>>>                            }
>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>                            ASSERT(mfn_valid(_mfn(mfn)));
>>>>                            m2pfn = get_gpfn_from_mfn(mfn);
>>>>                            if ( m2pfn != gfn&&
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:10:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhRA-0003tb-2v; Wed, 15 Feb 2012 16:10: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 1RxhR8-0003tO-Cr
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:10:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329322090!52863953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32629 invoked from network); 15 Feb 2012 16:08:10 -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;
	15 Feb 2012 16:08:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10721080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:10:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 16:10:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxhR1-0001ha-S4	for xen-devel@lists.xensource.com;
	Wed, 15 Feb 2012 16:10:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxhR1-0000cR-Ql	for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:10:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.55535.817293.121382@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 16:10:23 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent" config
	variable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

commit 4e1aba5e529e1d01b02d04546496001e0da452cd
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Feb 15 16:09:18 2012 +0000

    oxenstored: Fix spelling of "persistent" config variable
    
    Change "persistant" to "persistent", in the code and the
    example/default config.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/tools/ocaml/xenstored/oxenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
index 9616d32..13ee770 100644
--- a/tools/ocaml/xenstored/oxenstored.conf
+++ b/tools/ocaml/xenstored/oxenstored.conf
@@ -20,7 +20,7 @@ quota-maxwatch = 100
 quota-transaction = 10
 
 # Activate filed base backend
-persistant = false
+persistent = false
 
 # Xenstored logs
 # xenstored-log-file = /var/log/xenstored.log
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
index fdea41a..64cc106 100644
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -86,7 +86,7 @@ let parse_config filename =
 		("quota-maxentity", Config.Set_int Quota.maxent);
 		("quota-maxsize", Config.Set_int Quota.maxsize);
 		("test-eagain", Config.Set_bool Transaction.test_eagain);
-		("persistant", Config.Set_bool Disk.enable);
+		("persistent", Config.Set_bool Disk.enable);
 		("xenstored-log-file", Config.Set_string Logging.xenstored_log_file);
 		("xenstored-log-level", Config.String
 			(fun s -> Logging.xenstored_log_level := Logging.level_of_string s));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:10:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhRA-0003tb-2v; Wed, 15 Feb 2012 16:10: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 1RxhR8-0003tO-Cr
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:10:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329322090!52863953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32629 invoked from network); 15 Feb 2012 16:08:10 -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;
	15 Feb 2012 16:08:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10721080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:10:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 16:10:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxhR1-0001ha-S4	for xen-devel@lists.xensource.com;
	Wed, 15 Feb 2012 16:10:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxhR1-0000cR-Ql	for
	xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:10:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.55535.817293.121382@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 16:10:23 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent" config
	variable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

commit 4e1aba5e529e1d01b02d04546496001e0da452cd
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Feb 15 16:09:18 2012 +0000

    oxenstored: Fix spelling of "persistent" config variable
    
    Change "persistant" to "persistent", in the code and the
    example/default config.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/tools/ocaml/xenstored/oxenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
index 9616d32..13ee770 100644
--- a/tools/ocaml/xenstored/oxenstored.conf
+++ b/tools/ocaml/xenstored/oxenstored.conf
@@ -20,7 +20,7 @@ quota-maxwatch = 100
 quota-transaction = 10
 
 # Activate filed base backend
-persistant = false
+persistent = false
 
 # Xenstored logs
 # xenstored-log-file = /var/log/xenstored.log
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
index fdea41a..64cc106 100644
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -86,7 +86,7 @@ let parse_config filename =
 		("quota-maxentity", Config.Set_int Quota.maxent);
 		("quota-maxsize", Config.Set_int Quota.maxsize);
 		("test-eagain", Config.Set_bool Transaction.test_eagain);
-		("persistant", Config.Set_bool Disk.enable);
+		("persistent", Config.Set_bool Disk.enable);
 		("xenstored-log-file", Config.Set_string Logging.xenstored_log_file);
 		("xenstored-log-level", Config.String
 			(fun s -> Logging.xenstored_log_level := Logging.level_of_string s));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxhd1-0004au-Db; Wed, 15 Feb 2012 16:22:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rxhcz-0004am-5X
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:22:45 +0000
Received: from [85.158.139.83:22381] by server-7.bemta-5.messagelabs.com id
	24/B3-16195-3DBDB3F4; Wed, 15 Feb 2012 16:22:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329322962!15233450!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2590 invoked from network); 15 Feb 2012 16:22:42 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-182.messagelabs.com with SMTP;
	15 Feb 2012 16:22:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 5EE7E7EC069;
	Wed, 15 Feb 2012 08:22:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kCpAkcUewn50FNCDzchsjJHLSTolTM1KBHoxKeH+OEQy
	8jVUjpNzCt3NM1T8wStAGS9oIg+BTTFkkb04625tnEuXspYD7x6I9rftdypS1GLw
	f1ghul1cOKD+P6fwRH296KAG+Lt5fGxu4cNhTxNsz7kdQXMDazNVrXTi1qWFgqo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=lQFlWHBJgEAS7avQAUGJASZLvz4=; b=hJpSomxs
	VOPZ0FZ3xFRp9KSFWaiK8VTB4m0LGYUmtVebzlCWR63QXoKOxi7LP4lSmOWg0Dbp
	OhIF8L+QuKdNcLuNHxe6u5NHSV1jhdA7gS74/UZvQufZvKlRbvaML9xegZ5j414Q
	WKcoFG9gxgvnG9Na3mFTnavrFzui/v0ABv8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id B8F1D7EC063; 
	Wed, 15 Feb 2012 08:22:40 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 08:22:41 -0800
Message-ID: <278a7245084d24bf76fe2f799d04d622.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214200528.GA13265@ocelot.phlegethon.org>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
	<20120214200528.GA13265@ocelot.phlegethon.org>
Date: Wed, 15 Feb 2012 08:22:41 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:47 -0800 on 14 Feb (1329209245), Andres Lagar-Cavilla wrote:
>> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>> >
>> >> Why? Because it's really really hard to guarantee we'll go to sleep
>> in
>> >> an
>> >> atomic context. The main use for wait queues (imho) is in hvm_copy,
>> and
>> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
>> >> all
>> >> ways of bumping the preemption count.
>> >
>> > If the guests pagetable is paged out this code path will trigger, then
>> > one of the hypercalls returns an error and the guest runs into a
>> BUG().
>> > I think it was decrease_reservation, or similar.
>>
>> Unlikely to be something specific about decrease_reservation. If the
>> guest
>> page table is paged out, then copy_from_user for any hypercall, or,
>> "virtual address to gfn" for any emulation will run into this.
>>
>> Now, even an innocent-looking rcu lock anywhere in this code path will
>> crash the host if we go into a wait queue. Hence my concern.
>
> OK, so the current code breaks the guest and you're worried about it
> crashing the host instead.   That seems fair.
>
> Maybe we can arrange that instead of bugging out if the cpu is
> in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
> seems no worse than the current failure modes.

How about judiciously adding the following

get_gfn_sleep(d, gfn, type)
{
  if (d == current_domain && !in_atomic())
  {
    printk("Naughty");
    crash_domain(d);
    return INVALID_MFN;
  }

retry:
  mfn rval = get_gfn(d, gfn, type)
  if (d == current->domain && type == paging && !mfn_valid(mfn))
  {
    put_gfn(d, gfn);
    go to sleep on wait queue;
    goto retry;
  }

  return rval;
}

Then we could toss it in before vmx_load_pdptrs gets to do evil things,
for example.

Andres

>
>> > What other way exist to make paging 100% transparent to the guest?
>>
>> Don't page out page table pages? I know you were not expecting that...
>
> Sadly, it's not possible to reliably detect which pages are pagetables
> (or the shadow pagetable code would be more straightforward!).
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxhd1-0004au-Db; Wed, 15 Feb 2012 16:22:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rxhcz-0004am-5X
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:22:45 +0000
Received: from [85.158.139.83:22381] by server-7.bemta-5.messagelabs.com id
	24/B3-16195-3DBDB3F4; Wed, 15 Feb 2012 16:22:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329322962!15233450!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTUxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2590 invoked from network); 15 Feb 2012 16:22:42 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-182.messagelabs.com with SMTP;
	15 Feb 2012 16:22:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 5EE7E7EC069;
	Wed, 15 Feb 2012 08:22:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=kCpAkcUewn50FNCDzchsjJHLSTolTM1KBHoxKeH+OEQy
	8jVUjpNzCt3NM1T8wStAGS9oIg+BTTFkkb04625tnEuXspYD7x6I9rftdypS1GLw
	f1ghul1cOKD+P6fwRH296KAG+Lt5fGxu4cNhTxNsz7kdQXMDazNVrXTi1qWFgqo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=lQFlWHBJgEAS7avQAUGJASZLvz4=; b=hJpSomxs
	VOPZ0FZ3xFRp9KSFWaiK8VTB4m0LGYUmtVebzlCWR63QXoKOxi7LP4lSmOWg0Dbp
	OhIF8L+QuKdNcLuNHxe6u5NHSV1jhdA7gS74/UZvQufZvKlRbvaML9xegZ5j414Q
	WKcoFG9gxgvnG9Na3mFTnavrFzui/v0ABv8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id B8F1D7EC063; 
	Wed, 15 Feb 2012 08:22:40 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 08:22:41 -0800
Message-ID: <278a7245084d24bf76fe2f799d04d622.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120214200528.GA13265@ocelot.phlegethon.org>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
	<20120214200528.GA13265@ocelot.phlegethon.org>
Date: Wed, 15 Feb 2012 08:22:41 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:47 -0800 on 14 Feb (1329209245), Andres Lagar-Cavilla wrote:
>> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
>> >
>> >> Why? Because it's really really hard to guarantee we'll go to sleep
>> in
>> >> an
>> >> atomic context. The main use for wait queues (imho) is in hvm_copy,
>> and
>> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
>> >> all
>> >> ways of bumping the preemption count.
>> >
>> > If the guests pagetable is paged out this code path will trigger, then
>> > one of the hypercalls returns an error and the guest runs into a
>> BUG().
>> > I think it was decrease_reservation, or similar.
>>
>> Unlikely to be something specific about decrease_reservation. If the
>> guest
>> page table is paged out, then copy_from_user for any hypercall, or,
>> "virtual address to gfn" for any emulation will run into this.
>>
>> Now, even an innocent-looking rcu lock anywhere in this code path will
>> crash the host if we go into a wait queue. Hence my concern.
>
> OK, so the current code breaks the guest and you're worried about it
> crashing the host instead.   That seems fair.
>
> Maybe we can arrange that instead of bugging out if the cpu is
> in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
> seems no worse than the current failure modes.

How about judiciously adding the following

get_gfn_sleep(d, gfn, type)
{
  if (d == current_domain && !in_atomic())
  {
    printk("Naughty");
    crash_domain(d);
    return INVALID_MFN;
  }

retry:
  mfn rval = get_gfn(d, gfn, type)
  if (d == current->domain && type == paging && !mfn_valid(mfn))
  {
    put_gfn(d, gfn);
    go to sleep on wait queue;
    goto retry;
  }

  return rval;
}

Then we could toss it in before vmx_load_pdptrs gets to do evil things,
for example.

Andres

>
>> > What other way exist to make paging 100% transparent to the guest?
>>
>> Don't page out page table pages? I know you were not expecting that...
>
> Sadly, it's not possible to reliably detect which pages are pagetables
> (or the shadow pagetable code would be more straightforward!).
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:25:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhfZ-0004gQ-W1; Wed, 15 Feb 2012 16:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxhfZ-0004gK-9u
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:25:25 +0000
Received: from [85.158.139.83:37069] by server-11.bemta-5.messagelabs.com id
	FE/A6-14397-47CDB3F4; Wed, 15 Feb 2012 16:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329323123!15216652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25725 invoked from network); 15 Feb 2012 16:25: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;
	15 Feb 2012 16:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10721478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:25:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 16:25:23 +0000
Message-ID: <1329323121.31256.324.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 16:25:21 +0000
In-Reply-To: <20283.55535.817293.121382@mariner.uk.xensource.com>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent"
 config variable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 16:10 +0000, Ian Jackson wrote:
> commit 4e1aba5e529e1d01b02d04546496001e0da452cd
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Wed Feb 15 16:09:18 2012 +0000
> 
>     oxenstored: Fix spelling of "persistent" config variable
>     
>     Change "persistant" to "persistent", in the code and the
>     example/default config.
>     
>     Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/tools/ocaml/xenstored/oxenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
> index 9616d32..13ee770 100644
> --- a/tools/ocaml/xenstored/oxenstored.conf
> +++ b/tools/ocaml/xenstored/oxenstored.conf
> @@ -20,7 +20,7 @@ quota-maxwatch = 100
>  quota-transaction = 10
>  
>  # Activate filed base backend
> -persistant = false
> +persistent = false
>  
>  # Xenstored logs
>  # xenstored-log-file = /var/log/xenstored.log
> diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
> index fdea41a..64cc106 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -86,7 +86,7 @@ let parse_config filename =
>  		("quota-maxentity", Config.Set_int Quota.maxent);
>  		("quota-maxsize", Config.Set_int Quota.maxsize);
>  		("test-eagain", Config.Set_bool Transaction.test_eagain);
> -		("persistant", Config.Set_bool Disk.enable);
> +		("persistent", Config.Set_bool Disk.enable);
>  		("xenstored-log-file", Config.Set_string Logging.xenstored_log_file);
>  		("xenstored-log-level", Config.String
>  			(fun s -> Logging.xenstored_log_level := Logging.level_of_string s));
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:25:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhfZ-0004gQ-W1; Wed, 15 Feb 2012 16:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RxhfZ-0004gK-9u
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:25:25 +0000
Received: from [85.158.139.83:37069] by server-11.bemta-5.messagelabs.com id
	FE/A6-14397-47CDB3F4; Wed, 15 Feb 2012 16:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329323123!15216652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25725 invoked from network); 15 Feb 2012 16:25: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;
	15 Feb 2012 16:25:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10721478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:25:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 16:25:23 +0000
Message-ID: <1329323121.31256.324.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 16:25:21 +0000
In-Reply-To: <20283.55535.817293.121382@mariner.uk.xensource.com>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent"
 config variable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 16:10 +0000, Ian Jackson wrote:
> commit 4e1aba5e529e1d01b02d04546496001e0da452cd
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Wed Feb 15 16:09:18 2012 +0000
> 
>     oxenstored: Fix spelling of "persistent" config variable
>     
>     Change "persistant" to "persistent", in the code and the
>     example/default config.
>     
>     Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/tools/ocaml/xenstored/oxenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
> index 9616d32..13ee770 100644
> --- a/tools/ocaml/xenstored/oxenstored.conf
> +++ b/tools/ocaml/xenstored/oxenstored.conf
> @@ -20,7 +20,7 @@ quota-maxwatch = 100
>  quota-transaction = 10
>  
>  # Activate filed base backend
> -persistant = false
> +persistent = false
>  
>  # Xenstored logs
>  # xenstored-log-file = /var/log/xenstored.log
> diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
> index fdea41a..64cc106 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -86,7 +86,7 @@ let parse_config filename =
>  		("quota-maxentity", Config.Set_int Quota.maxent);
>  		("quota-maxsize", Config.Set_int Quota.maxsize);
>  		("test-eagain", Config.Set_bool Transaction.test_eagain);
> -		("persistant", Config.Set_bool Disk.enable);
> +		("persistent", Config.Set_bool Disk.enable);
>  		("xenstored-log-file", Config.Set_string Logging.xenstored_log_file);
>  		("xenstored-log-level", Config.String
>  			(fun s -> Logging.xenstored_log_level := Logging.level_of_string s));
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxhk4-0004sT-ME; Wed, 15 Feb 2012 16:30:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1Rxhk3-0004sL-0T
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:30:03 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329323395!2910237!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18501 invoked from network); 15 Feb 2012 16:29:56 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:29:56 -0000
Received: by yenm7 with SMTP id m7so13288063yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 08:29:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=0mdRoSdv6ZTJO64xavd4XMu2JMD0ZZmFEFlAQXyWypA=;
	b=uUfIlz+LDu9KaJYGc39Yy7qrCvRZMCASSlF64WyqKoN0gF1FrABEyzPrN+3aEnP35Z
	FP1OMgGGbwiyGO6R9nDt2yiqnFosMHLUdBNF845b8MEISGXhPnrVWeXlMc/FRSIKQMhH
	Y0AYbGV+1ISArIyBNsN2Vc1PqKzJKdMfgFy1s=
MIME-Version: 1.0
Received: by 10.50.208.69 with SMTP id mc5mr3638113igc.28.1329323394588; Wed,
	15 Feb 2012 08:29:54 -0800 (PST)
Received: by 10.231.132.71 with HTTP; Wed, 15 Feb 2012 08:29:54 -0800 (PST)
In-Reply-To: <20120209211316.GD14007@andromeda.dapyr.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
Date: Wed, 15 Feb 2012 19:29:54 +0300
Message-ID: <CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/10 Konrad Rzeszutek Wilk <konrad@darnok.org>:

AS>> Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)
KRW> Do you get the same issue with a pv-ops dom0? So also 3.1, but
from kernel.org?

Unfortunately, I'm not skilled at compiling the kernel myself. I tried
building the newest 3.2.6
with all Xen options (which I could find by "Xen" keyword) enabled,
but the resulting system
didn't have netback.ko module at all, barely booted, and xm was not
able to communicate
with the hypervisor.

As to vanilla kernel package provided by openSUSE, it is not Xen-enabled.

Meanwhile, an update was released, so I was testing 3.1.9-1.4-xen for
about a week,
though the outcome is still negative.


AS>> Supposedly "offending" DomU is paravirtualized NetBSD 5.1.1
AS>> for AMD64 with recompiled kernel (CARP enabled, no more changes).
KRW> What is CARP?

CARP is Common Address Redundancy Protocol, a "non-patented version of VRRP",
used for high availability and load balancing. It is supported in
NetBSD kernel (although
user-space implementation, uCARP, exist as well), but is not compiled
by default.
All my work to enable it was a quiet simple recompilation with following config:

include         "arch/amd64/conf/XEN3_DOMU"
pseudo-device   carp

It looks like GPFs happen only when those load-balancing DomUs are running;
at least, then they are shutoff, no fault is observed in a whole day,
but then they run,
fault can happen even after some minutes of Dom0 uptime, especially while
DomUs are stopping or starting.


KRW> Hm, that is a pretty neat stack output. Wonder which patch of
theirs does that.

It was not verbatim dump, but a generalized text. If you are
interested, here is an excerpt
from /var/log/messages for penultimate GPF (with date and hostname removed):


===[ Preceeding entries ]===

(Those can be absolutely unrelated to GPF, but all 3 recent faults
after kernel update
were happening during VMs shutdown, either massive or singular.)

21:18:33 avahi-daemon[3086]: Withdrawing workstation service for vif10.0.
21:18:33 kernel: [29722.267359] br1: port 10(vif10.0) entering forwarding state
21:18:33 kernel: [29722.267443] br1: port 10(vif10.0) entering disabled state
21:18:33 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/10/0
21:18:33 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif10.0 failed
21:18:33 logger: /etc/xen/scripts/vif-bridge: ifconfig vif10.0 down failed
21:18:33 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif10.0, bridge br1.
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/10/0
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/10/0
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/10/0
21:18:33 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/10/51712
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/10/0
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/10/51712
21:18:53 avahi-daemon[3086]: Withdrawing workstation service for vif9.0.
21:18:53 kernel: [29742.222676] br1: port 9(vif9.0) entering forwarding state
21:18:53 kernel: [29742.222779] br1: port 9(vif9.0) entering disabled state
21:18:53 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/9/0
21:18:53 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif9.0 failed
21:18:53 logger: /etc/xen/scripts/vif-bridge: ifconfig vif9.0 down failed
21:18:53 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif9.0, bridge br1.
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/9/0
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/9/0
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/9/0
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/9/0
21:18:53 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/9/51712
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/9/51712
21:19:13 avahi-daemon[3086]: Withdrawing workstation service for vif8.0.
21:19:13 kernel: [29762.605500] br1: port 8(vif8.0) entering forwarding state
21:19:13 kernel: [29762.605572] br1: port 8(vif8.0) entering disabled state
21:19:13 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/8/0
21:19:13 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif8.0 failed
21:19:13 logger: /etc/xen/scripts/vif-bridge: ifconfig vif8.0 down failed
21:19:13 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif8.0, bridge br1.
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/8/0
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/8/0
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/8/0
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/8/0
21:19:13 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/8/51712
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/8/51712
21:19:26 avahi-daemon[3086]: Withdrawing workstation service for vif7.0.
21:19:26 kernel: [29775.558990] br1: port 7(vif7.0) entering forwarding state
21:19:26 kernel: [29775.559105] br1: port 7(vif7.0) entering disabled state
21:19:26 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/7/0
21:19:26 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif7.0 failed
21:19:26 logger: /etc/xen/scripts/vif-bridge: ifconfig vif7.0 down failed
21:19:26 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif7.0, bridge br1.
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/7/0
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/7/0
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/7/0
21:19:26 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/7/51712
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/7/0
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/7/51712

===[ Fault alert itself ]===

21:19:37 kernel: [29786.610984] general protection fault: 0000 [#1] SMP
21:19:37 kernel: [29786.610992] CPU 0
21:19:37 kernel: [29786.610993] Modules linked in: fuse ip6t_LOG
xt_tcpudp xt_pkttype xt_physdev ipt_LOG xt_limit nfsd lockd nfs_acl
auth_rpcgss sunrpc usbbk netbk blkbk blkback_pagemap blktap domctl
xenbus_be gntdev evtchn af_packet bridge stp llc edd ip6t_REJECT
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT
iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables
microcode snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device eeepc_wmi
asus_wmi sparse_keymap rfkill usb_storage ppdev pci_hotplug uas
8250_pnp sg i2c_i801 sr_mod wmi parport_pc snd_hda_codec_hdmi
snd_hda_codec_realtek parport r8169 pcspkr mei(C) 8250 serial_core
iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm snd_timer snd soundcore snd_page_alloc usbhid hid dm_mod
linear btrfs zlib_deflate lzo_compress i915 drm_kms_helper drm
i2c_algo_bit ehci_hcd usbcor
21:19:37 kernel: e i2c_core button video processor thermal_sys hwmon
xenblk cdrom xennet ata_generic pata_via
21:19:37 kernel: [29786.611076]
21:19:37 kernel: [29786.611078] Pid: 3461, comm: netback/1 Tainted: G
       C  3.1.9-1.4-xen #1 System manufacturer System Product
Name/P8H67-M
21:19:37 kernel: [29786.611084] RIP: e030:[<ffffffff803e7f81>]
[<ffffffff803e7f81>] skb_release_data.part.46+0x61/0xc0
21:19:37 kernel: [29786.611092] RSP: e02b:ffff8802c8339d40  EFLAGS: 00010202
21:19:37 kernel: [29786.611095] RAX: 0000000000000000 RBX:
ffff88007ccf39c0 RCX: ffff8800e70db000
21:19:37 kernel: [29786.611098] RDX: ffff8800e70dbe80 RSI:
000000000000001f RDI: 0028f49c00000000
21:19:37 kernel: [29786.611101] RBP: ffff88007ccf39c0 R08:
ffff8800e70d0010 R09: 000000000000004e
21:19:37 kernel: [29786.611103] R10: 0000000000000003 R11:
ffff8802d0074c30 R12: ffff8802bb22f000
21:19:37 kernel: [29786.611106] R13: ffff88027ea382c0 R14:
ffffc900048cb960 R15: 0000000000000001
21:19:37 kernel: [29786.611114] FS:  00007f303913f700(0000)
GS:ffff8802de3c2000(0000) knlGS:0000000000000000
21:19:37 kernel: [29786.611117] CS:  e033 DS: 0000 ES: 0000 CR0:
000000008005003b
21:19:37 kernel: [29786.611119] CR2: 00000000006b6e30 CR3:
00000002c93fb000 CR4: 0000000000042660
21:19:37 kernel: [29786.611126] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
21:19:37 kernel: [29786.611131] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
21:19:37 kernel: [29786.611136] Process netback/1 (pid: 3461,
threadinfo ffff8802c8338000, task ffff8802d00747c0)
21:19:37 kernel: [29786.611140] Stack:
21:19:37 kernel: [29786.611144]  0000000000000000 ffff88007ccf39c0
0000000000000000 ffffffff803e8041
21:19:37 kernel: [29786.611151]  ffff88007ccf39c0 ffffffffa059fd3c
ffff8802d00747c0 ffff8802c8339e00
21:19:37 kernel: [29786.611157]  ffff8802c8339db0 ffffc900048a8f20
ffffc90000000002 0000000000000000
21:19:37 kernel: [29786.611164] Call Trace:
21:19:37 kernel: [29786.611173]  [<ffffffff803e8041>] __kfree_skb+0x11/0x20
21:19:37 kernel: [29786.611182]  [<ffffffffa059fd3c>]
net_rx_action+0x66c/0x9c0 [netbk]
21:19:37 kernel: [29786.611201]  [<ffffffffa05a173a>]
netbk_action_thread+0x5a/0x270 [netbk]
21:19:37 kernel: [29786.611211]  [<ffffffff8006444e>] kthread+0x7e/0x90
21:19:37 kernel: [29786.611220]  [<ffffffff80510d24>]
kernel_thread_helper+0x4/0x10
21:19:37 kernel: [29786.611225] Code: 48 8b 7c 02 08 e8 a0 60 cf ff 8b
95 d0 00 00 00 48 8b 8d d8 00 00 00 48 01 ca 0f b7 02 39 c3 7c d1 f6
42 0c 10 74 1e 48 8b 7a 30
21:19:37 kernel: [29786.611265] RIP  [<ffffffff803e7f81>]
skb_release_data.part.46+0x61/0xc0
21:19:37 kernel: [29786.611271]  RSP <ffff8802c8339d40>
21:19:37 kernel: [29786.671491] ---[ end trace 6875b40b2a9f1d46 ]---

(Note that numbers after "+" in call trace did not changed after kernel update,
as compared to previously posted, although absolute addresses did changed.)


===[ Subsequent entries ]===

(Again, sometimes those can be absolutely unrelated to GPF, and happen
minutes after.)

21:19:38 avahi-daemon[3086]: Withdrawing workstation service for vif6.0.
21:19:38 kernel: [29787.904571] br1: port 6(vif6.0) entering forwarding state
21:19:38 kernel: [29787.904649] br1: port 6(vif6.0) entering disabled state
21:19:38 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/6/0
21:19:38 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif6.0 failed
21:19:38 logger: /etc/xen/scripts/vif-bridge: ifconfig vif6.0 down failed
21:19:38 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif6.0, bridge br1.
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/6/0
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/6/0
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/6/0
21:19:39 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/6/51712
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/6/0
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/6/51712
21:19:58 kernel: [29807.860561] br1: port 5(vif5.0) entering forwarding state

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxhk4-0004sT-ME; Wed, 15 Feb 2012 16:30:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1Rxhk3-0004sL-0T
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:30:03 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329323395!2910237!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18501 invoked from network); 15 Feb 2012 16:29:56 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:29:56 -0000
Received: by yenm7 with SMTP id m7so13288063yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 08:29:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=0mdRoSdv6ZTJO64xavd4XMu2JMD0ZZmFEFlAQXyWypA=;
	b=uUfIlz+LDu9KaJYGc39Yy7qrCvRZMCASSlF64WyqKoN0gF1FrABEyzPrN+3aEnP35Z
	FP1OMgGGbwiyGO6R9nDt2yiqnFosMHLUdBNF845b8MEISGXhPnrVWeXlMc/FRSIKQMhH
	Y0AYbGV+1ISArIyBNsN2Vc1PqKzJKdMfgFy1s=
MIME-Version: 1.0
Received: by 10.50.208.69 with SMTP id mc5mr3638113igc.28.1329323394588; Wed,
	15 Feb 2012 08:29:54 -0800 (PST)
Received: by 10.231.132.71 with HTTP; Wed, 15 Feb 2012 08:29:54 -0800 (PST)
In-Reply-To: <20120209211316.GD14007@andromeda.dapyr.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
Date: Wed, 15 Feb 2012 19:29:54 +0300
Message-ID: <CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/2/10 Konrad Rzeszutek Wilk <konrad@darnok.org>:

AS>> Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)
KRW> Do you get the same issue with a pv-ops dom0? So also 3.1, but
from kernel.org?

Unfortunately, I'm not skilled at compiling the kernel myself. I tried
building the newest 3.2.6
with all Xen options (which I could find by "Xen" keyword) enabled,
but the resulting system
didn't have netback.ko module at all, barely booted, and xm was not
able to communicate
with the hypervisor.

As to vanilla kernel package provided by openSUSE, it is not Xen-enabled.

Meanwhile, an update was released, so I was testing 3.1.9-1.4-xen for
about a week,
though the outcome is still negative.


AS>> Supposedly "offending" DomU is paravirtualized NetBSD 5.1.1
AS>> for AMD64 with recompiled kernel (CARP enabled, no more changes).
KRW> What is CARP?

CARP is Common Address Redundancy Protocol, a "non-patented version of VRRP",
used for high availability and load balancing. It is supported in
NetBSD kernel (although
user-space implementation, uCARP, exist as well), but is not compiled
by default.
All my work to enable it was a quiet simple recompilation with following config:

include         "arch/amd64/conf/XEN3_DOMU"
pseudo-device   carp

It looks like GPFs happen only when those load-balancing DomUs are running;
at least, then they are shutoff, no fault is observed in a whole day,
but then they run,
fault can happen even after some minutes of Dom0 uptime, especially while
DomUs are stopping or starting.


KRW> Hm, that is a pretty neat stack output. Wonder which patch of
theirs does that.

It was not verbatim dump, but a generalized text. If you are
interested, here is an excerpt
from /var/log/messages for penultimate GPF (with date and hostname removed):


===[ Preceeding entries ]===

(Those can be absolutely unrelated to GPF, but all 3 recent faults
after kernel update
were happening during VMs shutdown, either massive or singular.)

21:18:33 avahi-daemon[3086]: Withdrawing workstation service for vif10.0.
21:18:33 kernel: [29722.267359] br1: port 10(vif10.0) entering forwarding state
21:18:33 kernel: [29722.267443] br1: port 10(vif10.0) entering disabled state
21:18:33 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/10/0
21:18:33 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif10.0 failed
21:18:33 logger: /etc/xen/scripts/vif-bridge: ifconfig vif10.0 down failed
21:18:33 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif10.0, bridge br1.
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/10/0
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/10/0
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/10/0
21:18:33 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/10/51712
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/10/0
21:18:33 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/10/51712
21:18:53 avahi-daemon[3086]: Withdrawing workstation service for vif9.0.
21:18:53 kernel: [29742.222676] br1: port 9(vif9.0) entering forwarding state
21:18:53 kernel: [29742.222779] br1: port 9(vif9.0) entering disabled state
21:18:53 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/9/0
21:18:53 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif9.0 failed
21:18:53 logger: /etc/xen/scripts/vif-bridge: ifconfig vif9.0 down failed
21:18:53 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif9.0, bridge br1.
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/9/0
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/9/0
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/9/0
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/9/0
21:18:53 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/9/51712
21:18:53 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/9/51712
21:19:13 avahi-daemon[3086]: Withdrawing workstation service for vif8.0.
21:19:13 kernel: [29762.605500] br1: port 8(vif8.0) entering forwarding state
21:19:13 kernel: [29762.605572] br1: port 8(vif8.0) entering disabled state
21:19:13 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/8/0
21:19:13 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif8.0 failed
21:19:13 logger: /etc/xen/scripts/vif-bridge: ifconfig vif8.0 down failed
21:19:13 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif8.0, bridge br1.
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/8/0
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/8/0
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/8/0
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/8/0
21:19:13 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/8/51712
21:19:13 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/8/51712
21:19:26 avahi-daemon[3086]: Withdrawing workstation service for vif7.0.
21:19:26 kernel: [29775.558990] br1: port 7(vif7.0) entering forwarding state
21:19:26 kernel: [29775.559105] br1: port 7(vif7.0) entering disabled state
21:19:26 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/7/0
21:19:26 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif7.0 failed
21:19:26 logger: /etc/xen/scripts/vif-bridge: ifconfig vif7.0 down failed
21:19:26 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif7.0, bridge br1.
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/7/0
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/7/0
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/7/0
21:19:26 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/7/51712
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/7/0
21:19:26 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/7/51712

===[ Fault alert itself ]===

21:19:37 kernel: [29786.610984] general protection fault: 0000 [#1] SMP
21:19:37 kernel: [29786.610992] CPU 0
21:19:37 kernel: [29786.610993] Modules linked in: fuse ip6t_LOG
xt_tcpudp xt_pkttype xt_physdev ipt_LOG xt_limit nfsd lockd nfs_acl
auth_rpcgss sunrpc usbbk netbk blkbk blkback_pagemap blktap domctl
xenbus_be gntdev evtchn af_packet bridge stp llc edd ip6t_REJECT
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT
iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables
microcode snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device eeepc_wmi
asus_wmi sparse_keymap rfkill usb_storage ppdev pci_hotplug uas
8250_pnp sg i2c_i801 sr_mod wmi parport_pc snd_hda_codec_hdmi
snd_hda_codec_realtek parport r8169 pcspkr mei(C) 8250 serial_core
iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm snd_timer snd soundcore snd_page_alloc usbhid hid dm_mod
linear btrfs zlib_deflate lzo_compress i915 drm_kms_helper drm
i2c_algo_bit ehci_hcd usbcor
21:19:37 kernel: e i2c_core button video processor thermal_sys hwmon
xenblk cdrom xennet ata_generic pata_via
21:19:37 kernel: [29786.611076]
21:19:37 kernel: [29786.611078] Pid: 3461, comm: netback/1 Tainted: G
       C  3.1.9-1.4-xen #1 System manufacturer System Product
Name/P8H67-M
21:19:37 kernel: [29786.611084] RIP: e030:[<ffffffff803e7f81>]
[<ffffffff803e7f81>] skb_release_data.part.46+0x61/0xc0
21:19:37 kernel: [29786.611092] RSP: e02b:ffff8802c8339d40  EFLAGS: 00010202
21:19:37 kernel: [29786.611095] RAX: 0000000000000000 RBX:
ffff88007ccf39c0 RCX: ffff8800e70db000
21:19:37 kernel: [29786.611098] RDX: ffff8800e70dbe80 RSI:
000000000000001f RDI: 0028f49c00000000
21:19:37 kernel: [29786.611101] RBP: ffff88007ccf39c0 R08:
ffff8800e70d0010 R09: 000000000000004e
21:19:37 kernel: [29786.611103] R10: 0000000000000003 R11:
ffff8802d0074c30 R12: ffff8802bb22f000
21:19:37 kernel: [29786.611106] R13: ffff88027ea382c0 R14:
ffffc900048cb960 R15: 0000000000000001
21:19:37 kernel: [29786.611114] FS:  00007f303913f700(0000)
GS:ffff8802de3c2000(0000) knlGS:0000000000000000
21:19:37 kernel: [29786.611117] CS:  e033 DS: 0000 ES: 0000 CR0:
000000008005003b
21:19:37 kernel: [29786.611119] CR2: 00000000006b6e30 CR3:
00000002c93fb000 CR4: 0000000000042660
21:19:37 kernel: [29786.611126] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
21:19:37 kernel: [29786.611131] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
21:19:37 kernel: [29786.611136] Process netback/1 (pid: 3461,
threadinfo ffff8802c8338000, task ffff8802d00747c0)
21:19:37 kernel: [29786.611140] Stack:
21:19:37 kernel: [29786.611144]  0000000000000000 ffff88007ccf39c0
0000000000000000 ffffffff803e8041
21:19:37 kernel: [29786.611151]  ffff88007ccf39c0 ffffffffa059fd3c
ffff8802d00747c0 ffff8802c8339e00
21:19:37 kernel: [29786.611157]  ffff8802c8339db0 ffffc900048a8f20
ffffc90000000002 0000000000000000
21:19:37 kernel: [29786.611164] Call Trace:
21:19:37 kernel: [29786.611173]  [<ffffffff803e8041>] __kfree_skb+0x11/0x20
21:19:37 kernel: [29786.611182]  [<ffffffffa059fd3c>]
net_rx_action+0x66c/0x9c0 [netbk]
21:19:37 kernel: [29786.611201]  [<ffffffffa05a173a>]
netbk_action_thread+0x5a/0x270 [netbk]
21:19:37 kernel: [29786.611211]  [<ffffffff8006444e>] kthread+0x7e/0x90
21:19:37 kernel: [29786.611220]  [<ffffffff80510d24>]
kernel_thread_helper+0x4/0x10
21:19:37 kernel: [29786.611225] Code: 48 8b 7c 02 08 e8 a0 60 cf ff 8b
95 d0 00 00 00 48 8b 8d d8 00 00 00 48 01 ca 0f b7 02 39 c3 7c d1 f6
42 0c 10 74 1e 48 8b 7a 30
21:19:37 kernel: [29786.611265] RIP  [<ffffffff803e7f81>]
skb_release_data.part.46+0x61/0xc0
21:19:37 kernel: [29786.611271]  RSP <ffff8802c8339d40>
21:19:37 kernel: [29786.671491] ---[ end trace 6875b40b2a9f1d46 ]---

(Note that numbers after "+" in call trace did not changed after kernel update,
as compared to previously posted, although absolute addresses did changed.)


===[ Subsequent entries ]===

(Again, sometimes those can be absolutely unrelated to GPF, and happen
minutes after.)

21:19:38 avahi-daemon[3086]: Withdrawing workstation service for vif6.0.
21:19:38 kernel: [29787.904571] br1: port 6(vif6.0) entering forwarding state
21:19:38 kernel: [29787.904649] br1: port 6(vif6.0) entering disabled state
21:19:38 logger: /etc/xen/scripts/vif-bridge: offline type_if=vif
XENBUS_PATH=backend/vif/6/0
21:19:38 logger: /etc/xen/scripts/vif-bridge: brctl delif br1 vif6.0 failed
21:19:38 logger: /etc/xen/scripts/vif-bridge: ifconfig vif6.0 down failed
21:19:38 logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge
offline for vif6.0, bridge br1.
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vkbd/6/0
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/console/6/0
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vfb/6/0
21:19:39 logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/6/51712
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vif/6/0
21:19:39 logger: /etc/xen/scripts/xen-hotplug-cleanup:
XENBUS_PATH=backend/vbd/6/51712
21:19:58 kernel: [29807.860561] br1: port 5(vif5.0) entering forwarding state

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:37:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxhqp-00055Q-IM; Wed, 15 Feb 2012 16:37:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rxhqn-00055K-RF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:37:02 +0000
Received: from [85.158.139.83:53211] by server-1.bemta-5.messagelabs.com id
	A0/99-28458-C2FDB3F4; Wed, 15 Feb 2012 16:37:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329323818!12506900!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxNTg4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23938 invoked from network); 15 Feb 2012 16:37:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 16:37: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 q1FGakZw023661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 16:36:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1FGaj9p012873
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 16:36:45 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
	q1FGaiG3002267; Wed, 15 Feb 2012 10:36:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 08:36:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0CCD04047D; Wed, 15 Feb 2012 11:33:41 -0500 (EST)
Date: Wed, 15 Feb 2012 11:33:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120215163340.GD4093@phenom.dumpdata.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
	<20120214183006.GJ12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120214183006.GJ12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090205.4F3BDF20.009A,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: Re: [Xen-devel] [RFC] acpi processor and cpufreq harester - aka
 pipe all of that up to the hypervisor (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, 2012 at 08:30:06PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Tue, Feb 14, 2012 at 12:06:46AM -0500, Konrad Rzeszutek Wilk wrote:
> > =

> > This "harvester" (I am horrible with names, if you have any suggestions=
 please
> > tell me them) collects the information that the cpufreq drivers and the
> > ACPI processor code save in the 'struct acpi_processor' and then sends =
it to
> > the hypervisor.
> > =

> =

> Btw there's a typo in the subject line.. "harester".

Duh!
> =

> I'm not very good with names either: collector? passthru? =


"passthru" sounds better.
> =

> =

> > The driver can be either an module or compiled in. In either mode the d=
river
> > launches a thread that checks whether an cpufreq driver is registered. =
If so
> > it reads all the 'struct acpi_processor' data for all online CPUs and s=
ends
> > it to hypervisor. The driver also register a CPU hotplug component - so=
 if a new
> > CPU shows up - it would send the data to the hypervisor for it as well.
> > =

> > I've tested this with success on a variety of Intel and AMD hardware (n=
eed
> > a patch to the hypervisor to allow the rdmsr to be passed through). The=
 one
> > caveat is that dom0_max_vcpus inhibits the driver from reading the vCPUs
> > that are not present in dom0. One solution is to boot without dom0_max_=
vcpus
> > and utilize the 'xl vcpu-set' command to offline the vCPUs. Other one t=
hat
> > Nakajima Jun suggested was to hotplug vCPUS in - so bootup dom0 and hot=
plug
> > the vCPUs in - but I am running in difficulties on how to do this in th=
e hypervisor.
> > =

> =

> When using this driver do you need to pass any options to Xen hypervisor? =

> (cpufreq=3Dsomething) ? =


No need. You only need that if you want to change the default cpufreq drive=
r from
the ondemand to performance (so cpufreq=3Dperformance) or want more verbose=
 information:
cpufreq=3Dverbose,performance

By default the Xen hypervisor will take the cpufreq data in account unless =
you
override that with 'dom0-is-deciding-power-management-and-I-cant-remember-e=
xactly'
parameter.

> =

> It might be good to mention something about that in the patch comments.

I will include cpufreq=3Dverbose and mention that the effect before and aft=
er. And also
with xenpm.

Thanks!
> =

> -- Pasi
> =

> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:37:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:37:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxhqp-00055Q-IM; Wed, 15 Feb 2012 16:37:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rxhqn-00055K-RF
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:37:02 +0000
Received: from [85.158.139.83:53211] by server-1.bemta-5.messagelabs.com id
	A0/99-28458-C2FDB3F4; Wed, 15 Feb 2012 16:37:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329323818!12506900!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxNTg4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23938 invoked from network); 15 Feb 2012 16:37:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 16:37: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 q1FGakZw023661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 16:36:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1FGaj9p012873
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 16:36:45 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
	q1FGaiG3002267; Wed, 15 Feb 2012 10:36:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 08:36:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0CCD04047D; Wed, 15 Feb 2012 11:33:41 -0500 (EST)
Date: Wed, 15 Feb 2012 11:33:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120215163340.GD4093@phenom.dumpdata.com>
References: <1329196009-25268-1-git-send-email-konrad.wilk@oracle.com>
	<20120214183006.GJ12984@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120214183006.GJ12984@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090205.4F3BDF20.009A,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: Re: [Xen-devel] [RFC] acpi processor and cpufreq harester - aka
 pipe all of that up to the hypervisor (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Feb 14, 2012 at 08:30:06PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Tue, Feb 14, 2012 at 12:06:46AM -0500, Konrad Rzeszutek Wilk wrote:
> > =

> > This "harvester" (I am horrible with names, if you have any suggestions=
 please
> > tell me them) collects the information that the cpufreq drivers and the
> > ACPI processor code save in the 'struct acpi_processor' and then sends =
it to
> > the hypervisor.
> > =

> =

> Btw there's a typo in the subject line.. "harester".

Duh!
> =

> I'm not very good with names either: collector? passthru? =


"passthru" sounds better.
> =

> =

> > The driver can be either an module or compiled in. In either mode the d=
river
> > launches a thread that checks whether an cpufreq driver is registered. =
If so
> > it reads all the 'struct acpi_processor' data for all online CPUs and s=
ends
> > it to hypervisor. The driver also register a CPU hotplug component - so=
 if a new
> > CPU shows up - it would send the data to the hypervisor for it as well.
> > =

> > I've tested this with success on a variety of Intel and AMD hardware (n=
eed
> > a patch to the hypervisor to allow the rdmsr to be passed through). The=
 one
> > caveat is that dom0_max_vcpus inhibits the driver from reading the vCPUs
> > that are not present in dom0. One solution is to boot without dom0_max_=
vcpus
> > and utilize the 'xl vcpu-set' command to offline the vCPUs. Other one t=
hat
> > Nakajima Jun suggested was to hotplug vCPUS in - so bootup dom0 and hot=
plug
> > the vCPUs in - but I am running in difficulties on how to do this in th=
e hypervisor.
> > =

> =

> When using this driver do you need to pass any options to Xen hypervisor? =

> (cpufreq=3Dsomething) ? =


No need. You only need that if you want to change the default cpufreq drive=
r from
the ondemand to performance (so cpufreq=3Dperformance) or want more verbose=
 information:
cpufreq=3Dverbose,performance

By default the Xen hypervisor will take the cpufreq data in account unless =
you
override that with 'dom0-is-deciding-power-management-and-I-cant-remember-e=
xactly'
parameter.

> =

> It might be good to mention something about that in the patch comments.

I will include cpufreq=3Dverbose and mention that the effect before and aft=
er. And also
with xenpm.

Thanks!
> =

> -- Pasi
> =

> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:39:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhsW-0005CC-D1; Wed, 15 Feb 2012 16:38:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RxhsU-0005Bk-TB; Wed, 15 Feb 2012 16:38:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329323920!14401485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30210 invoked from network); 15 Feb 2012 16:38:40 -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;
	15 Feb 2012 16:38:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10721912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:38:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 16:38:40 +0000
Message-ID: <1329323919.31256.329.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ben Pfaff <blp@nicira.com>
Date: Wed, 15 Feb 2012 16:38:39 +0000
In-Reply-To: <87r4xx9ubs.fsf@blp.benpfaff.org>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> Lars Kurth <lars.kurth@xen.org> writes:
> 
> > I have made preparations to reach out to further groups in SIlicon
> > valley, and want to ensure that the core people are signed up before I
> > do this.
> 
> Would it be helpful to have one of Nicira's Open vSwitch
> developers come? (Is anyone interested in discussing
> networking-related topics?)  

Hi Ben,

I think there will some xapi/XCP folks there who I expect would be
interested in talking networking and vswitch in that context.

In the context of xen-unstable and the libx/xl toolstacks there's not
much required for vswitch integration -- just a working hotplug script
mechanism and a suitable script. I actually have patches for the script
growing stale in my queue -- they don't work because of issues with
hotplug script running on shutdown (basically the xenstore info is gone
when the script runs so we can't remove the VIF from the switch). Roger
Pau Monee has a patch series fixing hotplug scripts and once it goes in
I'll resurrect my old patches.

Ian.

>   I've tentatively received permission
> from management here to join for one or more days if it would be
> useful.  We're in Silicon Valley anyway so it doesn't require
> much planning on our end.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:39:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxhsW-0005CC-D1; Wed, 15 Feb 2012 16:38:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RxhsU-0005Bk-TB; Wed, 15 Feb 2012 16:38:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329323920!14401485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30210 invoked from network); 15 Feb 2012 16:38:40 -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;
	15 Feb 2012 16:38:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10721912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 16:38:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 15 Feb 2012 16:38:40 +0000
Message-ID: <1329323919.31256.329.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ben Pfaff <blp@nicira.com>
Date: Wed, 15 Feb 2012 16:38:39 +0000
In-Reply-To: <87r4xx9ubs.fsf@blp.benpfaff.org>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> Lars Kurth <lars.kurth@xen.org> writes:
> 
> > I have made preparations to reach out to further groups in SIlicon
> > valley, and want to ensure that the core people are signed up before I
> > do this.
> 
> Would it be helpful to have one of Nicira's Open vSwitch
> developers come? (Is anyone interested in discussing
> networking-related topics?)  

Hi Ben,

I think there will some xapi/XCP folks there who I expect would be
interested in talking networking and vswitch in that context.

In the context of xen-unstable and the libx/xl toolstacks there's not
much required for vswitch integration -- just a working hotplug script
mechanism and a suitable script. I actually have patches for the script
growing stale in my queue -- they don't work because of issues with
hotplug script running on shutdown (basically the xenstore info is gone
when the script runs so we can't remove the VIF from the switch). Roger
Pau Monee has a patch series fixing hotplug scripts and once it goes in
I'll resurrect my old patches.

Ian.

>   I've tentatively received permission
> from management here to join for one or more days if it would be
> useful.  We're in Silicon Valley anyway so it doesn't require
> much planning on our end.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:50:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxi31-0005p4-IS; Wed, 15 Feb 2012 16:49:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxi30-0005nq-12
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:49:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329324570!13526979!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26512 invoked from network); 15 Feb 2012 16:49:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:49:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="22052113"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:49:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:49:14 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1FGnDlH001593; Wed, 15 Feb 2012 08:49:14 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 16:49:12 +0000
Message-ID: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: fix indentation level in
	startup_cpu_idle_loop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5fe370b..0b55934 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -163,15 +163,15 @@ void sync_local_execstate(void)
 
 void startup_cpu_idle_loop(void)
 {
-        struct vcpu *v = current;
+    struct vcpu *v = current;
 
-        ASSERT(is_idle_vcpu(v));
-        /* TODO
-           cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
-           cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
-        */
+    ASSERT(is_idle_vcpu(v));
+    /* TODO
+       cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+       cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+    */
 
-        reset_stack_and_jump(idle_loop);
+    reset_stack_and_jump(idle_loop);
 }
 
 struct domain *alloc_domain_struct(void)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:50:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxi31-0005p4-IS; Wed, 15 Feb 2012 16:49:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rxi30-0005nq-12
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:49:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329324570!13526979!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26512 invoked from network); 15 Feb 2012 16:49:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:49:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="22052113"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:49:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:49:14 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1FGnDlH001593; Wed, 15 Feb 2012 08:49:14 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 16:49:12 +0000
Message-ID: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: fix indentation level in
	startup_cpu_idle_loop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5fe370b..0b55934 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -163,15 +163,15 @@ void sync_local_execstate(void)
 
 void startup_cpu_idle_loop(void)
 {
-        struct vcpu *v = current;
+    struct vcpu *v = current;
 
-        ASSERT(is_idle_vcpu(v));
-        /* TODO
-           cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
-           cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
-        */
+    ASSERT(is_idle_vcpu(v));
+    /* TODO
+       cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
+       cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
+    */
 
-        reset_stack_and_jump(idle_loop);
+    reset_stack_and_jump(idle_loop);
 }
 
 struct domain *alloc_domain_struct(void)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:50:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxi3f-0005uu-1L; Wed, 15 Feb 2012 16:50: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 1Rxi3d-0005uj-GX
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:50:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329324584!56869972!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26419 invoked from network); 15 Feb 2012 16:49:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:49:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="181982755"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:49:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:49:53 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1FGnq6m001596; Wed, 15 Feb 2012 08:49:52 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 16:49:52 +0000
Message-ID: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 xen/arch/arm/asm-offsets.c    |    4 ++
 xen/arch/arm/domain.c         |  115 ++++++++++++----------------------------
 xen/arch/arm/domain_build.c   |    3 +-
 xen/arch/arm/entry.S          |   16 ++++++
 xen/arch/arm/setup.c          |    3 +-
 xen/include/asm-arm/current.h |   41 ++++++++------
 xen/include/asm-arm/domain.h  |   21 +++++++-
 xen/include/asm-arm/regs.h    |    4 +-
 xen/include/asm-arm/system.h  |    2 +
 9 files changed, 104 insertions(+), 105 deletions(-)

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
index ee5d5d4..cc1a72a 100644
--- a/xen/arch/arm/asm-offsets.c
+++ b/xen/arch/arm/asm-offsets.c
@@ -7,6 +7,7 @@
 
 #include <xen/config.h>
 #include <xen/types.h>
+#include <xen/sched.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -65,7 +66,10 @@ void __dummy__(void)
    BLANK();
 
    DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..52a3128 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -14,7 +14,7 @@
 #include "gic.h"
 #include "vtimer.h"
 
-DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+DEFINE_PER_CPU(struct pcpu_info, pcpu_info);
 
 static void continue_idle_domain(struct vcpu *v)
 {
@@ -44,7 +44,7 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
-
+    context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
@@ -52,52 +52,36 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
 }
 
-static void __context_switch(void)
+static void schedule_tail(struct vcpu *prev)
 {
-    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
-    unsigned int          cpu = smp_processor_id();
-    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
-    struct vcpu          *n = current;
-
-    ASSERT(p != n);
-    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
-
-    if ( !is_idle_vcpu(p) )
-    {
-        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_from(p);
-    }
+    /* Re-enable interrupts before restoring state which may fault. */
+    local_irq_enable();
 
-    if ( !is_idle_vcpu(n) )
-    {
-        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_to(n);
-    }
-
-    per_cpu(curr_vcpu, cpu) = n;
+    ctxt_switch_from(prev);
 
+    /* TODO
+       update_runstate_area(current);
+    */
+    ctxt_switch_to(current);
 }
 
-static void schedule_tail(struct vcpu *v)
+static void continue_new_vcpu(struct vcpu *prev)
 {
-    if ( is_idle_vcpu(v) )
-        continue_idle_domain(v);
+    schedule_tail(prev);
+
+    if ( is_idle_vcpu(current) )
+        continue_idle_domain(current);
     else
-        continue_nonidle_domain(v);
+        continue_nonidle_domain(current);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
-    unsigned int cpu = smp_processor_id();
-
     ASSERT(local_irq_is_enabled());
-
-    printk("context switch %d:%d%s -> %d:%d%s\n",
-           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
-           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+    ASSERT(prev != next);
+    ASSERT(cpumask_empty(next->vcpu_dirty_cpumask));
 
     /* TODO
-       if (prev != next)
        update_runstate_area(prev);
     */
 
@@ -105,60 +89,19 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     set_current(next);
 
-    if ( (per_cpu(curr_vcpu, cpu) == next) ||
-         (is_idle_vcpu(next) && cpu_online(cpu)) )
-    {
-        local_irq_enable();
-    }
-    else
-    {
-        __context_switch();
-
-        /* Re-enable interrupts before restoring state which may fault. */
-        local_irq_enable();
-    }
-
-    context_saved(prev);
-
-    /* TODO
-       if (prev != next)
-       update_runstate_area(next);
-    */
-
-    schedule_tail(next);
-    BUG();
+    prev = __context_switch(prev, next);
 
+    schedule_tail(prev);
 }
 
 void continue_running(struct vcpu *same)
 {
-    schedule_tail(same);
-    BUG();
-}
-
-int __sync_local_execstate(void)
-{
-    unsigned long flags;
-    int switch_required;
-
-    local_irq_save(flags);
-
-    switch_required = (this_cpu(curr_vcpu) != current);
-
-    if ( switch_required )
-    {
-        ASSERT(current == idle_vcpu[smp_processor_id()]);
-        __context_switch();
-    }
-
-    local_irq_restore(flags);
-
-    return switch_required;
+    /* Nothing to do */
 }
 
 void sync_local_execstate(void)
 {
-    (void)__sync_local_execstate();
+    /* Nothing to do -- no lazy switching */
 }
 
 void startup_cpu_idle_loop(void)
@@ -213,6 +156,18 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    v->arch.stack = alloc_xenheap_pages(STACK_ORDER, MEMF_node(vcpu_to_node(v)));
+    if ( v->arch.stack == NULL )
+        return -ENOMEM;
+
+    v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
+                                           + STACK_SIZE
+                                           - sizeof(struct cpu_info));
+
+    memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
+    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
@@ -224,7 +179,7 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-
+    free_xenheap_pages(v->arch.stack, STACK_ORDER);
 }
 
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..9240209 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -5,6 +5,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/irq.h>
+#include <asm/regs.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -71,7 +72,7 @@ int construct_dom0(struct domain *d)
     int rc;
 
     struct vcpu *v = d->vcpu[0];
-    struct cpu_user_regs *regs = &v->arch.user_regs;
+    struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
     /* Sanity! */
     BUG_ON(d->domain_id != 0);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 16a8f36..0b9cce5 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -105,3 +105,19 @@ ENTRY(return_to_hypervisor)
 	pop {r0-r12}
 	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
 	eret
+
+/*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * r0 - prev
+ * r1 - next
+ *
+ * Returns prev in r0
+ */
+ENTRY(__context_switch)
+	add	ip, r0, #VCPU_arch_saved_context
+	stmia	ip!, {r4 - sl, fp, sp, lr}	/* Save register state */
+
+	add	r4, r1, #VCPU_arch_saved_context
+	ldmia	r4, {r4 - sl, fp, sp, pc}	/* Load registers and return */
+
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4c1d89c..55d3df0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -42,7 +42,7 @@
 static unsigned int __initdata max_cpus = NR_CPUS;
 
 /* Xen stack for bringing up the first CPU. */
-unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
 extern char __init_begin[], __init_end[], __bss_start[];
 
@@ -61,7 +61,6 @@ static void __init init_idle_domain(void)
 {
         scheduler_init();
         set_current(idle_vcpu[0]);
-        this_cpu(curr_vcpu) = current;
         /* TODO: setup_idle_pagetable(); */
 }
 
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 826efa5..1753e8e 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -5,32 +5,44 @@
 #include <xen/percpu.h>
 #include <public/xen.h>
 
+#include <asm/percpu.h>
+
 #ifndef __ASSEMBLY__
 
 struct vcpu;
 
+struct pcpu_info {
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+};
+
+DECLARE_PER_CPU(struct pcpu_info, pcpu_info);
+
+static inline struct pcpu_info *get_pcpu_info(void)
+{
+    return &this_cpu(pcpu_info);
+}
+
 struct cpu_info {
     struct cpu_user_regs guest_cpu_user_regs;
     unsigned long elr;
-    unsigned int processor_id;
-    struct vcpu *current_vcpu;
-    unsigned long per_cpu_offset;
+    unsigned long pad;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
 {
-        register unsigned long sp asm ("sp");
-        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+    register unsigned long sp asm ("sp");
+    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+    //return (struct cpu_info*)(get_pcpu_info()->current_vcpu->arch.stack + STACK_SIZE - sizeof(struct cpu_info));
 }
 
-#define get_current()         (get_cpu_info()->current_vcpu)
-#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define get_current()         (get_pcpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_pcpu_info()->current_vcpu = (vcpu))
 #define current               (get_current())
 
-#define get_processor_id()    (get_cpu_info()->processor_id)
+#define get_processor_id()    (get_pcpu_info()->processor_id)
 #define set_processor_id(id)  do {                                      \
-    struct cpu_info *ci__ = get_cpu_info();                             \
-    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+    get_pcpu_info()->processor_id = (id);                               \
 } while (0)
 
 #define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
@@ -39,15 +51,8 @@ static inline struct cpu_info *get_cpu_info(void)
     __asm__ __volatile__ (                      \
         "mov sp,%0; b "STR(__fn)      \
         : : "r" (guest_cpu_user_regs()) : "memory" )
-#endif
 
-
-/*
- * Which VCPU's state is currently running on each CPU?
- * This is not necesasrily the same as 'current' as a CPU may be
- * executing a lazy state switch.
- */
-DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+#endif
 
 #endif /* __ARM_CURRENT_H__ */
 /*
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..c1afd19 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -47,7 +47,26 @@ struct arch_domain
 
 struct arch_vcpu
 {
-    struct cpu_user_regs user_regs;
+    struct {
+        uint32_t    r4;
+        uint32_t    r5;
+        uint32_t    r6;
+        uint32_t    r7;
+        uint32_t    r8;
+        uint32_t    r9;
+        uint32_t    sl;
+        uint32_t    fp;
+        uint32_t    sp;
+        uint32_t    pc;
+    } saved_context;
+
+    void *stack;
+
+    /*
+     * Points into ->stack, more convenient than doing pointer arith
+     * all the time.
+     */
+    struct cpu_info *cpu_info;
 
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index ee095bf..54f6ed8 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -28,9 +28,7 @@
     (diff == 0);                                                              \
 })
 
-#define return_reg(v) ((v)->arch.user_regs.r0)
-
-#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+#define return_reg(v) ((v)->arch.cpu_info->guest_cpu_user_regs.r0)
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 731d89f..7963ea5 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -191,6 +191,8 @@ static inline int local_fiq_is_enabled(void)
     return !!(flags & PSR_FIQ_MASK);
 }
 
+extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
+
 #endif
 /*
  * Local variables:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:50:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxi3f-0005uu-1L; Wed, 15 Feb 2012 16:50: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 1Rxi3d-0005uj-GX
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:50:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329324584!56869972!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26419 invoked from network); 15 Feb 2012 16:49:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 16:49:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="181982755"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:49:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:49:53 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1FGnq6m001596; Wed, 15 Feb 2012 08:49:52 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 15 Feb 2012 16:49:52 +0000
Message-ID: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 xen/arch/arm/asm-offsets.c    |    4 ++
 xen/arch/arm/domain.c         |  115 ++++++++++++----------------------------
 xen/arch/arm/domain_build.c   |    3 +-
 xen/arch/arm/entry.S          |   16 ++++++
 xen/arch/arm/setup.c          |    3 +-
 xen/include/asm-arm/current.h |   41 ++++++++------
 xen/include/asm-arm/domain.h  |   21 +++++++-
 xen/include/asm-arm/regs.h    |    4 +-
 xen/include/asm-arm/system.h  |    2 +
 9 files changed, 104 insertions(+), 105 deletions(-)

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
index ee5d5d4..cc1a72a 100644
--- a/xen/arch/arm/asm-offsets.c
+++ b/xen/arch/arm/asm-offsets.c
@@ -7,6 +7,7 @@
 
 #include <xen/config.h>
 #include <xen/types.h>
+#include <xen/sched.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -65,7 +66,10 @@ void __dummy__(void)
    BLANK();
 
    DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..52a3128 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -14,7 +14,7 @@
 #include "gic.h"
 #include "vtimer.h"
 
-DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
+DEFINE_PER_CPU(struct pcpu_info, pcpu_info);
 
 static void continue_idle_domain(struct vcpu *v)
 {
@@ -44,7 +44,7 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
-
+    context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
@@ -52,52 +52,36 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
 }
 
-static void __context_switch(void)
+static void schedule_tail(struct vcpu *prev)
 {
-    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
-    unsigned int          cpu = smp_processor_id();
-    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
-    struct vcpu          *n = current;
-
-    ASSERT(p != n);
-    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
-
-    if ( !is_idle_vcpu(p) )
-    {
-        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_from(p);
-    }
+    /* Re-enable interrupts before restoring state which may fault. */
+    local_irq_enable();
 
-    if ( !is_idle_vcpu(n) )
-    {
-        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_to(n);
-    }
-
-    per_cpu(curr_vcpu, cpu) = n;
+    ctxt_switch_from(prev);
 
+    /* TODO
+       update_runstate_area(current);
+    */
+    ctxt_switch_to(current);
 }
 
-static void schedule_tail(struct vcpu *v)
+static void continue_new_vcpu(struct vcpu *prev)
 {
-    if ( is_idle_vcpu(v) )
-        continue_idle_domain(v);
+    schedule_tail(prev);
+
+    if ( is_idle_vcpu(current) )
+        continue_idle_domain(current);
     else
-        continue_nonidle_domain(v);
+        continue_nonidle_domain(current);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
-    unsigned int cpu = smp_processor_id();
-
     ASSERT(local_irq_is_enabled());
-
-    printk("context switch %d:%d%s -> %d:%d%s\n",
-           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
-           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+    ASSERT(prev != next);
+    ASSERT(cpumask_empty(next->vcpu_dirty_cpumask));
 
     /* TODO
-       if (prev != next)
        update_runstate_area(prev);
     */
 
@@ -105,60 +89,19 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     set_current(next);
 
-    if ( (per_cpu(curr_vcpu, cpu) == next) ||
-         (is_idle_vcpu(next) && cpu_online(cpu)) )
-    {
-        local_irq_enable();
-    }
-    else
-    {
-        __context_switch();
-
-        /* Re-enable interrupts before restoring state which may fault. */
-        local_irq_enable();
-    }
-
-    context_saved(prev);
-
-    /* TODO
-       if (prev != next)
-       update_runstate_area(next);
-    */
-
-    schedule_tail(next);
-    BUG();
+    prev = __context_switch(prev, next);
 
+    schedule_tail(prev);
 }
 
 void continue_running(struct vcpu *same)
 {
-    schedule_tail(same);
-    BUG();
-}
-
-int __sync_local_execstate(void)
-{
-    unsigned long flags;
-    int switch_required;
-
-    local_irq_save(flags);
-
-    switch_required = (this_cpu(curr_vcpu) != current);
-
-    if ( switch_required )
-    {
-        ASSERT(current == idle_vcpu[smp_processor_id()]);
-        __context_switch();
-    }
-
-    local_irq_restore(flags);
-
-    return switch_required;
+    /* Nothing to do */
 }
 
 void sync_local_execstate(void)
 {
-    (void)__sync_local_execstate();
+    /* Nothing to do -- no lazy switching */
 }
 
 void startup_cpu_idle_loop(void)
@@ -213,6 +156,18 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    v->arch.stack = alloc_xenheap_pages(STACK_ORDER, MEMF_node(vcpu_to_node(v)));
+    if ( v->arch.stack == NULL )
+        return -ENOMEM;
+
+    v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
+                                           + STACK_SIZE
+                                           - sizeof(struct cpu_info));
+
+    memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
+    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
@@ -224,7 +179,7 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-
+    free_xenheap_pages(v->arch.stack, STACK_ORDER);
 }
 
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..9240209 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -5,6 +5,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/irq.h>
+#include <asm/regs.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -71,7 +72,7 @@ int construct_dom0(struct domain *d)
     int rc;
 
     struct vcpu *v = d->vcpu[0];
-    struct cpu_user_regs *regs = &v->arch.user_regs;
+    struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
     /* Sanity! */
     BUG_ON(d->domain_id != 0);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 16a8f36..0b9cce5 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -105,3 +105,19 @@ ENTRY(return_to_hypervisor)
 	pop {r0-r12}
 	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
 	eret
+
+/*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * r0 - prev
+ * r1 - next
+ *
+ * Returns prev in r0
+ */
+ENTRY(__context_switch)
+	add	ip, r0, #VCPU_arch_saved_context
+	stmia	ip!, {r4 - sl, fp, sp, lr}	/* Save register state */
+
+	add	r4, r1, #VCPU_arch_saved_context
+	ldmia	r4, {r4 - sl, fp, sp, pc}	/* Load registers and return */
+
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4c1d89c..55d3df0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -42,7 +42,7 @@
 static unsigned int __initdata max_cpus = NR_CPUS;
 
 /* Xen stack for bringing up the first CPU. */
-unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
 extern char __init_begin[], __init_end[], __bss_start[];
 
@@ -61,7 +61,6 @@ static void __init init_idle_domain(void)
 {
         scheduler_init();
         set_current(idle_vcpu[0]);
-        this_cpu(curr_vcpu) = current;
         /* TODO: setup_idle_pagetable(); */
 }
 
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 826efa5..1753e8e 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -5,32 +5,44 @@
 #include <xen/percpu.h>
 #include <public/xen.h>
 
+#include <asm/percpu.h>
+
 #ifndef __ASSEMBLY__
 
 struct vcpu;
 
+struct pcpu_info {
+    unsigned int processor_id;
+    struct vcpu *current_vcpu;
+};
+
+DECLARE_PER_CPU(struct pcpu_info, pcpu_info);
+
+static inline struct pcpu_info *get_pcpu_info(void)
+{
+    return &this_cpu(pcpu_info);
+}
+
 struct cpu_info {
     struct cpu_user_regs guest_cpu_user_regs;
     unsigned long elr;
-    unsigned int processor_id;
-    struct vcpu *current_vcpu;
-    unsigned long per_cpu_offset;
+    unsigned long pad;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
 {
-        register unsigned long sp asm ("sp");
-        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+    register unsigned long sp asm ("sp");
+    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+    //return (struct cpu_info*)(get_pcpu_info()->current_vcpu->arch.stack + STACK_SIZE - sizeof(struct cpu_info));
 }
 
-#define get_current()         (get_cpu_info()->current_vcpu)
-#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
+#define get_current()         (get_pcpu_info()->current_vcpu)
+#define set_current(vcpu)     (get_pcpu_info()->current_vcpu = (vcpu))
 #define current               (get_current())
 
-#define get_processor_id()    (get_cpu_info()->processor_id)
+#define get_processor_id()    (get_pcpu_info()->processor_id)
 #define set_processor_id(id)  do {                                      \
-    struct cpu_info *ci__ = get_cpu_info();                             \
-    ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
+    get_pcpu_info()->processor_id = (id);                               \
 } while (0)
 
 #define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
@@ -39,15 +51,8 @@ static inline struct cpu_info *get_cpu_info(void)
     __asm__ __volatile__ (                      \
         "mov sp,%0; b "STR(__fn)      \
         : : "r" (guest_cpu_user_regs()) : "memory" )
-#endif
 
-
-/*
- * Which VCPU's state is currently running on each CPU?
- * This is not necesasrily the same as 'current' as a CPU may be
- * executing a lazy state switch.
- */
-DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+#endif
 
 #endif /* __ARM_CURRENT_H__ */
 /*
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..c1afd19 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -47,7 +47,26 @@ struct arch_domain
 
 struct arch_vcpu
 {
-    struct cpu_user_regs user_regs;
+    struct {
+        uint32_t    r4;
+        uint32_t    r5;
+        uint32_t    r6;
+        uint32_t    r7;
+        uint32_t    r8;
+        uint32_t    r9;
+        uint32_t    sl;
+        uint32_t    fp;
+        uint32_t    sp;
+        uint32_t    pc;
+    } saved_context;
+
+    void *stack;
+
+    /*
+     * Points into ->stack, more convenient than doing pointer arith
+     * all the time.
+     */
+    struct cpu_info *cpu_info;
 
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index ee095bf..54f6ed8 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -28,9 +28,7 @@
     (diff == 0);                                                              \
 })
 
-#define return_reg(v) ((v)->arch.user_regs.r0)
-
-#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+#define return_reg(v) ((v)->arch.cpu_info->guest_cpu_user_regs.r0)
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 731d89f..7963ea5 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -191,6 +191,8 @@ static inline int local_fiq_is_enabled(void)
     return !!(flags & PSR_FIQ_MASK);
 }
 
+extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
+
 #endif
 /*
  * Local variables:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:55:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxi8q-0006OJ-J3; Wed, 15 Feb 2012 16:55:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxi8o-0006Nc-RJ
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:55:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329324931!13038745!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11329 invoked from network); 15 Feb 2012 16:55:32 -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;
	15 Feb 2012 16:55:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="22052700"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:55:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:55:30 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FGtMrQ001635;
	Wed, 15 Feb 2012 08:55:23 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 15 Feb 2012 16:59:56 +0000
Message-ID: <1329325196-2483-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Markus Armbruster <armbru@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: detach the blkdev before bdrv_delete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We need to detach the blkdev from the BlockDriverState before calling
bdrv_delete.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Markus Armbruster <armbru@redhat.com>
---
 hw/xen_disk.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 68fa36a..bf06fc1 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -726,6 +726,7 @@ static void blk_disconnect(struct XenDevice *xendev)
         if (!blkdev->dinfo) {
             /* close/delete only if we created it ourself */
             bdrv_close(blkdev->bs);
+            bdrv_detach_dev(blkdev->bs, blkdev);
             bdrv_delete(blkdev->bs);
         }
         blkdev->bs = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 16:55:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 16:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxi8q-0006OJ-J3; Wed, 15 Feb 2012 16:55:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rxi8o-0006Nc-RJ
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 16:55:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329324931!13038745!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjAwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11329 invoked from network); 15 Feb 2012 16:55:32 -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;
	15 Feb 2012 16:55:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="22052700"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 11:55:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 11:55:30 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1FGtMrQ001635;
	Wed, 15 Feb 2012 08:55:23 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 15 Feb 2012 16:59:56 +0000
Message-ID: <1329325196-2483-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Markus Armbruster <armbru@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: detach the blkdev before bdrv_delete
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We need to detach the blkdev from the BlockDriverState before calling
bdrv_delete.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Markus Armbruster <armbru@redhat.com>
---
 hw/xen_disk.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 68fa36a..bf06fc1 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -726,6 +726,7 @@ static void blk_disconnect(struct XenDevice *xendev)
         if (!blkdev->dinfo) {
             /* close/delete only if we created it ourself */
             bdrv_close(blkdev->bs);
+            bdrv_detach_dev(blkdev->bs, blkdev);
             bdrv_delete(blkdev->bs);
         }
         blkdev->bs = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:03:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiG6-0006o0-Fd; Wed, 15 Feb 2012 17:03:10 +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 1RxiG4-0006ns-7u
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:03:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329325329!56856281!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7255 invoked from network); 15 Feb 2012 17:02:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 17:02:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxiFv-0007Uj-V2; Wed, 15 Feb 2012 17:02:59 +0000
Date: Wed, 15 Feb 2012 17:02:59 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215170259.GA28101@ocelot.phlegethon.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Wei Wang <wei.wang2@amd.com>,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:06 -0800 on 15 Feb (1329293205), Andres Lagar-Cavilla wrote:
> > Where will p2m access bit be stored? Please note that bit 52 - bit 58
> > for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
> > and bit 1 - bit 8 are free to use if PR bit = 1.
> 
> Wei,
> 
> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
> current convention?
> 
> I propose limiting p2m type to bits 52-55, and storing p2m access on bits
> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
> be zero" requirement/convention.

Eh, let's step back a bit from this.  The problem is that the IOMMU
can't handle these bits being set, but the IOMMU can't handle paged-out
or CoW memory either (because there's no way to cause the peripheral to
retry a DMA that faulted).

So can we just say that any VM that's going to use paging, sharing
or access can't have a unified p2m and IOMMU table?  That's a bit ugly
since the admin will have to make the choice, but it seems like the
hardware is forcing us into it.

Maybe the sensible choice is to default to _not_ sharing p2m and IOMMU
tables, and have thet be something an expert user can turn on (and which
disables the other features)?

Should we have a hypervisor-level interlock between PCI passthrough and
paging/sharing/access anyway?  Doing both is unlikely to lead to happiness.

Tim.

> Right now, without any considerations for paging, we're storing the p2m
> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
> course. Given your statement above, and table 14 in the IOMMU manual, how
> is this even working? Or is it not working?
> 
> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
> 
> Thanks a lot for the info!
> Andres
> >
> > Thanks,
> > Wei
> >
> >> An alternative to enabling mem_access on AMD processors will be to limit
> >> the access types to 3 bits. This would force disabling support for two
> >> modes. I'm inclined to disable two out of X, W and WX. I don't think
> >> they
> >> make sense without R permissions.
> >> Thanks!
> >> Andres
> >>
> >>>
> >>> Thanks,
> >>> Wei
> >>>
> >>>>
> >>>> Finally, the triple fault. Maybe I'm missing something obvious.
> >>>> Comments
> >>>> welcome.
> >>>>
> >>>> Patch inline below, thanks!
> >>>> Andres
> >>>>
> >>>> Enable AMD support for paging.
> >>>>
> >>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> >>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
> >>>>
> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
> >>>> --- a/xen/arch/x86/mm/mem_event.c
> >>>> +++ b/xen/arch/x86/mm/mem_event.c
> >>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
> >>>>                if ( !hap_enabled(d) )
> >>>>                    break;
> >>>>
> >>>> -            /* Currently only EPT is supported */
> >>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> >>>> -                break;
> >>>> -
> >>>>                rc = -EXDEV;
> >>>>                /* Disallow paging in a PoD guest */
> >>>>                if ( p2m->pod.entry_count )
> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
> >>>> --- a/xen/arch/x86/mm/p2m-pt.c
> >>>> +++ b/xen/arch/x86/mm/p2m-pt.c
> >>>> @@ -53,6 +53,20 @@
> >>>>    #define P2M_BASE_FLAGS \
> >>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
> >>>>
> >>>> +#ifdef __x86_64__
> >>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
> >>>> 0xff..ff
> >>>> + * value tramples over the higher-order bits used for flags (NX,
> >>>> p2mt,
> >>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> >>>> + * juggle for l1 entries only (no paging superpages!) */
> >>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> >>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) - 1))
> >>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
> >>>> +                                INVALID_MFN : (mfn))
> >>>> +#else
> >>>> +#define clipped_mfn(mfn)    (mfn)
> >>>> +#define unclip_mfn(mfn)     (mfn)
> >>>> +#endif /* __x86_64__ */
> >>>> +
> >>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
> >>>>    {
> >>>>        unsigned long flags;
> >>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
> >>>>        case p2m_invalid:
> >>>>        case p2m_mmio_dm:
> >>>>        case p2m_populate_on_demand:
> >>>> +    case p2m_ram_paging_out:
> >>>> +    case p2m_ram_paged:
> >>>> +    case p2m_ram_paging_in:
> >>>>        default:
> >>>>            return flags;
> >>>>        case p2m_ram_ro:
> >>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
> >>>>                                          shift, max)) )
> >>>>            return 0;
> >>>>
> >>>> -    /* PoD: Not present doesn't imply empty. */
> >>>> +    /* PoD/paging: Not present doesn't imply empty. */
> >>>>        if ( !l1e_get_flags(*p2m_entry) )
> >>>>        {
> >>>>            struct page_info *pg;
> >>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
> >>>>                                       0, L1_PAGETABLE_ENTRIES);
> >>>>            ASSERT(p2m_entry);
> >>>>
> >>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
> >>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
> >>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
> >>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
> >>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
> >>>>                                             p2m_type_to_flags(p2mt,
> >>>> mfn));
> >>>>            else
> >>>>                entry_content = l1e_empty();
> >>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
> >>>>            if ( entry_content.l1 != 0 )
> >>>>            {
> >>>>                p2m_add_iommu_flags(&entry_content, 0,
> >>>> iommu_pte_flags);
> >>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
> >>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
> >>>>            }
> >>>>            /* level 1 entry */
> >>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
> >>>> entry_content, 1);
> >>>> @@ -615,11 +633,12 @@ pod_retry_l1:
> >>>>                               sizeof(l1e));
> >>>>
> >>>>        if ( ret == 0 ) {
> >>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
> >>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
> >>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
> >>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
> >>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt)) );
> >>>>
> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
> >>>> -             == p2m_populate_on_demand )
> >>>> +        if ( p2mt == p2m_populate_on_demand )
> >>>>            {
> >>>>                /* The read has succeeded, so we know that the mapping
> >>>>                 * exits at this point.  */
> >>>> @@ -641,7 +660,7 @@ pod_retry_l1:
> >>>>            }
> >>>>
> >>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
> >>>> -            mfn = _mfn(l1e_get_pfn(l1e));
> >>>> +            mfn = _mfn(l1e_mfn);
> >>>>            else
> >>>>                /* XXX see above */
> >>>>                p2mt = p2m_mmio_dm;
> >>>> @@ -783,18 +802,26 @@ pod_retry_l2:
> >>>>    pod_retry_l1:
> >>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
> >>>>        {
> >>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
> >>>>            /* PoD: Try to populate */
> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> >>>> p2m_populate_on_demand )
> >>>> +        if ( l1t == p2m_populate_on_demand )
> >>>>            {
> >>>>                if ( q != p2m_query ) {
> >>>>                    if ( !p2m_pod_demand_populate(p2m, gfn,
> >>>> PAGE_ORDER_4K,
> >>>> q) )
> >>>>                        goto pod_retry_l1;
> >>>>                } else
> >>>>                    *t = p2m_populate_on_demand;
> >>>> +        } else {
> >>>> +            if ( p2m_is_paging(l1t) )
> >>>> +            {
> >>>> +                *t = l1t;
> >>>> +                /* No need to unclip due to check below */
> >>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
> >>>> +            }
> >>>>            }
> >>>>
> >>>>            unmap_domain_page(l1e);
> >>>> -        return _mfn(INVALID_MFN);
> >>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
> >>>>        }
> >>>>        mfn = _mfn(l1e_get_pfn(*l1e));
> >>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
> >>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
> >>>>                        flags = l1e_get_flags(l1e[i1]);
> >>>>                        if ( p2m_flags_to_type(flags) != ot )
> >>>>                            continue;
> >>>> -                    mfn = l1e_get_pfn(l1e[i1]);
> >>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
> >>>>                        gfn = i1 + (i2 + (i3
> >>>>    #if CONFIG_PAGING_LEVELS>= 4
> >>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
> >>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
> >>>>                               * L2_PAGETABLE_ENTRIES) *
> >>>> L1_PAGETABLE_ENTRIES;
> >>>>                        /* create a new 1le entry with the new type */
> >>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
> >>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
> >>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
> >>>> flags);
> >>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
> >>>>                                             l1mfn, l1e_content, 1);
> >>>>                    }
> >>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
> >>>>                                    entry_count++;
> >>>>                                continue;
> >>>>                            }
> >>>> -                        mfn = l1e_get_pfn(l1e[i1]);
> >>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
> >>>>                            ASSERT(mfn_valid(_mfn(mfn)));
> >>>>                            m2pfn = get_gpfn_from_mfn(mfn);
> >>>>                            if ( m2pfn != gfn&&
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Xen-devel mailing list
> >>>> Xen-devel@lists.xensource.com
> >>>> http://lists.xensource.com/xen-devel
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:03:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiG6-0006o0-Fd; Wed, 15 Feb 2012 17:03:10 +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 1RxiG4-0006ns-7u
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:03:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329325329!56856281!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7255 invoked from network); 15 Feb 2012 17:02:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 17:02:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxiFv-0007Uj-V2; Wed, 15 Feb 2012 17:02:59 +0000
Date: Wed, 15 Feb 2012 17:02:59 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215170259.GA28101@ocelot.phlegethon.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Wei Wang <wei.wang2@amd.com>,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:06 -0800 on 15 Feb (1329293205), Andres Lagar-Cavilla wrote:
> > Where will p2m access bit be stored? Please note that bit 52 - bit 58
> > for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
> > and bit 1 - bit 8 are free to use if PR bit = 1.
> 
> Wei,
> 
> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
> current convention?
> 
> I propose limiting p2m type to bits 52-55, and storing p2m access on bits
> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
> be zero" requirement/convention.

Eh, let's step back a bit from this.  The problem is that the IOMMU
can't handle these bits being set, but the IOMMU can't handle paged-out
or CoW memory either (because there's no way to cause the peripheral to
retry a DMA that faulted).

So can we just say that any VM that's going to use paging, sharing
or access can't have a unified p2m and IOMMU table?  That's a bit ugly
since the admin will have to make the choice, but it seems like the
hardware is forcing us into it.

Maybe the sensible choice is to default to _not_ sharing p2m and IOMMU
tables, and have thet be something an expert user can turn on (and which
disables the other features)?

Should we have a hypervisor-level interlock between PCI passthrough and
paging/sharing/access anyway?  Doing both is unlikely to lead to happiness.

Tim.

> Right now, without any considerations for paging, we're storing the p2m
> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
> course. Given your statement above, and table 14 in the IOMMU manual, how
> is this even working? Or is it not working?
> 
> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
> 
> Thanks a lot for the info!
> Andres
> >
> > Thanks,
> > Wei
> >
> >> An alternative to enabling mem_access on AMD processors will be to limit
> >> the access types to 3 bits. This would force disabling support for two
> >> modes. I'm inclined to disable two out of X, W and WX. I don't think
> >> they
> >> make sense without R permissions.
> >> Thanks!
> >> Andres
> >>
> >>>
> >>> Thanks,
> >>> Wei
> >>>
> >>>>
> >>>> Finally, the triple fault. Maybe I'm missing something obvious.
> >>>> Comments
> >>>> welcome.
> >>>>
> >>>> Patch inline below, thanks!
> >>>> Andres
> >>>>
> >>>> Enable AMD support for paging.
> >>>>
> >>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> >>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
> >>>>
> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
> >>>> --- a/xen/arch/x86/mm/mem_event.c
> >>>> +++ b/xen/arch/x86/mm/mem_event.c
> >>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
> >>>>                if ( !hap_enabled(d) )
> >>>>                    break;
> >>>>
> >>>> -            /* Currently only EPT is supported */
> >>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> >>>> -                break;
> >>>> -
> >>>>                rc = -EXDEV;
> >>>>                /* Disallow paging in a PoD guest */
> >>>>                if ( p2m->pod.entry_count )
> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
> >>>> --- a/xen/arch/x86/mm/p2m-pt.c
> >>>> +++ b/xen/arch/x86/mm/p2m-pt.c
> >>>> @@ -53,6 +53,20 @@
> >>>>    #define P2M_BASE_FLAGS \
> >>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
> >>>>
> >>>> +#ifdef __x86_64__
> >>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
> >>>> 0xff..ff
> >>>> + * value tramples over the higher-order bits used for flags (NX,
> >>>> p2mt,
> >>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> >>>> + * juggle for l1 entries only (no paging superpages!) */
> >>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> >>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) - 1))
> >>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
> >>>> +                                INVALID_MFN : (mfn))
> >>>> +#else
> >>>> +#define clipped_mfn(mfn)    (mfn)
> >>>> +#define unclip_mfn(mfn)     (mfn)
> >>>> +#endif /* __x86_64__ */
> >>>> +
> >>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
> >>>>    {
> >>>>        unsigned long flags;
> >>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
> >>>>        case p2m_invalid:
> >>>>        case p2m_mmio_dm:
> >>>>        case p2m_populate_on_demand:
> >>>> +    case p2m_ram_paging_out:
> >>>> +    case p2m_ram_paged:
> >>>> +    case p2m_ram_paging_in:
> >>>>        default:
> >>>>            return flags;
> >>>>        case p2m_ram_ro:
> >>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
> >>>>                                          shift, max)) )
> >>>>            return 0;
> >>>>
> >>>> -    /* PoD: Not present doesn't imply empty. */
> >>>> +    /* PoD/paging: Not present doesn't imply empty. */
> >>>>        if ( !l1e_get_flags(*p2m_entry) )
> >>>>        {
> >>>>            struct page_info *pg;
> >>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
> >>>>                                       0, L1_PAGETABLE_ENTRIES);
> >>>>            ASSERT(p2m_entry);
> >>>>
> >>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
> >>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
> >>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
> >>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
> >>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
> >>>>                                             p2m_type_to_flags(p2mt,
> >>>> mfn));
> >>>>            else
> >>>>                entry_content = l1e_empty();
> >>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
> >>>>            if ( entry_content.l1 != 0 )
> >>>>            {
> >>>>                p2m_add_iommu_flags(&entry_content, 0,
> >>>> iommu_pte_flags);
> >>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
> >>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
> >>>>            }
> >>>>            /* level 1 entry */
> >>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
> >>>> entry_content, 1);
> >>>> @@ -615,11 +633,12 @@ pod_retry_l1:
> >>>>                               sizeof(l1e));
> >>>>
> >>>>        if ( ret == 0 ) {
> >>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
> >>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
> >>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
> >>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
> >>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt)) );
> >>>>
> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
> >>>> -             == p2m_populate_on_demand )
> >>>> +        if ( p2mt == p2m_populate_on_demand )
> >>>>            {
> >>>>                /* The read has succeeded, so we know that the mapping
> >>>>                 * exits at this point.  */
> >>>> @@ -641,7 +660,7 @@ pod_retry_l1:
> >>>>            }
> >>>>
> >>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
> >>>> -            mfn = _mfn(l1e_get_pfn(l1e));
> >>>> +            mfn = _mfn(l1e_mfn);
> >>>>            else
> >>>>                /* XXX see above */
> >>>>                p2mt = p2m_mmio_dm;
> >>>> @@ -783,18 +802,26 @@ pod_retry_l2:
> >>>>    pod_retry_l1:
> >>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
> >>>>        {
> >>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
> >>>>            /* PoD: Try to populate */
> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> >>>> p2m_populate_on_demand )
> >>>> +        if ( l1t == p2m_populate_on_demand )
> >>>>            {
> >>>>                if ( q != p2m_query ) {
> >>>>                    if ( !p2m_pod_demand_populate(p2m, gfn,
> >>>> PAGE_ORDER_4K,
> >>>> q) )
> >>>>                        goto pod_retry_l1;
> >>>>                } else
> >>>>                    *t = p2m_populate_on_demand;
> >>>> +        } else {
> >>>> +            if ( p2m_is_paging(l1t) )
> >>>> +            {
> >>>> +                *t = l1t;
> >>>> +                /* No need to unclip due to check below */
> >>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
> >>>> +            }
> >>>>            }
> >>>>
> >>>>            unmap_domain_page(l1e);
> >>>> -        return _mfn(INVALID_MFN);
> >>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
> >>>>        }
> >>>>        mfn = _mfn(l1e_get_pfn(*l1e));
> >>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
> >>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
> >>>>                        flags = l1e_get_flags(l1e[i1]);
> >>>>                        if ( p2m_flags_to_type(flags) != ot )
> >>>>                            continue;
> >>>> -                    mfn = l1e_get_pfn(l1e[i1]);
> >>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
> >>>>                        gfn = i1 + (i2 + (i3
> >>>>    #if CONFIG_PAGING_LEVELS>= 4
> >>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
> >>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
> >>>>                               * L2_PAGETABLE_ENTRIES) *
> >>>> L1_PAGETABLE_ENTRIES;
> >>>>                        /* create a new 1le entry with the new type */
> >>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
> >>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
> >>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
> >>>> flags);
> >>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
> >>>>                                             l1mfn, l1e_content, 1);
> >>>>                    }
> >>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
> >>>>                                    entry_count++;
> >>>>                                continue;
> >>>>                            }
> >>>> -                        mfn = l1e_get_pfn(l1e[i1]);
> >>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
> >>>>                            ASSERT(mfn_valid(_mfn(mfn)));
> >>>>                            m2pfn = get_gpfn_from_mfn(mfn);
> >>>>                            if ( m2pfn != gfn&&
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Xen-devel mailing list
> >>>> Xen-devel@lists.xensource.com
> >>>> http://lists.xensource.com/xen-devel
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:07:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiJZ-0006yg-AO; Wed, 15 Feb 2012 17:06:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxiJY-0006yE-19
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:06:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329325597!13455527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23976 invoked from network); 15 Feb 2012 17:06:37 -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;
	15 Feb 2012 17:06:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10722717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 17:06:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 17:06:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxiJQ-00022m-Vm;
	Wed, 15 Feb 2012 17:06:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxiJQ-00011d-QM;
	Wed, 15 Feb 2012 17:06:36 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11962-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 17:06:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11962: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11962 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11962/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11959

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  618cbd27bac0
baseline version:
 xen                  0ba87b95e80b

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.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>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=618cbd27bac0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 618cbd27bac0
+ branch=xen-unstable
+ revision=618cbd27bac0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 618cbd27bac0 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:07:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiJZ-0006yg-AO; Wed, 15 Feb 2012 17:06:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxiJY-0006yE-19
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:06:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329325597!13455527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23976 invoked from network); 15 Feb 2012 17:06:37 -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;
	15 Feb 2012 17:06:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10722717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 17:06:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 17:06:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxiJQ-00022m-Vm;
	Wed, 15 Feb 2012 17:06:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxiJQ-00011d-QM;
	Wed, 15 Feb 2012 17:06:36 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11962-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 17:06:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11962: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11962 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11962/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11959

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  618cbd27bac0
baseline version:
 xen                  0ba87b95e80b

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.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>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=618cbd27bac0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 618cbd27bac0
+ branch=xen-unstable
+ revision=618cbd27bac0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 618cbd27bac0 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:07:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:07:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiKM-00072x-Or; Wed, 15 Feb 2012 17:07:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxiKK-00072J-K7
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:07:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329325645!14459222!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21699 invoked from network); 15 Feb 2012 17:07:26 -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; 15 Feb 2012 17:07:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxiKC-0007Vb-C3; Wed, 15 Feb 2012 17:07:24 +0000
Date: Wed, 15 Feb 2012 17:07:24 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215170724.GB28101@ocelot.phlegethon.org>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
	<20120214200528.GA13265@ocelot.phlegethon.org>
	<278a7245084d24bf76fe2f799d04d622.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <278a7245084d24bf76fe2f799d04d622.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:22 -0800 on 15 Feb (1329294161), Andres Lagar-Cavilla wrote:
> > Maybe we can arrange that instead of bugging out if the cpu is
> > in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
> > seems no worse than the current failure modes.
> 
> How about judiciously adding the following
> 
> get_gfn_sleep(d, gfn, type)
> {
>   if (d == current_domain && !in_atomic())
>   {
>     printk("Naughty");
>     crash_domain(d);
>     return INVALID_MFN;
>   }

Yes, that's the sort of thing I had in mind (though the in_atomic() test
shouldn't be inverted).

I'll dig out Olaf's most recent patch tomorrow and see how that would
work; I'm travelling so my access to test hardware is a bit limited but
I'll try to at least make a draft patch.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:07:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:07:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiKM-00072x-Or; Wed, 15 Feb 2012 17:07:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxiKK-00072J-K7
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:07:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329325645!14459222!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21699 invoked from network); 15 Feb 2012 17:07:26 -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; 15 Feb 2012 17:07:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxiKC-0007Vb-C3; Wed, 15 Feb 2012 17:07:24 +0000
Date: Wed, 15 Feb 2012 17:07:24 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215170724.GB28101@ocelot.phlegethon.org>
References: <mailman.3388.1329129411.1471.xen-devel@lists.xensource.com>
	<f56b9a9d22ed4bc42e77212c43b364ec.squirrel@webmail.lagarcavilla.org>
	<20120214151803.GA22116@aepfle.de>
	<d0fa6559d71e21d5b272140187ef7d0e.squirrel@webmail.lagarcavilla.org>
	<20120214200528.GA13265@ocelot.phlegethon.org>
	<278a7245084d24bf76fe2f799d04d622.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <278a7245084d24bf76fe2f799d04d622.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:22 -0800 on 15 Feb (1329294161), Andres Lagar-Cavilla wrote:
> > Maybe we can arrange that instead of bugging out if the cpu is
> > in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
> > seems no worse than the current failure modes.
> 
> How about judiciously adding the following
> 
> get_gfn_sleep(d, gfn, type)
> {
>   if (d == current_domain && !in_atomic())
>   {
>     printk("Naughty");
>     crash_domain(d);
>     return INVALID_MFN;
>   }

Yes, that's the sort of thing I had in mind (though the in_atomic() test
shouldn't be inverted).

I'll dig out Olaf's most recent patch tomorrow and see how that would
work; I'm travelling so my access to test hardware is a bit limited but
I'll try to at least make a draft patch.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:09:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxiM5-0007CV-8c; Wed, 15 Feb 2012 17:09:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxiM4-0007C7-1Q
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:09:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329325752!14106073!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1Mzg2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1Mzg2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27520 invoked from network); 15 Feb 2012 17:09:12 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-216.messagelabs.com with SMTP;
	15 Feb 2012 17:09:12 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id B6960458080;
	Wed, 15 Feb 2012 09:09:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=NcQtsKM66akZAfKGuFggjjem57wTLigVX1TzWqQP0Chl
	UhVLCKJ+glPp9l5VKabqH+n4AycKV9BGf+FkBWG31tQzjeM1HQ+4/DKUAgLYFDsL
	1emTL8X0svyc6RHxbLJgsiQByuev0I9kAwFVE5yK38ozg96tDVe0IQkPqKmzZtE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Kch+JU55/o3EqLKa+HNBhPWPPss=; b=m8NYgwLy
	NhDHfgxdBmhmueWW98DwHrKswC8q3HmWwBmUFJ66knt3xNsXTCfb5RH8HZyFPfzJ
	wCdBaDWEVRPW7H4mF+P/XXlZwBnV52SNQ9B11CDGIWVwHEv9A3NmJNYKo8yYLekD
	4Li5WTSWb0fMTHyjH6z4TA+J6Nn2CMBEY2E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id D2F5B45807C; 
	Wed, 15 Feb 2012 09:09:10 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 09:09:11 -0800
Message-ID: <542008e21423a7c8aab407319824634e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120215170259.GA28101@ocelot.phlegethon.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<20120215170259.GA28101@ocelot.phlegethon.org>
Date: Wed, 15 Feb 2012 09:09:11 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Wei Wang <wei.wang2@amd.com>,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:06 -0800 on 15 Feb (1329293205), Andres Lagar-Cavilla wrote:
>> > Where will p2m access bit be stored? Please note that bit 52 - bit 58
>> > for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>> > and bit 1 - bit 8 are free to use if PR bit = 1.
>>
>> Wei,
>>
>> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
>> current convention?
>>
>> I propose limiting p2m type to bits 52-55, and storing p2m access on
>> bits
>> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
>> be zero" requirement/convention.
>
> Eh, let's step back a bit from this.  The problem is that the IOMMU
> can't handle these bits being set, but the IOMMU can't handle paged-out
> or CoW memory either (because there's no way to cause the peripheral to
> retry a DMA that faulted).
>
> So can we just say that any VM that's going to use paging, sharing
> or access can't have a unified p2m and IOMMU table?  That's a bit ugly
> since the admin will have to make the choice, but it seems like the
> hardware is forcing us into it.
>
> Maybe the sensible choice is to default to _not_ sharing p2m and IOMMU
> tables, and have thet be something an expert user can turn on (and which
> disables the other features)?
>
> Should we have a hypervisor-level interlock between PCI passthrough and
> paging/sharing/access anyway?  Doing both is unlikely to lead to
> happiness.

That's basically my thinking, these are mutually exclusive conditions. And
I'm curious as to whether that is causing the triple fault that's killing
my domains. You seem to imply that p2m+IOMMU unification is turned on by
default -- that would crash PoD domains on AMD, wouldn't it?

Andres

>
> Tim.
>
>> Right now, without any considerations for paging, we're storing the p2m
>> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
>> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
>> course. Given your statement above, and table 14 in the IOMMU manual,
>> how
>> is this even working? Or is it not working?
>>
>> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>>
>> Thanks a lot for the info!
>> Andres
>> >
>> > Thanks,
>> > Wei
>> >
>> >> An alternative to enabling mem_access on AMD processors will be to
>> limit
>> >> the access types to 3 bits. This would force disabling support for
>> two
>> >> modes. I'm inclined to disable two out of X, W and WX. I don't think
>> >> they
>> >> make sense without R permissions.
>> >> Thanks!
>> >> Andres
>> >>
>> >>>
>> >>> Thanks,
>> >>> Wei
>> >>>
>> >>>>
>> >>>> Finally, the triple fault. Maybe I'm missing something obvious.
>> >>>> Comments
>> >>>> welcome.
>> >>>>
>> >>>> Patch inline below, thanks!
>> >>>> Andres
>> >>>>
>> >>>> Enable AMD support for paging.
>> >>>>
>> >>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>> >>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>> >>>>
>> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>> >>>> --- a/xen/arch/x86/mm/mem_event.c
>> >>>> +++ b/xen/arch/x86/mm/mem_event.c
>> >>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>> >>>>                if ( !hap_enabled(d) )
>> >>>>                    break;
>> >>>>
>> >>>> -            /* Currently only EPT is supported */
>> >>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> >>>> -                break;
>> >>>> -
>> >>>>                rc = -EXDEV;
>> >>>>                /* Disallow paging in a PoD guest */
>> >>>>                if ( p2m->pod.entry_count )
>> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>> >>>> --- a/xen/arch/x86/mm/p2m-pt.c
>> >>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> >>>> @@ -53,6 +53,20 @@
>> >>>>    #define P2M_BASE_FLAGS \
>> >>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY |
>> _PAGE_ACCESSED)
>> >>>>
>> >>>> +#ifdef __x86_64__
>> >>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>> >>>> 0xff..ff
>> >>>> + * value tramples over the higher-order bits used for flags (NX,
>> >>>> p2mt,
>> >>>> + * etc.) This happens for paging entries. Thus we do this
>> clip/unclip
>> >>>> + * juggle for l1 entries only (no paging superpages!) */
>> >>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>> >>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) -
>> 1))
>> >>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ?
>> \
>> >>>> +                                INVALID_MFN : (mfn))
>> >>>> +#else
>> >>>> +#define clipped_mfn(mfn)    (mfn)
>> >>>> +#define unclip_mfn(mfn)     (mfn)
>> >>>> +#endif /* __x86_64__ */
>> >>>> +
>> >>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>> >>>>    {
>> >>>>        unsigned long flags;
>> >>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>> >>>>        case p2m_invalid:
>> >>>>        case p2m_mmio_dm:
>> >>>>        case p2m_populate_on_demand:
>> >>>> +    case p2m_ram_paging_out:
>> >>>> +    case p2m_ram_paged:
>> >>>> +    case p2m_ram_paging_in:
>> >>>>        default:
>> >>>>            return flags;
>> >>>>        case p2m_ram_ro:
>> >>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>> >>>>                                          shift, max)) )
>> >>>>            return 0;
>> >>>>
>> >>>> -    /* PoD: Not present doesn't imply empty. */
>> >>>> +    /* PoD/paging: Not present doesn't imply empty. */
>> >>>>        if ( !l1e_get_flags(*p2m_entry) )
>> >>>>        {
>> >>>>            struct page_info *pg;
>> >>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>> >>>>                                       0, L1_PAGETABLE_ENTRIES);
>> >>>>            ASSERT(p2m_entry);
>> >>>>
>> >>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>> >>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>> >>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>> >>>> +             (p2mt == p2m_ram_paged) || (p2mt ==
>> p2m_ram_paging_in) )
>> >>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>> >>>>                                             p2m_type_to_flags(p2mt,
>> >>>> mfn));
>> >>>>            else
>> >>>>                entry_content = l1e_empty();
>> >>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>> >>>>            if ( entry_content.l1 != 0 )
>> >>>>            {
>> >>>>                p2m_add_iommu_flags(&entry_content, 0,
>> >>>> iommu_pte_flags);
>> >>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>> >>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>> >>>>            }
>> >>>>            /* level 1 entry */
>> >>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>> >>>> entry_content, 1);
>> >>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>> >>>>                               sizeof(l1e));
>> >>>>
>> >>>>        if ( ret == 0 ) {
>> >>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>> >>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>> >>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN ||
>> !p2m_is_ram(p2mt));
>> >>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>> >>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt))
>> );
>> >>>>
>> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>> >>>> -             == p2m_populate_on_demand )
>> >>>> +        if ( p2mt == p2m_populate_on_demand )
>> >>>>            {
>> >>>>                /* The read has succeeded, so we know that the
>> mapping
>> >>>>                 * exits at this point.  */
>> >>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>> >>>>            }
>> >>>>
>> >>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>> >>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>> >>>> +            mfn = _mfn(l1e_mfn);
>> >>>>            else
>> >>>>                /* XXX see above */
>> >>>>                p2mt = p2m_mmio_dm;
>> >>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>> >>>>    pod_retry_l1:
>> >>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
>> >>>>        {
>> >>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> >>>>            /* PoD: Try to populate */
>> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>> >>>> p2m_populate_on_demand )
>> >>>> +        if ( l1t == p2m_populate_on_demand )
>> >>>>            {
>> >>>>                if ( q != p2m_query ) {
>> >>>>                    if ( !p2m_pod_demand_populate(p2m, gfn,
>> >>>> PAGE_ORDER_4K,
>> >>>> q) )
>> >>>>                        goto pod_retry_l1;
>> >>>>                } else
>> >>>>                    *t = p2m_populate_on_demand;
>> >>>> +        } else {
>> >>>> +            if ( p2m_is_paging(l1t) )
>> >>>> +            {
>> >>>> +                *t = l1t;
>> >>>> +                /* No need to unclip due to check below */
>> >>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>> >>>> +            }
>> >>>>            }
>> >>>>
>> >>>>            unmap_domain_page(l1e);
>> >>>> -        return _mfn(INVALID_MFN);
>> >>>> +        return (l1t == p2m_ram_paging_out) ? mfn :
>> _mfn(INVALID_MFN);
>> >>>>        }
>> >>>>        mfn = _mfn(l1e_get_pfn(*l1e));
>> >>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> >>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>> >>>>                        flags = l1e_get_flags(l1e[i1]);
>> >>>>                        if ( p2m_flags_to_type(flags) != ot )
>> >>>>                            continue;
>> >>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>> >>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>> >>>>                        gfn = i1 + (i2 + (i3
>> >>>>    #if CONFIG_PAGING_LEVELS>= 4
>> >>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
>> >>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>> >>>>                               * L2_PAGETABLE_ENTRIES) *
>> >>>> L1_PAGETABLE_ENTRIES;
>> >>>>                        /* create a new 1le entry with the new type
>> */
>> >>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
>> >>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>> >>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>> >>>> flags);
>> >>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>> >>>>                                             l1mfn, l1e_content, 1);
>> >>>>                    }
>> >>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>> >>>>                                    entry_count++;
>> >>>>                                continue;
>> >>>>                            }
>> >>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>> >>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>> >>>>                            ASSERT(mfn_valid(_mfn(mfn)));
>> >>>>                            m2pfn = get_gpfn_from_mfn(mfn);
>> >>>>                            if ( m2pfn != gfn&&
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Xen-devel mailing list
>> >>>> Xen-devel@lists.xensource.com
>> >>>> http://lists.xensource.com/xen-devel
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:09:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxiM5-0007CV-8c; Wed, 15 Feb 2012 17:09:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxiM4-0007C7-1Q
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:09:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329325752!14106073!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1Mzg2\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1Mzg2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27520 invoked from network); 15 Feb 2012 17:09:12 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-216.messagelabs.com with SMTP;
	15 Feb 2012 17:09:12 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id B6960458080;
	Wed, 15 Feb 2012 09:09:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=NcQtsKM66akZAfKGuFggjjem57wTLigVX1TzWqQP0Chl
	UhVLCKJ+glPp9l5VKabqH+n4AycKV9BGf+FkBWG31tQzjeM1HQ+4/DKUAgLYFDsL
	1emTL8X0svyc6RHxbLJgsiQByuev0I9kAwFVE5yK38ozg96tDVe0IQkPqKmzZtE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Kch+JU55/o3EqLKa+HNBhPWPPss=; b=m8NYgwLy
	NhDHfgxdBmhmueWW98DwHrKswC8q3HmWwBmUFJ66knt3xNsXTCfb5RH8HZyFPfzJ
	wCdBaDWEVRPW7H4mF+P/XXlZwBnV52SNQ9B11CDGIWVwHEv9A3NmJNYKo8yYLekD
	4Li5WTSWb0fMTHyjH6z4TA+J6Nn2CMBEY2E=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id D2F5B45807C; 
	Wed, 15 Feb 2012 09:09:10 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 09:09:11 -0800
Message-ID: <542008e21423a7c8aab407319824634e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120215170259.GA28101@ocelot.phlegethon.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<20120215170259.GA28101@ocelot.phlegethon.org>
Date: Wed, 15 Feb 2012 09:09:11 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Wei Wang <wei.wang2@amd.com>,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:06 -0800 on 15 Feb (1329293205), Andres Lagar-Cavilla wrote:
>> > Where will p2m access bit be stored? Please note that bit 52 - bit 58
>> > for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>> > and bit 1 - bit 8 are free to use if PR bit = 1.
>>
>> Wei,
>>
>> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
>> current convention?
>>
>> I propose limiting p2m type to bits 52-55, and storing p2m access on
>> bits
>> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
>> be zero" requirement/convention.
>
> Eh, let's step back a bit from this.  The problem is that the IOMMU
> can't handle these bits being set, but the IOMMU can't handle paged-out
> or CoW memory either (because there's no way to cause the peripheral to
> retry a DMA that faulted).
>
> So can we just say that any VM that's going to use paging, sharing
> or access can't have a unified p2m and IOMMU table?  That's a bit ugly
> since the admin will have to make the choice, but it seems like the
> hardware is forcing us into it.
>
> Maybe the sensible choice is to default to _not_ sharing p2m and IOMMU
> tables, and have thet be something an expert user can turn on (and which
> disables the other features)?
>
> Should we have a hypervisor-level interlock between PCI passthrough and
> paging/sharing/access anyway?  Doing both is unlikely to lead to
> happiness.

That's basically my thinking, these are mutually exclusive conditions. And
I'm curious as to whether that is causing the triple fault that's killing
my domains. You seem to imply that p2m+IOMMU unification is turned on by
default -- that would crash PoD domains on AMD, wouldn't it?

Andres

>
> Tim.
>
>> Right now, without any considerations for paging, we're storing the p2m
>> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
>> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
>> course. Given your statement above, and table 14 in the IOMMU manual,
>> how
>> is this even working? Or is it not working?
>>
>> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>>
>> Thanks a lot for the info!
>> Andres
>> >
>> > Thanks,
>> > Wei
>> >
>> >> An alternative to enabling mem_access on AMD processors will be to
>> limit
>> >> the access types to 3 bits. This would force disabling support for
>> two
>> >> modes. I'm inclined to disable two out of X, W and WX. I don't think
>> >> they
>> >> make sense without R permissions.
>> >> Thanks!
>> >> Andres
>> >>
>> >>>
>> >>> Thanks,
>> >>> Wei
>> >>>
>> >>>>
>> >>>> Finally, the triple fault. Maybe I'm missing something obvious.
>> >>>> Comments
>> >>>> welcome.
>> >>>>
>> >>>> Patch inline below, thanks!
>> >>>> Andres
>> >>>>
>> >>>> Enable AMD support for paging.
>> >>>>
>> >>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>> >>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>> >>>>
>> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>> >>>> --- a/xen/arch/x86/mm/mem_event.c
>> >>>> +++ b/xen/arch/x86/mm/mem_event.c
>> >>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>> >>>>                if ( !hap_enabled(d) )
>> >>>>                    break;
>> >>>>
>> >>>> -            /* Currently only EPT is supported */
>> >>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> >>>> -                break;
>> >>>> -
>> >>>>                rc = -EXDEV;
>> >>>>                /* Disallow paging in a PoD guest */
>> >>>>                if ( p2m->pod.entry_count )
>> >>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>> >>>> --- a/xen/arch/x86/mm/p2m-pt.c
>> >>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> >>>> @@ -53,6 +53,20 @@
>> >>>>    #define P2M_BASE_FLAGS \
>> >>>>            (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY |
>> _PAGE_ACCESSED)
>> >>>>
>> >>>> +#ifdef __x86_64__
>> >>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>> >>>> 0xff..ff
>> >>>> + * value tramples over the higher-order bits used for flags (NX,
>> >>>> p2mt,
>> >>>> + * etc.) This happens for paging entries. Thus we do this
>> clip/unclip
>> >>>> + * juggle for l1 entries only (no paging superpages!) */
>> >>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>> >>>> +#define clipped_mfn(mfn)    ((mfn)&   ((1UL<<   EFF_MFN_WIDTH) -
>> 1))
>> >>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ?
>> \
>> >>>> +                                INVALID_MFN : (mfn))
>> >>>> +#else
>> >>>> +#define clipped_mfn(mfn)    (mfn)
>> >>>> +#define unclip_mfn(mfn)     (mfn)
>> >>>> +#endif /* __x86_64__ */
>> >>>> +
>> >>>>    static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>> >>>>    {
>> >>>>        unsigned long flags;
>> >>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>> >>>>        case p2m_invalid:
>> >>>>        case p2m_mmio_dm:
>> >>>>        case p2m_populate_on_demand:
>> >>>> +    case p2m_ram_paging_out:
>> >>>> +    case p2m_ram_paged:
>> >>>> +    case p2m_ram_paging_in:
>> >>>>        default:
>> >>>>            return flags;
>> >>>>        case p2m_ram_ro:
>> >>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>> >>>>                                          shift, max)) )
>> >>>>            return 0;
>> >>>>
>> >>>> -    /* PoD: Not present doesn't imply empty. */
>> >>>> +    /* PoD/paging: Not present doesn't imply empty. */
>> >>>>        if ( !l1e_get_flags(*p2m_entry) )
>> >>>>        {
>> >>>>            struct page_info *pg;
>> >>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>> >>>>                                       0, L1_PAGETABLE_ENTRIES);
>> >>>>            ASSERT(p2m_entry);
>> >>>>
>> >>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>> >>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>> >>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>> >>>> +             (p2mt == p2m_ram_paged) || (p2mt ==
>> p2m_ram_paging_in) )
>> >>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>> >>>>                                             p2m_type_to_flags(p2mt,
>> >>>> mfn));
>> >>>>            else
>> >>>>                entry_content = l1e_empty();
>> >>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>> >>>>            if ( entry_content.l1 != 0 )
>> >>>>            {
>> >>>>                p2m_add_iommu_flags(&entry_content, 0,
>> >>>> iommu_pte_flags);
>> >>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>> >>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>> >>>>            }
>> >>>>            /* level 1 entry */
>> >>>>            p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>> >>>> entry_content, 1);
>> >>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>> >>>>                               sizeof(l1e));
>> >>>>
>> >>>>        if ( ret == 0 ) {
>> >>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>> >>>>            p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>> >>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN ||
>> !p2m_is_ram(p2mt));
>> >>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>> >>>> +                (l1e_mfn == INVALID_MFN&&   p2m_is_paging(p2mt))
>> );
>> >>>>
>> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>> >>>> -             == p2m_populate_on_demand )
>> >>>> +        if ( p2mt == p2m_populate_on_demand )
>> >>>>            {
>> >>>>                /* The read has succeeded, so we know that the
>> mapping
>> >>>>                 * exits at this point.  */
>> >>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>> >>>>            }
>> >>>>
>> >>>>            if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>> >>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>> >>>> +            mfn = _mfn(l1e_mfn);
>> >>>>            else
>> >>>>                /* XXX see above */
>> >>>>                p2mt = p2m_mmio_dm;
>> >>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>> >>>>    pod_retry_l1:
>> >>>>        if ( (l1e_get_flags(*l1e)&   _PAGE_PRESENT) == 0 )
>> >>>>        {
>> >>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> >>>>            /* PoD: Try to populate */
>> >>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>> >>>> p2m_populate_on_demand )
>> >>>> +        if ( l1t == p2m_populate_on_demand )
>> >>>>            {
>> >>>>                if ( q != p2m_query ) {
>> >>>>                    if ( !p2m_pod_demand_populate(p2m, gfn,
>> >>>> PAGE_ORDER_4K,
>> >>>> q) )
>> >>>>                        goto pod_retry_l1;
>> >>>>                } else
>> >>>>                    *t = p2m_populate_on_demand;
>> >>>> +        } else {
>> >>>> +            if ( p2m_is_paging(l1t) )
>> >>>> +            {
>> >>>> +                *t = l1t;
>> >>>> +                /* No need to unclip due to check below */
>> >>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>> >>>> +            }
>> >>>>            }
>> >>>>
>> >>>>            unmap_domain_page(l1e);
>> >>>> -        return _mfn(INVALID_MFN);
>> >>>> +        return (l1t == p2m_ram_paging_out) ? mfn :
>> _mfn(INVALID_MFN);
>> >>>>        }
>> >>>>        mfn = _mfn(l1e_get_pfn(*l1e));
>> >>>>        *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> >>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>> >>>>                        flags = l1e_get_flags(l1e[i1]);
>> >>>>                        if ( p2m_flags_to_type(flags) != ot )
>> >>>>                            continue;
>> >>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>> >>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>> >>>>                        gfn = i1 + (i2 + (i3
>> >>>>    #if CONFIG_PAGING_LEVELS>= 4
>> >>>>    					+ (i4 * L3_PAGETABLE_ENTRIES)
>> >>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>> >>>>                               * L2_PAGETABLE_ENTRIES) *
>> >>>> L1_PAGETABLE_ENTRIES;
>> >>>>                        /* create a new 1le entry with the new type
>> */
>> >>>>                        flags = p2m_type_to_flags(nt, _mfn(mfn));
>> >>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>> >>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>> >>>> flags);
>> >>>>                        p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>> >>>>                                             l1mfn, l1e_content, 1);
>> >>>>                    }
>> >>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>> >>>>                                    entry_count++;
>> >>>>                                continue;
>> >>>>                            }
>> >>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>> >>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>> >>>>                            ASSERT(mfn_valid(_mfn(mfn)));
>> >>>>                            m2pfn = get_gpfn_from_mfn(mfn);
>> >>>>                            if ( m2pfn != gfn&&
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Xen-devel mailing list
>> >>>> Xen-devel@lists.xensource.com
>> >>>> http://lists.xensource.com/xen-devel
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:11:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiO9-0007OG-Vi; Wed, 15 Feb 2012 17:11:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RxiO8-0007NP-Ju
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:11:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329325880!14708387!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4515 invoked from network); 15 Feb 2012 17:11:21 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 17:11:21 -0000
Received: by werb14 with SMTP id b14so2379571wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 09:11:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=U/suY/TILYqo6qbhyaKOOeXFvVWU+gNuCHiVSDUpBAs=;
	b=k76nV36gab7aFX3WZFvHMIBdn5WCdn1cQWdwN/cF/679fJnAIPCJ7T3VFb/Dmvm0EJ
	42sq4s87F4V4XbkgxHQ6iOBS+y4v7rEvvvvfXljImjbl9gqo6P2RdUcPBMYzBS78lLXK
	lsgdGafPzPrK4OMS0q3z44d2RI8RbCbiN/dzA=
Received: by 10.180.100.33 with SMTP id ev1mr46250978wib.3.1329325880228;
	Wed, 15 Feb 2012 09:11:20 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id ec3sm34726929wib.1.2012.02.15.09.11.17
	(version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 09:11:18 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 15 Feb 2012 17:11:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <CB6197B1.2B516%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
	existing extensions
Thread-Index: AczsBNHAj8zKgKX5QkuWJdEJI7L8QA==
In-Reply-To: <4F3BBE3F02000078000732C6@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/02/2012 13:16, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> Why? It got bumped very recently to 0x040200, your change could
>>> well go under that same version.
>> 
>> When reviewing the history of xen-compat.h, it appeared that the version was
>> bumped
>> for each incompatible change.  Considering there are 8 bits of sub-minor
>> space, why
>> wouldn't it be bumped?  It allows an integrator of new headers to review all
>> change sets
>> associated with this one header file to understand the work required for an
>> import.
> 
> Then be it that way if it is to Keir's liking.

Yep it's fine by me.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:11:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiO9-0007OG-Vi; Wed, 15 Feb 2012 17:11:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RxiO8-0007NP-Ju
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:11:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329325880!14708387!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4515 invoked from network); 15 Feb 2012 17:11:21 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 17:11:21 -0000
Received: by werb14 with SMTP id b14so2379571wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 09:11:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=U/suY/TILYqo6qbhyaKOOeXFvVWU+gNuCHiVSDUpBAs=;
	b=k76nV36gab7aFX3WZFvHMIBdn5WCdn1cQWdwN/cF/679fJnAIPCJ7T3VFb/Dmvm0EJ
	42sq4s87F4V4XbkgxHQ6iOBS+y4v7rEvvvvfXljImjbl9gqo6P2RdUcPBMYzBS78lLXK
	lsgdGafPzPrK4OMS0q3z44d2RI8RbCbiN/dzA=
Received: by 10.180.100.33 with SMTP id ev1mr46250978wib.3.1329325880228;
	Wed, 15 Feb 2012 09:11:20 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id ec3sm34726929wib.1.2012.02.15.09.11.17
	(version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 09:11:18 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 15 Feb 2012 17:11:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <CB6197B1.2B516%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
	existing extensions
Thread-Index: AczsBNHAj8zKgKX5QkuWJdEJI7L8QA==
In-Reply-To: <4F3BBE3F02000078000732C6@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 4 v2] blkif.h: Document protocol and
 existing extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/02/2012 13:16, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> Why? It got bumped very recently to 0x040200, your change could
>>> well go under that same version.
>> 
>> When reviewing the history of xen-compat.h, it appeared that the version was
>> bumped
>> for each incompatible change.  Considering there are 8 bits of sub-minor
>> space, why
>> wouldn't it be bumped?  It allows an integrator of new headers to review all
>> change sets
>> associated with this one header file to understand the work required for an
>> import.
> 
> Then be it that way if it is to Keir's liking.

Yep it's fine by me.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:18:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiUd-0007qz-4G; Wed, 15 Feb 2012 17:18: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 1RxiUb-0007qo-8e
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:18:09 +0000
Received: from [85.158.143.35:9703] by server-1.bemta-4.messagelabs.com id
	53/6F-20925-0D8EB3F4; Wed, 15 Feb 2012 17:18:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329326288!2019223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22656 invoked from network); 15 Feb 2012 17:18:08 -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;
	15 Feb 2012 17:18:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10722954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 17:18:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 17:18:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxiUZ-00027F-Cg; Wed, 15 Feb 2012 17:18:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxiUZ-0002cT-BA;
	Wed, 15 Feb 2012 17:18:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.59599.334639.858879@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 17:18:07 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
	<20275.59617.15772.210387@mariner.uk.xensource.com>
	<CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add
 libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add =
libxl__find_free_vdev"):
> The main purpose of this series is to separate the control code from
> the device code (make xl able to plug devices from a domain different
> than dom0). Since the root image might not be stored on the dom0, we
> need to be able to make this image available to the dom0 somehow, to
> extract the kernel and ramdisk. One option is to execute pygrub from
> the device domain, the other option is to plug the domU hard drive to
> the dom0, run the bootloader to extract the kernel/initrd and unplug
> the hd.

Wow.  So this relies on a frontend in dom0 ?

I think for now it might be wise to simply expect the kernel/ramdisk
to exist as files in dom0 somewhere.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:18:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxiUd-0007qz-4G; Wed, 15 Feb 2012 17:18: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 1RxiUb-0007qo-8e
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:18:09 +0000
Received: from [85.158.143.35:9703] by server-1.bemta-4.messagelabs.com id
	53/6F-20925-0D8EB3F4; Wed, 15 Feb 2012 17:18:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329326288!2019223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22656 invoked from network); 15 Feb 2012 17:18:08 -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;
	15 Feb 2012 17:18:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,424,1325462400"; d="scan'208";a="10722954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 17:18:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 17:18:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RxiUZ-00027F-Cg; Wed, 15 Feb 2012 17:18:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RxiUZ-0002cT-BA;
	Wed, 15 Feb 2012 17:18:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20283.59599.334639.858879@mariner.uk.xensource.com>
Date: Wed, 15 Feb 2012 17:18:07 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
	<20275.59617.15772.210387@mariner.uk.xensource.com>
	<CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add
 libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add =
libxl__find_free_vdev"):
> The main purpose of this series is to separate the control code from
> the device code (make xl able to plug devices from a domain different
> than dom0). Since the root image might not be stored on the dom0, we
> need to be able to make this image available to the dom0 somehow, to
> extract the kernel and ramdisk. One option is to execute pygrub from
> the device domain, the other option is to plug the domU hard drive to
> the dom0, run the bootloader to extract the kernel/initrd and unplug
> the hd.

Wow.  So this relies on a frontend in dom0 ?

I think for now it might be wise to simply expect the kernel/ramdisk
to exist as files in dom0 somewhere.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:18:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxiUu-0007so-HW; Wed, 15 Feb 2012 17:18:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxiUt-0007sA-Ii
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:18:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329326298!14956511!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31135 invoked from network); 15 Feb 2012 17:18:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 17:18:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxiUj-0007YH-2t; Wed, 15 Feb 2012 17:18:17 +0000
Date: Wed, 15 Feb 2012 17:18:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120215171817.GC28101@ocelot.phlegethon.org>
References: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] arm: fix indentation level in
	startup_cpu_idle_loop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:49 +0000 on 15 Feb (1329324552), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  xen/arch/arm/domain.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 5fe370b..0b55934 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -163,15 +163,15 @@ void sync_local_execstate(void)
>  
>  void startup_cpu_idle_loop(void)
>  {
> -        struct vcpu *v = current;
> +    struct vcpu *v = current;
>  
> -        ASSERT(is_idle_vcpu(v));
> -        /* TODO
> -           cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> -           cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> -        */
> +    ASSERT(is_idle_vcpu(v));
> +    /* TODO
> +       cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> +       cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> +    */
>  
> -        reset_stack_and_jump(idle_loop);
> +    reset_stack_and_jump(idle_loop);
>  }
>  
>  struct domain *alloc_domain_struct(void)
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:18:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxiUu-0007so-HW; Wed, 15 Feb 2012 17:18:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxiUt-0007sA-Ii
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:18:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329326298!14956511!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31135 invoked from network); 15 Feb 2012 17:18:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 17:18:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxiUj-0007YH-2t; Wed, 15 Feb 2012 17:18:17 +0000
Date: Wed, 15 Feb 2012 17:18:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120215171817.GC28101@ocelot.phlegethon.org>
References: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] arm: fix indentation level in
	startup_cpu_idle_loop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:49 +0000 on 15 Feb (1329324552), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  xen/arch/arm/domain.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 5fe370b..0b55934 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -163,15 +163,15 @@ void sync_local_execstate(void)
>  
>  void startup_cpu_idle_loop(void)
>  {
> -        struct vcpu *v = current;
> +    struct vcpu *v = current;
>  
> -        ASSERT(is_idle_vcpu(v));
> -        /* TODO
> -           cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> -           cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> -        */
> +    ASSERT(is_idle_vcpu(v));
> +    /* TODO
> +       cpumask_set_cpu(v->processor, v->domain->domain_dirty_cpumask);
> +       cpumask_set_cpu(v->processor, v->vcpu_dirty_cpumask);
> +    */
>  
> -        reset_stack_and_jump(idle_loop);
> +    reset_stack_and_jump(idle_loop);
>  }
>  
>  struct domain *alloc_domain_struct(void)
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:20:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxiX7-0008HT-2t; Wed, 15 Feb 2012 17:20:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RxiX5-0008Fa-1r
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:20:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329326433!14956822!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5386 invoked from network); 15 Feb 2012 17:20:34 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 17:20:34 -0000
Received: by werb14 with SMTP id b14so2397425wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 09:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=T4E0EDp22CNUhRPM61uCkvizVd6sRCOFBIxKqctH9yw=;
	b=H6/KnAvZP+pDdRM0A3gzmF1qa5ERh+D+I1LOKETqOV0HQiBQB2yhMLUNFlUFpFJi6d
	Yh9hbPGE0wAOSV4CMjJLQX39O9BGyQoO63t59fyBQxnt2PWr7aFv746b56HNSc4G9yH9
	5QkFsPjSIC5GoEpqf4TslmgwN2g7nbiWdcE10=
Received: by 10.216.145.207 with SMTP id p57mr9755247wej.29.1329326432746;
	Wed, 15 Feb 2012 09:20:32 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m16sm13159200wie.9.2012.02.15.09.20.29
	(version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 09:20:30 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 15 Feb 2012 17:20:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB6199DA.2B517%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] replace bogus gdprintk() uses with {,
	d}printk()
Thread-Index: AczsBhtd6CmTvkD8MkionDJ+faboIQ==
In-Reply-To: <4F3BD630020000780007330D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] replace bogus gdprintk() uses with {,
 d}printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/02/2012 14:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> When the subject domain is not the current one (e.g. during domctl or
> HVM save/restore handling), use of gdprintk() is questionable at best,
> as it won't give the intended information on what domain is affected.
> Use plain printk() or dprintk() instead, but keep things (mostly) as
> guest messages by using XENLOG_G_*.
> 
> 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
> @@ -783,7 +783,8 @@ long arch_do_domctl(
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> -            gdprintk(XENLOG_ERR, "pt_irq_create_bind failed!\n");
> +            printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for
> dom%d\n",
> +                   ret, d->domain_id);
>  
>      bind_out:
>          rcu_unlock_domain(d);
> @@ -812,7 +813,8 @@ long arch_do_domctl(
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> -            gdprintk(XENLOG_ERR, "pt_irq_destroy_bind failed!\n");
> +            printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for
> dom%d\n",
> +                   ret, d->domain_id);
>  
>      unbind_out:
>          rcu_unlock_domain(d);
> @@ -849,9 +851,9 @@ long arch_do_domctl(
>  
>          if ( add )
>          {
> -            gdprintk(XENLOG_INFO,
> -                "memory_map:add: gfn=%lx mfn=%lx nr_mfns=%lx\n",
> -                gfn, mfn, nr_mfns);
> +            printk(XENLOG_G_INFO
> +                   "memory_map:add: dom%d gfn=%lx mfn=%lx nr=%lx\n",
> +                   d->domain_id, gfn, mfn, nr_mfns);
>  
>              ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
>              for ( i = 0; i < nr_mfns; i++ )
> @@ -859,9 +861,9 @@ long arch_do_domctl(
>          }
>          else
>          {
> -            gdprintk(XENLOG_INFO,
> -                "memory_map:remove: gfn=%lx mfn=%lx nr_mfns=%lx\n",
> -                 gfn, mfn, nr_mfns);
> +            printk(XENLOG_G_INFO
> +                   "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);
> @@ -888,9 +890,9 @@ long arch_do_domctl(
>          if ( (np == 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||
>              ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                "ioport_map:invalid:gport=%x mport=%x nr_ports=%x\n",
> -                fgp, fmp, np);
> +            printk(XENLOG_G_ERR
> +                   "ioport_map:invalid:dom%d gport=%x mport=%x nr=%x\n",
> +                   domctl->domain, fgp, fmp, np);
>              break;
>          }
>  
> @@ -912,9 +914,9 @@ long arch_do_domctl(
>          hd = domain_hvm_iommu(d);
>          if ( add )
>          {
> -            gdprintk(XENLOG_INFO,
> -                "ioport_map:add f_gport=%x f_mport=%x np=%x\n",
> -                fgp, fmp, np);
> +            printk(XENLOG_G_INFO
> +                   "ioport_map:add: dom%d gport=%x mport=%x nr=%x\n",
> +                   d->domain_id, fgp, fmp, np);
>  
>              list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
>                  if (g2m_ioport->mport == fmp )
> @@ -936,9 +938,9 @@ long arch_do_domctl(
>          }
>          else
>          {
> -            gdprintk(XENLOG_INFO,
> -                "ioport_map:remove f_gport=%x f_mport=%x np=%x\n",
> -                fgp, fmp, np);
> +            printk(XENLOG_G_INFO
> +                   "ioport_map:remove: dom%d gport=%x mport=%x nr=%x\n",
> +                   d->domain_id, fgp, fmp, np);
>              list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
>                  if ( g2m_ioport->mport == fmp )
>                  {
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -681,7 +681,8 @@ static int hvm_load_cpu_ctxt(struct doma
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%u has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> @@ -693,15 +694,15 @@ static int hvm_load_cpu_ctxt(struct doma
>           !(ctxt.cr0 & X86_CR0_ET) ||
>           ((ctxt.cr0 & (X86_CR0_PE|X86_CR0_PG)) == X86_CR0_PG) )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: bad CR0 0x%"PRIx64"\n",
> -                 ctxt.cr0);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad CR0 %#" PRIx64 "\n",
> +               d->domain_id, ctxt.cr0);
>          return -EINVAL;
>      }
>  
>      if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS(v) )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
> -                 ctxt.cr4);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" PRIx64 "\n",
> +               d->domain_id, ctxt.cr4);
>          return -EINVAL;
>      }
>  
> @@ -709,8 +710,8 @@ static int hvm_load_cpu_ctxt(struct doma
>                     | EFER_NX | EFER_SCE;
>      if ( !hvm_efer_valid(d, ctxt.msr_efer, efer_validbits) )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: bad EFER 0x%"PRIx64"\n",
> -                 ctxt.msr_efer);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
> +               d->domain_id, ctxt.msr_efer);
>          return -EINVAL;
>      }
>  
> @@ -889,7 +890,8 @@ static int hvm_load_cpu_xsave_states(str
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> @@ -901,25 +903,25 @@ static int hvm_load_cpu_xsave_states(str
>      desc = (struct hvm_save_descriptor *)&h->data[h->cur];
>      if ( sizeof (*desc) > h->size - h->cur)
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore: not enough data left to read descriptpr"
> -                 "for type %u\n", CPU_XSAVE_CODE);
> +        printk(XENLOG_G_WARNING
> +               "HVM%d restore: not enough data left to read descriptor"
> +               "for type %u\n", d->domain_id, CPU_XSAVE_CODE);
>          return -1;
>      }
>      if ( desc->length + sizeof (*desc) > h->size - h->cur)
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore: not enough data left to read %u bytes "
> -                 "for type %u\n", desc->length, CPU_XSAVE_CODE);
> +        printk(XENLOG_G_WARNING
> +               "HVM%d restore: not enough data left to read %u bytes "
> +               "for type %u\n", d->domain_id, desc->length, CPU_XSAVE_CODE);
>          return -1;
>      }
>      if ( CPU_XSAVE_CODE != desc->typecode || (desc->length >
> HVM_CPU_XSAVE_SIZE) )
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore mismatch: expected type %u with max length %u,
> "
> -                 "saw type %u length %u\n", CPU_XSAVE_CODE,
> -                 (uint32_t)HVM_CPU_XSAVE_SIZE,
> -                 desc->typecode, desc->length);
> +        printk(XENLOG_G_WARNING
> +               "HVM%d restore mismatch: expected type %u with max length %u,
> "
> +               "saw type %u length %u\n", d->domain_id, CPU_XSAVE_CODE,
> +               (unsigned int)HVM_CPU_XSAVE_SIZE,
> +               desc->typecode, desc->length);
>          return -1;
>      }
>      h->cur += sizeof (*desc);
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -667,7 +667,8 @@ static int hvm_load_mtrr_msr(struct doma
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> --- a/xen/arch/x86/hvm/save.c
> +++ b/xen/arch/x86/hvm/save.c
> @@ -42,24 +42,24 @@ int arch_hvm_load(struct domain *d, stru
>  
>      if ( hdr->magic != HVM_FILE_MAGIC )
>      {
> -        gdprintk(XENLOG_ERR,
> -                 "HVM restore: bad magic number %#"PRIx32"\n", hdr->magic);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad magic number %#"PRIx32"\n",
> +               d->domain_id, hdr->magic);
>          return -1;
>      }
>  
>      if ( hdr->version != HVM_FILE_VERSION )
>      {
> -        gdprintk(XENLOG_ERR,
> -                 "HVM restore: unsupported version %u\n", hdr->version);
> +        printk(XENLOG_G_ERR "HVM%d restore: unsupported version %u\n",
> +               d->domain_id, hdr->version);
>          return -1;
>      }
>  
>      cpuid(1, &eax, &ebx, &ecx, &edx);
>      /* CPUs ought to match but with feature-masking they might not */
>      if ( (hdr->cpuid & ~0x0fUL) != (eax & ~0x0fUL) )
> -        gdprintk(XENLOG_INFO, "HVM restore (%u): VM saved on one CPU "
> -                 "(%#"PRIx32") and restored on another (%#"PRIx32").\n",
> -                 d->domain_id, hdr->cpuid, eax);
> +        printk(XENLOG_G_INFO "HVM%d restore: VM saved on one CPU "
> +               "(%#"PRIx32") and restored on another (%#"PRIx32").\n",
> +               d->domain_id, hdr->cpuid, eax);
>  
>      /* Restore guest's preferred TSC frequency. */
>      if ( hdr->gtsc_khz )
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -448,7 +448,8 @@ static int viridian_load_vcpu_ctxt(struc
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1136,7 +1136,8 @@ static int lapic_load_hidden(struct doma
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n",
> vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>      s = vcpu_vlapic(v);
> @@ -1159,7 +1160,8 @@ static int lapic_load_regs(struct domain
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n",
> vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>      s = vcpu_vlapic(v);
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1517,9 +1517,9 @@ int pirq_guest_bind(struct vcpu *v, stru
>      {
>          if ( desc->action != NULL )
>          {
> -            gdprintk(XENLOG_INFO,
> -                    "Cannot bind IRQ %d to guest. In use by '%s'.\n",
> -                    pirq->pirq, desc->action->name);
> +            printk(XENLOG_G_INFO
> +                   "Cannot bind IRQ%d to dom%d. In use by '%s'.\n",
> +                   pirq->pirq, v->domain->domain_id, desc->action->name);
>              rc = -EBUSY;
>              goto unlock_out;
>          }
> @@ -1531,9 +1531,9 @@ int pirq_guest_bind(struct vcpu *v, stru
>                   zalloc_cpumask_var(&newaction->cpu_eoi_map) )
>                  goto retry;
>              xfree(newaction);
> -            gdprintk(XENLOG_INFO,
> -                     "Cannot bind IRQ %d to guest. Out of memory.\n",
> -                     pirq->pirq);
> +            printk(XENLOG_G_INFO
> +                   "Cannot bind IRQ%d to dom%d. Out of memory.\n",
> +                   pirq->pirq, v->domain->domain_id);
>              rc = -ENOMEM;
>              goto out;
>          }
> @@ -1558,11 +1558,10 @@ int pirq_guest_bind(struct vcpu *v, stru
>      }
>      else if ( !will_share || !action->shareable )
>      {
> -        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. %s.\n",
> -                 pirq->pirq,
> -                 will_share ?
> -                 "Others do not share" :
> -                 "Will not share with others");
> +        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. %s.\n",
> +               pirq->pirq, v->domain->domain_id,
> +               will_share ? "Others do not share"
> +                          : "Will not share with others");
>          rc = -EBUSY;
>          goto unlock_out;
>      }
> @@ -1581,8 +1580,9 @@ int pirq_guest_bind(struct vcpu *v, stru
>  
>      if ( action->nr_guests == IRQ_MAX_GUESTS )
>      {
> -        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. "
> -               "Already at max share.\n", pirq->pirq);
> +        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. "
> +               "Already at max share.\n",
> +               pirq->pirq, v->domain->domain_id);
>          rc = -EBUSY;
>          goto unlock_out;
>      }
> --- a/xen/arch/x86/oprofile/op_model_ppro.c
> +++ b/xen/arch/x86/oprofile/op_model_ppro.c
> @@ -235,10 +235,10 @@ static int ppro_allocate_msr(struct vcpu
> vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
> return 1;
>  out:
> -        gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile
> is "
> -                 "unavailable on domain %d vcpu %d.\n",
> -                 v->vcpu_id, v->domain->domain_id);
> -        return 0;
> + printk(XENLOG_G_WARNING "Insufficient memory for oprofile,"
> +        " oprofile is unavailable on dom%d vcpu%d\n",
> +        v->vcpu_id, v->domain->domain_id);
> + return 0;
>  }
>  
>  static void ppro_free_msr(struct vcpu *v)
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -945,8 +945,8 @@ int cpu_frequency_change(u64 freq)
>      /* Sanity check: CPU frequency allegedly dropping below 1MHz? */
>      if ( freq < 1000000u )
>      {
> -        gdprintk(XENLOG_WARNING, "Rejecting CPU frequency change "
> -                 "to %"PRIu64" Hz.\n", freq);
> +        printk(XENLOG_WARNING "Rejecting CPU frequency change "
> +               "to %"PRIu64" Hz\n", freq);
>          return -EINVAL;
>      }
>  
> --- a/xen/common/hvm/save.c
> +++ b/xen/common/hvm/save.c
> @@ -108,8 +108,8 @@ int hvm_save_one(struct domain *d, uint1
>  
>      if ( hvm_sr_handlers[typecode].save(d, &ctxt) != 0 )
>      {
> -        gdprintk(XENLOG_ERR,
> -                 "HVM save: failed to save type %"PRIu16"\n", typecode);
> +        printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16"\n",
> +               d->domain_id, typecode);
>          rv = -EFAULT;
>      }
>      else if ( copy_to_guest(handle,
> @@ -149,7 +149,8 @@ int hvm_save(struct domain *d, hvm_domai
>  
>      if ( hvm_save_entry(HEADER, 0, h, &hdr) != 0 )
>      {
> -        gdprintk(XENLOG_ERR, "HVM save: failed to write header\n");
> +        printk(XENLOG_G_ERR "HVM%d save: failed to write header\n",
> +               d->domain_id);
>          return -EFAULT;
>      } 
>  
> @@ -159,11 +160,13 @@ int hvm_save(struct domain *d, hvm_domai
>          handler = hvm_sr_handlers[i].save;
>          if ( handler != NULL )
>          {
> -            gdprintk(XENLOG_INFO, "HVM save: %s\n",
> hvm_sr_handlers[i].name);
> +            printk(XENLOG_G_INFO "HVM%d save: %s\n",
> +                   d->domain_id, hvm_sr_handlers[i].name);
>              if ( handler(d, h) != 0 )
>              {
> -                gdprintk(XENLOG_ERR,
> -                         "HVM save: failed to save type %"PRIu16"\n", i);
> +                printk(XENLOG_G_ERR
> +                       "HVM%d save: failed to save type %"PRIu16"\n",
> +                       d->domain_id, i);
>                  return -EFAULT;
>              } 
>          }
> @@ -173,7 +176,8 @@ int hvm_save(struct domain *d, hvm_domai
>      if ( hvm_save_entry(END, 0, h, &end) != 0 )
>      {
>          /* Run out of data */
> -        gdprintk(XENLOG_ERR, "HVM save: no room for end marker.\n");
> +        printk(XENLOG_G_ERR "HVM%d save: no room for end marker\n",
> +               d->domain_id);
>          return -EFAULT;
>      }
>  
> @@ -209,8 +213,9 @@ int hvm_load(struct domain *d, hvm_domai
>          if ( h->size - h->cur < sizeof(struct hvm_save_descriptor) )
>          {
>              /* Run out of data */
> -            gdprintk(XENLOG_ERR,
> -                     "HVM restore: save did not end with a null entry\n");
> +            printk(XENLOG_G_ERR
> +                   "HVM%d restore: save did not end with a null entry\n",
> +                   d->domain_id);
>              return -1;
>          }
>          
> @@ -223,20 +228,18 @@ int hvm_load(struct domain *d, hvm_domai
>          if ( (desc->typecode > HVM_SAVE_CODE_MAX) ||
>               ((handler = hvm_sr_handlers[desc->typecode].load) == NULL) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                     "HVM restore: unknown entry typecode %u\n",
> -                     desc->typecode);
> +            printk(XENLOG_G_ERR "HVM%d restore: unknown entry typecode %u\n",
> +                   d->domain_id, desc->typecode);
>              return -1;
>          }
>  
>          /* Load the entry */
> -        gdprintk(XENLOG_INFO, "HVM restore: %s %"PRIu16"\n",
> -                 hvm_sr_handlers[desc->typecode].name, desc->instance);
> +        printk(XENLOG_G_INFO "HVM%d restore: %s %"PRIu16"\n", d->domain_id,
> +               hvm_sr_handlers[desc->typecode].name, desc->instance);
>          if ( handler(d, h) != 0 )
>          {
> -            gdprintk(XENLOG_ERR,
> -                     "HVM restore: failed to load entry %u/%u\n",
> -                     desc->typecode, desc->instance);
> +            printk(XENLOG_G_ERR "HVM%d restore: failed to load entry
> %u/%u\n",
> +                   d->domain_id, desc->typecode, desc->instance);
>              return -1;
>          }
>      }
> @@ -251,10 +254,9 @@ int _hvm_init_entry(struct hvm_domain_co
>          = (struct hvm_save_descriptor *)&h->data[h->cur];
>      if ( h->size - h->cur < len + sizeof (*d) )
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM save: no room for %"PRIu32" + %u bytes "
> -                 "for typecode %"PRIu16"\n",
> -                 len, (unsigned) sizeof (*d), tc);
> +        printk(XENLOG_G_WARNING "HVM save: no room for"
> +               " %"PRIu32" + %zu bytes for typecode %"PRIu16"\n",
> +               len, sizeof(*d), tc);
>          return -1;
>      }
>      d->typecode = tc;
> @@ -278,17 +280,17 @@ int _hvm_check_entry(struct hvm_domain_c
>          = (struct hvm_save_descriptor *)&h->data[h->cur];
>      if ( len + sizeof (*d) > h->size - h->cur)
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore: not enough data left to read %u bytes "
> -                 "for type %u\n", len, type);
> +        printk(XENLOG_G_WARNING
> +               "HVM restore: not enough data left to read %u bytes "
> +               "for type %u\n", len, type);
>          return -1;
>      }    
>      if ( (type != d->typecode) || (len < d->length) ||
>           (strict_length && (len != d->length)) )
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore mismatch: expected type %u length %u, "
> -                 "saw type %u length %u\n", type, len, d->typecode,
> d->length);
> +        printk(XENLOG_G_WARNING
> +               "HVM restore mismatch: expected type %u length %u, "
> +               "saw type %u length %u\n", type, len, d->typecode, d->length);
>          return -1;
>      }
>      h->cur += sizeof(*d);
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -299,8 +299,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
>                      ret = query_page_offline(pfn, ptr++);
>                      break;
>                  default:
> -                    gdprintk(XENLOG_WARNING, "invalid page offline op %x\n",
> -                            op->u.page_offline.cmd);
>                      ret = -EINVAL;
>                      break;
>              }
> --- a/xen/common/xenoprof.c
> +++ b/xen/common/xenoprof.c
> @@ -144,8 +144,8 @@ share_xenoprof_page_with_guest(struct do
>          struct page_info *page = mfn_to_page(mfn + i);
>          if ( (page->count_info & (PGC_allocated|PGC_count_mask)) != 0 )
>          {
> -            gdprintk(XENLOG_INFO, "mfn 0x%lx page->count_info 0x%lx\n",
> -                     mfn + i, (unsigned long)page->count_info);
> +            printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n",
> +                   d->domain_id, mfn + i, page->count_info);
>              return -EBUSY;
>          }
>          page_set_owner(page, NULL);
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -566,9 +566,9 @@ int iommu_do_domctl(
>  
>          if ( device_assigned(seg, bus, devfn) )
>          {
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: "
> -                     "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> -                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_INFO
> +                   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>              ret = -EINVAL;
>          }
>          break;
> @@ -576,8 +576,8 @@ int iommu_do_domctl(
>      case XEN_DOMCTL_assign_device:
>          if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
> +            printk(XENLOG_G_ERR
> +                   "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
>              ret = -EINVAL;
>              break;
>          }
> @@ -593,9 +593,9 @@ int iommu_do_domctl(
>  #ifdef __ia64__ /* XXX Is this really needed? */
>          if ( device_assigned(seg, bus, devfn) )
>          {
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
> -                     "%x:%x.%x already assigned, or non-existent\n",
> -                     bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> +                   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>              ret = -EINVAL;
>              goto assign_device_out;
>          }
> @@ -603,9 +603,10 @@ int iommu_do_domctl(
>  
>          ret = assign_device(d, seg, bus, devfn);
>          if ( ret )
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
> -                     "assign device (%04x:%02x:%02x.%u) failed\n",
> -                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> +                   "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> +                   d->domain_id, ret);
>  
>      assign_device_out:
>          put_domain(d);
> @@ -614,8 +615,8 @@ int iommu_do_domctl(
>      case XEN_DOMCTL_deassign_device:
>          if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");
> +            printk(XENLOG_G_ERR
> +                   "XEN_DOMCTL_deassign_device: get_domain_by_id()
> failed\n");
>              ret = -EINVAL;
>              break;
>          }
> @@ -640,9 +641,10 @@ int iommu_do_domctl(
>          ret = deassign_device(d, seg, bus, devfn);
>          spin_unlock(&pcidevs_lock);
>          if ( ret )
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: "
> -                     "deassign device (%04x:%02x:%02x.%u) failed\n",
> -                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_ERR
> +                   "deassign %04x:%02x:%02x.%u from dom%d failed (%d)\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> +                   d->domain_id, ret);
>  
>      deassign_device_out:
>          put_domain(d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:20:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxiX7-0008HT-2t; Wed, 15 Feb 2012 17:20:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RxiX5-0008Fa-1r
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:20:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329326433!14956822!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5386 invoked from network); 15 Feb 2012 17:20:34 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2012 17:20:34 -0000
Received: by werb14 with SMTP id b14so2397425wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 15 Feb 2012 09:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=T4E0EDp22CNUhRPM61uCkvizVd6sRCOFBIxKqctH9yw=;
	b=H6/KnAvZP+pDdRM0A3gzmF1qa5ERh+D+I1LOKETqOV0HQiBQB2yhMLUNFlUFpFJi6d
	Yh9hbPGE0wAOSV4CMjJLQX39O9BGyQoO63t59fyBQxnt2PWr7aFv746b56HNSc4G9yH9
	5QkFsPjSIC5GoEpqf4TslmgwN2g7nbiWdcE10=
Received: by 10.216.145.207 with SMTP id p57mr9755247wej.29.1329326432746;
	Wed, 15 Feb 2012 09:20:32 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m16sm13159200wie.9.2012.02.15.09.20.29
	(version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 09:20:30 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 15 Feb 2012 17:20:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB6199DA.2B517%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] replace bogus gdprintk() uses with {,
	d}printk()
Thread-Index: AczsBhtd6CmTvkD8MkionDJ+faboIQ==
In-Reply-To: <4F3BD630020000780007330D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] replace bogus gdprintk() uses with {,
 d}printk()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/02/2012 14:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> When the subject domain is not the current one (e.g. during domctl or
> HVM save/restore handling), use of gdprintk() is questionable at best,
> as it won't give the intended information on what domain is affected.
> Use plain printk() or dprintk() instead, but keep things (mostly) as
> guest messages by using XENLOG_G_*.
> 
> 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
> @@ -783,7 +783,8 @@ long arch_do_domctl(
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> -            gdprintk(XENLOG_ERR, "pt_irq_create_bind failed!\n");
> +            printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for
> dom%d\n",
> +                   ret, d->domain_id);
>  
>      bind_out:
>          rcu_unlock_domain(d);
> @@ -812,7 +813,8 @@ long arch_do_domctl(
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> -            gdprintk(XENLOG_ERR, "pt_irq_destroy_bind failed!\n");
> +            printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for
> dom%d\n",
> +                   ret, d->domain_id);
>  
>      unbind_out:
>          rcu_unlock_domain(d);
> @@ -849,9 +851,9 @@ long arch_do_domctl(
>  
>          if ( add )
>          {
> -            gdprintk(XENLOG_INFO,
> -                "memory_map:add: gfn=%lx mfn=%lx nr_mfns=%lx\n",
> -                gfn, mfn, nr_mfns);
> +            printk(XENLOG_G_INFO
> +                   "memory_map:add: dom%d gfn=%lx mfn=%lx nr=%lx\n",
> +                   d->domain_id, gfn, mfn, nr_mfns);
>  
>              ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
>              for ( i = 0; i < nr_mfns; i++ )
> @@ -859,9 +861,9 @@ long arch_do_domctl(
>          }
>          else
>          {
> -            gdprintk(XENLOG_INFO,
> -                "memory_map:remove: gfn=%lx mfn=%lx nr_mfns=%lx\n",
> -                 gfn, mfn, nr_mfns);
> +            printk(XENLOG_G_INFO
> +                   "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);
> @@ -888,9 +890,9 @@ long arch_do_domctl(
>          if ( (np == 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||
>              ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                "ioport_map:invalid:gport=%x mport=%x nr_ports=%x\n",
> -                fgp, fmp, np);
> +            printk(XENLOG_G_ERR
> +                   "ioport_map:invalid:dom%d gport=%x mport=%x nr=%x\n",
> +                   domctl->domain, fgp, fmp, np);
>              break;
>          }
>  
> @@ -912,9 +914,9 @@ long arch_do_domctl(
>          hd = domain_hvm_iommu(d);
>          if ( add )
>          {
> -            gdprintk(XENLOG_INFO,
> -                "ioport_map:add f_gport=%x f_mport=%x np=%x\n",
> -                fgp, fmp, np);
> +            printk(XENLOG_G_INFO
> +                   "ioport_map:add: dom%d gport=%x mport=%x nr=%x\n",
> +                   d->domain_id, fgp, fmp, np);
>  
>              list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
>                  if (g2m_ioport->mport == fmp )
> @@ -936,9 +938,9 @@ long arch_do_domctl(
>          }
>          else
>          {
> -            gdprintk(XENLOG_INFO,
> -                "ioport_map:remove f_gport=%x f_mport=%x np=%x\n",
> -                fgp, fmp, np);
> +            printk(XENLOG_G_INFO
> +                   "ioport_map:remove: dom%d gport=%x mport=%x nr=%x\n",
> +                   d->domain_id, fgp, fmp, np);
>              list_for_each_entry(g2m_ioport, &hd->g2m_ioport_list, list)
>                  if ( g2m_ioport->mport == fmp )
>                  {
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -681,7 +681,8 @@ static int hvm_load_cpu_ctxt(struct doma
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%u has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> @@ -693,15 +694,15 @@ static int hvm_load_cpu_ctxt(struct doma
>           !(ctxt.cr0 & X86_CR0_ET) ||
>           ((ctxt.cr0 & (X86_CR0_PE|X86_CR0_PG)) == X86_CR0_PG) )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: bad CR0 0x%"PRIx64"\n",
> -                 ctxt.cr0);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad CR0 %#" PRIx64 "\n",
> +               d->domain_id, ctxt.cr0);
>          return -EINVAL;
>      }
>  
>      if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS(v) )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
> -                 ctxt.cr4);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" PRIx64 "\n",
> +               d->domain_id, ctxt.cr4);
>          return -EINVAL;
>      }
>  
> @@ -709,8 +710,8 @@ static int hvm_load_cpu_ctxt(struct doma
>                     | EFER_NX | EFER_SCE;
>      if ( !hvm_efer_valid(d, ctxt.msr_efer, efer_validbits) )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: bad EFER 0x%"PRIx64"\n",
> -                 ctxt.msr_efer);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad EFER %#" PRIx64 "\n",
> +               d->domain_id, ctxt.msr_efer);
>          return -EINVAL;
>      }
>  
> @@ -889,7 +890,8 @@ static int hvm_load_cpu_xsave_states(str
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> @@ -901,25 +903,25 @@ static int hvm_load_cpu_xsave_states(str
>      desc = (struct hvm_save_descriptor *)&h->data[h->cur];
>      if ( sizeof (*desc) > h->size - h->cur)
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore: not enough data left to read descriptpr"
> -                 "for type %u\n", CPU_XSAVE_CODE);
> +        printk(XENLOG_G_WARNING
> +               "HVM%d restore: not enough data left to read descriptor"
> +               "for type %u\n", d->domain_id, CPU_XSAVE_CODE);
>          return -1;
>      }
>      if ( desc->length + sizeof (*desc) > h->size - h->cur)
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore: not enough data left to read %u bytes "
> -                 "for type %u\n", desc->length, CPU_XSAVE_CODE);
> +        printk(XENLOG_G_WARNING
> +               "HVM%d restore: not enough data left to read %u bytes "
> +               "for type %u\n", d->domain_id, desc->length, CPU_XSAVE_CODE);
>          return -1;
>      }
>      if ( CPU_XSAVE_CODE != desc->typecode || (desc->length >
> HVM_CPU_XSAVE_SIZE) )
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore mismatch: expected type %u with max length %u,
> "
> -                 "saw type %u length %u\n", CPU_XSAVE_CODE,
> -                 (uint32_t)HVM_CPU_XSAVE_SIZE,
> -                 desc->typecode, desc->length);
> +        printk(XENLOG_G_WARNING
> +               "HVM%d restore mismatch: expected type %u with max length %u,
> "
> +               "saw type %u length %u\n", d->domain_id, CPU_XSAVE_CODE,
> +               (unsigned int)HVM_CPU_XSAVE_SIZE,
> +               desc->typecode, desc->length);
>          return -1;
>      }
>      h->cur += sizeof (*desc);
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -667,7 +667,8 @@ static int hvm_load_mtrr_msr(struct doma
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> --- a/xen/arch/x86/hvm/save.c
> +++ b/xen/arch/x86/hvm/save.c
> @@ -42,24 +42,24 @@ int arch_hvm_load(struct domain *d, stru
>  
>      if ( hdr->magic != HVM_FILE_MAGIC )
>      {
> -        gdprintk(XENLOG_ERR,
> -                 "HVM restore: bad magic number %#"PRIx32"\n", hdr->magic);
> +        printk(XENLOG_G_ERR "HVM%d restore: bad magic number %#"PRIx32"\n",
> +               d->domain_id, hdr->magic);
>          return -1;
>      }
>  
>      if ( hdr->version != HVM_FILE_VERSION )
>      {
> -        gdprintk(XENLOG_ERR,
> -                 "HVM restore: unsupported version %u\n", hdr->version);
> +        printk(XENLOG_G_ERR "HVM%d restore: unsupported version %u\n",
> +               d->domain_id, hdr->version);
>          return -1;
>      }
>  
>      cpuid(1, &eax, &ebx, &ecx, &edx);
>      /* CPUs ought to match but with feature-masking they might not */
>      if ( (hdr->cpuid & ~0x0fUL) != (eax & ~0x0fUL) )
> -        gdprintk(XENLOG_INFO, "HVM restore (%u): VM saved on one CPU "
> -                 "(%#"PRIx32") and restored on another (%#"PRIx32").\n",
> -                 d->domain_id, hdr->cpuid, eax);
> +        printk(XENLOG_G_INFO "HVM%d restore: VM saved on one CPU "
> +               "(%#"PRIx32") and restored on another (%#"PRIx32").\n",
> +               d->domain_id, hdr->cpuid, eax);
>  
>      /* Restore guest's preferred TSC frequency. */
>      if ( hdr->gtsc_khz )
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -448,7 +448,8 @@ static int viridian_load_vcpu_ctxt(struc
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no vcpu%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>  
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1136,7 +1136,8 @@ static int lapic_load_hidden(struct doma
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n",
> vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>      s = vcpu_vlapic(v);
> @@ -1159,7 +1160,8 @@ static int lapic_load_regs(struct domain
>      vcpuid = hvm_load_instance(h);
>      if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
>      {
> -        gdprintk(XENLOG_ERR, "HVM restore: domain has no vlapic %u\n",
> vcpuid);
> +        dprintk(XENLOG_G_ERR, "HVM restore: dom%d has no apic%u\n",
> +                d->domain_id, vcpuid);
>          return -EINVAL;
>      }
>      s = vcpu_vlapic(v);
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1517,9 +1517,9 @@ int pirq_guest_bind(struct vcpu *v, stru
>      {
>          if ( desc->action != NULL )
>          {
> -            gdprintk(XENLOG_INFO,
> -                    "Cannot bind IRQ %d to guest. In use by '%s'.\n",
> -                    pirq->pirq, desc->action->name);
> +            printk(XENLOG_G_INFO
> +                   "Cannot bind IRQ%d to dom%d. In use by '%s'.\n",
> +                   pirq->pirq, v->domain->domain_id, desc->action->name);
>              rc = -EBUSY;
>              goto unlock_out;
>          }
> @@ -1531,9 +1531,9 @@ int pirq_guest_bind(struct vcpu *v, stru
>                   zalloc_cpumask_var(&newaction->cpu_eoi_map) )
>                  goto retry;
>              xfree(newaction);
> -            gdprintk(XENLOG_INFO,
> -                     "Cannot bind IRQ %d to guest. Out of memory.\n",
> -                     pirq->pirq);
> +            printk(XENLOG_G_INFO
> +                   "Cannot bind IRQ%d to dom%d. Out of memory.\n",
> +                   pirq->pirq, v->domain->domain_id);
>              rc = -ENOMEM;
>              goto out;
>          }
> @@ -1558,11 +1558,10 @@ int pirq_guest_bind(struct vcpu *v, stru
>      }
>      else if ( !will_share || !action->shareable )
>      {
> -        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. %s.\n",
> -                 pirq->pirq,
> -                 will_share ?
> -                 "Others do not share" :
> -                 "Will not share with others");
> +        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. %s.\n",
> +               pirq->pirq, v->domain->domain_id,
> +               will_share ? "Others do not share"
> +                          : "Will not share with others");
>          rc = -EBUSY;
>          goto unlock_out;
>      }
> @@ -1581,8 +1580,9 @@ int pirq_guest_bind(struct vcpu *v, stru
>  
>      if ( action->nr_guests == IRQ_MAX_GUESTS )
>      {
> -        gdprintk(XENLOG_INFO, "Cannot bind IRQ %d to guest. "
> -               "Already at max share.\n", pirq->pirq);
> +        printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. "
> +               "Already at max share.\n",
> +               pirq->pirq, v->domain->domain_id);
>          rc = -EBUSY;
>          goto unlock_out;
>      }
> --- a/xen/arch/x86/oprofile/op_model_ppro.c
> +++ b/xen/arch/x86/oprofile/op_model_ppro.c
> @@ -235,10 +235,10 @@ static int ppro_allocate_msr(struct vcpu
> vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED);
> return 1;
>  out:
> -        gdprintk(XENLOG_WARNING, "Insufficient memory for oprofile, oprofile
> is "
> -                 "unavailable on domain %d vcpu %d.\n",
> -                 v->vcpu_id, v->domain->domain_id);
> -        return 0;
> + printk(XENLOG_G_WARNING "Insufficient memory for oprofile,"
> +        " oprofile is unavailable on dom%d vcpu%d\n",
> +        v->vcpu_id, v->domain->domain_id);
> + return 0;
>  }
>  
>  static void ppro_free_msr(struct vcpu *v)
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -945,8 +945,8 @@ int cpu_frequency_change(u64 freq)
>      /* Sanity check: CPU frequency allegedly dropping below 1MHz? */
>      if ( freq < 1000000u )
>      {
> -        gdprintk(XENLOG_WARNING, "Rejecting CPU frequency change "
> -                 "to %"PRIu64" Hz.\n", freq);
> +        printk(XENLOG_WARNING "Rejecting CPU frequency change "
> +               "to %"PRIu64" Hz\n", freq);
>          return -EINVAL;
>      }
>  
> --- a/xen/common/hvm/save.c
> +++ b/xen/common/hvm/save.c
> @@ -108,8 +108,8 @@ int hvm_save_one(struct domain *d, uint1
>  
>      if ( hvm_sr_handlers[typecode].save(d, &ctxt) != 0 )
>      {
> -        gdprintk(XENLOG_ERR,
> -                 "HVM save: failed to save type %"PRIu16"\n", typecode);
> +        printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16"\n",
> +               d->domain_id, typecode);
>          rv = -EFAULT;
>      }
>      else if ( copy_to_guest(handle,
> @@ -149,7 +149,8 @@ int hvm_save(struct domain *d, hvm_domai
>  
>      if ( hvm_save_entry(HEADER, 0, h, &hdr) != 0 )
>      {
> -        gdprintk(XENLOG_ERR, "HVM save: failed to write header\n");
> +        printk(XENLOG_G_ERR "HVM%d save: failed to write header\n",
> +               d->domain_id);
>          return -EFAULT;
>      } 
>  
> @@ -159,11 +160,13 @@ int hvm_save(struct domain *d, hvm_domai
>          handler = hvm_sr_handlers[i].save;
>          if ( handler != NULL )
>          {
> -            gdprintk(XENLOG_INFO, "HVM save: %s\n",
> hvm_sr_handlers[i].name);
> +            printk(XENLOG_G_INFO "HVM%d save: %s\n",
> +                   d->domain_id, hvm_sr_handlers[i].name);
>              if ( handler(d, h) != 0 )
>              {
> -                gdprintk(XENLOG_ERR,
> -                         "HVM save: failed to save type %"PRIu16"\n", i);
> +                printk(XENLOG_G_ERR
> +                       "HVM%d save: failed to save type %"PRIu16"\n",
> +                       d->domain_id, i);
>                  return -EFAULT;
>              } 
>          }
> @@ -173,7 +176,8 @@ int hvm_save(struct domain *d, hvm_domai
>      if ( hvm_save_entry(END, 0, h, &end) != 0 )
>      {
>          /* Run out of data */
> -        gdprintk(XENLOG_ERR, "HVM save: no room for end marker.\n");
> +        printk(XENLOG_G_ERR "HVM%d save: no room for end marker\n",
> +               d->domain_id);
>          return -EFAULT;
>      }
>  
> @@ -209,8 +213,9 @@ int hvm_load(struct domain *d, hvm_domai
>          if ( h->size - h->cur < sizeof(struct hvm_save_descriptor) )
>          {
>              /* Run out of data */
> -            gdprintk(XENLOG_ERR,
> -                     "HVM restore: save did not end with a null entry\n");
> +            printk(XENLOG_G_ERR
> +                   "HVM%d restore: save did not end with a null entry\n",
> +                   d->domain_id);
>              return -1;
>          }
>          
> @@ -223,20 +228,18 @@ int hvm_load(struct domain *d, hvm_domai
>          if ( (desc->typecode > HVM_SAVE_CODE_MAX) ||
>               ((handler = hvm_sr_handlers[desc->typecode].load) == NULL) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                     "HVM restore: unknown entry typecode %u\n",
> -                     desc->typecode);
> +            printk(XENLOG_G_ERR "HVM%d restore: unknown entry typecode %u\n",
> +                   d->domain_id, desc->typecode);
>              return -1;
>          }
>  
>          /* Load the entry */
> -        gdprintk(XENLOG_INFO, "HVM restore: %s %"PRIu16"\n",
> -                 hvm_sr_handlers[desc->typecode].name, desc->instance);
> +        printk(XENLOG_G_INFO "HVM%d restore: %s %"PRIu16"\n", d->domain_id,
> +               hvm_sr_handlers[desc->typecode].name, desc->instance);
>          if ( handler(d, h) != 0 )
>          {
> -            gdprintk(XENLOG_ERR,
> -                     "HVM restore: failed to load entry %u/%u\n",
> -                     desc->typecode, desc->instance);
> +            printk(XENLOG_G_ERR "HVM%d restore: failed to load entry
> %u/%u\n",
> +                   d->domain_id, desc->typecode, desc->instance);
>              return -1;
>          }
>      }
> @@ -251,10 +254,9 @@ int _hvm_init_entry(struct hvm_domain_co
>          = (struct hvm_save_descriptor *)&h->data[h->cur];
>      if ( h->size - h->cur < len + sizeof (*d) )
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM save: no room for %"PRIu32" + %u bytes "
> -                 "for typecode %"PRIu16"\n",
> -                 len, (unsigned) sizeof (*d), tc);
> +        printk(XENLOG_G_WARNING "HVM save: no room for"
> +               " %"PRIu32" + %zu bytes for typecode %"PRIu16"\n",
> +               len, sizeof(*d), tc);
>          return -1;
>      }
>      d->typecode = tc;
> @@ -278,17 +280,17 @@ int _hvm_check_entry(struct hvm_domain_c
>          = (struct hvm_save_descriptor *)&h->data[h->cur];
>      if ( len + sizeof (*d) > h->size - h->cur)
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore: not enough data left to read %u bytes "
> -                 "for type %u\n", len, type);
> +        printk(XENLOG_G_WARNING
> +               "HVM restore: not enough data left to read %u bytes "
> +               "for type %u\n", len, type);
>          return -1;
>      }    
>      if ( (type != d->typecode) || (len < d->length) ||
>           (strict_length && (len != d->length)) )
>      {
> -        gdprintk(XENLOG_WARNING,
> -                 "HVM restore mismatch: expected type %u length %u, "
> -                 "saw type %u length %u\n", type, len, d->typecode,
> d->length);
> +        printk(XENLOG_G_WARNING
> +               "HVM restore mismatch: expected type %u length %u, "
> +               "saw type %u length %u\n", type, len, d->typecode, d->length);
>          return -1;
>      }
>      h->cur += sizeof(*d);
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -299,8 +299,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysc
>                      ret = query_page_offline(pfn, ptr++);
>                      break;
>                  default:
> -                    gdprintk(XENLOG_WARNING, "invalid page offline op %x\n",
> -                            op->u.page_offline.cmd);
>                      ret = -EINVAL;
>                      break;
>              }
> --- a/xen/common/xenoprof.c
> +++ b/xen/common/xenoprof.c
> @@ -144,8 +144,8 @@ share_xenoprof_page_with_guest(struct do
>          struct page_info *page = mfn_to_page(mfn + i);
>          if ( (page->count_info & (PGC_allocated|PGC_count_mask)) != 0 )
>          {
> -            gdprintk(XENLOG_INFO, "mfn 0x%lx page->count_info 0x%lx\n",
> -                     mfn + i, (unsigned long)page->count_info);
> +            printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n",
> +                   d->domain_id, mfn + i, page->count_info);
>              return -EBUSY;
>          }
>          page_set_owner(page, NULL);
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -566,9 +566,9 @@ int iommu_do_domctl(
>  
>          if ( device_assigned(seg, bus, devfn) )
>          {
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_test_assign_device: "
> -                     "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> -                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_INFO
> +                   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>              ret = -EINVAL;
>          }
>          break;
> @@ -576,8 +576,8 @@ int iommu_do_domctl(
>      case XEN_DOMCTL_assign_device:
>          if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
> +            printk(XENLOG_G_ERR
> +                   "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
>              ret = -EINVAL;
>              break;
>          }
> @@ -593,9 +593,9 @@ int iommu_do_domctl(
>  #ifdef __ia64__ /* XXX Is this really needed? */
>          if ( device_assigned(seg, bus, devfn) )
>          {
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
> -                     "%x:%x.%x already assigned, or non-existent\n",
> -                     bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> +                   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>              ret = -EINVAL;
>              goto assign_device_out;
>          }
> @@ -603,9 +603,10 @@ int iommu_do_domctl(
>  
>          ret = assign_device(d, seg, bus, devfn);
>          if ( ret )
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_assign_device: "
> -                     "assign device (%04x:%02x:%02x.%u) failed\n",
> -                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
> +                   "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> +                   d->domain_id, ret);
>  
>      assign_device_out:
>          put_domain(d);
> @@ -614,8 +615,8 @@ int iommu_do_domctl(
>      case XEN_DOMCTL_deassign_device:
>          if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
>          {
> -            gdprintk(XENLOG_ERR,
> -                "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");
> +            printk(XENLOG_G_ERR
> +                   "XEN_DOMCTL_deassign_device: get_domain_by_id()
> failed\n");
>              ret = -EINVAL;
>              break;
>          }
> @@ -640,9 +641,10 @@ int iommu_do_domctl(
>          ret = deassign_device(d, seg, bus, devfn);
>          spin_unlock(&pcidevs_lock);
>          if ( ret )
> -            gdprintk(XENLOG_ERR, "XEN_DOMCTL_deassign_device: "
> -                     "deassign device (%04x:%02x:%02x.%u) failed\n",
> -                     seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +            printk(XENLOG_G_ERR
> +                   "deassign %04x:%02x:%02x.%u from dom%d failed (%d)\n",
> +                   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> +                   d->domain_id, ret);
>  
>      deassign_device_out:
>          put_domain(d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:34:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxikd-0000Hq-4c; Wed, 15 Feb 2012 17:34:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rxikb-0000Hg-08
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:34:41 +0000
Received: from [85.158.139.83:27704] by server-4.bemta-5.messagelabs.com id
	9E/D6-10788-0BCEB3F4; Wed, 15 Feb 2012 17:34:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329327279!7799796!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24345 invoked from network); 15 Feb 2012 17:34:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 17:34:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxikV-0007bA-Ke; Wed, 15 Feb 2012 17:34:35 +0000
Date: Wed, 15 Feb 2012 17:34:35 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215173435.GD28101@ocelot.phlegethon.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<20120215170259.GA28101@ocelot.phlegethon.org>
	<542008e21423a7c8aab407319824634e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <542008e21423a7c8aab407319824634e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Wei Wang <wei.wang2@amd.com>,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:09 -0800 on 15 Feb (1329296951), Andres Lagar-Cavilla wrote:
> That's basically my thinking, these are mutually exclusive conditions. And
> I'm curious as to whether that is causing the triple fault that's killing
> my domains.

I doubt it - at least not directly.  Have you passed through a PCI[e]
card to them?

> You seem to imply that p2m+IOMMU unification is turned on by
> default -- that would crash PoD domains on AMD, wouldn't it?

Only PoD + passthrough, if you happened to DMA to a non-populated
address.  But the same is true on Intel (though not all Intel h/w has
compatible EPT and VT-D tables).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:34:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxikd-0000Hq-4c; Wed, 15 Feb 2012 17:34:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rxikb-0000Hg-08
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:34:41 +0000
Received: from [85.158.139.83:27704] by server-4.bemta-5.messagelabs.com id
	9E/D6-10788-0BCEB3F4; Wed, 15 Feb 2012 17:34:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329327279!7799796!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24345 invoked from network); 15 Feb 2012 17:34:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2012 17:34:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxikV-0007bA-Ke; Wed, 15 Feb 2012 17:34:35 +0000
Date: Wed, 15 Feb 2012 17:34:35 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120215173435.GD28101@ocelot.phlegethon.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<20120215170259.GA28101@ocelot.phlegethon.org>
	<542008e21423a7c8aab407319824634e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <542008e21423a7c8aab407319824634e.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Wei Wang <wei.wang2@amd.com>,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:09 -0800 on 15 Feb (1329296951), Andres Lagar-Cavilla wrote:
> That's basically my thinking, these are mutually exclusive conditions. And
> I'm curious as to whether that is causing the triple fault that's killing
> my domains.

I doubt it - at least not directly.  Have you passed through a PCI[e]
card to them?

> You seem to imply that p2m+IOMMU unification is turned on by
> default -- that would crash PoD domains on AMD, wouldn't it?

Only PoD + passthrough, if you happened to DMA to a non-populated
address.  But the same is true on Intel (though not all Intel h/w has
compatible EPT and VT-D tables).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxivD-0000tQ-VL; Wed, 15 Feb 2012 17:45:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rostedt@goodmis.org>) id 1RxivC-0000sz-1J
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:45:38 +0000
X-Env-Sender: rostedt@goodmis.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329327931!13522779!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=1.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzc2MDQ2\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzc2MDQ2\n,BODY_RANDOM_LONG,
	DATE_IN_PAST_12_24
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7140 invoked from network); 15 Feb 2012 17:45:31 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-11.tower-174.messagelabs.com with SMTP;
	15 Feb 2012 17:45:31 -0000
X-Authority-Analysis: v=2.0 cv=MaXuSuDf c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17
	a=CvlS4R1r7kYA:10 a=5SG0PmZfjMsA:10 a=IkcTkHD0fZMA:10
	a=0L0fD38RAAAA:8 a=VPITGj-Wx_x99NTzypQA:9
	a=inKsXQS5WXIiikbx5UsA:7 a=QEXdDO2ut3YA:10
	a=ZycB6UtQUfgMyuk2+PxD7w==:117
X-Cloudmark-Score: 0
X-Originating-IP: 74.67.80.29
Received: from [74.67.80.29] ([74.67.80.29:41803] helo=[127.0.0.1])
	by hrndva-oedge02.mail.rr.com (envelope-from <rostedt@goodmis.org>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 54/44-05484-93FEB3F4; Wed, 15 Feb 2012 17:45:30 +0000
From: Steven Rostedt <rostedt@goodmis.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120214152955.GA17671@phenom.dumpdata.com>
References: <20120214152955.GA17671@phenom.dumpdata.com>
Date: Tue, 14 Feb 2012 13:22:02 -0500
Message-ID: <1329243722.7469.7.camel@acer.local.home>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 10:29 -0500, Konrad Rzeszutek Wilk wrote: 
> Hey,
> 
> I was running some benchmarks (netserver/netperf) where the init script just launched
> the netserver and nothing else and was concerned to see the performance not up to par.
> This was an HVM guest running with PV drivers.
> 
> If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better

There is a known performance degrade of 1 or 2% with function tracing
enabled, on some work loads. Anything more that needs to be
investigated.

Did you also keep FRAME_POINTERS enabled? FUNCTION_TRACER selects frame
pointers which can also slow down the system.

> - but it was 
> my understanding that the tracing code does not impact the machine unless it is enabled.
> And when I inserted a bunch of print_dump_bytes I do see instructions such as
> e8 6a 90 60 e1 get replaced with 66 66 66 90 so I see the the instructions getting
> patched over.

Right on boot up (and module load) the calls do get changed to nops. Now
note that there's some calls that do not get changed at boot up, but the
most recent scripts/recordmcount.c should change them to nops at compile
time.
> 
> To get a better feel for this I tried this on baremetal, and (this is going
> to sound a bit round-about way, but please bear with me), I was working on making
> the pte_flags be paravirt (so it is a function instead of being a macro) and noticed
> that on on an AMD A8-3850, with a CONFIG_PARAVIRT and CONFIG_FUNCTION_TRACER and
> running kernelbench it would run slower than without CONFIG_FUNCTION_TRACER.

Have you tried what the difference is between !CONFIG_PARAVIRT and with
and without CONFIG_FUNCTION_TRACER?

> 
> I am not really sure what the problem is, but based on those experiments
> four things come to my mind:
>  - Lots of nops and we choke the CPU instruction decoder with 20-30 bytes
>    of 'nop', so the CPU is stalling waiting for some real instructions.

But the nop is only placed at the beginning of functions.

> - The compiler has choosen to compile most of the paravirt instructions as
>    functions making the call to mcount (which gets patched over), but the
>    end result is that we have an extra 'call' in the chain.

You mean that we get a lot more functions because the compiler made them
functions? Maybe we should add "notrace" to all paravirt functions? Then
they wont have the calls or nops.

> - Somehow the low-level para-virt (like the assembler ones) calls don't get
>    patched over and still end up calling mcount? (but I really doubt that is the
>    case - but you never know).

We only live patch code in a white list of sections. But with the latest
scripts/recordmcount.c, as I stated above, the ones that don't get
patched at boot up, should be patched at compile time. But that still
keeps the nops there.

> - Something else?
> 
> My thought was to crash the kernel as it is up and running and look at the
> diassembled core to see what the instructions end up looking to get a further feel
> for this.  But before I go with this are there some other ideas of what I should look
> for?

You can just look at the objdump of vmlinux, as the recordmcount.c would
have already patched the code that is not whitelisted, and you can also
see if things are function calls.

-- Steve

> 
> Thanks!
> 
> Note: The "working on making the pte_flags be paravirt" patches are here:
> http://darnok.org/results/baseline_pte_flags_pte_attrs/ if you are interested.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 17:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 17: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.xensource.com>)
	id 1RxivD-0000tQ-VL; Wed, 15 Feb 2012 17:45:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rostedt@goodmis.org>) id 1RxivC-0000sz-1J
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 17:45:38 +0000
X-Env-Sender: rostedt@goodmis.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329327931!13522779!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=1.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzc2MDQ2\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzc2MDQ2\n,BODY_RANDOM_LONG,
	DATE_IN_PAST_12_24
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7140 invoked from network); 15 Feb 2012 17:45:31 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-11.tower-174.messagelabs.com with SMTP;
	15 Feb 2012 17:45:31 -0000
X-Authority-Analysis: v=2.0 cv=MaXuSuDf c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17
	a=CvlS4R1r7kYA:10 a=5SG0PmZfjMsA:10 a=IkcTkHD0fZMA:10
	a=0L0fD38RAAAA:8 a=VPITGj-Wx_x99NTzypQA:9
	a=inKsXQS5WXIiikbx5UsA:7 a=QEXdDO2ut3YA:10
	a=ZycB6UtQUfgMyuk2+PxD7w==:117
X-Cloudmark-Score: 0
X-Originating-IP: 74.67.80.29
Received: from [74.67.80.29] ([74.67.80.29:41803] helo=[127.0.0.1])
	by hrndva-oedge02.mail.rr.com (envelope-from <rostedt@goodmis.org>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 54/44-05484-93FEB3F4; Wed, 15 Feb 2012 17:45:30 +0000
From: Steven Rostedt <rostedt@goodmis.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120214152955.GA17671@phenom.dumpdata.com>
References: <20120214152955.GA17671@phenom.dumpdata.com>
Date: Tue, 14 Feb 2012 13:22:02 -0500
Message-ID: <1329243722.7469.7.camel@acer.local.home>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-02-14 at 10:29 -0500, Konrad Rzeszutek Wilk wrote: 
> Hey,
> 
> I was running some benchmarks (netserver/netperf) where the init script just launched
> the netserver and nothing else and was concerned to see the performance not up to par.
> This was an HVM guest running with PV drivers.
> 
> If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better

There is a known performance degrade of 1 or 2% with function tracing
enabled, on some work loads. Anything more that needs to be
investigated.

Did you also keep FRAME_POINTERS enabled? FUNCTION_TRACER selects frame
pointers which can also slow down the system.

> - but it was 
> my understanding that the tracing code does not impact the machine unless it is enabled.
> And when I inserted a bunch of print_dump_bytes I do see instructions such as
> e8 6a 90 60 e1 get replaced with 66 66 66 90 so I see the the instructions getting
> patched over.

Right on boot up (and module load) the calls do get changed to nops. Now
note that there's some calls that do not get changed at boot up, but the
most recent scripts/recordmcount.c should change them to nops at compile
time.
> 
> To get a better feel for this I tried this on baremetal, and (this is going
> to sound a bit round-about way, but please bear with me), I was working on making
> the pte_flags be paravirt (so it is a function instead of being a macro) and noticed
> that on on an AMD A8-3850, with a CONFIG_PARAVIRT and CONFIG_FUNCTION_TRACER and
> running kernelbench it would run slower than without CONFIG_FUNCTION_TRACER.

Have you tried what the difference is between !CONFIG_PARAVIRT and with
and without CONFIG_FUNCTION_TRACER?

> 
> I am not really sure what the problem is, but based on those experiments
> four things come to my mind:
>  - Lots of nops and we choke the CPU instruction decoder with 20-30 bytes
>    of 'nop', so the CPU is stalling waiting for some real instructions.

But the nop is only placed at the beginning of functions.

> - The compiler has choosen to compile most of the paravirt instructions as
>    functions making the call to mcount (which gets patched over), but the
>    end result is that we have an extra 'call' in the chain.

You mean that we get a lot more functions because the compiler made them
functions? Maybe we should add "notrace" to all paravirt functions? Then
they wont have the calls or nops.

> - Somehow the low-level para-virt (like the assembler ones) calls don't get
>    patched over and still end up calling mcount? (but I really doubt that is the
>    case - but you never know).

We only live patch code in a white list of sections. But with the latest
scripts/recordmcount.c, as I stated above, the ones that don't get
patched at boot up, should be patched at compile time. But that still
keeps the nops there.

> - Something else?
> 
> My thought was to crash the kernel as it is up and running and look at the
> diassembled core to see what the instructions end up looking to get a further feel
> for this.  But before I go with this are there some other ideas of what I should look
> for?

You can just look at the objdump of vmlinux, as the recordmcount.c would
have already patched the code that is not whitelisted, and you can also
see if things are function calls.

-- Steve

> 
> Thanks!
> 
> Note: The "working on making the pte_flags be paravirt" patches are here:
> http://darnok.org/results/baseline_pte_flags_pte_attrs/ if you are interested.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 18:32:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 18:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxjdd-0002Y8-Gx; Wed, 15 Feb 2012 18:31:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rxjdc-0002Xw-6K
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 18:31:32 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329330685!14716947!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTAxODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8936 invoked from network); 15 Feb 2012 18:31:26 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 18:31:26 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E56EB26DE;
	Wed, 15 Feb 2012 20:31:23 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1C8652004A; Wed, 15 Feb 2012 20:31:23 +0200 (EET)
Date: Wed, 15 Feb 2012 20:31:23 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120215183122.GO12984@reaktio.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 15, 2012 at 07:29:54PM +0300, Anton Samsonov wrote:
> 2012/2/10 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> 
> AS>> Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)
> KRW> Do you get the same issue with a pv-ops dom0? So also 3.1, but
> from kernel.org?
> 
> Unfortunately, I'm not skilled at compiling the kernel myself. I tried
> building the newest 3.2.6
> with all Xen options (which I could find by "Xen" keyword) enabled,
> but the resulting system
> didn't have netback.ko module at all, barely booted, and xm was not
> able to communicate
> with the hypervisor.
> 

See this wiki page for all the common troubleshooting steps
when xend does not start:
http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F


About compiling the dom0 kernel, see this wiki page:
http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_support


Hopefully those help..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 18:32:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 18:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxjdd-0002Y8-Gx; Wed, 15 Feb 2012 18:31:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rxjdc-0002Xw-6K
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 18:31:32 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329330685!14716947!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTAxODU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8936 invoked from network); 15 Feb 2012 18:31:26 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 18:31:26 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E56EB26DE;
	Wed, 15 Feb 2012 20:31:23 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1C8652004A; Wed, 15 Feb 2012 20:31:23 +0200 (EET)
Date: Wed, 15 Feb 2012 20:31:23 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120215183122.GO12984@reaktio.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in netback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 15, 2012 at 07:29:54PM +0300, Anton Samsonov wrote:
> 2012/2/10 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> 
> AS>> Dom0 is openSUSE 12.1 on AMD64 (Linux 3.1.0-1.2-xen)
> KRW> Do you get the same issue with a pv-ops dom0? So also 3.1, but
> from kernel.org?
> 
> Unfortunately, I'm not skilled at compiling the kernel myself. I tried
> building the newest 3.2.6
> with all Xen options (which I could find by "Xen" keyword) enabled,
> but the resulting system
> didn't have netback.ko module at all, barely booted, and xm was not
> able to communicate
> with the hypervisor.
> 

See this wiki page for all the common troubleshooting steps
when xend does not start:
http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F


About compiling the dom0 kernel, see this wiki page:
http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_support


Hopefully those help..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 19:32:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 19:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxkaL-0003gl-6C; Wed, 15 Feb 2012 19:32: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 1RxkaI-0003gd-Vr
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 19:32:11 +0000
Received: from [85.158.139.83:33025] by server-10.bemta-5.messagelabs.com id
	6D/AC-07861-A380C3F4; Wed, 15 Feb 2012 19:32:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329334327!15237791!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxNTg4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32319 invoked from network); 15 Feb 2012 19:32:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 19:32: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 q1FJVEfX020777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 19:31:16 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
	q1FJVBNo009998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 19:31:11 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
	q1FJV8DT027238; Wed, 15 Feb 2012 13:31:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 11:31:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 12F2D41FD4; Wed, 15 Feb 2012 14:28:05 -0500 (EST)
Date: Wed, 15 Feb 2012 14:28:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20120215192804.GA21695@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X"
Content-Disposition: inline
In-Reply-To: <zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F3C0805.0056,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 25, 2012 at 08:06:12PM +0100, Carsten Schiers wrote:
> Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel. I noticed that the load increase is
> reduced a bit, but noticably. It's only a simple test, running the DomU for 2 minutes, but the idle load is aprox.
> 
>   - 2.6.32 pvops		12-13%
>   - 3.2.1 pvops		10-11%
>   - 2.6.34 XenoLinux	7-8%

I took a stab at Jan's idea - it compiles but I hadn't been able to properly test it.

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="vmalloc_using_xen_limit_pages.patch"

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..6bb6f68 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 
 #include <trace/events/xen.h>
 
@@ -2073,6 +2074,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */
 #define MAX_CONTIG_ORDER 9 /* 2MB */
 static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 
 #define VOID_PTE (mfn_pte(0, __pgprot(0)))
 static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
@@ -2097,6 +2099,36 @@ static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n = 0;
+	struct multicall_space mcs;
+	struct page *page;
+	xen_mc_batch();
+	for (i = 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+		page = &pages[i];
+		mcs = __xen_mc_entry(0);
+
+		if (in_frames)
+			in_frames[i] = pfn_to_mfn(page_to_pfn(page));
+
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_PTE, 0);
+		__set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] = page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+
+	return n;
+}
 
 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to
@@ -2140,6 +2172,49 @@ static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
 
 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn,
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit = 1u << order;
+	for (i = 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+		page = &pages[i];
+		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, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 
 /*
  * Perform the hypercall to exchange a region of our pfns to point to
@@ -2266,6 +2341,90 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames = discontig_frames, *out_frames = limited_frames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n = 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map = kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map = &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i = 0; i < 1ULL << order; i++) {
+		void *vaddr;
+		page = &pages[i];
+		vaddr = page_address(page);
+		if (address_bits) {
+			if (!pfn_to_mfn(virt_to_mfn(vaddr)) >> (address_bits - PAGE_SHIFT))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map != &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n = xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, limit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success = xen_exchange_memory(n, 0, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map != &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)
 {
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 03c85d7..ae5b1ef 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -28,4 +28,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 
+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 27be2f0..4fa2066 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 
+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 
 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end)
@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask == (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &= (__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size = (nr_pages * sizeof(struct page *));
 
@@ -1586,6 +1592,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] = page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages = i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 
 	if (map_vm_area(area, prot, &pages))

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--LZvS9be/3tNcYl/X--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 19:32:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 19:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxkaL-0003gl-6C; Wed, 15 Feb 2012 19:32: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 1RxkaI-0003gd-Vr
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 19:32:11 +0000
Received: from [85.158.139.83:33025] by server-10.bemta-5.messagelabs.com id
	6D/AC-07861-A380C3F4; Wed, 15 Feb 2012 19:32:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329334327!15237791!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQxNTg4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32319 invoked from network); 15 Feb 2012 19:32:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 19:32: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 q1FJVEfX020777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 19:31:16 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
	q1FJVBNo009998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 19:31:11 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
	q1FJV8DT027238; Wed, 15 Feb 2012 13:31:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 11:31:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 12F2D41FD4; Wed, 15 Feb 2012 14:28:05 -0500 (EST)
Date: Wed, 15 Feb 2012 14:28:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20120215192804.GA21695@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X"
Content-Disposition: inline
In-Reply-To: <zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F3C0805.0056,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 25, 2012 at 08:06:12PM +0100, Carsten Schiers wrote:
> Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel. I noticed that the load increase is
> reduced a bit, but noticably. It's only a simple test, running the DomU for 2 minutes, but the idle load is aprox.
> 
>   - 2.6.32 pvops		12-13%
>   - 3.2.1 pvops		10-11%
>   - 2.6.34 XenoLinux	7-8%

I took a stab at Jan's idea - it compiles but I hadn't been able to properly test it.

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="vmalloc_using_xen_limit_pages.patch"

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 87f6673..6bb6f68 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
 #include <linux/gfp.h>
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
+#include <linux/slab.h>
 
 #include <trace/events/xen.h>
 
@@ -2073,6 +2074,7 @@ void __init xen_init_mmu_ops(void)
 /* Protected by xen_reservation_lock. */
 #define MAX_CONTIG_ORDER 9 /* 2MB */
 static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];
 
 #define VOID_PTE (mfn_pte(0, __pgprot(0)))
 static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
@@ -2097,6 +2099,36 @@ static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
 	}
 	xen_mc_issue(0);
 }
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+				unsigned long *in_frames,
+				unsigned long *out_frames,
+				void *limit_bitmap)
+{
+	int i, n = 0;
+	struct multicall_space mcs;
+	struct page *page;
+	xen_mc_batch();
+	for (i = 0; i < (1UL<<order); i++) {
+		if (!test_bit(i, limit_bitmap))
+			continue;
+		page = &pages[i];
+		mcs = __xen_mc_entry(0);
+
+		if (in_frames)
+			in_frames[i] = pfn_to_mfn(page_to_pfn(page));
+
+		MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_PTE, 0);
+		__set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+		if (out_frames)
+			out_frames[i] = page_to_pfn(page);
+		++n;
+
+	}
+	xen_mc_issue(0);
+
+	return n;
+}
 
 /*
  * Update the pfn-to-mfn mappings for a virtual address range, either to
@@ -2140,6 +2172,49 @@ static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
 
 	xen_mc_issue(0);
 }
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+				     unsigned long *mfns,
+				     unsigned long first_mfn,
+				     void *limit_map)
+{
+	unsigned i, limit;
+	unsigned long mfn;
+	struct page *page;
+
+	xen_mc_batch();
+
+	limit = 1u << order;
+	for (i = 0; i < limit; i++) {
+		struct multicall_space mcs;
+		unsigned flags;
+
+		if (!test_bit(i, limit_map))
+			continue;
+		page = &pages[i];
+		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, (unsigned long)page_address(page),
+				mfn_pte(mfn, PAGE_KERNEL), flags);
+
+		set_phys_to_machine(page_to_pfn(page), mfn);
+	}
+
+	xen_mc_issue(0);
+}
+
 
 /*
  * Perform the hypercall to exchange a region of our pfns to point to
@@ -2266,6 +2341,90 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits)
+{
+	unsigned long *in_frames = discontig_frames, *out_frames = limited_frames;
+	unsigned long  flags;
+	struct page *page;
+	int success;
+	int i, n = 0;
+	unsigned long _limit_map;
+	unsigned long *limit_map;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	if (unlikely(order > MAX_CONTIG_ORDER))
+		return -ENOMEM;
+
+	if (BITS_PER_LONG >> order) {
+		limit_map = kzalloc(BITS_TO_LONGS(1U << order) *
+				    sizeof(*limit_map), GFP_KERNEL);
+		if (unlikely(!limit_map))
+			return -ENOMEM;
+	} else
+		limit_map = &_limit_map;
+
+	/* 0. Construct our per page bitmap lookup. */
+
+	if (address_bits && (address_bits < PAGE_SHIFT))
+			return -EINVAL;
+
+	if (order)
+		bitmap_zero(limit_map, 1U << order);
+	else
+		__set_bit(0, limit_map);
+
+	/* 1. Clear the pages */
+	for (i = 0; i < 1ULL << order; i++) {
+		void *vaddr;
+		page = &pages[i];
+		vaddr = page_address(page);
+		if (address_bits) {
+			if (!pfn_to_mfn(virt_to_mfn(vaddr)) >> (address_bits - PAGE_SHIFT))
+				continue;
+			__set_bit(i, limit_map);
+		}
+		if (!PageHighMem(page))
+			memset(vaddr, 0, PAGE_SIZE);
+		else {
+			memset(kmap(page), 0, PAGE_SIZE);
+			kunmap(page);
+			++n;
+		}
+	}
+	/* Check to see if we actually have to do any work. */
+	if (bitmap_empty(limit_map, 1U << order)) {
+		if (limit_map != &_limit_map)
+			kfree(limit_map);
+		return 0;
+	}
+	if (n)
+		kmap_flush_unused();
+
+	spin_lock_irqsave(&xen_reservation_lock, flags);
+
+	/* 2. Zap current PTEs. */
+	n = xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, limit_map);
+
+	/* 3. Do the exchange for non-contiguous MFNs. */
+	success = xen_exchange_memory(n, 0, in_frames,
+				      n, 0, out_frames, address_bits);
+
+	/* 4. Map new pages in place of old pages. */
+	if (success)
+		xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+	else
+		xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+	spin_unlock_irqrestore(&xen_reservation_lock, flags);
+	if (limit_map != &_limit_map)
+		kfree(limit_map);
+
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
 #ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_exit_mmap(struct mm_struct *mm)
 {
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 03c85d7..ae5b1ef 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -28,4 +28,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 
+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+			       unsigned int address_bits);
 #endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 27be2f0..4fa2066 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 
+#include <xen/xen.h>
+#include <xen/xen-ops.h>
 /*** Page table manipulation functions ***/
 
 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end)
@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
+	if (xen_pv_domain()) {
+		if (dma_mask == (__GFP_DMA | __GFP_DMA32))
+			gfp_mask &= (__GFP_DMA | __GFP_DMA32);
+	}
 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
 	array_size = (nr_pages * sizeof(struct page *));
 
@@ -1586,6 +1592,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 			goto fail;
 		}
 		area->pages[i] = page;
+		if (xen_pv_domain()) {
+			if (dma_mask) {
+				if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+					area->nr_pages = i + 1;
+					goto fail;
+				}
+			if (gfp_mask & __GFP_ZERO)
+				clear_highpage(page);
+			}
+		}
 	}
 
 	if (map_vm_area(area, prot, &pages))

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--LZvS9be/3tNcYl/X--


From xen-devel-bounces@lists.xensource.com Wed Feb 15 20:12:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 20: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.xensource.com>)
	id 1RxlCk-0004IF-3d; Wed, 15 Feb 2012 20:11: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 1RxlCi-0004I4-0p
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 20:11:52 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329336657!63012345!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NTUwMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21042 invoked from network); 15 Feb 2012 20:10:58 -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; 15 Feb 2012 20:10:58 -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 q1FKBd7f007279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 20:11: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
	q1FKBdDt015222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 20:11:39 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1FKBclP024581; Wed, 15 Feb 2012 14:11:38 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 12:11:38 -0800
Date: Wed, 15 Feb 2012 12:11:35 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120215121135.393a2efa@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1202151129570.7456@kaball-desktop>
References: <20120214185314.5546a24e@mantra.us.oracle.com>
	<alpine.DEB.2.00.1202151129570.7456@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020202.4F3C117D.00FB,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] HYBRID: memory mapped IO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 15 Feb 2012 11:49:59 +0000
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> In this case QEMU calls xc_domain_memory_mapping, that in Xen becomes
> XEN_DOMCTL_memory_mapping, that is implemented as set_mmio_p2m_entry.
> So maybe you just need to call set_mmio_p2m_entry.

Exactly what I was looking for. I knew I had seen that somewhere :)... 

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 20:12:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 20: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.xensource.com>)
	id 1RxlCk-0004IF-3d; Wed, 15 Feb 2012 20:11: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 1RxlCi-0004I4-0p
	for Xen-devel@lists.xensource.com; Wed, 15 Feb 2012 20:11:52 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329336657!63012345!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NTUwMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21042 invoked from network); 15 Feb 2012 20:10:58 -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; 15 Feb 2012 20:10:58 -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 q1FKBd7f007279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 20:11: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
	q1FKBdDt015222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 20:11:39 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1FKBclP024581; Wed, 15 Feb 2012 14:11:38 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 12:11:38 -0800
Date: Wed, 15 Feb 2012 12:11:35 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120215121135.393a2efa@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1202151129570.7456@kaball-desktop>
References: <20120214185314.5546a24e@mantra.us.oracle.com>
	<alpine.DEB.2.00.1202151129570.7456@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020202.4F3C117D.00FB,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] HYBRID: memory mapped IO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 15 Feb 2012 11:49:59 +0000
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> In this case QEMU calls xc_domain_memory_mapping, that in Xen becomes
> XEN_DOMCTL_memory_mapping, that is implemented as set_mmio_p2m_entry.
> So maybe you just need to call set_mmio_p2m_entry.

Exactly what I was looking for. I knew I had seen that somewhere :)... 

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 22:47:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 22: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.xensource.com>)
	id 1Rxnbx-0008Iu-EY; Wed, 15 Feb 2012 22:46:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rxnbw-0008Io-7u
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 22:46:04 +0000
Received: from [85.158.139.83:30560] by server-2.bemta-5.messagelabs.com id
	CF/BF-20263-BA53C3F4; Wed, 15 Feb 2012 22:46:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329345961!15190896!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NTUwMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21424 invoked from network); 15 Feb 2012 22:46:02 -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; 15 Feb 2012 22:46:02 -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 q1FMjvE4013777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 22:45:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1FMjvl1008772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 22:45:57 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
	q1FMjuEx028812; Wed, 15 Feb 2012 16:45:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 14:45:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B149741FD4; Wed, 15 Feb 2012 17:42:53 -0500 (EST)
Date: Wed, 15 Feb 2012 17:42:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120215224253.GA18762@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F3C35A8.003B,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

It also needs this:

>From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 15 Feb 2012 17:39:46 -0500
Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
 built for it.

Otherwise we end up:

BUG: unable to handle kernel paging request at ffff88004000c0c8
IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
PGD 1806063 PUD 0
22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
00 [#1] SMP
CPU 0
Modules linked in:

Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
.. snip.
Call Trace:
 [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
 [<ffffffff810f4eab>] __free_pages+0x1b/0x40
 [<ffffffff810f4f1a>] free_pages+0x4a/0x60
 [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
 [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
 [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
 [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
 [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/net/xen-netfront.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0223552..1eadd90 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -29,6 +29,8 @@
  * IN THE SOFTWARE.
  */
 
+#define DEBUG 1
+
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/netdevice.h>
@@ -66,7 +68,7 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define XENNET_MAX_RING_PAGE_ORDER 2
+#define XENNET_MAX_RING_PAGE_ORDER 4
 #define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
 
 #define NET_TX_RING_SIZE(_nr_pages)					\
@@ -1611,6 +1613,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		info->tx_ring_page_order = 0;
 		dev_info(&dev->dev, "single tx ring\n");
 	} else {
+		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
+				max_tx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
+			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
 		info->tx_ring_page_order = max_tx_ring_page_order;
 		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
 			 max_tx_ring_page_order);
@@ -1642,6 +1649,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		dev_info(&dev->dev, "single rx ring\n");
 	} else {
 		info->rx_ring_page_order = max_rx_ring_page_order;
+		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
+				max_rx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
+			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
 		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
 			 max_rx_ring_page_order);
 	}
-- 
1.7.9.48.g85da4d

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 22:47:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 22: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.xensource.com>)
	id 1Rxnbx-0008Iu-EY; Wed, 15 Feb 2012 22:46:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rxnbw-0008Io-7u
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 22:46:04 +0000
Received: from [85.158.139.83:30560] by server-2.bemta-5.messagelabs.com id
	CF/BF-20263-BA53C3F4; Wed, 15 Feb 2012 22:46:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329345961!15190896!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NTUwMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21424 invoked from network); 15 Feb 2012 22:46:02 -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; 15 Feb 2012 22:46:02 -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 q1FMjvE4013777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 22:45:59 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1FMjvl1008772
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 22:45:57 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
	q1FMjuEx028812; Wed, 15 Feb 2012 16:45:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 14:45:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B149741FD4; Wed, 15 Feb 2012 17:42:53 -0500 (EST)
Date: Wed, 15 Feb 2012 17:42:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120215224253.GA18762@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F3C35A8.003B,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

It also needs this:

>From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 15 Feb 2012 17:39:46 -0500
Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
 built for it.

Otherwise we end up:

BUG: unable to handle kernel paging request at ffff88004000c0c8
IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
PGD 1806063 PUD 0
22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
00 [#1] SMP
CPU 0
Modules linked in:

Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
.. snip.
Call Trace:
 [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
 [<ffffffff810f4eab>] __free_pages+0x1b/0x40
 [<ffffffff810f4f1a>] free_pages+0x4a/0x60
 [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
 [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
 [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
 [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
 [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/net/xen-netfront.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0223552..1eadd90 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -29,6 +29,8 @@
  * IN THE SOFTWARE.
  */
 
+#define DEBUG 1
+
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/netdevice.h>
@@ -66,7 +68,7 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define XENNET_MAX_RING_PAGE_ORDER 2
+#define XENNET_MAX_RING_PAGE_ORDER 4
 #define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
 
 #define NET_TX_RING_SIZE(_nr_pages)					\
@@ -1611,6 +1613,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		info->tx_ring_page_order = 0;
 		dev_info(&dev->dev, "single tx ring\n");
 	} else {
+		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
+				max_tx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
+			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
 		info->tx_ring_page_order = max_tx_ring_page_order;
 		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
 			 max_tx_ring_page_order);
@@ -1642,6 +1649,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		dev_info(&dev->dev, "single rx ring\n");
 	} else {
 		info->rx_ring_page_order = max_rx_ring_page_order;
+		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
+				max_rx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
+			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
 		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
 			 max_rx_ring_page_order);
 	}
-- 
1.7.9.48.g85da4d

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 22:52:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 22:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxni4-0000DZ-Ea; Wed, 15 Feb 2012 22:52:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Rxni3-0000DS-5p
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 22:52:23 +0000
Received: from [193.109.254.147:10149] by server-4.bemta-14.messagelabs.com id
	30/59-08205-6273C3F4; Wed, 15 Feb 2012 22:52:22 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329346288!52924205!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4220 invoked from network); 15 Feb 2012 22:51:29 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 22:51:29 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id q1FMqDEE030751
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 15 Feb 2012 14:52:16 -0800
Date: Wed, 15 Feb 2012 17:52:12 -0500 (EST)
Message-Id: <20120215.175212.1236819573371947275.davem@davemloft.net>
To: konrad.wilk@oracle.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <20120215224253.GA18762@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Wed, 15 Feb 2012 14:52:16 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 15 Feb 2012 17:42:53 -0500

> @@ -29,6 +29,8 @@
>   * IN THE SOFTWARE.
>   */
>  
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/netdevice.h>

This is never appropriate.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 22:52:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 22:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxni4-0000DZ-Ea; Wed, 15 Feb 2012 22:52:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1Rxni3-0000DS-5p
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 22:52:23 +0000
Received: from [193.109.254.147:10149] by server-4.bemta-14.messagelabs.com id
	30/59-08205-6273C3F4; Wed, 15 Feb 2012 22:52:22 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329346288!52924205!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4220 invoked from network); 15 Feb 2012 22:51:29 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 22:51:29 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id q1FMqDEE030751
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 15 Feb 2012 14:52:16 -0800
Date: Wed, 15 Feb 2012 17:52:12 -0500 (EST)
Message-Id: <20120215.175212.1236819573371947275.davem@davemloft.net>
To: konrad.wilk@oracle.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <20120215224253.GA18762@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Wed, 15 Feb 2012 14:52:16 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 15 Feb 2012 17:42:53 -0500

> @@ -29,6 +29,8 @@
>   * IN THE SOFTWARE.
>   */
>  
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/netdevice.h>

This is never appropriate.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 23:04:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 23:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxntB-0000iM-DJ; Wed, 15 Feb 2012 23:03:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxntA-0000i4-0y
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 23:03:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329347025!13518322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9844 invoked from network); 15 Feb 2012 23:03:45 -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;
	15 Feb 2012 23:03:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,425,1325462400"; d="scan'208";a="10728495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 23:03:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 23:03:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rxnt2-0004Wf-IL;
	Wed, 15 Feb 2012 23:03:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rxnt2-0000mt-9o;
	Wed, 15 Feb 2012 23:03:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11965-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 23:03:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11965: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11965 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11965/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fe427d3bb378
baseline version:
 xen                  618cbd27bac0

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  keir@xen.org
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=fe427d3bb378
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 fe427d3bb378
+ branch=xen-unstable
+ revision=fe427d3bb378
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r fe427d3bb378 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 13 changesets with 29 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 23:04:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 23:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxntB-0000iM-DJ; Wed, 15 Feb 2012 23:03:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxntA-0000i4-0y
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 23:03:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329347025!13518322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTk5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9844 invoked from network); 15 Feb 2012 23:03:45 -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;
	15 Feb 2012 23:03:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,425,1325462400"; d="scan'208";a="10728495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2012 23:03:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 15 Feb 2012 23:03:44 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rxnt2-0004Wf-IL;
	Wed, 15 Feb 2012 23:03:44 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rxnt2-0000mt-9o;
	Wed, 15 Feb 2012 23:03:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11965-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 15 Feb 2012 23:03:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11965: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11965 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11965/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fe427d3bb378
baseline version:
 xen                  618cbd27bac0

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  keir@xen.org
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=fe427d3bb378
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 fe427d3bb378
+ branch=xen-unstable
+ revision=fe427d3bb378
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r fe427d3bb378 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 13 changesets with 29 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 23:57:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 23: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.xensource.com>)
	id 1RxoiP-00027S-PF; Wed, 15 Feb 2012 23:56: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 1RxoiO-00027N-2v
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 23:56:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329350148!56887966!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NjY3MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31457 invoked from network); 15 Feb 2012 23:55:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 23:55:49 -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 q1FNuePo000645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 23:56:42 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
	q1FNudl7013374
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 23:56:40 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
	q1FNudXZ003470; Wed, 15 Feb 2012 17:56:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 15:56:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B3C7741FD4; Wed, 15 Feb 2012 18:53:35 -0500 (EST)
Date: Wed, 15 Feb 2012 18:53:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Miller <davem@davemloft.net>
Message-ID: <20120215235335.GA8440@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<20120215.175212.1236819573371947275.davem@davemloft.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120215.175212.1236819573371947275.davem@davemloft.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F3C463A.0033,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 15, 2012 at 05:52:12PM -0500, David Miller wrote:
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 15 Feb 2012 17:42:53 -0500
> 
> > @@ -29,6 +29,8 @@
> >   * IN THE SOFTWARE.
> >   */
> >  
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/kernel.h>
> >  #include <linux/netdevice.h>
> 
> This is never appropriate.

HA! No it is not. Thanks for spotting it.

I was thinking that Liu would actually squash the fix the patch I responded to.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Feb 15 23:57:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 15 Feb 2012 23: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.xensource.com>)
	id 1RxoiP-00027S-PF; Wed, 15 Feb 2012 23:56: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 1RxoiO-00027N-2v
	for xen-devel@lists.xensource.com; Wed, 15 Feb 2012 23:56:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329350148!56887966!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0NjY3MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31457 invoked from network); 15 Feb 2012 23:55:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2012 23:55:49 -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 q1FNuePo000645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 15 Feb 2012 23:56:42 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
	q1FNudl7013374
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Feb 2012 23:56:40 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
	q1FNudXZ003470; Wed, 15 Feb 2012 17:56:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 15 Feb 2012 15:56:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B3C7741FD4; Wed, 15 Feb 2012 18:53:35 -0500 (EST)
Date: Wed, 15 Feb 2012 18:53:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Miller <davem@davemloft.net>
Message-ID: <20120215235335.GA8440@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<20120215.175212.1236819573371947275.davem@davemloft.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120215.175212.1236819573371947275.davem@davemloft.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F3C463A.0033,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 15, 2012 at 05:52:12PM -0500, David Miller wrote:
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 15 Feb 2012 17:42:53 -0500
> 
> > @@ -29,6 +29,8 @@
> >   * IN THE SOFTWARE.
> >   */
> >  
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/kernel.h>
> >  #include <linux/netdevice.h>
> 
> This is never appropriate.

HA! No it is not. Thanks for spotting it.

I was thinking that Liu would actually squash the fix the patch I responded to.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 01:03:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 01:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxpkb-0006l4-Vj; Thu, 16 Feb 2012 01:03:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Rxpka-0006kv-Ql
	for Xen-devel@lists.xensource.com; Thu, 16 Feb 2012 01:03:09 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329354182!15061092!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA4OTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 606 invoked from network); 16 Feb 2012 01:03:02 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 01:03:02 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1G11xDx010673;
	Thu, 16 Feb 2012 01:02:03 GMT
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1G11hjS001923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 16 Feb 2012 01:01:43 GMT
Received: from vega-a.dur.ac.uk (localhost [127.0.0.1])
	by vega-a.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q1G11hZO027451;
	Thu, 16 Feb 2012 01:01:43 GMT
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q1G11fMf027445;
	Thu, 16 Feb 2012 01:01:42 GMT
Date: Thu, 16 Feb 2012 01:01:41 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
Message-ID: <alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
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: q1G11xDx010673
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] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, M A Young wrote:

> On Tue, 14 Feb 2012, Konrad Rzeszutek Wilk wrote:
>
>> On Mon, Feb 13, 2012 at 02:12:08PM +0000, M A Young wrote:
>>> On Mon, 13 Feb 2012, Ian Campbell wrote:
>>> 
>>>> On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
>>>>> I get the backtrace below if I try to boot a PV guest running F17 Alpha
>>>>> TC2 in graphical mode. Is this a known problem?
>>>> 
>>>> It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
>>>> the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
>>>> got to the bottom of the root cause though.
>>>> 
>>>> That occasion was a suspend/resume thing so perhaps not really related
>>>> but it seems fishily similar.
>>>> 
>>>> I've not looked at the code recently but it seems that back then I was
>>>> of the opinion that info->update_wanted == 0 must remain true until the
>>>> irq etc was all fully setup, that might be relevant now?
>>> 
>>> Yes, it does sound fishily similar. I didn't mention that it does work if
>>> I do a text boot and then switch to a graphical runlevel, so it could be
>> 
>> So how does F17 do it now? Is all in the graphical mode (KMS?) and it never
>> tries to hit text mode (so plymouth is on by default?)
>
> I was probably wrong about that. It was a separate non-kernel bug that was 
> stopping me getting a direct graphical boot. As the backtrace happens some 
> time but not others I am not longer convinced about the graphical vs text 
> boot link. The backtrace occurs before the line
> Feb 14 20:26:31 localhost kernel: [    2.611366] Console: switching to colour 
> frame buffer device 100x37
> so it seems to be when the frame buffer first launches.
>
>>> somthing happening in the wrong order, such as the framebuffer starting
>>> before the irq is properly set up.
>> 
>> Hm, could you instrument xen-fbfront.c and see what the flow is during
>> bootup and compare that when running it under F16? That might shed some
>> light on this.
>
> I will have a look at what useful debugging I can put into xen-fbfront.c - it 
> might be hard for me to compare it with F16 but the comparsion between a 
> backtrace and non-backtrace boot might be useful.

My first debugging attempt gives the values
update_wanted=0 in_cons=0 in_prod=1 width=800 height=600
just before the crash occurs. I am not sure how useful this is.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 01:03:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 01:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxpkb-0006l4-Vj; Thu, 16 Feb 2012 01:03:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1Rxpka-0006kv-Ql
	for Xen-devel@lists.xensource.com; Thu, 16 Feb 2012 01:03:09 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329354182!15061092!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiA4OTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 606 invoked from network); 16 Feb 2012 01:03:02 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 01:03:02 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1G11xDx010673;
	Thu, 16 Feb 2012 01:02:03 GMT
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q1G11hjS001923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 16 Feb 2012 01:01:43 GMT
Received: from vega-a.dur.ac.uk (localhost [127.0.0.1])
	by vega-a.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q1G11hZO027451;
	Thu, 16 Feb 2012 01:01:43 GMT
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q1G11fMf027445;
	Thu, 16 Feb 2012 01:01:42 GMT
Date: Thu, 16 Feb 2012 01:01:41 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
Message-ID: <alpine.DEB.2.00.1202160059130.26469@vega-a.dur.ac.uk>
References: <alpine.DEB.2.00.1202122128450.2225@vega-b.dur.ac.uk>
	<1329137635.31256.100.camel@zakaz.uk.xensource.com>
	<alpine.GSO.2.00.1202131404031.24105@algedi.dur.ac.uk>
	<20120214140020.GB21610@andromeda.dapyr.net>
	<alpine.DEB.2.00.1202142119220.1237@vega-c.dur.ac.uk>
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: q1G11xDx010673
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] irq problem with 3.3-rc3 on guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 14 Feb 2012, M A Young wrote:

> On Tue, 14 Feb 2012, Konrad Rzeszutek Wilk wrote:
>
>> On Mon, Feb 13, 2012 at 02:12:08PM +0000, M A Young wrote:
>>> On Mon, 13 Feb 2012, Ian Campbell wrote:
>>> 
>>>> On Sun, 2012-02-12 at 21:33 +0000, M A Young wrote:
>>>>> I get the backtrace below if I try to boot a PV guest running F17 Alpha
>>>>> TC2 in graphical mode. Is this a known problem?
>>>> 
>>>> It came up last year https://lkml.org/lkml/2011/1/6/19 which resulted in
>>>> the WARN_ON you saw instead of a kernel crash. I'm not sure if anyone
>>>> got to the bottom of the root cause though.
>>>> 
>>>> That occasion was a suspend/resume thing so perhaps not really related
>>>> but it seems fishily similar.
>>>> 
>>>> I've not looked at the code recently but it seems that back then I was
>>>> of the opinion that info->update_wanted == 0 must remain true until the
>>>> irq etc was all fully setup, that might be relevant now?
>>> 
>>> Yes, it does sound fishily similar. I didn't mention that it does work if
>>> I do a text boot and then switch to a graphical runlevel, so it could be
>> 
>> So how does F17 do it now? Is all in the graphical mode (KMS?) and it never
>> tries to hit text mode (so plymouth is on by default?)
>
> I was probably wrong about that. It was a separate non-kernel bug that was 
> stopping me getting a direct graphical boot. As the backtrace happens some 
> time but not others I am not longer convinced about the graphical vs text 
> boot link. The backtrace occurs before the line
> Feb 14 20:26:31 localhost kernel: [    2.611366] Console: switching to colour 
> frame buffer device 100x37
> so it seems to be when the frame buffer first launches.
>
>>> somthing happening in the wrong order, such as the framebuffer starting
>>> before the irq is properly set up.
>> 
>> Hm, could you instrument xen-fbfront.c and see what the flow is during
>> bootup and compare that when running it under F16? That might shed some
>> light on this.
>
> I will have a look at what useful debugging I can put into xen-fbfront.c - it 
> might be hard for me to compare it with F16 but the comparsion between a 
> backtrace and non-backtrace boot might be useful.

My first debugging attempt gives the values
update_wanted=0 in_cons=0 in_prod=1 width=800 height=600
just before the crash occurs. I am not sure how useful this is.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 01:23:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 01: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.xensource.com>)
	id 1Rxq3j-00073M-TQ; Thu, 16 Feb 2012 01:22:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1Rxq3h-00073D-VV
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 01:22:54 +0000
Received: from [85.158.139.83:52640] by server-2.bemta-5.messagelabs.com id
	58/2A-20263-D6A5C3F4; Thu, 16 Feb 2012 01:22:53 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329355371!15251584!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22030 invoked from network); 16 Feb 2012 01:22:52 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 01:22:52 -0000
Received: by ghbf1 with SMTP id f1so19628502ghb.30
	for <multiple recipients>; Wed, 15 Feb 2012 17:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=2i/DvMxyR0CsqFNPqjLPTG5J+M1JKoNp0rsxWqPXiUs=;
	b=GxjXUNxMIWvcAznVh6k4DHsA+5J6VDLYxhWO2gnxYzic5VfvgnbOlcZqGGEXXdok7X
	Fk7d00V1vo+PvvDV90Og8K4EcfZl14oEZjLLMHpa86kTKcXHsLLKpyXaxJ2/L1SGQg+U
	Zjcc4DdM8rljDHPbKo5D+N8574MPRB6KzbX50=
Received: by 10.236.72.195 with SMTP id t43mr422717yhd.126.1329355370596; Wed,
	15 Feb 2012 17:22:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.179.9 with HTTP; Wed, 15 Feb 2012 17:22:30 -0800 (PST)
In-Reply-To: <CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<201202140907.44528.hahn@univention.de>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Wed, 15 Feb 2012 17:22:30 -0800
Message-ID: <CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
To: Philipp Hahn <hahn@univention.de>, xen-users@lists.xensource.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgMTA6MDcgQU0sIEVyaWMgQ2FtYWNoYXQgPGVyaWMuY2Ft
YWNoYXRAZ21haWwuY29tPiB3cm90ZToKPiBPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxMjowNyBB
TSwgUGhpbGlwcCBIYWhuIDxoYWhuQHVuaXZlbnRpb24uZGU+IHdyb3RlOgo+PiBIZWxsbywKPj4K
Pj4gT24gVHVlc2RheSAxNCBGZWJydWFyeSAyMDEyIDAyOjA5OjM3IEVyaWMgQ2FtYWNoYXQgd3Jv
dGU6Cj4+PiBJIGZvbGxvd2VkIHhlbi00LjEuMi9kb2NzL21pc2Mva2V4ZWNfYW5kX2tkdW1wLnR4
dCwgYnV0IEkgY2Fubm90IHNlZQo+Pj4gIkNyYXNoIGtlcm5lbCIgaW4gL2Rldi9pb21lbS4KPj4+
IElzIHRoaXMgYSBrbm93biBpc3N1ZT8KPj4KPj4gQXMgZmFyIGFzIEkga25vdyBjcmFzaGR1bXAg
b25seSB3b3JrcyB3aXRoIGEgbm9uLXB2LW9wcy1kb20wLWtlcm5lbHMgKDIuNi4xOAo+PiBvciAy
LjYuMjYpLCBidXQgbm90IHdpdGggdGhlIG5ld2VyIHB2LW9wcy1zb20wLWtlcm5lbHMuIFRoYXRz
IHRoZSBpbXBvcnRhbnQKPj4gaW5mb3JtYXRpb24gbWlzc2luZyBpbiBhbGwgdGhvc2UgZG9jdW1l
bnRhdGlvbnMgSSByZWFkLCBpbmNsdWRpbmcgdGhhdCBmaWxlCj4+IHlvdSBtZW50aW9uZWQgYWJv
dmUuCj4+Cj4KPiBUaGFua3MgZm9yIHlvdXIgaW5mb3JtYXRpb24hCj4gSXQncyB0cnVlLCBubyB3
aGVyZSBtZW50aW9uZWQgdGhhdCBldmVuIHhlbi9kb2NzLgo+Cj4gRXJpYwoKVHJ5IHRvIHVzZSBI
WVBFUlZJU09SX2tleGVjX29wKCkgdG8gZmluZCBvdXQgd2hlcmUgY3Jhc2ggYnVmZmVyIGlzLgpC
dXQgaXQgcmV0dXJuZWQgYWRkcmVzcyB0aGF0IG91dHNpZGUgb2YgdG90YWwgbWVtb3J5IQoKVGVz
dCBiZWQ6Clhlbi00LjEuMiwgTGludXgtMi42LjMyLjI0LCB4ODZfNjQKClRlc3QgcmVzdWx0Ogpm
b3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAwMDAwZmY3ODBdIGZmNzgwCkZvdW5kIDEyOE1C
IG9mIG1lbW9yeSBhdCA5MDY5TUIgZm9yIGNyYXNoa2VybmVsIChTeXN0ZW0gUkFNOiA3ODAyTUIp
CkZvdW5kIDFNQiBvZiBtZW1vcnkgYXQgMzAyN01CIG9mIFhFTiBoeXBlcnZpc29yIChOQ1BVUyA9
IDQvNCkuCkZvdW5kIDBNQiBvZiB2bWNvcmUgYXQgMzAyOE1CIG9mIFhFTiBoeXBlcnZpc29yLgpa
b25lIFBGTiByYW5nZXM6CgpNeSBjb2RlOgp4ZW5fa2V4ZWNfcmFuZ2VfdCByYW5nZTsKeGVuX3Bs
YXRmb3JtX29wX3Qgb3A7CnN0cnVjdCByZXNvdXJjZSAqcmVzOwp1bnNpZ25lZCBpbnQgayA9IDAs
IG5yID0gMDsKaW50IHJjOwoKaWYgKHhlbl9zdGFydF9pbmZvLT5mbGFncyAmIFNJRl9JTklURE9N
QUlOKSB7CsKgIMKgLyogZmlsbCBpbiBjcmFzaGtfcmVzIGlmIHJhbmdlIGlzIHJlc2VydmVkIGJ5
IGh5cGVydmlzb3IgKi8KwqAgwqBtZW1zZXQoJnJhbmdlLCAwLCBzaXplb2YocmFuZ2UpKTsKwqAg
wqByYW5nZS5yYW5nZSA9IEtFWEVDX1JBTkdFX01BX0NSQVNIOwoKwqAgwqBpZiAoSFlQRVJWSVNP
Ul9rZXhlY19vcChLRVhFQ19DTURfa2V4ZWNfZ2V0X3JhbmdlLCAmcmFuZ2UpCsKgIMKgIMKgIMKg
fHwgIXJhbmdlLnNpemUpIHsKwqAgwqAgwqAgwqBwcmludGsoS0VSTl9JTkZPICJObyBDUkFTSCBy
YW5nZSFcbiIpOwrCoCDCoHJldHVybjsKfQoKwqAgwqBjcmFzaGtfcmVzLnN0YXJ0ID0gcmFuZ2Uu
c3RhcnQ7CsKgIMKgY3Jhc2hrX3Jlcy5lbmQgwqAgPSByYW5nZS5zdGFydCArIHJhbmdlLnNpemUg
LSAxOwoKwqAgwqBwcmludGsoS0VSTl9JTkZPICJGb3VuZCAlbGRNQiBvZiBtZW1vcnkgYXQgJWxk
TUIgIgrCoCDCoCJmb3IgY3Jhc2hrZXJuZWwgKFN5c3RlbSBSQU06ICVsZE1CKVxuIiwKwqAgwqAo
dW5zaWduZWQgbG9uZykocmFuZ2Uuc2l6ZSA+PiAyMCksCsKgIMKgKHVuc2lnbmVkIGxvbmcpKHJh
bmdlLnN0YXJ0ID4+IDIwKSwKwqAgwqAodW5zaWduZWQgbG9uZykoZ2V0X3RvdGFsX21lbSgpID4+
IDIwKSk7CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 16 01:23:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 01: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.xensource.com>)
	id 1Rxq3j-00073M-TQ; Thu, 16 Feb 2012 01:22:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1Rxq3h-00073D-VV
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 01:22:54 +0000
Received: from [85.158.139.83:52640] by server-2.bemta-5.messagelabs.com id
	58/2A-20263-D6A5C3F4; Thu, 16 Feb 2012 01:22:53 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329355371!15251584!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22030 invoked from network); 16 Feb 2012 01:22:52 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 01:22:52 -0000
Received: by ghbf1 with SMTP id f1so19628502ghb.30
	for <multiple recipients>; Wed, 15 Feb 2012 17:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=2i/DvMxyR0CsqFNPqjLPTG5J+M1JKoNp0rsxWqPXiUs=;
	b=GxjXUNxMIWvcAznVh6k4DHsA+5J6VDLYxhWO2gnxYzic5VfvgnbOlcZqGGEXXdok7X
	Fk7d00V1vo+PvvDV90Og8K4EcfZl14oEZjLLMHpa86kTKcXHsLLKpyXaxJ2/L1SGQg+U
	Zjcc4DdM8rljDHPbKo5D+N8574MPRB6KzbX50=
Received: by 10.236.72.195 with SMTP id t43mr422717yhd.126.1329355370596; Wed,
	15 Feb 2012 17:22:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.179.9 with HTTP; Wed, 15 Feb 2012 17:22:30 -0800 (PST)
In-Reply-To: <CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<201202140907.44528.hahn@univention.de>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Wed, 15 Feb 2012 17:22:30 -0800
Message-ID: <CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
To: Philipp Hahn <hahn@univention.de>, xen-users@lists.xensource.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgMTA6MDcgQU0sIEVyaWMgQ2FtYWNoYXQgPGVyaWMuY2Ft
YWNoYXRAZ21haWwuY29tPiB3cm90ZToKPiBPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxMjowNyBB
TSwgUGhpbGlwcCBIYWhuIDxoYWhuQHVuaXZlbnRpb24uZGU+IHdyb3RlOgo+PiBIZWxsbywKPj4K
Pj4gT24gVHVlc2RheSAxNCBGZWJydWFyeSAyMDEyIDAyOjA5OjM3IEVyaWMgQ2FtYWNoYXQgd3Jv
dGU6Cj4+PiBJIGZvbGxvd2VkIHhlbi00LjEuMi9kb2NzL21pc2Mva2V4ZWNfYW5kX2tkdW1wLnR4
dCwgYnV0IEkgY2Fubm90IHNlZQo+Pj4gIkNyYXNoIGtlcm5lbCIgaW4gL2Rldi9pb21lbS4KPj4+
IElzIHRoaXMgYSBrbm93biBpc3N1ZT8KPj4KPj4gQXMgZmFyIGFzIEkga25vdyBjcmFzaGR1bXAg
b25seSB3b3JrcyB3aXRoIGEgbm9uLXB2LW9wcy1kb20wLWtlcm5lbHMgKDIuNi4xOAo+PiBvciAy
LjYuMjYpLCBidXQgbm90IHdpdGggdGhlIG5ld2VyIHB2LW9wcy1zb20wLWtlcm5lbHMuIFRoYXRz
IHRoZSBpbXBvcnRhbnQKPj4gaW5mb3JtYXRpb24gbWlzc2luZyBpbiBhbGwgdGhvc2UgZG9jdW1l
bnRhdGlvbnMgSSByZWFkLCBpbmNsdWRpbmcgdGhhdCBmaWxlCj4+IHlvdSBtZW50aW9uZWQgYWJv
dmUuCj4+Cj4KPiBUaGFua3MgZm9yIHlvdXIgaW5mb3JtYXRpb24hCj4gSXQncyB0cnVlLCBubyB3
aGVyZSBtZW50aW9uZWQgdGhhdCBldmVuIHhlbi9kb2NzLgo+Cj4gRXJpYwoKVHJ5IHRvIHVzZSBI
WVBFUlZJU09SX2tleGVjX29wKCkgdG8gZmluZCBvdXQgd2hlcmUgY3Jhc2ggYnVmZmVyIGlzLgpC
dXQgaXQgcmV0dXJuZWQgYWRkcmVzcyB0aGF0IG91dHNpZGUgb2YgdG90YWwgbWVtb3J5IQoKVGVz
dCBiZWQ6Clhlbi00LjEuMiwgTGludXgtMi42LjMyLjI0LCB4ODZfNjQKClRlc3QgcmVzdWx0Ogpm
b3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAwMDAwZmY3ODBdIGZmNzgwCkZvdW5kIDEyOE1C
IG9mIG1lbW9yeSBhdCA5MDY5TUIgZm9yIGNyYXNoa2VybmVsIChTeXN0ZW0gUkFNOiA3ODAyTUIp
CkZvdW5kIDFNQiBvZiBtZW1vcnkgYXQgMzAyN01CIG9mIFhFTiBoeXBlcnZpc29yIChOQ1BVUyA9
IDQvNCkuCkZvdW5kIDBNQiBvZiB2bWNvcmUgYXQgMzAyOE1CIG9mIFhFTiBoeXBlcnZpc29yLgpa
b25lIFBGTiByYW5nZXM6CgpNeSBjb2RlOgp4ZW5fa2V4ZWNfcmFuZ2VfdCByYW5nZTsKeGVuX3Bs
YXRmb3JtX29wX3Qgb3A7CnN0cnVjdCByZXNvdXJjZSAqcmVzOwp1bnNpZ25lZCBpbnQgayA9IDAs
IG5yID0gMDsKaW50IHJjOwoKaWYgKHhlbl9zdGFydF9pbmZvLT5mbGFncyAmIFNJRl9JTklURE9N
QUlOKSB7CsKgIMKgLyogZmlsbCBpbiBjcmFzaGtfcmVzIGlmIHJhbmdlIGlzIHJlc2VydmVkIGJ5
IGh5cGVydmlzb3IgKi8KwqAgwqBtZW1zZXQoJnJhbmdlLCAwLCBzaXplb2YocmFuZ2UpKTsKwqAg
wqByYW5nZS5yYW5nZSA9IEtFWEVDX1JBTkdFX01BX0NSQVNIOwoKwqAgwqBpZiAoSFlQRVJWSVNP
Ul9rZXhlY19vcChLRVhFQ19DTURfa2V4ZWNfZ2V0X3JhbmdlLCAmcmFuZ2UpCsKgIMKgIMKgIMKg
fHwgIXJhbmdlLnNpemUpIHsKwqAgwqAgwqAgwqBwcmludGsoS0VSTl9JTkZPICJObyBDUkFTSCBy
YW5nZSFcbiIpOwrCoCDCoHJldHVybjsKfQoKwqAgwqBjcmFzaGtfcmVzLnN0YXJ0ID0gcmFuZ2Uu
c3RhcnQ7CsKgIMKgY3Jhc2hrX3Jlcy5lbmQgwqAgPSByYW5nZS5zdGFydCArIHJhbmdlLnNpemUg
LSAxOwoKwqAgwqBwcmludGsoS0VSTl9JTkZPICJGb3VuZCAlbGRNQiBvZiBtZW1vcnkgYXQgJWxk
TUIgIgrCoCDCoCJmb3IgY3Jhc2hrZXJuZWwgKFN5c3RlbSBSQU06ICVsZE1CKVxuIiwKwqAgwqAo
dW5zaWduZWQgbG9uZykocmFuZ2Uuc2l6ZSA+PiAyMCksCsKgIMKgKHVuc2lnbmVkIGxvbmcpKHJh
bmdlLnN0YXJ0ID4+IDIwKSwKwqAgwqAodW5zaWduZWQgbG9uZykoZ2V0X3RvdGFsX21lbSgpID4+
IDIwKSk7CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 16 02:33:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 02: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.xensource.com>)
	id 1Rxr9g-0000RX-B6; Thu, 16 Feb 2012 02:33:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rxr9f-0000RQ-Fn
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 02:33:07 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329359519!61276814!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMjYxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1804 invoked from network); 16 Feb 2012 02:32:00 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-2.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 02:32:00 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZG00BPBSCPUM@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:31:37 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZG00LZBSCP2F@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:31:37 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHD58128; Thu,
	16 Feb 2012 10:31:34 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159)
	by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 10:31:28 +0800
Received: from h00166998 (10.166.80.196) by szxeml420-hub.china.huawei.com
	(10.82.67.159) with Microsoft SMTP Server id 14.1.323.3; Thu,
	16 Feb 2012 10:31:23 +0800
Date: Thu, 16 Feb 2012 10:31:22 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
X-Originating-IP: [10.166.80.196]
To: andres@lagarcavilla.org, xen-devel@lists.xensource.com
Message-id: <000001ccec53$12f70100$38e50300$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczrTBY8d0cWPSj7TKKsXIgpkKalfgBASTQg
X-CFilter-Loop: Reflected
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
Cc: olaf@aepfle.de, hanweidong@huawei.com, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, keir.xen@gmail.com, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
> Sent: Wednesday, February 15, 2012 3:05 AM
> To: xen-devel@lists.xensource.com
> Cc: olaf@aepfle.de; keir.xen@gmail.com; tim@xen.org; JBeulich@suse.com; adin@gridcentric.ca
> Subject: [Xen-devel] RFC: AMD support for paging
> 
> We started hashing out some AMD support for mem_paging and mem_access.
> Right now my VMs boot, page out a bit, and then die on an HVM triple
> fault.
> 
> Most importantly, I want to get somebody from AMD to comment/help out on
> this. It feels like we're inches away from enabling support for this very
> nice feature. I'm not sure who exactly on AMD monitors the list for these
> kinds of things. It'd be great to have you on board!
> 
> For starters, the changes to the p2m code are relatively mild, but it'd be
> great if somebody spots a red flag.
> 
> Another issue: comments indicate that bits 59-62 in NPT entries are used
> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit (59)
> would give us enough space to support mem_access. Right now we only have 7
> bits available for Xen flags and that is not enough for paging and access.
> Is bit 59 effectively reserved?
> 
> Finally, the triple fault. Maybe I'm missing something obvious. Comments
> welcome.
> 
> Patch inline below, thanks!
> Andres
> 
> Enable AMD support for paging.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>              if ( !hap_enabled(d) )
>                  break;
> 
> -            /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> -                break;
> -
>              rc = -EXDEV;
>              /* Disallow paging in a PoD guest */
>              if ( p2m->pod.entry_count )
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -53,6 +53,20 @@
>  #define P2M_BASE_FLAGS \
>          (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
> 
> +#ifdef __x86_64__
> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
> + * value tramples over the higher-order bits used for flags (NX, p2mt,
> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> + * juggle for l1 entries only (no paging superpages!) */
> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> +#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
> +                                INVALID_MFN : (mfn))
> +#else
> +#define clipped_mfn(mfn)    (mfn)
> +#define unclip_mfn(mfn)     (mfn)
> +#endif /* __x86_64__ */
> +
>  static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>  {
>      unsigned long flags;
> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>      case p2m_invalid:
>      case p2m_mmio_dm:
>      case p2m_populate_on_demand:
> +    case p2m_ram_paging_out:
> +    case p2m_ram_paged:
> +    case p2m_ram_paging_in:
>      default:
>          return flags;
>      case p2m_ram_ro:
> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>                                        shift, max)) )
>          return 0;
> 
> -    /* PoD: Not present doesn't imply empty. */
> +    /* PoD/paging: Not present doesn't imply empty. */
>      if ( !l1e_get_flags(*p2m_entry) )
>      {
>          struct page_info *pg;
> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>                                     0, L1_PAGETABLE_ENTRIES);
>          ASSERT(p2m_entry);
> 
> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
> -            entry_content = l1e_from_pfn(mfn_x(mfn),
> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>                                           p2m_type_to_flags(p2mt, mfn));
>          else
>              entry_content = l1e_empty();
> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>          if ( entry_content.l1 != 0 )
>          {
>              p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
> -            old_mfn = l1e_get_pfn(*p2m_entry);
> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>          }
>          /* level 1 entry */
>          p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
> entry_content, 1);
> @@ -615,11 +633,12 @@ pod_retry_l1:
>                             sizeof(l1e));
> 
>      if ( ret == 0 ) {
> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>          p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
> +                (l1e_mfn == INVALID_MFN && p2m_is_paging(p2mt)) );
> 
> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
> -             == p2m_populate_on_demand )
> +        if ( p2mt == p2m_populate_on_demand )
>          {
>              /* The read has succeeded, so we know that the mapping
>               * exits at this point.  */
> @@ -641,7 +660,7 @@ pod_retry_l1:
>          }
> 
>          if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
> -            mfn = _mfn(l1e_get_pfn(l1e));
> +            mfn = _mfn(l1e_mfn);
>          else
>              /* XXX see above */
>              p2mt = p2m_mmio_dm;
> @@ -783,18 +802,26 @@ pod_retry_l2:
>  pod_retry_l1:
>      if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
>      {
> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>          /* PoD: Try to populate */
> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
> +        if ( l1t == p2m_populate_on_demand )
>          {
>              if ( q != p2m_query ) {
>                  if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
>                      goto pod_retry_l1;
>              } else
>                  *t = p2m_populate_on_demand;
> +        } else {
> +            if ( p2m_is_paging(l1t) )
> +            {
> +                *t = l1t;
> +                /* No need to unclip due to check below */
> +                mfn = _mfn(l1e_get_pfn(*l1e));
> +            }
>          }
> 
>          unmap_domain_page(l1e);
> -        return _mfn(INVALID_MFN);
> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                   This means when p2mt is p2m_ram_paging_in, the mfn must be INVALID_MFN;
                   But in p2m_type_to_flags,when p2m_ram_paging_in or  p2m_ram_paged, the _PAGE_PRESENT is not set.
 
My idea shows like this:
In p2m_gfn_to_mfn function:
@@ -1370,6 +1379,7 @@
     paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
     l2_pgentry_t *l2e;
     l1_pgentry_t *l1e;
+    unsigned long flags;
 
     ASSERT(paging_mode_translate(d));
 
@@ -1455,7 +1465,8 @@
     l1e = map_domain_page(mfn_x(mfn));
     l1e += l1_table_offset(addr);
 pod_retry_l1:
-    if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
+    flags = l1e_get_flags(*l1e);
+    if ((( flags & _PAGE_PRESENT) == 0) && (!p2m_is_paging(p2m_flags_to_type(flags))))
     {
         /* PoD: Try to populate */
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
        {
            if ( q != p2m_query ) {
                if ( !p2m_pod_check_and_populate(p2m, gfn,
                                                 (l1_pgentry_t *)l1e, PAGE_ORDER_4K, q) )
                    goto pod_retry_l1;
            } else
                *t = p2m_populate_on_demand;
        }
    
        unmap_domain_page(l1e);
        return _mfn(INVALID_MFN);
    }
    mfn = _mfn(l1e_get_pfn(*l1e));
    *t = p2m_flags_to_type(l1e_get_flags(*l1e));
    unmap_domain_page(l1e);




>      }
>      mfn = _mfn(l1e_get_pfn(*l1e));
>      *t = p2m_flags_to_type(l1e_get_flags(*l1e));
> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>                      flags = l1e_get_flags(l1e[i1]);
>                      if ( p2m_flags_to_type(flags) != ot )
>                          continue;
> -                    mfn = l1e_get_pfn(l1e[i1]);
> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                      gfn = i1 + (i2 + (i3
>  #if CONFIG_PAGING_LEVELS >= 4
>  					+ (i4 * L3_PAGETABLE_ENTRIES)
> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>                             * L2_PAGETABLE_ENTRIES) * L1_PAGETABLE_ENTRIES;
>                      /* create a new 1le entry with the new type */
>                      flags = p2m_type_to_flags(nt, _mfn(mfn));
> -                    l1e_content = l1e_from_pfn(mfn, flags);
> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn), flags);
>                      p2m->write_p2m_entry(p2m, gfn, &l1e[i1],
>                                           l1mfn, l1e_content, 1);
>                  }
> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>                                  entry_count++;
>                              continue;
>                          }
> -                        mfn = l1e_get_pfn(l1e[i1]);
> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                          ASSERT(mfn_valid(_mfn(mfn)));
>                          m2pfn = get_gpfn_from_mfn(mfn);
>                          if ( m2pfn != gfn &&
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 02:33:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 02: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.xensource.com>)
	id 1Rxr9g-0000RX-B6; Thu, 16 Feb 2012 02:33:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rxr9f-0000RQ-Fn
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 02:33:07 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329359519!61276814!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMjYxOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1804 invoked from network); 16 Feb 2012 02:32:00 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-2.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 02:32:00 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZG00BPBSCPUM@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:31:37 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZG00LZBSCP2F@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:31:37 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHD58128; Thu,
	16 Feb 2012 10:31:34 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159)
	by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 10:31:28 +0800
Received: from h00166998 (10.166.80.196) by szxeml420-hub.china.huawei.com
	(10.82.67.159) with Microsoft SMTP Server id 14.1.323.3; Thu,
	16 Feb 2012 10:31:23 +0800
Date: Thu, 16 Feb 2012 10:31:22 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
X-Originating-IP: [10.166.80.196]
To: andres@lagarcavilla.org, xen-devel@lists.xensource.com
Message-id: <000001ccec53$12f70100$38e50300$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczrTBY8d0cWPSj7TKKsXIgpkKalfgBASTQg
X-CFilter-Loop: Reflected
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
Cc: olaf@aepfle.de, hanweidong@huawei.com, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, keir.xen@gmail.com, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
> Sent: Wednesday, February 15, 2012 3:05 AM
> To: xen-devel@lists.xensource.com
> Cc: olaf@aepfle.de; keir.xen@gmail.com; tim@xen.org; JBeulich@suse.com; adin@gridcentric.ca
> Subject: [Xen-devel] RFC: AMD support for paging
> 
> We started hashing out some AMD support for mem_paging and mem_access.
> Right now my VMs boot, page out a bit, and then die on an HVM triple
> fault.
> 
> Most importantly, I want to get somebody from AMD to comment/help out on
> this. It feels like we're inches away from enabling support for this very
> nice feature. I'm not sure who exactly on AMD monitors the list for these
> kinds of things. It'd be great to have you on board!
> 
> For starters, the changes to the p2m code are relatively mild, but it'd be
> great if somebody spots a red flag.
> 
> Another issue: comments indicate that bits 59-62 in NPT entries are used
> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit (59)
> would give us enough space to support mem_access. Right now we only have 7
> bits available for Xen flags and that is not enough for paging and access.
> Is bit 59 effectively reserved?
> 
> Finally, the triple fault. Maybe I'm missing something obvious. Comments
> welcome.
> 
> Patch inline below, thanks!
> Andres
> 
> Enable AMD support for paging.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>              if ( !hap_enabled(d) )
>                  break;
> 
> -            /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> -                break;
> -
>              rc = -EXDEV;
>              /* Disallow paging in a PoD guest */
>              if ( p2m->pod.entry_count )
> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -53,6 +53,20 @@
>  #define P2M_BASE_FLAGS \
>          (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
> 
> +#ifdef __x86_64__
> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
> + * value tramples over the higher-order bits used for flags (NX, p2mt,
> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> + * juggle for l1 entries only (no paging superpages!) */
> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> +#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
> +                                INVALID_MFN : (mfn))
> +#else
> +#define clipped_mfn(mfn)    (mfn)
> +#define unclip_mfn(mfn)     (mfn)
> +#endif /* __x86_64__ */
> +
>  static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>  {
>      unsigned long flags;
> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>      case p2m_invalid:
>      case p2m_mmio_dm:
>      case p2m_populate_on_demand:
> +    case p2m_ram_paging_out:
> +    case p2m_ram_paged:
> +    case p2m_ram_paging_in:
>      default:
>          return flags;
>      case p2m_ram_ro:
> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>                                        shift, max)) )
>          return 0;
> 
> -    /* PoD: Not present doesn't imply empty. */
> +    /* PoD/paging: Not present doesn't imply empty. */
>      if ( !l1e_get_flags(*p2m_entry) )
>      {
>          struct page_info *pg;
> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>                                     0, L1_PAGETABLE_ENTRIES);
>          ASSERT(p2m_entry);
> 
> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
> -            entry_content = l1e_from_pfn(mfn_x(mfn),
> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>                                           p2m_type_to_flags(p2mt, mfn));
>          else
>              entry_content = l1e_empty();
> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>          if ( entry_content.l1 != 0 )
>          {
>              p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
> -            old_mfn = l1e_get_pfn(*p2m_entry);
> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>          }
>          /* level 1 entry */
>          p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
> entry_content, 1);
> @@ -615,11 +633,12 @@ pod_retry_l1:
>                             sizeof(l1e));
> 
>      if ( ret == 0 ) {
> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>          p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
> +                (l1e_mfn == INVALID_MFN && p2m_is_paging(p2mt)) );
> 
> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
> -             == p2m_populate_on_demand )
> +        if ( p2mt == p2m_populate_on_demand )
>          {
>              /* The read has succeeded, so we know that the mapping
>               * exits at this point.  */
> @@ -641,7 +660,7 @@ pod_retry_l1:
>          }
> 
>          if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
> -            mfn = _mfn(l1e_get_pfn(l1e));
> +            mfn = _mfn(l1e_mfn);
>          else
>              /* XXX see above */
>              p2mt = p2m_mmio_dm;
> @@ -783,18 +802,26 @@ pod_retry_l2:
>  pod_retry_l1:
>      if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
>      {
> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>          /* PoD: Try to populate */
> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
> +        if ( l1t == p2m_populate_on_demand )
>          {
>              if ( q != p2m_query ) {
>                  if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
>                      goto pod_retry_l1;
>              } else
>                  *t = p2m_populate_on_demand;
> +        } else {
> +            if ( p2m_is_paging(l1t) )
> +            {
> +                *t = l1t;
> +                /* No need to unclip due to check below */
> +                mfn = _mfn(l1e_get_pfn(*l1e));
> +            }
>          }
> 
>          unmap_domain_page(l1e);
> -        return _mfn(INVALID_MFN);
> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                   This means when p2mt is p2m_ram_paging_in, the mfn must be INVALID_MFN;
                   But in p2m_type_to_flags,when p2m_ram_paging_in or  p2m_ram_paged, the _PAGE_PRESENT is not set.
 
My idea shows like this:
In p2m_gfn_to_mfn function:
@@ -1370,6 +1379,7 @@
     paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
     l2_pgentry_t *l2e;
     l1_pgentry_t *l1e;
+    unsigned long flags;
 
     ASSERT(paging_mode_translate(d));
 
@@ -1455,7 +1465,8 @@
     l1e = map_domain_page(mfn_x(mfn));
     l1e += l1_table_offset(addr);
 pod_retry_l1:
-    if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
+    flags = l1e_get_flags(*l1e);
+    if ((( flags & _PAGE_PRESENT) == 0) && (!p2m_is_paging(p2m_flags_to_type(flags))))
     {
         /* PoD: Try to populate */
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
        {
            if ( q != p2m_query ) {
                if ( !p2m_pod_check_and_populate(p2m, gfn,
                                                 (l1_pgentry_t *)l1e, PAGE_ORDER_4K, q) )
                    goto pod_retry_l1;
            } else
                *t = p2m_populate_on_demand;
        }
    
        unmap_domain_page(l1e);
        return _mfn(INVALID_MFN);
    }
    mfn = _mfn(l1e_get_pfn(*l1e));
    *t = p2m_flags_to_type(l1e_get_flags(*l1e));
    unmap_domain_page(l1e);




>      }
>      mfn = _mfn(l1e_get_pfn(*l1e));
>      *t = p2m_flags_to_type(l1e_get_flags(*l1e));
> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>                      flags = l1e_get_flags(l1e[i1]);
>                      if ( p2m_flags_to_type(flags) != ot )
>                          continue;
> -                    mfn = l1e_get_pfn(l1e[i1]);
> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                      gfn = i1 + (i2 + (i3
>  #if CONFIG_PAGING_LEVELS >= 4
>  					+ (i4 * L3_PAGETABLE_ENTRIES)
> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>                             * L2_PAGETABLE_ENTRIES) * L1_PAGETABLE_ENTRIES;
>                      /* create a new 1le entry with the new type */
>                      flags = p2m_type_to_flags(nt, _mfn(mfn));
> -                    l1e_content = l1e_from_pfn(mfn, flags);
> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn), flags);
>                      p2m->write_p2m_entry(p2m, gfn, &l1e[i1],
>                                           l1mfn, l1e_content, 1);
>                  }
> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>                                  entry_count++;
>                              continue;
>                          }
> -                        mfn = l1e_get_pfn(l1e[i1]);
> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>                          ASSERT(mfn_valid(_mfn(mfn)));
>                          m2pfn = get_gpfn_from_mfn(mfn);
>                          if ( m2pfn != gfn &&
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFK-00024p-Ue; Thu, 16 Feb 2012 03:43:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFJ-00023L-9H
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329363774!6180150!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29576 invoked from network); 16 Feb 2012 03:42:54 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 03:42:54 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id DA1344B008F;
	Wed, 15 Feb 2012 19:42:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TM9FHLai8hLO66e3rpscAQMlCuB11s0zAS2h+KeBtQbF
	cZ8CqgOGdn+Es2e/nzN7x6mMYCoC7EL3CLmGltSPY4UPtfOzDcUzHKzCyOvyUHPM
	EBPpd2yJnbYx7v/MVh0nGJLGPP3hW6buYit3G0E+uOJaU85Xs1q+Z/9lFaPJKiA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=9gr4ldPN4TFf7aBilyHxaXF6XYA=; b=C2ItiWcERy8
	4ssjDhD74U+ZYMqp4XlBtZwJGP/bEd4hQiNEX+ZPzX1RMzmwAn9JLY1ltde9BqgK
	r6Gw4EJn/MS5CJdeTqWN8qFEAiAjFI+OHnz91CPyx1uGhwW0+8ww/IgZOZN+y/BA
	tCOd5EW1HTdVUwvOzFts9hAz4FQDHRgg=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 515474B0084; 
	Wed, 15 Feb 2012 19:42:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7a1d415a71d063a268e94450904869ba476848f9
Message-Id: <7a1d415a71d063a268e9.1329363747@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 4] x86/mm: Check sharing/paging/access have
 been enabled before processing a memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_access.c  |  3 +++
 xen/arch/x86/mm/mem_event.c   |  6 ++++--
 xen/arch/x86/mm/mem_paging.c  |  3 +++
 xen/arch/x86/mm/mem_sharing.c |  2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -29,6 +29,9 @@ int mem_access_memop(struct domain *d, x
 {
     int rc;
 
+    if ( unlikely(!d->mem_event->access.ring_page) )
+        return -ENODEV;
+
     switch( meo->op )
     {
     case XENMEM_access_op_resume:
diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -452,13 +452,15 @@ int mem_event_claim_slot(struct domain *
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_paging_notification(struct vcpu *v, unsigned int port)
 {
-    p2m_mem_paging_resume(v->domain);
+    if ( likely(v->domain->mem_event->paging.ring_page != NULL) )
+        p2m_mem_paging_resume(v->domain);
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_access_notification(struct vcpu *v, unsigned int port)
 {
-    p2m_mem_access_resume(v->domain);
+    if ( likely(v->domain->mem_event->access.ring_page != NULL) )
+        p2m_mem_access_resume(v->domain);
 }
 
 struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -27,6 +27,9 @@
 
 int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
+    if ( unlikely(!d->mem_event->paging.ring_page) )
+        return -ENODEV;
+
     switch( mec->op )
     {
     case XENMEM_paging_op_nominate:
diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1021,7 +1021,7 @@ int mem_sharing_memop(struct domain *d, 
     int rc = 0;
 
     /* Only HAP is supported */
-    if ( !hap_enabled(d) )
+    if ( !hap_enabled(d) || !d->arch.hvm_domain.mem_sharing_enabled )
          return -ENODEV;
 
     switch(mec->op)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFK-00024p-Ue; Thu, 16 Feb 2012 03:43:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFJ-00023L-9H
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329363774!6180150!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29576 invoked from network); 16 Feb 2012 03:42:54 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 03:42:54 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id DA1344B008F;
	Wed, 15 Feb 2012 19:42:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TM9FHLai8hLO66e3rpscAQMlCuB11s0zAS2h+KeBtQbF
	cZ8CqgOGdn+Es2e/nzN7x6mMYCoC7EL3CLmGltSPY4UPtfOzDcUzHKzCyOvyUHPM
	EBPpd2yJnbYx7v/MVh0nGJLGPP3hW6buYit3G0E+uOJaU85Xs1q+Z/9lFaPJKiA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=9gr4ldPN4TFf7aBilyHxaXF6XYA=; b=C2ItiWcERy8
	4ssjDhD74U+ZYMqp4XlBtZwJGP/bEd4hQiNEX+ZPzX1RMzmwAn9JLY1ltde9BqgK
	r6Gw4EJn/MS5CJdeTqWN8qFEAiAjFI+OHnz91CPyx1uGhwW0+8ww/IgZOZN+y/BA
	tCOd5EW1HTdVUwvOzFts9hAz4FQDHRgg=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 515474B0084; 
	Wed, 15 Feb 2012 19:42:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7a1d415a71d063a268e94450904869ba476848f9
Message-Id: <7a1d415a71d063a268e9.1329363747@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 4] x86/mm: Check sharing/paging/access have
 been enabled before processing a memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_access.c  |  3 +++
 xen/arch/x86/mm/mem_event.c   |  6 ++++--
 xen/arch/x86/mm/mem_paging.c  |  3 +++
 xen/arch/x86/mm/mem_sharing.c |  2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -29,6 +29,9 @@ int mem_access_memop(struct domain *d, x
 {
     int rc;
 
+    if ( unlikely(!d->mem_event->access.ring_page) )
+        return -ENODEV;
+
     switch( meo->op )
     {
     case XENMEM_access_op_resume:
diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -452,13 +452,15 @@ int mem_event_claim_slot(struct domain *
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_paging_notification(struct vcpu *v, unsigned int port)
 {
-    p2m_mem_paging_resume(v->domain);
+    if ( likely(v->domain->mem_event->paging.ring_page != NULL) )
+        p2m_mem_paging_resume(v->domain);
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_access_notification(struct vcpu *v, unsigned int port)
 {
-    p2m_mem_access_resume(v->domain);
+    if ( likely(v->domain->mem_event->access.ring_page != NULL) )
+        p2m_mem_access_resume(v->domain);
 }
 
 struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -27,6 +27,9 @@
 
 int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
+    if ( unlikely(!d->mem_event->paging.ring_page) )
+        return -ENODEV;
+
     switch( mec->op )
     {
     case XENMEM_paging_op_nominate:
diff -r b03a10be1428 -r 7a1d415a71d0 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1021,7 +1021,7 @@ int mem_sharing_memop(struct domain *d, 
     int rc = 0;
 
     /* Only HAP is supported */
-    if ( !hap_enabled(d) )
+    if ( !hap_enabled(d) || !d->arch.hvm_domain.mem_sharing_enabled )
          return -ENODEV;
 
     switch(mec->op)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFL-000252-BN; Thu, 16 Feb 2012 03:43:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFJ-00023M-I0
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329363773!13528279!2
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15452 invoked from network); 16 Feb 2012 03:42:55 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 03:42:55 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id AD9E54B0089;
	Wed, 15 Feb 2012 19:42:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=PjMOtDfcfGvxqDYcsCbUTSWxjNGKcUDGLWZgev/NdVaq
	Ht8g1sDfBRvzF725lUGqR4yIEP70bsHJKj5NETo6naaL/ovaDGPM/+FsziBUirdK
	DxSh1XTV8phyEUAA7BrIlBo2iIi0KCh64XioJZiYD4PbVOzFFPYJaDzwpY4bzDo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MrL/X54vLmgUCRGMVtmtuJHC08A=; b=t+fSms0wfDP
	bCjRXrwa15O1tiLYfiN3OmDy8R0zLJbt81zUm0ZUGKP8ESBcv32MQNEv9WpfKeTo
	QO7wTEmFL2UF+HukdqdkTQRm04zDRiiQo8VqG4aPT94b7LgBbFmBzdgDJ3bRu/zv
	pANcUq9PEzjggkZ219BQ328o+bEDYv3c=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 196D44B0084; 
	Wed, 15 Feb 2012 19:42:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 62b1fe67b8d1bb48932fc78119411d26852bc420
Message-Id: <62b1fe67b8d1bb48932f.1329363748@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 4] x86/mm: Fix two PAE+paging bugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/vmx/vmx.c |  16 +++++++++++++---
 xen/arch/x86/mm/hap/hap.c  |   2 +-
 2 files changed, 14 insertions(+), 4 deletions(-)


In hap_paging_update_modes, we were getting the gpa of the cr3, rather than the
gfn.

Vmx_load_pdptrs was crashing the host if the cr3 is paged out. Now it will only
crash the guest.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7a1d415a71d0 -r 62b1fe67b8d1 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1010,12 +1010,22 @@ static void vmx_load_pdptrs(struct vcpu 
     if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
 
-    mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-    if ( !p2m_is_ram(p2mt) )
+    mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
+    if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || 
+         /* If we didn't succeed in unsharing, get_page will fail
+          * (page still belongs to dom_cow) */
+         !get_page(mfn_to_page(mfn), v->domain) )
     {
+        /* Ideally you don't want to crash but rather go into a wait 
+         * queue, but this is the wrong place. We're holding at least
+         * the paging lock */
+        gdprintk(XENLOG_ERR,
+                    "Bad cr3 on load pdptrs gfn %"PRIx64" mfn %"PRIx64
+                    " type %d\n",cr3 >> PAGE_SHIFT, mfn, (int)p2mt);
         put_gfn(v->domain, cr3 >> PAGE_SHIFT);
         goto crash;
     }
+    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
 
     p = map_domain_page(mfn);
 
@@ -1043,7 +1053,7 @@ static void vmx_load_pdptrs(struct vcpu 
     vmx_vmcs_exit(v);
 
     unmap_domain_page(p);
-    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+    put_page(mfn_to_page(mfn));
     return;
 
  crash:
diff -r 7a1d415a71d0 -r 62b1fe67b8d1 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -786,7 +786,7 @@ hap_paging_get_mode(struct vcpu *v)
 static void hap_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
-    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
+    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3] >> PAGE_SHIFT;
     p2m_type_t t;
 
     /* We hold onto the cr3 as it may be modified later, and

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFL-000252-BN; Thu, 16 Feb 2012 03:43:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFJ-00023M-I0
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:43:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329363773!13528279!2
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15452 invoked from network); 16 Feb 2012 03:42:55 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 03:42:55 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id AD9E54B0089;
	Wed, 15 Feb 2012 19:42:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=PjMOtDfcfGvxqDYcsCbUTSWxjNGKcUDGLWZgev/NdVaq
	Ht8g1sDfBRvzF725lUGqR4yIEP70bsHJKj5NETo6naaL/ovaDGPM/+FsziBUirdK
	DxSh1XTV8phyEUAA7BrIlBo2iIi0KCh64XioJZiYD4PbVOzFFPYJaDzwpY4bzDo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=MrL/X54vLmgUCRGMVtmtuJHC08A=; b=t+fSms0wfDP
	bCjRXrwa15O1tiLYfiN3OmDy8R0zLJbt81zUm0ZUGKP8ESBcv32MQNEv9WpfKeTo
	QO7wTEmFL2UF+HukdqdkTQRm04zDRiiQo8VqG4aPT94b7LgBbFmBzdgDJ3bRu/zv
	pANcUq9PEzjggkZ219BQ328o+bEDYv3c=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 196D44B0084; 
	Wed, 15 Feb 2012 19:42:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 62b1fe67b8d1bb48932fc78119411d26852bc420
Message-Id: <62b1fe67b8d1bb48932f.1329363748@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 4] x86/mm: Fix two PAE+paging bugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/vmx/vmx.c |  16 +++++++++++++---
 xen/arch/x86/mm/hap/hap.c  |   2 +-
 2 files changed, 14 insertions(+), 4 deletions(-)


In hap_paging_update_modes, we were getting the gpa of the cr3, rather than the
gfn.

Vmx_load_pdptrs was crashing the host if the cr3 is paged out. Now it will only
crash the guest.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 7a1d415a71d0 -r 62b1fe67b8d1 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1010,12 +1010,22 @@ static void vmx_load_pdptrs(struct vcpu 
     if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
 
-    mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
-    if ( !p2m_is_ram(p2mt) )
+    mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
+    if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || 
+         /* If we didn't succeed in unsharing, get_page will fail
+          * (page still belongs to dom_cow) */
+         !get_page(mfn_to_page(mfn), v->domain) )
     {
+        /* Ideally you don't want to crash but rather go into a wait 
+         * queue, but this is the wrong place. We're holding at least
+         * the paging lock */
+        gdprintk(XENLOG_ERR,
+                    "Bad cr3 on load pdptrs gfn %"PRIx64" mfn %"PRIx64
+                    " type %d\n",cr3 >> PAGE_SHIFT, mfn, (int)p2mt);
         put_gfn(v->domain, cr3 >> PAGE_SHIFT);
         goto crash;
     }
+    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
 
     p = map_domain_page(mfn);
 
@@ -1043,7 +1053,7 @@ static void vmx_load_pdptrs(struct vcpu 
     vmx_vmcs_exit(v);
 
     unmap_domain_page(p);
-    put_gfn(v->domain, cr3 >> PAGE_SHIFT);
+    put_page(mfn_to_page(mfn));
     return;
 
  crash:
diff -r 7a1d415a71d0 -r 62b1fe67b8d1 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -786,7 +786,7 @@ hap_paging_get_mode(struct vcpu *v)
 static void hap_update_paging_modes(struct vcpu *v)
 {
     struct domain *d = v->domain;
-    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3];
+    unsigned long cr3_gfn = v->arch.hvm_vcpu.guest_cr[3] >> PAGE_SHIFT;
     p2m_type_t t;
 
     /* We hold onto the cr3 as it may be modified later, and

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFJ-00024Q-Dw; Thu, 16 Feb 2012 03:43:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFI-00023A-6p
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:43:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329363773!13528279!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15434 invoked from network); 16 Feb 2012 03:42:53 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 03:42:53 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 22F674B0089;
	Wed, 15 Feb 2012 19:42:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YzXc2DCH6FhLuM35MxbK1CkK+5B/moEchWUNOU6kYqGp
	B3EHARMT8OjmuyNV1avwzaHjeuIsRmz9npEI6cuVkOdLf2UmW1MfkPyKvwQiob0t
	jP76JOAve9tAc2w+yMZb021TTAeK7FIg52NNcE8gExsbwFhYyH3VD1ovLMrn5v8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7RMjv7ZMYo2aTpvDrzy4xPUznNo=; b=gcSqNkdFCqV
	INmIXnYJl8GMeFW2g3SY/Ufp3iKo/cJMZwsaRhQeKVQonjEazQktUh3XhcvbL/d7
	ePC21riqT8qhB/hMtaauOyli/pU5nbFev/PsbQWI/txuDWY7NG27NjEs7jniOO03
	L5H5COcQ9TXk0XtBQL7OX/BCTqQ/gykg=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 9A5B14B0084; 
	Wed, 15 Feb 2012 19:42:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b03a10be14280ecce5c7ceeed798130c90f3c2ad
Message-Id: <b03a10be14280ecce5c7.1329363746@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 4] x86/mm: Fix more ballooning+paging and
 ballooning+sharing bugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |   7 +++++--
 xen/common/memory.c   |  17 ++++++++++++++++-
 2 files changed, 21 insertions(+), 3 deletions(-)


If the guest balloons away a page that has been nominated for paging but not yet
paged out, we fix:
 - Send EVICT_FAIL flag in the event to the pager
 - Do not leak the underlying page

If the page was shared, we were not:
 - properly refreshing the mfn to balloon after the unshare.
 - unlocking the p2m on the error exit case

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a70a87d7bf84 -r b03a10be1428 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -928,11 +928,14 @@ void p2m_mem_paging_drop_page(struct dom
     req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
-
     /* Update stats unless the page hasn't yet been evicted */
     if ( p2mt != p2m_ram_paging_out )
         atomic_dec(&d->paged_pages);
+    else
+        /* Evict will fail now, tag this request for pager */
+        req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
diff -r a70a87d7bf84 -r b03a10be1428 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -167,6 +167,15 @@ int guest_remove_page(struct domain *d, 
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
         put_gfn(d, gmfn);
+        /* If the page hasn't yet been paged out, there is an
+         * actual page that needs to be released. */
+        if ( p2mt == p2m_ram_paging_out )
+        {
+            ASSERT(mfn_valid(mfn));
+            page = mfn_to_page(mfn);
+            if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
+                put_page(page);
+        }
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
         return 1;
     }
@@ -181,7 +190,6 @@ int guest_remove_page(struct domain *d, 
         return 0;
     }
             
-    page = mfn_to_page(mfn);
 #ifdef CONFIG_X86_64
     if ( p2m_is_shared(p2mt) )
     {
@@ -190,10 +198,17 @@ int guest_remove_page(struct domain *d, 
          * need to trigger proper cleanup. Once done, this is 
          * like any other page. */
         if ( mem_sharing_unshare_page(d, gmfn, 0) )
+        {
+            put_gfn(d, gmfn);
             return 0;
+        }
+        /* Maybe the mfn changed */
+        mfn = mfn_x(get_gfn_query_unlocked(d, gmfn, &p2mt));
+        ASSERT(!p2m_is_shared(p2mt));
     }
 #endif /* CONFIG_X86_64 */
 
+    page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
     {
         put_gfn(d, gmfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFJ-00024Q-Dw; Thu, 16 Feb 2012 03:43:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFI-00023A-6p
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:43:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329363773!13528279!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15434 invoked from network); 16 Feb 2012 03:42:53 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 03:42:53 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 22F674B0089;
	Wed, 15 Feb 2012 19:42:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YzXc2DCH6FhLuM35MxbK1CkK+5B/moEchWUNOU6kYqGp
	B3EHARMT8OjmuyNV1avwzaHjeuIsRmz9npEI6cuVkOdLf2UmW1MfkPyKvwQiob0t
	jP76JOAve9tAc2w+yMZb021TTAeK7FIg52NNcE8gExsbwFhYyH3VD1ovLMrn5v8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7RMjv7ZMYo2aTpvDrzy4xPUznNo=; b=gcSqNkdFCqV
	INmIXnYJl8GMeFW2g3SY/Ufp3iKo/cJMZwsaRhQeKVQonjEazQktUh3XhcvbL/d7
	ePC21riqT8qhB/hMtaauOyli/pU5nbFev/PsbQWI/txuDWY7NG27NjEs7jniOO03
	L5H5COcQ9TXk0XtBQL7OX/BCTqQ/gykg=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 9A5B14B0084; 
	Wed, 15 Feb 2012 19:42:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b03a10be14280ecce5c7ceeed798130c90f3c2ad
Message-Id: <b03a10be14280ecce5c7.1329363746@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 4] x86/mm: Fix more ballooning+paging and
 ballooning+sharing bugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |   7 +++++--
 xen/common/memory.c   |  17 ++++++++++++++++-
 2 files changed, 21 insertions(+), 3 deletions(-)


If the guest balloons away a page that has been nominated for paging but not yet
paged out, we fix:
 - Send EVICT_FAIL flag in the event to the pager
 - Do not leak the underlying page

If the page was shared, we were not:
 - properly refreshing the mfn to balloon after the unshare.
 - unlocking the p2m on the error exit case

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a70a87d7bf84 -r b03a10be1428 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -928,11 +928,14 @@ void p2m_mem_paging_drop_page(struct dom
     req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
-    mem_event_put_request(d, &d->mem_event->paging, &req);
-
     /* Update stats unless the page hasn't yet been evicted */
     if ( p2mt != p2m_ram_paging_out )
         atomic_dec(&d->paged_pages);
+    else
+        /* Evict will fail now, tag this request for pager */
+        req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
diff -r a70a87d7bf84 -r b03a10be1428 xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -167,6 +167,15 @@ int guest_remove_page(struct domain *d, 
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);
         put_gfn(d, gmfn);
+        /* If the page hasn't yet been paged out, there is an
+         * actual page that needs to be released. */
+        if ( p2mt == p2m_ram_paging_out )
+        {
+            ASSERT(mfn_valid(mfn));
+            page = mfn_to_page(mfn);
+            if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
+                put_page(page);
+        }
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
         return 1;
     }
@@ -181,7 +190,6 @@ int guest_remove_page(struct domain *d, 
         return 0;
     }
             
-    page = mfn_to_page(mfn);
 #ifdef CONFIG_X86_64
     if ( p2m_is_shared(p2mt) )
     {
@@ -190,10 +198,17 @@ int guest_remove_page(struct domain *d, 
          * need to trigger proper cleanup. Once done, this is 
          * like any other page. */
         if ( mem_sharing_unshare_page(d, gmfn, 0) )
+        {
+            put_gfn(d, gmfn);
             return 0;
+        }
+        /* Maybe the mfn changed */
+        mfn = mfn_x(get_gfn_query_unlocked(d, gmfn, &p2mt));
+        ASSERT(!p2m_is_shared(p2mt));
     }
 #endif /* CONFIG_X86_64 */
 
+    page = mfn_to_page(mfn);
     if ( unlikely(!get_page(page, d)) )
     {
         put_gfn(d, gmfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFE-00023R-Kq; Thu, 16 Feb 2012 03:42:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFC-000237-Rv
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:42:55 +0000
Received: from [85.158.139.83:62561] by server-3.bemta-5.messagelabs.com id
	CD/4A-06438-D3B7C3F4; Thu, 16 Feb 2012 03:42:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329363773!12558551!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDEzNzc2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11080 invoked from network); 16 Feb 2012 03:42:53 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 03:42:53 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 6CE2C4B008F;
	Wed, 15 Feb 2012 19:42:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Uo6x9+gxEYHOqlzPrHOvOxfTbAG0bUw5txiSlSQEaG9h
	ZgvLrB50e/zMw5vlO1Iu7rZN15nAE4M+2mFRvzQDl5xXqjbV1RlLJx7aM1Bxv59/
	ls9Q0JcIb+VKB+O+KP7fAwY9l8Qio/NK6AIm/Jl6OBOsllqJ4dt4trGtjLAbd00=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PNdYsyriBbhKllmYPLjvOXViCAU=; b=jaIDKc1fq+k
	OM43lUTGCdgLHuP96/ON2Ow7Aa1ywVSpHyx3irP9He4LNCWLGZtQL0G8I2JFCfqL
	dZTeL92Pj2VY1YRZ4jOnHk/2UyCYEjpqczsokrw6kEboay5SXT07zbIydlbKL+f/
	0AO2ipLY/5aQD+NcZg8ti6OodgHr/5tI=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id DB9344B0084; 
	Wed, 15 Feb 2012 19:42:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a70a87d7bf8402d0d6172b3d743ced09b937f840
Message-Id: <a70a87d7bf8402d0d617.1329363745@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 4] x86/mm: Make asserts on types and counts
 of shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  3 ++-
 xen/arch/x86/mm/p2m.c         |  7 +++++--
 2 files changed, 7 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 658530e2f380 -r a70a87d7bf84 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -201,7 +201,8 @@ static struct page_info* mem_sharing_loo
             /* Count has to be at least two, because we're called
              * with the mfn locked (1) and this is supposed to be 
              * a shared page (1). */
-            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2); 
+            unsigned long type = read_atomic(&page->u.inuse.type_info);
+            ASSERT((type & PGT_shared_page) && ((type & PGT_count_mask) >= 2));
             ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
             return page;
         }
diff -r 658530e2f380 -r a70a87d7bf84 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -735,6 +735,7 @@ set_shared_p2m_entry(struct domain *d, u
     p2m_access_t a;
     p2m_type_t ot;
     mfn_t omfn;
+    unsigned long pg_type;
 
     if ( !paging_mode_translate(p2m->domain) )
         return 0;
@@ -745,8 +746,10 @@ set_shared_p2m_entry(struct domain *d, u
      * sharable first */
     ASSERT(p2m_is_shared(ot));
     ASSERT(mfn_valid(omfn));
-    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
-                    != PGT_shared_page) )
+    /* Set the m2p entry to invalid only if there are no further type
+     * refs to this page as shared */
+    pg_type = read_atomic(&(mfn_to_page(omfn)->u.inuse.type_info));
+    if ( !((pg_type & PGT_shared_page) && (pg_type & PGT_count_mask)) )
         set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFE-00023R-Kq; Thu, 16 Feb 2012 03:42:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFC-000237-Rv
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:42:55 +0000
Received: from [85.158.139.83:62561] by server-3.bemta-5.messagelabs.com id
	CD/4A-06438-D3B7C3F4; Thu, 16 Feb 2012 03:42:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329363773!12558551!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDEzNzc2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11080 invoked from network); 16 Feb 2012 03:42:53 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.5) by server-4.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 03:42:53 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 6CE2C4B008F;
	Wed, 15 Feb 2012 19:42:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Uo6x9+gxEYHOqlzPrHOvOxfTbAG0bUw5txiSlSQEaG9h
	ZgvLrB50e/zMw5vlO1Iu7rZN15nAE4M+2mFRvzQDl5xXqjbV1RlLJx7aM1Bxv59/
	ls9Q0JcIb+VKB+O+KP7fAwY9l8Qio/NK6AIm/Jl6OBOsllqJ4dt4trGtjLAbd00=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PNdYsyriBbhKllmYPLjvOXViCAU=; b=jaIDKc1fq+k
	OM43lUTGCdgLHuP96/ON2Ow7Aa1ywVSpHyx3irP9He4LNCWLGZtQL0G8I2JFCfqL
	dZTeL92Pj2VY1YRZ4jOnHk/2UyCYEjpqczsokrw6kEboay5SXT07zbIydlbKL+f/
	0AO2ipLY/5aQD+NcZg8ti6OodgHr/5tI=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id DB9344B0084; 
	Wed, 15 Feb 2012 19:42:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a70a87d7bf8402d0d6172b3d743ced09b937f840
Message-Id: <a70a87d7bf8402d0d617.1329363745@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 4] x86/mm: Make asserts on types and counts
 of shared pages more accurate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  3 ++-
 xen/arch/x86/mm/p2m.c         |  7 +++++--
 2 files changed, 7 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 658530e2f380 -r a70a87d7bf84 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -201,7 +201,8 @@ static struct page_info* mem_sharing_loo
             /* Count has to be at least two, because we're called
              * with the mfn locked (1) and this is supposed to be 
              * a shared page (1). */
-            ASSERT((page->u.inuse.type_info & PGT_count_mask) >= 2); 
+            unsigned long type = read_atomic(&page->u.inuse.type_info);
+            ASSERT((type & PGT_shared_page) && ((type & PGT_count_mask) >= 2));
             ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
             return page;
         }
diff -r 658530e2f380 -r a70a87d7bf84 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -735,6 +735,7 @@ set_shared_p2m_entry(struct domain *d, u
     p2m_access_t a;
     p2m_type_t ot;
     mfn_t omfn;
+    unsigned long pg_type;
 
     if ( !paging_mode_translate(p2m->domain) )
         return 0;
@@ -745,8 +746,10 @@ set_shared_p2m_entry(struct domain *d, u
      * sharable first */
     ASSERT(p2m_is_shared(ot));
     ASSERT(mfn_valid(omfn));
-    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
-                    != PGT_shared_page) )
+    /* Set the m2p entry to invalid only if there are no further type
+     * refs to this page as shared */
+    pg_type = read_atomic(&(mfn_to_page(omfn)->u.inuse.type_info));
+    if ( !((pg_type & PGT_shared_page) && (pg_type & PGT_count_mask)) )
         set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFJ-00024H-13; Thu, 16 Feb 2012 03:43:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFG-00022y-R7
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:42:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329363772!13395013!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NDcx\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NDcx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22685 invoked from network); 16 Feb 2012 03:42:52 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-16.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 03:42:52 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id ABAB44B0089;
	Wed, 15 Feb 2012 19:42:51 -0800 (PST)
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=kwQ4UmF/EzNEplwxauNVro
	ttmMHmA1P0t7Aoi2Jh1aRAUZc9dP/s6MagizTsZjbY3IYOPlvid/H+DfzIKGGdyE
	xQZgNH7sO3osjVBebICvbztyE3F3B0fs2iFfKJWOP6Xu3973BqG+EyGA1tos2Drb
	0sa4tunibBx9bg/5I0xhc=
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=reqZcPyPLx5+
	SBJBNLzMLXpe+lI=; b=htumjd2bzptMSCL4h+9cgl+tE/hiNrOUB/YBF8KyI/rr
	AFaGTEZTpKqZxp6/yuhzPa4xhdAEyg+xH/+BOnpx2hDnSrF2hb5gqnMJtVw7oJeB
	nE9gRxkaHA8ySTgpKXVItQB0tdihk2nYvxyqQF+9GsHfjBbH3WIE8G5K308EGZw=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 227604B0084; 
	Wed, 15 Feb 2012 19:42:51 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 4] x86/mm: Four fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this series we post four patches with bugfixes to p2m, hap, paging and
sharing code:

- Make a few asserts on shared pages type and counts more accurate
 (this time done right, hopefully!)
- Bugfix interactions between the balloon and the paging and sharing
 subsystems. Posted a week ago, probably slipped through the cracks.
- Added a missing sanity check for sharing/paging/access memops.
- Fix vmx_load_pdptrs to crash the guest instead of the host in the
 presence of paged out cr3's.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_sharing.c |   3 ++-
 xen/arch/x86/mm/p2m.c         |   7 +++++--
 xen/arch/x86/mm/p2m.c         |   7 +++++--
 xen/common/memory.c           |  17 ++++++++++++++++-
 xen/arch/x86/mm/mem_access.c  |   3 +++
 xen/arch/x86/mm/mem_event.c   |   6 ++++--
 xen/arch/x86/mm/mem_paging.c  |   3 +++
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/hvm/vmx/vmx.c    |  16 +++++++++++++---
 xen/arch/x86/mm/hap/hap.c     |   2 +-
 10 files changed, 53 insertions(+), 13 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:43:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsFJ-00024H-13; Thu, 16 Feb 2012 03:43:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsFG-00022y-R7
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:42:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329363772!13395013!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NDcx\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE1NDcx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22685 invoked from network); 16 Feb 2012 03:42:52 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-16.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 03:42:52 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id ABAB44B0089;
	Wed, 15 Feb 2012 19:42:51 -0800 (PST)
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=kwQ4UmF/EzNEplwxauNVro
	ttmMHmA1P0t7Aoi2Jh1aRAUZc9dP/s6MagizTsZjbY3IYOPlvid/H+DfzIKGGdyE
	xQZgNH7sO3osjVBebICvbztyE3F3B0fs2iFfKJWOP6Xu3973BqG+EyGA1tos2Drb
	0sa4tunibBx9bg/5I0xhc=
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=reqZcPyPLx5+
	SBJBNLzMLXpe+lI=; b=htumjd2bzptMSCL4h+9cgl+tE/hiNrOUB/YBF8KyI/rr
	AFaGTEZTpKqZxp6/yuhzPa4xhdAEyg+xH/+BOnpx2hDnSrF2hb5gqnMJtVw7oJeB
	nE9gRxkaHA8ySTgpKXVItQB0tdihk2nYvxyqQF+9GsHfjBbH3WIE8G5K308EGZw=
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-a23.g.dreamhost.com (Postfix) with ESMTPSA id 227604B0084; 
	Wed, 15 Feb 2012 19:42:51 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:42:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 4] x86/mm: Four fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this series we post four patches with bugfixes to p2m, hap, paging and
sharing code:

- Make a few asserts on shared pages type and counts more accurate
 (this time done right, hopefully!)
- Bugfix interactions between the balloon and the paging and sharing
 subsystems. Posted a week ago, probably slipped through the cracks.
- Added a missing sanity check for sharing/paging/access memops.
- Fix vmx_load_pdptrs to crash the guest instead of the host in the
 presence of paged out cr3's.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_sharing.c |   3 ++-
 xen/arch/x86/mm/p2m.c         |   7 +++++--
 xen/arch/x86/mm/p2m.c         |   7 +++++--
 xen/common/memory.c           |  17 ++++++++++++++++-
 xen/arch/x86/mm/mem_access.c  |   3 +++
 xen/arch/x86/mm/mem_event.c   |   6 ++++--
 xen/arch/x86/mm/mem_paging.c  |   3 +++
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/hvm/vmx/vmx.c    |  16 +++++++++++++---
 xen/arch/x86/mm/hap/hap.c     |   2 +-
 10 files changed, 53 insertions(+), 13 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTc-0003YN-6Y; Thu, 16 Feb 2012 03:57:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTa-0003Xj-Fa
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329364531!52916453!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxMzc2OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14024 invoked from network); 16 Feb 2012 03:55:31 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 03:55:31 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 78C41380069;
	Wed, 15 Feb 2012 19:57:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=SlWOLDjqTJz+vuYTbI5ctnJzSatv7epaUgrBQ6aYAGdt
	1KiYO+OJI06AIeVYfgX9WplU2i/njZGcjbwA5CIsVeyRS9X7plPAbDVBQ9QVCyV4
	vrL6HnQz7778G8O0WVo3KecoTTR/PzcX74XQ2Dwi/5trbkLjvFThd479ZOQcnNQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ONt+0NfPbOzNulKRvJBE3tS5FRA=; b=IzIaZMQhdFY
	nKe6epnYcgEJHgdKvJsiwgEqU2ZeD31zu9MgbCbN8yoBI+ltLwx5RMlaF5DMG69K
	CXOveOwx9gPNcKjVn8ZUztT37s5ZM2+B+zzDYUQFPC7lYBnx+JRd/zp2fpax7E7g
	k4wdIydX6/6I+IEEpZYMYrjdhbY6tjCo=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 132C238006F; 
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 65c15f3c96117a2491403ad245a8ea74c46704be
Message-Id: <65c15f3c96117a249140.1329364627@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 4] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/page_alloc.c  |  10 ++++++++++
 xen/include/public/xen.h |   1 +
 2 files changed, 11 insertions(+), 0 deletions(-)


When a low memory threshold on the Xen heap is reached, we fire a global dom0
virq. If someone's listening, they can free up some more memory. The low
threshold is configurable via the command line token 'low_mem_virq_limit", and
defaults to 64MiB. We define a new virq VIRQ_ENOMEM. Potential listeners
include squeezed, xenballoond, or anything else that can be fired through
xencommons.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 407b5ac709aa -r 65c15f3c9611 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/event.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
@@ -300,6 +301,12 @@ static unsigned long init_node_heap(int 
     return needed;
 }
 
+/* Default to 64 MiB */
+#define DEFAULT_LOW_MEM_VIRQ_MIB    64
+static unsigned long long __read_mostly opt_low_mem_virq = 
+                                        (DEFAULT_LOW_MEM_VIRQ_MIB << 20);
+size_param("low_mem_virq_limit", opt_low_mem_virq);
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi,
@@ -420,6 +427,9 @@ static struct page_info *alloc_heap_page
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
+    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
+        send_global_virq(VIRQ_ENOMEM);
+
     if ( d != NULL )
         d->last_alloc_node = node;
 
diff -r 407b5ac709aa -r 65c15f3c9611 xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #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) Dangerously low on heap memory       */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTc-0003YN-6Y; Thu, 16 Feb 2012 03:57:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTa-0003Xj-Fa
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329364531!52916453!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxMzc2OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14024 invoked from network); 16 Feb 2012 03:55:31 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 03:55:31 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 78C41380069;
	Wed, 15 Feb 2012 19:57:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=SlWOLDjqTJz+vuYTbI5ctnJzSatv7epaUgrBQ6aYAGdt
	1KiYO+OJI06AIeVYfgX9WplU2i/njZGcjbwA5CIsVeyRS9X7plPAbDVBQ9QVCyV4
	vrL6HnQz7778G8O0WVo3KecoTTR/PzcX74XQ2Dwi/5trbkLjvFThd479ZOQcnNQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ONt+0NfPbOzNulKRvJBE3tS5FRA=; b=IzIaZMQhdFY
	nKe6epnYcgEJHgdKvJsiwgEqU2ZeD31zu9MgbCbN8yoBI+ltLwx5RMlaF5DMG69K
	CXOveOwx9gPNcKjVn8ZUztT37s5ZM2+B+zzDYUQFPC7lYBnx+JRd/zp2fpax7E7g
	k4wdIydX6/6I+IEEpZYMYrjdhbY6tjCo=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 132C238006F; 
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 65c15f3c96117a2491403ad245a8ea74c46704be
Message-Id: <65c15f3c96117a249140.1329364627@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 4] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/page_alloc.c  |  10 ++++++++++
 xen/include/public/xen.h |   1 +
 2 files changed, 11 insertions(+), 0 deletions(-)


When a low memory threshold on the Xen heap is reached, we fire a global dom0
virq. If someone's listening, they can free up some more memory. The low
threshold is configurable via the command line token 'low_mem_virq_limit", and
defaults to 64MiB. We define a new virq VIRQ_ENOMEM. Potential listeners
include squeezed, xenballoond, or anything else that can be fired through
xencommons.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 407b5ac709aa -r 65c15f3c9611 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/event.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
@@ -300,6 +301,12 @@ static unsigned long init_node_heap(int 
     return needed;
 }
 
+/* Default to 64 MiB */
+#define DEFAULT_LOW_MEM_VIRQ_MIB    64
+static unsigned long long __read_mostly opt_low_mem_virq = 
+                                        (DEFAULT_LOW_MEM_VIRQ_MIB << 20);
+size_param("low_mem_virq_limit", opt_low_mem_virq);
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi,
@@ -420,6 +427,9 @@ static struct page_info *alloc_heap_page
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
+    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
+        send_global_virq(VIRQ_ENOMEM);
+
     if ( d != NULL )
         d->last_alloc_node = node;
 
diff -r 407b5ac709aa -r 65c15f3c9611 xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #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) Dangerously low on heap memory       */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTb-0003YE-QC; Thu, 16 Feb 2012 03:57:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTa-0003Xd-3A
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:46 +0000
Received: from [193.109.254.147:28563] by server-3.bemta-14.messagelabs.com id
	9F/72-31466-9BE7C3F4; Thu, 16 Feb 2012 03:57:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329364612!52941103!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY1MzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28783 invoked from network); 16 Feb 2012 03:56:52 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 03:56:52 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 7CB46380065;
	Wed, 15 Feb 2012 19:57:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mGCzsFVfD8qOLoAe6A00lSKYepb8WnBlCyjKddwjAMDS
	niy9SVFep906ZSYoHvGa6sZY0bAm6/EwazJCif2KJZY2OQ1YVVgG7GLv59oY62zH
	5O5ko4D4oZHyV2E22lYp3aO3bfh787o30Tlz7cWNl4iYQyggXkgGU0QuEomjKX8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=O9nVGtuHPoe3NOnQl/L0M9AiuQ0=; b=sdcSVmbzDak
	DQHLcPC+l+XWO+9UC+7Tuj7th3/sukij7CH0b7u6H9A9BEuZWE3sY0yu7DlZ0keQ
	G0x8XZtr77JvhQ7Q7CK2Un9hhn4ZfQc1PVZPJ76i6G0iYjEKS2uCn8KSnRvdjqSI
	j9MOtfjRrWyZKdUJg3itH/2dfQLBA++8=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id EE2CF38006F; 
	Wed, 15 Feb 2012 19:57:41 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 11fd4e0a1e1a76ca3bc1ca812b2efa3fa5a1d4c1
Message-Id: <11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/domctl.c |  8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)


Apparently, setting d->max_pages to something lower than d->tot_pages is
used as a mechanism for controling a domain's footprint. It will result
in all new page allocations failing.

This is a really bad idea with paging or sharing, as regular guest memory
accesses may need to be satisfied by allocating new memory (either to
page in or to unshare).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
          * NB. We removed a check that new_max >= current tot_pages; this means
          * that the domain will now be allowed to "ratchet" down to new_max. In
          * the meantime, while tot > max, all new allocations are disallowed.
+         *
+         * Except that this is not a great idea for domains doing sharing or 
+         * paging, as they need to perform new allocations on the fly.
          */
-        d->max_pages = new_max;
+        if ( (new_max > d->max_pages) ||
+             !((d->mem_event->paging.ring_page != NULL) ||
+                d->arch.hvm_domain.mem_sharing_enabled) )
+            d->max_pages = new_max;
         ret = 0;
         spin_unlock(&d->page_alloc_lock);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTb-0003YE-QC; Thu, 16 Feb 2012 03:57:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTa-0003Xd-3A
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:46 +0000
Received: from [193.109.254.147:28563] by server-3.bemta-14.messagelabs.com id
	9F/72-31466-9BE7C3F4; Thu, 16 Feb 2012 03:57:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329364612!52941103!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY1MzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28783 invoked from network); 16 Feb 2012 03:56:52 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 03:56:52 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 7CB46380065;
	Wed, 15 Feb 2012 19:57:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mGCzsFVfD8qOLoAe6A00lSKYepb8WnBlCyjKddwjAMDS
	niy9SVFep906ZSYoHvGa6sZY0bAm6/EwazJCif2KJZY2OQ1YVVgG7GLv59oY62zH
	5O5ko4D4oZHyV2E22lYp3aO3bfh787o30Tlz7cWNl4iYQyggXkgGU0QuEomjKX8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=O9nVGtuHPoe3NOnQl/L0M9AiuQ0=; b=sdcSVmbzDak
	DQHLcPC+l+XWO+9UC+7Tuj7th3/sukij7CH0b7u6H9A9BEuZWE3sY0yu7DlZ0keQ
	G0x8XZtr77JvhQ7Q7CK2Un9hhn4ZfQc1PVZPJ76i6G0iYjEKS2uCn8KSnRvdjqSI
	j9MOtfjRrWyZKdUJg3itH/2dfQLBA++8=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id EE2CF38006F; 
	Wed, 15 Feb 2012 19:57:41 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 11fd4e0a1e1a76ca3bc1ca812b2efa3fa5a1d4c1
Message-Id: <11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/domctl.c |  8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)


Apparently, setting d->max_pages to something lower than d->tot_pages is
used as a mechanism for controling a domain's footprint. It will result
in all new page allocations failing.

This is a really bad idea with paging or sharing, as regular guest memory
accesses may need to be satisfied by allocating new memory (either to
page in or to unshare).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
          * NB. We removed a check that new_max >= current tot_pages; this means
          * that the domain will now be allowed to "ratchet" down to new_max. In
          * the meantime, while tot > max, all new allocations are disallowed.
+         *
+         * Except that this is not a great idea for domains doing sharing or 
+         * paging, as they need to perform new allocations on the fly.
          */
-        d->max_pages = new_max;
+        if ( (new_max > d->max_pages) ||
+             !((d->mem_event->paging.ring_page != NULL) ||
+                d->arch.hvm_domain.mem_sharing_enabled) )
+            d->max_pages = new_max;
         ret = 0;
         spin_unlock(&d->page_alloc_lock);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTe-0003ZD-Ps; Thu, 16 Feb 2012 03:57:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTd-0003XX-It
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329364662!11599409!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTQ2Mzk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1200 invoked from network); 16 Feb 2012 03:57:43 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.202) by server-7.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 03:57:43 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id C1CF4380073;
	Wed, 15 Feb 2012 19:57:41 -0800 (PST)
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=r5SolWg4QZRXtqXcm3FcK8
	DN0+iUo0B9pH1JL8bFd7J1maPEV52RNW5JVHCnR95nzQyMYAjptNsrSMXVr4eMYm
	T7JTTgm6arKscUnK4qv+Myd9jtiESkyixB14k2BvOBOJW1RKpMI8R7YM7Le/T3k6
	Y2qp+IFVwoggD6FbYuhQs=
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=XQQ96UzPHSNM
	N7bCaa/2fLHRodA=; b=Fgk+PbwrQjo5hHPeK6uU3JAl9gxXZkx6lXPX8kAKnycJ
	/X0vuOkNlvJEguQwQKuF/RBqWbxmSfqFcP4imnUDxMencvUN30V4ZsUzfxrP+6cG
	qjrnRR6jBlgPbUiIJXls9Pu80BhAinHfp54XlM5bRGjmIL4UXK7mg/0ivq3r1OY=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 532C438006F; 
	Wed, 15 Feb 2012 19:57:41 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:03 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After some experiments with the sharing code under low memory conditions, we
post the following series:
- Bugfix sharing unshare when we run out of memory.
- Sort out the situations in which we can go to sleep on a wait queue
 if unshare fails (and by extension the semantics of unshare error
 handling)
- Prevent a certain Ocaml-based toolstack from crashing domains doing sharing
 or paging.
- Add a VIRQ that the hypervisor can emit when reaching a low memory threshold.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/common/domctl.c               |   8 +++++-
 xen/arch/x86/mm/mem_event.c       |   5 ++-
 xen/include/asm-x86/mem_event.h   |  30 ++++++++++++++++++---
 xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
 xen/arch/x86/mm.c                 |   8 +++--
 xen/arch/x86/mm/mem_sharing.c     |  52 ++++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
 xen/common/grant_table.c          |  11 ++++---
 xen/common/memory.c               |   1 +
 xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
 xen/common/page_alloc.c           |  10 +++++++
 xen/include/public/xen.h          |   1 +
 12 files changed, 140 insertions(+), 39 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTe-0003ZD-Ps; Thu, 16 Feb 2012 03:57:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTd-0003XX-It
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329364662!11599409!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTQ2Mzk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1200 invoked from network); 16 Feb 2012 03:57:43 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.202) by server-7.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 03:57:43 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id C1CF4380073;
	Wed, 15 Feb 2012 19:57:41 -0800 (PST)
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=r5SolWg4QZRXtqXcm3FcK8
	DN0+iUo0B9pH1JL8bFd7J1maPEV52RNW5JVHCnR95nzQyMYAjptNsrSMXVr4eMYm
	T7JTTgm6arKscUnK4qv+Myd9jtiESkyixB14k2BvOBOJW1RKpMI8R7YM7Le/T3k6
	Y2qp+IFVwoggD6FbYuhQs=
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=XQQ96UzPHSNM
	N7bCaa/2fLHRodA=; b=Fgk+PbwrQjo5hHPeK6uU3JAl9gxXZkx6lXPX8kAKnycJ
	/X0vuOkNlvJEguQwQKuF/RBqWbxmSfqFcP4imnUDxMencvUN30V4ZsUzfxrP+6cG
	qjrnRR6jBlgPbUiIJXls9Pu80BhAinHfp54XlM5bRGjmIL4UXK7mg/0ivq3r1OY=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 532C438006F; 
	Wed, 15 Feb 2012 19:57:41 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:03 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After some experiments with the sharing code under low memory conditions, we
post the following series:
- Bugfix sharing unshare when we run out of memory.
- Sort out the situations in which we can go to sleep on a wait queue
 if unshare fails (and by extension the semantics of unshare error
 handling)
- Prevent a certain Ocaml-based toolstack from crashing domains doing sharing
 or paging.
- Add a VIRQ that the hypervisor can emit when reaching a low memory threshold.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/common/domctl.c               |   8 +++++-
 xen/arch/x86/mm/mem_event.c       |   5 ++-
 xen/include/asm-x86/mem_event.h   |  30 ++++++++++++++++++---
 xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
 xen/arch/x86/mm.c                 |   8 +++--
 xen/arch/x86/mm/mem_sharing.c     |  52 ++++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
 xen/common/grant_table.c          |  11 ++++---
 xen/common/memory.c               |   1 +
 xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
 xen/common/page_alloc.c           |  10 +++++++
 xen/include/public/xen.h          |   1 +
 12 files changed, 140 insertions(+), 39 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTj-0003aS-83; Thu, 16 Feb 2012 03:57:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTg-0003Y5-Md
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329364665!15001598!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8312 invoked from network); 16 Feb 2012 03:57:45 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 03:57:45 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id DB3CC380078;
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JxeznE4IA6+dwxXofWh7Fd7BzoiqVxF4WVahTrXVs+aT
	S3JVDakQZWZmJhMaYUtwFyR75Jhd51bblRNVSqmeTPzW5ye/O0nPAIcgB7IBRJbK
	PQ75sdj69kt+pYWUpw1bhycEht9pTOhEzUkQ2DuMmtiY3MVgTfTcRcINYMaY1WM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=beNzAyFjxY9XC+eaGUxXwtllbUc=; b=f3ydUAWQ8uo
	9YfzDfJv6rYkCicjA1rRefChsasYS22DWUUTs2WhG5iB5G5A0CZx1NFu08n+lp2u
	9+z3abopKRQBVfVH8AgYSb+YWOwOEIWz3V/iw4a/g+OgRRnjfLAdDW7c9iQaigjv
	VcIQZvr+MxpNVhupO38rROUCTpOSr5KQ=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 4ED8338006F; 
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 407b5ac709aa3d4e0030889d5116500edc61300a
Message-Id: <407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 4] Memory sharing: better handling of
 ENOMEM while unsharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
 xen/arch/x86/mm.c                 |   8 +++--
 xen/arch/x86/mm/mem_sharing.c     |  52 ++++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
 xen/common/grant_table.c          |  11 ++++---
 xen/common/memory.c               |   1 +
 xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
 7 files changed, 94 insertions(+), 31 deletions(-)


If unsharing fails with ENOMEM, we were:
 - leaving the list of gfns backed by the shared page in an inconsistent state
 - cycling forever on the hap page fault handler.
 - Attempting to produce a mem event (which could sleep on a wait queue)
   while holding locks.
 - Not checking, for all callers, that unshare could have indeed failed.

Fix bugs above, and sanitize callers to place a ring event in an unlocked
context, or without requiring to go to sleep on a wait queue.

A note on the rationale for unshare error handling:
 1. Unshare can only fail with ENOMEM. Any other error conditions BUG_ON()'s
 2. We notify a potential dom0 helper through a mem_event ring. But we
    allow the notification to not go to sleep. If the event ring is full
    of ENOMEM warnings, then the helper will already have been kicked enough.
 3. We cannot "just" go to sleep until the unshare is resolved, because we
    might be buried deep into locks (e.g. something -> copy_to_user ->
    __hvm_copy)
 4. So, we make sure we:
    4.1. return an error
    4.2. do not corrupt shared memory
    4.3. do not corrupt guest memory
    4.4. let the guest deal with the error if propagation will reach that far

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1196,7 +1196,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc, fall_through = 0, paged = 0;
+    int rc, fall_through = 0, paged = 0, sharing_enomem = 0;
     mem_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
@@ -1305,7 +1305,8 @@ int hvm_hap_nested_page_fault(unsigned l
     if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        mem_sharing_unshare_page(p2m->domain, gfn, 0);
+        sharing_enomem = 
+            (mem_sharing_unshare_page(p2m->domain, gfn, 0) < 0);
         rc = 1;
         goto out_put_gfn;
     }
@@ -1345,8 +1346,23 @@ int hvm_hap_nested_page_fault(unsigned l
 
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
+    /* All of these are delayed until we exit, since we might 
+     * sleep on event ring wait queues, and we must not hold
+     * locks in such circumstance */
     if ( paged )
         p2m_mem_paging_populate(v->domain, gfn);
+    if ( sharing_enomem )
+    {
+        int rv;
+        if ( (rv = mem_sharing_notify_enomem(v->domain, gfn, 1)) < 0 )
+        {
+            gdprintk(XENLOG_ERR, "Domain %hu attempt to unshare "
+                     "gfn %lx, ENOMEM and no helper (rc %d)\n",
+                        v->domain->domain_id, gfn, rv);
+            /* Crash the domain */
+            rc = 0;
+        }
+    }
     if ( req_ptr )
     {
         mem_access_send_req(v->domain, req_ptr);
diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3589,12 +3589,14 @@ int do_mmu_update(
                         /* Unshare the page for RW foreign mappings */
                         if ( l1e_get_flags(l1e) & _PAGE_RW )
                         {
-                            rc = mem_sharing_unshare_page(pg_owner, 
-                                                          l1e_get_pfn(l1e), 
-                                                          0);
+                            unsigned long gfn = l1e_get_pfn(l1e);
+                            rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
                             if ( rc )
                             {
                                 put_gfn(pg_owner, l1egfn);
+                                /* Notify helper, don't care about errors, will not
+                                 * sleep on wq, since we're a foreign domain. */
+                                (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
                                 break; 
                             }
                         }
diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -343,35 +343,30 @@ int mem_sharing_audit(void)
 #endif
 
 
-static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
+int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
+                                bool_t allow_sleep) 
 {
     struct vcpu *v = current;
+    int rc;
     mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
-    if ( v->domain != d )
+    if ( (rc = __mem_event_claim_slot(d, 
+                        &d->mem_event->share, allow_sleep)) < 0 )
+        return rc;
+
+    if ( v->domain == d )
     {
-        /* XXX This path needs some attention.  For now, just fail foreign 
-         * XXX requests to unshare if there's no memory.  This replaces 
-         * XXX old code that BUG()ed here; the callers now BUG()
-         * XXX elewhere. */
-        gdprintk(XENLOG_ERR, 
-                 "Failed alloc on unshare path for foreign (%d) lookup\n",
-                 d->domain_id);
-        return;
+        req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
+        vcpu_pause_nosync(v);
     }
 
-    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
-    {
-        return;
-    }
-
-    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
-    vcpu_pause_nosync(v);
-
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
+
     mem_event_put_request(d, &d->mem_event->share, &req);
+
+    return 0;
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -903,6 +898,20 @@ err_out:
     return ret;
 }
 
+
+/* A note on the rationale for unshare error handling:
+ *  1. Unshare can only fail with ENOMEM. Any other error conditions BUG_ON()'s
+ *  2. We notify a potential dom0 helper through a mem_event ring. But we
+ *     allow the notification to not go to sleep. If the event ring is full 
+ *     of ENOMEM warnings, then it's on the ball.
+ *  3. We cannot go to sleep until the unshare is resolved, because we might
+ *     be buried deep into locks (e.g. something -> copy_to_user -> __hvm_copy) 
+ *  4. So, we make sure we:
+ *     4.1. return an error
+ *     4.2. do not corrupt shared memory
+ *     4.3. do not corrupt guest memory
+ *     4.4. let the guest deal with it if the error propagation will reach it
+ */
 int mem_sharing_unshare_page(struct domain *d,
                              unsigned long gfn, 
                              uint16_t flags)
@@ -945,7 +954,6 @@ gfn_found:
     /* Do the accounting first. If anything fails below, we have bigger
      * bigger fish to fry. First, remove the gfn from the list. */ 
     last_gfn = list_has_one_entry(&page->sharing->gfns);
-    mem_sharing_gfn_destroy(d, gfn_info);
     if ( last_gfn )
     {
         /* Clean up shared state */
@@ -959,6 +967,7 @@ gfn_found:
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
+        mem_sharing_gfn_destroy(d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -971,6 +980,7 @@ gfn_found:
  
     if ( last_gfn )
     {
+        mem_sharing_gfn_destroy(d, gfn_info);
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
@@ -982,7 +992,8 @@ gfn_found:
     {
         mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
-        mem_sharing_notify_helper(d, gfn);
+        /* Caller is responsible for placing an event
+         * in the ring */
         return -ENOMEM;
     }
 
@@ -993,6 +1004,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
+    mem_sharing_gfn_destroy(d, gfn_info);
     mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 
diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -170,7 +170,10 @@ mfn_t __get_gfn_type_access(struct p2m_d
     if ( q == p2m_unshare && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        mem_sharing_unshare_page(p2m->domain, gfn, 0);
+        /* Try to unshare. If we fail, communicate ENOMEM without
+         * sleeping. */
+        if ( mem_sharing_unshare_page(p2m->domain, gfn, 0) < 0 )
+            (void)mem_sharing_notify_enomem(p2m->domain, gfn, 0);
         mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
     }
 #endif
@@ -371,6 +374,7 @@ void p2m_teardown(struct p2m_domain *p2m
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
+            /* Does not fail with ENOMEM given the DESTROY flag */
             BUG_ON(mem_sharing_unshare_page(d, gfn, MEM_SHARING_DESTROY_GFN));
         }
     }
@@ -510,6 +514,18 @@ guest_physmap_add_entry(struct domain *d
             if ( rc )
             {
                 p2m_unlock(p2m);
+                /* NOTE: Should a guest domain bring this upon itself,
+                 * there is not a whole lot we can do. We are buried
+                 * deep in locks from most code paths by now. So, fail
+                 * the call and don't try to sleep on a wait queue
+                 * while placing the mem event.
+                 *
+                 * However, all current (changeset 3432abcf9380) code
+                 * paths avoid this unsavoury situation. For now.
+                 *
+                 * Foreign domains are okay to place an event as they 
+                 * won't go to sleep. */
+                (void)mem_sharing_notify_enomem(p2m->domain, gfn + i, 0);
                 return rc;
             }
             omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
diff -r 09746decbd28 -r 407b5ac709aa xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -112,8 +112,7 @@ static unsigned inline int max_nr_maptra
     p2m_type_t __p2mt;                                      \
     unsigned long __x;                                      \
     __x = mfn_x(get_gfn_unshare((_d), (_gfn), &__p2mt));    \
-    BUG_ON(p2m_is_shared(__p2mt)); /* XXX fixme */          \
-    if ( !p2m_is_valid(__p2mt) )                            \
+    if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) )   \
         __x = INVALID_MFN;                                  \
     __x; })
 #else
@@ -155,9 +154,11 @@ static int __get_paged_frame(unsigned lo
     else
     {
         mfn = get_gfn_unshare(rd, gfn, &p2mt);
-        BUG_ON(p2m_is_shared(p2mt));
-        /* XXX Here, and above in gfn_to_mfn_private, need to handle
-         * XXX failure to unshare. */
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(rd, gfn);
+            return GNTST_eagain;
+        }
     }
 
     if ( p2m_is_valid(p2mt) ) {
diff -r 09746decbd28 -r 407b5ac709aa xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -200,6 +200,7 @@ int guest_remove_page(struct domain *d, 
         if ( mem_sharing_unshare_page(d, gmfn, 0) )
         {
             put_gfn(d, gmfn);
+            (void)mem_sharing_notify_enomem(d, gmfn, 0);
             return 0;
         }
         /* Maybe the mfn changed */
diff -r 09746decbd28 -r 407b5ac709aa xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -53,9 +53,24 @@ int mem_sharing_nominate_page(struct dom
                               int expected_refcnt,
                               shr_handle_t *phandle);
 #define MEM_SHARING_DESTROY_GFN       (1<<1)
+/* Only fails with -ENOMEM */
 int mem_sharing_unshare_page(struct domain *d, 
                              unsigned long gfn, 
                              uint16_t flags);
+/* If called by a foreign domain, possible errors are
+ *   -EBUSY -> ring full
+ *   -ENOSYS -> no ring to begin with
+ * and the foreign mapper is responsible for retrying.
+ *
+ * If called by the guest vcpu itself and allow_sleep is set, may 
+ * sleep on a wait queue, so the caller is responsible for not 
+ * holding locks on entry. It may only fail with ENOSYS 
+ *
+ * If called by the guest vcpu itself and allow_sleep is not set,
+ * then it's the same as a foreign domain.
+ */
+int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
+                                bool_t allow_sleep);
 int mem_sharing_sharing_resume(struct domain *d);
 int mem_sharing_memop(struct domain *d, 
                        xen_mem_sharing_op_t *mec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03: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.xensource.com>)
	id 1RxsTj-0003aS-83; Thu, 16 Feb 2012 03:57:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTg-0003Y5-Md
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329364665!15001598!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDg0NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8312 invoked from network); 16 Feb 2012 03:57:45 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 03:57:45 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id DB3CC380078;
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JxeznE4IA6+dwxXofWh7Fd7BzoiqVxF4WVahTrXVs+aT
	S3JVDakQZWZmJhMaYUtwFyR75Jhd51bblRNVSqmeTPzW5ye/O0nPAIcgB7IBRJbK
	PQ75sdj69kt+pYWUpw1bhycEht9pTOhEzUkQ2DuMmtiY3MVgTfTcRcINYMaY1WM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=beNzAyFjxY9XC+eaGUxXwtllbUc=; b=f3ydUAWQ8uo
	9YfzDfJv6rYkCicjA1rRefChsasYS22DWUUTs2WhG5iB5G5A0CZx1NFu08n+lp2u
	9+z3abopKRQBVfVH8AgYSb+YWOwOEIWz3V/iw4a/g+OgRRnjfLAdDW7c9iQaigjv
	VcIQZvr+MxpNVhupO38rROUCTpOSr5KQ=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 4ED8338006F; 
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 407b5ac709aa3d4e0030889d5116500edc61300a
Message-Id: <407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 4] Memory sharing: better handling of
 ENOMEM while unsharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
 xen/arch/x86/mm.c                 |   8 +++--
 xen/arch/x86/mm/mem_sharing.c     |  52 ++++++++++++++++++++++++---------------
 xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
 xen/common/grant_table.c          |  11 ++++---
 xen/common/memory.c               |   1 +
 xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
 7 files changed, 94 insertions(+), 31 deletions(-)


If unsharing fails with ENOMEM, we were:
 - leaving the list of gfns backed by the shared page in an inconsistent state
 - cycling forever on the hap page fault handler.
 - Attempting to produce a mem event (which could sleep on a wait queue)
   while holding locks.
 - Not checking, for all callers, that unshare could have indeed failed.

Fix bugs above, and sanitize callers to place a ring event in an unlocked
context, or without requiring to go to sleep on a wait queue.

A note on the rationale for unshare error handling:
 1. Unshare can only fail with ENOMEM. Any other error conditions BUG_ON()'s
 2. We notify a potential dom0 helper through a mem_event ring. But we
    allow the notification to not go to sleep. If the event ring is full
    of ENOMEM warnings, then the helper will already have been kicked enough.
 3. We cannot "just" go to sleep until the unshare is resolved, because we
    might be buried deep into locks (e.g. something -> copy_to_user ->
    __hvm_copy)
 4. So, we make sure we:
    4.1. return an error
    4.2. do not corrupt shared memory
    4.3. do not corrupt guest memory
    4.4. let the guest deal with the error if propagation will reach that far

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1196,7 +1196,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn_t mfn;
     struct vcpu *v = current;
     struct p2m_domain *p2m;
-    int rc, fall_through = 0, paged = 0;
+    int rc, fall_through = 0, paged = 0, sharing_enomem = 0;
     mem_event_request_t *req_ptr = NULL;
 
     /* On Nested Virtualization, walk the guest page table.
@@ -1305,7 +1305,8 @@ int hvm_hap_nested_page_fault(unsigned l
     if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        mem_sharing_unshare_page(p2m->domain, gfn, 0);
+        sharing_enomem = 
+            (mem_sharing_unshare_page(p2m->domain, gfn, 0) < 0);
         rc = 1;
         goto out_put_gfn;
     }
@@ -1345,8 +1346,23 @@ int hvm_hap_nested_page_fault(unsigned l
 
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
+    /* All of these are delayed until we exit, since we might 
+     * sleep on event ring wait queues, and we must not hold
+     * locks in such circumstance */
     if ( paged )
         p2m_mem_paging_populate(v->domain, gfn);
+    if ( sharing_enomem )
+    {
+        int rv;
+        if ( (rv = mem_sharing_notify_enomem(v->domain, gfn, 1)) < 0 )
+        {
+            gdprintk(XENLOG_ERR, "Domain %hu attempt to unshare "
+                     "gfn %lx, ENOMEM and no helper (rc %d)\n",
+                        v->domain->domain_id, gfn, rv);
+            /* Crash the domain */
+            rc = 0;
+        }
+    }
     if ( req_ptr )
     {
         mem_access_send_req(v->domain, req_ptr);
diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3589,12 +3589,14 @@ int do_mmu_update(
                         /* Unshare the page for RW foreign mappings */
                         if ( l1e_get_flags(l1e) & _PAGE_RW )
                         {
-                            rc = mem_sharing_unshare_page(pg_owner, 
-                                                          l1e_get_pfn(l1e), 
-                                                          0);
+                            unsigned long gfn = l1e_get_pfn(l1e);
+                            rc = mem_sharing_unshare_page(pg_owner, gfn, 0); 
                             if ( rc )
                             {
                                 put_gfn(pg_owner, l1egfn);
+                                /* Notify helper, don't care about errors, will not
+                                 * sleep on wq, since we're a foreign domain. */
+                                (void)mem_sharing_notify_enomem(pg_owner, gfn, 0);
                                 break; 
                             }
                         }
diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -343,35 +343,30 @@ int mem_sharing_audit(void)
 #endif
 
 
-static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
+int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
+                                bool_t allow_sleep) 
 {
     struct vcpu *v = current;
+    int rc;
     mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
 
-    if ( v->domain != d )
+    if ( (rc = __mem_event_claim_slot(d, 
+                        &d->mem_event->share, allow_sleep)) < 0 )
+        return rc;
+
+    if ( v->domain == d )
     {
-        /* XXX This path needs some attention.  For now, just fail foreign 
-         * XXX requests to unshare if there's no memory.  This replaces 
-         * XXX old code that BUG()ed here; the callers now BUG()
-         * XXX elewhere. */
-        gdprintk(XENLOG_ERR, 
-                 "Failed alloc on unshare path for foreign (%d) lookup\n",
-                 d->domain_id);
-        return;
+        req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
+        vcpu_pause_nosync(v);
     }
 
-    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
-    {
-        return;
-    }
-
-    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
-    vcpu_pause_nosync(v);
-
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
+
     mem_event_put_request(d, &d->mem_event->share, &req);
+
+    return 0;
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -903,6 +898,20 @@ err_out:
     return ret;
 }
 
+
+/* A note on the rationale for unshare error handling:
+ *  1. Unshare can only fail with ENOMEM. Any other error conditions BUG_ON()'s
+ *  2. We notify a potential dom0 helper through a mem_event ring. But we
+ *     allow the notification to not go to sleep. If the event ring is full 
+ *     of ENOMEM warnings, then it's on the ball.
+ *  3. We cannot go to sleep until the unshare is resolved, because we might
+ *     be buried deep into locks (e.g. something -> copy_to_user -> __hvm_copy) 
+ *  4. So, we make sure we:
+ *     4.1. return an error
+ *     4.2. do not corrupt shared memory
+ *     4.3. do not corrupt guest memory
+ *     4.4. let the guest deal with it if the error propagation will reach it
+ */
 int mem_sharing_unshare_page(struct domain *d,
                              unsigned long gfn, 
                              uint16_t flags)
@@ -945,7 +954,6 @@ gfn_found:
     /* Do the accounting first. If anything fails below, we have bigger
      * bigger fish to fry. First, remove the gfn from the list. */ 
     last_gfn = list_has_one_entry(&page->sharing->gfns);
-    mem_sharing_gfn_destroy(d, gfn_info);
     if ( last_gfn )
     {
         /* Clean up shared state */
@@ -959,6 +967,7 @@ gfn_found:
      * (possibly freeing the page), and exit early */
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
+        mem_sharing_gfn_destroy(d, gfn_info);
         put_page_and_type(page);
         mem_sharing_page_unlock(page);
         if ( last_gfn && 
@@ -971,6 +980,7 @@ gfn_found:
  
     if ( last_gfn )
     {
+        mem_sharing_gfn_destroy(d, gfn_info);
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
@@ -982,7 +992,8 @@ gfn_found:
     {
         mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
-        mem_sharing_notify_helper(d, gfn);
+        /* Caller is responsible for placing an event
+         * in the ring */
         return -ENOMEM;
     }
 
@@ -993,6 +1004,7 @@ gfn_found:
     unmap_domain_page(t);
 
     BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)) == 0);
+    mem_sharing_gfn_destroy(d, gfn_info);
     mem_sharing_page_unlock(old_page);
     put_page_and_type(old_page);
 
diff -r 09746decbd28 -r 407b5ac709aa xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -170,7 +170,10 @@ mfn_t __get_gfn_type_access(struct p2m_d
     if ( q == p2m_unshare && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
-        mem_sharing_unshare_page(p2m->domain, gfn, 0);
+        /* Try to unshare. If we fail, communicate ENOMEM without
+         * sleeping. */
+        if ( mem_sharing_unshare_page(p2m->domain, gfn, 0) < 0 )
+            (void)mem_sharing_notify_enomem(p2m->domain, gfn, 0);
         mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
     }
 #endif
@@ -371,6 +374,7 @@ void p2m_teardown(struct p2m_domain *p2m
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
+            /* Does not fail with ENOMEM given the DESTROY flag */
             BUG_ON(mem_sharing_unshare_page(d, gfn, MEM_SHARING_DESTROY_GFN));
         }
     }
@@ -510,6 +514,18 @@ guest_physmap_add_entry(struct domain *d
             if ( rc )
             {
                 p2m_unlock(p2m);
+                /* NOTE: Should a guest domain bring this upon itself,
+                 * there is not a whole lot we can do. We are buried
+                 * deep in locks from most code paths by now. So, fail
+                 * the call and don't try to sleep on a wait queue
+                 * while placing the mem event.
+                 *
+                 * However, all current (changeset 3432abcf9380) code
+                 * paths avoid this unsavoury situation. For now.
+                 *
+                 * Foreign domains are okay to place an event as they 
+                 * won't go to sleep. */
+                (void)mem_sharing_notify_enomem(p2m->domain, gfn + i, 0);
                 return rc;
             }
             omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
diff -r 09746decbd28 -r 407b5ac709aa xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -112,8 +112,7 @@ static unsigned inline int max_nr_maptra
     p2m_type_t __p2mt;                                      \
     unsigned long __x;                                      \
     __x = mfn_x(get_gfn_unshare((_d), (_gfn), &__p2mt));    \
-    BUG_ON(p2m_is_shared(__p2mt)); /* XXX fixme */          \
-    if ( !p2m_is_valid(__p2mt) )                            \
+    if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) )   \
         __x = INVALID_MFN;                                  \
     __x; })
 #else
@@ -155,9 +154,11 @@ static int __get_paged_frame(unsigned lo
     else
     {
         mfn = get_gfn_unshare(rd, gfn, &p2mt);
-        BUG_ON(p2m_is_shared(p2mt));
-        /* XXX Here, and above in gfn_to_mfn_private, need to handle
-         * XXX failure to unshare. */
+        if ( p2m_is_shared(p2mt) )
+        {
+            put_gfn(rd, gfn);
+            return GNTST_eagain;
+        }
     }
 
     if ( p2m_is_valid(p2mt) ) {
diff -r 09746decbd28 -r 407b5ac709aa xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -200,6 +200,7 @@ int guest_remove_page(struct domain *d, 
         if ( mem_sharing_unshare_page(d, gmfn, 0) )
         {
             put_gfn(d, gmfn);
+            (void)mem_sharing_notify_enomem(d, gmfn, 0);
             return 0;
         }
         /* Maybe the mfn changed */
diff -r 09746decbd28 -r 407b5ac709aa xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -53,9 +53,24 @@ int mem_sharing_nominate_page(struct dom
                               int expected_refcnt,
                               shr_handle_t *phandle);
 #define MEM_SHARING_DESTROY_GFN       (1<<1)
+/* Only fails with -ENOMEM */
 int mem_sharing_unshare_page(struct domain *d, 
                              unsigned long gfn, 
                              uint16_t flags);
+/* If called by a foreign domain, possible errors are
+ *   -EBUSY -> ring full
+ *   -ENOSYS -> no ring to begin with
+ * and the foreign mapper is responsible for retrying.
+ *
+ * If called by the guest vcpu itself and allow_sleep is set, may 
+ * sleep on a wait queue, so the caller is responsible for not 
+ * holding locks on entry. It may only fail with ENOSYS 
+ *
+ * If called by the guest vcpu itself and allow_sleep is not set,
+ * then it's the same as a foreign domain.
+ */
+int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
+                                bool_t allow_sleep);
 int mem_sharing_sharing_resume(struct domain *d);
 int mem_sharing_memop(struct domain *d, 
                        xen_mem_sharing_op_t *mec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsTb-0003Y6-DW; Thu, 16 Feb 2012 03:57:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTa-0003Xc-1y
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:46 +0000
Received: from [85.158.139.83:44428] by server-2.bemta-5.messagelabs.com id
	85/45-20263-9BE7C3F4; Thu, 16 Feb 2012 03:57:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329364663!15209256!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTQ3OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14803 invoked from network); 16 Feb 2012 03:57:44 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 03:57:44 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 21FA8380077;
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=f4cGDRrCf3MWcn3XE7+rwqMPINkWHF4dRZ2rcWdE3Y9Y
	Elv5NJBTkMxqzX9FKc/nZVa85b06mDPQtsnwhneln8jGt6MOOazVrnLHTJruELbW
	zHciW+p/Z7fICcoeTcb57M/wmidkYBcN9iGwZV6sY8KYkgeFa60GjjuAKFyBmXU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Wc3VTmLR3+ZkRs2acixBafsPXTk=; b=Ql3+jjPjWFO
	06kPpUklUz9Zpj43SCESZUpNZgcBmHJ4ZznkuXRqGlX5SHvGcnob4x2GRE3POkxO
	XvIKFPc2EdhAY6u1HjuWXLtUltXURCBfq1kPtWLU3AQedRcU24mAbNGprAUf8+Qy
	PTnUqYzWRQM27NlYKm7g9yPap24Kx+jA=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id A97EF38006F; 
	Wed, 15 Feb 2012 19:57:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 09746decbd28309ff25c9e485c7c84b0d5ff06b8
Message-Id: <09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:05 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 4] x86/mm: Allow to not sleep on mem event
	ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c     |   5 +++--
 xen/include/asm-x86/mem_event.h |  30 +++++++++++++++++++++++++-----
 2 files changed, 28 insertions(+), 7 deletions(-)


Under extreme congestion conditions, generating a mem event may put the vcpu to
sleep on a wait queue if the ring is full. This is generally desirable, although
fairly convoluted to work with, since sleeping on a wait queue requires a
non-atomic context (i.e. no locks held).

Introduce an allow_sleep flag to make this optional. The API remains such that
all current callers set allow_sleep to true and thus will sleep if necessary.

The end-use is for cases in which loss of guest mem events is tolerable. One
such consumer to be added later is the unsharing code under ENOMEM conditions.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 11fd4e0a1e1a -r 09746decbd28 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -441,9 +441,10 @@ bool_t mem_event_check_ring(struct mem_e
  *               0: a spot has been reserved
  *
  */
-int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
+int __mem_event_claim_slot(struct domain *d, struct mem_event_domain *med,
+                            bool_t allow_sleep)
 {
-    if ( current->domain == d )
+    if ( (current->domain == d) && allow_sleep )
         return mem_event_wait_slot(med);
     else
         return mem_event_grab_slot(med, 1);
diff -r 11fd4e0a1e1a -r 09746decbd28 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -28,11 +28,31 @@
 bool_t mem_event_check_ring(struct mem_event_domain *med);
 
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
- * available space. For success or -EBUSY, the vCPU may be left blocked
- * temporarily to ensure that the ring does not lose future events.  In
- * general, you must follow a claim_slot() call with either put_request() or
- * cancel_slot(), both of which are guaranteed to succeed. */
-int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+ * available space and the caller is a foreign domain. If the guest itself
+ * is the caller, -EBUSY is avoided by sleeping on a wait queue to ensure
+ * that the ring does not lose future events. 
+ *
+ * However, the allow_sleep flag can be set to false in cases in which it is ok
+ * to lose future events, and thus -EBUSY can be returned to guest vcpus
+ * (handle with care!). 
+ *
+ * In general, you must follow a claim_slot() call with either put_request() or
+ * cancel_slot(), both of which are guaranteed to
+ * succeed. 
+ */
+int __mem_event_claim_slot(struct domain *d, struct mem_event_domain *med,
+                            bool_t allow_sleep);
+static inline int mem_event_claim_slot(struct domain *d, 
+                                        struct mem_event_domain *med)
+{
+    return __mem_event_claim_slot(d, med, 1);
+}
+
+static inline int mem_event_claim_slot_nosleep(struct domain *d,
+                                        struct mem_event_domain *med)
+{
+    return __mem_event_claim_slot(d, med, 0);
+}
 
 void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 03:58:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 03:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxsTb-0003Y6-DW; Thu, 16 Feb 2012 03:57:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RxsTa-0003Xc-1y
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 03:57:46 +0000
Received: from [85.158.139.83:44428] by server-2.bemta-5.messagelabs.com id
	85/45-20263-9BE7C3F4; Thu, 16 Feb 2012 03:57:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329364663!15209256!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTQ3OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14803 invoked from network); 16 Feb 2012 03:57:44 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 03:57:44 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 21FA8380077;
	Wed, 15 Feb 2012 19:57:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=f4cGDRrCf3MWcn3XE7+rwqMPINkWHF4dRZ2rcWdE3Y9Y
	Elv5NJBTkMxqzX9FKc/nZVa85b06mDPQtsnwhneln8jGt6MOOazVrnLHTJruELbW
	zHciW+p/Z7fICcoeTcb57M/wmidkYBcN9iGwZV6sY8KYkgeFa60GjjuAKFyBmXU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Wc3VTmLR3+ZkRs2acixBafsPXTk=; b=Ql3+jjPjWFO
	06kPpUklUz9Zpj43SCESZUpNZgcBmHJ4ZznkuXRqGlX5SHvGcnob4x2GRE3POkxO
	XvIKFPc2EdhAY6u1HjuWXLtUltXURCBfq1kPtWLU3AQedRcU24mAbNGprAUf8+Qy
	PTnUqYzWRQM27NlYKm7g9yPap24Kx+jA=
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-a17.g.dreamhost.com (Postfix) with ESMTPSA id A97EF38006F; 
	Wed, 15 Feb 2012 19:57:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 09746decbd28309ff25c9e485c7c84b0d5ff06b8
Message-Id: <09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 15 Feb 2012 22:57:05 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 4] x86/mm: Allow to not sleep on mem event
	ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c     |   5 +++--
 xen/include/asm-x86/mem_event.h |  30 +++++++++++++++++++++++++-----
 2 files changed, 28 insertions(+), 7 deletions(-)


Under extreme congestion conditions, generating a mem event may put the vcpu to
sleep on a wait queue if the ring is full. This is generally desirable, although
fairly convoluted to work with, since sleeping on a wait queue requires a
non-atomic context (i.e. no locks held).

Introduce an allow_sleep flag to make this optional. The API remains such that
all current callers set allow_sleep to true and thus will sleep if necessary.

The end-use is for cases in which loss of guest mem events is tolerable. One
such consumer to be added later is the unsharing code under ENOMEM conditions.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 11fd4e0a1e1a -r 09746decbd28 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -441,9 +441,10 @@ bool_t mem_event_check_ring(struct mem_e
  *               0: a spot has been reserved
  *
  */
-int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
+int __mem_event_claim_slot(struct domain *d, struct mem_event_domain *med,
+                            bool_t allow_sleep)
 {
-    if ( current->domain == d )
+    if ( (current->domain == d) && allow_sleep )
         return mem_event_wait_slot(med);
     else
         return mem_event_grab_slot(med, 1);
diff -r 11fd4e0a1e1a -r 09746decbd28 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -28,11 +28,31 @@
 bool_t mem_event_check_ring(struct mem_event_domain *med);
 
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
- * available space. For success or -EBUSY, the vCPU may be left blocked
- * temporarily to ensure that the ring does not lose future events.  In
- * general, you must follow a claim_slot() call with either put_request() or
- * cancel_slot(), both of which are guaranteed to succeed. */
-int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+ * available space and the caller is a foreign domain. If the guest itself
+ * is the caller, -EBUSY is avoided by sleeping on a wait queue to ensure
+ * that the ring does not lose future events. 
+ *
+ * However, the allow_sleep flag can be set to false in cases in which it is ok
+ * to lose future events, and thus -EBUSY can be returned to guest vcpus
+ * (handle with care!). 
+ *
+ * In general, you must follow a claim_slot() call with either put_request() or
+ * cancel_slot(), both of which are guaranteed to
+ * succeed. 
+ */
+int __mem_event_claim_slot(struct domain *d, struct mem_event_domain *med,
+                            bool_t allow_sleep);
+static inline int mem_event_claim_slot(struct domain *d, 
+                                        struct mem_event_domain *med)
+{
+    return __mem_event_claim_slot(d, med, 1);
+}
+
+static inline int mem_event_claim_slot_nosleep(struct domain *d,
+                                        struct mem_event_domain *med)
+{
+    return __mem_event_claim_slot(d, med, 0);
+}
 
 void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 05:20:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 05:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxtl2-0006Go-PE; Thu, 16 Feb 2012 05:19:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rxtl1-0006Gb-Gd
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 05:19:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329369584!13569848!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTQ2ODY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32230 invoked from network); 16 Feb 2012 05:19:44 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a11.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 05:19:44 -0000
Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id F29D16E064;
	Wed, 15 Feb 2012 21:19:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=g4QXbSgcHIYqyTgOXAQblz1S5JQfaAF8JM35gtEMyIfk
	e5hiRW/N/M7X7yWzAp3MCKy57u6gleIYJHqzlmoK22LLS4lGNFOxW3IpUuBVlOzP
	71diLGf7CJ+np+OPcA+0erWFNHa2O2bxqk3NrDdo/vKUsdHWUw7LCeVqatpQhqA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ZzZuTaskKbr+CFn3kjmYnz8mRvs=; b=SR81LcGM
	URtO3fyqDScxKcNXR6pqe08OayGoQ7REol1DPDrWRlrxZpeOT1OCaEsPapMHuJDm
	ZnhSGORJfKJKHjyzWeVTmudaBnaRR3GKZCVu7B18DGjJ6Mh7NM9AI7pZUZtiQn4d
	P0/FeJqI5xBRXbSY+FFE+AloCnTBrQp3f7A=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id 99B9D6E063;
	Wed, 15 Feb 2012 21:19:43 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 21:19:43 -0800
Message-ID: <22d867d77cdc8e718fd3c0ae20ec4396.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <000001ccec53$12f70100$38e50300$@com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<000001ccec53$12f70100$38e50300$@com>
Date: Wed, 15 Feb 2012 21:19:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Hongkaixing" <hongkaixing@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, tim@xen.org, bicky.shi@huawei.com,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres
>> Lagar-Cavilla
>> Sent: Wednesday, February 15, 2012 3:05 AM
>> To: xen-devel@lists.xensource.com
>> Cc: olaf@aepfle.de; keir.xen@gmail.com; tim@xen.org; JBeulich@suse.com;
>> adin@gridcentric.ca
>> Subject: [Xen-devel] RFC: AMD support for paging
>>
>> We started hashing out some AMD support for mem_paging and mem_access.
>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>> fault.
>>
>> Most importantly, I want to get somebody from AMD to comment/help out on
>> this. It feels like we're inches away from enabling support for this
>> very
>> nice feature. I'm not sure who exactly on AMD monitors the list for
>> these
>> kinds of things. It'd be great to have you on board!
>>
>> For starters, the changes to the p2m code are relatively mild, but it'd
>> be
>> great if somebody spots a red flag.
>>
>> Another issue: comments indicate that bits 59-62 in NPT entries are used
>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>> (59)
>> would give us enough space to support mem_access. Right now we only have
>> 7
>> bits available for Xen flags and that is not enough for paging and
>> access.
>> Is bit 59 effectively reserved?
>>
>> Finally, the triple fault. Maybe I'm missing something obvious. Comments
>> welcome.
>>
>> Patch inline below, thanks!
>> Andres
>>
>> Enable AMD support for paging.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>>
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>              if ( !hap_enabled(d) )
>>                  break;
>>
>> -            /* Currently only EPT is supported */
>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> -                break;
>> -
>>              rc = -EXDEV;
>>              /* Disallow paging in a PoD guest */
>>              if ( p2m->pod.entry_count )
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -53,6 +53,20 @@
>>  #define P2M_BASE_FLAGS \
>>          (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>
>> +#ifdef __x86_64__
>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>> 0xff..ff
>> + * value tramples over the higher-order bits used for flags (NX, p2mt,
>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>> + * juggle for l1 entries only (no paging superpages!) */
>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>> +#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>> +                                INVALID_MFN : (mfn))
>> +#else
>> +#define clipped_mfn(mfn)    (mfn)
>> +#define unclip_mfn(mfn)     (mfn)
>> +#endif /* __x86_64__ */
>> +
>>  static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>  {
>>      unsigned long flags;
>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>      case p2m_invalid:
>>      case p2m_mmio_dm:
>>      case p2m_populate_on_demand:
>> +    case p2m_ram_paging_out:
>> +    case p2m_ram_paged:
>> +    case p2m_ram_paging_in:
>>      default:
>>          return flags;
>>      case p2m_ram_ro:
>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>                                        shift, max)) )
>>          return 0;
>>
>> -    /* PoD: Not present doesn't imply empty. */
>> +    /* PoD/paging: Not present doesn't imply empty. */
>>      if ( !l1e_get_flags(*p2m_entry) )
>>      {
>>          struct page_info *pg;
>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>                                     0, L1_PAGETABLE_ENTRIES);
>>          ASSERT(p2m_entry);
>>
>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>                                           p2m_type_to_flags(p2mt, mfn));
>>          else
>>              entry_content = l1e_empty();
>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>          if ( entry_content.l1 != 0 )
>>          {
>>              p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>          }
>>          /* level 1 entry */
>>          p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>> entry_content, 1);
>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>                             sizeof(l1e));
>>
>>      if ( ret == 0 ) {
>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>          p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>> +                (l1e_mfn == INVALID_MFN && p2m_is_paging(p2mt)) );
>>
>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>> -             == p2m_populate_on_demand )
>> +        if ( p2mt == p2m_populate_on_demand )
>>          {
>>              /* The read has succeeded, so we know that the mapping
>>               * exits at this point.  */
>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>          }
>>
>>          if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>> -            mfn = _mfn(l1e_get_pfn(l1e));
>> +            mfn = _mfn(l1e_mfn);
>>          else
>>              /* XXX see above */
>>              p2mt = p2m_mmio_dm;
>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>  pod_retry_l1:
>>      if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
>>      {
>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>          /* PoD: Try to populate */
>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>> p2m_populate_on_demand )
>> +        if ( l1t == p2m_populate_on_demand )
>>          {
>>              if ( q != p2m_query ) {
>>                  if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K,
>> q) )
>>                      goto pod_retry_l1;
>>              } else
>>                  *t = p2m_populate_on_demand;
>> +        } else {
>> +            if ( p2m_is_paging(l1t) )
>> +            {
>> +                *t = l1t;
>> +                /* No need to unclip due to check below */
>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>> +            }
>>          }
>>
>>          unmap_domain_page(l1e);
>> -        return _mfn(INVALID_MFN);
>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                    This means when p2mt is p2m_ram_paging_in, the mfn must
> be INVALID_MFN;
>                    But in p2m_type_to_flags,when p2m_ram_paging_in or
> p2m_ram_paged, the _PAGE_PRESENT is not set.

Your patch below looks reasonable. I'll give it a try.
Andres

>
> My idea shows like this:
> In p2m_gfn_to_mfn function:
> @@ -1370,6 +1379,7 @@
>      paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
>      l2_pgentry_t *l2e;
>      l1_pgentry_t *l1e;
> +    unsigned long flags;
>
>      ASSERT(paging_mode_translate(d));
>
> @@ -1455,7 +1465,8 @@
>      l1e = map_domain_page(mfn_x(mfn));
>      l1e += l1_table_offset(addr);
>  pod_retry_l1:
> -    if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
> +    flags = l1e_get_flags(*l1e);
> +    if ((( flags & _PAGE_PRESENT) == 0) &&
> (!p2m_is_paging(p2m_flags_to_type(flags))))
>      {
>          /* PoD: Try to populate */
>          if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
>         {
>             if ( q != p2m_query ) {
>                 if ( !p2m_pod_check_and_populate(p2m, gfn,
>                                                  (l1_pgentry_t *)l1e,
> PAGE_ORDER_4K, q) )
>                     goto pod_retry_l1;
>             } else
>                 *t = p2m_populate_on_demand;
>         }
>
>         unmap_domain_page(l1e);
>         return _mfn(INVALID_MFN);
>     }
>     mfn = _mfn(l1e_get_pfn(*l1e));
>     *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>     unmap_domain_page(l1e);
>
>
>
>
>>      }
>>      mfn = _mfn(l1e_get_pfn(*l1e));
>>      *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>                      flags = l1e_get_flags(l1e[i1]);
>>                      if ( p2m_flags_to_type(flags) != ot )
>>                          continue;
>> -                    mfn = l1e_get_pfn(l1e[i1]);
>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                      gfn = i1 + (i2 + (i3
>>  #if CONFIG_PAGING_LEVELS >= 4
>>  					+ (i4 * L3_PAGETABLE_ENTRIES)
>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>                             * L2_PAGETABLE_ENTRIES) *
>> L1_PAGETABLE_ENTRIES;
>>                      /* create a new 1le entry with the new type */
>>                      flags = p2m_type_to_flags(nt, _mfn(mfn));
>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>> flags);
>>                      p2m->write_p2m_entry(p2m, gfn, &l1e[i1],
>>                                           l1mfn, l1e_content, 1);
>>                  }
>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>                                  entry_count++;
>>                              continue;
>>                          }
>> -                        mfn = l1e_get_pfn(l1e[i1]);
>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                          ASSERT(mfn_valid(_mfn(mfn)));
>>                          m2pfn = get_gpfn_from_mfn(mfn);
>>                          if ( m2pfn != gfn &&
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 05:20:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 05:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxtl2-0006Go-PE; Thu, 16 Feb 2012 05:19:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rxtl1-0006Gb-Gd
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 05:19:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329369584!13569848!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTQ2ODY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32230 invoked from network); 16 Feb 2012 05:19:44 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a11.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-174.messagelabs.com with SMTP;
	16 Feb 2012 05:19:44 -0000
Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id F29D16E064;
	Wed, 15 Feb 2012 21:19:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=g4QXbSgcHIYqyTgOXAQblz1S5JQfaAF8JM35gtEMyIfk
	e5hiRW/N/M7X7yWzAp3MCKy57u6gleIYJHqzlmoK22LLS4lGNFOxW3IpUuBVlOzP
	71diLGf7CJ+np+OPcA+0erWFNHa2O2bxqk3NrDdo/vKUsdHWUw7LCeVqatpQhqA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ZzZuTaskKbr+CFn3kjmYnz8mRvs=; b=SR81LcGM
	URtO3fyqDScxKcNXR6pqe08OayGoQ7REol1DPDrWRlrxZpeOT1OCaEsPapMHuJDm
	ZnhSGORJfKJKHjyzWeVTmudaBnaRR3GKZCVu7B18DGjJ6Mh7NM9AI7pZUZtiQn4d
	P0/FeJqI5xBRXbSY+FFE+AloCnTBrQp3f7A=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id 99B9D6E063;
	Wed, 15 Feb 2012 21:19:43 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 15 Feb 2012 21:19:43 -0800
Message-ID: <22d867d77cdc8e718fd3c0ae20ec4396.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <000001ccec53$12f70100$38e50300$@com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<000001ccec53$12f70100$38e50300$@com>
Date: Wed, 15 Feb 2012 21:19:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Hongkaixing" <hongkaixing@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, tim@xen.org, bicky.shi@huawei.com,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres
>> Lagar-Cavilla
>> Sent: Wednesday, February 15, 2012 3:05 AM
>> To: xen-devel@lists.xensource.com
>> Cc: olaf@aepfle.de; keir.xen@gmail.com; tim@xen.org; JBeulich@suse.com;
>> adin@gridcentric.ca
>> Subject: [Xen-devel] RFC: AMD support for paging
>>
>> We started hashing out some AMD support for mem_paging and mem_access.
>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>> fault.
>>
>> Most importantly, I want to get somebody from AMD to comment/help out on
>> this. It feels like we're inches away from enabling support for this
>> very
>> nice feature. I'm not sure who exactly on AMD monitors the list for
>> these
>> kinds of things. It'd be great to have you on board!
>>
>> For starters, the changes to the p2m code are relatively mild, but it'd
>> be
>> great if somebody spots a red flag.
>>
>> Another issue: comments indicate that bits 59-62 in NPT entries are used
>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>> (59)
>> would give us enough space to support mem_access. Right now we only have
>> 7
>> bits available for Xen flags and that is not enough for paging and
>> access.
>> Is bit 59 effectively reserved?
>>
>> Finally, the triple fault. Maybe I'm missing something obvious. Comments
>> welcome.
>>
>> Patch inline below, thanks!
>> Andres
>>
>> Enable AMD support for paging.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>>
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>              if ( !hap_enabled(d) )
>>                  break;
>>
>> -            /* Currently only EPT is supported */
>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> -                break;
>> -
>>              rc = -EXDEV;
>>              /* Disallow paging in a PoD guest */
>>              if ( p2m->pod.entry_count )
>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -53,6 +53,20 @@
>>  #define P2M_BASE_FLAGS \
>>          (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>
>> +#ifdef __x86_64__
>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>> 0xff..ff
>> + * value tramples over the higher-order bits used for flags (NX, p2mt,
>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>> + * juggle for l1 entries only (no paging superpages!) */
>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>> +#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>> +                                INVALID_MFN : (mfn))
>> +#else
>> +#define clipped_mfn(mfn)    (mfn)
>> +#define unclip_mfn(mfn)     (mfn)
>> +#endif /* __x86_64__ */
>> +
>>  static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>  {
>>      unsigned long flags;
>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>      case p2m_invalid:
>>      case p2m_mmio_dm:
>>      case p2m_populate_on_demand:
>> +    case p2m_ram_paging_out:
>> +    case p2m_ram_paged:
>> +    case p2m_ram_paging_in:
>>      default:
>>          return flags;
>>      case p2m_ram_ro:
>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>                                        shift, max)) )
>>          return 0;
>>
>> -    /* PoD: Not present doesn't imply empty. */
>> +    /* PoD/paging: Not present doesn't imply empty. */
>>      if ( !l1e_get_flags(*p2m_entry) )
>>      {
>>          struct page_info *pg;
>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>                                     0, L1_PAGETABLE_ENTRIES);
>>          ASSERT(p2m_entry);
>>
>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>                                           p2m_type_to_flags(p2mt, mfn));
>>          else
>>              entry_content = l1e_empty();
>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>          if ( entry_content.l1 != 0 )
>>          {
>>              p2m_add_iommu_flags(&entry_content, 0, iommu_pte_flags);
>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>          }
>>          /* level 1 entry */
>>          p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>> entry_content, 1);
>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>                             sizeof(l1e));
>>
>>      if ( ret == 0 ) {
>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>          p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>> +                (l1e_mfn == INVALID_MFN && p2m_is_paging(p2mt)) );
>>
>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>> -             == p2m_populate_on_demand )
>> +        if ( p2mt == p2m_populate_on_demand )
>>          {
>>              /* The read has succeeded, so we know that the mapping
>>               * exits at this point.  */
>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>          }
>>
>>          if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>> -            mfn = _mfn(l1e_get_pfn(l1e));
>> +            mfn = _mfn(l1e_mfn);
>>          else
>>              /* XXX see above */
>>              p2mt = p2m_mmio_dm;
>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>  pod_retry_l1:
>>      if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
>>      {
>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>          /* PoD: Try to populate */
>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>> p2m_populate_on_demand )
>> +        if ( l1t == p2m_populate_on_demand )
>>          {
>>              if ( q != p2m_query ) {
>>                  if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K,
>> q) )
>>                      goto pod_retry_l1;
>>              } else
>>                  *t = p2m_populate_on_demand;
>> +        } else {
>> +            if ( p2m_is_paging(l1t) )
>> +            {
>> +                *t = l1t;
>> +                /* No need to unclip due to check below */
>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>> +            }
>>          }
>>
>>          unmap_domain_page(l1e);
>> -        return _mfn(INVALID_MFN);
>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                    This means when p2mt is p2m_ram_paging_in, the mfn must
> be INVALID_MFN;
>                    But in p2m_type_to_flags,when p2m_ram_paging_in or
> p2m_ram_paged, the _PAGE_PRESENT is not set.

Your patch below looks reasonable. I'll give it a try.
Andres

>
> My idea shows like this:
> In p2m_gfn_to_mfn function:
> @@ -1370,6 +1379,7 @@
>      paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
>      l2_pgentry_t *l2e;
>      l1_pgentry_t *l1e;
> +    unsigned long flags;
>
>      ASSERT(paging_mode_translate(d));
>
> @@ -1455,7 +1465,8 @@
>      l1e = map_domain_page(mfn_x(mfn));
>      l1e += l1_table_offset(addr);
>  pod_retry_l1:
> -    if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
> +    flags = l1e_get_flags(*l1e);
> +    if ((( flags & _PAGE_PRESENT) == 0) &&
> (!p2m_is_paging(p2m_flags_to_type(flags))))
>      {
>          /* PoD: Try to populate */
>          if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
>         {
>             if ( q != p2m_query ) {
>                 if ( !p2m_pod_check_and_populate(p2m, gfn,
>                                                  (l1_pgentry_t *)l1e,
> PAGE_ORDER_4K, q) )
>                     goto pod_retry_l1;
>             } else
>                 *t = p2m_populate_on_demand;
>         }
>
>         unmap_domain_page(l1e);
>         return _mfn(INVALID_MFN);
>     }
>     mfn = _mfn(l1e_get_pfn(*l1e));
>     *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>     unmap_domain_page(l1e);
>
>
>
>
>>      }
>>      mfn = _mfn(l1e_get_pfn(*l1e));
>>      *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>                      flags = l1e_get_flags(l1e[i1]);
>>                      if ( p2m_flags_to_type(flags) != ot )
>>                          continue;
>> -                    mfn = l1e_get_pfn(l1e[i1]);
>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                      gfn = i1 + (i2 + (i3
>>  #if CONFIG_PAGING_LEVELS >= 4
>>  					+ (i4 * L3_PAGETABLE_ENTRIES)
>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>                             * L2_PAGETABLE_ENTRIES) *
>> L1_PAGETABLE_ENTRIES;
>>                      /* create a new 1le entry with the new type */
>>                      flags = p2m_type_to_flags(nt, _mfn(mfn));
>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>> flags);
>>                      p2m->write_p2m_entry(p2m, gfn, &l1e[i1],
>>                                           l1mfn, l1e_content, 1);
>>                  }
>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>                                  entry_count++;
>>                              continue;
>>                          }
>> -                        mfn = l1e_get_pfn(l1e[i1]);
>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>                          ASSERT(mfn_valid(_mfn(mfn)));
>>                          m2pfn = get_gpfn_from_mfn(mfn);
>>                          if ( m2pfn != gfn &&
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 07:15:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 07:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxvXp-0008C2-OI; Thu, 16 Feb 2012 07:14:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxvXn-0008Bx-LB
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 07:14:19 +0000
Received: from [193.109.254.147:65026] by server-5.bemta-14.messagelabs.com id
	5A/54-01689-ACCAC3F4; Thu, 16 Feb 2012 07:14:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329376405!52955289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjM0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 16 Feb 2012 07:13:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 07:13:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,427,1325462400"; d="scan'208";a="10730970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 07:14:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 07:14:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxvXl-0008N4-OD;
	Thu, 16 Feb 2012 07:14:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxvXl-0004X8-C6;
	Thu, 16 Feb 2012 07:14:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11967-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 16 Feb 2012 07:14:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11967: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11967 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11967/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11965

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fe427d3bb378
baseline version:
 xen                  fe427d3bb378

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 07:15:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 07:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxvXp-0008C2-OI; Thu, 16 Feb 2012 07:14:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RxvXn-0008Bx-LB
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 07:14:19 +0000
Received: from [193.109.254.147:65026] by server-5.bemta-14.messagelabs.com id
	5A/54-01689-ACCAC3F4; Thu, 16 Feb 2012 07:14:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329376405!52955289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjM0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 16 Feb 2012 07:13:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 07:13:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,427,1325462400"; d="scan'208";a="10730970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 07:14:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 07:14:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RxvXl-0008N4-OD;
	Thu, 16 Feb 2012 07:14:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RxvXl-0004X8-C6;
	Thu, 16 Feb 2012 07:14:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11967-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 16 Feb 2012 07:14:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11967: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11967 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11967/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11965

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fe427d3bb378
baseline version:
 xen                  fe427d3bb378

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 07:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 07:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxvnB-0008PB-Bc; Thu, 16 Feb 2012 07:30:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Rxvn9-0008P3-9M
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 07:30:11 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329377404!15557434!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5884 invoked from network); 16 Feb 2012 07:30:04 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-12.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 07:30:04 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 4BB0C655A2A;
	Thu, 16 Feb 2012 08:28:10 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 3D92E655A32;
	Thu, 16 Feb 2012 08:28:10 +0100 (CET)
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 TXmJ-lzRbz-E; Thu, 16 Feb 2012 08:28:05 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 0B1D3655A2A;
	Thu, 16 Feb 2012 08:28:04 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: Eric Camachat <eric.camachat@gmail.com>,
 xen-devel@lists.xensource.com
Date: Thu, 16 Feb 2012 08:29:50 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
In-Reply-To: <CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202160829.54814.hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8524340265763969366=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8524340265763969366==
Content-Type: multipart/signed;
  boundary="nextPart7272037.Y8MBg4BLEK";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart7272037.Y8MBg4BLEK
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

Am Donnerstag 16 Februar 2012 02:22:30 schrieben Sie:
> On Tue, Feb 14, 2012 at 10:07 AM, Eric Camachat <eric.camachat@gmail.com>=
=20
wrote:
> > On Tue, Feb 14, 2012 at 12:07 AM, Philipp Hahn <hahn@univention.de> wro=
te:
> Try to use HYPERVISOR_kexec_op() to find out where crash buffer is.
> But it returned address that outside of total memory!

Yes, because the Hyervisor (which is running below your dom0 Linux kernel)=
=20
reserves the memory, so not even the dom0 kernel should be able to scribble=
=20
it. That's why you have to use the HYPERVIROS_OPs.

I've spend some time investigating this a month ago but finally did gave up=
=2E=20
Here're some of my notes:
=2D it should be possible to write a user-space tool (like kexec), which us=
es=20
HYPERVISOR_kexec_op() to load a crash-dump kernel.
=2D you would need to copy some code from the linux-kernel to fill in some =
data=20
structures.
=2D the Linux kernel prepends the crash kernel with some assembly code, whi=
ch=20
moves it to the final location on execution. This trampolin code would=20
possibly be  needed in your tool as well.

The other option I see would be to modify the current Linux kernel to use=20
HYPERVISOR_kexec_op() when used as a dom0 kernel.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart7272037.Y8MBg4BLEK
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)

iEYEABECAAYFAk88sG8ACgkQYPlgoZpUDjmZxACgiwtCJySm3zYi9A3/JOCw659B
F2UAoJSGw3VY52aPyBtbI5MLJ0FxB33P
=aaXm
-----END PGP SIGNATURE-----

--nextPart7272037.Y8MBg4BLEK--


--===============8524340265763969366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8524340265763969366==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 07:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 07:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxvnB-0008PB-Bc; Thu, 16 Feb 2012 07:30:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1Rxvn9-0008P3-9M
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 07:30:11 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329377404!15557434!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5884 invoked from network); 16 Feb 2012 07:30:04 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-12.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 07:30:04 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 4BB0C655A2A;
	Thu, 16 Feb 2012 08:28:10 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 3D92E655A32;
	Thu, 16 Feb 2012 08:28:10 +0100 (CET)
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 TXmJ-lzRbz-E; Thu, 16 Feb 2012 08:28:05 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 0B1D3655A2A;
	Thu, 16 Feb 2012 08:28:04 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: Eric Camachat <eric.camachat@gmail.com>,
 xen-devel@lists.xensource.com
Date: Thu, 16 Feb 2012 08:29:50 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
In-Reply-To: <CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202160829.54814.hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8524340265763969366=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8524340265763969366==
Content-Type: multipart/signed;
  boundary="nextPart7272037.Y8MBg4BLEK";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart7272037.Y8MBg4BLEK
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

Am Donnerstag 16 Februar 2012 02:22:30 schrieben Sie:
> On Tue, Feb 14, 2012 at 10:07 AM, Eric Camachat <eric.camachat@gmail.com>=
=20
wrote:
> > On Tue, Feb 14, 2012 at 12:07 AM, Philipp Hahn <hahn@univention.de> wro=
te:
> Try to use HYPERVISOR_kexec_op() to find out where crash buffer is.
> But it returned address that outside of total memory!

Yes, because the Hyervisor (which is running below your dom0 Linux kernel)=
=20
reserves the memory, so not even the dom0 kernel should be able to scribble=
=20
it. That's why you have to use the HYPERVIROS_OPs.

I've spend some time investigating this a month ago but finally did gave up=
=2E=20
Here're some of my notes:
=2D it should be possible to write a user-space tool (like kexec), which us=
es=20
HYPERVISOR_kexec_op() to load a crash-dump kernel.
=2D you would need to copy some code from the linux-kernel to fill in some =
data=20
structures.
=2D the Linux kernel prepends the crash kernel with some assembly code, whi=
ch=20
moves it to the final location on execution. This trampolin code would=20
possibly be  needed in your tool as well.

The other option I see would be to modify the current Linux kernel to use=20
HYPERVISOR_kexec_op() when used as a dom0 kernel.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart7272037.Y8MBg4BLEK
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)

iEYEABECAAYFAk88sG8ACgkQYPlgoZpUDjmZxACgiwtCJySm3zYi9A3/JOCw659B
F2UAoJSGw3VY52aPyBtbI5MLJ0FxB33P
=aaXm
-----END PGP SIGNATURE-----

--nextPart7272037.Y8MBg4BLEK--


--===============8524340265763969366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8524340265763969366==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 07:47:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Rxw3v-0000Of-M0; Thu, 16 Feb 2012 07:47:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rxw3t-0000OU-Sc
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 07:47:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329378441!11730206!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTc3NDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTc3NDc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15858 invoked from network); 16 Feb 2012 07:47:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Feb 2012 07:47:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329378441; l=14526;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=3ElZffq6uI1EwM78e+sEEgkmPC4=;
	b=hi5+pXXmYEXqNrWA2jXx86Rwz2hL3SR2Uf+UC+zvlU0519J4DmIoJfMvDBlL7Pberda
	6U5n2ef5+auwTdv6DyLCMVsPloiNqeJ7jDky0lo5LStXt2b0GsM0ccA3oVm+GmXGq3hDV
	Mcxx6hlskuVYpIGxeuiz+0herGoDIue/vXM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0Kfg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-004.pools.arcor-ip.net [88.65.99.4])
	by post.strato.de (mrclete mo48) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R04398o1G4WIWA
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:47:03 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2B69118632
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:47:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d368cf36d66c1e8df60bd0a4868c171b6a929edc
Message-Id: <d368cf36d66c1e8df60b.1329378421@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 16 Feb 2012 08:47:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329378376 -3600
# Node ID d368cf36d66c1e8df60bd0a4868c171b6a929edc
# Parent  bf0a7c205687857a8f8d3bd3841654ed61828193
RFC: initial libxl support for xenpaging

After the previous discussion about integration of xenpaging into xl/libxl it
was not clear to me wether my proposal as a whole or only parts of it were
rejected. So here is my current understanding of the comments I received.

Add initial support to libxl to start xenpaging for a HVM guest.
These are the considerations:
- a knob in domU.cfg is needed to start xenpaging
- xenpaging needs a target in KiB in "memory/target-tot_pages"
 -> the knob should be the target value in MiB: mem_target_paging=NUM
    if the value is 0, xenpaging is not started

- an cmdline interface is needed to adjust "memory/target-tot_pages" at runtime
 -> it was suggested to use 'xl mem-set' which should adjust both
    "memory/target" and "memory/target-tot_pages" at the same time
 -> maybe another cmdline interface should be 'xl mem-target-paging' which
    adjusts "memory/target-tot_pages", and maybe 'xl mem-target-balloon' which
    adjusts "memory/target"

- libxl starts xenpaging with at least two cmdline options which specifys the
  pagefile to use and the dom_id. An optional "xenpaging_file=path" specifies
  the pagefile name. Optional additional cmdline options for xenpaging can be
  specified with a domU.cfg option "xenpaging_extra=[ 'opt', 'opt' ]"

- currently maxmem= + memory= and mem_target_paging= can not be used because
  paging for a PoD guest is not implemented. This does not affect ballooning
  within the guest.

- I have some ideas to add runtime tuneables for xenpaging. Should there be a
  "xl xenpaging_ctrl tuneable_name value" command, or should it be done with a
  new tool xenpaging_ctrl? If the latter, the proposed 'xl mem-target-*'
  commands are not needed and this new helper could also adjust
  "memory/target-tot_pages".




The patch below is just a forward port of my previous version. It adds three
new config options, no xl or other changes:
mem_target_paging=<int>, the amount of memory in MiB for the guest
xenpaging_file=<string>, pagefile to use (optional)
xenpaging_extra=[ 'string', 'string' ], optional cmdline args for xenpaging

If 'mem_target_paging=' is not specified in config file, xenpaging will not start.
If 'xenpaging_file=' is not specified in config file,
/var/lib/xen/xenpaging/<domain_name>.<domaind_id>.paging is used.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -322,6 +322,7 @@ int libxl_init_build_info(libxl_ctx *ctx
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+int libxl__create_xenpaging(libxl_ctx *ctx, libxl_domain_config *d_config, uint32_t domid, char *path);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -457,6 +457,132 @@ static int store_libxl_entry(libxl__gc *
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
+static int create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid,
+                            libxl_domain_build_info *b_info)
+{
+    libxl__spawner_starting *buf_starting;
+    libxl_string_list xpe = b_info->u.hvm.xenpaging_extra;
+    int i, rc;
+    char *logfile;
+    int logfile_w, null, need_pagefile;
+    char *path, *dom_path, *value;
+    char **args;
+    char *xp;
+    flexarray_t *xp_args;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    /* Nothing to do */
+    if (!b_info->tot_memkb)
+        return 0;
+
+    /* Check if paging is already enabled */
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path ) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    path = libxl__sprintf(gc, "%s/xenpaging/state", dom_path);
+    if (!path ) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    value = xs_read(ctx->xsh, XBT_NULL, path, NULL);
+    rc = value && strcmp(value, "running") == 0;
+    free(value);
+    /* Already running, nothing to do */
+    if (rc)
+        return 0;
+
+    /* Check if xenpaging is present */
+    xp = libxl__abs_path(gc, "xenpaging", libxl_libexec_path());
+    if (access(xp, X_OK) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not executable", xp);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    /* Initialise settings for child */
+    buf_starting = calloc(sizeof(*buf_starting), 1);
+    if (!buf_starting) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    buf_starting->domid = domid;
+    buf_starting->dom_path = dom_path;
+    buf_starting->pid_path = "xenpaging/xenpaging-pid";
+    buf_starting->for_spawn = calloc(sizeof(libxl__spawn_starting), 1);
+    if (!buf_starting->for_spawn) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    /* Assemble arguments for xenpaging */
+    xp_args = flexarray_make(8, 1);
+    if (!xp_args) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    /* Set executable path */
+    flexarray_append(xp_args, xp);
+
+    /* Search pagefile option in extra flags */
+    need_pagefile = 1;
+    for (i = 0; xpe && xpe[i]; i++) {
+        if (strcmp(xpe[i], "-f") == 0) {
+            need_pagefile = 0;
+            break;
+        }
+    }
+    /* Append pagefile option if its not in extra flags */
+    if (need_pagefile) {
+        flexarray_append(xp_args, "-f");
+        if (b_info->u.hvm.xenpaging_file)
+            flexarray_append(xp_args, b_info->u.hvm.xenpaging_file);
+        else
+            flexarray_append(xp_args, libxl__sprintf(gc, "%s/%s.%u.paging",
+                             libxl_xenpaging_dir_path(), dom_name, domid));
+    }
+
+    /* Set maximum amount of memory xenpaging should handle */
+    flexarray_append(xp_args, "-m");
+    flexarray_append(xp_args, libxl__sprintf(gc, "%d", b_info->max_memkb));
+
+    /* Append extra args for pager */
+    for (i = 0; xpe && xpe[i]; i++)
+        flexarray_append(xp_args, xpe[i]);
+    /* Append domid for pager */
+    flexarray_append(xp_args, "-d");
+    flexarray_append(xp_args, libxl__sprintf(gc, "%u", domid));
+    flexarray_append(xp_args, NULL);
+    args = (char **) flexarray_contents(xp_args);
+
+    /* Initialise logfile */
+    libxl_create_logfile(ctx, libxl__sprintf(gc, "xenpaging-%s", dom_name),
+                         &logfile);
+    logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644);
+    free(logfile);
+    null = open("/dev/null", O_RDONLY);
+
+    /* Spawn the child */
+    rc = libxl__spawn_spawn(gc, buf_starting->for_spawn, "xenpaging",
+                            libxl_spawner_record_pid, buf_starting);
+    if (rc < 0)
+        goto out_close;
+    if (!rc) { /* inner child */
+        setsid();
+        /* Finally run xenpaging */
+        libxl__exec(null, logfile_w, logfile_w, xp, args);
+    }
+    rc = libxl__spawn_confirm_offspring_startup(gc, 5, "xenpaging", path,
+                                                "running", buf_starting);
+out_close:
+    close(null);
+    close(logfile_w);
+    free(args);
+out:
+    return rc;
+}
+
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv,
                             uint32_t *domid_out, int restore_fd)
@@ -633,6 +759,16 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = create_xenpaging(gc, d_config->c_info.name, domid,
+                              &d_config->b_info);
+        if (ret) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                      "Failed to start xenpaging.\n");
+            goto error_out;
+        }
+    }
+
     *domid_out = domid;
     return 0;
 
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -127,7 +127,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -140,9 +140,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "memory/target-tot_pages";
+    ents[13] = libxl__sprintf(gc, "%d", info->tot_memkb);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_memory.txt
--- a/tools/libxl/libxl_memory.txt
+++ b/tools/libxl/libxl_memory.txt
@@ -1,28 +1,28 @@
 /* === 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                                       
-             |  |          |  |                                               
-             +  +----------+  +                                               
+             +  +----------+                                                 +            
+             |  | shadow   |                                                 |            
+             |  +----------+                                                 |            
+    overhead |  | extra    |                                                 |            
+             |  | external |                                                 |            
+             |  +----------+                                      +          |            
+             |  | extra    |                                      |          |            
+             |  | internal |                                      |          |            
+             +  +----------+                            +         |          | footprint  
+             |  | video    |                            |         |          |            
+             |  +----------+  +           +    +        |         | xen      |            
+             |  |          |  | guest OS  |    |        | actual  | maximum  |            
+             |  | guest    |  | real RAM  |    |        | target  |          |            
+             |  |          |  |           |    | build  |         |          |            
+             |  |----------+  +           |    | start  +         |          |            
+      static |  | paging   |              |    |                  |          |            
+     maximum |  +----------+              |    +                  +          +            
+             |  |          |              |                                               
+             |  |          |              |                                               
+             |  | balloon  |              | build                                         
+             |  |          |              | maximum                                       
+             |  |          |              |                                               
+             +  +----------+              +                                               
                 
                 
     extra internal = LIBXL_MAXMEM_CONSTANT
@@ -34,6 +34,17 @@
     libxl_domain_setmaxmem -> xen maximum
     libxl_set_memory_target -> actual target
                 
+    build maximum = RAM as seen inside the virtual machine
+                    Guest OS has to configure itself for this amount of memory
+                    Increase/Decrease via memory hotplug of virtual hardware.
+                    xl mem-max
+    build start   = RAM usable by the guest OS
+                    Guest OS sees balloon driver as memory hog
+                    Increase/Decrease via commands to the balloon driver
+                    xl mem-set
+    actual target = RAM allocated for the guest
+                    Increase/Decrease via commands to paging daemon
+                    xl mem-paging_target (?)
                 
  === Domain memory breakdown: PV guests ==================================
                 
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -207,6 +207,7 @@ libxl_domain_build_info = Struct("domain
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
+    ("tot_memkb",       uint32),
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
@@ -240,6 +241,8 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", libxl_timer_mode),
                                        ("nested_hvm", bool),
+                                       ("xenpaging_file", string),
+                                       ("xenpaging_extra", libxl_string_list),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -508,6 +508,28 @@ vcpp_out:
     return rc;
 }
 
+static void parse_xenpaging_extra(const XLU_Config *config, libxl_string_list *xpe)
+{
+    XLU_ConfigList *args;
+    libxl_string_list l;
+    const char *val;
+    int nr_args = 0, i;
+
+    if (xlu_cfg_get_list(config, "xenpaging_extra", &args, &nr_args, 1))
+        return;
+
+    l = xmalloc(sizeof(char*)*(nr_args + 1));
+    if (!l)
+        return;
+
+    l[nr_args] = NULL;
+    for (i = 0; i < nr_args; i++) {
+        val = xlu_cfg_get_listitem(args, i);
+        l[i] = val ? strdup(val) : NULL;
+    }
+    *xpe = l;
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -629,6 +651,9 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
+    if (!xlu_cfg_get_long (config, "mem_target_paging", &l, 0))
+        b_info->tot_memkb = l * 1024;
+
     if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
@@ -747,6 +772,10 @@ static void parse_config_data(const char
 
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+
+        xlu_cfg_replace_string (config, "xenpaging_file", &b_info->u.hvm.xenpaging_file, 0);
+        parse_xenpaging_extra(config, &b_info->u.hvm.xenpaging_extra);
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
diff -r bf0a7c205687 -r d368cf36d66c tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -39,6 +39,8 @@
 
 /* Defines number of mfns a guest should use at a time, in KiB */
 #define WATCH_TARGETPAGES "memory/target-tot_pages"
+/* Defines path to startup confirmation */
+#define WATCH_STARTUP "xenpaging/state"
 static char *watch_target_tot_pages;
 static char *dom_path;
 static char watch_token[16];
@@ -845,6 +847,20 @@ static int evict_pages(struct xenpaging 
     return num;
 }
 
+static void xenpaging_confirm_startup(struct xenpaging *paging)
+{
+    xc_interface *xch = paging->xc_handle;
+    char *path;
+    int len;
+
+    len = asprintf(&path, "%s/%s", dom_path, WATCH_STARTUP);
+    if ( len < 0 )
+        return;
+    DPRINTF("confirming startup in %s\n", path);
+    xs_write(paging->xs_handle, XBT_NULL, path, "running", strlen("running"));
+    free(path);
+}
+
 int main(int argc, char *argv[])
 {
     struct sigaction act;
@@ -880,6 +896,9 @@ int main(int argc, char *argv[])
     /* listen for page-in events to stop pager */
     create_page_in_thread(paging);
 
+    /* Confirm startup to caller */
+    xenpaging_confirm_startup(paging);
+
     /* Swap pages in and out */
     while ( 1 )
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 07:47:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Rxw3v-0000Of-M0; Thu, 16 Feb 2012 07:47:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rxw3t-0000OU-Sc
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 07:47:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329378441!11730206!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTc3NDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTc3NDc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15858 invoked from network); 16 Feb 2012 07:47:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Feb 2012 07:47:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329378441; l=14526;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=3ElZffq6uI1EwM78e+sEEgkmPC4=;
	b=hi5+pXXmYEXqNrWA2jXx86Rwz2hL3SR2Uf+UC+zvlU0519J4DmIoJfMvDBlL7Pberda
	6U5n2ef5+auwTdv6DyLCMVsPloiNqeJ7jDky0lo5LStXt2b0GsM0ccA3oVm+GmXGq3hDV
	Mcxx6hlskuVYpIGxeuiz+0herGoDIue/vXM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0Kfg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-004.pools.arcor-ip.net [88.65.99.4])
	by post.strato.de (mrclete mo48) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R04398o1G4WIWA
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:47:03 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2B69118632
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:47:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d368cf36d66c1e8df60bd0a4868c171b6a929edc
Message-Id: <d368cf36d66c1e8df60b.1329378421@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 16 Feb 2012 08:47:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329378376 -3600
# Node ID d368cf36d66c1e8df60bd0a4868c171b6a929edc
# Parent  bf0a7c205687857a8f8d3bd3841654ed61828193
RFC: initial libxl support for xenpaging

After the previous discussion about integration of xenpaging into xl/libxl it
was not clear to me wether my proposal as a whole or only parts of it were
rejected. So here is my current understanding of the comments I received.

Add initial support to libxl to start xenpaging for a HVM guest.
These are the considerations:
- a knob in domU.cfg is needed to start xenpaging
- xenpaging needs a target in KiB in "memory/target-tot_pages"
 -> the knob should be the target value in MiB: mem_target_paging=NUM
    if the value is 0, xenpaging is not started

- an cmdline interface is needed to adjust "memory/target-tot_pages" at runtime
 -> it was suggested to use 'xl mem-set' which should adjust both
    "memory/target" and "memory/target-tot_pages" at the same time
 -> maybe another cmdline interface should be 'xl mem-target-paging' which
    adjusts "memory/target-tot_pages", and maybe 'xl mem-target-balloon' which
    adjusts "memory/target"

- libxl starts xenpaging with at least two cmdline options which specifys the
  pagefile to use and the dom_id. An optional "xenpaging_file=path" specifies
  the pagefile name. Optional additional cmdline options for xenpaging can be
  specified with a domU.cfg option "xenpaging_extra=[ 'opt', 'opt' ]"

- currently maxmem= + memory= and mem_target_paging= can not be used because
  paging for a PoD guest is not implemented. This does not affect ballooning
  within the guest.

- I have some ideas to add runtime tuneables for xenpaging. Should there be a
  "xl xenpaging_ctrl tuneable_name value" command, or should it be done with a
  new tool xenpaging_ctrl? If the latter, the proposed 'xl mem-target-*'
  commands are not needed and this new helper could also adjust
  "memory/target-tot_pages".




The patch below is just a forward port of my previous version. It adds three
new config options, no xl or other changes:
mem_target_paging=<int>, the amount of memory in MiB for the guest
xenpaging_file=<string>, pagefile to use (optional)
xenpaging_extra=[ 'string', 'string' ], optional cmdline args for xenpaging

If 'mem_target_paging=' is not specified in config file, xenpaging will not start.
If 'xenpaging_file=' is not specified in config file,
/var/lib/xen/xenpaging/<domain_name>.<domaind_id>.paging is used.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -322,6 +322,7 @@ int libxl_init_build_info(libxl_ctx *ctx
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
+int libxl__create_xenpaging(libxl_ctx *ctx, libxl_domain_config *d_config, uint32_t domid, char *path);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -457,6 +457,132 @@ static int store_libxl_entry(libxl__gc *
         libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
+static int create_xenpaging(libxl__gc *gc, char *dom_name, uint32_t domid,
+                            libxl_domain_build_info *b_info)
+{
+    libxl__spawner_starting *buf_starting;
+    libxl_string_list xpe = b_info->u.hvm.xenpaging_extra;
+    int i, rc;
+    char *logfile;
+    int logfile_w, null, need_pagefile;
+    char *path, *dom_path, *value;
+    char **args;
+    char *xp;
+    flexarray_t *xp_args;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    /* Nothing to do */
+    if (!b_info->tot_memkb)
+        return 0;
+
+    /* Check if paging is already enabled */
+    dom_path = libxl__xs_get_dompath(gc, domid);
+    if (!dom_path ) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    path = libxl__sprintf(gc, "%s/xenpaging/state", dom_path);
+    if (!path ) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    value = xs_read(ctx->xsh, XBT_NULL, path, NULL);
+    rc = value && strcmp(value, "running") == 0;
+    free(value);
+    /* Already running, nothing to do */
+    if (rc)
+        return 0;
+
+    /* Check if xenpaging is present */
+    xp = libxl__abs_path(gc, "xenpaging", libxl_libexec_path());
+    if (access(xp, X_OK) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "%s is not executable", xp);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    /* Initialise settings for child */
+    buf_starting = calloc(sizeof(*buf_starting), 1);
+    if (!buf_starting) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    buf_starting->domid = domid;
+    buf_starting->dom_path = dom_path;
+    buf_starting->pid_path = "xenpaging/xenpaging-pid";
+    buf_starting->for_spawn = calloc(sizeof(libxl__spawn_starting), 1);
+    if (!buf_starting->for_spawn) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    /* Assemble arguments for xenpaging */
+    xp_args = flexarray_make(8, 1);
+    if (!xp_args) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    /* Set executable path */
+    flexarray_append(xp_args, xp);
+
+    /* Search pagefile option in extra flags */
+    need_pagefile = 1;
+    for (i = 0; xpe && xpe[i]; i++) {
+        if (strcmp(xpe[i], "-f") == 0) {
+            need_pagefile = 0;
+            break;
+        }
+    }
+    /* Append pagefile option if its not in extra flags */
+    if (need_pagefile) {
+        flexarray_append(xp_args, "-f");
+        if (b_info->u.hvm.xenpaging_file)
+            flexarray_append(xp_args, b_info->u.hvm.xenpaging_file);
+        else
+            flexarray_append(xp_args, libxl__sprintf(gc, "%s/%s.%u.paging",
+                             libxl_xenpaging_dir_path(), dom_name, domid));
+    }
+
+    /* Set maximum amount of memory xenpaging should handle */
+    flexarray_append(xp_args, "-m");
+    flexarray_append(xp_args, libxl__sprintf(gc, "%d", b_info->max_memkb));
+
+    /* Append extra args for pager */
+    for (i = 0; xpe && xpe[i]; i++)
+        flexarray_append(xp_args, xpe[i]);
+    /* Append domid for pager */
+    flexarray_append(xp_args, "-d");
+    flexarray_append(xp_args, libxl__sprintf(gc, "%u", domid));
+    flexarray_append(xp_args, NULL);
+    args = (char **) flexarray_contents(xp_args);
+
+    /* Initialise logfile */
+    libxl_create_logfile(ctx, libxl__sprintf(gc, "xenpaging-%s", dom_name),
+                         &logfile);
+    logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644);
+    free(logfile);
+    null = open("/dev/null", O_RDONLY);
+
+    /* Spawn the child */
+    rc = libxl__spawn_spawn(gc, buf_starting->for_spawn, "xenpaging",
+                            libxl_spawner_record_pid, buf_starting);
+    if (rc < 0)
+        goto out_close;
+    if (!rc) { /* inner child */
+        setsid();
+        /* Finally run xenpaging */
+        libxl__exec(null, logfile_w, logfile_w, xp, args);
+    }
+    rc = libxl__spawn_confirm_offspring_startup(gc, 5, "xenpaging", path,
+                                                "running", buf_starting);
+out_close:
+    close(null);
+    close(logfile_w);
+    free(args);
+out:
+    return rc;
+}
+
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                             libxl_console_ready cb, void *priv,
                             uint32_t *domid_out, int restore_fd)
@@ -633,6 +759,16 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM) {
+        ret = create_xenpaging(gc, d_config->c_info.name, domid,
+                              &d_config->b_info);
+        if (ret) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                      "Failed to start xenpaging.\n");
+            goto error_out;
+        }
+    }
+
     *domid_out = domid;
     return 0;
 
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -127,7 +127,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -140,9 +140,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "memory/target-tot_pages";
+    ents[13] = libxl__sprintf(gc, "%d", info->tot_memkb);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_memory.txt
--- a/tools/libxl/libxl_memory.txt
+++ b/tools/libxl/libxl_memory.txt
@@ -1,28 +1,28 @@
 /* === 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                                       
-             |  |          |  |                                               
-             +  +----------+  +                                               
+             +  +----------+                                                 +            
+             |  | shadow   |                                                 |            
+             |  +----------+                                                 |            
+    overhead |  | extra    |                                                 |            
+             |  | external |                                                 |            
+             |  +----------+                                      +          |            
+             |  | extra    |                                      |          |            
+             |  | internal |                                      |          |            
+             +  +----------+                            +         |          | footprint  
+             |  | video    |                            |         |          |            
+             |  +----------+  +           +    +        |         | xen      |            
+             |  |          |  | guest OS  |    |        | actual  | maximum  |            
+             |  | guest    |  | real RAM  |    |        | target  |          |            
+             |  |          |  |           |    | build  |         |          |            
+             |  |----------+  +           |    | start  +         |          |            
+      static |  | paging   |              |    |                  |          |            
+     maximum |  +----------+              |    +                  +          +            
+             |  |          |              |                                               
+             |  |          |              |                                               
+             |  | balloon  |              | build                                         
+             |  |          |              | maximum                                       
+             |  |          |              |                                               
+             +  +----------+              +                                               
                 
                 
     extra internal = LIBXL_MAXMEM_CONSTANT
@@ -34,6 +34,17 @@
     libxl_domain_setmaxmem -> xen maximum
     libxl_set_memory_target -> actual target
                 
+    build maximum = RAM as seen inside the virtual machine
+                    Guest OS has to configure itself for this amount of memory
+                    Increase/Decrease via memory hotplug of virtual hardware.
+                    xl mem-max
+    build start   = RAM usable by the guest OS
+                    Guest OS sees balloon driver as memory hog
+                    Increase/Decrease via commands to the balloon driver
+                    xl mem-set
+    actual target = RAM allocated for the guest
+                    Increase/Decrease via commands to paging daemon
+                    xl mem-paging_target (?)
                 
  === Domain memory breakdown: PV guests ==================================
                 
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -207,6 +207,7 @@ libxl_domain_build_info = Struct("domain
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
+    ("tot_memkb",       uint32),
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
@@ -240,6 +241,8 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", libxl_timer_mode),
                                        ("nested_hvm", bool),
+                                       ("xenpaging_file", string),
+                                       ("xenpaging_extra", libxl_string_list),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
diff -r bf0a7c205687 -r d368cf36d66c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -508,6 +508,28 @@ vcpp_out:
     return rc;
 }
 
+static void parse_xenpaging_extra(const XLU_Config *config, libxl_string_list *xpe)
+{
+    XLU_ConfigList *args;
+    libxl_string_list l;
+    const char *val;
+    int nr_args = 0, i;
+
+    if (xlu_cfg_get_list(config, "xenpaging_extra", &args, &nr_args, 1))
+        return;
+
+    l = xmalloc(sizeof(char*)*(nr_args + 1));
+    if (!l)
+        return;
+
+    l[nr_args] = NULL;
+    for (i = 0; i < nr_args; i++) {
+        val = xlu_cfg_get_listitem(args, i);
+        l[i] = val ? strdup(val) : NULL;
+    }
+    *xpe = l;
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -629,6 +651,9 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
+    if (!xlu_cfg_get_long (config, "mem_target_paging", &l, 0))
+        b_info->tot_memkb = l * 1024;
+
     if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
@@ -747,6 +772,10 @@ static void parse_config_data(const char
 
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+
+        xlu_cfg_replace_string (config, "xenpaging_file", &b_info->u.hvm.xenpaging_file, 0);
+        parse_xenpaging_extra(config, &b_info->u.hvm.xenpaging_extra);
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
diff -r bf0a7c205687 -r d368cf36d66c tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -39,6 +39,8 @@
 
 /* Defines number of mfns a guest should use at a time, in KiB */
 #define WATCH_TARGETPAGES "memory/target-tot_pages"
+/* Defines path to startup confirmation */
+#define WATCH_STARTUP "xenpaging/state"
 static char *watch_target_tot_pages;
 static char *dom_path;
 static char watch_token[16];
@@ -845,6 +847,20 @@ static int evict_pages(struct xenpaging 
     return num;
 }
 
+static void xenpaging_confirm_startup(struct xenpaging *paging)
+{
+    xc_interface *xch = paging->xc_handle;
+    char *path;
+    int len;
+
+    len = asprintf(&path, "%s/%s", dom_path, WATCH_STARTUP);
+    if ( len < 0 )
+        return;
+    DPRINTF("confirming startup in %s\n", path);
+    xs_write(paging->xs_handle, XBT_NULL, path, "running", strlen("running"));
+    free(path);
+}
+
 int main(int argc, char *argv[])
 {
     struct sigaction act;
@@ -880,6 +896,9 @@ int main(int argc, char *argv[])
     /* listen for page-in events to stop pager */
     create_page_in_thread(paging);
 
+    /* Confirm startup to caller */
+    xenpaging_confirm_startup(paging);
+
     /* Swap pages in and out */
     while ( 1 )
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 08:42:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 08:42:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxwuv-0001M3-Nu; Thu, 16 Feb 2012 08:42:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxwuu-0001Lv-2G
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 08:42:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329381729!13582967!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15058 invoked from network); 16 Feb 2012 08:42:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 08:42:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 08:42:13 +0000
Message-Id: <4F3CCF6F02000078000735D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 08:42:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
In-Reply-To: <adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>       BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>       to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>       recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>       this value.
> 
> This extension first appeared in the FreeBSD Operating System.

Any pointer to their implementation?

> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 321810c42d55 -r adcb465964c5 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
> @@ -142,6 +142,32 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the backend.
> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
> + *
> + *      The maximum value of blkif_request.nr_segments supported by
> + *      the backend.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE

In particular, wrt the question about a reference to their implementation,
I don't see why both max-request-segments and max-request-size are
necessary here and below. What is the intended behavior when the two
aren't in sync?

> + *
> + *      The maximum amount of data, in bytes, that can be referenced by a
> + *      request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Backend Device Properties -------------------------
>   *
>   * discard-aligment
> @@ -239,6 +265,33 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)

max-ring-pages?

Jan

> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the frontend.
> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  MIN(255, backend/max-request-segments)
> + *
> + *      The maximum value the frontend will set in the
> + *      blkif_request.nr_segments field.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  max-request-segments * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by
> + *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -400,11 +453,28 @@
>  #define BLKIF_OP_DISCARD           5
>  
>  /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
>   * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
>   * NB. This could be 12 if the ring indexes weren't stored in the same 
> page.
>   */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040201
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
> +#else
> +/*
> + * Maximum scatter/gather segments per request (header block only).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> +#endif
>  
>  /*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -419,9 +489,25 @@ struct blkif_request_segment {
>      /* @last_sect: last sector in frame to transfer (inclusive).     */
>      uint8_t     first_sect, last_sect;
>  };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>  
>  /*
>   * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note:  Due to the way Xen request rings operate, the producer and
> + *        consumer indices of the ring must be incremented by the
> + *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + *        (e.g. a response to a 3 ring entry request must also consume
> + *        3 entries in the ring, even though only the first ring entry
> + *        in the response has any data.)
>   */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
> @@ -429,11 +515,22 @@ struct blkif_request {
>      blkif_vdev_t   handle;       /* only for read/write requests         */
>      uint64_t       id;           /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> -    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
>  };
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
>   * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
> @@ -470,6 +567,21 @@ typedef struct blkif_response blkif_resp
>   */
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
> +    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
> +    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
> +     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
> +    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> diff -r 321810c42d55 -r adcb465964c5 xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
> +++ b/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. 
> */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 08:42:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 08:42:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxwuv-0001M3-Nu; Thu, 16 Feb 2012 08:42:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxwuu-0001Lv-2G
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 08:42:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329381729!13582967!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15058 invoked from network); 16 Feb 2012 08:42:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 08:42:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 08:42:13 +0000
Message-Id: <4F3CCF6F02000078000735D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 08:42:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
In-Reply-To: <adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>       BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>       to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>       recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>       this value.
> 
> This extension first appeared in the FreeBSD Operating System.

Any pointer to their implementation?

> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 321810c42d55 -r adcb465964c5 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Tue Feb 14 21:54:09 2012 -0700
> @@ -142,6 +142,32 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the backend.
> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
> + *
> + *      The maximum value of blkif_request.nr_segments supported by
> + *      the backend.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE

In particular, wrt the question about a reference to their implementation,
I don't see why both max-request-segments and max-request-size are
necessary here and below. What is the intended behavior when the two
aren't in sync?

> + *
> + *      The maximum amount of data, in bytes, that can be referenced by a
> + *      request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Backend Device Properties -------------------------
>   *
>   * discard-aligment
> @@ -239,6 +265,33 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)

max-ring-pages?

Jan

> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the frontend.
> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  MIN(255, backend/max-request-segments)
> + *
> + *      The maximum value the frontend will set in the
> + *      blkif_request.nr_segments field.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  max-request-segments * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by
> + *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -400,11 +453,28 @@
>  #define BLKIF_OP_DISCARD           5
>  
>  /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
>   * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
>   * NB. This could be 12 if the ring indexes weren't stored in the same 
> page.
>   */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040201
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
> +#else
> +/*
> + * Maximum scatter/gather segments per request (header block only).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> +#endif
>  
>  /*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -419,9 +489,25 @@ struct blkif_request_segment {
>      /* @last_sect: last sector in frame to transfer (inclusive).     */
>      uint8_t     first_sect, last_sect;
>  };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>  
>  /*
>   * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note:  Due to the way Xen request rings operate, the producer and
> + *        consumer indices of the ring must be incremented by the
> + *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + *        (e.g. a response to a 3 ring entry request must also consume
> + *        3 entries in the ring, even though only the first ring entry
> + *        in the response has any data.)
>   */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
> @@ -429,11 +515,22 @@ struct blkif_request {
>      blkif_vdev_t   handle;       /* only for read/write requests         */
>      uint64_t       id;           /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> -    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
>  };
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
>   * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
> @@ -470,6 +567,21 @@ typedef struct blkif_response blkif_resp
>   */
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
> +    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
> +    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
> +     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
> +    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> diff -r 321810c42d55 -r adcb465964c5 xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
> +++ b/xen/include/public/xen-compat.h	Tue Feb 14 21:54:09 2012 -0700
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. 
> */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 08:54:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 08: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.xensource.com>)
	id 1Rxx64-0001bW-Tp; Thu, 16 Feb 2012 08:53:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rxx63-0001bJ-Kb
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 08:53:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329382421!11688989!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25188 invoked from network); 16 Feb 2012 08:53:41 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 08:53:41 -0000
Received: by wibhm2 with SMTP id hm2so3380225wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 00:53:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=8fDyd/gqfSSOJXWF7Tw+O2EBg6BbotDtLJoKvgBZOro=;
	b=l08anEsEBFrExWzMvXlD/sQayZjsWsEz91uPbU+MI4DsJI3jfUPmh1QjTluB/t492l
	Ghxmhn98bKGfNPJndMHwTs2rYnpCL1jVUaW5JmyS4hWlPwm2yPJb2HoQuEZyilxEhH7h
	4R+j3YluWD+FFcOX5fO+aS7Wctj76QlyZbHZM=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr17259934wia.3.1329382421060; Thu,
	16 Feb 2012 00:53:41 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 16 Feb 2012 00:53:41 -0800 (PST)
In-Reply-To: <20283.59599.334639.858879@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
	<20275.59617.15772.210387@mariner.uk.xensource.com>
	<CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
	<20283.59599.334639.858879@mariner.uk.xensource.com>
Date: Thu, 16 Feb 2012 09:53:41 +0100
X-Google-Sender-Auth: AQVK9Slyjon-XxC5Ul-IWaDv6sg
Message-ID: <CAPLaKK6R3z2bDYLDdOCPZ8qfdqTUFrfae=FNf4M0id7eze1z7Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add
	libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE1IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggMjggb2YgMjkgUkZD
XSBsaWJ4bDogYWRkIGxpYnhsX19maW5kX2ZyZWVfdmRldiIpOgo+PiBUaGUgbWFpbiBwdXJwb3Nl
IG9mIHRoaXMgc2VyaWVzIGlzIHRvIHNlcGFyYXRlIHRoZSBjb250cm9sIGNvZGUgZnJvbQo+PiB0
aGUgZGV2aWNlIGNvZGUgKG1ha2UgeGwgYWJsZSB0byBwbHVnIGRldmljZXMgZnJvbSBhIGRvbWFp
biBkaWZmZXJlbnQKPj4gdGhhbiBkb20wKS4gU2luY2UgdGhlIHJvb3QgaW1hZ2UgbWlnaHQgbm90
IGJlIHN0b3JlZCBvbiB0aGUgZG9tMCwgd2UKPj4gbmVlZCB0byBiZSBhYmxlIHRvIG1ha2UgdGhp
cyBpbWFnZSBhdmFpbGFibGUgdG8gdGhlIGRvbTAgc29tZWhvdywgdG8KPj4gZXh0cmFjdCB0aGUg
a2VybmVsIGFuZCByYW1kaXNrLiBPbmUgb3B0aW9uIGlzIHRvIGV4ZWN1dGUgcHlncnViIGZyb20K
Pj4gdGhlIGRldmljZSBkb21haW4sIHRoZSBvdGhlciBvcHRpb24gaXMgdG8gcGx1ZyB0aGUgZG9t
VSBoYXJkIGRyaXZlIHRvCj4+IHRoZSBkb20wLCBydW4gdGhlIGJvb3Rsb2FkZXIgdG8gZXh0cmFj
dCB0aGUga2VybmVsL2luaXRyZCBhbmQgdW5wbHVnCj4+IHRoZSBoZC4KPgo+IFdvdy4gwqBTbyB0
aGlzIHJlbGllcyBvbiBhIGZyb250ZW5kIGluIGRvbTAgPwoKWWVzLCB0aGF0J3MgYmVlbiBkaXNj
dXNzZWQgYmVmb3JlLCBhbmQgc2VlbWVkIGxpa2UgdGhlIHdheSB0byBnbzoKCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDEvbXNnMDI2NjMuaHRtbApo
dHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAxL21zZzAy
NzYxLmh0bWwKCkkndmUgYmVlbiBwbGF5aW5nIHdpdGggdGhpcyBpbXBsZW1lbnRhdGlvbiBhbmQg
c2VlbXMgdG8gd29yayBvay4KCj4gSSB0aGluayBmb3Igbm93IGl0IG1pZ2h0IGJlIHdpc2UgdG8g
c2ltcGx5IGV4cGVjdCB0aGUga2VybmVsL3JhbWRpc2sKPiB0byBleGlzdCBhcyBmaWxlcyBpbiBk
b20wIHNvbWV3aGVyZS4KCldlbGwsIHRoYXQgaXMgYWxyZWFkeSBhcmNoaXZlZCB1c2luZyBrZXJu
ZWwgYW5kIHJhbWRpc2sgcGFyYW1ldGVycyBpbgpjb25maWd1cmF0aW9uIGZpbGUgcmlnaHQ/Cgo+
IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDov
L2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 16 08:54:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 08: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.xensource.com>)
	id 1Rxx64-0001bW-Tp; Thu, 16 Feb 2012 08:53:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rxx63-0001bJ-Kb
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 08:53:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329382421!11688989!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25188 invoked from network); 16 Feb 2012 08:53:41 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 08:53:41 -0000
Received: by wibhm2 with SMTP id hm2so3380225wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 00:53:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=8fDyd/gqfSSOJXWF7Tw+O2EBg6BbotDtLJoKvgBZOro=;
	b=l08anEsEBFrExWzMvXlD/sQayZjsWsEz91uPbU+MI4DsJI3jfUPmh1QjTluB/t492l
	Ghxmhn98bKGfNPJndMHwTs2rYnpCL1jVUaW5JmyS4hWlPwm2yPJb2HoQuEZyilxEhH7h
	4R+j3YluWD+FFcOX5fO+aS7Wctj76QlyZbHZM=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr17259934wia.3.1329382421060; Thu,
	16 Feb 2012 00:53:41 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 16 Feb 2012 00:53:41 -0800 (PST)
In-Reply-To: <20283.59599.334639.858879@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<35164add2785b8606c0e.1328189223@debian.localdomain>
	<20275.59617.15772.210387@mariner.uk.xensource.com>
	<CAPLaKK6L3++OrpeJ+tff6Ep+NSmOt23MfR9dGQSLyNsRqh7kkg@mail.gmail.com>
	<20283.59599.334639.858879@mariner.uk.xensource.com>
Date: Thu, 16 Feb 2012 09:53:41 +0100
X-Google-Sender-Auth: AQVK9Slyjon-XxC5Ul-IWaDv6sg
Message-ID: <CAPLaKK6R3z2bDYLDdOCPZ8qfdqTUFrfae=FNf4M0id7eze1z7Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add
	libxl__find_free_vdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE1IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggMjggb2YgMjkgUkZD
XSBsaWJ4bDogYWRkIGxpYnhsX19maW5kX2ZyZWVfdmRldiIpOgo+PiBUaGUgbWFpbiBwdXJwb3Nl
IG9mIHRoaXMgc2VyaWVzIGlzIHRvIHNlcGFyYXRlIHRoZSBjb250cm9sIGNvZGUgZnJvbQo+PiB0
aGUgZGV2aWNlIGNvZGUgKG1ha2UgeGwgYWJsZSB0byBwbHVnIGRldmljZXMgZnJvbSBhIGRvbWFp
biBkaWZmZXJlbnQKPj4gdGhhbiBkb20wKS4gU2luY2UgdGhlIHJvb3QgaW1hZ2UgbWlnaHQgbm90
IGJlIHN0b3JlZCBvbiB0aGUgZG9tMCwgd2UKPj4gbmVlZCB0byBiZSBhYmxlIHRvIG1ha2UgdGhp
cyBpbWFnZSBhdmFpbGFibGUgdG8gdGhlIGRvbTAgc29tZWhvdywgdG8KPj4gZXh0cmFjdCB0aGUg
a2VybmVsIGFuZCByYW1kaXNrLiBPbmUgb3B0aW9uIGlzIHRvIGV4ZWN1dGUgcHlncnViIGZyb20K
Pj4gdGhlIGRldmljZSBkb21haW4sIHRoZSBvdGhlciBvcHRpb24gaXMgdG8gcGx1ZyB0aGUgZG9t
VSBoYXJkIGRyaXZlIHRvCj4+IHRoZSBkb20wLCBydW4gdGhlIGJvb3Rsb2FkZXIgdG8gZXh0cmFj
dCB0aGUga2VybmVsL2luaXRyZCBhbmQgdW5wbHVnCj4+IHRoZSBoZC4KPgo+IFdvdy4gwqBTbyB0
aGlzIHJlbGllcyBvbiBhIGZyb250ZW5kIGluIGRvbTAgPwoKWWVzLCB0aGF0J3MgYmVlbiBkaXNj
dXNzZWQgYmVmb3JlLCBhbmQgc2VlbWVkIGxpa2UgdGhlIHdheSB0byBnbzoKCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTItMDEvbXNnMDI2NjMuaHRtbApo
dHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAxL21zZzAy
NzYxLmh0bWwKCkkndmUgYmVlbiBwbGF5aW5nIHdpdGggdGhpcyBpbXBsZW1lbnRhdGlvbiBhbmQg
c2VlbXMgdG8gd29yayBvay4KCj4gSSB0aGluayBmb3Igbm93IGl0IG1pZ2h0IGJlIHdpc2UgdG8g
c2ltcGx5IGV4cGVjdCB0aGUga2VybmVsL3JhbWRpc2sKPiB0byBleGlzdCBhcyBmaWxlcyBpbiBk
b20wIHNvbWV3aGVyZS4KCldlbGwsIHRoYXQgaXMgYWxyZWFkeSBhcmNoaXZlZCB1c2luZyBrZXJu
ZWwgYW5kIHJhbWRpc2sgcGFyYW1ldGVycyBpbgpjb25maWd1cmF0aW9uIGZpbGUgcmlnaHQ/Cgo+
IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDov
L2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Feb 16 08:57:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 08:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxx9C-0001ja-I7; Thu, 16 Feb 2012 08:57:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxx9B-0001jO-Dt
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 08:57:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329382483!52943536!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10108 invoked from network); 16 Feb 2012 08:54:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 08:54:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 08:57:05 +0000
Message-Id: <4F3CD2E502000078000735E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 08:56:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
	<20120215192804.GA21695@phenom.dumpdata.com>
In-Reply-To: <20120215192804.GA21695@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> 	struct page **pages;
> 	unsigned int nr_pages, array_size, i;
> 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
>-
>+	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
>+	if (xen_pv_domain()) {
>+		if (dma_mask == (__GFP_DMA | __GFP_DMA32))

I didn't spot where you force this normally invalid combination, without
which the change won't affect vmalloc32() in a 32-bit kernel.

>+			gfp_mask &= (__GFP_DMA | __GFP_DMA32);

			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);

Jan

>+	}
> 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> 	array_size = (nr_pages * sizeof(struct page *));
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 08:57:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 08:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rxx9C-0001ja-I7; Thu, 16 Feb 2012 08:57:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rxx9B-0001jO-Dt
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 08:57:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329382483!52943536!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10108 invoked from network); 16 Feb 2012 08:54:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 08:54:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 08:57:05 +0000
Message-Id: <4F3CD2E502000078000735E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 08:56:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
	<20120215192804.GA21695@phenom.dumpdata.com>
In-Reply-To: <20120215192804.GA21695@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> 	struct page **pages;
> 	unsigned int nr_pages, array_size, i;
> 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
>-
>+	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
>+	if (xen_pv_domain()) {
>+		if (dma_mask == (__GFP_DMA | __GFP_DMA32))

I didn't spot where you force this normally invalid combination, without
which the change won't affect vmalloc32() in a 32-bit kernel.

>+			gfp_mask &= (__GFP_DMA | __GFP_DMA32);

			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);

Jan

>+	}
> 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> 	array_size = (nr_pages * sizeof(struct page *));
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 09:01:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 09: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.xensource.com>)
	id 1RxxDU-0001z2-9g; Thu, 16 Feb 2012 09:01:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxxDS-0001yr-Qi
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 09:01:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329382823!56931107!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27444 invoked from network); 16 Feb 2012 09:00:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 09:00:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 09:01:30 +0000
Message-Id: <4F3CD3F002000078000735F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 09:01:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Eric Camachat" <eric.camachat@gmail.com>,
	"Philipp Hahn" <hahn@univention.de>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
In-Reply-To: <201202160829.54814.hahn@univention.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Daniel Kiper <dkiper@net-space.pl>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
 linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 08:29, Philipp Hahn <hahn@univention.de> wrote:
> Hello,
> 
> Am Donnerstag 16 Februar 2012 02:22:30 schrieben Sie:
>> On Tue, Feb 14, 2012 at 10:07 AM, Eric Camachat <eric.camachat@gmail.com> 
> wrote:
>> > On Tue, Feb 14, 2012 at 12:07 AM, Philipp Hahn <hahn@univention.de> wrote:
>> Try to use HYPERVISOR_kexec_op() to find out where crash buffer is.
>> But it returned address that outside of total memory!
> 
> Yes, because the Hyervisor (which is running below your dom0 Linux kernel) 
> reserves the memory, so not even the dom0 kernel should be able to scribble 
> it. That's why you have to use the HYPERVIROS_OPs.
> 
> I've spend some time investigating this a month ago but finally did gave up. 
> 
> Here're some of my notes:
> - it should be possible to write a user-space tool (like kexec), which uses 
> HYPERVISOR_kexec_op() to load a crash-dump kernel.
> - you would need to copy some code from the linux-kernel to fill in some 
> data 
> structures.
> - the Linux kernel prepends the crash kernel with some assembly code, which 
> moves it to the final location on execution. This trampolin code would 
> possibly be  needed in your tool as well.
> 
> The other option I see would be to modify the current Linux kernel to use 
> HYPERVISOR_kexec_op() when used as a dom0 kernel.

You may want to get in touch with Daniel, who iirc started looking at
adding kexec support to the pv-ops kernel some time last year.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 09:01:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 09: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.xensource.com>)
	id 1RxxDU-0001z2-9g; Thu, 16 Feb 2012 09:01:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxxDS-0001yr-Qi
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 09:01:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329382823!56931107!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27444 invoked from network); 16 Feb 2012 09:00:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 09:00:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 09:01:30 +0000
Message-Id: <4F3CD3F002000078000735F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 09:01:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Eric Camachat" <eric.camachat@gmail.com>,
	"Philipp Hahn" <hahn@univention.de>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
In-Reply-To: <201202160829.54814.hahn@univention.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Daniel Kiper <dkiper@net-space.pl>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
 linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 08:29, Philipp Hahn <hahn@univention.de> wrote:
> Hello,
> 
> Am Donnerstag 16 Februar 2012 02:22:30 schrieben Sie:
>> On Tue, Feb 14, 2012 at 10:07 AM, Eric Camachat <eric.camachat@gmail.com> 
> wrote:
>> > On Tue, Feb 14, 2012 at 12:07 AM, Philipp Hahn <hahn@univention.de> wrote:
>> Try to use HYPERVISOR_kexec_op() to find out where crash buffer is.
>> But it returned address that outside of total memory!
> 
> Yes, because the Hyervisor (which is running below your dom0 Linux kernel) 
> reserves the memory, so not even the dom0 kernel should be able to scribble 
> it. That's why you have to use the HYPERVIROS_OPs.
> 
> I've spend some time investigating this a month ago but finally did gave up. 
> 
> Here're some of my notes:
> - it should be possible to write a user-space tool (like kexec), which uses 
> HYPERVISOR_kexec_op() to load a crash-dump kernel.
> - you would need to copy some code from the linux-kernel to fill in some 
> data 
> structures.
> - the Linux kernel prepends the crash kernel with some assembly code, which 
> moves it to the final location on execution. This trampolin code would 
> possibly be  needed in your tool as well.
> 
> The other option I see would be to modify the current Linux kernel to use 
> HYPERVISOR_kexec_op() when used as a dom0 kernel.

You may want to get in touch with Daniel, who iirc started looking at
adding kexec support to the pv-ops kernel some time last year.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 09:17:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 09: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.xensource.com>)
	id 1RxxSe-0002DV-Ps; Thu, 16 Feb 2012 09:17:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxxSc-0002DQ-GM
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 09:17:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329383819!2999950!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20522 invoked from network); 16 Feb 2012 09:17:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 09:17:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 09:17:25 +0000
Message-Id: <4F3CD79A02000078000735F9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 09:16:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
In-Reply-To: <11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/common/domctl.c |  8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> 
> Apparently, setting d->max_pages to something lower than d->tot_pages is
> used as a mechanism for controling a domain's footprint. It will result
> in all new page allocations failing.
> 
> This is a really bad idea with paging or sharing, as regular guest memory
> accesses may need to be satisfied by allocating new memory (either to
> page in or to unshare).
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>           * NB. We removed a check that new_max >= current tot_pages; this means
>           * that the domain will now be allowed to "ratchet" down to new_max. In
>           * the meantime, while tot > max, all new allocations are disallowed.
> +         *
> +         * Except that this is not a great idea for domains doing sharing or 
> +         * paging, as they need to perform new allocations on the fly.
>           */
> -        d->max_pages = new_max;
> +        if ( (new_max > d->max_pages) ||
> +             !((d->mem_event->paging.ring_page != NULL) ||
> +                d->arch.hvm_domain.mem_sharing_enabled) )
> +            d->max_pages = new_max;

I don't think this is appropriate here, as it will allow not only
paging/sharing allocations to succeed, but also such that aren't
intended to. I think that *if* an override to the limit enforcement
is needed, it ought to be implemented by passing a special flag
to the page allocator to have it make an exception. But that's
questionable in the first place - if a domain is told to shrink, it
ought to follow that directive (and the paging/sharing code then
probably should obtain a page from inside the guest; I realize
that might be problematic when sharing is enabled but paging
isn't).

Jan

>          ret = 0;
>          spin_unlock(&d->page_alloc_lock);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 09:17:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 09: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.xensource.com>)
	id 1RxxSe-0002DV-Ps; Thu, 16 Feb 2012 09:17:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxxSc-0002DQ-GM
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 09:17:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329383819!2999950!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20522 invoked from network); 16 Feb 2012 09:17:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 09:17:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 09:17:25 +0000
Message-Id: <4F3CD79A02000078000735F9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 09:16:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
In-Reply-To: <11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/common/domctl.c |  8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> 
> Apparently, setting d->max_pages to something lower than d->tot_pages is
> used as a mechanism for controling a domain's footprint. It will result
> in all new page allocations failing.
> 
> This is a really bad idea with paging or sharing, as regular guest memory
> accesses may need to be satisfied by allocating new memory (either to
> page in or to unshare).
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>           * NB. We removed a check that new_max >= current tot_pages; this means
>           * that the domain will now be allowed to "ratchet" down to new_max. In
>           * the meantime, while tot > max, all new allocations are disallowed.
> +         *
> +         * Except that this is not a great idea for domains doing sharing or 
> +         * paging, as they need to perform new allocations on the fly.
>           */
> -        d->max_pages = new_max;
> +        if ( (new_max > d->max_pages) ||
> +             !((d->mem_event->paging.ring_page != NULL) ||
> +                d->arch.hvm_domain.mem_sharing_enabled) )
> +            d->max_pages = new_max;

I don't think this is appropriate here, as it will allow not only
paging/sharing allocations to succeed, but also such that aren't
intended to. I think that *if* an override to the limit enforcement
is needed, it ought to be implemented by passing a special flag
to the page allocator to have it make an exception. But that's
questionable in the first place - if a domain is told to shrink, it
ought to follow that directive (and the paging/sharing code then
probably should obtain a page from inside the guest; I realize
that might be problematic when sharing is enabled but paging
isn't).

Jan

>          ret = 0;
>          spin_unlock(&d->page_alloc_lock);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 09:31:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 09: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.xensource.com>)
	id 1RxxgS-0002Qh-KL; Thu, 16 Feb 2012 09:31:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxxgQ-0002Qc-O9
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 09:31:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329384630!54482511!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5012 invoked from network); 16 Feb 2012 09:30:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 09:30:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 09:32:43 +0000
Message-Id: <4F3CDAF80200007800073601@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 09:31:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> - Add a VIRQ that the hypervisor can emit when reaching a low memory 
> threshold.

In this patch, which didn't make it to my inbox yet, you will want to
change this

+    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )

to

    if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )

to avoid the case (on 32-bit hypervisors) where total_avail_pages,
being just 'long', would get significant bits shifted out.

I'm further wondering whether the default value shouldn't be set
dynamically based on available memory and/or taking into account
an eventual dom0_mem= option.

Finally, rate limiting will be needed for sending the vIRQ - currently,
once below the threshold you're sending one on each and every
allocation (which may become harmful if the listener can't really do
anything about the situation).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 09:31:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 09: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.xensource.com>)
	id 1RxxgS-0002Qh-KL; Thu, 16 Feb 2012 09:31:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RxxgQ-0002Qc-O9
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 09:31:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329384630!54482511!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5012 invoked from network); 16 Feb 2012 09:30:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 09:30:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 09:32:43 +0000
Message-Id: <4F3CDAF80200007800073601@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 09:31:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329364623@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> - Add a VIRQ that the hypervisor can emit when reaching a low memory 
> threshold.

In this patch, which didn't make it to my inbox yet, you will want to
change this

+    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )

to

    if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )

to avoid the case (on 32-bit hypervisors) where total_avail_pages,
being just 'long', would get significant bits shifted out.

I'm further wondering whether the default value shouldn't be set
dynamically based on available memory and/or taking into account
an eventual dom0_mem= option.

Finally, rate limiting will be needed for sending the vIRQ - currently,
once below the threshold you're sending one on each and every
allocation (which may become harmful if the listener can't really do
anything about the situation).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:08:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxyFd-00039M-O2; Thu, 16 Feb 2012 10:07:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RxyFc-00039H-K5
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:07:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329386607!12128658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17095 invoked from network); 16 Feb 2012 10:03:28 -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;
	16 Feb 2012 10:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="10737544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 10:03:27 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 10:03:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120215224253.GA18762@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
Date: Thu, 16 Feb 2012 10:02:51 +0000
Message-ID: <1329386571.4520.44.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 22:42 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> It also needs this:
> 
> From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 15 Feb 2012 17:39:46 -0500
> Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
>  built for it.
> 
> Otherwise we end up:
> 
> BUG: unable to handle kernel paging request at ffff88004000c0c8
> IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> PGD 1806063 PUD 0
> 22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
> 00 [#1] SMP
> CPU 0
> Modules linked in:
> 
> Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
> RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
> .. snip.
> Call Trace:
>  [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
>  [<ffffffff810f4eab>] __free_pages+0x1b/0x40
>  [<ffffffff810f4f1a>] free_pages+0x4a/0x60
>  [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
>  [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
>  [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
>  [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
>  [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/net/xen-netfront.c |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 0223552..1eadd90 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -29,6 +29,8 @@
>   * IN THE SOFTWARE.
>   */
>  
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/netdevice.h>
> @@ -66,7 +68,7 @@ struct netfront_cb {
>  
>  #define GRANT_INVALID_REF	0
>  
> -#define XENNET_MAX_RING_PAGE_ORDER 2
> +#define XENNET_MAX_RING_PAGE_ORDER 4

I guess this is you tuning with page order? And here is not the only one
place you changed?

As a matter of fact, in the previous patch 8 I encode hard limit 2 on
the ring page order, your change here will stop FE / BE from connecting.

I think I will also need to change this to something like

  #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER

to remind people to modify that value. 

>  #define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
>  
>  #define NET_TX_RING_SIZE(_nr_pages)					\
> @@ -1611,6 +1613,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		info->tx_ring_page_order = 0;
>  		dev_info(&dev->dev, "single tx ring\n");
>  	} else {
> +		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> +				max_tx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> +			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
>  		info->tx_ring_page_order = max_tx_ring_page_order;
>  		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
>  			 max_tx_ring_page_order);
> @@ -1642,6 +1649,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		dev_info(&dev->dev, "single rx ring\n");
>  	} else {
>  		info->rx_ring_page_order = max_rx_ring_page_order;
> +		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> +				max_rx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> +			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
>  		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
>  			 max_rx_ring_page_order);
>  	}

Thanks for this, I will squash it into my patch.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:08:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxyFd-00039M-O2; Thu, 16 Feb 2012 10:07:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RxyFc-00039H-K5
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:07:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329386607!12128658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17095 invoked from network); 16 Feb 2012 10:03:28 -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;
	16 Feb 2012 10:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="10737544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 10:03:27 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 10:03:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120215224253.GA18762@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
Date: Thu, 16 Feb 2012 10:02:51 +0000
Message-ID: <1329386571.4520.44.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 22:42 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> It also needs this:
> 
> From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 15 Feb 2012 17:39:46 -0500
> Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
>  built for it.
> 
> Otherwise we end up:
> 
> BUG: unable to handle kernel paging request at ffff88004000c0c8
> IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> PGD 1806063 PUD 0
> 22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
> 00 [#1] SMP
> CPU 0
> Modules linked in:
> 
> Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
> RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
> .. snip.
> Call Trace:
>  [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
>  [<ffffffff810f4eab>] __free_pages+0x1b/0x40
>  [<ffffffff810f4f1a>] free_pages+0x4a/0x60
>  [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
>  [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
>  [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
>  [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
>  [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/net/xen-netfront.c |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 0223552..1eadd90 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -29,6 +29,8 @@
>   * IN THE SOFTWARE.
>   */
>  
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/netdevice.h>
> @@ -66,7 +68,7 @@ struct netfront_cb {
>  
>  #define GRANT_INVALID_REF	0
>  
> -#define XENNET_MAX_RING_PAGE_ORDER 2
> +#define XENNET_MAX_RING_PAGE_ORDER 4

I guess this is you tuning with page order? And here is not the only one
place you changed?

As a matter of fact, in the previous patch 8 I encode hard limit 2 on
the ring page order, your change here will stop FE / BE from connecting.

I think I will also need to change this to something like

  #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER

to remind people to modify that value. 

>  #define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
>  
>  #define NET_TX_RING_SIZE(_nr_pages)					\
> @@ -1611,6 +1613,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		info->tx_ring_page_order = 0;
>  		dev_info(&dev->dev, "single tx ring\n");
>  	} else {
> +		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> +				max_tx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> +			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
>  		info->tx_ring_page_order = max_tx_ring_page_order;
>  		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
>  			 max_tx_ring_page_order);
> @@ -1642,6 +1649,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		dev_info(&dev->dev, "single rx ring\n");
>  	} else {
>  		info->rx_ring_page_order = max_rx_ring_page_order;
> +		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> +				max_rx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> +			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
>  		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
>  			 max_rx_ring_page_order);
>  	}

Thanks for this, I will squash it into my patch.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:12:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxyJw-0003IX-JQ; Thu, 16 Feb 2012 10:12:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RxyJt-0003IL-3B
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:12:10 +0000
Received: from [85.158.139.83:26928] by server-12.bemta-5.messagelabs.com id
	8F/96-24595-876DC3F4; Thu, 16 Feb 2012 10:12:08 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329387124!15303429!1
X-Originating-IP: [66.94.236.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21612 invoked from network); 16 Feb 2012 10:12:05 -0000
Received: from nm13-vm0.access.bullet.mail.mud.yahoo.com (HELO
	nm13-vm0.access.bullet.mail.mud.yahoo.com) (66.94.236.13)
	by server-3.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 10:12:05 -0000
Received: from [66.94.237.198] by nm13.access.bullet.mail.mud.yahoo.com with
	NNFMP; 16 Feb 2012 10:12:04 -0000
Received: from [66.94.237.96] by tm9.access.bullet.mail.mud.yahoo.com with
	NNFMP; 16 Feb 2012 10:12:04 -0000
Received: from [127.0.0.1] by omp1001.access.mail.mud.yahoo.com with NNFMP;
	16 Feb 2012 10:12:03 -0000
X-Yahoo-Newman-Id: 985743.60476.bm@omp1001.access.mail.mud.yahoo.com
Received: (qmail 37439 invoked from network); 16 Feb 2012 10:12:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1329387123; bh=FKBmce0AgND6Bmxcs6C1KNtvlQaqmC8RWf51/E/5c0Y=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=jwNvSo08Xhb3Cs40Ej/5NRGg3gPdT1rS4uL9BVhF5g+mZb4BbXTmMuWBfe4htgOJ2ru9+d9mFhhS99BTmvzqHRR85wIHL7MjEHIPUzNSHrlkcTjoe0lpG4NQQk5sVNlGi/RTJZ2qFic5T4C9x+HESQFwq9p73SL5q/3J1BZ6YwA=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: QpLsnTkVM1nURU0AWcSY775xUVnW_1kzW1XzQXvhAKhv30x
	7JJgEY2kEiFr_aPCzpFnQ4Edb7Ey09kWhkNa8QcY99Xy0rkvNrKBZCjdsavT
	RtAJ.4blGzxL_JB2RAp.pORS_LNi2CwD2SPgqIxL3yixF1N1.hY27wcdS4.n
	gKbImfqpFLSynL8mLLRAwbASr2TsiQTbmU8.nrqEtzmnExGsjDK6CiOniXF3
	FY1vT3jo2tQ5lqhNSByPWjsRSFIDGG6egt4nu4TEAyzzB4ttA8o.ZzyzeT9X
	yeQHdSePIRRAKyPMT6DV6r29VOZUwD7OZEU7Al9fpGPwZjpbeVCgG7mn11uY
	83PmSAbsFFQuxmIZwmL4soWMDM7RCB6ReZ4KuWA48kpZlJ8X73GuKvwg0zQE
	Agalmkr8MNhPgBscb4f8ozpop3VMMYqZR.5IZL70J2nxOm3XTPIAsjyThd2c
	lWqu48hRYjG7yHDMJhL.V6z2N8rd5R2QgxQ_7l8z7LfsLo0hT8P2ejFm2sor
	.S0rImJbTwf2kkCH8UbE9wiDkgT2WrbNlLXzysEva19BTS.BiR4KZqR3H_cI v
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.191 with plain)
	by smtp106.sbc.mail.mud.yahoo.com with SMTP;
	16 Feb 2012 02:12:02 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: xen-users@lists.xen.org
Date: Thu, 16 Feb 2012 05:11:52 -0500
Message-ID: <51142288.L1Ice6IuWj@dell4550>
User-Agent: KMail/4.8.0 (Linux/3.1.9-1.4-default; KDE/4.8.0; i686; ; )
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Problems with stubdoms, and xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1531123294308609982=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1531123294308609982==
Content-Type: multipart/alternative; boundary="nextPart7831939.5g3HAvzpyp"
Content-Transfer-Encoding: 7Bit


--nextPart7831939.5g3HAvzpyp
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

Pls cc: me in replies, as I am not subscribed.

System is fedora 16, with rawhide xen 4.1.2, and rawhide 3.3.0-rc3 (with the 
debug options turned off.

I finally got stubdoms to work recently, with some minor problems. For those 
interested in how, I describe how after I describe the problems.

1) After my winxp hvm domu, started with a stubdom, got some windows updates 
yesterday, I restarted (not shutdown), and the new domain hung in pause:

root@insp6400 02/16/12  3:02AM:~
[543] > xl list
Name                                     ID   Mem VCPUs      State   Time(s)
Domain-0                                  0  1052     2     r-----   17288.1
winxp                                     8   751     1     --p---       0.0

'xl unpause'-ing it leaves all dashes in the State, and Time remains at 0.0

Since 'xenstore-ls /vm' lists 'winxp' as having the uuid I specified in the 
hvm config, this is indeed the main domain, not the stubdom, which would be 
called 'winxp-dm', and have Mem equal to 32.

I tried playing around with the methodology used in 
/usr/lib/xen/bin/stubdom.sh to create a stubdom with 'xm'. I saved the stubdom 
config file generated, in /etc/xen, and manually issued the 'xm create' line 
from stubdom.sh, substituting 'xl' for 'xm'. The original line is:

xm create -c ${stubdom_configdir}/$domname-dm target=$domid memory=32 
extra="$extra" < /tmp/$domname-dm &

and with the config file:

kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
disk = [ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]
vif = [ 'mac=00:16:3e:23:1d:36, bridge=xenbr0, model=e1000' ]
vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=1, vncdisplay=3, vncpasswd= ']

I executed:

xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"

and only got a syntax error on the '-d'. Not that I was expecting this to 
work: lsof shows qemu-dm (the stubdom from a working 'xl create') has a socket 
and a fifo open, and I have no idea how to set this up. There are no sockets 
in /tmp or /var/lib/xen* that don't correspond to the startup of xend.

So my question is: is this a bug, and is it fixed in xen 4.2? Since windows 
restarts by itself fairly often enough, this requires manual intervention.

2) I'm having a strange problem right after I get a xen update from rawhide: 
stubdoms stop working for a day after wards. It happened with fedora xen 
4.1.2-7 and -8. The next time it happens, I'll look at whether something in 
/var/lib/xen* changed.

Just to be complete, I'll repeat some continuing problems with xl I posted at 
the end of October in the thread 'Problems with 'xl create winxp' (hvm) on Xen 
4.1.2 (also affects GPLPV)':

3) Specifying vncviewer=1 will automatically start a vnc viewer for you when 
you 'xm create' an hvm domain. (Sadly, this never worked for a pv domain. You 
have to use the xm/xl vncviewer domainname command.) This does not work with 
'xl create'.

Yes, I know about 'xl create --vncviewer' - it doesn't do anything. You still 
have to give a separate 'xl vncviewer <domanme>'.

4) The 'localtime=1' option in your config is ignored by xl. This works with 
xm. Xl will not honor the rtc_timeoffset option either.

The answer given to the two above problems at the time was essentially that 
they had not been implemented. Have they been implemented in xen 4.2 yet? They 
are not mentioned in the xl.cfg documentation, which I assume is for 4.2:

http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html

Now for what does work to get a stubdom up and running. I used the below 
config, with python commented out to keep xl happy. Note the spice options, 
and 'device_model_stubdomain_override = 1' don't actually do anything (the 
latter contrary to what someone else reported). I assume that they will become 
functional in xen 4.2. Also, while device_model_args does indeed add '-
localtime' to the end of the qemu-dm args, it's still ineffective.

Two interesting observations: 1) 'xm create' is useless for creating stubdoms 
- I always get a page fault reported in qemu-dm-winxp.log (the log for the 
main domain, not the stubdom). In exploring this, I noticed that 'xm create' 
uses /usr/lib/xen/bin/stubdom.sh. You can add a 'set -x' to this file, and the 
trace will show up in qemu-dm-winxp.log. 'xl create' does not use this 
program. You can move it completely away from /usr/lib/xen/bin, and the 
stubdom will still be created. The device_model option is just telling xl not 
to use the normal qemu-dm method.

And 2) If you have GPLPV installed in your domain, it completely takes over. 
Booting with GPLPV enabled is no faster with stubdoms as without. Booting with 
/nogplpv is just as slow as if you booted without stubdoms. I suspect 
xenpci.sys is overriding what stubdoms is doing. The only part of the boot 
process that is faster is the initial grub screen. (This is an iscsi export 
from a dual-boot server.) After Windows starts to boot, it reverts back to 
gplpv (or /nogplpv) speeds. The same holds true for a linux hvm: a normal hvm 
domu with PvHvm drivers is no faster than a linux stubdom (w/no PvHvm). (I 
didn't try both at the same time.)

#import os, re
#arch = os.uname()[4]
#if re.search('64', arch):
#    arch_libdir = 'lib64'
#else:
#    arch_libdir = 'lib'

name = "winxp"
builder='hvm'
memory = "768"
uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
#ostype = "hvm"
on_reboot = "restart"
on_crash = "restart"
on_poweroff = "destroy"
vcpus = "2"
viridian=1
#
#kernel = "/usr/lib/xen/boot/hvmloader"
kernel = "hvmloader"
acpi=1
apic=1
boot= "cda"
# New stuff
#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#device_model = '/usr/lib/xen/bin/qemu-dm'
#device_model = 'qemu-dm'
# must comment out 'soundhw' below for stubdom
device_model = 'stubdom-dm'
device_model_stubdomain_override = 1
device_model_args=[ "-localtime" ]
#
keymap='en-us'
localtime=1
#rtc_timeoffset=' -14400'
rtc_timeoffset=' -18000'
pae=1
nx=1
serial='pty'
#serial = "/dev/ttyS0"
#   enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='es1370'
# enable stdvga, default = 0 (use cirrus logic device model)
#stdvga=1
videoram=16
stdvga=0
#usbdevice="mouse"
usbdevice="tablet"
xen_extended_power_mgmt = 0
#
#disk=[ 'tap2:aio:/var/lib/xen/images/winxp,hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
#disk=[ 'file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
#disk=[ 'file:/var/lib/xen/images/winxp,ioemu:hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
disk=[ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/sr0,hdc:cdrom,r' ]
#
#vif = [ 'mac=00:16:3e:23:1d:36, script=/etc/xen/scripts/vif-bridge, 
bridge=xenbr0, model=rtl8139' ]
vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=/etc/xen/scripts/vif-
bridge, bridge=xenbr0, model=e1000' ]
#vif = [ 'mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge, bridge = 
xenbr0' ]
#
sdl=0
#vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3, vncpasswd= ']
vnc=1
vnclisten="0.0.0.0"
#vnclisten="192.168.1.0"
# set VNC display number, default = domid
vncdisplay=3
# try to find an unused port for the VNC server, default = 1
vncunused=0
vncviewer=1
vncconsole=1
monitor=1
vncpasswd=""

#spice
spice=1
spiceport=6000 
spicehost='192.168.1.100'
spicedisable_ticketing = 0 # default is 0 
spicepasswd = ''

--nextPart7831939.5g3HAvzpyp
Content-Transfer-Encoding: 7Bit
Content-Type: text/html; charset="us-ascii"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'Courier [Adobe]'; font-size:9pt; font-weight:400; font-style:normal;">
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Pls cc: me in replies, as I am not subscribed.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">System is fedora 16, with rawhide xen 4.1.2, and rawhide 3.3.0-rc3 (with the debug options turned off.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I finally got stubdoms to work recently, with some minor problems. For those interested in how, I describe how after I describe the problems.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">1) After my winxp hvm domu, started with a stubdom, got some windows updates yesterday, I restarted (not shutdown), and the new domain hung in pause:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">root@insp6400 02/16/12  3:02AM:~</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">[543] &gt; xl list</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Name                                     ID   Mem VCPUs      State   Time(s)</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Domain-0                                  0  1052     2     r-----   17288.1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">winxp                                     8   751     1     --p---       0.0</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">'xl unpause'-ing it leaves all dashes in the State, and Time remains at 0.0</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Since 'xenstore-ls /vm' lists 'winxp' as having the uuid I specified in the hvm config, this is indeed the main domain, not the stubdom, which would be called 'winxp-dm', and have Mem equal to 32.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I tried playing around with the methodology used in /usr/lib/xen/bin/stubdom.sh to create a stubdom with 'xm'. I saved the stubdom config file generated, in /etc/xen, and manually issued the 'xm create' line from stubdom.sh, substituting 'xl' for 'xm'. The original line is:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xm create -c ${stubdom_configdir}/$domname-dm target=$domid memory=32 extra=&quot;$extra&quot; &lt; /tmp/$domname-dm &amp;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">and with the config file:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">kernel = &quot;/usr/lib/xen/boot/ioemu-stubdom.gz&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">disk = [ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vif = [ 'mac=00:16:3e:23:1d:36, bridge=xenbr0, model=e1000' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=1, vncdisplay=3, vncpasswd= ']</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I executed:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xl create /etc/xen/winxp-dm target=8 memory=32 extra=&quot; -d 8&quot;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">and only got a syntax error on the '-d'. Not that I was expecting this to work: lsof shows qemu-dm (the stubdom from a working 'xl create') has a socket and a fifo open, and I have no idea how to set this up. There are no sockets in /tmp or /var/lib/xen* that don't correspond to the startup of xend.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">So my question is: is this a bug, and is it fixed in xen 4.2? Since windows restarts by itself fairly often enough, this requires manual intervention.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">2) I'm having a strange problem right after I get a xen update from rawhide: stubdoms stop working for a day after wards. It happened with fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at whether something in /var/lib/xen* changed.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Just to be complete, I'll repeat some continuing problems with xl I posted at the end of October in the thread 'Problems with 'xl create winxp' (hvm) on Xen 4.1.2 (also affects GPLPV)':</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">3) Specifying vncviewer=1 will automatically start a vnc viewer for you when you 'xm create' an hvm domain. (Sadly, this never worked for a pv domain. You have to use the xm/xl vncviewer domainname command.) This does not work with 'xl create'.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Yes, I know about 'xl create --vncviewer' - it doesn't do anything. You still have to give a separate 'xl vncviewer &lt;domanme&gt;'.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">4) The 'localtime=1' option in your config is ignored by xl. This works with </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xm. Xl will not honor the rtc_timeoffset option either.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">The answer given to the two above problems at the time was essentially that they had not been implemented. Have they been implemented in xen 4.2 yet? They are not mentioned in the xl.cfg documentation, which I assume is for 4.2:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Now for what does work to get a stubdom up and running. I used the below config, with python commented out to keep xl happy. Note the spice options, and 'device_model_stubdomain_override = 1' don't actually do anything (the latter contrary to what someone else reported). I assume that they will become functional in xen 4.2. Also, while device_model_args does indeed add '-localtime' to the end of the qemu-dm args, it's still ineffective.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Two interesting observations: 1) 'xm create' is useless for creating stubdoms - I always get a page fault reported in qemu-dm-winxp.log (the log for the main domain, not the stubdom). In exploring this, I noticed that 'xm create' uses /usr/lib/xen/bin/stubdom.sh. You can add a 'set -x' to this file, and the trace will show up in qemu-dm-winxp.log. 'xl create' does not use this program. You can move it completely away from /usr/lib/xen/bin, and the stubdom will still be created. The device_model option is just telling xl not to use the normal qemu-dm method.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">And 2) If you have GPLPV installed in your domain, it completely takes over. Booting with GPLPV enabled is no faster with stubdoms as without. Booting with /nogplpv is just as slow as if you booted without stubdoms. I suspect xenpci.sys is overriding what stubdoms is doing. The only part of the boot process that is faster is the initial grub screen. (This is an iscsi export from a dual-boot server.) After Windows starts to boot, it reverts back to gplpv (or /nogplpv) speeds. The same holds true for a linux hvm: a normal hvm domu with PvHvm drivers is no faster than a linux stubdom (w/no PvHvm). (I didn't try both at the same time.)</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#import os, re</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#arch = os.uname()[4]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#if re.search('64', arch):</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#    arch_libdir = 'lib64'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#else:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#    arch_libdir = 'lib'</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">name = &quot;winxp&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">builder='hvm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">memory = &quot;768&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">uuid = &quot;6c7de04e-df10-caa8-bb2a-8368246225c1&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#ostype = &quot;hvm&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">on_reboot = &quot;restart&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">on_crash = &quot;restart&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">on_poweroff = &quot;destroy&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vcpus = &quot;2&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">viridian=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#kernel = &quot;/usr/lib/xen/boot/hvmloader&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">kernel = &quot;hvmloader&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">acpi=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">apic=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">boot= &quot;cda&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># New stuff</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#device_model = '/usr/lib/xen/bin/qemu-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#device_model = 'qemu-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># must comment out 'soundhw' below for stubdom</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">device_model = 'stubdom-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">device_model_stubdomain_override = 1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">device_model_args=[ &quot;-localtime&quot; ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">keymap='en-us'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">localtime=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#rtc_timeoffset=' -14400'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">rtc_timeoffset=' -18000'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">pae=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">nx=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">serial='pty'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#serial = &quot;/dev/ttyS0&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#   enable sound card support, [sb16|es1370|all|..,..], default none</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#soundhw='es1370'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># enable stdvga, default = 0 (use cirrus logic device model)</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#stdvga=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">videoram=16</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">stdvga=0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#usbdevice=&quot;mouse&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">usbdevice=&quot;tablet&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xen_extended_power_mgmt = 0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#disk=[ 'tap2:aio:/var/lib/xen/images/winxp,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#disk=[ 'file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#disk=[ 'file:/var/lib/xen/images/winxp,ioemu:hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">disk=[ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/sr0,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vif = [ 'mac=00:16:3e:23:1d:36, script=/etc/xen/scripts/vif-bridge, bridge=xenbr0, model=rtl8139' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=/etc/xen/scripts/vif-bridge, bridge=xenbr0, model=e1000' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vif = [ 'mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge, bridge = xenbr0' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">sdl=0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3, vncpasswd= ']</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vnc=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vnclisten=&quot;0.0.0.0&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vnclisten=&quot;192.168.1.0&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># set VNC display number, default = domid</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncdisplay=3</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># try to find an unused port for the VNC server, default = 1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncunused=0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncviewer=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncconsole=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">monitor=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncpasswd=&quot;&quot;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#spice</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spice=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spiceport=6000 </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spicehost='192.168.1.100'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spicedisable_ticketing = 0 # default is 0 </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spicepasswd = ''</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p></body></html>
--nextPart7831939.5g3HAvzpyp--



--===============1531123294308609982==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1531123294308609982==--



From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:12:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxyJw-0003IX-JQ; Thu, 16 Feb 2012 10:12:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RxyJt-0003IL-3B
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:12:10 +0000
Received: from [85.158.139.83:26928] by server-12.bemta-5.messagelabs.com id
	8F/96-24595-876DC3F4; Thu, 16 Feb 2012 10:12:08 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329387124!15303429!1
X-Originating-IP: [66.94.236.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21612 invoked from network); 16 Feb 2012 10:12:05 -0000
Received: from nm13-vm0.access.bullet.mail.mud.yahoo.com (HELO
	nm13-vm0.access.bullet.mail.mud.yahoo.com) (66.94.236.13)
	by server-3.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 10:12:05 -0000
Received: from [66.94.237.198] by nm13.access.bullet.mail.mud.yahoo.com with
	NNFMP; 16 Feb 2012 10:12:04 -0000
Received: from [66.94.237.96] by tm9.access.bullet.mail.mud.yahoo.com with
	NNFMP; 16 Feb 2012 10:12:04 -0000
Received: from [127.0.0.1] by omp1001.access.mail.mud.yahoo.com with NNFMP;
	16 Feb 2012 10:12:03 -0000
X-Yahoo-Newman-Id: 985743.60476.bm@omp1001.access.mail.mud.yahoo.com
Received: (qmail 37439 invoked from network); 16 Feb 2012 10:12:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1329387123; bh=FKBmce0AgND6Bmxcs6C1KNtvlQaqmC8RWf51/E/5c0Y=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=jwNvSo08Xhb3Cs40Ej/5NRGg3gPdT1rS4uL9BVhF5g+mZb4BbXTmMuWBfe4htgOJ2ru9+d9mFhhS99BTmvzqHRR85wIHL7MjEHIPUzNSHrlkcTjoe0lpG4NQQk5sVNlGi/RTJZ2qFic5T4C9x+HESQFwq9p73SL5q/3J1BZ6YwA=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: QpLsnTkVM1nURU0AWcSY775xUVnW_1kzW1XzQXvhAKhv30x
	7JJgEY2kEiFr_aPCzpFnQ4Edb7Ey09kWhkNa8QcY99Xy0rkvNrKBZCjdsavT
	RtAJ.4blGzxL_JB2RAp.pORS_LNi2CwD2SPgqIxL3yixF1N1.hY27wcdS4.n
	gKbImfqpFLSynL8mLLRAwbASr2TsiQTbmU8.nrqEtzmnExGsjDK6CiOniXF3
	FY1vT3jo2tQ5lqhNSByPWjsRSFIDGG6egt4nu4TEAyzzB4ttA8o.ZzyzeT9X
	yeQHdSePIRRAKyPMT6DV6r29VOZUwD7OZEU7Al9fpGPwZjpbeVCgG7mn11uY
	83PmSAbsFFQuxmIZwmL4soWMDM7RCB6ReZ4KuWA48kpZlJ8X73GuKvwg0zQE
	Agalmkr8MNhPgBscb4f8ozpop3VMMYqZR.5IZL70J2nxOm3XTPIAsjyThd2c
	lWqu48hRYjG7yHDMJhL.V6z2N8rd5R2QgxQ_7l8z7LfsLo0hT8P2ejFm2sor
	.S0rImJbTwf2kkCH8UbE9wiDkgT2WrbNlLXzysEva19BTS.BiR4KZqR3H_cI v
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.191 with plain)
	by smtp106.sbc.mail.mud.yahoo.com with SMTP;
	16 Feb 2012 02:12:02 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: xen-users@lists.xen.org
Date: Thu, 16 Feb 2012 05:11:52 -0500
Message-ID: <51142288.L1Ice6IuWj@dell4550>
User-Agent: KMail/4.8.0 (Linux/3.1.9-1.4-default; KDE/4.8.0; i686; ; )
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Problems with stubdoms, and xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1531123294308609982=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1531123294308609982==
Content-Type: multipart/alternative; boundary="nextPart7831939.5g3HAvzpyp"
Content-Transfer-Encoding: 7Bit


--nextPart7831939.5g3HAvzpyp
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

Pls cc: me in replies, as I am not subscribed.

System is fedora 16, with rawhide xen 4.1.2, and rawhide 3.3.0-rc3 (with the 
debug options turned off.

I finally got stubdoms to work recently, with some minor problems. For those 
interested in how, I describe how after I describe the problems.

1) After my winxp hvm domu, started with a stubdom, got some windows updates 
yesterday, I restarted (not shutdown), and the new domain hung in pause:

root@insp6400 02/16/12  3:02AM:~
[543] > xl list
Name                                     ID   Mem VCPUs      State   Time(s)
Domain-0                                  0  1052     2     r-----   17288.1
winxp                                     8   751     1     --p---       0.0

'xl unpause'-ing it leaves all dashes in the State, and Time remains at 0.0

Since 'xenstore-ls /vm' lists 'winxp' as having the uuid I specified in the 
hvm config, this is indeed the main domain, not the stubdom, which would be 
called 'winxp-dm', and have Mem equal to 32.

I tried playing around with the methodology used in 
/usr/lib/xen/bin/stubdom.sh to create a stubdom with 'xm'. I saved the stubdom 
config file generated, in /etc/xen, and manually issued the 'xm create' line 
from stubdom.sh, substituting 'xl' for 'xm'. The original line is:

xm create -c ${stubdom_configdir}/$domname-dm target=$domid memory=32 
extra="$extra" < /tmp/$domname-dm &

and with the config file:

kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
disk = [ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]
vif = [ 'mac=00:16:3e:23:1d:36, bridge=xenbr0, model=e1000' ]
vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=1, vncdisplay=3, vncpasswd= ']

I executed:

xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"

and only got a syntax error on the '-d'. Not that I was expecting this to 
work: lsof shows qemu-dm (the stubdom from a working 'xl create') has a socket 
and a fifo open, and I have no idea how to set this up. There are no sockets 
in /tmp or /var/lib/xen* that don't correspond to the startup of xend.

So my question is: is this a bug, and is it fixed in xen 4.2? Since windows 
restarts by itself fairly often enough, this requires manual intervention.

2) I'm having a strange problem right after I get a xen update from rawhide: 
stubdoms stop working for a day after wards. It happened with fedora xen 
4.1.2-7 and -8. The next time it happens, I'll look at whether something in 
/var/lib/xen* changed.

Just to be complete, I'll repeat some continuing problems with xl I posted at 
the end of October in the thread 'Problems with 'xl create winxp' (hvm) on Xen 
4.1.2 (also affects GPLPV)':

3) Specifying vncviewer=1 will automatically start a vnc viewer for you when 
you 'xm create' an hvm domain. (Sadly, this never worked for a pv domain. You 
have to use the xm/xl vncviewer domainname command.) This does not work with 
'xl create'.

Yes, I know about 'xl create --vncviewer' - it doesn't do anything. You still 
have to give a separate 'xl vncviewer <domanme>'.

4) The 'localtime=1' option in your config is ignored by xl. This works with 
xm. Xl will not honor the rtc_timeoffset option either.

The answer given to the two above problems at the time was essentially that 
they had not been implemented. Have they been implemented in xen 4.2 yet? They 
are not mentioned in the xl.cfg documentation, which I assume is for 4.2:

http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html

Now for what does work to get a stubdom up and running. I used the below 
config, with python commented out to keep xl happy. Note the spice options, 
and 'device_model_stubdomain_override = 1' don't actually do anything (the 
latter contrary to what someone else reported). I assume that they will become 
functional in xen 4.2. Also, while device_model_args does indeed add '-
localtime' to the end of the qemu-dm args, it's still ineffective.

Two interesting observations: 1) 'xm create' is useless for creating stubdoms 
- I always get a page fault reported in qemu-dm-winxp.log (the log for the 
main domain, not the stubdom). In exploring this, I noticed that 'xm create' 
uses /usr/lib/xen/bin/stubdom.sh. You can add a 'set -x' to this file, and the 
trace will show up in qemu-dm-winxp.log. 'xl create' does not use this 
program. You can move it completely away from /usr/lib/xen/bin, and the 
stubdom will still be created. The device_model option is just telling xl not 
to use the normal qemu-dm method.

And 2) If you have GPLPV installed in your domain, it completely takes over. 
Booting with GPLPV enabled is no faster with stubdoms as without. Booting with 
/nogplpv is just as slow as if you booted without stubdoms. I suspect 
xenpci.sys is overriding what stubdoms is doing. The only part of the boot 
process that is faster is the initial grub screen. (This is an iscsi export 
from a dual-boot server.) After Windows starts to boot, it reverts back to 
gplpv (or /nogplpv) speeds. The same holds true for a linux hvm: a normal hvm 
domu with PvHvm drivers is no faster than a linux stubdom (w/no PvHvm). (I 
didn't try both at the same time.)

#import os, re
#arch = os.uname()[4]
#if re.search('64', arch):
#    arch_libdir = 'lib64'
#else:
#    arch_libdir = 'lib'

name = "winxp"
builder='hvm'
memory = "768"
uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
#ostype = "hvm"
on_reboot = "restart"
on_crash = "restart"
on_poweroff = "destroy"
vcpus = "2"
viridian=1
#
#kernel = "/usr/lib/xen/boot/hvmloader"
kernel = "hvmloader"
acpi=1
apic=1
boot= "cda"
# New stuff
#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#device_model = '/usr/lib/xen/bin/qemu-dm'
#device_model = 'qemu-dm'
# must comment out 'soundhw' below for stubdom
device_model = 'stubdom-dm'
device_model_stubdomain_override = 1
device_model_args=[ "-localtime" ]
#
keymap='en-us'
localtime=1
#rtc_timeoffset=' -14400'
rtc_timeoffset=' -18000'
pae=1
nx=1
serial='pty'
#serial = "/dev/ttyS0"
#   enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='es1370'
# enable stdvga, default = 0 (use cirrus logic device model)
#stdvga=1
videoram=16
stdvga=0
#usbdevice="mouse"
usbdevice="tablet"
xen_extended_power_mgmt = 0
#
#disk=[ 'tap2:aio:/var/lib/xen/images/winxp,hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
#disk=[ 'file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
#disk=[ 'file:/var/lib/xen/images/winxp,ioemu:hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
disk=[ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/sr0,hdc:cdrom,r' ]
#
#vif = [ 'mac=00:16:3e:23:1d:36, script=/etc/xen/scripts/vif-bridge, 
bridge=xenbr0, model=rtl8139' ]
vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=/etc/xen/scripts/vif-
bridge, bridge=xenbr0, model=e1000' ]
#vif = [ 'mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge, bridge = 
xenbr0' ]
#
sdl=0
#vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3, vncpasswd= ']
vnc=1
vnclisten="0.0.0.0"
#vnclisten="192.168.1.0"
# set VNC display number, default = domid
vncdisplay=3
# try to find an unused port for the VNC server, default = 1
vncunused=0
vncviewer=1
vncconsole=1
monitor=1
vncpasswd=""

#spice
spice=1
spiceport=6000 
spicehost='192.168.1.100'
spicedisable_ticketing = 0 # default is 0 
spicepasswd = ''

--nextPart7831939.5g3HAvzpyp
Content-Transfer-Encoding: 7Bit
Content-Type: text/html; charset="us-ascii"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'Courier [Adobe]'; font-size:9pt; font-weight:400; font-style:normal;">
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Pls cc: me in replies, as I am not subscribed.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">System is fedora 16, with rawhide xen 4.1.2, and rawhide 3.3.0-rc3 (with the debug options turned off.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I finally got stubdoms to work recently, with some minor problems. For those interested in how, I describe how after I describe the problems.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">1) After my winxp hvm domu, started with a stubdom, got some windows updates yesterday, I restarted (not shutdown), and the new domain hung in pause:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">root@insp6400 02/16/12  3:02AM:~</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">[543] &gt; xl list</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Name                                     ID   Mem VCPUs      State   Time(s)</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Domain-0                                  0  1052     2     r-----   17288.1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">winxp                                     8   751     1     --p---       0.0</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">'xl unpause'-ing it leaves all dashes in the State, and Time remains at 0.0</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Since 'xenstore-ls /vm' lists 'winxp' as having the uuid I specified in the hvm config, this is indeed the main domain, not the stubdom, which would be called 'winxp-dm', and have Mem equal to 32.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I tried playing around with the methodology used in /usr/lib/xen/bin/stubdom.sh to create a stubdom with 'xm'. I saved the stubdom config file generated, in /etc/xen, and manually issued the 'xm create' line from stubdom.sh, substituting 'xl' for 'xm'. The original line is:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xm create -c ${stubdom_configdir}/$domname-dm target=$domid memory=32 extra=&quot;$extra&quot; &lt; /tmp/$domname-dm &amp;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">and with the config file:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">kernel = &quot;/usr/lib/xen/boot/ioemu-stubdom.gz&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">disk = [ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vif = [ 'mac=00:16:3e:23:1d:36, bridge=xenbr0, model=e1000' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=1, vncdisplay=3, vncpasswd= ']</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I executed:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xl create /etc/xen/winxp-dm target=8 memory=32 extra=&quot; -d 8&quot;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">and only got a syntax error on the '-d'. Not that I was expecting this to work: lsof shows qemu-dm (the stubdom from a working 'xl create') has a socket and a fifo open, and I have no idea how to set this up. There are no sockets in /tmp or /var/lib/xen* that don't correspond to the startup of xend.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">So my question is: is this a bug, and is it fixed in xen 4.2? Since windows restarts by itself fairly often enough, this requires manual intervention.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">2) I'm having a strange problem right after I get a xen update from rawhide: stubdoms stop working for a day after wards. It happened with fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at whether something in /var/lib/xen* changed.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Just to be complete, I'll repeat some continuing problems with xl I posted at the end of October in the thread 'Problems with 'xl create winxp' (hvm) on Xen 4.1.2 (also affects GPLPV)':</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">3) Specifying vncviewer=1 will automatically start a vnc viewer for you when you 'xm create' an hvm domain. (Sadly, this never worked for a pv domain. You have to use the xm/xl vncviewer domainname command.) This does not work with 'xl create'.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Yes, I know about 'xl create --vncviewer' - it doesn't do anything. You still have to give a separate 'xl vncviewer &lt;domanme&gt;'.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">4) The 'localtime=1' option in your config is ignored by xl. This works with </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xm. Xl will not honor the rtc_timeoffset option either.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">The answer given to the two above problems at the time was essentially that they had not been implemented. Have they been implemented in xen 4.2 yet? They are not mentioned in the xl.cfg documentation, which I assume is for 4.2:</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Now for what does work to get a stubdom up and running. I used the below config, with python commented out to keep xl happy. Note the spice options, and 'device_model_stubdomain_override = 1' don't actually do anything (the latter contrary to what someone else reported). I assume that they will become functional in xen 4.2. Also, while device_model_args does indeed add '-localtime' to the end of the qemu-dm args, it's still ineffective.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Two interesting observations: 1) 'xm create' is useless for creating stubdoms - I always get a page fault reported in qemu-dm-winxp.log (the log for the main domain, not the stubdom). In exploring this, I noticed that 'xm create' uses /usr/lib/xen/bin/stubdom.sh. You can add a 'set -x' to this file, and the trace will show up in qemu-dm-winxp.log. 'xl create' does not use this program. You can move it completely away from /usr/lib/xen/bin, and the stubdom will still be created. The device_model option is just telling xl not to use the normal qemu-dm method.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">And 2) If you have GPLPV installed in your domain, it completely takes over. Booting with GPLPV enabled is no faster with stubdoms as without. Booting with /nogplpv is just as slow as if you booted without stubdoms. I suspect xenpci.sys is overriding what stubdoms is doing. The only part of the boot process that is faster is the initial grub screen. (This is an iscsi export from a dual-boot server.) After Windows starts to boot, it reverts back to gplpv (or /nogplpv) speeds. The same holds true for a linux hvm: a normal hvm domu with PvHvm drivers is no faster than a linux stubdom (w/no PvHvm). (I didn't try both at the same time.)</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#import os, re</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#arch = os.uname()[4]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#if re.search('64', arch):</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#    arch_libdir = 'lib64'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#else:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#    arch_libdir = 'lib'</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">name = &quot;winxp&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">builder='hvm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">memory = &quot;768&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">uuid = &quot;6c7de04e-df10-caa8-bb2a-8368246225c1&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#ostype = &quot;hvm&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">on_reboot = &quot;restart&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">on_crash = &quot;restart&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">on_poweroff = &quot;destroy&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vcpus = &quot;2&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">viridian=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#kernel = &quot;/usr/lib/xen/boot/hvmloader&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">kernel = &quot;hvmloader&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">acpi=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">apic=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">boot= &quot;cda&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># New stuff</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#device_model = '/usr/lib/xen/bin/qemu-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#device_model = 'qemu-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># must comment out 'soundhw' below for stubdom</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">device_model = 'stubdom-dm'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">device_model_stubdomain_override = 1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">device_model_args=[ &quot;-localtime&quot; ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">keymap='en-us'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">localtime=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#rtc_timeoffset=' -14400'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">rtc_timeoffset=' -18000'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">pae=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">nx=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">serial='pty'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#serial = &quot;/dev/ttyS0&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#   enable sound card support, [sb16|es1370|all|..,..], default none</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#soundhw='es1370'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># enable stdvga, default = 0 (use cirrus logic device model)</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#stdvga=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">videoram=16</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">stdvga=0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#usbdevice=&quot;mouse&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">usbdevice=&quot;tablet&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">xen_extended_power_mgmt = 0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#disk=[ 'tap2:aio:/var/lib/xen/images/winxp,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#disk=[ 'file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#disk=[ 'file:/var/lib/xen/images/winxp,ioemu:hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">disk=[ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/sr0,hdc:cdrom,r' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vif = [ 'mac=00:16:3e:23:1d:36, script=/etc/xen/scripts/vif-bridge, bridge=xenbr0, model=rtl8139' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=/etc/xen/scripts/vif-bridge, bridge=xenbr0, model=e1000' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vif = [ 'mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge, bridge = xenbr0' ]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">sdl=0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3, vncpasswd= ']</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vnc=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vnclisten=&quot;0.0.0.0&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#vnclisten=&quot;192.168.1.0&quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># set VNC display number, default = domid</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncdisplay=3</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"># try to find an unused port for the VNC server, default = 1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncunused=0</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncviewer=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncconsole=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">monitor=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">vncpasswd=&quot;&quot;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">#spice</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spice=1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spiceport=6000 </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spicehost='192.168.1.100'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spicedisable_ticketing = 0 # default is 0 </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">spicepasswd = ''</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p></body></html>
--nextPart7831939.5g3HAvzpyp--



--===============1531123294308609982==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1531123294308609982==--



From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:12:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxyK6-0003K5-TX; Thu, 16 Feb 2012 10:12:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RxyK6-0003JP-6K
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:12:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329387134!8455424!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27091 invoked from network); 16 Feb 2012 10:12:15 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Feb 2012 10:12:15 -0000
Received: from mail116-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 10:12:14 +0000
Received: from mail116-tx2 (localhost [127.0.0.1])	by
	mail116-tx2-R.bigfish.com (Postfix) with ESMTP id 757581A035D;
	Thu, 16 Feb 2012 10:12:13 +0000 (UTC)
X-SpamScore: -20
X-BigFish: VPS-20(zzbb2dI9371I103dK148cM1447M1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dh5eeeKz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail116-tx2 (localhost.localdomain [127.0.0.1]) by mail116-tx2
	(MessageSwitch) id 1329387130737804_24610;
	Thu, 16 Feb 2012 10:12:10 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.237])	by
	mail116-tx2.bigfish.com (Postfix) with ESMTP id AD38D1C0045;
	Thu, 16 Feb 2012 10:12:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 10:12:06 +0000
X-WSS-ID: 0LZHDO4-01-1MJ-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 23D4C102819B;	Thu, 16 Feb 2012 04:12:04 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 16 Feb 2012 04:12:18 -0600
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.289.1;
	Thu, 16 Feb 2012 04:12:04 -0600
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, 16 Feb 2012
	05:12:02 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B1F0549C34C; Thu, 16 Feb 2012
	10:12:01 +0000 (GMT)
Message-ID: <4F3CD7C0.1010309@amd.com>
Date: Thu, 16 Feb 2012 11:17:36 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <andres@lagarcavilla.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/15/2012 05:06 PM, Andres Lagar-Cavilla wrote:
>> On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>>>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>>>> We started hashing out some AMD support for mem_paging and mem_access.
>>>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>>>> fault.
>>>>>
>>>>> Most importantly, I want to get somebody from AMD to comment/help out
>>>>> on
>>>>> this. It feels like we're inches away from enabling support for this
>>>>> very
>>>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>>>> these
>>>>> kinds of things. It'd be great to have you on board!
>>>>>
>>>>> For starters, the changes to the p2m code are relatively mild, but
>>>>> it'd
>>>>> be
>>>>> great if somebody spots a red flag.
>>>>>
>>>>> Another issue: comments indicate that bits 59-62 in NPT entries are
>>>>> used
>>>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>>>> (59)
>>>>> would give us enough space to support mem_access. Right now we only
>>>>> have
>>>>> 7
>>>>> bits available for Xen flags and that is not enough for paging and
>>>>> access.
>>>>> Is bit 59 effectively reserved?
>>>>
>>>> Hi
>>>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>>>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
>>>> are not potentially used by DMA, this bit could be non-zero. I could
>>>> tested it on my iommu machines if you had some patches that use U bits.
>>>
>>> Hi Wei, thanks for pitching in! I assume you're talking about table 14
>>> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf
>>
>> Yes, indeed.
>>
>>> I don't think this will work. The p2m access value is arbitrary, and
>>> independent of the p2m type. So bit 59 is out of reach and we're stuck
>>> with 7 bits for Xen use. Thanks for the clarification.
>>
>> Where will p2m access bit be stored? Please note that bit 52 - bit 58
>> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>> and bit 1 - bit 8 are free to use if PR bit = 1.
>
> Wei,
>
> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
> current convention?
>
> I propose limiting p2m type to bits 52-55, and storing p2m access on bits
> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
> be zero" requirement/convention.
>
> Right now, without any considerations for paging, we're storing the p2m
> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
> course. Given your statement above, and table 14 in the IOMMU manual, how
> is this even working? Or is it not working?

It works because only p2m_ram_rw (which is 0) pages suppose to be used 
by DMA. But, indeed, if iommu tries to access pages with non-zero types, 
like p2m_ram_ro,,it will have io page faults. It seems that we don't 
have use cases like this.

If mem access bits are independent to p2m types, I think we might have a 
few solutions here:
1) reverse iommu pt sharing for amd iommu totally.
2) disable iommu pt sharing when xen paging enabled.

I am open for both of them.

Thanks,

Wei


> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>
> Thanks a lot for the info!
> Andres
>>
>> Thanks,
>> Wei
>>
>>> An alternative to enabling mem_access on AMD processors will be to limit
>>> the access types to 3 bits. This would force disabling support for two
>>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>>> they
>>> make sense without R permissions.
>>> Thanks!
>>> Andres
>>>
>>>>
>>>> Thanks,
>>>> Wei
>>>>
>>>>>
>>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>>> Comments
>>>>> welcome.
>>>>>
>>>>> Patch inline below, thanks!
>>>>> Andres
>>>>>
>>>>> Enable AMD support for paging.
>>>>>
>>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>>
>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>>                 if ( !hap_enabled(d) )
>>>>>                     break;
>>>>>
>>>>> -            /* Currently only EPT is supported */
>>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>>> -                break;
>>>>> -
>>>>>                 rc = -EXDEV;
>>>>>                 /* Disallow paging in a PoD guest */
>>>>>                 if ( p2m->pod.entry_count )
>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>>> @@ -53,6 +53,20 @@
>>>>>     #define P2M_BASE_FLAGS \
>>>>>             (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>>
>>>>> +#ifdef __x86_64__
>>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>>> 0xff..ff
>>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>>> p2mt,
>>>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>>> +#define clipped_mfn(mfn)    ((mfn)&    ((1UL<<    EFF_MFN_WIDTH) - 1))
>>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>>>> +                                INVALID_MFN : (mfn))
>>>>> +#else
>>>>> +#define clipped_mfn(mfn)    (mfn)
>>>>> +#define unclip_mfn(mfn)     (mfn)
>>>>> +#endif /* __x86_64__ */
>>>>> +
>>>>>     static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>>     {
>>>>>         unsigned long flags;
>>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>>         case p2m_invalid:
>>>>>         case p2m_mmio_dm:
>>>>>         case p2m_populate_on_demand:
>>>>> +    case p2m_ram_paging_out:
>>>>> +    case p2m_ram_paged:
>>>>> +    case p2m_ram_paging_in:
>>>>>         default:
>>>>>             return flags;
>>>>>         case p2m_ram_ro:
>>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>>                                           shift, max)) )
>>>>>             return 0;
>>>>>
>>>>> -    /* PoD: Not present doesn't imply empty. */
>>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>>         if ( !l1e_get_flags(*p2m_entry) )
>>>>>         {
>>>>>             struct page_info *pg;
>>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>                                        0, L1_PAGETABLE_ENTRIES);
>>>>>             ASSERT(p2m_entry);
>>>>>
>>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>>                                              p2m_type_to_flags(p2mt,
>>>>> mfn));
>>>>>             else
>>>>>                 entry_content = l1e_empty();
>>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>             if ( entry_content.l1 != 0 )
>>>>>             {
>>>>>                 p2m_add_iommu_flags(&entry_content, 0,
>>>>> iommu_pte_flags);
>>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>>             }
>>>>>             /* level 1 entry */
>>>>>             p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>>> entry_content, 1);
>>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>>                                sizeof(l1e));
>>>>>
>>>>>         if ( ret == 0 ) {
>>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>>             p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>>> +                (l1e_mfn == INVALID_MFN&&    p2m_is_paging(p2mt)) );
>>>>>
>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>>> -             == p2m_populate_on_demand )
>>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>>             {
>>>>>                 /* The read has succeeded, so we know that the mapping
>>>>>                  * exits at this point.  */
>>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>>             }
>>>>>
>>>>>             if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>>> +            mfn = _mfn(l1e_mfn);
>>>>>             else
>>>>>                 /* XXX see above */
>>>>>                 p2mt = p2m_mmio_dm;
>>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>>     pod_retry_l1:
>>>>>         if ( (l1e_get_flags(*l1e)&    _PAGE_PRESENT) == 0 )
>>>>>         {
>>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>             /* PoD: Try to populate */
>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>>> p2m_populate_on_demand )
>>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>>             {
>>>>>                 if ( q != p2m_query ) {
>>>>>                     if ( !p2m_pod_demand_populate(p2m, gfn,
>>>>> PAGE_ORDER_4K,
>>>>> q) )
>>>>>                         goto pod_retry_l1;
>>>>>                 } else
>>>>>                     *t = p2m_populate_on_demand;
>>>>> +        } else {
>>>>> +            if ( p2m_is_paging(l1t) )
>>>>> +            {
>>>>> +                *t = l1t;
>>>>> +                /* No need to unclip due to check below */
>>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>>> +            }
>>>>>             }
>>>>>
>>>>>             unmap_domain_page(l1e);
>>>>> -        return _mfn(INVALID_MFN);
>>>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>>>         }
>>>>>         mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>         *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>>                         flags = l1e_get_flags(l1e[i1]);
>>>>>                         if ( p2m_flags_to_type(flags) != ot )
>>>>>                             continue;
>>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>                         gfn = i1 + (i2 + (i3
>>>>>     #if CONFIG_PAGING_LEVELS>= 4
>>>>>     					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>>                                * L2_PAGETABLE_ENTRIES) *
>>>>> L1_PAGETABLE_ENTRIES;
>>>>>                         /* create a new 1le entry with the new type */
>>>>>                         flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>>> flags);
>>>>>                         p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>>                                              l1mfn, l1e_content, 1);
>>>>>                     }
>>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>>                                     entry_count++;
>>>>>                                 continue;
>>>>>                             }
>>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>                             ASSERT(mfn_valid(_mfn(mfn)));
>>>>>                             m2pfn = get_gpfn_from_mfn(mfn);
>>>>>                             if ( m2pfn != gfn&&
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:12:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxyK6-0003K5-TX; Thu, 16 Feb 2012 10:12:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RxyK6-0003JP-6K
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:12:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329387134!8455424!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27091 invoked from network); 16 Feb 2012 10:12:15 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Feb 2012 10:12:15 -0000
Received: from mail116-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 10:12:14 +0000
Received: from mail116-tx2 (localhost [127.0.0.1])	by
	mail116-tx2-R.bigfish.com (Postfix) with ESMTP id 757581A035D;
	Thu, 16 Feb 2012 10:12:13 +0000 (UTC)
X-SpamScore: -20
X-BigFish: VPS-20(zzbb2dI9371I103dK148cM1447M1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dh5eeeKz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail116-tx2 (localhost.localdomain [127.0.0.1]) by mail116-tx2
	(MessageSwitch) id 1329387130737804_24610;
	Thu, 16 Feb 2012 10:12:10 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.237])	by
	mail116-tx2.bigfish.com (Postfix) with ESMTP id AD38D1C0045;
	Thu, 16 Feb 2012 10:12:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 10:12:06 +0000
X-WSS-ID: 0LZHDO4-01-1MJ-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 23D4C102819B;	Thu, 16 Feb 2012 04:12:04 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 16 Feb 2012 04:12:18 -0600
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.289.1;
	Thu, 16 Feb 2012 04:12:04 -0600
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, 16 Feb 2012
	05:12:02 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B1F0549C34C; Thu, 16 Feb 2012
	10:12:01 +0000 (GMT)
Message-ID: <4F3CD7C0.1010309@amd.com>
Date: Thu, 16 Feb 2012 11:17:36 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <andres@lagarcavilla.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/15/2012 05:06 PM, Andres Lagar-Cavilla wrote:
>> On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>>>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>>>> We started hashing out some AMD support for mem_paging and mem_access.
>>>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>>>> fault.
>>>>>
>>>>> Most importantly, I want to get somebody from AMD to comment/help out
>>>>> on
>>>>> this. It feels like we're inches away from enabling support for this
>>>>> very
>>>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>>>> these
>>>>> kinds of things. It'd be great to have you on board!
>>>>>
>>>>> For starters, the changes to the p2m code are relatively mild, but
>>>>> it'd
>>>>> be
>>>>> great if somebody spots a red flag.
>>>>>
>>>>> Another issue: comments indicate that bits 59-62 in NPT entries are
>>>>> used
>>>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>>>> (59)
>>>>> would give us enough space to support mem_access. Right now we only
>>>>> have
>>>>> 7
>>>>> bits available for Xen flags and that is not enough for paging and
>>>>> access.
>>>>> Is bit 59 effectively reserved?
>>>>
>>>> Hi
>>>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>>>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types that
>>>> are not potentially used by DMA, this bit could be non-zero. I could
>>>> tested it on my iommu machines if you had some patches that use U bits.
>>>
>>> Hi Wei, thanks for pitching in! I assume you're talking about table 14
>>> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf
>>
>> Yes, indeed.
>>
>>> I don't think this will work. The p2m access value is arbitrary, and
>>> independent of the p2m type. So bit 59 is out of reach and we're stuck
>>> with 7 bits for Xen use. Thanks for the clarification.
>>
>> Where will p2m access bit be stored? Please note that bit 52 - bit 58
>> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>> and bit 1 - bit 8 are free to use if PR bit = 1.
>
> Wei,
>
> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
> current convention?
>
> I propose limiting p2m type to bits 52-55, and storing p2m access on bits
> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
> be zero" requirement/convention.
>
> Right now, without any considerations for paging, we're storing the p2m
> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
> course. Given your statement above, and table 14 in the IOMMU manual, how
> is this even working? Or is it not working?

It works because only p2m_ram_rw (which is 0) pages suppose to be used 
by DMA. But, indeed, if iommu tries to access pages with non-zero types, 
like p2m_ram_ro,,it will have io page faults. It seems that we don't 
have use cases like this.

If mem access bits are independent to p2m types, I think we might have a 
few solutions here:
1) reverse iommu pt sharing for amd iommu totally.
2) disable iommu pt sharing when xen paging enabled.

I am open for both of them.

Thanks,

Wei


> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>
> Thanks a lot for the info!
> Andres
>>
>> Thanks,
>> Wei
>>
>>> An alternative to enabling mem_access on AMD processors will be to limit
>>> the access types to 3 bits. This would force disabling support for two
>>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>>> they
>>> make sense without R permissions.
>>> Thanks!
>>> Andres
>>>
>>>>
>>>> Thanks,
>>>> Wei
>>>>
>>>>>
>>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>>> Comments
>>>>> welcome.
>>>>>
>>>>> Patch inline below, thanks!
>>>>> Andres
>>>>>
>>>>> Enable AMD support for paging.
>>>>>
>>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>>
>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>>                 if ( !hap_enabled(d) )
>>>>>                     break;
>>>>>
>>>>> -            /* Currently only EPT is supported */
>>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>>> -                break;
>>>>> -
>>>>>                 rc = -EXDEV;
>>>>>                 /* Disallow paging in a PoD guest */
>>>>>                 if ( p2m->pod.entry_count )
>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>>> @@ -53,6 +53,20 @@
>>>>>     #define P2M_BASE_FLAGS \
>>>>>             (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>>
>>>>> +#ifdef __x86_64__
>>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>>> 0xff..ff
>>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>>> p2mt,
>>>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>>> +#define clipped_mfn(mfn)    ((mfn)&    ((1UL<<    EFF_MFN_WIDTH) - 1))
>>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>>>> +                                INVALID_MFN : (mfn))
>>>>> +#else
>>>>> +#define clipped_mfn(mfn)    (mfn)
>>>>> +#define unclip_mfn(mfn)     (mfn)
>>>>> +#endif /* __x86_64__ */
>>>>> +
>>>>>     static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>>     {
>>>>>         unsigned long flags;
>>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>>         case p2m_invalid:
>>>>>         case p2m_mmio_dm:
>>>>>         case p2m_populate_on_demand:
>>>>> +    case p2m_ram_paging_out:
>>>>> +    case p2m_ram_paged:
>>>>> +    case p2m_ram_paging_in:
>>>>>         default:
>>>>>             return flags;
>>>>>         case p2m_ram_ro:
>>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>>                                           shift, max)) )
>>>>>             return 0;
>>>>>
>>>>> -    /* PoD: Not present doesn't imply empty. */
>>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>>         if ( !l1e_get_flags(*p2m_entry) )
>>>>>         {
>>>>>             struct page_info *pg;
>>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>                                        0, L1_PAGETABLE_ENTRIES);
>>>>>             ASSERT(p2m_entry);
>>>>>
>>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>>                                              p2m_type_to_flags(p2mt,
>>>>> mfn));
>>>>>             else
>>>>>                 entry_content = l1e_empty();
>>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>             if ( entry_content.l1 != 0 )
>>>>>             {
>>>>>                 p2m_add_iommu_flags(&entry_content, 0,
>>>>> iommu_pte_flags);
>>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>>             }
>>>>>             /* level 1 entry */
>>>>>             p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>>> entry_content, 1);
>>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>>                                sizeof(l1e));
>>>>>
>>>>>         if ( ret == 0 ) {
>>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>>             p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>>> +                (l1e_mfn == INVALID_MFN&&    p2m_is_paging(p2mt)) );
>>>>>
>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>>> -             == p2m_populate_on_demand )
>>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>>             {
>>>>>                 /* The read has succeeded, so we know that the mapping
>>>>>                  * exits at this point.  */
>>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>>             }
>>>>>
>>>>>             if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>>> +            mfn = _mfn(l1e_mfn);
>>>>>             else
>>>>>                 /* XXX see above */
>>>>>                 p2mt = p2m_mmio_dm;
>>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>>     pod_retry_l1:
>>>>>         if ( (l1e_get_flags(*l1e)&    _PAGE_PRESENT) == 0 )
>>>>>         {
>>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>             /* PoD: Try to populate */
>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>>> p2m_populate_on_demand )
>>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>>             {
>>>>>                 if ( q != p2m_query ) {
>>>>>                     if ( !p2m_pod_demand_populate(p2m, gfn,
>>>>> PAGE_ORDER_4K,
>>>>> q) )
>>>>>                         goto pod_retry_l1;
>>>>>                 } else
>>>>>                     *t = p2m_populate_on_demand;
>>>>> +        } else {
>>>>> +            if ( p2m_is_paging(l1t) )
>>>>> +            {
>>>>> +                *t = l1t;
>>>>> +                /* No need to unclip due to check below */
>>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>>> +            }
>>>>>             }
>>>>>
>>>>>             unmap_domain_page(l1e);
>>>>> -        return _mfn(INVALID_MFN);
>>>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>>>         }
>>>>>         mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>         *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>>                         flags = l1e_get_flags(l1e[i1]);
>>>>>                         if ( p2m_flags_to_type(flags) != ot )
>>>>>                             continue;
>>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>                         gfn = i1 + (i2 + (i3
>>>>>     #if CONFIG_PAGING_LEVELS>= 4
>>>>>     					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>>                                * L2_PAGETABLE_ENTRIES) *
>>>>> L1_PAGETABLE_ENTRIES;
>>>>>                         /* create a new 1le entry with the new type */
>>>>>                         flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>>> flags);
>>>>>                         p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>>                                              l1mfn, l1e_content, 1);
>>>>>                     }
>>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>>                                     entry_count++;
>>>>>                                 continue;
>>>>>                             }
>>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>                             ASSERT(mfn_valid(_mfn(mfn)));
>>>>>                             m2pfn = get_gpfn_from_mfn(mfn);
>>>>>                             if ( m2pfn != gfn&&
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:17:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxyOc-0003oY-Kp; Thu, 16 Feb 2012 10:17:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RxyOb-0003ni-7A
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:17:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329387375!52671939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31194 invoked from network); 16 Feb 2012 10:16:15 -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;
	16 Feb 2012 10:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="10738319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 10:16:54 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 10:16:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1329386571.4520.44.camel@leeds.uk.xensource.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<1329386571.4520.44.camel@leeds.uk.xensource.com>
Date: Thu, 16 Feb 2012 10:16:19 +0000
Message-ID: <1329387379.4520.54.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 10:02 +0000, Wei Liu (Intern) wrote:
> On Wed, 2012-02-15 at 22:42 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > It also needs this:
> > 
> > From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 15 Feb 2012 17:39:46 -0500
> > Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
> >  built for it.
> > 
> > Otherwise we end up:
> > 
> > BUG: unable to handle kernel paging request at ffff88004000c0c8
> > IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > PGD 1806063 PUD 0
> > 22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
> > 00 [#1] SMP
> > CPU 0
> > Modules linked in:
> > 
> > Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
> > RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
> > .. snip.
> > Call Trace:
> >  [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
> >  [<ffffffff810f4eab>] __free_pages+0x1b/0x40
> >  [<ffffffff810f4f1a>] free_pages+0x4a/0x60
> >  [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
> >  [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
> >  [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
> >  [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
> >  [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/net/xen-netfront.c |   14 +++++++++++++-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 0223552..1eadd90 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -29,6 +29,8 @@
> >   * IN THE SOFTWARE.
> >   */
> >  
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/kernel.h>
> >  #include <linux/netdevice.h>
> > @@ -66,7 +68,7 @@ struct netfront_cb {
> >  
> >  #define GRANT_INVALID_REF	0
> >  
> > -#define XENNET_MAX_RING_PAGE_ORDER 2
> > +#define XENNET_MAX_RING_PAGE_ORDER 4
> 
> I guess this is you tuning with page order? And here is not the only one
> place you changed?
> 
> As a matter of fact, in the previous patch 8 I encode hard limit 2 on
> the ring page order, your change here will stop FE / BE from connecting.
> 
> I think I will also need to change this to something like
> 
>   #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> 
> to remind people to modify that value. 
> 

To be more precise on this, tangling with RING_PAGE_ORDER will not
affect FE, because the mapping is done in BE. However if you make
RING_PAGE_ORDER larger than BE limit, it will fail.

So the above #define is actually asking people playing with FE to check
BE limit. :-(


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:17:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxyOc-0003oY-Kp; Thu, 16 Feb 2012 10:17:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RxyOb-0003ni-7A
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:17:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329387375!52671939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31194 invoked from network); 16 Feb 2012 10:16:15 -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;
	16 Feb 2012 10:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="10738319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 10:16:54 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 10:16:54 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1329386571.4520.44.camel@leeds.uk.xensource.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<1329386571.4520.44.camel@leeds.uk.xensource.com>
Date: Thu, 16 Feb 2012 10:16:19 +0000
Message-ID: <1329387379.4520.54.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 10:02 +0000, Wei Liu (Intern) wrote:
> On Wed, 2012-02-15 at 22:42 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > It also needs this:
> > 
> > From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 15 Feb 2012 17:39:46 -0500
> > Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
> >  built for it.
> > 
> > Otherwise we end up:
> > 
> > BUG: unable to handle kernel paging request at ffff88004000c0c8
> > IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > PGD 1806063 PUD 0
> > 22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
> > 00 [#1] SMP
> > CPU 0
> > Modules linked in:
> > 
> > Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
> > RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
> > .. snip.
> > Call Trace:
> >  [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
> >  [<ffffffff810f4eab>] __free_pages+0x1b/0x40
> >  [<ffffffff810f4f1a>] free_pages+0x4a/0x60
> >  [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
> >  [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
> >  [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
> >  [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
> >  [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/net/xen-netfront.c |   14 +++++++++++++-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 0223552..1eadd90 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -29,6 +29,8 @@
> >   * IN THE SOFTWARE.
> >   */
> >  
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/kernel.h>
> >  #include <linux/netdevice.h>
> > @@ -66,7 +68,7 @@ struct netfront_cb {
> >  
> >  #define GRANT_INVALID_REF	0
> >  
> > -#define XENNET_MAX_RING_PAGE_ORDER 2
> > +#define XENNET_MAX_RING_PAGE_ORDER 4
> 
> I guess this is you tuning with page order? And here is not the only one
> place you changed?
> 
> As a matter of fact, in the previous patch 8 I encode hard limit 2 on
> the ring page order, your change here will stop FE / BE from connecting.
> 
> I think I will also need to change this to something like
> 
>   #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> 
> to remind people to modify that value. 
> 

To be more precise on this, tangling with RING_PAGE_ORDER will not
affect FE, because the mapping is done in BE. However if you make
RING_PAGE_ORDER larger than BE limit, it will fail.

So the above #define is actually asking people playing with FE to check
BE limit. :-(


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:20:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxyRu-00042p-9K; Thu, 16 Feb 2012 10:20:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxyRs-00042Y-9V
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:20:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329387617!11756103!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11161 invoked from network); 16 Feb 2012 10:20:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 10:20:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxyRi-000ATR-K2; Thu, 16 Feb 2012 10:20:14 +0000
Date: Thu, 16 Feb 2012 10:20:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216102014.GA40020@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
	domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:57 -0500 on 15 Feb (1329346624), Andres Lagar-Cavilla wrote:
>  xen/common/domctl.c |  8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> 
> Apparently, setting d->max_pages to something lower than d->tot_pages is
> used as a mechanism for controling a domain's footprint. It will result
> in all new page allocations failing.

Yep.  

> This is a really bad idea with paging or sharing, as regular guest memory
> accesses may need to be satisfied by allocating new memory (either to
> page in or to unshare).

Nack.  If a domain ends up with a max_pages so low that it can't page
in, that's a tools bug.  This patch doesn't fix it, because the
toolstack could set new max == current tot (er, +1) and then you have
the same problem if you page in twice.   (And also it silently ignores
the update rather than reporting an error.)

Tim.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>           * NB. We removed a check that new_max >= current tot_pages; this means
>           * that the domain will now be allowed to "ratchet" down to new_max. In
>           * the meantime, while tot > max, all new allocations are disallowed.
> +         *
> +         * Except that this is not a great idea for domains doing sharing or 
> +         * paging, as they need to perform new allocations on the fly.
>           */
> -        d->max_pages = new_max;
> +        if ( (new_max > d->max_pages) ||
> +             !((d->mem_event->paging.ring_page != NULL) ||
> +                d->arch.hvm_domain.mem_sharing_enabled) )
> +            d->max_pages = new_max;
>          ret = 0;
>          spin_unlock(&d->page_alloc_lock);
>  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:20:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxyRu-00042p-9K; Thu, 16 Feb 2012 10:20:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RxyRs-00042Y-9V
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:20:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329387617!11756103!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11161 invoked from network); 16 Feb 2012 10:20:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 10:20:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RxyRi-000ATR-K2; Thu, 16 Feb 2012 10:20:14 +0000
Date: Thu, 16 Feb 2012 10:20:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216102014.GA40020@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
	domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:57 -0500 on 15 Feb (1329346624), Andres Lagar-Cavilla wrote:
>  xen/common/domctl.c |  8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> 
> Apparently, setting d->max_pages to something lower than d->tot_pages is
> used as a mechanism for controling a domain's footprint. It will result
> in all new page allocations failing.

Yep.  

> This is a really bad idea with paging or sharing, as regular guest memory
> accesses may need to be satisfied by allocating new memory (either to
> page in or to unshare).

Nack.  If a domain ends up with a max_pages so low that it can't page
in, that's a tools bug.  This patch doesn't fix it, because the
toolstack could set new max == current tot (er, +1) and then you have
the same problem if you page in twice.   (And also it silently ignores
the update rather than reporting an error.)

Tim.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>           * NB. We removed a check that new_max >= current tot_pages; this means
>           * that the domain will now be allowed to "ratchet" down to new_max. In
>           * the meantime, while tot > max, all new allocations are disallowed.
> +         *
> +         * Except that this is not a great idea for domains doing sharing or 
> +         * paging, as they need to perform new allocations on the fly.
>           */
> -        d->max_pages = new_max;
> +        if ( (new_max > d->max_pages) ||
> +             !((d->mem_event->paging.ring_page != NULL) ||
> +                d->arch.hvm_domain.mem_sharing_enabled) )
> +            d->max_pages = new_max;
>          ret = 0;
>          spin_unlock(&d->page_alloc_lock);
>  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:20:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxySA-00044J-NB; Thu, 16 Feb 2012 10:20:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qrux.qed@gmail.com>) id 1RxyS5-00043i-OC
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:20:41 +0000
Received: from [85.158.139.83:6472] by server-6.bemta-5.messagelabs.com id
	9B/69-27305-478DC3F4; Thu, 16 Feb 2012 10:20:36 +0000
X-Env-Sender: qrux.qed@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329387632!15316082!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3833 invoked from network); 16 Feb 2012 10:20:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 10:20:34 -0000
Received: by damc16 with SMTP id c16so11200843dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 02:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:mime-version:content-type:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=/+7E/43ZwYP0W2JJHh1V9V6nDqHtOGpaR0RLjVjx6uY=;
	b=kRCFjQDoVmj3FfnjJFOHzIjtvq3ZGFvd90k592AP6P61Godo79yo1nWGBcOo3g7khG
	xjYbwPqrGjvRoPHoFgA+tFOoT/iJnksb32Ro34OpuTxiD6c+rwbD8mBdEvW2hBeochRg
	62MKlNoQ8ZsOn/KY4KTHGJIQlLjhpH0IMjWas=
Received: by 10.68.239.229 with SMTP id vv5mr11944148pbc.88.1329387631994;
	Thu, 16 Feb 2012 02:20:31 -0800 (PST)
Received: from [192.168.0.4] (c-71-198-0-100.hsd1.ca.comcast.net.
	[71.198.0.100])
	by mx.google.com with ESMTPS id a6sm1987152pbs.68.2012.02.16.02.20.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 16 Feb 2012 02:20:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Qrux <qrux.qed@gmail.com>
In-Reply-To: <1329236393.31256.267.camel@zakaz.uk.xensource.com>
Date: Thu, 16 Feb 2012 02:20:28 -0800
Message-Id: <A4D2CFC5-7B9D-4EBD-BDBC-58D6B35FCF6C@gmail.com>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
	<20120214155738.GC21610@andromeda.dapyr.net>
	<1329236393.31256.267.camel@zakaz.uk.xensource.com>
To: xen-devel@lists.xensource.com
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dear Abby,

I've been having intermittent problems booting an ext4 domU--LFS, Linux-3.1 pvops, Xen-4.1.2, xl (not xm).  This thread was started under a different guise, which Ian and Konrad were helpful; I thought the issue was related to NTP.  After more research, with their input, I was able to answer many of my own questions.  Then, after even more research, it seems clear the issue may be far deeper down the abyss...

To start, here's the domU config:

	kernel = "/boot/vmlinuz-3.1-lfs-7.0-DomU"
	memory = 1024
	name = "e4no23-ntp"
	vif = [ 'mac=00:16:3e:00:00:01, bridge=br0' ]
	disk = [ 'phy:/dev/vg-xen/e4no23-ntp,xvda1,w' ]
	root = "/dev/xvda1"
	on_crash = "preserve"

/dev/vg-xen/e4no23-ntp, as the name suggests, is an LVM volume.  When an otherwise identical volume is formatted as ext3, this problem cannot be reproduced.  When this volume is formatted at ext4, the problem below is intermittent, though once it appears, it seems to happen quite often.

In this domU, I boot it and watch the console.  It works, and I copied the output.  Then, I SSH-in and reboot it, again watching the console.  It fails, and I copy the output.  I've included a diff of the good boot vs the bad one, which has 3 chunks.  I'm happy to throw more info into a pastebin if it will help someone trying to eyeball this, but the summary is that in both boots, we see these 5 lines:

  bio: create slab <bio-0> at 0
  xen/balloon: Initialising balloon driver.
  last_pfn = 0x40100 max_arch_pfn = 0x400000000
  Switching to clocksource xen
  Switched to NOHz mode on CPU #0

as the last 5 lines of common output before things get weird in the bad boot:

+ CE: xen increased min_delta_ns to 150000 nsec
+ CE: xen increased min_delta_ns to 225000 nsec
+ CE: xen increased min_delta_ns to 337500 nsec
+ CE: xen increased min_delta_ns to 506250 nsec
+ CE: xen increased min_delta_ns to 759375 nsec
+ CE: xen increased min_delta_ns to 1139062 nsec
+ CE: xen increased min_delta_ns to 1708593 nsec
+ CE: xen increased min_delta_ns to 2562889 nsec
+ CE: xen increased min_delta_ns to 3844333 nsec
+ CE: xen increased min_delta_ns to 4000000 nsec
+ CE: Reprogramming failure. Giving up
+ CE: Reprogramming failure. Giving up
+ hrtimer: interrupt took 9750 ns
+ CE: Reprogramming failure. Giving up
  FS-Cache: Loaded
  CacheFiles: Loaded
  NET: Registered protocol family 2
  IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
  TCP established hash table entries: 131072 (order: 9, 2097152 bytes)

>From my research, it seems as if this issue has come up before, in perhaps 3 manifestations:

	* Jul 2010
	* [Xen-devel] xen tsc problems?
	* http://tinyurl.com/7dqf5qx

	* Jan 2011
	* [Xen-users] CentOS 5.5 x86_64 - XEN DomU LVM ext4 partition support
	* http://tinyurl.com/842rx8b

	* Aug 2011
	* [Xen-devel] xen-4.1: PV domain hanging at startup, jiffies stopped
	* http://tinyurl.com/7f9osav

Of course, I'm not absolutely certain that they are related, but the symptoms that all 3 people described fit my current observations.  In the first one, it seemed like the resolution was about timer_mode being changed from its default of 0 (zero) to 1 (one) in xl.  The post suggests that the TSC can operate in multiple "modes", though I have no idea what those are, and what they do.  That seemed to conclude the issue in mid 2010...

In Jan 2011, it manifests (in my interpretation) as an EXT4 failure.  And, in my particular case, I believe these issues are related, because I cannot repro this problem using ext3.

Then, in Aug 2011, it comes back.  (Interestingly, this issue appears alongside a nearly identical issue captured in a thread in Feb 2011...more on this later.)  The OP does an epic amount of debugging, during which, someone suggest using xenctx to look at the crashed VM.  Here's what I get:

====
xlapp [~] # /usr/lib/xen/bin/xenctx -s /boot/System.map-3.1-DomU 3 0
rip: ffffffff810013aa hypercall_page+0x3aa 
flags: 00001246 i z p
rsp: ffffffff81709ee0
rax: 0000000000000000	rcx: ffffffff810013aa	rdx: 0000000000000000
rbx: ffffffff81709fd8	rsi: 0000000000000000	rdi: 0000000000000001
rbp: ffffffff81709ef8	 r8: 0000000000000000	 r9: 0000000000000000
r10: 0000000000000400	r11: 0000000000000246	r12: 0000000000000000
r13: ffff88003fff3b80	r14: ffffffffffffffff	r15: 0000000000000000
 cs: e033	 ss: e02b	 ds: 0000	 es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ ffff88003ffd3000/0000000000000000
Code (instr addr ffffffff810013aa)
cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc 


Stack:
 0000000000000000 00000000ffffffff ffffffff81009f60 ffffffff81709f28
 ffffffff8101a2c0 ffffffff81709fd8 ffffffff817784c0 ffff88003fff3b80
 ffffffffffffffff ffffffff81709f48 ffffffff810121b6 ffffffff817c6e40
 ffffffff817ca5e0 ffffffff81709f58 ffffffff81526549 ffffffff81709f98

Call Trace:
  [<ffffffff810013aa>] hypercall_page+0x3aa  <--
  [<ffffffff81009f60>] xen_safe_halt+0x10 
  [<ffffffff8101a2c0>] default_idle+0x60 
  [<ffffffff810121b6>] cpu_idle+0x66 
  [<ffffffff81526549>] rest_init+0x6d 
  [<ffffffff81796b87>] start_kernel+0x332 
  [<ffffffff81796347>] x86_64_start_reservations+0x132 
  [<ffffffff817994a9>] xen_start_kernel+0x50c 
====

This is the same "useless" output that the OP of thread 3 saw: a trace ending in the same "hypercall_page+0x3aa" line.  Later on in the thread, having received very little feedback, OP makes this claim (responding to his own email):

====
> I've collected few more messages from successful and failed domU starts.
> The only difference is the place where "Switched to NOHz mode on CPU #0"
> appears and existence of "CE: xen increased min_delta_ns to ..." and
> "CE: Reprogramming failure. Giving up" messages.
> 
> I think it can be related to:
> http://lists.xensource.com/archives/html/xen-devel/2010-07/msg00649.html
> (this was on HVM not PV, but looks similar)
> 
> I've tried also xenpm set-max-cstate 0 and tsc_mode=1 in domU config,
> but it doesn't help. Also pinning vcpu doesn't help (this domUs have
> only 1 vcpu). Is 'xenpm set-max-cstate 0' the same as booting xen with
> max_cstate=0?

Looks like tsc_mode=2 solves the problem.
====

Other people go on to say that setting tsc_mode=2 is a work-around, and only indicative of a deeper problem, though no one seems to know what it is.  Someone else suggests that tsc_mode=0 is (was?) the default and should be equivalent to tsc_mode=2, making the OP's change an effective no-op.  Later, the OP references a document:

	http://lxr.xensource.com/lxr/source/docs/misc/tscmode.txt

which doesn't exist, but I assume is this:

	xen-4.1.2/docs/misc/tscmode.txt

I've run:

	xl debug-key s; xl dmesg | tail

per its suggestion:

====
xlapp [~] # xl dmesg | tail
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.3
(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.1
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 01:00.0
(XEN) TSC has constant rate, no deep Cstates, passed warp test, deemed reliable, warp=0 (count=1)
(XEN) dom3: mode=0,ofs=0xf193f5ae955,khz=2628837,inc=1,vtsc count: 516338 kernel, 0 user
====

It appears as if the system is TSC-safe (in the lexicon of docs/misc/tscmode.txt).  So, it looks like it's going to use mode=0, and essentially use the native rdtsc family of instructions.

But, this doesn't appear to be the case.  Like the OP from Aug 11, explicitly setting tsc_mode=1 breaks domU (repro's the hang), whereas setting tsc_mode=2 unbreaks it (I have not, over several restarts, seen the problem reappear.

* * *

After doing more research, it turns out there was a parallel discussion to the one in Aug 2011 which started 6 months earlier, but continued through Sept 2011:

	* Feb 2011 - Sept 2011
	* [Xen-devel] Xen 4 TSC problems
	* http://xen.1045712.n5.nabble.com/Xen-4-TSC-problems-td3396848.html

Lots of issues were discussed, including changing the Xen platform timer to PIT instead of TSC/HPET, setting cpuidle=0, disabling HPET from the BIOS, turning deep C states off, and so on.  I hate to complain about a product I've so enjoyed using, now in version 4.x.y, but that's--

	A LOT of trial-and-error...

...with A LOT of wait-and-see if it solves the issue.  The main question, IMO, is:

	Is there a definitive configuration which is safe?

The academic-leaning "correctness" issue seems to be:

	Why isn't tsc_mode=1 working, when it's claimed to be "slow-but-correct"?

But, practically, is there a safe CPU configuration?  Putting aside everyone's concerns about saving the planet, (or budgetary concerns, if your colo bills by the Watt or if you run your own data center and pay for the electricity), is there a "safe" server config in terms of C-states, ACPI, etc?  And, by "safe", I mean, a statement like this:

====
"We know this BIOS config will very likely work if the CPU doesn't try to do a bunch of fancy speed-stepping or turbo-boosting (who are we, Knight Rider?) or deep-sleeping or blah-blah-blah.  Turn X on, and Y off, and set Z to this in your BIOS, start the hypervisor (kernel=xen line) with options A=a, B=b, C=c, run dom0 (module=vmlinuz-dom0 line) with options L=l, M=m, and N=n, and try to get your machine to state EFGHIJK so we know the machine will roughly have behaviors P, Q, R, and S, which should work with tsc_mode=N."
====

Since September, I can't find any further information about this issue. What is the state of this issue?  The inconsistency I see right now is this: in the July 2010 TSC discussion, a "Stefano Stabellini" posted this:

====
> /me wonders if timer_mode=1 is the default for xl?
> Or only for xm?

no, it is not.
Xl defaults to 0 [zero], I am going to change it right now.
====

So, it seems like (at least as of July 2010), xl is defaulting to "timer_mode=1".  That is, assuming that the then-current timer_mode is the same as present-day tsc_mode.  In addition, I'm assuming he was changing it from 0 (zero) to 1 (one)--and not some other mode.  But,

	xen-4.1.2/docs/misc/tscmode.txt

says:

	"The default mode (tsc_mode==0) checks TSC-safeness of the underlying
	hardware on which the virtual machine is launched.  If it is
	TSC-safe, rdtsc will execute at hardware speed; if it is not, rdtsc
	will be emulated."

Which implies the default is always 0 (zero).  Which is it?  More importantly, is the solution to force tsc_mode=2?  If so, under what BIOS/xen-boot-params/dom0-boot-params conditions?  And--please excuse my exasperation--but WTH does this have to do with ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET "jumpiness" (if that's even what's happening)?

Sincerely,
  Deeply Concerned & Slightly Frustrated




p.s. I've attached my dom0 'xl dmesg' output, in case that helps:

======== START xl dmesg ========
 __  __            _  _    _   ____  
 \ \/ /___ _ __   | || |  / | |___ \ 
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/ 
 /_/\_\___|_| |_|    |_|(_)_(_)_____|
                                     
(XEN) Xen version 4.1.2 (blfs@site) (gcc version 4.6.1 (GCC) ) Tue Feb 14 21:47:22 PST 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=1024M loglvl=all guest_loglvl=all console_to_ring sync_console
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e4000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000ddd80000 (usable)
(XEN)  00000000ddd80000 - 00000000ddd8e000 (ACPI data)
(XEN)  00000000ddd8e000 - 00000000dddd0000 (ACPI NVS)
(XEN)  00000000dddd0000 - 00000000e0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000220000000 (usable)
(XEN) ACPI: RSDP 000FB760, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT DDD80100, 0054 (r1 A_M_I_ OEMXSDT  10001121 MSFT       97)
(XEN) ACPI: FACP DDD80290, 00F4 (r3 A_M_I_ OEMFACP  10001121 MSFT       97)
(XEN) ACPI: DSDT DDD80440, 8794 (r1  A1745 A1745000        0 INTL 20060113)
(XEN) ACPI: FACS DDD8E000, 0040
(XEN) ACPI: APIC DDD80390, 006C (r1 A_M_I_ OEMAPIC  10001121 MSFT       97)
(XEN) ACPI: MCFG DDD80400, 003C (r1 A_M_I_ OEMMCFG  10001121 MSFT       97)
(XEN) ACPI: OEMB DDD8E040, 0089 (r1 A_M_I_ AMI_OEM  10001121 MSFT       97)
(XEN) ACPI: HPET DDD88BE0, 0038 (r1 A_M_I_ OEMHPET  10001121 MSFT       97)
(XEN) ACPI: GSCI DDD8E0D0, 2024 (r1 A_M_I_ GMCHSCI  10001121 MSFT       97)
(XEN) System RAM: 8157MB (8352892kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000220000000
(XEN) Domain heap initialised
(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[ddd8e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
(XEN) Processor #2 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
(XEN) Processor #3 6:15 APIC version 20
(XEN) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2628.837 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC TPR shadow
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Brought up 4 CPUs
(XEN) HPET: 3 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x23cf000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000214000000->0000000218000000 (245760 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff823cf000
(XEN)  Init. ramdisk: ffffffff823cf000->ffffffff823cf000
(XEN)  Phys-Mach map: ffffffff823cf000->ffffffff825cf000
(XEN)  Start info:    ffffffff825cf000->ffffffff825cf4b4
(XEN)  Page tables:   ffffffff825d0000->ffffffff825e7000
(XEN)  Boot stack:    ffffffff825e7000->ffffffff825e8000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82800000
(XEN)  ENTRY ADDRESS: ffffffff820e3200
(XEN) Dom0 has maximum 4 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) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 216kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.0-xlapp-dom0-debug (root@xlapp) (gcc version 4.6.1 (GCC) ) #1 SMP Wed Feb 15 19:22:24 PST 2012
[    0.000000] Command line: root=/dev/sda5 raid=noautodetect console=tty0 earlyprintk=xen nomodeset initcall_debug debug loglevel=10
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 140000 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009f000 (usable)
[    0.000000]  Xen: 000000000009fc00 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 00000000ddd80000 (unusable)
[    0.000000]  Xen: 00000000ddd80000 - 00000000ddd8e000 (ACPI data)
[    0.000000]  Xen: 00000000ddd8e000 - 00000000dddd0000 (ACPI NVS)
[    0.000000]  Xen: 00000000dddd0000 - 00000000e0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000002bdd80000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] DMI: System manufacturer System Product Name/P5G41T-M LX PLUS, BIOS 0502    10/21/2011
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x2bdd80 max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[    0.000000] initial memory mapped : 0 - 023cf000
[    0.000000] Base memory trampoline at [ffff88000009d000] 9d000 size 8192
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000]  0000000000 - 0040000000 page 4k
[    0.000000] kernel direct mapping tables up to 40000000 @ dfe000-1000000
[    0.000000] xen: setting RW the range fe6000 - 1000000
[    0.000000] init_memory_mapping: 0000000100000000-00000002bdd80000
[    0.000000]  0100000000 - 02bdd80000 page 4k
[    0.000000] kernel direct mapping tables up to 2bdd80000 @ 3ea05000-40000000
[    0.000000] xen: setting RW the range 3f7fb000 - 40000000
[    0.000000] ACPI: RSDP 00000000000fb760 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 00000000ddd80100 00054 (v01 A_M_I_ OEMXSDT  10001121 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000ddd80290 000F4 (v03 A_M_I_ OEMFACP  10001121 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000ddd80440 08794 (v01  A1745 A1745000 00000000 INTL 20060113)
[    0.000000] ACPI: FACS 00000000ddd8e000 00040
[    0.000000] ACPI: APIC 00000000ddd80390 0006C (v01 A_M_I_ OEMAPIC  10001121 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000ddd80400 0003C (v01 A_M_I_ OEMMCFG  10001121 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000ddd8e040 00089 (v01 A_M_I_ AMI_OEM  10001121 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000ddd88be0 00038 (v01 A_M_I_ OEMHPET  10001121 MSFT 00000097)
[    0.000000] ACPI: GSCI 00000000ddd8e0d0 02024 (v01 A_M_I_ GMCHSCI  10001121 MSFT 00000097)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000002bdd80000
[    0.000000] Initmem setup node 0 0000000000000000-00000002bdd80000
[    0.000000]   NODE_DATA [000000003fffb000 - 000000003fffffff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x002bdd80
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00100000 -> 0x002bdd80
[    0.000000] On node 0 totalpages: 2088207
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 490 pages reserved
[    0.000000]   DMA zone: 3429 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 16320 pages used for memmap
[    0.000000]   DMA32 zone: 241728 pages, LIFO batch:31
[    0.000000]   Normal zone: 28534 pages used for memmap
[    0.000000]   Normal zone: 1797642 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 4, version 255, address 0xfec00000, GSI 0-255
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 272
[    0.000000] Allocating PCI resources starting at e0000000 (gap: e0000000:1ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.2 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88003ff57000 s78912 r8192 d23488 u110592
[    0.000000] pcpu-alloc: s78912 r8192 d23488 u110592 alloc=27*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2042799
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=/dev/sda5 raid=noautodetect console=tty0 earlyprintk=xen nomodeset initcall_debug debug loglevel=10
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Placing 64MB software IO TLB between ffff880032600000 - ffff880036600000
[    0.000000] software IO TLB at phys 0x32600000 - 0x36600000
[    0.000000] Memory: 812604k/11499008k available (11712k kernel code, 3146180k absent, 7540224k reserved, 5491k data, 828k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:4352 nr_irqs:1024 16
[    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0
[    0.000000] xen: registering gsi 9 triggering 0 polarity 0
[    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
[    0.000000] xen: acpi sci 9
[    0.000000] xen: --> pirq=1 -> irq=1 (gsi=1)
[    0.000000] xen: --> pirq=2 -> irq=2 (gsi=2)
[    0.000000] xen: --> pirq=3 -> irq=3 (gsi=3)
[    0.000000] xen: --> pirq=4 -> irq=4 (gsi=4)
[    0.000000] xen: --> pirq=5 -> irq=5 (gsi=5)
[    0.000000] xen: --> pirq=6 -> irq=6 (gsi=6)
[    0.000000] xen: --> pirq=7 -> irq=7 (gsi=7)
[    0.000000] xen: --> pirq=8 -> irq=8 (gsi=8)
[    0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9
[    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
[    0.000000] xen: --> pirq=10 -> irq=10 (gsi=10)
[    0.000000] xen: --> pirq=11 -> irq=11 (gsi=11)
[    0.000000] xen: --> pirq=12 -> irq=12 (gsi=12)
[    0.000000] xen: --> pirq=13 -> irq=13 (gsi=13)
[    0.000000] xen: --> pirq=14 -> irq=14 (gsi=14)
[    0.000000] xen: --> pirq=15 -> irq=15 (gsi=15)
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled, bootconsole disabled
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:02.0
(XEN) PCI add device 00:1b.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.1
(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.3
(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.1
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 01:00.0
(XEN) TSC has constant rate, no deep Cstates, passed warp test, deemed reliable, warp=0 (count=1)
(XEN) dom3: mode=0,ofs=0xf193f5ae955,khz=2628837,inc=1,vtsc count: 516338 kernel, 0 user
========  END  xl dmesg ========
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:20:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1RxySA-00044J-NB; Thu, 16 Feb 2012 10:20:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qrux.qed@gmail.com>) id 1RxyS5-00043i-OC
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:20:41 +0000
Received: from [85.158.139.83:6472] by server-6.bemta-5.messagelabs.com id
	9B/69-27305-478DC3F4; Thu, 16 Feb 2012 10:20:36 +0000
X-Env-Sender: qrux.qed@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329387632!15316082!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3833 invoked from network); 16 Feb 2012 10:20:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 10:20:34 -0000
Received: by damc16 with SMTP id c16so11200843dam.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 02:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:mime-version:content-type:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=/+7E/43ZwYP0W2JJHh1V9V6nDqHtOGpaR0RLjVjx6uY=;
	b=kRCFjQDoVmj3FfnjJFOHzIjtvq3ZGFvd90k592AP6P61Godo79yo1nWGBcOo3g7khG
	xjYbwPqrGjvRoPHoFgA+tFOoT/iJnksb32Ro34OpuTxiD6c+rwbD8mBdEvW2hBeochRg
	62MKlNoQ8ZsOn/KY4KTHGJIQlLjhpH0IMjWas=
Received: by 10.68.239.229 with SMTP id vv5mr11944148pbc.88.1329387631994;
	Thu, 16 Feb 2012 02:20:31 -0800 (PST)
Received: from [192.168.0.4] (c-71-198-0-100.hsd1.ca.comcast.net.
	[71.198.0.100])
	by mx.google.com with ESMTPS id a6sm1987152pbs.68.2012.02.16.02.20.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 16 Feb 2012 02:20:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Qrux <qrux.qed@gmail.com>
In-Reply-To: <1329236393.31256.267.camel@zakaz.uk.xensource.com>
Date: Thu, 16 Feb 2012 02:20:28 -0800
Message-Id: <A4D2CFC5-7B9D-4EBD-BDBC-58D6B35FCF6C@gmail.com>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
	<20120214155738.GC21610@andromeda.dapyr.net>
	<1329236393.31256.267.camel@zakaz.uk.xensource.com>
To: xen-devel@lists.xensource.com
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dear Abby,

I've been having intermittent problems booting an ext4 domU--LFS, Linux-3.1 pvops, Xen-4.1.2, xl (not xm).  This thread was started under a different guise, which Ian and Konrad were helpful; I thought the issue was related to NTP.  After more research, with their input, I was able to answer many of my own questions.  Then, after even more research, it seems clear the issue may be far deeper down the abyss...

To start, here's the domU config:

	kernel = "/boot/vmlinuz-3.1-lfs-7.0-DomU"
	memory = 1024
	name = "e4no23-ntp"
	vif = [ 'mac=00:16:3e:00:00:01, bridge=br0' ]
	disk = [ 'phy:/dev/vg-xen/e4no23-ntp,xvda1,w' ]
	root = "/dev/xvda1"
	on_crash = "preserve"

/dev/vg-xen/e4no23-ntp, as the name suggests, is an LVM volume.  When an otherwise identical volume is formatted as ext3, this problem cannot be reproduced.  When this volume is formatted at ext4, the problem below is intermittent, though once it appears, it seems to happen quite often.

In this domU, I boot it and watch the console.  It works, and I copied the output.  Then, I SSH-in and reboot it, again watching the console.  It fails, and I copy the output.  I've included a diff of the good boot vs the bad one, which has 3 chunks.  I'm happy to throw more info into a pastebin if it will help someone trying to eyeball this, but the summary is that in both boots, we see these 5 lines:

  bio: create slab <bio-0> at 0
  xen/balloon: Initialising balloon driver.
  last_pfn = 0x40100 max_arch_pfn = 0x400000000
  Switching to clocksource xen
  Switched to NOHz mode on CPU #0

as the last 5 lines of common output before things get weird in the bad boot:

+ CE: xen increased min_delta_ns to 150000 nsec
+ CE: xen increased min_delta_ns to 225000 nsec
+ CE: xen increased min_delta_ns to 337500 nsec
+ CE: xen increased min_delta_ns to 506250 nsec
+ CE: xen increased min_delta_ns to 759375 nsec
+ CE: xen increased min_delta_ns to 1139062 nsec
+ CE: xen increased min_delta_ns to 1708593 nsec
+ CE: xen increased min_delta_ns to 2562889 nsec
+ CE: xen increased min_delta_ns to 3844333 nsec
+ CE: xen increased min_delta_ns to 4000000 nsec
+ CE: Reprogramming failure. Giving up
+ CE: Reprogramming failure. Giving up
+ hrtimer: interrupt took 9750 ns
+ CE: Reprogramming failure. Giving up
  FS-Cache: Loaded
  CacheFiles: Loaded
  NET: Registered protocol family 2
  IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
  TCP established hash table entries: 131072 (order: 9, 2097152 bytes)

>From my research, it seems as if this issue has come up before, in perhaps 3 manifestations:

	* Jul 2010
	* [Xen-devel] xen tsc problems?
	* http://tinyurl.com/7dqf5qx

	* Jan 2011
	* [Xen-users] CentOS 5.5 x86_64 - XEN DomU LVM ext4 partition support
	* http://tinyurl.com/842rx8b

	* Aug 2011
	* [Xen-devel] xen-4.1: PV domain hanging at startup, jiffies stopped
	* http://tinyurl.com/7f9osav

Of course, I'm not absolutely certain that they are related, but the symptoms that all 3 people described fit my current observations.  In the first one, it seemed like the resolution was about timer_mode being changed from its default of 0 (zero) to 1 (one) in xl.  The post suggests that the TSC can operate in multiple "modes", though I have no idea what those are, and what they do.  That seemed to conclude the issue in mid 2010...

In Jan 2011, it manifests (in my interpretation) as an EXT4 failure.  And, in my particular case, I believe these issues are related, because I cannot repro this problem using ext3.

Then, in Aug 2011, it comes back.  (Interestingly, this issue appears alongside a nearly identical issue captured in a thread in Feb 2011...more on this later.)  The OP does an epic amount of debugging, during which, someone suggest using xenctx to look at the crashed VM.  Here's what I get:

====
xlapp [~] # /usr/lib/xen/bin/xenctx -s /boot/System.map-3.1-DomU 3 0
rip: ffffffff810013aa hypercall_page+0x3aa 
flags: 00001246 i z p
rsp: ffffffff81709ee0
rax: 0000000000000000	rcx: ffffffff810013aa	rdx: 0000000000000000
rbx: ffffffff81709fd8	rsi: 0000000000000000	rdi: 0000000000000001
rbp: ffffffff81709ef8	 r8: 0000000000000000	 r9: 0000000000000000
r10: 0000000000000400	r11: 0000000000000246	r12: 0000000000000000
r13: ffff88003fff3b80	r14: ffffffffffffffff	r15: 0000000000000000
 cs: e033	 ss: e02b	 ds: 0000	 es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ ffff88003ffd3000/0000000000000000
Code (instr addr ffffffff810013aa)
cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc 


Stack:
 0000000000000000 00000000ffffffff ffffffff81009f60 ffffffff81709f28
 ffffffff8101a2c0 ffffffff81709fd8 ffffffff817784c0 ffff88003fff3b80
 ffffffffffffffff ffffffff81709f48 ffffffff810121b6 ffffffff817c6e40
 ffffffff817ca5e0 ffffffff81709f58 ffffffff81526549 ffffffff81709f98

Call Trace:
  [<ffffffff810013aa>] hypercall_page+0x3aa  <--
  [<ffffffff81009f60>] xen_safe_halt+0x10 
  [<ffffffff8101a2c0>] default_idle+0x60 
  [<ffffffff810121b6>] cpu_idle+0x66 
  [<ffffffff81526549>] rest_init+0x6d 
  [<ffffffff81796b87>] start_kernel+0x332 
  [<ffffffff81796347>] x86_64_start_reservations+0x132 
  [<ffffffff817994a9>] xen_start_kernel+0x50c 
====

This is the same "useless" output that the OP of thread 3 saw: a trace ending in the same "hypercall_page+0x3aa" line.  Later on in the thread, having received very little feedback, OP makes this claim (responding to his own email):

====
> I've collected few more messages from successful and failed domU starts.
> The only difference is the place where "Switched to NOHz mode on CPU #0"
> appears and existence of "CE: xen increased min_delta_ns to ..." and
> "CE: Reprogramming failure. Giving up" messages.
> 
> I think it can be related to:
> http://lists.xensource.com/archives/html/xen-devel/2010-07/msg00649.html
> (this was on HVM not PV, but looks similar)
> 
> I've tried also xenpm set-max-cstate 0 and tsc_mode=1 in domU config,
> but it doesn't help. Also pinning vcpu doesn't help (this domUs have
> only 1 vcpu). Is 'xenpm set-max-cstate 0' the same as booting xen with
> max_cstate=0?

Looks like tsc_mode=2 solves the problem.
====

Other people go on to say that setting tsc_mode=2 is a work-around, and only indicative of a deeper problem, though no one seems to know what it is.  Someone else suggests that tsc_mode=0 is (was?) the default and should be equivalent to tsc_mode=2, making the OP's change an effective no-op.  Later, the OP references a document:

	http://lxr.xensource.com/lxr/source/docs/misc/tscmode.txt

which doesn't exist, but I assume is this:

	xen-4.1.2/docs/misc/tscmode.txt

I've run:

	xl debug-key s; xl dmesg | tail

per its suggestion:

====
xlapp [~] # xl dmesg | tail
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.3
(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.1
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 01:00.0
(XEN) TSC has constant rate, no deep Cstates, passed warp test, deemed reliable, warp=0 (count=1)
(XEN) dom3: mode=0,ofs=0xf193f5ae955,khz=2628837,inc=1,vtsc count: 516338 kernel, 0 user
====

It appears as if the system is TSC-safe (in the lexicon of docs/misc/tscmode.txt).  So, it looks like it's going to use mode=0, and essentially use the native rdtsc family of instructions.

But, this doesn't appear to be the case.  Like the OP from Aug 11, explicitly setting tsc_mode=1 breaks domU (repro's the hang), whereas setting tsc_mode=2 unbreaks it (I have not, over several restarts, seen the problem reappear.

* * *

After doing more research, it turns out there was a parallel discussion to the one in Aug 2011 which started 6 months earlier, but continued through Sept 2011:

	* Feb 2011 - Sept 2011
	* [Xen-devel] Xen 4 TSC problems
	* http://xen.1045712.n5.nabble.com/Xen-4-TSC-problems-td3396848.html

Lots of issues were discussed, including changing the Xen platform timer to PIT instead of TSC/HPET, setting cpuidle=0, disabling HPET from the BIOS, turning deep C states off, and so on.  I hate to complain about a product I've so enjoyed using, now in version 4.x.y, but that's--

	A LOT of trial-and-error...

...with A LOT of wait-and-see if it solves the issue.  The main question, IMO, is:

	Is there a definitive configuration which is safe?

The academic-leaning "correctness" issue seems to be:

	Why isn't tsc_mode=1 working, when it's claimed to be "slow-but-correct"?

But, practically, is there a safe CPU configuration?  Putting aside everyone's concerns about saving the planet, (or budgetary concerns, if your colo bills by the Watt or if you run your own data center and pay for the electricity), is there a "safe" server config in terms of C-states, ACPI, etc?  And, by "safe", I mean, a statement like this:

====
"We know this BIOS config will very likely work if the CPU doesn't try to do a bunch of fancy speed-stepping or turbo-boosting (who are we, Knight Rider?) or deep-sleeping or blah-blah-blah.  Turn X on, and Y off, and set Z to this in your BIOS, start the hypervisor (kernel=xen line) with options A=a, B=b, C=c, run dom0 (module=vmlinuz-dom0 line) with options L=l, M=m, and N=n, and try to get your machine to state EFGHIJK so we know the machine will roughly have behaviors P, Q, R, and S, which should work with tsc_mode=N."
====

Since September, I can't find any further information about this issue. What is the state of this issue?  The inconsistency I see right now is this: in the July 2010 TSC discussion, a "Stefano Stabellini" posted this:

====
> /me wonders if timer_mode=1 is the default for xl?
> Or only for xm?

no, it is not.
Xl defaults to 0 [zero], I am going to change it right now.
====

So, it seems like (at least as of July 2010), xl is defaulting to "timer_mode=1".  That is, assuming that the then-current timer_mode is the same as present-day tsc_mode.  In addition, I'm assuming he was changing it from 0 (zero) to 1 (one)--and not some other mode.  But,

	xen-4.1.2/docs/misc/tscmode.txt

says:

	"The default mode (tsc_mode==0) checks TSC-safeness of the underlying
	hardware on which the virtual machine is launched.  If it is
	TSC-safe, rdtsc will execute at hardware speed; if it is not, rdtsc
	will be emulated."

Which implies the default is always 0 (zero).  Which is it?  More importantly, is the solution to force tsc_mode=2?  If so, under what BIOS/xen-boot-params/dom0-boot-params conditions?  And--please excuse my exasperation--but WTH does this have to do with ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET "jumpiness" (if that's even what's happening)?

Sincerely,
  Deeply Concerned & Slightly Frustrated




p.s. I've attached my dom0 'xl dmesg' output, in case that helps:

======== START xl dmesg ========
 __  __            _  _    _   ____  
 \ \/ /___ _ __   | || |  / | |___ \ 
  \  // _ \ '_ \  | || |_ | |   __) |
  /  \  __/ | | | |__   _|| |_ / __/ 
 /_/\_\___|_| |_|    |_|(_)_(_)_____|
                                     
(XEN) Xen version 4.1.2 (blfs@site) (gcc version 4.6.1 (GCC) ) Tue Feb 14 21:47:22 PST 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=1024M loglvl=all guest_loglvl=all console_to_ring sync_console
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e4000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000ddd80000 (usable)
(XEN)  00000000ddd80000 - 00000000ddd8e000 (ACPI data)
(XEN)  00000000ddd8e000 - 00000000dddd0000 (ACPI NVS)
(XEN)  00000000dddd0000 - 00000000e0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000220000000 (usable)
(XEN) ACPI: RSDP 000FB760, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT DDD80100, 0054 (r1 A_M_I_ OEMXSDT  10001121 MSFT       97)
(XEN) ACPI: FACP DDD80290, 00F4 (r3 A_M_I_ OEMFACP  10001121 MSFT       97)
(XEN) ACPI: DSDT DDD80440, 8794 (r1  A1745 A1745000        0 INTL 20060113)
(XEN) ACPI: FACS DDD8E000, 0040
(XEN) ACPI: APIC DDD80390, 006C (r1 A_M_I_ OEMAPIC  10001121 MSFT       97)
(XEN) ACPI: MCFG DDD80400, 003C (r1 A_M_I_ OEMMCFG  10001121 MSFT       97)
(XEN) ACPI: OEMB DDD8E040, 0089 (r1 A_M_I_ AMI_OEM  10001121 MSFT       97)
(XEN) ACPI: HPET DDD88BE0, 0038 (r1 A_M_I_ OEMHPET  10001121 MSFT       97)
(XEN) ACPI: GSCI DDD8E0D0, 2024 (r1 A_M_I_ GMCHSCI  10001121 MSFT       97)
(XEN) System RAM: 8157MB (8352892kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000220000000
(XEN) Domain heap initialised
(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[ddd8e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
(XEN) Processor #2 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
(XEN) Processor #3 6:15 APIC version 20
(XEN) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2628.837 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC TPR shadow
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Brought up 4 CPUs
(XEN) HPET: 3 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x23cf000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000214000000->0000000218000000 (245760 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff823cf000
(XEN)  Init. ramdisk: ffffffff823cf000->ffffffff823cf000
(XEN)  Phys-Mach map: ffffffff823cf000->ffffffff825cf000
(XEN)  Start info:    ffffffff825cf000->ffffffff825cf4b4
(XEN)  Page tables:   ffffffff825d0000->ffffffff825e7000
(XEN)  Boot stack:    ffffffff825e7000->ffffffff825e8000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82800000
(XEN)  ENTRY ADDRESS: ffffffff820e3200
(XEN) Dom0 has maximum 4 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) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 216kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.0-xlapp-dom0-debug (root@xlapp) (gcc version 4.6.1 (GCC) ) #1 SMP Wed Feb 15 19:22:24 PST 2012
[    0.000000] Command line: root=/dev/sda5 raid=noautodetect console=tty0 earlyprintk=xen nomodeset initcall_debug debug loglevel=10
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 140000 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009f000 (usable)
[    0.000000]  Xen: 000000000009fc00 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  Xen: 0000000040000000 - 00000000ddd80000 (unusable)
[    0.000000]  Xen: 00000000ddd80000 - 00000000ddd8e000 (ACPI data)
[    0.000000]  Xen: 00000000ddd8e000 - 00000000dddd0000 (ACPI NVS)
[    0.000000]  Xen: 00000000dddd0000 - 00000000e0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 00000002bdd80000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] DMI: System manufacturer System Product Name/P5G41T-M LX PLUS, BIOS 0502    10/21/2011
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x2bdd80 max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[    0.000000] initial memory mapped : 0 - 023cf000
[    0.000000] Base memory trampoline at [ffff88000009d000] 9d000 size 8192
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000]  0000000000 - 0040000000 page 4k
[    0.000000] kernel direct mapping tables up to 40000000 @ dfe000-1000000
[    0.000000] xen: setting RW the range fe6000 - 1000000
[    0.000000] init_memory_mapping: 0000000100000000-00000002bdd80000
[    0.000000]  0100000000 - 02bdd80000 page 4k
[    0.000000] kernel direct mapping tables up to 2bdd80000 @ 3ea05000-40000000
[    0.000000] xen: setting RW the range 3f7fb000 - 40000000
[    0.000000] ACPI: RSDP 00000000000fb760 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 00000000ddd80100 00054 (v01 A_M_I_ OEMXSDT  10001121 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000ddd80290 000F4 (v03 A_M_I_ OEMFACP  10001121 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000ddd80440 08794 (v01  A1745 A1745000 00000000 INTL 20060113)
[    0.000000] ACPI: FACS 00000000ddd8e000 00040
[    0.000000] ACPI: APIC 00000000ddd80390 0006C (v01 A_M_I_ OEMAPIC  10001121 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000ddd80400 0003C (v01 A_M_I_ OEMMCFG  10001121 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000ddd8e040 00089 (v01 A_M_I_ AMI_OEM  10001121 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000ddd88be0 00038 (v01 A_M_I_ OEMHPET  10001121 MSFT 00000097)
[    0.000000] ACPI: GSCI 00000000ddd8e0d0 02024 (v01 A_M_I_ GMCHSCI  10001121 MSFT 00000097)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000002bdd80000
[    0.000000] Initmem setup node 0 0000000000000000-00000002bdd80000
[    0.000000]   NODE_DATA [000000003fffb000 - 000000003fffffff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x002bdd80
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00100000 -> 0x002bdd80
[    0.000000] On node 0 totalpages: 2088207
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 490 pages reserved
[    0.000000]   DMA zone: 3429 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 16320 pages used for memmap
[    0.000000]   DMA32 zone: 241728 pages, LIFO batch:31
[    0.000000]   Normal zone: 28534 pages used for memmap
[    0.000000]   Normal zone: 1797642 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 4, version 255, address 0xfec00000, GSI 0-255
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 272
[    0.000000] Allocating PCI resources starting at e0000000 (gap: e0000000:1ec00000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.2 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88003ff57000 s78912 r8192 d23488 u110592
[    0.000000] pcpu-alloc: s78912 r8192 d23488 u110592 alloc=27*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2042799
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=/dev/sda5 raid=noautodetect console=tty0 earlyprintk=xen nomodeset initcall_debug debug loglevel=10
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Placing 64MB software IO TLB between ffff880032600000 - ffff880036600000
[    0.000000] software IO TLB at phys 0x32600000 - 0x36600000
[    0.000000] Memory: 812604k/11499008k available (11712k kernel code, 3146180k absent, 7540224k reserved, 5491k data, 828k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:4352 nr_irqs:1024 16
[    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0
[    0.000000] xen: registering gsi 9 triggering 0 polarity 0
[    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
[    0.000000] xen: acpi sci 9
[    0.000000] xen: --> pirq=1 -> irq=1 (gsi=1)
[    0.000000] xen: --> pirq=2 -> irq=2 (gsi=2)
[    0.000000] xen: --> pirq=3 -> irq=3 (gsi=3)
[    0.000000] xen: --> pirq=4 -> irq=4 (gsi=4)
[    0.000000] xen: --> pirq=5 -> irq=5 (gsi=5)
[    0.000000] xen: --> pirq=6 -> irq=6 (gsi=6)
[    0.000000] xen: --> pirq=7 -> irq=7 (gsi=7)
[    0.000000] xen: --> pirq=8 -> irq=8 (gsi=8)
[    0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9
[    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
[    0.000000] xen: --> pirq=10 -> irq=10 (gsi=10)
[    0.000000] xen: --> pirq=11 -> irq=11 (gsi=11)
[    0.000000] xen: --> pirq=12 -> irq=12 (gsi=12)
[    0.000000] xen: --> pirq=13 -> irq=13 (gsi=13)
[    0.000000] xen: --> pirq=14 -> irq=14 (gsi=14)
[    0.000000] xen: --> pirq=15 -> irq=15 (gsi=15)
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled, bootconsole disabled
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:02.0
(XEN) PCI add device 00:1b.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.1
(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.3
(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.1
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 01:00.0
(XEN) TSC has constant rate, no deep Cstates, passed warp test, deemed reliable, warp=0 (count=1)
(XEN) dom3: mode=0,ofs=0xf193f5ae955,khz=2628837,inc=1,vtsc count: 516338 kernel, 0 user
========  END  xl dmesg ========
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:53:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1Rxyxh-00052z-8U; Thu, 16 Feb 2012 10:53:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1Rxyxf-00052r-U3
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:53:16 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329389588!15590747!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21934 invoked from network); 16 Feb 2012 10:53:09 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 10:53:09 -0000
Received: by vbbfq11 with SMTP id fq11so3469459vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 02:53:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=t2hdgmI/1OcTmyis3ijA/mtN8kYC+NjYJGWvm2UJN/Q=;
	b=nhhp1qmDVWCXRYlh1431q9Oa68xzr9dIIJJ1526e9FTGdcs3Dpz7IkBgvVG8CAWD8v
	C3VMOzAN7D4WHilx8NdARzyxaWMgo/cnhdejvEUOXtwZdJAI8qRwHRsTZY085LZibDq/
	sIFZmRd9mAO4OimLOWdpr7t7u8I2+P+M5I5Dc=
MIME-Version: 1.0
Received: by 10.52.93.74 with SMTP id cs10mr800238vdb.42.1329389588496; Thu,
	16 Feb 2012 02:53:08 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Thu, 16 Feb 2012 02:53:08 -0800 (PST)
Date: Thu, 16 Feb 2012 19:53:08 +0900
Message-ID: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello All,

When a HVM guest is started upstream qemu presents the emulated drives
as PCI devices or ata drives?
If more than drive is present how can I know which drive is which in xensto=
re?

Thanks for the info,

Daniel


-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 10:53:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 10: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.xensource.com>)
	id 1Rxyxh-00052z-8U; Thu, 16 Feb 2012 10:53:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1Rxyxf-00052r-U3
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 10:53:16 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329389588!15590747!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21934 invoked from network); 16 Feb 2012 10:53:09 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 10:53:09 -0000
Received: by vbbfq11 with SMTP id fq11so3469459vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 02:53:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=t2hdgmI/1OcTmyis3ijA/mtN8kYC+NjYJGWvm2UJN/Q=;
	b=nhhp1qmDVWCXRYlh1431q9Oa68xzr9dIIJJ1526e9FTGdcs3Dpz7IkBgvVG8CAWD8v
	C3VMOzAN7D4WHilx8NdARzyxaWMgo/cnhdejvEUOXtwZdJAI8qRwHRsTZY085LZibDq/
	sIFZmRd9mAO4OimLOWdpr7t7u8I2+P+M5I5Dc=
MIME-Version: 1.0
Received: by 10.52.93.74 with SMTP id cs10mr800238vdb.42.1329389588496; Thu,
	16 Feb 2012 02:53:08 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Thu, 16 Feb 2012 02:53:08 -0800 (PST)
Date: Thu, 16 Feb 2012 19:53:08 +0900
Message-ID: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello All,

When a HVM guest is started upstream qemu presents the emulated drives
as PCI devices or ata drives?
If more than drive is present how can I know which drive is which in xensto=
re?

Thanks for the info,

Daniel


-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 11:14:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 11: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.xensource.com>)
	id 1RxzHV-0005KA-Eu; Thu, 16 Feb 2012 11:13: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 1RxzHT-0005K5-Kk
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 11:13:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329390778!52683473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5201 invoked from network); 16 Feb 2012 11:12:58 -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;
	16 Feb 2012 11:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="10741355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 11:13:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 11:13:37 +0000
Message-ID: <1329390815.5975.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Thu, 16 Feb 2012 11:13:35 +0000
In-Reply-To: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
> Hello All,
> 
> When a HVM guest is started upstream qemu presents the emulated drives
> as PCI devices or ata drives?

> If more than drive is present how can I know which drive is which in xenstore?

Emulated devices do not appear in xenstore.

Some PV devices may have an emulated equivalent but the rule of thumb is
that an OS should only use either PV or Emulated devices and not mix and
match.

In Linux we implement this by requiring that the emulated devices are
unplugged before we will use the PV path.

In principal you can infer which Emulated device might matches a PV
device, the file docs/misc/vbd-interface.txt in the xen tree gives some
hints about this, but basically PV disks 0..3 can correspond to the
first four IDE devices (primary-master, primary-slave, secondary-master
& secondary-slave).

I presume you are asking in the context of SeaBIOS. In that context you
could argue against unplugging because the guest OS may want to use
emulated devices, however I would suggest that for simplicity for time
being you just unplug the emulated devices before you enable the PV
path.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 11:14:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 11: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.xensource.com>)
	id 1RxzHV-0005KA-Eu; Thu, 16 Feb 2012 11:13: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 1RxzHT-0005K5-Kk
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 11:13:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329390778!52683473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5201 invoked from network); 16 Feb 2012 11:12:58 -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;
	16 Feb 2012 11:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208";a="10741355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 11:13:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 11:13:37 +0000
Message-ID: <1329390815.5975.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Thu, 16 Feb 2012 11:13:35 +0000
In-Reply-To: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
> Hello All,
> 
> When a HVM guest is started upstream qemu presents the emulated drives
> as PCI devices or ata drives?

> If more than drive is present how can I know which drive is which in xenstore?

Emulated devices do not appear in xenstore.

Some PV devices may have an emulated equivalent but the rule of thumb is
that an OS should only use either PV or Emulated devices and not mix and
match.

In Linux we implement this by requiring that the emulated devices are
unplugged before we will use the PV path.

In principal you can infer which Emulated device might matches a PV
device, the file docs/misc/vbd-interface.txt in the xen tree gives some
hints about this, but basically PV disks 0..3 can correspond to the
first four IDE devices (primary-master, primary-slave, secondary-master
& secondary-slave).

I presume you are asking in the context of SeaBIOS. In that context you
could argue against unplugging because the guest OS may want to use
emulated devices, however I would suggest that for simplicity for time
being you just unplug the emulated devices before you enable the PV
path.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 11:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 11:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxzZ8-0005Xd-6C; Thu, 16 Feb 2012 11:31:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxzZ6-0005XY-Gi
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 11:31:56 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329391909!9441446!1
X-Originating-IP: [209.85.212.65]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24165 invoked from network); 16 Feb 2012 11:31:50 -0000
Received: from mail-vw0-f65.google.com (HELO mail-vw0-f65.google.com)
	(209.85.212.65)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 11:31:50 -0000
Received: by vbbez10 with SMTP id ez10so142968vbb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 03:31:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=vqrLUCftqOo1RkL+wqWnHGOTlrPJWo3MCUsyHzL1MH0=;
	b=g0rgFCfkEuV8V4dBRfTTgdrTiD5tBDx0qXHvk42xh0RKKQuAK/hKMDRzo9eGIE9zIC
	T81fmSncYXsokI4mGMLA0s1YvzNXRTooUkgxFRTufF8yuKgFTe9n30i5J1LFxfr8cSKp
	jfPFtyghT/l5xNkGiAibgDNPcR6Cl8T6wL06Q=
MIME-Version: 1.0
Received: by 10.52.172.202 with SMTP id be10mr779241vdc.116.1329390817793;
	Thu, 16 Feb 2012 03:13:37 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Thu, 16 Feb 2012 03:13:37 -0800 (PST)
Date: Thu, 16 Feb 2012 19:13:37 +0800
Message-ID: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Where's the entry code of backup host in Remus?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6908350487583101460=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6908350487583101460==
Content-Type: multipart/alternative; boundary=bcaec51b18af76569604b912ebea

--bcaec51b18af76569604b912ebea
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I'm reading Remus part of Xen 4.x code and now I can find the entry code of
Primary host, which is located in tools/remus directory. But I cannot find
the entry code of backup host. Which codes will the backup host execute
when the primary code send header of a VM? I can only find some codes are
executed in tools/libxc/xc_domain_restore.c, which restores the backup VM
as soon as the Primary VM stops. When the backup host synchronizing the
state of primary VM (including machine state, memory state and disk state),
which part of code will be execute?

Thanks.

-- 
Regards, Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--bcaec51b18af76569604b912ebea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I&#39;m reading Remus part of Xen 4.x code and now I can find t=
he entry code of Primary host, which is located in tools/remus directory. B=
ut I cannot find the entry code of backup host. Which codes will the backup=
 host execute when the primary code send header of a VM? I can only find so=
me codes are executed in tools/libxc/xc_domain_restore.c, which restores th=
e backup VM as soon as the Primary VM stops. When the backup host=A0synchro=
nizing the state of primary VM (including machine state, memory state and d=
isk state), which part of code will be execute?</div>
<div><br></div><div>Thanks.</div><div><br>-- <br>Regards, Chunqi Li<br>Depa=
rtment of Computer Science<br>School of EECS<br>Peking University<br>Beijin=
g, China<br>
</div>

--bcaec51b18af76569604b912ebea--


--===============6908350487583101460==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6908350487583101460==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 11:32:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 11:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RxzZ8-0005Xd-6C; Thu, 16 Feb 2012 11:31:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RxzZ6-0005XY-Gi
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 11:31:56 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329391909!9441446!1
X-Originating-IP: [209.85.212.65]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24165 invoked from network); 16 Feb 2012 11:31:50 -0000
Received: from mail-vw0-f65.google.com (HELO mail-vw0-f65.google.com)
	(209.85.212.65)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 11:31:50 -0000
Received: by vbbez10 with SMTP id ez10so142968vbb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 03:31:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=vqrLUCftqOo1RkL+wqWnHGOTlrPJWo3MCUsyHzL1MH0=;
	b=g0rgFCfkEuV8V4dBRfTTgdrTiD5tBDx0qXHvk42xh0RKKQuAK/hKMDRzo9eGIE9zIC
	T81fmSncYXsokI4mGMLA0s1YvzNXRTooUkgxFRTufF8yuKgFTe9n30i5J1LFxfr8cSKp
	jfPFtyghT/l5xNkGiAibgDNPcR6Cl8T6wL06Q=
MIME-Version: 1.0
Received: by 10.52.172.202 with SMTP id be10mr779241vdc.116.1329390817793;
	Thu, 16 Feb 2012 03:13:37 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Thu, 16 Feb 2012 03:13:37 -0800 (PST)
Date: Thu, 16 Feb 2012 19:13:37 +0800
Message-ID: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Where's the entry code of backup host in Remus?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6908350487583101460=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6908350487583101460==
Content-Type: multipart/alternative; boundary=bcaec51b18af76569604b912ebea

--bcaec51b18af76569604b912ebea
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I'm reading Remus part of Xen 4.x code and now I can find the entry code of
Primary host, which is located in tools/remus directory. But I cannot find
the entry code of backup host. Which codes will the backup host execute
when the primary code send header of a VM? I can only find some codes are
executed in tools/libxc/xc_domain_restore.c, which restores the backup VM
as soon as the Primary VM stops. When the backup host synchronizing the
state of primary VM (including machine state, memory state and disk state),
which part of code will be execute?

Thanks.

-- 
Regards, Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--bcaec51b18af76569604b912ebea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I&#39;m reading Remus part of Xen 4.x code and now I can find t=
he entry code of Primary host, which is located in tools/remus directory. B=
ut I cannot find the entry code of backup host. Which codes will the backup=
 host execute when the primary code send header of a VM? I can only find so=
me codes are executed in tools/libxc/xc_domain_restore.c, which restores th=
e backup VM as soon as the Primary VM stops. When the backup host=A0synchro=
nizing the state of primary VM (including machine state, memory state and d=
isk state), which part of code will be execute?</div>
<div><br></div><div>Thanks.</div><div><br>-- <br>Regards, Chunqi Li<br>Depa=
rtment of Computer Science<br>School of EECS<br>Peking University<br>Beijin=
g, China<br>
</div>

--bcaec51b18af76569604b912ebea--


--===============6908350487583101460==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6908350487583101460==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 12:17:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 12:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry0GL-0005tm-F6; Thu, 16 Feb 2012 12:16:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Ry0GJ-0005th-Q2
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 12:16:36 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329394542!54514635!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0NzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4077 invoked from network); 16 Feb 2012 12:15:43 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 12:15:43 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1GCGUsm020854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 16 Feb 2012 07:16:30 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1GCGRv7020797; Thu, 16 Feb 2012 07:16:28 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Thu, 16 Feb 2012 13:16:25 +0100
Message-Id: <1329394585-10129-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] blkfront: don't put bdev right after getting it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We should hang onto bdev until we're done with it.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/block/xen-blkfront.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..5d45688 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
 	mutex_lock(&blkfront_mutex);
 
 	bdev = bdget_disk(disk, 0);
-	bdput(bdev);
 
 	if (bdev->bd_openers)
 		goto out;
@@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
 	}
 
 out:
+	bdput(bdev);
 	mutex_unlock(&blkfront_mutex);
 	return 0;
 }
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 12:17:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 12:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry0GL-0005tm-F6; Thu, 16 Feb 2012 12:16:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Ry0GJ-0005th-Q2
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 12:16:36 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329394542!54514635!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0NzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4077 invoked from network); 16 Feb 2012 12:15:43 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 12:15:43 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1GCGUsm020854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 16 Feb 2012 07:16:30 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1GCGRv7020797; Thu, 16 Feb 2012 07:16:28 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Thu, 16 Feb 2012 13:16:25 +0100
Message-Id: <1329394585-10129-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] blkfront: don't put bdev right after getting it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We should hang onto bdev until we're done with it.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/block/xen-blkfront.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..5d45688 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
 	mutex_lock(&blkfront_mutex);
 
 	bdev = bdget_disk(disk, 0);
-	bdput(bdev);
 
 	if (bdev->bd_openers)
 		goto out;
@@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
 	}
 
 out:
+	bdput(bdev);
 	mutex_unlock(&blkfront_mutex);
 	return 0;
 }
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 12:17:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 12:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry0H3-0005wW-S9; Thu, 16 Feb 2012 12:17:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Ry0H2-0005wB-J4
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 12:17:20 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329394633!11676283!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0NzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5006 invoked from network); 16 Feb 2012 12:17:13 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 12:17:13 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1GCHB2L021001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 16 Feb 2012 07:17:11 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1GCH9gi020887; Thu, 16 Feb 2012 07:17:10 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Thu, 16 Feb 2012 13:17:09 +0100
Message-Id: <1329394629-10299-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We just reported to xenbus that we can't close yet, because
blkfront is still in use. So we shouldn't then immediately
state that we are closing.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/block/xen-blkfront.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5d45688..b53cae4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
 	if (bdev->bd_openers) {
 		xenbus_dev_error(xbdev, -EBUSY,
 				 "Device in use; refusing to close");
-		xenbus_switch_state(xbdev, XenbusStateClosing);
 	} else {
 		xlvbd_release_gendisk(info);
 		xenbus_frontend_closed(xbdev);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 12:17:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 12:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry0H3-0005wW-S9; Thu, 16 Feb 2012 12:17:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Ry0H2-0005wB-J4
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 12:17:20 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329394633!11676283!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM0NzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5006 invoked from network); 16 Feb 2012 12:17:13 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 12:17:13 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1GCHB2L021001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 16 Feb 2012 07:17:11 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1GCH9gi020887; Thu, 16 Feb 2012 07:17:10 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Thu, 16 Feb 2012 13:17:09 +0100
Message-Id: <1329394629-10299-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We just reported to xenbus that we can't close yet, because
blkfront is still in use. So we shouldn't then immediately
state that we are closing.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/block/xen-blkfront.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5d45688..b53cae4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
 	if (bdev->bd_openers) {
 		xenbus_dev_error(xbdev, -EBUSY,
 				 "Device in use; refusing to close");
-		xenbus_switch_state(xbdev, XenbusStateClosing);
 	} else {
 		xlvbd_release_gendisk(info);
 		xenbus_frontend_closed(xbdev);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 13:39:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry1YB-0006Q8-Ej; Thu, 16 Feb 2012 13:39:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1Ry1Y9-0006Q3-VT
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 13:39:06 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329399538!14833376!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8110 invoked from network); 16 Feb 2012 13:38:59 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Feb 2012 13:38:59 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1Ry1Y1-0002QM-2x
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 05:38:57 -0800
Date: Thu, 16 Feb 2012 05:38:57 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329399537084-5489530.post@n5.nabble.com>
In-Reply-To: <201112141043.45780.tobias.geiger@vido.info>
References: <1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGVsbG8sIEknbSB0cnlpbmcgdmdhLXBhc3N0aHJvdWdoIHdpdGggYW4gblZJRElBIGNhcmQuCkkg
YW0gYXQgdGhlIGVuZCBvZiB0aGUgd2F5LCBJIGhhdmUgYXBwbGllZCB0aGUgcGF0Y2hlcyB3aXRo
b3V0IHByb2JsZW1zLiBJCmhhdmUgY29uZmlndXJlZCBteSB3aW54cCBEb21VIGFzIGZvbGxvdzoK
Cmtlcm5lbCA9ICcvdXNyL2xpYi94ZW4vYm9vdC9odm1sb2FkZXInCmJ1aWxkZXIgPSAnaHZtJwpt
ZW1vcnkgPSAnNTEyJwpkZXZpY2VfbW9kZWw9Jy91c3IvbGliL3hlbi9iaW4vcWVtdS1kbScKCiNO
dW1iZXIgb2YgQ1BV4oCZcwp2Y3B1cyA9IDEJCgojIERpc2tzCmRpc2sgPSBbICdmaWxlOi94ZW4v
ZG9tYWlucy93aW4wMS9kaXNrLmltZyxpb2VtdTpoZGEsdycsCidmaWxlOi9ob21lL1dpbmRvd3NY
UC1TUDIvaW1hZ2UuaXNvLGlvZW11OmhkYzpjZHJvbSxyJyBdCgojIEhvc3RuYW1lCm5hbWUgPSAn
d2luMDEnCgojIE5ldHdvcmtpbmcKdmlmID0gWyd0eXBlPWlvZW11LCBicmlkZ2U9eGVuYnIwJ10K
CiNQYXNzdGhyb3VnaAoqZ2Z4X3Bhc3N0aHJ1PTEKcGNpICA9IFsgJzAxOjAwLjAnIF0qCgpib290
PSdjZCcKKnZuYz0xCnZuY3ZpZXdlcj0xKgphY3BpID0gMQpzZGw9MApzZXJpYWw9J3B0eScKb25f
cG93ZXJvZmYgPSAnZGVzdHJveScKb25fcmVib290ID0gJ3Jlc3RhcnQnCm9uX2NyYXNoID0gJ3Jl
c3RhcnQnCgpJIGhhdmUgcmVhZCB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSB0byB1c2UgVk5DIGlm
IEkgcGFzc2VkLXRocm91Z2gtVkdBIENhcmQsCmFzIFRvYmlhcyBzYXlzIGhlcmU6CgoKClRvYmlh
cyBHZWlnZXIgd3JvdGUKPiAKPiBIaSBTeXRocmFyLAo+IAo+IHlvdSBjYW4ndCBzZWUgdGhlIG91
dHB1dCBvZiB0aGUgcGFzc2VkLXRocm91Z2gtVkdBIENhcmQgaW4gVk5DLiBBdCBsZWFzdAo+IG5v
dCAKPiBpbiB0aGUgcWVtdS12bmMgc2VydmVyOyBUaGUgb3V0cHV0IHRvIHRoYXQgZW11bGF0ZWQg
KENpcnJ1cz8pIENhcmQgc3RvcHMKPiBhcyAKPiBzb29uIGFzICB0aGUgRHJpdmVyIGZvciB0aGUg
cGFzc2VkLXRocm91Z2gtVkdBIENhcmQgaXMgbG9hZGVkIHdpdGhpbiB0aGUKPiBEb21VLgo+IEZy
b20gdGhhdCBtb21lbnQgb24gdGhlIHlvdSBjYW4gb25seSBzZWUgdGhlIG91dHB1dCBvbiBhIE1v
bml0b3IgYXR0YWNoZWQKPiB0byAKPiB0aGUgcGFzc2VkLXRocm91Z2gtVkdBIENhcmQuIFZOQyBp
cyBvZiBjb3Vyc2UgcG9zc2libGUgd2l0aCB0aGUgRG9tVSAKPiBmYWNpbGl0aWVzLCBpLmUuIGlu
c3RhbGwgYSBWTkMgU2VydmVyIHdpdGhpbiBEb21VIGFuZCBhdHRhY2ggYSB2bmN2aWV3ZXIKPiB0
byBpdCAKPiAtIGJ1dCBpdHMgbm90IHJlYWxseSBwcmFjdGljYWwgcmVnYXJkaW5nIDNELSBvciBN
b3ZpZSBPdXRwdXQgKGF0IGxlYXN0IG5vdCAKPiB3aXRob3V0IG9wdGltaXphdGlvbnMgdG8gdGhl
IFZOQyBTZXJ2ZXIvQ2xpZW50KQo+IAo+IEdyZWV0aW5ncwo+IFRvYmlhcwo+IAoKU28gSSBoYXZl
IHR3byBwcm9iZW1zLCAKSSBkb24ndCBrbm93IGhvdyB0byBhdHRhY2ggYSBNb25pdG9yIHRvIHRo
ZSBwYXNzZWQtdGhyb3VnaC1WR0EgQ2FyZCwKaG93IGNhbiBJIGRvIHRoaXMgaW4gdGhlIGNmZyBm
aWxlPwpTaG91bGQgSSB1c2UgYW5vdGhlciBvcHRpb24gdG8gZGlzYWJsZSB0aGUgY2lycnVzIGVt
dWxhdGVkIGNhcmQgaW4gdGhlIGNmZwpmaWxlPwoKQ291bGQgYW55b25lIHdpdGggYW4gblZJRElB
IGNhcmQgcGFzc2VkLXRocm91Z2hlZCBwb3N0IGhpcyBjb25maWcgZmlsZSBoZXJlPyAKVGhhbmtz
IHlvdSB2ZXJ5IG11Y2ggdG8gZXZlcnlvbmUgaW4gYWR2YW5jZQoKSmFtZXMuCgoKLS0KVmlldyB0
aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20v
UGF0Y2hlcy1mb3ItVkdBLVBhc3N0aHJvdWdoLVhFTi00LTItdW5zdGFibGUtdHA0NDA2MjY1cDU0
ODk1MzAuaHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBh
dCBOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 16 13:39:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry1YB-0006Q8-Ej; Thu, 16 Feb 2012 13:39:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1Ry1Y9-0006Q3-VT
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 13:39:06 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329399538!14833376!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8110 invoked from network); 16 Feb 2012 13:38:59 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Feb 2012 13:38:59 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1Ry1Y1-0002QM-2x
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 05:38:57 -0800
Date: Thu, 16 Feb 2012 05:38:57 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329399537084-5489530.post@n5.nabble.com>
In-Reply-To: <201112141043.45780.tobias.geiger@vido.info>
References: <1319630071722-4939528.post@n5.nabble.com>
	<1319636130.20499.YahooMailNeo@web29808.mail.ird.yahoo.com>
	<1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGVsbG8sIEknbSB0cnlpbmcgdmdhLXBhc3N0aHJvdWdoIHdpdGggYW4gblZJRElBIGNhcmQuCkkg
YW0gYXQgdGhlIGVuZCBvZiB0aGUgd2F5LCBJIGhhdmUgYXBwbGllZCB0aGUgcGF0Y2hlcyB3aXRo
b3V0IHByb2JsZW1zLiBJCmhhdmUgY29uZmlndXJlZCBteSB3aW54cCBEb21VIGFzIGZvbGxvdzoK
Cmtlcm5lbCA9ICcvdXNyL2xpYi94ZW4vYm9vdC9odm1sb2FkZXInCmJ1aWxkZXIgPSAnaHZtJwpt
ZW1vcnkgPSAnNTEyJwpkZXZpY2VfbW9kZWw9Jy91c3IvbGliL3hlbi9iaW4vcWVtdS1kbScKCiNO
dW1iZXIgb2YgQ1BV4oCZcwp2Y3B1cyA9IDEJCgojIERpc2tzCmRpc2sgPSBbICdmaWxlOi94ZW4v
ZG9tYWlucy93aW4wMS9kaXNrLmltZyxpb2VtdTpoZGEsdycsCidmaWxlOi9ob21lL1dpbmRvd3NY
UC1TUDIvaW1hZ2UuaXNvLGlvZW11OmhkYzpjZHJvbSxyJyBdCgojIEhvc3RuYW1lCm5hbWUgPSAn
d2luMDEnCgojIE5ldHdvcmtpbmcKdmlmID0gWyd0eXBlPWlvZW11LCBicmlkZ2U9eGVuYnIwJ10K
CiNQYXNzdGhyb3VnaAoqZ2Z4X3Bhc3N0aHJ1PTEKcGNpICA9IFsgJzAxOjAwLjAnIF0qCgpib290
PSdjZCcKKnZuYz0xCnZuY3ZpZXdlcj0xKgphY3BpID0gMQpzZGw9MApzZXJpYWw9J3B0eScKb25f
cG93ZXJvZmYgPSAnZGVzdHJveScKb25fcmVib290ID0gJ3Jlc3RhcnQnCm9uX2NyYXNoID0gJ3Jl
c3RhcnQnCgpJIGhhdmUgcmVhZCB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSB0byB1c2UgVk5DIGlm
IEkgcGFzc2VkLXRocm91Z2gtVkdBIENhcmQsCmFzIFRvYmlhcyBzYXlzIGhlcmU6CgoKClRvYmlh
cyBHZWlnZXIgd3JvdGUKPiAKPiBIaSBTeXRocmFyLAo+IAo+IHlvdSBjYW4ndCBzZWUgdGhlIG91
dHB1dCBvZiB0aGUgcGFzc2VkLXRocm91Z2gtVkdBIENhcmQgaW4gVk5DLiBBdCBsZWFzdAo+IG5v
dCAKPiBpbiB0aGUgcWVtdS12bmMgc2VydmVyOyBUaGUgb3V0cHV0IHRvIHRoYXQgZW11bGF0ZWQg
KENpcnJ1cz8pIENhcmQgc3RvcHMKPiBhcyAKPiBzb29uIGFzICB0aGUgRHJpdmVyIGZvciB0aGUg
cGFzc2VkLXRocm91Z2gtVkdBIENhcmQgaXMgbG9hZGVkIHdpdGhpbiB0aGUKPiBEb21VLgo+IEZy
b20gdGhhdCBtb21lbnQgb24gdGhlIHlvdSBjYW4gb25seSBzZWUgdGhlIG91dHB1dCBvbiBhIE1v
bml0b3IgYXR0YWNoZWQKPiB0byAKPiB0aGUgcGFzc2VkLXRocm91Z2gtVkdBIENhcmQuIFZOQyBp
cyBvZiBjb3Vyc2UgcG9zc2libGUgd2l0aCB0aGUgRG9tVSAKPiBmYWNpbGl0aWVzLCBpLmUuIGlu
c3RhbGwgYSBWTkMgU2VydmVyIHdpdGhpbiBEb21VIGFuZCBhdHRhY2ggYSB2bmN2aWV3ZXIKPiB0
byBpdCAKPiAtIGJ1dCBpdHMgbm90IHJlYWxseSBwcmFjdGljYWwgcmVnYXJkaW5nIDNELSBvciBN
b3ZpZSBPdXRwdXQgKGF0IGxlYXN0IG5vdCAKPiB3aXRob3V0IG9wdGltaXphdGlvbnMgdG8gdGhl
IFZOQyBTZXJ2ZXIvQ2xpZW50KQo+IAo+IEdyZWV0aW5ncwo+IFRvYmlhcwo+IAoKU28gSSBoYXZl
IHR3byBwcm9iZW1zLCAKSSBkb24ndCBrbm93IGhvdyB0byBhdHRhY2ggYSBNb25pdG9yIHRvIHRo
ZSBwYXNzZWQtdGhyb3VnaC1WR0EgQ2FyZCwKaG93IGNhbiBJIGRvIHRoaXMgaW4gdGhlIGNmZyBm
aWxlPwpTaG91bGQgSSB1c2UgYW5vdGhlciBvcHRpb24gdG8gZGlzYWJsZSB0aGUgY2lycnVzIGVt
dWxhdGVkIGNhcmQgaW4gdGhlIGNmZwpmaWxlPwoKQ291bGQgYW55b25lIHdpdGggYW4gblZJRElB
IGNhcmQgcGFzc2VkLXRocm91Z2hlZCBwb3N0IGhpcyBjb25maWcgZmlsZSBoZXJlPyAKVGhhbmtz
IHlvdSB2ZXJ5IG11Y2ggdG8gZXZlcnlvbmUgaW4gYWR2YW5jZQoKSmFtZXMuCgoKLS0KVmlldyB0
aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20v
UGF0Y2hlcy1mb3ItVkdBLVBhc3N0aHJvdWdoLVhFTi00LTItdW5zdGFibGUtdHA0NDA2MjY1cDU0
ODk1MzAuaHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBh
dCBOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry281-0006k8-QJ; Thu, 16 Feb 2012 14:16:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxHXb-0002Zg-N4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:31:27 +0000
Received: from [85.158.139.83:29755] by server-4.bemta-5.messagelabs.com id
	28/9E-10788-E145A3F4; Tue, 14 Feb 2012 12:31:26 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329222685!12295913!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gODkxMTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15114 invoked from network); 14 Feb 2012 12:31:26 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 12:31:26 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxHXZ-0002pA-B5; Tue, 14 Feb 2012 12:31:25 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Tue, 14 Feb 2012
	12:31:04 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 14 Feb 2012 12:30:53 +0000
Thread-Topic: [Xen-devel] xc_gnttab_get_version question/bug
Thread-Index: Aczg7vp78MN2otoZRXeIr4wCI7QzxgKJYN/f
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>,
	<1328107019.17444.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328107019.17444.74.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have set the noreboot option for Xen and it does not reboot but the machine freezes.
I am unable to get output. Which logs should I check?

Thank you,
Francisco
________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: 01 February 2012 14:36
To: Francisco Rocha
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug

On Thu, 2012-01-26 at 12:04 +0000, Francisco Rocha wrote:
> Hi everyon,
>
> I am new to Xen Development, so I don't know if it is a bug or my lack of knowledge regarding Xen dev.
>
> I am running Fedora 16 x86-64 XFCE with the latest xen unstable and when I run the following code the machine reboots.

Ouch, it certainly shouldn't do that! Do you get any serial console
message or stack trace etc?

You might find it helpful to pass the "noreboot" option on the
hypervisor command line so that you have a chance to see the error
message.

Ian.


>
> #include <xenctrl.h>
>
>
> int main(int argc, char **argv)
> {
>         xc_interface *xch;
>         xch = xc_interface_open(NULL, NULL, 0);
>
>         printf("version: %d\n", xc_gnttab_get_version(xch, 1));
>
>         xc_interface_close(xch);
>
>         return 0;
> }
>
> Can anyone help? Thank you for your time.
>
> Cheers,
> Francisco
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry281-0006k8-QJ; Thu, 16 Feb 2012 14:16:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxHXb-0002Zg-N4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 12:31:27 +0000
Received: from [85.158.139.83:29755] by server-4.bemta-5.messagelabs.com id
	28/9E-10788-E145A3F4; Tue, 14 Feb 2012 12:31:26 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329222685!12295913!1
X-Originating-IP: [128.240.234.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMTIgPT4gODkxMTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15114 invoked from network); 14 Feb 2012 12:31:26 -0000
Received: from cheviot12.ncl.ac.uk (HELO cheviot12.ncl.ac.uk) (128.240.234.12)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 12:31:26 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot12.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxHXZ-0002pA-B5; Tue, 14 Feb 2012 12:31:25 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Tue, 14 Feb 2012
	12:31:04 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 14 Feb 2012 12:30:53 +0000
Thread-Topic: [Xen-devel] xc_gnttab_get_version question/bug
Thread-Index: Aczg7vp78MN2otoZRXeIr4wCI7QzxgKJYN/f
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>,
	<1328107019.17444.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328107019.17444.74.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have set the noreboot option for Xen and it does not reboot but the machine freezes.
I am unable to get output. Which logs should I check?

Thank you,
Francisco
________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: 01 February 2012 14:36
To: Francisco Rocha
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug

On Thu, 2012-01-26 at 12:04 +0000, Francisco Rocha wrote:
> Hi everyon,
>
> I am new to Xen Development, so I don't know if it is a bug or my lack of knowledge regarding Xen dev.
>
> I am running Fedora 16 x86-64 XFCE with the latest xen unstable and when I run the following code the machine reboots.

Ouch, it certainly shouldn't do that! Do you get any serial console
message or stack trace etc?

You might find it helpful to pass the "noreboot" option on the
hypervisor command line so that you have a chance to see the error
message.

Ian.


>
> #include <xenctrl.h>
>
>
> int main(int argc, char **argv)
> {
>         xc_interface *xch;
>         xch = xc_interface_open(NULL, NULL, 0);
>
>         printf("version: %d\n", xc_gnttab_get_version(xch, 1));
>
>         xc_interface_close(xch);
>
>         return 0;
> }
>
> Can anyone help? Thank you for your time.
>
> Cheers,
> Francisco
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry283-0006kl-FJ; Thu, 16 Feb 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 <lars.kurth.xen@gmail.com>) id 1Ry0Hl-0005zs-8L
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 12:18:05 +0000
Received: from [85.158.139.83:5794] by server-10.bemta-5.messagelabs.com id
	EB/C9-07861-BF3FC3F4; Thu, 16 Feb 2012 12:18:03 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329394681!15258795!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29949 invoked from network); 16 Feb 2012 12:18:02 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 12:18:02 -0000
Received: by iaeh11 with SMTP id h11so15658213iae.30
	for <multiple recipients>; Thu, 16 Feb 2012 04:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8pTAyESiwdZSCPlcJJnJJpas5+sDR3gehfsQPKlg48c=;
	b=lVdDpsELdGvH5Yzarccoeetwcyh1sXe9G0Qj/QmFy5Sln3wRYBbjIarnPxAK1Bh1rz
	Bjrj6uSOaGnD4xPRynTjd8VLJBZOYU/z6slrZQ/ko0uzlmVBIqI90mpTTcVivLrtZTqz
	HrpozOjvXJOWAVAQyD4tLOXEOBYpP6px7waRY=
MIME-Version: 1.0
Received: by 10.50.160.131 with SMTP id xk3mr2623726igb.19.1329394680771; Thu,
	16 Feb 2012 04:18:00 -0800 (PST)
Received: by 10.231.7.14 with HTTP; Thu, 16 Feb 2012 04:18:00 -0800 (PST)
In-Reply-To: <1329323919.31256.329.camel@zakaz.uk.xensource.com>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
	<1329323919.31256.329.camel@zakaz.uk.xensource.com>
Date: Thu, 16 Feb 2012 12:18:00 +0000
Message-ID: <CAOqnZH7cB+ixvAvt5KrY+dx2kAOg23BB_Cjo5KRCEgmSj+eyWA@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: Ben Pfaff <blp@nicira.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] [Xen-API]  Pre4paration for the Xen Hackathon,
	March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8367570655928493927=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8367570655928493927==
Content-Type: multipart/alternative; boundary=14dae9340443b6b56604b913d19c

--14dae9340443b6b56604b913d19c
Content-Type: text/plain; charset=ISO-8859-1

Ben,

Mike told me that there are some issues with XCP and Open vSwitch 1.4,
where it would make sense to get Nicira and XCP guys into one room. In
particular using OpenvSwitch 1.4 with the XCP toolstack on Debian Sid and
Linux 3.2. The previous stable OVS release doesn't compile on Linux 3.2, so
unless 1.4 works out of the box, we won't have OVS support in XCP toolstack
on Ubuntu 12.04. That, plus maybe doing some early proof-of-concept work
with Zeus (XCP on Fedora) may also make sense.

Regards
Lars

On Wed, Feb 15, 2012 at 4:38 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> > Lars Kurth <lars.kurth@xen.org> writes:
> >
> > > I have made preparations to reach out to further groups in SIlicon
> > > valley, and want to ensure that the core people are signed up before I
> > > do this.
> >
> > Would it be helpful to have one of Nicira's Open vSwitch
> > developers come? (Is anyone interested in discussing
> > networking-related topics?)
>
> Hi Ben,
>
> I think there will some xapi/XCP folks there who I expect would be
> interested in talking networking and vswitch in that context.
>
> In the context of xen-unstable and the libx/xl toolstacks there's not
> much required for vswitch integration -- just a working hotplug script
> mechanism and a suitable script. I actually have patches for the script
> growing stale in my queue -- they don't work because of issues with
> hotplug script running on shutdown (basically the xenstore info is gone
> when the script runs so we can't remove the VIF from the switch). Roger
> Pau Monee has a patch series fixing hotplug scripts and once it goes in
> I'll resurrect my old patches.
>
> Ian.
>
> >   I've tentatively received permission
> > from management here to join for one or more days if it would be
> > useful.  We're in Silicon Valley anyway so it doesn't require
> > much planning on our end.
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/mailman/listinfo/xen-api
>

--14dae9340443b6b56604b913d19c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ben,<br><br>Mike told me that there are some issues with XCP and Open vSwit=
ch 1.4, where it would make sense to get Nicira and XCP guys into one room.=
 In particular using OpenvSwitch 1.4 with the XCP toolstack on Debian Sid a=
nd Linux 3.2. The previous stable OVS release doesn&#39;t compile on Linux =
3.2, so unless 1.4 works out of the box, we won&#39;t have OVS support in X=
CP toolstack on Ubuntu 12.04. That, plus maybe doing some early proof-of-co=
ncept work with Zeus (XCP on Fedora) may also make sense.<br>

<br>Regards<br>Lars<br><br><div class=3D"gmail_quote">On Wed, Feb 15, 2012 =
at 4:38 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbe=
ll@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div class=3D"im">On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:<br>
&gt; Lars Kurth &lt;<a href=3D"mailto:lars.kurth@xen.org">lars.kurth@xen.or=
g</a>&gt; writes:<br>
&gt;<br>
&gt; &gt; I have made preparations to reach out to further groups in SIlico=
n<br>
&gt; &gt; valley, and want to ensure that the core people are signed up bef=
ore I<br>
&gt; &gt; do this.<br>
&gt;<br>
&gt; Would it be helpful to have one of Nicira&#39;s Open vSwitch<br>
&gt; developers come? (Is anyone interested in discussing<br>
&gt; networking-related topics?)<br>
<br>
</div>Hi Ben,<br>
<br>
I think there will some xapi/XCP folks there who I expect would be<br>
interested in talking networking and vswitch in that context.<br>
<br>
In the context of xen-unstable and the libx/xl toolstacks there&#39;s not<b=
r>
much required for vswitch integration -- just a working hotplug script<br>
mechanism and a suitable script. I actually have patches for the script<br>
growing stale in my queue -- they don&#39;t work because of issues with<br>
hotplug script running on shutdown (basically the xenstore info is gone<br>
when the script runs so we can&#39;t remove the VIF from the switch). Roger=
<br>
Pau Monee has a patch series fixing hotplug scripts and once it goes in<br>
I&#39;ll resurrect my old patches.<br>
<br>
Ian.<br>
<div class=3D"im"><br>
&gt; =A0 I&#39;ve tentatively received permission<br>
&gt; from management here to join for one or more days if it would be<br>
&gt; useful. =A0We&#39;re in Silicon Valley anyway so it doesn&#39;t requir=
e<br>
&gt; much planning on our end.<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
</div>&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
xen-api mailing list<br>
<a href=3D"mailto:xen-api@lists.xensource.com">xen-api@lists.xensource.com<=
/a><br>
<a href=3D"http://lists.xensource.com/mailman/listinfo/xen-api" target=3D"_=
blank">http://lists.xensource.com/mailman/listinfo/xen-api</a><br>
</div></div></blockquote></div><br>

--14dae9340443b6b56604b913d19c--


--===============8367570655928493927==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8367570655928493927==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry283-0006kl-FJ; Thu, 16 Feb 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 <lars.kurth.xen@gmail.com>) id 1Ry0Hl-0005zs-8L
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 12:18:05 +0000
Received: from [85.158.139.83:5794] by server-10.bemta-5.messagelabs.com id
	EB/C9-07861-BF3FC3F4; Thu, 16 Feb 2012 12:18:03 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329394681!15258795!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29949 invoked from network); 16 Feb 2012 12:18:02 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 12:18:02 -0000
Received: by iaeh11 with SMTP id h11so15658213iae.30
	for <multiple recipients>; Thu, 16 Feb 2012 04:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=8pTAyESiwdZSCPlcJJnJJpas5+sDR3gehfsQPKlg48c=;
	b=lVdDpsELdGvH5Yzarccoeetwcyh1sXe9G0Qj/QmFy5Sln3wRYBbjIarnPxAK1Bh1rz
	Bjrj6uSOaGnD4xPRynTjd8VLJBZOYU/z6slrZQ/ko0uzlmVBIqI90mpTTcVivLrtZTqz
	HrpozOjvXJOWAVAQyD4tLOXEOBYpP6px7waRY=
MIME-Version: 1.0
Received: by 10.50.160.131 with SMTP id xk3mr2623726igb.19.1329394680771; Thu,
	16 Feb 2012 04:18:00 -0800 (PST)
Received: by 10.231.7.14 with HTTP; Thu, 16 Feb 2012 04:18:00 -0800 (PST)
In-Reply-To: <1329323919.31256.329.camel@zakaz.uk.xensource.com>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
	<1329323919.31256.329.camel@zakaz.uk.xensource.com>
Date: Thu, 16 Feb 2012 12:18:00 +0000
Message-ID: <CAOqnZH7cB+ixvAvt5KrY+dx2kAOg23BB_Cjo5KRCEgmSj+eyWA@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: Ben Pfaff <blp@nicira.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] [Xen-API]  Pre4paration for the Xen Hackathon,
	March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8367570655928493927=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8367570655928493927==
Content-Type: multipart/alternative; boundary=14dae9340443b6b56604b913d19c

--14dae9340443b6b56604b913d19c
Content-Type: text/plain; charset=ISO-8859-1

Ben,

Mike told me that there are some issues with XCP and Open vSwitch 1.4,
where it would make sense to get Nicira and XCP guys into one room. In
particular using OpenvSwitch 1.4 with the XCP toolstack on Debian Sid and
Linux 3.2. The previous stable OVS release doesn't compile on Linux 3.2, so
unless 1.4 works out of the box, we won't have OVS support in XCP toolstack
on Ubuntu 12.04. That, plus maybe doing some early proof-of-concept work
with Zeus (XCP on Fedora) may also make sense.

Regards
Lars

On Wed, Feb 15, 2012 at 4:38 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> > Lars Kurth <lars.kurth@xen.org> writes:
> >
> > > I have made preparations to reach out to further groups in SIlicon
> > > valley, and want to ensure that the core people are signed up before I
> > > do this.
> >
> > Would it be helpful to have one of Nicira's Open vSwitch
> > developers come? (Is anyone interested in discussing
> > networking-related topics?)
>
> Hi Ben,
>
> I think there will some xapi/XCP folks there who I expect would be
> interested in talking networking and vswitch in that context.
>
> In the context of xen-unstable and the libx/xl toolstacks there's not
> much required for vswitch integration -- just a working hotplug script
> mechanism and a suitable script. I actually have patches for the script
> growing stale in my queue -- they don't work because of issues with
> hotplug script running on shutdown (basically the xenstore info is gone
> when the script runs so we can't remove the VIF from the switch). Roger
> Pau Monee has a patch series fixing hotplug scripts and once it goes in
> I'll resurrect my old patches.
>
> Ian.
>
> >   I've tentatively received permission
> > from management here to join for one or more days if it would be
> > useful.  We're in Silicon Valley anyway so it doesn't require
> > much planning on our end.
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/mailman/listinfo/xen-api
>

--14dae9340443b6b56604b913d19c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ben,<br><br>Mike told me that there are some issues with XCP and Open vSwit=
ch 1.4, where it would make sense to get Nicira and XCP guys into one room.=
 In particular using OpenvSwitch 1.4 with the XCP toolstack on Debian Sid a=
nd Linux 3.2. The previous stable OVS release doesn&#39;t compile on Linux =
3.2, so unless 1.4 works out of the box, we won&#39;t have OVS support in X=
CP toolstack on Ubuntu 12.04. That, plus maybe doing some early proof-of-co=
ncept work with Zeus (XCP on Fedora) may also make sense.<br>

<br>Regards<br>Lars<br><br><div class=3D"gmail_quote">On Wed, Feb 15, 2012 =
at 4:38 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbe=
ll@citrix.com">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div class=3D"im">On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:<br>
&gt; Lars Kurth &lt;<a href=3D"mailto:lars.kurth@xen.org">lars.kurth@xen.or=
g</a>&gt; writes:<br>
&gt;<br>
&gt; &gt; I have made preparations to reach out to further groups in SIlico=
n<br>
&gt; &gt; valley, and want to ensure that the core people are signed up bef=
ore I<br>
&gt; &gt; do this.<br>
&gt;<br>
&gt; Would it be helpful to have one of Nicira&#39;s Open vSwitch<br>
&gt; developers come? (Is anyone interested in discussing<br>
&gt; networking-related topics?)<br>
<br>
</div>Hi Ben,<br>
<br>
I think there will some xapi/XCP folks there who I expect would be<br>
interested in talking networking and vswitch in that context.<br>
<br>
In the context of xen-unstable and the libx/xl toolstacks there&#39;s not<b=
r>
much required for vswitch integration -- just a working hotplug script<br>
mechanism and a suitable script. I actually have patches for the script<br>
growing stale in my queue -- they don&#39;t work because of issues with<br>
hotplug script running on shutdown (basically the xenstore info is gone<br>
when the script runs so we can&#39;t remove the VIF from the switch). Roger=
<br>
Pau Monee has a patch series fixing hotplug scripts and once it goes in<br>
I&#39;ll resurrect my old patches.<br>
<br>
Ian.<br>
<div class=3D"im"><br>
&gt; =A0 I&#39;ve tentatively received permission<br>
&gt; from management here to join for one or more days if it would be<br>
&gt; useful. =A0We&#39;re in Silicon Valley anyway so it doesn&#39;t requir=
e<br>
&gt; much planning on our end.<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
</div>&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
xen-api mailing list<br>
<a href=3D"mailto:xen-api@lists.xensource.com">xen-api@lists.xensource.com<=
/a><br>
<a href=3D"http://lists.xensource.com/mailman/listinfo/xen-api" target=3D"_=
blank">http://lists.xensource.com/mailman/listinfo/xen-api</a><br>
</div></div></blockquote></div><br>

--14dae9340443b6b56604b913d19c--


--===============8367570655928493927==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8367570655928493927==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry283-0006l3-Tq; Thu, 16 Feb 2012 14:16:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jordi.Jacobs@howest.be>) id 1Ry1AM-0006ML-W6
	for Xen-devel@lists.xensource.com; Thu, 16 Feb 2012 13:14:31 +0000
X-Env-Sender: Jordi.Jacobs@howest.be
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329398004!61359956!1
X-Originating-IP: [193.191.136.242]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29827 invoked from network); 16 Feb 2012 13:13:25 -0000
Received: from smtp1.howest.be (HELO EDGE1.howest.be) (193.191.136.242)
	by server-2.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Feb 2012 13:13:25 -0000
Received: from MAIL1.hogeschool-wvl.be (172.20.1.43) by EDGE1.howest.be
	(192.168.2.23) with Microsoft SMTP Server (TLS) id 14.2.247.3;
	Thu, 16 Feb 2012 15:52:57 +0100
Received: from MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43]) by
	MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43%12]) with mapi id
	14.02.0247.003; Thu, 16 Feb 2012 14:14:16 +0100
From: Jacobs Jordi <Jordi.Jacobs@howest.be>
To: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	=?Windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] 1 GPU multiple VMs
Thread-Index: AcziEI9YhPf/uaMKQPWlLvKH91C0fwEbQRaAAAFEGQAAAIeaAAAAPT6AAAAhroABORqvAABQLLlA
Date: Thu, 16 Feb 2012 13:14:15 +0000
Message-ID: <8D0A507D03F2B0499D85192120C2158F113ADAE0@MAIL1.hogeschool-wvl.be>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>,
	<90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US, nl-BE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.2.236]
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "Zaborowski, Andrew" <andrew.zaborowski@intel.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://xen.org/products/xci_source.html
XCI (Xen Client Initiative)
XenClient from Citrix is also capable to share a GPU.
However the software doesn't support many GPUs, so that might be a downside.
(I have not yet analysed the repositories.)
________________________________________
From: Lv, Zhiyuan [zhiyuan.lv@intel.com]
Sent: Wednesday, February 15, 2012 12:47 AM
To: Pasi K=E4rkk=E4inen; Stefano Stabellini
Cc: Xen-devel@lists.xensource.com; Jacobs Jordi; Zaborowski, Andrew
Subject: RE: [Xen-devel] 1 GPU multiple VMs

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Pasi K?rkk?in=
en
> Sent: Thursday, February 09, 2012 2:23 AM
> To: Stefano Stabellini
> Cc: Xen-devel@lists.xensource.com; Jacobs Jordi
> Subject: Re: [Xen-devel] 1 GPU multiple VMs
>
> On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am wondering how GPU sharing could/should be implemented for =
the
> Xen Hypervisor.
> > > > > >
> > > > > > I have come across several papers that explain many possibiliti=
es on
> GPU sharing for multiple VMs but I'm not sure wich
> > > > > > one would be the best solution for Xen.
> > > > > >
> > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > Mediated passthrough (Multiplexing the GPU while maintaining the
> different contexts.)
> > > > > >
> > > > > > Can you guys give me your idea on the matter?
> > > > > > Please also mention any existing projects you know that are rel=
ated to
> this problem.
> > > > >
> > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > remoting. Gallium remoting could also be OK but considering that =
many
> > > > > cards don't have Gallium drivers we would probably end up doing t=
wo
> > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > Gallium->OpenGL in dom0).
> > > > > Mediated passthrough is very card specific so I am afraid you wou=
ld end
> > > > > up writing virtualization specific drivers for all the cards you =
want to
> > > > > support. Not to mention that you might need to access some videoc=
ard
> > > > > interfaces that on Nvidia are not discosed.
> > > > >
> > > > > I believe that virtualbox already supports OpenGL remoting in a d=
ecent
> > > > > way, so I would start from there, port what they have to Xen, and
> > > > > improve it.
> > > > >
> > > >
> > > > I wonder if SPICE already supports OpenGL stuff..
> > > > I think it's at least supposed to be able to support OpenGL.
> > > >
> > > >
> (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.ht
> ml)
> > >
> > > Not yet, but I think that they are working on it. Still very early da=
ys
> > > though.
> > > Also it would only work with HVM guests, while having a proper xen
> > > frontend/backend OpenGL remoting driver pair would work for both.
> >
> > Yep.
> >
> > There's also: http://sourceforge.net/projects/vmgl/
> >
> > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware
> acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs;
> X11-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and =
Intel
> GPUs. "
> >
>
> And Chromium might have something related aswell:
> http://chromium.sourceforge.net/doc/index.html
>
Hello,

Another related work is as below:
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01027.html

Similar to VMGL, it is an API remoting approach but not based on chromium. =
Another difference is that it does not require X server extensions. Just fo=
r your reference. Thanks!

>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry283-0006l3-Tq; Thu, 16 Feb 2012 14:16:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jordi.Jacobs@howest.be>) id 1Ry1AM-0006ML-W6
	for Xen-devel@lists.xensource.com; Thu, 16 Feb 2012 13:14:31 +0000
X-Env-Sender: Jordi.Jacobs@howest.be
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329398004!61359956!1
X-Originating-IP: [193.191.136.242]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29827 invoked from network); 16 Feb 2012 13:13:25 -0000
Received: from smtp1.howest.be (HELO EDGE1.howest.be) (193.191.136.242)
	by server-2.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Feb 2012 13:13:25 -0000
Received: from MAIL1.hogeschool-wvl.be (172.20.1.43) by EDGE1.howest.be
	(192.168.2.23) with Microsoft SMTP Server (TLS) id 14.2.247.3;
	Thu, 16 Feb 2012 15:52:57 +0100
Received: from MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43]) by
	MAIL1.hogeschool-wvl.be ([fe80::5efe:172.20.1.43%12]) with mapi id
	14.02.0247.003; Thu, 16 Feb 2012 14:14:16 +0100
From: Jacobs Jordi <Jordi.Jacobs@howest.be>
To: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	=?Windows-1252?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] 1 GPU multiple VMs
Thread-Index: AcziEI9YhPf/uaMKQPWlLvKH91C0fwEbQRaAAAFEGQAAAIeaAAAAPT6AAAAhroABORqvAABQLLlA
Date: Thu, 16 Feb 2012 13:14:15 +0000
Message-ID: <8D0A507D03F2B0499D85192120C2158F113ADAE0@MAIL1.hogeschool-wvl.be>
References: <8D0A507D03F2B0499D85192120C2158F11386D23@MAIL1.hogeschool-wvl.be>
	<alpine.DEB.2.00.1202081713570.3196@kaball-desktop>
	<20120208175646.GY12984@reaktio.net>
	<alpine.DEB.2.00.1202081810100.3196@kaball-desktop>
	<20120208181847.GA12984@reaktio.net>
	<20120208182233.GB12984@reaktio.net>,
	<90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <90B205B787589546A1197E4FC0AE9C1E05DBFA@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US, nl-BE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.2.236]
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "Zaborowski, Andrew" <andrew.zaborowski@intel.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 1 GPU multiple VMs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://xen.org/products/xci_source.html
XCI (Xen Client Initiative)
XenClient from Citrix is also capable to share a GPU.
However the software doesn't support many GPUs, so that might be a downside.
(I have not yet analysed the repositories.)
________________________________________
From: Lv, Zhiyuan [zhiyuan.lv@intel.com]
Sent: Wednesday, February 15, 2012 12:47 AM
To: Pasi K=E4rkk=E4inen; Stefano Stabellini
Cc: Xen-devel@lists.xensource.com; Jacobs Jordi; Zaborowski, Andrew
Subject: RE: [Xen-devel] 1 GPU multiple VMs

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Pasi K?rkk?in=
en
> Sent: Thursday, February 09, 2012 2:23 AM
> To: Stefano Stabellini
> Cc: Xen-devel@lists.xensource.com; Jacobs Jordi
> Subject: Re: [Xen-devel] 1 GPU multiple VMs
>
> On Wed, Feb 08, 2012 at 08:18:47PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Feb 08, 2012 at 06:11:56PM +0000, Stefano Stabellini wrote:
> > > On Wed, 8 Feb 2012, Pasi K=C3=83=C2?rkk=C3=83=C2?inen wrote:
> > > > On Wed, Feb 08, 2012 at 05:20:31PM +0000, Stefano Stabellini wrote:
> > > > > On Fri, 3 Feb 2012, Jacobs Jordi wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am wondering how GPU sharing could/should be implemented for =
the
> Xen Hypervisor.
> > > > > >
> > > > > > I have come across several papers that explain many possibiliti=
es on
> GPU sharing for multiple VMs but I'm not sure wich
> > > > > > one would be the best solution for Xen.
> > > > > >
> > > > > > API remoting (gallium3D) (ex. Xen3D project)
> > > > > > Mediated passthrough (Multiplexing the GPU while maintaining the
> different contexts.)
> > > > > >
> > > > > > Can you guys give me your idea on the matter?
> > > > > > Please also mention any existing projects you know that are rel=
ated to
> this problem.
> > > > >
> > > > > My personal opinion is that the simplest thing to do is OpenGL
> > > > > remoting. Gallium remoting could also be OK but considering that =
many
> > > > > cards don't have Gallium drivers we would probably end up doing t=
wo
> > > > > conversions instead of one (DirectX->Gallium in the guest,
> > > > > Gallium->OpenGL in dom0).
> > > > > Mediated passthrough is very card specific so I am afraid you wou=
ld end
> > > > > up writing virtualization specific drivers for all the cards you =
want to
> > > > > support. Not to mention that you might need to access some videoc=
ard
> > > > > interfaces that on Nvidia are not discosed.
> > > > >
> > > > > I believe that virtualbox already supports OpenGL remoting in a d=
ecent
> > > > > way, so I would start from there, port what they have to Xen, and
> > > > > improve it.
> > > > >
> > > >
> > > > I wonder if SPICE already supports OpenGL stuff..
> > > > I think it's at least supposed to be able to support OpenGL.
> > > >
> > > >
> (http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.ht
> ml)
> > >
> > > Not yet, but I think that they are working on it. Still very early da=
ys
> > > though.
> > > Also it would only work with HVM guests, while having a proper xen
> > > frontend/backend OpenGL remoting driver pair would work for both.
> >
> > Yep.
> >
> > There's also: http://sourceforge.net/projects/vmgl/
> >
> > "OpenGL apps running inside a VM use VMGL to obtain graphics hardware
> acceleration. VMGL supports VMware, Xen PV and HVM, qemu, and KVM VMs;
> X11-based OS such as Linux, FreeBSD and OpenSolaris; and ATI, Nvidia and =
Intel
> GPUs. "
> >
>
> And Chromium might have something related aswell:
> http://chromium.sourceforge.net/doc/index.html
>
Hello,

Another related work is as below:
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01027.html

Similar to VMGL, it is an API remoting approach but not based on chromium. =
Another difference is that it does not require X server extensions. Just fo=
r your reference. Thanks!

>
> -- Pasi
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry282-0006kT-Kk; Thu, 16 Feb 2012 14:16:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxKAh-0003o2-E4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:19:59 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329232661!52690401!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gODg2MTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23519 invoked from network); 14 Feb 2012 15:17:42 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:17:42 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxKAc-00084l-FZ
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:19:54 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Tue, 14 Feb 2012
	15:19:20 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 15:14:59 +0000
Thread-Topic: monitoring domU events in Dom0
Thread-Index: AQHM6ywFCaQaesqwpEq5bfVnSd/8lA==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AF23@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Subject: [Xen-devel] monitoring domU events in Dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,

Consider the following scenario: I have Dom0 and a running DomU.

If I want to monitor the events happening in the DomU while in the Dom0, how can I do it?

I have found the evtchn_pending bit array, but I have no xen development experience.
So, the question is if I can get live access to the events happening in the DomU.
The objective would be to monitor events I want to intercept in order to perform operations on the Dom0.

Any kind of guidance will be welcomed. Thank you for your time,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry282-0006kT-Kk; Thu, 16 Feb 2012 14:16:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxKAh-0003o2-E4
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:19:59 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329232661!52690401!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gODg2MTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23519 invoked from network); 14 Feb 2012 15:17:42 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 15:17:42 -0000
Received: from exhubdb01.ncl.ac.uk ([10.8.239.3]
	helo=exhubdb01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxKAc-00084l-FZ
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 15:19:54 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubdb01.campus.ncl.ac.uk ([10.8.239.3]) with mapi; Tue, 14 Feb 2012
	15:19:20 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 14 Feb 2012 15:14:59 +0000
Thread-Topic: monitoring domU events in Dom0
Thread-Index: AQHM6ywFCaQaesqwpEq5bfVnSd/8lA==
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AF23@EXCCR03.campus.ncl.ac.uk>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Subject: [Xen-devel] monitoring domU events in Dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,

Consider the following scenario: I have Dom0 and a running DomU.

If I want to monitor the events happening in the DomU while in the Dom0, how can I do it?

I have found the evtchn_pending bit array, but I have no xen development experience.
So, the question is if I can get live access to the events happening in the DomU.
The objective would be to monitor events I want to intercept in order to perform operations on the Dom0.

Any kind of guidance will be welcomed. Thank you for your time,
Francisco
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry283-0006kd-2n; Thu, 16 Feb 2012 14:16:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RxL71-0007Ju-J4; Tue, 14 Feb 2012 16:20:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329236408!14779620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20633 invoked from network); 14 Feb 2012 16:20:09 -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;
	14 Feb 2012 16:20:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10691078"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 16:19:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 16:19:55 +0000
Message-ID: <1329236393.31256.267.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 14 Feb 2012 16:19:53 +0000
In-Reply-To: <20120214155738.GC21610@andromeda.dapyr.net>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
	<20120214155738.GC21610@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Mr Qrux, please do not cross post. I have moved xen-devel to BCC since
the bit I'm replying too seems more appropriate to the xen-users list.

On Tue, 2012-02-14 at 15:57 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 13, 2012 at 06:18:07PM -0800, Qrux wrote:
> > Howdy, all.
> > 
> > Is there definitive documentation about accurate timekeeping on Linux PV domUs (Xen-4.1.2, Linux-3.1-pvops)?
> > 
> > Specifically:
> > 
> > 	* Is there a way to keep good time (i.e., bare-metal accuracy) on domU?
> 
> It does that now. It uses the same clock as the hypervisor does so there
> is no "lost ticks" or such.
> 
> > 
> > 	* What's happened to /proc/sys/xen/independent_wallclock?
> 
> No idea. What did that do?

There was a feature of the classic-Xen Linux kernels called dependent
wallclock (it was the default for those kernels). In this mode each call
to gettimeofday would return the time direct from the wallclock time
provided by the hypervisor in the shared info (wc_*). This means that
guest userspace would always get the wallclock time from the hypervisor.
dom0 would keep the hypervisor up to date by running ntp and pushing the
results down and therefore keep all guests in sync automatically.

Setting independent_wallclock would configure a guest to not use the
shared wallclock time but instead to grab the time once from the shared
info at boot and thereafter maintain its own idea of time based on its
timer ticks. This is analogous to how things happen on native (i.e. read
the RTC on boot and then user the ticks to keep in sync).

A pvops kernel has no concept of dependent_wallclock and is effectively
always in independent_wallclock mode. Jeremy made this call IIRC because
it matches how native works which reduces the special casing needed for
VMs.

This does however mean that you need to run NTP in a guest which runs a
pvops kernel.

> > 
> > 	* Does NTP on domU "work"?  Does adjtimex do anything?

For the reasons above running NTP is highly recommended in any domain
running a pvops kernel.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry283-0006kd-2n; Thu, 16 Feb 2012 14:16:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RxL71-0007Ju-J4; Tue, 14 Feb 2012 16:20:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329236408!14779620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20633 invoked from network); 14 Feb 2012 16:20:09 -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;
	14 Feb 2012 16:20:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="10691078"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2012 16:19:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 14 Feb 2012 16:19:55 +0000
Message-ID: <1329236393.31256.267.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 14 Feb 2012 16:19:53 +0000
In-Reply-To: <20120214155738.GC21610@andromeda.dapyr.net>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
	<20120214155738.GC21610@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Mr Qrux, please do not cross post. I have moved xen-devel to BCC since
the bit I'm replying too seems more appropriate to the xen-users list.

On Tue, 2012-02-14 at 15:57 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 13, 2012 at 06:18:07PM -0800, Qrux wrote:
> > Howdy, all.
> > 
> > Is there definitive documentation about accurate timekeeping on Linux PV domUs (Xen-4.1.2, Linux-3.1-pvops)?
> > 
> > Specifically:
> > 
> > 	* Is there a way to keep good time (i.e., bare-metal accuracy) on domU?
> 
> It does that now. It uses the same clock as the hypervisor does so there
> is no "lost ticks" or such.
> 
> > 
> > 	* What's happened to /proc/sys/xen/independent_wallclock?
> 
> No idea. What did that do?

There was a feature of the classic-Xen Linux kernels called dependent
wallclock (it was the default for those kernels). In this mode each call
to gettimeofday would return the time direct from the wallclock time
provided by the hypervisor in the shared info (wc_*). This means that
guest userspace would always get the wallclock time from the hypervisor.
dom0 would keep the hypervisor up to date by running ntp and pushing the
results down and therefore keep all guests in sync automatically.

Setting independent_wallclock would configure a guest to not use the
shared wallclock time but instead to grab the time once from the shared
info at boot and thereafter maintain its own idea of time based on its
timer ticks. This is analogous to how things happen on native (i.e. read
the RTC on boot and then user the ticks to keep in sync).

A pvops kernel has no concept of dependent_wallclock and is effectively
always in independent_wallclock mode. Jeremy made this call IIRC because
it matches how native works which reduces the special casing needed for
VMs.

This does however mean that you need to run NTP in a guest which runs a
pvops kernel.

> > 
> > 	* Does NTP on domU "work"?  Does adjtimex do anything?

For the reasons above running NTP is highly recommended in any domain
running a pvops kernel.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry282-0006kH-73; Thu, 16 Feb 2012 14:16:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxIEX-0003uG-Hj
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:15:49 +0000
Received: from [193.109.254.147:15540] by server-1.bemta-14.messagelabs.com id
	DB/A5-12485-48E5A3F4; Tue, 14 Feb 2012 13:15:48 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329225296!52684385!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gODg2MTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26063 invoked from network); 14 Feb 2012 13:14:56 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:14:56 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxIEV-0000Cp-Fn; Tue, 14 Feb 2012 13:15:47 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Tue, 14 Feb 2012
	13:15:28 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 14 Feb 2012 13:14:16 +0000
Thread-Topic: [Xen-devel] xc_gnttab_get_version question/bug
Thread-Index: AczrF5DX3OpofKvUQpqTpoWgVVRAuwAAvy89
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AF21@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
	,<1328107019.17444.74.camel@zakaz.uk.xensource.com>
	<5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
	<1329223464.31256.234.camel@zakaz.uk.xensource.com>,
	<1329223963.31256.236.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329223963.31256.236.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: 14 February 2012 12:52
To: Francisco Rocha
Cc: xen-devel@lists.xensource.com; Keir (Xen.org)
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug

On Tue, 2012-02-14 at 12:44 +0000, Ian Campbell wrote:
> I've no idea where this might be coming from though.

Turns out I do... The following fixes it for me. Ought to be backported
IMHO.

Ian.

Thank you, it also solves the problem for me.

Francisco


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329223776 0
# Node ID 86ebf7589758da1d026175ac46b3f9bda75f0937
# Parent  43f94d0d384b1c00b5d8fc9a90d6d48165cd854d
xen: add missing unlock from gnttab_get_version

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>

diff -r 43f94d0d384b -r 86ebf7589758 xen/common/grant_table.c
--- a/xen/common/grant_table.c  Tue Feb 14 12:40:13 2012 +0000
+++ b/xen/common/grant_table.c  Tue Feb 14 12:49:36 2012 +0000
@@ -2321,6 +2321,8 @@ gnttab_get_version(XEN_GUEST_HANDLE(gntt
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);

+    rcu_unlock_domain(d);
+
     if ( copy_to_guest(uop, &op, 1) )
         return -EFAULT;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry282-0006kH-73; Thu, 16 Feb 2012 14:16:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxIEX-0003uG-Hj
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 13:15:49 +0000
Received: from [193.109.254.147:15540] by server-1.bemta-14.messagelabs.com id
	DB/A5-12485-48E5A3F4; Tue, 14 Feb 2012 13:15:48 +0000
X-Env-Sender: f.e.liberal-rocha@newcastle.ac.uk
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329225296!52684385!1
X-Originating-IP: [128.240.234.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI4LjI0MC4yMzQuMjIgPT4gODg2MTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26063 invoked from network); 14 Feb 2012 13:14:56 -0000
Received: from cheviot22.ncl.ac.uk (HELO cheviot22.ncl.ac.uk) (128.240.234.22)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 13:14:56 -0000
Received: from exhubct01.ncl.ac.uk ([10.8.239.5]
	helo=exhubct01.campus.ncl.ac.uk)
	by cheviot22.ncl.ac.uk with esmtp (Exim 4.63)
	(envelope-from <f.e.liberal-rocha@newcastle.ac.uk>)
	id 1RxIEV-0000Cp-Fn; Tue, 14 Feb 2012 13:15:47 +0000
Received: from EXCCR03.campus.ncl.ac.uk
	([fe80:0000:0000:0000:2916:a33e:133.54.144.227]) by
	exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Tue, 14 Feb 2012
	13:15:28 +0000
From: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 14 Feb 2012 13:14:16 +0000
Thread-Topic: [Xen-devel] xc_gnttab_get_version question/bug
Thread-Index: AczrF5DX3OpofKvUQpqTpoWgVVRAuwAAvy89
Message-ID: <5E615268CEC26C4E920B9D9911A2307C03412170AF21@EXCCR03.campus.ncl.ac.uk>
References: <5E615268CEC26C4E920B9D9911A2307C03412170AEFF@EXCCR03.campus.ncl.ac.uk>
	,<1328107019.17444.74.camel@zakaz.uk.xensource.com>
	<5E615268CEC26C4E920B9D9911A2307C03412170AF1E@EXCCR03.campus.ncl.ac.uk>
	<1329223464.31256.234.camel@zakaz.uk.xensource.com>,
	<1329223963.31256.236.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329223963.31256.236.camel@zakaz.uk.xensource.com>
Accept-Language: en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-GB
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: 14 February 2012 12:52
To: Francisco Rocha
Cc: xen-devel@lists.xensource.com; Keir (Xen.org)
Subject: Re: [Xen-devel] xc_gnttab_get_version question/bug

On Tue, 2012-02-14 at 12:44 +0000, Ian Campbell wrote:
> I've no idea where this might be coming from though.

Turns out I do... The following fixes it for me. Ought to be backported
IMHO.

Ian.

Thank you, it also solves the problem for me.

Francisco


# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329223776 0
# Node ID 86ebf7589758da1d026175ac46b3f9bda75f0937
# Parent  43f94d0d384b1c00b5d8fc9a90d6d48165cd854d
xen: add missing unlock from gnttab_get_version

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>

diff -r 43f94d0d384b -r 86ebf7589758 xen/common/grant_table.c
--- a/xen/common/grant_table.c  Tue Feb 14 12:40:13 2012 +0000
+++ b/xen/common/grant_table.c  Tue Feb 14 12:49:36 2012 +0000
@@ -2321,6 +2321,8 @@ gnttab_get_version(XEN_GUEST_HANDLE(gntt
     op.version = d->grant_table->gt_version;
     spin_unlock(&d->grant_table->lock);

+    rcu_unlock_domain(d);
+
     if ( copy_to_guest(uop, &op, 1) )
         return -EFAULT;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry281-0006k0-D1; Thu, 16 Feb 2012 14:16:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RxG0T-00063u-7B
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:53:09 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329216781!15274349!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MTAyNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14481 invoked from network); 14 Feb 2012 10:53:03 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 10:53:03 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RxG0H-00025s-9D from Paul_Brook@mentor.com ;
	Tue, 14 Feb 2012 02:52:57 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2012 10:52:56 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 817CA6EE61;
	Tue, 14 Feb 2012 10:52:55 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 10:52:53 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202102334.40125.paul@codesourcery.com>
	<alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201202141052.55100.paul@codesourcery.com>
X-OriginalArrivalTime: 14 Feb 2012 10:52:56.0239 (UTC)
	FILETIME=[CF042BF0:01CCEB06]
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Yes, you are right. Also considering that we are only calling
> slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
> the !CONFIG_SLIRP dummy version of the function.

Looks reasonable to me.  Unfortunately I can't remember which combination of 
headless VM and timer configs caused hangs when this was originally added.

If anyone has a setup that suffered timeout-related hangs last time we made 
this change, please retest with this patch.  Otherwise I guess we apply the 
patch and hope we didn't miss anything.

> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Mon Feb 13 11:25:03 2012 +0000
> 
>     main_loop_wait: block indefinitely
>     
>     - remove qemu_calculate_timeout;
>     
>     - explicitly size timeout to uint32_t;
>     
>     - introduce slirp_update_timeout;
>     
>     - pass NULL as timeout argument to select in case timeout is the
>     maximum value;
>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Paul Brook <paul@codesourcery.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry281-0006k0-D1; Thu, 16 Feb 2012 14:16:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul_Brook@mentor.com>) id 1RxG0T-00063u-7B
	for xen-devel@lists.xensource.com; Tue, 14 Feb 2012 10:53:09 +0000
X-Env-Sender: Paul_Brook@mentor.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329216781!15274349!1
X-Originating-IP: [192.94.38.131]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjk0LjM4LjEzMSA9PiA2MTAyNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14481 invoked from network); 14 Feb 2012 10:53:03 -0000
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2012 10:53:03 -0000
Received: from nat-ies.mentorg.com ([192.94.31.2]
	helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp 
	id 1RxG0H-00025s-9D from Paul_Brook@mentor.com ;
	Tue, 14 Feb 2012 02:52:57 -0800
Received: from nowt.org ([172.30.64.210]) by EU1-MAIL.mgc.mentorg.com with
	Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2012 10:52:56 +0000
Received: from wren.localnet (wren.home [192.168.93.7])
	by nowt.org (Postfix) with ESMTP id 817CA6EE61;
	Tue, 14 Feb 2012 10:52:55 +0000 (GMT)
From: Paul Brook <paul@codesourcery.com>
Organization: Mentor Graphics
To: qemu-devel@nongnu.org
Date: Tue, 14 Feb 2012 10:52:53 +0000
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<201202102334.40125.paul@codesourcery.com>
	<alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202131150360.7456@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201202141052.55100.paul@codesourcery.com>
X-OriginalArrivalTime: 14 Feb 2012 10:52:56.0239 (UTC)
	FILETIME=[CF042BF0:01CCEB06]
X-Mailman-Approved-At: Thu, 16 Feb 2012 14:16:08 +0000
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"avi@redhat.com" <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v3 6/6] qemu_calculate_timeout:
	increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Yes, you are right. Also considering that we are only calling
> slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
> the !CONFIG_SLIRP dummy version of the function.

Looks reasonable to me.  Unfortunately I can't remember which combination of 
headless VM and timer configs caused hangs when this was originally added.

If anyone has a setup that suffered timeout-related hangs last time we made 
this change, please retest with this patch.  Otherwise I guess we apply the 
patch and hope we didn't miss anything.

> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Mon Feb 13 11:25:03 2012 +0000
> 
>     main_loop_wait: block indefinitely
>     
>     - remove qemu_calculate_timeout;
>     
>     - explicitly size timeout to uint32_t;
>     
>     - introduce slirp_update_timeout;
>     
>     - pass NULL as timeout argument to select in case timeout is the
>     maximum value;
>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Paul Brook <paul@codesourcery.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:17:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry298-0007F0-K7; Thu, 16 Feb 2012 14:17:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ry297-0007Ck-5X
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:17:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329401830!13643637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17772 invoked from network); 16 Feb 2012 14:17:11 -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;
	16 Feb 2012 14:17:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,429,1325462400"; d="scan'208";a="10746984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 14:17:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 14:17:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ry290-0003CX-DA;
	Thu, 16 Feb 2012 14:17:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ry290-00046N-Br;
	Thu, 16 Feb 2012 14:17:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11973-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 16 Feb 2012 14:17:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11973: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11973 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11973/

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. 11967
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 11967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-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-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  01c1bcbc6222
baseline version:
 xen                  fe427d3bb378

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.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>
------------------------------------------------------------

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:   24819:01c1bcbc6222
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Feb 16 08:48:23 2012 +0100
    
    replace bogus gdprintk() uses with {,d}printk()
    
    When the subject domain is not the current one (e.g. during domctl or
    HVM save/restore handling), use of gdprintk() is questionable at best,
    as it won't give the intended information on what domain is affected.
    Use plain printk() or dprintk() instead, but keep things (mostly) as
    guest messages by using XENLOG_G_*.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24818:fe427d3bb378
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Feb 15 12:24:21 2012 +0000
    
    arm: Group remaining dummy symbols somewhat according to functionality
    
    Makes it easier to see what needs to be done.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 414b878e8ea17c65cd0d7f9dfc38dba472857f74
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Mon Feb 13 17:00:13 2012 +0000

    qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
    
    A recent changeset introduced a bug whereby an initialization function
    that reads /proc/bus/pci is called from graphics set-up functions even
    if pass-through graphics are not enabled.  If qemu is run without
    permission to this file, this causes qemu to fail during
    initialization.
    
    This patch re-works the functions so that the initialization happens
    only if we actually need to do the pci host read or write.  It also
    makes failures call abort().
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:17:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry298-0007F0-K7; Thu, 16 Feb 2012 14:17:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ry297-0007Ck-5X
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:17:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329401830!13643637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17772 invoked from network); 16 Feb 2012 14:17:11 -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;
	16 Feb 2012 14:17:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,429,1325462400"; d="scan'208";a="10746984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 14:17:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 14:17:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ry290-0003CX-DA;
	Thu, 16 Feb 2012 14:17:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ry290-00046N-Br;
	Thu, 16 Feb 2012 14:17:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11973-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 16 Feb 2012 14:17:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11973: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11973 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11973/

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. 11967
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 11967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemuu-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-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  01c1bcbc6222
baseline version:
 xen                  fe427d3bb378

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.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>
------------------------------------------------------------

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:   24819:01c1bcbc6222
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Feb 16 08:48:23 2012 +0100
    
    replace bogus gdprintk() uses with {,d}printk()
    
    When the subject domain is not the current one (e.g. during domctl or
    HVM save/restore handling), use of gdprintk() is questionable at best,
    as it won't give the intended information on what domain is affected.
    Use plain printk() or dprintk() instead, but keep things (mostly) as
    guest messages by using XENLOG_G_*.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24818:fe427d3bb378
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Feb 15 12:24:21 2012 +0000
    
    arm: Group remaining dummy symbols somewhat according to functionality
    
    Makes it easier to see what needs to be done.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 414b878e8ea17c65cd0d7f9dfc38dba472857f74
Author: George Dunlap <george.dunlap@eu.citrix.com>
Date:   Mon Feb 13 17:00:13 2012 +0000

    qemu: Don't access /proc/bus/pci unless graphics pass-thru is enabled
    
    A recent changeset introduced a bug whereby an initialization function
    that reads /proc/bus/pci is called from graphics set-up functions even
    if pass-through graphics are not enabled.  If qemu is run without
    permission to this file, this causes qemu to fail during
    initialization.
    
    This patch re-works the functions so that the initialization happens
    only if we actually need to do the pci host read or write.  It also
    makes failures call abort().
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:23:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2FJ-0000Cx-Fg; Thu, 16 Feb 2012 14:23:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Ry2FH-0000CZ-UX
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:23:40 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329402213!13665482!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22475 invoked from network); 16 Feb 2012 14:23:33 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-9.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Feb 2012 14:23:33 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1607820Ab2BPOX2 (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 16 Feb 2012 15:23:28 +0100
Date: Thu, 16 Feb 2012 15:23:28 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120216142328.GA15987@router-fw-old.local.net-space.pl>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
	<4F3CD3F002000078000735F0@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3CD3F002000078000735F0@nat28.tlf.novell.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com, Eric Camachat <eric.camachat@gmail.com>,
	Daniel Kiper <dkiper@net-space.pl>, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 09:01:20AM +0000, Jan Beulich wrote:
> >>> On 16.02.12 at 08:29, Philipp Hahn <hahn@univention.de> wrote:
> > Hello,
> >
> > Am Donnerstag 16 Februar 2012 02:22:30 schrieben Sie:
> >> On Tue, Feb 14, 2012 at 10:07 AM, Eric Camachat <eric.camachat@gmail.com>
> > wrote:
> >> > On Tue, Feb 14, 2012 at 12:07 AM, Philipp Hahn <hahn@univention.de> wrote:
> >> Try to use HYPERVISOR_kexec_op() to find out where crash buffer is.
> >> But it returned address that outside of total memory!
> >
> > Yes, because the Hyervisor (which is running below your dom0 Linux kernel)
> > reserves the memory, so not even the dom0 kernel should be able to scribble
> > it. That's why you have to use the HYPERVIROS_OPs.
> >
> > I've spend some time investigating this a month ago but finally did gave up.
> >
> > Here're some of my notes:
> > - it should be possible to write a user-space tool (like kexec), which uses
> > HYPERVISOR_kexec_op() to load a crash-dump kernel.
> > - you would need to copy some code from the linux-kernel to fill in some
> > data
> > structures.
> > - the Linux kernel prepends the crash kernel with some assembly code, which
> > moves it to the final location on execution. This trampolin code would
> > possibly be  needed in your tool as well.
> >
> > The other option I see would be to modify the current Linux kernel to use
> > HYPERVISOR_kexec_op() when used as a dom0 kernel.
>
> You may want to get in touch with Daniel, who iirc started looking at
> adding kexec support to the pv-ops kernel some time last year.

... and I still work on it. To be precise I have working kexec for
domU PV guest running very ancient Linux Kernel Ver. 2.6.18 (it is
not based on current 2.6.18 tree). I am starting work on kdump for domU.
Work on kexec/kdump for dom0 is postponed until I finnish work on
kexec/kdump for domU. After that I would like to prepare relevant patches
for Xen, mainline Linux Kernel and kexec-tools and publish them as a complete
solution for dom0 and domU (I am going to do that on March or April,
however, ... You know...). I am not going to prepare support/backport for
Linux Kernel Ver. 2.6.32 (or even 2.6.18), however, if it be required
by quite large number of users I will think about that.

Regarding kexec/kdump documentation please look into my presentation
prepared for Xen Summit 2011 (http://xen.org/files/xensummit_santaclara11/aug3/7_DanielK_Kexec_KDump.pdf).
I do not mention documentation which you could find in Linux Kernel source
code. However, if you need some more explanation drop me a line.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:23:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2FJ-0000Cx-Fg; Thu, 16 Feb 2012 14:23:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Ry2FH-0000CZ-UX
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:23:40 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329402213!13665482!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22475 invoked from network); 16 Feb 2012 14:23:33 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-9.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Feb 2012 14:23:33 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1607820Ab2BPOX2 (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 16 Feb 2012 15:23:28 +0100
Date: Thu, 16 Feb 2012 15:23:28 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120216142328.GA15987@router-fw-old.local.net-space.pl>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
	<4F3CD3F002000078000735F0@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3CD3F002000078000735F0@nat28.tlf.novell.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com, Eric Camachat <eric.camachat@gmail.com>,
	Daniel Kiper <dkiper@net-space.pl>, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 09:01:20AM +0000, Jan Beulich wrote:
> >>> On 16.02.12 at 08:29, Philipp Hahn <hahn@univention.de> wrote:
> > Hello,
> >
> > Am Donnerstag 16 Februar 2012 02:22:30 schrieben Sie:
> >> On Tue, Feb 14, 2012 at 10:07 AM, Eric Camachat <eric.camachat@gmail.com>
> > wrote:
> >> > On Tue, Feb 14, 2012 at 12:07 AM, Philipp Hahn <hahn@univention.de> wrote:
> >> Try to use HYPERVISOR_kexec_op() to find out where crash buffer is.
> >> But it returned address that outside of total memory!
> >
> > Yes, because the Hyervisor (which is running below your dom0 Linux kernel)
> > reserves the memory, so not even the dom0 kernel should be able to scribble
> > it. That's why you have to use the HYPERVIROS_OPs.
> >
> > I've spend some time investigating this a month ago but finally did gave up.
> >
> > Here're some of my notes:
> > - it should be possible to write a user-space tool (like kexec), which uses
> > HYPERVISOR_kexec_op() to load a crash-dump kernel.
> > - you would need to copy some code from the linux-kernel to fill in some
> > data
> > structures.
> > - the Linux kernel prepends the crash kernel with some assembly code, which
> > moves it to the final location on execution. This trampolin code would
> > possibly be  needed in your tool as well.
> >
> > The other option I see would be to modify the current Linux kernel to use
> > HYPERVISOR_kexec_op() when used as a dom0 kernel.
>
> You may want to get in touch with Daniel, who iirc started looking at
> adding kexec support to the pv-ops kernel some time last year.

... and I still work on it. To be precise I have working kexec for
domU PV guest running very ancient Linux Kernel Ver. 2.6.18 (it is
not based on current 2.6.18 tree). I am starting work on kdump for domU.
Work on kexec/kdump for dom0 is postponed until I finnish work on
kexec/kdump for domU. After that I would like to prepare relevant patches
for Xen, mainline Linux Kernel and kexec-tools and publish them as a complete
solution for dom0 and domU (I am going to do that on March or April,
however, ... You know...). I am not going to prepare support/backport for
Linux Kernel Ver. 2.6.32 (or even 2.6.18), however, if it be required
by quite large number of users I will think about that.

Regarding kexec/kdump documentation please look into my presentation
prepared for Xen Summit 2011 (http://xen.org/files/xensummit_santaclara11/aug3/7_DanielK_Kexec_KDump.pdf).
I do not mention documentation which you could find in Linux Kernel source
code. However, if you need some more explanation drop me a line.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:36:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2RY-0000hQ-4K; Thu, 16 Feb 2012 14:36:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry2RW-0000hL-GF
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:36:18 +0000
Received: from [85.158.139.83:7668] by server-3.bemta-5.messagelabs.com id
	D6/F0-06438-1641D3F4; Thu, 16 Feb 2012 14:36:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329402973!15355384!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY5Mjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10528 invoked from network); 16 Feb 2012 14:36:14 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 14:36:14 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id AFB745EC086;
	Thu, 16 Feb 2012 06:36:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=jK1UYddNCm9d/lbV1DwCnF7S0qP4ua5Y3+tKJNdxYH0d
	jtAOpUgPMa3eockPxlL5y2/czyzSYg65FfS6y8RUUP6mn/XjPeTjxfq1gfeX/VMb
	guojBOn0sW0Ssov/S5g4xRK7Do5lrPM28smcsyZ8cKz6xWHHYERK4YNk/OlcIN8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=O+cchdBweLFb2pDLHM85NnSdpSc=; b=QpZRo27W
	iDlazp0sn58YmNQchz5YdzLe4dHrkZAHG1eX1V8FfeIc+PY4vE4gZ/HyYktncjSV
	LxwDILwZoTO2pLFZuJts7l9gsKGmSLkG1Ad6Sgmk1Cmpx9O6HNc/cqOCnROQHO0p
	lO3ve0Dg5QzTMtJlgMZAC/gBliYtwyBx/74=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 49F375EC080; 
	Thu, 16 Feb 2012 06:36:12 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 06:36:12 -0800
Message-ID: <da398f710afd1f95545ecb9479933d7d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3CD7C0.1010309@amd.com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<4F3CD7C0.1010309@amd.com>
Date: Thu, 16 Feb 2012 06:36:12 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Wei Wang" <wei.wang2@amd.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/15/2012 05:06 PM, Andres Lagar-Cavilla wrote:
>>> On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>>>>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>>>>> We started hashing out some AMD support for mem_paging and
>>>>>> mem_access.
>>>>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>>>>> fault.
>>>>>>
>>>>>> Most importantly, I want to get somebody from AMD to comment/help
>>>>>> out
>>>>>> on
>>>>>> this. It feels like we're inches away from enabling support for this
>>>>>> very
>>>>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>>>>> these
>>>>>> kinds of things. It'd be great to have you on board!
>>>>>>
>>>>>> For starters, the changes to the p2m code are relatively mild, but
>>>>>> it'd
>>>>>> be
>>>>>> great if somebody spots a red flag.
>>>>>>
>>>>>> Another issue: comments indicate that bits 59-62 in NPT entries are
>>>>>> used
>>>>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>>>>> (59)
>>>>>> would give us enough space to support mem_access. Right now we only
>>>>>> have
>>>>>> 7
>>>>>> bits available for Xen flags and that is not enough for paging and
>>>>>> access.
>>>>>> Is bit 59 effectively reserved?
>>>>>
>>>>> Hi
>>>>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>>>>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types
>>>>> that
>>>>> are not potentially used by DMA, this bit could be non-zero. I could
>>>>> tested it on my iommu machines if you had some patches that use U
>>>>> bits.
>>>>
>>>> Hi Wei, thanks for pitching in! I assume you're talking about table 14
>>>> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf
>>>
>>> Yes, indeed.
>>>
>>>> I don't think this will work. The p2m access value is arbitrary, and
>>>> independent of the p2m type. So bit 59 is out of reach and we're stuck
>>>> with 7 bits for Xen use. Thanks for the clarification.
>>>
>>> Where will p2m access bit be stored? Please note that bit 52 - bit 58
>>> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>>> and bit 1 - bit 8 are free to use if PR bit = 1.
>>
>> Wei,
>>
>> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
>> current convention?
>>
>> I propose limiting p2m type to bits 52-55, and storing p2m access on
>> bits
>> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
>> be zero" requirement/convention.
>>
>> Right now, without any considerations for paging, we're storing the p2m
>> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
>> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
>> course. Given your statement above, and table 14 in the IOMMU manual,
>> how
>> is this even working? Or is it not working?
>
> It works because only p2m_ram_rw (which is 0) pages suppose to be used
> by DMA. But, indeed, if iommu tries to access pages with non-zero types,
> like p2m_ram_ro,,it will have io page faults. It seems that we don't
> have use cases like this.
>
I guess no one unleashed log dirty on a domain doing DMA. Rightly so.

> If mem access bits are independent to p2m types, I think we might have a
> few solutions here:
> 1) reverse iommu pt sharing for amd iommu totally.
> 2) disable iommu pt sharing when xen paging enabled.
>
> I am open for both of them.

Great. When I get back to this, I'll look into making the two feature sets
mutually exclusive. And then we can enjoy full mem_access on AMD
platforms.

Thanks,
Andres
>
> Thanks,
>
> Wei
>
>
>> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>>
>> Thanks a lot for the info!
>> Andres
>>>
>>> Thanks,
>>> Wei
>>>
>>>> An alternative to enabling mem_access on AMD processors will be to
>>>> limit
>>>> the access types to 3 bits. This would force disabling support for two
>>>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>>>> they
>>>> make sense without R permissions.
>>>> Thanks!
>>>> Andres
>>>>
>>>>>
>>>>> Thanks,
>>>>> Wei
>>>>>
>>>>>>
>>>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>>>> Comments
>>>>>> welcome.
>>>>>>
>>>>>> Patch inline below, thanks!
>>>>>> Andres
>>>>>>
>>>>>> Enable AMD support for paging.
>>>>>>
>>>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>>>
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>>>                 if ( !hap_enabled(d) )
>>>>>>                     break;
>>>>>>
>>>>>> -            /* Currently only EPT is supported */
>>>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>>>> -                break;
>>>>>> -
>>>>>>                 rc = -EXDEV;
>>>>>>                 /* Disallow paging in a PoD guest */
>>>>>>                 if ( p2m->pod.entry_count )
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>>>> @@ -53,6 +53,20 @@
>>>>>>     #define P2M_BASE_FLAGS \
>>>>>>             (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY |
>>>>>> _PAGE_ACCESSED)
>>>>>>
>>>>>> +#ifdef __x86_64__
>>>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>>>> 0xff..ff
>>>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>>>> p2mt,
>>>>>> + * etc.) This happens for paging entries. Thus we do this
>>>>>> clip/unclip
>>>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>>>> +#define clipped_mfn(mfn)    ((mfn)&    ((1UL<<    EFF_MFN_WIDTH) -
>>>>>> 1))
>>>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ?
>>>>>> \
>>>>>> +                                INVALID_MFN : (mfn))
>>>>>> +#else
>>>>>> +#define clipped_mfn(mfn)    (mfn)
>>>>>> +#define unclip_mfn(mfn)     (mfn)
>>>>>> +#endif /* __x86_64__ */
>>>>>> +
>>>>>>     static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>>>     {
>>>>>>         unsigned long flags;
>>>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>>>         case p2m_invalid:
>>>>>>         case p2m_mmio_dm:
>>>>>>         case p2m_populate_on_demand:
>>>>>> +    case p2m_ram_paging_out:
>>>>>> +    case p2m_ram_paged:
>>>>>> +    case p2m_ram_paging_in:
>>>>>>         default:
>>>>>>             return flags;
>>>>>>         case p2m_ram_ro:
>>>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>>>                                           shift, max)) )
>>>>>>             return 0;
>>>>>>
>>>>>> -    /* PoD: Not present doesn't imply empty. */
>>>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>>>         if ( !l1e_get_flags(*p2m_entry) )
>>>>>>         {
>>>>>>             struct page_info *pg;
>>>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>                                        0, L1_PAGETABLE_ENTRIES);
>>>>>>             ASSERT(p2m_entry);
>>>>>>
>>>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in)
>>>>>> )
>>>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>>>                                              p2m_type_to_flags(p2mt,
>>>>>> mfn));
>>>>>>             else
>>>>>>                 entry_content = l1e_empty();
>>>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>             if ( entry_content.l1 != 0 )
>>>>>>             {
>>>>>>                 p2m_add_iommu_flags(&entry_content, 0,
>>>>>> iommu_pte_flags);
>>>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>>>             }
>>>>>>             /* level 1 entry */
>>>>>>             p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>>>> entry_content, 1);
>>>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>>>                                sizeof(l1e));
>>>>>>
>>>>>>         if ( ret == 0 ) {
>>>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>>>             p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN ||
>>>>>> !p2m_is_ram(p2mt));
>>>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>>>> +                (l1e_mfn == INVALID_MFN&&    p2m_is_paging(p2mt))
>>>>>> );
>>>>>>
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>>>> -             == p2m_populate_on_demand )
>>>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 /* The read has succeeded, so we know that the
>>>>>> mapping
>>>>>>                  * exits at this point.  */
>>>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>>>             }
>>>>>>
>>>>>>             if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>>>> +            mfn = _mfn(l1e_mfn);
>>>>>>             else
>>>>>>                 /* XXX see above */
>>>>>>                 p2mt = p2m_mmio_dm;
>>>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>>>     pod_retry_l1:
>>>>>>         if ( (l1e_get_flags(*l1e)&    _PAGE_PRESENT) == 0 )
>>>>>>         {
>>>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>>             /* PoD: Try to populate */
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>>>> p2m_populate_on_demand )
>>>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 if ( q != p2m_query ) {
>>>>>>                     if ( !p2m_pod_demand_populate(p2m, gfn,
>>>>>> PAGE_ORDER_4K,
>>>>>> q) )
>>>>>>                         goto pod_retry_l1;
>>>>>>                 } else
>>>>>>                     *t = p2m_populate_on_demand;
>>>>>> +        } else {
>>>>>> +            if ( p2m_is_paging(l1t) )
>>>>>> +            {
>>>>>> +                *t = l1t;
>>>>>> +                /* No need to unclip due to check below */
>>>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>> +            }
>>>>>>             }
>>>>>>
>>>>>>             unmap_domain_page(l1e);
>>>>>> -        return _mfn(INVALID_MFN);
>>>>>> +        return (l1t == p2m_ram_paging_out) ? mfn :
>>>>>> _mfn(INVALID_MFN);
>>>>>>         }
>>>>>>         mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>>         *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>>>                         flags = l1e_get_flags(l1e[i1]);
>>>>>>                         if ( p2m_flags_to_type(flags) != ot )
>>>>>>                             continue;
>>>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                         gfn = i1 + (i2 + (i3
>>>>>>     #if CONFIG_PAGING_LEVELS>= 4
>>>>>>     					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>>>                                * L2_PAGETABLE_ENTRIES) *
>>>>>> L1_PAGETABLE_ENTRIES;
>>>>>>                         /* create a new 1le entry with the new type
>>>>>> */
>>>>>>                         flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>>>> flags);
>>>>>>                         p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>>>                                              l1mfn, l1e_content, 1);
>>>>>>                     }
>>>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>>>                                     entry_count++;
>>>>>>                                 continue;
>>>>>>                             }
>>>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                             ASSERT(mfn_valid(_mfn(mfn)));
>>>>>>                             m2pfn = get_gpfn_from_mfn(mfn);
>>>>>>                             if ( m2pfn != gfn&&
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:36:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2RY-0000hQ-4K; Thu, 16 Feb 2012 14:36:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry2RW-0000hL-GF
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:36:18 +0000
Received: from [85.158.139.83:7668] by server-3.bemta-5.messagelabs.com id
	D6/F0-06438-1641D3F4; Thu, 16 Feb 2012 14:36:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329402973!15355384!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY5Mjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10528 invoked from network); 16 Feb 2012 14:36:14 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-182.messagelabs.com with SMTP;
	16 Feb 2012 14:36:14 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id AFB745EC086;
	Thu, 16 Feb 2012 06:36:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=jK1UYddNCm9d/lbV1DwCnF7S0qP4ua5Y3+tKJNdxYH0d
	jtAOpUgPMa3eockPxlL5y2/czyzSYg65FfS6y8RUUP6mn/XjPeTjxfq1gfeX/VMb
	guojBOn0sW0Ssov/S5g4xRK7Do5lrPM28smcsyZ8cKz6xWHHYERK4YNk/OlcIN8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=O+cchdBweLFb2pDLHM85NnSdpSc=; b=QpZRo27W
	iDlazp0sn58YmNQchz5YdzLe4dHrkZAHG1eX1V8FfeIc+PY4vE4gZ/HyYktncjSV
	LxwDILwZoTO2pLFZuJts7l9gsKGmSLkG1Ad6Sgmk1Cmpx9O6HNc/cqOCnROQHO0p
	lO3ve0Dg5QzTMtJlgMZAC/gBliYtwyBx/74=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 49F375EC080; 
	Thu, 16 Feb 2012 06:36:12 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 06:36:12 -0800
Message-ID: <da398f710afd1f95545ecb9479933d7d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3CD7C0.1010309@amd.com>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<4F3CD7C0.1010309@amd.com>
Date: Thu, 16 Feb 2012 06:36:12 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Wei Wang" <wei.wang2@amd.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On 02/15/2012 05:06 PM, Andres Lagar-Cavilla wrote:
>>> On 02/15/2012 04:14 PM, Andres Lagar-Cavilla wrote:
>>>>> On 02/14/2012 08:05 PM, Andres Lagar-Cavilla wrote:
>>>>>> We started hashing out some AMD support for mem_paging and
>>>>>> mem_access.
>>>>>> Right now my VMs boot, page out a bit, and then die on an HVM triple
>>>>>> fault.
>>>>>>
>>>>>> Most importantly, I want to get somebody from AMD to comment/help
>>>>>> out
>>>>>> on
>>>>>> this. It feels like we're inches away from enabling support for this
>>>>>> very
>>>>>> nice feature. I'm not sure who exactly on AMD monitors the list for
>>>>>> these
>>>>>> kinds of things. It'd be great to have you on board!
>>>>>>
>>>>>> For starters, the changes to the p2m code are relatively mild, but
>>>>>> it'd
>>>>>> be
>>>>>> great if somebody spots a red flag.
>>>>>>
>>>>>> Another issue: comments indicate that bits 59-62 in NPT entries are
>>>>>> used
>>>>>> for IOMMU flags but effectively bits 61-62 are. Repossessing one bit
>>>>>> (59)
>>>>>> would give us enough space to support mem_access. Right now we only
>>>>>> have
>>>>>> 7
>>>>>> bits available for Xen flags and that is not enough for paging and
>>>>>> access.
>>>>>> Is bit 59 effectively reserved?
>>>>>
>>>>> Hi
>>>>> bit 59 is used by iommu hardware for ATS response. In most cases, for
>>>>> p2m_ram_rw pages, U bit must be 0. But maybe for other page types
>>>>> that
>>>>> are not potentially used by DMA, this bit could be non-zero. I could
>>>>> tested it on my iommu machines if you had some patches that use U
>>>>> bits.
>>>>
>>>> Hi Wei, thanks for pitching in! I assume you're talking about table 14
>>>> (and fig 9) in http://support.amd.com/us/Processor_TechDocs/48882.pdf
>>>
>>> Yes, indeed.
>>>
>>>> I don't think this will work. The p2m access value is arbitrary, and
>>>> independent of the p2m type. So bit 59 is out of reach and we're stuck
>>>> with 7 bits for Xen use. Thanks for the clarification.
>>>
>>> Where will p2m access bit be stored? Please note that bit 52 - bit 58
>>> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>>> and bit 1 - bit 8 are free to use if PR bit = 1.
>>
>> Wei,
>>
>> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
>> current convention?
>>
>> I propose limiting p2m type to bits 52-55, and storing p2m access on
>> bits
>> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
>> be zero" requirement/convention.
>>
>> Right now, without any considerations for paging, we're storing the p2m
>> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
>> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
>> course. Given your statement above, and table 14 in the IOMMU manual,
>> how
>> is this even working? Or is it not working?
>
> It works because only p2m_ram_rw (which is 0) pages suppose to be used
> by DMA. But, indeed, if iommu tries to access pages with non-zero types,
> like p2m_ram_ro,,it will have io page faults. It seems that we don't
> have use cases like this.
>
I guess no one unleashed log dirty on a domain doing DMA. Rightly so.

> If mem access bits are independent to p2m types, I think we might have a
> few solutions here:
> 1) reverse iommu pt sharing for amd iommu totally.
> 2) disable iommu pt sharing when xen paging enabled.
>
> I am open for both of them.

Great. When I get back to this, I'll look into making the two feature sets
mutually exclusive. And then we can enjoy full mem_access on AMD
platforms.

Thanks,
Andres
>
> Thanks,
>
> Wei
>
>
>> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>>
>> Thanks a lot for the info!
>> Andres
>>>
>>> Thanks,
>>> Wei
>>>
>>>> An alternative to enabling mem_access on AMD processors will be to
>>>> limit
>>>> the access types to 3 bits. This would force disabling support for two
>>>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>>>> they
>>>> make sense without R permissions.
>>>> Thanks!
>>>> Andres
>>>>
>>>>>
>>>>> Thanks,
>>>>> Wei
>>>>>
>>>>>>
>>>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>>>> Comments
>>>>>> welcome.
>>>>>>
>>>>>> Patch inline below, thanks!
>>>>>> Andres
>>>>>>
>>>>>> Enable AMD support for paging.
>>>>>>
>>>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>>>
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>>>                 if ( !hap_enabled(d) )
>>>>>>                     break;
>>>>>>
>>>>>> -            /* Currently only EPT is supported */
>>>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>>>> -                break;
>>>>>> -
>>>>>>                 rc = -EXDEV;
>>>>>>                 /* Disallow paging in a PoD guest */
>>>>>>                 if ( p2m->pod.entry_count )
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>>>> @@ -53,6 +53,20 @@
>>>>>>     #define P2M_BASE_FLAGS \
>>>>>>             (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY |
>>>>>> _PAGE_ACCESSED)
>>>>>>
>>>>>> +#ifdef __x86_64__
>>>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>>>> 0xff..ff
>>>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>>>> p2mt,
>>>>>> + * etc.) This happens for paging entries. Thus we do this
>>>>>> clip/unclip
>>>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>>>> +#define clipped_mfn(mfn)    ((mfn)&    ((1UL<<    EFF_MFN_WIDTH) -
>>>>>> 1))
>>>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ?
>>>>>> \
>>>>>> +                                INVALID_MFN : (mfn))
>>>>>> +#else
>>>>>> +#define clipped_mfn(mfn)    (mfn)
>>>>>> +#define unclip_mfn(mfn)     (mfn)
>>>>>> +#endif /* __x86_64__ */
>>>>>> +
>>>>>>     static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>>>     {
>>>>>>         unsigned long flags;
>>>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>>>         case p2m_invalid:
>>>>>>         case p2m_mmio_dm:
>>>>>>         case p2m_populate_on_demand:
>>>>>> +    case p2m_ram_paging_out:
>>>>>> +    case p2m_ram_paged:
>>>>>> +    case p2m_ram_paging_in:
>>>>>>         default:
>>>>>>             return flags;
>>>>>>         case p2m_ram_ro:
>>>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>>>                                           shift, max)) )
>>>>>>             return 0;
>>>>>>
>>>>>> -    /* PoD: Not present doesn't imply empty. */
>>>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>>>         if ( !l1e_get_flags(*p2m_entry) )
>>>>>>         {
>>>>>>             struct page_info *pg;
>>>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>                                        0, L1_PAGETABLE_ENTRIES);
>>>>>>             ASSERT(p2m_entry);
>>>>>>
>>>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in)
>>>>>> )
>>>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>>>                                              p2m_type_to_flags(p2mt,
>>>>>> mfn));
>>>>>>             else
>>>>>>                 entry_content = l1e_empty();
>>>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>             if ( entry_content.l1 != 0 )
>>>>>>             {
>>>>>>                 p2m_add_iommu_flags(&entry_content, 0,
>>>>>> iommu_pte_flags);
>>>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>>>             }
>>>>>>             /* level 1 entry */
>>>>>>             p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>>>> entry_content, 1);
>>>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>>>                                sizeof(l1e));
>>>>>>
>>>>>>         if ( ret == 0 ) {
>>>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>>>             p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN ||
>>>>>> !p2m_is_ram(p2mt));
>>>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>>>> +                (l1e_mfn == INVALID_MFN&&    p2m_is_paging(p2mt))
>>>>>> );
>>>>>>
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>>>> -             == p2m_populate_on_demand )
>>>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 /* The read has succeeded, so we know that the
>>>>>> mapping
>>>>>>                  * exits at this point.  */
>>>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>>>             }
>>>>>>
>>>>>>             if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>>>> +            mfn = _mfn(l1e_mfn);
>>>>>>             else
>>>>>>                 /* XXX see above */
>>>>>>                 p2mt = p2m_mmio_dm;
>>>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>>>     pod_retry_l1:
>>>>>>         if ( (l1e_get_flags(*l1e)&    _PAGE_PRESENT) == 0 )
>>>>>>         {
>>>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>>             /* PoD: Try to populate */
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>>>> p2m_populate_on_demand )
>>>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 if ( q != p2m_query ) {
>>>>>>                     if ( !p2m_pod_demand_populate(p2m, gfn,
>>>>>> PAGE_ORDER_4K,
>>>>>> q) )
>>>>>>                         goto pod_retry_l1;
>>>>>>                 } else
>>>>>>                     *t = p2m_populate_on_demand;
>>>>>> +        } else {
>>>>>> +            if ( p2m_is_paging(l1t) )
>>>>>> +            {
>>>>>> +                *t = l1t;
>>>>>> +                /* No need to unclip due to check below */
>>>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>> +            }
>>>>>>             }
>>>>>>
>>>>>>             unmap_domain_page(l1e);
>>>>>> -        return _mfn(INVALID_MFN);
>>>>>> +        return (l1t == p2m_ram_paging_out) ? mfn :
>>>>>> _mfn(INVALID_MFN);
>>>>>>         }
>>>>>>         mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>>         *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>>>                         flags = l1e_get_flags(l1e[i1]);
>>>>>>                         if ( p2m_flags_to_type(flags) != ot )
>>>>>>                             continue;
>>>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                         gfn = i1 + (i2 + (i3
>>>>>>     #if CONFIG_PAGING_LEVELS>= 4
>>>>>>     					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>>>                                * L2_PAGETABLE_ENTRIES) *
>>>>>> L1_PAGETABLE_ENTRIES;
>>>>>>                         /* create a new 1le entry with the new type
>>>>>> */
>>>>>>                         flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>>>> flags);
>>>>>>                         p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>>>                                              l1mfn, l1e_content, 1);
>>>>>>                     }
>>>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>>>                                     entry_count++;
>>>>>>                                 continue;
>>>>>>                             }
>>>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                             ASSERT(mfn_valid(_mfn(mfn)));
>>>>>>                             m2pfn = get_gpfn_from_mfn(mfn);
>>>>>>                             if ( m2pfn != gfn&&
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:42:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2Wm-0000sV-V7; Thu, 16 Feb 2012 14:41:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry2Wl-0000sJ-Kw
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 14:41:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329403259!9481681!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTM1OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23346 invoked from network); 16 Feb 2012 14:40:59 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 14:40:59 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id B18C2458080;
	Thu, 16 Feb 2012 06:40:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=cueAi5BlA7BA1SvIjuO4TlT+6ZEOYN8GnALMkl4sbSNY
	EN37wwf04g9DKTKLlQKEyQSO6eHTH0NyZxf3OFqqMNtw3jUuZv9FV+VwAM/LBqqs
	QPgkNw3EIaTsVJt/MQq/0omXGMUOrM4YiMm14kT2qYjTZb30P7W29+T3+USG3AM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=7kvZlykHlbkn32pEi44UWh9Z24o=; b=qKDwyRkw
	vu6wrjHoMG2vSb6dJ7ZxzzOcVAr31XaqWXgAmO0BhqWLoRyZTgJtwuq54zwrICMG
	iGSh5o2xSj65jIWeiYv7bwZBxt4UCDjHdDznu/cRXVfiUZ2yuR7DM3opz4s96AXL
	qJfD4kKmQA/Y8jRDXJJY6sfpk6xcm5UoQTM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 337F745807C; 
	Thu, 16 Feb 2012 06:40:58 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 06:40:58 -0800
Message-ID: <1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3CDAF80200007800073601@nat28.tlf.novell.com>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
Date: Thu, 16 Feb 2012 06:40:58 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> wrote:
>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>> threshold.
>
> In this patch, which didn't make it to my inbox yet, you will want to
> change this
>
> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>
> to
>
>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>
> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
> being just 'long', would get significant bits shifted out.
>
> I'm further wondering whether the default value shouldn't be set
> dynamically based on available memory and/or taking into account
> an eventual dom0_mem= option.

I can cap or get rid of the threshold (and the virq) if it doesn't make
sense with respect to total memory. I'm not sure about integrating
dom0_mem, since dom0's footprint is also a quantity manipulated by the
receiver of the virq.

>
> Finally, rate limiting will be needed for sending the vIRQ - currently,
> once below the threshold you're sending one on each and every
> allocation (which may become harmful if the listener can't really do
> anything about the situation).

All three are sensible. I'll look into printk rate-limiting for inspiration.
Thanks,
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:42:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2Wm-0000sV-V7; Thu, 16 Feb 2012 14:41:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry2Wl-0000sJ-Kw
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 14:41:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329403259!9481681!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTM1OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23346 invoked from network); 16 Feb 2012 14:40:59 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-21.messagelabs.com with SMTP;
	16 Feb 2012 14:40:59 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id B18C2458080;
	Thu, 16 Feb 2012 06:40:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=cueAi5BlA7BA1SvIjuO4TlT+6ZEOYN8GnALMkl4sbSNY
	EN37wwf04g9DKTKLlQKEyQSO6eHTH0NyZxf3OFqqMNtw3jUuZv9FV+VwAM/LBqqs
	QPgkNw3EIaTsVJt/MQq/0omXGMUOrM4YiMm14kT2qYjTZb30P7W29+T3+USG3AM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=7kvZlykHlbkn32pEi44UWh9Z24o=; b=qKDwyRkw
	vu6wrjHoMG2vSb6dJ7ZxzzOcVAr31XaqWXgAmO0BhqWLoRyZTgJtwuq54zwrICMG
	iGSh5o2xSj65jIWeiYv7bwZBxt4UCDjHdDznu/cRXVfiUZ2yuR7DM3opz4s96AXL
	qJfD4kKmQA/Y8jRDXJJY6sfpk6xcm5UoQTM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 337F745807C; 
	Thu, 16 Feb 2012 06:40:58 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 06:40:58 -0800
Message-ID: <1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3CDAF80200007800073601@nat28.tlf.novell.com>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
Date: Thu, 16 Feb 2012 06:40:58 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> wrote:
>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>> threshold.
>
> In this patch, which didn't make it to my inbox yet, you will want to
> change this
>
> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>
> to
>
>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>
> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
> being just 'long', would get significant bits shifted out.
>
> I'm further wondering whether the default value shouldn't be set
> dynamically based on available memory and/or taking into account
> an eventual dom0_mem= option.

I can cap or get rid of the threshold (and the virq) if it doesn't make
sense with respect to total memory. I'm not sure about integrating
dom0_mem, since dom0's footprint is also a quantity manipulated by the
receiver of the virq.

>
> Finally, rate limiting will be needed for sending the vIRQ - currently,
> once below the threshold you're sending one on each and every
> allocation (which may become harmful if the listener can't really do
> anything about the situation).

All three are sensible. I'll look into printk rate-limiting for inspiration.
Thanks,
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:46:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2ax-000162-T0; Thu, 16 Feb 2012 14:46:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry2av-00015m-8i
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:46:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329403552!14543629!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTQ4ODE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14957 invoked from network); 16 Feb 2012 14:45:53 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 14:45:53 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 3EE5C60408D;
	Thu, 16 Feb 2012 06:45:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Vt/r6Xv/wx16zTPhvPtj13dlaDUzFO86CL5R1y10Z3rW
	uD+fQ76t/EKKXCBbYtQ6cD7oGShEMecLHDP716UH/WDnDObzV/M3M5WtbLDZfBL4
	v7oM/ufdPh9eyhXAvNRSIvnMNB3zYcJvS1/rFJeDfV6vMZ76BKPCC1KfXNSVx90=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=K8hBXLeuym7zpBnK/JnYxsPPDV8=; b=RtazNca0
	N0zoFJ3T4mWBsFxPsr0nGMn1onh7Q0OVihhCQ+6S98jjeLjcqWL8rbi+Zit32YNv
	cNn6dEc7QHiojEX4xYUjj8rHQxhSZuVRvke7tjEdif8YQsfFOAomOdWXxvqW5sRA
	Zvam4k6mzmXsFx4C3qn+DTv1NHD6Gm2vy6o=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id E8CEE60408C; 
	Thu, 16 Feb 2012 06:45:50 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 06:45:51 -0800
Message-ID: <5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216102014.GA40020@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
Date: Thu, 16 Feb 2012 06:45:51 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:57 -0500 on 15 Feb (1329346624), Andres Lagar-Cavilla wrote:
>>  xen/common/domctl.c |  8 +++++++-
>>  1 files changed, 7 insertions(+), 1 deletions(-)
>>
>>
>> Apparently, setting d->max_pages to something lower than d->tot_pages is
>> used as a mechanism for controling a domain's footprint. It will result
>> in all new page allocations failing.
>
> Yep.
>
>> This is a really bad idea with paging or sharing, as regular guest
>> memory
>> accesses may need to be satisfied by allocating new memory (either to
>> page in or to unshare).
>
> Nack.  If a domain ends up with a max_pages so low that it can't page
> in, that's a tools bug.  This patch doesn't fix it, because the
> toolstack could set new max == current tot (er, +1) and then you have
> the same problem if you page in twice.   (And also it silently ignores
> the update rather than reporting an error.)

Fair enough (also referring to Jan's comments). We would be building
policy into the hypervisor.

But I've seen squeezed set criminally low max_pages value (i.e. 256).
Granted, this is squeezed's problem, but shouldn't some sanity checking be
wired into the hypervisor? Why should we even allow max_pages < tot_pages?

Also please note that paging can somewhat deal with this because the pager
gets synchronous kicks in a "clean" context -- the pager can swap out some
stuff with ease. Sharing is seriously disadvantaged here -- the enomem
ring is not mandatory, and failed allocations can happen in runtime paths
rather than on the pager's request.

Andres

>
> Tim.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>>           * NB. We removed a check that new_max >= current tot_pages;
>> this means
>>           * that the domain will now be allowed to "ratchet" down to
>> new_max. In
>>           * the meantime, while tot > max, all new allocations are
>> disallowed.
>> +         *
>> +         * Except that this is not a great idea for domains doing
>> sharing or
>> +         * paging, as they need to perform new allocations on the fly.
>>           */
>> -        d->max_pages = new_max;
>> +        if ( (new_max > d->max_pages) ||
>> +             !((d->mem_event->paging.ring_page != NULL) ||
>> +                d->arch.hvm_domain.mem_sharing_enabled) )
>> +            d->max_pages = new_max;
>>          ret = 0;
>>          spin_unlock(&d->page_alloc_lock);
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:46:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 14: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.xensource.com>)
	id 1Ry2ax-000162-T0; Thu, 16 Feb 2012 14:46:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry2av-00015m-8i
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:46:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329403552!14543629!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTQ4ODE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14957 invoked from network); 16 Feb 2012 14:45:53 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-14.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 14:45:53 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 3EE5C60408D;
	Thu, 16 Feb 2012 06:45:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Vt/r6Xv/wx16zTPhvPtj13dlaDUzFO86CL5R1y10Z3rW
	uD+fQ76t/EKKXCBbYtQ6cD7oGShEMecLHDP716UH/WDnDObzV/M3M5WtbLDZfBL4
	v7oM/ufdPh9eyhXAvNRSIvnMNB3zYcJvS1/rFJeDfV6vMZ76BKPCC1KfXNSVx90=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=K8hBXLeuym7zpBnK/JnYxsPPDV8=; b=RtazNca0
	N0zoFJ3T4mWBsFxPsr0nGMn1onh7Q0OVihhCQ+6S98jjeLjcqWL8rbi+Zit32YNv
	cNn6dEc7QHiojEX4xYUjj8rHQxhSZuVRvke7tjEdif8YQsfFOAomOdWXxvqW5sRA
	Zvam4k6mzmXsFx4C3qn+DTv1NHD6Gm2vy6o=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id E8CEE60408C; 
	Thu, 16 Feb 2012 06:45:50 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 06:45:51 -0800
Message-ID: <5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216102014.GA40020@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
Date: Thu, 16 Feb 2012 06:45:51 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:57 -0500 on 15 Feb (1329346624), Andres Lagar-Cavilla wrote:
>>  xen/common/domctl.c |  8 +++++++-
>>  1 files changed, 7 insertions(+), 1 deletions(-)
>>
>>
>> Apparently, setting d->max_pages to something lower than d->tot_pages is
>> used as a mechanism for controling a domain's footprint. It will result
>> in all new page allocations failing.
>
> Yep.
>
>> This is a really bad idea with paging or sharing, as regular guest
>> memory
>> accesses may need to be satisfied by allocating new memory (either to
>> page in or to unshare).
>
> Nack.  If a domain ends up with a max_pages so low that it can't page
> in, that's a tools bug.  This patch doesn't fix it, because the
> toolstack could set new max == current tot (er, +1) and then you have
> the same problem if you page in twice.   (And also it silently ignores
> the update rather than reporting an error.)

Fair enough (also referring to Jan's comments). We would be building
policy into the hypervisor.

But I've seen squeezed set criminally low max_pages value (i.e. 256).
Granted, this is squeezed's problem, but shouldn't some sanity checking be
wired into the hypervisor? Why should we even allow max_pages < tot_pages?

Also please note that paging can somewhat deal with this because the pager
gets synchronous kicks in a "clean" context -- the pager can swap out some
stuff with ease. Sharing is seriously disadvantaged here -- the enomem
ring is not mandatory, and failed allocations can happen in runtime paths
rather than on the pager's request.

Andres

>
> Tim.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 62b1fe67b8d1 -r 11fd4e0a1e1a xen/common/domctl.c
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -813,8 +813,14 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>>           * NB. We removed a check that new_max >= current tot_pages;
>> this means
>>           * that the domain will now be allowed to "ratchet" down to
>> new_max. In
>>           * the meantime, while tot > max, all new allocations are
>> disallowed.
>> +         *
>> +         * Except that this is not a great idea for domains doing
>> sharing or
>> +         * paging, as they need to perform new allocations on the fly.
>>           */
>> -        d->max_pages = new_max;
>> +        if ( (new_max > d->max_pages) ||
>> +             !((d->mem_event->paging.ring_page != NULL) ||
>> +                d->arch.hvm_domain.mem_sharing_enabled) )
>> +            d->max_pages = new_max;
>>          ret = 0;
>>          spin_unlock(&d->page_alloc_lock);
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:59:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry2nD-0001M4-6p; Thu, 16 Feb 2012 14:58:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry2nB-0001Lq-Ls
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:58:41 +0000
Received: from [85.158.139.83:39286] by server-5.bemta-5.messagelabs.com id
	F6/34-13566-0A91D3F4; Thu, 16 Feb 2012 14:58:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329404318!15359107!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15410 invoked from network); 16 Feb 2012 14:58:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 14:58:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry2n7-000BK0-8s; Thu, 16 Feb 2012 14:58:37 +0000
Date: Thu, 16 Feb 2012 14:58:37 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216145837.GA41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-api@lists.xensource.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
	domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:45 -0800 on 16 Feb (1329374751), Andres Lagar-Cavilla wrote:
> Fair enough (also referring to Jan's comments). We would be building
> policy into the hypervisor.
> 
> But I've seen squeezed set criminally low max_pages value (i.e. 256).
> Granted, this is squeezed's problem, but shouldn't some sanity checking be
> wired into the hypervisor?

Some operating systems do just fine in 640K. :)  But seriously, what
lower limit would we use?  Stupidly low max_pages for some uses would be
just fine for others. 

> Why should we even allow max_pages < tot_pages?

The reasoning is:
 - the tools want a hard guarantee that a rogue balloon driver can't 
   mess up their calculations of how much free RAM there is.
 - when a VM is ballooning down we don't want to have the tools spinning
   watching actual max_pages and adjusting tot_pages down as it
   changes.

It's not a particularly nice interface, though, and I'd be happy to see
it revert to the old one (where new max had to be <= current tot).  But
that will need a fix for Xapi/squeezed to handle the ballooning-down
case some other way.

Cc-ing xen-API.  Any XCP folks got an opinion about this?  Would it be
easy to make squeezed not need this behaviour?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 14:59:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry2nD-0001M4-6p; Thu, 16 Feb 2012 14:58:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry2nB-0001Lq-Ls
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 14:58:41 +0000
Received: from [85.158.139.83:39286] by server-5.bemta-5.messagelabs.com id
	F6/34-13566-0A91D3F4; Thu, 16 Feb 2012 14:58:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329404318!15359107!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15410 invoked from network); 16 Feb 2012 14:58:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 14:58:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry2n7-000BK0-8s; Thu, 16 Feb 2012 14:58:37 +0000
Date: Thu, 16 Feb 2012 14:58:37 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216145837.GA41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-api@lists.xensource.com, andres@gridcentric.ca,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
	domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 06:45 -0800 on 16 Feb (1329374751), Andres Lagar-Cavilla wrote:
> Fair enough (also referring to Jan's comments). We would be building
> policy into the hypervisor.
> 
> But I've seen squeezed set criminally low max_pages value (i.e. 256).
> Granted, this is squeezed's problem, but shouldn't some sanity checking be
> wired into the hypervisor?

Some operating systems do just fine in 640K. :)  But seriously, what
lower limit would we use?  Stupidly low max_pages for some uses would be
just fine for others. 

> Why should we even allow max_pages < tot_pages?

The reasoning is:
 - the tools want a hard guarantee that a rogue balloon driver can't 
   mess up their calculations of how much free RAM there is.
 - when a VM is ballooning down we don't want to have the tools spinning
   watching actual max_pages and adjusting tot_pages down as it
   changes.

It's not a particularly nice interface, though, and I'd be happy to see
it revert to the old one (where new max had to be <= current tot).  But
that will need a fix for Xapi/squeezed to handle the ballooning-down
case some other way.

Cc-ing xen-API.  Any XCP folks got an opinion about this?  Would it be
easy to make squeezed not need this behaviour?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:21:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry38c-0001e9-He; Thu, 16 Feb 2012 15:20:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry38a-0001e1-PZ
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:20:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329405641!13675669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23477 invoked from network); 16 Feb 2012 15:20:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 15:20:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry38S-000BOZ-JV; Thu, 16 Feb 2012 15:20:40 +0000
Date: Thu, 16 Feb 2012 15:20:40 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120216152040.GC41163@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

As promised, a revised version of the waitq-on-missing-pages patch.
I've cut it back a fair bit; I think the resulting patch is maybe a bit
less efficient, but easier to understand.

I've smoke-tested it a bit and haven't seen anything catch fire but I
suspect the VMs aren't very happy.  I'll debug more throughly when I'm
back in the office next week, but would really like some feedback from
the rest of you in the meantime.

Cheers,

Tim.

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Parent 01c1bcbc62224833304ede44187400f65e8a6b4c
[RFC] x86/mm: use wait queues for mem_paging

Use a wait queue to put a guest vcpu to sleep while the requested gfn is
in paging state. This adds missing p2m_mem_paging_populate() calls to
some callers of the new get_gfn* variants, which would crash now
because they get an invalid mfn. It also fixes guest crashes due to
unexpected returns from do_memory_op because copy_to/from_guest ran into
a paged gfn. Now those places will always get a valid mfn.

This is based on an earlier RFC patch by Olaf Hering, but heavily
simplified (removing a per-gfn queue of waiting vcpus in favour of
a scan of all vcpus on page-in).

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
@@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    locked = locked && hap_enabled(p2m->domain);
+
+#ifdef __x86_64__
+again:
+#endif
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
+    if ( p2m_is_paging(*t) && q != p2m_query 
+         && p2m->domain == current->domain ) 
+    {
+        if ( locked )
+            gfn_unlock(p2m, gfn, 0);
+
+        /* Ping the pager */
+        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+            p2m_mem_paging_populate(p2m->domain, gfn);
+
+        /* Safety catch: it _should_ be safe to wait here but if it's not, 
+         * crash the VM, not the host */
+        if ( in_atomic() )
+        {
+            WARN();
+            domain_crash(p2m->domain);
+        }
+        else
+        {
+            current->arch.mem_paging_gfn = gfn;
+            wait_event(current->arch.mem_paging_wq, ({
+                        mfn = p2m->get_entry(p2m, gfn, t, a,
+                                             p2m_query, page_order);
+                        (*t != p2m_ram_paging_in);
+                    }));
+            goto again;
+        }
+    }
+#endif
+
+#ifdef __x86_64__
     if ( q == p2m_unshare && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -942,25 +978,25 @@ void p2m_mem_paging_drop_page(struct dom
  * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
  * paging types because the gfn may not be backed by a mfn.
  *
- * The gfn can be in any of the paging states, but the pager needs only be
- * notified when the gfn is in the paging-out path (paging_out or paged).  This
- * function may be called more than once from several vcpus. If the vcpu belongs
- * to the guest, the vcpu must be stopped and the pager notified that the vcpu
- * was stopped. The pager needs to handle several requests for the same gfn.
+ * The gfn can be in any of the paging states, but the pager needs only
+ * be notified when the gfn is in the paging-out path (paging_out or
+ * paged).  This function may be called more than once from several
+ * vcpus.  The pager needs to handle several requests for the same gfn.
  *
- * If the gfn is not in the paging-out path and the vcpu does not belong to the
- * guest, nothing needs to be done and the function assumes that a request was
- * already sent to the pager. In this case the caller has to try again until the
- * gfn is fully paged in again.
+ * If the gfn is not in the paging-out path nothing needs to be done and
+ * the function assumes that a request was already sent to the pager.
+ * In this case the caller has to try again until the gfn is fully paged
+ * in again.
  */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = {0};
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int send_request = 0;
 
     /* We're paging. There should be a ring */
     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
@@ -974,9 +1010,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( rc < 0 )
         return;
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
-
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -986,26 +1019,29 @@ void p2m_mem_paging_populate(struct doma
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
-
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain == d )
+            /* Short-cut back to paged-in state (but not for foreign 
+             * mappings, or the pager couldn't map it to page it out) */
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                          paging_mode_log_dirty(d) 
+                          ? p2m_ram_logdirty : p2m_ram_rw, a);
+        else
+        {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+            send_request = 1;
+        }
     }
     gfn_unlock(p2m, gfn, 0);
 
-    /* Pause domain if request came from guest and gfn has paging type */
-    if ( p2m_is_paging(p2mt) && v->domain == d )
+    /* No need to inform pager if the gfn is not in the page-out path */
+    if ( !send_request ) 
     {
-        vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    }
-    /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
-    {
-        /* gfn is already on its way back and vcpu is not paused */
         mem_event_cancel_slot(d, &d->mem_event->paging);
         return;
     }
 
     /* Send request to pager */
+    req.type = MEM_EVENT_TYPE_PAGING;
     req.gfn = gfn;
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
@@ -1122,6 +1158,7 @@ void p2m_mem_paging_resume(struct domain
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     mem_event_response_t rsp;
+    struct vcpu *v;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -1147,9 +1184,10 @@ void p2m_mem_paging_resume(struct domain
             }
             gfn_unlock(p2m, rsp.gfn, 0);
         }
-        /* Unpause domain */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+        /* Wake any vcpus that were waiting for this GFN */
+        for_each_vcpu ( d, v )
+            if ( v->arch.mem_paging_gfn == rsp.gfn )
+                wake_up_all(&v->arch.mem_paging_wq);
     }
 }
 
diff -r 01c1bcbc6222 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Feb 16 08:48:23 2012 +0100
+++ b/xen/include/asm-x86/domain.h	Thu Feb 16 14:39:13 2012 +0000
@@ -4,6 +4,7 @@
 #include <xen/config.h>
 #include <xen/mm.h>
 #include <xen/radix-tree.h>
+#include <xen/wait.h>
 #include <asm/hvm/vcpu.h>
 #include <asm/hvm/domain.h>
 #include <asm/e820.h>
@@ -491,6 +492,12 @@ struct arch_vcpu
     
     struct paging_vcpu paging;
 
+#ifdef CONFIG_X86_64
+    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
+    struct waitqueue_head mem_paging_wq;
+    unsigned long mem_paging_gfn;
+#endif
+
 #ifdef CONFIG_X86_32
     /* map_domain_page() mapping cache. */
     struct mapcache_vcpu mapcache;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:21:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry38c-0001e9-He; Thu, 16 Feb 2012 15:20:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry38a-0001e1-PZ
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:20:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329405641!13675669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23477 invoked from network); 16 Feb 2012 15:20:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 15:20:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry38S-000BOZ-JV; Thu, 16 Feb 2012 15:20:40 +0000
Date: Thu, 16 Feb 2012 15:20:40 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120216152040.GC41163@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

As promised, a revised version of the waitq-on-missing-pages patch.
I've cut it back a fair bit; I think the resulting patch is maybe a bit
less efficient, but easier to understand.

I've smoke-tested it a bit and haven't seen anything catch fire but I
suspect the VMs aren't very happy.  I'll debug more throughly when I'm
back in the office next week, but would really like some feedback from
the rest of you in the meantime.

Cheers,

Tim.

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Parent 01c1bcbc62224833304ede44187400f65e8a6b4c
[RFC] x86/mm: use wait queues for mem_paging

Use a wait queue to put a guest vcpu to sleep while the requested gfn is
in paging state. This adds missing p2m_mem_paging_populate() calls to
some callers of the new get_gfn* variants, which would crash now
because they get an invalid mfn. It also fixes guest crashes due to
unexpected returns from do_memory_op because copy_to/from_guest ran into
a paged gfn. Now those places will always get a valid mfn.

This is based on an earlier RFC patch by Olaf Hering, but heavily
simplified (removing a per-gfn queue of waiting vcpus in favour of
a scan of all vcpus on page-in).

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
@@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    locked = locked && hap_enabled(p2m->domain);
+
+#ifdef __x86_64__
+again:
+#endif
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
+    if ( p2m_is_paging(*t) && q != p2m_query 
+         && p2m->domain == current->domain ) 
+    {
+        if ( locked )
+            gfn_unlock(p2m, gfn, 0);
+
+        /* Ping the pager */
+        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+            p2m_mem_paging_populate(p2m->domain, gfn);
+
+        /* Safety catch: it _should_ be safe to wait here but if it's not, 
+         * crash the VM, not the host */
+        if ( in_atomic() )
+        {
+            WARN();
+            domain_crash(p2m->domain);
+        }
+        else
+        {
+            current->arch.mem_paging_gfn = gfn;
+            wait_event(current->arch.mem_paging_wq, ({
+                        mfn = p2m->get_entry(p2m, gfn, t, a,
+                                             p2m_query, page_order);
+                        (*t != p2m_ram_paging_in);
+                    }));
+            goto again;
+        }
+    }
+#endif
+
+#ifdef __x86_64__
     if ( q == p2m_unshare && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -942,25 +978,25 @@ void p2m_mem_paging_drop_page(struct dom
  * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
  * paging types because the gfn may not be backed by a mfn.
  *
- * The gfn can be in any of the paging states, but the pager needs only be
- * notified when the gfn is in the paging-out path (paging_out or paged).  This
- * function may be called more than once from several vcpus. If the vcpu belongs
- * to the guest, the vcpu must be stopped and the pager notified that the vcpu
- * was stopped. The pager needs to handle several requests for the same gfn.
+ * The gfn can be in any of the paging states, but the pager needs only
+ * be notified when the gfn is in the paging-out path (paging_out or
+ * paged).  This function may be called more than once from several
+ * vcpus.  The pager needs to handle several requests for the same gfn.
  *
- * If the gfn is not in the paging-out path and the vcpu does not belong to the
- * guest, nothing needs to be done and the function assumes that a request was
- * already sent to the pager. In this case the caller has to try again until the
- * gfn is fully paged in again.
+ * If the gfn is not in the paging-out path nothing needs to be done and
+ * the function assumes that a request was already sent to the pager.
+ * In this case the caller has to try again until the gfn is fully paged
+ * in again.
  */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = {0};
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int send_request = 0;
 
     /* We're paging. There should be a ring */
     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
@@ -974,9 +1010,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( rc < 0 )
         return;
 
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
-
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -986,26 +1019,29 @@ void p2m_mem_paging_populate(struct doma
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
-
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain == d )
+            /* Short-cut back to paged-in state (but not for foreign 
+             * mappings, or the pager couldn't map it to page it out) */
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                          paging_mode_log_dirty(d) 
+                          ? p2m_ram_logdirty : p2m_ram_rw, a);
+        else
+        {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+            send_request = 1;
+        }
     }
     gfn_unlock(p2m, gfn, 0);
 
-    /* Pause domain if request came from guest and gfn has paging type */
-    if ( p2m_is_paging(p2mt) && v->domain == d )
+    /* No need to inform pager if the gfn is not in the page-out path */
+    if ( !send_request ) 
     {
-        vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    }
-    /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
-    {
-        /* gfn is already on its way back and vcpu is not paused */
         mem_event_cancel_slot(d, &d->mem_event->paging);
         return;
     }
 
     /* Send request to pager */
+    req.type = MEM_EVENT_TYPE_PAGING;
     req.gfn = gfn;
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
@@ -1122,6 +1158,7 @@ void p2m_mem_paging_resume(struct domain
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     mem_event_response_t rsp;
+    struct vcpu *v;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -1147,9 +1184,10 @@ void p2m_mem_paging_resume(struct domain
             }
             gfn_unlock(p2m, rsp.gfn, 0);
         }
-        /* Unpause domain */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+        /* Wake any vcpus that were waiting for this GFN */
+        for_each_vcpu ( d, v )
+            if ( v->arch.mem_paging_gfn == rsp.gfn )
+                wake_up_all(&v->arch.mem_paging_wq);
     }
 }
 
diff -r 01c1bcbc6222 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Feb 16 08:48:23 2012 +0100
+++ b/xen/include/asm-x86/domain.h	Thu Feb 16 14:39:13 2012 +0000
@@ -4,6 +4,7 @@
 #include <xen/config.h>
 #include <xen/mm.h>
 #include <xen/radix-tree.h>
+#include <xen/wait.h>
 #include <asm/hvm/vcpu.h>
 #include <asm/hvm/domain.h>
 #include <asm/e820.h>
@@ -491,6 +492,12 @@ struct arch_vcpu
     
     struct paging_vcpu paging;
 
+#ifdef CONFIG_X86_64
+    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
+    struct waitqueue_head mem_paging_wq;
+    unsigned long mem_paging_gfn;
+#endif
+
 #ifdef CONFIG_X86_32
     /* map_domain_page() mapping cache. */
     struct mapcache_vcpu mapcache;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:22:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15: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.xensource.com>)
	id 1Ry39p-0001gg-Bd; Thu, 16 Feb 2012 15:22: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 1Ry39m-0001gY-Mx
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 15:22:03 +0000
Received: from [85.158.139.83:10784] by server-4.bemta-5.messagelabs.com id
	40/68-10788-91F1D3F4; Thu, 16 Feb 2012 15:22:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329405720!15292429!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10291 invoked from network); 16 Feb 2012 15:22:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 15:22:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 15:22:00 +0000
Message-Id: <4F3D2D28020000780007377D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 15:22:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
	<1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>> wrote:
>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>> threshold.
>>
>> In this patch, which didn't make it to my inbox yet, you will want to
>> change this
>>
>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>
>> to
>>
>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>
>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>> being just 'long', would get significant bits shifted out.
>>
>> I'm further wondering whether the default value shouldn't be set
>> dynamically based on available memory and/or taking into account
>> an eventual dom0_mem= option.
> 
> I can cap or get rid of the threshold (and the virq) if it doesn't make
> sense with respect to total memory. I'm not sure about integrating
> dom0_mem, since dom0's footprint is also a quantity manipulated by the
> receiver of the virq.

No, dom0_mem= is only specifying the starting value, and the case
that would be of possibly interest is that of having a negative amount
specified.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:22:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15: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.xensource.com>)
	id 1Ry39p-0001gg-Bd; Thu, 16 Feb 2012 15:22: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 1Ry39m-0001gY-Mx
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 15:22:03 +0000
Received: from [85.158.139.83:10784] by server-4.bemta-5.messagelabs.com id
	40/68-10788-91F1D3F4; Thu, 16 Feb 2012 15:22:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329405720!15292429!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10291 invoked from network); 16 Feb 2012 15:22:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 15:22:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 15:22:00 +0000
Message-Id: <4F3D2D28020000780007377D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 15:22:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
	<1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>> wrote:
>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>> threshold.
>>
>> In this patch, which didn't make it to my inbox yet, you will want to
>> change this
>>
>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>
>> to
>>
>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>
>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>> being just 'long', would get significant bits shifted out.
>>
>> I'm further wondering whether the default value shouldn't be set
>> dynamically based on available memory and/or taking into account
>> an eventual dom0_mem= option.
> 
> I can cap or get rid of the threshold (and the virq) if it doesn't make
> sense with respect to total memory. I'm not sure about integrating
> dom0_mem, since dom0's footprint is also a quantity manipulated by the
> receiver of the virq.

No, dom0_mem= is only specifying the starting value, and the case
that would be of possibly interest is that of having a negative amount
specified.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3K1-0001xX-FX; Thu, 16 Feb 2012 15:32:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ry3K0-0001xS-KJ
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:32:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329406349!13677755!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10857 invoked from network); 16 Feb 2012 15:32:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 15:32:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 15:32:28 +0000
Message-Id: <4F3D2F9C020000780007378E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 15:32:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Tim Deegan <tim@xen.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 15:45, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> But I've seen squeezed set criminally low max_pages value (i.e. 256).
> Granted, this is squeezed's problem, but shouldn't some sanity checking be
> wired into the hypervisor? Why should we even allow max_pages < tot_pages?

The only lower boundary that the hypervisor could (perhaps should)
enforce is that of not being able to guarantee guest forward progress:
On x86, up to 2 text pages plus up to 4 data pages, times the number
of page table levels (i.e. 24 pages on 64-bit).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3K1-0001xX-FX; Thu, 16 Feb 2012 15:32:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ry3K0-0001xS-KJ
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:32:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329406349!13677755!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10857 invoked from network); 16 Feb 2012 15:32:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 15:32:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 15:32:28 +0000
Message-Id: <4F3D2F9C020000780007378E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 15:32:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Tim Deegan <tim@xen.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 15:45, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> But I've seen squeezed set criminally low max_pages value (i.e. 256).
> Granted, this is squeezed's problem, but shouldn't some sanity checking be
> wired into the hypervisor? Why should we even allow max_pages < tot_pages?

The only lower boundary that the hypervisor could (perhaps should)
enforce is that of not being able to guarantee guest forward progress:
On x86, up to 2 text pages plus up to 4 data pages, times the number
of page table levels (i.e. 24 pages on 64-bit).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:34:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3Lh-00021s-W6; Thu, 16 Feb 2012 15:34:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry3Lg-00021f-Ky
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 15:34:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329406402!54554617!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTQ5MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24023 invoked from network); 16 Feb 2012 15:33:23 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 15:33:23 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 5391976C06E;
	Thu, 16 Feb 2012 07:34:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c45NSU/+fiBIS3jc8ScUCHYvvThorlYSM81mz+SFORJZ
	1qyyYfixUIaOdZuV4JEmLUBGzhbpVJhWHoz2f6MpHF0cHqNMpZQEOng2gJwWmZfV
	6ZZXiPIFFrZ6QGOFEvIM2SjBQIhhPcWd+7MZlJ/WGdE0SQc1Arbxeny4IdCc4wk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=PiY/lHNi2wzc3J6PFxWeiJ+zt5E=; b=o5YWx9Xw
	hiLHfyttkEIM2IEvkIYD8clWrANvU6vQ/M7X7HIv4RW51FzTDwOBvfwzeUdxpaHn
	Y+60qc653tkc+53HjTxahdG+/VnYQzB/inWpI8oDL8Hor0vbdQy6xA3TNlFrFsK0
	ga+yb+stoXAy2nDG7IcrwBgiK5PYmfB457M=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id E1FF576C069; 
	Thu, 16 Feb 2012 07:34:12 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 07:34:13 -0800
Message-ID: <06a5548b6f1f6c2b7fa0a1e2bc11115f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3D2D28020000780007377D@nat28.tlf.novell.com>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
	<1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
	<4F3D2D28020000780007377D@nat28.tlf.novell.com>
Date: Thu, 16 Feb 2012 07:34:13 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>>> wrote:
>>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>>> threshold.
>>>
>>> In this patch, which didn't make it to my inbox yet, you will want to
>>> change this
>>>
>>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>>
>>> to
>>>
>>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>>
>>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>>> being just 'long', would get significant bits shifted out.
>>>
>>> I'm further wondering whether the default value shouldn't be set
>>> dynamically based on available memory and/or taking into account
>>> an eventual dom0_mem= option.
>>
>> I can cap or get rid of the threshold (and the virq) if it doesn't make
>> sense with respect to total memory. I'm not sure about integrating
>> dom0_mem, since dom0's footprint is also a quantity manipulated by the
>> receiver of the virq.
>
> No, dom0_mem= is only specifying the starting value, and the case
> that would be of possibly interest is that of having a negative amount
> specified.

Sorry, not following entirely. The negative quantity you refer to would be
dom0_mem or the low mem virq threshold? Additional checks pertaining only
to dom0_mem, not in relation to this threshold, would most likely go on a
separate patch.

And both quantities are parsed using strtoull, so you get at most really
large numbers. I certainly need to add additional checks for unsuitable
low_mem_virq thresholds to this patch.

Thanks,
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:34:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3Lh-00021s-W6; Thu, 16 Feb 2012 15:34:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Ry3Lg-00021f-Ky
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 15:34:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329406402!54554617!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTQ5MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24023 invoked from network); 16 Feb 2012 15:33:23 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	16 Feb 2012 15:33:23 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 5391976C06E;
	Thu, 16 Feb 2012 07:34:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c45NSU/+fiBIS3jc8ScUCHYvvThorlYSM81mz+SFORJZ
	1qyyYfixUIaOdZuV4JEmLUBGzhbpVJhWHoz2f6MpHF0cHqNMpZQEOng2gJwWmZfV
	6ZZXiPIFFrZ6QGOFEvIM2SjBQIhhPcWd+7MZlJ/WGdE0SQc1Arbxeny4IdCc4wk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=PiY/lHNi2wzc3J6PFxWeiJ+zt5E=; b=o5YWx9Xw
	hiLHfyttkEIM2IEvkIYD8clWrANvU6vQ/M7X7HIv4RW51FzTDwOBvfwzeUdxpaHn
	Y+60qc653tkc+53HjTxahdG+/VnYQzB/inWpI8oDL8Hor0vbdQy6xA3TNlFrFsK0
	ga+yb+stoXAy2nDG7IcrwBgiK5PYmfB457M=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id E1FF576C069; 
	Thu, 16 Feb 2012 07:34:12 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 16 Feb 2012 07:34:13 -0800
Message-ID: <06a5548b6f1f6c2b7fa0a1e2bc11115f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F3D2D28020000780007377D@nat28.tlf.novell.com>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
	<1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
	<4F3D2D28020000780007377D@nat28.tlf.novell.com>
Date: Thu, 16 Feb 2012 07:34:13 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>>> wrote:
>>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>>> threshold.
>>>
>>> In this patch, which didn't make it to my inbox yet, you will want to
>>> change this
>>>
>>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>>
>>> to
>>>
>>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>>
>>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>>> being just 'long', would get significant bits shifted out.
>>>
>>> I'm further wondering whether the default value shouldn't be set
>>> dynamically based on available memory and/or taking into account
>>> an eventual dom0_mem= option.
>>
>> I can cap or get rid of the threshold (and the virq) if it doesn't make
>> sense with respect to total memory. I'm not sure about integrating
>> dom0_mem, since dom0's footprint is also a quantity manipulated by the
>> receiver of the virq.
>
> No, dom0_mem= is only specifying the starting value, and the case
> that would be of possibly interest is that of having a negative amount
> specified.

Sorry, not following entirely. The negative quantity you refer to would be
dom0_mem or the low mem virq threshold? Additional checks pertaining only
to dom0_mem, not in relation to this threshold, would most likely go on a
separate patch.

And both quantities are parsed using strtoull, so you get at most really
large numbers. I certainly need to add additional checks for unsuitable
low_mem_virq thresholds to this patch.

Thanks,
Andres
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:52:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3cO-0002ae-DX; Thu, 16 Feb 2012 15:51:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Ry3cN-0002aY-3P
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:51:35 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329407486!9760561!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23077 invoked from network); 16 Feb 2012 15:51:28 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE008.bigfish.com) (65.55.88.11)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Feb 2012 15:51:28 -0000
Received: from mail173-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 15:51:25 +0000
Received: from mail173-tx2 (localhost [127.0.0.1])	by
	mail173-tx2-R.bigfish.com (Postfix) with ESMTP id CEDB12E05D2;
	Thu, 16 Feb 2012 15:47:48 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VPS-5(zz103dK1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail173-tx2 (localhost.localdomain [127.0.0.1]) by mail173-tx2
	(MessageSwitch) id 1329407266623804_21191;
	Thu, 16 Feb 2012 15:47:46 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.240])	by
	mail173-tx2.bigfish.com (Postfix) with ESMTP id 8741240052;
	Thu, 16 Feb 2012 15:47:46 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 15:47:44 +0000
X-WSS-ID: 0LZHT7G-02-B4P-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 2D4BAC808C;	Thu, 16 Feb 2012 09:47:39 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 16 Feb 2012 09:47:58 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 16 Feb 2012 09:47:42 -0600
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, 16 Feb 2012
	10:47:40 -0500
Received: from [165.204.15.175] (silber.osrc.amd.com [165.204.15.175])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6FF9749C34C; Thu, 16 Feb 2012
	15:47:39 +0000 (GMT)
Message-ID: <4F3D251B.7070209@amd.com>
Date: Thu, 16 Feb 2012 16:47:39 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<20120215170259.GA28101@ocelot.phlegethon.org>
In-Reply-To: <20120215170259.GA28101@ocelot.phlegethon.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 15.02.2012 18:02, schrieb Tim Deegan:
> At 08:06 -0800 on 15 Feb (1329293205), Andres Lagar-Cavilla wrote:
>>> Where will p2m access bit be stored? Please note that bit 52 - bit 58
>>> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>>> and bit 1 - bit 8 are free to use if PR bit = 1.
>>
>> Wei,
>>
>> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
>> current convention?
>>
>> I propose limiting p2m type to bits 52-55, and storing p2m access on bits
>> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
>> be zero" requirement/convention.
>
> Eh, let's step back a bit from this.  The problem is that the IOMMU
> can't handle these bits being set, but the IOMMU can't handle paged-out
> or CoW memory either (because there's no way to cause the peripheral to
> retry a DMA that faulted).
>
> So can we just say that any VM that's going to use paging, sharing
> or access can't have a unified p2m and IOMMU table?  That's a bit ugly
> since the admin will have to make the choice, but it seems like the
> hardware is forcing us into it.

Seems true. Although iommuv2 support demand paging, it only works for 
guest OS process context. And we also need support from device side to 
do that.

>
> Maybe the sensible choice is to default to _not_ sharing p2m and IOMMU
> tables, and have thet be something an expert user can turn on (and which
> disables the other features)?

That looks good to me.

> Should we have a hypervisor-level interlock between PCI passthrough and
> paging/sharing/access anyway?  Doing both is unlikely to lead to happiness.

I think we should. DMA might result miserable errors when paging happens.

Thanks
Wei

> Tim.
>
>> Right now, without any considerations for paging, we're storing the p2m
>> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
>> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
>> course. Given your statement above, and table 14 in the IOMMU manual, how
>> is this even working? Or is it not working?
>>
>> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>>
>> Thanks a lot for the info!
>> Andres
>>>
>>> Thanks,
>>> Wei
>>>
>>>> An alternative to enabling mem_access on AMD processors will be to limit
>>>> the access types to 3 bits. This would force disabling support for two
>>>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>>>> they
>>>> make sense without R permissions.
>>>> Thanks!
>>>> Andres
>>>>
>>>>>
>>>>> Thanks,
>>>>> Wei
>>>>>
>>>>>>
>>>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>>>> Comments
>>>>>> welcome.
>>>>>>
>>>>>> Patch inline below, thanks!
>>>>>> Andres
>>>>>>
>>>>>> Enable AMD support for paging.
>>>>>>
>>>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>>>
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>>>                 if ( !hap_enabled(d) )
>>>>>>                     break;
>>>>>>
>>>>>> -            /* Currently only EPT is supported */
>>>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>>>> -                break;
>>>>>> -
>>>>>>                 rc = -EXDEV;
>>>>>>                 /* Disallow paging in a PoD guest */
>>>>>>                 if ( p2m->pod.entry_count )
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>>>> @@ -53,6 +53,20 @@
>>>>>>     #define P2M_BASE_FLAGS \
>>>>>>             (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>>>
>>>>>> +#ifdef __x86_64__
>>>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>>>> 0xff..ff
>>>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>>>> p2mt,
>>>>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>>>> +#define clipped_mfn(mfn)    ((mfn)&    ((1UL<<    EFF_MFN_WIDTH) - 1))
>>>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>>>>> +                                INVALID_MFN : (mfn))
>>>>>> +#else
>>>>>> +#define clipped_mfn(mfn)    (mfn)
>>>>>> +#define unclip_mfn(mfn)     (mfn)
>>>>>> +#endif /* __x86_64__ */
>>>>>> +
>>>>>>     static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>>>     {
>>>>>>         unsigned long flags;
>>>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>>>         case p2m_invalid:
>>>>>>         case p2m_mmio_dm:
>>>>>>         case p2m_populate_on_demand:
>>>>>> +    case p2m_ram_paging_out:
>>>>>> +    case p2m_ram_paged:
>>>>>> +    case p2m_ram_paging_in:
>>>>>>         default:
>>>>>>             return flags;
>>>>>>         case p2m_ram_ro:
>>>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>>>                                           shift, max)) )
>>>>>>             return 0;
>>>>>>
>>>>>> -    /* PoD: Not present doesn't imply empty. */
>>>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>>>         if ( !l1e_get_flags(*p2m_entry) )
>>>>>>         {
>>>>>>             struct page_info *pg;
>>>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>                                        0, L1_PAGETABLE_ENTRIES);
>>>>>>             ASSERT(p2m_entry);
>>>>>>
>>>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>>>                                              p2m_type_to_flags(p2mt,
>>>>>> mfn));
>>>>>>             else
>>>>>>                 entry_content = l1e_empty();
>>>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>             if ( entry_content.l1 != 0 )
>>>>>>             {
>>>>>>                 p2m_add_iommu_flags(&entry_content, 0,
>>>>>> iommu_pte_flags);
>>>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>>>             }
>>>>>>             /* level 1 entry */
>>>>>>             p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>>>> entry_content, 1);
>>>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>>>                                sizeof(l1e));
>>>>>>
>>>>>>         if ( ret == 0 ) {
>>>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>>>             p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>>>> +                (l1e_mfn == INVALID_MFN&&    p2m_is_paging(p2mt)) );
>>>>>>
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>>>> -             == p2m_populate_on_demand )
>>>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 /* The read has succeeded, so we know that the mapping
>>>>>>                  * exits at this point.  */
>>>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>>>             }
>>>>>>
>>>>>>             if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>>>> +            mfn = _mfn(l1e_mfn);
>>>>>>             else
>>>>>>                 /* XXX see above */
>>>>>>                 p2mt = p2m_mmio_dm;
>>>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>>>     pod_retry_l1:
>>>>>>         if ( (l1e_get_flags(*l1e)&    _PAGE_PRESENT) == 0 )
>>>>>>         {
>>>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>>             /* PoD: Try to populate */
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>>>> p2m_populate_on_demand )
>>>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 if ( q != p2m_query ) {
>>>>>>                     if ( !p2m_pod_demand_populate(p2m, gfn,
>>>>>> PAGE_ORDER_4K,
>>>>>> q) )
>>>>>>                         goto pod_retry_l1;
>>>>>>                 } else
>>>>>>                     *t = p2m_populate_on_demand;
>>>>>> +        } else {
>>>>>> +            if ( p2m_is_paging(l1t) )
>>>>>> +            {
>>>>>> +                *t = l1t;
>>>>>> +                /* No need to unclip due to check below */
>>>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>> +            }
>>>>>>             }
>>>>>>
>>>>>>             unmap_domain_page(l1e);
>>>>>> -        return _mfn(INVALID_MFN);
>>>>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>>>>         }
>>>>>>         mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>>         *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>>>                         flags = l1e_get_flags(l1e[i1]);
>>>>>>                         if ( p2m_flags_to_type(flags) != ot )
>>>>>>                             continue;
>>>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                         gfn = i1 + (i2 + (i3
>>>>>>     #if CONFIG_PAGING_LEVELS>= 4
>>>>>>     					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>>>                                * L2_PAGETABLE_ENTRIES) *
>>>>>> L1_PAGETABLE_ENTRIES;
>>>>>>                         /* create a new 1le entry with the new type */
>>>>>>                         flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>>>> flags);
>>>>>>                         p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>>>                                              l1mfn, l1e_content, 1);
>>>>>>                     }
>>>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>>>                                     entry_count++;
>>>>>>                                 continue;
>>>>>>                             }
>>>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                             ASSERT(mfn_valid(_mfn(mfn)));
>>>>>>                             m2pfn = get_gpfn_from_mfn(mfn);
>>>>>>                             if ( m2pfn != gfn&&
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:52:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3cO-0002ae-DX; Thu, 16 Feb 2012 15:51:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1Ry3cN-0002aY-3P
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:51:35 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329407486!9760561!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23077 invoked from network); 16 Feb 2012 15:51:28 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE008.bigfish.com) (65.55.88.11)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Feb 2012 15:51:28 -0000
Received: from mail173-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 15:51:25 +0000
Received: from mail173-tx2 (localhost [127.0.0.1])	by
	mail173-tx2-R.bigfish.com (Postfix) with ESMTP id CEDB12E05D2;
	Thu, 16 Feb 2012 15:47:48 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VPS-5(zz103dK1432N98dK4015La1fflb922l853kzz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail173-tx2 (localhost.localdomain [127.0.0.1]) by mail173-tx2
	(MessageSwitch) id 1329407266623804_21191;
	Thu, 16 Feb 2012 15:47:46 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.240])	by
	mail173-tx2.bigfish.com (Postfix) with ESMTP id 8741240052;
	Thu, 16 Feb 2012 15:47:46 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server id
	14.1.225.23; Thu, 16 Feb 2012 15:47:44 +0000
X-WSS-ID: 0LZHT7G-02-B4P-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 2D4BAC808C;	Thu, 16 Feb 2012 09:47:39 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 16 Feb 2012 09:47:58 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 16 Feb 2012 09:47:42 -0600
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, 16 Feb 2012
	10:47:40 -0500
Received: from [165.204.15.175] (silber.osrc.amd.com [165.204.15.175])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6FF9749C34C; Thu, 16 Feb 2012
	15:47:39 +0000 (GMT)
Message-ID: <4F3D251B.7070209@amd.com>
Date: Thu, 16 Feb 2012 16:47:39 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <91f45eaceac6f38f9df39ed7d60c47a7.squirrel@webmail.lagarcavilla.org>
	<4F3BA067.4010303@amd.com>
	<21f5b643b779128cde513142ea14509f.squirrel@webmail.lagarcavilla.org>
	<4F3BD053.5070404@amd.com>
	<eff279cd5d0e5a7bf5777323b4473c4e.squirrel@webmail.lagarcavilla.org>
	<20120215170259.GA28101@ocelot.phlegethon.org>
In-Reply-To: <20120215170259.GA28101@ocelot.phlegethon.org>
X-OriginatorOrg: amd.com
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] RFC: AMD support for paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 15.02.2012 18:02, schrieb Tim Deegan:
> At 08:06 -0800 on 15 Feb (1329293205), Andres Lagar-Cavilla wrote:
>>> Where will p2m access bit be stored? Please note that bit 52 - bit 58
>>> for pte must be zero for p2m_ram_rw pages. For iommu pte, only bit 63
>>> and bit 1 - bit 8 are free to use if PR bit = 1.
>>
>> Wei,
>>
>> Why *must* bits 52-58 be zero for p2m_ram_rw pages? Or is it just the
>> current convention?
>>
>> I propose limiting p2m type to bits 52-55, and storing p2m access on bits
>> 56-58. So, p2m_ram_rw pages with a non-zero access would break the "must
>> be zero" requirement/convention.
>
> Eh, let's step back a bit from this.  The problem is that the IOMMU
> can't handle these bits being set, but the IOMMU can't handle paged-out
> or CoW memory either (because there's no way to cause the peripheral to
> retry a DMA that faulted).
>
> So can we just say that any VM that's going to use paging, sharing
> or access can't have a unified p2m and IOMMU table?  That's a bit ugly
> since the admin will have to make the choice, but it seems like the
> hardware is forcing us into it.

Seems true. Although iommuv2 support demand paging, it only works for 
guest OS process context. And we also need support from device side to 
do that.

>
> Maybe the sensible choice is to default to _not_ sharing p2m and IOMMU
> tables, and have thet be something an expert user can turn on (and which
> disables the other features)?

That looks good to me.

> Should we have a hypervisor-level interlock between PCI passthrough and
> paging/sharing/access anyway?  Doing both is unlikely to lead to happiness.

I think we should. DMA might result miserable errors when paging happens.

Thanks
Wei

> Tim.
>
>> Right now, without any considerations for paging, we're storing the p2m
>> type in bits 52-58 when PR=1. That p2m type can be non zero. p2m_ram_ro,
>> p2m_mmio_dm, p2m_logdirty, p2m_populate_on_demand are all par for the
>> course. Given your statement above, and table 14 in the IOMMU manual, how
>> is this even working? Or is it not working?
>>
>> Would a violation of these rules cause a VMEXIT_SHUTDOWN?
>>
>> Thanks a lot for the info!
>> Andres
>>>
>>> Thanks,
>>> Wei
>>>
>>>> An alternative to enabling mem_access on AMD processors will be to limit
>>>> the access types to 3 bits. This would force disabling support for two
>>>> modes. I'm inclined to disable two out of X, W and WX. I don't think
>>>> they
>>>> make sense without R permissions.
>>>> Thanks!
>>>> Andres
>>>>
>>>>>
>>>>> Thanks,
>>>>> Wei
>>>>>
>>>>>>
>>>>>> Finally, the triple fault. Maybe I'm missing something obvious.
>>>>>> Comments
>>>>>> welcome.
>>>>>>
>>>>>> Patch inline below, thanks!
>>>>>> Andres
>>>>>>
>>>>>> Enable AMD support for paging.
>>>>>>
>>>>>> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
>>>>>> Signed-off-by: Adin Scannell<adin@scannell.ca>
>>>>>>
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/mem_event.c
>>>>>> --- a/xen/arch/x86/mm/mem_event.c
>>>>>> +++ b/xen/arch/x86/mm/mem_event.c
>>>>>> @@ -537,10 +537,6 @@ int mem_event_domctl(struct domain *d, x
>>>>>>                 if ( !hap_enabled(d) )
>>>>>>                     break;
>>>>>>
>>>>>> -            /* Currently only EPT is supported */
>>>>>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>>>> -                break;
>>>>>> -
>>>>>>                 rc = -EXDEV;
>>>>>>                 /* Disallow paging in a PoD guest */
>>>>>>                 if ( p2m->pod.entry_count )
>>>>>> diff -r 25ca78889ed4 -r 10ca4e4293ce xen/arch/x86/mm/p2m-pt.c
>>>>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>>>>> @@ -53,6 +53,20 @@
>>>>>>     #define P2M_BASE_FLAGS \
>>>>>>             (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>>>>>>
>>>>>> +#ifdef __x86_64__
>>>>>> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The
>>>>>> 0xff..ff
>>>>>> + * value tramples over the higher-order bits used for flags (NX,
>>>>>> p2mt,
>>>>>> + * etc.) This happens for paging entries. Thus we do this clip/unclip
>>>>>> + * juggle for l1 entries only (no paging superpages!) */
>>>>>> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
>>>>>> +#define clipped_mfn(mfn)    ((mfn)&    ((1UL<<    EFF_MFN_WIDTH) - 1))
>>>>>> +#define unclip_mfn(mfn)     ((clipped_mfn((mfn)) == INVALID_MFN) ? \
>>>>>> +                                INVALID_MFN : (mfn))
>>>>>> +#else
>>>>>> +#define clipped_mfn(mfn)    (mfn)
>>>>>> +#define unclip_mfn(mfn)     (mfn)
>>>>>> +#endif /* __x86_64__ */
>>>>>> +
>>>>>>     static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t mfn)
>>>>>>     {
>>>>>>         unsigned long flags;
>>>>>> @@ -77,6 +91,9 @@ static unsigned long p2m_type_to_flags(p
>>>>>>         case p2m_invalid:
>>>>>>         case p2m_mmio_dm:
>>>>>>         case p2m_populate_on_demand:
>>>>>> +    case p2m_ram_paging_out:
>>>>>> +    case p2m_ram_paged:
>>>>>> +    case p2m_ram_paging_in:
>>>>>>         default:
>>>>>>             return flags;
>>>>>>         case p2m_ram_ro:
>>>>>> @@ -168,7 +185,7 @@ p2m_next_level(struct p2m_domain *p2m, m
>>>>>>                                           shift, max)) )
>>>>>>             return 0;
>>>>>>
>>>>>> -    /* PoD: Not present doesn't imply empty. */
>>>>>> +    /* PoD/paging: Not present doesn't imply empty. */
>>>>>>         if ( !l1e_get_flags(*p2m_entry) )
>>>>>>         {
>>>>>>             struct page_info *pg;
>>>>>> @@ -384,8 +401,9 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>                                        0, L1_PAGETABLE_ENTRIES);
>>>>>>             ASSERT(p2m_entry);
>>>>>>
>>>>>> -        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>>>>>> -            entry_content = l1e_from_pfn(mfn_x(mfn),
>>>>>> +        if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) ||
>>>>>> +             (p2mt == p2m_ram_paged) || (p2mt == p2m_ram_paging_in) )
>>>>>> +            entry_content = l1e_from_pfn(clipped_mfn(mfn_x(mfn)),
>>>>>>                                              p2m_type_to_flags(p2mt,
>>>>>> mfn));
>>>>>>             else
>>>>>>                 entry_content = l1e_empty();
>>>>>> @@ -393,7 +411,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
>>>>>>             if ( entry_content.l1 != 0 )
>>>>>>             {
>>>>>>                 p2m_add_iommu_flags(&entry_content, 0,
>>>>>> iommu_pte_flags);
>>>>>> -            old_mfn = l1e_get_pfn(*p2m_entry);
>>>>>> +            old_mfn = unclip_mfn(l1e_get_pfn(*p2m_entry));
>>>>>>             }
>>>>>>             /* level 1 entry */
>>>>>>             p2m->write_p2m_entry(p2m, gfn, p2m_entry, table_mfn,
>>>>>> entry_content, 1);
>>>>>> @@ -615,11 +633,12 @@ pod_retry_l1:
>>>>>>                                sizeof(l1e));
>>>>>>
>>>>>>         if ( ret == 0 ) {
>>>>>> +        unsigned long l1e_mfn = unclip_mfn(l1e_get_pfn(l1e));
>>>>>>             p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
>>>>>> -        ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt));
>>>>>> +        ASSERT( (l1e_mfn != INVALID_MFN || !p2m_is_ram(p2mt)) ||
>>>>>> +                (l1e_mfn == INVALID_MFN&&    p2m_is_paging(p2mt)) );
>>>>>>
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(l1e))
>>>>>> -             == p2m_populate_on_demand )
>>>>>> +        if ( p2mt == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 /* The read has succeeded, so we know that the mapping
>>>>>>                  * exits at this point.  */
>>>>>> @@ -641,7 +660,7 @@ pod_retry_l1:
>>>>>>             }
>>>>>>
>>>>>>             if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
>>>>>> -            mfn = _mfn(l1e_get_pfn(l1e));
>>>>>> +            mfn = _mfn(l1e_mfn);
>>>>>>             else
>>>>>>                 /* XXX see above */
>>>>>>                 p2mt = p2m_mmio_dm;
>>>>>> @@ -783,18 +802,26 @@ pod_retry_l2:
>>>>>>     pod_retry_l1:
>>>>>>         if ( (l1e_get_flags(*l1e)&    _PAGE_PRESENT) == 0 )
>>>>>>         {
>>>>>> +        p2m_type_t l1t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>>             /* PoD: Try to populate */
>>>>>> -        if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
>>>>>> p2m_populate_on_demand )
>>>>>> +        if ( l1t == p2m_populate_on_demand )
>>>>>>             {
>>>>>>                 if ( q != p2m_query ) {
>>>>>>                     if ( !p2m_pod_demand_populate(p2m, gfn,
>>>>>> PAGE_ORDER_4K,
>>>>>> q) )
>>>>>>                         goto pod_retry_l1;
>>>>>>                 } else
>>>>>>                     *t = p2m_populate_on_demand;
>>>>>> +        } else {
>>>>>> +            if ( p2m_is_paging(l1t) )
>>>>>> +            {
>>>>>> +                *t = l1t;
>>>>>> +                /* No need to unclip due to check below */
>>>>>> +                mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>> +            }
>>>>>>             }
>>>>>>
>>>>>>             unmap_domain_page(l1e);
>>>>>> -        return _mfn(INVALID_MFN);
>>>>>> +        return (l1t == p2m_ram_paging_out) ? mfn : _mfn(INVALID_MFN);
>>>>>>         }
>>>>>>         mfn = _mfn(l1e_get_pfn(*l1e));
>>>>>>         *t = p2m_flags_to_type(l1e_get_flags(*l1e));
>>>>>> @@ -914,7 +941,7 @@ static void p2m_change_type_global(struc
>>>>>>                         flags = l1e_get_flags(l1e[i1]);
>>>>>>                         if ( p2m_flags_to_type(flags) != ot )
>>>>>>                             continue;
>>>>>> -                    mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                    mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                         gfn = i1 + (i2 + (i3
>>>>>>     #if CONFIG_PAGING_LEVELS>= 4
>>>>>>     					+ (i4 * L3_PAGETABLE_ENTRIES)
>>>>>> @@ -923,7 +950,7 @@ static void p2m_change_type_global(struc
>>>>>>                                * L2_PAGETABLE_ENTRIES) *
>>>>>> L1_PAGETABLE_ENTRIES;
>>>>>>                         /* create a new 1le entry with the new type */
>>>>>>                         flags = p2m_type_to_flags(nt, _mfn(mfn));
>>>>>> -                    l1e_content = l1e_from_pfn(mfn, flags);
>>>>>> +                    l1e_content = l1e_from_pfn(clipped_mfn(mfn),
>>>>>> flags);
>>>>>>                         p2m->write_p2m_entry(p2m, gfn,&l1e[i1],
>>>>>>                                              l1mfn, l1e_content, 1);
>>>>>>                     }
>>>>>> @@ -1073,7 +1100,7 @@ long p2m_pt_audit_p2m(struct p2m_domain
>>>>>>                                     entry_count++;
>>>>>>                                 continue;
>>>>>>                             }
>>>>>> -                        mfn = l1e_get_pfn(l1e[i1]);
>>>>>> +                        mfn = unclip_mfn(l1e_get_pfn(l1e[i1]));
>>>>>>                             ASSERT(mfn_valid(_mfn(mfn)));
>>>>>>                             m2pfn = get_gpfn_from_mfn(mfn);
>>>>>>                             if ( m2pfn != gfn&&
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:59:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15: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.xensource.com>)
	id 1Ry3js-0002rb-LK; Thu, 16 Feb 2012 15:59:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry3jr-0002rV-1p
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:59:19 +0000
Received: from [85.158.139.83:43502] by server-1.bemta-5.messagelabs.com id
	2F/87-28458-6D72D3F4; Thu, 16 Feb 2012 15:59:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329407957!15385760!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 419 invoked from network); 16 Feb 2012 15:59:17 -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; 16 Feb 2012 15:59:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry3jo-000BWc-Ae; Thu, 16 Feb 2012 15:59:16 +0000
Date: Thu, 16 Feb 2012 15:59:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216155916.GD41163@ocelot.phlegethon.org>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] x86/mm: Four fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:42 -0500 on 15 Feb (1329345744), Andres Lagar-Cavilla wrote:
> In this series we post four patches with bugfixes to p2m, hap, paging and
> sharing code:
> 
> - Make a few asserts on shared pages type and counts more accurate
>  (this time done right, hopefully!)

Nope, sorry! :)  I fixed the tests up and applied it; please check that
it still does what you wanted.

> - Bugfix interactions between the balloon and the paging and sharing
>  subsystems. Posted a week ago, probably slipped through the cracks.
> - Added a missing sanity check for sharing/paging/access memops.
> - Fix vmx_load_pdptrs to crash the guest instead of the host in the
>  presence of paged out cr3's.

This needed a minor adjustment to a printk format for 32-bit builds. 

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

All applied, thanks.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 15:59:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 15: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.xensource.com>)
	id 1Ry3js-0002rb-LK; Thu, 16 Feb 2012 15:59:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry3jr-0002rV-1p
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 15:59:19 +0000
Received: from [85.158.139.83:43502] by server-1.bemta-5.messagelabs.com id
	2F/87-28458-6D72D3F4; Thu, 16 Feb 2012 15:59:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329407957!15385760!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 419 invoked from network); 16 Feb 2012 15:59:17 -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; 16 Feb 2012 15:59:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry3jo-000BWc-Ae; Thu, 16 Feb 2012 15:59:16 +0000
Date: Thu, 16 Feb 2012 15:59:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216155916.GD41163@ocelot.phlegethon.org>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329363744@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] x86/mm: Four fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:42 -0500 on 15 Feb (1329345744), Andres Lagar-Cavilla wrote:
> In this series we post four patches with bugfixes to p2m, hap, paging and
> sharing code:
> 
> - Make a few asserts on shared pages type and counts more accurate
>  (this time done right, hopefully!)

Nope, sorry! :)  I fixed the tests up and applied it; please check that
it still does what you wanted.

> - Bugfix interactions between the balloon and the paging and sharing
>  subsystems. Posted a week ago, probably slipped through the cracks.
> - Added a missing sanity check for sharing/paging/access memops.
> - Fix vmx_load_pdptrs to crash the guest instead of the host in the
>  presence of paged out cr3's.

This needed a minor adjustment to a printk format for 32-bit builds. 

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

All applied, thanks.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3sp-0003T2-U4; Thu, 16 Feb 2012 16:08:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry3so-0003Sx-D8
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:08:34 +0000
Received: from [85.158.139.83:21814] by server-4.bemta-5.messagelabs.com id
	E0/82-10788-10A2D3F4; Thu, 16 Feb 2012 16:08:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329408512!15376528!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5500 invoked from network); 16 Feb 2012 16:08:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:08:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry3sh-000BYO-7o; Thu, 16 Feb 2012 16:08:27 +0000
Date: Thu, 16 Feb 2012 16:08:27 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120216160827.GE41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
	<4F3D2F9C020000780007378E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3D2F9C020000780007378E@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	andres@lagarcavilla.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
	domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:32 +0000 on 16 Feb (1329406348), Jan Beulich wrote:
> >>> On 16.02.12 at 15:45, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> > But I've seen squeezed set criminally low max_pages value (i.e. 256).
> > Granted, this is squeezed's problem, but shouldn't some sanity checking be
> > wired into the hypervisor? Why should we even allow max_pages < tot_pages?
> 
> The only lower boundary that the hypervisor could (perhaps should)
> enforce is that of not being able to guarantee guest forward progress:
> On x86, up to 2 text pages plus up to 4 data pages, times the number
> of page table levels (i.e. 24 pages on 64-bit).

OT: ISTR the actual number of memory accesses needed to complete one x86
instruction is much crazier than that (e.g. a memory-to-memory copy that
faults on the second page of the destination, pushing most of a stack
frame before hitting the SS limit and double-faulting via a task gate,
&c).  We did try to count it exactly for the shadow pagetables once but
gave up and wildly overestimated instead, (because perf near the limit
would have been too awful anyway).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3sp-0003T2-U4; Thu, 16 Feb 2012 16:08:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry3so-0003Sx-D8
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:08:34 +0000
Received: from [85.158.139.83:21814] by server-4.bemta-5.messagelabs.com id
	E0/82-10788-10A2D3F4; Thu, 16 Feb 2012 16:08:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329408512!15376528!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5500 invoked from network); 16 Feb 2012 16:08:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:08:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry3sh-000BYO-7o; Thu, 16 Feb 2012 16:08:27 +0000
Date: Thu, 16 Feb 2012 16:08:27 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120216160827.GE41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
	<4F3D2F9C020000780007378E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3D2F9C020000780007378E@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	andres@lagarcavilla.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
	domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:32 +0000 on 16 Feb (1329406348), Jan Beulich wrote:
> >>> On 16.02.12 at 15:45, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> > But I've seen squeezed set criminally low max_pages value (i.e. 256).
> > Granted, this is squeezed's problem, but shouldn't some sanity checking be
> > wired into the hypervisor? Why should we even allow max_pages < tot_pages?
> 
> The only lower boundary that the hypervisor could (perhaps should)
> enforce is that of not being able to guarantee guest forward progress:
> On x86, up to 2 text pages plus up to 4 data pages, times the number
> of page table levels (i.e. 24 pages on 64-bit).

OT: ISTR the actual number of memory accesses needed to complete one x86
instruction is much crazier than that (e.g. a memory-to-memory copy that
faults on the second page of the destination, pushing most of a stack
frame before hitting the SS limit and double-faulting via a task gate,
&c).  We did try to count it exactly for the shadow pagetables once but
gave up and wildly overestimated instead, (because perf near the limit
would have been too awful anyway).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3vY-0003Yl-Gc; Thu, 16 Feb 2012 16:11:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry3vX-0003YX-8l
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:11:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329408675!11827089!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5715 invoked from network); 16 Feb 2012 16:11:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:11:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry3vO-000BZL-Mq; Thu, 16 Feb 2012 16:11:14 +0000
Date: Thu, 16 Feb 2012 16:11:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216161114.GF41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 4] x86/mm: Allow to not sleep on mem
	event ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:57 -0500 on 15 Feb (1329346625), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_event.c     |   5 +++--
>  xen/include/asm-x86/mem_event.h |  30 +++++++++++++++++++++++++-----
>  2 files changed, 28 insertions(+), 7 deletions(-)
> 
> 
> Under extreme congestion conditions, generating a mem event may put the vcpu to
> sleep on a wait queue if the ring is full. This is generally desirable, although
> fairly convoluted to work with, since sleeping on a wait queue requires a
> non-atomic context (i.e. no locks held).
> 
> Introduce an allow_sleep flag to make this optional. The API remains such that
> all current callers set allow_sleep to true and thus will sleep if necessary.
> 
> The end-use is for cases in which loss of guest mem events is tolerable. One
> such consumer to be added later is the unsharing code under ENOMEM conditions.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Hmm.  This interface is getting a bit twisty now, but assuming the
patches that use it are OK, then Ack.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry3vY-0003Yl-Gc; Thu, 16 Feb 2012 16:11:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Ry3vX-0003YX-8l
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:11:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329408675!11827089!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5715 invoked from network); 16 Feb 2012 16:11:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:11:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry3vO-000BZL-Mq; Thu, 16 Feb 2012 16:11:14 +0000
Date: Thu, 16 Feb 2012 16:11:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216161114.GF41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 4] x86/mm: Allow to not sleep on mem
	event ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:57 -0500 on 15 Feb (1329346625), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_event.c     |   5 +++--
>  xen/include/asm-x86/mem_event.h |  30 +++++++++++++++++++++++++-----
>  2 files changed, 28 insertions(+), 7 deletions(-)
> 
> 
> Under extreme congestion conditions, generating a mem event may put the vcpu to
> sleep on a wait queue if the ring is full. This is generally desirable, although
> fairly convoluted to work with, since sleeping on a wait queue requires a
> non-atomic context (i.e. no locks held).
> 
> Introduce an allow_sleep flag to make this optional. The API remains such that
> all current callers set allow_sleep to true and thus will sleep if necessary.
> 
> The end-use is for cases in which loss of guest mem events is tolerable. One
> such consumer to be added later is the unsharing code under ENOMEM conditions.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Hmm.  This interface is getting a bit twisty now, but assuming the
patches that use it are OK, then Ack.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:19:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry43D-0003oo-En; Thu, 16 Feb 2012 16:19:19 +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 1Ry43C-0003og-4S
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:19:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329409128!53224227!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21445 invoked from network); 16 Feb 2012 16:18:48 -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; 16 Feb 2012 16:18:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry435-000BaP-I1; Thu, 16 Feb 2012 16:19:11 +0000
Date: Thu, 16 Feb 2012 16:19:11 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216161911.GG41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 4] Memory sharing: better handling of
	ENOMEM while unsharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:57 -0500 on 15 Feb (1329346626), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
>  xen/arch/x86/mm.c                 |   8 +++--
>  xen/arch/x86/mm/mem_sharing.c     |  52 ++++++++++++++++++++++++---------------
>  xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
>  xen/common/grant_table.c          |  11 ++++---
>  xen/common/memory.c               |   1 +
>  xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
>  7 files changed, 94 insertions(+), 31 deletions(-)
> 
> 
> If unsharing fails with ENOMEM, we were:
>  - leaving the list of gfns backed by the shared page in an inconsistent state
>  - cycling forever on the hap page fault handler.
>  - Attempting to produce a mem event (which could sleep on a wait queue)
>    while holding locks.
>  - Not checking, for all callers, that unshare could have indeed failed.
> 
> Fix bugs above, and sanitize callers to place a ring event in an unlocked
> context, or without requiring to go to sleep on a wait queue.
> 
> A note on the rationale for unshare error handling:
>  1. Unshare can only fail with ENOMEM. Any other error conditions BUG_ON()'s

Please enforce this in the code -- either the function should just
return success/failure or (better, I think) the caller should ASSERT
that it doesn't see any other error codes.

>  2. We notify a potential dom0 helper through a mem_event ring. But we
>     allow the notification to not go to sleep. If the event ring is full
>     of ENOMEM warnings, then the helper will already have been kicked enough.

Could we just keep a count (or flag) to remind us that an ENOMEM is in
the pipe and avoid having an exception to the waiting rules?

>  3. We cannot "just" go to sleep until the unshare is resolved, because we
>     might be buried deep into locks (e.g. something -> copy_to_user ->
>     __hvm_copy)
>  4. So, we make sure we:
>     4.1. return an error
>     4.2. do not corrupt shared memory
>     4.3. do not corrupt guest memory
>     4.4. let the guest deal with the error if propagation will reach that far

Yep, the other cleanups look good to me. 

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:19:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry43D-0003oo-En; Thu, 16 Feb 2012 16:19:19 +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 1Ry43C-0003og-4S
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:19:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329409128!53224227!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21445 invoked from network); 16 Feb 2012 16:18:48 -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; 16 Feb 2012 16:18:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Ry435-000BaP-I1; Thu, 16 Feb 2012 16:19:11 +0000
Date: Thu, 16 Feb 2012 16:19:11 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120216161911.GG41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 4] Memory sharing: better handling of
	ENOMEM while unsharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:57 -0500 on 15 Feb (1329346626), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
>  xen/arch/x86/mm.c                 |   8 +++--
>  xen/arch/x86/mm/mem_sharing.c     |  52 ++++++++++++++++++++++++---------------
>  xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
>  xen/common/grant_table.c          |  11 ++++---
>  xen/common/memory.c               |   1 +
>  xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
>  7 files changed, 94 insertions(+), 31 deletions(-)
> 
> 
> If unsharing fails with ENOMEM, we were:
>  - leaving the list of gfns backed by the shared page in an inconsistent state
>  - cycling forever on the hap page fault handler.
>  - Attempting to produce a mem event (which could sleep on a wait queue)
>    while holding locks.
>  - Not checking, for all callers, that unshare could have indeed failed.
> 
> Fix bugs above, and sanitize callers to place a ring event in an unlocked
> context, or without requiring to go to sleep on a wait queue.
> 
> A note on the rationale for unshare error handling:
>  1. Unshare can only fail with ENOMEM. Any other error conditions BUG_ON()'s

Please enforce this in the code -- either the function should just
return success/failure or (better, I think) the caller should ASSERT
that it doesn't see any other error codes.

>  2. We notify a potential dom0 helper through a mem_event ring. But we
>     allow the notification to not go to sleep. If the event ring is full
>     of ENOMEM warnings, then the helper will already have been kicked enough.

Could we just keep a count (or flag) to remind us that an ENOMEM is in
the pipe and avoid having an exception to the waiting rules?

>  3. We cannot "just" go to sleep until the unshare is resolved, because we
>     might be buried deep into locks (e.g. something -> copy_to_user ->
>     __hvm_copy)
>  4. So, we make sure we:
>     4.1. return an error
>     4.2. do not corrupt shared memory
>     4.3. do not corrupt guest memory
>     4.4. let the guest deal with the error if propagation will reach that far

Yep, the other cleanups look good to me. 

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:27:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry4An-0003yf-GC; Thu, 16 Feb 2012 16:27:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ry4Al-0003ya-H6
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 16:27:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329409620!15103744!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5029 invoked from network); 16 Feb 2012 16:27:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:27:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 16:27:00 +0000
Message-Id: <4F3D3C6202000078000737C6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 16:26:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
	<1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
	<4F3D2D28020000780007377D@nat28.tlf.novell.com>
	<06a5548b6f1f6c2b7fa0a1e2bc11115f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <06a5548b6f1f6c2b7fa0a1e2bc11115f.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 16:34, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>>> wrote:
>>>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>>>> wrote:
>>>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>>>> threshold.
>>>>
>>>> In this patch, which didn't make it to my inbox yet, you will want to
>>>> change this
>>>>
>>>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>>>
>>>> to
>>>>
>>>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>>>
>>>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>>>> being just 'long', would get significant bits shifted out.
>>>>
>>>> I'm further wondering whether the default value shouldn't be set
>>>> dynamically based on available memory and/or taking into account
>>>> an eventual dom0_mem= option.
>>>
>>> I can cap or get rid of the threshold (and the virq) if it doesn't make
>>> sense with respect to total memory. I'm not sure about integrating
>>> dom0_mem, since dom0's footprint is also a quantity manipulated by the
>>> receiver of the virq.
>>
>> No, dom0_mem= is only specifying the starting value, and the case
>> that would be of possibly interest is that of having a negative amount
>> specified.
> 
> Sorry, not following entirely. The negative quantity you refer to would be
> dom0_mem or the low mem virq threshold? Additional checks pertaining only
> to dom0_mem, not in relation to this threshold, would most likely go on a
> separate patch.

Consider someone useing "dom0_mem=-64M" - that'd make your
code raise the vIRQ immediately, even though the admin decided
that leaving 64M inside Xen is okay at boot time at least.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:27:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry4An-0003yf-GC; Thu, 16 Feb 2012 16:27:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ry4Al-0003ya-H6
	for xen-devel@lists.xen.org; Thu, 16 Feb 2012 16:27:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329409620!15103744!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5029 invoked from network); 16 Feb 2012 16:27:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:27:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 16:27:00 +0000
Message-Id: <4F3D3C6202000078000737C6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 16:26:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<4F3CDAF80200007800073601@nat28.tlf.novell.com>
	<1e27162d41edf2d71660cc29471d153f.squirrel@webmail.lagarcavilla.org>
	<4F3D2D28020000780007377D@nat28.tlf.novell.com>
	<06a5548b6f1f6c2b7fa0a1e2bc11115f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <06a5548b6f1f6c2b7fa0a1e2bc11115f.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel <xen-devel@lists.xen.org>, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] Handling of (some) low memory
 conditions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 16:34, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 16.02.12 at 15:40, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>>> wrote:
>>>>>>> On 16.02.12 at 04:57, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>>>> wrote:
>>>>> - Add a VIRQ that the hypervisor can emit when reaching a low memory
>>>>> threshold.
>>>>
>>>> In this patch, which didn't make it to my inbox yet, you will want to
>>>> change this
>>>>
>>>> +    if ( (total_avail_pages << PAGE_SHIFT) <= opt_low_mem_virq )
>>>>
>>>> to
>>>>
>>>>     if ( total_avail_pages <= PFN_DOWN(opt_low_mem_virq) )
>>>>
>>>> to avoid the case (on 32-bit hypervisors) where total_avail_pages,
>>>> being just 'long', would get significant bits shifted out.
>>>>
>>>> I'm further wondering whether the default value shouldn't be set
>>>> dynamically based on available memory and/or taking into account
>>>> an eventual dom0_mem= option.
>>>
>>> I can cap or get rid of the threshold (and the virq) if it doesn't make
>>> sense with respect to total memory. I'm not sure about integrating
>>> dom0_mem, since dom0's footprint is also a quantity manipulated by the
>>> receiver of the virq.
>>
>> No, dom0_mem= is only specifying the starting value, and the case
>> that would be of possibly interest is that of having a negative amount
>> specified.
> 
> Sorry, not following entirely. The negative quantity you refer to would be
> dom0_mem or the low mem virq threshold? Additional checks pertaining only
> to dom0_mem, not in relation to this threshold, would most likely go on a
> separate patch.

Consider someone useing "dom0_mem=-64M" - that'd make your
code raise the vIRQ immediately, even though the admin decided
that leaving 64M inside Xen is okay at boot time at least.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:45:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16: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.xensource.com>)
	id 1Ry4Rn-00049q-4b; Thu, 16 Feb 2012 16:44:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ry4Rl-00049l-Gf
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:44:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329410607!63164254!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29093 invoked from network); 16 Feb 2012 16:43:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:43:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 16:44:39 +0000
Message-Id: <4F3D408802000078000737D6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 16:44:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
	<4F3D2F9C020000780007378E@nat28.tlf.novell.com>
	<20120216160827.GE41163@ocelot.phlegethon.org>
In-Reply-To: <20120216160827.GE41163@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	andres@lagarcavilla.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 17:08, Tim Deegan <tim@xen.org> wrote:
> At 15:32 +0000 on 16 Feb (1329406348), Jan Beulich wrote:
>> >>> On 16.02.12 at 15:45, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>> > But I've seen squeezed set criminally low max_pages value (i.e. 256).
>> > Granted, this is squeezed's problem, but shouldn't some sanity checking be
>> > wired into the hypervisor? Why should we even allow max_pages < tot_pages?
>> 
>> The only lower boundary that the hypervisor could (perhaps should)
>> enforce is that of not being able to guarantee guest forward progress:
>> On x86, up to 2 text pages plus up to 4 data pages, times the number
>> of page table levels (i.e. 24 pages on 64-bit).
> 
> OT: ISTR the actual number of memory accesses needed to complete one x86
> instruction is much crazier than that (e.g. a memory-to-memory copy that
> faults on the second page of the destination, pushing most of a stack
> frame before hitting the SS limit and double-faulting via a task gate,
> &c).  We did try to count it exactly for the shadow pagetables once but
> gave up and wildly overestimated instead, (because perf near the limit
> would have been too awful anyway).

Hmm, indeed: When a page fault occurs, you don't need the text or
data pages the original instruction referenced anymore. Instead, you
now need up to 2 IDT pages, up to 4 GDT pages, and up to 2 stack
pages. So yes, the number is higher (but not that much). An exception
going through a task gate is of course much uglier, but luckily that
doesn't need to be considered at least for x86-64.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:45:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16: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.xensource.com>)
	id 1Ry4Rn-00049q-4b; Thu, 16 Feb 2012 16:44:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ry4Rl-00049l-Gf
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:44:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329410607!63164254!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29093 invoked from network); 16 Feb 2012 16:43:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 16:43:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 16 Feb 2012 16:44:39 +0000
Message-Id: <4F3D408802000078000737D6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 16 Feb 2012 16:44:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<11fd4e0a1e1a76ca3bc1.1329364624@xdev.gridcentric.ca>
	<20120216102014.GA40020@ocelot.phlegethon.org>
	<5612c7c996f87bb6a0e864258766e926.squirrel@webmail.lagarcavilla.org>
	<4F3D2F9C020000780007378E@nat28.tlf.novell.com>
	<20120216160827.GE41163@ocelot.phlegethon.org>
In-Reply-To: <20120216160827.GE41163@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	andres@lagarcavilla.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Prevent low values of max_pages for
 domains doing sharing or paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.02.12 at 17:08, Tim Deegan <tim@xen.org> wrote:
> At 15:32 +0000 on 16 Feb (1329406348), Jan Beulich wrote:
>> >>> On 16.02.12 at 15:45, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>> > But I've seen squeezed set criminally low max_pages value (i.e. 256).
>> > Granted, this is squeezed's problem, but shouldn't some sanity checking be
>> > wired into the hypervisor? Why should we even allow max_pages < tot_pages?
>> 
>> The only lower boundary that the hypervisor could (perhaps should)
>> enforce is that of not being able to guarantee guest forward progress:
>> On x86, up to 2 text pages plus up to 4 data pages, times the number
>> of page table levels (i.e. 24 pages on 64-bit).
> 
> OT: ISTR the actual number of memory accesses needed to complete one x86
> instruction is much crazier than that (e.g. a memory-to-memory copy that
> faults on the second page of the destination, pushing most of a stack
> frame before hitting the SS limit and double-faulting via a task gate,
> &c).  We did try to count it exactly for the shadow pagetables once but
> gave up and wildly overestimated instead, (because perf near the limit
> would have been too awful anyway).

Hmm, indeed: When a page fault occurs, you don't need the text or
data pages the original instruction referenced anymore. Instead, you
now need up to 2 IDT pages, up to 4 GDT pages, and up to 2 stack
pages. So yes, the number is higher (but not that much). An exception
going through a task gate is of course much uglier, but luckily that
doesn't need to be considered at least for x86-64.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:50:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16: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.xensource.com>)
	id 1Ry4Wm-0004KJ-SU; Thu, 16 Feb 2012 16:49:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ry4Wm-0004KC-4s
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:49:52 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329410964!53228777!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26646 invoked from network); 16 Feb 2012 16:49:26 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 16:49:26 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1GGnk5C011435
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 16 Feb 2012 08:49:47 -0800
Received: by bkcjg15 with SMTP id jg15so3728273bkc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:49:44 -0800 (PST)
Received: by 10.204.156.69 with SMTP id v5mr1725140bkw.103.1329410984416; Thu,
	16 Feb 2012 08:49:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Thu, 16 Feb 2012 08:49:04 -0800 (PST)
In-Reply-To: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
References: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 08:49:04 -0800
Message-ID: <CAP8mzPNRqxcCgj93NWugc7QaZK2XZphVsVfz8jY-0Rbrzc5wbw@mail.gmail.com>
To: =?UTF-8?B?5p2O5pil5aWH?= <yzt356@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Where's the entry code of backup host in Remus?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1793241174476344869=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1793241174476344869==
Content-Type: multipart/alternative; boundary=0015175cb67a7c948704b9179d1b

--0015175cb67a7c948704b9179d1b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Look for the entry point into the live migration code, on the receiver host=
.

Start with tools/python/xen/xend/XendCheckpoint.py
 def restore(xd, fd, dominfo =3D None, paused =3D False, relocating =3D Fal=
se)
  --forks off xc_restore and waits for it to complete.
  ------xc_restore calls xc_domain_restore


hope that helps.

cheers
shriram

On Thu, Feb 16, 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 <Chunqi Li> <y=
zt356@gmail.com> wrote:

> Hi all,
> I'm reading Remus part of Xen 4.x code and now I can find the entry code
> of Primary host, which is located in tools/remus directory. But I cannot
> find the entry code of backup host. Which codes will the backup host
> execute when the primary code send header of a VM? I can only find some
> codes are executed in tools/libxc/xc_domain_restore.c, which restores the
> backup VM as soon as the Primary VM stops. When the backup
> host synchronizing the state of primary VM (including machine state, memo=
ry
> state and disk state), which part of code will be execute?
>
> Thanks.
>
> --
> Regards, Chunqi Li
> Department of Computer Science
> School of EECS
> Peking University
> Beijing, China
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

--0015175cb67a7c948704b9179d1b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Look for the entry point into the live migration code, on the receiver host=
.<br><br>Start with tools/python/xen/xend/XendCheckpoint.py<br>=C2=A0def re=
store(xd, fd, dominfo =3D None, paused =3D False, relocating =3D False)<br>=
=C2=A0 --forks off xc_restore and waits for it to complete.<br>

=C2=A0 ------xc_restore calls xc_domain_restore<br><br><br>hope that helps.=
<br><br>cheers<br>shriram<br><br><div class=3D"gmail_quote">On Thu, Feb 16,=
 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 &lt;Chunqi Li&gt; <span dir=
=3D"ltr">&lt;<a href=3D"mailto:yzt356@gmail.com">yzt356@gmail.com</a>&gt;</=
span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi all,<div>I&#39;m reading Remus part of Xe=
n 4.x code and now I can find the entry code of Primary host, which is loca=
ted in tools/remus directory. But I cannot find the entry code of backup ho=
st. Which codes will the backup host execute when the primary code send hea=
der of a VM? I can only find some codes are executed in tools/libxc/xc_doma=
in_restore.c, which restores the backup VM as soon as the Primary VM stops.=
 When the backup host=C2=A0synchronizing the state of primary VM (including=
 machine state, memory state and disk state), which part of code will be ex=
ecute?</div>


<div><br></div><div>Thanks.</div><span class=3D"HOEnZb"><font color=3D"#888=
888"><div><br>-- <br>Regards, Chunqi Li<br>Department of Computer Science<b=
r>School of EECS<br>Peking University<br>Beijing, China<br>
</div>
</font></span><br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br>

--0015175cb67a7c948704b9179d1b--


--===============1793241174476344869==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1793241174476344869==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:50:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16: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.xensource.com>)
	id 1Ry4Wm-0004KJ-SU; Thu, 16 Feb 2012 16:49:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ry4Wm-0004KC-4s
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:49:52 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329410964!53228777!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26646 invoked from network); 16 Feb 2012 16:49:26 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 16:49:26 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1GGnk5C011435
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 16 Feb 2012 08:49:47 -0800
Received: by bkcjg15 with SMTP id jg15so3728273bkc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:49:44 -0800 (PST)
Received: by 10.204.156.69 with SMTP id v5mr1725140bkw.103.1329410984416; Thu,
	16 Feb 2012 08:49:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Thu, 16 Feb 2012 08:49:04 -0800 (PST)
In-Reply-To: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
References: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 08:49:04 -0800
Message-ID: <CAP8mzPNRqxcCgj93NWugc7QaZK2XZphVsVfz8jY-0Rbrzc5wbw@mail.gmail.com>
To: =?UTF-8?B?5p2O5pil5aWH?= <yzt356@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Where's the entry code of backup host in Remus?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1793241174476344869=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1793241174476344869==
Content-Type: multipart/alternative; boundary=0015175cb67a7c948704b9179d1b

--0015175cb67a7c948704b9179d1b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Look for the entry point into the live migration code, on the receiver host=
.

Start with tools/python/xen/xend/XendCheckpoint.py
 def restore(xd, fd, dominfo =3D None, paused =3D False, relocating =3D Fal=
se)
  --forks off xc_restore and waits for it to complete.
  ------xc_restore calls xc_domain_restore


hope that helps.

cheers
shriram

On Thu, Feb 16, 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 <Chunqi Li> <y=
zt356@gmail.com> wrote:

> Hi all,
> I'm reading Remus part of Xen 4.x code and now I can find the entry code
> of Primary host, which is located in tools/remus directory. But I cannot
> find the entry code of backup host. Which codes will the backup host
> execute when the primary code send header of a VM? I can only find some
> codes are executed in tools/libxc/xc_domain_restore.c, which restores the
> backup VM as soon as the Primary VM stops. When the backup
> host synchronizing the state of primary VM (including machine state, memo=
ry
> state and disk state), which part of code will be execute?
>
> Thanks.
>
> --
> Regards, Chunqi Li
> Department of Computer Science
> School of EECS
> Peking University
> Beijing, China
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

--0015175cb67a7c948704b9179d1b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Look for the entry point into the live migration code, on the receiver host=
.<br><br>Start with tools/python/xen/xend/XendCheckpoint.py<br>=C2=A0def re=
store(xd, fd, dominfo =3D None, paused =3D False, relocating =3D False)<br>=
=C2=A0 --forks off xc_restore and waits for it to complete.<br>

=C2=A0 ------xc_restore calls xc_domain_restore<br><br><br>hope that helps.=
<br><br>cheers<br>shriram<br><br><div class=3D"gmail_quote">On Thu, Feb 16,=
 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 &lt;Chunqi Li&gt; <span dir=
=3D"ltr">&lt;<a href=3D"mailto:yzt356@gmail.com">yzt356@gmail.com</a>&gt;</=
span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi all,<div>I&#39;m reading Remus part of Xe=
n 4.x code and now I can find the entry code of Primary host, which is loca=
ted in tools/remus directory. But I cannot find the entry code of backup ho=
st. Which codes will the backup host execute when the primary code send hea=
der of a VM? I can only find some codes are executed in tools/libxc/xc_doma=
in_restore.c, which restores the backup VM as soon as the Primary VM stops.=
 When the backup host=C2=A0synchronizing the state of primary VM (including=
 machine state, memory state and disk state), which part of code will be ex=
ecute?</div>


<div><br></div><div>Thanks.</div><span class=3D"HOEnZb"><font color=3D"#888=
888"><div><br>-- <br>Regards, Chunqi Li<br>Department of Computer Science<b=
r>School of EECS<br>Peking University<br>Beijing, China<br>
</div>
</font></span><br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br>

--0015175cb67a7c948704b9179d1b--


--===============1793241174476344869==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1793241174476344869==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:56:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry4cb-0004V6-ML; Thu, 16 Feb 2012 16:55:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ry4ca-0004Uz-Hd
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:55:52 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329411343!9772737!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 490 invoked from network); 16 Feb 2012 16:55:45 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 16:55:45 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1GGteMx013093
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 16 Feb 2012 08:55:41 -0800
Received: by bkcjg15 with SMTP id jg15so3742238bkc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:55:39 -0800 (PST)
Received: by 10.204.152.88 with SMTP id f24mr1790210bkw.31.1329411339334; Thu,
	16 Feb 2012 08:55:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Thu, 16 Feb 2012 08:54:59 -0800 (PST)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 08:54:59 -0800
Message-ID: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen-unstable - Build fail
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6597912299562301884=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6597912299562301884==
Content-Type: multipart/alternative; boundary=0015175d009ea4348304b917b292

--0015175d009ea4348304b917b292
Content-Type: text/plain; charset=ISO-8859-1

This is from the latest c/s in xen-unstable (24818)

make -C etherboot all
make[6]: Entering directory
`/home/source/xen-unstable.hg/tools/firmware/etherboot'
rm -rf ipxe
gzip -dc ipxe.tar.gz | tar xf -
for i in $(cat patches/series) ; do                 \
        patch -d ipxe -p1 --quiet <patches/$i || exit 1 ; \
    done
1 out of 4 hunks FAILED -- saving rejects to file
src/arch/i386/prefix/romprefix.S.rej
make[6]: *** [ipxe/src/arch/i386/Makefile] Error 1
make[6]: Leaving directory
`/home/source/xen-unstable.hg/tools/firmware/etherboot'
make[5]: *** [subdir-all-etherboot] Error 2
make[5]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/source/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/source/xen-unstable.hg/tools'
make: *** [install-tools] Error 2

--0015175d009ea4348304b917b292
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is from the latest c/s in xen-unstable (24818)<br><br>make -C etherboo=
t all<br>
make[6]: Entering directory `/home/source/xen-unstable.hg/tools/firmware/et=
herboot&#39;<br>
rm -rf ipxe<br>
gzip -dc ipxe.tar.gz | tar xf -<br>
for i in $(cat patches/series) ; do=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 \<br>
=A0=A0=A0 =A0=A0=A0 patch -d ipxe -p1 --quiet &lt;patches/$i || exit 1 ; \<=
br>
=A0=A0=A0 done<br>
1 out of 4 hunks FAILED -- saving rejects to file src/arch/i386/prefix/romp=
refix.S.rej<br>
make[6]: *** [ipxe/src/arch/i386/Makefile] Error 1<br>
make[6]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware/eth=
erboot&#39;<br>
make[5]: *** [subdir-all-etherboot] Error 2<br>
make[5]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware&#39=
;<br>
make[4]: *** [subdirs-all] Error 2<br>
make[4]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware&#39=
;<br>
make[3]: *** [all] Error 2<br>
make[3]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware&#39=
;<br>
make[2]: *** [subdir-install-firmware] Error 2<br>
make[2]: Leaving directory `/home/source/xen-unstable.hg/tools&#39;<br>
make[1]: *** [subdirs-install] Error 2<br>
make[1]: Leaving directory `/home/source/xen-unstable.hg/tools&#39;<br>
make: *** [install-tools] Error 2<br>
<br>

--0015175d009ea4348304b917b292--


--===============6597912299562301884==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6597912299562301884==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 16:56:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 16:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry4cb-0004V6-ML; Thu, 16 Feb 2012 16:55:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ry4ca-0004Uz-Hd
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 16:55:52 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329411343!9772737!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 490 invoked from network); 16 Feb 2012 16:55:45 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 16:55:45 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1GGteMx013093
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 16 Feb 2012 08:55:41 -0800
Received: by bkcjg15 with SMTP id jg15so3742238bkc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 08:55:39 -0800 (PST)
Received: by 10.204.152.88 with SMTP id f24mr1790210bkw.31.1329411339334; Thu,
	16 Feb 2012 08:55:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Thu, 16 Feb 2012 08:54:59 -0800 (PST)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 08:54:59 -0800
Message-ID: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen-unstable - Build fail
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6597912299562301884=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6597912299562301884==
Content-Type: multipart/alternative; boundary=0015175d009ea4348304b917b292

--0015175d009ea4348304b917b292
Content-Type: text/plain; charset=ISO-8859-1

This is from the latest c/s in xen-unstable (24818)

make -C etherboot all
make[6]: Entering directory
`/home/source/xen-unstable.hg/tools/firmware/etherboot'
rm -rf ipxe
gzip -dc ipxe.tar.gz | tar xf -
for i in $(cat patches/series) ; do                 \
        patch -d ipxe -p1 --quiet <patches/$i || exit 1 ; \
    done
1 out of 4 hunks FAILED -- saving rejects to file
src/arch/i386/prefix/romprefix.S.rej
make[6]: *** [ipxe/src/arch/i386/Makefile] Error 1
make[6]: Leaving directory
`/home/source/xen-unstable.hg/tools/firmware/etherboot'
make[5]: *** [subdir-all-etherboot] Error 2
make[5]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/source/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/source/xen-unstable.hg/tools'
make: *** [install-tools] Error 2

--0015175d009ea4348304b917b292
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is from the latest c/s in xen-unstable (24818)<br><br>make -C etherboo=
t all<br>
make[6]: Entering directory `/home/source/xen-unstable.hg/tools/firmware/et=
herboot&#39;<br>
rm -rf ipxe<br>
gzip -dc ipxe.tar.gz | tar xf -<br>
for i in $(cat patches/series) ; do=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 \<br>
=A0=A0=A0 =A0=A0=A0 patch -d ipxe -p1 --quiet &lt;patches/$i || exit 1 ; \<=
br>
=A0=A0=A0 done<br>
1 out of 4 hunks FAILED -- saving rejects to file src/arch/i386/prefix/romp=
refix.S.rej<br>
make[6]: *** [ipxe/src/arch/i386/Makefile] Error 1<br>
make[6]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware/eth=
erboot&#39;<br>
make[5]: *** [subdir-all-etherboot] Error 2<br>
make[5]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware&#39=
;<br>
make[4]: *** [subdirs-all] Error 2<br>
make[4]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware&#39=
;<br>
make[3]: *** [all] Error 2<br>
make[3]: Leaving directory `/home/source/xen-unstable.hg/tools/firmware&#39=
;<br>
make[2]: *** [subdir-install-firmware] Error 2<br>
make[2]: Leaving directory `/home/source/xen-unstable.hg/tools&#39;<br>
make[1]: *** [subdirs-install] Error 2<br>
make[1]: Leaving directory `/home/source/xen-unstable.hg/tools&#39;<br>
make: *** [install-tools] Error 2<br>
<br>

--0015175d009ea4348304b917b292--


--===============6597912299562301884==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6597912299562301884==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 17:26:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 17:26:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry568-0004uh-Lv; Thu, 16 Feb 2012 17:26:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ry567-0004uc-2m
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 17:26:23 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329413174!8634443!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30114 invoked from network); 16 Feb 2012 17:26:16 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 17:26:16 -0000
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com
	[209.85.215.171]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1GHQCDE027874
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 16 Feb 2012 09:26:13 -0800
Received: by eaan12 with SMTP id n12so11891866eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 09:26:11 -0800 (PST)
Received: by 10.204.156.69 with SMTP id v5mr1858994bkw.103.1329413171304; Thu,
	16 Feb 2012 09:26:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Thu, 16 Feb 2012 09:25:31 -0800 (PST)
In-Reply-To: <1329412003.3133.5.camel@zakaz.uk.xensource.com>
References: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
	<1329412003.3133.5.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 09:25:31 -0800
Message-ID: <CAP8mzPOXC+tbBc6nA3kAHzSCPkrURWSwVJ_UdZ0859P5t5R64Q@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable - Build fail
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9139981183900147146=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9139981183900147146==
Content-Type: multipart/alternative; boundary=0015175cb67ad5da2504b9181f5e

--0015175cb67ad5da2504b9181f5e
Content-Type: text/plain; charset=ISO-8859-1

yep works. thanks

On Thu, Feb 16, 2012 at 9:06 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-02-16 at 16:54 +0000, Shriram Rajagopalan wrote:
> > This is from the latest c/s in xen-unstable (24818)
> >
> > make -C etherboot all
> > make[6]: Entering directory
> > `/home/source/xen-unstable.hg/tools/firmware/etherboot'
> > rm -rf ipxe
> > gzip -dc ipxe.tar.gz | tar xf -
>
> Can you try nuking that file so that it gets re-downloaded?
>
> What version were you running previously?
>
> Ian.
>
>
>

--0015175cb67ad5da2504b9181f5e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

yep works. thanks<br><br><div class=3D"gmail_quote">On Thu, Feb 16, 2012 at=
 9:06 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell=
@citrix.com">Ian.Campbell@citrix.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">On Thu, 2012-02-16 at 16:54 +0000, Shriram Rajagopalan wr=
ote:<br>
&gt; This is from the latest c/s in xen-unstable (24818)<br>
&gt;<br>
&gt; make -C etherboot all<br>
&gt; make[6]: Entering directory<br>
&gt; `/home/source/xen-unstable.hg/tools/firmware/etherboot&#39;<br>
&gt; rm -rf ipxe<br>
&gt; gzip -dc ipxe.tar.gz | tar xf -<br>
<br>
</div>Can you try nuking that file so that it gets re-downloaded?<br>
<br>
What version were you running previously?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br>

--0015175cb67ad5da2504b9181f5e--


--===============9139981183900147146==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9139981183900147146==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 17:26:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 17:26:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry568-0004uh-Lv; Thu, 16 Feb 2012 17:26:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Ry567-0004uc-2m
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 17:26:23 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329413174!8634443!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30114 invoked from network); 16 Feb 2012 17:26:16 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2012 17:26:16 -0000
Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com
	[209.85.215.171]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1GHQCDE027874
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 16 Feb 2012 09:26:13 -0800
Received: by eaan12 with SMTP id n12so11891866eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 09:26:11 -0800 (PST)
Received: by 10.204.156.69 with SMTP id v5mr1858994bkw.103.1329413171304; Thu,
	16 Feb 2012 09:26:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Thu, 16 Feb 2012 09:25:31 -0800 (PST)
In-Reply-To: <1329412003.3133.5.camel@zakaz.uk.xensource.com>
References: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
	<1329412003.3133.5.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 09:25:31 -0800
Message-ID: <CAP8mzPOXC+tbBc6nA3kAHzSCPkrURWSwVJ_UdZ0859P5t5R64Q@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable - Build fail
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9139981183900147146=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9139981183900147146==
Content-Type: multipart/alternative; boundary=0015175cb67ad5da2504b9181f5e

--0015175cb67ad5da2504b9181f5e
Content-Type: text/plain; charset=ISO-8859-1

yep works. thanks

On Thu, Feb 16, 2012 at 9:06 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-02-16 at 16:54 +0000, Shriram Rajagopalan wrote:
> > This is from the latest c/s in xen-unstable (24818)
> >
> > make -C etherboot all
> > make[6]: Entering directory
> > `/home/source/xen-unstable.hg/tools/firmware/etherboot'
> > rm -rf ipxe
> > gzip -dc ipxe.tar.gz | tar xf -
>
> Can you try nuking that file so that it gets re-downloaded?
>
> What version were you running previously?
>
> Ian.
>
>
>

--0015175cb67ad5da2504b9181f5e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

yep works. thanks<br><br><div class=3D"gmail_quote">On Thu, Feb 16, 2012 at=
 9:06 AM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell=
@citrix.com">Ian.Campbell@citrix.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">On Thu, 2012-02-16 at 16:54 +0000, Shriram Rajagopalan wr=
ote:<br>
&gt; This is from the latest c/s in xen-unstable (24818)<br>
&gt;<br>
&gt; make -C etherboot all<br>
&gt; make[6]: Entering directory<br>
&gt; `/home/source/xen-unstable.hg/tools/firmware/etherboot&#39;<br>
&gt; rm -rf ipxe<br>
&gt; gzip -dc ipxe.tar.gz | tar xf -<br>
<br>
</div>Can you try nuking that file so that it gets re-downloaded?<br>
<br>
What version were you running previously?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br>

--0015175cb67ad5da2504b9181f5e--


--===============9139981183900147146==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9139981183900147146==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 17:34:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 17: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.xensource.com>)
	id 1Ry5DG-00054L-IT; Thu, 16 Feb 2012 17:33:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Ry5DE-000548-FT
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 17:33:44 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329413617!11780840!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjcwNzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20916 invoked from network); 16 Feb 2012 17:33:37 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-7.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 17:33:37 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1GHXWBv027344;
	Thu, 16 Feb 2012 12:33:32 -0500
Date: Thu, 16 Feb 2012 12:33:32 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.5.248]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c
> b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
>  	if (bdev->bd_openers) {
>  		xenbus_dev_error(xbdev, -EBUSY,
>  				 "Device in use; refusing to close");
> -		xenbus_switch_state(xbdev, XenbusStateClosing);
>  	} else {
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(xbdev);
> --
> 1.7.7.5
> 

Hmm, I should maybe self-nack this. The bug that led me to writing
it is likely only with older tooling, such as RHEL5's. The problem
was if you attempted to detach a mounted disk twice, then the second
time it would succeed. The guest had flipped to Closing on the first
try, and thus didn't issue an error to xenbus on the second. I see now
in libxl__initiate_device_remove() that it bails out if state != 4,
so that tooling shouldn't have this issue.

The reason I only say maybe self-nack though, is because this state
change seemed to be thrown in with another fix[1]. I'm not sure if
the new behavior on legacy hosts was considered or not. If not, then
we can consider it now. Do we want to have deferred asynch detaches
over protecting the guest from multiple detach calls on legacy hosts?

Drew

[1] b70f5fa blkfront: Lock blkfront_info when closing

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 17:34:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 17: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.xensource.com>)
	id 1Ry5DG-00054L-IT; Thu, 16 Feb 2012 17:33:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Ry5DE-000548-FT
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 17:33:44 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329413617!11780840!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjcwNzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20916 invoked from network); 16 Feb 2012 17:33:37 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-7.tower-216.messagelabs.com with SMTP;
	16 Feb 2012 17:33:37 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1GHXWBv027344;
	Thu, 16 Feb 2012 12:33:32 -0500
Date: Thu, 16 Feb 2012 12:33:32 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.5.248]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c
> b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
>  	if (bdev->bd_openers) {
>  		xenbus_dev_error(xbdev, -EBUSY,
>  				 "Device in use; refusing to close");
> -		xenbus_switch_state(xbdev, XenbusStateClosing);
>  	} else {
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(xbdev);
> --
> 1.7.7.5
> 

Hmm, I should maybe self-nack this. The bug that led me to writing
it is likely only with older tooling, such as RHEL5's. The problem
was if you attempted to detach a mounted disk twice, then the second
time it would succeed. The guest had flipped to Closing on the first
try, and thus didn't issue an error to xenbus on the second. I see now
in libxl__initiate_device_remove() that it bails out if state != 4,
so that tooling shouldn't have this issue.

The reason I only say maybe self-nack though, is because this state
change seemed to be thrown in with another fix[1]. I'm not sure if
the new behavior on legacy hosts was considered or not. If not, then
we can consider it now. Do we want to have deferred asynch detaches
over protecting the guest from multiple detach calls on legacy hosts?

Drew

[1] b70f5fa blkfront: Lock blkfront_info when closing

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 17:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 17: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.xensource.com>)
	id 1Ry5Zx-0005Iv-NX; Thu, 16 Feb 2012 17:57:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ry5Zw-0005In-9Q
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 17:57:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329412005!12195158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30180 invoked from network); 16 Feb 2012 17:06:45 -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;
	16 Feb 2012 17:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="10753985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 17:06:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 17:06:44 +0000
Message-ID: <1329412003.3133.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 17:06:43 +0000
In-Reply-To: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
References: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable - Build fail
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 16:54 +0000, Shriram Rajagopalan wrote:
> This is from the latest c/s in xen-unstable (24818)
> 
> make -C etherboot all
> make[6]: Entering directory
> `/home/source/xen-unstable.hg/tools/firmware/etherboot'
> rm -rf ipxe
> gzip -dc ipxe.tar.gz | tar xf -

Can you try nuking that file so that it gets re-downloaded?

What version were you running previously?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 17:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 17: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.xensource.com>)
	id 1Ry5Zx-0005Iv-NX; Thu, 16 Feb 2012 17:57:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ry5Zw-0005In-9Q
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 17:57:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329412005!12195158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30180 invoked from network); 16 Feb 2012 17:06:45 -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;
	16 Feb 2012 17:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="10753985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 17:06:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 16 Feb 2012 17:06:44 +0000
Message-ID: <1329412003.3133.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 16 Feb 2012 17:06:43 +0000
In-Reply-To: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
References: <CAP8mzPNbi2bu4da_AbzkujNuCdVAeQ_ZQ-2kHOYhAmoP3mVDvQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable - Build fail
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 16:54 +0000, Shriram Rajagopalan wrote:
> This is from the latest c/s in xen-unstable (24818)
> 
> make -C etherboot all
> make[6]: Entering directory
> `/home/source/xen-unstable.hg/tools/firmware/etherboot'
> rm -rf ipxe
> gzip -dc ipxe.tar.gz | tar xf -

Can you try nuking that file so that it gets re-downloaded?

What version were you running previously?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 18:37:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 18:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry6CC-0006NF-BF; Thu, 16 Feb 2012 18:36:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1Ry6CB-0006NA-5G
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 18:36:43 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329417394!9785920!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26724 invoked from network); 16 Feb 2012 18:36:35 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 18:36:35 -0000
Received: by yenm7 with SMTP id m7so30797385yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 10:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=RznQqXGxt1KtSrtPCYvewJGYsvxCX6h4pIC1OBrSMLA=;
	b=E/6ohwtvEL43mMmfu4qmu0HWKmvJaEXadce0oTu7wQJR28fBDqXfuy01lZvjjUaYtO
	9RiGqppkCpKjKIJhiybYmh4/PdyrglwwaL1JbYgRh4irCxfda4b4n/wrf99w6vfK6rLT
	IIGnZZxjgu6VQpLhbAKcO9BAYnrwBtbIyE4jA=
Received: by 10.236.78.6 with SMTP id f6mr5084514yhe.109.1329417394234; Thu,
	16 Feb 2012 10:36:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.179.9 with HTTP; Thu, 16 Feb 2012 10:36:14 -0800 (PST)
In-Reply-To: <20120216142328.GA15987@router-fw-old.local.net-space.pl>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
	<4F3CD3F002000078000735F0@nat28.tlf.novell.com>
	<20120216142328.GA15987@router-fw-old.local.net-space.pl>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Thu, 16 Feb 2012 10:36:14 -0800
Message-ID: <CACeEFf4WrxdwJHZujAqzWOFwuTNgGnE5yN4_nz8mk9sNFu-Msg@mail.gmail.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBGZWIgMTYsIDIwMTIgYXQgNjoyMyBBTSwgRGFuaWVsIEtpcGVyIDxka2lwZXJAbmV0
LXNwYWNlLnBsPiB3cm90ZToKPiBPbiBUaHUsIEZlYiAxNiwgMjAxMiBhdCAwOTowMToyMEFNICsw
MDAwLCBKYW4gQmV1bGljaCB3cm90ZToKPj4gPj4+IE9uIDE2LjAyLjEyIGF0IDA4OjI5LCBQaGls
aXBwIEhhaG4gPGhhaG5AdW5pdmVudGlvbi5kZT4gd3JvdGU6Cj4+ID4gSGVsbG8sCj4+ID4KPj4g
PiBBbSBEb25uZXJzdGFnIDE2IEZlYnJ1YXIgMjAxMiAwMjoyMjozMCBzY2hyaWViZW4gU2llOgo+
PiA+PiBPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxMDowNyBBTSwgRXJpYyBDYW1hY2hhdCA8ZXJp
Yy5jYW1hY2hhdEBnbWFpbC5jb20+Cj4+ID4gd3JvdGU6Cj4+ID4+ID4gT24gVHVlLCBGZWIgMTQs
IDIwMTIgYXQgMTI6MDcgQU0sIFBoaWxpcHAgSGFobiA8aGFobkB1bml2ZW50aW9uLmRlPiB3cm90
ZToKPj4gPj4gVHJ5IHRvIHVzZSBIWVBFUlZJU09SX2tleGVjX29wKCkgdG8gZmluZCBvdXQgd2hl
cmUgY3Jhc2ggYnVmZmVyIGlzLgo+PiA+PiBCdXQgaXQgcmV0dXJuZWQgYWRkcmVzcyB0aGF0IG91
dHNpZGUgb2YgdG90YWwgbWVtb3J5IQo+PiA+Cj4+ID4gWWVzLCBiZWNhdXNlIHRoZSBIeWVydmlz
b3IgKHdoaWNoIGlzIHJ1bm5pbmcgYmVsb3cgeW91ciBkb20wIExpbnV4IGtlcm5lbCkKPj4gPiBy
ZXNlcnZlcyB0aGUgbWVtb3J5LCBzbyBub3QgZXZlbiB0aGUgZG9tMCBrZXJuZWwgc2hvdWxkIGJl
IGFibGUgdG8gc2NyaWJibGUKPj4gPiBpdC4gVGhhdCdzIHdoeSB5b3UgaGF2ZSB0byB1c2UgdGhl
IEhZUEVSVklST1NfT1BzLgo+PiA+Cj4+ID4gSSd2ZSBzcGVuZCBzb21lIHRpbWUgaW52ZXN0aWdh
dGluZyB0aGlzIGEgbW9udGggYWdvIGJ1dCBmaW5hbGx5IGRpZCBnYXZlIHVwLgo+PiA+Cj4+ID4g
SGVyZSdyZSBzb21lIG9mIG15IG5vdGVzOgo+PiA+IC0gaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRv
IHdyaXRlIGEgdXNlci1zcGFjZSB0b29sIChsaWtlIGtleGVjKSwgd2hpY2ggdXNlcwo+PiA+IEhZ
UEVSVklTT1Jfa2V4ZWNfb3AoKSB0byBsb2FkIGEgY3Jhc2gtZHVtcCBrZXJuZWwuCj4+ID4gLSB5
b3Ugd291bGQgbmVlZCB0byBjb3B5IHNvbWUgY29kZSBmcm9tIHRoZSBsaW51eC1rZXJuZWwgdG8g
ZmlsbCBpbiBzb21lCj4+ID4gZGF0YQo+PiA+IHN0cnVjdHVyZXMuCj4+ID4gLSB0aGUgTGludXgg
a2VybmVsIHByZXBlbmRzIHRoZSBjcmFzaCBrZXJuZWwgd2l0aCBzb21lIGFzc2VtYmx5IGNvZGUs
IHdoaWNoCj4+ID4gbW92ZXMgaXQgdG8gdGhlIGZpbmFsIGxvY2F0aW9uIG9uIGV4ZWN1dGlvbi4g
VGhpcyB0cmFtcG9saW4gY29kZSB3b3VsZAo+PiA+IHBvc3NpYmx5IGJlIMKgbmVlZGVkIGluIHlv
dXIgdG9vbCBhcyB3ZWxsLgo+PiA+Cj4+ID4gVGhlIG90aGVyIG9wdGlvbiBJIHNlZSB3b3VsZCBi
ZSB0byBtb2RpZnkgdGhlIGN1cnJlbnQgTGludXgga2VybmVsIHRvIHVzZQo+PiA+IEhZUEVSVklT
T1Jfa2V4ZWNfb3AoKSB3aGVuIHVzZWQgYXMgYSBkb20wIGtlcm5lbC4KPj4KPj4gWW91IG1heSB3
YW50IHRvIGdldCBpbiB0b3VjaCB3aXRoIERhbmllbCwgd2hvIGlpcmMgc3RhcnRlZCBsb29raW5n
IGF0Cj4+IGFkZGluZyBrZXhlYyBzdXBwb3J0IHRvIHRoZSBwdi1vcHMga2VybmVsIHNvbWUgdGlt
ZSBsYXN0IHllYXIuCj4KPiAuLi4gYW5kIEkgc3RpbGwgd29yayBvbiBpdC4gVG8gYmUgcHJlY2lz
ZSBJIGhhdmUgd29ya2luZyBrZXhlYyBmb3IKPiBkb21VIFBWIGd1ZXN0IHJ1bm5pbmcgdmVyeSBh
bmNpZW50IExpbnV4IEtlcm5lbCBWZXIuIDIuNi4xOCAoaXQgaXMKPiBub3QgYmFzZWQgb24gY3Vy
cmVudCAyLjYuMTggdHJlZSkuIEkgYW0gc3RhcnRpbmcgd29yayBvbiBrZHVtcCBmb3IgZG9tVS4K
PiBXb3JrIG9uIGtleGVjL2tkdW1wIGZvciBkb20wIGlzIHBvc3Rwb25lZCB1bnRpbCBJIGZpbm5p
c2ggd29yayBvbgo+IGtleGVjL2tkdW1wIGZvciBkb21VLiBBZnRlciB0aGF0IEkgd291bGQgbGlr
ZSB0byBwcmVwYXJlIHJlbGV2YW50IHBhdGNoZXMKPiBmb3IgWGVuLCBtYWlubGluZSBMaW51eCBL
ZXJuZWwgYW5kIGtleGVjLXRvb2xzIGFuZCBwdWJsaXNoIHRoZW0gYXMgYSBjb21wbGV0ZQo+IHNv
bHV0aW9uIGZvciBkb20wIGFuZCBkb21VIChJIGFtIGdvaW5nIHRvIGRvIHRoYXQgb24gTWFyY2gg
b3IgQXByaWwsCj4gaG93ZXZlciwgLi4uIFlvdSBrbm93Li4uKS4gSSBhbSBub3QgZ29pbmcgdG8g
cHJlcGFyZSBzdXBwb3J0L2JhY2twb3J0IGZvcgo+IExpbnV4IEtlcm5lbCBWZXIuIDIuNi4zMiAo
b3IgZXZlbiAyLjYuMTgpLCBob3dldmVyLCBpZiBpdCBiZSByZXF1aXJlZAo+IGJ5IHF1aXRlIGxh
cmdlIG51bWJlciBvZiB1c2VycyBJIHdpbGwgdGhpbmsgYWJvdXQgdGhhdC4KPgo+IFJlZ2FyZGlu
ZyBrZXhlYy9rZHVtcCBkb2N1bWVudGF0aW9uIHBsZWFzZSBsb29rIGludG8gbXkgcHJlc2VudGF0
aW9uCj4gcHJlcGFyZWQgZm9yIFhlbiBTdW1taXQgMjAxMSAoaHR0cDovL3hlbi5vcmcvZmlsZXMv
eGVuc3VtbWl0X3NhbnRhY2xhcmExMS9hdWczLzdfRGFuaWVsS19LZXhlY19LRHVtcC5wZGYpLgo+
IEkgZG8gbm90IG1lbnRpb24gZG9jdW1lbnRhdGlvbiB3aGljaCB5b3UgY291bGQgZmluZCBpbiBM
aW51eCBLZXJuZWwgc291cmNlCj4gY29kZS4gSG93ZXZlciwgaWYgeW91IG5lZWQgc29tZSBtb3Jl
IGV4cGxhbmF0aW9uIGRyb3AgbWUgYSBsaW5lLgo+Cj4gRGFuaWVsCgpBdCBiZWdpbm5pbmcsIEkg
dGhvdWdoIHRoZXJlIGFyZSBzb21lIGh5cGVydmlzb3IgY2FsbHMgdG8gZmluZCBvdXQgdGhlCmNy
YXNoIGJ1ZmZlciwgcHV0IGltYWdlIGludG8gaXQsIGV4Y3V0ZSBpdC4gQnV0IGl0IHNlZW1zIG5v
dC4KSSBoYXZlIHRvIHN0dWR5IGtleGVjL2tkdW1wIGluIGJvdGggbGludXggYW5kIHhlbiB0byBm
aWd1cmUgb3V0IGhvdyB0bwpzdXBwb3J0IGtkdW1wLgoKVGhhbmsgeW91IGd1eXMuCgpFcmljCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 16 18:37:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 18:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry6CC-0006NF-BF; Thu, 16 Feb 2012 18:36:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1Ry6CB-0006NA-5G
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 18:36:43 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329417394!9785920!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26724 invoked from network); 16 Feb 2012 18:36:35 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 18:36:35 -0000
Received: by yenm7 with SMTP id m7so30797385yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 10:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=RznQqXGxt1KtSrtPCYvewJGYsvxCX6h4pIC1OBrSMLA=;
	b=E/6ohwtvEL43mMmfu4qmu0HWKmvJaEXadce0oTu7wQJR28fBDqXfuy01lZvjjUaYtO
	9RiGqppkCpKjKIJhiybYmh4/PdyrglwwaL1JbYgRh4irCxfda4b4n/wrf99w6vfK6rLT
	IIGnZZxjgu6VQpLhbAKcO9BAYnrwBtbIyE4jA=
Received: by 10.236.78.6 with SMTP id f6mr5084514yhe.109.1329417394234; Thu,
	16 Feb 2012 10:36:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.179.9 with HTTP; Thu, 16 Feb 2012 10:36:14 -0800 (PST)
In-Reply-To: <20120216142328.GA15987@router-fw-old.local.net-space.pl>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
	<4F3CD3F002000078000735F0@nat28.tlf.novell.com>
	<20120216142328.GA15987@router-fw-old.local.net-space.pl>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Thu, 16 Feb 2012 10:36:14 -0800
Message-ID: <CACeEFf4WrxdwJHZujAqzWOFwuTNgGnE5yN4_nz8mk9sNFu-Msg@mail.gmail.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBGZWIgMTYsIDIwMTIgYXQgNjoyMyBBTSwgRGFuaWVsIEtpcGVyIDxka2lwZXJAbmV0
LXNwYWNlLnBsPiB3cm90ZToKPiBPbiBUaHUsIEZlYiAxNiwgMjAxMiBhdCAwOTowMToyMEFNICsw
MDAwLCBKYW4gQmV1bGljaCB3cm90ZToKPj4gPj4+IE9uIDE2LjAyLjEyIGF0IDA4OjI5LCBQaGls
aXBwIEhhaG4gPGhhaG5AdW5pdmVudGlvbi5kZT4gd3JvdGU6Cj4+ID4gSGVsbG8sCj4+ID4KPj4g
PiBBbSBEb25uZXJzdGFnIDE2IEZlYnJ1YXIgMjAxMiAwMjoyMjozMCBzY2hyaWViZW4gU2llOgo+
PiA+PiBPbiBUdWUsIEZlYiAxNCwgMjAxMiBhdCAxMDowNyBBTSwgRXJpYyBDYW1hY2hhdCA8ZXJp
Yy5jYW1hY2hhdEBnbWFpbC5jb20+Cj4+ID4gd3JvdGU6Cj4+ID4+ID4gT24gVHVlLCBGZWIgMTQs
IDIwMTIgYXQgMTI6MDcgQU0sIFBoaWxpcHAgSGFobiA8aGFobkB1bml2ZW50aW9uLmRlPiB3cm90
ZToKPj4gPj4gVHJ5IHRvIHVzZSBIWVBFUlZJU09SX2tleGVjX29wKCkgdG8gZmluZCBvdXQgd2hl
cmUgY3Jhc2ggYnVmZmVyIGlzLgo+PiA+PiBCdXQgaXQgcmV0dXJuZWQgYWRkcmVzcyB0aGF0IG91
dHNpZGUgb2YgdG90YWwgbWVtb3J5IQo+PiA+Cj4+ID4gWWVzLCBiZWNhdXNlIHRoZSBIeWVydmlz
b3IgKHdoaWNoIGlzIHJ1bm5pbmcgYmVsb3cgeW91ciBkb20wIExpbnV4IGtlcm5lbCkKPj4gPiBy
ZXNlcnZlcyB0aGUgbWVtb3J5LCBzbyBub3QgZXZlbiB0aGUgZG9tMCBrZXJuZWwgc2hvdWxkIGJl
IGFibGUgdG8gc2NyaWJibGUKPj4gPiBpdC4gVGhhdCdzIHdoeSB5b3UgaGF2ZSB0byB1c2UgdGhl
IEhZUEVSVklST1NfT1BzLgo+PiA+Cj4+ID4gSSd2ZSBzcGVuZCBzb21lIHRpbWUgaW52ZXN0aWdh
dGluZyB0aGlzIGEgbW9udGggYWdvIGJ1dCBmaW5hbGx5IGRpZCBnYXZlIHVwLgo+PiA+Cj4+ID4g
SGVyZSdyZSBzb21lIG9mIG15IG5vdGVzOgo+PiA+IC0gaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRv
IHdyaXRlIGEgdXNlci1zcGFjZSB0b29sIChsaWtlIGtleGVjKSwgd2hpY2ggdXNlcwo+PiA+IEhZ
UEVSVklTT1Jfa2V4ZWNfb3AoKSB0byBsb2FkIGEgY3Jhc2gtZHVtcCBrZXJuZWwuCj4+ID4gLSB5
b3Ugd291bGQgbmVlZCB0byBjb3B5IHNvbWUgY29kZSBmcm9tIHRoZSBsaW51eC1rZXJuZWwgdG8g
ZmlsbCBpbiBzb21lCj4+ID4gZGF0YQo+PiA+IHN0cnVjdHVyZXMuCj4+ID4gLSB0aGUgTGludXgg
a2VybmVsIHByZXBlbmRzIHRoZSBjcmFzaCBrZXJuZWwgd2l0aCBzb21lIGFzc2VtYmx5IGNvZGUs
IHdoaWNoCj4+ID4gbW92ZXMgaXQgdG8gdGhlIGZpbmFsIGxvY2F0aW9uIG9uIGV4ZWN1dGlvbi4g
VGhpcyB0cmFtcG9saW4gY29kZSB3b3VsZAo+PiA+IHBvc3NpYmx5IGJlIMKgbmVlZGVkIGluIHlv
dXIgdG9vbCBhcyB3ZWxsLgo+PiA+Cj4+ID4gVGhlIG90aGVyIG9wdGlvbiBJIHNlZSB3b3VsZCBi
ZSB0byBtb2RpZnkgdGhlIGN1cnJlbnQgTGludXgga2VybmVsIHRvIHVzZQo+PiA+IEhZUEVSVklT
T1Jfa2V4ZWNfb3AoKSB3aGVuIHVzZWQgYXMgYSBkb20wIGtlcm5lbC4KPj4KPj4gWW91IG1heSB3
YW50IHRvIGdldCBpbiB0b3VjaCB3aXRoIERhbmllbCwgd2hvIGlpcmMgc3RhcnRlZCBsb29raW5n
IGF0Cj4+IGFkZGluZyBrZXhlYyBzdXBwb3J0IHRvIHRoZSBwdi1vcHMga2VybmVsIHNvbWUgdGlt
ZSBsYXN0IHllYXIuCj4KPiAuLi4gYW5kIEkgc3RpbGwgd29yayBvbiBpdC4gVG8gYmUgcHJlY2lz
ZSBJIGhhdmUgd29ya2luZyBrZXhlYyBmb3IKPiBkb21VIFBWIGd1ZXN0IHJ1bm5pbmcgdmVyeSBh
bmNpZW50IExpbnV4IEtlcm5lbCBWZXIuIDIuNi4xOCAoaXQgaXMKPiBub3QgYmFzZWQgb24gY3Vy
cmVudCAyLjYuMTggdHJlZSkuIEkgYW0gc3RhcnRpbmcgd29yayBvbiBrZHVtcCBmb3IgZG9tVS4K
PiBXb3JrIG9uIGtleGVjL2tkdW1wIGZvciBkb20wIGlzIHBvc3Rwb25lZCB1bnRpbCBJIGZpbm5p
c2ggd29yayBvbgo+IGtleGVjL2tkdW1wIGZvciBkb21VLiBBZnRlciB0aGF0IEkgd291bGQgbGlr
ZSB0byBwcmVwYXJlIHJlbGV2YW50IHBhdGNoZXMKPiBmb3IgWGVuLCBtYWlubGluZSBMaW51eCBL
ZXJuZWwgYW5kIGtleGVjLXRvb2xzIGFuZCBwdWJsaXNoIHRoZW0gYXMgYSBjb21wbGV0ZQo+IHNv
bHV0aW9uIGZvciBkb20wIGFuZCBkb21VIChJIGFtIGdvaW5nIHRvIGRvIHRoYXQgb24gTWFyY2gg
b3IgQXByaWwsCj4gaG93ZXZlciwgLi4uIFlvdSBrbm93Li4uKS4gSSBhbSBub3QgZ29pbmcgdG8g
cHJlcGFyZSBzdXBwb3J0L2JhY2twb3J0IGZvcgo+IExpbnV4IEtlcm5lbCBWZXIuIDIuNi4zMiAo
b3IgZXZlbiAyLjYuMTgpLCBob3dldmVyLCBpZiBpdCBiZSByZXF1aXJlZAo+IGJ5IHF1aXRlIGxh
cmdlIG51bWJlciBvZiB1c2VycyBJIHdpbGwgdGhpbmsgYWJvdXQgdGhhdC4KPgo+IFJlZ2FyZGlu
ZyBrZXhlYy9rZHVtcCBkb2N1bWVudGF0aW9uIHBsZWFzZSBsb29rIGludG8gbXkgcHJlc2VudGF0
aW9uCj4gcHJlcGFyZWQgZm9yIFhlbiBTdW1taXQgMjAxMSAoaHR0cDovL3hlbi5vcmcvZmlsZXMv
eGVuc3VtbWl0X3NhbnRhY2xhcmExMS9hdWczLzdfRGFuaWVsS19LZXhlY19LRHVtcC5wZGYpLgo+
IEkgZG8gbm90IG1lbnRpb24gZG9jdW1lbnRhdGlvbiB3aGljaCB5b3UgY291bGQgZmluZCBpbiBM
aW51eCBLZXJuZWwgc291cmNlCj4gY29kZS4gSG93ZXZlciwgaWYgeW91IG5lZWQgc29tZSBtb3Jl
IGV4cGxhbmF0aW9uIGRyb3AgbWUgYSBsaW5lLgo+Cj4gRGFuaWVsCgpBdCBiZWdpbm5pbmcsIEkg
dGhvdWdoIHRoZXJlIGFyZSBzb21lIGh5cGVydmlzb3IgY2FsbHMgdG8gZmluZCBvdXQgdGhlCmNy
YXNoIGJ1ZmZlciwgcHV0IGltYWdlIGludG8gaXQsIGV4Y3V0ZSBpdC4gQnV0IGl0IHNlZW1zIG5v
dC4KSSBoYXZlIHRvIHN0dWR5IGtleGVjL2tkdW1wIGluIGJvdGggbGludXggYW5kIHhlbiB0byBm
aWd1cmUgb3V0IGhvdyB0bwpzdXBwb3J0IGtkdW1wLgoKVGhhbmsgeW91IGd1eXMuCgpFcmljCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Feb 16 18:51:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 18: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.xensource.com>)
	id 1Ry6Q4-0006cH-IL; Thu, 16 Feb 2012 18:51:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blp@nicira.com>) id 1Ry6Q3-0006bs-RH
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 18:51:04 +0000
X-Env-Sender: blp@nicira.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329418251!13239696!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24417 invoked from network); 16 Feb 2012 18:50:53 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 18:50:53 -0000
Received: by pbbro2 with SMTP id ro2so16672114pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 10:50:51 -0800 (PST)
Received: by 10.68.227.36 with SMTP id rx4mr10764327pbc.165.1329418251018;
	Thu, 16 Feb 2012 10:50:51 -0800 (PST)
Received: from nicira.com (107-0-204-137-ip-static.hfc.comcastbusiness.net.
	[107.0.204.137])
	by mx.google.com with ESMTPS id x6sm2953671pbp.31.2012.02.16.10.50.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 16 Feb 2012 10:50:49 -0800 (PST)
Date: Thu, 16 Feb 2012 10:50:45 -0800
From: Ben Pfaff <blp@nicira.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120216185045.GE9108@nicira.com>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
	<1329323919.31256.329.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329323919.31256.329.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Gm-Message-State: ALoCoQn6Tbq3RxlOFcHneZmt5u7cYaMQ9X1Ro22/PZ+jCJ/k/mtF1Vfde+ZGW3c0Pyj7JFLCYiXu
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 15, 2012 at 04:38:39PM +0000, Ian Campbell wrote:
> On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> > Lars Kurth <lars.kurth@xen.org> writes:
> > 
> > > I have made preparations to reach out to further groups in SIlicon
> > > valley, and want to ensure that the core people are signed up before I
> > > do this.
> > 
> > Would it be helpful to have one of Nicira's Open vSwitch
> > developers come? (Is anyone interested in discussing
> > networking-related topics?)  
> 
> I think there will some xapi/XCP folks there who I expect would be
> interested in talking networking and vswitch in that context.

Thanks.  I added my name to the wiki page.  I'll plan to attend at
least the first day, and then additional days as it becomes
worthwhile.

> In the context of xen-unstable and the libx/xl toolstacks there's not
> much required for vswitch integration -- just a working hotplug script
> mechanism and a suitable script. I actually have patches for the script
> growing stale in my queue -- they don't work because of issues with
> hotplug script running on shutdown (basically the xenstore info is gone
> when the script runs so we can't remove the VIF from the switch). Roger
> Pau Monee has a patch series fixing hotplug scripts and once it goes in
> I'll resurrect my old patches.

Sounds good, thank you for the information.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 18:51:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 18: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.xensource.com>)
	id 1Ry6Q4-0006cH-IL; Thu, 16 Feb 2012 18:51:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blp@nicira.com>) id 1Ry6Q3-0006bs-RH
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 18:51:04 +0000
X-Env-Sender: blp@nicira.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329418251!13239696!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24417 invoked from network); 16 Feb 2012 18:50:53 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 18:50:53 -0000
Received: by pbbro2 with SMTP id ro2so16672114pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 10:50:51 -0800 (PST)
Received: by 10.68.227.36 with SMTP id rx4mr10764327pbc.165.1329418251018;
	Thu, 16 Feb 2012 10:50:51 -0800 (PST)
Received: from nicira.com (107-0-204-137-ip-static.hfc.comcastbusiness.net.
	[107.0.204.137])
	by mx.google.com with ESMTPS id x6sm2953671pbp.31.2012.02.16.10.50.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 16 Feb 2012 10:50:49 -0800 (PST)
Date: Thu, 16 Feb 2012 10:50:45 -0800
From: Ben Pfaff <blp@nicira.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120216185045.GE9108@nicira.com>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
	<1329323919.31256.329.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329323919.31256.329.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Gm-Message-State: ALoCoQn6Tbq3RxlOFcHneZmt5u7cYaMQ9X1Ro22/PZ+jCJ/k/mtF1Vfde+ZGW3c0Pyj7JFLCYiXu
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Pre4paration for the Xen Hackathon, March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Feb 15, 2012 at 04:38:39PM +0000, Ian Campbell wrote:
> On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> > Lars Kurth <lars.kurth@xen.org> writes:
> > 
> > > I have made preparations to reach out to further groups in SIlicon
> > > valley, and want to ensure that the core people are signed up before I
> > > do this.
> > 
> > Would it be helpful to have one of Nicira's Open vSwitch
> > developers come? (Is anyone interested in discussing
> > networking-related topics?)  
> 
> I think there will some xapi/XCP folks there who I expect would be
> interested in talking networking and vswitch in that context.

Thanks.  I added my name to the wiki page.  I'll plan to attend at
least the first day, and then additional days as it becomes
worthwhile.

> In the context of xen-unstable and the libx/xl toolstacks there's not
> much required for vswitch integration -- just a working hotplug script
> mechanism and a suitable script. I actually have patches for the script
> growing stale in my queue -- they don't work because of issues with
> hotplug script running on shutdown (basically the xenstore info is gone
> when the script runs so we can't remove the VIF from the switch). Roger
> Pau Monee has a patch series fixing hotplug scripts and once it goes in
> I'll resurrect my old patches.

Sounds good, thank you for the information.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 18:59:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 18:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry6Xo-00073f-I5; Thu, 16 Feb 2012 18:59:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blp@nicira.com>) id 1Ry6Xn-00073U-Fu
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 18:59:03 +0000
X-Env-Sender: blp@nicira.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329418735!15019873!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9504 invoked from network); 16 Feb 2012 18:58:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 18:58:57 -0000
Received: by pbbro2 with SMTP id ro2so16722115pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 10:58:55 -0800 (PST)
Received: by 10.68.236.136 with SMTP id uu8mr16507231pbc.21.1329418735300;
	Thu, 16 Feb 2012 10:58:55 -0800 (PST)
Received: from nicira.com (107-0-204-137-ip-static.hfc.comcastbusiness.net.
	[107.0.204.137])
	by mx.google.com with ESMTPS id x3sm2967097pbg.35.2012.02.16.10.58.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 16 Feb 2012 10:58:54 -0800 (PST)
Date: Thu, 16 Feb 2012 10:58:50 -0800
From: Ben Pfaff <blp@nicira.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <20120216185850.GF9108@nicira.com>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
	<1329323919.31256.329.camel@zakaz.uk.xensource.com>
	<CAOqnZH7cB+ixvAvt5KrY+dx2kAOg23BB_Cjo5KRCEgmSj+eyWA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOqnZH7cB+ixvAvt5KrY+dx2kAOg23BB_Cjo5KRCEgmSj+eyWA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Gm-Message-State: ALoCoQlegTIy9iBqcmkvk3Hiq5omz57YQpPzy7Sq4F/+4a84e62rPIvbz0Zdvwkv7YMalOqN4DNw
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Pre4paration for the Xen Hackathon,
 March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I hope that all of the OVS issues are being reported to us one way or
another, either via an OVS email list or the Debian bug tracking
system.  Right now I only see one unresolved bug in the Debian BTS
(which should get fixed this week) so I wonder whether some have been
missed?

Certainly face-to-face discussion can be productive, so I look forward
to seeing everyone in a few weeks.

On Thu, Feb 16, 2012 at 12:18:00PM +0000, Lars Kurth wrote:
> Ben,
> 
> Mike told me that there are some issues with XCP and Open vSwitch 1.4,
> where it would make sense to get Nicira and XCP guys into one room. In
> particular using OpenvSwitch 1.4 with the XCP toolstack on Debian Sid and
> Linux 3.2. The previous stable OVS release doesn't compile on Linux 3.2, so
> unless 1.4 works out of the box, we won't have OVS support in XCP toolstack
> on Ubuntu 12.04. That, plus maybe doing some early proof-of-concept work
> with Zeus (XCP on Fedora) may also make sense.
> 
> Regards
> Lars
> 
> On Wed, Feb 15, 2012 at 4:38 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
> 
> > On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> > > Lars Kurth <lars.kurth@xen.org> writes:
> > >
> > > > I have made preparations to reach out to further groups in SIlicon
> > > > valley, and want to ensure that the core people are signed up before I
> > > > do this.
> > >
> > > Would it be helpful to have one of Nicira's Open vSwitch
> > > developers come? (Is anyone interested in discussing
> > > networking-related topics?)
> >
> > Hi Ben,
> >
> > I think there will some xapi/XCP folks there who I expect would be
> > interested in talking networking and vswitch in that context.
> >
> > In the context of xen-unstable and the libx/xl toolstacks there's not
> > much required for vswitch integration -- just a working hotplug script
> > mechanism and a suitable script. I actually have patches for the script
> > growing stale in my queue -- they don't work because of issues with
> > hotplug script running on shutdown (basically the xenstore info is gone
> > when the script runs so we can't remove the VIF from the switch). Roger
> > Pau Monee has a patch series fixing hotplug scripts and once it goes in
> > I'll resurrect my old patches.
> >
> > Ian.
> >
> > >   I've tentatively received permission
> > > from management here to join for one or more days if it would be
> > > useful.  We're in Silicon Valley anyway so it doesn't require
> > > much planning on our end.
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> >
> >
> >
> > _______________________________________________
> > xen-api mailing list
> > xen-api@lists.xensource.com
> > http://lists.xensource.com/mailman/listinfo/xen-api
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 18:59:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 18:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry6Xo-00073f-I5; Thu, 16 Feb 2012 18:59:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blp@nicira.com>) id 1Ry6Xn-00073U-Fu
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 18:59:03 +0000
X-Env-Sender: blp@nicira.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329418735!15019873!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9504 invoked from network); 16 Feb 2012 18:58:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 18:58:57 -0000
Received: by pbbro2 with SMTP id ro2so16722115pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 10:58:55 -0800 (PST)
Received: by 10.68.236.136 with SMTP id uu8mr16507231pbc.21.1329418735300;
	Thu, 16 Feb 2012 10:58:55 -0800 (PST)
Received: from nicira.com (107-0-204-137-ip-static.hfc.comcastbusiness.net.
	[107.0.204.137])
	by mx.google.com with ESMTPS id x3sm2967097pbg.35.2012.02.16.10.58.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 16 Feb 2012 10:58:54 -0800 (PST)
Date: Thu, 16 Feb 2012 10:58:50 -0800
From: Ben Pfaff <blp@nicira.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <20120216185850.GF9108@nicira.com>
References: <4F3A90AD.50804@xen.org> <87r4xx9ubs.fsf@blp.benpfaff.org>
	<1329323919.31256.329.camel@zakaz.uk.xensource.com>
	<CAOqnZH7cB+ixvAvt5KrY+dx2kAOg23BB_Cjo5KRCEgmSj+eyWA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOqnZH7cB+ixvAvt5KrY+dx2kAOg23BB_Cjo5KRCEgmSj+eyWA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Gm-Message-State: ALoCoQlegTIy9iBqcmkvk3Hiq5omz57YQpPzy7Sq4F/+4a84e62rPIvbz0Zdvwkv7YMalOqN4DNw
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Pre4paration for the Xen Hackathon,
 March 6-8
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I hope that all of the OVS issues are being reported to us one way or
another, either via an OVS email list or the Debian bug tracking
system.  Right now I only see one unresolved bug in the Debian BTS
(which should get fixed this week) so I wonder whether some have been
missed?

Certainly face-to-face discussion can be productive, so I look forward
to seeing everyone in a few weeks.

On Thu, Feb 16, 2012 at 12:18:00PM +0000, Lars Kurth wrote:
> Ben,
> 
> Mike told me that there are some issues with XCP and Open vSwitch 1.4,
> where it would make sense to get Nicira and XCP guys into one room. In
> particular using OpenvSwitch 1.4 with the XCP toolstack on Debian Sid and
> Linux 3.2. The previous stable OVS release doesn't compile on Linux 3.2, so
> unless 1.4 works out of the box, we won't have OVS support in XCP toolstack
> on Ubuntu 12.04. That, plus maybe doing some early proof-of-concept work
> with Zeus (XCP on Fedora) may also make sense.
> 
> Regards
> Lars
> 
> On Wed, Feb 15, 2012 at 4:38 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
> 
> > On Tue, 2012-02-14 at 17:51 +0000, Ben Pfaff wrote:
> > > Lars Kurth <lars.kurth@xen.org> writes:
> > >
> > > > I have made preparations to reach out to further groups in SIlicon
> > > > valley, and want to ensure that the core people are signed up before I
> > > > do this.
> > >
> > > Would it be helpful to have one of Nicira's Open vSwitch
> > > developers come? (Is anyone interested in discussing
> > > networking-related topics?)
> >
> > Hi Ben,
> >
> > I think there will some xapi/XCP folks there who I expect would be
> > interested in talking networking and vswitch in that context.
> >
> > In the context of xen-unstable and the libx/xl toolstacks there's not
> > much required for vswitch integration -- just a working hotplug script
> > mechanism and a suitable script. I actually have patches for the script
> > growing stale in my queue -- they don't work because of issues with
> > hotplug script running on shutdown (basically the xenstore info is gone
> > when the script runs so we can't remove the VIF from the switch). Roger
> > Pau Monee has a patch series fixing hotplug scripts and once it goes in
> > I'll resurrect my old patches.
> >
> > Ian.
> >
> > >   I've tentatively received permission
> > > from management here to join for one or more days if it would be
> > > useful.  We're in Silicon Valley anyway so it doesn't require
> > > much planning on our end.
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> >
> >
> >
> > _______________________________________________
> > xen-api mailing list
> > xen-api@lists.xensource.com
> > http://lists.xensource.com/mailman/listinfo/xen-api
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:23:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry6v3-0007TB-U1; Thu, 16 Feb 2012 19:23:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ry6v2-0007Sy-4b; Thu, 16 Feb 2012 19:23:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329420178!5387729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25296 invoked from network); 16 Feb 2012 19:22:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 19:22:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="10756522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 19:22:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 19:22:57 +0000
Date: Thu, 16 Feb 2012 19:27:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jae-Min Ryu <jm77.ryu@samsung.com>
In-Reply-To: <24653710.69381329119360053.JavaMail.weblogic@epv6ml04>
Message-ID: <alpine.DEB.2.00.1202161925290.7456@kaball-desktop>
References: <24653710.69381329119360053.JavaMail.weblogic@epv6ml04>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	=?UTF-8?B?7ISc7IOB67KU?= <sbuk.suh@samsung.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/14]  arm: start working on ARM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Jae-Min,
I am glad to see the ARM PV code being submitted upstream, thanks for
you hard work!
It is not clear on what changeset the patches are based on, next time
could you please send an introductory email with an high level
description of the work, the diff stat and the changeset on which the
work is based on? Otherwise it is very hard to review.
See for example:

http://marc.info/?l=xen-devel&m=132811994102227

The other piece of information that is missing is what ARM processors
families and models are supported and how we could try out the code.

Also, as of last week the Xen port to ARMv7 with virtualization
extensions went in xen-unstable (see
http://marc.info/?l=xen-devel&m=132759546228687): I think it would be
great if you could rebase your patches on it so that we could start
collaborating together toward a single Xen ARM port.
It would certainly be a great benefit for the Xen community.

However I do understand that there are technical differences between the
two approaches and that it would be a significant amount of work for you
to rebase on top of the current xen/arch/arm, so if you want to keep
your port as it is, you could choose a different name for it, for
example armpv, and you would be able to keep it completely separate
(xen/arch/armpv).

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:23:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry6v3-0007TB-U1; Thu, 16 Feb 2012 19:23:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Ry6v2-0007Sy-4b; Thu, 16 Feb 2012 19:23:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329420178!5387729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25296 invoked from network); 16 Feb 2012 19:22:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 19:22:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="10756522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 19:22:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 19:22:57 +0000
Date: Thu, 16 Feb 2012 19:27:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jae-Min Ryu <jm77.ryu@samsung.com>
In-Reply-To: <24653710.69381329119360053.JavaMail.weblogic@epv6ml04>
Message-ID: <alpine.DEB.2.00.1202161925290.7456@kaball-desktop>
References: <24653710.69381329119360053.JavaMail.weblogic@epv6ml04>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	=?UTF-8?B?7ISc7IOB67KU?= <sbuk.suh@samsung.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/14]  arm: start working on ARM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Jae-Min,
I am glad to see the ARM PV code being submitted upstream, thanks for
you hard work!
It is not clear on what changeset the patches are based on, next time
could you please send an introductory email with an high level
description of the work, the diff stat and the changeset on which the
work is based on? Otherwise it is very hard to review.
See for example:

http://marc.info/?l=xen-devel&m=132811994102227

The other piece of information that is missing is what ARM processors
families and models are supported and how we could try out the code.

Also, as of last week the Xen port to ARMv7 with virtualization
extensions went in xen-unstable (see
http://marc.info/?l=xen-devel&m=132759546228687): I think it would be
great if you could rebase your patches on it so that we could start
collaborating together toward a single Xen ARM port.
It would certainly be a great benefit for the Xen community.

However I do understand that there are technical differences between the
two approaches and that it would be a significant amount of work for you
to rebase on top of the current xen/arch/arm, so if you want to keep
your port as it is, you could choose a different name for it, for
example armpv, and you would be able to keep it completely separate
(xen/arch/armpv).

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:41:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry7Cn-0007fs-KQ; Thu, 16 Feb 2012 19: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.Jackson@eu.citrix.com>) id 1Ry7Cm-0007fn-NO
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 19:41:25 +0000
Received: from [85.158.139.83:40499] by server-4.bemta-5.messagelabs.com id
	E6/85-10788-4EB5D3F4; Thu, 16 Feb 2012 19:41:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329421282!15393631!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1082 invoked from network); 16 Feb 2012 19:41:22 -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 Feb 2012 19:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,431,1325462400"; d="scan'208";a="10756731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 19:41:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 19:41:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ry7Cj-0005QU-SJ;
	Thu, 16 Feb 2012 19:41:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ry7Cj-0001kX-Ox;
	Thu, 16 Feb 2012 19:41:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11976-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 16 Feb 2012 19:41:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11976: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11976 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11976/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  01c1bcbc6222
baseline version:
 xen                  fe427d3bb378

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.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>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=01c1bcbc6222
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 01c1bcbc6222
+ branch=xen-unstable
+ revision=01c1bcbc6222
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 01c1bcbc6222 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 13 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:41:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry7Cn-0007fs-KQ; Thu, 16 Feb 2012 19: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.Jackson@eu.citrix.com>) id 1Ry7Cm-0007fn-NO
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 19:41:25 +0000
Received: from [85.158.139.83:40499] by server-4.bemta-5.messagelabs.com id
	E6/85-10788-4EB5D3F4; Thu, 16 Feb 2012 19:41:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329421282!15393631!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MjUwNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1082 invoked from network); 16 Feb 2012 19:41:22 -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 Feb 2012 19:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,431,1325462400"; d="scan'208";a="10756731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2012 19:41:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 16 Feb 2012 19:41:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Ry7Cj-0005QU-SJ;
	Thu, 16 Feb 2012 19:41:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ry7Cj-0001kX-Ox;
	Thu, 16 Feb 2012 19:41:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11976-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 16 Feb 2012 19:41:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11976: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11976 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11976/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  01c1bcbc6222
baseline version:
 xen                  fe427d3bb378

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.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>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=01c1bcbc6222
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 01c1bcbc6222
+ branch=xen-unstable
+ revision=01c1bcbc6222
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 01c1bcbc6222 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 13 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:45:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19: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.xensource.com>)
	id 1Ry7Ft-0007ot-Fl; Thu, 16 Feb 2012 19:44:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ry7Fr-0007oa-J6
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 19:44:35 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329421468!5390054!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1708 invoked from network); 16 Feb 2012 19:44:29 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 19:44:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1GJiNNG008095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 16 Feb 2012 14:44:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1GJiMFP008093;
	Thu, 16 Feb 2012 14:44:22 -0500
Date: Thu, 16 Feb 2012 15:44:22 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120216194422.GA8023@andromeda.dapyr.net>
References: <1329394585-10129-1-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329394585-10129-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after
	getting it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> We should hang onto bdev until we're done with it.

Looks ok. Is there a BZ that sparked this? Thanks.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..5d45688 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	mutex_lock(&blkfront_mutex);
>  
>  	bdev = bdget_disk(disk, 0);
> -	bdput(bdev);
>  
>  	if (bdev->bd_openers)
>  		goto out;
> @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	}
>  
>  out:
> +	bdput(bdev);
>  	mutex_unlock(&blkfront_mutex);
>  	return 0;
>  }
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:45:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19: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.xensource.com>)
	id 1Ry7Ft-0007ot-Fl; Thu, 16 Feb 2012 19:44:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ry7Fr-0007oa-J6
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 19:44:35 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329421468!5390054!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1708 invoked from network); 16 Feb 2012 19:44:29 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 19:44:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1GJiNNG008095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 16 Feb 2012 14:44:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1GJiMFP008093;
	Thu, 16 Feb 2012 14:44:22 -0500
Date: Thu, 16 Feb 2012 15:44:22 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120216194422.GA8023@andromeda.dapyr.net>
References: <1329394585-10129-1-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329394585-10129-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after
	getting it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> We should hang onto bdev until we're done with it.

Looks ok. Is there a BZ that sparked this? Thanks.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..5d45688 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	mutex_lock(&blkfront_mutex);
>  
>  	bdev = bdget_disk(disk, 0);
> -	bdput(bdev);
>  
>  	if (bdev->bd_openers)
>  		goto out;
> @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	}
>  
>  out:
> +	bdput(bdev);
>  	mutex_unlock(&blkfront_mutex);
>  	return 0;
>  }
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:48:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry7JI-00081l-3r; Thu, 16 Feb 2012 19:48:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ry7JH-00081e-DM
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 19:48:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329421627!57043309!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1341 invoked from network); 16 Feb 2012 19:47:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 19:47:08 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1GJm1uq008178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 16 Feb 2012 14:48:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1GJm1r2008170;
	Thu, 16 Feb 2012 14:48:01 -0500
Date: Thu, 16 Feb 2012 15:48:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120216194801.GB8023@andromeda.dapyr.net>
References: <1329394629-10299-1-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.

What happens if the user uses --force to unplug the device?
Will that still work?
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
>  	if (bdev->bd_openers) {
>  		xenbus_dev_error(xbdev, -EBUSY,
>  				 "Device in use; refusing to close");
> -		xenbus_switch_state(xbdev, XenbusStateClosing);
>  	} else {
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(xbdev);
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 19:48:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 19:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry7JI-00081l-3r; Thu, 16 Feb 2012 19:48:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Ry7JH-00081e-DM
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 19:48:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329421627!57043309!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1341 invoked from network); 16 Feb 2012 19:47:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Feb 2012 19:47:08 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1GJm1uq008178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 16 Feb 2012 14:48:01 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1GJm1r2008170;
	Thu, 16 Feb 2012 14:48:01 -0500
Date: Thu, 16 Feb 2012 15:48:01 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120216194801.GB8023@andromeda.dapyr.net>
References: <1329394629-10299-1-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.

What happens if the user uses --force to unplug the device?
Will that still work?
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
>  	if (bdev->bd_openers) {
>  		xenbus_dev_error(xbdev, -EBUSY,
>  				 "Device in use; refusing to close");
> -		xenbus_switch_state(xbdev, XenbusStateClosing);
>  	} else {
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(xbdev);
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 20:09:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 20:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry7dh-0008Ln-HY; Thu, 16 Feb 2012 20:09:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1Ry7dg-0008Lf-2I
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 20:09:12 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329422945!13700693!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9143 invoked from network); 16 Feb 2012 20:09:05 -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;
	16 Feb 2012 20:09:05 -0000
Received: by werb14 with SMTP id b14so5023847wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 12:09:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.135.66 with SMTP id t44mr1939681wei.52.1329422944940; Thu,
	16 Feb 2012 12:09:04 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Thu, 16 Feb 2012 12:09:04 -0800 (PST)
Date: Thu, 16 Feb 2012 12:09:04 -0800
Message-ID: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnWw4Xc/DRnR1UtqC8dIUInGeIiUZLXpkPpoDKmjPD1rczpQlV8HS++hnJDKlVrGXvFhwkW
Subject: [Xen-devel] persistent or "steady-state" style disks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3057443695391217239=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3057443695391217239==
Content-Type: multipart/alternative; boundary=0016e6de002463b18e04b91a66f7

--0016e6de002463b18e04b91a66f7
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have a requirement (and a limited timeframe) to make a Windows 7 VM
domain roll back to a fixed state on restart, shutdown etc.
Something like a Kiosk Mode.  I think this is a very needed part of the
core of xen and this functionality does
not appear to be part of xen already.  So I've been trying various ways to
make this work.

Has anyone already implemented something like this successfully before?

What I've been experimenting unsuccessfully with currently is the following:

1) Add hooks into the blktap2 code to roll back a VHD (currently based on
the name ending in -persist.vhd).
However, it's not working out as it should.

2) Second attempt was to write an external script and call it periodically.
The idea was to call vhd-snapshot on the parent disk to a new disk (temp
name).  Then do an atomic rename on existing vhd
and unlink the old vhd.  When it restarts you would think it would open up
the new snapshot.  Unfortunately, a reboot seems to
detect that the file is different and so it's not re-started as desired but
instead the domain is shutdown.

I don't like either of the above methods.  They are hacks in my opinion but
I'm not currently familiar enough with xen internals.
Can someone propose a method and/or suggest where I could hook into the xen
tools to implement it?

Regards,
Matthew

--0016e6de002463b18e04b91a66f7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I have a requirement (and a limited timeframe) to ma=
ke a Windows 7 VM domain roll back to a fixed state on restart, shutdown et=
c.</div><div>Something like a Kiosk Mode. =A0I think this is a very needed =
part of the core of xen and this functionality does=A0</div>
<div>not appear to be part of xen already. =A0So I&#39;ve been trying vario=
us ways=A0to make this work.</div><div><br></div><div>Has anyone already im=
plemented something like this successfully before?</div><div><br></div><div=
>
What I&#39;ve been experimenting unsuccessfully with currently is the follo=
wing:</div><div><br></div><div>1) Add hooks into the blktap2 code to roll b=
ack a VHD (currently based on the name ending in -persist.vhd). =A0</div>
<div>However, it&#39;s not working out as it should.</div><div><br></div><d=
iv>2) Second attempt was to write an external script and call it periodical=
ly.</div><div>The idea was to call vhd-snapshot on the parent disk to a new=
 disk (temp name). =A0Then do an atomic rename on existing vhd</div>
<div>and unlink the old vhd. =A0When it restarts you would think it would o=
pen up the new snapshot. =A0Unfortunately, a reboot seems to</div><div>dete=
ct that the file is different and so it&#39;s not re-started as desired but=
 instead the domain is shutdown.</div>
<div><br></div><div>I don&#39;t like either of the above methods. =A0They a=
re hacks in my opinion but I&#39;m not currently familiar enough with xen i=
nternals. =A0</div><div>Can=A0someone propose a method and/or suggest where=
 I could hook into the xen tools to implement it?</div>
<div><br></div><div>Regards,</div><div>Matthew</div>

--0016e6de002463b18e04b91a66f7--


--===============3057443695391217239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3057443695391217239==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 20:09:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 20:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry7dh-0008Ln-HY; Thu, 16 Feb 2012 20:09:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1Ry7dg-0008Lf-2I
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 20:09:12 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329422945!13700693!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9143 invoked from network); 16 Feb 2012 20:09:05 -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;
	16 Feb 2012 20:09:05 -0000
Received: by werb14 with SMTP id b14so5023847wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 12:09:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.135.66 with SMTP id t44mr1939681wei.52.1329422944940; Thu,
	16 Feb 2012 12:09:04 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Thu, 16 Feb 2012 12:09:04 -0800 (PST)
Date: Thu, 16 Feb 2012 12:09:04 -0800
Message-ID: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnWw4Xc/DRnR1UtqC8dIUInGeIiUZLXpkPpoDKmjPD1rczpQlV8HS++hnJDKlVrGXvFhwkW
Subject: [Xen-devel] persistent or "steady-state" style disks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3057443695391217239=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3057443695391217239==
Content-Type: multipart/alternative; boundary=0016e6de002463b18e04b91a66f7

--0016e6de002463b18e04b91a66f7
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have a requirement (and a limited timeframe) to make a Windows 7 VM
domain roll back to a fixed state on restart, shutdown etc.
Something like a Kiosk Mode.  I think this is a very needed part of the
core of xen and this functionality does
not appear to be part of xen already.  So I've been trying various ways to
make this work.

Has anyone already implemented something like this successfully before?

What I've been experimenting unsuccessfully with currently is the following:

1) Add hooks into the blktap2 code to roll back a VHD (currently based on
the name ending in -persist.vhd).
However, it's not working out as it should.

2) Second attempt was to write an external script and call it periodically.
The idea was to call vhd-snapshot on the parent disk to a new disk (temp
name).  Then do an atomic rename on existing vhd
and unlink the old vhd.  When it restarts you would think it would open up
the new snapshot.  Unfortunately, a reboot seems to
detect that the file is different and so it's not re-started as desired but
instead the domain is shutdown.

I don't like either of the above methods.  They are hacks in my opinion but
I'm not currently familiar enough with xen internals.
Can someone propose a method and/or suggest where I could hook into the xen
tools to implement it?

Regards,
Matthew

--0016e6de002463b18e04b91a66f7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I have a requirement (and a limited timeframe) to ma=
ke a Windows 7 VM domain roll back to a fixed state on restart, shutdown et=
c.</div><div>Something like a Kiosk Mode. =A0I think this is a very needed =
part of the core of xen and this functionality does=A0</div>
<div>not appear to be part of xen already. =A0So I&#39;ve been trying vario=
us ways=A0to make this work.</div><div><br></div><div>Has anyone already im=
plemented something like this successfully before?</div><div><br></div><div=
>
What I&#39;ve been experimenting unsuccessfully with currently is the follo=
wing:</div><div><br></div><div>1) Add hooks into the blktap2 code to roll b=
ack a VHD (currently based on the name ending in -persist.vhd). =A0</div>
<div>However, it&#39;s not working out as it should.</div><div><br></div><d=
iv>2) Second attempt was to write an external script and call it periodical=
ly.</div><div>The idea was to call vhd-snapshot on the parent disk to a new=
 disk (temp name). =A0Then do an atomic rename on existing vhd</div>
<div>and unlink the old vhd. =A0When it restarts you would think it would o=
pen up the new snapshot. =A0Unfortunately, a reboot seems to</div><div>dete=
ct that the file is different and so it&#39;s not re-started as desired but=
 instead the domain is shutdown.</div>
<div><br></div><div>I don&#39;t like either of the above methods. =A0They a=
re hacks in my opinion but I&#39;m not currently familiar enough with xen i=
nternals. =A0</div><div>Can=A0someone propose a method and/or suggest where=
 I could hook into the xen tools to implement it?</div>
<div><br></div><div>Regards,</div><div>Matthew</div>

--0016e6de002463b18e04b91a66f7--


--===============3057443695391217239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3057443695391217239==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 20:16:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry7kc-0008Vs-FZ; Thu, 16 Feb 2012 20:16:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Ry7ka-0008VP-Qb
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 20:16:20 +0000
Received: from [85.158.139.83:19675] by server-1.bemta-5.messagelabs.com id
	72/99-28458-3146D3F4; Thu, 16 Feb 2012 20:16:19 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329423375!7977264!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23151 invoked from network); 16 Feb 2012 20:16:18 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-8.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Feb 2012 20:16:18 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1608169Ab2BPUQI (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 16 Feb 2012 21:16:08 +0100
Date: Thu, 16 Feb 2012 21:16:08 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120216201608.GA19626@router-fw-old.local.net-space.pl>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
	<4F3CD3F002000078000735F0@nat28.tlf.novell.com>
	<20120216142328.GA15987@router-fw-old.local.net-space.pl>
	<CACeEFf4WrxdwJHZujAqzWOFwuTNgGnE5yN4_nz8mk9sNFu-Msg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf4WrxdwJHZujAqzWOFwuTNgGnE5yN4_nz8mk9sNFu-Msg@mail.gmail.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>,
	Daniel Kiper <dkiper@net-space.pl>, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 10:36:14AM -0800, Eric Camachat wrote:

[...]

> At beginning, I though there are some hypervisor calls to find out the
> crash buffer, put image into it, excute it. But it seems not.
> I have to study kexec/kdump in both linux and xen to figure out how to
> support kdump.

HYPERVISOR_kexec_op() hypercall is used in dom0 only (more or less for
things you mentioned). Look into include/xen/interface/kexec.h in
Xen Linux Kernel Ver. 2.6.18 for details. kexec/kdump for domU
does not use that hypercall.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 20:16:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 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.xensource.com>)
	id 1Ry7kc-0008Vs-FZ; Thu, 16 Feb 2012 20:16:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1Ry7ka-0008VP-Qb
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 20:16:20 +0000
Received: from [85.158.139.83:19675] by server-1.bemta-5.messagelabs.com id
	72/99-28458-3146D3F4; Thu, 16 Feb 2012 20:16:19 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329423375!7977264!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23151 invoked from network); 16 Feb 2012 20:16:18 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-8.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Feb 2012 20:16:18 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1608169Ab2BPUQI (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 16 Feb 2012 21:16:08 +0100
Date: Thu, 16 Feb 2012 21:16:08 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120216201608.GA19626@router-fw-old.local.net-space.pl>
References: <CACeEFf4c0MFWtoN8StcMS3cg0=6yd3ZuVZCynAjd5D0OqmvsSQ@mail.gmail.com>
	<CACeEFf5AXELd+C701RG1X7iRAgoyansFjd4oJSDXMnqPjNq9Vw@mail.gmail.com>
	<CACeEFf654tBmP86cu0Aum+eeLdEkq-9XM_oba0Lwv2F+HL3xoQ@mail.gmail.com>
	<201202160829.54814.hahn@univention.de>
	<4F3CD3F002000078000735F0@nat28.tlf.novell.com>
	<20120216142328.GA15987@router-fw-old.local.net-space.pl>
	<CACeEFf4WrxdwJHZujAqzWOFwuTNgGnE5yN4_nz8mk9sNFu-Msg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf4WrxdwJHZujAqzWOFwuTNgGnE5yN4_nz8mk9sNFu-Msg@mail.gmail.com>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>,
	Daniel Kiper <dkiper@net-space.pl>, Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] [Xen-users] crashkernel doesn't work with
	linux-2.6.32-dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 10:36:14AM -0800, Eric Camachat wrote:

[...]

> At beginning, I though there are some hypervisor calls to find out the
> crash buffer, put image into it, excute it. But it seems not.
> I have to study kexec/kdump in both linux and xen to figure out how to
> support kdump.

HYPERVISOR_kexec_op() hypercall is used in dom0 only (more or less for
things you mentioned). Look into include/xen/interface/kexec.h in
Xen Linux Kernel Ver. 2.6.18 for details. kexec/kdump for domU
does not use that hypercall.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 20:35:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 20:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry82G-0000Is-7x; Thu, 16 Feb 2012 20:34:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1Ry82E-0000In-5d
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 20:34:34 +0000
Received: from [85.158.139.83:4885] by server-3.bemta-5.messagelabs.com id
	1D/67-06438-9586D3F4; Thu, 16 Feb 2012 20:34:33 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329424472!12697009!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18516 invoked from network); 16 Feb 2012 20:34:32 -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;
	16 Feb 2012 20:34:32 -0000
Received: by eaan12 with SMTP id n12so12797708eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 12:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=l6M4RnBHq7B5/XFBinXfQ8w5PkzG4zMrj6c8PTCpBUI=;
	b=x9sepkGRclM307s5dwYDh8nSi1mFiK7tNrNsTknM0pep0y88OjF6ucMLP/gv3bB34G
	aA1wc9RJzHLu/LI3NTcI4OHZ7OHg83Iof9wFmQ2788yLchANcthK5Qz0eDlWk+8it4wd
	p3rYmcjb4445x/T57WCVMC4+zm2YkIP9Gz5Ew=
MIME-Version: 1.0
Received: by 10.112.36.65 with SMTP id o1mr1609679lbj.32.1329424471942; Thu,
	16 Feb 2012 12:34:31 -0800 (PST)
Received: by 10.152.21.7 with HTTP; Thu, 16 Feb 2012 12:34:31 -0800 (PST)
Date: Thu, 16 Feb 2012 15:34:31 -0500
Message-ID: <CAJEOSFvFV-zNXrmqkiu+aLHy0cG+qz2gOdVC7foOvm+TKrv31g@mail.gmail.com>
From: X <studyxen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] question about syscall interception
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6654557442869447091=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6654557442869447091==
Content-Type: multipart/alternative; boundary=e0cb4efa6ed867e54004b91ac16d

--e0cb4efa6ed867e54004b91ac16d
Content-Type: text/plain; charset=ISO-8859-1

Hello everyone,

I have a few questions about syscall interception in Xen. Thanks for any
advice/suggestion.

Setting: CPU, Xen and PV Linux guest are all 64-bit

(1) If a guest app uses "syscall" instruction to launch a system call to
the guest kernel, is that behavior intercepted by Xen by default? If yes,
could someone please point me to the related code in Xen for this
interception? (anything to do with "switch_to_kernel in
xen/arch/x86/x86_64/entry.S"?) If no, then how could I intercept that
instruction in this case?

(2) If a guest app uses "int 0x80" to launch a system call, then is it true
that after "init_int80_direct_trap," the int 0x80 is no longer intercepted
by Xen, and the app can trap directly into the guest kernel? My
understanding is that "init_int80_direct_trap" initializes vcpu's
arch_vpuc.int80_bounce. Could someone please briefly explain how things
work after this struct is properly setup? How could I intercept system
calls launched in this way in Xen?

Thanks.

X

--e0cb4efa6ed867e54004b91ac16d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello everyone,<div><br></div><div>I have a few questions about syscall int=
erception in Xen. Thanks for any advice/suggestion.=A0</div><div><br></div>=
<div>Setting: CPU, Xen and PV Linux guest are all 64-bit</div><div><br></di=
v>
<div>(1) If a guest app uses &quot;syscall&quot; instruction to launch a sy=
stem call to the guest kernel, is that behavior intercepted by Xen by defau=
lt? If yes, could someone please point me to the related code in Xen for th=
is interception? (anything to do with &quot;switch_to_kernel in xen/arch/x8=
6/x86_64/entry.S&quot;?) If no, then how could I intercept that instruction=
 in this case?=A0</div>
<div><br></div><div>(2) If a guest app uses &quot;int 0x80&quot; to launch =
a system call, then is it true that after &quot;init_int80_direct_trap,&quo=
t; the int 0x80 is no longer intercepted by Xen, and the app can trap direc=
tly into the guest kernel? My understanding is that &quot;init_int80_direct=
_trap&quot; initializes vcpu&#39;s arch_vpuc.int80_bounce. Could someone pl=
ease briefly explain how things work after this struct is properly setup? H=
ow could I intercept system calls launched in this way in Xen?</div>
<div><br></div><div>Thanks.</div><div><br></div><div>X</div>

--e0cb4efa6ed867e54004b91ac16d--


--===============6654557442869447091==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6654557442869447091==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 20:35:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 20:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ry82G-0000Is-7x; Thu, 16 Feb 2012 20:34:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1Ry82E-0000In-5d
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 20:34:34 +0000
Received: from [85.158.139.83:4885] by server-3.bemta-5.messagelabs.com id
	1D/67-06438-9586D3F4; Thu, 16 Feb 2012 20:34:33 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329424472!12697009!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18516 invoked from network); 16 Feb 2012 20:34:32 -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;
	16 Feb 2012 20:34:32 -0000
Received: by eaan12 with SMTP id n12so12797708eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 12:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=l6M4RnBHq7B5/XFBinXfQ8w5PkzG4zMrj6c8PTCpBUI=;
	b=x9sepkGRclM307s5dwYDh8nSi1mFiK7tNrNsTknM0pep0y88OjF6ucMLP/gv3bB34G
	aA1wc9RJzHLu/LI3NTcI4OHZ7OHg83Iof9wFmQ2788yLchANcthK5Qz0eDlWk+8it4wd
	p3rYmcjb4445x/T57WCVMC4+zm2YkIP9Gz5Ew=
MIME-Version: 1.0
Received: by 10.112.36.65 with SMTP id o1mr1609679lbj.32.1329424471942; Thu,
	16 Feb 2012 12:34:31 -0800 (PST)
Received: by 10.152.21.7 with HTTP; Thu, 16 Feb 2012 12:34:31 -0800 (PST)
Date: Thu, 16 Feb 2012 15:34:31 -0500
Message-ID: <CAJEOSFvFV-zNXrmqkiu+aLHy0cG+qz2gOdVC7foOvm+TKrv31g@mail.gmail.com>
From: X <studyxen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] question about syscall interception
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6654557442869447091=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6654557442869447091==
Content-Type: multipart/alternative; boundary=e0cb4efa6ed867e54004b91ac16d

--e0cb4efa6ed867e54004b91ac16d
Content-Type: text/plain; charset=ISO-8859-1

Hello everyone,

I have a few questions about syscall interception in Xen. Thanks for any
advice/suggestion.

Setting: CPU, Xen and PV Linux guest are all 64-bit

(1) If a guest app uses "syscall" instruction to launch a system call to
the guest kernel, is that behavior intercepted by Xen by default? If yes,
could someone please point me to the related code in Xen for this
interception? (anything to do with "switch_to_kernel in
xen/arch/x86/x86_64/entry.S"?) If no, then how could I intercept that
instruction in this case?

(2) If a guest app uses "int 0x80" to launch a system call, then is it true
that after "init_int80_direct_trap," the int 0x80 is no longer intercepted
by Xen, and the app can trap directly into the guest kernel? My
understanding is that "init_int80_direct_trap" initializes vcpu's
arch_vpuc.int80_bounce. Could someone please briefly explain how things
work after this struct is properly setup? How could I intercept system
calls launched in this way in Xen?

Thanks.

X

--e0cb4efa6ed867e54004b91ac16d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello everyone,<div><br></div><div>I have a few questions about syscall int=
erception in Xen. Thanks for any advice/suggestion.=A0</div><div><br></div>=
<div>Setting: CPU, Xen and PV Linux guest are all 64-bit</div><div><br></di=
v>
<div>(1) If a guest app uses &quot;syscall&quot; instruction to launch a sy=
stem call to the guest kernel, is that behavior intercepted by Xen by defau=
lt? If yes, could someone please point me to the related code in Xen for th=
is interception? (anything to do with &quot;switch_to_kernel in xen/arch/x8=
6/x86_64/entry.S&quot;?) If no, then how could I intercept that instruction=
 in this case?=A0</div>
<div><br></div><div>(2) If a guest app uses &quot;int 0x80&quot; to launch =
a system call, then is it true that after &quot;init_int80_direct_trap,&quo=
t; the int 0x80 is no longer intercepted by Xen, and the app can trap direc=
tly into the guest kernel? My understanding is that &quot;init_int80_direct=
_trap&quot; initializes vcpu&#39;s arch_vpuc.int80_bounce. Could someone pl=
ease briefly explain how things work after this struct is properly setup? H=
ow could I intercept system calls launched in this way in Xen?</div>
<div><br></div><div>Thanks.</div><div><br></div><div>X</div>

--e0cb4efa6ed867e54004b91ac16d--


--===============6654557442869447091==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6654557442869447091==--


From xen-devel-bounces@lists.xensource.com Thu Feb 16 22:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 22: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.xensource.com>)
	id 1RyABq-00028o-SS; Thu, 16 Feb 2012 22:52:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RyABp-00028Z-FU
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 22:52:37 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329432749!12659343!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19802 invoked from network); 16 Feb 2012 22:52:30 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 22:52:30 -0000
Received: by vbbfq11 with SMTP id fq11so4616857vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 14:52:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=UYYdcW4cURrHqMtVLzG9cxWN4OtHxc6TT5EthO7XcOM=;
	b=fhj6u825Rf1y5J4c74h08sEkm/FW/dX41l1ZOOg7Hh6FrK2a4UL8cKW0ZjOh+t2AQ/
	w09faDW6z8++5yDZOm/BlW7sKQ0QjtwUhW3gSyttm3zTr3Bp4QmofKzGrH8akYfcuIai
	lHgofRRfSd8pdyLh96Q8Etx90Nhxmp8js9kC4=
MIME-Version: 1.0
Received: by 10.52.20.142 with SMTP id n14mr2036344vde.59.1329432749129; Thu,
	16 Feb 2012 14:52:29 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Thu, 16 Feb 2012 14:52:29 -0800 (PST)
In-Reply-To: <1329390815.5975.7.camel@zakaz.uk.xensource.com>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
	<1329390815.5975.7.camel@zakaz.uk.xensource.com>
Date: Fri, 17 Feb 2012 07:52:29 +0900
Message-ID: <CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 8:13 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
>> Hello All,
>>
>> When a HVM guest is started upstream qemu presents the emulated drives
>> as PCI devices or ata drives?
>
>> If more than drive is present how can I know which drive is which in xen=
store?
>
> Emulated devices do not appear in xenstore.
>
> Some PV devices may have an emulated equivalent but the rule of thumb is
> that an OS should only use either PV or Emulated devices and not mix and
> match.
>
> In Linux we implement this by requiring that the emulated devices are
> unplugged before we will use the PV path.
>
> In principal you can infer which Emulated device might matches a PV
> device, the file docs/misc/vbd-interface.txt in the xen tree gives some
> hints about this, but basically PV disks 0..3 can correspond to the
> first four IDE devices (primary-master, primary-slave, secondary-master
> & secondary-slave).
>
> I presume you are asking in the context of SeaBIOS. In that context you
> could argue against unplugging because the guest OS may want to use
> emulated devices, however I would suggest that for simplicity for time
> being you just unplug the emulated devices before you enable the PV
> path.
Thanks for the response Ian, I am not sure I understand you. What I do
is something similar to this:
Find the emulated devices. ATA Devices are the drives and the PCI
device is for what?
Find if the device is a disk. (in the context of a vbd the xenstore id
corresponds to what?)
If disk, then find corresponding entry on xenstore. Example
device/vbd/832, device/vbd/985
Change state of device. (This step means unplug?)
Write device details to xenstore -rings, ref, etc
Write in Seabios device details -size, CHS, etc.
Change status in xenstore to plug the PV device
Device is ready to use.


Thanks for your very useful information.
>
> Ian.
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 22:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 22: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.xensource.com>)
	id 1RyABq-00028o-SS; Thu, 16 Feb 2012 22:52:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RyABp-00028Z-FU
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 22:52:37 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329432749!12659343!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19802 invoked from network); 16 Feb 2012 22:52:30 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 22:52:30 -0000
Received: by vbbfq11 with SMTP id fq11so4616857vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 14:52:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=UYYdcW4cURrHqMtVLzG9cxWN4OtHxc6TT5EthO7XcOM=;
	b=fhj6u825Rf1y5J4c74h08sEkm/FW/dX41l1ZOOg7Hh6FrK2a4UL8cKW0ZjOh+t2AQ/
	w09faDW6z8++5yDZOm/BlW7sKQ0QjtwUhW3gSyttm3zTr3Bp4QmofKzGrH8akYfcuIai
	lHgofRRfSd8pdyLh96Q8Etx90Nhxmp8js9kC4=
MIME-Version: 1.0
Received: by 10.52.20.142 with SMTP id n14mr2036344vde.59.1329432749129; Thu,
	16 Feb 2012 14:52:29 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Thu, 16 Feb 2012 14:52:29 -0800 (PST)
In-Reply-To: <1329390815.5975.7.camel@zakaz.uk.xensource.com>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
	<1329390815.5975.7.camel@zakaz.uk.xensource.com>
Date: Fri, 17 Feb 2012 07:52:29 +0900
Message-ID: <CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 8:13 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
>> Hello All,
>>
>> When a HVM guest is started upstream qemu presents the emulated drives
>> as PCI devices or ata drives?
>
>> If more than drive is present how can I know which drive is which in xen=
store?
>
> Emulated devices do not appear in xenstore.
>
> Some PV devices may have an emulated equivalent but the rule of thumb is
> that an OS should only use either PV or Emulated devices and not mix and
> match.
>
> In Linux we implement this by requiring that the emulated devices are
> unplugged before we will use the PV path.
>
> In principal you can infer which Emulated device might matches a PV
> device, the file docs/misc/vbd-interface.txt in the xen tree gives some
> hints about this, but basically PV disks 0..3 can correspond to the
> first four IDE devices (primary-master, primary-slave, secondary-master
> & secondary-slave).
>
> I presume you are asking in the context of SeaBIOS. In that context you
> could argue against unplugging because the guest OS may want to use
> emulated devices, however I would suggest that for simplicity for time
> being you just unplug the emulated devices before you enable the PV
> path.
Thanks for the response Ian, I am not sure I understand you. What I do
is something similar to this:
Find the emulated devices. ATA Devices are the drives and the PCI
device is for what?
Find if the device is a disk. (in the context of a vbd the xenstore id
corresponds to what?)
If disk, then find corresponding entry on xenstore. Example
device/vbd/832, device/vbd/985
Change state of device. (This step means unplug?)
Write device details to xenstore -rings, ref, etc
Write in Seabios device details -size, CHS, etc.
Change status in xenstore to plug the PV device
Device is ready to use.


Thanks for your very useful information.
>
> Ian.
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 23:01:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 23:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyAJW-0002ML-ST; Thu, 16 Feb 2012 23:00: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 1RyAJV-0002MG-4c
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 23:00:33 +0000
Received: from [85.158.139.83:56609] by server-3.bemta-5.messagelabs.com id
	F8/38-06438-09A8D3F4; Thu, 16 Feb 2012 23:00:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329433224!14865355!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MDQxOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15729 invoked from network); 16 Feb 2012 23:00:30 -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; 16 Feb 2012 23:00:30 -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 q1GN0LEs030321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 16 Feb 2012 23:00:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1GN0KpW006372
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 16 Feb 2012 23:00:21 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
	q1GN0KFS004734; Thu, 16 Feb 2012 17:00:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 16 Feb 2012 15:00:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E855E41FDD; Thu, 16 Feb 2012 17:57:13 -0500 (EST)
Date: Thu, 16 Feb 2012 17:57:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120216225713.GC2795@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<1329386571.4520.44.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329386571.4520.44.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F3D8A86.00A6,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 10:02:51AM +0000, Wei Liu wrote:
> On Wed, 2012-02-15 at 22:42 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > It also needs this:
> > 
> > From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 15 Feb 2012 17:39:46 -0500
> > Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
> >  built for it.
> > 
> > Otherwise we end up:
> > 
> > BUG: unable to handle kernel paging request at ffff88004000c0c8
> > IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > PGD 1806063 PUD 0
> > 22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
> > 00 [#1] SMP
> > CPU 0
> > Modules linked in:
> > 
> > Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
> > RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
> > .. snip.
> > Call Trace:
> >  [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
> >  [<ffffffff810f4eab>] __free_pages+0x1b/0x40
> >  [<ffffffff810f4f1a>] free_pages+0x4a/0x60
> >  [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
> >  [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
> >  [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
> >  [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
> >  [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/net/xen-netfront.c |   14 +++++++++++++-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 0223552..1eadd90 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -29,6 +29,8 @@
> >   * IN THE SOFTWARE.
> >   */
> >  
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/kernel.h>
> >  #include <linux/netdevice.h>
> > @@ -66,7 +68,7 @@ struct netfront_cb {
> >  
> >  #define GRANT_INVALID_REF	0
> >  
> > -#define XENNET_MAX_RING_PAGE_ORDER 2
> > +#define XENNET_MAX_RING_PAGE_ORDER 4
> 
> I guess this is you tuning with page order? And here is not the only one
> place you changed?

Yup. Was playing with it and saw this blow up.
> 
> As a matter of fact, in the previous patch 8 I encode hard limit 2 on
> the ring page order, your change here will stop FE / BE from connecting.

I think it will work OK - it will just use up to 4 instead of the default two.

> 
> I think I will also need to change this to something like
> 
>   #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> 
> to remind people to modify that value. 

<nods>

> 
> >  #define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
> >  
> >  #define NET_TX_RING_SIZE(_nr_pages)					\
> > @@ -1611,6 +1613,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >  		info->tx_ring_page_order = 0;
> >  		dev_info(&dev->dev, "single tx ring\n");
> >  	} else {
> > +		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> > +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> > +				max_tx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> > +			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> > +		}
> >  		info->tx_ring_page_order = max_tx_ring_page_order;
> >  		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> >  			 max_tx_ring_page_order);
> > @@ -1642,6 +1649,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >  		dev_info(&dev->dev, "single rx ring\n");
> >  	} else {
> >  		info->rx_ring_page_order = max_rx_ring_page_order;
> > +		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> > +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> > +				max_rx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> > +			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> > +		}
> >  		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
> >  			 max_rx_ring_page_order);
> >  	}
> 
> Thanks for this, I will squash it into my patch.

Thanks.
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Feb 16 23:01:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 16 Feb 2012 23:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyAJW-0002ML-ST; Thu, 16 Feb 2012 23:00: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 1RyAJV-0002MG-4c
	for xen-devel@lists.xensource.com; Thu, 16 Feb 2012 23:00:33 +0000
Received: from [85.158.139.83:56609] by server-3.bemta-5.messagelabs.com id
	F8/38-06438-09A8D3F4; Thu, 16 Feb 2012 23:00:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329433224!14865355!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MDQxOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15729 invoked from network); 16 Feb 2012 23:00:30 -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; 16 Feb 2012 23:00:30 -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 q1GN0LEs030321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 16 Feb 2012 23:00:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1GN0KpW006372
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 16 Feb 2012 23:00:21 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
	q1GN0KFS004734; Thu, 16 Feb 2012 17:00:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 16 Feb 2012 15:00:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E855E41FDD; Thu, 16 Feb 2012 17:57:13 -0500 (EST)
Date: Thu, 16 Feb 2012 17:57:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120216225713.GC2795@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<1329386571.4520.44.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329386571.4520.44.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F3D8A86.00A6,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 10:02:51AM +0000, Wei Liu wrote:
> On Wed, 2012-02-15 at 22:42 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 02, 2012 at 04:49:22PM +0000, Wei Liu wrote:
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > It also needs this:
> > 
> > From 4cf97c025792cf073edc4d312b962ecc0b3b67ab Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 15 Feb 2012 17:39:46 -0500
> > Subject: [PATCH] xen/net: Don't try to use all of the rings if we are not
> >  built for it.
> > 
> > Otherwise we end up:
> > 
> > BUG: unable to handle kernel paging request at ffff88004000c0c8
> > IP: [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > PGD 1806063 PUD 0
> > 22:22:34 tst007 logger: /etc/xen/scripts/vif-bridge: offline XENBUS_PATH=backend/vif/1/0
> > 00 [#1] SMP
> > CPU 0
> > Modules linked in:
> > 
> > Pid: 17, comm: xenwatch Not tainted 3.2.0upstream #2 Xen HVM domU
> > RIP: 0010:[<ffffffff810f1ee4>]  [<ffffffff810f1ee4>] free_one_page+0x144/0x410
> > RSP: 0018:ffff88003bea3c40  EFLAGS: 00010046
> > .. snip.
> > Call Trace:
> >  [<ffffffff810f2c7f>] __free_pages_ok+0x9f/0xe0
> >  [<ffffffff810f4eab>] __free_pages+0x1b/0x40
> >  [<ffffffff810f4f1a>] free_pages+0x4a/0x60
> >  [<ffffffff8138b33d>] xennet_disconnect_backend+0xbd/0x130
> >  [<ffffffff8138bd88>] talk_to_netback+0x8e8/0x1160
> >  [<ffffffff812f4e28>] ? xenbus_gather+0xd8/0x170
> >  [<ffffffff8138e3bd>] netback_changed+0xcd/0x550
> >  [<ffffffff812f5bb8>] xenbus_otherend_changed+0xa8/0xb0
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/net/xen-netfront.c |   14 +++++++++++++-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 0223552..1eadd90 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -29,6 +29,8 @@
> >   * IN THE SOFTWARE.
> >   */
> >  
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/kernel.h>
> >  #include <linux/netdevice.h>
> > @@ -66,7 +68,7 @@ struct netfront_cb {
> >  
> >  #define GRANT_INVALID_REF	0
> >  
> > -#define XENNET_MAX_RING_PAGE_ORDER 2
> > +#define XENNET_MAX_RING_PAGE_ORDER 4
> 
> I guess this is you tuning with page order? And here is not the only one
> place you changed?

Yup. Was playing with it and saw this blow up.
> 
> As a matter of fact, in the previous patch 8 I encode hard limit 2 on
> the ring page order, your change here will stop FE / BE from connecting.

I think it will work OK - it will just use up to 4 instead of the default two.

> 
> I think I will also need to change this to something like
> 
>   #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> 
> to remind people to modify that value. 

<nods>

> 
> >  #define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
> >  
> >  #define NET_TX_RING_SIZE(_nr_pages)					\
> > @@ -1611,6 +1613,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >  		info->tx_ring_page_order = 0;
> >  		dev_info(&dev->dev, "single tx ring\n");
> >  	} else {
> > +		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> > +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> > +				max_tx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> > +			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> > +		}
> >  		info->tx_ring_page_order = max_tx_ring_page_order;
> >  		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> >  			 max_tx_ring_page_order);
> > @@ -1642,6 +1649,11 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >  		dev_info(&dev->dev, "single rx ring\n");
> >  	} else {
> >  		info->rx_ring_page_order = max_rx_ring_page_order;
> > +		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
> > +			dev_warn(&dev->dev, "Backend can do %d pages but we can only do %d!\n",
> > +				max_rx_ring_page_order, XENNET_MAX_RING_PAGE_ORDER);
> > +			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> > +		}
> >  		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
> >  			 max_rx_ring_page_order);
> >  	}
> 
> Thanks for this, I will squash it into my patch.

Thanks.
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 00:42:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 00: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.xensource.com>)
	id 1RyBtU-0003Mc-S3; Fri, 17 Feb 2012 00:41:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RyBtS-0003MU-PH
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 00:41:46 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329439297!13687399!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22967 invoked from network); 17 Feb 2012 00:41:39 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 00:41:39 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1H0fZkj016947
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 16 Feb 2012 17:41:36 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F3CCF6F02000078000735D1@nat28.tlf.novell.com>
Date: Thu, 16 Feb 2012 17:41:36 -0700
Message-Id: <49459334-68F4-4998-AA1D-0F1BCEB05C28@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
	<4F3CCF6F02000078000735D1@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 16 Feb 2012 17:41:36 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 16, 2012, at 1:42 AM, Jan Beulich wrote:

> >>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> > Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> >      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
> >      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
> >      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
> >      this value.
> > 
> > This extension first appeared in the FreeBSD Operating System.
>
> Any pointer to their implementation?

http://svnweb.freebsd.org/base/head/sys/dev/xen/

...

> > + * max-request-segments
> > + *      Values:         <uint8_t>
> > + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> > + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
> > + *
> > + *      The maximum value of blkif_request.nr_segments supported by
> > + *      the backend.
> > + *
> > + * max-request-size
> > + *      Values:         <uint32_t>
> > + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> > + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
>
> In particular, wrt the question about a reference to their implementation,
> I don't see why both max-request-segments and max-request-size are
> necessary here and below. What is the intended behavior when the two
> aren't in sync?

The resources needed to deal with fragmentation and overall I/O
request size are distinct.  The goal of the interface is to explicity
indicate both the maximum size and maximum fragmentation (i.e. how
many underutilized segments are allowed) for an I/O.

The FreeBSD block front implementation reserves an extra segment
so that a maximum sized I/O can be transferred even if it does not
start on a page boundary.  I can imagine many reasons why a customized
system may need to handle much higher fragmentation levels.  "Over
provising" the segment count means you can handle this without a
copy to coalesce the fragments.

> > @@ -239,6 +265,33 @@
> >  *      The size of the frontend allocated request ring buffer in units of
> >  *      machine pages.  The value must be a power of 2.
> >  *
> > + * max-requests
> > + *      Values:         <uint32_t>
> > + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> > + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
> > 
>
> max-ring-pages?

Yes.  Nice catch.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 00:42:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 00: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.xensource.com>)
	id 1RyBtU-0003Mc-S3; Fri, 17 Feb 2012 00:41:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RyBtS-0003MU-PH
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 00:41:46 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329439297!13687399!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22967 invoked from network); 17 Feb 2012 00:41:39 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 00:41:39 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1H0fZkj016947
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 16 Feb 2012 17:41:36 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <4F3CCF6F02000078000735D1@nat28.tlf.novell.com>
Date: Thu, 16 Feb 2012 17:41:36 -0700
Message-Id: <49459334-68F4-4998-AA1D-0F1BCEB05C28@spectralogic.com>
References: <patchbomb.1329282413@ns1.eng.sldomain.com>
	<adcb465964c5ea0f0007.1329282417@ns1.eng.sldomain.com>
	<4F3CCF6F02000078000735D1@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Thu, 16 Feb 2012 17:41:36 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Feb 16, 2012, at 1:42 AM, Jan Beulich wrote:

> >>> On 15.02.12 at 06:06, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> > Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> >      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
> >      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
> >      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
> >      this value.
> > 
> > This extension first appeared in the FreeBSD Operating System.
>
> Any pointer to their implementation?

http://svnweb.freebsd.org/base/head/sys/dev/xen/

...

> > + * max-request-segments
> > + *      Values:         <uint8_t>
> > + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> > + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
> > + *
> > + *      The maximum value of blkif_request.nr_segments supported by
> > + *      the backend.
> > + *
> > + * max-request-size
> > + *      Values:         <uint32_t>
> > + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> > + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
>
> In particular, wrt the question about a reference to their implementation,
> I don't see why both max-request-segments and max-request-size are
> necessary here and below. What is the intended behavior when the two
> aren't in sync?

The resources needed to deal with fragmentation and overall I/O
request size are distinct.  The goal of the interface is to explicity
indicate both the maximum size and maximum fragmentation (i.e. how
many underutilized segments are allowed) for an I/O.

The FreeBSD block front implementation reserves an extra segment
so that a maximum sized I/O can be transferred even if it does not
start on a page boundary.  I can imagine many reasons why a customized
system may need to handle much higher fragmentation levels.  "Over
provising" the segment count means you can handle this without a
copy to coalesce the fragments.

> > @@ -239,6 +265,33 @@
> >  *      The size of the frontend allocated request ring buffer in units of
> >  *      machine pages.  The value must be a power of 2.
> >  *
> > + * max-requests
> > + *      Values:         <uint32_t>
> > + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> > + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages)
> > 
>
> max-ring-pages?

Yes.  Nice catch.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 00:54:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 00:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyC5P-0003ab-8V; Fri, 17 Feb 2012 00:54:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyC5N-0003aW-Hb
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 00:54:05 +0000
Received: from [85.158.139.83:32127] by server-11.bemta-5.messagelabs.com id
	8E/BB-14397-C25AD3F4; Fri, 17 Feb 2012 00:54:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329440044!7995146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27310 invoked from network); 17 Feb 2012 00:54:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 00:54:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,433,1325462400"; d="scan'208";a="10759854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 00:54:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 00:54:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyC5L-0007HX-Fg;
	Fri, 17 Feb 2012 00:54:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyC5L-0007Ou-DH;
	Fri, 17 Feb 2012 00:54:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11978-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 00:54:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11978: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11978 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11978/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11976

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b75664e53905
baseline version:
 xen                  01c1bcbc6222

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=b75664e53905
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 b75664e53905
+ branch=xen-unstable
+ revision=b75664e53905
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r b75664e53905 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 10 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 00:54:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 00:54:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyC5P-0003ab-8V; Fri, 17 Feb 2012 00:54:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyC5N-0003aW-Hb
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 00:54:05 +0000
Received: from [85.158.139.83:32127] by server-11.bemta-5.messagelabs.com id
	8E/BB-14397-C25AD3F4; Fri, 17 Feb 2012 00:54:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329440044!7995146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27310 invoked from network); 17 Feb 2012 00:54:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 00:54:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,433,1325462400"; d="scan'208";a="10759854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 00:54:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 00:54:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyC5L-0007HX-Fg;
	Fri, 17 Feb 2012 00:54:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyC5L-0007Ou-DH;
	Fri, 17 Feb 2012 00:54:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11978-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 00:54:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11978: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11978 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11978/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11976

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b75664e53905
baseline version:
 xen                  01c1bcbc6222

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=b75664e53905
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 b75664e53905
+ branch=xen-unstable
+ revision=b75664e53905
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r b75664e53905 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 10 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 03:12:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 03: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.xensource.com>)
	id 1RyEF6-0000AN-TT; Fri, 17 Feb 2012 03:12:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RyEF5-0000AE-34
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 03:12:15 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329448327!13556039!1
X-Originating-IP: [209.85.220.171]
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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15151 invoked from network); 17 Feb 2012 03:12:08 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 03:12:08 -0000
Received: by vcbfo11 with SMTP id fo11so4872217vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 19:12:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A5gPjE1iMTMPGdwMeG0DSv3QLqc7q2iVeS/NKyoy6WQ=;
	b=SKCKw77kbhhODiGJi24DBEmq6aQGtqGfjGXC3ig0BePzvNQY3u5uSen3vFvuY65BiW
	DlnBnqu7XjgsLYxe1amWwtHTdvFEzCZLXLoTOYpX5mO1MYqQD2ELX5eYObPmEmK2CuW+
	5Axc6yGA0ZjdmJvfmIxmYhZ/lnpKIegRYoyqk=
MIME-Version: 1.0
Received: by 10.52.172.202 with SMTP id be10mr2296981vdc.116.1329448326641;
	Thu, 16 Feb 2012 19:12:06 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Thu, 16 Feb 2012 19:12:06 -0800 (PST)
In-Reply-To: <CAP8mzPNRqxcCgj93NWugc7QaZK2XZphVsVfz8jY-0Rbrzc5wbw@mail.gmail.com>
References: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
	<CAP8mzPNRqxcCgj93NWugc7QaZK2XZphVsVfz8jY-0Rbrzc5wbw@mail.gmail.com>
Date: Fri, 17 Feb 2012 11:12:06 +0800
Message-ID: <CABpY8MKw3xvfXcAgUw0pVaYXgM69EHd=1knU_kYpNs6Dr-CTyQ@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: rshriram@cs.ubc.ca
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Where's the entry code of backup host in Remus?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4395802429989011840=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4395802429989011840==
Content-Type: multipart/alternative; boundary=bcaec51b18af41b7e204b9204fa2

--bcaec51b18af41b7e204b9204fa2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 17, 2012 at 12:49 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>w=
rote:

> Look for the entry point into the live migration code, on the receiver
> host.
>
> Start with tools/python/xen/xend/XendCheckpoint.py
>  def restore(xd, fd, dominfo =3D None, paused =3D False, relocating =3D F=
alse)
>   --forks off xc_restore and waits for it to complete.
>   ------xc_restore calls xc_domain_restore
>
>
> hope that helps.
>
> cheers
> shriram
>
> On Thu, Feb 16, 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 <Chunqi Li> =
<yzt356@gmail.com> wrote:
>
>> Hi all,
>> I'm reading Remus part of Xen 4.x code and now I can find the entry code
>> of Primary host, which is located in tools/remus directory. But I cannot
>> find the entry code of backup host. Which codes will the backup host
>> execute when the primary code send header of a VM? I can only find some
>> codes are executed in tools/libxc/xc_domain_restore.c, which restores th=
e
>> backup VM as soon as the Primary VM stops. When the backup
>> host synchronizing the state of primary VM (including machine state, mem=
ory
>> state and disk state), which part of code will be execute?
>>
>> Thanks.
>>
>> --
>> Regards, Chunqi Li
>> Department of Computer Science
>> School of EECS
>> Peking University
>> Beijing, China
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>
I find it, thanks very much.

--=20
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--bcaec51b18af41b7e204b9204fa2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 12:49 AM, Shriram Ra=
jagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshri=
ram@cs.ubc.ca</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">
Look for the entry point into the live migration code, on the receiver host=
.<br><br>Start with tools/python/xen/xend/XendCheckpoint.py<br>=C2=A0def re=
store(xd, fd, dominfo =3D None, paused =3D False, relocating =3D False)<br>=
=C2=A0 --forks off xc_restore and waits for it to complete.<br>


=C2=A0 ------xc_restore calls xc_domain_restore<br><br><br>hope that helps.=
<br><br>cheers<br>shriram<br><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On Thu, Feb 16, 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 &lt;Ch=
unqi Li&gt; <span dir=3D"ltr">&lt;<a href=3D"mailto:yzt356@gmail.com" targe=
t=3D"_blank">yzt356@gmail.com</a>&gt;</span> wrote:<br>


</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">Hi all,<d=
iv>I&#39;m reading Remus part of Xen 4.x code and now I can find the entry =
code of Primary host, which is located in tools/remus directory. But I cann=
ot find the entry code of backup host. Which codes will the backup host exe=
cute when the primary code send header of a VM? I can only find some codes =
are executed in tools/libxc/xc_domain_restore.c, which restores the backup =
VM as soon as the Primary VM stops. When the backup host=C2=A0synchronizing=
 the state of primary VM (including machine state, memory state and disk st=
ate), which part of code will be execute?</div>



<div><br></div><div>Thanks.</div><span><font color=3D"#888888"><div><br>-- =
<br>Regards, Chunqi Li<br>Department of Computer Science<br>School of EECS<=
br>Peking University<br>Beijing, China<br>
</div>
</font></span><br></div></div>_____________________________________________=
__<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br>I find it, thanks very much.<br clear=3D"all"><div><=
br></div>-- <br>Chunqi Li<br>Department of Computer Science<br>School of EE=
CS<br>Peking University<br>Beijing, China<br>

--bcaec51b18af41b7e204b9204fa2--


--===============4395802429989011840==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4395802429989011840==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 03:12:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 03: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.xensource.com>)
	id 1RyEF6-0000AN-TT; Fri, 17 Feb 2012 03:12:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RyEF5-0000AE-34
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 03:12:15 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329448327!13556039!1
X-Originating-IP: [209.85.220.171]
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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15151 invoked from network); 17 Feb 2012 03:12:08 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 03:12:08 -0000
Received: by vcbfo11 with SMTP id fo11so4872217vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 19:12:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A5gPjE1iMTMPGdwMeG0DSv3QLqc7q2iVeS/NKyoy6WQ=;
	b=SKCKw77kbhhODiGJi24DBEmq6aQGtqGfjGXC3ig0BePzvNQY3u5uSen3vFvuY65BiW
	DlnBnqu7XjgsLYxe1amWwtHTdvFEzCZLXLoTOYpX5mO1MYqQD2ELX5eYObPmEmK2CuW+
	5Axc6yGA0ZjdmJvfmIxmYhZ/lnpKIegRYoyqk=
MIME-Version: 1.0
Received: by 10.52.172.202 with SMTP id be10mr2296981vdc.116.1329448326641;
	Thu, 16 Feb 2012 19:12:06 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Thu, 16 Feb 2012 19:12:06 -0800 (PST)
In-Reply-To: <CAP8mzPNRqxcCgj93NWugc7QaZK2XZphVsVfz8jY-0Rbrzc5wbw@mail.gmail.com>
References: <CABpY8M+YFR_Pu_e8zjJsr5htnHd2iyQUEDN0iz3L=fkxTBvfbQ@mail.gmail.com>
	<CAP8mzPNRqxcCgj93NWugc7QaZK2XZphVsVfz8jY-0Rbrzc5wbw@mail.gmail.com>
Date: Fri, 17 Feb 2012 11:12:06 +0800
Message-ID: <CABpY8MKw3xvfXcAgUw0pVaYXgM69EHd=1knU_kYpNs6Dr-CTyQ@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: rshriram@cs.ubc.ca
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Where's the entry code of backup host in Remus?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4395802429989011840=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4395802429989011840==
Content-Type: multipart/alternative; boundary=bcaec51b18af41b7e204b9204fa2

--bcaec51b18af41b7e204b9204fa2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 17, 2012 at 12:49 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>w=
rote:

> Look for the entry point into the live migration code, on the receiver
> host.
>
> Start with tools/python/xen/xend/XendCheckpoint.py
>  def restore(xd, fd, dominfo =3D None, paused =3D False, relocating =3D F=
alse)
>   --forks off xc_restore and waits for it to complete.
>   ------xc_restore calls xc_domain_restore
>
>
> hope that helps.
>
> cheers
> shriram
>
> On Thu, Feb 16, 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 <Chunqi Li> =
<yzt356@gmail.com> wrote:
>
>> Hi all,
>> I'm reading Remus part of Xen 4.x code and now I can find the entry code
>> of Primary host, which is located in tools/remus directory. But I cannot
>> find the entry code of backup host. Which codes will the backup host
>> execute when the primary code send header of a VM? I can only find some
>> codes are executed in tools/libxc/xc_domain_restore.c, which restores th=
e
>> backup VM as soon as the Primary VM stops. When the backup
>> host synchronizing the state of primary VM (including machine state, mem=
ory
>> state and disk state), which part of code will be execute?
>>
>> Thanks.
>>
>> --
>> Regards, Chunqi Li
>> Department of Computer Science
>> School of EECS
>> Peking University
>> Beijing, China
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>
I find it, thanks very much.

--=20
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--bcaec51b18af41b7e204b9204fa2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 12:49 AM, Shriram Ra=
jagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshri=
ram@cs.ubc.ca</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">
Look for the entry point into the live migration code, on the receiver host=
.<br><br>Start with tools/python/xen/xend/XendCheckpoint.py<br>=C2=A0def re=
store(xd, fd, dominfo =3D None, paused =3D False, relocating =3D False)<br>=
=C2=A0 --forks off xc_restore and waits for it to complete.<br>


=C2=A0 ------xc_restore calls xc_domain_restore<br><br><br>hope that helps.=
<br><br>cheers<br>shriram<br><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On Thu, Feb 16, 2012 at 3:13 AM, =E6=9D=8E=E6=98=A5=E5=A5=87 &lt;Ch=
unqi Li&gt; <span dir=3D"ltr">&lt;<a href=3D"mailto:yzt356@gmail.com" targe=
t=3D"_blank">yzt356@gmail.com</a>&gt;</span> wrote:<br>


</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">Hi all,<d=
iv>I&#39;m reading Remus part of Xen 4.x code and now I can find the entry =
code of Primary host, which is located in tools/remus directory. But I cann=
ot find the entry code of backup host. Which codes will the backup host exe=
cute when the primary code send header of a VM? I can only find some codes =
are executed in tools/libxc/xc_domain_restore.c, which restores the backup =
VM as soon as the Primary VM stops. When the backup host=C2=A0synchronizing=
 the state of primary VM (including machine state, memory state and disk st=
ate), which part of code will be execute?</div>



<div><br></div><div>Thanks.</div><span><font color=3D"#888888"><div><br>-- =
<br>Regards, Chunqi Li<br>Department of Computer Science<br>School of EECS<=
br>Peking University<br>Beijing, China<br>
</div>
</font></span><br></div></div>_____________________________________________=
__<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br>
</blockquote></div><br>I find it, thanks very much.<br clear=3D"all"><div><=
br></div>-- <br>Chunqi Li<br>Department of Computer Science<br>School of EE=
CS<br>Peking University<br>Beijing, China<br>

--bcaec51b18af41b7e204b9204fa2--


--===============4395802429989011840==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4395802429989011840==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 04:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 04: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.xensource.com>)
	id 1RyFjE-000176-39; Fri, 17 Feb 2012 04:47:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RyFjD-00016v-0J
	for Xen-devel@lists.xensource.com; Fri, 17 Feb 2012 04:47:27 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329454040!13720582!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18739 invoked from network); 17 Feb 2012 04:47:20 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 04:47:20 -0000
Received: by lagp5 with SMTP id p5so4619275lag.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 20:47:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/kBehtAAlkNZ2BGlBi2mQ1aiLPp3+pC4s4pD2gxuAII=;
	b=WRys8254l54VcGTuXspI8f7p5V0ENBh+oDSQvMiRGLbWW9eGvvnF6MJfTQ6VOVKS74
	Ov86oBUYlHEAUYDp3L0PtMYrhvcqLWl8Rmcy4dla18vuHvLYqipZU0LOOsqD9MLa8f3h
	iUc8VL5VnaTF+5PTxC+k2CSiCf2JV2VPIdsE4=
MIME-Version: 1.0
Received: by 10.112.44.232 with SMTP id h8mr2008613lbm.85.1329454040108; Thu,
	16 Feb 2012 20:47:20 -0800 (PST)
Received: by 10.112.84.193 with HTTP; Thu, 16 Feb 2012 20:47:20 -0800 (PST)
Date: Fri, 17 Feb 2012 12:47:20 +0800
Message-ID: <CANqQZNHc11vDEbkT2_JMER7FWeqdSQi+5_n1gN36BnJGs8mDiA@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] will softirq handler potentially be called
	many times?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I see the __do_softirq is called when ! in_atomic(), which means
potentially __do_softirq may be interrupted by trap, exception,
interrupt, etc, so seems softirq handler may be executed many times?

For example, if interrupt happens after i =
find_first_set_bit(pending), the same softirq hander will be called
twice as the do_softriq will be called after all interrupt handler
returned, and the pending bit has not been cleared yet when first
do_softirq was called.

static void __do_softirq(unsigned long ignore_mask)
{
    ......
    for ( ; ; )
    {
        ......
        i = find_first_set_bit(pending);
                                                   <- interrupt happens
        clear_bit(i, &softirq_pending(cpu));
        (*softirq_handlers[i])();
    }
}

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 04:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 04: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.xensource.com>)
	id 1RyFjE-000176-39; Fri, 17 Feb 2012 04:47:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RyFjD-00016v-0J
	for Xen-devel@lists.xensource.com; Fri, 17 Feb 2012 04:47:27 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329454040!13720582!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18739 invoked from network); 17 Feb 2012 04:47:20 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 04:47:20 -0000
Received: by lagp5 with SMTP id p5so4619275lag.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 20:47:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/kBehtAAlkNZ2BGlBi2mQ1aiLPp3+pC4s4pD2gxuAII=;
	b=WRys8254l54VcGTuXspI8f7p5V0ENBh+oDSQvMiRGLbWW9eGvvnF6MJfTQ6VOVKS74
	Ov86oBUYlHEAUYDp3L0PtMYrhvcqLWl8Rmcy4dla18vuHvLYqipZU0LOOsqD9MLa8f3h
	iUc8VL5VnaTF+5PTxC+k2CSiCf2JV2VPIdsE4=
MIME-Version: 1.0
Received: by 10.112.44.232 with SMTP id h8mr2008613lbm.85.1329454040108; Thu,
	16 Feb 2012 20:47:20 -0800 (PST)
Received: by 10.112.84.193 with HTTP; Thu, 16 Feb 2012 20:47:20 -0800 (PST)
Date: Fri, 17 Feb 2012 12:47:20 +0800
Message-ID: <CANqQZNHc11vDEbkT2_JMER7FWeqdSQi+5_n1gN36BnJGs8mDiA@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] will softirq handler potentially be called
	many times?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I see the __do_softirq is called when ! in_atomic(), which means
potentially __do_softirq may be interrupted by trap, exception,
interrupt, etc, so seems softirq handler may be executed many times?

For example, if interrupt happens after i =
find_first_set_bit(pending), the same softirq hander will be called
twice as the do_softriq will be called after all interrupt handler
returned, and the pending bit has not been cleared yet when first
do_softirq was called.

static void __do_softirq(unsigned long ignore_mask)
{
    ......
    for ( ; ; )
    {
        ......
        i = find_first_set_bit(pending);
                                                   <- interrupt happens
        clear_bit(i, &softirq_pending(cpu));
        (*softirq_handlers[i])();
    }
}

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 04:53:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 04:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyFoV-0001Fb-R0; Fri, 17 Feb 2012 04:52:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RyFoU-0001FR-CV
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 04:52:54 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329454366!14679111!1
X-Originating-IP: [209.85.212.65]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26416 invoked from network); 17 Feb 2012 04:52:47 -0000
Received: from mail-vw0-f65.google.com (HELO mail-vw0-f65.google.com)
	(209.85.212.65)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 04:52:47 -0000
Received: by vbbez10 with SMTP id ez10so205547vbb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 20:52:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=p/zfMMwr0VYIpFHfranYhG9gErvTfJ3du6qWr5BIDYw=;
	b=NoVvaZt7Ty781lqnju2QtuyIhlKK0mAj1iN0n7/WkBL0uFncDm409gBIaJUAA1G6P5
	Z+VzuEhpUGI9GrVP+/JE8jalRGjbKCQ5LOgOCTBMU8lJrQrJBMnb8rkjNAlfRHdTTgXZ
	GRkxLCK3HDhUjHzhKKtcWaG4UVr7DowhtIngo=
MIME-Version: 1.0
Received: by 10.52.178.40 with SMTP id cv8mr2437645vdc.82.1329454366461; Thu,
	16 Feb 2012 20:52:46 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Thu, 16 Feb 2012 20:52:46 -0800 (PST)
Date: Fri, 17 Feb 2012 12:52:46 +0800
Message-ID: <CABpY8M+o0ACrdTwU=8it1VrS+kvAV31ok9zq=OezHbZE=MBN7g@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [question]What strategy of Memory Compression does
	Remus use
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3304687021575995335=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3304687021575995335==
Content-Type: multipart/alternative; boundary=20cf3071caf84210bd04b921b768

--20cf3071caf84210bd04b921b768
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I found this line in  http://wiki.xen.org/wiki/Remus
Checkpoint compression for less data to transfer between hosts.
in Xen 4.2 (xen-unstable development branch).

So I want to know what checkpoint compression algorithm does Remus use in
the most recently devel branch of Xen 4.2?

Thank you.

-- 
Regards, Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3071caf84210bd04b921b768
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I found this line in=A0
<a href=3D"http://wiki.xen.org/wiki/Remus">http://wiki.xen.org/wiki/Remus</=
a></div><div><span style=3D"font-family:sans-serif;font-size:13px;line-heig=
ht:19px;background-color:rgb(255,255,255)">Checkpoint compression for less =
data to transfer between hosts.</span>=A0</div>
<div>in Xen 4.2 (xen-unstable development branch).</div><div><br></div><div=
>So I want to know what checkpoint compression=A0algorithm=A0does Remus use=
 in the most recently devel branch of Xen 4.2?</div><div><br></div><div>Tha=
nk you.<br clear=3D"all">
<div><br></div>-- <br>Regards, Chunqi Li<br>Department of Computer Science<=
br>School of EECS<br>Peking University<br>Beijing, China<br>
</div>

--20cf3071caf84210bd04b921b768--


--===============3304687021575995335==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3304687021575995335==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 04:53:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 04:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyFoV-0001Fb-R0; Fri, 17 Feb 2012 04:52:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1RyFoU-0001FR-CV
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 04:52:54 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329454366!14679111!1
X-Originating-IP: [209.85.212.65]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26416 invoked from network); 17 Feb 2012 04:52:47 -0000
Received: from mail-vw0-f65.google.com (HELO mail-vw0-f65.google.com)
	(209.85.212.65)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 04:52:47 -0000
Received: by vbbez10 with SMTP id ez10so205547vbb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 20:52:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=p/zfMMwr0VYIpFHfranYhG9gErvTfJ3du6qWr5BIDYw=;
	b=NoVvaZt7Ty781lqnju2QtuyIhlKK0mAj1iN0n7/WkBL0uFncDm409gBIaJUAA1G6P5
	Z+VzuEhpUGI9GrVP+/JE8jalRGjbKCQ5LOgOCTBMU8lJrQrJBMnb8rkjNAlfRHdTTgXZ
	GRkxLCK3HDhUjHzhKKtcWaG4UVr7DowhtIngo=
MIME-Version: 1.0
Received: by 10.52.178.40 with SMTP id cv8mr2437645vdc.82.1329454366461; Thu,
	16 Feb 2012 20:52:46 -0800 (PST)
Received: by 10.52.156.225 with HTTP; Thu, 16 Feb 2012 20:52:46 -0800 (PST)
Date: Fri, 17 Feb 2012 12:52:46 +0800
Message-ID: <CABpY8M+o0ACrdTwU=8it1VrS+kvAV31ok9zq=OezHbZE=MBN7g@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [question]What strategy of Memory Compression does
	Remus use
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3304687021575995335=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3304687021575995335==
Content-Type: multipart/alternative; boundary=20cf3071caf84210bd04b921b768

--20cf3071caf84210bd04b921b768
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I found this line in  http://wiki.xen.org/wiki/Remus
Checkpoint compression for less data to transfer between hosts.
in Xen 4.2 (xen-unstable development branch).

So I want to know what checkpoint compression algorithm does Remus use in
the most recently devel branch of Xen 4.2?

Thank you.

-- 
Regards, Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf3071caf84210bd04b921b768
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I found this line in=A0
<a href=3D"http://wiki.xen.org/wiki/Remus">http://wiki.xen.org/wiki/Remus</=
a></div><div><span style=3D"font-family:sans-serif;font-size:13px;line-heig=
ht:19px;background-color:rgb(255,255,255)">Checkpoint compression for less =
data to transfer between hosts.</span>=A0</div>
<div>in Xen 4.2 (xen-unstable development branch).</div><div><br></div><div=
>So I want to know what checkpoint compression=A0algorithm=A0does Remus use=
 in the most recently devel branch of Xen 4.2?</div><div><br></div><div>Tha=
nk you.<br clear=3D"all">
<div><br></div>-- <br>Regards, Chunqi Li<br>Department of Computer Science<=
br>School of EECS<br>Peking University<br>Beijing, China<br>
</div>

--20cf3071caf84210bd04b921b768--


--===============3304687021575995335==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3304687021575995335==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 05:36:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 05: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.xensource.com>)
	id 1RyGUc-00026T-Fy; Fri, 17 Feb 2012 05:36:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RyGUa-00026O-H2
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 05:36:24 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329456977!14619699!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13609 invoked from network); 17 Feb 2012 05:36:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 05:36:18 -0000
Received: by werb14 with SMTP id b14so5568325wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 21:36:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=MPzjk9yjpFV27jIZ3UHKmvyZkBliI/HzOoTQl3pYY8w=;
	b=TH8c4IArtTSI6kuR8NlAbYXcw++pbG2d5qEOfjPVSfSfitQu1E55JWfxKk5fkMpDKN
	v4TJH+0WyVITFL1oaIpcbRoqo17YFLitU2AqOejDXn5E9d5M++WKE5wcgFL0Xd8WXi66
	/4vKJ5Z2wzWJGLhQ8BVWLqedkHa0Q+VhXydS0=
MIME-Version: 1.0
Received: by 10.180.99.65 with SMTP id eo1mr1135590wib.13.1329456977348; Thu,
	16 Feb 2012 21:36:17 -0800 (PST)
Received: by 10.180.101.167 with HTTP; Thu, 16 Feb 2012 21:36:17 -0800 (PST)
Date: Thu, 16 Feb 2012 22:36:17 -0700
Message-ID: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7152374400616179123=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7152374400616179123==
Content-Type: multipart/alternative; boundary=f46d04428e5ee1080c04b9225212

--f46d04428e5ee1080c04b9225212
Content-Type: text/plain; charset=ISO-8859-1

I am trying to create arch linux package xen 4.2 unstable . It builds mots
of xen fine but I get error with xl_cmdimpl.c
4.2/src/xen-unstable.git-build/tools/libxl/../../tools/include  -c -o
xl_cmdimpl.o xl_cmdimpl.c
xl_cmdimpl.c: In function 'printf_info':
xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=unused-value]
xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this function)
xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only once
for each function it appears in
xl_cmdimpl.c:306:5: error: too many arguments to function 'yajl_gen_alloc'
/usr/include/yajl/yajl_gen.h:118:23: note: declared here
xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf' from
incompatible pointer type [-Werror]
/usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but argument
is of type 'unsigned int *'
cc1: all warnings being treated as errors
I saw this error mentioned I wonder if there is patch

--f46d04428e5ee1080c04b9225212
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I am trying to create arch linux package xen 4.2 unstable . It builds =
mots of xen fine but I get error with xl_cmdimpl.c</div>
<div>4.2/src/xen-unstable.git-build/tools/libxl/../../tools/include=A0 -c -=
o xl_cmdimpl.o xl_cmdimpl.c<br>xl_cmdimpl.c: In function &#39;printf_info&#=
39;:<br>xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=3Dunus=
ed-value]<br>
xl_cmdimpl.c:300:21: error: expected &#39;;&#39; before &#39;conf&#39;<br>x=
l_cmdimpl.c:306:28: error: &#39;conf&#39; undeclared (first use in this fun=
ction)<br>xl_cmdimpl.c:306:28: note: each undeclared identifier is reported=
 only once for each function it appears in<br>
xl_cmdimpl.c:306:5: error: too many arguments to function &#39;yajl_gen_all=
oc&#39;<br>/usr/include/yajl/yajl_gen.h:118:23: note: declared here<br>xl_c=
mdimpl.c:339:5: error: passing argument 3 of &#39;yajl_gen_get_buf&#39; fro=
m incompatible pointer type [-Werror]<br>
/usr/include/yajl/yajl_gen.h:144:30: note: expected &#39;size_t *&#39; but =
argument is of type &#39;unsigned int *&#39;<br>cc1: all warnings being tre=
ated as errors<br>I saw this error mentioned I wonder if there is patch </d=
iv>

--f46d04428e5ee1080c04b9225212--


--===============7152374400616179123==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7152374400616179123==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 05:36:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 05: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.xensource.com>)
	id 1RyGUc-00026T-Fy; Fri, 17 Feb 2012 05:36:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RyGUa-00026O-H2
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 05:36:24 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329456977!14619699!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13609 invoked from network); 17 Feb 2012 05:36:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 05:36:18 -0000
Received: by werb14 with SMTP id b14so5568325wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 16 Feb 2012 21:36:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=MPzjk9yjpFV27jIZ3UHKmvyZkBliI/HzOoTQl3pYY8w=;
	b=TH8c4IArtTSI6kuR8NlAbYXcw++pbG2d5qEOfjPVSfSfitQu1E55JWfxKk5fkMpDKN
	v4TJH+0WyVITFL1oaIpcbRoqo17YFLitU2AqOejDXn5E9d5M++WKE5wcgFL0Xd8WXi66
	/4vKJ5Z2wzWJGLhQ8BVWLqedkHa0Q+VhXydS0=
MIME-Version: 1.0
Received: by 10.180.99.65 with SMTP id eo1mr1135590wib.13.1329456977348; Thu,
	16 Feb 2012 21:36:17 -0800 (PST)
Received: by 10.180.101.167 with HTTP; Thu, 16 Feb 2012 21:36:17 -0800 (PST)
Date: Thu, 16 Feb 2012 22:36:17 -0700
Message-ID: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7152374400616179123=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7152374400616179123==
Content-Type: multipart/alternative; boundary=f46d04428e5ee1080c04b9225212

--f46d04428e5ee1080c04b9225212
Content-Type: text/plain; charset=ISO-8859-1

I am trying to create arch linux package xen 4.2 unstable . It builds mots
of xen fine but I get error with xl_cmdimpl.c
4.2/src/xen-unstable.git-build/tools/libxl/../../tools/include  -c -o
xl_cmdimpl.o xl_cmdimpl.c
xl_cmdimpl.c: In function 'printf_info':
xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=unused-value]
xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this function)
xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only once
for each function it appears in
xl_cmdimpl.c:306:5: error: too many arguments to function 'yajl_gen_alloc'
/usr/include/yajl/yajl_gen.h:118:23: note: declared here
xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf' from
incompatible pointer type [-Werror]
/usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but argument
is of type 'unsigned int *'
cc1: all warnings being treated as errors
I saw this error mentioned I wonder if there is patch

--f46d04428e5ee1080c04b9225212
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I am trying to create arch linux package xen 4.2 unstable . It builds =
mots of xen fine but I get error with xl_cmdimpl.c</div>
<div>4.2/src/xen-unstable.git-build/tools/libxl/../../tools/include=A0 -c -=
o xl_cmdimpl.o xl_cmdimpl.c<br>xl_cmdimpl.c: In function &#39;printf_info&#=
39;:<br>xl_cmdimpl.c:300:5: error: statement with no effect [-Werror=3Dunus=
ed-value]<br>
xl_cmdimpl.c:300:21: error: expected &#39;;&#39; before &#39;conf&#39;<br>x=
l_cmdimpl.c:306:28: error: &#39;conf&#39; undeclared (first use in this fun=
ction)<br>xl_cmdimpl.c:306:28: note: each undeclared identifier is reported=
 only once for each function it appears in<br>
xl_cmdimpl.c:306:5: error: too many arguments to function &#39;yajl_gen_all=
oc&#39;<br>/usr/include/yajl/yajl_gen.h:118:23: note: declared here<br>xl_c=
mdimpl.c:339:5: error: passing argument 3 of &#39;yajl_gen_get_buf&#39; fro=
m incompatible pointer type [-Werror]<br>
/usr/include/yajl/yajl_gen.h:144:30: note: expected &#39;size_t *&#39; but =
argument is of type &#39;unsigned int *&#39;<br>cc1: all warnings being tre=
ated as errors<br>I saw this error mentioned I wonder if there is patch </d=
iv>

--f46d04428e5ee1080c04b9225212--


--===============7152374400616179123==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7152374400616179123==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 06:22:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 06:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyHCv-0002tD-5O; Fri, 17 Feb 2012 06:22:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RyHCt-0002t5-NI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 06:22:11 +0000
Received: from [85.158.139.83:60219] by server-4.bemta-5.messagelabs.com id
	9C/89-10788-212FD3F4; Fri, 17 Feb 2012 06:22:10 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329459728!12732932!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMjYxNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30705 invoked from network); 17 Feb 2012 06:22:09 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-4.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 06:22:09 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZI002QZXOUFF@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:22:06 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZI007TJXOD7C@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:22:06 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGX22717; Fri,
	17 Feb 2012 14:22:05 +0800
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162)
	by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 14:21:54 +0800
Received: from h00166998 (10.166.80.196) by szxeml423-hub.china.huawei.com
	(10.82.67.162) with Microsoft SMTP Server id 14.1.323.3; Fri,
	17 Feb 2012 14:21:58 +0800
Date: Fri, 17 Feb 2012 14:21:54 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <1329298049.31256.277.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Message-id: <004201cced3c$73b1baf0$5b1530d0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczrxQRKrzjUe/ISR2OS9sH1lMHn7wBYlBbA
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
	<1329298049.31256.277.camel@zakaz.uk.xensource.com>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, February 15, 2012 5:27 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> 
> On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > > how xenpaging works but why does paging need a domU event channel
> > > anyway? Surely paging is transparent to the guest.
> > >
> > > Or is this really a dom0<->Xen event channel which just appears to be
> > > assigned to the guest?
> >
> > In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> [...]
> > > Who assigns this remote domain port? Shouldn't it either be closed when
> > > the dom0 end is closed or retained such that it can be reused each time
> > > instead of leaking?
> >
> >   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> > and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> > leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.
> 
> The two ends of that event channel are actually dom0 and Xen, because
> chn->xen_consumer is not NULL, even though the Xen end does live in the
> domU evtchn address space. It is not exactly dom0 and domU as you
> suggest, which is where my confused question arose.

   See what xenpaging_init() does when xenpaging is launched:
   xc_mem_paging_enable() ---> this function allocate a event channel of domain U, the remote port is stored in paging->mem_event.shared_page->port
            |
            V
    Xc_event_bind_interdomain() --> this function bind dom0 with domU port allocated above

   But when xenpaging is tear down:
   xc_mem_paging_disable()  -->  do nothing about event channel
            |
            V
   xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU )  ECS_UNBOUND


 Hong Kaixing.

> 
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 06:22:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 06:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyHCv-0002tD-5O; Fri, 17 Feb 2012 06:22:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RyHCt-0002t5-NI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 06:22:11 +0000
Received: from [85.158.139.83:60219] by server-4.bemta-5.messagelabs.com id
	9C/89-10788-212FD3F4; Fri, 17 Feb 2012 06:22:10 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329459728!12732932!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMjYxNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30705 invoked from network); 17 Feb 2012 06:22:09 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-4.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 06:22:09 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZI002QZXOUFF@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:22:06 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZI007TJXOD7C@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:22:06 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGX22717; Fri,
	17 Feb 2012 14:22:05 +0800
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162)
	by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 14:21:54 +0800
Received: from h00166998 (10.166.80.196) by szxeml423-hub.china.huawei.com
	(10.82.67.162) with Microsoft SMTP Server id 14.1.323.3; Fri,
	17 Feb 2012 14:21:58 +0800
Date: Fri, 17 Feb 2012 14:21:54 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <1329298049.31256.277.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Message-id: <004201cced3c$73b1baf0$5b1530d0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczrxQRKrzjUe/ISR2OS9sH1lMHn7wBYlBbA
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
	<1329298049.31256.277.camel@zakaz.uk.xensource.com>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, February 15, 2012 5:27 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> 
> On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > > how xenpaging works but why does paging need a domU event channel
> > > anyway? Surely paging is transparent to the guest.
> > >
> > > Or is this really a dom0<->Xen event channel which just appears to be
> > > assigned to the guest?
> >
> > In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> [...]
> > > Who assigns this remote domain port? Shouldn't it either be closed when
> > > the dom0 end is closed or retained such that it can be reused each time
> > > instead of leaking?
> >
> >   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> > and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> > leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.
> 
> The two ends of that event channel are actually dom0 and Xen, because
> chn->xen_consumer is not NULL, even though the Xen end does live in the
> domU evtchn address space. It is not exactly dom0 and domU as you
> suggest, which is where my confused question arose.

   See what xenpaging_init() does when xenpaging is launched:
   xc_mem_paging_enable() ---> this function allocate a event channel of domain U, the remote port is stored in paging->mem_event.shared_page->port
            |
            V
    Xc_event_bind_interdomain() --> this function bind dom0 with domU port allocated above

   But when xenpaging is tear down:
   xc_mem_paging_disable()  -->  do nothing about event channel
            |
            V
   xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU )  ECS_UNBOUND


 Hong Kaixing.

> 
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 06:27:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 06: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.xensource.com>)
	id 1RyHHf-00030h-T4; Fri, 17 Feb 2012 06:27:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyHHe-00030a-9X
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 06:27:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329460020!15167217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1386 invoked from network); 17 Feb 2012 06:27:00 -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 Feb 2012 06:27:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,434,1325462400"; d="scan'208";a="10762451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 06:26:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 06:26:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyHHX-00019i-BS;
	Fri, 17 Feb 2012 06:26:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyHHX-00034L-6r;
	Fri, 17 Feb 2012 06:26:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11979-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 06:26:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11979: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11979 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11979/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11978

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b75664e53905
baseline version:
 xen                  b75664e53905

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 06:27:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 06: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.xensource.com>)
	id 1RyHHf-00030h-T4; Fri, 17 Feb 2012 06:27:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyHHe-00030a-9X
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 06:27:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329460020!15167217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1386 invoked from network); 17 Feb 2012 06:27:00 -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 Feb 2012 06:27:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,434,1325462400"; d="scan'208";a="10762451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 06:26:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 06:26:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyHHX-00019i-BS;
	Fri, 17 Feb 2012 06:26:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyHHX-00034L-6r;
	Fri, 17 Feb 2012 06:26:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11979-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 06:26:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11979: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11979 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11979/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11978

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b75664e53905
baseline version:
 xen                  b75664e53905

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 07:16:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 07:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyI2b-0003Tr-H6; Fri, 17 Feb 2012 07:15:37 +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 1RyI2Z-0003Tm-TB
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 07:15:36 +0000
Received: from [85.158.139.83:6208] by server-11.bemta-5.messagelabs.com id
	C5/A4-14397-79EFD3F4; Fri, 17 Feb 2012 07:15:35 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329462932!8109389!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9395 invoked from network); 17 Feb 2012 07:15:34 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 07:15:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=kYFGMaoaQL+J
	dyqQgx+DdrWH6cI=; b=MtJcVmobAwhE0lcfGoNfClh7dvMv8rsp0RwjvEXJhaeW
	rMdxa1SIPHLc418KeUuzI9tHyUmyZQ59gaGgdZsWuEbcd3hoLyDANADsUtXmCxBp
	eXQ+bwAST5jnE+Fa4EFcqkS7agpKeY6bmezxJEbMlGyNR2briBz6IhNgF7oPZOI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=rzvHQ2
	Ngqi3140L4DGV3Yk45Itk+sehO7hNeilTAmWQER8zuQopCoa+U7eMG7tm8H6UAMI
	Gl2ar3HqdTNRujMDstE2KqUvGlao0ixXBUMVkZvg1xudMOr00o5ifR5YoZ9xNtX0
	6ObiZ3AmhYkmgW/DdZRJLevMKA1i3+H/Movwk=
Received: (qmail 5422 invoked from network); 17 Feb 2012 07:15:31 -0000
X-AntiVirus: Clean
Received: from 216-19-182-203.dyn.novuscom.net (HELO ?192.168.1.102?)
	(nathan@gt.net@216.19.182.203)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	17 Feb 2012 07:15:31 -0000
Message-ID: <4F3DFE96.2030803@gt.net>
Date: Thu, 16 Feb 2012 23:15:34 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
In-Reply-To: <20120201013036.GA12637@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/31/2012 5:30 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 31, 2012 at 01:42:23PM -0800, Nathan March wrote:
>> Hi All,
>>
>> We've got a xen setup based around a dell iscsi device with each xen
>> host having 2 lun's, we then run multipath on top of that. After adding
>> a couple new virtual disks the other day, a couple of our online stable
>> VM's suddenly hard locked up. Attaching to the console gave me nothing,
>> looked like they lost their disk devices.
>>
>> Attempting to restart them on the same dom0 failed with hot plug errors,
>> as did attempting to start them on a few different dom0's. After doing a
>> "multipath -F" to remove unused devices and manually bringing in just
>> the selected LUN's via "multipath diskname", I was able to successfully
>> start them. This initially made me think perhaps I was hitting some sort
>> of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun
>> = 1088 iscsi connections). Just to be clear, the problem occurred on
>> multiple dom0's at the same time so it definitely seems iscsi related.
>>
>> Now, a day later, I'm debugging this further and I'm again unable to
>> start VM's, even with all extra multipath devices removed. I rebooted
>> one of the dom0's and was able to successfully migrate our production
>> VM's off a broken server, so I've now got an empty dom0 that's unable to
>> start any vm's.
>>
>> Starting a VM results in the following in xend.log:
>>
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:628)
>> hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
>> [2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices
>> failed.
>> Traceback (most recent call last):
>>    File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line
>> 85, in perform
>>      return op_method(op, req)
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line
>> 85, in op_wait_for_devices
>>      return self.dom.waitForDevices()
>>    File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
>> line 1237, in waitForDevices
>>      self.getDeviceController(devclass).waitForDevices()
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 140, in waitForDevices
>>      return map(self.waitForDevice, self.deviceIDs())
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 155, in waitForDevice
>>      (devid, self.deviceClass))
>> VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.
>
> Was there anything in the kernel (dmesg) about vifs? What does your
> /proc/interrupts look like? Can you provide the dmesg that you get
> during startup. I am mainly looking for:
>
> NR_IRQS:16640 nr_irqs:1536 16
>
> How many guests are your running when this happens?
>
> One theory is that your are running out dom0 interrupts. Thought
> I *think* that was made dynamic in 3.0..
>
>
> Thought that does explain your iSCSI network wonky in the guest -
> was there anything in the dmesg when the guest started going bad?
>
>> [2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071)
>> XendDomainInfo.destroy: domid=35
>> [2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying
>> device model
>>
>> I tried turning up udev's log level but that didn't reveal anything.
>> Reading the xenstore for the vif doesn't show anything unusual either:
>>
>> ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
>> 0 = ""
>>   bridge = "vlan91"
>>   domain = "nathanxenuk1"
>>   handle = "0"
>>   uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
>>   script = "/etc/xen/scripts/vif-bridge"
>>   state = "1"
>>   frontend = "/local/domain/35/device/vif/0"
>>   mac = "00:16:3d:03:00:44"
>>   online = "1"
>>   frontend-id = "35"
>>
>> The bridge device (vlan91) exists, trying a different bridge doesn't
>> matter. Removing the VIF completely results in the same error for the
>> VBD. Adding debugging to the hotplug/network scripts didn't reveal
>> anything, it looks like they aren't even being executed yet. Nothing is
>> logged to xen-hotplug.log.
> OK, so that would imply the kernel hasn't been able to do the right
> thing. Hmm.
>
> What do you see when this happens with udev --monitor --kernel --udev
> --property ?

I have this happening again on a server and running udev monitor 
(udevadm monitor --kernel --udev --property) prints absolutely 
*nothing*. I've confirmed on a working xen host that it does actually 
print a ton of debugging when i restart a VM. This machine however 
prints nothing when trying to spawn.

Still returns the same hotplug failure error.

Any suggestions on what I can do to debug? Still nothing in dmesg.


>
>> The only thing I can think of that this may be related to, is gentoo
>> defaulted to a 10mb /dev which we filled up a few months back. We upped
>> the size to 50mb in the mount options and everything's been completely
>> stable since (~33 days). None of the /dev on the dom0's is higher than
>> 25% usage. Asides from adding the new luns, no changes have been made in
>> the past month.
>>
>> To try and test if removing some devices would solve anything, I tried
>> doing an "iscsiadm -m node --logout" and it promptly hard locked the
>> entire box. After a reboot, I was unable to reproduce the problem on
>> that particular dom0.
>>
>> I've still got 1 dom0 that's exhibiting the problem, if anyone is able
>> to suggest any further debugging steps?
>>
>> - Nathan
>>
>>
>> (XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1,
>> pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011
>>
>> ukxen1 xen # xm info
>> host                   : ukxen1
>> release                : 3.0.3
>> version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
>> machine                : x86_64
>> nr_cpus                : 24
>> nr_nodes               : 2
>> cores_per_socket       : 6
>> threads_per_core       : 2
>> cpu_mhz                : 2261
>> hw_caps                :
>> bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
>> virt_caps              : hvm hvm_directio
>> total_memory           : 98291
>> free_memory            : 91908
>> free_cpus              : 0
>> xen_major              : 4
>> xen_minor              : 1
>> xen_extra              : .1
>> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
>> hvm-3.0-x86_32p hvm-3.0-x86_64
>> xen_scheduler          : credit
>> xen_pagesize           : 4096
>> platform_params        : virt_start=0xffff800000000000
>> xen_changeset          : unavailable
>> xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1
>> dom0_vcpus_pin=true
>> cc_compiler            : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
>> cc_compile_by          : root
>> cc_compile_domain      :
>> cc_compile_date        : Mon Aug 29 16:24:12 PDT 2011
>> xend_config_format     : 4
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 07:16:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 07:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyI2b-0003Tr-H6; Fri, 17 Feb 2012 07:15:37 +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 1RyI2Z-0003Tm-TB
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 07:15:36 +0000
Received: from [85.158.139.83:6208] by server-11.bemta-5.messagelabs.com id
	C5/A4-14397-79EFD3F4; Fri, 17 Feb 2012 07:15:35 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329462932!8109389!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9395 invoked from network); 17 Feb 2012 07:15:34 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 07:15:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=kYFGMaoaQL+J
	dyqQgx+DdrWH6cI=; b=MtJcVmobAwhE0lcfGoNfClh7dvMv8rsp0RwjvEXJhaeW
	rMdxa1SIPHLc418KeUuzI9tHyUmyZQ59gaGgdZsWuEbcd3hoLyDANADsUtXmCxBp
	eXQ+bwAST5jnE+Fa4EFcqkS7agpKeY6bmezxJEbMlGyNR2briBz6IhNgF7oPZOI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=rzvHQ2
	Ngqi3140L4DGV3Yk45Itk+sehO7hNeilTAmWQER8zuQopCoa+U7eMG7tm8H6UAMI
	Gl2ar3HqdTNRujMDstE2KqUvGlao0ixXBUMVkZvg1xudMOr00o5ifR5YoZ9xNtX0
	6ObiZ3AmhYkmgW/DdZRJLevMKA1i3+H/Movwk=
Received: (qmail 5422 invoked from network); 17 Feb 2012 07:15:31 -0000
X-AntiVirus: Clean
Received: from 216-19-182-203.dyn.novuscom.net (HELO ?192.168.1.102?)
	(nathan@gt.net@216.19.182.203)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	17 Feb 2012 07:15:31 -0000
Message-ID: <4F3DFE96.2030803@gt.net>
Date: Thu, 16 Feb 2012 23:15:34 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
In-Reply-To: <20120201013036.GA12637@andromeda.dapyr.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/31/2012 5:30 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 31, 2012 at 01:42:23PM -0800, Nathan March wrote:
>> Hi All,
>>
>> We've got a xen setup based around a dell iscsi device with each xen
>> host having 2 lun's, we then run multipath on top of that. After adding
>> a couple new virtual disks the other day, a couple of our online stable
>> VM's suddenly hard locked up. Attaching to the console gave me nothing,
>> looked like they lost their disk devices.
>>
>> Attempting to restart them on the same dom0 failed with hot plug errors,
>> as did attempting to start them on a few different dom0's. After doing a
>> "multipath -F" to remove unused devices and manually bringing in just
>> the selected LUN's via "multipath diskname", I was able to successfully
>> start them. This initially made me think perhaps I was hitting some sort
>> of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun
>> = 1088 iscsi connections). Just to be clear, the problem occurred on
>> multiple dom0's at the same time so it definitely seems iscsi related.
>>
>> Now, a day later, I'm debugging this further and I'm again unable to
>> start VM's, even with all extra multipath devices removed. I rebooted
>> one of the dom0's and was able to successfully migrate our production
>> VM's off a broken server, so I've now got an empty dom0 that's unable to
>> start any vm's.
>>
>> Starting a VM results in the following in xend.log:
>>
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
>> [2012-01-31 13:06:16 12353] DEBUG (DevController:628)
>> hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
>> [2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices
>> failed.
>> Traceback (most recent call last):
>>    File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line
>> 85, in perform
>>      return op_method(op, req)
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line
>> 85, in op_wait_for_devices
>>      return self.dom.waitForDevices()
>>    File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py",
>> line 1237, in waitForDevices
>>      self.getDeviceController(devclass).waitForDevices()
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 140, in waitForDevices
>>      return map(self.waitForDevice, self.deviceIDs())
>>    File
>> "/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py",
>> line 155, in waitForDevice
>>      (devid, self.deviceClass))
>> VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.
>
> Was there anything in the kernel (dmesg) about vifs? What does your
> /proc/interrupts look like? Can you provide the dmesg that you get
> during startup. I am mainly looking for:
>
> NR_IRQS:16640 nr_irqs:1536 16
>
> How many guests are your running when this happens?
>
> One theory is that your are running out dom0 interrupts. Thought
> I *think* that was made dynamic in 3.0..
>
>
> Thought that does explain your iSCSI network wonky in the guest -
> was there anything in the dmesg when the guest started going bad?
>
>> [2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071)
>> XendDomainInfo.destroy: domid=35
>> [2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying
>> device model
>>
>> I tried turning up udev's log level but that didn't reveal anything.
>> Reading the xenstore for the vif doesn't show anything unusual either:
>>
>> ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
>> 0 = ""
>>   bridge = "vlan91"
>>   domain = "nathanxenuk1"
>>   handle = "0"
>>   uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
>>   script = "/etc/xen/scripts/vif-bridge"
>>   state = "1"
>>   frontend = "/local/domain/35/device/vif/0"
>>   mac = "00:16:3d:03:00:44"
>>   online = "1"
>>   frontend-id = "35"
>>
>> The bridge device (vlan91) exists, trying a different bridge doesn't
>> matter. Removing the VIF completely results in the same error for the
>> VBD. Adding debugging to the hotplug/network scripts didn't reveal
>> anything, it looks like they aren't even being executed yet. Nothing is
>> logged to xen-hotplug.log.
> OK, so that would imply the kernel hasn't been able to do the right
> thing. Hmm.
>
> What do you see when this happens with udev --monitor --kernel --udev
> --property ?

I have this happening again on a server and running udev monitor 
(udevadm monitor --kernel --udev --property) prints absolutely 
*nothing*. I've confirmed on a working xen host that it does actually 
print a ton of debugging when i restart a VM. This machine however 
prints nothing when trying to spawn.

Still returns the same hotplug failure error.

Any suggestions on what I can do to debug? Still nothing in dmesg.


>
>> The only thing I can think of that this may be related to, is gentoo
>> defaulted to a 10mb /dev which we filled up a few months back. We upped
>> the size to 50mb in the mount options and everything's been completely
>> stable since (~33 days). None of the /dev on the dom0's is higher than
>> 25% usage. Asides from adding the new luns, no changes have been made in
>> the past month.
>>
>> To try and test if removing some devices would solve anything, I tried
>> doing an "iscsiadm -m node --logout" and it promptly hard locked the
>> entire box. After a reboot, I was unable to reproduce the problem on
>> that particular dom0.
>>
>> I've still got 1 dom0 that's exhibiting the problem, if anyone is able
>> to suggest any further debugging steps?
>>
>> - Nathan
>>
>>
>> (XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1,
>> pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011
>>
>> ukxen1 xen # xm info
>> host                   : ukxen1
>> release                : 3.0.3
>> version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
>> machine                : x86_64
>> nr_cpus                : 24
>> nr_nodes               : 2
>> cores_per_socket       : 6
>> threads_per_core       : 2
>> cpu_mhz                : 2261
>> hw_caps                :
>> bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
>> virt_caps              : hvm hvm_directio
>> total_memory           : 98291
>> free_memory            : 91908
>> free_cpus              : 0
>> xen_major              : 4
>> xen_minor              : 1
>> xen_extra              : .1
>> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
>> hvm-3.0-x86_32p hvm-3.0-x86_64
>> xen_scheduler          : credit
>> xen_pagesize           : 4096
>> platform_params        : virt_start=0xffff800000000000
>> xen_changeset          : unavailable
>> xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1
>> dom0_vcpus_pin=true
>> cc_compiler            : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
>> cc_compile_by          : root
>> cc_compile_domain      :
>> cc_compile_date        : Mon Aug 29 16:24:12 PDT 2011
>> xend_config_format     : 4
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 07:16:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 07: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.xensource.com>)
	id 1RyI3F-0003VO-1S; Fri, 17 Feb 2012 07:16:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RyI3E-0003VF-1p
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 07:16:16 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329462916!57085683!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMzE4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31567 invoked from network); 17 Feb 2012 07:15:17 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-3.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 07:15:17 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ00DQT06JVO@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:15:55 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ00FWK05SU1@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:15:55 +0800 (CST)
Received: from szxeml209-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGX29282; Fri,
	17 Feb 2012 15:15:54 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136)
	by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 15:15:40 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml409-hub.china.huawei.com (10.82.67.136) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 15:15:44 +0800
Date: Fri, 17 Feb 2012 15:15:43 +0800
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <9fd12f919ddbd1592711.1329462943@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.9+10-e9264b45237d
X-Mercurial-Node: 9fd12f919ddbd15927117eff42149664dba698ca
X-CFilter-Loop: Reflected
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: [Xen-devel] [PATCH] x86/mm: Make sure the event channel is released
	accurately
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7093614109929523318=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7093614109929523318==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1329462865 -28800
# Node ID 9fd12f919ddbd15927117eff42149664dba698ca
# Parent  b75664e5390583c5d2075c82a14245bc941b3aaf
x86/mm: Make sure the event channel is released accurately

    In xenpaging source code,there is an interdomain communication between dom0
and domU. In mem_event_enable(),the function alloc_unbound_xen_event_channel()
allocates a free port for domU, and then it will be bound with dom0.
When xenpaging tears down,it just frees dom0's event channel port by
xc_evtchn_unbind(), leaves domU's port still occupied.
    So we add the patch to free domU's port when xenpaging exits.
We need double free interdomain eventchannel. First free domainU port,
and leave domain 0 port unbond, Then free domain 0 port.

Signed-off-by£ºKaixing Hong <hongkaixing@huawei.com>,
Signed-off-by£ºZhen Shi <bicky.shi@huawei.com>

diff -r b75664e53905 -r 9fd12f919ddb xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Thu Feb 16 15:43:02 2012 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Fri Feb 17 15:14:25 2012 +0800
@@ -243,6 +243,9 @@
             return -EBUSY;
         }
 
+        /* Free domU's event channel and leave the other one unbound */
+        free_xen_event_channel(d->vcpu[0], med->xen_port);
+        
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 


--===============7093614109929523318==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7093614109929523318==--

From xen-devel-bounces@lists.xensource.com Fri Feb 17 07:16:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 07: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.xensource.com>)
	id 1RyI3F-0003VO-1S; Fri, 17 Feb 2012 07:16:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RyI3E-0003VF-1p
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 07:16:16 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329462916!57085683!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAyMzE4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31567 invoked from network); 17 Feb 2012 07:15:17 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-3.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 07:15:17 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ00DQT06JVO@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:15:55 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ00FWK05SU1@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:15:55 +0800 (CST)
Received: from szxeml209-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGX29282; Fri,
	17 Feb 2012 15:15:54 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136)
	by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 15:15:40 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml409-hub.china.huawei.com (10.82.67.136) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 15:15:44 +0800
Date: Fri, 17 Feb 2012 15:15:43 +0800
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <9fd12f919ddbd1592711.1329462943@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.9+10-e9264b45237d
X-Mercurial-Node: 9fd12f919ddbd15927117eff42149664dba698ca
X-CFilter-Loop: Reflected
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: [Xen-devel] [PATCH] x86/mm: Make sure the event channel is released
	accurately
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7093614109929523318=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7093614109929523318==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1329462865 -28800
# Node ID 9fd12f919ddbd15927117eff42149664dba698ca
# Parent  b75664e5390583c5d2075c82a14245bc941b3aaf
x86/mm: Make sure the event channel is released accurately

    In xenpaging source code,there is an interdomain communication between dom0
and domU. In mem_event_enable(),the function alloc_unbound_xen_event_channel()
allocates a free port for domU, and then it will be bound with dom0.
When xenpaging tears down,it just frees dom0's event channel port by
xc_evtchn_unbind(), leaves domU's port still occupied.
    So we add the patch to free domU's port when xenpaging exits.
We need double free interdomain eventchannel. First free domainU port,
and leave domain 0 port unbond, Then free domain 0 port.

Signed-off-by£ºKaixing Hong <hongkaixing@huawei.com>,
Signed-off-by£ºZhen Shi <bicky.shi@huawei.com>

diff -r b75664e53905 -r 9fd12f919ddb xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Thu Feb 16 15:43:02 2012 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Fri Feb 17 15:14:25 2012 +0800
@@ -243,6 +243,9 @@
             return -EBUSY;
         }
 
+        /* Free domU's event channel and leave the other one unbound */
+        free_xen_event_channel(d->vcpu[0], med->xen_port);
+        
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 


--===============7093614109929523318==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7093614109929523318==--

From xen-devel-bounces@lists.xensource.com Fri Feb 17 07:39:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 07: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.xensource.com>)
	id 1RyIPJ-0003s9-4N; Fri, 17 Feb 2012 07:39:05 +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 1RyIPH-0003s4-AA
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 07:39:03 +0000
Received: from [85.158.139.83:48771] by server-3.bemta-5.messagelabs.com id
	61/E0-06438-6140E3F4; Fri, 17 Feb 2012 07:39:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329464341!8111975!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ4ODQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ4ODQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18448 invoked from network); 17 Feb 2012 07:39:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 07:39:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329464340; l=763;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dhNRkx4R3GXQEoCL7gsp0ZgsO7E=;
	b=Y0B7yOpQcBFUuj1t2iJVUq/nXW/IWJnYSqUuL7vWspA4m+w6PKk+Ve2ble+XHXOqpwS
	r7FM1u7Tn7kgBnqQsLWBZZAg51oD4WID/Fbns3ECei2PVOdw4zIFYGAuj2XJh1MPrbv05
	2Vx8uRXtTOH9AVuYNlVX3eaw32OJjlPQVJk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (cohen mo38) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04f36o1H5dA9M ;
	Fri, 17 Feb 2012 08:38:37 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B334318637; Fri, 17 Feb 2012 08:38:29 +0100 (CET)
Date: Fri, 17 Feb 2012 08:38:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120217073829.GA21330@aepfle.de>
References: <9fd12f919ddbd1592711.1329462943@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9fd12f919ddbd1592711.1329462943@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make sure the event channel is
 released accurately
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, hongkaixing@huawei.com wrote:

>     In xenpaging source code,there is an interdomain communication between dom0
> and domU. In mem_event_enable(),the function alloc_unbound_xen_event_channel()
> allocates a free port for domU, and then it will be bound with dom0.
> When xenpaging tears down,it just frees dom0's event channel port by
> xc_evtchn_unbind(), leaves domU's port still occupied.
>     So we add the patch to free domU's port when xenpaging exits.
> We need double free interdomain eventchannel. First free domainU port,
> and leave domain 0 port unbond, Then free domain 0 port.
> 
> Signed-off-by??Kaixing Hong <hongkaixing@huawei.com>,
> Signed-off-by??Zhen Shi <bicky.shi@huawei.com>

Acked-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 07:39:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 07: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.xensource.com>)
	id 1RyIPJ-0003s9-4N; Fri, 17 Feb 2012 07:39:05 +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 1RyIPH-0003s4-AA
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 07:39:03 +0000
Received: from [85.158.139.83:48771] by server-3.bemta-5.messagelabs.com id
	61/E0-06438-6140E3F4; Fri, 17 Feb 2012 07:39:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329464341!8111975!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ4ODQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDQ4ODQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18448 invoked from network); 17 Feb 2012 07:39:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 07:39:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329464340; l=763;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dhNRkx4R3GXQEoCL7gsp0ZgsO7E=;
	b=Y0B7yOpQcBFUuj1t2iJVUq/nXW/IWJnYSqUuL7vWspA4m+w6PKk+Ve2ble+XHXOqpwS
	r7FM1u7Tn7kgBnqQsLWBZZAg51oD4WID/Fbns3ECei2PVOdw4zIFYGAuj2XJh1MPrbv05
	2Vx8uRXtTOH9AVuYNlVX3eaw32OJjlPQVJk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (cohen mo38) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04f36o1H5dA9M ;
	Fri, 17 Feb 2012 08:38:37 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B334318637; Fri, 17 Feb 2012 08:38:29 +0100 (CET)
Date: Fri, 17 Feb 2012 08:38:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120217073829.GA21330@aepfle.de>
References: <9fd12f919ddbd1592711.1329462943@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9fd12f919ddbd1592711.1329462943@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] x86/mm: Make sure the event channel is
 released accurately
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, hongkaixing@huawei.com wrote:

>     In xenpaging source code,there is an interdomain communication between dom0
> and domU. In mem_event_enable(),the function alloc_unbound_xen_event_channel()
> allocates a free port for domU, and then it will be bound with dom0.
> When xenpaging tears down,it just frees dom0's event channel port by
> xc_evtchn_unbind(), leaves domU's port still occupied.
>     So we add the patch to free domU's port when xenpaging exits.
> We need double free interdomain eventchannel. First free domainU port,
> and leave domain 0 port unbond, Then free domain 0 port.
> 
> Signed-off-by??Kaixing Hong <hongkaixing@huawei.com>,
> Signed-off-by??Zhen Shi <bicky.shi@huawei.com>

Acked-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:21:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJ3Y-0004j7-2y; Fri, 17 Feb 2012 08:20:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyJ3W-0004j2-KF
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:20:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329466832!15178991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10272 invoked from network); 17 Feb 2012 08:20:32 -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 Feb 2012 08:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,434,1325462400"; d="scan'208";a="10763899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:20:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 08:20:32 +0000
Message-ID: <1329466831.8012.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hongkaixing <hongkaixing@huawei.com>
Date: Fri, 17 Feb 2012 08:20:31 +0000
In-Reply-To: <004201cced3c$73b1baf0$5b1530d0$@com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
	<1329298049.31256.277.camel@zakaz.uk.xensource.com>
	<004201cced3c$73b1baf0$5b1530d0$@com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	'Olaf Hering' <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 06:21 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Wednesday, February 15, 2012 5:27 PM
> > To: Hongkaixing
> > Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> > hanweidong@huawei.com
> > Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> > 
> > On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> > >
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > > > how xenpaging works but why does paging need a domU event channel
> > > > anyway? Surely paging is transparent to the guest.
> > > >
> > > > Or is this really a dom0<->Xen event channel which just appears to be
> > > > assigned to the guest?
> > >
> > > In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> > [...]
> > > > Who assigns this remote domain port? Shouldn't it either be closed when
> > > > the dom0 end is closed or retained such that it can be reused each time
> > > > instead of leaking?
> > >
> > >   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> > > and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> > > leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.
> > 
> > The two ends of that event channel are actually dom0 and Xen, because
> > chn->xen_consumer is not NULL, even though the Xen end does live in the
> > domU evtchn address space. It is not exactly dom0 and domU as you
> > suggest, which is where my confused question arose.
> 
>    See what xenpaging_init() does when xenpaging is launched:
>    xc_mem_paging_enable() ---> this function allocate a event channel of domain U, the remote port is stored in paging->mem_event.shared_page->port
>             |
>             V
>     Xc_event_bind_interdomain() --> this function bind dom0 with domU port allocated above
> 
>    But when xenpaging is tear down:
>    xc_mem_paging_disable()  -->  do nothing about event channel
>             |
>             V
>    xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU )  ECS_UNBOUND

I wasn't querying the presence of the leak or the validity of the fix, I
was asking what the domU event channel was even for (i.e. why does it
exist at all?).

I answered that myself in my previous mail -- it's actually a Xen event
channel not a guest visible one.

Ian.

> 
> 
>  Hong Kaixing.
> 
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:21:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJ3Y-0004j7-2y; Fri, 17 Feb 2012 08:20:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyJ3W-0004j2-KF
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:20:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329466832!15178991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10272 invoked from network); 17 Feb 2012 08:20:32 -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 Feb 2012 08:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,434,1325462400"; d="scan'208";a="10763899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:20:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 08:20:32 +0000
Message-ID: <1329466831.8012.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Hongkaixing <hongkaixing@huawei.com>
Date: Fri, 17 Feb 2012 08:20:31 +0000
In-Reply-To: <004201cced3c$73b1baf0$5b1530d0$@com>
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
	<1329298049.31256.277.camel@zakaz.uk.xensource.com>
	<004201cced3c$73b1baf0$5b1530d0$@com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xiaowei.yang@huawei.com" <xiaowei.yang@huawei.com>,
	'Olaf Hering' <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hanweidong@huawei.com" <hanweidong@huawei.com>,
	"yanqiangjun@huawei.com" <yanqiangjun@huawei.com>,
	"bicky.shi@huawei.com" <bicky.shi@huawei.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 06:21 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Wednesday, February 15, 2012 5:27 PM
> > To: Hongkaixing
> > Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> > hanweidong@huawei.com
> > Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> > 
> > On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> > >
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > > > how xenpaging works but why does paging need a domU event channel
> > > > anyway? Surely paging is transparent to the guest.
> > > >
> > > > Or is this really a dom0<->Xen event channel which just appears to be
> > > > assigned to the guest?
> > >
> > > In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> > [...]
> > > > Who assigns this remote domain port? Shouldn't it either be closed when
> > > > the dom0 end is closed or retained such that it can be reused each time
> > > > instead of leaking?
> > >
> > >   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> > > and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> > > leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.
> > 
> > The two ends of that event channel are actually dom0 and Xen, because
> > chn->xen_consumer is not NULL, even though the Xen end does live in the
> > domU evtchn address space. It is not exactly dom0 and domU as you
> > suggest, which is where my confused question arose.
> 
>    See what xenpaging_init() does when xenpaging is launched:
>    xc_mem_paging_enable() ---> this function allocate a event channel of domain U, the remote port is stored in paging->mem_event.shared_page->port
>             |
>             V
>     Xc_event_bind_interdomain() --> this function bind dom0 with domU port allocated above
> 
>    But when xenpaging is tear down:
>    xc_mem_paging_disable()  -->  do nothing about event channel
>             |
>             V
>    xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU )  ECS_UNBOUND

I wasn't querying the presence of the leak or the validity of the fix, I
was asking what the domU event channel was even for (i.e. why does it
exist at all?).

I answered that myself in my previous mail -- it's actually a Xen event
channel not a guest visible one.

Ian.

> 
> 
>  Hong Kaixing.
> 
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08: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.xensource.com>)
	id 1RyJ58-0004mk-J4; Fri, 17 Feb 2012 08:22:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyJ57-0004mQ-4L
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:22:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329466931!9858358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10864 invoked from network); 17 Feb 2012 08:22:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 08:22:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,434,1325462400"; d="scan'208";a="10763927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:22:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 08:22:11 +0000
Message-ID: <1329466930.8012.8.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Date: Fri, 17 Feb 2012 08:22:10 +0000
In-Reply-To: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 05:36 +0000, jacek burghardt wrote:
> I am trying to create arch linux package xen 4.2 unstable . It builds
> mots of xen fine but I get error with xl_cmdimpl.c
> 4.2/src/xen-unstable.git-build/tools/libxl/../../tools/include  -c -o
> xl_cmdimpl.o xl_cmdimpl.c
> xl_cmdimpl.c: In function 'printf_info':
> xl_cmdimpl.c:300:5: error: statement with no effect
> [-Werror=unused-value]
> xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
> xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this
> function)
> xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only
> once for each function it appears in
> xl_cmdimpl.c:306:5: error: too many arguments to function
> 'yajl_gen_alloc'
> /usr/include/yajl/yajl_gen.h:118:23: note: declared here
> xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf'
> from incompatible pointer type [-Werror]
> /usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but
> argument is of type 'unsigned int *'
> cc1: all warnings being treated as errors
> I saw this error mentioned I wonder if there is patch 

This is due to xl only supporting yajl1 while you seem to have yajl2.

Olaf Herring posted a patch last week (or maybe the week before). I
thought it had been committed but perhaps not -- although you don't say
which xen-unstable you are running so I don't know how up to date you
are -- this is always worth mentioning.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08: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.xensource.com>)
	id 1RyJ58-0004mk-J4; Fri, 17 Feb 2012 08:22:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyJ57-0004mQ-4L
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:22:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329466931!9858358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10864 invoked from network); 17 Feb 2012 08:22:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 08:22:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,434,1325462400"; d="scan'208";a="10763927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:22:11 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 08:22:11 +0000
Message-ID: <1329466930.8012.8.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Date: Fri, 17 Feb 2012 08:22:10 +0000
In-Reply-To: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 05:36 +0000, jacek burghardt wrote:
> I am trying to create arch linux package xen 4.2 unstable . It builds
> mots of xen fine but I get error with xl_cmdimpl.c
> 4.2/src/xen-unstable.git-build/tools/libxl/../../tools/include  -c -o
> xl_cmdimpl.o xl_cmdimpl.c
> xl_cmdimpl.c: In function 'printf_info':
> xl_cmdimpl.c:300:5: error: statement with no effect
> [-Werror=unused-value]
> xl_cmdimpl.c:300:21: error: expected ';' before 'conf'
> xl_cmdimpl.c:306:28: error: 'conf' undeclared (first use in this
> function)
> xl_cmdimpl.c:306:28: note: each undeclared identifier is reported only
> once for each function it appears in
> xl_cmdimpl.c:306:5: error: too many arguments to function
> 'yajl_gen_alloc'
> /usr/include/yajl/yajl_gen.h:118:23: note: declared here
> xl_cmdimpl.c:339:5: error: passing argument 3 of 'yajl_gen_get_buf'
> from incompatible pointer type [-Werror]
> /usr/include/yajl/yajl_gen.h:144:30: note: expected 'size_t *' but
> argument is of type 'unsigned int *'
> cc1: all warnings being treated as errors
> I saw this error mentioned I wonder if there is patch 

This is due to xl only supporting yajl1 while you seem to have yajl2.

Olaf Herring posted a patch last week (or maybe the week before). I
thought it had been committed but perhaps not -- although you don't say
which xen-unstable you are running so I don't know how up to date you
are -- this is always worth mentioning.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJHG-000527-Rh; Fri, 17 Feb 2012 08:34:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RyJHF-00051z-Oc
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:34:49 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329467680!15724259!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk2NDA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3419 invoked from network); 17 Feb 2012 08:34:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-12.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 08:34:42 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 17 Feb 2012 00:34:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="107835950"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 17 Feb 2012 00:34:38 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 17 Feb 2012 16:31:44 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:31:44 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:24818 & Dom0: 414b878e...
Thread-Index: AQHM7U6UBp5rQnA/hkWLdv5i41iZzA==
Date: Fri, 17 Feb 2012 08:31:43 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FCBB3EF@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24818 & Dom0: 414b878e...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report of xen-unstable tree. One bug has been fixed and no new bugs.

Version Info
=================================================================
xen-changeset:   24818:fe427d3bb378
pvops git: Jeremy's tree
commit 414b878e8ea17c65cd0d7f9dfc38dba472857f74
=================================================================


Fix issue(1)
==============
1. blank screen in SLES11 SP2 RC3 guest with a VF statically assigned
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805


Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752




Thanks
Zhou, Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJHG-000527-Rh; Fri, 17 Feb 2012 08:34:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <chao.zhou@intel.com>) id 1RyJHF-00051z-Oc
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:34:49 +0000
X-Env-Sender: chao.zhou@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329467680!15724259!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk2NDA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3419 invoked from network); 17 Feb 2012 08:34:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-12.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 08:34:42 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 17 Feb 2012 00:34:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="107835950"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 17 Feb 2012 00:34:38 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Fri, 17 Feb 2012 16:31:44 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:31:44 +0800
From: "Zhou, Chao" <chao.zhou@intel.com>
To: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Thread-Topic: VMX status report. Xen:24818 & Dom0: 414b878e...
Thread-Index: AQHM7U6UBp5rQnA/hkWLdv5i41iZzA==
Date: Fri, 17 Feb 2012 08:31:43 +0000
Message-ID: <40352EBA8B4DF841A9907B883F22B59B0FCBB3EF@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] VMX status report. Xen:24818 & Dom0: 414b878e...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This is the test report of xen-unstable tree. One bug has been fixed and no new bugs.

Version Info
=================================================================
xen-changeset:   24818:fe427d3bb378
pvops git: Jeremy's tree
commit 414b878e8ea17c65cd0d7f9dfc38dba472857f74
=================================================================


Fix issue(1)
==============
1. blank screen in SLES11 SP2 RC3 guest with a VF statically assigned
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805


Old issues(6)
==============
1. [ACPI] System cann't resume after do suspend
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1707
2.[XL]"xl vcpu-set" causes dom0 crash or panic
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1730
3.[VT-D]fail to detach NIC from guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736
4.Dom0 crash on power-off
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1740
5.Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1747
6.[VT-D] device reset fail when create/destroy guest
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1752




Thanks
Zhou, Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:35:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08: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.xensource.com>)
	id 1RyJHO-00052U-89; Fri, 17 Feb 2012 08:34:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RyJHM-00052C-DT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:34:56 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329467689!12709982!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30361 invoked from network); 17 Feb 2012 08:34:49 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-14.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 08:34:49 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 88A7AD3478A
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:34:48 +0100 (CET)
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 EzWxec5JFQhk for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:34:42 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 7A225D341E4
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:34:42 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 09:34:41 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1319630071722-4939528.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
In-Reply-To: <1329399537084-5489530.post@n5.nabble.com>
MIME-Version: 1.0
Message-Id: <201202170934.41725.tobias.geiger@vido.info>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGkgSmFtZXMgCgpZb3UgY2FuIGVpdGhlciByZW1vdmUgdGhlICJwY2kgPSAgWyAnMDE6MDAuMCcg
XSIgKGJ0dyB3aGF0IGFyZSB0aGUgKiBpbiB5b3VyIApjb25maWc/ISkgdW50aWwgeW91IGFyZSBy
ZWFkeSB0byBpbnN0YWxsIHRoZSBEcml2ZXIgZm9yIHRoZSBwYXNzZWQgdGhyb3VnaCAKY2FyZCwg
b3IgeW91IGNhbiBmaWRkbGUgYXJvdW5kIHdpdGggZ2Z4X3Bhc3N0aHJ1PTEvMCAsIDAgbWVhbmlu
ZyB0aGUgcGNpLWNhcmQgCndpbGwgYmUgdGhlcmUgYXMgYSBzZWNvbmRhcnkgY2FyZCB3aXRoaW4g
ZG9tVSwgMSBtZWFuaW5nIHRoZSBjaXJydXMgZ2V0cyAKZGlzYWJsZWQgYW5kIHRoZSBwY2ktY2Fy
ZCBwYXNzZWQgdGhyb3VnaCB3aWxsIGJlIHRoZSBvbmx5IGNhcmQgd2l0aGluIGRvbXUuIAoKUGVy
c29uYWx5IGkgcHJlZmVyIHRoZSBmaXJzdCBvbmUuCgpHcmVldGluZ3MKVG9iaWFzCgpQLlMuOiBU
aGlzIHVzYWdlIHF1ZXN0aW9uIHdvdWxkIGJldHRlciBzdWl0IHRvIHhlbi11c2VycywgYnV0Li4u
CgpBbSBEb25uZXJzdGFnLCAxNi4gRmVicnVhciAyMDEyLCAxNDozODo1NyBzY2hyaWViIEphbWVz
ZmZzOgo+IEhlbGxvLCBJJ20gdHJ5aW5nIHZnYS1wYXNzdGhyb3VnaCB3aXRoIGFuIG5WSURJQSBj
YXJkLgo+IEkgYW0gYXQgdGhlIGVuZCBvZiB0aGUgd2F5LCBJIGhhdmUgYXBwbGllZCB0aGUgcGF0
Y2hlcyB3aXRob3V0IHByb2JsZW1zLiBJCj4gaGF2ZSBjb25maWd1cmVkIG15IHdpbnhwIERvbVUg
YXMgZm9sbG93Ogo+IAo+IGtlcm5lbCA9ICcvdXNyL2xpYi94ZW4vYm9vdC9odm1sb2FkZXInCj4g
YnVpbGRlciA9ICdodm0nCj4gbWVtb3J5ID0gJzUxMicKPiBkZXZpY2VfbW9kZWw9Jy91c3IvbGli
L3hlbi9iaW4vcWVtdS1kbScKPiAKPiAjTnVtYmVyIG9mIENQVeKAmXMKPiB2Y3B1cyA9IDEKPiAK
PiAjIERpc2tzCj4gZGlzayA9IFsgJ2ZpbGU6L3hlbi9kb21haW5zL3dpbjAxL2Rpc2suaW1nLGlv
ZW11OmhkYSx3JywKPiAnZmlsZTovaG9tZS9XaW5kb3dzWFAtU1AyL2ltYWdlLmlzbyxpb2VtdTpo
ZGM6Y2Ryb20scicgXQo+IAo+ICMgSG9zdG5hbWUKPiBuYW1lID0gJ3dpbjAxJwo+IAo+ICMgTmV0
d29ya2luZwo+IHZpZiA9IFsndHlwZT1pb2VtdSwgYnJpZGdlPXhlbmJyMCddCj4gCj4gI1Bhc3N0
aHJvdWdoCj4gKmdmeF9wYXNzdGhydT0xCj4gcGNpICA9IFsgJzAxOjAwLjAnIF0qCj4gCj4gYm9v
dD0nY2QnCj4gKnZuYz0xCj4gdm5jdmlld2VyPTEqCj4gYWNwaSA9IDEKPiBzZGw9MAo+IHNlcmlh
bD0ncHR5Jwo+IG9uX3Bvd2Vyb2ZmID0gJ2Rlc3Ryb3knCj4gb25fcmVib290ID0gJ3Jlc3RhcnQn
Cj4gb25fY3Jhc2ggPSAncmVzdGFydCcKPiAKPiBJIGhhdmUgcmVhZCB0aGF0IGl0IGlzIG5vdCBw
b3NzaWJsZSB0byB1c2UgVk5DIGlmIEkgcGFzc2VkLXRocm91Z2gtVkdBCj4gQ2FyZCwgYXMgVG9i
aWFzIHNheXMgaGVyZToKPiAKPiAKPiAKPiBUb2JpYXMgR2VpZ2VyIHdyb3RlCj4gCj4gPiBIaSBT
eXRocmFyLAo+ID4gCj4gPiB5b3UgY2FuJ3Qgc2VlIHRoZSBvdXRwdXQgb2YgdGhlIHBhc3NlZC10
aHJvdWdoLVZHQSBDYXJkIGluIFZOQy4gQXQgbGVhc3QKPiA+IG5vdAo+ID4gaW4gdGhlIHFlbXUt
dm5jIHNlcnZlcjsgVGhlIG91dHB1dCB0byB0aGF0IGVtdWxhdGVkIChDaXJydXM/KSBDYXJkIHN0
b3BzCj4gPiBhcwo+ID4gc29vbiBhcyAgdGhlIERyaXZlciBmb3IgdGhlIHBhc3NlZC10aHJvdWdo
LVZHQSBDYXJkIGlzIGxvYWRlZCB3aXRoaW4gdGhlCj4gPiBEb21VLgo+ID4gRnJvbSB0aGF0IG1v
bWVudCBvbiB0aGUgeW91IGNhbiBvbmx5IHNlZSB0aGUgb3V0cHV0IG9uIGEgTW9uaXRvciBhdHRh
Y2hlZAo+ID4gdG8KPiA+IHRoZSBwYXNzZWQtdGhyb3VnaC1WR0EgQ2FyZC4gVk5DIGlzIG9mIGNv
dXJzZSBwb3NzaWJsZSB3aXRoIHRoZSBEb21VCj4gPiBmYWNpbGl0aWVzLCBpLmUuIGluc3RhbGwg
YSBWTkMgU2VydmVyIHdpdGhpbiBEb21VIGFuZCBhdHRhY2ggYSB2bmN2aWV3ZXIKPiA+IHRvIGl0
Cj4gPiAtIGJ1dCBpdHMgbm90IHJlYWxseSBwcmFjdGljYWwgcmVnYXJkaW5nIDNELSBvciBNb3Zp
ZSBPdXRwdXQgKGF0IGxlYXN0Cj4gPiBub3Qgd2l0aG91dCBvcHRpbWl6YXRpb25zIHRvIHRoZSBW
TkMgU2VydmVyL0NsaWVudCkKPiA+IAo+ID4gR3JlZXRpbmdzCj4gPiBUb2JpYXMKPiAKPiBTbyBJ
IGhhdmUgdHdvIHByb2JlbXMsCj4gSSBkb24ndCBrbm93IGhvdyB0byBhdHRhY2ggYSBNb25pdG9y
IHRvIHRoZSBwYXNzZWQtdGhyb3VnaC1WR0EgQ2FyZCwKPiBob3cgY2FuIEkgZG8gdGhpcyBpbiB0
aGUgY2ZnIGZpbGU/Cj4gU2hvdWxkIEkgdXNlIGFub3RoZXIgb3B0aW9uIHRvIGRpc2FibGUgdGhl
IGNpcnJ1cyBlbXVsYXRlZCBjYXJkIGluIHRoZSBjZmcKPiBmaWxlPwo+IAo+IENvdWxkIGFueW9u
ZSB3aXRoIGFuIG5WSURJQSBjYXJkIHBhc3NlZC10aHJvdWdoZWQgcG9zdCBoaXMgY29uZmlnIGZp
bGUKPiBoZXJlPyBUaGFua3MgeW91IHZlcnkgbXVjaCB0byBldmVyeW9uZSBpbiBhZHZhbmNlCj4g
Cj4gSmFtZXMuCj4gCj4gCj4gLS0KPiBWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0Ogo+IGh0
dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL1BhdGNoZXMtZm9yLVZHQS1QYXNzdGhyb3Vn
aC1YRU4tNC0yLXVuc3RhCj4gYmxlLXRwNDQwNjI2NXA1NDg5NTMwLmh0bWwgU2VudCBmcm9tIHRo
ZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQKPiBOYWJibGUuY29tLgo+IAo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:35:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08: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.xensource.com>)
	id 1RyJHO-00052U-89; Fri, 17 Feb 2012 08:34:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RyJHM-00052C-DT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:34:56 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329467689!12709982!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30361 invoked from network); 17 Feb 2012 08:34:49 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-14.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 08:34:49 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 88A7AD3478A
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:34:48 +0100 (CET)
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 EzWxec5JFQhk for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:34:42 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 7A225D341E4
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:34:42 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 09:34:41 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1319630071722-4939528.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
In-Reply-To: <1329399537084-5489530.post@n5.nabble.com>
MIME-Version: 1.0
Message-Id: <201202170934.41725.tobias.geiger@vido.info>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGkgSmFtZXMgCgpZb3UgY2FuIGVpdGhlciByZW1vdmUgdGhlICJwY2kgPSAgWyAnMDE6MDAuMCcg
XSIgKGJ0dyB3aGF0IGFyZSB0aGUgKiBpbiB5b3VyIApjb25maWc/ISkgdW50aWwgeW91IGFyZSBy
ZWFkeSB0byBpbnN0YWxsIHRoZSBEcml2ZXIgZm9yIHRoZSBwYXNzZWQgdGhyb3VnaCAKY2FyZCwg
b3IgeW91IGNhbiBmaWRkbGUgYXJvdW5kIHdpdGggZ2Z4X3Bhc3N0aHJ1PTEvMCAsIDAgbWVhbmlu
ZyB0aGUgcGNpLWNhcmQgCndpbGwgYmUgdGhlcmUgYXMgYSBzZWNvbmRhcnkgY2FyZCB3aXRoaW4g
ZG9tVSwgMSBtZWFuaW5nIHRoZSBjaXJydXMgZ2V0cyAKZGlzYWJsZWQgYW5kIHRoZSBwY2ktY2Fy
ZCBwYXNzZWQgdGhyb3VnaCB3aWxsIGJlIHRoZSBvbmx5IGNhcmQgd2l0aGluIGRvbXUuIAoKUGVy
c29uYWx5IGkgcHJlZmVyIHRoZSBmaXJzdCBvbmUuCgpHcmVldGluZ3MKVG9iaWFzCgpQLlMuOiBU
aGlzIHVzYWdlIHF1ZXN0aW9uIHdvdWxkIGJldHRlciBzdWl0IHRvIHhlbi11c2VycywgYnV0Li4u
CgpBbSBEb25uZXJzdGFnLCAxNi4gRmVicnVhciAyMDEyLCAxNDozODo1NyBzY2hyaWViIEphbWVz
ZmZzOgo+IEhlbGxvLCBJJ20gdHJ5aW5nIHZnYS1wYXNzdGhyb3VnaCB3aXRoIGFuIG5WSURJQSBj
YXJkLgo+IEkgYW0gYXQgdGhlIGVuZCBvZiB0aGUgd2F5LCBJIGhhdmUgYXBwbGllZCB0aGUgcGF0
Y2hlcyB3aXRob3V0IHByb2JsZW1zLiBJCj4gaGF2ZSBjb25maWd1cmVkIG15IHdpbnhwIERvbVUg
YXMgZm9sbG93Ogo+IAo+IGtlcm5lbCA9ICcvdXNyL2xpYi94ZW4vYm9vdC9odm1sb2FkZXInCj4g
YnVpbGRlciA9ICdodm0nCj4gbWVtb3J5ID0gJzUxMicKPiBkZXZpY2VfbW9kZWw9Jy91c3IvbGli
L3hlbi9iaW4vcWVtdS1kbScKPiAKPiAjTnVtYmVyIG9mIENQVeKAmXMKPiB2Y3B1cyA9IDEKPiAK
PiAjIERpc2tzCj4gZGlzayA9IFsgJ2ZpbGU6L3hlbi9kb21haW5zL3dpbjAxL2Rpc2suaW1nLGlv
ZW11OmhkYSx3JywKPiAnZmlsZTovaG9tZS9XaW5kb3dzWFAtU1AyL2ltYWdlLmlzbyxpb2VtdTpo
ZGM6Y2Ryb20scicgXQo+IAo+ICMgSG9zdG5hbWUKPiBuYW1lID0gJ3dpbjAxJwo+IAo+ICMgTmV0
d29ya2luZwo+IHZpZiA9IFsndHlwZT1pb2VtdSwgYnJpZGdlPXhlbmJyMCddCj4gCj4gI1Bhc3N0
aHJvdWdoCj4gKmdmeF9wYXNzdGhydT0xCj4gcGNpICA9IFsgJzAxOjAwLjAnIF0qCj4gCj4gYm9v
dD0nY2QnCj4gKnZuYz0xCj4gdm5jdmlld2VyPTEqCj4gYWNwaSA9IDEKPiBzZGw9MAo+IHNlcmlh
bD0ncHR5Jwo+IG9uX3Bvd2Vyb2ZmID0gJ2Rlc3Ryb3knCj4gb25fcmVib290ID0gJ3Jlc3RhcnQn
Cj4gb25fY3Jhc2ggPSAncmVzdGFydCcKPiAKPiBJIGhhdmUgcmVhZCB0aGF0IGl0IGlzIG5vdCBw
b3NzaWJsZSB0byB1c2UgVk5DIGlmIEkgcGFzc2VkLXRocm91Z2gtVkdBCj4gQ2FyZCwgYXMgVG9i
aWFzIHNheXMgaGVyZToKPiAKPiAKPiAKPiBUb2JpYXMgR2VpZ2VyIHdyb3RlCj4gCj4gPiBIaSBT
eXRocmFyLAo+ID4gCj4gPiB5b3UgY2FuJ3Qgc2VlIHRoZSBvdXRwdXQgb2YgdGhlIHBhc3NlZC10
aHJvdWdoLVZHQSBDYXJkIGluIFZOQy4gQXQgbGVhc3QKPiA+IG5vdAo+ID4gaW4gdGhlIHFlbXUt
dm5jIHNlcnZlcjsgVGhlIG91dHB1dCB0byB0aGF0IGVtdWxhdGVkIChDaXJydXM/KSBDYXJkIHN0
b3BzCj4gPiBhcwo+ID4gc29vbiBhcyAgdGhlIERyaXZlciBmb3IgdGhlIHBhc3NlZC10aHJvdWdo
LVZHQSBDYXJkIGlzIGxvYWRlZCB3aXRoaW4gdGhlCj4gPiBEb21VLgo+ID4gRnJvbSB0aGF0IG1v
bWVudCBvbiB0aGUgeW91IGNhbiBvbmx5IHNlZSB0aGUgb3V0cHV0IG9uIGEgTW9uaXRvciBhdHRh
Y2hlZAo+ID4gdG8KPiA+IHRoZSBwYXNzZWQtdGhyb3VnaC1WR0EgQ2FyZC4gVk5DIGlzIG9mIGNv
dXJzZSBwb3NzaWJsZSB3aXRoIHRoZSBEb21VCj4gPiBmYWNpbGl0aWVzLCBpLmUuIGluc3RhbGwg
YSBWTkMgU2VydmVyIHdpdGhpbiBEb21VIGFuZCBhdHRhY2ggYSB2bmN2aWV3ZXIKPiA+IHRvIGl0
Cj4gPiAtIGJ1dCBpdHMgbm90IHJlYWxseSBwcmFjdGljYWwgcmVnYXJkaW5nIDNELSBvciBNb3Zp
ZSBPdXRwdXQgKGF0IGxlYXN0Cj4gPiBub3Qgd2l0aG91dCBvcHRpbWl6YXRpb25zIHRvIHRoZSBW
TkMgU2VydmVyL0NsaWVudCkKPiA+IAo+ID4gR3JlZXRpbmdzCj4gPiBUb2JpYXMKPiAKPiBTbyBJ
IGhhdmUgdHdvIHByb2JlbXMsCj4gSSBkb24ndCBrbm93IGhvdyB0byBhdHRhY2ggYSBNb25pdG9y
IHRvIHRoZSBwYXNzZWQtdGhyb3VnaC1WR0EgQ2FyZCwKPiBob3cgY2FuIEkgZG8gdGhpcyBpbiB0
aGUgY2ZnIGZpbGU/Cj4gU2hvdWxkIEkgdXNlIGFub3RoZXIgb3B0aW9uIHRvIGRpc2FibGUgdGhl
IGNpcnJ1cyBlbXVsYXRlZCBjYXJkIGluIHRoZSBjZmcKPiBmaWxlPwo+IAo+IENvdWxkIGFueW9u
ZSB3aXRoIGFuIG5WSURJQSBjYXJkIHBhc3NlZC10aHJvdWdoZWQgcG9zdCBoaXMgY29uZmlnIGZp
bGUKPiBoZXJlPyBUaGFua3MgeW91IHZlcnkgbXVjaCB0byBldmVyeW9uZSBpbiBhZHZhbmNlCj4g
Cj4gSmFtZXMuCj4gCj4gCj4gLS0KPiBWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0Ogo+IGh0
dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL1BhdGNoZXMtZm9yLVZHQS1QYXNzdGhyb3Vn
aC1YRU4tNC0yLXVuc3RhCj4gYmxlLXRwNDQwNjI2NXA1NDg5NTMwLmh0bWwgU2VudCBmcm9tIHRo
ZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQKPiBOYWJibGUuY29tLgo+IAo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:37:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJJf-0005Bz-Qr; Fri, 17 Feb 2012 08:37:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyJJe-0005Bd-7T
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:37:18 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329467830!15248067!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27756 invoked from network); 17 Feb 2012 08:37:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 08:37:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyJJV-0003kF-AT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 00:37:09 -0800
Date: Fri, 17 Feb 2012 00:37:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329467829314-5491845.post@n5.nabble.com>
In-Reply-To: <1329466930.8012.8.camel@dagon.hellion.org.uk>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes on unstable there is yajl 2 support:
http://xenbits.xen.org/hg/xen-unstable.hg/rev/ab397bd22b56
Probably today I compile unstable on Wheezy with yajl2 and I will report if
complete and correct

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5491845.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:37:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJJf-0005Bz-Qr; Fri, 17 Feb 2012 08:37:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyJJe-0005Bd-7T
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:37:18 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329467830!15248067!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27756 invoked from network); 17 Feb 2012 08:37:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 08:37:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyJJV-0003kF-AT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 00:37:09 -0800
Date: Fri, 17 Feb 2012 00:37:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329467829314-5491845.post@n5.nabble.com>
In-Reply-To: <1329466930.8012.8.camel@dagon.hellion.org.uk>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes on unstable there is yajl 2 support:
http://xenbits.xen.org/hg/xen-unstable.hg/rev/ab397bd22b56
Probably today I compile unstable on Wheezy with yajl2 and I will report if
complete and correct

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5491845.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:43:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJOt-0005Rv-JA; Fri, 17 Feb 2012 08:42:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyJOs-0005Rk-5Z
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:42:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329468156!2294530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28222 invoked from network); 17 Feb 2012 08:42:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 08:42:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="10764471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08: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.213.0;
	Fri, 17 Feb 2012 08:42:36 +0000
Message-ID: <1329468155.8012.27.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Fri, 17 Feb 2012 08:42:35 +0000
In-Reply-To: <CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
	<1329390815.5975.7.camel@zakaz.uk.xensource.com>
	<CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VOn Thu, 2012-02-16 at 22:52 +0000, Daniel Castro wrote:
> On Thu, Feb 16, 2012 at 8:13 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
> >> Hello All,
> >>
> >> When a HVM guest is started upstream qemu presents the emulated drives
> >> as PCI devices or ata drives?
> >
> >> If more than drive is present how can I know which drive is which in xenstore?
> >
> > Emulated devices do not appear in xenstore.
> >
> > Some PV devices may have an emulated equivalent but the rule of thumb is
> > that an OS should only use either PV or Emulated devices and not mix and
> > match.
> >
> > In Linux we implement this by requiring that the emulated devices are
> > unplugged before we will use the PV path.
> >
> > In principal you can infer which Emulated device might matches a PV
> > device, the file docs/misc/vbd-interface.txt in the xen tree gives some
> > hints about this, but basically PV disks 0..3 can correspond to the
> > first four IDE devices (primary-master, primary-slave, secondary-master
> > & secondary-slave).
> >
> > I presume you are asking in the context of SeaBIOS. In that context you
> > could argue against unplugging because the guest OS may want to use
> > emulated devices, however I would suggest that for simplicity for time
> > being you just unplug the emulated devices before you enable the PV
> > path.
> Thanks for the response Ian, I am not sure I understand you. What I do
> is something similar to this:
> Find the emulated devices.

Why? You don't need these in your Xen code.

If anything is going to enumerate these devices it will be the existing
SeaBIOS code which drive the emulated devices. There is no need for you
to touch that.

>  ATA Devices are the drives and the PCI device is for what?

You are referring to the Xen platform device (5853:0001)?. This device
has nothing to do with the emulated disks.

The platform device just serves as a useful point to hook the Xen driver
loading off since many OSes handle autoloading of PCI drivers well so we
use it to trigger the loading of Xen drivers.

It has some secondary purposes such as the IRQ associated with this
device can also be used to inject event channels and the unplug protocol
happens via I/O ports on this device. 

> Find if the device is a disk. (in the context of a vbd the xenstore id
> corresponds to what?)

The meaning of the VBD number (e.g. 832 and 985 in your examples below)
is described by the document I pointed you at in my last mail:
docs/misc/vbd-interface.txt.

> If disk, then find corresponding entry on xenstore. Example
> device/vbd/832, device/vbd/985

You should enumerate (using XS_DIRECTORY) the device/vbd directory. Each
entry you find in there is a disk. There is no need for you to go
anywhere near the emulated disk devices to do this, nor to establish any
correspondence with the emulated devices. You know they are all vbds
because you found them in device/vbd.

The sequence of events should be:

      * Notice that you are running under Xen and that the platform PCI
        device is present. You most likely want to do this by using
        pci_find_init_device() to register a callback for the platform
        device. If you never get a callback then there is nothing for
        you to do and you should assume standard SeaBIOS drivers etc
        will take care of the emulated devices.
      * Unplug all of the emulated devices per the protocol defined in
        docs/misc/hvm-emulated-unplug.markdown. You do not need to
        enumerate the emulated devices to do this. If this fails then
        abort and assume standard SeaBIOS drivers etc will take care of
        the emulated devices.
      * Enumerate the contents of device/vbd in xenstore, for each disk:
              * parse the disk and partition number per
                docs/misc/vbd-interface.txt,
              * "Write device details to xenstore -rings, ref, etc" and
                do the necessary xenbus state transitions to get into
                state 4 (XenBusConnected)
              * create and register the appropriate disk device
                structures with SeaBIOS.

In the future once all this is working then there may be extensions such
as not unplugging devices and ensuring the safe coexistence of the
emulated and PV devices but you can leave that to one side for now since
there are other issues with doing that (c.f. previous discussions about
how to safely shutdown the PV devices after SeaBIOS is finished).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:43:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:43:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJOt-0005Rv-JA; Fri, 17 Feb 2012 08:42:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyJOs-0005Rk-5Z
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:42:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329468156!2294530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjg4OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28222 invoked from network); 17 Feb 2012 08:42:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 08:42:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="10764471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08: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.213.0;
	Fri, 17 Feb 2012 08:42:36 +0000
Message-ID: <1329468155.8012.27.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel Castro <evil.dani@gmail.com>
Date: Fri, 17 Feb 2012 08:42:35 +0000
In-Reply-To: <CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
	<1329390815.5975.7.camel@zakaz.uk.xensource.com>
	<CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VOn Thu, 2012-02-16 at 22:52 +0000, Daniel Castro wrote:
> On Thu, Feb 16, 2012 at 8:13 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
> >> Hello All,
> >>
> >> When a HVM guest is started upstream qemu presents the emulated drives
> >> as PCI devices or ata drives?
> >
> >> If more than drive is present how can I know which drive is which in xenstore?
> >
> > Emulated devices do not appear in xenstore.
> >
> > Some PV devices may have an emulated equivalent but the rule of thumb is
> > that an OS should only use either PV or Emulated devices and not mix and
> > match.
> >
> > In Linux we implement this by requiring that the emulated devices are
> > unplugged before we will use the PV path.
> >
> > In principal you can infer which Emulated device might matches a PV
> > device, the file docs/misc/vbd-interface.txt in the xen tree gives some
> > hints about this, but basically PV disks 0..3 can correspond to the
> > first four IDE devices (primary-master, primary-slave, secondary-master
> > & secondary-slave).
> >
> > I presume you are asking in the context of SeaBIOS. In that context you
> > could argue against unplugging because the guest OS may want to use
> > emulated devices, however I would suggest that for simplicity for time
> > being you just unplug the emulated devices before you enable the PV
> > path.
> Thanks for the response Ian, I am not sure I understand you. What I do
> is something similar to this:
> Find the emulated devices.

Why? You don't need these in your Xen code.

If anything is going to enumerate these devices it will be the existing
SeaBIOS code which drive the emulated devices. There is no need for you
to touch that.

>  ATA Devices are the drives and the PCI device is for what?

You are referring to the Xen platform device (5853:0001)?. This device
has nothing to do with the emulated disks.

The platform device just serves as a useful point to hook the Xen driver
loading off since many OSes handle autoloading of PCI drivers well so we
use it to trigger the loading of Xen drivers.

It has some secondary purposes such as the IRQ associated with this
device can also be used to inject event channels and the unplug protocol
happens via I/O ports on this device. 

> Find if the device is a disk. (in the context of a vbd the xenstore id
> corresponds to what?)

The meaning of the VBD number (e.g. 832 and 985 in your examples below)
is described by the document I pointed you at in my last mail:
docs/misc/vbd-interface.txt.

> If disk, then find corresponding entry on xenstore. Example
> device/vbd/832, device/vbd/985

You should enumerate (using XS_DIRECTORY) the device/vbd directory. Each
entry you find in there is a disk. There is no need for you to go
anywhere near the emulated disk devices to do this, nor to establish any
correspondence with the emulated devices. You know they are all vbds
because you found them in device/vbd.

The sequence of events should be:

      * Notice that you are running under Xen and that the platform PCI
        device is present. You most likely want to do this by using
        pci_find_init_device() to register a callback for the platform
        device. If you never get a callback then there is nothing for
        you to do and you should assume standard SeaBIOS drivers etc
        will take care of the emulated devices.
      * Unplug all of the emulated devices per the protocol defined in
        docs/misc/hvm-emulated-unplug.markdown. You do not need to
        enumerate the emulated devices to do this. If this fails then
        abort and assume standard SeaBIOS drivers etc will take care of
        the emulated devices.
      * Enumerate the contents of device/vbd in xenstore, for each disk:
              * parse the disk and partition number per
                docs/misc/vbd-interface.txt,
              * "Write device details to xenstore -rings, ref, etc" and
                do the necessary xenbus state transitions to get into
                state 4 (XenBusConnected)
              * create and register the appropriate disk device
                structures with SeaBIOS.

In the future once all this is working then there may be extensions such
as not unplugging devices and ensuring the safe coexistence of the
emulated and PV devices but you can leave that to one side for now since
there are other issues with doing that (c.f. previous discussions about
how to safely shutdown the PV devices after SeaBIOS is finished).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:56:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJbS-0005iK-0c; Fri, 17 Feb 2012 08:55:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJbQ-0005iF-0p
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:55:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329468933!8602680!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3540 invoked from network); 17 Feb 2012 08:55:33 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 08:55:33 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:55:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118565288"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:55:31 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:54:48 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:54:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:54:46 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich
	<JBeulich@suse.com>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: Core parking feature enable
Thread-Index: AcztUcu6w5JNa93KSUGX56XJx53QOA==
Date: Fri, 17 Feb 2012 08:54:45 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D848@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: "Li, Shaohua" <shaohua.li@intel.com>
Subject: [Xen-devel] Core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Core parking is a power control feature and it can co-work with NPTM to control system power budget through online/offline some CPUs in the system. These patches implement core parking feature for xen. They consist of 2 parts: dom0 patches and xen hypervisor patches.

At dom0 side, patches include
[Patch 1/3] intercept native pad (Processor Aggregator Device) logic, providing a native interface for natvie platform and a paravirt template for paravirt platform, so that os can implicitly hook to proper ops accordingly;
[Patch 2/3] redirect paravirt template to Xen pv ops;
[Patch 3/3] implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Due to the characteristic of xen continue_hypercall_on_cpu, dom0 seperately send/get core parking request/result;

At Xen hypervisor side, patches include
[Patch 1/2] implement hypercall through which dom0 send core parking request, and get core parking result;
[Patch 2/2] implement Xen core parking. Different core parking sequence has different power/performance result, due to cpu socket/core/thread topology. This patch provide power-first and performance-first policies, users can choose core parking policy on their own demand, considering power and performance tradeoff.

cc Shaohua, core parking feature author at linux kernel side.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:56:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJbS-0005iK-0c; Fri, 17 Feb 2012 08:55:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJbQ-0005iF-0p
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:55:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329468933!8602680!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3540 invoked from network); 17 Feb 2012 08:55:33 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 08:55:33 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:55:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118565288"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:55:31 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:54:48 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:54:48 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:54:46 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich
	<JBeulich@suse.com>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: Core parking feature enable
Thread-Index: AcztUcu6w5JNa93KSUGX56XJx53QOA==
Date: Fri, 17 Feb 2012 08:54:45 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D848@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: "Li, Shaohua" <shaohua.li@intel.com>
Subject: [Xen-devel] Core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Core parking is a power control feature and it can co-work with NPTM to control system power budget through online/offline some CPUs in the system. These patches implement core parking feature for xen. They consist of 2 parts: dom0 patches and xen hypervisor patches.

At dom0 side, patches include
[Patch 1/3] intercept native pad (Processor Aggregator Device) logic, providing a native interface for natvie platform and a paravirt template for paravirt platform, so that os can implicitly hook to proper ops accordingly;
[Patch 2/3] redirect paravirt template to Xen pv ops;
[Patch 3/3] implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Due to the characteristic of xen continue_hypercall_on_cpu, dom0 seperately send/get core parking request/result;

At Xen hypervisor side, patches include
[Patch 1/2] implement hypercall through which dom0 send core parking request, and get core parking result;
[Patch 2/2] implement Xen core parking. Different core parking sequence has different power/performance result, due to cpu socket/core/thread topology. This patch provide power-first and performance-first policies, users can choose core parking policy on their own demand, considering power and performance tradeoff.

cc Shaohua, core parking feature author at linux kernel side.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:58:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJdm-0005pB-O7; Fri, 17 Feb 2012 08:58:06 +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 1RyJdk-0005p1-W8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:58:05 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329469037!52824127!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30468 invoked from network); 17 Feb 2012 08:57:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 08:57:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:57:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="118565975"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:57:55 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:56:45 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:56:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:56:43 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 1/3] PAD helper for native and paravirt platform
Thread-Index: AcztUhHG6RKQx7+6TLaQA8tFAlSyZg==
Date: Fri, 17 Feb 2012 08:56:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D853@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_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 10 Feb 2012 20:32:50 +0800
Subject: [PATCH 1/3] PAD helper for native and paravirt platform

This patch is PAD (Processor Aggregator Device) helper.
It provides a native interface for natvie platform, and a template
for paravirt platform, so that os can implicitly hook to proper ops accordi=
ngly.
The paravirt template will further redirect to Xen pv ops in later patch fo=
r Xen
 core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/include/asm/paravirt.h       |   10 +++++
 arch/x86/include/asm/paravirt_types.h |    7 ++++
 arch/x86/kernel/paravirt.c            |    9 +++++
 drivers/acpi/acpi_pad.c               |   15 +++-----
 include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++=
++++
 5 files changed, 93 insertions(+), 9 deletions(-)
 create mode 100644 include/acpi/acpi_pad.h

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravir=
t.h
index a7d2db9..02e6df0 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
 	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
 }
=20
+static inline int __acpi_pad_init(void)
+{
+	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
+}
+
+static inline void __acpi_pad_exit(void)
+{
+	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
+}
+
 static inline void write_cr0(unsigned long x)
 {
 	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/p=
aravirt_types.h
index 8e8b9a4..61e20de 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -336,6 +336,11 @@ struct pv_lock_ops {
 	void (*spin_unlock)(struct arch_spinlock *lock);
 };
=20
+struct pv_pad_ops {
+	int (*acpi_pad_init)(void);
+	void (*acpi_pad_exit)(void);
+};
+
 /* This contains all the paravirt structures: we get a convenient
  * number for each function using the offset which we use to indicate
  * what to patch. */
@@ -347,6 +352,7 @@ struct paravirt_patch_template {
 	struct pv_apic_ops pv_apic_ops;
 	struct pv_mmu_ops pv_mmu_ops;
 	struct pv_lock_ops pv_lock_ops;
+	struct pv_pad_ops pv_pad_ops;
 };
=20
 extern struct pv_info pv_info;
@@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
 extern struct pv_apic_ops pv_apic_ops;
 extern struct pv_mmu_ops pv_mmu_ops;
 extern struct pv_lock_ops pv_lock_ops;
+extern struct pv_pad_ops pv_pad_ops;
=20
 #define PARAVIRT_PATCH(x)					\
 	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index d90272e..ec778f6 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -38,6 +38,8 @@
 #include <asm/tlbflush.h>
 #include <asm/timer.h>
=20
+#include <acpi/acpi_pad.h>
+
 /* nop stub */
 void _paravirt_nop(void)
 {
@@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 		.pv_lock_ops =3D pv_lock_ops,
 #endif
+		.pv_pad_ops =3D pv_pad_ops,
 	};
 	return *((void **)&tmpl + type);
 }
@@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops =3D {
 	.set_fixmap =3D native_set_fixmap,
 };
=20
+struct pv_pad_ops pv_pad_ops =3D {
+	.acpi_pad_init =3D native_acpi_pad_init,
+	.acpi_pad_exit =3D native_acpi_pad_exit,
+};
+
 EXPORT_SYMBOL_GPL(pv_time_ops);
 EXPORT_SYMBOL    (pv_cpu_ops);
 EXPORT_SYMBOL    (pv_mmu_ops);
 EXPORT_SYMBOL_GPL(pv_apic_ops);
 EXPORT_SYMBOL_GPL(pv_info);
 EXPORT_SYMBOL    (pv_irq_ops);
+EXPORT_SYMBOL_GPL(pv_pad_ops);
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..3f0fd27 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -30,6 +30,7 @@
 #include <linux/slab.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
+#include <acpi/acpi_pad.h>
 #include <asm/mwait.h>
=20
 #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
@@ -37,14 +38,14 @@
 #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
 static DEFINE_MUTEX(isolated_cpus_lock);
=20
-static unsigned long power_saving_mwait_eax;
+unsigned long power_saving_mwait_eax;
=20
 static unsigned char tsc_detected_unstable;
 static unsigned char tsc_marked_unstable;
 static unsigned char lapic_detected_unstable;
 static unsigned char lapic_marked_unstable;
=20
-static void power_saving_mwait_init(void)
+void power_saving_mwait_init(void)
 {
 	unsigned int eax, ebx, ecx, edx;
 	unsigned int highest_cstate =3D 0;
@@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] =3D=
 {
 };
 MODULE_DEVICE_TABLE(acpi, pad_device_ids);
=20
-static struct acpi_driver acpi_pad_driver =3D {
+struct acpi_driver acpi_pad_driver =3D {
 	.name =3D "processor_aggregator",
 	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
 	.ids =3D pad_device_ids,
@@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver =3D {
=20
 static int __init acpi_pad_init(void)
 {
-	power_saving_mwait_init();
-	if (power_saving_mwait_eax =3D=3D 0)
-		return -EINVAL;
-
-	return acpi_bus_register_driver(&acpi_pad_driver);
+	return __acpi_pad_init();
 }
=20
 static void __exit acpi_pad_exit(void)
 {
-	acpi_bus_unregister_driver(&acpi_pad_driver);
+	__acpi_pad_exit();
 }
=20
 module_init(acpi_pad_init);
diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
new file mode 100644
index 0000000..1a1471d
--- /dev/null
+++ b/include/acpi/acpi_pad.h
@@ -0,0 +1,61 @@
+/*
+ *  acpi_pad.h - pad device helper for native and paravirt platform
+ *
+ *  Copyright (C) 2012, Intel Corporation.
+ *     Author: 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.
+ */
+
+#ifndef __ACPI_PAD_H__
+#define __ACPI_PAD_H__
+
+#include <acpi/acpi_bus.h>
+
+extern unsigned long power_saving_mwait_eax;
+extern struct acpi_driver acpi_pad_driver;
+extern void power_saving_mwait_init(void);
+
+static inline int native_acpi_pad_init(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	power_saving_mwait_init();
+	if (power_saving_mwait_eax =3D=3D 0)
+		return -EINVAL;
+
+	return acpi_bus_register_driver(&acpi_pad_driver);
+#else
+	return 0;
+#endif
+}
+
+static inline void native_acpi_pad_exit(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_bus_unregister_driver(&acpi_pad_driver);
+#endif
+}
+
+#ifdef CONFIG_PARAVIRT
+#include <asm/paravirt.h>
+#else
+static inline int __acpi_pad_init(void)
+{
+	return native_acpi_pad_init();
+}
+
+static inline void __acpi_pad_exit(void)
+{
+	native_acpi_pad_exit();
+}
+#endif
+
+#endif /* __ACPI_PAD_H__ */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-PAD-helper-for-native-and-paravirt-platform.patch"
Content-Description: 0001-PAD-helper-for-native-and-paravirt-platform.patch
Content-Disposition: attachment;
	filename="0001-PAD-helper-for-native-and-paravirt-platform.patch"; size=7005;
	creation-date="Fri, 17 Feb 2012 08:52:46 GMT";
	modification-date="Fri, 17 Feb 2012 16:49:16 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmNjZhMmRmMTM5MmJiZTY5NDI2Mzg3NjU3YTIyMDE3N2JlNTBkNThhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxMCBGZWIgMjAxMiAyMDozMjo1MCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8z
XSBQQUQgaGVscGVyIGZvciBuYXRpdmUgYW5kIHBhcmF2aXJ0IHBsYXRmb3JtCgpUaGlzIHBhdGNo
IGlzIFBBRCAoUHJvY2Vzc29yIEFnZ3JlZ2F0b3IgRGV2aWNlKSBoZWxwZXIuCkl0IHByb3ZpZGVz
IGEgbmF0aXZlIGludGVyZmFjZSBmb3IgbmF0dmllIHBsYXRmb3JtLCBhbmQgYSB0ZW1wbGF0ZQpm
b3IgcGFyYXZpcnQgcGxhdGZvcm0sIHNvIHRoYXQgb3MgY2FuIGltcGxpY2l0bHkgaG9vayB0byBw
cm9wZXIgb3BzIGFjY29yZGluZ2x5LgpUaGUgcGFyYXZpcnQgdGVtcGxhdGUgd2lsbCBmdXJ0aGVy
IHJlZGlyZWN0IHRvIFhlbiBwdiBvcHMgaW4gbGF0ZXIgcGF0Y2ggZm9yIFhlbgogY29yZSBwYXJr
aW5nLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
Ci0tLQogYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaCAgICAgICB8ICAgMTAgKysrKysK
IGFyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmggfCAgICA3ICsrKysKIGFyY2gv
eDg2L2tlcm5lbC9wYXJhdmlydC5jICAgICAgICAgICAgfCAgICA5ICsrKysrCiBkcml2ZXJzL2Fj
cGkvYWNwaV9wYWQuYyAgICAgICAgICAgICAgIHwgICAxNSArKystLS0tLQogaW5jbHVkZS9hY3Bp
L2FjcGlfcGFkLmggICAgICAgICAgICAgICB8ICAgNjEgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrCiA1IGZpbGVzIGNoYW5nZWQsIDkzIGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25z
KC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS9hY3BpL2FjcGlfcGFkLmgKCmRpZmYgLS1n
aXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oIGIvYXJjaC94ODYvaW5jbHVkZS9h
c20vcGFyYXZpcnQuaAppbmRleCBhN2QyZGI5Li4wMmU2ZGYwIDEwMDY0NAotLS0gYS9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2
aXJ0LmgKQEAgLTU0LDYgKzU0LDE2IEBAIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyByZWFk
X2NyMCh2b2lkKQogCXJldHVybiBQVk9QX0NBTEwwKHVuc2lnbmVkIGxvbmcsIHB2X2NwdV9vcHMu
cmVhZF9jcjApOwogfQogCitzdGF0aWMgaW5saW5lIGludCBfX2FjcGlfcGFkX2luaXQodm9pZCkK
K3sKKwlyZXR1cm4gUFZPUF9DQUxMMChpbnQsIHB2X3BhZF9vcHMuYWNwaV9wYWRfaW5pdCk7Cit9
CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBfX2FjcGlfcGFkX2V4aXQodm9pZCkKK3sKKwlQVk9QX1ZD
QUxMMChwdl9wYWRfb3BzLmFjcGlfcGFkX2V4aXQpOworfQorCiBzdGF0aWMgaW5saW5lIHZvaWQg
d3JpdGVfY3IwKHVuc2lnbmVkIGxvbmcgeCkKIHsKIAlQVk9QX1ZDQUxMMShwdl9jcHVfb3BzLndy
aXRlX2NyMCwgeCk7CmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90
eXBlcy5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaAppbmRleCA4ZThi
OWE0Li42MWUyMGRlIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90
eXBlcy5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmgKQEAgLTMz
Niw2ICszMzYsMTEgQEAgc3RydWN0IHB2X2xvY2tfb3BzIHsKIAl2b2lkICgqc3Bpbl91bmxvY2sp
KHN0cnVjdCBhcmNoX3NwaW5sb2NrICpsb2NrKTsKIH07CiAKK3N0cnVjdCBwdl9wYWRfb3BzIHsK
KwlpbnQgKCphY3BpX3BhZF9pbml0KSh2b2lkKTsKKwl2b2lkICgqYWNwaV9wYWRfZXhpdCkodm9p
ZCk7Cit9OworCiAvKiBUaGlzIGNvbnRhaW5zIGFsbCB0aGUgcGFyYXZpcnQgc3RydWN0dXJlczog
d2UgZ2V0IGEgY29udmVuaWVudAogICogbnVtYmVyIGZvciBlYWNoIGZ1bmN0aW9uIHVzaW5nIHRo
ZSBvZmZzZXQgd2hpY2ggd2UgdXNlIHRvIGluZGljYXRlCiAgKiB3aGF0IHRvIHBhdGNoLiAqLwpA
QCAtMzQ3LDYgKzM1Miw3IEBAIHN0cnVjdCBwYXJhdmlydF9wYXRjaF90ZW1wbGF0ZSB7CiAJc3Ry
dWN0IHB2X2FwaWNfb3BzIHB2X2FwaWNfb3BzOwogCXN0cnVjdCBwdl9tbXVfb3BzIHB2X21tdV9v
cHM7CiAJc3RydWN0IHB2X2xvY2tfb3BzIHB2X2xvY2tfb3BzOworCXN0cnVjdCBwdl9wYWRfb3Bz
IHB2X3BhZF9vcHM7CiB9OwogCiBleHRlcm4gc3RydWN0IHB2X2luZm8gcHZfaW5mbzsKQEAgLTM1
Nyw2ICszNjMsNyBAQCBleHRlcm4gc3RydWN0IHB2X2lycV9vcHMgcHZfaXJxX29wczsKIGV4dGVy
biBzdHJ1Y3QgcHZfYXBpY19vcHMgcHZfYXBpY19vcHM7CiBleHRlcm4gc3RydWN0IHB2X21tdV9v
cHMgcHZfbW11X29wczsKIGV4dGVybiBzdHJ1Y3QgcHZfbG9ja19vcHMgcHZfbG9ja19vcHM7Citl
eHRlcm4gc3RydWN0IHB2X3BhZF9vcHMgcHZfcGFkX29wczsKIAogI2RlZmluZSBQQVJBVklSVF9Q
QVRDSCh4KQkJCQkJXAogCShvZmZzZXRvZihzdHJ1Y3QgcGFyYXZpcnRfcGF0Y2hfdGVtcGxhdGUs
IHgpIC8gc2l6ZW9mKHZvaWQgKikpCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZp
cnQuYyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCmluZGV4IGQ5MDI3MmUuLmVjNzc4ZjYg
MTAwNjQ0Ci0tLSBhL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCisrKyBiL2FyY2gveDg2L2tl
cm5lbC9wYXJhdmlydC5jCkBAIC0zOCw2ICszOCw4IEBACiAjaW5jbHVkZSA8YXNtL3RsYmZsdXNo
Lmg+CiAjaW5jbHVkZSA8YXNtL3RpbWVyLmg+CiAKKyNpbmNsdWRlIDxhY3BpL2FjcGlfcGFkLmg+
CisKIC8qIG5vcCBzdHViICovCiB2b2lkIF9wYXJhdmlydF9ub3Aodm9pZCkKIHsKQEAgLTEzMiw2
ICsxMzQsNyBAQCBzdGF0aWMgdm9pZCAqZ2V0X2NhbGxfZGVzdGluYXRpb24odTggdHlwZSkKICNp
ZmRlZiBDT05GSUdfUEFSQVZJUlRfU1BJTkxPQ0tTCiAJCS5wdl9sb2NrX29wcyA9IHB2X2xvY2tf
b3BzLAogI2VuZGlmCisJCS5wdl9wYWRfb3BzID0gcHZfcGFkX29wcywKIAl9OwogCXJldHVybiAq
KCh2b2lkICoqKSZ0bXBsICsgdHlwZSk7CiB9CkBAIC00ODAsOSArNDgzLDE1IEBAIHN0cnVjdCBw
dl9tbXVfb3BzIHB2X21tdV9vcHMgPSB7CiAJLnNldF9maXhtYXAgPSBuYXRpdmVfc2V0X2ZpeG1h
cCwKIH07CiAKK3N0cnVjdCBwdl9wYWRfb3BzIHB2X3BhZF9vcHMgPSB7CisJLmFjcGlfcGFkX2lu
aXQgPSBuYXRpdmVfYWNwaV9wYWRfaW5pdCwKKwkuYWNwaV9wYWRfZXhpdCA9IG5hdGl2ZV9hY3Bp
X3BhZF9leGl0LAorfTsKKwogRVhQT1JUX1NZTUJPTF9HUEwocHZfdGltZV9vcHMpOwogRVhQT1JU
X1NZTUJPTCAgICAocHZfY3B1X29wcyk7CiBFWFBPUlRfU1lNQk9MICAgIChwdl9tbXVfb3BzKTsK
IEVYUE9SVF9TWU1CT0xfR1BMKHB2X2FwaWNfb3BzKTsKIEVYUE9SVF9TWU1CT0xfR1BMKHB2X2lu
Zm8pOwogRVhQT1JUX1NZTUJPTCAgICAocHZfaXJxX29wcyk7CitFWFBPUlRfU1lNQk9MX0dQTChw
dl9wYWRfb3BzKTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX3BhZC5jIGIvZHJpdmVy
cy9hY3BpL2FjcGlfcGFkLmMKaW5kZXggYTQzZmExYS4uM2YwZmQyNyAxMDA2NDQKLS0tIGEvZHJp
dmVycy9hY3BpL2FjcGlfcGFkLmMKKysrIGIvZHJpdmVycy9hY3BpL2FjcGlfcGFkLmMKQEAgLTMw
LDYgKzMwLDcgQEAKICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+CiAjaW5jbHVkZSA8YWNwaS9hY3Bp
X2J1cy5oPgogI2luY2x1ZGUgPGFjcGkvYWNwaV9kcml2ZXJzLmg+CisjaW5jbHVkZSA8YWNwaS9h
Y3BpX3BhZC5oPgogI2luY2x1ZGUgPGFzbS9td2FpdC5oPgogCiAjZGVmaW5lIEFDUElfUFJPQ0VT
U09SX0FHR1JFR0FUT1JfQ0xBU1MJImFjcGlfcGFkIgpAQCAtMzcsMTQgKzM4LDE0IEBACiAjZGVm
aW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZIDB4ODAKIHN0YXRpYyBERUZJTkVf
TVVURVgoaXNvbGF0ZWRfY3B1c19sb2NrKTsKIAotc3RhdGljIHVuc2lnbmVkIGxvbmcgcG93ZXJf
c2F2aW5nX213YWl0X2VheDsKK3Vuc2lnbmVkIGxvbmcgcG93ZXJfc2F2aW5nX213YWl0X2VheDsK
IAogc3RhdGljIHVuc2lnbmVkIGNoYXIgdHNjX2RldGVjdGVkX3Vuc3RhYmxlOwogc3RhdGljIHVu
c2lnbmVkIGNoYXIgdHNjX21hcmtlZF91bnN0YWJsZTsKIHN0YXRpYyB1bnNpZ25lZCBjaGFyIGxh
cGljX2RldGVjdGVkX3Vuc3RhYmxlOwogc3RhdGljIHVuc2lnbmVkIGNoYXIgbGFwaWNfbWFya2Vk
X3Vuc3RhYmxlOwogCi1zdGF0aWMgdm9pZCBwb3dlcl9zYXZpbmdfbXdhaXRfaW5pdCh2b2lkKQor
dm9pZCBwb3dlcl9zYXZpbmdfbXdhaXRfaW5pdCh2b2lkKQogewogCXVuc2lnbmVkIGludCBlYXgs
IGVieCwgZWN4LCBlZHg7CiAJdW5zaWduZWQgaW50IGhpZ2hlc3RfY3N0YXRlID0gMDsKQEAgLTUw
MCw3ICs1MDEsNyBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IGFjcGlfZGV2aWNlX2lkIHBhZF9kZXZp
Y2VfaWRzW10gPSB7CiB9OwogTU9EVUxFX0RFVklDRV9UQUJMRShhY3BpLCBwYWRfZGV2aWNlX2lk
cyk7CiAKLXN0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgYWNwaV9wYWRfZHJpdmVyID0geworc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfcGFkX2RyaXZlciA9IHsKIAkubmFtZSA9ICJwcm9jZXNzb3Jf
YWdncmVnYXRvciIsCiAJLmNsYXNzID0gQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUywK
IAkuaWRzID0gcGFkX2RldmljZV9pZHMsCkBAIC01MTIsMTYgKzUxMywxMiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfcGFkX2RyaXZlciA9IHsKIAogc3RhdGljIGludCBfX2luaXQg
YWNwaV9wYWRfaW5pdCh2b2lkKQogewotCXBvd2VyX3NhdmluZ19td2FpdF9pbml0KCk7Ci0JaWYg
KHBvd2VyX3NhdmluZ19td2FpdF9lYXggPT0gMCkKLQkJcmV0dXJuIC1FSU5WQUw7Ci0KLQlyZXR1
cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIpOworCXJldHVybiBf
X2FjcGlfcGFkX2luaXQoKTsKIH0KIAogc3RhdGljIHZvaWQgX19leGl0IGFjcGlfcGFkX2V4aXQo
dm9pZCkKIHsKLQlhY3BpX2J1c191bnJlZ2lzdGVyX2RyaXZlcigmYWNwaV9wYWRfZHJpdmVyKTsK
KwlfX2FjcGlfcGFkX2V4aXQoKTsKIH0KIAogbW9kdWxlX2luaXQoYWNwaV9wYWRfaW5pdCk7CmRp
ZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9wYWQuaCBiL2luY2x1ZGUvYWNwaS9hY3BpX3Bh
ZC5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjFhMTQ3MWQKLS0tIC9kZXYv
bnVsbAorKysgYi9pbmNsdWRlL2FjcGkvYWNwaV9wYWQuaApAQCAtMCwwICsxLDYxIEBACisvKgor
ICogIGFjcGlfcGFkLmggLSBwYWQgZGV2aWNlIGhlbHBlciBmb3IgbmF0aXZlIGFuZCBwYXJhdmly
dCBwbGF0Zm9ybQorICoKKyAqICBDb3B5cmlnaHQgKEMpIDIwMTIsIEludGVsIENvcnBvcmF0aW9u
LgorICogICAgIEF1dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Cisg
KgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQKKyAq
ICB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq
ICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCisgKiAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiAgU2VlIHRoZSBHTlUKKyAqICBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKi8KKworI2lmbmRlZiBfX0FDUElfUEFEX0hfXworI2RlZmluZSBfX0FDUElfUEFE
X0hfXworCisjaW5jbHVkZSA8YWNwaS9hY3BpX2J1cy5oPgorCitleHRlcm4gdW5zaWduZWQgbG9u
ZyBwb3dlcl9zYXZpbmdfbXdhaXRfZWF4OworZXh0ZXJuIHN0cnVjdCBhY3BpX2RyaXZlciBhY3Bp
X3BhZF9kcml2ZXI7CitleHRlcm4gdm9pZCBwb3dlcl9zYXZpbmdfbXdhaXRfaW5pdCh2b2lkKTsK
Kworc3RhdGljIGlubGluZSBpbnQgbmF0aXZlX2FjcGlfcGFkX2luaXQodm9pZCkKK3sKKyNpZmRl
ZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUgorCXBvd2VyX3NhdmluZ19td2FpdF9p
bml0KCk7CisJaWYgKHBvd2VyX3NhdmluZ19td2FpdF9lYXggPT0gMCkKKwkJcmV0dXJuIC1FSU5W
QUw7CisKKwlyZXR1cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIp
OworI2Vsc2UKKwlyZXR1cm4gMDsKKyNlbmRpZgorfQorCitzdGF0aWMgaW5saW5lIHZvaWQgbmF0
aXZlX2FjcGlfcGFkX2V4aXQodm9pZCkKK3sKKyNpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1Jf
QUdHUkVHQVRPUgorCWFjcGlfYnVzX3VucmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIp
OworI2VuZGlmCit9CisKKyNpZmRlZiBDT05GSUdfUEFSQVZJUlQKKyNpbmNsdWRlIDxhc20vcGFy
YXZpcnQuaD4KKyNlbHNlCitzdGF0aWMgaW5saW5lIGludCBfX2FjcGlfcGFkX2luaXQodm9pZCkK
K3sKKwlyZXR1cm4gbmF0aXZlX2FjcGlfcGFkX2luaXQoKTsKK30KKworc3RhdGljIGlubGluZSB2
b2lkIF9fYWNwaV9wYWRfZXhpdCh2b2lkKQoreworCW5hdGl2ZV9hY3BpX3BhZF9leGl0KCk7Cit9
CisjZW5kaWYKKworI2VuZGlmIC8qIF9fQUNQSV9QQURfSF9fICovCi0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:58:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJdm-0005pB-O7; Fri, 17 Feb 2012 08:58:06 +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 1RyJdk-0005p1-W8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:58:05 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329469037!52824127!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30468 invoked from network); 17 Feb 2012 08:57:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 08:57:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:57:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="118565975"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:57:55 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:56:45 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:56:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:56:43 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 1/3] PAD helper for native and paravirt platform
Thread-Index: AcztUhHG6RKQx7+6TLaQA8tFAlSyZg==
Date: Fri, 17 Feb 2012 08:56:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D853@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_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 10 Feb 2012 20:32:50 +0800
Subject: [PATCH 1/3] PAD helper for native and paravirt platform

This patch is PAD (Processor Aggregator Device) helper.
It provides a native interface for natvie platform, and a template
for paravirt platform, so that os can implicitly hook to proper ops accordi=
ngly.
The paravirt template will further redirect to Xen pv ops in later patch fo=
r Xen
 core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/include/asm/paravirt.h       |   10 +++++
 arch/x86/include/asm/paravirt_types.h |    7 ++++
 arch/x86/kernel/paravirt.c            |    9 +++++
 drivers/acpi/acpi_pad.c               |   15 +++-----
 include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++=
++++
 5 files changed, 93 insertions(+), 9 deletions(-)
 create mode 100644 include/acpi/acpi_pad.h

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravir=
t.h
index a7d2db9..02e6df0 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
 	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
 }
=20
+static inline int __acpi_pad_init(void)
+{
+	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
+}
+
+static inline void __acpi_pad_exit(void)
+{
+	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
+}
+
 static inline void write_cr0(unsigned long x)
 {
 	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/p=
aravirt_types.h
index 8e8b9a4..61e20de 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -336,6 +336,11 @@ struct pv_lock_ops {
 	void (*spin_unlock)(struct arch_spinlock *lock);
 };
=20
+struct pv_pad_ops {
+	int (*acpi_pad_init)(void);
+	void (*acpi_pad_exit)(void);
+};
+
 /* This contains all the paravirt structures: we get a convenient
  * number for each function using the offset which we use to indicate
  * what to patch. */
@@ -347,6 +352,7 @@ struct paravirt_patch_template {
 	struct pv_apic_ops pv_apic_ops;
 	struct pv_mmu_ops pv_mmu_ops;
 	struct pv_lock_ops pv_lock_ops;
+	struct pv_pad_ops pv_pad_ops;
 };
=20
 extern struct pv_info pv_info;
@@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
 extern struct pv_apic_ops pv_apic_ops;
 extern struct pv_mmu_ops pv_mmu_ops;
 extern struct pv_lock_ops pv_lock_ops;
+extern struct pv_pad_ops pv_pad_ops;
=20
 #define PARAVIRT_PATCH(x)					\
 	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index d90272e..ec778f6 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -38,6 +38,8 @@
 #include <asm/tlbflush.h>
 #include <asm/timer.h>
=20
+#include <acpi/acpi_pad.h>
+
 /* nop stub */
 void _paravirt_nop(void)
 {
@@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 		.pv_lock_ops =3D pv_lock_ops,
 #endif
+		.pv_pad_ops =3D pv_pad_ops,
 	};
 	return *((void **)&tmpl + type);
 }
@@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops =3D {
 	.set_fixmap =3D native_set_fixmap,
 };
=20
+struct pv_pad_ops pv_pad_ops =3D {
+	.acpi_pad_init =3D native_acpi_pad_init,
+	.acpi_pad_exit =3D native_acpi_pad_exit,
+};
+
 EXPORT_SYMBOL_GPL(pv_time_ops);
 EXPORT_SYMBOL    (pv_cpu_ops);
 EXPORT_SYMBOL    (pv_mmu_ops);
 EXPORT_SYMBOL_GPL(pv_apic_ops);
 EXPORT_SYMBOL_GPL(pv_info);
 EXPORT_SYMBOL    (pv_irq_ops);
+EXPORT_SYMBOL_GPL(pv_pad_ops);
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..3f0fd27 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -30,6 +30,7 @@
 #include <linux/slab.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
+#include <acpi/acpi_pad.h>
 #include <asm/mwait.h>
=20
 #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
@@ -37,14 +38,14 @@
 #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
 static DEFINE_MUTEX(isolated_cpus_lock);
=20
-static unsigned long power_saving_mwait_eax;
+unsigned long power_saving_mwait_eax;
=20
 static unsigned char tsc_detected_unstable;
 static unsigned char tsc_marked_unstable;
 static unsigned char lapic_detected_unstable;
 static unsigned char lapic_marked_unstable;
=20
-static void power_saving_mwait_init(void)
+void power_saving_mwait_init(void)
 {
 	unsigned int eax, ebx, ecx, edx;
 	unsigned int highest_cstate =3D 0;
@@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] =3D=
 {
 };
 MODULE_DEVICE_TABLE(acpi, pad_device_ids);
=20
-static struct acpi_driver acpi_pad_driver =3D {
+struct acpi_driver acpi_pad_driver =3D {
 	.name =3D "processor_aggregator",
 	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
 	.ids =3D pad_device_ids,
@@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver =3D {
=20
 static int __init acpi_pad_init(void)
 {
-	power_saving_mwait_init();
-	if (power_saving_mwait_eax =3D=3D 0)
-		return -EINVAL;
-
-	return acpi_bus_register_driver(&acpi_pad_driver);
+	return __acpi_pad_init();
 }
=20
 static void __exit acpi_pad_exit(void)
 {
-	acpi_bus_unregister_driver(&acpi_pad_driver);
+	__acpi_pad_exit();
 }
=20
 module_init(acpi_pad_init);
diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
new file mode 100644
index 0000000..1a1471d
--- /dev/null
+++ b/include/acpi/acpi_pad.h
@@ -0,0 +1,61 @@
+/*
+ *  acpi_pad.h - pad device helper for native and paravirt platform
+ *
+ *  Copyright (C) 2012, Intel Corporation.
+ *     Author: 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.
+ */
+
+#ifndef __ACPI_PAD_H__
+#define __ACPI_PAD_H__
+
+#include <acpi/acpi_bus.h>
+
+extern unsigned long power_saving_mwait_eax;
+extern struct acpi_driver acpi_pad_driver;
+extern void power_saving_mwait_init(void);
+
+static inline int native_acpi_pad_init(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	power_saving_mwait_init();
+	if (power_saving_mwait_eax =3D=3D 0)
+		return -EINVAL;
+
+	return acpi_bus_register_driver(&acpi_pad_driver);
+#else
+	return 0;
+#endif
+}
+
+static inline void native_acpi_pad_exit(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_bus_unregister_driver(&acpi_pad_driver);
+#endif
+}
+
+#ifdef CONFIG_PARAVIRT
+#include <asm/paravirt.h>
+#else
+static inline int __acpi_pad_init(void)
+{
+	return native_acpi_pad_init();
+}
+
+static inline void __acpi_pad_exit(void)
+{
+	native_acpi_pad_exit();
+}
+#endif
+
+#endif /* __ACPI_PAD_H__ */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-PAD-helper-for-native-and-paravirt-platform.patch"
Content-Description: 0001-PAD-helper-for-native-and-paravirt-platform.patch
Content-Disposition: attachment;
	filename="0001-PAD-helper-for-native-and-paravirt-platform.patch"; size=7005;
	creation-date="Fri, 17 Feb 2012 08:52:46 GMT";
	modification-date="Fri, 17 Feb 2012 16:49:16 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmNjZhMmRmMTM5MmJiZTY5NDI2Mzg3NjU3YTIyMDE3N2JlNTBkNThhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxMCBGZWIgMjAxMiAyMDozMjo1MCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8z
XSBQQUQgaGVscGVyIGZvciBuYXRpdmUgYW5kIHBhcmF2aXJ0IHBsYXRmb3JtCgpUaGlzIHBhdGNo
IGlzIFBBRCAoUHJvY2Vzc29yIEFnZ3JlZ2F0b3IgRGV2aWNlKSBoZWxwZXIuCkl0IHByb3ZpZGVz
IGEgbmF0aXZlIGludGVyZmFjZSBmb3IgbmF0dmllIHBsYXRmb3JtLCBhbmQgYSB0ZW1wbGF0ZQpm
b3IgcGFyYXZpcnQgcGxhdGZvcm0sIHNvIHRoYXQgb3MgY2FuIGltcGxpY2l0bHkgaG9vayB0byBw
cm9wZXIgb3BzIGFjY29yZGluZ2x5LgpUaGUgcGFyYXZpcnQgdGVtcGxhdGUgd2lsbCBmdXJ0aGVy
IHJlZGlyZWN0IHRvIFhlbiBwdiBvcHMgaW4gbGF0ZXIgcGF0Y2ggZm9yIFhlbgogY29yZSBwYXJr
aW5nLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
Ci0tLQogYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaCAgICAgICB8ICAgMTAgKysrKysK
IGFyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmggfCAgICA3ICsrKysKIGFyY2gv
eDg2L2tlcm5lbC9wYXJhdmlydC5jICAgICAgICAgICAgfCAgICA5ICsrKysrCiBkcml2ZXJzL2Fj
cGkvYWNwaV9wYWQuYyAgICAgICAgICAgICAgIHwgICAxNSArKystLS0tLQogaW5jbHVkZS9hY3Bp
L2FjcGlfcGFkLmggICAgICAgICAgICAgICB8ICAgNjEgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrCiA1IGZpbGVzIGNoYW5nZWQsIDkzIGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25z
KC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS9hY3BpL2FjcGlfcGFkLmgKCmRpZmYgLS1n
aXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oIGIvYXJjaC94ODYvaW5jbHVkZS9h
c20vcGFyYXZpcnQuaAppbmRleCBhN2QyZGI5Li4wMmU2ZGYwIDEwMDY0NAotLS0gYS9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2
aXJ0LmgKQEAgLTU0LDYgKzU0LDE2IEBAIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyByZWFk
X2NyMCh2b2lkKQogCXJldHVybiBQVk9QX0NBTEwwKHVuc2lnbmVkIGxvbmcsIHB2X2NwdV9vcHMu
cmVhZF9jcjApOwogfQogCitzdGF0aWMgaW5saW5lIGludCBfX2FjcGlfcGFkX2luaXQodm9pZCkK
K3sKKwlyZXR1cm4gUFZPUF9DQUxMMChpbnQsIHB2X3BhZF9vcHMuYWNwaV9wYWRfaW5pdCk7Cit9
CisKK3N0YXRpYyBpbmxpbmUgdm9pZCBfX2FjcGlfcGFkX2V4aXQodm9pZCkKK3sKKwlQVk9QX1ZD
QUxMMChwdl9wYWRfb3BzLmFjcGlfcGFkX2V4aXQpOworfQorCiBzdGF0aWMgaW5saW5lIHZvaWQg
d3JpdGVfY3IwKHVuc2lnbmVkIGxvbmcgeCkKIHsKIAlQVk9QX1ZDQUxMMShwdl9jcHVfb3BzLndy
aXRlX2NyMCwgeCk7CmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90
eXBlcy5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaAppbmRleCA4ZThi
OWE0Li42MWUyMGRlIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90
eXBlcy5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmgKQEAgLTMz
Niw2ICszMzYsMTEgQEAgc3RydWN0IHB2X2xvY2tfb3BzIHsKIAl2b2lkICgqc3Bpbl91bmxvY2sp
KHN0cnVjdCBhcmNoX3NwaW5sb2NrICpsb2NrKTsKIH07CiAKK3N0cnVjdCBwdl9wYWRfb3BzIHsK
KwlpbnQgKCphY3BpX3BhZF9pbml0KSh2b2lkKTsKKwl2b2lkICgqYWNwaV9wYWRfZXhpdCkodm9p
ZCk7Cit9OworCiAvKiBUaGlzIGNvbnRhaW5zIGFsbCB0aGUgcGFyYXZpcnQgc3RydWN0dXJlczog
d2UgZ2V0IGEgY29udmVuaWVudAogICogbnVtYmVyIGZvciBlYWNoIGZ1bmN0aW9uIHVzaW5nIHRo
ZSBvZmZzZXQgd2hpY2ggd2UgdXNlIHRvIGluZGljYXRlCiAgKiB3aGF0IHRvIHBhdGNoLiAqLwpA
QCAtMzQ3LDYgKzM1Miw3IEBAIHN0cnVjdCBwYXJhdmlydF9wYXRjaF90ZW1wbGF0ZSB7CiAJc3Ry
dWN0IHB2X2FwaWNfb3BzIHB2X2FwaWNfb3BzOwogCXN0cnVjdCBwdl9tbXVfb3BzIHB2X21tdV9v
cHM7CiAJc3RydWN0IHB2X2xvY2tfb3BzIHB2X2xvY2tfb3BzOworCXN0cnVjdCBwdl9wYWRfb3Bz
IHB2X3BhZF9vcHM7CiB9OwogCiBleHRlcm4gc3RydWN0IHB2X2luZm8gcHZfaW5mbzsKQEAgLTM1
Nyw2ICszNjMsNyBAQCBleHRlcm4gc3RydWN0IHB2X2lycV9vcHMgcHZfaXJxX29wczsKIGV4dGVy
biBzdHJ1Y3QgcHZfYXBpY19vcHMgcHZfYXBpY19vcHM7CiBleHRlcm4gc3RydWN0IHB2X21tdV9v
cHMgcHZfbW11X29wczsKIGV4dGVybiBzdHJ1Y3QgcHZfbG9ja19vcHMgcHZfbG9ja19vcHM7Citl
eHRlcm4gc3RydWN0IHB2X3BhZF9vcHMgcHZfcGFkX29wczsKIAogI2RlZmluZSBQQVJBVklSVF9Q
QVRDSCh4KQkJCQkJXAogCShvZmZzZXRvZihzdHJ1Y3QgcGFyYXZpcnRfcGF0Y2hfdGVtcGxhdGUs
IHgpIC8gc2l6ZW9mKHZvaWQgKikpCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZp
cnQuYyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCmluZGV4IGQ5MDI3MmUuLmVjNzc4ZjYg
MTAwNjQ0Ci0tLSBhL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCisrKyBiL2FyY2gveDg2L2tl
cm5lbC9wYXJhdmlydC5jCkBAIC0zOCw2ICszOCw4IEBACiAjaW5jbHVkZSA8YXNtL3RsYmZsdXNo
Lmg+CiAjaW5jbHVkZSA8YXNtL3RpbWVyLmg+CiAKKyNpbmNsdWRlIDxhY3BpL2FjcGlfcGFkLmg+
CisKIC8qIG5vcCBzdHViICovCiB2b2lkIF9wYXJhdmlydF9ub3Aodm9pZCkKIHsKQEAgLTEzMiw2
ICsxMzQsNyBAQCBzdGF0aWMgdm9pZCAqZ2V0X2NhbGxfZGVzdGluYXRpb24odTggdHlwZSkKICNp
ZmRlZiBDT05GSUdfUEFSQVZJUlRfU1BJTkxPQ0tTCiAJCS5wdl9sb2NrX29wcyA9IHB2X2xvY2tf
b3BzLAogI2VuZGlmCisJCS5wdl9wYWRfb3BzID0gcHZfcGFkX29wcywKIAl9OwogCXJldHVybiAq
KCh2b2lkICoqKSZ0bXBsICsgdHlwZSk7CiB9CkBAIC00ODAsOSArNDgzLDE1IEBAIHN0cnVjdCBw
dl9tbXVfb3BzIHB2X21tdV9vcHMgPSB7CiAJLnNldF9maXhtYXAgPSBuYXRpdmVfc2V0X2ZpeG1h
cCwKIH07CiAKK3N0cnVjdCBwdl9wYWRfb3BzIHB2X3BhZF9vcHMgPSB7CisJLmFjcGlfcGFkX2lu
aXQgPSBuYXRpdmVfYWNwaV9wYWRfaW5pdCwKKwkuYWNwaV9wYWRfZXhpdCA9IG5hdGl2ZV9hY3Bp
X3BhZF9leGl0LAorfTsKKwogRVhQT1JUX1NZTUJPTF9HUEwocHZfdGltZV9vcHMpOwogRVhQT1JU
X1NZTUJPTCAgICAocHZfY3B1X29wcyk7CiBFWFBPUlRfU1lNQk9MICAgIChwdl9tbXVfb3BzKTsK
IEVYUE9SVF9TWU1CT0xfR1BMKHB2X2FwaWNfb3BzKTsKIEVYUE9SVF9TWU1CT0xfR1BMKHB2X2lu
Zm8pOwogRVhQT1JUX1NZTUJPTCAgICAocHZfaXJxX29wcyk7CitFWFBPUlRfU1lNQk9MX0dQTChw
dl9wYWRfb3BzKTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpX3BhZC5jIGIvZHJpdmVy
cy9hY3BpL2FjcGlfcGFkLmMKaW5kZXggYTQzZmExYS4uM2YwZmQyNyAxMDA2NDQKLS0tIGEvZHJp
dmVycy9hY3BpL2FjcGlfcGFkLmMKKysrIGIvZHJpdmVycy9hY3BpL2FjcGlfcGFkLmMKQEAgLTMw
LDYgKzMwLDcgQEAKICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+CiAjaW5jbHVkZSA8YWNwaS9hY3Bp
X2J1cy5oPgogI2luY2x1ZGUgPGFjcGkvYWNwaV9kcml2ZXJzLmg+CisjaW5jbHVkZSA8YWNwaS9h
Y3BpX3BhZC5oPgogI2luY2x1ZGUgPGFzbS9td2FpdC5oPgogCiAjZGVmaW5lIEFDUElfUFJPQ0VT
U09SX0FHR1JFR0FUT1JfQ0xBU1MJImFjcGlfcGFkIgpAQCAtMzcsMTQgKzM4LDE0IEBACiAjZGVm
aW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZIDB4ODAKIHN0YXRpYyBERUZJTkVf
TVVURVgoaXNvbGF0ZWRfY3B1c19sb2NrKTsKIAotc3RhdGljIHVuc2lnbmVkIGxvbmcgcG93ZXJf
c2F2aW5nX213YWl0X2VheDsKK3Vuc2lnbmVkIGxvbmcgcG93ZXJfc2F2aW5nX213YWl0X2VheDsK
IAogc3RhdGljIHVuc2lnbmVkIGNoYXIgdHNjX2RldGVjdGVkX3Vuc3RhYmxlOwogc3RhdGljIHVu
c2lnbmVkIGNoYXIgdHNjX21hcmtlZF91bnN0YWJsZTsKIHN0YXRpYyB1bnNpZ25lZCBjaGFyIGxh
cGljX2RldGVjdGVkX3Vuc3RhYmxlOwogc3RhdGljIHVuc2lnbmVkIGNoYXIgbGFwaWNfbWFya2Vk
X3Vuc3RhYmxlOwogCi1zdGF0aWMgdm9pZCBwb3dlcl9zYXZpbmdfbXdhaXRfaW5pdCh2b2lkKQor
dm9pZCBwb3dlcl9zYXZpbmdfbXdhaXRfaW5pdCh2b2lkKQogewogCXVuc2lnbmVkIGludCBlYXgs
IGVieCwgZWN4LCBlZHg7CiAJdW5zaWduZWQgaW50IGhpZ2hlc3RfY3N0YXRlID0gMDsKQEAgLTUw
MCw3ICs1MDEsNyBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IGFjcGlfZGV2aWNlX2lkIHBhZF9kZXZp
Y2VfaWRzW10gPSB7CiB9OwogTU9EVUxFX0RFVklDRV9UQUJMRShhY3BpLCBwYWRfZGV2aWNlX2lk
cyk7CiAKLXN0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgYWNwaV9wYWRfZHJpdmVyID0geworc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfcGFkX2RyaXZlciA9IHsKIAkubmFtZSA9ICJwcm9jZXNzb3Jf
YWdncmVnYXRvciIsCiAJLmNsYXNzID0gQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUywK
IAkuaWRzID0gcGFkX2RldmljZV9pZHMsCkBAIC01MTIsMTYgKzUxMywxMiBAQCBzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIGFjcGlfcGFkX2RyaXZlciA9IHsKIAogc3RhdGljIGludCBfX2luaXQg
YWNwaV9wYWRfaW5pdCh2b2lkKQogewotCXBvd2VyX3NhdmluZ19td2FpdF9pbml0KCk7Ci0JaWYg
KHBvd2VyX3NhdmluZ19td2FpdF9lYXggPT0gMCkKLQkJcmV0dXJuIC1FSU5WQUw7Ci0KLQlyZXR1
cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIpOworCXJldHVybiBf
X2FjcGlfcGFkX2luaXQoKTsKIH0KIAogc3RhdGljIHZvaWQgX19leGl0IGFjcGlfcGFkX2V4aXQo
dm9pZCkKIHsKLQlhY3BpX2J1c191bnJlZ2lzdGVyX2RyaXZlcigmYWNwaV9wYWRfZHJpdmVyKTsK
KwlfX2FjcGlfcGFkX2V4aXQoKTsKIH0KIAogbW9kdWxlX2luaXQoYWNwaV9wYWRfaW5pdCk7CmRp
ZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9wYWQuaCBiL2luY2x1ZGUvYWNwaS9hY3BpX3Bh
ZC5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjFhMTQ3MWQKLS0tIC9kZXYv
bnVsbAorKysgYi9pbmNsdWRlL2FjcGkvYWNwaV9wYWQuaApAQCAtMCwwICsxLDYxIEBACisvKgor
ICogIGFjcGlfcGFkLmggLSBwYWQgZGV2aWNlIGhlbHBlciBmb3IgbmF0aXZlIGFuZCBwYXJhdmly
dCBwbGF0Zm9ybQorICoKKyAqICBDb3B5cmlnaHQgKEMpIDIwMTIsIEludGVsIENvcnBvcmF0aW9u
LgorICogICAgIEF1dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Cisg
KgorICogIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiAgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyAqICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQKKyAq
ICB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICogIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq
ICBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5
IG9mCisgKiAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiAgU2VlIHRoZSBHTlUKKyAqICBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl
dGFpbHMuCisgKi8KKworI2lmbmRlZiBfX0FDUElfUEFEX0hfXworI2RlZmluZSBfX0FDUElfUEFE
X0hfXworCisjaW5jbHVkZSA8YWNwaS9hY3BpX2J1cy5oPgorCitleHRlcm4gdW5zaWduZWQgbG9u
ZyBwb3dlcl9zYXZpbmdfbXdhaXRfZWF4OworZXh0ZXJuIHN0cnVjdCBhY3BpX2RyaXZlciBhY3Bp
X3BhZF9kcml2ZXI7CitleHRlcm4gdm9pZCBwb3dlcl9zYXZpbmdfbXdhaXRfaW5pdCh2b2lkKTsK
Kworc3RhdGljIGlubGluZSBpbnQgbmF0aXZlX2FjcGlfcGFkX2luaXQodm9pZCkKK3sKKyNpZmRl
ZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUgorCXBvd2VyX3NhdmluZ19td2FpdF9p
bml0KCk7CisJaWYgKHBvd2VyX3NhdmluZ19td2FpdF9lYXggPT0gMCkKKwkJcmV0dXJuIC1FSU5W
QUw7CisKKwlyZXR1cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIp
OworI2Vsc2UKKwlyZXR1cm4gMDsKKyNlbmRpZgorfQorCitzdGF0aWMgaW5saW5lIHZvaWQgbmF0
aXZlX2FjcGlfcGFkX2V4aXQodm9pZCkKK3sKKyNpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1Jf
QUdHUkVHQVRPUgorCWFjcGlfYnVzX3VucmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIp
OworI2VuZGlmCit9CisKKyNpZmRlZiBDT05GSUdfUEFSQVZJUlQKKyNpbmNsdWRlIDxhc20vcGFy
YXZpcnQuaD4KKyNlbHNlCitzdGF0aWMgaW5saW5lIGludCBfX2FjcGlfcGFkX2luaXQodm9pZCkK
K3sKKwlyZXR1cm4gbmF0aXZlX2FjcGlfcGFkX2luaXQoKTsKK30KKworc3RhdGljIGlubGluZSB2
b2lkIF9fYWNwaV9wYWRfZXhpdCh2b2lkKQoreworCW5hdGl2ZV9hY3BpX3BhZF9leGl0KCk7Cit9
CisjZW5kaWYKKworI2VuZGlmIC8qIF9fQUNQSV9QQURfSF9fICovCi0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D853SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:58:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJdx-0005qA-5e; Fri, 17 Feb 2012 08:58:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1RyJdw-0005pU-9b
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:58:16 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329469089!15259225!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29963 invoked from network); 17 Feb 2012 08:58:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 08:58:10 -0000
Received: by werb14 with SMTP id b14so5854816wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 00:58:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:reply-to:to:date:content-type:x-mailer
	:content-transfer-encoding:mime-version;
	bh=Hll/az6XE0CQUWv4M1NlB2hYx/Mhxm70TXeJAPOHpLY=;
	b=rZ4mVrZQF1HqLd8/3vt+QRDXWclIOz0OVMx1whkB7X8uXA7FyEC/pXOiXOtC7t1Gtu
	YPpNw+Wfr7BVd8JydI6NnMQW5dLshXrvFBLui4v1s8oGvxzGzD3/wV82MlODSppkKOlZ
	/jx5u28k+03dTaiJnbJjxquiht34wyekGTUZY=
Received: by 10.180.86.105 with SMTP id o9mr2104158wiz.4.1329469089593;
	Fri, 17 Feb 2012 00:58:09 -0800 (PST)
Received: from [192.168.1.140]
	(host170-152-static.43-88-b.business.telecomitalia.it.
	[88.43.152.170])
	by mx.google.com with ESMTPS id h19sm6094141wiw.9.2012.02.17.00.58.07
	(version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 00:58:08 -0800 (PST)
Message-ID: <1329469038.4815.11.camel@ironlight2.geaaru.homelinux.net>
From: "Ge@@ru" <geaaru@gmail.com>
To: Xen-Devel ML <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 09:57:18 +0100
X-Mailer: Evolution 3.2.3 
Mime-Version: 1.0
Subject: [Xen-devel] Dom0 with kernel 3.x and nvidia driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have a problem on use nvidia driver inside xen-dom0 kernel, version
3.x (I do test with this version: 3.0.18, 3.1.5, 3.2.5.

Compilation of the driver is done without errors and yet load of the
kernel driver is done correctly, but when I try to start X... I have
first a black screen and then monitor that go on standby status. It
seems that video card doesn't initialize correctly vga port.

I don't think that problem is on xorg server and I don't understand if
problem is on nvidia kernel driver because, same xorg-server, same
kernel image and same nvidia kernel module works fine if kernel is
bootstrap without xen hypervisor.

Could be relative to a wrong configuration on pass-through of the video
card bus from hypervisor to dom0 ? Is it correct speak of pass-through
yet on dom0 or pass-through is only for domU domain?

Same nvidia kernel driver works correctly on dom0 if I use
kernel-2.6.38-xen (gentoo ebuild).

Any suggestions ?

Thanks in advance




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:58:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJdx-0005qA-5e; Fri, 17 Feb 2012 08:58:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1RyJdw-0005pU-9b
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:58:16 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329469089!15259225!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29963 invoked from network); 17 Feb 2012 08:58:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 08:58:10 -0000
Received: by werb14 with SMTP id b14so5854816wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 00:58:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:reply-to:to:date:content-type:x-mailer
	:content-transfer-encoding:mime-version;
	bh=Hll/az6XE0CQUWv4M1NlB2hYx/Mhxm70TXeJAPOHpLY=;
	b=rZ4mVrZQF1HqLd8/3vt+QRDXWclIOz0OVMx1whkB7X8uXA7FyEC/pXOiXOtC7t1Gtu
	YPpNw+Wfr7BVd8JydI6NnMQW5dLshXrvFBLui4v1s8oGvxzGzD3/wV82MlODSppkKOlZ
	/jx5u28k+03dTaiJnbJjxquiht34wyekGTUZY=
Received: by 10.180.86.105 with SMTP id o9mr2104158wiz.4.1329469089593;
	Fri, 17 Feb 2012 00:58:09 -0800 (PST)
Received: from [192.168.1.140]
	(host170-152-static.43-88-b.business.telecomitalia.it.
	[88.43.152.170])
	by mx.google.com with ESMTPS id h19sm6094141wiw.9.2012.02.17.00.58.07
	(version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 00:58:08 -0800 (PST)
Message-ID: <1329469038.4815.11.camel@ironlight2.geaaru.homelinux.net>
From: "Ge@@ru" <geaaru@gmail.com>
To: Xen-Devel ML <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 09:57:18 +0100
X-Mailer: Evolution 3.2.3 
Mime-Version: 1.0
Subject: [Xen-devel] Dom0 with kernel 3.x and nvidia driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have a problem on use nvidia driver inside xen-dom0 kernel, version
3.x (I do test with this version: 3.0.18, 3.1.5, 3.2.5.

Compilation of the driver is done without errors and yet load of the
kernel driver is done correctly, but when I try to start X... I have
first a black screen and then monitor that go on standby status. It
seems that video card doesn't initialize correctly vga port.

I don't think that problem is on xorg server and I don't understand if
problem is on nvidia kernel driver because, same xorg-server, same
kernel image and same nvidia kernel module works fine if kernel is
bootstrap without xen hypervisor.

Could be relative to a wrong configuration on pass-through of the video
card bus from hypervisor to dom0 ? Is it correct speak of pass-through
yet on dom0 or pass-through is only for domU domain?

Same nvidia kernel driver works correctly on dom0 if I use
kernel-2.6.38-xen (gentoo ebuild).

Any suggestions ?

Thanks in advance




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:59:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJez-0005wT-LP; Fri, 17 Feb 2012 08:59:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJey-0005w6-BI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:59:20 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329469152!13744344!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27920 invoked from network); 17 Feb 2012 08:59:13 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 08:59:13 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:59:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="118566230"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:59:11 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:57:50 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:57:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:57:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 2/3] Xen pad paravirt interface
Thread-Index: AcztUjkgdUkSYt9KSnaf70j5GjXZdQ==
Date: Fri, 17 Feb 2012 08:57:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D85E@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_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/3] Xen pad paravirt interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 9b7dbe30e9d2a862a0931ee365e832bbd4d6c2e5 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 10 Feb 2012 20:34:46 +0800
Subject: [PATCH 2/3] Xen pad paravirt interface

Redirect paravirt template to Xen pv ops, preparing for Xen core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/xen/enlighten.c   |    6 ++++++
 drivers/xen/Makefile       |    1 +
 drivers/xen/xen_acpi_pad.c |    8 ++++++++
 include/xen/xen-ops.h      |    3 +++
 4 files changed, 18 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..5b4f209 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1023,6 +1023,11 @@ static const struct pv_cpu_ops xen_cpu_ops __initcon=
st =3D {
 	.end_context_switch =3D xen_end_context_switch,
 };
=20
+static const struct pv_pad_ops xen_pad_ops __initconst =3D {
+	.acpi_pad_init =3D xen_acpi_pad_init,
+	.acpi_pad_exit =3D xen_acpi_pad_exit,
+};
+
 static const struct pv_apic_ops xen_apic_ops __initconst =3D {
 #ifdef CONFIG_X86_LOCAL_APIC
 	.startup_ipi_hook =3D paravirt_nop,
@@ -1126,6 +1131,7 @@ asmlinkage void __init xen_start_kernel(void)
 	pv_init_ops =3D xen_init_ops;
 	pv_cpu_ops =3D xen_cpu_ops;
 	pv_apic_ops =3D xen_apic_ops;
+	pv_pad_ops =3D xen_pad_ops;
=20
 	x86_init.resources.memory_setup =3D xen_memory_setup;
 	x86_init.oem.arch_setup =3D xen_arch_setup;
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..c0268c9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
=20
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..63ab2fb
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,8 @@
+int xen_acpi_pad_init(void)
+{
+	return 0;
+}
+
+void xen_acpi_pad_exit(void)
+{
+}
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 03c85d7..eeb0d38 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -28,4 +28,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma=
,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
=20
+int xen_acpi_pad_init(void);
+void xen_acpi_pad_exit(void);
+
 #endif /* INCLUDE_XEN_OPS_H */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Xen-pad-paravirt-interface.patch"
Content-Description: 0002-Xen-pad-paravirt-interface.patch
Content-Disposition: attachment;
	filename="0002-Xen-pad-paravirt-interface.patch"; size=2549;
	creation-date="Fri, 17 Feb 2012 08:52:46 GMT";
	modification-date="Fri, 17 Feb 2012 16:49:16 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5YjdkYmUzMGU5ZDJhODYyYTA5MzFlZTM2NWU4MzJiYmQ0ZDZjMmU1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxMCBGZWIgMjAxMiAyMDozNDo0NiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8z
XSBYZW4gcGFkIHBhcmF2aXJ0IGludGVyZmFjZQoKUmVkaXJlY3QgcGFyYXZpcnQgdGVtcGxhdGUg
dG8gWGVuIHB2IG9wcywgcHJlcGFyaW5nIGZvciBYZW4gY29yZSBwYXJraW5nLgoKU2lnbmVkLW9m
Zi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQogYXJjaC94ODYv
eGVuL2VubGlnaHRlbi5jICAgfCAgICA2ICsrKysrKwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAg
ICAgfCAgICAxICsKIGRyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jIHwgICAgOCArKysrKysrKwog
aW5jbHVkZS94ZW4veGVuLW9wcy5oICAgICAgfCAgICAzICsrKwogNCBmaWxlcyBjaGFuZ2VkLCAx
OCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZl
cnMveGVuL3hlbl9hY3BpX3BhZC5jCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRl
bi5jIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCmluZGV4IDEyZWIwN2IuLjViNGYyMDkgMTAw
NjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYworKysgYi9hcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMKQEAgLTEwMjMsNiArMTAyMywxMSBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IHB2X2Nw
dV9vcHMgeGVuX2NwdV9vcHMgX19pbml0Y29uc3QgPSB7CiAJLmVuZF9jb250ZXh0X3N3aXRjaCA9
IHhlbl9lbmRfY29udGV4dF9zd2l0Y2gsCiB9OwogCitzdGF0aWMgY29uc3Qgc3RydWN0IHB2X3Bh
ZF9vcHMgeGVuX3BhZF9vcHMgX19pbml0Y29uc3QgPSB7CisJLmFjcGlfcGFkX2luaXQgPSB4ZW5f
YWNwaV9wYWRfaW5pdCwKKwkuYWNwaV9wYWRfZXhpdCA9IHhlbl9hY3BpX3BhZF9leGl0LAorfTsK
Kwogc3RhdGljIGNvbnN0IHN0cnVjdCBwdl9hcGljX29wcyB4ZW5fYXBpY19vcHMgX19pbml0Y29u
c3QgPSB7CiAjaWZkZWYgQ09ORklHX1g4Nl9MT0NBTF9BUElDCiAJLnN0YXJ0dXBfaXBpX2hvb2sg
PSBwYXJhdmlydF9ub3AsCkBAIC0xMTI2LDYgKzExMzEsNyBAQCBhc21saW5rYWdlIHZvaWQgX19p
bml0IHhlbl9zdGFydF9rZXJuZWwodm9pZCkKIAlwdl9pbml0X29wcyA9IHhlbl9pbml0X29wczsK
IAlwdl9jcHVfb3BzID0geGVuX2NwdV9vcHM7CiAJcHZfYXBpY19vcHMgPSB4ZW5fYXBpY19vcHM7
CisJcHZfcGFkX29wcyA9IHhlbl9wYWRfb3BzOwogCiAJeDg2X2luaXQucmVzb3VyY2VzLm1lbW9y
eV9zZXR1cCA9IHhlbl9tZW1vcnlfc2V0dXA7CiAJeDg2X2luaXQub2VtLmFyY2hfc2V0dXAgPSB4
ZW5fYXJjaF9zZXR1cDsKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVy
cy94ZW4vTWFrZWZpbGUKaW5kZXggYWEzMTMzNy4uYzAyNjhjOSAxMDA2NDQKLS0tIGEvZHJpdmVy
cy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIwLDcg
QEAgb2JqLSQoQ09ORklHX1NXSU9UTEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09O
RklHX1hFTl9ET00wKQkJCSs9IHBjaS5vCiBvYmotJChDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5E
KQkrPSB4ZW4tcGNpYmFjay8KIG9iai0kKENPTkZJR19YRU5fUFJJVkNNRCkJCSs9IHhlbi1wcml2
Y21kLm8KK29iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSB4ZW5fYWNwaV9wYWQubwogCiB4ZW4t
ZXZ0Y2huLXkJCQkJOj0gZXZ0Y2huLm8KIHhlbi1nbnRkZXYteQkJCQk6PSBnbnRkZXYubwpkaWZm
IC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMgYi9kcml2ZXJzL3hlbi94ZW5fYWNw
aV9wYWQuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi42M2FiMmZiCi0tLSAv
ZGV2L251bGwKKysrIGIvZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMKQEAgLTAsMCArMSw4IEBA
CitpbnQgeGVuX2FjcGlfcGFkX2luaXQodm9pZCkKK3sKKwlyZXR1cm4gMDsKK30KKwordm9pZCB4
ZW5fYWNwaV9wYWRfZXhpdCh2b2lkKQoreworfQpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4veGVu
LW9wcy5oIGIvaW5jbHVkZS94ZW4veGVuLW9wcy5oCmluZGV4IDAzYzg1ZDcuLmVlYjBkMzggMTAw
NjQ0Ci0tLSBhL2luY2x1ZGUveGVuL3hlbi1vcHMuaAorKysgYi9pbmNsdWRlL3hlbi94ZW4tb3Bz
LmgKQEAgLTI4LDQgKzI4LDcgQEAgaW50IHhlbl9yZW1hcF9kb21haW5fbWZuX3JhbmdlKHN0cnVj
dCB2bV9hcmVhX3N0cnVjdCAqdm1hLAogCQkJICAgICAgIHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQg
bnIsCiAJCQkgICAgICAgcGdwcm90X3QgcHJvdCwgdW5zaWduZWQgZG9taWQpOwogCitpbnQgeGVu
X2FjcGlfcGFkX2luaXQodm9pZCk7Cit2b2lkIHhlbl9hY3BpX3BhZF9leGl0KHZvaWQpOworCiAj
ZW5kaWYgLyogSU5DTFVERV9YRU5fT1BTX0ggKi8KLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:59:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJez-0005wT-LP; Fri, 17 Feb 2012 08:59:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJey-0005w6-BI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:59:20 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329469152!13744344!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27920 invoked from network); 17 Feb 2012 08:59:13 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 08:59:13 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:59:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="118566230"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:59:11 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:57:50 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:57:50 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:57:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 2/3] Xen pad paravirt interface
Thread-Index: AcztUjkgdUkSYt9KSnaf70j5GjXZdQ==
Date: Fri, 17 Feb 2012 08:57:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D85E@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_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/3] Xen pad paravirt interface
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 9b7dbe30e9d2a862a0931ee365e832bbd4d6c2e5 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 10 Feb 2012 20:34:46 +0800
Subject: [PATCH 2/3] Xen pad paravirt interface

Redirect paravirt template to Xen pv ops, preparing for Xen core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/xen/enlighten.c   |    6 ++++++
 drivers/xen/Makefile       |    1 +
 drivers/xen/xen_acpi_pad.c |    8 ++++++++
 include/xen/xen-ops.h      |    3 +++
 4 files changed, 18 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..5b4f209 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1023,6 +1023,11 @@ static const struct pv_cpu_ops xen_cpu_ops __initcon=
st =3D {
 	.end_context_switch =3D xen_end_context_switch,
 };
=20
+static const struct pv_pad_ops xen_pad_ops __initconst =3D {
+	.acpi_pad_init =3D xen_acpi_pad_init,
+	.acpi_pad_exit =3D xen_acpi_pad_exit,
+};
+
 static const struct pv_apic_ops xen_apic_ops __initconst =3D {
 #ifdef CONFIG_X86_LOCAL_APIC
 	.startup_ipi_hook =3D paravirt_nop,
@@ -1126,6 +1131,7 @@ asmlinkage void __init xen_start_kernel(void)
 	pv_init_ops =3D xen_init_ops;
 	pv_cpu_ops =3D xen_cpu_ops;
 	pv_apic_ops =3D xen_apic_ops;
+	pv_pad_ops =3D xen_pad_ops;
=20
 	x86_init.resources.memory_setup =3D xen_memory_setup;
 	x86_init.oem.arch_setup =3D xen_arch_setup;
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..c0268c9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
=20
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..63ab2fb
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,8 @@
+int xen_acpi_pad_init(void)
+{
+	return 0;
+}
+
+void xen_acpi_pad_exit(void)
+{
+}
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 03c85d7..eeb0d38 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -28,4 +28,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma=
,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
=20
+int xen_acpi_pad_init(void);
+void xen_acpi_pad_exit(void);
+
 #endif /* INCLUDE_XEN_OPS_H */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Xen-pad-paravirt-interface.patch"
Content-Description: 0002-Xen-pad-paravirt-interface.patch
Content-Disposition: attachment;
	filename="0002-Xen-pad-paravirt-interface.patch"; size=2549;
	creation-date="Fri, 17 Feb 2012 08:52:46 GMT";
	modification-date="Fri, 17 Feb 2012 16:49:16 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5YjdkYmUzMGU5ZDJhODYyYTA5MzFlZTM2NWU4MzJiYmQ0ZDZjMmU1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAxMCBGZWIgMjAxMiAyMDozNDo0NiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8z
XSBYZW4gcGFkIHBhcmF2aXJ0IGludGVyZmFjZQoKUmVkaXJlY3QgcGFyYXZpcnQgdGVtcGxhdGUg
dG8gWGVuIHB2IG9wcywgcHJlcGFyaW5nIGZvciBYZW4gY29yZSBwYXJraW5nLgoKU2lnbmVkLW9m
Zi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQogYXJjaC94ODYv
eGVuL2VubGlnaHRlbi5jICAgfCAgICA2ICsrKysrKwogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAg
ICAgfCAgICAxICsKIGRyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jIHwgICAgOCArKysrKysrKwog
aW5jbHVkZS94ZW4veGVuLW9wcy5oICAgICAgfCAgICAzICsrKwogNCBmaWxlcyBjaGFuZ2VkLCAx
OCBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZl
cnMveGVuL3hlbl9hY3BpX3BhZC5jCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRl
bi5jIGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCmluZGV4IDEyZWIwN2IuLjViNGYyMDkgMTAw
NjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYworKysgYi9hcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMKQEAgLTEwMjMsNiArMTAyMywxMSBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IHB2X2Nw
dV9vcHMgeGVuX2NwdV9vcHMgX19pbml0Y29uc3QgPSB7CiAJLmVuZF9jb250ZXh0X3N3aXRjaCA9
IHhlbl9lbmRfY29udGV4dF9zd2l0Y2gsCiB9OwogCitzdGF0aWMgY29uc3Qgc3RydWN0IHB2X3Bh
ZF9vcHMgeGVuX3BhZF9vcHMgX19pbml0Y29uc3QgPSB7CisJLmFjcGlfcGFkX2luaXQgPSB4ZW5f
YWNwaV9wYWRfaW5pdCwKKwkuYWNwaV9wYWRfZXhpdCA9IHhlbl9hY3BpX3BhZF9leGl0LAorfTsK
Kwogc3RhdGljIGNvbnN0IHN0cnVjdCBwdl9hcGljX29wcyB4ZW5fYXBpY19vcHMgX19pbml0Y29u
c3QgPSB7CiAjaWZkZWYgQ09ORklHX1g4Nl9MT0NBTF9BUElDCiAJLnN0YXJ0dXBfaXBpX2hvb2sg
PSBwYXJhdmlydF9ub3AsCkBAIC0xMTI2LDYgKzExMzEsNyBAQCBhc21saW5rYWdlIHZvaWQgX19p
bml0IHhlbl9zdGFydF9rZXJuZWwodm9pZCkKIAlwdl9pbml0X29wcyA9IHhlbl9pbml0X29wczsK
IAlwdl9jcHVfb3BzID0geGVuX2NwdV9vcHM7CiAJcHZfYXBpY19vcHMgPSB4ZW5fYXBpY19vcHM7
CisJcHZfcGFkX29wcyA9IHhlbl9wYWRfb3BzOwogCiAJeDg2X2luaXQucmVzb3VyY2VzLm1lbW9y
eV9zZXR1cCA9IHhlbl9tZW1vcnlfc2V0dXA7CiAJeDg2X2luaXQub2VtLmFyY2hfc2V0dXAgPSB4
ZW5fYXJjaF9zZXR1cDsKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVy
cy94ZW4vTWFrZWZpbGUKaW5kZXggYWEzMTMzNy4uYzAyNjhjOSAxMDA2NDQKLS0tIGEvZHJpdmVy
cy94ZW4vTWFrZWZpbGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIwLDcg
QEAgb2JqLSQoQ09ORklHX1NXSU9UTEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09O
RklHX1hFTl9ET00wKQkJCSs9IHBjaS5vCiBvYmotJChDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5E
KQkrPSB4ZW4tcGNpYmFjay8KIG9iai0kKENPTkZJR19YRU5fUFJJVkNNRCkJCSs9IHhlbi1wcml2
Y21kLm8KK29iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSB4ZW5fYWNwaV9wYWQubwogCiB4ZW4t
ZXZ0Y2huLXkJCQkJOj0gZXZ0Y2huLm8KIHhlbi1nbnRkZXYteQkJCQk6PSBnbnRkZXYubwpkaWZm
IC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMgYi9kcml2ZXJzL3hlbi94ZW5fYWNw
aV9wYWQuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi42M2FiMmZiCi0tLSAv
ZGV2L251bGwKKysrIGIvZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMKQEAgLTAsMCArMSw4IEBA
CitpbnQgeGVuX2FjcGlfcGFkX2luaXQodm9pZCkKK3sKKwlyZXR1cm4gMDsKK30KKwordm9pZCB4
ZW5fYWNwaV9wYWRfZXhpdCh2b2lkKQoreworfQpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4veGVu
LW9wcy5oIGIvaW5jbHVkZS94ZW4veGVuLW9wcy5oCmluZGV4IDAzYzg1ZDcuLmVlYjBkMzggMTAw
NjQ0Ci0tLSBhL2luY2x1ZGUveGVuL3hlbi1vcHMuaAorKysgYi9pbmNsdWRlL3hlbi94ZW4tb3Bz
LmgKQEAgLTI4LDQgKzI4LDcgQEAgaW50IHhlbl9yZW1hcF9kb21haW5fbWZuX3JhbmdlKHN0cnVj
dCB2bV9hcmVhX3N0cnVjdCAqdm1hLAogCQkJICAgICAgIHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQg
bnIsCiAJCQkgICAgICAgcGdwcm90X3QgcHJvdCwgdW5zaWduZWQgZG9taWQpOwogCitpbnQgeGVu
X2FjcGlfcGFkX2luaXQodm9pZCk7Cit2b2lkIHhlbl9hY3BpX3BhZF9leGl0KHZvaWQpOworCiAj
ZW5kaWYgLyogSU5DTFVERV9YRU5fT1BTX0ggKi8KLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D85ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08: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.xensource.com>)
	id 1RyJfO-000606-7k; Fri, 17 Feb 2012 08:59:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJfN-0005zK-7G
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:59:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329469177!14343581!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24198 invoked from network); 17 Feb 2012 08:59:38 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 08:59:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:59:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="118566289"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:59:30 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:58:39 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:58:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 3/3] Xen pad logic and notification
Thread-Index: AcztUlYS1HfHeb7nTGSKH/iUASruog==
Date: Fri, 17 Feb 2012 08:58:38 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D87E@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_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From fee39804d2634dfba7b369dc82dac19b57400f84 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Sat, 18 Feb 2012 00:46:29 +0800
Subject: [PATCH 3/3] Xen pad logic and notification

This patch implement Xen pad logic, and when getting pad device
notification, it hypercalls to Xen hypervisor for core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen_acpi_pad.c       |  189 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   14 +++
 2 files changed, 203 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
index 63ab2fb..ba66d51 100644
--- a/drivers/xen/xen_acpi_pad.c
+++ b/drivers/xen/xen_acpi_pad.c
@@ -1,8 +1,197 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong <jinsong.liu@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 f=
or
+ * more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
+#include <asm/xen/hypercall.h>
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS "xen_acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Xen Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+static DEFINE_MUTEX(xen_cpu_lock);
+
+static int xen_acpi_pad_idle_cpus(int *num_cpus)
+{
+	int ret;
+
+	struct xen_platform_op op =3D {
+		.cmd =3D XENPF_core_parking,
+		.interface_version =3D XENPF_INTERFACE_VERSION,
+	};
+
+	/* set cpu nums expected to be idled */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D (uint32_t)*num_cpus;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/*
+	 * get cpu nums actually be idled
+	 * cannot get it by using hypercall once (shared with _SET)
+	 * because of the characteristic of Xen continue_hypercall_on_cpu
+	 */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	*num_cpus =3D op.u.core_parking.idle_nums;
+	return 0;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int ret, num_cpus;
+
+	mutex_lock(&xen_cpu_lock);
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	ret =3D xen_acpi_pad_idle_cpus(&num_cpus);
+	if (ret) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device,
+	int type)
+{
+	int num_cpus =3D 0;
+
+	mutex_lock(&xen_cpu_lock);
+	xen_acpi_pad_idle_cpus(&num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+
+	acpi_remove_notify_handler(device->handle,
+		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
+	return 0;
+}
+
+static const struct acpi_device_id xen_pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "xen_processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D xen_pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+		.remove =3D xen_acpi_pad_remove,
+	},
+};
+
 int xen_acpi_pad_init(void)
 {
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	return acpi_bus_register_driver(&xen_acpi_pad_driver);
+#else
 	return 0;
+#endif
 }
=20
 void xen_acpi_pad_exit(void)
 {
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_bus_unregister_driver(&xen_acpi_pad_driver);
+#endif
 }
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..56ec72a 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_core_parking      60
+
+#define XEN_CORE_PARKING_SET    1
+#define XEN_CORE_PARKING_GET    2
+struct xenpf_core_parking {
+	/* IN variables */
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,6 +325,7 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0003-Xen-pad-logic-and-notification.patch"
Content-Description: 0003-Xen-pad-logic-and-notification.patch
Content-Disposition: attachment;
	filename="0003-Xen-pad-logic-and-notification.patch"; size=6797;
	creation-date="Fri, 17 Feb 2012 08:52:46 GMT";
	modification-date="Fri, 17 Feb 2012 16:49:16 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmZWUzOTgwNGQyNjM0ZGZiYTdiMzY5ZGM4MmRhYzE5YjU3NDAwZjg0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU2F0LCAxOCBGZWIgMjAxMiAwMDo0NjoyOSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy8z
XSBYZW4gcGFkIGxvZ2ljIGFuZCBub3RpZmljYXRpb24KClRoaXMgcGF0Y2ggaW1wbGVtZW50IFhl
biBwYWQgbG9naWMsIGFuZCB3aGVuIGdldHRpbmcgcGFkIGRldmljZQpub3RpZmljYXRpb24sIGl0
IGh5cGVyY2FsbHMgdG8gWGVuIGh5cGVydmlzb3IgZm9yIGNvcmUgcGFya2luZy4KClNpZ25lZC1v
ZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgotLS0KIGRyaXZlcnMv
eGVuL3hlbl9hY3BpX3BhZC5jICAgICAgIHwgIDE4OSArKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggfCAgIDE0ICsr
KwogMiBmaWxlcyBjaGFuZ2VkLCAyMDMgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKCmRp
ZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW5fYWNwaV9wYWQuYyBiL2RyaXZlcnMveGVuL3hlbl9h
Y3BpX3BhZC5jCmluZGV4IDYzYWIyZmIuLmJhNjZkNTEgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVu
L3hlbl9hY3BpX3BhZC5jCisrKyBiL2RyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jCkBAIC0xLDgg
KzEsMTk3IEBACisvKgorICogeGVuX2FjcGlfcGFkLmMgLSBYZW4gcGFkIGludGVyZmFjZQorICoK
KyAqIENvcHlyaWdodCAoYykgMjAxMiwgSW50ZWwgQ29ycG9yYXRpb24uCisgKiAgICBBdXRob3I6
IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
IGl0CisgKiB1bmRlciB0aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlLAorICogdmVyc2lvbiAyLCBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFO
VFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkg
b3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqLworCisjaW5jbHVk
ZSA8bGludXgva2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxh
Y3BpL2FjcGlfYnVzLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2RyaXZlcnMuaD4KKworI2luY2x1
ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisKKyNkZWZpbmUgQUNQSV9QUk9DRVNTT1JfQUdHUkVH
QVRPUl9DTEFTUyAieGVuX2FjcGlfcGFkIgorI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdB
VE9SX0RFVklDRV9OQU1FICJYZW4gUHJvY2Vzc29yIEFnZ3JlZ2F0b3IiCisjZGVmaW5lIEFDUElf
UFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZIDB4ODAKK3N0YXRpYyBERUZJTkVfTVVURVgoeGVu
X2NwdV9sb2NrKTsKKworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRfaWRsZV9jcHVzKGludCAqbnVt
X2NwdXMpCit7CisJaW50IHJldDsKKworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7CisJ
CS5jbWQgPSBYRU5QRl9jb3JlX3BhcmtpbmcsCisJCS5pbnRlcmZhY2VfdmVyc2lvbiA9IFhFTlBG
X0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwkvKiBzZXQgY3B1IG51bXMgZXhwZWN0ZWQgdG8g
YmUgaWRsZWQgKi8KKwlvcC51LmNvcmVfcGFya2luZy50eXBlID0gWEVOX0NPUkVfUEFSS0lOR19T
RVQ7CisJb3AudS5jb3JlX3BhcmtpbmcuaWRsZV9udW1zID0gKHVpbnQzMl90KSpudW1fY3B1czsK
KwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0KQorCQlyZXR1cm4gcmV0
OworCisJLyoKKwkgKiBnZXQgY3B1IG51bXMgYWN0dWFsbHkgYmUgaWRsZWQKKwkgKiBjYW5ub3Qg
Z2V0IGl0IGJ5IHVzaW5nIGh5cGVyY2FsbCBvbmNlIChzaGFyZWQgd2l0aCBfU0VUKQorCSAqIGJl
Y2F1c2Ugb2YgdGhlIGNoYXJhY3RlcmlzdGljIG9mIFhlbiBjb250aW51ZV9oeXBlcmNhbGxfb25f
Y3B1CisJICovCisJb3AudS5jb3JlX3BhcmtpbmcudHlwZSA9IFhFTl9DT1JFX1BBUktJTkdfR0VU
OworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOworCWlmIChyZXQpCisJCXJldHVybiBy
ZXQ7CisKKwkqbnVtX2NwdXMgPSBvcC51LmNvcmVfcGFya2luZy5pZGxlX251bXM7CisJcmV0dXJu
IDA7Cit9CisKKy8qCisgKiBRdWVyeSBmaXJtd2FyZSBob3cgbWFueSBDUFVzIHNob3VsZCBiZSBp
ZGxlCisgKiByZXR1cm4gLTEgb24gZmFpbHVyZQorICovCitzdGF0aWMgaW50IHhlbl9hY3BpX3Bh
ZF9wdXIoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXN0cnVjdCBhY3BpX2J1ZmZlciBidWZmZXIg
PSB7QUNQSV9BTExPQ0FURV9CVUZGRVIsIE5VTEx9OworCXVuaW9uIGFjcGlfb2JqZWN0ICpwYWNr
YWdlOworCWludCBudW0gPSAtMTsKKworCWlmIChBQ1BJX0ZBSUxVUkUoYWNwaV9ldmFsdWF0ZV9v
YmplY3QoaGFuZGxlLCAiX1BVUiIsIE5VTEwsICZidWZmZXIpKSkKKwkJcmV0dXJuIG51bTsKKwor
CWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIpCisJCXJldHVybiBudW07CisK
KwlwYWNrYWdlID0gYnVmZmVyLnBvaW50ZXI7CisKKwlpZiAocGFja2FnZS0+dHlwZSA9PSBBQ1BJ
X1RZUEVfUEFDS0FHRSAmJgorCQlwYWNrYWdlLT5wYWNrYWdlLmNvdW50ID09IDIgJiYKKwkJcGFj
a2FnZS0+cGFja2FnZS5lbGVtZW50c1swXS5pbnRlZ2VyLnZhbHVlID09IDEpIC8qIHJldiAxICov
CisKKwkJbnVtID0gcGFja2FnZS0+cGFja2FnZS5lbGVtZW50c1sxXS5pbnRlZ2VyLnZhbHVlOwor
CisJa2ZyZWUoYnVmZmVyLnBvaW50ZXIpOworCXJldHVybiBudW07Cit9CisKKy8qIE5vdGlmeSBm
aXJtd2FyZSBob3cgbWFueSBDUFVzIGFyZSBpZGxlICovCitzdGF0aWMgdm9pZCB4ZW5fYWNwaV9w
YWRfb3N0KGFjcGlfaGFuZGxlIGhhbmRsZSwgaW50IHN0YXQsCisJdWludDMyX3QgaWRsZV9jcHVz
KQoreworCXVuaW9uIGFjcGlfb2JqZWN0IHBhcmFtc1szXSA9IHsKKwkJey50eXBlID0gQUNQSV9U
WVBFX0lOVEVHRVIsfSwKKwkJey50eXBlID0gQUNQSV9UWVBFX0lOVEVHRVIsfSwKKwkJey50eXBl
ID0gQUNQSV9UWVBFX0JVRkZFUix9LAorCX07CisJc3RydWN0IGFjcGlfb2JqZWN0X2xpc3QgYXJn
X2xpc3QgPSB7MywgcGFyYW1zfTsKKworCXBhcmFtc1swXS5pbnRlZ2VyLnZhbHVlID0gQUNQSV9Q
Uk9DRVNTT1JfQUdHUkVHQVRPUl9OT1RJRlk7CisJcGFyYW1zWzFdLmludGVnZXIudmFsdWUgPSAg
c3RhdDsKKwlwYXJhbXNbMl0uYnVmZmVyLmxlbmd0aCA9IDQ7CisJcGFyYW1zWzJdLmJ1ZmZlci5w
b2ludGVyID0gKHZvaWQgKikmaWRsZV9jcHVzOworCWFjcGlfZXZhbHVhdGVfb2JqZWN0KGhhbmRs
ZSwgIl9PU1QiLCAmYXJnX2xpc3QsIE5VTEwpOworfQorCitzdGF0aWMgdm9pZCB4ZW5fYWNwaV9w
YWRfaGFuZGxlX25vdGlmeShhY3BpX2hhbmRsZSBoYW5kbGUpCit7CisJaW50IHJldCwgbnVtX2Nw
dXM7CisKKwltdXRleF9sb2NrKCZ4ZW5fY3B1X2xvY2spOworCW51bV9jcHVzID0geGVuX2FjcGlf
cGFkX3B1cihoYW5kbGUpOworCWlmIChudW1fY3B1cyA8IDApIHsKKwkJbXV0ZXhfdW5sb2NrKCZ4
ZW5fY3B1X2xvY2spOworCQlyZXR1cm47CisJfQorCisJcmV0ID0geGVuX2FjcGlfcGFkX2lkbGVf
Y3B1cygmbnVtX2NwdXMpOworCWlmIChyZXQpIHsKKwkJbXV0ZXhfdW5sb2NrKCZ4ZW5fY3B1X2xv
Y2spOworCQlyZXR1cm47CisJfQorCisJeGVuX2FjcGlfcGFkX29zdChoYW5kbGUsIDAsIG51bV9j
cHVzKTsKKwltdXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7Cit9CisKK3N0YXRpYyB2b2lkIHhl
bl9hY3BpX3BhZF9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZlbnQsCisJdm9pZCAq
ZGF0YSkKK3sKKwlzd2l0Y2ggKGV2ZW50KSB7CisJY2FzZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdB
VE9SX05PVElGWToKKwkJeGVuX2FjcGlfcGFkX2hhbmRsZV9ub3RpZnkoaGFuZGxlKTsKKwkJYnJl
YWs7CisJZGVmYXVsdDoKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAiVW5zdXBwb3J0ZWQgZXZlbnQg
WzB4JXhdXG4iLCBldmVudCk7CisJCWJyZWFrOworCX0KK30KKworc3RhdGljIGludCB4ZW5fYWNw
aV9wYWRfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCWFjcGlfc3RhdHVzIHN0
YXR1czsKKworCXN0cmNweShhY3BpX2RldmljZV9uYW1lKGRldmljZSksIEFDUElfUFJPQ0VTU09S
X0FHR1JFR0FUT1JfREVWSUNFX05BTUUpOworCXN0cmNweShhY3BpX2RldmljZV9jbGFzcyhkZXZp
Y2UpLCBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0NMQVNTKTsKKworCXN0YXR1cyA9IGFjcGlf
aW5zdGFsbF9ub3RpZnlfaGFuZGxlcihkZXZpY2UtPmhhbmRsZSwKKwkJIEFDUElfREVWSUNFX05P
VElGWSwgeGVuX2FjcGlfcGFkX25vdGlmeSwgZGV2aWNlKTsKKwlpZiAoQUNQSV9GQUlMVVJFKHN0
YXR1cykpCisJCXJldHVybiAtRU5PREVWOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQg
eGVuX2FjcGlfcGFkX3JlbW92ZShzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSwKKwlpbnQgdHlw
ZSkKK3sKKwlpbnQgbnVtX2NwdXMgPSAwOworCisJbXV0ZXhfbG9jaygmeGVuX2NwdV9sb2NrKTsK
Kwl4ZW5fYWNwaV9wYWRfaWRsZV9jcHVzKCZudW1fY3B1cyk7CisJbXV0ZXhfdW5sb2NrKCZ4ZW5f
Y3B1X2xvY2spOworCisJYWNwaV9yZW1vdmVfbm90aWZ5X2hhbmRsZXIoZGV2aWNlLT5oYW5kbGUs
CisJCUFDUElfREVWSUNFX05PVElGWSwgeGVuX2FjcGlfcGFkX25vdGlmeSk7CisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBjb25zdCBzdHJ1Y3QgYWNwaV9kZXZpY2VfaWQgeGVuX3BhZF9kZXZpY2Vf
aWRzW10gPSB7CisJeyJBQ1BJMDAwQyIsIDB9LAorCXsiIiwgMH0sCit9OworCitzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3BhZF9kcml2ZXIgPSB7CisJLm5hbWUgPSAieGVuX3By
b2Nlc3Nvcl9hZ2dyZWdhdG9yIiwKKwkuY2xhc3MgPSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9S
X0NMQVNTLAorCS5pZHMgPSB4ZW5fcGFkX2RldmljZV9pZHMsCisJLm9wcyA9IHsKKwkJLmFkZCA9
IHhlbl9hY3BpX3BhZF9hZGQsCisJCS5yZW1vdmUgPSB4ZW5fYWNwaV9wYWRfcmVtb3ZlLAorCX0s
Cit9OworCiBpbnQgeGVuX2FjcGlfcGFkX2luaXQodm9pZCkKIHsKKyNpZmRlZiBDT05GSUdfQUNQ
SV9QUk9DRVNTT1JfQUdHUkVHQVRPUgorCXJldHVybiBhY3BpX2J1c19yZWdpc3Rlcl9kcml2ZXIo
Jnhlbl9hY3BpX3BhZF9kcml2ZXIpOworI2Vsc2UKIAlyZXR1cm4gMDsKKyNlbmRpZgogfQogCiB2
b2lkIHhlbl9hY3BpX3BhZF9leGl0KHZvaWQpCiB7CisjaWZkZWYgQ09ORklHX0FDUElfUFJPQ0VT
U09SX0FHR1JFR0FUT1IKKwlhY3BpX2J1c191bnJlZ2lzdGVyX2RyaXZlcigmeGVuX2FjcGlfcGFk
X2RyaXZlcik7CisjZW5kaWYKIH0KZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9w
bGF0Zm9ybS5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggYzE2ODQ2
OC4uNTZlYzcyYSAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgK
KysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTI5Nyw2ICsyOTcsMTkg
QEAgc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZvIHsKIH07CiBERUZJTkVfR1VFU1Rf
SEFORExFX1NUUlVDVCh4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyk7CiAKKyNkZWZpbmUgWEVO
UEZfY29yZV9wYXJraW5nICAgICAgNjAKKworI2RlZmluZSBYRU5fQ09SRV9QQVJLSU5HX1NFVCAg
ICAxCisjZGVmaW5lIFhFTl9DT1JFX1BBUktJTkdfR0VUICAgIDIKK3N0cnVjdCB4ZW5wZl9jb3Jl
X3BhcmtpbmcgeworCS8qIElOIHZhcmlhYmxlcyAqLworCXVpbnQzMl90IHR5cGU7CisJLyogSU4g
dmFyaWFibGVzOiAgc2V0IGNwdSBudW1zIGV4cGVjdGVkIHRvIGJlIGlkbGVkICovCisJLyogT1VU
IHZhcmlhYmxlczogZ2V0IGNwdSBudW1zIGFjdHVhbGx5IGJlIGlkbGVkICovCisJdWludDMyX3Qg
aWRsZV9udW1zOworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbnBmX2NvcmVfcGFy
a2luZyk7CisKIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCXVpbnQzMl90IGNtZDsKIAl1aW50
MzJfdCBpbnRlcmZhY2VfdmVyc2lvbjsgLyogWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAg
LTMxMiw2ICszMjUsNyBAQCBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAkJc3RydWN0IHhlbnBm
X2NoYW5nZV9mcmVxICAgICAgIGNoYW5nZV9mcmVxOwogCQlzdHJ1Y3QgeGVucGZfZ2V0aWRsZXRp
bWUgICAgICAgZ2V0aWRsZXRpbWU7CiAJCXN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5m
byBzZXRfcG1pbmZvOworCQlzdHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nICAgICAgY29yZV9wYXJr
aW5nOwogCQl1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgcGFkWzEyOF07CiAJfSB1Owog
fTsKLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 08:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 08: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.xensource.com>)
	id 1RyJfO-000606-7k; Fri, 17 Feb 2012 08:59:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJfN-0005zK-7G
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:59:45 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329469177!14343581!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24198 invoked from network); 17 Feb 2012 08:59:38 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 08:59:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 00:59:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="scan'208,223";a="118566289"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 00:59:30 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:58:39 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:58:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: [PATCH 3/3] Xen pad logic and notification
Thread-Index: AcztUlYS1HfHeb7nTGSKH/iUASruog==
Date: Fri, 17 Feb 2012 08:58:38 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D87E@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_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From fee39804d2634dfba7b369dc82dac19b57400f84 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Sat, 18 Feb 2012 00:46:29 +0800
Subject: [PATCH 3/3] Xen pad logic and notification

This patch implement Xen pad logic, and when getting pad device
notification, it hypercalls to Xen hypervisor for core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen_acpi_pad.c       |  189 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   14 +++
 2 files changed, 203 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
index 63ab2fb..ba66d51 100644
--- a/drivers/xen/xen_acpi_pad.c
+++ b/drivers/xen/xen_acpi_pad.c
@@ -1,8 +1,197 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong <jinsong.liu@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 f=
or
+ * more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
+#include <asm/xen/hypercall.h>
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS "xen_acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Xen Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+static DEFINE_MUTEX(xen_cpu_lock);
+
+static int xen_acpi_pad_idle_cpus(int *num_cpus)
+{
+	int ret;
+
+	struct xen_platform_op op =3D {
+		.cmd =3D XENPF_core_parking,
+		.interface_version =3D XENPF_INTERFACE_VERSION,
+	};
+
+	/* set cpu nums expected to be idled */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D (uint32_t)*num_cpus;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/*
+	 * get cpu nums actually be idled
+	 * cannot get it by using hypercall once (shared with _SET)
+	 * because of the characteristic of Xen continue_hypercall_on_cpu
+	 */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	*num_cpus =3D op.u.core_parking.idle_nums;
+	return 0;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int ret, num_cpus;
+
+	mutex_lock(&xen_cpu_lock);
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	ret =3D xen_acpi_pad_idle_cpus(&num_cpus);
+	if (ret) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device,
+	int type)
+{
+	int num_cpus =3D 0;
+
+	mutex_lock(&xen_cpu_lock);
+	xen_acpi_pad_idle_cpus(&num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+
+	acpi_remove_notify_handler(device->handle,
+		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
+	return 0;
+}
+
+static const struct acpi_device_id xen_pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "xen_processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D xen_pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+		.remove =3D xen_acpi_pad_remove,
+	},
+};
+
 int xen_acpi_pad_init(void)
 {
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	return acpi_bus_register_driver(&xen_acpi_pad_driver);
+#else
 	return 0;
+#endif
 }
=20
 void xen_acpi_pad_exit(void)
 {
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_bus_unregister_driver(&xen_acpi_pad_driver);
+#endif
 }
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..56ec72a 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_core_parking      60
+
+#define XEN_CORE_PARKING_SET    1
+#define XEN_CORE_PARKING_GET    2
+struct xenpf_core_parking {
+	/* IN variables */
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,6 +325,7 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0003-Xen-pad-logic-and-notification.patch"
Content-Description: 0003-Xen-pad-logic-and-notification.patch
Content-Disposition: attachment;
	filename="0003-Xen-pad-logic-and-notification.patch"; size=6797;
	creation-date="Fri, 17 Feb 2012 08:52:46 GMT";
	modification-date="Fri, 17 Feb 2012 16:49:16 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmZWUzOTgwNGQyNjM0ZGZiYTdiMzY5ZGM4MmRhYzE5YjU3NDAwZjg0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU2F0LCAxOCBGZWIgMjAxMiAwMDo0NjoyOSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy8z
XSBYZW4gcGFkIGxvZ2ljIGFuZCBub3RpZmljYXRpb24KClRoaXMgcGF0Y2ggaW1wbGVtZW50IFhl
biBwYWQgbG9naWMsIGFuZCB3aGVuIGdldHRpbmcgcGFkIGRldmljZQpub3RpZmljYXRpb24sIGl0
IGh5cGVyY2FsbHMgdG8gWGVuIGh5cGVydmlzb3IgZm9yIGNvcmUgcGFya2luZy4KClNpZ25lZC1v
ZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgotLS0KIGRyaXZlcnMv
eGVuL3hlbl9hY3BpX3BhZC5jICAgICAgIHwgIDE4OSArKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggfCAgIDE0ICsr
KwogMiBmaWxlcyBjaGFuZ2VkLCAyMDMgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKCmRp
ZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW5fYWNwaV9wYWQuYyBiL2RyaXZlcnMveGVuL3hlbl9h
Y3BpX3BhZC5jCmluZGV4IDYzYWIyZmIuLmJhNjZkNTEgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVu
L3hlbl9hY3BpX3BhZC5jCisrKyBiL2RyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jCkBAIC0xLDgg
KzEsMTk3IEBACisvKgorICogeGVuX2FjcGlfcGFkLmMgLSBYZW4gcGFkIGludGVyZmFjZQorICoK
KyAqIENvcHlyaWdodCAoYykgMjAxMiwgSW50ZWwgQ29ycG9yYXRpb24uCisgKiAgICBBdXRob3I6
IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgorICoKKyAqIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
IGl0CisgKiB1bmRlciB0aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlLAorICogdmVyc2lvbiAyLCBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFO
VFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkg
b3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqLworCisjaW5jbHVk
ZSA8bGludXgva2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxh
Y3BpL2FjcGlfYnVzLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2RyaXZlcnMuaD4KKworI2luY2x1
ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisKKyNkZWZpbmUgQUNQSV9QUk9DRVNTT1JfQUdHUkVH
QVRPUl9DTEFTUyAieGVuX2FjcGlfcGFkIgorI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdB
VE9SX0RFVklDRV9OQU1FICJYZW4gUHJvY2Vzc29yIEFnZ3JlZ2F0b3IiCisjZGVmaW5lIEFDUElf
UFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZIDB4ODAKK3N0YXRpYyBERUZJTkVfTVVURVgoeGVu
X2NwdV9sb2NrKTsKKworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRfaWRsZV9jcHVzKGludCAqbnVt
X2NwdXMpCit7CisJaW50IHJldDsKKworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7CisJ
CS5jbWQgPSBYRU5QRl9jb3JlX3BhcmtpbmcsCisJCS5pbnRlcmZhY2VfdmVyc2lvbiA9IFhFTlBG
X0lOVEVSRkFDRV9WRVJTSU9OLAorCX07CisKKwkvKiBzZXQgY3B1IG51bXMgZXhwZWN0ZWQgdG8g
YmUgaWRsZWQgKi8KKwlvcC51LmNvcmVfcGFya2luZy50eXBlID0gWEVOX0NPUkVfUEFSS0lOR19T
RVQ7CisJb3AudS5jb3JlX3BhcmtpbmcuaWRsZV9udW1zID0gKHVpbnQzMl90KSpudW1fY3B1czsK
KwlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKwlpZiAocmV0KQorCQlyZXR1cm4gcmV0
OworCisJLyoKKwkgKiBnZXQgY3B1IG51bXMgYWN0dWFsbHkgYmUgaWRsZWQKKwkgKiBjYW5ub3Qg
Z2V0IGl0IGJ5IHVzaW5nIGh5cGVyY2FsbCBvbmNlIChzaGFyZWQgd2l0aCBfU0VUKQorCSAqIGJl
Y2F1c2Ugb2YgdGhlIGNoYXJhY3RlcmlzdGljIG9mIFhlbiBjb250aW51ZV9oeXBlcmNhbGxfb25f
Y3B1CisJICovCisJb3AudS5jb3JlX3BhcmtpbmcudHlwZSA9IFhFTl9DT1JFX1BBUktJTkdfR0VU
OworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOworCWlmIChyZXQpCisJCXJldHVybiBy
ZXQ7CisKKwkqbnVtX2NwdXMgPSBvcC51LmNvcmVfcGFya2luZy5pZGxlX251bXM7CisJcmV0dXJu
IDA7Cit9CisKKy8qCisgKiBRdWVyeSBmaXJtd2FyZSBob3cgbWFueSBDUFVzIHNob3VsZCBiZSBp
ZGxlCisgKiByZXR1cm4gLTEgb24gZmFpbHVyZQorICovCitzdGF0aWMgaW50IHhlbl9hY3BpX3Bh
ZF9wdXIoYWNwaV9oYW5kbGUgaGFuZGxlKQoreworCXN0cnVjdCBhY3BpX2J1ZmZlciBidWZmZXIg
PSB7QUNQSV9BTExPQ0FURV9CVUZGRVIsIE5VTEx9OworCXVuaW9uIGFjcGlfb2JqZWN0ICpwYWNr
YWdlOworCWludCBudW0gPSAtMTsKKworCWlmIChBQ1BJX0ZBSUxVUkUoYWNwaV9ldmFsdWF0ZV9v
YmplY3QoaGFuZGxlLCAiX1BVUiIsIE5VTEwsICZidWZmZXIpKSkKKwkJcmV0dXJuIG51bTsKKwor
CWlmICghYnVmZmVyLmxlbmd0aCB8fCAhYnVmZmVyLnBvaW50ZXIpCisJCXJldHVybiBudW07CisK
KwlwYWNrYWdlID0gYnVmZmVyLnBvaW50ZXI7CisKKwlpZiAocGFja2FnZS0+dHlwZSA9PSBBQ1BJ
X1RZUEVfUEFDS0FHRSAmJgorCQlwYWNrYWdlLT5wYWNrYWdlLmNvdW50ID09IDIgJiYKKwkJcGFj
a2FnZS0+cGFja2FnZS5lbGVtZW50c1swXS5pbnRlZ2VyLnZhbHVlID09IDEpIC8qIHJldiAxICov
CisKKwkJbnVtID0gcGFja2FnZS0+cGFja2FnZS5lbGVtZW50c1sxXS5pbnRlZ2VyLnZhbHVlOwor
CisJa2ZyZWUoYnVmZmVyLnBvaW50ZXIpOworCXJldHVybiBudW07Cit9CisKKy8qIE5vdGlmeSBm
aXJtd2FyZSBob3cgbWFueSBDUFVzIGFyZSBpZGxlICovCitzdGF0aWMgdm9pZCB4ZW5fYWNwaV9w
YWRfb3N0KGFjcGlfaGFuZGxlIGhhbmRsZSwgaW50IHN0YXQsCisJdWludDMyX3QgaWRsZV9jcHVz
KQoreworCXVuaW9uIGFjcGlfb2JqZWN0IHBhcmFtc1szXSA9IHsKKwkJey50eXBlID0gQUNQSV9U
WVBFX0lOVEVHRVIsfSwKKwkJey50eXBlID0gQUNQSV9UWVBFX0lOVEVHRVIsfSwKKwkJey50eXBl
ID0gQUNQSV9UWVBFX0JVRkZFUix9LAorCX07CisJc3RydWN0IGFjcGlfb2JqZWN0X2xpc3QgYXJn
X2xpc3QgPSB7MywgcGFyYW1zfTsKKworCXBhcmFtc1swXS5pbnRlZ2VyLnZhbHVlID0gQUNQSV9Q
Uk9DRVNTT1JfQUdHUkVHQVRPUl9OT1RJRlk7CisJcGFyYW1zWzFdLmludGVnZXIudmFsdWUgPSAg
c3RhdDsKKwlwYXJhbXNbMl0uYnVmZmVyLmxlbmd0aCA9IDQ7CisJcGFyYW1zWzJdLmJ1ZmZlci5w
b2ludGVyID0gKHZvaWQgKikmaWRsZV9jcHVzOworCWFjcGlfZXZhbHVhdGVfb2JqZWN0KGhhbmRs
ZSwgIl9PU1QiLCAmYXJnX2xpc3QsIE5VTEwpOworfQorCitzdGF0aWMgdm9pZCB4ZW5fYWNwaV9w
YWRfaGFuZGxlX25vdGlmeShhY3BpX2hhbmRsZSBoYW5kbGUpCit7CisJaW50IHJldCwgbnVtX2Nw
dXM7CisKKwltdXRleF9sb2NrKCZ4ZW5fY3B1X2xvY2spOworCW51bV9jcHVzID0geGVuX2FjcGlf
cGFkX3B1cihoYW5kbGUpOworCWlmIChudW1fY3B1cyA8IDApIHsKKwkJbXV0ZXhfdW5sb2NrKCZ4
ZW5fY3B1X2xvY2spOworCQlyZXR1cm47CisJfQorCisJcmV0ID0geGVuX2FjcGlfcGFkX2lkbGVf
Y3B1cygmbnVtX2NwdXMpOworCWlmIChyZXQpIHsKKwkJbXV0ZXhfdW5sb2NrKCZ4ZW5fY3B1X2xv
Y2spOworCQlyZXR1cm47CisJfQorCisJeGVuX2FjcGlfcGFkX29zdChoYW5kbGUsIDAsIG51bV9j
cHVzKTsKKwltdXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7Cit9CisKK3N0YXRpYyB2b2lkIHhl
bl9hY3BpX3BhZF9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZlbnQsCisJdm9pZCAq
ZGF0YSkKK3sKKwlzd2l0Y2ggKGV2ZW50KSB7CisJY2FzZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdB
VE9SX05PVElGWToKKwkJeGVuX2FjcGlfcGFkX2hhbmRsZV9ub3RpZnkoaGFuZGxlKTsKKwkJYnJl
YWs7CisJZGVmYXVsdDoKKwkJcHJpbnRrKEtFUk5fV0FSTklORyAiVW5zdXBwb3J0ZWQgZXZlbnQg
WzB4JXhdXG4iLCBldmVudCk7CisJCWJyZWFrOworCX0KK30KKworc3RhdGljIGludCB4ZW5fYWNw
aV9wYWRfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCWFjcGlfc3RhdHVzIHN0
YXR1czsKKworCXN0cmNweShhY3BpX2RldmljZV9uYW1lKGRldmljZSksIEFDUElfUFJPQ0VTU09S
X0FHR1JFR0FUT1JfREVWSUNFX05BTUUpOworCXN0cmNweShhY3BpX2RldmljZV9jbGFzcyhkZXZp
Y2UpLCBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0NMQVNTKTsKKworCXN0YXR1cyA9IGFjcGlf
aW5zdGFsbF9ub3RpZnlfaGFuZGxlcihkZXZpY2UtPmhhbmRsZSwKKwkJIEFDUElfREVWSUNFX05P
VElGWSwgeGVuX2FjcGlfcGFkX25vdGlmeSwgZGV2aWNlKTsKKwlpZiAoQUNQSV9GQUlMVVJFKHN0
YXR1cykpCisJCXJldHVybiAtRU5PREVWOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQg
eGVuX2FjcGlfcGFkX3JlbW92ZShzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSwKKwlpbnQgdHlw
ZSkKK3sKKwlpbnQgbnVtX2NwdXMgPSAwOworCisJbXV0ZXhfbG9jaygmeGVuX2NwdV9sb2NrKTsK
Kwl4ZW5fYWNwaV9wYWRfaWRsZV9jcHVzKCZudW1fY3B1cyk7CisJbXV0ZXhfdW5sb2NrKCZ4ZW5f
Y3B1X2xvY2spOworCisJYWNwaV9yZW1vdmVfbm90aWZ5X2hhbmRsZXIoZGV2aWNlLT5oYW5kbGUs
CisJCUFDUElfREVWSUNFX05PVElGWSwgeGVuX2FjcGlfcGFkX25vdGlmeSk7CisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBjb25zdCBzdHJ1Y3QgYWNwaV9kZXZpY2VfaWQgeGVuX3BhZF9kZXZpY2Vf
aWRzW10gPSB7CisJeyJBQ1BJMDAwQyIsIDB9LAorCXsiIiwgMH0sCit9OworCitzdGF0aWMgc3Ry
dWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3BhZF9kcml2ZXIgPSB7CisJLm5hbWUgPSAieGVuX3By
b2Nlc3Nvcl9hZ2dyZWdhdG9yIiwKKwkuY2xhc3MgPSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9S
X0NMQVNTLAorCS5pZHMgPSB4ZW5fcGFkX2RldmljZV9pZHMsCisJLm9wcyA9IHsKKwkJLmFkZCA9
IHhlbl9hY3BpX3BhZF9hZGQsCisJCS5yZW1vdmUgPSB4ZW5fYWNwaV9wYWRfcmVtb3ZlLAorCX0s
Cit9OworCiBpbnQgeGVuX2FjcGlfcGFkX2luaXQodm9pZCkKIHsKKyNpZmRlZiBDT05GSUdfQUNQ
SV9QUk9DRVNTT1JfQUdHUkVHQVRPUgorCXJldHVybiBhY3BpX2J1c19yZWdpc3Rlcl9kcml2ZXIo
Jnhlbl9hY3BpX3BhZF9kcml2ZXIpOworI2Vsc2UKIAlyZXR1cm4gMDsKKyNlbmRpZgogfQogCiB2
b2lkIHhlbl9hY3BpX3BhZF9leGl0KHZvaWQpCiB7CisjaWZkZWYgQ09ORklHX0FDUElfUFJPQ0VT
U09SX0FHR1JFR0FUT1IKKwlhY3BpX2J1c191bnJlZ2lzdGVyX2RyaXZlcigmeGVuX2FjcGlfcGFk
X2RyaXZlcik7CisjZW5kaWYKIH0KZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9w
bGF0Zm9ybS5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggYzE2ODQ2
OC4uNTZlYzcyYSAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgK
KysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTI5Nyw2ICsyOTcsMTkg
QEAgc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZvIHsKIH07CiBERUZJTkVfR1VFU1Rf
SEFORExFX1NUUlVDVCh4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5mbyk7CiAKKyNkZWZpbmUgWEVO
UEZfY29yZV9wYXJraW5nICAgICAgNjAKKworI2RlZmluZSBYRU5fQ09SRV9QQVJLSU5HX1NFVCAg
ICAxCisjZGVmaW5lIFhFTl9DT1JFX1BBUktJTkdfR0VUICAgIDIKK3N0cnVjdCB4ZW5wZl9jb3Jl
X3BhcmtpbmcgeworCS8qIElOIHZhcmlhYmxlcyAqLworCXVpbnQzMl90IHR5cGU7CisJLyogSU4g
dmFyaWFibGVzOiAgc2V0IGNwdSBudW1zIGV4cGVjdGVkIHRvIGJlIGlkbGVkICovCisJLyogT1VU
IHZhcmlhYmxlczogZ2V0IGNwdSBudW1zIGFjdHVhbGx5IGJlIGlkbGVkICovCisJdWludDMyX3Qg
aWRsZV9udW1zOworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbnBmX2NvcmVfcGFy
a2luZyk7CisKIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCXVpbnQzMl90IGNtZDsKIAl1aW50
MzJfdCBpbnRlcmZhY2VfdmVyc2lvbjsgLyogWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAg
LTMxMiw2ICszMjUsNyBAQCBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAkJc3RydWN0IHhlbnBm
X2NoYW5nZV9mcmVxICAgICAgIGNoYW5nZV9mcmVxOwogCQlzdHJ1Y3QgeGVucGZfZ2V0aWRsZXRp
bWUgICAgICAgZ2V0aWRsZXRpbWU7CiAJCXN0cnVjdCB4ZW5wZl9zZXRfcHJvY2Vzc29yX3BtaW5m
byBzZXRfcG1pbmZvOworCQlzdHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nICAgICAgY29yZV9wYXJr
aW5nOwogCQl1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgcGFkWzEyOF07CiAJfSB1Owog
fTsKLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D87ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09: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.xensource.com>)
	id 1RyJgP-0006Ci-Rg; Fri, 17 Feb 2012 09:00:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJgO-0006CM-7K
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:00:48 +0000
Received: from [85.158.139.83:23246] by server-11.bemta-5.messagelabs.com id
	8D/76-14397-F371E3F4; Fri, 17 Feb 2012 09:00:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329469245!8122855!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1479 invoked from network); 17 Feb 2012 09:00:46 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 09:00:46 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 01:00:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126616123"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2012 01:00:44 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:59:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:59:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Kernel development list
	<linux-kernel@vger.kernel.org>
Thread-Topic: [Patch 1/2] Xen core parking 1: hypercall
Thread-Index: AcztUoOfr+N2rwJJRvakui4rZ0L2nQ==
Date: Fri, 17 Feb 2012 08:59:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D8A4@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_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [Patch 1/2] Xen core parking 1: hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen core parking 1: hypercall

This patch implement hypercall through which dom0 send core parking request=
, and get core parking result.
Due to the characteristic of continue_hypercall_on_cpu, dom0 seperately sen=
d/get core parking request/result.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 92e03310878f xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/arch/x86/platform_hypercall.c	Mon Feb 13 11:33:16 2012 +0800
@@ -56,6 +56,10 @@
 long cpu_up_helper(void *data);
 long cpu_down_helper(void *data);
=20
+/* from core_parking.c */
+long core_parking_helper(void *data);
+uint32_t get_cur_idle_nums(void);
+
 ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
 {
     ret_t ret =3D 0;
@@ -593,6 +597,32 @@
                       op->u.mem_add.epfn,
                       op->u.mem_add.pxm);
         break;
+
+    case XENPF_core_parking:
+    {
+        uint32_t idle_nums;
+
+        switch(op->u.core_parking.type)
+        {
+        case XEN_CORE_PARKING_SET:
+            idle_nums =3D min_t(uint32_t,
+                    op->u.core_parking.idle_nums, num_present_cpus() - 1);
+            ret =3D continue_hypercall_on_cpu(
+                    0, core_parking_helper, (void *)(unsigned long)idle_nu=
ms);
+            break;
+
+        case XEN_CORE_PARKING_GET:
+            op->u.core_parking.idle_nums =3D get_cur_idle_nums();
+            ret =3D copy_to_guest(u_xenpf_op, op, 1) ? -EFAULT : 0;
+            break;
+
+        default:
+            ret =3D -EINVAL;
+            break;
+        }
+    }
+    break;
+
     default:
         ret =3D -ENOSYS;
         break;
diff -r 92e03310878f xen/common/Makefile
--- a/xen/common/Makefile	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/common/Makefile	Mon Feb 13 11:33:16 2012 +0800
@@ -1,6 +1,7 @@
 obj-y +=3D bitmap.o
 obj-y +=3D cpu.o
 obj-y +=3D cpupool.o
+obj-y +=3D core_parking.o
 obj-y +=3D domctl.o
 obj-y +=3D domain.o
 obj-y +=3D event_channel.o
diff -r 92e03310878f xen/common/core_parking.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/common/core_parking.c	Mon Feb 13 11:33:16 2012 +0800
@@ -0,0 +1,13 @@
+#include <xen/types.h>
+
+static uint32_t cur_idle_nums;
+
+long core_parking_helper(void *data)
+{
+    return 0;
+}
+
+uint32_t get_cur_idle_nums(void)
+{
+    return cur_idle_nums;
+}
diff -r 92e03310878f xen/include/public/platform.h
--- a/xen/include/public/platform.h	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/include/public/platform.h	Mon Feb 13 11:33:16 2012 +0800
@@ -490,6 +490,20 @@
     uint32_t flags;
 };
=20
+#define XENPF_core_parking  60
+
+#define XEN_CORE_PARKING_SET 1
+#define XEN_CORE_PARKING_GET 2
+struct xenpf_core_parking {
+    /* IN variables */
+    uint32_t type;
+    /* IN variables:  set cpu nums expected to be idled */
+    /* OUT variables: get cpu nums actually be idled */
+    uint32_t idle_nums;
+};
+typedef struct xenpf_core_parking xenpf_core_parking_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_core_parking_t);
+
 struct xen_platform_op {
     uint32_t cmd;
     uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -511,6 +525,7 @@
         struct xenpf_cpu_ol            cpu_ol;
         struct xenpf_cpu_hotadd        cpu_add;
         struct xenpf_mem_hotadd        mem_add;
+        struct xenpf_core_parking      core_parking;
         uint8_t                        pad[128];
     } u;
 };=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_1.patch"
Content-Description: xen_core_parking_1.patch
Content-Disposition: attachment; filename="xen_core_parking_1.patch";
	size=3395; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Mon, 13 Feb 2012 16:41:16 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAxOiBoeXBlcmNhbGwKClRoaXMgcGF0Y2ggaW1wbGVtZW50IGh5cGVy
Y2FsbCB0aHJvdWdoIHdoaWNoIGRvbTAgc2VuZCBjb3JlIHBhcmtpbmcgcmVxdWVzdCwgYW5kIGdl
dCBjb3JlIHBhcmtpbmcgcmVzdWx0LgpEdWUgdG8gdGhlIGNoYXJhY3RlcmlzdGljIG9mIGNvbnRp
bnVlX2h5cGVyY2FsbF9vbl9jcHUsIGRvbTAgc2VwZXJhdGVseSBzZW5kL2dldCBjb3JlIHBhcmtp
bmcgcmVxdWVzdC9yZXN1bHQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcu
bGl1QGludGVsLmNvbT4KCmRpZmYgLXIgOTJlMDMzMTA4NzhmIHhlbi9hcmNoL3g4Ni9wbGF0Zm9y
bV9oeXBlcmNhbGwuYwotLS0gYS94ZW4vYXJjaC94ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMJV2Vk
IEZlYiAwOCAyMTowNTo1MiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9o
eXBlcmNhbGwuYwlNb24gRmViIDEzIDExOjMzOjE2IDIwMTIgKzA4MDAKQEAgLTU2LDYgKzU2LDEw
IEBACiBsb25nIGNwdV91cF9oZWxwZXIodm9pZCAqZGF0YSk7CiBsb25nIGNwdV9kb3duX2hlbHBl
cih2b2lkICpkYXRhKTsKIAorLyogZnJvbSBjb3JlX3BhcmtpbmcuYyAqLworbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpOwordWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9p
ZCk7CisKIHJldF90IGRvX3BsYXRmb3JtX29wKFhFTl9HVUVTVF9IQU5ETEUoeGVuX3BsYXRmb3Jt
X29wX3QpIHVfeGVucGZfb3ApCiB7CiAgICAgcmV0X3QgcmV0ID0gMDsKQEAgLTU5Myw2ICs1OTcs
MzIgQEAKICAgICAgICAgICAgICAgICAgICAgICBvcC0+dS5tZW1fYWRkLmVwZm4sCiAgICAgICAg
ICAgICAgICAgICAgICAgb3AtPnUubWVtX2FkZC5weG0pOwogICAgICAgICBicmVhazsKKworICAg
IGNhc2UgWEVOUEZfY29yZV9wYXJraW5nOgorICAgIHsKKyAgICAgICAgdWludDMyX3QgaWRsZV9u
dW1zOworCisgICAgICAgIHN3aXRjaChvcC0+dS5jb3JlX3BhcmtpbmcudHlwZSkKKyAgICAgICAg
eworICAgICAgICBjYXNlIFhFTl9DT1JFX1BBUktJTkdfU0VUOgorICAgICAgICAgICAgaWRsZV9u
dW1zID0gbWluX3QodWludDMyX3QsCisgICAgICAgICAgICAgICAgICAgIG9wLT51LmNvcmVfcGFy
a2luZy5pZGxlX251bXMsIG51bV9wcmVzZW50X2NwdXMoKSAtIDEpOworICAgICAgICAgICAgcmV0
ID0gY29udGludWVfaHlwZXJjYWxsX29uX2NwdSgKKyAgICAgICAgICAgICAgICAgICAgMCwgY29y
ZV9wYXJraW5nX2hlbHBlciwgKHZvaWQgKikodW5zaWduZWQgbG9uZylpZGxlX251bXMpOworICAg
ICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgY2FzZSBYRU5fQ09SRV9QQVJLSU5HX0dFVDoKKyAg
ICAgICAgICAgIG9wLT51LmNvcmVfcGFya2luZy5pZGxlX251bXMgPSBnZXRfY3VyX2lkbGVfbnVt
cygpOworICAgICAgICAgICAgcmV0ID0gY29weV90b19ndWVzdCh1X3hlbnBmX29wLCBvcCwgMSkg
PyAtRUZBVUxUIDogMDsKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIGRlZmF1bHQ6Cisg
ICAgICAgICAgICByZXQgPSAtRUlOVkFMOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIH0K
KyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSAtRU5PU1lT
OwogICAgICAgICBicmVhazsKZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9NYWtlZmls
ZQotLS0gYS94ZW4vY29tbW9uL01ha2VmaWxlCVdlZCBGZWIgMDggMjE6MDU6NTIgMjAxMiArMDgw
MAorKysgYi94ZW4vY29tbW9uL01ha2VmaWxlCU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgw
MApAQCAtMSw2ICsxLDcgQEAKIG9iai15ICs9IGJpdG1hcC5vCiBvYmoteSArPSBjcHUubwogb2Jq
LXkgKz0gY3B1cG9vbC5vCitvYmoteSArPSBjb3JlX3Bhcmtpbmcubwogb2JqLXkgKz0gZG9tY3Rs
Lm8KIG9iai15ICs9IGRvbWFpbi5vCiBvYmoteSArPSBldmVudF9jaGFubmVsLm8KZGlmZiAtciA5
MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5j
CU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtMCwwICsxLDEzIEBACisjaW5jbHVk
ZSA8eGVuL3R5cGVzLmg+CisKK3N0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOworCitsb25n
IGNvcmVfcGFya2luZ19oZWxwZXIodm9pZCAqZGF0YSkKK3sKKyAgICByZXR1cm4gMDsKK30KKwor
dWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9pZCkKK3sKKyAgICByZXR1cm4gY3VyX2lkbGVf
bnVtczsKK30KZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3Jt
LmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3JtLmgJV2VkIEZlYiAwOCAyMTowNTo1
MiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9wbGF0Zm9ybS5oCU1vbiBGZWIg
MTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtNDkwLDYgKzQ5MCwyMCBAQAogICAgIHVpbnQzMl90
IGZsYWdzOwogfTsKIAorI2RlZmluZSBYRU5QRl9jb3JlX3BhcmtpbmcgIDYwCisKKyNkZWZpbmUg
WEVOX0NPUkVfUEFSS0lOR19TRVQgMQorI2RlZmluZSBYRU5fQ09SRV9QQVJLSU5HX0dFVCAyCitz
dHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nIHsKKyAgICAvKiBJTiB2YXJpYWJsZXMgKi8KKyAgICB1
aW50MzJfdCB0eXBlOworICAgIC8qIElOIHZhcmlhYmxlczogIHNldCBjcHUgbnVtcyBleHBlY3Rl
ZCB0byBiZSBpZGxlZCAqLworICAgIC8qIE9VVCB2YXJpYWJsZXM6IGdldCBjcHUgbnVtcyBhY3R1
YWxseSBiZSBpZGxlZCAqLworICAgIHVpbnQzMl90IGlkbGVfbnVtczsKK307Cit0eXBlZGVmIHN0
cnVjdCB4ZW5wZl9jb3JlX3BhcmtpbmcgeGVucGZfY29yZV9wYXJraW5nX3Q7CitERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5wZl9jb3JlX3BhcmtpbmdfdCk7CisKIHN0cnVjdCB4ZW5fcGxhdGZv
cm1fb3AgewogICAgIHVpbnQzMl90IGNtZDsKICAgICB1aW50MzJfdCBpbnRlcmZhY2VfdmVyc2lv
bjsgLyogWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAgLTUxMSw2ICs1MjUsNyBAQAogICAg
ICAgICBzdHJ1Y3QgeGVucGZfY3B1X29sICAgICAgICAgICAgY3B1X29sOwogICAgICAgICBzdHJ1
Y3QgeGVucGZfY3B1X2hvdGFkZCAgICAgICAgY3B1X2FkZDsKICAgICAgICAgc3RydWN0IHhlbnBm
X21lbV9ob3RhZGQgICAgICAgIG1lbV9hZGQ7CisgICAgICAgIHN0cnVjdCB4ZW5wZl9jb3JlX3Bh
cmtpbmcgICAgICBjb3JlX3Bhcmtpbmc7CiAgICAgICAgIHVpbnQ4X3QgICAgICAgICAgICAgICAg
ICAgICAgICBwYWRbMTI4XTsKICAgICB9IHU7CiB9Owo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09: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.xensource.com>)
	id 1RyJgP-0006Ci-Rg; Fri, 17 Feb 2012 09:00:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJgO-0006CM-7K
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:00:48 +0000
Received: from [85.158.139.83:23246] by server-11.bemta-5.messagelabs.com id
	8D/76-14397-F371E3F4; Fri, 17 Feb 2012 09:00:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329469245!8122855!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1479 invoked from network); 17 Feb 2012 09:00:46 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 09:00:46 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 01:00:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126616123"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2012 01:00:44 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 16:59:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 16:59:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Kernel development list
	<linux-kernel@vger.kernel.org>
Thread-Topic: [Patch 1/2] Xen core parking 1: hypercall
Thread-Index: AcztUoOfr+N2rwJJRvakui4rZ0L2nQ==
Date: Fri, 17 Feb 2012 08:59:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D8A4@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_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [Patch 1/2] Xen core parking 1: hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen core parking 1: hypercall

This patch implement hypercall through which dom0 send core parking request=
, and get core parking result.
Due to the characteristic of continue_hypercall_on_cpu, dom0 seperately sen=
d/get core parking request/result.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 92e03310878f xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/arch/x86/platform_hypercall.c	Mon Feb 13 11:33:16 2012 +0800
@@ -56,6 +56,10 @@
 long cpu_up_helper(void *data);
 long cpu_down_helper(void *data);
=20
+/* from core_parking.c */
+long core_parking_helper(void *data);
+uint32_t get_cur_idle_nums(void);
+
 ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
 {
     ret_t ret =3D 0;
@@ -593,6 +597,32 @@
                       op->u.mem_add.epfn,
                       op->u.mem_add.pxm);
         break;
+
+    case XENPF_core_parking:
+    {
+        uint32_t idle_nums;
+
+        switch(op->u.core_parking.type)
+        {
+        case XEN_CORE_PARKING_SET:
+            idle_nums =3D min_t(uint32_t,
+                    op->u.core_parking.idle_nums, num_present_cpus() - 1);
+            ret =3D continue_hypercall_on_cpu(
+                    0, core_parking_helper, (void *)(unsigned long)idle_nu=
ms);
+            break;
+
+        case XEN_CORE_PARKING_GET:
+            op->u.core_parking.idle_nums =3D get_cur_idle_nums();
+            ret =3D copy_to_guest(u_xenpf_op, op, 1) ? -EFAULT : 0;
+            break;
+
+        default:
+            ret =3D -EINVAL;
+            break;
+        }
+    }
+    break;
+
     default:
         ret =3D -ENOSYS;
         break;
diff -r 92e03310878f xen/common/Makefile
--- a/xen/common/Makefile	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/common/Makefile	Mon Feb 13 11:33:16 2012 +0800
@@ -1,6 +1,7 @@
 obj-y +=3D bitmap.o
 obj-y +=3D cpu.o
 obj-y +=3D cpupool.o
+obj-y +=3D core_parking.o
 obj-y +=3D domctl.o
 obj-y +=3D domain.o
 obj-y +=3D event_channel.o
diff -r 92e03310878f xen/common/core_parking.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/common/core_parking.c	Mon Feb 13 11:33:16 2012 +0800
@@ -0,0 +1,13 @@
+#include <xen/types.h>
+
+static uint32_t cur_idle_nums;
+
+long core_parking_helper(void *data)
+{
+    return 0;
+}
+
+uint32_t get_cur_idle_nums(void)
+{
+    return cur_idle_nums;
+}
diff -r 92e03310878f xen/include/public/platform.h
--- a/xen/include/public/platform.h	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/include/public/platform.h	Mon Feb 13 11:33:16 2012 +0800
@@ -490,6 +490,20 @@
     uint32_t flags;
 };
=20
+#define XENPF_core_parking  60
+
+#define XEN_CORE_PARKING_SET 1
+#define XEN_CORE_PARKING_GET 2
+struct xenpf_core_parking {
+    /* IN variables */
+    uint32_t type;
+    /* IN variables:  set cpu nums expected to be idled */
+    /* OUT variables: get cpu nums actually be idled */
+    uint32_t idle_nums;
+};
+typedef struct xenpf_core_parking xenpf_core_parking_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_core_parking_t);
+
 struct xen_platform_op {
     uint32_t cmd;
     uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -511,6 +525,7 @@
         struct xenpf_cpu_ol            cpu_ol;
         struct xenpf_cpu_hotadd        cpu_add;
         struct xenpf_mem_hotadd        mem_add;
+        struct xenpf_core_parking      core_parking;
         uint8_t                        pad[128];
     } u;
 };=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_1.patch"
Content-Description: xen_core_parking_1.patch
Content-Disposition: attachment; filename="xen_core_parking_1.patch";
	size=3395; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Mon, 13 Feb 2012 16:41:16 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAxOiBoeXBlcmNhbGwKClRoaXMgcGF0Y2ggaW1wbGVtZW50IGh5cGVy
Y2FsbCB0aHJvdWdoIHdoaWNoIGRvbTAgc2VuZCBjb3JlIHBhcmtpbmcgcmVxdWVzdCwgYW5kIGdl
dCBjb3JlIHBhcmtpbmcgcmVzdWx0LgpEdWUgdG8gdGhlIGNoYXJhY3RlcmlzdGljIG9mIGNvbnRp
bnVlX2h5cGVyY2FsbF9vbl9jcHUsIGRvbTAgc2VwZXJhdGVseSBzZW5kL2dldCBjb3JlIHBhcmtp
bmcgcmVxdWVzdC9yZXN1bHQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcu
bGl1QGludGVsLmNvbT4KCmRpZmYgLXIgOTJlMDMzMTA4NzhmIHhlbi9hcmNoL3g4Ni9wbGF0Zm9y
bV9oeXBlcmNhbGwuYwotLS0gYS94ZW4vYXJjaC94ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMJV2Vk
IEZlYiAwOCAyMTowNTo1MiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9o
eXBlcmNhbGwuYwlNb24gRmViIDEzIDExOjMzOjE2IDIwMTIgKzA4MDAKQEAgLTU2LDYgKzU2LDEw
IEBACiBsb25nIGNwdV91cF9oZWxwZXIodm9pZCAqZGF0YSk7CiBsb25nIGNwdV9kb3duX2hlbHBl
cih2b2lkICpkYXRhKTsKIAorLyogZnJvbSBjb3JlX3BhcmtpbmcuYyAqLworbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpOwordWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9p
ZCk7CisKIHJldF90IGRvX3BsYXRmb3JtX29wKFhFTl9HVUVTVF9IQU5ETEUoeGVuX3BsYXRmb3Jt
X29wX3QpIHVfeGVucGZfb3ApCiB7CiAgICAgcmV0X3QgcmV0ID0gMDsKQEAgLTU5Myw2ICs1OTcs
MzIgQEAKICAgICAgICAgICAgICAgICAgICAgICBvcC0+dS5tZW1fYWRkLmVwZm4sCiAgICAgICAg
ICAgICAgICAgICAgICAgb3AtPnUubWVtX2FkZC5weG0pOwogICAgICAgICBicmVhazsKKworICAg
IGNhc2UgWEVOUEZfY29yZV9wYXJraW5nOgorICAgIHsKKyAgICAgICAgdWludDMyX3QgaWRsZV9u
dW1zOworCisgICAgICAgIHN3aXRjaChvcC0+dS5jb3JlX3BhcmtpbmcudHlwZSkKKyAgICAgICAg
eworICAgICAgICBjYXNlIFhFTl9DT1JFX1BBUktJTkdfU0VUOgorICAgICAgICAgICAgaWRsZV9u
dW1zID0gbWluX3QodWludDMyX3QsCisgICAgICAgICAgICAgICAgICAgIG9wLT51LmNvcmVfcGFy
a2luZy5pZGxlX251bXMsIG51bV9wcmVzZW50X2NwdXMoKSAtIDEpOworICAgICAgICAgICAgcmV0
ID0gY29udGludWVfaHlwZXJjYWxsX29uX2NwdSgKKyAgICAgICAgICAgICAgICAgICAgMCwgY29y
ZV9wYXJraW5nX2hlbHBlciwgKHZvaWQgKikodW5zaWduZWQgbG9uZylpZGxlX251bXMpOworICAg
ICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgY2FzZSBYRU5fQ09SRV9QQVJLSU5HX0dFVDoKKyAg
ICAgICAgICAgIG9wLT51LmNvcmVfcGFya2luZy5pZGxlX251bXMgPSBnZXRfY3VyX2lkbGVfbnVt
cygpOworICAgICAgICAgICAgcmV0ID0gY29weV90b19ndWVzdCh1X3hlbnBmX29wLCBvcCwgMSkg
PyAtRUZBVUxUIDogMDsKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIGRlZmF1bHQ6Cisg
ICAgICAgICAgICByZXQgPSAtRUlOVkFMOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIH0K
KyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSAtRU5PU1lT
OwogICAgICAgICBicmVhazsKZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9NYWtlZmls
ZQotLS0gYS94ZW4vY29tbW9uL01ha2VmaWxlCVdlZCBGZWIgMDggMjE6MDU6NTIgMjAxMiArMDgw
MAorKysgYi94ZW4vY29tbW9uL01ha2VmaWxlCU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgw
MApAQCAtMSw2ICsxLDcgQEAKIG9iai15ICs9IGJpdG1hcC5vCiBvYmoteSArPSBjcHUubwogb2Jq
LXkgKz0gY3B1cG9vbC5vCitvYmoteSArPSBjb3JlX3Bhcmtpbmcubwogb2JqLXkgKz0gZG9tY3Rs
Lm8KIG9iai15ICs9IGRvbWFpbi5vCiBvYmoteSArPSBldmVudF9jaGFubmVsLm8KZGlmZiAtciA5
MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5j
CU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtMCwwICsxLDEzIEBACisjaW5jbHVk
ZSA8eGVuL3R5cGVzLmg+CisKK3N0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOworCitsb25n
IGNvcmVfcGFya2luZ19oZWxwZXIodm9pZCAqZGF0YSkKK3sKKyAgICByZXR1cm4gMDsKK30KKwor
dWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9pZCkKK3sKKyAgICByZXR1cm4gY3VyX2lkbGVf
bnVtczsKK30KZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3Jt
LmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3JtLmgJV2VkIEZlYiAwOCAyMTowNTo1
MiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9wbGF0Zm9ybS5oCU1vbiBGZWIg
MTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtNDkwLDYgKzQ5MCwyMCBAQAogICAgIHVpbnQzMl90
IGZsYWdzOwogfTsKIAorI2RlZmluZSBYRU5QRl9jb3JlX3BhcmtpbmcgIDYwCisKKyNkZWZpbmUg
WEVOX0NPUkVfUEFSS0lOR19TRVQgMQorI2RlZmluZSBYRU5fQ09SRV9QQVJLSU5HX0dFVCAyCitz
dHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nIHsKKyAgICAvKiBJTiB2YXJpYWJsZXMgKi8KKyAgICB1
aW50MzJfdCB0eXBlOworICAgIC8qIElOIHZhcmlhYmxlczogIHNldCBjcHUgbnVtcyBleHBlY3Rl
ZCB0byBiZSBpZGxlZCAqLworICAgIC8qIE9VVCB2YXJpYWJsZXM6IGdldCBjcHUgbnVtcyBhY3R1
YWxseSBiZSBpZGxlZCAqLworICAgIHVpbnQzMl90IGlkbGVfbnVtczsKK307Cit0eXBlZGVmIHN0
cnVjdCB4ZW5wZl9jb3JlX3BhcmtpbmcgeGVucGZfY29yZV9wYXJraW5nX3Q7CitERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5wZl9jb3JlX3BhcmtpbmdfdCk7CisKIHN0cnVjdCB4ZW5fcGxhdGZv
cm1fb3AgewogICAgIHVpbnQzMl90IGNtZDsKICAgICB1aW50MzJfdCBpbnRlcmZhY2VfdmVyc2lv
bjsgLyogWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAgLTUxMSw2ICs1MjUsNyBAQAogICAg
ICAgICBzdHJ1Y3QgeGVucGZfY3B1X29sICAgICAgICAgICAgY3B1X29sOwogICAgICAgICBzdHJ1
Y3QgeGVucGZfY3B1X2hvdGFkZCAgICAgICAgY3B1X2FkZDsKICAgICAgICAgc3RydWN0IHhlbnBm
X21lbV9ob3RhZGQgICAgICAgIG1lbV9hZGQ7CisgICAgICAgIHN0cnVjdCB4ZW5wZl9jb3JlX3Bh
cmtpbmcgICAgICBjb3JlX3Bhcmtpbmc7CiAgICAgICAgIHVpbnQ4X3QgICAgICAgICAgICAgICAg
ICAgICAgICBwYWRbMTI4XTsKICAgICB9IHU7CiB9Owo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D8A4SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJic-0006We-KZ; Fri, 17 Feb 2012 09:03:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJia-0006Vq-Oi
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:03:05 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329469376!11904085!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6356 invoked from network); 17 Feb 2012 09:02:57 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 09:02:57 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 01:02:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118567380"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 01:02:54 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 17:01:18 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 17:01:16 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Kernel development list
	<linux-kernel@vger.kernel.org>
Thread-Topic: [Patch 2/2] Xen core parking 2: core parking implementation
Thread-Index: AcztUrPbW9dePUw1SLqPZ9Ouh5ZgWA==
Date: Fri, 17 Feb 2012 09:01:15 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D8BC@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_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [Patch 2/2] Xen core parking 2: core parking
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen core parking 2: core parking implementation

This patch implement Xen core parking.
Different core parking sequence has different power/performance result, due=
 to cpu socket/core/thread topology.
This patch provide power-first and performance-first policies, users can ch=
oose core parking policy by their own demand.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 392e77171d74 xen/common/core_parking.c
--- a/xen/common/core_parking.c	Mon Feb 13 11:33:17 2012 +0800
+++ b/xen/common/core_parking.c	Thu Feb 16 23:39:57 2012 +0800
@@ -1,13 +1,240 @@
+/*
+ *  core_parking.c - implement core parking according to dom0 requirement
+ *
+ *  Copyright (C) 2012, Intel Corporation.
+ *     Author: 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.
+ */
+
 #include <xen/types.h>
+#include <xen/cpu.h>
+#include <xen/init.h>
+#include <xen/cpumask.h>
+#include <asm/percpu.h>
+#include <asm/smp.h>
+
+#define CORE_PARKING_INCREMENT 1
+#define CORE_PARKING_DECREMENT 2
+
+static unsigned int core_parking_power(unsigned int event);
+static unsigned int core_parking_performance(unsigned int event);
=20
 static uint32_t cur_idle_nums;
+static unsigned int core_parking_cpunum[NR_CPUS] =3D {[0 ... NR_CPUS-1] =
=3D -1};
+
+static struct core_parking_policy {
+    char name[30];
+    unsigned int (*next)(unsigned int event);
+} *core_parking_policy;
+
+static enum core_parking_controller {
+    POWER_FIRST,
+    PERFORMANCE_FIRST
+} core_parking_controller =3D POWER_FIRST;
+
+static void __init setup_core_parking_option(char *str)
+{
+    if ( !strcmp(str, "power") )
+        core_parking_controller =3D POWER_FIRST;
+    else if ( !strcmp(str, "performance") )
+        core_parking_controller =3D PERFORMANCE_FIRST;
+    else
+        return;
+}
+custom_param("core_parking", setup_core_parking_option);
+
+static unsigned int core_parking_performance(unsigned int event)
+{
+    unsigned int cpu =3D -1;
+
+    switch ( event )
+    {
+    case CORE_PARKING_INCREMENT:
+    {
+        int core_tmp, core_weight =3D -1;
+        int sibling_tmp, sibling_weight =3D -1;
+        cpumask_t core_candidate_map, sibling_candidate_map;
+        cpumask_clear(&core_candidate_map);
+        cpumask_clear(&sibling_candidate_map);
+
+        for_each_cpu(cpu, &cpu_online_map)
+        {
+            if ( cpu =3D=3D 0 )
+                continue;
+
+            core_tmp =3D cpumask_weight(per_cpu(cpu_core_mask, cpu));
+            if ( core_weight < core_tmp )
+            {
+                core_weight =3D core_tmp;
+                cpumask_clear(&core_candidate_map);
+                cpumask_set_cpu(cpu, &core_candidate_map);
+            }
+            else if ( core_weight =3D=3D core_tmp )
+                cpumask_set_cpu(cpu, &core_candidate_map);
+        }
+
+        for_each_cpu(cpu, &core_candidate_map)
+        {
+            sibling_tmp =3D cpumask_weight(per_cpu(cpu_sibling_mask, cpu))=
;
+            if ( sibling_weight < sibling_tmp )
+            {
+                sibling_weight =3D sibling_tmp;
+                cpumask_clear(&sibling_candidate_map);
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+            }
+            else if ( sibling_weight =3D=3D sibling_tmp )
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+        }
+
+        cpu =3D cpumask_first(&sibling_candidate_map);
+    }
+    break;
+
+    case CORE_PARKING_DECREMENT:
+    {
+        cpu =3D core_parking_cpunum[cur_idle_nums -1];
+    }
+    break;
+
+    default:
+        break;
+    }
+
+    return cpu;
+}
+
+static unsigned int core_parking_power(unsigned int event)
+{
+    unsigned int cpu =3D -1;
+
+    switch ( event )
+    {
+    case CORE_PARKING_INCREMENT:
+    {
+        int core_tmp, core_weight =3D NR_CPUS + 1;
+        int sibling_tmp, sibling_weight =3D NR_CPUS + 1;
+        cpumask_t core_candidate_map, sibling_candidate_map;
+        cpumask_clear(&core_candidate_map);
+        cpumask_clear(&sibling_candidate_map);
+
+        for_each_cpu(cpu, &cpu_online_map)
+        {
+            if ( cpu =3D=3D 0 )
+                continue;
+
+            core_tmp =3D cpumask_weight(per_cpu(cpu_core_mask, cpu));
+            if ( core_weight > core_tmp )
+            {
+                core_weight =3D core_tmp;
+                cpumask_clear(&core_candidate_map);
+                cpumask_set_cpu(cpu, &core_candidate_map);
+            }
+            else if ( core_weight =3D=3D core_tmp )
+                cpumask_set_cpu(cpu, &core_candidate_map);
+        }
+
+        for_each_cpu(cpu, &core_candidate_map)
+        {
+            sibling_tmp =3D cpumask_weight(per_cpu(cpu_sibling_mask, cpu))=
;
+            if ( sibling_weight > sibling_tmp )
+            {
+                sibling_weight =3D sibling_tmp;
+                cpumask_clear(&sibling_candidate_map);
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+            }
+            else if ( sibling_weight =3D=3D sibling_tmp )
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+        }
+
+        cpu =3D cpumask_first(&sibling_candidate_map);
+    }
+    break;
+
+    case CORE_PARKING_DECREMENT:
+    {
+        cpu =3D core_parking_cpunum[cur_idle_nums -1];
+    }
+    break;
+
+    default:
+        break;
+    }
+
+    return cpu;
+}
=20
 long core_parking_helper(void *data)
 {
-    return 0;
+    uint32_t idle_nums =3D (unsigned long)data;
+    unsigned int cpu;
+    int ret =3D 0;
+
+    if ( !core_parking_policy )
+        return -EINVAL;
+
+    while ( cur_idle_nums < idle_nums )
+    {
+        cpu =3D core_parking_policy->next(CORE_PARKING_INCREMENT);
+        ret =3D cpu_down(cpu);
+        if ( ret )
+            return ret;
+        core_parking_cpunum[cur_idle_nums++] =3D cpu;
+    }
+
+    while ( cur_idle_nums > idle_nums )
+    {
+        cpu =3D core_parking_policy->next(CORE_PARKING_DECREMENT);
+        ret =3D cpu_up(cpu);
+        if ( ret )
+            return ret;
+        core_parking_cpunum[--cur_idle_nums] =3D -1;
+    }
+
+    return ret;
 }
=20
 uint32_t get_cur_idle_nums(void)
 {
     return cur_idle_nums;
 }
+
+static struct core_parking_policy power_first =3D {
+    .name =3D "power",
+    .next =3D core_parking_power,
+};
+
+static struct core_parking_policy performance_first =3D {
+    .name =3D "performance",
+    .next =3D core_parking_performance,
+};
+
+static int register_core_parking_policy(struct core_parking_policy *policy=
)
+{
+    if ( !policy || !policy->next )
+        return -EINVAL;
+
+    core_parking_policy =3D policy;
+    return 0;
+}
+
+static int __init core_parking_init(void)
+{
+    int ret =3D 0;
+
+    if ( core_parking_controller =3D=3D PERFORMANCE_FIRST )
+        ret =3D register_core_parking_policy(&performance_first);
+    else
+        ret =3D register_core_parking_policy(&power_first);
+
+    return ret;
+}
+__initcall(core_parking_init);=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_2.patch"
Content-Description: xen_core_parking_2.patch
Content-Disposition: attachment; filename="xen_core_parking_2.patch";
	size=7292; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Thu, 16 Feb 2012 15:39:58 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAyOiBjb3JlIHBhcmtpbmcgaW1wbGVtZW50YXRpb24KClRoaXMgcGF0
Y2ggaW1wbGVtZW50IFhlbiBjb3JlIHBhcmtpbmcuCkRpZmZlcmVudCBjb3JlIHBhcmtpbmcgc2Vx
dWVuY2UgaGFzIGRpZmZlcmVudCBwb3dlci9wZXJmb3JtYW5jZSByZXN1bHQsIGR1ZSB0byBjcHUg
c29ja2V0L2NvcmUvdGhyZWFkIHRvcG9sb2d5LgpUaGlzIHBhdGNoIHByb3ZpZGUgcG93ZXItZmly
c3QgYW5kIHBlcmZvcm1hbmNlLWZpcnN0IHBvbGljaWVzLCB1c2VycyBjYW4gY2hvb3NlIGNvcmUg
cGFya2luZyBwb2xpY3kgYnkgdGhlaXIgb3duIGRlbWFuZC4KClNpZ25lZC1vZmYtYnk6IExpdSwg
Smluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciAzOTJlNzcxNzFkNzQgeGVu
L2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gYS94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5jCU1v
biBGZWIgMTMgMTE6MzM6MTcgMjAxMiArMDgwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2lu
Zy5jCVRodSBGZWIgMTYgMjM6Mzk6NTcgMjAxMiArMDgwMApAQCAtMSwxMyArMSwyNDAgQEAKKy8q
CisgKiAgY29yZV9wYXJraW5nLmMgLSBpbXBsZW1lbnQgY29yZSBwYXJraW5nIGFjY29yZGluZyB0
byBkb20wIHJlcXVpcmVtZW50CisgKgorICogIENvcHlyaWdodCAoQykgMjAxMiwgSW50ZWwgQ29y
cG9yYXRpb24uCisgKiAgICAgQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KKyAqCisgKiAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVk
aXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICogIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9y
IChhdAorICogIHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAqCisgKiAgVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWws
IGJ1dAorICogIFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQg
d2FycmFudHkgb2YKKyAqICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorICogIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9y
IG1vcmUgZGV0YWlscy4KKyAqLworCiAjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8
eGVuL2NwdS5oPgorI2luY2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL2NwdW1hc2su
aD4KKyNpbmNsdWRlIDxhc20vcGVyY3B1Lmg+CisjaW5jbHVkZSA8YXNtL3NtcC5oPgorCisjZGVm
aW5lIENPUkVfUEFSS0lOR19JTkNSRU1FTlQgMQorI2RlZmluZSBDT1JFX1BBUktJTkdfREVDUkVN
RU5UIDIKKworc3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQg
aW50IGV2ZW50KTsKK3N0YXRpYyB1bnNpZ25lZCBpbnQgY29yZV9wYXJraW5nX3BlcmZvcm1hbmNl
KHVuc2lnbmVkIGludCBldmVudCk7CiAKIHN0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOwor
c3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfY3B1bnVtW05SX0NQVVNdID0ge1swIC4u
LiBOUl9DUFVTLTFdID0gLTF9OworCitzdGF0aWMgc3RydWN0IGNvcmVfcGFya2luZ19wb2xpY3kg
eworICAgIGNoYXIgbmFtZVszMF07CisgICAgdW5zaWduZWQgaW50ICgqbmV4dCkodW5zaWduZWQg
aW50IGV2ZW50KTsKK30gKmNvcmVfcGFya2luZ19wb2xpY3k7CisKK3N0YXRpYyBlbnVtIGNvcmVf
cGFya2luZ19jb250cm9sbGVyIHsKKyAgICBQT1dFUl9GSVJTVCwKKyAgICBQRVJGT1JNQU5DRV9G
SVJTVAorfSBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBPV0VSX0ZJUlNUOworCitzdGF0aWMg
dm9pZCBfX2luaXQgc2V0dXBfY29yZV9wYXJraW5nX29wdGlvbihjaGFyICpzdHIpCit7CisgICAg
aWYgKCAhc3RyY21wKHN0ciwgInBvd2VyIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJv
bGxlciA9IFBPV0VSX0ZJUlNUOworICAgIGVsc2UgaWYgKCAhc3RyY21wKHN0ciwgInBlcmZvcm1h
bmNlIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBFUkZPUk1BTkNFX0ZJ
UlNUOworICAgIGVsc2UKKyAgICAgICAgcmV0dXJuOworfQorY3VzdG9tX3BhcmFtKCJjb3JlX3Bh
cmtpbmciLCBzZXR1cF9jb3JlX3Bhcmtpbmdfb3B0aW9uKTsKKworc3RhdGljIHVuc2lnbmVkIGlu
dCBjb3JlX3BhcmtpbmdfcGVyZm9ybWFuY2UodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVu
c2lnbmVkIGludCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAg
Y2FzZSBDT1JFX1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1w
LCBjb3JlX3dlaWdodCA9IC0xOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gLTE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAsIHNpYmxpbmdf
Y2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFw
KTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKworICAg
ICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVlOworCisgICAg
ICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2NvcmVfbWFzaywg
Y3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0IDwgY29yZV90bXAgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7CisgICAgICAg
ICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
ICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3JlX3RtcCApCisg
ICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlkYXRlX21hcCk7
CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVf
bWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1hc2tfd2VpZ2h0
KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIHNpYmxp
bmdfd2VpZ2h0IDwgc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
IHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAgY3B1bWFza19j
bGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBjcHVtYXNrX3Nl
dF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCApCisgICAgICAg
ICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRlX21hcCk7Cisg
ICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5nX2NhbmRpZGF0
ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJLSU5HX0RFQ1JF
TUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1bY3VyX2lkbGVf
bnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAgICAgICAgYnJl
YWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KKworc3RhdGljIHVuc2lnbmVkIGludCBj
b3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVuc2lnbmVkIGlu
dCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAgY2FzZSBDT1JF
X1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1wLCBjb3JlX3dl
aWdodCA9IE5SX0NQVVMgKyAxOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gTlJfQ1BVUyArIDE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAs
IHNpYmxpbmdfY2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5k
aWRhdGVfbWFwKTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFw
KTsKKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVl
OworCisgICAgICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2Nv
cmVfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0ID4gY29yZV90bXAg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7
CisgICAgICAgICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAg
ICAgICAgICAgICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsK
KyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3Jl
X3RtcCApCisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlk
YXRlX21hcCk7CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9j
YW5kaWRhdGVfbWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1h
c2tfd2VpZ2h0KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBp
ZiAoIHNpYmxpbmdfd2VpZ2h0ID4gc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAg
ICAgICAgICAgIHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAg
Y3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBj
cHVtYXNrX3NldF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
IH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCAp
CisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRl
X21hcCk7CisgICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5n
X2NhbmRpZGF0ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJL
SU5HX0RFQ1JFTUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1b
Y3VyX2lkbGVfbnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAg
ICAgICAgYnJlYWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KIAogbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpCiB7Ci0gICAgcmV0dXJuIDA7CisgICAgdWludDMyX3Qg
aWRsZV9udW1zID0gKHVuc2lnbmVkIGxvbmcpZGF0YTsKKyAgICB1bnNpZ25lZCBpbnQgY3B1Owor
ICAgIGludCByZXQgPSAwOworCisgICAgaWYgKCAhY29yZV9wYXJraW5nX3BvbGljeSApCisgICAg
ICAgIHJldHVybiAtRUlOVkFMOworCisgICAgd2hpbGUgKCBjdXJfaWRsZV9udW1zIDwgaWRsZV9u
dW1zICkKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19wb2xpY3ktPm5leHQoQ09S
RV9QQVJLSU5HX0lOQ1JFTUVOVCk7CisgICAgICAgIHJldCA9IGNwdV9kb3duKGNwdSk7CisgICAg
ICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiByZXQ7CisgICAgICAgIGNvcmVfcGFy
a2luZ19jcHVudW1bY3VyX2lkbGVfbnVtcysrXSA9IGNwdTsKKyAgICB9CisKKyAgICB3aGlsZSAo
IGN1cl9pZGxlX251bXMgPiBpZGxlX251bXMgKQorICAgIHsKKyAgICAgICAgY3B1ID0gY29yZV9w
YXJraW5nX3BvbGljeS0+bmV4dChDT1JFX1BBUktJTkdfREVDUkVNRU5UKTsKKyAgICAgICAgcmV0
ID0gY3B1X3VwKGNwdSk7CisgICAgICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiBy
ZXQ7CisgICAgICAgIGNvcmVfcGFya2luZ19jcHVudW1bLS1jdXJfaWRsZV9udW1zXSA9IC0xOwor
ICAgIH0KKworICAgIHJldHVybiByZXQ7CiB9CiAKIHVpbnQzMl90IGdldF9jdXJfaWRsZV9udW1z
KHZvaWQpCiB7CiAgICAgcmV0dXJuIGN1cl9pZGxlX251bXM7CiB9CisKK3N0YXRpYyBzdHJ1Y3Qg
Y29yZV9wYXJraW5nX3BvbGljeSBwb3dlcl9maXJzdCA9IHsKKyAgICAubmFtZSA9ICJwb3dlciIs
CisgICAgLm5leHQgPSBjb3JlX3BhcmtpbmdfcG93ZXIsCit9OworCitzdGF0aWMgc3RydWN0IGNv
cmVfcGFya2luZ19wb2xpY3kgcGVyZm9ybWFuY2VfZmlyc3QgPSB7CisgICAgLm5hbWUgPSAicGVy
Zm9ybWFuY2UiLAorICAgIC5uZXh0ID0gY29yZV9wYXJraW5nX3BlcmZvcm1hbmNlLAorfTsKKwor
c3RhdGljIGludCByZWdpc3Rlcl9jb3JlX3BhcmtpbmdfcG9saWN5KHN0cnVjdCBjb3JlX3Bhcmtp
bmdfcG9saWN5ICpwb2xpY3kpCit7CisgICAgaWYgKCAhcG9saWN5IHx8ICFwb2xpY3ktPm5leHQg
KQorICAgICAgICByZXR1cm4gLUVJTlZBTDsKKworICAgIGNvcmVfcGFya2luZ19wb2xpY3kgPSBw
b2xpY3k7CisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IGNvcmVfcGFya2lu
Z19pbml0KHZvaWQpCit7CisgICAgaW50IHJldCA9IDA7CisKKyAgICBpZiAoIGNvcmVfcGFya2lu
Z19jb250cm9sbGVyID09IFBFUkZPUk1BTkNFX0ZJUlNUICkKKyAgICAgICAgcmV0ID0gcmVnaXN0
ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcGVyZm9ybWFuY2VfZmlyc3QpOworICAgIGVsc2UKKyAg
ICAgICAgcmV0ID0gcmVnaXN0ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcG93ZXJfZmlyc3QpOwor
CisgICAgcmV0dXJuIHJldDsKK30KK19faW5pdGNhbGwoY29yZV9wYXJraW5nX2luaXQpOwo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:03:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:03:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJic-0006We-KZ; Fri, 17 Feb 2012 09:03:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyJia-0006Vq-Oi
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:03:05 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329469376!11904085!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6356 invoked from network); 17 Feb 2012 09:02:57 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 09:02:57 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 01:02:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118567380"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 01:02:54 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 17:01:18 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 17:01:16 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir.xen@gmail.com"
	<keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Kernel development list
	<linux-kernel@vger.kernel.org>
Thread-Topic: [Patch 2/2] Xen core parking 2: core parking implementation
Thread-Index: AcztUrPbW9dePUw1SLqPZ9Ouh5ZgWA==
Date: Fri, 17 Feb 2012 09:01:15 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D8BC@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_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [Patch 2/2] Xen core parking 2: core parking
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen core parking 2: core parking implementation

This patch implement Xen core parking.
Different core parking sequence has different power/performance result, due=
 to cpu socket/core/thread topology.
This patch provide power-first and performance-first policies, users can ch=
oose core parking policy by their own demand.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 392e77171d74 xen/common/core_parking.c
--- a/xen/common/core_parking.c	Mon Feb 13 11:33:17 2012 +0800
+++ b/xen/common/core_parking.c	Thu Feb 16 23:39:57 2012 +0800
@@ -1,13 +1,240 @@
+/*
+ *  core_parking.c - implement core parking according to dom0 requirement
+ *
+ *  Copyright (C) 2012, Intel Corporation.
+ *     Author: 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.
+ */
+
 #include <xen/types.h>
+#include <xen/cpu.h>
+#include <xen/init.h>
+#include <xen/cpumask.h>
+#include <asm/percpu.h>
+#include <asm/smp.h>
+
+#define CORE_PARKING_INCREMENT 1
+#define CORE_PARKING_DECREMENT 2
+
+static unsigned int core_parking_power(unsigned int event);
+static unsigned int core_parking_performance(unsigned int event);
=20
 static uint32_t cur_idle_nums;
+static unsigned int core_parking_cpunum[NR_CPUS] =3D {[0 ... NR_CPUS-1] =
=3D -1};
+
+static struct core_parking_policy {
+    char name[30];
+    unsigned int (*next)(unsigned int event);
+} *core_parking_policy;
+
+static enum core_parking_controller {
+    POWER_FIRST,
+    PERFORMANCE_FIRST
+} core_parking_controller =3D POWER_FIRST;
+
+static void __init setup_core_parking_option(char *str)
+{
+    if ( !strcmp(str, "power") )
+        core_parking_controller =3D POWER_FIRST;
+    else if ( !strcmp(str, "performance") )
+        core_parking_controller =3D PERFORMANCE_FIRST;
+    else
+        return;
+}
+custom_param("core_parking", setup_core_parking_option);
+
+static unsigned int core_parking_performance(unsigned int event)
+{
+    unsigned int cpu =3D -1;
+
+    switch ( event )
+    {
+    case CORE_PARKING_INCREMENT:
+    {
+        int core_tmp, core_weight =3D -1;
+        int sibling_tmp, sibling_weight =3D -1;
+        cpumask_t core_candidate_map, sibling_candidate_map;
+        cpumask_clear(&core_candidate_map);
+        cpumask_clear(&sibling_candidate_map);
+
+        for_each_cpu(cpu, &cpu_online_map)
+        {
+            if ( cpu =3D=3D 0 )
+                continue;
+
+            core_tmp =3D cpumask_weight(per_cpu(cpu_core_mask, cpu));
+            if ( core_weight < core_tmp )
+            {
+                core_weight =3D core_tmp;
+                cpumask_clear(&core_candidate_map);
+                cpumask_set_cpu(cpu, &core_candidate_map);
+            }
+            else if ( core_weight =3D=3D core_tmp )
+                cpumask_set_cpu(cpu, &core_candidate_map);
+        }
+
+        for_each_cpu(cpu, &core_candidate_map)
+        {
+            sibling_tmp =3D cpumask_weight(per_cpu(cpu_sibling_mask, cpu))=
;
+            if ( sibling_weight < sibling_tmp )
+            {
+                sibling_weight =3D sibling_tmp;
+                cpumask_clear(&sibling_candidate_map);
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+            }
+            else if ( sibling_weight =3D=3D sibling_tmp )
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+        }
+
+        cpu =3D cpumask_first(&sibling_candidate_map);
+    }
+    break;
+
+    case CORE_PARKING_DECREMENT:
+    {
+        cpu =3D core_parking_cpunum[cur_idle_nums -1];
+    }
+    break;
+
+    default:
+        break;
+    }
+
+    return cpu;
+}
+
+static unsigned int core_parking_power(unsigned int event)
+{
+    unsigned int cpu =3D -1;
+
+    switch ( event )
+    {
+    case CORE_PARKING_INCREMENT:
+    {
+        int core_tmp, core_weight =3D NR_CPUS + 1;
+        int sibling_tmp, sibling_weight =3D NR_CPUS + 1;
+        cpumask_t core_candidate_map, sibling_candidate_map;
+        cpumask_clear(&core_candidate_map);
+        cpumask_clear(&sibling_candidate_map);
+
+        for_each_cpu(cpu, &cpu_online_map)
+        {
+            if ( cpu =3D=3D 0 )
+                continue;
+
+            core_tmp =3D cpumask_weight(per_cpu(cpu_core_mask, cpu));
+            if ( core_weight > core_tmp )
+            {
+                core_weight =3D core_tmp;
+                cpumask_clear(&core_candidate_map);
+                cpumask_set_cpu(cpu, &core_candidate_map);
+            }
+            else if ( core_weight =3D=3D core_tmp )
+                cpumask_set_cpu(cpu, &core_candidate_map);
+        }
+
+        for_each_cpu(cpu, &core_candidate_map)
+        {
+            sibling_tmp =3D cpumask_weight(per_cpu(cpu_sibling_mask, cpu))=
;
+            if ( sibling_weight > sibling_tmp )
+            {
+                sibling_weight =3D sibling_tmp;
+                cpumask_clear(&sibling_candidate_map);
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+            }
+            else if ( sibling_weight =3D=3D sibling_tmp )
+                cpumask_set_cpu(cpu, &sibling_candidate_map);
+        }
+
+        cpu =3D cpumask_first(&sibling_candidate_map);
+    }
+    break;
+
+    case CORE_PARKING_DECREMENT:
+    {
+        cpu =3D core_parking_cpunum[cur_idle_nums -1];
+    }
+    break;
+
+    default:
+        break;
+    }
+
+    return cpu;
+}
=20
 long core_parking_helper(void *data)
 {
-    return 0;
+    uint32_t idle_nums =3D (unsigned long)data;
+    unsigned int cpu;
+    int ret =3D 0;
+
+    if ( !core_parking_policy )
+        return -EINVAL;
+
+    while ( cur_idle_nums < idle_nums )
+    {
+        cpu =3D core_parking_policy->next(CORE_PARKING_INCREMENT);
+        ret =3D cpu_down(cpu);
+        if ( ret )
+            return ret;
+        core_parking_cpunum[cur_idle_nums++] =3D cpu;
+    }
+
+    while ( cur_idle_nums > idle_nums )
+    {
+        cpu =3D core_parking_policy->next(CORE_PARKING_DECREMENT);
+        ret =3D cpu_up(cpu);
+        if ( ret )
+            return ret;
+        core_parking_cpunum[--cur_idle_nums] =3D -1;
+    }
+
+    return ret;
 }
=20
 uint32_t get_cur_idle_nums(void)
 {
     return cur_idle_nums;
 }
+
+static struct core_parking_policy power_first =3D {
+    .name =3D "power",
+    .next =3D core_parking_power,
+};
+
+static struct core_parking_policy performance_first =3D {
+    .name =3D "performance",
+    .next =3D core_parking_performance,
+};
+
+static int register_core_parking_policy(struct core_parking_policy *policy=
)
+{
+    if ( !policy || !policy->next )
+        return -EINVAL;
+
+    core_parking_policy =3D policy;
+    return 0;
+}
+
+static int __init core_parking_init(void)
+{
+    int ret =3D 0;
+
+    if ( core_parking_controller =3D=3D PERFORMANCE_FIRST )
+        ret =3D register_core_parking_policy(&performance_first);
+    else
+        ret =3D register_core_parking_policy(&power_first);
+
+    return ret;
+}
+__initcall(core_parking_init);=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_2.patch"
Content-Description: xen_core_parking_2.patch
Content-Disposition: attachment; filename="xen_core_parking_2.patch";
	size=7292; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Thu, 16 Feb 2012 15:39:58 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAyOiBjb3JlIHBhcmtpbmcgaW1wbGVtZW50YXRpb24KClRoaXMgcGF0
Y2ggaW1wbGVtZW50IFhlbiBjb3JlIHBhcmtpbmcuCkRpZmZlcmVudCBjb3JlIHBhcmtpbmcgc2Vx
dWVuY2UgaGFzIGRpZmZlcmVudCBwb3dlci9wZXJmb3JtYW5jZSByZXN1bHQsIGR1ZSB0byBjcHUg
c29ja2V0L2NvcmUvdGhyZWFkIHRvcG9sb2d5LgpUaGlzIHBhdGNoIHByb3ZpZGUgcG93ZXItZmly
c3QgYW5kIHBlcmZvcm1hbmNlLWZpcnN0IHBvbGljaWVzLCB1c2VycyBjYW4gY2hvb3NlIGNvcmUg
cGFya2luZyBwb2xpY3kgYnkgdGhlaXIgb3duIGRlbWFuZC4KClNpZ25lZC1vZmYtYnk6IExpdSwg
Smluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciAzOTJlNzcxNzFkNzQgeGVu
L2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gYS94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5jCU1v
biBGZWIgMTMgMTE6MzM6MTcgMjAxMiArMDgwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2lu
Zy5jCVRodSBGZWIgMTYgMjM6Mzk6NTcgMjAxMiArMDgwMApAQCAtMSwxMyArMSwyNDAgQEAKKy8q
CisgKiAgY29yZV9wYXJraW5nLmMgLSBpbXBsZW1lbnQgY29yZSBwYXJraW5nIGFjY29yZGluZyB0
byBkb20wIHJlcXVpcmVtZW50CisgKgorICogIENvcHlyaWdodCAoQykgMjAxMiwgSW50ZWwgQ29y
cG9yYXRpb24uCisgKiAgICAgQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KKyAqCisgKiAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVk
aXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICogIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9y
IChhdAorICogIHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAqCisgKiAgVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWws
IGJ1dAorICogIFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQg
d2FycmFudHkgb2YKKyAqICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorICogIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9y
IG1vcmUgZGV0YWlscy4KKyAqLworCiAjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8
eGVuL2NwdS5oPgorI2luY2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL2NwdW1hc2su
aD4KKyNpbmNsdWRlIDxhc20vcGVyY3B1Lmg+CisjaW5jbHVkZSA8YXNtL3NtcC5oPgorCisjZGVm
aW5lIENPUkVfUEFSS0lOR19JTkNSRU1FTlQgMQorI2RlZmluZSBDT1JFX1BBUktJTkdfREVDUkVN
RU5UIDIKKworc3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQg
aW50IGV2ZW50KTsKK3N0YXRpYyB1bnNpZ25lZCBpbnQgY29yZV9wYXJraW5nX3BlcmZvcm1hbmNl
KHVuc2lnbmVkIGludCBldmVudCk7CiAKIHN0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOwor
c3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfY3B1bnVtW05SX0NQVVNdID0ge1swIC4u
LiBOUl9DUFVTLTFdID0gLTF9OworCitzdGF0aWMgc3RydWN0IGNvcmVfcGFya2luZ19wb2xpY3kg
eworICAgIGNoYXIgbmFtZVszMF07CisgICAgdW5zaWduZWQgaW50ICgqbmV4dCkodW5zaWduZWQg
aW50IGV2ZW50KTsKK30gKmNvcmVfcGFya2luZ19wb2xpY3k7CisKK3N0YXRpYyBlbnVtIGNvcmVf
cGFya2luZ19jb250cm9sbGVyIHsKKyAgICBQT1dFUl9GSVJTVCwKKyAgICBQRVJGT1JNQU5DRV9G
SVJTVAorfSBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBPV0VSX0ZJUlNUOworCitzdGF0aWMg
dm9pZCBfX2luaXQgc2V0dXBfY29yZV9wYXJraW5nX29wdGlvbihjaGFyICpzdHIpCit7CisgICAg
aWYgKCAhc3RyY21wKHN0ciwgInBvd2VyIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJv
bGxlciA9IFBPV0VSX0ZJUlNUOworICAgIGVsc2UgaWYgKCAhc3RyY21wKHN0ciwgInBlcmZvcm1h
bmNlIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBFUkZPUk1BTkNFX0ZJ
UlNUOworICAgIGVsc2UKKyAgICAgICAgcmV0dXJuOworfQorY3VzdG9tX3BhcmFtKCJjb3JlX3Bh
cmtpbmciLCBzZXR1cF9jb3JlX3Bhcmtpbmdfb3B0aW9uKTsKKworc3RhdGljIHVuc2lnbmVkIGlu
dCBjb3JlX3BhcmtpbmdfcGVyZm9ybWFuY2UodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVu
c2lnbmVkIGludCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAg
Y2FzZSBDT1JFX1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1w
LCBjb3JlX3dlaWdodCA9IC0xOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gLTE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAsIHNpYmxpbmdf
Y2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFw
KTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKworICAg
ICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVlOworCisgICAg
ICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2NvcmVfbWFzaywg
Y3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0IDwgY29yZV90bXAgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7CisgICAgICAg
ICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
ICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3JlX3RtcCApCisg
ICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlkYXRlX21hcCk7
CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVf
bWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1hc2tfd2VpZ2h0
KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIHNpYmxp
bmdfd2VpZ2h0IDwgc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
IHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAgY3B1bWFza19j
bGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBjcHVtYXNrX3Nl
dF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCApCisgICAgICAg
ICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRlX21hcCk7Cisg
ICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5nX2NhbmRpZGF0
ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJLSU5HX0RFQ1JF
TUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1bY3VyX2lkbGVf
bnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAgICAgICAgYnJl
YWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KKworc3RhdGljIHVuc2lnbmVkIGludCBj
b3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVuc2lnbmVkIGlu
dCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAgY2FzZSBDT1JF
X1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1wLCBjb3JlX3dl
aWdodCA9IE5SX0NQVVMgKyAxOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gTlJfQ1BVUyArIDE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAs
IHNpYmxpbmdfY2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5k
aWRhdGVfbWFwKTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFw
KTsKKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVl
OworCisgICAgICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2Nv
cmVfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0ID4gY29yZV90bXAg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7
CisgICAgICAgICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAg
ICAgICAgICAgICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsK
KyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3Jl
X3RtcCApCisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlk
YXRlX21hcCk7CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9j
YW5kaWRhdGVfbWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1h
c2tfd2VpZ2h0KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBp
ZiAoIHNpYmxpbmdfd2VpZ2h0ID4gc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAg
ICAgICAgICAgIHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAg
Y3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBj
cHVtYXNrX3NldF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
IH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCAp
CisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRl
X21hcCk7CisgICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5n
X2NhbmRpZGF0ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJL
SU5HX0RFQ1JFTUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1b
Y3VyX2lkbGVfbnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAg
ICAgICAgYnJlYWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KIAogbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpCiB7Ci0gICAgcmV0dXJuIDA7CisgICAgdWludDMyX3Qg
aWRsZV9udW1zID0gKHVuc2lnbmVkIGxvbmcpZGF0YTsKKyAgICB1bnNpZ25lZCBpbnQgY3B1Owor
ICAgIGludCByZXQgPSAwOworCisgICAgaWYgKCAhY29yZV9wYXJraW5nX3BvbGljeSApCisgICAg
ICAgIHJldHVybiAtRUlOVkFMOworCisgICAgd2hpbGUgKCBjdXJfaWRsZV9udW1zIDwgaWRsZV9u
dW1zICkKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19wb2xpY3ktPm5leHQoQ09S
RV9QQVJLSU5HX0lOQ1JFTUVOVCk7CisgICAgICAgIHJldCA9IGNwdV9kb3duKGNwdSk7CisgICAg
ICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiByZXQ7CisgICAgICAgIGNvcmVfcGFy
a2luZ19jcHVudW1bY3VyX2lkbGVfbnVtcysrXSA9IGNwdTsKKyAgICB9CisKKyAgICB3aGlsZSAo
IGN1cl9pZGxlX251bXMgPiBpZGxlX251bXMgKQorICAgIHsKKyAgICAgICAgY3B1ID0gY29yZV9w
YXJraW5nX3BvbGljeS0+bmV4dChDT1JFX1BBUktJTkdfREVDUkVNRU5UKTsKKyAgICAgICAgcmV0
ID0gY3B1X3VwKGNwdSk7CisgICAgICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiBy
ZXQ7CisgICAgICAgIGNvcmVfcGFya2luZ19jcHVudW1bLS1jdXJfaWRsZV9udW1zXSA9IC0xOwor
ICAgIH0KKworICAgIHJldHVybiByZXQ7CiB9CiAKIHVpbnQzMl90IGdldF9jdXJfaWRsZV9udW1z
KHZvaWQpCiB7CiAgICAgcmV0dXJuIGN1cl9pZGxlX251bXM7CiB9CisKK3N0YXRpYyBzdHJ1Y3Qg
Y29yZV9wYXJraW5nX3BvbGljeSBwb3dlcl9maXJzdCA9IHsKKyAgICAubmFtZSA9ICJwb3dlciIs
CisgICAgLm5leHQgPSBjb3JlX3BhcmtpbmdfcG93ZXIsCit9OworCitzdGF0aWMgc3RydWN0IGNv
cmVfcGFya2luZ19wb2xpY3kgcGVyZm9ybWFuY2VfZmlyc3QgPSB7CisgICAgLm5hbWUgPSAicGVy
Zm9ybWFuY2UiLAorICAgIC5uZXh0ID0gY29yZV9wYXJraW5nX3BlcmZvcm1hbmNlLAorfTsKKwor
c3RhdGljIGludCByZWdpc3Rlcl9jb3JlX3BhcmtpbmdfcG9saWN5KHN0cnVjdCBjb3JlX3Bhcmtp
bmdfcG9saWN5ICpwb2xpY3kpCit7CisgICAgaWYgKCAhcG9saWN5IHx8ICFwb2xpY3ktPm5leHQg
KQorICAgICAgICByZXR1cm4gLUVJTlZBTDsKKworICAgIGNvcmVfcGFya2luZ19wb2xpY3kgPSBw
b2xpY3k7CisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IGNvcmVfcGFya2lu
Z19pbml0KHZvaWQpCit7CisgICAgaW50IHJldCA9IDA7CisKKyAgICBpZiAoIGNvcmVfcGFya2lu
Z19jb250cm9sbGVyID09IFBFUkZPUk1BTkNFX0ZJUlNUICkKKyAgICAgICAgcmV0ID0gcmVnaXN0
ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcGVyZm9ybWFuY2VfZmlyc3QpOworICAgIGVsc2UKKyAg
ICAgICAgcmV0ID0gcmVnaXN0ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcG93ZXJfZmlyc3QpOwor
CisgICAgcmV0dXJuIHJldDsKK30KK19faW5pdGNhbGwoY29yZV9wYXJraW5nX2luaXQpOwo=

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233509D8BCSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:06:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJlZ-0006nJ-8S; Fri, 17 Feb 2012 09:06:09 +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 1RyJlX-0006mw-QU
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:06:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329469513!63236527!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20263 invoked from network); 17 Feb 2012 09:05:14 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 09:05:14 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 01:06:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126617913"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2012 01:06:01 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 17:05:52 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 17:05:50 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich
	<JBeulich@suse.com>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: Xen core parking feature enable
Thread-Index: AcztU1d3PLSuJdLoSSKv/gZj8IDL9w==
Date: Fri, 17 Feb 2012 09:05:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D902@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: "Li, Shaohua" <shaohua.li@intel.com>
Subject: [Xen-devel] Xen core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, forget cc kernel development list.

Core parking is a power control feature and it can co-work with NPTM to control system power budget through online/offline some CPUs in the system. These patches implement core parking feature for xen. They consist of 2 parts: dom0 patches and xen hypervisor patches.

At dom0 side, patches include
[Patch 1/3] intercept native pad (Processor Aggregator Device) logic, providing a native interface for natvie platform and a paravirt template for paravirt platform, so that os can implicitly hook to proper ops accordingly;
[Patch 2/3] redirect paravirt template to Xen pv ops;
[Patch 3/3] implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Due to the characteristic of xen continue_hypercall_on_cpu, dom0 seperately send/get core parking request/result;

At Xen hypervisor side, patches include
[Patch 1/2] implement hypercall through which dom0 send core parking request, and get core parking result;
[Patch 2/2] implement Xen core parking. Different core parking sequence has different power/performance result, due to cpu socket/core/thread topology. This patch provide power-first and performance-first policies, users can choose core parking policy on their own demand, considering power and performance tradeoff.

cc Shaohua, core parking feature author at linux kernel side.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:06:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJlZ-0006nJ-8S; Fri, 17 Feb 2012 09:06:09 +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 1RyJlX-0006mw-QU
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:06:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329469513!63236527!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20263 invoked from network); 17 Feb 2012 09:05:14 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 09:05:14 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 01:06:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126617913"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2012 01:06:01 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 17 Feb 2012 17:05:52 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Fri, 17 Feb 2012 17:05:50 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jan Beulich
	<JBeulich@suse.com>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Kernel
	development list <linux-kernel@vger.kernel.org>
Thread-Topic: Xen core parking feature enable
Thread-Index: AcztU1d3PLSuJdLoSSKv/gZj8IDL9w==
Date: Fri, 17 Feb 2012 09:05:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509D902@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: "Li, Shaohua" <shaohua.li@intel.com>
Subject: [Xen-devel] Xen core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, forget cc kernel development list.

Core parking is a power control feature and it can co-work with NPTM to control system power budget through online/offline some CPUs in the system. These patches implement core parking feature for xen. They consist of 2 parts: dom0 patches and xen hypervisor patches.

At dom0 side, patches include
[Patch 1/3] intercept native pad (Processor Aggregator Device) logic, providing a native interface for natvie platform and a paravirt template for paravirt platform, so that os can implicitly hook to proper ops accordingly;
[Patch 2/3] redirect paravirt template to Xen pv ops;
[Patch 3/3] implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Due to the characteristic of xen continue_hypercall_on_cpu, dom0 seperately send/get core parking request/result;

At Xen hypervisor side, patches include
[Patch 1/2] implement hypercall through which dom0 send core parking request, and get core parking result;
[Patch 2/2] implement Xen core parking. Different core parking sequence has different power/performance result, due to cpu socket/core/thread topology. This patch provide power-first and performance-first policies, users can choose core parking policy on their own demand, considering power and performance tradeoff.

cc Shaohua, core parking feature author at linux kernel side.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJuO-00071F-Qs; Fri, 17 Feb 2012 09:15:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1RyJuN-000717-CN
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:15:15 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329470107!4456281!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3812 invoked from network); 17 Feb 2012 09:15:09 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 09:15:09 -0000
Received: by damc16 with SMTP id c16so18995028dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 01:15:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.73.234 with SMTP id o10mr22236429pbv.90.1329470106890; Fri,
	17 Feb 2012 01:15:06 -0800 (PST)
Received: by 10.68.231.38 with HTTP; Fri, 17 Feb 2012 01:15:06 -0800 (PST)
In-Reply-To: <4F3DFE96.2030803@gt.net>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
	<4F3DFE96.2030803@gt.net>
Date: Fri, 17 Feb 2012 16:15:06 +0700
Message-ID: <CAG1y0scV6c=oRM3P8sMD8+u9Uu8Awzc0MFpjvzRgng=VYV8DgA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Nathan March <nathan@gt.net>
X-Gm-Message-State: ALoCoQljB5ieOE7aOdek+0zUMwnKxWxHk9BP9wpni0HxTD0hiyOgMmuUuKhCycaQuaP0YQaIYzNX
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 2:15 PM, Nathan March <nathan@gt.net> wrote:
> I have this happening again on a server and running udev monitor (udevadm
> monitor --kernel --udev --property) prints absolutely *nothing*. I've
> confirmed on a working xen host that it does actually print a ton of
> debugging when i restart a VM. This machine however prints nothing when
> trying to spawn.

This might sound silly, but is udevd running? I've had cases where it
suddenly died.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJuO-00071F-Qs; Fri, 17 Feb 2012 09:15:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1RyJuN-000717-CN
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:15:15 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329470107!4456281!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3812 invoked from network); 17 Feb 2012 09:15:09 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 09:15:09 -0000
Received: by damc16 with SMTP id c16so18995028dam.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 01:15:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.73.234 with SMTP id o10mr22236429pbv.90.1329470106890; Fri,
	17 Feb 2012 01:15:06 -0800 (PST)
Received: by 10.68.231.38 with HTTP; Fri, 17 Feb 2012 01:15:06 -0800 (PST)
In-Reply-To: <4F3DFE96.2030803@gt.net>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
	<4F3DFE96.2030803@gt.net>
Date: Fri, 17 Feb 2012 16:15:06 +0700
Message-ID: <CAG1y0scV6c=oRM3P8sMD8+u9Uu8Awzc0MFpjvzRgng=VYV8DgA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Nathan March <nathan@gt.net>
X-Gm-Message-State: ALoCoQljB5ieOE7aOdek+0zUMwnKxWxHk9BP9wpni0HxTD0hiyOgMmuUuKhCycaQuaP0YQaIYzNX
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 2:15 PM, Nathan March <nathan@gt.net> wrote:
> I have this happening again on a server and running udev monitor (udevadm
> monitor --kernel --udev --property) prints absolutely *nothing*. I've
> confirmed on a working xen host that it does actually print a ton of
> debugging when i restart a VM. This machine however prints nothing when
> trying to spawn.

This might sound silly, but is udevd running? I've had cases where it
suddenly died.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJzF-0007Fi-IV; Fri, 17 Feb 2012 09:20:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RyJzD-0007FZ-KQ
	for Xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:20:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329470407!13742088!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20382 invoked from network); 17 Feb 2012 09:20:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 09:20:09 -0000
Received: by wibhm2 with SMTP id hm2so4702938wib.30
	for <Xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 01:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MXtN1tNrAfweWYklGk5dQbODwSPizSaYH8VWr5uG6ro=;
	b=XGLJ3UPAsRy/F4fXuhpLj0omis/7ZDK6cAOaH52kWw1LiKcCDc04UZqhGxLZjPCtbh
	yhmq5UhVavCxRzuHMLi1M25QfWk50dv5T5zx3DMrLhgGyXA/bkrRs0ob0Pqo0+aLVrUg
	8TlZWT69BZV9CsjoRvn0RFdsoFH4fKjftqmnk=
Received: by 10.180.100.33 with SMTP id ev1mr2766838wib.3.1329470406258;
	Fri, 17 Feb 2012 01:20:06 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164]) by mx.google.com with ESMTPS id
	hb10sm32564944wib.10.2012.02.17.01.20.04
	(version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 01:20:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 17 Feb 2012 09:20:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>,
	<Xen-devel@lists.xensource.com>
Message-ID: <CB63CC43.2B6E0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [question] will softirq handler potentially be
	called many times?
Thread-Index: AcztVVRYby6kbTTENUCk0nsbtjA5Mg==
In-Reply-To: <CANqQZNHc11vDEbkT2_JMER7FWeqdSQi+5_n1gN36BnJGs8mDiA@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [question] will softirq handler potentially be
 called many times?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/2012 04:47, "Kai Huang" <mail.kai.huang@gmail.com> wrote:

> Hi,
> 
> I see the __do_softirq is called when ! in_atomic(), which means
> potentially __do_softirq may be interrupted by trap, exception,
> interrupt, etc, so seems softirq handler may be executed many times?
> 
> For example, if interrupt happens after i =
> find_first_set_bit(pending), the same softirq hander will be called
> twice as the do_softriq will be called after all interrupt handler
> returned, and the pending bit has not been cleared yet when first
> do_softirq was called.

Can't happen, we only call do_softirq() when returning from an interrupt
back to guest context. Therefore a nested interrupt call does not cause
do_softirq to run.

  -- Keir

> static void __do_softirq(unsigned long ignore_mask)
> {
>     ......
>     for ( ; ; )
>     {
>         ......
>         i = find_first_set_bit(pending);
>                                                    <- interrupt happens
>         clear_bit(i, &softirq_pending(cpu));
>         (*softirq_handlers[i])();
>     }
> }
> 
> -cody
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyJzF-0007Fi-IV; Fri, 17 Feb 2012 09:20:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RyJzD-0007FZ-KQ
	for Xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:20:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329470407!13742088!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20382 invoked from network); 17 Feb 2012 09:20:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 09:20:09 -0000
Received: by wibhm2 with SMTP id hm2so4702938wib.30
	for <Xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 01:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MXtN1tNrAfweWYklGk5dQbODwSPizSaYH8VWr5uG6ro=;
	b=XGLJ3UPAsRy/F4fXuhpLj0omis/7ZDK6cAOaH52kWw1LiKcCDc04UZqhGxLZjPCtbh
	yhmq5UhVavCxRzuHMLi1M25QfWk50dv5T5zx3DMrLhgGyXA/bkrRs0ob0Pqo0+aLVrUg
	8TlZWT69BZV9CsjoRvn0RFdsoFH4fKjftqmnk=
Received: by 10.180.100.33 with SMTP id ev1mr2766838wib.3.1329470406258;
	Fri, 17 Feb 2012 01:20:06 -0800 (PST)
Received: from [192.168.1.84] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164]) by mx.google.com with ESMTPS id
	hb10sm32564944wib.10.2012.02.17.01.20.04
	(version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 01:20:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 17 Feb 2012 09:20:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>,
	<Xen-devel@lists.xensource.com>
Message-ID: <CB63CC43.2B6E0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [question] will softirq handler potentially be
	called many times?
Thread-Index: AcztVVRYby6kbTTENUCk0nsbtjA5Mg==
In-Reply-To: <CANqQZNHc11vDEbkT2_JMER7FWeqdSQi+5_n1gN36BnJGs8mDiA@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [question] will softirq handler potentially be
 called many times?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/2012 04:47, "Kai Huang" <mail.kai.huang@gmail.com> wrote:

> Hi,
> 
> I see the __do_softirq is called when ! in_atomic(), which means
> potentially __do_softirq may be interrupted by trap, exception,
> interrupt, etc, so seems softirq handler may be executed many times?
> 
> For example, if interrupt happens after i =
> find_first_set_bit(pending), the same softirq hander will be called
> twice as the do_softriq will be called after all interrupt handler
> returned, and the pending bit has not been cleared yet when first
> do_softirq was called.

Can't happen, we only call do_softirq() when returning from an interrupt
back to guest context. Therefore a nested interrupt call does not cause
do_softirq to run.

  -- Keir

> static void __do_softirq(unsigned long ignore_mask)
> {
>     ......
>     for ( ; ; )
>     {
>         ......
>         i = find_first_set_bit(pending);
>                                                    <- interrupt happens
>         clear_bit(i, &softirq_pending(cpu));
>         (*softirq_handlers[i])();
>     }
> }
> 
> -cody
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:21:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyK0P-0007Lg-75; Fri, 17 Feb 2012 09:21:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RyK0O-0007L2-31
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:21:28 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329470479!8607091!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32269 invoked from network); 17 Feb 2012 09:21:21 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 09:21:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=/290BSY/ZQ2C
	eCylfuDuMZw4NCA=; b=ip+IHwDpf5O1MiPao2lXWpZCXFBwnNIDnBNC2bwrLoFl
	9rNog3oQ6qba5hAiu7G7kXSf3oI5iGH6eMRXtCRwzPnAIBbcyAcUDi8hfz/G7uux
	KoZfRvNda7dN2yCNKnzblD1N3WrlctoSQsMZOuASa9vNN7Mpoyx8qkjGt4Xh7Nw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=GcZ7u4
	8LDzlt1+6Ox6OIkKuQft1FWkzGpbXBVW85mDbysKmIer2dXwgV2w58GXSRa09HDC
	VQ0/eIGgwiN0GL93g1uNe7G3T8O+EguIO4GqxakDkrxS0VpXjvmHvt/hSuvQmqFA
	9S2iw1FiR+b3LMUXgW9xqle5UhWGBrDVmlx9s=
Received: (qmail 19907 invoked from network); 17 Feb 2012 09:21:19 -0000
X-AntiVirus: Clean
Received: from 216-19-182-203.dyn.novuscom.net (HELO ?192.168.1.102?)
	(nathan@gt.net@216.19.182.203)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	17 Feb 2012 09:21:19 -0000
Message-ID: <4F3E1C12.6010005@gt.net>
Date: Fri, 17 Feb 2012 01:21:22 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
	<4F3DFE96.2030803@gt.net>
	<CAG1y0scV6c=oRM3P8sMD8+u9Uu8Awzc0MFpjvzRgng=VYV8DgA@mail.gmail.com>
In-Reply-To: <CAG1y0scV6c=oRM3P8sMD8+u9Uu8Awzc0MFpjvzRgng=VYV8DgA@mail.gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2/17/2012 1:15 AM, Fajar A. Nugraha wrote:
> On Fri, Feb 17, 2012 at 2:15 PM, Nathan March<nathan@gt.net>  wrote:
>> I have this happening again on a server and running udev monitor (udevadm
>> monitor --kernel --udev --property) prints absolutely *nothing*. I've
>> confirmed on a working xen host that it does actually print a ton of
>> debugging when i restart a VM. This machine however prints nothing when
>> trying to spawn.
> This might sound silly, but is udevd running? I've had cases where it
> suddenly died.
>
Sometimes it takes someone to point out the obvious =)

It's running, but whether it's actually working or not may be another 
question:

root      2476  0.0  0.0   6184   488 ?        S<s  Feb14   0:00 
/sbin/udevd --daemon
root     16274  0.0  0.0   6180   284 ?        S<   Feb15   0:00  \_ 
/sbin/udevd --daemon
root     16285  0.0  0.0   6180   164 ?        S<   Feb15   0:00  \_ 
/sbin/udevd --daemon

*Although* we're currently on udev 141 which appears to be ancient, so 
that may be the source of the problem. Will try an upgrade.

- Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:21:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyK0P-0007Lg-75; Fri, 17 Feb 2012 09:21:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RyK0O-0007L2-31
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:21:28 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329470479!8607091!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32269 invoked from network); 17 Feb 2012 09:21:21 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 09:21:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=mail; bh=/290BSY/ZQ2C
	eCylfuDuMZw4NCA=; b=ip+IHwDpf5O1MiPao2lXWpZCXFBwnNIDnBNC2bwrLoFl
	9rNog3oQ6qba5hAiu7G7kXSf3oI5iGH6eMRXtCRwzPnAIBbcyAcUDi8hfz/G7uux
	KoZfRvNda7dN2yCNKnzblD1N3WrlctoSQsMZOuASa9vNN7Mpoyx8qkjGt4Xh7Nw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=mail; b=GcZ7u4
	8LDzlt1+6Ox6OIkKuQft1FWkzGpbXBVW85mDbysKmIer2dXwgV2w58GXSRa09HDC
	VQ0/eIGgwiN0GL93g1uNe7G3T8O+EguIO4GqxakDkrxS0VpXjvmHvt/hSuvQmqFA
	9S2iw1FiR+b3LMUXgW9xqle5UhWGBrDVmlx9s=
Received: (qmail 19907 invoked from network); 17 Feb 2012 09:21:19 -0000
X-AntiVirus: Clean
Received: from 216-19-182-203.dyn.novuscom.net (HELO ?192.168.1.102?)
	(nathan@gt.net@216.19.182.203)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	17 Feb 2012 09:21:19 -0000
Message-ID: <4F3E1C12.6010005@gt.net>
Date: Fri, 17 Feb 2012 01:21:22 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <4F28603F.8010900@gt.net>
	<20120201013036.GA12637@andromeda.dapyr.net>
	<4F3DFE96.2030803@gt.net>
	<CAG1y0scV6c=oRM3P8sMD8+u9Uu8Awzc0MFpjvzRgng=VYV8DgA@mail.gmail.com>
In-Reply-To: <CAG1y0scV6c=oRM3P8sMD8+u9Uu8Awzc0MFpjvzRgng=VYV8DgA@mail.gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Crashing / unable to start domUs due to high number
 of luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2/17/2012 1:15 AM, Fajar A. Nugraha wrote:
> On Fri, Feb 17, 2012 at 2:15 PM, Nathan March<nathan@gt.net>  wrote:
>> I have this happening again on a server and running udev monitor (udevadm
>> monitor --kernel --udev --property) prints absolutely *nothing*. I've
>> confirmed on a working xen host that it does actually print a ton of
>> debugging when i restart a VM. This machine however prints nothing when
>> trying to spawn.
> This might sound silly, but is udevd running? I've had cases where it
> suddenly died.
>
Sometimes it takes someone to point out the obvious =)

It's running, but whether it's actually working or not may be another 
question:

root      2476  0.0  0.0   6184   488 ?        S<s  Feb14   0:00 
/sbin/udevd --daemon
root     16274  0.0  0.0   6180   284 ?        S<   Feb15   0:00  \_ 
/sbin/udevd --daemon
root     16285  0.0  0.0   6180   164 ?        S<   Feb15   0:00  \_ 
/sbin/udevd --daemon

*Although* we're currently on udev 141 which appears to be ancient, so 
that may be the source of the problem. Will try an upgrade.

- Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09: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.xensource.com>)
	id 1RyKKA-0007db-Cy; Fri, 17 Feb 2012 09:41:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyKK8-0007dV-Td
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 09:41:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329471706!6412992!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11723 invoked from network); 17 Feb 2012 09:41:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 09:41:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 09:41:46 +0000
Message-Id: <4F3E2EEA020000780007397F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 09:41:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Core parking is a power control feature and it can co-work with NPTM to 
> control system power budget through online/offline some CPUs in the system. 
> These patches implement core parking feature for xen. They consist of 2 
> parts: dom0 patches and xen hypervisor patches.
> 
> At dom0 side, patches include
> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic, 
> providing a native interface for natvie platform and a paravirt template for 
> paravirt platform, so that os can implicitly hook to proper ops accordingly;
> [Patch 2/3] redirect paravirt template to Xen pv ops;
> [Patch 3/3] implement Xen pad logic, and when getting pad device 
> notification, it hypercalls to Xen hypervisor for core parking. Due to the 
> characteristic of xen continue_hypercall_on_cpu, dom0 seperately send/get 
> core parking request/result;
> 
> At Xen hypervisor side, patches include
> [Patch 1/2] implement hypercall through which dom0 send core parking 
> request, and get core parking result;
> [Patch 2/2] implement Xen core parking. Different core parking sequence has 
> different power/performance result, due to cpu socket/core/thread topology. 
> This patch provide power-first and performance-first policies, users can choose 
> core parking policy on their own demand, considering power and performance 
> tradeoff.

Does this really need to be implemented in the hypervisor? All this
boils down to is a wrapper around cpu_down() and cpu_up(), which
have hypercall interfaces already. So I'd rather see this as being
an extension to Dom0's pCPU management patches (which aren't
upstream afaict)...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09: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.xensource.com>)
	id 1RyKKA-0007db-Cy; Fri, 17 Feb 2012 09:41:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyKK8-0007dV-Td
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 09:41:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329471706!6412992!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11723 invoked from network); 17 Feb 2012 09:41:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 09:41:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 09:41:46 +0000
Message-Id: <4F3E2EEA020000780007397F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 09:41:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Core parking is a power control feature and it can co-work with NPTM to 
> control system power budget through online/offline some CPUs in the system. 
> These patches implement core parking feature for xen. They consist of 2 
> parts: dom0 patches and xen hypervisor patches.
> 
> At dom0 side, patches include
> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic, 
> providing a native interface for natvie platform and a paravirt template for 
> paravirt platform, so that os can implicitly hook to proper ops accordingly;
> [Patch 2/3] redirect paravirt template to Xen pv ops;
> [Patch 3/3] implement Xen pad logic, and when getting pad device 
> notification, it hypercalls to Xen hypervisor for core parking. Due to the 
> characteristic of xen continue_hypercall_on_cpu, dom0 seperately send/get 
> core parking request/result;
> 
> At Xen hypervisor side, patches include
> [Patch 1/2] implement hypercall through which dom0 send core parking 
> request, and get core parking result;
> [Patch 2/2] implement Xen core parking. Different core parking sequence has 
> different power/performance result, due to cpu socket/core/thread topology. 
> This patch provide power-first and performance-first policies, users can choose 
> core parking policy on their own demand, considering power and performance 
> tradeoff.

Does this really need to be implemented in the hypervisor? All this
boils down to is a wrapper around cpu_down() and cpu_up(), which
have hypercall interfaces already. So I'd rather see this as being
an extension to Dom0's pCPU management patches (which aren't
upstream afaict)...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:45:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09: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.xensource.com>)
	id 1RyKNO-0007lX-Lg; Fri, 17 Feb 2012 09:45:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RyKNN-0007lD-9n
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:45:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329471857!63243948!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15995 invoked from network); 17 Feb 2012 09:44:19 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 09:44:19 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1H9j4il001931
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 17 Feb 2012 01:45:05 -0800
Received: by bkcjg15 with SMTP id jg15so5537057bkc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 01:45:03 -0800 (PST)
Received: by 10.204.152.193 with SMTP id h1mr3767369bkw.85.1329471903288; Fri,
	17 Feb 2012 01:45:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Fri, 17 Feb 2012 01:44:23 -0800 (PST)
In-Reply-To: <1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 17 Feb 2012 01:44:23 -0800
Message-ID: <CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4742717693860134092=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4742717693860134092==
Content-Type: multipart/alternative; boundary=0015175d079a88cc0504b925ccd4

--0015175d079a88cc0504b925ccd4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Introduce a new save_id to save/restore toolstack specific extra
> information.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
>
cc-ing Ian Jackson.
These patches (and other follow ups including mine) have been acked.
Ian, are there any issues blocking these patches ?

thanks
shriram

--0015175d079a88cc0504b925ccd4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Wed, Feb 1, 2012 at 10:10 AM, Stefano Sta=
bellini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citri=
x.com">stefano.stabellini@eu.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">

<div class=3D"im">Introduce a new save_id to save/restore toolstack specifi=
c extra<br>
information.<br>
<br>
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
</div>Acked-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.c=
a">rshriram@cs.ubc.ca</a>&gt;<br>
<br></blockquote></div><br>cc-ing Ian Jackson.<br>These patches (and other =
follow ups including mine) have been acked.<br>Ian, are there any issues bl=
ocking these patches ?<br><br>thanks<br>shriram<br>

--0015175d079a88cc0504b925ccd4--


--===============4742717693860134092==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4742717693860134092==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 09:45:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 09: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.xensource.com>)
	id 1RyKNO-0007lX-Lg; Fri, 17 Feb 2012 09:45:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RyKNN-0007lD-9n
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 09:45:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329471857!63243948!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15995 invoked from network); 17 Feb 2012 09:44:19 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 09:44:19 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1H9j4il001931
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 17 Feb 2012 01:45:05 -0800
Received: by bkcjg15 with SMTP id jg15so5537057bkc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 01:45:03 -0800 (PST)
Received: by 10.204.152.193 with SMTP id h1mr3767369bkw.85.1329471903288; Fri,
	17 Feb 2012 01:45:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Fri, 17 Feb 2012 01:44:23 -0800 (PST)
In-Reply-To: <1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 17 Feb 2012 01:44:23 -0800
Message-ID: <CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4742717693860134092=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4742717693860134092==
Content-Type: multipart/alternative; boundary=0015175d079a88cc0504b925ccd4

--0015175d079a88cc0504b925ccd4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Introduce a new save_id to save/restore toolstack specific extra
> information.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
>
cc-ing Ian Jackson.
These patches (and other follow ups including mine) have been acked.
Ian, are there any issues blocking these patches ?

thanks
shriram

--0015175d079a88cc0504b925ccd4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Wed, Feb 1, 2012 at 10:10 AM, Stefano Sta=
bellini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citri=
x.com">stefano.stabellini@eu.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">

<div class=3D"im">Introduce a new save_id to save/restore toolstack specifi=
c extra<br>
information.<br>
<br>
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
</div>Acked-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.c=
a">rshriram@cs.ubc.ca</a>&gt;<br>
<br></blockquote></div><br>cc-ing Ian Jackson.<br>These patches (and other =
follow ups including mine) have been acked.<br>Ian, are there any issues bl=
ocking these patches ?<br><br>thanks<br>shriram<br>

--0015175d079a88cc0504b925ccd4--


--===============4742717693860134092==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4742717693860134092==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyKgc-0008UK-KO; Fri, 17 Feb 2012 10:05:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyKga-0008UF-Ns
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 10:05:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329473097!13706068!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4745 invoked from network); 17 Feb 2012 10:04:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 10:04:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 10:04:57 +0000
Message-Id: <4F3E345802000078000739B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 10:04:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Kerneldevelopment list <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.02.12 at 09:56, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops 
> accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch for 
> Xen
>  core parking.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   10 +++++
>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>  arch/x86/kernel/paravirt.c            |    9 +++++
>  drivers/acpi/acpi_pad.c               |   15 +++-----
>  include/acpi/acpi_pad.h               |   61 
> +++++++++++++++++++++++++++++++++
>  5 files changed, 93 insertions(+), 9 deletions(-)
>  create mode 100644 include/acpi/acpi_pad.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index a7d2db9..02e6df0 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
>  }
>  
> +static inline int __acpi_pad_init(void)
> +{
> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> +}

With this you, aiui, you aim at getting the calls patched. Are the callers
of this really on performance critical paths? If not, the simpler approach
of having an ops structure the fields of which get overwritten by
Xen initialization would seem a more appropriate approach.

Jan

> +
>  static inline void write_cr0(unsigned long x)
>  {
>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..61e20de 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -336,6 +336,11 @@ struct pv_lock_ops {
>  	void (*spin_unlock)(struct arch_spinlock *lock);
>  };
>  
> +struct pv_pad_ops {
> +	int (*acpi_pad_init)(void);
> +	void (*acpi_pad_exit)(void);
> +};
> +
>  /* This contains all the paravirt structures: we get a convenient
>   * number for each function using the offset which we use to indicate
>   * what to patch. */
> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>  	struct pv_apic_ops pv_apic_ops;
>  	struct pv_mmu_ops pv_mmu_ops;
>  	struct pv_lock_ops pv_lock_ops;
> +	struct pv_pad_ops pv_pad_ops;
>  };
>  
>  extern struct pv_info pv_info;
> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>  extern struct pv_apic_ops pv_apic_ops;
>  extern struct pv_mmu_ops pv_mmu_ops;
>  extern struct pv_lock_ops pv_lock_ops;
> +extern struct pv_pad_ops pv_pad_ops;
>  
>  #define PARAVIRT_PATCH(x)					\
>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index d90272e..ec778f6 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -38,6 +38,8 @@
>  #include <asm/tlbflush.h>
>  #include <asm/timer.h>
>  
> +#include <acpi/acpi_pad.h>
> +
>  /* nop stub */
>  void _paravirt_nop(void)
>  {
> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>  		.pv_lock_ops = pv_lock_ops,
>  #endif
> +		.pv_pad_ops = pv_pad_ops,
>  	};
>  	return *((void **)&tmpl + type);
>  }
> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>  	.set_fixmap = native_set_fixmap,
>  };
>  
> +struct pv_pad_ops pv_pad_ops = {
> +	.acpi_pad_init = native_acpi_pad_init,
> +	.acpi_pad_exit = native_acpi_pad_exit,
> +};
> +
>  EXPORT_SYMBOL_GPL(pv_time_ops);
>  EXPORT_SYMBOL    (pv_cpu_ops);
>  EXPORT_SYMBOL    (pv_mmu_ops);
>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>  EXPORT_SYMBOL_GPL(pv_info);
>  EXPORT_SYMBOL    (pv_irq_ops);
> +EXPORT_SYMBOL_GPL(pv_pad_ops);
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index a43fa1a..3f0fd27 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -30,6 +30,7 @@
>  #include <linux/slab.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_pad.h>
>  #include <asm/mwait.h>
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> @@ -37,14 +38,14 @@
>  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>  static DEFINE_MUTEX(isolated_cpus_lock);
>  
> -static unsigned long power_saving_mwait_eax;
> +unsigned long power_saving_mwait_eax;
>  
>  static unsigned char tsc_detected_unstable;
>  static unsigned char tsc_marked_unstable;
>  static unsigned char lapic_detected_unstable;
>  static unsigned char lapic_marked_unstable;
>  
> -static void power_saving_mwait_init(void)
> +void power_saving_mwait_init(void)
>  {
>  	unsigned int eax, ebx, ecx, edx;
>  	unsigned int highest_cstate = 0;
> @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>  
> -static struct acpi_driver acpi_pad_driver = {
> +struct acpi_driver acpi_pad_driver = {
>  	.name = "processor_aggregator",
>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>  	.ids = pad_device_ids,
> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> -	power_saving_mwait_init();
> -	if (power_saving_mwait_eax == 0)
> -		return -EINVAL;
> -
> -	return acpi_bus_register_driver(&acpi_pad_driver);
> +	return __acpi_pad_init();
>  }
>  
>  static void __exit acpi_pad_exit(void)
>  {
> -	acpi_bus_unregister_driver(&acpi_pad_driver);
> +	__acpi_pad_exit();
>  }
>  
>  module_init(acpi_pad_init);
> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> new file mode 100644
> index 0000000..1a1471d
> --- /dev/null
> +++ b/include/acpi/acpi_pad.h
> @@ -0,0 +1,61 @@
> +/*
> + *  acpi_pad.h - pad device helper for native and paravirt platform
> + *
> + *  Copyright (C) 2012, Intel Corporation.
> + *     Author: 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.
> + */
> +
> +#ifndef __ACPI_PAD_H__
> +#define __ACPI_PAD_H__
> +
> +#include <acpi/acpi_bus.h>
> +
> +extern unsigned long power_saving_mwait_eax;
> +extern struct acpi_driver acpi_pad_driver;
> +extern void power_saving_mwait_init(void);
> +
> +static inline int native_acpi_pad_init(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	power_saving_mwait_init();
> +	if (power_saving_mwait_eax == 0)
> +		return -EINVAL;
> +
> +	return acpi_bus_register_driver(&acpi_pad_driver);
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static inline void native_acpi_pad_exit(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&acpi_pad_driver);
> +#endif
> +}
> +
> +#ifdef CONFIG_PARAVIRT
> +#include <asm/paravirt.h>
> +#else
> +static inline int __acpi_pad_init(void)
> +{
> +	return native_acpi_pad_init();
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	native_acpi_pad_exit();
> +}
> +#endif
> +
> +#endif /* __ACPI_PAD_H__ */
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyKgc-0008UK-KO; Fri, 17 Feb 2012 10:05:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyKga-0008UF-Ns
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 10:05:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1329473097!13706068!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4745 invoked from network); 17 Feb 2012 10:04:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 10:04:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 10:04:57 +0000
Message-Id: <4F3E345802000078000739B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 10:04:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Kerneldevelopment list <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.02.12 at 09:56, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops 
> accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch for 
> Xen
>  core parking.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   10 +++++
>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>  arch/x86/kernel/paravirt.c            |    9 +++++
>  drivers/acpi/acpi_pad.c               |   15 +++-----
>  include/acpi/acpi_pad.h               |   61 
> +++++++++++++++++++++++++++++++++
>  5 files changed, 93 insertions(+), 9 deletions(-)
>  create mode 100644 include/acpi/acpi_pad.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index a7d2db9..02e6df0 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
>  }
>  
> +static inline int __acpi_pad_init(void)
> +{
> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> +}

With this you, aiui, you aim at getting the calls patched. Are the callers
of this really on performance critical paths? If not, the simpler approach
of having an ops structure the fields of which get overwritten by
Xen initialization would seem a more appropriate approach.

Jan

> +
>  static inline void write_cr0(unsigned long x)
>  {
>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..61e20de 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -336,6 +336,11 @@ struct pv_lock_ops {
>  	void (*spin_unlock)(struct arch_spinlock *lock);
>  };
>  
> +struct pv_pad_ops {
> +	int (*acpi_pad_init)(void);
> +	void (*acpi_pad_exit)(void);
> +};
> +
>  /* This contains all the paravirt structures: we get a convenient
>   * number for each function using the offset which we use to indicate
>   * what to patch. */
> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>  	struct pv_apic_ops pv_apic_ops;
>  	struct pv_mmu_ops pv_mmu_ops;
>  	struct pv_lock_ops pv_lock_ops;
> +	struct pv_pad_ops pv_pad_ops;
>  };
>  
>  extern struct pv_info pv_info;
> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>  extern struct pv_apic_ops pv_apic_ops;
>  extern struct pv_mmu_ops pv_mmu_ops;
>  extern struct pv_lock_ops pv_lock_ops;
> +extern struct pv_pad_ops pv_pad_ops;
>  
>  #define PARAVIRT_PATCH(x)					\
>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index d90272e..ec778f6 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -38,6 +38,8 @@
>  #include <asm/tlbflush.h>
>  #include <asm/timer.h>
>  
> +#include <acpi/acpi_pad.h>
> +
>  /* nop stub */
>  void _paravirt_nop(void)
>  {
> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>  		.pv_lock_ops = pv_lock_ops,
>  #endif
> +		.pv_pad_ops = pv_pad_ops,
>  	};
>  	return *((void **)&tmpl + type);
>  }
> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>  	.set_fixmap = native_set_fixmap,
>  };
>  
> +struct pv_pad_ops pv_pad_ops = {
> +	.acpi_pad_init = native_acpi_pad_init,
> +	.acpi_pad_exit = native_acpi_pad_exit,
> +};
> +
>  EXPORT_SYMBOL_GPL(pv_time_ops);
>  EXPORT_SYMBOL    (pv_cpu_ops);
>  EXPORT_SYMBOL    (pv_mmu_ops);
>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>  EXPORT_SYMBOL_GPL(pv_info);
>  EXPORT_SYMBOL    (pv_irq_ops);
> +EXPORT_SYMBOL_GPL(pv_pad_ops);
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index a43fa1a..3f0fd27 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -30,6 +30,7 @@
>  #include <linux/slab.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_pad.h>
>  #include <asm/mwait.h>
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> @@ -37,14 +38,14 @@
>  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>  static DEFINE_MUTEX(isolated_cpus_lock);
>  
> -static unsigned long power_saving_mwait_eax;
> +unsigned long power_saving_mwait_eax;
>  
>  static unsigned char tsc_detected_unstable;
>  static unsigned char tsc_marked_unstable;
>  static unsigned char lapic_detected_unstable;
>  static unsigned char lapic_marked_unstable;
>  
> -static void power_saving_mwait_init(void)
> +void power_saving_mwait_init(void)
>  {
>  	unsigned int eax, ebx, ecx, edx;
>  	unsigned int highest_cstate = 0;
> @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>  
> -static struct acpi_driver acpi_pad_driver = {
> +struct acpi_driver acpi_pad_driver = {
>  	.name = "processor_aggregator",
>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>  	.ids = pad_device_ids,
> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> -	power_saving_mwait_init();
> -	if (power_saving_mwait_eax == 0)
> -		return -EINVAL;
> -
> -	return acpi_bus_register_driver(&acpi_pad_driver);
> +	return __acpi_pad_init();
>  }
>  
>  static void __exit acpi_pad_exit(void)
>  {
> -	acpi_bus_unregister_driver(&acpi_pad_driver);
> +	__acpi_pad_exit();
>  }
>  
>  module_init(acpi_pad_init);
> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> new file mode 100644
> index 0000000..1a1471d
> --- /dev/null
> +++ b/include/acpi/acpi_pad.h
> @@ -0,0 +1,61 @@
> +/*
> + *  acpi_pad.h - pad device helper for native and paravirt platform
> + *
> + *  Copyright (C) 2012, Intel Corporation.
> + *     Author: 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.
> + */
> +
> +#ifndef __ACPI_PAD_H__
> +#define __ACPI_PAD_H__
> +
> +#include <acpi/acpi_bus.h>
> +
> +extern unsigned long power_saving_mwait_eax;
> +extern struct acpi_driver acpi_pad_driver;
> +extern void power_saving_mwait_init(void);
> +
> +static inline int native_acpi_pad_init(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	power_saving_mwait_init();
> +	if (power_saving_mwait_eax == 0)
> +		return -EINVAL;
> +
> +	return acpi_bus_register_driver(&acpi_pad_driver);
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static inline void native_acpi_pad_exit(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&acpi_pad_driver);
> +#endif
> +}
> +
> +#ifdef CONFIG_PARAVIRT
> +#include <asm/paravirt.h>
> +#else
> +static inline int __acpi_pad_init(void)
> +{
> +	return native_acpi_pad_init();
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	native_acpi_pad_exit();
> +}
> +#endif
> +
> +#endif /* __ACPI_PAD_H__ */
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:22:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyKxI-0000Hc-6C; Fri, 17 Feb 2012 10:22: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 1RyKxG-0000HW-6z
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 10:22:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329474111!63917578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20796 invoked from network); 17 Feb 2012 10:21:51 -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;
	17 Feb 2012 10:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="10767519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 10:22:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 10:22:14 +0000
Message-ID: <1329474132.3131.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jim burns <jim_burn@bellsouth.net>
Date: Fri, 17 Feb 2012 10:22:12 +0000
In-Reply-To: <51142288.L1Ice6IuWj@dell4550>
References: <51142288.L1Ice6IuWj@dell4550>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Problems with stubdoms, and xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:
[...]
> 1) After my winxp hvm domu, started with a stubdom, got some windows
> updates yesterday, I restarted (not shutdown), and the new domain hung
> in pause:
[..]

I tried this with win7 on xen-unstable and it worked ok. This may be a
bug specific to 4.1.

[...]
> xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"

> and only got a syntax error on the '-d'.

I don't think this approach is advised but FWIW the error here is
probably lack of quoting of the " against the shell. You would have
needed 
	... extra=\" -d 8\"

> So my question is: is this a bug, and is it fixed in xen 4.2?

The failure to restart the stub DM when rebooting a VM is a bug, AFAICT
it is fixed in unstable and therefore will be fixed in 4.2.

I've not been able to spot a specific changeset with the fix, but there
was quite a lot to wade through.

> 2) I'm having a strange problem right after I get a xen update from
> rawhide: stubdoms stop working for a day after wards. It happened with
> fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at
> whether something in /var/lib/xen* changed.

Stop working for a day and then magically starts working? Or stops
working for a day until the next update?

> 3) Specifying vncviewer=1 will automatically start a vnc viewer for
> you
[...]
> 4) The 'localtime=1' option in your config is ignored by xl. This
> works with 
[...]
> The answer given to the two above problems at the time was essentially
> that they had not been implemented. Have they been implemented in xen
> 4.2 yet?

Not as far as I can tell with grep. Patches would be greatly
appreciated, these should be relatively simple issues for a newcomer to
tackle with only basic C required I think, I'd be glad to advise etc.

I'll add these as "nice to have" in the 4.2 TODO thread.

>  They are not mentioned in the xl.cfg documentation, which I assume is
> for 4.2:

Correct.

[...]
> Now for what does work to get a stubdom up and running. I used the
> below config, with python commented out to keep xl happy. Note the
> spice options, and 'device_model_stubdomain_override = 1' don't
> actually do anything (the latter contrary to what someone else
> reported). 

Yes, I think these are the 4.2 names, In 4.1 you likely need
	device_model = "stubdom-dm"

> I assume that they will become functional in xen 4.2.

Yes.

>  Also, while device_model_args does indeed add '-localtime' to the end
> of the qemu-dm args, it's still ineffective.

I'm not 100% sure of this but I don't think xm's "localtime" corresponds
to solely passing "-localtime" to the DM (although it may also do that
also).

I think it needs to turn into a hypercall to tell the hypervisor about
the guests time offset, e.g. a call to xc_domain_set_time_offset. The
rtc_timeoffset option relates to this call as well.

In a Xen system the RTC is emulated by the hypervisor not by qemu (it
used to be done by qemu many moons ago, which might explain the
vestigial passing of -localtime to qemu).

> And 2) If you have GPLPV installed in your domain, it completely takes
> over. Booting with GPLPV enabled is no faster with stubdoms as
> without. Booting with /nogplpv is just as slow as if you booted
> without stubdoms. I suspect xenpci.sys is overriding what stubdoms is
> doing.

If you are using PV devices then you won't be hitting the emulated
devices (which is what is in the stubdom) all that much after the very
early boot stages IOW after anything which uses BIOS int13 hook e.g. the
bootloader. If you aren't hitting the emulated devices then putting them
in stubdom vs dom0 won't make much odds to the performance.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:22:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyKxI-0000Hc-6C; Fri, 17 Feb 2012 10:22: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 1RyKxG-0000HW-6z
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 10:22:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329474111!63917578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20796 invoked from network); 17 Feb 2012 10:21:51 -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;
	17 Feb 2012 10:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="10767519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 10:22:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 10:22:14 +0000
Message-ID: <1329474132.3131.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jim burns <jim_burn@bellsouth.net>
Date: Fri, 17 Feb 2012 10:22:12 +0000
In-Reply-To: <51142288.L1Ice6IuWj@dell4550>
References: <51142288.L1Ice6IuWj@dell4550>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Problems with stubdoms, and xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:
[...]
> 1) After my winxp hvm domu, started with a stubdom, got some windows
> updates yesterday, I restarted (not shutdown), and the new domain hung
> in pause:
[..]

I tried this with win7 on xen-unstable and it worked ok. This may be a
bug specific to 4.1.

[...]
> xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"

> and only got a syntax error on the '-d'.

I don't think this approach is advised but FWIW the error here is
probably lack of quoting of the " against the shell. You would have
needed 
	... extra=\" -d 8\"

> So my question is: is this a bug, and is it fixed in xen 4.2?

The failure to restart the stub DM when rebooting a VM is a bug, AFAICT
it is fixed in unstable and therefore will be fixed in 4.2.

I've not been able to spot a specific changeset with the fix, but there
was quite a lot to wade through.

> 2) I'm having a strange problem right after I get a xen update from
> rawhide: stubdoms stop working for a day after wards. It happened with
> fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at
> whether something in /var/lib/xen* changed.

Stop working for a day and then magically starts working? Or stops
working for a day until the next update?

> 3) Specifying vncviewer=1 will automatically start a vnc viewer for
> you
[...]
> 4) The 'localtime=1' option in your config is ignored by xl. This
> works with 
[...]
> The answer given to the two above problems at the time was essentially
> that they had not been implemented. Have they been implemented in xen
> 4.2 yet?

Not as far as I can tell with grep. Patches would be greatly
appreciated, these should be relatively simple issues for a newcomer to
tackle with only basic C required I think, I'd be glad to advise etc.

I'll add these as "nice to have" in the 4.2 TODO thread.

>  They are not mentioned in the xl.cfg documentation, which I assume is
> for 4.2:

Correct.

[...]
> Now for what does work to get a stubdom up and running. I used the
> below config, with python commented out to keep xl happy. Note the
> spice options, and 'device_model_stubdomain_override = 1' don't
> actually do anything (the latter contrary to what someone else
> reported). 

Yes, I think these are the 4.2 names, In 4.1 you likely need
	device_model = "stubdom-dm"

> I assume that they will become functional in xen 4.2.

Yes.

>  Also, while device_model_args does indeed add '-localtime' to the end
> of the qemu-dm args, it's still ineffective.

I'm not 100% sure of this but I don't think xm's "localtime" corresponds
to solely passing "-localtime" to the DM (although it may also do that
also).

I think it needs to turn into a hypercall to tell the hypervisor about
the guests time offset, e.g. a call to xc_domain_set_time_offset. The
rtc_timeoffset option relates to this call as well.

In a Xen system the RTC is emulated by the hypervisor not by qemu (it
used to be done by qemu many moons ago, which might explain the
vestigial passing of -localtime to qemu).

> And 2) If you have GPLPV installed in your domain, it completely takes
> over. Booting with GPLPV enabled is no faster with stubdoms as
> without. Booting with /nogplpv is just as slow as if you booted
> without stubdoms. I suspect xenpci.sys is overriding what stubdoms is
> doing.

If you are using PV devices then you won't be hitting the emulated
devices (which is what is in the stubdom) all that much after the very
early boot stages IOW after anything which uses BIOS int13 hook e.g. the
bootloader. If you aren't hitting the emulated devices then putting them
in stubdom vs dom0 won't make much odds to the performance.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:24:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10: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.xensource.com>)
	id 1RyKye-0000OJ-B2; Fri, 17 Feb 2012 10:23:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyKyc-0000NR-Q0
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 10:23:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329474216!13773427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28201 invoked from network); 17 Feb 2012 10:23:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 10:23:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="10767565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 10:23:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 10:23:36 +0000
Message-ID: <1329474214.3131.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 10:23:34 +0000
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 10:17 +0000, Ian Campbell wrote:
> 
> tools, nice to have: 

Jim Burns reports that

	vncviewer=1 used to auto spawn a vnc viewer for you

and that

	localtime and rtc_timeoffset do not work with xl.

Both seem like worthwhile things to have in some form.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:24:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10: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.xensource.com>)
	id 1RyKye-0000OJ-B2; Fri, 17 Feb 2012 10:23:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyKyc-0000NR-Q0
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 10:23:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329474216!13773427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28201 invoked from network); 17 Feb 2012 10:23:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 10:23:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="10767565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 10:23:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 10:23:36 +0000
Message-ID: <1329474214.3131.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 10:23:34 +0000
In-Reply-To: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 10:17 +0000, Ian Campbell wrote:
> 
> tools, nice to have: 

Jim Burns reports that

	vncviewer=1 used to auto spawn a vnc viewer for you

and that

	localtime and rtc_timeoffset do not work with xl.

Both seem like worthwhile things to have in some form.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:29:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10:29:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyL3W-0000oI-8Z; Fri, 17 Feb 2012 10:28:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RyL3U-0000oD-JB
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 10:28:44 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329474449!63257155!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMzE2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31390 invoked from network); 17 Feb 2012 10:27:29 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-7.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 10:27:29 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ003TV93MWC@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:28:34 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ008A393K34@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:28:34 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGX54255; Fri,
	17 Feb 2012 18:28:10 +0800
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155)
	by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 18:27:59 +0800
Received: from h00166998 (10.166.80.196) by szxeml416-hub.china.huawei.com
	(10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Fri,
	17 Feb 2012 18:28:02 +0800
Date: Fri, 17 Feb 2012 18:28:01 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <1329466831.8012.6.camel@dagon.hellion.org.uk>
X-Originating-IP: [10.166.80.196]
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Message-id: <002401cced5e$d3cb3340$7b6199c0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AcztTSs0CmPIpvYkSZ+GmbTHimRFrgAEVEtA
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
	<1329298049.31256.277.camel@zakaz.uk.xensource.com>
	<004201cced3c$73b1baf0$5b1530d0$@com>
	<1329466831.8012.6.camel@dagon.hellion.org.uk>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, February 17, 2012 4:21 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> 
> On Fri, 2012-02-17 at 06:21 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Wednesday, February 15, 2012 5:27 PM
> > > To: Hongkaixing
> > > Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> > > hanweidong@huawei.com
> > > Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> > >
> > > On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > > > > how xenpaging works but why does paging need a domU event channel
> > > > > anyway? Surely paging is transparent to the guest.
> > > > >
> > > > > Or is this really a dom0<->Xen event channel which just appears to be
> > > > > assigned to the guest?
> > > >
> > > > In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> > > [...]
> > > > > Who assigns this remote domain port? Shouldn't it either be closed when
> > > > > the dom0 end is closed or retained such that it can be reused each time
> > > > > instead of leaking?
> > > >
> > > >   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> > > > and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> > > > leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.
> > >
> > > The two ends of that event channel are actually dom0 and Xen, because
> > > chn->xen_consumer is not NULL, even though the Xen end does live in the
> > > domU evtchn address space. It is not exactly dom0 and domU as you
> > > suggest, which is where my confused question arose.
> >
> >    See what xenpaging_init() does when xenpaging is launched:
> >    xc_mem_paging_enable() ---> this function allocate a event channel of domain U, the remote port is stored in
> paging->mem_event.shared_page->port
> >             |
> >             V
> >     Xc_event_bind_interdomain() --> this function bind dom0 with domU port allocated above
> >
> >    But when xenpaging is tear down:
> >    xc_mem_paging_disable()  -->  do nothing about event channel
> >             |
> >             V
> >    xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU )  ECS_UNBOUND
> 
> I wasn't querying the presence of the leak or the validity of the fix, I
> was asking what the domU event channel was even for (i.e. why does it
> exist at all?).

Sorry! The event channel is used to wake domU up when its page has already been paged in.

> 
> I answered that myself in my previous mail -- it's actually a Xen event
> channel not a guest visible one.
> 
> Ian.
> 
> >
> >
> >  Hong Kaixing.
> >
> > >
> > > Ian.
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 10:29:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 10:29:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyL3W-0000oI-8Z; Fri, 17 Feb 2012 10:28:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RyL3U-0000oD-JB
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 10:28:44 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329474449!63257155!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAzMzE2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31390 invoked from network); 17 Feb 2012 10:27:29 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-7.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 10:27:29 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ003TV93MWC@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:28:34 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LZJ008A393K34@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:28:34 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGX54255; Fri,
	17 Feb 2012 18:28:10 +0800
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155)
	by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 18:27:59 +0800
Received: from h00166998 (10.166.80.196) by szxeml416-hub.china.huawei.com
	(10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Fri,
	17 Feb 2012 18:28:02 +0800
Date: Fri, 17 Feb 2012 18:28:01 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <1329466831.8012.6.camel@dagon.hellion.org.uk>
X-Originating-IP: [10.166.80.196]
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Message-id: <002401cced5e$d3cb3340$7b6199c0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AcztTSs0CmPIpvYkSZ+GmbTHimRFrgAEVEtA
X-CFilter-Loop: Reflected
References: <9f4640e40d4f31563885.1328777634@h00166998.china.huawei.com>
	<20120210164010.GA10009@aepfle.de>
	<002201ccea12$e83c0420$b8b40c60$@com>
	<1329135113.31256.77.camel@zakaz.uk.xensource.com>
	<003001cceb88$f7302930$e5907b90$@com>
	<1329298049.31256.277.camel@zakaz.uk.xensource.com>
	<004201cced3c$73b1baf0$5b1530d0$@com>
	<1329466831.8012.6.camel@dagon.hellion.org.uk>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and
 free port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, February 17, 2012 4:21 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> 
> On Fri, 2012-02-17 at 06:21 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Wednesday, February 15, 2012 5:27 PM
> > > To: Hongkaixing
> > > Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> > > hanweidong@huawei.com
> > > Subject: RE: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> > >
> > > On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > > Perhaps I'm misunderstanding something and/or showing my ignorance about
> > > > > how xenpaging works but why does paging need a domU event channel
> > > > > anyway? Surely paging is transparent to the guest.
> > > > >
> > > > > Or is this really a dom0<->Xen event channel which just appears to be
> > > > > assigned to the guest?
> > > >
> > > > In xenpaging source code, there is an inter-domain event channel between dom0 and domU.
> > > [...]
> > > > > Who assigns this remote domain port? Shouldn't it either be closed when
> > > > > the dom0 end is closed or retained such that it can be reused each time
> > > > > instead of leaking?
> > > >
> > > >   In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU,
> > > > and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(),
> > > > leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits.
> > >
> > > The two ends of that event channel are actually dom0 and Xen, because
> > > chn->xen_consumer is not NULL, even though the Xen end does live in the
> > > domU evtchn address space. It is not exactly dom0 and domU as you
> > > suggest, which is where my confused question arose.
> >
> >    See what xenpaging_init() does when xenpaging is launched:
> >    xc_mem_paging_enable() ---> this function allocate a event channel of domain U, the remote port is stored in
> paging->mem_event.shared_page->port
> >             |
> >             V
> >     Xc_event_bind_interdomain() --> this function bind dom0 with domU port allocated above
> >
> >    But when xenpaging is tear down:
> >    xc_mem_paging_disable()  -->  do nothing about event channel
> >             |
> >             V
> >    xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU )  ECS_UNBOUND
> 
> I wasn't querying the presence of the leak or the validity of the fix, I
> was asking what the domU event channel was even for (i.e. why does it
> exist at all?).

Sorry! The event channel is used to wake domU up when its page has already been paged in.

> 
> I answered that myself in my previous mail -- it's actually a Xen event
> channel not a guest visible one.
> 
> Ian.
> 
> >
> >
> >  Hong Kaixing.
> >
> > >
> > > Ian.
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:06:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 11: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.xensource.com>)
	id 1RyLdv-0001bx-2g; Fri, 17 Feb 2012 11:06:23 +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 1RyLdt-0001bs-LF
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:06:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329476726!49680755!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25747 invoked from network); 17 Feb 2012 11:05:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 11:05:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyLdq-0003Ri-Lm
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 03:06:18 -0800
Date: Fri, 17 Feb 2012 03:06:18 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329476778668-5492170.post@n5.nabble.com>
In-Reply-To: <1329467829314-5491845.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBoYXZlIHRlc3RlZCBub3cgeGVuLXVuc3RhYmxlIHJldi4gMjQ4MjM6Yjc1NjY0ZTUzOTA1IGJ1
aWxkIG9uIFdoZWV6eSBhbmQgaXMKZmFpbGVkIHdpdGggc2FtZSBlcnJvcjoKLi4uCmdjYyAgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OQotV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50Ci1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU1N
RCAtTUYgLnhsX2NtZGltcGwuby5kIAotRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0
X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMKLVdlcnJvciAtV25vLWZvcm1hdC16
ZXJvLWxlbmd0aCAtV21pc3NpbmctZGVjbGFyYXRpb25zCi1Xbm8tZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1XZm9ybWF0LW5vbmxpdGVyYWwgLUkuIC1mUElDCi1ESEFWRV9ZQUpMX1ZFUlNJ
T04KLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwvLi4vLi4vdG9vbHMv
bGlieGMKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwvLi4vLi4vdG9v
bHMvaW5jbHVkZSAKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwvLi4v
Li4vdG9vbHMvbGlieGwKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwv
Li4vLi4vdG9vbHMvbGlieGMKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGli
eGwvLi4vLi4vdG9vbHMvaW5jbHVkZQotSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9saWJ4bC8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbwp4bF9jbWRpbXBsLm8geGxfY21kaW1w
bC5jIAp4bF9jbWRpbXBsLmM6IEluIGZ1bmN0aW9uIMOicHJpbnRmX2luZm/DojoKeGxfY21kaW1w
bC5jOjMwMDo1OiBlcnJvcjogc3RhdGVtZW50IHdpdGggbm8gZWZmZWN0IFstV2Vycm9yPXVudXNl
ZC12YWx1ZV0KeGxfY21kaW1wbC5jOjMwMDoyMTogZXJyb3I6IGV4cGVjdGVkIMOiO8OiIGJlZm9y
ZSDDomNvbmbDogp4bF9jbWRpbXBsLmM6MzA2OjI4OiBlcnJvcjogw6Jjb25mw6IgdW5kZWNsYXJl
ZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCnhsX2NtZGltcGwuYzozMDY6Mjg6IG5vdGU6
IGVhY2ggdW5kZWNsYXJlZCBpZGVudGlmaWVyIGlzIHJlcG9ydGVkIG9ubHkgb25jZQpmb3IgZWFj
aCBmdW5jdGlvbiBpdCBhcHBlYXJzIGluCnhsX2NtZGltcGwuYzozMDY6NTogZXJyb3I6IHRvbyBt
YW55IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDDonlhamxfZ2VuX2FsbG9jw6IKL3Vzci9pbmNsdWRl
L3lhamwveWFqbF9nZW4uaDoxMTg6MjM6IG5vdGU6IGRlY2xhcmVkIGhlcmUKeGxfY21kaW1wbC5j
OjMzOTo1OiBlcnJvcjogcGFzc2luZyBhcmd1bWVudCAzIG9mIMOieWFqbF9nZW5fZ2V0X2J1ZsOi
IGZyb20KaW5jb21wYXRpYmxlIHBvaW50ZXIgdHlwZSBbLVdlcnJvcl0KL3Vzci9pbmNsdWRlL3lh
amwveWFqbF9nZW4uaDoxNDQ6MzA6IG5vdGU6IGV4cGVjdGVkIMOic2l6ZV90ICrDoiBidXQgYXJn
dW1lbnQKaXMgb2YgdHlwZSDDonVuc2lnbmVkIGludCAqw6IKY2MxOiBhbGwgd2FybmluZ3MgYmVp
bmcgdHJlYXRlZCBhcyBlcnJvcnMKCm1ha2VbM106ICoqKiBbeGxfY21kaW1wbC5vXSBFcnJvciAx
Cm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGwnCm1ha2VbMl06ICoqKiBbc3ViZGlyLWluc3RhbGwtbGlieGxdIEVycm9yIDIK
bWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scycKbWFrZVsxXTogKioqIFtzdWJkaXJzLWluc3RhbGxdIEVycm9yIDIKbWFrZVsxXTogTGVh
dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycKbWFrZTog
KioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyCgpJZiBjYW4gaGVscCBJIGF0dGFjaCBhbHNvIGZ1
bGwgYnVpbGQgbG9nOiAKaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vZmlsZS9uNTQ5
MjE3MC94ZW5idWlsZC5sb2cgeGVuYnVpbGQubG9nIAoKSSB0cmllZCB0byBzb2x2ZSBmYXN0IHRo
ZSBwcm9ibGVtIGZvciBjb250aW51ZSB3aXRoIGFsc28gc3BpY2UgYnVpbGQgYnV0IEkKbm90IGJl
ZW4gYWJsZSB0byBmaXggdGhpcyBwcm9ibGVtLgoKVGhhbmtzIGZvciBhbnkgcmVwbHkgYW5kIHNv
cnJ5IGZvciBiYWQgZW5nbGlzaC4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0
dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL3hsLWNtZGltcGwtYy1lcnJvcnMtdHA1NDkx
NTM3cDU0OTIxNzAuaHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJj
aGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:06:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 11: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.xensource.com>)
	id 1RyLdv-0001bx-2g; Fri, 17 Feb 2012 11:06:23 +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 1RyLdt-0001bs-LF
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:06:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329476726!49680755!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25747 invoked from network); 17 Feb 2012 11:05:27 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 11:05:27 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyLdq-0003Ri-Lm
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 03:06:18 -0800
Date: Fri, 17 Feb 2012 03:06:18 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329476778668-5492170.post@n5.nabble.com>
In-Reply-To: <1329467829314-5491845.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBoYXZlIHRlc3RlZCBub3cgeGVuLXVuc3RhYmxlIHJldi4gMjQ4MjM6Yjc1NjY0ZTUzOTA1IGJ1
aWxkIG9uIFdoZWV6eSBhbmQgaXMKZmFpbGVkIHdpdGggc2FtZSBlcnJvcjoKLi4uCmdjYyAgLU8x
IC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXN0
ZD1nbnU5OQotV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3Rh
dGVtZW50Ci1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUgICAtRF9fWEVOX1RPT0xTX18gLU1N
RCAtTUYgLnhsX2NtZGltcGwuby5kIAotRF9MQVJHRUZJTEVfU09VUkNFIC1EX0xBUkdFRklMRTY0
X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMKLVdlcnJvciAtV25vLWZvcm1hdC16
ZXJvLWxlbmd0aCAtV21pc3NpbmctZGVjbGFyYXRpb25zCi1Xbm8tZGVjbGFyYXRpb24tYWZ0ZXIt
c3RhdGVtZW50IC1XZm9ybWF0LW5vbmxpdGVyYWwgLUkuIC1mUElDCi1ESEFWRV9ZQUpMX1ZFUlNJ
T04KLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwvLi4vLi4vdG9vbHMv
bGlieGMKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwvLi4vLi4vdG9v
bHMvaW5jbHVkZSAKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwvLi4v
Li4vdG9vbHMvbGlieGwKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGlieGwv
Li4vLi4vdG9vbHMvbGlieGMKLUkvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvbGli
eGwvLi4vLi4vdG9vbHMvaW5jbHVkZQotSS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29s
cy9saWJ4bC8uLi8uLi90b29scy9pbmNsdWRlICAtYyAtbwp4bF9jbWRpbXBsLm8geGxfY21kaW1w
bC5jIAp4bF9jbWRpbXBsLmM6IEluIGZ1bmN0aW9uIMOicHJpbnRmX2luZm/DojoKeGxfY21kaW1w
bC5jOjMwMDo1OiBlcnJvcjogc3RhdGVtZW50IHdpdGggbm8gZWZmZWN0IFstV2Vycm9yPXVudXNl
ZC12YWx1ZV0KeGxfY21kaW1wbC5jOjMwMDoyMTogZXJyb3I6IGV4cGVjdGVkIMOiO8OiIGJlZm9y
ZSDDomNvbmbDogp4bF9jbWRpbXBsLmM6MzA2OjI4OiBlcnJvcjogw6Jjb25mw6IgdW5kZWNsYXJl
ZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCnhsX2NtZGltcGwuYzozMDY6Mjg6IG5vdGU6
IGVhY2ggdW5kZWNsYXJlZCBpZGVudGlmaWVyIGlzIHJlcG9ydGVkIG9ubHkgb25jZQpmb3IgZWFj
aCBmdW5jdGlvbiBpdCBhcHBlYXJzIGluCnhsX2NtZGltcGwuYzozMDY6NTogZXJyb3I6IHRvbyBt
YW55IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDDonlhamxfZ2VuX2FsbG9jw6IKL3Vzci9pbmNsdWRl
L3lhamwveWFqbF9nZW4uaDoxMTg6MjM6IG5vdGU6IGRlY2xhcmVkIGhlcmUKeGxfY21kaW1wbC5j
OjMzOTo1OiBlcnJvcjogcGFzc2luZyBhcmd1bWVudCAzIG9mIMOieWFqbF9nZW5fZ2V0X2J1ZsOi
IGZyb20KaW5jb21wYXRpYmxlIHBvaW50ZXIgdHlwZSBbLVdlcnJvcl0KL3Vzci9pbmNsdWRlL3lh
amwveWFqbF9nZW4uaDoxNDQ6MzA6IG5vdGU6IGV4cGVjdGVkIMOic2l6ZV90ICrDoiBidXQgYXJn
dW1lbnQKaXMgb2YgdHlwZSDDonVuc2lnbmVkIGludCAqw6IKY2MxOiBhbGwgd2FybmluZ3MgYmVp
bmcgdHJlYXRlZCBhcyBlcnJvcnMKCm1ha2VbM106ICoqKiBbeGxfY21kaW1wbC5vXSBFcnJvciAx
Cm1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcv
dG9vbHMvbGlieGwnCm1ha2VbMl06ICoqKiBbc3ViZGlyLWluc3RhbGwtbGlieGxdIEVycm9yIDIK
bWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90
b29scycKbWFrZVsxXTogKioqIFtzdWJkaXJzLWluc3RhbGxdIEVycm9yIDIKbWFrZVsxXTogTGVh
dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycKbWFrZTog
KioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyCgpJZiBjYW4gaGVscCBJIGF0dGFjaCBhbHNvIGZ1
bGwgYnVpbGQgbG9nOiAKaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vZmlsZS9uNTQ5
MjE3MC94ZW5idWlsZC5sb2cgeGVuYnVpbGQubG9nIAoKSSB0cmllZCB0byBzb2x2ZSBmYXN0IHRo
ZSBwcm9ibGVtIGZvciBjb250aW51ZSB3aXRoIGFsc28gc3BpY2UgYnVpbGQgYnV0IEkKbm90IGJl
ZW4gYWJsZSB0byBmaXggdGhpcyBwcm9ibGVtLgoKVGhhbmtzIGZvciBhbnkgcmVwbHkgYW5kIHNv
cnJ5IGZvciBiYWQgZW5nbGlzaC4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0
dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL3hsLWNtZGltcGwtYy1lcnJvcnMtdHA1NDkx
NTM3cDU0OTIxNzAuaHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJj
aGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:33:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyM3A-0001ru-90; Fri, 17 Feb 2012 11:32:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RyM38-0001rp-Rz
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:32:27 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329478339!13347295!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5515 invoked from network); 17 Feb 2012 11:32:20 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 11:32:20 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RyM31-0007yy-8e
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 03:32:19 -0800
Date: Fri, 17 Feb 2012 03:32:19 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329478339260-5492208.post@n5.nabble.com>
In-Reply-To: <201202170934.41725.tobias.geiger@vido.info>
References: <1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Tobias, thank you for the answer.

The * on my cfg appear because I used bold letter there.(They dont exists on
my real cfg)

In order to install the driver I need to see the graphic card in my Windows
DomU, so I must passed through the card first right? 
So I used the options 'pci =  [ '01:00.0' ]' and 'gfx_passthru=1' to
passthru the card, but when I do this (after bind the device with pci-stub)
I just can see (through VNC) a screen with qemu console and after a while
the DomU crash. When u said before that it is not possible to see the DomU
with VNC I thought that I should use a monitor attached to the graphic card
but Im not sure how to do that.

Anyway Im start thinking that the DomU crash is due to VT-d is not enabled
properly, after using the parameter iommu=1 i have the following output in
xl dmesg:

(XEN) I/O virtualisation enabled
.
.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled. 
(XEN) Intel VT-d Shared EPT table not enabled.

So maybe the problem is there... 

Well thank you for your help


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5492208.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:33:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyM3A-0001ru-90; Fri, 17 Feb 2012 11:32:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RyM38-0001rp-Rz
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:32:27 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329478339!13347295!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5515 invoked from network); 17 Feb 2012 11:32:20 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 11:32:20 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RyM31-0007yy-8e
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 03:32:19 -0800
Date: Fri, 17 Feb 2012 03:32:19 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329478339260-5492208.post@n5.nabble.com>
In-Reply-To: <201202170934.41725.tobias.geiger@vido.info>
References: <1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Tobias, thank you for the answer.

The * on my cfg appear because I used bold letter there.(They dont exists on
my real cfg)

In order to install the driver I need to see the graphic card in my Windows
DomU, so I must passed through the card first right? 
So I used the options 'pci =  [ '01:00.0' ]' and 'gfx_passthru=1' to
passthru the card, but when I do this (after bind the device with pci-stub)
I just can see (through VNC) a screen with qemu console and after a while
the DomU crash. When u said before that it is not possible to see the DomU
with VNC I thought that I should use a monitor attached to the graphic card
but Im not sure how to do that.

Anyway Im start thinking that the DomU crash is due to VT-d is not enabled
properly, after using the parameter iommu=1 i have the following output in
xl dmesg:

(XEN) I/O virtualisation enabled
.
.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation not enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled. 
(XEN) Intel VT-d Shared EPT table not enabled.

So maybe the problem is there... 

Well thank you for your help


--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5492208.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:37:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 11:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyM7G-00020o-Uj; Fri, 17 Feb 2012 11:36:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RyM7E-00020R-Sv
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:36:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329478593!13781465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17312 invoked from network); 17 Feb 2012 11:36:34 -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;
	17 Feb 2012 11:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10769478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 11:36:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 11:36:33 +0000
Date: Fri, 17 Feb 2012 11:41:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano.Stabellini@eu.citrix.com, sandr8@gmail.com
Subject: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Forwarding this email to xen-devel with a proper subject.


---------- Forwarded message ----------
Stefano,

   after a few days running traffic, we are seeing that one of the
linux netdevice txqueues has gone into a frozen state and any packet
that you give from there onwards is always queued to a softqueue and
is never put into the xen-netfront txqueue...

it also looks like xen-netfront is not registering a timeout callback
and this may lead to a crash if the callback ever gets invoked.

do you happen to know if this has been seen before and if there was a
fix for it?

we are currently running with linux-3.0.9.

Thank you!
-Alessandro-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:37:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 11:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyM7G-00020o-Uj; Fri, 17 Feb 2012 11:36:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RyM7E-00020R-Sv
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:36:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329478593!13781465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17312 invoked from network); 17 Feb 2012 11:36:34 -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;
	17 Feb 2012 11:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10769478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 11:36:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 11:36:33 +0000
Date: Fri, 17 Feb 2012 11:41:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano.Stabellini@eu.citrix.com, sandr8@gmail.com
Subject: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Forwarding this email to xen-devel with a proper subject.


---------- Forwarded message ----------
Stefano,

   after a few days running traffic, we are seeing that one of the
linux netdevice txqueues has gone into a frozen state and any packet
that you give from there onwards is always queued to a softqueue and
is never put into the xen-netfront txqueue...

it also looks like xen-netfront is not registering a timeout callback
and this may lead to a crash if the callback ever gets invoked.

do you happen to know if this has been seen before and if there was a
fix for it?

we are currently running with linux-3.0.9.

Thank you!
-Alessandro-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:41:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyMB9-0002Ab-KY; Fri, 17 Feb 2012 11:40:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RyMB7-0002AR-G9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:40:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329478831!13772666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3422 invoked from network); 17 Feb 2012 11:40:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 11:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10769592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 11:40:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 11:40:31 +0000
Date: Fri, 17 Feb 2012 11:45:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 17 Feb 2012, Shriram Rajagopalan wrote:
> 
> On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       Introduce a new save_id to save/restore toolstack specific extra
>       information.
> 
>       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> 
> cc-ing Ian Jackson.
> These patches (and other follow ups including mine) have been acked.
> Ian, are there any issues blocking these patches ?

The issue are the QEMU side acks. Let me ask them again for feedback.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:41:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyMB9-0002Ab-KY; Fri, 17 Feb 2012 11:40:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RyMB7-0002AR-G9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:40:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329478831!13772666!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3422 invoked from network); 17 Feb 2012 11:40:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 11:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10769592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 11:40:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 11:40:31 +0000
Date: Fri, 17 Feb 2012 11:45:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 17 Feb 2012, Shriram Rajagopalan wrote:
> 
> On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       Introduce a new save_id to save/restore toolstack specific extra
>       information.
> 
>       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> 
> cc-ing Ian Jackson.
> These patches (and other follow ups including mine) have been acked.
> Ian, are there any issues blocking these patches ?

The issue are the QEMU side acks. Let me ask them again for feedback.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyMF5-0002JJ-9j; Fri, 17 Feb 2012 11:44:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RyMF3-0002J3-Mr
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:44:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329479078!6437484!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21089 invoked from network); 17 Feb 2012 11:44:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 11:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325480400"; d="scan'208";a="22186061"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 06:44:18 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	06:44:18 -0500
Message-ID: <4F3E3D91.7020605@citrix.com>
Date: Fri, 17 Feb 2012 11:44:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

XenServer had an issue which looked a little like this.

The fix was
http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
if you are using PV guests then this is certainly not the same issue.

~Andrew

On 17/02/12 11:41, Stefano Stabellini wrote:
> Forwarding this email to xen-devel with a proper subject.
>
>
> ---------- Forwarded message ----------
> Stefano,
>
>    after a few days running traffic, we are seeing that one of the
> linux netdevice txqueues has gone into a frozen state and any packet
> that you give from there onwards is always queued to a softqueue and
> is never put into the xen-netfront txqueue...
>
> it also looks like xen-netfront is not registering a timeout callback
> and this may lead to a crash if the callback ever gets invoked.
>
> do you happen to know if this has been seen before and if there was a
> fix for it?
>
> we are currently running with linux-3.0.9.
>
> Thank you!
> -Alessandro-
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyMF5-0002JJ-9j; Fri, 17 Feb 2012 11:44:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RyMF3-0002J3-Mr
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:44:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329479078!6437484!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21089 invoked from network); 17 Feb 2012 11:44:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 11:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325480400"; d="scan'208";a="22186061"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 06:44:18 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	06:44:18 -0500
Message-ID: <4F3E3D91.7020605@citrix.com>
Date: Fri, 17 Feb 2012 11:44:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

XenServer had an issue which looked a little like this.

The fix was
http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
if you are using PV guests then this is certainly not the same issue.

~Andrew

On 17/02/12 11:41, Stefano Stabellini wrote:
> Forwarding this email to xen-devel with a proper subject.
>
>
> ---------- Forwarded message ----------
> Stefano,
>
>    after a few days running traffic, we are seeing that one of the
> linux netdevice txqueues has gone into a frozen state and any packet
> that you give from there onwards is always queued to a softqueue and
> is never put into the xen-netfront txqueue...
>
> it also looks like xen-netfront is not registering a timeout callback
> and this may lead to a crash if the callback ever gets invoked.
>
> do you happen to know if this has been seen before and if there was a
> fix for it?
>
> we are currently running with linux-3.0.9.
>
> Thank you!
> -Alessandro-
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:59:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 11:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMTI-0002ZU-OH; Fri, 17 Feb 2012 11:59:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RyMTH-0002ZP-D4
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:59:27 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329479957!13718984!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27569 invoked from network); 17 Feb 2012 11:59:19 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 11:59:19 -0000
Received: by vbbfq11 with SMTP id fq11so5644139vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 03:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=CNa8SajhzeZkBSy5gPBjb4UvMPo2Qqg5NkX8SHyFsn0=;
	b=nN2yxS/rq0I2P0s3/YZsOKABGCo0isRBBfNyGBmM3TfClyYtTTXpQl4UAlGSfZX65B
	0zytHvxdznaLmJuhrK5ENUKlA0MAwT0n8112fOX5f7bC8wO8zwoQ8GKAj+LZ8Z75PIpr
	ownuX4R+qjM+PJKgdTmPDP/gGzuV7yZSbM8/g=
MIME-Version: 1.0
Received: by 10.220.228.73 with SMTP id jd9mr3795886vcb.58.1329479957222; Fri,
	17 Feb 2012 03:59:17 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Fri, 17 Feb 2012 03:59:17 -0800 (PST)
In-Reply-To: <1329468155.8012.27.camel@dagon.hellion.org.uk>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
	<1329390815.5975.7.camel@zakaz.uk.xensource.com>
	<CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
	<1329468155.8012.27.camel@dagon.hellion.org.uk>
Date: Fri, 17 Feb 2012 20:59:17 +0900
Message-ID: <CAP2B85_fd9WUBsfq0uaN9N1d2PdmQRvrfHUn9rOYvQ9yi7vVvA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 5:42 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> VOn Thu, 2012-02-16 at 22:52 +0000, Daniel Castro wrote:
>> On Thu, Feb 16, 2012 at 8:13 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
>> >> Hello All,
>> >>
>> >> When a HVM guest is started upstream qemu presents the emulated drives
>> >> as PCI devices or ata drives?
>> >
>> >> If more than drive is present how can I know which drive is which in =
xenstore?
>> >
>> > Emulated devices do not appear in xenstore.
>> >
>> > Some PV devices may have an emulated equivalent but the rule of thumb =
is
>> > that an OS should only use either PV or Emulated devices and not mix a=
nd
>> > match.
>> >
>> > In Linux we implement this by requiring that the emulated devices are
>> > unplugged before we will use the PV path.
>> >
>> > In principal you can infer which Emulated device might matches a PV
>> > device, the file docs/misc/vbd-interface.txt in the xen tree gives some
>> > hints about this, but basically PV disks 0..3 can correspond to the
>> > first four IDE devices (primary-master, primary-slave, secondary-master
>> > & secondary-slave).
>> >
>> > I presume you are asking in the context of SeaBIOS. In that context you
>> > could argue against unplugging because the guest OS may want to use
>> > emulated devices, however I would suggest that for simplicity for time
>> > being you just unplug the emulated devices before you enable the PV
>> > path.
>> Thanks for the response Ian, I am not sure I understand you. What I do
>> is something similar to this:
>> Find the emulated devices.
>
> Why? You don't need these in your Xen code.
>
> If anything is going to enumerate these devices it will be the existing
> SeaBIOS code which drive the emulated devices. There is no need for you
> to touch that.
>
>> =A0ATA Devices are the drives and the PCI device is for what?
>
> You are referring to the Xen platform device (5853:0001)?. This device
> has nothing to do with the emulated disks.
>
> The platform device just serves as a useful point to hook the Xen driver
> loading off since many OSes handle autoloading of PCI drivers well so we
> use it to trigger the loading of Xen drivers.
>
> It has some secondary purposes such as the IRQ associated with this
> device can also be used to inject event channels and the unplug protocol
> happens via I/O ports on this device.
>
>> Find if the device is a disk. (in the context of a vbd the xenstore id
>> corresponds to what?)
>
> The meaning of the VBD number (e.g. 832 and 985 in your examples below)
> is described by the document I pointed you at in my last mail:
> docs/misc/vbd-interface.txt.
>
>> If disk, then find corresponding entry on xenstore. Example
>> device/vbd/832, device/vbd/985
>
> You should enumerate (using XS_DIRECTORY) the device/vbd directory. Each
> entry you find in there is a disk. There is no need for you to go
> anywhere near the emulated disk devices to do this, nor to establish any
> correspondence with the emulated devices. You know they are all vbds
> because you found them in device/vbd.
>
> The sequence of events should be:
>
> =A0 =A0 =A0* Notice that you are running under Xen and that the platform =
PCI
> =A0 =A0 =A0 =A0device is present. You most likely want to do this by using
> =A0 =A0 =A0 =A0pci_find_init_device() to register a callback for the plat=
form
> =A0 =A0 =A0 =A0device. If you never get a callback then there is nothing =
for
> =A0 =A0 =A0 =A0you to do and you should assume standard SeaBIOS drivers e=
tc
> =A0 =A0 =A0 =A0will take care of the emulated devices.
> =A0 =A0 =A0* Unplug all of the emulated devices per the protocol defined =
in
> =A0 =A0 =A0 =A0docs/misc/hvm-emulated-unplug.markdown. You do not need to
> =A0 =A0 =A0 =A0enumerate the emulated devices to do this. If this fails t=
hen
> =A0 =A0 =A0 =A0abort and assume standard SeaBIOS drivers etc will take ca=
re of
> =A0 =A0 =A0 =A0the emulated devices.
> =A0 =A0 =A0* Enumerate the contents of device/vbd in xenstore, for each d=
isk:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* parse the disk and partition number per
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0docs/misc/vbd-interface.txt,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "Write device details to xenstore -rings, re=
f, etc" and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0do the necessary xenbus state transitions =
to get into
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state 4 (XenBusConnected)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* create and register the appropriate disk dev=
ice
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0structures with SeaBIOS.
>
> In the future once all this is working then there may be extensions such
> as not unplugging devices and ensuring the safe coexistence of the
> emulated and PV devices but you can leave that to one side for now since
> there are other issues with doing that (c.f. previous discussions about
> how to safely shutdown the PV devices after SeaBIOS is finished).
>
> Ian.
Thanks a million Ian. Perfectly clear now, I will get on to it then.
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 11:59:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 11:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMTI-0002ZU-OH; Fri, 17 Feb 2012 11:59:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evil.dani@gmail.com>) id 1RyMTH-0002ZP-D4
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 11:59:27 +0000
X-Env-Sender: evil.dani@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329479957!13718984!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27569 invoked from network); 17 Feb 2012 11:59:19 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 11:59:19 -0000
Received: by vbbfq11 with SMTP id fq11so5644139vbb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 03:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=CNa8SajhzeZkBSy5gPBjb4UvMPo2Qqg5NkX8SHyFsn0=;
	b=nN2yxS/rq0I2P0s3/YZsOKABGCo0isRBBfNyGBmM3TfClyYtTTXpQl4UAlGSfZX65B
	0zytHvxdznaLmJuhrK5ENUKlA0MAwT0n8112fOX5f7bC8wO8zwoQ8GKAj+LZ8Z75PIpr
	ownuX4R+qjM+PJKgdTmPDP/gGzuV7yZSbM8/g=
MIME-Version: 1.0
Received: by 10.220.228.73 with SMTP id jd9mr3795886vcb.58.1329479957222; Fri,
	17 Feb 2012 03:59:17 -0800 (PST)
Received: by 10.220.7.80 with HTTP; Fri, 17 Feb 2012 03:59:17 -0800 (PST)
In-Reply-To: <1329468155.8012.27.camel@dagon.hellion.org.uk>
References: <CAP2B85_Je6ZeMfqh5sYUy3pLjM=LzptnkqariM+Z6vzY4kqs2g@mail.gmail.com>
	<1329390815.5975.7.camel@zakaz.uk.xensource.com>
	<CAP2B85-CtXs5coXDzxWowkjEbucBWry+QzJk1eB_MbcCDWsEgQ@mail.gmail.com>
	<1329468155.8012.27.camel@dagon.hellion.org.uk>
Date: Fri, 17 Feb 2012 20:59:17 +0900
Message-ID: <CAP2B85_fd9WUBsfq0uaN9N1d2PdmQRvrfHUn9rOYvQ9yi7vVvA@mail.gmail.com>
From: Daniel Castro <evil.dani@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Qemu upstream drive question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 5:42 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> VOn Thu, 2012-02-16 at 22:52 +0000, Daniel Castro wrote:
>> On Thu, Feb 16, 2012 at 8:13 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Thu, 2012-02-16 at 10:53 +0000, Daniel Castro wrote:
>> >> Hello All,
>> >>
>> >> When a HVM guest is started upstream qemu presents the emulated drives
>> >> as PCI devices or ata drives?
>> >
>> >> If more than drive is present how can I know which drive is which in =
xenstore?
>> >
>> > Emulated devices do not appear in xenstore.
>> >
>> > Some PV devices may have an emulated equivalent but the rule of thumb =
is
>> > that an OS should only use either PV or Emulated devices and not mix a=
nd
>> > match.
>> >
>> > In Linux we implement this by requiring that the emulated devices are
>> > unplugged before we will use the PV path.
>> >
>> > In principal you can infer which Emulated device might matches a PV
>> > device, the file docs/misc/vbd-interface.txt in the xen tree gives some
>> > hints about this, but basically PV disks 0..3 can correspond to the
>> > first four IDE devices (primary-master, primary-slave, secondary-master
>> > & secondary-slave).
>> >
>> > I presume you are asking in the context of SeaBIOS. In that context you
>> > could argue against unplugging because the guest OS may want to use
>> > emulated devices, however I would suggest that for simplicity for time
>> > being you just unplug the emulated devices before you enable the PV
>> > path.
>> Thanks for the response Ian, I am not sure I understand you. What I do
>> is something similar to this:
>> Find the emulated devices.
>
> Why? You don't need these in your Xen code.
>
> If anything is going to enumerate these devices it will be the existing
> SeaBIOS code which drive the emulated devices. There is no need for you
> to touch that.
>
>> =A0ATA Devices are the drives and the PCI device is for what?
>
> You are referring to the Xen platform device (5853:0001)?. This device
> has nothing to do with the emulated disks.
>
> The platform device just serves as a useful point to hook the Xen driver
> loading off since many OSes handle autoloading of PCI drivers well so we
> use it to trigger the loading of Xen drivers.
>
> It has some secondary purposes such as the IRQ associated with this
> device can also be used to inject event channels and the unplug protocol
> happens via I/O ports on this device.
>
>> Find if the device is a disk. (in the context of a vbd the xenstore id
>> corresponds to what?)
>
> The meaning of the VBD number (e.g. 832 and 985 in your examples below)
> is described by the document I pointed you at in my last mail:
> docs/misc/vbd-interface.txt.
>
>> If disk, then find corresponding entry on xenstore. Example
>> device/vbd/832, device/vbd/985
>
> You should enumerate (using XS_DIRECTORY) the device/vbd directory. Each
> entry you find in there is a disk. There is no need for you to go
> anywhere near the emulated disk devices to do this, nor to establish any
> correspondence with the emulated devices. You know they are all vbds
> because you found them in device/vbd.
>
> The sequence of events should be:
>
> =A0 =A0 =A0* Notice that you are running under Xen and that the platform =
PCI
> =A0 =A0 =A0 =A0device is present. You most likely want to do this by using
> =A0 =A0 =A0 =A0pci_find_init_device() to register a callback for the plat=
form
> =A0 =A0 =A0 =A0device. If you never get a callback then there is nothing =
for
> =A0 =A0 =A0 =A0you to do and you should assume standard SeaBIOS drivers e=
tc
> =A0 =A0 =A0 =A0will take care of the emulated devices.
> =A0 =A0 =A0* Unplug all of the emulated devices per the protocol defined =
in
> =A0 =A0 =A0 =A0docs/misc/hvm-emulated-unplug.markdown. You do not need to
> =A0 =A0 =A0 =A0enumerate the emulated devices to do this. If this fails t=
hen
> =A0 =A0 =A0 =A0abort and assume standard SeaBIOS drivers etc will take ca=
re of
> =A0 =A0 =A0 =A0the emulated devices.
> =A0 =A0 =A0* Enumerate the contents of device/vbd in xenstore, for each d=
isk:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* parse the disk and partition number per
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0docs/misc/vbd-interface.txt,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* "Write device details to xenstore -rings, re=
f, etc" and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0do the necessary xenbus state transitions =
to get into
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state 4 (XenBusConnected)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* create and register the appropriate disk dev=
ice
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0structures with SeaBIOS.
>
> In the future once all this is working then there may be extensions such
> as not unplugging devices and ensuring the safe coexistence of the
> emulated and PV devices but you can leave that to one side for now since
> there are other issues with doing that (c.f. previous discussions about
> how to safely shutdown the PV devices after SeaBIOS is finished).
>
> Ian.
Thanks a million Ian. Perfectly clear now, I will get on to it then.
>
>



-- =

+-=3D=3D=3D=3D=3D---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| |=A0=A0 | Consultant/Programmer.|
| |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:02:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyMVb-0002ly-Vm; Fri, 17 Feb 2012 12:01: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 1RyMVa-0002lo-Rh
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:01:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329480084!53338349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30268 invoked from network); 17 Feb 2012 12:01:25 -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;
	17 Feb 2012 12:01:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:01:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:01:48 +0000
Message-ID: <1329480107.3131.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 17 Feb 2012 12:01:47 +0000
In-Reply-To: <1329476778668-5492170.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 11:06 +0000, Fantu wrote:
> I have tested now xen-unstable rev. 24823:b75664e53905 build on Wheezy and is
> failed with same error:

It seems that Olaf's fix to xl (<patchbomb.1328791978@probook.site>)
isn't in the tree yet, only Roger's fix to libxl is. I presume it is in
IanJ's queue and will committed in the fullness of time.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:02:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyMVb-0002ly-Vm; Fri, 17 Feb 2012 12:01: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 1RyMVa-0002lo-Rh
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:01:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329480084!53338349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30268 invoked from network); 17 Feb 2012 12:01:25 -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;
	17 Feb 2012 12:01:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:01:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:01:48 +0000
Message-ID: <1329480107.3131.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 17 Feb 2012 12:01:47 +0000
In-Reply-To: <1329476778668-5492170.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 11:06 +0000, Fantu wrote:
> I have tested now xen-unstable rev. 24823:b75664e53905 build on Wheezy and is
> failed with same error:

It seems that Olaf's fix to xl (<patchbomb.1328791978@probook.site>)
isn't in the tree yet, only Roger's fix to libxl is. I presume it is in
IanJ's queue and will committed in the fullness of time.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:04:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:04:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMYI-0002wP-Jp; Fri, 17 Feb 2012 12:04:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyMYH-0002w7-3H
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:04:37 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329480269!13776548!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzQ0OTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1832 invoked from network); 17 Feb 2012 12:04:30 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 12:04:30 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1HC3j8u019909;
	Fri, 17 Feb 2012 07:03:45 -0500
Date: Fri, 17 Feb 2012 07:03:45 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <432bdad6-a4f5-44ff-9de6-ccb34f70e1ac@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120216194422.GA8023@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.11.9.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after
	getting it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> > We should hang onto bdev until we're done with it.
> 
> Looks ok. Is there a BZ that sparked this? Thanks.

Nope. Just came across it while I was looking at the code.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/block/xen-blkfront.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c
> > b/drivers/block/xen-blkfront.c
> > index 2f22874..5d45688 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk
> > *disk, fmode_t mode)
> >  	mutex_lock(&blkfront_mutex);
> >  
> >  	bdev = bdget_disk(disk, 0);
> > -	bdput(bdev);
> >  
> >  	if (bdev->bd_openers)
> >  		goto out;
> > @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk
> > *disk, fmode_t mode)
> >  	}
> >  
> >  out:
> > +	bdput(bdev);
> >  	mutex_unlock(&blkfront_mutex);
> >  	return 0;
> >  }
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:04:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:04:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMYI-0002wP-Jp; Fri, 17 Feb 2012 12:04:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyMYH-0002w7-3H
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:04:37 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329480269!13776548!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzQ0OTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1832 invoked from network); 17 Feb 2012 12:04:30 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 12:04:30 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1HC3j8u019909;
	Fri, 17 Feb 2012 07:03:45 -0500
Date: Fri, 17 Feb 2012 07:03:45 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <432bdad6-a4f5-44ff-9de6-ccb34f70e1ac@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120216194422.GA8023@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.11.9.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after
	getting it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> > We should hang onto bdev until we're done with it.
> 
> Looks ok. Is there a BZ that sparked this? Thanks.

Nope. Just came across it while I was looking at the code.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/block/xen-blkfront.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c
> > b/drivers/block/xen-blkfront.c
> > index 2f22874..5d45688 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk
> > *disk, fmode_t mode)
> >  	mutex_lock(&blkfront_mutex);
> >  
> >  	bdev = bdget_disk(disk, 0);
> > -	bdput(bdev);
> >  
> >  	if (bdev->bd_openers)
> >  		goto out;
> > @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk
> > *disk, fmode_t mode)
> >  	}
> >  
> >  out:
> > +	bdput(bdev);
> >  	mutex_unlock(&blkfront_mutex);
> >  	return 0;
> >  }
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:06:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMZm-00033s-4J; Fri, 17 Feb 2012 12:06: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 1RyMZl-00033g-GT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:06:09 +0000
Received: from [85.158.139.83:29467] by server-8.bemta-5.messagelabs.com id
	CB/2F-09797-0B24E3F4; Fri, 17 Feb 2012 12:06:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329480367!15482097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9336 invoked from network); 17 Feb 2012 12:06:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:06:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:06:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:06:06 +0000
Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Qrux <qrux.qed@gmail.com>
Date: Fri, 17 Feb 2012 12:06:05 +0000
In-Reply-To: <A4D2CFC5-7B9D-4EBD-BDBC-58D6B35FCF6C@gmail.com>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
	<20120214155738.GC21610@andromeda.dapyr.net>
	<1329236393.31256.267.camel@zakaz.uk.xensource.com>
	<A4D2CFC5-7B9D-4EBD-BDBC-58D6B35FCF6C@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm afraid I don't know the answer to most of your questions (hence I'm
afraid I've trimmed the quotes rather aggressively) but here's some of
what I do know.

> But, practically, is there a safe CPU configuration? 

I think that part of the problem here is that it is very hard to
determine this at the hardware level. There are at least 3 (if not more)
CPUID feature bits which say "no really, the TSC is good and safe to use
this time, you can rely on that" because they keep inventing new ways to
get it wrong.

[...]
> 
> Since September, I can't find any further information about this
> issue. What is the state of this issue?  The inconsistency I see right
> now is this: in the July 2010 TSC discussion, a "Stefano Stabellini"
> posted this:
> 
> ====
> > /me wonders if timer_mode=1 is the default for xl?
> > Or only for xm?
> 
> no, it is not.
> Xl defaults to 0 [zero], I am going to change it right now.
> ====
> 
> So, it seems like (at least as of July 2010), xl is defaulting to
> "timer_mode=1".  That is, assuming that the then-current timer_mode is
> the same as present-day tsc_mode.

No, I believe they are different things.

tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)

timer_mode is to do with the the way that timer interrupts are injected
into the guest. This is described in xen/include/public/hvm/params.h.
This isn't documented in xl.cfg(5) because I couldn't make head nor tail
of the meaning of that header :-(

>   In addition, I'm assuming he was changing it from 0 (zero) to 1
> (one)--and not some other mode.  But,
> 
>         xen-4.1.2/docs/misc/tscmode.txt

Remember that he was referring to timer_mode not tsc_mode...

> says:
> 
>         "The default mode (tsc_mode==0) checks TSC-safeness of the underlying
>         hardware on which the virtual machine is launched.  If it is
>         TSC-safe, rdtsc will execute at hardware speed; if it is not, rdtsc
>         will be emulated."
> 
> Which implies the default is always 0 (zero).  Which is it?

It seems that xl, in xen-unstable, defaults to:
	timer_mode = 1
	tsc_mode = 0
as does 4.1 as far as I can tell via code inspection.

> More importantly, is the solution to force tsc_mode=2?

IMHO this is safe in most situations unless you are running some sort of
workload (e.g. a well known database) which has stringent requirements
regarding the TSC for transactional consistency (hence the conservative
default).

>   If so, under what BIOS/xen-boot-params/dom0-boot-params conditions?
> And--please excuse my exasperation--but WTH does this have to do with
> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
> "jumpiness" (if that's even what's happening)?

Sorry, I have no idea how/why the filesystem would be related to the
TSC.

It is possible you are actually seeing two bugs I suppose -- there have
been issues relating to ext4 and barriers in some kernel versions (I'm
afraid I don't recall the details, the list archives ought to contain
something).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:06:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMZm-00033s-4J; Fri, 17 Feb 2012 12:06: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 1RyMZl-00033g-GT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:06:09 +0000
Received: from [85.158.139.83:29467] by server-8.bemta-5.messagelabs.com id
	CB/2F-09797-0B24E3F4; Fri, 17 Feb 2012 12:06:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329480367!15482097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9336 invoked from network); 17 Feb 2012 12:06:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:06:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:06:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:06:06 +0000
Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Qrux <qrux.qed@gmail.com>
Date: Fri, 17 Feb 2012 12:06:05 +0000
In-Reply-To: <A4D2CFC5-7B9D-4EBD-BDBC-58D6B35FCF6C@gmail.com>
References: <81DF6A67-0306-422B-B6FC-12888A53D05D@gmail.com>
	<20120214155738.GC21610@andromeda.dapyr.net>
	<1329236393.31256.267.camel@zakaz.uk.xensource.com>
	<A4D2CFC5-7B9D-4EBD-BDBC-58D6B35FCF6C@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm afraid I don't know the answer to most of your questions (hence I'm
afraid I've trimmed the quotes rather aggressively) but here's some of
what I do know.

> But, practically, is there a safe CPU configuration? 

I think that part of the problem here is that it is very hard to
determine this at the hardware level. There are at least 3 (if not more)
CPUID feature bits which say "no really, the TSC is good and safe to use
this time, you can rely on that" because they keep inventing new ways to
get it wrong.

[...]
> 
> Since September, I can't find any further information about this
> issue. What is the state of this issue?  The inconsistency I see right
> now is this: in the July 2010 TSC discussion, a "Stefano Stabellini"
> posted this:
> 
> ====
> > /me wonders if timer_mode=1 is the default for xl?
> > Or only for xm?
> 
> no, it is not.
> Xl defaults to 0 [zero], I am going to change it right now.
> ====
> 
> So, it seems like (at least as of July 2010), xl is defaulting to
> "timer_mode=1".  That is, assuming that the then-current timer_mode is
> the same as present-day tsc_mode.

No, I believe they are different things.

tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)

timer_mode is to do with the the way that timer interrupts are injected
into the guest. This is described in xen/include/public/hvm/params.h.
This isn't documented in xl.cfg(5) because I couldn't make head nor tail
of the meaning of that header :-(

>   In addition, I'm assuming he was changing it from 0 (zero) to 1
> (one)--and not some other mode.  But,
> 
>         xen-4.1.2/docs/misc/tscmode.txt

Remember that he was referring to timer_mode not tsc_mode...

> says:
> 
>         "The default mode (tsc_mode==0) checks TSC-safeness of the underlying
>         hardware on which the virtual machine is launched.  If it is
>         TSC-safe, rdtsc will execute at hardware speed; if it is not, rdtsc
>         will be emulated."
> 
> Which implies the default is always 0 (zero).  Which is it?

It seems that xl, in xen-unstable, defaults to:
	timer_mode = 1
	tsc_mode = 0
as does 4.1 as far as I can tell via code inspection.

> More importantly, is the solution to force tsc_mode=2?

IMHO this is safe in most situations unless you are running some sort of
workload (e.g. a well known database) which has stringent requirements
regarding the TSC for transactional consistency (hence the conservative
default).

>   If so, under what BIOS/xen-boot-params/dom0-boot-params conditions?
> And--please excuse my exasperation--but WTH does this have to do with
> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
> "jumpiness" (if that's even what's happening)?

Sorry, I have no idea how/why the filesystem would be related to the
TSC.

It is possible you are actually seeing two bugs I suppose -- there have
been issues relating to ext4 and barriers in some kernel versions (I'm
afraid I don't recall the details, the list archives ought to contain
something).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:06:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMaA-00036r-HZ; Fri, 17 Feb 2012 12:06:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1RyMa8-00036C-KR
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:06:32 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329480385!8634904!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16170 invoked from network); 17 Feb 2012 12:06:26 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:06:26 -0000
Received: by wgbdr13 with SMTP id dr13so2385236wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 04:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:reply-to:to:date:content-type:x-mailer
	:content-transfer-encoding:mime-version;
	bh=Hll/az6XE0CQUWv4M1NlB2hYx/Mhxm70TXeJAPOHpLY=;
	b=bWX4JB4SAu+7DntcnVBqlbD1InYK3jR1oJkqdxyVJY9zktY6UB6wpGjn6QRd8z8GVN
	OljGpr9cRavMSW95h2l3OTE/tEXof3GFGEVockCyY5Jtd5fm/LqYezIBfLFiYC5sxQ6g
	4lupgojtNpasRSycoXBvQF4chrVHJp4pVBmiY=
Received: by 10.216.134.37 with SMTP id r37mr3067388wei.38.1329480385215;
	Fri, 17 Feb 2012 04:06:25 -0800 (PST)
Received: from [192.168.1.140]
	(host170-152-static.43-88-b.business.telecomitalia.it.
	[88.43.152.170])
	by mx.google.com with ESMTPS id em6sm4625124wib.5.2012.02.17.04.06.24
	(version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 04:06:24 -0800 (PST)
Message-ID: <1329480334.4815.12.camel@ironlight2.geaaru.homelinux.net>
From: "Ge@@ru" <geaaru@gmail.com>
To: Xen-Devel ML <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 13:05:34 +0100
X-Mailer: Evolution 3.2.3 
Mime-Version: 1.0
Subject: [Xen-devel]  Dom0 with kernel 3.x and nvidia driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have a problem on use nvidia driver inside xen-dom0 kernel, version
3.x (I do test with this version: 3.0.18, 3.1.5, 3.2.5.

Compilation of the driver is done without errors and yet load of the
kernel driver is done correctly, but when I try to start X... I have
first a black screen and then monitor that go on standby status. It
seems that video card doesn't initialize correctly vga port.

I don't think that problem is on xorg server and I don't understand if
problem is on nvidia kernel driver because, same xorg-server, same
kernel image and same nvidia kernel module works fine if kernel is
bootstrap without xen hypervisor.

Could be relative to a wrong configuration on pass-through of the video
card bus from hypervisor to dom0 ? Is it correct speak of pass-through
yet on dom0 or pass-through is only for domU domain?

Same nvidia kernel driver works correctly on dom0 if I use
kernel-2.6.38-xen (gentoo ebuild).

Any suggestions ?

Thanks in advance





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:06:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMaA-00036r-HZ; Fri, 17 Feb 2012 12:06:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <geaaru@gmail.com>) id 1RyMa8-00036C-KR
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:06:32 +0000
X-Env-Sender: geaaru@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329480385!8634904!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16170 invoked from network); 17 Feb 2012 12:06:26 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:06:26 -0000
Received: by wgbdr13 with SMTP id dr13so2385236wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 04:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:reply-to:to:date:content-type:x-mailer
	:content-transfer-encoding:mime-version;
	bh=Hll/az6XE0CQUWv4M1NlB2hYx/Mhxm70TXeJAPOHpLY=;
	b=bWX4JB4SAu+7DntcnVBqlbD1InYK3jR1oJkqdxyVJY9zktY6UB6wpGjn6QRd8z8GVN
	OljGpr9cRavMSW95h2l3OTE/tEXof3GFGEVockCyY5Jtd5fm/LqYezIBfLFiYC5sxQ6g
	4lupgojtNpasRSycoXBvQF4chrVHJp4pVBmiY=
Received: by 10.216.134.37 with SMTP id r37mr3067388wei.38.1329480385215;
	Fri, 17 Feb 2012 04:06:25 -0800 (PST)
Received: from [192.168.1.140]
	(host170-152-static.43-88-b.business.telecomitalia.it.
	[88.43.152.170])
	by mx.google.com with ESMTPS id em6sm4625124wib.5.2012.02.17.04.06.24
	(version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 04:06:24 -0800 (PST)
Message-ID: <1329480334.4815.12.camel@ironlight2.geaaru.homelinux.net>
From: "Ge@@ru" <geaaru@gmail.com>
To: Xen-Devel ML <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 13:05:34 +0100
X-Mailer: Evolution 3.2.3 
Mime-Version: 1.0
Subject: [Xen-devel]  Dom0 with kernel 3.x and nvidia driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: geaaru@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have a problem on use nvidia driver inside xen-dom0 kernel, version
3.x (I do test with this version: 3.0.18, 3.1.5, 3.2.5.

Compilation of the driver is done without errors and yet load of the
kernel driver is done correctly, but when I try to start X... I have
first a black screen and then monitor that go on standby status. It
seems that video card doesn't initialize correctly vga port.

I don't think that problem is on xorg server and I don't understand if
problem is on nvidia kernel driver because, same xorg-server, same
kernel image and same nvidia kernel module works fine if kernel is
bootstrap without xen hypervisor.

Could be relative to a wrong configuration on pass-through of the video
card bus from hypervisor to dom0 ? Is it correct speak of pass-through
yet on dom0 or pass-through is only for domU domain?

Same nvidia kernel driver works correctly on dom0 if I use
kernel-2.6.38-xen (gentoo ebuild).

Any suggestions ?

Thanks in advance





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:11:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMeF-0003Qu-83; Fri, 17 Feb 2012 12:10:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RyMeD-0003QY-AI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:10:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329480638!15283737!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10920 invoked from network); 17 Feb 2012 12:10:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:10:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325480400"; d="scan'208";a="22186512"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 07:10:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 07:10:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1HCAZoe007784;
	Fri, 17 Feb 2012 04:10:36 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 12:10:28 +0000
Message-ID: <1329480628-27341-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] xen: add more files generated in
	xen/arch/x86/efi to .gitignore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

These files were already listed in .hgignore.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 .gitignore |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4df6c20..d1a503b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -282,6 +282,9 @@ xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
 xen/arch/x86/boot/reloc.S
+xen/arch/x86/efi.lds
+xen/arch/x86/efi/disabled
+xen/arch/x86/efi/mkreloc
 xen/ddb/*
 xen/include/headers.chk
 xen/include/asm
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:11:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMeF-0003Qu-83; Fri, 17 Feb 2012 12:10:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RyMeD-0003QY-AI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:10:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329480638!15283737!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10920 invoked from network); 17 Feb 2012 12:10:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:10:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325480400"; d="scan'208";a="22186512"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 07:10:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 07:10:37 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1HCAZoe007784;
	Fri, 17 Feb 2012 04:10:36 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 12:10:28 +0000
Message-ID: <1329480628-27341-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] xen: add more files generated in
	xen/arch/x86/efi to .gitignore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

These files were already listed in .hgignore.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 .gitignore |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4df6c20..d1a503b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -282,6 +282,9 @@ xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
 xen/arch/x86/boot/reloc.S
+xen/arch/x86/efi.lds
+xen/arch/x86/efi/disabled
+xen/arch/x86/efi/mkreloc
 xen/ddb/*
 xen/include/headers.chk
 xen/include/asm
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:11:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMeU-0003SC-L2; Fri, 17 Feb 2012 12:11:02 +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 1RyMeS-0003RT-A1
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:11:00 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329480629!53340041!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2942 invoked from network); 17 Feb 2012 12:10:30 -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;
	17 Feb 2012 12:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325480400"; d="scan'208";a="22186513"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 07:10:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 07:10:52 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1HCAp8O007787;
	Fri, 17 Feb 2012 04:10:51 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 12:10:42 +0000
Message-ID: <1329480642-27378-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>,
	Santosh Jodh <santosh.jodh@citrix.com>
Subject: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

alloca() does not return NULL on an allocation failure so remove the
unneccessary tests.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Santosh Jodh <santosh.jodh@citrix.com>
---
 tools/libxc/xc_linux_osdep.c |   79 ++++++++++++++++++------------------------
 1 files changed, 34 insertions(+), 45 deletions(-)

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 779fcd7..896f5c1 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -243,63 +243,54 @@ static void *linux_privcmd_map_foreign_bulk(xc_interface *xch, xc_osdep_handle h
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
+        privcmd_mmapbatch_t ioctlx;
         xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
 
-        if ( pfn )
-        {
-            privcmd_mmapbatch_t ioctlx;
-
-            memcpy(pfn, arr, num * sizeof(*arr));
+        memcpy(pfn, arr, num * sizeof(*arr));
 
-            ioctlx.num = num;
-            ioctlx.dom = dom;
-            ioctlx.addr = (unsigned long)addr;
-            ioctlx.arr = pfn;
+        ioctlx.num = num;
+        ioctlx.dom = dom;
+        ioctlx.addr = (unsigned long)addr;
+        ioctlx.arr = pfn;
 
-            rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
+        rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
 
-            rc = rc < 0 ? -errno : 0;
+        rc = rc < 0 ? -errno : 0;
 
-            for ( i = 0; i < num; ++i )
+        for ( i = 0; i < num; ++i )
+        {
+            switch ( pfn[i] ^ arr[i] )
             {
-                switch ( pfn[i] ^ arr[i] )
+            case 0:
+                err[i] = rc != -ENOENT ? rc : 0;
+                continue;
+            default:
+                err[i] = -EINVAL;
+                continue;
+            case XEN_DOMCTL_PFINFO_PAGEDTAB:
+                if ( rc != -ENOENT )
                 {
-                case 0:
-                    err[i] = rc != -ENOENT ? rc : 0;
+                    err[i] = rc ?: -EINVAL;
                     continue;
-                default:
-                    err[i] = -EINVAL;
-                    continue;
-                case XEN_DOMCTL_PFINFO_PAGEDTAB:
-                    if ( rc != -ENOENT )
-                    {
-                        err[i] = rc ?: -EINVAL;
-                        continue;
-                    }
-                    rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
+                 }
+                rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
                         (unsigned long)addr + ((unsigned long)i<<XC_PAGE_SHIFT));
-                    if ( rc < 0 )
-                    {
-                        rc = -errno;
-                        break;
-                    }
-                    rc = -ENOENT;
-                    continue;
+                if ( rc < 0 )
+                {
+                    rc = -errno;
+                    break;
                 }
-                break;
-            }
-
-            if ( rc == -ENOENT && i == num )
-                rc = 0;
-            else if ( rc )
-            {
-                errno = -rc;
-                rc = -1;
+                rc = -ENOENT;
+                continue;
             }
+            break;
         }
-        else
+
+        if ( rc == -ENOENT && i == num )
+            rc = 0;
+        else if ( rc )
         {
-            errno = -ENOMEM;
+            errno = -rc;
             rc = -1;
         }
     }
@@ -525,8 +516,6 @@ static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h,
 
     map = alloca(sizeof(*map) +
                  (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
-    if ( map == NULL )
-        return NULL;
 
     for ( i = 0; i < count; i++ )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:11:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMeU-0003SC-L2; Fri, 17 Feb 2012 12:11:02 +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 1RyMeS-0003RT-A1
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:11:00 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329480629!53340041!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2942 invoked from network); 17 Feb 2012 12:10:30 -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;
	17 Feb 2012 12:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325480400"; d="scan'208";a="22186513"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 07:10:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 07:10:52 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1HCAp8O007787;
	Fri, 17 Feb 2012 04:10:51 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 12:10:42 +0000
Message-ID: <1329480642-27378-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>,
	Santosh Jodh <santosh.jodh@citrix.com>
Subject: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

alloca() does not return NULL on an allocation failure so remove the
unneccessary tests.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Santosh Jodh <santosh.jodh@citrix.com>
---
 tools/libxc/xc_linux_osdep.c |   79 ++++++++++++++++++------------------------
 1 files changed, 34 insertions(+), 45 deletions(-)

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 779fcd7..896f5c1 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -243,63 +243,54 @@ static void *linux_privcmd_map_foreign_bulk(xc_interface *xch, xc_osdep_handle h
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
          * IOCTL_PRIVCMD_MMAPBATCH.
          */
+        privcmd_mmapbatch_t ioctlx;
         xen_pfn_t *pfn = alloca(num * sizeof(*pfn));
 
-        if ( pfn )
-        {
-            privcmd_mmapbatch_t ioctlx;
-
-            memcpy(pfn, arr, num * sizeof(*arr));
+        memcpy(pfn, arr, num * sizeof(*arr));
 
-            ioctlx.num = num;
-            ioctlx.dom = dom;
-            ioctlx.addr = (unsigned long)addr;
-            ioctlx.arr = pfn;
+        ioctlx.num = num;
+        ioctlx.dom = dom;
+        ioctlx.addr = (unsigned long)addr;
+        ioctlx.arr = pfn;
 
-            rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
+        rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
 
-            rc = rc < 0 ? -errno : 0;
+        rc = rc < 0 ? -errno : 0;
 
-            for ( i = 0; i < num; ++i )
+        for ( i = 0; i < num; ++i )
+        {
+            switch ( pfn[i] ^ arr[i] )
             {
-                switch ( pfn[i] ^ arr[i] )
+            case 0:
+                err[i] = rc != -ENOENT ? rc : 0;
+                continue;
+            default:
+                err[i] = -EINVAL;
+                continue;
+            case XEN_DOMCTL_PFINFO_PAGEDTAB:
+                if ( rc != -ENOENT )
                 {
-                case 0:
-                    err[i] = rc != -ENOENT ? rc : 0;
+                    err[i] = rc ?: -EINVAL;
                     continue;
-                default:
-                    err[i] = -EINVAL;
-                    continue;
-                case XEN_DOMCTL_PFINFO_PAGEDTAB:
-                    if ( rc != -ENOENT )
-                    {
-                        err[i] = rc ?: -EINVAL;
-                        continue;
-                    }
-                    rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
+                 }
+                rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
                         (unsigned long)addr + ((unsigned long)i<<XC_PAGE_SHIFT));
-                    if ( rc < 0 )
-                    {
-                        rc = -errno;
-                        break;
-                    }
-                    rc = -ENOENT;
-                    continue;
+                if ( rc < 0 )
+                {
+                    rc = -errno;
+                    break;
                 }
-                break;
-            }
-
-            if ( rc == -ENOENT && i == num )
-                rc = 0;
-            else if ( rc )
-            {
-                errno = -rc;
-                rc = -1;
+                rc = -ENOENT;
+                continue;
             }
+            break;
         }
-        else
+
+        if ( rc == -ENOENT && i == num )
+            rc = 0;
+        else if ( rc )
         {
-            errno = -ENOMEM;
+            errno = -rc;
             rc = -1;
         }
     }
@@ -525,8 +516,6 @@ static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h,
 
     map = alloca(sizeof(*map) +
                  (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
-    if ( map == NULL )
-        return NULL;
 
     for ( i = 0; i < count; i++ )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:18:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMlN-0003mn-IW; Fri, 17 Feb 2012 12:18:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyMlM-0003mi-Aj
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:18:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329481082!17106315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25689 invoked from network); 17 Feb 2012 12:18:02 -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;
	17 Feb 2012 12:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770612"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:18:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:18:02 +0000
Message-ID: <1329481080.3131.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:18:00 +0000
In-Reply-To: <1329308673-30175-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_dom_arm.c.
> Provide empty implementations of xc_domain_save and xc_domain_restore
> when CONFIG_MIGRATE is not set.
> Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
> x86 specific, introduce xc_hvm_build_arm.c with empty stubs.
> 
> 
> Changes in v3:
> 
> - rename xc_hvm_build.c to xc_hvm_build_x86.c;
> 
> - remove xc_nohvm, introduce xc_hvm_build_arm.c instead;
> 
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:18:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMlN-0003mn-IW; Fri, 17 Feb 2012 12:18:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyMlM-0003mi-Aj
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:18:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329481082!17106315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25689 invoked from network); 17 Feb 2012 12:18:02 -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;
	17 Feb 2012 12:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770612"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:18:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:18:02 +0000
Message-ID: <1329481080.3131.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:18:00 +0000
In-Reply-To: <1329308673-30175-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_dom_arm.c.
> Provide empty implementations of xc_domain_save and xc_domain_restore
> when CONFIG_MIGRATE is not set.
> Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
> x86 specific, introduce xc_hvm_build_arm.c with empty stubs.
> 
> 
> Changes in v3:
> 
> - rename xc_hvm_build.c to xc_hvm_build_x86.c;
> 
> - remove xc_nohvm, introduce xc_hvm_build_arm.c instead;
> 
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:19:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMmv-0003tl-1w; Fri, 17 Feb 2012 12:19: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 1RyMmt-0003sN-Cz
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:19:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329481154!63937209!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25062 invoked from network); 17 Feb 2012 12:19:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:19:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:19:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:19:36 +0000
Message-ID: <1329481175.3131.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:19:35 +0000
In-Reply-To: <1329308673-30175-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> Introduce an arch specific internal domain creation function. At the
> moment only x86 provides an implementation.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Assuming this really is mostly code motion as it appears then:
Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:19:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMmv-0003tl-1w; Fri, 17 Feb 2012 12:19: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 1RyMmt-0003sN-Cz
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:19:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329481154!63937209!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25062 invoked from network); 17 Feb 2012 12:19:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:19:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:19:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:19:36 +0000
Message-ID: <1329481175.3131.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:19:35 +0000
In-Reply-To: <1329308673-30175-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> Introduce an arch specific internal domain creation function. At the
> moment only x86 provides an implementation.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Assuming this really is mostly code motion as it appears then:
Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:21:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMo0-000407-Lf; Fri, 17 Feb 2012 12:20:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyMnz-0003zb-5D
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329481243!8760335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21160 invoked from network); 17 Feb 2012 12:20:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:20:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770688"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:20:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:20:43 +0000
Message-ID: <1329481241.3131.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:20:41 +0000
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 12:23 +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series allows tools/ to compile on ARM, mostly providing an
> empty implementation for all the arch specific functions that are needed.

I think I've acked (or authored) everything here. Since the majority of
the actual meat is changes or movement of non-ARM related code I'll
leave it to IanJ to actually commit.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:21:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMo0-000407-Lf; Fri, 17 Feb 2012 12:20:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyMnz-0003zb-5D
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329481243!8760335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21160 invoked from network); 17 Feb 2012 12:20:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:20:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770688"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:20:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:20:43 +0000
Message-ID: <1329481241.3131.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:20:41 +0000
In-Reply-To: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/7] arm: compile tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 12:23 +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series allows tools/ to compile on ARM, mostly providing an
> empty implementation for all the arch specific functions that are needed.

I think I've acked (or authored) everything here. Since the majority of
the actual meat is changes or movement of non-ARM related code I'll
leave it to IanJ to actually commit.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:21:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMoR-00043S-2g; Fri, 17 Feb 2012 12:21:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyMoP-00042h-Lu
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 12:21:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329481271!14969607!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26398 invoked from network); 17 Feb 2012 12:21:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 12:21:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 12:21:10 +0000
Message-Id: <4F3E54470200007800073A25@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 12:21:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part78560427.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/drivers/xen/: constify all
 instances of "struct attribute_group"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part78560427.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The functions these get passed to have been taking pointers to const
since at least 2.6.16.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/balloon/sysfs.c
+++ b/drivers/xen/balloon/sysfs.c
@@ -97,7 +97,7 @@ static struct attribute *balloon_info_at
 	NULL
 };
=20
-static struct attribute_group balloon_info_group =3D {
+static const struct attribute_group balloon_info_group =3D {
 	.name =3D "info",
 	.attrs =3D balloon_info_attrs,
 };
--- a/drivers/xen/blkback/xenbus.c
+++ b/drivers/xen/blkback/xenbus.c
@@ -136,7 +136,7 @@ static struct attribute *vbdstat_attrs[]
 	NULL
 };
=20
-static struct attribute_group vbdstat_group =3D {
+static const struct attribute_group vbdstat_group =3D {
 	.name =3D "statistics",
 	.attrs =3D vbdstat_attrs,
 };
--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -152,7 +152,7 @@ static struct attribute *tapstat_attrs[]
 	NULL
 };
=20
-static struct attribute_group tapstat_group =3D {
+static const struct attribute_group tapstat_group =3D {
 	.name =3D "statistics",
 	.attrs =3D tapstat_attrs,
 };
--- a/drivers/xen/core/xen_sysfs.c
+++ b/drivers/xen/core/xen_sysfs.c
@@ -84,7 +84,7 @@ static struct attribute *version_attrs[]
 	NULL
 };
=20
-static struct attribute_group version_group =3D {
+static const struct attribute_group version_group =3D {
 	.name =3D "version",
 	.attrs =3D version_attrs,
 };
@@ -197,12 +197,12 @@ static struct attribute *xen_compile_att
 	NULL
 };
=20
-static struct attribute_group xen_compilation_group =3D {
+static const struct attribute_group xen_compilation_group =3D {
 	.name =3D "compilation",
 	.attrs =3D xen_compile_attrs,
 };
=20
-int __init static xen_compilation_init(void)
+static int __init xen_compilation_init(void)
 {
 	return sysfs_create_group(&hypervisor_subsys.kset.kobj,
 				  &xen_compilation_group);
@@ -318,7 +318,7 @@ static struct attribute *xen_properties_
 	NULL
 };
=20
-static struct attribute_group xen_properties_group =3D {
+static const struct attribute_group xen_properties_group =3D {
 	.name =3D "properties",
 	.attrs =3D xen_properties_attrs,
 };




--=__Part78560427.0__=
Content-Type: text/plain; name="xen-const-attribute_group.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-const-attribute_group.patch"

drivers/xen/: constify all instances of "struct attribute_group"=0A=0AThe =
functions these get passed to have been taking pointers to const=0Asince =
at least 2.6.16.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A-=
-- a/drivers/xen/balloon/sysfs.c=0A+++ b/drivers/xen/balloon/sysfs.c=0A@@ =
-97,7 +97,7 @@ static struct attribute *balloon_info_at=0A 	NULL=0A =
};=0A =0A-static struct attribute_group balloon_info_group =3D {=0A+static =
const struct attribute_group balloon_info_group =3D {=0A 	.name =3D =
"info",=0A 	.attrs =3D balloon_info_attrs,=0A };=0A--- a/drivers/xen/bl=
kback/xenbus.c=0A+++ b/drivers/xen/blkback/xenbus.c=0A@@ -136,7 +136,7 @@ =
static struct attribute *vbdstat_attrs[]=0A 	NULL=0A };=0A =0A-static =
struct attribute_group vbdstat_group =3D {=0A+static const struct =
attribute_group vbdstat_group =3D {=0A 	.name =3D "statistics",=0A 	=
.attrs =3D vbdstat_attrs,=0A };=0A--- a/drivers/xen/blktap/xenbus.c=0A+++ =
b/drivers/xen/blktap/xenbus.c=0A@@ -152,7 +152,7 @@ static struct =
attribute *tapstat_attrs[]=0A 	NULL=0A };=0A =0A-static struct attribute_g=
roup tapstat_group =3D {=0A+static const struct attribute_group tapstat_gro=
up =3D {=0A 	.name =3D "statistics",=0A 	.attrs =3D tapstat_attrs,=
=0A };=0A--- a/drivers/xen/core/xen_sysfs.c=0A+++ b/drivers/xen/core/xen_sy=
sfs.c=0A@@ -84,7 +84,7 @@ static struct attribute *version_attrs[]=0A 	=
NULL=0A };=0A =0A-static struct attribute_group version_group =3D =
{=0A+static const struct attribute_group version_group =3D {=0A 	=
.name =3D "version",=0A 	.attrs =3D version_attrs,=0A };=0A@@ =
-197,12 +197,12 @@ static struct attribute *xen_compile_att=0A 	NULL=0A =
};=0A =0A-static struct attribute_group xen_compilation_group =3D =
{=0A+static const struct attribute_group xen_compilation_group =3D {=0A 	=
.name =3D "compilation",=0A 	.attrs =3D xen_compile_attrs,=0A };=0A =
=0A-int __init static xen_compilation_init(void)=0A+static int __init =
xen_compilation_init(void)=0A {=0A 	return sysfs_create_group(&hypervis=
or_subsys.kset.kobj,=0A 				  &xen_compilation_=
group);=0A@@ -318,7 +318,7 @@ static struct attribute *xen_properties_=0A 	=
NULL=0A };=0A =0A-static struct attribute_group xen_properties_group =3D =
{=0A+static const struct attribute_group xen_properties_group =3D {=0A 	=
.name =3D "properties",=0A 	.attrs =3D xen_properties_attrs,=0A };=0A
--=__Part78560427.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part78560427.0__=--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:21:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyMoR-00043S-2g; Fri, 17 Feb 2012 12:21:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyMoP-00042h-Lu
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 12:21:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329481271!14969607!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26398 invoked from network); 17 Feb 2012 12:21:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 12:21:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 12:21:10 +0000
Message-Id: <4F3E54470200007800073A25@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 12:21:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part78560427.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/drivers/xen/: constify all
 instances of "struct attribute_group"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part78560427.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The functions these get passed to have been taking pointers to const
since at least 2.6.16.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/balloon/sysfs.c
+++ b/drivers/xen/balloon/sysfs.c
@@ -97,7 +97,7 @@ static struct attribute *balloon_info_at
 	NULL
 };
=20
-static struct attribute_group balloon_info_group =3D {
+static const struct attribute_group balloon_info_group =3D {
 	.name =3D "info",
 	.attrs =3D balloon_info_attrs,
 };
--- a/drivers/xen/blkback/xenbus.c
+++ b/drivers/xen/blkback/xenbus.c
@@ -136,7 +136,7 @@ static struct attribute *vbdstat_attrs[]
 	NULL
 };
=20
-static struct attribute_group vbdstat_group =3D {
+static const struct attribute_group vbdstat_group =3D {
 	.name =3D "statistics",
 	.attrs =3D vbdstat_attrs,
 };
--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -152,7 +152,7 @@ static struct attribute *tapstat_attrs[]
 	NULL
 };
=20
-static struct attribute_group tapstat_group =3D {
+static const struct attribute_group tapstat_group =3D {
 	.name =3D "statistics",
 	.attrs =3D tapstat_attrs,
 };
--- a/drivers/xen/core/xen_sysfs.c
+++ b/drivers/xen/core/xen_sysfs.c
@@ -84,7 +84,7 @@ static struct attribute *version_attrs[]
 	NULL
 };
=20
-static struct attribute_group version_group =3D {
+static const struct attribute_group version_group =3D {
 	.name =3D "version",
 	.attrs =3D version_attrs,
 };
@@ -197,12 +197,12 @@ static struct attribute *xen_compile_att
 	NULL
 };
=20
-static struct attribute_group xen_compilation_group =3D {
+static const struct attribute_group xen_compilation_group =3D {
 	.name =3D "compilation",
 	.attrs =3D xen_compile_attrs,
 };
=20
-int __init static xen_compilation_init(void)
+static int __init xen_compilation_init(void)
 {
 	return sysfs_create_group(&hypervisor_subsys.kset.kobj,
 				  &xen_compilation_group);
@@ -318,7 +318,7 @@ static struct attribute *xen_properties_
 	NULL
 };
=20
-static struct attribute_group xen_properties_group =3D {
+static const struct attribute_group xen_properties_group =3D {
 	.name =3D "properties",
 	.attrs =3D xen_properties_attrs,
 };




--=__Part78560427.0__=
Content-Type: text/plain; name="xen-const-attribute_group.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-const-attribute_group.patch"

drivers/xen/: constify all instances of "struct attribute_group"=0A=0AThe =
functions these get passed to have been taking pointers to const=0Asince =
at least 2.6.16.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A-=
-- a/drivers/xen/balloon/sysfs.c=0A+++ b/drivers/xen/balloon/sysfs.c=0A@@ =
-97,7 +97,7 @@ static struct attribute *balloon_info_at=0A 	NULL=0A =
};=0A =0A-static struct attribute_group balloon_info_group =3D {=0A+static =
const struct attribute_group balloon_info_group =3D {=0A 	.name =3D =
"info",=0A 	.attrs =3D balloon_info_attrs,=0A };=0A--- a/drivers/xen/bl=
kback/xenbus.c=0A+++ b/drivers/xen/blkback/xenbus.c=0A@@ -136,7 +136,7 @@ =
static struct attribute *vbdstat_attrs[]=0A 	NULL=0A };=0A =0A-static =
struct attribute_group vbdstat_group =3D {=0A+static const struct =
attribute_group vbdstat_group =3D {=0A 	.name =3D "statistics",=0A 	=
.attrs =3D vbdstat_attrs,=0A };=0A--- a/drivers/xen/blktap/xenbus.c=0A+++ =
b/drivers/xen/blktap/xenbus.c=0A@@ -152,7 +152,7 @@ static struct =
attribute *tapstat_attrs[]=0A 	NULL=0A };=0A =0A-static struct attribute_g=
roup tapstat_group =3D {=0A+static const struct attribute_group tapstat_gro=
up =3D {=0A 	.name =3D "statistics",=0A 	.attrs =3D tapstat_attrs,=
=0A };=0A--- a/drivers/xen/core/xen_sysfs.c=0A+++ b/drivers/xen/core/xen_sy=
sfs.c=0A@@ -84,7 +84,7 @@ static struct attribute *version_attrs[]=0A 	=
NULL=0A };=0A =0A-static struct attribute_group version_group =3D =
{=0A+static const struct attribute_group version_group =3D {=0A 	=
.name =3D "version",=0A 	.attrs =3D version_attrs,=0A };=0A@@ =
-197,12 +197,12 @@ static struct attribute *xen_compile_att=0A 	NULL=0A =
};=0A =0A-static struct attribute_group xen_compilation_group =3D =
{=0A+static const struct attribute_group xen_compilation_group =3D {=0A 	=
.name =3D "compilation",=0A 	.attrs =3D xen_compile_attrs,=0A };=0A =
=0A-int __init static xen_compilation_init(void)=0A+static int __init =
xen_compilation_init(void)=0A {=0A 	return sysfs_create_group(&hypervis=
or_subsys.kset.kobj,=0A 				  &xen_compilation_=
group);=0A@@ -318,7 +318,7 @@ static struct attribute *xen_properties_=0A 	=
NULL=0A };=0A =0A-static struct attribute_group xen_properties_group =3D =
{=0A+static const struct attribute_group xen_properties_group =3D {=0A 	=
.name =3D "properties",=0A 	.attrs =3D xen_properties_attrs,=0A };=0A
--=__Part78560427.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.xensource.com
http://lists.xensource.com/xen-devel

--=__Part78560427.0__=--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMtD-0004Pk-Sr; Fri, 17 Feb 2012 12:26:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyMtC-0004PZ-PW
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:26:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329481568!13579994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8203 invoked from network); 17 Feb 2012 12:26:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:25:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:25:38 +0000
Message-ID: <1329481536.3131.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 17 Feb 2012 12:25:36 +0000
In-Reply-To: <20120215171817.GC28101@ocelot.phlegethon.org>
References: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
	<20120215171817.GC28101@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: fix indentation level in
 startup_cpu_idle_loop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 17:18 +0000, Tim Deegan wrote:
> At 16:49 +0000 on 15 Feb (1329324552), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Thanks, committed.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMtD-0004Pk-Sr; Fri, 17 Feb 2012 12:26:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyMtC-0004PZ-PW
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:26:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329481568!13579994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8203 invoked from network); 17 Feb 2012 12:26:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 12:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10770800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:25:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:25:38 +0000
Message-ID: <1329481536.3131.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 17 Feb 2012 12:25:36 +0000
In-Reply-To: <20120215171817.GC28101@ocelot.phlegethon.org>
References: <1329324552-885-1-git-send-email-ian.campbell@citrix.com>
	<20120215171817.GC28101@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: fix indentation level in
 startup_cpu_idle_loop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 17:18 +0000, Tim Deegan wrote:
> At 16:49 +0000 on 15 Feb (1329324552), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Thanks, committed.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:26:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMtI-0004Q3-8w; Fri, 17 Feb 2012 12:26:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyMtH-0004Pw-0y
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:26:19 +0000
Received: from [85.158.139.83:51858] by server-7.bemta-5.messagelabs.com id
	94/30-16195-A674E3F4; Fri, 17 Feb 2012 12:26:18 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329481576!12789238!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20966 invoked from network); 17 Feb 2012 12:26:17 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 12:26:17 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyMtD-00060K-K8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 04:26:15 -0800
Date: Fri, 17 Feb 2012 04:26:15 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329481575617-5492321.post@n5.nabble.com>
In-Reply-To: <1329480107.3131.47.camel@zakaz.uk.xensource.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The patch to fix is the second here, right?
http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html

Now I try to apply it and rebuild, after I report it if it works.



--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492321.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:26:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyMtI-0004Q3-8w; Fri, 17 Feb 2012 12:26:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyMtH-0004Pw-0y
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:26:19 +0000
Received: from [85.158.139.83:51858] by server-7.bemta-5.messagelabs.com id
	94/30-16195-A674E3F4; Fri, 17 Feb 2012 12:26:18 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329481576!12789238!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20966 invoked from network); 17 Feb 2012 12:26:17 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 12:26:17 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyMtD-00060K-K8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 04:26:15 -0800
Date: Fri, 17 Feb 2012 04:26:15 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329481575617-5492321.post@n5.nabble.com>
In-Reply-To: <1329480107.3131.47.camel@zakaz.uk.xensource.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The patch to fix is the second here, right?
http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html

Now I try to apply it and rebuild, after I report it if it works.



--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492321.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:38:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyN4K-0004kG-IK; Fri, 17 Feb 2012 12:37:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1Ry4u7-0004q8-6F; Thu, 16 Feb 2012 17:13:59 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329412431!8529436!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3500 invoked from network); 16 Feb 2012 17:13:52 -0000
Received: from mail-gy0-f173.google.com (HELO mail-gy0-f173.google.com)
	(209.85.160.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 17:13:52 -0000
Received: by ghrr20 with SMTP id r20so1697959ghr.32
	for <multiple recipients>; Thu, 16 Feb 2012 09:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=D/ta5UjgqigYefVowhSx0a3ZVsVBEJ5+gN+qlW05s0g=;
	b=kkevHGIa5mU6H1F1zXpoYAuK3Fgnk53Hxn+5lY8CBeqAc+NHR920CPUglEhsz+oi1+
	/WM8xo1R3vb5Rmy2a8Bn9LihO1dsU25bKxPWKygw1Sx6l0qCXRnUwi42gW2Up1UpvyQP
	rae5cdP6lWrw3jbF3xWZpJUFyADJ+r7uFg9ic=
Received: by 10.236.116.73 with SMTP id f49mr4345013yhh.97.1329412431053;
	Thu, 16 Feb 2012 09:13:51 -0800 (PST)
Received: from [10.80.3.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id a39sm15668721yhk.15.2012.02.16.09.13.48
	(version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 09:13:49 -0800 (PST)
Message-ID: <4F3D393A.7070500@gmail.com>
Date: Thu, 16 Feb 2012 17:13:30 +0000
From: Lars Kurth <lars.kurth.xen@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	xen-arm@lists.xen.org, xen-arm@lists.xen.org
X-Mailman-Approved-At: Fri, 17 Feb 2012 12:37:42 +0000
Subject: [Xen-devel] Next Xen Document Day : Feb 27
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0815319931146053399=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============0815319931146053399==
Content-Type: multipart/alternative;
 boundary="------------080607080100050201090606"

This is a multi-part message in MIME format.
--------------080607080100050201090606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,
the next Xen Document Day is coming up:

  * Feb 27, 2012
  * Join us on IRC: freenode channel #xendocday
  * See for more information http://wiki.xen.org/wiki/Xen_Document_Days

I will need a volunteer who kicks of the day and reminds people a couple 
of days beforehand that the docs day will be happening (I will be on 
holidays; in fact I will be trekking in the mountains and won't be able 
to help out that day).

There is also an etherpad page at openetherpad.org/TSPGIEOBiS with a 
todo list (but it seems Etherpad is down at the moment).

Regards
Lars

--------------080607080100050201090606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    the next Xen Document Day is coming up:<br>
    <ul>
      <li>Feb 27, 2012&nbsp;</li>
      <li>Join us on IRC: freenode channel #xendocday</li>
      <li>See for more information
        <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Xen_Document_Days">http://wiki.xen.org/wiki/Xen_Document_Days</a></li>
    </ul>
    I will need a volunteer who kicks of the day and reminds people a
    couple of days beforehand that the docs day will be happening (I
    will be on holidays; in fact I will be trekking in the mountains and
    won't be able to help out that day).<br>
    <br>
    There is also an etherpad page at openetherpad.org/TSPGIEOBiS with a
    todo list (but it seems Etherpad is down at the moment).<br>
    <br>
    Regards<br>
    Lars<br>
  </body>
</html>

--------------080607080100050201090606--


--===============0815319931146053399==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0815319931146053399==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:38:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyN4K-0004kG-IK; Fri, 17 Feb 2012 12:37:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1Ry4u7-0004q8-6F; Thu, 16 Feb 2012 17:13:59 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329412431!8529436!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3500 invoked from network); 16 Feb 2012 17:13:52 -0000
Received: from mail-gy0-f173.google.com (HELO mail-gy0-f173.google.com)
	(209.85.160.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2012 17:13:52 -0000
Received: by ghrr20 with SMTP id r20so1697959ghr.32
	for <multiple recipients>; Thu, 16 Feb 2012 09:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=D/ta5UjgqigYefVowhSx0a3ZVsVBEJ5+gN+qlW05s0g=;
	b=kkevHGIa5mU6H1F1zXpoYAuK3Fgnk53Hxn+5lY8CBeqAc+NHR920CPUglEhsz+oi1+
	/WM8xo1R3vb5Rmy2a8Bn9LihO1dsU25bKxPWKygw1Sx6l0qCXRnUwi42gW2Up1UpvyQP
	rae5cdP6lWrw3jbF3xWZpJUFyADJ+r7uFg9ic=
Received: by 10.236.116.73 with SMTP id f49mr4345013yhh.97.1329412431053;
	Thu, 16 Feb 2012 09:13:51 -0800 (PST)
Received: from [10.80.3.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id a39sm15668721yhk.15.2012.02.16.09.13.48
	(version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 09:13:49 -0800 (PST)
Message-ID: <4F3D393A.7070500@gmail.com>
Date: Thu, 16 Feb 2012 17:13:30 +0000
From: Lars Kurth <lars.kurth.xen@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	xen-arm@lists.xen.org, xen-arm@lists.xen.org
X-Mailman-Approved-At: Fri, 17 Feb 2012 12:37:42 +0000
Subject: [Xen-devel] Next Xen Document Day : Feb 27
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0815319931146053399=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============0815319931146053399==
Content-Type: multipart/alternative;
 boundary="------------080607080100050201090606"

This is a multi-part message in MIME format.
--------------080607080100050201090606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,
the next Xen Document Day is coming up:

  * Feb 27, 2012
  * Join us on IRC: freenode channel #xendocday
  * See for more information http://wiki.xen.org/wiki/Xen_Document_Days

I will need a volunteer who kicks of the day and reminds people a couple 
of days beforehand that the docs day will be happening (I will be on 
holidays; in fact I will be trekking in the mountains and won't be able 
to help out that day).

There is also an etherpad page at openetherpad.org/TSPGIEOBiS with a 
todo list (but it seems Etherpad is down at the moment).

Regards
Lars

--------------080607080100050201090606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    the next Xen Document Day is coming up:<br>
    <ul>
      <li>Feb 27, 2012&nbsp;</li>
      <li>Join us on IRC: freenode channel #xendocday</li>
      <li>See for more information
        <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Xen_Document_Days">http://wiki.xen.org/wiki/Xen_Document_Days</a></li>
    </ul>
    I will need a volunteer who kicks of the day and reminds people a
    couple of days beforehand that the docs day will be happening (I
    will be on holidays; in fact I will be trekking in the mountains and
    won't be able to help out that day).<br>
    <br>
    There is also an etherpad page at openetherpad.org/TSPGIEOBiS with a
    todo list (but it seems Etherpad is down at the moment).<br>
    <br>
    Regards<br>
    Lars<br>
  </body>
</html>

--------------080607080100050201090606--


--===============0815319931146053399==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0815319931146053399==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:46:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNCy-0005SY-0J; Fri, 17 Feb 2012 12:46:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyNCw-0005SJ-Dy
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329482791!13766478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4128 invoked from network); 17 Feb 2012 12:46:31 -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;
	17 Feb 2012 12:46:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10771488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:46:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:46:30 +0000
Message-ID: <1329482789.3131.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:46:29 +0000
In-Reply-To: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.
> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   61 ++++++++++++++++++++++++++++++++++++++---
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 57 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..520a400 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;

Is there somewhere in the code which clamps the number of LRs reported
by the h/w to 64? (and warns appropriately)

This is a mask of in-use LRs, right?

> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,51 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +    struct pending_irq *iter, *n;
> +
> +    spin_lock(&gic.lock);
> +
> +    if ( list_empty(&gic.lr_pending) )
> +    {
> +        for (i = 0; i < nr_lrs; i++) {

One of the bitops.h functions should be usable avoid this loop. We don't
seem to have a find-and-set type operation so you still need the lock.

Do we have any per-LR state which we keep? If we did then it be worth
chaining them into a free list, which you could cheaply enqueue and
dequeue entries from.

> +            if (!test_and_set_bit(i, &gic.lr_mask))

test_and_set_bit is atomic which is unnecessary since you are also
protecting this field with a lock, or if you use the find_first_zero
idea you could just use __set_bit.

> +            {
> +                gic_set_lr(i, virtual_irq, state, priority);
> +                spin_unlock(&gic.lock);
> +                return;
> +            }
> +        }
> +    }
> +
> +    n = irq_to_pending(current, virtual_irq);
> +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> +    {
> +        if ( iter->priority < priority )
> +        {
> +            list_add_tail(&n->lr_link, &iter->lr_link);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }
> +    list_add(&n->lr_link, &gic.lr_pending);
> +    spin_unlock(&gic.lock);

I'm not sure I follow the logic here -- it seems that only one IRQ will
ever be pending in the LRs at a time, but if we've got 4 LRs wouldn't we
want to have 4 active at once and only trap every 4 Acks?

If there's only going to be one active LR then we can jut always use LR0
and do away with the bitmap for the time being.

Are interrupts only on lr_pending if they are not active in an LR? Are
pending irqs which are in an lr kept in a list somewhere else?

Also it would be nice to have a single exit and unlock path.

> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -435,13 +475,25 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> +    for ( i = 0; i < nr_lrs; i++ ) {
>          if ( eisr & ((uint64_t)1 << i) ) {

This loop and test could also use a call to whichever bitops.h thing is
appropriate.

Maybe doesn't matter for loops of the order of 64 iterations but would
be a nice cleanup to make.

>              struct pending_irq *p;
>  
> +            spin_lock(&gic.lock);
>              lr = GICH[GICH_LR + i];
>              virq = lr & GICH_LR_VIRTUAL_MASK;
>              GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +
> +            if ( !list_empty(gic.lr_pending.next) ) {
> +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +                list_del_init(&p->lr_link);
> +                set_bit(i, &gic.lr_mask);
> +            } else {
> +                gic_inject_irq_stop();
> +            }
> +            spin_unlock(&gic.lock);
>  
>              spin_lock(&current->arch.vgic.lock);
>              p = irq_to_pending(current, virq);
> @@ -449,7 +501,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            gic_inject_irq_stop();
>              list_del(&p->link);
>              INIT_LIST_HEAD(&p->link);
>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;
>  };
>  
>  struct arch_domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:46:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNCy-0005SY-0J; Fri, 17 Feb 2012 12:46:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyNCw-0005SJ-Dy
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:46:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329482791!13766478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4128 invoked from network); 17 Feb 2012 12:46:31 -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;
	17 Feb 2012 12:46:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10771488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:46:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:46:30 +0000
Message-ID: <1329482789.3131.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:46:29 +0000
In-Reply-To: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual irqs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.
> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   61 ++++++++++++++++++++++++++++++++++++++---
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 57 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..520a400 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;

Is there somewhere in the code which clamps the number of LRs reported
by the h/w to 64? (and warns appropriately)

This is a mask of in-use LRs, right?

> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,51 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +    struct pending_irq *iter, *n;
> +
> +    spin_lock(&gic.lock);
> +
> +    if ( list_empty(&gic.lr_pending) )
> +    {
> +        for (i = 0; i < nr_lrs; i++) {

One of the bitops.h functions should be usable avoid this loop. We don't
seem to have a find-and-set type operation so you still need the lock.

Do we have any per-LR state which we keep? If we did then it be worth
chaining them into a free list, which you could cheaply enqueue and
dequeue entries from.

> +            if (!test_and_set_bit(i, &gic.lr_mask))

test_and_set_bit is atomic which is unnecessary since you are also
protecting this field with a lock, or if you use the find_first_zero
idea you could just use __set_bit.

> +            {
> +                gic_set_lr(i, virtual_irq, state, priority);
> +                spin_unlock(&gic.lock);
> +                return;
> +            }
> +        }
> +    }
> +
> +    n = irq_to_pending(current, virtual_irq);
> +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> +    {
> +        if ( iter->priority < priority )
> +        {
> +            list_add_tail(&n->lr_link, &iter->lr_link);
> +            spin_unlock(&gic.lock);
> +            return;
> +        }
> +    }
> +    list_add(&n->lr_link, &gic.lr_pending);
> +    spin_unlock(&gic.lock);

I'm not sure I follow the logic here -- it seems that only one IRQ will
ever be pending in the LRs at a time, but if we've got 4 LRs wouldn't we
want to have 4 active at once and only trap every 4 Acks?

If there's only going to be one active LR then we can jut always use LR0
and do away with the bitmap for the time being.

Are interrupts only on lr_pending if they are not active in an LR? Are
pending irqs which are in an lr kept in a list somewhere else?

Also it would be nice to have a single exit and unlock path.

> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -435,13 +475,25 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> +    for ( i = 0; i < nr_lrs; i++ ) {
>          if ( eisr & ((uint64_t)1 << i) ) {

This loop and test could also use a call to whichever bitops.h thing is
appropriate.

Maybe doesn't matter for loops of the order of 64 iterations but would
be a nice cleanup to make.

>              struct pending_irq *p;
>  
> +            spin_lock(&gic.lock);
>              lr = GICH[GICH_LR + i];
>              virq = lr & GICH_LR_VIRTUAL_MASK;
>              GICH[GICH_LR + i] = 0;
> +            clear_bit(i, &gic.lr_mask);
> +
> +            if ( !list_empty(gic.lr_pending.next) ) {
> +                p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +                gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +                list_del_init(&p->lr_link);
> +                set_bit(i, &gic.lr_mask);
> +            } else {
> +                gic_inject_irq_stop();
> +            }
> +            spin_unlock(&gic.lock);
>  
>              spin_lock(&current->arch.vgic.lock);
>              p = irq_to_pending(current, virq);
> @@ -449,7 +501,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            gic_inject_irq_stop();
>              list_del(&p->link);
>              INIT_LIST_HEAD(&p->link);
>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;
>  };
>  
>  struct arch_domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyNH0-0005gY-Lz; Fri, 17 Feb 2012 12:50:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyNGz-0005gF-83
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:50:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329483040!11972733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 17 Feb 2012 12:50:41 -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 Feb 2012 12:50:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10771946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:50:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:50:40 +0000
Message-ID: <1329483039.3131.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:50:39 +0000
In-Reply-To: <1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: replace list_del and INIT_LIST_HEAD
 with list_del_init
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Is this safe to take without the other vgic patch?

> ---
>  xen/arch/arm/gic.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 520a400..c34661b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -501,8 +501,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            list_del(&p->link);
> -            INIT_LIST_HEAD(&p->link);
> +            list_del_init(&p->link);

David said:
        
        I don't think you need the INIT_LIST_HEAD() here (and even if
        you did you should use list_del_init()).  You only need to init
        nodes if you need to test if they are in a list or not.
        
But I'm not seeing where we test if a node is in a list or not, have I
missed it?

>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
>              spin_unlock(&current->arch.vgic.lock);
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyNH0-0005gY-Lz; Fri, 17 Feb 2012 12:50:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyNGz-0005gF-83
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:50:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329483040!11972733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 17 Feb 2012 12:50:41 -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 Feb 2012 12:50:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="10771946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:50:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:50:40 +0000
Message-ID: <1329483039.3131.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 17 Feb 2012 12:50:39 +0000
In-Reply-To: <1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: replace list_del and INIT_LIST_HEAD
 with list_del_init
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Is this safe to take without the other vgic patch?

> ---
>  xen/arch/arm/gic.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 520a400..c34661b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -501,8 +501,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
>                  p->desc->status &= ~IRQ_INPROGRESS;
>                  GICC[GICC_DIR] = virq;
>              }
> -            list_del(&p->link);
> -            INIT_LIST_HEAD(&p->link);
> +            list_del_init(&p->link);

David said:
        
        I don't think you need the INIT_LIST_HEAD() here (and even if
        you did you should use list_del_init()).  You only need to init
        nodes if you need to test if they are in a list or not.
        
But I'm not seeing where we test if a node is in a list or not, have I
missed it?

>              cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
>              spin_unlock(&current->arch.vgic.lock);
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyNHG-0005iT-8q; Fri, 17 Feb 2012 12:51:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyNHE-0005iF-K2
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:51:04 +0000
Received: from [85.158.139.83:35511] by server-4.bemta-5.messagelabs.com id
	33/9A-10788-73D4E3F4; Fri, 17 Feb 2012 12:51:03 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329483062!8162063!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjc2NDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29924 invoked from network); 17 Feb 2012 12:51:03 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-16.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 12:51:03 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1HCoBHR030887;
	Fri, 17 Feb 2012 07:50:11 -0500
Date: Fri, 17 Feb 2012 07:50:11 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120216194801.GB8023@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.11.9.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > We just reported to xenbus that we can't close yet, because
> > blkfront is still in use. So we shouldn't then immediately
> > state that we are closing.
> 
> What happens if the user uses --force to unplug the device?
> Will that still work?

With RHEL5 tooling I get the same results. That is, the device
is forcibly detached, and then any task in the guest that still
attempts to use (or even just unmount) the device hangs.

I don't know anything about xl, but afaict block-detach
doesn't take a 'force' option?

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/block/xen-blkfront.c |    1 -
> >  1 files changed, 0 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c
> > b/drivers/block/xen-blkfront.c
> > index 5d45688..b53cae4 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> >  	if (bdev->bd_openers) {
> >  		xenbus_dev_error(xbdev, -EBUSY,
> >  				 "Device in use; refusing to close");
> > -		xenbus_switch_state(xbdev, XenbusStateClosing);
> >  	} else {
> >  		xlvbd_release_gendisk(info);
> >  		xenbus_frontend_closed(xbdev);
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 12:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 12: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.xensource.com>)
	id 1RyNHG-0005iT-8q; Fri, 17 Feb 2012 12:51:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyNHE-0005iF-K2
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 12:51:04 +0000
Received: from [85.158.139.83:35511] by server-4.bemta-5.messagelabs.com id
	33/9A-10788-73D4E3F4; Fri, 17 Feb 2012 12:51:03 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329483062!8162063!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjc2NDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29924 invoked from network); 17 Feb 2012 12:51:03 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-16.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 12:51:03 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1HCoBHR030887;
	Fri, 17 Feb 2012 07:50:11 -0500
Date: Fri, 17 Feb 2012 07:50:11 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120216194801.GB8023@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.11.9.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > We just reported to xenbus that we can't close yet, because
> > blkfront is still in use. So we shouldn't then immediately
> > state that we are closing.
> 
> What happens if the user uses --force to unplug the device?
> Will that still work?

With RHEL5 tooling I get the same results. That is, the device
is forcibly detached, and then any task in the guest that still
attempts to use (or even just unmount) the device hangs.

I don't know anything about xl, but afaict block-detach
doesn't take a 'force' option?

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/block/xen-blkfront.c |    1 -
> >  1 files changed, 0 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/block/xen-blkfront.c
> > b/drivers/block/xen-blkfront.c
> > index 5d45688..b53cae4 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> >  	if (bdev->bd_openers) {
> >  		xenbus_dev_error(xbdev, -EBUSY,
> >  				 "Device in use; refusing to close");
> > -		xenbus_switch_state(xbdev, XenbusStateClosing);
> >  	} else {
> >  		xlvbd_release_gendisk(info);
> >  		xenbus_frontend_closed(xbdev);
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:14:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyNdq-0006XS-3v; Fri, 17 Feb 2012 13:14:26 +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 1RyNdo-0006XN-Rr
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:14:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329484409!49703252!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31576 invoked from network); 17 Feb 2012 13:13:30 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 13:13:30 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyNdm-0002bw-0O
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 05:14:22 -0800
Date: Fri, 17 Feb 2012 05:14:22 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329484462005-5492438.post@n5.nabble.com>
In-Reply-To: <1329481575617-5492321.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

V2l0aCBvbmx5IHNlY29uZCBwYXRjaCBmYWlsOgoKZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5Ci1XYWxsIC1Xc3Ry
aWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQKLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTU1EIC1NRiAueGxfY21kaW1wbC5v
LmQgCi1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscwotV2Vycm9yIC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RoIC1XbWlzc2lu
Zy1kZWNsYXJhdGlvbnMKLVduby1kZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdmb3JtYXQt
bm9ubGl0ZXJhbCAtSS4gLWZQSUMKLURIQVZFX1lBSkxfVkVSU0lPTgotSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9saWJ4YwotSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9pbmNsdWRlIAotSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9saWJ4bAotSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9saWJ4Ywot
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9pbmNs
dWRlCi1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhsLy4uLy4uL3Rvb2xz
L2luY2x1ZGUgIC1jIC1vCnhsX2NtZGltcGwubyB4bF9jbWRpbXBsLmMgCnhsX2NtZGltcGwuYzog
SW4gZnVuY3Rpb24gw6JwcmludGZfaW5mb8OiOgp4bF9jbWRpbXBsLmM6MzA1OjU6IGVycm9yOiBp
bXBsaWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbgrDomxpYnhsX3lhamxfZ2VuX2FsbG9jw6Ig
Wy1XZXJyb3I9aW1wbGljaXQtZnVuY3Rpb24tZGVjbGFyYXRpb25dCnhsX2NtZGltcGwuYzozMDU6
MTA6IGVycm9yOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQg
YQpjYXN0IFstV2Vycm9yXQpjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFzIGVycm9y
cwoKbWFrZVszXTogKioqIFt4bF9jbWRpbXBsLm9dIEVycm9yIDEKbWFrZVszXTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bCcKbWFrZVsy
XTogKioqIFtzdWJkaXItaW5zdGFsbC1saWJ4bF0gRXJyb3IgMgptYWtlWzJdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJwptYWtlWzFdOiAqKiog
W3N1YmRpcnMtaW5zdGFsbF0gRXJyb3IgMgptYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJwptYWtlOiAqKiogW2luc3RhbGwtdG9vbHNd
IEVycm9yIDIKClByb2JhYmx5IG5lZWQgYWxzbyB0aGUgZmlyc3QsIG5vdCBhZGQgYWZ0ZXIgcmVh
ZCB0aGlzOgo+IHRvb2xzL2xpYnhsOiByZW5hbWUgbGlieGxfX3lhamxfZ2VuX2FsbG9jCj4KPiBs
aWJ4bF9feWFqbF9nZW5fYWxsb2MoKSBpcyBjYWxsZWQgYnkgZ2VuZXJpYyBjb2RlLAo+IHJlbmFt
ZSBpdCB0byBsaWJ4X195YWpsX2dlbl9hbGxvYygpLgoKT3RoZXIgdGhhbiB0aGlzIHR5cG8gYm90
aCBwYXRjaGVzIGluIHRoaXMgc2VyaWVzIGxvb2sgZ29vZCB0byBtZSwKdGhhbmtzLgoKQWNrZWQt
Ynk6IElhbiBDYW1wYmVsbCA8W2hpZGRlbiBlbWFpbF0+IAoKTm93IEkgdHJ5IGFsc28gZmlyc3Qu
CgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3MTIubjUu
bmFiYmxlLmNvbS94bC1jbWRpbXBsLWMtZXJyb3JzLXRwNTQ5MTUzN3A1NDkyNDM4Lmh0bWwKU2Vu
dCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFiYmxlLmNvbS4K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:14:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyNdq-0006XS-3v; Fri, 17 Feb 2012 13:14:26 +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 1RyNdo-0006XN-Rr
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:14:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329484409!49703252!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31576 invoked from network); 17 Feb 2012 13:13:30 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 13:13:30 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyNdm-0002bw-0O
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 05:14:22 -0800
Date: Fri, 17 Feb 2012 05:14:22 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329484462005-5492438.post@n5.nabble.com>
In-Reply-To: <1329481575617-5492321.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

V2l0aCBvbmx5IHNlY29uZCBwYXRjaCBmYWlsOgoKZ2NjICAtTzEgLWZuby1vbWl0LWZyYW1lLXBv
aW50ZXIgLW02NCAtZyAtZm5vLXN0cmljdC1hbGlhc2luZyAtc3RkPWdudTk5Ci1XYWxsIC1Xc3Ry
aWN0LXByb3RvdHlwZXMgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQKLVduby11bnVzZWQt
YnV0LXNldC12YXJpYWJsZSAgIC1EX19YRU5fVE9PTFNfXyAtTU1EIC1NRiAueGxfY21kaW1wbC5v
LmQgCi1EX0xBUkdFRklMRV9TT1VSQ0UgLURfTEFSR0VGSUxFNjRfU09VUkNFIC1mbm8tb3B0aW1p
emUtc2libGluZy1jYWxscwotV2Vycm9yIC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RoIC1XbWlzc2lu
Zy1kZWNsYXJhdGlvbnMKLVduby1kZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQgLVdmb3JtYXQt
bm9ubGl0ZXJhbCAtSS4gLWZQSUMKLURIQVZFX1lBSkxfVkVSU0lPTgotSS9tbnQvdm0veGVuL3hl
bi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9saWJ4YwotSS9tbnQvdm0veGVu
L3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9pbmNsdWRlIAotSS9tbnQv
dm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9saWJ4bAotSS9t
bnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9saWJ4Ywot
SS9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bC8uLi8uLi90b29scy9pbmNs
dWRlCi1JL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzL2xpYnhsLy4uLy4uL3Rvb2xz
L2luY2x1ZGUgIC1jIC1vCnhsX2NtZGltcGwubyB4bF9jbWRpbXBsLmMgCnhsX2NtZGltcGwuYzog
SW4gZnVuY3Rpb24gw6JwcmludGZfaW5mb8OiOgp4bF9jbWRpbXBsLmM6MzA1OjU6IGVycm9yOiBp
bXBsaWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbgrDomxpYnhsX3lhamxfZ2VuX2FsbG9jw6Ig
Wy1XZXJyb3I9aW1wbGljaXQtZnVuY3Rpb24tZGVjbGFyYXRpb25dCnhsX2NtZGltcGwuYzozMDU6
MTA6IGVycm9yOiBhc3NpZ25tZW50IG1ha2VzIHBvaW50ZXIgZnJvbSBpbnRlZ2VyIHdpdGhvdXQg
YQpjYXN0IFstV2Vycm9yXQpjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFzIGVycm9y
cwoKbWFrZVszXTogKioqIFt4bF9jbWRpbXBsLm9dIEVycm9yIDEKbWFrZVszXTogTGVhdmluZyBk
aXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9saWJ4bCcKbWFrZVsy
XTogKioqIFtzdWJkaXItaW5zdGFsbC1saWJ4bF0gRXJyb3IgMgptYWtlWzJdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL21udC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJwptYWtlWzFdOiAqKiog
W3N1YmRpcnMtaW5zdGFsbF0gRXJyb3IgMgptYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL21u
dC92bS94ZW4veGVuLXVuc3RhYmxlLmhnL3Rvb2xzJwptYWtlOiAqKiogW2luc3RhbGwtdG9vbHNd
IEVycm9yIDIKClByb2JhYmx5IG5lZWQgYWxzbyB0aGUgZmlyc3QsIG5vdCBhZGQgYWZ0ZXIgcmVh
ZCB0aGlzOgo+IHRvb2xzL2xpYnhsOiByZW5hbWUgbGlieGxfX3lhamxfZ2VuX2FsbG9jCj4KPiBs
aWJ4bF9feWFqbF9nZW5fYWxsb2MoKSBpcyBjYWxsZWQgYnkgZ2VuZXJpYyBjb2RlLAo+IHJlbmFt
ZSBpdCB0byBsaWJ4X195YWpsX2dlbl9hbGxvYygpLgoKT3RoZXIgdGhhbiB0aGlzIHR5cG8gYm90
aCBwYXRjaGVzIGluIHRoaXMgc2VyaWVzIGxvb2sgZ29vZCB0byBtZSwKdGhhbmtzLgoKQWNrZWQt
Ynk6IElhbiBDYW1wYmVsbCA8W2hpZGRlbiBlbWFpbF0+IAoKTm93IEkgdHJ5IGFsc28gZmlyc3Qu
CgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3MTIubjUu
bmFiYmxlLmNvbS94bC1jbWRpbXBsLWMtZXJyb3JzLXRwNTQ5MTUzN3A1NDkyNDM4Lmh0bWwKU2Vu
dCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFiYmxlLmNvbS4K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:25:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13: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.xensource.com>)
	id 1RyNnz-0006jR-7p; Fri, 17 Feb 2012 13:24:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyNnx-0006jM-UN
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:24:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329485087!4504290!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1871 invoked from network); 17 Feb 2012 13:24:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 13:24:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyNnr-000F5e-Fd; Fri, 17 Feb 2012 13:24:47 +0000
Date: Fri, 17 Feb 2012 13:24:47 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120217132447.GA57907@ocelot.phlegethon.org>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:10 +0000 on 17 Feb (1329480642), David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> alloca() does not return NULL on an allocation failure

Nack: on some BSD systems it does. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:25:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13: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.xensource.com>)
	id 1RyNnz-0006jR-7p; Fri, 17 Feb 2012 13:24:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyNnx-0006jM-UN
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:24:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329485087!4504290!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1871 invoked from network); 17 Feb 2012 13:24:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 13:24:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyNnr-000F5e-Fd; Fri, 17 Feb 2012 13:24:47 +0000
Date: Fri, 17 Feb 2012 13:24:47 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120217132447.GA57907@ocelot.phlegethon.org>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:10 +0000 on 17 Feb (1329480642), David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> alloca() does not return NULL on an allocation failure

Nack: on some BSD systems it does. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:27:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13: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.xensource.com>)
	id 1RyNqU-0006pf-EN; Fri, 17 Feb 2012 13:27:30 +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 1RyNqT-0006pV-4O
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:27:29 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329485222!53353042!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7979 invoked from network); 17 Feb 2012 13:27:03 -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;
	17 Feb 2012 13:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325480400"; d="scan'208";a="22188910"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:27:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	08:27:25 -0500
Message-ID: <4F3E55BC.4050004@citrix.com>
Date: Fri, 17 Feb 2012 13:27:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------070701020402010101020007"
Subject: [Xen-devel] IO-APIC line level race condition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070701020402010101020007
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Sadly, we have discovered another line level interrupt race condition in
Xen-4.1.  The result was that an outstanding un-eoi'd interrupt at the
IO-APIC resulted in the mptsas controller offlining the root filesystem.

This is now two separate IO-APIC bugs found recently.

1) Cisco C210 M2 server - EOI Broadcast Suppression, io_apci_ack=old
2) Dell R710 - No EOI Broadcast Suppression, io_apic_ack=new

Both servers use IO-APIC version 0x20 and have an mptsas controller for
their disks, using Legacy PCI line level interrupts.  Workload on both
servers appear to have more active vcpus

Case 1 is now considered stable by the customer after I provided a
private fix which caused Xen to never consider turning on EOI Broadcast
Suppression.  I have re-attached a patch which allows this problem to be
"fixed" by specifying "ioapic_ack=new" on the command line, rather than
requiring a patch and recompile of Xen.

Case 2 has only been seen once (this morning) so we currently have no
idea as to its reproducibility.  However, given that this hardware is
fairly common in our test infrastructure, i would say that it is fairly
rare.

With Case1 and the new patch, Case1 becomes the same as Case2 with
respect to IO-APIC setup, presumably meaning that the Case2 bug still
exists with Case1.


I will start working on cleaning up the IO-APIC code as soon as I can,
as reducing the unnecessary complexity should make race conditions like
this easier to find.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070701020402010101020007
Content-Type: text/x-patch; name="ioapic-ack-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ioapic-ack-fix.patch"

# HG changeset patch
# Parent 9ad1e42c341bc78463b6f6610a6300f75b535fbb
IO-APIC: Prevent using EOI broadcast suppression if user specified
ioapic_ack=new on the command line.

Currently, if EOI broadcast suppression is advertised on the BSP LAPIC, Xen will
discard any user specified option regarding IO-APIC ack mode.

This patch introduces a check which prevents EOI Broadcast suppression from
forcing the IO-APIC ack mode to old if the user has explicitly asked for the new
ack mode on the command line.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 9ad1e42c341b xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -424,9 +424,16 @@ int __init verify_local_APIC(void)
      */
     if ( reg0 & APIC_LVR_DIRECTED_EOI )
     {
-        ioapic_ack_new = 0;
-        directed_eoi_enabled = 1;
-        printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        if ( ioapic_ack_new == 1 && ioapic_ack_forced == 1 )
+            printk("Not enabling EOI broadcast suppression because "
+                   "ioapic_ack_new has been forced on the command line\n");
+        else
+        {
+            ioapic_ack_new = 0;
+            directed_eoi_enabled = 1;
+            printk("Enabled EOI broadcast suppression with ioapic_ack_old "
+                   "on!\n");
+        }
     }
 
     /*
diff -r 9ad1e42c341b xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -44,6 +44,7 @@ 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;
 
 #ifndef sis_apic_bug
 /*
@@ -1543,9 +1544,15 @@ static unsigned int startup_level_ioapic
 static void __init setup_ioapic_ack(char *s)
 {
     if ( !strcmp(s, "old") )
+    {
         ioapic_ack_new = 0;
+        ioapic_ack_forced = 1;
+    }
     else if ( !strcmp(s, "new") )
+    {
         ioapic_ack_new = 1;
+        ioapic_ack_forced = 1;
+    }
     else
         printk("Unknown ioapic_ack value specified: '%s'\n", s);
 }
diff -r 9ad1e42c341b xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -180,6 +180,7 @@ static inline void io_apic_modify(unsign
 /* 1 if "noapic" boot option passed */
 extern bool_t skip_ioapic_setup;
 extern bool_t ioapic_ack_new;
+extern bool_t ioapic_ack_forced;
 
 #ifdef CONFIG_ACPI_BOOT
 extern int io_apic_get_unique_id (int ioapic, int apic_id);

--------------070701020402010101020007
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070701020402010101020007--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:27:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13: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.xensource.com>)
	id 1RyNqU-0006pf-EN; Fri, 17 Feb 2012 13:27:30 +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 1RyNqT-0006pV-4O
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:27:29 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329485222!53353042!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7979 invoked from network); 17 Feb 2012 13:27:03 -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;
	17 Feb 2012 13:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325480400"; d="scan'208";a="22188910"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:27:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	08:27:25 -0500
Message-ID: <4F3E55BC.4050004@citrix.com>
Date: Fri, 17 Feb 2012 13:27:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------070701020402010101020007"
Subject: [Xen-devel] IO-APIC line level race condition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070701020402010101020007
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Sadly, we have discovered another line level interrupt race condition in
Xen-4.1.  The result was that an outstanding un-eoi'd interrupt at the
IO-APIC resulted in the mptsas controller offlining the root filesystem.

This is now two separate IO-APIC bugs found recently.

1) Cisco C210 M2 server - EOI Broadcast Suppression, io_apci_ack=old
2) Dell R710 - No EOI Broadcast Suppression, io_apic_ack=new

Both servers use IO-APIC version 0x20 and have an mptsas controller for
their disks, using Legacy PCI line level interrupts.  Workload on both
servers appear to have more active vcpus

Case 1 is now considered stable by the customer after I provided a
private fix which caused Xen to never consider turning on EOI Broadcast
Suppression.  I have re-attached a patch which allows this problem to be
"fixed" by specifying "ioapic_ack=new" on the command line, rather than
requiring a patch and recompile of Xen.

Case 2 has only been seen once (this morning) so we currently have no
idea as to its reproducibility.  However, given that this hardware is
fairly common in our test infrastructure, i would say that it is fairly
rare.

With Case1 and the new patch, Case1 becomes the same as Case2 with
respect to IO-APIC setup, presumably meaning that the Case2 bug still
exists with Case1.


I will start working on cleaning up the IO-APIC code as soon as I can,
as reducing the unnecessary complexity should make race conditions like
this easier to find.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070701020402010101020007
Content-Type: text/x-patch; name="ioapic-ack-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ioapic-ack-fix.patch"

# HG changeset patch
# Parent 9ad1e42c341bc78463b6f6610a6300f75b535fbb
IO-APIC: Prevent using EOI broadcast suppression if user specified
ioapic_ack=new on the command line.

Currently, if EOI broadcast suppression is advertised on the BSP LAPIC, Xen will
discard any user specified option regarding IO-APIC ack mode.

This patch introduces a check which prevents EOI Broadcast suppression from
forcing the IO-APIC ack mode to old if the user has explicitly asked for the new
ack mode on the command line.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 9ad1e42c341b xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -424,9 +424,16 @@ int __init verify_local_APIC(void)
      */
     if ( reg0 & APIC_LVR_DIRECTED_EOI )
     {
-        ioapic_ack_new = 0;
-        directed_eoi_enabled = 1;
-        printk("Enabled directed EOI with ioapic_ack_old on!\n");
+        if ( ioapic_ack_new == 1 && ioapic_ack_forced == 1 )
+            printk("Not enabling EOI broadcast suppression because "
+                   "ioapic_ack_new has been forced on the command line\n");
+        else
+        {
+            ioapic_ack_new = 0;
+            directed_eoi_enabled = 1;
+            printk("Enabled EOI broadcast suppression with ioapic_ack_old "
+                   "on!\n");
+        }
     }
 
     /*
diff -r 9ad1e42c341b xen/arch/x86/io_apic.c
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -44,6 +44,7 @@ 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;
 
 #ifndef sis_apic_bug
 /*
@@ -1543,9 +1544,15 @@ static unsigned int startup_level_ioapic
 static void __init setup_ioapic_ack(char *s)
 {
     if ( !strcmp(s, "old") )
+    {
         ioapic_ack_new = 0;
+        ioapic_ack_forced = 1;
+    }
     else if ( !strcmp(s, "new") )
+    {
         ioapic_ack_new = 1;
+        ioapic_ack_forced = 1;
+    }
     else
         printk("Unknown ioapic_ack value specified: '%s'\n", s);
 }
diff -r 9ad1e42c341b xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -180,6 +180,7 @@ static inline void io_apic_modify(unsign
 /* 1 if "noapic" boot option passed */
 extern bool_t skip_ioapic_setup;
 extern bool_t ioapic_ack_new;
+extern bool_t ioapic_ack_forced;
 
 #ifdef CONFIG_ACPI_BOOT
 extern int io_apic_get_unique_id (int ioapic, int apic_id);

--------------070701020402010101020007
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------070701020402010101020007--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNt2-00076I-0i; Fri, 17 Feb 2012 13:30:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RyNt0-00075p-2z
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 13:30:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329485399!14387978!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22479 invoked from network); 17 Feb 2012 13:30:00 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 13:30:00 -0000
Received: by wibhi20 with SMTP id hi20so828920wib.32
	for <xen-devel@lists.xen.org>; Fri, 17 Feb 2012 05:29:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=ZyXNP2mHrNJFl8hSAZHqEO4NoCMkcKFibTcNtMrEEUg=;
	b=eye/XZAEbQt9jU3Xnq/J4GvuXoos9RAOQRbSG99QHYfYOeWFTYGQcKbonSSkYTto6W
	xacD9YLkVQBy3At32L4SZ9GwlfrXhgUHaXrsmUWqHmEHrbfwkE+Et6Y4w8m2B/ZWmo8J
	4K1aXznwpr1H0OO5uECxhCaMSgsFOtRxrcUkI=
Received: by 10.180.80.226 with SMTP id u2mr4329872wix.0.1329485399748;
	Fri, 17 Feb 2012 05:29:59 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id by3sm7624930wib.3.2012.02.17.05.29.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 17 Feb 2012 05:29:59 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org,
	qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 18:06:37 +0100
Message-Id: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH] build: add needed missing libraries libm and
	librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libm is used in cutils.c, but the library was not specified
when linking some binaries, throwing the following error:

cutils.o: In function `strtosz_suffix_unit':
/home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:354: undefined
reference to `__isnan'
/home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:357: undefined
reference to `modf'
collect2: ld returned 1 exit status

According to modf man page [0], -lm should be used when linking.

librt is used in qemu-time.c, but again the library was not specified
at link time, throwing the following error:

/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:597: undefined
reference to `timer_gettime'
/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:610: undefined
reference to `timer_settime'
../qemu-timer.o: In function `dynticks_start_timer':
/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:565: undefined
reference to `timer_create'
../qemu-timer.o: In function `dynticks_stop_timer':
/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:583: undefined
reference to `timer_delete'
collect2: ld returned 1 exit status

According to timer_getttime man page [1], -lrt should be used when
linking.

[0] http://linux.die.net/man/3/modf
[1] http://linux.die.net/man/2/timer_gettime

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 Makefile        |    4 ++--
 Makefile.target |    2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 301c75e..e2c3cd4 100644
--- a/Makefile
+++ b/Makefile
@@ -34,7 +34,7 @@ configure: ;
 
 $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
 
-LIBS+=-lz $(LIBS_TOOLS)
+LIBS+=-lz -lm -lrt $(LIBS_TOOLS)
 
 ifdef BUILD_DOCS
 DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 QMP/qmp-commands.txt
@@ -170,7 +170,7 @@ test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y)
 $(qapi-obj-y): $(GENERATED_HEADERS)
 qapi-dir := $(BUILD_DIR)/qapi-generated
 test-visitor.o test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir)
-qemu-ga$(EXESUF): LIBS = $(LIBS_QGA)
+qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) -lm
 
 $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\
 $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py
diff --git a/Makefile.target b/Makefile.target
index a111521..95d6bc0 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -33,6 +33,8 @@ endif
 PROGS=$(QEMU_PROG)
 STPFILES=
 
+LIBS+=-lrt
+
 ifndef CONFIG_HAIKU
 LIBS+=-lm
 endif
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNt2-00076I-0i; Fri, 17 Feb 2012 13:30:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RyNt0-00075p-2z
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 13:30:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329485399!14387978!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22479 invoked from network); 17 Feb 2012 13:30:00 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 13:30:00 -0000
Received: by wibhi20 with SMTP id hi20so828920wib.32
	for <xen-devel@lists.xen.org>; Fri, 17 Feb 2012 05:29:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=ZyXNP2mHrNJFl8hSAZHqEO4NoCMkcKFibTcNtMrEEUg=;
	b=eye/XZAEbQt9jU3Xnq/J4GvuXoos9RAOQRbSG99QHYfYOeWFTYGQcKbonSSkYTto6W
	xacD9YLkVQBy3At32L4SZ9GwlfrXhgUHaXrsmUWqHmEHrbfwkE+Et6Y4w8m2B/ZWmo8J
	4K1aXznwpr1H0OO5uECxhCaMSgsFOtRxrcUkI=
Received: by 10.180.80.226 with SMTP id u2mr4329872wix.0.1329485399748;
	Fri, 17 Feb 2012 05:29:59 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id by3sm7624930wib.3.2012.02.17.05.29.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 17 Feb 2012 05:29:59 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org,
	qemu-devel@nongnu.org
Date: Wed,  8 Feb 2012 18:06:37 +0100
Message-Id: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH] build: add needed missing libraries libm and
	librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libm is used in cutils.c, but the library was not specified
when linking some binaries, throwing the following error:

cutils.o: In function `strtosz_suffix_unit':
/home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:354: undefined
reference to `__isnan'
/home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:357: undefined
reference to `modf'
collect2: ld returned 1 exit status

According to modf man page [0], -lm should be used when linking.

librt is used in qemu-time.c, but again the library was not specified
at link time, throwing the following error:

/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:597: undefined
reference to `timer_gettime'
/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:610: undefined
reference to `timer_settime'
../qemu-timer.o: In function `dynticks_start_timer':
/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:565: undefined
reference to `timer_create'
../qemu-timer.o: In function `dynticks_stop_timer':
/home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:583: undefined
reference to `timer_delete'
collect2: ld returned 1 exit status

According to timer_getttime man page [1], -lrt should be used when
linking.

[0] http://linux.die.net/man/3/modf
[1] http://linux.die.net/man/2/timer_gettime

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 Makefile        |    4 ++--
 Makefile.target |    2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 301c75e..e2c3cd4 100644
--- a/Makefile
+++ b/Makefile
@@ -34,7 +34,7 @@ configure: ;
 
 $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
 
-LIBS+=-lz $(LIBS_TOOLS)
+LIBS+=-lz -lm -lrt $(LIBS_TOOLS)
 
 ifdef BUILD_DOCS
 DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 QMP/qmp-commands.txt
@@ -170,7 +170,7 @@ test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y)
 $(qapi-obj-y): $(GENERATED_HEADERS)
 qapi-dir := $(BUILD_DIR)/qapi-generated
 test-visitor.o test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir)
-qemu-ga$(EXESUF): LIBS = $(LIBS_QGA)
+qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) -lm
 
 $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\
 $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py
diff --git a/Makefile.target b/Makefile.target
index a111521..95d6bc0 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -33,6 +33,8 @@ endif
 PROGS=$(QEMU_PROG)
 STPFILES=
 
+LIBS+=-lrt
+
 ifndef CONFIG_HAIKU
 LIBS+=-lm
 endif
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:33:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:33:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNvk-0007LS-LH; Fri, 17 Feb 2012 13:32:56 +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 1RyNvk-0007LJ-24
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:32:56 +0000
Received: from [85.158.139.83:13221] by server-2.bemta-5.messagelabs.com id
	86/E7-20263-7075E3F4; Fri, 17 Feb 2012 13:32:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329485573!15476361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25535 invoked from network); 17 Feb 2012 13:32:54 -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;
	17 Feb 2012 13:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325480400"; d="scan'208";a="182380235"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:32:52 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	08:32:52 -0500
Message-ID: <4F3E5703.1080407@citrix.com>
Date: Fri, 17 Feb 2012 13:32:51 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
	<20120217132447.GA57907@ocelot.phlegethon.org>
In-Reply-To: <20120217132447.GA57907@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/12 13:24, Tim Deegan wrote:
> At 12:10 +0000 on 17 Feb (1329480642), David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> alloca() does not return NULL on an allocation failure
> 
> Nack: on some BSD systems it does. 

xc_linux_osdep.c is only built if CONFIG_Linux is set.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:33:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:33:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNvk-0007LS-LH; Fri, 17 Feb 2012 13:32:56 +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 1RyNvk-0007LJ-24
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:32:56 +0000
Received: from [85.158.139.83:13221] by server-2.bemta-5.messagelabs.com id
	86/E7-20263-7075E3F4; Fri, 17 Feb 2012 13:32:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329485573!15476361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25535 invoked from network); 17 Feb 2012 13:32:54 -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;
	17 Feb 2012 13:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325480400"; d="scan'208";a="182380235"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 08:32:52 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	08:32:52 -0500
Message-ID: <4F3E5703.1080407@citrix.com>
Date: Fri, 17 Feb 2012 13:32:51 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
	<20120217132447.GA57907@ocelot.phlegethon.org>
In-Reply-To: <20120217132447.GA57907@ocelot.phlegethon.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/12 13:24, Tim Deegan wrote:
> At 12:10 +0000 on 17 Feb (1329480642), David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> alloca() does not return NULL on an allocation failure
> 
> Nack: on some BSD systems it does. 

xc_linux_osdep.c is only built if CONFIG_Linux is set.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:35:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNxc-0007U1-5e; Fri, 17 Feb 2012 13:34:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyNxa-0007TT-96
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:34:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329485684!15296639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7044 invoked from network); 17 Feb 2012 13:34:44 -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;
	17 Feb 2012 13:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10773310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 13:34:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 13:34:43 +0000
Message-ID: <1329485681.3131.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 17 Feb 2012 13:34:41 +0000
In-Reply-To: <1329484462005-5492438.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 13:14 +0000, Fantu wrote:
> With only second patch fail:

Right, you need both patches since the second relies on the renaming
done in the first..



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:35:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:35:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyNxc-0007U1-5e; Fri, 17 Feb 2012 13:34:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyNxa-0007TT-96
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:34:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329485684!15296639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7044 invoked from network); 17 Feb 2012 13:34:44 -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;
	17 Feb 2012 13:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10773310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 13:34:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 13:34:43 +0000
Message-ID: <1329485681.3131.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 17 Feb 2012 13:34:41 +0000
In-Reply-To: <1329484462005-5492438.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 13:14 +0000, Fantu wrote:
> With only second patch fail:

Right, you need both patches since the second relies on the renaming
done in the first..



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:37:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyNzn-0007es-OC; Fri, 17 Feb 2012 13:37:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyNzl-0007eT-NR
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:37:05 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329485818!13734427!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24841 invoked from network); 17 Feb 2012 13:36:59 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 13:36:59 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyNzd-0005gj-EH
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 05:36:57 -0800
Date: Fri, 17 Feb 2012 05:36:57 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329485817436-5492514.post@n5.nabble.com>
In-Reply-To: <1329485681.3131.77.camel@zakaz.uk.xensource.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
	<1329485681.3131.77.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

With the 2 patches build done without error, now I also start testing xen
unstable on Wheezy.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492514.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:37:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyNzn-0007es-OC; Fri, 17 Feb 2012 13:37:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyNzl-0007eT-NR
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:37:05 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329485818!13734427!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24841 invoked from network); 17 Feb 2012 13:36:59 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 13:36:59 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyNzd-0005gj-EH
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 05:36:57 -0800
Date: Fri, 17 Feb 2012 05:36:57 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329485817436-5492514.post@n5.nabble.com>
In-Reply-To: <1329485681.3131.77.camel@zakaz.uk.xensource.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
	<1329485681.3131.77.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

With the 2 patches build done without error, now I also start testing xen
unstable on Wheezy.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492514.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyO12-0007lA-C2; Fri, 17 Feb 2012 13:38:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyO10-0007km-DX
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:38:22 +0000
Received: from [85.158.139.83:53952] by server-5.bemta-5.messagelabs.com id
	9E/EE-13566-C485E3F4; Fri, 17 Feb 2012 13:38:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329485900!15502442!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27673 invoked from network); 17 Feb 2012 13:38:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 13:38:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyO0x-000F8W-KK; Fri, 17 Feb 2012 13:38:19 +0000
Date: Fri, 17 Feb 2012 13:38:19 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120217133819.GB57907@ocelot.phlegethon.org>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
	<20120217132447.GA57907@ocelot.phlegethon.org>
	<4F3E5703.1080407@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3E5703.1080407@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:32 +0000 on 17 Feb (1329485571), David Vrabel wrote:
> On 17/02/12 13:24, Tim Deegan wrote:
> > At 12:10 +0000 on 17 Feb (1329480642), David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> alloca() does not return NULL on an allocation failure
> > 
> > Nack: on some BSD systems it does. 
> 
> xc_linux_osdep.c is only built if CONFIG_Linux is set.

My apologies - I didn't see that this was in os-specific code. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:38:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyO12-0007lA-C2; Fri, 17 Feb 2012 13:38:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyO10-0007km-DX
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:38:22 +0000
Received: from [85.158.139.83:53952] by server-5.bemta-5.messagelabs.com id
	9E/EE-13566-C485E3F4; Fri, 17 Feb 2012 13:38:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329485900!15502442!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27673 invoked from network); 17 Feb 2012 13:38:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 13:38:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyO0x-000F8W-KK; Fri, 17 Feb 2012 13:38:19 +0000
Date: Fri, 17 Feb 2012 13:38:19 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120217133819.GB57907@ocelot.phlegethon.org>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
	<20120217132447.GA57907@ocelot.phlegethon.org>
	<4F3E5703.1080407@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3E5703.1080407@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:32 +0000 on 17 Feb (1329485571), David Vrabel wrote:
> On 17/02/12 13:24, Tim Deegan wrote:
> > At 12:10 +0000 on 17 Feb (1329480642), David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> alloca() does not return NULL on an allocation failure
> > 
> > Nack: on some BSD systems it does. 
> 
> xc_linux_osdep.c is only built if CONFIG_Linux is set.

My apologies - I didn't see that this was in os-specific code. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:44:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyO6c-00087H-HP; Fri, 17 Feb 2012 13:44:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyO6a-000870-Sp
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:44:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329486242!6458877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19788 invoked from network); 17 Feb 2012 13:44:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 13:44:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10773516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 13:44:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 13:44:02 +0000
Message-ID: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 13:44:01 +0000
In-Reply-To: <d368cf36d66c1e8df60b.1329378421@probook.site>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 07:47 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1329378376 -3600
> # Node ID d368cf36d66c1e8df60bd0a4868c171b6a929edc
> # Parent  bf0a7c205687857a8f8d3bd3841654ed61828193
> RFC: initial libxl support for xenpaging
> 
> After the previous discussion about integration of xenpaging into xl/libxl it
> was not clear to me wether my proposal as a whole or only parts of it were
> rejected. So here is my current understanding of the comments I received.
> 
> Add initial support to libxl to start xenpaging for a HVM guest.
> These are the considerations:
> - a knob in domU.cfg is needed to start xenpaging
> - xenpaging needs a target in KiB in "memory/target-tot_pages"
>  -> the knob should be the target value in MiB: mem_target_paging=NUM
>     if the value is 0, xenpaging is not started

Wasn't the plan that the knob exported by xl should be a boolean and
that libxl should have the full value in its API, or am I
misremembering?

IOW at the libxl layer we have the full semantics available to callers
but at the xl layer we only expose one "target memory" value to users
which we expect the guest to use ballooning to reach but which we
"enforce" with paging if they don't comply.

[...] 
> - I have some ideas to add runtime tuneables for xenpaging. Should there be a
>   "xl xenpaging_ctrl tuneable_name value" command, or should it be done with a
>   new tool xenpaging_ctrl? If the latter, the proposed 'xl mem-target-*'
>   commands are not needed and this new helper could also adjust
>   "memory/target-tot_pages".

I think users would reasonably expect to always interact with the paging
daemon via the toolstack, at least for normal non-debug operations, and
so the paging daemon should not have any public interface.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 13:44:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 13:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyO6c-00087H-HP; Fri, 17 Feb 2012 13:44:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyO6a-000870-Sp
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 13:44:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329486242!6458877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19788 invoked from network); 17 Feb 2012 13:44:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 13:44:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10773516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 13:44:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 13:44:02 +0000
Message-ID: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 13:44:01 +0000
In-Reply-To: <d368cf36d66c1e8df60b.1329378421@probook.site>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-02-16 at 07:47 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1329378376 -3600
> # Node ID d368cf36d66c1e8df60bd0a4868c171b6a929edc
> # Parent  bf0a7c205687857a8f8d3bd3841654ed61828193
> RFC: initial libxl support for xenpaging
> 
> After the previous discussion about integration of xenpaging into xl/libxl it
> was not clear to me wether my proposal as a whole or only parts of it were
> rejected. So here is my current understanding of the comments I received.
> 
> Add initial support to libxl to start xenpaging for a HVM guest.
> These are the considerations:
> - a knob in domU.cfg is needed to start xenpaging
> - xenpaging needs a target in KiB in "memory/target-tot_pages"
>  -> the knob should be the target value in MiB: mem_target_paging=NUM
>     if the value is 0, xenpaging is not started

Wasn't the plan that the knob exported by xl should be a boolean and
that libxl should have the full value in its API, or am I
misremembering?

IOW at the libxl layer we have the full semantics available to callers
but at the xl layer we only expose one "target memory" value to users
which we expect the guest to use ballooning to reach but which we
"enforce" with paging if they don't comply.

[...] 
> - I have some ideas to add runtime tuneables for xenpaging. Should there be a
>   "xl xenpaging_ctrl tuneable_name value" command, or should it be done with a
>   new tool xenpaging_ctrl? If the latter, the proposed 'xl mem-target-*'
>   commands are not needed and this new helper could also adjust
>   "memory/target-tot_pages".

I think users would reasonably expect to always interact with the paging
daemon via the toolstack, at least for normal non-debug operations, and
so the paging daemon should not have any public interface.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:26:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyOkg-0000Id-Fc; Fri, 17 Feb 2012 14:25:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyOkf-0000I7-1L
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:25:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329488726!15243153!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjg5MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjg5MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6864 invoked from network); 17 Feb 2012 14:25:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 14:25:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329488726; l=2187;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=yXeR25nXbPX87t3eQUxgxFTvwLA=;
	b=IHLZ12WpbT+O/l8slvhBvaAHZ+xV306dTJpw4mp2+7HnC0oQbI+XCCIRXwZDMYgkwdu
	PwUFfZpY+2n4V/nwL4JvRe4IUWVa7CwPhgnvrsZA9g8eA6VxvFcZLe0VBnxQrp9utzzxz
	ueJMyj/Y/E0OZqqozlVDW0qTwDJO97k7nfU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (cohen mo14) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d03c09o1HEHa6P ;
	Fri, 17 Feb 2012 15:25:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B28A018637; Fri, 17 Feb 2012 15:25:05 +0100 (CET)
Date: Fri, 17 Feb 2012 15:25:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217142505.GA10523@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> On Thu, 2012-02-16 at 07:47 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1329378376 -3600
> > # Node ID d368cf36d66c1e8df60bd0a4868c171b6a929edc
> > # Parent  bf0a7c205687857a8f8d3bd3841654ed61828193
> > RFC: initial libxl support for xenpaging
> > 
> > After the previous discussion about integration of xenpaging into xl/libxl it
> > was not clear to me wether my proposal as a whole or only parts of it were
> > rejected. So here is my current understanding of the comments I received.
> > 
> > Add initial support to libxl to start xenpaging for a HVM guest.
> > These are the considerations:
> > - a knob in domU.cfg is needed to start xenpaging
> > - xenpaging needs a target in KiB in "memory/target-tot_pages"
> >  -> the knob should be the target value in MiB: mem_target_paging=NUM
> >     if the value is 0, xenpaging is not started
> 
> Wasn't the plan that the knob exported by xl should be a boolean and
> that libxl should have the full value in its API, or am I
> misremembering?

That was not clear to me, thats why I'm asking again.

> IOW at the libxl layer we have the full semantics available to callers
> but at the xl layer we only expose one "target memory" value to users
> which we expect the guest to use ballooning to reach but which we
> "enforce" with paging if they don't comply.

So if I understand that right there should be a new boolean, like
xenpaging=yes/no?

In the .cfg it can be either like this, which appears to mean the pager
is started but has no target (or target is N itself):

memory=N
xenpaging=yes

Or it could be like this (in which case the pager currently cant start
due to lack of PoD support):

memory=N
maxmem=N+X
xenpaging=yes


In both cases "xl mem-set" will adjust both ballooning and paging values?
Should there be xl commands to adjust just ballooning and/or paging?


Regarding the tuning knobs, right now I can only think of the policy mru
size and the number of evicts before checking for new events.
So you propose to have something like "xl xenpaging domid knob value"?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:26:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyOkg-0000Id-Fc; Fri, 17 Feb 2012 14:25:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyOkf-0000I7-1L
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:25:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329488726!15243153!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjg5MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjg5MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6864 invoked from network); 17 Feb 2012 14:25:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 14:25:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329488726; l=2187;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=yXeR25nXbPX87t3eQUxgxFTvwLA=;
	b=IHLZ12WpbT+O/l8slvhBvaAHZ+xV306dTJpw4mp2+7HnC0oQbI+XCCIRXwZDMYgkwdu
	PwUFfZpY+2n4V/nwL4JvRe4IUWVa7CwPhgnvrsZA9g8eA6VxvFcZLe0VBnxQrp9utzzxz
	ueJMyj/Y/E0OZqqozlVDW0qTwDJO97k7nfU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (cohen mo14) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d03c09o1HEHa6P ;
	Fri, 17 Feb 2012 15:25:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B28A018637; Fri, 17 Feb 2012 15:25:05 +0100 (CET)
Date: Fri, 17 Feb 2012 15:25:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217142505.GA10523@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> On Thu, 2012-02-16 at 07:47 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1329378376 -3600
> > # Node ID d368cf36d66c1e8df60bd0a4868c171b6a929edc
> > # Parent  bf0a7c205687857a8f8d3bd3841654ed61828193
> > RFC: initial libxl support for xenpaging
> > 
> > After the previous discussion about integration of xenpaging into xl/libxl it
> > was not clear to me wether my proposal as a whole or only parts of it were
> > rejected. So here is my current understanding of the comments I received.
> > 
> > Add initial support to libxl to start xenpaging for a HVM guest.
> > These are the considerations:
> > - a knob in domU.cfg is needed to start xenpaging
> > - xenpaging needs a target in KiB in "memory/target-tot_pages"
> >  -> the knob should be the target value in MiB: mem_target_paging=NUM
> >     if the value is 0, xenpaging is not started
> 
> Wasn't the plan that the knob exported by xl should be a boolean and
> that libxl should have the full value in its API, or am I
> misremembering?

That was not clear to me, thats why I'm asking again.

> IOW at the libxl layer we have the full semantics available to callers
> but at the xl layer we only expose one "target memory" value to users
> which we expect the guest to use ballooning to reach but which we
> "enforce" with paging if they don't comply.

So if I understand that right there should be a new boolean, like
xenpaging=yes/no?

In the .cfg it can be either like this, which appears to mean the pager
is started but has no target (or target is N itself):

memory=N
xenpaging=yes

Or it could be like this (in which case the pager currently cant start
due to lack of PoD support):

memory=N
maxmem=N+X
xenpaging=yes


In both cases "xl mem-set" will adjust both ballooning and paging values?
Should there be xl commands to adjust just ballooning and/or paging?


Regarding the tuning knobs, right now I can only think of the policy mru
size and the number of evicts before checking for new events.
So you propose to have something like "xl xenpaging domid knob value"?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:33:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyOrU-0000a5-BO; Fri, 17 Feb 2012 14:32:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyOrT-0000Zm-24
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:32:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329489147!13599592!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1059 invoked from network); 17 Feb 2012 14:32:28 -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; 17 Feb 2012 14:32:28 -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 q1HEWI9B017360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:32:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1HEWHtI002998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:32:18 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
	q1HEWGen029620; Fri, 17 Feb 2012 08:32:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:32:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA21F41FE1; Fri, 17 Feb 2012 09:29:09 -0500 (EST)
Date: Fri, 17 Feb 2012 09:29:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217142909.GA29110@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F3E64F4.00D4,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
> >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch for Xen
>  core parking.

You need to CC the ACPI maintainer and the acpi mailing on this patch. I did that
for you in the CC.


> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   10 +++++
>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>  arch/x86/kernel/paravirt.c            |    9 +++++
>  drivers/acpi/acpi_pad.c               |   15 +++-----
>  include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++++++
>  5 files changed, 93 insertions(+), 9 deletions(-)
>  create mode 100644 include/acpi/acpi_pad.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index a7d2db9..02e6df0 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
>  }
>  
> +static inline int __acpi_pad_init(void)
> +{
> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> +}
> +
>  static inline void write_cr0(unsigned long x)
>  {
>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..61e20de 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -336,6 +336,11 @@ struct pv_lock_ops {
>  	void (*spin_unlock)(struct arch_spinlock *lock);
>  };
>  
> +struct pv_pad_ops {
> +	int (*acpi_pad_init)(void);
> +	void (*acpi_pad_exit)(void);
> +};
> +
>  /* This contains all the paravirt structures: we get a convenient
>   * number for each function using the offset which we use to indicate
>   * what to patch. */
> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>  	struct pv_apic_ops pv_apic_ops;
>  	struct pv_mmu_ops pv_mmu_ops;
>  	struct pv_lock_ops pv_lock_ops;
> +	struct pv_pad_ops pv_pad_ops;
>  };
>  
>  extern struct pv_info pv_info;
> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>  extern struct pv_apic_ops pv_apic_ops;
>  extern struct pv_mmu_ops pv_mmu_ops;
>  extern struct pv_lock_ops pv_lock_ops;
> +extern struct pv_pad_ops pv_pad_ops;
>  
>  #define PARAVIRT_PATCH(x)					\
>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index d90272e..ec778f6 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -38,6 +38,8 @@
>  #include <asm/tlbflush.h>
>  #include <asm/timer.h>
>  
> +#include <acpi/acpi_pad.h>
> +
>  /* nop stub */
>  void _paravirt_nop(void)
>  {
> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>  		.pv_lock_ops = pv_lock_ops,
>  #endif
> +		.pv_pad_ops = pv_pad_ops,
>  	};
>  	return *((void **)&tmpl + type);
>  }
> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>  	.set_fixmap = native_set_fixmap,
>  };
>  
> +struct pv_pad_ops pv_pad_ops = {
> +	.acpi_pad_init = native_acpi_pad_init,
> +	.acpi_pad_exit = native_acpi_pad_exit,
> +};
> +
>  EXPORT_SYMBOL_GPL(pv_time_ops);
>  EXPORT_SYMBOL    (pv_cpu_ops);
>  EXPORT_SYMBOL    (pv_mmu_ops);
>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>  EXPORT_SYMBOL_GPL(pv_info);
>  EXPORT_SYMBOL    (pv_irq_ops);
> +EXPORT_SYMBOL_GPL(pv_pad_ops);
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index a43fa1a..3f0fd27 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -30,6 +30,7 @@
>  #include <linux/slab.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_pad.h>
>  #include <asm/mwait.h>
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> @@ -37,14 +38,14 @@
>  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>  static DEFINE_MUTEX(isolated_cpus_lock);
>  
> -static unsigned long power_saving_mwait_eax;
> +unsigned long power_saving_mwait_eax;
>  
>  static unsigned char tsc_detected_unstable;
>  static unsigned char tsc_marked_unstable;
>  static unsigned char lapic_detected_unstable;
>  static unsigned char lapic_marked_unstable;
>  
> -static void power_saving_mwait_init(void)
> +void power_saving_mwait_init(void)
>  {
>  	unsigned int eax, ebx, ecx, edx;
>  	unsigned int highest_cstate = 0;
> @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>  
> -static struct acpi_driver acpi_pad_driver = {
> +struct acpi_driver acpi_pad_driver = {
>  	.name = "processor_aggregator",
>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>  	.ids = pad_device_ids,
> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> -	power_saving_mwait_init();
> -	if (power_saving_mwait_eax == 0)
> -		return -EINVAL;
> -
> -	return acpi_bus_register_driver(&acpi_pad_driver);
> +	return __acpi_pad_init();
>  }
>  
>  static void __exit acpi_pad_exit(void)
>  {
> -	acpi_bus_unregister_driver(&acpi_pad_driver);
> +	__acpi_pad_exit();
>  }
>  
>  module_init(acpi_pad_init);
> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> new file mode 100644
> index 0000000..1a1471d
> --- /dev/null
> +++ b/include/acpi/acpi_pad.h
> @@ -0,0 +1,61 @@
> +/*
> + *  acpi_pad.h - pad device helper for native and paravirt platform
> + *
> + *  Copyright (C) 2012, Intel Corporation.
> + *     Author: 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.
> + */
> +
> +#ifndef __ACPI_PAD_H__
> +#define __ACPI_PAD_H__
> +
> +#include <acpi/acpi_bus.h>
> +
> +extern unsigned long power_saving_mwait_eax;
> +extern struct acpi_driver acpi_pad_driver;
> +extern void power_saving_mwait_init(void);
> +
> +static inline int native_acpi_pad_init(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	power_saving_mwait_init();
> +	if (power_saving_mwait_eax == 0)
> +		return -EINVAL;
> +
> +	return acpi_bus_register_driver(&acpi_pad_driver);
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static inline void native_acpi_pad_exit(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&acpi_pad_driver);
> +#endif
> +}
> +
> +#ifdef CONFIG_PARAVIRT
> +#include <asm/paravirt.h>
> +#else
> +static inline int __acpi_pad_init(void)
> +{
> +	return native_acpi_pad_init();
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	native_acpi_pad_exit();
> +}
> +#endif
> +
> +#endif /* __ACPI_PAD_H__ */
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:33:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyOrU-0000a5-BO; Fri, 17 Feb 2012 14:32:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyOrT-0000Zm-24
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:32:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329489147!13599592!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1059 invoked from network); 17 Feb 2012 14:32:28 -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; 17 Feb 2012 14:32:28 -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 q1HEWI9B017360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:32:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1HEWHtI002998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:32:18 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
	q1HEWGen029620; Fri, 17 Feb 2012 08:32:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:32:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA21F41FE1; Fri, 17 Feb 2012 09:29:09 -0500 (EST)
Date: Fri, 17 Feb 2012 09:29:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217142909.GA29110@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F3E64F4.00D4,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
> >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch for Xen
>  core parking.

You need to CC the ACPI maintainer and the acpi mailing on this patch. I did that
for you in the CC.


> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   10 +++++
>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>  arch/x86/kernel/paravirt.c            |    9 +++++
>  drivers/acpi/acpi_pad.c               |   15 +++-----
>  include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++++++
>  5 files changed, 93 insertions(+), 9 deletions(-)
>  create mode 100644 include/acpi/acpi_pad.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index a7d2db9..02e6df0 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
>  }
>  
> +static inline int __acpi_pad_init(void)
> +{
> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> +}
> +
>  static inline void write_cr0(unsigned long x)
>  {
>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..61e20de 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -336,6 +336,11 @@ struct pv_lock_ops {
>  	void (*spin_unlock)(struct arch_spinlock *lock);
>  };
>  
> +struct pv_pad_ops {
> +	int (*acpi_pad_init)(void);
> +	void (*acpi_pad_exit)(void);
> +};
> +
>  /* This contains all the paravirt structures: we get a convenient
>   * number for each function using the offset which we use to indicate
>   * what to patch. */
> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>  	struct pv_apic_ops pv_apic_ops;
>  	struct pv_mmu_ops pv_mmu_ops;
>  	struct pv_lock_ops pv_lock_ops;
> +	struct pv_pad_ops pv_pad_ops;
>  };
>  
>  extern struct pv_info pv_info;
> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>  extern struct pv_apic_ops pv_apic_ops;
>  extern struct pv_mmu_ops pv_mmu_ops;
>  extern struct pv_lock_ops pv_lock_ops;
> +extern struct pv_pad_ops pv_pad_ops;
>  
>  #define PARAVIRT_PATCH(x)					\
>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index d90272e..ec778f6 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -38,6 +38,8 @@
>  #include <asm/tlbflush.h>
>  #include <asm/timer.h>
>  
> +#include <acpi/acpi_pad.h>
> +
>  /* nop stub */
>  void _paravirt_nop(void)
>  {
> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>  		.pv_lock_ops = pv_lock_ops,
>  #endif
> +		.pv_pad_ops = pv_pad_ops,
>  	};
>  	return *((void **)&tmpl + type);
>  }
> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>  	.set_fixmap = native_set_fixmap,
>  };
>  
> +struct pv_pad_ops pv_pad_ops = {
> +	.acpi_pad_init = native_acpi_pad_init,
> +	.acpi_pad_exit = native_acpi_pad_exit,
> +};
> +
>  EXPORT_SYMBOL_GPL(pv_time_ops);
>  EXPORT_SYMBOL    (pv_cpu_ops);
>  EXPORT_SYMBOL    (pv_mmu_ops);
>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>  EXPORT_SYMBOL_GPL(pv_info);
>  EXPORT_SYMBOL    (pv_irq_ops);
> +EXPORT_SYMBOL_GPL(pv_pad_ops);
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index a43fa1a..3f0fd27 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -30,6 +30,7 @@
>  #include <linux/slab.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_pad.h>
>  #include <asm/mwait.h>
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> @@ -37,14 +38,14 @@
>  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>  static DEFINE_MUTEX(isolated_cpus_lock);
>  
> -static unsigned long power_saving_mwait_eax;
> +unsigned long power_saving_mwait_eax;
>  
>  static unsigned char tsc_detected_unstable;
>  static unsigned char tsc_marked_unstable;
>  static unsigned char lapic_detected_unstable;
>  static unsigned char lapic_marked_unstable;
>  
> -static void power_saving_mwait_init(void)
> +void power_saving_mwait_init(void)
>  {
>  	unsigned int eax, ebx, ecx, edx;
>  	unsigned int highest_cstate = 0;
> @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>  
> -static struct acpi_driver acpi_pad_driver = {
> +struct acpi_driver acpi_pad_driver = {
>  	.name = "processor_aggregator",
>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>  	.ids = pad_device_ids,
> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> -	power_saving_mwait_init();
> -	if (power_saving_mwait_eax == 0)
> -		return -EINVAL;
> -
> -	return acpi_bus_register_driver(&acpi_pad_driver);
> +	return __acpi_pad_init();
>  }
>  
>  static void __exit acpi_pad_exit(void)
>  {
> -	acpi_bus_unregister_driver(&acpi_pad_driver);
> +	__acpi_pad_exit();
>  }
>  
>  module_init(acpi_pad_init);
> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> new file mode 100644
> index 0000000..1a1471d
> --- /dev/null
> +++ b/include/acpi/acpi_pad.h
> @@ -0,0 +1,61 @@
> +/*
> + *  acpi_pad.h - pad device helper for native and paravirt platform
> + *
> + *  Copyright (C) 2012, Intel Corporation.
> + *     Author: 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.
> + */
> +
> +#ifndef __ACPI_PAD_H__
> +#define __ACPI_PAD_H__
> +
> +#include <acpi/acpi_bus.h>
> +
> +extern unsigned long power_saving_mwait_eax;
> +extern struct acpi_driver acpi_pad_driver;
> +extern void power_saving_mwait_init(void);
> +
> +static inline int native_acpi_pad_init(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	power_saving_mwait_init();
> +	if (power_saving_mwait_eax == 0)
> +		return -EINVAL;
> +
> +	return acpi_bus_register_driver(&acpi_pad_driver);
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static inline void native_acpi_pad_exit(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&acpi_pad_driver);
> +#endif
> +}
> +
> +#ifdef CONFIG_PARAVIRT
> +#include <asm/paravirt.h>
> +#else
> +static inline int __acpi_pad_init(void)
> +{
> +	return native_acpi_pad_init();
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	native_acpi_pad_exit();
> +}
> +#endif
> +
> +#endif /* __ACPI_PAD_H__ */
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:35:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyOtO-0000fJ-ST; Fri, 17 Feb 2012 14:34:34 +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 1RyOtM-0000ew-O6
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:34:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329489242!63959198!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26641 invoked from network); 17 Feb 2012 14:34:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 14:34:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1HEYM67011465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:34: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
	q1HEYLG4025116
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:34:21 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
	q1HEYL7v016565; Fri, 17 Feb 2012 08:34:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:34:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30FBC41FE1; Fri, 17 Feb 2012 09:31:14 -0500 (EST)
Date: Fri, 17 Feb 2012 09:31:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ge@@ru" <geaaru@gmail.com>
Message-ID: <20120217143114.GB29110@phenom.dumpdata.com>
References: <1329469038.4815.11.camel@ironlight2.geaaru.homelinux.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329469038.4815.11.camel@ironlight2.geaaru.homelinux.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F3E656F.0013,ss=1,re=0.000,fgs=0
Cc: Xen-Devel ML <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Dom0 with kernel 3.x and nvidia driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 09:57:18AM +0100, Ge@@ru wrote:
> Hi,
> 
> I have a problem on use nvidia driver inside xen-dom0 kernel, version
> 3.x (I do test with this version: 3.0.18, 3.1.5, 3.2.5.
> 
> Compilation of the driver is done without errors and yet load of the
> kernel driver is done correctly, but when I try to start X... I have
> first a black screen and then monitor that go on standby status. It
> seems that video card doesn't initialize correctly vga port.
> 
> I don't think that problem is on xorg server and I don't understand if
> problem is on nvidia kernel driver because, same xorg-server, same
> kernel image and same nvidia kernel module works fine if kernel is
> bootstrap without xen hypervisor.

Hm, strange. I have the problem where the nvidia driver won't work with 3.2
at all - baremetal or Xen.

> 
> Could be relative to a wrong configuration on pass-through of the video
> card bus from hypervisor to dom0 ? Is it correct speak of pass-through
> yet on dom0 or pass-through is only for domU domain?
> 
> Same nvidia kernel driver works correctly on dom0 if I use
> kernel-2.6.38-xen (gentoo ebuild).
> 
> Any suggestions ?
> 
> Thanks in advance
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:35:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyOtO-0000fJ-ST; Fri, 17 Feb 2012 14:34:34 +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 1RyOtM-0000ew-O6
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:34:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329489242!63959198!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26641 invoked from network); 17 Feb 2012 14:34:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 14:34:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1HEYM67011465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:34: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
	q1HEYLG4025116
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:34:21 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
	q1HEYL7v016565; Fri, 17 Feb 2012 08:34:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:34:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30FBC41FE1; Fri, 17 Feb 2012 09:31:14 -0500 (EST)
Date: Fri, 17 Feb 2012 09:31:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ge@@ru" <geaaru@gmail.com>
Message-ID: <20120217143114.GB29110@phenom.dumpdata.com>
References: <1329469038.4815.11.camel@ironlight2.geaaru.homelinux.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329469038.4815.11.camel@ironlight2.geaaru.homelinux.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F3E656F.0013,ss=1,re=0.000,fgs=0
Cc: Xen-Devel ML <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Dom0 with kernel 3.x and nvidia driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 09:57:18AM +0100, Ge@@ru wrote:
> Hi,
> 
> I have a problem on use nvidia driver inside xen-dom0 kernel, version
> 3.x (I do test with this version: 3.0.18, 3.1.5, 3.2.5.
> 
> Compilation of the driver is done without errors and yet load of the
> kernel driver is done correctly, but when I try to start X... I have
> first a black screen and then monitor that go on standby status. It
> seems that video card doesn't initialize correctly vga port.
> 
> I don't think that problem is on xorg server and I don't understand if
> problem is on nvidia kernel driver because, same xorg-server, same
> kernel image and same nvidia kernel module works fine if kernel is
> bootstrap without xen hypervisor.

Hm, strange. I have the problem where the nvidia driver won't work with 3.2
at all - baremetal or Xen.

> 
> Could be relative to a wrong configuration on pass-through of the video
> card bus from hypervisor to dom0 ? Is it correct speak of pass-through
> yet on dom0 or pass-through is only for domU domain?
> 
> Same nvidia kernel driver works correctly on dom0 if I use
> kernel-2.6.38-xen (gentoo ebuild).
> 
> Any suggestions ?
> 
> Thanks in advance
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:41:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyOzX-0000x3-Qk; Fri, 17 Feb 2012 14:40:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyOzW-0000wl-Jm
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:40:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329489644!14757161!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6904 invoked from network); 17 Feb 2012 14:40:46 -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; 17 Feb 2012 14:40:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1HEeaJ9017899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:40:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1HEeZbF017396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:40:35 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1HEeY52003818; Fri, 17 Feb 2012 08:40:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:40:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8257E41FE1; Fri, 17 Feb 2012 09:37:27 -0500 (EST)
Date: Fri, 17 Feb 2012 09:37:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217143727.GC29110@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090205.4F3E66E6.0002,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 08:58:38AM +0000, Liu, Jinsong wrote:
> >From fee39804d2634dfba7b369dc82dac19b57400f84 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Sat, 18 Feb 2012 00:46:29 +0800
> Subject: [PATCH 3/3] Xen pad logic and notification
> 
> This patch implement Xen pad logic, and when getting pad device
> notification, it hypercalls to Xen hypervisor for core parking.

CC-ing linux-acpi@vger.kernel.org and Len Brown.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  drivers/xen/xen_acpi_pad.c       |  189 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   14 +++
>  2 files changed, 203 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
> index 63ab2fb..ba66d51 100644
> --- a/drivers/xen/xen_acpi_pad.c
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -1,8 +1,197 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *    Author: Liu, Jinsong <jinsong.liu@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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/acpi_drivers.h>
> +
> +#include <asm/xen/hypercall.h>
> +
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "xen_acpi_pad"
> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Xen Processor Aggregator"
> +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> +static DEFINE_MUTEX(xen_cpu_lock);
> +
> +static int xen_acpi_pad_idle_cpus(int *num_cpus)
> +{
> +	int ret;
> +
> +	struct xen_platform_op op = {
> +		.cmd = XENPF_core_parking,
> +		.interface_version = XENPF_INTERFACE_VERSION,
> +	};
> +
> +	/* set cpu nums expected to be idled */
> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
> +	op.u.core_parking.idle_nums = (uint32_t)*num_cpus;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * get cpu nums actually be idled
> +	 * cannot get it by using hypercall once (shared with _SET)
> +	 * because of the characteristic of Xen continue_hypercall_on_cpu
> +	 */
> +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	*num_cpus = op.u.core_parking.idle_nums;
> +	return 0;
> +}
> +
> +/*
> + * Query firmware how many CPUs should be idle
> + * return -1 on failure
> + */
> +static int xen_acpi_pad_pur(acpi_handle handle)
> +{
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> +	union acpi_object *package;
> +	int num = -1;
> +
> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
> +		return num;
> +
> +	if (!buffer.length || !buffer.pointer)
> +		return num;
> +
> +	package = buffer.pointer;
> +
> +	if (package->type == ACPI_TYPE_PACKAGE &&
> +		package->package.count == 2 &&
> +		package->package.elements[0].integer.value == 1) /* rev 1 */
> +
> +		num = package->package.elements[1].integer.value;
> +
> +	kfree(buffer.pointer);
> +	return num;
> +}
> +
> +/* Notify firmware how many CPUs are idle */
> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
> +	uint32_t idle_cpus)
> +{
> +	union acpi_object params[3] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_BUFFER,},
> +	};
> +	struct acpi_object_list arg_list = {3, params};
> +
> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
> +	params[1].integer.value =  stat;
> +	params[2].buffer.length = 4;
> +	params[2].buffer.pointer = (void *)&idle_cpus;
> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
> +}
> +
> +static void xen_acpi_pad_handle_notify(acpi_handle handle)
> +{
> +	int ret, num_cpus;
> +
> +	mutex_lock(&xen_cpu_lock);
> +	num_cpus = xen_acpi_pad_pur(handle);
> +	if (num_cpus < 0) {
> +		mutex_unlock(&xen_cpu_lock);
> +		return;
> +	}
> +
> +	ret = xen_acpi_pad_idle_cpus(&num_cpus);
> +	if (ret) {
> +		mutex_unlock(&xen_cpu_lock);
> +		return;
> +	}
> +
> +	xen_acpi_pad_ost(handle, 0, num_cpus);
> +	mutex_unlock(&xen_cpu_lock);
> +}
> +
> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
> +	void *data)
> +{
> +	switch (event) {
> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
> +		xen_acpi_pad_handle_notify(handle);
> +		break;
> +	default:
> +		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
> +		break;
> +	}
> +}
> +
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	acpi_status status;
> +
> +	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
> +	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
> +
> +	status = acpi_install_notify_handler(device->handle,
> +		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
> +static int xen_acpi_pad_remove(struct acpi_device *device,
> +	int type)
> +{
> +	int num_cpus = 0;
> +
> +	mutex_lock(&xen_cpu_lock);
> +	xen_acpi_pad_idle_cpus(&num_cpus);
> +	mutex_unlock(&xen_cpu_lock);
> +
> +	acpi_remove_notify_handler(device->handle,
> +		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
> +	return 0;
> +}
> +
> +static const struct acpi_device_id xen_pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "xen_processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = xen_pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,
> +		.remove = xen_acpi_pad_remove,
> +	},
> +};
> +
>  int xen_acpi_pad_init(void)
>  {
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR

How does that work when the the driver is booted under baremetal? Won't
it kick out the native ACPI_PROCESSOR_AGGREGATOR_CLASS (acpi_pad.c) ?

What about if the other ACPI_PROCESSOR_AGGREGATOR_CLASS gets called first?
Won't this fail?

Or is the acpi_bus_register_driver smart enough to process more than one
ACPI bus device?

> +	return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +#else
>  	return 0;
> +#endif
>  }
>  
>  void xen_acpi_pad_exit(void)
>  {
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&xen_acpi_pad_driver);
> +#endif
>  }
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index c168468..56ec72a 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
>  
> +#define XENPF_core_parking      60
> +
> +#define XEN_CORE_PARKING_SET    1
> +#define XEN_CORE_PARKING_GET    2
> +struct xenpf_core_parking {
> +	/* IN variables */
> +	uint32_t type;
> +	/* IN variables:  set cpu nums expected to be idled */
> +	/* OUT variables: get cpu nums actually be idled */
> +	uint32_t idle_nums;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -312,6 +325,7 @@ struct xen_platform_op {
>  		struct xenpf_change_freq       change_freq;
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
> +		struct xenpf_core_parking      core_parking;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:41:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyOzX-0000x3-Qk; Fri, 17 Feb 2012 14:40:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyOzW-0000wl-Jm
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:40:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329489644!14757161!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6904 invoked from network); 17 Feb 2012 14:40:46 -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; 17 Feb 2012 14:40:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1HEeaJ9017899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:40:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1HEeZbF017396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:40:35 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1HEeY52003818; Fri, 17 Feb 2012 08:40:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:40:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8257E41FE1; Fri, 17 Feb 2012 09:37:27 -0500 (EST)
Date: Fri, 17 Feb 2012 09:37:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217143727.GC29110@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090205.4F3E66E6.0002,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 08:58:38AM +0000, Liu, Jinsong wrote:
> >From fee39804d2634dfba7b369dc82dac19b57400f84 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Sat, 18 Feb 2012 00:46:29 +0800
> Subject: [PATCH 3/3] Xen pad logic and notification
> 
> This patch implement Xen pad logic, and when getting pad device
> notification, it hypercalls to Xen hypervisor for core parking.

CC-ing linux-acpi@vger.kernel.org and Len Brown.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  drivers/xen/xen_acpi_pad.c       |  189 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   14 +++
>  2 files changed, 203 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
> index 63ab2fb..ba66d51 100644
> --- a/drivers/xen/xen_acpi_pad.c
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -1,8 +1,197 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *    Author: Liu, Jinsong <jinsong.liu@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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/acpi_drivers.h>
> +
> +#include <asm/xen/hypercall.h>
> +
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "xen_acpi_pad"
> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Xen Processor Aggregator"
> +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> +static DEFINE_MUTEX(xen_cpu_lock);
> +
> +static int xen_acpi_pad_idle_cpus(int *num_cpus)
> +{
> +	int ret;
> +
> +	struct xen_platform_op op = {
> +		.cmd = XENPF_core_parking,
> +		.interface_version = XENPF_INTERFACE_VERSION,
> +	};
> +
> +	/* set cpu nums expected to be idled */
> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
> +	op.u.core_parking.idle_nums = (uint32_t)*num_cpus;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * get cpu nums actually be idled
> +	 * cannot get it by using hypercall once (shared with _SET)
> +	 * because of the characteristic of Xen continue_hypercall_on_cpu
> +	 */
> +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	*num_cpus = op.u.core_parking.idle_nums;
> +	return 0;
> +}
> +
> +/*
> + * Query firmware how many CPUs should be idle
> + * return -1 on failure
> + */
> +static int xen_acpi_pad_pur(acpi_handle handle)
> +{
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> +	union acpi_object *package;
> +	int num = -1;
> +
> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
> +		return num;
> +
> +	if (!buffer.length || !buffer.pointer)
> +		return num;
> +
> +	package = buffer.pointer;
> +
> +	if (package->type == ACPI_TYPE_PACKAGE &&
> +		package->package.count == 2 &&
> +		package->package.elements[0].integer.value == 1) /* rev 1 */
> +
> +		num = package->package.elements[1].integer.value;
> +
> +	kfree(buffer.pointer);
> +	return num;
> +}
> +
> +/* Notify firmware how many CPUs are idle */
> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
> +	uint32_t idle_cpus)
> +{
> +	union acpi_object params[3] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_BUFFER,},
> +	};
> +	struct acpi_object_list arg_list = {3, params};
> +
> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
> +	params[1].integer.value =  stat;
> +	params[2].buffer.length = 4;
> +	params[2].buffer.pointer = (void *)&idle_cpus;
> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
> +}
> +
> +static void xen_acpi_pad_handle_notify(acpi_handle handle)
> +{
> +	int ret, num_cpus;
> +
> +	mutex_lock(&xen_cpu_lock);
> +	num_cpus = xen_acpi_pad_pur(handle);
> +	if (num_cpus < 0) {
> +		mutex_unlock(&xen_cpu_lock);
> +		return;
> +	}
> +
> +	ret = xen_acpi_pad_idle_cpus(&num_cpus);
> +	if (ret) {
> +		mutex_unlock(&xen_cpu_lock);
> +		return;
> +	}
> +
> +	xen_acpi_pad_ost(handle, 0, num_cpus);
> +	mutex_unlock(&xen_cpu_lock);
> +}
> +
> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
> +	void *data)
> +{
> +	switch (event) {
> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
> +		xen_acpi_pad_handle_notify(handle);
> +		break;
> +	default:
> +		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
> +		break;
> +	}
> +}
> +
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	acpi_status status;
> +
> +	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
> +	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
> +
> +	status = acpi_install_notify_handler(device->handle,
> +		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
> +static int xen_acpi_pad_remove(struct acpi_device *device,
> +	int type)
> +{
> +	int num_cpus = 0;
> +
> +	mutex_lock(&xen_cpu_lock);
> +	xen_acpi_pad_idle_cpus(&num_cpus);
> +	mutex_unlock(&xen_cpu_lock);
> +
> +	acpi_remove_notify_handler(device->handle,
> +		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
> +	return 0;
> +}
> +
> +static const struct acpi_device_id xen_pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "xen_processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = xen_pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,
> +		.remove = xen_acpi_pad_remove,
> +	},
> +};
> +
>  int xen_acpi_pad_init(void)
>  {
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR

How does that work when the the driver is booted under baremetal? Won't
it kick out the native ACPI_PROCESSOR_AGGREGATOR_CLASS (acpi_pad.c) ?

What about if the other ACPI_PROCESSOR_AGGREGATOR_CLASS gets called first?
Won't this fail?

Or is the acpi_bus_register_driver smart enough to process more than one
ACPI bus device?

> +	return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +#else
>  	return 0;
> +#endif
>  }
>  
>  void xen_acpi_pad_exit(void)
>  {
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&xen_acpi_pad_driver);
> +#endif
>  }
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index c168468..56ec72a 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
>  
> +#define XENPF_core_parking      60
> +
> +#define XEN_CORE_PARKING_SET    1
> +#define XEN_CORE_PARKING_GET    2
> +struct xenpf_core_parking {
> +	/* IN variables */
> +	uint32_t type;
> +	/* IN variables:  set cpu nums expected to be idled */
> +	/* OUT variables: get cpu nums actually be idled */
> +	uint32_t idle_nums;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -312,6 +325,7 @@ struct xen_platform_op {
>  		struct xenpf_change_freq       change_freq;
>  		struct xenpf_getidletime       getidletime;
>  		struct xenpf_set_processor_pminfo set_pminfo;
> +		struct xenpf_core_parking      core_parking;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyP9Q-0001CQ-5P; Fri, 17 Feb 2012 14:51: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 1RyP9O-0001CL-A4
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:51:06 +0000
Received: from [85.158.139.83:59278] by server-2.bemta-5.messagelabs.com id
	FF/9D-20263-9596E3F4; Fri, 17 Feb 2012 14:51:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329490262!15527365!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4080 invoked from network); 17 Feb 2012 14:51:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 14:51:03 -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 q1HEoreZ003430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:50:54 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
	q1HEopOV005646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:50:52 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
	q1HEoonQ005315; Fri, 17 Feb 2012 08:50:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:50:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E1D4641FE1; Fri, 17 Feb 2012 09:47:42 -0500 (EST)
Date: Fri, 17 Feb 2012 09:47:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217144742.GA29454@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120217142909.GA29110@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F3E694E.00DE,ss=1,re=-2.300,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 09:29:09AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
> > >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Fri, 10 Feb 2012 20:32:50 +0800
> > Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> > 
> > This patch is PAD (Processor Aggregator Device) helper.
> > It provides a native interface for natvie platform, and a template
> > for paravirt platform, so that os can implicitly hook to proper ops accordingly.
> > The paravirt template will further redirect to Xen pv ops in later patch for Xen
> >  core parking.
> 
> You need to CC the ACPI maintainer and the acpi mailing on this patch. I did that
> for you in the CC.
> 
> 
> > 
> > Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> > ---
> >  arch/x86/include/asm/paravirt.h       |   10 +++++
> >  arch/x86/include/asm/paravirt_types.h |    7 ++++
> >  arch/x86/kernel/paravirt.c            |    9 +++++
> >  drivers/acpi/acpi_pad.c               |   15 +++-----
> >  include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++++++
> >  5 files changed, 93 insertions(+), 9 deletions(-)
> >  create mode 100644 include/acpi/acpi_pad.h
> > 
> > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> > index a7d2db9..02e6df0 100644
> > --- a/arch/x86/include/asm/paravirt.h
> > +++ b/arch/x86/include/asm/paravirt.h
> > @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
> >  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
> >  }
> >  
> > +static inline int __acpi_pad_init(void)
> > +{
> > +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> > +}
> > +
> > +static inline void __acpi_pad_exit(void)
> > +{
> > +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> > +}
> > +
> >  static inline void write_cr0(unsigned long x)
> >  {
> >  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> > diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> > index 8e8b9a4..61e20de 100644
> > --- a/arch/x86/include/asm/paravirt_types.h
> > +++ b/arch/x86/include/asm/paravirt_types.h
> > @@ -336,6 +336,11 @@ struct pv_lock_ops {
> >  	void (*spin_unlock)(struct arch_spinlock *lock);
> >  };
> >  
> > +struct pv_pad_ops {
> > +	int (*acpi_pad_init)(void);
> > +	void (*acpi_pad_exit)(void);
> > +};
> > +

Looking at this a bit closer I am not sure why you choose the paravirt
interface for this? There is another one - the x86 that could have been
choosen. Or introduce a new one that is specific to ACPI.

I am curious - what was the reason for using the paravirt interface?
I understand it does get the job done, but it seems a bit overkill when something
simple could have been used?

> >  /* This contains all the paravirt structures: we get a convenient
> >   * number for each function using the offset which we use to indicate
> >   * what to patch. */
> > @@ -347,6 +352,7 @@ struct paravirt_patch_template {
> >  	struct pv_apic_ops pv_apic_ops;
> >  	struct pv_mmu_ops pv_mmu_ops;
> >  	struct pv_lock_ops pv_lock_ops;
> > +	struct pv_pad_ops pv_pad_ops;
> >  };
> >  
> >  extern struct pv_info pv_info;
> > @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
> >  extern struct pv_apic_ops pv_apic_ops;
> >  extern struct pv_mmu_ops pv_mmu_ops;
> >  extern struct pv_lock_ops pv_lock_ops;
> > +extern struct pv_pad_ops pv_pad_ops;
> >  
> >  #define PARAVIRT_PATCH(x)					\
> >  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> > index d90272e..ec778f6 100644
> > --- a/arch/x86/kernel/paravirt.c
> > +++ b/arch/x86/kernel/paravirt.c
> > @@ -38,6 +38,8 @@
> >  #include <asm/tlbflush.h>
> >  #include <asm/timer.h>
> >  
> > +#include <acpi/acpi_pad.h>
> > +
> >  /* nop stub */
> >  void _paravirt_nop(void)
> >  {
> > @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
> >  #ifdef CONFIG_PARAVIRT_SPINLOCKS
> >  		.pv_lock_ops = pv_lock_ops,
> >  #endif
> > +		.pv_pad_ops = pv_pad_ops,
> >  	};
> >  	return *((void **)&tmpl + type);
> >  }
> > @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
> >  	.set_fixmap = native_set_fixmap,
> >  };
> >  
> > +struct pv_pad_ops pv_pad_ops = {
> > +	.acpi_pad_init = native_acpi_pad_init,
> > +	.acpi_pad_exit = native_acpi_pad_exit,
> > +};
> > +
> >  EXPORT_SYMBOL_GPL(pv_time_ops);
> >  EXPORT_SYMBOL    (pv_cpu_ops);
> >  EXPORT_SYMBOL    (pv_mmu_ops);
> >  EXPORT_SYMBOL_GPL(pv_apic_ops);
> >  EXPORT_SYMBOL_GPL(pv_info);
> >  EXPORT_SYMBOL    (pv_irq_ops);
> > +EXPORT_SYMBOL_GPL(pv_pad_ops);
> > diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> > index a43fa1a..3f0fd27 100644
> > --- a/drivers/acpi/acpi_pad.c
> > +++ b/drivers/acpi/acpi_pad.c
> > @@ -30,6 +30,7 @@
> >  #include <linux/slab.h>
> >  #include <acpi/acpi_bus.h>
> >  #include <acpi/acpi_drivers.h>
> > +#include <acpi/acpi_pad.h>
> >  #include <asm/mwait.h>
> >  
> >  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> > @@ -37,14 +38,14 @@
> >  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> >  static DEFINE_MUTEX(isolated_cpus_lock);
> >  
> > -static unsigned long power_saving_mwait_eax;
> > +unsigned long power_saving_mwait_eax;
> >  
> >  static unsigned char tsc_detected_unstable;
> >  static unsigned char tsc_marked_unstable;
> >  static unsigned char lapic_detected_unstable;
> >  static unsigned char lapic_marked_unstable;
> >  
> > -static void power_saving_mwait_init(void)
> > +void power_saving_mwait_init(void)
> >  {
> >  	unsigned int eax, ebx, ecx, edx;
> >  	unsigned int highest_cstate = 0;
> > @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
> >  };
> >  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
> >  
> > -static struct acpi_driver acpi_pad_driver = {
> > +struct acpi_driver acpi_pad_driver = {
> >  	.name = "processor_aggregator",
> >  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> >  	.ids = pad_device_ids,
> > @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
> >  
> >  static int __init acpi_pad_init(void)
> >  {
> > -	power_saving_mwait_init();
> > -	if (power_saving_mwait_eax == 0)
> > -		return -EINVAL;
> > -
> > -	return acpi_bus_register_driver(&acpi_pad_driver);
> > +	return __acpi_pad_init();
> >  }
> >  
> >  static void __exit acpi_pad_exit(void)
> >  {
> > -	acpi_bus_unregister_driver(&acpi_pad_driver);
> > +	__acpi_pad_exit();
> >  }
> >  
> >  module_init(acpi_pad_init);
> > diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> > new file mode 100644
> > index 0000000..1a1471d
> > --- /dev/null
> > +++ b/include/acpi/acpi_pad.h
> > @@ -0,0 +1,61 @@
> > +/*
> > + *  acpi_pad.h - pad device helper for native and paravirt platform
> > + *
> > + *  Copyright (C) 2012, Intel Corporation.
> > + *     Author: 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.
> > + */
> > +
> > +#ifndef __ACPI_PAD_H__
> > +#define __ACPI_PAD_H__
> > +
> > +#include <acpi/acpi_bus.h>
> > +
> > +extern unsigned long power_saving_mwait_eax;
> > +extern struct acpi_driver acpi_pad_driver;
> > +extern void power_saving_mwait_init(void);
> > +
> > +static inline int native_acpi_pad_init(void)
> > +{
> > +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > +	power_saving_mwait_init();
> > +	if (power_saving_mwait_eax == 0)
> > +		return -EINVAL;
> > +
> > +	return acpi_bus_register_driver(&acpi_pad_driver);
> > +#else
> > +	return 0;
> > +#endif
> > +}
> > +
> > +static inline void native_acpi_pad_exit(void)
> > +{
> > +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > +	acpi_bus_unregister_driver(&acpi_pad_driver);
> > +#endif
> > +}
> > +
> > +#ifdef CONFIG_PARAVIRT
> > +#include <asm/paravirt.h>
> > +#else
> > +static inline int __acpi_pad_init(void)
> > +{
> > +	return native_acpi_pad_init();
> > +}
> > +
> > +static inline void __acpi_pad_exit(void)
> > +{
> > +	native_acpi_pad_exit();
> > +}
> > +#endif
> > +
> > +#endif /* __ACPI_PAD_H__ */
> > -- 
> > 1.7.1
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14: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.xensource.com>)
	id 1RyP9Q-0001CQ-5P; Fri, 17 Feb 2012 14:51: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 1RyP9O-0001CL-A4
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:51:06 +0000
Received: from [85.158.139.83:59278] by server-2.bemta-5.messagelabs.com id
	FF/9D-20263-9596E3F4; Fri, 17 Feb 2012 14:51:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329490262!15527365!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4080 invoked from network); 17 Feb 2012 14:51:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 14:51:03 -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 q1HEoreZ003430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 14:50:54 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
	q1HEopOV005646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 14:50:52 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
	q1HEoonQ005315; Fri, 17 Feb 2012 08:50:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 06:50:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E1D4641FE1; Fri, 17 Feb 2012 09:47:42 -0500 (EST)
Date: Fri, 17 Feb 2012 09:47:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217144742.GA29454@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120217142909.GA29110@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F3E694E.00DE,ss=1,re=-2.300,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 09:29:09AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
> > >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Fri, 10 Feb 2012 20:32:50 +0800
> > Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> > 
> > This patch is PAD (Processor Aggregator Device) helper.
> > It provides a native interface for natvie platform, and a template
> > for paravirt platform, so that os can implicitly hook to proper ops accordingly.
> > The paravirt template will further redirect to Xen pv ops in later patch for Xen
> >  core parking.
> 
> You need to CC the ACPI maintainer and the acpi mailing on this patch. I did that
> for you in the CC.
> 
> 
> > 
> > Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> > ---
> >  arch/x86/include/asm/paravirt.h       |   10 +++++
> >  arch/x86/include/asm/paravirt_types.h |    7 ++++
> >  arch/x86/kernel/paravirt.c            |    9 +++++
> >  drivers/acpi/acpi_pad.c               |   15 +++-----
> >  include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++++++
> >  5 files changed, 93 insertions(+), 9 deletions(-)
> >  create mode 100644 include/acpi/acpi_pad.h
> > 
> > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> > index a7d2db9..02e6df0 100644
> > --- a/arch/x86/include/asm/paravirt.h
> > +++ b/arch/x86/include/asm/paravirt.h
> > @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
> >  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
> >  }
> >  
> > +static inline int __acpi_pad_init(void)
> > +{
> > +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> > +}
> > +
> > +static inline void __acpi_pad_exit(void)
> > +{
> > +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> > +}
> > +
> >  static inline void write_cr0(unsigned long x)
> >  {
> >  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> > diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> > index 8e8b9a4..61e20de 100644
> > --- a/arch/x86/include/asm/paravirt_types.h
> > +++ b/arch/x86/include/asm/paravirt_types.h
> > @@ -336,6 +336,11 @@ struct pv_lock_ops {
> >  	void (*spin_unlock)(struct arch_spinlock *lock);
> >  };
> >  
> > +struct pv_pad_ops {
> > +	int (*acpi_pad_init)(void);
> > +	void (*acpi_pad_exit)(void);
> > +};
> > +

Looking at this a bit closer I am not sure why you choose the paravirt
interface for this? There is another one - the x86 that could have been
choosen. Or introduce a new one that is specific to ACPI.

I am curious - what was the reason for using the paravirt interface?
I understand it does get the job done, but it seems a bit overkill when something
simple could have been used?

> >  /* This contains all the paravirt structures: we get a convenient
> >   * number for each function using the offset which we use to indicate
> >   * what to patch. */
> > @@ -347,6 +352,7 @@ struct paravirt_patch_template {
> >  	struct pv_apic_ops pv_apic_ops;
> >  	struct pv_mmu_ops pv_mmu_ops;
> >  	struct pv_lock_ops pv_lock_ops;
> > +	struct pv_pad_ops pv_pad_ops;
> >  };
> >  
> >  extern struct pv_info pv_info;
> > @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
> >  extern struct pv_apic_ops pv_apic_ops;
> >  extern struct pv_mmu_ops pv_mmu_ops;
> >  extern struct pv_lock_ops pv_lock_ops;
> > +extern struct pv_pad_ops pv_pad_ops;
> >  
> >  #define PARAVIRT_PATCH(x)					\
> >  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> > index d90272e..ec778f6 100644
> > --- a/arch/x86/kernel/paravirt.c
> > +++ b/arch/x86/kernel/paravirt.c
> > @@ -38,6 +38,8 @@
> >  #include <asm/tlbflush.h>
> >  #include <asm/timer.h>
> >  
> > +#include <acpi/acpi_pad.h>
> > +
> >  /* nop stub */
> >  void _paravirt_nop(void)
> >  {
> > @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
> >  #ifdef CONFIG_PARAVIRT_SPINLOCKS
> >  		.pv_lock_ops = pv_lock_ops,
> >  #endif
> > +		.pv_pad_ops = pv_pad_ops,
> >  	};
> >  	return *((void **)&tmpl + type);
> >  }
> > @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
> >  	.set_fixmap = native_set_fixmap,
> >  };
> >  
> > +struct pv_pad_ops pv_pad_ops = {
> > +	.acpi_pad_init = native_acpi_pad_init,
> > +	.acpi_pad_exit = native_acpi_pad_exit,
> > +};
> > +
> >  EXPORT_SYMBOL_GPL(pv_time_ops);
> >  EXPORT_SYMBOL    (pv_cpu_ops);
> >  EXPORT_SYMBOL    (pv_mmu_ops);
> >  EXPORT_SYMBOL_GPL(pv_apic_ops);
> >  EXPORT_SYMBOL_GPL(pv_info);
> >  EXPORT_SYMBOL    (pv_irq_ops);
> > +EXPORT_SYMBOL_GPL(pv_pad_ops);
> > diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> > index a43fa1a..3f0fd27 100644
> > --- a/drivers/acpi/acpi_pad.c
> > +++ b/drivers/acpi/acpi_pad.c
> > @@ -30,6 +30,7 @@
> >  #include <linux/slab.h>
> >  #include <acpi/acpi_bus.h>
> >  #include <acpi/acpi_drivers.h>
> > +#include <acpi/acpi_pad.h>
> >  #include <asm/mwait.h>
> >  
> >  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> > @@ -37,14 +38,14 @@
> >  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> >  static DEFINE_MUTEX(isolated_cpus_lock);
> >  
> > -static unsigned long power_saving_mwait_eax;
> > +unsigned long power_saving_mwait_eax;
> >  
> >  static unsigned char tsc_detected_unstable;
> >  static unsigned char tsc_marked_unstable;
> >  static unsigned char lapic_detected_unstable;
> >  static unsigned char lapic_marked_unstable;
> >  
> > -static void power_saving_mwait_init(void)
> > +void power_saving_mwait_init(void)
> >  {
> >  	unsigned int eax, ebx, ecx, edx;
> >  	unsigned int highest_cstate = 0;
> > @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
> >  };
> >  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
> >  
> > -static struct acpi_driver acpi_pad_driver = {
> > +struct acpi_driver acpi_pad_driver = {
> >  	.name = "processor_aggregator",
> >  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> >  	.ids = pad_device_ids,
> > @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
> >  
> >  static int __init acpi_pad_init(void)
> >  {
> > -	power_saving_mwait_init();
> > -	if (power_saving_mwait_eax == 0)
> > -		return -EINVAL;
> > -
> > -	return acpi_bus_register_driver(&acpi_pad_driver);
> > +	return __acpi_pad_init();
> >  }
> >  
> >  static void __exit acpi_pad_exit(void)
> >  {
> > -	acpi_bus_unregister_driver(&acpi_pad_driver);
> > +	__acpi_pad_exit();
> >  }
> >  
> >  module_init(acpi_pad_init);
> > diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> > new file mode 100644
> > index 0000000..1a1471d
> > --- /dev/null
> > +++ b/include/acpi/acpi_pad.h
> > @@ -0,0 +1,61 @@
> > +/*
> > + *  acpi_pad.h - pad device helper for native and paravirt platform
> > + *
> > + *  Copyright (C) 2012, Intel Corporation.
> > + *     Author: 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.
> > + */
> > +
> > +#ifndef __ACPI_PAD_H__
> > +#define __ACPI_PAD_H__
> > +
> > +#include <acpi/acpi_bus.h>
> > +
> > +extern unsigned long power_saving_mwait_eax;
> > +extern struct acpi_driver acpi_pad_driver;
> > +extern void power_saving_mwait_init(void);
> > +
> > +static inline int native_acpi_pad_init(void)
> > +{
> > +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > +	power_saving_mwait_init();
> > +	if (power_saving_mwait_eax == 0)
> > +		return -EINVAL;
> > +
> > +	return acpi_bus_register_driver(&acpi_pad_driver);
> > +#else
> > +	return 0;
> > +#endif
> > +}
> > +
> > +static inline void native_acpi_pad_exit(void)
> > +{
> > +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > +	acpi_bus_unregister_driver(&acpi_pad_driver);
> > +#endif
> > +}
> > +
> > +#ifdef CONFIG_PARAVIRT
> > +#include <asm/paravirt.h>
> > +#else
> > +static inline int __acpi_pad_init(void)
> > +{
> > +	return native_acpi_pad_init();
> > +}
> > +
> > +static inline void __acpi_pad_exit(void)
> > +{
> > +	native_acpi_pad_exit();
> > +}
> > +#endif
> > +
> > +#endif /* __ACPI_PAD_H__ */
> > -- 
> > 1.7.1
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:59:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPGk-0001MI-49; Fri, 17 Feb 2012 14:58:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyPGi-0001MA-0b
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:58:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329490713!2363131!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23430 invoked from network); 17 Feb 2012 14:58:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 14:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10775790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 14:58:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 14:58:33 +0000
Message-ID: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 14:58:32 +0000
In-Reply-To: <20120217142505.GA10523@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 14:25 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> > IOW at the libxl layer we have the full semantics available to callers
> > but at the xl layer we only expose one "target memory" value to users
> > which we expect the guest to use ballooning to reach but which we
> > "enforce" with paging if they don't comply.
> 
> So if I understand that right there should be a new boolean, like
> xenpaging=yes/no?

Yes. Although you can probably omit the "xen" prefix in a Xen
configuration file.

[...]
> Or it could be like this (in which case the pager currently cant start
> due to lack of PoD support):
> 
> memory=N
> maxmem=N+X
> xenpaging=yes

This is the style I was thinking of.

Paging needs to either be compatible with or replace PoD IMHO (or
perhaps simply be mutually exclusive with it as an interim solution,
i.e. paging=yes disables pod).

> In both cases "xl mem-set" will adjust both ballooning and paging values?

Yes.

> Should there be xl commands to adjust just ballooning and/or paging?

Perhaps as debuging aids or something but I wouldn't expect these to be
commands which we would suggest end users needed to touch. The
interactions between these different knobs and the semantics of changing
just one or the other would be pretty complex.

The only additional nob I can see being useful would be a minmem option
which is the smallest amount of memory which the guest should think it
has, i.e. it would be a lower bound on the ballooning target but not the
paging target. The default would be some fraction of maxmem (similar to
the minimum_target stuff in linux-2.6.18-xen.hg:drivers/xen/balloon/).
This would be used to reduce the memory used by a domain past the point
at which it would start OOMing etc.

> Regarding the tuning knobs, right now I can only think of the policy mru
> size and the number of evicts before checking for new events.
> So you propose to have something like "xl xenpaging domid knob value"?

The other option would be
	xl paging-knob-set domid value

We seem to have commands in both forms already.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 14:59:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 14:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPGk-0001MI-49; Fri, 17 Feb 2012 14:58:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyPGi-0001MA-0b
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 14:58:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329490713!2363131!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23430 invoked from network); 17 Feb 2012 14:58:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 14:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10775790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 14:58:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 14:58:33 +0000
Message-ID: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 14:58:32 +0000
In-Reply-To: <20120217142505.GA10523@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 14:25 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> > IOW at the libxl layer we have the full semantics available to callers
> > but at the xl layer we only expose one "target memory" value to users
> > which we expect the guest to use ballooning to reach but which we
> > "enforce" with paging if they don't comply.
> 
> So if I understand that right there should be a new boolean, like
> xenpaging=yes/no?

Yes. Although you can probably omit the "xen" prefix in a Xen
configuration file.

[...]
> Or it could be like this (in which case the pager currently cant start
> due to lack of PoD support):
> 
> memory=N
> maxmem=N+X
> xenpaging=yes

This is the style I was thinking of.

Paging needs to either be compatible with or replace PoD IMHO (or
perhaps simply be mutually exclusive with it as an interim solution,
i.e. paging=yes disables pod).

> In both cases "xl mem-set" will adjust both ballooning and paging values?

Yes.

> Should there be xl commands to adjust just ballooning and/or paging?

Perhaps as debuging aids or something but I wouldn't expect these to be
commands which we would suggest end users needed to touch. The
interactions between these different knobs and the semantics of changing
just one or the other would be pretty complex.

The only additional nob I can see being useful would be a minmem option
which is the smallest amount of memory which the guest should think it
has, i.e. it would be a lower bound on the ballooning target but not the
paging target. The default would be some fraction of maxmem (similar to
the minimum_target stuff in linux-2.6.18-xen.hg:drivers/xen/balloon/).
This would be used to reduce the memory used by a domain past the point
at which it would start OOMing etc.

> Regarding the tuning knobs, right now I can only think of the policy mru
> size and the number of evicts before checking for new events.
> So you propose to have something like "xl xenpaging domid knob value"?

The other option would be
	xl paging-knob-set domid value

We seem to have commands in both forms already.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:12:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPTk-0001ZE-Ec; Fri, 17 Feb 2012 15:12:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyPTj-0001Z9-3x
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:12:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329491519!13781203!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2240 invoked from network); 17 Feb 2012 15:12:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 15:12: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 q1HFB9rj017481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 15:11:10 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
	q1HFB7iN016366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 15:11: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
	q1HFB7FW023044; Fri, 17 Feb 2012 09:11:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 07:11:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DE8F741FE1; Fri, 17 Feb 2012 10:07:59 -0500 (EST)
Date: Fri, 17 Feb 2012 10:07:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120217150759.GA29554@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
	<20120215192804.GA21695@phenom.dumpdata.com>
	<4F3CD2E502000078000735E4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3CD2E502000078000735E4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090208.4F3E6E0F.00FD,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > 	struct page **pages;
> > 	unsigned int nr_pages, array_size, i;
> > 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+	if (xen_pv_domain()) {
> >+		if (dma_mask == (__GFP_DMA | __GFP_DMA32))
> 
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
> 
> >+			gfp_mask &= (__GFP_DMA | __GFP_DMA32);
> 
> 			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> 
> Jan

Duh!
Good eyes. Thanks for catching that.

> 
> >+	}
> > 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > 	array_size = (nr_pages * sizeof(struct page *));
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:12:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPTk-0001ZE-Ec; Fri, 17 Feb 2012 15:12:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyPTj-0001Z9-3x
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:12:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329491519!13781203!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2240 invoked from network); 17 Feb 2012 15:12:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 15:12: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 q1HFB9rj017481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 15:11:10 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
	q1HFB7iN016366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 15:11: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
	q1HFB7FW023044; Fri, 17 Feb 2012 09:11:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 07:11:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DE8F741FE1; Fri, 17 Feb 2012 10:07:59 -0500 (EST)
Date: Fri, 17 Feb 2012 10:07:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120217150759.GA29554@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
	<20120215192804.GA21695@phenom.dumpdata.com>
	<4F3CD2E502000078000735E4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3CD2E502000078000735E4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090208.4F3E6E0F.00FD,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > 	struct page **pages;
> > 	unsigned int nr_pages, array_size, i;
> > 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+	if (xen_pv_domain()) {
> >+		if (dma_mask == (__GFP_DMA | __GFP_DMA32))
> 
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
> 
> >+			gfp_mask &= (__GFP_DMA | __GFP_DMA32);
> 
> 			gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> 
> Jan

Duh!
Good eyes. Thanks for catching that.

> 
> >+	}
> > 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > 	array_size = (nr_pages * sizeof(struct page *));
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:14:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyPVi-0001dV-VP; Fri, 17 Feb 2012 15:14:10 +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 1RyPVh-0001dL-Qw
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:14:10 +0000
Received: from [85.158.139.83:24480] by server-6.bemta-5.messagelabs.com id
	C1/9B-27305-0CE6E3F4; Fri, 17 Feb 2012 15:14:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329491646!12816425!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14493 invoked from network); 17 Feb 2012 15:14:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 15:14:08 -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 q1HFE4gN020480
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 15:14: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
	q1HFE3Go021260
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 15:14:04 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
	q1HFE3Pj007269; Fri, 17 Feb 2012 09:14:03 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 07:14:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B061641FE1; Fri, 17 Feb 2012 10:10:56 -0500 (EST)
Date: Fri, 17 Feb 2012 10:10:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120217151056.GB29554@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<1329386571.4520.44.camel@leeds.uk.xensource.com>
	<1329387379.4520.54.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329387379.4520.54.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F3E6EBD.00AE,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > -#define XENNET_MAX_RING_PAGE_ORDER 2
> > > +#define XENNET_MAX_RING_PAGE_ORDER 4
> > 
> > I guess this is you tuning with page order? And here is not the only one
> > place you changed?
> > 
> > As a matter of fact, in the previous patch 8 I encode hard limit 2 on
> > the ring page order, your change here will stop FE / BE from connecting.
> > 
> > I think I will also need to change this to something like
> > 
> >   #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> > 
> > to remind people to modify that value. 
> > 
> 
> To be more precise on this, tangling with RING_PAGE_ORDER will not
> affect FE, because the mapping is done in BE. However if you make
> RING_PAGE_ORDER larger than BE limit, it will fail.
> 
> So the above #define is actually asking people playing with FE to check
> BE limit. :-(

Say that in two years we decide that the ring order in the FE should be 256,
and we also change that in the backend. Some customers might still be running
with the old backends which advertise only 4.

Or vice-versa. The users run a brand new BE which advertises 256 and the user
is running a frontend that can only do 4. It (frontend) should be able to safely
negotiate the proper minimum value.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:14:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyPVi-0001dV-VP; Fri, 17 Feb 2012 15:14:10 +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 1RyPVh-0001dL-Qw
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:14:10 +0000
Received: from [85.158.139.83:24480] by server-6.bemta-5.messagelabs.com id
	C1/9B-27305-0CE6E3F4; Fri, 17 Feb 2012 15:14:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329491646!12816425!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14493 invoked from network); 17 Feb 2012 15:14:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 15:14:08 -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 q1HFE4gN020480
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 15:14: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
	q1HFE3Go021260
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 15:14:04 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
	q1HFE3Pj007269; Fri, 17 Feb 2012 09:14:03 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 07:14:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B061641FE1; Fri, 17 Feb 2012 10:10:56 -0500 (EST)
Date: Fri, 17 Feb 2012 10:10:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120217151056.GB29554@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-13-git-send-email-wei.liu2@citrix.com>
	<20120215224253.GA18762@phenom.dumpdata.com>
	<1329386571.4520.44.camel@leeds.uk.xensource.com>
	<1329387379.4520.54.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329387379.4520.54.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090209.4F3E6EBD.00AE,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 12/13] netfront: multi page ring
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > -#define XENNET_MAX_RING_PAGE_ORDER 2
> > > +#define XENNET_MAX_RING_PAGE_ORDER 4
> > 
> > I guess this is you tuning with page order? And here is not the only one
> > place you changed?
> > 
> > As a matter of fact, in the previous patch 8 I encode hard limit 2 on
> > the ring page order, your change here will stop FE / BE from connecting.
> > 
> > I think I will also need to change this to something like
> > 
> >   #define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> > 
> > to remind people to modify that value. 
> > 
> 
> To be more precise on this, tangling with RING_PAGE_ORDER will not
> affect FE, because the mapping is done in BE. However if you make
> RING_PAGE_ORDER larger than BE limit, it will fail.
> 
> So the above #define is actually asking people playing with FE to check
> BE limit. :-(

Say that in two years we decide that the ring order in the FE should be 256,
and we also change that in the backend. Some customers might still be running
with the old backends which advertise only 4.

Or vice-versa. The users run a brand new BE which advertises 256 and the user
is running a frontend that can only do 4. It (frontend) should be able to safely
negotiate the proper minimum value.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyPfc-0001ub-31; Fri, 17 Feb 2012 15:24:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyPfa-0001uV-De
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:24:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329492254!15312761!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22468 invoked from network); 17 Feb 2012 15:24:15 -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 Feb 2012 15:24:15 -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 q1HFNG63030647
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 15:23:17 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
	q1HFNDqJ005775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 15:23:14 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1HFNBeE003491; Fri, 17 Feb 2012 09:23:11 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 07:23:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 872F641FE4; Fri, 17 Feb 2012 10:20:04 -0500 (EST)
Date: Fri, 17 Feb 2012 10:20:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120217152004.GB30298@phenom.dumpdata.com>
References: <20120216194801.GB8023@andromeda.dapyr.net>
	<df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F3E70E6.00A6,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, jeremy@goop.org,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 07:50:11AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > > We just reported to xenbus that we can't close yet, because
> > > blkfront is still in use. So we shouldn't then immediately
> > > state that we are closing.
> > 
> > What happens if the user uses --force to unplug the device?
> > Will that still work?
> 
> With RHEL5 tooling I get the same results. That is, the device
> is forcibly detached, and then any task in the guest that still
> attempts to use (or even just unmount) the device hangs.
> 
> I don't know anything about xl, but afaict block-detach
> doesn't take a 'force' option?

konrad@phenom:~/ssd/linux$ xm block-detach
xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp
Error: 'xm block-detach' requires between 2 and 3 arguments.

Usage: xm block-detach <Domain> <DevId> [-f|--force]

Destroy a domain's virtual block device.


> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  drivers/block/xen-blkfront.c |    1 -
> > >  1 files changed, 0 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkfront.c
> > > b/drivers/block/xen-blkfront.c
> > > index 5d45688..b53cae4 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> > >  	if (bdev->bd_openers) {
> > >  		xenbus_dev_error(xbdev, -EBUSY,
> > >  				 "Device in use; refusing to close");
> > > -		xenbus_switch_state(xbdev, XenbusStateClosing);
> > >  	} else {
> > >  		xlvbd_release_gendisk(info);
> > >  		xenbus_frontend_closed(xbdev);
> > > --
> > > 1.7.7.5
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyPfc-0001ub-31; Fri, 17 Feb 2012 15:24:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyPfa-0001uV-De
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:24:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329492254!15312761!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22468 invoked from network); 17 Feb 2012 15:24:15 -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 Feb 2012 15:24:15 -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 q1HFNG63030647
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 15:23:17 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
	q1HFNDqJ005775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 15:23:14 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1HFNBeE003491; Fri, 17 Feb 2012 09:23:11 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 07:23:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 872F641FE4; Fri, 17 Feb 2012 10:20:04 -0500 (EST)
Date: Fri, 17 Feb 2012 10:20:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120217152004.GB30298@phenom.dumpdata.com>
References: <20120216194801.GB8023@andromeda.dapyr.net>
	<df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F3E70E6.00A6,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, jeremy@goop.org,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 07:50:11AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > > We just reported to xenbus that we can't close yet, because
> > > blkfront is still in use. So we shouldn't then immediately
> > > state that we are closing.
> > 
> > What happens if the user uses --force to unplug the device?
> > Will that still work?
> 
> With RHEL5 tooling I get the same results. That is, the device
> is forcibly detached, and then any task in the guest that still
> attempts to use (or even just unmount) the device hangs.
> 
> I don't know anything about xl, but afaict block-detach
> doesn't take a 'force' option?

konrad@phenom:~/ssd/linux$ xm block-detach
xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp
Error: 'xm block-detach' requires between 2 and 3 arguments.

Usage: xm block-detach <Domain> <DevId> [-f|--force]

Destroy a domain's virtual block device.


> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  drivers/block/xen-blkfront.c |    1 -
> > >  1 files changed, 0 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkfront.c
> > > b/drivers/block/xen-blkfront.c
> > > index 5d45688..b53cae4 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> > >  	if (bdev->bd_openers) {
> > >  		xenbus_dev_error(xbdev, -EBUSY,
> > >  				 "Device in use; refusing to close");
> > > -		xenbus_switch_state(xbdev, XenbusStateClosing);
> > >  	} else {
> > >  		xlvbd_release_gendisk(info);
> > >  		xenbus_frontend_closed(xbdev);
> > > --
> > > 1.7.7.5
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:25:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPg7-0001wg-Li; Fri, 17 Feb 2012 15:24:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyPg6-0001wH-5H
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:24:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329492287!13389071!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4159 invoked from network); 17 Feb 2012 15:24:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Feb 2012 15:24:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329492287; l=1599;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=1Km75RtO58iAsz+1uvEvbxdjnTc=;
	b=pZvOCrNSt0kbzHueHRgZ40D78CumV7DcRWgG/BXgGj96PzA3b9Ju8ZQJfhvo9iX/+bQ
	ypDCpT8NOjaLFr3yG2QuRpBFCoRYvoMLjQ9XjpS+NsFAbuCieFNcH2AQu6xZEGhAVtN+O
	akToIchVAmgQB4W43H7OiGq3va/YpXXaEG0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (klopstock mo62) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v04ffeo1HEoh1T ;
	Fri, 17 Feb 2012 16:24:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BA17C18637; Fri, 17 Feb 2012 16:24:43 +0100 (CET)
Date: Fri, 17 Feb 2012 16:24:43 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217152443.GA16995@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> Paging needs to either be compatible with or replace PoD IMHO (or
> perhaps simply be mutually exclusive with it as an interim solution,
> i.e. paging=yes disables pod).

This has to be fixed in hypervisor at some point. PoD as such is very
useful, and I expect adding the cooperation with paging is not very
hard. It just takes time.

> > Should there be xl commands to adjust just ballooning and/or paging?
> 
> Perhaps as debuging aids or something but I wouldn't expect these to be
> commands which we would suggest end users needed to touch. The
> interactions between these different knobs and the semantics of changing
> just one or the other would be pretty complex.

Where do you see the complexity? The balloon driver does not notice that
the guest is paged, and xenpaging itself can cope with ballooning.

Giving the host admin the choice to page more (at the expense of some IO
and slight slowdown) without caring about the current memory constraints
within the guest sounds useful to me. 

> The only additional nob I can see being useful would be a minmem option
> which is the smallest amount of memory which the guest should think it
> has, i.e. it would be a lower bound on the ballooning target but not the
> paging target. The default would be some fraction of maxmem (similar to
> the minimum_target stuff in linux-2.6.18-xen.hg:drivers/xen/balloon/).
> This would be used to reduce the memory used by a domain past the point
> at which it would start OOMing etc.

Sounds useful to prevent accidents.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:25:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPg7-0001wg-Li; Fri, 17 Feb 2012 15:24:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyPg6-0001wH-5H
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:24:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329492287!13389071!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4159 invoked from network); 17 Feb 2012 15:24:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Feb 2012 15:24:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329492287; l=1599;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=1Km75RtO58iAsz+1uvEvbxdjnTc=;
	b=pZvOCrNSt0kbzHueHRgZ40D78CumV7DcRWgG/BXgGj96PzA3b9Ju8ZQJfhvo9iX/+bQ
	ypDCpT8NOjaLFr3yG2QuRpBFCoRYvoMLjQ9XjpS+NsFAbuCieFNcH2AQu6xZEGhAVtN+O
	akToIchVAmgQB4W43H7OiGq3va/YpXXaEG0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (klopstock mo62) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v04ffeo1HEoh1T ;
	Fri, 17 Feb 2012 16:24:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BA17C18637; Fri, 17 Feb 2012 16:24:43 +0100 (CET)
Date: Fri, 17 Feb 2012 16:24:43 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217152443.GA16995@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> Paging needs to either be compatible with or replace PoD IMHO (or
> perhaps simply be mutually exclusive with it as an interim solution,
> i.e. paging=yes disables pod).

This has to be fixed in hypervisor at some point. PoD as such is very
useful, and I expect adding the cooperation with paging is not very
hard. It just takes time.

> > Should there be xl commands to adjust just ballooning and/or paging?
> 
> Perhaps as debuging aids or something but I wouldn't expect these to be
> commands which we would suggest end users needed to touch. The
> interactions between these different knobs and the semantics of changing
> just one or the other would be pretty complex.

Where do you see the complexity? The balloon driver does not notice that
the guest is paged, and xenpaging itself can cope with ballooning.

Giving the host admin the choice to page more (at the expense of some IO
and slight slowdown) without caring about the current memory constraints
within the guest sounds useful to me. 

> The only additional nob I can see being useful would be a minmem option
> which is the smallest amount of memory which the guest should think it
> has, i.e. it would be a lower bound on the ballooning target but not the
> paging target. The default would be some fraction of maxmem (similar to
> the minimum_target stuff in linux-2.6.18-xen.hg:drivers/xen/balloon/).
> This would be used to reduce the memory used by a domain past the point
> at which it would start OOMing etc.

Sounds useful to prevent accidents.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPgc-00020M-2v; Fri, 17 Feb 2012 15:25:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1RyPga-0001zd-FK
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:25:24 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329492317!15775767!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM4NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11655 invoked from network); 17 Feb 2012 15:25:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 15:25:18 -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 q1HFP86N020181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 10:25:08 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1HFP7JG032226; Fri, 17 Feb 2012 10:25:08 -0500
Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com
	[10.34.1.247])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q1HFP4ZE027511;
	Fri, 17 Feb 2012 10:25:05 -0500
Message-ID: <4F3E7150.7000804@redhat.com>
Date: Fri, 17 Feb 2012 16:25:04 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <28a9ca8a-4696-4c9c-bd15-f2fa5558740e@zmail16.collab.prod.int.phx2.redhat.com>
	<4F3D0CB1.5070707@redhat.com>
In-Reply-To: <4F3D0CB1.5070707@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, kvm@vger.kernel.org,
	mtosatti@redhat.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, Avi Kivity <avi@redhat.com>, hpa@zytor.com,
	amit shah <amit.shah@redhat.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] BUG in pv_clock when overflow condition is
	detected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/16/2012 03:03 PM, Avi Kivity wrote:
> On 02/15/2012 07:18 PM, Igor Mammedov wrote:
>>> On 02/15/2012 01:23 PM, Igor Mammedov wrote:
>>>>>>    static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time
>>>>>> *shadow)
>>>>>>    {
>>>>>> -    u64 delta = native_read_tsc() - shadow->tsc_timestamp;
>>>>>> +    u64 delta;
>>>>>> +    u64 tsc = native_read_tsc();
>>>>>> +    BUG_ON(tsc<   shadow->tsc_timestamp);
>>>>>> +    delta = tsc - shadow->tsc_timestamp;
>>>>>>        return pvclock_scale_delta(delta, shadow->tsc_to_nsec_mul,
>>>>>>                       shadow->tsc_shift);
>>>>>
>>>>> Maybe a WARN_ON_ONCE()?  Otherwise a relatively minor hypervisor
>>>>> bug can
>>>>> kill the guest.
>>>>
>>>>
>>>> An attempt to print from this place is not perfect since it often
>>>> leads
>>>> to recursive calling to this very function and it hang there
>>>> anyway.
>>>> But if you insist I'll re-post it with WARN_ON_ONCE,
>>>> It won't make much difference because guest will hang/stall due
>>>> overflow
>>>> anyway.
>>>
>>> Won't a BUG_ON() also result in a printk?
>> Yes, it will. But stack will still keep failure point and poking
>> with crash/gdb at core will always show where it's BUGged.
>>
>> In case it manages to print dump somehow (saw it couple times from ~
>> 30 test cycles), logs from console or from kernel message buffer
>> (again poking with gdb) will show where it was called from.
>>
>> If WARN* is used, it will still totaly screwup clock and
>> "last value" and system will become unusable, requiring looking with
>> gdb/crash at the core any way.
>>
>> So I've just used more stable failure point that will leave trace
>> everywhere it manages (maybe in console log, but for sure in stack)
>> in case of WARN it might leave trace on console or not and probably
>> won't reflect failure point in stack either leaving only kernel
>> message buffer for clue.
>>
>
> Makes sense.  But do get an ack from the Xen people to ensure this
> doesn't break for them.
>
Konrad, Ian

Could you please review patch form point of view of xen?
Whole thread could be found here https://lkml.org/lkml/2012/2/13/286

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyPgc-00020M-2v; Fri, 17 Feb 2012 15:25:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1RyPga-0001zd-FK
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:25:24 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329492317!15775767!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM4NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11655 invoked from network); 17 Feb 2012 15:25:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 15:25:18 -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 q1HFP86N020181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 10:25:08 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1HFP7JG032226; Fri, 17 Feb 2012 10:25:08 -0500
Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com
	[10.34.1.247])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q1HFP4ZE027511;
	Fri, 17 Feb 2012 10:25:05 -0500
Message-ID: <4F3E7150.7000804@redhat.com>
Date: Fri, 17 Feb 2012 16:25:04 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <28a9ca8a-4696-4c9c-bd15-f2fa5558740e@zmail16.collab.prod.int.phx2.redhat.com>
	<4F3D0CB1.5070707@redhat.com>
In-Reply-To: <4F3D0CB1.5070707@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, kvm@vger.kernel.org,
	mtosatti@redhat.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, Avi Kivity <avi@redhat.com>, hpa@zytor.com,
	amit shah <amit.shah@redhat.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] BUG in pv_clock when overflow condition is
	detected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/16/2012 03:03 PM, Avi Kivity wrote:
> On 02/15/2012 07:18 PM, Igor Mammedov wrote:
>>> On 02/15/2012 01:23 PM, Igor Mammedov wrote:
>>>>>>    static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time
>>>>>> *shadow)
>>>>>>    {
>>>>>> -    u64 delta = native_read_tsc() - shadow->tsc_timestamp;
>>>>>> +    u64 delta;
>>>>>> +    u64 tsc = native_read_tsc();
>>>>>> +    BUG_ON(tsc<   shadow->tsc_timestamp);
>>>>>> +    delta = tsc - shadow->tsc_timestamp;
>>>>>>        return pvclock_scale_delta(delta, shadow->tsc_to_nsec_mul,
>>>>>>                       shadow->tsc_shift);
>>>>>
>>>>> Maybe a WARN_ON_ONCE()?  Otherwise a relatively minor hypervisor
>>>>> bug can
>>>>> kill the guest.
>>>>
>>>>
>>>> An attempt to print from this place is not perfect since it often
>>>> leads
>>>> to recursive calling to this very function and it hang there
>>>> anyway.
>>>> But if you insist I'll re-post it with WARN_ON_ONCE,
>>>> It won't make much difference because guest will hang/stall due
>>>> overflow
>>>> anyway.
>>>
>>> Won't a BUG_ON() also result in a printk?
>> Yes, it will. But stack will still keep failure point and poking
>> with crash/gdb at core will always show where it's BUGged.
>>
>> In case it manages to print dump somehow (saw it couple times from ~
>> 30 test cycles), logs from console or from kernel message buffer
>> (again poking with gdb) will show where it was called from.
>>
>> If WARN* is used, it will still totaly screwup clock and
>> "last value" and system will become unusable, requiring looking with
>> gdb/crash at the core any way.
>>
>> So I've just used more stable failure point that will leave trace
>> everywhere it manages (maybe in console log, but for sure in stack)
>> in case of WARN it might leave trace on console or not and probably
>> won't reflect failure point in stack either leaving only kernel
>> message buffer for clue.
>>
>
> Makes sense.  But do get an ack from the Xen people to ensure this
> doesn't break for them.
>
Konrad, Ian

Could you please review patch form point of view of xen?
Whole thread could be found here https://lkml.org/lkml/2012/2/13/286

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:33:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyPoM-0002OT-3B; Fri, 17 Feb 2012 15:33:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyPoK-0002OO-Ju
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:33:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329492798!14752581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29882 invoked from network); 17 Feb 2012 15:33:18 -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;
	17 Feb 2012 15:33:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10777253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 15:33:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 15:33:18 +0000
Message-ID: <1329492796.3131.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 15:33:16 +0000
In-Reply-To: <20120217152443.GA16995@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 15:24 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> 
> > Paging needs to either be compatible with or replace PoD IMHO (or
> > perhaps simply be mutually exclusive with it as an interim solution,
> > i.e. paging=yes disables pod).
> 
> This has to be fixed in hypervisor at some point. PoD as such is very
> useful, and I expect adding the cooperation with paging is not very
> hard. It just takes time.
> 
> > > Should there be xl commands to adjust just ballooning and/or paging?
> > 
> > Perhaps as debuging aids or something but I wouldn't expect these to be
> > commands which we would suggest end users needed to touch. The
> > interactions between these different knobs and the semantics of changing
> > just one or the other would be pretty complex.
> 
> Where do you see the complexity?

For users in determining what changing a given value will actually do,
what values they need to use to get the behaviour which they want, what
happens if they change first one value and then the other, how do they
interact with mem-set and memmax, what are the various invalid or
meaningless combinations etc.

There's also complexity for us in trying to decide what the right answer
is to each of those questions and trying to implement it in a consistent
way and explain it all to users.

>  The balloon driver does not notice that
> the guest is paged, and xenpaging itself can cope with ballooning.
> 
> Giving the host admin the choice to page more (at the expense of some IO
> and slight slowdown) without caring about the current memory constraints
> within the guest sounds useful to me.

The "minmem" suggestion allows exactly this without exposing the user to
too much of the underlying implementation details.

> > The only additional nob I can see being useful would be a minmem option
> > which is the smallest amount of memory which the guest should think it
> > has, i.e. it would be a lower bound on the ballooning target but not the
> > paging target. The default would be some fraction of maxmem (similar to
> > the minimum_target stuff in linux-2.6.18-xen.hg:drivers/xen/balloon/).
> > This would be used to reduce the memory used by a domain past the point
> > at which it would start OOMing etc.
> 
> Sounds useful to prevent accidents.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:33:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyPoM-0002OT-3B; Fri, 17 Feb 2012 15:33:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyPoK-0002OO-Ju
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:33:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329492798!14752581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29882 invoked from network); 17 Feb 2012 15:33:18 -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;
	17 Feb 2012 15:33:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10777253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 15:33:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 15:33:18 +0000
Message-ID: <1329492796.3131.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 15:33:16 +0000
In-Reply-To: <20120217152443.GA16995@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 15:24 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> 
> > Paging needs to either be compatible with or replace PoD IMHO (or
> > perhaps simply be mutually exclusive with it as an interim solution,
> > i.e. paging=yes disables pod).
> 
> This has to be fixed in hypervisor at some point. PoD as such is very
> useful, and I expect adding the cooperation with paging is not very
> hard. It just takes time.
> 
> > > Should there be xl commands to adjust just ballooning and/or paging?
> > 
> > Perhaps as debuging aids or something but I wouldn't expect these to be
> > commands which we would suggest end users needed to touch. The
> > interactions between these different knobs and the semantics of changing
> > just one or the other would be pretty complex.
> 
> Where do you see the complexity?

For users in determining what changing a given value will actually do,
what values they need to use to get the behaviour which they want, what
happens if they change first one value and then the other, how do they
interact with mem-set and memmax, what are the various invalid or
meaningless combinations etc.

There's also complexity for us in trying to decide what the right answer
is to each of those questions and trying to implement it in a consistent
way and explain it all to users.

>  The balloon driver does not notice that
> the guest is paged, and xenpaging itself can cope with ballooning.
> 
> Giving the host admin the choice to page more (at the expense of some IO
> and slight slowdown) without caring about the current memory constraints
> within the guest sounds useful to me.

The "minmem" suggestion allows exactly this without exposing the user to
too much of the underlying implementation details.

> > The only additional nob I can see being useful would be a minmem option
> > which is the smallest amount of memory which the guest should think it
> > has, i.e. it would be a lower bound on the ballooning target but not the
> > paging target. The default would be some fraction of maxmem (similar to
> > the minimum_target stuff in linux-2.6.18-xen.hg:drivers/xen/balloon/).
> > This would be used to reduce the memory used by a domain past the point
> > at which it would start OOMing etc.
> 
> Sounds useful to prevent accidents.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyQ04-0002Ys-Ba; Fri, 17 Feb 2012 15:45: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 1RyQ02-0002Yn-Tn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:45:31 +0000
Received: from [85.158.139.83:40572] by server-12.bemta-5.messagelabs.com id
	EF/5D-24595-A167E3F4; Fri, 17 Feb 2012 15:45:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329493529!14893830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6124 invoked from network); 17 Feb 2012 15:45:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 15:45:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10777903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 15:45:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 15:45:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyPze-0005Kr-Hi; Fri, 17 Feb 2012 15:45:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyPze-0004G3-8q;
	Fri, 17 Feb 2012 15:45:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20286.30209.884503.259901@mariner.uk.xensource.com>
Date: Fri, 17 Feb 2012 15:45:05 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5QQidU4y7gA7j1--2c_T9LnyYd68Doy44-W6NJBEABSw@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<7de94a26474f869177ce.1328189224@debian.localdomain>
	<20275.59790.700273.845107@mariner.uk.xensource.com>
	<CAPLaKK5QQidU4y7gA7j1--2c_T9LnyYd68Doy44-W6NJBEABSw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 29 of 29 RFC] libxl: dele=
gate plug/unplug of disk and nic devices to xldeviced"):
> 2012/2/9 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > and to make the new functionality have the same
> > libxl_device_disk_add name (etc.) as before.
> =

> I would like to keep the original libxl_device_<type>_add functions,
> since they are called from xldeviced and perform the actual plug of
> the device. libxl_device_<type>_hotplug_add are called from xl to
> trigger the plug (pass the command to xldeviced). Probably the names
> should be changed to something more descriptive of what they actually
> do, I'm open to suggestion there.

Something like that.  But if xldeviced is an internal feature of
libxl, rather than a user of libxl's public API (which is how I think
it should be) then all of these functions should be called
libxl__something and not be expored in libxl.h.

> How does renaming libxl_device_<type>_add to
> libxl_device_<type>_plug/unplug (which will be called from xldeviced)
> and libxl_device_<type>_hotplug_add to libxl_device_<type>_add, this
> will mean less modifications in xl code since it will call the same
> functions?

Yes, exactly.  I don't think this move should involve changing xl
(unless of course we discover bugs in the api...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyQ04-0002Ys-Ba; Fri, 17 Feb 2012 15:45: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 1RyQ02-0002Yn-Tn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:45:31 +0000
Received: from [85.158.139.83:40572] by server-12.bemta-5.messagelabs.com id
	EF/5D-24595-A167E3F4; Fri, 17 Feb 2012 15:45:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329493529!14893830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6124 invoked from network); 17 Feb 2012 15:45:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 15:45:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10777903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 15:45:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 15:45:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyPze-0005Kr-Hi; Fri, 17 Feb 2012 15:45:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyPze-0004G3-8q;
	Fri, 17 Feb 2012 15:45:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20286.30209.884503.259901@mariner.uk.xensource.com>
Date: Fri, 17 Feb 2012 15:45:05 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5QQidU4y7gA7j1--2c_T9LnyYd68Doy44-W6NJBEABSw@mail.gmail.com>
References: <patchbomb.1328189195@debian.localdomain>
	<7de94a26474f869177ce.1328189224@debian.localdomain>
	<20275.59790.700273.845107@mariner.uk.xensource.com>
	<CAPLaKK5QQidU4y7gA7j1--2c_T9LnyYd68Doy44-W6NJBEABSw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 29 of 29 RFC] libxl: delegate plug/unplug of
 disk and nic devices to xldeviced
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 29 of 29 RFC] libxl: dele=
gate plug/unplug of disk and nic devices to xldeviced"):
> 2012/2/9 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > and to make the new functionality have the same
> > libxl_device_disk_add name (etc.) as before.
> =

> I would like to keep the original libxl_device_<type>_add functions,
> since they are called from xldeviced and perform the actual plug of
> the device. libxl_device_<type>_hotplug_add are called from xl to
> trigger the plug (pass the command to xldeviced). Probably the names
> should be changed to something more descriptive of what they actually
> do, I'm open to suggestion there.

Something like that.  But if xldeviced is an internal feature of
libxl, rather than a user of libxl's public API (which is how I think
it should be) then all of these functions should be called
libxl__something and not be expored in libxl.h.

> How does renaming libxl_device_<type>_add to
> libxl_device_<type>_plug/unplug (which will be called from xldeviced)
> and libxl_device_<type>_hotplug_add to libxl_device_<type>_add, this
> will mean less modifications in xl code since it will call the same
> functions?

Yes, exactly.  I don't think this move should involve changing xl
(unless of course we discover bugs in the api...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:51:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQ5A-0002iJ-4G; Fri, 17 Feb 2012 15:50:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyQ59-0002i9-4r
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 15:50:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329493840!15146104!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1367 invoked from network); 17 Feb 2012 15:50:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 15:50:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 15:50:39 +0000
Message-Id: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 15:50:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest pagetable
 walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim,

this c/s or-s PFEC_reserved_bit into the error code passed to the guest
in two places, and I'm afraid it is responsible for problems we're seeing
when a Linux HVM PAE guest on a non-HAP platform runs into
invocations of pgtable_bad(). Linux check the reserved bit before
looking at the present bit, and expects the reserved bit to always be
clear when the present bit also is. The respective lines from the
guest's kernel log however are

Bad pagetable: 000c [#1] SMP
Bad pagetable: 000e [#2] SMP
Bad pagetable: 000e [#3] SMP
Bad pagetable: 000c [#4] SMP
Bad pagetable: 000c [#5] SMP
Bad pagetable: 000c [#6] SMP
Bad pagetable: 000a [#7] SMP
Bad pagetable: 000a [#8] SMP
Bad pagetable: 000c [#10] SMP
Bad pagetable: 000c [#11] SMP

(i.e. reserved flag always set, present flag always clear) with the
corresponding page table dumps being

*pdpt = 0000000035682001 *pde = 0000000013014067 *pte = 002dea0000000000
*pdpt = 0000000035d65001 *pde = 0000000028a8a067 *pte = 002dd16000000000
*pdpt = 0000000013177001 *pde = 0000000028bf9067 *pte = 002dd16000000000
*pdpt = 0000000035480001 *pde = 000000005e6b1067
*pdpt = 00000000133b6001 *pde = 000000005e6c1067
*pdpt = 00000000131b7001 *pde = 000000005de15067
*pdpt = 00000000354bd001 *pde = 00000000355ad067 *pte = 002dfca000000000
*pdpt = 000000002bd5c001 *pde = 000000002bf2c067 *pte = 002dfa6000000000
*pdpt = 000000002bd79001 *pde = 0000000000000000
*pdpt = 000000002bdc6001 *pde = 000000005e63c067
*pdpt = 00000000130ef001 *pde = 000000005e690067

(i.e. no invalid bits at all, but paged out entries with page indexes
into the swap file indicating a swap size of over 10G - with anything
up to 4G, the reserved bits would never be run into).

The problem appears to be that the or-ing in of PFEC_reserved_bit
happens without consideration of PFEC_present. If you can confirm
I'm not mis-interpreting things, fixing this should be relatively
strait forward (though the question would be whether it should be
guest_walk_tables() or its callers that should be fixed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:51:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQ5A-0002iJ-4G; Fri, 17 Feb 2012 15:50:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyQ59-0002i9-4r
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 15:50:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329493840!15146104!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1367 invoked from network); 17 Feb 2012 15:50:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 15:50:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 15:50:39 +0000
Message-Id: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 15:50:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest pagetable
 walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim,

this c/s or-s PFEC_reserved_bit into the error code passed to the guest
in two places, and I'm afraid it is responsible for problems we're seeing
when a Linux HVM PAE guest on a non-HAP platform runs into
invocations of pgtable_bad(). Linux check the reserved bit before
looking at the present bit, and expects the reserved bit to always be
clear when the present bit also is. The respective lines from the
guest's kernel log however are

Bad pagetable: 000c [#1] SMP
Bad pagetable: 000e [#2] SMP
Bad pagetable: 000e [#3] SMP
Bad pagetable: 000c [#4] SMP
Bad pagetable: 000c [#5] SMP
Bad pagetable: 000c [#6] SMP
Bad pagetable: 000a [#7] SMP
Bad pagetable: 000a [#8] SMP
Bad pagetable: 000c [#10] SMP
Bad pagetable: 000c [#11] SMP

(i.e. reserved flag always set, present flag always clear) with the
corresponding page table dumps being

*pdpt = 0000000035682001 *pde = 0000000013014067 *pte = 002dea0000000000
*pdpt = 0000000035d65001 *pde = 0000000028a8a067 *pte = 002dd16000000000
*pdpt = 0000000013177001 *pde = 0000000028bf9067 *pte = 002dd16000000000
*pdpt = 0000000035480001 *pde = 000000005e6b1067
*pdpt = 00000000133b6001 *pde = 000000005e6c1067
*pdpt = 00000000131b7001 *pde = 000000005de15067
*pdpt = 00000000354bd001 *pde = 00000000355ad067 *pte = 002dfca000000000
*pdpt = 000000002bd5c001 *pde = 000000002bf2c067 *pte = 002dfa6000000000
*pdpt = 000000002bd79001 *pde = 0000000000000000
*pdpt = 000000002bdc6001 *pde = 000000005e63c067
*pdpt = 00000000130ef001 *pde = 000000005e690067

(i.e. no invalid bits at all, but paged out entries with page indexes
into the swap file indicating a swap size of over 10G - with anything
up to 4G, the reserved bits would never be run into).

The problem appears to be that the or-ing in of PFEC_reserved_bit
happens without consideration of PFEC_present. If you can confirm
I'm not mis-interpreting things, fixing this should be relatively
strait forward (though the question would be whether it should be
guest_walk_tables() or its callers that should be fixed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:51:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQ5w-0002lL-I7; Fri, 17 Feb 2012 15:51:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyQ5u-0002kt-Ro
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:51:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329493437!12328404!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8675 invoked from network); 17 Feb 2012 15:43:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Feb 2012 15:43:58 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329493437; l=820;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=8+I6zv6JE0yxSmYNkDsOiEnP2FM=;
	b=CsrrlctwwpgBtQhUoDzgbqpuVNMGIig8pLfDk6jxpwf73sv9+tL8Z1ZeM15hbXVtiiw
	c3+vaFvNdtGnQa3t671HkMCQ+KSCrj36kDwtRoEja74Lu0VyXlE1FNvV+v8f38oNJAOWy
	Eh60w11PnSwY2pxUUliwBZXR0B1AHZELtPw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (klopstock mo11) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 003149o1HFe0zw ;
	Fri, 17 Feb 2012 16:43:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7411718637; Fri, 17 Feb 2012 16:43:47 +0100 (CET)
Date: Fri, 17 Feb 2012 16:43:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217154346.GA19731@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329492796.3131.104.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> On Fri, 2012-02-17 at 15:24 +0000, Olaf Hering wrote:
> > Where do you see the complexity?
> 
> For users in determining what changing a given value will actually do,
> what values they need to use to get the behaviour which they want, what
> happens if they change first one value and then the other, how do they
> interact with mem-set and memmax, what are the various invalid or
> meaningless combinations etc.
> 
> There's also complexity for us in trying to decide what the right answer
> is to each of those questions and trying to implement it in a consistent
> way and explain it all to users.

A figure like the one in tools/libxl/libxl_memory.txt will explain it
very well, if done right.
Perhaps I should write up something based on that figure.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:51:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQ5w-0002lL-I7; Fri, 17 Feb 2012 15:51:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyQ5u-0002kt-Ro
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:51:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329493437!12328404!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8675 invoked from network); 17 Feb 2012 15:43:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Feb 2012 15:43:58 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329493437; l=820;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=8+I6zv6JE0yxSmYNkDsOiEnP2FM=;
	b=CsrrlctwwpgBtQhUoDzgbqpuVNMGIig8pLfDk6jxpwf73sv9+tL8Z1ZeM15hbXVtiiw
	c3+vaFvNdtGnQa3t671HkMCQ+KSCrj36kDwtRoEja74Lu0VyXlE1FNvV+v8f38oNJAOWy
	Eh60w11PnSwY2pxUUliwBZXR0B1AHZELtPw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (klopstock mo11) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 003149o1HFe0zw ;
	Fri, 17 Feb 2012 16:43:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7411718637; Fri, 17 Feb 2012 16:43:47 +0100 (CET)
Date: Fri, 17 Feb 2012 16:43:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217154346.GA19731@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329492796.3131.104.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> On Fri, 2012-02-17 at 15:24 +0000, Olaf Hering wrote:
> > Where do you see the complexity?
> 
> For users in determining what changing a given value will actually do,
> what values they need to use to get the behaviour which they want, what
> happens if they change first one value and then the other, how do they
> interact with mem-set and memmax, what are the various invalid or
> meaningless combinations etc.
> 
> There's also complexity for us in trying to decide what the right answer
> is to each of those questions and trying to implement it in a consistent
> way and explain it all to users.

A figure like the one in tools/libxl/libxl_memory.txt will explain it
very well, if done right.
Perhaps I should write up something based on that figure.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:54:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyQ8o-0002wj-7I; Fri, 17 Feb 2012 15:54: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 1RyQ8n-0002wa-8f
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:54:33 +0000
Received: from [85.158.139.83:21183] by server-5.bemta-5.messagelabs.com id
	B6/D6-13566-8387E3F4; Fri, 17 Feb 2012 15:54:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329494071!14675180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29953 invoked from network); 17 Feb 2012 15:54:31 -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;
	17 Feb 2012 15:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10778085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 15:54:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 15:54:31 +0000
Message-ID: <1329494069.3131.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 15:54:29 +0000
In-Reply-To: <20120217154346.GA19731@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 15:43 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> 
> > On Fri, 2012-02-17 at 15:24 +0000, Olaf Hering wrote:
> > > Where do you see the complexity?
> > 
> > For users in determining what changing a given value will actually do,
> > what values they need to use to get the behaviour which they want, what
> > happens if they change first one value and then the other, how do they
> > interact with mem-set and memmax, what are the various invalid or
> > meaningless combinations etc.
> > 
> > There's also complexity for us in trying to decide what the right answer
> > is to each of those questions and trying to implement it in a consistent
> > way and explain it all to users.
> 
> A figure like the one in tools/libxl/libxl_memory.txt will explain it
> very well, if done right.

That's exactly the sort of complexity we should not be exposing to the
end user!

It's bad enough us developers trying to keep it all the moving parts
straight in our heads...


> Perhaps I should write up something based on that figure.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 15:54:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 15: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.xensource.com>)
	id 1RyQ8o-0002wj-7I; Fri, 17 Feb 2012 15:54: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 1RyQ8n-0002wa-8f
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 15:54:33 +0000
Received: from [85.158.139.83:21183] by server-5.bemta-5.messagelabs.com id
	B6/D6-13566-8387E3F4; Fri, 17 Feb 2012 15:54:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329494071!14675180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29953 invoked from network); 17 Feb 2012 15:54:31 -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;
	17 Feb 2012 15:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10778085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 15:54:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 15:54:31 +0000
Message-ID: <1329494069.3131.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 15:54:29 +0000
In-Reply-To: <20120217154346.GA19731@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 15:43 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> 
> > On Fri, 2012-02-17 at 15:24 +0000, Olaf Hering wrote:
> > > Where do you see the complexity?
> > 
> > For users in determining what changing a given value will actually do,
> > what values they need to use to get the behaviour which they want, what
> > happens if they change first one value and then the other, how do they
> > interact with mem-set and memmax, what are the various invalid or
> > meaningless combinations etc.
> > 
> > There's also complexity for us in trying to decide what the right answer
> > is to each of those questions and trying to implement it in a consistent
> > way and explain it all to users.
> 
> A figure like the one in tools/libxl/libxl_memory.txt will explain it
> very well, if done right.

That's exactly the sort of complexity we should not be exposing to the
end user!

It's bad enough us developers trying to keep it all the moving parts
straight in our heads...


> Perhaps I should write up something based on that figure.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQHu-0003hW-Os; Fri, 17 Feb 2012 16:03:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyQHt-0003hR-7l
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:03:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329494630!13789080!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3536 invoked from network); 17 Feb 2012 16:03:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Feb 2012 16:03:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329494630; l=294;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vdMNukc90ujEZprKW6OddTBIT1E=;
	b=P1+aTjAIM6JAXB/dVBLL3GXnszIerI/CM3HkaVSuaV8G262jXoAqRFiOrcLFfNBFNfa
	JCgxNYOj095RKVD0E6qGx4GT/gALXw7RvHXChRynfjFwlycm/liI/toGl6TbZdIyhOVPX
	jqH0kZwEA5fdgzm2ElKj0D2G1YSbB3+A7UI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (klopstock mo51) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a0499fo1HElUgO ;
	Fri, 17 Feb 2012 17:03:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E828018637; Fri, 17 Feb 2012 17:03:41 +0100 (CET)
Date: Fri, 17 Feb 2012 17:03:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217160341.GA22266@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329494069.3131.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> That's exactly the sort of complexity we should not be exposing to the
> end user!

Of course not as is!
Right now one has to understand two values, maxmem and the size of the
memhog called "guest balloon driver". Paging adds a third one.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQHu-0003hW-Os; Fri, 17 Feb 2012 16:03:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RyQHt-0003hR-7l
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:03:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329494630!13789080!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDY2Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3536 invoked from network); 17 Feb 2012 16:03:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Feb 2012 16:03:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329494630; l=294;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vdMNukc90ujEZprKW6OddTBIT1E=;
	b=P1+aTjAIM6JAXB/dVBLL3GXnszIerI/CM3HkaVSuaV8G262jXoAqRFiOrcLFfNBFNfa
	JCgxNYOj095RKVD0E6qGx4GT/gALXw7RvHXChRynfjFwlycm/liI/toGl6TbZdIyhOVPX
	jqH0kZwEA5fdgzm2ElKj0D2G1YSbB3+A7UI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0c7pEMNI
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-224.pools.arcor-ip.net [84.57.78.224])
	by smtp.strato.de (klopstock mo51) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a0499fo1HElUgO ;
	Fri, 17 Feb 2012 17:03:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E828018637; Fri, 17 Feb 2012 17:03:41 +0100 (CET)
Date: Fri, 17 Feb 2012 17:03:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120217160341.GA22266@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329494069.3131.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, Ian Campbell wrote:

> That's exactly the sort of complexity we should not be exposing to the
> end user!

Of course not as is!
Right now one has to understand two values, maxmem and the size of the
memhog called "guest balloon driver". Paging adds a third one.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQJv-0003me-9T; Fri, 17 Feb 2012 16:06:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyQJt-0003mV-RN
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:06:02 +0000
Received: from [85.158.139.83:46627] by server-6.bemta-5.messagelabs.com id
	1C/8C-27305-9EA7E3F4; Fri, 17 Feb 2012 16:06:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329494759!15532135!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTMzMTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23632 invoked from network); 17 Feb 2012 16:06:00 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.177) by server-6.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 16:06:00 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 4DD1F380069;
	Fri, 17 Feb 2012 08:05:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PnKmTxVJeGmMhC/dyrCT5v1lO9hcfK7Eq7pPUTrNuo4e
	PosT4YENDAChSl+Afz3svW/xosMdIaHRXEoTwo3LHdzWjUUcb/JfdsIeVsBXx7Zk
	Oo0rHlsREUTOa9mDTXT+q7hOJuxp/+yCdGSQs7AdGS5fQAnFzOiNy+0PB6VN+tA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Jp5iDD+zicYQB7GWp6m6dnosUbI=; b=uURAAO/j
	k4IBE4TtWa3KZzXGtTwPTyx/1KmQlXuIH4MKXCHIZDTJxaQ0gABm9onKGIeMj4O7
	Wo22fyoAkoRbi+rKHd1WQd7kF/8o7e+fBW7mySFtN/oHscj6jNkc6upAOmk64pAY
	ReWU3n1JJTbE5+2G7JvMcorAREkNCzlyBCA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id CFD36380065; 
	Fri, 17 Feb 2012 08:05:58 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:05:59 -0800
Message-ID: <0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
Date: Fri, 17 Feb 2012 08:05:59 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: tim@xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
> On Feb 16, 2012, at 10:20 AM, Tim Deegan wrote:
>
>> Hi,
>>
>> As promised, a revised version of the waitq-on-missing-pages patch.
>> I've cut it back a fair bit; I think the resulting patch is maybe a bit
>> less efficient, but easier to understand.
>>
>> I've smoke-tested it a bit and haven't seen anything catch fire but I
>> suspect the VMs aren't very happy.  I'll debug more throughly when I'm
>> back in the office next week, but would really like some feedback from
>> the rest of you in the meantime.

Well, thanks for taking a stab at it. Looks fairly well. My main
observation is that we do not want to unconditionally go on a wait queue
everywhere. For example, the grant table code pretty reliable unwinds
itself and correctly tells the grant mapper to retry, in the presence of a
paged page. The same could be said of emulation (X86_EMUL_RETRY). And
certainly the balloon code should not sleep waiting for populate!

Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
wait queue code is invoked only there. And then we can call get_gfn_sleep
in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.

I understand that is cleaner not to have to make that distinction, but I
don't want to fix things that aren't broken :)

More comments inline

>>
>> Cheers,
>>
>> Tim.
>>
>> # HG changeset patch
>> # User Tim Deegan <tim@xen.org>
>> # Parent 01c1bcbc62224833304ede44187400f65e8a6b4c
>> [RFC] x86/mm: use wait queues for mem_paging
>>
>> Use a wait queue to put a guest vcpu to sleep while the requested gfn is
>> in paging state. This adds missing p2m_mem_paging_populate() calls to
>> some callers of the new get_gfn* variants, which would crash now
>> because they get an invalid mfn. It also fixes guest crashes due to
>> unexpected returns from do_memory_op because copy_to/from_guest ran into
>> a paged gfn. Now those places will always get a valid mfn.
>>
>> This is based on an earlier RFC patch by Olaf Hering, but heavily
>> simplified (removing a per-gfn queue of waiting vcpus in favour of
>> a scan of all vcpus on page-in).
>>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> Signed-off-by: Tim Deegan <tim@xen.org>
>>
>> diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
>> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
>> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
>>     }
>>
>>     /* For now only perform locking on hap domains */
>> -    if ( locked && (hap_enabled(p2m->domain)) )
>> +    locked = locked && hap_enabled(p2m->domain);
>> +
>> +#ifdef __x86_64__
When are we getting rid of 32 bit hypervisor? (half kidding. Only half)

>> +again:
>> +#endif
>> +    if ( locked )
>>         /* Grab the lock here, don't release until put_gfn */
>>         gfn_lock(p2m, gfn, 0);
>>
>>     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>>
>> #ifdef __x86_64__
>> +    if ( p2m_is_paging(*t) && q != p2m_query
>> +         && p2m->domain == current->domain )
>> +    {
>> +        if ( locked )
>> +            gfn_unlock(p2m, gfn, 0);
>> +
>> +        /* Ping the pager */
>> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
>> +            p2m_mem_paging_populate(p2m->domain, gfn);

You want to make sure the mfn is not valid. For p2m_ram_paging_out we
still have the mfn in place.

>> +
>> +        /* Safety catch: it _should_ be safe to wait here but if it's
>> not,
>> +         * crash the VM, not the host */
>> +        if ( in_atomic() )
>> +        {
>> +            WARN();
>> +            domain_crash(p2m->domain);
>> +        }
>> +        else
>> +        {
>> +            current->arch.mem_paging_gfn = gfn;
>> +            wait_event(current->arch.mem_paging_wq, ({
>> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
>> +                                             p2m_query, page_order);
>> +                        (*t != p2m_ram_paging_in);

Well, first of all mfn->get_entry will not happen in a locked context, so
you will exit the wait loop not holding the p2m lock and crash later. So
you want __get_gfn_type_access with q = p2m_query, and then put_gfn if the
condition fails. Probably not gonna fit in a ({}) block ;)

I think checking for (!p2m_is_paging(*t)) is more appropriate.

Or even (!p2m_is_paging(*t) && mfn_valid(mfn)). Although I'm mildly
hesitant about the latter because conceivably another vcpu may beat us to
grabbing the p2m lock after the gfn is populated, and do something to its
mfn.

>> +                    }));
>> +            goto again;
>> +        }
>> +    }
>> +#endif
>> +
>> +#ifdef __x86_64__
>>     if ( q == p2m_unshare && p2m_is_shared(*t) )
>>     {
>>         ASSERT(!p2m_is_nestedp2m(p2m));
>> @@ -942,25 +978,25 @@ void p2m_mem_paging_drop_page(struct dom
>>  * This function needs to be called whenever gfn_to_mfn() returns any of
>> the p2m
>>  * paging types because the gfn may not be backed by a mfn.
>>  *
>> - * The gfn can be in any of the paging states, but the pager needs only
>> be
>> - * notified when the gfn is in the paging-out path (paging_out or
>> paged).  This
>> - * function may be called more than once from several vcpus. If the
>> vcpu belongs
>> - * to the guest, the vcpu must be stopped and the pager notified that
>> the vcpu
>> - * was stopped. The pager needs to handle several requests for the same
>> gfn.
>> + * The gfn can be in any of the paging states, but the pager needs only
>> + * be notified when the gfn is in the paging-out path (paging_out or
>> + * paged).  This function may be called more than once from several
>> + * vcpus.  The pager needs to handle several requests for the same gfn.
>>  *
>> - * If the gfn is not in the paging-out path and the vcpu does not
>> belong to the
>> - * guest, nothing needs to be done and the function assumes that a
>> request was
>> - * already sent to the pager. In this case the caller has to try again
>> until the
>> - * gfn is fully paged in again.
>> + * If the gfn is not in the paging-out path nothing needs to be done
>> and
>> + * the function assumes that a request was already sent to the pager.
>> + * In this case the caller has to try again until the gfn is fully
>> paged
>> + * in again.
>>  */
>> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> {
>>     struct vcpu *v = current;
>> -    mem_event_request_t req;
>> +    mem_event_request_t req = {0};
>>     p2m_type_t p2mt;
>>     p2m_access_t a;
>>     mfn_t mfn;
>>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +    int send_request = 0;
>>
>>     /* We're paging. There should be a ring */
>>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);

Given all the optimizations around the send_request flag, it might be
worth moving the claim_slot call to an if(send_request) block at the
bottom, and get rid of cancel_slot altogether. Claim_slot could
potentially go (or cause someone else to go) to a wait queue, and it's
best to not be that rude.

>> @@ -974,9 +1010,6 @@ void p2m_mem_paging_populate(struct doma
>>     else if ( rc < 0 )
>>         return;
>>
>> -    memset(&req, 0, sizeof(req));
>> -    req.type = MEM_EVENT_TYPE_PAGING;
>> -
>>     /* Fix p2m mapping */
>>     gfn_lock(p2m, gfn, 0);
>>     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
>> @@ -986,26 +1019,29 @@ void p2m_mem_paging_populate(struct doma
>>         /* Evict will fail now, tag this request for pager */
>>         if ( p2mt == p2m_ram_paging_out )
>>             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
>> -
>> -        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in,
>> a);
>> +        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain
>> == d )
>> +            /* Short-cut back to paged-in state (but not for foreign
>> +             * mappings, or the pager couldn't map it to page it out)
>> */
>> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> +                          paging_mode_log_dirty(d)
>> +                          ? p2m_ram_logdirty : p2m_ram_rw, a);
>> +        else
>> +        {
>> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> p2m_ram_paging_in, a);
>> +            send_request = 1;
>> +        }
>>     }
>>     gfn_unlock(p2m, gfn, 0);
>>
>> -    /* Pause domain if request came from guest and gfn has paging type
>> */
>> -    if ( p2m_is_paging(p2mt) && v->domain == d )
>> +    /* No need to inform pager if the gfn is not in the page-out path
>> */
>> +    if ( !send_request )
>>     {
>> -        vcpu_pause_nosync(v);

I see no sin in stacking vcpu_pauses. Plus, this will need to stay if we
(hopefully) adopt get_gfn_sleep.

>> -        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>> -    }
>> -    /* No need to inform pager if the gfn is not in the page-out path
>> */
>> -    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>> -    {
>> -        /* gfn is already on its way back and vcpu is not paused */
>>         mem_event_cancel_slot(d, &d->mem_event->paging);
>>         return;
>>     }
>>
>>     /* Send request to pager */
>> +    req.type = MEM_EVENT_TYPE_PAGING;
>>     req.gfn = gfn;
>>     req.p2mt = p2mt;
>>     req.vcpu_id = v->vcpu_id;
>> @@ -1122,6 +1158,7 @@ void p2m_mem_paging_resume(struct domain
>> {
>>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>     mem_event_response_t rsp;
>> +    struct vcpu *v;
>>     p2m_type_t p2mt;
>>     p2m_access_t a;
>>     mfn_t mfn;
>> @@ -1147,9 +1184,10 @@ void p2m_mem_paging_resume(struct domain
>>             }
>>             gfn_unlock(p2m, rsp.gfn, 0);
>>         }
>> -        /* Unpause domain */
>> -        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>> -            vcpu_unpause(d->vcpu[rsp.vcpu_id]);

I see no sin in stacking vcpu pauses, redux...

That's all I have. Thanks!
Andres

>> +        /* Wake any vcpus that were waiting for this GFN */
>> +        for_each_vcpu ( d, v )
>> +            if ( v->arch.mem_paging_gfn == rsp.gfn )
>> +                wake_up_all(&v->arch.mem_paging_wq);
>>     }
>> }
>>
>> diff -r 01c1bcbc6222 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h	Thu Feb 16 08:48:23 2012 +0100
>> +++ b/xen/include/asm-x86/domain.h	Thu Feb 16 14:39:13 2012 +0000
>> @@ -4,6 +4,7 @@
>> #include <xen/config.h>
>> #include <xen/mm.h>
>> #include <xen/radix-tree.h>
>> +#include <xen/wait.h>
>> #include <asm/hvm/vcpu.h>
>> #include <asm/hvm/domain.h>
>> #include <asm/e820.h>
>> @@ -491,6 +492,12 @@ struct arch_vcpu
>>
>>     struct paging_vcpu paging;
>>
>> +#ifdef CONFIG_X86_64
>> +    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
>> +    struct waitqueue_head mem_paging_wq;
>> +    unsigned long mem_paging_gfn;
>> +#endif
>> +
>> #ifdef CONFIG_X86_32
>>     /* map_domain_page() mapping cache. */
>>     struct mapcache_vcpu mapcache;
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQJv-0003me-9T; Fri, 17 Feb 2012 16:06:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyQJt-0003mV-RN
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:06:02 +0000
Received: from [85.158.139.83:46627] by server-6.bemta-5.messagelabs.com id
	1C/8C-27305-9EA7E3F4; Fri, 17 Feb 2012 16:06:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329494759!15532135!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTMzMTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23632 invoked from network); 17 Feb 2012 16:06:00 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.177) by server-6.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 16:06:00 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 4DD1F380069;
	Fri, 17 Feb 2012 08:05:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PnKmTxVJeGmMhC/dyrCT5v1lO9hcfK7Eq7pPUTrNuo4e
	PosT4YENDAChSl+Afz3svW/xosMdIaHRXEoTwo3LHdzWjUUcb/JfdsIeVsBXx7Zk
	Oo0rHlsREUTOa9mDTXT+q7hOJuxp/+yCdGSQs7AdGS5fQAnFzOiNy+0PB6VN+tA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Jp5iDD+zicYQB7GWp6m6dnosUbI=; b=uURAAO/j
	k4IBE4TtWa3KZzXGtTwPTyx/1KmQlXuIH4MKXCHIZDTJxaQ0gABm9onKGIeMj4O7
	Wo22fyoAkoRbi+rKHd1WQd7kF/8o7e+fBW7mySFtN/oHscj6jNkc6upAOmk64pAY
	ReWU3n1JJTbE5+2G7JvMcorAREkNCzlyBCA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id CFD36380065; 
	Fri, 17 Feb 2012 08:05:58 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:05:59 -0800
Message-ID: <0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
Date: Fri, 17 Feb 2012 08:05:59 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: tim@xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
> On Feb 16, 2012, at 10:20 AM, Tim Deegan wrote:
>
>> Hi,
>>
>> As promised, a revised version of the waitq-on-missing-pages patch.
>> I've cut it back a fair bit; I think the resulting patch is maybe a bit
>> less efficient, but easier to understand.
>>
>> I've smoke-tested it a bit and haven't seen anything catch fire but I
>> suspect the VMs aren't very happy.  I'll debug more throughly when I'm
>> back in the office next week, but would really like some feedback from
>> the rest of you in the meantime.

Well, thanks for taking a stab at it. Looks fairly well. My main
observation is that we do not want to unconditionally go on a wait queue
everywhere. For example, the grant table code pretty reliable unwinds
itself and correctly tells the grant mapper to retry, in the presence of a
paged page. The same could be said of emulation (X86_EMUL_RETRY). And
certainly the balloon code should not sleep waiting for populate!

Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
wait queue code is invoked only there. And then we can call get_gfn_sleep
in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.

I understand that is cleaner not to have to make that distinction, but I
don't want to fix things that aren't broken :)

More comments inline

>>
>> Cheers,
>>
>> Tim.
>>
>> # HG changeset patch
>> # User Tim Deegan <tim@xen.org>
>> # Parent 01c1bcbc62224833304ede44187400f65e8a6b4c
>> [RFC] x86/mm: use wait queues for mem_paging
>>
>> Use a wait queue to put a guest vcpu to sleep while the requested gfn is
>> in paging state. This adds missing p2m_mem_paging_populate() calls to
>> some callers of the new get_gfn* variants, which would crash now
>> because they get an invalid mfn. It also fixes guest crashes due to
>> unexpected returns from do_memory_op because copy_to/from_guest ran into
>> a paged gfn. Now those places will always get a valid mfn.
>>
>> This is based on an earlier RFC patch by Olaf Hering, but heavily
>> simplified (removing a per-gfn queue of waiting vcpus in favour of
>> a scan of all vcpus on page-in).
>>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>> Signed-off-by: Tim Deegan <tim@xen.org>
>>
>> diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
>> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
>> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
>>     }
>>
>>     /* For now only perform locking on hap domains */
>> -    if ( locked && (hap_enabled(p2m->domain)) )
>> +    locked = locked && hap_enabled(p2m->domain);
>> +
>> +#ifdef __x86_64__
When are we getting rid of 32 bit hypervisor? (half kidding. Only half)

>> +again:
>> +#endif
>> +    if ( locked )
>>         /* Grab the lock here, don't release until put_gfn */
>>         gfn_lock(p2m, gfn, 0);
>>
>>     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>>
>> #ifdef __x86_64__
>> +    if ( p2m_is_paging(*t) && q != p2m_query
>> +         && p2m->domain == current->domain )
>> +    {
>> +        if ( locked )
>> +            gfn_unlock(p2m, gfn, 0);
>> +
>> +        /* Ping the pager */
>> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
>> +            p2m_mem_paging_populate(p2m->domain, gfn);

You want to make sure the mfn is not valid. For p2m_ram_paging_out we
still have the mfn in place.

>> +
>> +        /* Safety catch: it _should_ be safe to wait here but if it's
>> not,
>> +         * crash the VM, not the host */
>> +        if ( in_atomic() )
>> +        {
>> +            WARN();
>> +            domain_crash(p2m->domain);
>> +        }
>> +        else
>> +        {
>> +            current->arch.mem_paging_gfn = gfn;
>> +            wait_event(current->arch.mem_paging_wq, ({
>> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
>> +                                             p2m_query, page_order);
>> +                        (*t != p2m_ram_paging_in);

Well, first of all mfn->get_entry will not happen in a locked context, so
you will exit the wait loop not holding the p2m lock and crash later. So
you want __get_gfn_type_access with q = p2m_query, and then put_gfn if the
condition fails. Probably not gonna fit in a ({}) block ;)

I think checking for (!p2m_is_paging(*t)) is more appropriate.

Or even (!p2m_is_paging(*t) && mfn_valid(mfn)). Although I'm mildly
hesitant about the latter because conceivably another vcpu may beat us to
grabbing the p2m lock after the gfn is populated, and do something to its
mfn.

>> +                    }));
>> +            goto again;
>> +        }
>> +    }
>> +#endif
>> +
>> +#ifdef __x86_64__
>>     if ( q == p2m_unshare && p2m_is_shared(*t) )
>>     {
>>         ASSERT(!p2m_is_nestedp2m(p2m));
>> @@ -942,25 +978,25 @@ void p2m_mem_paging_drop_page(struct dom
>>  * This function needs to be called whenever gfn_to_mfn() returns any of
>> the p2m
>>  * paging types because the gfn may not be backed by a mfn.
>>  *
>> - * The gfn can be in any of the paging states, but the pager needs only
>> be
>> - * notified when the gfn is in the paging-out path (paging_out or
>> paged).  This
>> - * function may be called more than once from several vcpus. If the
>> vcpu belongs
>> - * to the guest, the vcpu must be stopped and the pager notified that
>> the vcpu
>> - * was stopped. The pager needs to handle several requests for the same
>> gfn.
>> + * The gfn can be in any of the paging states, but the pager needs only
>> + * be notified when the gfn is in the paging-out path (paging_out or
>> + * paged).  This function may be called more than once from several
>> + * vcpus.  The pager needs to handle several requests for the same gfn.
>>  *
>> - * If the gfn is not in the paging-out path and the vcpu does not
>> belong to the
>> - * guest, nothing needs to be done and the function assumes that a
>> request was
>> - * already sent to the pager. In this case the caller has to try again
>> until the
>> - * gfn is fully paged in again.
>> + * If the gfn is not in the paging-out path nothing needs to be done
>> and
>> + * the function assumes that a request was already sent to the pager.
>> + * In this case the caller has to try again until the gfn is fully
>> paged
>> + * in again.
>>  */
>> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> {
>>     struct vcpu *v = current;
>> -    mem_event_request_t req;
>> +    mem_event_request_t req = {0};
>>     p2m_type_t p2mt;
>>     p2m_access_t a;
>>     mfn_t mfn;
>>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +    int send_request = 0;
>>
>>     /* We're paging. There should be a ring */
>>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);

Given all the optimizations around the send_request flag, it might be
worth moving the claim_slot call to an if(send_request) block at the
bottom, and get rid of cancel_slot altogether. Claim_slot could
potentially go (or cause someone else to go) to a wait queue, and it's
best to not be that rude.

>> @@ -974,9 +1010,6 @@ void p2m_mem_paging_populate(struct doma
>>     else if ( rc < 0 )
>>         return;
>>
>> -    memset(&req, 0, sizeof(req));
>> -    req.type = MEM_EVENT_TYPE_PAGING;
>> -
>>     /* Fix p2m mapping */
>>     gfn_lock(p2m, gfn, 0);
>>     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
>> @@ -986,26 +1019,29 @@ void p2m_mem_paging_populate(struct doma
>>         /* Evict will fail now, tag this request for pager */
>>         if ( p2mt == p2m_ram_paging_out )
>>             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
>> -
>> -        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in,
>> a);
>> +        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain
>> == d )
>> +            /* Short-cut back to paged-in state (but not for foreign
>> +             * mappings, or the pager couldn't map it to page it out)
>> */
>> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> +                          paging_mode_log_dirty(d)
>> +                          ? p2m_ram_logdirty : p2m_ram_rw, a);
>> +        else
>> +        {
>> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
>> p2m_ram_paging_in, a);
>> +            send_request = 1;
>> +        }
>>     }
>>     gfn_unlock(p2m, gfn, 0);
>>
>> -    /* Pause domain if request came from guest and gfn has paging type
>> */
>> -    if ( p2m_is_paging(p2mt) && v->domain == d )
>> +    /* No need to inform pager if the gfn is not in the page-out path
>> */
>> +    if ( !send_request )
>>     {
>> -        vcpu_pause_nosync(v);

I see no sin in stacking vcpu_pauses. Plus, this will need to stay if we
(hopefully) adopt get_gfn_sleep.

>> -        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>> -    }
>> -    /* No need to inform pager if the gfn is not in the page-out path
>> */
>> -    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>> -    {
>> -        /* gfn is already on its way back and vcpu is not paused */
>>         mem_event_cancel_slot(d, &d->mem_event->paging);
>>         return;
>>     }
>>
>>     /* Send request to pager */
>> +    req.type = MEM_EVENT_TYPE_PAGING;
>>     req.gfn = gfn;
>>     req.p2mt = p2mt;
>>     req.vcpu_id = v->vcpu_id;
>> @@ -1122,6 +1158,7 @@ void p2m_mem_paging_resume(struct domain
>> {
>>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>     mem_event_response_t rsp;
>> +    struct vcpu *v;
>>     p2m_type_t p2mt;
>>     p2m_access_t a;
>>     mfn_t mfn;
>> @@ -1147,9 +1184,10 @@ void p2m_mem_paging_resume(struct domain
>>             }
>>             gfn_unlock(p2m, rsp.gfn, 0);
>>         }
>> -        /* Unpause domain */
>> -        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>> -            vcpu_unpause(d->vcpu[rsp.vcpu_id]);

I see no sin in stacking vcpu pauses, redux...

That's all I have. Thanks!
Andres

>> +        /* Wake any vcpus that were waiting for this GFN */
>> +        for_each_vcpu ( d, v )
>> +            if ( v->arch.mem_paging_gfn == rsp.gfn )
>> +                wake_up_all(&v->arch.mem_paging_wq);
>>     }
>> }
>>
>> diff -r 01c1bcbc6222 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h	Thu Feb 16 08:48:23 2012 +0100
>> +++ b/xen/include/asm-x86/domain.h	Thu Feb 16 14:39:13 2012 +0000
>> @@ -4,6 +4,7 @@
>> #include <xen/config.h>
>> #include <xen/mm.h>
>> #include <xen/radix-tree.h>
>> +#include <xen/wait.h>
>> #include <asm/hvm/vcpu.h>
>> #include <asm/hvm/domain.h>
>> #include <asm/e820.h>
>> @@ -491,6 +492,12 @@ struct arch_vcpu
>>
>>     struct paging_vcpu paging;
>>
>> +#ifdef CONFIG_X86_64
>> +    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
>> +    struct waitqueue_head mem_paging_wq;
>> +    unsigned long mem_paging_gfn;
>> +#endif
>> +
>> #ifdef CONFIG_X86_32
>>     /* map_domain_page() mapping cache. */
>>     struct mapcache_vcpu mapcache;
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:06:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQKZ-0003pR-Nd; Fri, 17 Feb 2012 16:06:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyQKY-0003pH-6i
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:06:42 +0000
Received: from [85.158.139.83:49563] by server-11.bemta-5.messagelabs.com id
	73/96-14397-11B7E3F4; Fri, 17 Feb 2012 16:06:41 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329494799!15455027!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15223 invoked from network); 17 Feb 2012 16:06:40 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 16:06:40 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyQKV-0007VO-5A
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:06:39 -0800
Date: Fri, 17 Feb 2012 08:06:39 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329494799149-5493035.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
xen-unstable.hg changeset 24823:b75664e53905 plus these patch for not fail
build:
http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html

On boot start to load but after start ramdisk load server reboot without
message on screen.

The grub2 entry is:
-----------------------------------------
menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID' --class debian
--class gnu-linux --class gnu --class os {
	set root='(RAID-ROOT)'
	echo	'Caricamento Hypervisor Xen 4.2...'
	multiboot	/boot/xen.gz placeholder dom0_mem=1024M
	echo	'Caricamento Linux 3.2.0-1-amd64...'
	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro 
quiet
	echo	'Caricamento ramdisk iniziale...'
	initrd	/boot/initrd.img-3.2.0-1-amd64
}
-----------------------------------------

I try also with debug options and see with SOL (serial on lan) if see some
more but also with it see only the three echo line.

The grub2 entry is:
-----------------------------------------
menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID - Debug su
Seriale' --class debian --class gnu-linux --class gnu --class os {
	set root='(RAID-ROOT)'
	echo	'Caricamento Hypervisor Xen 4.2...'
	multiboot	/boot/xen.gz placeholder dom0_mem=1024M loglvl=all
guest_loglvl=all sync_console console_to_ring com2=19200,8n1 console=com2
	echo	'Caricamento Linux 3.2.0-1-amd64...'
	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro
console=hvc0 earlyprintk=xen nomodeset
	echo	'Caricamento ramdisk iniziale...'
	initrd	/boot/initrd.img-3.2.0-1-amd64
}
-----------------------------------------

Without xen boot correctly.

I have missed or wrong something on grub debug entry?

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5493035.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:06:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQKZ-0003pR-Nd; Fri, 17 Feb 2012 16:06:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyQKY-0003pH-6i
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:06:42 +0000
Received: from [85.158.139.83:49563] by server-11.bemta-5.messagelabs.com id
	73/96-14397-11B7E3F4; Fri, 17 Feb 2012 16:06:41 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329494799!15455027!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15223 invoked from network); 17 Feb 2012 16:06:40 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2012 16:06:40 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RyQKV-0007VO-5A
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 08:06:39 -0800
Date: Fri, 17 Feb 2012 08:06:39 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329494799149-5493035.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
xen-unstable.hg changeset 24823:b75664e53905 plus these patch for not fail
build:
http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html

On boot start to load but after start ramdisk load server reboot without
message on screen.

The grub2 entry is:
-----------------------------------------
menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID' --class debian
--class gnu-linux --class gnu --class os {
	set root='(RAID-ROOT)'
	echo	'Caricamento Hypervisor Xen 4.2...'
	multiboot	/boot/xen.gz placeholder dom0_mem=1024M
	echo	'Caricamento Linux 3.2.0-1-amd64...'
	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro 
quiet
	echo	'Caricamento ramdisk iniziale...'
	initrd	/boot/initrd.img-3.2.0-1-amd64
}
-----------------------------------------

I try also with debug options and see with SOL (serial on lan) if see some
more but also with it see only the three echo line.

The grub2 entry is:
-----------------------------------------
menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID - Debug su
Seriale' --class debian --class gnu-linux --class gnu --class os {
	set root='(RAID-ROOT)'
	echo	'Caricamento Hypervisor Xen 4.2...'
	multiboot	/boot/xen.gz placeholder dom0_mem=1024M loglvl=all
guest_loglvl=all sync_console console_to_ring com2=19200,8n1 console=com2
	echo	'Caricamento Linux 3.2.0-1-amd64...'
	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro
console=hvc0 earlyprintk=xen nomodeset
	echo	'Caricamento ramdisk iniziale...'
	initrd	/boot/initrd.img-3.2.0-1-amd64
}
-----------------------------------------

Without xen boot correctly.

I have missed or wrong something on grub debug entry?

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5493035.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:13:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQQh-000490-Jz; Fri, 17 Feb 2012 16:13:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyQQf-00048t-D8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:13:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329495174!9678681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 17 Feb 2012 16:12:54 -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;
	17 Feb 2012 16:12:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10778527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 16:12:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 16:12:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyQQY-0005Wt-3e; Fri, 17 Feb 2012 16:12:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyQQX-0001EN-Vr;
	Fri, 17 Feb 2012 16:12:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20286.31877.938411.558236@mariner.uk.xensource.com>
Date: Fri, 17 Feb 2012 16:12:53 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronou=
s/long-running operation infrastructure"):
> 2012/2/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > How are you expecting this ao to complete ?
> =

> I was expecting that AO_INPROGRESS returns 0 if no events have been
> added, so I don't need to know whether I have added events or not to
> call AO_INPROGRESS.

You must always call AO_INPROGRESS.  After calling AO_CREATE you must
call AO_INPROGRESS.

You must also arrange to call libxl__ao_complete at some point.  You
may only call libxl__ao_complete from an event callback.  So you had
better have set up an event ("added" an event as you put it).

Otherwise libxl__ao_complete will never be called at all, and indeed
the synchronous call will never return.

> > If you haven't asked for
> > an event callback then presumably libxl__ao_complete will never be
> > called.
> =

> I'm talking about libxl__ao_inprogress, which is called from
> AO_INPROGRESS macro. With the current code this macro might be called
> from libxl_device_disk_remove for example without adding any events,
> because libxl__initiate_device_remove can return successfully without
> adding an event, and AO_INPROGRESS is called unconditionally.

Yes, you are right, there is a bug in libxl_device_disk_remove /
libxl__initiate_device_remove.  I hadn't spotted that the "out" path
from the old device removal code was used in a success case too.

I will fix it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:13:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQQh-000490-Jz; Fri, 17 Feb 2012 16:13:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyQQf-00048t-D8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:13:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329495174!9678681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 17 Feb 2012 16:12:54 -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;
	17 Feb 2012 16:12:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10778527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 16:12:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 16:12:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyQQY-0005Wt-3e; Fri, 17 Feb 2012 16:12:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyQQX-0001EN-Vr;
	Fri, 17 Feb 2012 16:12:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20286.31877.938411.558236@mariner.uk.xensource.com>
Date: Fri, 17 Feb 2012 16:12:53 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronou=
s/long-running operation infrastructure"):
> 2012/2/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > How are you expecting this ao to complete ?
> =

> I was expecting that AO_INPROGRESS returns 0 if no events have been
> added, so I don't need to know whether I have added events or not to
> call AO_INPROGRESS.

You must always call AO_INPROGRESS.  After calling AO_CREATE you must
call AO_INPROGRESS.

You must also arrange to call libxl__ao_complete at some point.  You
may only call libxl__ao_complete from an event callback.  So you had
better have set up an event ("added" an event as you put it).

Otherwise libxl__ao_complete will never be called at all, and indeed
the synchronous call will never return.

> > If you haven't asked for
> > an event callback then presumably libxl__ao_complete will never be
> > called.
> =

> I'm talking about libxl__ao_inprogress, which is called from
> AO_INPROGRESS macro. With the current code this macro might be called
> from libxl_device_disk_remove for example without adding any events,
> because libxl__initiate_device_remove can return successfully without
> adding an event, and AO_INPROGRESS is called unconditionally.

Yes, you are right, there is a bug in libxl_device_disk_remove /
libxl__initiate_device_remove.  I hadn't spotted that the "out" path
from the old device removal code was used in a success case too.

I will fix it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:14:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQRn-0004Cf-42; Fri, 17 Feb 2012 16:14:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyQRl-0004C8-CQ
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:14:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329495242!9678908!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTMzMTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12397 invoked from network); 17 Feb 2012 16:14:03 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 16:14:03 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id DE3091A8089;
	Fri, 17 Feb 2012 08:14:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=IB9lk4A5TA8DAQ+CBc5knw6pUPG+5KD3/uSVOzW2ClKu
	P7XEe7c99N5D3UxICULP5cQmDPH/Pm/a+4WV08L+stXw1Xkq/4EjkwTfcWJuBWHC
	SxtzhpCo6Ak5vFqwFv0lIpa4PVPulFVW+C5htsfwgcpg8rk6NCsJucyf7oYnbIo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=/cF6UjoGgv/8lm4XRMflTjMmd+E=; b=HcWoAxTz
	Uuv3aAIgY4fpeseYg+keQuxmAq+mZEQksjbAnhCGrNfWPrMlpoI6GCOYE6Api7Bs
	iwcXWeht70L7x8od/pdOaik+AbbeHXiTi2uUEJJnaAK4TJVhBGWEDV7aMDIejbEv
	dwXJXIN/HWmsf5IhVjPtX/o2RsZJz7mYUoM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 6A8C81A8083; 
	Fri, 17 Feb 2012 08:14:01 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:14:02 -0800
Message-ID: <c1bd070755d4f325bd62759107377ee6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216155916.GD41163@ocelot.phlegethon.org>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
	<20120216155916.GD41163@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 08:14:02 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] x86/mm: Four fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:42 -0500 on 15 Feb (1329345744), Andres Lagar-Cavilla wrote:
>> In this series we post four patches with bugfixes to p2m, hap, paging
>> and
>> sharing code:
>>
>> - Make a few asserts on shared pages type and counts more accurate
>>  (this time done right, hopefully!)
>
> Nope, sorry! :)  I fixed the tests up and applied it; please check that
> it still does what you wanted.
Check. It wasn't that bad to begin with :)
Thanks
Andres
>
>> - Bugfix interactions between the balloon and the paging and sharing
>>  subsystems. Posted a week ago, probably slipped through the cracks.
>> - Added a missing sanity check for sharing/paging/access memops.
>> - Fix vmx_load_pdptrs to crash the guest instead of the host in the
>>  presence of paged out cr3's.
>
> This needed a minor adjustment to a printk format for 32-bit builds.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> All applied, thanks.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:14:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQRn-0004Cf-42; Fri, 17 Feb 2012 16:14:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyQRl-0004C8-CQ
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:14:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329495242!9678908!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTMzMTk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12397 invoked from network); 17 Feb 2012 16:14:03 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 16:14:03 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id DE3091A8089;
	Fri, 17 Feb 2012 08:14:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=IB9lk4A5TA8DAQ+CBc5knw6pUPG+5KD3/uSVOzW2ClKu
	P7XEe7c99N5D3UxICULP5cQmDPH/Pm/a+4WV08L+stXw1Xkq/4EjkwTfcWJuBWHC
	SxtzhpCo6Ak5vFqwFv0lIpa4PVPulFVW+C5htsfwgcpg8rk6NCsJucyf7oYnbIo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=/cF6UjoGgv/8lm4XRMflTjMmd+E=; b=HcWoAxTz
	Uuv3aAIgY4fpeseYg+keQuxmAq+mZEQksjbAnhCGrNfWPrMlpoI6GCOYE6Api7Bs
	iwcXWeht70L7x8od/pdOaik+AbbeHXiTi2uUEJJnaAK4TJVhBGWEDV7aMDIejbEv
	dwXJXIN/HWmsf5IhVjPtX/o2RsZJz7mYUoM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 6A8C81A8083; 
	Fri, 17 Feb 2012 08:14:01 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:14:02 -0800
Message-ID: <c1bd070755d4f325bd62759107377ee6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216155916.GD41163@ocelot.phlegethon.org>
References: <patchbomb.1329363744@xdev.gridcentric.ca>
	<20120216155916.GD41163@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 08:14:02 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 4] x86/mm: Four fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:42 -0500 on 15 Feb (1329345744), Andres Lagar-Cavilla wrote:
>> In this series we post four patches with bugfixes to p2m, hap, paging
>> and
>> sharing code:
>>
>> - Make a few asserts on shared pages type and counts more accurate
>>  (this time done right, hopefully!)
>
> Nope, sorry! :)  I fixed the tests up and applied it; please check that
> it still does what you wanted.
Check. It wasn't that bad to begin with :)
Thanks
Andres
>
>> - Bugfix interactions between the balloon and the paging and sharing
>>  subsystems. Posted a week ago, probably slipped through the cracks.
>> - Added a missing sanity check for sharing/paging/access memops.
>> - Fix vmx_load_pdptrs to crash the guest instead of the host in the
>>  presence of paged out cr3's.
>
> This needed a minor adjustment to a printk format for 32-bit builds.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> All applied, thanks.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:14:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQS5-0004FE-N7; Fri, 17 Feb 2012 16:14:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyQS4-0004EQ-DF
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:14:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329495141!8746805!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1839 invoked from network); 17 Feb 2012 16:12:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 16:12:22 -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 q1HGCKG9028414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 16:12:20 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
	q1HGCJ8f011534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 16:12:19 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
	q1HGCJPC006271; Fri, 17 Feb 2012 10:12:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 08:12:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3396341FE1; Fri, 17 Feb 2012 11:09:12 -0500 (EST)
Date: Fri, 17 Feb 2012 11:09:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Fantu <fantonifabio@tiscali.it>
Message-ID: <20120217160912.GG31531@phenom.dumpdata.com>
References: <1329494799149-5493035.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329494799149-5493035.post@n5.nabble.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F3E7C64.00D4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 08:06:39AM -0800, Fantu wrote:
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24823:b75664e53905 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> 
> On boot start to load but after start ramdisk load server reboot without
> message on screen.
> 
> The grub2 entry is:
> -----------------------------------------
> menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID' --class debian
> --class gnu-linux --class gnu --class os {
> 	set root='(RAID-ROOT)'
> 	echo	'Caricamento Hypervisor Xen 4.2...'
> 	multiboot	/boot/xen.gz placeholder dom0_mem=1024M
> 	echo	'Caricamento Linux 3.2.0-1-amd64...'
> 	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro 

IT should be 'module'
> quiet
> 	echo	'Caricamento ramdisk iniziale...'
> 	initrd	/boot/initrd.img-3.2.0-1-amd64

and 'module' here too.

> }
> -----------------------------------------
> 
> I try also with debug options and see with SOL (serial on lan) if see some
> more but also with it see only the three echo line.
> 
> The grub2 entry is:
> -----------------------------------------
> menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID - Debug su
> Seriale' --class debian --class gnu-linux --class gnu --class os {
> 	set root='(RAID-ROOT)'
> 	echo	'Caricamento Hypervisor Xen 4.2...'
> 	multiboot	/boot/xen.gz placeholder dom0_mem=1024M loglvl=all
> guest_loglvl=all sync_console console_to_ring com2=19200,8n1 console=com2
> 	echo	'Caricamento Linux 3.2.0-1-amd64...'
> 	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro
> console=hvc0 earlyprintk=xen nomodeset
> 	echo	'Caricamento ramdisk iniziale...'
> 	initrd	/boot/initrd.img-3.2.0-1-amd64
> }
> -----------------------------------------
> 
> Without xen boot correctly.
> 
> I have missed or wrong something on grub debug entry?

Yup. You should have used 'module'

> 
> Thanks for any reply and sorry for bad english.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5493035.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:14:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQS5-0004FE-N7; Fri, 17 Feb 2012 16:14:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyQS4-0004EQ-DF
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:14:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329495141!8746805!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1839 invoked from network); 17 Feb 2012 16:12:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 16:12:22 -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 q1HGCKG9028414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 16:12:20 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
	q1HGCJ8f011534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 16:12:19 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
	q1HGCJPC006271; Fri, 17 Feb 2012 10:12:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 08:12:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3396341FE1; Fri, 17 Feb 2012 11:09:12 -0500 (EST)
Date: Fri, 17 Feb 2012 11:09:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Fantu <fantonifabio@tiscali.it>
Message-ID: <20120217160912.GG31531@phenom.dumpdata.com>
References: <1329494799149-5493035.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329494799149-5493035.post@n5.nabble.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F3E7C64.00D4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 08:06:39AM -0800, Fantu wrote:
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24823:b75664e53905 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> 
> On boot start to load but after start ramdisk load server reboot without
> message on screen.
> 
> The grub2 entry is:
> -----------------------------------------
> menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID' --class debian
> --class gnu-linux --class gnu --class os {
> 	set root='(RAID-ROOT)'
> 	echo	'Caricamento Hypervisor Xen 4.2...'
> 	multiboot	/boot/xen.gz placeholder dom0_mem=1024M
> 	echo	'Caricamento Linux 3.2.0-1-amd64...'
> 	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro 

IT should be 'module'
> quiet
> 	echo	'Caricamento ramdisk iniziale...'
> 	initrd	/boot/initrd.img-3.2.0-1-amd64

and 'module' here too.

> }
> -----------------------------------------
> 
> I try also with debug options and see with SOL (serial on lan) if see some
> more but also with it see only the three echo line.
> 
> The grub2 entry is:
> -----------------------------------------
> menuentry 'Wheezy con Linux 3.2.0-1-amd64 e XEN 4.2 - RAID - Debug su
> Seriale' --class debian --class gnu-linux --class gnu --class os {
> 	set root='(RAID-ROOT)'
> 	echo	'Caricamento Hypervisor Xen 4.2...'
> 	multiboot	/boot/xen.gz placeholder dom0_mem=1024M loglvl=all
> guest_loglvl=all sync_console console_to_ring com2=19200,8n1 console=com2
> 	echo	'Caricamento Linux 3.2.0-1-amd64...'
> 	linux	/boot/vmlinuz-3.2.0-1-amd64 placeholder root=/dev/mapper/RAID-ROOT ro
> console=hvc0 earlyprintk=xen nomodeset
> 	echo	'Caricamento ramdisk iniziale...'
> 	initrd	/boot/initrd.img-3.2.0-1-amd64
> }
> -----------------------------------------
> 
> Without xen boot correctly.
> 
> I have missed or wrong something on grub debug entry?

Yup. You should have used 'module'

> 
> Thanks for any reply and sorry for bad english.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5493035.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:20:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQXa-0004f9-GU; Fri, 17 Feb 2012 16:20:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RyQXZ-0004f0-5d
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:20:09 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329495468!53186769!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17658 invoked from network); 17 Feb 2012 16:17:48 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-14.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 16:17:48 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 74C6AD3474E;
	Fri, 17 Feb 2012 17:20:02 +0100 (CET)
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 bJtqzoef8B1A; Fri, 17 Feb 2012 17:20:00 +0100 (CET)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 5B864D341E4;
	Fri, 17 Feb 2012 17:20:00 +0100 (CET)
Message-ID: <4F3E7E2F.5@vido.info>
Date: Fri, 17 Feb 2012 17:19:59 +0100
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0
MIME-Version: 1.0
To: Jamesffs <javiapple@hotmail.com>
References: <1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
	<1329478339260-5492208.post@n5.nabble.com>
In-Reply-To: <1329478339260-5492208.post@n5.nabble.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi James,

ah ok - somehow my client didnt display anything in bold, therefore my 
irritation :)

But i'm nearly equally irritated by your Problem(description)...

1st, for reference, here is my xl dmesg output regarding iommu:

(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled

Yours indicates a few more "not enabled" features, but iirc the only 
important one here is the last "I/O virtualisation enabled", but dont 
nail me down on that;
Is "01:00.0" the output of "xl pci-list-assignable-devices" ? if not, 
you have a config/hardware problem you need to solve first.

lets assume your hardware is capable and your xen is conf'ed correct 
(xen cmdline and dom0-kernel cmdline regarding pcipassthrough and iommu) 
then:

after you installed your domu os (i assume here its windows), with 
gfx_passthrough=0 (so that the cirrus-card gets used as primary within 
domu), you should see within the qemu-vnc on localhost:5900 (or 
whereever it listens according to your domu-config), 2 Graphics-devices: 
one cirrus, working "normaly" and one representing your passed-through 
card, which is disabled because no device driver is loaded for it.
 From here on you should be able to normaly install the driver for the 
card (nvidia/ati-catalyst installer...), and after a reboot, the card 
should get initialized and bring a picture to the physically connected 
monitor of the passedtrough card.
After all that you can set gfx_passthrough=1 for the pure cosmetic 
reason that the cirrus card gets removed from the devicemanager (and you 
therefore only see the qemu-command-console when you vnc to 
localhost:5900) - but its not necessary at all.

Good luck!
Greetings
Tobias

Am 17.02.2012 12:32, schrieb Jamesffs:
> Hi Tobias, thank you for the answer.
>
> The * on my cfg appear because I used bold letter there.(They dont exists on
> my real cfg)
>
> In order to install the driver I need to see the graphic card in my Windows
> DomU, so I must passed through the card first right?
> So I used the options 'pci =  [ '01:00.0' ]' and 'gfx_passthru=1' to
> passthru the card, but when I do this (after bind the device with pci-stub)
> I just can see (through VNC) a screen with qemu console and after a while
> the DomU crash. When u said before that it is not possible to see the DomU
> with VNC I thought that I should use a monitor attached to the graphic card
> but Im not sure how to do that.
>
> Anyway Im start thinking that the DomU crash is due to VT-d is not enabled
> properly, after using the parameter iommu=1 i have the following output in
> xl dmesg:
>
> (XEN) I/O virtualisation enabled
> .
> .
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation not enabled.
> (XEN) Intel VT-d Interrupt Remapping not enabled.
> (XEN) Intel VT-d Shared EPT table not enabled.
>
> So maybe the problem is there...
>
> Well thank you for your help
>
>
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5492208.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:20:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQXa-0004f9-GU; Fri, 17 Feb 2012 16:20:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RyQXZ-0004f0-5d
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:20:09 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329495468!53186769!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17658 invoked from network); 17 Feb 2012 16:17:48 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-14.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 16:17:48 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 74C6AD3474E;
	Fri, 17 Feb 2012 17:20:02 +0100 (CET)
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 bJtqzoef8B1A; Fri, 17 Feb 2012 17:20:00 +0100 (CET)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 5B864D341E4;
	Fri, 17 Feb 2012 17:20:00 +0100 (CET)
Message-ID: <4F3E7E2F.5@vido.info>
Date: Fri, 17 Feb 2012 17:19:59 +0100
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0
MIME-Version: 1.0
To: Jamesffs <javiapple@hotmail.com>
References: <1319695116310-4942047.post@n5.nabble.com>
	<1319710499.206.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
	<1329478339260-5492208.post@n5.nabble.com>
In-Reply-To: <1329478339260-5492208.post@n5.nabble.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi James,

ah ok - somehow my client didnt display anything in bold, therefore my 
irritation :)

But i'm nearly equally irritated by your Problem(description)...

1st, for reference, here is my xl dmesg output regarding iommu:

(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled

Yours indicates a few more "not enabled" features, but iirc the only 
important one here is the last "I/O virtualisation enabled", but dont 
nail me down on that;
Is "01:00.0" the output of "xl pci-list-assignable-devices" ? if not, 
you have a config/hardware problem you need to solve first.

lets assume your hardware is capable and your xen is conf'ed correct 
(xen cmdline and dom0-kernel cmdline regarding pcipassthrough and iommu) 
then:

after you installed your domu os (i assume here its windows), with 
gfx_passthrough=0 (so that the cirrus-card gets used as primary within 
domu), you should see within the qemu-vnc on localhost:5900 (or 
whereever it listens according to your domu-config), 2 Graphics-devices: 
one cirrus, working "normaly" and one representing your passed-through 
card, which is disabled because no device driver is loaded for it.
 From here on you should be able to normaly install the driver for the 
card (nvidia/ati-catalyst installer...), and after a reboot, the card 
should get initialized and bring a picture to the physically connected 
monitor of the passedtrough card.
After all that you can set gfx_passthrough=1 for the pure cosmetic 
reason that the cirrus card gets removed from the devicemanager (and you 
therefore only see the qemu-command-console when you vnc to 
localhost:5900) - but its not necessary at all.

Good luck!
Greetings
Tobias

Am 17.02.2012 12:32, schrieb Jamesffs:
> Hi Tobias, thank you for the answer.
>
> The * on my cfg appear because I used bold letter there.(They dont exists on
> my real cfg)
>
> In order to install the driver I need to see the graphic card in my Windows
> DomU, so I must passed through the card first right?
> So I used the options 'pci =  [ '01:00.0' ]' and 'gfx_passthru=1' to
> passthru the card, but when I do this (after bind the device with pci-stub)
> I just can see (through VNC) a screen with qemu console and after a while
> the DomU crash. When u said before that it is not possible to see the DomU
> with VNC I thought that I should use a monitor attached to the graphic card
> but Im not sure how to do that.
>
> Anyway Im start thinking that the DomU crash is due to VT-d is not enabled
> properly, after using the parameter iommu=1 i have the following output in
> xl dmesg:
>
> (XEN) I/O virtualisation enabled
> .
> .
> (XEN) Intel VT-d Snoop Control not enabled.
> (XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> (XEN) Intel VT-d Queued Invalidation not enabled.
> (XEN) Intel VT-d Interrupt Remapping not enabled.
> (XEN) Intel VT-d Shared EPT table not enabled.
>
> So maybe the problem is there...
>
> Well thank you for your help
>
>
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5492208.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:21:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQYt-0004jA-0V; Fri, 17 Feb 2012 16:21:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RyQYq-0004ip-Hj
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:21:29 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329495680!11919233!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15104 invoked from network); 17 Feb 2012 16:21:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 16:21:21 -0000
Received: by wibhm2 with SMTP id hm2so5468993wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 08:21:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=HSh36GvXylM68VW8yQP7Mbx76uKzZ9mPihn6meDdYY8=;
	b=rKDwrZJ42Oz2u2a6dgbXvhQaQVlAf4O0CMhMD0MI5iRsFVw6OuUhCBn/CW1xKYIlWH
	Gjdvcu/EyuntYb3rcDjUoVy/4/g3/B4icL+2yD/puledH3gNpGQ4vdEjyELBC/0Anf1b
	In/bWq6IxbdM1cy4UJBHGO3Z8o8vjGJAEqYMY=
MIME-Version: 1.0
Received: by 10.180.101.72 with SMTP id fe8mr4818929wib.4.1329495680486; Fri,
	17 Feb 2012 08:21:20 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Fri, 17 Feb 2012 08:21:19 -0800 (PST)
Date: Fri, 17 Feb 2012 11:21:19 -0500
Message-ID: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=f46d04430662c40d6304b92b55c3
Subject: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--f46d04430662c40d6304b92b55c3
Content-Type: multipart/alternative; boundary=f46d04430662c40d6004b92b55c1

--f46d04430662c40d6004b92b55c1
Content-Type: text/plain; charset=ISO-8859-1

Environment:
ASRock Z86 Extreme4 - Intel i5 2500
http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4

I have installed the latest UEFI patch(1.70) and all tests were run from a
reset of everything to default. I have tested with both Ubuntu 11.10 and
Fedora 16 and get the same results on both, including building xen
4.2-unstable. I bought this particular MB because it had a know working
vt-d implementation via VMWare.

NOTE: current unstable as of last night is still affected by this library
error http://www.gossamer-threads.com/lists/xen/devel/234300

However, after correcting the library error, I was able to complete the
unstable build.

In both cases, it either stops with a panic/blank screen, or just reboots.

Here are some other notes:

1) If x2apic is enabled on the motherboard, it almost immediately reboots
with any of the configurations above

2) The boot gets to here:

(XEN) HVM: VMX enabled

(XEN) HVM: Hardware Assisted Paging detected.


Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is where
it hangs with the blank/panic screen or reboots. This sometimes shows up on
CPU 1, CPU2, or both.


3) There is no boot log written and the machine does not have a native
serial port, so capturing anything may prove difficult, but I am open to
suggestions.


4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic is
enabled, then it simply panics and reboots.

The logs(xen_live.tgz) are attached. Note this was captured with VT-d being
enabled, but I did check it with VT-d enabled and the boot looked the same.
I can capture it again if needed.


5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d enabled(which
shows working in xl) and x2apic enabled.

I have also attached(xen_server_6.0.0.tar.gz) these logs, which includes
logs both with and without VT-d and x2apic enabled. I did not actually
create any VMs, only booted this and checked what xl reported.


If there is anything else I can add, please let me know. I am going to
download 4.1.1 now, build it and see if it works, because it does on Xen
Server. I am open to testing anything as this is an original build on this
box, so I'm willing to knock it around if it will help.


Thanks,

Paul

--f46d04430662c40d6004b92b55c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Environment:<div>ASRock Z86 Extreme4 - Intel i5 2500</div><div><a href=3D"h=
ttp://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme4">http://www.asr=
ock.com/mb/overview.asp?Model=3DZ68%20Extreme4</a></div><div><br></div><div=
>I have installed the latest UEFI patch(1.70) and all tests were run from a=
 reset of everything to default.=A0I have tested with both Ubuntu 11.10 and=
 Fedora 16 and get the same results on both, including building xen 4.2-uns=
table. I bought this particular MB because it had a know working vt-d imple=
mentation via VMWare.</div>
<div><br></div><div>NOTE: current unstable as of last night is still affect=
ed by this library error <a href=3D"http://www.gossamer-threads.com/lists/x=
en/devel/234300">http://www.gossamer-threads.com/lists/xen/devel/234300</a>=
</div>
<div><br></div><div>However, after correcting the library error, I was able=
 to complete the unstable build.</div><div><br></div><div>In both cases, it=
 either stops with a panic/blank screen, or just reboots.</div><div><br>
</div><div>Here are some other notes:</div><div><br></div><div>1) If x2apic=
 is enabled on the motherboard, it almost immediately reboots with any of t=
he configurations above</div><div><br></div><div>2) The boot gets to here:<=
/div>
<div><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,A=
rial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lan=
g=3D"EN-US">(XEN) HVM: VMX enabled</span></p><p class=3D"MsoNormal" style=
=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;ba=
ckground-color:rgb(255,255,255)">
<span lang=3D"EN-US">(XEN) HVM: Hardware Assisted Paging detected.</span></=
p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Aria=
l,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lang=
=3D"EN-US"><br>
</span></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helve=
tica,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><sp=
an lang=3D"EN-US">Then goes to a &quot;(XEN)Failed to bring up CPU x(error =
-5)&quot; and this is where it hangs with the blank/panic screen or reboots=
. This sometimes shows up on CPU 1, CPU2, or both.</span></p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lang=3D"=
EN-US"><br></span></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,G=
eneva,Helvetica,Arial,sans-serif;font-size:13px;background-color:rgb(255,25=
5,255)">
<span lang=3D"EN-US">3) There is no boot log written and the machine does n=
ot have a native serial port, so capturing anything may prove=A0difficult, =
but I am open to suggestions.</span></p><p class=3D"MsoNormal" style=3D"fon=
t-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;backgroun=
d-color:rgb(255,255,255)">
<span lang=3D"EN-US"><br></span></p><p class=3D"MsoNormal" style=3D"font-fa=
mily:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;background-co=
lor:rgb(255,255,255)"><span lang=3D"EN-US">4) Xen Live(</span><a href=3D"ht=
tp://wiki.xen.org/wiki/LiveCD" style=3D"background-color:transparent">http:=
//wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic is enabled, then it=
 simply panics and reboots.</p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)">The logs(xen_l=
ive.tgz) are attached. Note this was captured with VT-d being enabled, but =
I did check it with VT-d enabled=A0and the boot looked the same. I can capt=
ure it again if needed.</p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></p><p cla=
ss=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-s=
erif;font-size:13px;background-color:rgb(255,255,255)">
5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d enabled(which sho=
ws working in xl) and x2apic enabled.</p><p class=3D"MsoNormal" style=3D"fo=
nt-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;backgrou=
nd-color:rgb(255,255,255)">
I have also attached(xen_server_6.0.0.tar.gz) these logs, which includes lo=
gs both with and without VT-d and x2apic enabled. I did not actually create=
 any VMs, only booted this and checked what xl reported.</p><p class=3D"Mso=
Normal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font=
-size:13px;background-color:rgb(255,255,255)">
<br></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetic=
a,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">If the=
re is anything else I can add, please let me know. I am going to download 4=
.1.1 now, build it and see if it works, because it does on Xen Server. I am=
 open to testing anything as this is an original build on this box, so I&#3=
9;m willing to knock it around if it will help.</p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></p><p cla=
ss=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-s=
erif;font-size:13px;background-color:rgb(255,255,255)">
Thanks,</p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helve=
tica,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Pau=
l</p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,A=
rial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetic=
a,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></=
p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Aria=
l,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetic=
a,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></=
p></div>

--f46d04430662c40d6004b92b55c1--
--f46d04430662c40d6304b92b55c3
Content-Type: application/x-gzip; name="xen_live.tgz"
Content-Disposition: attachment; filename="xen_live.tgz"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyrew38j0

H4sIACxsPk8AA9xc63PbRpLP5/srpnY/rOS1GMxggAFY5aulKMnhxpIYUcmlVudigQBIYUUCNADa
Vv766x48OHjxIdvZ5FiJJYHdv+nX9HTPAPBWfrL47tt+NPiYXJM/4ZP/5NlPCr/p5neUCiq4qZsC
rlONAxnRvrFc8rNJUicm5Ls4itJddI63+j3E+b0/DwQ+Wi9zyXsyCoM0cJbBb0G4IO4ijjZrkmxm
yXNC3PUm8dP/OoqhTv0uCDefyUc/ToIoJKxn9ph5Rs8+++GZs/JMTk4u/FngbL/ST8nJJ2fpBf/w
5Be9KF7ApYXrlii8R3s6YZpmaUIDhHXsx/7SdxL/tIRDGnbG+Okp+Sslk+sxmTgp+Sd8QzVg7et2
n5nk5/sh4th1qYfRauWEHlkGod8nMwiUN8vgo0/AHnHorHz5F+hAHqMklRfgDycjCUHEN85mnpA4
Im4UJtHSf5OmzxpZOZ+nyyhav2GGWR/xfHQ7OVvH0cfA8z2yfnxOAtdZkrvBNbCt+3Vy8qsf9olW
+5Cz8hKzrOzSySZxZkv/tI5wGaZ+jC50PG/quCnIPo2dcOGfaK8J/EdNw7KsU6IRP0zjwE9INCcg
ONrAq4OhZut5OAVR1yD+m5y7ThZA6ExX/iqKnyUpDF8nubgeQSgIAj5NYODeNxWbEN+Jl88ExgJj
kgcmr5+ZOrWpeE/uL3+9JxeD+wE5n0x28lLyYOrIfcYgq83n8/foIFL4cycvg3GpyJjZzJLM47f3
g/N3l3W+f0WhT8ZXN0RqnDSjAsw3IOoHQuK/5S9csxsxJ8l1VtAiiSSHZGwZooX8JopXEJSkJNlF
fh19xMAjv6HQmHJTKfo8ikF795GEkefXeaRZpvgNxscDfU8yFytKN6WCv/o1fdvD7zaUgwJRGqXO
cu0spO9aaTNToux9AtEjaWUMSQUghkG+XTxazoJhHH9sC4EtLYfFLyN/Td6Nrm7JzEndx77W5a+M
izHKjpCr5KOGbVht4+m00+NVnfYOp7r+YLbBcDzqk7vJxRiT2JXGDZzRGoMEHzMyeDeY/DhoZLGM
6dfJxT05vzKgshCSyRgCE82ZkGNArskIQxUnmk0GkGWyMNZgwWkHvYIfEtSi1ELQK5SEfxnoRSkp
NQBUXJ1fKOopoEU4j27u3+ESZVCol7olnQCoqZ1fWVJ93gidjHAwHg0zlRiVhILB6PqXqTQpVLJg
zQFQqrHM+Nej4fhnyT6+ux0WKlFyPbm6J0SXILQD9Hp49TYD1W0pqb7Hoxmo/NhddhoMrnJJ9QsJ
eqGroLeX15LiONAfxpc5KB/IMNGtvbHXK1NuV5hcD+5y0Esp6bnWDlrYVIZJ8VcH6Dvp/hPHXQfT
wHvQPmuQX5fOOnDzPzEBhzhxvYMRWBWBHY+gVxH48Qi8imAehDC9gdBWUHDVfQwWj8T3Fj7WfSlc
pO87IEa3mRSl3aAagUyfIJDv5qSLJJjOoCh90JowGQB80ye56Fi8FAUu/JoDki3ga/J2MiJQJOgd
Mt3cTyd3w+ntL3fkZLYBVgL/ToP4A/y2WEYzZyn/YMSbL/H/Lt26cWwVx87stfQ/+p1Qdz9pWdqf
PZMItIuhGmqUdCUtO4LW3k878dMUK0XpKmhT5B9pRKBUr5P+nEhCACcn14OL+1O5TmHXAAX8PFhs
YidFxwThHBdE/L0h2XIZuY4cYzwc4bofbWIXlj1Z+siKNSWZJ7EqX0BRT2bzrEjv63OD4ncNO44v
7yCJ9lV0WPdtBoqnWW279mPsu4jnpE6d++ZuCtyTPtHZaxLGU6CDSIOahzfaj02wTCGP4Iq9DJI0
AVWzcjOKPT9+TVbRLFgG6TORDR/KEYWQxu6xkCJlJaWbrLH0/Agtk78EQ/7eLVWlUQU7/LUh2nh0
QR6d5JGkslzJO4Z+VgmfSM1BK7CdzoRpZTZvNlKfUz/Epm14fTshz1DC9nHBbgyGDUHsr6M49T30
iM16BlSW1z/8hn0CREoSxUoMcy1rRKWyfdB6CfFEfnk7+DuxtM/MqFPmZiEPaJcyBXZSPX50z2gn
2QWa4pm4UKf7rRaiOpXFQ24jWPiKjqBuJJ77Agrvs2480zD0rcnFa2IwDuVEB9okmqefnNiHNEru
350XWvRJnZAMYHqkm9jPGgSTQ+25cCRogzSPU9ll9Am0YXPZQjPPxFIFWuvykpldag6W5+wk+A3r
c0FmQdoYB5LDGSzv/TznJIUqs2gTuvBjM59nDS5mINDvZPI/o1tQsmGEa9lHQ3fC4WM9fW+aumGw
J+J8dIKltO4JY0I8kadiAno+uIlqhsmfyr4EHce0J5k+XhNGzSfZpTdGG45BZJznZB1FS0kj5xbE
PcU0RPMiH/p2J8tV26iC/krTYVkeAsMszrKY5y+dZ5j8MicHK0hiydp3g3ng5qna7/UgKiyzxw1y
Hi2i69F4Qk6W63+/gdgTzKb2qYJPhYEJ393EmKOuYsgfn6L4SZVToWY6dPeTS7k3BZFxEcgtEg8z
NCamnkpq2yj42snT37vJdQeobgpsejdhuiPOlTQFLNymO/fTwkQhhhmyb/PNcd1U4TCpsZPD8z8G
rq+OYdo6uhoWnHdQU2bzH3PVj6/xwoVyQWGysOzLmFhBAXpWSExakOgFiUk5V2lsxnOacbH7NS7y
IhldQB+pElslcUkzjDAjVAltjYP/cCF3likuNLibAH5IPgXQ8uYFwc9jOTlKLptZplXUGhI1Bktl
G5i46aizslM2NaZbYu8IWSWxHcKEWYUx2Fii6F4KVqc4yl1VplZ3VUna3VWh2eeuKnHTXYpGlkbB
8OcQpIvHlECkcuRK6gRwTYPJmjqZgRMQ0DvzopUThP06Lcmu4x5Rw5Z6nThZO0B51rhOsrJH7hJS
qKAbBIBGXyDR/vHkaKoty/HYNxlPjkZoy3j6NxlPzyyqEujW0UGtMnUEtUrSFdQKzf6gVombQa3/
v5umjZgI/XSKhTo42cV9RcY4qZRWBeHN5X2f3PkL6Cv8GE834iiNoKAlc2cVLJ+hb1A5GC1SLzaf
6fMaSg43gBRc8CvElDNZUeUbRtVmDeIP22/iF01X4i9WsBJnDa2Pje0ZmNRQ8BjuHki8myjNq5Pr
6+HtzdXobU+lw7Ve0mVVXHVgKTOVBZwUAJZlsOWW3YZGqdDxcgjei6InTHaXQ+y6cIuwpKUmdFQF
LZ4RkentZHQiK5dT8mHjQ5UeLMJINQvwWGy7kzQik2cw3Ir8Am1KBNX1fUTOfXIVLLHkOX8mt73L
3nVPYRecq+wQC97GTckN+PoAbgtt2OT+JdvbOATAtFWA88iJvXzwf0EXBv1W7K98rnDYrMqBdiq0
HUBtCWEfQr28cIAz9BJYCFx1QNumDfYLKGBhcljfM+N7ptFt8FOhGaV1x/LUEQILGltkxf0B4swi
aFph1V+il85wj+kfHxd+3MsKcTzQVNAoFmn5tsac/EXuSEVJ8Ea6+C8Eq9iEzPw0xS58nY0XRmkw
fz4I34ZpWeLj2RkU6PBvvfFDQqsMypNks8ZGNSETjUwomehkYpwqtFwvDZ5NgHxDDEM+wFHizTot
9lwUPkM3v+J8pTbEiooHfZSDRXyJUHQ5OK/k7s4qSh/9eCZDqtyiKQGZJXSjMrGLyV9BPSP+PPuU
nDo38cQwj4rhiNxBHwGFTIC7iQ9wASbxidzqUTZ5TK5xk6tco9J2d/l+1b3sHx7+dzo5n/YQpzcd
392/VyDMrYMPhRhf/tqCY1kvwOENHGG8RB6jgWNR8wU4ZhPH0l6AIxo4Nj/aVRLn/I7ROhh04S9R
Lgc7v9NbEMXL1CwQG46kTDe+EBF+Yw1Y/UV+3cI2IoXqL/RwgdiIGaihvkz1RvRQQ7O/CNFqIgr9
ixDtBqKpH58BtHEjFIVGO6wHa9oTeXh38+MAsuHo7qcEyn9ODGISgbflvKIUqkhCOaHKanMI3rmK
96oEbMUzqGaLPXjDAu9VIWA3mjDpHrSLrXSv9qDp+2W7bLWdCkdeaQqiZe5DvDoOkcNqtwfxbRPx
VafOhs47IrnE+6GO92qHfw1ZFWQ3no2XmwXBY4cxbjdOsrKGfNR6tiAn7ikZeM4KylH4ss6/Dtcg
TjjO6gbc8qtT1JuUcN3WpGzhiFz9cRc1xqag2CVtqUOaPAQPBEkQwdef3bl1hv/OyXzpLPCIkO7g
rFpAKpPt+72Gri4h45ux5mhW/lPHI1HcwGqYs0CkL5CfFvKvoAvBA02PYil0lv1qzw/RpIZR1GKA
UdRiR2PA4PZWDlt/IQbbYugvlMPXSgxfOxgDXebiL9DULzE9f9gE8dM0kd3eFHrmaemZv2ufte8B
zXB34e2PFBhub4SwF0QIq0a4NEXtszVJ5vlOy9SwmI1ozD7Apl9Zisxg7Ov4hx3oH9biH2zutkj6
Qf7BZq3Ck1nGWzmQgQsj8Aq92UKvWLLN/sAlOrksCmyW3sFndfMJ5BMdfHY3n418s+P55sjXrh/D
s7MOPhfN4nXw6VW7HOB7hrcVNH3PcIusQOKH+Z5xo8KjSi1QakHbpeZ2G1/8gVjt9Dav0B+g5axD
S9U/xmFa6hqt8Khamhh7ZruWumFV+A6Q2mqXWsd9wALJPFBqm1V4VKkp+oa2R5Ru6518jAGf3sXH
O/k4Bz6ji8/o5DNxPLN9ZutqHqnzGcjXNZ7o5BM4nujiszr5LLSnpXXw2d18aBfLbOXjakao82Fh
Z7XPFa5Ga53PRT7/aD65NLavjMDXHWcO2nPWxdcdZ35Wr3Xw7YgzDxm51z4fuVaNmC9cd01em2Ev
X3e5GsvisPnN1bgSVTvMs5Kk1QqGaneh5l7aPtEMW6swHKQmb1NTHlEUSNZhasIKV+GpTHNU02yf
djv5cNqZvINPtPGheVrphV7V6QDr6NA+ZT9nbVayDcWx9kFWElRdIOzapJAdAzdavQucvJvTwDzD
2xMicBqdnJTKlEhpe9IAXrOT15DyGp2jihbObcPobhvGrgYJMKwdGO62yXI7G0bAsHfJgSt5Lodm
dWIIrRtjXjauzZ6igsEqGF/Y7AmLVz3z4mZPWKqFnMPi2KZahacajVzGcWvBDpyswvmFyd0Cy1bx
dtthdHOvzzVvR5K35K5pgTg7yB6WKfQKTz3KtlsKmqa3R4ita9VxD/Aobd3gsY08Xrf7XX0yjzYA
RVn9JjEgN/XygEeOUtkB24Rte2C2aUFS+eyH+PTf9kYcecQ2Q1NFIfFiEGt7B2zBtElmboQ3cG5x
Seh/yo4Z547r54xIOE9ezP24mR3Km1lEGbbOqJwfSgPJOznvfmqchwpBt+eod/dDgsfUn5wnKOTi
aEUm2/YanJ1n5T5JH8ux/5aF/d/wVkMy8+UNxg3jA6+AuZ+RFns9QYTBJu917diRUyCrT7ABIMWl
bBdg2/bcLkCGZ5h7JGzs1e0ExJvy9gA2Nu7caLP08HAdYNtA9X1qt+3k7ZKSN9XOPZvdalUj5hVi
hqPL7exi+O1W185B8Zy3irNjUNw5UojNxqDb2nzXoIbB6zjdgxpG1Xl2c9Cy9tk1qKxLd+OUldBO
HIvtwVHrol1IAjdWdiJtq6RdOJZmNXHqM7peMu0Lb8ui+0CbNdQuKe02bWtSNgqqHYDQyrY4tALY
Ul3tUZtreN9LFbQzNIG4mkqdlpAqypldmlBu13E6BzVMlFAuKtkNJdmD/32ZMXpanZDgUwOfgtCL
PvXlPStnvnqnSkl1fXldkoG5rK3lZlr15paSZXx3eXV5P/xB4csTvVY82XSmXKrfJLNLE+ru0cTL
b9Lv7dZkB1lD+k7aLgn5bglRfe8QW8+Mra2NQ219tLTG17Anisi30vJvJq35taTVt9Lq30JasX/W
/Ydj1QaT/rElBBvyP7yExh9eQvPrSIhThW5nDa3PGmHsy/5eM/vDpRqOzTTWpYlQNbGZyfZrAvU4
PcDWtjxQOMzWNscdpHYJrYqEBrMOkNDIht4noZmpe5CEAu+9aZfQrkgo7AOiwbayofdJaOPu6SES
Cun7VgnNSlZCQlPbJyFQUby3+4h4RZYOjx8Vr4DDcK+oa70SCmEeiXs0kSdUOzVhdQl4R2Qcq4lh
dNyjphaSD4P3+PYcfMsANcmJfLD/NVlGn07xMm5gbB/UAExTFFsdxYP2Syf1Q/c5f54zmhc7Jeog
eF+8yRUYQTtuJlMrQ1U00S6a6g8Lt1WOEg0HaYhmif2i8eNEo9vZcYRovC4a1bruzVXrv4fzYxxK
qfkC0YyGaLTrDka12HsYbkWz2kWzFEydseNFMxuiyQ2cPaKJh4utaHa7aLaCyS1+vGiiIZqhddx7
qyZPNdYOEM3UjxMtG6QhmrnbauIFyYMK67jkIVqTB76aaY9o/Gir2eUzKgeLxltEs8XOGWq/wKGM
avpRotmtDmWU7XOocaxDGTOOdqjRIhrrupVfrXmPS7mMa0c71GwRjev7Yk1URduf15jc6TxONNEi
mmF1PHKjVq9HxprQrGNFs1pEE133iqtl65GxZh25UGWD1EXTNZyh+55NLZ9MFgaFIH9PRmN5juPv
eDlK9raY4mUm5msC/QzlvPYyEwCU90jdD8fETxAiSB5BggNet2IDpGYLarAmpmnmmDOoFQ9410rn
q1sEvtFNSKw++aHEScqn9kDWE1XwXEg5rhyjAoUHCShW7IdRyzGVMHWm6wc8K6ww6HjyCk5wnzAG
gjkJVviCkiCRt+vHzmqe9Ho9EqRwqWQTunwXyVXs+5ILKeXRq3yZCjMN3Xgic/h2K5rIXtThbLwg
7W/f/oHsoZ8u8SGFJHKf/JScFHX/aZ0ZD0jf4IlTBnMCJY3NLduCLAjB0qen/bbXihTcv1xN+via
kifyYROlTkI8/Dk1e0aP1mkv8KsdryCBOM6dj+8Zk686qjk+B1oli1UYbLexE1AQ5hDV9caY50vQ
H2bhM4BOhjCNF36Ij92Sk1myOC22tsvXm0FBu4wcfGfSycr5dxQTZuiN4YMoe83AZgmsYRS1PV3R
SuuEaeAGaycFjx7K4/mOh2+mOpTenX9Qj4VPPH/ubJbFa3OgVNEF0/DE1g3yJETlWgytJD4Yim+F
jfIkpbBAQHxhSyVhDDxccJIkWITT8mnc6QpffXolj/WvJ/gWguKdNgqnyUFRmJ/RpxDiQ/0C70pb
OWt5x9TcCcpHh+W3wty+AM0nYzwOmfgxCvqgCtoHa/jQ/2w5LQ0rmkM5dZXTEMetT80eT8KYhvky
W1kCE22LrSwLD2q7bGVZ1l6NUdCmrWzKj6tjmq3jFuYlGmecLRpnX3RpnH27V2P+tTQ2/iwaG19L
Y/PPorH5tTQWfxaNxVfQuNmW/wc1/qKe/U8jN/+KcnNOsT1rys05tKadcnPOzeOqgWZLLWEMbDJe
JLf4P/autLmNHMn25/kViJ75IHlECkChLm44oilRamusgyOqbe9qOxjFS+KKItk8fPz7zQfUSbIo
Vonq6NhYha2z8BKVSCSQiUSm2LgboD+42/rt+4UtR2e937RNVeX67dlwyW3ot+fgonFevz0vdveX
NcY1jO+XlBNf5PDbF9v47VvF+e2t99u3y/Lbd+Bu39RvBz3L7bcvC89Lf63fNtfpeEr02+Y65ny9
3zaXMl+f2A5347omwcP0AYUNknDSr7wquLX6NK0MZNmRsS1tfizIOOaRTfSP2zC1IBn5VZ+zfzDF
dOqdI+33mD8GOhloJl1PgrseEKoJbQkITdp2Zr0aIzaRPRNaY6tPDMfTJRm8V0GX3m9CluTzZDlH
itLFgqy4/vNyZBL3EK3j7oiG4Fi3MJ/5Khry334dzhbLYBSnoZ0vdWqswXJEpv1wPF8EOisUAT5+
7a4hnH3tI7nmYzBGPtNQNuJW1fTjOPwk23wwm4wXK/HGUR/6yAREz2QDj5Pma7wdelxJ9tTpvche
NI+fjm6QbIzvepFcsPy+E7nmdbPGmq1jiZTBi9lkBCv1PryWUmu25MffkcMI92qO9CUZffUlHwWF
XILZHLPtMfjaZ/Xfvmi5jE82j+BwWTzC2QJ/S3cym/W7iyhDFdKosm/DxaPhQ3U8ofdLURM6gJGE
dVILOfXxpGEIbOmlp2z4cp+HyDenu2kkMhQFpJgmcUS4NUmEfizV1LHFBi7PFt1293ky385kT+kj
xehhPaSqhp/ZWoh4/BDh0fc8BeIjagC/q1EHg9nzHFnfiMPIs009XzwesR/WU7qB561TzRMkz+a4
0nU9YcOT8ztiyoIGJD0vPNtCOj544brLDjLtbnhT28I68KIbzl1tkeLAIpg/0aRczGOPj1h7euWd
5uEKEIZEdrU/iTgjuZAVLivCZULVlBUVbUr8Z87hKnbk2luOdYr4MP1x7OFDiuOUf0+QvlY6JjpU
d/U7djcLxvORvr1BSxOjadz/YXKGbVR18dsJm7aJcWaQsDCGw0/OTAERT+kiDvQR1dVgp62owERO
YQyA2rbw0zcu6M+0FnJMvBTXA3hmJ7gT0zbzgW9GSFI73jf1aXSS7c2jqUEDvdAXazCCsVcwvxvi
pW6IXbohXtsN+VI3ZILg2tJdR7BeQohXdUk7evul0ICgyLGGxtRpCItZwsHqfkjD0H6//9gdth+7
vcyjNXb2gTr7YTJfpFaJpKkUOOLKaYqbL7+1TvRtn4RLR+HOC6UY6A/j5XOHeioSTEdgz52D2et3
lg9G68tUEymic2vjxdaOWSRVBwssPdII5w7lxVSB2MCZNCL0Qk4n9BLjHMG/G17A6jjc4Txp75Cy
cXPbgymSxkHXeQBHNJNJHfGjSFULzhr9LpJHqxSowuHfct7Bf1zsyyRD/Ltg3cfJnJYjfRdI/5Ra
z6i5jWtYj8sOExXqStQT/ELf3Uo96eBgJfOkNHvMeI2IH3YtC1bnb+MhCl2wq+VoMaw0SQ71j2eV
i8ZZ+FKpJgrnMMMeLYP1+Xz5DMm1LNQ1CLU5JGM+7YfVn5oXN9h29uf/EZfuCHcKEIf5++/fI2jL
sXUdtoRH16EQhqOtX5RGrmeSfb4XPaeDH8Oco+9pnGQaDMH7uWDzBXbac9rvDmbvraMocel7eRRu
36+1cL8XCaLDERqRIIZNts8zaiaQ4zZpdhWMl2Q8oE7BrBZaFhsqJUbylwaCpZsApftZ2zgXaHRz
s7zFz/cyqktaG1WXtFYxi6mu3qrqimDWp1nvJdX1QtMiqiuRF9fahrlJdUVNXqm6eqnh2t4JXc7H
WlFddkp14TAC7oic9uVUl+XF9yPxXxZUXdTcdULVJbeqLnrSQ6hK5sk81aV8i/R0ulevUBYAc90t
YIWVBSG6Nk8j7qQsqJmOcUqalVQWAHJVGihHWaSkT/mui6ujZFH0sB8PrwIbTsZmBfwoMCv0ua+p
LAGlv3aajSddGyeFo2EnWASxcWCRvIUeiARUy7FeVdrhWXItsi1h8f1MBkkHRSLnT++RuubnyJMx
DVD7AxmOsdbgKV16iczBUf8hIIV00aozrGJaitLkMDrN8Hk8kPh0qBO8Wo37hvRI0UoiKsLoF10L
yyxyKTExGcTj2Yfb2VFhr1jWiCfaZRjDFZpNru1KBFya5V1smU30pMJhZ+ZJJ2c2kS3p4QrtYy8g
SbmzLMkdyeutI4ZyqI2L1kejIOLnHRnPPv0SL0w+j3tudvJJlcZy/XyszNzjydzjK3MvlGNZ1cUW
PQMoXztgsiotK95JyIIDhtbKwUVLo9TyB0w/6UEoM096GwdMVqlPlstTnSo9ABpLWU4+VuEBQF0w
vVvtdWBf15FQ80O9paRi/3kU/uK0cdz41Kjc3lylJYva+sJH7tzcqSniqSmrtF5I7K0ee6QuPjdO
6b/kZ/XbVoXzq0+fT/hm+bWQJ9XnrtY33HigxMAk03KPoF8chupvsBRU0kRxpIRGF8ImOjeacHUT
N2lix00cbsF41bPqOfhOu5E/ln1S/KZilC3kx+FJ9LArlEKMg37YkbYgdimPzWnYJ7M5O0C9YVey
q5ND9u0YuXsVNWan2HYcsdMPrfe0fArrWNr2sWPFoLQK2NG8NluUwWg5f0SdumhPknrWQ1SneZg+
CXyS+BTjedzxkClHM/ylN/K4q5AgJiUGyvvComHXXyuoeH1K3xzffjZDhFg35T2Fr5bC8iBSkaVy
mhKdGUuc6lY1qkhHbYSQ2DDrzmK8ufSFk2Ip4rNoboOnhoUIY7NXWEgoOlhbo7zAQjyLyW4epk/h
fsCuKlKpsG0uWjfMJ7kwZeTQZ8yrYXc2QWUw9q/JaNhfsEvsv6OaItTYFj4CZTc2vr29aLbhTKjH
j3s4a0QA22Aelk2PxNjGxsAsypPJdON5gF11falDyed/LIP544BoJEu3VTn91NKc8465on+HrPk4
HI2GU3aJKj7hVsZyq0jlgvimJWmRXuIZlHa0/TQP+iiQoSP7Qn9c85S1pv3gCS7PTd43o5cVxyLu
IutR1G7yjZqcmMOKg/Pzw83Nrag5Gf36VldoGq21vm9+vj3/PfW04/AcYqdXOcRU3BzGm9hMDK1B
7CQhZrlCxF37fIV6B3DQz9IDpZDU2HN0ujcsX5PFdLR8MEbeB7I5dH4Y/KArunyNynHw8J6wwrbf
4ujU/HHafSRhaC1o/YPXc6V5fL7QyMT1ASt8QVW1aZXDdT+zZFR0YXjaZi77OMNJBIiIVq0X2gwn
3cWoxlRV0E6xon/SAudWBK8I7zDeas5RArD3XOlhtvxCJt5jsKh2J88G3676Dm1oCX+AHSQasQPo
oKgvbtU//NtP/+c/aH8+mjy8LQ1YE47i+it9hF+V+SpcJSz1kxAufefYrkV/Fyhj8RPjb9st87GE
vmHsp9lkstj2XNB7/jO682d/nPc7LDxOUTWhWFxm1RyU0Hx7fiIBId0uvKoDpw+qVCKDFXvPjlGq
9Pjpef4Qae3q37KA9jqgXkZy6rKu1TCc9xd7RiwMZ4zqSC1sMK4PGv3OMEj+ZB2yg2/BqDf8paf/
gBI89KuHbjdGIe1VtcLFF1kUp2S+97U9exjD4RlZkerwEEYEaga2aF/5L/qL4NS0ZvnR8RcKiRd+
rdO3r8BbtEsotVQhkUI8dI9Nowpl2AOS9q8VxkOQgfFlpD9YJf6V9EyeE3aw1MfYh4VJnMH20D6F
Xq9tcqm1de6XAxRqP2LCQb3LQ8ajiHt4/og3ul51YWrg7nQwbuu1sEcT0MAXxsFq1zZHoBoLaciK
YqDAlay6KPFK1u2i+MT/c1nHWD+YjXADQJdtvNfpvnjFIQsMG++7sy93rAFr8KTVeh24YPcOrDFe
oS09bqObYJdIrl8HLqnnwjXosuNp9Oavd/WTy7PCwLqgd/P82iQrmpeYXyQEdZb+4DgPYHr76Ref
/xrPkhGYvowCvPBGUgm8a9RnH2lHUnir6TV4V5Ov+vIMyqKbBU+zD67FPll+DFWtC4PqwW2jKabi
PW4W6bmQGpkSL84Yr60MSkldcTPW78VwPrMIRnFx91JgRmLAvxqjmWyKROu4DDCRNBKx4FWgPMSM
k2y9BkxxFeIdscuL8xvWCRbdxxovLdgGVkoh9/nqMbCwfdvb1GNLlJ87Wb6+vsPpSbQ/3DBrZqvR
xOJ+zpWNRYRLxNhIVr+stz7Wi6/uBvWLidyxBRmZGtU+1ZE7BhUt6uyKXUCvQDP7cTwPNaDNYEmq
5/RFU/WEiRc6x7uoN6baiN9V2ETVPT9ppDiYohqplovru0tsQG1BFtwr3rVlYqPOPc1hVXyOhQE8
qDupuSaFRsI92Zn1xlxrRVzzaEdJVAVyA0NCri5Om79p/ObtzWnEtbXYrnJUdZFLTdXy9btaL8il
oao//NJjVa+fh+9qNTTVhpWmenN2pZ/YM9UPzbOQqqrr2WB5L87BaryRKD0bruq3IdUz/a4nfDPV
aFz1bIh+Kkv1Ugvxga79Ouzd8+9w4o2C6bAb/ohdwzi8WLwvEjJLQr4BCStLQr0BCZUl4eyHRPua
lESKDDbd+sCwj3quZEAv6Jfi97I0wmq5B/HghmeM90mO1d/Zw3zYRj3ce16CjqFATWss5A4MrPgC
9lF8qplQPNLRPmRlWGXf6vqu3bo9bd98umUHCKnRdXvbOALj7GE06QQj/YNkvcEI/0uzL5+Qnybk
mzHTwUulad3+m5u9SudHHK9W3PSNweQ+wfw9gEUBW1oiwwzlCMyidoWxUjnPD67qjbtDvcGDIyt7
RI4y2bTVxPfFX95cuQQhnEbE2fWNeaa9CwsWZaNlBw/BtMY6YXbbmjWwdVrk4tLQPLulhb2WJk+7
ej9MwAFHBY5jutMl6wWLoDD89W2b4FvIHXLExrM2AdGcJbNLFfepLYejBa1M2G6PhvMFbmcYy18n
fThizxNzE4ppRyneZDKmlfMOxh6LrT1kzy5M+6OJte/+9TyNGRcxsfrvxV+uedHYmFBDey2idCqC
xs/kfwmTahR2kuEoF97Q06ubFvvRDwgU3p/CQF/0VRZzHg258mXVJgsccbnTKPa+iLpQ3DiR9Ygg
6GVEE499+rX+T+bx79IuDBVdArvH6MbrdnmYx6/diiiP08CA/tiS1mclCc964pyiFC/gZtmSqSWb
qMc9YrZUZG6UJdeaDBbfglkfeSrvLk8iRtVYYSRWJ2WHCETjcXIUGfEPge5WcaxQZ2jHV40hcaX2
0cueA2uJVZJfOeZXJbobbnZMUIp0WWe4KN5TWm4qZB9EpT3mETs7k+W4i2uRg4Fxb+t6HzfsoPX5
4oYYXXykrsK7SraiD+/p2HEs25ZPLPgaDEdaRg6kdN2n6G5Tl+SIpFFw21FPsScM8in5k16Qjsy9
JxwDFO/OabNe0wsDm04mo3RkJy0ztPKJ0KUznfXjsjc7E7FpaBFsdkp/7czMytpDQeYwFs8EkM+n
/e5wgCtreofSr1YZyuhUlc1OJg+Tq4tmix2Mpv/zniapK33h7/6W1AGBTGCtfnc5w7J4jgjSb5PZ
UyaGtQCcLt7ZOtPHiDRDGuGNSWxMsBburnSBhcQ7p/HtZXbZuirbLQvXna9IWLdlhyqythKmzoy0
5fh1vPs0sxFtZr10mBt0u7ufDxOkg9rxWyCj8kZFIHFTVm8GL8n+NwsGFtiPR/hFI/WLIqg68sWg
ygiCBqMYBkrRGwwrwnCEUoVAfNyV0iDN6Dw2uat30aix3RUw0LwYLQbRAUhFkXyOrFawJYLRAttI
HJmQwM6/DRfdx9Bo+a2pdeHusL70nDiwSvdrFoYOmrN6S+7uSHe4tBAz/UIfjTlUoJMOqWFolLUt
bJGu5UDIwhD7FfwsajnBz2KUFPwMyKsFP4u2LvhF2O5xhP6dzBBNucCFcQXY3TVWhECNeHhpXG9f
cHe80ps8B8Px7gfBERgzDXHmuCZTu/uPIrT5NCCoSvGGzNiw+oBfMMmKI1CHxVtwZQ+vpF+okNDF
ryT/oq+kX4gV0VvxK1l/0VeyjOgVQrC8/evRNGpZPZrGKK1HUyB70KNptHU9WmTg/n/52tvyVXwC
j/uLNhx9NOGQu0VIGaZDLoz0YmaS3e0XQMo4CD8pY9odpjOjFEATKipToE9qs05vUjc4zmFRbUw2
7z88k91lTi/6OMWokOTs7kcjgjJObX49WYQG89XV6c31+cWvu5uZAHKiROTGuZHtumaL0H4N/QqB
ztpUAN/XhawNn89OScwnkydsZc5O4ZxGCMLuYMLUGzdgCCBl7ZvWxYG2tg/ZH8v+7AcbPownhcaO
QJMc6gh0bJlbrOa2XI3dTdhJn50PdXqqkx/spnpWvSrAYeG4SqXxwztz7JomxT7gPe5sgv8UXc3Y
AwXHT1M40flwTPf/y/Hgt571n/u7n1cQpC+zkBjMiOP1Z1z6peX5qv8QEPS4N6etZrdQl3VGlRX8
RrBAFJJ3LO1jyUUBVSZcnWouvLJj7iLPqV8aG0daLOhMqB3ZeCMIYwXnx798fejPqgYKYeFFyAkR
l5C4GLCf9XH0ZD58r0X9ZwYXFVJWLRY41QkvR48ni+Hgx3464AsZv69OEzGd6ZvVRT3sQPLi+Z/k
+Wlx1hKsZbGWvbu7jsBUUjXZaKvwPB36Kc4AGFdbLgBsx6U//hT9LXzHyxAMZv0AXsKYROTKhZbU
x6rPE2StM7moksLiO1OUnmtlC1RHq0WGbIVFVZt3h7aUIzKFf26RAs4UzmL39AtkmtKHsEWOXx3F
lZOTauk2PKy+0x7M+/9ut07aVRCqtpu3d78XoeHInAIa+TSaZ1/KEPJykq9sJaSKE3LtMm9kFyfk
JQnPChByShDKKw2zlZBbnJCvCgucJnRyK0VhakLwMvwLqZ3cWmVIuuU4GZEsLo5C5tUr25kkfSeL
07VKSWdCt/iEEFZJOY1IFp8aZCm+jrvFJ4mweU4NqR1JeiVIutarSPrFSebmytpCkjeLT0kUgNtM
6BLVZe4vrz/Wafm8uP33nFlMMZs5zMWtwHdCkDFNJJgosofaheBJmuC7mGI5grbgeWUBY4KnEcF3
0Su+gpzr5FTrisk1kvd791py1stvd7Zx/NL02LsCHhrb8pyXSJ7vmaRy8op5xSR/XSf5rjxbbUvl
TPmY4IdVgu9eI6W23pCb+7864QGi2JoIRmgZowX5vX2XHXQPWb0XPJNNTX8sTEBnIW6Om2ZPj+P8
whCrPqvxtJTPKukQM/m/kEALHp4ojqOMlbEOyhBvjDR1jH/vDrwKPg/YYBQ8IAK5gA2+Dp0dJs1Q
c6Z/xC4ac2S05gH3wq8WgrpxKFtcKCKS4i1YJCIWhWn8+j1dFbhivvUHe2HWCpHI2iMikbW3fyLU
fT95E996KyIyIWK91Zv0eUykz/dHBJLZxTddkijsKf5YDmdPbZNGr41ULrF8/ZN/58dEzu6+iuDL
M4b68/qZIt9ipsisMtHDsfKRDIsR8PKjs0JM+iAn/X0M/J/9HmZU5Z8kZXJHKZNlpAzuxISUtR8p
g/cvA2pGp/cc0L4iGogCzm0AOhsAU8NdSoocXV47B9YThOtZZYG9fGAXwG5ZYD8f2Adw5w2ABwAu
yWPJeS5wF2PXKwtsZQdvh0kicYulxCSROIuMSKk9TRKp7AxomjE6+aErSjJG+ZuAZ38wrySgrzKA
O3C6U5bTaTG098Rpi4sMaJrTDqa5U5LTlu1lgHdgjFeSMZZjJaScfTHGlxnQNGOESdlZkjG+lQss
ZQVZQMsCq1xgpQjYLg1s5wI76LFTcimw0kvXKrAN4NI9dnOBXfTYLQ3s5QJ7kAqPlwX284ExeJ5T
Dlil15hVYFjIXknNp9KaYxW4C+D+/oH1zrjkxpiA86d0AKnolAbOn9J9Y/iWBd4ypXtAVr2S+lnx
7Nx76427o1YU6htu3FVar7h7WhBUeoa62bEYGLuq3EjYaelx03sSUVKv2j7PIO7EalWK1TpGKiLl
7YnVtH/NgGbWBbDaKalltwJDyzqqLLC7CRhjWA7QtbJ83WEILW6FXzulhtK3UwLu72coXZHem/kr
Gkx7uZRdTsoJWuVD21jaVMllnqDtXGgh9EIvRMlliMCdXHBbs8Qu3293A3Ti7O0mzt7SjkUi4m0h
0k28l93yzl4i4m97E9gK4ZtwrzwRl+cTGcRu63VHWTEiMkPkrf2wrqey8vV2fljXS49SsCeV8b/s
XY1v2ziy/1eIvgM2BWKbpER9+CHAJU6D5HbT5uK03YegCGRLjnWxLa8kJ+399W+GkizJn6JkL4q7
7V2ztSP9hjOcGX4NZ2xGS6Blu9aly6i3RYSp4UvQx570WMJkZYK7++Lm44M2om6TyY8lYwkykoPD
9IllmFoJdNUc82MRSrWalmJrtNzyCorL6h212WJZ1Tg7Hu0mpUvwOFf1ri7gGdoyDE62s3RgupjV
OjJNql/B7zGh7kpx4QH2ZzBb1hRWRV1Eg7WCslitJq94kla4gAdHapJQgh8vBgcDT6vG5A1XRi7E
q8pelAkW7v+pHuJrmiyPHb5/6BEMMH9zXrykVk9fYYMfrCKdjKxU4JY+anM5YRVwLLyVltJKz+38
AO1a5snYckZcoKmYDBUoMpxm7qK46cC4EUWOUbd7eFw7PW5GEe9n76G4dpQ8DBYTV5btG3i1qGr7
JLvpbLkRn/q6ZFerRiuh6SU0ju2X0TAZA/nJaLNmY3R0mVCTZuMxYQHNWGt2vlXTqNlC6KuEGjRb
iLKO2uvNXq7PGjVbbhHsJrRcrTUjZPE9hIprt0akTDyg2kkqX8k1ImRRa53Qqn9eXdY19iSWxfZR
XV/nNeLT3iTQFT7XFn1NKOqUbVDLEsUNK8CmktUpXlAqU61vw4BWHr2dDaaVLZgaCYvp9iqh+s0W
BgpBTraSezt5WVDK2gqRoikSwSxYb/7MDd668nJRy1O6UrSEuf1wu8SBTrfy/h9QxWtKS8y7+w9X
Hx561wXgdH5Ds+yRrcJXyvehdkmTDZtK001zSimsMDZKswnOmgTrg22Tksp8fJOUsBPdg+jcQOQ6
Jw6mc4eXmML1w2PqFYpJzyWm/8QSU8gXcGyJabnEtJ9TYuYBRoL/fN9lg2r9JaUKuqT/JaUKUhJ/
SamClIyfRUrovlnuyZmyJzfFvhmquz5Dha9UCdmc8m3SNJWkaXODH0CatqaxQ+icLQPYDqRzto7n
qpulZKlJSdYXbi4lkXDXWEpG0mmHkZKJdwM3S8lWk5JpH8IybSvhrrGUbAwhOYiUTGmoG6VkqM0Y
EMmgjaUEMAxT8BzSfyHmFus7rP8CQhxPcbfN600VpNTxNJWmjG/dKU2uzKS+xUoPLk0htlyZLm4C
PZ5/w+KCWCqGGeRE1lbBGsFv7/FrPJRTSMAGRA0zO9/LCpFMnNibDX+kib+DUXZ+WGwF5lgyqm8O
AB2Tbbm6XNyTKTJnbmZOSassPGxUYg5boc6cZe5nTj8wcyx3ZQrM6crMMbotdUhx1+Px4qBqyZhR
gzmhzhzbljeguEHx2MuZszYzV70wJxDVOFdnzlBnTp577mHOfLzMmbM3M1e91DUQ1S1dnTlTnTlB
t6QGKQ7oRZs7BHOGpsZc0gp15ozdPWceYyhgpqU2FJj1hgIsr7mHOf3wPWcvU8tVZk6vw5xt7vSW
9jHUkjOqKTFn11NLzvg+tRQHV0vOhbJaijrM8W15o4o7HAcexLlOldXSqMOcru2zObPM3AHGOS4j
KdSYM+swJ6wtufaK+wSHtjmTWqrMWXWYM7fl/Cku7w9tc5bi9CtphTJzGkVvuS+jdPXc7qZg4C6+
kZs7GZro7SgmltSIy2p7GaeEG5zpumptL6Aob4E+9O6IFyENPxoDDxXql9lAk9omE7wGUcNIiQ5g
NVqheFn9Ymkm1lg2JbEuuV4SipbZWYHbkyLrKZuyYbIRarQwaAwZC71ZUCd20zQ0rmkV8pSrIGoY
Ow6qNHxBW/BHxJ9iOS4/ksmjQmc6itrtNvFj+Ko6rqnJyltXoedJWISSweOy+Bg3hCZeyAh+q8C9
mZSEchauH3fzSlWIP/PiCabtioLhixeTk2yHRaF/UnSM4D7DOM2EzgmsaGzdsi0YeMGquux9t1aN
rAz+y1W/i1W7XsgfiyB2IuLif5+Mtmgr9FoKdonv7ii4BS4jtRIsyytrSapaSEppGj1PZ34eTxSB
kMEjMk1Tb/XFBDoJnO4PaFa/B2792ZthPm5yMoie32cxRst6wrCunwQOVq08mTr/CkLChUJp9Yyo
HySVPRYTwJ4FQa2UZhvBnFnsD/25E4NmHwzU9RwXK5weDHA4+qMYO3/ieiNnMalcsA8WQ5rJKQal
D/10YGRypt0lF5iM+dV3vSAdOFUwwbSOvUcn6QgMZnOiyH+ePS3zeD9NA9cjV/IOyG0fy3ZktfBU
oA0dhA0OPXibgaUpvYnXi6fOXF4aHTl+9cTn8nXTyGsWe+QOQwD7XojCeiwKqwtd5lFaNWcoQlsU
V11VoTUlaGGqTS5rbFxKOoYwjtTjlokzlDo9blkY7l67xy3L2tstKKwaPW4zXW21VmPLNadzlG5J
oOt0S/Jm7W5JXt/bLfqf1i1qm8X/5d0i/rRuUdvm/i/vFuNP6xa1Dfr/8m4x/4xuqXG08J/dLcc9
ufhLdvUPRo4rO11nuP9bQ3a6znVaX3a6rhtqC7MaRxOSjsAtxuPIzmT1FmbwptlIdratvH+uevKB
dATD1cRRZGcJPOquIzvLwLz6tWVnWcu4q6MdrEg6tn0sm7VZXb2zWSO9szV1vVM9t5F0xNH0zjYw
rKmW7Axkvr7sbK48VqgeCwEdQWWdv2PITlCZCaqG7ATlvME4KwyKaptUtnCe588OTB3zrB+vtM1o
1WK6ORzMPX0Hvra4oB1mCEGzneG/3UM/JJUnWdum5G9EJ7Lo36k8DYzGTojd5ylVEswJr2fdkC1p
knUjBx+EbpdAZy8mXrqrrQzhz+aLuEtunSHIOIjGALeIPDJYxHEwI950MUlqCkJrO8MJaFpHvpH8
rBoGnJP7HRh+9cN44UzwWCwKoOXRQhZpHS0mkx/Qnih2ZOlPoDh+HaqT+PDqzeLWcOzM4LeZlS1h
qwbJJngY3z3z4lEYzOKV/DkZFx6WOYRnFBPp5PhrGuJbVOfkZeA2VxLEX8JliQDrXbve22Bn8f0w
Db77eNcld/0OJz0QexhM8MThMc1P2L3r81+/YQ1IzOF4KvMtyiSJDcg487nnhBF637EDL5x//l26
gGVk9SkeZMZjPMTEc8xhEIbeMM4KmQ7wxOLNj8eJqNuzACSk0hwmMzSAXwi6aW/9enGZtKAJn5Yu
MGZm6mMda8loYtupSQyD6RQMGzMUgWXIx1SwDcE2qEIYD5+G0yBqqAmWLgOSMzSpuXoXP5O1xE3L
h4Ag/FvBYVi6jddc8KUuyMAJpxGWegY1CGYeCGsWj0/JD+1FCdGy1ttd2+IsQTER68eA+BdXD9Bz
MeidkhOzhIa1yDFOYLgY+MN63SE0nKPtDRSoGtCVQxb6MXaiF3DScbQ8rFXR9RRuRfBROvlK804M
5Vkx9C+njLcob6XYWpcb5PNDj+Tn85VjMXLiWXTCYgZW5qZP5UEKzFALUWAw0dFlnqF0jD5/IA+h
M4smMgkfzCsJuHXvR1Jid+P4XF2ATGh2XoCy3798IBdXBr34wKxTEKalk5OQ4aPntzdE/un1H0j6
h8EsE7STJJfCWXXJMSEEs4tp7+B9mApT9LMF1XAwhibA9IpPifOqbuRlEndhgFONAMcTeSsgL/Fs
gR8DfY5lEkfUw+qBDdsZYfsYUemh7YywozPC9zFSNfQMSZiCm+sktH0kqs/6uc4sse+iiXPQYEBJ
VFZxVzswcJRXfZKO+Ea88dB/Gg/dElaXfLgGdq+DKC7MnhSwOcP41y3YmCPxc/9C5qbMe+o0XYBC
n+EvZovpAHitrtlcNxju8mwh6nqDxXMyG6quZIDJWXYDIQlpkgEwkf9vD7tBkwqNWZhSu8HG/9jU
O0okcRjYwoacvBmnGEeTJj0dGNSAR6oTMGB0MrcSwI7hoE1g8sjOaaIJMDzR02wCwii59IYw+lEF
dYPOwejkRTTAv5h1uFRs/n8YGY6DCCZ6MjGl/KQylQR8galPxwt4vgXMZLzgFzKhqgqUgQGNJSie
rOaXc6fqaKam4a7155kPc+QpuV1MYr91BxYtP35o3Vx+SAWrgqljgKTvwhz2PIoWU3QSmnZ7/e9s
joImFM1hmiBn5nc3n3CB70X/SwIgFMKL6VIDzSI6+/69Mm3NEDYrdeTH1JxTrZfCBgV1v3gzNwjP
mGsM8COMNe5iGJ+BtlU3QKSGqcW2Uoti3FeJuuR2FJ5ppySjwk/TzZqP0o+cVfcjmmFQvA2Uk0wx
GzpFwGWcFXFvndli5AzjRYgRw8lWFW8boIAt1gKYljN1Yb2WGaoSJdwpzykVRdGt55dAibcWh14C
uqXBkGsbB0NefQTOiKoNhq7yYJjRWfeJbuPBcA+2ymCoYDemtotorcEww2w4GLoqSrebDRwMubYy
GAqVwRCD3/DMZQuBIw2GmrVMII1/+aEHQ8A3jXQw5M0GQ4Cy8BJaCar2YKjbGsw+iowfc/BAaqa5
g9rhBw8gaQpaJHmYwQNw5S3OHPdYgwdSMvUipS2Dh4od67ZpYn7vjwFxce8kTWyfdHf1bSg8TcJt
KBmgHy0G6VxH/eoDQpkCI5Un/sCJneVekQamnZ6BKDRLOh05HXtKrw10s11d3Cl9Nw+Dgfc0daKX
M6yq9y47bJk7oTMFGwrlJA2fwvENt1En3rMDQ9xN/5zg/FCam1J7UAnvUkBEyI++oJW03a7OHdbA
zKZgrMWSEWvsP4/T+WXBnhbySGPpS7FiguO6oRdFCsMM9Is8Bl/SO6xvNIXJMQdBMrtnTXwjQOkY
z12CMur6RktQC7O1j10HbO5B0zg1OD3vn5Lzh3NyedP/NRlyqgMafOlspSD3+FqLWmbZ1/LqQxoS
M+3txEquluaulq642qo+hbcZZQK3NZEiP7pe8jbXtOVShB9aLxFeNzDZdTLQNtBLCWWh/ZegrHp6
ydvAtmbSAt/HUyNJTNeM7cQOr0aGZnC5ceAOcG/8/O6G+NfnfZ3r5P9O0y96l53LL5et+0+3SiYI
4Dazqb3DE7Pqnpi3YSbGcQU5dmF8+XrZg7+cfji/77covf3y9YLWdBVa2xCaTU05gtHksJCNktKy
5imOWAYBDZdbT1W7EjF1qusSk6WYsmIyMyWmmWNWTeELmAbVcF9Z+sip8x1WTH8sPJhS4RpEXi38
1b+ojGYyXcd7PxLN4IJBp+sWicA+gjAiJ+CB8WLt7cV78tZhsBDRAZ30cOVzSnrX/TOYHDOtw4Xo
GFXXtEAV5lci8/PJMmo0WURjmA4t100qYBama0jQ4AfDHxx/VG+RRQ0Lq/xJvWosVYuaOhaWKxiU
bv1OMgOS/23dn9+CVbXuO/dfE1XFu9m69ZKKV4WYhdab7a71ClYakjwmR2vzqi4BQBnjuH8i5YGG
QbnNjIJi4E1cGAxQMxJFwGvXQlURgIzMqSPJNFUEBMPhI0GDH1XXLKKtw1QDd/Ru+p+IDRZGPnyP
vRnKDf2sPwyDKBjF5B/BxPdi8htu6JCqXAK6YDYm+tiIfn9/c/eE5x3n1fEsDCPGC9ejCFfdFmY6
q/62rSXT/iCY14t5Em3T5jItUfTHwonGI2AjXz1ord6XvlQQq0N1+P97cjf2JxN/Tn4LFs/jqks+
zWxjjTi8h7qAoc/ND7O5yHYjKiLZbQxU0fID4Lse6c895wVDCTYd91acEukUFxom1r7MgIM3wLxI
Yr5Orq7eb8avqDuAb1BDZhBN9xzX4B/vvt5fVbz0kcAZBt3S3N7tluZWVC7Ex41Xtrm5CI/NvVBo
rmYytuT+6+0NLvrncwBVUVgAsk3LkKWscf4bxPPJ4jnZwb0O4qS2HX7oBaGXqRks86sm1tdxN0yj
yHc0ng/HYFb9GGbYGE2wgr+Mwros3aZHYlWFrLcFTJMxi28yIWxNpUS6ZOFhvF5uitCqdlVF2wrq
B8MYHtLbTGvTlvwkbdtsMdpi1vvlzkPkuV3iTlsuOse/h547duL2MJhWbIBo24ZtYnnOEe4XICo5
wYEz48Zs2xUP33WrjUVj8fR1b5xNxRExgTRxU2gSyDwRMpoNJrX+K25S5A69Ip4tb0LjflC/91Ax
yUmSXaVSjpMw+hFNgmfokccg9J/9GcHx680JvbN32e/ekejtSyLcs3dam1lt4x353pr7LnzUTBs/
+LNRcPZuHMfzbqfz9vbWTl/Gjn2HMUfSD6+0w9rMsxBthqWuYDl+f9crdcvCnZMYA3LkdnwyJK2u
CdRR4+F+VHsrKkyGKcbx3CTxrrh0eZmNIuiTYTD/AUIdg4L23hMYumEa/+KHf58GM8dtR2+Dtuu9
VyBkco4heh+v+pdZxcPOqxN2Jv6gAxQ7r3roDfHM8gd6Z4wRhEdf9SQihSx/5/qhnJythqbvpKzj
pl1CWXYlErdpC6Z5AajZc4hrtDnGU664Wm5uRjW0thBCx4CBJD0vGUGz3lIBbouY24lmWrjgi6fz
QZrv9zIM5nOEA+u+uXq6evp89Qnm6TNo6ixYfnn99anX/3xLRp6DG8Tt7RThHxHIDf1XL0u3I78g
ayvTaq+BccwnXryL5gqXFkxOZNGtRTT3ZoAoXTnJQq/5Sgo0XujTi99+hQVG7+H+t0fNhJlClwwm
L7EzH8Yh4L/iIEBV3k4uOySrB2hf6LyliYdOHD94/+0wUNGP2bAR1usUnVkG9zp1Xxo2bepi7p8U
Dz42gvtjGLwRCXiC/1TDkmXNZr/EYDmImWz6pKefuEf+S9K/9BcV0M/y0gUeCUszL+hIGUUr6Ghn
EYWdCMabDqx/Zo+yEF0XfN79p4/vyc1HMLoTGCxGPuCOXHJGVrP/7MbiOVb/4fz+4fMdOQH2XsCX
1sVJ2nS/mM3QFmEOIuPJ/xUMymF7ogvD6BIRRrNn7LSOFw878G0nGob+PAa3649amcsJZvKY9/cP
Hy8+95/uzh+uzwbO8AVMFR/rsA6tQWCAMbRdWbx5I/DABWDBTKatgJuKrf8a+nFSqLjU5E46EW55
YQh61VuW05OKl7yc6Z8Xj+nW93EgWkQkgQEVyzxju2G797ZoBd+qgI/Hglm7hxPPmS1gtr5R/C9S
/selMRrUJJHqzlrP5jrTmeHVtQ5Iq4MrfbarY6pQLJnDaKRoDwcVW3rd6Xiim49/RP7QmbRSXTO7
jcVXgeqKOQGXM3lMcdCe2+3IeBOJ7nJkfKMjU239z+LIVNt9DEeWCj30pjD9VxxADiF33lDu/Ehy
r+58G4mnOpna/vDnGgrruQZln97IA23yrvw4w6HSGH80pv7cgYr/mQPVnilGI5HucZrHG6x+Vqf5
87iaRuJXcsorGmR1dbZxf0bjtM0xQIItYzLaVhJqM4FlvkqkjbZCkG8lqBmaJvQSQeVYmz0EhLyf
VCCwJ6iF6gOtGNSiMTpUI6fvIrctrGU1EHW10/bQNEo0l5GoSPjTPEbfSW7xLndlVCGElYa3rl2g
Rp3IY1vSE/ix7wKL1fENzcYL4ekJ3VpDN5/Qicr4BsOSMin+KTQudN7SMKvrm0vcMGQspfS4Rvwb
BqwA561iCCyKVom8ZSuIDx6ERirh20n3wGtd8srbRjdjDimuXzQSWmm/pgBoMLOtc4uZWq5FZs0o
O70yRYEp+mmJoqrt7yPAmc1KBPbavkWLtu9QaqiRE7vIlWyfbbd9TY2mUaKZR6F/BxWD12QLtNLu
eAVQqwRaDkF/CKKxP3DUAO0SYDnSnFOGfzTdsNkq85tPExDWhOcxT/RNMRM/MnsLXoP0YZKAu9xp
lpXSEUc13GgY+ZR0kxj0PLENbk6vU0nC3KvT0EHEXIqkFSUY3ZJWYhzdqi0pwr05ycwMG5xC48a4
F8cTjwy8EXqJaOjIbeQ6lCo7tqxJykTWxJxGSxWIrnTrFpdpcN42DcMUbLPIUQzL86zKiLZhyVgC
VBQC44T8H7mUB5Stc5mjCOOIyMOn/vXNxTlZM0m8YsHI3T+7hJLzj/2bLjEqEtfajHOOZ2mXWZoo
9xfoAM/FjCSuIzu+VbyaMFhET1hcgkxhchu4kQohge4gcnMeHyPX+UbA3WmCCwyYE4y3sLYDGTuh
K8+sliF0WE2RU4EhdAo0dR1j3NZp4nLDQyeHsc14Cy34f/au/DmNZEnPn1Ix+36QvQLV2QcbjngI
JFtrI/GExjP7FBOKFjSIJ6AZDh/7129mVV9IILqa1uzshgnbsoD+vqqsqqysIzM3MoGWhe3gsrkH
SwvoE0JAu+g/XgXIqdOuHg/m9h+MTV0NjLuwHj1UwPKjKf6XmgJoggb+w/AfXvx5Bebv1lHVjIP+
mHkHj1fzoPBnx0TruzrJD17/urw57yX6l9dZnfvk9nwSoOlxffIr6Vy1f/l09nu9MK6HLx7jfokm
62mYuwnJMiCFxrLYeoeFYaQrqSTFW91FgFhDbF2pMuo7eG0lWZ4kJoU2tMbLeJvmeItFakC3l45R
ATaw0IknYs+WellPE1GYUQmmcr40dWtfk/0EwkFXI5yiWElbZj+H9MSOiTW1ZWxksgWulC1TVDg5
6e9bINwPgg2PF6a8CunsFwglOPObAxyWta3rXw+B21wavDdOkYcAPl0aUIdKJqjPTarxTWgpdkB7
deU4dJeJvd3e24voChe9J7S9x3bbe7EQanEEkBZekDUvvEG7Ye9R0mr1nhRA7iiAX2ceLEyknjTY
5qThetxXVL40+UtK/Y2ZvwCbdml6zvbizF8ElqltsPmZn6Yz/9MW34PsbkO2mfn3svjwg/5pjeBj
0r/qG2En7MGNsBO54kbQLJn5ZfWo420t4IblpU9P9HUybYP99OP1l39NQQODml++JgfOQY6k+ie8
4p/S/GTM5Ur9BD+YKx2YL+Bz3NniPxH6moVKXmu89kjIT4soWr30vWAw/TOK82e/Nm+Eb1EB4+nj
JBoR4waAsYpGZBmtF2ARvCMn80XUP3mcLkeJ21VRf11aN53gyVZkfwQ6bR5HryD9+RrM1YoRreFM
9JBkybUlishRO7wfB9lH4g05+hpMBuO/D/QH9WgxgrdG/X6KImHhJmIHPZj9juZgCYZ64+lNCoff
4TUu37zBJU2v0yU9WBT8J3zCKDzaEH4SURVwiieLTqrViqZTXIHhWXpDx1d+p78OIl/MgmmofwMQ
AmuplX4jRVzP0DNE+xguoiTE+LvV6jtFB9k7vEXxjqviKZ6TIp1eXPVq0KUwM+WAJDcYCLrDToN5
wxoPI6GbmCz5F6mlb3HPM28drbXbTvEkpQkF1nc+nN1ppyi86swcBQt/axz0arozYWw11ub+cjGM
ducC+qBLoDPB6ndlPxQJCYPFBFOiLtHMvuX6/ZojmLYRb85+uyFtdKI/7fUOA2fk1kEHclrjoPeH
w6GJWp+0/WHgHEoOk4pG5/eeRu++v2mefjqzBv4nRqnunl+SRTCDWbJEH4RmaZL8i2KoN6KdD337
MaLxBE/AdIZgxIvzaZfAu4wWUxhlJMU4CK8TG4D/jYIzHgUoPtyECMFSJHjZyhpUN+4dPoqD4xYz
SvdX+P2sZUpUHH5rPGmUkqPXOKFe99pdVC3nVCqKEZ05RnTmpPmp2fvYtNctBvU3EydawQLK1aiq
peNEG1R8okk65AJbDPu8n0aPhgeYRdrlTdZz+KFZPWaiU59jXeQrs7bTujIFrO75aTsnwRxr0mgX
lzefcPpTYDC6B9S1ZyJxn3tawrJoNISnSM3uRctIjTON5HIov3hlqfUSqXkwnwEro9z0kM5Fq/uL
xu9eX7USqZWMJP6UtdM6f29Yha/rKvb0S8OqX37ptmo2z+O6irZmbYs869VZR3+jYtYP3bOYVTb1
aBDe3jFYT1V06dHQaV7HrGe6rqd0O2vSrno0JL+VZf2kO/FR0J+P78aDW/oNT0cmwXzcj39FfWwS
9VRHwTcp+CtQiE0K+QoUcpPCqYbi7hKURI4GzRl9vhLi7Usw31fwJvu9LMfFlalH2rjxkQwyhf34
q6Pl+O4eVie3tASPYYBHGySWDoHunCyFaHbslDEe6xC5YL8VDaXyrFaXN3e969bd1edrcoRBYqk+
zceISpSMJtF9MNG/cDIYTvBvafHtJvLzRL5pMx3x154rie6rmwoWtPoXc7PXGsv4kWPpyVGn2b55
o40zXF9unqOhhz9Yhvh/e9mYpLRIhNEtoHX1lsEycyWHpaxpalx9jWB1R+6HZjHWEEPF8DN7MXXP
rmHGa+Tp8R4VJ7i1jLu96LGOmwBkEKwCa/jT9XiyAj2Ltu1kvFxhniKzQogWg3BxTKaRSQFH9KYD
0kczmAduohUY2HPcZoOlD8ZUszcwPuq3dUKhv9iqfWO7BcT/b/aV6160MZdRHOcCtOZqMUZZ6dXN
kRYuCI4fE8FdxzOtad87dCgO3Floda565DssKvRZmX1xf9MZl0wMqgaUyed1pRyCAebnSc4Qm9W3
pGZDRrcIHmdPYLSQz++b/048+o0XjQCXQSVZ326xdX+3zKu3BebhS7/GyuO0sUG/x1G8trUzHkyg
qRy3NJhYyVLUuqll3CdhrVjbTWgCpiR87jFRXILxXJauF4dQgamO3Hw6TQTVINZIpAkaCg+GzcrU
kWQajgJdLHusWGfoBXKDDOGl97v4wEHbn9SytxzzVonixlO3CYbHXXI/LhyLN4OBOaIG1m4S4ySJ
SAP6bY2xO+7Xw2G4SO4ygIyPer9eXIGg7VuqE2eKUhJe3uOJ4wil+CMJvgTjie4jR5y77mP8PAyB
QXiMh2DKkY84j4WLLxjqHNZY9FHPIscm6xRu4BUvjgKpowNCCz69X5iZahBOgu/xHRkTvX85D/vj
IeYT0zN+WK9Dx/WculTkNBpFnYtujxxN5v96B+PH5T4rGgbJFIC5Cg2L/nqBM9Y5Blv+ilEW7ANG
azguXIA707vl0HnTQEgw0eM0VVwfIhZefW6lGVXJp16nbLEEZljtQD9avaAObKY9wJR4Rf6FU4ai
sZ4MmlJPL2Q/O7MI+v3ixyAA6eBlgRcgn1+93g+J6Ry1cfUJFprJSbTgH4/xjXbuDRtUfRfYoPIE
AhrDDsNhCYZIMBwmpRWIj1mFNEg3OXbI0n9dtBukuG5ENC9FS0F0BDlbJJ9KGAlomwcTfQ8adz2h
wy6/jlf9h3gR8EtXq6nisD73nDR0ni7XIo4Fao6kBC8aHxPDBnKBt5H2lNEsLywK6YDCRo3yzLq0
KdoOiKJhrTOIajv+Jmq5jr+JUbLjb4Ac3PE30Z53fBuxexRv+p7qGy4rTBgqEba4xkoQlvNgRmit
+DYCPojhQKtu8Txq2RbPY5Ru8RxIBS2eR3ve4jZi/zHQKhtoNirSDJNZuLrD3QIYLpjImHEuid2i
I0HaG1ezuKWFkDyNGIt7a9oZZ94f2yfY1WgMQyPrBE368GJzu4sCBTr+hMmu1DIcTTHUnt7QC3Fj
rwY9p/hiHK/SovGpCc3CZpNR14bpNY1mDvR12OL4zHF4ug+JdyfI3VXv4khb4G/IH2sM/TgezSIr
KQEo3gBOTiAuSM+kkTG3udGRkZyG5Hys08effidX9bN6p7hxD/iulHn8+G41uYTuVwW8R51t8J+T
cLoVMDh+nuFU5wY2xf+n4+E20yKchkXDbmtIn29CYmMmEm9O8WY0TGOdcBQA9GywBJOmb1VknTT1
CX47WOF9Ve+EqxP0JrXAc6lK+0jX+MstoVwaG7eNSXCPUTTA7ptgZ6zh4cXfv4zCRd1A4Y0oGzqG
65l4v31IftZnIdFy/E539Z8JLlsxEfpqhZuwsQPfLFqNh9+rKYAPCjEtAHprzhc6MZHthhgieSJB
ytIJ9yjpMdITpKeKL+EBTIq02xgFEx/moEoZpwkI4/MCG2CFmxN/nqZkvuNtEAaLMMCdg5Qi2XnB
HXd9dDGNVg/hwuTlTo8XijNyzxVqQzd3Oq2ry/OL9xu0NRIOzas4tJAOS1Mv4+nHNcaajGPe3sIb
mBJbH3TYHHE40qXZKNjMMAnD4JHcfrr82ATki+t/LIkAe1kRh7h4V/AtYzCjAwVhNt2rCOFpnvBt
yliOUDHqu3sIWwnh26SKB9C5DttD187q9/ZQOrG/dmdb2y/PR95amIkKA4nvoTyvmFLq7A8vUr5/
Tvm2vFiVkGIP4YenhG8P6aVK6ypzK1jH78fzuC7u3fZiV/svmFWAHPXfkOYgmIK5AR9aE8xnc6jQ
rGvUHe5+WkM8NZxn81KGs/IVBh3ZKFAjdlMEAdpuJgKeI9LpVNduo4jrWblC6qSh8Dleo22kmz5L
E2hrMolg5ooDW1ij2kRuGNpJwgr+YX1fGXjs1pcV3Bo5N3nqVtSHM9f/sLc3XJdlhsz1TYugtfs1
eAyNB2/PwpT2BcXUCXHuS5xjGWaqwAS4+hhM3zEZaLfImvmvD5M7HgqA/aiPdY2dYcPIMCH2S4yJ
OQGMiTlxGCNHc3RPHf2sjr44nFF7RL/MyDNGoevYT+PF3YelWMU+yQ7DkKasIT1cshLPAXKMHBlN
/JSYkvvIxv1DiXBFliNynhHJARLJATuMSKnNlvOfE2n5SSUOI9KbES8TKQ+J3ANFpzcoXiRizNPJ
9NihreTq1AsvUSktPHVonTzMdfaU6KnW6mdaq5rx5XlsH2s/G1/9CjSXv02gT+pJvbSe1DuUUVK2
pVtuMA5T7TxMtPOhkpXU25yFgi2DQepR5x5UPTD0RDwTn8ZROuOlJWjLwjmoMySC1yu+jmeD6GtD
L4NrodXiN4XpnHVSHBCsl8n4nlouqFPM7vXZ+dlN60MOOJ5ZaXKXsJZ7y3rl/pI0Wf9QaQ7iGxEW
5udWaR6C80yC5cF2ScnGWNsmJWzEQSV97l5lfU5V1ueql5jFRtlr9isUk8wkJv/CErM4Q3ptiYlM
YuKvKTG3gpng/7/u8qFr/ZBSgb4kf0ipgJTUDykVkJLzV5ESqm+WaXJmrcldtc9CHTy3UOEtWyKf
U75Lmq6VNH3u8Aqk6QsMPHd4n4OloVNZn/Ml3m/cLiXPTko6xfLhUlKmdgdLyTGNVo2UXDyq2S4l
305Krl/FyPQ9U7uDpeRztyIpuXqgbpWSY2cxIJJDD5YSwDC8LFKl/kLMHaOvWv0FRNxlu+161wYp
VjyHSlP47h5pcutKyh2jtHJpKrXjBDu/CXTb/B2jW6BHLXPIkXZBxUBOX9/g23hiY3EpD0hdtuOE
N79Xkid1t5Natbbn7ieVFZMyKnZcgMiv3m9PKxUvY7uuCeQXwLetjNTbTlo8jAmQ6pOWPaTubTsj
9beTFo9DhbdLqPcSqVGw+TatgtR5uabuawwZjKKyh1RWX1PffbH3+q8hXs74PvGqysXLuUf3kDqV
ayQuxb42dTdJKxinXGWXc3eQetW3qbvrSk/eXKy4TQXF3rvvNnlxlxJXYVKG38lFV99PCF/wRjZO
5olzsHNMYKXEpLR1DgZGgcltblpdEi6RY7zESKkFHKB94KS+yxQvQeo4Mek9Jmnb7/1c3tsaY+ej
pQ1kDfIhJVqm90Whtkf5qsfV1AXThbDjwiNzrNginEVlbjK5juBCFPBRsEEU6AADXan/iBdhxsM4
U/x4qe9sLYLpcFmv18kY4w0Xx3WF9g8+X4ShhkWoAZnG3svcUUI9kiF8alF71ziuBuvBeNXI/GkR
fxauJnhbbhn1H8MVOUosaYv2idHxGtc7vAlieI6Y4L70fA/UPoyqBnvTKOXJm8B/Pu9h+PDlI/lj
Ha2CJRngzzunruoWrRaDtfHZF9yCQWXEowSj1OhgFLYjJGaaLkfT2Tg76V2CkFcRjAdhX+pTzFRJ
JsF3KJaOujwysdPJ0f1y9Ca50JWG16lLUMIBhr04mgb/ihaEK4tIYwnpOCJLjPO8ngD2LIpK3STc
ChbMVuP+eB6soGdXBjoIg4FOEloVYH/4R/4C3dEgHAbrSWGPfzAphavQlzdYLsej2V16O/9uisHD
z/Vlyk4P3d4Sr3cbaEdCgUEpRl9ng40MdvufRFf7aTAnGKRoGIyLuzPg456jnFeqk+fiPFamTp6H
l7hK18ln8rXqZKDL1Mk8+aNOP+r0o04/6vR/rE5SMly2lqiTlFzS8nWSUuEK7HXq5LJycy486R5S
J7BK5SvVyVMYuKRMnTwHvXBK18nz/dfqez4r204+O6idfPVq7eQ76C9Rqk4O5qUsWydFtePva9RJ
UYa+aiXqpCjnB+g95VA3zfIQjOYjDFmeed58oXVGi8axyOBMRq4G8biiJ8xRiiYLs79dx7F2GvB1
n5K/EUm0F/Cx3iRbPgQ60llo5VqcEd8vBg0C7QGrlnjdZw0R5xfvBH0QQwTL4mlksqGuVrCgzDLh
bU03XvRANKP7DdbDX8aL1TqYpBEHl2sdC2G4nky+Q3mWq0C76wPjw5e+PcXZlxDjfz0EM/g08XxK
YYseFxo8POmehavhIpqtnriZJbUI0TUZvmPpb5bhdy+7DdLtnXAMCrlaRBNcgt7Cu1RQ0ej2+Mff
0U2ZfnPoMfwjdccvupOwjQazVwSLJe5JPATwQPOX33SnTI9Uj3Fna/WAu1q4sdWPFpjBLfG1xwBv
5Ot49UDGHuasnEXz2dymOEy7P8CYiRoGgnw8bZsSHFJPTyqMBjEdY1ATXVHTleMegMFU44yO0BH0
12ywPVTCi1X/rj+NlvqWv2zg7+SZv136JejA8H+LDuxJHy+g4EMNKGSwmGKyYmwnDDsLpV89HJPv
4tECUVEfhsRlRMan5zcgCsyFZjUIPCUw0gvuxPbX9xie0HaTxYDg9Lh3K7bokUwGmZP7Klg+wiBf
LdPtMJvOE8M9aeBlHIo5du7o6904aA9OGa9RXouxRZKcJ9sBLbzbnZEn+7/rGXTbQfytbBsYA0/a
bAIzmMuk9LxUxzdvyM0imC1Bo2MON1BZHJ74bsIqbNXvxQXIFCwpUi/kOEmBQ0/PTEIJT+pg9vBK
kiCQVi8J1V82SQGyKsX8vHcxPO82KEXFlesaAZ5SRBMQ7p3RBsUH5SZFFn/ptquvCmVhPTydo2+F
W+s6QZbF1vHuirB9FbFpod0VYa9eEb6vIkUP95DCVdx9TiH2URQ37DisYdW+KyhBpcegmtTHBWya
MjnP1CBnH6AYH6LlKmcmWGBzhifYO7BncZpddM3PJHgc2/4gS/xgpjPOWihVLh2GC8UdpIPwfj0y
037xxgdMjrpyB6Y2GZxj3M5Hrz+80OVQhxYOdgwEDqhwdycBSonXaZIB79g0C6atPU5sfkZJO+xj
cM2i3lGaVao4zS/8tU5zXQBfYRiGhzV8vwaVSeqCb+jgDjZQDp6rbkBxs6pJDYziaK4QGGHrl9kY
ExDEGYG7MEXpX89qF+2zWLA2mBLPaccDMMzSpKpCYMj2eCLH/mwylqM92L24wlVUuPwPEgHRAh6M
DVzso8t3374V5haO0unTsobckzGbDZz7jYzZlBYfDciGvqc72TYSZovdCbOLD2rhOFT5eco0X/ZB
GgpwGWd53M3E2WbJviUhYzJQrZhw5ytj2syonR/wFqC+I1684AaAg40Zg4utM0bhLCgZ6XNdNTh4
xtiDbTNjWPRnV7xEWmrG2IOp88KIJzOGspkx8AgSNzR3ELzSjCG8NOIL/uVVzxiA7zrxjMEPmzEA
ysOLghtQpWcM6QuYovMVf00Ni2yu+wJb9RoWKF1F85TVaFjA1TdTM9zX0rDI5Mo80w4NO7DQsNJ3
XYz2cxmRAa7C40hUprmLb2jg1jNuaOjLNCZCPhoE9teUAEorCm1n3MXXchrJJhluPP08X0T3mMRy
+fiOfhPDn5Ot2nmA+RcwpiRaH/gtnSRpMiGTcBT0v5OLXpOg4aOHSOHyOFyqxBpgNWaUtE5EZUyd
XK81iSdSjYVBzZK8XMXHhqscfZKT8lWrgVzlcrwdbwxNdogGAiiJd1c2oJyyGshT1MMISQ+DAHr2
jRCcOpw2e8cE0+W2L3ofjWIvDujwVKVpQe7RaB713E2NxotPHEjm+rvJNhQazRQafaLQio5cXtcJ
Pj3DyF+9X/I6FyK1innV/RLhpYOhdMx0dkC/1FAeqvoNKK9cv+R1qLZwaa7er9eNNJkUzm6y6rsR
plLTa9jBPe5lNjFQ4odmT3JJ/us4fqPVPml/bteurzpWQ5DXwULhuPx4GIAO/7Xdgr+cnjWvezVK
O59/PaUlB7fAwJw+dfUsQc35BhvqeFVD9xhnBYdg+j3ctygqfMSUFANrAyaLMV2N6WpMN8MsGm4E
MB0qcOdOa7Vp8A3M+j/WIZgaJtuTYvzj+LQwmsukdL0YzeGKQTNJjyyhR0eLJTnCfOAuJ53TN+Tr
CQMDXQI6aeHt3GPS+tB7B0YjEydcqROn6IIIWMHuUIlmNld9/4e9J2tu3GZynv0rsM5D7MSkAN7U
rlORZXnG+/layzOT1FRKRfGwuNYVkfKR2t+8L/sHthvgTUqWPEeOMpOaGRF9ACDQ6G400MF4GY0w
F6Fwb248nTgxSwcNW1CDPxj+oeAfm9fIooal0mRcfXavWtTUDKM0BTTrF5IOef63dN05h3kgXbeu
P4qhiucLNOsu6d5tmFk431LXTLcwrxYk39hW5Y0zHAJRxhQ0vnl/4MSgis2MwsDAaHIQ3zgyxEDA
owP6tgMB2PDzZpzN5w4EJIYCX1CDPzbV5XVZszCqCcPwg0ik2zE3nuY66tE6niLGbI0v2+fXZdNW
+CW90e9LJxoFIJDT3TFVVqXuhz7vcqtFNfh/n1yNwvE4nJMzzMWyqXGhmsAGvitqFSD+vXwDTtFT
u3dDSraMu9Vqvml11SX9ue/cYfB40xbVhmqBRlFdNw0tJzx7AJpHIs5h7+Rkv5n+hmNOwxQQBr8/
IHEB1ch/uvp4ffLbNuQMg66obvd8RXU3HFxIH/1grLm6SB6re7RFdVWTsaz1H8/xcncMNFhsNWA1
vEzZMnBDao464Cyej5e3wqH2bhaLK5jxB09/cp+meaCbXqulod9FpdjuaDR3RzCt+jFombgDWqGf
hWIcl85YILNNO1mTdVAV8Q4PoRRJE94jbbL0MUYln4pQK3nTgbaSaDhzYwDSZKbKVOK/+Nw2JUYl
Zu1nNm6EySq9ieSh8/Hnhe+NnFh2Z5MNK6DLtgG2OFQgQCsXqZI9XIrS1pjyprkJNQsUBVCQ2Aax
ARuuMYKkie6H8aydZya8gq+IpjXPC4vV3NCu1mx+8gE9D/3uzYZH38SZu41Ovi2ip2g8u4Uv8mm2
CG/DaZYQ83A3Ldsl0UOS0uRwV5WZJRu75FGahx78VE0bf2AmjsPdURzP263Ww8ODnCDjh93FOAku
hyv1sJrbrOsyw8tkwSS9vuqWPsvSm5MYgwi4F1YsSVXny/ZUY/d5qvZKqqBeUow9OBUxXmhB3k2D
CL6JO5s/QaeOYIB29wmzbVCM78LFz5PZ1PHk6GEoe/7+FoxMRcEwoIuT/nF6GXbr3lm0xuGwBRxb
99rCd3EL6QmlcwxaB4Dea2IXnWRlXrjg6k41YnItZw1dTYJzllfbphIoTjMYZrcLjF+cY1BVRdQq
ZjNVQ5V1XdfweockXUUA1XpIOnBVlM8aahYs2/zC1yWY9VMY0FzIkTQQTykdfbbaGmukBIaBrKCh
xzLbUraEy2A8e9jKY6BWGCorGaqGqupaieHWPoNnGOh8/73A4BnjnGpDtWicq4y627HT1rFbZZ5X
3dZ0O55GiWfmt0bGl/OY50E7x6C8janCELUSZ/iGt+aHHjRxc/qGauO1KomWVatos5alb0zfYCCa
1IT+AVRu4Twk7qJ3p8fknsmMJZw+1Zj/hmY8tFwqOsyxa7dib9nb5TSASm5F3xafB9BAoVFko502
DjnW9+51tQ1rYxNBg5mypljMVPNRZL7QW6htzFHHw/e0xHHbuf8cA4XZrMTg2blv0eLcdyg1tmOn
r2NXmvts9dxXt+NplHjme1aPPE/smNdALW34bEDUKhEtb1jdzKJROHS2I2iXCJb3pTAxGjyqZtis
2vjmdQ/JmgBPq1mdsbHnIDXAvJgt8IqAJDpclremG7lRSElb7FjlAfm4dVTnUkvP8gwPDbpY2U4+
SJFgtjWTWm0TV0yBaaV3VkgeQ1HABhH5pLF3CAhH/h+o+6hZSR1+oAAdIOTmsv/u9KhDauMQdyEZ
ufovMOhI56IP9qqxIXPQwBVFQVUnMQ2/j7zvobt8D8O1PZHgXSruBA6X0YCnvJn48WjmRdsw0nEO
gDKbtfFT5Dm/EUzbpis6+s50pkh4VQEZgRmLlkPuTcOLzRSqozdtC56axlMF1Hh+XITABWY2bkxg
tOWsdIHZS8n+bZsCdJ02/sHwD2VzfB10jsav2oljdFZ6YrJ7YVSM9dfh/xXSzTb5nSnoN7m4Oemn
s1WRmazY5NPJ2EF5f936SM4vj9+f9X6TN6Zr4aMkdO9n4+XEL7gQWU5IRw1FbTT+GJ4T0XSN4gbD
JoRYW200Dxi1DbT3Up0wleN8dQsjWLin8D0PGtQAQbS5doyqoHiolOZ7sPJLtynVjTnqKtMLG7Hy
1huVzzNQDZ7JB0Qke+ECsimPQiOeU26GnlPadWS69QXZba/cvIBn0bBRQCXvXn/8HHJlteatCCX5
HIJVtYYaVGMqtRVx0WWZtKauIG3JuqmauHvFF1m2epFNqiwl4btddKeKB/2tpUWWkm63X6mAtqIC
tswsUIE0LilZWVKalmLrVFu3YmiU2qXlYgNuNrWbuK1dLp4la8Nf9Js1wsaLt75GIzjZfM3bCtWw
mmpUXu4W/mR2zy9l4gvfm9fnSz+PE9mb+NGtHD/GX4sHChhD094kF91W/mbwn/mGMZOZmqErqv6G
MtDq2BtCv1aFis8SXaeEvFnMZms74Lnyv+mz90vvYl+cwc4UL9CgyN6xPwwd/ktmkrJP9h6csRf+
7PHXmD8bXt26boamyaCxZWj8F6Ltk74Tk/9cToliEWq3VQV3A/BgJO4x7wj23dlkghoTXtnVJt5s
QjGJ56Gh0fME4kPo+TOeW3wx4bpKOykgH952UHDF/iPfJvCJRR8V/QCUjGlMrEdmZIBHvdbxcTc1
uECZm039fye949NjsdMQgHoch5jGHVNaow89SnE5EM9sjjnBFj5eEIfZqIe+6yx5snGCpJMCZ5ww
yQO2BJ1j0EcbGyHuTsDgl2uC0fIOLvxRtbR3fFzERsVm6RYh4TNKvqVQggEfE2ee0aeVB2zRwi8b
s7yRvSXfF9tvwBEAJRyHk9lLU5Y1Yfk1TkLXWIvFqvUbBpqr0zX1ywCKODoTnHhi0osP/QasBKSM
ZedYYLU7jWh2DY2nN1vTrAykjGWvb1YCUMQxqP0cpwSkhMW05zojASlhqe6zvARICcsMnuUlQIpY
Ij3cyr5Ikx8WcOCVRtfXL03sl2OxtGg1Vg6SYWnqivr1RaA4TLY2YYZq6OdHZI8Zpo6bw3dH+/ms
JCMfZiNY1hxC01UlLz6eTZxQQJT344/PO+Qh9OIRUfHO1Did5SKe4nQKcib0yEmn289lBvm//02g
8uO831FitBlo21en3UxcK6wOp2wIp20IZ6yDO73E95/ob23izEN3AE2hB/kipOQWe56G8oCfkqKS
oiZEenhLCk9AjDxQ/LdBXII1K5NkM5aR09YlL067T7zPrnYE0+j8inQXvhfGpJ9d+Ljn8jfZR0oE
OVTMVmSD6QSPDs7TtsoJWPLXuw8wIj6c/5Ld4pIsc1fvaZufAhvvXe/zgJW9m/N9EuqSAhIMy8nP
GIRF3+K5xNifz7Gq1Ezwj0AFwRcZW8JaCvHDObGwf8p1AGLsyzJTWtoaZsqXZaa2jDXM1M9hdjOL
YYWeBXjxTsovImBsh/cOvwkjGVsXnaOz04u3MFIlPrwwhXwqLaSfknGEHqFO91/Jgp/OgfSwKqoT
C36CNBjPHvDmFJABtm2R/w6DIPQjuRkB9BkGGhSzcJC9u+rdpN20wBi8GG8A0bCZaXXAzJpBU4L8
Ppo/EocOvwxJFp1V6F2cKWOiKeKsq0H4dmYaVwPcUcvJoyITsXN+DF1xfv4+D6FJSn744Qdydtk5
xs46vjzvnF6ABgUv085CAZhZgIYmgSw7IONoeIA3sMydWFVSSJCFtBlyjtIA0y8nwvknvBVGBTsy
1SGv3v3aP+12zjCTx+X1r6Rzfd25eNs7713ctEvkMRe8K4OcyOS7kmQPlX7KJH62TjANz4kA+1uf
X48z9AUBHCmpcPhwen3zfj3nM3EFb9q0NNGsRZWEc/6m1Cr+QWWycCZoABcRDYyXLiIqlA39bK6Q
q9FTJJ2DLc0VQVIEcyuITC9MMox+4zdgBTPsI1IFqyBqjpZxRG+hCINqVxC9KqKpFDji7McIFveu
ytGstpGZagHx5vKmc9Ym6ZN3Dq32qiIyW2b6/MUNfqjj4+tev1//HPnKTPmdzRPnMZwsJzDpPhRm
3am4lHsMo5s+Mtu3fVyheCSOiMCvfqxUbXAXyyE/34XXuwj1Qf7rPh6YSamcwpkc87ii4TIAeynK
k+6kjYtB3JzNbvkx5jbpLRZcuIL98uAspuiHTQDf8pj3HPJiFo+wT/auYWpJ43ASxqgENRAo6lX8
fg/QAH5fhhFHR3MwuUVMLogn4f4UMRcoPEBMweTmG3Dfd2+uzyTne7zjBD4HSmA+06OHMIbZI1Dg
N7BLOeN383AL4+5IBDuKG3lShpN4AWqF2N0LIzDWgAwK2sBO1JhEiM3G0MAHdMFJQxj8uJakv0Ew
wgiBBj1LUgz2A+0LkhSz58DaguSf7cZ4fV74gOrQ+to8KKb90qt+v8wfyN8l/j/NUNQ36BLU6Bui
f+2K4bOp/8/xJt+iOt/6we//uz9ZSt5EUuTx7PYr8MAPXPf/Zr9VXWfZ96eKgv5fVTP/Yv7ff+j3
746cKahtj/eeg4vceDa7I+PwzsczbTsfcVHgIc2o8Y5bHndVtGgrPWeAZkRLaWFEeriIn1pT/zGW
uCXlb4zsCufvDqzfQQwa8lP0NAHVXMVNoyeXe3SNaqFjFAvhn2AepKVB4BRQ1Xqpu650SPNSpV7K
slLTrpcqOS6tl6p5KauXajllvV6q56X19g7z3jDNeqmZlzbwtfLShvbaeala/QhK3hlKtUzLu7GO
l3eEVivLu0GvleWdUBsQev7JzRpeYbDUypyszK6V5V3DaK0w7xnGarUJ8sJa1yjDvLDWN2ZeqNQa
aXp5Ya2Vat4Std6UfGRqtaaYed9ptaaY+WzRarVV80K9hlmYwHqtE9S8h3R15zEaLHzH29tvk/up
O3ei6MEjt35MfNT+ZdK6n7Q8i7oMDEBJ8xVLGrr6UAoUxZGY6VLHhDXEcVgrw5Z33JGzSCNA0JW3
EP47kHEogFrzOGrRna6wFNpkvvDnDoY4Cil1AMZGyD1SqBFj+MjCD9CoK8syFF7iwmKAqhZF3OQA
JidHbfKxQA6vtkVN2gebxoV2o6dm53iGxenrB66Nz6Y12ZkAtO7vhh7wqBM/Ofp82sGQk8465xZv
90Ws/JVwLGFvBnikCXtIgi5q8eDNJz9ubDS/MxmrEJa8VEn9stIVFVSShUO0/QtUr+ssFk/IJ/nW
ayniq5QMzARbRwmQ3DuVASXBZoLzLTdw01b9VS2kov7H/iT9T9XNgv7HuP73l9v/f9X/Vqlw7HP0
P/aq/73qf6/636v+95z+Z8DqYGkqk1zf1iRb95lke4ovaRr1HXdoq2pgfWv9j63W/9g30P/Y19P/
2DMKVl0dMs2t1KEvrx+yin7YqOL92cvtX+5B/Q/vdUzu1fgqGuAz+l/J/0sVKGeY/flV//sWD35/
MYGk4TIce/5Cmn7pUbD+++M19FX/r8ZU5fX7f4vnu+++IxI+5NFNFj+SDAQwBm6DEBe3uY/3N3Ow
nUd3AGCDNAgCpPyEp9o93MUePOSLK1oTjN9wdRhP5kFEFrN0U/Ywjp+oWAymzsQ/5FF4C8p2D0jg
i7DXw93dlIuIlxhgLcCohz85zm4LzxS0eKLtFicVgYYAlVj+IfHLak2JMUlQzkhNeI05KUwVBk+b
KIoGuuhRCpJEWWzCTiTklsPJ7XYcTZMVOWLipAFMwQHS45f/YMD1AWZQizCqR8J7ex4tY2BopZ+q
Miej+0nhd+VnuRiwU46g5UT+gLcFr0HD/FdpEbpKBvxqJtwXXjzhots7O5HS/NKiCEMV0iRraxDF
1cHDP055NvQCaqlzSOFpE8007ULneLPB7XL6RzhvE/4Xmd0dYASQ4gSKKSKANMcJdLpz+a8dfxwk
bRuGUwez48xHHlSHxw0d0sckrnjiT6I/8OpdiwdkPIelcbAMixlOM1aakSfjw2un87BFDo7fWKBM
Zzhp3r7v9W8Gl31ySHZx4D7urgH70Lvun15eICwMtmbIX3oXRbhksDTDYrzS4KjT7wEkfUyCn5rr
KQJlBJgIs24Ee/frVe+62zk7G1x13qZkGVVWwZ/0Ojfvr3u8+f+GsQQYQjLAIKuBCCD6n7kDv9Gr
MHCGs3t/oN0Omxtz1ekNzi+Pkenukx81A2F0Wu8aQZLB3Ay2nN5NZw9TnGoEyjEMzid79NHbbwTv
v+9f9S6OB93ORbd3xlvNmrvnw6B/04FOP7v8yMEC3Vrd51cYlzS4PDnp9244dA6Gw3IAs9YduCMf
w6WSGFk/au/gHMIMdIMhnjFPntIHxhdi7CKZWRBgGnrBIENO3jYjc4g7EeFUgGBVCNTSSxVIZkIG
4U9BTJQgksFVklJY1zRiriL92gXGYrJlTFIB408SqYqX+IMEPD86SML4YF4jGv9xQLQ7AgbkqI5X
BCsJ7BwkFaBQKRHK2E7snEp182BmvOSTqMrOGjHI0PGQLxG4GDcLbLG+RP7thF8dl8ZYZoRWdREh
e/NgKoQV+RHb6buimfvZBwimg3g2mMcLfh7nPQYRYhQtiMYU80eBxyPdzEC1Tdf2/HRMo8AvyVSS
3HRbhhX1St95Bl2Nz8r4AraM7zOqMndl7yTLe7F3kv4QvcPsoVHsHSjkvcNU16l0T+NnY8XP9lwH
AvEfE9J5DxquahSG8IoF0LQsU3NFpYGAbTC6ss3z0VOkTDAKNG1z2sq0zW6pzVgqGk23HRGA+SPH
y9pjqQrzC+0RtUOyvDIkiZXk56qy2on6ZNVxjf2V6DDJ8OIRnxQa55pldHM1euq7KaFbZXRrf2e6
KC5MCJcarWl8Z0tViq/TJxmcFeADGMmc1F60jraa0abF1+6XoE0pE7QV9jxtlw1T2lpOfOV4y2OA
8z61i+PNs8vjzbVfOt5cuz7e6NrxNswCjfMvLuqTVcez9xskL0LzhUuQxPUtRXcKDJsw5rfQHQUM
0cul9aQs3J2FO4IujZdzXuo7i/ETdgE/bSCCZFNsseakukAWsJ+sQRja2a5YES/FRIviPw4JjxLN
V8NNqJTtkpdjzl+Kmjea38TjDzjgYK5MoFcBQ1X4KYOSarDjjqHf+dApjDfrgEz4vzWVUU1vBjJL
QMYWw5mLz/Joxrj5HS4lByglB6IrsqEiRskImrzAN0lV7hPjJdXAkQO3gJSdioEvzBYSwDCbL8Jp
jApadrphRwjG+lIHA1mnOrfUxG9nOpuSSWLjZuKU4PUF0Q4nMZ9n9LhHoQps27qZ0xP9UwFRdE01
EKYyP8bcCYFps31vIE4tiB6l6YcYBqqPmx4ZRLUb7935cv27hVoUO8UPrO2MneUUanQ/SXHBfI8f
Y+xxc2gNDStzL/j8+qdGLe4LeFLccQhC+NWT8upJefWkvHpSXj0pr56Ur+JJUXSj5EoRtyg870sp
wH1LZ4rOlL+nM8W3bLqpM0XAlpwhnkKHq/HLzpQEtoI/HL46U7Z1pgTNzhTthc4UrWTc0mC4zrht
cqYEZWdKsKUzJSg7U4ItnSlB2ZkSvDpTPt+ZEhSdKQ6tOFOCFztTgrozhfprx1uDMyWpT1od+LmV
M8Whr86Uf5YzRSz6jY6SoORNYc3elKDkTWFbeFOCmjeF+nx0/RW9KZqmfXNviiF2mf5sb0pQ9Kaw
td4UzzUVZ6U35c8No/nbPkn8nyfxTOpf5wAICoG18X+mVj3/axiv8V/f5PkFF9MkIR9Ky5NFSMrp
fWxMgqDIKO0wnwdL/6G8Trl/wJPO/6909Is/6+e/aWpMr8x/ZjD1df5/i+cTTm6JKlJxwqsmZqY6
vTi5JHv9xf2xA5rNtK2qjF+64xHxIsvjuRUNPaHh/n97V9vjtq2s87X7K4QAB14DS69Evbt3L26T
NG1wmrZIm9wPRWDoNWvEb7XsTfYU+e93ZkjJsi3LlFfr7OZaTROLEodDcmY4pB4OaeMZeB44Hw9u
guEIJzq9RsQsLokVJzG+FeuOtWRe/Pjs7U/aOWYUsRdfoZ9jmJLYKq03T2gPRXL+T2ccfB6QFzOM
O33NvNA6eIPBguDWMnzX9lzfNPgv8CTLhvE8SeGBa7qWBSngQsOdjs+ul4sYOMQNL9l0IlNjXOmX
v6cT/AhEhWVIGx+jxZWPZxhwNr+J5gGeLijv5svJRNAx4A44xrW1jyHeg3L5nuMbnv5LiQmZr3iN
TiakN6Bz4hFW7S94ocGf95A3BA/3Y8EUfviBnx3RrEzvfOnu7+PNvrH8rvZGdAbO3KTjDeTfvn31
ogj4ySr+yq/e9u4dvbmQ4DlKXToZgWJNvcYAvyC5WV/7B/oNF5bjQbaYzrDCww+T6TzpUHMH0NoD
MT/ARzqmLpfUpx0V7jskFyAz6KNjJnl4I6bThBfTzunzh3YuFy67XZlrhge5TlOUx04M+ebTW/lE
8ouE1hiGRyRZGyXh65fyHmaOy8miqEwurR0rvxuQTmOSYXcq5eAAHdV1b9X8UgpKXQDFXpqX0pgM
R8MFtbZQqEoeUIXEwtUlRRwjdnXLs12nIxQDeuwS6vshoWdCQTpC+y95TVGk8B3cuKbav7mSiwbN
kmg5B6oDIJ9QM+al6jWl4nOj7rk4w/ZyJuNNMvmlmI3xlIYiPiSTBzZSc5QbCRcEMBEkQSbFDfsR
nppd7Yc4xh6USVozTeybLpiDCR1lgWE8SfZwixmdPZs1pCYFy9+2/sIG/iFtJW1nVhqd/qCP133D
dbswtA0/a7NgcX1VnApKWkRTrgzt5KKO5v/+8OZXjKpJ/P7w+6u+44IC4Mm6OOvta++evejBEDqQ
+xwxbCcdrtIGTYoM1wrFDIQKRuceKBGu+Q3w1NN5nLVDnI4UJdKCbNtU4baldn0t6C1x4QpN8gBc
qLYoZ/dE+dVLYnqSLD5N5x/bI9q60Eqar3943jLBP9+2Q1CsrzSSKOkLvf7lze/Pc6OCntBvYJvp
REE0LnIUFLZEg5cZvK0JAA1tkkW7A55hYXdYMBv28PXvNZCYa5DzYSSiBWOo0zBJJkVMT9qZu7gG
myroKXjn7XI7Hs1nETFbVbTp1Ttrlr5l04U//wKPUJgswK2nsQM/kgdjdF/AhQhm0nH9lOAx0R1a
K/0C97+/G4AfQE7OnXa64XiaA7RK4zr+/gvdZ3neFnGT6okXhJHBDCsOGU91lzluGrM4dHhkpF7s
pga8eN7BPc9A6J/Cq1TK+aUL5SWebphuGjIrsVzmRS5ndmTGzAtMJ/Dj1EjNVJQxTKmIkM6GxkKS
xTU5K+MgIlfB6Qe877p9I+iHVj9cc3OVikHHJ5oPZ+RsQXlMlkWM2lboJKltMSflDjPi2GRRzA2m
u54dBj6Mt5wLRjfaQikjTlygW1Hu5QRKnJiHBFA+8PvTUoTm74heIkcI+5+qmfuWBHmrwLktQ/CX
l8zrGbqEt7Gh6Tm97O8leNppRu04jYnGXFQ4tvzADIOIcd0NmR1HOuN+6LPIMczQNkPfMWNR4TSk
Ct9MouVETg+FGzkFBZ8PxCFyJFHbr+Q+HTwhx3USgfqDg3grvL8v+18p9bISy1+6XzYnCdjeFFt5
gC0nE0Dj6JsEQd5yVcHoMqBggyBdYM0qpinQ/eALpKRQan3/XhQmMQ3kuDcCKtI0LBtI73ogjByQ
eRmMskTOO1aOfNkQiDoHCzELW85kzX9+91p8zVxZJmyy3G2nnhR2YkBhdIjlZVY4mIwO8bkMh0Vw
p440YWJyuKOKu6CfpSnAqmWVuvr92kRzc2Is5ldYdxiDBuNhviCxqv50NIxu864XjTUOPucrHOvZ
Kd1xDd3zHGtLUkprHoqzYEk+voXuU6C/mjJJcQgGi2SMXZaURGGTKNW5RDRXJJVwJ1VrC/qm3hSD
VpU5+LJVjcolBrDEq35XMuTY7zeL2bjI9r5y2Wf3CN73fauLx3KIFR88ZgGGbJDVPERLX8v16Fvx
DHgTz8DxQ56YScoC1zBZYoBouFHgsBjlhVu+47rWYaP2mj1XKqZ21I6txA78NGW6H3pMj92AeWHs
sdQDp8SxU9PXvXsexPj+QYyvD2IKLFPlfBhFXB/cqiQwU+bZYDE5132mW27kuo6Z2H5Q7Z8p5aQy
dCd0wjixmB2aEbP9JGYhWtxQjwxbjxwwB26l26OU8aG5PcfzDJSa56t4BvzRewYK+nPyDA70DGLu
6V4ScBaFrslgLI5YGsY2MyIz9JxQtyyXfx3PQGmwOKJnwB+9Z5Dv6WriGdhpqvuOETLXjALmGJ4B
Jg3mPlbIHRuMGow17kGeQZCWB0mlYmo9A9exXS+MEua4OlgIn/vMiayI+T6MgKkfB2BG7tkzMPd7
Bma50kosy8q5SWSYoAHccUEhYJB3Ah1u4R3bh1eh8ao9A6WcVEbg+b5phRGLY8ti3AmgH2BIYykP
Yi/1Yj21nUrPQCnjMT0DMLsfYQx4KK6BUvsc1zUoW4JH7BooKdDRXQOOU23bsp378g1qCriDc1Cm
WngHCmHyv453oDRgHMM7yFXpW/EOGq0bmLbnpzY0O48ck0UcdE/noclix/RCL3B4FKbV45JSThqX
LN12LNfwQMlB/MwgsljgeAm6qVasG77BXb9yXFLK+ODGJbjlnmu6CYzUpm+kLIn8lMWmhZ9cDBhK
uBMbhnHProy135Wxyq6MEstUuciNYzP1LOYHoC5W6EIe3bdYFKRR4thW7DjRQQ5luLbqolTMbofy
eN6BkpR+Fe/gsS8cKMnkyTs43DsAA24HXgyObYo23NJNlnrQ3kHghIbDeeTpwdfxDpS0/4jegcra
ASKRRS7X6Ypzc0u4xPzzhOil5s6GAS7StrcBbbqYL6OFSFOgGuKOs+lE4JufyRvNsD0Yzk2u/Xv4
TEvnSfI9NAa0Atct73tNHPnaqGGrYH0HeFiGq5tblUYzWdBE50mBrtgGyk3o7l+n2rtfn2vyWAEh
psu5RLfAgKwFEcIeD2HWhB4alNhb05srsWtu06JciRhTur79cIg7C3WVlq/rVW5t9irBVhW6VUB4
RNMZpt8VWxtF3bRpdiUAxiDfV4ZAXV6pdLGgZzrQsYRxXe1DvFISkTw/dCWGj8GYD0V+x2pAwO5q
cjvxikCDIatBSWAOaDP9ILlZRNeTxlV1u7nPn1O40lQsUp4fxFIGk1rV9E6gpQZlg9isBYfY0co1
vo96YS7MxwT89zCZco1uESyryL+V3e6bdu32BNsA2ZQTQXKh+hpOn7R+Y0BWXdmSdSjhufAKRwix
w0FiPYkOZ0Y7/E9nNp8uptGUnDOx/ZYF4ZBG+IVwIQR8Rx79wUoAdJkk3Lr6Q0g6X+hYlbrTOLbN
zt6Kcb2mYvlhIJJjqkThI68hbPI3tyuyweJ2q0jcvIBBbVdxuyFqa6kuOjAkVU8AHyaa63HJrDjc
pl5k4Z3WJXa7qw6XV+SvcT9Vd/VuiS/xUtaysvTUK4Vo6ZZ0YsOaPkZIZ8t6IrlnQiioUQzXMDvF
gh/Lu4pWIHCuv1OzKnSpUtlqNYtsoOChVrvgPXqrbQ07XJ9yjta+bypK2KbUrLdbsdhStTbSTH6a
qSfK7B79XPVXSzo6TElHvwY+vGXdqmO42Bor9OSelWqY7h+u4J3Wh6vtTqxWr43WOLw3L5NFhOuM
lyIpuyx17x4RqtIDpXGtziZgo+5RINE3CsojFyM8mBpls+ATbYeRu59orTXra/VLrdpf+9ZioVaM
RjFD/BQ7XGkEu1jvMSb9Pr1H//WLROme4J04u5DEe0FLmuw1/g1Fz24675Ur7OOUv1RPbYaBQ0zf
sxWk9Qhbr1VB1ru2Xoud0DIIQMcwuW8hcsDu+abMdtS910Z+V9p7TcvGcof4040d4g3WPrraeT6p
bzaXh4y4VHzXPVNApvxxYo+6wNsYADbTztfixVpg9D3dsTmY/vMicG5HOWwucrGK+GtybnBuWy6H
5PXwwtAIkLYWfVYvXvrtD426ARI2gv0CRc49Tl+Zz2WgXRllFxI2YuQaVIKM2HubZHArQgwDFQf+
OB7WshzMWIag63a7Ty9We+GLJlYZQ5vux5fbxvOTQukjpDgstJDLS4pgi09WjJc+DtGR7fS9Uigc
aEkFOW9FbvVpTzYdKUWxG19V5Q/dKS+YuL5hpKlsNP1EXBaSt3qHpJxNSXNJIFaP0LVnGHxYNouU
s9UHpM2QBJtUZTwUarde6SkINcs9SpCZcjtXxT/IM8XxnIlwxoXRkfXMg+WxmQxCsZLh1VuyjVgU
TKJkZZb2BTMQmfPlOeKdFJKRQjJUyPVWL17NFZq4YkKhC843YxkMp2A0OlUacVEKylAqBvWo1MBS
rVbimUvsQct5Nuh1+Vxcid1A5/oAF+8rLrTkzbzPe83fa92DPXg6WHBUdhW4H/txxAMWJpbBbCf0
mOtbEQNv1oe72HCE3djvi1JAyFw5K5zTcrfcLMDE1nuhpXY+oAVtZ13clGi0FTxjH3c2enzyYOI/
oA2X2XMwNVjxfT75pcyFVhiyVVbKfaBFO7q/q2heS20tAoH8IGnoGHDrJR0ygVJEkT4Lo4I9/l9y
2B7GV4a25nTJr5NX+R4EjeT4SgSg+u++Jub9mq6dQ9Xxg9VyJKJvhMnq6O+e9rxIx9MtNDGly6cF
OLlUaKFNifN8d0vipHvdFx8ZK75M7ifr46JGNVmRcm5s4w32k7W5j3aK6GxO/Q4hZzoYDQvDn66o
bX++ViCE8dPeQCffIB2a8TanYvvbmMi8zeTCkODw+SjIMu0Ky7nIm+Dq0FI3ec9X8I7BfxiX+T+8
5M06iGPrj1CBj+s1OLDcTfbxo8QxuE/DMvOHlbrBezHiH4F/WVapDncoHWyBALgc3aT8+ObNb28I
AvUMozDjZPNN8jdFDRcHEYiDjXpnf86DKKHR63w8hafzJIIZHwXF0aBJFl08b+UlhrF+WjGpx7vZ
7eJ6ShFhLj8l4aUssje7hWksQRw8+0KDEQymIjhTo7DXcxjn5hNtOhuMYYiZxufT2QUk/t1tUBgt
uYjB8LKAepWKdV0qFsqgGpfLzZJR2vsc98TYKp6fUyKkYBCgX2GgPe9ioHQcTBtzteq/Ej8w1pvE
UbnUMxkCHCN19z6Bp/dyOheCmZ3foViS81XRtudQyesFUNlUa6ixSFv5ObieE6FOdO/MluyjNTeq
3C4238Wc7K5xMBO9s/bKheBdKMOrF8BY65xJEVorlhh7+q/sqfYvsegVrzFCduRCS+ZzYOfd+Mf5
fDo/qi9Wj3rMN1fsQD3uN0WHoB63qbaHeqzjuBL1uI3T2l/pfahHXol63KbbAupRgdkDUY+G3hD2
2Kxbt2GP3OGGZSl0rDruke/EPe7qjGrco4qQ1OEem4hD+8DH3SWpAR9351cDPu7O3xrwcecmsd1l
3wPwcWdhisDH3flVgY/r0OBDgI9q+5nryn5wa5s0ZeLVC5tcAfhYX7EmwEe+/mV+LV7AzpVO3i7w
ke+p5QMAPt7PPv/HJbMwU94rsjuBj3eQ2DrgY1N53QQ+KvVTdVc3AT7yxsDH9nRiw5o+ytANLSvK
Q0Q+8t3IR66GfLyDih2uUFXIR1URawn5qCBAzRRUDfrIFbri3qCPbYbSaVm56hg+OvRx74C1E/p4
B22qgz6W9WsH9LF5bx4EfRQ9UqUHB0IfeUPoo9oQd0zoI6+CPpZ7bBP6aLYCfayscDX00TKsynn7
nrAj9wB9VI0T0xD6CBbdOUEf24A+FnJ7gj7eF/SxaGKVMbQt6CP3W4U+miWc3R7oo6rKPxroo1jf
PWEfW8Q+lkfLAvvIW8M+1ntlTbGPD3atJW/mfe5rPfbxa0wIK7GPYZqkQQiGw7Mji4VmGIBva3nM
jBzP0QM9jl1FZ/SesI/7XNH2cYt7BFkJVVlL40AAIlcDID7UohtjH3Nqd8Y+cm3N68qxj0UQpWOC
H/eIrQL4sfKT2R6y+8GPvBL8uIdsU/DjPnLKSKV9hNTAj/VU7gv82Iz3Oghi2/yrgx+b1WEnCLHt
CqiCH5uxvwuG2Db3auDHRrzXwg9b5r8h+HGvLVADP7ZuUk7gxxP48QR+/PbAj0/+/13RbNkj9Vh8
XtxXGQj6cyzricT/bf5ruYb+xMAj6i3H0U3nCdhd3TafaPp9MVS+lmgpNO0JLtLWvbfv+SO9iuW8
7/AY7hvQ2+l8MIzh7qdksgQ9fQVT+tEZiAkMauPh6BaeOGc01H4HPy0uftPsCe7zi3Kdv+mC0s2T
8z9fd7Whzbit69rz399q/6OZPVP/6ef/nGWLZDaDUReyulTI65//g3RN7vOebTtnURBdJxqCH7Fg
w7K0fz87m13fZkMYRDViVD/LhiGYlA/ZdxhzNIIS8QE9QZKYIB4Fs2GUP8GF+yGQkGmYlM6W+OwW
7CP8HCSfo2SGqxUyDWgNY22U3EDVgZp59mlWvD4KoHS4gXxgUbRFFmnjbA4jHFigzx4VAnZspo0X
87kWgeeFh4Jr0SgdLbNrLYhmQ208/qylnyFTliX4P4e/tGvwKG4z4S+MyVlaBJPFAOnPk9ngw3Qa
a7PJEF7NEhOKMhzMag0M8Q/XZtNZBB7HKLhOB0BhGAdn4fQDDIkzbBIHxq6eZZ/ljOTtbIl2HwSj
4YfJGFwWkYiLoSAs9BpmNx0tHC4yLe+PC83yRIqEaJzRRyAZYxfp9M/OyhJnfGsSZ+yUOL4tcfwk
cUeXOP6tSRzfKXHWtsRZJ4k7usSZ35rEmTslztmWOOckcUeRuK/tR56u03W6TtfpOl2n63SdrtN1
uk7X6Tpdp+t0na7TdbpO1+k6XafrdJ2uh3H9H+kCGZwAIAMA
--f46d04430662c40d6304b92b55c3
Content-Type: application/x-gzip; name="xen_server_6.0.0.tar.gz"
Content-Disposition: attachment; filename="xen_server_6.0.0.tar.gz"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyrf2gav1

H4sIAIhyPk8AA9RcW3PqSJLuZ35FxfTD2GcNo7sEu54YjPE5xDG227inO9brcOhSYK1BYiThY/ev
38wq3UAlJHDPw9LRx0LKLzMrKysz64K8FY0XP/17PxJ8DE1jf+Gz89c0DFn6SZZN2dRMSZflnyRZ
MmTtJyL9m/Vin02c2BEhP0VhmOyja3r+//RzT2MavfnBgrz5UbKxl8T2vIjGMYnXtkuJ7YRvlEjv
c+qy3upc+8HmnbzRKPbDgCg9o6cqPVnpSj2zJ/feY6MnwX+60u/JpgRd+04DcrKg9DX8h7Pxl95L
GCencMd1cyYaABWiSJIlmZJGTu6pR77ZCb/f1azTU/KzTGbTO/KwoWS4WRBVIrI2kPWBKpPx5QNg
ZbnzfXx/M74m8Wa9DqMEeLjrTTzoEDIJErokX2mw8QPKvsDN4fQSWCUvNEh8F77ArZvZCKhCjxLn
A7/ArdFH5L/zfydBnFDbw5uAsTdR9vebvVnGcPshsoN4RRM7E/UwfbeMrQf51eju187vNOiuo/DN
90DXle2+AISs6CqMPuDrGjS/mNzOBkTa+ZBu+VYfO4acbGLbWdJTAYYTbGFsxuYkYn1PPRGKViTJ
UiNK3tVPyVSu0y8nKGOUJkk5SYHSmiTlBGVMoyStKsm0PdPYJykn2MK4CsMMR3cTcvPPmQjFSbZR
ToHy7MQWwpwKbK7vb1ZOso1qata80iwqGU2SUpItlKw1GSMl2UKpbqMsTrKFMueNsjhJCeXwv/W2
cCxOUMLM7RRTq18WQ0sovCU3oTzZ3UV5WpOsubQjS84e1aMKkhylmXO6Y4utuLV++Yh9F9LG/XCa
Ri14vjdoKXNrh+PldAKZxCRrVCxIep2lHSfP63lAziH1MHrg/f5sR+5LfjtTtuMHfuKDBkXoXINi
oEJJJiN65hTPSAEZr6pkd1fFTomEcct1X9sLSrTXziuNAkgunh9RNyEpZ5Jgu2KyWZMkJDnmH8Qz
8LJLaR+Zg8kuJ7PvqIdeDEe3j97XQX8dkPvZ5R3qMJc0XcILBfLjm6SQ4fVw9n14mpL9PoMkyCOI
ycj0EZLJKRmBz5BMyYRAF5sQZfqQ/iaE8C6X1YzNFfxhbGxZt/DpFZOmHcjmMteGsTGvri7KSpfY
ZKad3DxcYwEA1Z9slrSZEYwfDhgQabXMKsO7yYjrqXCr9C0UoB6o5yzT01YoNhfKztRq0wkkaGRD
7u5vR/nwINPZ1QORVP4tYzMdXX3lbNQ500ZtMj5nwz79vLnD4VWqjaYyNpfqFpvb8ZSRNLD5djdO
2egS60PVanaFXj7cc4+aDu9TNhrTZlzHJrMN68Ps22lHml6Qb5Ov36bjKbHfbH+JQ6LXgcwID65v
f9u5T7Jxuwx/kMhe8eFbjMPa+wHWa1LpcTFclTQGFlQOFPEgp0yEf3QIcZ0TnVA7Wn4QHh3tBErT
+JScn/+dw+iKPFaiAf/yBBJ+lvjjrRpI9zTZ057QWg/j3x/I5fBhSC5mM8a1lhy5yfyxXk7TPHow
bhhkSR6Ec24icuSmpI89vSxMl42UW/65uP9e4iYgR24qf8z5p4+pR3Pd+MD5+jC8uB4X3ETkyE2r
mBU/xja3i9vbh+nwruAmIu/Mw03gsYnC9K7LYjCBacTjnEIEUVTgB1RzD646/x1CrX13dQM+Eywo
myVcTodclvResP97+k3mbnQTRivINKR0N6dhPgk03/zFyxScpXR3h2YavjHd/kAlcPqZMFXmYQQe
6L4wZ+0wX3zGS8xXj8oTsd3Efytr3WHaDkQKM8/cei5S5DbIBkYSJvYSc1o8IHJf0WWlM48ohYxL
7WeWO5FwkJKfkfUCqlHiShp1ZAu+cz3pCnUlrswL+9So2MwBURWWMyEpxuCx2FYgB+otIimlyQqU
rYeaZGj8+Rm5nlzdEsdO3JdBqV84naxZVq2sbUrL6CuWgKcqZ2FQYbnmxF777rPvPaLxnsiGX8lP
hAbYk14WNd8VJIS7CRQi/iIII2hDLScl56R8kpOWc1I/ycnIOWmHc3q+gTR7wvHz9PNEXmBAEOpB
vbT0gwQeyU8Zx8ktVyC3bLr48FgsODyRRew/O3ZMHyXAcQRcDkiqNbpjtpKgKmf5+kXB4ox8nUGi
6ipqJvbm4Xl2P3q+/ec9OXE2MWaGTfzsR/+Cq8UydOwl+6IQb77E/0+bgf0ysM8bvaRvtMDe/yJx
h3Q+SAgaRxC7e8VDZd/DvuDhrzGWmmxeczIdXj6cMk/H6OeGwdxfbCKWw4gfzNHp8bozXC5DFy4B
eDea4DgLN5ELI4WFIbwNw7qYyiygoM+/Dsw5nwyfdm7un6FAmg1gUAfRs7verOz49dnxk7i4BV0T
DzT8woIDfpM7d+N7AA7IeOVQD1NXn4++vwGA/MOVDQcrYxLLKtQmJJIIRGtZ08jG0HXV6KyBrGtj
GwZ1NIQ9PpeNL5rU30Y8YgZg/8rsX4X9q5LO7Edat0+vbmJmRQyyWPjYkE9AKQcsDHc0ObunwfxL
1k87Fxt/mQA7jCdLP05isDZhySWMPBqdkVXo+Es/+SCLKNwwGWHQg2oA4y3JA67U7yud73wq4YYQ
qkAEDBYIUbjseH49vBhfn+NlN4g+Nos5XcAD8k4D6On4/OXNxS6PwyXFayn/kiQfEvnXxqcJeVvY
56alk3gNc6uXzt3kkrzABZ+psCHtoypoM3LCdB8QGEyyoVoauF1CY5im8ZHvQo6iQrSsYk2Z480z
oiuaAtE4ZTBBT+jW43kHZnDjjCiGgj2bwscYjtCEc5gekiuo0GMbEiIaCxw5gXDU6/WIB9bvFbSb
AH0TPG02mV4yEH136ZqNjHSpsEBN+FTS/wOR4Kg/S51ZOE9+QBqEWEUeri+ymDggHTJc0yjZRNBL
+IHktKILm+kKz7JVVP8PeA5JBgdHh6R9zPL3ABKl6aRrPq7OLzswLLuQ8waED+84E+9AbePCn818
TiNmBHBT0Olk9tvkFhQ73VY+q0KQKs3xJ1mVMMguTjtTNiMGW1uKqUmvfzNNS4G/RWVOThTd0l/J
a+acHj0jlin1ldc8S4ObaDrQ4ALVGVFl45VgyXBGgBHGQUi+p51seTlllE7Wl/ZHuEkGrFKZ++9Y
PeDMHUK3ZZppgfeO9RtboSHkRDVkg7xCaxGxfmWAFKHlJSF8MfgXQCiSZuWItxWLBRxRKiIBobKF
DkQQRTHJNEXAxAJLf4ZwywiaTesRAdOaHEFID5ufIrS5miFcSdeUDKGW2gEItF2KUC3DtMwUoc0V
3bQQgTYuIxL6nskoJhEFnPCeY4jRC3Vf0Sv8OUle/BhnDhD0Y/CNlzCADBDDbUp+u0MvJZC0MGng
6MCtAaRaQbfDKLl97XW++TTCdRi+6DP6lfir9ZKucCkcx1QPcwMkrNkA7d4Zvyc0wDg/mt7OyAcU
tQPC3BznLxHlC/VYHPaVngGpY/rtj0K5XmfEAxmMlHAJahJvs1p9EI+++TAULOld0TtprCOPGOzy
kqW4jQGxuD2C8eFEPAF6FLwP8ipbsPFXNILgSF1/DiUOxGoggSYTw5BxJ4NchItwOrmbkZPl+n/P
VVXq65YJ09y170HN+z4AbnN7s0ywLaZhkRW4wGoD81FVkjsz6m4iTAJXMEWlP8KIDxA2WEGpKQzt
ZE9YxGp85YIVcFEijVkxZM7paAz1avAaFx3815dl8ldgHifRxmX9AW24/d7rYFlgLxMYfDbOIoBr
/MNPcM9hgWtUv96xoZ0WHCMIpdA70Pdsj0eSIEFJahMPXnkAk0oUlau3lM4FGHnxkuAimYa34iqR
2vkKkTJJ7ZHvOXVuxg8Dck8XkHBphIuQUZiE4CKQGFY+zOBlI20IlmjJx5qStetDgzIABtl03Wa7
VILJElaahGYDPaYLdG1e59GYLz7oOmdwEyap+0yno9ubq8nXHn/AQ/c2a6aGzOIxE2G76OQdxw/B
u2GWlcBUECIu+S+405X+jnVYttw1Hg3IdRi+oqnGIxyauMKWPXwH58LdLpk4ENleYxLOcbxulrTL
6k/Id0jBTDicXpf7GffConVE4d98hPAnJ7mbzSQy07MaljcsrdqxKT5yiDbrJB0yiz/JtIwBTj7R
DjkkSzhoAlb3rkKIW5ET2pFX1LLlPsg6hk+us2DENeM7nGnLcB2cPN/OJidsg/MUyiZameXchFAn
uK9pAMJKcRN4aZ9PkBJF4gYncaBEhwnPDz/wwh9AGIUrpvF/YggOKHa9HX2cYVVP/gLOeQ4Xz24U
/yWtZtD2xAbLLFLRWK3fQwFILjjnR7gBce0kzecQiMDD0y8DSe6Bue+m459Lu6FMh0uJXKovwOZS
hfHi1aE8P+besPVcwecwiogsQbWDqWK1QvfF2ZrDs28XL00+8asDWyUwLvnPGYd0ywU5ONnUsYYD
VP2IhGZx2alcSd1ByMY+halkZgqzSyH4UBuWUEIbynZJJVWpqGQUKhnqrgU4+GCV7AaVnP1WkgqV
1EqncPDBKjkNKrlHcXUbuWpHcdUauOpHcdUbuBpHcTUauJpHcTX3cvX2+7ReOJBe9WnvqK72Grp6
3lNylbZihSwzXWTZfKpDaDsIrr0sqbUIaycezXk8mtfLcHcQlCNorYxKzPM4wtu1Z4HYaYfkcoRb
Raj7xr9WdJ8mVbovB1cU1Lg4vYrQxV0jORzhVM2mi7tGsjnCrppNr+maPkf062Xsdo3FEVatjErL
TY4wa1te6RqDI4wthAygPSPLzvPl3K7myy2wJsy42WwWOLiCjLvFwa14hlWI7+8H77SWchTdsU8Z
oZZbWyg8dwqZjiQLSgRewUCplNZfMCt5ZMu0cleSRbQpnUi/Gu4pYrc3rLJqouqlDD6iN/L0Jmic
0pWUMq267Tjlxnl8WMIfsxah7SBUjlDVWoS1g1A4QqmX4e4gZI6Qa2Uou+2QOGK7bFO33a6SjDw5
7yS4NOe14FoP9Ipu9qTdTso4CNMZ5rI62n31iqDD1W4lGTFagTdnhhK5k1brzVvNrPiitu1flZzh
FmAXjSwE5xPMS5lcKgKCupoAyesqA62NUXWxUbWupFVMpNebqNzKion0BhM5BdipmEhvMpH+CRPp
bUxkiE2kdyW9YiKj3kTlVlZMZOxPb45dgO1KrDcaLCBuu9Gm7aa47Ua3MkNktIIx5xZhfA+i0mCr
1GBx/Df3ZhCvyCAYF3c5mEctC5gNywLwXDuKq9bAVT+Kq97A9YhJ/RZKzNU8iqvZwNU6iqvVwLV/
FNf+Pq75sBIMG3Nn2GS07YfNDmLfsOnXBpk/YdgIGmd1JatM228K3P1PBO5+Q/DKx5RA0X5XskWK
imjtHVqnIZX1S/aXdmuqLbAl7G5JjChsqAieCg1Yazqn2XR6nTmcruQ8CWjbO/AOouLAZQNW3M+t
s/6WA2dlLV7u5SBee90eApWytsyhtjAuDUOr4gbuUenabe42o67b3K7kPgloW0QRSxQDjE9HEbNO
Va8reU+iIC6gpV2JPolCs4B2noXeZ/ZV4mUECQNy8+t0mJ4KKG0vTPK9nHu+l0Me2KbR4/88zy6e
e7jh0Hu+u394OhBzN/79aKB2LFA/FmgcCzSPB17cK/In0Rf36p/A4mhzl1nAlfJ5Pkd3YMHiE12Z
sfhspwIL6/Ms+sexkO72ucS1H7ySx+ub78MncjK5/yUmKtGITgxiYqb5IstEVnA1SM63f2sYXJQZ
fMk5tGcwyhh8yVQ4CH6524DD1B8L21/Gky/iOJmzuPo8i69VFl8OssK3XQZfqr3wTgM8pY07//yo
Bdskd/BMFKQFL/LfaNTrvC1sO3IG2TkbGw9qMrEDnkT4Uu2ZR/EoQXzuh/8BPM/CH0F+zQ4inAdh
QHNmy9D2spMXpZOr7BTb/S/58YFZ+USJy/iwXX087NhZB2vQI7jjUDxCUznnEazL5zy2AAO+X4+2
SDfws1/eILctFpugxCT+gIsV4S2Hgg+Pg7EDfOzYWLGkCJdYv+ERHuJQdr4pPcW+jwMtCgearvse
yAEE9wsd+upRHJSCg3qUDsVGMVw2c1CQAzvlkLFQ2NaM0m8AmhWgxrbCNE/eD3SqQKavpqsHA3UL
gWaDqlWgLLPdJFluamUVqjNl9VYydz3ULTy0uWcEHIqlTsqXOokbbpYelJAJ8Gmth2TlekjWEXrM
85EybzVSXEHHaazHTQFw30bSGYkh2AWeHX2QopiWBRiCZ3L5sZ8B2dpMEhLjr+AKasEukhB1dz++
Gj+MvpWgHFjaREpvpIbau5Mkbp0iwGy1bs/Rje2G7SWstKXVXohYZVWA2emQ0n6IkHinQ6obIUJU
60bozY3QBJhWdtdF+ld2KYSo1vobzfrrAkwr/Q2R/pUtBCGqjf7VhTyx/pYA06S/KRzQewnbqFxd
phOrbAswTSoXdA0qF4Qtray1UbkvwLSwstbWytpBKuttVHYEmJ3oUloBFBLvendl6U+IatkIo00j
XAGmhd0Nsf6VVTMhqjZdlRbN8hsCNmabhok2V1o0zGzrUOZBfWG1UZkKMC1UttqqbB2kcr+NynMB
poXK/bYq99urXN11EqtsCjCthq0hjJDCLSch6lNuX92KFrfOEGBata4g3tM6u06tT7euyMWTmwcy
xB+m4490ZYOcsF8tnOEPr07xNq4OyIYAHNOErXwt7YQG7kf6G54kJEalhBKKMsWiTAH4AFHaZ0Rp
B4nSC1EXhxmQgw8QZRSiRrkoSyzKEoAPEGUWoi5zUX2xqL4A3E5UOXps91ULURm4nSjzM85uHuTs
5err4FZl4Hai+p8xYP9QA+qfMaB+kCjj6GiRgVuLMsWiWoyrDNxalPUZt7AOEtX/TF/1W4ja3s/M
fvdF8IQoZCb2Jol0jUiw/ZmTy4SthD9maaq0rJR9duGyUNrugeEaQCGv7rBwDVBhu8yEv4Co9pxw
CawK1dw9CVoDKKlZcwq0BNRqgOKzkSWgXgMUnxgsAQ1h23ZPXtQAypLEp+1qgNtdULfXXwKbh6pp
NqvZb5R0sJrOoWo6NWqKz7CUgG5z+6xGYIv2Nf00WOlM7thmE93zHgv+E+7sPRT6WfZii/Q9FA+j
O0JjxPjxC8ho8SoMC3hImqWbRpmJA6VzixdhVN6jAdgB+Zbj4vyntqDMSVmzTG+Uw3hyuRENwvI2
WePvqUsxOvudxgX+GBVfPxamu2mdh+gj3bfbBGvbfWXvLpnHxF/huxLtmG3YRfZqHvd6vc5VRCl7
JQHe9NL3QeCLKCTrleC7p7zOdDQecN3f8KU6uFV4eTvFd70tFrhXCM+f8cbz9e3XARoPkoQXriSy
Al95w+zy8n/cPWtX48iO8zm/orbvh4ZzsOPyIwk5lz0TEuhmpnlMQnfPXS6H9SuJB8f2+BHgHn78
SirbeWBDAvTO7mWmIbGrpHpIKkmlUpmB47vxWsmzkM3whHsWT/AAMqZeqCkRhMFyoW/Hoy4beMkt
+zMLU+iRg39vWrIhq40Bfn7mFD+n3I00pZiyiDKt5PM5SyazwFvsScD6h8Ootfcbpj+h5kC5lEYg
SZ0Yhm3nFn7vNg5xhxSzaADQUR+WWWisG3s227GSyW6+o1uenFdkPd+HZTsz8w+Aphr6bsMLWQKt
xiPjmCwkXNlCXXlpYrJkLzJTzN1RV8hxTQeT19QWsMd/Lr1jO3nqhN3G3E3MMYiYMaZJEJlO6Bz8
/VjIFxi2PEsgjA4d/O2Ip+IUPlcV5XZP5DJjXNe01m0JEjNYMC8BDUK51zvKPW/tUYYd3w0m6fSA
q5jFjPLxHChlpcSOQ9+nVKHQ0Ni8K99cxpmLOSmAOzHDy4HSNbqtLkiKZOqNU/jKOTxRGrC+d9m3
o1GPffvUE/3KU7gUXDP2wyh6gFJf6QA+9mwSmxbmPVNpwjEzhyiUT2fjeNBHaZ0wk0Vhkkp8f5+z
jqq02w0rdrr56f9ix92HCV1/htk3ioQsRaaMJKOMBOPMB47HDBKm78NIA01iCo3G0dzFJBXAUZTv
VIQGlMXkhuXfpmZ0I15QyjjgXXpWFC4oTivK4nH51ZJ0gJ7Kdalg4KbjOAzStYCFoukunv6HMmXk
wtfAw1xX7BTIyZMuQH+kr0fSyeCoGL2LMxCeF6OmyvoAGScYJuMKnioaKEIXI/XXa0F0LWUPfukM
ZQ9fqoYUaGLKlBA4du6y3tffKQa0dFLtlXlW8P/ADmNKDhv5LiZAwGSS7M5Lp8zrKLoqB2EURI0E
uBaWX3rEfj0cCIgV7Zh5mAmEGjILMX1APrqYNgpYHCkGZoRhsZfleruxxIcg0G5hOtOklBe8QWr8
OZvheEL770u6XZ56yp1wNBgAWFsku5orMuj7wI669EsWSCowhraaNaGU/1lAmc1W0gJ1RRIhsQp4
QZQBAfQuRfZ0tAkcNoJJV6HSg8j9AETatH0zSZpUWvxWFuljVvKU5LlkKpgRU8poSiNLLJgzt7ss
pAL3TiS7GGNW/FyuQsFxsnnxaWbVFs4bsADccKegB01t4Oevo0Omygr7eBQA+9mu85F9xiQTS/S7
c/S5f7LLBoLEi6oLz4i5pU1WA+E5w6ymCjZsvbl1ZXEgsLOo/S3GZw+mN/EmAea/gxdBNrMAKa8D
4sDKMRHso9aVEas0LVIovjFliqYit2JEQxmfXFebGBHWD1jUUBVdZG6oq1BMICXZww7RoHBZIVrD
2ebdtXQpf+PMnoYJyGkKkqZvyNJAQ4xLALiAiw8ER628UpmInnfcFGRPZV+cSppQtUqaULU6CNvR
hLMFTTjb0kTVfDsb0ITzJppwCppQtTWaMKppwtmMJtRtaEKtpwm1libCFRHDZc4+nkduUCFezpfF
S7ZSDdZcXC9gOV6vdbImABukoSaZlcfoLOfA8j0LM6CViTxhHHJlRW7Ai5vI8+4XI0hJDhZ3kHCt
rsxT/3itx6sGAmYdvmIXCrtQ2QVnFxq7riv6HCckduIprMuKqvSALz+ADyAFRpghembes6+gADa5
pjF75mDk2FhhdurDJ20MdsPMmZlMpIEQ4kjH+uoz9dtl/fZK/Y6ob1R2qnKHYasRNJZGUJJwBOH3
NZE4l7hgb8qVmkSw2BNB5Uuh0OlL7sG8SEVqV7UO1ag/zBNrgY5ostHJ4GJIinKZztDKQE8L3ST4
CEpYGN/WQXppLtX1udTW5lKrnwvMdJFPBqawWJqNdj6bNJb6cxD2FxA6KxA6BYRyiLdZWHj9wpK/
aq0LEcSjvmEqy/rbCLvadpavOjXtxC2iV7WUZAzK53xafAy8ziIQmwb7ZEUJ2xmNQHuG1YhzDShR
yEGmYXIuUZO/ouZSqzcbn7KRgEmCWqNLTVOVlqr0RqCEy73eL3srFLWo0FINrqu63sGNZrDwkz2h
94Ou02VfDnvw4qz/G5rrERgvSlNTlzoG2CiUGv8wxrzPvRHAgk//2GP/9YV/W0aaL3HYrY6YDMze
v81c6ItWL7m+0PZZ6xavKQBNQKZlwPH0HxvQBR5STwgPut7gMs8HvzSC4gGOIrv4DdOV985G0Guj
kTgLUFeJY14vjabBVQkdPei3oqyZIk9fl+0AWPbpsKnud9gn73C3Asr32IOKF2C3oQXpYXK/cUWx
U/RujNwgwRzqCtNM/L3cR45l+wNpeH66nO6/mK7l+RJvcM5e7KNoHSlO3SKB4B5oaabz5GEhc3NF
ig0uzhnMxvHXXoMBrO4yRWxG6FiN4y8Vf2kVzeulKbbCEZ4xsM5J2qtEFWNYEIQfCQgqm7mCKXdK
5hNMqz5ld9BM1plWrWB3dY3dnfAuWFTRWSUiZFno//dBH/6pylFvOJIU5fTb90NlD8hIVnqHBn/K
vqKytg/Lh7rPW1vyr/osGxEF8Q24ZL3R1N6nFMSXpsi6Xm50PZtgC9nlYROIg7PLnFHWANUxylqx
WkapAfgOtI1+RMfiFSgq6DNCFcK0o8LbrtXustdvp9aAeHZT9UW0ZQCWEM4S+WFjDLAHNaSLV/UZ
siLRN0y5jCfOdUnhu6WSn+AZImcmOdjon4HOpmYq2+GscftHmMWB6TtlDnqZgRUxm3mpcKHM0Ztr
5NFPSePo90tNGifo0swCOkUMnJxbFORWIxc7PKeUypS5uPAhXfTZKHLNW3QrV3mMeMPrKPwmmS3v
GIsUZ1tEv4zcGDoMGohqKE3eMgwlt3/2gO9JKdmjosnUJH9nObQJVcRqXZamDyMF/X8nzXNS+gEd
KnYHTN8Vrl+C3GtgI80tysepfWPPQuwfbcMOL/tA0AG7g2EREnakPykE39kTt1VZCMYSPitYC1pu
+mY8K+6+wkz4M5B00z32oN3ugYKTZ3NnwTw2Z40kRspE9VmazWwxTkBNnfsm/GN3yIMxc+aOBIWZ
7TTjO3ZvNtGpq8JXx2RpbD6Ubt98gcudaMM8gTGIRlkFFo8XK2HJeSTe8mrQlpJQwjsAcJilKSxA
laSiFofxlkteXXwfHl5vDkSrA3J8vbKcrTa32OJJJoo4sfZc3xaFuSi8KoXrCqsF5LNwyXjq39Nl
ErRC4IUN/PnX6vOvtedf6410osl2d67JnLf+YDu/mEGGwY8qLIF44eduA0uU28R1grI2cOdp5edE
JPpKuLavlxvhWwvmGgjbBSa56RR+X3qTMNDYVQQCMwh3DvunRrvdAWkbu3OGHw2ON6fsYOuO7vFa
vWQX7PD+4nIUpasaXVXt2m63pXYtqxaVWVDIxed/oCAB6C2D7XAFlWj8pxyaiStdsqN8M2aX7XwH
NWGE6vwVXvVSB3n4uw2aVwJl6BBrfzoZHn3CGzlOT0By4Yfe6Bj/XI7ObTO64lUpGQQosH5v4js7
jf3icigAig/x7oerli5ZXnpdTgBof3cSpmmGmujYkmhW0P2FA7ZLF64cXPHWNWOnpyfnB1dlfEOZ
4gTegBJ2Ydq3bnpwhanu4dHJsHlyiZoUpuZPDq70Zud6i90Bz4G1sRAeaAedRykpQqe0z1MpQfRG
zrMS6s/QRFi59UOtq3GlL+MwwAq9APj5ZMDm0E+eg7x6guUa00MAKGnZWYlaebGlss3eCPSoIf50
2VyVW92iDQih8AluDND3YFXOTH81TTyCPIVBYSPQeDHOIN8KlGVSXXXWFdqVC6qwsCdIvX1SKz8Q
vE33pERUbjyBViiCCyByY6lCebJanEeGRVtbfX1nemlxxUdeFOQBCgr0YLljHL4EFu0AoyBIcuv1
GvqnnEDyTdE+7peJHzSgVzR0hfX7I1wf9JfWB61YHzzXdQVPkfc3Pyt+Mugefh1d4YWaXa6oGjDH
p68nA2DOzpiDieSCaYxXDF+vIAOt2L5m7Y66byj6M/aAju0Gu1mT21ppOK9BqbMH1oqt2AOaMAZy
e2CtZC8BYUXqGhJAYQOQhsLSKd1lUDnHOE+4ORv5buq+Ei4YEHjhkWPzVwKoqLVie8TuLL+TjqyQ
szCQ5iHyi1/eSF2EknBZa/hRt+RKEU6CbtUgXNvinQEl9LI0FC44bOKwB9xvxqCzJTK9HiEVQ32l
cO/Q5xyMKGIChDgLGLI0fscbLYpng/OzI5ksAnY8QtGFPoE9wa1gUrDctGicjM7ZfqulMLqPBJVC
oKNTz45DvF+H/RL6eEfSF7ouQasuPRyeXNxgpEWv0XMc7AzFZCm3LLkzI8TdnJtxE7/QL6BRDobM
ReyFePVHV+Li/oE06XK8RApxJ13DaCvt1i1r/FX3v8/wJoKJm/xIHLiWtBTlp3xpXv3L1bauaT9x
3uZtvc1BOvwEup3G1Z+Y8iMbVfxkaHUy9hMGqz1X7qX3/09/jl0LVWQOchpUh31Ms0Hn4WNpmv3r
duZPfAa2NYhgMBpksPIpGhPtdLmxQdVy2ZRit/QwdVm/DC1qhlHaxIoU4NmENR5vK2lW1mOSNDMD
IFa6NkSSYBmEAouVGcBYsQKG5xtadoww2fvC/AIiEuXFvRl55JSge1DEdjMZ3CQ48G0T1GfclJId
i16/ZYhX/XnfRAQMoY/MdPoGyCbdK3STwRogRucNsHCVxqHJ+73m+cWGvxlFMRA0A/ls0sbC4HN/
7abEN2ApP94UI1xmi6Mf6e0dqUJR3r5OKK6yj2gOfbx+ZyywbsVmvp0GWH4MeAude28F34sin4KQ
MU4RL4AFtbnppnYTZJgoVrCYlNixF6VJk2LBpZwy3oscNm/HX4Cy7Lo3tseT9+76MCOzpLjGssua
ieUFiEtcuoQUis7BWZoxbihrHMGVt6MCDGkY+kz6VSCbxCFq/8wXf98VYZbEAmk4T6S5bwaSlU0k
HGUzJuOOWrA+oO+AtMSZoMddktBrBJR8oFKYhSShJ1zyaA2T4K/k3tPtpI7rS2SaUruo5Mx8EG9R
/ZasQuRWvaSa+esCAMaq53dS5W/oTi5J9KA7vUOX08GHJw6nD9WVcV/uBp32B6BlBI7powcZSpKF
4lZhuskJK3ejg0IgWWhMQCUrlgCDhHo3mgGS5xQ17xOp4IYs80Dw5E6F01LBOBOvN5k4EbvaZR1F
lflv7NuX3hkb5S4AsJc67NAN2KfYdUHR/PuE/lo/g+GDFxCCZTTFbZD/3AZRz/fxarAkN5isBzYw
59C5kQxGDYVe/d0x5+5saZtlI/glQXXJy8Yf6cvjydnx+eOSzvZ/nP4+VBHgP59S4D8//BvRoJgL
UvIcMXv6YzimgG8xf0LpKVZdBna4sMJUTVU6HT621dehMR6FniOwiJsMnUL3KcYoYGKD7ucqLWhT
TK1KTMs0AXhWEL8OT7seTy7N3wNL57EsJhDFuZwH8L+7wYje7NFtgkQejNs2H7fGqqTYLUvSLcuQ
LMNQJd5STb09NkzLsl/XlP1VSlmmEaFMiPM28DM228p47Dpmq+NsI7ByX1jBukF5HGHmJXYWZgnt
074CIk3IW+Btq8WA5rL5rGNxDPzosm0r0qGYITZK2I74AAzHTeo6U9v3XDwzgxbO4GTUP/92NESy
yocf5lI1DHnpnyDuVnux395aw8Sfm4u6XRlKTerRVrCZAiSFnVpRssfwiBFzMjxP8h5ojjF6zM7D
adDTKyzHy9/Jp5h/G/6+hqr1w8ausz2m8+NjQCPim/ZBiWh1ZK4AdH17UMOj374ejS43avP20Hv9
X1/bzLOjyyujo2rXBTMVkHN7hHWBUByStWS34Klffy4jU24CfkOWeaGPFintMGJL/UPCpdU/cO9M
RMQ0va20ioAUebPW1TgnMMwl/TEW6w9ryV+CdGurtbol4iQbrG4g06X8h/yZQHzFd7YtIIoKo2aX
T4lutwZEy66Nl3m7ccKKdq2DaVeBQZaemdGVsa9xYLHzwH+gs9P5obcv5+cXh8i9eQTAf2wCs5C8
w4v+yjnCzIkw8CZISI6Io6XrbLAVwNT+AQDPjkdzXebMMu3b4tzqq5DEkS3jwUjnqgV6Gwzut+J8
pKzI+2yUh629CtQE1jBQ8ayHAE8junEMa1Xu91yr+yrw9IUVqiUGaoVhKmMI7V2+YeV7VjMYJ00q
2UxmdEJyGoZ4stTDs5HobM8A0ToVdqoa4N8luEf3RZzQLw43bVO1GE2G7+msq3+HF49sgx2poNCl
3cCJQpA/i9763q175yVuU8by2wN245p+acZz/ZpmQtJRJDA0bHTy6fJoePp6GH7Rmi0gLHowpYMw
AObV+Auqyicq2QpSGkbRi7P8fFdKGgspJcCrqm4/jRuR5wZz8Dry3HByq/tVufxsNyHPg9hoaCpB
FHL8zowDyrfw30FKyuBHlD0J01QM4WI2GKYWHjH34NmO705M+6GMtvEwcsndXUNXKSdz4FctTTVI
SroRxd0xUZCpSkduG3KnI+voMkYXkQSi3ujoqoJ636Y4EME+IMDPTJdVWY34z1zmRluRQjYCq2jg
2niiDqwao4MKwtfLPp6b32c7fOOeABZNASwRKFcU8coOKLYHd7q2aitBWSHPxU7onec7thk7e0yR
6b+/4bmHQRG7/D5I/HCPcbVNCDghOAreE77QGvfWtPu3IMrzFgjieQhsWnEpelxXtoUFugBqZxgF
22Uful3+AZoOFqXnkBuoUN32mDcJwnizts5bwJlXFFn7+PT1o/L4eGeiJyicXLOdobtbxOBjRYy0
2QRHwbxJlkQuOktczBXCCp1L19aAVC6xuP/9bEsxmAn07Jt/uXFY22qE8rTZRqVfIY/UksjDB1wj
ZannJ132fSn6bnTKIj+DxYL5c1KNrJW0NqtY1Gf6RZrdy/0qVFjEPxrmuBM26Lq2Ne64LUVVWvuP
yewGwySu2RkeTc8DAZfCCGDZyBuPui9MSYIZdGM6FfRAx1XoULtwrG/RCRLPL3fCsYgTdoQ5f+MG
813ogTJuadywO9xSjbzINcaMRbhXF1p/YJze+w/oBm2Zun4ECv01Oy7PhI0x6VThUnLCmQkEsENe
2AOQzurY7Bi6tN/RTEm3XUPqOPq+ZGpK2wXAiqJpu3/NqJY9+V4so+697UYUTPHx5AzUzbPel5uj
4fB8iHixv2CH73zwgRKo9CxKH6D/QDIfdtn1R7BH40TEpgOhYOIaPPYBFnzsMHSIpFksvKRZTGZC
/gpTw6BFvMkY1DFhcWx3jQOLQEpmjvFkCGdNPHHHkjVUWhWqtVgjdEG9NAMgqqYuiBYLGvdYfsqn
BUa/pZgdyxhbhto2H0kIZdF18fpqvcI1MOETrez92tp+XKPYPHJz0NXHjm7pHUdRLOtpMytrVbdV
//FBXrFLoatvQHyGodIJ6UGYLXDiwWqEakDuy6cUH3tFEjkAIr8BF63LJBi85BU7NFvh+hrcBmQ7
Lm1v4vGM2LOyFN6LiZPIFyZN57P/LVTR/AdisiMY3JsxMBEGDeFxjjVklebEdkt75rjzl9b2rdBU
CC/CsSa9lBrpVYnrRfZvKbRHL3TeGyx+s0iwkqtk0zC8RTsJc8oVO9IYTD11MbGfiLrLGwxLS9s1
dF13nXar/VRqvCOualnzbzixldrze8fIFrLvPDL/zNyhO+4qrVabj3lHcloul1zDbUnm/v7+/7B3
rc1tG0s2n/0rprIfLFaZFN4AqVLtlWUrq4rl6EpKynsdFwoEQQrXfIUPW9r4/vftHgAkSA6AmQFA
Ko5o60UCfRrz7Jnp0900LU81HKPnwwQGN07Dfuqmnm9YpoLpytq21dR1y2zqttlv9kzL6jqG43Tt
APem0065JR637EAqgvWamteg+/XlBWkrqm5aAcBYYM7Z/Z7XNPs0fbDWVU3FazsYiImeM6c48lAt
eBxWpn5FHHSFJBc46ArJknPQlSoIYQddIRQ5B93SEFsOukz/3NIg+f65FYnP8s8VEp/pVkE3lAVq
IOVYIXor1zmx0FPV6HVckx4HgBQ+v62mYXF5HVcBJeR1XBJQzutYcFSOFktxnBx1P6jPvs778DP1
+4bqeJ4Dho7Va9ptU2l2Dd1qKoHZM+Av2/cdnkp8dhf+LqqxIhfI4pk660bmeQDnPM28tyqPOB7p
XB5xbEHoEWfbSru0R1ydJcjtEWe3MzzisrTbv0dcbZocBFTcohLRpORuY21QO7uNVSIV7jbmHl1m
bc0ZhkmW4/CheXN9/u368qKV0skNp+Smo6kwVju9nmb3rW8o7hM5g45Hs4B8DofwPL1hQKIuSeaL
JZ6rbvvbHEw33G/48hS1Q4J42B0+0hzvC7oRCVWKG3QgZBzQbZJtNZlUx0UwmiJVCzcaA5r0AcP9
/XuJW1bTwQwjYJzgUWZy3arvzoI/luHWnqPRUZh++yNcbaN7XofcYe6IJEh2dFa7cuFb+4tSX75X
ZD5B6NjtIJovsnCZM/QDDitRmoTb2G8osdrQHWn18fEHjFmJv7Wmj6TZp/CCAL9S9S5gurzG8/vY
j3IerzI6RFDcx7ezGTy79ome+Sz9exoLEGMvrk67BSWiHKheGosQt3NX0cma8aZUnKsm+nxLOLuJ
r4W/i2KlxDvlUTwANPvimqbxCkPM0qPa63CHGxBs78R0DaaUx7LYvF1jeo+l6wf9PFN79CgrlRZG
UNq7Ce58ze+D4XDzTp15QpS4kZQN1GxIgm3ubWaFnRWTLRjaSkA4bxQsAZEyAbPqKI50bC0B+Vxh
uDblMVtwujgqDawlgi0Sg2tTbq5/ZTXhtkoBMiNzlZLIEwHrKQGkwnk9JbUEg4RtSmZOrOhjgUGC
hzgRNOPIwZFtRN68/e3y/O0p4JCz87vLX96fwvidFmpluMakPSbRIwoedIwpRCKWy/nZuyOlAVbR
AsbxJYzbG92jnWF7oTc87lJ8dBwVl+PzDUd3mnYvmqNnQXfL6gGRzFFp+ri4x9iz129vLq5+eY8H
ulAfYDiEg3EU0LiJDnjbxBEQxxwYaneyEQQu5WQjiFXqbFgQS2YHusY9uyztK9t6PYDuNWw41Am1
ueFQMVL+hgOA5foCCftKg25BiCsEHHmgjffAfGhRL+I4qhuNvs6jQjK000VMQsHJWiu0MxZe6aGc
UiTiAZEGjEjGSR5BIhwrIRlMjlWBhAKOlRB+LseqSBIHpafoUXI4Vlm37nAQtye+V2Q5bs5Sju44
X8Q1vz1NMBGYHN6krFkc3nbG2jyxfH6OSBzJbHU0nU38RvLQ2ypxSoLlfIAJOeEZwUbzWA/H3Gsq
6AKa2tHZJkxhlMbMWw8epVFUM54ojaIyK4nSKFzE3E5gopLznMBEZUk4gckWhJgTmCiKhBNYFRDF
URqrQMnxAqtOPNMLTFR8Xf5S9elxAEix0z1RPUr4S1UExe8vVR5QwnOpGtAn7Pbyd/BcyqzEZ8+l
76Iaqw68WQhUMvBmQXuUjN7oO/2+6snBlIzeKIBUKnqjAE6J6I0CKHVHbxRQpXT0xsJWLxy9kVci
b/TGyqwblgditvAC10W8kRlYgMPxLvPeSlwXUTqTbV1txEZpGPGIjQhVX/BDTunFrp6ZgtDV01JM
rZyrZ6Z4zhZXTfBDGLZslqtnjnZ7dvWsU5ODgIovBisJfsgliCf4IZegqGOgk4MbRhvC2B1oSldV
WBgGRZksMKQO9fvDr69fw2ibDc+cvyvlisNGZopJwkZaqmUJho1EmZWGjRQWWBQ2UkqgaNjITJDU
QYhm6DxhI/lFSYWN5BdfU9hIVEAybGTRrRzB5wrRZePy8Qlmx+XLvLeeiHgIxzx2WkfEayusiHiW
1dI0p6WjCaWlYuIZhqba6lZMvFwUhDCqiIlXiGLyxMTjklI2Jl4ZEJ6YeGXkP4jExOMC4oyJxyWr
REw8Lvl9dJWneZfXAUx6WJ3owXl9lTr6oyPeYnoMyvQXmzAGc/1YYei9TIyi0HtbixODueasLfRe
JmLNXAfEZfoO7jjl+bFvwgQTObfoPNqBYUZV8UQyoYjMgj4MGr0GjXm2et4PZ9eXiQ/cFjbTIbCi
QICmEig9z4Oua/u1BQLEh2C6OcnEJVPyY6j1LVP3en3Ha9ttmRhqVeqqtTNjqGmaZvtB2/QUTZOO
oZapa93unaLAZdw7RbHKuHeKYj0t985M7f8C7p2iJV/CvbNWqA33zqqRct07RWv/7c3NN5j9PgeP
5Met8zc0ipLjujgI549RPf8ITX24HI03ju+2lGCT4oqomapdcbw5MOXavuEonhP09xxvDkuBaSpW
RY4EAJNpwMmRI3nEiZEjeSTy8xcNlcFf1LKyVqzYF7Zj2ULsCxCpMbWWY1/wiwMD8SaI5mLK+p3M
vFk4fCTL8YoyKiX3bgZjDNpq5GiE0yI6bKM9D42fBuFtbDYDbrmEXGDl/8iwiaYwsI0m4x9f0Umd
tHVYC0It/jf1iJv5sG5Gk+aoUTew40TA1IDClz/CcMvwHa1zZH5/OYI/Rt7DMBhLarM28F+Rl0UV
+HIHJOO0r2bTTRC4lOkmiFXKdBPEemKmW5b2fwXTTbDky5hudUJtmm4VI+WbbgDG3GDYHzMnUwUR
Zk6mkPQWGQ8zJ1sbfmaOmAwWM6dIQj4zRww/j5lTKKmYmVP4KNnMHLyVuQO1c8wjy8zJRBBl5mQK
EmbmCEgqYOagJOZRaVEXMDKix3Awc7JuPTwzR1AzLmaOoMxqmDmiRczPzBGUnMvMEZQlw8yRLAhB
Zo4gigwzpwIIDmZOBSh5zJzKxLOZOYLia2Pm1KbHASAFnbEE9SjDzKkGSoCZUxpQhplTCegTpnX8
LZg5WZX4zMz5jqpRktDS1RX4LgdTltDCj1SO0MKPU4bQwo9SO6GFX5XyhJaqplwm6yNLeOVktCKg
smS0IvnitB9Oidy0n8x6LGLmmBlxvnh4Eln3VsM0AenMXcqKmTmyMBLMHDMjAFpl5cUhnYOZkyUo
YuYYdklmTpZ4zhZX8Ix8zByYuhWHyczJ1m7fzJwaNTkIqOBiMEsTYWYOjyAuZg6PIG7yC48wEfLL
X145DmZOlpgUM0cVZeZkyZRm5ogKLGTmyAgUZuZkgaQPQnSHi5nDLUqOmcMtvi5mjpkR15CDmVNw
Kw8zpwhdmpnDJTiDmZN1b03MHDMj0uKameOYQswcve042jYzJw8FIdqVMHMKUCjFqJiZwyOlNDOn
BAgXM6eE/AchZg4PEC8zh0dWGWYOj/wKmDlmRgDJKpk5WRhCzBwzK3lEbcycLMS6mTlmRtjLfTBz
zI7KdnGthpnTgwG62273NR8ZInUxc+AhcklcsjQc0+6rPc2zfMXypGg4WYpVS8NpG5YRmF0Pvuvy
NBzQlRm4pHZfTkHgUr6cglilfDkFsZ6YL2eW9n8FX07Bki/jy1kn1KYvZ8VI+b6cgrVfDw0HlMh1
KM2m4RgV03D0drdvd7u645m9fdNwTFxUsEqhKhoOB4AIDYdDnCANh0MiPw1Ht1k0HDOL8SWTB4xH
GjsPmOZkeGymFwGCCV60NogVlakpsHp2WpbZ0u21XO3FD3+H1xzWWAEURAuMiLow6Gm5ovwQnfBv
/1Rt2zJ+UFVbtQ1bMXV4X9VUTfmBKHUplH4tcYgj5AccKfKuK/r8L/r6qEFpK5pq36k4BXWgIyi2
869vvaC7HGQsjvFdGLdgEp7G+bxwRsAkm3Bpr0l9BKLJ/bStwXD2c/j6BROnLYKz2keM3beH6U2T
pBlH+/6YLdWNLTDcXVJ24A2Ab6uF8JPp/BMuJsBeU6J8n14PLluEc5yBYOk2HE4APcpbd4I0vbA7
ox7liXUT78edwv2sYjD1lm4oIsVwg7sioAg9kYif+hgU8cZgFUWgx2Cve3bP6zc9y/aa8Eu36Xla
t9lrK1rgW0FPaWsVqII1AJMYOV7pAW8fzyIF96VTDLOqrejEzsVG6PZnAZh70dIx2YzAv6E6Mhum
BORisvCG7oymNcOKHniwqkl2NXG7ir7xEt4Jx/0qAO8QEDfYQjSn4Nf4GSe4H9zDk4fQd0ch3Vk1
HccxFdr6TnBbdEi9zdIq4ua09wXb7HKMDTqa7+kdjSq0vfIewhHMqNMJrGQxfRxWS6Jy2CfeOodw
tG6frzsWWvUwRe88U9u2VauS5rKczSKzFftUrBjFsEGwQUuBHHkhzbOHfS5pOI2TE6p5vNUAg9Mg
WGDGX5ox7wQEfg2wOrwkG7HXowNIfOEJBUOh03tvHlTxKBcrnW8VcqOQO9WyzbbuOCdQmXe2rSiG
Q87in1cKef3wpQrYD34rKgMXGtbIe8Dyo0PmqULgz1PTNgzLIEdfvflp02C0KAMg82ecijucOKB4
h3Mq63Di2tbU4TSjCuWyO1yEkdPhktP5pMwIiFwO7vP7YXwxXXaye5r4M1yslGX1tLjBn8U/aU97
qASWrkBpZnMst6RgyKQfV26HTKZBTP4JR6vqR5sIiiYp+XTdDqGcF5iCNWkBUX7PqFVUoXP8d9L6
ol19WMVHFkPrnNZoNFGDknN3BCvkeMo+cl8Rd6tD0IhiLdUUslMkLNQERzuMhUpDw7QM3araMlR7
bcfXlW5TAfO36fTBHtODLthjjmEFjuE5puGxVbFrswzr0qlSyzCBFGv9tS0d5NQpMW8mgPlLtnLz
pmpatlXJvCmnbR3zpmY42+saOeWy501La+vxTLBvQ1XuUS5WOq+mT8sBu9TgNVTlYEsZqghptYyC
CaHiDicOKNzhHKOyDieubT0drq0wZlNx5XIMVYqxX0NV7hkuVsqyehqHoSoJe1BDVU7nqg1V9Atq
OY6QBSdjqEY4bfNAhip6fbQcS2jHmMdQ9bqG2bdNtdnra+2mY5hms2tZvaZnG2YQ9Po+rAEqUEXI
UK1Lp2oNVSnI+gzVWB2xqbrMvCkFKD5vVrPBI6dtXfOmUYVy+Yaq5hzGUJV6lIuVzrKGqhRsOUMV
3VlaoOU+OxwC1rmjCvXQrmhlKKVtTR1O3V4ZSimXb6iq2p4NValnuFgpK2uoysEe1lCV0rm8oZo+
/0eP9hpdP+gr3/9DM1TNXPt/aPYPiqrYlvns/7GP145fht0ynQK/jOE0+EQuY8c/jOOx693BIeV+
sZh+Im+h+Lsg5R4Hp1/H4UMy7MTsJhxkaJSrtev8l92D30I8NdY68R7EgMroeN8EU7tHHRojB8fd
Iw+tpeYu4nSYcsKH5s31efJIyfLmT+iii/sJBjG+/uX27oQsZyH8fnxC4HPouafkIyGfTijdHkYR
dxiMB7DiwrdV3cRPKLmxD6UQjP0JJX6ekhPyJSYr0qkPb598DgN62ym9yZt/ptfNl1383YWhCP+M
YZqLx2lA30AOoOsNcAA7pV6Ex2qrTf7DLoI8cyJdBDCe0DXlJ1ptp1UJi8uUso7cpADeVyd9Pp3A
tTCKHoFEpQXDkMr0fdDsvJMno462YKr2E2oLWAR5flOGSFuQE7ZqCx6GbHODyIQkf8a/uOG4c3uE
81/jZG1f4rt/xvN1ckv6MqSqwd9o2QzRkGqcIE8T3oEaV5TGSewIDW8sZsug8Z/soskka20+DZTx
J3K2wNjji5jSTZ+HvESdXpLksahZGRkgn4PHVtlCpLDvQh+vo57InShCwEOK00I/zH6+TFf0FFAs
ZA2Fz5a4fyee1LHxSR3LhymVsh9SpGx/QmJvtE+xVaSDGWVvRoivyNf70L8n4yDo0TgP3SApc+pk
TXSF9LzHeemS3x1sVi0W1rOrthizFOb0zY+3RxhHqHFye/TPyS3+uL33cAcIt7Cgu+I715MJTmD4
65UHD3w/GePva5Yc/nUJ/X04DM/RhG98SvcLhPlz/nnp4liw0iIeV+BvC+mt0P6DGcz24+WoG8zg
XXiDEvOwz6jQV2aT3tJfYNhq+mHwMA3BeKajqaboqnOHoWbw/78aJ7T44bPxpHGCJHl6hz8ZTb3x
I/097o5q+g8tuipcRJcg0TC6EWxyWEmukP3JcryYxRfBU428GagJ5ePGUOfhYgZWxockplXjBJmD
s9CHeSUKQ+XGLLIhfVLa3dfXDL3u7pugwSBgvU0rCWrnc+6H7jxcBC4SRkCfx91LvwZddx4M+wmB
vugCNwrzO8scrNodxWxZBZ4c2GQ/IeM1oWLGIbtPCCZumMzoctKHdfcYYxLRlrbTSQSAkr3v2zNC
yaO4JmOMBXwSqa0XR7cOHvxgGi3gxoQS8ty5h+FTg5MVGA5D+BFMihnANANfyzKNUqZxLMUqcKao
zDTmwZMzjWmau5aZ68L9nZvGokWQaw7JC+MxjctILzaNo+N4Pfc4vhbTWNdt7Qk1BpEyKGwMZoEj
7lOyjZ+th+/Yekg94dCj7cIbztNv/zGZM96dglnqeosF3TRO9GVcNw4W0FZ3waAhe8PJIPR3P5pG
Fu9aWEA3Wd2He48BMIqNYsZHwQjD7HrDgJ6G7wLdh6g3Boh3Y5sHd14ZJThkVOsMJtHdd3sjxps0
QBgNasT4bLqkjGWmgv7KyF8/3XToLVBVF6yYxUY1DpZDbwYteeD2QixbRg2Ppox6D6PFA02pwCjF
wXTJeM61nIKlc2qw2+fSWXyMlVw6J0CHWDqnsQXK9i1GHUktnBME6hESjc6R3RwP0PadpscDNIEb
hzQaZdDvQ9PMVuh52Vw48aXK9XniO/iymWYYa7XbBdyD8stmESC+ZXMikedgp9plM3VPM4v4GkXL
5kiKVcDGqG7ZzIEnuWymDiGqlVce3/uyWbAI8ldK0sK4ls0lpHMsmyPnICVvL+u7XzYLlgFHY3AU
8TX4d7lsfrYenpfNz8vm73bZvB7s9rpsFh5jZZfNqefb+7JZrmwlls0a57K5xMz2t1w2a88T3wGX
zYd2anx+cb+6mD6gZgfgfP9fRTHtVPw3DeO/qZpmPPv/7uO1jp2o6hmhJzFDkuloerkMSegwxQzN
iOJtW2mXTMCkdvRM7S1oVjXldyqTPurQdY8vDFN/2P6vGqatpvq/HvX/Z///vbw2+z8zPH6SyWAx
0OOccT6YVpgzLpz9gQkw2uQIvjUot+jq9vIYvpofXlQh2UHJTh2SbZRs1yHZQslWHZJNlGyWkFxV
aspCoJKpKQvlC6em5JXIm5oS5e0hj6M0jHgeR4TKTWQimjNMWGBRzjApgaI5w5BMxLQj6sn6RLlL
Mulj9LQQo6PnJlNbzrtEa6otu0PGwVdyHw7uCYiFIvr19nXS9KOMzMG9H7r3fo+2k3g1TAxJsI00
iOS/VMxDNoehJkrViX8BsKBsf4IR/2frWsYnWudMisIUkGHYXc6X3lBEeHL++H/04BAK5sqDZ7+N
Vs6x4FarJSISsxIaYALent9ekmC0HMbbUdD5dgFoNcxrKQ64sBlvAYjI39ExachrPKHiSKmxGnH7
NLUpjIWijWwt6asXnYFjscZSF5g4ZbEYBqQbwNvBKgXPFkhugjesPWJ0FPqPvKHh+ptnNAw+wRdl
mIR+k1xhMqTmuTfrkehFOenX/+wQhZy9v73En+fnt0LYvTXyWXwcECk0iFDJHMwEetimbMnNHb7S
cj/Oe/4nYjta24TFjanCCPa4wLRmA9y7J93hxP8875AjA5/mp9fHesvWyU9IqS8FiC4LAbmeTcC0
WNDJqd8vJ/EKJmdyG9BtTgWNp+h/OaFn8/mSOmvQPkSibfzIEwKP9pEnLwLAavvYKDEHDsz6i+2O
eVhtMdkpwvjqk1KLAZD0DTrEzoLR5EtEuA83krwgb4S5+5BI/jnKjJekUjoC289vEKiw6XRrkOOX
lIRXgoESyoBS0TYSNKkdvZ4Fl7zkogWXvOSiBZe85KIFl7zkogVXoeSqFlyFQCUXXIXyhRdcvBJ5
F1woj5mlqdoFlzSM+IILoSpdcAkLLEzSLCNQOEkzgOSOpxWn2UVGXOl8nXpG6iLh2URAUtFsYnRM
ZmbN8rOJtOTC2URacuFsIi25cDaRllw4mxRJrmw2KQIqO5sUyRefTTglcs8mZkfZw/adNIzEbJJ1
QCU9m4gKLJxNZAQKzyb7T9oumf350Ac/8eth2OqNgvmgtXio7XiLnv8ZRtb5n2bZSnz+Z9mGpmL+
N8W0ns//9vE6+vD2fYO89nokTtd4SiYR7ePlyxfEdQn9Wr9c+j/65pIX5Hfy+zE5duEiN7ryG/kG
/wk5hm/w9YLAJeT4GD7+nbzEb/EVLv7Efy/wWnzfdY+T96gkl15Grzh2j393fwcU+jd8IZD77cht
uPiFMgpeL6IH/QAzZeLgDuMKjCxHWLH/CMCYuv+jtfJJxCmtQY4Gvr9xuUY0RXEUGwayoxsYov4H
9y3x/aZhNRrkbonbUFOi6kRVOyY6oZG3b+7Q30+NFXgHQ858Qc5piN/bYNHBiJVfvHCIuxbxNa9B
oyEm+Zx1yO3/3r67fP/rB4BREF1Vmord1NTkgc5TmaA7yHRRMNbfqW1qV2A0foXf3WAUzAbB2H+k
HsCn6hXxZ978PhqiTi3j6h86XLyq/i8D7xSny6byoOgrvX8Le8GEOkPORnQTuxN/QH776QynqMHM
m96HfjTVEstQHgxHeUVUi3Sn09W1r98ev3lzHlMX5h0ynoyDEyijyzdrNgJGm8Yd0yR1aXwvvQgV
iDLRB4tZCIMqWCeB78GwjOnnUXT8AY0oSvkRvQD3GYNeLOcNmATM57igG9EauXp9Q+bhYBw5Rm5/
+vbNm/TdmC506aevhBbWDBxNITdnV2TkTVfyla0Xaabfagc+hjFd0nzCDcY90QUb93hUzFESLZx1
V7CDpCqFd6nb+nX7Jga5zdZvdcHmPV4+0uqSjbt8k951dn59Sd7/dsu6K7pk865gfRdmwGXeFuzc
1ncKVYwu+X/2rr05cSTJ70epm/uj3RMtRu8HF7MR2OBuYozNgtvXexMdipJUsrkGxCLhtjf6w19m
6YGwJSwworW3dke0MarHT1lZWVmVWZmbtawXiBEXyNfRReulnpIiG7Uk9SViJEU2ainui33FRTZq
Gf6LfcVF8rVM/ruUFj7zpCc9wVequB2f78e/17Wk9FF5rXWRrJaqlOD7w1vNFm2QUoNTcqJrmqJ/
O32PGr34IMdVk4JIDFBKx90htnkuqhrINIxZCjhk0rnojP/ovN8o+2UMAv/0XDvTYJnAstoZlJWS
srgUdciA9Amojwb0ZZHOoB/bjOAVlM22zuEXb6srSSa2dY79qnu11c1wSRq0ZZyfdnPvkGsr/hFJ
//L6Apc7TQLd7BmuMbSli6fnJn9HdZNenWH/LMYtS/y5IUNfyl64xynurmwiDSRRjuk56J8NP/Na
w9HVWYpbgq31+TUhSswTm20Nzs4/xm0pFselvDA2cVv8x3pCg07nPMGldHlbXSXf1lVvwEtUauvT
sJe0pXb4OCvmizzTSt9YfTLOg84oaavHcZ2KxW2l9OLjnP6VtjWOc4nDGtaGJVzRdZwoaZY7mCvp
YhrfrL1jdJHmI+dpAwAE+T7xojvYVxHYV4UbEBX5N139EnNR6mIAO/UZplvHTdZ5B4ZcICgRUcD8
Jj75+ZD4Kihy0uxwGaBRFvbE/ykSHT19OAemmpssPS8nVyynViynbyvXv8Lv/8Tk43QxcW1MtfAh
K6bIHzIyiA8+rvP8JT+O+0QUZCVppIe3tfC1eR+oZbVBLZnSCDjhM6cHjOVvV/xxSu9rbgsD7QxV
Jm5p/490gPnlgzj2NW8w8RR4kDlCd7rCXXgrKR23H2KF1ZSrpYMhOVvijRIyTr8lJy7/JmOORPGC
F7TklqaLZPDpn3gqE9MsbZu7XWTJJEh4R5f8aDN9GsF++eZa8Mh4HgQLUHjjUxF8o/gCm1dQFhhT
5Fw4pGGYGBpfqPK3FVsB2P4cdMeJF2t35aXx43K5WkRkxEDLW3DfmdLS8T0a0hteE7yczsJCLDB4
95NltMJJtNF/utIJ8XvFYz9iU/qQPevFJYnHvRSwr6t+ksEl4CNK3W92MMXDo5QFepedU9hbfAT2
FDgL9Ed/y/Rd4a/JoGOdztkfiTadMn5yWY7r6ktkMEltKZKJA4zCLJ3uWSj+ZHdBlrxJH8XCH5PT
9M1vBl/a6YkmJh3x7vHCoEfS20ntNQE40MGgf0Vo7IixSbEnBa+HI2QoL/i+ftB7iNgcjzWH6NFy
HQ/HCQzN+3WZm7hRYT3B+x6bRxN/AnOWnNwM+93npcnloL/+cjAeJYMhJEhBDgKnrEt8nqdXagDM
R7x/nA4MsEly5hQSGSQv/AFUXgDelGKfbkAwd8b9bviUi/gTIOgT3uFff6JL7ztwIprl8ZSN04Bb
59OpilvJJw2e8skT4ZGnSmDJzWQLiy+7wVuT7yi6veCWCIKAZUAMB9/oY4t/lnKf5dxnJfmctPfr
r7+Si6tOFzmyezXo9C9BCYEvU4Lh1j07V9NVPK77QKah84F7UNAoWw3iSZKWjA/2PpBhp5cUX6Cw
BUmbbnP+Cp81X1srfcNPfx/3zzoXZNAbXI3+TjqjUefyY2/Qu7xub/TBMyG02iSnI7P4t/DXtYqc
Kq6SqRuSyocxCzSbTpCMm1AatsiSztCBoZ1TZCWN5tvNVNt0CvVH15+3Q77AIwUvI0wK0E005zVk
V9wgRwmmrFi+oms5uYrDu8dQGFBY1XEjTJ4Wy1f0NCNXkQfV4PvsNslRNy32pKLqqFmPOKdjEdt+
UtF8WlHXcz3imQts5kFKPu2RF9usmId6fXXduWhn50zrYk8ZwU02KNl5xuU1DlS3O+qNx8+HY61h
ieSOhpj4hacgUclNbhKO3eXKcXAanmMCC66vtRr74wXzTILhdI54IGZn5fsgVtvos5MXWePIawHT
3k7ZPfJrb7kMQPiihEoO8VMicNmZK3kZRDz4y8kIppbAE3Lg5d+CBt7nZM+Y3zkFplusIhQKIINg
0nIPu3dn16MLgb7jIV0YX/T4DI5vcCZV4G94p7RFHA4PNEDYWHLNOFFv0re3bZdrU/Y9XlSHBYJf
61xGbe62yEVyMAP5BwMf3TFQmib3kym7xQWeq9wHMx9k5/+x4tcC6rTuI8FrpavAAewCyM5bzv8V
WVzn/zBE/S+ipMuq9Hb+f4yft/P/t/P/t/P/9Qm/svX8X/n3PP+XU8hl+LIC+TrySz1lRda11Jd6
ygrk67zYk/q8J4N6hr6tp6zARh1XFrcekmdFNms561qF1omszEY1X9v+WlmRzVovvZb/7LWYqL/U
U1Jko9ZL1omsyEatl6wTWZGNWi9ZJ7IiuVpO/LucFk5iHsjV8WlSp9w68XNtGobPCt+qbpuG0eme
yQeyaWBbHW6HeL1Ng+NKbBrnp6+zaRid3labBsctx/SyzNfZNOK2erFNQ3+dTYO3pZwfxKbB21KV
g9g0eFuaeBCbRtyWynH1StrawaYhW4lNI84zub9N40HODuRRD6JTjC71mJ6iofPkaf9q3Np4oYoW
EJS6bxaQzALSIGuGDjzwZs14s2a8WTPerBn/f60ZaqJ/rg+xVTlVWV9jzTB844k1I1Vq36wZb9aM
fxFrxpsxo3HGjLefnX8e2Py3uvtAAWBoWon9J/4sSbqi6IYuiRj/TVQ09S9EqxsY/vyb23/WFo/6
ggDiAJfF/5NhzYVBT+1/kiyqeP9HNuQ3+98xfp4mNVbMlqZsza6a5DWx/8mWwY/4qc0XhW7b0zRJ
l0xDg38/kvjlX+OMEX+mG+MwWvErcJi/4euznMqH695bzWaP2PUdm8J+I4FRhAJqap6qiYbnMUsx
COz7+S7PeYzrbDZcDHlrYp09KfYFNn1k3Bvd9EZkfN0ZXcNeooRiB+m+mGJFKKCmTz3qWVTymafU
TLEKCH488ADswdwO+SGfjWGNf8dw1IQnVFiiZXNG8RDoeOM3pEt+5jCZ491PPA3CUPPFI7g1Dd0r
R7AYB9SlmmX6ugn1/b24/jCgi+REkgWK8Nwp3GLm0LCMdNtyyR1CXBSDgQZ0x3Ak1WeSqOt70a86
8upAfvCnnvMV9hAbxdbprniJlueA+s3C+buIJElspo+EYQqDFj+WnMxX/OTyDfnLyGPxc0dbdDlj
mJLpHc/28Y6cADt4zKerafT+iHhgi30XOVP7YTb9iiS5j1O1EC/yfsZ45gjD6VKMQalBmuApEQLt
fjobkikDkGGJFDlI78VSpAAEVHR8lxkONQ2X7Sc91C3ZSTYRvwyAc7C98u7chVeQAhDT6LXwP5vh
ucOJLH4gvwQLNv8Ffq+nJ1YX4vZhkv7ynkyTjsuKtOMXxyIYtxIz0zymAFOuKn35gzPLiMVoUWVA
76Mli0qY5SC9FzNLAQicVzqVFVM0fMvcS92qhV4XSXgjHNjMloccWUI1rc4pVgIF+dzSJVeXmGia
zl60q467KoxkwRjzxjbD5LaPjCFJppOmQGwTnoLnJ4FwlhSDpWTpco4Mw1lNpp6dpB0isCPU5cWR
Idzd8iAxtyxE39Ajd57xgNRSapzCT8TIGaZx41lxE2N4fCpcIkT0+oRICRCklaZbqqU7smnsJ0L0
ymt1NRDJgKG/L1mtJt7aeyS2kmdbPUHIDuGBDPHxe4D213s6XZWsrdVJ/C8FtjpHjhMQ3A14SnhG
X5gaJRxp1MeRJUCgsus6ime5qqx4/l4ceRDUJXRbLVJGiEMtRhiB+xt7/IkULIUEzVi+ZRigBou+
6+1Fy9rOS9N9Fi6LwYzEK1McAZzCG5SQs8bTwCqooCXDU0RHNWAj6Kv7UHR7vvB91fsVjwBPkq8J
Tx9aTMLD9F+i4BfBwPNMUXF9U9V0Vd2PZluzo29grgIhEdqnkzkFyUwXC0aXqaOHGyzRFWj6iNdO
vrHiM4Ud8OyyRYvDA/KU9yOymK5AvykRK1qNW/piHFCXuY5vMl2URd3aaxSrg66E4Uc4s9kDc2Gz
kWRASPy4cL39LVhEuTys4YzHlRwP0raKEBpGdfGyK8JRKx9/Ea9GfZsH3+frqIyPpHN9Neif2cPO
53HvWPC+5qNSJp6lvS/XAM+DT5jpk7CHqBRNRcVvV2Klo8ShhJm74Qk+XkXxzYBnkKyWuIOto4bx
G4/s8VnnspnIOtfXnbNPzcTW7R0TWxHL98dXeZafhEEpmrpZHqFUZHlNbJly9ePt1xDobHzxMU8h
N5zeluKpm0QcTFUaSS1Jr761f5Xc/Bv6deYlJyasL0VUu+zkcKqTSd5Fyzry6sfhHV59KBrFczQg
5wYRDcqleOoeQw6m+hAqcvWz8HpE+RkI8v7lxwaCe4m/6oBXxF+X5+M8e83956poiqZu7kIoOzCX
dRwCfTrt5Al059BSNHUTCKFUJ5BmHGct7uK2LU8ivo8rRVQ3kWI41cmky83dZdUEr2gUL24GwRNW
n97PghJ256jqHskU0g5jaR2H5fs8BdqGhu6Gk1JE9evoCKc6mYwdzi1fQ6aVx+7zVMK/S/HUTSQO
pjqNTKO6ueNV6y9sNofDjSWYRXTx3BiaYqp9FY4BVaeUtcOh/E8QoHXAKxOgz+QCitBS2cCRHUOI
7iYf5JYoNnhE64FXMqJPxrIUzRFGcdfx4+5jB4d0ibcd0+Ptta/Z+jwb0wexucev5aWH3+hCGl9c
R8/R1w7pnoY9wAaPowLX5sP1X8GSl8LghmVNNH1q6b4s72rA2JHxqkD4keTMtSezxRRHmoRpLmpe
ehKSBXqt8PvfwJN89JerecIBcdmW5/zX2tPQmdL5t3L3wtoGPs/Ud1G02OJXwDHUaMYthYK3AmRN
FVVGDapJezFAHXcp8oDjexxCMJ8+NomOpbCgKVOTqaJR36Pyzu6btdH0AqFzkbmaTx5IGICMLHB4
xf6lGu3hhTCwqmx4omJorqpq+9AMMVf1j64AIXXZXPHwF5jv75E4PChgUjwK2uTzZf9LbgHC/2qk
Z+l4csf7uyAsG80ab8wUgEBvMFGRdNGhpi/ufNMoRbzzWJYBqDSSfdhxYNJOdIZtSW3zuUfs4ShZ
5g/5qbPpGnz80SyFgl5ToIpR13WYZLn7jml9tEPFbx7MBQAOynMgTIPbEvIdxE3lBfIVoIEWZFOl
oGpIlmfstSocBvpzH77VgnRPK7FejR42xTigrqKIhuEzyfXozh42O4KuhCF1YU9uWXpOUrrEKAYI
djCi7ILgz9zOB3Vj0HqLh62m/nkgr3lg8xglx+w4jsbbfpgV2JHr6zWL2mxHd5OQ3zhu443j12Ko
PlX5n6lza3oHj81hq1yynzwMiuL5ugUMNCDpzMeQi7Ct2PmyG0e+g5t3ZSDJQHY8L72AlpXnxxht
8i4EDQE44F2jQNFVdNcsROHK+V/mRs0ChZf+m4UIub1ZiHha6mZBwouPzUNkL/DCSrNw3Qyahsee
YfR9N2wcrluMqtZUdMNh0xDZdLGYTjBsabOQdUd282QoHjE0D5HNk3xgTPgGYmugMOW4Gikg4tFc
rJqFas6i78GyYVPxpn/eOEDNZKph0yg1bCqlToO51yxENxedy2YhGjdMEx2PmoXnpttvGKDTbuMA
NXP6D5tGqYbqdTfXw4YJgSRLQ7NAraCvZiHCL+z4BnCzgDnTwGkWohkLQ3rbMDLFMcKahSmOrluC
aYdoHwcV5Gdla/DPAvRx+LlZiACQfbsMVmVLy0+CdbOVUBX9QnZAhCZ6Gx0GyPl0FfLsC2tMAaY5
IdSNJvcsM+YXXE+rm15OEKdp8BFiVqdNnhuB/xUpt4P/5a6UG7IlGoyxSpLeDQ2+H8+KgVR3vOON
QJe+o4qqxURXstQfnmPful9J/3YecCdB6oRs7jJMGsUDPC6ZGyy542qctAgjVU+hoL1a3C4pJsZC
4zJ6ubKHRZzUKJgTf7IMI4IW51LQPCvIy6A9J3ycu+RktQDaMZvN79/DK4i+rkiaa0qOrCVFvmJ+
XQ454Ka+wo6V6gy/Q8dj+L9N8LMdW47tzLPriCgy9+Htne8QIa9C57MAODRY2sulF37N4siORl3i
L4NZEn4X/UzisOfczygeHx5o7XfJdSVf92VBdHVHUB1HExxNkwVJl6lq+Bp1HLf0NSqKh51f45xO
pnGqPgwPW/42bZJsCLmXfuZuwV/y9W9XK5/G09pOzpQxV44dR7LD6yXFkKoLmldNnfQw+YggsplT
1u0OQQsqdBtL+bO0U0yoKraJ5jKLur4k6K7uCSCbRUH2ZV+QZAODVVsWUwrulCK4g0qTAnBSmxgu
NUyPioIpuabgyKIlmBRY2mTMU13X8WWx2K1IO+iAFYCT20SRDNdRqSXIHmOCL7pMUJjpCZ6i+JZs
eTIsdoXg9OoOnvuBU9rEYlQ2maEKKqy2gmqJvsAMVxFg/hsw3qJnicXDelhw5fMtDjrIGzoijmzK
pTEPS/uueCGrQt+xN9iGfPcnc+9paNATHgH0dwJgfGpqqmCZChVUl2mC6amWQBXRYCKmKFeU4ntk
+kHFBV4N46nbvpIR5Yl+aUSm7AGo15pN24bWkjTgLkyiFvYeFssL9sCW+ESWtZYp6BY+SZw/8WtJ
tlqyKijm0+81q6UK8rOvDaMlqYJk4PcxdPYQ8fbFlgxCSi16oMuCruGDh9l0uXDtELRDDkrSJWxO
lUspdzjFMBvw/44T0LVzAePf9S+ve6PLzoXdG42uRm3yJ2eL1ZKd/BITt51Ee4+Cb2z+y3vy9V3m
QjuliXYLg5EoyAJ8iFa8mzTnw1p3BmWBPo9ByF+4usNjZRHUTcOIJv1n9wjvKOxraBgG7mQzSywv
11rLrnnwvRht9dOaw6PlHjKZxlUdc/16S3LcDUoVfnG3BGWy5NpePWDy/SIp+JWSDFaxOndYJPFQ
fsEUDZuuHa2fRZPcACWl72fHoETaPy+Cg3GTXBst7tyofs9qh84/p51jhOrpBLgBtvM3gxII1S9p
7AAB/+frO7ufuCzOA7rMXUa8j/eCycaLi9sqC+4R3gB2eXglxs5Wj477j9UEL7jjEzzdgCG9WtB/
rNiI+W3F8hQq6lTwXN0SNMXTBE8zVUFTdd90DNmzYIXkYcT5QlKi6RgHVRm40+zXPXCegA408dpE
fE9GfOK2Fm7xBcHDAn5G8xHjSVbqpflB197XnoTsz/3VQ2j9vJOQV71dzSchs+Ce2cBu3zBBsOOV
SMlacPDO+bHrnKcV+hanHBaJg3wv0CiimLeY3Jx2Q3Iy8bFc8Z7DrEGR7EQRqsB8IQkIZlOqcnXY
3KYkqvwCszAanv0ouabjTULufNlObra0winF8Ql4lLI21V3qmYqu6yIruKeTf4tCdNa2S9c5dMW9
+67q+4xpVGJ+liInLhhj4Um2vwHDW0xyVM1gluO6LmWS5zPdlyTVt3wqi4rKj6rjBJArjJPyO5mE
8bGxHa6AGmiGjx/jZRob/7RDaBf3ICDcf8/6MRXV16ivSq6lqwz2fL6syoZFmc9UplrFRNi2p9+H
CPtxytZQhNrunHLLIptv3rttR2au6lgKVZyim6v5VyiGVt2+U+90ksRtGqK+O5FgFNEwhzcGDdnx
FV1TWVEYjZdmkiRuW3f050yUdaz51JCZr4hOlhc1nUQebPGWwWPlWVQMrG4jz2Li2zANafGGoqb+
n27yhv1zcnQQfG2azEGH96mLcaj+LLzHWVPvMzqnt2yGRysZBoAAXThL8ZhA8ryAkyvdYhabsmsC
4aZ39zkEvslcHZMXckRwJkFow8wFNMdEAPKenPavxiTpGvcJyQ3kUhSH05TzL/01S+PDz17yoJ5n
eUUoZv0GPh8kxt3aEm3jixdjqeFUb+tad68X4zgok9zr7nTCt8FAh0UwR9eT8Ql0K7ZETZYKtWhp
h+DI+xzHcOYIAz/6DkpcmtCwCAisbXUAOaNTdzVNgowFsFOLJjPWahWyqCzWQguSbH+T03MakY2u
Zdjb/08hnB1iiew3Y2Ll+96b2NwDiAdWKJRm9UP5P+qutrltW0v/FX5LPBPGeCMIOOMPbbptM9Ps
5tppd2c7HQ1eY25kSVeSm+Te3v++AEjJtARCJG3Zvpl2bIuk+ODg4ODgvKqrarEy3UsWwWOfiheq
mjSmuxgAjB6UBE3c09t3GXD/zgA8A26Vvspmv1W6Etnb+XIxrytdvMp+4ij7/Sfz43ypTMYZANlP
H//Y6K9xrEdZSy1ifVrEN148IL6uP5V++vCrE2n2/MWtPQwJRaBlIi+MtTkDZZFbalROidJaSkxK
ZV5sdfyXQQydZ60vsAaJAtoi969z31KoHJRG5koyCxg33FL2IioyMT4Kdbf+4aUXU/70G3/5cSOp
WhFw0deTo1jvN6rEz62Ez9dTH5PottJgEvBmtWSUFyZHEVHKJ1xPQ4bzajKfBV/PWVNXMPtSTafN
HSGOMtwVB3cUltnusu7l8y8+DnFhaqHhzim/vY8jOYoc/bFyZzRvtrt5NpDSxPn+h+dHnUfFlCbP
ux+fH3keFVOaPD+8e37keVRMSfJcXjw76jwqpCRxuvevo5yP+5HnkUDV6ly7QG/ILamLqAfn5W3O
REcxfI/pCCpmP0wdhd3xgMYBD4wo1uPSIxrQLPehEcV7x3lMR4g97Yepq+ojPkaUcz9IHa2PPKYj
uDX7YYq29PKIjmAt64co2lTII3pKEdDVp8PjOkKIWc+56+gF40AdI+a7rwyP2nIwPYIppR+iePtP
D+nJVl1n8yyP6slWXrwDk4d0FPvDhdlaIHxcyHW1Ch4/X1WlsUbERdPDormH0xonYyrL+8aAFBor
JQQhjMcKLB/yXOMy1fOzPBT+wChgvGTaAKUOxIBoWRakKCTVsKAlQxQjy4iFWgquKXvKGBBcppTZ
MUQYxyllimfZvWJAuIElZIIoqGIBDu0hRKGxI2wV44iUDO7i/Yl0eRHoI79NPLtNpkKaqc9BFpjx
giFd4DExVe7h50IontL0IRhEqcpnBekb5bO0iSZuQQlpWTFK4iTbnLZx9QHw134p+vbNF2clNKW0
kCFQyjqd6UxxrKFiJKeoULlyYinHkJq8FEQXkFhmBDm59RD0lWAnQ4nQa3ISw/lL3Ohq/cedEZ9l
TcbWC5+CpMtS5JCQMtfa2FxKAHMnCpFAChnN9Is3TV+ywPzuof8xs8sAJvvoxHG8uBMBRzj6j2Jx
kgylgHAQi3sf43x95baVpiOAYzSmuNUWUMzkCE4nINWTsg1vAI6/fF6JsdaoeuZ3b48CeVgn7X1m
DKZ4B6LB4vuDDwb2ZRyYKCm0wCEcM1PoCFaRcQRKOpMh7k8gR5mNDuY4SFInuhDithyzqxGU6hPX
RnX49fsSu3XrxRkgtLSIlsZN5UZeC8VwIXnOGVE5VNbmtqAsFwJoaxiEiMsjy2uSLC3SJkDnYDbS
+vYGb3zuK6mzlzui+cTJ7uC7ftGnsEL2ch/2SVy64+eiwJCkRxmOiJ6/jbpFgjtiE2mKWIerg9zg
PcrdyyESNL59M9WWWVBQyYk8FO97gH/jyAY0+Rlai2frMVjMF5vIKd9Ax6dldIJ5+LJFX0NmpbiN
DfAOdr8UVp65tPvKkGDnZt+n3ejXIXZglV3frHwWcm5mIRvHbZnXKzP904RiPdNKVetp1OxKSP+c
on6I/IBK7WRDmEZ0OyAP9HWNT59l89lkQ4lJTYmJf9O3s2zVjq8cvfwDtgZS58CPw0v19FWfZiLU
T/INy5pcq+Zb3Q+xzqq1r6U0/1znXLmf7jOfxbl9Q0ee8xGR37WS3T7gkwzdSphOfYWCR8f0dj5z
suNGres6WXldxSYPK/PMkXbliyTMPq2vzqPZf0fF1ppmb8D7Iqqt4AgxqWGNLJZzZR6ADcPVPt2Y
rqp86iZtejuGpoZXNHSeDPB2JjDEt6lOKN4uI612QkJSqsWITkxDcPeF4Xb9yVW1oVb2w+buleO1
a5E1gbx+4b4sXmUUn7zJZDUTy2/ddzwP6G6L8NrCK187bfP80tTpzkdkiq42YY0g9KLRrIUfmY/k
yHzs28xpDBuBeUx+PQDth4tnA016cdxIpVhmTAeUlBMF0i698tCUOKyIsMJblxDxpUVGrNsBpWCH
yptDtAr6MSoo1FBgGjtOPyT8gWiaTeX97Z3vPmRC66Wnf7U6yyBHryFlryHw6YJPg+7y6mbdFHT6
Mgsay3yq48+n8pgfAehmRXt3X/0Cnzf07kNvOvZUjEfC69H09w7Mjs6/JBmGA8uuhX5IwDnUJYCY
QIK0YWP6r5MBSTbjaHhhtmJ7VRd6juEokh4w2HarOK3tj+yr2zSv81BNZf1tYc6nf143CZjnwf58
7cTRtdj489z3BZdeiF9fiNXqy3ypz2duWqNYWCotvY2ldbquZhPvp55svt0ftSGiwlpjjSBp32Tp
zknU/U8KSSRnmnOGMZAY4AKBwsraN2nFdLVxToaRPJ6Dski63+5FklGmmSLphEMDfEsRV2UpsKTe
9MUhiCyp9hii2HjSVhmnVZMFLt3DCJSWwd2KBrvGmUMsE0eWMq0hGFtky7zhVc92efDTnP8SCo6s
nAByMuB2/fnSfY7R8vCBZ79gH8h7F19tyhPltR/hrP7r/NT9PHXT9flUfssrfeojnPLL7z5+N7n8
iDECFIHvLifF335EP3388F3umH2Nh654ClKGojZh0uytIGOAF6KgfNe4trPiDYTAOrFNhdPQCkqF
+xNgyyRThRH06Vc8TWYc3osko1Y8TTr90ADHTWzFU6sdcSST2EZWfHsMUWxJ91abVpcXt7Z5Q5Tg
FmFrMWx5Ujem+bt+0TtLLmo3fwAQDcduL9/GJews+dV14+w7/z3LokcbmvSz9UKzunZY3vsgNCeF
mgKp7rfz20Q5AmxZSqVzBqzNlbY8t5KLHFlLjJszgQDLVtU/TNzqRGEqBf0Oi19PzFejPCtII6Sy
jGgO0iscKGQ5scRtJYiWinsXTIGR1G6RQyPE/gp/zNUNU47r3kMft5JhShlGAzyMkZUMFYWA2dKC
ksVWcmsMUWzJ9Hs0wOXjt74AbMeVDhThGhteFnAf4N0VEAXIU/4VNKBOT+O/3oHHLBMSqZIZjEbB
S9JvQIWcBt5W0jhsRsMSAKSp5ftS+jA2loztRQMCIX97H7CJ6bQp3b6afHFU9AcgLbhGVjrdTO7r
jn0wJjW0ASF43su7A9KHKRCIDNKFLIsx3MeT9Y/Q8OC3u+i0O62WHEKlyXDmw68RfQyj49Zk4UZV
zXWlgvVW30xNzN74WKguzPV8XZuL3UFh9YhI3m4q35hrs/xkZupb1jR79bU+zLoDyhHti4cQ+W+B
VArDCEbRI17aavJg8Hco+Wtj85fzmQ5Oqe/dHjKfjSAgBp0L0NeMaqhRm3J0EyFjC3cMKQFSfLgd
qQeeXi/eeBM3E+hosDImq2w4SQaN2JepvWN7vRKrTF2J2aeYk8QDS2k6GHURamdBhSA4o0ojOLYw
VsXuMIWSQGAXkIS8cW8VSEopNCGFGu6f6wGq/9tDaXzfDswx71Yg+vZJu48Frh8zWfcUCx3Lyz0s
QSkNKgrhDr0PTsSx0uBd3W2qcseDjbW31oRu6tzYDrEwoBXWUAIeQuQP0pqwkjoFW0STQQ5T8kHg
d1EydAuolPtm91sH/foHn42n3x0c3llHocBYak1ZMYZqA+qW/7J9bYjdcSeiElqqGBKk6HWqi5UL
8xD6p2ekIcQqhf3T6Moz2GR+sz67fGmXxpy8sY5MN+6e8OHvly99QtbJm8uXf5tf+h+XV+6UrCeN
xcJ/8sGdt91b/a/vhePYq/nM//52PpsZ5b/e//VutjbTafXWB66c/PFG6PrN7kzuX/PP1eebiTdv
blE0sQTub/oavAYnb9zY3RzPbq6lWbpP3QfBYbRyv8OTN4sQJL9Wc23CRfN1US2/nYVSaAhgyD76
ikv+v/89efPJ9xlx12bzkzd+7wtPqPn1Qsy+hd8btyNs/4Hqu6p1fUuodh9+Wzhii+n2zcoJ6vWy
ucmN6losHUxf9rt51dtqvay+Ztuoz5M3S2+CrtR68ufqS+ULLTa9WqZhpN5S0bpnKuT+hw7BJxP7
OEySm53PyYuTVbU24bzg8Hzbv/WLkZOVmVrPf5WKvGjnhkmtSWzR/+tfcd7uH7x+7+UVN5p4EKlz
/0D96m5E1HxmtkFRNgTAmR0Va+PednBrTSuOMHW6wCPMOjuFjilXlBgLgIqpX21Cx+GlvDJtePHX
c6qcCHbfYuCBREPl3s01g4IRSA3l7rgqRamZ0zCUsLx8ukRDRwWW2ipGUWEcO7PUmsIjQqtbNkAE
RCm4BAIjGuGU9hji2Pqrc8db78nkOTzAzhcMkT5Jp9Y4TFMs2ZsigQMrGS+EiHo9Dq0ongq/aEMc
iGU/QaPruYszpjABmhEgoW2yNZgklNJC5wUDMKeUwxwpVuRu7TG3JpFSgkeyNQ4t25OhpOk1e/1G
tnEP/Ry/u66S491E41Mx3mQ7CM6z37ONunPulZ1Xm8DJ86DqvMraqs75qyYyZnUOX2UtNcddqJWc
830V51UWVJzz2fxV8DW5exv1xv22UW5uf0X+ulNs/Lu8WuN+3io14dmg0vjLewrN+a468ypLqDNB
/LbucMrM7kdBldn/cKurJC7dVWN2b9zRUQ5c3qgwu7f9ORWz2rnU+vDv89XeZ34zmmxaW2xQ7t1V
1/DYfUkoqON2BrV7YVGr2puvqTMKJl+vxN4XXzea+N4Fcy0qB2xqgvlh9wVXlUda+T1zUTdo9qUO
92g13Zu2pRR7aPX13kehnPdiXoXt9u6VhWet1ecIKLU9SWxGs5iKtQc3sdV03ZqkTzdTsXR8+Wmi
K0/Bvdm7XuzNaFWfTEJI/R61Pi1u9kbVKBHxc24yRmWEgApstDmS/ZH911TX9To3H2XbrJJH//cU
4/9P86Vr/KFwiDukZpeXjTd9+8+fUMMv7z++7TGwt7Ove5+1z6+J8WPwDM40OFlXG9+nnYbhQAmq
kZGlGqHaYJBqaI1T/TSsMVAYaBWju+eE3RCuQxpHHNkxPA+73qSdJqx1Nk9UkBwHz7WjmFsZk6v5
/POk/oqOtyfN151xtdHxhbOyJpIwDYAcHnZ+CM49rYcRmvh4Bywdpxe6BOW+y/TREB9gpyvj/pYm
JM+NnMuxUHYbtfz8Xa07dkBImZ8dO3XxDaJCAVQCDsE9wloPAbgnA3WRIoRtM1pyIb0kGsVFSbqx
rmW4yxc+uBYIJgsrC1SO8WcFJD1TAu40Q51cicmGGmUpkMTGGsxFM5uOVtXqNn92PsvkfH11W/Y7
pNd6w5nfwu87s88W2HgJEHQhLTPvI3R3PR2Q7swwj+BBnD/9EEy09Nm68UiN4yAJPZsnbg+ZuXPX
aDrgAVE+cSOiJr6TGOdlqWO1QNrCdDg80hn6cJcHgyFQAAKU4hyO2zuTODod+re5OwRRTTCXVo3y
Oz8Ql8RRRpglxECUpuQGKVOME8/H4Ov1/EZdhfYUvjpBKKkb52vY3086mF4REP6gUWBigXsMjWMx
mOwN2Rm8siNj/LGkpEq5Yw1Dxagd3geXZ1/Echbf4W+38r8ObOqtyasv/76nHTr5EQ8PwTB1YHSq
SzPuv1o2odZyY4qXzDAMtNQ7rXW3jetDn666ta575rf392mY+wSAE31IPJpUSsd90Kipm8MQcfe1
Wq1b7kd/WImURz2EZawk+FADDwml8zyENud1Q5RV3aGvQy6kCqzgSMLWTgVUKLXGAnOki7RrUCPA
C1oqXzSqFGUJmUSQA6M4LH0C11O6BnEyY+Oe0vHgxHj+cgBLpIgsQKwm0mERlfQ/j5nFcWe4h6Hj
Dme3i75sQ/HszSyYmzuUSHjEGNs0Hk9OogXxCTi2HDeb/cEPwhIPU4x+Rdg7nwG473ToXr95KDQ7
uz3GO9G/Om2MQyFE4+83xjsCAgOdl8g3bwv/XtWZmpuIzJeMku21SPr/kw/ze6GaSJYwxr2hYfpv
O7QL86eYVk3XE/N17ZNVp9NvuZfqTo5XKqyWRk5FRt45cPysh/1x+a2RpY16sLqR/2fUevUi7L7Z
zapND6cGLt1Fb2FrnJ3bYhV7FOGdFOHPmiK/zN0twbqzOyIH9N9yjiMB3y0Ff2eQiHQOkj7rUf5a
8288DHqAoHrIYfZXJnxC501TkSNccJO1rBYdaUNpDOR+sVqcQosc/RXAsXzNtlIWx3ZEj0snmcLB
3lhIKCoRH5MM8kC4d+bVsaE7DZjmJLYBP581qnYebm8G0THVRyTnEHQhJ18V0BquCjbKODZgKPdA
tslYasJpNwziThSnZq1O/avnN0tlTuuveq3rbiZi+ekmRNeGr356/P+xfaoD9imAufkqrhdTk8Kc
NBw/gv8sWUabDIia/O19CPqoEU70N3car9Rk6YOffXgBg0ZKBrRkscPNQQs2SkVOkljkZH88+9GT
qWcvzjSVhYCYYu2O3XUEZWmMLlFJcssFy5VVIjeQm1whqCx1exbDOhJBeci6cTKURL1msv/oNlGU
iSd8I9i7zZgxd/sPoCLXivK8wLrItVs3eUGoZbJEmiPy4o2vN+WeK5i3r7rXuQ/E1/YH0THipHV3
3Bin83BqmtQcsHILSdUVJL1t8LN3ELoRDhteLbLW889uDUYTr9Odnx9qIBdmasTqyANJ+SAJdcrh
1FtFJ1vJ5VQTiQwx1MDir2ZYjZTzGUx374+/MulFOvRK/4zTQE2+XKhW4uzCKVeUlHGd6SHf+N/L
ygnq2SZPtjnCORmSEemDmYTNBS3drAgrcyGQzDUHyChqNOAoCi9Zdb0PvPnCccuXIDbrHx7SBnbm
5OnV6iz7PTtdOcjmH0afupGcbrLNTpuvb0oYn/YZRvZHw1nVtfFRYPDW6OKOrsrnm8ZHmox/e4Tt
MlnZmIxoDXZb4F4XCAvrXqhH7ZDJ0o4k0hFr+2bgznIF82XUiDgQgHdow4ojK1OesO5Ja8eW7TvB
4hF3nZ6wYkCn2UfRDlH+55X2bqCZPyZ1KYglToWdknZ5k1YBunaVxytd97h8oGKPHlKqCFQb0oHK
hr6hAtTUx2+mnUAFh6Lk1tDCmrLErDBOlhDJuABccfnUpd88SZIbxH1IMkpMlSSpJ42IR2kZICTy
J3nqFryOZay3xxDFluyJW4BeHH0lxcPxc5EKXe6YvFpycgCoVgZowvUByXmIh+PIUt2o2qRKsxUA
REvDuGaKp1caKwpcGOh7AhhZigLS0umWBSkMYVAR/fQrLdkA914kGbfSaEojKQb0M4usNGoxlZhS
q0AsLbM9hii2MnUiLNDhlXb90FtHMqW4Y/bqpVYSbigXQpX2UJbAISaOI0suNdSXrxTHGCChIJUw
vdSsLJkFAjDOFSoZQJJhqiEqSi4LRMunX2rJCsb3Ism4pcaSS+1+VRALphUnCHOLo7nyrTFEsfFU
CENB+iy1B93TeGpP65i7eqFpKgHEuiwU343N2V1oh1g4jiylPRbxRlwxrjJWWgYNK+mBPU3Rwhgi
FHLHXcAKiIEC3EkSqQotJS2efqHxlA3lXiQZtdBYsmZhMcAmHHNfKViWRihtQTTPrDWGKDaYqjvd
QauGsTUSEttCAowP5ZkdYJkoMtzf8fgoB0ycX3vLTUgIzrVw5+NZ1zmTvIZJ80ERNx9EeNAwWBin
6vLSHCj6ATUQEHHOC8YIJNggVhCJ3DCFRFSQJ6z268mRlFLxdMZoLW9YYAbda0uWJoeknGpEjdFC
ElEgaCSFWgILDf9/7p60N47jyr8yyBdZQIqp+2BWCziKNzE2Ngw59vpLQNQZccFD4FCyvev973nV
0zPsGVZXd/VwRGm/STM97PdevXr3wYR6bnJUJdQx3LFAQmV4av72UcezDB5RlZjH7YH3Cox8p1xK
rlQRP6RpGbZaBEkcFwsghIFM5Q7jWIJtSN8ibCeZr+q3ld79cKdSkcaTvXskc38IQo6bOK6ZMM6W
l7DX0/MZ3vmdIKXXayy9ks5LvetBf90DkVcJda1v3WKaXEg2mGbV/4nzQeYoauml4hzRkCTCjjGU
QoqIpZSo1jFQbY9FYf5xd5Vxm3axuOonk6weJpOUD79hAGDz4U8AlK+Nxp7aFIUXJSNokhUaZge2
AXOUEFS1wJ5cMJxgv9xc0hjAs6DKqkX3pxp7kAWdcVDtLqzyySiCg5pQ5dR4bKMQ3kcMpi7OriXp
7Mm8Vzo+X89CpkLtCi6iwjJmqY5Vk8dpTIpBIwGkIGlLzvwQhzJs8zcyf8TrVV3gJBv0eDegJZfq
X7y7er85Vp+cidKDD2MXCSRdvVsD2OYCMTLRbPiDN+cKGywBJu8p7gtxEnfEaaFQBF2HfKAGgQGi
QFNxxQNNgvhYKMSZurIvW4kx66AmUNqbYTZ87Clml/V/Cv5K5r+ec5FP/0SbSnN4JHVf7/5r7/65
mXFWGpDEzyStbVhXsyPzOmEjFCOcalmXs/CM9iDpKDjlcGRGKWKMNwpjnSw35JkDO5kktSt7FEkW
iRBZLRFTxyUrfPImOR284qUFAUMcSrBpVQtA6FpgR1nPhPUy75uaCOxMsUwJMiNq6qDlPudC+QxJ
/Mfqjb3MhVn2ftUtV988vz67vjoX+Awsa81W6N93E2zS7d3P9i4X1OcnKCNnVCEu8yN5PFv3ITVg
XyNaKME4OQo7GFje6omIyID1ZnNfjJa/VvAtQfzERN7yaGba7/dh6NYyxV98fNfNxn5rb0KexLz6
C0iF3cern7769svvvr747m8//OXrby/+48uv//bDm69y+dNGEv5x9Z/x16/u7m7v/rh6AbC6O/yi
LBFPg9MD2fPYug1HEGAaKhDjHeG7j+Mv9903GIjOEC3KpxOzxfHwyaqR2ABfv1j1AbRHzGnYGeE9
68JnH+z68kPsgaT0jKIRCGvBlWMgfASDPKMU0ZPBN9sw+2wALfJkDdrHTEEE7QQalg/fbz7nAvjW
IKLpyC+JPuOoaB+aasnAE7gXD9huFgNkeOQZU0h1aA4+FFqdCYYI1fmLAfiaA+ICvmCtx/gpuk6m
GurTC0Kgg+GFThgZhE+0fbxLhqxWdqBrm28JU1RbyjBPh+Vzh1bPlHdThOx0MaZdfXrWuy++BPMn
ZnW6PuvVdfe/L35X1MO/+/3q4uWL1c9v87SY+8Pu2IP3DzoMb3uv6TEuxyI/P1D5JzgWFBMYc/er
bjN4btS+Tat3b39d58G8q2+/fl2OVZvqLoMjw5WzwMrx6yhMCjoYqdo3gLXhsASkbUy7P/YurL1Z
YZYVQbwJ56uBp1uG8BQTVnb7oKYi7CMnf8IsxWzQcvTVOK8ESBtGw5LTr64JXUrby+F+oH4Sd5mM
DRsKmslYgiIzp9GE2MADCaXqvWmKzQd5BgRH6c9qRMss2B1/EFRW3vlgrOYLZqQBeHnzw6gSNYUw
y8HrmYkqJCEDm9hBrh2LgkXlnKfJOwm2JlZORadpSMQ+46KSTIWazlpEhWXMUt23a44LMjGniXOG
58RjKbI/wKEM24Ic6sN9IikoJaM2YDMNU6j5qe/+9Od1N1Bs3a3RWn3/ptDBdAoIFhySOMO4yiwN
u+Ezx28X0+byLsoJkVpSw9qvcoZrvro7KXlqstc0lJruyLOpy8osrDEjXsRIfPvEbACtOuDw41Go
Oo3ONIy4eLzXeLcaGmNDQrR50Hu7xZlhnD8f96Skql1501BOWdhQ/bBGWxPmSFYRtH34AwBJPw22
orUwkGnfht6JZeCkiFPiHAcq2/dFZrDmewYnpU7NiDYN3adbTur3UygjdLKEYKvbjfsMV0Nv5QR5
+o8vrPeg/kHBvr/LplEe9dWv3Mmq9XwkDXlaWL6P91tdP6iGMo4HHIhGyiYLXqtViDj4b7CE5qQY
Bqtt5bdo7DYHrf4NrbrcZBmLT0N0sVoA3jRUaWSGy2HaXLAYEsu1vtLSRXeR1WaPDmGaevnjGoPd
g2/OFU1RCLA1CSV9bUE0jBrJGAIdzJFiPCASdUQRUxeUDsbIUm3BlNMwv7agR37WgYygsq0p2H59
3jHzq9WLQCkD280hLZRDLDqFvLcRGSbh94xER/mL04C0YdBv7GYN5/dvOjN69/AXmTSvHq7b9qco
/xYumcn1DomhGKy3KlChoilMBsuA1jLMcwDdyoPL63dXIA3enG3ucnd4520QrtZ3g184kBOCEoyw
ZhJpnBfwRa6QkphGixnzuDD5oUfpKNqPBIZ2qOW5BB4nLoU18bFu2P9rx4E49tLf1tdA7G/Alb4F
qvXyE/716inoVwu/D4FbX1902WMwJTyWJHnpTJpoPAqEB0+5pcFLlhjXNDKXvGWKMk1NoW39o4UL
etRnnUsV9WVqpdqeTvCCgNIgRhClxUIqLUDQlrpmB0gUgTM1A4LghgBGl6HMkHXjmy82GYks5V1u
GHdWkViMYgyYvwQhqW6QIrjBe++tZPfrropHex0CcKtwJeJNglZ1Cwlu8Jx3xHsAzpmoKYiaaHWx
rnMSuBrLE9zgtP74569HPTEipRWGOK9jyb6ZhJLW4mcEN/iLWaKGcHF/e8iAPHARPQBACjJ9Dog1
E2wPxDZYfsu1UDGl6O83+vXxL8rwPKkYfzT0ZkKOF0F6Iqvoh5vrB7vIphxCenrLiFSnkRWB7TMO
Gaq1tzl+TCOYtk5rhfnW53jT3YxNYjjXXtzdZj+qa3VM+ZfgwkRwVCwiHJR1CDEh5zBBoLmopZ7G
AO7oW7vetC3GcFYGvn6rR1fadXDnVe55U7oLhitntSld2SFqy0AYedcxSpRMKNEFJfT7CQGbQIQ5
J6UpLsob4lGGr2Zu78E31moQRd5KyWI8HEt1YGgZpfJ15N4bKpmzxHjMwS8Bxxz8M1Bkz5aW6cnw
pJ78X/synW0T8UW3KLUb/JejObkiakRsN4By0oyi2PTXVpjX/DaCHVAEW68Zpd4HPYsiFze33fzD
GmGeBpr5sas216Uc6ToV1E8e5co3awkCSyTEQm6sRdsIOS5nSTXHKhmujSolfIZILAFugbP0UL1m
MBU4CrBW2ksUxEQbdvMtzgb/bunz+tc1nGSn/f/7Pfwkb+nujAD4qmfQh5WNcNT9D4tgitrMiD0K
PqIQiwqgZARINGUmTsX5yqDVXbnTWA7ipFsb4wcQAevxxbVTABDS4CWCk9Dbny4QjKWk4B2WeHnS
XHkaooyYmkXa5KoqnyRwCGZGlIb5T17A055kD2Zv49/ARwuOc3EXfz+Z9w87qyiz+hVQqFQjOc1U
YvUL2Ht55FK8+e237iD+sfqqO4+zzacX8MBun/fmLIovqo6gO3ZwwDjW2STX3LBoQGbT9p2EbZDP
B+QoUVQt+ydEjgmAAU/mqJXjhDJsGE5LaiqIrCsIVo5nFATP45TS9rk35xGIJQRziVLeZ5QAaikc
OMDRioCwTQQxYwxKlGjHjY/MyEJGacrfedki96oV+3u4l1HZasXNl+f5ZF6tXsxy7b/4Kd5sar5X
fwcPbf2ymGCqD+qYD+FBgmn77GEUZftLlH+KLCMeecsjMilY7WSSyaRyFEXWDbVpOPcTHd0TT5Lm
mIKsKBp//Gb1Rbi9zoPJ8ctViHmd1EX3HZzv67d5AP0PN/4WLnousf8Qx5PZ9XEVB69f9tocR8SY
AIsJHQkZ4NA47/5yvbq5/Xk1eEEZo7rYWjAH/HDWBdHeUmm0XiTQVK0Xe48VHyKiFK6mEBg8+4Tr
8RbOuAaz2EkbqXHgPuSAo7NB2qQTFoUpsR8z4FLtM5iP+zJ9pqqRcVKYlPVo0ze1IjkM4n1ifhq2
oDoIEwE7zyXDWnnpldEJlAaO5lmDXtVOCkKOG++hJQk0SMOTKhnNw7NcAtySM1rILNX4BzluNJdQ
JAUZbMKuWDw5QKIInK6JuGexFasDUODppl1FfWYx34yLK+viVcc5Ea6UwALH9hVlGcCG0rOPRLKq
4qcNgS0gWS+AwNy2LlDlRbS2fUc7QJU7FcaF5BCqydcXdzf1T745V6CdnBCSSrXd1JSi1BgbiYJT
GAUqKAraakQFSU4k4hUvbWqakrYtRVyk2qmxh/8YMoPFTJvvz1cDTs7rmHLKFGgMTvXV1eo6hkv7
YvNIiJu5orkrEh78e892uaXSv13B07c/r7Ph1P920z6Z7m6vD/5aCTNabSt4jhsA/63SuqFWYkxo
YEU0OF8+sCWF1xQ3lBZ/JJJVY5K0ITq3d2uVEAKujrVkSaiL4lqOfw+qydfXhUZ0yRHOAtGS9UKD
+SAYlQlx6zxSiWgE8HHkLIsh4SCZTycWGh3+805lDJlJofFflzch3/6fvlt9/x3gzihyl/cvy4Lj
9dXtDfDdbQIWBa/pfidHLkFEgEl5e23zWuarq19z4v/D5bpb9Po2Xt7t8ok/vwWGTJd36/uVu73N
pLM3IT+Tt2Nt+7e7ru7rdbz6AG/bLI16G4GX7/Nw9G0uYNN6NQL/WVlWVauBnuXiVXcxEtpSn1SW
VSl6rplj3pkldf602p3xPCSr24Rt+yt3wkJyL7j00gS2pESd0tr06D2oJl9fl1XUE5vtGauJ3MYU
hbdcCoM8VwpR7AgixMJN8C7gGCnTWp9aVlV7MPbwH0Nmtqz68RKMks9XVO2DPyKpJsjZ0BU1VpGa
uDJYCcZxeqyc96OURQirBVDPIhjq1VG0IUL3qEY2GGBQGyhYj4+zMDOIxesmaUNwZETMyyBsNnc0
pe3TPDOAn9xpivppNkRKapW7KTlOklJJ4cchkxkHW520TlhbgGKnDQjhkVjsqFBLkn5UVNMnrCEG
8OgmcOuFl8Rx7B7ryTkEq5YIDgk2SZm6nsSJcsUoi477Xk+SSLh3xKGcg0eK+4isowwlq6NTLiQX
Th0IoPXqjyH+Y8jM1pPq89WRako/1jP/rMXHr0gHSznwufFU+EXSoZozehapWs+UsDZHvxgbSZEk
k9ex4UV2dDVA/jwkqwZUWZuLthNkAoADtgmK60UKW1frF4ZQTb6+Lkc1pzioIHNpWy9HBcOJiaQR
D8mgKKxGkYNElYzooKk3LtJTy9HqwPY9/MeQaZGjkn+2crQHfUSO1jvfWIszDXI0uIvLPAIwvPdd
6bjUNHFnjHSP1zdMi09WXUr2HLKAVYPdhDW4ZSPiMwBG2hEapVoyTIfhulgohiHqB1eQDoc/eHMu
bF5JypLxcNJ91sUlG63TiGAukU1Ro4QjQyJY6wihjihSEBJThQYvmxioLiSGQYk6Tj3T/G9OsP8+
uP8bPJiRfUUkA2w5QTk9jjh3AQHsEhEQi1gFGzDzA+ny6qd48zrm4Xtnl+vbMugNPSQfiffrerDB
vd5TRJIbGkEqS7EksciqA38Ia/GsgQVAiF6srx+CJMprTYwWKrglfn8HXeU6qiktPSDORNpTSCWs
ZTzisJ1dARcIY8eRssGgECVBueEAyRiCIcpHrk/t7UydjhpJew6Qma2l+6pCivFnnMYoIVHW3IxW
M+qsNBRlisP3enEfPVyGoi5hG6I0faRhCJszTDlvccwFZoXbx701ibKUWHEOBavOTiK8JTjTE2Mz
J7XbJq6IZXCNksZpiWRgVUuCt4VoHh2qBhXk4QaHwmrjGYRjDaOIPo7yqU7t2CPXXLocNp5P8zqv
8jo/vq7AUBatiYmbpJboQl4N+/EW577n9w+Xd/fvc/ng5f900/k0y94dmG9xSTxkCsC2EYL9pIDh
+XIrXXDeE5GKDscU37c07n4cvq8upd2jWANpRmYu1Lm/Ho/nC9OuEY5CcRXAs4pLWL4ef+ctDlnP
8tuB4xfv7y+vLtebYqicR8cqCe9FLAzDnsH6ololzKfyw0M61S1B0JdJWh8Zx7q3BPP2bcmkRcxb
iTB3EXkbFdKRwNMUvtGlnpMntQRFNWvPR/LDQ2QmLcHXl/d3l7+swLf68t27PP7//4Vp2ITViK2Y
80GjzDcsPnwoj/cOnHefNA/msDXgsAsWe5oMT9xJQ6XyJmJNBLjwIWlHoi22OLPqnp8hSCCfHkqb
BgL8KLFa74DiRzdzCMzyEnlhsS/6jVOKSFazZHyyXp1Sq6PN82HFRGNHXoUWCCVgz8qglZVUM088
Fy5PwCHyOXsKmKxGJ3ljDvggyEUxiGsN/gUJiyR6wz7hj2Qs1FuUFnHNQkCqUUheWu00cUCzopDA
r8xqLSWx29IogYGNQWWh6HlAIiiKMA0ElGDUjoFwY6mUqnjSKGQ95zakxgROU1FIDlaCF5YgB/Aj
njAoBWtzQ6YFeaMwxpQPo5C/rNF9bsIcDULWIRfHt1/knDvIQUuXtRWwel+POG6KByjWwJXlWMhS
R97wtpSB+9RSmay6CfrkSldXPQjR5j8/VISoZBXDcDOLM6smWajeYiQaJwQeRhx01JJ56XD0j136
GbJD1yy3PZpNEqfuNgQVWVCag17elssIgU20lKIkhUWaO4oUxxjxIBW3NmrP7KndBl2NGAzxH0Nm
WQD5c034lpAYcQp01cYUxQqCCQ5fEECut6uJhpjVYOQ3NjS4yCn3hUDaDPO7us+GiMas+H7gWEUf
rPGeGv044jFDIphPLkZVryEQxyfFtUhWsugFXrBWS5zxT66OoIOocvdKnU0j7F2daJ90nkrL87xV
3At1m8dwEasQx5HnqRIGyWwag5mrlQLW08VmyCk38WXD9aqfxx72I7iMjrQXjsEFSQklnFe1Ri0Q
eBEp1yiBbawjwO+L0pDXmwbnwNQ20377U5R/ixJhAUnqNHI0irywXLNIizNHeL2oQSzNwzupsNfB
R7ykHo3jaqZ7Dv1mjtqfQ7j9UfscJ6WcD0hj4Ayfa9aSMxbRlHgkWluKdRmnapHpHJymZ+0D0Dxo
HTEvLPHZ/2tHwjj21u0MmqsP12PD9hdTkNTl3GT9w4Ap6+arMYqLiBV2dFuA5JXOnjtFAeOEaAwW
Ma0c4rmkh2KBUzx11LvDf95dHUPmiaLen5s924RV2cDlpC7SF5QGHaRDDfORqcA8XNIFplwH4DyZ
+RCXNzFqLiXl0U9Mi/HaSAq8D5cnCZXgEmjndU4BMSk08c86soeTuhabi/sy86u+skAcN4VFERzB
+NHJ8dJIkSESZeCqEl0uqFoZSWlyrpIIVCrGl3givGVh1ccxq2mddG2zT4rluUZRuDwG7Mkl42I4
+9QaQjir3kO5MCiXLMegOpO3dskaR15d+NU+zOwwYzkV3i/DVB/dNHcmYWG9w7/Yu7beuG4k/Vf6
MQFCh3eyjPEAc8liF8ggg3jztA8Gr4kxsuTVJZP8+y221fKRfU6xm0edbmOVp1jqFqt4Dr+68qsn
5yXcyrq8f7aXNpw+vt7tkFyK5V56Hu79Ls5tQe9FMB25ZS5my4ILkgH6UVa4pGXkx/a76GdlF9KG
U2UG0ob+y2suoJRY8KroLrjj0FdrTRpse0CW8DO6b93mYEKbhFfnyHx6ZKqa7tCaivbZ0kbHIJzn
WbraQawe/+u8aOtmlLze/nb/sS3pCl/ocltmZ7asFmbHUN0OSMRNuWd03Uu040i0m/q93+58xnzb
iEdjaSq1zEFLDuOBuJ8ZzTa/4MFu7Pmbd+U25HAbWj795iiK/CVvB/bgfpa3P19uw4LHqzbBUpvt
8HLzP7NE3Gsl+Ol9/uDi7JZ9s/Vzblvg1+jHlkU7hjT/cXWHoPp4B6bA0MC7SXKs3XiyGUr17eXb
m18WhiitlfJvA+ewI5GhTMtJvGO6a9Gup2eSLqPX6jhKPOQok3QCp9ky2vUa7BPWRoYovVBpiO5d
WzIRaXvtt9PlaYdYRVVqFD5FuaujN+qtgAE/E1ICE0p5lk3VDBQGHdqIRvF9bIeYbLd8pP+SMk+R
iPwCPeSDtFpwmUky9JMcUrpT0K4v2eJrinGgSqWKoUQJ2dh1mi0jO1HsYNktaFl8BBGE/Pwa2T77
RJbdbK/AMl2exjUDEaorwkX1wKsbsg5ORCajzUzYDIwXmzDkN7qYaFX2x6bI1DQ5h10osEyVGQv0
v7R6CqXEEmrRydQDyidLFHSJBxEtzyXMcqBMi5SzEtIcIPbwy6efyCdK0srzouJMgnwf+cgddAdk
8mcux4K2eFpaCmCWEr8rHMlIfRKEpbuu3PrsvcjCJV6CEjPXA/cAG6BMwGm2jLzh7Aaz90mZxI2p
xfCRS3kayMu6rpd9ni7fI3s3EFR0YEPZZZ+VjY2eiKkQDbMmZ1alKkx7W5LRGcLxq/5An/uF7PNU
mSdytr80K3WQVvNmy5AtF6c4pEaQfe9uPedaDEFZl52VaaQF3pC1+NNsGZl3cYOca43vTFl0Wnkc
SSIYQab6XY9zbbp8pxm/WNxxleWEcy1AcUIqJsE5VkMqzINrbW8uIE6it23n6JSeEte2+u/3VJaU
GXK2f5RfHpJ19FjArrPrqDB0R4U7LJs321GhS+Ke++jl0JkkeVROsmVkj4dwh+VWHsBDtfR7rjrp
IWI4o8iLRFOpust3OjG5s1ABoubqwScrNaM4zLQxGr6CZsmEyKQKgoM2ypqjY5ci0zdT/ZeUeRqf
7EsEs0MVW0A3RQcra/jZgetqnAflylwRvxcMG5o63o3kOibk8Y2UHUTwps5R4vaFo/ftiZjQwUMJ
iPfKqblKVF/Ks7Ndhqx5+PW3lwEQuDjikeNDfjdJXnOaLSNtlz+MleyeVuiTpJpLqiCaBh300Gkg
uUweiXiYLAukSNNvLMpDbNnorWZ8q4CbkPXQdRxjSXZA3703PFmeNveBJ/yskaFouRudpVQsUhRW
igfGc1YsoITM1Zx0MSZjzHJsc0+OPX+k/5IyXXP/+uoiXKOFFnzzVfkNd+ftu3J5Gy6+HLu+qMGC
AT+7OqahCSr8+tSKyFFV7mIUM0Q+e7yHZNXwNFtGehN+MLUieBLJc467MXJF1zgyZex7qZXp8p2x
IBANdy2VkndEuVk6p7XlLBWfWDbBMlmtZCVmw22xWeljp4wNXWzzC6mVqTJdvPoRhf/PcLv5rvFO
v8dzXzbfv728+22jX5hOX8bDxNBtQxo1MBRjBBb+HRCFvvuexXCDa+IDu72+unmx+e+rzd1N+QT+
tt9qCPW37//rm4d5o79f3V23Be62bW+/vmP3v/jmA9ohim22hpl9QL3dr9l1eX918xbh8vd2JNqf
xXfll/b/2794WW7/fXX9r83Hj32zKS9+frH55fb2/ctvv/3Th53/87d/al/78wYx8rLevPzw05f3
P53HRji7tDM9ctavT90YyNZoI7XRI+U0Q9b7TrNltC83mLopVoN3zvgshsIEINPOvpe6mS5PY6NV
yUCI1aSy48+q2gYQGlgQIbEACJCpSsOKViJZVSsC5bGxEcgeD7+QupkqswYb7TM2rsRGS04OOMVB
Ry+BfKUOa+aaw8YQA7iUrMDocuDMW3lurralx676w0YYPoATvhvJOtylsVHaiCwkNs6y4C8s32k1
CBIjAanQURS7sasS41mlBaumoN+YTGa1akRJIWItwskqjj12dav/fk9lSZk12NibMPeMjV1sJG+2
neSg0yTt/pB08zw28qK5rwmMtSNj4a0+N15FS1+lgcEpoNFWjrDgRbBDNsSQ9BLQG7U5Xb5DOS7R
DXTeZvz4rl0ha58zr4iIsjKI0jJVECukgBKN8gaFPTY20slsWBi1OVVmDTb27jo8Y2MXG+251Ucs
zRsO61tUQYI3ghcf6kisaO255RutJV1tGCWYQEgIUQkM8cb2icw3QpcgYbI8jY1CZceThJT0DhsT
F0o4AGYho9+ouGbcaotH20rpYpK86mNjo6Ut1kJ9ZKpMvx2iXN7+8Po5u/gUSEimh09yrD0ZeMD6
yguP0UruoklipDHMkpdDTrNlZAQNg5WXnF2MMktp68gNMuvJG2TQq7xMl+/djLUIYF7mmnaVl3Z3
hYPOGDyrinAYNNM5Vqa4E6bg44/x2DfILE1ADAuVl6ky+yPhcy5xNRKSyeCTHGv6tgesr7OADsF4
brSboRnsv+GObH08xZY5cr6ggME6i7C+BGPBeTMSLztNdhZBr84yXb6DhElwhCtbndzVWQRXopoM
zEdfmKuA8bLShXGJgIh/Nul8bCR0dOIHFuosU2X2R8LnzOFaJHRnFx27TnS8vqqii/LFWKMRDEdO
+NlFx64THQ9WVWQRNTYiVi1HWGVcJzruVVWmy3cuCyBySe+U1rHuunE8+v2hNvpAnZjIITAH2TNj
wOgIuvBSjo2Eneh4oaoyVWZ/JHzOE65GwrOLjl0nOl5fQ8kuCUg+hDqUJ3RnFx07MjqWfLCGIoQt
jYpZFT7Sv+k81XvzSKru8jQSVg4ZICoUYMcblZ1qg1st4yJUVqIDhpEAMDR/QaUotS3x2EjoqVrb
I/2XlBmvoTznDVcjIzma5yTHnIzf8fPrL8NDkCDBoSUeIa/wZzcsyJOjafDDgxdK28VG6dFPg5G8
oecURfcjqbrL08gorTKlFlNr1buB1j4JFyzioWzZQqWB2SIMy22sZwgRzNEvlG713++pLCmzChnJ
O6TPyNhDRi/OLRSkJZJ8fUWlci4SBDw5aggZxbmlXj05KkPywYqKrV5GxYErN3dDsbtPkuq7eSRV
d/kOMjplJagkDOyu2qvgpC0yMyOlZ5r7yLQPisUqUubKi6qPjoyStlcLFZWpMvtGz88e4mocPLuJ
JJ6cSCL5+nqK4glkiUU02oKB83129RRP1lMkH6ynoHtWdIhVRzeSbfWa9hB79ZTp8p3e7OJr8C5q
JeQDXVIbsGQFkzIXlooITOboGAKgC5Ach3DsO32ebO19pP+SMgfg4LM/uA4Hz66a4i39+qyvphge
ANCxFGKWl6T7fpNZ8pNsGUlrLflgNQVyKjG7rJQfipRJjuZHUnWX7+QQqy0ImFaEh2FMIgTIrjrm
ktEsFClY8eBYljp64DmUfOxqiic5mh/pv6RMFwd/QLkvynMK8QjASBZXJD+cZPkxBsnglJQ1RjXX
5ddjg/FkHUOKwymWP3tL/v4yFmNtNjwZkYdkJHdQHEaqc/MJDTQHG2XxxqJbOiLc2dFAbyVahkux
QPBD7cun1D6PPjsvA2lIxGEp19lcjPc+Q6myqiGbcnZU1LREUhyQvprDieCCR5/el6jd0GtO2iAx
mCkqXKA1LT6FOBIhAZ3ZFweEusvoFZwOaLd51nmEZB/auHniOPayWdMt6vSCVPRTDOe5ND6irfci
XSrcVsMqt5lFkSOzSQgWo0yl5sodV0f2Xrb67/fmLCmzxnt5DutWeS9AsoFLcUBm5P6EbafBNb8F
I/RGLM/jyGgIkOfWfwHk/X786PpRZxWczC4IJ0fSbiDPbdQZSLI5QgyGmxndVkQ5fL3ynKnr7hNJ
ifBIqu7yvcJs4wcUXsqwS7tVjFVDxXBTSK2ZNDmwkMGy7MApi05PDPnYgE1SIjzSf0mZ8cKsfcGf
I861mK3PrQMDNO2nrW/n0+3qp2zzAOVciNl958+ORQLIywRSDrbzWSGtS9UEX0auwoAmU3Gy1843
Xb4zF51rgY63F0nsmlZ0ktXFElmRGZgp6NYithmG+FiUrL5dHzk2NpIkzY/0X1JmJTY++7PrsNGc
W84d6DKFfAJKBGudNCZaO9S2Avbc2laA5NFFOzBIFxOD4FJ5DLhHWsLBka3OstfQN12+QxmtvQIQ
1rgHKi2+dRxNZgiskWmrOdOhFAbGOJErgmU6NiXCVv/9nsqSMsOB/rPb+ATQSF7kPsk5pxP/cn1H
n7SmsYW0ZNOQO3R2yX8gOWGlHMzTxjY8S7bGuHj4LRA8nJwMqWUvBzpdvlPBRRSqkBHt9A4aIxcq
OROZl1oymThnGCRkFqoSJtcqleNHhcZ7/fd7KkvKrIPGZ69xBTTiDsrziqibRGRELdc3+aUiRVbA
Iy+He41NwPMqsDWJqPwnosuqacKuWCl0KqldPzs0n92Eo52nwenoNhmEKzRTbnbGcfch0qlAeUCC
dqbC7KD5u4VXnQ+vvDfhyDq37I1un+5Nh4IMuFKmhmzsw5TcNpDRKMNq8mhUAvrbEnJzur3TWVrL
szm2USEn9z3Sf0mZfdsjp+71XrNank1K16Qo8pKDnKsydM7QgV0aTQY6x7h6/rv3NVhpo3Dq8KYD
lO/MRqI1iUhiBzOJSHDny28ltfxLKV5b2/qp9f3ir8tNG0/0Ao8Nvuq4Iff4kDxYmTlP+ESNq5xX
H5NXKVhljRdpViZyTJtU68e0BXzD0A2oqZTDe22agCStyXTT/vnXv794f3H3c3N+vQER8QXRht/v
2k+X78J1e8j4dm9CRUd38/CFr5owr354H/73rvxY6sPXWfs+q0JlZmVs437xrfOpeFXk1/PSnlcp
oElEOi7qsAzhx7ZYtEQAKVoLh7M99aVSS8LcpHC5ubpsIhgHSXrtnY9zNCsYuVlveAoxmjERFtZa
9zTIEoA6IMK+uUeBm4vwK562q5/ftn4jYyW+ripDjXOnbarHrHyWjLWn8s2vj96JQ7wGF6F8Alf3
784OrYoRPjoTkq08gOJFFPwPEQshX2WvNu+vri5e3V7fFVwTAeXV5u0NLpPCxZubO9wPNO7XH34d
7m5/edP++eYG/y7a4Gv0Ll7t1gGvdDWhapHA6saLUzGUdxBKLbpoWNwGouT4cRfQdD04R0WnAFWq
WtW6I0vehhh7CIOCkPkgdUCcuBMURby6u93eQI/GZp9zsp+PLHu8l/OikYUPdUA8thOtGa/7mbE6
8VoMFM6LmjlF0/2dF47isnu0b5/tC3iOFpOXzO2nB+hTew8JXBZScCdwJx06S2jsRdIm6pyksCOi
zfX3LuF+p6HQ66gxUAEB8T7uCRi1WC4Uq7mVX4uxrGgZmRRFJpe9sfW4Izua/nubwyVlDop77nNn
z3HP08Q9lkx0HMlm0wVDddjk7K2A6J3o5AM3KSs/17vctdOevN2p5tIX84t/foh3n0MQLi6Dxg+G
urvhblWuznHLrBCGAWTBgoySaS9kVTl6nuamy/aM/deH6r7f85hXZQerH375ssUDePqsQJSxIrKq
0dN3SuDJdT4xxbMyhgNHs7z56vvmgOxGwn49/5J6MjBW07xXukBBfiubm2uGbkt4x9qZaxv9ai9x
pqfz5VvhL9m/yu+vtk4S242tbY7R1n+6vrq6xYN6c4OHM7+6vLu4GJF+3939x8dgazvs9v6zn0Za
u2+y9lUmg40s2FZuQY9NOV+z0guRlrdkoyVhYtHz81xlA+h+dExsEYJXoaVtF5qNtQH/yRXG1T6Z
gsLOS0aW8qfPfyLa28s3bVzwm90Dakn0iudLgahCdnxp4bQRBX3aFPDtgMYIW3xx3MTc3BT44EvX
cHGzc6a3L8Mf6FDTxdhVezIG6mTxdZ/X/OYdPo5/bC5+fYen9832EzfXkzdbcwTKmDLzvFaWcgVW
IwQma9VFeB8k9yOSHZBXm/FsRY14qILwWs61qUy3d164ve3OxxSW1lo1+I+tAEu+xxKdWCWUC1Fx
AYh+OgcMAXzCn0QMGD5/j//Id/jMyM+bRPSp2vdpHGNxvT5zCLaqiiclejNXFeu5+oKTB0kfkPma
OUgWPARheHaz2afpLs8Ld16MB00i0q3Sg31xFmFQoU3SfKB/sElFGlPd64ubLk/Hq0Vlq5Wz1lvY
XYDLtooAhiEiOuY4JBZM4aw6m1K7qeHVca/v3+u/31NZUqYbr77+6fV39/0ekwaQ19u1NrB5/U99
hPa4199/9/r/U+gqONn8rhZKdiHnN7dXn5bG0P/wwokiTGP9f1y4m/nGrDyCTDJqdcwo5er6LTp3
GKT8Gi7uCvv4Or56FF8dGrsIQXsn817mh6BAFBM9usuqDWWlg4Ketz0vGpl3m2437QBnhQ/f8mSs
6QQFIHNyPmuMWmwMIhaeOHp/OhmdMdCacab+4KBAkG1IJ7GBdGPUqqc0KBCZgdeHdWTOOVkC0L0u
QUN2hw8raALSXsNAiWDiZGXRKGVFy1fNXsac7PK8cOd1abVJRNb/9CBXnDZeC4UuafWHX2BDqehm
KN3jipsu3529kyXPRVW341kvPESfjWDosWgWQCQWlefMOQdGiBKqOS5XXNOfPvbLs3celFnnZAmO
XpZ49rLWe1lqbzPb97JcsMHkHLVJfNTL0vTJmjcoHzwStNVCYvRiVHG9SmDH1M+Ldl7s9E0iGhzX
kyBko4IPWml02kZwkmyWOsmWkVO2pR4kQXCgquLFg0ojPVvC0KewR4IwXb7DPQqyWB94/Mi5V7Oq
XDvBMATRTOgsWCkxMeu9B64xKgnHZa2513+/p7KkzBPYE/lsT9bbE7oVR8N8lHyBe7O5/f19edXK
A9uY+ebV1qd993/sXUtvJEdyvvtX9NGGnaN8PwToYGsugrXYxQzWl4VB5FPT0JAckxyttNgfv5H9
IKubWZFdVWyxbRMCRoNmcyoyMivii8iIL9Y362u/r2uaGN5qNLwdCtOJTrwyNBaZNT2+ADuKIUMy
8AIVFryFiNdHC1BHwlupo4e3pMjXjyHRioBXMcl4jcKiXZopEJqoV8sT9UrLoDQLYF2f13KdYC47
Ak7IPDdiSO/AhoMn0aU9oXmg5aZwKKvtqxwwg4bcasK9xqfb+4dW6b1mMcckslL+OU46vAedI+G0
1ttHWMAM4yyAHy98Th8pM1j5/YFU3cd3rhJMKKV6cxr2E2Y9B8fujIcoNxrCpRTEAkAh3BRq651s
1uedJtZd/4hh2sYiEUAzDSyxaHvZ0Z7LGBXttAMzpucXAEziDTAtB0ydnZyQsGx3BUXHRAiOw/+e
9/2dYJoseimsVAPQVYyzhXQvhuTwEja1tJuUleS8F7JB03SKilCYqdrVyw0Ao4uE11PqFIXt1H0E
RWOCL0dmIXZLtJgcY3a+0ES58q8PM/FJjIt0Mg8E4FVCakKupIWZDLNCSeMLa+Xdh4toC3dpXVAM
50dW0/IkbQzsEqy7dtzNaYhiFzYrskqEW/JptHtPBJeeJRs1pa7Zt93TE6do5+tQqu7jcRAnwf7E
JK13as+vGUTleimeKJ4lKSV4YpJPBHCyUaoaVBfPDOI4Tlo9XP/YYl4AKb0VhCxHShwf4TniUnbN
U8FmY4oKQfbgeM+1tkVDvZ2mYyDpqDokOBVNtoZIGjIBtB6JMoaR7AR8rIWUka9SLv7r5wfy8cNp
1SQToRZnaEfjcC24584ihaKoUbJ0Ci+k59lyYWIJqTYLU2U9U7xWoUEAKfiroxl+YeM3exIt26WZ
AqF9Yno5saIvyetYTAiz+uI5Og+U62VJMy0VnNtITWl0Zx5quS3cZRFlgkQcxct6ZkrKMJ54MJ5J
On0ERZUK9QG6l5IaPr6DZjxNOrI6kmXPQsOM0RpeLZKKp6REZ4jlUZAaYFuILwR352XE3a3/tF0Z
W8xCNPNWdPECSIajiUXd4nWuLnDDMbNz/1cfP9SKf4AnOcQEJ+yw4qLx9aYk+PRSLRvApebAj4EL
i5EVXTihUQciQ1AkKMUJ09xLwF0+hJoX9/efCBiLL+T+jpxeDjsVwOAlLSOucYsTjRTa0KggSFEd
nNgDLW3R0B483SAqaHttzqRVESxQkb2iVkCvQSiahU7RGsZEkYB4snVUaZHM62MrfBrsIp3M83wo
oT/Xyyo0nTM6cfjDqxZTwnARbeEuaxJLlQhHorNn1vCUikjUB9eYWdPPyvbkWl4ctZlQngr8Z+Zc
r3F5cZhP4ZhvZnGUZdxmD8aGqVkZLIWO9NItOtvNPW11fxufc1V9ztX9XZVFg3EPmbJQ2IHDbP9G
Wx60w0r3irWG6sAxKGWaquSUyWp/LSo5BxQZZB0UDRhUMkOU14UwT1kJktba9HNjUJySSY8Uaw0X
sxiDvhX/vggORcczcMNeEv3df70HK5TI+tr/lM8LADVqxsz0Katg+fcXPTqYJGuLbXzuvk9wShrN
xo+AnR0Lg5LZF+18ir0cZg/0zRDNtAkiWjgMvJH38MxoNY5NS+TOFZeiZ8ZzKQF6y5RCsdboOpfr
9bGpRjGEmZAz2jGE/rK+e/gKoleDFP1u5mVRhnoKMrhGa/QphwpNvS3auXk4Aq/oMxNyRw0ETbmA
oxJAJU04MVxEUzh86rqZVnBR9/TLp9/u15vzuP5bdfCiKF18gJOsZwFXfAC5mTZm9UDArw/rz+v7
/bHjEd6COqG26OdNUCfIaS+tuJ/jhRimxdX2iPt2/ulq45+2YDFS7YNW3pYQ22Dx+JfaUuFGZFoL
WysQET7ANjnOg5wFsPFaDTONr+vQXwLQZqoUIyh9Xhhxyhm7uBjJoddjI8Z21zLNQtSwSyb74/qe
Yw/ec41t0dDksJkZvgkBgULRqtAy63Q51DvZKdXU73/YHC9wnld3OYLTur/6KwDq7eDmEGRIKgv1
vJzkhIPmULYB0wvqhkrqjJPSTCRaSkwx7YO6UHLgMRLDvarFEYkwyyLxHlwIZy7lePaLBbx4xYwE
dcPFvExH54vPTvn/FtQJnJbGtoK6LyFt6zWrYzstnNtVdu7iuEXFnQKnrLEn41edTJBS5eKCwyMP
Cx7TMG4LLFVZcJtMUHj3HMRJzFP1+vxvPZ3wU3WSN22unOb0SOw+dlMgogdjHWUwXlBNhcw6KhZ0
ZI5Frl9fJ3hlymQutWeVPx0ytbZMlzWTrCfRsrdppkBowLXoKM8UCL30tDM45YcUHM4q6gSL3rUq
QYZanSPcstsnrYPUtaPXpdYEvqGG28K9DJNsY7TEi/OdCrxCyi4fZ5h87W/y0aQ8h0REXBybj8DJ
c87DFi3wkhY7dxaXtULDaZaOTZ81WaVCb+pHrOg2zEvBZ1Gc8uqJOnnE5fRwSFs0NFy3E8K8521r
zHDYkORlbpEb9ZimBc7W41p1sAfd319T/mV1f73nPtt8BmHS6VcFL9VwJPASHYsxozkhnAMNaW96
+9+j+Z4jWncS2+DNwEPVUJJkCvy3lGZf0a+yAjPhCDXZEeEtBAixjj82zPGiqbXx3ORDAh+TZ0cm
sQ0X8zJkEW+h6tJQFaeR6vqbj5uflgoiTjIO8Rb0lx/yu7MI8+DvNq4PYqHPgAp+3tG4nyTaeSQ6
US1HHP0Q0a1uwEbef4Izmep2wgch16XV2V8/wWdwNPxqM0JnRTbf/eRv0uf6jev84JN/8KtNEQ+c
/M3B/XK7vnk4yxq/n6HsVQHHcP8ppxGJ0PJBd3plvQJJA2BVozvZCE2lyZla5ZwRyelAuQP7p0XK
YJDi6xNPCoFCjkU6mQca8aJBt5ABI2lFwbdB+N+a4zpcRFO4i6vRExLF2G45K6b0cHqMkCY0Z092
ffrFcasJtDqPOzMHygZ4X39+DTTbWcxMFk2uRFEZrBdTYc6mKzSfN2JVthg7gAnLNRvNUuxg7J51
bYuGFsMMd79TUsFBQyqzGF2HOSrSFClzgkdZkoa3SQRDXZA0ppwAur6+E0BHdS7TybxXFGfNcz0W
1uHx7YykzrUi24LI/rG12QbLDBXEZ+WI04yRmFMmShrrM2csZnruQAhnzXMjLKzDxbwMCcxbILQ0
EOrs5LIRNtkb6aWNwjeuxg9fx6Zw6FBLQVsXiicndcCr52SMJwzCcpJSLiQEygiYIu555DnZ9HJu
UKNJvRELtiOXTTTbAA5EG94bK92x5NNFO1AyblwFIAmRRZRUHY+/PnI4tOhkrOFghbzwPNBiufYJ
DBEPMib6+g4HpblbppN5DsdgmSdBl9U1qlKY0tqp4lu51+Ei2sJdGoeMMJhVE3TCVdZI1JGLcSqA
K2N2TgeOQCstX0VlaE0loIWFUcfva247i5l5s8Nj9llzmbhoTWTrbrrF2onGrMrWCYAJd4rGWIzt
ZfZ71rUtGla/erD7uMFjRuqsLNhYfdzGeuQEvPMs+VQnoGvuXRFSB5W4F6Y4GZl9fSeAVs8u08nM
VxT31L3rl+Hx7VQKwlFN1sOpeZz94Iyn0YRAQtSW1BIdAkvKpAQtjXdRxLO3f23Wf9pbPbaYlyFU
eos6lkYdKCWeoMuiDgWmJWQBkYdvJVGHr2NLOEkvrbtAUmw0xZgl2vMKcAauILLgSsdx9CzyqGjj
O8mWk+9YKl1mmQXVHL/dMxoSZWETjLdwzfUxrnkpYAIQ+uLOFupU2Mk1ctJa52JxxnZLYF2wMlmn
tTGCRWFL4TZKTsEhhEugEN3oBDkzMxmIUuIA43KMPM2Zr9mTaslOzTw6WBADQeOy3BGnmUqfnaMt
sD1cRFM4tGT3YA+7m9Xha7LU8mipBoH2bRW17ZWJRIrTiXDwNBDsREccIB5nDPNalDODpc36TzvD
Y4tZztf0BpQWAiWJctsJ1uLAhqh8t51V62Q7rPNDvr79xYfP+XFg55Nzg8U+gMkkm09ArT9vW+0n
NNi3on74l9cx7zW57zn+7hv4fGtWdsmBiQ6U46/1yezOikPUkgpngBRxd6Wi1j54z7KSrEjpwXGB
WBresEp98fqBak8nbcewa+0vKjsFANGKY6/9rGK047bbol1aQYJEi34FW94TG5LLEiIc7dgctkjJ
0bTDohM+U2O4DVrKXx5pVOCPCm2BouEi2sJdWvmGRCuRBZvZC8t0MlyEpIOd0wsrBVZWcCBV9/G9
4ewi5RRczQnt6SszZxLiSGJzFMQY+KMkwYiWNqVkmbacnRsOodV+B+sfW8zLUAe9QaKlkEicbB8/
fhjUHgRX4OjI4ssjsH38+XYnV487+QwtnU2Sfb3suwFkuxqDbI+TQ777ywa+gahbEPXfTfEknpo5
Rbz7axAODsfmbufuavel+7tBm1QJ0nGXEjE+aZKSKIQ67YlWsVLtg2FPbFX5Sb5r3jxIiV6KHLi7
x9bKLA0vMeeUn12JH4E3I0TQpShtk6KRwW8px2p/ZXSRUdcg+vk9gRtKFPgqzguV6PTdmPlwHGhM
G2PRgmbFA5zIgsIWzZmgLtFaUcEnEEq0OiThtWPWK59Cq1hmqOW2cJdGWCJRuj7Bp+WGnwgvnODe
eQ3izWl+lBpNpvMWVc/Y4ztISBZOJZXWebZDQiaxRJ3NBOTKJGhh4I8ciPB16mEsCYKxcyMhlKPu
YP1ji+kiofc5rP3N6sd8c/PbSr2jZ2BM3D7ifz3w+ac/lrKOa/95daCz799/8/6/3q825E73q3S7
bYv5+uXL7d1DVcIWVG7WW9Y3afXDxz/uv7zRYbr9t9WXzxmUA4IUgJ8Pt9/uJYi319ewxQ+/vYvr
h7v1r+/gg2/qUf/sf/vm1/tvtoL860aQNu65uDmb0qCFgnxCU8YY0ZWyXCUOkUqZlbtHC5JeR2W4
L5t7x8GMKLKwIu2cbgxp0VQW72btB4/vFVYHZa2wkbM9wy0P3hbQL5E+GwCxThIhowUbo2hw2fJg
0rmNM164xEey9sPFnGqcPwJ+z3/LK/1mnhHz/MMNhKZpY0AfRTtS4Eb+ncGuz7v++vlhTfxd/PRk
lmsj413+n6/ru5zetY2qu7iqA7xIgy9v3YK3I+qckgl0DlMCLPPiVIaGT3xa3ekTb7c32grBtU5z
ik2lw3H4hJT32BRqK0Lh1voCdrDBgTfMKYxKiJh91TH7QwXhZl8V76iwwnBG92bfuQTOPZNYalON
1pawlCUJICR85FT25yYW6O2Qapv94WJmmf0XT0a+mf2JZl/h9VN8OgPqcLxwllwAIBLK5ee1U/3X
UnVqKKbm5o5vFHvJuVGZLsroK5RlTPDlA2tlvSDRUjCW5mQ8FMpHNSVPPVM/eKQxo9hzQwBxtbn2
rBsJxyX6aMD7tJh++6f80noxFH6hP9RYWyORG8mtkL6kDvWisClZZSNL3KskipYGvJ7TRRhDPViN
TX58W+r4e6fHN2oYPzhiZv7Qcie0Kzkb2ioP7r5NuFSzNmfmKUHtjljGRKG8Z1THXJxtpcqHi2gL
h5aVil6WdbhJnSyrF7kIkRiV+/tmCCm8c4YSo00gNgdJcrKZ2ACmwDKuFD93llXhRRNiLMs6WEwX
0f05fL15+Lr68WuEHfvxt5tfV4y+o+cY+Px/BNa1ERhaQXJ+74iXi4gJebg//cf7d5UnqXoi7a0L
IY8MWOi6RJSJ6ECo3tOfv7yPX/zwbeCOVjIDUXzYvbuFJwbI0ZFK7k2YrQUjytb6Q2NzVOBEVGi8
uz0/9i9TV3/aloysZf/q7n/8bf1bffmcEjI7qUkxIROegiORCr0ph8leCoifffuUorRDJ8m0PaR/
eKI/rcRVj18+Zj/d/yqpv0uYFIo4znPNiPpkimIy5Cb7qUIZf14FTkm0ufEU3e0qMK7WIN2mXMM/
PHiI9KrSvp2mtNX93bfTqifaa1p8RtvW5GltEMqxkBlgNqXp80rGw39toYxjTz0uQNl9aXIByhzx
luc3ea0SrvOCKof5DKQpLy4wkWiebrijTwkBbrIvioqg0jEP+jEPfGV8D0Jn6jVgT8+54Do4abyl
2dvGxNjfMxpReDRy6trnKR6djynE3MRyElrRzER0c3rrlMIjkAmJ5UYEYn2xwSsGIKIVgQxV2xYO
m2NwoLKubjo5ZcY4uO7MI9sPbLe1xVRkSjwFP2+ksIRKrogsMQjAIwpM1bkjEIXiWjGWUx4sZn4E
8pZYnhKBmEur3FL4NbRYPsEYwnAvAwUIzufUCUBEcHEqQ/tKxMyyf0oLdYJbkcycK1JlcSPYK/sf
Pr5DGZHB5oHzNhqA09YI0qBFZryQ7Lkk3miIc0qpwY7PgifninbnNoLogLmD9Y8t5lQj+AcP//Y6
/rz6Q853P4NhA1PInkorVv+cfwXNra8Bh/jPb5bxNMvoLq27R+E3tWJ5jXJgAB1YiEnrOUGDRi8U
X0NlGmdgkFPG8A3xWTRceE+z5nGWntAU11Cq7uNxyyhMpjkyFqkKj2Q6WZVoJLHScKIrGW9SLhDA
mqZ2WClz9lkGGmWiOFj/2GKWWsYdSHyzjDMso8YvneWEu7Gxmh6VnIIAWfFYmhObBmmatoTYDcir
GCL8IlourxI2IgchavGpm4NqNbu0QEDjl51ywu1EozwFQs2YRQat8FaE3z1hHE2KyGkJvEfLnpMv
xspgWZzDLa7x/m05bYj24UxjG5n3zlkvm5wofYXhPk92fN5QM52UCKB7So20ge5HzSaqkgTUT5IR
nmTjIvGUQjQgHIhNowpentvn4Zeyw/WPLabr88D9rP79Tz+sPr7/z7Yn+/Mz5zOoMfOrwe/v/M6B
i7vOad2+IdIc5ayVc6o8n06ehi1i9cYsNgo8Tzh5+JWanJJQQEYxA35KLLkiomjlM7tSStzaTYjh
64VGSlcPt8deFfyDCcpymprVJ8tEXOgiPv68/vKlfu99vr7ddbID/Hk8qCFHX7ETwJaHxyO7Pdy1
0vF6fV8P7O8u9jzPhndHyxlVaU+ceyxZ53IdpjcrNJFoh6JsJW1OOm9/B11c5VJy3Da/N36jLQ/a
oi0bFU+PqtDJMecis8H6TjVoz9K3RXvZC6ljmXo3Um2ZTkdx259erW/WD0cH4+/3darX1y+7w/aX
v96tH7beAL66HyfW7Pt/oee3D31TjPpaJhcM1xDUulbzcvfId26STi5vaMx3ffkSB1zauTv8OMbt
/QcIDdMtgZfovr3D6vTGl8k73BSjgnV4NwGq26TcnA7IF5L5SGff+/jp+fC3gXTl9i6vf7rZ3Bzf
vxvR5ukFK5O1OVHAigCcC2BoaBRNQqS+ntF7CMXG3Nlg2p3TSifOrebN1BpYQm2jrqPJ4zwRRp61
yJ+jg0yOEAZsyj+ou5LeOJLs/Fd4mxHgFGJfONCpDcMC7IagPszBByHWFjFsUqAo9ciG/7tfZFWR
WVWvXmRmcZEv3aSYVfnFi3hrvKV82m3Jp++gRdsBl1yXFBXoqwdp8iVvLJCHZ0cz5B6wtxjU3ubt
b/G5EOezwNfSak4ayJbPtcV3305TA3LixD8JkBPniMTTjo/JrjCWWMpr8q+XgV+AZbvn/7F56p9f
h82D8PXNNLhsFVNv2TCgyQZwiJ9D5wd45I9wE34vLTgKShf0WQ1pdBlB+ZYLePYZ4ZwwAWagauwU
sgPHDjgKDR/2t3n+ElYg2m7238PGnGmM3Lp0tWMyFnOd+LLfwxVw/s3F+w8XYDzfgdX4etj3xWRI
Y5nZRZh+2U8BcwMs47guL7gXb7lxb8dLAbSW4GVw/if2od9vKbB/uwh7e3BXhtHQDDc/wF7djawF
+/OnOSWzlSkZKdcrSkv2a2C8y1ZLG6p02CXn1CjA8ZG3sHrFOKSDkjKhRI68SJNWefCajMU9d03B
+PrTXrFGGsLuL187kbj0wmjemeJirWQhy1Rl0jUZoUOUWYHrpEypyrnXrB8zhiyjm54SnAzSeMvg
OSZcp4zOsRqAYD5VsCbayU1RS3CXeKkiOStfnQzzmHn2aVh3LOnOU6v241mArGhc/zitD4ilZBY5
5+NASL/2xBgyEKIX3B5hzXYNi8EGz0PF7ienG42DI9ss6fPyfbORqkTJLUMrDqebj4Mjqzymm3q0
aRx4h/kSgwmH8u4wItgrNMKhkbcfz+QQG1qHL+ssMAJsA8jB8Y85tpbNa/S2mV/RsN7k+RWMtrsy
ml+NZK306jHol0o0uog0ZJP5oEBqD+D4xyGHNsLKqKS8uATnvgH5cbGz4a5uftblcFFB9IfBM64G
kaQaEmidQUqrUrU2uWL/Hy3HR5VZ5m4A0zAMpQY78Ai/5sBFqskDh9WfaznreJPsoCf1govGI1mW
jQEh7njN6+K0lizc1uSsqQSmSWnX/EcjgI6GCXQMJhwamcyssfl3uOg6Tl7YPffxMgHngOGvnK27
DkFZyci4lkM0PA0lcz5oBZxWS9ayBMectEjqQs82frNEctLt+qZrx5fy2Gm6/fGyXY+8u/gLsFWQ
XtZB8wT/EVIPsioxJKUdb035I7DAX486Ub/BMxAW1DHMD4Kl2xuwhMtd47Cv5Sa3/7cgx9d2twOk
hr+OmRHhutzd49EwupphNu0OSmd3zx5eK+0+ObSPDmCz5EH4IgddgC2DqIz5iF8rkTjPjNotImMz
FZWKOTDr2ap5A0+0lqPrnuvrBrz88370kz7f3v7j0yYB4VMsLYj3qW3V+FVX4frqv0/ckLr5OdIr
bnyWYmzfW4WQXmfHy6qY+NMs6PBmYXcTuPn4w8pub45WUL43rdmWCvJ5jKDC8ttgn+vRoYU/Xm3m
/4w6++rmObdlw6zbtVzufoBDD/x5A+Kswoe+fi7oxHkagtTTrJDJvKVxPODQ8oHHoUmzpOo0c/jy
irub4R/lx7sxJjB8vr1vdBrGYUwLJySNS1g8IWlrO4jCqgEXR2vXUeC9qUg4NPpisC+ID8rBx0ee
pBjcODI1UuM5LsjUnSCcSgHICP5FZwByikzZCoZaMUobm4KMhcEym/sNAF99rpSh5+2eRZN1ZjMN
yLBT1vITSq5WFGfhzCtVsjWrsrzHMc5/hrubU6t4PrgTEb+R6f/1lEIdvJJTYnW25f6YpuUsuOnS
OWdV7HBS0Mom7oGhapLcRC+kERlEkfclKmSg6ItyEXlXYRZUaiBBM1lF5UlIodFhY1POWwFu9sas
Y2e6wbA5r4EZU+BbZuWz4ZgfPF0EBs4ycmDWVPj1kzAty3wMxdS6NgnTMlJ3Gvmclsnt3RXwNxgm
38P1tzKQQ4oWmiuWrsM7oWQ25koR2pQkgsjB9GZbd5QtDo2UWga5r8D1XzRepuB4Bb+/M2vSBM20
YL5qlWOAvQEzpkbJtI+eC/nqNsFIk3nHcDFNVgkRSw8hNucNIdasNRcVwYJljAiR6SJQcJwMphms
j9pJIQIbVaU0mQfh1woRurHoid3bMJusJdjoJLBkj9l6pxiHRisDdNLts81pt4JMeTezh3DWrIKr
ze+wHSPGaF9LZdr4lvzOHTc+Bm29sMyDbYM0P3pp1qcnp55Fk3WsT1famfOuI7UQPMNh9zxgtUTT
RaDg6IGbJ6i1vUOGQ5CVDqCdUofVeqfmJDSCbhY3JbbndTJUurU+z3dX39vUIXya9NXX2zOHSafc
nyQNzyzlb7rB5ZQE9FkG9eNjidF7W2j+Vt7A+g14hdGJLF1ICaxzLpRXSqb4E/A3XaN3Fk3W8bek
bY0Vt2TT9mKgnGTNPmQ0F2K6CBScoploQf3YqQJ8q0MIOUYrkAza/cAYjpCW1/vRtscOD76o0CZL
pGq6g1IfJQB6I/QUEB7urSby59OR/EFGo4JUQMPMlh4zaRf0I8FGLlRbvPPKJX1sMc7ZNPrMz6HY
jKGtyhpvYk1DEAEkcWuwW+GkD7VwHoth3uZIDG21ikwwNGjYQBcWYtLcZdUZ2pplsCFEVTg4zEGA
JgRFaK12xQsvM3vVeI6l+0DOXvs6kUi/3C4IJh01F9Cgir3Jgrl0PGVoxsmlW1Ta86I5srjY+kQo
b7H6wil9cXCkILLL+lh8BVzfr+7uv8F5a61otlHQBiMk45uXFo4vTeeQkPRl7QJfdovyy+cfX69G
ttjcM/oQZYw8yYwYtTMAGpqMy3pb7AH8dn8FvtwDIbNRALOKilRQz8FJE3KBZ3DEJpKB5cGYbRXE
a6DRqT92YVreqZMYlU2+MKGdWkVAS+vIZZ0QsJPIQcY7nlwSEhva0gVI53TYBeYXfRIL09VaHlyS
WA/sPk6SY9xyY+PxJHoVi0+paqePu8HMgUaaGm7JeBWiJ0d03BllwTdlWEJ0F6Wn03qXXh0dBYY7
d0c4JvpidG5CEVKs/uRJRY4eMPY8ucedl7oFtsAp5yiJHBlsXPLhuIJo3yDGEZKp7G5FBdFjGmTM
ktkYHVB3RZK0o68dHBWkzSGKlKOVwfUyMHvZiTg0Uq+6ZQbKoesEW8WU4M4bgxkn/S0li666J/23
8a915MU512S77hdvnwXMLvcKNNJ1hB3bphzOgvY8iGaSBckWbc2BxgHmn0MrBIWFwD/E0pa3S+Fu
FawXY7XPxTA++znc5OvjzgnhftM868vt1c39s6zzlxUEf8gpwxHx+cHGOd7yISf33GUcE31tNj8y
s05BCFr8rihz2i8VEyUDDYo3tWBhmK4sEbQMRqL3++/nkWkTNUsiWTrYEYOJJcfkimRcMhZVLjUG
YWsxvKTwmqWDTpJW9ioyrDsv9JWFW+A1IcGFKnUyOQUFkgBR2NNF4ODOj9mdRRtS4LkFvtpkhpcp
TjPGtQtIG5oZDKRImeewHmYn3k5OEJMW7BdXLOPG7+Y5h+gVV3woQZlBKOcHkVkaGHOW1ZqViVij
yR4fvlm6+nlbcmItJyeIAa9WLqMfZI6wOsbUYE1gA3y4lUuVkrVHY/GODnvPwYSWQZxsr7X76NA+
O2jVJmyrqIYctM1BFuC4irssdHR5DtKZ87rmQNyf1zUncI6uiQ7czllTf16X0FIxVl1QCbswmn7b
mRhPvXXOvK71JJwtUh7NKPBtlBfZCRc797Mu1VYYrXLizAZnovA1GzCt4FelfX3VSwdH9gqZv/Z1
CoYOS7sVrTInyhfWby2LIKcl1m55uggMnKctSb8gwHYq1CC5stYIA84xdvcwPf8oQkkGQ/zyO5up
0wzU4YkV50FdrgJH7q1fEKk5ik+K4lmyEk63wZLnutDoG3a/IESDNDTmwdsoksq+YPVtfXCkhvdL
eo8TwdNShSyxWG0kOgOti5I0Df2y+xo8LVFIn1OGd/O86gBqMiXRY2PaZmFZmSLpNZmyuVjLHBU+
d9QMionuVzLfdFvSHXW1+ebpbhfezuhA6ZjkHhR+SBrjTjC/Sy5AxmzxQ9WFcOJd56hJT186+hXp
SvvOtOJWJavBL1EYp03XgeKzZEaiRyr7D5z54lQsDN7ODzOAD3PdotcagAopZZBMeS2tlLrKLGt6
sKVeJ6bh6QvY5/bWvaXtlTW7sBIIeTPpz2mArl2NTBWWM3r73HOfvaXYF9TJeakkuk2bEEC+iCX+
TemLgyMVhKcKVni0QgIP25QPo4KHeqIXjsChkYGoZxJ7ZNcHxZaZt9tmHayGAvwba0H7A3ZFHVnN
u4ep83KqUwhrtlliPjK3G+yVXJDC6Dg4lcpQjCwDq6IOIWufkgUXJ3Ak9tSTl2+Wrn3efuBLwTuF
cOlidKUMwBx1KC6awfnqB5uLBfSw1NYu5TEjE28R8lTgZrbi2H1yaB8dDFdqiCX5QYVQnM6GG+Zx
G4bMjZiDs1upvjYM0oM29dhOFwLO2s45LQqW5957R85sOJFnvhGgkQXpVAER7nu3Yr18exSap5yR
vW1/NP65TbG4bIPwnfnmkrviQlY1azgoXsfShg4oE1x1Spv8qiGm3tqRNpF4+j8DOeZMqqxb8lRl
SbVWgNgGalgfQy2x3beyBD4RVrf9wiURnqxQnn8e1ilWTxmq523IswBakTMzMcuMKNxqDqahxVy+
KVVxcJRdrdh5daBVcFFAmFRfsTL7KYWPwdm3jCwm39vKfpBD15S4czK0RLI1QY6Gh7L9FUOLLZ9K
h5wuJp/UcyzSKW1BtMGH88q2sFWWyqRNTiTZ0Sk9gYVDo1IJ9mhNs3Ex1sNLgKq5437r6BOrpUoT
Y/bC6mqzsqolirZYYnxlubqlybzzt5gmK0RbA0TFbhQ7r5Q0lnZ5IIFXEhYIny4CBUdWke9Rqy89
GAs1S5O1lWGt9ODU/eyp3dswW+CsCDB6nDY9A653ilFoglZRJ0pb1wi2sQ52Mtvx3YdtAvnFGWJM
UMnOe/BpvhDJNddRcKNVR1bwIKq04HRwcCir0K2Bl8q5ObCce/X6soKs8j6PJutkBTlFVLHzylI1
yzKAYxg9w6JT00Wg4CRtBh2kpsN7j2aUfrwE8VCjkNYVmScloNjT68MDRwzUvgbhISSO0JZJGzDL
l3nOgSALpxVbEUk9CPw7Ea0I0jKFJkZP1oHjo/UHErE8mNYBWxtsYNrlw6zyozkILHBno+U2Vi54
UDXoVFUOoPtiVK8X+G9koI2ONWRYeV5IY4OfGd72tRSjnPIcvTqbLAIHR4Zz+RMMlq86cqe4crwe
X2rvh9FQhOQs2ZfmfXKMrOLL8ie+tXlzLTgPNplJQlgWFVZk2OV4su5e8fPGtqux5XVhqWQszay/
f6RDxE84wyht0PD89smPoCxVkdYXa4zbBugrIA8xmQFc8jjU1hpUm+IGYIdoHDMmo1PIe3LtzaLN
IeXQdP2nFjNRypu/P2WU/mkQHsS/tw89QQQc4GnSSp7Cm6RoJGnAnmU1l06UNlabdKxZSCcj6BZY
Em8pG1LCuqpBGrW8pBIjpx/OX/s6Ydd5+fLyr0n3AR6caBWbCbF7ZwgVMuND8fPm5nBlglaVZYWm
o0zpuwbcsnL0090HsswqAaWSP86knEFCMjNB8eWV6Yc135V7rxzzlSOFkXMA0nbTGUXp+zXf4GBl
LTXstlyl4BwZhODLatP32cREpwwvOhWfV0EjfVexrBz95EksINK4NdzXiBXNd1F60sITC1MKkJOY
ba2+yiJjxeyrPkDSvhLLrD7iJIbMW1s0VpJZZSp7kmPEcjvw8SQWHVrTtsyjwHqd9KBxskRciSdK
oNVg6wXHQTyLNSKHc/okLlArDWWOn65u7u9u87fUwBnQK6LW4FVYwyacU00q98DNRXFsTx994ONl
9KW4xEwBwmzN6lYJq4LVA5jIavAqyyFnnocglQ0+gj1cMLO6dyH+Zik15m1VZ01bE+l/mp33Lzn+
7+TBTXg4cytrjQPTLICl7fMQpQ9DyUkKLg1jxU/blP32y2/vL9glu+SXSC1uQ04L5QXmwSmXW0ie
LDdRl4ox69RyRxGSRRZgsy5jg6+Hhf/gQdnWGUOzNVKOk41JlVhmFxx6u6Y2r0l4cPkww7RPOtJZ
EdjQqh6N9u5tjh5GUZCFvEou0Pu7922mpY2dFLk22jMDPH5cPjtj+2hs4hxzSbnIMnPaF4ZB624e
HdmVyw0R1FziIHgMqNGUkYESM1DSATG5wBrZbe4O5q5ZkytggfBgjF3jWfQALu++dmjPMWZU4lwp
GTE136cgKYHlQmOEaicVwXQPIVcQKasoSUZm5JM1YOMh2mBYNaDK1xCUrKJZHqI5yo7uxGhWYFqc
3Hc0GbZjzKCYyNnM8/NhF3SSWpkT27DSid4vGnfnlhYpKxI2HnIUkrPFq5KiCWj1Qie+yzsVHs+Q
hd9eStpAckWDjMdqDp6rT0pZlY7p0UtIb9DI3KzpVh0XTIBkNskG7WsvXaQXosehkVcRkkpFtiJ5
eKWwjvVmpfXS+1FodKa8nBq1L5Ki98SpLpye5dXlkkm3rlmLJLp1PQGYU9265kB7HkQzyTK9C3rB
Nl3nL/CwTdes1RJtuhoiqi7hVKLRdhKRsjqCTZSC7eWQ9hKuUGiemum4Jww6+ZLSeSVSEcweDro/
uAUTTctVIVpP6AJGQYnwsWJLBq3nPBiar50Xxuls9LNosk4F00FheV6bDC5DUDpmlhGjZH8RGDjB
Z5+gfg4pHF/NSg4y67UZ6IKTzHZi9zbMpkCbqyhdYJZ1mK13ilFotCmlGKJ5v1zVYZRXC4edLFSa
wpKZt1No9Jl3rLTenwl2sdOL32QblTeMy1TaPAwLnMord4kJB57Ca08kA5qQnaDPo8kqOSDo6z91
3sDHKrhOXEXGFTrWcLIIFBx9IzSl1of3//bQuzjmyiO3Jhj+0Jls++fL8cyPySdzTvxfj1+LJ6FI
RpNxBtKtpdCItBl3flP+vNjcEI1mw6/vf7m8KPef2eXFo3+ckzKaOTYwb80gpdEDiLs6ZG3a5atz
ERsI0/CSMfL5eAFVM7zavNVNjPWPNoYV7KhyV0PC300OmzrFAxtpykIby5aqV75Xk96TBTg00o9R
2NzKJk3HwW4LpelmUNS7tqNPNAmu4SddRDV74KFI1vtirNDpUGsdpuQ7A14i0MzFZLlnLhWZhDGe
M1l4Mq8uciWdwHoWTVaJXElnYarziv+syilqYBMe0D5Wk0Wg4DQtGLBiu8YBTVA18+nbXRmuvmz8
eQ+8p8GKGZSRYbA1h0HX1tsyicg1C95FcfHHbS7v8uf0ZfFZJzvsndrXjRjxxZvAQGaCidrzgDrn
G4dG2otqdsUYfJFJDujFdWc+e3FVKbAdC5MVhL6HX12AZeYYq5UVqdZ+aTbUZED2LJqsY0NDq+wz
q+jgmGjYhwDbgLDhdBEoOLI5yh61mn6ecN8n4L6PlwJUkHM5C/s4F+34wcv2b80YmsOpf/nbyKvj
ILV//+UD/Pr+Q/sFfrgp93+0dW1++x3W+mf4sf3tX3/9DX5C19ixhRetcXMQ2nJmSR0wWdK3u3ao
r39s+37C/oSbPFoyuxdt7pf+j7tr/XGj2PLf71/RyxeCdNup92NgkFjCLtGG3NXARle6QlY9E4t5
XTuTEIk/fk91e2badrna7rbjAQQo8at/deo8q87jnYEPvzPXb4P/ujkzaybQgx4BXuuAyi+xrOqP
ucQG9uYa02krAG81QbtgIEZy4W4qG5rlJ8cz58x9Xdk5rD0t/+62ur75+JmWPEy8VdmQDbhjWKtz
Ioix4KUXIXvp2FlHHl/ZVcsc4K09H37PaM8pCetzV9cn1IER8M5QbiRASof5gUpjsBFURnjtlHVO
VJW9syFkGMYv5TRONrJQUofoo3KUZlI4VxexCU61B1DbwfFcpXATjixmb9PNCChosJ7pyrVuNdl+
zhYAKA68XgGwvk2JjfKWXAQcAtUQ5T94Yd/5pKGaH0h713z7fjJHHlcxYOviarLNWnpMH+kxXdLj
xZkKIAqMKI6xuzeZP5a+8znx7Kn7QU97+BGAYOco2Wnj/RzIem/HziqsyQQLNcEI/kXPCeeT+/8y
cUFa2M4cOGBh378L7relvC5CqGaxYd9mfOvNvGuMYC0de5xFWg6vRiL9ufl04wKY60/pwuejmTWq
Jp3RrB2DdAgPC9vONaxczLCfzWx10uLX6vnN7fvn6fdu7uYuPL+c2ZQm8vzBnHdjtqqu78Wuk3wh
hEwnJjWYOFwHHkRttNY1FwYzBXFmtBy+COHfnidSyX2o6w6hFnfOheBBJ/4reVa3d80R3d9eBICa
zkOAvEDLZCznV61TlqjdsvdkMqk8bMTkb1/mRugemLqDLUzCUdYNAyzMY1sYY4klykPYl0vOLjsj
CVrxqJ6XLjgsEhoCzxh4XO/esDH7p8cRyUJLB9QgZPPrw+2eXXrvv80uL6uZvwSP/3LW8OH7u+vr
cLnYDmSnoL4fyPJBU5ec8l+r/7q8W7xrr+Th7yd5evD/cRLyG/d+9mH3DTisHP/SFF6AF1uhapnk
CnIDCrtRmZ8LxT9i9fHdzL1LIOZhByY8znaASnUze/kprT8FiY0tW6TsPPiR6+CS3s1jOrh+3SeO
N9dV+H22aJRxLmo9g/XY2bVvTXazu/cJMC1WWCkozKwvcYSl/fzu7n3zcH/z8boh8s2lzwKvnoFh
BScjk9+YkJXvfYcguydLiv+XpAFL+/J/173FrXgOpZ+WeJJTsFhECEk+VcCksHeLG/dbc35xVr18
/cMva7jOVBYaxwc/kbjo8FArrZsP1hPRc9A/4MGHc5QBHj+4JjuCdww4i3O8mcDbgt/HZ624uum6
Yvf7ib0C5QR2yNH/ch6qFDzVPSHP+tK3+477s9BksWdql47lE3hDFRfYaqdoz62EZdZrplVqnxLA
7QPfzxERRFCeO6NOnZeVaFKUgVE0GRAkJEBlZt+jPCbXbifN6URMMiE2a8VXF5EFVz4j61KrCa0f
BXDaFcCLZp6NISgGlLqCds5a8t8466qNfa4sPt8iHv2WPUPh5MFcJv/jU5WqItItBLyytuCvYYca
tX990zjMOUcsrax4xSaK2QuHSUHQE4mGaJlWAUYpI7NMecr7Euj7NEseWjGGEjtnAiilA3JYa056
jt4xi9KnAyQAaj2OkSFqqAzeQazuTp4dkWhS9HBH0WSQApSoeEoixmVHBIIoxRJ7w3OtkbuLyIIr
J6ZuodYydSn6SDUBBS/6zkn6uCYPrbyR2xI3usL/cF1YP1wXNo5SOuEbpRNw8a5L7Hz3j8HdNE5j
G8165vr6nRcYB4ejQcR4SrQSTjAJm8uiUFHzzIDEzy14uKysx9BkmOCVr3jEuHwIZa2m3CumaS4f
oruILLhyp1CRuwBL3N0MCzuasy9pMQVpyx626oAILwPz4MLb9TaVmyPTy7ych1aMQ7bMrcgVHGAU
HTVKYd/j7MNHuIfPymipx6DHg8KEChEFM4yIJyBy5W6Ro2gyTOTKBwRi3J2z8s5qBB4XkjmR6y4i
D66YgtSlVjoeWM7xc2BYg7I68ui7iUfLsdAjffcDYFoe/M4/LbdqOfQXPn6205FjFla5x19xSAyz
nDJJrPehrxirT8Cy0Ipz/pjQ2w5P2trMtw+1mbukNLffaUS7W6a5fD2N45kt3GI2nf37epw/IYu9
hER+qllGkDlHEESIyIjtmf6ipcfeIaS0p5Y4n2RHMxII55R4hk6v3HoODsbQZJhyk8U2FXJc42Ck
4B8crHcyN2u2u4gsuJ5DgK5YLI98zWyRgvP36apqCjRoswMXk6vLM4onhNccV/W3mXcFwhPGa4xQ
eh/e+mAWsw8h/P4+vUvIhNT5HS3P8yli3HiKmBBSE54QpM9OAWZ6HWMywarmYl9oZcenNFZQMO0Q
ZUaTjWqudYXXJ3R5aGUT0aVaKslNzwrDSAe7XmOq1t8gCE1kzdjG65xMWE3y/m250mlTTf/z/ofD
7y40de7Tpro5zM+q/wbF8/By9fL1Lz9cvP7u1fSHi4t/XJxV/6q+BxZNDVQm6Q/RzC7v5uHZF/8T
PlWP6jmVS8fmzmUGutrcfvFVLrliAPBHQsNeg0ZpSMlREiDakKx9eUl8jNQE05pkuVDxosqTWy8G
Wns0D1c3H8KRzNueFk3xYgKG3PkcWhJKjOXSRhd75rtpTr0JXEXjIeoSnHHpLRJpigmEGJnOwZ/Z
oqlyu5lRNBlk0ZQoBqFy3Nm8E0hFUG0akdzRVHcRWXDlioEVYdjPoh3AXqhyftGWrVwGytpBiMJY
NLrPQe5j6Sy0chXCCt2ejr3YB/VR7UVjKMomYm+shzQR5QQOmbsS6ZiIxV7hT9co1A+m4Bz+myRk
NSITd3MFO2BSd5cza8AVkkHsbSvKrT/k7gWNSNLgHHHY9MxoS41CDfeeEIIY0dZHRFxkQYE/hmk4
dXVZoknxaGcUTYbZinKAIcddY2BwikUMFMdsOUF3EXlwO3PQarPWfIeNYJ0NxAUZyOqUtm3fyWHS
5aGIW3ZwGVIQpymJwhFj+nps9HByFlr5ZFyKjBL5cLWuQuBHowGXtQb+NjVzgdfKM10bimRAUSBE
6Wp3K+CFeHVzff5N+/dvvwGumxl7Gb79pkn4afpdnX8RFyBL5m344vm33zx//Mjz5bf2VS+aFDsP
ynwHtFxKBI+aMOMIUz3qBaTacuGloih6b7Vk0TJFgJ+cC1SceqxboknZuRpDk0HqRZfb0MoB1W0d
9cKsoVxZT53IqZfuIrLgWFm9iIx6efPTtvY9XAShrFCRq9VWwtlvZPGUK8W37N6yUhyMNLaEwKN6
Z3j3cPEaNHYGfl/PKE+Za5yXhKFefLp2dWphZs1in/PT9qnlXuxy525U1FhsvcOEsp7OPN47EVhU
JlgSQNOapHKtEIhHC4r7pIkQS5oU8w5G0WRfEV8CKuuccR26PAWzA2ER8OhmD+LVRWTBlcvButRK
GztJ7Dp9YNeLM86V4MRGju19G7N4XwPx8LF0O3N5Wd1cX86uAwQafiMjf4ml6Psp9MeobaBF468G
NEhaLWD1VEQTIzJW5eqIu5TK4yvePalMaL36fOQkk0BDqVGPmVZBICWNQRCQg4NpuaXMeKUCxOdU
GX6iOuIlGYq3DYPIMJBfipKhxh0SAWm4wwrFaDaHa64uIguOFcPhsaLCiipU7dE5vYkc5uHfd2Bj
p+nY5e42rd5jRpAxwrDcPKFeUWFlRdHBl3++Z04HImzUNiwJ9ePmB4/QY6yFz4tZVIPgL6sXqtuZ
P6skeJXVM9cmfp23LSK+ui/+afupYiIngGSCzxhbP5g6GsjGwrad0IKfLiED4mbfpze3789fp1KD
xRReO0+LyAIrF8woBqDD+5Y5kx6bejtNVuvX1OMjzD40dWEN1kSHj/MZKMbkInqbEnZ/v8o7WuVW
qIo/PjSvlbgE/cos4y729OHyjkehBPhWgXrmjVbBp5nkwH7wJ36qJg9LMhSz7AeRYZiG0mUNNS7H
DcdgJeUyzQTI3Ul3FpEDh8upuF0OfXF3dbviKgEL/vOnV6ADfaAIcCgFwdkaHy9CWwT3Lhgf5llX
6tgQktisfGmL3OByv4vROO5bK+8OqJzho+QmBz+EkKnemSPmgiF9Fxh9QpyHVqbVEI37WBOanPIH
6px1RGzxHth7sjHz9BHSwYzAPPibpAk6ZdLrIcKyiDh9soZP5nm7nI8y0vfB5XGPakxxP4+OKkKM
pTY34bHP7cHl0nFVKu430kdqUx4N62uU1xcdZKHporewJehedjHHmluHnMF2PW7Z7DtQPnzYhIb7
DvBVLnGuOZlpEuoHZrctn1zWNTtnchHLGMGOU79BoTXnwWBOJfJcChFRAB1kOajgSAGa1lqQE5/O
JJqUDfcYmgyQ9wSoeDqjx2W3+SBk9IxSkukttrqIHDhdLlPZQq3lPJlgLdNWeNj2HrHq45o8tKIb
rnM5O41YreWjWs2dDErWDNlQB2ldzaXEddAUXhaUMUd2SNj5kOzPla/Ddbo08fuKqi43htc7p6hQ
4bBTBlmlew5SLZJEY4NioLBHRGBChIrKuhitpeikV7EtTUhRcY6iySBR1aQYfehxJzIQ2iOhDWcC
i9xBamcRWXDlcys9PG3nIImoozEeLxF1Ca2YWLSF2Zbl9lpS5LSMpLeXeJ/QZaGV5wjqJ5dYtDfq
IyYWrevlHdJRh8E/TK4RPJtMKC1WPuudc1CMAleeao4s6euvQB23UrHk0HrrPBdcGJXuIDGhNGT6
K3w2Q0DaPv+FvRhDjwGGIAEq+x7jcnK4hABDRpPqqnKX5p1F5MBxUrqT5YjsSi2I1dL1vEeW92QA
a+KxEAqczChgQ3X6BiacC4IkAq/upNzDi3OSx9FjEPfwYmtPjva43cgVplt4mJeGg+uc4Z7uInLg
RLHHEcfZMUAP0eoBej8sUZRSh1ZQlPcsVQkbRRQKIvQce4tAIKiXOEhCkeQoGmW4B86SlqYpaqd1
hxNNSoHiOJoM4mNRLDyHCG5knTfzCoIwQtnm7PbVRWTB0aIW3EKt1p9T0iKlBZfO9bVP6uOaPLSi
QupOCf4ckStw6s309uZjmN/sU22yXErJa15ZSk/vgailRBKDE7zuQq97Kp5zox1oCO6UTQfzDiMt
KKg8qa06aYpfS5NiLfY4mgyT0+JdPcfj7A1sAI2ahsjV5mjv1UVkwfGyViMnD1vHYTxq2JqgDRHA
5W0Ax8aIgLR1vU2SeoQuC03sLAdPJmzdD/URw9YVpbxbzDoA+8FiVtozj5DiPx6agsK2zm78zFWL
lB5yB4RKQQ2x1hrPGHem4Ya387Tgh48Aa16G0NzP3l0DxaprAFWFD6mt2TOMm7QtAUH5IjVW84v1
TqdPBiKQdTvENDuitIMYc+Djy2lytcP1H380v53yl6tn/uYqJd6gr5bT4Kbtc8+r70H33VyGZ29e
f//3imuEtzy3FJKMee4vQIS/VxCt5h8scelKkWO2s7F03kWPmfC2b4gJDlyA7oNtxAp7UH/GqkDA
dQsM8OkTOxCJJmX/cAxNBjgQCVDp2BYoObIBA/KYkBACyjVg6C4iB06Vvenu9LY3PzXPTf25PwY/
ffOfL6Yt1y7S+TqNRPAoQsTsvt/M9i+cJe4/r77cqRbnGQgDmNPLCqTFzNJ07yax76zaLWFPtkXd
hTV2ijR+vlg5SmLUSCLTCGWVN7Lets3bp+8/3YZFq+bZhMha6GQAHt6eXd1epnd5SgOotVi+2faQ
bL9HiIRvilqQ9OYcHtf6LnqCBVjblRdparVc48aWt+uZLsdNpLcln2CcNdCHosU9QzZqe/X5abZF
1WvMf/zu9YtXP0xfvn7z3auXL5Ix//ni607Lztf/9+pVzkofYwEHM+NH5bQngm3dQd/kPk0nmC15
c1dP/FjoSj7wUbB1x6B35y9jDipaEOa4+XOA3Duk2GQE+LlGSyHx+H67BkGAR3SNJd7yTawgwsgE
vLDM4rRI3h0Ptro657WNXuoYkfir6PKD0OKUuvzgCzikvjwepz0RbEfT5UdBdyA1uTu2LWoSUw1B
j5JCRvrnAPk0dbmCiL54MCh3jT2EIIZH6x0y/GnFHrBGUbytlFv9moiCExhFCc7NX8JeHYoWJ7NX
x1jAwWzCUTntiWA7jr06FrpDmIK9sG0xBUEwKxV11OPj2KuDg3yy9qrYw5fLrX5NaprhpLNUUvuX
0eWHoMVJdfmhF3BQfXk0Tnsi2I6ny4+B7lBqcmdsW9SkgR+lVBorCf5zgHySupzwiWClSxmBdo09
UvNrTIkklMUnFXukNRbDSIG2+jWeS6MxM9q6+FewVwejxans1VEWcCibcFxOeyLYjmKvjobuAKZg
P2xbTAGRAfRiEAos658D5JO1V8UQS6Ctfg1LeawhaKfVXyL2OBgtTqrLD72Ag+rLo3HaE8F2PF1+
DHSHUpM7Y9uiJimTqYmWZs7pPwfIJ6nLqZywYnGkyBcJWd/WCKUQYI8xGYvzxbweV1DUIC51bhW7
F88AOqKRZJK5vlbnCjstuQMwmljHiEMII+2Exx4rZk6bZ9jQpBhBjqLJ/nmGDaBSBogYW1DUeJqK
SedzhQrdRWTBld20bNUOcG7D8skvOb+DELpaXN335G5es7DVv7XVPAIbbgW2dWRW1ZKC+rZSuZoi
T9MQKoQEOUx9XbOYUnXUtq1vywYsMVwFBoTC60XFGz3Se0QgD63UyUfsXj5DvaEuNSDRGzOg10uK
CGNYS+swJU2Ct+UYccpSrYP2/qTD5Zc0KQvGGJoMk1RZylMXI0uKtHfUSysUxjbXCaOziCw4Vdb1
pZqYiBR31ilqbd9s5T6uyUIr9i8U3dTuQUrEYGKoprHm2MH/CAUPNTJSO8YVpphG68LhlEix55bY
PU/dOJW6ooeo8PrUhTVJ5UozEbSRSqsoAg4qOOo8ltZ4ILs7vaQWp5iNo8kgSeWo7KqNy92PlLHg
jbGR5op0u4vIgiuOGk99cDbF4YOf1bN0rOzv3P3MNUQcR2ArrRe8ZkjJ2ipiam+ZksYyDCxSLb3I
3USklTUAVCW+ScHy+XOQvJbUjbw9X3i3r8DwYrf8bcyxHB/AjUSWO2xtX4+ZPiHJQyvrzJ3nUjAv
gkojqa1eV6Brshyjdt5yiy3oS4IMJdRKi4RVglFQ7ieXZV4sexlHk2GyXGxmKvC4WR3WBnA9RaDY
5fzj7iKy4IptNlao9ebFy8mjCF+cgTRyAtKIozMPV1Ddz5xVP1+kW6edZPfZRRrHmLr9VIv3N3Pz
Nnz15ddVM+fm0thwmX5o87apWUExeN95Be0O/2Tmv6XtBeTxZr66nupZIur540nb/ffr9AM1Iww0
mEe2JtTowASILY6b9XMN5p15dAfMQ/RqIuy0Iew5OCbL4Snn/6oyB4cHxLu4Ar3yU9W4Q2ARpo8f
XMw7dI0WPC5wxmppvKi9B9ZBWphacMclB30cPa6uw8fpHnbkcY2/Fq1DfvmlNn+rKuVq2pzivjjD
wPbMBlCWqKeLEwL3gzDNBaIIB4MdeKSOGmIIJ1LkZkt/TnVanK6x+9qHqc7imCOBB3TV7ZYwcpt6
hhAkXS5g6S4iC644cVPgPQa0NF2QE7K14UfEeuI1I0r+P3VX+9y2jfT/FT73pclMpfIVJNXpB8dp
U88kqR876XSmk+GAAGjxiSTqSMmJ73L/+7MLkrIsgRApkXIu7aU+iyJ+WCwW+4ZdmOp+5d/tvaVE
GGhFo92hSGnl7txsIwTnERp6TpyElB0DLtRqkXYHtxHKHB5vSRNYW9smYQj0S+z9soxtwGl3/Da4
tii+7eHf+8LNBIwzFiTMtz2fGS+QTye+Y7uOCUeL5YVslCQWGxHHZSPfSwISe17i+uzlZoov2gqV
l12p0W6pDsypEgb/Ron2I4//E514dn28fWW4ExP/UQEnpvbcsjuU/sSJFTs7wMPykZwKhyv6pB0m
KzG1lvg2utYwnrZI231YjUIr4O0OTqF6vDldgP4mY9zENx2fMWYqykG1oJDe0rQ7VOyrsd2n+WqN
B2f6L9yhITEpoyHxgdeOAqg9A+wOdnoNcDl9KFI82rHESFpIRUVmKjsOMD91HbHf+acFUG0PS2J3
6HxRHQXxw8ZF7zPfIgHjPPaPgqY/pTrYRwBte40xE47VBDQTGBbYGYTpUZtV2/EMPu2McrPQFSvG
1OYkdKjnhMecp0RbbpPYHdSRXYBPORFYCa2cxLb5cTh1tY+6K9O7fpRDB58Sk6s30bvZYx8X80cr
kiYrMZgdSbQd6Ymjiuh2cUxjpxju+3RkuYCJc5GM4ti0RmAyAD2ZLXjAe3NMkwPRLV2bTstiglGQ
FYF1KABwyIGlhqY9qZ3WMVcLi3haPknEpu9hg1EoODOdxHIFSFYR+L4DWhGxuENB6ROgcz+7n41o
E7ZPo8lRxiLRh9uck+PQYUJEzIWyQOv2JJTgtN1nQHafuFMtJ4jjQIgRSMlkJIKYjIIwCUc+F34c
eqA9YC3Uvnaqr6vz2rT05U71GSeUBswXm/sOTTv10BZQQ9OeLk7rmGvgEB8OD98kyQH3jeN4NktA
LYupAB4wqRABx0x74QSmL76DnRpodb+TaHLcTtX24gNF98Sd6pss4cA1RLVTtyehBBfqmVsXhzZB
PhCHMjM4GO45xDU70Dysbm/p06Gc1mFKk4gkDuEUtJwDbQUD1wG1XtigNMcscWNOQe4nVhxzHiZw
2u4zdxTxbG5G0f18mZ+HySva6AXsKbTpyuQVIP1xdFoIl3GLsAA0GVeofJfbk9gD5zljV9ukpYei
ihdc9hpM1guZpm28zeCRleSszAC1dy1+NAoc4xdHtkHHPz+WJ911NeKLx092ld9qDjqxNnRhyHAc
hLAVGmtX+mch8/X+16YCXhkDQzwLoN111wHcZwXSzAukkRnOMzENM3iSF7CQcgMvBIjQCXT2OSCs
dnmUi3s6S7k0tyMkJLqpfDDDuOeHrl8LpcfHABQ2QQREqMXNjOpFBdadXU2FDHfNZALvUbj6Zomb
beA16NnDCM8EoGfKpCzbTKIPeXGeierkhY2FZOFcM7U84mlbyDgGj8uGnH/v9+H89K2HRpmhbJOi
bWpG3NYJFIx6oC+Apk42JfKaIqAeEJcxT3gW8HhMLdCGEjN2bJfErmM9a3X4iibaw/wkmnTVLkpA
2qZmxD0tqUTEQpCYeb7rqoq7bk9CCc7TgvN2+7/iyPfzIvoyTRlQK5ebJgIxwdal0/FmQogQwhfM
I4TXySa/t/nuAN3YzzLHkjfqz7FtM04DBinkpAi2YX9+XPA5CE3sbYEvKwzYacbfuykkJS6iE23E
875dYG/msQRVvR79q3ZMmJ9QQsPYenL1DH76spBnH6aCwEEHbCp71JfX5uTJx9Y5bv2Sb1+0lTa7
ovkRv4aurfBvM279zGAM2gdgWX9/SoFDZKH77B4pD9JM5KsqpLguOzVEDMh+J5CB5FAFfms5owuD
wdRUj8Kv/21kMy65byboPa7lLwamIP0sk3vw9zTP0ycfSDaLVlkErCCTxfCDRNjUsxJPSRz5uvW8
LtRfwDcWmVFi2AxUvd/4j5qS2gBVe0p+Mj4WOJkvsxiOYJbN52JR6nmFzDZj0ywrSpaWPDGlhQGS
eGFUk+UGPIRfTgvZXYDew5zwg3H14ixP4dABZY/O7uDn1XQ+8HyOkE/9D95WCLlj19WGGEjrlnQx
Cz1qEfRCHsiXDUDMAGbPTRyX24npUy+0EuYLk8VOEj/rfbKKJtoFOYkmR6g2CEgbUyentekLTeJa
jhd71NuPoz+dhAqcr+cgX9u5JfDCmCTc497BWyoHGjvuQ/PGbqDrG0781gvpUDPE/jJxeKhveOI4
gc+Y7cZhwuHwsmxQGIG/3YAKbj2v67uiidYreBJNjmBuBKSNmvmnMTcVGAUKPCfkQnUFa2sSKnCe
XkcLfA1zuwlzg8RkZhIeiusc4hoVtMDRxjCCQBE/w9NgVEzXK559WYzoHWqC7SNd1bDaSMX2sDVF
ihm9FxV/N3iYMZrFgyQIN1GCC77xeCAzlR6bKg9ejUvLRtu45EFaUyEqqQCyKLGYY1ueoHZ9pVBq
paAgoRekfG4if2eU3/mSzgBS9R50LVnF/8AfNTqttRyEZcOtKIHV+GTM0rvpSv4cgeYe8QzsjwrG
xAA6zHCHvcsWKZAjynNejNH7sl4ioQqg9UbLv7l5XZSkmz0cCWu+NcwnoxqnoImI0M9Sia3ZgxRX
vQzxSg4xwYngNGEK5b2Dd2VYt1XBrg3DgGj43Auqi5xN0yeAsvj/BFv1CkpfjWCbhW/FSorZ0m6q
WkLDAOXBArIn8AJq+zwMhLXNWRcxyiZkE9ANlV9WA9Na0CcBO/LUCDwtrcIjUhtqMQUCCrWi0Aa1
R7CABZbqFtHWPJT4iF5MtmV7aUMc5pyuo+nZuZXZ3QKUNmys6kT/dAk4pWAjWDG3nQNaF+Ombyee
K7iwKOfCTxLL47HrYoYcrFCpdZWJHWe8LlKRQXswHUWG47aM/q572CH1W3WDNjY58bgwHXs/mfTp
JFTgQuu7EzGh/opX2CEnQ2ocq5R9nonoMdgHeo9PqeOY3I0dVWLGISETansDP0HYhMAGxdjxhWM6
Vlm8bjTNss8gIW7Wi8XGicHRkYgfSFGxdS2tcjONiGN5I7Dr2QgOvHjEYlB8g1CECVG4wyvg7Ujb
GfivXwVbV/4XAPyD1HmX+BcXbAb7eYSz+cky0S+3uoc1+sFAfdSg+V1h/G2M8AvI1D8bbeTgz8YI
1q3IFj8bbCboYqNe790bLGeuT8p4Fj7Xp/qGR6RlPBr4YcwssGPwv8cwuKfrqvgE2t7Q3Iup5VnE
SdhurG3X/Dp0fOxDI8DCltYyDHuIPtrWxLXGxNRtFrPy80f/Enn2rfw0SuGsR5ksfFBKmRUEFvsm
zYf1slqyv6/gEUQEvL5YiBmcdKvpJ+Xw2svarYdXc44KhTwtfFtgnR3XVSlf2y8eEPIOxf66uL4y
bn+9+fPXG+P2w8XNh6v3b85PMRUKTCIVFvNi23J4ojpJ+qRYCwTVfssWUfFQgEiK4ixblQoWamJR
ns3EL3MKH+XnW79rmsuQQLrAgF6WPxhJOhMNK6gzD09cQTUOWbjA9mwv8LHJ+FFr2AtolZygs1RC
rhT+SoipSadNO+pDXKjBoDOPeDY1iUWpnRxDvw7I2wP5NqXFdBXPoq/z2SfsJgxvlSKPr/gZUchP
efxJ6nN1qJBHMi8nygXuT+MXlQfgjKgqFxfAkprU7OE5EZXSKSpYni5XGA3dd3CdiTR0TPM5cLKW
GDrT7tit/zajMk/t9e+X1wasCKhYDVteZ7uduOUVIGShgkRwnzmcEFW9psNbXadXPkV8GEDpYFvz
KVty2OJ0fTfdrk78EVTUMf4ViTzP8he2+aPxD9TN/wH/fVTP8euj8v1jHv/jJfBHOXDTI5Ny4vgI
pnug4v9QA6y5asDl2mGWG1GixfMdM/pysWpgll60WTWzKECgEUItC9R76lrefuWDFsyivUZ6/Oa6
u0OouLB1koDkSDXVtAbzyVusAQrGzyzhEoolCEJ+FO3a424LY2PM4cueJtJMzoxhKa+vriJdksfZ
QMQ5XfCJ8ZdYlKQ5M4x4nc54tFjPYyzQ7pk+sZdnhjC9q7KYCrGaGGcefMMD1tgZcAvviJHLqWDy
YjV70qKmQYjoogQnCpEGILIqjiCmi3VzraPOakd3xesp6nYgqgXDS1lGdfOzmKP/qvQDPtploxHG
yeQJC2TA9EnYazBl457OGpRBR5c69F8Mtj1H1m7LIr3DvLuqZUOD5ujovKEncmQDEMzWTkIXI7PU
VBS+aMORvaBuoNt6WTOCKftLweIK47N4aKKgLjWsJwo2QsLXMC9wsV5YHB5ldGsD8b04LfBYzOZG
eTIZd2IhQFnIcjU5tSH4Pr0XDajwTYHpUydxfM+kx1C0nynsqvdVOKj6NZyzILwaSNiLLdqg4Ktg
YLQe64Jwj3PqqGp+HqSZNpvgKeY2ECqh/SpdUJDMdLkUNJf3tmIB0j7PBVvNwFZLF5+F2gnUAU8X
E+0uRadGVYdlOVuDftMgVrR3Jk620lQ40FAzhckpTSjzVdGiw6vYHnQrDHW5HTA2GC1Xnae4eHje
/pQtVz/hONk6Z+KnYi5jo7fv6nepEAak/d7oivBmzOiSxukMhAz2N1wvPi8wDLn57YNx8eGPd1eX
0fXFx9tfzwXv02a5YS15nqLN9utfHwAeh59kNVvxddWIpqXi15VY9SpJKMV6ucxyWStQyOAx+kZf
qiCFHXx9A6zf7U10e3nx/vtEdvHhw8Xl798ntte/nhObiuWvbv/YZvm0yBrRDM3yCKUtyztjV1tw
sD8CXd6+fbNNIVbM7hrxDE0iCaY9jTyvvRJ7ktz8348Xb59Izn+u6awR0eCyU8JpT6Yu/oezn37D
wFOt4m8Y7d1aRIz+NuIZeg0lmA5LGLQ3N4cR5ZcgyK/ev/kOwR3krwHgqfjr/W+32+y1SBSqaIVm
aO5CKO2Zy/fOo37+/upim0DTmDaiGZpACKU9gQJt8eb+CPQazbZtEkk7rhHR0EQq4XQgkz+cHdiD
HBgCnmoV3/75Ltth9dn9PGtgd4lq6JWsIbVfy7CDj/o0/fzy9uqphs6KtBHR8Do6wulApvA8uous
ublFJfz/jXiGJlJZALQljdyxpb1i0OP5C8bm9fWTI1is6FIRDK0wDX4Kl4A6UEp7JfeZBegw8JoE
6J5cQBHaIBsqZOcQot3kgzu2vf41hx5XdAh4DSu6s5aNaM6wil3XT6aP9Q7pfbYyitq9vVVFbePP
xju/YsFhZR+d3zwTZcEV8TXdLaLXfUmPDOwBNlnrTRHB6G38FpG8GoaBLSlMJxBxEHtO9wzubozX
BsK36r58lM6XM1zp+gJ99XRaYGG/ArmF4/11ufr5elHX0ZPPjnn882OmYTyji8+a9MKhFn6bqaer
1VKXV4AYBoyKN0KRW4xYIggS13a7X8PoDbeGdmVa8yjD7OrviI6NsDCwaoWuxRzGYqEq4fE8NH2L
0Bdlacv0q1FkICNVCa84/oC3gZQw8Ksg6m2e4P+6x8MrzG3zo1tAqFM214yJokjWM1jmGGuF1o+v
sonx8f3VX9rrir3Ss3E9ZeI93kdoWM0BbwYpQGCqOTcT26Ekpv5+Q6Y2a9k+FHAYQKuVvAKLw7Bs
H5Nhx9YkUGTE9kbJpnzI3y+epgaffzUbochkETPghIfCJN2zpganHSp+i2wxAuD1zVQ1+bQFFfsi
nwINZuB6tpf4puWavHtSf2/Q93P41kvj9as2rDck7dQ44LtxSGxuxnESHHcudADdCkOdwl5dieRx
9XRDUAwRtJf+XRCo6kefc/x5xsVkkUWzdJ6q7amBBobdNaeryde5Io483KibOp3RapoW8nrwRH3B
rhuG9lu1qEubY3JrfQdPLMBUbrAn+0Gh3q8aMPACS9iWGdq28JU17A5uWm2zmx3krYFUC/k6xtWW
Kew0XRQTY38fGS+q7FbkBtv0QrWHY0iU71CRyQXDmmhcFos9Fqbjto8KdoDZS6mICt1QRNzUDisr
7tffUS25Glt7V/dzUK6DRtWVctciRzFbXvqXbhsUk28ulUBIe3OVx1gY2HixXgIMEYnF/UsAQEKX
uwHlfhCL6hFQ2OHviYE/R6UEiTYa/hlRbNxI5xz8aeWz+jqvrHuWZ/PqGjbqG2WtiqOqoamm4frt
M+c6TwPh4wVhOAn+i2eB9/yl/0e6kcsthV+VpZuU+7RnOIrtgWXIcx7JigRzMc/yh6i8SIXRDTWk
9g7Pk3ashMSW6zOC2GzYpmG1fes6D1uKy8t60Mvrj4Y5MRLhJjzEfu9JAlwbUDFKEuBfGgfA/4kZ
uEGiBtc+d+A4cNbEICYcbLFJR57HrRE3uTkKfRKOwDT1BXYkc+1QDa5XIacAZ0+MwE0S33PoKHQA
XGJb3iigdjyKmWkllmBmnLhqcO1Pw+PAOUA51/Vj7pERYTwe2TFNRmYgnBHx4Ow0WSA8ZivBhe2N
0JP2W3nnTb7ojDg2W66+cqceu1cxWOny9R2/UgQ+BvmmWFOYFkXGUml7gLZfZDNRPTd+XNlF9kWN
dngJSYsp2FZLLCIDv5jmcM6o41MDgdkeV0aG0OTYwFIfHP0iKRfxL9mfRJ4U9eDj56LJ1gJVT9/P
z0GJenz5CC7Gn1V8tGHw9pZ9h8E/1oPLhnPYtThLAIgSgtehxF8HCPi3lCTiPmWwl+mCA58+Rt3u
SzWx0sngNxMwfA9Xsj7DDLCNM+CJSi8JFixm/1ynmMkhGzyDhQ5L+liHFGuBUpPQEWdw9HoO90bc
C9yR55IkiH2bh7Zb3pdfZZ9Fg0zteQqybdSnI3C+AMGf8olhvjRu5MYdL5kyEuaZvSpfezS/EbKa
0LA0/65MvaO53/2eTL3vZBZK22qeYWVrQT8LHt3HXC0Nh8EhB0d+oAtZJ+sz5oVhWQ3ZNH5EVyuK
nSuNP1+9LowXaYLPKX2AnjeA8tWxdG+NRGfhHNE55Wnl8cTkYMR4PphZvsLxvD0LNTpd5FnRfvrp
6BYFeyVwYt+PD3SUMkMqvNDjobAsmgRWaDvENX1XOE7o2J75POXfKyJoQ2bHEOE4TiE6nj2t87bJ
qcss07PVWW/bU1BDG8ASPo5IvrapxAl1sB03cHlMfYvHqhDOwZ3kaxtZaapgO2YCXw6ZEKG9s4l2
q2Af2kVqYEMbDss0iWAbUrXhMND4u8bc9dVvhg7EIM5yeTalC9DVE8owsfpveHucm8rw5EAY5nRB
78Qc42YbJM8CZJsjcIvVBqU61jQQCFanpEgI0qRcn5MjtogQp1kRwf4FNOdEgC0lX139cWtUQ6NV
UAXWn4cOuUhgs04fo1kRSkk1ll7N/BbHzD1R4+jVt3pP2CyVlibQYZktMCB7+wKGNcdwIltqBbZf
9+6ex0P6voosWX0B/akujqkCAqbIEEAu6YytZ1XCOla2XqVzMR6PzwjBqGwzHB6OeroydoaGYdVw
erXpFTum1HvveRrJuHjZbFcNpdfwicprO02XhWjesqTDfecjzxKWRpV3TAmA6HIW1M0fFe0NfTsI
fTARrIR6ekuGucQJTB4G1Hd4Qmzb8TiPHRJYrsttz99vH3pGU4ZobYhTqHGUtk6IjjuCk0waEbuW
TQM/tn1VnuT2FFTQ/A7JYq3PmuvLK8OEPxP81x6bPxpXoJLNjMssX2Zl3tKPhr3gxpvHPKZLrNR4
nWeYrJ3lxm90ns4e5PfucjmnNzldTlNWYGcCLEI6w5LK5XyVE9P2EOtjR94t1SqV7w8QzL1+c/0R
zs3klx8e/Zq+42DQ1hxRyw1GLif2yEzsYOTFls0SPyCB4/2w4YkXdav6bk2xflCey36HHLhjIoqy
wyuKBPXg7a9HHzO4rMleRgzVww/jfNxqohXNBWitrBjPMB0MBI2Uk+g91aYjhcMgY3TBxCxCiVJE
2ULG7CbVRaiytWz5hExhk08pwYWDrNpGlYPBsy/A55gAU6oKE+PPd/tIvLGpbcB7NJLf0v+n7lqf
28aR/L+ibxNXhQneD+f8YZLc1k3VztScc7t3dVNbKhAAY1VkyStZedxm//drUJRMSyD4kGhn58NE
Fknx141Go9HoB+zBg1t288NASjPn7fsfjztPiinNnl/+9OOx50kxpdnz/pcolB5xvednz5NiSrLn
w3UcySgblW7ceVJISebE16+AZZRdVDf2NIMawen/3s991U5wm+Ze1Vooj00f4tUbqlkFUCOY7R1B
RcsyBUgjROJ1hBQtUgqQehSnPjekpko6AdVZ1VEvVA1lOAOos1pnPUcvWqQmgBojdrAbqET1nABs
hGDiroIVq5IYII2w6+wIKZ4CGTCNEDbYEVO8Km/A9HzqvLGoXYD1fAo9WtU8QHo+hR6v1gaYeqT1
jjB6cUgjqPN6xZHQMq+qClUGqXVRnEn/56iYmrh0XndcH0RN4n3e/JxeiBpXYTnCutINU6MOP2/c
Qh9IzdbveQ9r+2BqWn3Pe1TaB1HTgnJeD21PFZAwnc7rvO01ds0m+RjJYV11eHzrMkZGWDdEjZbT
GHlg3SWqUc5HMJy6oWo0UsZJt7r2+xOKEBd8O1uXEV9//fPPv1WnFXHVdF40g49BA5LU1McDQjsf
R6AyJlBBvNGSxTrApkMXA7xUTcM6vPjrlaWKIJZbwYuWs3MHu5DcU4UK62ghGaeIKe24zi0TPH++
KODAhdQsH8SFQcKCk9EueECIa+3Q3GFb+JwrUbBYkGudhji2EZaLgVxKjpY8IRDYFyA1CgkhbawZ
attswjjVIAjHYzC2bzaSKyVUwbXWLZHAbTMpjqxHc9m+BTT2vua75d0usCvUigoJG41gzl9rpOzz
fmMeTpXD0WzwcJe9/Rz8ZJliB6MfShu5V+Wp83pyuymrz2R+Eb4O+YC3az//7Newibqbz+zsfh41
yDHuXmm+GyIgiFvtgJ5cIWkfCApAX23xucvJcjHdcWK65cQ0vOnb5b7DbBn10KWkxOTFMfSLElsF
KU54j5KdQ4av7Ag7r2rzVdlW1a/CP+Y+dNCdrSfLTwHpfAn/mm1L3f0bopnOoyJ/bD89PBDSDGEm
zOehTvOTY3q3XIDu2Nht3+FFtq2YkZUz8xJYC2Iyh+fvb64i+QMjY6sNczDtvpjZXnGUIbPlHLkL
wVFnEMPyapfCYzezbA6DNn+gYXP3cWVcrOxYwDBi2bFGKGG1dhYxgQutHOtddKwf7q4wYNWf3sx2
3Jq83929Blm7NQ8t2teTF/zlRNCLN5N824G18Y4fAzosEcFaeAlaZf/8ym8TnkcUiqaKeJUiDKoR
9vaBshADMAlRUwuwGHYKc0x5bYH2/vqHgZYHdVxppVi2TAOUEevOtiEKGXuKIYwUUUzH9nTtk7s7
/J5odgX7Hu785feJcW4VRne2vpxgTV5hocBGD5uZ50H34WZzX5Vo+bIo7YLl3MWfb84jfhKgu3kT
3C3bF4SMnV9+78zHjubnQHgdqkg/ghktJd3GSKybtmltGi6YFdLBTkiEWkX9W1IDMpLaFRHUhKxN
wYWdpBKwkUSaC9+/1wQg69GFbNjoXvu92l7fbxYLHz2coXSMQsyHC8Z+IgCLZ0s3s+XK6zZzH18r
ngbVNRjL99ulHngVa8EwFpJ9cW0YydVHv7Dfgh//y3L1KaSRRTsZBCg9qov2XbXaEAX/EjXEStha
CDdk1ToT/ANO/qWy1/LlwpUbirew54nW/A4IUnOO0CZtkJDe4NhxDFliCsMQHcSWFlDd3/49bEE/
roIif5heofrp4WMlD+O2bQsc0uhyC9nSlcTUCkm+v2TGWWdyTJTu3z6hA55OL97tlndCDnKy9n4C
xkHwpJTNqEIhpkdWzw3sC+yNWXxsYtSIDY4apDr4jxS3sPCIAisziJ2jtoXy+wWyrQJ/GxTCmiTt
QGuHOYCNIgz+h3n/qvoByIhddtpYE9ZuSTnGGAkihymQMdwkj/pbzWcWfhk+NQzkiD6SOI7wrNTY
24IhLYatRt1B/3n/2qoji9WCKuq09Ep3OeiIZaIHCCmzuadqe+xsWy783t9WlL5Vf6Dddns6ALtV
clGEPXIM0kyKpcn/w7tZmALT5eb+8sOLYuX9xZsCBnID95Rf/vHhRTgIvnjz4cV/Lj+Efz7cmJV3
0yqmLXzz+3IZqA4ffzUwp26Wi/D53RIsXht+PvxVZmrOZ++CW/Tib2+A+PLNZl6+5h/rT5vp/bc7
v0dReargbxGa6Fy8AdpBCheb29yv4Fv4otworeEzvnhzt1q6jb23oYlEuOi/3s1W3y7LOgAEUWAp
oWXaKPrfizeg2W24bbG8eBNWnvIJu7y9g3ErP1dDg+t/kO1ds/vtLWU1xfLTHTDbzPdvtrD436+q
m4CqW7P6VIYBTqtXvZvdr2ZfJ//jFx/K4bx4swqnTzN7P/28/jILpT3sPhUV7g8HsrV75iY//hIQ
fPSxr8tBgtH5lLw4Xc/ufVn3GfB8O771i8+naz8vgvzNbORFBzdMt5K+R//Pf8Zlu3uk3MkKoOmk
kyZzQ8jJwQPWMi9za6m0sSPhOhlxeCkXBGk9Ni9ghyw9LM3yQU/FgwdyUhjEYbNvhDJaYJtL2Fyj
XEvLDVfPGjxAk6kNg7gwTFiSiQPktOABDyaIpoBQ2qijpUZDHNsTLqeNDEoGLZMecQMB2KtQGmNr
cfiqBBZg1SaXYIA7qwkaMqNEqrNfHWJPLN+PT5canru+pCiXAkRfhYn1IgjApdPeEE2KzFhnMyIE
ziTSNpOFy7kQznguLx6y7rtO24u+rOk0et0o+242sMpXZ+vHd29z40LpgMHn6D+9mRwguJr8MdkZ
E1fBlHi5O/S6Kg2Jl5O6IXH1svK3rq/wy0nNiIALWxPi6tiAeDkpDYirxfJl2UUZ7q2MB/i0Mx0e
PpJwHcyG8K5gNMC/DyZD+WxpMITLR+bC1aGx8HKSMBZK9Vu7A0yFw69KQ+H4y70lkLj02Eg4vPHA
Ami5vDMQDm/7PDeLbXGX2pd/X66PvguL0XRXsHSH8uiubWTu4UvKMHlYGezhhbutIbv7mW00yPTr
jTn64dvKzj264G/NDIDNfekwOnzBzSwgnYU1827bEScUODji1fxo2Fa5OULrbo++Ksuz3S1n5XL7
+MpdEK31pwgou7fTd9Tczc19ADctZvP72iB93MzNCuTy49TNAgePRu/27mhEZ1u7vwyHOOLWx7vN
EVWVERHf5/YIhx9vjVMpfzQZUHZnH6HGCUGOcOqRHLS0qVSxpjqyozcrSQSnQgvjaEtsXNuKE0fW
3dQffppQacJd34htJE5ckEbBcwscC83GQ++e6fYnGt7eI1Kwr7smAgIeBBNCK0ycohYP8dWcB3HL
+N14+Dv3ZaTZ2Mw7gHJY7/Q/ft4u1gMgkMbT1qh8AjBCCOwONTeIDPKe9sjp6C1OTYyZhBpglBvL
hdK6fwPaNtjAxSZ2YSYd5Vp77Mlpirx7dOmjBiLTGzPdMUFw5Tjsvbznu60lsGi2fog4XS4m+fL+
ptZQOgSkBn9gcJydOqA/LLDhaqCsk+XySThLg7ueD0gqlupJEUxdHuJbG87H1RgHSh/D0c4UFpIF
WLtJPqTeThtPKx8PcvCoCyRyzhSSRf8er2fjQhxshBlBbTvuOGFMwcr6fIgPxu1+ubFlD9AyXr1M
v20Yt9SZFcWn+j2NERQLyTH1MebUdXh/eCcOZ4RHwf+GBAIjWDEihw1nam9CGwOdDo2e8CowxY0r
wLqWegiSkJk3+WJWiziSh1d+b3l5Tbi2l/84MtFADhpO55P5gbQx1ONhflHtCqNywQo76KA9DaDx
dPtA5wbjuaAEW+UxEbFtWbfxaLIz6lMtPpUkQlbJnBfG2LQPn9BcM6oLJo0uvC+My3Ob51J6sC2d
5c/qw++RL9pd3dUaCy+WGVgz8KPbCpLrbbH6uPLTKTf1oBEZZoH2qF3ZW8u1siboPI8tdliA2Ayb
YmNso+tZPvuIq2KzKH1UDTaQHnFHncZT+mWY5l4i6VwxiIvdwffCEo9Gi/5Eqep+AHA/u7Jh2e6h
si7yw+bz+vr9+nXl4CgDJ/6+8cF7WArQlSQIvULlfy8npf9/F3j3Qgm2vxaNRH9mMt8aW8WXlDQe
kUbFvyxp1/6zmc+qAon+K/x4iJL5loUVBtaUmS1nS6VnI5Q3Ek5/aLL/a/WtWguqmKH1pmxQt/6p
tAQmm3WdH2BFreBi8G9UJyT7vIkjjuhGjugfmiN/XsItpXPikCIA+i85xpG43pp9fEAkYY1Eih+a
yr9s5TceO9lDUZ2TzO7GhP/q7aZKwSgvwGCtZndNuQZJDPS0AI9ceEGNLHRBYv7SulEZxzaim7eR
TeFsiCiOveFKmVjFhnbzZgxPWejAPXNbQX8Av1xUJm5W3l4R0TDUI7KzD7pghpNwkia1s2JIqnEf
Uk5Atgvhr4JcdwICO6LX/t6+Dq9eblbWv97+1Cu3LWxkVh83Zcxr+dMx/KxHD9zT8f/7/qkG2K8R
zvxXc3s39wnMOBnpNP7pBcOpvRftEWr111/L4Jwtwqn7tjC3MztdhZDkEBtvlac0RzkXQxx5LJlD
SWPhVt3xHIdcpZ69vsReO+c9Ql6ZKuyKcqSs5SJTJEcZV85lUhqdUVpIWuBCUOQiYVdtnpaLvizq
NJLdqduFXiWeCD0jHvdt6dLQ+qc3k1sQ56sJLAeEY0wFfGG+1r+I0khSKmogjSP3SMdRQpLZUOci
5LyNxxsISZo6CozDeYhOmu41Fy04otIaL4j7XpFVabmQVPD4/hFeGZ4BC9RnqztbyyS7A+NKcNZA
ZPJ0qt8b/3s1A0W92OU9VVu40KgeO60sRXmGkMaZKkyRUeBH5hQTXrHQijxaZPB0eMs7kJYvpdrc
/hMg7WCHLp03oW3q5PUaIPv/8+41UPJ6lwDyuvr5qmbN6y5kTP5WSdbs1ofQIfzgdIGtqw3ZclFK
k40FnmK57NHZ4ElsDJJ9vnEWpvkiGNuNZkay+wHVJwSbCVQIllvLchfrbd66aoWY/OaFXSeCzZyi
CPahRmvpWoLN2tbZODKaOP9KyFo9Duf46CseXdZ4/sVEauQYqo2cnQMHvoKxucrmsHvf7pvnIB7b
crdV4+WrchsJi+/s1uwOcdbBe3Trr8q+ZrsOg1eLzTwavsFkasjqkNL9C0H5WGqVUHnh0wdSiCml
sc6tx5oXXCKaS8pyjw0YWn6XVFLv5lhS8nSnUixZBOIklgxTU8nq4WzAsXzNAVEYohzMHgV2bWTG
12mIYlOpc8wGXm1nvEaaMxgDyumhxBw1YW8RmTiyJNdIp7l2k5vzzbRkaFkdUFqshGIeOwa8k4fN
6w9mWsG44UTn1FiBuWSF0wYxiZjOJROSPP9MS4a7nMSSYTMtGWHC6EkzDec0pxoLXOSx0jR1GqLY
km5Ixtrl+fbcS4dO1RNtGL2q7GohifLOgimJW+Z+mxDHkaUcDHVepeXKGSO814TLtqlmuSFcWZ87
jIkSAmEsMVMElJUQuVLPPtV4ssbxSSwZNNU4Si6yA3Jsa1MN4CnqKSxeLDbV6jTEsaXSARt4tRVs
Cbt3LhhmuT6UmKN6wi0iE0WGk1wTXZTAOdc0niwpXMeTliruqCpQrqm1LRNNOsLA6NfKeKK1cUUR
7P+CCaJRgTl7/omGU16tk1gybKIl67WyAWW7axMNdkWMK4JgsxsrI1SnIYqNJjcfcV5VEw2WBJVb
AlKAWiZam8hEkfVoB/ckrgGa3QbPTZlFmDkDG81Fs4dA8KQCi+/DIzKYF8KhAoEi9Sw9LUNBg1wi
43OTS5PDrplTnhPtEYW5Q+3xtHzCKSl40hyI58BF2IEV5aLQHOemhR1KMlDqIG7cC+0EVYLA1kUw
xzUsPeIHYEezRjhFOgZpKJEsEHDS8AzEk9LgHJ2kMR1MfscLinBUY9Z5GseW2jHx03wBhhcSiUIx
xmLY6vyNYuuRidvjUH9VNaKpSi7FgzREMgH31JP7Qwhh/ZFSYJXDSuKGFBoVPVpmdefVvulwSNiq
agFMHmoBNHBuxPqVLYCCUEmpmVC5cH5InKzo0eKrH5iTNEjS98RP7z6kCXDFqVyxmJu+nWmp7kO8
tXSOdFgWDgnrZMs6WAgDFiAWiOWo8AVjxjrQbzrXhUUMyedMPhBJZ88gLgwTlmQSBB9QO6DudPKO
eaqVMCIWp1WnIY6te/zd000vmfRliB4LdFmzJsS5T6s+rDC3wGLz0iqko4tg29ySKLUjrmPrCqKh
hlD9gevLnOU2VKyUhOEqisUwQ3ImfIZh95V5xYsstxZnRiNpiaVMIBOJYmmbshd9mdFpoFpIelQ1
qH7bOaoFVT8FvxLkr5LczBYfs22YNtxSlJf3f5rVx21VoXhJEkVSNTdEZ7e2lEwUxtACFHbLmZox
hS4oNYgybWGus1zj0NiKcQxb8+f39CuSWhFPYskgFaJIyo4Wp3n6nUFIYbCjCYlVbavTEMWmUttV
mfKKFFpZlxfWgJXedqbWIjIxZLpHA8yey8E+zCk+B18sF5PI7L2c/LarlFrWTK3HoT8xAScIo05a
AIr0F8a9QFACSzgGibBySD1enTziUakjniK3Ocmpp6RVFNuWnDiyMeorvwVkmS+K5ep+2zEmZF8t
i8ndzbd1KNE1+e2Xd/ENqNYjllvuBCuMtvC8EAhRPagXQB8ahkB66I5WzlLAtmtmEJJO/CI02XuY
/XGE3V0Mb2v9Ofaofv/lT2XGiyDCOM0kRjvhDARNKoLMdhaHKbynDZ68nGiEaWgtkjFBTSjDaDJe
IAtWB8kxR6A387jiHA/3Q1LZtvTd0wHtPq32zRJKc63skBIS3Gq1rytBiEwtESIJx5tanaEF/1gu
uKHGYjmgQRTQgcfIdp/VS7FXRQ/jbExmJ5zIxhiKcNYB4kYNYRwMnkEc6w65A4Lha3SAkjJg1QCD
8bE3wfOcOGYR9aZ/va8AL7lQ0zZnhgs7TuqDd1q2HMAKriVY+kopLz3BTmKJhCqcMEKA3fl8Lp3A
hZTnfhAXBgpLyjhR7DSXDtWIOhOcA7HdRZ2GKLbkTuzgZHPn+H6YTzrninmDlfa7Fejd7q7f375f
l40N1mU/gMmH60jc9xgIhg1SMv1E9XDSBokvRyj0GQ6RXN7zcBLKeP/OIQFX9yV4TPYkk1pUj7TX
PXu2p9lBhAmHtxnCWdG/rFKA1r1K1qgcSpnLqkdkxYfrnfiUtZRXbj39cuNXASx1lIAOpEaZ/q5+
wMi6n4+MyapkWwfVw8cNOqaRV0Qx45x2VPL+NZkCyB9DrFhy8eiR3lGJVamWQZIkya1XhhfRoLh2
7vRIlhmTOyntqHv4/neSVJWCpjwEB+XCqAGV+wBXsh1FP/ZUX09N2QgUFtjNKphGoUBKVd08LK2X
Df7ncbF8qHrdA/dq2YfWw9bIE5s54XDGDKYZpjjPwEyh1gpmmQardkfGvkj75N+ySemUjlNxPtXV
kQpMCjAuTQa7Z5aFI5LMcuwzSiWzhZQWLN7+VJzP2OlGhc6ZQw6rTJrCZL4wMsM5/OkMJrawGplw
0t6Xiu7ngOehAkuw8Q1BmRIFzYyiOLPS40znGIdIWUmIe04qTlFhPKXgdQ93b1Bh4fQqgJMIBt4Q
Y4v+hZcBk6CJ/WMdU9vLj48r9zdeXwqDfe5hj1uYojqmRN4JS43NiGQks3Ax01zyjDMEy7hiJMex
Hidt29Dux5SB+JRc1IlvIGV3PLm7fFkK89XkJ55TqkVRZAXCOsNe8YwgWmRhf1BQ5TGS9qc4pJQt
0gXSrmX4tkndh+tyY7a/+UVgzdXDdNs9moVnM8eYyygDTUg5t8gVeWGpi1ToCUBTh1VdgO70wez2
bg7a4PpV5ccMCC/7IZysV7UnGAKdnVuXKQQjYF2hsyLXJgMlzzwIA2iXSJA9kCRTfrouJDW4Gvek
wS6dWK2lNZhHau8//rXTIDa99Pv6Fpj962T++Ra4VulP+HR1Dv79P3PX0iPHkZz/Sh/FQ8r5fsje
k2TAC1gXySsYWCwG+VzRJoeCZkR7Df14Rza7OdXd0ZGV1TMcAbqIU9X1ZWRkvDOCuui2BPfw/q4X
TPdKcdhEXk2NuZ5ni87iTyK6IKzKmidtTOU5mlhyALsWuMEo5ALAlwxAubXHllz6NrVCll+G24JO
UklvY041oH2qlmvAsAlyEFmYiLXsC0U6sH3z0rtPGd8emy9KWLDghbZYf+Ql66MALamTJ6IdB6fr
DF7ioB296Ffe0BtJI3iO1FDzoQZgv8/YbIwhgs9gVdyCTZGlFGHCtz9gS/84ch2XtqRmRcOnyQ6R
Kcr2DhOe9Geue8IWk0wxyGx0xerEhtg0JcEFn3Bkf/ruz0RIJAXdRPFJYeW1Y5RUjBQM8anNjaXc
PX64OLlJ5RpdMlZvOblKU3ddTiDOYfkd5OxdBYcwP34ySy7fwPBo0roXfMK8h48+nJ3VGC1PPhQQ
d1iaaEQsbanr+ifg1qI4J9PJsygGsspA8IlU2kFgfHz76+NvsY9Y62r+ML+7yZJNiL5pi82OGFHK
kIFTwSfU6YVYE7VGqaJo4HVtgkYpesEntOlhv1ACKhBuIoYkRcQaEA5Rkipf8DmV2lEeiyHAWvu/
LtuaEEYrp010mE0yBEh6feCZbQf42+Pbd28fjoQMMvgEbqrIdYsWM6TuF3xewXaruA+CrD1bpY21
spUi+4o3oCOvjwg+H67eoyv1033JIys68PLhNKe2hYJekBQUE7oWMZ9kduCSWHBJKpZ1GIKTJAHF
nIo9l9Q2Z6FNrcXwLWfES6qs4ATcWhTT+sIrmkBzChWxzU3tbadEcA4deDCkkaZoNO3unhdHjvxd
HBLpCq6OHv3l/v1T/Ci2nrx9/giSJ6OyQlwdyvKQ4/3uw/0+S+qsSdXALhm0Mqs043yRpkSkV9Aa
CFe+dYu/7g1pW4ubb4lZHYszIhTpsbs/y3Xg+Bx59ocXpKRpwqWQueHnLd3OZ9RUcHBdAk6vujln
q2olOGUBvq8pv+I1sU6GP0Te05OXtrftxosAmbDrFhkErquRVabg+fw1UABFXiEX4rYuF1Y0J0F9
gQ+NpYaXlMXBUbmVE4qNSEMmV2TVWvbmErKG4wB5OP4clC3jxXIGJ92yVFNhphoPGsgaZ7A7YM+Z
XNmvfh2/XFnL1exKAPVXg7asuVSZLCmwzBX8b1GiRq2aExHNrowwvYy8p/2NNYSYy+kcX2X9XaZE
VkxLYINWRO5BNS+qwjUymXwSYs7j2JMSBKEyMmZnm8yYmTzURpbWRiuotzLRtIZsp4mmljT4eL1L
eCyWlaLgvAUbmTUZDpgRoM1wy5FsB7pqTeNMU1CVF51ETvwyvHb6azdivPbVY6rpt1I/Xss1bSah
o2Wrv+KgXPLkpWg9PvfDNy2KZEQfRZrzQbKaIrz2obGkQmAejBdmnfVM8Mid1zLEKLEe8QNL583M
kSD7gp6sHV/K0Sj79MdvukABqWpFNMmKxJpOnjklNEvOZ6Z4AVueB1AbcvfVv3fr62jnvMGlLB24
WI3vTN4dnz0Xd8c3WX+VJa3gyAadWY3c+6ZC76yGizsyX3nC4k8enNDAsE0GW8rAuNUhJi64LUYB
iydjjIo8mRCUBN2ZxKsmLL0jo9Wr175NI5IZyzUMcprE3j/xLClsT7aTEWJDj+2FPclBAsDxbyU1
LOOxJC8OjrpefkK2pz1zIEo4lzwked4v7YxfbWpW6ciz9kAv44PrDYmsFiAVihbudfmV7Peyfu3b
+NWTAk3e1hkqGC5tsqEpjqV2lovAwAVJnmQ5EUe8lmMv4A6YrJJpGYuyLHU+ipAO5Mn5QN4yxuhc
zvAfcJLBonhjcGQ0Rs5npZ7yPb73idJNRCuwfM8YGplJkROpKCSPDQeu5grfjOgVvSE4srJfyIlw
wFW20721INcl8MtM+6lC2IJwIs5GZdojrzUDCiMKFmkf05He5PkSjzMqNtti8UKZjDQsW0NFUlfL
OZ8Qz76XUputoJo1en9jSEJy+sQJxDksGysBAlnALuR8amwp73rDTcFFLV5eRndX7Ocgujtr9J6n
LUZWL47pZn94Pm+xOUoSLLm9SqzIW9jYslUCXMaACQ0Bfljmyjg4uNsgXPnWLVZQoONYakO7ktNI
dWwmSyC8A1MIa5S/WAeOj+pud4IP/74xtjnvKvzsyLUTXseaoyipZNikLIHfqwnSRNGS5a+Ztwhk
EO+L5S0CWVi5bTc2AiEVrJow8BbB+axBTgQJfmaan4M6BnVb0a6PXpYcrcxov4olZVFwdPzmhaSL
IysOlts02g8yWWJUa0n6okClHcc+qtycUo5l1QLjySkWjNFMcmN59a05rl44WTIiuUI14HItV5Ml
RUoltUjMG5f6DDdYZ46VBWWdbErUJDUaxgtkTfsqTHN5i+OrvX4gMCFgR2Toowx9DlEDvuQFrpEH
SCcL4z7FiHUKKsFmpoBewB5qI0fdj1lFvZV5izVkO81bpNyykYIz7pVlvg/4A2vIMWe5rJHDeeBI
kyBYEx0dW7Omcd4CDFgJJjiXEimSPP21GzFe++oxuvj24cO1tMV2CpIhvCWnDliSSlt4k4TIhrtU
6vG2HYhtVbVg2u/vVnrBBAgEkAfGSqtdsl1gXci4kaHzZuZE0CG85drxpeBpC9i4qIJqzIDdzoxU
hqnWbxRq4/uiW8pAhB/q+w8fY9pPcSZSF8+FcWXq4vgm668yL2tmJVXBvNPFFq1r0QGXeJ5Mfy25
/MmL4yKaErnMYErS9m0JjmfQg94ZF6vh3BlVlODRm1ida68aCg50NHb12reZKZ4MF65gkLOk6GXu
YmtKNJB9rYWaiMihUeoihdA8Z4c5Z0v64uDI2xpLuj1tWqqtmVqN9nUwHSg1I1oOIbkMZ6Zl73Iw
yoEwUkZbH16ZYcnwxuq1b2PYQAbfZ2bDI1zhShMlyFIbx7hiuYhLcG7QEUqo+RL3n777c+95knwf
xCVyDPWyV9YoSAa4FH2U5iN4i0sgcIBbLVY3femcrYFGeo56tgk6VhednddKK9ck2jBmYSqhCOm4
+8zcUuqailcxJcNFwOLuK+hI33Cbmfl4scUlCZWSlyZxtB/RkIA0tIlA27UtdjnGHDWYbBE7H0uF
hSOkmXDukhR2x0fqmn0T3IE9vWV3yU44YmbMIJI687C/ijutzLb9pQvA9fyl42V+QJmaRfXFNaQX
8IqtNaQvPTM3jr4dBZsnlSzKRIt1QhjvMI1zQnVQ2T0VVXKJW6Am2oZttNV0wenMTKnL7HJ0HD7s
a2fnDQSkw/n6Fh0nnQULSTufzSbxQtcezky7uprngyMieWqR24T2zRltLNmIQ5gJGU2xn1dgxZTs
hWmX5fEr9pgc8n5CyDmKbcqMdjwkz5k5pXvVNCiAy0ZfZE5Y6euQ/Rzpq5jVM3OBj8EZ0dJIMfBf
YvAxccBknUzFqQb7DqfH2lyk4gqpFfyiczyGNJkOOJynjUcRBxwTLSZu2acNvhYAomOPM/O/rphF
JlfjQSaZFDClOeRsT8qD6QrC810clRDimOiQ2+o0w0zyf2OqoaOlJdhtQZbiUx/CAk51w6yNJZ/i
4Oii3rWF1wgln7n4umNdnZb9vIuHVu8d1TEirq1LOfEY4zFJ/MNehX6a3xIfd7/8+qG3G9xP5m39
zRpLLc5FBm6KY73ch6XEBQP5J6PMshZfdj/Hh09Tdmv5egP6meFttJWcjfChGR4Ukmdec+BpERnW
3LFNzqoiNRx/rOHNcgu2QbjyrZskcSCFysyoOLw6QcSSsxOd67Grgct14PjIbPcS35VJkMVoB7/O
1bBvvyvScPCmwaAQEd5I0eomwbo1RobXrFXpZCAFlp2vDH7yQeCb2VRXVS1YHnF4csiBKC9yVdB9
LTgZttgynuzzXKYondRcpmgkVu9LXzoaQftCZUUdxuqDvfrgbARCevZ2IgS2KGNRLRfuE9gReb7r
ewdFRpbshtYCC+skm+KiD7Elgd3VXlIWB0dWni6Z+4J5tbLGpOJzDm1gg45u2qHQyAk9L6SjBh+1
85E21BmW1iauQ65yU6hXkKN4xnLwx/1f95bXqguG+cP7X97Vx4qaXTeDOQ596qNE++yxQ3Z+FbSX
QbSSLGf3LkFH7+4/PB4HrsAi4B9S7UvrkuTv8G99MNhuL/t2bP/sz/G+vOtPvK+PscTHuNsny8BG
fvwZ3v7lw9v7xxdZ47cbiL1rYOw//HzF/BaC1gKbLqrX3JzJuTdRx8TbyKQTgrxNulQII8lPFjAK
Cc5pS+BZa3co7um+rFHSM5lKYzpzw8DAM6z2eh2vPG9FvGgB42H169ThlbVcLWAE67EJlQJTJVkG
+kUzZyNnyrXe5L53lwpIMU/HRFuXKzDNFTAeX2X9XSaNruAWR800d65lWbTyFnWGwTUneYe+zb5k
XKosTElrem09F+HIOWAwcKuTYZZHw8BezywqYxm4nG2fIgTVgXHOwKd4M3VuSFfaokGL5VLwsrBV
bv5X/1nvf9x/cfcf4AU9YEVhQ4RuLomDhfW0VUllKbRCak1X6GhJhvXWMPrKWtM1HH7WjN3ZYFMD
vpIxMW28ZC0Ex1oVIlULHmBBWnMd1vQMbLGyEu/4JuuvssBBHWUNgKtO4LFoX0Cp4Ud3gHMF7cc1
sRpY1mUN1mzDbkIuf+1GjNe+uqaXx/atpoMhGotKKw7SqRinqhlc1smthiJMAxnUb7ymJL1usaNR
yYQYX7E27LD2m9j8tFj5spxwW6lyR7Zao5O7ss03krSviCYqQha5yZKMF4OYmHc6RdggUH8ymyaE
si538aqtA1r5V2aJ1QqRXPtGwpNhL7chArWIIESw15oJwieLdiZccA8Kjm4k4G4Lb3DdeGrSey3Q
i9wLCuPgSJ/E3VATdVY4E+Hom2okR7qIrDAW6AJCd0vffmGiNrEqsMgvY4wroNGVg/6ZeuNXJWJJ
qfUu/ptQkkfEbyj9eKJgls6lXuEtNVb3NsRG90OcmUDbsZV0B0YTIOz8H4sUslYw8i6L3tYgI5W8
x9xjCsKlo3P6NCDK3hrY5ySKPrg74A8XOMeacR4bCzFkUIiSM3AVBPgvCtzfhLg7o+ryN7N0WLdD
1IIOMv7pz319fxIc1Fm3XVOxBoxy71jyMrKStHcxaaEyLlgHly9nq/PPY7IjAuKYVl/qI6/iTCSz
N17HAax04cfMTOFrFbuhNRH6TA+F1qstbXUcIX0N4AXu9PaPkipxZpbwRUagZmu9qbpgLvPoMlqH
RoujZRuM80+3AM4ub0q4aEbdMAb3565CI6h229CfllKRqWoj0ILWMR/Rp3LER4t0wKqLe3Q64FYw
19IBa6C9DKKVZEHuM37ZlMCN6zxPCaxaNJ0SoBHNjJq+JoK5SBzw2FyRZvOnXjmOkLYbbym41hyo
VX3wMmEzW4anOpCG98x0ZWxiFjhUYH0EWQ02kWcMjtzZMFENTnkFvMVakgTPJaDZ7QFKSZduzEx3
vVqBnbPKKjhZLNpKeQyRvHyODntdhWVjNbjkdNZjNu53rnxHgT8U0yApvzpnNFONujlvJOk8aFgz
QsM6rUMyXHGU7zN4HML1xuoWdR3GEK586xbDUtKDfWbmSl5rPuR9qL2JbMbk6XIdOD4yFxyGQxta
gx8VyfbxwYObz5nbVlq14Iwp0cCTla4YGbTRyoQiX7O8T4rnbkX1b/s9fPgahAqABKj1HowgeO2u
6529HVevsOl6KIcy47cPp3BqlklFqY1t8TbmJdPSm5jjRYDY36+QGWhReXbeCCNTXLU1d/cfgOn+
m9yh50FzPmb+2+OsePZ5VvyPPzx8s/vrbq7lwj/v5nIqy+fXtKM+eX5FJm33ty9JxR/r4567ek3G
E05QqtZUmVmxRTAdhWJgrSdWIlgH2eoMZN3l4wbcfd6Af2G7LnLwBZBW8szI28uYQbClxqSltJeB
33GNywjaM9NWAHdUHVngQjOZlWbZiMqUcjp3xeSrm6WtJI2bZ15ASL0iRXg4VC2yXqrDRIL/LeDs
wfkJHFTH9AJoI/t5FyAc6LW4b5fUFIteCZZdFSwkIUAAOydlmV4AbS1NeKnYvKIagHtldMZhNzWW
egMHRzYVWh69i6MFJiwHH1/5WEeXxEZlZzg0Khl9qr4//fWua/GzQ/37/krPb78cSPnXh2P8p36E
LXw4/AouV8lh16sBXLHGURz7ELuS0ZfiQ8Y856HAeh7Q16h2gHm4jXUP//SSpDtDASctd/fqnz4b
jt0CegcUetiAQnK++18wicHoe6z3v/++34i/7f51vx9ff/rXO3jguObDXuAfojTwjZxCrHpvMEdT
M5xBE9E77UN2WY98PZCbLFSyFAKevyYlFzy5j1UYwbkW4NFhczfGdHkevX+wk3uAbP9cLd/sHv4B
rPV+f9/wv36DV36th2uH8KeDUto7a/vfA8IdXkRhkgUIVzj8p+93X5UP79/C9/ibXakf3+Z6t//b
7k+7b3+O93+vf7nPH2C/foVt/lh3+6IY/PNUDPHs89s+27eyhKCsB1UFm/+0hkUhXygqcrDdS7aB
GVUMK6bf7NW2+eRkCVJ/CpX/z27xgfkVvVRoQ1GhDTkzRv6K91isjlJkk/COJqPDQM7LkJPz0Q8V
zCIVpZo2RnksBjUMtyiqWuyEZjhNsvVKCTBBsvd0uIWHYHob+wAipTThawL3J4ogrebcefGq4Ray
smcbGTbyMNX79oRHBsxAlbMHL53xHh7zx3J2II8RMlQmNQdHoyTJUr85oFO0FTwQGVzD6jsGMbQ3
U7xIKYuTteNLwcvZwbJOydcKS6mNVZ8s86EF5gpwI7CkVY3vvvrup+925VcQZ1cq2Ufgbiugs8kp
FbXkDenZdcpdKDhNeafrKbey4vv4JuuvgmNXEgOdUliTTelqU80Wm1vdcVIS+lXMJBLRGsoNm5Ju
re2WZC87ySfCOT99f8wrdsF69y6m+m6fXc7FVtcnaM134u8Aad2BJqFqJ0WJkl9eRz0vPgdR5sCJ
6/3pwW5RNVpV+31MEOIWvPVXrTSWZBu/9WvfyLQT87W/zDEimwb27he3SMfWAiBMsUSkldcpWbeA
m6geOBwk4LN4d6Rjz3kVDlyjuEpuk5dEAxS3tLpzPGTttCrZYbWno8oLaf5wEpvsXijFTE3D91it
ikqmquhtbQJtUTnczD/e4SRNF/FMDfd6y4DUeEnVYbXhQ06zpA0jJq5PXFF3ss/sAycsa43GeEcb
SzakfJWNJQuipZgpWccFG5wB20QuyttNHq8lTRgx19XtVLBZ76JWXEaH9nMbs9tEgv0L7SYVQ5Ri
ouQXF2wCHJ6SjQWFgqnR8WZSYuRVKEZ2EoVHn0ewJfhuzE5FKbFOokNOG6CcabeLCzaVchYG7OXq
N5kf/0/d1fbGcSPpvzLYL3cL3Agki2SRBu6AYLN3WOBuE9jJflkEBl8T4WzLkOQkC+yPP3Ikx/J0
T810tZzm+ZukaU91kSxWkU89DymKvs3A0oFtfcbmtAoyaN+GdU7n67zLyCRkiazxtJFJgJUtPFUv
cI647vx8Gy6ykYrpaonO8nxkQ6FcLjpHmJU/PDuaZA+KWqKy/HE0H2JINy3JEnXIps7SEJ8dTNK0
TQaTbIdRS1SfT4QzL6KWFdsKmEkkLxnN4cIZ2ZailqhRT6OFxIL94LBWMUeAcX6C0WtzidTzfKht
hTHG4EsJyLpaJflC1RK17JnF2bHDvqI3c0IY5303XEbk6Ui2/MzwWBIbTI0hakDekSHZLbGNx8i7
1yUi3X169ebzz4KZEMUorSpEM8eleXaKeTp0LM+EJlVxgJQ81lgyqyomW0y2GVFKzFjNapqfHbr5
numjR16+KB0/pqMV4OPjxVrzrWzxGfZWmLTHFu33GFHuaw5VeRfabidmLtbO8Wz8cdEkomP8E4+c
fauPXGPTD77ov+sXbrpUSCbIzmmt97oKtY8hdDqpkIJHIYTS/7LrD+4fvqE98+vd/r7TSF1d393M
37895zusml3kdgRLMv8T+2XOtraiMcvIKk3OGLgg2Z6/6o7auSxVjb7O8Sw8dfScfSBGy2gPFp0O
GE89Nu8RnzM611nd9Jk7rSINhGCssQA+R+mlVyFi6tKkKdW8JQYCyDY8tUSk/lQbaAt+XTrZ+Jjn
+Fee3qtyLOQMFHPG0IYsr4GOKQt8jwExgDacozogGZbVSo106VI0utg2k+aq7adOnjdutCslEGPs
LWfsWCJDeiLZq4BKRudSmVGIvmRe0QYuP89/yq/Q0Z4AEWJxcxdI56MDvfEtPA3+8D4/7MfYMjHZ
vrRWOccgeH6/G61IBJKUWC2RDj11utpicS5toUfWTRtIOnytafcv3nnUwnYqD84kk1Sjx2eT7Pxs
mi8qHj/a0noQNfkkai3ysZhQpijIwexzVmWvfG98dlXvhS4Cc/U5FJgpJs6lHX9cMp/JBuJt5jNZ
Iz8dk5P+/Wen1OjuKj/sXobru+a9cL/r3/j653x99fbNC6nclbJ7g7v9f+zetl2xd0HVm9tfwkEy
p39EORRXem8s9RF5Zffz+ddzvMZHjpAPP/50vyu/pvL+QH33y0/Xb8ru1cvX33z755dfffeXb/76
+q/ffPf61ffffvvNy+/+/PXnPZ2X9Gjufmir4ONL7h5fsty+2H3s3e/FYAcRfrL19x27U/7XV+3F
pOxD1Nbdz+Hu+udSfr3vfwS4au/bwgsxfP15tZfQP/Mw1R8fVuJKib3Sc3+wam/N6f9Van8l7V4p
cmrZNnHAHj5z29748Fv18OCszuKXc+1vXw/u4MzDqz025Pz02Mvc/oztr3KvZxTXn8m4jxG2h89X
n3/9AXH32/x/fWDr6bPzv26eLovnXRC/y3t+GoW7+9uP88e0uWf2cJh7D79+nHtStDGAtlH8vhPk
GUwjgSNLpLpP3Bi22iq3TbG4OCvUfTZDGQ3kBWSH9aLd48k4Tta0hyupH1f8cfhU6kqd2NrI7mn1
XLrmyejorfSulDms49ncjraS58KJk+yVUnv1vA5cmHb+f7BxNq5Qhk7nqjTqsD0J++nvh6eMtPJK
+n0XCpp/UrqWx3EmyRKF+RM1OqqCJaLRPrBqdLLRn3WY8WkA0pvr8u7gensFbf87eP7TLz3AIT16
yFKWTJ1nt5kXREmOAaXXiMiBqqqm5iCHc0CQs2WXGu3mFEjtgc+cNVXUS20aB5VqS5/OcB6cq13n
TaPhWYz59KebD2/ygfmxB4nrzph06LXtDnv1crffpYea66vO53Z7e9MCyWNKevjpX/9wOtf8w7/t
Xs+2S515Db1eFBlUafmrKirMHOVesmPSBq4HIGeRUUqtaoE56cWzwZCkvd9k1dCt5no1ylcbbbB3
TXVoDMdjZFGgl0vrneDiD6F4lNZBnCVFPzv1yGbqbUaWVjFbKrxxHAjPIQLmbaIX6HrssUH0VUTQ
gpet0JIKF2sVLaAqZ+sVgR4umJAWKb3moLzagNU5EcwMscAF61OTcc6sx0k047LrZ95GzulIn515
ZHvtFxIuBU2uR8MAZ3ziVo8lZ+9E9XauC+CcmBxt2jazmyK5/cxZE2d4lZzUCayv54jmzynynTSN
GMflVeBxE6KNLSYZayNw6KuAFFpRZkEhQx64iFanquxzmZE1viBGmHXawU8Y8S/SLCQZ8Vcbc4oR
/xLTvoxFD3T2l3pnoug4y4L/Ntz1zXV/ggD/i7zIV7lfg3R/lusf3x0wUke0+82w1BkEX+z+Pn8M
v9KC7/sZ1dOXfX0IdvftiV0bbsK0L2HNf958eJePPPB09T0IENy8+VLeeHnAzz/w2PVTudubzgXZ
f16wGDtvFylLsNbKY6GEi6w6Y9FwCaAhkRJmeQF+nN8LDzm27aa6mTbbCzYikj9AmfVHGNVKaGU+
IM40P16yBw1XR9IEB2b5CcFx5qxVpw8VzWWGw3AAwzEcAM1wYJ7t0EJF14puECaHudbM85ONtnN5
OX6UNmZtsoJcTZastNFSRdsmI0uSLiizvv/FJWNNleiCZZ0wkhQH27iMjB92DZuMA5kVWp9qnGs2
PDv/SQoBZZc3Ah+Htl6KBAEVRGJtV2cMfCaqlCqLNBVd21MVx404XB5CUggouxoQr0JINqRqQHN6
goHuQLerOnBjiQpK1aLoqeLJJaM53HaK9CpY3hM8xaH7XLuennacHicge9A3cRndFW8Xdik/PXF5
zHNRVNkZ8WxOrNBLCkoqu7wz+Dj0pqyrDAYD1mlQu2RMh9tI6dZ4uzpbQ3AasmxFKavTD+jOeLsk
N3qccyfS3gi6uppcAMmKcGRX+iZD68nlistvJyb3YioX1NIEP9NncMHY0m3puFC57+7AetB8fPPu
zT96F4TWQevUgrDgDehwPQCeBIzi8gP54/CGPrXZD13/ldXTQrblbuMyMnzgkpztMSd62s0VEKVQ
umjhWI02nsxBcPnJ1lHwDdE069pr2hlWr/PjqcVopbIm+yqbt5eN522XyS2v6+3N28/GVSuhBUK2
oczx7p0b13NWru9xDA4AU0g6sVj6taBgHJ+5cbG/PlP7PPnQvFWjCYxoUu5T4fqE0pX2HTl2ZXnO
FnrOwIXMLo/KrE+H1ilhQivfgkqcEKclJSr7mYFLLJlMsuPPn7RlsPlFZ0DLT/6ONwAnBWibJbBI
mzUpF7iNx8gN3a1PagVIh8VWlI5zuqblxeIWFxHGT1SLzzDGz9pEQs83GUYahH6xmMMCSBxb0OGM
rW79gW6XElHeOZ1mKNoumHJqtEpF05hptxo65E20Hlu2kYBzDqNJKbMvJN2kabUyt6bxomvSgLTK
+9krgXOqNJqUMNtkBgGZ2Lj1l/5YvFRJ2wiKNYWAJFRyVGdI9pizidXrdC7cn9Memjdtneb6E8jZ
RbpCJORstTGnIGeXmPZlLLrQLU/llh4k5e53dw9wtfYGc7izsDtQOe32h8/Og896h9oj+On63f0X
ecFjUNFFb0uCijQplbdNfCFLdLeeEhZFgKpiQswcAIomuxq2cRl5VeDWc/cDSo9FWKs495+aVC/b
xGO0ZJlbr24lY3VaWIgmsTYxsoFhG5eRFbFbz9vkXc6timzrUrFK4uHk3TStoeZWHyIUZa2tCWwL
9SyPDXeIQHc2+PWHCMFI1/Zsq11ihTISFryJy2j5Lr++CAZjCyQsYAQHo6ZJlPA2LiNTDL+6CG5Z
is5d4KMY3iQbDYygaVSwfwZ5LCdbDpuKSolzwamHQwVrGm3rn0EeC8AG773SgZVi2OHOHkkAsPLL
U/+jddmKqX6jY11l9fNrUvFsG4+RGYZff5/pa9U2Yq6ahdbXwwmdaVrozD8DFE2BNkWZnBLPZcNV
S7SGmF/fOFBlEtoEacwUEHSBx3C4YolGJPv1jQMtwXCqX06LWVXa8y4bLsUghcNArG/ZT1WFUIXT
WbDWJYni3sZlVNIDYrWyWZG+ZqFa9pdYFflw8mGaBEqDWM+fFmRMQiRTcAagdInLhiuWSPkwEMtT
/wnLUk01eVeELqxqyQ2XYpDQbRCr0YPYSQ9yFM5lVvAfTjlMkxhtEOt7PlCnWFQ+7AEcl/nhUgwS
ow1ifaNuVM0jqRSvCs9lw1VLpFoYiNX6dN5LIUPNLlhWJCNVprbxGJ1hrGfwEkFW50VgEsaZ4fSc
DKnOA2K9enBWXRQ9R6c0Z10aUp5nG5eRKYZczbcN0tsgi3XAulkyYrQMw5CAbJDLM//pfll1MVIH
xZLBNcPpzhgSkA1yfY+OCwC6y9xX5KT+hhTG2cZlVNIDcnVfdRRaIYjU6UJZHhstwzCkckDvX1y7
LkGW5GJNKFnnsWY43LghceMgn0EC2urmLB1FDpyWHENyrm/iMhI1DnI93gdrKgFaAeBZ63I4tnBD
ArFBrsf7APpaUmr7CIsiwpC47G1cRqcY6/E+CoqJSqsQWT2QhkRtb+MyKulpSeh6HF4L/NbFkj2H
7tgMx0duSEAsqPV4HwVgjIu5hMhKykg06jYuI1MM9QxNL7p2lUKV277JctlwKQZJ8927DNbek0RR
0ScRVWAFfxKNuonHSGpvUOvxPtWJ1JnQk1KsQwwSjbqNy8gUQ63H+1RTs9PBZQ2sUwwSjbqNy8jz
WLUa7xOsBCu9lJWFwzMkGnUbj5EZhlqP94kOvQk5OOTtl8OR1BpDpxjr8T66NktjkEnPCL9d4rLh
UgwSfwpqNd6nuSrYEGsA3n5phsswSPhpP3Veuy5LMr1SqjHMCNZc4DI7XIpBwk8B1uN9itBSJSUq
AIfgzAxHR2tIOlqA1XgfpQwIB0mlwjopG46N1pDwU4D1eJ+EKvqajXWZlZTZ4VIMEn4KsB7v05wB
oeVW0MG2DJcNxz9rSPwpwGq8j8sVTE9jK+8yDofLMEj4KcB6vE+SHkzEELPlcJGb4cCehgZ7wnq8
T6q+yM5eU5DlsuHQnoZGe8JqvE/LLypahSJ41rokoZXbeIzeL9fjfaqQwajmEC14k2y4/ZKGLsJ6
vE+RJqrqnC6SlWIMh8MzNA5Pr8b7aAVFYkUlWBW5JSFcW3jMknyfsETC/tR+KVrsT23DlCzGYDsc
RMoKcr9kSKVP8ljrhe7w2MhiiLTDkR5aEk8DSwTIT/RfStnKS3TBsw4XLQkV2cRjNBKDIUE96Sfx
oeV2pThbWS5To5XklsYVLJEVP7Eug3RCgcpBFE6KYYe7JbckSROsV+2Wsm2YWZcIvHU53I2vJW9U
YYmO+Knz2FxNSrLmJDhQDDucmrMlb1SBIdY9ZVQ23oeMUbDyWDscv48lb1RhiQD2KR4Rr0OxMRYW
maYdjt/HkjeqwNDlnvSTOB1zjpgli6rMDsfvY+n7yyWi3SfWpagVpVEppsraL0lumG1cRqYY6/Wx
VQGMSfuUNOcE25LUMJt4jLwehCWK3afWZU2tIuu3JJVD8WCHu4yz9GUcQ/x2gsNTLb2w2djMwvvY
4W7jLH0bt0SO98Q9SbTSIqITlnPja4e7jLP0ZRxDjfd4XWZdtYw6IrIokSxJDbOJy8jrQViixnsK
hxdC9kkLEzwHt25JbphtXEbmsc8gDOxQx6BycY61Xw53s2Tpm6VnEAZGZ00RaFNA1iQbjkfE0jwi
S4SBT+WxXkHCGFrRxEoxhpOAtDSPCEOw+GhdCp1tUMLazAJh2+Eu4yzJbAKLFJRP5LHG9lNsI3gU
D5aUftzEZSSzCTDEkyfnsSkFibIIw+onscPdX1pS7hEW6TnP8/tgyDKg94KF97HD8YhYmkfkGTSd
tVA6iggRLecyDofjEUGaR2SRpvOpPi8XMGZVaua5bLSSHGkeEYbK9HE/SVWdQFbnJDjrEoe7JEea
R4QhMj3hqZTJ+mCr7p0WHJeNlmIgyWwCi3Sv59elkRqM7uSehnPug8PxiCDNI8LQuz7m3VI6e6FC
8IJz7oPD8YggzSOySID7xLmPKi5iK8lV4dxf4nA8IkjziDyDBndJJYrikkXBKclxOB4RpNErizS4
5/l9Uof7pNBmGqe+xOF4RJDmEWHogk/wsUVldLm0fxw+PByORwRpvM8iYfAT9WVtLomhZs3i98Hh
eESQ5hFhqJQf42NzaB4JHmth7ZfDIaSQ5hFhyIFPeESyV8VDMNGxUv/heESQ5hFZJFB+QmcvOukj
grCWtS6HQ5UhzSOyXhTc9CBmdLBSsjKM4XhEkOYReQZRcNn8pWsAbysHIoXD8YggzSPyDKLWbY5J
kVL1hnVLjsPxiCCJc4P1otbFI0ShqhIs8AoOxyOCNI/IEsXrU7pBQXkvglWFRe2Jw/GIII3DY+he
T/jWk04epDGShcPD4XhEkOYRYUj5Ht9f5pStC1plzRGNw+F4RJDmEWEo+R6vS5uTy6JijZFVXw7H
I4I0jwhDyvd4XdqYA6qoW/rHysqGgy4iqWMHDCnf4/2y2ahT1Vi1YXlsuAyDRi4ylHyP16WrMWdE
j8iCFONw0EWkoYsMKd8pbl24XGuqFVn3JMPxiCDNI8KQ8p30eXkAEbwymYPEwOF4RJBGLjKUfCd9
XqWYKIsxhVcsDccjgjSPCEPKd6JPkoTIooiYgHVUhqN1RyCJPwWGlO/xuU8NPteodWTpk6AbLsMg
4afAUPKd5LGqaAshamdY95fDgT2Rpl5hSPlO+AoESPBZBuDdxg2H9kQa7cmQ8j3GrctQbMv8U5fr
ZnhsOLAn0mBPhpLvZL8E5ZV2ELJirUtS1W4bl5HFEkPK93hd+mCzFlZox+IrQJJNZxuXUUmPZkj5
TupLU713AkXieWy0DMOR8FPNUPKd4mOtrxYDGpZ0hBsO7OlIGTvNkPKd1JfBpqhlkjZzjsqcGC3F
cCT+VDOkfI9xBTVYKJhKqbxJNlqG4Uiwp2Yo+U50g6JqM7lIJYFzuOhIVbtNXEbCTzVDynfCIyKz
Qqmr0CwUtpOjpRiOxJ9qhpTvMQ6vWt/CmLWOdVLm5GgZhiPhp5qh5Dvpv7QSXPdbcJz7SyeHSzFI
+KlmSPlO9ktrTAzKeRAc1kWnhksxSPypZkj5HvMVmBiLMSIG4NSXbjhyN9oizVDyneqTWJ1S7MfY
rBSDRKNu4zIq6dEMKd8pDk9JI0OMKbFmGQyXYpD4U82Q8j2+J1G2fafTygoOrsCRfH0rPfbqf6/f
v++f+7q8vdn99/W7D7/u/vY/vz21iyWFD3dl9/7m7n53/e7uPrx5s7tLt9fv2493u7fXd3ft6d/d
bOZAk4nREgHiu9Le++bd1ZubH28+3PczhCqzzc6CYY5xi3TNv/XmrGmTr3YRlNRQNAB+HNXHz+Ry
d39706y4Dc2/+d+F96ZglD4Zmat0JRaVgvTKaiHQyXnTLo9xD399ff3u+v7opf/ZZs7t/Yf3j478
+y+314fRO3w03bTBLvflhy/4/fMDOmtGD3IarTDSOmNZQU5fnnxc7rNX/cfDWn25uy35Zt+mwN28
zxbgUBf7bNaMHuaCs8kr1N5xLgTcAiDo5T77U0g/dVvflvuQw33Y/e3rv9w9ta7e3JbrH9+1AHfz
5u7qhDcvL1gWe3Ohgb13IFkQiJB5veluCY1jM668/mja659b/OuxrsUj1WqZjpd4DDjfv/8/7q79
t23jyf8rvP7SFPhS5S65fCjwAc6jjXGJm7OTXIEiEPZFWxeKdEXJie9y//vNLClZkkmKpEXb6RfF
t6742M/OzM5rZ4eq0Nvre43yXlhZaqHF2JzE9lTvC7G9KOSazwtaAxqrxLdAqiKQGs63j7s6c74Z
D+a/REBdQgSRUT9GdwHfAUvJ87fFXd9yu7gRXo9GZ2z5I2fk2Ha1NTkMRXetCYdbZjzlF3qmU3RU
Fnoec6nROwC1ri24txJOhwad3Y1LC1S4LSh8UZQeyT41IV2m0ANRyez/4oWhxIUMAxgxAS+39mUX
fAorP7VO3ltcqTn4I4+HfdtZ5PLv5XSuLb75sicBswCmqnGNLXDTRuCRjIgD/ziPh/Nd1UMXWRPY
5xbf4sFc21fJ8gIE5AYcW/zzAub9/sWrJyMlbUMK1pjTIR0y+iu/Pk/4tZ6ATwULCPSudkMmKXUD
r1dCH7vpNsQV3t24Ynt8P8avxFPiQPS6E1wUaNaxRRirkOsoDgj6zsr1Y+0SR6iQxoRGyjO2/2gx
XwILMAdzBPEjDCN5MsmXQA+IMufFZb5cXE7wPyc5vNe64nPg5NFqnAjCuJjx2ANT5HuaUhZTjwYR
17H2tBdVk6E5K9KHDD3lpXEHiHTYzlgBxYTDcjlViDKMIi9wNeOqKmW6OYlKcB1Ky/uvs1PQFHNt
1jzSDha99ccV/3upz3Q8llr4DGJSG4JpYnucuDZxibAVl66Uvie9iI7Bo0QgN9ZKcUzTpzodQmOQ
Sm5HDvFsKl3Phshb2xCpezIOAhnq4AeaTiQ85SgS2gGPua1jHtjgEYbAHUJlLCMH1uAPNB0SgLrg
1LFDP3ZtHrrEloEmdiQIcQgJAkrV05pOP53TeP7BIx32A+/kniSJsekLiyTplSfBqv4G8+Q3pL0o
UxELtNAxYXvSXvtMUyW0DvX87QMVmaVg0/QcOZjrVOG/0RHNQQIQLlxdTE3MrOeL6oilQ7/fzhFL
J3goojTiLqx6QXmvPbrDzOVOyidJELj+tjCexGWWfZkUKesJSAsEMBMUF/OqKU+m/1OTd+xwPKFH
1qcrRrNZpSISOj6JWZ9zUAea0G5WZZUNLB5fzyxL78wAAkfQdjhVWPImeoTp63nKE+PywcWp5Ea+
UNdO0yHZUiiMci7j1R8g9GAbUtDEMTyUX2pVDaFZoQZ1evSAtIH5QKwVSS90eKh7hQY4C+srn6d1
sxgO7oYQFVLz1yHFBuxVFePCPeVNHtksWpAJyMc3baIWO5nmC4xD+Cw/Mr72DPDN+CqcyRENRDTz
LMPb8vxrNldH6TJJqlE07/WElUZvmk6+TkFTrF6PFpB6gYqUCDy6awF3YjMVuiHESOCAxjFX0ic+
jTwiwlhTR3pxMcujmCf5KjgzU3moAC3cUxN0P5r0cJrCPRU3HulQrFERqIEeV9INHcYqO0BsTqIS
XGN/Io86dXJsRNgGIBYCORIRA4c3DGzPEdrWgZA2CwJi68iFn33X8yQtxN42QmH2te1yX7v4/Yu+
OQJxyCZX2VdQuWnnxYB7sp0XQ+EBCuZEkXY0Yd5ubmLXA9y3AKqhBU3QNqncLJPaE74MVeh4kbMn
h0ICz+cA1g0CHyvsAocFynOcCIKAQMaPv04bexbdjyb91mljSyCPdqh3qVinmkSK+9IUvFSs081J
VIJr7FixvU4LGpzxaQ5D8IUF63YCNJgby5aPZsnYJSPKbEYs+98rrvoOGXnMJo6D1+HSNc+n1xpM
JV6ldETtao7eA+OdUfwRpTZliMBYcYCJvxNCRyS0md8RGnaH6LwAC92gHJ8KAe6P78T7osM9i64a
WrPYbVJNwDA4lu5HOuC6Tdxw9wJ1nBEobu/O74yOPJu690Vt7Mafqxfrb1JfoaxNLnmqIPobW7+D
4ln/bJ2cfnh9dnr8dvL67OyPs7H1l/USRHS5mCYj/CPm02Q5189++g99Y23ZixReE2fLFBMrEGle
/fSLVeH398B+S2tgNygVQ03m4BpyDdWKn0v6EyccEdemFYIYjVhjBgU4ARxIJugk6vT7d+OvfsYq
qmcqm03V2HJ+sZS+nko9KXzZI+slrNos0c8+nb78l8Uih/xSOW7Q5BXdZ9wPMO1/WRGrGhhoRKJG
q0xpWzUfhDKgyouF0KrZ9AkJVFagsLkgKnaodmnsuixwPQYqFuT/UU2foUmji3ovmnQ3fQZQsy3u
Uc62YfoCKVxzVpWQqkNxm5OoAuc2l9RvfmeyLJqEABBUgpp8evFqUkgt1prAIEEQsDAOwZ/nSzU1
El73wBil/8j6GcDEHKJfGxjNbU9qZofKi2zuOoF2Yt9xXNd6BosBDEFiwWrB3WpQRpdZvhhbdwH/
8nPlHBsrHL3ND9Cdn23SNnZDEXLFQxlG1eZBiUlRe7O4udJ5oaC8EQ1sP0LVtb48nV0leBXFIbQj
v7zI5dovIJQG8KRv+xQvzmG4wupGI+KDndj60cUNW5sYK1QmTwqBMa8K2IiQKtNyMFqsBBIl9Hx7
fP1NS2uvGXpzfPrq7evJyemn47cnr9AMnZ8930j5n358+7bCvgwygUMZoGEl7Ylg23Ut70pf5I6I
V8pmSx9yMHRN3tsg2NaaehukJyMhHEEjzYMfA2RnZ/iuIBDwcFFLOf7t9WIOPgUZiWwSkJonSQi+
cVA9zUbrvvlpzO3Z4TdowVuJYogY/jG6/BC0eFRdfugJHFRfDiZpTwTbcLp8CHSHUpOtsdWoSQci
DxJr5gvH/zFAPlVdzho/q+GFbWMPxhwlRCwhaHCeWuzBGpuze2GtX0M50QAnjpgW/xB7dRhaPKK9
OvwEDmgTBpS0J4JtKHs1DLrDmIIO2GpMgeszEcec+A4ZKvY4MMgna68av9HghbV+TRSFQUxCwgJH
/2N0+SFo8ai6/NATOKi+HEzSngi24XT5EOgOpSZbY6tRkzSQfuQFMWf+cLr8oCCfpi5nI7fxrDB1
v69PT8PLppmaSiuHZa6WoIRMkZznSMpj7jmumePFHPdG17eAOku0Ng0blulimlgpTLWskHtGiDPC
UgSfAWaZwWMVm3tPAWIYBVEdRHeMxMVq+vr9x7B1OVgkQkkCiMGU8vbsP/quZrBSI+pGLouJFlQ7
klBXecxh+lFLb0qaNC+g+9Ck6/5jCagxm9DlKwZVZ5kCxlzBhE+iqoYam5OoBBc1lrVstozGwNuM
fD3LJ18vpxKoNTfyOtHXXC6L2tKzMYmwsZ6IeKz4Kh3wps2zYxPbY26ASEliP6a2I31he0IwWzBG
beJTDpqNYVcd61mLHMCDzLGQjdV1kA0zje1j3o+PC66DvsKaRnxZbsFKs/7adc0MLoY9Puu1ShR8
P85vUjkyoMrXaxycgcIHQaNMbmeF4a+vaXFGItVfV7XMsIIKr9LUKsvlHJd+IbfP2mqbSq3ImnuU
tsO/Kbire4YS0IMANsVNlxwkxFQRZddIedBmer4oWywtizK4iQSyX2gUIDNUjk9dJTy1JEyt6lb4
+X+tLFFG+hLNr5GXR+DsW5+fI0fN73w+n25dMGI2WWQTEAUuEm0uxJpyRmJWSRzzuuVsVQWVwxNp
ZhUY1gOV77f+r5KSzZXr7Sn52fqIDZusr4mw5mCBZzOdqqKK0Jzpl5dZlhcibWTikueW0GAPyskq
C27Ch6e5Kd3i1zAnvDAqX5zNp2B0sDY/uYC/F5ezgefTXT8NMHhLJUTBD8a+97VKiG02NG02444Q
sfZVSB2tm12bSMWcMha5JPaE6xHNvTgOCGVOHLiUP2ppVUmTpmL7+9Gku2uDgBpb7bMuLVQrXBsh
qS9cKZ1IVh3c2ZzEXXCk6GtcL0FVh9mrqYWng1QchXHgyz3OsQDrGyjPiyh1idLSCWlIhKKB60K0
5D+yBJE9nZXvR5MeEgSASNMRDXbPg/6URywIfAd85KrOQJuTqAQXNDlCjDYduiDwbuJI7Qoe7ims
3ic1d6HREW2mG90MKlZHW1Dl2vnlcqGyr6nNL9Ddan8MpRy2yWXdGna3QQTKd7UsSe5rBWpWxWJV
g36slFW+AIXJPG3li2wOqKtxNcr1Ji5jrVZUmBRUeDVWvq99h+jQWfdONK4feCEY5Rf3jc1vVvHM
1yl2eCzfg0XZJP83+F8PdK5THBmYxMCNz1YyvbhcmL8n4B5PVAZOfgljbMny/N+7LJ0COSbzucpH
mF1YXiGhcqD12pU+O3uVF6RLbiphNfYmNrBmG8N8tspxch7rCeBZlGoruTHq6iBDvDBDjHEiOE2Y
gnG3Pr0rTmK12jReCwyohi8HQXWMTb+2AGXiv7VcHBZUoy3dFOFzvTBqtghO0sLfhAEKwwLCzLXj
K08TxummZB0L1E0oJuCAVT5cDawpOrkfsF5WAyA1puaY2+M003YfmxCUsBOHgcNEVR/yzXn0wddW
7I2jvl9yuo7WLM6tYtv9oFjToaQtFlWzQEuXyTgAJzCmzV6XTwPmC08wT0RKh54nZEwDEfncjbyQ
OI/UUakkQ+Oq7kWGfkum8TvVzL3fKQim3DCKXJ/7lY7W5iSqwLnNbuljqBi32cFyO3QsMx7HYiq/
JHpyqcGMC6APbrpLh0tw9Bwe9FEyLm1eYd6Oz1OBIIDlHARRSEKvIJaN7QNAQ5wt03SdKVCYrTN9
BVBV3G7urnI5tu8SZjPNpA0GT9hShLETRjqK/bAaeKNBuRfw19+0XJZJDgD8s/F5sSm3DX51AuvZ
xtn8ShxMfi2wUevPFvqjFp9f5NZflo0PoFA/t9roweeWDXzLs/S5JRPN07V7fWfTu5h5Y6HG48h5
Ywtm5t6n6xHVzMO2NxDFVJ2N2ivgXlNTvi1od5t9a+57jDgxkWJP+LXPfNyF5oJ2aIYGJhdbPqMW
/2z9lixz0zMWm/kKnpv+VdjtF8tGwF9fN4feGYmNnXAEkWDPPi5UCVdz8N7igO52ozlJizalIOtp
qhOwdIvLXYkthm/8qFzr4aslpwqF6foQB1opxWRQ1b9n88UDQt6h2J/H70+s89dnn16fWecfjs8+
nJz+/vAUq0KBEXRAYyli4gZkaIq1QFCutyyd5Dc5qKSJyLJF4WChJzaZZ4k+KpplPRz/3vN5XnSw
x12zbH5jxdPkTkerEkD7D6J15mA1DnShMGXuxyzUQWWvk708PAjoKj3Bk6mBXDr8pRKrIV3fttVt
1UU1GEwHR0EU+KEfOZWfDN9Pv/bI2wP5fsnzy4VIJt9myWc8VQ5vNSpPLXaPAw+JwlxV4rPx51b7
cWpi6k4mc43r0zqqzAA8HKoyxQWwjCeV3DwmokI7lZ3mcMuxIsH1MKThIz6fgSQfiBjtl/7bjJu+
hq/evHxvAUfAxapc8m7jR1TvueQrQODGkBu43Pd5SFQfVWkQ1zpv24j3AygSbEt1Ka8ULHG+vLjc
rJD9CC7qCP9voufzbP6MOv+yfkLf/Cf49617jo/bxftHSvz0C8hHMXDdLWNr/Q0grKlAx/9mBXAl
VQOya0dYznSB1ny3ItcA7U5XznL0g3iz1cJSAQKjbM054x6JXZ/0EZYOn/rssriKRrvI2NVOvJHI
aqo1ftzz3kusBgrWMLqeEqFUPPL60a497rYw1sEcvmy7WmX8wBiu5playsWksZLioUCIOU/V2PpT
pwVpHhiGWE4TNUmXM4GHBJgT+PTqgSFcXpSlQrlejK0HHnwtA2S0e17jkEt4t4Vv+T04XAcbxyRr
lEjfb221UCI1QNCt8VTEhOtLyvq45QZ1S1vdDkTJMLjmWGWP0nyG+asiD3gbl9k27pMVnz1bmBpF
WGswZeuaJ9XOYBcS/1Bg20vkKm2ZTy+wuK08NlTjOQ4pkTVAMHesIqqFUJqofkZtSLotr1aC4Jgz
zsBcbX3RN3UU7NsYvAMFayGZ0g2pHd/1Iz+q2sLYT8u+TapbJy3QLGYzq7BM1oVOsRlkNq8h50Hg
tMhe1KBC28JDTzsijAStKnrbT9G+XwdsdO/L7aBV+2/zHdIaEvb9BmAbB78KBqbOeCBl6PuYM+5D
s8bKi23MbSCUSvvFNOWgmfnVleageBaZJTRo+/lcy0UCsdo0/XKnJ1xnPF1CtAtsgGi+WXB+VvYA
r1ErhwFQF6VV4cC0vxsyEUUxlbSXLunCxTYYvuezCZ6ChWBD8oLraorMQ3v7a3a1+BXHyZZzqX/N
Z2Zv9Pzd6l1VCFmH4LcrwrOR5FdcTBNQMthjY5l+SXEbcv3rjXX84Y93Jy8n748/nr9+KHif1+wG
Xqr5FGO2139+AHgK/sJiDGxSX4umpePXlVgrLhko+fLqKsO8o/VMm81jzI3unispILH2ln8A/p2f
Tc5fHp8+TWTHHz4cv3zzNLG9ev2Q2KpE/uT8j02Rn+ZZLZqhRR6htBR5/CZh49nFwxHo5fnb3zcp
JPNk92Ppt3iGJpEB055GlLXfr7yX3vzPj8dvtzTn30u+W6V9i2hw3WngtCdTc6fbx7V+A8Gr4uJv
uNu7wUTc/a3FMzQPDZgOLBxAG3RT5S9BkZ+c/v4Ewe2VrwfSpKe/nW+KVxrfdUVXaIaWLoTSXrg8
+jC2+M2L400CXQpei2ZoAiGUDgQK2ld43IdArzBs2ySRieNqEQ1NpAJOezIxt30G5BH0wBDwqrj4
9tO7bEfUk+tZViPuBtXQnFxB6sDL8GGM8sn5y/OTbQ9d5rvlsreIhvfREU57MvmNZcWHI9NS6etN
KuF/1+IZmkgGTHsaBY1flD6g/YVg8/37LROsF/zq7mboCtPgVrgA1J5S4YCJtAMo0CHg1SnQO3oB
VWitbjDIHkKJdtUPYfikXeMh4NVwdIeXtWgegItd+WfKxw4OCT/8na/S27e1Zrf5bDzzq1MFnL1N
fqtMF11N9DcY674s7bmxB9jwDHJFHbIZf+hjC7sw4FHiC+KoAGu4O29DrTC3FLw2EL6X5+VN01Lk
9OoAfXn3NMfGdTlKi/momOH+fJmWElDcO1Li+W2loUh4+qW+vPBwhG/Yu7pcLK4a6gqGZn4tFKS+
pk6stB+ErKoXWysBGJR2RVmznWF1dRs6DngOohUsVFtSx64rQ4e5US+aDnEs4q35lFzRunH6zcoz
0JEVBa9m/AEPRFTCwAoXx2dSyAiUQOf66BXmtvXRLSCsSjaXUuo8j5cJsFmYTxmWty+ysfXx9OTP
5uOKh6RnLT9N4T2eR3hMbq5BwIOh53HKfc2E7GdU+vCyDkArTp5AxGERGmAx7IiMw7sVsYPxcV1U
9+Z4uzS4mpvRgCcXaqHA4zHh2hPKB6XWS6cdBncd7dDxS7PUBuCrk6k15BuwSqQJDVJQuMILwNiC
te1FwSEqbM41VgS9etFK9AakXTUOVMrY3YgGYayjfnLXHnQrDKsS9vJIpBLl3bWbYmGHo6FdEPy1
Efmgbwxebw3bhhl/lik9TrNJMp1Nq+OpgQaG1TXji/G3WeU+8lCjrpthThaX09wcDx5XHrDriKH9
Us1XrbuxuHV1Bk+nECrXxJNDHupuAINBhRcpGbnK85w+qi5qbK2yg7w1kJKRrwRy25Sw82maj627
68h6Vla3ojS4NHQrMxyDonyHjsxcS+yJpkxH1t4w/fYhegeYh2gVsUI3FBHXvcNihLh+porlPyDl
gg6F310p917PUc3+P3XX+ty2reX/FX1rPBM5BECChDP+0Cbb3cy0u11n271zOx0NCIA2J3pVDyfZ
2/u/7zkgJdMSCD4kyrmZjC2LD/xwcHBwgPMqgv7tsQ2KyX9/5wSStAeiU8y+O3q1XQIMMzHzxyv0
H48IIYlIZUxFeQso7PDzZoSfJ4UEmew1/Aui2B8jXbLx55nPduG8Nu/ZajErw7BR3yhyVfTKhnbc
DXIdJO3dGTp3A+FjgDCsBP/CvcA4f3v+Y4+RiymFj9rUTY55inDax7v0mx6Y63ulJzYjwczMFquv
kyKQCq0bbkjt7fknzVgLSS23FwSxn7C1zfpMJa1zCceEY7GURIgo9mf6EzSJIs4iTCWn44BqHoC0
FUqkBMRGKo7zK18m1V9BDW8GllOo0TWxl4VDvIH+p+VVTuIspUGoMioCh05a7YIbWnvrUAt2LYj0
bses7375dRTcjFIWcZ5KNtY0isdEMDHOMsXGVCXAOyQMpXK4wiC49ifG/cCRm1GUGsUNScdBEvAx
11KNQT9Nx1GiIylkKACVE1yHbAT9wNGbUcJZkIkkAlwsHgdMk3EcJnycGq4zIYQ+ztdWgjurdHaA
YzcjEaSw15FmrIVKxzJJsnFIRTzOZJAoFhmQCodJB0twF9KsilhJ+6IL4tiL6l2oprvtAVj7/S42
tFg6n4zDD5iLGuTaQuVWPsAucb2YmvK+66eRnS8+O9F2cPToO2Jy/QDSb4nJh+CLhxXoJy675mBg
qu1aiyJuVfewnArHmZEUg/g3WzzGahi7xq9fiiaVASrvfpxdghK79u0tOBi/lXb1msbPqhnvGv91
1ziG8E9BLR4tMgBSA2EQrQ9/WklSFviWcw18+mStfSy2F6UuD9/cjGiLDOgX6AEoemgz2JUgBMVJ
/bnN0QMIr2DxcBjSp/y1TGgmAy7HWnExjpiOxjpKwnEU8ixJY6oFDYs8C5vFJ1MnU8/bBVvT648e
OF+B4M/1zSi4Gt3ZiXu9VG69kJ5V+Tqi+Z2xWaiGpXn7g64LHBH05v5wwG50PiL4Rnrh3JPPFpgR
3chPRk8eU+2WhsPgsI0jP8i5za/2Cf0JMR1Livw9lpsNFobWo99+eL8evcozvM9xdnx2fKfsDEPf
YTuhpxZPULDrigXsuGjicj+pdsMJz1s5oArP3XwgRcQVo6GJAv9xAmMxMzwiOgpgC5GZRAQJpSLU
RMAWlkUvVDigpIJPuelFhX7M4g2RJqeVDZAZ5YonghHhSg5V7YMb21n3UidRybeokg7FAo4ymaeS
M6NZSJizSkDzbPIZXmoKfhUtCyYSQ3Ss2D6nSV0O9aaZ5EbW3ubXb+FY5tkEpqKs2T4M0/7hlu6X
Dz+OLg7CrlD5HDT2TCp0y/8d3p6uAodxezAMMzmX92aGVtc9khcBUuUInGO7baXLUjkYCLVzaLIQ
7MZye0mOqBAhzRfrCcxfQHNJBFj184cP//VxVDaNe4PSLeNl6LAyGUzWhydb6ATF5AWwtFhoHg+r
/hU4+FmPfx+5muZ2vwl0WC7maM7/+AqaDa6DiBK3GnteCEfnHvYEbL3INp9Bh9qlVnUDOes+dgfk
nZyq7bQMd8C86Jt8Zq6vry8IYVTu0LB5WOvlZvSs6fCGkb874cSDDE1lxhS676POJ9aroqiH7IYy
+NntQ75cG8+UjQc5n6uuJSqflGdkLgCwbR4YwP3SvYIM1PLexGBLheJmx934MMvnrnGb3LswITib
75BntwvVK9WYJjMDC5haX0/RrwhEt90B4nGKx6+FXEdsEIZUcq7MdIK7gfVkMbeH+DdlRE1Ro7S4
w/pC2bvc4AZhmb1Uh8YXn7Eo+rL0sQOV9LefnUg6BOx0QPJjDuo4ntNsvxlIfuL88P7bo85FMfnJ
8+HHb488F8XkJ8/7D04oHQJHzk+ei2LykufjnRvJIOa0dtS5KCQvcWrXLzGIstuOPPWgBjhUf2+m
pqxLV8RLl0H71o7y5Phck34PQQ3hZtEOlDtyBjENsINtiak27xC55h2q0QwBqyaXBwIbwMuiJbCa
fFsI6qwqZCdQzkRyCGmAI/iWkNzphxDTWaVmJ0wehhrA57ElqNrJ94LC05H12UJ6OdHpzjmLmF5O
dLoyBSOk8+5yuwmCmnRWiOrlxJMzmQ9CGsAltZq6AmuvlemFrNdKG0lwXs+xLpjqqEQHEOLtENXJ
gfM6KXVCVKfWcTqAbGqHqU6r43QA0dQOUr2SwgaQTe0w1eko7MWEQN3K2yEJ6PlFgEfrZS827TzL
CnuxeVe3/HbIt3lmRLVKSviSi0rt9i58sZlXuzkIBzlSuTN7CwU6Cs7ytXX++O2n7/+ztFa4RdN5
0ZzgwcRDrwdTj3ix5/5ozAQm1Jl1/u3hxsRDX6rpKjx380KkRgZJGoWCHPgyHToFprEgiVEqw2rM
mktFVcxNREkgE8bkSzoFcr/nZh8q9GOWyCcACT/JKTCQGVMqJXFsXO6j1T64sQ0gCXtSySf9SHyC
UyCwKCeBSWIVuarENc6myJfuu4rsqOUwUyFhLIphmjQ5BTbMJDeyAXNY7M+al4vlzscDkw6hB3ct
mPMnrbAFwx/kk1UZTbN4wm2LxGl4pY25gdHHHDn62lqd16PZ1qYxGZs5fo0BQrO1mT6aNWyiltNc
5ZupWyGP2mfpb4cIOqRpKDIuwiRk8VOHEOh1gU/fjBbzyY4Sk4ISE2zp682+VKl19mmTm2D06hj6
lcVWQnJ3fLCkMsXw2dKi0zLJWxl+Ub4VfskNlmLN16PFJ0Q6XcBvWdRm3bdQE/o4IPLn+tPTAxh3
BDNhOsWEvxfH9G4xB9mxVUUB2/m4SL0wtjPzBkgLbDKF5zcPt05H8EGxVYYZVbvPMt8LDus9Z+fI
crVQ5gxsWJ876iCD1UM+nsKgTZ/6sF3er6R25a8CDB289jwY3MtULRR4PIokzXiijDbdU851w90W
Bqz6k4d8R63R+93da+C1mXyq9b0evYpejzi7ejtKi1KetXd8G9BhiUBt4TVIlf3zK1NEQA7IFHWp
1UpBiKIR9vbYM/QBGKHX1Bw0hp3AHJJfG6C9v/tmoKUojkup5HKc7wGFiDq9smlIkOtCKVWcCCpF
5zLEQ8ubJlrhHiKmgVSphm50z8TdDX5HNLucdE93fvhlJLVeIf3z9c2ICHpNeHKN1Q4D92o3OLqP
D9tNmU3i89xqLIupdj/vC3m8ANDdjMaDoKIBDCv48Es7Orav19ETXotEyc9gOrMlI1LfTpIGdRO9
ScAB6owzqkDpZpz0WqBFe9NRPxremb3YXm+287lxGmeSDv4a/ReMPbsBifOFzpVdefV2atxrxWVQ
3YGyvCmWeqCVK5f/UEj2WZphJFf3Zq6+4jn+58XqE0aUOFPiIxTfAQ1ldczsIT4q7pkmoCFFKsr6
8HEjqPat/4U7qPsVzvYn7sAskIePWWK6VbMGOLT2xAjj/sohqCTUe3/DdJLyjJvUaHZ+8sBK3abh
3WZvxzWwb1obM4IVBA8CbFEeTCzybGl8ALVWPcj5fR2h2h+gd1Y0mtgbTyOjJDAhjZTW/djuLPAP
puWvpfKfLoAFkco/AHmdmcgHJmANEHjYGCGFCnhgSD9+HLS+kNkvkE2p3Jug0LBuqh5IbVyKsyiN
dCyU4v146Sw0aah5VEMaeAvXBoQgSUAUql7wh0j0/axQ0jRX8Gb4VDOQPgAdZdzzQ6PF3OzPjTJ7
RmgOxNxuBwBzpJB2A5KoRVWrPaXQmJDEXIUmonEU9xrX9ub7n/bNlsVHJAmSMGQ61TzrHzabdMia
6Ifgipj9h9E5ToHJYru5+fgqWxlz9TYDMm3hHvvl7x9foSH46u3HV/+9+Ii/Pj7IldGT0qcNv/ll
sUBuwY8/S5hTD4s5fn63AI1X4evxrw+gKgNTvcNj0as/3gLT2Jbl1Dbzj/Wn7WTzdWn2KMqTKvib
YzWWq7fQdxjj+XaWmhV8C1/Y7cgaPpOrt8vVQm/VRmE1Arxovizz1dcbGxJMAwYkpfQGNilB8Per
tyDZFd42X1y9xaXbPqEWsyXwu/1csjSp/kGLu/JNcYtNr2Y/LYHYcrpvWYH2tFmVN0GvZnL1yboB
Tsqm3uWbVf5l9Dcz/2iH8+rtCq1PudpMHtefc4zyx6z0q8V0anuKBtnKPVOZHn8JCO6N62s7SDA6
n7wXJ+t8Y2wCYcDz9fjWzyadrM00Q/7LlaOhgxsmhYTYo//nP9283V6xP3l61Vk6E6/nJz3ZeSBj
PKFxYrJUE5e5s9INNzzm2ejTRrO55EmWRkGSEEkbnAd0FmLKE0k41TJNdCwZDcIsMVHGRBK/pPNA
4s082osKPZnFp3HS05wHQg3oVCzSjDndTCp9cGO74GJVTyCfwYh28BtAYNcYJV+s56bMhoN0SoNI
p0KmwlkKqHFGoQ9z/YyqQOyI5a9j61LNc3c3aSZIFCodyDAdvUIGuIkDldGERuMki8mYqygZM07o
WPGYBDpkkpnoat/fV22n7VVX0rQavXY9+0tuYZUvbevHdxexcaPb0Xe97ejfvR0dILgd/T7aKRO3
qEq83hm9bq0i8XpUVSRuX5enmutb8npUUSLgQqFC3B4rEK9HVoG4nS9e23K8cG+pPMCnnerw9JHi
dVAbsC1UGuD3k8pgn7UKA14+UhduD5WF1yOPsmDFb+UOUBUOv7KKwvGXe03Ac+m5knB444EG0HB5
pyAc3vY4lfMiCX7lyz8X66PvcDGa7DIY7lAe3VV45h42Yt3kYWVQhxeWhSK7e03hDTL58iCPXjwr
9dyjC2YmcwA2NfbE7bCBhxyR5rhmLovSKpjg4IhW06NhW6XyCK2eHX1lMzUtF7ldbp9fWSJrrT85
QKm9nr7rzXIqNwhukuXTTWWQ7rdTuQK+vJ/oHCl4NHqz5dGI5oXeb90hjqh1v9we9apUItz73A7Z
U4db47yRCzQ5wTcu0ImkAiR3xFxJBRvlN/Oln6wiO07Vx3mmFQuMTtIm37iGFceNrL1nY39rQikJ
d4nkC08cNyMNgmcGFMOq1VgEZlK8YsjW3dzlAGG1R50wksSJDPtYlS8zfg8G/k6N9TQbmngHUA5T
H/7H97Ul2psg0FrnBSd/4kl8CBuhKJXws9eJcocgoc7sVEcYdLRQKpahIaFm5uywgYp15AozKYWJ
U5BYJ+WHhY1oayP6s4oCkwc52RFBqCSJQGElar+qAIny9ZPH6WI+Shebh0plYnRIxXNUPDirBdZy
QL8hYKzWmH84sZF54oxoKrlyB1U0M0+Hsne9BZLN2KXTEZpF4a6XA+Lz6roogolO0dO2xlI/CJJ7
NDJNYEmbg97tpQNGBnyWq7mbOZ+48K8GfqwgKC7/frQywSyqsep64yNZrfn7OauhmVEQHmrOZRa5
Dg6bJ4gXR62rwpN7jUwZEYYaofoZxToEZHZelRw8gWOYMpGlGOShuxecPxviA/bdLLbKVve0AQQ2
HrqGfX2tM3LyQTRhwN0xEZy5bGHVRdUNz7f1YrW24gO5gXwFuxssgxXGtI9/ZtIhprYzXzkGC/lK
hKEUVAuZuvKYNyMWHj2jOrI1+fDTUCckjInmDVUBMiNkbGIVslimgdTSiECZGMAHSWzky57heyOP
e1Ghn9YX+qxO7LQz/EyEJoD/sXY671b74MY2xN6mUsV3vhiDxgcvLbJsrovc3m551CEAuvM8a4SE
cVqpEjQ0MiSm1/YiHEIZqUYg7d3psu3cnp/VaEXnAVLniuPDA+9QsY4VBUUiIL3WxA7gO2Fxuxo6
X2EXjm8A3PfaVlfaPWTzGT9tjO/u3q/flIcv1hnmz63Bk03LQLcxDYLrwP57PbK2iZ1X5auEh/tr
Tl/0F+7mD1KVPkO2j0ddY/xftmt35lFO8zJ5o/kCL0fPp69jXP1gvcuVnS2lnHf0vLbj7Jvu9v+s
vpZrZukHtt7aalrr76yWMtquq/SABW8FF/HspbTe7CMnjigiaikimijS3pdzAIr8tIBb7MHJYY8A
aN8xftEeOZy2K5vYg07SsLaT/Jvu5a8F/7r9OjsIqnN2s70yYb4YtS3DQ+wFGKxVvqyLg/BiuMR5
6XmI4FZkammBTqoqyhh0QVPSa8c4yOBhTeBcF9z8BH4xL/XYsb297ETNeA54QNIFHerasY4STUUU
Ra7EJc0Ubt+VE5DtgjBK7+QdgwCvvzEb9QabXmxXyrwpXnWti8xKcnW/tc7K9tVO/B0Sr5yO/9/2
T9XAfhOQsfkiZ8up8WH2nhd1cLX67WfrnFPIi4n+OpezXE1W6MqN8UEY6ZBGWUhDl7tV47lR5D38
cLlbtcdz7HLle/buJqFRTCUnYRJlpdsVNTyWQqbjIAuycQwMPg4phx8yCAzTAQ+pcLhdNZ20XHUl
UauRbN+7neuV5wmsGYHOV90q3H73dgTbdnguSqA9QhiHL+SX6hfOPnLfDOvZx4GLJjtzNCXce65+
po6ctxJxTUe88iMBBWyK3kmTvR7BDaEyM5Iwkf5VdqvUOTCo4Pn9AzSJz4CWZ8arpaqE4i1zPeJR
Hdv5Dos7tvi/qxzUpvku7qncJmHlapmGURZHZKwzKsagb0TjlHM9lnEYGaMzRdxVQE+Ht1gCt3y2
YrP4hZB2sLFg3wNWUBy9WQNk839Gv4GevNkFgLwpX1/mrHnTphujP0rOymcGXYfI08EGbA8VRss5
e+qtqnUJ5dVbVIuJE7y2kiCJEmkoi2KXetoo/mOfG0IVmcNfLMjiNJQqE6zBa6tpwXIj81lUPYNW
dWg5Nqa63bTqLapx+yREF1HO6PjxQSsQ0HPcpdTqZ95SGmFQYTg1hYa/gK63Gk9hh1zsTafQSJHu
tqzBemttDLD45jO5M+Ks8YRmZm5tXbOlXK8/L1b6dr6dOt03RODzD6xCqnBaPp/ghJ/s3o7DG2hQ
mgg1oTB+gxRRKg0yEFZRkLKEEEpNqmPOqZRhZkCaWIOUdQstLVK2J5ezSglvcoGTSNJLTAlvtHrY
wwpcsU6JVOmUYlpD7rJjVvvgxuZT5WtoVQgqJlnKBYvT9CnBSI2gamIZJzJvEFdIW821h1Seb6YR
n0wPHSXQ3WwVMaIFls9OaOafaSIB4S7SWDLCGOxlFNAadEuFgb0sNPLlZ5o3duokkvSbacSnjIan
VYdPIxVIQKmM08eh2gcnNuqL+quhVTHTIi4EDXREYCI3zLQmlnEj81ItbJ5ps3MvatSXIzR0V4l3
8BUMhgx1xpM4bkiznFCRmYTrkBLY7oacpQmRQmacxyyJUv3yU80boXASSfpNNeZz/Qh7xNhWppom
sY6ZgP/c5Txd7YMbmy9Rbg2tiqlmiDTEUBJFvGlRa2IZNzLvKPI2U+2sa1royzlWxePnKpWF0HGl
tIxlw5oWJyTFlMtApixWzCRZpjkVsIPRoB9ELz/RvP46J5Gk30Tz+uyEPdJ2V+OTaQyTyWhBlcu3
qdoHJ7bIu/lw06qYaEQFqU5AHdSiKXF3E8s4kfH21viLbDDZeIYnNzaKcAw79dliXrfPpNcB9wow
9/GBS9gDoUItkozShvWPBkyBMk4ioeM4UwlThGJydFDTkww0j+NpebEp2UgOdwycgxwkkUbSJExF
FvvJEcoUuC5JVCaMoTpgNIkIC6IkVoYzrl6eHPUS4RTu6CGhEI93UTtleAbAEwUnScyABQmo4USZ
LHWpJhWaOrHFPrUpOu0sQAUh6Ewp5yxzSfMqfZ3YkiFSCe8L0ZSpqlyOENj2WRJC1hjODyEgrTRP
4zCWxJDuaaQQ7xBevfuiwxiwVeYCGD3lAqih3IA+vQ2AcD5kKmI01UEadc8S1w19NzAnSZDEtyOO
eoSDP/d7B54TJiGBCHT3MByE5zu0ixwC93nzWqQRCCrYQ6WHJoaDdRBJmTIhk0wKDtpaqmCXI5NQ
ZLD3MvwFgw9KKrQapNZU6Mcswie6+GnLDZNxlKSoKhvXoVO1D25s3+T08mZp5h0WQZuzBn3JJ2Ud
VgBJo0gSlcEq1z2wB7H5dM0qtrYganIIVR+4u8l4qhRXRJtAl14saRpEQZiqcaRJMuZwcUx4CH8K
HO2QGRoEDi+Wpil71ZUYrQaqoUvPsgZVbztHtqD/Z+7aeuS4sfNf6be1H2jw8M7Z+MU2ghhIFgsp
WQQIFgKvlhBrxtDIDjbwj9/Dnu6Z6m7WqWL1jMYvhiVVdX08JM/9cvgp/JV2/g4nl6X6E3tIhcZH
6v6fH/8YPv300FWo15JEfAOectWa1W5t4NbwaAA3Sy3E1HCR0SUIMsWmQfIKSpsIEsBq4187pnYg
yfxJuIYkm1gIeCryYK7z9KushIxZgDRdPXqyhh42oaluZJb0iuhUVNC6OeuXYmoLR6aHTA7MDh8U
B49pTv07+NXd7a5ze292fzl2mN33mp3men/hBVxxGCXZ0NWJ8cP4lIdSnBTGaiHseMFcQ0YdRUcF
nepe9VC11kUH3ZLI6SN7iVK+7xAZK7Xeffr8MJelVTjd1d0v7/9x31p07f7y4/d9A/SZ8PT3dxWs
ZpTqiLoRPohq3abdXr+GLZCepqPtbyliO/afb4Ud5bYN2Xu6/X2E69P2v5vM53hE9dcf/7Wh0lCs
SNFmeETVFrQ7LCg83OJ2hR/Xhm/e7DwHqU1BDcPIwGzNgenKE2odIoLmwbs4Q9kXw/1UuPXQ+u7L
AV1/rR6nTezVtf2ElFZENukZfjgIM1frBWtMVkNrxpSCCjyoCpVvuV5kK82ttP0wbXR+aHrYJ6N4
QUdPD0WjmBDKBVmF7HY6XqbYesgrEFwlowXFG90GhfHUm4AqRFLNVK9xiz9RCmoE7hRe//MQjATv
lA4l0aZGCioJCA4V3Fhy0ak6zi0yG+PRzszuNV06ksxE2USFjYeFsnudus6lg9q9Q5UxW91z/k3X
0MVGJl6cRTaPju+n+xQ0uFhitfHRwvj++NRfv/vhfj8Q4n4/D2D39k0n7/slEGzbJEn53dxABko7
8fsdanOG8SqLBAU3SfDuxO/FqzzQuu9FyUMyvIGeKI/keYhmN4wJ9RCFWkhSm8TCQFOmF6UQecsH
Mivevjken30v5U/5/t3/vS+fGtjIebS1+erSFnekJDvbfDlSkUkxbiAggjxmllYFTUghrXdlQ0+m
BnIg5+MlaUWpu26gKuVwrPZsGfGF4GOAKOyGiukGa32f5RelDlVC4QeiJceTdGgFza3ZJ7AEGTYp
9/r5Ltrhr9+F/bhNFLC/fmqqUWtCcuhu3kTrzaz/+SWxvD3MukfqTaoPU4lGF5FYNhmYCiAZSIgs
hyRTMiopjzfyuIzHJu27f2G7vVP6D7IKEBWVy8DQelZMJKlYQoubIaNXqVqbXLHjqxgoI3+WVfio
Mm8hHxtqYKUGyyDiH3MAkWryPLRQ4B99FWBRxw+CM2eqZGhuAEu2APMRgANYK0QeX8UfQ7Miq/T9
QPiysbAWvWqyryJbF61Qx22SfWRJvu+FLWc+fhmufHzwzY2WWSiQlvtijmHKYHStsjLhfGYahRQT
Jmkmaw5oTqpcQy9MuWSGjoQpJTnYebr4maUcw5PHf77ZH+Zvd3/SUUpvamWVg2dQnGaC41oLWmdV
ugLcpj+9DKTjYO6H4X5v3+wNs8eHv2qk+fbpuh1fZe1dFmNIzHFtkH3YDKh7Om1KpwtOA0plgK8B
euQHHz7+8jNygzffHPyYDeHNGMLd/afJG4ojz44p43O4AylXz2r0gSGTVwWcQ+7i+kuimN2aJc24
Gh+X9sNNTk5B9VGUfKmMnf7adRDnPvr7/Uck9n/sfv7tI1LtwD/x/759DvpRhW5TcPcf37WE6b2b
TtvgZYYqDe1/0tmUEKJQyIaTTTLgTdJO4oVCgSF1edXUWkl2gli99G1iheyk4K8MaXMOEgWyKdCL
I07X0MOmSIeYH3CI7RNFGrB9g9B3DxHffSUCdyEYKWTXupke/S5A0k72A86gg9F1Dg81Sq9MLE70
rItleJRp6gecMQd4ePwesYWqLTIcZ1y3qeoSNq3JvR13g8R/HE8dCJ9MSV5VbrYgo4XogNfh8dQ9
YQvOV8VzLq47oGMZG7mjA1b+3374cdYjok3ViseWsb2NgJSxjVJ3aG9Dzu8+353fDG5kTNwo48Q2
iJTiegJxDMvvyGbfFbQH0+cHreTyjR4eQzZuQtNliGT3Z1dVoYJrRWzz2XtRoiViGUPVW52AW4vi
nEwnz3YxWPpMDWS7HPjFbx8+ff41tAlrTcofxnfzKlIJtSmGW46VIfPVgA9I0wuuxg0Io7krqlsC
sgyN4rfAB4TpYb+6BJS8eFskaL2Jv1myiQbwMYnaUB5zIVBZ+/+9txc0iqwQk/U9i3cZIKWqAR+T
qScAf/384ecP90dCCvDOitbYy27DSTOUcfnalOI2B7K0YBWHxFXQYBNs2mag78mAjJ2iy+WhXPKB
gg5Sm3giLZofGzB6MpIFfNyjPmWGUkAQgmerXC8cuwyOZIcwJmLPOXX0IkvJk83drIJlcKRwhRnh
SqEYlhd0/TLAmEDtqOaoxmUrnbW5O1RnkUZ6rQNklbV7nhu5ZO72IVEkW+88+q/bj0/uo1Bb7Pb5
HUie9IYCzE5Huk/hdnd3u59rVnTWPmRpunewQLJoeFmVRNdhsQxh5lvXmOte0xd/Q5LIeX2SF1KC
iDL0zvV0HX18Ay3WXs5Z7mmVFTrNOE7JkKBCjhwvTl3wLAlTVGpt6pKoqO2noJ1DHaOiESqM8uE1
M5u8IdWpTWTYuB80kAG9bhJA0CLzmnV0ym2JTXvSHQpw5QAfcBDBR+O6RteUsn1wlDv0hGJLpCFj
KzVBigYPkS3+EFvRVbliuWXR6sKQDzvms/IshuJ0wf9y3mtk/JyxFbqRxsnqZ9YyG1xBMacK3leG
TKYwBOJZ4hL/mCWUoBARhG5wZQnTy/B70jW8ihBjIZ3jq6y9yyBqxWqRAY+BSZ6nylOwfYlMOpIB
xiyOPSl/uLHWp5SUxt/tzfZclEYN07pLNEe9lXGmNWQ7jTPVqLzwOTMbsmE5y4pKkAnM6KStRrul
5m4vB0/24Vi1puVAE8RgY1K88g7dT3/tSoxzXz1Gmn7N5be5UNN2EtIGSq+VfP9MXrLW43NvboBD
QY2dm5TsgbNyngGNZs44mMKSi8CccBHxazT0kXVmbTucdUnF+HroSpCOgena+0s5akMP/3jTGApy
VQNBRwORVRUdsxIUSg+XmORZas0950bsvvr3pvYc1b2v+1zW0pqb7llGXkSuQokxLrXYQSbumxMN
j5iVRsXonDJeuJQzijb7uh2HPNmmZf3enPH647PnrP74JmuvMuvwSGYPhXlXtRBJaDTr+qyebMG9
fo+2SUSy/TbAhjYZE63NBOEBLeQku66P6SK2gFvewdMA+/6JZwmve0uVepwgm+wZ2lEFrBI+5oVO
lhFPe0kRiZdSFVpX44t3IQCEFKp45Xu1WjUh177xvNKycEO/+GljKKMdVK+V62SEnC7iEpz8hpPF
Zfj09SF2k6RHLTtZo3shlanM7yMk906MO/KmPkabPGoKwQVeekGVRXBkTQqI8ajUU7xHh5hQIxDV
d6PYy9BIB6gYCEV1wtgKshEVhX6WvWKVZXDknRADXiwqjq1iCdEaKFVv213S1yYGnBZzl0MU6Syi
EMpfettOJUMXIZl/AmIsGtWPbqNQMSbLokLXBFskIlnDAWI8EHWeI4PsjSsEKDvNRNeQkOq6ckLC
MVptygRoeEj9XIyHxqb8LptsguGqSLHtvNGG06hyftFzdUE772IiwxYDHpKRuMVGL0lDS4ozyVfE
LWyqWTmvpZTdzCseUGjyBNp2tKE1EGa+tV0Lah8leanc0ILy1FONnNRKjvpvVL3uOdN1dPHRAYPl
ofIGRaLOsnXiPm/hfaYqWyeydqi7Vi9Da7XlTNC5lii5zxKF/asFDA5keO3wTYNByrVNu7ERCCm9
5ICCN3HOgxHIJVRW0Y0XjTVQJMeT1+XsBlEtEk+J4HrcZUrZPrjX4C60n3e6TUv7QQZLPFrReDa1
jUUfXHommlIhSVaiTgxsCAxFgGPIiCz+qofK4UWDJcskF10JOF3LbLAk41eFgsgcPsckymCWEoo9
L40VVUJBzbXjxnsWTGNxi+OrrL3LXCqJmeAAZbMLEKI0KJ77Epn2VcvBxLgHH3GwxkerahW1pzQv
SyNqEskq6q2MW6wh22ncIqaatADOuJOGOe6BiaIss4aLEtDsTHzmlJKK7Zo1LcctAkJTQVpUOS+Z
1+mvXYlx7qtHB96H+7u5sMVmCloqZ+jkpC4cSSpsIQq3QcTaGvMfeFzlBa96NkxkxVkxSTEA6ZHH
5YyKsKrWyw6PW1J0vh65EbTLebr2/lL6YYsAIkgvK9OQ8D9CtgpCJVhrqoNqhqwxld1Xb8rHu99C
3M9Qng1dPB/Gle7745usvcqEtYpZJB+DUFpymks2uj7Hs1R7vpNT/mTFuRgtHk8lil1o9SMkh8i1
Lc4KjyIOwIOPXEaPwqKKzlCjL6ngWlp3Wrv2bWqKJTMIVhyQs6DoZXhgW0h0Gdp1k5Wk5zY5Z9EK
7LkLp/Ttg6PVO9XbtKgtD0nJWmBhtGRQUB1SOSf8Dxe6FKWs4mhPojpn3WvWBra1r1ZPyLVvPLC0
1X5dhpTWLluvZC6513dyuogeOACaMuOexb/98GNreeKK5CWirOLp0jxbdpIB2fMN5LgH78nvLm2u
3tWAPHUbNJpkA7GoOY92wrtuNPcxpF7myJSbdRHSEZWRsaVUmYovztggY7IdhrSCjmQTMFDPEDZD
Vm2CzALN7F74Z6pybkE4HpmaupELoChPgQfV8RGs2WSSrajxWqTzKp+Wv5CSC8a6y/qUNftL2gEj
cwYvrjDaHgGQxVguL7POV9COjqeMTBu95C4RT53SwetuzdHimSNbUIF6ttoo07KgdJJGyy1RjCWc
g5mKczxGFFR8OaAUCXnTRpMeFHVdHXLONmouqoDSy3NZ3GpNs+nx4qjpKUyteCUplTbtribF78gg
LrJGWoEtPrVZgNsISKMcl3MXLLCq1GIiaHZflr+tOH50wEYPCBCKjAClTbirvoXTN2w27Z/XY9yQ
YDmga2uzizyn47JfQU3aZa/HJF4/+Ow0FN6a9ut8yW9WnEi64EDPeJeWsWwMhIMhE9b0NNZMDv8I
UbocpZalLEyJTSibIfjYBv1qHmRS1uOfUnaCm2LdK89DaTQh9ZKraLLJQIT1mdSrsgovph0vpBV2
MS1kp67Nou3kAzxzJu0iVj3eouVJjhatOXDU5lynt80KlrUA7boRwEbr7Gz2aIP1UrOm57MP7nld
mOfnbsmH2cdES8wxu39WrQw5JplMKxXYJIksnf//AlVM+FFyzuZANHAkR2dzRBDI6ZCwZbbe43wb
rXjFQ42WVsc9slS90aDRvqUeIQ8jDhrFDqEgGa3LWqOgicfpBm/2etnD3KLweffLp7vWZnM/kbq2
N0vIJVsbGFrnluVcKouRA0N5JQJyuJJd3r0P9w/TpUv+ZgN6M+aU6Hf3QNKWNnIWeurk4uUgJ3Ci
ErciO0skHozN4E03NXZK+20QZr513f2kxg+enPiLE413CtUWlDEhiiWuulDH1IdGclVzdcG7jiYm
ndCg5t2++xMSd/F5MnHMLJdYKy9CiboYuzAWVWuNfL/mUF2RuaognEdZporjXmebXjNxDPzztfq9
5iCTMLbtxkYgNKsbUOwmiUo2qv18s2j1eMG7XBhfuCz73+7/dS8PVtX7pbuPv/xcPpe+MLgWzHEE
Uxvs2SaBHYLlq6C9DKKVZDkrg8RburtFM/Iw/gQXgX8RS1ta2/af8O/amK7d/qDu2P7Z9+E2/9ye
+Fg+hxw+h90+doWS+/N7fPuXuw+3n19kjd9vIPauogpy/35OKfC0wLvOzkBR79He1C50W0RMr/sW
cOM6/Vy7r5SbPxaQw/cCUouKiye1+hfSGjxp/Jte6cQMMyOzLrnIFbfI2yz5ISNJRpFSbUqo4pyl
XBwr0WmmlAk12xpzSS+cdblEctO1aaZrmc26RClbAW1NJnM0THCumDWBM2lra8xfCt7KbgYSPkpi
GnPLH6yFap2LSgrcr14kcklBEnRLvzV0GssEPb7K2rusIrGYao2lQkLlIoLKrvbtPsFJD+gapCuz
LtdAPOtKbo03eP8ZmluRKe0Eq2jg4rsAsRiOn4/9NZH8fs2alrMuLQjLY5u56nshzemvXYlx7qtr
ukVcRULiWPi+Y7xze6i0y6rxsxWyhABHJmesboyMSSMtQ0Vft7TLwJJw1bmENpfPHSa3ZCZ8PXR5
6a3xPV/qdCn9tMtV3oSv/rvcvt1/cfefaNjc95MuBacl9FqEK5Muj2+y9ipLgPpOWwvzaBp5qJ5X
W2eYC5l6Y8frmJ88vaJaX7kLXnTarC8rD4LTJvYyCU9zni+zErdmPAu+WsN4cvMGKYMCW4Wt59PM
zwxqZZThPHoPIbgQeNFehyhcMYVLpc2rJv4Jcrz3+rVvUu32H1/H854+XqX0FgyALQs98xQUIyTX
UJKXKZSWrGzxDMdkkPRavjLhaYVl7do3Ep70PdvrartyttlZXnPN3ajL5PT0wZFODXtdknDV1VWP
4tyIniNuSuE+OJKL2WfqKZDRaKnBoPnBL0m4gteSE3fHU5nPXaxLucx9THSW79q6hYGA6ebaBUF3
ZX6Z8kIhSS3IXRMQEg4FY8iJm9RzUCzVxQhJeu4d5bkP1WjvhZFeLsXhl0p5+tDoYqqlrZp4G1eV
6ZDexqvBzHkb10B7GUQrydKpXvqiHsdr13nucVy1aNLjKOhGniNT2eeyt2OpeGMkb7Gu3q2emK59
hCRHHhkF3snexhuPGm4OVneKCFaAo3ucjYzAniOfT2hVOBGFD72eLlPbo4+Q5tfXZNVIJVJr7q5M
J61yDfHI2zAy/rmT1etqjdWabL3dBM7ROzvg7aZUKC8VL0FwBd2I6zJK0pIeHHXcz1/0QcsQmoVi
e4ryMkSyftvNuIyWsWzMpRSedmGN2tHn6sGSIT2LaX4bR2YyXzpEUkK7z7nSc1mv4B/0rJz1LuuR
dKXNbmtJO/39qqQVAKODUgC61/RD+Gy4sRVM7qa+LUOY+dY1WvnSR58pQ11V67SpqsbOnLvlsyQ5
yVNHhhj2MxaKrFbjHQs19FjVlNp9fM89vv7f9uDvv0F2dP8hI18qt6h94msPM9ObAl1mTtF6KIek
tg/3p3CkEMoFWYXMcN3ZIkNBfjGPBH9PGtPaPQtN+8JSVMEhT3ERH7bSa1ASTfZcVClRS/+aWT2S
dv97/fvMJreDUZPmxbZO2asOxrvbO1zV/5Ln43nQnI8S//44D5w9zgN/++b+Zvc/u7G6+j/vxjze
0+fXtPU9eX5FMGv39y9Jxf5A9lSi0UUklk0GpgJIhkZaZDkkmRJaR6qNYesOZG9nur8AMuIzMtb0
MpmxlfigoJXQj3Uv5ARIeuraJraxjX/RwYPn3mTAY1pUYJ6DYgJ1L5Y0/JO6a9uR40ayv1KYl7WB
zV4yglcDu8Bg7F3sg8eGfHkZGA1e7V7IaqNbkj2AP36Y1dVWdRUrMsksOXMBvaguXZFBMhhBnjgn
DYhahDKvgxmbDNsGmT6Eb1FhrRw1l+I3MhY4K9GvNsxHo1A3juw+OJ6BZzOMC2d58ZDXYooNcwqt
ctE0wm9LdHVLhmE1gvAi1K75JzOhCdOuOyetF7GMoCkBO7thhM0M3Jf/RsehxGbLyr7XPCfJu5kr
PwDXZVMuYX8wKuNQZgEfgk58sJ5zxrnWALH5AciDr9btfDx/2H8uxc92j/98LHFq3wLwf+/KVx7S
oROgvHV4vn3Ssv97JZAdvlg3k9qhXuaBT+/ejungSXz+ff/77345TOt/PD6f4Kb3xWOPh79S3yI5
tcPMNuBC1VW1Y19va68yeFaXrZ7ce65j9CWvHcw8NJG8KS99TNedWFEmdhjL6P/4owIZ98TXxUOP
F6ygCnhgbPdbSZ9L9fA2vfn99/1A/LD7Yj8eN0+v3pYPPD/zYSzaf2jhTCGeejzrc2DBZCE81iRY
p6fLfMvnG7IsZ6EOvcvnL+1YR3NyhPSiB+M5i0n1YOSRVES4MHW+/3L3Sbz/+a4EO/bpLqb3dyHd
7t/b/efubz+5Nz+m796E++KIh+K/92m3hzbUf57aY05+vu9nxzMNK0FJ9F6pdPQMHzYftBEdK/VN
DMoOEqMcojRikEKNgF2IFsTTLdKvu6MfaH+ij3U2BNQWAi1C3NTZUBoLM13qP3A1mpnJjAioYAkt
ouaXzoYQjTKyJG5dMQIpwskX9tV/30guhPKGR5/pUxA/AoKKnSGAFYIJmUUs/2U26oglV171FITk
UupzQ9+sRjo2NVS+z7P6qF08ai1ABJNTjXZlci6TeiPQqtx+AM8CtxFKnYax2ps3dbY5YdOyIjIb
JaQNLKRqM9bxoNeNo7a7VTZgpG6tXgzhxFhRQGfrVCnGkHsA9SyLVxyZBJqh7Dg4WMfdIE3Mg4yl
/HXKCYk1Wbypk9NPm6YKnXzIGgbq+FHqQGeOxnuT0iB8ykMyXg3G5vGOJ2lvZVKY2e6Tz7//fBcf
yv55AeOMJIQCWqTon9f90062v11M0Y6nC6CqSo9Ty15QB03QIkT//ZfPEWkM8LevnU+vRwNVZiFI
FbSrQSkm9zBSImf+wM7Ehz9/cxi/OgCU0h3B2yElEZEFMSom1W/xBFWbz7Fzkhu2twGCNm2VSCUo
QtgXzvpwn62Ck2WuGFYygAkGYyMlD0rHIBjTJTrxHLwsRotohApiVXhyCXFzJwr57J2OJ8Mkb7lz
fVruxXHu9nmOjPhadCWgRZVl5bp1znInQyVfiJ8GSFwkL4KssXcce7lqHMmaV7aoJfkbswwQNChV
pb6fDOSkbasscklGbt4C6P6yCtIzJa+wwZZsoZpdTk01ksIPWjTtz3dlbW3Zkk0YBch6BnNzEVuS
BTlvKV3qeYISzHmOseQKXbUuyXe4jsvoUNZwlTPOr7H5/IXDZGKpZOuYfO46vFDUJRhURbQn7Tgv
HCpfGZsPDGcuqQjGHGoImRwHE80QpRaDSiCGYEAOoANPoOV4nFCpIaY6kT5t9ci8AZt8qufe8PMP
fja+NtYWImUs+1BJNUvZM4jMYPDOjT2VLjirGWMg/m03fnF4+oXynd8eh7djL+XN3eN9vdQgiSob
n2HJ5Fd0vGiBotYTDWNlRm90zKm2l0/GiwkDO2R9Xx4aMWVLDuSVt6m2BRw7um4f1Rjywr767/Ng
lJdaGqmnzu6sKrsVN0EA2hL2onNSsbJ7lSmYfEyrnt2RSPpVwjppUd/AdBpC7i8t2s/1/CqOAAbj
xz6NrpuYCfs6JCNfCGdHwY1HFivp8ksnV40j2TFXmVdkW8afGLlpO1o0sS9kekGXkGi1yaaCQ5kx
r0gJIGhRxh4d+e6X+LShZGtF4lwpqFCazgjYpALPOjOKvJ5qUumu78FclrLTCSz/av0q0yNJ7nHH
Izk9ZPXU8/DRVyW/zMpJaVP2eEg5rbDcOpuHjJoNI6Xo4MGLgUfvHbfRaxSVlHNqu/y0adKQm8mx
By4+ze9jd91oXPph98rdPRZb3dvdOClu38e7m59ff1YS6xtQg9S74b92P5dYOqKX8v3Dr25PGTp+
BIxmN2KQivoIv1FDfZe+xmM8twu++/Gnt7v0W0i/7Lm1fv3p7nXaffPq9quvv3j112//96u/3/79
q29vv/nu66+/evXtF5+/xPnOwe3ufihz7vkhd4eHTA+f7Z6bPcYEfTwk/mDrnzt2l/wvbsqDcT4O
UZnl793j3fuUfns7vonjfjuUVUgM3/h9GDiOn3mKRocvA7sBNpR4UHlDwaDk5b/Khb3h40E5ObVU
mTiluho/81CeeP8qPH2xStv28Vz7x8+j2Ttz/2gHZM9PB3x7eVuXd/kg6mXiNYx7jmdjsPrm5c/v
j3z/mP+3+8bdcXb+z/3xsrjugvhTnvPDKDy+fXieP7LMPTngfu49vXyYe5yVMcABPl7AqU6QK5hG
pb2r5AGGPLaGloPOaqEgyl7olU1gK0z1M9IAsm21afc4GsezNW1HTZ7Dij8NnwA3cGFrIzmv1xlO
8ty6z11nDlE3AANc1VmtCd3/BxurMYQy9Hxecgn7rYipD+/vvyW54jfcDiOHav2b3JScrSqsg4Y+
3uqoJj88X3h9l97sn0yVcDfo/YN9eNEi7jONpw2/ZWSubnPnAiPtgOV3HcGMwMOSlkvRFzDpwq6D
cveYz0YZ7pxmFQ25GQUN2dy/TrgkUVHHzjpvJ9PBOCNZ2dxOz1BPm32mqsK6afQJ2fJDchVL/lee
QCtRUwScnmizr7Dmrsi/3b97HfeMNGMUuxsbivdA53FEv3m1G3bhqQD860iU8PBwXyLdIT/e/++T
v1xOfP/y77vbOjbHbu6wj+S5L7XR4pRMKuVSSsFVydgmB57kzV7HYyRsBpcD1WLJX/MocZ1Dn8s2
l/eTFgE2HMBfIvopHlNgo8ypKqt3jG+rWShICgjA5XAk1N6UREqXHa1np90beEUezTPilYnr67pN
tDTFXMbcBrq/btZc2lbAdrXbYyIswUCgVywxqEGmpmff1ko7Qfb2Ay6GTLFgpBWgrDNVspHJ5bC1
GEdbBLhE6XlcgiNXqAVZU2CdnF5kDz/g8jIiaRQlxdJaqPOWjxmjOUGU+1FEJwTZhA24pHYpFbnG
VIzkvHodNUGWLsj26lVmN6d4v14465wdVFutuRGaeTaxC00xztdNW6ZzdsQOOotNnmQHpY0BvJJ0
Y1SlvC0ZT/S8dkM8HRAWuuwSh+kcB3b5rb0MOc2/bIhS4igHHmtcldMhaqHLnhhS506yM8mCKrHq
z+5xTJaGC5yqHZ6eEWvjXtyxDHi6+/HNHpF1wuRaDAsjg8Rnu39Ur3OWWvDdeP55/LC3+2j3tnxj
V+YjYdrHsOa/79+9iSceOJ5eT5y2968/ljeuprdJMt0utfKUe3eWVRMWbS4DBLLNQCyGwSmThOGx
VD22h9dDkP3z63iMrDLEcoSX1sHbkj07Hc5lXOe4jDawTWulpjMrS2I/6lOzUaipYyeHrZ1yCyDr
INECiruA9QJhmbIlm4w9qD1BN+GLNkpsQonPgAzOGZTFpz1DS9q5ytDSrAFi8fV9NjkbFUTw+pyt
e87Izqd7+rM8Rqa1YnnlbVlAWTZSKVVPs5JA8jBbLGF58xhL9eZMjKbG8jY9/ze3wdMt6uIKt2RG
g1PJOpe6tiu6RV00qjZeqj6l87bkaKHkI7WGksmBFQ0Kz3/SwJJHQXJ55mYFD4yj0LrnRkeIzQU2
QQY2uTwxclEo4yFaYbvOPOnmdrk8tQTORMKyVqPvysbJ/vJVxlSS27tcnrlJFAk8cGV1V+Y2YeDV
MjehhWfGJukruhIz5t7mmqYF3TQtF2duoSwEn0yW0nbdbpI90yCX6KwYBBucBYDKOp0zmFvr+xN0
O7dsaee+gArLwQSfvWasp6NVqM1VLqRFIK+kR5M9dyIyw0Luugam277l8kNwXhYog8BSxh4UliD1
rtYZWDIPUYszNyYgmhx5gqrE1bTHaPsWEbWk4PJeEDrhedCdM902F9noRl11hfNAFqUqmYIWXdAq
ockKUDV2fB5XWIe010oeudNMpVwTLJsc0811Ewu6i1ct7/10qTySiiM7aQ/RkyA13tZxGZmtqUY+
ICLRTdKAcYmVgi12zTY6urUfb51GXw0l8DoZJHSdh2yuA0oYMhFRy3M3LZw1fKS/FV0RbsLAxkzp
cc9FVXx8/+b1P/d+5DoGJlGFrmTcbO4Ki27RUMtzNpkzT4IDaOgqrcg+CNAtGdIhAzlGPhqrZan7
NETouuTYXJeGMGQpqlsytjqZCfqyAAJIxK7tym6NXk+QTQ1l2rbNsIdRZTjd5of7n1/MNGU0V1lL
Fyp6qTNm2oSV7adbp5EXlUtOy6x43yGvJWnQjt3Y7K8Xap8Xv1S3anMlHyn3CXp5QhkgGes9Kuwi
9BJkg8gaLpN0d4NenKdpKxhzTHOPPfjfKfsaE96Dlu3xYih/PCmEmCH0tIdIRq/NGqH5DEvOluXp
5y/asrHpRV6f6eVJLQe0aLSMsnIZNGd+zeajn8XyfApbnqJ5rtu0tdpE0m0Cevn1NshoBTgFGHTP
MNIGzmZgb+g36mZhl2R3wTrDS3ZA6eWdngDJBueE77oQlTTE9OPI+0ha38s0VEfnfQ/SaCYFpuir
QWtCSEKSKlbrzCDyeNa0l0ancV6i9KyE0JS6Loj3Bl6O88ejeTZaKSmhGXiOeKqzfCan6Wm5kKpp
JDh4enYfdanMkgIhu1QWG3Op/2OOaR/HopluOVZIeZIde7t7fGrNKE9Q67Fwuz1p6m7Yf7beaDFS
kRyA/ndv3n6UBzwF0M96WhJAL0l9ulXiCy1ZZ5Y3YSutos+aJw09aElJwsHXcRl5Am/aTzVOKzsV
QiwJPnjWlXnD5jYxGp9u2o8PTjcxx5XPApjF1HNlLDeH+5Y07tu0o4fOTlxEqewyT6rkTF0u29oh
lSSh6GAWn7goCKFk257zrktPSeK+1/EYee5ulh8iuFz2TJOCydhzPitJ9PcqLqPh3mZ5wc5GZnOJ
igXflY+TuOp1XEYWwWZxERyYjwxF2TG7gJCSxFWv4zGyQrbL6Y6CVsykkscy1kMFIjcHpJa0Opdt
r5PP9ktluICEPMlz3MYMl5FA6nVcRqb+tj31P0WSMG2st57HvsyfBFCv4zEy87fL7zOdtMyKlD1U
UPBzXLa51J8GTtvlN4elFtcGA2cCu9bl5oDTkoYk2+WNAzlxYYUzKfcgkuXmEMmSlnOyy1s+HRc5
BK1LDt+V+qvNpf407Ne2p/6n61LzKGzgkRvVlZWRsN9VXEajam176n+yLpPKEEsy6wV2JWWb06CR
NKjWtmf+p+vSlCpJxiyjlH0u29y6JLUNkLWn/mf9KN7mXKKZ4bYLN0LqCaziMhI+i2wxepCDls5F
lWLf4eLmALSSZMFHdoWeD6Wsc9KA69svSY7zdVxGRQpkV6BYCQqjzRKl6Dr3Idm6V3EZiZpFtpjP
VIqoGVeZm9R1gk3ScK/jMSpSIGvP/M90lk1GHxFV7jv3IXGg67iMihTI2lP/03WZcSR6ES5k2RX9
7eZKcpIZHFl76n+yLm0Wljlteew6wVZsaxW5IuGfyNoz/zOwpcNRMN6WNLanWFKbI7NWJJk1suU9
OlpqDgjajmTKPS7bWuqvGJn688V91Tx7oa1nzvmezj5FQkFX8Rgn1yVfDo5Db3XmkJB1HZWpzZFK
K06uS74c76M1AFfIdTB9LtvcuiRBocgX431kGrHsPjlre5IyBZtblyTwDvlyvA8D9I4xD6Ev+G+O
llUBWZLz5XgfYCJ7a20Kpiv6k6i3dVxGluR8Md7HW5ND4Ahe9WT+ikS9reIxJCtyvhzvY5mXUnih
nOu5jFMk6m0dl5ElOV+O90mJa6E8+pHtrcdlWyvJFUnAinwx3mfML3TwnsvUVSyRqLdVPEbC3BCW
431ABGNN2Xll7GmvVZujD1UkzA1hOd6nxDGWFc9cma51SaLe1nEZuS5hMd5HY9QeI8vOdwV/sb11
SZ6UwXK8D9dgfZRGB95zT6Lk5o7KSJgbwnK8jy3rMo1nP7aLm0VtjihUkTg3XK7QrkrsB5AxhS7B
YSU3V5GTMDe8hkazTNyUvCxL6AplanMlOQlzwxbV6IsSEYbzpPe3JV0u21xJTuLcsEOg+Ux6gUdM
MRWHdSVlJM/lOh4jK/IOYeOz+8sgSi7KhbXQ57LNleQkzA07lI3PRHAVlMzfJma6IMWKRL2t4zIy
9W9RNq6vy1KiGgWiZP6h6/5yc+SWioS5YYfS8tl+iZCMkMhZ7jpc3BxppCJhbtiiXXzpPFbEYDxy
J7qUxZTZ3LokcW54Bf1i8DKZxD303ZOQtJHreIysyFv0iy+d+yjOnPI6mi4SJ0USM67jMrIk79BV
Pl2XJkfBPJT1BV0u2xxXpCJxbtgiunzh3CcGrR2DwEUPxZTaHN2hImFu2KIofGFdjsLMmZdEQ1Q4
eee4bHMlOQlzwyuICXPngmDOjiuzw2Wa5Dtcw2WaxLnhcu3SoJVkjruAXToKmqQYXMdjZEXeIg16
YV16zqSD4KWTfZNsayW5JmFu2CH3eiYFYEIoRWKOlvWk/npznIyaxLlhh5rqKa7A5GSkjzLxngxD
k6i3dTxGZv4t8q6X1qXCVHIyXVKNnss4TaLe1nEZmfp36LpWzmMNSyk76bqi/+aoEDVJhYgdwq6n
/ZeGWeOjN67rBFuTqLdVPEbSzWGL0uwl8khneA5MuL76UpOot3VcRqb+V9Cbjd57NKMwqe8KZZtT
H9ck3xy2KOBeILnNGEsK6zFDzyW5JlFvq3iMpJvDDu3bs/2SATNSW1+if5fLNpf6k3Rz2CJ+e5lH
RJbsXyHr6ibUJOptHZeRqX+HHO+ZqkpgqNHI6Ho6yfXmxMY1jcPrUOM92y9DTA4dT8x1FUubw+Fp
GofXog98aV0Ct1n7kpfpHvSK3pyOt6ZxeMuFgRVo7SWIqF3Xfrk5HJ4myd2wRar40nms1JjAeOtt
l8s2h8PTJLkbdggWn+WxFsELnROXfS7bXOpPsrthk2BxdV06NVLVOC4474pkmyN30yS5G3aIJ5+t
S2aUdA6Msj3gFb05cjdNkrthh3jy2XkslCxB8sxEV5ev3hy7mybZ3bBJz7neT5K14GPPkuo799kc
uZsmVabxCprO2VjGgpJWdUH99ebI3TQp4oxNKtMX+klQs1GYSvNOl22uJCf55rBDZfpkXRrGs0Tu
pO/Cx2pSKXkdj5EVeZPI9IX+Sy6KlQZUhB7oot4cDk/TOLwOueszfRIbHSCPZZJ1nftsDoenaRxe
h9716X6ZWEYnuAihK/PfHA5P0zi8JgHuSzyVPAQ+wspin8s2l/rTOLwraHBnHUvgD6CU67paIrWH
V3EZjcNrUgWv4wqyCOVfmWVdfOt6c+RumiZ369AFP8PHRsxSaOsgdiVlmyN30zS5W5Mw+IX6MlhZ
UpWYVJc6ldkcu5uh2d06VMrP9ssgmY4iRtFzT2I2R+5maHK3Djnwc7xPjMFLid73nPuYzZG7GZrc
rUlu+8J+GUr8FwiuT6/ZbI7dzXCyJF+uoK4kcBm84hB6zmPN5uSGDUk3h1cQBWdZMKNjjC70tOAY
EvW2jsvIkvwKAtw5Zh6T1oJ1QYoNiXpbxWUk3xwuF7XW0aFzo5Zj3yTbnMiqIenmsEXx+sK6jOgN
uvQv7q62yW0bSfvz/grWflmnKtTglQRma67Oayd3rnO8KTubS10qpQIB0FZFLxNRGttb/vHXIKWR
hi8QCUkeOVOb9YyobjzdaDS6gSZgJJMhr+CIi7tkVRBv6B9w73VzvjSKaCm54EEhxsXdsiq8583R
gKt86+fHUgWJUipMWEWxuLhLVoX/cLeAm3zr49IiazAyeY5tUFB2cYe7Cf/hbgFX+TbOK0itO3ZL
pzxoFUNc3OluwlvnRgOu8q2fHwvBGERlHJQWFMd6rzR9FI15y9xowE2+jXUfkmVJwnKR4qAQ4+IO
dxPeMjcacJVvY90HscQIopKcBIUY3jtNH0dl3pQ84Crf+rqPsZRnzOZGBRmZt+rtUTTmLXOjATf5
Ns73yTTkSzLnhoWp7OJScv/hbgFX+TbOK9A5RBkWQtkkaFx6q94eR2XecRlwlW/9fRJtrbaMEIxD
6grExR3uJvyHuwXc5NuoK0iJEijL80SGFJWJizvcTfgPdwu4yrd5P4k73QHz1NiQrSVxcae7Cf/p
bgFX+dbfJ8GYpFophoJO3BUXd7ib8B/uFnCTb+PcLUsZzTIlbNCVoeLiDncT/sPdAq7ybeSXRlr3
goTEOGgV4+JOdxPeOjcacJVvfd0nMwonwmY8CRqX3itNH0dj3ow84CbfRn6ZSqUkzmRY8Yq4uKIy
4S8qC7jKt3GuM2I4oxjxLMzKLq6qTHiryljAVb71OJayRKVWUJwHxbEXV1QmvEVlLOAm30Z+KXlm
TU6ECTp3S1xcUZnwFpWxgKt86+NSJ4JmgluKadA+ycWd7ia8dW4s4Crf+jki4MGEzrDOWEhFsbi4
w92Et8yNBdzk26grSBKecc1zFHRftLy4w92kt8yNBVzl29i/5JZwJlGCg96Llhd3upv01rmxgKt8
6/MlQbkSudIyC3H+8uKKyqS3qIwF3OTbWPfJNGdWGmrTkDhWXlxRmfQWlbGAq3wb70VbxHWmKUNB
73nJi6sqk96qMhZwlW/9vWiSUyIIzAF5mJGdcaXs7e+T21v3vRd2toheTebrj9HPP9xTRZnVal3Y
6HZRrKLJvFip6TQq9HJyC38W0WxSFED9xWEHdrTPwbEhFxAXFuRezEfTxbvFeuXWEDRM7pYgJYNu
uZOuCg70my8OQms0DUM+ZVi4qCzZ9urmO8YWq+UCUCwV6NfcZDYhlMMMoYlkENfwnBn4E0mTGpql
rBXagOtXq6fjyXyyqgn9GSxnuVrfbhT564flpOy98qt6AZ1tV/a3M7bf3qGtMJxOE0g7uUw4RkHx
2oD7V/vr7K37sxyrb6KlNYsYTKDo0Fn/pGSwzlphuBhX4yzFeQI/IQuPckCNXn+dPVf6vcM6sytl
1EpFP794WeyjyxdLO3k3Bwe3mBajDm2eBFm7NgcCdLYJQxhrk7tz74P0PMAvAzg73kIb34H/cyvM
kC4bTrhImNk4nH/dmspv33+3dN6raDGP3IyxL8RDUY+F2N8UCquWla4BTbTBt3JadUA6er5/SDy4
5/143GJOjvOMZizFKCTPHgZ+AJZNn7+qvvWxiKsvAns36VxHyQiNUBzjM2q0Ppso+MpMzdU7O7Nz
F6is7BKmOeuiA3DrNoLvfvEO7oMKOGVGMhhoeZ4GXV83RIQARJvO/l9VTZRuIEMDpZlAlNvJ7J2a
wMifRy9/jJQxS4hHHg/7w2BR6T/Wk6WN1D6zi4BZATPtuK4jLMkIJ2KEEfwPPR7OH9qI3i18YP8e
qQd9sLTx7XT9DgzkEwS27td3IPeP/3hxMVbSN6XwVskzPGBFfxvXF1N1Z8cQU8EAgtwHk0xiIowK
W6BwZ8N68grczCsetk+AO5K5zUVia8lFheY+t8gxUUylmmiBeJoxlGh32hzQKU6RVeXcf7NarqEL
3BrMDeSP0IxW03GxBn1AlrmsHqv16v3Y/TkugG90q5bQkzfbdqSgLOcqZ1jLhFlCeE6Y24+0uWWW
yXY1eFdFgtQQZi/eC+AZHrCdsQXqFhzW64kpk9DMCJxTwmjrAuCeEO3g+mcN4ePsNXiKpS3HvNMd
DPron7fqj7V9Y/NrDVkst0THJjE4ZgrTGFOcxUZpqnXCNJPkGiJKB+RTtHUck/mlioNJDlapYokw
i4mmLNYc25jSlOk8TbWw6VckjsyYQQaLOFW5im2u0hhn8KdR7hVTLRGMwa9IHJyCu4AhEYskp7ES
FMc6tTiWGcYI4zQlxFyWOIE+x7sfiAfsBzbWnhi1KMswDFYTch6TdEc4e6Yn6ln2wljmGJtMaEYO
LHsdmpraofWvHuifqOjFHOY0u3Q9WNi5cf+6QLQAC3Bw4elqUubMdrlqz1gGnCo9OGMZBM+tbEsF
M3DipuOgpYjTyNJY8plOHXD7cVVGEu8Xi9/H1ZL1OLMugRk7cylZTdR08u+OdUfvYdlHr/oMxehi
wUQoLVJB86CX7U4kUH1VZbsaWJHfS7aYNySAxBG8nRMVhnyZPYL4djlX0zLkg4cTrUr7cr52Mj9n
t1QOYyPL9fYXMHqYG+bgiXMgKt5bMxwCw6zLj55QN24ZTmbu3HAqFA/aiHNSRB/Uct4lxfng7hlR
ZTW/ntJsYL5q6zg2It67uBjeL1rQU7CPj7bMWuLppFi5PETNipsy1p4BvpnapjOFQwMZzXKxcF8r
ig+LpbmZr6fTVhRui9Yz6fHWSW8yH3+YgKfYsncBQsIgIM7zHGIYf27GcwtOw8gUY8qVSghLcgux
qTYmIdTiKjfL1bTYJmelKF8qQXM68edFx+gkIGhygHw7OAwPKNZoSdSslJIaksNQaKs52xeiFRzx
Z/Xt2qrCpiwT1mQZEhzXjaYeNh2ymnZofr2lXUOsHF0x6ChyOrrJJIdYXKQxQ5mNbZrpmKcpji2E
jBC4UVAQqUZkXNprueUeb7bcq89/t59uwFIX49vFB5gN5oPHqdv28Wg57WuTVAqthVSK8XqkWhun
khFCBNagdYoRS5ESMHp0QiHM0nkmH3+cendmjtNJ2Dj1rg0yPKDepXWcUiUUUhljbVua+0K0gvMm
hQ8HQ6WDN2pSQBNqFcHgGIMOluXMVoxm02uKR4THHEfxf7Q8TRAeMR5jhNxzeHSnismdhanSPSVk
ROL2Hj0CY6OVBPojJtwhKGdxgOk+x5iMsIh5MhRaEjAAKzeXpIwjqbIUSX3AzR0adO3Q/Ga3r7UM
mnFt2TDVQa/HmIr6A4LQCLwja3zOyYjFhB6LunTOv2wZ24/a3jpbG79XcwPZ33X0X+B47j+OXr7+
6bs3r5+9Gn/35s0/31xHv0bPwUTXq8l05H7J1WS6Xtqnf/0f+yl64JTnwCZfrOduYQUyzdu/fhO1
xP0B2He6hu4Gp1JqkyM3hmipterjjf4xEiNMY9LS23wkvScuQU9AD0zHLki088+fy3j1N1dF9dQs
ZhNzHaFvImPvJtqOq1j2JnoOo3YxtU9/fv3824hLhL9pb9cn8zHt/gRifxtJ3tpwMmKJP0SVvd08
owixDCtl+IEQFaILRDhKtcZuIsIGG5vTPBfKFSipR576nE78IeoxOgmY+hwgb6hFAsrZ9vcSBDLE
8IQY2Xas274QbeC496U4tn/P5KZoEhJAcAlm/PM/Xowrqy1KP46sQc4CKPms1mZSWngXwbWz/pvo
bwAmV4KzGDpaxUxbHgvDZKwoSi3KE4QojZ7CYICJYBrBaHG71eCM3i+K1XXUBPzN31pl9B7fy/Yv
oHv75oFuuYVEWHFsNGmfHkw2rmpvVp9ubVE5KPCBaZxI57ruH09mt1P3FPwaTLAy2TxU+j4uwBAh
AWUSJ8Q9XEJz1awrRziBeeLBh9Rt2Ma4nIU2iyeVwZSsUj7CuHVqOZUutgbpLPTtw/btR6ujg9PQ
fz97/eLVd+OXr39+9urlCzcNvX3z970l/9f/evWqbX45hwAnm4DOamkXgq0eWjatT9IRZhvb7BtD
ngudL3o7C7Z7T/0QpEA6sUgkKc/w1wFycDDcNAQMEa7zUijZPa9kSAjYiIxxijsosYDYOG0X07s0
uH815kPpcpYSYjOjIdX40/jyU+jiUX35qQU4qb88m6VdCLbz+fJzoDuVm+yNrcNNmswQipGWGJuv
A+Sl+nL/xV0s7Zt7ZEJSlqaKW3ZxuYf/shUmOuMaq4TCVFCCEf+TzFen0cUjzlenF+CEc8IZLe1C
sJ1rvjoPutNMBQOwdUwFKU2oMVoQg/XXAfJi5yt/iiU645osMTCZ0Fzn5M/jy0+hi0f15acW4KT+
8myWdiHYzufLz4HuVG6yN7YON8m1KyrEacox/TpAXqQvJ/jAfTuEfr5/exqYTRZmoqMChrlZgxNy
q4652/aS7qQgWcr4bun2Ru+/Au5sam15YMN6vppMozmIuqmQe4oxGiEiKEKAWS+ArLm5dxkQCU27
ITIxQl5j4ahvBpcmmqmEpkiZy8rgQEbsrTDjuDM6FIZkVovEECH+DLP+yXTxWLP+WQQ41cx6Xku7
EGxnmfXPhu4EE+owbF3JEdEGCwUg7Vlm/dODvMhZvxTTN6Vy3L0yzXmilLVada2nfoW+/BS6eFRf
fmoBTuovz2ZpF4LtfL78HOhO5SZ7Y+twk3kqhKRGp1lqvw6QF+jLU/h8JL0XOZ0gPXpmyvcq8/W8
9M3RqwV8ZVXWQi4i8E5r+231PtoNZHIjVP58Gzn3f/PjpsWnuyf1/OnLyOBN8aQ7UBdz3pXiyS8C
8ccm2XsLLDOrVo8CqN7vPoBNU0i6bSHpNIYvI5jHGPjGFnCHLVB0jfAo5cRTbsz7l9ZmSqZG8ITY
NPWXG1PDspQhqhnSmEnEtSYslYnWwhhX8tooNx6PIdNH4/Hd7Hb5RcqOt7rxR9DH6GZg2fEWkG93
nR9ZdmyTPDGcuLfN2i582ReiAQ6jUeI974aTpLe2DCKUQ+fkRPgtKUXQRYLkNDUmZZYilVgjsMkz
JA1EDk1L+lLWU+rDd/DNcfoYbj0lIN+WHicDjnRusZ4ktVImiSKMth2lti9EExw+cN40eMpNk+Ol
vVPTiSnfvho7h+7et04TRiVOGEq2RUa7r7lzFKbT3YvLG0bF9o3m0hzKBcQgXKeemt7sA9+Cnn6K
9963BsXeC3GCuOULCeqLWwhAY4glSfdchcmIpb4jSyjk3Pl0XbyPft2NhcIFdyOT/fb5szsv1R0q
9Vv0vfuWQ+JOwsxUUUZ/zkZcxn5ndyer/uXJI/048VYLwBErraGrnWc4dRvOEhLGnlQ2gR7+ixFO
EHsCeQdOGbhZlDxBGMYvfxKhUwNp+1k7a46iJ+5FI9/3Dj3/Sn8eGD+m1zSFuZ//32/RCxTtfj44
X1z+Vu2iRM8R+45+n4roLz0ZbAZgOIN7BG7I27kpOTD0IgBCMId7DPp27ai/R88xGt5+D+rE03a1
JXVVvF+vzOLDvFKlfP68N6sdkKNZNVF9KpZ/bPh811+6JqT+fEbkno9ezGYTx6aDIG00vJxAlLcz
7KtiXUCMY65KPLF+r+ZzO40Y7cuvZucd/A5Yf5PtvZ5ndrZYfroCn+VOUSgtGOh787mHN4RPSoDP
M7zHZ24/QEfNu/TcJNgJ8J8T18Fmre2Lak8VEq7y5JW+nO5FGMiJejAt7dTC7BzIZ4foOD73eK7K
SBH+/52uXuWN9n4djGo4N+Gc1zOyx+1Ah28IRjsAy9n2tzI86kt2YACLpA4MxpYXmBsCz+gASSqC
dknuZn2JDskh6rB8cogR4mX/sp5y7Aja5SggkLf/huC+J6lPGkfA6uAOSJOW4vP+0jQJdo77Xpqr
pS0jdRO7FCuuPFwkCU568jyAWiBHkPRH3SRoQ30LSW3CUt6Xxc5L7AS/1SA8/AXO5pfeWHYOYgAj
zkpbT3trgTNRJ9jTQuWaquqaK3TlVk6iynvG6Ghu5QEJ0fF8YNjDf1d9KoaObuvhvJymCDHRzfTY
yX0guG1wllu1Wi9tnLn6qsU8wsM599TnVbnmcx7N94XQ2yj3POZeM7P3V7/Y+dvFeqlt/NMPY/jj
O3cW7O1yUrgPovunT3/64ZtIQWLy4CvVp0u3WPDOHQLiDo9fLZWxM7X8vYgW+Y5B9HKuRz0RFnZ1
a5ezog/Cpd92es8UnMl6f3h8blkiiOtuCyx6U4zXAmqPpL0z2kdb9U+8yHPQSovDaGfrkZWTEWJl
rCL2oHscZTuBRzmOICm1Kfu30CTwxOUf3WGNbdFrB6fuuNzLKUUeTA/j6aF8uuLyYDzVSl95IE/c
Yn2HYISR17OC3fSmVupq7e7kAY8QCul0PDtxzmxRqHe2OBXGQH4efPuz5clAhjM9hHQ914vNuXB3
9sSAj+HdiXubbJ4Iah92VT68Fx4dcI1NggPOtyLYB+ydmUoSVifxt8FE6WXxXlrvl6KF4GEgki0W
q3g1mdmr3cn08UzpeHOlS4RQ+f4Audb2OiHXWdazmQOCVJMnJr0F2RLsptuH8cpBQdpClnbG/mm8
BbpPVjqitEyQMO0nayuB35JaSQ7GOOYTxLETHc+AK08ZS9jJOauPwzgfUmQZXeK9dYVDiqzMcm/l
Yva7mSwr7G057hUkMGoOQe9GEpZlKjUqj1WSqhh+yWKlSBYbiYjViTVIkr5N+8zqnmBAPh6EtSWH
d40zVNds96pCcQve1p659U7Rz9b63rrPAavaEuy6tm/27hkMTaYH7KUkODLd5wz4iLr4vlF4T5Ds
bbJ0D6ojequ9bVlv26ele4JHMa3W1tfz7cB6jNZbVnzP4P12/fQIzmyg3Ocx0P22faMJRjuvCPZU
5fM+QJCgOkFQyt7OKSRlP4Spb6p9CNFxfDpTke3ePzA09q4YDuxUDHcI72ZHoDlIjD0tH1iPaCfv
vZzhyEn/num19NDO87jljIE4Dy4/DMQYyO/I5QzHlA4BGc70NMsZYYCP4R28nDEQahi77nFUFVid
CFwQt05sdrlcLE+MsDdPXufpT7MdiRhGIkYcVa3sbXH4JnhHkNQJTr9k09qML1JxBFW6LvoLUilL
nHbJppWxLwvYI+ghK7tGaMQ2SZHsIeuGQNYJ9udzkMX915dybzLvpExHlJZTMemzpLkhIHUCzxb3
XK+gq2JXjCBIUt9y7mLo0ysQyDJyIX3WLzcEuE7g3Yx2btNBj28Xy1V5w4KH6yBnvOPa6lHC0a42
bN2tDCcDu/Jh5deIjjgphzPpswJbEVS7kaTPuid3wFmV2pA+654lQZo2CDwtEDkitDKnPguCGwJc
J+hsQbq3nhAR9R71ESQjyVi9tzwEmIOWGnU4XQQEXzM0EqS58NOzGHvDYLPUtMegS2tbAty91NSv
RVxvcXD5ZzeUvnXg3ViGFpD2UMsALMMrynu035P6mPLXPvocyufICvc+iglgdXxR7pYb6SGjr869
m8+wevl9PscXCXej6llMzwZLGVJM36MTei2c94AXwKfHmvaGgFdz0l7DB/z3hqB3MXYn2SFgsg7s
wFRWLWT1KcbeEpTDsW8xdifRATk2BD3lwCNchRV9irG3BOXAG1aM3Unqk2ZH0F+aKiLpU4zdSXBE
MfaWJ67zPISa1OOoQ6gbBJ3F2JzVbz3tZDGwGLub0cBi7IpRQnsXY28JTlOMHcCttRg7gE9wMfa2
rUYJ6jHF2PtMj50cBoLrWYzdh/OZi7FPCaGHUVbNXGIxdifCo4qxO7n6Z4qkSgz7FGNXBNAtjqBP
RXMnwcFlsm7KQ8tkjpKNWLPIzgeylcCnBiCQ1VJqj4W4ToLBe7jdnIbu4fbB1Gfvdcsn/f/2zi29
URiGwrOh8IWLwXQ3SdPsfwlTYqdNwZKOJPebebDez/Hh5oD8Q5hEPh9onRKIYZPb1ymRSPU8beuU
hoyQX9Tkk5YUaVPHOqU9qbyWaA/s8TatUxqiynbhnNbtgIb/UzDtBfzk+xS8BKaX5LJkgtHuTbAt
+6WrAuiVk4K6a3jkMNKGpMUmoCW/E9RbwyONuZuTT0F6HwChhZNgSg/lCC1MCvgzaZMMe4kbu67g
TGDXpLO0I9MVBgCyT0G6lQhm7Lq/rfF9PF9P5/Pan+L9cj+NH9fL6Ran+SNO2zPBBR2aP62ywEEq
QllLT+vb4Mt+z2qx68qjK9nYCqMD4CMpkC/PjGsoSG32zU/SVjrJMuT53eP1EOOkKZLC25OYuykc
2DNuAtkEj9/b1zdltcS4cUIojs3tpS/BP7kqiqNrifG6oyuJcfdxKp6cvzsPK7e7+gl6+HXlrqal
G4YDuMVNnEWBqdtQdrJ0G6RMaJdASuTzMRLjQLBahgAxjqQRxQszstBKKcvhTswmj/iRgbomZU9f
J0aZU+ycKDMa/ZydGHVIu2mdTowtsMfb3IlRRrXZWYhxyxVkcbMT44aEsOe69+QfQT4l+Wkblqxf
LTgAtCYFGNe7hLWwerkZrntD7p5k7cKcbmIAXpoUuLjen66aS4bneh1paa73aXp4McDH9Q7D23nq
Yv/IilDhT0HYC8iDPb71S9cvB2KdEQxjNx7vABjBODy5coiJfZDD88IwXQKhmgzWdDBeDMi99iKw
MbHUiHomlowCM7FkFjUTK+8WcxYllyrvFY6OlbcDVLuYWHlfaPhMYI+gWKy8gYZgFb5ITVspCVtF
JJuPkYmVc5mYWHm3Ya1BOZ7BB2Fi06sj/QE95efvZUivjuBMLCUTgmXBSzD+pywLICY2C3RMLCWS
tgNnYh+COB++Acxvx1OgY2IpKb81hXDC1qQJD2JiKYGHiaU8odQQE0sJaCZ25EK6mFjSSMvEfhrF
buwf3V2IiaUENiZW71ZmYvU+diZWPxbAxL6Yen8clOFQJhZw/m0mNkeYKkQATso0zH/JxFIJfUws
5cr9UmyCsD8e3Jwbu5A4FYiJpQQyE0sqRSY2bH+4dY6Hb1UyIcsCZjd8Cvoh9b2QNgQl0K9SkU7q
VSogE7S6BCTy+WArMXIMm9yxEgNEqudpXInRZzT6eVZiLCHtphVWYsyBPd62lRh9VMQuNU8QJjYL
5r1AmnwPLD+z6JAk0wH85seY8S/4PgXDXlCZiaWGkTYkCRAmNgsSLVKTiaWMmZuTVwG6rTGvOSBM
LCWQzqSCxM/E+p0pJpZylnZk5kzxHZlhSzMTe7lO4b6E/nS7D+spTiGcrvN8O12WKXx83O7vfaAO
yGFo/rSK6StXDhYLylp4Wv8e3MPEVh5dSf9VGB1hYimBfHnWZmIpW+kkq8vEUqZICmdPoh+6uBwO
BDeBfAk8TKxxQiiOze2l7637F1dFcXQtE1t3dCUT6z5OxZPzd+dh5Xb/zgkKMbHbN/66sT8QBtzE
WRSYug1lJ0u3QcqEdgmkRD4fKxMrB6tliDCxQBqDGO7ESGOb5L5OjPLgwJ7VmFjSz96JUedDmibq
kHbTOp0YW2CPt7kTo4xqszMxsfpwJjcHE6tPCHtqmNgkGTRM7Pbtzi7md84QJpYSoExsXEFD7p4k
dGsiJiAmlhL4mNgfrhWZ2Ow76NMyTOwP03pMbNj+lWNOgDTExGbBuheQB3t5Ow/dNCaIFunpUoKX
Ef60atWqVatWrVq1atWqVatWrVq1atWqVatWrVq1alWp/gK6CST0APgMAA==
--f46d04430662c40d6304b92b55c3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--f46d04430662c40d6304b92b55c3--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:21:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQYt-0004jA-0V; Fri, 17 Feb 2012 16:21:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RyQYq-0004ip-Hj
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:21:29 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329495680!11919233!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15104 invoked from network); 17 Feb 2012 16:21:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 16:21:21 -0000
Received: by wibhm2 with SMTP id hm2so5468993wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 08:21:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=HSh36GvXylM68VW8yQP7Mbx76uKzZ9mPihn6meDdYY8=;
	b=rKDwrZJ42Oz2u2a6dgbXvhQaQVlAf4O0CMhMD0MI5iRsFVw6OuUhCBn/CW1xKYIlWH
	Gjdvcu/EyuntYb3rcDjUoVy/4/g3/B4icL+2yD/puledH3gNpGQ4vdEjyELBC/0Anf1b
	In/bWq6IxbdM1cy4UJBHGO3Z8o8vjGJAEqYMY=
MIME-Version: 1.0
Received: by 10.180.101.72 with SMTP id fe8mr4818929wib.4.1329495680486; Fri,
	17 Feb 2012 08:21:20 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Fri, 17 Feb 2012 08:21:19 -0800 (PST)
Date: Fri, 17 Feb 2012 11:21:19 -0500
Message-ID: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=f46d04430662c40d6304b92b55c3
Subject: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--f46d04430662c40d6304b92b55c3
Content-Type: multipart/alternative; boundary=f46d04430662c40d6004b92b55c1

--f46d04430662c40d6004b92b55c1
Content-Type: text/plain; charset=ISO-8859-1

Environment:
ASRock Z86 Extreme4 - Intel i5 2500
http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4

I have installed the latest UEFI patch(1.70) and all tests were run from a
reset of everything to default. I have tested with both Ubuntu 11.10 and
Fedora 16 and get the same results on both, including building xen
4.2-unstable. I bought this particular MB because it had a know working
vt-d implementation via VMWare.

NOTE: current unstable as of last night is still affected by this library
error http://www.gossamer-threads.com/lists/xen/devel/234300

However, after correcting the library error, I was able to complete the
unstable build.

In both cases, it either stops with a panic/blank screen, or just reboots.

Here are some other notes:

1) If x2apic is enabled on the motherboard, it almost immediately reboots
with any of the configurations above

2) The boot gets to here:

(XEN) HVM: VMX enabled

(XEN) HVM: Hardware Assisted Paging detected.


Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is where
it hangs with the blank/panic screen or reboots. This sometimes shows up on
CPU 1, CPU2, or both.


3) There is no boot log written and the machine does not have a native
serial port, so capturing anything may prove difficult, but I am open to
suggestions.


4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic is
enabled, then it simply panics and reboots.

The logs(xen_live.tgz) are attached. Note this was captured with VT-d being
enabled, but I did check it with VT-d enabled and the boot looked the same.
I can capture it again if needed.


5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d enabled(which
shows working in xl) and x2apic enabled.

I have also attached(xen_server_6.0.0.tar.gz) these logs, which includes
logs both with and without VT-d and x2apic enabled. I did not actually
create any VMs, only booted this and checked what xl reported.


If there is anything else I can add, please let me know. I am going to
download 4.1.1 now, build it and see if it works, because it does on Xen
Server. I am open to testing anything as this is an original build on this
box, so I'm willing to knock it around if it will help.


Thanks,

Paul

--f46d04430662c40d6004b92b55c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Environment:<div>ASRock Z86 Extreme4 - Intel i5 2500</div><div><a href=3D"h=
ttp://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme4">http://www.asr=
ock.com/mb/overview.asp?Model=3DZ68%20Extreme4</a></div><div><br></div><div=
>I have installed the latest UEFI patch(1.70) and all tests were run from a=
 reset of everything to default.=A0I have tested with both Ubuntu 11.10 and=
 Fedora 16 and get the same results on both, including building xen 4.2-uns=
table. I bought this particular MB because it had a know working vt-d imple=
mentation via VMWare.</div>
<div><br></div><div>NOTE: current unstable as of last night is still affect=
ed by this library error <a href=3D"http://www.gossamer-threads.com/lists/x=
en/devel/234300">http://www.gossamer-threads.com/lists/xen/devel/234300</a>=
</div>
<div><br></div><div>However, after correcting the library error, I was able=
 to complete the unstable build.</div><div><br></div><div>In both cases, it=
 either stops with a panic/blank screen, or just reboots.</div><div><br>
</div><div>Here are some other notes:</div><div><br></div><div>1) If x2apic=
 is enabled on the motherboard, it almost immediately reboots with any of t=
he configurations above</div><div><br></div><div>2) The boot gets to here:<=
/div>
<div><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,A=
rial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lan=
g=3D"EN-US">(XEN) HVM: VMX enabled</span></p><p class=3D"MsoNormal" style=
=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;ba=
ckground-color:rgb(255,255,255)">
<span lang=3D"EN-US">(XEN) HVM: Hardware Assisted Paging detected.</span></=
p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Aria=
l,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lang=
=3D"EN-US"><br>
</span></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helve=
tica,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><sp=
an lang=3D"EN-US">Then goes to a &quot;(XEN)Failed to bring up CPU x(error =
-5)&quot; and this is where it hangs with the blank/panic screen or reboots=
. This sometimes shows up on CPU 1, CPU2, or both.</span></p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lang=3D"=
EN-US"><br></span></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,G=
eneva,Helvetica,Arial,sans-serif;font-size:13px;background-color:rgb(255,25=
5,255)">
<span lang=3D"EN-US">3) There is no boot log written and the machine does n=
ot have a native serial port, so capturing anything may prove=A0difficult, =
but I am open to suggestions.</span></p><p class=3D"MsoNormal" style=3D"fon=
t-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;backgroun=
d-color:rgb(255,255,255)">
<span lang=3D"EN-US"><br></span></p><p class=3D"MsoNormal" style=3D"font-fa=
mily:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;background-co=
lor:rgb(255,255,255)"><span lang=3D"EN-US">4) Xen Live(</span><a href=3D"ht=
tp://wiki.xen.org/wiki/LiveCD" style=3D"background-color:transparent">http:=
//wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic is enabled, then it=
 simply panics and reboots.</p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)">The logs(xen_l=
ive.tgz) are attached. Note this was captured with VT-d being enabled, but =
I did check it with VT-d enabled=A0and the boot looked the same. I can capt=
ure it again if needed.</p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></p><p cla=
ss=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-s=
erif;font-size:13px;background-color:rgb(255,255,255)">
5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d enabled(which sho=
ws working in xl) and x2apic enabled.</p><p class=3D"MsoNormal" style=3D"fo=
nt-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font-size:13px;backgrou=
nd-color:rgb(255,255,255)">
I have also attached(xen_server_6.0.0.tar.gz) these logs, which includes lo=
gs both with and without VT-d and x2apic enabled. I did not actually create=
 any VMs, only booted this and checked what xl reported.</p><p class=3D"Mso=
Normal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-serif;font=
-size:13px;background-color:rgb(255,255,255)">
<br></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetic=
a,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">If the=
re is anything else I can add, please let me know. I am going to download 4=
.1.1 now, build it and see if it works, because it does on Xen Server. I am=
 open to testing anything as this is an original build on this box, so I&#3=
9;m willing to knock it around if it will help.</p>
<p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,=
sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></p><p cla=
ss=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Arial,sans-s=
erif;font-size:13px;background-color:rgb(255,255,255)">
Thanks,</p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helve=
tica,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Pau=
l</p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,A=
rial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetic=
a,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></=
p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetica,Aria=
l,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></p><p class=3D"MsoNormal" style=3D"font-family:Verdana,Geneva,Helvetic=
a,Arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></=
p></div>

--f46d04430662c40d6004b92b55c1--
--f46d04430662c40d6304b92b55c3
Content-Type: application/x-gzip; name="xen_live.tgz"
Content-Disposition: attachment; filename="xen_live.tgz"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyrew38j0

H4sIACxsPk8AA9xc63PbRpLP5/srpnY/rOS1GMxggAFY5aulKMnhxpIYUcmlVudigQBIYUUCNADa
Vv766x48OHjxIdvZ5FiJJYHdv+nX9HTPAPBWfrL47tt+NPiYXJM/4ZP/5NlPCr/p5neUCiq4qZsC
rlONAxnRvrFc8rNJUicm5Ls4itJddI63+j3E+b0/DwQ+Wi9zyXsyCoM0cJbBb0G4IO4ijjZrkmxm
yXNC3PUm8dP/OoqhTv0uCDefyUc/ToIoJKxn9ph5Rs8+++GZs/JMTk4u/FngbL/ST8nJJ2fpBf/w
5Be9KF7ApYXrlii8R3s6YZpmaUIDhHXsx/7SdxL/tIRDGnbG+Okp+Sslk+sxmTgp+Sd8QzVg7et2
n5nk5/sh4th1qYfRauWEHlkGod8nMwiUN8vgo0/AHnHorHz5F+hAHqMklRfgDycjCUHEN85mnpA4
Im4UJtHSf5OmzxpZOZ+nyyhav2GGWR/xfHQ7OVvH0cfA8z2yfnxOAtdZkrvBNbCt+3Vy8qsf9olW
+5Cz8hKzrOzSySZxZkv/tI5wGaZ+jC50PG/quCnIPo2dcOGfaK8J/EdNw7KsU6IRP0zjwE9INCcg
ONrAq4OhZut5OAVR1yD+m5y7ThZA6ExX/iqKnyUpDF8nubgeQSgIAj5NYODeNxWbEN+Jl88ExgJj
kgcmr5+ZOrWpeE/uL3+9JxeD+wE5n0x28lLyYOrIfcYgq83n8/foIFL4cycvg3GpyJjZzJLM47f3
g/N3l3W+f0WhT8ZXN0RqnDSjAsw3IOoHQuK/5S9csxsxJ8l1VtAiiSSHZGwZooX8JopXEJSkJNlF
fh19xMAjv6HQmHJTKfo8ikF795GEkefXeaRZpvgNxscDfU8yFytKN6WCv/o1fdvD7zaUgwJRGqXO
cu0spO9aaTNToux9AtEjaWUMSQUghkG+XTxazoJhHH9sC4EtLYfFLyN/Td6Nrm7JzEndx77W5a+M
izHKjpCr5KOGbVht4+m00+NVnfYOp7r+YLbBcDzqk7vJxRiT2JXGDZzRGoMEHzMyeDeY/DhoZLGM
6dfJxT05vzKgshCSyRgCE82ZkGNArskIQxUnmk0GkGWyMNZgwWkHvYIfEtSi1ELQK5SEfxnoRSkp
NQBUXJ1fKOopoEU4j27u3+ESZVCol7olnQCoqZ1fWVJ93gidjHAwHg0zlRiVhILB6PqXqTQpVLJg
zQFQqrHM+Nej4fhnyT6+ux0WKlFyPbm6J0SXILQD9Hp49TYD1W0pqb7Hoxmo/NhddhoMrnJJ9QsJ
eqGroLeX15LiONAfxpc5KB/IMNGtvbHXK1NuV5hcD+5y0Esp6bnWDlrYVIZJ8VcH6Dvp/hPHXQfT
wHvQPmuQX5fOOnDzPzEBhzhxvYMRWBWBHY+gVxH48Qi8imAehDC9gdBWUHDVfQwWj8T3Fj7WfSlc
pO87IEa3mRSl3aAagUyfIJDv5qSLJJjOoCh90JowGQB80ye56Fi8FAUu/JoDki3ga/J2MiJQJOgd
Mt3cTyd3w+ntL3fkZLYBVgL/ToP4A/y2WEYzZyn/YMSbL/H/Lt26cWwVx87stfQ/+p1Qdz9pWdqf
PZMItIuhGmqUdCUtO4LW3k878dMUK0XpKmhT5B9pRKBUr5P+nEhCACcn14OL+1O5TmHXAAX8PFhs
YidFxwThHBdE/L0h2XIZuY4cYzwc4bofbWIXlj1Z+siKNSWZJ7EqX0BRT2bzrEjv63OD4ncNO44v
7yCJ9lV0WPdtBoqnWW279mPsu4jnpE6d++ZuCtyTPtHZaxLGU6CDSIOahzfaj02wTCGP4Iq9DJI0
AVWzcjOKPT9+TVbRLFgG6TORDR/KEYWQxu6xkCJlJaWbrLH0/Agtk78EQ/7eLVWlUQU7/LUh2nh0
QR6d5JGkslzJO4Z+VgmfSM1BK7CdzoRpZTZvNlKfUz/Epm14fTshz1DC9nHBbgyGDUHsr6M49T30
iM16BlSW1z/8hn0CREoSxUoMcy1rRKWyfdB6CfFEfnk7+DuxtM/MqFPmZiEPaJcyBXZSPX50z2gn
2QWa4pm4UKf7rRaiOpXFQ24jWPiKjqBuJJ77Agrvs2480zD0rcnFa2IwDuVEB9okmqefnNiHNEru
350XWvRJnZAMYHqkm9jPGgSTQ+25cCRogzSPU9ll9Am0YXPZQjPPxFIFWuvykpldag6W5+wk+A3r
c0FmQdoYB5LDGSzv/TznJIUqs2gTuvBjM59nDS5mINDvZPI/o1tQsmGEa9lHQ3fC4WM9fW+aumGw
J+J8dIKltO4JY0I8kadiAno+uIlqhsmfyr4EHce0J5k+XhNGzSfZpTdGG45BZJznZB1FS0kj5xbE
PcU0RPMiH/p2J8tV26iC/krTYVkeAsMszrKY5y+dZ5j8MicHK0hiydp3g3ng5qna7/UgKiyzxw1y
Hi2i69F4Qk6W63+/gdgTzKb2qYJPhYEJ393EmKOuYsgfn6L4SZVToWY6dPeTS7k3BZFxEcgtEg8z
NCamnkpq2yj42snT37vJdQeobgpsejdhuiPOlTQFLNymO/fTwkQhhhmyb/PNcd1U4TCpsZPD8z8G
rq+OYdo6uhoWnHdQU2bzH3PVj6/xwoVyQWGysOzLmFhBAXpWSExakOgFiUk5V2lsxnOacbH7NS7y
IhldQB+pElslcUkzjDAjVAltjYP/cCF3likuNLibAH5IPgXQ8uYFwc9jOTlKLptZplXUGhI1Bktl
G5i46aizslM2NaZbYu8IWSWxHcKEWYUx2Fii6F4KVqc4yl1VplZ3VUna3VWh2eeuKnHTXYpGlkbB
8OcQpIvHlECkcuRK6gRwTYPJmjqZgRMQ0DvzopUThP06Lcmu4x5Rw5Z6nThZO0B51rhOsrJH7hJS
qKAbBIBGXyDR/vHkaKoty/HYNxlPjkZoy3j6NxlPzyyqEujW0UGtMnUEtUrSFdQKzf6gVombQa3/
v5umjZgI/XSKhTo42cV9RcY4qZRWBeHN5X2f3PkL6Cv8GE834iiNoKAlc2cVLJ+hb1A5GC1SLzaf
6fMaSg43gBRc8CvElDNZUeUbRtVmDeIP22/iF01X4i9WsBJnDa2Pje0ZmNRQ8BjuHki8myjNq5Pr
6+HtzdXobU+lw7Ve0mVVXHVgKTOVBZwUAJZlsOWW3YZGqdDxcgjei6InTHaXQ+y6cIuwpKUmdFQF
LZ4RkentZHQiK5dT8mHjQ5UeLMJINQvwWGy7kzQik2cw3Ir8Am1KBNX1fUTOfXIVLLHkOX8mt73L
3nVPYRecq+wQC97GTckN+PoAbgtt2OT+JdvbOATAtFWA88iJvXzwf0EXBv1W7K98rnDYrMqBdiq0
HUBtCWEfQr28cIAz9BJYCFx1QNumDfYLKGBhcljfM+N7ptFt8FOhGaV1x/LUEQILGltkxf0B4swi
aFph1V+il85wj+kfHxd+3MsKcTzQVNAoFmn5tsac/EXuSEVJ8Ea6+C8Eq9iEzPw0xS58nY0XRmkw
fz4I34ZpWeLj2RkU6PBvvfFDQqsMypNks8ZGNSETjUwomehkYpwqtFwvDZ5NgHxDDEM+wFHizTot
9lwUPkM3v+J8pTbEiooHfZSDRXyJUHQ5OK/k7s4qSh/9eCZDqtyiKQGZJXSjMrGLyV9BPSP+PPuU
nDo38cQwj4rhiNxBHwGFTIC7iQ9wASbxidzqUTZ5TK5xk6tco9J2d/l+1b3sHx7+dzo5n/YQpzcd
392/VyDMrYMPhRhf/tqCY1kvwOENHGG8RB6jgWNR8wU4ZhPH0l6AIxo4Nj/aVRLn/I7ROhh04S9R
Lgc7v9NbEMXL1CwQG46kTDe+EBF+Yw1Y/UV+3cI2IoXqL/RwgdiIGaihvkz1RvRQQ7O/CNFqIgr9
ixDtBqKpH58BtHEjFIVGO6wHa9oTeXh38+MAsuHo7qcEyn9ODGISgbflvKIUqkhCOaHKanMI3rmK
96oEbMUzqGaLPXjDAu9VIWA3mjDpHrSLrXSv9qDp+2W7bLWdCkdeaQqiZe5DvDoOkcNqtwfxbRPx
VafOhs47IrnE+6GO92qHfw1ZFWQ3no2XmwXBY4cxbjdOsrKGfNR6tiAn7ikZeM4KylH4ss6/Dtcg
TjjO6gbc8qtT1JuUcN3WpGzhiFz9cRc1xqag2CVtqUOaPAQPBEkQwdef3bl1hv/OyXzpLPCIkO7g
rFpAKpPt+72Gri4h45ux5mhW/lPHI1HcwGqYs0CkL5CfFvKvoAvBA02PYil0lv1qzw/RpIZR1GKA
UdRiR2PA4PZWDlt/IQbbYugvlMPXSgxfOxgDXebiL9DULzE9f9gE8dM0kd3eFHrmaemZv2ufte8B
zXB34e2PFBhub4SwF0QIq0a4NEXtszVJ5vlOy9SwmI1ozD7Apl9Zisxg7Ov4hx3oH9biH2zutkj6
Qf7BZq3Ck1nGWzmQgQsj8Aq92UKvWLLN/sAlOrksCmyW3sFndfMJ5BMdfHY3n418s+P55sjXrh/D
s7MOPhfN4nXw6VW7HOB7hrcVNH3PcIusQOKH+Z5xo8KjSi1QakHbpeZ2G1/8gVjt9Dav0B+g5axD
S9U/xmFa6hqt8Khamhh7ZruWumFV+A6Q2mqXWsd9wALJPFBqm1V4VKkp+oa2R5Ru6518jAGf3sXH
O/k4Bz6ji8/o5DNxPLN9ZutqHqnzGcjXNZ7o5BM4nujiszr5LLSnpXXw2d18aBfLbOXjakao82Fh
Z7XPFa5Ga53PRT7/aD65NLavjMDXHWcO2nPWxdcdZ35Wr3Xw7YgzDxm51z4fuVaNmC9cd01em2Ev
X3e5GsvisPnN1bgSVTvMs5Kk1QqGaneh5l7aPtEMW6swHKQmb1NTHlEUSNZhasIKV+GpTHNU02yf
djv5cNqZvINPtPGheVrphV7V6QDr6NA+ZT9nbVayDcWx9kFWElRdIOzapJAdAzdavQucvJvTwDzD
2xMicBqdnJTKlEhpe9IAXrOT15DyGp2jihbObcPobhvGrgYJMKwdGO62yXI7G0bAsHfJgSt5Lodm
dWIIrRtjXjauzZ6igsEqGF/Y7AmLVz3z4mZPWKqFnMPi2KZahacajVzGcWvBDpyswvmFyd0Cy1bx
dtthdHOvzzVvR5K35K5pgTg7yB6WKfQKTz3KtlsKmqa3R4ita9VxD/Aobd3gsY08Xrf7XX0yjzYA
RVn9JjEgN/XygEeOUtkB24Rte2C2aUFS+eyH+PTf9kYcecQ2Q1NFIfFiEGt7B2zBtElmboQ3cG5x
Seh/yo4Z547r54xIOE9ezP24mR3Km1lEGbbOqJwfSgPJOznvfmqchwpBt+eod/dDgsfUn5wnKOTi
aEUm2/YanJ1n5T5JH8ux/5aF/d/wVkMy8+UNxg3jA6+AuZ+RFns9QYTBJu917diRUyCrT7ABIMWl
bBdg2/bcLkCGZ5h7JGzs1e0ExJvy9gA2Nu7caLP08HAdYNtA9X1qt+3k7ZKSN9XOPZvdalUj5hVi
hqPL7exi+O1W185B8Zy3irNjUNw5UojNxqDb2nzXoIbB6zjdgxpG1Xl2c9Cy9tk1qKxLd+OUldBO
HIvtwVHrol1IAjdWdiJtq6RdOJZmNXHqM7peMu0Lb8ui+0CbNdQuKe02bWtSNgqqHYDQyrY4tALY
Ul3tUZtreN9LFbQzNIG4mkqdlpAqypldmlBu13E6BzVMlFAuKtkNJdmD/32ZMXpanZDgUwOfgtCL
PvXlPStnvnqnSkl1fXldkoG5rK3lZlr15paSZXx3eXV5P/xB4csTvVY82XSmXKrfJLNLE+ru0cTL
b9Lv7dZkB1lD+k7aLgn5bglRfe8QW8+Mra2NQ219tLTG17Anisi30vJvJq35taTVt9Lq30JasX/W
/Ydj1QaT/rElBBvyP7yExh9eQvPrSIhThW5nDa3PGmHsy/5eM/vDpRqOzTTWpYlQNbGZyfZrAvU4
PcDWtjxQOMzWNscdpHYJrYqEBrMOkNDIht4noZmpe5CEAu+9aZfQrkgo7AOiwbayofdJaOPu6SES
Cun7VgnNSlZCQlPbJyFQUby3+4h4RZYOjx8Vr4DDcK+oa70SCmEeiXs0kSdUOzVhdQl4R2Qcq4lh
dNyjphaSD4P3+PYcfMsANcmJfLD/NVlGn07xMm5gbB/UAExTFFsdxYP2Syf1Q/c5f54zmhc7Jeog
eF+8yRUYQTtuJlMrQ1U00S6a6g8Lt1WOEg0HaYhmif2i8eNEo9vZcYRovC4a1bruzVXrv4fzYxxK
qfkC0YyGaLTrDka12HsYbkWz2kWzFEydseNFMxuiyQ2cPaKJh4utaHa7aLaCyS1+vGiiIZqhddx7
qyZPNdYOEM3UjxMtG6QhmrnbauIFyYMK67jkIVqTB76aaY9o/Gir2eUzKgeLxltEs8XOGWq/wKGM
avpRotmtDmWU7XOocaxDGTOOdqjRIhrrupVfrXmPS7mMa0c71GwRjev7Yk1URduf15jc6TxONNEi
mmF1PHKjVq9HxprQrGNFs1pEE133iqtl65GxZh25UGWD1EXTNZyh+55NLZ9MFgaFIH9PRmN5juPv
eDlK9raY4mUm5msC/QzlvPYyEwCU90jdD8fETxAiSB5BggNet2IDpGYLarAmpmnmmDOoFQ9410rn
q1sEvtFNSKw++aHEScqn9kDWE1XwXEg5rhyjAoUHCShW7IdRyzGVMHWm6wc8K6ww6HjyCk5wnzAG
gjkJVviCkiCRt+vHzmqe9Ho9EqRwqWQTunwXyVXs+5ILKeXRq3yZCjMN3Xgic/h2K5rIXtThbLwg
7W/f/oHsoZ8u8SGFJHKf/JScFHX/aZ0ZD0jf4IlTBnMCJY3NLduCLAjB0qen/bbXihTcv1xN+via
kifyYROlTkI8/Dk1e0aP1mkv8KsdryCBOM6dj+8Zk686qjk+B1oli1UYbLexE1AQ5hDV9caY50vQ
H2bhM4BOhjCNF36Ij92Sk1myOC22tsvXm0FBu4wcfGfSycr5dxQTZuiN4YMoe83AZgmsYRS1PV3R
SuuEaeAGaycFjx7K4/mOh2+mOpTenX9Qj4VPPH/ubJbFa3OgVNEF0/DE1g3yJETlWgytJD4Yim+F
jfIkpbBAQHxhSyVhDDxccJIkWITT8mnc6QpffXolj/WvJ/gWguKdNgqnyUFRmJ/RpxDiQ/0C70pb
OWt5x9TcCcpHh+W3wty+AM0nYzwOmfgxCvqgCtoHa/jQ/2w5LQ0rmkM5dZXTEMetT80eT8KYhvky
W1kCE22LrSwLD2q7bGVZ1l6NUdCmrWzKj6tjmq3jFuYlGmecLRpnX3RpnH27V2P+tTQ2/iwaG19L
Y/PPorH5tTQWfxaNxVfQuNmW/wc1/qKe/U8jN/+KcnNOsT1rys05tKadcnPOzeOqgWZLLWEMbDJe
JLf4P/autLmNHMn25/kViJ75IHlECkChLm44oilRamusgyOqbe9qOxjFS+KKItk8fPz7zQfUSbIo
Vonq6NhYha2z8BKVSCSQiUSm2LgboD+42/rt+4UtR2e937RNVeX67dlwyW3ot+fgonFevz0vdveX
NcY1jO+XlBNf5PDbF9v47VvF+e2t99u3y/Lbd+Bu39RvBz3L7bcvC89Lf63fNtfpeEr02+Y65ny9
3zaXMl+f2A5347omwcP0AYUNknDSr7wquLX6NK0MZNmRsS1tfizIOOaRTfSP2zC1IBn5VZ+zfzDF
dOqdI+33mD8GOhloJl1PgrseEKoJbQkITdp2Zr0aIzaRPRNaY6tPDMfTJRm8V0GX3m9CluTzZDlH
itLFgqy4/vNyZBL3EK3j7oiG4Fi3MJ/5Khry334dzhbLYBSnoZ0vdWqswXJEpv1wPF8EOisUAT5+
7a4hnH3tI7nmYzBGPtNQNuJW1fTjOPwk23wwm4wXK/HGUR/6yAREz2QDj5Pma7wdelxJ9tTpvche
NI+fjm6QbIzvepFcsPy+E7nmdbPGmq1jiZTBi9lkBCv1PryWUmu25MffkcMI92qO9CUZffUlHwWF
XILZHLPtMfjaZ/Xfvmi5jE82j+BwWTzC2QJ/S3cym/W7iyhDFdKosm/DxaPhQ3U8ofdLURM6gJGE
dVILOfXxpGEIbOmlp2z4cp+HyDenu2kkMhQFpJgmcUS4NUmEfizV1LHFBi7PFt1293ky385kT+kj
xehhPaSqhp/ZWoh4/BDh0fc8BeIjagC/q1EHg9nzHFnfiMPIs009XzwesR/WU7qB561TzRMkz+a4
0nU9YcOT8ztiyoIGJD0vPNtCOj544brLDjLtbnhT28I68KIbzl1tkeLAIpg/0aRczGOPj1h7euWd
5uEKEIZEdrU/iTgjuZAVLivCZULVlBUVbUr8Z87hKnbk2luOdYr4MP1x7OFDiuOUf0+QvlY6JjpU
d/U7djcLxvORvr1BSxOjadz/YXKGbVR18dsJm7aJcWaQsDCGw0/OTAERT+kiDvQR1dVgp62owERO
YQyA2rbw0zcu6M+0FnJMvBTXA3hmJ7gT0zbzgW9GSFI73jf1aXSS7c2jqUEDvdAXazCCsVcwvxvi
pW6IXbohXtsN+VI3ZILg2tJdR7BeQohXdUk7evul0ICgyLGGxtRpCItZwsHqfkjD0H6//9gdth+7
vcyjNXb2gTr7YTJfpFaJpKkUOOLKaYqbL7+1TvRtn4RLR+HOC6UY6A/j5XOHeioSTEdgz52D2et3
lg9G68tUEymic2vjxdaOWSRVBwssPdII5w7lxVSB2MCZNCL0Qk4n9BLjHMG/G17A6jjc4Txp75Cy
cXPbgymSxkHXeQBHNJNJHfGjSFULzhr9LpJHqxSowuHfct7Bf1zsyyRD/Ltg3cfJnJYjfRdI/5Ra
z6i5jWtYj8sOExXqStQT/ELf3Uo96eBgJfOkNHvMeI2IH3YtC1bnb+MhCl2wq+VoMaw0SQ71j2eV
i8ZZ+FKpJgrnMMMeLYP1+Xz5DMm1LNQ1CLU5JGM+7YfVn5oXN9h29uf/EZfuCHcKEIf5++/fI2jL
sXUdtoRH16EQhqOtX5RGrmeSfb4XPaeDH8Oco+9pnGQaDMH7uWDzBXbac9rvDmbvraMocel7eRRu
36+1cL8XCaLDERqRIIZNts8zaiaQ4zZpdhWMl2Q8oE7BrBZaFhsqJUbylwaCpZsApftZ2zgXaHRz
s7zFz/cyqktaG1WXtFYxi6mu3qrqimDWp1nvJdX1QtMiqiuRF9fahrlJdUVNXqm6eqnh2t4JXc7H
WlFddkp14TAC7oic9uVUl+XF9yPxXxZUXdTcdULVJbeqLnrSQ6hK5sk81aV8i/R0ulevUBYAc90t
YIWVBSG6Nk8j7qQsqJmOcUqalVQWAHJVGihHWaSkT/mui6ujZFH0sB8PrwIbTsZmBfwoMCv0ua+p
LAGlv3aajSddGyeFo2EnWASxcWCRvIUeiARUy7FeVdrhWXItsi1h8f1MBkkHRSLnT++RuubnyJMx
DVD7AxmOsdbgKV16iczBUf8hIIV00aozrGJaitLkMDrN8Hk8kPh0qBO8Wo37hvRI0UoiKsLoF10L
yyxyKTExGcTj2Yfb2VFhr1jWiCfaZRjDFZpNru1KBFya5V1smU30pMJhZ+ZJJ2c2kS3p4QrtYy8g
SbmzLMkdyeutI4ZyqI2L1kejIOLnHRnPPv0SL0w+j3tudvJJlcZy/XyszNzjydzjK3MvlGNZ1cUW
PQMoXztgsiotK95JyIIDhtbKwUVLo9TyB0w/6UEoM096GwdMVqlPlstTnSo9ABpLWU4+VuEBQF0w
vVvtdWBf15FQ80O9paRi/3kU/uK0cdz41Kjc3lylJYva+sJH7tzcqSniqSmrtF5I7K0ee6QuPjdO
6b/kZ/XbVoXzq0+fT/hm+bWQJ9XnrtY33HigxMAk03KPoF8chupvsBRU0kRxpIRGF8ImOjeacHUT
N2lix00cbsF41bPqOfhOu5E/ln1S/KZilC3kx+FJ9LArlEKMg37YkbYgdimPzWnYJ7M5O0C9YVey
q5ND9u0YuXsVNWan2HYcsdMPrfe0fArrWNr2sWPFoLQK2NG8NluUwWg5f0SdumhPknrWQ1SneZg+
CXyS+BTjedzxkClHM/ylN/K4q5AgJiUGyvvComHXXyuoeH1K3xzffjZDhFg35T2Fr5bC8iBSkaVy
mhKdGUuc6lY1qkhHbYSQ2DDrzmK8ufSFk2Ip4rNoboOnhoUIY7NXWEgoOlhbo7zAQjyLyW4epk/h
fsCuKlKpsG0uWjfMJ7kwZeTQZ8yrYXc2QWUw9q/JaNhfsEvsv6OaItTYFj4CZTc2vr29aLbhTKjH
j3s4a0QA22Aelk2PxNjGxsAsypPJdON5gF11falDyed/LIP544BoJEu3VTn91NKc8465on+HrPk4
HI2GU3aJKj7hVsZyq0jlgvimJWmRXuIZlHa0/TQP+iiQoSP7Qn9c85S1pv3gCS7PTd43o5cVxyLu
IutR1G7yjZqcmMOKg/Pzw83Nrag5Gf36VldoGq21vm9+vj3/PfW04/AcYqdXOcRU3BzGm9hMDK1B
7CQhZrlCxF37fIV6B3DQz9IDpZDU2HN0ujcsX5PFdLR8MEbeB7I5dH4Y/KArunyNynHw8J6wwrbf
4ujU/HHafSRhaC1o/YPXc6V5fL7QyMT1ASt8QVW1aZXDdT+zZFR0YXjaZi77OMNJBIiIVq0X2gwn
3cWoxlRV0E6xon/SAudWBK8I7zDeas5RArD3XOlhtvxCJt5jsKh2J88G3676Dm1oCX+AHSQasQPo
oKgvbtU//NtP/+c/aH8+mjy8LQ1YE47i+it9hF+V+SpcJSz1kxAufefYrkV/Fyhj8RPjb9st87GE
vmHsp9lkstj2XNB7/jO682d/nPc7LDxOUTWhWFxm1RyU0Hx7fiIBId0uvKoDpw+qVCKDFXvPjlGq
9Pjpef4Qae3q37KA9jqgXkZy6rKu1TCc9xd7RiwMZ4zqSC1sMK4PGv3OMEj+ZB2yg2/BqDf8paf/
gBI89KuHbjdGIe1VtcLFF1kUp2S+97U9exjD4RlZkerwEEYEaga2aF/5L/qL4NS0ZvnR8RcKiRd+
rdO3r8BbtEsotVQhkUI8dI9Nowpl2AOS9q8VxkOQgfFlpD9YJf6V9EyeE3aw1MfYh4VJnMH20D6F
Xq9tcqm1de6XAxRqP2LCQb3LQ8ajiHt4/og3ul51YWrg7nQwbuu1sEcT0MAXxsFq1zZHoBoLaciK
YqDAlay6KPFK1u2i+MT/c1nHWD+YjXADQJdtvNfpvnjFIQsMG++7sy93rAFr8KTVeh24YPcOrDFe
oS09bqObYJdIrl8HLqnnwjXosuNp9Oavd/WTy7PCwLqgd/P82iQrmpeYXyQEdZb+4DgPYHr76Ref
/xrPkhGYvowCvPBGUgm8a9RnH2lHUnir6TV4V5Ov+vIMyqKbBU+zD67FPll+DFWtC4PqwW2jKabi
PW4W6bmQGpkSL84Yr60MSkldcTPW78VwPrMIRnFx91JgRmLAvxqjmWyKROu4DDCRNBKx4FWgPMSM
k2y9BkxxFeIdscuL8xvWCRbdxxovLdgGVkoh9/nqMbCwfdvb1GNLlJ87Wb6+vsPpSbQ/3DBrZqvR
xOJ+zpWNRYRLxNhIVr+stz7Wi6/uBvWLidyxBRmZGtU+1ZE7BhUt6uyKXUCvQDP7cTwPNaDNYEmq
5/RFU/WEiRc6x7uoN6baiN9V2ETVPT9ppDiYohqplovru0tsQG1BFtwr3rVlYqPOPc1hVXyOhQE8
qDupuSaFRsI92Zn1xlxrRVzzaEdJVAVyA0NCri5Om79p/ObtzWnEtbXYrnJUdZFLTdXy9btaL8il
oao//NJjVa+fh+9qNTTVhpWmenN2pZ/YM9UPzbOQqqrr2WB5L87BaryRKD0bruq3IdUz/a4nfDPV
aFz1bIh+Kkv1Ugvxga79Ouzd8+9w4o2C6bAb/ohdwzi8WLwvEjJLQr4BCStLQr0BCZUl4eyHRPua
lESKDDbd+sCwj3quZEAv6Jfi97I0wmq5B/HghmeM90mO1d/Zw3zYRj3ce16CjqFATWss5A4MrPgC
9lF8qplQPNLRPmRlWGXf6vqu3bo9bd98umUHCKnRdXvbOALj7GE06QQj/YNkvcEI/0uzL5+Qnybk
mzHTwUulad3+m5u9SudHHK9W3PSNweQ+wfw9gEUBW1oiwwzlCMyidoWxUjnPD67qjbtDvcGDIyt7
RI4y2bTVxPfFX95cuQQhnEbE2fWNeaa9CwsWZaNlBw/BtMY6YXbbmjWwdVrk4tLQPLulhb2WJk+7
ej9MwAFHBY5jutMl6wWLoDD89W2b4FvIHXLExrM2AdGcJbNLFfepLYejBa1M2G6PhvMFbmcYy18n
fThizxNzE4ppRyneZDKmlfMOxh6LrT1kzy5M+6OJte/+9TyNGRcxsfrvxV+uedHYmFBDey2idCqC
xs/kfwmTahR2kuEoF97Q06ubFvvRDwgU3p/CQF/0VRZzHg258mXVJgsccbnTKPa+iLpQ3DiR9Ygg
6GVEE499+rX+T+bx79IuDBVdArvH6MbrdnmYx6/diiiP08CA/tiS1mclCc964pyiFC/gZtmSqSWb
qMc9YrZUZG6UJdeaDBbfglkfeSrvLk8iRtVYYSRWJ2WHCETjcXIUGfEPge5WcaxQZ2jHV40hcaX2
0cueA2uJVZJfOeZXJbobbnZMUIp0WWe4KN5TWm4qZB9EpT3mETs7k+W4i2uRg4Fxb+t6HzfsoPX5
4oYYXXykrsK7SraiD+/p2HEs25ZPLPgaDEdaRg6kdN2n6G5Tl+SIpFFw21FPsScM8in5k16Qjsy9
JxwDFO/OabNe0wsDm04mo3RkJy0ztPKJ0KUznfXjsjc7E7FpaBFsdkp/7czMytpDQeYwFs8EkM+n
/e5wgCtreofSr1YZyuhUlc1OJg+Tq4tmix2Mpv/zniapK33h7/6W1AGBTGCtfnc5w7J4jgjSb5PZ
UyaGtQCcLt7ZOtPHiDRDGuGNSWxMsBburnSBhcQ7p/HtZXbZuirbLQvXna9IWLdlhyqythKmzoy0
5fh1vPs0sxFtZr10mBt0u7ufDxOkg9rxWyCj8kZFIHFTVm8GL8n+NwsGFtiPR/hFI/WLIqg68sWg
ygiCBqMYBkrRGwwrwnCEUoVAfNyV0iDN6Dw2uat30aix3RUw0LwYLQbRAUhFkXyOrFawJYLRAttI
HJmQwM6/DRfdx9Bo+a2pdeHusL70nDiwSvdrFoYOmrN6S+7uSHe4tBAz/UIfjTlUoJMOqWFolLUt
bJGu5UDIwhD7FfwsajnBz2KUFPwMyKsFP4u2LvhF2O5xhP6dzBBNucCFcQXY3TVWhECNeHhpXG9f
cHe80ps8B8Px7gfBERgzDXHmuCZTu/uPIrT5NCCoSvGGzNiw+oBfMMmKI1CHxVtwZQ+vpF+okNDF
ryT/oq+kX4gV0VvxK1l/0VeyjOgVQrC8/evRNGpZPZrGKK1HUyB70KNptHU9WmTg/n/52tvyVXwC
j/uLNhx9NOGQu0VIGaZDLoz0YmaS3e0XQMo4CD8pY9odpjOjFEATKipToE9qs05vUjc4zmFRbUw2
7z88k91lTi/6OMWokOTs7kcjgjJObX49WYQG89XV6c31+cWvu5uZAHKiROTGuZHtumaL0H4N/QqB
ztpUAN/XhawNn89OScwnkydsZc5O4ZxGCMLuYMLUGzdgCCBl7ZvWxYG2tg/ZH8v+7AcbPownhcaO
QJMc6gh0bJlbrOa2XI3dTdhJn50PdXqqkx/spnpWvSrAYeG4SqXxwztz7JomxT7gPe5sgv8UXc3Y
AwXHT1M40flwTPf/y/Hgt571n/u7n1cQpC+zkBjMiOP1Z1z6peX5qv8QEPS4N6etZrdQl3VGlRX8
RrBAFJJ3LO1jyUUBVSZcnWouvLJj7iLPqV8aG0daLOhMqB3ZeCMIYwXnx798fejPqgYKYeFFyAkR
l5C4GLCf9XH0ZD58r0X9ZwYXFVJWLRY41QkvR48ni+Hgx3464AsZv69OEzGd6ZvVRT3sQPLi+Z/k
+Wlx1hKsZbGWvbu7jsBUUjXZaKvwPB36Kc4AGFdbLgBsx6U//hT9LXzHyxAMZv0AXsKYROTKhZbU
x6rPE2StM7moksLiO1OUnmtlC1RHq0WGbIVFVZt3h7aUIzKFf26RAs4UzmL39AtkmtKHsEWOXx3F
lZOTauk2PKy+0x7M+/9ut07aVRCqtpu3d78XoeHInAIa+TSaZ1/KEPJykq9sJaSKE3LtMm9kFyfk
JQnPChByShDKKw2zlZBbnJCvCgucJnRyK0VhakLwMvwLqZ3cWmVIuuU4GZEsLo5C5tUr25kkfSeL
07VKSWdCt/iEEFZJOY1IFp8aZCm+jrvFJ4mweU4NqR1JeiVIutarSPrFSebmytpCkjeLT0kUgNtM
6BLVZe4vrz/Wafm8uP33nFlMMZs5zMWtwHdCkDFNJJgosofaheBJmuC7mGI5grbgeWUBY4KnEcF3
0Su+gpzr5FTrisk1kvd791py1stvd7Zx/NL02LsCHhrb8pyXSJ7vmaRy8op5xSR/XSf5rjxbbUvl
TPmY4IdVgu9eI6W23pCb+7864QGi2JoIRmgZowX5vX2XHXQPWb0XPJNNTX8sTEBnIW6Om2ZPj+P8
whCrPqvxtJTPKukQM/m/kEALHp4ojqOMlbEOyhBvjDR1jH/vDrwKPg/YYBQ8IAK5gA2+Dp0dJs1Q
c6Z/xC4ac2S05gH3wq8WgrpxKFtcKCKS4i1YJCIWhWn8+j1dFbhivvUHe2HWCpHI2iMikbW3fyLU
fT95E996KyIyIWK91Zv0eUykz/dHBJLZxTddkijsKf5YDmdPbZNGr41ULrF8/ZN/58dEzu6+iuDL
M4b68/qZIt9ipsisMtHDsfKRDIsR8PKjs0JM+iAn/X0M/J/9HmZU5Z8kZXJHKZNlpAzuxISUtR8p
g/cvA2pGp/cc0L4iGogCzm0AOhsAU8NdSoocXV47B9YThOtZZYG9fGAXwG5ZYD8f2Adw5w2ABwAu
yWPJeS5wF2PXKwtsZQdvh0kicYulxCSROIuMSKk9TRKp7AxomjE6+aErSjJG+ZuAZ38wrySgrzKA
O3C6U5bTaTG098Rpi4sMaJrTDqa5U5LTlu1lgHdgjFeSMZZjJaScfTHGlxnQNGOESdlZkjG+lQss
ZQVZQMsCq1xgpQjYLg1s5wI76LFTcimw0kvXKrAN4NI9dnOBXfTYLQ3s5QJ7kAqPlwX284ExeJ5T
Dlil15hVYFjIXknNp9KaYxW4C+D+/oH1zrjkxpiA86d0AKnolAbOn9J9Y/iWBd4ypXtAVr2S+lnx
7Nx76427o1YU6htu3FVar7h7WhBUeoa62bEYGLuq3EjYaelx03sSUVKv2j7PIO7EalWK1TpGKiLl
7YnVtH/NgGbWBbDaKalltwJDyzqqLLC7CRhjWA7QtbJ83WEILW6FXzulhtK3UwLu72coXZHem/kr
Gkx7uZRdTsoJWuVD21jaVMllnqDtXGgh9EIvRMlliMCdXHBbs8Qu3293A3Ti7O0mzt7SjkUi4m0h
0k28l93yzl4i4m97E9gK4ZtwrzwRl+cTGcRu63VHWTEiMkPkrf2wrqey8vV2fljXS49SsCeV8b/s
XY1v2ziy/1eIvgM2BWKbpER9+CHAJU6D5HbT5uK03YegCGRLjnWxLa8kJ+399W+GkizJn6JkL4q7
7V2ztSP9hjOcGX4NZ2xGS6Blu9aly6i3RYSp4UvQx570WMJkZYK7++Lm44M2om6TyY8lYwkykoPD
9IllmFoJdNUc82MRSrWalmJrtNzyCorL6h212WJZ1Tg7Hu0mpUvwOFf1ri7gGdoyDE62s3RgupjV
OjJNql/B7zGh7kpx4QH2ZzBb1hRWRV1Eg7WCslitJq94kla4gAdHapJQgh8vBgcDT6vG5A1XRi7E
q8pelAkW7v+pHuJrmiyPHb5/6BEMMH9zXrykVk9fYYMfrCKdjKxU4JY+anM5YRVwLLyVltJKz+38
AO1a5snYckZcoKmYDBUoMpxm7qK46cC4EUWOUbd7eFw7PW5GEe9n76G4dpQ8DBYTV5btG3i1qGr7
JLvpbLkRn/q6ZFerRiuh6SU0ju2X0TAZA/nJaLNmY3R0mVCTZuMxYQHNWGt2vlXTqNlC6KuEGjRb
iLKO2uvNXq7PGjVbbhHsJrRcrTUjZPE9hIprt0akTDyg2kkqX8k1ImRRa53Qqn9eXdY19iSWxfZR
XV/nNeLT3iTQFT7XFn1NKOqUbVDLEsUNK8CmktUpXlAqU61vw4BWHr2dDaaVLZgaCYvp9iqh+s0W
BgpBTraSezt5WVDK2gqRoikSwSxYb/7MDd668nJRy1O6UrSEuf1wu8SBTrfy/h9QxWtKS8y7+w9X
Hx561wXgdH5Ds+yRrcJXyvehdkmTDZtK001zSimsMDZKswnOmgTrg22Tksp8fJOUsBPdg+jcQOQ6
Jw6mc4eXmML1w2PqFYpJzyWm/8QSU8gXcGyJabnEtJ9TYuYBRoL/fN9lg2r9JaUKuqT/JaUKUhJ/
SamClIyfRUrovlnuyZmyJzfFvhmquz5Dha9UCdmc8m3SNJWkaXODH0CatqaxQ+icLQPYDqRzto7n
qpulZKlJSdYXbi4lkXDXWEpG0mmHkZKJdwM3S8lWk5JpH8IybSvhrrGUbAwhOYiUTGmoG6VkqM0Y
EMmgjaUEMAxT8BzSfyHmFus7rP8CQhxPcbfN600VpNTxNJWmjG/dKU2uzKS+xUoPLk0htlyZLm4C
PZ5/w+KCWCqGGeRE1lbBGsFv7/FrPJRTSMAGRA0zO9/LCpFMnNibDX+kib+DUXZ+WGwF5lgyqm8O
AB2Tbbm6XNyTKTJnbmZOSassPGxUYg5boc6cZe5nTj8wcyx3ZQrM6crMMbotdUhx1+Px4qBqyZhR
gzmhzhzbljeguEHx2MuZszYzV70wJxDVOFdnzlBnTp577mHOfLzMmbM3M1e91DUQ1S1dnTlTnTlB
t6QGKQ7oRZs7BHOGpsZc0gp15ozdPWceYyhgpqU2FJj1hgIsr7mHOf3wPWcvU8tVZk6vw5xt7vSW
9jHUkjOqKTFn11NLzvg+tRQHV0vOhbJaijrM8W15o4o7HAcexLlOldXSqMOcru2zObPM3AHGOS4j
KdSYM+swJ6wtufaK+wSHtjmTWqrMWXWYM7fl/Cku7w9tc5bi9CtphTJzGkVvuS+jdPXc7qZg4C6+
kZs7GZro7SgmltSIy2p7GaeEG5zpumptL6Aob4E+9O6IFyENPxoDDxXql9lAk9omE7wGUcNIiQ5g
NVqheFn9Ymkm1lg2JbEuuV4SipbZWYHbkyLrKZuyYbIRarQwaAwZC71ZUCd20zQ0rmkV8pSrIGoY
Ow6qNHxBW/BHxJ9iOS4/ksmjQmc6itrtNvFj+Ko6rqnJyltXoedJWISSweOy+Bg3hCZeyAh+q8C9
mZSEchauH3fzSlWIP/PiCabtioLhixeTk2yHRaF/UnSM4D7DOM2EzgmsaGzdsi0YeMGquux9t1aN
rAz+y1W/i1W7XsgfiyB2IuLif5+Mtmgr9FoKdonv7ii4BS4jtRIsyytrSapaSEppGj1PZ34eTxSB
kMEjMk1Tb/XFBDoJnO4PaFa/B2792ZthPm5yMoie32cxRst6wrCunwQOVq08mTr/CkLChUJp9Yyo
HySVPRYTwJ4FQa2UZhvBnFnsD/25E4NmHwzU9RwXK5weDHA4+qMYO3/ieiNnMalcsA8WQ5rJKQal
D/10YGRypt0lF5iM+dV3vSAdOFUwwbSOvUcn6QgMZnOiyH+ePS3zeD9NA9cjV/IOyG0fy3ZktfBU
oA0dhA0OPXibgaUpvYnXi6fOXF4aHTl+9cTn8nXTyGsWe+QOQwD7XojCeiwKqwtd5lFaNWcoQlsU
V11VoTUlaGGqTS5rbFxKOoYwjtTjlokzlDo9blkY7l67xy3L2tstKKwaPW4zXW21VmPLNadzlG5J
oOt0S/Jm7W5JXt/bLfqf1i1qm8X/5d0i/rRuUdvm/i/vFuNP6xa1Dfr/8m4x/4xuqXG08J/dLcc9
ufhLdvUPRo4rO11nuP9bQ3a6znVaX3a6rhtqC7MaRxOSjsAtxuPIzmT1FmbwptlIdratvH+uevKB
dATD1cRRZGcJPOquIzvLwLz6tWVnWcu4q6MdrEg6tn0sm7VZXb2zWSO9szV1vVM9t5F0xNH0zjYw
rKmW7Axkvr7sbK48VqgeCwEdQWWdv2PITlCZCaqG7ATlvME4KwyKaptUtnCe588OTB3zrB+vtM1o
1WK6ORzMPX0Hvra4oB1mCEGzneG/3UM/JJUnWdum5G9EJ7Lo36k8DYzGTojd5ylVEswJr2fdkC1p
knUjBx+EbpdAZy8mXrqrrQzhz+aLuEtunSHIOIjGALeIPDJYxHEwI950MUlqCkJrO8MJaFpHvpH8
rBoGnJP7HRh+9cN44UzwWCwKoOXRQhZpHS0mkx/Qnih2ZOlPoDh+HaqT+PDqzeLWcOzM4LeZlS1h
qwbJJngY3z3z4lEYzOKV/DkZFx6WOYRnFBPp5PhrGuJbVOfkZeA2VxLEX8JliQDrXbve22Bn8f0w
Db77eNcld/0OJz0QexhM8MThMc1P2L3r81+/YQ1IzOF4KvMtyiSJDcg487nnhBF637EDL5x//l26
gGVk9SkeZMZjPMTEc8xhEIbeMM4KmQ7wxOLNj8eJqNuzACSk0hwmMzSAXwi6aW/9enGZtKAJn5Yu
MGZm6mMda8loYtupSQyD6RQMGzMUgWXIx1SwDcE2qEIYD5+G0yBqqAmWLgOSMzSpuXoXP5O1xE3L
h4Ag/FvBYVi6jddc8KUuyMAJpxGWegY1CGYeCGsWj0/JD+1FCdGy1ttd2+IsQTER68eA+BdXD9Bz
MeidkhOzhIa1yDFOYLgY+MN63SE0nKPtDRSoGtCVQxb6MXaiF3DScbQ8rFXR9RRuRfBROvlK804M
5Vkx9C+njLcob6XYWpcb5PNDj+Tn85VjMXLiWXTCYgZW5qZP5UEKzFALUWAw0dFlnqF0jD5/IA+h
M4smMgkfzCsJuHXvR1Jid+P4XF2ATGh2XoCy3798IBdXBr34wKxTEKalk5OQ4aPntzdE/un1H0j6
h8EsE7STJJfCWXXJMSEEs4tp7+B9mApT9LMF1XAwhibA9IpPifOqbuRlEndhgFONAMcTeSsgL/Fs
gR8DfY5lEkfUw+qBDdsZYfsYUemh7YywozPC9zFSNfQMSZiCm+sktH0kqs/6uc4sse+iiXPQYEBJ
VFZxVzswcJRXfZKO+Ea88dB/Gg/dElaXfLgGdq+DKC7MnhSwOcP41y3YmCPxc/9C5qbMe+o0XYBC
n+EvZovpAHitrtlcNxju8mwh6nqDxXMyG6quZIDJWXYDIQlpkgEwkf9vD7tBkwqNWZhSu8HG/9jU
O0okcRjYwoacvBmnGEeTJj0dGNSAR6oTMGB0MrcSwI7hoE1g8sjOaaIJMDzR02wCwii59IYw+lEF
dYPOwejkRTTAv5h1uFRs/n8YGY6DCCZ6MjGl/KQylQR8galPxwt4vgXMZLzgFzKhqgqUgQGNJSie
rOaXc6fqaKam4a7155kPc+QpuV1MYr91BxYtP35o3Vx+SAWrgqljgKTvwhz2PIoWU3QSmnZ7/e9s
joImFM1hmiBn5nc3n3CB70X/SwIgFMKL6VIDzSI6+/69Mm3NEDYrdeTH1JxTrZfCBgV1v3gzNwjP
mGsM8COMNe5iGJ+BtlU3QKSGqcW2Uoti3FeJuuR2FJ5ppySjwk/TzZqP0o+cVfcjmmFQvA2Uk0wx
GzpFwGWcFXFvndli5AzjRYgRw8lWFW8boIAt1gKYljN1Yb2WGaoSJdwpzykVRdGt55dAibcWh14C
uqXBkGsbB0NefQTOiKoNhq7yYJjRWfeJbuPBcA+2ymCoYDemtotorcEww2w4GLoqSrebDRwMubYy
GAqVwRCD3/DMZQuBIw2GmrVMII1/+aEHQ8A3jXQw5M0GQ4Cy8BJaCar2YKjbGsw+iowfc/BAaqa5
g9rhBw8gaQpaJHmYwQNw5S3OHPdYgwdSMvUipS2Dh4od67ZpYn7vjwFxce8kTWyfdHf1bSg8TcJt
KBmgHy0G6VxH/eoDQpkCI5Un/sCJneVekQamnZ6BKDRLOh05HXtKrw10s11d3Cl9Nw+Dgfc0daKX
M6yq9y47bJk7oTMFGwrlJA2fwvENt1En3rMDQ9xN/5zg/FCam1J7UAnvUkBEyI++oJW03a7OHdbA
zKZgrMWSEWvsP4/T+WXBnhbySGPpS7FiguO6oRdFCsMM9Is8Bl/SO6xvNIXJMQdBMrtnTXwjQOkY
z12CMur6RktQC7O1j10HbO5B0zg1OD3vn5Lzh3NyedP/NRlyqgMafOlspSD3+FqLWmbZ1/LqQxoS
M+3txEquluaulq642qo+hbcZZQK3NZEiP7pe8jbXtOVShB9aLxFeNzDZdTLQNtBLCWWh/ZegrHp6
ydvAtmbSAt/HUyNJTNeM7cQOr0aGZnC5ceAOcG/8/O6G+NfnfZ3r5P9O0y96l53LL5et+0+3SiYI
4Dazqb3DE7Pqnpi3YSbGcQU5dmF8+XrZg7+cfji/77covf3y9YLWdBVa2xCaTU05gtHksJCNktKy
5imOWAYBDZdbT1W7EjF1qusSk6WYsmIyMyWmmWNWTeELmAbVcF9Z+sip8x1WTH8sPJhS4RpEXi38
1b+ojGYyXcd7PxLN4IJBp+sWicA+gjAiJ+CB8WLt7cV78tZhsBDRAZ30cOVzSnrX/TOYHDOtw4Xo
GFXXtEAV5lci8/PJMmo0WURjmA4t100qYBama0jQ4AfDHxx/VG+RRQ0Lq/xJvWosVYuaOhaWKxiU
bv1OMgOS/23dn9+CVbXuO/dfE1XFu9m69ZKKV4WYhdab7a71ClYakjwmR2vzqi4BQBnjuH8i5YGG
QbnNjIJi4E1cGAxQMxJFwGvXQlURgIzMqSPJNFUEBMPhI0GDH1XXLKKtw1QDd/Ru+p+IDRZGPnyP
vRnKDf2sPwyDKBjF5B/BxPdi8htu6JCqXAK6YDYm+tiIfn9/c/eE5x3n1fEsDCPGC9ejCFfdFmY6
q/62rSXT/iCY14t5Em3T5jItUfTHwonGI2AjXz1ord6XvlQQq0N1+P97cjf2JxN/Tn4LFs/jqks+
zWxjjTi8h7qAoc/ND7O5yHYjKiLZbQxU0fID4Lse6c895wVDCTYd91acEukUFxom1r7MgIM3wLxI
Yr5Orq7eb8avqDuAb1BDZhBN9xzX4B/vvt5fVbz0kcAZBt3S3N7tluZWVC7Ex41Xtrm5CI/NvVBo
rmYytuT+6+0NLvrncwBVUVgAsk3LkKWscf4bxPPJ4jnZwb0O4qS2HX7oBaGXqRks86sm1tdxN0yj
yHc0ng/HYFb9GGbYGE2wgr+Mwros3aZHYlWFrLcFTJMxi28yIWxNpUS6ZOFhvF5uitCqdlVF2wrq
B8MYHtLbTGvTlvwkbdtsMdpi1vvlzkPkuV3iTlsuOse/h547duL2MJhWbIBo24ZtYnnOEe4XICo5
wYEz48Zs2xUP33WrjUVj8fR1b5xNxRExgTRxU2gSyDwRMpoNJrX+K25S5A69Ip4tb0LjflC/91Ax
yUmSXaVSjpMw+hFNgmfokccg9J/9GcHx680JvbN32e/ekejtSyLcs3dam1lt4x353pr7LnzUTBs/
+LNRcPZuHMfzbqfz9vbWTl/Gjn2HMUfSD6+0w9rMsxBthqWuYDl+f9crdcvCnZMYA3LkdnwyJK2u
CdRR4+F+VHsrKkyGKcbx3CTxrrh0eZmNIuiTYTD/AUIdg4L23hMYumEa/+KHf58GM8dtR2+Dtuu9
VyBkco4heh+v+pdZxcPOqxN2Jv6gAxQ7r3roDfHM8gd6Z4wRhEdf9SQihSx/5/qhnJythqbvpKzj
pl1CWXYlErdpC6Z5AajZc4hrtDnGU664Wm5uRjW0thBCx4CBJD0vGUGz3lIBbouY24lmWrjgi6fz
QZrv9zIM5nOEA+u+uXq6evp89Qnm6TNo6ixYfnn99anX/3xLRp6DG8Tt7RThHxHIDf1XL0u3I78g
ayvTaq+BccwnXryL5gqXFkxOZNGtRTT3ZoAoXTnJQq/5Sgo0XujTi99+hQVG7+H+t0fNhJlClwwm
L7EzH8Yh4L/iIEBV3k4uOySrB2hf6LyliYdOHD94/+0wUNGP2bAR1usUnVkG9zp1Xxo2bepi7p8U
Dz42gvtjGLwRCXiC/1TDkmXNZr/EYDmImWz6pKefuEf+S9K/9BcV0M/y0gUeCUszL+hIGUUr6Ghn
EYWdCMabDqx/Zo+yEF0XfN79p4/vyc1HMLoTGCxGPuCOXHJGVrP/7MbiOVb/4fz+4fMdOQH2XsCX
1sVJ2nS/mM3QFmEOIuPJ/xUMymF7ogvD6BIRRrNn7LSOFw878G0nGob+PAa3649amcsJZvKY9/cP
Hy8+95/uzh+uzwbO8AVMFR/rsA6tQWCAMbRdWbx5I/DABWDBTKatgJuKrf8a+nFSqLjU5E46EW55
YQh61VuW05OKl7yc6Z8Xj+nW93EgWkQkgQEVyzxju2G797ZoBd+qgI/Hglm7hxPPmS1gtr5R/C9S
/selMRrUJJHqzlrP5jrTmeHVtQ5Iq4MrfbarY6pQLJnDaKRoDwcVW3rd6Xiim49/RP7QmbRSXTO7
jcVXgeqKOQGXM3lMcdCe2+3IeBOJ7nJkfKMjU239z+LIVNt9DEeWCj30pjD9VxxADiF33lDu/Ehy
r+58G4mnOpna/vDnGgrruQZln97IA23yrvw4w6HSGH80pv7cgYr/mQPVnilGI5HucZrHG6x+Vqf5
87iaRuJXcsorGmR1dbZxf0bjtM0xQIItYzLaVhJqM4FlvkqkjbZCkG8lqBmaJvQSQeVYmz0EhLyf
VCCwJ6iF6gOtGNSiMTpUI6fvIrctrGU1EHW10/bQNEo0l5GoSPjTPEbfSW7xLndlVCGElYa3rl2g
Rp3IY1vSE/ix7wKL1fENzcYL4ekJ3VpDN5/Qicr4BsOSMin+KTQudN7SMKvrm0vcMGQspfS4Rvwb
BqwA561iCCyKVom8ZSuIDx6ERirh20n3wGtd8srbRjdjDimuXzQSWmm/pgBoMLOtc4uZWq5FZs0o
O70yRYEp+mmJoqrt7yPAmc1KBPbavkWLtu9QaqiRE7vIlWyfbbd9TY2mUaKZR6F/BxWD12QLtNLu
eAVQqwRaDkF/CKKxP3DUAO0SYDnSnFOGfzTdsNkq85tPExDWhOcxT/RNMRM/MnsLXoP0YZKAu9xp
lpXSEUc13GgY+ZR0kxj0PLENbk6vU0nC3KvT0EHEXIqkFSUY3ZJWYhzdqi0pwr05ycwMG5xC48a4
F8cTjwy8EXqJaOjIbeQ6lCo7tqxJykTWxJxGSxWIrnTrFpdpcN42DcMUbLPIUQzL86zKiLZhyVgC
VBQC44T8H7mUB5Stc5mjCOOIyMOn/vXNxTlZM0m8YsHI3T+7hJLzj/2bLjEqEtfajHOOZ2mXWZoo
9xfoAM/FjCSuIzu+VbyaMFhET1hcgkxhchu4kQohge4gcnMeHyPX+UbA3WmCCwyYE4y3sLYDGTuh
K8+sliF0WE2RU4EhdAo0dR1j3NZp4nLDQyeHsc14Cy34f/au/DmNZEnPn1Ix+36QvQLV2QcbjngI
JFtrI/GExjP7FBOKFjSIJ6AZDh/7129mVV9IILqa1uzshgnbsoD+vqqsqqysIzM3MoGWhe3gsrkH
SwvoE0JAu+g/XgXIqdOuHg/m9h+MTV0NjLuwHj1UwPKjKf6XmgJoggb+w/AfXvx5Bebv1lHVjIP+
mHkHj1fzoPBnx0TruzrJD17/urw57yX6l9dZnfvk9nwSoOlxffIr6Vy1f/l09nu9MK6HLx7jfokm
62mYuwnJMiCFxrLYeoeFYaQrqSTFW91FgFhDbF2pMuo7eG0lWZ4kJoU2tMbLeJvmeItFakC3l45R
ATaw0IknYs+WellPE1GYUQmmcr40dWtfk/0EwkFXI5yiWElbZj+H9MSOiTW1ZWxksgWulC1TVDg5
6e9bINwPgg2PF6a8CunsFwglOPObAxyWta3rXw+B21wavDdOkYcAPl0aUIdKJqjPTarxTWgpdkB7
deU4dJeJvd3e24voChe9J7S9x3bbe7EQanEEkBZekDUvvEG7Ye9R0mr1nhRA7iiAX2ceLEyknjTY
5qThetxXVL40+UtK/Y2ZvwCbdml6zvbizF8ElqltsPmZn6Yz/9MW34PsbkO2mfn3svjwg/5pjeBj
0r/qG2En7MGNsBO54kbQLJn5ZfWo420t4IblpU9P9HUybYP99OP1l39NQQODml++JgfOQY6k+ie8
4p/S/GTM5Ur9BD+YKx2YL+Bz3NniPxH6moVKXmu89kjIT4soWr30vWAw/TOK82e/Nm+Eb1EB4+nj
JBoR4waAsYpGZBmtF2ARvCMn80XUP3mcLkeJ21VRf11aN53gyVZkfwQ6bR5HryD9+RrM1YoRreFM
9JBkybUlishRO7wfB9lH4g05+hpMBuO/D/QH9WgxgrdG/X6KImHhJmIHPZj9juZgCYZ64+lNCoff
4TUu37zBJU2v0yU9WBT8J3zCKDzaEH4SURVwiieLTqrViqZTXIHhWXpDx1d+p78OIl/MgmmofwMQ
AmuplX4jRVzP0DNE+xguoiTE+LvV6jtFB9k7vEXxjqviKZ6TIp1eXPVq0KUwM+WAJDcYCLrDToN5
wxoPI6GbmCz5F6mlb3HPM28drbXbTvEkpQkF1nc+nN1ppyi86swcBQt/axz0arozYWw11ub+cjGM
ducC+qBLoDPB6ndlPxQJCYPFBFOiLtHMvuX6/ZojmLYRb85+uyFtdKI/7fUOA2fk1kEHclrjoPeH
w6GJWp+0/WHgHEoOk4pG5/eeRu++v2mefjqzBv4nRqnunl+SRTCDWbJEH4RmaZL8i2KoN6KdD337
MaLxBE/AdIZgxIvzaZfAu4wWUxhlJMU4CK8TG4D/jYIzHgUoPtyECMFSJHjZyhpUN+4dPoqD4xYz
SvdX+P2sZUpUHH5rPGmUkqPXOKFe99pdVC3nVCqKEZ05RnTmpPmp2fvYtNctBvU3EydawQLK1aiq
peNEG1R8okk65AJbDPu8n0aPhgeYRdrlTdZz+KFZPWaiU59jXeQrs7bTujIFrO75aTsnwRxr0mgX
lzefcPpTYDC6B9S1ZyJxn3tawrJoNISnSM3uRctIjTON5HIov3hlqfUSqXkwnwEro9z0kM5Fq/uL
xu9eX7USqZWMJP6UtdM6f29Yha/rKvb0S8OqX37ptmo2z+O6irZmbYs869VZR3+jYtYP3bOYVTb1
aBDe3jFYT1V06dHQaV7HrGe6rqd0O2vSrno0JL+VZf2kO/FR0J+P78aDW/oNT0cmwXzcj39FfWwS
9VRHwTcp+CtQiE0K+QoUcpPCqYbi7hKURI4GzRl9vhLi7Usw31fwJvu9LMfFlalH2rjxkQwyhf34
q6Pl+O4eVie3tASPYYBHGySWDoHunCyFaHbslDEe6xC5YL8VDaXyrFaXN3e969bd1edrcoRBYqk+
zceISpSMJtF9MNG/cDIYTvBvafHtJvLzRL5pMx3x154rie6rmwoWtPoXc7PXGsv4kWPpyVGn2b55
o40zXF9unqOhhz9Yhvh/e9mYpLRIhNEtoHX1lsEycyWHpaxpalx9jWB1R+6HZjHWEEPF8DN7MXXP
rmHGa+Tp8R4VJ7i1jLu96LGOmwBkEKwCa/jT9XiyAj2Ltu1kvFxhniKzQogWg3BxTKaRSQFH9KYD
0kczmAduohUY2HPcZoOlD8ZUszcwPuq3dUKhv9iqfWO7BcT/b/aV6160MZdRHOcCtOZqMUZZ6dXN
kRYuCI4fE8FdxzOtad87dCgO3Floda565DssKvRZmX1xf9MZl0wMqgaUyed1pRyCAebnSc4Qm9W3
pGZDRrcIHmdPYLSQz++b/048+o0XjQCXQSVZ326xdX+3zKu3BebhS7/GyuO0sUG/x1G8trUzHkyg
qRy3NJhYyVLUuqll3CdhrVjbTWgCpiR87jFRXILxXJauF4dQgamO3Hw6TQTVINZIpAkaCg+GzcrU
kWQajgJdLHusWGfoBXKDDOGl97v4wEHbn9SytxzzVonixlO3CYbHXXI/LhyLN4OBOaIG1m4S4ySJ
SAP6bY2xO+7Xw2G4SO4ygIyPer9eXIGg7VuqE2eKUhJe3uOJ4wil+CMJvgTjie4jR5y77mP8PAyB
QXiMh2DKkY84j4WLLxjqHNZY9FHPIscm6xRu4BUvjgKpowNCCz69X5iZahBOgu/xHRkTvX85D/vj
IeYT0zN+WK9Dx/WculTkNBpFnYtujxxN5v96B+PH5T4rGgbJFIC5Cg2L/nqBM9Y5Blv+ilEW7ANG
azguXIA707vl0HnTQEgw0eM0VVwfIhZefW6lGVXJp16nbLEEZljtQD9avaAObKY9wJR4Rf6FU4ai
sZ4MmlJPL2Q/O7MI+v3ixyAA6eBlgRcgn1+93g+J6Ry1cfUJFprJSbTgH4/xjXbuDRtUfRfYoPIE
AhrDDsNhCYZIMBwmpRWIj1mFNEg3OXbI0n9dtBukuG5ENC9FS0F0BDlbJJ9KGAlomwcTfQ8adz2h
wy6/jlf9h3gR8EtXq6nisD73nDR0ni7XIo4Fao6kBC8aHxPDBnKBt5H2lNEsLywK6YDCRo3yzLq0
KdoOiKJhrTOIajv+Jmq5jr+JUbLjb4Ac3PE30Z53fBuxexRv+p7qGy4rTBgqEba4xkoQlvNgRmit
+DYCPojhQKtu8Txq2RbPY5Ru8RxIBS2eR3ve4jZi/zHQKhtoNirSDJNZuLrD3QIYLpjImHEuid2i
I0HaG1ezuKWFkDyNGIt7a9oZZ94f2yfY1WgMQyPrBE368GJzu4sCBTr+hMmu1DIcTTHUnt7QC3Fj
rwY9p/hiHK/SovGpCc3CZpNR14bpNY1mDvR12OL4zHF4ug+JdyfI3VXv4khb4G/IH2sM/TgezSIr
KQEo3gBOTiAuSM+kkTG3udGRkZyG5Hys08effidX9bN6p7hxD/iulHn8+G41uYTuVwW8R51t8J+T
cLoVMDh+nuFU5wY2xf+n4+E20yKchkXDbmtIn29CYmMmEm9O8WY0TGOdcBQA9GywBJOmb1VknTT1
CX47WOF9Ve+EqxP0JrXAc6lK+0jX+MstoVwaG7eNSXCPUTTA7ptgZ6zh4cXfv4zCRd1A4Y0oGzqG
65l4v31IftZnIdFy/E539Z8JLlsxEfpqhZuwsQPfLFqNh9+rKYAPCjEtAHprzhc6MZHthhgieSJB
ytIJ9yjpMdITpKeKL+EBTIq02xgFEx/moEoZpwkI4/MCG2CFmxN/nqZkvuNtEAaLMMCdg5Qi2XnB
HXd9dDGNVg/hwuTlTo8XijNyzxVqQzd3Oq2ry/OL9xu0NRIOzas4tJAOS1Mv4+nHNcaajGPe3sIb
mBJbH3TYHHE40qXZKNjMMAnD4JHcfrr82ATki+t/LIkAe1kRh7h4V/AtYzCjAwVhNt2rCOFpnvBt
yliOUDHqu3sIWwnh26SKB9C5DttD187q9/ZQOrG/dmdb2y/PR95amIkKA4nvoTyvmFLq7A8vUr5/
Tvm2vFiVkGIP4YenhG8P6aVK6ypzK1jH78fzuC7u3fZiV/svmFWAHPXfkOYgmIK5AR9aE8xnc6jQ
rGvUHe5+WkM8NZxn81KGs/IVBh3ZKFAjdlMEAdpuJgKeI9LpVNduo4jrWblC6qSh8Dleo22kmz5L
E2hrMolg5ooDW1ij2kRuGNpJwgr+YX1fGXjs1pcV3Bo5N3nqVtSHM9f/sLc3XJdlhsz1TYugtfs1
eAyNB2/PwpT2BcXUCXHuS5xjGWaqwAS4+hhM3zEZaLfImvmvD5M7HgqA/aiPdY2dYcPIMCH2S4yJ
OQGMiTlxGCNHc3RPHf2sjr44nFF7RL/MyDNGoevYT+PF3YelWMU+yQ7DkKasIT1cshLPAXKMHBlN
/JSYkvvIxv1DiXBFliNynhHJARLJATuMSKnNlvOfE2n5SSUOI9KbES8TKQ+J3ANFpzcoXiRizNPJ
9NihreTq1AsvUSktPHVonTzMdfaU6KnW6mdaq5rx5XlsH2s/G1/9CjSXv02gT+pJvbSe1DuUUVK2
pVtuMA5T7TxMtPOhkpXU25yFgi2DQepR5x5UPTD0RDwTn8ZROuOlJWjLwjmoMySC1yu+jmeD6GtD
L4NrodXiN4XpnHVSHBCsl8n4nlouqFPM7vXZ+dlN60MOOJ5ZaXKXsJZ7y3rl/pI0Wf9QaQ7iGxEW
5udWaR6C80yC5cF2ScnGWNsmJWzEQSV97l5lfU5V1ueql5jFRtlr9isUk8wkJv/CErM4Q3ptiYlM
YuKvKTG3gpng/7/u8qFr/ZBSgb4kf0ipgJTUDykVkJLzV5ESqm+WaXJmrcldtc9CHTy3UOEtWyKf
U75Lmq6VNH3u8Aqk6QsMPHd4n4OloVNZn/Ml3m/cLiXPTko6xfLhUlKmdgdLyTGNVo2UXDyq2S4l
305Krl/FyPQ9U7uDpeRztyIpuXqgbpWSY2cxIJJDD5YSwDC8LFKl/kLMHaOvWv0FRNxlu+161wYp
VjyHSlP47h5pcutKyh2jtHJpKrXjBDu/CXTb/B2jW6BHLXPIkXZBxUBOX9/g23hiY3EpD0hdtuOE
N79Xkid1t5Natbbn7ieVFZMyKnZcgMiv3m9PKxUvY7uuCeQXwLetjNTbTlo8jAmQ6pOWPaTubTsj
9beTFo9DhbdLqPcSqVGw+TatgtR5uabuawwZjKKyh1RWX1PffbH3+q8hXs74PvGqysXLuUf3kDqV
ayQuxb42dTdJKxinXGWXc3eQetW3qbvrSk/eXKy4TQXF3rvvNnlxlxJXYVKG38lFV99PCF/wRjZO
5olzsHNMYKXEpLR1DgZGgcltblpdEi6RY7zESKkFHKB94KS+yxQvQeo4Mek9Jmnb7/1c3tsaY+ej
pQ1kDfIhJVqm90Whtkf5qsfV1AXThbDjwiNzrNginEVlbjK5juBCFPBRsEEU6AADXan/iBdhxsM4
U/x4qe9sLYLpcFmv18kY4w0Xx3WF9g8+X4ShhkWoAZnG3svcUUI9kiF8alF71ziuBuvBeNXI/GkR
fxauJnhbbhn1H8MVOUosaYv2idHxGtc7vAlieI6Y4L70fA/UPoyqBnvTKOXJm8B/Pu9h+PDlI/lj
Ha2CJRngzzunruoWrRaDtfHZF9yCQWXEowSj1OhgFLYjJGaaLkfT2Tg76V2CkFcRjAdhX+pTzFRJ
JsF3KJaOujwysdPJ0f1y9Ca50JWG16lLUMIBhr04mgb/ihaEK4tIYwnpOCJLjPO8ngD2LIpK3STc
ChbMVuP+eB6soGdXBjoIg4FOEloVYH/4R/4C3dEgHAbrSWGPfzAphavQlzdYLsej2V16O/9uisHD
z/Vlyk4P3d4Sr3cbaEdCgUEpRl9ng40MdvufRFf7aTAnGKRoGIyLuzPg456jnFeqk+fiPFamTp6H
l7hK18ln8rXqZKDL1Mk8+aNOP+r0o04/6vR/rE5SMly2lqiTlFzS8nWSUuEK7HXq5LJycy486R5S
J7BK5SvVyVMYuKRMnTwHvXBK18nz/dfqez4r204+O6idfPVq7eQ76C9Rqk4O5qUsWydFtePva9RJ
UYa+aiXqpCjnB+g95VA3zfIQjOYjDFmeed58oXVGi8axyOBMRq4G8biiJ8xRiiYLs79dx7F2GvB1
n5K/EUm0F/Cx3iRbPgQ60llo5VqcEd8vBg0C7QGrlnjdZw0R5xfvBH0QQwTL4mlksqGuVrCgzDLh
bU03XvRANKP7DdbDX8aL1TqYpBEHl2sdC2G4nky+Q3mWq0C76wPjw5e+PcXZlxDjfz0EM/g08XxK
YYseFxo8POmehavhIpqtnriZJbUI0TUZvmPpb5bhdy+7DdLtnXAMCrlaRBNcgt7Cu1RQ0ej2+Mff
0U2ZfnPoMfwjdccvupOwjQazVwSLJe5JPATwQPOX33SnTI9Uj3Fna/WAu1q4sdWPFpjBLfG1xwBv
5Ot49UDGHuasnEXz2dymOEy7P8CYiRoGgnw8bZsSHFJPTyqMBjEdY1ATXVHTleMegMFU44yO0BH0
12ywPVTCi1X/rj+NlvqWv2zg7+SZv136JejA8H+LDuxJHy+g4EMNKGSwmGKyYmwnDDsLpV89HJPv
4tECUVEfhsRlRMan5zcgCsyFZjUIPCUw0gvuxPbX9xie0HaTxYDg9Lh3K7bokUwGmZP7Klg+wiBf
LdPtMJvOE8M9aeBlHIo5du7o6904aA9OGa9RXouxRZKcJ9sBLbzbnZEn+7/rGXTbQfytbBsYA0/a
bAIzmMuk9LxUxzdvyM0imC1Bo2MON1BZHJ74bsIqbNXvxQXIFCwpUi/kOEmBQ0/PTEIJT+pg9vBK
kiCQVi8J1V82SQGyKsX8vHcxPO82KEXFlesaAZ5SRBMQ7p3RBsUH5SZFFn/ptquvCmVhPTydo2+F
W+s6QZbF1vHuirB9FbFpod0VYa9eEb6vIkUP95DCVdx9TiH2URQ37DisYdW+KyhBpcegmtTHBWya
MjnP1CBnH6AYH6LlKmcmWGBzhifYO7BncZpddM3PJHgc2/4gS/xgpjPOWihVLh2GC8UdpIPwfj0y
037xxgdMjrpyB6Y2GZxj3M5Hrz+80OVQhxYOdgwEDqhwdycBSonXaZIB79g0C6atPU5sfkZJO+xj
cM2i3lGaVao4zS/8tU5zXQBfYRiGhzV8vwaVSeqCb+jgDjZQDp6rbkBxs6pJDYziaK4QGGHrl9kY
ExDEGYG7MEXpX89qF+2zWLA2mBLPaccDMMzSpKpCYMj2eCLH/mwylqM92L24wlVUuPwPEgHRAh6M
DVzso8t3374V5haO0unTsobckzGbDZz7jYzZlBYfDciGvqc72TYSZovdCbOLD2rhOFT5eco0X/ZB
GgpwGWd53M3E2WbJviUhYzJQrZhw5ytj2syonR/wFqC+I1684AaAg40Zg4utM0bhLCgZ6XNdNTh4
xtiDbTNjWPRnV7xEWmrG2IOp88KIJzOGspkx8AgSNzR3ELzSjCG8NOIL/uVVzxiA7zrxjMEPmzEA
ysOLghtQpWcM6QuYovMVf00Ni2yu+wJb9RoWKF1F85TVaFjA1TdTM9zX0rDI5Mo80w4NO7DQsNJ3
XYz2cxmRAa7C40hUprmLb2jg1jNuaOjLNCZCPhoE9teUAEorCm1n3MXXchrJJhluPP08X0T3mMRy
+fiOfhPDn5Ot2nmA+RcwpiRaH/gtnSRpMiGTcBT0v5OLXpOg4aOHSOHyOFyqxBpgNWaUtE5EZUyd
XK81iSdSjYVBzZK8XMXHhqscfZKT8lWrgVzlcrwdbwxNdogGAiiJd1c2oJyyGshT1MMISQ+DAHr2
jRCcOpw2e8cE0+W2L3ofjWIvDujwVKVpQe7RaB713E2NxotPHEjm+rvJNhQazRQafaLQio5cXtcJ
Pj3DyF+9X/I6FyK1innV/RLhpYOhdMx0dkC/1FAeqvoNKK9cv+R1qLZwaa7er9eNNJkUzm6y6rsR
plLTa9jBPe5lNjFQ4odmT3JJ/us4fqPVPml/bteurzpWQ5DXwULhuPx4GIAO/7Xdgr+cnjWvezVK
O59/PaUlB7fAwJw+dfUsQc35BhvqeFVD9xhnBYdg+j3ctygqfMSUFANrAyaLMV2N6WpMN8MsGm4E
MB0qcOdOa7Vp8A3M+j/WIZgaJtuTYvzj+LQwmsukdL0YzeGKQTNJjyyhR0eLJTnCfOAuJ53TN+Tr
CQMDXQI6aeHt3GPS+tB7B0YjEydcqROn6IIIWMHuUIlmNld9/4e9J2tu3GZynv0rsM5D7MSkAN7U
rlORZXnG+/layzOT1FRKRfGwuNYVkfKR2t+8L/sHthvgTUqWPEeOMpOaGRF9ACDQ6G400MF4GY0w
F6Fwb248nTgxSwcNW1CDPxj+oeAfm9fIooal0mRcfXavWtTUDKM0BTTrF5IOef63dN05h3kgXbeu
P4qhiucLNOsu6d5tmFk431LXTLcwrxYk39hW5Y0zHAJRxhQ0vnl/4MSgis2MwsDAaHIQ3zgyxEDA
owP6tgMB2PDzZpzN5w4EJIYCX1CDPzbV5XVZszCqCcPwg0ik2zE3nuY66tE6niLGbI0v2+fXZdNW
+CW90e9LJxoFIJDT3TFVVqXuhz7vcqtFNfh/n1yNwvE4nJMzzMWyqXGhmsAGvitqFSD+vXwDTtFT
u3dDSraMu9Vqvml11SX9ue/cYfB40xbVhmqBRlFdNw0tJzx7AJpHIs5h7+Rkv5n+hmNOwxQQBr8/
IHEB1ch/uvp4ffLbNuQMg66obvd8RXU3HFxIH/1grLm6SB6re7RFdVWTsaz1H8/xcncMNFhsNWA1
vEzZMnBDao464Cyej5e3wqH2bhaLK5jxB09/cp+meaCbXqulod9FpdjuaDR3RzCt+jFombgDWqGf
hWIcl85YILNNO1mTdVAV8Q4PoRRJE94jbbL0MUYln4pQK3nTgbaSaDhzYwDSZKbKVOK/+Nw2JUYl
Zu1nNm6EySq9ieSh8/Hnhe+NnFh2Z5MNK6DLtgG2OFQgQCsXqZI9XIrS1pjyprkJNQsUBVCQ2Aax
ARuuMYKkie6H8aydZya8gq+IpjXPC4vV3NCu1mx+8gE9D/3uzYZH38SZu41Ovi2ip2g8u4Uv8mm2
CG/DaZYQ83A3Ldsl0UOS0uRwV5WZJRu75FGahx78VE0bf2AmjsPdURzP263Ww8ODnCDjh93FOAku
hyv1sJrbrOsyw8tkwSS9vuqWPsvSm5MYgwi4F1YsSVXny/ZUY/d5qvZKqqBeUow9OBUxXmhB3k2D
CL6JO5s/QaeOYIB29wmzbVCM78LFz5PZ1PHk6GEoe/7+FoxMRcEwoIuT/nF6GXbr3lm0xuGwBRxb
99rCd3EL6QmlcwxaB4Dea2IXnWRlXrjg6k41YnItZw1dTYJzllfbphIoTjMYZrcLjF+cY1BVRdQq
ZjNVQ5V1XdfweockXUUA1XpIOnBVlM8aahYs2/zC1yWY9VMY0FzIkTQQTykdfbbaGmukBIaBrKCh
xzLbUraEy2A8e9jKY6BWGCorGaqGqupaieHWPoNnGOh8/73A4BnjnGpDtWicq4y627HT1rFbZZ5X
3dZ0O55GiWfmt0bGl/OY50E7x6C8janCELUSZ/iGt+aHHjRxc/qGauO1KomWVatos5alb0zfYCCa
1IT+AVRu4Twk7qJ3p8fknsmMJZw+1Zj/hmY8tFwqOsyxa7dib9nb5TSASm5F3xafB9BAoVFko502
DjnW9+51tQ1rYxNBg5mypljMVPNRZL7QW6htzFHHw/e0xHHbuf8cA4XZrMTg2blv0eLcdyg1tmOn
r2NXmvts9dxXt+NplHjme1aPPE/smNdALW34bEDUKhEtb1jdzKJROHS2I2iXCJb3pTAxGjyqZtis
2vjmdQ/JmgBPq1mdsbHnIDXAvJgt8IqAJDpclremG7lRSElb7FjlAfm4dVTnUkvP8gwPDbpY2U4+
SJFgtjWTWm0TV0yBaaV3VkgeQ1HABhH5pLF3CAhH/h+o+6hZSR1+oAAdIOTmsv/u9KhDauMQdyEZ
ufovMOhI56IP9qqxIXPQwBVFQVUnMQ2/j7zvobt8D8O1PZHgXSruBA6X0YCnvJn48WjmRdsw0nEO
gDKbtfFT5Dm/EUzbpis6+s50pkh4VQEZgRmLlkPuTcOLzRSqozdtC56axlMF1Hh+XITABWY2bkxg
tOWsdIHZS8n+bZsCdJ02/sHwD2VzfB10jsav2oljdFZ6YrJ7YVSM9dfh/xXSzTb5nSnoN7m4Oemn
s1WRmazY5NPJ2EF5f936SM4vj9+f9X6TN6Zr4aMkdO9n4+XEL7gQWU5IRw1FbTT+GJ4T0XSN4gbD
JoRYW200Dxi1DbT3Up0wleN8dQsjWLin8D0PGtQAQbS5doyqoHiolOZ7sPJLtynVjTnqKtMLG7Hy
1huVzzNQDZ7JB0Qke+ECsimPQiOeU26GnlPadWS69QXZba/cvIBn0bBRQCXvXn/8HHJlteatCCX5
HIJVtYYaVGMqtRVx0WWZtKauIG3JuqmauHvFF1m2epFNqiwl4btddKeKB/2tpUWWkm63X6mAtqIC
tswsUIE0LilZWVKalmLrVFu3YmiU2qXlYgNuNrWbuK1dLp4la8Nf9Js1wsaLt75GIzjZfM3bCtWw
mmpUXu4W/mR2zy9l4gvfm9fnSz+PE9mb+NGtHD/GX4sHChhD094kF91W/mbwn/mGMZOZmqErqv6G
MtDq2BtCv1aFis8SXaeEvFnMZms74Lnyv+mz90vvYl+cwc4UL9CgyN6xPwwd/ktmkrJP9h6csRf+
7PHXmD8bXt26boamyaCxZWj8F6Ltk74Tk/9cToliEWq3VQV3A/BgJO4x7wj23dlkghoTXtnVJt5s
QjGJ56Gh0fME4kPo+TOeW3wx4bpKOykgH952UHDF/iPfJvCJRR8V/QCUjGlMrEdmZIBHvdbxcTc1
uECZm039fye949NjsdMQgHoch5jGHVNaow89SnE5EM9sjjnBFj5eEIfZqIe+6yx5snGCpJMCZ5ww
yQO2BJ1j0EcbGyHuTsDgl2uC0fIOLvxRtbR3fFzERsVm6RYh4TNKvqVQggEfE2ee0aeVB2zRwi8b
s7yRvSXfF9tvwBEAJRyHk9lLU5Y1Yfk1TkLXWIvFqvUbBpqr0zX1ywCKODoTnHhi0osP/QasBKSM
ZedYYLU7jWh2DY2nN1vTrAykjGWvb1YCUMQxqP0cpwSkhMW05zojASlhqe6zvARICcsMnuUlQIpY
Ij3cyr5Ikx8WcOCVRtfXL03sl2OxtGg1Vg6SYWnqivr1RaA4TLY2YYZq6OdHZI8Zpo6bw3dH+/ms
JCMfZiNY1hxC01UlLz6eTZxQQJT344/PO+Qh9OIRUfHO1Did5SKe4nQKcib0yEmn289lBvm//02g
8uO831FitBlo21en3UxcK6wOp2wIp20IZ6yDO73E95/ob23izEN3AE2hB/kipOQWe56G8oCfkqKS
oiZEenhLCk9AjDxQ/LdBXII1K5NkM5aR09YlL067T7zPrnYE0+j8inQXvhfGpJ9d+Ljn8jfZR0oE
OVTMVmSD6QSPDs7TtsoJWPLXuw8wIj6c/5Ld4pIsc1fvaZufAhvvXe/zgJW9m/N9EuqSAhIMy8nP
GIRF3+K5xNifz7Gq1Ezwj0AFwRcZW8JaCvHDObGwf8p1AGLsyzJTWtoaZsqXZaa2jDXM1M9hdjOL
YYWeBXjxTsovImBsh/cOvwkjGVsXnaOz04u3MFIlPrwwhXwqLaSfknGEHqFO91/Jgp/OgfSwKqoT
C36CNBjPHvDmFJABtm2R/w6DIPQjuRkB9BkGGhSzcJC9u+rdpN20wBi8GG8A0bCZaXXAzJpBU4L8
Ppo/EocOvwxJFp1V6F2cKWOiKeKsq0H4dmYaVwPcUcvJoyITsXN+DF1xfv4+D6FJSn744Qdydtk5
xs46vjzvnF6ABgUv085CAZhZgIYmgSw7IONoeIA3sMydWFVSSJCFtBlyjtIA0y8nwvknvBVGBTsy
1SGv3v3aP+12zjCTx+X1r6Rzfd25eNs7713ctEvkMRe8K4OcyOS7kmQPlX7KJH62TjANz4kA+1uf
X48z9AUBHCmpcPhwen3zfj3nM3EFb9q0NNGsRZWEc/6m1Cr+QWWycCZoABcRDYyXLiIqlA39bK6Q
q9FTJJ2DLc0VQVIEcyuITC9MMox+4zdgBTPsI1IFqyBqjpZxRG+hCINqVxC9KqKpFDji7McIFveu
ytGstpGZagHx5vKmc9Ym6ZN3Dq32qiIyW2b6/MUNfqjj4+tev1//HPnKTPmdzRPnMZwsJzDpPhRm
3am4lHsMo5s+Mtu3fVyheCSOiMCvfqxUbXAXyyE/34XXuwj1Qf7rPh6YSamcwpkc87ii4TIAeynK
k+6kjYtB3JzNbvkx5jbpLRZcuIL98uAspuiHTQDf8pj3HPJiFo+wT/auYWpJ43ASxqgENRAo6lX8
fg/QAH5fhhFHR3MwuUVMLogn4f4UMRcoPEBMweTmG3Dfd2+uzyTne7zjBD4HSmA+06OHMIbZI1Dg
N7BLOeN383AL4+5IBDuKG3lShpN4AWqF2N0LIzDWgAwK2sBO1JhEiM3G0MAHdMFJQxj8uJakv0Ew
wgiBBj1LUgz2A+0LkhSz58DaguSf7cZ4fV74gOrQ+to8KKb90qt+v8wfyN8l/j/NUNQ36BLU6Bui
f+2K4bOp/8/xJt+iOt/6we//uz9ZSt5EUuTx7PYr8MAPXPf/Zr9VXWfZ96eKgv5fVTP/Yv7ff+j3
746cKahtj/eeg4vceDa7I+PwzsczbTsfcVHgIc2o8Y5bHndVtGgrPWeAZkRLaWFEeriIn1pT/zGW
uCXlb4zsCufvDqzfQQwa8lP0NAHVXMVNoyeXe3SNaqFjFAvhn2AepKVB4BRQ1Xqpu650SPNSpV7K
slLTrpcqOS6tl6p5KauXajllvV6q56X19g7z3jDNeqmZlzbwtfLShvbaeala/QhK3hlKtUzLu7GO
l3eEVivLu0GvleWdUBsQev7JzRpeYbDUypyszK6V5V3DaK0w7xnGarUJ8sJa1yjDvLDWN2ZeqNQa
aXp5Ya2Vat4Std6UfGRqtaaYed9ptaaY+WzRarVV80K9hlmYwHqtE9S8h3R15zEaLHzH29tvk/up
O3ei6MEjt35MfNT+ZdK6n7Q8i7oMDEBJ8xVLGrr6UAoUxZGY6VLHhDXEcVgrw5Z33JGzSCNA0JW3
EP47kHEogFrzOGrRna6wFNpkvvDnDoY4Cil1AMZGyD1SqBFj+MjCD9CoK8syFF7iwmKAqhZF3OQA
JidHbfKxQA6vtkVN2gebxoV2o6dm53iGxenrB66Nz6Y12ZkAtO7vhh7wqBM/Ofp82sGQk8465xZv
90Ws/JVwLGFvBnikCXtIgi5q8eDNJz9ubDS/MxmrEJa8VEn9stIVFVSShUO0/QtUr+ssFk/IJ/nW
ayniq5QMzARbRwmQ3DuVASXBZoLzLTdw01b9VS2kov7H/iT9T9XNgv7HuP73l9v/f9X/Vqlw7HP0
P/aq/73qf6/636v+95z+Z8DqYGkqk1zf1iRb95lke4ovaRr1HXdoq2pgfWv9j63W/9g30P/Y19P/
2DMKVl0dMs2t1KEvrx+yin7YqOL92cvtX+5B/Q/vdUzu1fgqGuAz+l/J/0sVKGeY/flV//sWD35/
MYGk4TIce/5Cmn7pUbD+++M19FX/r8ZU5fX7f4vnu+++IxI+5NFNFj+SDAQwBm6DEBe3uY/3N3Ow
nUd3AGCDNAgCpPyEp9o93MUePOSLK1oTjN9wdRhP5kFEFrN0U/Ywjp+oWAymzsQ/5FF4C8p2D0jg
i7DXw93dlIuIlxhgLcCohz85zm4LzxS0eKLtFicVgYYAlVj+IfHLak2JMUlQzkhNeI05KUwVBk+b
KIoGuuhRCpJEWWzCTiTklsPJ7XYcTZMVOWLipAFMwQHS45f/YMD1AWZQizCqR8J7ex4tY2BopZ+q
Miej+0nhd+VnuRiwU46g5UT+gLcFr0HD/FdpEbpKBvxqJtwXXjzhots7O5HS/NKiCEMV0iRraxDF
1cHDP055NvQCaqlzSOFpE8007ULneLPB7XL6RzhvE/4Xmd0dYASQ4gSKKSKANMcJdLpz+a8dfxwk
bRuGUwez48xHHlSHxw0d0sckrnjiT6I/8OpdiwdkPIelcbAMixlOM1aakSfjw2un87BFDo7fWKBM
Zzhp3r7v9W8Gl31ySHZx4D7urgH70Lvun15eICwMtmbIX3oXRbhksDTDYrzS4KjT7wEkfUyCn5rr
KQJlBJgIs24Ee/frVe+62zk7G1x13qZkGVVWwZ/0Ojfvr3u8+f+GsQQYQjLAIKuBCCD6n7kDv9Gr
MHCGs3t/oN0Omxtz1ekNzi+Pkenukx81A2F0Wu8aQZLB3Ay2nN5NZw9TnGoEyjEMzid79NHbbwTv
v+9f9S6OB93ORbd3xlvNmrvnw6B/04FOP7v8yMEC3Vrd51cYlzS4PDnp9244dA6Gw3IAs9YduCMf
w6WSGFk/au/gHMIMdIMhnjFPntIHxhdi7CKZWRBgGnrBIENO3jYjc4g7EeFUgGBVCNTSSxVIZkIG
4U9BTJQgksFVklJY1zRiriL92gXGYrJlTFIB408SqYqX+IMEPD86SML4YF4jGv9xQLQ7AgbkqI5X
BCsJ7BwkFaBQKRHK2E7snEp182BmvOSTqMrOGjHI0PGQLxG4GDcLbLG+RP7thF8dl8ZYZoRWdREh
e/NgKoQV+RHb6buimfvZBwimg3g2mMcLfh7nPQYRYhQtiMYU80eBxyPdzEC1Tdf2/HRMo8AvyVSS
3HRbhhX1St95Bl2Nz8r4AraM7zOqMndl7yTLe7F3kv4QvcPsoVHsHSjkvcNU16l0T+NnY8XP9lwH
AvEfE9J5DxquahSG8IoF0LQsU3NFpYGAbTC6ss3z0VOkTDAKNG1z2sq0zW6pzVgqGk23HRGA+SPH
y9pjqQrzC+0RtUOyvDIkiZXk56qy2on6ZNVxjf2V6DDJ8OIRnxQa55pldHM1euq7KaFbZXRrf2e6
KC5MCJcarWl8Z0tViq/TJxmcFeADGMmc1F60jraa0abF1+6XoE0pE7QV9jxtlw1T2lpOfOV4y2OA
8z61i+PNs8vjzbVfOt5cuz7e6NrxNswCjfMvLuqTVcez9xskL0LzhUuQxPUtRXcKDJsw5rfQHQUM
0cul9aQs3J2FO4IujZdzXuo7i/ETdgE/bSCCZFNsseakukAWsJ+sQRja2a5YES/FRIviPw4JjxLN
V8NNqJTtkpdjzl+Kmjea38TjDzjgYK5MoFcBQ1X4KYOSarDjjqHf+dApjDfrgEz4vzWVUU1vBjJL
QMYWw5mLz/Joxrj5HS4lByglB6IrsqEiRskImrzAN0lV7hPjJdXAkQO3gJSdioEvzBYSwDCbL8Jp
jApadrphRwjG+lIHA1mnOrfUxG9nOpuSSWLjZuKU4PUF0Q4nMZ9n9LhHoQps27qZ0xP9UwFRdE01
EKYyP8bcCYFps31vIE4tiB6l6YcYBqqPmx4ZRLUb7935cv27hVoUO8UPrO2MneUUanQ/SXHBfI8f
Y+xxc2gNDStzL/j8+qdGLe4LeFLccQhC+NWT8upJefWkvHpSXj0pr56Ur+JJUXSj5EoRtyg870sp
wH1LZ4rOlL+nM8W3bLqpM0XAlpwhnkKHq/HLzpQEtoI/HL46U7Z1pgTNzhTthc4UrWTc0mC4zrht
cqYEZWdKsKUzJSg7U4ItnSlB2ZkSvDpTPt+ZEhSdKQ6tOFOCFztTgrozhfprx1uDMyWpT1od+LmV
M8Whr86Uf5YzRSz6jY6SoORNYc3elKDkTWFbeFOCmjeF+nx0/RW9KZqmfXNviiF2mf5sb0pQ9Kaw
td4UzzUVZ6U35c8No/nbPkn8nyfxTOpf5wAICoG18X+mVj3/axiv8V/f5PkFF9MkIR9Ky5NFSMrp
fWxMgqDIKO0wnwdL/6G8Trl/wJPO/6909Is/6+e/aWpMr8x/ZjD1df5/i+cTTm6JKlJxwqsmZqY6
vTi5JHv9xf2xA5rNtK2qjF+64xHxIsvjuRUNPaHh/n97V9vjtq2s87X7K4QAB14DS69Evbt3L26T
NG1wmrZIm9wPRWDoNWvEb7XsTfYU+e93ZkjJsi3LlFfr7OZaTROLEodDcmY4pB4OaeMZeB44Hw9u
guEIJzq9RsQsLokVJzG+FeuOtWRe/Pjs7U/aOWYUsRdfoZ9jmJLYKq03T2gPRXL+T2ccfB6QFzOM
O33NvNA6eIPBguDWMnzX9lzfNPgv8CTLhvE8SeGBa7qWBSngQsOdjs+ul4sYOMQNL9l0IlNjXOmX
v6cT/AhEhWVIGx+jxZWPZxhwNr+J5gGeLijv5svJRNAx4A44xrW1jyHeg3L5nuMbnv5LiQmZr3iN
TiakN6Bz4hFW7S94ocGf95A3BA/3Y8EUfviBnx3RrEzvfOnu7+PNvrH8rvZGdAbO3KTjDeTfvn31
ogj4ySr+yq/e9u4dvbmQ4DlKXToZgWJNvcYAvyC5WV/7B/oNF5bjQbaYzrDCww+T6TzpUHMH0NoD
MT/ARzqmLpfUpx0V7jskFyAz6KNjJnl4I6bThBfTzunzh3YuFy67XZlrhge5TlOUx04M+ebTW/lE
8ouE1hiGRyRZGyXh65fyHmaOy8miqEwurR0rvxuQTmOSYXcq5eAAHdV1b9X8UgpKXQDFXpqX0pgM
R8MFtbZQqEoeUIXEwtUlRRwjdnXLs12nIxQDeuwS6vshoWdCQTpC+y95TVGk8B3cuKbav7mSiwbN
kmg5B6oDIJ9QM+al6jWl4nOj7rk4w/ZyJuNNMvmlmI3xlIYiPiSTBzZSc5QbCRcEMBEkQSbFDfsR
nppd7Yc4xh6USVozTeybLpiDCR1lgWE8SfZwixmdPZs1pCYFy9+2/sIG/iFtJW1nVhqd/qCP133D
dbswtA0/a7NgcX1VnApKWkRTrgzt5KKO5v/+8OZXjKpJ/P7w+6u+44IC4Mm6OOvta++evejBEDqQ
+xwxbCcdrtIGTYoM1wrFDIQKRuceKBGu+Q3w1NN5nLVDnI4UJdKCbNtU4baldn0t6C1x4QpN8gBc
qLYoZ/dE+dVLYnqSLD5N5x/bI9q60Eqar3943jLBP9+2Q1CsrzSSKOkLvf7lze/Pc6OCntBvYJvp
REE0LnIUFLZEg5cZvK0JAA1tkkW7A55hYXdYMBv28PXvNZCYa5DzYSSiBWOo0zBJJkVMT9qZu7gG
myroKXjn7XI7Hs1nETFbVbTp1Ttrlr5l04U//wKPUJgswK2nsQM/kgdjdF/AhQhm0nH9lOAx0R1a
K/0C97+/G4AfQE7OnXa64XiaA7RK4zr+/gvdZ3neFnGT6okXhJHBDCsOGU91lzluGrM4dHhkpF7s
pga8eN7BPc9A6J/Cq1TK+aUL5SWebphuGjIrsVzmRS5ndmTGzAtMJ/Dj1EjNVJQxTKmIkM6GxkKS
xTU5K+MgIlfB6Qe877p9I+iHVj9cc3OVikHHJ5oPZ+RsQXlMlkWM2lboJKltMSflDjPi2GRRzA2m
u54dBj6Mt5wLRjfaQikjTlygW1Hu5QRKnJiHBFA+8PvTUoTm74heIkcI+5+qmfuWBHmrwLktQ/CX
l8zrGbqEt7Gh6Tm97O8leNppRu04jYnGXFQ4tvzADIOIcd0NmR1HOuN+6LPIMczQNkPfMWNR4TSk
Ct9MouVETg+FGzkFBZ8PxCFyJFHbr+Q+HTwhx3USgfqDg3grvL8v+18p9bISy1+6XzYnCdjeFFt5
gC0nE0Dj6JsEQd5yVcHoMqBggyBdYM0qpinQ/eALpKRQan3/XhQmMQ3kuDcCKtI0LBtI73ogjByQ
eRmMskTOO1aOfNkQiDoHCzELW85kzX9+91p8zVxZJmyy3G2nnhR2YkBhdIjlZVY4mIwO8bkMh0Vw
p440YWJyuKOKu6CfpSnAqmWVuvr92kRzc2Is5ldYdxiDBuNhviCxqv50NIxu864XjTUOPucrHOvZ
Kd1xDd3zHGtLUkprHoqzYEk+voXuU6C/mjJJcQgGi2SMXZaURGGTKNW5RDRXJJVwJ1VrC/qm3hSD
VpU5+LJVjcolBrDEq35XMuTY7zeL2bjI9r5y2Wf3CN73fauLx3KIFR88ZgGGbJDVPERLX8v16Fvx
DHgTz8DxQ56YScoC1zBZYoBouFHgsBjlhVu+47rWYaP2mj1XKqZ21I6txA78NGW6H3pMj92AeWHs
sdQDp8SxU9PXvXsexPj+QYyvD2IKLFPlfBhFXB/cqiQwU+bZYDE5132mW27kuo6Z2H5Q7Z8p5aQy
dCd0wjixmB2aEbP9JGYhWtxQjwxbjxwwB26l26OU8aG5PcfzDJSa56t4BvzRewYK+nPyDA70DGLu
6V4ScBaFrslgLI5YGsY2MyIz9JxQtyyXfx3PQGmwOKJnwB+9Z5Dv6WriGdhpqvuOETLXjALmGJ4B
Jg3mPlbIHRuMGow17kGeQZCWB0mlYmo9A9exXS+MEua4OlgIn/vMiayI+T6MgKkfB2BG7tkzMPd7
Bma50kosy8q5SWSYoAHccUEhYJB3Ah1u4R3bh1eh8ao9A6WcVEbg+b5phRGLY8ti3AmgH2BIYykP
Yi/1Yj21nUrPQCnjMT0DMLsfYQx4KK6BUvsc1zUoW4JH7BooKdDRXQOOU23bsp378g1qCriDc1Cm
WngHCmHyv453oDRgHMM7yFXpW/EOGq0bmLbnpzY0O48ck0UcdE/noclix/RCL3B4FKbV45JSThqX
LN12LNfwQMlB/MwgsljgeAm6qVasG77BXb9yXFLK+ODGJbjlnmu6CYzUpm+kLIn8lMWmhZ9cDBhK
uBMbhnHProy135Wxyq6MEstUuciNYzP1LOYHoC5W6EIe3bdYFKRR4thW7DjRQQ5luLbqolTMbofy
eN6BkpR+Fe/gsS8cKMnkyTs43DsAA24HXgyObYo23NJNlnrQ3kHghIbDeeTpwdfxDpS0/4jegcra
ASKRRS7X6Ypzc0u4xPzzhOil5s6GAS7StrcBbbqYL6OFSFOgGuKOs+lE4JufyRvNsD0Yzk2u/Xv4
TEvnSfI9NAa0Atct73tNHPnaqGGrYH0HeFiGq5tblUYzWdBE50mBrtgGyk3o7l+n2rtfn2vyWAEh
psu5RLfAgKwFEcIeD2HWhB4alNhb05srsWtu06JciRhTur79cIg7C3WVlq/rVW5t9irBVhW6VUB4
RNMZpt8VWxtF3bRpdiUAxiDfV4ZAXV6pdLGgZzrQsYRxXe1DvFISkTw/dCWGj8GYD0V+x2pAwO5q
cjvxikCDIatBSWAOaDP9ILlZRNeTxlV1u7nPn1O40lQsUp4fxFIGk1rV9E6gpQZlg9isBYfY0co1
vo96YS7MxwT89zCZco1uESyryL+V3e6bdu32BNsA2ZQTQXKh+hpOn7R+Y0BWXdmSdSjhufAKRwix
w0FiPYkOZ0Y7/E9nNp8uptGUnDOx/ZYF4ZBG+IVwIQR8Rx79wUoAdJkk3Lr6Q0g6X+hYlbrTOLbN
zt6Kcb2mYvlhIJJjqkThI68hbPI3tyuyweJ2q0jcvIBBbVdxuyFqa6kuOjAkVU8AHyaa63HJrDjc
pl5k4Z3WJXa7qw6XV+SvcT9Vd/VuiS/xUtaysvTUK4Vo6ZZ0YsOaPkZIZ8t6IrlnQiioUQzXMDvF
gh/Lu4pWIHCuv1OzKnSpUtlqNYtsoOChVrvgPXqrbQ07XJ9yjta+bypK2KbUrLdbsdhStTbSTH6a
qSfK7B79XPVXSzo6TElHvwY+vGXdqmO42Bor9OSelWqY7h+u4J3Wh6vtTqxWr43WOLw3L5NFhOuM
lyIpuyx17x4RqtIDpXGtziZgo+5RINE3CsojFyM8mBpls+ATbYeRu59orTXra/VLrdpf+9ZioVaM
RjFD/BQ7XGkEu1jvMSb9Pr1H//WLROme4J04u5DEe0FLmuw1/g1Fz24675Ur7OOUv1RPbYaBQ0zf
sxWk9Qhbr1VB1ru2Xoud0DIIQMcwuW8hcsDu+abMdtS910Z+V9p7TcvGcof4040d4g3WPrraeT6p
bzaXh4y4VHzXPVNApvxxYo+6wNsYADbTztfixVpg9D3dsTmY/vMicG5HOWwucrGK+GtybnBuWy6H
5PXwwtAIkLYWfVYvXvrtD426ARI2gv0CRc49Tl+Zz2WgXRllFxI2YuQaVIKM2HubZHArQgwDFQf+
OB7WshzMWIag63a7Ty9We+GLJlYZQ5vux5fbxvOTQukjpDgstJDLS4pgi09WjJc+DtGR7fS9Uigc
aEkFOW9FbvVpTzYdKUWxG19V5Q/dKS+YuL5hpKlsNP1EXBaSt3qHpJxNSXNJIFaP0LVnGHxYNouU
s9UHpM2QBJtUZTwUarde6SkINcs9SpCZcjtXxT/IM8XxnIlwxoXRkfXMg+WxmQxCsZLh1VuyjVgU
TKJkZZb2BTMQmfPlOeKdFJKRQjJUyPVWL17NFZq4YkKhC843YxkMp2A0OlUacVEKylAqBvWo1MBS
rVbimUvsQct5Nuh1+Vxcid1A5/oAF+8rLrTkzbzPe83fa92DPXg6WHBUdhW4H/txxAMWJpbBbCf0
mOtbEQNv1oe72HCE3djvi1JAyFw5K5zTcrfcLMDE1nuhpXY+oAVtZ13clGi0FTxjH3c2enzyYOI/
oA2X2XMwNVjxfT75pcyFVhiyVVbKfaBFO7q/q2heS20tAoH8IGnoGHDrJR0ygVJEkT4Lo4I9/l9y
2B7GV4a25nTJr5NX+R4EjeT4SgSg+u++Jub9mq6dQ9Xxg9VyJKJvhMnq6O+e9rxIx9MtNDGly6cF
OLlUaKFNifN8d0vipHvdFx8ZK75M7ifr46JGNVmRcm5s4w32k7W5j3aK6GxO/Q4hZzoYDQvDn66o
bX++ViCE8dPeQCffIB2a8TanYvvbmMi8zeTCkODw+SjIMu0Ky7nIm+Dq0FI3ec9X8I7BfxiX+T+8
5M06iGPrj1CBj+s1OLDcTfbxo8QxuE/DMvOHlbrBezHiH4F/WVapDncoHWyBALgc3aT8+ObNb28I
AvUMozDjZPNN8jdFDRcHEYiDjXpnf86DKKHR63w8hafzJIIZHwXF0aBJFl08b+UlhrF+WjGpx7vZ
7eJ6ShFhLj8l4aUssje7hWksQRw8+0KDEQymIjhTo7DXcxjn5hNtOhuMYYiZxufT2QUk/t1tUBgt
uYjB8LKAepWKdV0qFsqgGpfLzZJR2vsc98TYKp6fUyKkYBCgX2GgPe9ioHQcTBtzteq/Ej8w1pvE
UbnUMxkCHCN19z6Bp/dyOheCmZ3foViS81XRtudQyesFUNlUa6ixSFv5ObieE6FOdO/MluyjNTeq
3C4238Wc7K5xMBO9s/bKheBdKMOrF8BY65xJEVorlhh7+q/sqfYvsegVrzFCduRCS+ZzYOfd+Mf5
fDo/qi9Wj3rMN1fsQD3uN0WHoB63qbaHeqzjuBL1uI3T2l/pfahHXol63KbbAupRgdkDUY+G3hD2
2Kxbt2GP3OGGZSl0rDruke/EPe7qjGrco4qQ1OEem4hD+8DH3SWpAR9351cDPu7O3xrwcecmsd1l
3wPwcWdhisDH3flVgY/r0OBDgI9q+5nryn5wa5s0ZeLVC5tcAfhYX7EmwEe+/mV+LV7AzpVO3i7w
ke+p5QMAPt7PPv/HJbMwU94rsjuBj3eQ2DrgY1N53QQ+KvVTdVc3AT7yxsDH9nRiw5o+ytANLSvK
Q0Q+8t3IR66GfLyDih2uUFXIR1URawn5qCBAzRRUDfrIFbri3qCPbYbSaVm56hg+OvRx74C1E/p4
B22qgz6W9WsH9LF5bx4EfRQ9UqUHB0IfeUPoo9oQd0zoI6+CPpZ7bBP6aLYCfayscDX00TKsynn7
nrAj9wB9VI0T0xD6CBbdOUEf24A+FnJ7gj7eF/SxaGKVMbQt6CP3W4U+miWc3R7oo6rKPxroo1jf
PWEfW8Q+lkfLAvvIW8M+1ntlTbGPD3atJW/mfe5rPfbxa0wIK7GPYZqkQQiGw7Mji4VmGIBva3nM
jBzP0QM9jl1FZ/SesI/7XNH2cYt7BFkJVVlL40AAIlcDID7UohtjH3Nqd8Y+cm3N68qxj0UQpWOC
H/eIrQL4sfKT2R6y+8GPvBL8uIdsU/DjPnLKSKV9hNTAj/VU7gv82Iz3Oghi2/yrgx+b1WEnCLHt
CqiCH5uxvwuG2Db3auDHRrzXwg9b5r8h+HGvLVADP7ZuUk7gxxP48QR+/PbAj0/+/13RbNkj9Vh8
XtxXGQj6cyzricT/bf5ruYb+xMAj6i3H0U3nCdhd3TafaPp9MVS+lmgpNO0JLtLWvbfv+SO9iuW8
7/AY7hvQ2+l8MIzh7qdksgQ9fQVT+tEZiAkMauPh6BaeOGc01H4HPy0uftPsCe7zi3Kdv+mC0s2T
8z9fd7Whzbit69rz399q/6OZPVP/6ef/nGWLZDaDUReyulTI65//g3RN7vOebTtnURBdJxqCH7Fg
w7K0fz87m13fZkMYRDViVD/LhiGYlA/ZdxhzNIIS8QE9QZKYIB4Fs2GUP8GF+yGQkGmYlM6W+OwW
7CP8HCSfo2SGqxUyDWgNY22U3EDVgZp59mlWvD4KoHS4gXxgUbRFFmnjbA4jHFigzx4VAnZspo0X
87kWgeeFh4Jr0SgdLbNrLYhmQ208/qylnyFTliX4P4e/tGvwKG4z4S+MyVlaBJPFAOnPk9ngw3Qa
a7PJEF7NEhOKMhzMag0M8Q/XZtNZBB7HKLhOB0BhGAdn4fQDDIkzbBIHxq6eZZ/ljOTtbIl2HwSj
4YfJGFwWkYiLoSAs9BpmNx0tHC4yLe+PC83yRIqEaJzRRyAZYxfp9M/OyhJnfGsSZ+yUOL4tcfwk
cUeXOP6tSRzfKXHWtsRZJ4k7usSZ35rEmTslztmWOOckcUeRuK/tR56u03W6TtfpOl2n63SdrtN1
uk7X6Tpdp+t0na7TdbpO1+k6XafrdJ2uh3H9H+kCGZwAIAMA
--f46d04430662c40d6304b92b55c3
Content-Type: application/x-gzip; name="xen_server_6.0.0.tar.gz"
Content-Disposition: attachment; filename="xen_server_6.0.0.tar.gz"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyrf2gav1

H4sIAIhyPk8AA9RcW3PqSJLuZ35FxfTD2GcNo7sEu54YjPE5xDG227inO9brcOhSYK1BYiThY/ev
38wq3UAlJHDPw9LRx0LKLzMrKysz64K8FY0XP/17PxJ8DE1jf+Gz89c0DFn6SZZN2dRMSZflnyRZ
MmTtJyL9m/Vin02c2BEhP0VhmOyja3r+//RzT2MavfnBgrz5UbKxl8T2vIjGMYnXtkuJ7YRvlEjv
c+qy3upc+8HmnbzRKPbDgCg9o6cqPVnpSj2zJ/feY6MnwX+60u/JpgRd+04DcrKg9DX8h7Pxl95L
GCencMd1cyYaABWiSJIlmZJGTu6pR77ZCb/f1azTU/KzTGbTO/KwoWS4WRBVIrI2kPWBKpPx5QNg
ZbnzfXx/M74m8Wa9DqMEeLjrTTzoEDIJErokX2mw8QPKvsDN4fQSWCUvNEh8F77ArZvZCKhCjxLn
A7/ArdFH5L/zfydBnFDbw5uAsTdR9vebvVnGcPshsoN4RRM7E/UwfbeMrQf51eju187vNOiuo/DN
90DXle2+AISs6CqMPuDrGjS/mNzOBkTa+ZBu+VYfO4acbGLbWdJTAYYTbGFsxuYkYn1PPRGKViTJ
UiNK3tVPyVSu0y8nKGOUJkk5SYHSmiTlBGVMoyStKsm0PdPYJykn2MK4CsMMR3cTcvPPmQjFSbZR
ToHy7MQWwpwKbK7vb1ZOso1qata80iwqGU2SUpItlKw1GSMl2UKpbqMsTrKFMueNsjhJCeXwv/W2
cCxOUMLM7RRTq18WQ0sovCU3oTzZ3UV5WpOsubQjS84e1aMKkhylmXO6Y4utuLV++Yh9F9LG/XCa
Ri14vjdoKXNrh+PldAKZxCRrVCxIep2lHSfP63lAziH1MHrg/f5sR+5LfjtTtuMHfuKDBkXoXINi
oEJJJiN65hTPSAEZr6pkd1fFTomEcct1X9sLSrTXziuNAkgunh9RNyEpZ5Jgu2KyWZMkJDnmH8Qz
8LJLaR+Zg8kuJ7PvqIdeDEe3j97XQX8dkPvZ5R3qMJc0XcILBfLjm6SQ4fVw9n14mpL9PoMkyCOI
ycj0EZLJKRmBz5BMyYRAF5sQZfqQ/iaE8C6X1YzNFfxhbGxZt/DpFZOmHcjmMteGsTGvri7KSpfY
ZKad3DxcYwEA1Z9slrSZEYwfDhgQabXMKsO7yYjrqXCr9C0UoB6o5yzT01YoNhfKztRq0wkkaGRD
7u5vR/nwINPZ1QORVP4tYzMdXX3lbNQ500ZtMj5nwz79vLnD4VWqjaYyNpfqFpvb8ZSRNLD5djdO
2egS60PVanaFXj7cc4+aDu9TNhrTZlzHJrMN68Ps22lHml6Qb5Ov36bjKbHfbH+JQ6LXgcwID65v
f9u5T7Jxuwx/kMhe8eFbjMPa+wHWa1LpcTFclTQGFlQOFPEgp0yEf3QIcZ0TnVA7Wn4QHh3tBErT
+JScn/+dw+iKPFaiAf/yBBJ+lvjjrRpI9zTZ057QWg/j3x/I5fBhSC5mM8a1lhy5yfyxXk7TPHow
bhhkSR6Ec24icuSmpI89vSxMl42UW/65uP9e4iYgR24qf8z5p4+pR3Pd+MD5+jC8uB4X3ETkyE2r
mBU/xja3i9vbh+nwruAmIu/Mw03gsYnC9K7LYjCBacTjnEIEUVTgB1RzD646/x1CrX13dQM+Eywo
myVcTodclvResP97+k3mbnQTRivINKR0N6dhPgk03/zFyxScpXR3h2YavjHd/kAlcPqZMFXmYQQe
6L4wZ+0wX3zGS8xXj8oTsd3Efytr3WHaDkQKM8/cei5S5DbIBkYSJvYSc1o8IHJf0WWlM48ohYxL
7WeWO5FwkJKfkfUCqlHiShp1ZAu+cz3pCnUlrswL+9So2MwBURWWMyEpxuCx2FYgB+otIimlyQqU
rYeaZGj8+Rm5nlzdEsdO3JdBqV84naxZVq2sbUrL6CuWgKcqZ2FQYbnmxF777rPvPaLxnsiGX8lP
hAbYk14WNd8VJIS7CRQi/iIII2hDLScl56R8kpOWc1I/ycnIOWmHc3q+gTR7wvHz9PNEXmBAEOpB
vbT0gwQeyU8Zx8ktVyC3bLr48FgsODyRRew/O3ZMHyXAcQRcDkiqNbpjtpKgKmf5+kXB4ox8nUGi
6ipqJvbm4Xl2P3q+/ec9OXE2MWaGTfzsR/+Cq8UydOwl+6IQb77E/0+bgf0ysM8bvaRvtMDe/yJx
h3Q+SAgaRxC7e8VDZd/DvuDhrzGWmmxeczIdXj6cMk/H6OeGwdxfbCKWw4gfzNHp8bozXC5DFy4B
eDea4DgLN5ELI4WFIbwNw7qYyiygoM+/Dsw5nwyfdm7un6FAmg1gUAfRs7verOz49dnxk7i4BV0T
DzT8woIDfpM7d+N7AA7IeOVQD1NXn4++vwGA/MOVDQcrYxLLKtQmJJIIRGtZ08jG0HXV6KyBrGtj
GwZ1NIQ9PpeNL5rU30Y8YgZg/8rsX4X9q5LO7Edat0+vbmJmRQyyWPjYkE9AKQcsDHc0ObunwfxL
1k87Fxt/mQA7jCdLP05isDZhySWMPBqdkVXo+Es/+SCLKNwwGWHQg2oA4y3JA67U7yud73wq4YYQ
qkAEDBYIUbjseH49vBhfn+NlN4g+Nos5XcAD8k4D6On4/OXNxS6PwyXFayn/kiQfEvnXxqcJeVvY
56alk3gNc6uXzt3kkrzABZ+psCHtoypoM3LCdB8QGEyyoVoauF1CY5im8ZHvQo6iQrSsYk2Z480z
oiuaAtE4ZTBBT+jW43kHZnDjjCiGgj2bwscYjtCEc5gekiuo0GMbEiIaCxw5gXDU6/WIB9bvFbSb
AH0TPG02mV4yEH136ZqNjHSpsEBN+FTS/wOR4Kg/S51ZOE9+QBqEWEUeri+ymDggHTJc0yjZRNBL
+IHktKILm+kKz7JVVP8PeA5JBgdHh6R9zPL3ABKl6aRrPq7OLzswLLuQ8waED+84E+9AbePCn818
TiNmBHBT0Olk9tvkFhQ73VY+q0KQKs3xJ1mVMMguTjtTNiMGW1uKqUmvfzNNS4G/RWVOThTd0l/J
a+acHj0jlin1ldc8S4ObaDrQ4ALVGVFl45VgyXBGgBHGQUi+p51seTlllE7Wl/ZHuEkGrFKZ++9Y
PeDMHUK3ZZppgfeO9RtboSHkRDVkg7xCaxGxfmWAFKHlJSF8MfgXQCiSZuWItxWLBRxRKiIBobKF
DkQQRTHJNEXAxAJLf4ZwywiaTesRAdOaHEFID5ufIrS5miFcSdeUDKGW2gEItF2KUC3DtMwUoc0V
3bQQgTYuIxL6nskoJhEFnPCeY4jRC3Vf0Sv8OUle/BhnDhD0Y/CNlzCADBDDbUp+u0MvJZC0MGng
6MCtAaRaQbfDKLl97XW++TTCdRi+6DP6lfir9ZKucCkcx1QPcwMkrNkA7d4Zvyc0wDg/mt7OyAcU
tQPC3BznLxHlC/VYHPaVngGpY/rtj0K5XmfEAxmMlHAJahJvs1p9EI+++TAULOld0TtprCOPGOzy
kqW4jQGxuD2C8eFEPAF6FLwP8ipbsPFXNILgSF1/DiUOxGoggSYTw5BxJ4NchItwOrmbkZPl+n/P
VVXq65YJ09y170HN+z4AbnN7s0ywLaZhkRW4wGoD81FVkjsz6m4iTAJXMEWlP8KIDxA2WEGpKQzt
ZE9YxGp85YIVcFEijVkxZM7paAz1avAaFx3815dl8ldgHifRxmX9AW24/d7rYFlgLxMYfDbOIoBr
/MNPcM9hgWtUv96xoZ0WHCMIpdA70Pdsj0eSIEFJahMPXnkAk0oUlau3lM4FGHnxkuAimYa34iqR
2vkKkTJJ7ZHvOXVuxg8Dck8XkHBphIuQUZiE4CKQGFY+zOBlI20IlmjJx5qStetDgzIABtl03Wa7
VILJElaahGYDPaYLdG1e59GYLz7oOmdwEyap+0yno9ubq8nXHn/AQ/c2a6aGzOIxE2G76OQdxw/B
u2GWlcBUECIu+S+405X+jnVYttw1Hg3IdRi+oqnGIxyauMKWPXwH58LdLpk4ENleYxLOcbxulrTL
6k/Id0jBTDicXpf7GffConVE4d98hPAnJ7mbzSQy07MaljcsrdqxKT5yiDbrJB0yiz/JtIwBTj7R
DjkkSzhoAlb3rkKIW5ET2pFX1LLlPsg6hk+us2DENeM7nGnLcB2cPN/OJidsg/MUyiZameXchFAn
uK9pAMJKcRN4aZ9PkBJF4gYncaBEhwnPDz/wwh9AGIUrpvF/YggOKHa9HX2cYVVP/gLOeQ4Xz24U
/yWtZtD2xAbLLFLRWK3fQwFILjjnR7gBce0kzecQiMDD0y8DSe6Bue+m459Lu6FMh0uJXKovwOZS
hfHi1aE8P+besPVcwecwiogsQbWDqWK1QvfF2ZrDs28XL00+8asDWyUwLvnPGYd0ywU5ONnUsYYD
VP2IhGZx2alcSd1ByMY+halkZgqzSyH4UBuWUEIbynZJJVWpqGQUKhnqrgU4+GCV7AaVnP1WkgqV
1EqncPDBKjkNKrlHcXUbuWpHcdUauOpHcdUbuBpHcTUauJpHcTX3cvX2+7ReOJBe9WnvqK72Grp6
3lNylbZihSwzXWTZfKpDaDsIrr0sqbUIaycezXk8mtfLcHcQlCNorYxKzPM4wtu1Z4HYaYfkcoRb
Raj7xr9WdJ8mVbovB1cU1Lg4vYrQxV0jORzhVM2mi7tGsjnCrppNr+maPkf062Xsdo3FEVatjErL
TY4wa1te6RqDI4wthAygPSPLzvPl3K7myy2wJsy42WwWOLiCjLvFwa14hlWI7+8H77SWchTdsU8Z
oZZbWyg8dwqZjiQLSgRewUCplNZfMCt5ZMu0cleSRbQpnUi/Gu4pYrc3rLJqouqlDD6iN/L0Jmic
0pWUMq267Tjlxnl8WMIfsxah7SBUjlDVWoS1g1A4QqmX4e4gZI6Qa2Uou+2QOGK7bFO33a6SjDw5
7yS4NOe14FoP9Ipu9qTdTso4CNMZ5rI62n31iqDD1W4lGTFagTdnhhK5k1brzVvNrPiitu1flZzh
FmAXjSwE5xPMS5lcKgKCupoAyesqA62NUXWxUbWupFVMpNebqNzKion0BhM5BdipmEhvMpH+CRPp
bUxkiE2kdyW9YiKj3kTlVlZMZOxPb45dgO1KrDcaLCBuu9Gm7aa47Ua3MkNktIIx5xZhfA+i0mCr
1GBx/Df3ZhCvyCAYF3c5mEctC5gNywLwXDuKq9bAVT+Kq97A9YhJ/RZKzNU8iqvZwNU6iqvVwLV/
FNf+Pq75sBIMG3Nn2GS07YfNDmLfsOnXBpk/YdgIGmd1JatM228K3P1PBO5+Q/DKx5RA0X5XskWK
imjtHVqnIZX1S/aXdmuqLbAl7G5JjChsqAieCg1Yazqn2XR6nTmcruQ8CWjbO/AOouLAZQNW3M+t
s/6WA2dlLV7u5SBee90eApWytsyhtjAuDUOr4gbuUenabe42o67b3K7kPgloW0QRSxQDjE9HEbNO
Va8reU+iIC6gpV2JPolCs4B2noXeZ/ZV4mUECQNy8+t0mJ4KKG0vTPK9nHu+l0Me2KbR4/88zy6e
e7jh0Hu+u394OhBzN/79aKB2LFA/FmgcCzSPB17cK/In0Rf36p/A4mhzl1nAlfJ5Pkd3YMHiE12Z
sfhspwIL6/Ms+sexkO72ucS1H7ySx+ub78MncjK5/yUmKtGITgxiYqb5IstEVnA1SM63f2sYXJQZ
fMk5tGcwyhh8yVQ4CH6524DD1B8L21/Gky/iOJmzuPo8i69VFl8OssK3XQZfqr3wTgM8pY07//yo
Bdskd/BMFKQFL/LfaNTrvC1sO3IG2TkbGw9qMrEDnkT4Uu2ZR/EoQXzuh/8BPM/CH0F+zQ4inAdh
QHNmy9D2spMXpZOr7BTb/S/58YFZ+USJy/iwXX087NhZB2vQI7jjUDxCUznnEazL5zy2AAO+X4+2
SDfws1/eILctFpugxCT+gIsV4S2Hgg+Pg7EDfOzYWLGkCJdYv+ERHuJQdr4pPcW+jwMtCgearvse
yAEE9wsd+upRHJSCg3qUDsVGMVw2c1CQAzvlkLFQ2NaM0m8AmhWgxrbCNE/eD3SqQKavpqsHA3UL
gWaDqlWgLLPdJFluamUVqjNl9VYydz3ULTy0uWcEHIqlTsqXOokbbpYelJAJ8Gmth2TlekjWEXrM
85EybzVSXEHHaazHTQFw30bSGYkh2AWeHX2QopiWBRiCZ3L5sZ8B2dpMEhLjr+AKasEukhB1dz++
Gj+MvpWgHFjaREpvpIbau5Mkbp0iwGy1bs/Rje2G7SWstKXVXohYZVWA2emQ0n6IkHinQ6obIUJU
60bozY3QBJhWdtdF+ld2KYSo1vobzfrrAkwr/Q2R/pUtBCGqjf7VhTyx/pYA06S/KRzQewnbqFxd
phOrbAswTSoXdA0qF4Qtray1UbkvwLSwstbWytpBKuttVHYEmJ3oUloBFBLvendl6U+IatkIo00j
XAGmhd0Nsf6VVTMhqjZdlRbN8hsCNmabhok2V1o0zGzrUOZBfWG1UZkKMC1UttqqbB2kcr+NynMB
poXK/bYq99urXN11EqtsCjCthq0hjJDCLSch6lNuX92KFrfOEGBata4g3tM6u06tT7euyMWTmwcy
xB+m4490ZYOcsF8tnOEPr07xNq4OyIYAHNOErXwt7YQG7kf6G54kJEalhBKKMsWiTAH4AFHaZ0Rp
B4nSC1EXhxmQgw8QZRSiRrkoSyzKEoAPEGUWoi5zUX2xqL4A3E5UOXps91ULURm4nSjzM85uHuTs
5err4FZl4Hai+p8xYP9QA+qfMaB+kCjj6GiRgVuLMsWiWoyrDNxalPUZt7AOEtX/TF/1W4ja3s/M
fvdF8IQoZCb2Jol0jUiw/ZmTy4SthD9maaq0rJR9duGyUNrugeEaQCGv7rBwDVBhu8yEv4Co9pxw
CawK1dw9CVoDKKlZcwq0BNRqgOKzkSWgXgMUnxgsAQ1h23ZPXtQAypLEp+1qgNtdULfXXwKbh6pp
NqvZb5R0sJrOoWo6NWqKz7CUgG5z+6xGYIv2Nf00WOlM7thmE93zHgv+E+7sPRT6WfZii/Q9FA+j
O0JjxPjxC8ho8SoMC3hImqWbRpmJA6VzixdhVN6jAdgB+Zbj4vyntqDMSVmzTG+Uw3hyuRENwvI2
WePvqUsxOvudxgX+GBVfPxamu2mdh+gj3bfbBGvbfWXvLpnHxF/huxLtmG3YRfZqHvd6vc5VRCl7
JQHe9NL3QeCLKCTrleC7p7zOdDQecN3f8KU6uFV4eTvFd70tFrhXCM+f8cbz9e3XARoPkoQXriSy
Al95w+zy8n/cPWtX48iO8zm/orbvh4ZzsOPyIwk5lz0TEuhmpnlMQnfPXS6H9SuJB8f2+BHgHn78
SirbeWBDAvTO7mWmIbGrpHpIKkmlUpmB47vxWsmzkM3whHsWT/AAMqZeqCkRhMFyoW/Hoy4beMkt
+zMLU+iRg39vWrIhq40Bfn7mFD+n3I00pZiyiDKt5PM5SyazwFvsScD6h8Ootfcbpj+h5kC5lEYg
SZ0Yhm3nFn7vNg5xhxSzaADQUR+WWWisG3s227GSyW6+o1uenFdkPd+HZTsz8w+Aphr6bsMLWQKt
xiPjmCwkXNlCXXlpYrJkLzJTzN1RV8hxTQeT19QWsMd/Lr1jO3nqhN3G3E3MMYiYMaZJEJlO6Bz8
/VjIFxi2PEsgjA4d/O2Ip+IUPlcV5XZP5DJjXNe01m0JEjNYMC8BDUK51zvKPW/tUYYd3w0m6fSA
q5jFjPLxHChlpcSOQ9+nVKHQ0Ni8K99cxpmLOSmAOzHDy4HSNbqtLkiKZOqNU/jKOTxRGrC+d9m3
o1GPffvUE/3KU7gUXDP2wyh6gFJf6QA+9mwSmxbmPVNpwjEzhyiUT2fjeNBHaZ0wk0Vhkkp8f5+z
jqq02w0rdrr56f9ix92HCV1/htk3ioQsRaaMJKOMBOPMB47HDBKm78NIA01iCo3G0dzFJBXAUZTv
VIQGlMXkhuXfpmZ0I15QyjjgXXpWFC4oTivK4nH51ZJ0gJ7Kdalg4KbjOAzStYCFoukunv6HMmXk
wtfAw1xX7BTIyZMuQH+kr0fSyeCoGL2LMxCeF6OmyvoAGScYJuMKnioaKEIXI/XXa0F0LWUPfukM
ZQ9fqoYUaGLKlBA4du6y3tffKQa0dFLtlXlW8P/ADmNKDhv5LiZAwGSS7M5Lp8zrKLoqB2EURI0E
uBaWX3rEfj0cCIgV7Zh5mAmEGjILMX1APrqYNgpYHCkGZoRhsZfleruxxIcg0G5hOtOklBe8QWr8
OZvheEL770u6XZ56yp1wNBgAWFsku5orMuj7wI669EsWSCowhraaNaGU/1lAmc1W0gJ1RRIhsQp4
QZQBAfQuRfZ0tAkcNoJJV6HSg8j9AETatH0zSZpUWvxWFuljVvKU5LlkKpgRU8poSiNLLJgzt7ss
pAL3TiS7GGNW/FyuQsFxsnnxaWbVFs4bsADccKegB01t4Oevo0Omygr7eBQA+9mu85F9xiQTS/S7
c/S5f7LLBoLEi6oLz4i5pU1WA+E5w6ymCjZsvbl1ZXEgsLOo/S3GZw+mN/EmAea/gxdBNrMAKa8D
4sDKMRHso9aVEas0LVIovjFliqYit2JEQxmfXFebGBHWD1jUUBVdZG6oq1BMICXZww7RoHBZIVrD
2ebdtXQpf+PMnoYJyGkKkqZvyNJAQ4xLALiAiw8ER628UpmInnfcFGRPZV+cSppQtUqaULU6CNvR
hLMFTTjb0kTVfDsb0ITzJppwCppQtTWaMKppwtmMJtRtaEKtpwm1libCFRHDZc4+nkduUCFezpfF
S7ZSDdZcXC9gOV6vdbImABukoSaZlcfoLOfA8j0LM6CViTxhHHJlRW7Ai5vI8+4XI0hJDhZ3kHCt
rsxT/3itx6sGAmYdvmIXCrtQ2QVnFxq7riv6HCckduIprMuKqvSALz+ADyAFRpghembes6+gADa5
pjF75mDk2FhhdurDJ20MdsPMmZlMpIEQ4kjH+uoz9dtl/fZK/Y6ob1R2qnKHYasRNJZGUJJwBOH3
NZE4l7hgb8qVmkSw2BNB5Uuh0OlL7sG8SEVqV7UO1ag/zBNrgY5ostHJ4GJIinKZztDKQE8L3ST4
CEpYGN/WQXppLtX1udTW5lKrnwvMdJFPBqawWJqNdj6bNJb6cxD2FxA6KxA6BYRyiLdZWHj9wpK/
aq0LEcSjvmEqy/rbCLvadpavOjXtxC2iV7WUZAzK53xafAy8ziIQmwb7ZEUJ2xmNQHuG1YhzDShR
yEGmYXIuUZO/ouZSqzcbn7KRgEmCWqNLTVOVlqr0RqCEy73eL3srFLWo0FINrqu63sGNZrDwkz2h
94Ou02VfDnvw4qz/G5rrERgvSlNTlzoG2CiUGv8wxrzPvRHAgk//2GP/9YV/W0aaL3HYrY6YDMze
v81c6ItWL7m+0PZZ6xavKQBNQKZlwPH0HxvQBR5STwgPut7gMs8HvzSC4gGOIrv4DdOV985G0Guj
kTgLUFeJY14vjabBVQkdPei3oqyZIk9fl+0AWPbpsKnud9gn73C3Asr32IOKF2C3oQXpYXK/cUWx
U/RujNwgwRzqCtNM/L3cR45l+wNpeH66nO6/mK7l+RJvcM5e7KNoHSlO3SKB4B5oaabz5GEhc3NF
ig0uzhnMxvHXXoMBrO4yRWxG6FiN4y8Vf2kVzeulKbbCEZ4xsM5J2qtEFWNYEIQfCQgqm7mCKXdK
5hNMqz5ld9BM1plWrWB3dY3dnfAuWFTRWSUiZFno//dBH/6pylFvOJIU5fTb90NlD8hIVnqHBn/K
vqKytg/Lh7rPW1vyr/osGxEF8Q24ZL3R1N6nFMSXpsi6Xm50PZtgC9nlYROIg7PLnFHWANUxylqx
WkapAfgOtI1+RMfiFSgq6DNCFcK0o8LbrtXustdvp9aAeHZT9UW0ZQCWEM4S+WFjDLAHNaSLV/UZ
siLRN0y5jCfOdUnhu6WSn+AZImcmOdjon4HOpmYq2+GscftHmMWB6TtlDnqZgRUxm3mpcKHM0Ztr
5NFPSePo90tNGifo0swCOkUMnJxbFORWIxc7PKeUypS5uPAhXfTZKHLNW3QrV3mMeMPrKPwmmS3v
GIsUZ1tEv4zcGDoMGohqKE3eMgwlt3/2gO9JKdmjosnUJH9nObQJVcRqXZamDyMF/X8nzXNS+gEd
KnYHTN8Vrl+C3GtgI80tysepfWPPQuwfbcMOL/tA0AG7g2EREnakPykE39kTt1VZCMYSPitYC1pu
+mY8K+6+wkz4M5B00z32oN3ugYKTZ3NnwTw2Z40kRspE9VmazWwxTkBNnfsm/GN3yIMxc+aOBIWZ
7TTjO3ZvNtGpq8JXx2RpbD6Ubt98gcudaMM8gTGIRlkFFo8XK2HJeSTe8mrQlpJQwjsAcJilKSxA
laSiFofxlkteXXwfHl5vDkSrA3J8vbKcrTa32OJJJoo4sfZc3xaFuSi8KoXrCqsF5LNwyXjq39Nl
ErRC4IUN/PnX6vOvtedf6410osl2d67JnLf+YDu/mEGGwY8qLIF44eduA0uU28R1grI2cOdp5edE
JPpKuLavlxvhWwvmGgjbBSa56RR+X3qTMNDYVQQCMwh3DvunRrvdAWkbu3OGHw2ON6fsYOuO7vFa
vWQX7PD+4nIUpasaXVXt2m63pXYtqxaVWVDIxed/oCAB6C2D7XAFlWj8pxyaiStdsqN8M2aX7XwH
NWGE6vwVXvVSB3n4uw2aVwJl6BBrfzoZHn3CGzlOT0By4Yfe6Bj/XI7ObTO64lUpGQQosH5v4js7
jf3icigAig/x7oerli5ZXnpdTgBof3cSpmmGmujYkmhW0P2FA7ZLF64cXPHWNWOnpyfnB1dlfEOZ
4gTegBJ2Ydq3bnpwhanu4dHJsHlyiZoUpuZPDq70Zud6i90Bz4G1sRAeaAedRykpQqe0z1MpQfRG
zrMS6s/QRFi59UOtq3GlL+MwwAq9APj5ZMDm0E+eg7x6guUa00MAKGnZWYlaebGlss3eCPSoIf50
2VyVW92iDQih8AluDND3YFXOTH81TTyCPIVBYSPQeDHOIN8KlGVSXXXWFdqVC6qwsCdIvX1SKz8Q
vE33pERUbjyBViiCCyByY6lCebJanEeGRVtbfX1nemlxxUdeFOQBCgr0YLljHL4EFu0AoyBIcuv1
GvqnnEDyTdE+7peJHzSgVzR0hfX7I1wf9JfWB61YHzzXdQVPkfc3Pyt+Mugefh1d4YWaXa6oGjDH
p68nA2DOzpiDieSCaYxXDF+vIAOt2L5m7Y66byj6M/aAju0Gu1mT21ppOK9BqbMH1oqt2AOaMAZy
e2CtZC8BYUXqGhJAYQOQhsLSKd1lUDnHOE+4ORv5buq+Ei4YEHjhkWPzVwKoqLVie8TuLL+TjqyQ
szCQ5iHyi1/eSF2EknBZa/hRt+RKEU6CbtUgXNvinQEl9LI0FC44bOKwB9xvxqCzJTK9HiEVQ32l
cO/Q5xyMKGIChDgLGLI0fscbLYpng/OzI5ksAnY8QtGFPoE9wa1gUrDctGicjM7ZfqulMLqPBJVC
oKNTz45DvF+H/RL6eEfSF7ouQasuPRyeXNxgpEWv0XMc7AzFZCm3LLkzI8TdnJtxE7/QL6BRDobM
ReyFePVHV+Li/oE06XK8RApxJ13DaCvt1i1r/FX3v8/wJoKJm/xIHLiWtBTlp3xpXv3L1bauaT9x
3uZtvc1BOvwEup3G1Z+Y8iMbVfxkaHUy9hMGqz1X7qX3/09/jl0LVWQOchpUh31Ms0Hn4WNpmv3r
duZPfAa2NYhgMBpksPIpGhPtdLmxQdVy2ZRit/QwdVm/DC1qhlHaxIoU4NmENR5vK2lW1mOSNDMD
IFa6NkSSYBmEAouVGcBYsQKG5xtadoww2fvC/AIiEuXFvRl55JSge1DEdjMZ3CQ48G0T1GfclJId
i16/ZYhX/XnfRAQMoY/MdPoGyCbdK3STwRogRucNsHCVxqHJ+73m+cWGvxlFMRA0A/ls0sbC4HN/
7abEN2ApP94UI1xmi6Mf6e0dqUJR3r5OKK6yj2gOfbx+ZyywbsVmvp0GWH4MeAude28F34sin4KQ
MU4RL4AFtbnppnYTZJgoVrCYlNixF6VJk2LBpZwy3oscNm/HX4Cy7Lo3tseT9+76MCOzpLjGssua
ieUFiEtcuoQUis7BWZoxbihrHMGVt6MCDGkY+kz6VSCbxCFq/8wXf98VYZbEAmk4T6S5bwaSlU0k
HGUzJuOOWrA+oO+AtMSZoMddktBrBJR8oFKYhSShJ1zyaA2T4K/k3tPtpI7rS2SaUruo5Mx8EG9R
/ZasQuRWvaSa+esCAMaq53dS5W/oTi5J9KA7vUOX08GHJw6nD9WVcV/uBp32B6BlBI7powcZSpKF
4lZhuskJK3ejg0IgWWhMQCUrlgCDhHo3mgGS5xQ17xOp4IYs80Dw5E6F01LBOBOvN5k4EbvaZR1F
lflv7NuX3hkb5S4AsJc67NAN2KfYdUHR/PuE/lo/g+GDFxCCZTTFbZD/3AZRz/fxarAkN5isBzYw
59C5kQxGDYVe/d0x5+5saZtlI/glQXXJy8Yf6cvjydnx+eOSzvZ/nP4+VBHgP59S4D8//BvRoJgL
UvIcMXv6YzimgG8xf0LpKVZdBna4sMJUTVU6HT621dehMR6FniOwiJsMnUL3KcYoYGKD7ucqLWhT
TK1KTMs0AXhWEL8OT7seTy7N3wNL57EsJhDFuZwH8L+7wYje7NFtgkQejNs2H7fGqqTYLUvSLcuQ
LMNQJd5STb09NkzLsl/XlP1VSlmmEaFMiPM28DM228p47Dpmq+NsI7ByX1jBukF5HGHmJXYWZgnt
074CIk3IW+Btq8WA5rL5rGNxDPzosm0r0qGYITZK2I74AAzHTeo6U9v3XDwzgxbO4GTUP/92NESy
yocf5lI1DHnpnyDuVnux395aw8Sfm4u6XRlKTerRVrCZAiSFnVpRssfwiBFzMjxP8h5ojjF6zM7D
adDTKyzHy9/Jp5h/G/6+hqr1w8ausz2m8+NjQCPim/ZBiWh1ZK4AdH17UMOj374ejS43avP20Hv9
X1/bzLOjyyujo2rXBTMVkHN7hHWBUByStWS34Klffy4jU24CfkOWeaGPFintMGJL/UPCpdU/cO9M
RMQ0va20ioAUebPW1TgnMMwl/TEW6w9ryV+CdGurtbol4iQbrG4g06X8h/yZQHzFd7YtIIoKo2aX
T4lutwZEy66Nl3m7ccKKdq2DaVeBQZaemdGVsa9xYLHzwH+gs9P5obcv5+cXh8i9eQTAf2wCs5C8
w4v+yjnCzIkw8CZISI6Io6XrbLAVwNT+AQDPjkdzXebMMu3b4tzqq5DEkS3jwUjnqgV6Gwzut+J8
pKzI+2yUh629CtQE1jBQ8ayHAE8junEMa1Xu91yr+yrw9IUVqiUGaoVhKmMI7V2+YeV7VjMYJ00q
2UxmdEJyGoZ4stTDs5HobM8A0ToVdqoa4N8luEf3RZzQLw43bVO1GE2G7+msq3+HF49sgx2poNCl
3cCJQpA/i9763q175yVuU8by2wN245p+acZz/ZpmQtJRJDA0bHTy6fJoePp6GH7Rmi0gLHowpYMw
AObV+Auqyicq2QpSGkbRi7P8fFdKGgspJcCrqm4/jRuR5wZz8Dry3HByq/tVufxsNyHPg9hoaCpB
FHL8zowDyrfw30FKyuBHlD0J01QM4WI2GKYWHjH34NmO705M+6GMtvEwcsndXUNXKSdz4FctTTVI
SroRxd0xUZCpSkduG3KnI+voMkYXkQSi3ujoqoJ636Y4EME+IMDPTJdVWY34z1zmRluRQjYCq2jg
2niiDqwao4MKwtfLPp6b32c7fOOeABZNASwRKFcU8coOKLYHd7q2aitBWSHPxU7onec7thk7e0yR
6b+/4bmHQRG7/D5I/HCPcbVNCDghOAreE77QGvfWtPu3IMrzFgjieQhsWnEpelxXtoUFugBqZxgF
22Uful3+AZoOFqXnkBuoUN32mDcJwnizts5bwJlXFFn7+PT1o/L4eGeiJyicXLOdobtbxOBjRYy0
2QRHwbxJlkQuOktczBXCCp1L19aAVC6xuP/9bEsxmAn07Jt/uXFY22qE8rTZRqVfIY/UksjDB1wj
ZannJ132fSn6bnTKIj+DxYL5c1KNrJW0NqtY1Gf6RZrdy/0qVFjEPxrmuBM26Lq2Ne64LUVVWvuP
yewGwySu2RkeTc8DAZfCCGDZyBuPui9MSYIZdGM6FfRAx1XoULtwrG/RCRLPL3fCsYgTdoQ5f+MG
813ogTJuadywO9xSjbzINcaMRbhXF1p/YJze+w/oBm2Zun4ECv01Oy7PhI0x6VThUnLCmQkEsENe
2AOQzurY7Bi6tN/RTEm3XUPqOPq+ZGpK2wXAiqJpu3/NqJY9+V4so+697UYUTPHx5AzUzbPel5uj
4fB8iHixv2CH73zwgRKo9CxKH6D/QDIfdtn1R7BH40TEpgOhYOIaPPYBFnzsMHSIpFksvKRZTGZC
/gpTw6BFvMkY1DFhcWx3jQOLQEpmjvFkCGdNPHHHkjVUWhWqtVgjdEG9NAMgqqYuiBYLGvdYfsqn
BUa/pZgdyxhbhto2H0kIZdF18fpqvcI1MOETrez92tp+XKPYPHJz0NXHjm7pHUdRLOtpMytrVbdV
//FBXrFLoatvQHyGodIJ6UGYLXDiwWqEakDuy6cUH3tFEjkAIr8BF63LJBi85BU7NFvh+hrcBmQ7
Lm1v4vGM2LOyFN6LiZPIFyZN57P/LVTR/AdisiMY3JsxMBEGDeFxjjVklebEdkt75rjzl9b2rdBU
CC/CsSa9lBrpVYnrRfZvKbRHL3TeGyx+s0iwkqtk0zC8RTsJc8oVO9IYTD11MbGfiLrLGwxLS9s1
dF13nXar/VRqvCOualnzbzixldrze8fIFrLvPDL/zNyhO+4qrVabj3lHcloul1zDbUnm/v7+/7B3
rc1tG0s2n/0rprIfLFaZFN4AqVLtlWUrq4rl6EpKynsdFwoEQQrXfIUPW9r4/vftHgAkSA6AmQFA
Ko5o60UCfRrz7Jnp0900LU81HKPnwwQGN07Dfuqmnm9YpoLpytq21dR1y2zqttlv9kzL6jqG43Tt
APem0065JR637EAqgvWamteg+/XlBWkrqm5aAcBYYM7Z/Z7XNPs0fbDWVU3FazsYiImeM6c48lAt
eBxWpn5FHHSFJBc46ArJknPQlSoIYQddIRQ5B93SEFsOukz/3NIg+f65FYnP8s8VEp/pVkE3lAVq
IOVYIXor1zmx0FPV6HVckx4HgBQ+v62mYXF5HVcBJeR1XBJQzutYcFSOFktxnBx1P6jPvs778DP1
+4bqeJ4Dho7Va9ptU2l2Dd1qKoHZM+Av2/cdnkp8dhf+LqqxIhfI4pk660bmeQDnPM28tyqPOB7p
XB5xbEHoEWfbSru0R1ydJcjtEWe3MzzisrTbv0dcbZocBFTcohLRpORuY21QO7uNVSIV7jbmHl1m
bc0ZhkmW4/CheXN9/u368qKV0skNp+Smo6kwVju9nmb3rW8o7hM5g45Hs4B8DofwPL1hQKIuSeaL
JZ6rbvvbHEw33G/48hS1Q4J42B0+0hzvC7oRCVWKG3QgZBzQbZJtNZlUx0UwmiJVCzcaA5r0AcP9
/XuJW1bTwQwjYJzgUWZy3arvzoI/luHWnqPRUZh++yNcbaN7XofcYe6IJEh2dFa7cuFb+4tSX75X
ZD5B6NjtIJovsnCZM/QDDitRmoTb2G8osdrQHWn18fEHjFmJv7Wmj6TZp/CCAL9S9S5gurzG8/vY
j3IerzI6RFDcx7ezGTy79ome+Sz9exoLEGMvrk67BSWiHKheGosQt3NX0cma8aZUnKsm+nxLOLuJ
r4W/i2KlxDvlUTwANPvimqbxCkPM0qPa63CHGxBs78R0DaaUx7LYvF1jeo+l6wf9PFN79CgrlRZG
UNq7Ce58ze+D4XDzTp15QpS4kZQN1GxIgm3ubWaFnRWTLRjaSkA4bxQsAZEyAbPqKI50bC0B+Vxh
uDblMVtwujgqDawlgi0Sg2tTbq5/ZTXhtkoBMiNzlZLIEwHrKQGkwnk9JbUEg4RtSmZOrOhjgUGC
hzgRNOPIwZFtRN68/e3y/O0p4JCz87vLX96fwvidFmpluMakPSbRIwoedIwpRCKWy/nZuyOlAVbR
AsbxJYzbG92jnWF7oTc87lJ8dBwVl+PzDUd3mnYvmqNnQXfL6gGRzFFp+ri4x9iz129vLq5+eY8H
ulAfYDiEg3EU0LiJDnjbxBEQxxwYaneyEQQu5WQjiFXqbFgQS2YHusY9uyztK9t6PYDuNWw41Am1
ueFQMVL+hgOA5foCCftKg25BiCsEHHmgjffAfGhRL+I4qhuNvs6jQjK000VMQsHJWiu0MxZe6aGc
UiTiAZEGjEjGSR5BIhwrIRlMjlWBhAKOlRB+LseqSBIHpafoUXI4Vlm37nAQtye+V2Q5bs5Sju44
X8Q1vz1NMBGYHN6krFkc3nbG2jyxfH6OSBzJbHU0nU38RvLQ2ypxSoLlfIAJOeEZwUbzWA/H3Gsq
6AKa2tHZJkxhlMbMWw8epVFUM54ojaIyK4nSKFzE3E5gopLznMBEZUk4gckWhJgTmCiKhBNYFRDF
URqrQMnxAqtOPNMLTFR8Xf5S9elxAEix0z1RPUr4S1UExe8vVR5QwnOpGtAn7Pbyd/BcyqzEZ8+l
76Iaqw68WQhUMvBmQXuUjN7oO/2+6snBlIzeKIBUKnqjAE6J6I0CKHVHbxRQpXT0xsJWLxy9kVci
b/TGyqwblgditvAC10W8kRlYgMPxLvPeSlwXUTqTbV1txEZpGPGIjQhVX/BDTunFrp6ZgtDV01JM
rZyrZ6Z4zhZXTfBDGLZslqtnjnZ7dvWsU5ODgIovBisJfsgliCf4IZegqGOgk4MbRhvC2B1oSldV
WBgGRZksMKQO9fvDr69fw2ibDc+cvyvlisNGZopJwkZaqmUJho1EmZWGjRQWWBQ2UkqgaNjITJDU
QYhm6DxhI/lFSYWN5BdfU9hIVEAybGTRrRzB5wrRZePy8Qlmx+XLvLeeiHgIxzx2WkfEayusiHiW
1dI0p6WjCaWlYuIZhqba6lZMvFwUhDCqiIlXiGLyxMTjklI2Jl4ZEJ6YeGXkP4jExOMC4oyJxyWr
REw8Lvl9dJWneZfXAUx6WJ3owXl9lTr6oyPeYnoMyvQXmzAGc/1YYei9TIyi0HtbixODueasLfRe
JmLNXAfEZfoO7jjl+bFvwgQTObfoPNqBYUZV8UQyoYjMgj4MGr0GjXm2et4PZ9eXiQ/cFjbTIbCi
QICmEig9z4Oua/u1BQLEh2C6OcnEJVPyY6j1LVP3en3Ha9ttmRhqVeqqtTNjqGmaZvtB2/QUTZOO
oZapa93unaLAZdw7RbHKuHeKYj0t985M7f8C7p2iJV/CvbNWqA33zqqRct07RWv/7c3NN5j9PgeP
5Met8zc0ipLjujgI549RPf8ITX24HI03ju+2lGCT4oqomapdcbw5MOXavuEonhP09xxvDkuBaSpW
RY4EAJNpwMmRI3nEiZEjeSTy8xcNlcFf1LKyVqzYF7Zj2ULsCxCpMbWWY1/wiwMD8SaI5mLK+p3M
vFk4fCTL8YoyKiX3bgZjDNpq5GiE0yI6bKM9D42fBuFtbDYDbrmEXGDl/8iwiaYwsI0m4x9f0Umd
tHVYC0It/jf1iJv5sG5Gk+aoUTew40TA1IDClz/CcMvwHa1zZH5/OYI/Rt7DMBhLarM28F+Rl0UV
+HIHJOO0r2bTTRC4lOkmiFXKdBPEemKmW5b2fwXTTbDky5hudUJtmm4VI+WbbgDG3GDYHzMnUwUR
Zk6mkPQWGQ8zJ1sbfmaOmAwWM6dIQj4zRww/j5lTKKmYmVP4KNnMHLyVuQO1c8wjy8zJRBBl5mQK
EmbmCEgqYOagJOZRaVEXMDKix3Awc7JuPTwzR1AzLmaOoMxqmDmiRczPzBGUnMvMEZQlw8yRLAhB
Zo4gigwzpwIIDmZOBSh5zJzKxLOZOYLia2Pm1KbHASAFnbEE9SjDzKkGSoCZUxpQhplTCegTpnX8
LZg5WZX4zMz5jqpRktDS1RX4LgdTltDCj1SO0MKPU4bQwo9SO6GFX5XyhJaqplwm6yNLeOVktCKg
smS0IvnitB9Oidy0n8x6LGLmmBlxvnh4Eln3VsM0AenMXcqKmTmyMBLMHDMjAFpl5cUhnYOZkyUo
YuYYdklmTpZ4zhZX8Ix8zByYuhWHyczJ1m7fzJwaNTkIqOBiMEsTYWYOjyAuZg6PIG7yC48wEfLL
X145DmZOlpgUM0cVZeZkyZRm5ogKLGTmyAgUZuZkgaQPQnSHi5nDLUqOmcMtvi5mjpkR15CDmVNw
Kw8zpwhdmpnDJTiDmZN1b03MHDMj0uKameOYQswcve042jYzJw8FIdqVMHMKUCjFqJiZwyOlNDOn
BAgXM6eE/AchZg4PEC8zh0dWGWYOj/wKmDlmRgDJKpk5WRhCzBwzK3lEbcycLMS6mTlmRtjLfTBz
zI7KdnGthpnTgwG62273NR8ZInUxc+AhcklcsjQc0+6rPc2zfMXypGg4WYpVS8NpG5YRmF0Pvuvy
NBzQlRm4pHZfTkHgUr6cglilfDkFsZ6YL2eW9n8FX07Bki/jy1kn1KYvZ8VI+b6cgrVfDw0HlMh1
KM2m4RgV03D0drdvd7u645m9fdNwTFxUsEqhKhoOB4AIDYdDnCANh0MiPw1Ht1k0HDOL8SWTB4xH
GjsPmOZkeGymFwGCCV60NogVlakpsHp2WpbZ0u21XO3FD3+H1xzWWAEURAuMiLow6Gm5ovwQnfBv
/1Rt2zJ+UFVbtQ1bMXV4X9VUTfmBKHUplH4tcYgj5AccKfKuK/r8L/r6qEFpK5pq36k4BXWgIyi2
869vvaC7HGQsjvFdGLdgEp7G+bxwRsAkm3Bpr0l9BKLJ/bStwXD2c/j6BROnLYKz2keM3beH6U2T
pBlH+/6YLdWNLTDcXVJ24A2Ab6uF8JPp/BMuJsBeU6J8n14PLluEc5yBYOk2HE4APcpbd4I0vbA7
ox7liXUT78edwv2sYjD1lm4oIsVwg7sioAg9kYif+hgU8cZgFUWgx2Cve3bP6zc9y/aa8Eu36Xla
t9lrK1rgW0FPaWsVqII1AJMYOV7pAW8fzyIF96VTDLOqrejEzsVG6PZnAZh70dIx2YzAv6E6Mhum
BORisvCG7oymNcOKHniwqkl2NXG7ir7xEt4Jx/0qAO8QEDfYQjSn4Nf4GSe4H9zDk4fQd0ch3Vk1
HccxFdr6TnBbdEi9zdIq4ua09wXb7HKMDTqa7+kdjSq0vfIewhHMqNMJrGQxfRxWS6Jy2CfeOodw
tG6frzsWWvUwRe88U9u2VauS5rKczSKzFftUrBjFsEGwQUuBHHkhzbOHfS5pOI2TE6p5vNUAg9Mg
WGDGX5ox7wQEfg2wOrwkG7HXowNIfOEJBUOh03tvHlTxKBcrnW8VcqOQO9WyzbbuOCdQmXe2rSiG
Q87in1cKef3wpQrYD34rKgMXGtbIe8Dyo0PmqULgz1PTNgzLIEdfvflp02C0KAMg82ecijucOKB4
h3Mq63Di2tbU4TSjCuWyO1yEkdPhktP5pMwIiFwO7vP7YXwxXXaye5r4M1yslGX1tLjBn8U/aU97
qASWrkBpZnMst6RgyKQfV26HTKZBTP4JR6vqR5sIiiYp+XTdDqGcF5iCNWkBUX7PqFVUoXP8d9L6
ol19WMVHFkPrnNZoNFGDknN3BCvkeMo+cl8Rd6tD0IhiLdUUslMkLNQERzuMhUpDw7QM3araMlR7
bcfXlW5TAfO36fTBHtODLthjjmEFjuE5puGxVbFrswzr0qlSyzCBFGv9tS0d5NQpMW8mgPlLtnLz
pmpatlXJvCmnbR3zpmY42+saOeWy501La+vxTLBvQ1XuUS5WOq+mT8sBu9TgNVTlYEsZqghptYyC
CaHiDicOKNzhHKOyDieubT0drq0wZlNx5XIMVYqxX0NV7hkuVsqyehqHoSoJe1BDVU7nqg1V9Atq
OY6QBSdjqEY4bfNAhip6fbQcS2jHmMdQ9bqG2bdNtdnra+2mY5hms2tZvaZnG2YQ9Po+rAEqUEXI
UK1Lp2oNVSnI+gzVWB2xqbrMvCkFKD5vVrPBI6dtXfOmUYVy+Yaq5hzGUJV6lIuVzrKGqhRsOUMV
3VlaoOU+OxwC1rmjCvXQrmhlKKVtTR1O3V4ZSimXb6iq2p4NValnuFgpK2uoysEe1lCV0rm8oZo+
/0eP9hpdP+gr3/9DM1TNXPt/aPYPiqrYlvns/7GP145fht0ynQK/jOE0+EQuY8c/jOOx693BIeV+
sZh+Im+h+Lsg5R4Hp1/H4UMy7MTsJhxkaJSrtev8l92D30I8NdY68R7EgMroeN8EU7tHHRojB8fd
Iw+tpeYu4nSYcsKH5s31efJIyfLmT+iii/sJBjG+/uX27oQsZyH8fnxC4HPouafkIyGfTijdHkYR
dxiMB7DiwrdV3cRPKLmxD6UQjP0JJX6ekhPyJSYr0qkPb598DgN62ym9yZt/ptfNl1383YWhCP+M
YZqLx2lA30AOoOsNcAA7pV6Ex2qrTf7DLoI8cyJdBDCe0DXlJ1ptp1UJi8uUso7cpADeVyd9Pp3A
tTCKHoFEpQXDkMr0fdDsvJMno462YKr2E2oLWAR5flOGSFuQE7ZqCx6GbHODyIQkf8a/uOG4c3uE
81/jZG1f4rt/xvN1ckv6MqSqwd9o2QzRkGqcIE8T3oEaV5TGSewIDW8sZsug8Z/soskka20+DZTx
J3K2wNjji5jSTZ+HvESdXpLksahZGRkgn4PHVtlCpLDvQh+vo57InShCwEOK00I/zH6+TFf0FFAs
ZA2Fz5a4fyee1LHxSR3LhymVsh9SpGx/QmJvtE+xVaSDGWVvRoivyNf70L8n4yDo0TgP3SApc+pk
TXSF9LzHeemS3x1sVi0W1rOrthizFOb0zY+3RxhHqHFye/TPyS3+uL33cAcIt7Cgu+I715MJTmD4
65UHD3w/GePva5Yc/nUJ/X04DM/RhG98SvcLhPlz/nnp4liw0iIeV+BvC+mt0P6DGcz24+WoG8zg
XXiDEvOwz6jQV2aT3tJfYNhq+mHwMA3BeKajqaboqnOHoWbw/78aJ7T44bPxpHGCJHl6hz8ZTb3x
I/097o5q+g8tuipcRJcg0TC6EWxyWEmukP3JcryYxRfBU428GagJ5ePGUOfhYgZWxockplXjBJmD
s9CHeSUKQ+XGLLIhfVLa3dfXDL3u7pugwSBgvU0rCWrnc+6H7jxcBC4SRkCfx91LvwZddx4M+wmB
vugCNwrzO8scrNodxWxZBZ4c2GQ/IeM1oWLGIbtPCCZumMzoctKHdfcYYxLRlrbTSQSAkr3v2zNC
yaO4JmOMBXwSqa0XR7cOHvxgGi3gxoQS8ty5h+FTg5MVGA5D+BFMihnANANfyzKNUqZxLMUqcKao
zDTmwZMzjWmau5aZ68L9nZvGokWQaw7JC+MxjctILzaNo+N4Pfc4vhbTWNdt7Qk1BpEyKGwMZoEj
7lOyjZ+th+/Yekg94dCj7cIbztNv/zGZM96dglnqeosF3TRO9GVcNw4W0FZ3waAhe8PJIPR3P5pG
Fu9aWEA3Wd2He48BMIqNYsZHwQjD7HrDgJ6G7wLdh6g3Boh3Y5sHd14ZJThkVOsMJtHdd3sjxps0
QBgNasT4bLqkjGWmgv7KyF8/3XToLVBVF6yYxUY1DpZDbwYteeD2QixbRg2Ppox6D6PFA02pwCjF
wXTJeM61nIKlc2qw2+fSWXyMlVw6J0CHWDqnsQXK9i1GHUktnBME6hESjc6R3RwP0PadpscDNIEb
hzQaZdDvQ9PMVuh52Vw48aXK9XniO/iymWYYa7XbBdyD8stmESC+ZXMikedgp9plM3VPM4v4GkXL
5kiKVcDGqG7ZzIEnuWymDiGqlVce3/uyWbAI8ldK0sK4ls0lpHMsmyPnICVvL+u7XzYLlgFHY3AU
8TX4d7lsfrYenpfNz8vm73bZvB7s9rpsFh5jZZfNqefb+7JZrmwlls0a57K5xMz2t1w2a88T3wGX
zYd2anx+cb+6mD6gZgfgfP9fRTHtVPw3DeO/qZpmPPv/7uO1jp2o6hmhJzFDkuloerkMSegwxQzN
iOJtW2mXTMCkdvRM7S1oVjXldyqTPurQdY8vDFN/2P6vGqatpvq/HvX/Z///vbw2+z8zPH6SyWAx
0OOccT6YVpgzLpz9gQkw2uQIvjUot+jq9vIYvpofXlQh2UHJTh2SbZRs1yHZQslWHZJNlGyWkFxV
aspCoJKpKQvlC6em5JXIm5oS5e0hj6M0jHgeR4TKTWQimjNMWGBRzjApgaI5w5BMxLQj6sn6RLlL
Mulj9LQQo6PnJlNbzrtEa6otu0PGwVdyHw7uCYiFIvr19nXS9KOMzMG9H7r3fo+2k3g1TAxJsI00
iOS/VMxDNoehJkrViX8BsKBsf4IR/2frWsYnWudMisIUkGHYXc6X3lBEeHL++H/04BAK5sqDZ7+N
Vs6x4FarJSISsxIaYALent9ekmC0HMbbUdD5dgFoNcxrKQ64sBlvAYjI39ExachrPKHiSKmxGnH7
NLUpjIWijWwt6asXnYFjscZSF5g4ZbEYBqQbwNvBKgXPFkhugjesPWJ0FPqPvKHh+ptnNAw+wRdl
mIR+k1xhMqTmuTfrkehFOenX/+wQhZy9v73En+fnt0LYvTXyWXwcECk0iFDJHMwEetimbMnNHb7S
cj/Oe/4nYjta24TFjanCCPa4wLRmA9y7J93hxP8875AjA5/mp9fHesvWyU9IqS8FiC4LAbmeTcC0
WNDJqd8vJ/EKJmdyG9BtTgWNp+h/OaFn8/mSOmvQPkSibfzIEwKP9pEnLwLAavvYKDEHDsz6i+2O
eVhtMdkpwvjqk1KLAZD0DTrEzoLR5EtEuA83krwgb4S5+5BI/jnKjJekUjoC289vEKiw6XRrkOOX
lIRXgoESyoBS0TYSNKkdvZ4Fl7zkogWXvOSiBZe85KIFl7zkogVXoeSqFlyFQCUXXIXyhRdcvBJ5
F1woj5mlqdoFlzSM+IILoSpdcAkLLEzSLCNQOEkzgOSOpxWn2UVGXOl8nXpG6iLh2URAUtFsYnRM
ZmbN8rOJtOTC2URacuFsIi25cDaRllw4mxRJrmw2KQIqO5sUyRefTTglcs8mZkfZw/adNIzEbJJ1
QCU9m4gKLJxNZAQKzyb7T9oumf350Ac/8eth2OqNgvmgtXio7XiLnv8ZRtb5n2bZSnz+Z9mGpmL+
N8W0ns//9vE6+vD2fYO89nokTtd4SiYR7ePlyxfEdQn9Wr9c+j/65pIX5Hfy+zE5duEiN7ryG/kG
/wk5hm/w9YLAJeT4GD7+nbzEb/EVLv7Efy/wWnzfdY+T96gkl15Grzh2j393fwcU+jd8IZD77cht
uPiFMgpeL6IH/QAzZeLgDuMKjCxHWLH/CMCYuv+jtfJJxCmtQY4Gvr9xuUY0RXEUGwayoxsYov4H
9y3x/aZhNRrkbonbUFOi6kRVOyY6oZG3b+7Q30+NFXgHQ858Qc5piN/bYNHBiJVfvHCIuxbxNa9B
oyEm+Zx1yO3/3r67fP/rB4BREF1Vmord1NTkgc5TmaA7yHRRMNbfqW1qV2A0foXf3WAUzAbB2H+k
HsCn6hXxZ978PhqiTi3j6h86XLyq/i8D7xSny6byoOgrvX8Le8GEOkPORnQTuxN/QH776QynqMHM
m96HfjTVEstQHgxHeUVUi3Sn09W1r98ev3lzHlMX5h0ynoyDEyijyzdrNgJGm8Yd0yR1aXwvvQgV
iDLRB4tZCIMqWCeB78GwjOnnUXT8AY0oSvkRvQD3GYNeLOcNmATM57igG9EauXp9Q+bhYBw5Rm5/
+vbNm/TdmC506aevhBbWDBxNITdnV2TkTVfyla0Xaabfagc+hjFd0nzCDcY90QUb93hUzFESLZx1
V7CDpCqFd6nb+nX7Jga5zdZvdcHmPV4+0uqSjbt8k951dn59Sd7/dsu6K7pk865gfRdmwGXeFuzc
1ncKVYwu+X/2rr05cSTJ70epm/uj3RMtRu8HF7MR2OBuYozNgtvXexMdipJUsrkGxCLhtjf6w19m
6YGwJSwworW3dke0MarHT1lZWVmVWZmbtawXiBEXyNfRReulnpIiG7Uk9SViJEU2ainui33FRTZq
Gf6LfcVF8rVM/ruUFj7zpCc9wVequB2f78e/17Wk9FF5rXWRrJaqlOD7w1vNFm2QUoNTcqJrmqJ/
O32PGr34IMdVk4JIDFBKx90htnkuqhrINIxZCjhk0rnojP/ovN8o+2UMAv/0XDvTYJnAstoZlJWS
srgUdciA9Amojwb0ZZHOoB/bjOAVlM22zuEXb6srSSa2dY79qnu11c1wSRq0ZZyfdnPvkGsr/hFJ
//L6Apc7TQLd7BmuMbSli6fnJn9HdZNenWH/LMYtS/y5IUNfyl64xynurmwiDSRRjuk56J8NP/Na
w9HVWYpbgq31+TUhSswTm20Nzs4/xm0pFselvDA2cVv8x3pCg07nPMGldHlbXSXf1lVvwEtUauvT
sJe0pXb4OCvmizzTSt9YfTLOg84oaavHcZ2KxW2l9OLjnP6VtjWOc4nDGtaGJVzRdZwoaZY7mCvp
YhrfrL1jdJHmI+dpAwAE+T7xojvYVxHYV4UbEBX5N139EnNR6mIAO/UZplvHTdZ5B4ZcICgRUcD8
Jj75+ZD4Kihy0uxwGaBRFvbE/ykSHT19OAemmpssPS8nVyynViynbyvXv8Lv/8Tk43QxcW1MtfAh
K6bIHzIyiA8+rvP8JT+O+0QUZCVppIe3tfC1eR+oZbVBLZnSCDjhM6cHjOVvV/xxSu9rbgsD7QxV
Jm5p/490gPnlgzj2NW8w8RR4kDlCd7rCXXgrKR23H2KF1ZSrpYMhOVvijRIyTr8lJy7/JmOORPGC
F7TklqaLZPDpn3gqE9MsbZu7XWTJJEh4R5f8aDN9GsF++eZa8Mh4HgQLUHjjUxF8o/gCm1dQFhhT
5Fw4pGGYGBpfqPK3FVsB2P4cdMeJF2t35aXx43K5WkRkxEDLW3DfmdLS8T0a0hteE7yczsJCLDB4
95NltMJJtNF/utIJ8XvFYz9iU/qQPevFJYnHvRSwr6t+ksEl4CNK3W92MMXDo5QFepedU9hbfAT2
FDgL9Ed/y/Rd4a/JoGOdztkfiTadMn5yWY7r6ktkMEltKZKJA4zCLJ3uWSj+ZHdBlrxJH8XCH5PT
9M1vBl/a6YkmJh3x7vHCoEfS20ntNQE40MGgf0Vo7IixSbEnBa+HI2QoL/i+ftB7iNgcjzWH6NFy
HQ/HCQzN+3WZm7hRYT3B+x6bRxN/AnOWnNwM+93npcnloL/+cjAeJYMhJEhBDgKnrEt8nqdXagDM
R7x/nA4MsEly5hQSGSQv/AFUXgDelGKfbkAwd8b9bviUi/gTIOgT3uFff6JL7ztwIprl8ZSN04Bb
59OpilvJJw2e8skT4ZGnSmDJzWQLiy+7wVuT7yi6veCWCIKAZUAMB9/oY4t/lnKf5dxnJfmctPfr
r7+Si6tOFzmyezXo9C9BCYEvU4Lh1j07V9NVPK77QKah84F7UNAoWw3iSZKWjA/2PpBhp5cUX6Cw
BUmbbnP+Cp81X1srfcNPfx/3zzoXZNAbXI3+TjqjUefyY2/Qu7xub/TBMyG02iSnI7P4t/DXtYqc
Kq6SqRuSyocxCzSbTpCMm1AatsiSztCBoZ1TZCWN5tvNVNt0CvVH15+3Q77AIwUvI0wK0E005zVk
V9wgRwmmrFi+oms5uYrDu8dQGFBY1XEjTJ4Wy1f0NCNXkQfV4PvsNslRNy32pKLqqFmPOKdjEdt+
UtF8WlHXcz3imQts5kFKPu2RF9usmId6fXXduWhn50zrYk8ZwU02KNl5xuU1DlS3O+qNx8+HY61h
ieSOhpj4hacgUclNbhKO3eXKcXAanmMCC66vtRr74wXzTILhdI54IGZn5fsgVtvos5MXWePIawHT
3k7ZPfJrb7kMQPiihEoO8VMicNmZK3kZRDz4y8kIppbAE3Lg5d+CBt7nZM+Y3zkFplusIhQKIINg
0nIPu3dn16MLgb7jIV0YX/T4DI5vcCZV4G94p7RFHA4PNEDYWHLNOFFv0re3bZdrU/Y9XlSHBYJf
61xGbe62yEVyMAP5BwMf3TFQmib3kym7xQWeq9wHMx9k5/+x4tcC6rTuI8FrpavAAewCyM5bzv8V
WVzn/zBE/S+ipMuq9Hb+f4yft/P/t/P/t/P/9Qm/svX8X/n3PP+XU8hl+LIC+TrySz1lRda11Jd6
ygrk67zYk/q8J4N6hr6tp6zARh1XFrcekmdFNms561qF1omszEY1X9v+WlmRzVovvZb/7LWYqL/U
U1Jko9ZL1omsyEatl6wTWZGNWi9ZJ7IiuVpO/LucFk5iHsjV8WlSp9w68XNtGobPCt+qbpuG0eme
yQeyaWBbHW6HeL1Ng+NKbBrnp6+zaRid3labBsctx/SyzNfZNOK2erFNQ3+dTYO3pZwfxKbB21KV
g9g0eFuaeBCbRtyWynH1StrawaYhW4lNI84zub9N40HODuRRD6JTjC71mJ6iofPkaf9q3Np4oYoW
EJS6bxaQzALSIGuGDjzwZs14s2a8WTPerBn/f60ZaqJ/rg+xVTlVWV9jzTB844k1I1Vq36wZb9aM
fxFrxpsxo3HGjLefnX8e2Py3uvtAAWBoWon9J/4sSbqi6IYuiRj/TVQ09S9EqxsY/vyb23/WFo/6
ggDiAJfF/5NhzYVBT+1/kiyqeP9HNuQ3+98xfp4mNVbMlqZsza6a5DWx/8mWwY/4qc0XhW7b0zRJ
l0xDg38/kvjlX+OMEX+mG+MwWvErcJi/4euznMqH695bzWaP2PUdm8J+I4FRhAJqap6qiYbnMUsx
COz7+S7PeYzrbDZcDHlrYp09KfYFNn1k3Bvd9EZkfN0ZXcNeooRiB+m+mGJFKKCmTz3qWVTymafU
TLEKCH488ADswdwO+SGfjWGNf8dw1IQnVFiiZXNG8RDoeOM3pEt+5jCZ491PPA3CUPPFI7g1Dd0r
R7AYB9SlmmX6ugn1/b24/jCgi+REkgWK8Nwp3GLm0LCMdNtyyR1CXBSDgQZ0x3Ak1WeSqOt70a86
8upAfvCnnvMV9hAbxdbprniJlueA+s3C+buIJElspo+EYQqDFj+WnMxX/OTyDfnLyGPxc0dbdDlj
mJLpHc/28Y6cADt4zKerafT+iHhgi30XOVP7YTb9iiS5j1O1EC/yfsZ45gjD6VKMQalBmuApEQLt
fjobkikDkGGJFDlI78VSpAAEVHR8lxkONQ2X7Sc91C3ZSTYRvwyAc7C98u7chVeQAhDT6LXwP5vh
ucOJLH4gvwQLNv8Ffq+nJ1YX4vZhkv7ynkyTjsuKtOMXxyIYtxIz0zymAFOuKn35gzPLiMVoUWVA
76Mli0qY5SC9FzNLAQicVzqVFVM0fMvcS92qhV4XSXgjHNjMloccWUI1rc4pVgIF+dzSJVeXmGia
zl60q467KoxkwRjzxjbD5LaPjCFJppOmQGwTnoLnJ4FwlhSDpWTpco4Mw1lNpp6dpB0isCPU5cWR
Idzd8iAxtyxE39Ajd57xgNRSapzCT8TIGaZx41lxE2N4fCpcIkT0+oRICRCklaZbqqU7smnsJ0L0
ymt1NRDJgKG/L1mtJt7aeyS2kmdbPUHIDuGBDPHxe4D213s6XZWsrdVJ/C8FtjpHjhMQ3A14SnhG
X5gaJRxp1MeRJUCgsus6ime5qqx4/l4ceRDUJXRbLVJGiEMtRhiB+xt7/IkULIUEzVi+ZRigBou+
6+1Fy9rOS9N9Fi6LwYzEK1McAZzCG5SQs8bTwCqooCXDU0RHNWAj6Kv7UHR7vvB91fsVjwBPkq8J
Tx9aTMLD9F+i4BfBwPNMUXF9U9V0Vd2PZluzo29grgIhEdqnkzkFyUwXC0aXqaOHGyzRFWj6iNdO
vrHiM4Ud8OyyRYvDA/KU9yOymK5AvykRK1qNW/piHFCXuY5vMl2URd3aaxSrg66E4Uc4s9kDc2Gz
kWRASPy4cL39LVhEuTys4YzHlRwP0raKEBpGdfGyK8JRKx9/Ea9GfZsH3+frqIyPpHN9Neif2cPO
53HvWPC+5qNSJp6lvS/XAM+DT5jpk7CHqBRNRcVvV2Klo8ShhJm74Qk+XkXxzYBnkKyWuIOto4bx
G4/s8VnnspnIOtfXnbNPzcTW7R0TWxHL98dXeZafhEEpmrpZHqFUZHlNbJly9ePt1xDobHzxMU8h
N5zeluKpm0QcTFUaSS1Jr761f5Xc/Bv6deYlJyasL0VUu+zkcKqTSd5Fyzry6sfhHV59KBrFczQg
5wYRDcqleOoeQw6m+hAqcvWz8HpE+RkI8v7lxwaCe4m/6oBXxF+X5+M8e83956poiqZu7kIoOzCX
dRwCfTrt5Al059BSNHUTCKFUJ5BmHGct7uK2LU8ivo8rRVQ3kWI41cmky83dZdUEr2gUL24GwRNW
n97PghJ256jqHskU0g5jaR2H5fs8BdqGhu6Gk1JE9evoCKc6mYwdzi1fQ6aVx+7zVMK/S/HUTSQO
pjqNTKO6ueNV6y9sNofDjSWYRXTx3BiaYqp9FY4BVaeUtcOh/E8QoHXAKxOgz+QCitBS2cCRHUOI
7iYf5JYoNnhE64FXMqJPxrIUzRFGcdfx4+5jB4d0ibcd0+Ptta/Z+jwb0wexucev5aWH3+hCGl9c
R8/R1w7pnoY9wAaPowLX5sP1X8GSl8LghmVNNH1q6b4s72rA2JHxqkD4keTMtSezxRRHmoRpLmpe
ehKSBXqt8PvfwJN89JerecIBcdmW5/zX2tPQmdL5t3L3wtoGPs/Ud1G02OJXwDHUaMYthYK3AmRN
FVVGDapJezFAHXcp8oDjexxCMJ8+NomOpbCgKVOTqaJR36Pyzu6btdH0AqFzkbmaTx5IGICMLHB4
xf6lGu3hhTCwqmx4omJorqpq+9AMMVf1j64AIXXZXPHwF5jv75E4PChgUjwK2uTzZf9LbgHC/2qk
Z+l4csf7uyAsG80ab8wUgEBvMFGRdNGhpi/ufNMoRbzzWJYBqDSSfdhxYNJOdIZtSW3zuUfs4ShZ
5g/5qbPpGnz80SyFgl5ToIpR13WYZLn7jml9tEPFbx7MBQAOynMgTIPbEvIdxE3lBfIVoIEWZFOl
oGpIlmfstSocBvpzH77VgnRPK7FejR42xTigrqKIhuEzyfXozh42O4KuhCF1YU9uWXpOUrrEKAYI
djCi7ILgz9zOB3Vj0HqLh62m/nkgr3lg8xglx+w4jsbbfpgV2JHr6zWL2mxHd5OQ3zhu443j12Ko
PlX5n6lza3oHj81hq1yynzwMiuL5ugUMNCDpzMeQi7Ct2PmyG0e+g5t3ZSDJQHY8L72AlpXnxxht
8i4EDQE44F2jQNFVdNcsROHK+V/mRs0ChZf+m4UIub1ZiHha6mZBwouPzUNkL/DCSrNw3Qyahsee
YfR9N2wcrluMqtZUdMNh0xDZdLGYTjBsabOQdUd282QoHjE0D5HNk3xgTPgGYmugMOW4Gikg4tFc
rJqFas6i78GyYVPxpn/eOEDNZKph0yg1bCqlToO51yxENxedy2YhGjdMEx2PmoXnpttvGKDTbuMA
NXP6D5tGqYbqdTfXw4YJgSRLQ7NAraCvZiHCL+z4BnCzgDnTwGkWohkLQ3rbMDLFMcKahSmOrluC
aYdoHwcV5Gdla/DPAvRx+LlZiACQfbsMVmVLy0+CdbOVUBX9QnZAhCZ6Gx0GyPl0FfLsC2tMAaY5
IdSNJvcsM+YXXE+rm15OEKdp8BFiVqdNnhuB/xUpt4P/5a6UG7IlGoyxSpLeDQ2+H8+KgVR3vOON
QJe+o4qqxURXstQfnmPful9J/3YecCdB6oRs7jJMGsUDPC6ZGyy542qctAgjVU+hoL1a3C4pJsZC
4zJ6ubKHRZzUKJgTf7IMI4IW51LQPCvIy6A9J3ycu+RktQDaMZvN79/DK4i+rkiaa0qOrCVFvmJ+
XQ454Ka+wo6V6gy/Q8dj+L9N8LMdW47tzLPriCgy9+Htne8QIa9C57MAODRY2sulF37N4siORl3i
L4NZEn4X/UzisOfczygeHx5o7XfJdSVf92VBdHVHUB1HExxNkwVJl6lq+Bp1HLf0NSqKh51f45xO
pnGqPgwPW/42bZJsCLmXfuZuwV/y9W9XK5/G09pOzpQxV44dR7LD6yXFkKoLmldNnfQw+YggsplT
1u0OQQsqdBtL+bO0U0yoKraJ5jKLur4k6K7uCSCbRUH2ZV+QZAODVVsWUwrulCK4g0qTAnBSmxgu
NUyPioIpuabgyKIlmBRY2mTMU13X8WWx2K1IO+iAFYCT20SRDNdRqSXIHmOCL7pMUJjpCZ6i+JZs
eTIsdoXg9OoOnvuBU9rEYlQ2maEKKqy2gmqJvsAMVxFg/hsw3qJnicXDelhw5fMtDjrIGzoijmzK
pTEPS/uueCGrQt+xN9iGfPcnc+9paNATHgH0dwJgfGpqqmCZChVUl2mC6amWQBXRYCKmKFeU4ntk
+kHFBV4N46nbvpIR5Yl+aUSm7AGo15pN24bWkjTgLkyiFvYeFssL9sCW+ESWtZYp6BY+SZw/8WtJ
tlqyKijm0+81q6UK8rOvDaMlqYJk4PcxdPYQ8fbFlgxCSi16oMuCruGDh9l0uXDtELRDDkrSJWxO
lUspdzjFMBvw/44T0LVzAePf9S+ve6PLzoXdG42uRm3yJ2eL1ZKd/BITt51Ee4+Cb2z+y3vy9V3m
QjuliXYLg5EoyAJ8iFa8mzTnw1p3BmWBPo9ByF+4usNjZRHUTcOIJv1n9wjvKOxraBgG7mQzSywv
11rLrnnwvRht9dOaw6PlHjKZxlUdc/16S3LcDUoVfnG3BGWy5NpePWDy/SIp+JWSDFaxOndYJPFQ
fsEUDZuuHa2fRZPcACWl72fHoETaPy+Cg3GTXBst7tyofs9qh84/p51jhOrpBLgBtvM3gxII1S9p
7AAB/+frO7ufuCzOA7rMXUa8j/eCycaLi9sqC+4R3gB2eXglxs5Wj477j9UEL7jjEzzdgCG9WtB/
rNiI+W3F8hQq6lTwXN0SNMXTBE8zVUFTdd90DNmzYIXkYcT5QlKi6RgHVRm40+zXPXCegA408dpE
fE9GfOK2Fm7xBcHDAn5G8xHjSVbqpflB197XnoTsz/3VQ2j9vJOQV71dzSchs+Ce2cBu3zBBsOOV
SMlacPDO+bHrnKcV+hanHBaJg3wv0CiimLeY3Jx2Q3Iy8bFc8Z7DrEGR7EQRqsB8IQkIZlOqcnXY
3KYkqvwCszAanv0ouabjTULufNlObra0winF8Ql4lLI21V3qmYqu6yIruKeTf4tCdNa2S9c5dMW9
+67q+4xpVGJ+liInLhhj4Um2vwHDW0xyVM1gluO6LmWS5zPdlyTVt3wqi4rKj6rjBJArjJPyO5mE
8bGxHa6AGmiGjx/jZRob/7RDaBf3ICDcf8/6MRXV16ivSq6lqwz2fL6syoZFmc9UplrFRNi2p9+H
CPtxytZQhNrunHLLIptv3rttR2au6lgKVZyim6v5VyiGVt2+U+90ksRtGqK+O5FgFNEwhzcGDdnx
FV1TWVEYjZdmkiRuW3f050yUdaz51JCZr4hOlhc1nUQebPGWwWPlWVQMrG4jz2Li2zANafGGoqb+
n27yhv1zcnQQfG2azEGH96mLcaj+LLzHWVPvMzqnt2yGRysZBoAAXThL8ZhA8ryAkyvdYhabsmsC
4aZ39zkEvslcHZMXckRwJkFow8wFNMdEAPKenPavxiTpGvcJyQ3kUhSH05TzL/01S+PDz17yoJ5n
eUUoZv0GPh8kxt3aEm3jixdjqeFUb+tad68X4zgok9zr7nTCt8FAh0UwR9eT8Ql0K7ZETZYKtWhp
h+DI+xzHcOYIAz/6DkpcmtCwCAisbXUAOaNTdzVNgowFsFOLJjPWahWyqCzWQguSbH+T03MakY2u
Zdjb/08hnB1iiew3Y2Ll+96b2NwDiAdWKJRm9UP5P+qutrltW0v/FX5LPBPGeCMIOOMPbbptM9Ps
5tppd2c7HQ1eY25kSVeSm+Te3v++AEjJtARCJG3Zvpl2bIuk+ODg4ODgvKqrarEy3UsWwWOfiheq
mjSmuxgAjB6UBE3c09t3GXD/zgA8A26Vvspmv1W6Etnb+XIxrytdvMp+4ij7/Sfz43ypTMYZANlP
H//Y6K9xrEdZSy1ifVrEN148IL6uP5V++vCrE2n2/MWtPQwJRaBlIi+MtTkDZZFbalROidJaSkxK
ZV5sdfyXQQydZ60vsAaJAtoi969z31KoHJRG5koyCxg33FL2IioyMT4Kdbf+4aUXU/70G3/5cSOp
WhFw0deTo1jvN6rEz62Ez9dTH5PottJgEvBmtWSUFyZHEVHKJ1xPQ4bzajKfBV/PWVNXMPtSTafN
HSGOMtwVB3cUltnusu7l8y8+DnFhaqHhzim/vY8jOYoc/bFyZzRvtrt5NpDSxPn+h+dHnUfFlCbP
ux+fH3keFVOaPD+8e37keVRMSfJcXjw76jwqpCRxuvevo5yP+5HnkUDV6ly7QG/ILamLqAfn5W3O
REcxfI/pCCpmP0wdhd3xgMYBD4wo1uPSIxrQLPehEcV7x3lMR4g97Yepq+ojPkaUcz9IHa2PPKYj
uDX7YYq29PKIjmAt64co2lTII3pKEdDVp8PjOkKIWc+56+gF40AdI+a7rwyP2nIwPYIppR+iePtP
D+nJVl1n8yyP6slWXrwDk4d0FPvDhdlaIHxcyHW1Ch4/X1WlsUbERdPDormH0xonYyrL+8aAFBor
JQQhjMcKLB/yXOMy1fOzPBT+wChgvGTaAKUOxIBoWRakKCTVsKAlQxQjy4iFWgquKXvKGBBcppTZ
MUQYxyllimfZvWJAuIElZIIoqGIBDu0hRKGxI2wV44iUDO7i/Yl0eRHoI79NPLtNpkKaqc9BFpjx
giFd4DExVe7h50IontL0IRhEqcpnBekb5bO0iSZuQQlpWTFK4iTbnLZx9QHw134p+vbNF2clNKW0
kCFQyjqd6UxxrKFiJKeoULlyYinHkJq8FEQXkFhmBDm59RD0lWAnQ4nQa3ISw/lL3Ohq/cedEZ9l
TcbWC5+CpMtS5JCQMtfa2FxKAHMnCpFAChnN9Is3TV+ywPzuof8xs8sAJvvoxHG8uBMBRzj6j2Jx
kgylgHAQi3sf43x95baVpiOAYzSmuNUWUMzkCE4nINWTsg1vAI6/fF6JsdaoeuZ3b48CeVgn7X1m
DKZ4B6LB4vuDDwb2ZRyYKCm0wCEcM1PoCFaRcQRKOpMh7k8gR5mNDuY4SFInuhDithyzqxGU6hPX
RnX49fsSu3XrxRkgtLSIlsZN5UZeC8VwIXnOGVE5VNbmtqAsFwJoaxiEiMsjy2uSLC3SJkDnYDbS
+vYGb3zuK6mzlzui+cTJ7uC7ftGnsEL2ch/2SVy64+eiwJCkRxmOiJ6/jbpFgjtiE2mKWIerg9zg
PcrdyyESNL59M9WWWVBQyYk8FO97gH/jyAY0+Rlai2frMVjMF5vIKd9Ax6dldIJ5+LJFX0NmpbiN
DfAOdr8UVp65tPvKkGDnZt+n3ejXIXZglV3frHwWcm5mIRvHbZnXKzP904RiPdNKVetp1OxKSP+c
on6I/IBK7WRDmEZ0OyAP9HWNT59l89lkQ4lJTYmJf9O3s2zVjq8cvfwDtgZS58CPw0v19FWfZiLU
T/INy5pcq+Zb3Q+xzqq1r6U0/1znXLmf7jOfxbl9Q0ee8xGR37WS3T7gkwzdSphOfYWCR8f0dj5z
suNGres6WXldxSYPK/PMkXbliyTMPq2vzqPZf0fF1ppmb8D7Iqqt4AgxqWGNLJZzZR6ADcPVPt2Y
rqp86iZtejuGpoZXNHSeDPB2JjDEt6lOKN4uI612QkJSqsWITkxDcPeF4Xb9yVW1oVb2w+buleO1
a5E1gbx+4b4sXmUUn7zJZDUTy2/ddzwP6G6L8NrCK187bfP80tTpzkdkiq42YY0g9KLRrIUfmY/k
yHzs28xpDBuBeUx+PQDth4tnA016cdxIpVhmTAeUlBMF0i698tCUOKyIsMJblxDxpUVGrNsBpWCH
yptDtAr6MSoo1FBgGjtOPyT8gWiaTeX97Z3vPmRC66Wnf7U6yyBHryFlryHw6YJPg+7y6mbdFHT6
Mgsay3yq48+n8pgfAehmRXt3X/0Cnzf07kNvOvZUjEfC69H09w7Mjs6/JBmGA8uuhX5IwDnUJYCY
QIK0YWP6r5MBSTbjaHhhtmJ7VRd6juEokh4w2HarOK3tj+yr2zSv81BNZf1tYc6nf143CZjnwf58
7cTRtdj489z3BZdeiF9fiNXqy3ypz2duWqNYWCotvY2ldbquZhPvp55svt0ftSGiwlpjjSBp32Tp
zknU/U8KSSRnmnOGMZAY4AKBwsraN2nFdLVxToaRPJ6Dski63+5FklGmmSLphEMDfEsRV2UpsKTe
9MUhiCyp9hii2HjSVhmnVZMFLt3DCJSWwd2KBrvGmUMsE0eWMq0hGFtky7zhVc92efDTnP8SCo6s
nAByMuB2/fnSfY7R8vCBZ79gH8h7F19tyhPltR/hrP7r/NT9PHXT9flUfssrfeojnPLL7z5+N7n8
iDECFIHvLifF335EP3388F3umH2Nh654ClKGojZh0uytIGOAF6KgfNe4trPiDYTAOrFNhdPQCkqF
+xNgyyRThRH06Vc8TWYc3osko1Y8TTr90ADHTWzFU6sdcSST2EZWfHsMUWxJ91abVpcXt7Z5Q5Tg
FmFrMWx5Ujem+bt+0TtLLmo3fwAQDcduL9/GJews+dV14+w7/z3LokcbmvSz9UKzunZY3vsgNCeF
mgKp7rfz20Q5AmxZSqVzBqzNlbY8t5KLHFlLjJszgQDLVtU/TNzqRGEqBf0Oi19PzFejPCtII6Sy
jGgO0iscKGQ5scRtJYiWinsXTIGR1G6RQyPE/gp/zNUNU47r3kMft5JhShlGAzyMkZUMFYWA2dKC
ksVWcmsMUWzJ9Hs0wOXjt74AbMeVDhThGhteFnAf4N0VEAXIU/4VNKBOT+O/3oHHLBMSqZIZjEbB
S9JvQIWcBt5W0jhsRsMSAKSp5ftS+jA2loztRQMCIX97H7CJ6bQp3b6afHFU9AcgLbhGVjrdTO7r
jn0wJjW0ASF43su7A9KHKRCIDNKFLIsx3MeT9Y/Q8OC3u+i0O62WHEKlyXDmw68RfQyj49Zk4UZV
zXWlgvVW30xNzN74WKguzPV8XZuL3UFh9YhI3m4q35hrs/xkZupb1jR79bU+zLoDyhHti4cQ+W+B
VArDCEbRI17aavJg8Hco+Wtj85fzmQ5Oqe/dHjKfjSAgBp0L0NeMaqhRm3J0EyFjC3cMKQFSfLgd
qQeeXi/eeBM3E+hosDImq2w4SQaN2JepvWN7vRKrTF2J2aeYk8QDS2k6GHURamdBhSA4o0ojOLYw
VsXuMIWSQGAXkIS8cW8VSEopNCGFGu6f6wGq/9tDaXzfDswx71Yg+vZJu48Frh8zWfcUCx3Lyz0s
QSkNKgrhDr0PTsSx0uBd3W2qcseDjbW31oRu6tzYDrEwoBXWUAIeQuQP0pqwkjoFW0STQQ5T8kHg
d1EydAuolPtm91sH/foHn42n3x0c3llHocBYak1ZMYZqA+qW/7J9bYjdcSeiElqqGBKk6HWqi5UL
8xD6p2ekIcQqhf3T6Moz2GR+sz67fGmXxpy8sY5MN+6e8OHvly99QtbJm8uXf5tf+h+XV+6UrCeN
xcJ/8sGdt91b/a/vhePYq/nM//52PpsZ5b/e//VutjbTafXWB66c/PFG6PrN7kzuX/PP1eebiTdv
blE0sQTub/oavAYnb9zY3RzPbq6lWbpP3QfBYbRyv8OTN4sQJL9Wc23CRfN1US2/nYVSaAhgyD76
ikv+v/89efPJ9xlx12bzkzd+7wtPqPn1Qsy+hd8btyNs/4Hqu6p1fUuodh9+Wzhii+n2zcoJ6vWy
ucmN6losHUxf9rt51dtqvay+Ztuoz5M3S2+CrtR68ufqS+ULLTa9WqZhpN5S0bpnKuT+hw7BJxP7
OEySm53PyYuTVbU24bzg8Hzbv/WLkZOVmVrPf5WKvGjnhkmtSWzR/+tfcd7uH7x+7+UVN5p4EKlz
/0D96m5E1HxmtkFRNgTAmR0Va+PednBrTSuOMHW6wCPMOjuFjilXlBgLgIqpX21Cx+GlvDJtePHX
c6qcCHbfYuCBREPl3s01g4IRSA3l7rgqRamZ0zCUsLx8ukRDRwWW2ipGUWEcO7PUmsIjQqtbNkAE
RCm4BAIjGuGU9hji2Pqrc8db78nkOTzAzhcMkT5Jp9Y4TFMs2ZsigQMrGS+EiHo9Dq0ongq/aEMc
iGU/QaPruYszpjABmhEgoW2yNZgklNJC5wUDMKeUwxwpVuRu7TG3JpFSgkeyNQ4t25OhpOk1e/1G
tnEP/Ry/u66S491E41Mx3mQ7CM6z37ONunPulZ1Xm8DJ86DqvMraqs75qyYyZnUOX2UtNcddqJWc
830V51UWVJzz2fxV8DW5exv1xv22UW5uf0X+ulNs/Lu8WuN+3io14dmg0vjLewrN+a468ypLqDNB
/LbucMrM7kdBldn/cKurJC7dVWN2b9zRUQ5c3qgwu7f9ORWz2rnU+vDv89XeZ34zmmxaW2xQ7t1V
1/DYfUkoqON2BrV7YVGr2puvqTMKJl+vxN4XXzea+N4Fcy0qB2xqgvlh9wVXlUda+T1zUTdo9qUO
92g13Zu2pRR7aPX13kehnPdiXoXt9u6VhWet1ecIKLU9SWxGs5iKtQc3sdV03ZqkTzdTsXR8+Wmi
K0/Bvdm7XuzNaFWfTEJI/R61Pi1u9kbVKBHxc24yRmWEgApstDmS/ZH911TX9To3H2XbrJJH//cU
4/9P86Vr/KFwiDukZpeXjTd9+8+fUMMv7z++7TGwt7Ove5+1z6+J8WPwDM40OFlXG9+nnYbhQAmq
kZGlGqHaYJBqaI1T/TSsMVAYaBWju+eE3RCuQxpHHNkxPA+73qSdJqx1Nk9UkBwHz7WjmFsZk6v5
/POk/oqOtyfN151xtdHxhbOyJpIwDYAcHnZ+CM49rYcRmvh4Bywdpxe6BOW+y/TREB9gpyvj/pYm
JM+NnMuxUHYbtfz8Xa07dkBImZ8dO3XxDaJCAVQCDsE9wloPAbgnA3WRIoRtM1pyIb0kGsVFSbqx
rmW4yxc+uBYIJgsrC1SO8WcFJD1TAu40Q51cicmGGmUpkMTGGsxFM5uOVtXqNn92PsvkfH11W/Y7
pNd6w5nfwu87s88W2HgJEHQhLTPvI3R3PR2Q7swwj+BBnD/9EEy09Nm68UiN4yAJPZsnbg+ZuXPX
aDrgAVE+cSOiJr6TGOdlqWO1QNrCdDg80hn6cJcHgyFQAAKU4hyO2zuTODod+re5OwRRTTCXVo3y
Oz8Ql8RRRpglxECUpuQGKVOME8/H4Ov1/EZdhfYUvjpBKKkb52vY3086mF4REP6gUWBigXsMjWMx
mOwN2Rm8siNj/LGkpEq5Yw1Dxagd3geXZ1/Echbf4W+38r8ObOqtyasv/76nHTr5EQ8PwTB1YHSq
SzPuv1o2odZyY4qXzDAMtNQ7rXW3jetDn666ta575rf392mY+wSAE31IPJpUSsd90Kipm8MQcfe1
Wq1b7kd/WImURz2EZawk+FADDwml8zyENud1Q5RV3aGvQy6kCqzgSMLWTgVUKLXGAnOki7RrUCPA
C1oqXzSqFGUJmUSQA6M4LH0C11O6BnEyY+Oe0vHgxHj+cgBLpIgsQKwm0mERlfQ/j5nFcWe4h6Hj
Dme3i75sQ/HszSyYmzuUSHjEGNs0Hk9OogXxCTi2HDeb/cEPwhIPU4x+Rdg7nwG473ToXr95KDQ7
uz3GO9G/Om2MQyFE4+83xjsCAgOdl8g3bwv/XtWZmpuIzJeMku21SPr/kw/ze6GaSJYwxr2hYfpv
O7QL86eYVk3XE/N17ZNVp9NvuZfqTo5XKqyWRk5FRt45cPysh/1x+a2RpY16sLqR/2fUevUi7L7Z
zapND6cGLt1Fb2FrnJ3bYhV7FOGdFOHPmiK/zN0twbqzOyIH9N9yjiMB3y0Ff2eQiHQOkj7rUf5a
8288DHqAoHrIYfZXJnxC501TkSNccJO1rBYdaUNpDOR+sVqcQosc/RXAsXzNtlIWx3ZEj0snmcLB
3lhIKCoRH5MM8kC4d+bVsaE7DZjmJLYBP581qnYebm8G0THVRyTnEHQhJ18V0BquCjbKODZgKPdA
tslYasJpNwziThSnZq1O/avnN0tlTuuveq3rbiZi+ekmRNeGr356/P+xfaoD9imAufkqrhdTk8Kc
NBw/gv8sWUabDIia/O19CPqoEU70N3car9Rk6YOffXgBg0ZKBrRkscPNQQs2SkVOkljkZH88+9GT
qWcvzjSVhYCYYu2O3XUEZWmMLlFJcssFy5VVIjeQm1whqCx1exbDOhJBeci6cTKURL1msv/oNlGU
iSd8I9i7zZgxd/sPoCLXivK8wLrItVs3eUGoZbJEmiPy4o2vN+WeK5i3r7rXuQ/E1/YH0THipHV3
3Bin83BqmtQcsHILSdUVJL1t8LN3ELoRDhteLbLW889uDUYTr9Odnx9qIBdmasTqyANJ+SAJdcrh
1FtFJ1vJ5VQTiQwx1MDir2ZYjZTzGUx374+/MulFOvRK/4zTQE2+XKhW4uzCKVeUlHGd6SHf+N/L
ygnq2SZPtjnCORmSEemDmYTNBS3drAgrcyGQzDUHyChqNOAoCi9Zdb0PvPnCccuXIDbrHx7SBnbm
5OnV6iz7PTtdOcjmH0afupGcbrLNTpuvb0oYn/YZRvZHw1nVtfFRYPDW6OKOrsrnm8ZHmox/e4Tt
MlnZmIxoDXZb4F4XCAvrXqhH7ZDJ0o4k0hFr+2bgznIF82XUiDgQgHdow4ojK1OesO5Ja8eW7TvB
4hF3nZ6wYkCn2UfRDlH+55X2bqCZPyZ1KYglToWdknZ5k1YBunaVxytd97h8oGKPHlKqCFQb0oHK
hr6hAtTUx2+mnUAFh6Lk1tDCmrLErDBOlhDJuABccfnUpd88SZIbxH1IMkpMlSSpJ42IR2kZICTy
J3nqFryOZay3xxDFluyJW4BeHH0lxcPxc5EKXe6YvFpycgCoVgZowvUByXmIh+PIUt2o2qRKsxUA
REvDuGaKp1caKwpcGOh7AhhZigLS0umWBSkMYVAR/fQrLdkA914kGbfSaEojKQb0M4usNGoxlZhS
q0AsLbM9hii2MnUiLNDhlXb90FtHMqW4Y/bqpVYSbigXQpX2UJbAISaOI0suNdSXrxTHGCChIJUw
vdSsLJkFAjDOFSoZQJJhqiEqSi4LRMunX2rJCsb3Ism4pcaSS+1+VRALphUnCHOLo7nyrTFEsfFU
CENB+iy1B93TeGpP65i7eqFpKgHEuiwU343N2V1oh1g4jiylPRbxRlwxrjJWWgYNK+mBPU3Rwhgi
FHLHXcAKiIEC3EkSqQotJS2efqHxlA3lXiQZtdBYsmZhMcAmHHNfKViWRihtQTTPrDWGKDaYqjvd
QauGsTUSEttCAowP5ZkdYJkoMtzf8fgoB0ycX3vLTUgIzrVw5+NZ1zmTvIZJ80ERNx9EeNAwWBin
6vLSHCj6ATUQEHHOC8YIJNggVhCJ3DCFRFSQJ6z268mRlFLxdMZoLW9YYAbda0uWJoeknGpEjdFC
ElEgaCSFWgILDf9/7p60N47jyr8yyBdZQIqp+2BWCziKNzE2Ngw59vpLQNQZccFD4FCyvev973nV
0zPsGVZXd/VwRGm/STM97PdevXr3wYR6bnJUJdQx3LFAQmV4av72UcezDB5RlZjH7YH3Cox8p1xK
rlQRP6RpGbZaBEkcFwsghIFM5Q7jWIJtSN8ibCeZr+q3ld79cKdSkcaTvXskc38IQo6bOK6ZMM6W
l7DX0/MZ3vmdIKXXayy9ks5LvetBf90DkVcJda1v3WKaXEg2mGbV/4nzQeYoauml4hzRkCTCjjGU
QoqIpZSo1jFQbY9FYf5xd5Vxm3axuOonk6weJpOUD79hAGDz4U8AlK+Nxp7aFIUXJSNokhUaZge2
AXOUEFS1wJ5cMJxgv9xc0hjAs6DKqkX3pxp7kAWdcVDtLqzyySiCg5pQ5dR4bKMQ3kcMpi7OriXp
7Mm8Vzo+X89CpkLtCi6iwjJmqY5Vk8dpTIpBIwGkIGlLzvwQhzJs8zcyf8TrVV3gJBv0eDegJZfq
X7y7er85Vp+cidKDD2MXCSRdvVsD2OYCMTLRbPiDN+cKGywBJu8p7gtxEnfEaaFQBF2HfKAGgQGi
QFNxxQNNgvhYKMSZurIvW4kx66AmUNqbYTZ87Clml/V/Cv5K5r+ec5FP/0SbSnN4JHVf7/5r7/65
mXFWGpDEzyStbVhXsyPzOmEjFCOcalmXs/CM9iDpKDjlcGRGKWKMNwpjnSw35JkDO5kktSt7FEkW
iRBZLRFTxyUrfPImOR284qUFAUMcSrBpVQtA6FpgR1nPhPUy75uaCOxMsUwJMiNq6qDlPudC+QxJ
/Mfqjb3MhVn2ftUtV988vz67vjoX+Awsa81W6N93E2zS7d3P9i4X1OcnKCNnVCEu8yN5PFv3ITVg
XyNaKME4OQo7GFje6omIyID1ZnNfjJa/VvAtQfzERN7yaGba7/dh6NYyxV98fNfNxn5rb0KexLz6
C0iF3cern7769svvvr747m8//OXrby/+48uv//bDm69y+dNGEv5x9Z/x16/u7m7v/rh6AbC6O/yi
LBFPg9MD2fPYug1HEGAaKhDjHeG7j+Mv9903GIjOEC3KpxOzxfHwyaqR2ABfv1j1AbRHzGnYGeE9
68JnH+z68kPsgaT0jKIRCGvBlWMgfASDPKMU0ZPBN9sw+2wALfJkDdrHTEEE7QQalg/fbz7nAvjW
IKLpyC+JPuOoaB+aasnAE7gXD9huFgNkeOQZU0h1aA4+FFqdCYYI1fmLAfiaA+ICvmCtx/gpuk6m
GurTC0Kgg+GFThgZhE+0fbxLhqxWdqBrm28JU1RbyjBPh+Vzh1bPlHdThOx0MaZdfXrWuy++BPMn
ZnW6PuvVdfe/L35X1MO/+/3q4uWL1c9v87SY+8Pu2IP3DzoMb3uv6TEuxyI/P1D5JzgWFBMYc/er
bjN4btS+Tat3b39d58G8q2+/fl2OVZvqLoMjw5WzwMrx6yhMCjoYqdo3gLXhsASkbUy7P/YurL1Z
YZYVQbwJ56uBp1uG8BQTVnb7oKYi7CMnf8IsxWzQcvTVOK8ESBtGw5LTr64JXUrby+F+oH4Sd5mM
DRsKmslYgiIzp9GE2MADCaXqvWmKzQd5BgRH6c9qRMss2B1/EFRW3vlgrOYLZqQBeHnzw6gSNYUw
y8HrmYkqJCEDm9hBrh2LgkXlnKfJOwm2JlZORadpSMQ+46KSTIWazlpEhWXMUt23a44LMjGniXOG
58RjKbI/wKEM24Ic6sN9IikoJaM2YDMNU6j5qe/+9Od1N1Bs3a3RWn3/ptDBdAoIFhySOMO4yiwN
u+Ezx28X0+byLsoJkVpSw9qvcoZrvro7KXlqstc0lJruyLOpy8osrDEjXsRIfPvEbACtOuDw41Go
Oo3ONIy4eLzXeLcaGmNDQrR50Hu7xZlhnD8f96Skql1501BOWdhQ/bBGWxPmSFYRtH34AwBJPw22
orUwkGnfht6JZeCkiFPiHAcq2/dFZrDmewYnpU7NiDYN3adbTur3UygjdLKEYKvbjfsMV0Nv5QR5
+o8vrPeg/kHBvr/LplEe9dWv3Mmq9XwkDXlaWL6P91tdP6iGMo4HHIhGyiYLXqtViDj4b7CE5qQY
Bqtt5bdo7DYHrf4NrbrcZBmLT0N0sVoA3jRUaWSGy2HaXLAYEsu1vtLSRXeR1WaPDmGaevnjGoPd
g2/OFU1RCLA1CSV9bUE0jBrJGAIdzJFiPCASdUQRUxeUDsbIUm3BlNMwv7agR37WgYygsq0p2H59
3jHzq9WLQCkD280hLZRDLDqFvLcRGSbh94xER/mL04C0YdBv7GYN5/dvOjN69/AXmTSvHq7b9qco
/xYumcn1DomhGKy3KlChoilMBsuA1jLMcwDdyoPL63dXIA3enG3ucnd4520QrtZ3g184kBOCEoyw
ZhJpnBfwRa6QkphGixnzuDD5oUfpKNqPBIZ2qOW5BB4nLoU18bFu2P9rx4E49tLf1tdA7G/Alb4F
qvXyE/716inoVwu/D4FbX1902WMwJTyWJHnpTJpoPAqEB0+5pcFLlhjXNDKXvGWKMk1NoW39o4UL
etRnnUsV9WVqpdqeTvCCgNIgRhClxUIqLUDQlrpmB0gUgTM1A4LghgBGl6HMkHXjmy82GYks5V1u
GHdWkViMYgyYvwQhqW6QIrjBe++tZPfrropHex0CcKtwJeJNglZ1Cwlu8Jx3xHsAzpmoKYiaaHWx
rnMSuBrLE9zgtP74569HPTEipRWGOK9jyb6ZhJLW4mcEN/iLWaKGcHF/e8iAPHARPQBACjJ9Dog1
E2wPxDZYfsu1UDGl6O83+vXxL8rwPKkYfzT0ZkKOF0F6Iqvoh5vrB7vIphxCenrLiFSnkRWB7TMO
Gaq1tzl+TCOYtk5rhfnW53jT3YxNYjjXXtzdZj+qa3VM+ZfgwkRwVCwiHJR1CDEh5zBBoLmopZ7G
AO7oW7vetC3GcFYGvn6rR1fadXDnVe55U7oLhitntSld2SFqy0AYedcxSpRMKNEFJfT7CQGbQIQ5
J6UpLsob4lGGr2Zu78E31moQRd5KyWI8HEt1YGgZpfJ15N4bKpmzxHjMwS8Bxxz8M1Bkz5aW6cnw
pJ78X/synW0T8UW3KLUb/JejObkiakRsN4By0oyi2PTXVpjX/DaCHVAEW68Zpd4HPYsiFze33fzD
GmGeBpr5sas216Uc6ToV1E8e5co3awkCSyTEQm6sRdsIOS5nSTXHKhmujSolfIZILAFugbP0UL1m
MBU4CrBW2ksUxEQbdvMtzgb/bunz+tc1nGSn/f/7Pfwkb+nujAD4qmfQh5WNcNT9D4tgitrMiD0K
PqIQiwqgZARINGUmTsX5yqDVXbnTWA7ipFsb4wcQAevxxbVTABDS4CWCk9Dbny4QjKWk4B2WeHnS
XHkaooyYmkXa5KoqnyRwCGZGlIb5T17A055kD2Zv49/ARwuOc3EXfz+Z9w87qyiz+hVQqFQjOc1U
YvUL2Ht55FK8+e237iD+sfqqO4+zzacX8MBun/fmLIovqo6gO3ZwwDjW2STX3LBoQGbT9p2EbZDP
B+QoUVQt+ydEjgmAAU/mqJXjhDJsGE5LaiqIrCsIVo5nFATP45TS9rk35xGIJQRziVLeZ5QAaikc
OMDRioCwTQQxYwxKlGjHjY/MyEJGacrfedki96oV+3u4l1HZasXNl+f5ZF6tXsxy7b/4Kd5sar5X
fwcPbf2ymGCqD+qYD+FBgmn77GEUZftLlH+KLCMeecsjMilY7WSSyaRyFEXWDbVpOPcTHd0TT5Lm
mIKsKBp//Gb1Rbi9zoPJ8ctViHmd1EX3HZzv67d5AP0PN/4WLnousf8Qx5PZ9XEVB69f9tocR8SY
AIsJHQkZ4NA47/5yvbq5/Xk1eEEZo7rYWjAH/HDWBdHeUmm0XiTQVK0Xe48VHyKiFK6mEBg8+4Tr
8RbOuAaz2EkbqXHgPuSAo7NB2qQTFoUpsR8z4FLtM5iP+zJ9pqqRcVKYlPVo0ze1IjkM4n1ifhq2
oDoIEwE7zyXDWnnpldEJlAaO5lmDXtVOCkKOG++hJQk0SMOTKhnNw7NcAtySM1rILNX4BzluNJdQ
JAUZbMKuWDw5QKIInK6JuGexFasDUODppl1FfWYx34yLK+viVcc5Ea6UwALH9hVlGcCG0rOPRLKq
4qcNgS0gWS+AwNy2LlDlRbS2fUc7QJU7FcaF5BCqydcXdzf1T745V6CdnBCSSrXd1JSi1BgbiYJT
GAUqKAraakQFSU4k4hUvbWqakrYtRVyk2qmxh/8YMoPFTJvvz1cDTs7rmHLKFGgMTvXV1eo6hkv7
YvNIiJu5orkrEh78e892uaXSv13B07c/r7Ph1P920z6Z7m6vD/5aCTNabSt4jhsA/63SuqFWYkxo
YEU0OF8+sCWF1xQ3lBZ/JJJVY5K0ITq3d2uVEAKujrVkSaiL4lqOfw+qydfXhUZ0yRHOAtGS9UKD
+SAYlQlx6zxSiWgE8HHkLIsh4SCZTycWGh3+805lDJlJofFflzch3/6fvlt9/x3gzihyl/cvy4Lj
9dXtDfDdbQIWBa/pfidHLkFEgEl5e23zWuarq19z4v/D5bpb9Po2Xt7t8ok/vwWGTJd36/uVu73N
pLM3IT+Tt2Nt+7e7ru7rdbz6AG/bLI16G4GX7/Nw9G0uYNN6NQL/WVlWVauBnuXiVXcxEtpSn1SW
VSl6rplj3pkldf602p3xPCSr24Rt+yt3wkJyL7j00gS2pESd0tr06D2oJl9fl1XUE5vtGauJ3MYU
hbdcCoM8VwpR7AgixMJN8C7gGCnTWp9aVlV7MPbwH0Nmtqz68RKMks9XVO2DPyKpJsjZ0BU1VpGa
uDJYCcZxeqyc96OURQirBVDPIhjq1VG0IUL3qEY2GGBQGyhYj4+zMDOIxesmaUNwZETMyyBsNnc0
pe3TPDOAn9xpivppNkRKapW7KTlOklJJ4cchkxkHW520TlhbgGKnDQjhkVjsqFBLkn5UVNMnrCEG
8OgmcOuFl8Rx7B7ryTkEq5YIDgk2SZm6nsSJcsUoi477Xk+SSLh3xKGcg0eK+4isowwlq6NTLiQX
Th0IoPXqjyH+Y8jM1pPq89WRako/1jP/rMXHr0gHSznwufFU+EXSoZozehapWs+UsDZHvxgbSZEk
k9ex4UV2dDVA/jwkqwZUWZuLthNkAoADtgmK60UKW1frF4ZQTb6+Lkc1pzioIHNpWy9HBcOJiaQR
D8mgKKxGkYNElYzooKk3LtJTy9HqwPY9/MeQaZGjkn+2crQHfUSO1jvfWIszDXI0uIvLPAIwvPdd
6bjUNHFnjHSP1zdMi09WXUr2HLKAVYPdhDW4ZSPiMwBG2hEapVoyTIfhulgohiHqB1eQDoc/eHMu
bF5JypLxcNJ91sUlG63TiGAukU1Ro4QjQyJY6wihjihSEBJThQYvmxioLiSGQYk6Tj3T/G9OsP8+
uP8bPJiRfUUkA2w5QTk9jjh3AQHsEhEQi1gFGzDzA+ny6qd48zrm4Xtnl+vbMugNPSQfiffrerDB
vd5TRJIbGkEqS7EksciqA38Ia/GsgQVAiF6srx+CJMprTYwWKrglfn8HXeU6qiktPSDORNpTSCWs
ZTzisJ1dARcIY8eRssGgECVBueEAyRiCIcpHrk/t7UydjhpJew6Qma2l+6pCivFnnMYoIVHW3IxW
M+qsNBRlisP3enEfPVyGoi5hG6I0faRhCJszTDlvccwFZoXbx701ibKUWHEOBavOTiK8JTjTE2Mz
J7XbJq6IZXCNksZpiWRgVUuCt4VoHh2qBhXk4QaHwmrjGYRjDaOIPo7yqU7t2CPXXLocNp5P8zqv
8jo/vq7AUBatiYmbpJboQl4N+/EW577n9w+Xd/fvc/ng5f900/k0y94dmG9xSTxkCsC2EYL9pIDh
+XIrXXDeE5GKDscU37c07n4cvq8upd2jWANpRmYu1Lm/Ho/nC9OuEY5CcRXAs4pLWL4ef+ctDlnP
8tuB4xfv7y+vLtebYqicR8cqCe9FLAzDnsH6ololzKfyw0M61S1B0JdJWh8Zx7q3BPP2bcmkRcxb
iTB3EXkbFdKRwNMUvtGlnpMntQRFNWvPR/LDQ2QmLcHXl/d3l7+swLf68t27PP7//4Vp2ITViK2Y
80GjzDcsPnwoj/cOnHefNA/msDXgsAsWe5oMT9xJQ6XyJmJNBLjwIWlHoi22OLPqnp8hSCCfHkqb
BgL8KLFa74DiRzdzCMzyEnlhsS/6jVOKSFazZHyyXp1Sq6PN82HFRGNHXoUWCCVgz8qglZVUM088
Fy5PwCHyOXsKmKxGJ3ljDvggyEUxiGsN/gUJiyR6wz7hj2Qs1FuUFnHNQkCqUUheWu00cUCzopDA
r8xqLSWx29IogYGNQWWh6HlAIiiKMA0ElGDUjoFwY6mUqnjSKGQ95zakxgROU1FIDlaCF5YgB/Aj
njAoBWtzQ6YFeaMwxpQPo5C/rNF9bsIcDULWIRfHt1/knDvIQUuXtRWwel+POG6KByjWwJXlWMhS
R97wtpSB+9RSmay6CfrkSldXPQjR5j8/VISoZBXDcDOLM6smWajeYiQaJwQeRhx01JJ56XD0j136
GbJD1yy3PZpNEqfuNgQVWVCag17elssIgU20lKIkhUWaO4oUxxjxIBW3NmrP7KndBl2NGAzxH0Nm
WQD5c034lpAYcQp01cYUxQqCCQ5fEECut6uJhpjVYOQ3NjS4yCn3hUDaDPO7us+GiMas+H7gWEUf
rPGeGv044jFDIphPLkZVryEQxyfFtUhWsugFXrBWS5zxT66OoIOocvdKnU0j7F2daJ90nkrL87xV
3At1m8dwEasQx5HnqRIGyWwag5mrlQLW08VmyCk38WXD9aqfxx72I7iMjrQXjsEFSQklnFe1Ri0Q
eBEp1yiBbawjwO+L0pDXmwbnwNQ20377U5R/ixJhAUnqNHI0irywXLNIizNHeL2oQSzNwzupsNfB
R7ykHo3jaqZ7Dv1mjtqfQ7j9UfscJ6WcD0hj4Ayfa9aSMxbRlHgkWluKdRmnapHpHJymZ+0D0Dxo
HTEvLPHZ/2tHwjj21u0MmqsP12PD9hdTkNTl3GT9w4Ap6+arMYqLiBV2dFuA5JXOnjtFAeOEaAwW
Ma0c4rmkh2KBUzx11LvDf95dHUPmiaLen5s924RV2cDlpC7SF5QGHaRDDfORqcA8XNIFplwH4DyZ
+RCXNzFqLiXl0U9Mi/HaSAq8D5cnCZXgEmjndU4BMSk08c86soeTuhabi/sy86u+skAcN4VFERzB
+NHJ8dJIkSESZeCqEl0uqFoZSWlyrpIIVCrGl3givGVh1ccxq2mddG2zT4rluUZRuDwG7Mkl42I4
+9QaQjir3kO5MCiXLMegOpO3dskaR15d+NU+zOwwYzkV3i/DVB/dNHcmYWG9w7/Yu7beuG4k/Vf6
MQFCh3eyjPEAc8liF8ggg3jztA8Gr4kxsuTVJZP8+y221fKRfU6xm0edbmOVp1jqFqt4Dr+68qsn
5yXcyrq8f7aXNpw+vt7tkFyK5V56Hu79Ls5tQe9FMB25ZS5my4ILkgH6UVa4pGXkx/a76GdlF9KG
U2UG0ob+y2suoJRY8KroLrjj0FdrTRpse0CW8DO6b93mYEKbhFfnyHx6ZKqa7tCaivbZ0kbHIJzn
WbraQawe/+u8aOtmlLze/nb/sS3pCl/ocltmZ7asFmbHUN0OSMRNuWd03Uu040i0m/q93+58xnzb
iEdjaSq1zEFLDuOBuJ8ZzTa/4MFu7Pmbd+U25HAbWj795iiK/CVvB/bgfpa3P19uw4LHqzbBUpvt
8HLzP7NE3Gsl+Ol9/uDi7JZ9s/Vzblvg1+jHlkU7hjT/cXWHoPp4B6bA0MC7SXKs3XiyGUr17eXb
m18WhiitlfJvA+ewI5GhTMtJvGO6a9Gup2eSLqPX6jhKPOQok3QCp9ky2vUa7BPWRoYovVBpiO5d
WzIRaXvtt9PlaYdYRVVqFD5FuaujN+qtgAE/E1ICE0p5lk3VDBQGHdqIRvF9bIeYbLd8pP+SMk+R
iPwCPeSDtFpwmUky9JMcUrpT0K4v2eJrinGgSqWKoUQJ2dh1mi0jO1HsYNktaFl8BBGE/Pwa2T77
RJbdbK/AMl2exjUDEaorwkX1wKsbsg5ORCajzUzYDIwXmzDkN7qYaFX2x6bI1DQ5h10osEyVGQv0
v7R6CqXEEmrRydQDyidLFHSJBxEtzyXMcqBMi5SzEtIcIPbwy6efyCdK0srzouJMgnwf+cgddAdk
8mcux4K2eFpaCmCWEr8rHMlIfRKEpbuu3PrsvcjCJV6CEjPXA/cAG6BMwGm2jLzh7Aaz90mZxI2p
xfCRS3kayMu6rpd9ni7fI3s3EFR0YEPZZZ+VjY2eiKkQDbMmZ1alKkx7W5LRGcLxq/5An/uF7PNU
mSdytr80K3WQVvNmy5AtF6c4pEaQfe9uPedaDEFZl52VaaQF3pC1+NNsGZl3cYOca43vTFl0Wnkc
SSIYQab6XY9zbbp8pxm/WNxxleWEcy1AcUIqJsE5VkMqzINrbW8uIE6it23n6JSeEte2+u/3VJaU
GXK2f5RfHpJ19FjArrPrqDB0R4U7LJs321GhS+Ke++jl0JkkeVROsmVkj4dwh+VWHsBDtfR7rjrp
IWI4o8iLRFOpust3OjG5s1ABoubqwScrNaM4zLQxGr6CZsmEyKQKgoM2ypqjY5ci0zdT/ZeUeRqf
7EsEs0MVW0A3RQcra/jZgetqnAflylwRvxcMG5o63o3kOibk8Y2UHUTwps5R4vaFo/ftiZjQwUMJ
iPfKqblKVF/Ks7Ndhqx5+PW3lwEQuDjikeNDfjdJXnOaLSNtlz+MleyeVuiTpJpLqiCaBh300Gkg
uUweiXiYLAukSNNvLMpDbNnorWZ8q4CbkPXQdRxjSXZA3703PFmeNveBJ/yskaFouRudpVQsUhRW
igfGc1YsoITM1Zx0MSZjzHJsc0+OPX+k/5IyXXP/+uoiXKOFFnzzVfkNd+ftu3J5Gy6+HLu+qMGC
AT+7OqahCSr8+tSKyFFV7mIUM0Q+e7yHZNXwNFtGehN+MLUieBLJc467MXJF1zgyZex7qZXp8p2x
IBANdy2VkndEuVk6p7XlLBWfWDbBMlmtZCVmw22xWeljp4wNXWzzC6mVqTJdvPoRhf/PcLv5rvFO
v8dzXzbfv728+22jX5hOX8bDxNBtQxo1MBRjBBb+HRCFvvuexXCDa+IDu72+unmx+e+rzd1N+QT+
tt9qCPW37//rm4d5o79f3V23Be62bW+/vmP3v/jmA9ohim22hpl9QL3dr9l1eX918xbh8vd2JNqf
xXfll/b/2794WW7/fXX9r83Hj32zKS9+frH55fb2/ctvv/3Th53/87d/al/78wYx8rLevPzw05f3
P53HRji7tDM9ctavT90YyNZoI7XRI+U0Q9b7TrNltC83mLopVoN3zvgshsIEINPOvpe6mS5PY6NV
yUCI1aSy48+q2gYQGlgQIbEACJCpSsOKViJZVSsC5bGxEcgeD7+QupkqswYb7TM2rsRGS04OOMVB
Ry+BfKUOa+aaw8YQA7iUrMDocuDMW3lurralx676w0YYPoATvhvJOtylsVHaiCwkNs6y4C8s32k1
CBIjAanQURS7sasS41mlBaumoN+YTGa1akRJIWItwskqjj12dav/fk9lSZk12NibMPeMjV1sJG+2
neSg0yTt/pB08zw28qK5rwmMtSNj4a0+N15FS1+lgcEpoNFWjrDgRbBDNsSQ9BLQG7U5Xb5DOS7R
DXTeZvz4rl0ha58zr4iIsjKI0jJVECukgBKN8gaFPTY20slsWBi1OVVmDTb27jo8Y2MXG+251Ucs
zRsO61tUQYI3ghcf6kisaO255RutJV1tGCWYQEgIUQkM8cb2icw3QpcgYbI8jY1CZceThJT0DhsT
F0o4AGYho9+ouGbcaotH20rpYpK86mNjo6Ut1kJ9ZKpMvx2iXN7+8Po5u/gUSEimh09yrD0ZeMD6
yguP0UruoklipDHMkpdDTrNlZAQNg5WXnF2MMktp68gNMuvJG2TQq7xMl+/djLUIYF7mmnaVl3Z3
hYPOGDyrinAYNNM5Vqa4E6bg44/x2DfILE1ADAuVl6ky+yPhcy5xNRKSyeCTHGv6tgesr7OADsF4
brSboRnsv+GObH08xZY5cr6ggME6i7C+BGPBeTMSLztNdhZBr84yXb6DhElwhCtbndzVWQRXopoM
zEdfmKuA8bLShXGJgIh/Nul8bCR0dOIHFuosU2X2R8LnzOFaJHRnFx27TnS8vqqii/LFWKMRDEdO
+NlFx64THQ9WVWQRNTYiVi1HWGVcJzruVVWmy3cuCyBySe+U1rHuunE8+v2hNvpAnZjIITAH2TNj
wOgIuvBSjo2Eneh4oaoyVWZ/JHzOE65GwrOLjl0nOl5fQ8kuCUg+hDqUJ3RnFx07MjqWfLCGIoQt
jYpZFT7Sv+k81XvzSKru8jQSVg4ZICoUYMcblZ1qg1st4yJUVqIDhpEAMDR/QaUotS3x2EjoqVrb
I/2XlBmvoTznDVcjIzma5yTHnIzf8fPrL8NDkCDBoSUeIa/wZzcsyJOjafDDgxdK28VG6dFPg5G8
oecURfcjqbrL08gorTKlFlNr1buB1j4JFyzioWzZQqWB2SIMy22sZwgRzNEvlG713++pLCmzChnJ
O6TPyNhDRi/OLRSkJZJ8fUWlci4SBDw5aggZxbmlXj05KkPywYqKrV5GxYErN3dDsbtPkuq7eSRV
d/kOMjplJagkDOyu2qvgpC0yMyOlZ5r7yLQPisUqUubKi6qPjoyStlcLFZWpMvtGz88e4mocPLuJ
JJ6cSCL5+nqK4glkiUU02oKB83129RRP1lMkH6ynoHtWdIhVRzeSbfWa9hB79ZTp8p3e7OJr8C5q
JeQDXVIbsGQFkzIXlooITOboGAKgC5Ach3DsO32ebO19pP+SMgfg4LM/uA4Hz66a4i39+qyvphge
ANCxFGKWl6T7fpNZ8pNsGUlrLflgNQVyKjG7rJQfipRJjuZHUnWX7+QQqy0ImFaEh2FMIgTIrjrm
ktEsFClY8eBYljp64DmUfOxqiic5mh/pv6RMFwd/QLkvynMK8QjASBZXJD+cZPkxBsnglJQ1RjXX
5ddjg/FkHUOKwymWP3tL/v4yFmNtNjwZkYdkJHdQHEaqc/MJDTQHG2XxxqJbOiLc2dFAbyVahkux
QPBD7cun1D6PPjsvA2lIxGEp19lcjPc+Q6myqiGbcnZU1LREUhyQvprDieCCR5/el6jd0GtO2iAx
mCkqXKA1LT6FOBIhAZ3ZFweEusvoFZwOaLd51nmEZB/auHniOPayWdMt6vSCVPRTDOe5ND6irfci
XSrcVsMqt5lFkSOzSQgWo0yl5sodV0f2Xrb67/fmLCmzxnt5DutWeS9AsoFLcUBm5P6EbafBNb8F
I/RGLM/jyGgIkOfWfwHk/X786PpRZxWczC4IJ0fSbiDPbdQZSLI5QgyGmxndVkQ5fL3ynKnr7hNJ
ifBIqu7yvcJs4wcUXsqwS7tVjFVDxXBTSK2ZNDmwkMGy7MApi05PDPnYgE1SIjzSf0mZ8cKsfcGf
I861mK3PrQMDNO2nrW/n0+3qp2zzAOVciNl958+ORQLIywRSDrbzWSGtS9UEX0auwoAmU3Gy1843
Xb4zF51rgY63F0nsmlZ0ktXFElmRGZgp6NYithmG+FiUrL5dHzk2NpIkzY/0X1JmJTY++7PrsNGc
W84d6DKFfAJKBGudNCZaO9S2Avbc2laA5NFFOzBIFxOD4FJ5DLhHWsLBka3OstfQN12+QxmtvQIQ
1rgHKi2+dRxNZgiskWmrOdOhFAbGOJErgmU6NiXCVv/9nsqSMsOB/rPb+ATQSF7kPsk5pxP/cn1H
n7SmsYW0ZNOQO3R2yX8gOWGlHMzTxjY8S7bGuHj4LRA8nJwMqWUvBzpdvlPBRRSqkBHt9A4aIxcq
OROZl1oymThnGCRkFqoSJtcqleNHhcZ7/fd7KkvKrIPGZ69xBTTiDsrziqibRGRELdc3+aUiRVbA
Iy+He41NwPMqsDWJqPwnosuqacKuWCl0KqldPzs0n92Eo52nwenoNhmEKzRTbnbGcfch0qlAeUCC
dqbC7KD5u4VXnQ+vvDfhyDq37I1un+5Nh4IMuFKmhmzsw5TcNpDRKMNq8mhUAvrbEnJzur3TWVrL
szm2USEn9z3Sf0mZfdsjp+71XrNank1K16Qo8pKDnKsydM7QgV0aTQY6x7h6/rv3NVhpo3Dq8KYD
lO/MRqI1iUhiBzOJSHDny28ltfxLKV5b2/qp9f3ir8tNG0/0Ao8Nvuq4Iff4kDxYmTlP+ESNq5xX
H5NXKVhljRdpViZyTJtU68e0BXzD0A2oqZTDe22agCStyXTT/vnXv794f3H3c3N+vQER8QXRht/v
2k+X78J1e8j4dm9CRUd38/CFr5owr354H/73rvxY6sPXWfs+q0JlZmVs437xrfOpeFXk1/PSnlcp
oElEOi7qsAzhx7ZYtEQAKVoLh7M99aVSS8LcpHC5ubpsIhgHSXrtnY9zNCsYuVlveAoxmjERFtZa
9zTIEoA6IMK+uUeBm4vwK562q5/ftn4jYyW+ripDjXOnbarHrHyWjLWn8s2vj96JQ7wGF6F8Alf3
784OrYoRPjoTkq08gOJFFPwPEQshX2WvNu+vri5e3V7fFVwTAeXV5u0NLpPCxZubO9wPNO7XH34d
7m5/edP++eYG/y7a4Gv0Ll7t1gGvdDWhapHA6saLUzGUdxBKLbpoWNwGouT4cRfQdD04R0WnAFWq
WtW6I0vehhh7CIOCkPkgdUCcuBMURby6u93eQI/GZp9zsp+PLHu8l/OikYUPdUA8thOtGa/7mbE6
8VoMFM6LmjlF0/2dF47isnu0b5/tC3iOFpOXzO2nB+hTew8JXBZScCdwJx06S2jsRdIm6pyksCOi
zfX3LuF+p6HQ66gxUAEB8T7uCRi1WC4Uq7mVX4uxrGgZmRRFJpe9sfW4Izua/nubwyVlDop77nNn
z3HP08Q9lkx0HMlm0wVDddjk7K2A6J3o5AM3KSs/17vctdOevN2p5tIX84t/foh3n0MQLi6Dxg+G
urvhblWuznHLrBCGAWTBgoySaS9kVTl6nuamy/aM/deH6r7f85hXZQerH375ssUDePqsQJSxIrKq
0dN3SuDJdT4xxbMyhgNHs7z56vvmgOxGwn49/5J6MjBW07xXukBBfiubm2uGbkt4x9qZaxv9ai9x
pqfz5VvhL9m/yu+vtk4S242tbY7R1n+6vrq6xYN6c4OHM7+6vLu4GJF+3939x8dgazvs9v6zn0Za
u2+y9lUmg40s2FZuQY9NOV+z0guRlrdkoyVhYtHz81xlA+h+dExsEYJXoaVtF5qNtQH/yRXG1T6Z
gsLOS0aW8qfPfyLa28s3bVzwm90Dakn0iudLgahCdnxp4bQRBX3aFPDtgMYIW3xx3MTc3BT44EvX
cHGzc6a3L8Mf6FDTxdhVezIG6mTxdZ/X/OYdPo5/bC5+fYen9832EzfXkzdbcwTKmDLzvFaWcgVW
IwQma9VFeB8k9yOSHZBXm/FsRY14qILwWs61qUy3d164ve3OxxSW1lo1+I+tAEu+xxKdWCWUC1Fx
AYh+OgcMAXzCn0QMGD5/j//Id/jMyM+bRPSp2vdpHGNxvT5zCLaqiiclejNXFeu5+oKTB0kfkPma
OUgWPARheHaz2afpLs8Ld16MB00i0q3Sg31xFmFQoU3SfKB/sElFGlPd64ubLk/Hq0Vlq5Wz1lvY
XYDLtooAhiEiOuY4JBZM4aw6m1K7qeHVca/v3+u/31NZUqYbr77+6fV39/0ekwaQ19u1NrB5/U99
hPa4199/9/r/U+gqONn8rhZKdiHnN7dXn5bG0P/wwokiTGP9f1y4m/nGrDyCTDJqdcwo5er6LTp3
GKT8Gi7uCvv4Or56FF8dGrsIQXsn817mh6BAFBM9usuqDWWlg4Ketz0vGpl3m2437QBnhQ/f8mSs
6QQFIHNyPmuMWmwMIhaeOHp/OhmdMdCacab+4KBAkG1IJ7GBdGPUqqc0KBCZgdeHdWTOOVkC0L0u
QUN2hw8raALSXsNAiWDiZGXRKGVFy1fNXsac7PK8cOd1abVJRNb/9CBXnDZeC4UuafWHX2BDqehm
KN3jipsu3529kyXPRVW341kvPESfjWDosWgWQCQWlefMOQdGiBKqOS5XXNOfPvbLs3celFnnZAmO
XpZ49rLWe1lqbzPb97JcsMHkHLVJfNTL0vTJmjcoHzwStNVCYvRiVHG9SmDH1M+Ldl7s9E0iGhzX
kyBko4IPWml02kZwkmyWOsmWkVO2pR4kQXCgquLFg0ojPVvC0KewR4IwXb7DPQqyWB94/Mi5V7Oq
XDvBMATRTOgsWCkxMeu9B64xKgnHZa2513+/p7KkzBPYE/lsT9bbE7oVR8N8lHyBe7O5/f19edXK
A9uY+ebV1qd993/sXUtvJEdyvvtX9NGGnaN8PwToYGsugrXYxQzWl4VB5FPT0JAckxyttNgfv5H9
IKubWZFdVWyxbRMCRoNmcyoyMivii8iIL9Y362u/r2uaGN5qNLwdCtOJTrwyNBaZNT2+ADuKIUMy
8AIVFryFiNdHC1BHwlupo4e3pMjXjyHRioBXMcl4jcKiXZopEJqoV8sT9UrLoDQLYF2f13KdYC47
Ak7IPDdiSO/AhoMn0aU9oXmg5aZwKKvtqxwwg4bcasK9xqfb+4dW6b1mMcckslL+OU46vAedI+G0
1ttHWMAM4yyAHy98Th8pM1j5/YFU3cd3rhJMKKV6cxr2E2Y9B8fujIcoNxrCpRTEAkAh3BRq651s
1uedJtZd/4hh2sYiEUAzDSyxaHvZ0Z7LGBXttAMzpucXAEziDTAtB0ydnZyQsGx3BUXHRAiOw/+e
9/2dYJoseimsVAPQVYyzhXQvhuTwEja1tJuUleS8F7JB03SKilCYqdrVyw0Ao4uE11PqFIXt1H0E
RWOCL0dmIXZLtJgcY3a+0ES58q8PM/FJjIt0Mg8E4FVCakKupIWZDLNCSeMLa+Xdh4toC3dpXVAM
50dW0/IkbQzsEqy7dtzNaYhiFzYrskqEW/JptHtPBJeeJRs1pa7Zt93TE6do5+tQqu7jcRAnwf7E
JK13as+vGUTleimeKJ4lKSV4YpJPBHCyUaoaVBfPDOI4Tlo9XP/YYl4AKb0VhCxHShwf4TniUnbN
U8FmY4oKQfbgeM+1tkVDvZ2mYyDpqDokOBVNtoZIGjIBtB6JMoaR7AR8rIWUka9SLv7r5wfy8cNp
1SQToRZnaEfjcC24584ihaKoUbJ0Ci+k59lyYWIJqTYLU2U9U7xWoUEAKfiroxl+YeM3exIt26WZ
AqF9Yno5saIvyetYTAiz+uI5Og+U62VJMy0VnNtITWl0Zx5quS3cZRFlgkQcxct6ZkrKMJ54MJ5J
On0ERZUK9QG6l5IaPr6DZjxNOrI6kmXPQsOM0RpeLZKKp6REZ4jlUZAaYFuILwR352XE3a3/tF0Z
W8xCNPNWdPECSIajiUXd4nWuLnDDMbNz/1cfP9SKf4AnOcQEJ+yw4qLx9aYk+PRSLRvApebAj4EL
i5EVXTihUQciQ1AkKMUJ09xLwF0+hJoX9/efCBiLL+T+jpxeDjsVwOAlLSOucYsTjRTa0KggSFEd
nNgDLW3R0B483SAqaHttzqRVESxQkb2iVkCvQSiahU7RGsZEkYB4snVUaZHM62MrfBrsIp3M83wo
oT/Xyyo0nTM6cfjDqxZTwnARbeEuaxJLlQhHorNn1vCUikjUB9eYWdPPyvbkWl4ctZlQngr8Z+Zc
r3F5cZhP4ZhvZnGUZdxmD8aGqVkZLIWO9NItOtvNPW11fxufc1V9ztX9XZVFg3EPmbJQ2IHDbP9G
Wx60w0r3irWG6sAxKGWaquSUyWp/LSo5BxQZZB0UDRhUMkOU14UwT1kJktba9HNjUJySSY8Uaw0X
sxiDvhX/vggORcczcMNeEv3df70HK5TI+tr/lM8LADVqxsz0Katg+fcXPTqYJGuLbXzuvk9wShrN
xo+AnR0Lg5LZF+18ir0cZg/0zRDNtAkiWjgMvJH38MxoNY5NS+TOFZeiZ8ZzKQF6y5RCsdboOpfr
9bGpRjGEmZAz2jGE/rK+e/gKoleDFP1u5mVRhnoKMrhGa/QphwpNvS3auXk4Aq/oMxNyRw0ETbmA
oxJAJU04MVxEUzh86rqZVnBR9/TLp9/u15vzuP5bdfCiKF18gJOsZwFXfAC5mTZm9UDArw/rz+v7
/bHjEd6COqG26OdNUCfIaS+tuJ/jhRimxdX2iPt2/ulq45+2YDFS7YNW3pYQ22Dx+JfaUuFGZFoL
WysQET7ANjnOg5wFsPFaDTONr+vQXwLQZqoUIyh9Xhhxyhm7uBjJoddjI8Z21zLNQtSwSyb74/qe
Yw/ec41t0dDksJkZvgkBgULRqtAy63Q51DvZKdXU73/YHC9wnld3OYLTur/6KwDq7eDmEGRIKgv1
vJzkhIPmULYB0wvqhkrqjJPSTCRaSkwx7YO6UHLgMRLDvarFEYkwyyLxHlwIZy7lePaLBbx4xYwE
dcPFvExH54vPTvn/FtQJnJbGtoK6LyFt6zWrYzstnNtVdu7iuEXFnQKnrLEn41edTJBS5eKCwyMP
Cx7TMG4LLFVZcJtMUHj3HMRJzFP1+vxvPZ3wU3WSN22unOb0SOw+dlMgogdjHWUwXlBNhcw6KhZ0
ZI5Frl9fJ3hlymQutWeVPx0ytbZMlzWTrCfRsrdppkBowLXoKM8UCL30tDM45YcUHM4q6gSL3rUq
QYZanSPcstsnrYPUtaPXpdYEvqGG28K9DJNsY7TEi/OdCrxCyi4fZ5h87W/y0aQ8h0REXBybj8DJ
c87DFi3wkhY7dxaXtULDaZaOTZ81WaVCb+pHrOg2zEvBZ1Gc8uqJOnnE5fRwSFs0NFy3E8K8521r
zHDYkORlbpEb9ZimBc7W41p1sAfd319T/mV1f73nPtt8BmHS6VcFL9VwJPASHYsxozkhnAMNaW96
+9+j+Z4jWncS2+DNwEPVUJJkCvy3lGZf0a+yAjPhCDXZEeEtBAixjj82zPGiqbXx3ORDAh+TZ0cm
sQ0X8zJkEW+h6tJQFaeR6vqbj5uflgoiTjIO8Rb0lx/yu7MI8+DvNq4PYqHPgAp+3tG4nyTaeSQ6
US1HHP0Q0a1uwEbef4Izmep2wgch16XV2V8/wWdwNPxqM0JnRTbf/eRv0uf6jev84JN/8KtNEQ+c
/M3B/XK7vnk4yxq/n6HsVQHHcP8ppxGJ0PJBd3plvQJJA2BVozvZCE2lyZla5ZwRyelAuQP7p0XK
YJDi6xNPCoFCjkU6mQca8aJBt5ABI2lFwbdB+N+a4zpcRFO4i6vRExLF2G45K6b0cHqMkCY0Z092
ffrFcasJtDqPOzMHygZ4X39+DTTbWcxMFk2uRFEZrBdTYc6mKzSfN2JVthg7gAnLNRvNUuxg7J51
bYuGFsMMd79TUsFBQyqzGF2HOSrSFClzgkdZkoa3SQRDXZA0ppwAur6+E0BHdS7TybxXFGfNcz0W
1uHx7YykzrUi24LI/rG12QbLDBXEZ+WI04yRmFMmShrrM2csZnruQAhnzXMjLKzDxbwMCcxbILQ0
EOrs5LIRNtkb6aWNwjeuxg9fx6Zw6FBLQVsXiicndcCr52SMJwzCcpJSLiQEygiYIu555DnZ9HJu
UKNJvRELtiOXTTTbAA5EG94bK92x5NNFO1AyblwFIAmRRZRUHY+/PnI4tOhkrOFghbzwPNBiufYJ
DBEPMib6+g4HpblbppN5DsdgmSdBl9U1qlKY0tqp4lu51+Ei2sJdGoeMMJhVE3TCVdZI1JGLcSqA
K2N2TgeOQCstX0VlaE0loIWFUcfva247i5l5s8Nj9llzmbhoTWTrbrrF2onGrMrWCYAJd4rGWIzt
ZfZ71rUtGla/erD7uMFjRuqsLNhYfdzGeuQEvPMs+VQnoGvuXRFSB5W4F6Y4GZl9fSeAVs8u08nM
VxT31L3rl+Hx7VQKwlFN1sOpeZz94Iyn0YRAQtSW1BIdAkvKpAQtjXdRxLO3f23Wf9pbPbaYlyFU
eos6lkYdKCWeoMuiDgWmJWQBkYdvJVGHr2NLOEkvrbtAUmw0xZgl2vMKcAauILLgSsdx9CzyqGjj
O8mWk+9YKl1mmQXVHL/dMxoSZWETjLdwzfUxrnkpYAIQ+uLOFupU2Mk1ctJa52JxxnZLYF2wMlmn
tTGCRWFL4TZKTsEhhEugEN3oBDkzMxmIUuIA43KMPM2Zr9mTaslOzTw6WBADQeOy3BGnmUqfnaMt
sD1cRFM4tGT3YA+7m9Xha7LU8mipBoH2bRW17ZWJRIrTiXDwNBDsREccIB5nDPNalDODpc36TzvD
Y4tZztf0BpQWAiWJctsJ1uLAhqh8t51V62Q7rPNDvr79xYfP+XFg55Nzg8U+gMkkm09ArT9vW+0n
NNi3on74l9cx7zW57zn+7hv4fGtWdsmBiQ6U46/1yezOikPUkgpngBRxd6Wi1j54z7KSrEjpwXGB
WBresEp98fqBak8nbcewa+0vKjsFANGKY6/9rGK047bbol1aQYJEi34FW94TG5LLEiIc7dgctkjJ
0bTDohM+U2O4DVrKXx5pVOCPCm2BouEi2sJdWvmGRCuRBZvZC8t0MlyEpIOd0wsrBVZWcCBV9/G9
4ewi5RRczQnt6SszZxLiSGJzFMQY+KMkwYiWNqVkmbacnRsOodV+B+sfW8zLUAe9QaKlkEicbB8/
fhjUHgRX4OjI4ssjsH38+XYnV487+QwtnU2Sfb3suwFkuxqDbI+TQ777ywa+gahbEPXfTfEknpo5
Rbz7axAODsfmbufuavel+7tBm1QJ0nGXEjE+aZKSKIQ67YlWsVLtg2FPbFX5Sb5r3jxIiV6KHLi7
x9bKLA0vMeeUn12JH4E3I0TQpShtk6KRwW8px2p/ZXSRUdcg+vk9gRtKFPgqzguV6PTdmPlwHGhM
G2PRgmbFA5zIgsIWzZmgLtFaUcEnEEq0OiThtWPWK59Cq1hmqOW2cJdGWCJRuj7Bp+WGnwgvnODe
eQ3izWl+lBpNpvMWVc/Y4ztISBZOJZXWebZDQiaxRJ3NBOTKJGhh4I8ciPB16mEsCYKxcyMhlKPu
YP1ji+kiofc5rP3N6sd8c/PbSr2jZ2BM3D7ifz3w+ac/lrKOa/95daCz799/8/6/3q825E73q3S7
bYv5+uXL7d1DVcIWVG7WW9Y3afXDxz/uv7zRYbr9t9WXzxmUA4IUgJ8Pt9/uJYi319ewxQ+/vYvr
h7v1r+/gg2/qUf/sf/vm1/tvtoL860aQNu65uDmb0qCFgnxCU8YY0ZWyXCUOkUqZlbtHC5JeR2W4
L5t7x8GMKLKwIu2cbgxp0VQW72btB4/vFVYHZa2wkbM9wy0P3hbQL5E+GwCxThIhowUbo2hw2fJg
0rmNM164xEey9sPFnGqcPwJ+z3/LK/1mnhHz/MMNhKZpY0AfRTtS4Eb+ncGuz7v++vlhTfxd/PRk
lmsj413+n6/ru5zetY2qu7iqA7xIgy9v3YK3I+qckgl0DlMCLPPiVIaGT3xa3ekTb7c32grBtU5z
ik2lw3H4hJT32BRqK0Lh1voCdrDBgTfMKYxKiJh91TH7QwXhZl8V76iwwnBG92bfuQTOPZNYalON
1pawlCUJICR85FT25yYW6O2Qapv94WJmmf0XT0a+mf2JZl/h9VN8OgPqcLxwllwAIBLK5ee1U/3X
UnVqKKbm5o5vFHvJuVGZLsroK5RlTPDlA2tlvSDRUjCW5mQ8FMpHNSVPPVM/eKQxo9hzQwBxtbn2
rBsJxyX6aMD7tJh++6f80noxFH6hP9RYWyORG8mtkL6kDvWisClZZSNL3KskipYGvJ7TRRhDPViN
TX58W+r4e6fHN2oYPzhiZv7Qcie0Kzkb2ioP7r5NuFSzNmfmKUHtjljGRKG8Z1THXJxtpcqHi2gL
h5aVil6WdbhJnSyrF7kIkRiV+/tmCCm8c4YSo00gNgdJcrKZ2ACmwDKuFD93llXhRRNiLMs6WEwX
0f05fL15+Lr68WuEHfvxt5tfV4y+o+cY+Px/BNa1ERhaQXJ+74iXi4gJebg//cf7d5UnqXoi7a0L
IY8MWOi6RJSJ6ECo3tOfv7yPX/zwbeCOVjIDUXzYvbuFJwbI0ZFK7k2YrQUjytb6Q2NzVOBEVGi8
uz0/9i9TV3/aloysZf/q7n/8bf1bffmcEjI7qUkxIROegiORCr0ph8leCoifffuUorRDJ8m0PaR/
eKI/rcRVj18+Zj/d/yqpv0uYFIo4znPNiPpkimIy5Cb7qUIZf14FTkm0ufEU3e0qMK7WIN2mXMM/
PHiI9KrSvp2mtNX93bfTqifaa1p8RtvW5GltEMqxkBlgNqXp80rGw39toYxjTz0uQNl9aXIByhzx
luc3ea0SrvOCKof5DKQpLy4wkWiebrijTwkBbrIvioqg0jEP+jEPfGV8D0Jn6jVgT8+54Do4abyl
2dvGxNjfMxpReDRy6trnKR6djynE3MRyElrRzER0c3rrlMIjkAmJ5UYEYn2xwSsGIKIVgQxV2xYO
m2NwoLKubjo5ZcY4uO7MI9sPbLe1xVRkSjwFP2+ksIRKrogsMQjAIwpM1bkjEIXiWjGWUx4sZn4E
8pZYnhKBmEur3FL4NbRYPsEYwnAvAwUIzufUCUBEcHEqQ/tKxMyyf0oLdYJbkcycK1JlcSPYK/sf
Pr5DGZHB5oHzNhqA09YI0qBFZryQ7Lkk3miIc0qpwY7PgifninbnNoLogLmD9Y8t5lQj+AcP//Y6
/rz6Q853P4NhA1PInkorVv+cfwXNra8Bh/jPb5bxNMvoLq27R+E3tWJ5jXJgAB1YiEnrOUGDRi8U
X0NlGmdgkFPG8A3xWTRceE+z5nGWntAU11Cq7uNxyyhMpjkyFqkKj2Q6WZVoJLHScKIrGW9SLhDA
mqZ2WClz9lkGGmWiOFj/2GKWWsYdSHyzjDMso8YvneWEu7Gxmh6VnIIAWfFYmhObBmmatoTYDcir
GCL8IlourxI2IgchavGpm4NqNbu0QEDjl51ywu1EozwFQs2YRQat8FaE3z1hHE2KyGkJvEfLnpMv
xspgWZzDLa7x/m05bYj24UxjG5n3zlkvm5wofYXhPk92fN5QM52UCKB7So20ge5HzSaqkgTUT5IR
nmTjIvGUQjQgHIhNowpentvn4Zeyw/WPLabr88D9rP79Tz+sPr7/z7Yn+/Mz5zOoMfOrwe/v/M6B
i7vOad2+IdIc5ayVc6o8n06ehi1i9cYsNgo8Tzh5+JWanJJQQEYxA35KLLkiomjlM7tSStzaTYjh
64VGSlcPt8deFfyDCcpymprVJ8tEXOgiPv68/vKlfu99vr7ddbID/Hk8qCFHX7ETwJaHxyO7Pdy1
0vF6fV8P7O8u9jzPhndHyxlVaU+ceyxZ53IdpjcrNJFoh6JsJW1OOm9/B11c5VJy3Da/N36jLQ/a
oi0bFU+PqtDJMecis8H6TjVoz9K3RXvZC6ljmXo3Um2ZTkdx259erW/WD0cH4+/3darX1y+7w/aX
v96tH7beAL66HyfW7Pt/oee3D31TjPpaJhcM1xDUulbzcvfId26STi5vaMx3ffkSB1zauTv8OMbt
/QcIDdMtgZfovr3D6vTGl8k73BSjgnV4NwGq26TcnA7IF5L5SGff+/jp+fC3gXTl9i6vf7rZ3Bzf
vxvR5ukFK5O1OVHAigCcC2BoaBRNQqS+ntF7CMXG3Nlg2p3TSifOrebN1BpYQm2jrqPJ4zwRRp61
yJ+jg0yOEAZsyj+ou5LeOJLs/Fd4mxHgFGJfONCpDcMC7IagPszBByHWFjFsUqAo9ciG/7tfZFWR
WVWvXmRmcZEv3aSYVfnFi3hrvKV82m3Jp++gRdsBl1yXFBXoqwdp8iVvLJCHZ0cz5B6wtxjU3ubt
b/G5EOezwNfSak4ayJbPtcV3305TA3LixD8JkBPniMTTjo/JrjCWWMpr8q+XgV+AZbvn/7F56p9f
h82D8PXNNLhsFVNv2TCgyQZwiJ9D5wd45I9wE34vLTgKShf0WQ1pdBlB+ZYLePYZ4ZwwAWagauwU
sgPHDjgKDR/2t3n+ElYg2m7238PGnGmM3Lp0tWMyFnOd+LLfwxVw/s3F+w8XYDzfgdX4etj3xWRI
Y5nZRZh+2U8BcwMs47guL7gXb7lxb8dLAbSW4GVw/if2od9vKbB/uwh7e3BXhtHQDDc/wF7djawF
+/OnOSWzlSkZKdcrSkv2a2C8y1ZLG6p02CXn1CjA8ZG3sHrFOKSDkjKhRI68SJNWefCajMU9d03B
+PrTXrFGGsLuL187kbj0wmjemeJirWQhy1Rl0jUZoUOUWYHrpEypyrnXrB8zhiyjm54SnAzSeMvg
OSZcp4zOsRqAYD5VsCbayU1RS3CXeKkiOStfnQzzmHn2aVh3LOnOU6v241mArGhc/zitD4ilZBY5
5+NASL/2xBgyEKIX3B5hzXYNi8EGz0PF7ienG42DI9ss6fPyfbORqkTJLUMrDqebj4Mjqzymm3q0
aRx4h/kSgwmH8u4wItgrNMKhkbcfz+QQG1qHL+ssMAJsA8jB8Y85tpbNa/S2mV/RsN7k+RWMtrsy
ml+NZK306jHol0o0uog0ZJP5oEBqD+D4xyGHNsLKqKS8uATnvgH5cbGz4a5uftblcFFB9IfBM64G
kaQaEmidQUqrUrU2uWL/Hy3HR5VZ5m4A0zAMpQY78Ai/5sBFqskDh9WfaznreJPsoCf1govGI1mW
jQEh7njN6+K0lizc1uSsqQSmSWnX/EcjgI6GCXQMJhwamcyssfl3uOg6Tl7YPffxMgHngOGvnK27
DkFZyci4lkM0PA0lcz5oBZxWS9ayBMectEjqQs82frNEctLt+qZrx5fy2Gm6/fGyXY+8u/gLsFWQ
XtZB8wT/EVIPsioxJKUdb035I7DAX486Ub/BMxAW1DHMD4Kl2xuwhMtd47Cv5Sa3/7cgx9d2twOk
hr+OmRHhutzd49EwupphNu0OSmd3zx5eK+0+ObSPDmCz5EH4IgddgC2DqIz5iF8rkTjPjNotImMz
FZWKOTDr2ap5A0+0lqPrnuvrBrz88370kz7f3v7j0yYB4VMsLYj3qW3V+FVX4frqv0/ckLr5OdIr
bnyWYmzfW4WQXmfHy6qY+NMs6PBmYXcTuPn4w8pub45WUL43rdmWCvJ5jKDC8ttgn+vRoYU/Xm3m
/4w6++rmObdlw6zbtVzufoBDD/x5A+Kswoe+fi7oxHkagtTTrJDJvKVxPODQ8oHHoUmzpOo0c/jy
irub4R/lx7sxJjB8vr1vdBrGYUwLJySNS1g8IWlrO4jCqgEXR2vXUeC9qUg4NPpisC+ID8rBx0ee
pBjcODI1UuM5LsjUnSCcSgHICP5FZwByikzZCoZaMUobm4KMhcEym/sNAF99rpSh5+2eRZN1ZjMN
yLBT1vITSq5WFGfhzCtVsjWrsrzHMc5/hrubU6t4PrgTEb+R6f/1lEIdvJJTYnW25f6YpuUsuOnS
OWdV7HBS0Mom7oGhapLcRC+kERlEkfclKmSg6ItyEXlXYRZUaiBBM1lF5UlIodFhY1POWwFu9sas
Y2e6wbA5r4EZU+BbZuWz4ZgfPF0EBs4ycmDWVPj1kzAty3wMxdS6NgnTMlJ3Gvmclsnt3RXwNxgm
38P1tzKQQ4oWmiuWrsM7oWQ25koR2pQkgsjB9GZbd5QtDo2UWga5r8D1XzRepuB4Bb+/M2vSBM20
YL5qlWOAvQEzpkbJtI+eC/nqNsFIk3nHcDFNVgkRSw8hNucNIdasNRcVwYJljAiR6SJQcJwMphms
j9pJIQIbVaU0mQfh1woRurHoid3bMJusJdjoJLBkj9l6pxiHRisDdNLts81pt4JMeTezh3DWrIKr
ze+wHSPGaF9LZdr4lvzOHTc+Bm29sMyDbYM0P3pp1qcnp55Fk3WsT1famfOuI7UQPMNh9zxgtUTT
RaDg6IGbJ6i1vUOGQ5CVDqCdUofVeqfmJDSCbhY3JbbndTJUurU+z3dX39vUIXya9NXX2zOHSafc
nyQNzyzlb7rB5ZQE9FkG9eNjidF7W2j+Vt7A+g14hdGJLF1ICaxzLpRXSqb4E/A3XaN3Fk3W8bek
bY0Vt2TT9mKgnGTNPmQ0F2K6CBScoploQf3YqQJ8q0MIOUYrkAza/cAYjpCW1/vRtscOD76o0CZL
pGq6g1IfJQB6I/QUEB7urSby59OR/EFGo4JUQMPMlh4zaRf0I8FGLlRbvPPKJX1sMc7ZNPrMz6HY
jKGtyhpvYk1DEAEkcWuwW+GkD7VwHoth3uZIDG21ikwwNGjYQBcWYtLcZdUZ2pplsCFEVTg4zEGA
JgRFaK12xQsvM3vVeI6l+0DOXvs6kUi/3C4IJh01F9Cgir3Jgrl0PGVoxsmlW1Ta86I5srjY+kQo
b7H6wil9cXCkILLL+lh8BVzfr+7uv8F5a61otlHQBiMk45uXFo4vTeeQkPRl7QJfdovyy+cfX69G
ttjcM/oQZYw8yYwYtTMAGpqMy3pb7AH8dn8FvtwDIbNRALOKilRQz8FJE3KBZ3DEJpKB5cGYbRXE
a6DRqT92YVreqZMYlU2+MKGdWkVAS+vIZZ0QsJPIQcY7nlwSEhva0gVI53TYBeYXfRIL09VaHlyS
WA/sPk6SY9xyY+PxJHoVi0+paqePu8HMgUaaGm7JeBWiJ0d03BllwTdlWEJ0F6Wn03qXXh0dBYY7
d0c4JvpidG5CEVKs/uRJRY4eMPY8ucedl7oFtsAp5yiJHBlsXPLhuIJo3yDGEZKp7G5FBdFjGmTM
ktkYHVB3RZK0o68dHBWkzSGKlKOVwfUyMHvZiTg0Uq+6ZQbKoesEW8WU4M4bgxkn/S0li666J/23
8a915MU512S77hdvnwXMLvcKNNJ1hB3bphzOgvY8iGaSBckWbc2BxgHmn0MrBIWFwD/E0pa3S+Fu
FawXY7XPxTA++znc5OvjzgnhftM868vt1c39s6zzlxUEf8gpwxHx+cHGOd7yISf33GUcE31tNj8y
s05BCFr8rihz2i8VEyUDDYo3tWBhmK4sEbQMRqL3++/nkWkTNUsiWTrYEYOJJcfkimRcMhZVLjUG
YWsxvKTwmqWDTpJW9ioyrDsv9JWFW+A1IcGFKnUyOQUFkgBR2NNF4ODOj9mdRRtS4LkFvtpkhpcp
TjPGtQtIG5oZDKRImeewHmYn3k5OEJMW7BdXLOPG7+Y5h+gVV3woQZlBKOcHkVkaGHOW1ZqViVij
yR4fvlm6+nlbcmItJyeIAa9WLqMfZI6wOsbUYE1gA3y4lUuVkrVHY/GODnvPwYSWQZxsr7X76NA+
O2jVJmyrqIYctM1BFuC4irssdHR5DtKZ87rmQNyf1zUncI6uiQ7czllTf16X0FIxVl1QCbswmn7b
mRhPvXXOvK71JJwtUh7NKPBtlBfZCRc797Mu1VYYrXLizAZnovA1GzCt4FelfX3VSwdH9gqZv/Z1
CoYOS7sVrTInyhfWby2LIKcl1m55uggMnKctSb8gwHYq1CC5stYIA84xdvcwPf8oQkkGQ/zyO5up
0wzU4YkV50FdrgJH7q1fEKk5ik+K4lmyEk63wZLnutDoG3a/IESDNDTmwdsoksq+YPVtfXCkhvdL
eo8TwdNShSyxWG0kOgOti5I0Df2y+xo8LVFIn1OGd/O86gBqMiXRY2PaZmFZmSLpNZmyuVjLHBU+
d9QMionuVzLfdFvSHXW1+ebpbhfezuhA6ZjkHhR+SBrjTjC/Sy5AxmzxQ9WFcOJd56hJT186+hXp
SvvOtOJWJavBL1EYp03XgeKzZEaiRyr7D5z54lQsDN7ODzOAD3PdotcagAopZZBMeS2tlLrKLGt6
sKVeJ6bh6QvY5/bWvaXtlTW7sBIIeTPpz2mArl2NTBWWM3r73HOfvaXYF9TJeakkuk2bEEC+iCX+
TemLgyMVhKcKVni0QgIP25QPo4KHeqIXjsChkYGoZxJ7ZNcHxZaZt9tmHayGAvwba0H7A3ZFHVnN
u4ep83KqUwhrtlliPjK3G+yVXJDC6Dg4lcpQjCwDq6IOIWufkgUXJ3Ak9tSTl2+Wrn3efuBLwTuF
cOlidKUMwBx1KC6awfnqB5uLBfSw1NYu5TEjE28R8lTgZrbi2H1yaB8dDFdqiCX5QYVQnM6GG+Zx
G4bMjZiDs1upvjYM0oM29dhOFwLO2s45LQqW5957R85sOJFnvhGgkQXpVAER7nu3Yr18exSap5yR
vW1/NP65TbG4bIPwnfnmkrviQlY1azgoXsfShg4oE1x1Spv8qiGm3tqRNpF4+j8DOeZMqqxb8lRl
SbVWgNgGalgfQy2x3beyBD4RVrf9wiURnqxQnn8e1ilWTxmq523IswBakTMzMcuMKNxqDqahxVy+
KVVxcJRdrdh5daBVcFFAmFRfsTL7KYWPwdm3jCwm39vKfpBD15S4czK0RLI1QY6Gh7L9FUOLLZ9K
h5wuJp/UcyzSKW1BtMGH88q2sFWWyqRNTiTZ0Sk9gYVDo1IJ9mhNs3Ex1sNLgKq5437r6BOrpUoT
Y/bC6mqzsqolirZYYnxlubqlybzzt5gmK0RbA0TFbhQ7r5Q0lnZ5IIFXEhYIny4CBUdWke9Rqy89
GAs1S5O1lWGt9ODU/eyp3dswW+CsCDB6nDY9A653ilFoglZRJ0pb1wi2sQ52Mtvx3YdtAvnFGWJM
UMnOe/BpvhDJNddRcKNVR1bwIKq04HRwcCir0K2Bl8q5ObCce/X6soKs8j6PJutkBTlFVLHzylI1
yzKAYxg9w6JT00Wg4CRtBh2kpsN7j2aUfrwE8VCjkNYVmScloNjT68MDRwzUvgbhISSO0JZJGzDL
l3nOgSALpxVbEUk9CPw7Ea0I0jKFJkZP1oHjo/UHErE8mNYBWxtsYNrlw6zyozkILHBno+U2Vi54
UDXoVFUOoPtiVK8X+G9koI2ONWRYeV5IY4OfGd72tRSjnPIcvTqbLAIHR4Zz+RMMlq86cqe4crwe
X2rvh9FQhOQs2ZfmfXKMrOLL8ie+tXlzLTgPNplJQlgWFVZk2OV4su5e8fPGtqux5XVhqWQszay/
f6RDxE84wyht0PD89smPoCxVkdYXa4zbBugrIA8xmQFc8jjU1hpUm+IGYIdoHDMmo1PIe3LtzaLN
IeXQdP2nFjNRypu/P2WU/mkQHsS/tw89QQQc4GnSSp7Cm6RoJGnAnmU1l06UNlabdKxZSCcj6BZY
Em8pG1LCuqpBGrW8pBIjpx/OX/s6Ydd5+fLyr0n3AR6caBWbCbF7ZwgVMuND8fPm5nBlglaVZYWm
o0zpuwbcsnL0090HsswqAaWSP86knEFCMjNB8eWV6Yc135V7rxzzlSOFkXMA0nbTGUXp+zXf4GBl
LTXstlyl4BwZhODLatP32cREpwwvOhWfV0EjfVexrBz95EksINK4NdzXiBXNd1F60sITC1MKkJOY
ba2+yiJjxeyrPkDSvhLLrD7iJIbMW1s0VpJZZSp7kmPEcjvw8SQWHVrTtsyjwHqd9KBxskRciSdK
oNVg6wXHQTyLNSKHc/okLlArDWWOn65u7u9u87fUwBnQK6LW4FVYwyacU00q98DNRXFsTx994ONl
9KW4xEwBwmzN6lYJq4LVA5jIavAqyyFnnocglQ0+gj1cMLO6dyH+Zik15m1VZ01bE+l/mp33Lzn+
7+TBTXg4cytrjQPTLICl7fMQpQ9DyUkKLg1jxU/blP32y2/vL9glu+SXSC1uQ04L5QXmwSmXW0ie
LDdRl4ox69RyRxGSRRZgsy5jg6+Hhf/gQdnWGUOzNVKOk41JlVhmFxx6u6Y2r0l4cPkww7RPOtJZ
EdjQqh6N9u5tjh5GUZCFvEou0Pu7922mpY2dFLk22jMDPH5cPjtj+2hs4hxzSbnIMnPaF4ZB624e
HdmVyw0R1FziIHgMqNGUkYESM1DSATG5wBrZbe4O5q5ZkytggfBgjF3jWfQALu++dmjPMWZU4lwp
GTE136cgKYHlQmOEaicVwXQPIVcQKasoSUZm5JM1YOMh2mBYNaDK1xCUrKJZHqI5yo7uxGhWYFqc
3Hc0GbZjzKCYyNnM8/NhF3SSWpkT27DSid4vGnfnlhYpKxI2HnIUkrPFq5KiCWj1Qie+yzsVHs+Q
hd9eStpAckWDjMdqDp6rT0pZlY7p0UtIb9DI3KzpVh0XTIBkNskG7WsvXaQXosehkVcRkkpFtiJ5
eKWwjvVmpfXS+1FodKa8nBq1L5Ki98SpLpye5dXlkkm3rlmLJLp1PQGYU9265kB7HkQzyTK9C3rB
Nl3nL/CwTdes1RJtuhoiqi7hVKLRdhKRsjqCTZSC7eWQ9hKuUGiemum4Jww6+ZLSeSVSEcweDro/
uAUTTctVIVpP6AJGQYnwsWJLBq3nPBiar50Xxuls9LNosk4F00FheV6bDC5DUDpmlhGjZH8RGDjB
Z5+gfg4pHF/NSg4y67UZ6IKTzHZi9zbMpkCbqyhdYJZ1mK13ilFotCmlGKJ5v1zVYZRXC4edLFSa
wpKZt1No9Jl3rLTenwl2sdOL32QblTeMy1TaPAwLnMord4kJB57Ca08kA5qQnaDPo8kqOSDo6z91
3sDHKrhOXEXGFTrWcLIIFBx9IzSl1of3//bQuzjmyiO3Jhj+0Jls++fL8cyPySdzTvxfj1+LJ6FI
RpNxBtKtpdCItBl3flP+vNjcEI1mw6/vf7m8KPef2eXFo3+ckzKaOTYwb80gpdEDiLs6ZG3a5atz
ERsI0/CSMfL5eAFVM7zavNVNjPWPNoYV7KhyV0PC300OmzrFAxtpykIby5aqV75Xk96TBTg00o9R
2NzKJk3HwW4LpelmUNS7tqNPNAmu4SddRDV74KFI1vtirNDpUGsdpuQ7A14i0MzFZLlnLhWZhDGe
M1l4Mq8uciWdwHoWTVaJXElnYarziv+syilqYBMe0D5Wk0Wg4DQtGLBiu8YBTVA18+nbXRmuvmz8
eQ+8p8GKGZSRYbA1h0HX1tsyicg1C95FcfHHbS7v8uf0ZfFZJzvsndrXjRjxxZvAQGaCidrzgDrn
G4dG2otqdsUYfJFJDujFdWc+e3FVKbAdC5MVhL6HX12AZeYYq5UVqdZ+aTbUZED2LJqsY0NDq+wz
q+jgmGjYhwDbgLDhdBEoOLI5yh61mn6ecN8n4L6PlwJUkHM5C/s4F+34wcv2b80YmsOpf/nbyKvj
ILV//+UD/Pr+Q/sFfrgp93+0dW1++x3W+mf4sf3tX3/9DX5C19ixhRetcXMQ2nJmSR0wWdK3u3ao
r39s+37C/oSbPFoyuxdt7pf+j7tr/XGj2PLf71/RyxeCdNup92NgkFjCLtGG3NXARle6QlY9E4t5
XTuTEIk/fk91e2badrna7rbjAQQo8at/deo8q87jnYEPvzPXb4P/ujkzaybQgx4BXuuAyi+xrOqP
ucQG9uYa02krAG81QbtgIEZy4W4qG5rlJ8cz58x9Xdk5rD0t/+62ur75+JmWPEy8VdmQDbhjWKtz
Ioix4KUXIXvp2FlHHl/ZVcsc4K09H37PaM8pCetzV9cn1IER8M5QbiRASof5gUpjsBFURnjtlHVO
VJW9syFkGMYv5TRONrJQUofoo3KUZlI4VxexCU61B1DbwfFcpXATjixmb9PNCChosJ7pyrVuNdl+
zhYAKA68XgGwvk2JjfKWXAQcAtUQ5T94Yd/5pKGaH0h713z7fjJHHlcxYOviarLNWnpMH+kxXdLj
xZkKIAqMKI6xuzeZP5a+8znx7Kn7QU97+BGAYOco2Wnj/RzIem/HziqsyQQLNcEI/kXPCeeT+/8y
cUFa2M4cOGBh378L7relvC5CqGaxYd9mfOvNvGuMYC0de5xFWg6vRiL9ufl04wKY60/pwuejmTWq
Jp3RrB2DdAgPC9vONaxczLCfzWx10uLX6vnN7fvn6fdu7uYuPL+c2ZQm8vzBnHdjtqqu78Wuk3wh
hEwnJjWYOFwHHkRttNY1FwYzBXFmtBy+COHfnidSyX2o6w6hFnfOheBBJ/4reVa3d80R3d9eBICa
zkOAvEDLZCznV61TlqjdsvdkMqk8bMTkb1/mRugemLqDLUzCUdYNAyzMY1sYY4klykPYl0vOLjsj
CVrxqJ6XLjgsEhoCzxh4XO/esDH7p8cRyUJLB9QgZPPrw+2eXXrvv80uL6uZvwSP/3LW8OH7u+vr
cLnYDmSnoL4fyPJBU5ec8l+r/7q8W7xrr+Th7yd5evD/cRLyG/d+9mH3DTisHP/SFF6AF1uhapnk
CnIDCrtRmZ8LxT9i9fHdzL1LIOZhByY8znaASnUze/kprT8FiY0tW6TsPPiR6+CS3s1jOrh+3SeO
N9dV+H22aJRxLmo9g/XY2bVvTXazu/cJMC1WWCkozKwvcYSl/fzu7n3zcH/z8boh8s2lzwKvnoFh
BScjk9+YkJXvfYcguydLiv+XpAFL+/J/173FrXgOpZ+WeJJTsFhECEk+VcCksHeLG/dbc35xVr18
/cMva7jOVBYaxwc/kbjo8FArrZsP1hPRc9A/4MGHc5QBHj+4JjuCdww4i3O8mcDbgt/HZ624uum6
Yvf7ib0C5QR2yNH/ch6qFDzVPSHP+tK3+477s9BksWdql47lE3hDFRfYaqdoz62EZdZrplVqnxLA
7QPfzxERRFCeO6NOnZeVaFKUgVE0GRAkJEBlZt+jPCbXbifN6URMMiE2a8VXF5EFVz4j61KrCa0f
BXDaFcCLZp6NISgGlLqCds5a8t8466qNfa4sPt8iHv2WPUPh5MFcJv/jU5WqItItBLyytuCvYYca
tX990zjMOUcsrax4xSaK2QuHSUHQE4mGaJlWAUYpI7NMecr7Euj7NEseWjGGEjtnAiilA3JYa056
jt4xi9KnAyQAaj2OkSFqqAzeQazuTp4dkWhS9HBH0WSQApSoeEoixmVHBIIoxRJ7w3OtkbuLyIIr
J6ZuodYydSn6SDUBBS/6zkn6uCYPrbyR2xI3usL/cF1YP1wXNo5SOuEbpRNw8a5L7Hz3j8HdNE5j
G8165vr6nRcYB4ejQcR4SrQSTjAJm8uiUFHzzIDEzy14uKysx9BkmOCVr3jEuHwIZa2m3CumaS4f
oruILLhyp1CRuwBL3N0MCzuasy9pMQVpyx626oAILwPz4MLb9TaVmyPTy7ych1aMQ7bMrcgVHGAU
HTVKYd/j7MNHuIfPymipx6DHg8KEChEFM4yIJyBy5W6Ro2gyTOTKBwRi3J2z8s5qBB4XkjmR6y4i
D66YgtSlVjoeWM7xc2BYg7I68ui7iUfLsdAjffcDYFoe/M4/LbdqOfQXPn6205FjFla5x19xSAyz
nDJJrPehrxirT8Cy0Ipz/pjQ2w5P2trMtw+1mbukNLffaUS7W6a5fD2N45kt3GI2nf37epw/IYu9
hER+qllGkDlHEESIyIjtmf6ipcfeIaS0p5Y4n2RHMxII55R4hk6v3HoODsbQZJhyk8U2FXJc42Ck
4B8crHcyN2u2u4gsuJ5DgK5YLI98zWyRgvP36apqCjRoswMXk6vLM4onhNccV/W3mXcFwhPGa4xQ
eh/e+mAWsw8h/P4+vUvIhNT5HS3P8yli3HiKmBBSE54QpM9OAWZ6HWMywarmYl9oZcenNFZQMO0Q
ZUaTjWqudYXXJ3R5aGUT0aVaKslNzwrDSAe7XmOq1t8gCE1kzdjG65xMWE3y/m250mlTTf/z/ofD
7y40de7Tpro5zM+q/wbF8/By9fL1Lz9cvP7u1fSHi4t/XJxV/6q+BxZNDVQm6Q/RzC7v5uHZF/8T
PlWP6jmVS8fmzmUGutrcfvFVLrliAPBHQsNeg0ZpSMlREiDakKx9eUl8jNQE05pkuVDxosqTWy8G
Wns0D1c3H8KRzNueFk3xYgKG3PkcWhJKjOXSRhd75rtpTr0JXEXjIeoSnHHpLRJpigmEGJnOwZ/Z
oqlyu5lRNBlk0ZQoBqFy3Nm8E0hFUG0akdzRVHcRWXDlioEVYdjPoh3AXqhyftGWrVwGytpBiMJY
NLrPQe5j6Sy0chXCCt2ejr3YB/VR7UVjKMomYm+shzQR5QQOmbsS6ZiIxV7hT9co1A+m4Bz+myRk
NSITd3MFO2BSd5cza8AVkkHsbSvKrT/k7gWNSNLgHHHY9MxoS41CDfeeEIIY0dZHRFxkQYE/hmk4
dXVZoknxaGcUTYbZinKAIcddY2BwikUMFMdsOUF3EXlwO3PQarPWfIeNYJ0NxAUZyOqUtm3fyWHS
5aGIW3ZwGVIQpymJwhFj+nps9HByFlr5ZFyKjBL5cLWuQuBHowGXtQb+NjVzgdfKM10bimRAUSBE
6Wp3K+CFeHVzff5N+/dvvwGumxl7Gb79pkn4afpdnX8RFyBL5m344vm33zx//Mjz5bf2VS+aFDsP
ynwHtFxKBI+aMOMIUz3qBaTacuGloih6b7Vk0TJFgJ+cC1SceqxboknZuRpDk0HqRZfb0MoB1W0d
9cKsoVxZT53IqZfuIrLgWFm9iIx6efPTtvY9XAShrFCRq9VWwtlvZPGUK8W37N6yUhyMNLaEwKN6
Z3j3cPEaNHYGfl/PKE+Za5yXhKFefLp2dWphZs1in/PT9qnlXuxy525U1FhsvcOEsp7OPN47EVhU
JlgSQNOapHKtEIhHC4r7pIkQS5oU8w5G0WRfEV8CKuuccR26PAWzA2ER8OhmD+LVRWTBlcvButRK
GztJ7Dp9YNeLM86V4MRGju19G7N4XwPx8LF0O3N5Wd1cX86uAwQafiMjf4ml6Psp9MeobaBF468G
NEhaLWD1VEQTIzJW5eqIu5TK4yvePalMaL36fOQkk0BDqVGPmVZBICWNQRCQg4NpuaXMeKUCxOdU
GX6iOuIlGYq3DYPIMJBfipKhxh0SAWm4wwrFaDaHa64uIguOFcPhsaLCiipU7dE5vYkc5uHfd2Bj
p+nY5e42rd5jRpAxwrDcPKFeUWFlRdHBl3++Z04HImzUNiwJ9ePmB4/QY6yFz4tZVIPgL6sXqtuZ
P6skeJXVM9cmfp23LSK+ui/+afupYiIngGSCzxhbP5g6GsjGwrad0IKfLiED4mbfpze3789fp1KD
xRReO0+LyAIrF8woBqDD+5Y5kx6bejtNVuvX1OMjzD40dWEN1kSHj/MZKMbkInqbEnZ/v8o7WuVW
qIo/PjSvlbgE/cos4y729OHyjkehBPhWgXrmjVbBp5nkwH7wJ36qJg9LMhSz7AeRYZiG0mUNNS7H
DcdgJeUyzQTI3Ul3FpEDh8upuF0OfXF3dbviKgEL/vOnV6ADfaAIcCgFwdkaHy9CWwT3Lhgf5llX
6tgQktisfGmL3OByv4vROO5bK+8OqJzho+QmBz+EkKnemSPmgiF9Fxh9QpyHVqbVEI37WBOanPIH
6px1RGzxHth7sjHz9BHSwYzAPPibpAk6ZdLrIcKyiDh9soZP5nm7nI8y0vfB5XGPakxxP4+OKkKM
pTY34bHP7cHl0nFVKu430kdqUx4N62uU1xcdZKHporewJehedjHHmluHnMF2PW7Z7DtQPnzYhIb7
DvBVLnGuOZlpEuoHZrctn1zWNTtnchHLGMGOU79BoTXnwWBOJfJcChFRAB1kOajgSAGa1lqQE5/O
JJqUDfcYmgyQ9wSoeDqjx2W3+SBk9IxSkukttrqIHDhdLlPZQq3lPJlgLdNWeNj2HrHq45o8tKIb
rnM5O41YreWjWs2dDErWDNlQB2ldzaXEddAUXhaUMUd2SNj5kOzPla/Ddbo08fuKqi43htc7p6hQ
4bBTBlmlew5SLZJEY4NioLBHRGBChIrKuhitpeikV7EtTUhRcY6iySBR1aQYfehxJzIQ2iOhDWcC
i9xBamcRWXDlcys9PG3nIImoozEeLxF1Ca2YWLSF2Zbl9lpS5LSMpLeXeJ/QZaGV5wjqJ5dYtDfq
IyYWrevlHdJRh8E/TK4RPJtMKC1WPuudc1CMAleeao4s6euvQB23UrHk0HrrPBdcGJXuIDGhNGT6
K3w2Q0DaPv+FvRhDjwGGIAEq+x7jcnK4hABDRpPqqnKX5p1F5MBxUrqT5YjsSi2I1dL1vEeW92QA
a+KxEAqczChgQ3X6BiacC4IkAq/upNzDi3OSx9FjEPfwYmtPjva43cgVplt4mJeGg+uc4Z7uInLg
RLHHEcfZMUAP0eoBej8sUZRSh1ZQlPcsVQkbRRQKIvQce4tAIKiXOEhCkeQoGmW4B86SlqYpaqd1
hxNNSoHiOJoM4mNRLDyHCG5knTfzCoIwQtnm7PbVRWTB0aIW3EKt1p9T0iKlBZfO9bVP6uOaPLSi
QupOCf4ckStw6s309uZjmN/sU22yXErJa15ZSk/vgailRBKDE7zuQq97Kp5zox1oCO6UTQfzDiMt
KKg8qa06aYpfS5NiLfY4mgyT0+JdPcfj7A1sAI2ahsjV5mjv1UVkwfGyViMnD1vHYTxq2JqgDRHA
5W0Ax8aIgLR1vU2SeoQuC03sLAdPJmzdD/URw9YVpbxbzDoA+8FiVtozj5DiPx6agsK2zm78zFWL
lB5yB4RKQQ2x1hrPGHem4Ya387Tgh48Aa16G0NzP3l0DxaprAFWFD6mt2TOMm7QtAUH5IjVW84v1
TqdPBiKQdTvENDuitIMYc+Djy2lytcP1H380v53yl6tn/uYqJd6gr5bT4Kbtc8+r70H33VyGZ29e
f//3imuEtzy3FJKMee4vQIS/VxCt5h8scelKkWO2s7F03kWPmfC2b4gJDlyA7oNtxAp7UH/GqkDA
dQsM8OkTOxCJJmX/cAxNBjgQCVDp2BYoObIBA/KYkBACyjVg6C4iB06Vvenu9LY3PzXPTf25PwY/
ffOfL6Yt1y7S+TqNRPAoQsTsvt/M9i+cJe4/r77cqRbnGQgDmNPLCqTFzNJ07yax76zaLWFPtkXd
hTV2ijR+vlg5SmLUSCLTCGWVN7Lets3bp+8/3YZFq+bZhMha6GQAHt6eXd1epnd5SgOotVi+2faQ
bL9HiIRvilqQ9OYcHtf6LnqCBVjblRdparVc48aWt+uZLsdNpLcln2CcNdCHosU9QzZqe/X5abZF
1WvMf/zu9YtXP0xfvn7z3auXL5Ix//ni607Lztf/9+pVzkofYwEHM+NH5bQngm3dQd/kPk0nmC15
c1dP/FjoSj7wUbB1x6B35y9jDipaEOa4+XOA3Duk2GQE+LlGSyHx+H67BkGAR3SNJd7yTawgwsgE
vLDM4rRI3h0Ptro657WNXuoYkfir6PKD0OKUuvzgCzikvjwepz0RbEfT5UdBdyA1uTu2LWoSUw1B
j5JCRvrnAPk0dbmCiL54MCh3jT2EIIZH6x0y/GnFHrBGUbytlFv9moiCExhFCc7NX8JeHYoWJ7NX
x1jAwWzCUTntiWA7jr06FrpDmIK9sG0xBUEwKxV11OPj2KuDg3yy9qrYw5fLrX5NaprhpLNUUvuX
0eWHoMVJdfmhF3BQfXk0Tnsi2I6ny4+B7lBqcmdsW9SkgR+lVBorCf5zgHySupzwiWClSxmBdo09
UvNrTIkklMUnFXukNRbDSIG2+jWeS6MxM9q6+FewVwejxans1VEWcCibcFxOeyLYjmKvjobuAKZg
P2xbTAGRAfRiEAos658D5JO1V8UQS6Ctfg1LeawhaKfVXyL2OBgtTqrLD72Ag+rLo3HaE8F2PF1+
DHSHUpM7Y9uiJimTqYmWZs7pPwfIJ6nLqZywYnGkyBcJWd/WCKUQYI8xGYvzxbweV1DUIC51bhW7
F88AOqKRZJK5vlbnCjstuQMwmljHiEMII+2Exx4rZk6bZ9jQpBhBjqLJ/nmGDaBSBogYW1DUeJqK
SedzhQrdRWTBld20bNUOcG7D8skvOb+DELpaXN335G5es7DVv7XVPAIbbgW2dWRW1ZKC+rZSuZoi
T9MQKoQEOUx9XbOYUnXUtq1vywYsMVwFBoTC60XFGz3Se0QgD63UyUfsXj5DvaEuNSDRGzOg10uK
CGNYS+swJU2Ct+UYccpSrYP2/qTD5Zc0KQvGGJoMk1RZylMXI0uKtHfUSysUxjbXCaOziCw4Vdb1
pZqYiBR31ilqbd9s5T6uyUIr9i8U3dTuQUrEYGKoprHm2MH/CAUPNTJSO8YVpphG68LhlEix55bY
PU/dOJW6ooeo8PrUhTVJ5UozEbSRSqsoAg4qOOo8ltZ4ILs7vaQWp5iNo8kgSeWo7KqNy92PlLHg
jbGR5op0u4vIgiuOGk99cDbF4YOf1bN0rOzv3P3MNUQcR2ArrRe8ZkjJ2ipiam+ZksYyDCxSLb3I
3USklTUAVCW+ScHy+XOQvJbUjbw9X3i3r8DwYrf8bcyxHB/AjUSWO2xtX4+ZPiHJQyvrzJ3nUjAv
gkojqa1eV6Brshyjdt5yiy3oS4IMJdRKi4RVglFQ7ieXZV4sexlHk2GyXGxmKvC4WR3WBnA9RaDY
5fzj7iKy4IptNlao9ebFy8mjCF+cgTRyAtKIozMPV1Ddz5xVP1+kW6edZPfZRRrHmLr9VIv3N3Pz
Nnz15ddVM+fm0thwmX5o87apWUExeN95Be0O/2Tmv6XtBeTxZr66nupZIur540nb/ffr9AM1Iww0
mEe2JtTowASILY6b9XMN5p15dAfMQ/RqIuy0Iew5OCbL4Snn/6oyB4cHxLu4Ar3yU9W4Q2ARpo8f
XMw7dI0WPC5wxmppvKi9B9ZBWphacMclB30cPa6uw8fpHnbkcY2/Fq1DfvmlNn+rKuVq2pzivjjD
wPbMBlCWqKeLEwL3gzDNBaIIB4MdeKSOGmIIJ1LkZkt/TnVanK6x+9qHqc7imCOBB3TV7ZYwcpt6
hhAkXS5g6S4iC644cVPgPQa0NF2QE7K14UfEeuI1I0r+P3VX+9y2jfT/FT73pclMpfIVJNXpB8dp
U88kqR876XSmk+GAAGjxiSTqSMmJ73L/+7MLkrIsgRApkXIu7aU+iyJ+WCwW+4ZdmOp+5d/tvaVE
GGhFo92hSGnl7txsIwTnERp6TpyElB0DLtRqkXYHtxHKHB5vSRNYW9smYQj0S+z9soxtwGl3/Da4
tii+7eHf+8LNBIwzFiTMtz2fGS+QTye+Y7uOCUeL5YVslCQWGxHHZSPfSwISe17i+uzlZoov2gqV
l12p0W6pDsypEgb/Ron2I4//E514dn28fWW4ExP/UQEnpvbcsjuU/sSJFTs7wMPykZwKhyv6pB0m
KzG1lvg2utYwnrZI231YjUIr4O0OTqF6vDldgP4mY9zENx2fMWYqykG1oJDe0rQ7VOyrsd2n+WqN
B2f6L9yhITEpoyHxgdeOAqg9A+wOdnoNcDl9KFI82rHESFpIRUVmKjsOMD91HbHf+acFUG0PS2J3
6HxRHQXxw8ZF7zPfIgHjPPaPgqY/pTrYRwBte40xE47VBDQTGBbYGYTpUZtV2/EMPu2McrPQFSvG
1OYkdKjnhMecp0RbbpPYHdSRXYBPORFYCa2cxLb5cTh1tY+6K9O7fpRDB58Sk6s30bvZYx8X80cr
kiYrMZgdSbQd6Ymjiuh2cUxjpxju+3RkuYCJc5GM4ti0RmAyAD2ZLXjAe3NMkwPRLV2bTstiglGQ
FYF1KABwyIGlhqY9qZ3WMVcLi3haPknEpu9hg1EoODOdxHIFSFYR+L4DWhGxuENB6ROgcz+7n41o
E7ZPo8lRxiLRh9uck+PQYUJEzIWyQOv2JJTgtN1nQHafuFMtJ4jjQIgRSMlkJIKYjIIwCUc+F34c
eqA9YC3Uvnaqr6vz2rT05U71GSeUBswXm/sOTTv10BZQQ9OeLk7rmGvgEB8OD98kyQH3jeN4NktA
LYupAB4wqRABx0x74QSmL76DnRpodb+TaHLcTtX24gNF98Sd6pss4cA1RLVTtyehBBfqmVsXhzZB
PhCHMjM4GO45xDU70Dysbm/p06Gc1mFKk4gkDuEUtJwDbQUD1wG1XtigNMcscWNOQe4nVhxzHiZw
2u4zdxTxbG5G0f18mZ+HySva6AXsKbTpyuQVIP1xdFoIl3GLsAA0GVeofJfbk9gD5zljV9ukpYei
ihdc9hpM1guZpm28zeCRleSszAC1dy1+NAoc4xdHtkHHPz+WJ911NeKLx092ld9qDjqxNnRhyHAc
hLAVGmtX+mch8/X+16YCXhkDQzwLoN111wHcZwXSzAukkRnOMzENM3iSF7CQcgMvBIjQCXT2OSCs
dnmUi3s6S7k0tyMkJLqpfDDDuOeHrl8LpcfHABQ2QQREqMXNjOpFBdadXU2FDHfNZALvUbj6Zomb
beA16NnDCM8EoGfKpCzbTKIPeXGeierkhY2FZOFcM7U84mlbyDgGj8uGnH/v9+H89K2HRpmhbJOi
bWpG3NYJFIx6oC+Apk42JfKaIqAeEJcxT3gW8HhMLdCGEjN2bJfErmM9a3X4iibaw/wkmnTVLkpA
2qZmxD0tqUTEQpCYeb7rqoq7bk9CCc7TgvN2+7/iyPfzIvoyTRlQK5ebJgIxwdal0/FmQogQwhfM
I4TXySa/t/nuAN3YzzLHkjfqz7FtM04DBinkpAi2YX9+XPA5CE3sbYEvKwzYacbfuykkJS6iE23E
875dYG/msQRVvR79q3ZMmJ9QQsPYenL1DH76spBnH6aCwEEHbCp71JfX5uTJx9Y5bv2Sb1+0lTa7
ovkRv4aurfBvM279zGAM2gdgWX9/SoFDZKH77B4pD9JM5KsqpLguOzVEDMh+J5CB5FAFfms5owuD
wdRUj8Kv/21kMy65byboPa7lLwamIP0sk3vw9zTP0ycfSDaLVlkErCCTxfCDRNjUsxJPSRz5uvW8
LtRfwDcWmVFi2AxUvd/4j5qS2gBVe0p+Mj4WOJkvsxiOYJbN52JR6nmFzDZj0ywrSpaWPDGlhQGS
eGFUk+UGPIRfTgvZXYDew5zwg3H14ixP4dABZY/O7uDn1XQ+8HyOkE/9D95WCLlj19WGGEjrlnQx
Cz1qEfRCHsiXDUDMAGbPTRyX24npUy+0EuYLk8VOEj/rfbKKJtoFOYkmR6g2CEgbUyentekLTeJa
jhd71NuPoz+dhAqcr+cgX9u5JfDCmCTc497BWyoHGjvuQ/PGbqDrG0781gvpUDPE/jJxeKhveOI4
gc+Y7cZhwuHwsmxQGIG/3YAKbj2v67uiidYreBJNjmBuBKSNmvmnMTcVGAUKPCfkQnUFa2sSKnCe
XkcLfA1zuwlzg8RkZhIeiusc4hoVtMDRxjCCQBE/w9NgVEzXK559WYzoHWqC7SNd1bDaSMX2sDVF
ihm9FxV/N3iYMZrFgyQIN1GCC77xeCAzlR6bKg9ejUvLRtu45EFaUyEqqQCyKLGYY1ueoHZ9pVBq
paAgoRekfG4if2eU3/mSzgBS9R50LVnF/8AfNTqttRyEZcOtKIHV+GTM0rvpSv4cgeYe8QzsjwrG
xAA6zHCHvcsWKZAjynNejNH7sl4ioQqg9UbLv7l5XZSkmz0cCWu+NcwnoxqnoImI0M9Sia3ZgxRX
vQzxSg4xwYngNGEK5b2Dd2VYt1XBrg3DgGj43Auqi5xN0yeAsvj/BFv1CkpfjWCbhW/FSorZ0m6q
WkLDAOXBArIn8AJq+zwMhLXNWRcxyiZkE9ANlV9WA9Na0CcBO/LUCDwtrcIjUhtqMQUCCrWi0Aa1
R7CABZbqFtHWPJT4iF5MtmV7aUMc5pyuo+nZuZXZ3QKUNmys6kT/dAk4pWAjWDG3nQNaF+Ombyee
K7iwKOfCTxLL47HrYoYcrFCpdZWJHWe8LlKRQXswHUWG47aM/q572CH1W3WDNjY58bgwHXs/mfTp
JFTgQuu7EzGh/opX2CEnQ2ocq5R9nonoMdgHeo9PqeOY3I0dVWLGISETansDP0HYhMAGxdjxhWM6
Vlm8bjTNss8gIW7Wi8XGicHRkYgfSFGxdS2tcjONiGN5I7Dr2QgOvHjEYlB8g1CECVG4wyvg7Ujb
GfivXwVbV/4XAPyD1HmX+BcXbAb7eYSz+cky0S+3uoc1+sFAfdSg+V1h/G2M8AvI1D8bbeTgz8YI
1q3IFj8bbCboYqNe790bLGeuT8p4Fj7Xp/qGR6RlPBr4YcwssGPwv8cwuKfrqvgE2t7Q3Iup5VnE
SdhurG3X/Dp0fOxDI8DCltYyDHuIPtrWxLXGxNRtFrPy80f/Enn2rfw0SuGsR5ksfFBKmRUEFvsm
zYf1slqyv6/gEUQEvL5YiBmcdKvpJ+Xw2svarYdXc44KhTwtfFtgnR3XVSlf2y8eEPIOxf66uL4y
bn+9+fPXG+P2w8XNh6v3b85PMRUKTCIVFvNi23J4ojpJ+qRYCwTVfssWUfFQgEiK4ixblQoWamJR
ns3EL3MKH+XnW79rmsuQQLrAgF6WPxhJOhMNK6gzD09cQTUOWbjA9mwv8LHJ+FFr2AtolZygs1RC
rhT+SoipSadNO+pDXKjBoDOPeDY1iUWpnRxDvw7I2wP5NqXFdBXPoq/z2SfsJgxvlSKPr/gZUchP
efxJ6nN1qJBHMi8nygXuT+MXlQfgjKgqFxfAkprU7OE5EZXSKSpYni5XGA3dd3CdiTR0TPM5cLKW
GDrT7tit/zajMk/t9e+X1wasCKhYDVteZ7uduOUVIGShgkRwnzmcEFW9psNbXadXPkV8GEDpYFvz
KVty2OJ0fTfdrk78EVTUMf4ViTzP8he2+aPxD9TN/wH/fVTP8euj8v1jHv/jJfBHOXDTI5Ny4vgI
pnug4v9QA6y5asDl2mGWG1GixfMdM/pysWpgll60WTWzKECgEUItC9R76lrefuWDFsyivUZ6/Oa6
u0OouLB1koDkSDXVtAbzyVusAQrGzyzhEoolCEJ+FO3a424LY2PM4cueJtJMzoxhKa+vriJdksfZ
QMQ5XfCJ8ZdYlKQ5M4x4nc54tFjPYyzQ7pk+sZdnhjC9q7KYCrGaGGcefMMD1tgZcAvviJHLqWDy
YjV70qKmQYjoogQnCpEGILIqjiCmi3VzraPOakd3xesp6nYgqgXDS1lGdfOzmKP/qvQDPtploxHG
yeQJC2TA9EnYazBl457OGpRBR5c69F8Mtj1H1m7LIr3DvLuqZUOD5ujovKEncmQDEMzWTkIXI7PU
VBS+aMORvaBuoNt6WTOCKftLweIK47N4aKKgLjWsJwo2QsLXMC9wsV5YHB5ldGsD8b04LfBYzOZG
eTIZd2IhQFnIcjU5tSH4Pr0XDajwTYHpUydxfM+kx1C0nynsqvdVOKj6NZyzILwaSNiLLdqg4Ktg
YLQe64Jwj3PqqGp+HqSZNpvgKeY2ECqh/SpdUJDMdLkUNJf3tmIB0j7PBVvNwFZLF5+F2gnUAU8X
E+0uRadGVYdlOVuDftMgVrR3Jk620lQ40FAzhckpTSjzVdGiw6vYHnQrDHW5HTA2GC1Xnae4eHje
/pQtVz/hONk6Z+KnYi5jo7fv6nepEAak/d7oivBmzOiSxukMhAz2N1wvPi8wDLn57YNx8eGPd1eX
0fXFx9tfzwXv02a5YS15nqLN9utfHwAeh59kNVvxddWIpqXi15VY9SpJKMV6ucxyWStQyOAx+kZf
qiCFHXx9A6zf7U10e3nx/vtEdvHhw8Xl798ntte/nhObiuWvbv/YZvm0yBrRDM3yCKUtyztjV1tw
sD8CXd6+fbNNIVbM7hrxDE0iCaY9jTyvvRJ7ktz8348Xb59Izn+u6awR0eCyU8JpT6Yu/oezn37D
wFOt4m8Y7d1aRIz+NuIZeg0lmA5LGLQ3N4cR5ZcgyK/ev/kOwR3krwHgqfjr/W+32+y1SBSqaIVm
aO5CKO2Zy/fOo37+/upim0DTmDaiGZpACKU9gQJt8eb+CPQazbZtEkk7rhHR0EQq4XQgkz+cHdiD
HBgCnmoV3/75Ltth9dn9PGtgd4lq6JWsIbVfy7CDj/o0/fzy9uqphs6KtBHR8Do6wulApvA8uous
ublFJfz/jXiGJlJZALQljdyxpb1i0OP5C8bm9fWTI1is6FIRDK0wDX4Kl4A6UEp7JfeZBegw8JoE
6J5cQBHaIBsqZOcQot3kgzu2vf41hx5XdAh4DSu6s5aNaM6wil3XT6aP9Q7pfbYyitq9vVVFbePP
xju/YsFhZR+d3zwTZcEV8TXdLaLXfUmPDOwBNlnrTRHB6G38FpG8GoaBLSlMJxBxEHtO9wzubozX
BsK36r58lM6XM1zp+gJ99XRaYGG/ArmF4/11ufr5elHX0ZPPjnn882OmYTyji8+a9MKhFn6bqaer
1VKXV4AYBoyKN0KRW4xYIggS13a7X8PoDbeGdmVa8yjD7OrviI6NsDCwaoWuxRzGYqEq4fE8NH2L
0Bdlacv0q1FkICNVCa84/oC3gZQw8Ksg6m2e4P+6x8MrzG3zo1tAqFM214yJokjWM1jmGGuF1o+v
sonx8f3VX9rrir3Ss3E9ZeI93kdoWM0BbwYpQGCqOTcT26Ekpv5+Q6Y2a9k+FHAYQKuVvAKLw7Bs
H5Nhx9YkUGTE9kbJpnzI3y+epgaffzUbochkETPghIfCJN2zpganHSp+i2wxAuD1zVQ1+bQFFfsi
nwINZuB6tpf4puWavHtSf2/Q93P41kvj9as2rDck7dQ44LtxSGxuxnESHHcudADdCkOdwl5dieRx
9XRDUAwRtJf+XRCo6kefc/x5xsVkkUWzdJ6q7amBBobdNaeryde5Io483KibOp3RapoW8nrwRH3B
rhuG9lu1qEubY3JrfQdPLMBUbrAn+0Gh3q8aMPACS9iWGdq28JU17A5uWm2zmx3krYFUC/k6xtWW
Kew0XRQTY38fGS+q7FbkBtv0QrWHY0iU71CRyQXDmmhcFos9Fqbjto8KdoDZS6mICt1QRNzUDisr
7tffUS25Glt7V/dzUK6DRtWVctciRzFbXvqXbhsUk28ulUBIe3OVx1gY2HixXgIMEYnF/UsAQEKX
uwHlfhCL6hFQ2OHviYE/R6UEiTYa/hlRbNxI5xz8aeWz+jqvrHuWZ/PqGjbqG2WtiqOqoamm4frt
M+c6TwPh4wVhOAn+i2eB9/yl/0e6kcsthV+VpZuU+7RnOIrtgWXIcx7JigRzMc/yh6i8SIXRDTWk
9g7Pk3ashMSW6zOC2GzYpmG1fes6D1uKy8t60Mvrj4Y5MRLhJjzEfu9JAlwbUDFKEuBfGgfA/4kZ
uEGiBtc+d+A4cNbEICYcbLFJR57HrRE3uTkKfRKOwDT1BXYkc+1QDa5XIacAZ0+MwE0S33PoKHQA
XGJb3iigdjyKmWkllmBmnLhqcO1Pw+PAOUA51/Vj7pERYTwe2TFNRmYgnBHx4Ow0WSA8ZivBhe2N
0JP2W3nnTb7ojDg2W66+cqceu1cxWOny9R2/UgQ+BvmmWFOYFkXGUml7gLZfZDNRPTd+XNlF9kWN
dngJSYsp2FZLLCIDv5jmcM6o41MDgdkeV0aG0OTYwFIfHP0iKRfxL9mfRJ4U9eDj56LJ1gJVT9/P
z0GJenz5CC7Gn1V8tGHw9pZ9h8E/1oPLhnPYtThLAIgSgtehxF8HCPi3lCTiPmWwl+mCA58+Rt3u
SzWx0sngNxMwfA9Xsj7DDLCNM+CJSi8JFixm/1ynmMkhGzyDhQ5L+liHFGuBUpPQEWdw9HoO90bc
C9yR55IkiH2bh7Zb3pdfZZ9Fg0zteQqybdSnI3C+AMGf8olhvjRu5MYdL5kyEuaZvSpfezS/EbKa
0LA0/65MvaO53/2eTL3vZBZK22qeYWVrQT8LHt3HXC0Nh8EhB0d+oAtZJ+sz5oVhWQ3ZNH5EVyuK
nSuNP1+9LowXaYLPKX2AnjeA8tWxdG+NRGfhHNE55Wnl8cTkYMR4PphZvsLxvD0LNTpd5FnRfvrp
6BYFeyVwYt+PD3SUMkMqvNDjobAsmgRWaDvENX1XOE7o2J75POXfKyJoQ2bHEOE4TiE6nj2t87bJ
qcss07PVWW/bU1BDG8ASPo5IvrapxAl1sB03cHlMfYvHqhDOwZ3kaxtZaapgO2YCXw6ZEKG9s4l2
q2Af2kVqYEMbDss0iWAbUrXhMND4u8bc9dVvhg7EIM5yeTalC9DVE8owsfpveHucm8rw5EAY5nRB
78Qc42YbJM8CZJsjcIvVBqU61jQQCFanpEgI0qRcn5MjtogQp1kRwf4FNOdEgC0lX139cWtUQ6NV
UAXWn4cOuUhgs04fo1kRSkk1ll7N/BbHzD1R4+jVt3pP2CyVlibQYZktMCB7+wKGNcdwIltqBbZf
9+6ex0P6voosWX0B/akujqkCAqbIEEAu6YytZ1XCOla2XqVzMR6PzwjBqGwzHB6OeroydoaGYdVw
erXpFTum1HvveRrJuHjZbFcNpdfwicprO02XhWjesqTDfecjzxKWRpV3TAmA6HIW1M0fFe0NfTsI
fTARrIR6ekuGucQJTB4G1Hd4Qmzb8TiPHRJYrsttz99vH3pGU4ZobYhTqHGUtk6IjjuCk0waEbuW
TQM/tn1VnuT2FFTQ/A7JYq3PmuvLK8OEPxP81x6bPxpXoJLNjMssX2Zl3tKPhr3gxpvHPKZLrNR4
nWeYrJ3lxm90ns4e5PfucjmnNzldTlNWYGcCLEI6w5LK5XyVE9P2EOtjR94t1SqV7w8QzL1+c/0R
zs3klx8e/Zq+42DQ1hxRyw1GLif2yEzsYOTFls0SPyCB4/2w4YkXdav6bk2xflCey36HHLhjIoqy
wyuKBPXg7a9HHzO4rMleRgzVww/jfNxqohXNBWitrBjPMB0MBI2Uk+g91aYjhcMgY3TBxCxCiVJE
2ULG7CbVRaiytWz5hExhk08pwYWDrNpGlYPBsy/A55gAU6oKE+PPd/tIvLGpbcB7NJLf0v+n7lqf
28aR/L+ibxNXhQneD+f8YZLc1k3VztScc7t3dVNbKhAAY1VkyStZedxm//drUJRMSyD4kGhn58NE
Fknx141Go9HoB+zBg1t288NASjPn7fsfjztPiinNnl/+9OOx50kxpdnz/pcolB5xvednz5NiSrLn
w3UcySgblW7ceVJISebE16+AZZRdVDf2NIMawen/3s991U5wm+Ze1Vooj00f4tUbqlkFUCOY7R1B
RcsyBUgjROJ1hBQtUgqQehSnPjekpko6AdVZ1VEvVA1lOAOos1pnPUcvWqQmgBojdrAbqET1nABs
hGDiroIVq5IYII2w6+wIKZ4CGTCNEDbYEVO8Km/A9HzqvLGoXYD1fAo9WtU8QHo+hR6v1gaYeqT1
jjB6cUgjqPN6xZHQMq+qClUGqXVRnEn/56iYmrh0XndcH0RN4n3e/JxeiBpXYTnCutINU6MOP2/c
Qh9IzdbveQ9r+2BqWn3Pe1TaB1HTgnJeD21PFZAwnc7rvO01ds0m+RjJYV11eHzrMkZGWDdEjZbT
GHlg3SWqUc5HMJy6oWo0UsZJt7r2+xOKEBd8O1uXEV9//fPPv1WnFXHVdF40g49BA5LU1McDQjsf
R6AyJlBBvNGSxTrApkMXA7xUTcM6vPjrlaWKIJZbwYuWs3MHu5DcU4UK62ghGaeIKe24zi0TPH++
KODAhdQsH8SFQcKCk9EueECIa+3Q3GFb+JwrUbBYkGudhji2EZaLgVxKjpY8IRDYFyA1CgkhbawZ
attswjjVIAjHYzC2bzaSKyVUwbXWLZHAbTMpjqxHc9m+BTT2vua75d0usCvUigoJG41gzl9rpOzz
fmMeTpXD0WzwcJe9/Rz8ZJliB6MfShu5V+Wp83pyuymrz2R+Eb4O+YC3az//7Newibqbz+zsfh41
yDHuXmm+GyIgiFvtgJ5cIWkfCApAX23xucvJcjHdcWK65cQ0vOnb5b7DbBn10KWkxOTFMfSLElsF
KU54j5KdQ4av7Ag7r2rzVdlW1a/CP+Y+dNCdrSfLTwHpfAn/mm1L3f0bopnOoyJ/bD89PBDSDGEm
zOehTvOTY3q3XIDu2Nht3+FFtq2YkZUz8xJYC2Iyh+fvb64i+QMjY6sNczDtvpjZXnGUIbPlHLkL
wVFnEMPyapfCYzezbA6DNn+gYXP3cWVcrOxYwDBi2bFGKGG1dhYxgQutHOtddKwf7q4wYNWf3sx2
3Jq83929Blm7NQ8t2teTF/zlRNCLN5N824G18Y4fAzosEcFaeAlaZf/8ym8TnkcUiqaKeJUiDKoR
9vaBshADMAlRUwuwGHYKc0x5bYH2/vqHgZYHdVxppVi2TAOUEevOtiEKGXuKIYwUUUzH9nTtk7s7
/J5odgX7Hu785feJcW4VRne2vpxgTV5hocBGD5uZ50H34WZzX5Vo+bIo7YLl3MWfb84jfhKgu3kT
3C3bF4SMnV9+78zHjubnQHgdqkg/ghktJd3GSKybtmltGi6YFdLBTkiEWkX9W1IDMpLaFRHUhKxN
wYWdpBKwkUSaC9+/1wQg69GFbNjoXvu92l7fbxYLHz2coXSMQsyHC8Z+IgCLZ0s3s+XK6zZzH18r
ngbVNRjL99ulHngVa8EwFpJ9cW0YydVHv7Dfgh//y3L1KaSRRTsZBCg9qov2XbXaEAX/EjXEStha
CDdk1ToT/ANO/qWy1/LlwpUbirew54nW/A4IUnOO0CZtkJDe4NhxDFliCsMQHcSWFlDd3/49bEE/
roIif5heofrp4WMlD+O2bQsc0uhyC9nSlcTUCkm+v2TGWWdyTJTu3z6hA55OL97tlndCDnKy9n4C
xkHwpJTNqEIhpkdWzw3sC+yNWXxsYtSIDY4apDr4jxS3sPCIAisziJ2jtoXy+wWyrQJ/GxTCmiTt
QGuHOYCNIgz+h3n/qvoByIhddtpYE9ZuSTnGGAkihymQMdwkj/pbzWcWfhk+NQzkiD6SOI7wrNTY
24IhLYatRt1B/3n/2qoji9WCKuq09Ep3OeiIZaIHCCmzuadqe+xsWy783t9WlL5Vf6Dddns6ALtV
clGEPXIM0kyKpcn/w7tZmALT5eb+8sOLYuX9xZsCBnID95Rf/vHhRTgIvnjz4cV/Lj+Efz7cmJV3
0yqmLXzz+3IZqA4ffzUwp26Wi/D53RIsXht+PvxVZmrOZ++CW/Tib2+A+PLNZl6+5h/rT5vp/bc7
v0dReargbxGa6Fy8AdpBCheb29yv4Fv4otworeEzvnhzt1q6jb23oYlEuOi/3s1W3y7LOgAEUWAp
oWXaKPrfizeg2W24bbG8eBNWnvIJu7y9g3ErP1dDg+t/kO1ds/vtLWU1xfLTHTDbzPdvtrD436+q
m4CqW7P6VIYBTqtXvZvdr2ZfJ//jFx/K4bx4swqnTzN7P/28/jILpT3sPhUV7g8HsrV75iY//hIQ
fPSxr8tBgtH5lLw4Xc/ufVn3GfB8O771i8+naz8vgvzNbORFBzdMt5K+R//Pf8Zlu3uk3MkKoOmk
kyZzQ8jJwQPWMi9za6m0sSPhOhlxeCkXBGk9Ni9ghyw9LM3yQU/FgwdyUhjEYbNvhDJaYJtL2Fyj
XEvLDVfPGjxAk6kNg7gwTFiSiQPktOABDyaIpoBQ2qijpUZDHNsTLqeNDEoGLZMecQMB2KtQGmNr
cfiqBBZg1SaXYIA7qwkaMqNEqrNfHWJPLN+PT5canru+pCiXAkRfhYn1IgjApdPeEE2KzFhnMyIE
ziTSNpOFy7kQznguLx6y7rtO24u+rOk0et0o+242sMpXZ+vHd29z40LpgMHn6D+9mRwguJr8MdkZ
E1fBlHi5O/S6Kg2Jl5O6IXH1svK3rq/wy0nNiIALWxPi6tiAeDkpDYirxfJl2UUZ7q2MB/i0Mx0e
PpJwHcyG8K5gNMC/DyZD+WxpMITLR+bC1aGx8HKSMBZK9Vu7A0yFw69KQ+H4y70lkLj02Eg4vPHA
Ami5vDMQDm/7PDeLbXGX2pd/X66PvguL0XRXsHSH8uiubWTu4UvKMHlYGezhhbutIbv7mW00yPTr
jTn64dvKzj264G/NDIDNfekwOnzBzSwgnYU1827bEScUODji1fxo2Fa5OULrbo++Ksuz3S1n5XL7
+MpdEK31pwgou7fTd9Tczc19ADctZvP72iB93MzNCuTy49TNAgePRu/27mhEZ1u7vwyHOOLWx7vN
EVWVERHf5/YIhx9vjVMpfzQZUHZnH6HGCUGOcOqRHLS0qVSxpjqyozcrSQSnQgvjaEtsXNuKE0fW
3dQffppQacJd34htJE5ckEbBcwscC83GQ++e6fYnGt7eI1Kwr7smAgIeBBNCK0ycohYP8dWcB3HL
+N14+Dv3ZaTZ2Mw7gHJY7/Q/ft4u1gMgkMbT1qh8AjBCCOwONTeIDPKe9sjp6C1OTYyZhBpglBvL
hdK6fwPaNtjAxSZ2YSYd5Vp77Mlpirx7dOmjBiLTGzPdMUFw5Tjsvbznu60lsGi2fog4XS4m+fL+
ptZQOgSkBn9gcJydOqA/LLDhaqCsk+XySThLg7ueD0gqlupJEUxdHuJbG87H1RgHSh/D0c4UFpIF
WLtJPqTeThtPKx8PcvCoCyRyzhSSRf8er2fjQhxshBlBbTvuOGFMwcr6fIgPxu1+ubFlD9AyXr1M
v20Yt9SZFcWn+j2NERQLyTH1MebUdXh/eCcOZ4RHwf+GBAIjWDEihw1nam9CGwOdDo2e8CowxY0r
wLqWegiSkJk3+WJWiziSh1d+b3l5Tbi2l/84MtFADhpO55P5gbQx1ONhflHtCqNywQo76KA9DaDx
dPtA5wbjuaAEW+UxEbFtWbfxaLIz6lMtPpUkQlbJnBfG2LQPn9BcM6oLJo0uvC+My3Ob51J6sC2d
5c/qw++RL9pd3dUaCy+WGVgz8KPbCpLrbbH6uPLTKTf1oBEZZoH2qF3ZW8u1siboPI8tdliA2Ayb
YmNso+tZPvuIq2KzKH1UDTaQHnFHncZT+mWY5l4i6VwxiIvdwffCEo9Gi/5Eqep+AHA/u7Jh2e6h
si7yw+bz+vr9+nXl4CgDJ/6+8cF7WArQlSQIvULlfy8npf9/F3j3Qgm2vxaNRH9mMt8aW8WXlDQe
kUbFvyxp1/6zmc+qAon+K/x4iJL5loUVBtaUmS1nS6VnI5Q3Ek5/aLL/a/WtWguqmKH1pmxQt/6p
tAQmm3WdH2BFreBi8G9UJyT7vIkjjuhGjugfmiN/XsItpXPikCIA+i85xpG43pp9fEAkYY1Eih+a
yr9s5TceO9lDUZ2TzO7GhP/q7aZKwSgvwGCtZndNuQZJDPS0AI9ceEGNLHRBYv7SulEZxzaim7eR
TeFsiCiOveFKmVjFhnbzZgxPWejAPXNbQX8Av1xUJm5W3l4R0TDUI7KzD7pghpNwkia1s2JIqnEf
Uk5Atgvhr4JcdwICO6LX/t6+Dq9eblbWv97+1Cu3LWxkVh83Zcxr+dMx/KxHD9zT8f/7/qkG2K8R
zvxXc3s39wnMOBnpNP7pBcOpvRftEWr111/L4Jwtwqn7tjC3MztdhZDkEBtvlac0RzkXQxx5LJlD
SWPhVt3xHIdcpZ69vsReO+c9Ql6ZKuyKcqSs5SJTJEcZV85lUhqdUVpIWuBCUOQiYVdtnpaLvizq
NJLdqduFXiWeCD0jHvdt6dLQ+qc3k1sQ56sJLAeEY0wFfGG+1r+I0khSKmogjSP3SMdRQpLZUOci
5LyNxxsISZo6CozDeYhOmu41Fy04otIaL4j7XpFVabmQVPD4/hFeGZ4BC9RnqztbyyS7A+NKcNZA
ZPJ0qt8b/3s1A0W92OU9VVu40KgeO60sRXmGkMaZKkyRUeBH5hQTXrHQijxaZPB0eMs7kJYvpdrc
/hMg7WCHLp03oW3q5PUaIPv/8+41UPJ6lwDyuvr5qmbN6y5kTP5WSdbs1ofQIfzgdIGtqw3ZclFK
k40FnmK57NHZ4ElsDJJ9vnEWpvkiGNuNZkay+wHVJwSbCVQIllvLchfrbd66aoWY/OaFXSeCzZyi
CPahRmvpWoLN2tbZODKaOP9KyFo9Duf46CseXdZ4/sVEauQYqo2cnQMHvoKxucrmsHvf7pvnIB7b
crdV4+WrchsJi+/s1uwOcdbBe3Trr8q+ZrsOg1eLzTwavsFkasjqkNL9C0H5WGqVUHnh0wdSiCml
sc6tx5oXXCKaS8pyjw0YWn6XVFLv5lhS8nSnUixZBOIklgxTU8nq4WzAsXzNAVEYohzMHgV2bWTG
12mIYlOpc8wGXm1nvEaaMxgDyumhxBw1YW8RmTiyJNdIp7l2k5vzzbRkaFkdUFqshGIeOwa8k4fN
6w9mWsG44UTn1FiBuWSF0wYxiZjOJROSPP9MS4a7nMSSYTMtGWHC6EkzDec0pxoLXOSx0jR1GqLY
km5Ixtrl+fbcS4dO1RNtGL2q7GohifLOgimJW+Z+mxDHkaUcDHVepeXKGSO814TLtqlmuSFcWZ87
jIkSAmEsMVMElJUQuVLPPtV4ssbxSSwZNNU4Si6yA3Jsa1MN4CnqKSxeLDbV6jTEsaXSARt4tRVs
Cbt3LhhmuT6UmKN6wi0iE0WGk1wTXZTAOdc0niwpXMeTliruqCpQrqm1LRNNOsLA6NfKeKK1cUUR
7P+CCaJRgTl7/omGU16tk1gybKIl67WyAWW7axMNdkWMK4JgsxsrI1SnIYqNJjcfcV5VEw2WBJVb
AlKAWiZam8hEkfVoB/ckrgGa3QbPTZlFmDkDG81Fs4dA8KQCi+/DIzKYF8KhAoEi9Sw9LUNBg1wi
43OTS5PDrplTnhPtEYW5Q+3xtHzCKSl40hyI58BF2IEV5aLQHOemhR1KMlDqIG7cC+0EVYLA1kUw
xzUsPeIHYEezRjhFOgZpKJEsEHDS8AzEk9LgHJ2kMR1MfscLinBUY9Z5GseW2jHx03wBhhcSiUIx
xmLY6vyNYuuRidvjUH9VNaKpSi7FgzREMgH31JP7Qwhh/ZFSYJXDSuKGFBoVPVpmdefVvulwSNiq
agFMHmoBNHBuxPqVLYCCUEmpmVC5cH5InKzo0eKrH5iTNEjS98RP7z6kCXDFqVyxmJu+nWmp7kO8
tXSOdFgWDgnrZMs6WAgDFiAWiOWo8AVjxjrQbzrXhUUMyedMPhBJZ88gLgwTlmQSBB9QO6DudPKO
eaqVMCIWp1WnIY6te/zd000vmfRliB4LdFmzJsS5T6s+rDC3wGLz0iqko4tg29ySKLUjrmPrCqKh
hlD9gevLnOU2VKyUhOEqisUwQ3ImfIZh95V5xYsstxZnRiNpiaVMIBOJYmmbshd9mdFpoFpIelQ1
qH7bOaoFVT8FvxLkr5LczBYfs22YNtxSlJf3f5rVx21VoXhJEkVSNTdEZ7e2lEwUxtACFHbLmZox
hS4oNYgybWGus1zj0NiKcQxb8+f39CuSWhFPYskgFaJIyo4Wp3n6nUFIYbCjCYlVbavTEMWmUttV
mfKKFFpZlxfWgJXedqbWIjIxZLpHA8yey8E+zCk+B18sF5PI7L2c/LarlFrWTK3HoT8xAScIo05a
AIr0F8a9QFACSzgGibBySD1enTziUakjniK3Ocmpp6RVFNuWnDiyMeorvwVkmS+K5ep+2zEmZF8t
i8ndzbd1KNE1+e2Xd/ENqNYjllvuBCuMtvC8EAhRPagXQB8ahkB66I5WzlLAtmtmEJJO/CI02XuY
/XGE3V0Mb2v9Ofaofv/lT2XGiyDCOM0kRjvhDARNKoLMdhaHKbynDZ68nGiEaWgtkjFBTSjDaDJe
IAtWB8kxR6A387jiHA/3Q1LZtvTd0wHtPq32zRJKc63skBIS3Gq1rytBiEwtESIJx5tanaEF/1gu
uKHGYjmgQRTQgcfIdp/VS7FXRQ/jbExmJ5zIxhiKcNYB4kYNYRwMnkEc6w65A4Lha3SAkjJg1QCD
8bE3wfOcOGYR9aZ/va8AL7lQ0zZnhgs7TuqDd1q2HMAKriVY+kopLz3BTmKJhCqcMEKA3fl8Lp3A
hZTnfhAXBgpLyjhR7DSXDtWIOhOcA7HdRZ2GKLbkTuzgZHPn+H6YTzrninmDlfa7Fejd7q7f375f
l40N1mU/gMmH60jc9xgIhg1SMv1E9XDSBokvRyj0GQ6RXN7zcBLKeP/OIQFX9yV4TPYkk1pUj7TX
PXu2p9lBhAmHtxnCWdG/rFKA1r1K1qgcSpnLqkdkxYfrnfiUtZRXbj39cuNXASx1lIAOpEaZ/q5+
wMi6n4+MyapkWwfVw8cNOqaRV0Qx45x2VPL+NZkCyB9DrFhy8eiR3lGJVamWQZIkya1XhhfRoLh2
7vRIlhmTOyntqHv4/neSVJWCpjwEB+XCqAGV+wBXsh1FP/ZUX09N2QgUFtjNKphGoUBKVd08LK2X
Df7ncbF8qHrdA/dq2YfWw9bIE5s54XDGDKYZpjjPwEyh1gpmmQardkfGvkj75N+ySemUjlNxPtXV
kQpMCjAuTQa7Z5aFI5LMcuwzSiWzhZQWLN7+VJzP2OlGhc6ZQw6rTJrCZL4wMsM5/OkMJrawGplw
0t6Xiu7ngOehAkuw8Q1BmRIFzYyiOLPS40znGIdIWUmIe04qTlFhPKXgdQ93b1Bh4fQqgJMIBt4Q
Y4v+hZcBk6CJ/WMdU9vLj48r9zdeXwqDfe5hj1uYojqmRN4JS43NiGQks3Ax01zyjDMEy7hiJMex
Hidt29Dux5SB+JRc1IlvIGV3PLm7fFkK89XkJ55TqkVRZAXCOsNe8YwgWmRhf1BQ5TGS9qc4pJQt
0gXSrmX4tkndh+tyY7a/+UVgzdXDdNs9moVnM8eYyygDTUg5t8gVeWGpi1ToCUBTh1VdgO70wez2
bg7a4PpV5ccMCC/7IZysV7UnGAKdnVuXKQQjYF2hsyLXJgMlzzwIA2iXSJA9kCRTfrouJDW4Gvek
wS6dWK2lNZhHau8//rXTIDa99Pv6Fpj962T++Ra4VulP+HR1Dv79P3PX0iPHkZz/Sh/FQ8r5fsje
k2TAC1gXySsYWCwG+VzRJoeCZkR7Df14Rza7OdXd0ZGV1TMcAbqIU9X1ZWRkvDOCuui2BPfw/q4X
TPdKcdhEXk2NuZ5ni87iTyK6IKzKmidtTOU5mlhyALsWuMEo5ALAlwxAubXHllz6NrVCll+G24JO
UklvY041oH2qlmvAsAlyEFmYiLXsC0U6sH3z0rtPGd8emy9KWLDghbZYf+Ql66MALamTJ6IdB6fr
DF7ioB296Ffe0BtJI3iO1FDzoQZgv8/YbIwhgs9gVdyCTZGlFGHCtz9gS/84ch2XtqRmRcOnyQ6R
Kcr2DhOe9Geue8IWk0wxyGx0xerEhtg0JcEFn3Bkf/ruz0RIJAXdRPFJYeW1Y5RUjBQM8anNjaXc
PX64OLlJ5RpdMlZvOblKU3ddTiDOYfkd5OxdBYcwP34ySy7fwPBo0roXfMK8h48+nJ3VGC1PPhQQ
d1iaaEQsbanr+ifg1qI4J9PJsygGsspA8IlU2kFgfHz76+NvsY9Y62r+ML+7yZJNiL5pi82OGFHK
kIFTwSfU6YVYE7VGqaJo4HVtgkYpesEntOlhv1ACKhBuIoYkRcQaEA5Rkipf8DmV2lEeiyHAWvu/
LtuaEEYrp010mE0yBEh6feCZbQf42+Pbd28fjoQMMvgEbqrIdYsWM6TuF3xewXaruA+CrD1bpY21
spUi+4o3oCOvjwg+H67eoyv1033JIys68PLhNKe2hYJekBQUE7oWMZ9kduCSWHBJKpZ1GIKTJAHF
nIo9l9Q2Z6FNrcXwLWfES6qs4ATcWhTT+sIrmkBzChWxzU3tbadEcA4deDCkkaZoNO3unhdHjvxd
HBLpCq6OHv3l/v1T/Ci2nrx9/giSJ6OyQlwdyvKQ4/3uw/0+S+qsSdXALhm0Mqs043yRpkSkV9Aa
CFe+dYu/7g1pW4ubb4lZHYszIhTpsbs/y3Xg+Bx59ocXpKRpwqWQueHnLd3OZ9RUcHBdAk6vujln
q2olOGUBvq8pv+I1sU6GP0Te05OXtrftxosAmbDrFhkErquRVabg+fw1UABFXiEX4rYuF1Y0J0F9
gQ+NpYaXlMXBUbmVE4qNSEMmV2TVWvbmErKG4wB5OP4clC3jxXIGJ92yVFNhphoPGsgaZ7A7YM+Z
XNmvfh2/XFnL1exKAPVXg7asuVSZLCmwzBX8b1GiRq2aExHNrowwvYy8p/2NNYSYy+kcX2X9XaZE
VkxLYINWRO5BNS+qwjUymXwSYs7j2JMSBKEyMmZnm8yYmTzURpbWRiuotzLRtIZsp4mmljT4eL1L
eCyWlaLgvAUbmTUZDpgRoM1wy5FsB7pqTeNMU1CVF51ETvwyvHb6azdivPbVY6rpt1I/Xss1bSah
o2Wrv+KgXPLkpWg9PvfDNy2KZEQfRZrzQbKaIrz2obGkQmAejBdmnfVM8Mid1zLEKLEe8QNL583M
kSD7gp6sHV/K0Sj79MdvukABqWpFNMmKxJpOnjklNEvOZ6Z4AVueB1AbcvfVv3fr62jnvMGlLB24
WI3vTN4dnz0Xd8c3WX+VJa3gyAadWY3c+6ZC76yGizsyX3nC4k8enNDAsE0GW8rAuNUhJi64LUYB
iydjjIo8mRCUBN2ZxKsmLL0jo9Wr175NI5IZyzUMcprE3j/xLClsT7aTEWJDj+2FPclBAsDxbyU1
LOOxJC8OjrpefkK2pz1zIEo4lzwked4v7YxfbWpW6ciz9kAv44PrDYmsFiAVihbudfmV7Peyfu3b
+NWTAk3e1hkqGC5tsqEpjqV2lovAwAVJnmQ5EUe8lmMv4A6YrJJpGYuyLHU+ipAO5Mn5QN4yxuhc
zvAfcJLBonhjcGQ0Rs5npZ7yPb73idJNRCuwfM8YGplJkROpKCSPDQeu5grfjOgVvSE4srJfyIlw
wFW20721INcl8MtM+6lC2IJwIs5GZdojrzUDCiMKFmkf05He5PkSjzMqNtti8UKZjDQsW0NFUlfL
OZ8Qz76XUputoJo1en9jSEJy+sQJxDksGysBAlnALuR8amwp73rDTcFFLV5eRndX7Ocgujtr9J6n
LUZWL47pZn94Pm+xOUoSLLm9SqzIW9jYslUCXMaACQ0Bfljmyjg4uNsgXPnWLVZQoONYakO7ktNI
dWwmSyC8A1MIa5S/WAeOj+pud4IP/74xtjnvKvzsyLUTXseaoyipZNikLIHfqwnSRNGS5a+Ztwhk
EO+L5S0CWVi5bTc2AiEVrJow8BbB+axBTgQJfmaan4M6BnVb0a6PXpYcrcxov4olZVFwdPzmhaSL
IysOlts02g8yWWJUa0n6okClHcc+qtycUo5l1QLjySkWjNFMcmN59a05rl44WTIiuUI14HItV5Ml
RUoltUjMG5f6DDdYZ46VBWWdbErUJDUaxgtkTfsqTHN5i+OrvX4gMCFgR2Toowx9DlEDvuQFrpEH
SCcL4z7FiHUKKsFmpoBewB5qI0fdj1lFvZV5izVkO81bpNyykYIz7pVlvg/4A2vIMWe5rJHDeeBI
kyBYEx0dW7Omcd4CDFgJJjiXEimSPP21GzFe++oxuvj24cO1tMV2CpIhvCWnDliSSlt4k4TIhrtU
6vG2HYhtVbVg2u/vVnrBBAgEkAfGSqtdsl1gXci4kaHzZuZE0CG85drxpeBpC9i4qIJqzIDdzoxU
hqnWbxRq4/uiW8pAhB/q+w8fY9pPcSZSF8+FcWXq4vgm668yL2tmJVXBvNPFFq1r0QGXeJ5Mfy25
/MmL4yKaErnMYErS9m0JjmfQg94ZF6vh3BlVlODRm1ida68aCg50NHb12reZKZ4MF65gkLOk6GXu
YmtKNJB9rYWaiMihUeoihdA8Z4c5Z0v64uDI2xpLuj1tWqqtmVqN9nUwHSg1I1oOIbkMZ6Zl73Iw
yoEwUkZbH16ZYcnwxuq1b2PYQAbfZ2bDI1zhShMlyFIbx7hiuYhLcG7QEUqo+RL3n777c+95knwf
xCVyDPWyV9YoSAa4FH2U5iN4i0sgcIBbLVY3femcrYFGeo56tgk6VhednddKK9ck2jBmYSqhCOm4
+8zcUuqailcxJcNFwOLuK+hI33Cbmfl4scUlCZWSlyZxtB/RkIA0tIlA27UtdjnGHDWYbBE7H0uF
hSOkmXDukhR2x0fqmn0T3IE9vWV3yU44YmbMIJI687C/ijutzLb9pQvA9fyl42V+QJmaRfXFNaQX
8IqtNaQvPTM3jr4dBZsnlSzKRIt1QhjvMI1zQnVQ2T0VVXKJW6Am2oZttNV0wenMTKnL7HJ0HD7s
a2fnDQSkw/n6Fh0nnQULSTufzSbxQtcezky7uprngyMieWqR24T2zRltLNmIQ5gJGU2xn1dgxZTs
hWmX5fEr9pgc8n5CyDmKbcqMdjwkz5k5pXvVNCiAy0ZfZE5Y6euQ/Rzpq5jVM3OBj8EZ0dJIMfBf
YvAxccBknUzFqQb7DqfH2lyk4gqpFfyiczyGNJkOOJynjUcRBxwTLSZu2acNvhYAomOPM/O/rphF
JlfjQSaZFDClOeRsT8qD6QrC810clRDimOiQ2+o0w0zyf2OqoaOlJdhtQZbiUx/CAk51w6yNJZ/i
4Oii3rWF1wgln7n4umNdnZb9vIuHVu8d1TEirq1LOfEY4zFJ/MNehX6a3xIfd7/8+qG3G9xP5m39
zRpLLc5FBm6KY73ch6XEBQP5J6PMshZfdj/Hh09Tdmv5egP6meFttJWcjfChGR4Ukmdec+BpERnW
3LFNzqoiNRx/rOHNcgu2QbjyrZskcSCFysyoOLw6QcSSsxOd67Grgct14PjIbPcS35VJkMVoB7/O
1bBvvyvScPCmwaAQEd5I0eomwbo1RobXrFXpZCAFlp2vDH7yQeCb2VRXVS1YHnF4csiBKC9yVdB9
LTgZttgynuzzXKYondRcpmgkVu9LXzoaQftCZUUdxuqDvfrgbARCevZ2IgS2KGNRLRfuE9gReb7r
ewdFRpbshtYCC+skm+KiD7Elgd3VXlIWB0dWni6Z+4J5tbLGpOJzDm1gg45u2qHQyAk9L6SjBh+1
85E21BmW1iauQ65yU6hXkKN4xnLwx/1f95bXqguG+cP7X97Vx4qaXTeDOQ596qNE++yxQ3Z+FbSX
QbSSLGf3LkFH7+4/PB4HrsAi4B9S7UvrkuTv8G99MNhuL/t2bP/sz/G+vOtPvK+PscTHuNsny8BG
fvwZ3v7lw9v7xxdZ47cbiL1rYOw//HzF/BaC1gKbLqrX3JzJuTdRx8TbyKQTgrxNulQII8lPFjAK
Cc5pS+BZa3co7um+rFHSM5lKYzpzw8DAM6z2eh2vPG9FvGgB42H169ThlbVcLWAE67EJlQJTJVkG
+kUzZyNnyrXe5L53lwpIMU/HRFuXKzDNFTAeX2X9XSaNruAWR800d65lWbTyFnWGwTUneYe+zb5k
XKosTElrem09F+HIOWAwcKuTYZZHw8BezywqYxm4nG2fIgTVgXHOwKd4M3VuSFfaokGL5VLwsrBV
bv5X/1nvf9x/cfcf4AU9YEVhQ4RuLomDhfW0VUllKbRCak1X6GhJhvXWMPrKWtM1HH7WjN3ZYFMD
vpIxMW28ZC0Ex1oVIlULHmBBWnMd1vQMbLGyEu/4JuuvssBBHWUNgKtO4LFoX0Cp4Ud3gHMF7cc1
sRpY1mUN1mzDbkIuf+1GjNe+uqaXx/atpoMhGotKKw7SqRinqhlc1smthiJMAxnUb7ymJL1usaNR
yYQYX7E27LD2m9j8tFj5spxwW6lyR7Zao5O7ss03krSviCYqQha5yZKMF4OYmHc6RdggUH8ymyaE
si538aqtA1r5V2aJ1QqRXPtGwpNhL7chArWIIESw15oJwieLdiZccA8Kjm4k4G4Lb3DdeGrSey3Q
i9wLCuPgSJ/E3VATdVY4E+Hom2okR7qIrDAW6AJCd0vffmGiNrEqsMgvY4wroNGVg/6ZeuNXJWJJ
qfUu/ptQkkfEbyj9eKJgls6lXuEtNVb3NsRG90OcmUDbsZV0B0YTIOz8H4sUslYw8i6L3tYgI5W8
x9xjCsKlo3P6NCDK3hrY5ySKPrg74A8XOMeacR4bCzFkUIiSM3AVBPgvCtzfhLg7o+ryN7N0WLdD
1IIOMv7pz319fxIc1Fm3XVOxBoxy71jyMrKStHcxaaEyLlgHly9nq/PPY7IjAuKYVl/qI6/iTCSz
N17HAax04cfMTOFrFbuhNRH6TA+F1qstbXUcIX0N4AXu9PaPkipxZpbwRUagZmu9qbpgLvPoMlqH
RoujZRuM80+3AM4ub0q4aEbdMAb3565CI6h229CfllKRqWoj0ILWMR/Rp3LER4t0wKqLe3Q64FYw
19IBa6C9DKKVZEHuM37ZlMCN6zxPCaxaNJ0SoBHNjJq+JoK5SBzw2FyRZvOnXjmOkLYbbym41hyo
VX3wMmEzW4anOpCG98x0ZWxiFjhUYH0EWQ02kWcMjtzZMFENTnkFvMVakgTPJaDZ7QFKSZduzEx3
vVqBnbPKKjhZLNpKeQyRvHyODntdhWVjNbjkdNZjNu53rnxHgT8U0yApvzpnNFONujlvJOk8aFgz
QsM6rUMyXHGU7zN4HML1xuoWdR3GEK586xbDUtKDfWbmSl5rPuR9qL2JbMbk6XIdOD4yFxyGQxta
gx8VyfbxwYObz5nbVlq14Iwp0cCTla4YGbTRyoQiX7O8T4rnbkX1b/s9fPgahAqABKj1HowgeO2u
6529HVevsOl6KIcy47cPp3BqlklFqY1t8TbmJdPSm5jjRYDY36+QGWhReXbeCCNTXLU1d/cfgOn+
m9yh50FzPmb+2+OsePZ5VvyPPzx8s/vrbq7lwj/v5nIqy+fXtKM+eX5FJm33ty9JxR/r4567ek3G
E05QqtZUmVmxRTAdhWJgrSdWIlgH2eoMZN3l4wbcfd6Af2G7LnLwBZBW8szI28uYQbClxqSltJeB
33GNywjaM9NWAHdUHVngQjOZlWbZiMqUcjp3xeSrm6WtJI2bZ15ASL0iRXg4VC2yXqrDRIL/LeDs
wfkJHFTH9AJoI/t5FyAc6LW4b5fUFIteCZZdFSwkIUAAOydlmV4AbS1NeKnYvKIagHtldMZhNzWW
egMHRzYVWh69i6MFJiwHH1/5WEeXxEZlZzg0Khl9qr4//fWua/GzQ/37/krPb78cSPnXh2P8p36E
LXw4/AouV8lh16sBXLHGURz7ELuS0ZfiQ8Y856HAeh7Q16h2gHm4jXUP//SSpDtDASctd/fqnz4b
jt0CegcUetiAQnK++18wicHoe6z3v/++34i/7f51vx9ff/rXO3jguObDXuAfojTwjZxCrHpvMEdT
M5xBE9E77UN2WY98PZCbLFSyFAKevyYlFzy5j1UYwbkW4NFhczfGdHkevX+wk3uAbP9cLd/sHv4B
rPV+f9/wv36DV36th2uH8KeDUto7a/vfA8IdXkRhkgUIVzj8p+93X5UP79/C9/ibXakf3+Z6t//b
7k+7b3+O93+vf7nPH2C/foVt/lh3+6IY/PNUDPHs89s+27eyhKCsB1UFm/+0hkUhXygqcrDdS7aB
GVUMK6bf7NW2+eRkCVJ/CpX/z27xgfkVvVRoQ1GhDTkzRv6K91isjlJkk/COJqPDQM7LkJPz0Q8V
zCIVpZo2RnksBjUMtyiqWuyEZjhNsvVKCTBBsvd0uIWHYHob+wAipTThawL3J4ogrebcefGq4Ray
smcbGTbyMNX79oRHBsxAlbMHL53xHh7zx3J2II8RMlQmNQdHoyTJUr85oFO0FTwQGVzD6jsGMbQ3
U7xIKYuTteNLwcvZwbJOydcKS6mNVZ8s86EF5gpwI7CkVY3vvvrup+925VcQZ1cq2Ufgbiugs8kp
FbXkDenZdcpdKDhNeafrKbey4vv4JuuvgmNXEgOdUliTTelqU80Wm1vdcVIS+lXMJBLRGsoNm5Ju
re2WZC87ySfCOT99f8wrdsF69y6m+m6fXc7FVtcnaM134u8Aad2BJqFqJ0WJkl9eRz0vPgdR5sCJ
6/3pwW5RNVpV+31MEOIWvPVXrTSWZBu/9WvfyLQT87W/zDEimwb27he3SMfWAiBMsUSkldcpWbeA
m6geOBwk4LN4d6Rjz3kVDlyjuEpuk5dEAxS3tLpzPGTttCrZYbWno8oLaf5wEpvsXijFTE3D91it
ikqmquhtbQJtUTnczD/e4SRNF/FMDfd6y4DUeEnVYbXhQ06zpA0jJq5PXFF3ss/sAycsa43GeEcb
SzakfJWNJQuipZgpWccFG5wB20QuyttNHq8lTRgx19XtVLBZ76JWXEaH9nMbs9tEgv0L7SYVQ5Ri
ouQXF2wCHJ6SjQWFgqnR8WZSYuRVKEZ2EoVHn0ewJfhuzE5FKbFOokNOG6CcabeLCzaVchYG7OXq
N5kf/0/d1fbGcSPpvzLYL3cL3Agki2SRBu6AYLN3WOBuE9jJflkEBl8T4WzLkOQkC+yPP3Ikx/J0
T810tZzm+ZukaU91kSxWkU89DymKvs3A0oFtfcbmtAoyaN+GdU7n67zLyCRkiazxtJFJgJUtPFUv
cI647vx8Gy6ykYrpaonO8nxkQ6FcLjpHmJU/PDuaZA+KWqKy/HE0H2JINy3JEnXIps7SEJ8dTNK0
TQaTbIdRS1SfT4QzL6KWFdsKmEkkLxnN4cIZ2ZailqhRT6OFxIL94LBWMUeAcX6C0WtzidTzfKht
hTHG4EsJyLpaJflC1RK17JnF2bHDvqI3c0IY5303XEbk6Ui2/MzwWBIbTI0hakDekSHZLbGNx8i7
1yUi3X169ebzz4KZEMUorSpEM8eleXaKeTp0LM+EJlVxgJQ81lgyqyomW0y2GVFKzFjNapqfHbr5
numjR16+KB0/pqMV4OPjxVrzrWzxGfZWmLTHFu33GFHuaw5VeRfabidmLtbO8Wz8cdEkomP8E4+c
fauPXGPTD77ov+sXbrpUSCbIzmmt97oKtY8hdDqpkIJHIYTS/7LrD+4fvqE98+vd/r7TSF1d393M
37895zusml3kdgRLMv8T+2XOtraiMcvIKk3OGLgg2Z6/6o7auSxVjb7O8Sw8dfScfSBGy2gPFp0O
GE89Nu8RnzM611nd9Jk7rSINhGCssQA+R+mlVyFi6tKkKdW8JQYCyDY8tUSk/lQbaAt+XTrZ+Jjn
+Fee3qtyLOQMFHPG0IYsr4GOKQt8jwExgDacozogGZbVSo106VI0utg2k+aq7adOnjdutCslEGPs
LWfsWCJDeiLZq4BKRudSmVGIvmRe0QYuP89/yq/Q0Z4AEWJxcxdI56MDvfEtPA3+8D4/7MfYMjHZ
vrRWOccgeH6/G61IBJKUWC2RDj11utpicS5toUfWTRtIOnytafcv3nnUwnYqD84kk1Sjx2eT7Pxs
mi8qHj/a0noQNfkkai3ysZhQpijIwexzVmWvfG98dlXvhS4Cc/U5FJgpJs6lHX9cMp/JBuJt5jNZ
Iz8dk5P+/Wen1OjuKj/sXobru+a9cL/r3/j653x99fbNC6nclbJ7g7v9f+zetl2xd0HVm9tfwkEy
p39EORRXem8s9RF5Zffz+ddzvMZHjpAPP/50vyu/pvL+QH33y0/Xb8ru1cvX33z755dfffeXb/76
+q/ffPf61ffffvvNy+/+/PXnPZ2X9Gjufmir4ONL7h5fsty+2H3s3e/FYAcRfrL19x27U/7XV+3F
pOxD1Nbdz+Hu+udSfr3vfwS4au/bwgsxfP15tZfQP/Mw1R8fVuJKib3Sc3+wam/N6f9Van8l7V4p
cmrZNnHAHj5z29748Fv18OCszuKXc+1vXw/u4MzDqz025Pz02Mvc/oztr3KvZxTXn8m4jxG2h89X
n3/9AXH32/x/fWDr6bPzv26eLovnXRC/y3t+GoW7+9uP88e0uWf2cJh7D79+nHtStDGAtlH8vhPk
GUwjgSNLpLpP3Bi22iq3TbG4OCvUfTZDGQ3kBWSH9aLd48k4Tta0hyupH1f8cfhU6kqd2NrI7mn1
XLrmyejorfSulDms49ncjraS58KJk+yVUnv1vA5cmHb+f7BxNq5Qhk7nqjTqsD0J++nvh6eMtPJK
+n0XCpp/UrqWx3EmyRKF+RM1OqqCJaLRPrBqdLLRn3WY8WkA0pvr8u7gensFbf87eP7TLz3AIT16
yFKWTJ1nt5kXREmOAaXXiMiBqqqm5iCHc0CQs2WXGu3mFEjtgc+cNVXUS20aB5VqS5/OcB6cq13n
TaPhWYz59KebD2/ygfmxB4nrzph06LXtDnv1crffpYea66vO53Z7e9MCyWNKevjpX/9wOtf8w7/t
Xs+2S515Db1eFBlUafmrKirMHOVesmPSBq4HIGeRUUqtaoE56cWzwZCkvd9k1dCt5no1ylcbbbB3
TXVoDMdjZFGgl0vrneDiD6F4lNZBnCVFPzv1yGbqbUaWVjFbKrxxHAjPIQLmbaIX6HrssUH0VUTQ
gpet0JIKF2sVLaAqZ+sVgR4umJAWKb3moLzagNU5EcwMscAF61OTcc6sx0k047LrZ95GzulIn515
ZHvtFxIuBU2uR8MAZ3ziVo8lZ+9E9XauC+CcmBxt2jazmyK5/cxZE2d4lZzUCayv54jmzynynTSN
GMflVeBxE6KNLSYZayNw6KuAFFpRZkEhQx64iFanquxzmZE1viBGmHXawU8Y8S/SLCQZ8Vcbc4oR
/xLTvoxFD3T2l3pnoug4y4L/Ntz1zXV/ggD/i7zIV7lfg3R/lusf3x0wUke0+82w1BkEX+z+Pn8M
v9KC7/sZ1dOXfX0IdvftiV0bbsK0L2HNf958eJePPPB09T0IENy8+VLeeHnAzz/w2PVTudubzgXZ
f16wGDtvFylLsNbKY6GEi6w6Y9FwCaAhkRJmeQF+nN8LDzm27aa6mTbbCzYikj9AmfVHGNVKaGU+
IM40P16yBw1XR9IEB2b5CcFx5qxVpw8VzWWGw3AAwzEcAM1wYJ7t0EJF14puECaHudbM85ONtnN5
OX6UNmZtsoJcTZastNFSRdsmI0uSLiizvv/FJWNNleiCZZ0wkhQH27iMjB92DZuMA5kVWp9qnGs2
PDv/SQoBZZc3Ah+Htl6KBAEVRGJtV2cMfCaqlCqLNBVd21MVx404XB5CUggouxoQr0JINqRqQHN6
goHuQLerOnBjiQpK1aLoqeLJJaM53HaK9CpY3hM8xaH7XLuennacHicge9A3cRndFW8Xdik/PXF5
zHNRVNkZ8WxOrNBLCkoqu7wz+Dj0pqyrDAYD1mlQu2RMh9tI6dZ4uzpbQ3AasmxFKavTD+jOeLsk
N3qccyfS3gi6uppcAMmKcGRX+iZD68nlistvJyb3YioX1NIEP9NncMHY0m3puFC57+7AetB8fPPu
zT96F4TWQevUgrDgDehwPQCeBIzi8gP54/CGPrXZD13/ldXTQrblbuMyMnzgkpztMSd62s0VEKVQ
umjhWI02nsxBcPnJ1lHwDdE069pr2hlWr/PjqcVopbIm+yqbt5eN522XyS2v6+3N28/GVSuhBUK2
oczx7p0b13NWru9xDA4AU0g6sVj6taBgHJ+5cbG/PlP7PPnQvFWjCYxoUu5T4fqE0pX2HTl2ZXnO
FnrOwIXMLo/KrE+H1ilhQivfgkqcEKclJSr7mYFLLJlMsuPPn7RlsPlFZ0DLT/6ONwAnBWibJbBI
mzUpF7iNx8gN3a1PagVIh8VWlI5zuqblxeIWFxHGT1SLzzDGz9pEQs83GUYahH6xmMMCSBxb0OGM
rW79gW6XElHeOZ1mKNoumHJqtEpF05hptxo65E20Hlu2kYBzDqNJKbMvJN2kabUyt6bxomvSgLTK
+9krgXOqNJqUMNtkBgGZ2Lj1l/5YvFRJ2wiKNYWAJFRyVGdI9pizidXrdC7cn9Memjdtneb6E8jZ
RbpCJORstTGnIGeXmPZlLLrQLU/llh4k5e53dw9wtfYGc7izsDtQOe32h8/Og896h9oj+On63f0X
ecFjUNFFb0uCijQplbdNfCFLdLeeEhZFgKpiQswcAIomuxq2cRl5VeDWc/cDSo9FWKs495+aVC/b
xGO0ZJlbr24lY3VaWIgmsTYxsoFhG5eRFbFbz9vkXc6timzrUrFK4uHk3TStoeZWHyIUZa2tCWwL
9SyPDXeIQHc2+PWHCMFI1/Zsq11ihTISFryJy2j5Lr++CAZjCyQsYAQHo6ZJlPA2LiNTDL+6CG5Z
is5d4KMY3iQbDYygaVSwfwZ5LCdbDpuKSolzwamHQwVrGm3rn0EeC8AG773SgZVi2OHOHkkAsPLL
U/+jddmKqX6jY11l9fNrUvFsG4+RGYZff5/pa9U2Yq6ahdbXwwmdaVrozD8DFE2BNkWZnBLPZcNV
S7SGmF/fOFBlEtoEacwUEHSBx3C4YolGJPv1jQMtwXCqX06LWVXa8y4bLsUghcNArG/ZT1WFUIXT
WbDWJYni3sZlVNIDYrWyWZG+ZqFa9pdYFflw8mGaBEqDWM+fFmRMQiRTcAagdInLhiuWSPkwEMtT
/wnLUk01eVeELqxqyQ2XYpDQbRCr0YPYSQ9yFM5lVvAfTjlMkxhtEOt7PlCnWFQ+7AEcl/nhUgwS
ow1ifaNuVM0jqRSvCs9lw1VLpFoYiNX6dN5LIUPNLlhWJCNVprbxGJ1hrGfwEkFW50VgEsaZ4fSc
DKnOA2K9enBWXRQ9R6c0Z10aUp5nG5eRKYZczbcN0tsgi3XAulkyYrQMw5CAbJDLM//pfll1MVIH
xZLBNcPpzhgSkA1yfY+OCwC6y9xX5KT+hhTG2cZlVNIDcnVfdRRaIYjU6UJZHhstwzCkckDvX1y7
LkGW5GJNKFnnsWY43LghceMgn0EC2urmLB1FDpyWHENyrm/iMhI1DnI93gdrKgFaAeBZ63I4tnBD
ArFBrsf7APpaUmr7CIsiwpC47G1cRqcY6/E+CoqJSqsQWT2QhkRtb+MyKulpSeh6HF4L/NbFkj2H
7tgMx0duSEAsqPV4HwVgjIu5hMhKykg06jYuI1MM9QxNL7p2lUKV277JctlwKQZJ8927DNbek0RR
0ScRVWAFfxKNuonHSGpvUOvxPtWJ1JnQk1KsQwwSjbqNy8gUQ63H+1RTs9PBZQ2sUwwSjbqNy8jz
WLUa7xOsBCu9lJWFwzMkGnUbj5EZhlqP94kOvQk5OOTtl8OR1BpDpxjr8T66NktjkEnPCL9d4rLh
UgwSfwpqNd6nuSrYEGsA3n5phsswSPhpP3Veuy5LMr1SqjHMCNZc4DI7XIpBwk8B1uN9itBSJSUq
AIfgzAxHR2tIOlqA1XgfpQwIB0mlwjopG46N1pDwU4D1eJ+EKvqajXWZlZTZ4VIMEn4KsB7v05wB
oeVW0MG2DJcNxz9rSPwpwGq8j8sVTE9jK+8yDofLMEj4KcB6vE+SHkzEELPlcJGb4cCehgZ7wnq8
T6q+yM5eU5DlsuHQnoZGe8JqvE/LLypahSJ41rokoZXbeIzeL9fjfaqQwajmEC14k2y4/ZKGLsJ6
vE+RJqrqnC6SlWIMh8MzNA5Pr8b7aAVFYkUlWBW5JSFcW3jMknyfsETC/tR+KVrsT23DlCzGYDsc
RMoKcr9kSKVP8ljrhe7w2MhiiLTDkR5aEk8DSwTIT/RfStnKS3TBsw4XLQkV2cRjNBKDIUE96Sfx
oeV2pThbWS5To5XklsYVLJEVP7Eug3RCgcpBFE6KYYe7JbckSROsV+2Wsm2YWZcIvHU53I2vJW9U
YYmO+Knz2FxNSrLmJDhQDDucmrMlb1SBIdY9ZVQ23oeMUbDyWDscv48lb1RhiQD2KR4Rr0OxMRYW
maYdjt/HkjeqwNDlnvSTOB1zjpgli6rMDsfvY+n7yyWi3SfWpagVpVEppsraL0lumG1cRqYY6/Wx
VQGMSfuUNOcE25LUMJt4jLwehCWK3afWZU2tIuu3JJVD8WCHu4yz9GUcQ/x2gsNTLb2w2djMwvvY
4W7jLH0bt0SO98Q9SbTSIqITlnPja4e7jLP0ZRxDjfd4XWZdtYw6IrIokSxJDbOJy8jrQViixnsK
hxdC9kkLEzwHt25JbphtXEbmsc8gDOxQx6BycY61Xw53s2Tpm6VnEAZGZ00RaFNA1iQbjkfE0jwi
S4SBT+WxXkHCGFrRxEoxhpOAtDSPCEOw+GhdCp1tUMLazAJh2+Eu4yzJbAKLFJRP5LHG9lNsI3gU
D5aUftzEZSSzCTDEkyfnsSkFibIIw+onscPdX1pS7hEW6TnP8/tgyDKg94KF97HD8YhYmkfkGTSd
tVA6iggRLecyDofjEUGaR2SRpvOpPi8XMGZVaua5bLSSHGkeEYbK9HE/SVWdQFbnJDjrEoe7JEea
R4QhMj3hqZTJ+mCr7p0WHJeNlmIgyWwCi3Sv59elkRqM7uSehnPug8PxiCDNI8LQuz7m3VI6e6FC
8IJz7oPD8YggzSOySID7xLmPKi5iK8lV4dxf4nA8IkjziDyDBndJJYrikkXBKclxOB4RpNErizS4
5/l9Uof7pNBmGqe+xOF4RJDmEWHogk/wsUVldLm0fxw+PByORwRpvM8iYfAT9WVtLomhZs3i98Hh
eESQ5hFhqJQf42NzaB4JHmth7ZfDIaSQ5hFhyIFPeESyV8VDMNGxUv/heESQ5hFZJFB+QmcvOukj
grCWtS6HQ5UhzSOyXhTc9CBmdLBSsjKM4XhEkOYReQZRcNn8pWsAbysHIoXD8YggzSPyDKLWbY5J
kVL1hnVLjsPxiCCJc4P1otbFI0ShqhIs8AoOxyOCNI/IEsXrU7pBQXkvglWFRe2Jw/GIII3DY+he
T/jWk04epDGShcPD4XhEkOYRYUj5Ht9f5pStC1plzRGNw+F4RJDmEWEo+R6vS5uTy6JijZFVXw7H
I4I0jwhDyvd4XdqYA6qoW/rHysqGgy4iqWMHDCnf4/2y2ahT1Vi1YXlsuAyDRi4ylHyP16WrMWdE
j8iCFONw0EWkoYsMKd8pbl24XGuqFVn3JMPxiCDNI8KQ8p30eXkAEbwymYPEwOF4RJBGLjKUfCd9
XqWYKIsxhVcsDccjgjSPCEPKd6JPkoTIooiYgHVUhqN1RyCJPwWGlO/xuU8NPteodWTpk6AbLsMg
4afAUPKd5LGqaAshamdY95fDgT2Rpl5hSPlO+AoESPBZBuDdxg2H9kQa7cmQ8j3GrctQbMv8U5fr
ZnhsOLAn0mBPhpLvZL8E5ZV2ELJirUtS1W4bl5HFEkPK93hd+mCzFlZox+IrQJJNZxuXUUmPZkj5
TupLU713AkXieWy0DMOR8FPNUPKd4mOtrxYDGpZ0hBsO7OlIGTvNkPKd1JfBpqhlkjZzjsqcGC3F
cCT+VDOkfI9xBTVYKJhKqbxJNlqG4Uiwp2Yo+U50g6JqM7lIJYFzuOhIVbtNXEbCTzVDynfCIyKz
Qqmr0CwUtpOjpRiOxJ9qhpTvMQ6vWt/CmLWOdVLm5GgZhiPhp5qh5Dvpv7QSXPdbcJz7SyeHSzFI
+KlmSPlO9ktrTAzKeRAc1kWnhksxSPypZkj5HvMVmBiLMSIG4NSXbjhyN9oizVDyneqTWJ1S7MfY
rBSDRKNu4zIq6dEMKd8pDk9JI0OMKbFmGQyXYpD4U82Q8j2+J1G2fafTygoOrsCRfH0rPfbqf6/f
v++f+7q8vdn99/W7D7/u/vY/vz21iyWFD3dl9/7m7n53/e7uPrx5s7tLt9fv2493u7fXd3ft6d/d
bOZAk4nREgHiu9Le++bd1ZubH28+3PczhCqzzc6CYY5xi3TNv/XmrGmTr3YRlNRQNAB+HNXHz+Ry
d39706y4Dc2/+d+F96ZglD4Zmat0JRaVgvTKaiHQyXnTLo9xD399ff3u+v7opf/ZZs7t/Yf3j478
+y+314fRO3w03bTBLvflhy/4/fMDOmtGD3IarTDSOmNZQU5fnnxc7rNX/cfDWn25uy35Zt+mwN28
zxbgUBf7bNaMHuaCs8kr1N5xLgTcAiDo5T77U0g/dVvflvuQw33Y/e3rv9w9ta7e3JbrH9+1AHfz
5u7qhDcvL1gWe3Ohgb13IFkQiJB5veluCY1jM668/mja659b/OuxrsUj1WqZjpd4DDjfv/8/7q79
t23jyf8rvP7SFPhS5S65fCjwAc6jjXGJm7OTXIEiEPZFWxeKdEXJie9y//vNLClZkkmKpEXb6RfF
t6742M/OzM5rZ4eq0Nvre43yXlhZaqHF2JzE9lTvC7G9KOSazwtaAxqrxLdAqiKQGs63j7s6c74Z
D+a/REBdQgSRUT9GdwHfAUvJ87fFXd9yu7gRXo9GZ2z5I2fk2Ha1NTkMRXetCYdbZjzlF3qmU3RU
Fnoec6nROwC1ri24txJOhwad3Y1LC1S4LSh8UZQeyT41IV2m0ANRyez/4oWhxIUMAxgxAS+39mUX
fAorP7VO3ltcqTn4I4+HfdtZ5PLv5XSuLb75sicBswCmqnGNLXDTRuCRjIgD/ziPh/Nd1UMXWRPY
5xbf4sFc21fJ8gIE5AYcW/zzAub9/sWrJyMlbUMK1pjTIR0y+iu/Pk/4tZ6ATwULCPSudkMmKXUD
r1dCH7vpNsQV3t24Ynt8P8avxFPiQPS6E1wUaNaxRRirkOsoDgj6zsr1Y+0SR6iQxoRGyjO2/2gx
XwILMAdzBPEjDCN5MsmXQA+IMufFZb5cXE7wPyc5vNe64nPg5NFqnAjCuJjx2ANT5HuaUhZTjwYR
17H2tBdVk6E5K9KHDD3lpXEHiHTYzlgBxYTDcjlViDKMIi9wNeOqKmW6OYlKcB1Ky/uvs1PQFHNt
1jzSDha99ccV/3upz3Q8llr4DGJSG4JpYnucuDZxibAVl66Uvie9iI7Bo0QgN9ZKcUzTpzodQmOQ
Sm5HDvFsKl3Phshb2xCpezIOAhnq4AeaTiQ85SgS2gGPua1jHtjgEYbAHUJlLCMH1uAPNB0SgLrg
1LFDP3ZtHrrEloEmdiQIcQgJAkrV05pOP53TeP7BIx32A+/kniSJsekLiyTplSfBqv4G8+Q3pL0o
UxELtNAxYXvSXvtMUyW0DvX87QMVmaVg0/QcOZjrVOG/0RHNQQIQLlxdTE3MrOeL6oilQ7/fzhFL
J3goojTiLqx6QXmvPbrDzOVOyidJELj+tjCexGWWfZkUKesJSAsEMBMUF/OqKU+m/1OTd+xwPKFH
1qcrRrNZpSISOj6JWZ9zUAea0G5WZZUNLB5fzyxL78wAAkfQdjhVWPImeoTp63nKE+PywcWp5Ea+
UNdO0yHZUiiMci7j1R8g9GAbUtDEMTyUX2pVDaFZoQZ1evSAtIH5QKwVSS90eKh7hQY4C+srn6d1
sxgO7oYQFVLz1yHFBuxVFePCPeVNHtksWpAJyMc3baIWO5nmC4xD+Cw/Mr72DPDN+CqcyRENRDTz
LMPb8vxrNldH6TJJqlE07/WElUZvmk6+TkFTrF6PFpB6gYqUCDy6awF3YjMVuiHESOCAxjFX0ic+
jTwiwlhTR3pxMcujmCf5KjgzU3moAC3cUxN0P5r0cJrCPRU3HulQrFERqIEeV9INHcYqO0BsTqIS
XGN/Io86dXJsRNgGIBYCORIRA4c3DGzPEdrWgZA2CwJi68iFn33X8yQtxN42QmH2te1yX7v4/Yu+
OQJxyCZX2VdQuWnnxYB7sp0XQ+EBCuZEkXY0Yd5ubmLXA9y3AKqhBU3QNqncLJPaE74MVeh4kbMn
h0ICz+cA1g0CHyvsAocFynOcCIKAQMaPv04bexbdjyb91mljSyCPdqh3qVinmkSK+9IUvFSs081J
VIJr7FixvU4LGpzxaQ5D8IUF63YCNJgby5aPZsnYJSPKbEYs+98rrvoOGXnMJo6D1+HSNc+n1xpM
JV6ldETtao7eA+OdUfwRpTZliMBYcYCJvxNCRyS0md8RGnaH6LwAC92gHJ8KAe6P78T7osM9i64a
WrPYbVJNwDA4lu5HOuC6Tdxw9wJ1nBEobu/O74yOPJu690Vt7Mafqxfrb1JfoaxNLnmqIPobW7+D
4ln/bJ2cfnh9dnr8dvL67OyPs7H1l/USRHS5mCYj/CPm02Q5189++g99Y23ZixReE2fLFBMrEGle
/fSLVeH398B+S2tgNygVQ03m4BpyDdWKn0v6EyccEdemFYIYjVhjBgU4ARxIJugk6vT7d+OvfsYq
qmcqm03V2HJ+sZS+nko9KXzZI+slrNos0c8+nb78l8Uih/xSOW7Q5BXdZ9wPMO1/WRGrGhhoRKJG
q0xpWzUfhDKgyouF0KrZ9AkJVFagsLkgKnaodmnsuixwPQYqFuT/UU2foUmji3ovmnQ3fQZQsy3u
Uc62YfoCKVxzVpWQqkNxm5OoAuc2l9RvfmeyLJqEABBUgpp8evFqUkgt1prAIEEQsDAOwZ/nSzU1
El73wBil/8j6GcDEHKJfGxjNbU9qZofKi2zuOoF2Yt9xXNd6BosBDEFiwWrB3WpQRpdZvhhbdwH/
8nPlHBsrHL3ND9Cdn23SNnZDEXLFQxlG1eZBiUlRe7O4udJ5oaC8EQ1sP0LVtb48nV0leBXFIbQj
v7zI5dovIJQG8KRv+xQvzmG4wupGI+KDndj60cUNW5sYK1QmTwqBMa8K2IiQKtNyMFqsBBIl9Hx7
fP1NS2uvGXpzfPrq7evJyemn47cnr9AMnZ8930j5n358+7bCvgwygUMZoGEl7Ylg23Ut70pf5I6I
V8pmSx9yMHRN3tsg2NaaehukJyMhHEEjzYMfA2RnZ/iuIBDwcFFLOf7t9WIOPgUZiWwSkJonSQi+
cVA9zUbrvvlpzO3Z4TdowVuJYogY/jG6/BC0eFRdfugJHFRfDiZpTwTbcLp8CHSHUpOtsdWoSQci
DxJr5gvH/zFAPlVdzho/q+GFbWMPxhwlRCwhaHCeWuzBGpuze2GtX0M50QAnjpgW/xB7dRhaPKK9
OvwEDmgTBpS0J4JtKHs1DLrDmIIO2GpMgeszEcec+A4ZKvY4MMgna68av9HghbV+TRSFQUxCwgJH
/2N0+SFo8ai6/NATOKi+HEzSngi24XT5EOgOpSZbY6tRkzSQfuQFMWf+cLr8oCCfpi5nI7fxrDB1
v69PT8PLppmaSiuHZa6WoIRMkZznSMpj7jmumePFHPdG17eAOku0Ng0blulimlgpTLWskHtGiDPC
UgSfAWaZwWMVm3tPAWIYBVEdRHeMxMVq+vr9x7B1OVgkQkkCiMGU8vbsP/quZrBSI+pGLouJFlQ7
klBXecxh+lFLb0qaNC+g+9Ck6/5jCagxm9DlKwZVZ5kCxlzBhE+iqoYam5OoBBc1lrVstozGwNuM
fD3LJ18vpxKoNTfyOtHXXC6L2tKzMYmwsZ6IeKz4Kh3wps2zYxPbY26ASEliP6a2I31he0IwWzBG
beJTDpqNYVcd61mLHMCDzLGQjdV1kA0zje1j3o+PC66DvsKaRnxZbsFKs/7adc0MLoY9Puu1ShR8
P85vUjkyoMrXaxycgcIHQaNMbmeF4a+vaXFGItVfV7XMsIIKr9LUKsvlHJd+IbfP2mqbSq3ImnuU
tsO/Kbire4YS0IMANsVNlxwkxFQRZddIedBmer4oWywtizK4iQSyX2gUIDNUjk9dJTy1JEyt6lb4
+X+tLFFG+hLNr5GXR+DsW5+fI0fN73w+n25dMGI2WWQTEAUuEm0uxJpyRmJWSRzzuuVsVQWVwxNp
ZhUY1gOV77f+r5KSzZXr7Sn52fqIDZusr4mw5mCBZzOdqqKK0Jzpl5dZlhcibWTikueW0GAPyskq
C27Ch6e5Kd3i1zAnvDAqX5zNp2B0sDY/uYC/F5ezgefTXT8NMHhLJUTBD8a+97VKiG02NG02444Q
sfZVSB2tm12bSMWcMha5JPaE6xHNvTgOCGVOHLiUP2ppVUmTpmL7+9Gku2uDgBpb7bMuLVQrXBsh
qS9cKZ1IVh3c2ZzEXXCk6GtcL0FVh9mrqYWng1QchXHgyz3OsQDrGyjPiyh1idLSCWlIhKKB60K0
5D+yBJE9nZXvR5MeEgSASNMRDXbPg/6URywIfAd85KrOQJuTqAQXNDlCjDYduiDwbuJI7Qoe7ims
3ic1d6HREW2mG90MKlZHW1Dl2vnlcqGyr6nNL9Ddan8MpRy2yWXdGna3QQTKd7UsSe5rBWpWxWJV
g36slFW+AIXJPG3li2wOqKtxNcr1Ji5jrVZUmBRUeDVWvq99h+jQWfdONK4feCEY5Rf3jc1vVvHM
1yl2eCzfg0XZJP83+F8PdK5THBmYxMCNz1YyvbhcmL8n4B5PVAZOfgljbMny/N+7LJ0COSbzucpH
mF1YXiGhcqD12pU+O3uVF6RLbiphNfYmNrBmG8N8tspxch7rCeBZlGoruTHq6iBDvDBDjHEiOE2Y
gnG3Pr0rTmK12jReCwyohi8HQXWMTb+2AGXiv7VcHBZUoy3dFOFzvTBqtghO0sLfhAEKwwLCzLXj
K08TxummZB0L1E0oJuCAVT5cDawpOrkfsF5WAyA1puaY2+M003YfmxCUsBOHgcNEVR/yzXn0wddW
7I2jvl9yuo7WLM6tYtv9oFjToaQtFlWzQEuXyTgAJzCmzV6XTwPmC08wT0RKh54nZEwDEfncjbyQ
OI/UUakkQ+Oq7kWGfkum8TvVzL3fKQim3DCKXJ/7lY7W5iSqwLnNbuljqBi32cFyO3QsMx7HYiq/
JHpyqcGMC6APbrpLh0tw9Bwe9FEyLm1eYd6Oz1OBIIDlHARRSEKvIJaN7QNAQ5wt03SdKVCYrTN9
BVBV3G7urnI5tu8SZjPNpA0GT9hShLETRjqK/bAaeKNBuRfw19+0XJZJDgD8s/F5sSm3DX51AuvZ
xtn8ShxMfi2wUevPFvqjFp9f5NZflo0PoFA/t9roweeWDXzLs/S5JRPN07V7fWfTu5h5Y6HG48h5
Ywtm5t6n6xHVzMO2NxDFVJ2N2ivgXlNTvi1od5t9a+57jDgxkWJP+LXPfNyF5oJ2aIYGJhdbPqMW
/2z9lixz0zMWm/kKnpv+VdjtF8tGwF9fN4feGYmNnXAEkWDPPi5UCVdz8N7igO52ozlJizalIOtp
qhOwdIvLXYkthm/8qFzr4aslpwqF6foQB1opxWRQ1b9n88UDQt6h2J/H70+s89dnn16fWecfjs8+
nJz+/vAUq0KBEXRAYyli4gZkaIq1QFCutyyd5Dc5qKSJyLJF4WChJzaZZ4k+KpplPRz/3vN5XnSw
x12zbH5jxdPkTkerEkD7D6J15mA1DnShMGXuxyzUQWWvk708PAjoKj3Bk6mBXDr8pRKrIV3fttVt
1UU1GEwHR0EU+KEfOZWfDN9Pv/bI2wP5fsnzy4VIJt9myWc8VQ5vNSpPLXaPAw+JwlxV4rPx51b7
cWpi6k4mc43r0zqqzAA8HKoyxQWwjCeV3DwmokI7lZ3mcMuxIsH1MKThIz6fgSQfiBjtl/7bjJu+
hq/evHxvAUfAxapc8m7jR1TvueQrQODGkBu43Pd5SFQfVWkQ1zpv24j3AygSbEt1Ka8ULHG+vLjc
rJD9CC7qCP9voufzbP6MOv+yfkLf/Cf49617jo/bxftHSvz0C8hHMXDdLWNr/Q0grKlAx/9mBXAl
VQOya0dYznSB1ny3ItcA7U5XznL0g3iz1cJSAQKjbM054x6JXZ/0EZYOn/rssriKRrvI2NVOvJHI
aqo1ftzz3kusBgrWMLqeEqFUPPL60a497rYw1sEcvmy7WmX8wBiu5playsWksZLioUCIOU/V2PpT
pwVpHhiGWE4TNUmXM4GHBJgT+PTqgSFcXpSlQrlejK0HHnwtA2S0e17jkEt4t4Vv+T04XAcbxyRr
lEjfb221UCI1QNCt8VTEhOtLyvq45QZ1S1vdDkTJMLjmWGWP0nyG+asiD3gbl9k27pMVnz1bmBpF
WGswZeuaJ9XOYBcS/1Bg20vkKm2ZTy+wuK08NlTjOQ4pkTVAMHesIqqFUJqofkZtSLotr1aC4Jgz
zsBcbX3RN3UU7NsYvAMFayGZ0g2pHd/1Iz+q2sLYT8u+TapbJy3QLGYzq7BM1oVOsRlkNq8h50Hg
tMhe1KBC28JDTzsijAStKnrbT9G+XwdsdO/L7aBV+2/zHdIaEvb9BmAbB78KBqbOeCBl6PuYM+5D
s8bKi23MbSCUSvvFNOWgmfnVleageBaZJTRo+/lcy0UCsdo0/XKnJ1xnPF1CtAtsgGi+WXB+VvYA
r1ErhwFQF6VV4cC0vxsyEUUxlbSXLunCxTYYvuezCZ6ChWBD8oLraorMQ3v7a3a1+BXHyZZzqX/N
Z2Zv9Pzd6l1VCFmH4LcrwrOR5FdcTBNQMthjY5l+SXEbcv3rjXX84Y93Jy8n748/nr9+KHif1+wG
Xqr5FGO2139+AHgK/sJiDGxSX4umpePXlVgrLhko+fLqKsO8o/VMm81jzI3unispILH2ln8A/p2f
Tc5fHp8+TWTHHz4cv3zzNLG9ev2Q2KpE/uT8j02Rn+ZZLZqhRR6htBR5/CZh49nFwxHo5fnb3zcp
JPNk92Ppt3iGJpEB055GlLXfr7yX3vzPj8dvtzTn30u+W6V9i2hw3WngtCdTc6fbx7V+A8Gr4uJv
uNu7wUTc/a3FMzQPDZgOLBxAG3RT5S9BkZ+c/v4Ewe2VrwfSpKe/nW+KVxrfdUVXaIaWLoTSXrg8
+jC2+M2L400CXQpei2ZoAiGUDgQK2ld43IdArzBs2ySRieNqEQ1NpAJOezIxt30G5BH0wBDwqrj4
9tO7bEfUk+tZViPuBtXQnFxB6sDL8GGM8sn5y/OTbQ9d5rvlsreIhvfREU57MvmNZcWHI9NS6etN
KuF/1+IZmkgGTHsaBY1flD6g/YVg8/37LROsF/zq7mboCtPgVrgA1J5S4YCJtAMo0CHg1SnQO3oB
VWitbjDIHkKJdtUPYfikXeMh4NVwdIeXtWgegItd+WfKxw4OCT/8na/S27e1Zrf5bDzzq1MFnL1N
fqtMF11N9DcY674s7bmxB9jwDHJFHbIZf+hjC7sw4FHiC+KoAGu4O29DrTC3FLw2EL6X5+VN01Lk
9OoAfXn3NMfGdTlKi/momOH+fJmWElDcO1Li+W2loUh4+qW+vPBwhG/Yu7pcLK4a6gqGZn4tFKS+
pk6stB+ErKoXWysBGJR2RVmznWF1dRs6DngOohUsVFtSx64rQ4e5US+aDnEs4q35lFzRunH6zcoz
0JEVBa9m/AEPRFTCwAoXx2dSyAiUQOf66BXmtvXRLSCsSjaXUuo8j5cJsFmYTxmWty+ysfXx9OTP
5uOKh6RnLT9N4T2eR3hMbq5BwIOh53HKfc2E7GdU+vCyDkArTp5AxGERGmAx7IiMw7sVsYPxcV1U
9+Z4uzS4mpvRgCcXaqHA4zHh2hPKB6XWS6cdBncd7dDxS7PUBuCrk6k15BuwSqQJDVJQuMILwNiC
te1FwSEqbM41VgS9etFK9AakXTUOVMrY3YgGYayjfnLXHnQrDKsS9vJIpBLl3bWbYmGHo6FdEPy1
Efmgbwxebw3bhhl/lik9TrNJMp1Nq+OpgQaG1TXji/G3WeU+8lCjrpthThaX09wcDx5XHrDriKH9
Us1XrbuxuHV1Bk+nECrXxJNDHupuAINBhRcpGbnK85w+qi5qbK2yg7w1kJKRrwRy25Sw82maj627
68h6Vla3ojS4NHQrMxyDonyHjsxcS+yJpkxH1t4w/fYhegeYh2gVsUI3FBHXvcNihLh+porlPyDl
gg6F310p917PUc3+P3XX+ty2reX/FX1rPBM5BECChDP+0Cbb3cy0u11n271zOx0NCIA2J3pVDyfZ
2/u/7zkgJdMSCD4kyrmZjC2LD/xwcHBwgPMqgv7tsQ2KyX9/5wSStAeiU8y+O3q1XQIMMzHzxyv0
H48IIYlIZUxFeQso7PDzZoSfJ4UEmew1/Aui2B8jXbLx55nPduG8Nu/ZajErw7BR3yhyVfTKhnbc
DXIdJO3dGTp3A+FjgDCsBP/CvcA4f3v+Y4+RiymFj9rUTY55inDax7v0mx6Y63ulJzYjwczMFquv
kyKQCq0bbkjt7fknzVgLSS23FwSxn7C1zfpMJa1zCceEY7GURIgo9mf6EzSJIs4iTCWn44BqHoC0
FUqkBMRGKo7zK18m1V9BDW8GllOo0TWxl4VDvIH+p+VVTuIspUGoMioCh05a7YIbWnvrUAt2LYj0
bses7375dRTcjFIWcZ5KNtY0isdEMDHOMsXGVCXAOyQMpXK4wiC49ifG/cCRm1GUGsUNScdBEvAx
11KNQT9Nx1GiIylkKACVE1yHbAT9wNGbUcJZkIkkAlwsHgdMk3EcJnycGq4zIYQ+ztdWgjurdHaA
YzcjEaSw15FmrIVKxzJJsnFIRTzOZJAoFhmQCodJB0twF9KsilhJ+6IL4tiL6l2oprvtAVj7/S42
tFg6n4zDD5iLGuTaQuVWPsAucb2YmvK+66eRnS8+O9F2cPToO2Jy/QDSb4nJh+CLhxXoJy675mBg
qu1aiyJuVfewnArHmZEUg/g3WzzGahi7xq9fiiaVASrvfpxdghK79u0tOBi/lXb1msbPqhnvGv91
1ziG8E9BLR4tMgBSA2EQrQ9/WklSFviWcw18+mStfSy2F6UuD9/cjGiLDOgX6AEoemgz2JUgBMVJ
/bnN0QMIr2DxcBjSp/y1TGgmAy7HWnExjpiOxjpKwnEU8ixJY6oFDYs8C5vFJ1MnU8/bBVvT648e
OF+B4M/1zSi4Gt3ZiXu9VG69kJ5V+Tqi+Z2xWaiGpXn7g64LHBH05v5wwG50PiL4Rnrh3JPPFpgR
3chPRk8eU+2WhsPgsI0jP8i5za/2Cf0JMR1Livw9lpsNFobWo99+eL8evcozvM9xdnx2fKfsDEPf
YTuhpxZPULDrigXsuGjicj+pdsMJz1s5oArP3XwgRcQVo6GJAv9xAmMxMzwiOgpgC5GZRAQJpSLU
RMAWlkUvVDigpIJPuelFhX7M4g2RJqeVDZAZ5YonghHhSg5V7YMb21n3UidRybeokg7FAo4ymaeS
M6NZSJizSkDzbPIZXmoKfhUtCyYSQ3Ss2D6nSV0O9aaZ5EbW3ubXb+FY5tkEpqKs2T4M0/7hlu6X
Dz+OLg7CrlD5HDT2TCp0y/8d3p6uAodxezAMMzmX92aGVtc9khcBUuUInGO7baXLUjkYCLVzaLIQ
7MZye0mOqBAhzRfrCcxfQHNJBFj184cP//VxVDaNe4PSLeNl6LAyGUzWhydb6ATF5AWwtFhoHg+r
/hU4+FmPfx+5muZ2vwl0WC7maM7/+AqaDa6DiBK3GnteCEfnHvYEbL3INp9Bh9qlVnUDOes+dgfk
nZyq7bQMd8C86Jt8Zq6vry8IYVTu0LB5WOvlZvSs6fCGkb874cSDDE1lxhS676POJ9aroqiH7IYy
+NntQ75cG8+UjQc5n6uuJSqflGdkLgCwbR4YwP3SvYIM1PLexGBLheJmx934MMvnrnGb3LswITib
75BntwvVK9WYJjMDC5haX0/RrwhEt90B4nGKx6+FXEdsEIZUcq7MdIK7gfVkMbeH+DdlRE1Ro7S4
w/pC2bvc4AZhmb1Uh8YXn7Eo+rL0sQOV9LefnUg6BOx0QPJjDuo4ntNsvxlIfuL88P7bo85FMfnJ
8+HHb488F8XkJ8/7D04oHQJHzk+ei2LykufjnRvJIOa0dtS5KCQvcWrXLzGIstuOPPWgBjhUf2+m
pqxLV8RLl0H71o7y5Phck34PQQ3hZtEOlDtyBjENsINtiak27xC55h2q0QwBqyaXBwIbwMuiJbCa
fFsI6qwqZCdQzkRyCGmAI/iWkNzphxDTWaVmJ0wehhrA57ElqNrJ94LC05H12UJ6OdHpzjmLmF5O
dLoyBSOk8+5yuwmCmnRWiOrlxJMzmQ9CGsAltZq6AmuvlemFrNdKG0lwXs+xLpjqqEQHEOLtENXJ
gfM6KXVCVKfWcTqAbGqHqU6r43QA0dQOUr2SwgaQTe0w1eko7MWEQN3K2yEJ6PlFgEfrZS827TzL
CnuxeVe3/HbIt3lmRLVKSviSi0rt9i58sZlXuzkIBzlSuTN7CwU6Cs7ytXX++O2n7/+ztFa4RdN5
0ZzgwcRDrwdTj3ix5/5ozAQm1Jl1/u3hxsRDX6rpKjx380KkRgZJGoWCHPgyHToFprEgiVEqw2rM
mktFVcxNREkgE8bkSzoFcr/nZh8q9GOWyCcACT/JKTCQGVMqJXFsXO6j1T64sQ0gCXtSySf9SHyC
UyCwKCeBSWIVuarENc6myJfuu4rsqOUwUyFhLIphmjQ5BTbMJDeyAXNY7M+al4vlzscDkw6hB3ct
mPMnrbAFwx/kk1UZTbN4wm2LxGl4pY25gdHHHDn62lqd16PZ1qYxGZs5fo0BQrO1mT6aNWyiltNc
5ZupWyGP2mfpb4cIOqRpKDIuwiRk8VOHEOh1gU/fjBbzyY4Sk4ISE2zp682+VKl19mmTm2D06hj6
lcVWQnJ3fLCkMsXw2dKi0zLJWxl+Ub4VfskNlmLN16PFJ0Q6XcBvWdRm3bdQE/o4IPLn+tPTAxh3
BDNhOsWEvxfH9G4xB9mxVUUB2/m4SL0wtjPzBkgLbDKF5zcPt05H8EGxVYYZVbvPMt8LDus9Z+fI
crVQ5gxsWJ876iCD1UM+nsKgTZ/6sF3er6R25a8CDB289jwY3MtULRR4PIokzXiijDbdU851w90W
Bqz6k4d8R63R+93da+C1mXyq9b0evYpejzi7ejtKi1KetXd8G9BhiUBt4TVIlf3zK1NEQA7IFHWp
1UpBiKIR9vbYM/QBGKHX1Bw0hp3AHJJfG6C9v/tmoKUojkup5HKc7wGFiDq9smlIkOtCKVWcCCpF
5zLEQ8ubJlrhHiKmgVSphm50z8TdDX5HNLucdE93fvhlJLVeIf3z9c2ICHpNeHKN1Q4D92o3OLqP
D9tNmU3i89xqLIupdj/vC3m8ANDdjMaDoKIBDCv48Es7Orav19ETXotEyc9gOrMlI1LfTpIGdRO9
ScAB6owzqkDpZpz0WqBFe9NRPxremb3YXm+287lxGmeSDv4a/ReMPbsBifOFzpVdefV2atxrxWVQ
3YGyvCmWeqCVK5f/UEj2WZphJFf3Zq6+4jn+58XqE0aUOFPiIxTfAQ1ldczsIT4q7pkmoCFFKsr6
8HEjqPat/4U7qPsVzvYn7sAskIePWWK6VbMGOLT2xAjj/sohqCTUe3/DdJLyjJvUaHZ+8sBK3abh
3WZvxzWwb1obM4IVBA8CbFEeTCzybGl8ALVWPcj5fR2h2h+gd1Y0mtgbTyOjJDAhjZTW/djuLPAP
puWvpfKfLoAFkco/AHmdmcgHJmANEHjYGCGFCnhgSD9+HLS+kNkvkE2p3Jug0LBuqh5IbVyKsyiN
dCyU4v146Sw0aah5VEMaeAvXBoQgSUAUql7wh0j0/axQ0jRX8Gb4VDOQPgAdZdzzQ6PF3OzPjTJ7
RmgOxNxuBwBzpJB2A5KoRVWrPaXQmJDEXIUmonEU9xrX9ub7n/bNlsVHJAmSMGQ61TzrHzabdMia
6Ifgipj9h9E5ToHJYru5+fgqWxlz9TYDMm3hHvvl7x9foSH46u3HV/+9+Ii/Pj7IldGT0qcNv/ll
sUBuwY8/S5hTD4s5fn63AI1X4evxrw+gKgNTvcNj0as/3gLT2Jbl1Dbzj/Wn7WTzdWn2KMqTKvib
YzWWq7fQdxjj+XaWmhV8C1/Y7cgaPpOrt8vVQm/VRmE1Arxovizz1dcbGxJMAwYkpfQGNilB8Per
tyDZFd42X1y9xaXbPqEWsyXwu/1csjSp/kGLu/JNcYtNr2Y/LYHYcrpvWYH2tFmVN0GvZnL1yboB
Tsqm3uWbVf5l9Dcz/2iH8+rtCq1PudpMHtefc4zyx6z0q8V0anuKBtnKPVOZHn8JCO6N62s7SDA6
n7wXJ+t8Y2wCYcDz9fjWzyadrM00Q/7LlaOhgxsmhYTYo//nP9283V6xP3l61Vk6E6/nJz3ZeSBj
PKFxYrJUE5e5s9INNzzm2ejTRrO55EmWRkGSEEkbnAd0FmLKE0k41TJNdCwZDcIsMVHGRBK/pPNA
4s082osKPZnFp3HS05wHQg3oVCzSjDndTCp9cGO74GJVTyCfwYh28BtAYNcYJV+s56bMhoN0SoNI
p0KmwlkKqHFGoQ9z/YyqQOyI5a9j61LNc3c3aSZIFCodyDAdvUIGuIkDldGERuMki8mYqygZM07o
WPGYBDpkkpnoat/fV22n7VVX0rQavXY9+0tuYZUvbevHdxexcaPb0Xe97ejfvR0dILgd/T7aKRO3
qEq83hm9bq0i8XpUVSRuX5enmutb8npUUSLgQqFC3B4rEK9HVoG4nS9e23K8cG+pPMCnnerw9JHi
dVAbsC1UGuD3k8pgn7UKA14+UhduD5WF1yOPsmDFb+UOUBUOv7KKwvGXe03Ac+m5knB444EG0HB5
pyAc3vY4lfMiCX7lyz8X66PvcDGa7DIY7lAe3VV45h42Yt3kYWVQhxeWhSK7e03hDTL58iCPXjwr
9dyjC2YmcwA2NfbE7bCBhxyR5rhmLovSKpjg4IhW06NhW6XyCK2eHX1lMzUtF7ldbp9fWSJrrT85
QKm9nr7rzXIqNwhukuXTTWWQ7rdTuQK+vJ/oHCl4NHqz5dGI5oXeb90hjqh1v9we9apUItz73A7Z
U4db47yRCzQ5wTcu0ImkAiR3xFxJBRvlN/Oln6wiO07Vx3mmFQuMTtIm37iGFceNrL1nY39rQikJ
d4nkC08cNyMNgmcGFMOq1VgEZlK8YsjW3dzlAGG1R50wksSJDPtYlS8zfg8G/k6N9TQbmngHUA5T
H/7H97Ul2psg0FrnBSd/4kl8CBuhKJXws9eJcocgoc7sVEcYdLRQKpahIaFm5uywgYp15AozKYWJ
U5BYJ+WHhY1oayP6s4oCkwc52RFBqCSJQGElar+qAIny9ZPH6WI+Shebh0plYnRIxXNUPDirBdZy
QL8hYKzWmH84sZF54oxoKrlyB1U0M0+Hsne9BZLN2KXTEZpF4a6XA+Lz6roogolO0dO2xlI/CJJ7
NDJNYEmbg97tpQNGBnyWq7mbOZ+48K8GfqwgKC7/frQywSyqsep64yNZrfn7OauhmVEQHmrOZRa5
Dg6bJ4gXR62rwpN7jUwZEYYaofoZxToEZHZelRw8gWOYMpGlGOShuxecPxviA/bdLLbKVve0AQQ2
HrqGfX2tM3LyQTRhwN0xEZy5bGHVRdUNz7f1YrW24gO5gXwFuxssgxXGtI9/ZtIhprYzXzkGC/lK
hKEUVAuZuvKYNyMWHj2jOrI1+fDTUCckjInmDVUBMiNkbGIVslimgdTSiECZGMAHSWzky57heyOP
e1Ghn9YX+qxO7LQz/EyEJoD/sXY671b74MY2xN6mUsV3vhiDxgcvLbJsrovc3m551CEAuvM8a4SE
cVqpEjQ0MiSm1/YiHEIZqUYg7d3psu3cnp/VaEXnAVLniuPDA+9QsY4VBUUiIL3WxA7gO2Fxuxo6
X2EXjm8A3PfaVlfaPWTzGT9tjO/u3q/flIcv1hnmz63Bk03LQLcxDYLrwP57PbK2iZ1X5auEh/tr
Tl/0F+7mD1KVPkO2j0ddY/xftmt35lFO8zJ5o/kCL0fPp69jXP1gvcuVnS2lnHf0vLbj7Jvu9v+s
vpZrZukHtt7aalrr76yWMtquq/SABW8FF/HspbTe7CMnjigiaikimijS3pdzAIr8tIBb7MHJYY8A
aN8xftEeOZy2K5vYg07SsLaT/Jvu5a8F/7r9OjsIqnN2s70yYb4YtS3DQ+wFGKxVvqyLg/BiuMR5
6XmI4FZkammBTqoqyhh0QVPSa8c4yOBhTeBcF9z8BH4xL/XYsb297ETNeA54QNIFHerasY4STUUU
Ra7EJc0Ubt+VE5DtgjBK7+QdgwCvvzEb9QabXmxXyrwpXnWti8xKcnW/tc7K9tVO/B0Sr5yO/9/2
T9XAfhOQsfkiZ8up8WH2nhd1cLX67WfrnFPIi4n+OpezXE1W6MqN8UEY6ZBGWUhDl7tV47lR5D38
cLlbtcdz7HLle/buJqFRTCUnYRJlpdsVNTyWQqbjIAuycQwMPg4phx8yCAzTAQ+pcLhdNZ20XHUl
UauRbN+7neuV5wmsGYHOV90q3H73dgTbdnguSqA9QhiHL+SX6hfOPnLfDOvZx4GLJjtzNCXce65+
po6ctxJxTUe88iMBBWyK3kmTvR7BDaEyM5Iwkf5VdqvUOTCo4Pn9AzSJz4CWZ8arpaqE4i1zPeJR
Hdv5Dos7tvi/qxzUpvku7qncJmHlapmGURZHZKwzKsagb0TjlHM9lnEYGaMzRdxVQE+Ht1gCt3y2
YrP4hZB2sLFg3wNWUBy9WQNk839Gv4GevNkFgLwpX1/mrHnTphujP0rOymcGXYfI08EGbA8VRss5
e+qtqnUJ5dVbVIuJE7y2kiCJEmkoi2KXetoo/mOfG0IVmcNfLMjiNJQqE6zBa6tpwXIj81lUPYNW
dWg5Nqa63bTqLapx+yREF1HO6PjxQSsQ0HPcpdTqZ95SGmFQYTg1hYa/gK63Gk9hh1zsTafQSJHu
tqzBemttDLD45jO5M+Ks8YRmZm5tXbOlXK8/L1b6dr6dOt03RODzD6xCqnBaPp/ghJ/s3o7DG2hQ
mgg1oTB+gxRRKg0yEFZRkLKEEEpNqmPOqZRhZkCaWIOUdQstLVK2J5ezSglvcoGTSNJLTAlvtHrY
wwpcsU6JVOmUYlpD7rJjVvvgxuZT5WtoVQgqJlnKBYvT9CnBSI2gamIZJzJvEFdIW821h1Seb6YR
n0wPHSXQ3WwVMaIFls9OaOafaSIB4S7SWDLCGOxlFNAadEuFgb0sNPLlZ5o3duokkvSbacSnjIan
VYdPIxVIQKmM08eh2gcnNuqL+quhVTHTIi4EDXREYCI3zLQmlnEj81ItbJ5ps3MvatSXIzR0V4l3
8BUMhgx1xpM4bkiznFCRmYTrkBLY7oacpQmRQmacxyyJUv3yU80boXASSfpNNeZz/Qh7xNhWppom
sY6ZgP/c5Txd7YMbmy9Rbg2tiqlmiDTEUBJFvGlRa2IZNzLvKPI2U+2sa1royzlWxePnKpWF0HGl
tIxlw5oWJyTFlMtApixWzCRZpjkVsIPRoB9ELz/RvP46J5Gk30Tz+uyEPdJ2V+OTaQyTyWhBlcu3
qdoHJ7bIu/lw06qYaEQFqU5AHdSiKXF3E8s4kfH21viLbDDZeIYnNzaKcAw79dliXrfPpNcB9wow
9/GBS9gDoUItkozShvWPBkyBMk4ioeM4UwlThGJydFDTkww0j+NpebEp2UgOdwycgxwkkUbSJExF
FvvJEcoUuC5JVCaMoTpgNIkIC6IkVoYzrl6eHPUS4RTu6CGhEI93UTtleAbAEwUnScyABQmo4USZ
LHWpJhWaOrHFPrUpOu0sQAUh6Ewp5yxzSfMqfZ3YkiFSCe8L0ZSpqlyOENj2WRJC1hjODyEgrTRP
4zCWxJDuaaQQ7xBevfuiwxiwVeYCGD3lAqih3IA+vQ2AcD5kKmI01UEadc8S1w19NzAnSZDEtyOO
eoSDP/d7B54TJiGBCHT3MByE5zu0ixwC93nzWqQRCCrYQ6WHJoaDdRBJmTIhk0wKDtpaqmCXI5NQ
ZLD3MvwFgw9KKrQapNZU6Mcswie6+GnLDZNxlKSoKhvXoVO1D25s3+T08mZp5h0WQZuzBn3JJ2Ud
VgBJo0gSlcEq1z2wB7H5dM0qtrYganIIVR+4u8l4qhRXRJtAl14saRpEQZiqcaRJMuZwcUx4CH8K
HO2QGRoEDi+Wpil71ZUYrQaqoUvPsgZVbztHtqD/Z+7aeuS4sfNf6be1H2jw8M7Z+MU2ghhIFgsp
WQQIFgKvlhBrxtDIDjbwj9/Dnu6Z6m7WqWL1jMYvhiVVdX08JM/9cvgp/JV2/g4nl6X6E3tIhcZH
6v6fH/8YPv300FWo15JEfAOectWa1W5t4NbwaAA3Sy3E1HCR0SUIMsWmQfIKSpsIEsBq4187pnYg
yfxJuIYkm1gIeCryYK7z9KushIxZgDRdPXqyhh42oaluZJb0iuhUVNC6OeuXYmoLR6aHTA7MDh8U
B49pTv07+NXd7a5ze292fzl2mN33mp3men/hBVxxGCXZ0NWJ8cP4lIdSnBTGaiHseMFcQ0YdRUcF
nepe9VC11kUH3ZLI6SN7iVK+7xAZK7Xeffr8MJelVTjd1d0v7/9x31p07f7y4/d9A/SZ8PT3dxWs
ZpTqiLoRPohq3abdXr+GLZCepqPtbyliO/afb4Ud5bYN2Xu6/X2E69P2v5vM53hE9dcf/7Wh0lCs
SNFmeETVFrQ7LCg83OJ2hR/Xhm/e7DwHqU1BDcPIwGzNgenKE2odIoLmwbs4Q9kXw/1UuPXQ+u7L
AV1/rR6nTezVtf2ElFZENukZfjgIM1frBWtMVkNrxpSCCjyoCpVvuV5kK82ttP0wbXR+aHrYJ6N4
QUdPD0WjmBDKBVmF7HY6XqbYesgrEFwlowXFG90GhfHUm4AqRFLNVK9xiz9RCmoE7hRe//MQjATv
lA4l0aZGCioJCA4V3Fhy0ak6zi0yG+PRzszuNV06ksxE2USFjYeFsnudus6lg9q9Q5UxW91z/k3X
0MVGJl6cRTaPju+n+xQ0uFhitfHRwvj++NRfv/vhfj8Q4n4/D2D39k0n7/slEGzbJEn53dxABko7
8fsdanOG8SqLBAU3SfDuxO/FqzzQuu9FyUMyvIGeKI/keYhmN4wJ9RCFWkhSm8TCQFOmF6UQecsH
Mivevjken30v5U/5/t3/vS+fGtjIebS1+erSFnekJDvbfDlSkUkxbiAggjxmllYFTUghrXdlQ0+m
BnIg5+MlaUWpu26gKuVwrPZsGfGF4GOAKOyGiukGa32f5RelDlVC4QeiJceTdGgFza3ZJ7AEGTYp
9/r5Ltrhr9+F/bhNFLC/fmqqUWtCcuhu3kTrzaz/+SWxvD3MukfqTaoPU4lGF5FYNhmYCiAZSIgs
hyRTMiopjzfyuIzHJu27f2G7vVP6D7IKEBWVy8DQelZMJKlYQoubIaNXqVqbXLHjqxgoI3+WVfio
Mm8hHxtqYKUGyyDiH3MAkWryPLRQ4B99FWBRxw+CM2eqZGhuAEu2APMRgANYK0QeX8UfQ7Miq/T9
QPiysbAWvWqyryJbF61Qx22SfWRJvu+FLWc+fhmufHzwzY2WWSiQlvtijmHKYHStsjLhfGYahRQT
Jmkmaw5oTqpcQy9MuWSGjoQpJTnYebr4maUcw5PHf77ZH+Zvd3/SUUpvamWVg2dQnGaC41oLWmdV
ugLcpj+9DKTjYO6H4X5v3+wNs8eHv2qk+fbpuh1fZe1dFmNIzHFtkH3YDKh7Om1KpwtOA0plgK8B
euQHHz7+8jNygzffHPyYDeHNGMLd/afJG4ojz44p43O4AylXz2r0gSGTVwWcQ+7i+kuimN2aJc24
Gh+X9sNNTk5B9VGUfKmMnf7adRDnPvr7/Uck9n/sfv7tI1LtwD/x/759DvpRhW5TcPcf37WE6b2b
TtvgZYYqDe1/0tmUEKJQyIaTTTLgTdJO4oVCgSF1edXUWkl2gli99G1iheyk4K8MaXMOEgWyKdCL
I07X0MOmSIeYH3CI7RNFGrB9g9B3DxHffSUCdyEYKWTXupke/S5A0k72A86gg9F1Dg81Sq9MLE70
rItleJRp6gecMQd4ePwesYWqLTIcZ1y3qeoSNq3JvR13g8R/HE8dCJ9MSV5VbrYgo4XogNfh8dQ9
YQvOV8VzLq47oGMZG7mjA1b+3374cdYjok3ViseWsb2NgJSxjVJ3aG9Dzu8+353fDG5kTNwo48Q2
iJTiegJxDMvvyGbfFbQH0+cHreTyjR4eQzZuQtNliGT3Z1dVoYJrRWzz2XtRoiViGUPVW52AW4vi
nEwnz3YxWPpMDWS7HPjFbx8+ff41tAlrTcofxnfzKlIJtSmGW46VIfPVgA9I0wuuxg0Io7krqlsC
sgyN4rfAB4TpYb+6BJS8eFskaL2Jv1myiQbwMYnaUB5zIVBZ+/+9txc0iqwQk/U9i3cZIKWqAR+T
qScAf/384ecP90dCCvDOitbYy27DSTOUcfnalOI2B7K0YBWHxFXQYBNs2mag78mAjJ2iy+WhXPKB
gg5Sm3giLZofGzB6MpIFfNyjPmWGUkAQgmerXC8cuwyOZIcwJmLPOXX0IkvJk83drIJlcKRwhRnh
SqEYlhd0/TLAmEDtqOaoxmUrnbW5O1RnkUZ6rQNklbV7nhu5ZO72IVEkW+88+q/bj0/uo1Bb7Pb5
HUie9IYCzE5Huk/hdnd3u59rVnTWPmRpunewQLJoeFmVRNdhsQxh5lvXmOte0xd/Q5LIeX2SF1KC
iDL0zvV0HX18Ay3WXs5Z7mmVFTrNOE7JkKBCjhwvTl3wLAlTVGpt6pKoqO2noJ1DHaOiESqM8uE1
M5u8IdWpTWTYuB80kAG9bhJA0CLzmnV0ym2JTXvSHQpw5QAfcBDBR+O6RteUsn1wlDv0hGJLpCFj
KzVBigYPkS3+EFvRVbliuWXR6sKQDzvms/IshuJ0wf9y3mtk/JyxFbqRxsnqZ9YyG1xBMacK3leG
TKYwBOJZ4hL/mCWUoBARhG5wZQnTy/B70jW8ihBjIZ3jq6y9yyBqxWqRAY+BSZ6nylOwfYlMOpIB
xiyOPSl/uLHWp5SUxt/tzfZclEYN07pLNEe9lXGmNWQ7jTPVqLzwOTMbsmE5y4pKkAnM6KStRrul
5m4vB0/24Vi1puVAE8RgY1K88g7dT3/tSoxzXz1Gmn7N5be5UNN2EtIGSq+VfP9MXrLW43NvboBD
QY2dm5TsgbNyngGNZs44mMKSi8CccBHxazT0kXVmbTucdUnF+HroSpCOgena+0s5akMP/3jTGApy
VQNBRwORVRUdsxIUSg+XmORZas0950bsvvr3pvYc1b2v+1zW0pqb7llGXkSuQokxLrXYQSbumxMN
j5iVRsXonDJeuJQzijb7uh2HPNmmZf3enPH647PnrP74JmuvMuvwSGYPhXlXtRBJaDTr+qyebMG9
fo+2SUSy/TbAhjYZE63NBOEBLeQku66P6SK2gFvewdMA+/6JZwmve0uVepwgm+wZ2lEFrBI+5oVO
lhFPe0kRiZdSFVpX44t3IQCEFKp45Xu1WjUh177xvNKycEO/+GljKKMdVK+V62SEnC7iEpz8hpPF
Zfj09SF2k6RHLTtZo3shlanM7yMk906MO/KmPkabPGoKwQVeekGVRXBkTQqI8ajUU7xHh5hQIxDV
d6PYy9BIB6gYCEV1wtgKshEVhX6WvWKVZXDknRADXiwqjq1iCdEaKFVv213S1yYGnBZzl0MU6Syi
EMpfettOJUMXIZl/AmIsGtWPbqNQMSbLokLXBFskIlnDAWI8EHWeI4PsjSsEKDvNRNeQkOq6ckLC
MVptygRoeEj9XIyHxqb8LptsguGqSLHtvNGG06hyftFzdUE772IiwxYDHpKRuMVGL0lDS4ozyVfE
LWyqWTmvpZTdzCseUGjyBNp2tKE1EGa+tV0Lah8leanc0ILy1FONnNRKjvpvVL3uOdN1dPHRAYPl
ofIGRaLOsnXiPm/hfaYqWyeydqi7Vi9Da7XlTNC5lii5zxKF/asFDA5keO3wTYNByrVNu7ERCCm9
5ICCN3HOgxHIJVRW0Y0XjTVQJMeT1+XsBlEtEk+J4HrcZUrZPrjX4C60n3e6TUv7QQZLPFrReDa1
jUUfXHommlIhSVaiTgxsCAxFgGPIiCz+qofK4UWDJcskF10JOF3LbLAk41eFgsgcPsckymCWEoo9
L40VVUJBzbXjxnsWTGNxi+OrrL3LXCqJmeAAZbMLEKI0KJ77Epn2VcvBxLgHH3GwxkerahW1pzQv
SyNqEskq6q2MW6wh22ncIqaatADOuJOGOe6BiaIss4aLEtDsTHzmlJKK7Zo1LcctAkJTQVpUOS+Z
1+mvXYlx7qtHB96H+7u5sMVmCloqZ+jkpC4cSSpsIQq3QcTaGvMfeFzlBa96NkxkxVkxSTEA6ZHH
5YyKsKrWyw6PW1J0vh65EbTLebr2/lL6YYsAIkgvK9OQ8D9CtgpCJVhrqoNqhqwxld1Xb8rHu99C
3M9Qng1dPB/Gle7745usvcqEtYpZJB+DUFpymks2uj7Hs1R7vpNT/mTFuRgtHk8lil1o9SMkh8i1
Lc4KjyIOwIOPXEaPwqKKzlCjL6ngWlp3Wrv2bWqKJTMIVhyQs6DoZXhgW0h0Gdp1k5Wk5zY5Z9EK
7LkLp/Ttg6PVO9XbtKgtD0nJWmBhtGRQUB1SOSf8Dxe6FKWs4mhPojpn3WvWBra1r1ZPyLVvPLC0
1X5dhpTWLluvZC6513dyuogeOACaMuOexb/98GNreeKK5CWirOLp0jxbdpIB2fMN5LgH78nvLm2u
3tWAPHUbNJpkA7GoOY92wrtuNPcxpF7myJSbdRHSEZWRsaVUmYovztggY7IdhrSCjmQTMFDPEDZD
Vm2CzALN7F74Z6pybkE4HpmaupELoChPgQfV8RGs2WSSrajxWqTzKp+Wv5CSC8a6y/qUNftL2gEj
cwYvrjDaHgGQxVguL7POV9COjqeMTBu95C4RT53SwetuzdHimSNbUIF6ttoo07KgdJJGyy1RjCWc
g5mKczxGFFR8OaAUCXnTRpMeFHVdHXLONmouqoDSy3NZ3GpNs+nx4qjpKUyteCUplTbtribF78gg
LrJGWoEtPrVZgNsISKMcl3MXLLCq1GIiaHZflr+tOH50wEYPCBCKjAClTbirvoXTN2w27Z/XY9yQ
YDmga2uzizyn47JfQU3aZa/HJF4/+Ow0FN6a9ut8yW9WnEi64EDPeJeWsWwMhIMhE9b0NNZMDv8I
UbocpZalLEyJTSibIfjYBv1qHmRS1uOfUnaCm2LdK89DaTQh9ZKraLLJQIT1mdSrsgovph0vpBV2
MS1kp67Nou3kAzxzJu0iVj3eouVJjhatOXDU5lynt80KlrUA7boRwEbr7Gz2aIP1UrOm57MP7nld
mOfnbsmH2cdES8wxu39WrQw5JplMKxXYJIksnf//AlVM+FFyzuZANHAkR2dzRBDI6ZCwZbbe43wb
rXjFQ42WVsc9slS90aDRvqUeIQ8jDhrFDqEgGa3LWqOgicfpBm/2etnD3KLweffLp7vWZnM/kbq2
N0vIJVsbGFrnluVcKouRA0N5JQJyuJJd3r0P9w/TpUv+ZgN6M+aU6Hf3QNKWNnIWeurk4uUgJ3Ci
ErciO0skHozN4E03NXZK+20QZr513f2kxg+enPiLE413CtUWlDEhiiWuulDH1IdGclVzdcG7jiYm
ndCg5t2++xMSd/F5MnHMLJdYKy9CiboYuzAWVWuNfL/mUF2RuaognEdZporjXmebXjNxDPzztfq9
5iCTMLbtxkYgNKsbUOwmiUo2qv18s2j1eMG7XBhfuCz73+7/dS8PVtX7pbuPv/xcPpe+MLgWzHEE
Uxvs2SaBHYLlq6C9DKKVZDkrg8RburtFM/Iw/gQXgX8RS1ta2/af8O/amK7d/qDu2P7Z9+E2/9ye
+Fg+hxw+h90+doWS+/N7fPuXuw+3n19kjd9vIPauogpy/35OKfC0wLvOzkBR79He1C50W0RMr/sW
cOM6/Vy7r5SbPxaQw/cCUouKiye1+hfSGjxp/Jte6cQMMyOzLrnIFbfI2yz5ISNJRpFSbUqo4pyl
XBwr0WmmlAk12xpzSS+cdblEctO1aaZrmc26RClbAW1NJnM0THCumDWBM2lra8xfCt7KbgYSPkpi
GnPLH6yFap2LSgrcr14kcklBEnRLvzV0GssEPb7K2rusIrGYao2lQkLlIoLKrvbtPsFJD+gapCuz
LtdAPOtKbo03eP8ZmluRKe0Eq2jg4rsAsRiOn4/9NZH8fs2alrMuLQjLY5u56nshzemvXYlx7qtr
ukVcRULiWPi+Y7xze6i0y6rxsxWyhABHJmesboyMSSMtQ0Vft7TLwJJw1bmENpfPHSa3ZCZ8PXR5
6a3xPV/qdCn9tMtV3oSv/rvcvt1/cfefaNjc95MuBacl9FqEK5Muj2+y9ipLgPpOWwvzaBp5qJ5X
W2eYC5l6Y8frmJ88vaJaX7kLXnTarC8rD4LTJvYyCU9zni+zErdmPAu+WsN4cvMGKYMCW4Wt59PM
zwxqZZThPHoPIbgQeNFehyhcMYVLpc2rJv4Jcrz3+rVvUu32H1/H854+XqX0FgyALQs98xQUIyTX
UJKXKZSWrGzxDMdkkPRavjLhaYVl7do3Ep70PdvrartyttlZXnPN3ajL5PT0wZFODXtdknDV1VWP
4tyIniNuSuE+OJKL2WfqKZDRaKnBoPnBL0m4gteSE3fHU5nPXaxLucx9THSW79q6hYGA6ebaBUF3
ZX6Z8kIhSS3IXRMQEg4FY8iJm9RzUCzVxQhJeu4d5bkP1WjvhZFeLsXhl0p5+tDoYqqlrZp4G1eV
6ZDexqvBzHkb10B7GUQrydKpXvqiHsdr13nucVy1aNLjKOhGniNT2eeyt2OpeGMkb7Gu3q2emK59
hCRHHhkF3snexhuPGm4OVneKCFaAo3ucjYzAniOfT2hVOBGFD72eLlPbo4+Q5tfXZNVIJVJr7q5M
J61yDfHI2zAy/rmT1etqjdWabL3dBM7ROzvg7aZUKC8VL0FwBd2I6zJK0pIeHHXcz1/0QcsQmoVi
e4ryMkSyftvNuIyWsWzMpRSedmGN2tHn6sGSIT2LaX4bR2YyXzpEUkK7z7nSc1mv4B/0rJz1LuuR
dKXNbmtJO/39qqQVAKODUgC61/RD+Gy4sRVM7qa+LUOY+dY1WvnSR58pQ11V67SpqsbOnLvlsyQ5
yVNHhhj2MxaKrFbjHQs19FjVlNp9fM89vv7f9uDvv0F2dP8hI18qt6h94msPM9ObAl1mTtF6KIek
tg/3p3CkEMoFWYXMcN3ZIkNBfjGPBH9PGtPaPQtN+8JSVMEhT3ERH7bSa1ASTfZcVClRS/+aWT2S
dv97/fvMJreDUZPmxbZO2asOxrvbO1zV/5Ln43nQnI8S//44D5w9zgN/++b+Zvc/u7G6+j/vxjze
0+fXtPU9eX5FMGv39y9Jxf5A9lSi0UUklk0GpgJIhkZaZDkkmRJaR6qNYesOZG9nur8AMuIzMtb0
MpmxlfigoJXQj3Uv5ARIeuraJraxjX/RwYPn3mTAY1pUYJ6DYgJ1L5Y0/JO6a9uR40ayv1KYl7WB
zV4yglcDu8Bg7F3sg8eGfHkZGA1e7V7IaqNbkj2AP36Y1dVWdRUrMsksOXMBvaguXZFBMhhBnjgn
DYhahDKvgxmbDNsGmT6Eb1FhrRw1l+I3MhY4K9GvNsxHo1A3juw+OJ6BZzOMC2d58ZDXYooNcwqt
ctE0wm9LdHVLhmE1gvAi1K75JzOhCdOuOyetF7GMoCkBO7thhM0M3Jf/RsehxGbLyr7XPCfJu5kr
PwDXZVMuYX8wKuNQZgEfgk58sJ5zxrnWALH5AciDr9btfDx/2H8uxc92j/98LHFq3wLwf+/KVx7S
oROgvHV4vn3Ssv97JZAdvlg3k9qhXuaBT+/ejungSXz+ff/77345TOt/PD6f4Kb3xWOPh79S3yI5
tcPMNuBC1VW1Y19va68yeFaXrZ7ce65j9CWvHcw8NJG8KS99TNedWFEmdhjL6P/4owIZ98TXxUOP
F6ygCnhgbPdbSZ9L9fA2vfn99/1A/LD7Yj8eN0+v3pYPPD/zYSzaf2jhTCGeejzrc2DBZCE81iRY
p6fLfMvnG7IsZ6EOvcvnL+1YR3NyhPSiB+M5i0n1YOSRVES4MHW+/3L3Sbz/+a4EO/bpLqb3dyHd
7t/b/efubz+5Nz+m796E++KIh+K/92m3hzbUf57aY05+vu9nxzMNK0FJ9F6pdPQMHzYftBEdK/VN
DMoOEqMcojRikEKNgF2IFsTTLdKvu6MfaH+ij3U2BNQWAi1C3NTZUBoLM13qP3A1mpnJjAioYAkt
ouaXzoYQjTKyJG5dMQIpwskX9tV/30guhPKGR5/pUxA/AoKKnSGAFYIJmUUs/2U26oglV171FITk
UupzQ9+sRjo2NVS+z7P6qF08ai1ABJNTjXZlci6TeiPQqtx+AM8CtxFKnYax2ps3dbY5YdOyIjIb
JaQNLKRqM9bxoNeNo7a7VTZgpG6tXgzhxFhRQGfrVCnGkHsA9SyLVxyZBJqh7Dg4WMfdIE3Mg4yl
/HXKCYk1Wbypk9NPm6YKnXzIGgbq+FHqQGeOxnuT0iB8ykMyXg3G5vGOJ2lvZVKY2e6Tz7//fBcf
yv55AeOMJIQCWqTon9f90062v11M0Y6nC6CqSo9Ty15QB03QIkT//ZfPEWkM8LevnU+vRwNVZiFI
FbSrQSkm9zBSImf+wM7Ehz9/cxi/OgCU0h3B2yElEZEFMSom1W/xBFWbz7Fzkhu2twGCNm2VSCUo
QtgXzvpwn62Ck2WuGFYygAkGYyMlD0rHIBjTJTrxHLwsRotohApiVXhyCXFzJwr57J2OJ8Mkb7lz
fVruxXHu9nmOjPhadCWgRZVl5bp1znInQyVfiJ8GSFwkL4KssXcce7lqHMmaV7aoJfkbswwQNChV
pb6fDOSkbasscklGbt4C6P6yCtIzJa+wwZZsoZpdTk01ksIPWjTtz3dlbW3Zkk0YBch6BnNzEVuS
BTlvKV3qeYISzHmOseQKXbUuyXe4jsvoUNZwlTPOr7H5/IXDZGKpZOuYfO46vFDUJRhURbQn7Tgv
HCpfGZsPDGcuqQjGHGoImRwHE80QpRaDSiCGYEAOoANPoOV4nFCpIaY6kT5t9ci8AZt8qufe8PMP
fja+NtYWImUs+1BJNUvZM4jMYPDOjT2VLjirGWMg/m03fnF4+oXynd8eh7djL+XN3eN9vdQgiSob
n2HJ5Fd0vGiBotYTDWNlRm90zKm2l0/GiwkDO2R9Xx4aMWVLDuSVt6m2BRw7um4f1Rjywr767/Ng
lJdaGqmnzu6sKrsVN0EA2hL2onNSsbJ7lSmYfEyrnt2RSPpVwjppUd/AdBpC7i8t2s/1/CqOAAbj
xz6NrpuYCfs6JCNfCGdHwY1HFivp8ksnV40j2TFXmVdkW8afGLlpO1o0sS9kekGXkGi1yaaCQ5kx
r0gJIGhRxh4d+e6X+LShZGtF4lwpqFCazgjYpALPOjOKvJ5qUumu78FclrLTCSz/av0q0yNJ7nHH
Izk9ZPXU8/DRVyW/zMpJaVP2eEg5rbDcOpuHjJoNI6Xo4MGLgUfvHbfRaxSVlHNqu/y0adKQm8mx
By4+ze9jd91oXPph98rdPRZb3dvdOClu38e7m59ff1YS6xtQg9S74b92P5dYOqKX8v3Dr25PGTp+
BIxmN2KQivoIv1FDfZe+xmM8twu++/Gnt7v0W0i/7Lm1fv3p7nXaffPq9quvv3j112//96u/3/79
q29vv/nu66+/evXtF5+/xPnOwe3ufihz7vkhd4eHTA+f7Z6bPcYEfTwk/mDrnzt2l/wvbsqDcT4O
UZnl793j3fuUfns7vonjfjuUVUgM3/h9GDiOn3mKRocvA7sBNpR4UHlDwaDk5b/Khb3h40E5ObVU
mTiluho/81CeeP8qPH2xStv28Vz7x8+j2Ttz/2gHZM9PB3x7eVuXd/kg6mXiNYx7jmdjsPrm5c/v
j3z/mP+3+8bdcXb+z/3xsrjugvhTnvPDKDy+fXieP7LMPTngfu49vXyYe5yVMcABPl7AqU6QK5hG
pb2r5AGGPLaGloPOaqEgyl7olU1gK0z1M9IAsm21afc4GsezNW1HTZ7Dij8NnwA3cGFrIzmv1xlO
8ty6z11nDlE3AANc1VmtCd3/BxurMYQy9Hxecgn7rYipD+/vvyW54jfcDiOHav2b3JScrSqsg4Y+
3uqoJj88X3h9l97sn0yVcDfo/YN9eNEi7jONpw2/ZWSubnPnAiPtgOV3HcGMwMOSlkvRFzDpwq6D
cveYz0YZ7pxmFQ25GQUN2dy/TrgkUVHHzjpvJ9PBOCNZ2dxOz1BPm32mqsK6afQJ2fJDchVL/lee
QCtRUwScnmizr7Dmrsi/3b97HfeMNGMUuxsbivdA53FEv3m1G3bhqQD860iU8PBwXyLdIT/e/++T
v1xOfP/y77vbOjbHbu6wj+S5L7XR4pRMKuVSSsFVydgmB57kzV7HYyRsBpcD1WLJX/MocZ1Dn8s2
l/eTFgE2HMBfIvopHlNgo8ypKqt3jG+rWShICgjA5XAk1N6UREqXHa1np90beEUezTPilYnr67pN
tDTFXMbcBrq/btZc2lbAdrXbYyIswUCgVywxqEGmpmff1ko7Qfb2Ay6GTLFgpBWgrDNVspHJ5bC1
GEdbBLhE6XlcgiNXqAVZU2CdnF5kDz/g8jIiaRQlxdJaqPOWjxmjOUGU+1FEJwTZhA24pHYpFbnG
VIzkvHodNUGWLsj26lVmN6d4v14465wdVFutuRGaeTaxC00xztdNW6ZzdsQOOotNnmQHpY0BvJJ0
Y1SlvC0ZT/S8dkM8HRAWuuwSh+kcB3b5rb0MOc2/bIhS4igHHmtcldMhaqHLnhhS506yM8mCKrHq
z+5xTJaGC5yqHZ6eEWvjXtyxDHi6+/HNHpF1wuRaDAsjg8Rnu39Ur3OWWvDdeP55/LC3+2j3tnxj
V+YjYdrHsOa/79+9iSceOJ5eT5y2968/ljeuprdJMt0utfKUe3eWVRMWbS4DBLLNQCyGwSmThOGx
VD22h9dDkP3z63iMrDLEcoSX1sHbkj07Hc5lXOe4jDawTWulpjMrS2I/6lOzUaipYyeHrZ1yCyDr
INECiruA9QJhmbIlm4w9qD1BN+GLNkpsQonPgAzOGZTFpz1DS9q5ytDSrAFi8fV9NjkbFUTw+pyt
e87Izqd7+rM8Rqa1YnnlbVlAWTZSKVVPs5JA8jBbLGF58xhL9eZMjKbG8jY9/ze3wdMt6uIKt2RG
g1PJOpe6tiu6RV00qjZeqj6l87bkaKHkI7WGksmBFQ0Kz3/SwJJHQXJ55mYFD4yj0LrnRkeIzQU2
QQY2uTwxclEo4yFaYbvOPOnmdrk8tQTORMKyVqPvysbJ/vJVxlSS27tcnrlJFAk8cGV1V+Y2YeDV
MjehhWfGJukruhIz5t7mmqYF3TQtF2duoSwEn0yW0nbdbpI90yCX6KwYBBucBYDKOp0zmFvr+xN0
O7dsaee+gArLwQSfvWasp6NVqM1VLqRFIK+kR5M9dyIyw0Luugam277l8kNwXhYog8BSxh4UliD1
rtYZWDIPUYszNyYgmhx5gqrE1bTHaPsWEbWk4PJeEDrhedCdM902F9noRl11hfNAFqUqmYIWXdAq
ockKUDV2fB5XWIe010oeudNMpVwTLJsc0811Ewu6i1ct7/10qTySiiM7aQ/RkyA13tZxGZmtqUY+
ICLRTdKAcYmVgi12zTY6urUfb51GXw0l8DoZJHSdh2yuA0oYMhFRy3M3LZw1fKS/FV0RbsLAxkzp
cc9FVXx8/+b1P/d+5DoGJlGFrmTcbO4Ki27RUMtzNpkzT4IDaOgqrcg+CNAtGdIhAzlGPhqrZan7
NETouuTYXJeGMGQpqlsytjqZCfqyAAJIxK7tym6NXk+QTQ1l2rbNsIdRZTjd5of7n1/MNGU0V1lL
Fyp6qTNm2oSV7adbp5EXlUtOy6x43yGvJWnQjt3Y7K8Xap8Xv1S3anMlHyn3CXp5QhkgGes9Kuwi
9BJkg8gaLpN0d4NenKdpKxhzTHOPPfjfKfsaE96Dlu3xYih/PCmEmCH0tIdIRq/NGqH5DEvOluXp
5y/asrHpRV6f6eVJLQe0aLSMsnIZNGd+zeajn8XyfApbnqJ5rtu0tdpE0m0Cevn1NshoBTgFGHTP
MNIGzmZgb+g36mZhl2R3wTrDS3ZA6eWdngDJBueE77oQlTTE9OPI+0ha38s0VEfnfQ/SaCYFpuir
QWtCSEKSKlbrzCDyeNa0l0ancV6i9KyE0JS6Loj3Bl6O88ejeTZaKSmhGXiOeKqzfCan6Wm5kKpp
JDh4enYfdanMkgIhu1QWG3Op/2OOaR/HopluOVZIeZIde7t7fGrNKE9Q67Fwuz1p6m7Yf7beaDFS
kRyA/ndv3n6UBzwF0M96WhJAL0l9ulXiCy1ZZ5Y3YSutos+aJw09aElJwsHXcRl5Am/aTzVOKzsV
QiwJPnjWlXnD5jYxGp9u2o8PTjcxx5XPApjF1HNlLDeH+5Y07tu0o4fOTlxEqewyT6rkTF0u29oh
lSSh6GAWn7goCKFk257zrktPSeK+1/EYee5ulh8iuFz2TJOCydhzPitJ9PcqLqPh3mZ5wc5GZnOJ
igXflY+TuOp1XEYWwWZxERyYjwxF2TG7gJCSxFWv4zGyQrbL6Y6CVsykkscy1kMFIjcHpJa0Opdt
r5PP9ktluICEPMlz3MYMl5FA6nVcRqb+tj31P0WSMG2st57HvsyfBFCv4zEy87fL7zOdtMyKlD1U
UPBzXLa51J8GTtvlN4elFtcGA2cCu9bl5oDTkoYk2+WNAzlxYYUzKfcgkuXmEMmSlnOyy1s+HRc5
BK1LDt+V+qvNpf407Ne2p/6n61LzKGzgkRvVlZWRsN9VXEajam176n+yLpPKEEsy6wV2JWWb06CR
NKjWtmf+p+vSlCpJxiyjlH0u29y6JLUNkLWn/mf9KN7mXKKZ4bYLN0LqCaziMhI+i2wxepCDls5F
lWLf4eLmALSSZMFHdoWeD6Wsc9KA69svSY7zdVxGRQpkV6BYCQqjzRKl6Dr3Idm6V3EZiZpFtpjP
VIqoGVeZm9R1gk3ScK/jMSpSIGvP/M90lk1GHxFV7jv3IXGg67iMihTI2lP/03WZcSR6ES5k2RX9
7eZKcpIZHFl76n+yLm0Wljlteew6wVZsaxW5IuGfyNoz/zOwpcNRMN6WNLanWFKbI7NWJJk1suU9
OlpqDgjajmTKPS7bWuqvGJn688V91Tx7oa1nzvmezj5FQkFX8Rgn1yVfDo5Db3XmkJB1HZWpzZFK
K06uS74c76M1AFfIdTB9LtvcuiRBocgX431kGrHsPjlre5IyBZtblyTwDvlyvA8D9I4xD6Ev+G+O
llUBWZLz5XgfYCJ7a20Kpiv6k6i3dVxGluR8Md7HW5ND4Ahe9WT+ikS9reIxJCtyvhzvY5mXUnih
nOu5jFMk6m0dl5ElOV+O90mJa6E8+pHtrcdlWyvJFUnAinwx3mfML3TwnsvUVSyRqLdVPEbC3BCW
431ABGNN2Xll7GmvVZujD1UkzA1hOd6nxDGWFc9cma51SaLe1nEZuS5hMd5HY9QeI8vOdwV/sb11
SZ6UwXK8D9dgfZRGB95zT6Lk5o7KSJgbwnK8jy3rMo1nP7aLm0VtjihUkTg3XK7QrkrsB5AxhS7B
YSU3V5GTMDe8hkazTNyUvCxL6AplanMlOQlzwxbV6IsSEYbzpPe3JV0u21xJTuLcsEOg+Ux6gUdM
MRWHdSVlJM/lOh4jK/IOYeOz+8sgSi7KhbXQ57LNleQkzA07lI3PRHAVlMzfJma6IMWKRL2t4zIy
9W9RNq6vy1KiGgWiZP6h6/5yc+SWioS5YYfS8tl+iZCMkMhZ7jpc3BxppCJhbtiiXXzpPFbEYDxy
J7qUxZTZ3LokcW54Bf1i8DKZxD303ZOQtJHreIysyFv0iy+d+yjOnPI6mi4SJ0USM67jMrIk79BV
Pl2XJkfBPJT1BV0u2xxXpCJxbtgiunzh3CcGrR2DwEUPxZTaHN2hImFu2KIofGFdjsLMmZdEQ1Q4
eee4bHMlOQlzwyuICXPngmDOjiuzw2Wa5Dtcw2WaxLnhcu3SoJVkjruAXToKmqQYXMdjZEXeIg16
YV16zqSD4KWTfZNsayW5JmFu2CH3eiYFYEIoRWKOlvWk/npznIyaxLlhh5rqKa7A5GSkjzLxngxD
k6i3dTxGZv4t8q6X1qXCVHIyXVKNnss4TaLe1nEZmfp36LpWzmMNSyk76bqi/+aoEDVJhYgdwq6n
/ZeGWeOjN67rBFuTqLdVPEbSzWGL0uwl8khneA5MuL76UpOot3VcRqb+V9Cbjd57NKMwqe8KZZtT
H9ck3xy2KOBeILnNGEsK6zFDzyW5JlFvq3iMpJvDDu3bs/2SATNSW1+if5fLNpf6k3Rz2CJ+e5lH
RJbsXyHr6ibUJOptHZeRqX+HHO+ZqkpgqNHI6Ho6yfXmxMY1jcPrUOM92y9DTA4dT8x1FUubw+Fp
GofXog98aV0Ct1n7kpfpHvSK3pyOt6ZxeMuFgRVo7SWIqF3Xfrk5HJ4myd2wRar40nms1JjAeOtt
l8s2h8PTJLkbdggWn+WxFsELnROXfS7bXOpPsrthk2BxdV06NVLVOC4474pkmyN30yS5G3aIJ5+t
S2aUdA6Msj3gFb05cjdNkrthh3jy2XkslCxB8sxEV5ev3hy7mybZ3bBJz7neT5K14GPPkuo799kc
uZsmVabxCprO2VjGgpJWdUH99ebI3TQp4oxNKtMX+klQs1GYSvNOl22uJCf55rBDZfpkXRrGs0Tu
pO/Cx2pSKXkdj5EVeZPI9IX+Sy6KlQZUhB7oot4cDk/TOLwOueszfRIbHSCPZZJ1nftsDoenaRxe
h9716X6ZWEYnuAihK/PfHA5P0zi8JgHuSzyVPAQ+wspin8s2l/rTOLwraHBnHUvgD6CU67paIrWH
V3EZjcNrUgWv4wqyCOVfmWVdfOt6c+RumiZ369AFP8PHRsxSaOsgdiVlmyN30zS5W5Mw+IX6MlhZ
UpWYVJc6ldkcu5uh2d06VMrP9ssgmY4iRtFzT2I2R+5maHK3Djnwc7xPjMFLid73nPuYzZG7GZrc
rUlu+8J+GUr8FwiuT6/ZbI7dzXCyJF+uoK4kcBm84hB6zmPN5uSGDUk3h1cQBWdZMKNjjC70tOAY
EvW2jsvIkvwKAtw5Zh6T1oJ1QYoNiXpbxWUk3xwuF7XW0aFzo5Zj3yTbnMiqIenmsEXx+sK6jOgN
uvQv7q62yW0bSfvz/grWflmnKtTglQRma67Oayd3rnO8KTubS10qpQIB0FZFLxNRGttb/vHXIKWR
hi8QCUkeOVOb9YyobjzdaDS6gSZgJJMhr+CIi7tkVRBv6B9w73VzvjSKaCm54EEhxsXdsiq8583R
gKt86+fHUgWJUipMWEWxuLhLVoX/cLeAm3zr49IiazAyeY5tUFB2cYe7Cf/hbgFX+TbOK0itO3ZL
pzxoFUNc3OluwlvnRgOu8q2fHwvBGERlHJQWFMd6rzR9FI15y9xowE2+jXUfkmVJwnKR4qAQ4+IO
dxPeMjcacJVvY90HscQIopKcBIUY3jtNH0dl3pQ84Crf+rqPsZRnzOZGBRmZt+rtUTTmLXOjATf5
Ns73yTTkSzLnhoWp7OJScv/hbgFX+TbOK9A5RBkWQtkkaFx6q94eR2XecRlwlW/9fRJtrbaMEIxD
6grExR3uJvyHuwXc5NuoK0iJEijL80SGFJWJizvcTfgPdwu4yrd5P4k73QHz1NiQrSVxcae7Cf/p
bgFX+dbfJ8GYpFophoJO3BUXd7ib8B/uFnCTb+PcLUsZzTIlbNCVoeLiDncT/sPdAq7ybeSXRlr3
goTEOGgV4+JOdxPeOjcacJVvfd0nMwonwmY8CRqX3itNH0dj3ow84CbfRn6ZSqUkzmRY8Yq4uKIy
4S8qC7jKt3GuM2I4oxjxLMzKLq6qTHiryljAVb71OJayRKVWUJwHxbEXV1QmvEVlLOAm30Z+KXlm
TU6ECTp3S1xcUZnwFpWxgKt86+NSJ4JmgluKadA+ycWd7ia8dW4s4Crf+jki4MGEzrDOWEhFsbi4
w92Et8yNBdzk26grSBKecc1zFHRftLy4w92kt8yNBVzl29i/5JZwJlGCg96Llhd3upv01rmxgKt8
6/MlQbkSudIyC3H+8uKKyqS3qIwF3OTbWPfJNGdWGmrTkDhWXlxRmfQWlbGAq3wb70VbxHWmKUNB
73nJi6sqk96qMhZwlW/9vWiSUyIIzAF5mJGdcaXs7e+T21v3vRd2toheTebrj9HPP9xTRZnVal3Y
6HZRrKLJvFip6TQq9HJyC38W0WxSFED9xWEHdrTPwbEhFxAXFuRezEfTxbvFeuXWEDRM7pYgJYNu
uZOuCg70my8OQms0DUM+ZVi4qCzZ9urmO8YWq+UCUCwV6NfcZDYhlMMMoYlkENfwnBn4E0mTGpql
rBXagOtXq6fjyXyyqgn9GSxnuVrfbhT564flpOy98qt6AZ1tV/a3M7bf3qGtMJxOE0g7uUw4RkHx
2oD7V/vr7K37sxyrb6KlNYsYTKDo0Fn/pGSwzlphuBhX4yzFeQI/IQuPckCNXn+dPVf6vcM6sytl
1EpFP794WeyjyxdLO3k3Bwe3mBajDm2eBFm7NgcCdLYJQxhrk7tz74P0PMAvAzg73kIb34H/cyvM
kC4bTrhImNk4nH/dmspv33+3dN6raDGP3IyxL8RDUY+F2N8UCquWla4BTbTBt3JadUA6er5/SDy4
5/143GJOjvOMZizFKCTPHgZ+AJZNn7+qvvWxiKsvAns36VxHyQiNUBzjM2q0Ppso+MpMzdU7O7Nz
F6is7BKmOeuiA3DrNoLvfvEO7oMKOGVGMhhoeZ4GXV83RIQARJvO/l9VTZRuIEMDpZlAlNvJ7J2a
wMifRy9/jJQxS4hHHg/7w2BR6T/Wk6WN1D6zi4BZATPtuK4jLMkIJ2KEEfwPPR7OH9qI3i18YP8e
qQd9sLTx7XT9DgzkEwS27td3IPeP/3hxMVbSN6XwVskzPGBFfxvXF1N1Z8cQU8EAgtwHk0xiIowK
W6BwZ8N68grczCsetk+AO5K5zUVia8lFheY+t8gxUUylmmiBeJoxlGh32hzQKU6RVeXcf7NarqEL
3BrMDeSP0IxW03GxBn1AlrmsHqv16v3Y/TkugG90q5bQkzfbdqSgLOcqZ1jLhFlCeE6Y24+0uWWW
yXY1eFdFgtQQZi/eC+AZHrCdsQXqFhzW64kpk9DMCJxTwmjrAuCeEO3g+mcN4ePsNXiKpS3HvNMd
DPron7fqj7V9Y/NrDVkst0THJjE4ZgrTGFOcxUZpqnXCNJPkGiJKB+RTtHUck/mlioNJDlapYokw
i4mmLNYc25jSlOk8TbWw6VckjsyYQQaLOFW5im2u0hhn8KdR7hVTLRGMwa9IHJyCu4AhEYskp7ES
FMc6tTiWGcYI4zQlxFyWOIE+x7sfiAfsBzbWnhi1KMswDFYTch6TdEc4e6Yn6ln2wljmGJtMaEYO
LHsdmpraofWvHuifqOjFHOY0u3Q9WNi5cf+6QLQAC3Bw4elqUubMdrlqz1gGnCo9OGMZBM+tbEsF
M3DipuOgpYjTyNJY8plOHXD7cVVGEu8Xi9/H1ZL1OLMugRk7cylZTdR08u+OdUfvYdlHr/oMxehi
wUQoLVJB86CX7U4kUH1VZbsaWJHfS7aYNySAxBG8nRMVhnyZPYL4djlX0zLkg4cTrUr7cr52Mj9n
t1QOYyPL9fYXMHqYG+bgiXMgKt5bMxwCw6zLj55QN24ZTmbu3HAqFA/aiHNSRB/Uct4lxfng7hlR
ZTW/ntJsYL5q6zg2It67uBjeL1rQU7CPj7bMWuLppFi5PETNipsy1p4BvpnapjOFQwMZzXKxcF8r
ig+LpbmZr6fTVhRui9Yz6fHWSW8yH3+YgKfYsncBQsIgIM7zHGIYf27GcwtOw8gUY8qVSghLcgux
qTYmIdTiKjfL1bTYJmelKF8qQXM68edFx+gkIGhygHw7OAwPKNZoSdSslJIaksNQaKs52xeiFRzx
Z/Xt2qrCpiwT1mQZEhzXjaYeNh2ymnZofr2lXUOsHF0x6ChyOrrJJIdYXKQxQ5mNbZrpmKcpji2E
jBC4UVAQqUZkXNprueUeb7bcq89/t59uwFIX49vFB5gN5oPHqdv28Wg57WuTVAqthVSK8XqkWhun
khFCBNagdYoRS5ESMHp0QiHM0nkmH3+cendmjtNJ2Dj1rg0yPKDepXWcUiUUUhljbVua+0K0gvMm
hQ8HQ6WDN2pSQBNqFcHgGIMOluXMVoxm02uKR4THHEfxf7Q8TRAeMR5jhNxzeHSnismdhanSPSVk
ROL2Hj0CY6OVBPojJtwhKGdxgOk+x5iMsIh5MhRaEjAAKzeXpIwjqbIUSX3AzR0adO3Q/Ga3r7UM
mnFt2TDVQa/HmIr6A4LQCLwja3zOyYjFhB6LunTOv2wZ24/a3jpbG79XcwPZ33X0X+B47j+OXr7+
6bs3r5+9Gn/35s0/31xHv0bPwUTXq8l05H7J1WS6Xtqnf/0f+yl64JTnwCZfrOduYQUyzdu/fhO1
xP0B2He6hu4Gp1JqkyM3hmipterjjf4xEiNMY9LS23wkvScuQU9AD0zHLki088+fy3j1N1dF9dQs
ZhNzHaFvImPvJtqOq1j2JnoOo3YxtU9/fv3824hLhL9pb9cn8zHt/gRifxtJ3tpwMmKJP0SVvd08
owixDCtl+IEQFaILRDhKtcZuIsIGG5vTPBfKFSipR576nE78IeoxOgmY+hwgb6hFAsrZ9vcSBDLE
8IQY2Xas274QbeC496U4tn/P5KZoEhJAcAlm/PM/Xowrqy1KP46sQc4CKPms1mZSWngXwbWz/pvo
bwAmV4KzGDpaxUxbHgvDZKwoSi3KE4QojZ7CYICJYBrBaHG71eCM3i+K1XXUBPzN31pl9B7fy/Yv
oHv75oFuuYVEWHFsNGmfHkw2rmpvVp9ubVE5KPCBaZxI57ruH09mt1P3FPwaTLAy2TxU+j4uwBAh
AWUSJ8Q9XEJz1awrRziBeeLBh9Rt2Ma4nIU2iyeVwZSsUj7CuHVqOZUutgbpLPTtw/btR6ujg9PQ
fz97/eLVd+OXr39+9urlCzcNvX3z970l/9f/evWqbX45hwAnm4DOamkXgq0eWjatT9IRZhvb7BtD
ngudL3o7C7Z7T/0QpEA6sUgkKc/w1wFycDDcNAQMEa7zUijZPa9kSAjYiIxxijsosYDYOG0X07s0
uH815kPpcpYSYjOjIdX40/jyU+jiUX35qQU4qb88m6VdCLbz+fJzoDuVm+yNrcNNmswQipGWGJuv
A+Sl+nL/xV0s7Zt7ZEJSlqaKW3ZxuYf/shUmOuMaq4TCVFCCEf+TzFen0cUjzlenF+CEc8IZLe1C
sJ1rvjoPutNMBQOwdUwFKU2oMVoQg/XXAfJi5yt/iiU645osMTCZ0Fzn5M/jy0+hi0f15acW4KT+
8myWdiHYzufLz4HuVG6yN7YON8m1KyrEacox/TpAXqQvJ/jAfTuEfr5/exqYTRZmoqMChrlZgxNy
q4652/aS7qQgWcr4bun2Ru+/Au5sam15YMN6vppMozmIuqmQe4oxGiEiKEKAWS+ArLm5dxkQCU27
ITIxQl5j4ahvBpcmmqmEpkiZy8rgQEbsrTDjuDM6FIZkVovEECH+DLP+yXTxWLP+WQQ41cx6Xku7
EGxnmfXPhu4EE+owbF3JEdEGCwUg7Vlm/dODvMhZvxTTN6Vy3L0yzXmilLVada2nfoW+/BS6eFRf
fmoBTuovz2ZpF4LtfL78HOhO5SZ7Y+twk3kqhKRGp1lqvw6QF+jLU/h8JL0XOZ0gPXpmyvcq8/W8
9M3RqwV8ZVXWQi4i8E5r+231PtoNZHIjVP58Gzn3f/PjpsWnuyf1/OnLyOBN8aQ7UBdz3pXiyS8C
8ccm2XsLLDOrVo8CqN7vPoBNU0i6bSHpNIYvI5jHGPjGFnCHLVB0jfAo5cRTbsz7l9ZmSqZG8ITY
NPWXG1PDspQhqhnSmEnEtSYslYnWwhhX8tooNx6PIdNH4/Hd7Hb5RcqOt7rxR9DH6GZg2fEWkG93
nR9ZdmyTPDGcuLfN2i582ReiAQ6jUeI974aTpLe2DCKUQ+fkRPgtKUXQRYLkNDUmZZYilVgjsMkz
JA1EDk1L+lLWU+rDd/DNcfoYbj0lIN+WHicDjnRusZ4ktVImiSKMth2lti9EExw+cN40eMpNk+Ol
vVPTiSnfvho7h+7et04TRiVOGEq2RUa7r7lzFKbT3YvLG0bF9o3m0hzKBcQgXKeemt7sA9+Cnn6K
9963BsXeC3GCuOULCeqLWwhAY4glSfdchcmIpb4jSyjk3Pl0XbyPft2NhcIFdyOT/fb5szsv1R0q
9Vv0vfuWQ+JOwsxUUUZ/zkZcxn5ndyer/uXJI/048VYLwBErraGrnWc4dRvOEhLGnlQ2gR7+ixFO
EHsCeQdOGbhZlDxBGMYvfxKhUwNp+1k7a46iJ+5FI9/3Dj3/Sn8eGD+m1zSFuZ//32/RCxTtfj44
X1z+Vu2iRM8R+45+n4roLz0ZbAZgOIN7BG7I27kpOTD0IgBCMId7DPp27ai/R88xGt5+D+rE03a1
JXVVvF+vzOLDvFKlfP68N6sdkKNZNVF9KpZ/bPh811+6JqT+fEbkno9ezGYTx6aDIG00vJxAlLcz
7KtiXUCMY65KPLF+r+ZzO40Y7cuvZucd/A5Yf5PtvZ5ndrZYfroCn+VOUSgtGOh787mHN4RPSoDP
M7zHZ24/QEfNu/TcJNgJ8J8T18Fmre2Lak8VEq7y5JW+nO5FGMiJejAt7dTC7BzIZ4foOD73eK7K
SBH+/52uXuWN9n4djGo4N+Gc1zOyx+1Ah28IRjsAy9n2tzI86kt2YACLpA4MxpYXmBsCz+gASSqC
dknuZn2JDskh6rB8cogR4mX/sp5y7Aja5SggkLf/huC+J6lPGkfA6uAOSJOW4vP+0jQJdo77Xpqr
pS0jdRO7FCuuPFwkCU568jyAWiBHkPRH3SRoQ30LSW3CUt6Xxc5L7AS/1SA8/AXO5pfeWHYOYgAj
zkpbT3trgTNRJ9jTQuWaquqaK3TlVk6iynvG6Ghu5QEJ0fF8YNjDf1d9KoaObuvhvJymCDHRzfTY
yX0guG1wllu1Wi9tnLn6qsU8wsM599TnVbnmcx7N94XQ2yj3POZeM7P3V7/Y+dvFeqlt/NMPY/jj
O3cW7O1yUrgPovunT3/64ZtIQWLy4CvVp0u3WPDOHQLiDo9fLZWxM7X8vYgW+Y5B9HKuRz0RFnZ1
a5ezog/Cpd92es8UnMl6f3h8blkiiOtuCyx6U4zXAmqPpL0z2kdb9U+8yHPQSovDaGfrkZWTEWJl
rCL2oHscZTuBRzmOICm1Kfu30CTwxOUf3WGNbdFrB6fuuNzLKUUeTA/j6aF8uuLyYDzVSl95IE/c
Yn2HYISR17OC3fSmVupq7e7kAY8QCul0PDtxzmxRqHe2OBXGQH4efPuz5clAhjM9hHQ914vNuXB3
9sSAj+HdiXubbJ4Iah92VT68Fx4dcI1NggPOtyLYB+ydmUoSVifxt8FE6WXxXlrvl6KF4GEgki0W
q3g1mdmr3cn08UzpeHOlS4RQ+f4Audb2OiHXWdazmQOCVJMnJr0F2RLsptuH8cpBQdpClnbG/mm8
BbpPVjqitEyQMO0nayuB35JaSQ7GOOYTxLETHc+AK08ZS9jJOauPwzgfUmQZXeK9dYVDiqzMcm/l
Yva7mSwr7G057hUkMGoOQe9GEpZlKjUqj1WSqhh+yWKlSBYbiYjViTVIkr5N+8zqnmBAPh6EtSWH
d40zVNds96pCcQve1p659U7Rz9b63rrPAavaEuy6tm/27hkMTaYH7KUkODLd5wz4iLr4vlF4T5Ds
bbJ0D6ojequ9bVlv26ele4JHMa3W1tfz7cB6jNZbVnzP4P12/fQIzmyg3Ocx0P22faMJRjuvCPZU
5fM+QJCgOkFQyt7OKSRlP4Spb6p9CNFxfDpTke3ePzA09q4YDuxUDHcI72ZHoDlIjD0tH1iPaCfv
vZzhyEn/num19NDO87jljIE4Dy4/DMQYyO/I5QzHlA4BGc70NMsZYYCP4R28nDEQahi77nFUFVid
CFwQt05sdrlcLE+MsDdPXufpT7MdiRhGIkYcVa3sbXH4JnhHkNQJTr9k09qML1JxBFW6LvoLUilL
nHbJppWxLwvYI+ghK7tGaMQ2SZHsIeuGQNYJ9udzkMX915dybzLvpExHlJZTMemzpLkhIHUCzxb3
XK+gq2JXjCBIUt9y7mLo0ysQyDJyIX3WLzcEuE7g3Yx2btNBj28Xy1V5w4KH6yBnvOPa6lHC0a42
bN2tDCcDu/Jh5deIjjgphzPpswJbEVS7kaTPuid3wFmV2pA+654lQZo2CDwtEDkitDKnPguCGwJc
J+hsQbq3nhAR9R71ESQjyVi9tzwEmIOWGnU4XQQEXzM0EqS58NOzGHvDYLPUtMegS2tbAty91NSv
RVxvcXD5ZzeUvnXg3ViGFpD2UMsALMMrynu035P6mPLXPvocyufICvc+iglgdXxR7pYb6SGjr869
m8+wevl9PscXCXej6llMzwZLGVJM36MTei2c94AXwKfHmvaGgFdz0l7DB/z3hqB3MXYn2SFgsg7s
wFRWLWT1KcbeEpTDsW8xdifRATk2BD3lwCNchRV9irG3BOXAG1aM3Unqk2ZH0F+aKiLpU4zdSXBE
MfaWJ67zPISa1OOoQ6gbBJ3F2JzVbz3tZDGwGLub0cBi7IpRQnsXY28JTlOMHcCttRg7gE9wMfa2
rUYJ6jHF2PtMj50cBoLrWYzdh/OZi7FPCaGHUVbNXGIxdifCo4qxO7n6Z4qkSgz7FGNXBNAtjqBP
RXMnwcFlsm7KQ8tkjpKNWLPIzgeylcCnBiCQ1VJqj4W4ToLBe7jdnIbu4fbB1Gfvdcsn/f/2zi29
URiGwrOh8IWLwXQ3SdPsfwlTYqdNwZKOJPebebDez/Hh5oD8Q5hEPh9onRKIYZPb1ymRSPU8beuU
hoyQX9Tkk5YUaVPHOqU9qbyWaA/s8TatUxqiynbhnNbtgIb/UzDtBfzk+xS8BKaX5LJkgtHuTbAt
+6WrAuiVk4K6a3jkMNKGpMUmoCW/E9RbwyONuZuTT0F6HwChhZNgSg/lCC1MCvgzaZMMe4kbu67g
TGDXpLO0I9MVBgCyT0G6lQhm7Lq/rfF9PF9P5/Pan+L9cj+NH9fL6Ran+SNO2zPBBR2aP62ywEEq
QllLT+vb4Mt+z2qx68qjK9nYCqMD4CMpkC/PjGsoSG32zU/SVjrJMuT53eP1EOOkKZLC25OYuykc
2DNuAtkEj9/b1zdltcS4cUIojs3tpS/BP7kqiqNrifG6oyuJcfdxKp6cvzsPK7e7+gl6+HXlrqal
G4YDuMVNnEWBqdtQdrJ0G6RMaJdASuTzMRLjQLBahgAxjqQRxQszstBKKcvhTswmj/iRgbomZU9f
J0aZU+ycKDMa/ZydGHVIu2mdTowtsMfb3IlRRrXZWYhxyxVkcbMT44aEsOe69+QfQT4l+Wkblqxf
LTgAtCYFGNe7hLWwerkZrntD7p5k7cKcbmIAXpoUuLjen66aS4bneh1paa73aXp4McDH9Q7D23nq
Yv/IilDhT0HYC8iDPb71S9cvB2KdEQxjNx7vABjBODy5coiJfZDD88IwXQKhmgzWdDBeDMi99iKw
MbHUiHomlowCM7FkFjUTK+8WcxYllyrvFY6OlbcDVLuYWHlfaPhMYI+gWKy8gYZgFb5ITVspCVtF
JJuPkYmVc5mYWHm3Ya1BOZ7BB2Fi06sj/QE95efvZUivjuBMLCUTgmXBSzD+pywLICY2C3RMLCWS
tgNnYh+COB++Acxvx1OgY2IpKb81hXDC1qQJD2JiKYGHiaU8odQQE0sJaCZ25EK6mFjSSMvEfhrF
buwf3V2IiaUENiZW71ZmYvU+diZWPxbAxL6Yen8clOFQJhZw/m0mNkeYKkQATso0zH/JxFIJfUws
5cr9UmyCsD8e3Jwbu5A4FYiJpQQyE0sqRSY2bH+4dY6Hb1UyIcsCZjd8Cvoh9b2QNgQl0K9SkU7q
VSogE7S6BCTy+WArMXIMm9yxEgNEqudpXInRZzT6eVZiLCHtphVWYsyBPd62lRh9VMQuNU8QJjYL
5r1AmnwPLD+z6JAk0wH85seY8S/4PgXDXlCZiaWGkTYkCRAmNgsSLVKTiaWMmZuTVwG6rTGvOSBM
LCWQzqSCxM/E+p0pJpZylnZk5kzxHZlhSzMTe7lO4b6E/nS7D+spTiGcrvN8O12WKXx83O7vfaAO
yGFo/rSK6StXDhYLylp4Wv8e3MPEVh5dSf9VGB1hYimBfHnWZmIpW+kkq8vEUqZICmdPoh+6uBwO
BDeBfAk8TKxxQiiOze2l7637F1dFcXQtE1t3dCUT6z5OxZPzd+dh5Xb/zgkKMbHbN/66sT8QBtzE
WRSYug1lJ0u3QcqEdgmkRD4fKxMrB6tliDCxQBqDGO7ESGOb5L5OjPLgwJ7VmFjSz96JUedDmibq
kHbTOp0YW2CPt7kTo4xqszMxsfpwJjcHE6tPCHtqmNgkGTRM7Pbtzi7md84QJpYSoExsXEFD7p4k
dGsiJiAmlhL4mNgfrhWZ2Ow76NMyTOwP03pMbNj+lWNOgDTExGbBuheQB3t5Ow/dNCaIFunpUoKX
Ef60atWqVatWrVq1atWqVatWrVq1atWqVatWrVq1alWp/gK6CST0APgMAA==
--f46d04430662c40d6304b92b55c3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--f46d04430662c40d6304b92b55c3--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:24:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQb8-0004t0-5b; Fri, 17 Feb 2012 16:23:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyQb6-0004sn-4T
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 16:23:48 +0000
Received: from [85.158.139.83:31005] by server-11.bemta-5.messagelabs.com id
	25/8D-14397-31F7E3F4; Fri, 17 Feb 2012 16:23:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329495825!15534398!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8179 invoked from network); 17 Feb 2012 16:23:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 16:23:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyQb2-000FeE-LN; Fri, 17 Feb 2012 16:23:44 +0000
Date: Fri, 17 Feb 2012 16:23:44 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120217162344.GA59026@ocelot.phlegethon.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
In-Reply-To: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
	pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Hi, 

At 15:50 +0000 on 17 Feb (1329493838), Jan Beulich wrote:
> this c/s or-s PFEC_reserved_bit into the error code passed to the guest
> in two places, and I'm afraid it is responsible for problems we're seeing
> when a Linux HVM PAE guest on a non-HAP platform runs into
> invocations of pgtable_bad(). Linux check the reserved bit before
> looking at the present bit, and expects the reserved bit to always be
> clear when the present bit also is. The respective lines from the
> guest's kernel log however are
> 
> Bad pagetable: 000c [#1] SMP
> Bad pagetable: 000e [#2] SMP
> Bad pagetable: 000e [#3] SMP
> Bad pagetable: 000c [#4] SMP
> Bad pagetable: 000c [#5] SMP
> Bad pagetable: 000c [#6] SMP
> Bad pagetable: 000a [#7] SMP
> Bad pagetable: 000a [#8] SMP
> Bad pagetable: 000c [#10] SMP
> Bad pagetable: 000c [#11] SMP
> 
> (i.e. reserved flag always set, present flag always clear) with the
> corresponding page table dumps being
> 
> *pdpt = 0000000035682001 *pde = 0000000013014067 *pte = 002dea0000000000
> *pdpt = 0000000035d65001 *pde = 0000000028a8a067 *pte = 002dd16000000000
> *pdpt = 0000000013177001 *pde = 0000000028bf9067 *pte = 002dd16000000000
> *pdpt = 0000000035480001 *pde = 000000005e6b1067
> *pdpt = 00000000133b6001 *pde = 000000005e6c1067
> *pdpt = 00000000131b7001 *pde = 000000005de15067
> *pdpt = 00000000354bd001 *pde = 00000000355ad067 *pte = 002dfca000000000
> *pdpt = 000000002bd5c001 *pde = 000000002bf2c067 *pte = 002dfa6000000000
> *pdpt = 000000002bd79001 *pde = 0000000000000000
> *pdpt = 000000002bdc6001 *pde = 000000005e63c067
> *pdpt = 00000000130ef001 *pde = 000000005e690067
> 
> (i.e. no invalid bits at all, but paged out entries with page indexes
> into the swap file indicating a swap size of over 10G - with anything
> up to 4G, the reserved bits would never be run into).

Right - so the problem is that the walker is choking on the reserved
bits even though the present bit it clear in that particular PTE?
Yeah, that's a bug.

> The problem appears to be that the or-ing in of PFEC_reserved_bit
> happens without consideration of PFEC_present. If you can confirm
> I'm not mis-interpreting things, fixing this should be relatively
> strait forward (though the question would be whether it should be
> guest_walk_tables() or its callers that should be fixed).

We should fix it in guest_walk_tables, since AFAICS it's possible for
PFEC_reserved_bit to be set based on a bad higher-level entry even if a
lower-level one has _PAGE_PRESENT clear.

Something like the attached (compile-tested only) patch? 

(Sigh; this PT walker was once relatively readable and efficient.)

Cheers,

Tim.

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=pfec

# HG changeset patch
# Parent 87218bd367befca7d3488ba1cf4feb2b10d5f14e
x86/mm: Don't check for invalid bits in non-present PTEs.

If _PAGE_PRESENT is clean in a pagetable entry, any pattern of bits
is valid in the rest of the entry.  OSes that special-case
PFEC_invalid_bits (since it should never happen) will be confused 
by our setting it in this way.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 87218bd367be -r 05a3b346f1c3 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Fri Feb 17 12:24:38 2012 +0000
+++ b/xen/arch/x86/mm/guest_walk.c	Fri Feb 17 16:14:19 2012 +0000
@@ -179,8 +179,11 @@ guest_walk_tables(struct vcpu *v, struct
     l4p = (guest_l4e_t *) top_map;
     gw->l4e = l4p[guest_l4_table_offset(va)];
     gflags = guest_l4e_get_flags(gw->l4e) ^ iflags;
+    if ( !(gflags & _PAGE_PRESENT) ) {
+        rc |= _PAGE_PRESENT;
+        goto out;
+    }
     rc |= ((gflags & mflags) ^ mflags);
-    if ( rc & _PAGE_PRESENT ) goto out;
 
     /* Map the l3 table */
     l3p = map_domain_gfn(p2m, 
@@ -193,9 +196,11 @@ guest_walk_tables(struct vcpu *v, struct
     /* Get the l3e and check its flags*/
     gw->l3e = l3p[guest_l3_table_offset(va)];
     gflags = guest_l3e_get_flags(gw->l3e) ^ iflags;
+    if ( !(gflags & _PAGE_PRESENT) ) {
+        rc |= _PAGE_PRESENT;
+        goto out;
+    }
     rc |= ((gflags & mflags) ^ mflags);
-    if ( rc & _PAGE_PRESENT )
-        goto out;
     
     pse1G = (gflags & _PAGE_PSE) && guest_supports_1G_superpages(v); 
 
@@ -261,9 +266,11 @@ guest_walk_tables(struct vcpu *v, struct
 #endif /* All levels... */
 
     gflags = guest_l2e_get_flags(gw->l2e) ^ iflags;
+    if ( !(gflags & _PAGE_PRESENT) ) {
+        rc |= _PAGE_PRESENT;
+        goto out;
+    }
     rc |= ((gflags & mflags) ^ mflags);
-    if ( rc & _PAGE_PRESENT )
-        goto out;
 
     pse2M = (gflags & _PAGE_PSE) && guest_supports_superpages(v); 
 
@@ -321,6 +328,10 @@ guest_walk_tables(struct vcpu *v, struct
             goto out;
         gw->l1e = l1p[guest_l1_table_offset(va)];
         gflags = guest_l1e_get_flags(gw->l1e) ^ iflags;
+        if ( !(gflags & _PAGE_PRESENT) ) {
+            rc |= _PAGE_PRESENT;
+            goto out;
+        }
         rc |= ((gflags & mflags) ^ mflags);
     }
 

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--4Ckj6UjgE2iN1+kY--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:24:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQb8-0004t0-5b; Fri, 17 Feb 2012 16:23:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyQb6-0004sn-4T
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 16:23:48 +0000
Received: from [85.158.139.83:31005] by server-11.bemta-5.messagelabs.com id
	25/8D-14397-31F7E3F4; Fri, 17 Feb 2012 16:23:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329495825!15534398!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8179 invoked from network); 17 Feb 2012 16:23:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 16:23:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyQb2-000FeE-LN; Fri, 17 Feb 2012 16:23:44 +0000
Date: Fri, 17 Feb 2012 16:23:44 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120217162344.GA59026@ocelot.phlegethon.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
In-Reply-To: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
	pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Hi, 

At 15:50 +0000 on 17 Feb (1329493838), Jan Beulich wrote:
> this c/s or-s PFEC_reserved_bit into the error code passed to the guest
> in two places, and I'm afraid it is responsible for problems we're seeing
> when a Linux HVM PAE guest on a non-HAP platform runs into
> invocations of pgtable_bad(). Linux check the reserved bit before
> looking at the present bit, and expects the reserved bit to always be
> clear when the present bit also is. The respective lines from the
> guest's kernel log however are
> 
> Bad pagetable: 000c [#1] SMP
> Bad pagetable: 000e [#2] SMP
> Bad pagetable: 000e [#3] SMP
> Bad pagetable: 000c [#4] SMP
> Bad pagetable: 000c [#5] SMP
> Bad pagetable: 000c [#6] SMP
> Bad pagetable: 000a [#7] SMP
> Bad pagetable: 000a [#8] SMP
> Bad pagetable: 000c [#10] SMP
> Bad pagetable: 000c [#11] SMP
> 
> (i.e. reserved flag always set, present flag always clear) with the
> corresponding page table dumps being
> 
> *pdpt = 0000000035682001 *pde = 0000000013014067 *pte = 002dea0000000000
> *pdpt = 0000000035d65001 *pde = 0000000028a8a067 *pte = 002dd16000000000
> *pdpt = 0000000013177001 *pde = 0000000028bf9067 *pte = 002dd16000000000
> *pdpt = 0000000035480001 *pde = 000000005e6b1067
> *pdpt = 00000000133b6001 *pde = 000000005e6c1067
> *pdpt = 00000000131b7001 *pde = 000000005de15067
> *pdpt = 00000000354bd001 *pde = 00000000355ad067 *pte = 002dfca000000000
> *pdpt = 000000002bd5c001 *pde = 000000002bf2c067 *pte = 002dfa6000000000
> *pdpt = 000000002bd79001 *pde = 0000000000000000
> *pdpt = 000000002bdc6001 *pde = 000000005e63c067
> *pdpt = 00000000130ef001 *pde = 000000005e690067
> 
> (i.e. no invalid bits at all, but paged out entries with page indexes
> into the swap file indicating a swap size of over 10G - with anything
> up to 4G, the reserved bits would never be run into).

Right - so the problem is that the walker is choking on the reserved
bits even though the present bit it clear in that particular PTE?
Yeah, that's a bug.

> The problem appears to be that the or-ing in of PFEC_reserved_bit
> happens without consideration of PFEC_present. If you can confirm
> I'm not mis-interpreting things, fixing this should be relatively
> strait forward (though the question would be whether it should be
> guest_walk_tables() or its callers that should be fixed).

We should fix it in guest_walk_tables, since AFAICS it's possible for
PFEC_reserved_bit to be set based on a bad higher-level entry even if a
lower-level one has _PAGE_PRESENT clear.

Something like the attached (compile-tested only) patch? 

(Sigh; this PT walker was once relatively readable and efficient.)

Cheers,

Tim.

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=pfec

# HG changeset patch
# Parent 87218bd367befca7d3488ba1cf4feb2b10d5f14e
x86/mm: Don't check for invalid bits in non-present PTEs.

If _PAGE_PRESENT is clean in a pagetable entry, any pattern of bits
is valid in the rest of the entry.  OSes that special-case
PFEC_invalid_bits (since it should never happen) will be confused 
by our setting it in this way.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 87218bd367be -r 05a3b346f1c3 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Fri Feb 17 12:24:38 2012 +0000
+++ b/xen/arch/x86/mm/guest_walk.c	Fri Feb 17 16:14:19 2012 +0000
@@ -179,8 +179,11 @@ guest_walk_tables(struct vcpu *v, struct
     l4p = (guest_l4e_t *) top_map;
     gw->l4e = l4p[guest_l4_table_offset(va)];
     gflags = guest_l4e_get_flags(gw->l4e) ^ iflags;
+    if ( !(gflags & _PAGE_PRESENT) ) {
+        rc |= _PAGE_PRESENT;
+        goto out;
+    }
     rc |= ((gflags & mflags) ^ mflags);
-    if ( rc & _PAGE_PRESENT ) goto out;
 
     /* Map the l3 table */
     l3p = map_domain_gfn(p2m, 
@@ -193,9 +196,11 @@ guest_walk_tables(struct vcpu *v, struct
     /* Get the l3e and check its flags*/
     gw->l3e = l3p[guest_l3_table_offset(va)];
     gflags = guest_l3e_get_flags(gw->l3e) ^ iflags;
+    if ( !(gflags & _PAGE_PRESENT) ) {
+        rc |= _PAGE_PRESENT;
+        goto out;
+    }
     rc |= ((gflags & mflags) ^ mflags);
-    if ( rc & _PAGE_PRESENT )
-        goto out;
     
     pse1G = (gflags & _PAGE_PSE) && guest_supports_1G_superpages(v); 
 
@@ -261,9 +266,11 @@ guest_walk_tables(struct vcpu *v, struct
 #endif /* All levels... */
 
     gflags = guest_l2e_get_flags(gw->l2e) ^ iflags;
+    if ( !(gflags & _PAGE_PRESENT) ) {
+        rc |= _PAGE_PRESENT;
+        goto out;
+    }
     rc |= ((gflags & mflags) ^ mflags);
-    if ( rc & _PAGE_PRESENT )
-        goto out;
 
     pse2M = (gflags & _PAGE_PSE) && guest_supports_superpages(v); 
 
@@ -321,6 +328,10 @@ guest_walk_tables(struct vcpu *v, struct
             goto out;
         gw->l1e = l1p[guest_l1_table_offset(va)];
         gflags = guest_l1e_get_flags(gw->l1e) ^ iflags;
+        if ( !(gflags & _PAGE_PRESENT) ) {
+            rc |= _PAGE_PRESENT;
+            goto out;
+        }
         rc |= ((gflags & mflags) ^ mflags);
     }
 

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--4Ckj6UjgE2iN1+kY--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:28:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQfV-00057f-UD; Fri, 17 Feb 2012 16:28:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyQfU-00057Y-E3
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:28:20 +0000
Received: from [85.158.139.83:39303] by server-9.bemta-5.messagelabs.com id
	5B/AE-30171-3208E3F4; Fri, 17 Feb 2012 16:28:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329496098!14982186!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTg5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11758 invoked from network); 17 Feb 2012 16:28:18 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.66) by server-13.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 16:28:18 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 8BC02380065;
	Fri, 17 Feb 2012 08:28:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=B66QxyZxJLN4a36H7iRSoa71ioW7ggaj3oLqQ8aql0Ga
	GoaAaSobMZu5sZt5oQKMxtfwr65D/R0nrnelg5TMeQvnYdHw5O+r24udzXD7Wtrv
	9ENjlFjDDepZebkKUmYG4x897IklKxBjMdrZTk74WPZVrv3U4rxNYllQqw2XRcE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5fFVaOucxSVgsy+9epNe8+SDCiM=; b=ggz4wHo1
	1BsTbw7DMGV188YuBixWZXfAGllEz1J+DsV4qpIcSGUrSznWt8sRe4+OvDitQgat
	1svZT/1s5uFurGIfA2/8EgZQkTEhFxX6igznnHQ68wSqTTm08T3dE7b/j0fNByFm
	BaVxmWVfj2FDmitvTaOjFR2B9CPbNmugN4o=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 26C3138005F; 
	Fri, 17 Feb 2012 08:28:17 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:28:17 -0800
Message-ID: <91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 08:28:17 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Fri, 17 Feb 2012 12:06:05 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Qrux <qrux.qed@gmail.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
> Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I'm afraid I don't know the answer to most of your questions (hence I'm
> afraid I've trimmed the quotes rather aggressively) but here's some of
> what I do know.

I'm gonna add another data point.

We're seeing the Windows 7 Query Performance Counter get mightily
confused. People have reported this in Amazon EC2 as well
https://forums.aws.amazon.com/thread.jspa?threadID=41426

We've tracked it down to the hpet. Xen schedules an interrupt delivery for
an hpet tick, but the vcpu is asleep. Could be an admin pause, a sleep on
a wait queue, paused while qemu does its thing, paused while a mem event
is processed...

When the vcpu wakes up it receives the "late" hpet tick. We believe
Windows 7 QPC also reads the TSC at that point. The TSC kept on ticking
while the vcpu was paused. Windows does not know what to do about the
discrepancy and reports a large time leap, usually consistent with a full
round trip of the 32 bit hpet counter at the Xen-emulated 1/16GHz
frequency.

MSDN forums blame "bad hardware" for this. Funny.

So, we could solve our particular problem if the tsc were not to tick
during vcpu sleep. And I get an inkling that would help with this post as
well. But I don't think any of the advertised timer or tsc modes do that.

Thanks,
Andres



I'm not sure this will help with the original post, but there's gotta be
somebody who
>
>> But, practically, is there a safe CPU configuration?
>
> I think that part of the problem here is that it is very hard to
> determine this at the hardware level. There are at least 3 (if not more)
> CPUID feature bits which say "no really, the TSC is good and safe to use
> this time, you can rely on that" because they keep inventing new ways to
> get it wrong.
>
> [...]
>>
>> Since September, I can't find any further information about this
>> issue. What is the state of this issue?  The inconsistency I see right
>> now is this: in the July 2010 TSC discussion, a "Stefano Stabellini"
>> posted this:
>>
>> ====
>> > /me wonders if timer_mode=1 is the default for xl?
>> > Or only for xm?
>>
>> no, it is not.
>> Xl defaults to 0 [zero], I am going to change it right now.
>> ====
>>
>> So, it seems like (at least as of July 2010), xl is defaulting to
>> "timer_mode=1".  That is, assuming that the then-current timer_mode is
>> the same as present-day tsc_mode.
>
> No, I believe they are different things.
>
> tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
> xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)
>
> timer_mode is to do with the the way that timer interrupts are injected
> into the guest. This is described in xen/include/public/hvm/params.h.
> This isn't documented in xl.cfg(5) because I couldn't make head nor tail
> of the meaning of that header :-(
>
>>   In addition, I'm assuming he was changing it from 0 (zero) to 1
>> (one)--and not some other mode.  But,
>>
>>         xen-4.1.2/docs/misc/tscmode.txt
>
> Remember that he was referring to timer_mode not tsc_mode...
>
>> says:
>>
>>         "The default mode (tsc_mode==0) checks TSC-safeness of the
>> underlying
>>         hardware on which the virtual machine is launched.  If it is
>>         TSC-safe, rdtsc will execute at hardware speed; if it is not,
>> rdtsc
>>         will be emulated."
>>
>> Which implies the default is always 0 (zero).  Which is it?
>
> It seems that xl, in xen-unstable, defaults to:
> 	timer_mode = 1
> 	tsc_mode = 0
> as does 4.1 as far as I can tell via code inspection.
>
>> More importantly, is the solution to force tsc_mode=2?
>
> IMHO this is safe in most situations unless you are running some sort of
> workload (e.g. a well known database) which has stringent requirements
> regarding the TSC for transactional consistency (hence the conservative
> default).
>
>>   If so, under what BIOS/xen-boot-params/dom0-boot-params conditions?
>> And--please excuse my exasperation--but WTH does this have to do with
>> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
>> "jumpiness" (if that's even what's happening)?
>
> Sorry, I have no idea how/why the filesystem would be related to the
> TSC.
>
> It is possible you are actually seeing two bugs I suppose -- there have
> been issues relating to ext4 and barriers in some kernel versions (I'm
> afraid I don't recall the details, the list archives ought to contain
> something).
>
> Ian.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:28:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQfV-00057f-UD; Fri, 17 Feb 2012 16:28:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyQfU-00057Y-E3
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:28:20 +0000
Received: from [85.158.139.83:39303] by server-9.bemta-5.messagelabs.com id
	5B/AE-30171-3208E3F4; Fri, 17 Feb 2012 16:28:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329496098!14982186!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMTg5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11758 invoked from network); 17 Feb 2012 16:28:18 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.66) by server-13.tower-182.messagelabs.com with SMTP;
	17 Feb 2012 16:28:18 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 8BC02380065;
	Fri, 17 Feb 2012 08:28:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=B66QxyZxJLN4a36H7iRSoa71ioW7ggaj3oLqQ8aql0Ga
	GoaAaSobMZu5sZt5oQKMxtfwr65D/R0nrnelg5TMeQvnYdHw5O+r24udzXD7Wtrv
	9ENjlFjDDepZebkKUmYG4x897IklKxBjMdrZTk74WPZVrv3U4rxNYllQqw2XRcE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=5fFVaOucxSVgsy+9epNe8+SDCiM=; b=ggz4wHo1
	1BsTbw7DMGV188YuBixWZXfAGllEz1J+DsV4qpIcSGUrSznWt8sRe4+OvDitQgat
	1svZT/1s5uFurGIfA2/8EgZQkTEhFxX6igznnHQ68wSqTTm08T3dE7b/j0fNByFm
	BaVxmWVfj2FDmitvTaOjFR2B9CPbNmugN4o=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 26C3138005F; 
	Fri, 17 Feb 2012 08:28:17 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:28:17 -0800
Message-ID: <91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 08:28:17 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Fri, 17 Feb 2012 12:06:05 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Qrux <qrux.qed@gmail.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
> Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I'm afraid I don't know the answer to most of your questions (hence I'm
> afraid I've trimmed the quotes rather aggressively) but here's some of
> what I do know.

I'm gonna add another data point.

We're seeing the Windows 7 Query Performance Counter get mightily
confused. People have reported this in Amazon EC2 as well
https://forums.aws.amazon.com/thread.jspa?threadID=41426

We've tracked it down to the hpet. Xen schedules an interrupt delivery for
an hpet tick, but the vcpu is asleep. Could be an admin pause, a sleep on
a wait queue, paused while qemu does its thing, paused while a mem event
is processed...

When the vcpu wakes up it receives the "late" hpet tick. We believe
Windows 7 QPC also reads the TSC at that point. The TSC kept on ticking
while the vcpu was paused. Windows does not know what to do about the
discrepancy and reports a large time leap, usually consistent with a full
round trip of the 32 bit hpet counter at the Xen-emulated 1/16GHz
frequency.

MSDN forums blame "bad hardware" for this. Funny.

So, we could solve our particular problem if the tsc were not to tick
during vcpu sleep. And I get an inkling that would help with this post as
well. But I don't think any of the advertised timer or tsc modes do that.

Thanks,
Andres



I'm not sure this will help with the original post, but there's gotta be
somebody who
>
>> But, practically, is there a safe CPU configuration?
>
> I think that part of the problem here is that it is very hard to
> determine this at the hardware level. There are at least 3 (if not more)
> CPUID feature bits which say "no really, the TSC is good and safe to use
> this time, you can rely on that" because they keep inventing new ways to
> get it wrong.
>
> [...]
>>
>> Since September, I can't find any further information about this
>> issue. What is the state of this issue?  The inconsistency I see right
>> now is this: in the July 2010 TSC discussion, a "Stefano Stabellini"
>> posted this:
>>
>> ====
>> > /me wonders if timer_mode=1 is the default for xl?
>> > Or only for xm?
>>
>> no, it is not.
>> Xl defaults to 0 [zero], I am going to change it right now.
>> ====
>>
>> So, it seems like (at least as of July 2010), xl is defaulting to
>> "timer_mode=1".  That is, assuming that the then-current timer_mode is
>> the same as present-day tsc_mode.
>
> No, I believe they are different things.
>
> tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
> xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)
>
> timer_mode is to do with the the way that timer interrupts are injected
> into the guest. This is described in xen/include/public/hvm/params.h.
> This isn't documented in xl.cfg(5) because I couldn't make head nor tail
> of the meaning of that header :-(
>
>>   In addition, I'm assuming he was changing it from 0 (zero) to 1
>> (one)--and not some other mode.  But,
>>
>>         xen-4.1.2/docs/misc/tscmode.txt
>
> Remember that he was referring to timer_mode not tsc_mode...
>
>> says:
>>
>>         "The default mode (tsc_mode==0) checks TSC-safeness of the
>> underlying
>>         hardware on which the virtual machine is launched.  If it is
>>         TSC-safe, rdtsc will execute at hardware speed; if it is not,
>> rdtsc
>>         will be emulated."
>>
>> Which implies the default is always 0 (zero).  Which is it?
>
> It seems that xl, in xen-unstable, defaults to:
> 	timer_mode = 1
> 	tsc_mode = 0
> as does 4.1 as far as I can tell via code inspection.
>
>> More importantly, is the solution to force tsc_mode=2?
>
> IMHO this is safe in most situations unless you are running some sort of
> workload (e.g. a well known database) which has stringent requirements
> regarding the TSC for transactional consistency (hence the conservative
> default).
>
>>   If so, under what BIOS/xen-boot-params/dom0-boot-params conditions?
>> And--please excuse my exasperation--but WTH does this have to do with
>> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
>> "jumpiness" (if that's even what's happening)?
>
> Sorry, I have no idea how/why the filesystem would be related to the
> TSC.
>
> It is possible you are actually seeing two bugs I suppose -- there have
> been issues relating to ext4 and barriers in some kernel versions (I'm
> afraid I don't recall the details, the list archives ought to contain
> something).
>
> Ian.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:33:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQk6-0005HH-LY; Fri, 17 Feb 2012 16:33:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyQk5-0005H4-0c
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:33:05 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329496352!12334154!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjc2NDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6879 invoked from network); 17 Feb 2012 16:32:32 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-16.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 16:32:32 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1HGVfN6012432;
	Fri, 17 Feb 2012 11:31:41 -0500
Date: Fri, 17 Feb 2012 11:31:41 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20135806-592a-42bb-876a-d9d1e879c358@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120217152004.GB30298@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.11.9.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, jeremy@goop.org,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, Feb 17, 2012 at 07:50:11AM -0500, Andrew Jones wrote:
> > 
> > 
> > ----- Original Message -----
> > > On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > > > We just reported to xenbus that we can't close yet, because
> > > > blkfront is still in use. So we shouldn't then immediately
> > > > state that we are closing.
> > > 
> > > What happens if the user uses --force to unplug the device?
> > > Will that still work?
> > 
> > With RHEL5 tooling I get the same results. That is, the device
> > is forcibly detached, and then any task in the guest that still
> > attempts to use (or even just unmount) the device hangs.
> > 
> > I don't know anything about xl, but afaict block-detach
> > doesn't take a 'force' option?
> 
> konrad@phenom:~/ssd/linux$ xm block-detach
> xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp
> Error: 'xm block-detach' requires between 2 and 3 arguments.
> 
> Usage: xm block-detach <Domain> <DevId> [-f|--force]
> 
> Destroy a domain's virtual block device.

That's 'xm', not 'xl'. I tested RHEL5's 'xm' with the force option
and, as I said above, I got the same results before and after this
patch. I believe the problem (the non-force case) may exist with
latest 'xm' too (not just RHEL5's), but I didn't really check, since
I know 'xl' is the tool that truly matters for upstream now. As I
said before, the problem shouldn't exist with 'xl' though, since it
bails on state != 4, and afaict it doesn't have a force option.
Anyway, I don't think this patch would break that path even if it
did.

I'm actually going to send a v2 of this patch in a few minutes. I'm
just finishing it up now.

Drew

> 
> 
> > 
> > Drew
> > 
> > > > 
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > >  drivers/block/xen-blkfront.c |    1 -
> > > >  1 files changed, 0 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/block/xen-blkfront.c
> > > > b/drivers/block/xen-blkfront.c
> > > > index 5d45688..b53cae4 100644
> > > > --- a/drivers/block/xen-blkfront.c
> > > > +++ b/drivers/block/xen-blkfront.c
> > > > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info
> > > > *info)
> > > >  	if (bdev->bd_openers) {
> > > >  		xenbus_dev_error(xbdev, -EBUSY,
> > > >  				 "Device in use; refusing to close");
> > > > -		xenbus_switch_state(xbdev, XenbusStateClosing);
> > > >  	} else {
> > > >  		xlvbd_release_gendisk(info);
> > > >  		xenbus_frontend_closed(xbdev);
> > > > --
> > > > 1.7.7.5
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:33:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:33:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQk6-0005HH-LY; Fri, 17 Feb 2012 16:33:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyQk5-0005H4-0c
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:33:05 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329496352!12334154!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjc2NDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6879 invoked from network); 17 Feb 2012 16:32:32 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-16.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 16:32:32 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1HGVfN6012432;
	Fri, 17 Feb 2012 11:31:41 -0500
Date: Fri, 17 Feb 2012 11:31:41 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20135806-592a-42bb-876a-d9d1e879c358@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120217152004.GB30298@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.11.9.132]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, jeremy@goop.org,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, Feb 17, 2012 at 07:50:11AM -0500, Andrew Jones wrote:
> > 
> > 
> > ----- Original Message -----
> > > On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > > > We just reported to xenbus that we can't close yet, because
> > > > blkfront is still in use. So we shouldn't then immediately
> > > > state that we are closing.
> > > 
> > > What happens if the user uses --force to unplug the device?
> > > Will that still work?
> > 
> > With RHEL5 tooling I get the same results. That is, the device
> > is forcibly detached, and then any task in the guest that still
> > attempts to use (or even just unmount) the device hangs.
> > 
> > I don't know anything about xl, but afaict block-detach
> > doesn't take a 'force' option?
> 
> konrad@phenom:~/ssd/linux$ xm block-detach
> xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp
> Error: 'xm block-detach' requires between 2 and 3 arguments.
> 
> Usage: xm block-detach <Domain> <DevId> [-f|--force]
> 
> Destroy a domain's virtual block device.

That's 'xm', not 'xl'. I tested RHEL5's 'xm' with the force option
and, as I said above, I got the same results before and after this
patch. I believe the problem (the non-force case) may exist with
latest 'xm' too (not just RHEL5's), but I didn't really check, since
I know 'xl' is the tool that truly matters for upstream now. As I
said before, the problem shouldn't exist with 'xl' though, since it
bails on state != 4, and afaict it doesn't have a force option.
Anyway, I don't think this patch would break that path even if it
did.

I'm actually going to send a v2 of this patch in a few minutes. I'm
just finishing it up now.

Drew

> 
> 
> > 
> > Drew
> > 
> > > > 
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > >  drivers/block/xen-blkfront.c |    1 -
> > > >  1 files changed, 0 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/block/xen-blkfront.c
> > > > b/drivers/block/xen-blkfront.c
> > > > index 5d45688..b53cae4 100644
> > > > --- a/drivers/block/xen-blkfront.c
> > > > +++ b/drivers/block/xen-blkfront.c
> > > > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info
> > > > *info)
> > > >  	if (bdev->bd_openers) {
> > > >  		xenbus_dev_error(xbdev, -EBUSY,
> > > >  				 "Device in use; refusing to close");
> > > > -		xenbus_switch_state(xbdev, XenbusStateClosing);
> > > >  	} else {
> > > >  		xlvbd_release_gendisk(info);
> > > >  		xenbus_frontend_closed(xbdev);
> > > > --
> > > > 1.7.7.5
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQpy-0005So-Gr; Fri, 17 Feb 2012 16:39:10 +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 1RyQpw-0005Sd-Iq
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:39:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329496692!49735456!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18266 invoked from network); 17 Feb 2012 16:38:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 16:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325480400"; d="scan'208";a="182418049"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 11:39:05 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	11:39:05 -0500
Message-ID: <4F3E82A8.4060204@citrix.com>
Date: Fri, 17 Feb 2012 16:39:04 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Paul S <pstroud@gmail.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
In-Reply-To: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/12 16:21, Paul S wrote:
> Environment:
> ASRock Z86 Extreme4 - Intel i5 2500
> http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
>
> I have installed the latest UEFI patch(1.70) and all tests were run
> from a reset of everything to default. I have tested with both Ubuntu
> 11.10 and Fedora 16 and get the same results on both, including
> building xen 4.2-unstable. I bought this particular MB because it had
> a know working vt-d implementation via VMWare.
>
> NOTE: current unstable as of last night is still affected by this
> library error http://www.gossamer-threads.com/lists/xen/devel/234300
>
> However, after correcting the library error, I was able to complete
> the unstable build.
>
> In both cases, it either stops with a panic/blank screen, or just reboots.
>
> Here are some other notes:
>
> 1) If x2apic is enabled on the motherboard, it almost immediately
> reboots with any of the configurations above

There are some fairly strict set of requirements on what which MSRs you
can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
early in boot which results in a protection fault.

>
> 2) The boot gets to here:
>
> (XEN) HVM: VMX enabled
>
> (XEN) HVM: Hardware Assisted Paging detected.
>
>
> Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
> where it hangs with the blank/panic screen or reboots. This sometimes
> shows up on CPU 1, CPU2, or both.
>
>
> 3) There is no boot log written and the machine does not have a native
> serial port, so capturing anything may prove difficult, but I am open
> to suggestions.
>

Try booting with noreboot - that should keep any panic message on screen
until you manually choose to reset the machine.  Seeing where in the
panic occurs would be very helpful, even if you just transcribe a few
lines manually.

>
> 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
> is enabled, then it simply panics and reboots.
>
> The logs(xen_live.tgz) are attached. Note this was captured with VT-d
> being enabled, but I did check it with VT-d enabled and the boot
> looked the same. I can capture it again if needed.
>
>
> 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
> enabled(which shows working in xl) and x2apic enabled.
>
> I have also attached(xen_server_6.0.0.tar.gz) these logs, which
> includes logs both with and without VT-d and x2apic enabled. I did not
> actually create any VMs, only booted this and checked what xl reported.
>
>

That is rather interesting - I am not aware of any XenServer specific
changes in this regard.

> If there is anything else I can add, please let me know. I am going to
> download 4.1.1 now, build it and see if it works, because it does on
> Xen Server. I am open to testing anything as this is an original build
> on this box, so I'm willing to knock it around if it will help.
>
> #
>

Knowing whether upstream 4.1.1 works will be very useful in workout out
whether it is a regression introduced into unstable, or whether there is
some XenServer specific change which we should upstream.

> Thanks,
>
> Paul
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQpy-0005So-Gr; Fri, 17 Feb 2012 16:39:10 +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 1RyQpw-0005Sd-Iq
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:39:08 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329496692!49735456!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18266 invoked from network); 17 Feb 2012 16:38:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 16:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325480400"; d="scan'208";a="182418049"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 11:39:05 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	11:39:05 -0500
Message-ID: <4F3E82A8.4060204@citrix.com>
Date: Fri, 17 Feb 2012 16:39:04 +0000
From: Andrew Cooper <andrew.cooper3@citrix.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: Paul S <pstroud@gmail.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
In-Reply-To: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/12 16:21, Paul S wrote:
> Environment:
> ASRock Z86 Extreme4 - Intel i5 2500
> http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
>
> I have installed the latest UEFI patch(1.70) and all tests were run
> from a reset of everything to default. I have tested with both Ubuntu
> 11.10 and Fedora 16 and get the same results on both, including
> building xen 4.2-unstable. I bought this particular MB because it had
> a know working vt-d implementation via VMWare.
>
> NOTE: current unstable as of last night is still affected by this
> library error http://www.gossamer-threads.com/lists/xen/devel/234300
>
> However, after correcting the library error, I was able to complete
> the unstable build.
>
> In both cases, it either stops with a panic/blank screen, or just reboots.
>
> Here are some other notes:
>
> 1) If x2apic is enabled on the motherboard, it almost immediately
> reboots with any of the configurations above

There are some fairly strict set of requirements on what which MSRs you
can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
early in boot which results in a protection fault.

>
> 2) The boot gets to here:
>
> (XEN) HVM: VMX enabled
>
> (XEN) HVM: Hardware Assisted Paging detected.
>
>
> Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
> where it hangs with the blank/panic screen or reboots. This sometimes
> shows up on CPU 1, CPU2, or both.
>
>
> 3) There is no boot log written and the machine does not have a native
> serial port, so capturing anything may prove difficult, but I am open
> to suggestions.
>

Try booting with noreboot - that should keep any panic message on screen
until you manually choose to reset the machine.  Seeing where in the
panic occurs would be very helpful, even if you just transcribe a few
lines manually.

>
> 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
> is enabled, then it simply panics and reboots.
>
> The logs(xen_live.tgz) are attached. Note this was captured with VT-d
> being enabled, but I did check it with VT-d enabled and the boot
> looked the same. I can capture it again if needed.
>
>
> 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
> enabled(which shows working in xl) and x2apic enabled.
>
> I have also attached(xen_server_6.0.0.tar.gz) these logs, which
> includes logs both with and without VT-d and x2apic enabled. I did not
> actually create any VMs, only booted this and checked what xl reported.
>
>

That is rather interesting - I am not aware of any XenServer specific
changes in this regard.

> If there is anything else I can add, please let me know. I am going to
> download 4.1.1 now, build it and see if it works, because it does on
> Xen Server. I am open to testing anything as this is an original build
> on this box, so I'm willing to knock it around if it will help.
>
> #
>

Knowing whether upstream 4.1.1 works will be very useful in workout out
whether it is a regression introduced into unstable, or whether there is
some XenServer specific change which we should upstream.

> Thanks,
>
> Paul
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:43:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQu3-0005aY-6E; Fri, 17 Feb 2012 16:43:23 +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 1RyQu1-0005aT-CI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329496947!49736004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28057 invoked from network); 17 Feb 2012 16:42:27 -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;
	17 Feb 2012 16:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10779256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 16:43:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 16:43:20 +0000
Message-ID: <1329496998.3131.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 16:43:18 +0000
In-Reply-To: <20120217160341.GA22266@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 16:03 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> 
> > That's exactly the sort of complexity we should not be exposing to the
> > end user!
> 
> Of course not as is!
> Right now one has to understand two values, maxmem and the size of the
> memhog called "guest balloon driver". Paging adds a third one.

Right, but that third one should not be "paging size" or anything like
that, just like they should not really have to understand what "a memhog
called "guest balloon driver"" is. Even today the thing we actually
expose is just called "memory" in the configuration.

The user cares about three things:
     1. The maximum amount of memory a guest can use.
     2. The amount of memory which the guest thinks it has.
     3. The actual amount of memory the guest has

The fact that these are implemented by some combination of paging and/or
ballooning is not really of interest to the user. They only need to be
aware that if #3 < #2 then there is a performance cost and that even if
#2==#3 a guest which tries to use more memory than that will be suffer a
performance penalty.

My point is that the memory knobs should be exposed to the user of xl as
semantically meaningful options without the need to refer to "the paging
target" or "the balloon target" which is why there should not IMHO be
"xl commands to adjust just ballooning and/or paging".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:43:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyQu3-0005aY-6E; Fri, 17 Feb 2012 16:43:23 +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 1RyQu1-0005aT-CI
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329496947!49736004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28057 invoked from network); 17 Feb 2012 16:42:27 -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;
	17 Feb 2012 16:42:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10779256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 16:43:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 16:43:20 +0000
Message-ID: <1329496998.3131.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 17 Feb 2012 16:43:18 +0000
In-Reply-To: <20120217160341.GA22266@aepfle.de>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 16:03 +0000, Olaf Hering wrote:
> On Fri, Feb 17, Ian Campbell wrote:
> 
> > That's exactly the sort of complexity we should not be exposing to the
> > end user!
> 
> Of course not as is!
> Right now one has to understand two values, maxmem and the size of the
> memhog called "guest balloon driver". Paging adds a third one.

Right, but that third one should not be "paging size" or anything like
that, just like they should not really have to understand what "a memhog
called "guest balloon driver"" is. Even today the thing we actually
expose is just called "memory" in the configuration.

The user cares about three things:
     1. The maximum amount of memory a guest can use.
     2. The amount of memory which the guest thinks it has.
     3. The actual amount of memory the guest has

The fact that these are implemented by some combination of paging and/or
ballooning is not really of interest to the user. They only need to be
aware that if #3 < #2 then there is a performance cost and that even if
#2==#3 a guest which tries to use more memory than that will be suffer a
performance penalty.

My point is that the memory knobs should be exposed to the user of xl as
semantically meaningful options without the need to refer to "the paging
target" or "the balloon target" which is why there should not IMHO be
"xl commands to adjust just ballooning and/or paging".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:44:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQv6-0005eu-Kh; Fri, 17 Feb 2012 16:44:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RyQv5-0005eT-8l
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:44:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329497059!4535782!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31925 invoked from network); 17 Feb 2012 16:44:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 16:44:21 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1HGiBR5014095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 17 Feb 2012 11:44:11 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1HGiBvD014093;
	Fri, 17 Feb 2012 11:44:11 -0500
Date: Fri, 17 Feb 2012 12:44:11 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "W. Michael Petullo" <mike@flyn.org>
Message-ID: <20120217164410.GA14012@andromeda.dapyr.net>
References: <20120128235449.GA22022@imp.flyn.org>
	<20120201010500.GC32295@andromeda.dapyr.net>
	<20120201012811.GA1994@imp.flyn.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120201012811.GA1994@imp.flyn.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 07:28:12PM -0600, W. Michael Petullo wrote:
> >> I have ported Anil's passive profile-capable OProfile patch to Linux
> >> 3.2. I have be able to hobble this patch along to new kernel versions, but
> >> it is in need of additional work if it is to be submitted upstream. Please
> >> see:
> >> 
> >> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz
> >> 
> >> With this patch applied to Linux 3.2, I can perform passive
> >> profiling of an unprivileged Xen domain.
> 
> > What version of oprofile did you use?
> 
> Fedora's oprofile-0.9.6-21.fc16.x86_64.

So I took a spin at this - it applies nicely and cleanly to 3.2, and
was wondering how you profile passive domains?

I do something like this:

opcontrol --vmlinux=/mnt/lab/vmlinux-dom0 --xen=/mnt/lab/xen-syms --passive-domains=3,2 --callgraph=10 --passive-images=/mnt/lab/10gb/tiny-vmlinux  -p=cpu 
opcontrol --start-daemon

opcontrol --start
/mnt/lab/10gb/create_csv.sh 1
opcontrol --stop

The little create_csv.sh makes the two domains talk to each other
(netperf) and I want to get a feel for what it is happening.

But what I get is exclusivly to domain0 and to xen. Nothing about
the guests?

Are you doing something speciail to profile the passive domains?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:44:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyQv6-0005eu-Kh; Fri, 17 Feb 2012 16:44:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RyQv5-0005eT-8l
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:44:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329497059!4535782!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31925 invoked from network); 17 Feb 2012 16:44:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 16:44:21 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q1HGiBR5014095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 17 Feb 2012 11:44:11 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q1HGiBvD014093;
	Fri, 17 Feb 2012 11:44:11 -0500
Date: Fri, 17 Feb 2012 12:44:11 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "W. Michael Petullo" <mike@flyn.org>
Message-ID: <20120217164410.GA14012@andromeda.dapyr.net>
References: <20120128235449.GA22022@imp.flyn.org>
	<20120201010500.GC32295@andromeda.dapyr.net>
	<20120201012811.GA1994@imp.flyn.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120201012811.GA1994@imp.flyn.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 07:28:12PM -0600, W. Michael Petullo wrote:
> >> I have ported Anil's passive profile-capable OProfile patch to Linux
> >> 3.2. I have be able to hobble this patch along to new kernel versions, but
> >> it is in need of additional work if it is to be submitted upstream. Please
> >> see:
> >> 
> >> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz
> >> 
> >> With this patch applied to Linux 3.2, I can perform passive
> >> profiling of an unprivileged Xen domain.
> 
> > What version of oprofile did you use?
> 
> Fedora's oprofile-0.9.6-21.fc16.x86_64.

So I took a spin at this - it applies nicely and cleanly to 3.2, and
was wondering how you profile passive domains?

I do something like this:

opcontrol --vmlinux=/mnt/lab/vmlinux-dom0 --xen=/mnt/lab/xen-syms --passive-domains=3,2 --callgraph=10 --passive-images=/mnt/lab/10gb/tiny-vmlinux  -p=cpu 
opcontrol --start-daemon

opcontrol --start
/mnt/lab/10gb/create_csv.sh 1
opcontrol --stop

The little create_csv.sh makes the two domains talk to each other
(netperf) and I want to get a feel for what it is happening.

But what I get is exclusivly to domain0 and to xen. Nothing about
the guests?

Are you doing something speciail to profile the passive domains?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:53:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyR3V-00060I-RC; Fri, 17 Feb 2012 16:53:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyR3U-00060D-8y
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:53:08 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329497581!15787371!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM4NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 612 invoked from network); 17 Feb 2012 16:53:01 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 16:53:01 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1HGqxrP005206
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 11:52:59 -0500
Received: from turtle.usersys.redhat.com (vpn-9-132.rdu.redhat.com
	[10.11.9.132])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1HGqs04026211
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 17 Feb 2012 11:52:57 -0500
Date: Fri, 17 Feb 2012 17:52:54 +0100
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <20120217165253.GA17397@turtle.usersys.redhat.com>
References: <1329394629-10299-1-git-send-email-drjones@redhat.com>
	<7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> Hmm, I should maybe self-nack this. The bug that led me to writing
> it is likely only with older tooling, such as RHEL5's. The problem
> was if you attempted to detach a mounted disk twice, then the second
> time it would succeed. The guest had flipped to Closing on the first
> try, and thus didn't issue an error to xenbus on the second. I see

Actually, it's even worse than I thought. Just a single attempt to
detach the device will cause the guest grief (with RHEL5's tools
anyway). Once xenbus shows the device is in the Closing state, then
tasks accessing the device may hang.

> The reason I only say maybe self-nack though, is because this state
> change seemed to be thrown in with another fix[1]. I'm not sure if
> the new behavior on legacy hosts was considered or not. If not, then
> we can consider it now. Do we want to have deferred asynch detaches
> over protecting the guest from multiple detach calls on legacy hosts?
> 

I guess we can keep the feature and protect the guest with a patch like
I'll send in a moment. It doesn't really work for me with a RHEL5 host
though. The deferred close works from the pov of the guest, but the
state of the block device gets left in Closed after the guest unmounts
it, and then RHEL5's tools can't detach/reattach it. If the deferred
close ever worked on other Xen hosts though, then I don't believe this
patch would break it, and it will also keep the guest safe when run on
hosts that don't treat state=Closing the way it currently expects.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:53:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16: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.xensource.com>)
	id 1RyR3V-00060I-RC; Fri, 17 Feb 2012 16:53:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyR3U-00060D-8y
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:53:08 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329497581!15787371!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM4NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 612 invoked from network); 17 Feb 2012 16:53:01 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 16:53:01 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1HGqxrP005206
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 11:52:59 -0500
Received: from turtle.usersys.redhat.com (vpn-9-132.rdu.redhat.com
	[10.11.9.132])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1HGqs04026211
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 17 Feb 2012 11:52:57 -0500
Date: Fri, 17 Feb 2012 17:52:54 +0100
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <20120217165253.GA17397@turtle.usersys.redhat.com>
References: <1329394629-10299-1-git-send-email-drjones@redhat.com>
	<7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> Hmm, I should maybe self-nack this. The bug that led me to writing
> it is likely only with older tooling, such as RHEL5's. The problem
> was if you attempted to detach a mounted disk twice, then the second
> time it would succeed. The guest had flipped to Closing on the first
> try, and thus didn't issue an error to xenbus on the second. I see

Actually, it's even worse than I thought. Just a single attempt to
detach the device will cause the guest grief (with RHEL5's tools
anyway). Once xenbus shows the device is in the Closing state, then
tasks accessing the device may hang.

> The reason I only say maybe self-nack though, is because this state
> change seemed to be thrown in with another fix[1]. I'm not sure if
> the new behavior on legacy hosts was considered or not. If not, then
> we can consider it now. Do we want to have deferred asynch detaches
> over protecting the guest from multiple detach calls on legacy hosts?
> 

I guess we can keep the feature and protect the guest with a patch like
I'll send in a moment. It doesn't really work for me with a RHEL5 host
though. The deferred close works from the pov of the guest, but the
state of the block device gets left in Closed after the guest unmounts
it, and then RHEL5's tools can't detach/reattach it. If the deferred
close ever worked on other Xen hosts though, then I don't believe this
patch would break it, and it will also keep the guest safe when run on
hosts that don't treat state=Closing the way it currently expects.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:53:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR3x-00061q-8F; Fri, 17 Feb 2012 16:53:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyR3v-00061T-IP
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:53:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329497609!9684511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28473 invoked from network); 17 Feb 2012 16:53:29 -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;
	17 Feb 2012 16:53:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10779413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 16: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.213.0; Fri, 17 Feb 2012 16:53:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyR3o-0005m8-Us;
	Fri, 17 Feb 2012 16:53:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyR3o-0000Di-UI;
	Fri, 17 Feb 2012 16:53:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11980-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 16:53:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11980: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11980 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11980/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11979

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b5ac7d99d93f
baseline version:
 xen                  b75664e53905

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Kaixing Hong <hongkaixing@huawei.com>,
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhen Shi <bicky.shi@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=b5ac7d99d93f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 b5ac7d99d93f
+ branch=xen-unstable
+ revision=b5ac7d99d93f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r b5ac7d99d93f 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:53:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR3x-00061q-8F; Fri, 17 Feb 2012 16:53:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyR3v-00061T-IP
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:53:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329497609!9684511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28473 invoked from network); 17 Feb 2012 16:53:29 -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;
	17 Feb 2012 16:53:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="10779413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 16: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.213.0; Fri, 17 Feb 2012 16:53:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyR3o-0005m8-Us;
	Fri, 17 Feb 2012 16:53:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyR3o-0000Di-UI;
	Fri, 17 Feb 2012 16:53:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11980-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 16:53:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11980: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11980 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11980/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11979

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b5ac7d99d93f
baseline version:
 xen                  b75664e53905

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Kaixing Hong <hongkaixing@huawei.com>,
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhen Shi <bicky.shi@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=b5ac7d99d93f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 b5ac7d99d93f
+ branch=xen-unstable
+ revision=b5ac7d99d93f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r b5ac7d99d93f 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:55:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR62-0006CJ-SP; Fri, 17 Feb 2012 16:55:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyR62-0006Bn-12
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:55:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329497739!8677282!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTUyODg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2555 invoked from network); 17 Feb 2012 16:55:39 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 16:55:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 83C7730006C;
	Fri, 17 Feb 2012 08:55:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=KV95SC03O1Z8RJnjTi1aCr3etea8SPcUN9C12U5IxCsO
	SKaaONWjG6FlQAu0TqCzQYvFWm2OkyS+qnVAYlfQOn4TdDCepaSFbL12lDfEWYJB
	f2+bj16odsnMJNvDlBgWZ2ypAQHzD8tJnkRCJ+j5pZq80j898EbCDo/cPvyAPX8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=btl89d38fANFGwK5Lc/DEgJzjsg=; b=Eg7jqGg7
	KJonaYCS3G4lTV32IthtXtFhdPgw1hkyNR0eEGoWBA5Cags924Vh99HsUmkym/BY
	5qhYs5OIXo+14+xA1jezUth/VKCzIJc9rSrMHzMBc2aUt6H9bx6t+RwuuSZ6kChz
	AP7XUOMvwIBTaVzxubp2Odpp7JmUqT4wt+4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id DB8C6300064; 
	Fri, 17 Feb 2012 08:55:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:55:38 -0800
Message-ID: <c67740cc67a8ccfa523e4483270282b6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3929.1329497068.1471.xen-devel@lists.xensource.com>
References: <mailman.3929.1329497068.1471.xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 08:55:38 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Fri, 17 Feb 2012 16:43:18 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for
> 	xenpaging
> Message-ID: <1329496998.3131.131.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2012-02-17 at 16:03 +0000, Olaf Hering wrote:
>> On Fri, Feb 17, Ian Campbell wrote:
>>
>> > That's exactly the sort of complexity we should not be exposing to the
>> > end user!
>>
>> Of course not as is!
>> Right now one has to understand two values, maxmem and the size of the
>> memhog called "guest balloon driver". Paging adds a third one.
>
> Right, but that third one should not be "paging size" or anything like
> that, just like they should not really have to understand what "a memhog
> called "guest balloon driver"" is. Even today the thing we actually
> expose is just called "memory" in the configuration.
>
> The user cares about three things:
>      1. The maximum amount of memory a guest can use.
>      2. The amount of memory which the guest thinks it has.
>      3. The actual amount of memory the guest has
>
> The fact that these are implemented by some combination of paging and/or
> ballooning is not really of interest to the user. They only need to be
> aware that if #3 < #2 then there is a performance cost and that even if
> #2==#3 a guest which tries to use more memory than that will be suffer a
> performance penalty.
>
> My point is that the memory knobs should be exposed to the user of xl as
> semantically meaningful options without the need to refer to "the paging
> target" or "the balloon target" which is why there should not IMHO be
> "xl commands to adjust just ballooning and/or paging".
>

May I suggest you call these things 'memory' and 'footprint'? Users can
adjust the memory the guest thinks it has (#2 above), and the footprint
the domain will actually occupy (#3).

Then footprint can be adjusted by paging or something else. I don't want
to begin to think about how PoD would jive there. It only seems to affect
'footprint' during bootup.

Andres
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:55:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR62-0006CJ-SP; Fri, 17 Feb 2012 16:55:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyR62-0006Bn-12
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:55:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329497739!8677282!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTUyODg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2555 invoked from network); 17 Feb 2012 16:55:39 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 16:55:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 83C7730006C;
	Fri, 17 Feb 2012 08:55:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=KV95SC03O1Z8RJnjTi1aCr3etea8SPcUN9C12U5IxCsO
	SKaaONWjG6FlQAu0TqCzQYvFWm2OkyS+qnVAYlfQOn4TdDCepaSFbL12lDfEWYJB
	f2+bj16odsnMJNvDlBgWZ2ypAQHzD8tJnkRCJ+j5pZq80j898EbCDo/cPvyAPX8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=btl89d38fANFGwK5Lc/DEgJzjsg=; b=Eg7jqGg7
	KJonaYCS3G4lTV32IthtXtFhdPgw1hkyNR0eEGoWBA5Cags924Vh99HsUmkym/BY
	5qhYs5OIXo+14+xA1jezUth/VKCzIJc9rSrMHzMBc2aUt6H9bx6t+RwuuSZ6kChz
	AP7XUOMvwIBTaVzxubp2Odpp7JmUqT4wt+4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id DB8C6300064; 
	Fri, 17 Feb 2012 08:55:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:55:38 -0800
Message-ID: <c67740cc67a8ccfa523e4483270282b6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.3929.1329497068.1471.xen-devel@lists.xensource.com>
References: <mailman.3929.1329497068.1471.xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 08:55:38 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Fri, 17 Feb 2012 16:43:18 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for
> 	xenpaging
> Message-ID: <1329496998.3131.131.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2012-02-17 at 16:03 +0000, Olaf Hering wrote:
>> On Fri, Feb 17, Ian Campbell wrote:
>>
>> > That's exactly the sort of complexity we should not be exposing to the
>> > end user!
>>
>> Of course not as is!
>> Right now one has to understand two values, maxmem and the size of the
>> memhog called "guest balloon driver". Paging adds a third one.
>
> Right, but that third one should not be "paging size" or anything like
> that, just like they should not really have to understand what "a memhog
> called "guest balloon driver"" is. Even today the thing we actually
> expose is just called "memory" in the configuration.
>
> The user cares about three things:
>      1. The maximum amount of memory a guest can use.
>      2. The amount of memory which the guest thinks it has.
>      3. The actual amount of memory the guest has
>
> The fact that these are implemented by some combination of paging and/or
> ballooning is not really of interest to the user. They only need to be
> aware that if #3 < #2 then there is a performance cost and that even if
> #2==#3 a guest which tries to use more memory than that will be suffer a
> performance penalty.
>
> My point is that the memory knobs should be exposed to the user of xl as
> semantically meaningful options without the need to refer to "the paging
> target" or "the balloon target" which is why there should not IMHO be
> "xl commands to adjust just ballooning and/or paging".
>

May I suggest you call these things 'memory' and 'footprint'? Users can
adjust the memory the guest thinks it has (#2 above), and the footprint
the domain will actually occupy (#3).

Then footprint can be adjusted by paging or something else. I don't want
to begin to think about how PoD would jive there. It only seems to affect
'footprint' during bootup.

Andres
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:57:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR7W-0006LR-Bo; Fri, 17 Feb 2012 16:57:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyR7U-0006Ka-N0
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:57:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329497830!11923538!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDEzODE3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31093 invoked from network); 17 Feb 2012 16:57:10 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-7.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 16:57:10 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 876E2604079;
	Fri, 17 Feb 2012 08:57:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=NwgXccFBjjN+kzIxqle+/pxexZhsFr7WKYBVwKMiar84
	zPI8/u/RR1kTCyZDU2aGTULBOT/rDK4awLm2l30FjzkLH2AwUfr/bXz/rC0ahZMi
	+kt0g4ZsdklYG3D8INfQVV3yRHQ+GEkzFFMISdK2jsZl3NflSck2gMqlzu8jWro=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=iAG/UEwLXU+Mu0behMduYiifCHw=; b=qbf1VDmf
	YKce1PUTJQj/WcIdu5QUIOU9dXNUM2dRcdRBOflIevCGv+Y2SdV20HTyBi96FNZs
	lzB6rPKaIKOcOQWmARpgA1AoLT9LQ3fafn6ul3xUsoxSE5Gv9dW5P8Es4s9XFAA8
	4L4v3Z0P/OJWxviKOuCtyeV0de1KvUuO0A4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 069C8604078; 
	Fri, 17 Feb 2012 08:57:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:57:09 -0800
Message-ID: <9a1bf975f48e75e714a3128f19f43336.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216161114.GF41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
	<20120216161114.GF41163@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 08:57:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 4] x86/mm: Allow to not sleep on mem
 event ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:57 -0500 on 15 Feb (1329346625), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_event.c     |   5 +++--
>>  xen/include/asm-x86/mem_event.h |  30 +++++++++++++++++++++++++-----
>>  2 files changed, 28 insertions(+), 7 deletions(-)
>>
>>
>> Under extreme congestion conditions, generating a mem event may put the
>> vcpu to
>> sleep on a wait queue if the ring is full. This is generally desirable,
>> although
>> fairly convoluted to work with, since sleeping on a wait queue requires
>> a
>> non-atomic context (i.e. no locks held).
>>
>> Introduce an allow_sleep flag to make this optional. The API remains
>> such that
>> all current callers set allow_sleep to true and thus will sleep if
>> necessary.
>>
>> The end-use is for cases in which loss of guest mem events is tolerable.
>> One
>> such consumer to be added later is the unsharing code under ENOMEM
>> conditions.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
> Hmm.  This interface is getting a bit twisty now, but assuming the
> patches that use it are OK, then Ack.

Another option is to call a ring "best effort", and then the event
producer doesn't have to specify whether sleep is allowable. The event
producer should know, though, whether the ring is best effort. I think
that makes up for a cleaner interface.

Andres
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:57:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR7W-0006LR-Bo; Fri, 17 Feb 2012 16:57:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyR7U-0006Ka-N0
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:57:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329497830!11923538!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDEzODE3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31093 invoked from network); 17 Feb 2012 16:57:10 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-7.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 16:57:10 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 876E2604079;
	Fri, 17 Feb 2012 08:57:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=NwgXccFBjjN+kzIxqle+/pxexZhsFr7WKYBVwKMiar84
	zPI8/u/RR1kTCyZDU2aGTULBOT/rDK4awLm2l30FjzkLH2AwUfr/bXz/rC0ahZMi
	+kt0g4ZsdklYG3D8INfQVV3yRHQ+GEkzFFMISdK2jsZl3NflSck2gMqlzu8jWro=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=iAG/UEwLXU+Mu0behMduYiifCHw=; b=qbf1VDmf
	YKce1PUTJQj/WcIdu5QUIOU9dXNUM2dRcdRBOflIevCGv+Y2SdV20HTyBi96FNZs
	lzB6rPKaIKOcOQWmARpgA1AoLT9LQ3fafn6ul3xUsoxSE5Gv9dW5P8Es4s9XFAA8
	4L4v3Z0P/OJWxviKOuCtyeV0de1KvUuO0A4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 069C8604078; 
	Fri, 17 Feb 2012 08:57:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 08:57:09 -0800
Message-ID: <9a1bf975f48e75e714a3128f19f43336.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216161114.GF41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<09746decbd28309ff25c.1329364625@xdev.gridcentric.ca>
	<20120216161114.GF41163@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 08:57:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 4] x86/mm: Allow to not sleep on mem
 event ring
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:57 -0500 on 15 Feb (1329346625), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_event.c     |   5 +++--
>>  xen/include/asm-x86/mem_event.h |  30 +++++++++++++++++++++++++-----
>>  2 files changed, 28 insertions(+), 7 deletions(-)
>>
>>
>> Under extreme congestion conditions, generating a mem event may put the
>> vcpu to
>> sleep on a wait queue if the ring is full. This is generally desirable,
>> although
>> fairly convoluted to work with, since sleeping on a wait queue requires
>> a
>> non-atomic context (i.e. no locks held).
>>
>> Introduce an allow_sleep flag to make this optional. The API remains
>> such that
>> all current callers set allow_sleep to true and thus will sleep if
>> necessary.
>>
>> The end-use is for cases in which loss of guest mem events is tolerable.
>> One
>> such consumer to be added later is the unsharing code under ENOMEM
>> conditions.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>
> Hmm.  This interface is getting a bit twisty now, but assuming the
> patches that use it are OK, then Ack.

Another option is to call a ring "best effort", and then the event
producer doesn't have to specify whether sleep is allowable. The event
producer should know, though, whether the ring is best effort. I think
that makes up for a cleaner interface.

Andres
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:59:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:59:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR9K-0006YD-1l; Fri, 17 Feb 2012 16:59:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyR9I-0006XU-8N
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 16:59:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329497941!13763431!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26559 invoked from network); 17 Feb 2012 16:59:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 16:59:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 16:59:01 +0000
Message-Id: <4F3E95610200007800073B97@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 16:58:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
In-Reply-To: <20120217162344.GA59026@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
 pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.02.12 at 17:23, Tim Deegan <tim@xen.org> wrote:
> At 15:50 +0000 on 17 Feb (1329493838), Jan Beulich wrote:
>> The problem appears to be that the or-ing in of PFEC_reserved_bit
>> happens without consideration of PFEC_present. If you can confirm
>> I'm not mis-interpreting things, fixing this should be relatively
>> strait forward (though the question would be whether it should be
>> guest_walk_tables() or its callers that should be fixed).
> 
> We should fix it in guest_walk_tables, since AFAICS it's possible for
> PFEC_reserved_bit to be set based on a bad higher-level entry even if a
> lower-level one has _PAGE_PRESENT clear.
> 
> Something like the attached (compile-tested only) patch? 

That was really fast, thanks!

Yes, that looks like it should do it. We'll want to give it a try early
next week.

> (Sigh; this PT walker was once relatively readable and efficient.)

Sorry for that ;-) (I wonder though whether this whole evaluation
of the flags couldn't be put in a macro, as it's - apart from the level
number - the same in all four places afaics.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:59:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:59:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR9K-0006YD-1l; Fri, 17 Feb 2012 16:59:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RyR9I-0006XU-8N
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 16:59:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329497941!13763431!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26559 invoked from network); 17 Feb 2012 16:59:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 16:59:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 17 Feb 2012 16:59:01 +0000
Message-Id: <4F3E95610200007800073B97@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 17 Feb 2012 16:58:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
In-Reply-To: <20120217162344.GA59026@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
 pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.02.12 at 17:23, Tim Deegan <tim@xen.org> wrote:
> At 15:50 +0000 on 17 Feb (1329493838), Jan Beulich wrote:
>> The problem appears to be that the or-ing in of PFEC_reserved_bit
>> happens without consideration of PFEC_present. If you can confirm
>> I'm not mis-interpreting things, fixing this should be relatively
>> strait forward (though the question would be whether it should be
>> guest_walk_tables() or its callers that should be fixed).
> 
> We should fix it in guest_walk_tables, since AFAICS it's possible for
> PFEC_reserved_bit to be set based on a bad higher-level entry even if a
> lower-level one has _PAGE_PRESENT clear.
> 
> Something like the attached (compile-tested only) patch? 

That was really fast, thanks!

Yes, that looks like it should do it. We'll want to give it a try early
next week.

> (Sigh; this PT walker was once relatively readable and efficient.)

Sorry for that ;-) (I wonder though whether this whole evaluation
of the flags couldn't be put in a macro, as it's - apart from the level
number - the same in all four places afaics.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR9i-0006bk-Fw; Fri, 17 Feb 2012 16:59:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyR9g-0006b3-SU
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:59:33 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329497965!13821269!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM4NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6562 invoked from network); 17 Feb 2012 16:59:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 16:59:25 -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 q1HGxN4w026616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 11:59:23 -0500
Received: from turtle.usersys.redhat.com (vpn-9-132.rdu.redhat.com
	[10.11.9.132])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1HGxLEd014836; Fri, 17 Feb 2012 11:59:22 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 17:59:19 +0100
Message-Id: <1329497959-19427-1-git-send-email-drjones@redhat.com>
In-Reply-To: <20120217165253.GA17397@turtle.usersys.redhat.com>
References: <20120217165253.GA17397@turtle.usersys.redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v2] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We just reported to xenbus that we can't close yet, because we're still
in use. So we shouldn't then immediately tell xenbus that we are
closing. If we do, then we risk bypassing the chance to complain again,
if we're told to close again, and we're still in use. The reason this
code was here was to implement a deferred close. We can still support
this feature by adding a member to our private data, and setting that
instead. Besides being able to complain each time, this patch fixes
a problem when running on hosts with legacy tools that may interpret
the lack of a complaint or state=Closing incorrectly, and then yank
the device out from under the guest.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/block/xen-blkfront.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..d7f2e03 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -103,6 +103,7 @@ struct blkfront_info
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
+	int closing;
 };
 
 static DEFINE_SPINLOCK(blkif_io_lock);
@@ -1134,7 +1135,7 @@ blkfront_closing(struct blkfront_info *info)
 	if (bdev->bd_openers) {
 		xenbus_dev_error(xbdev, -EBUSY,
 				 "Device in use; refusing to close");
-		xenbus_switch_state(xbdev, XenbusStateClosing);
+		info->closing = 1;
 	} else {
 		xlvbd_release_gendisk(info);
 		xenbus_frontend_closed(xbdev);
@@ -1423,8 +1424,10 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
 	mutex_lock(&info->mutex);
 	xbdev = info->xbdev;
 
-	if (xbdev && xbdev->state == XenbusStateClosing) {
+	if (xbdev && (xbdev->state == XenbusStateClosing || info->closing)) {
 		/* pending switch to state closed */
+		if (xbdev->state != XenbusStateClosing)
+			xenbus_switch_state(xbdev, XenbusStateClosing);
 		dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
 		xlvbd_release_gendisk(info);
 		xenbus_frontend_closed(info->xbdev);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 16:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 16:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyR9i-0006bk-Fw; Fri, 17 Feb 2012 16:59:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RyR9g-0006b3-SU
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 16:59:33 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329497965!13821269!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM4NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6562 invoked from network); 17 Feb 2012 16:59:25 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 16:59:25 -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 q1HGxN4w026616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 11:59:23 -0500
Received: from turtle.usersys.redhat.com (vpn-9-132.rdu.redhat.com
	[10.11.9.132])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1HGxLEd014836; Fri, 17 Feb 2012 11:59:22 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 17:59:19 +0100
Message-Id: <1329497959-19427-1-git-send-email-drjones@redhat.com>
In-Reply-To: <20120217165253.GA17397@turtle.usersys.redhat.com>
References: <20120217165253.GA17397@turtle.usersys.redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v2] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We just reported to xenbus that we can't close yet, because we're still
in use. So we shouldn't then immediately tell xenbus that we are
closing. If we do, then we risk bypassing the chance to complain again,
if we're told to close again, and we're still in use. The reason this
code was here was to implement a deferred close. We can still support
this feature by adding a member to our private data, and setting that
instead. Besides being able to complain each time, this patch fixes
a problem when running on hosts with legacy tools that may interpret
the lack of a complaint or state=Closing incorrectly, and then yank
the device out from under the guest.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/block/xen-blkfront.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..d7f2e03 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -103,6 +103,7 @@ struct blkfront_info
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
+	int closing;
 };
 
 static DEFINE_SPINLOCK(blkif_io_lock);
@@ -1134,7 +1135,7 @@ blkfront_closing(struct blkfront_info *info)
 	if (bdev->bd_openers) {
 		xenbus_dev_error(xbdev, -EBUSY,
 				 "Device in use; refusing to close");
-		xenbus_switch_state(xbdev, XenbusStateClosing);
+		info->closing = 1;
 	} else {
 		xlvbd_release_gendisk(info);
 		xenbus_frontend_closed(xbdev);
@@ -1423,8 +1424,10 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
 	mutex_lock(&info->mutex);
 	xbdev = info->xbdev;
 
-	if (xbdev && xbdev->state == XenbusStateClosing) {
+	if (xbdev && (xbdev->state == XenbusStateClosing || info->closing)) {
 		/* pending switch to state closed */
+		if (xbdev->state != XenbusStateClosing)
+			xenbus_switch_state(xbdev, XenbusStateClosing);
 		dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
 		xlvbd_release_gendisk(info);
 		xenbus_frontend_closed(info->xbdev);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRCC-0006vE-7U; Fri, 17 Feb 2012 17:02:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyRCA-0006uu-M9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:02:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329498120!9685768!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTUxMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23188 invoked from network); 17 Feb 2012 17:02:00 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 17:02:00 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 3D0FC5EC082;
	Fri, 17 Feb 2012 09:01:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=JS6+xr/UQ+Bd9vSP5KVNw2+NxVcU4mqaTXhML5dQD0ad
	Nc/acQQtZy/hpZL5sq8AqMoM6RQkm4T2Xf0yWlpDjZ4/KmCC5hsj+9bzSeL+e6XT
	6dHkgDoECiBK18aSKsPWUXCOBghS6+9TV67q3P09j47TCikzzHDJM6xNqNz13+A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=3sJd9yNNsqYTWib55mGKpn/xcGs=; b=ERlBK13J
	GyzcHeqIBP0z33u55c9PxeTLoPmLKJQ8Vy2vIqyikwy3Pc15cy2xmMBC/2eG2iWP
	W/9QhVHuZws01UoP26nIO0CuH/qxmZPD1DBA4jRr+74/8mx31xU+aMXPKTt5MSbF
	oILh6TY/YguTfflDSn17tIAtaIGSlEnv9dU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id A3B505EC080; 
	Fri, 17 Feb 2012 09:01:58 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 09:01:59 -0800
Message-ID: <18412e2a124a23a9d745da9ef97f6526.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216161911.GG41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
	<20120216161911.GG41163@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 09:01:59 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 4] Memory sharing: better handling of
 ENOMEM while unsharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:57 -0500 on 15 Feb (1329346626), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
>>  xen/arch/x86/mm.c                 |   8 +++--
>>  xen/arch/x86/mm/mem_sharing.c     |  52
>> ++++++++++++++++++++++++---------------
>>  xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
>>  xen/common/grant_table.c          |  11 ++++---
>>  xen/common/memory.c               |   1 +
>>  xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
>>  7 files changed, 94 insertions(+), 31 deletions(-)
>>
>>
>> If unsharing fails with ENOMEM, we were:
>>  - leaving the list of gfns backed by the shared page in an inconsistent
>> state
>>  - cycling forever on the hap page fault handler.
>>  - Attempting to produce a mem event (which could sleep on a wait queue)
>>    while holding locks.
>>  - Not checking, for all callers, that unshare could have indeed failed.
>>
>> Fix bugs above, and sanitize callers to place a ring event in an
>> unlocked
>> context, or without requiring to go to sleep on a wait queue.
>>
>> A note on the rationale for unshare error handling:
>>  1. Unshare can only fail with ENOMEM. Any other error conditions
>> BUG_ON()'s
>
> Please enforce this in the code -- either the function should just
> return success/failure or (better, I think) the caller should ASSERT
> that it doesn't see any other error codes.

I'll turn unshare into __unshare and make unshare a wrapper that asserts
the return value semantics of __unshare.

>
>>  2. We notify a potential dom0 helper through a mem_event ring. But we
>>     allow the notification to not go to sleep. If the event ring is full
>>     of ENOMEM warnings, then the helper will already have been kicked
>> enough.
>
> Could we just keep a count (or flag) to remind us that an ENOMEM is in
> the pipe and avoid having an exception to the waiting rules?

If we follow the "best effort ring" idea I just proposed for the previous
patch, it would make this one cleaner as well.

I don't think there's a point in remembering enomem's are on the pipe. The
helper will be woken up on enomem 1, it won't need over 64 notifications
to do something about it.

Andres

>
>>  3. We cannot "just" go to sleep until the unshare is resolved, because
>> we
>>     might be buried deep into locks (e.g. something -> copy_to_user ->
>>     __hvm_copy)
>>  4. So, we make sure we:
>>     4.1. return an error
>>     4.2. do not corrupt shared memory
>>     4.3. do not corrupt guest memory
>>     4.4. let the guest deal with the error if propagation will reach
>> that far
>
> Yep, the other cleanups look good to me.
>
> Cheers,
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRCC-0006vE-7U; Fri, 17 Feb 2012 17:02:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyRCA-0006uu-M9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:02:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329498120!9685768!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTUxMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23188 invoked from network); 17 Feb 2012 17:02:00 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 17:02:00 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 3D0FC5EC082;
	Fri, 17 Feb 2012 09:01:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=JS6+xr/UQ+Bd9vSP5KVNw2+NxVcU4mqaTXhML5dQD0ad
	Nc/acQQtZy/hpZL5sq8AqMoM6RQkm4T2Xf0yWlpDjZ4/KmCC5hsj+9bzSeL+e6XT
	6dHkgDoECiBK18aSKsPWUXCOBghS6+9TV67q3P09j47TCikzzHDJM6xNqNz13+A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=3sJd9yNNsqYTWib55mGKpn/xcGs=; b=ERlBK13J
	GyzcHeqIBP0z33u55c9PxeTLoPmLKJQ8Vy2vIqyikwy3Pc15cy2xmMBC/2eG2iWP
	W/9QhVHuZws01UoP26nIO0CuH/qxmZPD1DBA4jRr+74/8mx31xU+aMXPKTt5MSbF
	oILh6TY/YguTfflDSn17tIAtaIGSlEnv9dU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id A3B505EC080; 
	Fri, 17 Feb 2012 09:01:58 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 09:01:59 -0800
Message-ID: <18412e2a124a23a9d745da9ef97f6526.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120216161911.GG41163@ocelot.phlegethon.org>
References: <patchbomb.1329364623@xdev.gridcentric.ca>
	<407b5ac709aa3d4e0030.1329364626@xdev.gridcentric.ca>
	<20120216161911.GG41163@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 09:01:59 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 4] Memory sharing: better handling of
 ENOMEM while unsharing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:57 -0500 on 15 Feb (1329346626), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/hvm/hvm.c            |  20 +++++++++++++-
>>  xen/arch/x86/mm.c                 |   8 +++--
>>  xen/arch/x86/mm/mem_sharing.c     |  52
>> ++++++++++++++++++++++++---------------
>>  xen/arch/x86/mm/p2m.c             |  18 ++++++++++++-
>>  xen/common/grant_table.c          |  11 ++++---
>>  xen/common/memory.c               |   1 +
>>  xen/include/asm-x86/mem_sharing.h |  15 +++++++++++
>>  7 files changed, 94 insertions(+), 31 deletions(-)
>>
>>
>> If unsharing fails with ENOMEM, we were:
>>  - leaving the list of gfns backed by the shared page in an inconsistent
>> state
>>  - cycling forever on the hap page fault handler.
>>  - Attempting to produce a mem event (which could sleep on a wait queue)
>>    while holding locks.
>>  - Not checking, for all callers, that unshare could have indeed failed.
>>
>> Fix bugs above, and sanitize callers to place a ring event in an
>> unlocked
>> context, or without requiring to go to sleep on a wait queue.
>>
>> A note on the rationale for unshare error handling:
>>  1. Unshare can only fail with ENOMEM. Any other error conditions
>> BUG_ON()'s
>
> Please enforce this in the code -- either the function should just
> return success/failure or (better, I think) the caller should ASSERT
> that it doesn't see any other error codes.

I'll turn unshare into __unshare and make unshare a wrapper that asserts
the return value semantics of __unshare.

>
>>  2. We notify a potential dom0 helper through a mem_event ring. But we
>>     allow the notification to not go to sleep. If the event ring is full
>>     of ENOMEM warnings, then the helper will already have been kicked
>> enough.
>
> Could we just keep a count (or flag) to remind us that an ENOMEM is in
> the pipe and avoid having an exception to the waiting rules?

If we follow the "best effort ring" idea I just proposed for the previous
patch, it would make this one cleaner as well.

I don't think there's a point in remembering enomem's are on the pipe. The
helper will be woken up on enomem 1, it won't need over 64 notifications
to do something about it.

Andres

>
>>  3. We cannot "just" go to sleep until the unshare is resolved, because
>> we
>>     might be buried deep into locks (e.g. something -> copy_to_user ->
>>     __hvm_copy)
>>  4. So, we make sure we:
>>     4.1. return an error
>>     4.2. do not corrupt shared memory
>>     4.3. do not corrupt guest memory
>>     4.4. let the guest deal with the error if propagation will reach
>> that far
>
> Yep, the other cleanups look good to me.
>
> Cheers,
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:03:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRDR-00074U-Ml; Fri, 17 Feb 2012 17:03:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyRDR-00074K-5w
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:03:25 +0000
Received: from [85.158.139.83:51096] by server-10.bemta-5.messagelabs.com id
	4B/9C-07861-C588E3F4; Fri, 17 Feb 2012 17:03:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329498203!15532733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16884 invoked from network); 17 Feb 2012 17:03:24 -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;
	17 Feb 2012 17:03:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10779697"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 17:03:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 17:03:23 +0000
Message-ID: <1329498201.3131.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Fri, 17 Feb 2012 17:03:21 +0000
In-Reply-To: <c67740cc67a8ccfa523e4483270282b6.squirrel@webmail.lagarcavilla.org>
References: <mailman.3929.1329497068.1471.xen-devel@lists.xensource.com>
	<c67740cc67a8ccfa523e4483270282b6.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 16:55 +0000, Andres Lagar-Cavilla wrote:
> May I suggest you call these things 'memory' and 'footprint'? Users can
> adjust the memory the guest thinks it has (#2 above), and the footprint
> the domain will actually occupy (#3).

Footprint isn't a bad idea for that name.

> Then footprint can be adjusted by paging or something else. I don't want
> to begin to think about how PoD would jive there. It only seems to affect
> 'footprint' during bootup.

Yeah, it's basically a special case pager.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:03:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRDR-00074U-Ml; Fri, 17 Feb 2012 17:03:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyRDR-00074K-5w
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:03:25 +0000
Received: from [85.158.139.83:51096] by server-10.bemta-5.messagelabs.com id
	4B/9C-07861-C588E3F4; Fri, 17 Feb 2012 17:03:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329498203!15532733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16884 invoked from network); 17 Feb 2012 17:03:24 -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;
	17 Feb 2012 17:03:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10779697"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 17:03:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 17:03:23 +0000
Message-ID: <1329498201.3131.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Fri, 17 Feb 2012 17:03:21 +0000
In-Reply-To: <c67740cc67a8ccfa523e4483270282b6.squirrel@webmail.lagarcavilla.org>
References: <mailman.3929.1329497068.1471.xen-devel@lists.xensource.com>
	<c67740cc67a8ccfa523e4483270282b6.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 16:55 +0000, Andres Lagar-Cavilla wrote:
> May I suggest you call these things 'memory' and 'footprint'? Users can
> adjust the memory the guest thinks it has (#2 above), and the footprint
> the domain will actually occupy (#3).

Footprint isn't a bad idea for that name.

> Then footprint can be adjusted by paging or something else. I don't want
> to begin to think about how PoD would jive there. It only seems to affect
> 'footprint' during bootup.

Yeah, it's basically a special case pager.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIm-0007Lq-GJ; Fri, 17 Feb 2012 17:08: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 1RyRIl-0007Le-Jf
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:55 +0000
Received: from [85.158.139.83:38439] by server-3.bemta-5.messagelabs.com id
	91/1D-06438-6A98E3F4; Fri, 17 Feb 2012 17:08:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16640 invoked from network); 17 Feb 2012 17:08:54 -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;
	17 Feb 2012 17:08:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198919"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-16;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:36 +0000
Message-ID: <1329498525-8454-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 02/11] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIm-0007Lq-GJ; Fri, 17 Feb 2012 17:08: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 1RyRIl-0007Le-Jf
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:55 +0000
Received: from [85.158.139.83:38439] by server-3.bemta-5.messagelabs.com id
	91/1D-06438-6A98E3F4; Fri, 17 Feb 2012 17:08:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16640 invoked from network); 17 Feb 2012 17:08:54 -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;
	17 Feb 2012 17:08:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198919"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-16;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:36 +0000
Message-ID: <1329498525-8454-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 02/11] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIp-0007MX-LM; Fri, 17 Feb 2012 17:08:59 +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 1RyRIo-0007Ll-LX
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:58 +0000
Received: from [85.158.139.83:48808] by server-4.bemta-5.messagelabs.com id
	60/38-10788-8A98E3F4; Fri, 17 Feb 2012 17:08:56 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16659 invoked from network); 17 Feb 2012 17:08:55 -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;
	17 Feb 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198921"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-1e;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:37 +0000
Message-ID: <1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 03/11] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIp-0007MX-LM; Fri, 17 Feb 2012 17:08:59 +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 1RyRIo-0007Ll-LX
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:58 +0000
Received: from [85.158.139.83:48808] by server-4.bemta-5.messagelabs.com id
	60/38-10788-8A98E3F4; Fri, 17 Feb 2012 17:08:56 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16659 invoked from network); 17 Feb 2012 17:08:55 -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;
	17 Feb 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198921"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-1e;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:37 +0000
Message-ID: <1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 03/11] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIn-0007M1-Sp; Fri, 17 Feb 2012 17:08: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 1RyRIm-0007Lf-6q
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:56 +0000
Received: from [85.158.139.83:38480] by server-10.bemta-5.messagelabs.com id
	1D/6A-07861-7A98E3F4; Fri, 17 Feb 2012 17:08:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16650 invoked from network); 17 Feb 2012 17:08:54 -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;
	17 Feb 2012 17:08:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIh-0001tz-VV;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:35 +0000
Message-ID: <1329498525-8454-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 01/11] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..943106a 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIn-0007M1-Sp; Fri, 17 Feb 2012 17:08: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 1RyRIm-0007Lf-6q
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:56 +0000
Received: from [85.158.139.83:38480] by server-10.bemta-5.messagelabs.com id
	1D/6A-07861-7A98E3F4; Fri, 17 Feb 2012 17:08:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16650 invoked from network); 17 Feb 2012 17:08:54 -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;
	17 Feb 2012 17:08:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIh-0001tz-VV;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:35 +0000
Message-ID: <1329498525-8454-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 01/11] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..943106a 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIp-0007MM-9C; Fri, 17 Feb 2012 17:08:59 +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 1RyRIn-0007Ly-LX
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:57 +0000
Received: from [85.158.139.83:48849] by server-2.bemta-5.messagelabs.com id
	B8/F6-20263-8A98E3F4; Fri, 17 Feb 2012 17:08:56 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16671 invoked from network); 17 Feb 2012 17:08:56 -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;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198922"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIh-0001tz-Uo;
	Fri, 17 Feb 2012 17:08:51 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:34 +0000
Message-ID: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change since the previous set:
  - few fix and rebased on master
  - remove of the power management capability, keep the minimum like if it is
    always desactivated.
  - new patch: port of patch from the qemu-xen fork.


Change v5-v6:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.


Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property





Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Shan Haitao (1):
  xen passthrough: clean up MSI-X table handling

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 +++++
 hw/host-pci-device.h                 |   75 ++
 hw/pci.c                             |   47 +
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  898 ++++++++++++++++
 hw/xen_pci_passthrough.h             |  308 ++++++
 hw/xen_pci_passthrough_config_init.c | 1914 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  618 +++++++++++
 xen-all.c                            |   12 +
 16 files changed, 4221 insertions(+), 11 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIp-0007MM-9C; Fri, 17 Feb 2012 17:08:59 +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 1RyRIn-0007Ly-LX
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:08:57 +0000
Received: from [85.158.139.83:48849] by server-2.bemta-5.messagelabs.com id
	B8/F6-20263-8A98E3F4; Fri, 17 Feb 2012 17:08:56 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16671 invoked from network); 17 Feb 2012 17:08:56 -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;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198922"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIh-0001tz-Uo;
	Fri, 17 Feb 2012 17:08:51 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:34 +0000
Message-ID: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change since the previous set:
  - few fix and rebased on master
  - remove of the power management capability, keep the minimum like if it is
    always desactivated.
  - new patch: port of patch from the qemu-xen fork.


Change v5-v6:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.


Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property





Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Shan Haitao (1):
  xen passthrough: clean up MSI-X table handling

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 +++++
 hw/host-pci-device.h                 |   75 ++
 hw/pci.c                             |   47 +
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  898 ++++++++++++++++
 hw/xen_pci_passthrough.h             |  308 ++++++
 hw/xen_pci_passthrough_config_init.c | 1914 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  618 +++++++++++
 xen-all.c                            |   12 +
 16 files changed, 4221 insertions(+), 11 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIv-0007Os-N0; Fri, 17 Feb 2012 17:09:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIu-0007MG-2X
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329498535!13843596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29577 invoked from network); 17 Feb 2012 17:08:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423424"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-7F;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:42 +0000
Message-ID: <1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   10 +
 hw/xen_pci_passthrough.h             |    2 +
 hw/xen_pci_passthrough_config_init.c | 1431 ++++++++++++++++++++++++++++++++++
 3 files changed, 1443 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 3f305dd..26a3bdd 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(d, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(d, "no pin interrupt\n");
@@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index ea6719c..7ebc793 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -61,6 +61,8 @@ typedef int (*conf_byte_read)
 #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
 #define PT_PCI_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..f1fffd1 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,1442 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                int j = 0;
+                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIv-0007Os-N0; Fri, 17 Feb 2012 17:09:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIu-0007MG-2X
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:04 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329498535!13843596!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29577 invoked from network); 17 Feb 2012 17:08:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423424"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-7F;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:42 +0000
Message-ID: <1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   10 +
 hw/xen_pci_passthrough.h             |    2 +
 hw/xen_pci_passthrough_config_init.c | 1431 ++++++++++++++++++++++++++++++++++
 3 files changed, 1443 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 3f305dd..26a3bdd 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(d, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(d, "no pin interrupt\n");
@@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index ea6719c..7ebc793 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -61,6 +61,8 @@ typedef int (*conf_byte_read)
 #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
 #define PT_PCI_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..f1fffd1 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,1442 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                int j = 0;
+                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIr-0007Mt-2Z; Fri, 17 Feb 2012 17:09:01 +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 1RyRIp-0007ML-Kx
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:00 +0000
Received: from [85.158.139.83:48958] by server-1.bemta-5.messagelabs.com id
	F1/73-28458-AA98E3F4; Fri, 17 Feb 2012 17:08:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16687 invoked from network); 17 Feb 2012 17:08:56 -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;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198924"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-6T;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:41 +0000
Message-ID: <1329498525-8454-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 07/11] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  814 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  251 +++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1093 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 5098299..f7c5ce7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -224,6 +224,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..3f305dd
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,814 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+uint8_t mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0-Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (addr & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, addr, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#"PRIx64" maddr=%#"PRIx64
+           " len=%#"PRIx64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.maddr, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#04"PRIx64" pio_base=%#04"PRIx64
+           " len=%"PRId64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.pio_base, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_ADD_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &d->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+        return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = pci_get_bar_addr(d, bar);
+
+    /* need unmapping in case I/O Space or Memory Space is disabled */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    /* or ROM address is disabled. */
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(d, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as bar_read function */
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].e_physbase = r->base_addr;
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->flags & IORESOURCE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->flags & IORESOURCE_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]);
+
+        PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64" type: %#x)\n",
+               i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type & PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                          s->bases[i].e_physbase,
+                                          s->bases[i].access.pio_base,
+                                          e_size,
+                                          DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        } else {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, d->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+           bus, slot, func);
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            PT_ERR(d, "unbinding of interrupt INT%c failed."
+                   " (machine irq: %i, rc: %d)"
+                   " But bravely continuing on..\n",
+                   'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                       " But bravely continuing on..\n",
+                       machine_irq, rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pt_initfn;
+    k->exit = pt_unregister_device;
+    k->config_read = pt_pci_read_config;
+    k->config_write = pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..ea6719c
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,251 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index fd39168..e83ba2b 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1013,3 +1013,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIr-0007Mt-2Z; Fri, 17 Feb 2012 17:09:01 +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 1RyRIp-0007ML-Kx
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:00 +0000
Received: from [85.158.139.83:48958] by server-1.bemta-5.messagelabs.com id
	F1/73-28458-AA98E3F4; Fri, 17 Feb 2012 17:08:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329498533!8109414!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16687 invoked from network); 17 Feb 2012 17:08:56 -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;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198924"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-6T;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:41 +0000
Message-ID: <1329498525-8454-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 07/11] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  814 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  251 +++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1093 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 5098299..f7c5ce7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -224,6 +224,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..3f305dd
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,814 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+uint8_t mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0-Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (addr & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, addr, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#"PRIx64" maddr=%#"PRIx64
+           " len=%#"PRIx64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.maddr, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size)
+{
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int rc = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "BAR %i, e_phys=%#04"PRIx64" pio_base=%#04"PRIx64
+           " len=%"PRId64" first_map=%d\n",
+           i, e_phys, s->bases[i].access.pio_base, e_size, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_REMOVE_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                      s->bases[i].access.pio_base, e_size,
+                                      DPCI_ADD_MAPPING);
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &d->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+        return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = pci_get_bar_addr(d, bar);
+
+    /* need unmapping in case I/O Space or Memory Space is disabled */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    /* or ROM address is disabled. */
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(d, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice *d = o;
+    /* Same comment as bar_read function */
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].e_physbase = r->base_addr;
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->flags & IORESOURCE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->flags & IORESOURCE_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]);
+
+        PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64" type: %#x)\n",
+               i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type & PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                          s->bases[i].e_physbase,
+                                          s->bases[i].access.pio_base,
+                                          e_size,
+                                          DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        } else {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, d->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+           bus, slot, func);
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            PT_ERR(d, "unbinding of interrupt INT%c failed."
+                   " (machine irq: %i, rc: %d)"
+                   " But bravely continuing on..\n",
+                   'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                       " But bravely continuing on..\n",
+                       machine_irq, rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pt_initfn;
+    k->exit = pt_unregister_device;
+    k->config_read = pt_pci_read_config;
+    k->config_write = pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..ea6719c
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,251 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index fd39168..e83ba2b 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1013,3 +1013,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIv-0007Ob-8k; Fri, 17 Feb 2012 17:09:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIt-0007M0-4r
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:03 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329498533!13621317!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28897 invoked from network); 17 Feb 2012 17:08:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423419"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-3x;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:39 +0000
Message-ID: <1329498525-8454-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 05/11] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 651500e..5098299 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -222,6 +222,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 1);
+    if (rc == 0) {
+        *p = buf;
+    }
+    return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 2);
+    if (rc == 0) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 4);
+    if (rc == 0) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+    return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIv-0007Ob-8k; Fri, 17 Feb 2012 17:09:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIt-0007M0-4r
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:03 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329498533!13621317!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28897 invoked from network); 17 Feb 2012 17:08:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423419"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-3x;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:39 +0000
Message-ID: <1329498525-8454-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 05/11] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 651500e..5098299 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -222,6 +222,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 1);
+    if (rc == 0) {
+        *p = buf;
+    }
+    return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 2);
+    if (rc == 0) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 4);
+    if (rc == 0) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+    return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIu-0007O8-FI; Fri, 17 Feb 2012 17:09:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIs-0007Lx-8w
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329498533!13621317!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28884 invoked from network); 17 Feb 2012 17:08:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-4Z;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:40 +0000
Message-ID: <1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 06/11] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function helps Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 678a8c1..75d6529 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1985,6 +1985,53 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
     return dev->bus->address_space_io;
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type & PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type & PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
+
 static void pci_device_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/hw/pci.h b/hw/pci.h
index 33b0b18..f05fda5 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -566,4 +566,7 @@ extern const VMStateDescription vmstate_pci_device;
     .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIu-0007O8-FI; Fri, 17 Feb 2012 17:09:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIs-0007Lx-8w
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329498533!13621317!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28884 invoked from network); 17 Feb 2012 17:08:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423418"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-4Z;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:40 +0000
Message-ID: <1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 06/11] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function helps Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 678a8c1..75d6529 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1985,6 +1985,53 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
     return dev->bus->address_space_io;
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type & PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type & PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
+
 static void pci_device_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/hw/pci.h b/hw/pci.h
index 33b0b18..f05fda5 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -566,4 +566,7 @@ extern const VMStateDescription vmstate_pci_device;
     .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIt-0007Na-2M; Fri, 17 Feb 2012 17:09:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIr-0007Lk-D8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:01 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329498533!13621317!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28855 invoked from network); 17 Feb 2012 17:08:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423417"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-3P;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:38 +0000
Message-ID: <1329498525-8454-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 04/11] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 68f9ee6..e2c8d3f 100755
--- a/configure
+++ b/configure
@@ -132,6 +132,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -657,6 +658,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1005,6 +1010,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1458,6 +1465,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3592,6 +3614,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIt-0007Na-2M; Fri, 17 Feb 2012 17:09:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIr-0007Lk-D8
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:01 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329498533!13621317!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28855 invoked from network); 17 Feb 2012 17:08:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182423417"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:52 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-3P;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:38 +0000
Message-ID: <1329498525-8454-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 04/11] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 68f9ee6..e2c8d3f 100755
--- a/configure
+++ b/configure
@@ -132,6 +132,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -657,6 +658,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1005,6 +1010,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1458,6 +1465,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3592,6 +3614,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIu-0007OQ-SS; Fri, 17 Feb 2012 17:09:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIs-0007Lz-K1
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329498534!13835194!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2365 invoked from network); 17 Feb 2012 17:08:56 -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;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198923"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:53 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-7z;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:43 +0000
Message-ID: <1329498525-8454-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 09/11] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index ff9d24e..f9a73a8 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 static APICCommonState *local_apics[MAX_APICS + 1];
 
 static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRIu-0007OQ-SS; Fri, 17 Feb 2012 17:09:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRIs-0007Lz-K1
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329498534!13835194!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2365 invoked from network); 17 Feb 2012 17:08:56 -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;
	17 Feb 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22198923"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:08:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:08:53 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-7z;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:43 +0000
Message-ID: <1329498525-8454-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 09/11] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index ff9d24e..f9a73a8 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 static APICCommonState *local_apics[MAX_APICS + 1];
 
 static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRJ1-0007To-DJ; Fri, 17 Feb 2012 17:09:11 +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 1RyRIz-0007Rq-Ei
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329498508!52905090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6044 invoked from network); 17 Feb 2012 17:08: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;
	17 Feb 2012 17:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10779793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 17:09:08 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 17 Feb 2012
	17:09:08 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 17:09:06 +0000
Thread-Topic: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
Thread-Index: AcztkXzAwqTPk/IjSt+O/PPv3a/jGAABGjeg
Message-ID: <291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
	<91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IIRC Windows (7) calibrates tsc against RTC at start of day and you can get some pretty odd results if a vcpu is descheduled during that calculation. I was not aware of the exact scenario you described. You *can* get the equivalent of the /usepmtimer boot.ini option on more recent OS by doing:

bcdedit /set useplatformclock true

Enabling viridian timers in Xen may be the way to go though.

  Paul

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
> Sent: 17 February 2012 16:28
> To: xen-devel@lists.xensource.com
> Cc: Ian Campbell; Qrux
> Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
> 
> > Date: Fri, 17 Feb 2012 12:06:05 +0000
> > From: Ian Campbell <Ian.Campbell@citrix.com>
> > To: Qrux <qrux.qed@gmail.com>
> > Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> > Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
> > Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > I'm afraid I don't know the answer to most of your questions (hence
> > I'm afraid I've trimmed the quotes rather aggressively) but here's
> > some of what I do know.
> 
> I'm gonna add another data point.
> 
> We're seeing the Windows 7 Query Performance Counter get mightily
> confused. People have reported this in Amazon EC2 as well
> https://forums.aws.amazon.com/thread.jspa?threadID=41426
> 
> We've tracked it down to the hpet. Xen schedules an interrupt delivery for
> an hpet tick, but the vcpu is asleep. Could be an admin pause, a sleep on a
> wait queue, paused while qemu does its thing, paused while a mem event is
> processed...
> 
> When the vcpu wakes up it receives the "late" hpet tick. We believe
> Windows 7 QPC also reads the TSC at that point. The TSC kept on ticking
> while the vcpu was paused. Windows does not know what to do about the
> discrepancy and reports a large time leap, usually consistent with a full
> round trip of the 32 bit hpet counter at the Xen-emulated 1/16GHz
> frequency.
> 
> MSDN forums blame "bad hardware" for this. Funny.
> 
> So, we could solve our particular problem if the tsc were not to tick during
> vcpu sleep. And I get an inkling that would help with this post as well. But I
> don't think any of the advertised timer or tsc modes do that.
> 
> Thanks,
> Andres
> 
> 
> 
> I'm not sure this will help with the original post, but there's gotta be
> somebody who
> >
> >> But, practically, is there a safe CPU configuration?
> >
> > I think that part of the problem here is that it is very hard to
> > determine this at the hardware level. There are at least 3 (if not
> > more) CPUID feature bits which say "no really, the TSC is good and
> > safe to use this time, you can rely on that" because they keep
> > inventing new ways to get it wrong.
> >
> > [...]
> >>
> >> Since September, I can't find any further information about this
> >> issue. What is the state of this issue?  The inconsistency I see
> >> right now is this: in the July 2010 TSC discussion, a "Stefano Stabellini"
> >> posted this:
> >>
> >> ====
> >> > /me wonders if timer_mode=1 is the default for xl?
> >> > Or only for xm?
> >>
> >> no, it is not.
> >> Xl defaults to 0 [zero], I am going to change it right now.
> >> ====
> >>
> >> So, it seems like (at least as of July 2010), xl is defaulting to
> >> "timer_mode=1".  That is, assuming that the then-current timer_mode
> >> is the same as present-day tsc_mode.
> >
> > No, I believe they are different things.
> >
> > tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
> > xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)
> >
> > timer_mode is to do with the the way that timer interrupts are
> > injected into the guest. This is described in
> xen/include/public/hvm/params.h.
> > This isn't documented in xl.cfg(5) because I couldn't make head nor
> > tail of the meaning of that header :-(
> >
> >>   In addition, I'm assuming he was changing it from 0 (zero) to 1
> >> (one)--and not some other mode.  But,
> >>
> >>         xen-4.1.2/docs/misc/tscmode.txt
> >
> > Remember that he was referring to timer_mode not tsc_mode...
> >
> >> says:
> >>
> >>         "The default mode (tsc_mode==0) checks TSC-safeness of the
> >> underlying
> >>         hardware on which the virtual machine is launched.  If it is
> >>         TSC-safe, rdtsc will execute at hardware speed; if it is not,
> >> rdtsc
> >>         will be emulated."
> >>
> >> Which implies the default is always 0 (zero).  Which is it?
> >
> > It seems that xl, in xen-unstable, defaults to:
> > 	timer_mode = 1
> > 	tsc_mode = 0
> > as does 4.1 as far as I can tell via code inspection.
> >
> >> More importantly, is the solution to force tsc_mode=2?
> >
> > IMHO this is safe in most situations unless you are running some sort
> > of workload (e.g. a well known database) which has stringent
> > requirements regarding the TSC for transactional consistency (hence
> > the conservative default).
> >
> >>   If so, under what BIOS/xen-boot-params/dom0-boot-params
> conditions?
> >> And--please excuse my exasperation--but WTH does this have to do with
> >> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
> >> "jumpiness" (if that's even what's happening)?
> >
> > Sorry, I have no idea how/why the filesystem would be related to the
> > TSC.
> >
> > It is possible you are actually seeing two bugs I suppose -- there
> > have been issues relating to ext4 and barriers in some kernel versions
> > (I'm afraid I don't recall the details, the list archives ought to
> > contain something).
> >
> > Ian.
> >
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:09:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:09:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRJ1-0007To-DJ; Fri, 17 Feb 2012 17:09:11 +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 1RyRIz-0007Rq-Ei
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:09:09 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329498508!52905090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6044 invoked from network); 17 Feb 2012 17:08: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;
	17 Feb 2012 17:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10779793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 17:09:08 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 17 Feb 2012
	17:09:08 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 17:09:06 +0000
Thread-Topic: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
Thread-Index: AcztkXzAwqTPk/IjSt+O/PPv3a/jGAABGjeg
Message-ID: <291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
	<91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IIRC Windows (7) calibrates tsc against RTC at start of day and you can get some pretty odd results if a vcpu is descheduled during that calculation. I was not aware of the exact scenario you described. You *can* get the equivalent of the /usepmtimer boot.ini option on more recent OS by doing:

bcdedit /set useplatformclock true

Enabling viridian timers in Xen may be the way to go though.

  Paul

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
> Sent: 17 February 2012 16:28
> To: xen-devel@lists.xensource.com
> Cc: Ian Campbell; Qrux
> Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
> 
> > Date: Fri, 17 Feb 2012 12:06:05 +0000
> > From: Ian Campbell <Ian.Campbell@citrix.com>
> > To: Qrux <qrux.qed@gmail.com>
> > Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> > Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
> > Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > I'm afraid I don't know the answer to most of your questions (hence
> > I'm afraid I've trimmed the quotes rather aggressively) but here's
> > some of what I do know.
> 
> I'm gonna add another data point.
> 
> We're seeing the Windows 7 Query Performance Counter get mightily
> confused. People have reported this in Amazon EC2 as well
> https://forums.aws.amazon.com/thread.jspa?threadID=41426
> 
> We've tracked it down to the hpet. Xen schedules an interrupt delivery for
> an hpet tick, but the vcpu is asleep. Could be an admin pause, a sleep on a
> wait queue, paused while qemu does its thing, paused while a mem event is
> processed...
> 
> When the vcpu wakes up it receives the "late" hpet tick. We believe
> Windows 7 QPC also reads the TSC at that point. The TSC kept on ticking
> while the vcpu was paused. Windows does not know what to do about the
> discrepancy and reports a large time leap, usually consistent with a full
> round trip of the 32 bit hpet counter at the Xen-emulated 1/16GHz
> frequency.
> 
> MSDN forums blame "bad hardware" for this. Funny.
> 
> So, we could solve our particular problem if the tsc were not to tick during
> vcpu sleep. And I get an inkling that would help with this post as well. But I
> don't think any of the advertised timer or tsc modes do that.
> 
> Thanks,
> Andres
> 
> 
> 
> I'm not sure this will help with the original post, but there's gotta be
> somebody who
> >
> >> But, practically, is there a safe CPU configuration?
> >
> > I think that part of the problem here is that it is very hard to
> > determine this at the hardware level. There are at least 3 (if not
> > more) CPUID feature bits which say "no really, the TSC is good and
> > safe to use this time, you can rely on that" because they keep
> > inventing new ways to get it wrong.
> >
> > [...]
> >>
> >> Since September, I can't find any further information about this
> >> issue. What is the state of this issue?  The inconsistency I see
> >> right now is this: in the July 2010 TSC discussion, a "Stefano Stabellini"
> >> posted this:
> >>
> >> ====
> >> > /me wonders if timer_mode=1 is the default for xl?
> >> > Or only for xm?
> >>
> >> no, it is not.
> >> Xl defaults to 0 [zero], I am going to change it right now.
> >> ====
> >>
> >> So, it seems like (at least as of July 2010), xl is defaulting to
> >> "timer_mode=1".  That is, assuming that the then-current timer_mode
> >> is the same as present-day tsc_mode.
> >
> > No, I believe they are different things.
> >
> > tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
> > xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)
> >
> > timer_mode is to do with the the way that timer interrupts are
> > injected into the guest. This is described in
> xen/include/public/hvm/params.h.
> > This isn't documented in xl.cfg(5) because I couldn't make head nor
> > tail of the meaning of that header :-(
> >
> >>   In addition, I'm assuming he was changing it from 0 (zero) to 1
> >> (one)--and not some other mode.  But,
> >>
> >>         xen-4.1.2/docs/misc/tscmode.txt
> >
> > Remember that he was referring to timer_mode not tsc_mode...
> >
> >> says:
> >>
> >>         "The default mode (tsc_mode==0) checks TSC-safeness of the
> >> underlying
> >>         hardware on which the virtual machine is launched.  If it is
> >>         TSC-safe, rdtsc will execute at hardware speed; if it is not,
> >> rdtsc
> >>         will be emulated."
> >>
> >> Which implies the default is always 0 (zero).  Which is it?
> >
> > It seems that xl, in xen-unstable, defaults to:
> > 	timer_mode = 1
> > 	tsc_mode = 0
> > as does 4.1 as far as I can tell via code inspection.
> >
> >> More importantly, is the solution to force tsc_mode=2?
> >
> > IMHO this is safe in most situations unless you are running some sort
> > of workload (e.g. a well known database) which has stringent
> > requirements regarding the TSC for transactional consistency (hence
> > the conservative default).
> >
> >>   If so, under what BIOS/xen-boot-params/dom0-boot-params
> conditions?
> >> And--please excuse my exasperation--but WTH does this have to do with
> >> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
> >> "jumpiness" (if that's even what's happening)?
> >
> > Sorry, I have no idea how/why the filesystem would be related to the
> > TSC.
> >
> > It is possible you are actually seeing two bugs I suppose -- there
> > have been issues relating to ext4 and barriers in some kernel versions
> > (I'm afraid I don't recall the details, the list archives ought to
> > contain something).
> >
> > Ian.
> >
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:13:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRN7-0000L7-50; Fri, 17 Feb 2012 17:13:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyRN6-0000KI-Cw
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:13:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329498798!13765289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9357 invoked from network); 17 Feb 2012 17:13:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10779896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 17:13:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 17:13:17 +0000
Message-ID: <1329498796.3131.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 17 Feb 2012 17:13:16 +0000
In-Reply-To: <1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> diff --git a/config/arm.mk b/config/arm.mk
> index f64f0c1..f20fd2d 100644
> --- a/config/arm.mk
> +++ b/config/arm.mk
> @@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
>  
>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> +
> +# XXX: When running on the model there is no bootloader to provide a
> +# device tree.  It must be linked into Xen.
> +ifndef CONFIG_DTB_FILE
> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a
> DTB)
> +endif 

This turns out to be a little aggressive -- it also triggers when you
are building the tools. Not a big deal, but a bit annoying, is there
some way we can avoid this? Put it in xen/arch/arm/Foo perhaps?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:13:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRN7-0000L7-50; Fri, 17 Feb 2012 17:13:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RyRN6-0000KI-Cw
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:13:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329498798!13765289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9357 invoked from network); 17 Feb 2012 17:13:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10779896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 17:13:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 17:13:17 +0000
Message-ID: <1329498796.3131.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 17 Feb 2012 17:13:16 +0000
In-Reply-To: <1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> diff --git a/config/arm.mk b/config/arm.mk
> index f64f0c1..f20fd2d 100644
> --- a/config/arm.mk
> +++ b/config/arm.mk
> @@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
>  
>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> +
> +# XXX: When running on the model there is no bootloader to provide a
> +# device tree.  It must be linked into Xen.
> +ifndef CONFIG_DTB_FILE
> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a
> DTB)
> +endif 

This turns out to be a little aggressive -- it also triggers when you
are building the tools. Not a big deal, but a bit annoying, is there
some way we can avoid this? Put it in xen/arch/arm/Foo perhaps?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:18:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRSA-0000n8-UZ; Fri, 17 Feb 2012 17:18:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRS8-0000lF-PT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:18:37 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329499107!13844442!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23997 invoked from network); 17 Feb 2012 17:18:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:18:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22199163"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:18:26 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:18:26 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-Kw;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:44 +0000
Message-ID: <1329498525-8454-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 10/11] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   32 ++
 hw/xen_pci_passthrough.h             |   48 +++
 hw/xen_pci_passthrough_config_init.c |  472 ++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  664 ++++++++++++++++++++++++++++++++++
 6 files changed, 1219 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index f7c5ce7..fdaf518 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -226,6 +226,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 26a3bdd..6ea2c45 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -362,6 +376,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         rc = xc_domain_memory_mapping(xen_xc, xen_domid,
                                old_ebase >> XC_PAGE_SHIFT,
@@ -386,6 +401,16 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (rc) {
             PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
         }
+
+        rc = pt_remove_msix_mapping(s, i);
+        if (rc != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
+                   rc);
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -766,6 +791,13 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 7ebc793..3d41e04 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -162,6 +162,37 @@ typedef struct XenPTRegGroup {
 
 
 #define PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -174,6 +205,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 };
@@ -250,4 +284,18 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index f1fffd1..1323ef6 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1067,6 +1067,411 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            PT_LOG(&s->dev, "setup MSI\n");
+            if (pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *value &= ~PCI_MSI_FLAGS_ENABLE;
+    *value |= val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev,
+               "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        PT_LOG(&s->dev, "%s MSI-X\n",
+               s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1160,6 +1565,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1200,6 +1648,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1244,6 +1700,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1428,6 +1892,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..e848c61
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,664 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    host_pci_set_word(s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int *ppirq,
+                           bool is_msix,
+                           int msix_entry,
+                           bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                   " (vec: %#x, entry: %#x)\n",
+                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                   is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: %#x)\n",
+           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+               is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                   is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+               is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+               is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        PT_ERR(&s->dev,
+               "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
+        + PCI_MSIX_ENTRY_VECTOR_CTRL;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                   "enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr,
+            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    return get_entry_value(&msix->msix_entry[entry_nr], offset);
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, false);
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+           >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+           >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(msix && msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, true);
+
+    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+             >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *hd = s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "passthrough-msix",
+                          total_entries * PCI_MSIX_ENTRY_SIZE);
+
+    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
+
+    memory_region_transaction_begin();
+    memory_region_add_subregion_overlap(&s->bar[bar_index], msix->table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+    memory_region_set_enabled(&msix->mmio, false);
+    memory_region_transaction_commit();
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+               msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:18:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:18:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyRSA-0000n8-UZ; Fri, 17 Feb 2012 17:18:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRS8-0000lF-PT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:18:37 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329499107!13844442!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjEwNDg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23997 invoked from network); 17 Feb 2012 17:18:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:18:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="22199163"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:18:26 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:18:26 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIi-0001tz-Kw;
	Fri, 17 Feb 2012 17:08:52 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:44 +0000
Message-ID: <1329498525-8454-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 10/11] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   32 ++
 hw/xen_pci_passthrough.h             |   48 +++
 hw/xen_pci_passthrough_config_init.c |  472 ++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  664 ++++++++++++++++++++++++++++++++++
 6 files changed, 1219 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index f7c5ce7..fdaf518 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -226,6 +226,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 26a3bdd..6ea2c45 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -362,6 +376,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         rc = xc_domain_memory_mapping(xen_xc, xen_domid,
                                old_ebase >> XC_PAGE_SHIFT,
@@ -386,6 +401,16 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (rc) {
             PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
         }
+
+        rc = pt_remove_msix_mapping(s, i);
+        if (rc != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
+                   rc);
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -766,6 +791,13 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 7ebc793..3d41e04 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -162,6 +162,37 @@ typedef struct XenPTRegGroup {
 
 
 #define PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -174,6 +205,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 };
@@ -250,4 +284,18 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index f1fffd1..1323ef6 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1067,6 +1067,411 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            PT_LOG(&s->dev, "setup MSI\n");
+            if (pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *value &= ~PCI_MSI_FLAGS_ENABLE;
+    *value |= val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev,
+               "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        PT_LOG(&s->dev, "%s MSI-X\n",
+               s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1160,6 +1565,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1200,6 +1648,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1244,6 +1700,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1428,6 +1892,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..e848c61
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,664 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    host_pci_set_word(s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int *ppirq,
+                           bool is_msix,
+                           int msix_entry,
+                           bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                   " (vec: %#x, entry: %#x)\n",
+                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                   is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: %#x)\n",
+           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+               is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                   is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+               is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+               is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        PT_ERR(&s->dev,
+               "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
+        + PCI_MSIX_ENTRY_VECTOR_CTRL;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                   "enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr,
+            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    return get_entry_value(&msix->msix_entry[entry_nr], offset);
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, false);
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+           >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+           >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!(msix && msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    memory_region_set_enabled(&msix->mmio, true);
+
+    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
+             >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *hd = s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "passthrough-msix",
+                          total_entries * PCI_MSIX_ENTRY_SIZE);
+
+    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
+
+    memory_region_transaction_begin();
+    memory_region_add_subregion_overlap(&s->bar[bar_index], msix->table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+    memory_region_set_enabled(&msix->mmio, false);
+    memory_region_transaction_commit();
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+               msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:18:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRSL-0000oR-Gz; Fri, 17 Feb 2012 17:18:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRSK-0000nu-Vd
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:18:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329499108!3284314!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2550 invoked from network); 17 Feb 2012 17:18:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:18:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182424737"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:18:27 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:18:27 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIj-0001tz-12;
	Fri, 17 Feb 2012 17:08:53 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:45 +0000
Message-ID: <1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Shan Haitao <maillists.shan@gmail.com>,
	Xen Devel <xen-devel@lists.xensource.com>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 11/11] xen passthrough: clean up MSI-X table
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Shan Haitao <maillists.shan@gmail.com>

This patch does cleaning up of QEMU MSI handling. The fixes are:
1. Changes made to MSI-X table mapping handling to eliminate the small
windows in which guest could have access to physical MSI-X table.
2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
already in Xen now.
3. For registers that coexists inside the MSI-X table (this could be
only PBA I think), value read from physical page would be returned.

Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>

Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c     |   80 ++++++++++++++++++++++++++++++++----------
 hw/xen_pci_passthrough.h     |   11 +++++-
 hw/xen_pci_passthrough_msi.c |   62 ++++----------------------------
 3 files changed, 78 insertions(+), 75 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 6ea2c45..fab9fbe 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -356,6 +356,53 @@ out:
     }
 }
 
+static int pt_iomem_helper(XenPCIPassthroughState *s, int i,
+                           pcibus_t e_base, pcibus_t e_size, int op)
+{
+    uint64_t msix_last_pfn = 0;
+    pcibus_t bar_last_pfn = 0;
+    pcibus_t msix_table_size = 0;
+    XenPTMSIX *msix = s->msix;
+    int rc = 0;
+
+    if (!pt_has_msix_mapping(s, i)) {
+        return xc_domain_memory_mapping(xen_xc, xen_domid,
+                                        PFN(e_base),
+                                        PFN(s->bases[i].access.maddr),
+                                        PFN(e_size + XC_PAGE_SIZE - 1),
+                                        op);
+
+    }
+
+    if (msix->table_off) {
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      PFN(e_base),
+                                      PFN(s->bases[i].access.maddr),
+                                      PFN(msix->mmio_base_addr) - PFN(e_base),
+                                      op);
+    }
+
+    msix_table_size = msix->total_entries * PCI_MSIX_ENTRY_SIZE;
+    msix_last_pfn = PFN(msix->mmio_base_addr + msix_table_size - 1);
+    bar_last_pfn = PFN(e_base + e_size - 1);
+
+    if (rc == 0 && msix_last_pfn != bar_last_pfn) {
+        assert(msix_last_pfn < bar_last_pfn);
+
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      msix_last_pfn + 1,
+                                      PFN(s->bases[i].access.maddr
+                                          + msix->table_off
+                                          + msix_table_size
+                                          + XC_PAGE_SIZE - 1),
+                                      bar_last_pfn - msix_last_pfn,
+                                      op);
+    }
+
+    return rc;
+}
+
+
 /* ioport/iomem space*/
 static void pt_iomem_map(XenPCIPassthroughState *s, int i,
                          pcibus_t e_phys, pcibus_t e_size)
@@ -376,13 +423,10 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
-        pt_add_msix_mapping(s, i);
-        /* Remove old mapping */
-        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
-                               old_ebase >> XC_PAGE_SHIFT,
-                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
-                               DPCI_REMOVE_MAPPING);
+        if (pt_has_msix_mapping(s, i)) {
+            memory_region_set_enabled(&s->msix->mmio, false);
+        }
+        rc = pt_iomem_helper(s, i, old_ebase, e_size, DPCI_REMOVE_MAPPING);
         if (rc) {
             PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
             return;
@@ -391,21 +435,19 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
 
     /* map only valid guest address */
     if (e_phys != PCI_BAR_UNMAPPED) {
-        /* Create new mapping */
-        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
-                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
-                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
-                                   DPCI_ADD_MAPPING);
+        if (pt_has_msix_mapping(s, i)) {
+            XenPTMSIX *msix = s->msix;
 
-        if (rc) {
-            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+            msix->mmio_base_addr = s->bases[i].e_physbase + msix->table_off;
+
+            memory_region_set_enabled(&msix->mmio, true);
         }
 
-        rc = pt_remove_msix_mapping(s, i);
-        if (rc != 0) {
-            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
-                   rc);
+        rc = pt_iomem_helper(s, i, e_phys, e_size, DPCI_ADD_MAPPING);
+
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+            return;
         }
 
         if (old_ebase != e_phys && old_ebase != -1) {
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 3d41e04..f36e0d2 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -30,6 +30,9 @@ void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
 #endif
 
 
+/* Helper */
+#define PFN(x) ((x) >> XC_PAGE_SHIFT)
+
 typedef struct XenPTRegInfo XenPTRegInfo;
 typedef struct XenPTReg XenPTReg;
 
@@ -295,7 +298,11 @@ void pt_msix_delete(XenPCIPassthroughState *s);
 int pt_msix_update(XenPCIPassthroughState *s);
 int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
 void pt_msix_disable(XenPCIPassthroughState *s);
-int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
-int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
+static inline bool pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
 
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
index e848c61..e775d21 100644
--- a/hw/xen_pci_passthrough_msi.c
+++ b/hw/xen_pci_passthrough_msi.c
@@ -300,16 +300,6 @@ static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
                            enabled);
 }
 
-static void mask_physical_msix_entry(XenPCIPassthroughState *s,
-                                     int entry_nr, int mask)
-{
-    void *phys_off;
-
-    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
-        + PCI_MSIX_ENTRY_VECTOR_CTRL;
-    *(uint32_t *)phys_off = mask;
-}
-
 static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
 {
     XenPTMSIXEntry *entry = NULL;
@@ -480,8 +470,6 @@ static void pci_msix_write(void *opaque, target_phys_addr_t addr,
         if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
             pt_msix_update_one(s, entry_nr);
         }
-        mask_physical_msix_entry(s, entry_nr,
-            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
     }
 }
 
@@ -493,14 +481,19 @@ static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
     int entry_nr, offset;
 
     entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
-    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+    if (entry_nr < 0) {
         PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
         return 0;
     }
 
     offset = addr % PCI_MSIX_ENTRY_SIZE;
 
-    return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
 }
 
 static const MemoryRegionOps pci_msix_ops = {
@@ -514,45 +507,6 @@ static const MemoryRegionOps pci_msix_ops = {
     },
 };
 
-int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
-{
-    XenPTMSIX *msix = s->msix;
-
-    if (!(s->msix && s->msix->bar_index == bar_index)) {
-        return 0;
-    }
-
-    memory_region_set_enabled(&msix->mmio, false);
-    return xc_domain_memory_mapping(xen_xc, xen_domid,
-         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-         (s->bases[bar_index].access.maddr + s->msix->table_off)
-           >> XC_PAGE_SHIFT,
-         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
-           >> XC_PAGE_SHIFT,
-         DPCI_ADD_MAPPING);
-}
-
-int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
-{
-    XenPTMSIX *msix = s->msix;
-
-    if (!(msix && msix->bar_index == bar_index)) {
-        return 0;
-    }
-
-    memory_region_set_enabled(&msix->mmio, true);
-
-    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
-
-    return xc_domain_memory_mapping(xen_xc, xen_domid,
-         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-         (s->bases[bar_index].access.maddr + s->msix->table_off)
-             >> XC_PAGE_SHIFT,
-         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
-             >> XC_PAGE_SHIFT,
-         DPCI_REMOVE_MAPPING);
-}
-
 int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
 {
     uint8_t id = 0;
@@ -609,7 +563,7 @@ int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
     msix->phys_iomem_base =
         mmap(NULL,
              total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
-             PROT_WRITE | PROT_READ,
+             PROT_READ,
              MAP_SHARED | MAP_LOCKED,
              fd,
              msix->table_base + table_off - msix->table_offset_adjust);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:18:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRSL-0000oR-Gz; Fri, 17 Feb 2012 17:18:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RyRSK-0000nu-Vd
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:18:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329499108!3284314!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2550 invoked from network); 17 Feb 2012 17:18:29 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:18:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182424737"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:18:27 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 17 Feb 2012 12:18:27 -0500
Received: from [10.80.3.28] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1RyRIj-0001tz-12;
	Fri, 17 Feb 2012 17:08:53 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Fri, 17 Feb 2012 17:08:45 +0000
Message-ID: <1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Shan Haitao <maillists.shan@gmail.com>,
	Xen Devel <xen-devel@lists.xensource.com>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V7 11/11] xen passthrough: clean up MSI-X table
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Shan Haitao <maillists.shan@gmail.com>

This patch does cleaning up of QEMU MSI handling. The fixes are:
1. Changes made to MSI-X table mapping handling to eliminate the small
windows in which guest could have access to physical MSI-X table.
2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
already in Xen now.
3. For registers that coexists inside the MSI-X table (this could be
only PBA I think), value read from physical page would be returned.

Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>

Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c     |   80 ++++++++++++++++++++++++++++++++----------
 hw/xen_pci_passthrough.h     |   11 +++++-
 hw/xen_pci_passthrough_msi.c |   62 ++++----------------------------
 3 files changed, 78 insertions(+), 75 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 6ea2c45..fab9fbe 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -356,6 +356,53 @@ out:
     }
 }
 
+static int pt_iomem_helper(XenPCIPassthroughState *s, int i,
+                           pcibus_t e_base, pcibus_t e_size, int op)
+{
+    uint64_t msix_last_pfn = 0;
+    pcibus_t bar_last_pfn = 0;
+    pcibus_t msix_table_size = 0;
+    XenPTMSIX *msix = s->msix;
+    int rc = 0;
+
+    if (!pt_has_msix_mapping(s, i)) {
+        return xc_domain_memory_mapping(xen_xc, xen_domid,
+                                        PFN(e_base),
+                                        PFN(s->bases[i].access.maddr),
+                                        PFN(e_size + XC_PAGE_SIZE - 1),
+                                        op);
+
+    }
+
+    if (msix->table_off) {
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      PFN(e_base),
+                                      PFN(s->bases[i].access.maddr),
+                                      PFN(msix->mmio_base_addr) - PFN(e_base),
+                                      op);
+    }
+
+    msix_table_size = msix->total_entries * PCI_MSIX_ENTRY_SIZE;
+    msix_last_pfn = PFN(msix->mmio_base_addr + msix_table_size - 1);
+    bar_last_pfn = PFN(e_base + e_size - 1);
+
+    if (rc == 0 && msix_last_pfn != bar_last_pfn) {
+        assert(msix_last_pfn < bar_last_pfn);
+
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      msix_last_pfn + 1,
+                                      PFN(s->bases[i].access.maddr
+                                          + msix->table_off
+                                          + msix_table_size
+                                          + XC_PAGE_SIZE - 1),
+                                      bar_last_pfn - msix_last_pfn,
+                                      op);
+    }
+
+    return rc;
+}
+
+
 /* ioport/iomem space*/
 static void pt_iomem_map(XenPCIPassthroughState *s, int i,
                          pcibus_t e_phys, pcibus_t e_size)
@@ -376,13 +423,10 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
-        pt_add_msix_mapping(s, i);
-        /* Remove old mapping */
-        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
-                               old_ebase >> XC_PAGE_SHIFT,
-                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
-                               DPCI_REMOVE_MAPPING);
+        if (pt_has_msix_mapping(s, i)) {
+            memory_region_set_enabled(&s->msix->mmio, false);
+        }
+        rc = pt_iomem_helper(s, i, old_ebase, e_size, DPCI_REMOVE_MAPPING);
         if (rc) {
             PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
             return;
@@ -391,21 +435,19 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
 
     /* map only valid guest address */
     if (e_phys != PCI_BAR_UNMAPPED) {
-        /* Create new mapping */
-        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
-                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
-                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
-                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
-                                   DPCI_ADD_MAPPING);
+        if (pt_has_msix_mapping(s, i)) {
+            XenPTMSIX *msix = s->msix;
 
-        if (rc) {
-            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+            msix->mmio_base_addr = s->bases[i].e_physbase + msix->table_off;
+
+            memory_region_set_enabled(&msix->mmio, true);
         }
 
-        rc = pt_remove_msix_mapping(s, i);
-        if (rc != 0) {
-            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
-                   rc);
+        rc = pt_iomem_helper(s, i, e_phys, e_size, DPCI_ADD_MAPPING);
+
+        if (rc) {
+            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
+            return;
         }
 
         if (old_ebase != e_phys && old_ebase != -1) {
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 3d41e04..f36e0d2 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -30,6 +30,9 @@ void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
 #endif
 
 
+/* Helper */
+#define PFN(x) ((x) >> XC_PAGE_SHIFT)
+
 typedef struct XenPTRegInfo XenPTRegInfo;
 typedef struct XenPTReg XenPTReg;
 
@@ -295,7 +298,11 @@ void pt_msix_delete(XenPCIPassthroughState *s);
 int pt_msix_update(XenPCIPassthroughState *s);
 int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
 void pt_msix_disable(XenPCIPassthroughState *s);
-int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
-int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
+static inline bool pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
 
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
index e848c61..e775d21 100644
--- a/hw/xen_pci_passthrough_msi.c
+++ b/hw/xen_pci_passthrough_msi.c
@@ -300,16 +300,6 @@ static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
                            enabled);
 }
 
-static void mask_physical_msix_entry(XenPCIPassthroughState *s,
-                                     int entry_nr, int mask)
-{
-    void *phys_off;
-
-    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
-        + PCI_MSIX_ENTRY_VECTOR_CTRL;
-    *(uint32_t *)phys_off = mask;
-}
-
 static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
 {
     XenPTMSIXEntry *entry = NULL;
@@ -480,8 +470,6 @@ static void pci_msix_write(void *opaque, target_phys_addr_t addr,
         if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
             pt_msix_update_one(s, entry_nr);
         }
-        mask_physical_msix_entry(s, entry_nr,
-            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
     }
 }
 
@@ -493,14 +481,19 @@ static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
     int entry_nr, offset;
 
     entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
-    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+    if (entry_nr < 0) {
         PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
         return 0;
     }
 
     offset = addr % PCI_MSIX_ENTRY_SIZE;
 
-    return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
 }
 
 static const MemoryRegionOps pci_msix_ops = {
@@ -514,45 +507,6 @@ static const MemoryRegionOps pci_msix_ops = {
     },
 };
 
-int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
-{
-    XenPTMSIX *msix = s->msix;
-
-    if (!(s->msix && s->msix->bar_index == bar_index)) {
-        return 0;
-    }
-
-    memory_region_set_enabled(&msix->mmio, false);
-    return xc_domain_memory_mapping(xen_xc, xen_domid,
-         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-         (s->bases[bar_index].access.maddr + s->msix->table_off)
-           >> XC_PAGE_SHIFT,
-         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
-           >> XC_PAGE_SHIFT,
-         DPCI_ADD_MAPPING);
-}
-
-int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
-{
-    XenPTMSIX *msix = s->msix;
-
-    if (!(msix && msix->bar_index == bar_index)) {
-        return 0;
-    }
-
-    memory_region_set_enabled(&msix->mmio, true);
-
-    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
-
-    return xc_domain_memory_mapping(xen_xc, xen_domid,
-         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
-         (s->bases[bar_index].access.maddr + s->msix->table_off)
-             >> XC_PAGE_SHIFT,
-         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
-             >> XC_PAGE_SHIFT,
-         DPCI_REMOVE_MAPPING);
-}
-
 int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
 {
     uint8_t id = 0;
@@ -609,7 +563,7 @@ int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
     msix->phys_iomem_base =
         mmap(NULL,
              total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
-             PROT_WRITE | PROT_READ,
+             PROT_READ,
              MAP_SHARED | MAP_LOCKED,
              fd,
              msix->table_base + table_off - msix->table_offset_adjust);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:22:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyRWB-00017t-Cf; Fri, 17 Feb 2012 17:22:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RyRWA-00017l-E9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:22:46 +0000
Received: from [85.158.139.83:60064] by server-3.bemta-5.messagelabs.com id
	31/F0-06438-5EC8E3F4; Fri, 17 Feb 2012 17:22:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329499363!15479803!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10575 invoked from network); 17 Feb 2012 17:22:44 -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;
	17 Feb 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182425546"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:22:42 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	12:22:42 -0500
Message-ID: <4F3E8CE1.7030803@citrix.com>
Date: Fri, 17 Feb 2012 17:22:41 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>	
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
	<1329498796.3131.135.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329498796.3131.135.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/12 17:13, Ian Campbell wrote:
> On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
>> diff --git a/config/arm.mk b/config/arm.mk
>> index f64f0c1..f20fd2d 100644
>> --- a/config/arm.mk
>> +++ b/config/arm.mk
>> @@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
>>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
>>  
>>  CONFIG_LOAD_ADDRESS ?= 0x80000000
>> +
>> +# XXX: When running on the model there is no bootloader to provide a
>> +# device tree.  It must be linked into Xen.
>> +ifndef CONFIG_DTB_FILE
>> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a
>> DTB)
>> +endif 
> 
> This turns out to be a little aggressive -- it also triggers when you
> are building the tools. Not a big deal, but a bit annoying, is there
> some way we can avoid this? Put it in xen/arch/arm/Foo perhaps?

Does this do the right thing?

8<---------
arm: move check for CONFIG_DTB_FILE to xen/arch/arm/Makefile

CONFIG_DTB_FILE only needs to be set when building Xen itself.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 config/arm.mk         |    6 ------
 xen/arch/arm/Makefile |    4 ++++
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/config/arm.mk b/config/arm.mk
index f20fd2d..f64f0c1 100644
--- a/config/arm.mk
+++ b/config/arm.mk
@@ -16,9 +16,3 @@ LDFLAGS_DIRECT_Linux = _linux
 LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi

 CONFIG_LOAD_ADDRESS ?= 0x80000000
-
-# XXX: When running on the model there is no bootloader to provide a
-# device tree.  It must be linked into Xen.
-ifndef CONFIG_DTB_FILE
-$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
-endif
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 168716e..da9134b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -26,6 +26,10 @@ obj-y += vtimer.o
 ifdef CONFIG_DTB_FILE
 obj-y += dtb.o
 AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
+else
+# XXX: When running on the model there is no bootloader to provide a
+# device tree.  It must be linked into Xen.
+$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
 endif

 ALL_OBJS := head.o $(ALL_OBJS)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:22:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 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.xensource.com>)
	id 1RyRWB-00017t-Cf; Fri, 17 Feb 2012 17:22:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RyRWA-00017l-E9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:22:46 +0000
Received: from [85.158.139.83:60064] by server-3.bemta-5.messagelabs.com id
	31/F0-06438-5EC8E3F4; Fri, 17 Feb 2012 17:22:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329499363!15479803!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU1MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10575 invoked from network); 17 Feb 2012 17:22:44 -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;
	17 Feb 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325480400"; d="scan'208";a="182425546"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 12:22:42 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012
	12:22:42 -0500
Message-ID: <4F3E8CE1.7030803@citrix.com>
Date: Fri, 17 Feb 2012 17:22:41 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>	
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
	<1329498796.3131.135.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329498796.3131.135.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/02/12 17:13, Ian Campbell wrote:
> On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
>> diff --git a/config/arm.mk b/config/arm.mk
>> index f64f0c1..f20fd2d 100644
>> --- a/config/arm.mk
>> +++ b/config/arm.mk
>> @@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
>>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
>>  
>>  CONFIG_LOAD_ADDRESS ?= 0x80000000
>> +
>> +# XXX: When running on the model there is no bootloader to provide a
>> +# device tree.  It must be linked into Xen.
>> +ifndef CONFIG_DTB_FILE
>> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a
>> DTB)
>> +endif 
> 
> This turns out to be a little aggressive -- it also triggers when you
> are building the tools. Not a big deal, but a bit annoying, is there
> some way we can avoid this? Put it in xen/arch/arm/Foo perhaps?

Does this do the right thing?

8<---------
arm: move check for CONFIG_DTB_FILE to xen/arch/arm/Makefile

CONFIG_DTB_FILE only needs to be set when building Xen itself.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 config/arm.mk         |    6 ------
 xen/arch/arm/Makefile |    4 ++++
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/config/arm.mk b/config/arm.mk
index f20fd2d..f64f0c1 100644
--- a/config/arm.mk
+++ b/config/arm.mk
@@ -16,9 +16,3 @@ LDFLAGS_DIRECT_Linux = _linux
 LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi

 CONFIG_LOAD_ADDRESS ?= 0x80000000
-
-# XXX: When running on the model there is no bootloader to provide a
-# device tree.  It must be linked into Xen.
-ifndef CONFIG_DTB_FILE
-$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
-endif
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 168716e..da9134b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -26,6 +26,10 @@ obj-y += vtimer.o
 ifdef CONFIG_DTB_FILE
 obj-y += dtb.o
 AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
+else
+# XXX: When running on the model there is no bootloader to provide a
+# device tree.  It must be linked into Xen.
+$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
 endif

 ALL_OBJS := head.o $(ALL_OBJS)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRmo-0001Lz-24; Fri, 17 Feb 2012 17:39:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RyRmm-0001Lu-Ix
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:39:56 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329500330!61554791!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11439 invoked from network); 17 Feb 2012 17:38:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:38:50 -0000
Received: by wibhm2 with SMTP id hm2so5619671wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:39:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=gTz64xkgPAK3vX9q9WPLatDPsAxKQat7kekcH6d7yvo=;
	b=A9FHQxq9PjdQnSyhVyQpkKBc5Px0McEwPJQyWpYsjVQm/2OQeuhGBY0dXHeoffYtAK
	APQ14g/yTZaa7u2+KQjknbfV35jyjwhgp/WueaxHvNqIarvUI03WVFhGDGiDaFaFcFyx
	6ZHxoZS7b5NYhLdxG1RygkHEneRxCgMArKFWA=
MIME-Version: 1.0
Received: by 10.180.80.226 with SMTP id u2mr6099391wix.0.1329500395060; Fri,
	17 Feb 2012 09:39:55 -0800 (PST)
Received: by 10.180.101.167 with HTTP; Fri, 17 Feb 2012 09:39:55 -0800 (PST)
In-Reply-To: <1329485817436-5492514.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
	<1329485681.3131.77.camel@zakaz.uk.xensource.com>
	<1329485817436-5492514.post@n5.nabble.com>
Date: Fri, 17 Feb 2012 10:39:55 -0700
Message-ID: <CAHyyzzRRDgcMJnXhSf3iqPBKMFJScOCdmRn_pUYQqBeejMv+Lw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: Fantu <fantonifabio@tiscali.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1647074711465334598=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1647074711465334598==
Content-Type: multipart/alternative; boundary=f46d044288d2c6bd4b04b92c6e10

--f46d044288d2c6bd4b04b92c6e10
Content-Type: text/plain; charset=ISO-8859-1

I get this error
/home/dev/xen/xen-4.2/src/xen-unstable.git-build/tools/libxl/xl_cmdimpl.c:305:
undefined reference to `libx_yajl_gen_alloc'

/home/dev/xen/xen-4.2/src/xen-unstable.git-build/tools/libxl/xl_cmdimpl.c:305:
undefined reference to `libxl_yajl_gen_alloc

On Fri, Feb 17, 2012 at 6:36 AM, Fantu <fantonifabio@tiscali.it> wrote:

> With the 2 patches build done without error, now I also start testing xen
> unstable on Wheezy.
>
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492514.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--f46d044288d2c6bd4b04b92c6e10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I get this error <br>/home/dev/xen/xen-4.2/src/xen-unstable.git-build/tools=
/libxl/xl_cmdimpl.c:305: undefined reference to `libx_yajl_gen_alloc&#39;<b=
r><br><div class=3D"gmail_quote">/home/dev/xen/xen-4.2/src/xen-unstable.git=
-build/tools/libxl/xl_cmdimpl.c:305: undefined reference to `libxl_yajl_gen=
_alloc<br>
<br>On Fri, Feb 17, 2012 at 6:36 AM, Fantu <span dir=3D"ltr">&lt;<a href=3D=
"mailto:fantonifabio@tiscali.it">fantonifabio@tiscali.it</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
With the 2 patches build done without error, now I also start testing xen<b=
r>
unstable on Wheezy.<br>
<br>
--<br>
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/x=
l-cmdimpl-c-errors-tp5491537p5492514.html" target=3D"_blank">http://xen.104=
5712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492514.html</a><br>
<div class=3D"im HOEnZb">Sent from the Xen - Dev mailing list archive at Na=
bble.com.<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--f46d044288d2c6bd4b04b92c6e10--


--===============1647074711465334598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1647074711465334598==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRmo-0001Lz-24; Fri, 17 Feb 2012 17:39:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RyRmm-0001Lu-Ix
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:39:56 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329500330!61554791!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11439 invoked from network); 17 Feb 2012 17:38:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 17:38:50 -0000
Received: by wibhm2 with SMTP id hm2so5619671wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 09:39:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=gTz64xkgPAK3vX9q9WPLatDPsAxKQat7kekcH6d7yvo=;
	b=A9FHQxq9PjdQnSyhVyQpkKBc5Px0McEwPJQyWpYsjVQm/2OQeuhGBY0dXHeoffYtAK
	APQ14g/yTZaa7u2+KQjknbfV35jyjwhgp/WueaxHvNqIarvUI03WVFhGDGiDaFaFcFyx
	6ZHxoZS7b5NYhLdxG1RygkHEneRxCgMArKFWA=
MIME-Version: 1.0
Received: by 10.180.80.226 with SMTP id u2mr6099391wix.0.1329500395060; Fri,
	17 Feb 2012 09:39:55 -0800 (PST)
Received: by 10.180.101.167 with HTTP; Fri, 17 Feb 2012 09:39:55 -0800 (PST)
In-Reply-To: <1329485817436-5492514.post@n5.nabble.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
	<1329485681.3131.77.camel@zakaz.uk.xensource.com>
	<1329485817436-5492514.post@n5.nabble.com>
Date: Fri, 17 Feb 2012 10:39:55 -0700
Message-ID: <CAHyyzzRRDgcMJnXhSf3iqPBKMFJScOCdmRn_pUYQqBeejMv+Lw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: Fantu <fantonifabio@tiscali.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1647074711465334598=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1647074711465334598==
Content-Type: multipart/alternative; boundary=f46d044288d2c6bd4b04b92c6e10

--f46d044288d2c6bd4b04b92c6e10
Content-Type: text/plain; charset=ISO-8859-1

I get this error
/home/dev/xen/xen-4.2/src/xen-unstable.git-build/tools/libxl/xl_cmdimpl.c:305:
undefined reference to `libx_yajl_gen_alloc'

/home/dev/xen/xen-4.2/src/xen-unstable.git-build/tools/libxl/xl_cmdimpl.c:305:
undefined reference to `libxl_yajl_gen_alloc

On Fri, Feb 17, 2012 at 6:36 AM, Fantu <fantonifabio@tiscali.it> wrote:

> With the 2 patches build done without error, now I also start testing xen
> unstable on Wheezy.
>
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492514.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--f46d044288d2c6bd4b04b92c6e10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I get this error <br>/home/dev/xen/xen-4.2/src/xen-unstable.git-build/tools=
/libxl/xl_cmdimpl.c:305: undefined reference to `libx_yajl_gen_alloc&#39;<b=
r><br><div class=3D"gmail_quote">/home/dev/xen/xen-4.2/src/xen-unstable.git=
-build/tools/libxl/xl_cmdimpl.c:305: undefined reference to `libxl_yajl_gen=
_alloc<br>
<br>On Fri, Feb 17, 2012 at 6:36 AM, Fantu <span dir=3D"ltr">&lt;<a href=3D=
"mailto:fantonifabio@tiscali.it">fantonifabio@tiscali.it</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
With the 2 patches build done without error, now I also start testing xen<b=
r>
unstable on Wheezy.<br>
<br>
--<br>
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/x=
l-cmdimpl-c-errors-tp5491537p5492514.html" target=3D"_blank">http://xen.104=
5712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5492514.html</a><br>
<div class=3D"im HOEnZb">Sent from the Xen - Dev mailing list archive at Na=
bble.com.<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--f46d044288d2c6bd4b04b92c6e10--


--===============1647074711465334598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1647074711465334598==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:49:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRvO-0001cK-3E; Fri, 17 Feb 2012 17:48:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyRvM-0001cC-Fr
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 17:48:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329500921!14769148!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22230 invoked from network); 17 Feb 2012 17:48:42 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 17:48:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 09:48:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118697004"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 09:48:39 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:48:39 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:48:38 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sat, 18 Feb 2012 01:48:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM7Vhcw5JNa93KSUGX56XJx53QOJZBUWvA
Date: Fri, 17 Feb 2012 17:48:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
In-Reply-To: <4F3E2EEA020000780007397F@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: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Core parking is a power control feature and it can co-work with NPTM
>> to control system power budget through online/offline some CPUs in
>> the system. These patches implement core parking feature for xen.
>> They consist of 2 
>> parts: dom0 patches and xen hypervisor patches.
>> 
>> At dom0 side, patches include
>> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic,
>> providing a native interface for natvie platform and a paravirt
>> template for paravirt platform, so that os can implicitly hook to
>> proper ops accordingly; [Patch 2/3] redirect paravirt template to
>> Xen pv ops; [Patch 3/3] implement Xen pad logic, and when getting
>> pad device 
>> notification, it hypercalls to Xen hypervisor for core parking. Due
>> to the characteristic of xen continue_hypercall_on_cpu, dom0
>> seperately send/get 
>> core parking request/result;
>> 
>> At Xen hypervisor side, patches include
>> [Patch 1/2] implement hypercall through which dom0 send core parking
>> request, and get core parking result;
>> [Patch 2/2] implement Xen core parking. Different core parking
>> sequence has different power/performance result, due to cpu
>> socket/core/thread topology. This patch provide power-first and
>> performance-first policies, users can choose core parking policy on
>> their own demand, considering power and performance tradeoff.
> 
> Does this really need to be implemented in the hypervisor? All this
> boils down to is a wrapper around cpu_down() and cpu_up(), which
> have hypercall interfaces already. So I'd rather see this as being
> an extension to Dom0's pCPU management patches (which aren't
> upstream afaict)...
> 
> Jan

It's a design choice. Core parking is not only a wrapper around cpu_down/up, it also involves policy algorithms which depend on physical cpu topology and cpu_online/present_map, etc. Implement core parking at dom0 side need expose all those information to dom0, with potential issues (like coherence), while dom0 still need do same work as hypervisor.
Our idea is to keep dom0 as ACPI parser, then hypercall and do rest things at hypervisor side.

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:49:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17: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.xensource.com>)
	id 1RyRvO-0001cK-3E; Fri, 17 Feb 2012 17:48:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyRvM-0001cC-Fr
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 17:48:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329500921!14769148!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22230 invoked from network); 17 Feb 2012 17:48:42 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-216.messagelabs.com with SMTP;
	17 Feb 2012 17:48:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 09:48:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118697004"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2012 09:48:39 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:48:39 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:48:38 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sat, 18 Feb 2012 01:48:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM7Vhcw5JNa93KSUGX56XJx53QOJZBUWvA
Date: Fri, 17 Feb 2012 17:48:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
In-Reply-To: <4F3E2EEA020000780007397F@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: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature enable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Core parking is a power control feature and it can co-work with NPTM
>> to control system power budget through online/offline some CPUs in
>> the system. These patches implement core parking feature for xen.
>> They consist of 2 
>> parts: dom0 patches and xen hypervisor patches.
>> 
>> At dom0 side, patches include
>> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic,
>> providing a native interface for natvie platform and a paravirt
>> template for paravirt platform, so that os can implicitly hook to
>> proper ops accordingly; [Patch 2/3] redirect paravirt template to
>> Xen pv ops; [Patch 3/3] implement Xen pad logic, and when getting
>> pad device 
>> notification, it hypercalls to Xen hypervisor for core parking. Due
>> to the characteristic of xen continue_hypercall_on_cpu, dom0
>> seperately send/get 
>> core parking request/result;
>> 
>> At Xen hypervisor side, patches include
>> [Patch 1/2] implement hypercall through which dom0 send core parking
>> request, and get core parking result;
>> [Patch 2/2] implement Xen core parking. Different core parking
>> sequence has different power/performance result, due to cpu
>> socket/core/thread topology. This patch provide power-first and
>> performance-first policies, users can choose core parking policy on
>> their own demand, considering power and performance tradeoff.
> 
> Does this really need to be implemented in the hypervisor? All this
> boils down to is a wrapper around cpu_down() and cpu_up(), which
> have hypercall interfaces already. So I'd rather see this as being
> an extension to Dom0's pCPU management patches (which aren't
> upstream afaict)...
> 
> Jan

It's a design choice. Core parking is not only a wrapper around cpu_down/up, it also involves policy algorithms which depend on physical cpu topology and cpu_online/present_map, etc. Implement core parking at dom0 side need expose all those information to dom0, with potential issues (like coherence), while dom0 still need do same work as hypervisor.
Our idea is to keep dom0 as ACPI parser, then hypercall and do rest things at hypervisor side.

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:56:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyS2n-0001r6-0i; Fri, 17 Feb 2012 17:56:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyS2m-0001r1-5w
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:56:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329501381!15014943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12822 invoked from network); 17 Feb 2012 17:56:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 17:56:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyS2d-000Fx6-5e; Fri, 17 Feb 2012 17:56:19 +0000
Date: Fri, 17 Feb 2012 17:56:19 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120217175619.GB59026@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
> Well, thanks for taking a stab at it. Looks fairly well. My main
> observation is that we do not want to unconditionally go on a wait queue
> everywhere. For example, the grant table code pretty reliable unwinds
> itself and correctly tells the grant mapper to retry, in the presence of a
> paged page.

The grant table code is unlikely to hit a paged-out gfn in the caller's
address space.

> The same could be said of emulation (X86_EMUL_RETRY).

Fair enough.  But the emulator uses hvm_copy() in its callbacks anyway
we'd need another flag to say 'special handling for p2m fixups plz' in
all the hvm_copy() interfaces.  Unpleasant!

> And certainly the balloon code should not sleep waiting for populate!

The balloon code should not be trying to populate at all!

> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
> wait queue code is invoked only there. And then we can call get_gfn_sleep
> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.

I see.  In the longer term I definitely do not want get_gfn()'s callers
to have to deal with p2m_is_paged(), and PoD, and sharing, and every
other p2m hack we come up with.  I want all that stuff hidden behind
get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.

I don't like get_gfn_sleep() very much but I'll see if I can find a way
to do the equivalent with a flag to get_gfn_*().  But I suspect it will
end up with a tri-state argument of:
 a) just give me the current state;
 b) try (without sleeping) to fix up paging, PoD and sharing but 
    still maybe make me handle it myself by error propagation; and
 c) just fix it up.

'b' is a pretty weird interface.  Specially given that in corner cases,
'make me handle it' might involve hitting a wait queue anyway.  If we
intend in the fullness of time to get rid of it (as I hope we would)
then probably we shouldn't introduce it.  (And if that means pushing
this whole change out past 4.2, we should consider doing that.)

> >> diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
> >> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
> >> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
> >>     }
> >>
> >>     /* For now only perform locking on hap domains */
> >> -    if ( locked && (hap_enabled(p2m->domain)) )
> >> +    locked = locked && hap_enabled(p2m->domain);
> >> +
> >> +#ifdef __x86_64__
> When are we getting rid of 32 bit hypervisor? (half kidding. Only half)

Can't be soon enough for me.  I've been sharpening the axe for that one
for years now. :)

> >> +again:
> >> +#endif
> >> +    if ( locked )
> >>         /* Grab the lock here, don't release until put_gfn */
> >>         gfn_lock(p2m, gfn, 0);
> >>
> >>     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
> >>
> >> #ifdef __x86_64__
> >> +    if ( p2m_is_paging(*t) && q != p2m_query
> >> +         && p2m->domain == current->domain )
> >> +    {
> >> +        if ( locked )
> >> +            gfn_unlock(p2m, gfn, 0);
> >> +
> >> +        /* Ping the pager */
> >> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> >> +            p2m_mem_paging_populate(p2m->domain, gfn);
> 
> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
> still have the mfn in place.

Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
not, it really should.

> >> +
> >> +        /* Safety catch: it _should_ be safe to wait here but if it's
> >> not,
> >> +         * crash the VM, not the host */
> >> +        if ( in_atomic() )
> >> +        {
> >> +            WARN();
> >> +            domain_crash(p2m->domain);
> >> +        }
> >> +        else
> >> +        {
> >> +            current->arch.mem_paging_gfn = gfn;
> >> +            wait_event(current->arch.mem_paging_wq, ({
> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
> >> +                                             p2m_query, page_order);
> >> +                        (*t != p2m_ram_paging_in);
> 
> Well, first of all mfn->get_entry will not happen in a locked context, so
> you will exit the wait loop not holding the p2m lock and crash later.

Yes - we always exit the loop without the lock; then we 'goto again' and
do things properly.  I realise it's a bit inefficient, but on the
page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
write the version that handled the locking in this loop but it got a bit
twisty, plus we need the 'goto again' for other reasons (see below).

As a follow-up I ought to make the page-sharing fixup code that's just
below this use 'goto again' as well; we shouldn't really leave this
function until we get a lookup where all these cases are dealt with.

> So you want __get_gfn_type_access with q = p2m_query, and then put_gfn if the
> condition fails. Probably not gonna fit in a ({}) block ;)
> 
> I think checking for (!p2m_is_paging(*t)) is more appropriate.

No, that was deliberate, and IIRC a change from Olaf's patch.  If the
page gets paged in and back out while we're asleep, the type goes back
to p2m_ram_paged, and in that case we _must_ break out and retry or this
vcpu might stall forever.

> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >> {
> >>     struct vcpu *v = current;
> >> -    mem_event_request_t req;
> >> +    mem_event_request_t req = {0};
> >>     p2m_type_t p2mt;
> >>     p2m_access_t a;
> >>     mfn_t mfn;
> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> +    int send_request = 0;
> >>
> >>     /* We're paging. There should be a ring */
> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> 
> Given all the optimizations around the send_request flag, it might be
> worth moving the claim_slot call to an if(send_request) block at the
> bottom, and get rid of cancel_slot altogether. Claim_slot could
> potentially go (or cause someone else to go) to a wait queue, and it's
> best to not be that rude.

Sure.  It might be tricky to make sure we unwind properly in the failure
case, but I'll have a go at a follow-up patch that looks at that.

(This is not really a regression in this patch AFAICS - in the existing code
the get_gfn() callers end up calling this function anyway.)

> >> -    /* Pause domain if request came from guest and gfn has paging type
> >> */
> >> -    if ( p2m_is_paging(p2mt) && v->domain == d )
> >> +    /* No need to inform pager if the gfn is not in the page-out path
> >> */
> >> +    if ( !send_request )
> >>     {
> >> -        vcpu_pause_nosync(v);
> 
> I see no sin in stacking vcpu_pauses. Plus, this will need to stay if we
> (hopefully) adopt get_gfn_sleep.

Yes, if we do it that way, this pause definitely needs to stay.  But if
not then the waitqueue takes care of this case entirely, and this code
is just redundant and confusing.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 17:56:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 17:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyS2n-0001r6-0i; Fri, 17 Feb 2012 17:56:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RyS2m-0001r1-5w
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 17:56:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329501381!15014943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12822 invoked from network); 17 Feb 2012 17:56:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2012 17:56:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RyS2d-000Fx6-5e; Fri, 17 Feb 2012 17:56:19 +0000
Date: Fri, 17 Feb 2012 17:56:19 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120217175619.GB59026@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
> Well, thanks for taking a stab at it. Looks fairly well. My main
> observation is that we do not want to unconditionally go on a wait queue
> everywhere. For example, the grant table code pretty reliable unwinds
> itself and correctly tells the grant mapper to retry, in the presence of a
> paged page.

The grant table code is unlikely to hit a paged-out gfn in the caller's
address space.

> The same could be said of emulation (X86_EMUL_RETRY).

Fair enough.  But the emulator uses hvm_copy() in its callbacks anyway
we'd need another flag to say 'special handling for p2m fixups plz' in
all the hvm_copy() interfaces.  Unpleasant!

> And certainly the balloon code should not sleep waiting for populate!

The balloon code should not be trying to populate at all!

> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
> wait queue code is invoked only there. And then we can call get_gfn_sleep
> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.

I see.  In the longer term I definitely do not want get_gfn()'s callers
to have to deal with p2m_is_paged(), and PoD, and sharing, and every
other p2m hack we come up with.  I want all that stuff hidden behind
get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.

I don't like get_gfn_sleep() very much but I'll see if I can find a way
to do the equivalent with a flag to get_gfn_*().  But I suspect it will
end up with a tri-state argument of:
 a) just give me the current state;
 b) try (without sleeping) to fix up paging, PoD and sharing but 
    still maybe make me handle it myself by error propagation; and
 c) just fix it up.

'b' is a pretty weird interface.  Specially given that in corner cases,
'make me handle it' might involve hitting a wait queue anyway.  If we
intend in the fullness of time to get rid of it (as I hope we would)
then probably we shouldn't introduce it.  (And if that means pushing
this whole change out past 4.2, we should consider doing that.)

> >> diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
> >> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
> >> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
> >>     }
> >>
> >>     /* For now only perform locking on hap domains */
> >> -    if ( locked && (hap_enabled(p2m->domain)) )
> >> +    locked = locked && hap_enabled(p2m->domain);
> >> +
> >> +#ifdef __x86_64__
> When are we getting rid of 32 bit hypervisor? (half kidding. Only half)

Can't be soon enough for me.  I've been sharpening the axe for that one
for years now. :)

> >> +again:
> >> +#endif
> >> +    if ( locked )
> >>         /* Grab the lock here, don't release until put_gfn */
> >>         gfn_lock(p2m, gfn, 0);
> >>
> >>     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
> >>
> >> #ifdef __x86_64__
> >> +    if ( p2m_is_paging(*t) && q != p2m_query
> >> +         && p2m->domain == current->domain )
> >> +    {
> >> +        if ( locked )
> >> +            gfn_unlock(p2m, gfn, 0);
> >> +
> >> +        /* Ping the pager */
> >> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> >> +            p2m_mem_paging_populate(p2m->domain, gfn);
> 
> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
> still have the mfn in place.

Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
not, it really should.

> >> +
> >> +        /* Safety catch: it _should_ be safe to wait here but if it's
> >> not,
> >> +         * crash the VM, not the host */
> >> +        if ( in_atomic() )
> >> +        {
> >> +            WARN();
> >> +            domain_crash(p2m->domain);
> >> +        }
> >> +        else
> >> +        {
> >> +            current->arch.mem_paging_gfn = gfn;
> >> +            wait_event(current->arch.mem_paging_wq, ({
> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
> >> +                                             p2m_query, page_order);
> >> +                        (*t != p2m_ram_paging_in);
> 
> Well, first of all mfn->get_entry will not happen in a locked context, so
> you will exit the wait loop not holding the p2m lock and crash later.

Yes - we always exit the loop without the lock; then we 'goto again' and
do things properly.  I realise it's a bit inefficient, but on the
page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
write the version that handled the locking in this loop but it got a bit
twisty, plus we need the 'goto again' for other reasons (see below).

As a follow-up I ought to make the page-sharing fixup code that's just
below this use 'goto again' as well; we shouldn't really leave this
function until we get a lookup where all these cases are dealt with.

> So you want __get_gfn_type_access with q = p2m_query, and then put_gfn if the
> condition fails. Probably not gonna fit in a ({}) block ;)
> 
> I think checking for (!p2m_is_paging(*t)) is more appropriate.

No, that was deliberate, and IIRC a change from Olaf's patch.  If the
page gets paged in and back out while we're asleep, the type goes back
to p2m_ram_paged, and in that case we _must_ break out and retry or this
vcpu might stall forever.

> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >> {
> >>     struct vcpu *v = current;
> >> -    mem_event_request_t req;
> >> +    mem_event_request_t req = {0};
> >>     p2m_type_t p2mt;
> >>     p2m_access_t a;
> >>     mfn_t mfn;
> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> +    int send_request = 0;
> >>
> >>     /* We're paging. There should be a ring */
> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> 
> Given all the optimizations around the send_request flag, it might be
> worth moving the claim_slot call to an if(send_request) block at the
> bottom, and get rid of cancel_slot altogether. Claim_slot could
> potentially go (or cause someone else to go) to a wait queue, and it's
> best to not be that rude.

Sure.  It might be tricky to make sure we unwind properly in the failure
case, but I'll have a go at a follow-up patch that looks at that.

(This is not really a regression in this patch AFAICS - in the existing code
the get_gfn() callers end up calling this function anyway.)

> >> -    /* Pause domain if request came from guest and gfn has paging type
> >> */
> >> -    if ( p2m_is_paging(p2mt) && v->domain == d )
> >> +    /* No need to inform pager if the gfn is not in the page-out path
> >> */
> >> +    if ( !send_request )
> >>     {
> >> -        vcpu_pause_nosync(v);
> 
> I see no sin in stacking vcpu_pauses. Plus, this will need to stay if we
> (hopefully) adopt get_gfn_sleep.

Yes, if we do it that way, this pause definitely needs to stay.  But if
not then the waitqueue takes care of this case entirely, and this code
is just redundant and confusing.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyS6L-00023q-RU; Fri, 17 Feb 2012 18:00:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyS6K-00023T-Ph
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 18:00:09 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329501601!11983509!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27836 invoked from network); 17 Feb 2012 18:00:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 18:00:01 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 10:00:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126749678"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2012 09:59:59 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:59:59 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:59:58 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sat, 18 Feb 2012 01:59:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 1/3] PAD helper for native and paravirt platform
Thread-Index: AQHM7VuZ6RKQx7+6TLaQA8tFAlSyZpZBXlMA
Date: Fri, 17 Feb 2012 17:59:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509F044@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<4F3E345802000078000739B2@nat28.tlf.novell.com>
In-Reply-To: <4F3E345802000078000739B2@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: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Kerneldevelopment list <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> 
>> +static inline int __acpi_pad_init(void)
>> +{
>> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
>> +
>> +static inline void __acpi_pad_exit(void)
>> +{
>> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
>> +}
> 
> With this you, aiui, you aim at getting the calls patched. Are the
> callers of this really on performance critical paths? If not, the
> simpler approach of having an ops structure the fields of which get
> overwritten by 
> Xen initialization would seem a more appropriate approach.
> 

Yes, I agree. I code in this way just want to keep same coding style as other pv functions of paravirt.h.
I update the patch w/ a simpler approach, and will post later.
Of course, we need Konrad's comments.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyS6L-00023q-RU; Fri, 17 Feb 2012 18:00:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RyS6K-00023T-Ph
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 18:00:09 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329501601!11983509!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjQ3Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27836 invoked from network); 17 Feb 2012 18:00:01 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-174.messagelabs.com with SMTP;
	17 Feb 2012 18:00:01 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2012 10:00:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126749678"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2012 09:59:59 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:59:59 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 18 Feb 2012 01:59:58 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sat, 18 Feb 2012 01:59:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 1/3] PAD helper for native and paravirt platform
Thread-Index: AQHM7VuZ6RKQx7+6TLaQA8tFAlSyZpZBXlMA
Date: Fri, 17 Feb 2012 17:59:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233509F044@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<4F3E345802000078000739B2@nat28.tlf.novell.com>
In-Reply-To: <4F3E345802000078000739B2@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: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Kerneldevelopment list <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> 
>> +static inline int __acpi_pad_init(void)
>> +{
>> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
>> +
>> +static inline void __acpi_pad_exit(void)
>> +{
>> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
>> +}
> 
> With this you, aiui, you aim at getting the calls patched. Are the
> callers of this really on performance critical paths? If not, the
> simpler approach of having an ops structure the fields of which get
> overwritten by 
> Xen initialization would seem a more appropriate approach.
> 

Yes, I agree. I code in this way just want to keep same coding style as other pv functions of paravirt.h.
I update the patch w/ a simpler approach, and will post later.
Of course, we need Konrad's comments.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18: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.xensource.com>)
	id 1RySQJ-0002a4-DK; Fri, 17 Feb 2012 18:20:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RySQI-0002Zw-Fn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:20:46 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329502818!63982600!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5108 invoked from network); 17 Feb 2012 18:20:19 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:20:19 -0000
Received: by ggnu1 with SMTP id u1so47203095ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 10:20:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=Ld4w4UIPp8PY29B5ChcpyiwYVZty9vcHhdPOa1mQg4o=;
	b=U5BNEU01tcBd7tx3EyNDQPWiQHtQyHc36DhD7mvO5k+GrK3vUTuguFZESX08FqxQGn
	Y6N7NOGwD5LPTxcadGtsxu9jE3cJYFsB29YorjmIAUDdr8DBK067e/q8VRbLpn+VjIoy
	UVXMkXIPE1jvs/U10KkXEa0uq/RNkXJwv0eVM=
Received: by 10.236.201.195 with SMTP id b43mr10783109yho.75.1329502841168;
	Fri, 17 Feb 2012 10:20:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.179.9 with HTTP; Fri, 17 Feb 2012 10:20:21 -0800 (PST)
From: Eric Camachat <eric.camachat@gmail.com>
Date: Fri, 17 Feb 2012 10:20:21 -0800
Message-ID: <CACeEFf42Wa38-6YJ+xYhs216QJK2yurCVKrn5=Ni0zZR9wM_mQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] virtual, physical and bus address on Dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Consider the code:

dma_addr_t dma_addr, dma_addr2;
phys_addr_t phys_addr;
cpu_addr = pci_alloc_consistent(pdev, size, &dma_addr);
phys_addr = virt_to_phys(cpu_addr);
dma_addr2 = virt_to_bus(cpu_addr);

In Dom0 the outputs are:

dma_addr: 0xbc800000
phys_addr: 0x5b000000
dma_addr2: 0x5b000000

Why the addresses are different in dma_addr and dma_addr2?
Which one is the correct value I should use in DMA operations?

Eric

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18: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.xensource.com>)
	id 1RySQJ-0002a4-DK; Fri, 17 Feb 2012 18:20:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RySQI-0002Zw-Fn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:20:46 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329502818!63982600!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5108 invoked from network); 17 Feb 2012 18:20:19 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:20:19 -0000
Received: by ggnu1 with SMTP id u1so47203095ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 10:20:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=Ld4w4UIPp8PY29B5ChcpyiwYVZty9vcHhdPOa1mQg4o=;
	b=U5BNEU01tcBd7tx3EyNDQPWiQHtQyHc36DhD7mvO5k+GrK3vUTuguFZESX08FqxQGn
	Y6N7NOGwD5LPTxcadGtsxu9jE3cJYFsB29YorjmIAUDdr8DBK067e/q8VRbLpn+VjIoy
	UVXMkXIPE1jvs/U10KkXEa0uq/RNkXJwv0eVM=
Received: by 10.236.201.195 with SMTP id b43mr10783109yho.75.1329502841168;
	Fri, 17 Feb 2012 10:20:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.179.9 with HTTP; Fri, 17 Feb 2012 10:20:21 -0800 (PST)
From: Eric Camachat <eric.camachat@gmail.com>
Date: Fri, 17 Feb 2012 10:20:21 -0800
Message-ID: <CACeEFf42Wa38-6YJ+xYhs216QJK2yurCVKrn5=Ni0zZR9wM_mQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] virtual, physical and bus address on Dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Consider the code:

dma_addr_t dma_addr, dma_addr2;
phys_addr_t phys_addr;
cpu_addr = pci_alloc_consistent(pdev, size, &dma_addr);
phys_addr = virt_to_phys(cpu_addr);
dma_addr2 = virt_to_bus(cpu_addr);

In Dom0 the outputs are:

dma_addr: 0xbc800000
phys_addr: 0x5b000000
dma_addr2: 0x5b000000

Why the addresses are different in dma_addr and dma_addr2?
Which one is the correct value I should use in DMA operations?

Eric

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18: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.xensource.com>)
	id 1RySn5-0002uX-SA; Fri, 17 Feb 2012 18:44:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn3-0002uA-Gt
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16892 invoked from network); 17 Feb 2012 18:44:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySmw-0006Zs-Qf; Fri, 17 Feb 2012 18:44:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySmw-0005DT-Pm;
	Fri, 17 Feb 2012 18:44:10 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 18:43:57 +0000
Message-ID: <1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    8 ++++++--
 tools/libxl/libxl_internal.h |   13 +++++++++----
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..dda9d6f 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,8 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
-    assert(ao->in_initiator);
+    assert(ao->constructing && ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8846c68..49688e1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -337,7 +337,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1185,6 +1185,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
  * outside libxl, because they can cause reentrancy callbacks.
  *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
+ *
  * Lifecycle of an ao:
  *
  * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
@@ -1214,8 +1218,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1229,12 +1232,13 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
-    AO_GC;
+    EGC_INIT(ctx);
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1243,6 +1247,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18: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.xensource.com>)
	id 1RySn5-0002uX-SA; Fri, 17 Feb 2012 18:44:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn3-0002uA-Gt
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16892 invoked from network); 17 Feb 2012 18:44:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySmw-0006Zs-Qf; Fri, 17 Feb 2012 18:44:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySmw-0005DT-Pm;
	Fri, 17 Feb 2012 18:44:10 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 18:43:57 +0000
Message-ID: <1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    8 ++++++--
 tools/libxl/libxl_internal.h |   13 +++++++++----
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..dda9d6f 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,8 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
-    assert(ao->in_initiator);
+    assert(ao->constructing && ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8846c68..49688e1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -337,7 +337,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1185,6 +1185,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
  * outside libxl, because they can cause reentrancy callbacks.
  *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
+ *
  * Lifecycle of an ao:
  *
  * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
@@ -1214,8 +1218,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1229,12 +1232,13 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
-    AO_GC;
+    EGC_INIT(ctx);
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1243,6 +1247,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:44: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.xensource.com>)
	id 1RySn8-0002uj-8Q; Fri, 17 Feb 2012 18:44:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn7-0002uI-GR
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16971 invoked from network); 17 Feb 2012 18:44:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySn0-0006Zv-Rt; Fri, 17 Feb 2012 18:44:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySn0-0005Dc-QV;
	Fri, 17 Feb 2012 18:44:14 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 18:43:58 +0000
Message-ID: <1329504239-19999-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 68bba8f..7735223 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1362,7 +1362,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1815,7 +1815,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2159,7 +2159,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2286,7 +2286,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 49688e1..696c1ed 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -669,7 +669,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:44: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.xensource.com>)
	id 1RySn8-0002uj-8Q; Fri, 17 Feb 2012 18:44:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn7-0002uI-GR
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16971 invoked from network); 17 Feb 2012 18:44:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySn0-0006Zv-Rt; Fri, 17 Feb 2012 18:44:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySn0-0005Dc-QV;
	Fri, 17 Feb 2012 18:44:14 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 18:43:58 +0000
Message-ID: <1329504239-19999-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 68bba8f..7735223 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1362,7 +1362,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1815,7 +1815,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2159,7 +2159,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2286,7 +2286,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 49688e1..696c1ed 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -669,7 +669,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:44: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.xensource.com>)
	id 1RySn2-0002uJ-Fu; Fri, 17 Feb 2012 18:44:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn0-0002u9-Jn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16831 invoked from network); 17 Feb 2012 18:44:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySmt-0006Zo-Bi; Fri, 17 Feb 2012 18:44:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySmt-0005DJ-AZ;
	Fri, 17 Feb 2012 18:44:07 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 18:43:56 +0000
Message-ID: <1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure"):
> Yes, you are right, there is a bug in libxl_device_disk_remove /
> libxl__initiate_device_remove.  I hadn't spotted that the "out" path
> from the old device removal code was used in a success case too.
> 
> I will fix it.

Please take a look at the following 3-patch series.  I have compiled
it but not tested it, but I think something like it should work.

 1/3 libxl: ao: allow immediate completion
 2/3 libxl: fix hang due to libxl__initiate_device_remove
 3/3 libxl: Fix eventloop_iteration over-locking

Hopefully 1/3 and 2/3 will make the intended behaviour, and the
intended usage clear.  Sorry for confusing you with a bad example!

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:44: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.xensource.com>)
	id 1RySn2-0002uJ-Fu; Fri, 17 Feb 2012 18:44:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn0-0002u9-Jn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16831 invoked from network); 17 Feb 2012 18:44:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySmt-0006Zo-Bi; Fri, 17 Feb 2012 18:44:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySmt-0005DJ-AZ;
	Fri, 17 Feb 2012 18:44:07 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 18:43:56 +0000
Message-ID: <1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure"):
> Yes, you are right, there is a bug in libxl_device_disk_remove /
> libxl__initiate_device_remove.  I hadn't spotted that the "out" path
> from the old device removal code was used in a success case too.
> 
> I will fix it.

Please take a look at the following 3-patch series.  I have compiled
it but not tested it, but I think something like it should work.

 1/3 libxl: ao: allow immediate completion
 2/3 libxl: fix hang due to libxl__initiate_device_remove
 3/3 libxl: Fix eventloop_iteration over-locking

Hopefully 1/3 and 2/3 will make the intended behaviour, and the
intended usage clear.  Sorry for confusing you with a bad example!

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RySnB-0002vH-MI; Fri, 17 Feb 2012 18:44:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn9-0002uU-P9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 17 Feb 2012 18:44:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySn3-0006Zy-A7; Fri, 17 Feb 2012 18:44:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySn3-0005Dg-8U;
	Fri, 17 Feb 2012 18:44:17 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 18:43:59 +0000
Message-ID: <1329504239-19999-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: Fix eventloop_iteration over-locking
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index dda9d6f..522bd99 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 696c1ed..7b8d0c2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1165,7 +1165,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1260,7 +1260,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RySnB-0002vH-MI; Fri, 17 Feb 2012 18:44:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySn9-0002uU-P9
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:44:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329504248!15274194!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 17 Feb 2012 18:44:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 18:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:44:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:44:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySn3-0006Zy-A7; Fri, 17 Feb 2012 18:44:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySn3-0005Dg-8U;
	Fri, 17 Feb 2012 18:44:17 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 18:43:59 +0000
Message-ID: <1329504239-19999-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20286.31877.938411.558236@mariner.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: Fix eventloop_iteration over-locking
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index dda9d6f..522bd99 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 696c1ed..7b8d0c2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1165,7 +1165,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1260,7 +1260,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:48:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RySqS-0003Od-GC; Fri, 17 Feb 2012 18:47:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySqR-0003Nx-Hl
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:47:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329504461!13852341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10470 invoked from network); 17 Feb 2012 18:47: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;
	17 Feb 2012 18:47:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:47:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:47:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySqK-0006b7-DY; Fri, 17 Feb 2012 18:47:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySqK-0005E4-CP;
	Fri, 17 Feb 2012 18:47:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20286.41164.369217.262696@mariner.uk.xensource.com>
Date: Fri, 17 Feb 2012 18:47:40 +0000
To: Roger Pau =?utf-8?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("[PATCH 0/3] libxl: Permit immediate asynchronous completion"):
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure"):
> > Yes, you are right, there is a bug in libxl_device_disk_remove /
> > libxl__initiate_device_remove.  I hadn't spotted that the "out" path
> > from the old device removal code was used in a success case too.
> > 
> > I will fix it.
> 
> Please take a look at the following 3-patch series.  I have compiled
> it but not tested it, but I think something like it should work.

Sorry, Roger, the way I sent this mail omitted you from the CC.

>  1/3 libxl: ao: allow immediate completion
>  2/3 libxl: fix hang due to libxl__initiate_device_remove
>  3/3 libxl: Fix eventloop_iteration over-locking
> 
> Hopefully 1/3 and 2/3 will make the intended behaviour, and the
> intended usage clear.  Sorry for confusing you with a bad example!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 18:48:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 18:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RySqS-0003Od-GC; Fri, 17 Feb 2012 18:47:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RySqR-0003Nx-Hl
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 18:47:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329504461!13852341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10470 invoked from network); 17 Feb 2012 18:47: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;
	17 Feb 2012 18:47:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 18:47:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 18:47:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RySqK-0006b7-DY; Fri, 17 Feb 2012 18:47:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RySqK-0005E4-CP;
	Fri, 17 Feb 2012 18:47:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20286.41164.369217.262696@mariner.uk.xensource.com>
Date: Fri, 17 Feb 2012 18:47:40 +0000
To: Roger Pau =?utf-8?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("[PATCH 0/3] libxl: Permit immediate asynchronous completion"):
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure"):
> > Yes, you are right, there is a bug in libxl_device_disk_remove /
> > libxl__initiate_device_remove.  I hadn't spotted that the "out" path
> > from the old device removal code was used in a success case too.
> > 
> > I will fix it.
> 
> Please take a look at the following 3-patch series.  I have compiled
> it but not tested it, but I think something like it should work.

Sorry, Roger, the way I sent this mail omitted you from the CC.

>  1/3 libxl: ao: allow immediate completion
>  2/3 libxl: fix hang due to libxl__initiate_device_remove
>  3/3 libxl: Fix eventloop_iteration over-locking
> 
> Hopefully 1/3 and 2/3 will make the intended behaviour, and the
> intended usage clear.  Sorry for confusing you with a bad example!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:02:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19: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.xensource.com>)
	id 1RyT4I-0003nV-Vr; Fri, 17 Feb 2012 19:02:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyT4F-0003nQ-0a
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:02:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329505315!11988628!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32721 invoked from network); 17 Feb 2012 19:01:56 -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; 17 Feb 2012 19:01:56 -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 q1HJ1oFI022077
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:01:51 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
	q1HJ1k07021590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:01:47 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
	q1HJ1hQs030696; Fri, 17 Feb 2012 13:01:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:01:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D761941FE1; Fri, 17 Feb 2012 13:58:36 -0500 (EST)
Date: Fri, 17 Feb 2012 13:58:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120217185836.GA23942@phenom.dumpdata.com>
References: <1329394629-10299-1-git-send-email-drjones@redhat.com>
	<7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
	<20120217165253.GA17397@turtle.usersys.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120217165253.GA17397@turtle.usersys.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F3EA41F.00D6,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> > Hmm, I should maybe self-nack this. The bug that led me to writing
> > it is likely only with older tooling, such as RHEL5's. The problem
> > was if you attempted to detach a mounted disk twice, then the second
> > time it would succeed. The guest had flipped to Closing on the first
> > try, and thus didn't issue an error to xenbus on the second. I see
> 
> Actually, it's even worse than I thought. Just a single attempt to
> detach the device will cause the guest grief (with RHEL5's tools
> anyway). Once xenbus shows the device is in the Closing state, then
> tasks accessing the device may hang.
> 
> > The reason I only say maybe self-nack though, is because this state
> > change seemed to be thrown in with another fix[1]. I'm not sure if
> > the new behavior on legacy hosts was considered or not. If not, then
> > we can consider it now. Do we want to have deferred asynch detaches
> > over protecting the guest from multiple detach calls on legacy hosts?
> > 
> 
> I guess we can keep the feature and protect the guest with a patch like
> I'll send in a moment. It doesn't really work for me with a RHEL5 host
> though. The deferred close works from the pov of the guest, but the
> state of the block device gets left in Closed after the guest unmounts
> it, and then RHEL5's tools can't detach/reattach it. If the deferred
> close ever worked on other Xen hosts though, then I don't believe this
> patch would break it, and it will also keep the guest safe when run on
> hosts that don't treat state=Closing the way it currently expects.

There was another fix that sounds similar to this in the backend.
6f5986bce558e64fe867bff600a2127a3cb0c006

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:02:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19: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.xensource.com>)
	id 1RyT4I-0003nV-Vr; Fri, 17 Feb 2012 19:02:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyT4F-0003nQ-0a
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:02:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329505315!11988628!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32721 invoked from network); 17 Feb 2012 19:01:56 -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; 17 Feb 2012 19:01:56 -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 q1HJ1oFI022077
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:01:51 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
	q1HJ1k07021590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:01:47 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
	q1HJ1hQs030696; Fri, 17 Feb 2012 13:01:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:01:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D761941FE1; Fri, 17 Feb 2012 13:58:36 -0500 (EST)
Date: Fri, 17 Feb 2012 13:58:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120217185836.GA23942@phenom.dumpdata.com>
References: <1329394629-10299-1-git-send-email-drjones@redhat.com>
	<7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
	<20120217165253.GA17397@turtle.usersys.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120217165253.GA17397@turtle.usersys.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F3EA41F.00D6,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> > Hmm, I should maybe self-nack this. The bug that led me to writing
> > it is likely only with older tooling, such as RHEL5's. The problem
> > was if you attempted to detach a mounted disk twice, then the second
> > time it would succeed. The guest had flipped to Closing on the first
> > try, and thus didn't issue an error to xenbus on the second. I see
> 
> Actually, it's even worse than I thought. Just a single attempt to
> detach the device will cause the guest grief (with RHEL5's tools
> anyway). Once xenbus shows the device is in the Closing state, then
> tasks accessing the device may hang.
> 
> > The reason I only say maybe self-nack though, is because this state
> > change seemed to be thrown in with another fix[1]. I'm not sure if
> > the new behavior on legacy hosts was considered or not. If not, then
> > we can consider it now. Do we want to have deferred asynch detaches
> > over protecting the guest from multiple detach calls on legacy hosts?
> > 
> 
> I guess we can keep the feature and protect the guest with a patch like
> I'll send in a moment. It doesn't really work for me with a RHEL5 host
> though. The deferred close works from the pov of the guest, but the
> state of the block device gets left in Closed after the guest unmounts
> it, and then RHEL5's tools can't detach/reattach it. If the deferred
> close ever worked on other Xen hosts though, then I don't believe this
> patch would break it, and it will also keep the guest safe when run on
> hosts that don't treat state=Closing the way it currently expects.

There was another fix that sounds similar to this in the backend.
6f5986bce558e64fe867bff600a2127a3cb0c006

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:06:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyT8X-0003vp-Li; Fri, 17 Feb 2012 19:06:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyT8V-0003vf-O6
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:06:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329505580!13416951!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTUxMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19538 invoked from network); 17 Feb 2012 19:06:20 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-13.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 19:06:20 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 0BA7B4B0091;
	Fri, 17 Feb 2012 11:06:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ert01K/uBwuh8eZofBaBiam0QYgpvd6DPYiyc1btAcVW
	UwmIMTfLN82udZqEkr6FU3uxzUXdRFy8DbQiA5dqR2/9Ljq8ZOG1Bt4qcRgPjNKI
	in9WVSPg7topSGWCYNWEMCdLLnQrTgbi+njlP/EQaJXN5J8t2z631iyORtrkj1U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xoFKWt0KPW1yWZ2n43B3ZwGJ7jE=; b=LzMCsUgO
	rt6ije8YyaUMntuAM4oIrvcZoBqASJNOU6N0q7WG3aqfUfv8z+qV9vU2AaFDcgBu
	+DQLeAJZe+dnM0mpmL+xGeVmxsGxZwf18tk3C0mtaxDn7Mf+hA8igor3IW75YOPd
	LWDKdvyiPhOyjcxhBqQhzhnbGnumo389Jjk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id B53484B008F; 
	Fri, 17 Feb 2012 11:06:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 11:06:19 -0800
Message-ID: <0db5d62c10cd88eb11881a1cae41cdfe.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
	<91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
	<291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
Date: Fri, 17 Feb 2012 11:06:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> IIRC Windows (7) calibrates tsc against RTC at start of day and you can
> get some pretty odd results if a vcpu is descheduled during that
> calculation. I was not aware of the exact scenario you described. You
> *can* get the equivalent of the /usepmtimer boot.ini option on more recent
> OS by doing:
>
> bcdedit /set useplatformclock true
Hey Paul,
we've tried that, no joy.

>
> Enabling viridian timers in Xen may be the way to go though.
I'm looking at xen code (and various XenServer versions as well). I don't
see any timer implementations, at least not anything from the msdn
references (e.g. HV_X64_MSR_REFERENCE_TSC, HV_X64_MSR_STIMER0_CONFIG, etc)

Am I looking in the wrong place?
Thanks
Andres

>
>   Paul
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
>> Sent: 17 February 2012 16:28
>> To: xen-devel@lists.xensource.com
>> Cc: Ian Campbell; Qrux
>> Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
>>
>> > Date: Fri, 17 Feb 2012 12:06:05 +0000
>> > From: Ian Campbell <Ian.Campbell@citrix.com>
>> > To: Qrux <qrux.qed@gmail.com>
>> > Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>> > Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
>> > Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
>> > Content-Type: text/plain; charset="UTF-8"
>> >
>> > I'm afraid I don't know the answer to most of your questions (hence
>> > I'm afraid I've trimmed the quotes rather aggressively) but here's
>> > some of what I do know.
>>
>> I'm gonna add another data point.
>>
>> We're seeing the Windows 7 Query Performance Counter get mightily
>> confused. People have reported this in Amazon EC2 as well
>> https://forums.aws.amazon.com/thread.jspa?threadID=41426
>>
>> We've tracked it down to the hpet. Xen schedules an interrupt delivery
>> for
>> an hpet tick, but the vcpu is asleep. Could be an admin pause, a sleep
>> on a
>> wait queue, paused while qemu does its thing, paused while a mem event
>> is
>> processed...
>>
>> When the vcpu wakes up it receives the "late" hpet tick. We believe
>> Windows 7 QPC also reads the TSC at that point. The TSC kept on ticking
>> while the vcpu was paused. Windows does not know what to do about the
>> discrepancy and reports a large time leap, usually consistent with a
>> full
>> round trip of the 32 bit hpet counter at the Xen-emulated 1/16GHz
>> frequency.
>>
>> MSDN forums blame "bad hardware" for this. Funny.
>>
>> So, we could solve our particular problem if the tsc were not to tick
>> during
>> vcpu sleep. And I get an inkling that would help with this post as well.
>> But I
>> don't think any of the advertised timer or tsc modes do that.
>>
>> Thanks,
>> Andres
>>
>>
>>
>> I'm not sure this will help with the original post, but there's gotta be
>> somebody who
>> >
>> >> But, practically, is there a safe CPU configuration?
>> >
>> > I think that part of the problem here is that it is very hard to
>> > determine this at the hardware level. There are at least 3 (if not
>> > more) CPUID feature bits which say "no really, the TSC is good and
>> > safe to use this time, you can rely on that" because they keep
>> > inventing new ways to get it wrong.
>> >
>> > [...]
>> >>
>> >> Since September, I can't find any further information about this
>> >> issue. What is the state of this issue?  The inconsistency I see
>> >> right now is this: in the July 2010 TSC discussion, a "Stefano
>> Stabellini"
>> >> posted this:
>> >>
>> >> ====
>> >> > /me wonders if timer_mode=1 is the default for xl?
>> >> > Or only for xm?
>> >>
>> >> no, it is not.
>> >> Xl defaults to 0 [zero], I am going to change it right now.
>> >> ====
>> >>
>> >> So, it seems like (at least as of July 2010), xl is defaulting to
>> >> "timer_mode=1".  That is, assuming that the then-current timer_mode
>> >> is the same as present-day tsc_mode.
>> >
>> > No, I believe they are different things.
>> >
>> > tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
>> > xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)
>> >
>> > timer_mode is to do with the the way that timer interrupts are
>> > injected into the guest. This is described in
>> xen/include/public/hvm/params.h.
>> > This isn't documented in xl.cfg(5) because I couldn't make head nor
>> > tail of the meaning of that header :-(
>> >
>> >>   In addition, I'm assuming he was changing it from 0 (zero) to 1
>> >> (one)--and not some other mode.  But,
>> >>
>> >>         xen-4.1.2/docs/misc/tscmode.txt
>> >
>> > Remember that he was referring to timer_mode not tsc_mode...
>> >
>> >> says:
>> >>
>> >>         "The default mode (tsc_mode==0) checks TSC-safeness of the
>> >> underlying
>> >>         hardware on which the virtual machine is launched.  If it is
>> >>         TSC-safe, rdtsc will execute at hardware speed; if it is not,
>> >> rdtsc
>> >>         will be emulated."
>> >>
>> >> Which implies the default is always 0 (zero).  Which is it?
>> >
>> > It seems that xl, in xen-unstable, defaults to:
>> > 	timer_mode = 1
>> > 	tsc_mode = 0
>> > as does 4.1 as far as I can tell via code inspection.
>> >
>> >> More importantly, is the solution to force tsc_mode=2?
>> >
>> > IMHO this is safe in most situations unless you are running some sort
>> > of workload (e.g. a well known database) which has stringent
>> > requirements regarding the TSC for transactional consistency (hence
>> > the conservative default).
>> >
>> >>   If so, under what BIOS/xen-boot-params/dom0-boot-params
>> conditions?
>> >> And--please excuse my exasperation--but WTH does this have to do with
>> >> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
>> >> "jumpiness" (if that's even what's happening)?
>> >
>> > Sorry, I have no idea how/why the filesystem would be related to the
>> > TSC.
>> >
>> > It is possible you are actually seeing two bugs I suppose -- there
>> > have been issues relating to ext4 and barriers in some kernel versions
>> > (I'm afraid I don't recall the details, the list archives ought to
>> > contain something).
>> >
>> > Ian.
>> >
>> >
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:06:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyT8X-0003vp-Li; Fri, 17 Feb 2012 19:06:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyT8V-0003vf-O6
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:06:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329505580!13416951!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTUxMDY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19538 invoked from network); 17 Feb 2012 19:06:20 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-13.tower-21.messagelabs.com with SMTP;
	17 Feb 2012 19:06:20 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 0BA7B4B0091;
	Fri, 17 Feb 2012 11:06:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=ert01K/uBwuh8eZofBaBiam0QYgpvd6DPYiyc1btAcVW
	UwmIMTfLN82udZqEkr6FU3uxzUXdRFy8DbQiA5dqR2/9Ljq8ZOG1Bt4qcRgPjNKI
	in9WVSPg7topSGWCYNWEMCdLLnQrTgbi+njlP/EQaJXN5J8t2z631iyORtrkj1U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xoFKWt0KPW1yWZ2n43B3ZwGJ7jE=; b=LzMCsUgO
	rt6ije8YyaUMntuAM4oIrvcZoBqASJNOU6N0q7WG3aqfUfv8z+qV9vU2AaFDcgBu
	+DQLeAJZe+dnM0mpmL+xGeVmxsGxZwf18tk3C0mtaxDn7Mf+hA8igor3IW75YOPd
	LWDKdvyiPhOyjcxhBqQhzhnbGnumo389Jjk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id B53484B008F; 
	Fri, 17 Feb 2012 11:06:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 11:06:19 -0800
Message-ID: <0db5d62c10cd88eb11881a1cae41cdfe.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
	<91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
	<291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
Date: Fri, 17 Feb 2012 11:06:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> IIRC Windows (7) calibrates tsc against RTC at start of day and you can
> get some pretty odd results if a vcpu is descheduled during that
> calculation. I was not aware of the exact scenario you described. You
> *can* get the equivalent of the /usepmtimer boot.ini option on more recent
> OS by doing:
>
> bcdedit /set useplatformclock true
Hey Paul,
we've tried that, no joy.

>
> Enabling viridian timers in Xen may be the way to go though.
I'm looking at xen code (and various XenServer versions as well). I don't
see any timer implementations, at least not anything from the msdn
references (e.g. HV_X64_MSR_REFERENCE_TSC, HV_X64_MSR_STIMER0_CONFIG, etc)

Am I looking in the wrong place?
Thanks
Andres

>
>   Paul
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
>> Sent: 17 February 2012 16:28
>> To: xen-devel@lists.xensource.com
>> Cc: Ian Campbell; Qrux
>> Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
>>
>> > Date: Fri, 17 Feb 2012 12:06:05 +0000
>> > From: Ian Campbell <Ian.Campbell@citrix.com>
>> > To: Qrux <qrux.qed@gmail.com>
>> > Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>> > Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
>> > Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com>
>> > Content-Type: text/plain; charset="UTF-8"
>> >
>> > I'm afraid I don't know the answer to most of your questions (hence
>> > I'm afraid I've trimmed the quotes rather aggressively) but here's
>> > some of what I do know.
>>
>> I'm gonna add another data point.
>>
>> We're seeing the Windows 7 Query Performance Counter get mightily
>> confused. People have reported this in Amazon EC2 as well
>> https://forums.aws.amazon.com/thread.jspa?threadID=41426
>>
>> We've tracked it down to the hpet. Xen schedules an interrupt delivery
>> for
>> an hpet tick, but the vcpu is asleep. Could be an admin pause, a sleep
>> on a
>> wait queue, paused while qemu does its thing, paused while a mem event
>> is
>> processed...
>>
>> When the vcpu wakes up it receives the "late" hpet tick. We believe
>> Windows 7 QPC also reads the TSC at that point. The TSC kept on ticking
>> while the vcpu was paused. Windows does not know what to do about the
>> discrepancy and reports a large time leap, usually consistent with a
>> full
>> round trip of the 32 bit hpet counter at the Xen-emulated 1/16GHz
>> frequency.
>>
>> MSDN forums blame "bad hardware" for this. Funny.
>>
>> So, we could solve our particular problem if the tsc were not to tick
>> during
>> vcpu sleep. And I get an inkling that would help with this post as well.
>> But I
>> don't think any of the advertised timer or tsc modes do that.
>>
>> Thanks,
>> Andres
>>
>>
>>
>> I'm not sure this will help with the original post, but there's gotta be
>> somebody who
>> >
>> >> But, practically, is there a safe CPU configuration?
>> >
>> > I think that part of the problem here is that it is very hard to
>> > determine this at the hardware level. There are at least 3 (if not
>> > more) CPUID feature bits which say "no really, the TSC is good and
>> > safe to use this time, you can rely on that" because they keep
>> > inventing new ways to get it wrong.
>> >
>> > [...]
>> >>
>> >> Since September, I can't find any further information about this
>> >> issue. What is the state of this issue?  The inconsistency I see
>> >> right now is this: in the July 2010 TSC discussion, a "Stefano
>> Stabellini"
>> >> posted this:
>> >>
>> >> ====
>> >> > /me wonders if timer_mode=1 is the default for xl?
>> >> > Or only for xm?
>> >>
>> >> no, it is not.
>> >> Xl defaults to 0 [zero], I am going to change it right now.
>> >> ====
>> >>
>> >> So, it seems like (at least as of July 2010), xl is defaulting to
>> >> "timer_mode=1".  That is, assuming that the then-current timer_mode
>> >> is the same as present-day tsc_mode.
>> >
>> > No, I believe they are different things.
>> >
>> > tsc_mode is to do with the TSC, emulation vs direct exposure etc. Per
>> > xen/include/asm-x86/time.h and (in recent xen-unstable) xl.cfg(5)
>> >
>> > timer_mode is to do with the the way that timer interrupts are
>> > injected into the guest. This is described in
>> xen/include/public/hvm/params.h.
>> > This isn't documented in xl.cfg(5) because I couldn't make head nor
>> > tail of the meaning of that header :-(
>> >
>> >>   In addition, I'm assuming he was changing it from 0 (zero) to 1
>> >> (one)--and not some other mode.  But,
>> >>
>> >>         xen-4.1.2/docs/misc/tscmode.txt
>> >
>> > Remember that he was referring to timer_mode not tsc_mode...
>> >
>> >> says:
>> >>
>> >>         "The default mode (tsc_mode==0) checks TSC-safeness of the
>> >> underlying
>> >>         hardware on which the virtual machine is launched.  If it is
>> >>         TSC-safe, rdtsc will execute at hardware speed; if it is not,
>> >> rdtsc
>> >>         will be emulated."
>> >>
>> >> Which implies the default is always 0 (zero).  Which is it?
>> >
>> > It seems that xl, in xen-unstable, defaults to:
>> > 	timer_mode = 1
>> > 	tsc_mode = 0
>> > as does 4.1 as far as I can tell via code inspection.
>> >
>> >> More importantly, is the solution to force tsc_mode=2?
>> >
>> > IMHO this is safe in most situations unless you are running some sort
>> > of workload (e.g. a well known database) which has stringent
>> > requirements regarding the TSC for transactional consistency (hence
>> > the conservative default).
>> >
>> >>   If so, under what BIOS/xen-boot-params/dom0-boot-params
>> conditions?
>> >> And--please excuse my exasperation--but WTH does this have to do with
>> >> ext3 versus ext4?  Is ext4 exquisitely sensitive to TSC/HPET
>> >> "jumpiness" (if that's even what's happening)?
>> >
>> > Sorry, I have no idea how/why the filesystem would be related to the
>> > TSC.
>> >
>> > It is possible you are actually seeing two bugs I suppose -- there
>> > have been issues relating to ext4 and barriers in some kernel versions
>> > (I'm afraid I don't recall the details, the list archives ought to
>> > contain something).
>> >
>> > Ian.
>> >
>> >
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:10:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTBk-00043g-A7; Fri, 17 Feb 2012 19:09:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyTBi-00043U-A5
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 19:09:46 +0000
Received: from [85.158.139.83:39403] by server-9.bemta-5.messagelabs.com id
	76/A4-30171-9F5AE3F4; Fri, 17 Feb 2012 19:09:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329505783!15472827!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8548 invoked from network); 17 Feb 2012 19:09:44 -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; 17 Feb 2012 19:09:44 -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 q1HJ9dG3028911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:09:40 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
	q1HJ9cXb029428
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:09:38 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
	q1HJ9c0F032019; Fri, 17 Feb 2012 13:09:38 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:09:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5292241FE1; Fri, 17 Feb 2012 14:06:31 -0500 (EST)
Date: Fri, 17 Feb 2012 14:06:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217190631.GA20584@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<4F3E345802000078000739B2@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509F044@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509F044@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090208.4F3EA5F5.0014,ss=1,re=0.000,fgs=0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Kerneldevelopment list <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:59:56PM +0000, Liu, Jinsong wrote:
> >> 
> >> +static inline int __acpi_pad_init(void)
> >> +{
> >> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
> >> +
> >> +static inline void __acpi_pad_exit(void)
> >> +{
> >> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> >> +}
> > 
> > With this you, aiui, you aim at getting the calls patched. Are the
> > callers of this really on performance critical paths? If not, the
> > simpler approach of having an ops structure the fields of which get
> > overwritten by 
> > Xen initialization would seem a more appropriate approach.
> > 
> 
> Yes, I agree. I code in this way just want to keep same coding style as other pv functions of paravirt.h.
> I update the patch w/ a simpler approach, and will post later.
> Of course, we need Konrad's comments.

The thing is that the paravirt approach also impacts lguests. While I don't
think your patch will affect it, it just doesn't seem like the right place.

It seems that a more general approach, like the x86 one would be appropiate.
Or since this is ACPI related - perhaps in the drivers/acpi/osl.c ? - That is
all "OS dependent functions" and seem proper?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:10:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTBk-00043g-A7; Fri, 17 Feb 2012 19:09:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyTBi-00043U-A5
	for xen-devel@lists.xen.org; Fri, 17 Feb 2012 19:09:46 +0000
Received: from [85.158.139.83:39403] by server-9.bemta-5.messagelabs.com id
	76/A4-30171-9F5AE3F4; Fri, 17 Feb 2012 19:09:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329505783!15472827!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8548 invoked from network); 17 Feb 2012 19:09:44 -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; 17 Feb 2012 19:09:44 -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 q1HJ9dG3028911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:09:40 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
	q1HJ9cXb029428
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:09:38 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
	q1HJ9c0F032019; Fri, 17 Feb 2012 13:09:38 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:09:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5292241FE1; Fri, 17 Feb 2012 14:06:31 -0500 (EST)
Date: Fri, 17 Feb 2012 14:06:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120217190631.GA20584@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<4F3E345802000078000739B2@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509F044@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509F044@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090208.4F3EA5F5.0014,ss=1,re=0.000,fgs=0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Kerneldevelopment list <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:59:56PM +0000, Liu, Jinsong wrote:
> >> 
> >> +static inline int __acpi_pad_init(void)
> >> +{
> >> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
> >> +
> >> +static inline void __acpi_pad_exit(void)
> >> +{
> >> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> >> +}
> > 
> > With this you, aiui, you aim at getting the calls patched. Are the
> > callers of this really on performance critical paths? If not, the
> > simpler approach of having an ops structure the fields of which get
> > overwritten by 
> > Xen initialization would seem a more appropriate approach.
> > 
> 
> Yes, I agree. I code in this way just want to keep same coding style as other pv functions of paravirt.h.
> I update the patch w/ a simpler approach, and will post later.
> Of course, we need Konrad's comments.

The thing is that the paravirt approach also impacts lguests. While I don't
think your patch will affect it, it just doesn't seem like the right place.

It seems that a more general approach, like the x86 one would be appropiate.
Or since this is ACPI related - perhaps in the drivers/acpi/osl.c ? - That is
all "OS dependent functions" and seem proper?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:12:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTDZ-0004Ba-0e; Fri, 17 Feb 2012 19:11:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyTDX-0004BC-Cd
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:11:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329505892!12027918!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28621 invoked from network); 17 Feb 2012 19:11:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 19:11:33 -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 q1HJBU7R003954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:11: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
	q1HJBTj2002045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:11:30 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
	q1HJBTI2004772; Fri, 17 Feb 2012 13:11:29 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:11:29 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8010E41FE1; Fri, 17 Feb 2012 14:08:22 -0500 (EST)
Date: Fri, 17 Feb 2012 14:08:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120217190822.GB20584@phenom.dumpdata.com>
References: <CACeEFf42Wa38-6YJ+xYhs216QJK2yurCVKrn5=Ni0zZR9wM_mQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf42Wa38-6YJ+xYhs216QJK2yurCVKrn5=Ni0zZR9wM_mQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020209.4F3EA663.0062,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtual, physical and bus address on Dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 10:20:21AM -0800, Eric Camachat wrote:
> Consider the code:
> 
> dma_addr_t dma_addr, dma_addr2;
> phys_addr_t phys_addr;

> cpu_addr = pci_alloc_consistent(pdev, size, &dma_addr);
> phys_addr = virt_to_phys(cpu_addr);
> dma_addr2 = virt_to_bus(cpu_addr);
> 
> In Dom0 the outputs are:
> 
> dma_addr: 0xbc800000

You should use the dma_addr.

> phys_addr: 0x5b000000
> dma_addr2: 0x5b000000
> 
> Why the addresses are different in dma_addr and dma_addr2?

B/c you are doing a bit shift on the cpu_addr - both virt_to_phys
and virt_to_bus do exactly the same thing.

> Which one is the correct value I should use in DMA operations?

The one that pci_alloc_coherent gives you.
> 
> Eric
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:12:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTDZ-0004Ba-0e; Fri, 17 Feb 2012 19:11:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyTDX-0004BC-Cd
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:11:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329505892!12027918!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU0ODAwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28621 invoked from network); 17 Feb 2012 19:11:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2012 19:11:33 -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 q1HJBU7R003954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:11: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
	q1HJBTj2002045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:11:30 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
	q1HJBTI2004772; Fri, 17 Feb 2012 13:11:29 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:11:29 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8010E41FE1; Fri, 17 Feb 2012 14:08:22 -0500 (EST)
Date: Fri, 17 Feb 2012 14:08:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120217190822.GB20584@phenom.dumpdata.com>
References: <CACeEFf42Wa38-6YJ+xYhs216QJK2yurCVKrn5=Ni0zZR9wM_mQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf42Wa38-6YJ+xYhs216QJK2yurCVKrn5=Ni0zZR9wM_mQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020209.4F3EA663.0062,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtual, physical and bus address on Dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 10:20:21AM -0800, Eric Camachat wrote:
> Consider the code:
> 
> dma_addr_t dma_addr, dma_addr2;
> phys_addr_t phys_addr;

> cpu_addr = pci_alloc_consistent(pdev, size, &dma_addr);
> phys_addr = virt_to_phys(cpu_addr);
> dma_addr2 = virt_to_bus(cpu_addr);
> 
> In Dom0 the outputs are:
> 
> dma_addr: 0xbc800000

You should use the dma_addr.

> phys_addr: 0x5b000000
> dma_addr2: 0x5b000000
> 
> Why the addresses are different in dma_addr and dma_addr2?

B/c you are doing a bit shift on the cpu_addr - both virt_to_phys
and virt_to_bus do exactly the same thing.

> Which one is the correct value I should use in DMA operations?

The one that pci_alloc_coherent gives you.
> 
> Eric
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHM-0004Qf-8L; Fri, 17 Feb 2012 19:15: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 1RyTHK-0004Pw-OS
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26540 invoked from network); 17 Feb 2012 19:14:39 -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;
	17 Feb 2012 19:14:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208,223";a="10781643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHF-0006kJ-P5; Fri, 17 Feb 2012 19:15:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHF-00084U-N6;
	Fri, 17 Feb 2012 19:15:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 19:15:21 +0000
Message-ID: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>From Ian Jackson <ian.jackson@eu.citrix.com> # This line is ignored.
From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [RFC PATCH 0/6] libxl: New child process handling
In-Reply-To: 

This is the first draft of my new libxl API for child process
handling.

 1/6 libxl: Fix leak of ctx->lock
 2/6 libxl: abolish libxl_ctx_postfork
 3/6 tools: Correct PTHREAD options in config/StdGNU.mk
 4/6 libxl: Protect fds with CLOEXEC even with forking threads
 5/6 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 6/6 libxl: event API: new facilities for waiting for subprocesses

Please comment.  I'm particularly keen on comments about:

 * The correctness of the pthread_atfork logic in 4/6.
 * The sufficiency for applications of the child handling API in 6/6.
 * The portability of the pthread command line option changes in 3/6.
 * Correctness :-).

If you want to apply it to make sense of, you'll need to know that
this series is on top of my recently-posted 3-patch libxl event fixup
series.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHM-0004Qf-8L; Fri, 17 Feb 2012 19:15: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 1RyTHK-0004Pw-OS
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26540 invoked from network); 17 Feb 2012 19:14:39 -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;
	17 Feb 2012 19:14:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208,223";a="10781643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHF-0006kJ-P5; Fri, 17 Feb 2012 19:15:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHF-00084U-N6;
	Fri, 17 Feb 2012 19:15:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 19:15:21 +0000
Message-ID: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>From Ian Jackson <ian.jackson@eu.citrix.com> # This line is ignored.
From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [RFC PATCH 0/6] libxl: New child process handling
In-Reply-To: 

This is the first draft of my new libxl API for child process
handling.

 1/6 libxl: Fix leak of ctx->lock
 2/6 libxl: abolish libxl_ctx_postfork
 3/6 tools: Correct PTHREAD options in config/StdGNU.mk
 4/6 libxl: Protect fds with CLOEXEC even with forking threads
 5/6 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 6/6 libxl: event API: new facilities for waiting for subprocesses

Please comment.  I'm particularly keen on comments about:

 * The correctness of the pthread_atfork logic in 4/6.
 * The sufficiency for applications of the child handling API in 6/6.
 * The portability of the pthread command line option changes in 3/6.
 * Correctness :-).

If you want to apply it to make sense of, you'll need to know that
this series is on top of my recently-posted 3-patch libxl event fixup
series.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHK-0004QA-MQ; Fri, 17 Feb 2012 19:15: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 1RyTHJ-0004Q3-9E
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26572 invoked from network); 17 Feb 2012 19:14:40 -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;
	17 Feb 2012 19:14:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHH-0006kM-Ob; Fri, 17 Feb 2012 19:15:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHH-00084e-Nc;
	Fri, 17 Feb 2012 19:15:31 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 19:15:22 +0000
Message-ID: <1329506127-30969-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/6] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7735223..fd890cf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHK-0004QA-MQ; Fri, 17 Feb 2012 19:15: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 1RyTHJ-0004Q3-9E
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26572 invoked from network); 17 Feb 2012 19:14:40 -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;
	17 Feb 2012 19:14:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHH-0006kM-Ob; Fri, 17 Feb 2012 19:15:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHH-00084e-Nc;
	Fri, 17 Feb 2012 19:15:31 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 19:15:22 +0000
Message-ID: <1329506127-30969-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/6] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7735223..fd890cf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHP-0004RT-21; Fri, 17 Feb 2012 19:15:39 +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 1RyTHN-0004R4-Ga
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26686 invoked from network); 17 Feb 2012 19:14:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 19:14:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781646"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHM-0006kU-5j; Fri, 17 Feb 2012 19:15:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHM-00084r-4l;
	Fri, 17 Feb 2012 19:15:36 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:24 +0000
Message-ID: <1329506127-30969-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/6] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

So abolish PTHREAD_LIBS in StdGNU.mk, and add PTHREAD_CFLAGS and
PTHREAD_LDFLAGS instead.  Fix the one user (libxc).

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later version of this patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/StdGNU.mk     |    4 +++-
 tools/libxc/Makefile |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 2af2841..97445a7 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -68,10 +68,12 @@ XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
 CURSES_LIBS = -lncurses
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
+PTHREAD_CFLAGS = -pthread
+PTHREAD_LDFLAGS = -pthread
+
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..09e2f5f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -72,6 +72,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -156,7 +158,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHR-0004S6-G5; Fri, 17 Feb 2012 19:15: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 1RyTHP-0004RZ-MG
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26725 invoked from network); 17 Feb 2012 19:14:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 19:14:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHO-0006ka-9j; Fri, 17 Feb 2012 19:15:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHO-00084v-8s;
	Fri, 17 Feb 2012 19:15:38 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:25 +0000
Message-ID: <1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywherein libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

On Linux pthread_atfork demands compilation with -pthread, so add
PTHREAD_CFLAGS, _LDFLAGS, _LIBS to the corresponding variables in the
libxl Makefile.  It is not clear why we got away without these before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    6 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   10 +++
 tools/libxl/libxl_fork.c     |  167 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   65 ++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 253 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..a041294 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -26,6 +26,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
@@ -53,7 +57,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fd890cf..716163a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f889115..74a0402 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -369,6 +369,16 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl__postfork_child_noexec in the child.  One call
+ * for all libxl contexts is sufficient.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..66d0ee0
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered)
+        return 0;
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "pthread_atfork failed");
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+    int rc;
+
+    if (fd >= 0) {
+        rc = libxl_fd_set_cloexec(ctx, fd, 1);
+        if (rc) goto out;
+    }
+
+    cf = malloc(sizeof(*cf));
+    if (!cf) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to malloc for carefd");
+        goto out;
+    }
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+
+ out:
+    if (cf) free(cf);
+    return 0;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+    int r;
+
+    cf = libxl__carefd_record(ctx, fd);
+    if (!cf) {
+        r = close(fd);
+        if (r)
+            /* Carry on as best we can. */
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, "failed to close new fd");
+    }
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, "failed to close fd=%d"
+                             " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    LIBXL_LIST_REMOVE(cf, entry);
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7b8d0c2..088a417 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -588,6 +588,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1267,6 +1270,68 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  May fail due to lack of memory
+ * in which case it will have logged and will return NULL. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  If it fails and fd!=-1,
+ * it will close the fd before returning. */
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9fd67b4..d806077 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -97,6 +97,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHP-0004RT-21; Fri, 17 Feb 2012 19:15:39 +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 1RyTHN-0004R4-Ga
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26686 invoked from network); 17 Feb 2012 19:14:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 19:14:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781646"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHM-0006kU-5j; Fri, 17 Feb 2012 19:15:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHM-00084r-4l;
	Fri, 17 Feb 2012 19:15:36 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:24 +0000
Message-ID: <1329506127-30969-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/6] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

So abolish PTHREAD_LIBS in StdGNU.mk, and add PTHREAD_CFLAGS and
PTHREAD_LDFLAGS instead.  Fix the one user (libxc).

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later version of this patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/StdGNU.mk     |    4 +++-
 tools/libxc/Makefile |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 2af2841..97445a7 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -68,10 +68,12 @@ XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
 CURSES_LIBS = -lncurses
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
+PTHREAD_CFLAGS = -pthread
+PTHREAD_LDFLAGS = -pthread
+
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..09e2f5f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -72,6 +72,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -156,7 +158,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHR-0004S6-G5; Fri, 17 Feb 2012 19:15: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 1RyTHP-0004RZ-MG
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26725 invoked from network); 17 Feb 2012 19:14:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 19:14:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHO-0006ka-9j; Fri, 17 Feb 2012 19:15:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHO-00084v-8s;
	Fri, 17 Feb 2012 19:15:38 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:25 +0000
Message-ID: <1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywherein libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

On Linux pthread_atfork demands compilation with -pthread, so add
PTHREAD_CFLAGS, _LDFLAGS, _LIBS to the corresponding variables in the
libxl Makefile.  It is not clear why we got away without these before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    6 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   10 +++
 tools/libxl/libxl_fork.c     |  167 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   65 ++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 253 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..a041294 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -26,6 +26,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
@@ -53,7 +57,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fd890cf..716163a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f889115..74a0402 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -369,6 +369,16 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl__postfork_child_noexec in the child.  One call
+ * for all libxl contexts is sufficient.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..66d0ee0
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered)
+        return 0;
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "pthread_atfork failed");
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+    int rc;
+
+    if (fd >= 0) {
+        rc = libxl_fd_set_cloexec(ctx, fd, 1);
+        if (rc) goto out;
+    }
+
+    cf = malloc(sizeof(*cf));
+    if (!cf) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to malloc for carefd");
+        goto out;
+    }
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+
+ out:
+    if (cf) free(cf);
+    return 0;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+    int r;
+
+    cf = libxl__carefd_record(ctx, fd);
+    if (!cf) {
+        r = close(fd);
+        if (r)
+            /* Carry on as best we can. */
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, "failed to close new fd");
+    }
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, "failed to close fd=%d"
+                             " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    LIBXL_LIST_REMOVE(cf, entry);
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7b8d0c2..088a417 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -588,6 +588,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1267,6 +1270,68 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  May fail due to lack of memory
+ * in which case it will have logged and will return NULL. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  If it fails and fd!=-1,
+ * it will close the fd before returning. */
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9fd67b4..d806077 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -97,6 +97,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHM-0004Qs-L5; Fri, 17 Feb 2012 19:15: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 1RyTHL-0004QE-9q
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26632 invoked from network); 17 Feb 2012 19:14:43 -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;
	17 Feb 2012 19:14:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHJ-0006kP-UG; Fri, 17 Feb 2012 19:15:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHJ-00084i-TL;
	Fri, 17 Feb 2012 19:15:33 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:23 +0000
Message-ID: <1329506127-30969-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/6] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bffa03..19ef1de 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -312,7 +312,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index cd819c8..9f9f91d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -399,13 +399,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..9fd67b4 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -95,6 +95,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 702b208..394a128 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c58e9f3..2018153 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1422,7 +1422,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1709,11 +1709,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHM-0004Qs-L5; Fri, 17 Feb 2012 19:15: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 1RyTHL-0004QE-9q
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26632 invoked from network); 17 Feb 2012 19:14:43 -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;
	17 Feb 2012 19:14:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHJ-0006kP-UG; Fri, 17 Feb 2012 19:15:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHJ-00084i-TL;
	Fri, 17 Feb 2012 19:15:33 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:23 +0000
Message-ID: <1329506127-30969-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/6] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bffa03..19ef1de 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -312,7 +312,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index cd819c8..9f9f91d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -399,13 +399,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..9fd67b4 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -95,6 +95,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 702b208..394a128 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c58e9f3..2018153 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1422,7 +1422,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1709,11 +1709,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19: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.xensource.com>)
	id 1RyTHY-0004UZ-TF; Fri, 17 Feb 2012 19:15:48 +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 1RyTHX-0004SK-8e
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26791 invoked from network); 17 Feb 2012 19:14:50 -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;
	17 Feb 2012 19:14:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHQ-0006kd-Vy; Fri, 17 Feb 2012 19:15:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHQ-00084z-V3;
	Fri, 17 Feb 2012 19:15:40 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:26 +0000
Message-ID: <1329506127-30969-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/6] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 522bd99..8542e24 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19: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.xensource.com>)
	id 1RyTHY-0004UZ-TF; Fri, 17 Feb 2012 19:15:48 +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 1RyTHX-0004SK-8e
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26791 invoked from network); 17 Feb 2012 19:14:50 -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;
	17 Feb 2012 19:14:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHQ-0006kd-Vy; Fri, 17 Feb 2012 19:15:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHQ-00084z-V3;
	Fri, 17 Feb 2012 19:15:40 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 17 Feb 2012 19:15:26 +0000
Message-ID: <1329506127-30969-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/6] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 522bd99..8542e24 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:16:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHa-0004Vb-Fc; Fri, 17 Feb 2012 19:15:50 +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 1RyTHY-0004TC-BU
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26837 invoked from network); 17 Feb 2012 19:14: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;
	17 Feb 2012 19:14:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHT-0006kg-QS; Fri, 17 Feb 2012 19:15:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHT-000853-PE;
	Fri, 17 Feb 2012 19:15:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 19:15:27 +0000
Message-ID: <1329506127-30969-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 6/6] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl_event.c    |   52 +++++++--
 tools/libxl/libxl_event.h    |  142 ++++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  242 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   61 ++++++++++-
 5 files changed, 494 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 716163a..06ac064 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 8542e24..6e4c50c 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -620,6 +620,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -749,10 +753,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -763,11 +768,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1063,16 +1073,36 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 74a0402..869431d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -161,11 +161,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -370,6 +365,142 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     The application must install a SIGCHLD handler and reap (at
+ *     least) all of libxl's children and pass their exit status
+ *     to libxl by calling libxl_childproc_exited.
+ *
+ *     An application which does this must call
+ *     libxl_childproc_setmode.
+ * 
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_NOT_READY if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_NOT_READY.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
@@ -379,6 +510,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 void libxl_postfork_child_noexec(libxl_ctx *ctx);
 
 
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 66d0ee0..07d9ccf 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -129,6 +135,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -138,6 +145,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -159,6 +170,237 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_NOT_READY;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->callback(egc, ch, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc) {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                CTX->childproc_hooks->reaped_callback
+                    (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+            } else {
+                LIBXL__LOG(CTX, LIBXL__LOG_WARNING, "unknown child [%ld]"
+                           " exited with status=%d", (long)pid, status);
+            }
+        }
+    }
+}
+
+int libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                         libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 088a417..f4328f0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -179,6 +179,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -248,6 +261,8 @@ struct libxl__ctx {
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
 
+    LIBXL_LIST_ENTRY(struct libxl__ctx);
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -288,10 +303,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -534,6 +553,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon, and should not make
+ * any further libxl event calls in the meantime.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  Either death or cldstop may be
+ * NULL in which case that kind of event is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden int libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -587,6 +633,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:16:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTHa-0004Vb-Fc; Fri, 17 Feb 2012 19:15:50 +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 1RyTHY-0004TC-BU
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:15:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329506079!54730354!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26837 invoked from network); 17 Feb 2012 19:14: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;
	17 Feb 2012 19:14:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,439,1325462400"; d="scan'208";a="10781650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 19:15:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 19:15:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RyTHT-0006kg-QS; Fri, 17 Feb 2012 19:15:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RyTHT-000853-PE;
	Fri, 17 Feb 2012 19:15:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 19:15:27 +0000
Message-ID: <1329506127-30969-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 6/6] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl_event.c    |   52 +++++++--
 tools/libxl/libxl_event.h    |  142 ++++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  242 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   61 ++++++++++-
 5 files changed, 494 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 716163a..06ac064 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 8542e24..6e4c50c 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -620,6 +620,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -749,10 +753,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -763,11 +768,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1063,16 +1073,36 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 74a0402..869431d 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -161,11 +161,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -370,6 +365,142 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     The application must install a SIGCHLD handler and reap (at
+ *     least) all of libxl's children and pass their exit status
+ *     to libxl by calling libxl_childproc_exited.
+ *
+ *     An application which does this must call
+ *     libxl_childproc_setmode.
+ * 
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_NOT_READY if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_NOT_READY.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
@@ -379,6 +510,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 void libxl_postfork_child_noexec(libxl_ctx *ctx);
 
 
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 66d0ee0..07d9ccf 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -129,6 +135,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -138,6 +145,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -159,6 +170,237 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_NOT_READY;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->callback(egc, ch, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc) {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                CTX->childproc_hooks->reaped_callback
+                    (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+            } else {
+                LIBXL__LOG(CTX, LIBXL__LOG_WARNING, "unknown child [%ld]"
+                           " exited with status=%d", (long)pid, status);
+            }
+        }
+    }
+}
+
+int libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                         libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 088a417..f4328f0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -179,6 +179,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -248,6 +261,8 @@ struct libxl__ctx {
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
 
+    LIBXL_LIST_ENTRY(struct libxl__ctx);
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -288,10 +303,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -534,6 +553,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon, and should not make
+ * any further libxl event calls in the meantime.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  Either death or cldstop may be
+ * NULL in which case that kind of event is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden int libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -587,6 +633,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:22:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTNv-0005bt-D1; Fri, 17 Feb 2012 19:22:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyTNt-0005bo-T5
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:22:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329506534!13673280!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17722 invoked from network); 17 Feb 2012 19:22:15 -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; 17 Feb 2012 19:22:15 -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 q1HJMAsi007168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:22:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1HJM9bt000007
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:22:10 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
	q1HJM9Kd007816; Fri, 17 Feb 2012 13:22:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:22:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3AFB941FE1; Fri, 17 Feb 2012 14:19:02 -0500 (EST)
Date: Fri, 17 Feb 2012 14:19:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <20120217191902.GD20584@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
	<1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F3EA8E3.014A,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> Hmm, this kind of stuff should be discussed on lkml.
> 
> I doubt we want yet another memory allocator, with a global lock
> (contended), and no NUMA properties.

That should be fixed. Are there any existing memory pools that could be used
instead? I (And I think everybody) is all for using the existing APIs if  they
can do the job. I was lookign a bit at the dmapool code, but that requires something
we don't have  - the 'struct device'. We could manufacture a fake one, but that just
stinks of hack.

It [pagepool] also should use the shrinker API I think.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 19:22:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 19:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyTNv-0005bt-D1; Fri, 17 Feb 2012 19:22:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RyTNt-0005bo-T5
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 19:22:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329506534!13673280!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTQ5MjA3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17722 invoked from network); 17 Feb 2012 19:22:15 -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; 17 Feb 2012 19:22:15 -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 q1HJMAsi007168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 17 Feb 2012 19:22:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1HJM9bt000007
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 17 Feb 2012 19:22:10 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
	q1HJM9Kd007816; Fri, 17 Feb 2012 13:22:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 17 Feb 2012 11:22:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3AFB941FE1; Fri, 17 Feb 2012 14:19:02 -0500 (EST)
Date: Fri, 17 Feb 2012 14:19:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <20120217191902.GD20584@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
	<1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F3EA8E3.014A,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> Hmm, this kind of stuff should be discussed on lkml.
> 
> I doubt we want yet another memory allocator, with a global lock
> (contended), and no NUMA properties.

That should be fixed. Are there any existing memory pools that could be used
instead? I (And I think everybody) is all for using the existing APIs if  they
can do the job. I was lookign a bit at the dmapool code, but that requires something
we don't have  - the 'struct device'. We could manufacture a fake one, but that just
stinks of hack.

It [pagepool] also should use the shrinker API I think.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyUCo-0006MV-F9; Fri, 17 Feb 2012 20:14:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RyUCm-0006MP-Pl
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:14:57 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329509642!54733818!1
X-Originating-IP: [98.139.44.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21381 invoked from network); 17 Feb 2012 20:14:02 -0000
Received: from nm13.access.bullet.mail.sp2.yahoo.com (HELO
	nm13.access.bullet.mail.sp2.yahoo.com) (98.139.44.140)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 20:14:02 -0000
Received: from [98.139.44.103] by nm13.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 17 Feb 2012 20:14:53 -0000
Received: from [98.139.44.71] by tm8.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 17 Feb 2012 20:14:52 -0000
Received: from [127.0.0.1] by omp1008.access.mail.sp2.yahoo.com with NNFMP;
	17 Feb 2012 20:14:52 -0000
X-Yahoo-Newman-Id: 941165.70111.bm@omp1008.access.mail.sp2.yahoo.com
Received: (qmail 14321 invoked from network); 17 Feb 2012 20:14:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1329509692; bh=8iJf//qsdZYyzqm8CZ/ZxmaC4FP7LUUFjxM0S/rH+XY=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=a8LHdsYQQ6Pse66ixCbyamYuKcgxPIuYV9dALu5f6teFT17+Fy8HYKUX/udO1xddNZYaMwNds24wdZ7GKyz7EljNFar7FDdhKhWWG5ooDlwiesf/vEqjFcXwYT7t7SnUhSIJXufUegwvdS+dtVaC6lAUkkA/QGwqYEJ1svMSxag=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jb4.LFcVM1m5mQ5vS6vYbvoPCqDHgtaG.DbG8HFBgwk_mjW
	w6YYLczecKZZBjQqnNyVNSvy9ddvtzqaHq2ITSMntIC16Tmh5RuzlVE1u3az
	_BrQW63Ed3h_gX9AfRchE5afjGq1jmtTy9Dfbw5OSUbJWRn8JwKZdpQYHPSR
	ld1tbDtdn.xQvZC7sLWWdi2rpx.kBhhA95yLgMgpCJ6ZYngvJpgsRiBr2QHp
	dqZtwt9yOcTH0uBi0ei4T0PNNFyTZ6o1kVS0UJluqncODnJVo3pcIuHiX.sk
	JPc_eNCtzykfW3ukToDamVnpYSVCqoTCPTCRHydCmgl5QmMeFKiHctLt3nOe
	cVcuUNzaAibzXtmN_UQ9qD8KLypD1gonaYoflqffKLkHUDeH4GNr6JgGTIpl
	KglM4uyOsIZRE2Hg-
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.191 with plain)
	by smtp110.sbc.mail.gq1.yahoo.com with SMTP;
	17 Feb 2012 12:14:51 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 17 Feb 2012 15:14:39 -0500
Message-ID: <1354954.T2Gh7Kz0zK@dell4550>
User-Agent: KMail/4.8.0 (Linux/3.1.9-1.4-default; KDE/4.8.0; i686; ; )
In-Reply-To: <1329474132.3131.22.camel@zakaz.uk.xensource.com>
References: <51142288.L1Ice6IuWj@dell4550>
	<1329474132.3131.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Problems with stubdoms, and xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6429182619952053582=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6429182619952053582==
Content-Type: multipart/alternative; boundary="nextPart1596651.7dWOSpoz9S"
Content-Transfer-Encoding: 7Bit


--nextPart1596651.7dWOSpoz9S
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:
> On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:
> [...]
> 
> > 1) After my winxp hvm domu, started with a stubdom, got some windows
> > updates yesterday, I restarted (not shutdown), and the new domain hung
> > in pause:
> [..]
> 
> I tried this with win7 on xen-unstable and it worked ok. This may be a
> bug specific to 4.1.

Good to know! Thank you very much for taking the time to look at this.

> [...]
> 
> > xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"
> > 
> > and only got a syntax error on the '-d'.
> 
> I don't think this approach is advised but FWIW the error here is
> probably lack of quoting of the " against the shell. You would have
> needed
> 	... extra=\" -d 8\"

Ouch! I was trying to quote the '-' in -d!

> > So my question is: is this a bug, and is it fixed in xen 4.2?
> 
> The failure to restart the stub DM when rebooting a VM is a bug, AFAICT
> it is fixed in unstable and therefore will be fixed in 4.2.
> 
> I've not been able to spot a specific changeset with the fix, but there
> was quite a lot to wade through.
> 
> > 2) I'm having a strange problem right after I get a xen update from
> > rawhide: stubdoms stop working for a day after wards. It happened with
> > fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at
> > whether something in /var/lib/xen* changed.
> 
> Stop working for a day and then magically starts working? Or stops
> working for a day until the next update?

As it turns out, both, the two times it happened to me. Stubdoms stop working 
until the next yum update, but nothing installed the next day has any 
relationship to xen or a kernel. Whether or not it would have worked 1/2 hour 
before the yum update is not something I have had an opportunity to explore 
yet. Of course, a yum update is frequently accompanied by a systemd restart, 
which could have an effect.

Whenever I get a rawhide xen or kernel update, I usually reboot to test the 
update for regressions/bugs, then reboot back to the highest version kernel I 
have w/o debug options turned off (before the next yum update). Thus, a full 
reboot, twice, doesn't fix the problem. So I would think that a simple systemd 
restart wouldn't, either. That's why the next thing I intend to look at would 
be whether anything got damaged/not regenerated in /var/lib/xen*. Another 
possibility is that xend is still running. I usually take care not to mix xm 
and xl commands in one boot session. If I do mix them, I usually stop any 
domus, and do an 'xm mem-set 0 ...' back to the boot value in my system, and 
then use only one of the xm / xl commands thereafter. (It is really 
disconcerting to see xm list, xl list report differing dom0 memory amounts!) 
Anyway, stopping xend and trying stubdoms again is something else I will try.

> > 3) Specifying vncviewer=1 will automatically start a vnc viewer for
> > you
> 
> [...]
> 
> > 4) The 'localtime=1' option in your config is ignored by xl. This
> > works with
> 
> [...]
> 
> > The answer given to the two above problems at the time was essentially
> > that they had not been implemented. Have they been implemented in xen
> > 4.2 yet?
> 
> Not as far as I can tell with grep. Patches would be greatly
> appreciated, these should be relatively simple issues for a newcomer to
> tackle with only basic C required I think, I'd be glad to advise etc.
> 
> I'll add these as "nice to have" in the 4.2 TODO thread.

That is greatly appreciated. While I was a programmer awhile back, I have not 
read the xen code, and the learning curve there, and in learning how to write 
*acceptable* patches is more than my time constraints currently allow. I 
confine my time to administrative duties, and looking for bugs / regressions 
to report, and helping the occasional user on Xen-users with what I *have* 
learned. 

[...]
> >  Also, while device_model_args does indeed add '-localtime' to the end
> > 
> > of the qemu-dm args, it's still ineffective.
> 
> I'm not 100% sure of this but I don't think xm's "localtime" corresponds
> to solely passing "-localtime" to the DM (although it may also do that
> also).
> 
> I think it needs to turn into a hypercall to tell the hypervisor about
> the guests time offset, e.g. a call to xc_domain_set_time_offset. The
> rtc_timeoffset option relates to this call as well.

That makes sense. Thanx.

> In a Xen system the RTC is emulated by the hypervisor not by qemu (it
> used to be done by qemu many moons ago, which might explain the
> vestigial passing of -localtime to qemu).

And I've been with xen since the 3.0 days, so features start merging in my 
head! Thanx for the clarity!.

> > And 2) If you have GPLPV installed in your domain, it completely takes
> > over. Booting with GPLPV enabled is no faster with stubdoms as
> > without. Booting with /nogplpv is just as slow as if you booted
> > without stubdoms. I suspect xenpci.sys is overriding what stubdoms is
> > doing.
> 
> If you are using PV devices then you won't be hitting the emulated
> devices (which is what is in the stubdom) all that much after the very
> early boot stages IOW after anything which uses BIOS int13 hook e.g. the
> bootloader. If you aren't hitting the emulated devices then putting them
> in stubdom vs dom0 won't make much odds to the performance.
> 
> Ian.

Makes sense. The main thing that I was disappointed in was that even booting 
with /nogplpv didn't result in a speed increase. xenpci.sys seems to take over 
completely, even in that case.

Thanx again for your time and interest.
--nextPart1596651.7dWOSpoz9S
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/=
REC-html40/strict.dtd">
<html><head><meta name=3D"qrichtext" content=3D"1" /><style type=3D"tex=
t/css">
p, li { white-space: pre-wrap; }
</style></head><body style=3D" font-family:'Courier [Adobe]'; font-size=
:9pt; font-weight:400; font-style:normal;">
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">On =
Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 1) After my winxp hvm domu, started with a stubdom, got some win=
dows</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; updates yesterday, I restarted (not shutdown), and the new domai=
n hung</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; in pause:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [..]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I tried this with win7 on xen-unstable and it worked ok. This may be =
a</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; bug specific to 4.1.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Goo=
d to know! Thank you very much for taking the time to look at this.</p>=

<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; xl create /etc/xen/winxp-dm target=3D8 memory=3D32 extra=3D&quot=
; -d 8&quot;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; and only got a syntax error on the '-d'.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I don't think this approach is advised but FWIW the error here is</p>=

<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; probably lack of quoting of the &quot; against the shell. You would h=
ave</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; needed</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; =09... extra=3D\&quot; -d 8\&quot;</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Ouc=
h! I was trying to quote the '-' in -d!</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; So my question is: is this a bug, and is it fixed in xen 4.2?</p=
>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; The failure to restart the stub DM when rebooting a VM is a bug, AFAI=
CT</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; it is fixed in unstable and therefore will be fixed in 4.2.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I've not been able to spot a specific changeset with the fix, but the=
re</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; was quite a lot to wade through.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 2) I'm having a strange problem right after I get a xen update f=
rom</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; rawhide: stubdoms stop working for a day after wards. It happene=
d with</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; fedora xen 4.1.2-7 and -8. The next time it happens, I'll look a=
t</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; whether something in /var/lib/xen* changed.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; Stop working for a day and then magically starts working? Or stops</p=
>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; working for a day until the next update?</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">As =
it turns out, both, the two times it happened to me. Stubdoms stop work=
ing until the next yum update, but nothing installed the next day has a=
ny relationship to xen or a kernel. Whether or not it would have worked=
 1/2 hour before the yum update is not something I have had an opportun=
ity to explore yet. Of course, a yum update is frequently accompanied b=
y a systemd restart, which could have an effect.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Whe=
never I get a rawhide xen or kernel update, I usually reboot to test th=
e update for regressions/bugs, then reboot back to the highest version =
kernel I have w/o debug options turned off (before the next yum update)=
. Thus, a full reboot, twice, doesn't fix the problem. So I would think=
 that a simple systemd restart wouldn't, either. That's why the next th=
ing I intend to look at would be whether anything got damaged/not regen=
erated in /var/lib/xen*. Another possibility is that xend is still runn=
ing. I usually take care not to mix xm and xl commands in one boot sess=
ion. If I do mix them, I usually stop any domus, and do an 'xm mem-set =
0 ...' back to the boot value in my system, and then use only one of th=
e xm / xl commands thereafter. (It is really disconcerting to see xm li=
st, xl list report differing dom0 memory amounts!) Anyway, stopping xen=
d and trying stubdoms again is something else I will try.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 3) Specifying vncviewer=3D1 will automatically start a vnc viewe=
r for</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; you</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 4) The 'localtime=3D1' option in your config is ignored by xl. T=
his</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; works with</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; The answer given to the two above problems at the time was essen=
tially</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; that they had not been implemented. Have they been implemented i=
n xen</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 4.2 yet?</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; Not as far as I can tell with grep. Patches would be greatly</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; appreciated, these should be relatively simple issues for a newcomer =
to</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; tackle with only basic C required I think, I'd be glad to advise etc.=
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I'll add these as &quot;nice to have&quot; in the 4.2 TODO thread.</p=
>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Tha=
t is greatly appreciated. While I was a programmer awhile back, I have =
not read the xen code, and the learning curve there, and in learning ho=
w to write *acceptable* patches is more than my time constraints curren=
tly allow. I confine my time to administrative duties, and looking for =
bugs / regressions to report, and helping the occasional user on Xen-us=
ers with what I *have* learned. </p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">[..=
.]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt;  Also, while device_model_args does indeed add '-localtime' to t=
he end</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; of the qemu-dm args, it's still ineffective.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I'm not 100% sure of this but I don't think xm's &quot;localtime&quot=
; corresponds</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; to solely passing &quot;-localtime&quot; to the DM (although it may a=
lso do that</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; also).</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I think it needs to turn into a hypercall to tell the hypervisor abou=
t</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; the guests time offset, e.g. a call to xc_domain_set_time_offset. The=
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; rtc_timeoffset option relates to this call as well.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Tha=
t makes sense. Thanx.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; In a Xen system the RTC is emulated by the hypervisor not by qemu (it=
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; used to be done by qemu many moons ago, which might explain the</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; vestigial passing of -localtime to qemu).</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">And=
 I've been with xen since the 3.0 days, so features start merging in my=
 head! Thanx for the clarity!.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; And 2) If you have GPLPV installed in your domain, it completely=
 takes</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; over. Booting with GPLPV enabled is no faster with stubdoms as</=
p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; without. Booting with /nogplpv is just as slow as if you booted<=
/p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; without stubdoms. I suspect xenpci.sys is overriding what stubdo=
ms is</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; doing.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; If you are using PV devices then you won't be hitting the emulated</p=
>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; devices (which is what is in the stubdom) all that much after the ver=
y</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; early boot stages IOW after anything which uses BIOS int13 hook e.g. =
the</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; bootloader. If you aren't hitting the emulated devices then putting t=
hem</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; in stubdom vs dom0 won't make much odds to the performance.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; Ian.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Mak=
es sense. The main thing that I was disappointed in was that even booti=
ng with /nogplpv didn't result in a speed increase. xenpci.sys seems to=
 take over completely, even in that case.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Tha=
nx again for your time and interest.</p></body></html>
--nextPart1596651.7dWOSpoz9S--



--===============6429182619952053582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6429182619952053582==--



From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20:15:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyUCo-0006MV-F9; Fri, 17 Feb 2012 20:14:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RyUCm-0006MP-Pl
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:14:57 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329509642!54733818!1
X-Originating-IP: [98.139.44.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21381 invoked from network); 17 Feb 2012 20:14:02 -0000
Received: from nm13.access.bullet.mail.sp2.yahoo.com (HELO
	nm13.access.bullet.mail.sp2.yahoo.com) (98.139.44.140)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 20:14:02 -0000
Received: from [98.139.44.103] by nm13.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 17 Feb 2012 20:14:53 -0000
Received: from [98.139.44.71] by tm8.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 17 Feb 2012 20:14:52 -0000
Received: from [127.0.0.1] by omp1008.access.mail.sp2.yahoo.com with NNFMP;
	17 Feb 2012 20:14:52 -0000
X-Yahoo-Newman-Id: 941165.70111.bm@omp1008.access.mail.sp2.yahoo.com
Received: (qmail 14321 invoked from network); 17 Feb 2012 20:14:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1329509692; bh=8iJf//qsdZYyzqm8CZ/ZxmaC4FP7LUUFjxM0S/rH+XY=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=a8LHdsYQQ6Pse66ixCbyamYuKcgxPIuYV9dALu5f6teFT17+Fy8HYKUX/udO1xddNZYaMwNds24wdZ7GKyz7EljNFar7FDdhKhWWG5ooDlwiesf/vEqjFcXwYT7t7SnUhSIJXufUegwvdS+dtVaC6lAUkkA/QGwqYEJ1svMSxag=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jb4.LFcVM1m5mQ5vS6vYbvoPCqDHgtaG.DbG8HFBgwk_mjW
	w6YYLczecKZZBjQqnNyVNSvy9ddvtzqaHq2ITSMntIC16Tmh5RuzlVE1u3az
	_BrQW63Ed3h_gX9AfRchE5afjGq1jmtTy9Dfbw5OSUbJWRn8JwKZdpQYHPSR
	ld1tbDtdn.xQvZC7sLWWdi2rpx.kBhhA95yLgMgpCJ6ZYngvJpgsRiBr2QHp
	dqZtwt9yOcTH0uBi0ei4T0PNNFyTZ6o1kVS0UJluqncODnJVo3pcIuHiX.sk
	JPc_eNCtzykfW3ukToDamVnpYSVCqoTCPTCRHydCmgl5QmMeFKiHctLt3nOe
	cVcuUNzaAibzXtmN_UQ9qD8KLypD1gonaYoflqffKLkHUDeH4GNr6JgGTIpl
	KglM4uyOsIZRE2Hg-
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@184.36.12.191 with plain)
	by smtp110.sbc.mail.gq1.yahoo.com with SMTP;
	17 Feb 2012 12:14:51 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 17 Feb 2012 15:14:39 -0500
Message-ID: <1354954.T2Gh7Kz0zK@dell4550>
User-Agent: KMail/4.8.0 (Linux/3.1.9-1.4-default; KDE/4.8.0; i686; ; )
In-Reply-To: <1329474132.3131.22.camel@zakaz.uk.xensource.com>
References: <51142288.L1Ice6IuWj@dell4550>
	<1329474132.3131.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Problems with stubdoms, and xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6429182619952053582=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6429182619952053582==
Content-Type: multipart/alternative; boundary="nextPart1596651.7dWOSpoz9S"
Content-Transfer-Encoding: 7Bit


--nextPart1596651.7dWOSpoz9S
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:
> On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:
> [...]
> 
> > 1) After my winxp hvm domu, started with a stubdom, got some windows
> > updates yesterday, I restarted (not shutdown), and the new domain hung
> > in pause:
> [..]
> 
> I tried this with win7 on xen-unstable and it worked ok. This may be a
> bug specific to 4.1.

Good to know! Thank you very much for taking the time to look at this.

> [...]
> 
> > xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"
> > 
> > and only got a syntax error on the '-d'.
> 
> I don't think this approach is advised but FWIW the error here is
> probably lack of quoting of the " against the shell. You would have
> needed
> 	... extra=\" -d 8\"

Ouch! I was trying to quote the '-' in -d!

> > So my question is: is this a bug, and is it fixed in xen 4.2?
> 
> The failure to restart the stub DM when rebooting a VM is a bug, AFAICT
> it is fixed in unstable and therefore will be fixed in 4.2.
> 
> I've not been able to spot a specific changeset with the fix, but there
> was quite a lot to wade through.
> 
> > 2) I'm having a strange problem right after I get a xen update from
> > rawhide: stubdoms stop working for a day after wards. It happened with
> > fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at
> > whether something in /var/lib/xen* changed.
> 
> Stop working for a day and then magically starts working? Or stops
> working for a day until the next update?

As it turns out, both, the two times it happened to me. Stubdoms stop working 
until the next yum update, but nothing installed the next day has any 
relationship to xen or a kernel. Whether or not it would have worked 1/2 hour 
before the yum update is not something I have had an opportunity to explore 
yet. Of course, a yum update is frequently accompanied by a systemd restart, 
which could have an effect.

Whenever I get a rawhide xen or kernel update, I usually reboot to test the 
update for regressions/bugs, then reboot back to the highest version kernel I 
have w/o debug options turned off (before the next yum update). Thus, a full 
reboot, twice, doesn't fix the problem. So I would think that a simple systemd 
restart wouldn't, either. That's why the next thing I intend to look at would 
be whether anything got damaged/not regenerated in /var/lib/xen*. Another 
possibility is that xend is still running. I usually take care not to mix xm 
and xl commands in one boot session. If I do mix them, I usually stop any 
domus, and do an 'xm mem-set 0 ...' back to the boot value in my system, and 
then use only one of the xm / xl commands thereafter. (It is really 
disconcerting to see xm list, xl list report differing dom0 memory amounts!) 
Anyway, stopping xend and trying stubdoms again is something else I will try.

> > 3) Specifying vncviewer=1 will automatically start a vnc viewer for
> > you
> 
> [...]
> 
> > 4) The 'localtime=1' option in your config is ignored by xl. This
> > works with
> 
> [...]
> 
> > The answer given to the two above problems at the time was essentially
> > that they had not been implemented. Have they been implemented in xen
> > 4.2 yet?
> 
> Not as far as I can tell with grep. Patches would be greatly
> appreciated, these should be relatively simple issues for a newcomer to
> tackle with only basic C required I think, I'd be glad to advise etc.
> 
> I'll add these as "nice to have" in the 4.2 TODO thread.

That is greatly appreciated. While I was a programmer awhile back, I have not 
read the xen code, and the learning curve there, and in learning how to write 
*acceptable* patches is more than my time constraints currently allow. I 
confine my time to administrative duties, and looking for bugs / regressions 
to report, and helping the occasional user on Xen-users with what I *have* 
learned. 

[...]
> >  Also, while device_model_args does indeed add '-localtime' to the end
> > 
> > of the qemu-dm args, it's still ineffective.
> 
> I'm not 100% sure of this but I don't think xm's "localtime" corresponds
> to solely passing "-localtime" to the DM (although it may also do that
> also).
> 
> I think it needs to turn into a hypercall to tell the hypervisor about
> the guests time offset, e.g. a call to xc_domain_set_time_offset. The
> rtc_timeoffset option relates to this call as well.

That makes sense. Thanx.

> In a Xen system the RTC is emulated by the hypervisor not by qemu (it
> used to be done by qemu many moons ago, which might explain the
> vestigial passing of -localtime to qemu).

And I've been with xen since the 3.0 days, so features start merging in my 
head! Thanx for the clarity!.

> > And 2) If you have GPLPV installed in your domain, it completely takes
> > over. Booting with GPLPV enabled is no faster with stubdoms as
> > without. Booting with /nogplpv is just as slow as if you booted
> > without stubdoms. I suspect xenpci.sys is overriding what stubdoms is
> > doing.
> 
> If you are using PV devices then you won't be hitting the emulated
> devices (which is what is in the stubdom) all that much after the very
> early boot stages IOW after anything which uses BIOS int13 hook e.g. the
> bootloader. If you aren't hitting the emulated devices then putting them
> in stubdom vs dom0 won't make much odds to the performance.
> 
> Ian.

Makes sense. The main thing that I was disappointed in was that even booting 
with /nogplpv didn't result in a speed increase. xenpci.sys seems to take over 
completely, even in that case.

Thanx again for your time and interest.
--nextPart1596651.7dWOSpoz9S
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/=
REC-html40/strict.dtd">
<html><head><meta name=3D"qrichtext" content=3D"1" /><style type=3D"tex=
t/css">
p, li { white-space: pre-wrap; }
</style></head><body style=3D" font-family:'Courier [Adobe]'; font-size=
:9pt; font-weight:400; font-style:normal;">
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">On =
Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 1) After my winxp hvm domu, started with a stubdom, got some win=
dows</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; updates yesterday, I restarted (not shutdown), and the new domai=
n hung</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; in pause:</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [..]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I tried this with win7 on xen-unstable and it worked ok. This may be =
a</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; bug specific to 4.1.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Goo=
d to know! Thank you very much for taking the time to look at this.</p>=

<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; xl create /etc/xen/winxp-dm target=3D8 memory=3D32 extra=3D&quot=
; -d 8&quot;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; and only got a syntax error on the '-d'.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I don't think this approach is advised but FWIW the error here is</p>=

<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; probably lack of quoting of the &quot; against the shell. You would h=
ave</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; needed</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; =09... extra=3D\&quot; -d 8\&quot;</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Ouc=
h! I was trying to quote the '-' in -d!</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; So my question is: is this a bug, and is it fixed in xen 4.2?</p=
>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; The failure to restart the stub DM when rebooting a VM is a bug, AFAI=
CT</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; it is fixed in unstable and therefore will be fixed in 4.2.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I've not been able to spot a specific changeset with the fix, but the=
re</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; was quite a lot to wade through.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 2) I'm having a strange problem right after I get a xen update f=
rom</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; rawhide: stubdoms stop working for a day after wards. It happene=
d with</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; fedora xen 4.1.2-7 and -8. The next time it happens, I'll look a=
t</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; whether something in /var/lib/xen* changed.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; Stop working for a day and then magically starts working? Or stops</p=
>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; working for a day until the next update?</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">As =
it turns out, both, the two times it happened to me. Stubdoms stop work=
ing until the next yum update, but nothing installed the next day has a=
ny relationship to xen or a kernel. Whether or not it would have worked=
 1/2 hour before the yum update is not something I have had an opportun=
ity to explore yet. Of course, a yum update is frequently accompanied b=
y a systemd restart, which could have an effect.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Whe=
never I get a rawhide xen or kernel update, I usually reboot to test th=
e update for regressions/bugs, then reboot back to the highest version =
kernel I have w/o debug options turned off (before the next yum update)=
. Thus, a full reboot, twice, doesn't fix the problem. So I would think=
 that a simple systemd restart wouldn't, either. That's why the next th=
ing I intend to look at would be whether anything got damaged/not regen=
erated in /var/lib/xen*. Another possibility is that xend is still runn=
ing. I usually take care not to mix xm and xl commands in one boot sess=
ion. If I do mix them, I usually stop any domus, and do an 'xm mem-set =
0 ...' back to the boot value in my system, and then use only one of th=
e xm / xl commands thereafter. (It is really disconcerting to see xm li=
st, xl list report differing dom0 memory amounts!) Anyway, stopping xen=
d and trying stubdoms again is something else I will try.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 3) Specifying vncviewer=3D1 will automatically start a vnc viewe=
r for</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; you</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 4) The 'localtime=3D1' option in your config is ignored by xl. T=
his</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; works with</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; [...]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; The answer given to the two above problems at the time was essen=
tially</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; that they had not been implemented. Have they been implemented i=
n xen</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; 4.2 yet?</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; Not as far as I can tell with grep. Patches would be greatly</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; appreciated, these should be relatively simple issues for a newcomer =
to</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; tackle with only basic C required I think, I'd be glad to advise etc.=
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I'll add these as &quot;nice to have&quot; in the 4.2 TODO thread.</p=
>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Tha=
t is greatly appreciated. While I was a programmer awhile back, I have =
not read the xen code, and the learning curve there, and in learning ho=
w to write *acceptable* patches is more than my time constraints curren=
tly allow. I confine my time to administrative duties, and looking for =
bugs / regressions to report, and helping the occasional user on Xen-us=
ers with what I *have* learned. </p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">[..=
.]</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt;  Also, while device_model_args does indeed add '-localtime' to t=
he end</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; of the qemu-dm args, it's still ineffective.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I'm not 100% sure of this but I don't think xm's &quot;localtime&quot=
; corresponds</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; to solely passing &quot;-localtime&quot; to the DM (although it may a=
lso do that</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; also).</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; I think it needs to turn into a hypercall to tell the hypervisor abou=
t</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; the guests time offset, e.g. a call to xc_domain_set_time_offset. The=
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; rtc_timeoffset option relates to this call as well.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Tha=
t makes sense. Thanx.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; In a Xen system the RTC is emulated by the hypervisor not by qemu (it=
</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; used to be done by qemu many moons ago, which might explain the</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; vestigial passing of -localtime to qemu).</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">And=
 I've been with xen since the 3.0 days, so features start merging in my=
 head! Thanx for the clarity!.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; And 2) If you have GPLPV installed in your domain, it completely=
 takes</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; over. Booting with GPLPV enabled is no faster with stubdoms as</=
p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; without. Booting with /nogplpv is just as slow as if you booted<=
/p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; without stubdoms. I suspect xenpci.sys is overriding what stubdo=
ms is</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; &gt; doing.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; If you are using PV devices then you won't be hitting the emulated</p=
>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; devices (which is what is in the stubdom) all that much after the ver=
y</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; early boot stages IOW after anything which uses BIOS int13 hook e.g. =
the</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; bootloader. If you aren't hitting the emulated devices then putting t=
hem</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; in stubdom vs dom0 won't make much odds to the performance.</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; </p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt=
; Ian.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Mak=
es sense. The main thing that I was disappointed in was that even booti=
ng with /nogplpv didn't result in a speed increase. xenpci.sys seems to=
 take over completely, even in that case.</p>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px=
; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0p=
x; ">&nbsp;</p>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin=
-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Tha=
nx again for your time and interest.</p></body></html>
--nextPart1596651.7dWOSpoz9S--



--===============6429182619952053582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6429182619952053582==--



From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:17:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20: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.xensource.com>)
	id 1RyUEG-0006Vg-Vg; Fri, 17 Feb 2012 20:16:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RyUEF-0006Ui-6y
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:16:27 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329509779!6509425!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25449 invoked from network); 17 Feb 2012 20:16:20 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 20:16:20 -0000
Received: by qabg27 with SMTP id g27so8268576qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 12:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=H+oF5BwmP2iD6tDyVEKAI0zIxFWtFRxp+mHYNYzJ1NA=;
	b=McnYvupPbKtQQyZmX1TexSCLOFiH4L0x09IGN9SShvbXcAG+QHfxVL+oKCfr2TkwKS
	7O1JMZXlvIf96f7NqWf7np3XoBtvOw0yT+geFlBcOsXJ1XuYTvd2x/3PfEcchdylTZCC
	s3XWu5sgbMkApdFr5FGBk4bDg7YQDKaMrHy8Q=
Received: by 10.229.76.23 with SMTP id a23mr5908628qck.100.1329509779051; Fri,
	17 Feb 2012 12:16:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.33.211 with HTTP; Fri, 17 Feb 2012 12:15:48 -0800 (PST)
In-Reply-To: <4F3E3D91.7020605@citrix.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
	<4F3E3D91.7020605@citrix.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 17 Feb 2012 12:15:48 -0800
Message-ID: <CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

we are using PV networking (and disk for what matters).

thanks!
-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)

On Fri, Feb 17, 2012 at 03:44, Andrew Cooper <andrew.cooper3@citrix.com> wr=
ote:
> XenServer had an issue which looked a little like this.
>
> The fix was
> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
> if you are using PV guests then this is certainly not the same issue.
>
> ~Andrew
>
> On 17/02/12 11:41, Stefano Stabellini wrote:
>> Forwarding this email to xen-devel with a proper subject.
>>
>>
>> ---------- Forwarded message ----------
>> Stefano,
>>
>> =A0 =A0after a few days running traffic, we are seeing that one of the
>> linux netdevice txqueues has gone into a frozen state and any packet
>> that you give from there onwards is always queued to a softqueue and
>> is never put into the xen-netfront txqueue...
>>
>> it also looks like xen-netfront is not registering a timeout callback
>> and this may lead to a crash if the callback ever gets invoked.
>>
>> do you happen to know if this has been seen before and if there was a
>> fix for it?
>>
>> we are currently running with linux-3.0.9.
>>
>> Thank you!
>> -Alessandro-
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:17:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20: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.xensource.com>)
	id 1RyUEG-0006Vg-Vg; Fri, 17 Feb 2012 20:16:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RyUEF-0006Ui-6y
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:16:27 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329509779!6509425!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25449 invoked from network); 17 Feb 2012 20:16:20 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 20:16:20 -0000
Received: by qabg27 with SMTP id g27so8268576qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 12:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=H+oF5BwmP2iD6tDyVEKAI0zIxFWtFRxp+mHYNYzJ1NA=;
	b=McnYvupPbKtQQyZmX1TexSCLOFiH4L0x09IGN9SShvbXcAG+QHfxVL+oKCfr2TkwKS
	7O1JMZXlvIf96f7NqWf7np3XoBtvOw0yT+geFlBcOsXJ1XuYTvd2x/3PfEcchdylTZCC
	s3XWu5sgbMkApdFr5FGBk4bDg7YQDKaMrHy8Q=
Received: by 10.229.76.23 with SMTP id a23mr5908628qck.100.1329509779051; Fri,
	17 Feb 2012 12:16:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.33.211 with HTTP; Fri, 17 Feb 2012 12:15:48 -0800 (PST)
In-Reply-To: <4F3E3D91.7020605@citrix.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
	<4F3E3D91.7020605@citrix.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 17 Feb 2012 12:15:48 -0800
Message-ID: <CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

we are using PV networking (and disk for what matters).

thanks!
-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)

On Fri, Feb 17, 2012 at 03:44, Andrew Cooper <andrew.cooper3@citrix.com> wr=
ote:
> XenServer had an issue which looked a little like this.
>
> The fix was
> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
> if you are using PV guests then this is certainly not the same issue.
>
> ~Andrew
>
> On 17/02/12 11:41, Stefano Stabellini wrote:
>> Forwarding this email to xen-devel with a proper subject.
>>
>>
>> ---------- Forwarded message ----------
>> Stefano,
>>
>> =A0 =A0after a few days running traffic, we are seeing that one of the
>> linux netdevice txqueues has gone into a frozen state and any packet
>> that you give from there onwards is always queued to a softqueue and
>> is never put into the xen-netfront txqueue...
>>
>> it also looks like xen-netfront is not registering a timeout callback
>> and this may lead to a crash if the callback ever gets invoked.
>>
>> do you happen to know if this has been seen before and if there was a
>> fix for it?
>>
>> we are currently running with linux-3.0.9.
>>
>> Thank you!
>> -Alessandro-
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:18:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20: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.xensource.com>)
	id 1RyUFj-0006j4-Fp; Fri, 17 Feb 2012 20:17:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RyUFi-0006iS-ON
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:17:58 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329509871!14791985!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1577 invoked from network); 17 Feb 2012 20:17:52 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 20:17:52 -0000
Received: by qabg27 with SMTP id g27so8271259qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 12:17:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=oL6dlXP8fBR1Nw6AEp3waHstgmgRfNpBeYKvWcst3kc=;
	b=e8myFMO7KAcAv346b5VvbxcCh1miim8pdwsyirDh9SWbLlP0zu8zTKcICiVm+TAiG7
	2CNNFVJMhmSfEFqFcASgt+3Uuy4KmXoG2MHDS2tSh58asecOSdEOzo1KFS5qKeLlpbiZ
	x6EVq/zcaDM787oeL4Fi2BpMqqJTt0PfKPkFM=
Received: by 10.229.76.23 with SMTP id a23mr5911920qck.100.1329509871199; Fri,
	17 Feb 2012 12:17:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.33.211 with HTTP; Fri, 17 Feb 2012 12:17:21 -0800 (PST)
In-Reply-To: <CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@mail.gmail.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
	<4F3E3D91.7020605@citrix.com>
	<CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@mail.gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 17 Feb 2012 12:17:21 -0800
Message-ID: <CAJeBh4vw0GDjZuKdjggSPbxiGdxq2PEVfaL7pLvb010ZZHf-Sg@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

maybe i replied too quickly and impulsively.

On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wrot=
e:
> we are using PV networking (and disk for what matters).

we are using PV networking (and disk for what matters), *on HVM* (PV/HVM).

thanks!
-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)



On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wrot=
e:
> we are using PV networking (and disk for what matters).
>
> thanks!
> -Alessandro-
> =A0Here i am, A young man,
> =A0A crashing computer program,
> =A0Here is a pen, write out my name...
>
> (from: The Servant - Orchestra)
>
> On Fri, Feb 17, 2012 at 03:44, Andrew Cooper <andrew.cooper3@citrix.com> =
wrote:
>> XenServer had an issue which looked a little like this.
>>
>> The fix was
>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
>> if you are using PV guests then this is certainly not the same issue.
>>
>> ~Andrew
>>
>> On 17/02/12 11:41, Stefano Stabellini wrote:
>>> Forwarding this email to xen-devel with a proper subject.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> Stefano,
>>>
>>> =A0 =A0after a few days running traffic, we are seeing that one of the
>>> linux netdevice txqueues has gone into a frozen state and any packet
>>> that you give from there onwards is always queued to a softqueue and
>>> is never put into the xen-netfront txqueue...
>>>
>>> it also looks like xen-netfront is not registering a timeout callback
>>> and this may lead to a crash if the callback ever gets invoked.
>>>
>>> do you happen to know if this has been seen before and if there was a
>>> fix for it?
>>>
>>> we are currently running with linux-3.0.9.
>>>
>>> Thank you!
>>> -Alessandro-
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:18:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20: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.xensource.com>)
	id 1RyUFj-0006j4-Fp; Fri, 17 Feb 2012 20:17:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RyUFi-0006iS-ON
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:17:58 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329509871!14791985!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1577 invoked from network); 17 Feb 2012 20:17:52 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 20:17:52 -0000
Received: by qabg27 with SMTP id g27so8271259qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 12:17:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=oL6dlXP8fBR1Nw6AEp3waHstgmgRfNpBeYKvWcst3kc=;
	b=e8myFMO7KAcAv346b5VvbxcCh1miim8pdwsyirDh9SWbLlP0zu8zTKcICiVm+TAiG7
	2CNNFVJMhmSfEFqFcASgt+3Uuy4KmXoG2MHDS2tSh58asecOSdEOzo1KFS5qKeLlpbiZ
	x6EVq/zcaDM787oeL4Fi2BpMqqJTt0PfKPkFM=
Received: by 10.229.76.23 with SMTP id a23mr5911920qck.100.1329509871199; Fri,
	17 Feb 2012 12:17:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.33.211 with HTTP; Fri, 17 Feb 2012 12:17:21 -0800 (PST)
In-Reply-To: <CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@mail.gmail.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
	<4F3E3D91.7020605@citrix.com>
	<CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@mail.gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 17 Feb 2012 12:17:21 -0800
Message-ID: <CAJeBh4vw0GDjZuKdjggSPbxiGdxq2PEVfaL7pLvb010ZZHf-Sg@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

maybe i replied too quickly and impulsively.

On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wrot=
e:
> we are using PV networking (and disk for what matters).

we are using PV networking (and disk for what matters), *on HVM* (PV/HVM).

thanks!
-Alessandro-
=A0Here i am, A young man,
=A0A crashing computer program,
=A0Here is a pen, write out my name...

(from: The Servant - Orchestra)



On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wrot=
e:
> we are using PV networking (and disk for what matters).
>
> thanks!
> -Alessandro-
> =A0Here i am, A young man,
> =A0A crashing computer program,
> =A0Here is a pen, write out my name...
>
> (from: The Servant - Orchestra)
>
> On Fri, Feb 17, 2012 at 03:44, Andrew Cooper <andrew.cooper3@citrix.com> =
wrote:
>> XenServer had an issue which looked a little like this.
>>
>> The fix was
>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
>> if you are using PV guests then this is certainly not the same issue.
>>
>> ~Andrew
>>
>> On 17/02/12 11:41, Stefano Stabellini wrote:
>>> Forwarding this email to xen-devel with a proper subject.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> Stefano,
>>>
>>> =A0 =A0after a few days running traffic, we are seeing that one of the
>>> linux netdevice txqueues has gone into a frozen state and any packet
>>> that you give from there onwards is always queued to a softqueue and
>>> is never put into the xen-netfront txqueue...
>>>
>>> it also looks like xen-netfront is not registering a timeout callback
>>> and this may lead to a crash if the callback ever gets invoked.
>>>
>>> do you happen to know if this has been seen before and if there was a
>>> fix for it?
>>>
>>> we are currently running with linux-3.0.9.
>>>
>>> Thank you!
>>> -Alessandro-
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:44:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20: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.xensource.com>)
	id 1RyUec-0007IP-QW; Fri, 17 Feb 2012 20:43:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RyUeb-0007IJ-NT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:43:41 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329511413!2403320!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31089 invoked from network); 17 Feb 2012 20:43:34 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 20:43:34 -0000
Received: by qabg27 with SMTP id g27so8315297qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 12:43:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=bCzpLGttk34J3WqVHPe3qKPB8flmX9OyCe/R7Bc0B7s=;
	b=knT3XIM5eJTIh5ZWP35QdyE22Uj+HaWya7Y/dvY+lqyTZ1uSB+jWxn4AJwMnxXIC66
	jhPr0TrQy1WCnzLtbMSTJ+PkgIlMnYSNu+7Qznz/dzuxmDwRkkSnXiv6aFz8ILOx0Ijw
	PGjv++DR0XG/cdzj5hNT2aWUdxEnPPM6UGbl8=
Received: by 10.229.102.71 with SMTP id f7mr5966484qco.120.1329511413389; Fri,
	17 Feb 2012 12:43:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.33.211 with HTTP; Fri, 17 Feb 2012 12:43:03 -0800 (PST)
In-Reply-To: <CAJeBh4vw0GDjZuKdjggSPbxiGdxq2PEVfaL7pLvb010ZZHf-Sg@mail.gmail.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
	<4F3E3D91.7020605@citrix.com>
	<CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@mail.gmail.com>
	<CAJeBh4vw0GDjZuKdjggSPbxiGdxq2PEVfaL7pLvb010ZZHf-Sg@mail.gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 17 Feb 2012 12:43:03 -0800
Message-ID: <CAJeBh4sWzwk6BFaNPExL9Jk+YgT0mo07mE+aVaZM-ZnaTRPhyw@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andrew,

  is there a hot patch available for Xenserver 6.0.0 that fixes this?
if not, when would it be available?

thank you!
-alessandro-

On Fri, Feb 17, 2012 at 12:17, Alessandro Salvatori <sandr8@gmail.com> wrot=
e:
> maybe i replied too quickly and impulsively.
>
> On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wr=
ote:
>> we are using PV networking (and disk for what matters).
>
> we are using PV networking (and disk for what matters), *on HVM* (PV/HVM).
>
> thanks!
> -Alessandro-
> =A0Here i am, A young man,
> =A0A crashing computer program,
> =A0Here is a pen, write out my name...
>
> (from: The Servant - Orchestra)
>
>
>
> On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wr=
ote:
>> we are using PV networking (and disk for what matters).
>>
>> thanks!
>> -Alessandro-
>> =A0Here i am, A young man,
>> =A0A crashing computer program,
>> =A0Here is a pen, write out my name...
>>
>> (from: The Servant - Orchestra)
>>
>> On Fri, Feb 17, 2012 at 03:44, Andrew Cooper <andrew.cooper3@citrix.com>=
 wrote:
>>> XenServer had an issue which looked a little like this.
>>>
>>> The fix was
>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
>>> if you are using PV guests then this is certainly not the same issue.
>>>
>>> ~Andrew
>>>
>>> On 17/02/12 11:41, Stefano Stabellini wrote:
>>>> Forwarding this email to xen-devel with a proper subject.
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> Stefano,
>>>>
>>>> =A0 =A0after a few days running traffic, we are seeing that one of the
>>>> linux netdevice txqueues has gone into a frozen state and any packet
>>>> that you give from there onwards is always queued to a softqueue and
>>>> is never put into the xen-netfront txqueue...
>>>>
>>>> it also looks like xen-netfront is not registering a timeout callback
>>>> and this may lead to a crash if the callback ever gets invoked.
>>>>
>>>> do you happen to know if this has been seen before and if there was a
>>>> fix for it?
>>>>
>>>> we are currently running with linux-3.0.9.
>>>>
>>>> Thank you!
>>>> -Alessandro-
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:44:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20: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.xensource.com>)
	id 1RyUec-0007IP-QW; Fri, 17 Feb 2012 20:43:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RyUeb-0007IJ-NT
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:43:41 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329511413!2403320!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31089 invoked from network); 17 Feb 2012 20:43:34 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 20:43:34 -0000
Received: by qabg27 with SMTP id g27so8315297qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 12:43:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	bh=bCzpLGttk34J3WqVHPe3qKPB8flmX9OyCe/R7Bc0B7s=;
	b=knT3XIM5eJTIh5ZWP35QdyE22Uj+HaWya7Y/dvY+lqyTZ1uSB+jWxn4AJwMnxXIC66
	jhPr0TrQy1WCnzLtbMSTJ+PkgIlMnYSNu+7Qznz/dzuxmDwRkkSnXiv6aFz8ILOx0Ijw
	PGjv++DR0XG/cdzj5hNT2aWUdxEnPPM6UGbl8=
Received: by 10.229.102.71 with SMTP id f7mr5966484qco.120.1329511413389; Fri,
	17 Feb 2012 12:43:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.33.211 with HTTP; Fri, 17 Feb 2012 12:43:03 -0800 (PST)
In-Reply-To: <CAJeBh4vw0GDjZuKdjggSPbxiGdxq2PEVfaL7pLvb010ZZHf-Sg@mail.gmail.com>
References: <alpine.DEB.2.00.1202171139330.7456@kaball-desktop>
	<4F3E3D91.7020605@citrix.com>
	<CAJeBh4s02_g_KjuQz=HOZFdp3TzgDhM=2-f6xBw+L9qKG-ye1g@mail.gmail.com>
	<CAJeBh4vw0GDjZuKdjggSPbxiGdxq2PEVfaL7pLvb010ZZHf-Sg@mail.gmail.com>
From: Alessandro Salvatori <sandr8@gmail.com>
Date: Fri, 17 Feb 2012 12:43:03 -0800
Message-ID: <CAJeBh4sWzwk6BFaNPExL9Jk+YgT0mo07mE+aVaZM-ZnaTRPhyw@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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] xen-netfront: txqueues in a frozen state,
 no packets in the softqueue
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: sandr8@gmail.com
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andrew,

  is there a hot patch available for Xenserver 6.0.0 that fixes this?
if not, when would it be available?

thank you!
-alessandro-

On Fri, Feb 17, 2012 at 12:17, Alessandro Salvatori <sandr8@gmail.com> wrot=
e:
> maybe i replied too quickly and impulsively.
>
> On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wr=
ote:
>> we are using PV networking (and disk for what matters).
>
> we are using PV networking (and disk for what matters), *on HVM* (PV/HVM).
>
> thanks!
> -Alessandro-
> =A0Here i am, A young man,
> =A0A crashing computer program,
> =A0Here is a pen, write out my name...
>
> (from: The Servant - Orchestra)
>
>
>
> On Fri, Feb 17, 2012 at 12:15, Alessandro Salvatori <sandr8@gmail.com> wr=
ote:
>> we are using PV networking (and disk for what matters).
>>
>> thanks!
>> -Alessandro-
>> =A0Here i am, A young man,
>> =A0A crashing computer program,
>> =A0Here is a pen, write out my name...
>>
>> (from: The Servant - Orchestra)
>>
>> On Fri, Feb 17, 2012 at 03:44, Andrew Cooper <andrew.cooper3@citrix.com>=
 wrote:
>>> XenServer had an issue which looked a little like this.
>>>
>>> The fix was
>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/02b92d035f64 , but
>>> if you are using PV guests then this is certainly not the same issue.
>>>
>>> ~Andrew
>>>
>>> On 17/02/12 11:41, Stefano Stabellini wrote:
>>>> Forwarding this email to xen-devel with a proper subject.
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> Stefano,
>>>>
>>>> =A0 =A0after a few days running traffic, we are seeing that one of the
>>>> linux netdevice txqueues has gone into a frozen state and any packet
>>>> that you give from there onwards is always queued to a softqueue and
>>>> is never put into the xen-netfront txqueue...
>>>>
>>>> it also looks like xen-netfront is not registering a timeout callback
>>>> and this may lead to a crash if the callback ever gets invoked.
>>>>
>>>> do you happen to know if this has been seen before and if there was a
>>>> fix for it?
>>>>
>>>> we are currently running with linux-3.0.9.
>>>>
>>>> Thank you!
>>>> -Alessandro-
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyUrk-0007Xi-6X; Fri, 17 Feb 2012 20:57:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyUrh-0007Xd-Rn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:57:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329512201!57204594!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2MDcx\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2MDcx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12489 invoked from network); 17 Feb 2012 20:56:41 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 20:56:41 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B10B05EC080;
	Fri, 17 Feb 2012 12:57:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MYAkJCTEQa/Mm5EB/gw2rjBvmHDkgzUzRjGaVHP1aXNr
	EPHHPeYcw2vXNy4t3/Huy3smlBJ7zotUm93ioWaee+M+J18l/ewtOTjqZsgaGSn3
	i6ifv+bB2V9skQHydGobvJ46WQn2VTk9ak8ziCWqr8ZjUOmSJjtsBH+9uSlaUYk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ouu3AUh7aAH/yvmyKbzM6QzQFVU=; b=AN99JKUZ
	GbeS+rZOQobA1HM6+y5QmcvrACFUwfH2qn27TlGGwMNfWguKJXt/Ka0JssLuEV8+
	PYuYpz7/t8BYHVnD132heGa/fGjGZGGmf7GvILJzbXxT0FrpiOwF65LEC0UeDr9E
	Mckd2BGhHmrlh59vdpKcLzi73ZZaeCvdZN0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 438C35EC07C; 
	Fri, 17 Feb 2012 12:57:10 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 12:57:10 -0800
Message-ID: <8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120217175619.GB59026@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 12:57:10 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
>> Well, thanks for taking a stab at it. Looks fairly well. My main
>> observation is that we do not want to unconditionally go on a wait queue
>> everywhere. For example, the grant table code pretty reliable unwinds
>> itself and correctly tells the grant mapper to retry, in the presence of
>> a
>> paged page.
>
> The grant table code is unlikely to hit a paged-out gfn in the caller's
> address space.

Oh yeah they do. At least for the target gfn's behind the grants. That's
why we need the retry loops in the PV backends in dom0.

>
>> The same could be said of emulation (X86_EMUL_RETRY).
>
> Fair enough.  But the emulator uses hvm_copy() in its callbacks anyway
> we'd need another flag to say 'special handling for p2m fixups plz' in
> all the hvm_copy() interfaces.  Unpleasant!
>
>> And certainly the balloon code should not sleep waiting for populate!
>
> The balloon code should not be trying to populate at all!

Agreed. get_gfn_query is needed there. Nothing bad happens because we
immediately send drop_page. But it's wrong-ish.

>
>> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
>> wait queue code is invoked only there. And then we can call
>> get_gfn_sleep
>> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.
>
> I see.  In the longer term I definitely do not want get_gfn()'s callers
> to have to deal with p2m_is_paged(), and PoD, and sharing, and every
> other p2m hack we come up with.  I want all that stuff hidden behind
> get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.
>
> I don't like get_gfn_sleep() very much but I'll see if I can find a way
> to do the equivalent with a flag to get_gfn_*().  But I suspect it will
> end up with a tri-state argument of:
>  a) just give me the current state;
>  b) try (without sleeping) to fix up paging, PoD and sharing but
>     still maybe make me handle it myself by error propagation; and
>  c) just fix it up.
>
> 'b' is a pretty weird interface.  Specially given that in corner cases,
> 'make me handle it' might involve hitting a wait queue anyway.  If we
> intend in the fullness of time to get rid of it (as I hope we would)
> then probably we shouldn't introduce it.  (And if that means pushing
> this whole change out past 4.2, we should consider doing that.)
>
It's weird. b) is an evolutionary side-effect. It should disappear. I
guess what I'm arguing for is "it should disappear in the long term, not
on a patch so close to 4.2"

>> >> diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
>> >> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
>> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
>> >> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
>> >>     }
>> >>
>> >>     /* For now only perform locking on hap domains */
>> >> -    if ( locked && (hap_enabled(p2m->domain)) )
>> >> +    locked = locked && hap_enabled(p2m->domain);
>> >> +
>> >> +#ifdef __x86_64__
>> When are we getting rid of 32 bit hypervisor? (half kidding. Only half)
>
> Can't be soon enough for me.  I've been sharpening the axe for that one
> for years now. :)

What's stopping the death blow?

>
>> >> +again:
>> >> +#endif
>> >> +    if ( locked )
>> >>         /* Grab the lock here, don't release until put_gfn */
>> >>         gfn_lock(p2m, gfn, 0);
>> >>
>> >>     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>> >>
>> >> #ifdef __x86_64__
>> >> +    if ( p2m_is_paging(*t) && q != p2m_query
>> >> +         && p2m->domain == current->domain )
>> >> +    {
>> >> +        if ( locked )
>> >> +            gfn_unlock(p2m, gfn, 0);
>> >> +
>> >> +        /* Ping the pager */
>> >> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
>> >> +            p2m_mem_paging_populate(p2m->domain, gfn);
>>
>> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
>> still have the mfn in place.
>
> Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
> not, it really should.
>

It's not about populate, it's about killing the domain unnecessarily in
the in_atomic check.

>> >> +
>> >> +        /* Safety catch: it _should_ be safe to wait here but if
>> it's
>> >> not,
>> >> +         * crash the VM, not the host */
>> >> +        if ( in_atomic() )
>> >> +        {
>> >> +            WARN();
>> >> +            domain_crash(p2m->domain);
>> >> +        }
>> >> +        else
>> >> +        {
>> >> +            current->arch.mem_paging_gfn = gfn;
>> >> +            wait_event(current->arch.mem_paging_wq, ({
>> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
>> >> +                                             p2m_query, page_order);
>> >> +                        (*t != p2m_ram_paging_in);
>>
>> Well, first of all mfn->get_entry will not happen in a locked context,
>> so
>> you will exit the wait loop not holding the p2m lock and crash later.
>
> Yes - we always exit the loop without the lock; then we 'goto again' and
> do things properly.  I realise it's a bit inefficient, but on the
> page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
> write the version that handled the locking in this loop but it got a bit
> twisty, plus we need the 'goto again' for other reasons (see below).

Yes, but, you'll be reading the p2m in a racy manner.

>
> As a follow-up I ought to make the page-sharing fixup code that's just
> below this use 'goto again' as well; we shouldn't really leave this
> function until we get a lookup where all these cases are dealt with.
>

I was intending to do that and then I stepped back and ended up with the
current patch submitted a couple of days ago. Same problem, can't safely
go to a wait queue.

I think we won't be able to have a magic
get_gfn_solve_everything_silently() call until we find a solution to the
fact that get_gfn happens in locked contexts. I've though about a wacky
idea that
1. schedules a sleep-n-retry softirq
2. fails the call
3. avoids crashing the domain on the unwind path
4. when executing softirqs pauses the vcpu as per 1.
5. When woken up retries the last failed hypercall/vmexit/whatever

I shouldn't have said that out loud...

>> So you want __get_gfn_type_access with q = p2m_query, and then put_gfn
>> if the
>> condition fails. Probably not gonna fit in a ({}) block ;)
>>
>> I think checking for (!p2m_is_paging(*t)) is more appropriate.
>
> No, that was deliberate, and IIRC a change from Olaf's patch.  If the
> page gets paged in and back out while we're asleep, the type goes back
> to p2m_ram_paged, and in that case we _must_ break out and retry or this
> vcpu might stall forever.

I see, a new populate event is needed.

>
>> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >> {
>> >>     struct vcpu *v = current;
>> >> -    mem_event_request_t req;
>> >> +    mem_event_request_t req = {0};
>> >>     p2m_type_t p2mt;
>> >>     p2m_access_t a;
>> >>     mfn_t mfn;
>> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> >> +    int send_request = 0;
>> >>
>> >>     /* We're paging. There should be a ring */
>> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
>>
>> Given all the optimizations around the send_request flag, it might be
>> worth moving the claim_slot call to an if(send_request) block at the
>> bottom, and get rid of cancel_slot altogether. Claim_slot could
>> potentially go (or cause someone else to go) to a wait queue, and it's
>> best to not be that rude.
>
> Sure.  It might be tricky to make sure we unwind properly in the failure
> case, but I'll have a go at a follow-up patch that looks at that.
>
> (This is not really a regression in this patch AFAICS - in the existing
> code
> the get_gfn() callers end up calling this function anyway.)

*After* they've put gfn. Not a regression, just cleaner code imo.

Andres

>
>> >> -    /* Pause domain if request came from guest and gfn has paging
>> type
>> >> */
>> >> -    if ( p2m_is_paging(p2mt) && v->domain == d )
>> >> +    /* No need to inform pager if the gfn is not in the page-out
>> path
>> >> */
>> >> +    if ( !send_request )
>> >>     {
>> >> -        vcpu_pause_nosync(v);
>>
>> I see no sin in stacking vcpu_pauses. Plus, this will need to stay if we
>> (hopefully) adopt get_gfn_sleep.
>
> Yes, if we do it that way, this pause definitely needs to stay.  But if
> not then the waitqueue takes care of this case entirely, and this code
> is just redundant and confusing.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 20:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 20:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyUrk-0007Xi-6X; Fri, 17 Feb 2012 20:57:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RyUrh-0007Xd-Rn
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 20:57:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329512201!57204594!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2MDcx\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2MDcx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12489 invoked from network); 17 Feb 2012 20:56:41 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-27.messagelabs.com with SMTP;
	17 Feb 2012 20:56:41 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B10B05EC080;
	Fri, 17 Feb 2012 12:57:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MYAkJCTEQa/Mm5EB/gw2rjBvmHDkgzUzRjGaVHP1aXNr
	EPHHPeYcw2vXNy4t3/Huy3smlBJ7zotUm93ioWaee+M+J18l/ewtOTjqZsgaGSn3
	i6ifv+bB2V9skQHydGobvJ46WQn2VTk9ak8ziCWqr8ZjUOmSJjtsBH+9uSlaUYk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=ouu3AUh7aAH/yvmyKbzM6QzQFVU=; b=AN99JKUZ
	GbeS+rZOQobA1HM6+y5QmcvrACFUwfH2qn27TlGGwMNfWguKJXt/Ka0JssLuEV8+
	PYuYpz7/t8BYHVnD132heGa/fGjGZGGmf7GvILJzbXxT0FrpiOwF65LEC0UeDr9E
	Mckd2BGhHmrlh59vdpKcLzi73ZZaeCvdZN0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 438C35EC07C; 
	Fri, 17 Feb 2012 12:57:10 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 17 Feb 2012 12:57:10 -0800
Message-ID: <8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120217175619.GB59026@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
Date: Fri, 17 Feb 2012 12:57:10 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hi,
>
> At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
>> Well, thanks for taking a stab at it. Looks fairly well. My main
>> observation is that we do not want to unconditionally go on a wait queue
>> everywhere. For example, the grant table code pretty reliable unwinds
>> itself and correctly tells the grant mapper to retry, in the presence of
>> a
>> paged page.
>
> The grant table code is unlikely to hit a paged-out gfn in the caller's
> address space.

Oh yeah they do. At least for the target gfn's behind the grants. That's
why we need the retry loops in the PV backends in dom0.

>
>> The same could be said of emulation (X86_EMUL_RETRY).
>
> Fair enough.  But the emulator uses hvm_copy() in its callbacks anyway
> we'd need another flag to say 'special handling for p2m fixups plz' in
> all the hvm_copy() interfaces.  Unpleasant!
>
>> And certainly the balloon code should not sleep waiting for populate!
>
> The balloon code should not be trying to populate at all!

Agreed. get_gfn_query is needed there. Nothing bad happens because we
immediately send drop_page. But it's wrong-ish.

>
>> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
>> wait queue code is invoked only there. And then we can call
>> get_gfn_sleep
>> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.
>
> I see.  In the longer term I definitely do not want get_gfn()'s callers
> to have to deal with p2m_is_paged(), and PoD, and sharing, and every
> other p2m hack we come up with.  I want all that stuff hidden behind
> get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.
>
> I don't like get_gfn_sleep() very much but I'll see if I can find a way
> to do the equivalent with a flag to get_gfn_*().  But I suspect it will
> end up with a tri-state argument of:
>  a) just give me the current state;
>  b) try (without sleeping) to fix up paging, PoD and sharing but
>     still maybe make me handle it myself by error propagation; and
>  c) just fix it up.
>
> 'b' is a pretty weird interface.  Specially given that in corner cases,
> 'make me handle it' might involve hitting a wait queue anyway.  If we
> intend in the fullness of time to get rid of it (as I hope we would)
> then probably we shouldn't introduce it.  (And if that means pushing
> this whole change out past 4.2, we should consider doing that.)
>
It's weird. b) is an evolutionary side-effect. It should disappear. I
guess what I'm arguing for is "it should disappear in the long term, not
on a patch so close to 4.2"

>> >> diff -r 01c1bcbc6222 xen/arch/x86/mm/p2m.c
>> >> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 16 08:48:23 2012 +0100
>> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 16 14:39:13 2012 +0000
>> >> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
>> >>     }
>> >>
>> >>     /* For now only perform locking on hap domains */
>> >> -    if ( locked && (hap_enabled(p2m->domain)) )
>> >> +    locked = locked && hap_enabled(p2m->domain);
>> >> +
>> >> +#ifdef __x86_64__
>> When are we getting rid of 32 bit hypervisor? (half kidding. Only half)
>
> Can't be soon enough for me.  I've been sharpening the axe for that one
> for years now. :)

What's stopping the death blow?

>
>> >> +again:
>> >> +#endif
>> >> +    if ( locked )
>> >>         /* Grab the lock here, don't release until put_gfn */
>> >>         gfn_lock(p2m, gfn, 0);
>> >>
>> >>     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>> >>
>> >> #ifdef __x86_64__
>> >> +    if ( p2m_is_paging(*t) && q != p2m_query
>> >> +         && p2m->domain == current->domain )
>> >> +    {
>> >> +        if ( locked )
>> >> +            gfn_unlock(p2m, gfn, 0);
>> >> +
>> >> +        /* Ping the pager */
>> >> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
>> >> +            p2m_mem_paging_populate(p2m->domain, gfn);
>>
>> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
>> still have the mfn in place.
>
> Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
> not, it really should.
>

It's not about populate, it's about killing the domain unnecessarily in
the in_atomic check.

>> >> +
>> >> +        /* Safety catch: it _should_ be safe to wait here but if
>> it's
>> >> not,
>> >> +         * crash the VM, not the host */
>> >> +        if ( in_atomic() )
>> >> +        {
>> >> +            WARN();
>> >> +            domain_crash(p2m->domain);
>> >> +        }
>> >> +        else
>> >> +        {
>> >> +            current->arch.mem_paging_gfn = gfn;
>> >> +            wait_event(current->arch.mem_paging_wq, ({
>> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
>> >> +                                             p2m_query, page_order);
>> >> +                        (*t != p2m_ram_paging_in);
>>
>> Well, first of all mfn->get_entry will not happen in a locked context,
>> so
>> you will exit the wait loop not holding the p2m lock and crash later.
>
> Yes - we always exit the loop without the lock; then we 'goto again' and
> do things properly.  I realise it's a bit inefficient, but on the
> page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
> write the version that handled the locking in this loop but it got a bit
> twisty, plus we need the 'goto again' for other reasons (see below).

Yes, but, you'll be reading the p2m in a racy manner.

>
> As a follow-up I ought to make the page-sharing fixup code that's just
> below this use 'goto again' as well; we shouldn't really leave this
> function until we get a lookup where all these cases are dealt with.
>

I was intending to do that and then I stepped back and ended up with the
current patch submitted a couple of days ago. Same problem, can't safely
go to a wait queue.

I think we won't be able to have a magic
get_gfn_solve_everything_silently() call until we find a solution to the
fact that get_gfn happens in locked contexts. I've though about a wacky
idea that
1. schedules a sleep-n-retry softirq
2. fails the call
3. avoids crashing the domain on the unwind path
4. when executing softirqs pauses the vcpu as per 1.
5. When woken up retries the last failed hypercall/vmexit/whatever

I shouldn't have said that out loud...

>> So you want __get_gfn_type_access with q = p2m_query, and then put_gfn
>> if the
>> condition fails. Probably not gonna fit in a ({}) block ;)
>>
>> I think checking for (!p2m_is_paging(*t)) is more appropriate.
>
> No, that was deliberate, and IIRC a change from Olaf's patch.  If the
> page gets paged in and back out while we're asleep, the type goes back
> to p2m_ram_paged, and in that case we _must_ break out and retry or this
> vcpu might stall forever.

I see, a new populate event is needed.

>
>> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >> {
>> >>     struct vcpu *v = current;
>> >> -    mem_event_request_t req;
>> >> +    mem_event_request_t req = {0};
>> >>     p2m_type_t p2mt;
>> >>     p2m_access_t a;
>> >>     mfn_t mfn;
>> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> >> +    int send_request = 0;
>> >>
>> >>     /* We're paging. There should be a ring */
>> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
>>
>> Given all the optimizations around the send_request flag, it might be
>> worth moving the claim_slot call to an if(send_request) block at the
>> bottom, and get rid of cancel_slot altogether. Claim_slot could
>> potentially go (or cause someone else to go) to a wait queue, and it's
>> best to not be that rude.
>
> Sure.  It might be tricky to make sure we unwind properly in the failure
> case, but I'll have a go at a follow-up patch that looks at that.
>
> (This is not really a regression in this patch AFAICS - in the existing
> code
> the get_gfn() callers end up calling this function anyway.)

*After* they've put gfn. Not a regression, just cleaner code imo.

Andres

>
>> >> -    /* Pause domain if request came from guest and gfn has paging
>> type
>> >> */
>> >> -    if ( p2m_is_paging(p2mt) && v->domain == d )
>> >> +    /* No need to inform pager if the gfn is not in the page-out
>> path
>> >> */
>> >> +    if ( !send_request )
>> >>     {
>> >> -        vcpu_pause_nosync(v);
>>
>> I see no sin in stacking vcpu_pauses. Plus, this will need to stay if we
>> (hopefully) adopt get_gfn_sleep.
>
> Yes, if we do it that way, this pause definitely needs to stay.  But if
> not then the waitqueue takes care of this case entirely, and this code
> is just redundant and confusing.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 21:15:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 21: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.xensource.com>)
	id 1RyV8u-0007zk-Gp; Fri, 17 Feb 2012 21:15:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RyV8s-0007zc-VZ
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:14:59 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329513291!13822862!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19526 invoked from network); 17 Feb 2012 21:14:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 21:14:52 -0000
Received: by werb14 with SMTP id b14so7137583wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 13:14:51 -0800 (PST)
Received-SPF: pass (google.com: domain of pstroud@gmail.com designates
	10.180.101.72 as permitted sender) client-ip=10.180.101.72; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of pstroud@gmail.com
	designates 10.180.101.72 as permitted sender)
	smtp.mail=pstroud@gmail.com;
	dkim=pass header.i=pstroud@gmail.com
Received: from mr.google.com ([10.180.101.72])
	by 10.180.101.72 with SMTP id fe8mr7616381wib.4.1329513291920 (num_hops
	= 1); Fri, 17 Feb 2012 13:14:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=1iJwGnd9PRGM1tY7ljzyXaTq/IZcjaTEkAOBptn7YLA=;
	b=SGqcgyVLsSXUu/hQS05I2jFcfnz3EtQl24hL+QuMHO+9GawarUPHLGBmyhb1OjjrCB
	Z6bFlQr7g35aDTuvU2QYxQaTCC4C77bd3c5ypO/jaQugqFyg8FG6xGcvKYZwx5bEFyRK
	bnu9EnDGrW8fWFGf+j3zN7g1mXEiNjzJ7X258=
MIME-Version: 1.0
Received: by 10.180.101.72 with SMTP id fe8mr6408603wib.4.1329513290130; Fri,
	17 Feb 2012 13:14:50 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Fri, 17 Feb 2012 13:14:50 -0800 (PST)
In-Reply-To: <4F3E82A8.4060204@citrix.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
Date: Fri, 17 Feb 2012 16:14:50 -0500
Message-ID: <CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8898159192973128626=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8898159192973128626==
Content-Type: multipart/alternative; boundary=f46d0443066261e39d04b92f6ff7

--f46d0443066261e39d04b92f6ff7
Content-Type: text/plain; charset=ISO-8859-1

Andrew,
Thanks for the quick response! I was finally able to capture it and get a
bit more information. The problem does not always happen, even on 4.1.2, I
was able to get it to boot a few times, though I was never able to get
4.2-unstable to boot. There was lots of strangeness, such as after I built
and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
working.

That being said, I caught it on video, and captured a picture of the final
dump. I watched the video frame by frame and the boot actually got much
further than I thought it was.

I can see that even though it does not bring up two of the CPUs, the boot
continues into the kernel and dies somewhere with a:

BUG: Unable to handle paging request at FFFc7f(maybe).

I have captured several images from the video that shows the progression of
the boot before the crash. I think I have gotten things badly out of whack
at this point, so I'm going to stop, reinstall everything and move back to
4.1.1 and see if I can get things working again.

Let me know if anything in the pictures helps, or if you would like the
video as well.

Paul

On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper
<andrew.cooper3@citrix.com>wrote:

> On 17/02/12 16:21, Paul S wrote:
> > Environment:
> > ASRock Z86 Extreme4 - Intel i5 2500
> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
> >
> > I have installed the latest UEFI patch(1.70) and all tests were run
> > from a reset of everything to default. I have tested with both Ubuntu
> > 11.10 and Fedora 16 and get the same results on both, including
> > building xen 4.2-unstable. I bought this particular MB because it had
> > a know working vt-d implementation via VMWare.
> >
> > NOTE: current unstable as of last night is still affected by this
> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
> >
> > However, after correcting the library error, I was able to complete
> > the unstable build.
> >
> > In both cases, it either stops with a panic/blank screen, or just
> reboots.
> >
> > Here are some other notes:
> >
> > 1) If x2apic is enabled on the motherboard, it almost immediately
> > reboots with any of the configurations above
>
> There are some fairly strict set of requirements on what which MSRs you
> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
> early in boot which results in a protection fault.
>
> >
> > 2) The boot gets to here:
> >
> > (XEN) HVM: VMX enabled
> >
> > (XEN) HVM: Hardware Assisted Paging detected.
> >
> >
> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
> > where it hangs with the blank/panic screen or reboots. This sometimes
> > shows up on CPU 1, CPU2, or both.
> >
> >
> > 3) There is no boot log written and the machine does not have a native
> > serial port, so capturing anything may prove difficult, but I am open
> > to suggestions.
> >
>
> Try booting with noreboot - that should keep any panic message on screen
> until you manually choose to reset the machine.  Seeing where in the
> panic occurs would be very helpful, even if you just transcribe a few
> lines manually.
>
> >
> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
> > is enabled, then it simply panics and reboots.
> >
> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
> > being enabled, but I did check it with VT-d enabled and the boot
> > looked the same. I can capture it again if needed.
> >
> >
> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
> > enabled(which shows working in xl) and x2apic enabled.
> >
> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
> > includes logs both with and without VT-d and x2apic enabled. I did not
> > actually create any VMs, only booted this and checked what xl reported.
> >
> >
>
> That is rather interesting - I am not aware of any XenServer specific
> changes in this regard.
>
> > If there is anything else I can add, please let me know. I am going to
> > download 4.1.1 now, build it and see if it works, because it does on
> > Xen Server. I am open to testing anything as this is an original build
> > on this box, so I'm willing to knock it around if it will help.
> >
> > #
> >
>
> Knowing whether upstream 4.1.1 works will be very useful in workout out
> whether it is a regression introduced into unstable, or whether there is
> some XenServer specific change which we should upstream.
>
> > Thanks,
> >
> > Paul
> >
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
>
>

--f46d0443066261e39d04b92f6ff7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Andrew,<br>Thanks for the quick response!=A0I was finally able to capt=
ure it and get a bit more information. The problem does not always happen, =
even on 4.1.2, I was able to=A0get it to boot a few times, though I was nev=
er able to get 4.2-unstable to boot. There was lots of strangeness, such as=
 after I built and installed 4.1.1, it worked, but then, so did 4.1.2, now =
neither is working.</div>
<div><br></div><div>That being said, I caught it on video, and captured a p=
icture of the final dump. I watched the video frame by frame and the boot a=
ctually got much further than I thought it was.=A0</div><div><br>I can see =
that even though it does not bring up two of the CPUs, the boot continues i=
nto the kernel and dies somewhere with a:</div>
<div><br></div><div>BUG: Unable to handle paging request at FFFc7f(maybe).<=
/div><div><br></div><div>I have captured several images from the video that=
 shows the progression of the boot before the crash. I think I have gotten =
things badly out of whack at this point, so I&#39;m going to stop, reinstal=
l everything and move back to 4.1.1 and see if I can get things working aga=
in. =A0</div>
<div><br></div><div>Let me know if anything in the pictures helps, or if yo=
u would like the video as well.=A0</div><div><br></div><div>Paul</div><div>=
<br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 11:39 AM, Andrew Coo=
per <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.cooper3@citrix.com">andr=
ew.cooper3@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 17/02/12 16:21, Paul S =
wrote:<br>
&gt; Environment:<br>
&gt; ASRock Z86 Extreme4 - Intel i5 2500<br>
&gt; <a href=3D"http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme=
4" target=3D"_blank">http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Ex=
treme4</a><br>
&gt;<br>
&gt; I have installed the latest UEFI patch(1.70) and all tests were run<br=
>
&gt; from a reset of everything to default. I have tested with both Ubuntu<=
br>
&gt; 11.10 and Fedora 16 and get the same results on both, including<br>
&gt; building xen 4.2-unstable. I bought this particular MB because it had<=
br>
&gt; a know working vt-d implementation via VMWare.<br>
&gt;<br>
&gt; NOTE: current unstable as of last night is still affected by this<br>
&gt; library error <a href=3D"http://www.gossamer-threads.com/lists/xen/dev=
el/234300" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/deve=
l/234300</a><br>
&gt;<br>
&gt; However, after correcting the library error, I was able to complete<br=
>
&gt; the unstable build.<br>
&gt;<br>
&gt; In both cases, it either stops with a panic/blank screen, or just rebo=
ots.<br>
&gt;<br>
&gt; Here are some other notes:<br>
&gt;<br>
&gt; 1) If x2apic is enabled on the motherboard, it almost immediately<br>
&gt; reboots with any of the configurations above<br>
<br>
</div>There are some fairly strict set of requirements on what which MSRs y=
ou<br>
can wrt xAPIC/x2APIC mode. =A0It is possible that we are tickling an MSR<br=
>
early in boot which results in a protection fault.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; 2) The boot gets to here:<br>
&gt;<br>
&gt; (XEN) HVM: VMX enabled<br>
&gt;<br>
&gt; (XEN) HVM: Hardware Assisted Paging detected.<br>
&gt;<br>
&gt;<br>
&gt; Then goes to a &quot;(XEN)Failed to bring up CPU x(error -5)&quot; and=
 this is<br>
&gt; where it hangs with the blank/panic screen or reboots. This sometimes<=
br>
&gt; shows up on CPU 1, CPU2, or both.<br>
&gt;<br>
&gt;<br>
&gt; 3) There is no boot log written and the machine does not have a native=
<br>
&gt; serial port, so capturing anything may prove difficult, but I am open<=
br>
&gt; to suggestions.<br>
&gt;<br>
<br>
</div>Try booting with noreboot - that should keep any panic message on scr=
een<br>
until you manually choose to reset the machine. =A0Seeing where in the<br>
panic occurs would be very helpful, even if you just transcribe a few<br>
lines manually.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; 4) Xen Live(<a href=3D"http://wiki.xen.org/wiki/LiveCD" target=3D"_bla=
nk">http://wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic<br>
&gt; is enabled, then it simply panics and reboots.<br>
&gt;<br>
&gt; The logs(xen_live.tgz) are attached. Note this was captured with VT-d<=
br>
&gt; being enabled, but I did check it with VT-d enabled and the boot<br>
&gt; looked the same. I can capture it again if needed.<br>
&gt;<br>
&gt;<br>
&gt; 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d<br>
&gt; enabled(which shows working in xl) and x2apic enabled.<br>
&gt;<br>
&gt; I have also attached(xen_server_6.0.0.tar.gz) these logs, which<br>
&gt; includes logs both with and without VT-d and x2apic enabled. I did not=
<br>
&gt; actually create any VMs, only booted this and checked what xl reported=
.<br>
&gt;<br>
&gt;<br>
<br>
</div>That is rather interesting - I am not aware of any XenServer specific=
<br>
changes in this regard.<br>
<div class=3D"im"><br>
&gt; If there is anything else I can add, please let me know. I am going to=
<br>
&gt; download 4.1.1 now, build it and see if it works, because it does on<b=
r>
&gt; Xen Server. I am open to testing anything as this is an original build=
<br>
&gt; on this box, so I&#39;m willing to knock it around if it will help.<br=
>
&gt;<br>
</div>&gt; #<br>
&gt;<br>
<br>
Knowing whether upstream 4.1.1 works will be very useful in workout out<br>
whether it is a regression introduced into unstable, or whether there is<br=
>
some XenServer specific change which we should upstream.<br>
<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900">=
+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com" target=3D"_blank=
">http://www.citrix.com</a><br>
<br>
</font></span></blockquote></div><br></div>

--f46d0443066261e39d04b92f6ff7--


--===============8898159192973128626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8898159192973128626==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 21:15:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 21: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.xensource.com>)
	id 1RyV8u-0007zk-Gp; Fri, 17 Feb 2012 21:15:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RyV8s-0007zc-VZ
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:14:59 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1329513291!13822862!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19526 invoked from network); 17 Feb 2012 21:14:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 21:14:52 -0000
Received: by werb14 with SMTP id b14so7137583wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 13:14:51 -0800 (PST)
Received-SPF: pass (google.com: domain of pstroud@gmail.com designates
	10.180.101.72 as permitted sender) client-ip=10.180.101.72; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of pstroud@gmail.com
	designates 10.180.101.72 as permitted sender)
	smtp.mail=pstroud@gmail.com;
	dkim=pass header.i=pstroud@gmail.com
Received: from mr.google.com ([10.180.101.72])
	by 10.180.101.72 with SMTP id fe8mr7616381wib.4.1329513291920 (num_hops
	= 1); Fri, 17 Feb 2012 13:14:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=1iJwGnd9PRGM1tY7ljzyXaTq/IZcjaTEkAOBptn7YLA=;
	b=SGqcgyVLsSXUu/hQS05I2jFcfnz3EtQl24hL+QuMHO+9GawarUPHLGBmyhb1OjjrCB
	Z6bFlQr7g35aDTuvU2QYxQaTCC4C77bd3c5ypO/jaQugqFyg8FG6xGcvKYZwx5bEFyRK
	bnu9EnDGrW8fWFGf+j3zN7g1mXEiNjzJ7X258=
MIME-Version: 1.0
Received: by 10.180.101.72 with SMTP id fe8mr6408603wib.4.1329513290130; Fri,
	17 Feb 2012 13:14:50 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Fri, 17 Feb 2012 13:14:50 -0800 (PST)
In-Reply-To: <4F3E82A8.4060204@citrix.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
Date: Fri, 17 Feb 2012 16:14:50 -0500
Message-ID: <CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8898159192973128626=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8898159192973128626==
Content-Type: multipart/alternative; boundary=f46d0443066261e39d04b92f6ff7

--f46d0443066261e39d04b92f6ff7
Content-Type: text/plain; charset=ISO-8859-1

Andrew,
Thanks for the quick response! I was finally able to capture it and get a
bit more information. The problem does not always happen, even on 4.1.2, I
was able to get it to boot a few times, though I was never able to get
4.2-unstable to boot. There was lots of strangeness, such as after I built
and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
working.

That being said, I caught it on video, and captured a picture of the final
dump. I watched the video frame by frame and the boot actually got much
further than I thought it was.

I can see that even though it does not bring up two of the CPUs, the boot
continues into the kernel and dies somewhere with a:

BUG: Unable to handle paging request at FFFc7f(maybe).

I have captured several images from the video that shows the progression of
the boot before the crash. I think I have gotten things badly out of whack
at this point, so I'm going to stop, reinstall everything and move back to
4.1.1 and see if I can get things working again.

Let me know if anything in the pictures helps, or if you would like the
video as well.

Paul

On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper
<andrew.cooper3@citrix.com>wrote:

> On 17/02/12 16:21, Paul S wrote:
> > Environment:
> > ASRock Z86 Extreme4 - Intel i5 2500
> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
> >
> > I have installed the latest UEFI patch(1.70) and all tests were run
> > from a reset of everything to default. I have tested with both Ubuntu
> > 11.10 and Fedora 16 and get the same results on both, including
> > building xen 4.2-unstable. I bought this particular MB because it had
> > a know working vt-d implementation via VMWare.
> >
> > NOTE: current unstable as of last night is still affected by this
> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
> >
> > However, after correcting the library error, I was able to complete
> > the unstable build.
> >
> > In both cases, it either stops with a panic/blank screen, or just
> reboots.
> >
> > Here are some other notes:
> >
> > 1) If x2apic is enabled on the motherboard, it almost immediately
> > reboots with any of the configurations above
>
> There are some fairly strict set of requirements on what which MSRs you
> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
> early in boot which results in a protection fault.
>
> >
> > 2) The boot gets to here:
> >
> > (XEN) HVM: VMX enabled
> >
> > (XEN) HVM: Hardware Assisted Paging detected.
> >
> >
> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
> > where it hangs with the blank/panic screen or reboots. This sometimes
> > shows up on CPU 1, CPU2, or both.
> >
> >
> > 3) There is no boot log written and the machine does not have a native
> > serial port, so capturing anything may prove difficult, but I am open
> > to suggestions.
> >
>
> Try booting with noreboot - that should keep any panic message on screen
> until you manually choose to reset the machine.  Seeing where in the
> panic occurs would be very helpful, even if you just transcribe a few
> lines manually.
>
> >
> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
> > is enabled, then it simply panics and reboots.
> >
> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
> > being enabled, but I did check it with VT-d enabled and the boot
> > looked the same. I can capture it again if needed.
> >
> >
> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
> > enabled(which shows working in xl) and x2apic enabled.
> >
> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
> > includes logs both with and without VT-d and x2apic enabled. I did not
> > actually create any VMs, only booted this and checked what xl reported.
> >
> >
>
> That is rather interesting - I am not aware of any XenServer specific
> changes in this regard.
>
> > If there is anything else I can add, please let me know. I am going to
> > download 4.1.1 now, build it and see if it works, because it does on
> > Xen Server. I am open to testing anything as this is an original build
> > on this box, so I'm willing to knock it around if it will help.
> >
> > #
> >
>
> Knowing whether upstream 4.1.1 works will be very useful in workout out
> whether it is a regression introduced into unstable, or whether there is
> some XenServer specific change which we should upstream.
>
> > Thanks,
> >
> > Paul
> >
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
>
>

--f46d0443066261e39d04b92f6ff7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Andrew,<br>Thanks for the quick response!=A0I was finally able to capt=
ure it and get a bit more information. The problem does not always happen, =
even on 4.1.2, I was able to=A0get it to boot a few times, though I was nev=
er able to get 4.2-unstable to boot. There was lots of strangeness, such as=
 after I built and installed 4.1.1, it worked, but then, so did 4.1.2, now =
neither is working.</div>
<div><br></div><div>That being said, I caught it on video, and captured a p=
icture of the final dump. I watched the video frame by frame and the boot a=
ctually got much further than I thought it was.=A0</div><div><br>I can see =
that even though it does not bring up two of the CPUs, the boot continues i=
nto the kernel and dies somewhere with a:</div>
<div><br></div><div>BUG: Unable to handle paging request at FFFc7f(maybe).<=
/div><div><br></div><div>I have captured several images from the video that=
 shows the progression of the boot before the crash. I think I have gotten =
things badly out of whack at this point, so I&#39;m going to stop, reinstal=
l everything and move back to 4.1.1 and see if I can get things working aga=
in. =A0</div>
<div><br></div><div>Let me know if anything in the pictures helps, or if yo=
u would like the video as well.=A0</div><div><br></div><div>Paul</div><div>=
<br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 11:39 AM, Andrew Coo=
per <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.cooper3@citrix.com">andr=
ew.cooper3@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 17/02/12 16:21, Paul S =
wrote:<br>
&gt; Environment:<br>
&gt; ASRock Z86 Extreme4 - Intel i5 2500<br>
&gt; <a href=3D"http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme=
4" target=3D"_blank">http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Ex=
treme4</a><br>
&gt;<br>
&gt; I have installed the latest UEFI patch(1.70) and all tests were run<br=
>
&gt; from a reset of everything to default. I have tested with both Ubuntu<=
br>
&gt; 11.10 and Fedora 16 and get the same results on both, including<br>
&gt; building xen 4.2-unstable. I bought this particular MB because it had<=
br>
&gt; a know working vt-d implementation via VMWare.<br>
&gt;<br>
&gt; NOTE: current unstable as of last night is still affected by this<br>
&gt; library error <a href=3D"http://www.gossamer-threads.com/lists/xen/dev=
el/234300" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/deve=
l/234300</a><br>
&gt;<br>
&gt; However, after correcting the library error, I was able to complete<br=
>
&gt; the unstable build.<br>
&gt;<br>
&gt; In both cases, it either stops with a panic/blank screen, or just rebo=
ots.<br>
&gt;<br>
&gt; Here are some other notes:<br>
&gt;<br>
&gt; 1) If x2apic is enabled on the motherboard, it almost immediately<br>
&gt; reboots with any of the configurations above<br>
<br>
</div>There are some fairly strict set of requirements on what which MSRs y=
ou<br>
can wrt xAPIC/x2APIC mode. =A0It is possible that we are tickling an MSR<br=
>
early in boot which results in a protection fault.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; 2) The boot gets to here:<br>
&gt;<br>
&gt; (XEN) HVM: VMX enabled<br>
&gt;<br>
&gt; (XEN) HVM: Hardware Assisted Paging detected.<br>
&gt;<br>
&gt;<br>
&gt; Then goes to a &quot;(XEN)Failed to bring up CPU x(error -5)&quot; and=
 this is<br>
&gt; where it hangs with the blank/panic screen or reboots. This sometimes<=
br>
&gt; shows up on CPU 1, CPU2, or both.<br>
&gt;<br>
&gt;<br>
&gt; 3) There is no boot log written and the machine does not have a native=
<br>
&gt; serial port, so capturing anything may prove difficult, but I am open<=
br>
&gt; to suggestions.<br>
&gt;<br>
<br>
</div>Try booting with noreboot - that should keep any panic message on scr=
een<br>
until you manually choose to reset the machine. =A0Seeing where in the<br>
panic occurs would be very helpful, even if you just transcribe a few<br>
lines manually.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; 4) Xen Live(<a href=3D"http://wiki.xen.org/wiki/LiveCD" target=3D"_bla=
nk">http://wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic<br>
&gt; is enabled, then it simply panics and reboots.<br>
&gt;<br>
&gt; The logs(xen_live.tgz) are attached. Note this was captured with VT-d<=
br>
&gt; being enabled, but I did check it with VT-d enabled and the boot<br>
&gt; looked the same. I can capture it again if needed.<br>
&gt;<br>
&gt;<br>
&gt; 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d<br>
&gt; enabled(which shows working in xl) and x2apic enabled.<br>
&gt;<br>
&gt; I have also attached(xen_server_6.0.0.tar.gz) these logs, which<br>
&gt; includes logs both with and without VT-d and x2apic enabled. I did not=
<br>
&gt; actually create any VMs, only booted this and checked what xl reported=
.<br>
&gt;<br>
&gt;<br>
<br>
</div>That is rather interesting - I am not aware of any XenServer specific=
<br>
changes in this regard.<br>
<div class=3D"im"><br>
&gt; If there is anything else I can add, please let me know. I am going to=
<br>
&gt; download 4.1.1 now, build it and see if it works, because it does on<b=
r>
&gt; Xen Server. I am open to testing anything as this is an original build=
<br>
&gt; on this box, so I&#39;m willing to knock it around if it will help.<br=
>
&gt;<br>
</div>&gt; #<br>
&gt;<br>
<br>
Knowing whether upstream 4.1.1 works will be very useful in workout out<br>
whether it is a regression introduced into unstable, or whether there is<br=
>
some XenServer specific change which we should upstream.<br>
<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900">=
+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com" target=3D"_blank=
">http://www.citrix.com</a><br>
<br>
</font></span></blockquote></div><br></div>

--f46d0443066261e39d04b92f6ff7--


--===============8898159192973128626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8898159192973128626==--


From xen-devel-bounces@lists.xensource.com Fri Feb 17 21:22:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 21:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyVFb-0008ND-On; Fri, 17 Feb 2012 21:21:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@eu.citrix.com>) id 1RyVFa-0008N6-T2
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:21:55 +0000
X-Env-Sender: Dave.Scott@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329513683!57205993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6825 invoked from network); 17 Feb 2012 21:21:23 -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 Feb 2012 21:21:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,440,1325462400"; d="scan'208";a="10782512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 21:21:53 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 17 Feb 2012
	21:21:53 +0000
From: Dave Scott <Dave.Scott@eu.citrix.com>
To: 'Matthew Hook' <matthew.hook@otoy.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 21:21:53 +0000
Thread-Topic: [Xen-devel] persistent or "steady-state" style disks
Thread-Index: Aczs5uoIhsPuws3NTTWFi9iT9fmQ0QAszGiw
Message-ID: <81A73678E76EA642801C8F2E4823AD21D76F8D78BE@LONPMAILBOX01.citrite.net>
References: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@mail.gmail.com>
In-Reply-To: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@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] persistent or "steady-state" style disks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

Matthew Hook wrote:
> I have a requirement (and a limited timeframe) to make a Windows 7 VM domain roll back to a fixed state on restart, shutdown etc.
> Something like a Kiosk Mode.  I think this is a very needed part of the core of xen and this functionality does 
> not appear to be part of xen already.  So I've been trying various ways to make this work.

XCP has a feature which might do what you need.

If you are using .vhd file based storage (SR types 'ext' or 'nfs') then you can do the following: (for a VM called "myvm")

# 1. Ensure the .vhd chain has length 2 (a current restriction)
xe vm-copy vm=myvm new-name-label=nonpersistent.parent
xe vm-clone vm=nonpersistent.parent new-name-label=nonpersistent

# 2. Set the VDI on-boot=reset
xe vm-disk-list vm=nonpersistent
 ... note the VDI uuid of the disk you want to reset ...
xe vdi-param-set uuid=... on-boot=reset

# 3. Start the VM
xe vm-start vm=nonpersistent

HTH,
Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 21:22:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 21:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyVFb-0008ND-On; Fri, 17 Feb 2012 21:21:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@eu.citrix.com>) id 1RyVFa-0008N6-T2
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:21:55 +0000
X-Env-Sender: Dave.Scott@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329513683!57205993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzI5NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6825 invoked from network); 17 Feb 2012 21:21:23 -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 Feb 2012 21:21:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,440,1325462400"; d="scan'208";a="10782512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 21:21:53 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 17 Feb 2012
	21:21:53 +0000
From: Dave Scott <Dave.Scott@eu.citrix.com>
To: 'Matthew Hook' <matthew.hook@otoy.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 17 Feb 2012 21:21:53 +0000
Thread-Topic: [Xen-devel] persistent or "steady-state" style disks
Thread-Index: Aczs5uoIhsPuws3NTTWFi9iT9fmQ0QAszGiw
Message-ID: <81A73678E76EA642801C8F2E4823AD21D76F8D78BE@LONPMAILBOX01.citrite.net>
References: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@mail.gmail.com>
In-Reply-To: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@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] persistent or "steady-state" style disks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

Matthew Hook wrote:
> I have a requirement (and a limited timeframe) to make a Windows 7 VM domain roll back to a fixed state on restart, shutdown etc.
> Something like a Kiosk Mode.  I think this is a very needed part of the core of xen and this functionality does 
> not appear to be part of xen already.  So I've been trying various ways to make this work.

XCP has a feature which might do what you need.

If you are using .vhd file based storage (SR types 'ext' or 'nfs') then you can do the following: (for a VM called "myvm")

# 1. Ensure the .vhd chain has length 2 (a current restriction)
xe vm-copy vm=myvm new-name-label=nonpersistent.parent
xe vm-clone vm=nonpersistent.parent new-name-label=nonpersistent

# 2. Set the VDI on-boot=reset
xe vm-disk-list vm=nonpersistent
 ... note the VDI uuid of the disk you want to reset ...
xe vdi-param-set uuid=... on-boot=reset

# 3. Start the VM
xe vm-start vm=nonpersistent

HTH,
Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 21:41:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 21: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.xensource.com>)
	id 1RyVY5-00008t-V7; Fri, 17 Feb 2012 21:41:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyVY4-00008o-6q
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:41:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329514853!13864084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1405 invoked from network); 17 Feb 2012 21:40:53 -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;
	17 Feb 2012 21:40:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,440,1325462400"; d="scan'208";a="10782839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 21:40:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 21:40:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyVXn-0007d0-8y;
	Fri, 17 Feb 2012 21:40:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyVXn-0007qW-8G;
	Fri, 17 Feb 2012 21:40:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11981-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 21:40:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11981: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11981 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11981/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11980

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  87218bd367be
baseline version:
 xen                  b5ac7d99d93f

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Kaixing Hong <hongkaixing@huawei.com>,
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhen Shi <bicky.shi@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=87218bd367be
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 87218bd367be
+ branch=xen-unstable
+ revision=87218bd367be
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 87218bd367be 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 21:41:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 21: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.xensource.com>)
	id 1RyVY5-00008t-V7; Fri, 17 Feb 2012 21:41:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RyVY4-00008o-6q
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:41:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329514853!13864084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mjk5MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1405 invoked from network); 17 Feb 2012 21:40:53 -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;
	17 Feb 2012 21:40:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,440,1325462400"; d="scan'208";a="10782839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Feb 2012 21:40:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 17 Feb 2012 21:40:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RyVXn-0007d0-8y;
	Fri, 17 Feb 2012 21:40:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RyVXn-0007qW-8G;
	Fri, 17 Feb 2012 21:40:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11981-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 17 Feb 2012 21:40:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11981: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11981 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11981/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11980

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  87218bd367be
baseline version:
 xen                  b5ac7d99d93f

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Kaixing Hong <hongkaixing@huawei.com>,
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Zhen Shi <bicky.shi@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=87218bd367be
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 87218bd367be
+ branch=xen-unstable
+ revision=87218bd367be
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 87218bd367be 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.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 22:57:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 22:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyWje-0001DU-KP; Fri, 17 Feb 2012 22:57:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RyWjc-0001DP-Ax
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 22:57:00 +0000
Received: from [85.158.139.83:17523] by server-11.bemta-5.messagelabs.com id
	12/A4-14397-B3BDE3F4; Fri, 17 Feb 2012 22:56:59 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329519418!15565417!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2883 invoked from network); 17 Feb 2012 22:56:58 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 22:56:58 -0000
Received: by wibhm2 with SMTP id hm2so6082573wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 14:56:58 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr10090639wib.3.1329519418677
	(num_hops = 1); Fri, 17 Feb 2012 14:56:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr8487634wib.3.1329519418626; Fri,
	17 Feb 2012 14:56:58 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Fri, 17 Feb 2012 14:56:58 -0800 (PST)
Date: Fri, 17 Feb 2012 14:56:58 -0800
Message-ID: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQk4bsZzNd/CUg6Hlqg3eXuL7ut2CtgyDLHOi9YwCMs0dZExkZAVUDykNRm+exZcnnrKeszp
Subject: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I think this is a bug in the xl toolchain.

lspci -s 0000:12:0.*
12:00.0 Display controller: ATI Technologies Inc Device 671d
12:00.1 Audio device: ATI Technologies Inc Device aa80

sudo xm pci-list-assignable-devices
0000:13:00.0
0000:13:00.1
0000:12:00.0
0000:12:00.1

So there is a multi-function device (actually one ASIC of a AMD Radeon
6990 card).
It has two function addresses 0 = Display controller, 1 = Audio Device.

However when running xl create where the line for pci is of the form
pci=['12:00.*']
Where * means pass through all devices, you get an error as below.

Parsing config file xenwin7-1.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->0000000000179830
  TOTAL:         0000000000000000->000000007f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device
0:12:0.70 is not assignable

There is no function 70 on that device.

In relation to that, the BDF documentation
(http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
you can specify
the extended BDF notation on your kernel boot line in grub.  i.e.
xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
the kernel log.

Actually, if you look at the code for pci_stub.c in the linux kernel
(at least for Jeremy branch 2.6.32.48), extended BDF is not supported.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Feb 17 22:57:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 17 Feb 2012 22:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RyWje-0001DU-KP; Fri, 17 Feb 2012 22:57:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RyWjc-0001DP-Ax
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 22:57:00 +0000
Received: from [85.158.139.83:17523] by server-11.bemta-5.messagelabs.com id
	12/A4-14397-B3BDE3F4; Fri, 17 Feb 2012 22:56:59 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329519418!15565417!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2883 invoked from network); 17 Feb 2012 22:56:58 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 22:56:58 -0000
Received: by wibhm2 with SMTP id hm2so6082573wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 14:56:58 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr10090639wib.3.1329519418677
	(num_hops = 1); Fri, 17 Feb 2012 14:56:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr8487634wib.3.1329519418626; Fri,
	17 Feb 2012 14:56:58 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Fri, 17 Feb 2012 14:56:58 -0800 (PST)
Date: Fri, 17 Feb 2012 14:56:58 -0800
Message-ID: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQk4bsZzNd/CUg6Hlqg3eXuL7ut2CtgyDLHOi9YwCMs0dZExkZAVUDykNRm+exZcnnrKeszp
Subject: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I think this is a bug in the xl toolchain.

lspci -s 0000:12:0.*
12:00.0 Display controller: ATI Technologies Inc Device 671d
12:00.1 Audio device: ATI Technologies Inc Device aa80

sudo xm pci-list-assignable-devices
0000:13:00.0
0000:13:00.1
0000:12:00.0
0000:12:00.1

So there is a multi-function device (actually one ASIC of a AMD Radeon
6990 card).
It has two function addresses 0 = Display controller, 1 = Audio Device.

However when running xl create where the line for pci is of the form
pci=['12:00.*']
Where * means pass through all devices, you get an error as below.

Parsing config file xenwin7-1.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->0000000000179830
  TOTAL:         0000000000000000->000000007f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device
0:12:0.70 is not assignable

There is no function 70 on that device.

In relation to that, the BDF documentation
(http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
you can specify
the extended BDF notation on your kernel boot line in grub.  i.e.
xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
the kernel log.

Actually, if you look at the code for pci_stub.c in the linux kernel
(at least for Jeremy branch 2.6.32.48), extended BDF is not supported.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 04:58:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 04: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.xensource.com>)
	id 1RycN4-00089A-Nz; Sat, 18 Feb 2012 04:58:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RyVOx-00007R-5O
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:31:36 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329514288!11944982!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14050 invoked from network); 17 Feb 2012 21:31:28 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 21:31:28 -0000
Received: by wibhm2 with SMTP id hm2so5973891wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 13:31:28 -0800 (PST)
Received-SPF: pass (google.com: domain of pstroud@gmail.com designates
	10.180.82.227 as permitted sender) client-ip=10.180.82.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of pstroud@gmail.com
	designates 10.180.82.227 as permitted sender)
	smtp.mail=pstroud@gmail.com;
	dkim=pass header.i=pstroud@gmail.com
Received: from mr.google.com ([10.180.82.227])
	by 10.180.82.227 with SMTP id l3mr7699813wiy.1.1329514288009 (num_hops
	= 1); Fri, 17 Feb 2012 13:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=w+PjDJXvxnLpM6xH0LvEVfLyzum/+hwSwO8tyTqRSA4=;
	b=rMbQzEmung+FKrd1AEVphSsaAgxwUC3wap/LOQfXpzK3vpE2LIPuBuW7bcV9rWbljE
	wLuINnfqe4Ohzd2/nWlIUwyBp8Vwb8I9IpRHXz1CQpmftE71HrvnLv4en9x2zaELwTvU
	NlMooDnbgWpEyAk/nGFTquaxUKjx6VYR+lRBo=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr6484015wiy.1.1329514287918; Fri,
	17 Feb 2012 13:31:27 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Fri, 17 Feb 2012 13:31:27 -0800 (PST)
In-Reply-To: <CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
Date: Fri, 17 Feb 2012 16:31:27 -0500
Message-ID: <CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary=f46d0444040adaef0c04b92faae6
X-Mailman-Approved-At: Sat, 18 Feb 2012 04:58:05 +0000
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--f46d0444040adaef0c04b92faae6
Content-Type: multipart/alternative; boundary=f46d0444040adaef0904b92faae4

--f46d0444040adaef0904b92faae4
Content-Type: text/plain; charset=ISO-8859-1

File attached.

On Fri, Feb 17, 2012 at 4:14 PM, Paul S <pstroud@gmail.com> wrote:

> Andrew,
> Thanks for the quick response! I was finally able to capture it and get a
> bit more information. The problem does not always happen, even on 4.1.2, I
> was able to get it to boot a few times, though I was never able to get
> 4.2-unstable to boot. There was lots of strangeness, such as after I built
> and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
> working.
>
> That being said, I caught it on video, and captured a picture of the final
> dump. I watched the video frame by frame and the boot actually got much
> further than I thought it was.
>
> I can see that even though it does not bring up two of the CPUs, the boot
> continues into the kernel and dies somewhere with a:
>
> BUG: Unable to handle paging request at FFFc7f(maybe).
>
> I have captured several images from the video that shows the progression
> of the boot before the crash. I think I have gotten things badly out of
> whack at this point, so I'm going to stop, reinstall everything and move
> back to 4.1.1 and see if I can get things working again.
>
> Let me know if anything in the pictures helps, or if you would like the
> video as well.
>
> Paul
>
> On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper <andrew.cooper3@citrix.com
> > wrote:
>
>> On 17/02/12 16:21, Paul S wrote:
>> > Environment:
>> > ASRock Z86 Extreme4 - Intel i5 2500
>> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
>> >
>> > I have installed the latest UEFI patch(1.70) and all tests were run
>> > from a reset of everything to default. I have tested with both Ubuntu
>> > 11.10 and Fedora 16 and get the same results on both, including
>> > building xen 4.2-unstable. I bought this particular MB because it had
>> > a know working vt-d implementation via VMWare.
>> >
>> > NOTE: current unstable as of last night is still affected by this
>> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
>> >
>> > However, after correcting the library error, I was able to complete
>> > the unstable build.
>> >
>> > In both cases, it either stops with a panic/blank screen, or just
>> reboots.
>> >
>> > Here are some other notes:
>> >
>> > 1) If x2apic is enabled on the motherboard, it almost immediately
>> > reboots with any of the configurations above
>>
>> There are some fairly strict set of requirements on what which MSRs you
>> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
>> early in boot which results in a protection fault.
>>
>> >
>> > 2) The boot gets to here:
>> >
>> > (XEN) HVM: VMX enabled
>> >
>> > (XEN) HVM: Hardware Assisted Paging detected.
>> >
>> >
>> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
>> > where it hangs with the blank/panic screen or reboots. This sometimes
>> > shows up on CPU 1, CPU2, or both.
>> >
>> >
>> > 3) There is no boot log written and the machine does not have a native
>> > serial port, so capturing anything may prove difficult, but I am open
>> > to suggestions.
>> >
>>
>> Try booting with noreboot - that should keep any panic message on screen
>> until you manually choose to reset the machine.  Seeing where in the
>> panic occurs would be very helpful, even if you just transcribe a few
>> lines manually.
>>
>> >
>> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
>> > is enabled, then it simply panics and reboots.
>> >
>> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
>> > being enabled, but I did check it with VT-d enabled and the boot
>> > looked the same. I can capture it again if needed.
>> >
>> >
>> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
>> > enabled(which shows working in xl) and x2apic enabled.
>> >
>> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
>> > includes logs both with and without VT-d and x2apic enabled. I did not
>> > actually create any VMs, only booted this and checked what xl reported.
>> >
>> >
>>
>> That is rather interesting - I am not aware of any XenServer specific
>> changes in this regard.
>>
>> > If there is anything else I can add, please let me know. I am going to
>> > download 4.1.1 now, build it and see if it works, because it does on
>> > Xen Server. I am open to testing anything as this is an original build
>> > on this box, so I'm willing to knock it around if it will help.
>> >
>> > #
>> >
>>
>> Knowing whether upstream 4.1.1 works will be very useful in workout out
>> whether it is a regression introduced into unstable, or whether there is
>> some XenServer specific change which we should upstream.
>>
>> > Thanks,
>> >
>> > Paul
>> >
>>
>> --
>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>> T: +44 (0)1223 225 900, http://www.citrix.com
>>
>>
>

--f46d0444040adaef0904b92faae4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

File attached.<br><br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 4:=
14 PM, Paul S <span dir=3D"ltr">&lt;<a href=3D"mailto:pstroud@gmail.com">ps=
troud@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>Andrew,<br>Thanks for the quick response!=A0I was finally able to capt=
ure it and get a bit more information. The problem does not always happen, =
even on 4.1.2, I was able to=A0get it to boot a few times, though I was nev=
er able to get 4.2-unstable to boot. There was lots of strangeness, such as=
 after I built and installed 4.1.1, it worked, but then, so did 4.1.2, now =
neither is working.</div>

<div><br></div><div>That being said, I caught it on video, and captured a p=
icture of the final dump. I watched the video frame by frame and the boot a=
ctually got much further than I thought it was.=A0</div><div><br>I can see =
that even though it does not bring up two of the CPUs, the boot continues i=
nto the kernel and dies somewhere with a:</div>

<div><br></div><div>BUG: Unable to handle paging request at FFFc7f(maybe).<=
/div><div><br></div><div>I have captured several images from the video that=
 shows the progression of the boot before the crash. I think I have gotten =
things badly out of whack at this point, so I&#39;m going to stop, reinstal=
l everything and move back to 4.1.1 and see if I can get things working aga=
in. =A0</div>

<div><br></div><div>Let me know if anything in the pictures helps, or if yo=
u would like the video as well.=A0</div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div><br></div><div>Paul</div></font></span><div class=3D"HOEn=
Zb">
<div class=3D"h5"><div><br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 =
at 11:39 AM, Andrew Cooper <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.c=
ooper3@citrix.com" target=3D"_blank">andrew.cooper3@citrix.com</a>&gt;</spa=
n> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 17/02/12 16:21, Paul S wrote:<br>
&gt; Environment:<br>
&gt; ASRock Z86 Extreme4 - Intel i5 2500<br>
&gt; <a href=3D"http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme=
4" target=3D"_blank">http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Ex=
treme4</a><br>
&gt;<br>
&gt; I have installed the latest UEFI patch(1.70) and all tests were run<br=
>
&gt; from a reset of everything to default. I have tested with both Ubuntu<=
br>
&gt; 11.10 and Fedora 16 and get the same results on both, including<br>
&gt; building xen 4.2-unstable. I bought this particular MB because it had<=
br>
&gt; a know working vt-d implementation via VMWare.<br>
&gt;<br>
&gt; NOTE: current unstable as of last night is still affected by this<br>
&gt; library error <a href=3D"http://www.gossamer-threads.com/lists/xen/dev=
el/234300" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/deve=
l/234300</a><br>
&gt;<br>
&gt; However, after correcting the library error, I was able to complete<br=
>
&gt; the unstable build.<br>
&gt;<br>
&gt; In both cases, it either stops with a panic/blank screen, or just rebo=
ots.<br>
&gt;<br>
&gt; Here are some other notes:<br>
&gt;<br>
&gt; 1) If x2apic is enabled on the motherboard, it almost immediately<br>
&gt; reboots with any of the configurations above<br>
<br>
</div>There are some fairly strict set of requirements on what which MSRs y=
ou<br>
can wrt xAPIC/x2APIC mode. =A0It is possible that we are tickling an MSR<br=
>
early in boot which results in a protection fault.<br>
<div><br>
&gt;<br>
&gt; 2) The boot gets to here:<br>
&gt;<br>
&gt; (XEN) HVM: VMX enabled<br>
&gt;<br>
&gt; (XEN) HVM: Hardware Assisted Paging detected.<br>
&gt;<br>
&gt;<br>
&gt; Then goes to a &quot;(XEN)Failed to bring up CPU x(error -5)&quot; and=
 this is<br>
&gt; where it hangs with the blank/panic screen or reboots. This sometimes<=
br>
&gt; shows up on CPU 1, CPU2, or both.<br>
&gt;<br>
&gt;<br>
&gt; 3) There is no boot log written and the machine does not have a native=
<br>
&gt; serial port, so capturing anything may prove difficult, but I am open<=
br>
&gt; to suggestions.<br>
&gt;<br>
<br>
</div>Try booting with noreboot - that should keep any panic message on scr=
een<br>
until you manually choose to reset the machine. =A0Seeing where in the<br>
panic occurs would be very helpful, even if you just transcribe a few<br>
lines manually.<br>
<div><br>
&gt;<br>
&gt; 4) Xen Live(<a href=3D"http://wiki.xen.org/wiki/LiveCD" target=3D"_bla=
nk">http://wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic<br>
&gt; is enabled, then it simply panics and reboots.<br>
&gt;<br>
&gt; The logs(xen_live.tgz) are attached. Note this was captured with VT-d<=
br>
&gt; being enabled, but I did check it with VT-d enabled and the boot<br>
&gt; looked the same. I can capture it again if needed.<br>
&gt;<br>
&gt;<br>
&gt; 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d<br>
&gt; enabled(which shows working in xl) and x2apic enabled.<br>
&gt;<br>
&gt; I have also attached(xen_server_6.0.0.tar.gz) these logs, which<br>
&gt; includes logs both with and without VT-d and x2apic enabled. I did not=
<br>
&gt; actually create any VMs, only booted this and checked what xl reported=
.<br>
&gt;<br>
&gt;<br>
<br>
</div>That is rather interesting - I am not aware of any XenServer specific=
<br>
changes in this regard.<br>
<div><br>
&gt; If there is anything else I can add, please let me know. I am going to=
<br>
&gt; download 4.1.1 now, build it and see if it works, because it does on<b=
r>
&gt; Xen Server. I am open to testing anything as this is an original build=
<br>
&gt; on this box, so I&#39;m willing to knock it around if it will help.<br=
>
&gt;<br>
</div>&gt; #<br>
&gt;<br>
<br>
Knowing whether upstream 4.1.1 works will be very useful in workout out<br>
whether it is a regression introduced into unstable, or whether there is<br=
>
some XenServer specific change which we should upstream.<br>
<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
<span><font color=3D"#888888"><br>
--<br>
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
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><br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br>

--f46d0444040adaef0904b92faae4--
--f46d0444040adaef0c04b92faae6
Content-Type: application/zip; name="images.zip"
Content-Disposition: attachment; filename="images.zip"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyrqgvei0

UEsDBBQAAAAIAHh/UUDvny/+4MkAAD7KAAAMABwAYXNkZjA1ODMuanBnVVQJAAPEvz5PrsA+T3V4
CwABBOgDAAAE6AMAAJz9VVAlXRM1DB6kcbfGadzdHZrG3d3d3Rto3N3dnYMe3N0a94O7uzU+z/vN
P9/N3ExMXlTljoyoWLsqMnOtHXtHfa1+fQJQ5Iw9TDnZmHi4mVgBX+sAMQAcDAwsDCzc/zF4eHgE
BAT4//ftP0NCQkL4vx4SMgoyMvJ/VxRUVFQMDHR0bGxsPDySryGIIgAA4hvE/zHA/2MQkFDQ3/57
LDwCIgQACuL/Y/9fQTQAJAQUFCQ01Ldv0ND/Rfz+iwGg0b9hkLKKwmAqG8OSOWOxBSYWwpH/bOjH
Vpm7oWA3cQmCR8D5jouHT0lFTUNLx8HJxc3Dyyf2S1xCUkpaRlVNXUNTS1vH1MzcwtLK2sbVzd3D
08vbJzgkNCw8IjIqKTklNS09IzOrqLiktKy8orKqsQnU3NLa1t4xMDg0PDI6Nj4xv7C4tLyyugbe
3ds/ODw6Pjk9u727f3h8ev738or+H2RIaGgoaNj/QYaA9PzffNChv5GywmCIKsMaO2OSsQXCYf1M
LGzohydnV7nBNnGZQ8Ch4NilvP0f6v8D+v83zEH/f4H+v5j/L+SvPgA6HMQO1A8oCDIAJDoACh3w
BQYgQUH8N/jPFwbsDFPCRCUWWoflSov+RPDCAifyLQ2pMK0XktVEVIBGwM2BWWu/xhPgwkv5J6oR
ijmZ5qIEM6KELTnypIEUIuL8Ezq1onoTd3HWctR4QOYfrEVSHlGEP49sKvuxN87mGIjx58R7sKTa
U5hV1j7pDp4AZTVi1QppR0v1t0/IS/4py6HkFTfxmTU4Tb0iTzLSW1N/Stz6n4GxQrrBe/y2JgKd
VqnLlCRuFdMotrGty7WmDThS6KbbXfW4HkLHQLvVf1m+rg4jNGsF08vkyfmq6r7PyNHPz5TulKDQ
La3Qk8Rnsz/rPdflu/qtmeWTlTJhrE/DgREufEHNx/de0dNjODejmcsuE71ch8+V6UP3sZKXh5gB
6YeXlzEmGS+JSRCtt9Cikqgu6mF8QT5qBoz1cdvKiab6BfeB1xpCa585jh4w9sNBT0gKrkqGAit3
HPM5DRUput/5eNPC7anT/Og1ZO1UobFS8ElYDVak2zopoAgDrqer36f49mWTZi8tNb8AzsGof9VL
o2Gz8iehVQ8QM8LIULHPufqZOL4AqGJkV7oVZpG3s7cbKznSuKpZZwwCpkg4LfUEYh3TAj/fXkkK
Dc817WEyZa4HSjYM2T6PwGtjM6or88VfgBA2i3RFrcOfzCkZG3EZ16p1EXOhF5o/Mq4MAya88S41
VIeX5+RLM4qFDPJCRQQVbLknOCSFB3Nltr1tI6TUx37k9NbCAvX94DnaLk3jwPxhVji+YQmx/dIH
TH50K+/UHmwXqoR/qtoOvgA+jeW3yGlF9ZzPOY26N2XEUFU5f6y6JGLyMU/hS22QIiCraYyKC/aa
ODb59FWu+LUauu/H94Dnr31Ltb9nS0WUiqkFUFJJwh7hHi5VEDN7Dsyu3m3Ulp4Y5pL7sob8PX75
mqqsQRP1+ahLddFWyB+ibpLLJuN3GmcTp26M7suziWRa9sXdajsv9sgsu9q+2k9d5XtY3IVW7Rav
r9xWzSYn1M8xUXbdZQlcJNu176Bmw1KBuiR3F5uXMaanhN5tVs/H9XJMmoHu55goJTHr+L5zTnGS
lGKWVpVUt98iV+ybkV9ijcEbRkEwtNLVkDo5fluBFbq/KKxceKchXpzPT/8taoB1N8CKzscSQcy7
FA6OBVNur1slBvRh+ia0Q90/Yp37j2Hjp9ujDRuagQOT9CVDQX8skR8Fq7mKRiwpHf6ZSrUuN9MA
LRiwmxZ66HFrF/RRg6jjtvWb0yThogiTpKDKuynRs3RWQmuAbi/XjCENLy4ZcxQjpyw+RY+cM8MF
hl0WEq2Jmg5Xkjyv7rUTb7otbQ2JW16HXK1vxTHuXG8d94t+dCPV1V0ripy5y7lExYOt3iTcm6OK
OqB05zNnMExYx1BrouPdVBcqc60HwhjODHljVZLks0RAqrsBnDl+7Ft6LHaNOawzlGuCv3Je16vy
7gnDlr30oRvmkPCcKQUZP1RcNw3IN+rvIfGWGikC1/5q5cyh3B3FhloxJF8MYfwg0NOf7q6OQCpp
cYQKXPEm9QUwvI7rW6perRmOicQLdTfK700O4vIEK+JVpKg/4B1/AYwyRijgZPLCsdZtNfO8dvo3
ye0JPV81K2QZNJ46fKyXnfVJaDKlM51QeBno+SWiNjWOnniSL4UdlZvIn52Ok0CLaDVOHT1Zr+r9
rf5aSPkjTbHuWzwQzZmrLIlObc5zbZd6xeUTBA08JfsFf9wqwPng7JhlfQlx0UouFezqE0iUFBRQ
p9W66qKcU2lRVOE3SkZKuG9FUTQmhLSLcwo1YEBJaUmpceH5fA5t9XwO3R7kwjBbHv0vNvNqlj+K
nOp0f+mz7JBpZJhFVXLyctRYqgrGeSuRtoLK+liGk9M4f1gl+lgU82eV6P6+G4I4sy755m1p+ixB
18akS7E0jiTdd1TFbnZDW0Y20bIbrM8U7lghRgJmGPvxe9j7crm9Qjmi9nxA80Z7+FCPRUR0nHeU
s0Qbg+dS4cx3MpPCuL6BV3kWv/jJ5UPe9mwEujtHQow5w0lSTHuG9oKOYuLXzyVJHX/S+BYbcvL2
YeqkSxUk140KXHVs5c11cM1HPpE8x4UOoMTUdDHLOA4oTRcXVM2RWQDDFqjcQquVLMdbkMiuoFGm
uugq70Dd0F48rSJO1EjfEzk4UipC6FEnuEBq4SRp59+8bb19JmIcdVHaMKV8prqoIx97Gqwnvk7Y
7OlTXBH5GdZGP7NXc46vynoozPnL+s7vLK7dzNaULEUFX1TJJpQDrCotZaxCrWMuyLecwJ5YbT0P
XJJVSHWK2sRbdXGvhv7djEQ/peP+YjPHEMdmvcZb/rN9it+SU6Od4TcFCigd1lPGOR4LSDIpFkHW
MnfY8IDd8BGNXBZJXEz3EusiM3qSca1t7kzwFgWWN9g6/yXP53EH3mYkefv1VHIRS8YvtXDxaCtq
D1llcEXtinnP6NBfas0YUGb9qZ0khvfdMTlof77+AfnnjGSzb8W63xurUkwvHfXKVmvNIyK8Oz3B
F4BFwmXEDXEgie/TzbCJftG/uuz0qZEDBiYifB1i2oVdB3mn2hqJkYColFsO/rjMq8pnIy39O7KL
I45ippxznBO7Zrph6+dyk3n2Mxlao2sfz7Wi0uyxcFNB3Bfg4joh+wlV+VTlrENr4YDV1/KGQ38G
e7pKW4/B3//jox4lQCdfb7G4u40pFzJ0ppb2HmGU0RO9vzZpRbQR3yHfmyblZeh6lNR5w0eDYYjT
A+denCrc2C55pBGWf7EeFqYEg2e92pHNE42er5LnyuOJKvlCtUD/RNVTfhDv1WdFrGTc0dqviiFJ
4vvFFVYSHOMqqs98mi19tD2euZlTjed+Bd4+x1L4hNOzBiaD7wQLyVb/6LHGwc3c52jLIhkzOX9q
KkAAYjvqnDM6W7VEfyAWj0xxMybmsgLEX5os2RAij+/taWeuYSQkNwuGjudvBb2pb2hcpmy9+biw
OavavIqdpktspwl2Jv9DWG3j2h9qAMn1aLer5rE+tx+XWp816g7vI1rrF3mJQa6ShrFuPFQkhbtc
OO3N+7ti1vIllQSwarrpE+sbuGI0UUHwksfRNy7VOQycURHYWrS6eHTyUJNcRPUWfcRBlICIddYF
HKgdhPf3ieDPl0vv1p1LvP0OqMCaMY8adAFQUcCs5ZUx+5/HRAIjI0JlRTcfIG4+YIknNJyOaFse
7JEtz1VfK0qgQAfrkhigKICmEJqklq60OaT15044Aike77X+U9nlFwDusxjublHc761Z4QYl9guw
UhMAO0TVsvz8i8LYMXWm7rfvklZxzDo5xncBFWx3e2CSosMj2ItpnvZwUS4RHtoZB+xzaP1qetpx
BbTGnmrUvdhqdILNkXCy5tmu0NuTc/E0XM48bPwCIHu+Dp4O8E96XZTsPr2UcoX2nxFgZS2B+Nw0
lFbXGM6edtdu01xbBSWcZdeKUmuc0cDyron47AlsP4MUD2jLYCVGWHzjUte98NW/r1RTKA/hz4sF
Cdm9qvuRy8arrFDFvSBJoR+sL/D7+LvLpPhGHEyMBfN+2GzW5vt6I7Wiw3jt4bmgiuqjAO1LpQFS
Jl4l90O+LWid0qNUHfT8NByT+h7znOO6/B6b8V1Sl5LUGcR6egc7CaLDOg313Ys5o3ZIcTB7EMfE
zUq35F+ALtuqG9T3ULPpvTKwkodvXcCp9h3T3hGb5RwnvTDDFCYqZ0vhZu7UCas0V3JFXzz54A81
Ei4Uj3gn+mpQYukyx6J6IhBn5wLD0uF20exWk5y5c5hMSeH7AezV/pzrB1130hWHE1dLa2vE0RZ9
JAZrOg2BDarGhTB+LVUWxs+xCddp3BXb3Z+Jp+AXDaPfQYpFeYNRuyiKGX9Rtz6JS3ziHlyE9og4
/zai5kb72aBIAa9RTk5rZhh+pa5h8rxGzTbfpL3JrlExowVKK/nrb70vuvAH84q3Zu6z0bGKOBnC
Ovhxu5VRKAztYMa1HWOvfsSgwsFD17J7TSh9W/V18Tmq+eewoMgH08SR2MR3oXJgClWmKpSql2e2
PbYrx4bhVOPE5gTf98hTcXuuPxpkb8JcTY5thm+LbXkQrJX3Y04i+8kbO5rhtM3Hd690oV6v/1qx
f8TJmvVVU9W+vOEG9Iwr51dcK2T871XlwJywFSt1bs3LatLRnvNvNAk430xXEu+ZY+afRNn3Ohs2
D2ItSJHXhScPKICKprjzbqX9Iy4D4u+F2kcT1tF98ePQI1BLmssa3LBWHhbAT9GHly9wek6fqCVH
Meyg7W5f+FTrHv5lZZ04VYMRxiOOVnYYf8Nyko3QYRge05RQtUmxPaSfvPBHqgm8QTgsoa+PsiN6
xl6RrDLyuQS9wf7PrpY7V0wTO7hPFUTMNVHCT2yKLcKOVpQ7aQSQKSOeO4pg1LGTsLLiWuusB2sf
WQqaj6t+TA9h3LFYU3trSORmVCfmCOwtcR/+IWXwuF/GCDwuYZxQqgxSrQqrIrbJimLevZDM1ajB
6uurWvKqohVEohOq2CJJ4YkN0Bid9Ocf+0EU4Pk/j2q0yhns6opTNLD2qiIeZS0mY15mdZZE1N3a
pt5Y212y0wxWDbsQvYs3VdkQepwe5sm3X9nbca4bRl+AUN3WuSsmMb6RQ81rtPL4OkIVdKUJ+AEo
eavD5OU6AqowUZJ0+jGfH7GN/sF4wqFc2kyFhv+eEr/ze3LY8T6ME9nUvEHI1+RK6EaFYosF6sMA
C/R0Vgfd5g8mINbzhnzca92Vg90L5JbNYpU97vW5YqE9uRrJJXBfLB2X23GzE5A9dNS+ezxNCbZJ
roYkLFnrJcfmTc1rII/Anz+WoksUH5Hl+gVQLg32zLZTBz5W2RMm+Sy2xeSWtCp2jlddu37MyaQp
+NkYWxRfs5DoiEwg0zf/GpvSNEeXnA1Wz3Mn+kYVosmSd5ShhOD7V1FUfTNj9ofJt19DSqIc8zQQ
7ZVoi+5kqnF7dhtzR+tkwQtR1yZCJmEGbPQzbo+DkPQt9V1qIbA78Tpn5RSJkzwtY5zuZFS8F7bh
7bzIj5wr5/gpzARkLboLX4C6+bbz4Lv8ypqzzqx+rfGEe+WjfGqduHqLdHZWeQ5Qau577M+k3Ch7
aVEFBRDYxb0qEoPzYnavdkkXT2LDBMg6XltxYTG+A8BvPEBX25/ShULMAv2K/IELU+T5cia1urNX
CNY+3RpgrPxm/ZYSVeWJQmMyQdNpQkL3HhIVhMy2d4bHhGUfJVS7AekHW1lqDS+mz4BB8YnOMhzP
yezJFtfp55+So8pEhYUvPghunt8ZKYfNz74D+qKibk0k8tDkOQ8ZxyH6Y13DS/K0cbvktqCTbF/h
aTzVxgZLV2sbDK1f6hhuhL5V/1Nu/Ql0ZTNE2hpu4/2peg3wJtGx6yHoiRgpEsiU0CQ8an0X5+i1
DyCjFdKA0cQDD7QGgOZ53f7JQB0VDAa47eWPEf6e4UxWzOONgY2E6MdaM8laP0xAs9UcSsJeuvKA
lE51juu2McQGeYdbbt0lewh6xIG0MHgjKfuBWhz6EmdrVJEiUQ5YV1CcM3q8hCsF1k0l/jiNrl2t
Gf0eZrmj5TKeGvi8v2avs3RD1RlmXanYnFWiZVMitQMRRgF5vA+1+YOeKtriwEkeKq1lGPDmf+z/
USN2UOeMq4M+FB55eJT+c+4LcD6bBRMHebd8RZO6xQ23SfggHCuOklgp/z0bS24u+U9fDOapQSiH
x/x4jU5nuJYpJSn9gJFHVQdmwc1jhV38v4w/JU5CzwE2Ycl+onr3vRfAn3uaUTRm1piUKWYso3Vi
2ncviawYGHA8gl6cZ1yFxbceRRA766xfgFH6mWYCjdTjZGiaxPYfr4s89FnACP9+D1Ld2GRv+2fD
I7B/WBrFIrQtSK6h/cW5jZ7EYaRjHPZdOc3S10F6xsSLutStQ+/V55QPmhsOr1Trd8v+odH2DAdP
bbDUnbd9rYEjsylH9wKs576y7Lepagg6AcmKsdE9+sXjhpY3w4grkaHxeomPRcKrH6hieh7tpn4f
+eaCf8fpZBBGqW8JWUnS6HhJnKz63vzGf4ZZI+TBbfZjc6Y+Xrbc2pgR9Dz1KRI/5v/Q6sd7CXy/
1U//M0at9U3tC1DAq7/K80NVKd3FwbVlpXW2K2yzVMPu+u4++XFY7GhTkjk7Ev0+dwjNVd8xrFC5
yJZbPMDvO2m4cjK45Ba7rWOegz8+heNPNQbgfexcLHTUzRXjnHuhbNycoSdj9DhKuOXxGwA+DgAW
DC/l25dsiyN6iYkd/Dfqc2n3zo1dgtMSDynjmMIvN+QQH797rZgYswOsuwKWspd55r0vbq9rHu1s
vNRQkDtIXerXhXF8AZrKI364Bf6luPDGIjQtrPUcdl2VpbC3qSIsul4V0nse3f+PEeB56mxe/jXh
ThVBIgjtH7vOavgCwEuUgoK5XDoR0ceJj7vdiNlAf3SsbgexnDPti1AmupJEymxlbXffMkDXTZKc
DeHHHiS8JnxHpQP6o66hnkx/N8ep74GCJJptcwfWRuvd6Y5Tp9q1ExbJVgNXY8SjpdoLT90HCBKi
7tA+d3SmMrIVubH8+Vjb+t6iE9RJhwsTECyj3VrZwz6hf13o7SDFB1NxGR85i/cmbW0d0XRECdEZ
DNtxwUJGfe618Tpzdhj0d/Z7LVKkigxDXS9DATiCNi8Wr5FSOw9T/vpM9BkanM4uLGvYCVrJfY8f
tj18jKFdHeKta0NhZ2w6Kk4uAQPtb/mocs+e1uhKCe141C3OsmliNFYdXR2MM2BykW1alfBC4OQ1
4aYheBwijAMDuWb1mDh1ymB13Jw1dpULwAu7XJngOhLAp8AYS4TwL9oi8SPzoFL+8Pl5w3eBIzbg
jW/raOsXxigvdKWAkQbqcpaNnlm4a9HCuyh2TOs8AxS3c8aN0Fnwpfoj0PJNAZHnD5gxoWDmd9YI
lKBwLufif3q9TuYObWcMgmhG5sSe89yLgz+Wt9jlrs2o77031bXAWYKma8h9mZi8WZcelykx047g
r0h5ulAqhwHLnxlv0lYapjFh5m8eDzBtE7RvErCOtkBxoO2rWR8WWiKBww9jzTjFUu1b/2oEv175
aIZG+a6cKwU/uL026MRiAVYSsajfyU3MWyZ+01auxmZuiWctzv+8H3a0y6zf/yawsF6rSFdap3fY
x4LuJjF1KknIgjs5xxrIrTcIyAU8njjMPyrkA4taYA4zxCaCnPT/UHiciVuf6HLQl2U9os+OTLSR
PrUTcsH4aAo08T1QqHYdO5QsiHhoGlA2t+ErveRfYL6Ee94iPVO/qMvbPMsuMjExLe/tT/02oRRt
Pc15qjXkAPFKoYqCbjljfNSbAz3ASjXH1t9ET0GvK5ScyYKDkw6NY9lxG7kbHjyEUX9fugPo0ugj
Td4aeV4JlT34cxWCBXx8tgY9fgc7o6v7twkbLG5a3M3rs01M4P2agrOfZh2fIaLPtD5Mvm5wBPKi
cozzI6vcTesSUVGkmrGE3qsRS/gE6zbY6riMuvWYpKZtoqOh90OVek9fBDzGBaRaa5Oht29xEl9w
B2xTBKv7kn7/nNWqj0eHWECQFi61P23EA3VGIBUyIZ1MTPe7FC9wJjEBi0goLMTOnL79eo25HLJp
iDeeOVbaKub/JoVSB3UlLmoHhTFI0HI/JVojlJOmfKRmeZ+xKyXgwFMrQpC5Dt0wJf+Rzu4+pZIt
hZzrqhdni4gbPv1zP271sVbZbJKYfyk727z17c71NOcLQFfZDrGXekWlraDvfG4Qv3uMbKOci8Vm
dEU+37UML/H4ulJk7eGkv8alPIn7qSJoK5UwLasCCgOfmW+Uo/iow+SqFlQy1RzKRkLhjJkI2Tiu
RiMl0ZlxqKe9mg7sqEskWfM1fNgq9TuSbCfC7ivJulrkMP+1kbB8UTyXMhJqpt+kPaHrnF7US5QT
cedEDMUaTY2VkOb4o9KnJrdWji5HLxLxmpVo3VaJpvrT/Jw3E5XICygmUMumtexX2uA6bAtsgJ+y
qRV/ZKcy3arQ457U4f5DabYhPKnMligazzGhIbBgy5oJAilrZ0VmiYmTlrGUM7KozqqLuZjZartV
FwNVGgk1olBsC+1MRguqf7w3I8TZbKffHQExRn+KwEbBIC4oe3E05HBCmNj/ybKbu1WloklwwK3q
CZKa+v2NrCDszEuWQa6PW6l7dL5WHmfJZmPOzjharHPxJ/3fRgLHDEuEzTNPDqmB1kWm4tACSUfa
OG0Y53yflaYlZvJfvywQ8SZi3DiukSaxB1syKUQ+Sm8oENNUHx9q86TsQdXVfrxkyJHpv2N6fYU+
U+aJYoJrzzCCaoeCV+iXg6s2k2J0Mz53RxVL3T5/3NV0DcNDMRR8AyBPXmsaz7udGi1wh0gjBMdf
f9gsJrIZWEIIbsww53kn825e//cNGAdxUpL85B3PG4ZNq/iqmGYHDy9nmiVrT2/XvVUkABgFdj4W
lavSQsdCJrGfN2MPQER5nc9pCEfM8pTYdqWiG/9mkTyph4osOWdl4yzGGn2LnaSCjS8AkLyHHyGR
MzpiJwhNYpXktykRfmNRnLSnvcrPR6FUE1tr+1l22pee626qrkn5dMWI2uIk71TTbT4sF0lqwTNB
4eHvXGkDS0l46HodV7iDmFmu1vUGuo6tlvfFcpPfDfjbau1oDhK0wkf1jCzreug4e/aPuFEjao16
fB8RzBNlch5GWOMnqgy9omRXkYQtozgpkpRcpK91XlESHSvE/M30Ii7x0s+jbE9atm9i1jfITDTa
75rW8a5VaSbblRdHhKg6Pmf0eWokoE/vYndej7K2qLqGo95LtC7uvE4wy7yr2f/JWKFOCTa2TO1y
GyXG3PjgC3AXAj+m5ljFnTBgKPFaLn44TQja+F0dnkR8AXYZOt/cns2YXyXEBt+hiVcr3FExZCt0
Bm3mqkahMHGJNNepK6rSXhk3HxbEHQpAMtOaPbMBA0l+UCqBpB4hqZkthQaeXM6B56qTP9qlOlq8
8AQ/hFKbC2yjiwjC7rr2BagYiPs7FpF3Y6XRN4v6Ysxf3noNZcb0p3II7aE/1fI5PPD55MmHDNd6
bWKL7kk7ph+m+bI86vYoe0CtoChmKhp4+mlFznBTU3f/i/pioT5EbhHYTjdszs9EP9NDjob6ONFB
SyfhiL34LS0dvcAr/aXvic1NST73WWf/TY0T5lmhjSX/4RecGjdyYMwSo+Lg040V2P6VPS0jQdJ8
1Mcy9J2dqoEhaFefHO4v5YXzrLqOkWHrrXqXi43DLc/3F2Hat8zHWj5JYmdySk/Phyl5T7ygPa3A
XdzAB5i06QHbl3ncxSbh8oIzG01QGxFV+x6BvcTWkAiCtE2FkEOmwhcgV+jccIFTkc52rIQbvWwe
4mMQTZivuPKfds0P7aLkGQPspy8AYt4oNvM72fJyRcOWPoibTYJC6/ZOAm4M+lbTWxDG5b7jZZ4t
Di8S9wS2VLpsItIPqn2APmh0FkqfOH830bdcT5/8sDBHrB7pavxtKb3u5LxkmwNSlGpJL/X0v/pW
iq4FvsWpM6+wWV5xlhrGnNxMPW0iyXXQ9xpUbLfXJM10II2RzAtMQbh3/xahDp08i6J4qJE1soee
FqewRoAKeJ3Dm3L7ZjoPYjSVXiZeqo0Is5WKmxqqIuZ5icOpN+5tkle4sy6zdZlvUIJIo8ITeCZc
YSfKHY80i+PV4nLS4EVV6AqMai618sz6G5d4cKEy2sN6Hmd1nG4cd4u07LL5kubiCO0iNUKw6qOB
4w3sJELRnbw1TyRo2eFG8Te0KfctmzGlHyVDb850Xb3kKb32gAzkSNnHyvUQEvTI8Xd3lZkvW7qa
qtFj+fkFSJVVbIIMs5oS8tKBJ+Y6i1H7hMVGKyEdmreIokVy4rBIxsooAPxvAKfDLl/0h5B2IIP2
UQrWImbB2jp01CJF1XogEAPBq4xRijZqcBnESHaPQhe0OMlevslTYPmrvh/uZdUf6wsgrBiJiNS5
H1rrNTHNa5oP/Gm48enOYHF+jpwjiV9AJGgT85q7gOaZVdiLtZzM0d+gI+GxIU29nANUhqQ9oysu
/M4ovtwZizm0oKUb0TM2f6E/3BSfvnKqJ14/WfGMvXXaYnOjMFQxVZeYJAIkE+Od0tXlXsGQSYwI
Juncaihty+yNWHyWqZ8iMyNkPVC3SLShbJdOXdPuSLLu0a6MCZ4vsoavRIzAxNr7jo1HleWpihaC
YIouo7bggQ89klaGqWJX1jhLhp9Iy6rCRCOFLC9kX34HTMumnW9g2B0HBjCjL9+ujl+ZGfYoHmvd
59FrvIXVZMel5kyZqHEsyMoL2lKxhVLSFCxmRcpznFmXAGjP5bAeq+IOxlYXPo1fNIpGk7X5vMkf
gGb+/7Uqs3EPO7KaqxcbDDGTUpVOq19xCqIVT++LhbdZv5w7szwhByC/8XBS52Q7K18TLrTNY5yO
gDm63U5vFW0mDODbzb8AtstVCm9V08mFPSVUudnm3fV/gdurqECCR5rmYlvW00knDDSzlNyk51hF
Y900/x/apFJXZPdmcSLntI4Z8TJD825vsi15gocW0C80PtwF1MstRjfvGgmVPZZxHgk0EaZXebFZ
pf47VzYGtjp+B7H0OkJ3BUy6h9CeJdmG0sTjA40f6RWfz/M1U7vr9FTgFQzmq8Ewq5GFUbnX+brQ
mBtJDgdc3lGFLdDA3+NHPxX6D5EN41R4PIN3/5S3D3N3QDQoNNYjXsejoVi8fDOCWAFF6LfbTLNK
7/y2IsJwq8Q+3b+dKAVRCw0jFKlr9VzpSxV4wLk+TGbBYMWatPvxe0W/FOL5F8Ce1hVSkq1RQBs8
ZFmLagjU+c5M9+evwlbOw6t6rK4svvvEgLZTH5qCD36+2lxc0g+Cpa4DzRdfB8AXQIfROT5ZLWh+
bNiqLUv57dQ3/kmy2eWYMr59yrq7JFvW7rfPJc/7GT8R8b6yt0De78LunuBWnzQOOytwDZ+NXCOk
htXvHn5n+c4VhgWpcLk4iWRugrU/I3M5yzJaGzbcrOsSrOSEpjCFSw/WHIX3Uo1Guy23wSqHFDrt
XR1lGfZyLhvNfQg/Hf68RPn4nVXu6issKPa2pXkLlFjlquUd3EBg//V2udxseHrd2b+veJJ6pxFe
uC/1XLWUL7DFAXv0Mv5txISXlth91+3QaLtlyrDjqOiautPZvv4R/Oxp+bqSB7KDh00jqsSSCfeU
Q/NRVfVYRdXoNM+WvxUcc4FOKgSEQWMUx9lOKA9pj1F77A5b90a600dQtLJDESDxxbjAAtVaFmod
kzQDERlk26dRAK/LnsmeVh4X0+n9r6nN3XmltvQRB22ih01O7I/VHY8XiP8RzD2toywqyqfcPtdz
PbI0TfS8GufTKcP2przhEBd76Ao7qDxUjo2SDnjy+hVmhoOblmQs12IBhN9DJL6wi+5TjqfgrXzc
BTCtqayryRybWUDdqKqBipg7dcVjycaOvepoAQddXRNRNH4L8sNFCQuTk+Ry629EZ+SeKmJPNfUg
JUQnCPKow+n95WQKz/dYFM8T9nmj5Uvz2WYSNilupuKEKkj2H45y9//UGW0IAtAMxLyx/6L3/YAY
7L0Wo/k8Vr3U+5HwmtUJk+/tDJ3Oas8q4XTZLQF/wiLF4crSvvFP5pWIXarHw2r7g1WJ9gcGnwNk
ezy2bgn3daMyjROJp2H3tDDCAJsMvP5oXDE1kPPIU5iV+sxVZfWZs4vMRN9nuHS9wRz66vTfSt04
Y8waNHhPs13iLd+NSbQOITYqJ0j0Efv3sB8WPT18GvdbrSvoA1mTv2XobvUhey22hM/Nx73m+w/6
636l4vy9a21i9G402+8Tu0abBO+9AwTzbeuWvalRfZYuMFISDrA9/GrIHLft/GuGhby87/KKoNQn
TE1+e1oLRWzdrnX2np8oElx5mZzVlaPW3rYdirSGb3pQcbdXBx/0U6ZpT5of6zLX8bsbuiThnPSS
Fb96u+4TpWf+4kIGELpqVAsNSpPPU7Z+AaSXNdS+AD9xtk/+KjsROBJ4lf1zoPfjY2S/OCem1o4d
nlbO1M0hJzx0PTXwIL41sv5+SSybCyRlMmU87bz6xCsNEtSQeu7Hnhz+OJDW9voCWEHSuBOcqI9x
Ggmt8xIdBHzALSGpt5PnyU/PtYP9LcCrsB/FcajLGS0LPBNDF6hOJQ+vCNFc0jpRKeuTQesEVvse
KEKZp8rYnIxaDEzW7OL8pqmboMvTHOf8OhkxfGvaPVpEe7iDx5GF/InEokSpjTj2BToJq6YLUlqa
4iwRJuu1skuyFPUfOCnKsnI/56NklGgg9kp0jLDJooykQHvOP+cvpyDr50eyp2TIy+EqtfDQsGKa
hdOlVKIhIOs4+YAQdCKAql/JOu+NtA+cc6Ujb74Vk8QiZv0PhHvtq84dII2f0YkaIWZ8rFTZB1nN
5IcdJkWUsbKQzHTJk9ikqFLkpufifyyWsEbo6EwdFgcdFrXEPWyMfeqNKsD4DNDf/hNTnEYjdFwA
ZSPScmYdNtozcURndpUROZKJZorfpWZrksm6BLDpU44kIaOVwT4uAXzjec11bS70ZHuNmY30+PY8
8xoMVjNFUXTyIRxhuVJWEEV5ILDPbCtpFo7LftS8ymjW3ya9rLVQ9mF3USuLC1b9k3sKGGCEPHmf
VOFQEqpgRNlLfJZnmkZO9KWsSghGN/+0EZ0xjq/yAeas6iKCPDnhiupurgR2/SIDYYhv6ESTEw8R
u95BPVtcKlF31zOGXaR29qyyR1hcsBhIzOt+nG8kbdSZoF6vzlj32TPR1twd9+BuQirCxHWRdkTc
uaWFW6Wpip41/jrwnecRKMvIt+dmKW6hzmPC/sfvLHXg2HmPIJIZnSxKSqA0hNX+PCdwvkjfuwZ0
SWrqznh0mWD5z3VxGfadvCNu4yPz1fLa43HEpvjUs9DTW7GVZ4ZnphQ/ll11pNXa3SeISmOjeowX
j/N7xCNcbGhqY701eYxD/6mWpoYmC482emK8iBf1qdKkPR3EET3Sw2aWPEu7jGzYlKfB9240L5c3
14IAHnuVPtZXqClnZLQpWYz/SC2Dc+cXoAP+U41iSNGvUt7TtcfEDCyxJbWDf/Zbm03G7S4UxX4X
1jZsBMvJeb7tIfRvJ0LCF2BTMIBuI14+iwJGaw3iAAe3vM6pg+8feJrA9lz/NgO55QQ3MTOj1kmQ
tzagn3sSebqsZqKw2Ci7nm1rrcreWKDhSi01MSA6qfj2VDseshgHw5733VV8Q2a7cO5kp3+PwMMl
0y75NFiL7/x62SxO+S3ZdaaM21W7VVNlpD9Jk0E4AjPx3/LvdNUJl4tpP62Dz2a2imipR6qWMHmT
PRI6ctMn+TGnHonLdlzO/JIXln++ym1ahWlS15RoV+rCTPevmt+e3j5CvOftRli7Ht7PcJsJKgYH
CSbju8Yy1x9/OMuC1ws1BKEG2U+fwbWFLsvOpLqoHX1of/l2fLJWVty6BU7TRRkLNO7mRTTxJt2H
vX9xN/WNSG0mdmCg0Fku1+WgLbSP9b90qnXEPqCoWWYM2U0UQMSPCjzWXvd5Sr5x6wbD/SWNKcox
j5whfhwqEujMVF5l3qIrCXwkL+UDX9lyMyI2Yq444r0uVqKMtSJ35hrQHEXgyY9OEf+tYx77AliC
O/1kJuAFLKFdRPJkOYQ71zNW0Rfmux7rHH5fC+oPtU+/v689TsllPT4kMwBdLvncElrp/y0c1xOP
U4eBqO5hn9xMvXK9ZiZbO141CMEW0SW6WmnN989psLF/YfzEnU73gEoHnJN53R8+8wEDov7VIPlR
A+/3JkWwZH1cvNgCx9t6t6Ff7zhCeiyuKdRC1PG7KFcmbfiFxhEMrF0wrgHPlHrL8nXNljRZaqvs
88xzeOFTFabcfXti/zjvU6XDrnPuFwD/wk3XqvRmupBplNJBlcKy9bcbTy2/h9ewrbat5rKHi84v
Z6R8L9Na6+FVZD+UdUVf7V8tJ8/xNJC2KR4R8VfIbXBbB8uSEcZBBI2J69lGsBvTos+qpy+LHllT
m1GNkszfWu3NNQnCf2Ofqzs+IuZKmDIO5Zm6Tc/yvAsPVI5rWdXmSi53fmgP9WDOQzGxDDlAFTzX
CW6e0Ht3KfoyJq2xxE8YBFuS35bkBfEHQH8BzIeA2E3VCrPC4BLzDxjbmWaaJm++0bF7ElySS+Il
pkTgTIksRX0Vxpla2GmwkngFm95HuZXFhq716YxNvlW6KMfIqp5g6cyEtq41LJFI7cgJuZcBr1r3
4EfBVZLoGGytUOq4ZCWbXnNfHNuoAPoIqk2z+x5/dbSxbSPPHnTLIi50Vp0VsJ7StKTbq+zGDaGh
xHJa4A8s1L/4ZVANOjTx99iSO0/vgA6DZELL49cVwi3q3Ie58o+s9UlCh/UZ4eWS5lvB4Rqc8YNR
0ma7geN/NrzzJ+xtzR1NDS3LFh3NGvFvauQjUazBI7Yamxd1lzXEuL+4Yr+dwv8pldiwXPRZSROO
ZKZuaQttnOTYtk4ACN0IdTurrv0b+JyGDpS5FHdig91McKErViHnumKo6d3F0eM66QV9erPemwrC
+vztmHWzYtg6LG9XjQGPhk7mO3kPW8ajy6TRmjfIWQvnPvJOw1UydWkTbe1TpnyL8YXR2uUZUXOD
ieQYrpzipuwp6+ymG4F/J2HOUCe4pI9knTnW+67xblsQbJiGzPwm8GNVT+jzBUvCWTfwBHIa7rdm
uTj+iEjjpDkWzMCrZ428xdVwWWurpjTT/HVSZSh871XWhCGuxRP4UyrZD0SsBN72MsXjjAMnjQc8
DeS85Bkr+dxn9XghE63EMg9HmkW5B7BhazMOyfw8QM0uJpy34ru4P+ErGaFR06HsGI1I/xfQBXcl
1Fbrcz9crHQv1+Hebp08eS89rgQDRdt3gFBd5hXodsn2OW4cJd5+Tc7C+zjC+37mVyLaRK6ao7fR
1YbYdoy4cFP1M590EnMhLy8lNdvTDFCuKs73B0s1lEXtjxJUWomOSVSqOAtxMxsjK04poRJ0sVVB
x6saxYKnCozUjByzfDFMbgjTvmyWnOrAQn2k8bkOK9NtVKkjptSumoutzbZUR9KW9s8E8vNrTdwT
sUTJi9O8ouzDgW4tlWYQcHU+wHIiIGR2Vo97nVk5y1ZP90HrVqU2l/QT80Utf43tC+D5UD5BFjzN
z6jpG3yqI18mxRdV+/TNZy81zAIUq8zebOCl7rvkqYaVgY2XVWy3lNxS6ALKQEOzHs+ZlZrihaPK
8aSSAEbjL7qs08XlowmXWk+CqOjdG9JV87velpKddVrzfy/Ljx81ZDbS4bOLltRkTHAoi1vYkBZz
gMAA2km5YcFvatBPnKD3ADpwpC2mwtt2qpsSk20tAa6s835UKoAjlFY5XFT+z+gfbpnYH/3VtlKw
U1ImkvDVyrq13iUxUZm4FhnNdHq6SNyzy/FB+xFa5453LwOE4h8XX4Am7ef7kJ+wPoNBT7a0ngPD
iif+RcXZKkWxsT+2y0rIW5G0eq8l33iPPZs9wO1qkZoKq8YbZQH0nz5mlp77Bt7W1VuiAk0Sb2aZ
Mu2jSj57oIdNiSPcA60SAjNhnp2DT8GzZLwTnaF1o9a7923eAj17atznapzvkbYlAw6YXtYeOU/8
HSukXwB4lPIGURqP2IILvNFSNXuTy4I7HcUErh1BFOsT9akAYgAzqdv+s43k4bDmUiLJYIcaMJ7j
2LOWnlxlqbyXFbTxYoPl902zfbGsS01yZBFXnejbdyieMIq9zhmEtRIfen0zcd5sgoa2S5h2XGjb
SYRlRYyPpLE1kT+kvBR3roqymIvzt/IhXK6DHF4bt9XsppXnWUu3HIU1DPm4zHa9mZBt65sW+lJk
4+/wID8630uXvTu4H0aFP0SKFy+vJUU3iYgTzJIHO4JaxCTY/7gOm6ydtjRZJ21Pte3tW4uq17xL
O5s7CpBCMZwHiVuCvYL2xilCyMYJwylR5RalU2In4+HWuQqhfdfIfBUFKgg/Npf+2qCfZhjbJTME
tuw2DtbSPfQwLeYdMmnFjuVpERoV7sM0OTwGCAp7Qiu1fBymt0+LS3YIKoQJfytZZk93xv7Ltfcz
5GY9/NZ3oQvK0tzpNSOL5SrNjvcEttlMet+2sC0lpivxxaXVA3dYae63mFAyxTUuEvWLtuIzu6SA
L06sPftgC3irQbDG0kwGyC3gNkMiw2mIbD37Uwd8qGOWImHfCqmgwK5OdiuQYENiF4YV/2yOB3sL
da68bXs7AREF5jm4504bpYj3qS7MDYsvGC095TtMRrP0NU84hv5BLsCtc8+tRPSy7wzZMfNPvmSo
xkjDuhBdSnpEBLdWQQI5CdBv4nz6BTircIkgMCCZTdbyfp4wlSK/x73ckHogYZt9Fcr1ZEDX1mMb
Z8iGSxPyL6B1nKg6AT908I9NRO2pr57p4pHo4ad2/UqYQlpOS1gHOfbytx4cr9jM63UGdn8B4Nzb
3txoea0vTLa+AMwTUnic3/JDhFasrd0swa0ophASUo43JcRc+iuqjA3sW5KHY+s9yokxC3bvJox2
QEbizRydaXOkcrwZnr18TqGBJnJFJO51B3sDc8WmP1rPRgEdglZCeNoOl0DG2l+xdGn8YQs4fAcq
sns8DpzwdUgKQSIFdK308a4q3FEFUZ9bV3BwVqLQrVtGkryjWC+FRg1Yn+hWO+2ZTL+C1lrGA2Pw
Z2cvdpMHsmpi8UGJY5CshIGX6vnDOCPLTzTF5ratW8PxeOcxaj6aET9A8452xFSMTi6E6IGqbgND
fJ6hB4v2QsvmahLJJh+2zJoLCqlu9pM1GYAr1cQphzXb5ZtT2/JpCnDjd2T0/uPl+mbdCKZaxD5C
KgDBtPSoT/mkcVEpCPLMau+0+89+HVVH9jXUjDnS9fGQHE1dff2GmOujgCazKZvupjj5x5KRgmCs
Wx7lSsESlba9XORb6U82STrWXzr1wYNgo7wZldREClbmW2JVohGbuPyCqcqSRgmnhjy/qi9A2OOk
INfAJ0GKR9KOsRQeSSw+TrdtGXhbjOt6u3K9Ffjr0jn18Kb0QlPaBmbv9qUwXD6vrGixS9C5TFdc
IAZhMreNOHVJbC+j1hEbuM8g3NQVnBxD6DvvNeEVF19SdrB50GCEi9H+WH51F3E/68XZabsbfR4B
PECJYupdLHYPGKiXcOIZozhO1AeWR7jddDA0gqqpsjo9UGLjdt7mpQX7HMO7eAl6GijBDrYUL8Ww
EBnuJHKavBXRlplZ39aJnWDLm91xeiiayA28zcz4ohJxlcdeE180cQzxiI/KNxVNOtBTwYPOENIj
tpWLDwSIAahrW4NpaRKD3JVTLmvIf7zxYLPOa5sZufYH67XhMy0iny9HiXygdColhpLkd4UbTpWk
WhRdOQfC7kX7RCTNz/V8i2MnJDZrJOCOo66NbsWjx8s35SmiGApXTYhIoAifjrfaLlXO8K7KskhD
Etf+PFE12XwniiWBs8Z5BX4B1sr012IjhL4AMk11Jx5gfRD6JeTDWP9igKuAmgHaEuPDlNglWwvk
SB+qimSdTNMekcmKWhi1XvY2a3S7cH9+SgDdHEfwz7TS0mh7dsXsCfoj17Y8glN9AQPshUPQQvZY
ovxwtdwzfxgZHftCZU2urXJz5xxolTyFI20nTM6FXdfJK1kubnncYPfW3uyWQ4Qkc2wnbkNtZhwm
PFuvQrsEqsA0frqo+mbU1tWZNU8MY3dNy5N3NwC/SAQ6cIEzd2g25UyEdrWMHqH5R1lFeeBPtKIy
nRiETJwMTGqOLwCd2BzuB0QlqRKyg8455BZnjESx1YgTb3FqYAjDFUkg5hdgmwo4vHspY9jp8AWI
GLbj6vKpwHtFkLxFXiOh3z9x1ig+IIPrwqvm2TCJleyKfu9YiviN7jP1th4tpdljNukPVari53Cb
nZlPch3weAa7aBmwT31LVbUlarJ5HPY5+Hy1Y/GgYIMLOlfcb3+HXCQoSa7GfKwsCoy3waCSW2zS
p1tb+pOmScTvn9rBeRAHFsUuMz0ZynuMLj1NGmdrkOh74lxhisdYlSWwV/kCcAuol9WYW7rG2MtL
UxoZ2HRl1XTjcGKXvaqMSDF0+UYFPvwL6Am+rTTHK1fpvBB5Zfz5mvpf1Uwrv8OufNJVf1ug5Cxc
GH1v1QEMpd1dvo4tKW+ZLq0uHySuoSQBlbMvBouD/6k1ZCoYFNgv+UuTXk5peCrKpH1TQWYNrFwb
Lf01TfttTKr8R38xx78Xjv12Ns6HJ+EJ0BGeTKFR8Yv6yzRGh8aIvoL/yftIo4PilM6Kodey/IzO
SGEVvQo+LbLJiEppCVZZwYZ1SWlJJaC8sEw1qZYgmdxUHs9xooMHBnzkdsrVI5Q6W9OGvYYcQ9ku
EK8e0q+TzfAo106VEhYbcXBP5/XdFX8kzEJMY697dY2sBNky2miKAoAhfRpV85riAABkRWztKkDg
PReYy74gSg3WU4EEqEsGq/T/Whzxe+n87N0SDDWTe4vkqX6Faf5IFIjRpGXzdjyPVxYfibyotf+x
qDcDibuRog4VMgMI1Feer3mQ9Uwt1p5aRvpR99r1zDkONjgdr+QcagAlIDVS+202Xeom/CujB+Xx
L1qKfRZbHQp+U/GBWJG1tLYuF3VhLDK3amJS5CVvVp1/sOdXWjjITJGYooUbenjAlnFEs/ZsWZ7l
N6j6meEOda0utkfA43Zas4dhNkHMHsQCa3otBYT16pVpXcCBwHgUbfsCeL0u6eayYZboGIx0st/V
P5Z5BeuGq4UtqXqc7CO8PGITTbdjWjut/oKHHzc9VywAsTmPA6uJ6L7fLE3NEZTK1iAtw2a5Zq3O
N7ddFvrqhlg2pYno0R4LNUtXw526MaOsjluWCTQcHt1vrjf5+Ku7/bOUUWxhdRbIk+2o9d9R8vkC
hBqvew0sgz/BFNL+g5ATUahb0DGWnIqyt5Rd3z2naH/LO9yGjWr4aIrT47NapfGF2LpiALuBre+/
kQ6zifN1Dur2mrt7ae1u1/qP7DWTy4RHOnh+i1lbJa7rwlhRjIIRURQJH2t9VX1RWw+VwbM89iUu
Ei4ir2otGmGC72RbKlHrfZ8MB/iVWZ0VAmxyIxARX4AQH4Ri7cAN3ZMs9n6kN6SnMhazFDRLyVHh
TsId/D4+qI1I6mZJX2dacYdw3h0SH/D8IzLkiK63yp64Ir39cCc90VSck496Ngm69bmjs20+Jf6F
XAjSoZgZEgIJrdThwSzTfpuufba5Q4QiVZojsg26xHwjUYXT6Fv5Vkc7p6285LCPWz2riRa9v7rv
UFYIjgYYmOlinnfynzxopAWfFEcrItqo0NDj54weIeWY+0kCRWHDHWuVN5XIqu0nfxe0FiX3c57K
u+NkOhZtyvVBL6zpCjjsl7rWAde2raNtKNDYtl4Kszscpuj7Hf4cbA+ujDs/OTKA2jZbF31Vtrxc
XsfJvMkG2vsFjAgfqDolVkDPt9ilM1nQrLoh3qh0ug70KSuc3uVtWbhXYuuZeClI+3muUyqHiOnu
wjAERFTgR0uC0m/ZRwRO/AgjrXPuBIE9NGZW4wNtbzV+kef64tPA8jMf5BxmJzJfM7+54zSeS42C
lcLPsfrWlt4gsBTqXwoiwdtz6bsnZO2RwZJNaY+WHtXrsY22A6T7fJn5W4tgnFDGLmf3JE7TaW+y
FlCuwxrl0vvpvvUhSUfb+p/9HmSl29pK64qPKC1CVjU146ti6E83bgI7eqFjkth2Bv6lk4fzSpP7
pO+0MVdQrUDl6ZsvAJeQceD2TZ1a0/KDV4EXWRo64mkQGwFBSL+/3aurNE3MzgMRm73GLanW2oIT
Sp+TUFnZ4oNm2NMTeE3HsPGgDYoC4lyfK7xiDazFgDZJqFpW3qOa8z3as24+aV+/tfUWpeDENAlx
rKsl0dfMJHwCabe4Mc+MbZSAjXZQSEjJD9Gt0lCxM0qYc9dc8dpo/752nvdBn2r7TXj6O7reBkU6
Moka3jTqfN2557KlZDco8nKdVAcJPeGP2+ts0hX5DOmCQ9kggwqLY+cfp21Fw4FEOwczCgamdQUU
CB6hsG5EyUWO2zIreIoGhsSJTwupMeJHpNZlFbANy7osgsLKUHFQdYLflJBUT4XVHsb863e4iNt2
QhpoVhIFUKvTNvTUxNj3Mj1CTcuCLUnbKu51pp0sxYaE2LsEggWhZpRin9pl1q3uujXwMVOFp9Dm
pjSWi2TbAyvjb5Z7qxX8SJcyHADVPDfUhkX7IfIRs5PrCH/UI5GkarM9vVprnNWfCRBcSUAVVGtv
s3dUbt3DUaQEnKKprthsybLAseedUav+PM/ljEy1ZxmImxmaYqq1UMFF0Ku2fGCFdXD3ww3PJE4y
/tnmoqDhCTZZrQvTHckn9lzvgsHu4O454bs3oXvNZgckr7c90w/yqdjimf8durFIk5WN2MfATqD9
YWk9KvSvFnzn2OIXRnDriN2bP5MetO664nSq+ejRiI99gI4bGbeD22PcaYQtA18dGscmjGogXcZV
GHxYeRo89ljTD11bUMVKXEAy0enH91gnQPdE65Io04pHmgF1+IrQWviRyHEOt1nwl3stIal9RFFv
tqgz5v7fZTmDEvkVkSbhp761WZBXBn1xNbeIWpBtzzxywS1X2dVNxl8GU14CT9cYNXyPOke/GpH0
hgHywG3kwBlqPI4NTWdCWbDeT+wSDXWHA0LUulLqNSat74hU/e+6uo7HMZque4ISR7a+GUnzayb3
fzQ3SvYFTIkXP5Jkyy2flcZahjBK/f/uoACIPE0fK1YlIbDYxmSKQCFICQV5gl6XyoRHoIfVLW0H
j62P8MkWCyYezNf+f8vOZ/4gEPYQ1itNgVioFDKLal/Zn0SbIZMCUQ1TrCHdUBdxuwEGSOTztGtt
dEYFUlO1b0/2vIqvXYsWe6MgOv9m+V2bmPVmCFexS5zugv+Kf1+vB9x/FKrwsPlHzFHu0JqfltwL
GHa+Mx/pNO0aLk1qMN9nz87kJdTHIxQ13SpV0ZR+MyuIwyCq+OSb6b+wuXKQSebE/Sh2s7ZO90tj
SEvfzo24WXZ74TGbrsImor9F1aQlz1UA33a2RgvRD07p5mj/G/zlg4wysKGPqU77ha3V2VPv/bVS
T7MDny6CiPG43eByVRfjtS7b2dhxBJa6tGPKF2CSs9LIHMSo1IjfzTjruAt1qk7saCMFh4f8S6XM
ml2ZffYCymMhAc26x1yIPK2ILG1kOv8Tu9RJSKbcqJgkVbvdBKeDD89QFfJ/lIVJ9wgoG99lS7V/
rYFp0fCDI0VZG6kMGSsorWCRFhkmW+5b+f/O5qFyFLexq/RLvC8feWEHmqz6bOrdZp2FjTA7E1n/
gVBtvFVf3VlC2B9hVxg4KtiU7iltSO8RoQ0TVe8asB7kGKII5+RKL5Wv1mfsEvS2EIriywocoXfs
B8f2ZFe+JOfQj8wdz7bKIJA2zds7cDI3RCc03EEDN/+cvtzqahAT0DHlHb5HAF+kcZ1J8V40z4dN
xUq7p4FP4pmYR8xHx1BWgrag7s7WlQJ8+65YAi1q/mnoN5FvvYPnakDjVTsh/BYt0tzaqNIt59Ad
P3m15ptsQ8bFBLm6g3aAaVptiPegxALQ+E62RX0y9QXGZ0mWdjq+3LAiU+AwmRz22o/Wb7BhypaY
JFkmCM/c7qV3ME7zzKbTqtRu+Y4bQ8KLIgD+gXP238g/Q+s0NgeVi14WolhV2Yya39xEXX977Gq1
1Vycr08VCy5cSqLEOfEc5KkUbYLwyO+sRZ6qbmVblLsIPbFrHYHaLGkZwtf4MMqkIpWXbpO5xi0j
XKFnFyKiF7oFVbWK/rzXw+55BHlgZhSbAb+aPccOKQ3eK/6set7qXBhf2wz7knPagY67cqHwwne6
x+ugWvvizJBx0lAxtsA4uNpopTxa+98covFeOQ6AmKrjf93C+MB9IhstJsrWyPRJdxK2/aN3SR2D
aeZK6Zyy5N1xdy8HC2nTGN279cCjovrZK8eu5Z8YuHHEGm9FHQEwkHbuU6tKs7GdbcgPpXMl2hz6
soo/oY926g2EjATZtSdo3RkJH4djXpEa9CSdscKrGo32X5f4u3/6vvwez/7r4u3ok6+0UAskl2YS
0v/47iH1GnOrXfln5+0LoCOd4tERHy6g7M3ZnXP9VPpLJDb4UCQcj6A7HFvCENLGWXdKSHmZFsFY
lCJhdUfTssYrzlffZGCArQ6pUTdpEDmw2TWNEKEJeDZvzcXtss7i+b3RedD8d9cxVLN+Ud+97BcA
edu60mFhTxiUQ3oc8wXwKVgSYPcua24cu514xgWTC2+d6odHc8JzCpJI5P3Ms5VPKoj5FCslpjTG
KS9s0K/AwFDEvRxtKB8nQBhl/QLA6e9Y/Jw8onP8z0fTs+SpdRC3yk24UUsIQHi8W++SDuCCiKzR
FvsCoG6e8FueGshXYGtv2+Q/1gg6z/hE/2KaGPxLAbEVifHLqJZFUebsnbJ09PfKdwyeNRsoby3o
8X/4p3UPfnSOaKfxIXG0xSq3OXQwUP+a5rND7PDz9A87gv7WwNai0IlP8xyf6tc2tm6Z/w0wiax5
fo9TVoVTxBVUJII71+nIcbRhKFwAvXmb+LIYIqDoMfNnW68/2qkoiRPbdYYDpULHvwCY8cf6V9GW
5va7z91561O515m/m0Uugnn6iVPVY2OyVjI40hAP3mdbNoJgt0cVf7tXHUQQWmj5zHuHt3OCbTUU
VIZ7JmLiuUTF79bShc8Itpu1l2pCwGb3OmsSgSJiBEwUrfsVAXvvdIRozTzCLHM5C0LdttVzD2/6
qr/ScJVRihqD4N+GBSHOldhTkWS/4W14EbpXp6dx43z7deBgjgTgbyMXrC67/VabXy5ZpjOKnw0y
exONcaQ4TvA4LpXdO6fZXQLdYIWkGr/ItKA45/h8Yut1YFq6RjBTTf3j93P94Fu8XdOfhM81peI8
+wj1zCOLl5jPOxo7LfjeqpLkwws4wLdImKIOKtcq0Kb8bvQNikHyuWElypppX+AL8Jcsi2jwdztM
pz2BeHO+VEuelOfUB6herm0Sesb59FqGA678lqks8RvOE50ZWLOO6PvKTfkEeSzbmARR9i0VcNLc
3RJyo809zgA7XgL4BSA4TVuONuWsJ59qmYwxPao2IFfZwpr91IB22JCnRnTHtyQlypkfphxATRR6
eagQGJnmJnk760TGGba4aWlg2vxbw5UAL1xuY4iqs8aZNtMAT0n94Vponv2R88SRKszalKiZXBug
o3Q1tZI/0jFJRGTR1Z0ywGgCGvnXcpD/LM4/BHavzQauvsD16EVjsggE51hyfPzH07Lbwq7WrTK1
2SAImsaEUvzyDvqfYkjo+T0P9j1L3b8A6Op5dzhaP0cPSe8BfcLMh2q7oM1dEp7KmXUtB7wR1hc1
UKhp4rf4W2fp+JHOc33icdLZ7xcDii0x0wd+MzdlulYt3zh3MKNhJ97uwXG/yENLITtIsK3nrJ9Z
an6hU8AdE0VCRfUNM4ZA5n3jUAvKwBihWzQpkGlGq5ISXzcfB0YYx9RxZtplcgIJoet0PNDJtPs+
9BCIByDmxQt02D3LmrNRHi6+aTMqEcNxoq71VYdthvtYJgxk/bTTVUcYvKmTmZfiStyf79qj+LFS
cCInX6SaNuTOacut3iqbgQePJ8iuox64x1PqxT0ik/og1Jy1UeaqalUjKMyqZjaXX191N+mZ37N/
y6lfy7TyqSN8ZNP/XbjBXLAKj0Ma1qbkOT3/fml0Xzn7bfvl4iGwURrUqrD005bLoJl+azOvEVOd
oiPjkbekL/Lydqu6S51++qgaBJQSw2NVblzInPo1bQ3Ipr2N4RTvWkzk0kKoiJL4zPv3Qbe5gJyq
MMHekuvehrBemLQx0vY2pa2anwU6FsiayP9fr64ImVfJsrdQ1oiiqeAgEGekBGBVL2criE3xXFEZ
NpJ065xoNrs+xd4vb9gn0FcR4EmBtj0qJpeBlpyEiUG0nQjDDvI/zjXQRWAKyI8qaVGVVQOVi5Zi
e5ms0DVMlZiOnL7zx8u5v9NZV9v2paU9+3x0KLZaSWs5nHYxT0ozSlhQpt5tMBib32e6fM99UzyP
mm0I+jcxji97hNrdyv+HyDUqae/palvXO9kzKylVNM4JhSvwVL/rjJFju1m3qKzcmeRVp3BjDuZg
V9wau8CdBQiSVxFHIUu3JYTqBOTPADXyZXqZf6BPyBkG1E0+1s7Pq/0nfP03j6yDa8IJpJF7BYfx
sderbFT16Hu+JwxW7aWPVRP7Olt7Y8lSRJwTONX44JdTNk8UJKa+t5yMXuUX1onc/m65t0rD+NWp
1vDDtHzltkafNW1/QHPEzv/s/Fm890lH0SSpfewo3dlAlPxUjbJ9kNBnAXltWOY/MWaWn0+R87pU
4npmS0l1jwvpcb+ysNUsNGh9GORu1WrKL949epjF1BkcSb/vSP1Y5Xu43cJ2LBjOKdcwTrC6z8O7
sw/uNIQA68oTfWy0bUMHdFoQpCrWCtoUO+xWTnGk+6YJCN336RGN3pRvaBkWOWbhqfnUc27YprF0
8cEUZCNOCfgbK8Qmwb+Pc5oOd5SW5Tjad7V6tkXYwV6VtwmB+NmK4vmamhbruD8SqRMk2N7YQ4nL
s+xoveZTYs2secf0juPaa3v7XFqTgWTBXwDitf26XQ0BfkLZQlt2Y/n/pLTwb+ZWn6nRvyXOmrI+
bW8yE8WtmfkLnGqY60CrM80Vz6hIGpPE5OY4W6ZSRhmO+Rkdx1yjLgHUbLvMp6N4ao0UPjYDLtRp
lgOkxw3hkc5e5PP01g6cdlf2PS+VH9mSm0oos7D1lQKcFd1X2cDNjYZ4hHYwmyhsEuCxr7rxhHx6
yOePe7RZaTg9HnJbQEf5q9oKtZoZiZX0U50Y1QXUFwCytmdGo2WxS7U0AvYVtDpUy21P2AA0xIJT
leiCz+zdM/Lk4o1fJZH5na4bOsPKF3tC4L/AtJWx5aOuen987bqcT7bzpqlYdIqvvxnocs24Kszx
I5Q/YHWazZrGO3B6za+R29T+6GqUjEV6tA2raVtfZvBv4iSzXHKifl0wsEjf5ZUTqYEx+r1uEIX/
bZGvN4QcZsKWi8nhyPxuxsHKydg1KVm9K5VLcDB1hOs4jk6KuZnBhJaaVPLmisdwsNktqy54p2Xe
rDNO7GiQJnblx25k/z4RfcCgEHHLvMaB3GF5vpw3V34Hdrjd8zACahuV96IP8LLemHC6ME4K7/xc
OcB6E+/3teD7zDWGqz4DPnLivKFKuzfXy6cKGVHbMdDwv7RgWt3eXC+pUXe75pU6k2Vyfqx08pvg
OW2OldhV19kdE2v3fitfVC1ZfqQlZ22eTBGUrHzkbNvCYDlNf/Y03/XCpaPaKnhdoetDechKgig5
OFiKtj29yJGGjiWIi6Er12Gx+aWd9LSn3fWUGpM5fe2Ttq/R02UF9t7SiCbWdqiOlylt7kY91NSU
6zRHPmhB9add/bl1lu65Q5CpowIDYbqqyvAoO4ltHuRNrnFWNQqTZZ9hhubCF6MmgUFrw3bZ0upn
R4H+d0dqPXvjdWF/+RE64y8Tgbd+yWu8mPaW2CPu6HL6JJ3Uw8Opuse381yVs1t1y4SxKpeCp5lS
vn2trvYWWW1zRgS/xX3ICpPYsnJlnEv37HUaipYolQbZ5/TlXMdaQx3qdKRSTd7R3ooqf2Xy1kOp
Bp9Pdev6hkLizgrHxPejzR+D+deoPuYjhYKT5DKHUX7zvuqCbeVG8ybMeuff0yMwvHXElQCws27l
TA2+T4YNkVKtsEKGuFOWezkQJTBDfB8PrAwmJj+d2kc0T9X3l2qLMKvGnJ1cqd/UZa3JUtHqp4WF
hGVMGPQ3J72OpHVdiR8NsfbairH+iNCei2AdYs0xZLFqkmJrsGoaES4VcFxqtPyIzdDQrzjQtC7S
luTewqtuDjFncKCxKhGsbv6caia5+6uqkO0QEFQOFse4cgIixhUV/ohb2uyJd9iMqHm7RMHdZ2rf
q1RgW9XJKSBcTq1tdrboVMW9QNZMQi5L5Hi54vY25ZdQrK8+pDr66OmliELccYGAarFa5hSmsSdh
YztYVvPR3+wysC0zFbz/lBcskwaGMMC4Dnq+qhwgZrqccR28z6khe5p9qIdacUXNx44H/4uqpgrm
+wJAVFoVNfD5BhALFRUk8ZM/W+j87hAY/KdT+b+tApVFfWxWO0QUqg9VGDXuHGkOec0Kak42Wugd
jCInoGNUJRYbEaSgQjOso01lVk4ytFI+ykGEiIbKQl5jdRzaC0etMZH3ypVaVoUmddZ4nbAHI40Z
U4pm1vL/GmLO+1KpsM9kNtB1bA39KDtLRyYwtRKZkbSSCyNhfh5fDCNVkSOlKESMSbdnGeh1pYkd
kqNe4k//C0xarKcf5aoPSc/ASXDWPmz6Sy9GFbrYwybtlXvJNZy28ikUMmdlstWBnvpvsTuTUYN9
6Xi5rv6kNd0kJpa7ALra83JdOGi35sxj2byFIfaeuyhOXmWRQeu/pAzy6Iy6ubgvGiGw6r+8R3m0
WB/+Xq836VaDOJ67BqgTrLfmNLU0Bdq/sfllgRUZi78AeYGKDFvHQDfpYuu025auMYqFQxWy5v6+
hLjPJRmm9caYw9vlUnxJNCnIkfVFDsCdok7VJ8Pi9iVeJuRGQA0AIr+81B1sH5s7Ex56AmrCYDhI
S0AxJRlU9nIYlFy2WDzMA/PsqUGIvFUoahCn6E6lJY7qe4XdXS0x6gVj+QFIlitngJuCHeBrRIz/
am6M5fm5/kqkAH+5dQehCjjEZD5Him/nqUaQXLZ56UF3xWpA0XYs0af+mZNNxwEWa5QqQ553BDde
TDlruIAoy4kTP2gUKlkzXaabvnMs3bF2IYqhr5YAu7zs3FPnN/t63w5lH/g85vj2Ujse76faje+b
puHNm3xL76KcJjp8eNoQ1Cinc7DfL+X/XmTSybouuF6VKCdw1hPaJyte6xbrdVwjFQtbv91QVHeL
vLkJRDW2PowUy8U9IjqQPJt4qR088F3BzKwvREJPTnFM+pmzvHHBie6kh7Rt7tenTOV9uq0D4U6U
eV63qzlFHTFcNv9sTOVMs5sQ3s1w6VF6xaRANX0fysKJ8+oyV/Zu+6N0rXj7JhYew0eli26lVHXF
OXNFCDKWcxUSIJioQfvnzxL0RTTJHVd9yufQK0azlshMV5efI7445L1CIOmd9TbSPJWJEdTHCL6K
R06BunZxe+qhVj49bqWiYsTE8M2HSrf/5JfeaaVLIoW5AwyRbqKuP/pNW5ZG1ivNe/uPhAHgUgRs
fnm3+aqXxrFa1sH6ZRyuGc1f7/7xHdUnF8RMH38gV75PeiLdS4Q0ID49b6nSe2/z59XW0eYydtTh
c5t6/0xDxfVvVm9rd+SOeN7Dl2QLFs0VcGvzJQJ4cnAZg40ZDJWaEpznR3vXU6PJo2EkQW+ouFLa
GIvNuOvIcDPs9AXI9xklR81bOjHAma+pBUmXpYHBkt9FHC3617eh55UuRlw98ijbQb1Z/yRCj8Tw
DPrlFalj6jIZF+kqg8TI8uts0tXnaw6XdMBDnyc/LMCIlzzHZTaxX4CwOoYrxsvb9lrWwwQe3sLK
IIr2W/fNIVXxgwJMwvZHoWY6r+UPaMr9KIk4ZhpeXEo+oyXbOoRtsBjDDBlWxG5Lzvv25gxQF3Qj
VOgJrcJF7q3U5dyqAturYH03xvGj9ZZd0p6yK+2UQ545Cz0OssV1dF9BEd9QvMKvGdrqdwNJekzt
LMs3ow1daYeL2PjUqDzfyv4PW8nBZxyuBRnHH5hhSuiKFlP0iu2aHO7C+Ns2abH2dMMN6xSBM/tn
9GmJrcmxxaf6X4Bo03m70mSFqEm7RkmUFYOumNu45mkDL4u9kdnNY1YYqNQfQf6gUrxvf4Vp/0zz
CJ4G1ktNC9rOag6iGXp5THv9lHTzTJIezYM1vtbyx1gwzdZ941z03u2H9vWdw7eT5MObucXg+aCX
YFTYYwX1SBYCSf5JHvUsOVwCv3/oskIRfsMmeg5jZiSPnKT3jm9ycA7OP/xVR1z8q8OiGjfHrwg3
kyDIWV98JtyOU1aZMz41MQmCaKbUpZWYMG2a7JqDMgVmPVnVKutjOpd6+2/ApiCdu7Er37VC28I9
YXUM6zG2dLojoWa9zrr1J+UfqZ+ZXC6s29hTJz3E8W8OXrWFyMSja6NyysYn01C2PkpQPprOvt+C
ttd0ouH2TYXG/9hVkzreAEnQTvHFa7ilD0ehRk6f/GKTzjelypKpFEZzKhwGUsVG1sMgjh/rxJvC
Re3ZdJfn7xLH0HJyHg6WUTJtLSsNp7CUg7HWu7piMny+AHQOQsaYGfBZXjHHpbptrW+MQw0uHrwk
icDu73JhFqgu/WiuzW2b/+bGkAqy3ExmZcnsPaaFC2tOyRC+ub2GVJNjK2Fj0rU91CCm4u2lJmTq
Q8atAbPtuRU71SFVCRKn90dsfzDKww8qiYkDJQdXlpHkEq/kYDCo6dQeOFNbOqfIDe2Dtu4x+mOI
BilQbf4ucrh3t6eCHv4aOYz+9qNp0CFsoT2js2g1o2BLkKwogY+Ct3JB6HZcriw4qtONs9kj15ny
N9a/+sNVZhveSBh19aBORqqgizHVQVPUvrWHEOeGQao6u5gSVoXS56q5LBYwwarxMGmM9vsLgDas
0xnfLWm3XpxMVF0qz3Mlnjt65vVGQHNBH5NFPaLRySj7KTA6326ZPjEiIc5zgTS16Y03IRD9UPq5
vFjwBUiLCdjSW87RiU14MZcg3sdm0Sc7L50ofPCnZWHTHGo9fS4OEr0meSwnwYp/sS/Xbe1oQp1v
Hg2/PB5NFmCznFsRnq7a+Keyg1QV/ECW8Fe7uZtPsdec7AvQsf8aVch4lUr9K1WoTXhWfbIb8kjg
iOsL0CNvqmc9nYNmzR9jd6dF0jbkJ67q7LBJgTVes+GzxB2ZVjZgFlfBv4hULW//iIes0o+gprob
z0CHYrNU/XsH33kjkyAtNNVHTXMqUUcJy0rcYvsLEOvwRMaf4fpc096xXPKBbDa53F7e3rgaFyiO
DdAo4dhcbKZK/z/NHnJPJcqeBx8nBj5cJhcV27BZKjyq/Ac1soSNwCyyRFEDlTX3gqu0wqFWsjvE
S5kSbSHGUZ01X/RpeqI+NSPetKCkTwGyFijwqjwOd+Q4MajimaqW+4Re64QTWVZ+kRP3SkaK1EMz
lz/5XdS/GdTDGlrGdUnyLtMHTtuVkGAPfjzV8nzF4vPbwIl3Tqf8NRVHRvHwPOozZwjLvxWRpGIP
2Hj2esEWOT/VeXva+F5YDRvFYT53tIBoINH415C2iVT6rVlnZSjLIGsl3yLMGKvlU+dKIG10S+Ao
bbK/w36ze2lia1PASboed5Zo62Gd+RvYRjPW3t7nAlr3bnJMeJMsdOpAf4ypSxF5O/zyQsiUw4WV
YSuzqqWHNFx+rqzhDybjJCY7cfACtlDpzjiom2VrYojoIluQdfu25t9v4acpzmsj+yPmx+qPCRWF
PtdRIMvCehj5bKIcZ0IGKd0aSa4Vssy1xQxItnXBe1gZMl+NHsViY00geauDBPYc51Wo8FgPB6xU
sb5C1d7z2Lo7hWXrokcawDCI5+QfzCHxATlSW11x0jpOVqww3z3y5JqfAjWrvv1P1r5n8iPrR/KF
L2vXF6Bm8zyvrWaTe2DvWbG3+77enr2PxBfvzCaFTzqp/ypL8ptrKIJHTkDzfNU93JWNl68+aH7+
Fay/JT7ikVdWOtclbVmSvYrGE3RAkuOO93Su91fH/HJLjmXsDFapJCppULSzuztuwRTGNHhURiVl
rqqh2K9qDab1jqo9Z5SsnR1DMziHRpD+v6wJWR6brBpTjl8HLrP0xHyHXqGsOOHGdx9vpfF0oOsB
xstUge336Pl/7qpesxp8P/95ZGLp6rhvi+s/NkL9l+sSAqoMbsQmLX3PVtZXd10aKZFyqGZP6vMG
+qFWZWvg7lRWDHOserHqGLeaTyEvK/ZBI6lJsvspiTUhgA7oG3V02dJrWXbmpDf0/B29xC78r0Ds
YD0nVdMePUE3z9rI3yHpI0g/3RxLcL37JimH76m9WDqcT15zBpa5hAQiQLHMWtAnyGiqM0ZTv/gc
7JcffsVxmifKEZ9qBK+suXtDGZLw89zZuUcrJhdmWvA82R7/MndIaZysOmWjILF/xIW2YrLtytor
wAA0b97FVtybV6oh+px+D/T+rQv93GE2K/H3aZsU+V2szI9dL3L+qusp0MQj0ZsO65gY9OK2PqkS
uJuI93lMpNiA9fFAMXficzkkfBNvkDQkzXmTQbpfOQ1bUeP9rmnua2/TJOsONQib3ggVSt1A4aq3
uVkGSjza432vF445gFAvmmc+ipFJu2MjFgM4+adk55uA6PSlu9cCKTB8Hs+3t5LWVv7Kb0IxC8fK
o2R7ewwbh+ZU9u8XPnAQsV1avPEGvm9fGS0zZ72xEjk07Nki5vosqAZRW+3C1SSZJlRpxk+na97q
A68y/ayCJNgnkkYMi9BclHw1ad1Lt8DeJl7aAgPQ3sfOgmG0uhK9oYiT0BEQL41CJ4/COp1yluYl
/zoGtgZG4NNEnrLjWAcxwY2gbo/lBT37n0brKO+mtYoyw/oEam6astZEhleNMUGCEXsVjdIEWM7N
4Uq+ylOUsyi9ircCHprPrTQho264PmwHeeJKPT0NKSNzggtEL84Uozk5OUi3WssnFkk8/14yoJJg
DSux2/fkiVfEshC9JqUZ5qr9b+K7JEVbwqeYAl0uj5rLZ4xmUTlLoZ7ldn7nuFF3uyKscs6iIrFZ
xVZM9fBCGZESEj7UjD3IvqDxrY9p4o2pzkdzKBythHaJgMVnrXFB8nepdcogW/7H7w2m/vMwfLED
XRYLCh3JR1qRIs6dsBBNC+cG6TtvGUqc2YfmfTsfgnSXhcq8UzKyiAQn8JgcCRs4iev56R4eUSO3
jHc23NcCDG/8qDZLtyX87hjkPxx43hWBljY+ovVBy6pJVFAUDzPNFKWrlLbJ4HOuOStVrfr8qcxW
SwEkdX2YD461kpz4DIl+wONj9conUVNjU5i3A5F5FttJiJNiqfI8x0wrY/+3wCg2f+UsXv1RP/gL
xtD3a6d9+txpoXJOX63uMKP6YeLZP0iBahwnzBls6+SNwWHkwpVA2Hkm7CGHGHPj3EIFxYX2sgUM
C/Z2soq/8JydXJkc5mLkTPuhE3mKBVUrPmo3TMc/v0nSY7Kp2/xlVRnFkXc45RPt3OaSTEab9Mk3
lv+li2Uc8op//Zu6FCR1P9br5wRxRVcbW9gC3STx0+FF7Rlvn3NNDPRDnUDkUn6NzGEadniLREt4
3tgw5WP3VE9MfMo39LFKf71LgQ0X/37KVjxcERQnImSRmFbg2T52OazbQs65MLrrq22/M1ifpqWj
6PDN3JrPqb3dyqdH6j8VHZHFZH2ernP90PY0JBTU5sfJSkMcjn2iEdlC+YrQ/puCbRhLWe9CVBxL
BZI73k8ibZc9qkFWEw8is7LulRd7WkCaCWtHU9cjcJ+sXfYczzUF9qY2QvanDjkfbYq5xHWpUvsc
leIu+U0l7FOIwMhVb6xc1me5g0gqhvqD2yeIRUJMa2N4Ik31rCT+pgIJnNu60d5uaH8RkGdbSkzZ
6s/E8P3jQHh2MR9MTNKOG8AF9TmPIcyaxUk0Nz6+J2jtxc0g+SZN8gVAV5be000S9v3WVb5Yhnoa
dcoE6mba/5Aotk2e07ucOdb+Toyfc48Xp/xxkqnlb3QrUVg4M1UDCmeGtjwdFgHHNiER+PWKadaC
6CvGP9Z4Pq+n3pu02VfHSbY0SJQCBkrLSM3y5sIncPGrLvHKQEh0sLGhsnKm04MqosRa6GpjxpoM
27BZTv8xjuW9Xwo2uff4S9Lqe4bGUWO9juc63RFSI20C+JPJQGs9t5rRc72FjSU7tpg5aSWyhPIF
2oGSRR3r0hIOHErIhPkoeMoZrIeKUZlEZFbWhzN7RshVvTn5KSYriLXSMosc2g3TYSurFVnLCrDC
tgevevyx9l5eMFUtqhK/Ic5l9yLOEaxKeqcHmg8G4KiDQLfTj1lREWWcX+BZtu1vLddom9/m0nHY
8i156AEKjupb99rBG0KaLsFBHg+lNnRdbNTahusCdvOhfaDWgyNqYOkpfmqXqg4o7Cf53+jmpq3q
ExhBEpUO3+h1vzstdnNcY8P8dKHmCdFdeQdnqrGIu89PPeT2x6Os3+zV8CHEytZ4sn+AnXT8Bxap
h+/FlvqV/4IEFQdcapIlVoidCdjv7WGDo0ZuHt/5DIKrsyO/fzc3jmPx9891BteXzHJStPqmRy7T
rNuyXthUzF+bt3LTlO6piKG5xvjEgUo2W/Atfo+6xUn+HFqgHUJz8pnfa1iU+x61EK8WiGnd0GQa
36V2/LJszk28pIlPkTjIagQYP+FDLXUTQl3aW3A0w3BKR89YixfNe5zaq7P2Ud+quEqbbE/05Obp
+4/AkjZ1tLU333xmeztiTyistIOr/E8E7mjTFsS+AHByDZkm910DMgcOI65953oxfJwfA3K3Ye5/
EklnNkeBbIxsd7qWHYaPNFLUgqPNqi4/+f0QvgAXW1i5aVriYwkXGkYo/ZfL9Q+9aLwrRu0d9Bjh
6ia5LHzJem0ePy4Zr8W7XPVkyCP1Sxz+WFJluVx8bzjBT12k30OUXSuXNrn/BziGU4ReBj5e5TPl
V41QRLwsvFSw8aEq+twTZNtWS67xdbB8YuZEBft+AZpfFo5M2097iLKlG6PGk7REfL2FlrrrxQct
cYmQXflcRUkiTdzdtUKPPJNHNh6nXAFS7zR2O3ltO2otGgtnGMAugc4bNufX+SO/ELctlizKZeo0
btkQf1FY+lcNio6ELGZaYIFCPlucz+teQXd9vpyrI/e26rSC4rG6smwOSneVarqRILXBUhcQVgGn
FT0Sh5BFA494A18RyYaMBHEzLY+yzVq2qp0g4jrwsdb1E23K9Df8Icn2D/fz2ZhF2d1YtUGKccwu
53axVooD5/nqLHErh38BhlFXx2pvdoGUaRiJf72GrXMdZUHRP6UpZctbc2PierlmFVX8qhO6bpqf
8p8Cmr+FbOyQNfQfNxDFN4sDT5q8/KXSpJU3F1kQpyGKs0SS+Ij8pS24PVnPlEFIL1rPUHfHVzu+
GiUdx9mW5eOmgjk/aTza0kloR599VzKa/8bATUPwkje80xaJncuCOfCJamO9WL0MrCReGgc909uO
r2mJKuN5WlY0pNx5DvTzvWdIHv/mff5ZwdXvtuYm0Ym36nsQFFNaIO9YqP194IFZmbeFoc3ayV+/
4bs0maupYHi5dtAprXIJF8QpUEheSFT9V2Ck2LlKHXdGMllfFhX51NC0LUIRk+vfKGPwud63w0l9
PWn+R9fkwI2l3/k6clm8q9rf7SjXXeH3iU3M8v44ENm2LdddWN4Sp3vMi7lD23QOGP0RIZL3vlPr
zFRgf8G3URxDlVly5/d26/zX9Wj/bMtBh0psWEBUuYK/6CJpzZj62AVP1LIG9Uer3kDE4PGY7kKz
shx5dVocP3D11CeHtmhbnGKCMuuSCFaiz67p8qwYDBTqtMmji7vihRJtwEpgQbQ/yEHYxVo8YVfY
a+/dwyNPVmIDbudRJOb+IZTMC96Omr8l2viuga/mrNDo7Rw7wU/irFc0cMHDUYI7DY/8UNUWlz+s
6aQvWRZRimISKUZzGbiVPLCitAZ8SRzINKLLfDxqH0CBGDtuLV/OCdkHMhmfub/iFKWB/YakbsWd
ZlKtYYlshvPKhJv3085OEWp47gEvYqalztGdy8BfoafXS3AbHb1ZexfUuT0UOY1CfK797/SS6lIO
dmtdq+8bfkt2V8+vy9AshMtLYblPYfCtvB907W4bTK4taSpSHlVJQw/DPsxhD44NfXKTk18A+MqH
XEgCzO6wo8u8pTaemlJ+q18lHAXrf1i+cbG2lJTUXDv9TMza6zKnw1URHHRKye3uq13uWhneQXz+
cUxHI04uytkthHu5IYcvBQSzZVzZoop1x23dHvvzmsAuLkO5V+Ns2kqBuNxfrbWvtL8AXYe97FlX
Rl8AjV6ZeyCdKuGfFVPHgBA8WGx7fSvx2Cy6Gu7ZyT7H7HmgBoYGVb84lhocTVGUFRyTa/1ee/Sl
ii+8wgFSbpO+6iQuCTuEFrgGR3Pugq3CeL4ldGJ2PH4oje2Ww9c/1R1TdhHGNFX0gRqmvbP7u21r
mljcSMNx0NFmmzZsGwyoOdLqiupm1jjlR7wJPfH9YFP5L9N/li8ayD2dFeCcUVe6/QZqkjrsOsf9
7p8/oCeR9j8KsD5to8wyv/voNfgdkH9CaU+v4HwBzsBqXwC3xPdYD+Z9P6bfiLn8npWahH48sI9V
R+cDWWGKuZSZgr+iE4Ryrb/NjeQqKsWX3PszSH3I05+ntw2mBDwnKj7URt1Lzpc6PgjKbBnWqr5q
qH3id54F8cJWSZW/0+qIgNl01e6F3lnzC4Y1k65gvgBpIn7I8kLp7uj8hQm+lzw1L0bmAtWoffOg
oP1Jic0G1fUBoraauxL1SV4ZlnIsudixfTeD5lw/XXrqTJRrUS3PqSm1FrhMblhEbeAyyMH/0pJb
Z0A8lgOsI6aEVJrlVXEmql1mBxNFi8yKzGERo6IE/WcxygZNXAY0h5SCzy5FU8aB1V6mshjjYb2z
aFKCNUFMd5XdXGcf/LFA5zAjZ5lVrDKyLkVeASQtZLjq8tKzGRqRDkfP8PjYUiNJbtU55SA7ltWt
Lo1+0075COl9nWHGxZv5rZk1XrW5MQo5NjwE7W32iHs645Ol7/Fpm3Glo3FvCqB9GG22nwbafouX
vplUSOP7AjzFHQlqu3iixy3Bhhy027tOWR1KIYPylJKFPWEDs/Z2bxWaSHLG+aGcYDMHCAMvPznC
h/nmEs3eZGHE6dqUWFANgqJr/3oK8it1tywKCFZ5OzPYE7C1QVUSncfciKJ+1CR9ASrf+Emyr64+
tWvd3adEydsieNecpFMCvLKAKMXu9kgJQ9oqYmnP7za6kKVH3/6unnY3vCyaJEYySJ9Zs2t/q+UX
WC5xOhWH8K0M3k9AM+WMkyey3rDWytIvnB5MnYF+xl76LdQZtKKSPW1UeLmmKWB2rxcq9ONsN6Ge
PI+u2D9YkF/2CxDJGdZKOeEtLbST+SnwMGx56jHJHMJsriTLcJlfDnRp5Ssr9MaN0iZKlEScEZW1
r7RxAnehvQTBvPXRrv/LKp1aRekUaVgI2CVOVspaM7f1dtoqsays6lC/yv8v8xmjdQcwuJI9CP65
9E5yTuuc4dd41NmiZh6w8qfQkgv9q6K5X5s6eh//cbqIrpgLHJr+Agw5fdQNPR1Zqen6AdV6LaDj
ymr1T/DdPMBvDLIpCd7Ccu7Yx+n4h4/LcxQ1b954j0T/Kle0l0okyKTxWMN4KExn82+L88dQzgfz
iEBaDMjzJWEfenFvXHHsp3pbuTYt/tRhPKOIviDTtWpiIkM1PQq28TsXyIPLVx910wq9mgG/C0qN
zc42R0MgtfAPPmaSQnmLnTxu6VdNfjPJfNQPd8UPhKLuRaa6g3smohLHa85fSXY/gseOSmX1/zzP
XC5Fa4IWdE3JwVf3MEKqTW9LyVwdYKEQy1bwtEMtDAqqxkMdxed8h4XGfb5LDO34GFav1aJDyhCQ
oTJ3WNPV9XyYa7TwlJih53MuXiy1xTvmZIiJhzJ8V2sbY9+0ok+RfMwww+1Uz9Rgk0bd0zH5KkzY
kzizJO917zyzNEmFh2C1RZgvz3OVQaOYIyxQpc9TR0zxUo6s6FALp2QfG77ye6JaLWvNIpSM0uw3
QREX9/LjrKzpkb3bKFECmT4cuq4clLKMsbFhLaPgIFRTeT2xubZKdtkn7SSKzGJjgo9lQdT5PMZD
Vvgg1nie7XdeoiaFC0YnZR0d/Vawg4oQQFC6ZmxdsLr+BhgkUOStsNp3fn0qT6oFXuQ44ZgS9Khi
pX8O491rsw0hfTUFd+RjGgC25BT0YU/1UuL8Zno5aq9UpLhVl9qqSuNsfiWowBiGLKc2xiwLYELu
aOoXWyt6aZJ4xuSoU4gR2GJKk1VV8pKXeuIr5D85ty+GPXBYv1JoxBD+GW22DaKd8NGKZLUqiupP
wCKmKTEdZttT6V0kawrNzc4b3Ooa1e1+07ukruRs3tO9p7gKbIySwh6eosfhrZJaMa55X3y6M1oS
XCLjQmbTntOdApnh93QMTXAdk7W3HZOV3TfpUM3GLi3lUmpOs7gudwgKD821wTPrPdYJsc0zXJQH
SyRR5g1+O2CvVV78JCsfqyMPV8vDQBiTEDy3WBn5zhrbiLa/+Fh6McfwwNjnWWGZqyxdK/9bFWvw
2p5jjdOQ5XejRS3HPGXKo72NemI6Dx5nyGv1MX+vTraqGLsDbJ4tpNeBjKOI3BLf4mDxHsiuS+QL
4CGShPr0h3Okqa0sOl1Gb1AQS8+K++zbYWFs73ENrONpVrVw2INunt2jIU1e4gaK8HVh1N7+EoXB
I/dTobGYM16T7y6yxLeNMMTQC5NUBcnZe73NpdypJuw0WqV4NTt/r2Ft/JoJf208/5iAkVrxPdsK
CXhp2DcbgpfF0w1D8lwLc0Gp9+Ef3W3xV7I/Xlmx5+RrtQ1u3a0RA0B/JAI4hzW4srBHN/J0PR4o
9QNGH8vSM/ILU7KOCkneW10ECY4+3U0/MeBXTaR2A6qQlsJuVrL/fm+Zj//pQXJkE/KKU4gT4KKF
uqcC934v2cMIHwCyL327qfqg8/X11Q0jcKHHkLXee7vt+BDXXTi2OlCe4mn1k7ZUYXzPwEXJqPX4
9740mxnd/0+T22ebtyp59of5Rit23pLLwRK5ltQcvDglky09FI1DOUyZSQ4IP36K26twBls7soTM
9Qc25qQyhnVZBg6p3dJQFYt7daXCQaMOq7SEtZ5oFKuE1RRbOIJTmWpaQnhUFvbWSU8N7JENqQq5
vZGkaVab1bBpx614bm28vbkxkuz9UDJHxks0Ggr7qY4PUWh4JDDpYIDMXlAyo2F0qNPPb8olfYtU
XmUC9wqteVEGTT6PC2X1Vf3g1ro1aHlrgNyakOfeyTvnefsMtduNlh6ZvPFmaaml2LOmABSETsgT
74Z4t2PqSVZt7YlmeN7SkixmSTYCzCSPFQmoIDonmxzp8MtZuUOEF14wWf2XgOI8XlXvVTUw7ctr
X4Pgl9Oyp8vw1n1q+Lcb5exeZC5tUittVeIv1oHzHctDLcGAx5yhoqcpGT1tbA4XL7SPMmrMe+mi
5gSFAWZgfnvW+DznbjHorsghT5yubk1tUeYnW90u2sYk7knt4B2nRllbyhS5lE8DxScntpmOFayA
RoyP4N/INm+tEe/cgDRbbp7iaeeR/ZeFtkgqMXg658QVWGGghzDyj6BjHUS+6rq13JZeuRW0v4o6
i7Pu5XNMwwM0pg3JJNcozW6HFvjE3XZbhB2gxa2RcbERbumMF4tpp25bHEHRaxKuyntJTIfGJAGJ
n7dtznoWuXvrU5y1Iaxl68nJiQvUnPa/rT0Je611rcRH00zu611BX4BGHqDeLJFnKHbJvLupk8bG
BwgHQuJ7XjC4fYZEIuiOMfFSDCNhdeSTb9m+N9qhoLG9GYFQb4zCox+Wd0p1WUDUuSYjy139LoEs
FHdHwzXrET3f1Oo53amfZDtLPvqROuph7MGKYwbpHI39Og8HRkWz8DTQwNTc50lTaYN6K3SwblFT
3nnfNjrCodgqBbHwbdv1XK1KMm2gwbGfK9rVr3JEqxCHzZ6c8Ha+2sv1Z+vSI2Kn99qfKO7flaOb
VE0gRYyZYnmG+pG4eVLFTB/aT7cOw4haN9/22qJfjDzm5uR/CGppVPT/rDginzynP6WlpZuB6iKx
4tRQmrmKd7sh1yzj+OMfIraNDBQUnPU2dAbXbUgcohF2W5H8i4Cb/2I2q1sTEWTJHdhCX5okWaUW
lwSES62s7Zh+HyVZtQbl8j4BUSHFjCk66r0mq4ZkrnBJnd/P89KH078jwmXxUFlpmjTFOavXvIu5
lk9RzIbCGOA532WFC3pAMF0WtC1SSX0B5vahE48+fHznY2nwjKLwVHZLnQpV44/VHR+1OeF/r/zS
+AJYBirpGsrbOhPO7XDY4fkXRYx70B95vOaHMhTN1TpgqzMB19Tq/noL2tDnkkvNXXJsc03IlndE
u8URBpX8R581CLdoF8ul0SPWmbdf/B/h92JFfiU2SZKNsGTPYgSvLrjqhzqyq4xKNeJzbpUyNkmR
d7GOorvgMgVE9x6rnPhwZdecucAzHrS2xq1OKN+xiVz4BmvhdDw+9mZVvCVpbp2Mt8sS/ysl/rFI
3v4m4gdstZhlyQ7obJ1PF064PLI+A3uERDoe4GEPtSUAvPW+AKFaPbMP675inKlNUqFi3lVDjRgw
chM+Gt+WWwWXN2pkQccHSrzPlSRDrbHQCb+jkpCE5oKsju+gihYeuvnOlvD5HdlEyqe02Wq3wpi4
NIl+B/FHYtGK4O6iqj9x+q8P8YWg0/06q6oGObHBrgAtZOYVLi7TLHipgbLJfjDuhigyXwC73EHy
sWTym2piprnLnTj6E1FFLolvAfiHblMK+zJtmOst4wDyfLFFdI1HIv97tVjT3LAlXggJGD/r+2qI
uXMNZ8ndSxx1A22U/eQ/ihaXmplJAXC/EkXKRNmdMiicn2Odk86eNXHGbSlCC+Ovyo3lW5ZqL01Z
hml/Cap5vp8ci7rOC3AXWH/XkU9JXrfQkI6JCTjNBDJfnNhdQaedJIIpWKTm0NsaMh4RDYwd6wzX
JQ+H+cnuWFBJuA2nU90vxci5MZw6/W/felKVrcJ8Dlr4BJcOnEDK14ncSEjEeanBe4ao/fblG9KE
RmyTIWDhsHZB6iEM0YBvS4N4vwzzBOnn7N2jAzAGTipBRu9l2VIVTWO5tIHewFiT4ZorMxUWNmdt
r6MCu7RvL4F1Cjfmjx3rL0wiybx4dWwxl0B++pXApYQEUSxM27y15aLEIZGGE75lpsA6yQqJissW
JUD/J92mOQqLNaYtUtge74hyIDaj2cbPZdSnCLXL/7RVhKCguLXudDp6deEYWYLOQeqMV7TWG4UF
7vpzDO+oscZjrj7HvzgUM0HYxzr+7va0MwkPysjXBWXTqAaNp50xaWqKZf47m4PdD2R1utFmfijS
aWQeQc6EKAu4ogHGmlS6STUokxyKcufV7iNVxCVHrizzQjY7nXvrsp82dZnSR6rY0cSuzD6J7vCY
7e9niUlFnlj6kUMr+O0kvlku2/3MW7XuB2WR8pqsXHzxVFsBHRN0eBy5XwDnwBrKNuO5iGqWM/bh
d+2S1QtZoVSnnNApS2nChhu1KHC0/igGk80ouMZhdApE8lulnrDnCStMVR8rSx20UYw63XTF4f39
6l6mLyaZlCP7VkXekiOgL4CuVj1cSZweJAi/vDt7wEoiprG3zLSHiykkvFVTZN1ZcZzuosOdrpfy
BahB+AJcqzWccc3Xb2JUPmJPXZdLUhFwOmcyUTseUyc4+UQdXVO8TMH/XmfNKhfojOVV2EmNum+x
qeSkACppyBValRRzkrHfK6jKDwsgpDiEuCqhq+LLIRCgw2NN1Iuzpv2xh6aqLdyrGGGx2VMSo8RS
QXBnhZehpRUp8CRSUJYvR8iOSVCJsuf1qv4TV3Y92HCaZd7992rANxWV0PTqQnD8sfqpBzdYrSUQ
dGxt9gVI/7P6sV35iqDvqta6zKGLFxySNM+KHtlzO4qHbSu+VPOb26xR8kdb2yLMWgqG0HT+vm61
u5V5Lv8An/zmQ4uJNYWV0dYh3Mi7Gzaml6Vs0t3EHEUWd9LPpmoUkRmb+VlmDj9htbY22bEBeQef
vDjJTU5tB4bLR13Zl+t5i/t1J9WBcruFo3jn09UG15sjAseW9gSQM6nV2Pm/Fcqik+XXmnudll99
rPFET0/DHg3/Glcu8S9c9K7CfjlSU8fkyxz8Zg6wNw4QvJiHvhu8UH037xZKRZFCcTiDcmQfCQiM
+pSozmr2c6JuSxNhIVoL37OpPGraMHEvB3bNPJu6PqgqJUf1wjT4Qno7t6lD4Q78V/E40dql54r5
tdAkTRc1noNBk/aammFbh54j6pGGeggDaZqZk+0bo5WPwHhEm9kTcAm3ykFRGDSzgQRdYTFURfAg
X8CTR7uTCeXlIT0qNRy7VsM/dqUcSQoXqnFN1sN2B16orVbUKLdVt02VLeokyR6/Puw+vYWLLmtj
R+JEwmjSN5oAbqiYvHydubaGdbH8hXfKijNkPsk/s4RCiopA+n+Kyt9NZqle8Dwhu2J8VsTK/+NI
uM1BZma2LaboozycibtfAOwAyzNGwcmuyIZErTsRQZ4Ka4Rh/mt4w9XRozYNgpbc7vgeG9Odc1DI
OMVy9Z0jVIAgnb2hZmOb5Jq3O78000doVFHMMUB98ZY4rWWGgGPBgrGqpphu9fO5lGOn41voTXy4
nSPHpYRvuaaVCQXqldHHxbJC9u4a5+Q48LJUnAav0bfiWtXLdWj2lOwObDU57NOJizJQc+JPsfAQ
q3J0aBRAJ7XFCXgfJO8mnKynyeQrDzueX96STOL+TuJUDcl6PWV97sMHPvFRq8anTQDMM9+mEQbw
HZd3WCQwZ1xj3ARmlwv6VRctvYubexdZg3/T9V/CTRKHO8A+lB2023UCA0RT1weq7QkZ3X3tHRaY
DjQUemOtvbhFFh4Row/yfqWPx1z2je0Lc9HlrkQ+TEnQu3eBvA2gwZ2GCH5TarPvvzo4N4fmBt/a
G7ksix6GZVIckNJmBuWrbTy5nq4E2loxNlkK3hZbt5C5ikioDqmTtAUa0H60+DnR2guoE6U+rKCJ
NfIW04zneV9nhX9i0Bhn4QELaG6njhw9GBR5h/X3jd35COJRB8u9VLwO0QUn5CcDJ74ATfnKBv7j
9X980z6Q3T0/WcKeRo5mf/XN0GY0CBLmBbXTUkwixeUKY2ZNy2N54sPkMXbxcxVijDyrbnB2SYjA
iZQntV+vLlz95nUG6k87ksvzAi+gh42hbPNGoZbrOXrRm2Oz18aCtDxfKkL27fKKz2zFPjGzk10W
MlJqWiYd6UiuaPaxZZwdjbGvBIhvAswuf+dK7fq1D+sudqEThbhcdUfI445LkOc76lR778PkaHk7
23NhOMQLwk1xK9+q6cRnXFv1uBUfJTQIJxSpRMw5Kt4chrSYWLabrFI+ManDPV5rdBEYl+vNVDBM
HnEo88rFsfB/2JKNDtubo4mD/tT/7Hw25b0an10SZB7CPPVUVcSv9l7bKg8MO6MjECcXeuLUrXyy
dMxYnSkV1eQk2PVllz+s8e0N9VEnTAY3mlBgFRWNl0P60Zb01SMLINQSnCuiWDVBzufZlt8ctbmt
/Rmd2DDzqJXGL9PGJaZLNp29eFf4ddFID7N976zX4s3pqtjmnau8Wr+DlHXuTgJf2Yw5xHoH80F3
WUAodJbFPcy5y8qquqgqCVPWZ3f6PK8rExcjCq1ZfdKRdMZVTX3r5gj0ArmYdJIg2M5a/z3n3+Mi
MfBP2Yx0bj9lKEwJYkN2bbRhPWXmoN9Igi2z+a9BxRSAxRu+AIH4e9ePvA5m1nh38jIbNlzcU0sl
TRzpDjPJzxrln5tzl23RiprP/vLON+NHLYimZzZ7o3bCy3L0anOMBAtejXMpFQuMAWjCA/UO16bt
vGij3xsR6pOszp8Px19VpF2LAxBZ32lPyEmX5DXddU7sFxQ6/CJI7qqfDTBUUTMxD/b55WXFJJH2
seF5qj3ru0GxBDFsSXBVKHslxMHP844VSCkLlKSYeLQ95j91sntyh7TuaUvvlRxLmMX7fJEWpMqu
S7al0oSSnbE25h2KdsJfwuLZsXFcpaw3GF0WPZNGn/U+3a05MzWvfy8lJksZREeNnCzuphiH0eGl
4UmoRY0wZqmlpnfzR7RSlhdWxUMxyjFN8V/SbYrjIxzCxIbS0VaHJlaWajbjwLAQqhJkJUQZV5rQ
jSstNrlXvKnVYyTMSat8w0+U58bqlIfZKNaJ8mCV59ASledQwRRhMWh24KtqtqCDN9tLy6K1hmNV
wFJRhRjIVT7KQ/5GunhYZpEH2rXobzLYlmhPG76OuNtV/WMYezwn6dP4W9CtxWnzvSaZEJDPDnXS
51YbrZVEX4dwcu4wMQX5+QJx6LeqtoUecBHt6lsl02ueTI8liSKbF/cd3BoV8dfXENqGG0MSl7W6
wztQ1uX7hkcl5U3ogQTnvYkp+QWAZO+5tnVwTh8VPToS5V8ZyCWEJIXZnDhHHTG1M1u7pe3uPdqs
A3El7KVjofEOn5Wkr6NIlsKujbXsLiCceKShBqTdDE8ZxgX5a2Zys+HUYIhzKV9pmWG1DGM1xUG4
fYHzmBjdRECEkgd9ZD4T/gSWk5H0P87TldYIcoHEU4ArAjML/YrnYep3Pc2jVx1KHhYqd7tFU5tY
JT/XbjG8vf9/Fgzplbncnw1Rdfr0XzpSSC/tnxux++1idnzynZWsP2Fsz+lt65qLostpgq3P6Otv
S7jxc/9WQw40DDs+RVJuwXwBNvNTXKfUmxfjcncRqeMn2YZdpkCJ7VBuPJfLzR31cSYkUA1dWVu6
q0WsYw3I20O6s2pZK0H7czuJ4CvuJAEL1v6jah2b5K1znLuJY9eNYtYZIt/l+HhqDJvGRiFR9Tdg
6umlzC2tT44YE/yoTDNOrqeAgZnT2PjHTkn8oRLrzutKkVWyLFOuQ6OA0ns4SkyBKclID0iHuYJr
GsLO8kciwQ4hZvAfP9ovgEkO3+hhy9NJqYK8j1AyZwyf+V8VWUS5jrg7XRI2h4N4G7N7nY1/k4pW
v5sIvsE6IDycDhNWt11deD906G8g4Evpq+WYxbGfKuoT/4uJIAndXPjn5596Skzmxfjg+4/S6nPu
6djMgJvu+4uEUCqQXkcbETE6LBZDntxhITATAaqvrCi08iDhxPOZvocHL91jc7PVB9Inv5SXg/+5
jWvg+/2fcTkXWKDHZNXpvbUHmqQ7NijRIJMQM2i8l2cfXA5aedj+J1Nb+/4gpbEyiUEcJt/dbfWM
ZuOUjo/9WD2S/GvMzKlY8ONcccgfyw+BwJrbgf1XjX8JUuC/JXlVzY62NA7vmEqkkpHtC4f9h9rk
IXBtejV4XYqJghm5ozx9ZgtgNq9AvnhAOut4hcbhcRnEBr9Pvs4pume1mfjPnId8NurqASgxcyFN
uFIVVX3X4sznvIA9bMjG+bcmRluWkPVscPHDhnLSD0IvXUbXlB+x1FJESF2hxrbpCxDiKpfo1myW
hMd0CF7+0DU+WRNko8+9KR3JtvaZ385PIb2bZoN6Wx59ikvLys29P1OdYtAkXftJFE1ScDkPktf6
35/TEVakZZMmWVmg7X6hGHqRHEfVOe4i0+nacr+xOoLkTqbyO74L0tMtDD85eyXZDlLkW7gZ/Xmi
8FGvDsA7pXcsLZZlw6X2xgvozbn9fwUgSd+2RKSsI4PWbKOyvriGP7kcrKv0BqOw02bUZfJgALYz
ye1SazfJfX1xPGCEkldlz1wTT9GuobW5WWV5EAB5Q9/f2rKOj1Gx0/hy8geNGwWlfYoU5+b0p9x4
Xvre3mncDbAcP6g+lbd34h09bixnQtI0Mwd+DgjNW9U8VaZd2moRRli1028DHRq054AjFsfBt7eQ
QTIY9s4zGM8tgcipLHwXf3PnM4ESRSGPcR/EK7a21S10jQdCunJZowzCPjPzA4yOtcwPF8E1tNZz
meNZJjIWiODyelK8OwygPB9zJfGyDJvCb85HIqlq3h2TSkV2lSQMcHafun0NaemeJdPsNVe6aKZ4
xAY0zJljx1Nc/qGo/bJpHBfazFgrHpk1PNACmQA2K6yHwZczLGRIAZIDMoI6qBk965ANlq9W1LXI
NHtNMuEKyy/2UYiqnO3cMcgdDTTiByek+E7jV9wQ7MMyqSOHK9cdKbY+F5br7WSwjS1bYzE9WzjA
rQs/G6WsNjH5eHtJGbK8BvP6hqs6BqiTvfo3lpFPMspVmw3LZO2hWJdymPBdwdQSwR0MhiEzE/wo
eefeoNX8Pf2XB5wnjk+fYUGNw9+K1tZ8WxWfiW4ubYrNH5CwsVPXA5wfaub1LXIL1GSOAxl33Fi5
NDaKSI4GMbjHXAINezaBuu9Hi80ht0f9K8Y+225to0WPEwb5n/vCvTPh/feZavE8gOCdq56CnfQR
xOrweTe3C9hIw/I4rKY4NdJ4pi238xGMMSfxJrlZWwakskM2KPtbDoaovIaaHqdRXNP7WxHWk+0k
1n+Zik8yhCuXTckHg0huW/vGqW4mjcaEDLv2jNSJISRiqMZ5rpdE0z7S4JHFWiWbHhi0Z23ScZ4H
Hauy1K8itICu4DC4LViLdWmm2+1iFZR1/CuI1jxDNeM6Bvk3H8eapvQcSDVrsXNzLIOjMxH0zxWS
5pjTZqNpOKzbFLUGem76hZ6buqRFjfSF6h30m6gRNvo3VDuo3UwJS1JuqLNGaYiUvTS1MzSZoAfv
o8yojTSaBWJt9NNRbqN1AmPppNN3UZpXE0G6k3GimmncViQSEU4TkVBTc0XAtiekMoqrmkyaV7gO
lOTTKaTRmkFhaKKKkZWAp+KYKfSLInplOk603tTGgpMUUGmJibeasRVXBqxEaBE4paQGlosToGaM
0lLSGFLSUtAxwNPFRipFrSCCxoW1zeeW8cW8pj51UEjHv6VOZ794FVvMMCH5euwH69K6lrWOw8H2
dzAqmW+dluWAyQo6fSn+ECurqdNuoh9mX5/OxgL7FvetFFMZgQXetEJ5Mlz0wm0N0/2f/rUs8uuk
Dzjc4Dcbtw+b/Gu7sZ3TxRbWaxKlrCjJHwPmwPvZqnrV4Y9TjtoSZovti+YSvCnf0p8i7FI4z/ic
LKWAn81l54bcV+nXFVYlvdziLzNx++Ezn/gWK9zWTTZtUuYfJUXCWvBwOV215dpBKeJUiAyks7o4
x/Dk1LikM5CYOrYcYNECu8irGCzswChfvZ9q3fF0EUGq3Kx42hzjFZ3h441zTPT7XF/6FShuTYuj
SdZlkuIBHM72ylrhCx/dBeCX/Gkm0++tIIZJt6x3ABTJOG98elepwvanXvEMaRlHOnuZHz1AB5A+
tYWqQya9oejrZoJpLZXWVV6qdy5z+Wa0cYhY5ZfCmruu9IGxsD8f3T0NQPoepfZZbh4XWKI4Z2yP
yr1201GKBJyDua1sY1dTjAcDlT71jatrR1vwpfy7Fi2y7VC4GQvWlyxsJo8iKN1wceuKPNkXgMw/
E1t3K3n9jW5Mca227O/jexJ798VhA81NtRl2ztby/cpbo8jDrg/zrT0eLVLTU4xbQk3MeSA44GOp
/D1FdR4RjtLbwvf3hO2b7RtZ1++F4wB3wa0dbjeS+0aXTwqyNZqzHIG5SuWBPqa0tFDZyet2Wr3b
SX10EIU/PsbgMOxqaQ6v4g0v7QWi+zWi7M5wQF7dTzWvexNdaReSszW8kcvzxHgSH1qHw3Gf+EL1
de/n7h9O9FosSuc5pfhW81S2e6jlVYkfaS3B3elUL7TLqxlMTq24fqOx/Gu68JhpfDN/HH986ghC
57DHNS6lf2snia4W3jS5CWypJnGEYDnb2JpNQ9StTzF45VPzKw+uaYS3rXZeMUVIYGHlfNyoGBNj
3rizyRn+8M/SotECUWtyyhljYg55APaiO0uHBKoxA64FetTXdrbQaWmm2lvMv2YeYxKBQ5UZ3e+a
ydCe0+wa3JJ5KSpdYjTju3O31Ape7cep599mnDBDGwY9sHNTx2M4liV1KB2C5Yepr0m+tdMudWtH
MsSj+zw2FIw0+3oareKpLK4ttOeERKyOocIRnhsc4rRclhanN+I/C1xok2z70YTd5hHDHHRaj0fw
5Fqem396ZCGs8ZjA659fSu+8R6pYT22pPJcxTrLbr9lVSDtbA/KuY8J3FtFpevRPNHE86rsDnBbH
YVPugjj4dPubt3FvDJIEJyVGQPqelJJpt5FKkDQSCRyMIR8xB7gV2vh3Vbax0W9t0khS7e9ypk6F
c9u5qa11u3XVJ5L67hlkFgY4pljASOcjjnHOKT5X1KOe8QeGho1lYTMXD3K5dD/Ce4rmMlScV3fj
HVrXUNP02OO5W4lg3CTBz+NcpLb2y2SSrcBpmbDQ/wB0etZuMbgVm1C5kQRvM7IvRScgfQdqgL+5
pjcU2iyAlBzRimKcU/dUNAKOKlMrsPmdj/wI1FSimA8U7LDBUkH2NMFOzTQxDknJOTShaWlzQ2A5
ODWxpes3GmPvhbBrG3DFIGppgb11rMl85eXljVCVw9UQ1PDUmArYplBNFAmJk0maWnxR+Y4X1p2A
aDTgCa15tAuYohJgEYzxWTu8tiCOlFgsOUFSDXQWuvC0jGzhsAfkK5yScHpVZpCapSsJo2NS1iW9
kLE8elZbSk1Dupu6k2K5NvpjNUe6mlqkLjiaTNMJpM0CHlqTNMzRmmIfmjNMzS5oFZD80ZpmaXNA
rDs0mabupCaQDiabmkzRRzBcDTc0tNoELmjNJSUXGLuo3U2kouKw8mmGjNJmgVgopabRcVhpooPW
ipYx1FGaTNAFVamFIq06majWUGo2WpTTcZpCZDigipilJsoAr4xU8VIUpYxRYTJxS0gooQtBaKTN
FACg06mUuaAHVIDUWaeDTje+gG5Ya9c2lnJaZ8yFs4Rui57ipYfEVzBpbadEFRWbcZAMOec4J61p
6Rolqnh2fV508593lxp2B/vfWl8OWunaqjaeYcX8rZim6gD0xW0Yt9RoZa+Mrm3+zt5Sl4BhXI5P
GOfWln8XzThgII0LSCQsF5LA5reg0rSLPV9P0toBNMZD9rdgdpPoParHiGHT9On+z/ZLQeZcKIyn
3lTPRsVpy+bKSOX/AOEt1AXxvQQJDH5f/AcYrNg1i6tbp7mLAlfPJGcbupFew/8ACG6E99CQqK6w
bmtT/FletecW0Fvb+IjbNGpjkmMWD2BPaocQOWuZ5LiRpJCWZySSfU022la3mjmT78bhl+o6VseK
tPj07UpoI/uqePx5rL01A97bI3KtPGCPYtUJa2EzTXXNTW4luQ0omuUKSYHVD1z7UW2qajZKzQtL
Cr5BPIVscHFemRaVYjxRf4aMj7DIVi8v/VfJ945HHrWBrtnCPC2jGNV3+bcbiBznecg985rb2Stu
CZzEerakI54wZNtxhpOD82O/0qD7dem0NsrP9n3MSvO3cxyc17DZ29isELywR7V0eBpOBnOMk/Ws
bVf7Dk8N6k+nQqFSbBfHzFs9vak6aXUdjymSeUoIjI+wdEydo/Cq4rZlFsbE4gYy55uMHb16Vkdz
ULRiZetLq9SCSOBpPJP+sC52/wDAquwXWruI2QzOqfKhGTj2BrofB8cEvhfWEZFaUMCvTeR7d66j
wgkCaZpSui+Ybi5ZlYfNjHpWto9WB5vNPql3uiYzv3ZAG/8AHgKiDanagWw86MS8eTyN+f8AZ75r
1saxpdzNq0FpbpHcRWzF32gZPNY9hG15aPe3sMf9o24KWKthTIB0fHepcew1oeZyy31gzQ75YGB+
ZASOT6gd6qrczK5cO289WBwT9avat9oa5mkugRK0h3ZHOfXFbHgfR7LVru8+2AmO2gLhf7zf1qeV
Md32OZmup58eZIz46bjn+dQ5Poa7bV7PR1Sy+zROjtcBX4wpUtjBro5fCunKdQi8sARWYmQ+5XNH
JYNTytLydPlWSRR6Amr9npmoX0cs0AZlT5nYEj867rRfCll5CJdKrNLavOrY6dcc1N4KCW1lraMN
yK2xU7nnHT6U+RPqFzzVWmZwm9s7tvU9au39hf6Z5YuNy+YoZQSehrf8WaVb2N7aNAQDceW5X+6S
RxWx4qt4bnX9Ejc/u2jiViemMDrR7OPcLs87cXOwuQdoOO+T9KvaRo13rbtHbY3KpY7jjheprv8A
XHtrf+0IIdPEkQjKrLhdq8feXuTV3wzZWOnR2ph2lp9PlMtwcblYg4Wl7OHcep5FcRtbyPGWyVJU
/UelQFmP8R/Ormqf8ftx/wBdX/8AQqp5rKS10GJvI7k0b800ijpUgKabRRQA7FJnFGcCmE5qrIZK
Gp2ahU1JS5QH7qXdTKTNK4Em6l3VFmjNFwHlqUNTKTNFwJd1KHqHNG6kBPupd1QZpwNUhEwOa1NK
tGnnTA7isyFd7Ae9d9oVpHbQ+a/pWishbmneNFa2W18H5f6V5nfENM5XgEmt/XtaNw5jRvlXj8q5
iR81LKehAxxTN1K9RUiGyXdSZqPNGaQhxppNJmmk0AOJpKTNJmgQuaAabmjNAD80ZpAaKAFzS03N
GaQDqSkzSUAOpuaM0maQrC0U2kzQIVjTc01jUe6gCfNJmog1O3U7iuPNJSZpaLjCkopKRIUUUUgF
oxSUmaYAnSg0Cg0za4w0macaaRSJDcaN1JijBpiEZuKWOmsOKIutCB3LFFIaM0CClptLmgkKM0Zo
oGOFPFMWniqhuM63SPEMSaLNpVyp2Fi6MP7xp+h6zZaNbzTxrnUskROfuqnr9aoaL4fk1G1nvGYx
28PBbuW9Km0rQYtTjuNkv+kRn93D3cetbJPvYq/kb9v4n0+SezvJw/2qKTdKwH3x7U/U/EWjXk01
wLaZ5XdWTd0XBqpB4UgjFkl1M0dxcSBWhAGUB7//AK6uat4S07TTIhnnV1KhCw4Ymi0l9oE/IfN4
3hGt2+pKjbEgEbrnknbiudXWYBrLag8ZZQ5kRR/ezx+Vdevw0jf7IyTbklQNP68jPArlJNHtoNYa
wlJ2eZ5akdcnpS5X3Hcy9a1NtUu5LlushzVK1l8ieKXr5civj/dOa1Nf0Y6RdPA3bke4NZUCCSWN
D0Z1B+hNQlqSzrovGtwutS6oIwxlhaFk7YK4zVTSvFFzpzOHRbmIklI5+iE91zXXReBrP+3ktXjI
tBaFj83Jl8sHJ74yaydQ8O2VroEF4FYyTXEiOc8KAxAx7YrVKXcL+RXj8Z3CreCRQ32pNmB0RB2X
2FUbbxFJb6Vd6eIwy3Mvmbj29vyru9H8EaVLDatKp3yaaZC2eAz4yT+dRan4N0rT9IvbiNxPLG3y
spyEz0FDT7lanms+qTSWotCFEanIwMH86oZrUns7VbITfaQ0xb/UgdB9ayjWfUll/TtTudOffA+0
9x2P1FaMninUmukuzIVkQfLgYUfhWz4M02zvtD1hpkj8xB8kj/w1Y1vQ7VNI0VIAsks4Ks8a5Lk/
zrT2em4K5y0XiK9gnnnjkAef/WHaOaLjxHqNzPDPJMS8GPLwoAXFbWp+DBZab9tEv3SFdCOVPccU
+DwTbmzt7u4vTDHcL8mRgA++aFTf8xVzlLu9u9RnaWRjJI55AXqfYCltL6802QtGWiYjB6jI9xXV
+G/DiJewXskubOK7ESNwfOcHpk/w/WtPU/DcOr+INYT/AFa20PmKBxzjpQ6TWzHqcTd61eXiKr7Q
EbcNox83rU58Tam+/dMfnjEbf7o7Vr2Pgyaexu55C6NCyqke05fceDU134NSHTpboOVeEZeM89qn
ll1YXZgL4j1KNQqzMAowDnkD0qKDXb62MrRTFTL/AKzH8X1rpNP8L6S+lQahdTOglYqewGKm0nwr
pVxBeXck+baGTYjL3quRdwOLuNQuriRZJZHZl+6WPT6VI+pXdyVMkzuV+6WOSPpWj4istNgkQafK
7ZUFt4P9ap6Bai71S0gcZDygN7jvWdtdx3JpJtU8jc7XHlH+Jt20/ieKoi+vFAVJZVUdMOQPwxXr
1zaWcp1bTSVaO1tg8EW3BjOOpauZ0rTdNktkKWwedS+4SZLED/nm33cVSpJ9Q1OAbzJCSTknqSeT
TBGxYDua7XR7Swe5vI5rVjJu/d+aC0a89DsBrN1yyFrqcMfkrCGZfkToRkcjvzQ4pDSMa+sJ9PZU
mXa5RW29wG6Z96p7Sa7vx1axw69bhIt6Mtv+79cfeHNSa/awf2dJNb2scURIwrJskj9BzjOKXInu
NnHRaVdS2jXSxkwqcF8HGfSqao3ofy/wr0zS7ppfAzw26RPL5rApgZ2+ppNFtNPtNFt5xaC6ujMf
MTgsOenPQUNQXUVmebJEzuqYPJxkjFX9Y0W40cwpOMGVQyj2PSu5sLOwvL7U7oWy20tugMdqWDoW
Pf0rP+J06XV1ZSRNuAgTLD+8B0qXZAcGi5bHviusHge/8lJA8RLweeE/iCYzkiuTj++v+9/WvT/F
uszaPb2RtSrb9MSN3T5uq9OKpShbUNzzdoJMnCk46kDio1jkcnajNjrgZxXp/hvT7BbS1aVopPtU
ErPkr8jkHap96j8L6faHTboBY2uTqqpIMgkQ7ugpezhe6YHmyxvvVGUgsQMH3q3qGnSWMwh++5UN
8vv2xXS+K444PFwjijVVW4gAXgLjjPtVvXvs0fjGwcNF5R8ncQQV7Zzjim4w7i944ZradV3GNwPU
g0gtbkjPkyYxnO09PWvUtSm0xodXVmg+W8hMeCvIJGcetaN2lp9h1e5hERiS0VY8Y4JXn8aPZQtu
FmeMAVoaNprapdx2yZy7AEgZ2/Ws6RsSNj1zXd+Dr+xtNPVzJHFdC+DSs2ATDn+GlGMU9wMDUtAm
tdQlsoQ07x9kG449Tiok0O9WeKKSCRDIwA3Cu5tNY06LWNZk82Mi7gxBN/CDnoTjiqOo6ns+zGa9
huPLfd+6wNoz0zxVNRAz/EHhl9AS3PLGTaffJ7DFPvDqQtB5dvMFCAucfdGOpq/4r8QWGpS2N3Fd
K6wtDutv4vkxuzRrPiiGdr6S11O0jhliULAIf3/T7h4qbLuVscumharcxCdbd2RgWDeoHUjNXNB8
MSa1HdOG2fZ0JxkZLDt7Vf1DU9L1S204i/W0e2t9sior+Yzeilfl/OqvhnXrLTv7RguJXSO6Qoso
zu/3j7mkrdSWYcWi3t5LKkEJk8o/Njt+ND6BqEVxHBJburycqCOo9fSum0TX9P0uz1K0F1tec/ur
ho934+tPs/E9lbXoe5vHuwbcxiUp/q2I/hHpV+6IzfE/h+HR7HTZFXEsyHzOnX8K5E12HinXrLVL
a0ihlLtBkEnvzXM3IsVt42hkkacj96rfdU/7NRJLuIpZpuaM03NZgKTSA0maTNIY/NJmm5oFK5I8
GnZqOnVVwFzRmm0tIBc0ZptLRcAzRTaWkIWmsaCaYxpgNY0ygmm0EjqbuoJpuaBEgenB6gzS5oAs
BqXNVg1PDU0MmpDTN1LmkIdmjFJS5oK0FpppaQ0ixKSlFI1FxBmk3U2ilcYM3FMQ/NQ1MT71NCZb
60tNFLmgkKSlooABThTaWmA+lHWmZpwq4jO+8L6rbtoN9o7ssbyv5iu3AOKh8Ni3s7qbUJZ1X7G5
KxZwZT7eormdM0+71BmW3UnaMsf4VHuavWmj3l4JzEd/2fO8Z549PWtlfyC52019ZaveWmq+ekDC
4UzxM3QA9af4puLXUbiSb+1oDFGENvGCMsQe9cja+Gr66hWb7iO+wbzjLH2rQufBV7bJJ5k8ANug
Ypu5wf507y8hpnUS+LbeDV9L8u5/cLCFmweAdvftXI3V7a3fiFrgTKsK3HmeZ2IVs4/GpR4G1Ux2
ThAy3h+UjkKPU/5FZlxoMtvqBsJHVZAcFu2alqTGTeLtYj1e/aaP7oAUe4Heuft22TRt6Op/Wrmq
6XcaXMYphg9R7j1FZ8a7nA9SBUJaiZ6q3jOyXxJBdmZzZ/ZGiwOhk8oDp9e9Y9n4htLmGbT9QZvs
Jld4ynUAknA7+xqRPhvfNeWVuZB5bxmRpMcL8mdp/P8ASucm0S5E0iwo8wV3X5RkAqxHNXyz7iud
nB43t1+2RtlYfsa21pjkjYMAmsbT/EsVvo9/YzszSXLhkPXge9Y1tod7c3kNrs2PIwGGBBGTUmve
HrjRJTHKQQDihxkUmVZb61NgIBbgT7s+fnt6VmZpD39q07PQtRvYxJDbs6How6UuVkml4f8AEUWk
aVf2jxlnuhgHsK0U8bRpbaSn2cM1kcHd3HrWAnh7UHlaFYX3r94YPH1p1x4dv7QxCWJgZThMDqfS
q5JDTsbN740W902exEOFlcsxLd89apah4qF7p1lYfZwn2YYD7jj61Dc+Fb20i82R4gAMsAwyv1qW
28G393FFMroVmB8sDq2OoH0pqE+47jdI8WzaXbG18lZ4/N81FJ+5J/eB71di8cXcWpPqCxRh5I9j
o33W9zVW18I3DieSZo4IoX8sySHgv/dHvTm8HXT30doCA0q7kYjAYf7PrSantcOYt3PxB1aeNkBg
j3MD8i84XoPpVeXxrfywzQtHFi5G2Q7eW4pl54LubSFZlfzszeSAoPMnTaPeukg8OR2Hhe+N1HGb
kYYd3j46H0NL2cnux8xyr+K7uXTRpnlxiJCcHb8wzVXTvEV5pUTQRFXiY5aOQblz64NbPhLSVvI9
WkxG/lxE7XGSBjqKp6N4ZGs/a5PM2LAxz9M9TRyeY1Ixb7Up7+YyvtGeAFGAAOg/Kksr2eynjuIT
tkjOVPoa7D/hAcXoh87EQhExfqdpGeO1Utf8MQaPawXCSFxMflyMfL2OP51LhJCuZreKNSMt3M03
7y8XZMwGCy46VDB4m1K0QJFOcLnGQpIz74zWbLGfmI4A/M/Sq+DSvJdRqVuhpW+vajbu7RzkFzli
QCSTUVzqV1dTCeWUvIOjHtjpiqC9aMnNLmuHMadzq99eOks87yOnCsTyAPSkm1q/uE8uW4kdP7pP
FZ5bmlzSuvMOYsx39zAhWKaRFPUK2BTrfVLqAFYriZAeuHIzVTGRTApoSuwuy7/aNyHZ/Pl3N1O4
5P19ajkvJ5sB3ZgOgY5xVbGTSlcCiXkA8Pg5qWS6nlADSyMB0DMSBVZTmnN7UkropEyXEy8CR8eg
YgVq6R4iutK3FEikJYNudcsCPQ1hg04NQkFy/qmrT6pdvdTH945zkdvTH0qp9okPVmPuSagz81P6
0cvmS5MlE75ByTg5HNbU3irUJbU2xMaxsAG2rgsB61gE4oLfLRqh3FLVJGx9TVbNPR6cbiL63RjH
BqGW7eTqarOaZSk5BcmLk00k+tN3Cmlx2qfeGO3HNLuqPrRT95CY8tzRmmZpM0a9yR2aaTRTTTAK
bS02kAUUlLQAUopppRSsA+ikopCFopKKBC0tNpM0DHZozTKKoQ4mo2NOqNjSAYTSZoNNzTJFNNop
KQBS0lLSEJTs02imSLk04NTKKY7Eoen5qvnFOD0hFvFIalIqM0G1hEXmldaUGgnNDAhKUm2paQ1n
cCIrxUI4arLVWP3qaAnHSlpo6U6qJHUUmaWgYUmaM0U0SOFPBplKKpaDPQvAt1ANB122LKLiVP3Q
OATx2NU/CcFyuos5l8qK3+a7JPVV6rjvnmuTtDcGRUty5kboqZ3H6YrRhttUZ5kRZd6jMwGc49ZP
/r1tFvsF0ehazNHrM1re2MmLGOeNWjBC4IbkgVoeOIru9uJ44beBEjiSRp96gnA5Xg815laW2qTR
M1uszQo3zGPOwN+HGa1X0PxD5RaSK+27N3zScbPXBPSru/5Skz0iLxD9gGgQZQpNbqjjIO04xn2r
hvFLLceKCIWXmVDuzxweefpWE1hqzJE+yfYx2xsd3J6YU1Xn02/S5WCQOk7dAx+b86hyk+gG74/v
be6vohCwfy4VViCOoArj4OJFz/fX+dT3tpc2shWcMH77s1UXOalPUGe3DxQLXXtKtxPEbeSzTzGL
DCnZ6+tZEl7bXGmalFZzRR3P9pswcEDcm7sfTFcfa+CtWuoYbhRH5c3+rYyAbvpzWdcWdzZzSW7M
d8bbWCnPIrS8/IXMdvr2r20WoaU0Mo3QrF58i/3uM9Kh8bXMGplr6O4WRcLtQN7YJxXDMsmdrk59
+tXb7S7iwgildgVmUMoDZOD60ndjuZmRtb1zXfaNq9vZeE5Y/tAS78zci/xADoBXM2nh+4utLm1J
SPKiOCO9Z0dvNKSI43fB/hBP8qqKaRN9TtPDXi4Q/bxduQbqPYsxGSvH6VT1DVll+zL9umuPLl3M
xXYFGf4a5tbSYzJCyMjswG1lbOPXHWtvX/DJ0OC3kLFvOQNg8YJqXKS6Fpo1NS1rTJ9Plh3yXMpH
yfKU6jGGPGcetdLp+o2unaD4dvZcqIPMxGOS2c4zXkJOBXV2Hh7UtQ0eW8eeTyoeI4iflxj8hTvJ
iuXD4strnTrqyuFZRLdGYMg5AzkCpZPHFu2v2V6Im8i2jCAfxHC45rkLTSL3UDJ5MRYRttdh91T7
mo77SbrTn2ToUJGRnuPUUNS3uF12OzfxvaNbxRCMkpfG459M5p+oeN7K6t72LY+bpc59D6VwNsga
VVboWA/M12HiXwcNOit5rUNKjRK8mOSMjNNQlJX5g5vIpeHfFcOhJeI0DSm7QpkHhQfWk0fxWdHt
79Fi3i6BH+73qHT/AAdqeowi4jjQRsxClmHX0+tN03Q5P7YSylUMQxDJnr9PWp5Guo02+h0dr4xN
5eW20C3C2XlNv79u9T+N9Ss5NK0+2idXlUMW2kHHPeuZvNEaXWGsbZSj5IC59Kku/CGoWyb/APWf
vBHwf4z270/eaGZMmq7rL7GLdMbt3nfxk+n0rKYntXYXHgm5top3eVf3CgyYGdrH+An1rkZBtYis
ZR1KI1JzyKfxXQaR4WfUdOOoB8D7SLXYOSC5HzGrv/CHbdbOleaWYx793cttzgVUaRLRyRANKRxX
Tav4W/s2xF3v3DzTH+IOK52NN8iJ6uB+ZpuFuwXY6G3mlXKRuw9QpP8ASnxWFzNnZE7dshSR+fSu
7124PhddNt7KBGWaHfJ8obcxHTdzWj4TnjTQNRnnURgXm4/KMrzyAaaih2PMRZT4dgjYjOHOPun3
ps1tNGqs6lQ43Ln+Ieo9q9OintNV0/xPdw26xowUJwM/UfXNZHjOGGHR9ECIFP2FN3r0zz780pQS
QHn6qS2BWj/Y2oeV532eTy8Z3YOMetVLdXeZREMuSAg/2s8frXfS3N9odjcW94XudRuIcNDsJjgi
I69ODjmpWgzzxvlOKfBDLcSCOJC7t0VepqOXJdvrXX/D5IPtd+0gUyrYP5Gf+ehHb3paPoFzlJre
SCQpINrr1XuKaAeldx4a0e31KTUbi+5aDcdh6ls1NJa6NdapoyQwSYlk2ygghfQ4p8l+5LPP2znF
G1/SvQvEh0O0uprBLHZc28ybGx94EjP1q94gOh6RFHbtYA/abdCJAOjsKPZeYHmAU0YNetW+iadE
2j2wtUeOeBnllP8ADkdz2/GqenaZpltpmq3TWscwtr4rFkjLID2o5VHqM8wOaQGtLW7q2url5LaM
RRn+Adj3qhatEHzMGKdwvWpk9QJrGyfULqG2jPzyuEH1Na+q+FxpLSJJe27yxfejB+YH0+tRxala
RXNtJp1ubeeOVCHkfcCR6/jXV3UbX9jrFxq9paWl5tBgkiYFpH9eOefemrCOMg0a4urCa8hG5Yfv
qOoHr9Ky+ldz4Su4LHRtYedlAmh+zxgnlnPYCuFY5Y/WlKwCHrSUhNJuqRDs0hNNopXHYXNFJikN
IQGjNJRQA6ikzRQAtLmm5padxC5pabS5oYwzSUUlIVxaKbSk1QhpNRk0rGmUhMDTKfTTQAlFFLSA
TFFBoFUhBQaM0lAmBoBpKbQA800GkzSVLJ6m0y8VA1WTUEgpmxFSZ5oJqNutJgS5pM1GXphlqRkp
NVifmpTJUYOWpdQZaWlpq06rsZsWjNJSUILsXNLmm04VQDhTqaKeKS3A7r4dQW7f2xJIqmaOyJhJ
6hj6e9VtGur5NWZYFaRrtys4b+5nktnoMVzun6hcWEm+BipPBx0I9D61oW+tXttNLcRYWSVSrHHY
+npXRCXkxpJnoOvRHSkih0pFFq8qNceUc/vMjIOO1aHi2d0itxam68+S2XhNxTbjnIFeY2uu6lbp
JHGzFZDuYY3c+vStJvGGvSL1b7mwHyuQvoDirc12ZWx6NYawlhpOgLcQhxM8SfMvKPnrXF+PS51+
UwZ3naU29c57Yrn5dV1SWOFZHk2wvujznhs5qvc31/LcCeUuZuNpIOfbANTKV+g7o6b4kPbm4tBG
VLfZk37cfe2jriuEXqtT3kl1LIWuPM3Hu+Qf1qBR3qFdvYTPU0u/sfgfRt8RdgzqDnmI84Y+lZXh
e1juEuNUndJGWZU8ljl2UnlsHsK5fzdWeCGNhdGGQ4iXDbHP+yMc1EVvtPkKHfCw6r0x9RV69mGh
0vjizt7XUka2C+WyLyvTOBxV7x1HCmn6Q6KAzWa5x64rip7y6ucebIZMdM9qfcy3zoiXDSlVHyLI
DgD2BpqVugjtfDpH/CEamrEAmQkA9wKsaM8UGhWcttHHJdGX51JHT/az2rzxLydEMayMqHqoOFP4
dKEuJkGEkZfYEgfpTdZvoNJHo1nc2suoXsl8bYXK2+IVjx5YbHTPTNU/G2owXtpYKsySNGgDhTkg
+9cDvlZuG5+p5pWWUDc3T1zSk5NBoQO238/616H4Y1aObw1c2U10sMrXQ2lj/BjpXn5gkIzg4pVg
m7K34A1Kciep32l3lqPDt1YxTpHcDUN5cnaWiU9c+4rN8a6paX91b/ZSGEduiO4/iYKAf1Fcp5Nw
x2oHc/7OT+H1o+y3O/YY334ztwd2PXHWlLnZd0OicLKhPZ1P4A16td+L9JEbsJVkU2IiEf8A0124
/SvKHs7hE3tG6jOASDjPpmt3TPClxe6Vc6iW2rAu7b6j2zQlUsO5st4os18PW9nDK6XKzGQ4BXHP
rWD4f1oWWrx3t2zOFY5bq1N0TRP7VNxlnCwIWO1M9PU9qqWukXV+8ggiZ1jJ3MBwo/2qaUgubqeI
7ZPFC6nGjtCGY46HkVrnxpHJCI44WDvqYuFDHoM1yDaBqCXCQCCTe4yox1HqPapLjQr6whE8ymMZ
wCfX2qnz2C56JrV9AdG1WWZ0jluZU2x7hk+4xXj8rjzCfepbieaQ7Wd2x6kn+dVD1rnd7judfoHi
ePTtPksXXINwtyCPVe1bugeILbVPGEF6SIk8sq5c4AIXrXmlOWRl6Ej6VSmxHZeLNfjuI10yEYit
ppGBHRizHNciJdjBh1Bz+NRPIW5JzTM5pNtjOpXxjOYo0mghmeKPy45XGWVcYqNPFdymly6cEj8q
WTzGbHO41zZOKAeKabXUOY3NO8S3mmRTwRFDDOQXjbpkVHquv3OrBBPjEabFUdAuAMD8qx1pW6U5
PqFya2uGtZkljOHQhlPoRW9N4w1OXzCzRFpU2OxjG4jGOtcuCc07JoUtB3JGbcSfWp7O+msZfMhc
o3t3+tVM0gOaXPYNDVi1q9glkljlKNL9/HQ/hTn1y+eVJjMfMj5VhgbT7Vld8Zz9KWk5y8yfkWrr
Uri7m8+ZzJLnO9vvUt1qt1ebfPlaTZ93Pb6VRZaXbip55sC8NWvQNv2mfaOMbjjHpSf2jdhDGJ5A
h6ruOD9RVTjFJQ79wuDNTc00mnA0DFBI5FStdXD8NK7D0JOKjpDRqIkM0m3buO3rjtn1xURNFNzS
YgptLSUgFzRmkpM0AOzSE0lFAMM0ZpCKSgkdS02lpgLS5pKKQx1FNooELmlptFAC0xjinUx6YxhN
JmkNJSEx1NzRmkoJuFFFGaAuJRSUlO4C0maSkpEjs000tNoAKKSjNAjfNRSYp28NUExxTbNSNqY1
AOTQxAqGyiBzURNStzTcCpAj5oXrTyRTM80IllpOlPqKM8VJWqZIhNGaSloELmlzTaUGi47jwaet
R09auHL1Fqdf4I0mDVb2UT4KwQmUKf4iO1Pg1CK21eSR7dHR2MRj28BTxlPfjtWLomszaNcedF/E
NrD1U9qvwa9b2+oNfLbK4IO2N+gc/wAX51sppDR2epWFv4btC9vD57Xm1tzLnygT932rW8QTxaZp
1nOhhDyWoHk+SMuSOvTNcJB4wuVjnFwgnWU5UN0Tn+H6VcufHUF0IPNsYnMEexNx9qrnj5lnbaQN
Hk0LS2v4kXz7jh9oH7zdwCetct8QkSx1yFoAqhVQrgCsK68WXVzZWtqI40SGfzkAH8Wc4FVdX8Q3
Gr3Mc9xGm+MKAo6Hb/eFTKa6XDQ3/GttCbLTrtVVZLqFWYr649q4RT2960tT1u61TYJsBUGFReFU
D0FZXes1J3E0e66Zf6fb6f4Zhu41Jljg8hsDiTtWLrGkW0174gv5UM3kTjZEO+R7elcEfEN/LFp6
Nk/YMeRgHjHTNWG8T6ojzSNJg3fMgI4P4Vt7Tuhm7rGk2Vgmk3sSAefsLRfwjnpVr4kbZZbRooQI
/syZkQDbnH3c+1cZfa3eX4jEsmREMIBwFpJ9W1Ce2WGZ5Gix8u4cEfWlzLsBlgfeA6A133hjT9Nb
w/eahPbea0UuBx27/wBa4ZIpHUuqMV7sASPzq5FrF/a2z2sUpSB/vRjofrT5vIR3mgf2Pqeoajdt
aKnlwqYoePnYjnaKo6zJFJ9hA05Yf3/U7f3gyflI9K4iCe6jbMTyKf8AZZhVu9j1SFUe6SdQRvTz
N3T+8uf51LlLsPQ7m+xNp900SQwbYhvR41Kg46qU5q9oNrb/ANi6BO8cW6W4dZXIAGzPfNeVnUbo
xsgmcK3BGeDXSRa9fT6ILCG3/c2/zNMp5Un1NEZdkCsdT5mn/YdZXTDCt22oDy84yYMjlM8Yp89x
p8fiTRi7w/LbgXT8bd23+IjivLDLKGYhnyTycmmM8x5Zm/M03Ve1hqx6tqF7pNxp8qSSwlV1kbVX
GfK3dvarV3q+mC01e2iniEctuotEUjoF5BHqa8fUu5A3NyQOvrWzqnh+90pITMdwmjEikZ6GhTlY
d0dD4HvrO2XWPtM6Qh4HVVb+MkdBS+E9XsbK11ZbiQR+cD5We59q4ZIJ5GwqufTAJz9MVYsrOS5u
UgDFGZscg8fhReQXPUIvEunyX9iYv3rJprRsVXOHIqt4zkjXw9peHBcuxZf4uSfvVw7JPpl40cDm
SRDgFBk/lTr+fVrmIG5WQxg8FlIGfbihuTWwFVo7H7A8hlb7VuwI/wCHb61jN1rWk0a+Kl/s8u0L
uJ2nAX1+lZTLg1g009RiCir1vpd1cwfaI42aLeI9+Pl3t0XPqfSp/wDhH783X2TyXFxjPlEfNj6U
1Rb2JMgmitW+0C90+ETTxlUJwG6jI7ZHes6KLfIif3mC/maTjy7gIB60u0noDXbz6NpGhQ2sd4jT
STx72kz9zI4wvfFanhrw7pWoaZPcmBXMdxtDO4H7vPXn2q4wXcdjzH5h2zSFs9q9Nn8OaK9vrU1u
FkW3C+SVOQG74I9KxfFekWlhpelzQrh5rYFj3Puabiktxo4nJqTDEZpIWEcyMw3AEEj1APSvSdPt
4NW0nVJpLW0AW33W6Q4MqnH3mA5FSku4HmlCnnFPdcMfTdXUeCtLt7w6ndTrv+wW5lVMfeNTyJiO
VO9DyMfWlDd66zQ/Dq+JHvrqWQQxwfMw6DmrUnhPTG1GxtoLpXW4+9tOSpFUqT/mFdnElie1GSeo
IrttY8N6PYbY4bovOtwsTx5GTlsHFW9X8KaFpiyxPdTLcmJXj3D5MuOBnp+dHsn/ADDPPs+9Lniv
RrXwdYCW3sJt7TzWZm80fdU4z06YqOy8NaN/Z0l7eeaFjuGhJXpgHGfak6VuqGedEYpM1oavDbQ3
sqWr74Q3yN6iobWGKV9skgjX+8ajYNAtLeS7lSGFTJI5wqLySfQVbu9FvrNS08LxgZzux2/GtLSp
7HRNZ066s3e8aNyzRhMdula2r29rqelXupxJcWsiTkeVLJw2487QeuParT0A40WNw0H2gRsYs434
4qoa7vQ9h8F6sZsL+9Hk7+CT321wpqJCYyig0opWEJSUppQKLCDFAU1MiiphDxmrURFTYTQEJq4i
qGwcD61dSBWH+sgH/AhVcnmK5keWRTfLJ7Vt/Z4x/wAtoP8AvrNNZIB1nh/CnyLuFzI8pqURmr7N
br/Hn6Commh7ZP4Ypcse4XZVKU3FStMlRGVaiSQDaXFMMgpvm1IyQ0w0wy0zzKYm2OIpMUnmU3zK
Qh2MUlN35o3UAOpppu6jNADulGaYTTc0E6DyaTNNzRmgQ6kNJmkzQAtFJS0AaIcih2JoxS4pGxCK
ZJUrCoXqGBGxwKhLmpmBNMMdFgItxpU61KI6TG000J7FlBxTsUxG4pxaq1MxM0ZpKSgQ/NKDUeaU
GmBLmnA1GKctOFr6miN/wzox1zUEtd23ILE+y9a0Xi0a21ZoJkYWqEo3PO8cZzWX4a1k6Hfx3WNw
GVI/2W61oXEujXWrrcvK7WrN5kibTu39cfTNdKcRHRN4bsNJgkvrzE9tcL/oCL1Ge5xW1Lomk2+m
2t59hidHty7lmw3TqK51/F9neebbXUZNmq7bYKPmjx0NXbjxXol1Z6faO11tt1YOFVQG9M803KJS
NXRPCmh6rpBkk2wySXGIpC3Tnhc1z3jvSLTQ7u0WBFwEUvjo+PX61DL4qto9L/s+3icbLjzY29Bn
NUvEviOPXXtW8tx5Maq+c5bGM4qHJD0LPi7SLWytLG8gQR/aolfZ0AyO1cbnjPsa3te8Q/2zHbQB
SkNpGEiUnlcDHNc8wJBFTGWoOx6p4XiibwqJt1tC8VzkyzRBiwHOwEg9awI7dvEerTN5SpFGNzmJ
dqKOmT2GfSqFn4pFv4ebRTb53v5hl3cg+oFQ6P4judH+0rGqulwoVwx9KcpagrFzxLoK6JcxxK4c
SoJAfYgVq+KLRYPD+kSo2Ve2/ugdumfaud1nxLLrUsDSxKhhTYNvcDipdS8V3GqWVrZSpCsVqu2P
bgEjtn8OtVFrsB0ng+MSeGNaTC5xkZAz0qDQvD2n3GmSalevhRJs2j647Vz+meIrvTLa4trcx+Xc
cSbhkn6GmWviG8sYTBGVMRbdsf5lzn0q/axW0STqY/Dul6jqKxWUkiW6webISCGyOwzWh46WEaPp
nkghFtjFgjkdvm9/auLi8R6gbjzoWxJjGI14x6YFQX+vajeRfZ7iTKBtwUgAg+1S53Ww7oymTGfz
r0jwk0EnhPUtttG8q3CL2LOMenWvNyTyeeauWGs3mnRulvIYw/3qzjPlY7o7HRtKhtvD+p3ckKT3
q3giEMmGKIDyQvtVTxvaWdsNOMAVHmtY3lVezFBnPpzXLJq17EXKTuvmHL4P3j6n3NQT3c922+WQ
ykcZJzjHanKo30GrCwnDjPZh/OvbNTS0vrWGGfyzD/ZAZZCRw4XoDXhm5hU/9oXezb9om29Nu84x
6YojUfYrQ9M0+8TTPCsNzHDavMlwR8+zeY8n5sdcVzei38d54mtZ5VihV5ct0CAfyrHs9E1XUIlZ
AxjfhN8m0Of9kE81RvLefT5mhlBSReCuelNzkGh3ySWcPjlTJJGLbzDlxjYFPqelbE2raQ1owmmh
fbqwOxfmPl7u2O1eVWUU1/MsMYZ3boOtbcvh26sVExngJV1BVXDbWPQOO1ClITPR9Ue3fS9euI3U
qVUR9sIV6fU14q5G416Re6Nr81jLC1za7TCJ3jUbSVA4+vFc4/hC7VtOVmTN+fk9hRODmFy94X1q
zt9EewuHWN/7RiuVLd1U/wD1q6DR7+31Px5HcQOGjdD+YTpXn9/odxZ3s9mgM7wtg+UC38s1VS4v
dJmDxmS3mXocYYfnQueAXOy8aatZrpSaajF51upJCcdOfumuCWYIyuByrA/XBpbm7munaWVy7sSW
Y9ST3NVt1ZSfM9Ro7u48TaNrENvcX8ci3FtHsCIDtfHABotPFFjbeH7uyUSJPPMzoV6KvYGuE49R
9KX8TRfzHc63QfFFvpmn3ljOjMlz1ZeTn3qLxJ4lg1mK0giQrHbJtGeCa5bvStiiT8xD0YLIrEZA
Oceoz0rqbTxZbWEN4llZeVJewiN2L4VeMEgdq5LdSZz1pJDJZXyTWhoetT6PLI8XKyKVkQ9HU9jW
SRRmnfzJudHpviV9Oju7dYUeC7fdJGeMYOQAfQVLbeLJ7S/hvYra2BhUqkeMqARjJ9TXLAnPUfjT
gxzjIpNvuO5q3mrTXuoNfOEWRpBJtUYXOc9Km1vxDc63Mks4VSiqo2cfd6Vi8+oP0opXfcVzpY/G
epxqMOm5Y/LVyuWCYxjNVv8AhJb4adLYbgYpGLnI/iJyTWCDzSk0MLj91G6os0ZqRFy1umtpFkTh
l6Veu9evLuHyHf8Ad53bRwM1ig0/NMZbk1CeSJYi52L0XPy8+3Sqhak6UwmqJFzRmm0VIXF3Ub6a
aSi9gJRKRVqK44xVClDYqlMGWnYu3BpjiRe5piOQRWwkUc0I/vVXxEmKZH7k00sfU1burVkOQOKq
EEVLTQ0xuT70m806m4pCE3GjdSYoxSYrBmkzS4pKkYlJRRTAKaaWkpkgDS03FLimMKM0hopEsKSl
pDTAKSlpKQWCjNJRQAoNOplKKBdTX20xqfmo2qLm4xjUZFSGomYCkIMUEVH5gFNM4oGS1DJTTcVG
ZNxpxEToakqOOpiKuzIY2ilooQgAp4FIop4qhABUiimbhTlanEDQ07T5dRuoraIZeQ4FbM2gW1nq
UdnJc4U8SycYRvSs/wAM6qmlata3Mg+RG+b6GtrXltLzWFZLmPyLp97SA8RhuufTFbrlsMuJ4MWK
W6e4m8uyijLx3JwBKccAZ4P4VpReD9HTT7K+klumS5JBK7dox3on1vTbuD+xJJvLtrZCYrrO9ZHx
0PtV5dZsX0Gw04anaxMjsJcr0TNPmj5FpIq6R4Fg1e2u57e4OI5Cke7vj196zPFXhSLw+lsS5ZpA
C4P9Kv2/iCx0jQr20t7omX7TujYcbxnqPaqPjPxHbaxDp6RyeZLHaqJfZvek3ALGfq3h6C20u31K
A/u7jjB67u9cvwK6rWtdtm0Oy0uAlzD87N6Me1cc8hNQ5RuDseleEfD+najoct3JAJp0uVjyzYAU
np+VUdW8JpNrl1ZaeBxFv2NkAccn6fWmeGPE+nad4euLCdpVmmuVlBXsFx/hVpfG9n/wkM+pNE/k
m38hVXG9vlxuNUpRYjKuPBd5AbRUeKYzyeXtjIO096cfBMhFwEuY3ktVzKgU4X2zjHFU4vEAstVW
8i8x40mMixu59emOlar+N7ZP7UeG3kSXUhhizfKD9KrmghpCR+ApXaKPzQGktzdDHQcdKi0rwdJq
FrPO8gWOKbyV9WfOORVi2+I7wrAWtg0sMRtQ2cDbjrV3w14h85JoZDCkTXwl2u2COcnmmpU30HYP
D+gRaR4ss7RgJQ6lnyOOR3qDxJ4btzDc6hE4wlyVYAcdegpfEHiWK38U/b7LZIIYwo5+UnHYnrWJ
f+Lbq90+ewMSIk0xlJAPBJz1olNWtYEonTeJbLS4vCukvDE3mFCcquWJ7lvavN+iE+9bsXiy+jsR
ZERPGqlVLJkqD/dPasI7mzhSRWF9dhuKOo8O6Bb6lo99ey7mkt5Y0VRxw3UmtW98M2Nj4msNMUHy
rmJCd39515IJ61yWl61qGmLLDan5Jsb42XcCR3x61t6f4gvH1ixvtRWSU27rgLGS2xewGM8Vonf7
IJRNfxB4c0+z0S8uYovLlt73yAT1YAlSf0rzw9a6rxTrlzq88/leatk0pdUK4G4k53e9c59iuWQy
LBKU67gp249c9Khqz2A7bRdMutLsbTVZ457uWX5dPt03FYyR99h0FcnrrXM99K9yhjmJJdT2NRrr
+qxqkSXlwqx/dUNwv09KW1s9S1uSR40kuXXl26ke5NDblsmPQ3Ph1d21nrDtcFQGtWVWboGIqTUN
K1GHz7ky7Y2uQFBb/WZbggdwKwU0e9S5WDyn848hAOeO4xWhNo2shEZ1unXeIx+83Yc9Fxng0KFR
9A5rHb+O9cl06G1W0MZ+02SI7qclflGRxmpFkgvX8J3azx7baP8Af/MPkPOc81xUnhbXWnW2kt7h
5WG4KwLYXHUnsKrL4d1ZvNWON2WIkNtJxkdQPXFaLnQrpnX2+owzajq5Wa3aGS4+VmYRy4z1Vj1F
cl4wMT337u5W5XaPugfLgdCR1qhp2k3GqXy2MbKszZwGbrjrj1xWlZeD7y9vrmyhaN5bfO/B7jtg
nNKTlLoLQ5Z81Hg10moeGb6wtDczx+WolMeCO9YBHzY681i4vsVciwaXmuwt/BLSLAJboRTXCho4
SOuenPvXNahZS6fcy28yFHjYqQfbvUuNt0HyKeaXNWLWxuL19kETyt/dRSx/SrL6JfwyJFJbyJJJ
9xCp3N9B1oUW9kF2jOzRWvceHdRtFD3FtLEpOAXQgE1PL4T1eO3+0PaSrFt3eYVO3Hrmm4tdAMHN
NpDxSVAh1JSUVQh24ijcabS0WQ7hmlzSUlJodxc0hopvelqIeKeM0wVKtUkIUio9pqwBRtFMCHbT
SKs7RTGWkwsiCkqQikxSswIyKSpGqOiwhc4q1bXbRnHaqlIOKqLsDOiSWOZMHGao3FnzkVRinZD1
rTiulkGDWi5ZIkzmjIpuytCaINyKqMhWokrDRCVpNtSEU2oGM201hUhqNmpAyOkNGaDQSJSUtNpi
FopKKACkpKWmSFFFJSAM0lFFMoSlpDQKBMKXpSZoNJiNammlPynmkJqLGtxrcCs+4bmrsjcVnTHJ
oKREXNNL0hplIQ7cafGeaip8fWnEReQ8VIGqFOlSCtCGSZozTaKEK44GlzTKWgY/NKDTKcKS3Anh
RpXVEBLMQAB3JrZn0O5tLi2tpmVHnxgE/cz/AHqp+H5o7bVbOWXGxZlLZ6YzXWeM4jd6uj27h1nK
+U4YYBPv2xXRBRsBnr4R1D7abVT91N5k/gCgZzmtODwPJLZpdNexrG0piztJAYHHWuhhuFbTl0B7
kf2mV3Pc5GCpH+r3/SrWnSSQ+GIbVY7d5RcsuHdc4J+/1q+WPkNJHHweAb67F00LrILbOcHO76VR
1bwrc6Tbw3E/y+bHkL3BzXa6DeyaDpet754zcQusijeDuzztHPNU/HOtRavpOmTBk8xozvRSMqT6
jtQ1BdhnHXfh54dOj1BH8yF+N3bd/drn2rub3Ura18JWWm+YrzmQylV52g+prhn5NYytfQbWhb0/
SbvUd7QRSSBMZ2KT1q0+jXsdwtqY385ukZBDc1s+D/GJ8LRzhYUlaQgjcOlTXfjuW41dNT8pAyD7
m0fzq/3a3EjFvfDWqWCB7i3dAxwMjvVn/hC9ZFv9oNqwj27txz0rT1z4g3WtxorIibGBAA9Kmn+K
GpS2f2TYoj8vy+nbGM5obptAjhZVaN2Q9VOD9RXa+BNNs7+01N7iPzGhhZkO4jBxXEyy+Y7OerHJ
+prqfB+v2Wiw30dyHIuIig2e9RFpMos+FNJg1TWninUGNLZn2djtHFbVzo1lqOkTSJGkci3nkxlB
jjOBms238VaTpVxDLYW7nFsySlzhnLdqR/GlrFZ/Z7e32h7kTtuOe+SK2jUh1GkdCPBFqkUunmLM
tvbee1yTzv25wB6Uzw3ZWieH7R3t4nc6j9kZmXJ2M2OtYbfEJxql3eiPK3Nt5BTdwOMbqrWHjlbC
wSy+yiXE7TiQtja+cjjvV+1ppS06D0Lj6dBp/jW3tkVDGb6JNpHy7SemK39Jjhb4h3iSxoYo1uiE
x8oUR8YHr2rz238RSxaumpyASyJN5oDHjPb8qtDxfdR6zNq0aRiWVHQr/Dh+tc8K1mnbb2v47Csj
07VLbRrnQbuSzRB5l4qzg43R/PggDtms++02d782GnyQwww2YIicf635eSOOa89Hi6+W1uLQbBHc
S+a+Pvbs54NKnjLUo0VFfDKu3zD97b/dz6U3V5lsVoY18DHczA43b2DY6Zz/AI13HwxkZYNcC53G
3wvGefbvmuAnlaeR5G+85LH6mr+la9f6PvNrL5fmDDfKDxURm0ybnsCfZv7Rs/ueculvv/vK2O/v
VfTcf2WBNncdeBUv94ru6gHtXlB16/a4NyZ380/xA4p0+v6jOF3XEnynIwcYPrx3rb6w0rWK0Pb1
8WsPFCaV5Me3ZITMRztxkAGqks9haXOhw5K+fJIz7GwpJJ5k7fnXiZ1e+877QZ3M2MeYT82PTNMl
1W8lxvuJGx0+Y8fT0qPbsPdO90mKKL4hr5W1USafBGMAH0rR8MXP2LxH4mlZ0SQQzMuSOTkkY9fw
rygXc6yeYsrh/wC/uO78+tPW7nLM5lfewwW3HJ+p6mpdV9A0PT/GOupq3hWwlaRPPE7b0GMnn7xF
eYROBKpPZgf1qNpHIwWbHpnj8qjzUc8twPZINcs557C6jmtfJihUTvIwEqbB0Qdea828T6hFqerX
NzFkI7krnrjNY28+p/Om7uacpc24cx1HhPxOPDM7ziBZiwxhhWnqHj9rzVLW++zxqITym0dfrXCb
qQtUxclswujutc+JF1rsMcbQrEI5M429QDxUmofE7UL6wNkY1WPywg2rjgDHNef5xRuNNyk92CaQ
rHNJSUVJL1FpKKSmIXNGaSigB1JSUUrjFzSUUUEhUitUdKDTAuIcilIqCN8VYzmqAKQ0UtICMrSb
aloxQMruKhNWXqs1K4gFBFC1NtyKQmQU9HKmkZcU2mnYRoQ3PY1K4VxxWUGxVmK4x1q1K4D3TbUR
qyXVxVZxik0BG5qBjTnamZqQYooNNzRmpsIWm0maKBpgaTNKaSmhMKWm5ozTAU02nGm0iWLSUUGk
ISiiikMWikpaorQ2b4bJiPSq+cirOqgrezD0aqYNJtFDJjgVnScmrtw1VcZNZ9SiHFNxV0Q5o8gU
7oaKO005VINXfKAoKAUEsbGKmC0sSiptlaIhkeylCVMBRimIj2UgjqalxRYQzy6UR08U6iwxoXFW
BPMwG6Rzt+7knj6elQ08VSuBIZ5idxkYn1JJP50ouZx0mkH0Y1DRTu+5SJGmkJyXYk9Tk80eYx6s
fzplJQMc3PemYp1ITSERtTCaVzzUZNAXHbqaWpuaKTGhc0oamGjNSMl3UFqizRmmO5Jmk3UzNGaY
h+6nBqizRQFyXdRuqPNKKWoD91JuptJSAdupweoqXNO4yTdTSabmkoC46nZqOlzQA7NJTaM0D1Fz
Rmm0UgHZozTaUUCCikpaAClpKKBjqKSkpiCkooqbiuLRRRRYYopKM0UxBRRRTAcDU0b1BTlNNMLl
zORQKiRqk6UDEY4pN9NfmojmgTHu2aganE1G1IQL1qynSqq1YjNADmXNQsuKs01lzSEVKTNSyLio
TTQWJUlIqUuGFVM04NTbAc61GeKnBBpjrUgQUtBFJTASiikqWK7CilptNEtgaKKKZSClxSUZoELR
jNNzTlagaDbSbTUm4UhYUgkR0oozTaTJOg1wY1C4H+1WWxxW54lTbqlx9RWBKahbGhDM2aiTrSsa
E60mUW16UtNXpS1Igpj9KfTX6VcQY63q2BVODqatitlsQxcUlLSUAFOFIKWgQtLRRQAUuaSigB1F
IKWmhhmgUUUBcWmmlprdKAuQuaYTSuajJoAXNFNpc1LZSCiim0gHZpM0UUwuBoFFFAC0UmaWmIWi
kozQA7NNJozRmk0O4UlFLQUgooooEFFFFCAM0UUUNgFBopKQxaWkopjClpKWgkSgUUUhi0UlFMBa
KSikAtFFFIAopKWmIKKSlpgFOFNFLQIerYqdXyKq09TimBYprJSK1SU7DKzDFRNVmUVVbrUiYCp0
qutWFFIESZppekfpVdjTESs2artSkmm0AJRmikpCHBsVIsmahop3AnYAioWGKcrUMRRcLkWaKQmk
zQIdSUm4UbxQULRRuFJuFSSFFJuFJuFMYU4UwuKPMFMB9FR+aKPNFAElJURlFKJaQrM7TxdH5eqT
H1Arl5TXW+OONR+qVx0hrKOxaIGPNSKvFMqZfu0DJE6U6mLTxTGLTH6U/NNfpQkJiQ9atiqcPWrY
rVGbHCikpaYh2aKbS5oGLSikFFADqSgUtAwopKWmIXNLSYpRQAU1uRTjTSaVwK8gqPFSSdajoGJR
S0lSUJRRSZpCFoooqtACkpKKkY6loFJTGOpDRmkJp3CwUUUmaGxWFoooqRi5pKKXFAISiiindCHU
maSloKFptGaKBDqKTNBNAIWlpmaPNFO4x1FR+YKPMFAh9LUPnKPWkNwvvUAT0VV+0+xo+0e1Ai1m
jNUzde1J9q9qoZdoNUvtR9KX7QTQMt5pc1T85qPOamSy5kUZFVPMNG80AXNwo3iqW80gZjQBoCUV
Msy1l5anAt60XBF+SVcVWMgqAk+tIBmpbKLCuM1YWVcVS2VIo96ZLLTSDFVmkUdj+HNODxDgk/lS
OYvU/l/9enoIjMg9KYZgO1IZIs9T+VMZox60hof5vtTTMfSq7XKDoDUZuB6UrjZaMppvmtVUzn0p
n2g+lK5Jd81qaZWqr5xppmNNMZa3t60m9vWqnnGk8xjQ5D0Le8+tN3H1qvvNJuNTcRb3+9Jv96qb
zRuNVcRb8z3pPM96qbzQSaXMBa80Um8VVzTwaLiJy4o8yoKBQ2UibfTvMqvThUtjP//ZUEsDBBQA
AAAIAHh/UUDWMZYEwuUAAB7mAAAMABwAYXNkZjA1ODcuanBnVVQJAAPEvz5Pr8A+T3V4CwABBOgD
AAAE6AMAAJy9U3BlX/gtumN00LFtdmynY9vmjtGxOknHtm3s2PaO07Gtjm2d3//ce8/Lfbl1R9Vc
a876Vq0aq2rOb4zxtL5Wvj4BKPIm7macbMw83MysgK91gDgAHhYWDhYO/n8DAQEBERER4f+6/Qck
JCTE/zNDQkZBRkb+74qCioqKjo6GhoWFhYdH8jUEUQgAQMBA/G8A/m9AQEJBw/z3WgTEbxAAKIj/
B/+v4ncAJAQUFCQ0FAwMNPR/Fb//agBoNBh0MlZRWAwVEzhyZ0y2wIQCeAqx+n4s1dlrSnZTlyAE
RGwcXDx8KmoaWjp6Dk4ubh5ePvGfEpJS0jKyauoamlraOrpm5haWVtZAG9dfbu4enl7ewX9CQsPC
IyITk5JTUtPSMzILi4pLSsvKKyobGpuaW1rb2jsGBoeGR8CjY+Nz8wuLS8srq2u7e/sHh0fH/05O
b27v7h8en55fXtH+owwJDQ0FDfc/lCEgPf7ne9CgYchYYdFFVeBMnDHI2QLhMcUSCur7ESjYVa+x
TF1mEbEpOXapbv6H9f8m/f+Nc9D/L9L/h/P/ofzVB0CDh9iBIoWCIAdAogGg0ABfawAkKIj/Fv/N
hQE7J8hMVNIDmcCFZEzSCmUXelbVESGTh6rfxdbiaOSlaOp1fv2qvxncMKhFKEpuXTVVJG3E8lVG
yfNWY0isOAsx0eSanTXGGTL8ZaZg0RnkRdvmLaNwi5KZ1RtFH8M9PrY52e+n3Il5xk99EhpxEog3
e9rObVPNB9RvbbQwhhKkPf5QAAU9n0qb6IiuwlJlmq64XszeVH+8y62J3+UN5O06M0yACK5XWbPj
VD6nnPPWtebHIGg+NCGNjZF8NC96I38UeCmujCWItZiQgDT3u6MyGaPXLmpWDq0pNg+vZoxsTh0u
QY4cHwamYebj1ZQPr8uYPeSd6GDy8AXwk1O+W3GcfmfUhQHqWs8H60ZcvzNa9WjYJS6JUMqMLdeu
4yXX/db2dAvIoaRp+9BE7oHn+JpT1ceVjtmLBiQXbHpEfl1ov3QecXLkahhoZQtYEPiJlT5qH0dz
Gdvcpzu+5rfhWsot6SLIrltn+2QruNAv+iabQA3DMzLKbHRDaPPKFXM4hOdbqr/Pr/gFmOvEzIV/
X6X+I2Bbun4IOHZ0NvQrOcMAXqrXHNrVbcYlLw7fUM2Bf7GEXXyra0TR8Ktwacjiri2ZuxTg9iPO
wh5d7LczPmil7tpybGDKjxtzdV6eOsa9BwVcLDc2dTSvFRsQNt71P2DlfJTRrCq0fC/gneatroS0
xNXHyLzwhSN00TlDawjdxCmbhGt2nmax2coqnykdNf9jnm0lKIwfzpaw+Uw/TcexnvxLJ25dPebs
rmB7/IN1rYNrvovNLdbUqKVU2KXqtkXrCiLaeZmzf2xvxzz4fKlepHOwiwLAH7xx3/9Uvj1caO/s
ZvmbJPlHMmg52tgsKXNWts++JsmqtnskXcUkcUvGgFKETbkFdT/y8F2KqmoGieuGUUjdR26fIPL6
m2Z1D2PL7UGaUvS6/uSAEkfd2LHwD+fYh7ia08fM5NTLhIbR8gh+jKGY+G9kJXTk0eH5mafqIdq8
iY4Mjsarw78anlGVA0tizDU9k3xqtoLx9uo43kYvmPdTKIQ72u5kzlccgjpA4kNcuiFTU8s53g0y
2P3YV5tQcYp/lEEmHOa6npann5vUOuS0RlYzTxrd7Bp5Yp3BKtguhZeagEcCP0nbAPkbomJ86Qan
n1G/qHGJJF112Z7L5PGbL8Z8/Uqp0NpJusKuS4v/JEwq5U+VnGJXuXcWxdd+y2vb32p6N9mlMH0D
URg1VltfCkdIsiep2fqTNS2sy+dymS5N5xpTEAS5Pi8NP0U0+bR0tb/9jDleLzYlKoOI3CcRASrK
pR1F1k956om2LIIeYNrlccmBFEKdtvjzEpnn4/bJL9YrmyuuZ1cGOH/cGAhILkia9V+YOKh5+g3Z
JIVSaMKaPRl/fcjOWmiX5pre8CMNNxHn7SoWJzm3vr9JyxCWHGU4W5AXh8u1buIKLD1che42XR/o
BlcxzY+aMSwgebwuPnPygB4I4Hq69IbCXXxrU4SCSpcebOVy0OVMnGLPPOfoA8ckMfMG22YEiAIg
xFX38wYSqnJi0JT55nb+Yh4lYlAbpuCdqf6QjY61+UvO+wVYzCsv+7GJmVhzAG77oNMqEfoNmw48
UJOutmhDy5T1p2sDoZFFJlgPQ/5JH0PGnJ3ii7AjLUxMLeQPhpCATMMDQWOeyqtGZgDW3JgwqzlI
sUhLI/04QiGzm5J3NX9n0G/2bNxpqIL6suJ0qwLLCINxVcRDTRTE6lF1kVb/0YuYDmE12GhlUhK6
2Aiwzy9t8jVCyCMmyl/9VaOY9qpi62IYuNMYNL+mT0IDCtlZdkSJVp60hF5SaYXXoBLuRB7uSw57
o2T4Wb/KrU/vsTc+N/AO61Ll+jjNKVGw7jvPyEadl1SeX+GP7nrh8XBqyqz8wkI3E2kZ70qSnRsm
6d3XmMn4AYJcnAFJQ7fqdSBWvm2BcMXcShvJI41Vb2O4J4aVKIuatYDIpN9r6LmGkWRKCf9KW+b+
OSqCLFFsVtlQXTnl+BaTSMu5irPRDtnmR42DVM075cH1zBL9qmUgGMvb6zmwRPReel/Dd/4edmaQ
2jJxyFJDf/3eG2OhvZU7ovfAiVfWqmtSAyTA3UuNtBc1zbSnKy5WbmY08vJvxpLB2dZdysiOafO/
kFHpf7LR1zxBM5XuWJjmKRXpWozACVSPMMPgybfiZJRJKVE/xgJ+B4/0IYY6pi9sGXEkgn/TcfDE
4z5V1j5lSB3Z+gyt2fEJcLmr5At36mSqPY2ZPCn5ajL4huO6IaEe6uqOtGKDoNFlUdfMIBAu6rz/
rkmGL83/8lFw4SlrgSRp3Jnuel85HTzT42NKzSrf2pZsGZ/ADGC+POdfIs6rWQVyXUuYK12xPibu
l1/C2J/wpaZgXZxHsZNmMgtmYdY6/+PQOXniyylp1KVU+AIwQbZuYVW47erBS5zX76Zo0Rbl0cbZ
DON4W+Q8FJ/wT5Cze8W6/kbWa7qB6VCoSI1PPzLahNqYF+9g5/CBd7jC31KsRlCy0/AT2xClGOqO
FabPk+qO3Lqoyd4tQq4L8OE0vN2fSTn4vKG5K5tk0C8DWqfx5RSrIhW1qRlgtYahE8mpS2pJm4Y3
sJ5oa7IVaz3OtQ8U/066MDB63CxfqF0tEVJfGmL2tlorOUcg/KwoE0XJM+GBiX5BRyIe6ZAWoDP5
Ra60Bbmk134OLuMMs6hYs1EJsNqWJtfGbWJHeeH8u3b2OKQYKhoIPBgYrCBVTr9nre1CxWrJcGOf
xCtUFQtCYeGZ5l/GQkmhWVk7CYdwyTc3j3Ybdlexse7gAmHO57H9HHe4ipM9UDmPSeJNVWpGIsPd
KcuvPoUNJdFfltoVhOEsvzz0MHk031BHUZprn+/nXHmGvbEnUZ2MgvexgxOM9c511hl0mVW8GkzQ
s+5do9eJmmqFK9vdxor6SPJwRJc2dalxQfwCwJ99AZZrdh9oHQX46jdl8Oi87gKXoR/6Pt0K707q
122wTxjl8JolWyhrp1eO8f7ZGjlZ30m0tlFW20yjOvHNC80I3cEjE8CMqfwTlPDw/hYljLSZ7Lkk
kXyxoeXK7O06pXF9ce7dU+bl7Proyfw5eWYfizm1TvyQ1+68MrDoy/eqj60andcscYQWq77ELs4O
ieTA+pQcK1WP9a/jYsF1ePctwpygIOmD1GECIveoxUi0xd7xYswpeDKVVwMW7lU4ZfK3innfrUZT
O5I0Ci5R+71ggLC3ErWqbArS+AoNlKCf7YI9I2N+DrVYQ/GyavVZF2YU3HIrZ1qBtugXAEHjABXn
kmvqtlUEspVCKHfhI37623iCUAZFLp8PvhljcGXdO7I7yA95q8jKzNUKydBgeXIFkDLjvbA0Kb18
PVwswyE32wch9aZTvFOtWn9UkIc7YXZTcX5+1OOMJE755kTPVFnZPuHiovUs1LzhybU1xsGke2r3
kiA8fnPb511eHo31hMHTeQa0M5pI36mtVRrk1IcVZJhtbgNZtf5lRu5dM4tHfsFNdSyvvnCAz53e
0/PRnpSjnpogXgV1F+8n6PKA2wgVhL7JXBYjIOKYrWg5A23NqFIKB8sGlpEJuurkhX3H4aYoXfz4
NJX+FLW23RCqjGG8uLD/2eCRpEGEf6w+JGHVP9piJ8B0yN+ZQwuhRNrroGpuVXCRaAvPcpp0j5Xy
79lqNtNvjIUvTOT/xUDhzNn7WijcGafrHPI31ux8npGOfUSV+63aZ0GhyaNW/Aajbwt3TkyXaIoA
o/Fo9fORf1EvANV6KZMzZPHsyqd0wlimzezZecGyaoV5x6n/23e+4zL/Zs7hkOEagX9rAtExO7GC
XjUdM4OP1HqdbeljVsCwEX9T78BTQbovAFpLTYlDVFtZEola9qEUZBr5JY1ryJr2b/qxeYcW7Ns8
gHlOWdmhyj0b7SiFg2Bj5APwQU5BCCzR1mE/+erx7rOfocgzhRZkY2gUl2/wKBCSEIYrDIKfQkMq
s0UJm+tUoBmYPd2jo3QkZ8jYtN8Y5f9VmWqIbRsFUqXT+1bGhfAFyM2pJGLhVWz+kRaY+U9AdPfM
j+Q8MnrSAWPSeHXHx0fjw2YMdI9M7CDsiZhwqKp+DkcWJytu0EWMigO54Dior5caRYhUTl2l6yl8
gb0nQ0lWnC3xnQiVh1ORa8WKrOmhZJpBS3MeJcv9Mfj415kG4/3LA0JBJFpq8nvvh3esjlC+5kH0
zlxwa/17Vc9CU5aeMGKfWHESQRdrjJPM65LXNdVKoHwjo4scRJJJH8B+9OPY0abWIr/axarUWSZ7
2Wh3CnH8cV6to80JmvUc+ldEg5N/SkbZs42fJjCkM5jwW1fbNO8/1PYTGYkNTVZnGQOYmRDHi+NQ
5KxcQyk7iI3IEreiMYeSrlEjW5OgHul3ulvWlRldNzetT9zYZcmGLp2FpvUGFDjRK52lT/zuXI54
u7UPvoeqA2t3S56ycpAtMqLXVSpcFG0ibXouJvImvRE6cBaYmdwyi0RvfzKfiX+ohZbc7LKpEwuj
ud60z/uE5bKa4a3ahmPWaPIUrnIJnDSOKhh7xJxFmo9nU2pWeIQiYfvea9hMqgmcIMaOY5bxwa8/
1ht8EnW930t/auhFK9e1hieejTeftUdP6y/OYEadIuNYEYdSQMiMrSBgnpaU+JW0BpqOcRrP4wFT
1DCkt7xsqi+rKxzllHYFfb9JCM6cRXeesNy5m8s1DRF6Q6yl2piv/yT2RvzTT/EwVmFtUdrWGncZ
vQj8kf6xOMzLqP0wpfDIIZpqTC8yDaRMAv2cra9qSE8qmNL0Apdgo+kPy9PD8B5S51tSx//eKzIT
neL4C2lZolhYWFF0Sl9IPV02eHfhBvdQMyxqMXqlz5yWbCwlLHtu2htDRhCLwqclT5nIe4i9GlZr
AXHUTjB4G3ni1rlyySOeefSDIPC++rQzU1R7ymxKKtNVzRbWYHJSTYGfIyVn6mdxmWmWqrJ6gt/u
Q/nJTTbbh81uOzp3vhgmfrJbaT+zGaFaR+Zp7IhdKyyM7DanZmR1LqDyJ5vGi1k52qd3fCpDNH4M
hUBmVXhzgux5NX0LCUesjjXEsvCpomBFwz/VtTXQ5FR98aGxsGfF1X15SfwF3knC+1n5jfnsKRef
32I9sbr7Hg1R/9M7kCMqIvoXf6A9dEVE17mJGo2jIMlcxzdhhMknIa11Cq3bn2FQ/JJ8hOqfmElv
iJMz/itysy1YZ2P7Hi0MRiJNiTNabZZCxp54aTRXkDy4HPqgyf7d+Cv8knG5rv3A4Ey7XMwuqXj3
aCuh5hKIdnxQ0wXqaqFXC8Qlqr6WZEdE5pVaszEXGI/09UZxUoFiqmD+MGfVTJjt8dI/hbCg4EUv
iEFNLPkL4CDRv1KzHmfMe6b+LkfefFAqJPl48lCQr0nLbJlCQZjGLyU4BZzYjVHeIAhgsFzYzPXC
ndnXcWeWLDD5AhhoCed4pz3Wp2l2zEd7kcPS7vwisP6nKpA1YX1AtxAcS3+gwh8P4D2H0z3BZrA1
oCdo27uzSLXcHJGN2TzVq20E5pK13OIcuEuSPtLgVRzWZfJcSFBG28WjnfcFvy4JRJDSt41cZuBO
27bfHGTV4qWSpEEdg0k8lkucbh0oWZA89ROSYlOQ9dFUVKVS5i0RrSizf0HfvKgHu7j1vds2X2+m
5GzFeXlw1pvZ7OefsgwGq550SIZVn857seZR434TsD+FK1sqAet56S8XDKTF/zKb6YaaNrfipe31
fNXSA/UXMNWQB0mXoOCQSetbLZX5CcvqURysVln+2Mpj+SikBm8J3sgMQ/L0Coav3yXEqc1307Ma
ZcjgXuWmLFl3cKZsJbl5//NY34C+H8911sobwO5d5+bqdce1F1owO1XE4fcPK6FSmrTPFt+U38Ax
2056/duov9Pwkk6YCn1zlbs4f4pPlTE7UgGZrkuQRzMuiIJqVGKDCqfNcWbf/V+StxuepHkWhUr4
AiyVnQ8cI3/b5I+jy8npsKdxfjVLUiPI+kfJy1ad3n9wBfWybLGrgMjvZc98aBdBY11IxLrOUx2A
9rP3OkmRhcuv9hrKQ7fGiKV9pqvVnpwd7ylWvZHV0c7qvmzDhtuldJXGnTh6Q0tub5NDolqPgj19
fQwaIjbfW33ZH7kF8kQjJxMXev8te875WzY9tgQPCd1OPOqZFvlCrbEMGpWbjiSh6x2q90m1AApV
5Fj08VSnFimMPoBfi7Vy3S/y0hrTt3wI6dfOEjMU5ulT7aFDzkzSZ21e+31F2XLzt/RJF33+gtP2
nf1l3GoXBYiZ61sgKZfZjVCFPfFQegghADBzvJTfsMR87rB2Scc1vjrhZ8vY4z2fUvl7EX9xTj8r
5wvQ1X8KQfiwFwXyfrzkjNjwspFBxCFs9R47jOj7xy7LA24fpjzoCKpvxwmvKWq0taswzHlyPVFq
uWFaQAMTUKpVWzEcIe0sobDZiPZVud7h1cOFX4IyD4pqmPVchybeuha8e9pdqzhU5Von43B5Rl+8
NY1L646KtBbg8PDa7bBHD5yzNaeL9rw4re3JPFOw/8L3jSiN80UOluzlbor8uxAwcLa1xaoLpbml
vGO6+03xxLCxeEFgmHr6pJxk0SR29WHuIrRA0YNqsy+i8tffd77Vj759hSgutplAbz0KDYVgolnC
lMDDIaMSvzZcTXWeibErgWT1N8GfjJld/UGHGTUl3Vwg/Hm1gBFR3or40BxnsgRGtiO0Wa3N1vVS
8dOWVA5i1K+2u36pl6KXxjsf78g7fNpj03rQXtSfjiXmozgyXbU+u0+8vk8N7IiKseJtKY/fP61I
8SenaTcztfBWbYRoWjvnYfJDUlJ3Nhxo2osXuuSsKhwyPS+jBCCpYqheYGdj/bptY3gfOHy3muaN
f72itFqZIF/k9KWNd0uImY6I9E8HIDaX2j62ACv0kK/XNy8g+j720p/h4qbb3vN0nWjaK+VR5uYN
Wup6WrPl3JwoooPm357kbwPwR3vxzfgVoO84YmVoVcSQPjkjUZfSyJOSoCrbFhmZm9KZ8oQsOkxw
nmWeQFA1a5vaJ9cSXkwZTWq3pAdviLttJUhSsoJVRNPb8sv2Zs2ZCJuLqXdTd3qpyVA6fBeLPSXl
XpWrkgAHoiooZ0GvMrqydsZu7/hh8iiPrSy+PN1WoBuSiIUc94lOlK4763pepiYUYeD2dTH5mb78
DiYMXMNDqRf71NN6L96M0Cb9Sncoa/je5qUNgqNVMhauyj8YUuhGjcNVdZ+Fw3OTf4e9iKV1cqzg
ye0cbT65iwnIfO8gunwGAxsG+vNYpm6vK+WfG2rF2hQ7XAoSR7Qn6n+MmmYyi7UKC1rb5gzpSkW4
jqGfsI7xfxXNyL8ue/gYp+HLYYaHQfESpxTLWGGxrYkdmyCJlhO/OSIWZjOmY+QtZdstd9JWxGNa
9OS0EWposo0txp3pljJotwMx7ipvDXVpELnVkWZujbbSzocWar1JLsuxdI79F/RFZiGUeVSk5/jV
rf5T9LryjIoDNcT57/2qZbDp9NYjCvDy841tv96KI9vupAdTqat01hpdGCRAddlLE6Z8Gey81Wct
e7WbvqDIiQ67BfmGAo6Nv0AGUnagdWEjJwZHsqoabtPBqVDTeAJfHEgduzChE3UDiw8xdMM3CERa
k2wKHuGtAtyXF+HZNMzuIBbLUWsZ/cAtHYLjJEZZSySnixwccFWeTj8C1dAl1rz6QVDQ78R000U8
JqGRCifz5bqjnmgy7w/gn7xLEbrrMqdhtRHQtGxT87c/CDVzcUgfY+/dpP7gnqTtPX0KbgrozBWm
Xwl6UhMjkl9dgxXhXf/Eqt0N31++EJr4lSWReCkD6PMNmGB8Ak2hBDSdRcfgxqCvJrDBEfh8ilUw
oICZOYlkwtnwPA/MiVHLy7LO+uRgnaae4niF1RaWxd24zp5Bq3MWGHEZ6s4z4gZwq03LHW0DZWvQ
RmzGxs5LIOnUODafqD/2Yyk0V995hcPL5Rqze3W35ik1FgQSI8fvkgWsgmxK2+1SlxOlSESAnQgU
jDAbnf6aM3B/FwfWqjE+qqZdKYOJrXgpztQj6DXClAe6oVTb35hKcka/3zm0B8abZ7uqsocHq3X8
/h3z95ioUXnDYIaxirE2FS5YF989g7nyDTxKVIcipP/hWbmWknRy14TE/V2K5+kik4MO84FJ9fSS
KmK7lA217AtQ2WAmpHkx/Pvd+RNr6blhaBg5ao9lTg/qraRf+IrkWGnWzqTjeit/XjLXnFHWtyeY
t9rmh7eEQfZhS6dP2fqULQKx/KZoZapuzlRMf1tI0OimIo9wiKPus6TPc3GblvZi5DkjT2WaEFZ3
84JxyxrlZhil31zPQ1YwE3nKY6eX93fpUa7sQEJj1yu14T2flaK1HsN3+zskgb0OEkwgV+onyfyh
tIolDbocttBTtxMNP4qis+o+8z7/DPKZZqq3YhFmbIzA7UuBBR5BFdq7Rrlf3SbXkrtBmCCiN35a
/xpRTbWDeRuFnZNv/uuS9z/XbRsloN2oe0x/A1fIA6XKBGm76dPQ7YZOFqf0TkTeJDnlJ1+94z5B
Uy5CS5EXV+mG9060uabbZ7Crme0j6EYJnscqOhGi2nPdHwUTaoamtUa4BCde/5SpS0uw2lSwfI/7
zkz4bjJPcVHyzODN4mkt87tOuKXRrnCMwz8hgpalpm8RKmKbYOZFUydk11lrvui0OGvywfKZBe8P
utupB+Rvr8uRBNo5NCzhBxIq4MrFmWfFGl0g1Rv9++MAJPsI4Ew7MzTEr3SIqk1iTRGKbhRuq0bf
+oY6DOZ0mDuDwngsb1M5+e893/a3s8DUcbnexpBWdEuR5xVUtehXrTybJ8TXook4LjKhc+/SHel3
CQXssIrJhCaVVB3FBd6dPPn7yhsgfvQ8hy3aRtixKit4uZn62C8dy7E0dE/Susgag1DSzybxIBt2
zXkhN8XlSqm7xZg6cN55XyhFvUgq1dgJ1hNPWF79zgtm5I+gqyKhZtC/jigL/wlaMoE5xLu6LwDO
XBZ2khfPuNhM6Ppt9G43agmNE+18pQ4TTUhLl2LY7ELFewwfgc5RggoFVfqOWW7PIp0+fChwtSb3
eFBZt2hkeZQ5AYrDHLltWLfu2lerhVWfc/1H7jomfBvN3ycQFlzPb+f7lAWlXa6guVv3JBKzAMYf
T730BZXWMaX9tvyEH6WkO96qh9ZIajKZ8WWTwaWXB07CIx08vrRpKmMHW323YLjssWjn2IzCSRQr
jo35VfdEQbqla8HJCnSkxpa/glOkeEuRzT6mr75bciyWYFKU3JECltFeL1w/CcJqWFXLvJasSPHv
c4j6+FyZPyMy2WUkAMzAgazoJVBZWPO3dTU3aL0irX5HdktkVSj+PFn9xbSGDJIJng3PL4BOLrBh
ZUM3W7FH52Ir/ftRMr6sikgYYoINqyoTC43sQmPDHcvBjqbuwoRAcMwQImBrqtgTnZtotCTxdQDi
LeUOtWKvztwutjQfbmMOr5EaxEtCvfCqgXd1eQCja0X6gFf5aUkXvZpPgGm1VKxZrlEpqh7+Y42d
MVIrdXTY/dqz42htMqx+nP5FonGbaNjZWzWtLe6Uob69wejcS4a+s/jOi6LVZhbdpVW3upVxMp+U
8pqBT6bUv9pGk7Y4zjuiWDcC5QAp2g9YSp88dqGSRl3MTKpMZ+RA9ycTCD3/PQyLAE1xBSjQAT06
Vtqs0JI+IRJuo/15XQqhCh4b5gnsLpsGDBtk2oEsdcS8F0+SEPRA0VcVIe6rrjqumbPtbyONNGc6
8nOMoZlAYHMSbYGMLC0ndZCaAl+WNAwWuRsWkaBNQTvjP7vQf8MG0mdCowm4VTdjwQbfzKilg201
Qu0ClaMxMtNT1pcyqQfrk0tJj5Im+4YZVWlPgRvujC4wzJf03DnSe0VeQroe+D9xYuEpljm+ABcZ
5o3YiZ836iYIp72yVeywcEKhzXniQYMykY87qYlXH7qvqN7ctKlM3m6Ncp4q5Lej/GlBB95LD2WR
er7szU2M/7JwA3zOdLwt4xwrdQpPjj+4P3WHwFBEkVqiJf86lNYKmhzZpFg+38xcj7wh6dPKm0nt
XdDVwWVgDATokBEXJ1fFL8CfmKVXvRmGD1N7hn+skX/b5jk6vQQCsRbYcABeieZYM7rtNMFMayrN
K+BGphneYRyijKH+io/Mk7LVtlRKVDGfWWff5VjzpCv8FEYm3ZcL/Tb+cDFhkNYCY5ZiTqHD9nhS
vEs8y8kDyE9PP/J1axObCxnfSyq3OeFbFV/BJzXUXc3E5/fyybG3JRYOn66povmyZmZbSBaO3u+U
2Ky63ONkaTMRYdB54gpLnBwLl9B/coOpKyeKJqg2/g5ijJO7cNvv14I4m7yWfgXGBx0TsASAhK3Z
rsIfrDnhmZZId/rh42jKZA2gDJub5x2aniQ3nd91ZjixG3dPmpLxNsSZvQitzvQ7qij/xOmGqZ6j
rcjV6oDLcphdGY1Y4mVQbys7AsIZ7y8keSnQBcgFo7Xfj7faX4xzzd6a3cFqTa1C2YhlVF2zPeCY
VuJgW8gAJMtSRcnIY60qz8SRJ7k3SDztYTL6YakDJUfvvdVkWDhhdqvAcxsv+9JoyBvp3/cb8DPH
KgRyQZ1d7VyvF3b+nsNi3f1ZxBjLu7M1zJr269StrBY+DgQy7+y6aw6dpUC+pjS0pjkJwUbJSUlp
RtZsLawDeZm1GLBa3FyojvI5WTDxCu97ZR5nIBFoq75Uane1aeWQvXOD48ViTdKI33WrLdRcBA11
alkosFNt0tV+MvIZ7jkQQALuJqCmF3Zfl8JbP9PhZNgsWLnoYq/RFi00XFGgC9Up1tQCpSz/qn2W
3u/BwGyVMyFoNd1c6zpWaExT7ohdYyaWgkcghFTkrdKNzeHKcHqc59LxHP0X8LroOz//+nn8DpDu
Bdm4jFuGMP95BJH9gmp28OsYCYCXsD0uz+RFoHVBVQxqFxSXTZNbISo0ncjbzA58qNRPyJ47TvZG
AXsU2binvlL9QXWp4vAIn8pl40ZRarZtqSjjyGyL2bXMm7i1/AKkmqTFCmMY6lful3rHGRkZLnoo
Ldb+GiP67oCOohJ6rfVf544tzVvSJnIcctxQMu5U/7G6vxlNvJGkj3bYkO8Gt04QYm2j23xU47se
JE1CexwYu5iuuFUcObbY1QK1ZLJ47kAjF5ID2ZLIhDAKLQ0nO3kdjbQm1FYogY6gkXILy+JFupwL
x3Nqa6Z4w/jqVv2Y8IdO+HXO/5G+dsGyNfYyP/URNvYnv71Y4w+RlVPbnDmH4eaLplshDSqYtPUF
bw0al0sZ3iI84jzFpvf+ovalX/OVW5vbETtyqu2aW+0OfPan9OdaLrrPfHAR+3cpYxROVH432cGG
3kjpcAIB3R90pVJEuHEjse4Rh/wXKM82/sSL9ptzcq2+8ecQAm8LxNyeuetyEToCo9Uj13jeNydb
bSHxteJxZZiJsnOE9ZSxB0dVa52/8DUpg8gEZsUoVYd++zt2dr5oefiUGAFTa0tPHk8HHU5qv8Wl
27/lH2feTWY7SQtt9qRYXTTiDuD4orqqHrBBjdVE9Wt9XzvTvJUbv2XIok5zUxg4di3QWeeOzOX/
G5vXY0dospJLr+Bw7Nc0uqYnia1xezxwl3Ryoi+2LUMYRX3EnE568PhUYbVwyfziRZC7Krxcgtgq
B3/lK8pZE2NrhbEyTG6w+j6J6TTs/WFDJLC+9mxKJFG9A1SYSYUC+MvHIjslGijQ08tQNJRtqm6g
5pcFWG+GRwtbp00I93dGfzBIhNvmE7Vkd9g94pcW2ENGRPfRy0VI4x3bLFb8ijKr/hduEpN6ROpA
sQYd4FEAhsq8m7Adu+i/3Sj1ow+48Cn4kXUsc4QSk+lQZcrtK0GdhZA4y9gzxcgI7SK1xTrXzpd7
9GjbssnuKFSaP2XmxGEfmjyIIfcL9K8e3CqcLgxy0Dm9KU1hitIVWIr5hTipyDrjNhjAd9A3Zdi8
yHyOY99Vynqh9Z3zXaIohvqaUsr/nwb4jRf0A//iliPb7Q396gvg3W5WvilDmlI8ERtalHukF7px
TF2bH14hQUWLlY6K+VAaqEpbCl0l04m5K9PIAcCmzlINj+GRkB0w99xL16y2K15V7BOrUqOf+1OB
iWgtMSVwniTIc6bbeufVYa0A9h51ndH4L+AkOHhVJY7+/Gn8PUB4oLaAWjh1JI524bC7IiSzGP69
kouJJ0yw/Db7kUMb9ntQkSUWa2uAuLytFZEkbV04XkXIKTgeGINNW4c1gR99sHDEqlIHGfo7sjiK
LISbvCQO5ncZ0TCFw4hoZL3LF4BJvSH8oSqpduw/Ie7IvpjZ4swS1p1r+0+ILc+0JxfJEWV1GbA5
rGYlsKgH8MUVizkAs6pUbLk5QNBYQi2QbL11rgbwYVOSSGjZbBpH3mHaxO5OuklTUBqWoGCE1qoo
TB8r536mUCj7aZYp3y08waBaiCGnEh+amFKchFtlCmnNVSOFed435TKkpeZcpXfaQdXcFEvR1gRN
K3w7f6J/MUTNmqS6DtTC+U4Q30lu6NE7jiKIsDNbPs+ngHI7L9pkO7pp1REQP5j3YOO9NJLjUTpY
sb7NtAbGqGArdW0QEx5ph/9VVWD72EUxoKRBmv0WmLnacD21OdpCZmbUFBfPDghgbloEu3poZ8+4
pNl7YdjluEsWm5dell2DfjzLUhg4STKrnUtCtD0it7RndP3wcSjJwAkODsXDe7eBu178PIwe6Ksb
3bl/nV8A1if8Z/Y7aJir0MeNnAWIbVC/n0YFeFHWf2x3oM5VEbG5t3GdCrntBNkQZMnY64PpU0xU
5yET5fes14XdFj5/alXkoYE/eu0JPVizZEwHfft+ChmpgbEOP40ENJuECBapY3mh8XSEjoV9ThTI
iHi6Q48VuloizTGi7pj3+sx9XEcr/akWit40U8fIG+nL0v95o8UWa/GlqjGGCga7ZJPYLOM7puaz
vYPXX9SaB47AUbXYl7jHQdqTZCK3T+b397UCOlDErEsdPt3M2vOuBT+FmrM7KEZB9EGmhjIq2X7O
8zfVL7wG47o5cMHHkIMavCL9nhsivI9T4gVnXE8dGz/Ko1wbuAHxrNnOYzVcHonYDAQsRNfOeSCt
rZ1L3pnaL4BhcrFB7JtOZxef33GGrR3TmsLslTMZlKDpSIBs4pLP2TqPGVAgVc4XTN4hWPW713mu
zaqlW/vnEc33VkgxApMvQKDf9lJ58+Lc5zk/vQs88hdgueJ4E8us6zqn01DHNp/RItHc+lPZa4bn
EdQO4hgE6XQVIp+VEYuofCbCAeKMQM5CxDfQHfI42LMi883j8doYbT43OtwYo3PY7mn+e1407sDx
ojJar9qPEcLyixpTDE+bi6tF38MeIRl+0fXOchLZrdi1vzMlVWCE2CsFclUNL6feM9Rur5/LWnru
nZNSRY0kx/Jyb3GdR9Ksf2GFS4R8ou9jIL/xw+93RFllUBefMYuMM3uCm123GC2JSdm+43IUOY6z
SPrx4R/N7Ssr6xAb56x6mN1QRMo4MlObe7hbKnXITAslZ6GtPs+t2rt9Y0uohKSggYrd9NH82Eox
Y1xGgyeHOBe4Xpf0nWo/MzThKvFxjeOz8jWDiZUGy+Onvan+p8jAUruY4sRNQYRCTnSo2aYPdPDo
HCDQwEEjesMK+tc0nxZMzYDZAnNhELOm6ndv42vhDw1QgWcDMhNmSnrDMYnQv/bHU2HEvq5F3b1L
uT+U7D3ns7qyMjoQsqeboEPjQcK8Y41r3Lu5an0lznmHtKQZYd0wAtsc+Og3VbUprnLx8inMrXvA
JxCZv5kKwJ0pm4Q5R4s7bmhdUgwFtB7GHOJL4lC3jBHJI1QDYt0N0xGqNeJmFGYoYv5hwkxuy4eB
zZEuzFEnxTy1LlOGjHQqRYxHBLgsRMmrqNHPQ5zS/1LZSq9SVYbOSnYvZu5JQQGyS+M+elue0rFq
mCAilCFaV2ABVySi/JsLE7yioiPL7B1uD2jH+kEyv6LKz3eyg6DMSbybieBd6Amkl6tA7BYND87S
diWOalKPdjkLc3X6Auuc57rpy+77l2C1mvTj5wBZzTnzz6sTxX6XKMMANxitxMP1OhD2vL4bbjkx
mEi6xJhdV+uhXGetdgyx1lkjR125r1IOP6JRU8+6XDsyIcFVdTinb54bMZMQe1gdPqHV9NiB3ieV
DJlrhJHZVdXQzAT0igeadvcv/S8D6ao9cGZw6w5YjoZGz8rosND+14AzykOj5+atASWGTcmVvJWh
ez5EROHE2iCe1EaOLbVbULla5FnsCKOIjTEUCrC6wKtEckbW7qeq3lEqDz3YRh23mNUstLr6W9O8
xm8sNhZ6YGipYhFiNaOtg1/MzqaAeDBpwpK+G7jb+NQ1FAaikutp+fvILAX6H+PYjYU7G1W+XljH
mOLMw5RfN0OBnyf+KzWR6zN8D0153qvht4gfm7mLx8qGG1EBjYdd0ZcjKOx6j3zNe4PfdVZ9e9v/
S1UgqfqlM4uY/Re0NhWWOyUegRu9L8AaGtjH0foU5RlC8/7FdqZssRkB57g9pf/cWWNbvYuxwSva
ABZzP54uxcVeAc+tNon3Tez+fvO9Ugnfyz4gfVSY/Ji4rdrrR43AFbfznZL/A1LiBP9lfKLPUVR4
uca1NIns/b308uCa2VS3gSk0GyEA/LbYL0GpgtRwVGPgmetTjr4OkMJ9ESn7m2wHxEagWfuR06/+
Xz6oOG7WvhFiYkZTdlOWFEqZ1D5d/u5brh203uLziZm2VjK1XiW9USsr3j73HER4go0DoZ2qSeQa
rNFFDT7HHxewO53IC+jT5DwO/0Fdr6f2pFZwX/3Bb9hdJyPGIuQ06EdPfFhkJfH33Kqup7dn5pLE
WjGsVm0rH18op2pbr7+Md9CVvI4H9yzIllzQ/3J9EkBRnOdF6GTDvscw3KYX/sepgfkvOQDJZ+Ef
fk5Po5WDAPXjTQUkQSgeVPbrcurPw09NVRYnFL6lB3BkM95uKvbq4djT74eHakxmYagEHfW8BOvL
HgJQp40aghnShD2dJkXZC5bivGSw3g3GujkY9UpvnhT/+B5kui/difP94/IPcUyebs8WTQdOhWd4
wmi2iTeJmXh58c7FNQPSYtv1Z55QQrnhelpE9SFC0/3ozjI+ltQkAu+ZAdFypFVHc+aGBKYcu0OS
4w3rpW02Cf1eWYaRSW7Yzuhu3mBmWzZ6rp0c2NDn0y3Hfpd2pK0FlYHR5UcWUnCtolBKQoFnogH5
tyhHJqpQfx0FQyP8yY6gbS9rHQzTMiKGn3vQa0shJavidKEnudqEFeJjO49YtE3onpa80GW2snpA
0Vy4pxDXtNcqoxnGfkiOmLa9JrMbEQU6jt7GWDYoP6Cr2GuhAj8qQr+PFcxCYoqO+S2KoJ+NxrW6
06ZR1Vh6tdYRmDL4E0tsfthl9aRex0v0j+pL/ttSTc4esPlb1gnXOr0h6TYEz/5nh4arVP652XPS
4M0/U6KGNAzmSx/EI3cyZRxr/jrnWBnOtefHx7ULkOrmYKUILBvqglsN66hxsLFqWz8WuoeJWT0x
5BdA5jb6mUbxTfssNqP6gnuQwQvIuS4XDjpcpVPJdo3sxYmZ+AMke5nb0K1HjuP6zrpeABJGNNCj
jqvxqs4XCNKIbgjyuUnSulxBG7V9FX5kWvnTIk5qsZ/rZ9OTYEZcEGBrdxxhgbgt27nH5PhmeWhJ
12oKTRi7+Vxd/sO8JZWu6O2Gx+KdgWNxxJ1v86Elx82j9BtBQGPliw7U8bTQU7fDv5ZHhXzgvAxy
uKQppbtK58QjdTtDHJr25ksa22rrOqVB55P5j7aSthuYrjUkXZviwH1TD6ulZg2szFu0eucyYO+K
d/T1ECiqLnyzj+m9invEnesxooyR9c+mdcg1X2KznMINkhPw7uQJXofK6S3wEtVbCcP2DDSBQW6n
rUyLdxG7oF6ezRvQB4ukrUPBAw3Jhioeu7ilrdNfqbMlkLrEOkzUOnYYUKv5IHgWpKn8TxtbeZCU
kNBqqaOKyEdmnqKDRYIu8ZSE8UqAhkjCSkminLCRFDrOVc8fY45i8QGCsG0VPQN+xqAbxrQTKlvj
4puWPf7d9MiBG+2O25pPpIeIHr6ercedlBmuhsIqWELjSmGhi8G1LDxnE3HyUzX7nhfM6SpxA1Oa
UKHEYftj9VhT8/N680Tjyo2Bzdi6uCOdqS9hKCzaSpi2zPO3gSeJSlPMAdBknNa0szdsKc9xp1ty
b403Jcnud8qGyDQ/Yt5QD1mUSpsOY8aib4mUqicP4Y3qqT9ZkD2qUkNroltbK65rNupMN4oKFDMJ
soGAy+QFpsrQId7GF+D7OYzAs5Lam8eKuyQ1LZHLClKxuVnk38Yl0LbMG8xSwDICd6xO/QxnpYCG
2UdH2i0cK1V+nODTOcO0IL39dyBhaNXuWzeVSsntCvcTgTvvpS2rF4hI9uHSPA2dNebAUoOmnhcr
t8hxV07xT2I4lSBFwNvBMtBq900lX3urJKI7V0y+PQka9ck2xcBMZWSmqU7/V9UaR0v8GNKcvhxC
rMghxG69CDkEcuM2pSQFpsVjA3HV80NFl3hxgJlButQmPZ5/aFlvT2PXcsiqGSHE4IGT4vZNeZdC
pUS1YUbBqEgBrPfN9k3Zo+RsNL2ovEpkPKJ0woQaFauEAv48pAV0LAyPKPuvmJl36IXHN+Xg6HvQ
6MMqpjF57awEJzY7IhP9a8CD+23rrIJ+3CBfY7zQGOnMUxtW0RcAAWvAb7D1BHxbvj6kdfFfIsr6
fP0CnC0WM0B6Mmg5sRPS5V3JBpMY2lhcM61VeF0xmqh8ARQ8SMYrhBrdB48y6j+f/nO3lZznc3k9
AVCKAzbDGU22tl6IBCvF4BvaCtP5pvqJjdGADdEPm8gq3oMkzZDGul2Zd7piC2q7FZkSHaJZsMDK
W3/Lb6ldXb7YLpBDpR3XyPbpmO/+P/rYmGL+4Hb4bTDFUgeTnlTEeaGIMgcFHKVlzb/kWMFmDSJS
FY1tzfSPBRVd+5KRbp0AVmWhHNT3e9HnyNBIdsUyr9X6e6xvpzhln7p54809gzbdVuF+NrykDSS3
W+z3+Uh0Dg5G1TEaGSWC2plrqfysc6LqxW/cVliMlnqO5Xpu1tKm564axebFfeV9C+b42W3lGSHS
+nFYjLxamBuRqd+/IbZhUPgPT2+o1XyeFI4B9Gc9/dX07tn10jEeONOEdefzrvAn8q40OZHRsMgK
45cYLcjkpOkURNvmZeRkVCGUFP8ze4rNThuqfAq0Fgz2KDCua+YhkgxG0301o+fGT9SpivS4x980
DtMzw5jEzbhUWmtsFhsiMDMHIz1UovHbYQsOiUU5yTmKDZKxV6HybIpf4/0TmiWY9vns10Q4kGba
TF1sS+ftmM4FGJjzCwx9MuStPOGMCZ1P9IfKKLCKLGqbm6MzXcFHQy8DCX9z7+NnQbvuzYsUn+BE
lgZ+bJ2+l8D+Uz+GsiACOSZxpflUaIuQxzGKuIewpbacHzpRCk0JJlEfTFkRvR0Z/4Rl/zH5Ktj3
jHvteqSuiejXahIublj/85VxJmoUoNRjG6PfVWXBE0yPXP6cmqfKnTiMMEerst8/hnF+zrWN7bnB
illImrSj2qaGd3cS2xeEkfoRpXJlV6MJa9Qo0RxWw0KHqb7wuGabiByudoHYth8DJkQdKbmhzsGK
eRza8TLe//i05TtTj7xTeVMTk7d4n/x1QPhQeurdlZkyKC/JBhn4r2ouPbKmHVrLr/Bk6Q6oy3vL
xE5x0WYK+wL3JjhWK3jnfWOgmbdXxWBLxIVBNG13sJ2N4teTPK9JCfxb1LPguNs0QKljMSP6vdxB
gJNizBFTgmDa4oDl5Co2xXR7OFXGr9xAtroXGF1IH2ekC25cTl16xAOnqxBQ+TWquLkkeO8P/pRw
OxytNqGZjHYfVjaC3fS6lsRz5sOLj91aATXdEGUyFzHaUjRvuZT9zp+T2v9GW1KfkRK8Tj3QtQ+b
ZQ1C0fAVduWfGQ8JiezM9XpFrMf+s+ZfUibhgq19nOCv/x0xd2NpK6VSgubxjwyUHOEdHPKG+TFu
ha+Bm6Ntxclchs5+iJq70PXJ66xFWfo8u4DaLjvRwpUF8ShFP128c0LuQofjn+q8waStMb6IJ8Jf
L35VYgHYJ7fIKg1vDgv0zn8DdXR/hJ+HZjmXGsBqMOr9cvtz4RclRSLgr17Ad+BGRL+UUqJQteGX
C9Eh7wCuKzXoQuW95cb8V7xUFtIc5YehEXkkvxOq6vxXXWwzfdShS9jN1uqxASJqijWRH02T/Nqh
hG9kHAe95t9/nph4sbbctoXthE0HbmPLVZbgY3+u4+cC069NhsHW+XGxQQTVfJKs2JTaTuP/4rJM
fqL2ptNsNncLsk79G6YaalORNMFlpd/RI4muO8gNeXjhjtm9k1dR8PQp5PJXm8Oc3t3v+pxsc9jz
AL4xvXRkJj2Zebv7UQeBIguBjOF63v2FpxqNNBh9M56ZfQOUjkct9xnhx4TcXYMWqaZ9S0+syQis
VK4fo2rJV9mqiQ6GYvwMBogzSnOmCz9a9b8VxJc7N9ssBRZav6aWuEJ6gTDdD/fXnJ8xlHXPUvFb
YuzLNkbtPkfgR0kCOH+EcTL9kF+o1Vc0C7xAkgV37reW2JcEjfzpQZ1X2MrBZazisVtPSlVlH7Fl
3h64VrIAjcvc2ZGgxQ5Z9dpUlJ5V2O7hOpi3s/+kNLtX0wOBgEtL3ntUM5nLsfgcULCVAgVmCXGD
HUXkY48BKaGHT8SLWcwHpmFkaeX3NWtLj1MgU7nOYVb4aYJPQ6b1Ob59B3xhNn2uu7Z3cBXKSGkZ
U6gGx5obVx0lnaR1ST5kYmqWqKgENbA9P+GliGOc9vuruKQ1B5IIcLUUSmkKgFnEkdwE7w+UkKR7
qYKwLi5DBMDwOEtgwjtVQJQiekdaIyRWS9JDY9mQyUucmSsMBmxe6W7fMIE3qsMXElTDdcs9mDN+
PfwX13Ve54XWzfn0yg7VM2E5SeIHAvX/crcMFiNIO8Zf1w31SpDsqgsUKcVSKLDpcTClTTmD1QwT
CoFLN+tFLzJtsSWiNd/kwn5FCg57+0XatYpeaD5SuCuiwUmoPCMevGsAqX+Ga0MtQy8b6B91VoDa
b4vDJtVel2Q6U51qbfldU8ELizr21IZHraWLF2DIuUquesetuaa2atMsIKqyDVejo+yavelKwEQu
PdzSzoUdHfxQ4kbsos6Oo7ju7Wn5JhlkpUw51BeAMTWJKHopJgz0c9TmPs2n9w9i6Z1VMxnWKl0W
vaZ3dLccRImNtqeJimMV9rMllhO1lKjZEzBtg0nJJp9aQqPXMXlpE2npiPI4tboibkpXzSpzIg1k
wmUTPkWFqSlOFyxBWlLOiSguWjoPAbx5KL9TUmyScrJ8zOSZAmaOza9Haza4Gqh44wmOpqs6q442
a+cCk1yMB7Kr2yuHK6DwE9JWF36VZ8ovQESUBcrDyoyCFBjE9Krori4Jq9HeixxVP8KOdVSdM//d
M6nC/v3BkYErxSBzTFE/cOBewKGiJzV7wYmZjafDjPl5RPFu2vHNHvabeqtcBT7voVOPNgmXoC3B
oLOeBP+p2ga9X/yl9BPA3OIfnCDyr0SD/holYCVlFFKQBro4Rezvh+NmXeiIB2TEgTnefXZFfDau
NBIKq/lmLmGYCPTFJYUJ2on9cmjn18Wr7yNuvKUmXvaPnvswWAbfePdLkRlsE/QmCqtdC6JGv3Et
QUNyPYD96bDMYhc4mhoXkKvqv3USVHAq0J5UV3qhsJUtaFxhNBickXSahFkMup/J7XVLfstgIo8O
Mv7DkKcWSfCX0fVPZKOVLdOGz6J2jXMfdTn2mUFc2LuaVQmwMg6xM+zgqZz0iEQp6YKaMma1PqdA
xnEUaSHOzBl+Mn40eDEh7SVyQwljHdmiFlolmYdnfz6/KvM4kvGBlnwVMgiU2ClSyp6SOLdD/dMB
rmY+bgYrjY5hOQ/k/fOTY/5g/nOayb0+ysFzZ/+uljc71BUMnSleX7sL4nywTP+W2sxaetP0MKz+
Rrj8dGZOCTRYd3gUyjlz7Sul6mrbGu1tI/OIh1X0s/FhYlP4od7Y0+mZgHR82cYzdiotgFhVs1+f
voVKmxZCs7WUPc7iWcmVi9vZEVECoxZkhgzOCX7nrTm+wP7bG45XHGU+dot+dnc8D5eZdpGaUBuW
hibkWzfE8wLxef0FwFdkaJsd+ieEm6blk76lEQj6dG0LoC+p+qeFbyvVHSx2zEC642f71+4njfYy
tBK8Ztghf5qDUo9z5uBNyiQTsEwvTCqVp9erKXjhTX3l7+CCAPsjstDa+0Zx0D5SJZziqrDsRtpA
5n3dWj/VdhZ0kQvqThyFQKSBPeo7eQf8eE5RNlrCnUdNC5G1eECxXhWYEodLGmGrTRWnfQaTE41i
Uiqkxhw40SFO1JnMxr05o8jArj5HoGD9BfDB7B8RVbqulWpvC/LxExvGw3frZXvhT3aQ/wKgco49
g5UaGrhiLNd9VxppUUhs0S4yw3BTzJJFDFK8HYzbL8ZqKq/6tNzjqwutS6iF2W2C45snfrIf/hbl
B1OcGa6zhpJBz40R95fYO2Ybt2z90RhMlkpfe9Y80i7KlYEWsj0PZ3sQGgEN7kwpHmwxGmNYQ5hs
3s0QPyzNkG+ceLPrtWarnjsA4jo7WigXlqYeVvNT2KIg9M2uYMCy7uE2Xtk9SAs7jXLtZit4LX/A
VxCvGnJXqIarYo2yGWonYyRX3lpVngHqfg4DCA5bbIPKFLb205joPNUTEXZlzTdiF2sa8w5GpHHq
eJ/qmeI8yOyibYt2l5cJ++qNJDw0NMRbGWX9uz5nUyynKtTPgxf0vA5tM4RLVyE4fKgRLFkyaGY1
R+D8q2fN1JAqrphdBq9lE9dyrASjt/b74gWRnQdBcj+mIplQvL88r/hlmMgcUfi3k05w7TX7ez/r
p/wc6e3IQMtUKCJma+21KNJ1p4+ONJs66jmD0f4c1UGT9T/+uMGbWTmSRdbsI469nQd0LtXJ2vOM
sK51e9MZ4w9vTqwz2pj6GmFPysPvoCweehTonioxHniF4V4tJUkzjicPJvXhcS4/8x1LtAKXNSWc
pMZxzT/oH6ZmwlDDGTN5Zu2TUVkIvTyfiqupvZ61TDoJzeOG3DCvmOoz71HRZnaBjMraPyNo3Wkc
DTNmejm9dbpIM9Wk8CUdhKZZaVxWjvN0K6js+24vJaiUaAmyiNicVUwbTNFTo9VupOFPBqLV6kVg
MNtKhpURlDAhFCHTQ/dyYSCAK/liqpH6yjAAAfVIukh6jdLfuayahVgG9AfkFWQ4F8oYU7ZUze0q
dztLbsVeIJL6esBRufjSyH+xdUKidMwE/oR8flkpOZaeuz7B+0DFmEEwEyW2GTUe4kxToeCBI1cc
EYiQet+Hbf4aeV/l+EB3X8vZpNpQu6BVpJ3dlydbYaekOmVy1mLrQQINS/zQrh8XsZdDMBmTlSc7
hdxIbIDX0xuj6ocvf185J+fx8UQSUY6/dx4wIfV+GogTUG/xeSFOHcNymleiZjsx+18E1PfnJLDB
2RR4ep8ixbbnXG5WSZwC2yRcMcfpIFQ2GGwEeCfhYaYeei96RJZ4bXbcKXOApOVNZCMSc6dtqF2l
xewqQLc19MgPlttHNnOQGbM6Y7fGC9wHaEpBbBSwlYboDFr1iRujeb9tmQ2by5w8q1sFlgVWKymK
SzjWJgtBmCrK1lyRurIAurGnEK4cvKNK/ogsXeudD1tDPnCd96JkTXqzGR1qVomqWbCW0IM4pRnH
SrV4cPTfZl4oC5GizMQIZfX0vmKJCnODooRIaNXkhSUuHJzh9xSmxivi334KWqmdwkjhvbu4S9Ce
b0pZeCRbDBcXYhKEh90xGwmyo9Vm4e+fGSAFfoUFmhhd2o0iQmYe6DdVT52azJtUFoVOwg3YtwLX
aVeD0CoKCWfTVJKbvUZwHfjJRWkqc9YOftQeVS2EZDK8ZnEMJpDUj12dQGYBkzKIFz59l+8zN2X9
uVCUcJqUjWMKnhHWOZbvE8sdWZLAB5me/89MNpYoRdHjB5Ct2sttM2UBwwu9Qieg87/t6GrLmWWf
IcvFHnxiQBI7IVUtb3YYVERrWHy/g+Izuw80fcPO7KvIAGGOwnJDtRZ5TNEUyBCW7tiIw9NlP0Hd
Vcc1JSjiyIviVRyJOXPZ2zHTWKJRfxQxBWajqsWmWGtPm3gFhcYI3cWKvVktVTybNEP5w2S5DOG5
JvYYem3GrtTsawZ96yXfVlrpsBiqpGG5ufsCYHuN4l060XZcYvMAA7/FB+gW3dULnnUvNs0gr84I
ZldRyBB6qeHXJ1F6v6RXdlBHmDgXlawPTA/cjVMsYAzj6znxFPGXQdTfc4y0J316C3/c23qM8DHy
CZXeDLCEiH+6TTYsGchSs8tKbZvFeXek8qUlMguU3cZJzZCEWFa+x8yoGDbvrsO7kcD3JRHaJyp0
R5GIqhcdyRw5b+iLTY6ubD/9pslWo844sJ+Z8F52LHj2Hth9kCnbxF9NxCJIALvACSwiK86ItLc1
ylFbAok0JTTSf9BkY6gtNMWq1JRZrOmMv5rv35ZGtS8TmDvHZt/XXBnNCvCWEWRp3M1Z/+WwTxob
cc6T1SNBAs6vWc/bGT8d1ApZ4X7S1+hF70pMXmSzY2znAgtKkvf549prReqva3JsUcoE981F+am3
vK0qwJwztpq6qjP2H+kvyBNWQt1sC93puInaG7q7B38GCFIo7Wfaim2rWgh8x3ScY7UTIi8FvHMN
SlNu7x41Zoiez/SHe2dK9QOGurgDWl3fCvm9NVzy6fROMdZD1BOS6UaVPWfmSmVqaohaMjKKTzEE
PkQq0UZqopW2p4VStp9hlzZ0bJLk8jYHb1sJ0gTB3Uq0hGYbBnqtaR3ao8cOe8KEyrp3E8AAX7Q2
q5dIkooTA4UvQNgFhe23kxp9XX1+r9hBRhzO2TMEK+HgkrdvwweDzIsWhpWCfgrqZvnERkQXC7Rm
sUBI1pffpvTanyvGyZXyS32H6ealV77mUJq7cyDKQIMHPQsgBr9vu+uzs4HRH+Pf//DP2Sy1fVdw
GDZ+jVY43xHNCCd6UdN/4zf7jSqcImRdFpjMJ0OAltBJuvNq2dpsDylIoRLEmCaDyEI0rQQyuClJ
VrFJHdfvwN2fSfcx/lV5OO/UPpFxJdDLVJxnQvLrGIild2SYUfvzplJnuBQY4ejYnEmsI2WH0vNw
fAOmnjsjYFFLFEvkedgrVKkblXHoRq31Brg7sGl/yNC8LCSMLJNe7DQaoypdg/jtyfd4d1xbbZJp
lq8Qk5uxopdDPRXH0IocpVTLbnk48WINjyOvfH2sE22ur5Dr9+N86JMC42zKKqyXsJ3Gr4tj8EQP
9R3ukqMD0L8ACK+LtyGxovmpnJq/3DTfSpJ/b4t5CoeQM981udUqpUk1L3Iwwc42HitANbkcIyKZ
PVdNZw4YNcmhw1pGx4tFf2zcDXPFV6sySCIQasRRhpIulQYWEBm+MLVewFEm/IMQnisdxhVhEeYU
xjsxYPpMKK6+sCJZS9WIp37kVUvSS/RkUAy6Oic2zzVdf8l68m0f8VZb0eShIl7olKphmOO4Apws
YyvLPqlV9ZhT4BFIOdrUcged5+c+Cl6QhkLn+Cle7RQzEPuro7yUaFB3vF3BVRroFQO6HFFz1yMg
RD41iLvzh4ulzNi+n7BdkhKtUNRyaONNpK+ytpkJso/4p7A0ta2RjCUB8Tab9onbh92FmFrm9+rn
NCnpvwDm07vTbPxvC7nf042UkNgU14tCkvVwQ8G4As3YlHuQGH8xRMX4orUsikFDxF5w56l07F4Z
V8FzdQ/ro1dXpamcaxl9T+CAkd/1ifQ/S/eKRRXQJ9AiuyEXaYet1yObfs816y6G4tiUmBEfQ3bm
/FAKH8FbwAf9cQ2kJkIo7VIj7lp2+HXm+HJEFybfKjwotyaBPo1W6LxWSPqq5fLK1PkaObrQ5HkR
qp6kICOtm/1KFMZZhRp+aaz8mw5qqZyDhuNwzqEEYtaTJlhXW0rJttprDsaFRUs4xtymowId02Ij
/0Y5iyEKIHAIlif8AoQwjYMDWkM0oYi85w6+Zfwo102alCzkxmZ6CkbspQ6mOxQRlq2gDuP7AkBU
WJtLvTH1xpGoaBxGjn6spuYxx9F+Qr1o0DWN4TwrMEAQ1vevSXCKqcfVV1A1mT9UOsTS60LURCmz
gXgHFxjx4+FH6alFFe0XMbArILg0ohxTKmv2M9vtx6qCqSU/mvI6+yu5z4VzrMlRGdF0PAZflxpW
wi8tFD2rwQJLIWDZKf/mPzE/izkyijnTLzWLOZpCixdkxeWkgUiyGgJzqrFNs0h/m7JMQFSdWJFh
sNVFmhFNcpINm/OGx5x5HTH3L2P1vzYOTP9kQ6l7zF1VHpPQlT3mw3M0GuGJTPNU97Kl+TEb15v3
2PjovUWJyTNP5Ob/ElZR51422xUUQuC4kFP9hS5jmUeekDCDxymnXJ/kCNJfpzzBQ6R5eyaZmKvW
8Uy8HGFF5x4FdcHi9T+U/eNOdTaYcHR1oHoD3hY5dY1cusC/1z8vi5afpPrjR50rIc4IzEl+msV1
hIAn/juIMfpjaSNr1f1PilNHyKDbWtH1yOJP0t5k0R5NclhYgUdBuLuatyEElPQq2pYG81QYYsUh
JBmlLtYpfMuYwq1/utYdIRSphhotO9hbKAhCC3qTc+CczTMcDy3TwzE2VCNHmyKvciXfIx3t+reu
x0fIjjhCHfGiU+AhKWJkTBMKCgswl372Yn++6exZJO4CzSvE20X5C6CmwplPqJLvraqijW6tbYOj
yf85RUHmdrsSuPIFyG22JLJ8XOMtilnVNEsD15ZPWb8LIzC3IsrgT5ZQvWhb1ddkGcyCrqqJbyh+
Jht+pGjgEH3QJ9pZkX5SL1AiZ2BeGhSn4IGXioKHuB/rvBCoKTZ7cYlcl1rggqRzQDADzX/jJln3
s814Ku6vwpZ1Q9LyHpPxXHpkcC0Bj1PqxpdwnAHVBqcOlDldI1B4+/mV0PUz3d6cZYEw2bd++aA+
aYEFoihvfL/HYMw1i4U07BtRzt7NNyEWqR4GKVQWgUXXmO7ekVamd5ly3XVxe4JAQho6sPjDlXZN
decti9bdiWFU4T/lM2JsJArRH2uoM7EirwvlnZdw9D2UvbEyJSjt6aaicSk9hVVTe99aU+kCfoEw
YPVpTwVtJScG5rc3DcQJkFNX7/CjrhAEi1P/WcThMH8nPIbOfS7d02XntHd/0g1g203yB2xExQIq
LroUAuyJsm2ZJTIm+Tv9bCWf+l10JNgFFyylfzNhszmfvai7+yPZtp2X3P2WG9Bkj/2GsnohRcvW
ZEi3oKqz7cKdN1GFFOSfArNV7+p/01XIYvbWiQMVuTrfheHK0VgF0QK3dvy6KOgomiSeC2OppWUs
inuSG5oT4oKsNsTd0YQ27GJGzhqylk6Kkr3k612y2N25TpGAkZ3yVNM6go29tKSJIRLZCeq3QzJ/
XWa3tTVhyhqjTGTc51dHTYpdyGyb3GUAwOGeXT0v5WbVGpyEDHeWy8BSSuLBXVf/LRWZ+Y3DQ9wb
XtPZrwvNF7dOnaIyVe2zHACv1NssJo90oWaQpxrJI2NEz3pbWTObdKFS2utBnLrmgDFqlnR7l9kZ
UGCo5AxLEcTZngQ/KvIH1WBx7tQfv67ueiiR0qcs1jFX/yDpH+oTffavDausKwgsT35v4ud7kAHJ
kIeuvKs47CBmGRsFUpAPftgblHIOtkRz0hGekcmpbdl1TZi9T9FpoVuERcxAdRn0kI1pMadZ9kLz
RLfsCbOlsa6Avb5vEXA/0gFUo3+mhDFVb0iFiKcFB1nSOWdR3xu7pRJzy/wNNSW5Fe5Ey1et5Atg
tS2KGUXok+B/LE98VFHKn0J1w3mw1GuZZx6OY00FuyOY1cyctYc9b+fIhM4ycHbF7axnSPfXjpHj
jQIDlXV3S4RI5kpfN4QuGyO2ZxEjLoOiMB48v8xZ4lilWF2MlkwaHR0raPvDQT2lpqzPPfXJuy12
jypBINWOW0Sk4jeBt1U09q31dBGmRDJEp/UIHFYjSEfJy/JoSLRBYiLEMP/xC/CgyfmYZeLKlJJN
Yhl7cUg24AJ53MNQMV8PtKVnawowNq6edKEx0nevarSgdoqqPXVHWxcl7xMaxaN48bdeeMWfmG82
K90a82p1bbNDda/V6Z6vrr0ImdMbZDbbjMm3irwlmKCO3bOwWIHdK7o5kQFBuQoBoxO70qFcMQLX
OQVDi5jz2KYQEMddZ8Qfyt+zb8TEU1XAyrwnzwugMU5mX3GmWVOzQKIs50TOY6Fmu+eGl+WUmOLb
994m+4+jDe/FGfQTzcfUNY80TOemhKBpPvPXBTZPi4KwyTdZ1KQAqNB9Afz5ZGvSm9ASaBn89FHt
9zrE16XLkD0Ip+V5owY8i1a0wkCyO2Qpx/z1bevv45VB/9oBgRN7GaUr6yd147fgt2te5AU/utt8
ZDnt9lBrKmjf+nRcsycLVJvjByZTn4PvozgTMY3EcJvEQTVbqc7dcUQh5qJwazWq38XSjPNzMzgi
LIsNSe/s0aetExbJbwfrXq75kJaWsmjWuHI49Er+isEeKPtndQfsYMV57NpGSV9SWY41W6Dkuwue
XsTGuNf5VW6c3/YltTnWzsVXc53eac2bvRE+Op1LMXOXuij5LnN7seuPGsx+z7tEQnxgwpda3Fkt
H2n4OYio7eJ8tdVe+yxBrPdCpTHcMA1BJKp/j3kuiEJjwauFtXq6RRzpB6y2a5GENt7fJlwSKiuQ
KY1+qZ+KLZCeIuOw+skgu2qTUnmVALHDDvGyHOBYIAo1CBFBKSWi6xqzSjEPsg63NMzu5Xln+GvH
egByeXwVGiMcciloJ/6Nf3pBfrun8vORKpW2MPLYFDHSU9WcfhwVi4kMrzKqjrBrCS95xzlzrSnQ
NARnq8z6pezPXstxB/Vaeg+Zfsiwi6sEfetEgsHFBkGo+9V/R2ipvhmKqItcKgo627Qptm9aX8EP
ZzNVRRF/qwSV4Cmgp/0zBURcUDp2O0pEIPh72ABfM8f1DmGf5IoQXx7tt4CKd9Fx0JZSpdmL8idt
SBr6Sb3VIlEvyFFmt8rL7AsglUiH+saI+lCdVYu4UftzZj7vUE4lfd5W1zzPf07jlecLgFhEtZVC
9tZI+6S8vWvwkxjn1n4oSczKw68Ecd/0C+BTYmFLjO1ZI+/eKUOL+7MrrwQJiU4xfdtdEm6TVUPH
Pk4Gbl/XyToy7fFmy7dyDnDa7R+apnF9K1fdHRPvVyD+Yx6LCy2E0tndyaYpPCecs+mToK01kfA2
cRRD6KXi4YJ5aW6Pn/Z79eRocdKym5wW3oTdEUiPDra1eRPu3Mes9U+DaKvvcflMbfMvd3xoFs5s
YSt0HDyfuMsM2ADZctWlA+mjgiSE4MwC377lIrl8MORPaHI1urcvwAbeiC2ByvU5vv8xw2P83Tjr
x8o+yKKQmj/X2XmukbijFgt4UqbPIQfGA5f6aNE+TLGrJBdG0gNA0sDAikXqNKQ5fF1xkcuR+WUQ
W3ZZJnYQNVxmjoLmDCeLgJodQquqZdEUXsWCJkmmwkgSR/I4SSaUmjWW9M+izO2/bkdzQy2X3Ov6
0YoZI1JfgFqs38iOzx6Dx7peGWPSTEV31CbLDiL7dyAyp3qhjEod4JPrRrrAnnqUqdJr6QzqMwqD
iGeJg/34KVpWe9ewtbm+OX2L+/F1JZ9DWqnh5ozDnYA1xJswiV+YhFBG1fFAvfa6AnPx0UIVBLT1
4K8MY/YXzdyHopPXII4HEux/HdWzM64WvLeg95Loj80VwrxSBuYArGHqDCsLfLbmpv67vF3kbH+N
Co+dGOp+Yy9mh9FUEh6iXtrRf0r7Kque0EYneTataczTInEfOSt7MbLtCXuO38VrjaR49aWascIO
M8OGiEkNDHGZ9g3q9WhjhCFUPZMG5fI31gem4vvl8syWipY4UOt0Rb2I5TFqlF8zI2hMsleL8Ygk
6DiXPI0GHr2nQobvG/Thmk1ClP18TPMTw0LcpJv8ZJgPVFUgCN1eqgoW3vXszgg16xvIsvVb9sd4
p+R7YKMuRlYtXxQSOr4tHBPxVGJ/Ym8Wz5RLT/ZozKQEsd5egmWbnbVnlXB1pH6tRbQGNHdJCrZ/
bLH2F8nfTGqm3gxTKrrzt8LF4zceX9e48XuauCw1IGWEkfopydZtYc2rTQr5LpORmGC/728sRT5u
fPMwFIiUIbXedfsJY5SQiGyh/5yJNX/UUherfqedeqfoc493ofOammJh4YwoTpdjTuEk7MXms3j1
3dOSSGCtpJFfhkcepa+11iYNwYOOPS1XMjlIjSkuC3D3vGxS6NnO0U2qU8x2pfNE7H8tqJkRsPvB
IK8edLRn0Wb95BXpir3Hv8Dn+Cdmw9/39oWVlQFh5nV+ff26vCmq3XR7WPNxfpuDpUHUsytmm8VR
f/FbjJa8zG4qTN5BsvT6NqOT65nmvdE3hGav6h9RpDHfKgjNfZaFK3WpQJMVuJQUKXiPHDSknO8q
ewwGLmfTIeZxvibmcAV9YNlui711Hx8mttV8s0eE6Ay4q+PWZmdTFj1KrUK9dy7bdf5v4VZfAAP8
pqzeEKUSw8J2dc9x8uVTVe39LvttskEmY5u0xzQm1NU5k8MHNi6ZmtkeEuCNvhJS4uSWQmtO8unW
QKN9F0PplpGELfTTt3aEBAOp9LJ5zO6d9rw9Iv95jfrmINoDGTKRaL14/5Qo+wopeyBnfSvKHAo1
eLK0s/jZ2vXX3FSI0oOEouvng+gXAN4+08Dv9+iImYP55lrej3RiFyGDPqvMky7OPYzCYVeHmySi
DR+83ihcMFZ9yTPf9OW4T4au/vAvk7XsbCu80tY/jKmnRxsbLfdhkxF82MKbFc6Qqc17uA7V9ow7
G1GOeTl3XccnClHD2IOiabLOHInsl+ipOz74Mr4cddallx7mGSX0CcLQNd53+u1GW3wQT36n+PET
39zYYBBvfbt8a7y9tcR3877rrugarm4W9a4TeLFeS+0rNlzbjtnEcPQYHJx1bC3DHRup+tlMh+z6
6FUJSvqkpvklZ3H9uHHVGB04cm+tLS0rFxUaqO/7juJFpsA9jH/R0+qM+ZehQkJZ/AvQqAfcJeBc
lojqTLYNYI/r4pmmb2nd5WEyDZJT4c7g6JEd+fD+uCoRthw40Pqkblw4N420tXqTd/ayeXkRAZeo
zNU0rdvTXxKUt+r3vqYR9eK3Ou8ikIfzcWcxkvpVeA1Yba+1Sg1qH2DfMn4BGEpPYP2v8KZ+WP4l
/pXHLOmzLL7rZ0iEfb0hXb1ToI/SxhnwiabHb13c0e5xq6kQiVO7MH+v8E1u4YG6FX3ShBVHUyWI
dWVeWpNW12ZW5/Rmq1reDB17vZPpOXexPJc+urQGRFj2JtrAtu16oqSEAmw0WteVOh655UWp8QJY
ZS4GhJ3YLLONCf1LxLZelJ6WAvEHeojeuCWur692qb2HYzif6GbGppXxyXiboHCZB4TXuL59U5ov
auqw6GSglFgJfTGlKLA5t3uP2qRnxZt04Ip+oODg/KWvs88+RJGr2kufaoeSreHc6jS6T5rXt+zl
XAg0WptbnZ7GyyWNRFX5oabjTz57XwXrCdIZqtwxmVG2QTdexW6uWT+N1/0Z3+GXIcIr7Bkgm/Rm
07f6AknXoOb4IyX6jbg5xquMgCqOjSFNf1ea572yPLp8s22fZ1hVrP3fGmwJVmkOXi45Nrm8Vavg
Gde+dnPbYuqe+lTHxw6c0Xi9vUVHp0Scx+Vy3C2deYwIPW/pwIFuyN+2lK7eBy9+/xQ9BWU3Av14
uOwMyt88Qs10ofnW0oKoh2qgMSu3PXtdWuLPJUbeThZs4/5kAPv6iTIqBmW9NDS/rq2Kw/OuJCw3
lYsKDWeVlRnleSdmiyIPHEmONfUvPodKMe2Bcu31RLie03O7i65099xqD5KKozoOQf43IbNjqcTB
ICnZ0zCBBZlCNx4DF5WSs8LrgjU1B5HHhxp+1Xa9ioMUUYiIK8OSPb2feUrJKRvjbAzjNUXwTkWQ
xebfs3mE/uCf2TcPW8oY4E5WNX33PNEPQrFVXGuKwpByLtlO3fE7Fuae6yj/3PtgiL5+3powKIym
JV5QXwllwlTRH0CkLfz936hkRLqQNK7ECoO+ez8jv5R+wFwpNpFksPlEI8c/ZD6niRkT2XjVkqcq
YNT8uxEz2v6Ey5njXLJZI4n4BcgrUWw4dX8HUwSefAGWqhD2+J/bMnFLSS7oYLPw2benmltZB8yj
nNbOqyXPP+ArId9UmikmOtpw95M6740lfg0O8fnm3dyYqm2x581HuirtntXH8ebTfHqTkfyNWwr8
Z7r+3HJJ26IvQ1km7GNK+CEJw6VEAEGWcZEqA1jLth9YjMpBVUrPazRaE36jGmg90+EWwu9Q1pvY
KGrrhzs5k1NGN0LX1t8EO1MVVYjhntsdfgHwfbcY5nu2lulgRlGJB3Ny83JM9U9w0NwiwO/QkdM+
WkRxZ3IqHPYyVScKzpjljpjFgaP+oq/qWh3N1a+Z21W8gwwm4CdbFOlslLDbShCBaqcYP0Et+urE
4yDqdieUk3/ejxLdlmWPFxf/+81qPS3H196RNsAfND1d+5ERzH1lVX5r359zP2PcqdElss0ujxqZ
u34mpbxpZYW4JwjUBlxpeJWgEtvmdDtm1uhhYHIP6WYsHKHHw842eSdc6a8/VD0x6RwsC8T8LJ7C
TMkZUsV8teBRz/wmIycj30RWTGTNgQg9JlohJRuuXjUXpF2Yo1CSr/dNgpujPR/OMlmNXRE2Z0Sa
of5asRHmT2vqXXyVB0IcTT2l23tVLJbLyLTP2E8nMg+hYJ4noaCmYLzeshMnmUo+uV91gw6fjum4
vrsuYnRX2ZH/mgXlFG4okQSGmn0ktPdQ+rx2tX1XHvba4X/prUeVNirE0NOZQkUbu/VfApc6kC+2
c00lhC2Fu6x4lF2jrUq9TvQMgupP+Lq+AGvYXJpLT4+yeRYqdIztSKxgkEV/Dbjk2Zt2p12yPfK+
QFmKocv1fthlv/91acElvjweW39sjHiQE+6doiMv+TYcQXodOtZpoeYN4u+72IL9A569LgK2+IFJ
OO+gsYafj0orPkpGaQS2jP0e0hDhx262lqBf8bY2h9ghkr81UvslKkjCr3hTB9pLlGxE3A3az8bC
BzMjI9b2rwCWF0xLSBWYalJZ+l28e1E7twvSxTYIc/fTa9icouc6txOrp4pha+N36fRP9PpRtfXc
oGqZmnW53U0xPObFY9vJkZI+RkEpsvAnrCGgJrpNGp3jN/LOeNinb0kXSVNAG3/sBY4hq3jKyi7h
1MPHvMf6+Zsq8fbZf2vJFIMdf+xd6se+AIxskjuCnUua8bPpvgsLP3GC9JvsnDGYA0AuWdrEMXJv
k9hgqOApjlXGMwEVrrzHM8sGzwMSspROx9FpZ11/6gUQuh/9KV5RvMRhY2Gu4oazPlN389REpWQG
03wFSK4WyUazzgt00IDSSeBs9FQ/l5VczZP12tXh3823+dHCU3h7rVzHDgs1VyNes7r2z1tejtHu
Zpq9DQUgaDulfWHnmpliljHvSfKj/vj2TJbCqoK5taw1MvrT15KXaXSGQNz+RL+0s2z9J/Hxmxje
oRfBk7RrYC5DdqtkxhInjyXPSzjJNOiMT2I6ihzspOVDayzUdOgDM45MnpccXxarJHv1oOCFoTir
unb1oa8SkaAkgkr6pkVGHezS8cs7yp6l09g11ybaJNleY78Wr6IT2gdJiHLuqLs9wXEfpul50cVb
JtaWRLGjrm6hqDtLLVLKzZV6K6hro6uzDgqSb8f4M3kJqYhKuurIfcWq+J8hTSjDhUZNrUxg7yKk
DJFrX1WZztwXoDmg6XMeV9yiDulIPM7mNvt74CvUlRjlnV/foZRm/xrPpbemfWdInPTsw5s0x1l3
GmLSmL8+xc2tw5nOJ+kCE0qvo2DM9HO/2K3V4RNeDVI90YnGB+2xGX8AsY2ykRHDur5foWDUQHbl
zV+fZULAdudC8BfgrBSOkzwXxUf59wPJs8y50GaR/ysFtOZpQ4+QhX16X6WuYSvQDLZJ9Rf6hGvP
dyWao1OG1KbrzeEh2QtK5aYiluI/wTR1r/PG15sHQWZ0b7QxQWlJIZsXZxrTfed7i/dt73JE//J+
ia228pO8AFsBqCO5PWTzZZ9TPlkhP5AnsPcDiQOi1tqOrjePc1v+If2uueKHm4BaFkpW2q0q15BX
TINYt7pscNoKzeNHWwoYULLlXdoDFqn8mHIQ25+EapHQVsJai1FTMPkFDbluMb6zT/oLXOLc6Kl6
SZsdYZooPaK7iTpddYn83dN0d1G+EQwly45kJ2T5mF9U7Oc/coRXfeAWzQTOrJYUj76vwtYdic+8
MyiOcsRtZRh4L7k5eahR/IG0lXjkgf0v73ZOEfOTk/udfDmKVj8Jj6BrR0ihp1cW8C+/qz5YvXGB
qge95Wm72V9D/PVOYb75uWe9EqGGcJipawLlMv0iTnYga9CD3uyWyEFj3doaLHmJqpvyzk9PGcqb
ahlu+dOw4qHwkfJf7Y9fb+uCQlCV1c5gh4FdAK/Zijrr2dJSh2USplpdIl5EGlGa8HgdhmhO09IC
949UBALXGcwpGvG2xW00C3UryqNME1cj5QUQzQ3bZnVGoA58/CvKQ84ef7pDM29pqBIb9wgy3w/k
TRnKSr2JWHIPealxVtXe0Bo5STJiG5npm76+U+sNIJ4H9d9CXI9L8Ezb02O5VoKe1GADlhlG9WQv
BX1s7qLwO4VjU+m9bYjBCMQyyb7aKD/uLLbhn7iRauajq8y5uME53yCp25xndYokTdLrjX2PTIWG
2OiAqBOl1E0EdnRqjga9RP5lKcfdl8X2L4Am74/YrYFmUBdfItIljB+YY15aq34M2CGwXA2J0n02
ew8iZ+LD0iDhviHxTh1UDB2DLLw706q0UA4ji+0MgWehW9D0gNbqjZtqSfFTX47fKqV0jo2W8KFM
X1k9CTb0KP+nOiVk/+nmQVl/kXeigJ0wRp99X9VycGlUDuK6vlm7gO61tv5Pl1njwFim62KoZBJp
v25q9mHh39m8FwvYAwb/HiesIJ4xZM9WH7QCpN25n/xsfwmnPU3T5hZzKEiQks4tMaFjqkiQ/mdr
MiFTrjJaD87W2r18xQWrQYSPO3cGUWwePNUKUqItPWnTVmu8cDfQqEsdZPUS8A8gcn8i38azQM2A
RrsfsP/KxHNXsRKEQ6hi5cXfRiPe9rOhtq+rXzjk2j5tZaiSjldExNoo96oVCO6ejRNSjm+wIrx2
X+aFyYSvMdSkuEBWhLmShbfdDTipsAeS+ebH7t6I5oYCHdCM1/20o3hvYfd7QYruR8P7AhUkIape
NYW4MlQq59Kfkp0HS01+khsbmytdaMeQP41lhEPXJOc4viUHSR8nKMwOiS6wjp175jPHCXwuLFAI
n5V8AQLRA3KBeoadwr5SNO0SM8eRp4fXOVWyo24MLq6/w6LfTCs3n7mkKVcGaQH8exBtQkGlkwrZ
g6f1ra8Tnl8AiMgqqsPqHIp1veVPnESE3XCuWa5F2J/r0U/edj1o1g/1JRniliyfprWtskyk7dOW
1AL4nUAIs5TyBwW+tWmD+Al2PmJx8G//0JK5I7KBfZq57J+rxf2pAvhDncKsNbmXc25/2iN+Qznv
5z+8asIMR1/W0hfQF1G+qaX2YxtvZBbbahpw3RplkFsSL2oDPWK/VaN/58vWRGcsBqZ4cUysfqMX
OdeqbdbIxSO1b2CeP1EdmjyfH5ZSRRxjN1GgwgxND82EKEwKFEEPVq0oxzwq0S3Ufp9vVMBUhqdz
VSiuwH3/72ElXTMq2E6lMDaRjpjtdA1X891vZldvlm2V9bYcdTyJbH2xfyybQoOsRCGNAuzsWlFo
NgbbwFOLvavrmRcPe626XnHynk+SVY+HwWFsQbxgVb7lbGSHW96pgZ5VHffUSwlKfNABrFSoZkzx
27NAi9eV3l2VNpegnLIVPkocup4MU3/rEJVGj9opsIO4zLnYmltVidhCrjab5+F1Obc2irO7Ms8m
y+bXoeerOvoZzm0RxYb0+DFjZ0eeN2/89PqexZBrFJy87+ML7tOwWq+5EOr8UNvdU69Rd6OAVbcL
t3fJ1M4f+fNPacSMczgb5qsr5oSfnS2kfTshJHOlSqLJMHT5DMQilN6/gcimAyMzf+4+Okv3a9fQ
u3+oqkfOGKK/t3cq//4CYPtE3n7zibA3lykwTSQbrztFbdbL0ltgDqVqT2ifoenW9YY4+VaiXVNg
YUwacmHetE2ZPo2AN3KZUdUBG1WUJVfA1OVy2eOG5CSNt0+ccmhba4NYAH3xm0UoBd8Wp+7Y/JbZ
i8dsqZLtnjisIcDqxB2EWZ4w8GYZ4h2Qa4u+Wg0CuamaWsMS8M9MUHjX2E5RLjmWrOnuqTUd+IKD
ZbgaA5xy9ZM6aZ6A494QSLu+Y/DH0MsBO5v06+ctdxvQKQ6Ua+oQ6WFvBsNec71LINFKg7WyNKTq
SO/ftjyjyF8AdB1x+5rwi31Idnqsb6MCselnutvoAO66XShUKn87j/W5Ni9OggxKHXwxA/8zbxWh
Kq9frBxT1MJdNik/Zba8LLqgHCBrJPaxifoeqh6xncBlz77rw0hbtl+AkpyC8BlTH61M5jJ38lvf
49svQHtS3HgObK2PHZcE/0i3U1lkGcdInIK9sFJE86r9HHZ7mGNimK15nuhW26aN3FgqdWdLLI6F
QDmiDHG+JrkNjuyRRMpgbjFxU5KhvmLfFAUvETfhXlJuCGWEg11Z0BpdiUEV9+Zx7a5W03YzEds/
MIcM4sfzOkHWx9ZDCtPkXGXV6GTVrMwoiZJssM89dOCJmrsgXPtLDClPqWWypnyi8UBJrAguhsbv
slpM8ji9XE837DnqUNqafTS9q+yGuEYvqUQ4wxSbN5WGntb2SCisk9irqdsGCAsKIqUSL9LONo2B
0XHB9Hn0o1+mYxQMxMXoCO8StjPGghFucgSeF+fcw4S1ZQ3pd7NfgA5kiTIjnRP3s8cmOYzHtoZ2
5LYvgI9QyoGkV2soG6vJ32NKq78LoaderD1adr8mMN5PfCThKgd9HJEfFm6H0X9q1LtIT748nslR
beD/efT4Dsacrdmcniw6X7nkraX3KjO548e6p4kUdWUxqDwHXOQKI/LmmWw8dMtpNPcGSYOGPKIT
CfuGJf1O3RfP3wvKInCmuRhwlSWnPpYFGcCpe6KJeIGCit4LURwZm22XRHdS7Of8ubXASj2gikhr
gpTdhbf5Op4qFvzIfmQg826QoMJBLO7iLn0SA/IydOYdhjOrQPv7qShHNMtQwkPhnsOxR9nn0yBO
PTspE/Ohqohp7upRkwAGO9eElYSEiOJlBrgW5DUuRyMydfIU440athO0NDrGnvO8wftBFzlyWeKM
yeDmUMg2x7WDAMA40dhdAjFqwh/Sxqo6N0vTl3QgRe42Zx1n7ta3BWbjj/hEsG/9OVc50cRP1nSS
fiKHBhIz5Rpup0N9Nu2VGYhBd6fuKdGM07vzjNw6/32qZdaL4K9/n5JPQ91YiiwZ9RCka8b9QYzw
fWg8jHHq9w3EyVaNTICjDzZawirJZf2IVC3nsbtqmnH7mUFpSmHXOlEoTo3XUW7qhvwJ0yW66+EP
fnI4ilI/+nuZQOW1NSm7dJU43QYGhKqMtigJTE3zEDKeknLmA+1dd0okusr6YhU1lQWKFoOsRZ0G
3n88V9qDhs0tq5jnJekJHYTGJAPtCjYPRykRvvFK/oszTTVK1CB8O4+qKnFTKqAueaN0p2+XFWJA
ZK2eTR3TUBqstLwFWz5EV9Ja17wrt5oaRcNTlQL6jKK9Dl5RgkU0KQlbAM78mdxHO1Il0k9q1PeW
+1r+yN0w76xpmm65RmpwPk24/djq37i90XUts0VQ+JHEO4rtRHTMmaJchVoRmsZ4eqagO11RsoU2
fmJXDbLlJWonHUmMnZ7nuDGXLFRAs9xqoeIdxVJ+ppvoAqrrXHvcxUK2M/W23QLbFkfw1QGJd7MM
fKvrHo85jEaiYFkSC66wqLwQY8jTz+pK9+tjAtcLfbeP7OjDNEr8kQzzuPrSxUD2OdMbdboWPCJu
LOFuKLrOFte10tYbTPiiC2Tomc4r0b8/npcTCULhsiO9DdnuqQsfiWb0unr+HgRJrykxXEDZYgpz
C9wftUe8U9kKv3ue1gkTMvZS+Ad82ByEVu64AAlUKc2J/WKFyyvtIRY3gWnK1o6WN5CzMl180rjc
h1Nm/560uDCqk/TtYtnzGFPHiLMjp+NUO+OOdDJc1wO+AIa1X4ABLZbwYTZx+rr+jd9Jz3PzbT3i
EqNtC8QPDnsRQnNs0V4jXpzVa6DoVo80ZyN7C2WmVCl+UTClJl7nbG3A0jp83FPhS4BsRFM3m9GD
1oiwyDhCaVp6jwR46UrzEYO5DGv0DrPRDkbD9YP+sXsPM01Lx/64RZ2hST6DcL/gqH3perMfL3IP
AWzHovkegSXmR/zIXCfzAEVxBx3JiR2mUX6Kbz+dW8UvxTmh8NlAoqQ7PX9/mGjOyn2DWqt7FO4Z
O1cmtHOjp6uxvzZaUJ8QK2Xj3P1ALVVqq+Bo5Sjg0vvDjFD//h9DVu6bfOj4Ee2j/+2shqBHXK/6
Q9ZbVn5nHilE5IGDTsbtf20kq06CONCK0YOrUAPqg0TWudEJzhMrEKUR/eSRtd/N3pa8nQ1B8vEg
d3PKle2MuzwUjQ4tIdRIRcdFISkzjK3aLVW3mP8SefjciCOPxW39C2BPTtw8ZXOBlMY4K3dUcaXB
fVTkqtOiIpaLLK6kOzBSNGFaxIYog6xFnY6BZ0OdmA6kC29HGK2SU9890UyNShyjHabCK3GGpR3G
K+IYJ6QbyFDUFaP8x27AFbw7vHD/lvVSwjKIAvHtqUFJZau9ZnH2OWAopmRtQ0eAXJumn4KHXqoA
RApVy1HllglvV/qm4hpNbxHKd6BZU7Jz3DDfs0VojxoUBgg+UTdZvrC7zG+vb6Y7IMlzHhMW16r1
tUvT9MAu3HhxvQt+p1lq6qg7t/n3KpTFHVLjcICXQgD99qopFLZrsUSae67QQDu2+dfsrjKTO1K4
EWTRmErSNEg2vZXOKVgWGVOoP9Tyj6ns9He8FNEpX2pErQAFYRpXvLY+2OkuLwuaq3/7MpH9oSbz
cmBrfgBDtPMCFfPZ9LQd7q9Z3nTb0A1Pc2fQ3ji8iWdHNEZHadtN1Yytq3XLLLm0h/C0jOYDLEgQ
2vAamnV70+BkLp9lwm5a5lzdecqlI1sOeWO2VsId6prTR2qZQAa9iTWOTWP92Oqytsx7rC19ioGX
l1FGWE1nRiVhXqZMTQYrt7BuYw5DgSN5BK94CjMZ3h8oCWzaAcLrGjRZpgZGNMQ0NQWDAPy4RZlO
dvP1IqMVzkrkSVgibEndMnE2QEzAw4lctpp6guKZNEAthL5CEEJY1lmSZCCAQiLjJ8WVelQiMIh7
80npwEahOkeUREXBqG7YxQ/YTD2/gS9GXwOJGK/K6KDI1eLH4qrq5YCCyCIUohhAL/YdP0WBfcLJ
SSXwnv6/ggvNlpRRZcL7P0h1vz8ksicc298bTHk18ARZ9WdlZK/QWvqc9OAc/NjncgBeeubW05tO
+fXgGjhOCeLok1JbbPAoYpI71NviqA2f/KOi7/C7syYHfwRjmY5vOy6FC2R9/9Ne54Vpn80SpEV0
6Ij/yYySbJU1Q666FmSCV1UatsvAoQGRV99GsdVJpklLIll7woJ3Cqm/ZbFFFMVhQ56zYXu+DfaT
Znm4iDkuxfJWVyT8oUm7aULaWz9u3AwuqJv89WjJwnNJvCk6RFOQLzgSwao6M/BYexR5xIaf4N+V
6Ua3JDfdToVgeMUWh+8l3l4CNqUq/OiVhIVf/sk8/DbTt7yUxieEC92sQDySEAZ9XtFwZRkeqIqa
H0N84/JTSI630cdbTW4Xis4YEpCs0C59JPORe/hzt74NgwyoBqUVP4sTaTdGCc505vDnkpS6aIh/
5j2NVV6UbqauH7Q7yhN+qp9TK6O4aqKd3J6kORlPICUc7Ji7CS1SZhocwBPtOpX1Pu+XABAXbqjp
qsqMMH8c9PSxKbXW8M0XztdaAYoZ++55R/wzRgIQxVD50i3Lhk3c2PmK5WUJuTwBr+hO9LyMNakW
weNmDB8LhEki8JaljmAOAr2QbL0mOyoaAr7suc3VDR1j2U7X+by58sDSg2NKf/0A+mybmdn0vcZB
B55h3c/x9oRvf3aQt54foED8dfVWb+b3Zrd/3QhkPA/8bIWIiD/vPn7CfAHkP9iXMhyLDScnq1Dp
nVz7ZkqVMC+HzeRXB4XJQrTSJGdeG2dOlIfLtjO6imNF9m+rDCUroMLX2Iau4b4A+qpm7DX3J3tE
7LH7JZa7+wLBBr6NM0DUVztyDgFHwugPSUmbDD4/sFu+FBszvCkY+v5deCShVPJhZl+v8YTrHCGm
vbq9aQwnv8Iasce4aBr8BagpSl0z/8RQjh8sL9eFbyWalyL1u+QRRNaJ0u+NaU9ucL2tf3ioDlLg
9qo6Mt77FWwYHUSMZUEj8FvRRpu52sLufETqUL/lNRdhHN/GTpHGwscV788fYyc21w+G1NRfxzWu
M18A3TyqdTYzziwGV0XVNrI0dPNFU1fF+AU3JLNGGZlMetzo9/nkeWclyBKCgrgpiZZSjmR9eDwF
9oIqSnX55KFVRmpQxV7FEP3afbE4MW0x5qkperKqaqDIJV92YZYiFjceLQgZR9FP8/PbTx42LvZ/
/Ev2tp6Oap+ji0yXoxvkAnFmuvPf8J8e+TRiq4gq2OCVL7KPjzb440T10J41pymoLgargJ0IkSLb
7Fw8eNUxwKZNOS2ZkP/5y+CvEm9wXveVXtEQn1ztI2WJlmK0Ke+K71v9Qmxpq34L5FRY6L3OfXKv
HEMGhGvn8fTCjK5/yK4BgQ73eSKHdZdEV1z8F6A5d7UkTHdu/2+SYpyKtFLWoplv8oxsGRAE5NPo
qYXpHqqmNtpsV5vw828ywJTY64XX/bfmVh0ump50xJYdird/ok7x196xibo3Ck1AmOHgN+7rnaZb
AFp/QL722kvsE1rqlrYbUfuwRusyiJEDrk5sruugKSvtD03D64JMPi/XfqQTINI8jIY8Adl0hMft
qFNBSWa+6Hokw4eoAMPAYWtVwLQtZ5ulZum/7VWXNfDqlyg94mN3qESIPycMH52lBHeKsS7KhrXu
/FlO4rBIVBo6a6uss5HPTKXSyLOZuzgH3GKoa5m799SWNW9KY5qRqD7LcRlXwigtS73VGLw/DlzL
63QuTG0szl/SXTXD3neBbN/PZc/8e5MXUt2k3nqLaD5SvXGXSJ8W4RZlIK6Coxk4raN9uV9ifbZF
Me/mo71a6CzgDP3tnRcKj1Nxo9B6t8U0m0Fstmmb3rGpOlRV2CPIPfhKZ7KPd32+2ZRCTXK2eKlm
bokca7tAkAfEpDTAzadO7cjFO9AyV5+XxQuGqigXYKoWLzplNRgnsQnwqOVkLgOBXSs+SlFZC9Ff
grjMgqedJHStzff7lxN1OPewBqgfJccbarutgSQoNQ8E0g5mqfDvM51453ABJbpZIwn6TP9uV/1X
4SXP/pC6V9gJuMKU5HTX/86jRyiEJnR7qPxrPZPWt9yiNUZwvgL7QvOJZPWikUd84t6ithpeFCGu
h7zOxwtVQ7/wKRQrcduV0HwxgP1JFq0lXOuZiGynZx8djPhinleC7hETarDcZNH6t6kMknCcDR7X
cWjR6FmC7LsEu5GZ9+Wuh1T2LzaUFK6CPT29TfLpmTH6x3eHMd53GKa0yOpzE1omgyhm+M3kk5O1
8DEqtSlrpJXrkQiiz+AAnDSC8YZkHcQgqTbOERtvcz635z8996M/WstnVPQ6lGJQEqxcoZUDarIm
Tz2Jg+qbQZZMiofMpq3fWb61mZGFX/o3M1UxQYe70TY9j3/8Hh3XSmLbR9bZ9WCBayeZrrHBz85M
KhpNIJNAhLZtMvaO063sFq3QS/au9jb3lgXG636kU1ZByVJ+69mfHhGhrtb39J9XDL3dmx+L2Lob
R6WFUevFGhTfW0Vjen/WPJJzEqggqNwvO5TNZelMcEC/gBlSE7pi6qB7BKkvmxDtebpMewSrmMdN
GghMDkEcZoTdmBa2/L3grFJYjoOZ1UsHZ8FDUbx1+WsMo+IbIswWASQTvAylrpPvix1xNsCA2EXs
YU2FL0D754NQACl/W9PzlQMzyMLaMoRi4GcklPjhk9D9cV3kyOnA2maB9PoEMkb5thPl2QzIGXVv
PbGhyZnRRZblthbJ75TnXe8XJJ6KZSqLu+w+I72DxvTWmWzjnP1K36zehEDXFP3xJ8R91Y+ik5uP
0g8ziRx7CrJRGC2eyd/ey7kSe1kNPQZ9OHRHDio0/EIZFUbDrZ/mse4pTma3X4Bgx7qTSGY4V9vi
NZv4la49/sEedR0cgG8Rv4I6nb2HffUg1ZArpdNLPv3O2lhuRg1rl8KvT+U4riByPE0UWJ839QbP
0kf1FJEgEg6TVRyYsG6Fvu3kqmeaA+1+vW3GHeSpSwX9a8U4rOwWrcToMWeMlPvbG/3C58RdO/++
up/GZolDVnmGPvOgd6VyXSlMmVbsvvCsikF3TF74rYZFe5Omroah1FsZF6UMyPuXbu9AA4nQwlfb
KL12uYoolrFtIJGCV6KtB2tnm3ZcxthGUY2rYpZBV1cOdcqtOgxUC5ydBh2ZjTd1vb2ts2NpiiM3
9+80iiMKYQ8iZ+0e1nSqe02b4Al+4Q/1GVQb1VM1StWLj1mkbI1ePGADAvb5fd/JUqiqZV4K0DHA
FlEmBK38je9jZD9Rei/1k8HW2pSlNRlpjmgWKdH1716b27IjuXLkRGwGBSNcffnuEnMRNNxO9t0M
J4TZYmHiN6JzFp0WHLAaeAskvSIduVXY5b9t0K455nt8ZtCStDdhBoxKWzv7C7EUpK+YeAt/FB4K
rvFPSXMrpwcewCH2hYy9LgtXerYXw5Dt+vks//ConBFGOsZM3VcR5J5qwhj408guld73BdCaT1SS
nz/qaW6ir8A1vYiLt4JbWM7VPX2yxw2b1v7rMcMp4B0p4m9bWyNcokdCt2m0rTvoyACo8ebLJ2h/
ddUYSnUEJJNfvdFReGwT97lNuQCrgfXoA17fuA3vwUvn3BHQSQ5EXL+FXxco/0yngs8dbUnSZTbd
bqNqewjWBSu7WNfaFwZxACxjaZd+VztTFmvNLc3kcWw7hNdD+yQp/LqzbvDkG8yTCbT/PPe3l8qD
lcF2nFOV01WHCU3756FE2W8aPvvmDUBTamOIuPHvfjP8AhGCHcsYriAbxFypbPdYFvpMW4+6IGxL
TC4j8b9uJkCirnUPL8eAHxmPjt3zMV+AGJW2HLMb2KjDkB+Hg115XWz8y6jE9R4OkycMsA7FiQEg
SU6fuk+r7PW7+NUrick1/vCcgF1Ol/04wfDxbJI0kEVXgg3+TdBOXbgB27kDxLGAjxbb2uKZ3LHX
ufnnF8A75MrS4+5b4sv05UtRugKR2zRFRyqrFW4Ic9iVc1yaoOtWa9cZK2hkN8D1AEke9VIETBYm
eye5cLnp3jQtVSCgiiz5j06J9zEX8ThaZZpZba4Wf3xP4ce46iileM/2JQUcf+u820l1TXXkekEe
Tiwxg9HD79T9yS9AIOqxoTN2iSu6F5AB5n6KwwaH1WGVzGAIXcqlHXyYpJR5sHJ/Ibs3ON4VbQps
0T3EgJghvJOB2Yxcl3JwR1DMcW6g6U/3cXioZdVbHXzJtb18mEL1YQ1gn7Tfaj9KYzl3y8yZhBp0
RIsbA175LsaEmw5OHLadTDlDmrXlKeYunDhY5l2NTsJVVJ47Pz+U2zHqKYh5vnLqxGkJj7Brl8QQ
/GsjOLpdMxmFrJpwJLgt1hQ69dbne8r/ebvaalN5zbZY4OuNj/RvUwLClacKSpWU0/zcxqFf4g87
J8FCsbr9XEl4+YcNn89DqXrIQPBcYrBM4E+1u2FuzE4FCltk8khdWUYIBRtde0izojPNuUoqPcVk
9DEYJg7VhXBWRUxVDcCuYvmdImxQ/GvqFk1bglk0tgcpgC/RhnCpNeQ4cl23IdUUGkifSlMqjF+u
U9du6Yiysa6E3NVALkMHCOrz8vp8tNm9Dlk7RbBoYzXJ48eLRlX11vgCYBUZnKHc2K87jR32eE7z
vDOUtuSY1H0OJDq5SepHBBKiCy9cPoD2Ctmzw/pK9dQ8Hs8CGGUOQxGlaQQrWrbgunozb3GtYlXs
2gnUP69zx73xz5ry2LYHrmziJagGNrDIMtzfwQQNNr1hS2eSfiYluSRNTC33xKb7QsG53vMNtHu1
Agx+JmXfxlyqeh3m4N8lRDqQGoEDL6jplf5Owod5S529aGcka1toLW1+kUdi8NBWwSfamYxjFrsx
clMWJLakP9vxeK4iQ+MJGZxsjaT/Gmk09bZrrjHubQ0u0+BWe+kdOz7FuAmhLDFdYD8OmGJc3IQP
tkpwpmMydXFyvAq81vhrW7GEv2a/LoKvGyTy10+nnJN4SWkMNVuZy6IGMynXtPKIJtNwkHlWRCGU
xEeAdxcB0Nrlnk9wploUniSKzU5Yk5vc/e5PS9geoTtla5a3v8GA+Yt3IutlNr0NI3htHg2ALzh3
r0MBTjNY/i/H4jb2URcgaPC3XxWUSirJs8xegoVq0K5OltMarBen/ZBF2TVsdqvkzMUcHs8oWNmv
il4YFszonaHT1kiJwstzYYC1VWTluHfQxg1RYMxr1Dl/W2G2cA4yXjpgK6UxO4yOPQ6ObXKlxuYl
EIbe2BA94odODjL7/XEMtVY8+06GvNlTQjU/GWOKQI9DGLu4OrbHj7lw79qBgSjVnG4WDdKYbybg
FiI3auqr4h3itbPiaMI7vJOsoKhETdEOzLNJUmp50zj4jtE6laCcsE7dzDnFtTVUEHvCjNdvifDO
W8mnHvTtTUePTNXc1C+w/JRiLmBXq3Yt6YPSLwnKC+4pAyyvoX5tmIOJozqaNHFgkC6kCgEgbivJ
G44PGNCArt/sXfk0OMtLKhPQeGlex7O7KpQ7iJ7yt1D77BdYrCDL0NUKvp+y1HsItZKIkNxc2e1d
qzq7XpqjNUXlARqKt6clxMnOzD/kMEgFawbxN1xxBFAEjrlerZVeL0fZ292XyFXkXMLMc+25iGUS
ppkkX/oylU0AK9LRluSgwkxdkG10n3/I5g6MKNErzOslmsOFUHRq4NwghzTn1qk6cl+UxbIMnmmR
3jhk2dqWDD6mktmPbyB5cGrF/DERDgU5MFFFTmXaNiXX/K8AKGXXmjP8OazfEOm2mmR20UTZn2/v
x1w1aOg63Y6f4hnvGmaO2fdt49a5/XriO81G4nhfdHI5ZT7ZrObuNFawspL+7htohl5WCqPc12d3
4Pijs7g26uZbIfvy+cE4/hzXL+Hb+LTNVs7ubOyGQM2OtdafGVtKddV3cpe5Fuo7ZHeqi0gNjTPC
+l3Gl6XK1luaZSbiXP3ce1UvDeg2Nxa6ri2W6lgnCRk8A8+9MsfF9na22i24DMLMTedz94MKq2vi
iys7PU1iDlrmcMgwBgA5puaAnuvBsFxrckMAIhhjWSVR7jO0VJD4VthqOmSiINa3TbPKl4bI6mkP
ji0Et9MEkUz2Qj47SBcZqrb+NLcRaUJVd3tH3k+uc9/Wp5xnRX3g7SobTU5IQCcgR88xEkVhXWkQ
aascC6eb2R7fc8mOVyM8VVTxjHGmsRhXP2uQMgduB3qWHxzHuSaVG85IPKPPDcYp+0XYDS8OaJBL
otzMba3kljuM/wCkL91PapvDlhourrqssltHbxReWirjiEY9/esWy8X6d9guLSdJg8tz5qkHjHpT
B4rto4dTtraFovtZj2YP9anmuM6s6BosMWmtAq3Ae8CF25DA9qo61Dp9vex2Ztbb95OiqYx8wUnk
NXP6f4sSytLCB0Yi1l88YNS3fiXT55Jp0tT58syT72bONp6CnoTY7S58P6OJLxokj3Q2ZDwnGFbb
8jCsXQLyxu7W8X7DDm0svNBYAksprCfxkv8AaN9dLESLuDyCpPQ4xnFU9H8SxaVHeIYty3MBhJ/u
5obQ0iK5ubO/vPOkj+yRMFBCDp2ziqU4jSYrESyfwsepFNt7/wCzXHnqqOvO1X5HPtUU9z5krPtw
WP3R0FK/kM3vD8zR30O1tuWAJr1TXbVbzSm7kJnP4V4tbTkOrD5MEV7LpdzHe6NjeGPl46+1V0F1
PJJl2sw9Cag3Vfv4/LmlB/vH+dZUj4qCiTzttKL1xxuP51nySHNNDmkwuapvGPeo3uM1Q8yk8w0C
uXBcsD1pxuWPeqQbNIWPvSC5dEuasQRvMwVe9U7ZGdgBXZ6TpSqFlYdOa0iiDZ8MWAhVWfggZqz4
h1OOKFlz14/OqGoazBYw7Uba+Mbe/wCVcLqWrzXj/OTinJlRK91KWkY+9VC5pGlzUZNZtikPMlN3
1CzU3fRckm3Uhao/mzjBz6Y5pH3LwQQfQjFK4iXdRuqANT807gSbqTdTSGUZZWA9SCBT1ilddyxy
Ff7wViPzxigQ0uaYXNSiGV22hHLf3QpJ/LGaRraUHaUcN/d2nP5YzRr2Ag8w0helkjeM4ZWU+jAj
+dQGgCTcKaajzRuoEx1NJpu6kJpEiljSbzSGkNO4rD/NIpROahpuafMBcEwNNeQYqrupNxpNgDnJ
pKaTRUhYWiiipGVgKcelNFOPSgsgPWijvQaZQUGimk0yWOUc1ZTpVVTVqPpSESClpBS5osLQM0Zp
KWkAUtJS0DHLUi8HOQPc1GtaWjRRTajaJNjy2mQNu6Yz3zxWkLBYkZL8LCzeaQ5AiJzz/u//AFql
ktdRjnWNkl89uQvzbz/Wul8cv9m1fy7ddscKRGEAfJ0529ia39JUS6Z/al1Ao1ZVH2ffw7Lj/WY6
k1tGCaeozh4LHXpN2yC5+U/N8zcH396DputySGPyJy+0kr82dtegeHrhzoeqve+YG+05faDu/wCA
imeFLuc6nfSuG8oWjGPzuDtA96OX+v8AuGUjzibTNQS2894nEGdu8k7c+mKiNhemAS4Yxdjzj1/C
vU/El1Zaj4T+0QRCJTMQUxj96Oprn/Caq2ga153Khl8vd16HOz2HtUSVrjPOm4PNKreg6c064UCV
sdMn+dRrWUdxWLMTPM6pkksQoznvWtf6XqGkKgudyCRN6ruP3fpWRZ5+0Q46+YnT/eFeleNrK6v7
60WKPf8A6KuOOOFH4VvCwrHnhmlZOJMLnpjv600b3yd3PevRrbR7Ky03R2SBJpLqXbOdu7Zn19Px
pZfDVsNWvmGwwWsaMVXHOccYFVyprcLHnb+cuA5Yema0E0a+l099QBJiTrmuz1vw/YPq+kxx7Ugu
1Xf6A+hPatfUEhh0G9tkUKkFwFXAGWHr7is3TQHkeyc84OOv4VJaW015MsKcFiF+ma9Tkg0zT7LT
vs9h9tkeP59mDknsx7Vm6RZWRN5qKwxrdi7WMQnB8tc9RTikNHEavo9xocywXDAsyhh17/Ws8BmI
UNgnA5PHNdz8R5Q+pL91l2DBGCM49RXCMfmXAHLAdOafKu4zc1Xw3eaRHBIxVzNCJAF5OCKyViuZ
c7Y3O3rgHivZboWcmm2sW6N7/wDs35GJXCjb0J9fasjTZ4bPQrMW0ME908zfaN5UH73fPOKpqIHm
C21wTgI5Ppg057e5jwGidSemVIzXpOitFceIbwzRW0OIT8u5dm7HBB6E1h3mu/adStopooI1iuAD
MMY27ql8o0co9pdBNzROB6lTj+VEdhdSDIhkI9Qpx+eK9Yu5NOK61Hvg8vYrJgr1x2pl3qUcdta/
2cmneWIcOzsMjjutTpr6Aed6D4efWNQNmXKYQsR3qne6c9neSWobeQ5UGuq8H3Qg8RvcSyRIuJuc
hV74A6Vh69JG+qyujDY0pO5e2T1FL3eSPcDOvdOuNPZVnAVmXcBnPFVM1payYfMTyrp7obBln6qf
7orJ57VAztoPCKJo1tez3PltdrIYx79R5lQeH/C39pQXNzPNsgt8g7R19K0da1OGbwxo8KTxmSJR
5i/xDHbFL4c1e1i8N6rbvdrHNI25FPVh6CtG4/vf8KAydM8NpqWqtZRT5jHzeZ1yo57Ut9oNnHdw
21rK0rPJsIP8BzVvwPqlvZajI9xKqKYXQOem7ms9L1V1xJjKDGLrcW7Yz1pJxtEC3r/huy0hTH5z
tPtBI7HParM3hS0sNLtrm4lYPPHuVc8A9uKr+M9Rtr/UhJbymRNoz6A1e8UavYXei6XDHceZLHHh
gOoI/hNWpRsBU0Pw1b3Wmz6hdyN5UbFRtwOlL4e8PW+rXt3GXJgtlLkjjeKn07WbCLwrcWMsxS4e
Tcqjqag8H63a6SdQ86Uok1sUXjPNS5x5tujHYij0Sx1HWbe0t5Tskz8w6x49am1rRtNs7qK0tWaJ
/PRJt3X5uslUtAvbax1i2upXxEkrszdThu/607V9Qhudde9jcvG0ysGPXCnP4UJ2hT03cgOjm8La
en26LBH2eASRXP8AebFZ2geHrDUNM1Wd3LXEUe5F/hHvWlP4o08Nqk6szi+h2CM9EJHb6Vm6Bqun
6dp17FMzBrlPLAUdB60CH6J4biksJL+RTOTIY4rYcdDitX/hCrdpvtBDCDyBL5IGPm/u5rHsPEUE
Nk2myM6J5pdZ0+9yf61onxwvmGEBjb+T5W/+P6ip5kDRYi8HwahHFMImsv3u0pnPyj3ratbWZYLi
3tgbRIvkRs5L84rl18ZixjggtFd0WUyM85yTntTW8WxQCZ7XzDLcNuYyH5Y+f4KrmQrHQnRY5Zja
PErb1Obv+Ldj061WbwrDZC3VrcXm9gWZsfugTjjNZSeLo0uPt21zc7NoXP7gH121H/wlsdx9ne7E
jSQNlQrcHB4yKRVzVufCFppwuZI40uCZ/JhjfgAKoz19B0rB8TeHntpbRrWEHzohI8Ix8ueMA9et
TyeLTeJMl4paN5xKvlnBUdBn8uazdb16TU5ImQlEiQImDzj3pMDLNjJaMHuIwIwfmGR09PWtO+0i
Ix293bf8e8rKpDdYmOMo9ZCTFpFMrM6hslSeo9K3Ptz6pLBbooit0xtiXpwep9TSiI0/FNjp+k20
NqsCZlt1l84feD4zU0thYad4fspzbCR7sEs7YyD7VS8VPJdtBI8RHlxrHn1wKpXXiJLjTrOxaIn7
J/FnrWv2JEm94e020tNJudSZUkKucbunPatDwtdQ3T3dwDxHF5gjP3RxXHJ4nWLS59LMGUnbIPfN
QaN4lOii7XZvE6FMHtSul/4KGjZsBF4i8RoJUCrkk/3SBn8KraulpdawtmI0ULOqFl+XK5rI0fXn
0rUPtcabh83yH3qObV/NvzfGID595XPHXpU/8+vMGdD4wjsrGZbGKKPiMbWAww47+tW9fSz0nS7C
KOG3f7TZglsDfvP/AC0zXL61rp1q6+0yxBHYcbelLq2vPqcFvE8QX7PF5aMvpT6sSR0lulrpnhmK
98m2mea5fcJADlf+eYo0W3t10A3IRLeWS/UebgZYE/dA9K5l9flm0uLTTADHC5kD9+euadaeIZ7O
zWz8sSRrN54Ddj2pgzo9Qhs18Z26G3DIxgPk44z6mor7Ql1rxXe2qlbaNRuJHGABXP8A/CRXP9qr
qTKrSLgBT2xUsniu7bUmvwirI67WAHUUyTRm8N6VBNZeRepK0s6o6bgc89OlXvFsUEepwaWsMexv
LHCjcucc8c1zUmvnzLeRLOBDFJ5vydz9e1N1LX59Ru1vCixSKAMqPTpzSQHY61oUT/6HaPGEtLVX
kgIBbGOu/GfwqzHZW1jFpEUEkNuJPJMiFRm683+EZrkH8X3xLErGskkflmQR/Oy/WoYvFN7DtGYZ
WQEK0nLRfTvT2JZ3epWNnpNo5tZFtWnunLSsAd218JCM9mPy/jUuoabY2Md3eoyWTvJAnnqAQgKb
yOfUjb+NeeL4m1BIxGdknzbl387DnI2fjUUfiS/jaVnk8wSf6wSjeN49AeOlJ1AsbHjOJf7P0aTK
yyvbtulUABxu4PFcQa0tR1WXUcGTOAMKFJCD6L0/KssmsxgaZTiaYaTEwzRTaKQgLUoamUlO4WJC
ajNLmkzQKwlFLTaVxWGmig9aKljHUUZpM0AVRUo6UKtOpmpGUFRstTGk20hEOKaVqfZSbKYEIGKs
x1EUxUsfShgySlpKKSJ0FopM0UAKDTqjp2aAHipUYowYHBByD71ADVqyjE9zDETgPIqk/wC8cVUb
30A1p9buLxYTJ8xgwVJ5zj+/61NN4jv57mK6D7WhACAfdGPatbxVp1noEtraQIriJVd3zzNnkj6V
r6VpOl67CmsLb+VDaD9/aqPlkK/oa3jB23KRz0Hi/VoxLtEOLg7nBjyM+uKY3inVvPMwkCEw+T8i
Y+X8q7fw2llqNrrDraW8OyXEfmKMLj603RH07UdaaG4s7d44bVslUGGx3GKrl8/69mVY8/fXNQNj
9jaVjbBt20rgZP6VXk1a+W1+xguIRzwDjJ4616drekaRF4fvJrJUIMzHdxlSO1cx4Y0+HWdM1SOV
B/ow81Wx/WoktZefKI4Vie9N5qe8QR3EiDorEfkahG09e3T61mIkikKMGBwQQQR6iuiPijXLmMA3
FwyquzIU4xjpkVzOOpr0fSkz4BmYIqyfbCN2BnH1pqNwOXh13ULddsczAZzjtmmJq2oLI8izPvl4
bB+97V0GleGYLzShfyOR/pHkEDpnPWq+oaGul61Bb5ba5jYcdOewrTk8xq5kXWp6hJsE0kilDuXd
kY9+aWXUtUkjIkll2OBjOQMe1dB4vsksdWj3eZODEhx0yOPwrV8YxWsejaWYodp+zjkDv70ez03A
4FdVv4RtS5lA/wB6o01G6jJKzOpb7x3Hn61AyM33VJ+gJpm3sRWdtRFme7uLnBldnx61XDEHI6jn
8a1vDNpDeata28oJSV9rAeldLr9jodl9otYYit2rKqEkfMTV8pRxq312P+Wj/maVbuYdGZT9cV6L
B4RsksruOdB9sgtvPVvUYzx2q34Y8N6TeaLaSXMIMk7Tfvj1AiNPlDU8vW4nZxh23McZyf51YvdN
vrBUlnXb5nKn1969LvvCGkxXAvIkColp5xte5I9KyfiIIzBpfljA+ydvp0pWQanDy2d7FCtw7fI/
Rt3J9qr7p8Z3Pj6mu412wjj8KaO4i+dhluuc+/pVmws7aXT4/KsI0l2HPmQ5E3/bXoKdkO5xlto9
9dWr3aZMSfeOeRVBlk3bDknOP/1V6p4Iitxpesx3QRYfP+5xgew/GuP8TW0keqR+XGkQYjy9uMZz
1NKUV3C5zEsEsJAkVkzyAwI/nTCMVteJFuFuYxcSxzSeWPmQggD0OO9Y2cY+tZqOqGb8Pha7l08X
zSBI2GUBP3vpTdG8NXmr+YYyESP7zn7v511euzOvhLQQm0fJzhhn8RS+F7lU8K62CERi3GSATx2H
WtJRh+86+z3A5O30C6udQ+wQ4d8/eHIx68UXmgXFpcQQeYsjTHChOoPvit/4eXCprMjMyr+4k5c4
HT1NZ9pcZ8SQkuGUXWQc8AbqhqPNSfzQFfV/DU2kxDzZYy5x8oPzDPt1FTy+E5LayjupJkUPHvVG
4Y/TNW/Hs3ma04Rkdfl5VhjOO7dDitLxzcRT6XpPlyx5jgjysbA/8BOPatIuFnf+ZiMLTPCU9/YP
qDSCGMEx5bvUOjeGW1GeeIS5SH948g5wK6S1vh/whLwiWJJROSU3Ddj6dai8BX9vbx6sssyq8lr8
m843Gpbhcdjn00BrjVILC3lWRpf4h2q1f+HFtLyG1S5V2eby3B6hs7SPzqTwfdRWviGGe4kVUDON
zHuelR6vcrP4lkeaQPCbrduB42b8n2q+gzRm8HKkd+EnPmWUYkII/dnIzgH/AAqnpvhsXmkXepvK
Abcf6gcmumutasVXW2+0o0d1AFtIxyQcdKx/Ddzbw6TqsMt4kD3K/IshwBj/ABpOwHN2ulXd4rtF
CzIpxvxgH8a0dE8OzX99LbzK0SxLubg7sVs6brNvBoX2NLmKGdJtxdxlSM9qdo2v28Wp3kt7qCnf
BtEwGAzY6VCUSbMyBoSXeoLa2UhZcncD1GOtR3uiBLpLeFZgd+ws6/KW9Aal8OazbaVrLXMkmY2a
T5/Zjwa2LnxLZW1oxjkF5ML3zl3Domar3LBZjE8HwmQ22Ljz/L3B+fL3Yzg0q+EI4GtYbqKV2uDg
yJ92D0LVZ/4S20RzepOx3JgWnTD49ajPjCC9a3nmke0aJsmBTkT46A0012CxDL4OTTkllm3Tr5ux
Ej6kIe/86yNe8PNpskPkJIyzR+bjBYrntxW1J4yg1JJoZt1kvnFkkTJYj8PWsfWvFEl5cQ/Z2KpD
EIwf7+P4iKHYZiQWrG4jjmR0Rj8xKkYHrzXa6P4aMVxFIjb4nIAY9q5qxnk1G9i+0OWUZz9D1r0C
XWLWwggVTshhwcdyam1gQeMEsbKxMOB5hHyk+tczeaFY6fo1tcygma8HyndxGcVW8Xa7DrN6ksLO
qqqgA9Pc46VDruv2+oabptlGHVrNfmYjhjUlFzS/D9ifD51a6V5NzlVB/hA71W8O6DY6il/dyK/k
2wLKPUCo28R248MrpYWYzCYvx93BqHQfEVrpun3ttMsoe5TaNnTGP4qpgTaHpFlrWutCn/HqkbSb
c44Ufd96ZLpun32twWMCGOMzBJAJPQ/1qr4b1u10a88+RJWVoXjCp975qr2WrW9trMd95czLHKXC
5+YZ9alPUk2PFNnp+n3X2GKPayMgPvmrXiXTtO0azt4REhllhRxJnkEjvXP63rMOqai12iMuSpIJ
5+U1J4i8QRa15BWBozHEIyS33sDFMDdNhp2l+HtPuZLdJTfh975/eKf+WZFSaHp1rNplhKYrdpZb
oLIbkfeTP/LFq5/UPEEN5pOnWCwlfsI4bPBqSy8WJb2lrby2wf7FKHgxxj609yWba+GNPuNfugSI
rS2nUGAsBM5/2Rmr11b6NpniHUlmW2jj+zD7MGG5FkI6kVxc3iBrjU/7QK/MZg5UdwvY1PqXiaHU
tSa7exT54whTd6d6tOy1IaNWOxSC+spdSSySycna0UY8t/QN7U3WIJSJL2BNOkskmGPJX+EdA3rW
fd+J47qGwtjaRfZ7P/lix4I9M0268Sxtp7WFrarBEzh2/eFuc9hReHYDfhuAthdXOoW9snnoEs0V
FDc4GR3rTTR7WK8s9OVrdoZF/fxuAZG3DOQa4HUtfk1JLNGUJ9kUKpHfFX4vF9yoR/KR7iNdousf
vAMY4NTcdzrZ9Js9HjtRbvFF5suXMwDb+eVX04qXUtFstGinuoRFFJLciPzJxuRRjPA7Zrh4vE90
scSyxrceS26JpBkrUf8AwlF6fNE5+0LI+/y5hlQR0x9KHKyEWfHFnHby2kiEbpraOWQrwMn/ABrk
DWhqWoz6hL5kpP3dqqOigdhWaTWLuLUCabQTSZpXACabupGNRFqQEuaM1HupQ1O4XHmkozRRcApK
KSkSFFFFIBaMUlJmmAq9KTFLSE0zYYaTNONNNIkTJoyaXFJg0xajSamTpULCpYulCBj6KQ0ZoEFL
TaXNAgpc0maKAuPFSIcEGohUi8mrhuUdPrfiCLWVgmnjxdLtDn/lmyjt+NX/APhM0tZLZbGDy7SI
Ylh6B+MZP41R1fQodGtbYXOTPIFfHYI3pWhF4RivxBPp8nmWgAN0+QGjx9fettdV2Hcv2fjHSbaL
UoPscwivW3DacEUy38X6dYTCS1smRfs5iIPUn+9mptO8I6Lfy6kYpruYWwG0IBye9LY+F9E1PVIL
KKW6XEe6UMuDn3NK0u40zKPi1W0i7sCh/fyF1b0zVOx8SjS9OmtIEO+cESTDuPSun1T4dx6dp1/c
vJnY5EW05+Xtmue0LQLbWLK5iUkTwDzvYik0+4zlGfcST1NNDYqS4TZIy+hIpiioRLAc11OneKZb
bR30nyEZHbcXPWuYRdzqMZGRx+Neur4b0IQ2rvDbwwzWW9rhn5DYzxz61cUmCOLsvE11Y2UlmqK0
TSeYM9jmo9Q8SXWpXcV5Mo8yIADHfFdJpuh2N9oN26ovmR3RRZPbOATWI3g3UBNdRZH+joZMH+Jf
anbUbKOr+JZNdZHkVUZFChl64FTN4pvJLQWr7JFVdoLDJAp58K3SWUd8WjRXk8sA88+9WLnwnHa2
/myXqb9u4Lt4PsD0pkmHZ6rPp4lWJYz5oI5HK59DVMszszEZLHPAq/8A2JeS/NGg24+8WXGc/Wu4
8FaTp39k6k2pICA5Uyd1H95TRaLKR5/ZXVxYTrcQ5V0+6affaldahOLi4bc474HWvTNW0TRrrR7M
aRGZA1zjzcfOfXrXLav4O+x2kN0khbzJAhRiPlJ+lPkDUy/+Eo1R41RrjOF257lemDT7fxFq8EIS
KVxGucYBwM+9aV/4Z0vRpFt7q5k82SESDCgoMjI962/DNpbXXha9WXaB9rjUNj5sZqXB9wuzjZvE
WpyNue4YnGPw9KqXWrXd2FE0hkC/d9q0/FHh4aBffZ/MMgZA+fYiq3hjTItV1a3tnJWNjyQMHH0N
RyK+47srvrF/NCIHnkaMdEJ4GKfFrGoRJsE7BOw3dK9Hn+G+jIknlzy8Kdo6cxis+y8EWhgmWcHz
BE80eD6etVyeYanBpq11AHRJ5MSNuYZ6mopL2a6bdJIzkdCT0rr9C8OWF/YXdzMGLWk20D2zVTxV
oltpF5AtsN25VYx+rHtScF3Gcq7setRZ9a2PEXmrLF5lklg3lj9yvTH94/WsbriotqM2o9L1O4tv
NCyGEDIJJwR/siiw0/Ub1JBb7yiff+bCj612ur3JtfCvh8W67N8XzHHPT+tR+GpFj8La5KqYkEmQ
xHJ+lUOxxcWl3c1z9miR3m5yoz2749KLrSb2wnSKQfPIcLtfPJ7D/wCtXUeAbjz9auJJU8xvIf5i
MhTjrVGzuZbjxJaechkC3WAhBO0b+po3aXcLGXeaLqNmoe4XjH8TZP0qSXQdSWyju33BHGQCe3rW
x4/upDrMkAOIw4wO3Wtfxzdvb6bpKwjYptVBx06d6ULSTfaTX3BY4+x8O6jf2z3MfES9ycZ+maZp
+hXmoTNFCfufePp9fSuytLpovAZdExJ9pPPQ4zUfgCT/AEbWpTt8w2/Xv07ev4VT5bhY5FtHu/tw
sVw8p6bTn+WasX/hy406aGKRw7TcLt5wT2wM1reBp/M8S2rvgjY/zMRgenJqtcXD/wDCViOZxBEt
+pCk/LHls9avSwhk/hO5SK5KzKXsxmdBnK5qPSfC1/qcM0yny44Rku3RseldtqF3Go8ReY0So8IE
Lqy7pT74NVvCWu/b7a5glhgiEOnMFy4HmYHfPem4x7oLnKr4dZNOF9PeC3hZ9o4zk59qWw8Mi/jv
JlvcQWibnbZ/9atHSrjUZoVVJrb7Kk7b4pSP3S7uTg1PNchdQ1NNHureOFwu+B2UIxHUDPBqW4iO
cj0uxa5SFtRCqx5cxkAfjWk3hWM2gu7O58/Mvlr8uM5PUd6seI/7Pnm0pEMIfgXjIVC8nnJHFLqG
tWun6rZw27o1hblWby2zn1+tSkk9xkB8Kb98CXO+8RdxtsHpT4PCPzW8NzM1vNcD5FAJGe2TXQjX
7W3mmvRc2bxNH+7RVAlzL/CTSv4ltruazuEuLSOKPyjPDMMzkw9oTWjcQsc0vhNraJ5NRdoVD7VK
5OcnHvVe78Ny2NyIzkoyhlbHUHpXYN4mg1SNo4JI7SRJZSDcgYaGX098dKzNd8UQRTgxMshWPbkj
cCR6VErCOfs9tlqKRuQoz1PbPrU2sw3RvoreTcUmkAjK9DmsqS+Gs3q/aHSFGOGdVAwPwrTn123e
90+1ifFtYSKfObluO+fShPQCXX9CtdJ/ciZmuU2lgehDf88zT9Q8OWen6dDNPKwnnj8xBg7T7VX8
aapbX2rPcQzGWNlTHopFT+LdYtL+z0lbe43tDFtZcdDirVrAR2Xhm1bSP7Ru5Z1V2IiEf3fx9qbo
Hhy21G2vLy4Mggtn2fL1PGcipbzWbKTwlbafHcZninyYwlN0XXLOy0DUbKWcia4O4LsJxxjr2rGe
jfexVyPRfDtvq2rT2sDy/Z0iLeYPvkDqn41ANEs7jWrezsWkPmSeTIJD8y4PJ/Dml8Ia1b6TdTz3
Ej7HgeNNq9S+eo/Kqei6laWOux3c0kojim8xsJlsZOML3960ha9O+3K+f1Jb919+hc8RaRYadffY
7VZDJ5gjk3HO44/hq94l0HT9GjFphjdbI8NnhvqKydZ1K3u9aa7jdvJM3mbuSaf4x1231u/+1WzP
/q/4hisr/wDp0behqX2iWGmaRYS3AYzXdsZA6kfKccR4qbR/DWny2OlSmMXJvZCLgvJhoR/sDvj2
rH1/XrTVLHSreISq1pbhGL9D9Mc1ctPF1pFBpEcsEm7TSxTZ91yfXNby+KVvhsiS3p/hK1u9XlTP
+gQXfl4z88vP3cdcVOvhK1OpayVRPI09ciJz149a56DxKY9Z+3kSCHz/ADzEjYzznFaUnjOGS51a
QRSfZ9SGGXOJY8e9Jva/ZW9AexTHhu8uL2ON444Ely6FSAmwe5rpNV8GafHJo0NupBuj+9fPWuU1
nxMdQW1jhR4Y7dNv3vmb8auXXjJpINJ8hDDLp2PnYmTfiq54W2IN4+F7Wb+0bf7PBF5Kk28qsC5I
/vjqKfB4V0+38PXcrKkt2gyZgRgZ/hjHtXNz+L18q78iHy571ds0vnEnH+yO1QWHilbXSr3TvJDm
7OWk3c5+myp5qfYDqYNCtrRbCJYIJROIvtJlxuxN/wA8akvPD1poqgwrDM0ss3N5jCxRHoma5aPx
Y4FqZ7dJZbZCkU5JBU9s1HJ4wmkjRLyJbrym3puJ+TnPHr+NDqU9hlTxjYRadq9xBFwqYPHTLBTx
/wB9VzpNX9U1J9Tne4kJLyHJz/Ks0msZMQUhozTSazAaxqI05jTM0CFpN1ITTc0EkgenB6gzS5oA
sBhS5qtup4emMmpKj307dSEOzRikpc0FaC0005qYaLlhSdKcBTGpXEG6jdTKKLjGu1SRNUDVJFTQ
mT0tJmjNIkKSlooABThTaWmA+nKeajFOBq4DO98U6hb67bWl9GygxRJE0GeQR39au6brOn+HLGOz
DrdfbcfbJNxxGD/hXIf2Pc21mt5NlEfG1T1OfSrb+H74JbSBQwuMbCp3AZ/vYzit1cLnb6Hd6NpE
mpxRahEv2qLMD5OcmodMvNJ0fVYLmS/EzSwOLhl7MRx+NYVv4IvZnlh8+EGBBM/zZx9fzpP+EKuZ
bq1gjvIXa6/uk5Ue9O8ijaj8WW7aNq9rNOWllmZrYHJypPFYWga1baNBezFsy3CeSsPoM9akn8Aa
hax308uVS045/j+hrM03w9JqkEzxSZmjH+o79eprOaYzCuJfMldv7zE/maYHC8f3uB/P+lOniaF2
Ruqkg/UU1VyCf7vP9P61ktxMfCwWQE9M813PibXrHU9OsYrZ5A0EQRgRjJx1rhIk8yRVBA3MBk9B
k9TXex+EdPj8uGS6fe8e/wC0Bf8AR/purSKbJZDoniWz0rQrizdXMskgfPbrWvD4yW9vJjDaOVms
/KI/izjtWFo3hKTV5LkRsAsOfmBHzY9uayH0+6ivTbRHLhsKA205+tVawjutZv7G00O1s/mL+YJS
hYbsZ5HHSsS48T2T2RhW2dyRgCR87Poaw7rStShZftKPubhQzZ3H2OcVNJ4R1VYfN+zkDbuODnA+
lVFNlGM875IVio3Z2g1uaX4ll0/SrvTmj8xbk53E521f0Xwd9v025u5ZIl8v7mWAOR2IrkZ4Gink
jOMK2BiiS5QR2Gl+M30+xtrQRKywsWJ9c+ncU3UfGLXlv9nWEKgcSLnqGFcdsbIC98A5I6Zrqda0
JLLT9OmMe1pofvhs5/wo94dx914vN4oM9pbPKIvLEh6jHfFVrPxdcWFhJYxQoUkk8wseuc5xU0Pg
e8lWJg8e54fMhTPMoxmtrw54dto9M1C+vIVka3k2kemOMUnzD5jlNa8Q3OsypLKACkYSqumatPpl
3HdRY8yM5GelbNroJ8QahcfZtsUEY3EnsKi1rwvJp1pFfJKJon43AYzis3TtrcLl9viJqzg5EPQj
p61THjjUx8uU5DAtjnB7VnTQ6eLCN42ka4I+YMMKPx6VlKueuM0rvuFzvvDXiqx03S79LiTNzO25
QIcqa5fU9audRuDNK+SPu+w7YrJ6UMpzjj9DRr3Kuie5vJrogyuZCBgFjk49Kr9xzSuVJ4G32zmm
8Zp/MV2bj3us31qiO8klvEPl+U7QPY0lrf6qbd7S3kkMT/fjXOD9a7bUZYtH8KaP5CgfaI5N5I6/
nTPCZgt/Des3wUGTcnzY7H+7VKCcZa/ZYcxw9neajp87C1LpM4wfKBJI9O9LJLfwT+a/mRTk53YI
bJ9K67wIsGp67PNOijFq7KOwYd/SqMd4uqeJLSKYZVbjbjHYN3qacF+4TfV/cO5g3o1CQrJeeaW7
SS9TT7qLVrmzDTC6khQfKDnGPY+ldD47vFbVpbIDCI6qMY4A7r61reNpxZ6fpVtCgVHtV6DGcjvS
mlGLs/tv8wWpxNna6tc2hEHnvAv8OSU/AdKZYQ6pKZLe0Ep2/fWMkdPX6V3Fs6WXguOaDiYynNRe
AX/0PX7jA84Jw3rndgD9auyv8l/w47HFpbX0VwtsI5RcOcBF4b3z3p19pN/bSpHcQsJZH+XOc7vr
XTeCrhr7xXBJON5EUnJ/hOO9Qx38114stIpZdqLfrtBGcfP0B9BRG3NH56gzLvNA1W0t3kmjIES7
pFXrGCcc/l6VV0/Rr+/jlniVvJhjLNJzgYGf0zXod+oe38VMySR7ZE+YDAkAP3Vz1z7VJ4W1WyvN
Nv4baBoI4tNcNFx88hQbj9STRyLUg85g0i8uoXnBKRpn5ieDj0zVW1sbm6ukghy8jnAxXo8f2STQ
NHhW2FwXuGEq8ZQZ/iPas61vdP0DWZ7eGEOHmjCS7gfLJPO00KCA5TUdCu7C8SzkyZnx8qf7XSl1
Lw1eaXdQ206/vZcFQOev0rqPHLlvEkDwckCP5w30649Kva7drbeIdFvJmDRrGm5twbBxjnHpTSiB
yh8KXaxnDq8ijJhXlhU9t4WvCFDukcr/AHbcj96fwrtYdUtra7v7mWGCOCRJCtyGBeb2x2pW1m1v
NSs75Ps/2dRGz3DMN68fdA61b5e5RxqeHbkRsZJvsg3bRv6Mc9qwtXsLjTJvLm3ZIyCe/wBK9Hvd
cttTiRbJYZNs86MLkqNozw/Nc14q8QWc2qSFLdLjZGqZYgjcBzismkByFtA13MkKttZzgE9M1aGk
3C3i2cgw7sFGRwc0qMmq3KKgjtecs2cRqB3rpjq9vPq2kIjIy2zrvu3I+cj1oTjzR9fvEZet+HRp
ICmcSSfKGj6Fd3pUmo+Ff7PsYp5bhVnkQOkP95T6U/xldRTeIJ5IpkdWaMAqRtGMZNXfHt/FdppS
wTRz+XbKrFGHUD2rS8eV/wCIT3M5fCoXTI76a4EXmD92uB82KTSPCw1C1uLya68q2iOzcO59/atX
XdUgn8KadbR3EZeLmSJfvCo9K1K3h8I3tsbmMSu+dmO3vUTUXKpJPsHYytJ8MjVb+a0S4zDajzXl
UfLgbsfyOaZb+Hxd6zHYWkvnLMeXPRVz834nt9K0vA+qW2mjUHnu0t/NtmWMD+J/mx/OqPhS+hsd
fS7ubhkjDNmTHUnOM0Rj7qfdCDVNBtbbUIrO1maR3kETKc5B6ZqTxF4etNGXyUkZrgbMowxnd/zz
6VDNqNu3iD7UZ/3YvPML98bs07xZqdvqeryXEEzSRfJhvYdcU1EC5qPhuy0mwtnuJJRfXFt9oA/5
YnP/ACzq7aeELWSPTjKLhzeRs32hD+5t8Dv61meLdYtNTGn/AGe4aT7PZiFlPqK2rTxVpitps251
+x2rQtBtO12I9elV6gUvD3goaheyLO7LaI7Ks3eQj/nnRbeD4ZZNVkPmyQ2E5iEeQsrEfWq+h+Kn
stWM89y4sBK8whXkDceKux+LrGT+1YH8xY7ycyLMvXBNP90SYkHhu8vL424ga2VWy4k58uPPWtLx
X4cstCuLFIiximiDvIc8nviq2teJzdXUDWG+2SGNY2KnBkUU7xL4kttdeyz5223hCvnqSMZx7017
KwFrxD4asrb+zY7IEvcoh3N3LD3q7e+EbXTvD01xgPerOoLDlV9uKyPEXiSx1W3tY7dZ42gRUGcA
8DsaE8Uonh59OKzGR5t3mM2enY070rCZpax4ThbTrWexA8w2YnuIgTuPH+sFSeGvBcFxBNNfASPL
as1vEGBKnHWUDpUTeN4vsqBYCJhp/wBkBJ4xjGce9YOheJn0qS6kl8xzPamDlshc9TisZOHQRzky
7WOOmTioDU00gck+5/Wq5NZMoCaYxpajY1IDCaTNBpuaZIpptFJSAKWkpaQhKWikpki04NTKKY7E
gen5qvnFOD0hF0imEVKwpnSmjaw5V4qNlqTdTetJgiLZSbalpDWdxkDrxTUNSydKhTrTTAnopBS1
RA6ikzS0DCkzRmimiRwqRSBj61HSg81Udxno3i+4jv8ASNLuLZgY4YFjkC9jjHStDwrfJoWnrJqL
q8d6MWi5B8sMP9b7V55DFqMtq7IkrWw+8eRGOe56dalls9SEcDzRSiNv9SWLYP8AuV0JvfuM9S8N
WdzZ6rqomZZme03qGb7wJyBVbSYJrfX7O/utkKTrJtXdwMDrXEwaT4gkfCQXW9kz8rHJX39qJ9F1
xZI1eC53ucJlj1/OndroVc9Hk8RrqWma9DPKn7t2CDIyy44x61x/gm5g0+4v72aRVg8loQhOGz9O
tYw8OasPPJikXyR+8O48fWqlvo91eRyvCWby/vKOvucVnOTYFG+kWW4lYdC7EfnVZTw3uMfqDSyK
ykg9RTFzWPUCSHG8bjgZ5PoK9N0xdOtvKWTVFuNMMPzBiNyvj7oB5615jGCzADHJxzXaW/gbU5be
CYS2oFyuYVB5bArenewrmh4Z1i3sdQ1BDLshmhZYz6Z6Gm6XcaPY6xI084l+Rikp5AmPSuRktLmO
cw4O8ZBwD1FQeRNvK4YuO2DTad7jud34l1qz1K005I5V3wSgtgc7d3+FL4o8SxkwHTro4ECwyAeu
Oa4R4p0++rjP+yw/pS/YLvb5gjfZ64OKd5ILnU+G/EVja2N/YXT+X9pO7zMc5Nc1qEtv9ocxOXTs
xGKqEv0rQ0HRptcvVtoxncOtJtyHoZeVdlbqK7TW/EVjqWk2FtGW861g2njjj3rn9W0ebTbtrVlI
IOB71FNo15aoryxMqNj5sHH0zTSZB2dr44tIRo25GJsLRo3I7nFV4PF1pHpWpWRjkzdyb1PpzUOp
eDvJ0ex1C23SGeDey+nqazPCOjR6pftb3OR8jH6ECk+a9ir+QugeJk0Y3StGWW4UqfUA+lTaz4ri
vdOttPhjIjgYtuJ657VSk0S4utSns7SMP5RPJ6YFMvfC2p2jxCSMYlO2M9ifTNJw03Hcgn1YzWSW
nlRKE5DqAGP1rM381s3XhfUbSIySCDAGSvm4bFVLOxgmt7mV5kRox8qE8sfzrOURlHdS7qYeppKg
Q+m9aTNFUgOivfEN5qdjaWUqJ5VouI8L/OnWmvXtpps+mxLG0c3XCmusu7Wz0fwxpjpEjG+hLTE4
B3Y7VH4TtrS28PalqbRJJMJCFDYOM/WtVBDOO0vWL3SJzLakK7qVPylvve2KaL+8t7wXOFWbO7Pl
lTkmuq8G2tpqmuXUzxABImkRT0DYz9OtVzLDrPia0gkSJY/P2ttI5w2MHFHJG6XcDAv7+7vrkXVy
uJOoYrj/ACKn1LV9R1WKLz8tHGAFKqQMD3rovHc0Bvxp8cMcaQzLGpUDJB4xV7xrJbaVp1lawRIB
JbDPAyCR2qZ29m7fzW+4aRxyatqU1mLSPc1uvUKmQPqRmm2Op6pbJNbWJZTKMuqpk4Hrj612Vl5e
k+C4LmCNPNnkPmMwHzD0571F4GEX2PXL5lXzY1QK2Pu/e/SqSXtKn/XpfkOxxlrcahZXR8gPHOeN
oB3c+womW++0LLMjLMzZUkEEmuu8Fzwar4rWWdV4hlbGONw6GoYb86h4rsIZQNiXnV06jPpUU43j
C/b/ANuYmjDvP+EgERe4WfyiOSTxj3/+vVfTk1Jo5XtVmCBSXK5xjvk16HqZiaw8SKAQRcL8r/dH
r5dTaDJpsmi6tbWeNi6eTI2P49pzW/sYrW5FjzWD+1GjkaJpljTJY5O0/Sq8cdzczARl5JmPRcls
/QV6YLO1bRtBtlB33jMrun1/irL0mPTfDuryQH95d+cqRN1HJpcse4zk3sNXW7W3kSRbnaCFZsFV
9TzxUl/pOrRRobkM6u21TuL/ADegNdn4j0yXUvFcpgZkCwqZWHHy45A9zVezu2W902GSIxaVAcRe
YDl2/vHPrU2g+wHLT6Bqttb73VigxlQ24j6jr+dOj8M6rNAZtuBjO0thyPZa9AtpLKCbU5ZYzAjE
ZkdspJzxtWpnvbF9dglEYaEJn7aGHlLD5XQinyU11RR5taeHL65UlcpyR+9OzJHYZNZF/a3FjM0U
oIZSP16V6zeXdleRWBt4FuFVmRmU7fIPnfePsBXJeK9Q0htZuNyecAEHyEYBFZtREcpZWVxfSeXE
csw6Z609dOuDdJahT5rsEC89at2SG41JP7MP2duCpduBjr1rq472zl8VaT5RjLRSDzpTgLKR3HbN
EbXXqBzGr+HLjTHiE8qO7HAVPvKT61JqHhi4061FxOytnbJ5bdfmHFaHie5Mnia5YEbTeLtIPuKu
/EG782/t1QqyraRg46ds/rVxacIv/p6IyLfwrPLYC/aeGBXB2Rt1YD72PpxVfS/DE+qwTXAlWGGP
5AW6PycgfT+tdH4oul/4RbQ4h5GQvO373RaZa323wNcxh4lkNxjyz/rOc1Uv+X0v5bf5iMPSvDTa
tLMqyxRLarl5PQcgH9Kjt/Db3mrJYRTRyZVmMo7Kv3q2/BWoQWOlawZZoUeSDam/7xJ3ZB/TFU/A
d7Baa08888ca/Z5VDt03NnG3+tPR+zfV0m/wGUL7QUttSis4pluTKdgcDkH3FSa54ei0QALcee/C
yJjkd+nWptKvgPFEU8jpj7Vnfxsx6+mKj8TXiXWu3MqzIw+0D515TH4cVK0p03/M9fL1EibVfC0O
k28bPOBOyozxkYB3f886uxeCoS0UEk0n2iSzF0rLzb8joT/k1B4+1O31G9hlt5hNGkUQwP4SK3R4
r0xZYJhO32RdOETWeM/vNuP1q01rcGYfh3wXJrFzIJSbeFSy+Zzh9mcBfWm2XhMyW17eSqzW8EzR
IqfeY54q34S8Vi0vf9NnKWkMcrIuOhfpUtv4ns10+5svPaNn1AzeZj7yb84qH7EgydH8MSalJcll
ljjtQWZP4yB2Ge9Gl+H7a91drWcvBFsLL5mBK5Hb0rdm8ZaY0urrHutxdKoSYcn5cc8Vh+INcs9W
ltPKYosCBGlUYc+9P91YbNe48G20sWntbI9s11NsInOeP7wqceDra4E0UETwyxEASTnKyn1ArNk8
YR28WlwW5aZLFsl3B3H6ZqU+NUtVlNvvklmcOfM5WH/ZWhTw/YkuDwZaGT7G8M+7y8i8z8u+MdMU
1PBlvbPDYSwmc3ITfeZx9nklHp3qn/wmttG8l0puftMibdj824Y/6w4qKTxskhivZElF5GuBtP8A
o57eYVqZunbRDON1O2W0uJIl6IxX8qoVcvZ2uppJj/GxNUjXOxgTUbUrGozSC4hplPppoEJRRS0g
ExRS02mgYtFGaSmSwNANJTaAHmm5pM02pF1NiRahNWXHFV24pmqG9qQNSGmZxUsCUmm5qMyVGZKQ
ySRuKiXrTGbNLHQgZYFLSClqrGbFozSUlCC7FzS5ptOFUA4U7pTRTxSW4HoesQxWnhPRWtgP3wPn
leu8jnNWvBoXUbeS31RB9ihGYHfj5+wGetcVb61dxWj2fLxMOh5259PSpf7YvJLOO0OVjibcuBg5
966IuxR6b4ee6bxDcrd7vL+ySCEL90oFOMDp0qjZXEjeIdP8oTfYVudq+YON2e1cbD4l1mOSKWOR
t0abEby8/KePSln8Q6zLsZ5SCr7lIjC/P27VfN5FI9ZutVtLxNcgWJY5bZSDIAPmrz/wHIBrFx5v
+o+zyeZnpnNc6urapG1zteQm5H73g/Pn1qrFdX0SyRw7trffKg5/GolLQehHqrI17cFMbfMbGPrW
eakfdn5utNKmsVuS2C8n0r1y61ebRvDHh+aNQ8n2bhs8rx+leSIvNb6aVrlxAmUneHb8g/gx7DpW
iuCOu8LQwXNqdSuXR5HvNrRk84J6/Sr0cGlweJ70L5ZRoM2+SNocivNWa6tiYhJJGR1QHH5irNlq
ElvMkrqZihBwx61cW10A9D1yG3jsdFkkjQBp8ynjkZ/Wl1bUSktwtrFZfYzDglyv93sPWuJ1nxJd
arDHCY/LSH7ozx+Has2TT75bb7U6yiI9CScH6dqc6mmwWKU0uZH4H3j06Vv+CtUTTdYgkkfy48Nu
PpkVzvltISAegz1pixu7BVyT7UoNsTO9vjYNr8Vze3YmgkYn92c4z0q/r2radcaBNbRzW+9JtyYP
O0dq838uQYUq+ScAYOa0NQ0S50yONp1ZRKu4ZHGDVvm5Sk0ej2fiPSzYaOTcri1siJrfPU46Y71y
3hfV7C116W5uJBBC3mbTjpnOK5NLe4kH7uNyvqAcf4UsVjdz58uN3wcHaCf5Vn7zHc7fQ/EFlp2p
asS67bncEmxwM/xVQ1TWIGW0iN/Ld7Jt+QcBBn/lnWboXh6fVb9rF90ThC2COePY1R1XSZtOlZWT
Khiocjg49zxTadgTOm1XXdPubIxiVpZtuARxj/ermbS7soYZ0mthI8n3X9PemSaXcQWy3TbRHJ93
kfy61m9ah7bjJGI3EjpTTSUVl1EJThTaKaA6zVvFVtqOl6fYCBg1kmAzdGJ7/lS6f4oW10WfTPIz
5zljJ6egrWl8M6bpeiWU1yrGa8TeJP7vGQKPDOhWX9j32p3kPnqspRP8a2jFtVGnpb3h3Mbwx4kH
h+S6cx+abiJkyT90kdRVHT9U+walFeRxKRA5ZF/DvW94Q0O01jVb6WRcwWqM6Rkj5h7io47Sy1Tx
Da2tvCI4nOHXPGdx6fhiiK550Vf31FtecQuY2saxLq2pG/kTYxYPgdMg1Z17xHLrog8xAnkqAD64
GK0/GdvYWt79ht7cRlJFQn1BPNafi3TtN0LTYIRCpkkgU7u+TzxSa92625pffpcEzlj4kvJtIXSt
i+UmcMFy/wBcjNJpWvXul21zawjctyMS5XrXXWltZ6V4WttQW3ike5bBZsdP9n/61M8HWlqNP1jU
X8rdBtMakK2M/wAqqFNc1XXan+nUfMcdpWp32kXDXFm2yQ9eN3XsRTXurxLxbttyTbsqSCvJ9M11
HgtLXWvE+6SONY1jMnl8BeOhIpkF5Fq/iq1gkgQxxzhWCqBu5+/irjTThTV/shcybvWdWuIWWXcq
P9/5Cu76nFVbDUdQsoJo7bf5cikSEKSNvuRx+dd5qkUc+j60wkWYrdRqGKAfZRnp74q3o9npiaFr
EVm8dxttcvcYHXHSp5Y/zMTZ59a6tq0cP7je0afxKCQv4jgVSimvp7gzp5ksobfuUbip9eK9FTSL
YaRo1lA7wtfg7sDPmNnufSmWGjW2iaTqQlfZcfbPswlhG47T6UcqEcTFqOsy3LNHJM07Da2Mk49D
6Ul5LrO1UufOxnK+Znk+3rXSlY/CF8Vf9+Lq0yHHMqlu/sa6eIafPD4e3KGJ3ORLgFfwPNLliB5l
cQ6z5IM/n+UOxJx+VPisNXe3LKJvKC5I3EDb9K9HsxYTTap58hKKF3rc8IJCf4M8Y+lSj7CviFVw
fKWMjg/6H9nK/lUyhAo8utLLWJI3+yLMqHg4O0N/LNZNxBLFIySqVcH5t3XP417DqC6eG0fyd2zf
Gytan92sol+fzMcYxXHeKpdHk1e9Z3J/eDmPp0/KldIDjYllJ/dhyf8AZBzj8KtWlvc3M6wxhzKe
g5B/xq3pgkl1WMaZuOGBBfpt77vaux02SzbxpY+UBuA/e7OF84DkjNVFXav1JOO1LRdQsfL89TmU
kL3JIx6/WnXfh/UtPtRc3CFI26Z4PNaurSyP4rkj5x/aQwo7HzhV34jSONYMW75PJh4XoTgZ3e44
qm04q3/P1L7mM59PDd/JZC7+XYQWGeuF64p2n+Hb6+tmuk4jGQN3Ryeu38ua6jxxcKmi6CihVP2d
SSOp4702eby/Adt/t3Pb73B7UP8A5fS/kkl97/4JJy+k+GrzU5rhYvl8kDzGf7i8kD86S08O3F9q
D2URjDRKXkb+AKOprpvCEmzwrrp/d8jP7z73Gf8AGofh5dJHeakzeV/x4OBv/H7v9fwqkvft2hzf
gBgL4euG1CGyRw7z/cKHPHvj0pdY8Py6bMkBnW4dmCbUIzn6Vo+Ebpf+EohkkdUUeYdzEBfzPFV7
y5WTxUJN6hReE78/J97r6UtPcV943bAbrHhZtFjjDTo0rlQ0fTG7pV4+CRHI9q1yReRWf2owgfJt
Pbd0p/jnUYbvXSyyI8I8vLRkYwMZ5HHFdFceIdPD6hKL23az/s4JbLxv37cYNO8db9/vBnI+HvB8
+t+c8jeTHFE0gb+/t/u+uaW08Kl7Ca/k3rGkhRNoLFsHGeOlbfg/xUkYngupraOKKxkiiGOpPSpL
HxLZ/wBmWdp9o+zbLxpLgbMh1z/KpcaW9iTnNJ8MSX8d3cT7ktrc4YBfmZ+3HWskafK1y0EKN1+U
OCpP4HFd5/wlOm41SO1kaz866WWFx3A64HvUMviXRJr2ZwgyLONYbkr0cfxGk+QDnLHwteXV+liy
+QzLvb12+oBrXHguG5Rk08SpIlx5chueh55K+1WLrxhaprNtfxHzFFsbeUgc+m6lj8ZW9gH8lmvW
kuBMWfjaveMGnGdJfZERHwVb3Jnt41kjuLXafNb/AFcnripf+ENtY7k6c8UjTKhIvv8Alh5wGSKZ
L40jtWnmgLySTlf3T/dQdcA/WmS+NYvPkvw0vnNHj7N/y7rKwwWFE60GrKIHn9wCkkin++386rE1
PM2Xb3z+e7NVnrmZQxjTaDTaQh1NzRmkpE3CiiigLiGijNJRcApuaKKCRc000tNoAWkpKM0CN41X
kIqYnIzVOQnNDZsgzUTmpO1Qsc1LYyNjTOakOKTipAjINPjpGYUiHNOJLLS06mLTjWiZImaM0lLR
qAuaXNNpQaLhccDT1PNMpwqoWb1A719Og0zwtBeIqySagxUsRnaAOx7Vb8LRQeI4f7NuIQghHmCe
JcZx2Jx3rmrfxJINJbTJV82Nf9Rn/lkfap7bxJJa6eLS3QQvu3NcL99vb6V0qajKp1XIvn/+wNHe
aLPG3iFbIwJDDDbOi7kHzAD75qK/uo5dXsdPZ7eeIXP3hGMDn7ucVztr44ltpYLj7JFJLGmwseWl
7c1WuvGKybXjs4Y2E32ncgycntT5loUeqNHo9zJrAihRLiKHa/ygZHYj8a828FBZdbktZADFKsgO
RwCOlUE8Z6gtzd3a4zdptk9AP8+tZllr1xp7TmHAabO5u4z1waz5vedl9iX/AA36jIddiWDUrmNP
upKwH0zWcWqS5leeRpHOWY5JqDFYRZLRKrdK9u0R4pNJ8MoThih8sY4Jx1NeHJ94V1lv4n1eK2ji
WUhEGE/dHoffFbwlZbAdTPotlHbapqsyCWdL/wAkKOnLe1S/8I1psmqW54VX083DRerY6VxSaxqy
lwkjkOdzIVJGfXGKQ6jqkk4fMvnBcDarZC/T0pqo/wCX8AR1GoaZYnw/Lf8AkJHLFOQi9MgH9av6
o7XfhLThbxRvgZIGPlNcTcS6vcRMk32toh8xBVtv16VWjudShgaOIziE8Hrt/OlK8ug2ZkuVdhyD
mt/wm224kD2yzAx/eOCy+4BrK/s++lR5/Jcp/E/O38+lVY7ieB8RSGM+xx+tOD5CTsvEu60mtpcw
nIXACgHr/Fitnxuft1nZyCWP7OIY88rkZAzwOa81lu7iX/WSGTHTdzUT3tw42tIxUfwknFNz7FI9
bsbXTbG3aBJIpYH0zcJGI/4+COgrM094P+EY8uzlijvPtbbmJUHG7tmvNvtlxjHmvj03GmpcOn3W
Iz6HFS6jGrHo3hu9Wz8U+bfXUR2WuGmyNpOOnvUPje/s9SihuYJo9uWBtV7HPWvPmdmOdxz9aaXb
1qJSbQ7o3LiWy/s6JUuZHm3fNEc7UX27VjHHamA5FKtY9QCinUhpgMpwqM9aXNUgO58Ra/Z3mi6R
bxGVmskw+fUjFN0zxBaQ+HLnTN0wmuH83/pmBiln8IQWmjQXk90Ekuot6D/lmcDO2m6F4Vhv9Ol1
G5kK26PsG31Hf6VoqX8V36Ln9AK/hfxDFoct5JIpZp7cwrjoM96p6NrKabq8d46EpE3GB1rQ8K+G
7bWNRvkdy8FrG0qlOQwB4BI4psei2Op6/a2Fm0hhlK+ZwcpzzwOlONH97TS+LkfL5RsBT13VItT1
Q3xHDPuA3dcHpU3iTxF/b7Qt5PleSmz726rnijS9N026Sxt0xOJgjZbpk46D1rQ8T6LpmhWUEBgb
z5IQ+4nBJP8AeHUfjRTjBU3Z+7ztdfi0uO2pht4j36DBpQjJFu2Q4bimaN4mk0mxvLWKJWF4CGLD
n8M810NloOnWPhuHUrmDznuSSMOBsX161F4T0HT7yx1XU7iFZUgOUV3AwPoa0hC852eqg+b0sFjn
NA1x9BvHuYkVmdPL+brUEGqvb6kL6AYkD78e+c10/g/S9P1zX7oYVbeGAusbeu30qO1j0zVPFFnb
LZrHGZykoiI5cH/0DFNxT9lFPVw0/UfQz7zxRe3cE8KxwwpctmQKPvH1qHTNdvNNtrm3hXMd2MSn
1rtdT0a0l0q7LRwnF2saPbAAoC2ME1eGg2i366YqwfZNnlEcfac+T5nnetQoRuScDB4q1O1jgSMI
xtgVhY/8ss0kXiTUk8yKN8pM3nFMZG76V3T6La6Ra2AhEBa4RZJfNxvn3HHlLmrd14estLguJoPK
tZGuRF5sgBWHdH0Aq+RAeZtrepSXH2iVv368BW7D6dqLjVNUnaN5S4K/cwCPyr1I6DpwWS++QzCx
UtNsXYWP8a0yw0iy1W3sZbgpcOk7fvQFGfLqXCIzzK81XVZI181nRD3KFd34mj7VrDQkYuvL28nB
xt+tek2djY6guoRzyC8CzwhVKhfKOf8AVjPapVtLRtTns/tGYvssq/ZcDYPLHyNnpQ4wsB5fBJq5
hItBdmPHOMkVi3Ak3Evu3ZOc9c17Nc29ja3Wjxwv9mB8n5UGUk5/eKSOK4bxLY6Y2q3Q+0eWDMTh
Ysj9O1ZuEU9xnJW8txDkwl1JHJTPT3xU1q14848oymZuhXO7n9a1NIeSDVI005PtYPDZUbJE7ls5
xXWeHobODxuvkgPGEYtjBVXx0/A04xvON9tfyEcPcWOp208RnhkWZ87Cxw/bP9KkvtN1SEJPeRTg
NnaWOc9M4rWe7a+8S28b58pbxSq9ly3O3HY8Vf8AiJcOuv3EKkrERH8o+726ela04c1NP+ao1+SB
7nNSaRqX2T7VLHL5HYmn2ui6pdW7TKrLEoyN3cd8flXYfEO48uLSYovkVrBM4/iwq/yz+tLqMyxe
CdGUR4Jd8v6YFTUpctKtL/n3NR/FEs5HS/D+o6ojtbjKIcHnHJz/AIUyy8O6hqF1LbRhQ1v80pc/
KvUD5u3euv0J2TwPfsiDd9qb5j3GFz+XH50eAJCLXXmcRlntBj5scDd/LiqUaUHKLWqin98b/qSz
jf7Fvxqn2CNczf7Jz0+lPvNDu7WeKAvvkuOF8k7ix6YIHv2rpfAMif8ACSJNM6keRJy7ADp6tVa2
fzfFEDkLgXucZGwDzOuemKUqcebD6q01Lm/4I3sZ1/4Vu9LeGLzI5HkYJgHlZD2Iq3L4OuI0vC8q
GSyUNOn90Eetauu3UE3iUyGWHyheIxZGBGM9QRxXS32pWzrrRlubQrJGiwFGXLD/AG8dau1F3ulu
0Kx5/pXhC61K0ubxcxJbqWIPVsegqzaeDJbqKzdrnyze58rHPA7mus0fX7c2N4txc6fERYmCNFIG
7ik0/XdMWLSNupWqrDu+2KTk59hR7OhuI5KPwa/7+S4mZIbaTZvHJdumQKtnwJcxSsZWb7MF3iRB
lyDzjFa6+J9PkiuYYLtIWN7I8TzrkMn0qw/jnTX8y0E+0eXGFnYfKGjHXbRzUVpYDnx4D8wq8bub
Nk81pj94Ae1Kngf7WIGsJHCtNtb7QuMAdetaw8eWUYW0WTcvkEfaAOA3rioE8d21gkCI/wBty53y
HggH0HtSc6XYCn/whEd3DJHYtKZYniVjcg7Tv6lc9qjuPB1v/pkQF0stvHu8w/6hzEP3mKsDx1b6
ekjwXD3sjzxsVfgLFF/yyFVbrx1bLDfzRNLJJcxlVt3T5Y/N/wBZt9aylUp9ECZwlwuyV19GIqua
WWfzGL/3iT+dQmSsW0O45lpm2jzDTTJUiFIopm7NJuoEPpKZuozQA7pRmmE0maBWHmm5puaM0CHU
hpM0maBC0UlLQBpCQ4qJuTUuKQikzYiY8VDUrVEagCFmpm81KUpvl0AR5NSw9aXy+KRTtNUhSLij
ig1Gr0u6nqQFLmm5pKBMfmlBqPNKDTES5pRUYp3NC3LR2WmaDCuhy6rcrv3/ALqAejepqxoOlWWt
QGyRdmpk/K38Lr6e1VNL8TRf2FJo10GVd3mxyKM/N/cNS6HrdnosMlxErf2kT8kp+ZQP6V1vlU1/
LyrTzHY6bT9A0GLWLDS5LYS3GNt0zAhC1O1ex02zvobI2EETSXKhGTJ/dbu/NZ1t4v0lr611S5hl
+1IcTmNNu/Ppn3puoeI9Fnne7jju2n+1K6GVshADk8e4o5ldev4FKx2kvgPRPNnmg8okQfNa7snd
t6gV514fsrafWTYyRKVuGcKT/Bj0rWHjiCPXJL1YmEc1uYtmeh29TXP6frlrY6jLfPGzPlvJwfuk
nOTUcy57pf8ALuY9Cn4jsF03UJrZTkIxArG3Yq9qd++pXUlw/V2Jqgy5rFPUGKrYNer+EdbXUbDU
1+yQR/ZLKMrJtByR615OOCPaul8PeJJtEguYY7ZZBeKQc+npWsdESzube/F9oGo6p9nhS5W4iQkK
MDnrUfiW9/sr+zLqCKMvLZLvIAOWPeuO03xPcWcMtsER7aZ9zI3TNN1PxBdaoYd6RqkACoq9MDpW
ntXZadfwA9B8RalcrBo8YVNt5CqT/IOQ1Wm0u18/+yP3X2f7GZDFj5gSM5zXnV74qvr9LVJI4l+z
EFCvX5aD4q1b7cb7f++KbN3tT9r/AHQOpS3MPhHUYY8nF8VXuSM9K8+EE0F5EDDvcvkRMPvfXPat
WDxbqltE8YYBGYt/q/4jWTqOpXmoSrcS7g4GAyjbx7Gsasm3sPQm13zTdHzbZLR9q/uo/ugevHrW
KankuJrhsyuztjGWOTj0pvlOcDaefUYqBEFFXTpl3t3+RJtxndsbGPXOKlttGvrtS0MLSKOpXnH1
p2fYDOoIJrTt9FvbmYwRws0o6p0b8jUsvh/UYWVHtnUs20ZxjPpnpRyt9GNGP2pwIwc9e31rop/B
2rW8TySQqFjG5vm5A+lRR+E9SmVWEYG5dygnBI9QKXsblGLGV/i/SkJratvC+oTDftWFd23dOQqk
9O9VNT0a60mUQTgbzyMc5+lHsZR2CxmmkqSW3lhP7xWQkZwylTj15xUY6j60l8S9RHoHi/WLO70P
RLaK4WWW3hAnUHocUWGuWVv4PurH7Sq3JnyI884/KsxfBlzBpS380qL58fmQwMcfL65puj+GJtRs
5rtpkgtwxh3MCcn0rZc3719JL3x3LngfW7XRzfyXE20zW7Iq+p7A1R0DVbaw1yG6m4jibJb1560u
geFzq95d26yBEtYyZJv7yr6UJ4eiudZtdNtbgSrOR+8/u5OOamNJ+1ptfGoPl/w21BjPEOrQajrU
13FvMUkwfftOQAe1XPGHiK0117doBMAiKjeYOflHuOlV9f0O00meG3gneWZpNjRtwc/TqPxrQ8Re
FtM0KDa9zL9p2hgGBCt/u56/hRtQ0vb23/k3UOpBfeJrW48NWemBXMsAwT0Bx0zTNC8RWthoV7YS
RMZbk546KKsxeD9Og0OHU7yeZftf+rP8KD1x3pnhXw1b32nahqV0W8q1OwDtVL/mIt9le95lLYz/
AAx4gXQbuacRiTzI3j5I44wKh0/Xn07Vo9Qjj/1TlwCe7Vq+F/D1lrOt3kQBNtFDJMFHc+lJbaVp
eoeJrSxiUrbSs4cM3AeMdB/hTfM3h+T4tbenUGR3niwTWE1nawmDz5/tDMDk7/wqVPGsq4uXtke+
SLyxeHAwfetPWtEs7bRLm6a0EE0N55Me07maLt+FU7zS9KfwXZXcMTtM11tle4wjbv8AY24zH6Yp
8jfPffTmEVLXxjcxRwpPDHcNbEmGRuoFRDxpqEhnWcJOk77/AC36A9setGjeDbrVbN7qPcPL+7kc
Pg/w+v41LovgmTVrFrxjsi3GJScjn8alqa2kGxXPivUllMocYKbPI2/udvpiom8Tag/l7GEIjOVS
L5Rk+1dR4X0C0h1a/sLsxzolmSsi849xWVfaDNoeo2zwxpdpcE/ZQwyOT95h7Ucs+sguZ8/iLUp1
2s3l5OflGwk+pPekk8Rav5WzexXGC4U7se7V07RWNzNY6PPHHJdG4U3EiADap52bq34tMsri7utP
eS0aBLaXbaouHh8odS1P2afULnmkXiHWUh2o7Mig4OzO3PXDdqxZ7qaWQvITuPU969imsLS3vtO0
+KSGOKRYl+zbMtc7hySfavL/ABPbxW2qXkcYAVZnAA6de1KdJLW5JStdRnsyzQvsLLtJHoada6pc
2UpmhkKSHqw6ms6lrLYC8uq3Md2btJMTk534HX1A6Ul3qlzeSedM5kkznceuaziaXd2o5n3Yi/ca
tdXgQTyNJsGF3EnA9KY2o3bxrG0zlF4VSSQPoDVI0uannk9G2BP9tuAuzedn93t+VILuYcB2A9Ac
VAaM0ru4FqO8mRg3mPn61O12JF5Y7qzaUGqEWgZmzhuKY7zDgmpLZuQMA/Wr9zahxndk7e1FhmT5
hpDIaWWF4zzUVIQ7e3qaaXPrS7uMYpjClqIUHPelJxUa5FKcmm2wsG6lLGmYpTSYCE0ylpKQCU2n
U00ITEopKKYhTSZpKKLCuxc0lFJRYOZ9xabRRRypDCiikoEOBpaZSg0C6mtimMaeTUbVFzcjNMIp
7cVCZRSAfikxURmFMaekBO3Sq+eaY0+aEbJq4iLC0+kjxTzVWJY2ilooRIlPApBTxxVCFAqRRUe6
nB6qG4anRaP4ce8s5b2RvLtIwfm9ZOwqzp3h9dUs5Hhn3XCsdtr3YeorS8O6vbTeG7vSHkWOQkyq
T3x2qPwpNa6c0uqyTjzLXIjtc48z1OO9arlv8iki5b+D7JX0+3urpkurhsSQL1h9Kfq3hjStOdoP
OnWbzFRN/wDFlgN4+tXYta0u91Sz1iS7WCUTjzrYjIRf7wp3iPUNP1G5luzqKyiKeN4I1XG4K68H
8Ku8br119C0i/wD8KsRJo2M26Ew7y3cPjOK4uy0e2n1eWwk6szLH/vD1rtE8aWsWupL9ozatZFWB
OQH2+lcVY6paxeI3vp5QIopGePH8RNKUo/i/+AFkZes6Z/Zd3JbsRuQkVlNWn4k1ZdVv5rlBgO5P
1FYwc1zt3YDzXqGieH9N/wCEXs799OhlfeftBLYwI+4zXlp5z/k13uleK9Kj0GHSbn7YQj7m2nGf
YmtYNKMronqdB4f0Xw7qttq0sieQv2jZGzHiAGk8QaXpXhc6c/kR3KvD97s5PRveucbxdY29rqlp
bWpC3ZBjJ/hx61n6z4oXVrSwgdGBtYthz3+lXOpFbd6X/pBR2fiK+sLHT7GVNOs915a9fKGQTW7H
p9i9jaSm3t/LewLPGEHmE47d68x1vxUmqWVnbCAp9mAG7PXHatAfEORHtCtugFtb+SBu+9x3o9q3
zf4hmnp9pp/iSGTSI0WzmtpGfcRyyhs4P4VzvjK7gaSO0tkRPssflsyjG8jgk1BpfieTTdRuL1YF
cz7srxgbqxdRvHvbmWcqF8wk4HvWU5t2/ENDQ8J6fHq+sWtpL9xz89el3+j2N5ZaxGfsgOmL+6MY
w2B/fNeS6Rqk2jXiXkA/eJ03DitL/hL9RI1FQyAagf3/AB1Gc4FUpqMdVf8AzBHq2jhXsfC8T4MU
kU6yZHYeprL0JFh03xEsAwou41TA5+929q4UeNdU+yR2isixxqVG0YPP8qgsvE+p6dHJHbTbBK25
88kn6mj2rf3f+3lXR6rFHbR+NoSmMnT8ygDHO3+dZ+v4e10hrcMIDqHVupO7p9K8yGvamtw9ys7C
Zl27uvyntz0obxBqjqqNcPtQ705+6570e1aHc9J8brcyzullBMpEa+fJn5PLwKp6fDezrZW96PLP
ln7PfRtzDx3I6VwcniLV5UIe/mYMMEbuvtRb3WryxMY5rlo14JGdq/4UvbSfQR2dlFqMAlRil/Zt
d7CCwLICfv8AqKx/F8H2bVoVS63khCJGORH+PtXNx3d4m8xzSjJ+bDkZ+vNQzG4kOZCze5OaPa3V
uV/cHMX/ABEZvtQ868jvm2L+8jxjGPunHpWMv3h9RUmxvQ/lR5bDtmo1TvZknpHjS/xoWgJE0RP2
RQ21hkPj0FM0/UI4/Ak8AkQTG85TcAxT27152xdh825tvQEn9M9K2tM8PXeqQqUmiQO2FQtyW+me
tbe1coVE1rLX7h3Oj+HeoR2M2qPNcx25e0ZB5xGM49azfC98LHxLDPNOixCZhuJGOTwc1h6lptxp
V29rK8YcD5tzdqm0Dw/da/eG3XCDy8q6ng7KUKvvQlb7Dj+A07mj4g1G3uPEL3KSh0e4DiXOQAGr
Q8c+ILHWZLY204nxGiMcdCByDWbpPhS51S3vZRIubR9u1By351avPB8WnxypLer9qQA+VnGM1H/L
iST0bf39RdS5q+tWNx4V06yS53XMHDIRwMDtTdD1+xtfDOpWEs8yTXDkoqjirFj4Dt7vT7Gdrl1k
u+VVvu/Wqc3g+OGyhuftBxJdfZ1xyDWrXO6z6Tt+aKK/gvXbPQ7m8munkjV7ZokMfU9fWqmga8mk
a7HqEgM0UcjkqevzjmrfiHwXNBqU1jYq1ysMPmP/ALVYGp6Vdabs+0J5bSrv2DtkDr+dSm/dlbWC
t/4FFf5Eu50eq+KLKTTZrKBJyZ7v7U8j/wDoIpsnifS20BdFEFzuVvOWUtwDXFFsetG6sZTk23ca
Z31v8QvIgtkW0wUgNocHhlxjOKpReL/L00WE1oHhW4MsZWbB5PQ1x2T60n1qfaMR1+l+Mhpl9e3E
NnH5d1CY3jLH5f8AcOOOfSrMvj66N3a3EUMSpbReWsbHI8vuOe/b3rh8+9BNP2j8wOqvfFLzxjyr
eGCTzfP+0KSZt2fX0p1x401CWFkX7PFJIm15k4dh71yINOGCaXMxnSL4y1IIinyneNdqysMyD6Gs
Ge5kndnkYu7sWJPqajNNNEp3EPWn7ajV6mU00SRMlJtqZhTcUrDG7aYVqximsKYEBBpMVKRTMUrC
EpmakPSojQA9ZCtaFrefwtWXShitVF2EzoJokmTI61mSWxU0lvdleCeKveYkorSykiTM2Ypu2rks
PcVWK4rOSsMZtpuKkppqShtNbpTzUbNSEyM0lBNFSSxtJS0hqhBRSUUAFJSUtMkKKKSkAUlFFMoS
lpDQKBBSiiikxGmDlaTFJGflpScVBtchnOBWc7HNXLhqz2PNAxS1MLUhptAh26pYjUFTRU4gXVNP
DVCtSCrM2PzRmm0UJi1HA0uaZS0DHU4UylXqKFvsCNnTNJutQV3hHyxjLN2H41cs9Cu7y3uJkKny
OqA5Y/St7wbPDJoWsWQZUuJOUyeSAOgqDwpBPbXslxJKI7azOZ4yeXAP+r2muhKOmvQZWsfC13cQ
20ryLB9pk8tFkPzZ9cVoah4KnsUmMl5GWtwG2f3gfTNbuoT2+rajYanYSotvHcojQlgPLI6tt/Cr
Hi9JNUuZSjQRW0WyQyKwy4Ucrx+f4VVorsOyOfk+G+oCS0wdwuE37h24zisIaCG1GSwZ9rrkKfVs
9K9UXxdFb6vpcP2iNraW3AJ3DCNt7+lefOYZvFZuBKixR3bT7iflIjPTPTmk3DyGcvqWmyabcNDL
wwqtbIsk0aMcB3VSfqcVv+M7+DUtVmmgIKdARXO265mj5x868/8AAhWatzrtcGej3/w5hhiK29wX
mFoLwhxx5RHtXJweHL+5RWWLAYkAk4DEf3fX8K9Iv/EumWSPex3kM7PpItBGDk79uDmsdNe029tN
DIuFgbT33Sr75z+NaSceby/4IHJ2vhLVbuSZIoWZofvjnitGy8Cakbq1S6i+zpM33ic4FdhZeO9J
hutXk80oJZrfaygfNt60an8RtLKnyG8wi6DgEYby8fzpv2dtLDsjMPg6xnW6gW3ktZIFysjHKyY6
mvOZ4vLndP7hI/EV38vjWwtUupIppZnuEwsbj93BkdAa89lnDu8h53lj+dYVJPoitLHeeGdBttT8
OXlw0cZmWcKJmxkZrDl8KXSakLFgeV3BhkjB9T2/GrGheLbfSNCmsGid5JZQ3HTANaEnj2I3ck7Q
fJNB5RC/eU465rSDp2ippP8A/dgZWreEptIuLWKV1C3JAV2PAz60/U/CkNhCzfacuO23huM/KelS
a14wi1b7GTCSLTGA5+8B+uabeeL4ZrJrRLX7xzukbdt4/h9Kiap3fKI5LJDEeleg+FvA1rr2lfbJ
Z2jdp/KQD1rz1jkk+tdXofjW80WyS0hjU7ZvtGTUwstwudHqHw+S1mt/KcyoVMjHPl4EfU1leIvD
NrokumurmS3ugCQoyfpUEvj7UpSpYJjaU/4Cazr/AMV3d79mEiRkWrbo+M1fNT7D0OjuvCWn2dm+
qlneN0zBbjrnHVhSeFbRZdC1x03hkJ2g9DXMv4s1Fy0jSfIwxsIyvpwKhtvFGoWUM1tbsojm/wBa
MevpxRzLcaPR/CPhbSb7Rlluo90lw7AkH/nl2PpWpeeEtDhgneK3Ct9gDxbj3zXktv4m1Kzj8qC4
eNM52j1psviXVZSC13KcDHWmq9ug7I9IbQNOj1nw9H9nVoni3yIcbS2OhroL3RtES1utlpDEz2tw
27jKmGT+teJPreoSFXNzJuXoc8j6VFJreoyAq13OwIIILk5B7U51nJWCyI52CynYCeSBweRmu58P
6M2n6XFq0ax3l5dHFqrOP9G/2iM8GvPRK/ynd93p7ZqcahdBdgmkC9doYgZ+lZLQTNDxALlNRlNy
4eUnJIOR+Bq/4N1uPR9TMsnAlQozDjHGMmuaeVpDlmLH1JyaZmmpLsFz1m31rTPCSS7bpbo308ch
2YOyInODWV4hTT9Uu7jU/tqKJEDKgI3E/wB0+leeBqCxp+0sFz1HV9eii8LadDa3qrLGuxogQW2/
h0qCw8Q6Zc6DZWc9z5U1veGWTf3G7PWvNg59aaT71HtpXC56XeeKtPn1q5mW5KRGJY8kfLNjrmud
8V6hp13LG1nK8uB8+77qn/plXKZozT55S6jvoK/3qTNNoqSGP3UZpuaKVkAZpc0ylzTEOozSUlAx
+6mlqTNJSsK45TU6PVenqapAW+tJTEepOtUAtIaSlpMBpFN2VJRSArvxUJNWJKrmkIBzQRSpUpXI
pCZDUsMxQ1Gy4ptNOwjWjmWQc0yWPPSs5JCpq5HcAjmtLpgRsMVHViTDciqz8VLVhoaxqEmh2pua
kTFopuaM1NgFptJmihhzWFNNzSmkpoHqFLSUZpiA02nGm0iWLSUUGkISiiikMWiiiqsXoXlODTmN
RCns2BWNykU7hqqYzViQ5NCJmmMrEUmKveQDSeQKd0Mo7TUsYOateUKQKAaaJY9F4qQJT41GKk21
pYzkQ7KUJU2KMUAR7KQR1NS4osIj8ulEeKkFOpjHQyywOGjcoR3BxU/2uc7j5r5f73P3vr61AoFB
qhkgmlHHmNj0yR/Knea56u3/AH0f8ahoqSiXd7n86QyE1HRQAHmkxilpDTJI2NNzQxpmaY7km4+t
NLZ5PJppNNzSaBMkDUbqipc1JZJuoLVHmkzRcLkmaTdTM0ZpiH7qfuqHNFAXJdxo3VHmlFLUB+6k
3U2kpAO3Uoao6M07jJd1NNNzSUAPzS1HS5oAdmkptLmgeoucUm6mk0UgHbqCabRRYQtOptLQAtFJ
RmmAtFJSUAONNpc0tIBKKKSgAop1NoELSim0UxkgNTxvVWpEaqTAtUUxWzT6AELYppemvURzSBjn
bNQMaeTURpCJI6sCqyGrCmgVhGXNQuuKs01lzSEVOlG4inOuKjpoCxHN605iGqoDinh6bYIGWozx
VgEEVG61I2RUUEGkpiEpaSipYrhmkpaShCbEpaKKoaCjFJRmgQtGM03NOVqBoXbSFadupC1IGMpR
RSUhXLo6fiajkbippOP1qnI1SzQhY81NFUNTR1DKJhS0lFBIVC33qmqNutXAGWoelS4qGE8VLmtu
hAuKSlpKQBThSCloELS0UUALS5ptGaBjs0U2lzTAWjNFJQA6mOeKdTJOlAiAmm5pDTadxjs0UlGa
hspBRRTaQDs0maKKYXA0CiigBaKTNLTELRSUZoAdmmk0ZozSaHcKSiloKQUUUUCDNFFFCGFFFJTb
C4tBopKkLi0tJRTGFLSUtBIUUlFIYtFJRTAWikopALRRRSAM0UlLTEFFJS0wCnCmiloESo+DU+7I
qpT1bFNMZY61G605TTjTaAqNUZqeUVXqRD0qwtQRipwKQxScUwyUP0quxpkkjNmoGoJpKACjNJSU
hD1fFShgar0oOKdwJnWoDUofNNbFFxsjzSUNSZoELSUbhRuFAxaSgMKCwpCCko3Cm7hTGhaUU3eK
TzBQIkNJUfmijzRQBJSGozLSiQUhWNCQ8mqkhqzN1NVGqDVDV5NTKMVGnWpe9ICQGlpBTqACoX61
LmopOoqooTLEPSpjVeHpVitDNiiikpaBDs0U2lzQMWlFIKKAHUlApaBhRSUtMQuaWkxSigApj9Kc
ajc0hkDUw0802gYlFLSVIwzSUUmaQC0UUVWggpM0ZpKkY6loFJTGOpDRmkJp3CwUUUmaGxWFoooq
Ri5pKKXFAISjNFFO6EOpM0lLQULSUmaKBDqKTIphmUUAmSUuKj84UecKdxj6TNRG4Wk+0JQK5MKW
ofOX3pDcL71NwJ6KrfaaPtHtQK5apM1TN17UfavamMu0lUxdH0o+0Ggot5p2apecaPOamQy5mjIq
p5ho3mgC5uFODCqOXo3tQmBorKBUnnLWWC1Oy3rTuNFuSUVB5gqA5PelC571Ay1HKoqcSrWeQQac
DjqaolluSQVAzikDxnq9MeSEfxfpRoIDIKTzfamedD6n8qY08QpFIkMvtTTLULXEY6A1EbgelK4y
15ppvnGqpuPam/aM9qVyS55xpDK1UzOfSkMxppjLXmNSF2qp5xpDMxpuQKxa3n1pN59arbzRvNTc
C0HPrQZPeqhY0m407iZb8z3pDIKqbzQSaOYRa8wUbxVUGn5ouImLik8yoaKTZSJvMpfMqGlpXKP/
2VBLAwQUAAAACAB4f1FARlMDoQVoAAB3aQAADAAcAGFzZGYwNTk0LmpwZ1VUCQADxL8+T6/APk91
eAsAAQToAwAABOgDAACd/XdcUv8bP4zjrCwzFSu13AvcijtFM/cWV44sN5iaOcqJNqzQNLdiigsU
Fcs9ymy5xYnmtpy5cw8Eb96f3+/+/nP/cz/u83iAcDiHc71e13U9B+eAZ2NnVMBl0weh7koKMqoq
MvKAs0mALuA8M/M55nPn/7dcuHCBhYXlwv/vD225dOkSy/95dIn1MisrK+3+MhsbGwcHOzsXFxc3
N//ZT7pCAICOie5/C+D/v9DRMzAy0d72AstFOgAD3f+9/D9evAKgp2NgoGdkYGJiZKS9EkV7DcDI
zsQhKK/DzGn14JxQIFAhNrngvPDtqm9c1oP/RBTdHj+7wHL12nVuHlExcQkQGKKkrKKqpq57R0/f
wNDIGGZja2fvcNfR3cPTy9sHjggKDgl98jQs/PmLl3GvXr9BpaSmpWdkZmWjC4uKsbiSUnxZdU1t
XX1DY1Pz9x8/29o7Oru6h4ZJI6O/xsYn/szNLywuLf9dWd3e2d3bPzg8Oj5hp4VMz8jIwHjuv5Dp
6J/8Nx52RiZBeWYOHatzDwI5hRRizwNvJxdUfbsgrGj9j8vt8SDLVRHIH9Ht/6L+X9D/72J+9v8p
6P8T8/8J+ewrgP083W8GAQY6IQA9O4CBHXA2AbjEQEd7QnsMBfz2KYHBgUArPYAMmFi2WNZYnmGw
TAC967lnpqprF2hcWKsocGVwYYTEAHRfKrkPino/ePBY0oQ+fYC9jTE7z6p0QghXlwIIRz2bk7vu
lqwfsYdrVytXkV9vu/0K2A7tIYqnzMRVOJ32SerGzd+UYM+QfuMcZGiZKOfrEn1PdSktlo95cBdj
HNrYixRIzoN/uqBh4DhxxbPZG7LtuUt/Da2Z3rUs9zlO7dx2id8ttu91LsryMLMreLUOY81kr7v1
4gk8MN7LHTsEn7kOcW4xbEcpUF07gfOKpgFkkJ+YiKB0Muui7n/l4hiofoeFPM/HKuXQ1VrpGTLJ
IhzhxXRGetJyLBKFz16x+HHjlp69gr2V44kS4EhJG4IBiiG1PAA/oJX25WJI4TMJevUQpZfgAYa3
+ojboKx85gGQ8YAEHVivuE3Vkn7ABwsBSLMaoR0BOhY4VAgAuOoH5FB/D6r9Y0M/vJJ2YngONppt
4XjfuK4IIbQ6bWBB8Cb4TGrzsyZ3aPrQT/kTTwWssxLeewO5bfWB0bYXDfu/Mr/jeOjARowr9P3p
L2xWq+crvIN0TO15Jvt5FR6LETacqa26EYLHNr5ttG3TbhJPGL7tSfbcFX8T7n9fcb8y1a6OFPyJ
6SlOjBsZqr0uial/XZGskGjzzLf6y6iU6GCv4nIvf7B7i9NYaozcrRIR0rMuA8cIF2F6rkeIT0ag
eSUGMdAll0DLrifXr+sQ5fSE94nQ9bxaAXD2dJlCxXTZiuHcqp7+L/aDNjlwFkIoxqaamJfuXKUk
IHwF9GJIDjIF01a1if92bqbgJuKne5DEvtKjqTfroXw3mtqnp17Ncw0r5Bb/ki10NLrMwiZ3iTNx
5Jc8n/0fl0dw4Rx8x9p3qyS5X6DSx0wh0QKPpi/7prX8ZQqynZoR8wPy+Pty6oqhJEqlQLWrfgJA
208WrTarG5mzBHyy8F01YC1+KCHI8UqXEFEzDmx49U2jUGny57k8MOzqFZ7HBksg4fxysXUrickE
W1BYoF2yWumyqQKpNhb44RdvdLqRHhyh+3pNTR8s4xMfOldZtFGWsWD3wljitntQHiJwV8HGYYlw
OzSUuVakxr+sJrcjBtwb3/gua6mUuWepIk7AeolBeY757vn90o82Ub56s3mPEIT28zfVhzwLr/c5
VvhNgS9GEzD3wMs6FvnXM9nXES+e6Tl9Zm1VXbP9FM2VNmhYbiaWgQ4fvZTfJlGMzWcqTBiSz3ez
MtKTfykNnAA4Oho7AuT14UGmEKAMHA7yARSidLQvGpkYaV80hMNZAWIS2HzrZjo4Lg+ejaPnSXpP
qs3KZ3R8WowFVtIPDeqDpgBz73hAj0DOTFjcEMrNbWjIei72ojkwCwvcpBVq7SoHnZ4mPB9Ggn3k
JNxreKa/8t5WtPxj16OenWVPSbrid+3lu9VUt6xf7CXspSdooSq0edgJ+v3kpAG12lOcksK2A+kG
b2XcU+HHguGb+ksra7CoAhjFkV4TARLPs3r7k834giB6RjX2+KVZyfUnbIo3ETU6oDV0pNX9XTMO
30k5p8EG3qATu4MWN5ngRs9EuUtmux9vvn2w8ij+zTPO52MYx+ltOhJkWu3KLTPgPCa15Axwr+y7
mmx14eMO4K5oIRvMVifDHxd7f+ldW8T+PS5wcU2P+G3EGWDM5lID316cxtPm5qH7nmEyp3nw6N4o
VseMVSVVHVuP5seq2Pvs+V+J2t/0hE0EVxGKqdp0QoVieTYkD9vzYBuRKwhBWFtXG/uU9dh6pNpj
41jK6orj9L+wuUaKKLW/oWdBOCkHGzy8duX1P4fokMGoyxEa79trc0S+VnodnZ4BXgasNrwJErNr
mhzetbNW0lM0xRJFPayy4LXzZhVv7xBF1VH5HJV3o05K7NYnH8aMph0K5sjvlUgzL2tEm4/wLCtV
ZWMvK7M5Jj5IaXU0DEIld5iDCq7KPH0RBeYNbWeOdjW++ySd+4a1lDdcqPTOacAZwCtbawprd1Em
Ytj1MdrC7R3Rgnp3NMSxWWReqGzUxVjqthoRPvF2soFz426g7VH85fRAQXRo6Jzbzz3ugsJJqx/B
2wYf2drfD2+ussIHEovOXWZ1CGMG5xizx2iewLxCzxVUjBeKeJc6L5XXdmj+3Q0yvMgeUq5Z9t4c
gVS5iYj58EiXpUCgPKi7wvxr4Ka8rUj0WMWCIxjtKSPR5tHNgZIotrTSA8ZIFKIAxsYhwK8gRUPE
rV3DC3BQdhEEaGhYpMQO8cri8McSdZsxzTE3TQx5EgboTFBWxj50tWm1/xV5bW0tYAIEB40xFWag
lBlpHCaZIFHComuYTFsZPiImr1MyDCiB0Y1jmdEgPYA6xhR4wi788haMybD2a3WBvlxQh9o+wdep
ABhhDbA4fOsh+nBCs8JHxTMJCzDLyQ5PGadu8ccx8Y+nQmcutW7RQ3NNKMUdr4suJr7iJ+hINTRA
o7JbpzspTADHxPOCZ4C7It6Udtjpm2K/2xOXXs8pRHzEOcKHjA6rW12pLcYnkfL0nmiljvJSap22
19RsD+gYqA9KhjJnwDfe/Xk8wpZHONQHSXd59aUm33JOjrtxYg+v6CnpKj6P/cz0ztNmX6yRSO95
Dcx77pa9+5yfygaPqbUBz/PzvB/V2uADqa9TNifkX/8SK9MqAF0HsFRLdWxfioI7zszcuhrSMYpN
8+L2d92Sx4VZNxDgSn2YK/NLWiO2+w4OkcnJ+1wC9leXGwvyLdWEsqUXKlW/lsUZsTFum97ZYbz3
gqdyE/MdhMtBAbjLFM0hP7QB+GvPrVB5ojNfYa+zsZ7CG2sw416E00Xm9vCRnPhHZdHpfgoyDzqj
H+xXkH/s2q70E+9mmmWUenKt1FpZMgfihngcn1sWomjcGeG6/6x8pFw+264WZ6JcdgcY9hR41PbQ
o6sQb3J5710COrJqDyf0s5+KYlKe8hI0S836WnL7UYwtnRC+37hcfdeR/R2TPVqIlIVwv1e/kW7o
nUTwuScmv1/GPTF2WJG3KDTll/v5MtSVAP8wwxZ7HHg3OfC5Y6lC/ujrDOO4kuk27Suxw8BPid+1
CQKDV4WyLx/1u0WBgwF82TiO64J7eCbl8w8/6skvL0KxdhFiCVGL0Nvgn+l0iN7BCyxzxcLMr5tK
jCXuW3/+Ft2kBPPpUNL8KrIwLORcGYiOc1Ts/r1rqGckPqPErpQQb+gHhAVZ275bVbTKwPkXCz0c
RL8KUdVk4NcDwq4U23jYpP2A4e24zfDypjg6I/NJ/QlGhVyT+re13bdRj4qBhdhYgcJYPQCtwulp
aiX2LbYNaDt2e1CPHpvgaByi/I4JaKUjqF2I8nHHk76ZmJ4bblPcxtKXXgBg8620s7Yt7tV+s5am
Fzcf+QR352m/OX17vz2sggufYU/dB/grbTyDsqecQzq6+66qxjEmUdZ5OrPT5s8pOd0ipfmaIINU
xXuFk/7M1TjqB3zunYXp76JeL6E5RZgxlh8cs2yFuPE4jfbtzudSGLl54SRXxGrl6d1yUXRt8uR6
k7X8x0StLa6+v/evPdxO79DaH1jLqMdjnUqbXn9mf/6Ra/o5tS/IfiA1Gb0ZVv0kz+h3cJm/qHsf
4kdv/DD6TaUKklVX4lXPfvFOm2prnUHjQEw0MASnNaGLfsA4fOUF6gEi+jv8UjAdO470MtAMAui1
2Y7EFTDjkpYEYIkLioXD/uZgkyYj5rK7d27v4ytVYXuEZu59OX+2Xl/lIKLr+10b0QoPxGufQtSz
hM/WwyvpTC9peo+13O4VB8HuJqKt9WSEALrSl6319BteOOm5bb6IqEOipSqh9yT1ttyI8AFOkBe/
o7D9nChwjlz7sw/ukFuIudTFTT0czf1p0ShrLSEDWMpvarykNber11PW3gj9YZSWsKETu0L0Ssra
tdvM4ku3q161eiybRbcpeQ8y/6/CgR/O7ziB0qkL37UHdnl0LanM3HvPhpV8WyW3X668U9hRuw+p
0f9iR7dUV5WbcCe5JtFX7/wDW08WZfdtLFvivqhQb9FimRRPRVRB4OirbO7ANiaHZ+JCJdPoGKZ1
hOftabDDutUnvjSK5pPcF954bLMpC8FPPHBnCMQVELj8Rd2rwIY1LzAWQzAKHk//Unee6CnUXne7
vSQ6/W65jNUuK1EUCKte13iDtoSnFb7VYOoikero0e8tr11NBdZayisPK5PS0m/z6oP2rD+2zyXA
aozQMpJvC1GgS4+wxcBaQL7XM3lt1WJxSMd92srzxiCfkkdXYCu1tV+NQYFGxr9pJS50GwUiDXyD
jxUDV92BLI+KiRJlV7bNcc/NgTGPuIRYdKylAdA6Fcg/UGQ1PEUhlUsVldmjlRbzgsXUhmpVPG56
PmapRGfonQTeHjgoNfDRr1xhmTERPFq/tKlhYJUiOHa0z3WbYabCpfcf+Mc7m9PTiNEX2dFm4mlg
L7dpJsXlvdLrs9J6guzSt4RV3HUatOKyrnB8SedVqXMka4TzwOshHDazprJ2xIYW/QG6KWseMCf6
AdH8K8vbKm0FcB7fZQS46vL1uTKNd8RPIIVa8ucNqLFnggM30SzsbcmKY8trp/ekkdvmdQUCPTy9
absOnSMX9BRQMSBrtwzU88A02GvcgGG6iFkdiUyylRJediXYPAHWqxShb8eb97bA78M+htuOkRrb
/N1J2GWTv3Cmn+W/lEresHWzPz0oFUW5bqK0dZaNSVPE0eIJarqbwB6dYY9KC6eFVD49G1fhg3eJ
I8D63QePVTfM3nI/NFqzOixXYQculbP043VJPPWZ1gIMN8ESL30NWLhusAxyoGYD0n6fAYx5bZoY
8PM08/XbJgDwDWeV55/dJEwQbAzQtVY4Jf0DcZLKl6At0H5EGkGxp2vF8H7NR3xRS7LzI+39trsf
a2QFOq8r1VEwPP8sg/8yARIfL5GJLsXRqmVvZKZ+252ePNSm/nu5V8bhpHtdOCHW2IlHLyslah2t
/bSkVwuRVOdm2975tKwdF2QVgufgtmiTmXB8ws3uaOpWLJQKjPEKK5fPA7PWKTySoDvG0lTzE160
op6oxmuaCiA5F9RaD1k9cKDpDF0a2lrS0W4CNPK5nmY9aP4bmI1D+8NjJSAwusIYfrSVKfCP9rM0
HmdrdyBg9RGOhr0N1wvfg+TNudz4mFStWR4B32VtW2P1wTY4IVsu9blCeow2hz892isAkYiSYkDb
KfHB23N0BIlqcIBW2j9NfLGYc8NfxF8USJhVqkhy8gtYkpdbRijVR9PAmDQCuVBB/BL0KoEzCes7
kJO9KJWKkePPx3ETruWL/ytBehkalSA9TP4iwRmM/H4vgp/vlk6cHqCg3R8q40HrcCc9sII5iC7x
8HHeWNkGpKTF98v78pFfu2UERuGj0dgi+d5XR2VXWdccOYq1adT11j5AJFitWCHHq2iJoOb4Itkw
RT3v8nUbNfzvxZfORl77eRu1mS9eKvn3iVpev/IYjMt/ihhZN576Gr2fLe44nLqlMlQjsuageFtd
orCYxcbKDK9y07QQlXIb+2rrw2gh3o28tl9e0oitImm3fnKsuyJUUOs6Le2iN9ec0S4k64jx8Vwq
zxi3A246D9HXTAYZvLv9DzGcvIjW06DnRwAe3zYNwy/GROWoLgMXAhdJ32LiNUtTBth7V5P94oRn
qvUQqzVhuep2hhXhGY7x6LGGP0C7W2L1+Qw+BBkjtVs21lHDe3gRZxuxt9qF3TpY+uJMgpSPw7Yp
8/npMQCbUsnVrMh62Z3fIbj414LcDMlWZtFe17s6Rkv11tSYylkbAzJbd/GiLcmvWQzEqt38+o9g
j1fE78XFFrYt9F5WXp4a9XgrErOjugabMezLy6rY2Eise09kZ3yFTngH8lizMhr66C4U2lUMnNn7
Y5SmnjBoVioRAoSZAWTgujCJspvxLHCE6Ip5foYWypPrNj+t3Vn4jcwKi3VoxSi/Z/UfsWvjXnmI
SgNr16/SpDH+ykt4VslSjg1AAgtszKexuwkKEOqDGy7TtjIvBp7UAkB7g+ZAeTb69xIwY/VhwwsA
vBU8HtahI/KGt5UFm5TPXR64wvM8uC6Vehzwr3DUVfB5YmHdsEvTgwR0MXNwNB9pUfVqL3RGELkn
ZZcWfZHU2aXcs5/+lIIAKeVUUHagPLF1oP7trjNAFI+bV8pT5UjqzkHbNfJkF57/O9r5vOnJz4df
+TOu1/TjHvtemnFW2TY6GVaU5Es6A0Ri/pWJZkxaDD94l1RrAmb4xsCIquGAXxzlXjjYlUfnv+4N
fH5se1R77Mkv9Zi/sOHIVliNpz7889V5Cr+FLcMz3F2RJdxIXflWshhqysMT+WQwCnyQ/OfgSmme
skuHuFDFEaqv2yaB+50Ca6N4MkrmJSP5RtDqk7eHVgZD8rYY688B88IrbX51LSngJZ/Vmo6S5Ww9
Iy+NezOYY/95KpOVkWgvJtyId1upWj+txZP/sA9xwXPo12anxSkDkO7Fimx5tFi5AjTIyXpqhdLA
U3aoHPMIV3wJd26o6Bvhggyh/07ZkHFJ4QDE9j5CgdXc2cYTf8kL7KMaaLlZrtwoo2jL2rsQ7Iic
UnIkx4yEdtn7G2BhJI3RD+6iTS/Ft/kR3akEX2MtgwOulKlRDhVdGiz1stikTTjqz9HcEMALG59p
QdCBfX2kUx63YLjuB9jJICQwVeRc2JELt/0BqkyMu6mX+1Jo2i/hA8E24/YIm5JojgLbNBv2Hmqy
tyFhO8GOxxkj6411rBv5Cbbvcd/QjoedNlpNkTLfVvdeXrAVLvVXI6udIuqmp2oSHn7N94oa7CoL
8QrHzxSV9liOTjeK2n0sJEiIT8g/t3vp7rioPxA0hJefyzCpFm6faX2r7SkSxF2md8mrC+8WaWt2
rATWYjXbF8hzrp4rF0puM/Xsv45bvomfupMcaCHypOy7sctStqHTuMqHlbu4Wo/XEIfl0RrnuZpk
n9jVC2xcGqTLklethUpQ/mAra4cJeYs2IKBbApKdX4BD6RqhAe/kSgK4XCFez0x4X8r8sfRKGDDS
0tMqZ4DJGrNcRYUol9LTWkXiPwfpPDTsQ7QSQjv6+xAB6ig/IGDdEq7L4mtJZ2IokX/uv6mlwXhh
MRDQWMLiBZ+LvQz8Ywj6HgOE/SIIcAklIt5lg0deZypxoGrOl7EX+EgPLD1oDLcrmVzXnhv3Fb2S
NyKevKF9ta+AnjLp8+o3iFCOHD6P3EqmcllO5nUjwfDYV5ZIsPZd9VaKgs4RDFkn4s88wFZnu6NZ
ZvjnW5kgesJDH27pXn4ZyrMvaRKcKPI9MS99uRnousJO5VphvyTAZR29wlDlDEXVDokrlKr6B7l0
rTjHNZUTb3yB6bJfHEiG0fcZrvRN0s2VG5WoV63q+ZoRjNlOss4A4MqQZf6d79Du0lTIWMOhxaJl
SzwymGpbFqkj7utg8AVc27zYg+yRMBiwPN+d0pv0B5puH+FFXSkfRgxj/sRTj8oCSnunM4oLy7UN
3C0VVArKzcIE18HnGoN+Ac/HFJR2o5MxkO/t7ypU/CweXt629C8PzZICdQQqFn78E7ZX1rBMcKlr
nzmH6COpEv0G+vGJywsp1ayIpuMbozpK/cI2kEG0Mfgc3phm+H1o4s7oNk8KdBWsnqyeVFoeN5fR
Ye/L89oee4tkyZ8c/QzHNVQvF/EuWf+PBeIFWlf0svztDaLdtP6qtstuWnDpdI8N5M9Q1mtxfhlE
ZniT2hw+ry7T+k2h0geA7vX5BqWkm3Anb65C9qdpPg6X28s524yvnUd8Yolsc/DSUZK4D67qhBSs
OIdK+18v8Td79YvLKUTBoPCPm04XPhBVzvmetIC2v8/ReXuuZsyrwvQnqnw33EpAMBqsoGiRSlCu
kRa6ZQkysbYBvmEStgRdH+LmxqXq4HgYpRUyEngAxhJt1/PfEYFuuShPAN5m2AaGB2pAVj25888N
0srvj6GeBMQrhtcUsmuaz7xrTttOR9BIT72U+bl5MX1GDNDKyLwNIAGk1efTNoB+YR4okIb58rTt
0lhCr9T+0Qauwz5mLeJhBP068IDQd1Td+bLtSyOdBkra8HHwGeCa8dBF+EzpeFsrAU5A88Vl0Xc8
SHRAoRykLKZTKnIVKfkI5eHW6dO/d9LMavl3f+2VfsaeQzUH72jAtPrrCRxE6YvxpWsDv/I/qA9R
TbKodX/LD+1XYFaaF2JOlkIa/fxz3rizTnkwuICEuX48TexKefw36NPQazGX7mq4nMppfdIul83f
qjNAOJT818590oQ6u4SoEcnfR/aOyCu61ErtyWOOrpSKDEwhg3a5MvQ6/+5EexUEqVLVzp2yYF/X
aGUnzpW2xLN4pPSdO2kvI0JmZxF6bCljqMqBeYJwj8ph2dUUXdIQnccr+gKhOK/90h40ILS7xud8
OO7GyJriLtt3tGJpcEZKUs3v+cWKabPYFftoYnr/fUmxLWHU4LqpaZe5ANSxmyD5Yd8jYtTvPtFy
giZjPMEShcmlVnpcAqKG70keNsl75W+kc0XfULpHasuuih+6fQARRtulPEYsU+150ZWwZeC3KzeG
f2HvNo8JO9sGFyvYcOMvAyACxZmxuvetcstaLJTs+pUyrVLwBF+r5LsXSXaE7DkCXeGbLNdRvDJ4
1bDgujfBa+vbUuVaY7vh9yI77lJspG1QICpu0A4SC5t5ZZVYlyXjiP5lGjEYfBVSOMFLuDuTV9h0
BlB7s2a+m4Q/XVETqCrXkFEVKr22lD+7ZdSM7QwV8cJtlnYVEyXT3j0pQfngAaUP6bPgS1k+pu6s
yu/htTTMY8LS50nQ5ejxIkytUIBXfjJgZ2u3GG4j88Jn7YPmhe8AJcNw0s//TgIJ5ttmPcRhNl+e
ri6gpUkXmkaQv2XYdgjuHxOanW1bq0wS1iPDN5TYExLl4JCrAm1Q4JZMTJ3QFVFhGbBlbUItHZMh
Ey9YOw0wADrKl4bC85lhL2UmHjmGXrEEfYXVj0js0TGpx5RANmpfqOkZFmY17eFtLK9K6dr/4TJm
d7RkqTVRIlxDDaGYhQV4CCVic0Uk1OYe+fwL3cUykYUv/SotkIlOTd9WshR0yrUb/fA39Gtr+o1/
6+cwt6xP0M/dnxPDb6A9a0C8gMoIm2G32LiBcJiZ/HWGxaUP3yqnftreGk4Kr6S5tVvQWzM6TNAI
G50G33LIBxoydGxSiPdnEUFvsj1M5yo/c6xUl7phPpW6CJCKRZde0CRqd5SRxle2eStKfe/OALvj
kI///MLEfBWjLTeE+xuZcMRg3Q3OIaru3zUYsL0rPmx0qxPKUif2Vm4dKXz3kMeXoROaLlj4+YMX
Mn6vzL9+Go3RzDbPHzF4ETuUHifyTKYXXPNi3Sf5emipIcLuSkJhkSeQgH69FONej6pDaCGwqeiB
KvIPyOCl6fqcQwGeni9QpYfNJRnnb4xybc0Q+L4xyKyfpueiW0IOfbU+esXAa60sjRyGfQqTG630
IKSYphJQadmdJTwH0Vej8DlXsMuolAGX1snQgqLJhq+pbx7idbjLXpDMXI0M7zOSyFhZRBvvypSa
q/sdlw2BRFLXVsJndNEXtGN8upt3aogB2mv1NqnylZuVGOvdxDNA9w27aHht07P2koPyvbkilZhR
P2CdSI3UZJnUsE+x5aofzXeZ44bxAGuUvAmKICVfa2WOv84SCk/DxRYE0VyE7pUhazST0R38UK4V
yrHQYNAIrah9UU8R4lXK1Ha9KEQGYUwPYuIuznf/i/PCaD9DSeRfKEwvUmMcGdu/0PoZyed7iyV8
24xu+mmEc3VU/S8r0HR7dF2A0z/XHPbmKs92xdrwkEr6axLfYr9xjR8F/NxiwLZ883qx/ewpwW3+
wY3UyVqP8kvsq2COutXww7iKfQetX94v7+fEDTXeClb9oJoxXiCiKtlF/sHflyr90LrtOj4bRG/N
KXzR+mUJUwmddYNooVx6eHvvVDe+FnNP4tlIMajuycJ8YuvbkIMP3rixGLXs3aUUtf5DJMvQxPmv
pOAja22ge8BuxbMC5+WqyrjQieI8o3P7FUKfiiEVVl5DJrbQliTJVfV5KplQHsDmiHjdYdFIt03F
6T4/UgpaO79mX4HLGPyh/8ggvFjcjXdaaM3MTUbY52Cvc42qZLihqsagWT7Q2vCgdXjxleVbkajW
Tw+DPq05L87GbUptDC17uSU/llNEXU8QdUxjsXw19J5J8jyaZahhFcrSH1dLaDcsq2K9yZyRHXyC
2tOQf53RKH3TfPHkVxScioe3vrhDMyz3v4Kx6/QOOVrp/uj5x8m2bG8uvP8wRlIj/GV3N3mwYVNp
Vahwg68uJOjL1BlgWNhF4Ylh789f86yqfHXEHjdyf4YvbjQtqgi57R7rEI/v8lmWp3eqAjZf6vP1
bTy+/GPFzMXE9nlxNZ2TL+GuSazmJ9lm0u+/KtCdf4PIVr5BQy+2UxH1j+ShC9DZBCU92TcBSBRv
0Bq5wqtZt2DlELoqK/3+JCwe0106dWRud86//QwQElt8TkW54UbJcnUMstn1ZCRMSfpWEnr8FbkS
eoRuCvlDfr1Lxs23BrRXY4cWb6x3n8zFCGXstDWLxG98K2s34Zx+dUqfI4q3E4aflhW/1mkHO7SF
vkiNo4CvSk4kF5Wiko2/u22jW31KbjHczVL6hDMEts++dIGYQBpUMhTOz1UFaG1XZqzjXwQ6E5dh
trAHBrrg9d+2DPYfWl9E2PJ8QxfUrhorWirkAnuHV3iYFDBmeDqw4UraIo6xLAz/xPYRwnRYsNCM
1FRaY86cHhMNbyouzNZtcEsNgQyi3PjRzsMgPYFLQzygIG3WQhSIQz0jxzz/gZEOlgHyNTwBFQrq
lgPh8IIvxeC11gBscYlNgh93/rCPBIg0AX7D8gg3/NLIMApopaMbVoQOAXIoo0IlaMi9UmtpWTyo
D/K5PkHr1drzUaowpluWDG1aWWArbRbwz0s6a5ax1rJchtx/+dh+FcZSeySmihPYCIijjh8fTS66
6BdtLgPs38MzXT2bUe4pwITYWfQe/tT+QUgJRDBuo1g5fEfStVqCz23wd/KK6SSqJvhr79gKOv65
pWV3sKFHiNXpHRbrdBHtOMbQJbR2SDPkQrF2Q9BLBa4/Fv8ovsqry31p3cD7Kdobd2SVjlj6Y9QH
JWz9ivLLG07puMRCMzFDpek/PEbrvyIqkk/3Kro8jPgQC3LP26SuLDVAKGImn8+7d2n+dUpRNBku
bk4WNOzqWtW4fPzB+JXxG6no7lmFuepI6MMJ0yTGGEWV7RN788t6nOzz4ZvvTkJI+L7pn/iO60qJ
Xc/vlcxrcGX8IAICzPeXHuNYRe4C5uqk1VG9W44ZUWWD0jdDn8V0fw50ab5Eh1qIhF514Fk/p2OM
+ynvU4j6SXMw+eeLX3qsSuxsN0xgiyEDN2bqhLCdtGkMqRhzr2l2c0njQ12ojLepv8Z77o8zsT1J
yt84rqO0su5U9YTTbfjpE/Bd+vo/yc8khaKYF/jRYh2t9O/tqCPPO0SeBzRRbRWeptomvF0UufnD
4Nd2xU9PsxKza93CkokFQf2kpO0yjop/ScnTyGnvthDkvwzhS84O+rOb82iUi+uPQ8M79btOmINH
P9a0Ew3IFlYxi/5erLMpBmtWJpWrBlvGN8IVGFxuZExID1La/unvZShbHY9GnjD/ySqpTzsRqVrK
/GItx++UhUFft6DUlPJaJ+T5uZfvrHAsnFYEHo1cqD2GHfHuYLu/vqn063egSUf6sn6pc3XqJk/4
vyPBpX+DjH/wGfOlF7n7Ez8FaEoKM4aPzqQ+ZmApLVLjqT5+xp/XRB56Eq005GJ4CfkySOWVrK30
G6fshhIpzZewcntxsbJRqXFaL4AB+XWi+nWiOh8nQCCJK7WgYiJ9qZ0ozNqrwPGdpeFqiHLCwNVr
EK+UVMilUDg8G5t/zisj2wII+M80psFoskgL5af+7iIqWU/OJmZE8hLMFLIDx8UIl1jpCT17h2aV
Q9Psp1eOCUqXr5ZH24doTQfXU06D0cG/pySQXoeIAmE324jAtOzCH00C9Gg9wPBLOV50gMjwW4E1
48WL9W9rqaTvcHmmWzYuq3p4ujmsIyIRtGYX85RoWBtPvMVS/vEGk6bLr6OkZeN48wupemMXRtMN
lNTqn1J30k+GQ6+EFQjptSMMvxboGeKJjq+d88QlB0g/ZBASw+hPQCW7i4mJt1APM6YWRnMJRZ8A
TMGj926ajJE+stAtnAw94pSDuDDPWwnk/wzjzULtRVw8X+F2HqX+GGHi5EAQZm8v0C7nki726v51
5cK12Odr1rfPO/ONSCtidd1NiduXtEJzVPe4T8u7KmHMLUi7+1L+dAJeCgq+nf79fQZNuHjQPHrw
I/nHv4qZIEe7KD2f2LxX+UJ+vIaakthKYf337Y3Tu3wjn5U4+VRsSELtRK57E5u8L7sbtYqGKuxu
s0gUxtBuaAZJ6zh7O5++8+e4ujHs0xNqiXpsDaWVfWa3h27FJT9WRy2FmEQpH6N9sLbu7w8IHFfe
PS03av7e7+/Wb7cOVW9+52PfulrpJhURYLFdabx8J9sy6/vH/YQFanq6EmGx6UeHkAT31Ld2JB+T
w839/jj2V52KK4m+DJb/9gae76idAWIajuwYefoKPJqehQ1480s27CyjSK861LHNp0MGyhrqO8jk
/FShubZYYV+GlWes3j2+YHrkU3nqYGXt0znJoniKMrfijJAK+/7CUn6mw7+636CDiJwn7Tps6ad/
GZJ840tbFyvKzwAMZwAe/RFZ7TOAswX5941RsgPcPntH6fpzukMvRvfJ0rLho8fwa4fWE53afYtZ
/F8voTX/HZp6j4o8ePXSYsBGurT9lPfRl31/l6vbKl7MxwYil0YD6yM5/pCCb1j7FGt6xJJDCBc1
uKIWVSv8cp72MJ+Wu5o1fdMOHy5p4oRsCk9e5/4rmdsI1QzO3IjRbAuCUebtLYW8XPjzykm/zi0p
OaCXk/PXUabDPqX0WSU2vqPFpRAWT61sbSb6d2gff3iBQqBFqQ2pxzSmCO3oeO5RcTFRmoHFEeQD
KGHxk8Ax4GtX4QUCLE9LV3SKfxqZQQrfDdHrlZDcctH5V1H+8CAdH139QB2hrPbY50qKkBeDej/V
36vDQL+3TZlp7vmFqvWwBM7ydGgpGx0iCVgF1VrTGRWmZJQW6GllWxTTmZYMg/UNeRLr+BA6RNuv
AG48gOvqRPh7q/w3T9zeX0bcWMorAW7G5JqDbZWclTQdy6QuVj32rfyXEc+18MWj8diCu1KfdC2E
r5hlr/y8Xy1FMciYcTHaOXxkl6VdPP6OVX+1fIxkttITWGNGWFa9Yde3bxVzFljx0g78N/xACiIz
G2YgC3nHEyhjSHgqIMLSNwzrkxxOTbCPwh6F5NqW/A63TfFeQfsRJ0GmMfL9dU/sPsY/HYE/iNMI
Zsm/b5OLEOkdOwExSXsJlPafy0sX9V67djHAW/gqYD4RXlDE0KbefOwXwItsSdxf5jRpRA+M+OfZ
SVnAHHqnRopsbqkoFfmssolzZfDgjEBTBoaZhIBDh4U9oQrWx36N7p+mfmncyMJHrjIGZ/CQJzsD
B5t/WcHnfO9+5JWIIoZl5iSmLTYJ4UW6vKv0gi6N7SwY0MRS2hlAGMaJ2rke8majz9rA2e4nHySH
1/PhwZpBlenzAbTNTQe29qr9t2YFsaeFF/j2+9mu6Kls7+6XVvq/WI2+H7Rluy4U5+HsKy3zRFUX
01dqVCY3XRdnER6y/9rNkCtZtLYU/pD5GWJXmH5ob2XD5WruHPz7u0VxV30G7KPHzI5uUxDv54Zs
hinkH4cou2WLnRxq+Lcf9FHq0XWYkMK/9hdzXIwKHv5LbWs9A/C51HUi4UZTQ1Et/dtuaHb8kz89
g70KTlPzBW8yMY8THkvyLVu01jP2BAjJqK8/Yju9yIuwwptxH3s+2FPygnK63vl0qe3X4Pc6jdff
pFbPM9JN+d+g6F8odsKzh5Y3kyt/I9VnedoSzgDb+w/8ZzfAftCCNnnCnmT98aWDjl/R+6eoM4Bj
zuwDblDZjBM9HvL5YBXKCWONPm4XEfy6rl2e+jRUjU45s8rob4I2okQlbl8CFv11fkQOSbiKCWRz
MZZMOFf3oiEowa7uZfrnM4D6DfY+yUzlmm+HRYFHPGODm7mu7/ScOe/0jpJg7IInv6SFvXRdrubv
XD++EU57EtmL8OjgePmtB/0Mm7PFE6+UCmEBNRUpAay5BEr1oHU6HytGuMM94gpEhm+LwOEFx6Vv
hfZxzC+8le7bOiDaGOX3YEH6Pldqa6398wv+dz0ZrV1VLTXoCp/r0T2opTGcwVKaTVgJg86dwoxY
Y0TsHT/B/GEjvISimdhzs3x6lK52ObsosNuRWR0lgQfQ2DbGyvx/lz9a6enoGIMkHK+wAVf91Ct0
TCEnD0oljJPB6uEDDEQBLORZhW7bLZv7pHhreT3D52Jo0Bye7jH3rUI2bPBJACpPoIpYb3jUCVa3
50VnKBId2VftldH+LfDmYbfu8hTAstKP1avW4/XjwKTvlU99Hai9Wd7X3RSP0BunBjiDMngr4nVQ
wy1bx4mEneGb6kpLuJDJDqySPqvhW03pn5ySJ1d8xyE5RyEXbZ52/tEWJjd+4Igz5fkbbObvoq6t
G9nSgZAx0fT5wGVV+VOBCZnGP7dhPrx/PuQ6Y7JcgNUKzMzvRqdtXJDlponuyPPH54VJsDU+UF+2
XEMOxQkz3bqnVNFbVpwCuLnC8Xo5+/7tTW2AfZ7vyad7xrcbOktiHbWEf92aux+/Sf84yjflvoP8
wrZdvGFRiJiZpRjBiLdJhKViu/mgzJ0XHZ6H0CT8RYLlEOqxwaptEuFFjSgrwfLbsmHPUnu5bJQg
XSg3z4yMolnbw1SdgEDTjGzvDSb4D+tgKnS0NLNURLDpK+6qV+do1iNz+LxVfc6WW1P7Q+s4Ae+b
Po0VfVlOE1OPbiLV48w4tIzr3KTaLHq+7RPvJlk1vmwdZThB2et4SbdnQ9QErnLp/Cix1PM3qIw7
9tRJcg6ExRO0Fu6vM5Jie64hfA19izAmz8xtX3qaFRmWSHaeJG0XMyPR8MgJ0doMxe73NozsozFS
F0vuvUhqx8XD8pQ7Q/tHa3aNPgHvfZ+acb1i/Pwy1xng0ki5mT4o6aSOqycsrqShUT4P3FIkPK6I
J3mzcgAi7GWFE+qcMrZzfdWIl+0v26GGMOhCyAobpLsrg1ZsAhIoJCIx1xKhfYqGc4EczWrp6BzB
D2Hnl2LE4wgs5ayOwCvfUaCxsit86Te1MoFA+jQrlLMlnYkRisZW2A1TLJHu0X/GCViYgsoXh7UJ
Qr7Cp/EZLyDf4Q7DitqvOM2I0kDKVxZQ7eqHR7SdjXR0/+KGyy78d/HwyxJrGOJrIITGdEoMN82w
xfkez9JgTOqxSTQaFAWISuCGUO/ENoyM8kCKNjHvbFAIAfg4jrEJS9RrzmMFGIJtVUtjsczZoo0i
PxhW7r0sPIrfqPcatWf/7dc/jNq9P1Yu17c2MFc2r7Q1byV5/RvY4l576VLz7IUOvuI7nH5q89dx
T0t+9GA7eZTAL6hAh8suN1BVNwiWXG3qWiC6safudsqKOKPzhpcUx8j2pe1zd+xvXqeH8vzL8vZ4
iF/4VQT/AqmJ+y6KCcu65MfwYV5H3KxMP2XCkJCo9QBju9SUa+GiMBmmNh5H1x/J0j4SCVOa0Xa/
sgwIt5dXWjOM9pLeVxKuGnVcVbct24y4K4Mh93fHnQGg66SVeSP3zri+ITm2Im++I49Ku6Hry4u4
nQ7yyAN+k9gzQIQwFM91Wyngln3IYxaIcixyDXNUVQHyt+0SuYQxHqAODZw7rclCv6zTFHlOTaCS
vna/29po0/5q74l1gDfnd6SKeJwBGmxDZi9GvTXN2GgMtdZgCWVIirTRi8Hmot7zFX0YLb9aPB2T
XbyHO06/gHiQkqlI35+NgiPDK10hL1fwF1LDavP87KeNmnM7xdxYDVLX2lRC5FoEp9LQDCSnv9OG
OakBpYc0ETJtBrm8iG1JV5cvl1+7rPqI1TPVTFr7bf/GeW9ecyYd0c+ygy89/DuMrRQ/hAM+ib7r
6HluKxqbWifRElISP+LPEwvsfk+qKijX+BNg/KADYcrM8+bE5oWNxdA7LleC8qs1PQEWiWJIuxUW
4pZgw5NQ+F5PbkB71R8UVoxjfNPmwGVroQT3oTmKWBNDu0vWwz5Euau5ZoWxlwtz0KDL86W4oaVY
JhXIqrEuJ+SPaQlKhVHr2VMcpxEaa1qlPvydR49LdcXm04V3G0VcoOK5D+/uPC3iElV+1+6WCVyV
oKtdlUDoManTEDiG18h62Ayg8N9pNZCeqET+OZYQ5YzYeBO0MW0zFgkcYzYW2G0JnzqHCtFn1QiR
ZwNuWzGXPLdWMB1OI9kUVJnqpeMtf4/oSBum7GrffPLSI4T0+2ehfKPHL+xR+68N9bv+n8L6/9yT
dX/snn459Hcikufgh8L0XxbbH0t8X47KA26HNM3vvMXlw5VJhxipBM0L1JBcqZhRT05KYbr/2JMy
XrzKMIPTxovD0t750ZonQ1vFTMOPp9/wv1XpF8eLb5dFrDyBsT8yRmykBdxCyVkIlTqC0r/vV+4a
DQvGXvX62mb7wv/v1Tfwq7sxgXejwb+u6LvZHSddJ+pWHCXyGtbf7lmK4Pnt/2FmVVf4xlLsG0UP
dAXRDB5kdStdiO9eTnOBDJyB57aUV05z4RT8E1GeY7OYaNCcMNRYaYQ29hNDvIBCXgyrWKFzYiik
nDa5YcT3ny/xcTloUxLLjxpDuKKh2bWLdDhr9IP8c/4d4U+zSBBLpg8qqLfveV5BhtFV58MHjUwM
6VEgeVOP68AE1XxLiiSn3R04CITLFsbXwuCX0sNHYhBlIeXCWAVuoWH8s4QBwb1u0PeYK7SsqVoD
sMC4dJ/X67R7vKLuxQt63MVEndtDwzolqY5fpcQhNs/QIyUC8l3WME6sIZNSQdYUjylPzg3rSzCJ
JD8x8EOUKYvzc6FvRVziwAlmBdS9PYKlYO3JfbxdpWjyrp7qfmEcg7wZvrGUaHLF5jXoGe5eOjvo
PDy7hNPqEGclChyCB7XJcWQCs0tQoTEAYNr6sMPg/Rug0GEbUtoVOoR23XWajHDf1u82Ha6xBnCi
HsuAdOYylW6L2H27MXrKJ/olccrpFWVsnrvSF/KbFIcghlZLco7iPWz9lvI+mM+5d5YSNUJEtV5c
IHKX2E7LmlMHHz9HxSm8vEXva2A9sPyRN0ny7sepsCg8QoHyfqm3/J+O5pq5K3vnGyH9pw+GlXq7
QGKFMzpEHzSntNGtlCqpXiSP17blNZw/RJ5zcwndC5Zuf1cn+ToMQg/WJE2PPKGPHDYq7SpmHNwA
ZGQq8ZlJy/pIcvgXFtCi0HgdDVc0JYr5cAsWi2Wj4ZDXN8xUIMP6CH+HOfinxvxhiWXOm2g/4BSp
6nJhtskdgPNwI876xkgyyfEJFx+rLOSqtIyeIvNbXBaqjNUoYWguo0pJ0KNNX88cjg0yvKOKm8OO
63frXgd/Dy7VXiq5B0pRDdQTlQZoACccjd3c4d9zzIHP5oZQcKyxcKPz9WFFi3A/5WscqCium9o6
5sVcyqoEu6/6igZKcsBfwHFdnTbDC6WfRl7csB0WfdM4l0N0GJO32ljKKcEzRg5/RJhaj7RnXbkx
CGNHe4HUPYXAuujUFraJgr/xwsxY7lIDxzo+ViBebZ1RnCCqSjm5DYJYvh8GI//g3FH3eplZ0hVN
ubyk/ArPn0ehzercUQFcHz4+Z+fPNFkkjQOzgREs93UXhz835wgloKK7szo/N+veNEvW15P1Nr0j
KG+CitaTEMqsxsnnw7aNGq03gRHg+9exbWJ/zKckDoK/MkkrhsicQENjoidCu+OJJcff01di2M26
iqLh2RUL+xLvrfIQgqKaTmhsp44CKzFhXqtu7MjJ2CenN3perTLIoFal5tIHBkLoof1HuN03y0RO
4ELKG8P+bb+5MF9+vrhGbq3jDuOBFhLrAlH49Gtqm/enSynMkqp1Uw9BoC+eguEjj7mrjogy3a+i
ZHMsDt349ORQ3tlmuxKUsWyxCVPYrW4VNDRUyNT6ZWnkD5PPwwMXPkoQdRsHU02m6P0l5gqXMtGO
FwRJQ3BFs6IpKechL5SfYaWktTQ3LhWlE7iJkCO9QHsr3Rbrg8ehL2CJZl8daSomEy3D+N4y0Owb
7veI87kFWGNpWBH63sCFp8Wlf5dihIshu2YVKF5Dc1A7Gg6USzXJk2gTk7gyEIbvMC4LaiZ0DD27
U2Kl73MxHq1LEy30LCBFE206rLGxwy90IABhnP6Li+sSYwkMPiLMkqXSY2mLkZRfHq11AgzsDY0I
JGat1Jc5z/GAQx6yxCKGPvTYmi/SpaB58tyO4cLO9WAK+Z3YiQvpk9ZDmy8ORVZX/HFb5axc8u7A
Wegu8PVF66slhloPrM1VXbFePZKwBiWFD8geFiEre/RtM03eeomMtHq6nFKiQqbS68vMOOe5/PJ3
7gGaiD9XhH7AzFebbdzQjcx1B7fBkaTIfV+qY3RwNr/s8ZbFOJ2TrAVv2cDSMya+TpapoV1rDonO
kvV8xggzXjOzd8rkIQ/rAx8PJzNVQfzTvpk9bDK8Ofjr8wfYMTi5jbdNxvi+4gPsDlGjF/jFBxK9
/gwqNbiITiUCZyFWm1dV4NgOILcErBnXqTuqOcZAQIzBLUA9H4w/wHlqLj/nwouVANlf6sYxpEha
TI8ZegQhPV2NSAYoLDLy5HnGZdOoJiW71X9T3SbvURX+wJv5bthGJx3U+Cm+Qst5iJsOl63lGMcA
+oO4OUUqNBaSa4MMHT9DO0HaHhXPQ4bgF63PAAvfFxIKU48QyilvzwDS/Ih7hSK23ZtY49cmL9vA
RnZG3p68YKh6klYS3LTQmeUymF/5XY9Bbaxw0vQhlgEVH6LROxc3IL+WuPdtFvpSrqs+Ncqi7gww
xCi7DWuczRu5CscZc1mKC8DMwZyCpb1xmAb6oASeBM6GmaJdkIr1Qf5da7AOCtucplay/8xknjkV
VbTE8yiL1Hwo8TEQ7YuOj+LGN3K0I0xZKi+DnvBEDzDhYESDuzwX9EA4ngz6IU4jQ4T2m34lN+E2
O2F0HrjQCC5RnE+fNmTN80TEdPilCnD1CR18m39GWiH2jgo9set4tcVowTAC9qV7v6Qm5+ZruCIs
KpcCiu7eiwC9jiMsU/iKrhKo+xrrj0/OAF8RI+qYbvnvOlXR6TeSmnMP3A8xi9ir41v2PZZ3mAmQ
9zKz7Whpi3+RI6q1X88AiExRk+dsmlquo4W757LuFZNBf6dXotsDqd2j8RNXDFql0al9bRrrLcqH
uOtsi0a7CfpNjq/NiLfHiis8Fe8YbmVgU/z2LxQTveTbsZynOYhLQ7Z0yv9YlTAhBvqIu7orQWZr
2nPv2EqkXtgE5w/TwyRZLFRJD+Hpwk0qaPitXhuhXBshM1KTEh88yFIjJQASoMTnQ2S4cX24gcby
6wMMh9Ze2XoAo8+Dn0nBlow5pdNWg9oc/kUhBrSVzSVvYxZGLOHkxvyLXn9jX6qWrR9vnZDUiiDn
/yOcwgr3XTOiKBdjIlFm1RMIOPGHS+QzQIZ8aJONkqBNuLUbqtBIUR+eDfEYYNg1x1kvpX+1hivq
4IbpSBMhcvv5sRdwPDBTCEAe55U2zErPn2xkWmIpV5iS8Y4JCIO/Dl213L/JXawQtbcxwgx/Yik0
rXiDlIWbe2452SZHMEKb2nwUnjSqp8EzWLtcoKTDLOP1SuFdJeBEyF2hOZTpoPFXoLVXwuB94EiL
CgV+Bng0cmtoqa4ENh5bdc2elkouiTOA08aJnX2Oyjan2e4CdZvwpeEMkEJl3OHlCPPHzB6vWkxT
+g8kGZUnXEjUer7e8YRi5Dqshjx9fAaIHRU1IRMx69S0L9V8vaT+LIyoxgY7pY8sKSqcYtF0YqPl
ovSGIaB3R4vav/+pXvwQ4S6bKZ6987CCdthXp3O1ZmljalSWDwHKQt+yjGHeCFjo88gQg/Vxs31g
4PHbOnhZHWDgmpBm7WgWEhkFS+GXPuCJ/Hjrps9BOreem7yR3cv6I9MvuaVOzj+WqOnxOGsQ2jga
HBEfIMje2mo5wOVTpBS0XvV6PgyamFkjUYL2u4eaEHKdxOoF8YhPY9dfPb4CD9Ixq+0dGpMxlsCh
6gIQu4kSxvOSaF37uWrKYca+og5fl5ZFk2MEQH5F39eOTeYO8mTZtJb8t/VT0bjIFwHFUnylvhiS
YIZL2nuJT1DDNgJ3TRx/AVhTaDbINJNDn4ykoAeHPg5m16NoaKLePZHgDHvm9QE++9jx041A6hqV
qb7eRkZXPvLVXlEn0ng0fhNKqcFDnxwk7db42X8Ux8CudYb+BSvIO2F2v1dvIef/UOs4i30MLrHK
q5ZQ0nftgvu/nAE2rTEafcfQ30DKewi71e/gNSu7lx0nmM0zQJXN0U6bt4AQvuhFq3FcnQDowKas
5PwVWzLnGWBWEx798zScZzBlTrGFk5J0Gpqz1MGfgumotjiNrjsIRn6oFUoaS/qXS8K4Qw+J98g2
j6LOAFtnACaDg9fzu1+WybwSwX933nJHrfaPN9IdzQ6VjZwWb7f1T1cI3L1xNc//DJCzGVkblbAV
SOlGjz79/ZIaHTlyBviiCZ9FJEW2Qmep6rOHWstH0IPv6mnLMe2vKbar58zqHq8GpKjSRkUOsfai
rlRGaXV2rhmsRx4jO07s/I0Irg0l2cvI+dYN2+GFVRMPpMfOQQAVevpkzeKqoBaVL3UDv4OsOuWf
Kdr4btG6Ezn7wyl6IXnWjZ8WeIgEmW37DHCZOAlv9bM4YuWf4P92yqt8BqgzORTmkypKfcAvfvhp
KCoe+e8hBdmepQTAgIeiGnrIrVuBFhNWIjnrVRQi5h/YtdqA+sH7lO2ojK0B+eSolBwgegZICpjB
bkjEumk8PQMEQ1cyDvnbLNsCstyRtANH5xzMNpK1gs1yyvjrl6kMhz4HaV+r/e4IN8xQ1RMtZOg6
ZoMdy/y7yGcAJblpNuN7o9l6WYQzwFPaipcqpC93Hj98ckzdtyY/zDk8xFHKzGd/nEIony+Ir12l
zdNc0nEorRlHXOsM4VoD+zLYny4t8W9np+eqy35mygp8K9tP6GGRwN+qsRTi1DNZVMGqdIVuGNpz
oxUtdkT2ita3VgxquKOOSrvwxTdsH7OKIRiHygOt6gw+cQmY30M7Fu6C4oy1OdAOZWJqJW02Rm6x
hqwy8BRpFYhXShYT0EoXUDIsUQJQCvH35N+U9pyrIAYtv0c/e98AaBNVzzFkUCU8bQ3DQbmS7IZ2
AmR7NhxhR2IKe05aP/Nqpw2uv6J0F6YavmfxrU06LL9LosxSAYbf0glvZz3rps8AmkPVzGZ329qh
i1jwfQSy56LVIQVRcvKpP3W0rF2cenMv8gzwFs6TgQRcrZM9OprDNdMSYeir+SL7+IQ8fNoUulzH
7noN85vpk+vRQUZ+AvGUz0X3BsziUA33elHh4T0ztlMmId8t2V7KtNYRdWka2pxu53OPW1nFMaqt
/BuP2t99zOknzNHXMvXRnOteccDZmp6KzyO1tZ2zh1coEzb7ekI+vcLRrpQJz/Uqoxpv/9q/Uowz
T6Cr+GqH16igw9Up8QfpC6BTpZsuKZ1SWv7btp+LapCIr4yOLUy/0nlLDstvhRBuag1vRHuTGdCN
l7wnPuO6w2HojdBITMfhCsZ7V2YU+Bcu627o1MMfTiDfs+Q/GJvv+0nuqi5C/TaofUFuJTh+rns2
KkihYBaGdP1YxiiFjv5ctD7d9JelfNpWXAiQjw8f/vP+62RMSRti5y2Fc/R59bkzQF7de6Gxc5ML
RNAXEbeK/sUwuegtj8QzwNEiT5YhNMhmZYaff4L6rtI7LLt4zTGlPaM+kP94Ne1uoYHH7uGswcdW
aOupKlM3e+f2HtY3G3GQFS+S2noo1FnqZzERUHgGCE/yPpVFznM7T5mtme8uTVojpMkbmOly9aad
1setQW7IvxDCpnlUSadtN9/DNsQtjQOCkdEr8/ozgH8ur/hYIZV1yzHKafYMcCHVyyP6ERmD1Tg8
A7Q11582ngEiKGcAsHqwfMdi2xmAYbJ1yw5jvdYn63O/axl5FcnzAj2modUTuEaddrNXMrbDnwFi
0u6awI2X/TSlxSbTVuw/XDXbpmA2w1zJ0kYlyQcOL1o7whzJ14POAK69zPap0so+xa94j4iOKWov
e2d3fi1jR/pPjNkOhM4AAwh+627gzL50Hy0Eja3D0nnymgPlo+eHKiNqx3Rf/1yhhprGaQ51w/c4
+bhfdvOUgIku2rW2AFukutGSciDZMPag9QNFoms3G+NGywJG/B8sDiNOPD2P6XBUcDYIxohn7mhE
nYh8SXTZFifzb0ZN3OuLQXgjvaNCozb2MPfJeXbLM6F7BNk6PWp50r7TEyTrxSdAugv3zwCfZyaR
U5Mm4w9ebmXjOjS65TXgc98MxxuP0++7tF3yr6R6y290uCTXr+pG8Hm+M76OvITcgh04uFINPS64
Fbn5u21tnAEiBw8Y4ykPxJ+YMti11rpdSnnVMU0ZhTaZqaPNPjbwan7Zl3wwSrzc+0yDi2yQsjDi
KpiQd0+tfHDGqaU/z8jYQ9Hpq8fCGeDjPmaT0k9+mmv4u7qXzF+2a9daM5/pfVp9fKCkQr4NrQ1r
nTV7a6YSeBxt318TfUDdt99EfthG7ggfdi48P3ydZ7+9Pgvr8sC0JHlP6R+3tixSVpM28BxCuhOu
istY6sBcwJbRGaCGslF7BnhsJDv2BSl+BuA/A/h6rb6eoL1pF61aDhAWG/zz4+SJ57SBPWqO3I7q
1sTyr50BjNjN56BCBhbGeddPPwXUIhvqyyB5D6YQDv6fqz52tPjyeGY8fGYh8uFQyzg4WXf5DBBE
G9KX1YaJ1l+RmDWkcVzY6bFKslOEoY+RN80sOLCR6UuhlF3rfg3iYdk1jXKWVnLgHVopf84TPSQk
7ecFHEL3+PM+auMn5hBDudasRtBfzuL/RKyRTVSi0aLBQdLBrQ9HzLOyZwBURZLWsrfGATUtLFMD
muTp2tAwxl5CsyAC1CVarT/O7tisRx4o5UUP0yLiz6QieRAGQTVvySAy8iSEsnUktADJzVwYNxGW
/PemdbmiHzx/BLeWRN/7Rc1NaJwGX20zpYCL+Hxjc+hKXVFp721Mg6w1kjlN1fDmoLcoZkU0Gvxi
eA7CYWFOVEb5mLJKFEPSPZIKs/XkkwpTIbWjv30RyQb+GeRrvHN2StmO1xoeTRtc1ToRwnrx4AEn
rHJKGkqX6OsfnjYM+2uZw47WOGoJIewBDD8WA9gOyx9CNykfji7IOBpQny+dAXi1pvf5sMwCz1zn
ouusL85f6zoDSLU2meVtlJxqbbgYYz7RnAbz7ZKE0SkOsxuuCAxGKRTrfivPXyPQjm/OSMCw9aW6
lcXUa55CCeoP3zOAGQI3u04m5qU7aozP8RoY6wYKZhL7+x3LMJ8TyHRB9teb8QEWpyYba8oRbyq1
KKouzmHRrv9sCIKWXu3pItDHsseLuyMmTln3U9OOTyeK+CfczwD2XwopS8jJspBlcrXJBC1AI6IR
8gwgsMZ/KKkAk+U9OSCK4B+rZULf3qfOHsXf4aq3mFjfuOP6bUfTzbYzmPzGfZddtfDy4SGzz0pC
RutDyhyyjFZJeE+5aTPfLxbHnrvIba5cpve/eA+Q5xyNHnonuT1BfnKKOE2mDMQ/oQGXGaf3PwNb
5JMFGtxgyGnLH9EQGggdjERLoj0L6rDYqYuBgS3UE7un5VcPAgIzOzpb28z5dC+q/XyCOgP8MGtN
92oSRYQMzcCu9n+SDYdWn7a9+0k+sPvSV7+2TmVkxodm3rOy2PQrVjGivM84A3S0hphRks4AMjTd
QRsnjQ8+WZ0BvMIM/xNzM8ggclq6ej+G/NvA7ylTUyxtVanpYPFgs2yXvX7SQhhR5bQ6CiO+bYMZ
mw08AyxmEPejuxsTxmVOyUm0sCOURDc6m1OjfAyKO9Q9tSwwAf0mlPevIiOUH7q2Uk40XwZQGr1C
2n5hLskj+8Fak9WTneNHo/nDwvE98T2zrV4r8NbxWW+LpmXkNshi3I5WHS88J1yicnrPAH7KJEvz
+zm9hNn1xoFbmE0/i8O/SaZxFmJ+mG/KtE6pDG55qS2HzSSmRmlFZMtEwyV916GIpOVxaj1/E6UL
NOuxKxaBnD52EqGN+zD4ywc5eY/mFAdr4UPOzSGDkFuujxu+9NzgcGrbeUiZ2dpSyTbLGFXlXNgZ
PvxAm6WRKFfyn41LFnXOW9MzSVqPZ/ZbRSvkAzI3tTrPAL81VgacOsS6PI5n3a2DpQ86Ni6HwsX+
7tsrfYIqKwbQSKHlWPIi10s9t3jkSmDJae24IcemA9WarFle1LG5cUjp/4ic3yPKiY9LI9c2Dn4Z
jOxRW7N6l+dUeA/EZ0slg8zY+KowBws0sZRkdyeemkxjxAq+Lz3kRSEesG/FcX/rlndureMLRYNW
3J+736Gf+W8HVDmvF2pIZnOebhJapzuCNNaPlVW2kLGHyMe55GwZt3TOQyfOw9apytYHFidkkevs
E4b6Ya6HK2eA8a28aDNMm5NC9ZSUG8Tg+IT/N83fY5YNVDOU5Fv7p5JyFovGra59cUN697d6Q2dn
TzV8qP05C+O7r8iEiWaJxSSKQVdr550zgHs4zUeoqwnXJopkdlnszwZtimcfIloybkCfBr0yTzsD
lIlZYHpoqhbWWp39/LQj0jVK3oWJsGDJNAu50XUNfG46Eas4ecfDPcyfQbjsIcMRBR7BQ0f+gVa3
ck0N4o4++Mqqrind1w+pDjioTN0Y9RPMmv7WQI59PHngt4YiUErcQr3WHlj8mUwYiZCCPo7aFScL
ZlLcqpYDOkGzY5WxDcveZGj0h66Ksd5ouEjSEpUnnuzfZ1oQljo1dOAQQirED26PtIbUIF3zktYL
yTfp7lClZ9dtqtdCs3a+f5mV9To9Hbnwy05Wmt2kpL+VymREZvpY8XWlyqI7BaM1Aa0RSo2e/f1f
w8UVqldrQx8zRFK9+03VG3lP04SRhyvIGuSO66/jVPL3jjGhXT5WzGMxyhY5kLKaSpaBKvAitx5O
y5JHjM1cKUHrlHV8AyUJs+WHOwM8pHQhF5vFZg98DrI8DxhmFXFJbKiR4Y2ByUha+qRtgxxwuva/
R0yvHEdAJyp8yNDTtEIKIQWJjepPphqEfxBx35BdFCfPrtveGbmhv0I5nG1O2jCgHHZiWgguDhGY
qSsuYRby40NlpsxngIxc6Y6sJ7/FyXWMr6KCNpbsbx9kXssNuf4/7LjpPFpMr3YGGKUp9FYapFQb
L7uLQT/BKGXhM7nRFh+9fj+M3rSoDTgD4KDIBb1ZlX/IrwiL6eNfmKk7yNSja0uUmYmf6IhsLeqJ
SMpuD2U5u/rD5Ox6pJAKMuggkyadTK5RaiYbFnHUrT6LTSnXg55NO0Gya/puwM7fnc1IzPzOGaB/
3oAmXf5RAQ+pW/3x3lPjNFHw0ocylaJTs4lEkusSpP0jW2a1ulPXGzQ0BmkiYaX/MCYspcA91QLH
fi+QJN/PxWacvnoVT68c/sDdXMJMNlM7+7LZ3Rc2+rdskm9YCvVJQGJLpe2SVThQ/j44wSB9uES+
O57ULcGOD/S8Saj73Nqm4F+x43tv0ynirVb/4ZsvEl88KhC/2E+NuAZApIkQDwECQatvZq591eLY
l8tt9Et2iF8A08/HAZT9gFdngEzMn+tkXtm9J43jS6dUR6z0/uur/6b8dmjjOEeuA16j2sjSJlAq
+xBZZzW9yhds9RWzOl+OEa92PaC5zodMV75yunAlUH3C8q67149T+ucrQJcMvDj5Zw7xGMszwG0T
100tCgk2CLU2e+0nzIPM2QlIP6AljCztXcvv9tlCCcryUL1SwFA0PvpHE1yUdOmQL/g92Q6F1fKJ
DXCiIQ6qKmzxDODp+IWYnhNVSmmoMGw1DiT1Zsx6j+Vw4GyvSVvHoyN3kR0/aA39/HQDd9fZKaxf
8QxQsRt9p+JnS2rnzrmpUuRI7l6U2+6rfaqA0qkuTdekNczusHz87/Mll7b1X+ci3w9qjvRul2Qf
npuuwMLunsTea9aE9lL7684AH/qHmrprLjU803yzlHZQVmT/zkA3gBaSD4J/agfvMqc4Dv0XlXtA
k4rOE0qk93c8aGbA+viJK/iUOvJhVHwzovXX5/NT04sdIS23PqRST8LbXGiEFzCz3Uqx3y80lLkd
Sd7estXp4HprhBb8u1+DdY6ee4pM2pK+v4yuYeSwOARZhx4xBwtbP/vVZQCFbqn4UVn3L3xJHFXT
mt+abPA+vFqdY4ZZoGruVa/8AiAZ1smTEXYzk1d0qigl53IPaB5ffHanNT6aWHeB5N4cN7u8Ux/5
gTpkK7vuTc4Z7h//1ElVf+jovTm4iJQk0gRJcxLcJX5KtqtctAMNHQmI6qY5vUFKzY0IQfLfqoez
ttBqjyTi7pc78YslSHejHWS/mIUikgxB1oZRMXLi1NHEUeh09OHy1ORK68S/ji93Zlto00xdJbmO
zTydPde/u0FdNKEkX/ryUF7juAqJ3ER+9aFJj30qgJPspVhtP7v0gbJNkwS+xyvVyK0ts3S1wRQo
+ILK8YdT+OHVpPWsDeFZ8K1W6JTFpuy2FXWQEnnrqw6l5vCwZBNzhJzG/bdntH1KjlD8wjiVph/K
W8e+uL7f2i30G8PMehdKX+VNEgtozBEJjafSfB4rX99HILROyyxZPH13K+Do3HQR2Yl3WnBcChPt
+ImSelB6BiBRcoccYJS9nM06MwrmUopZwML6HSNlk1OLBcqqZu59hda64mOtO0+SNqGH8KpVRST/
FjJpmbpPU4yeHYyDulU3oU+WoNvUXXLt7PrRBmzB0OWwh9pALqdMaKYHLLOnU0qClgJosf5DstKc
y3Lv9HDANGEX++NcLvjhLLnlE3UuAEvtf3UI0yJS7SnVsybjJCry1T8etZUtL8zWiOno/oJaVYr9
2GZ11F5l6Ef04S/rt9xKvF3uYy4H1h0hYYsls+PX+tJbqTUesofQms/9ZPjO0Ap0e76E1og7u8ok
GtblQF+ulaxST2mpWMtJyyvRuDG0fBhxOBIkc5pB2JpqK/l0+u+4wR/TTBOHkjIH/esN0eZPRqUj
eTKsxVKjQYeua7MLO2FnAFvKRKYJ6GCNpjqePCV6X2yqvfSu7ak7VTNN6lr0vT+Hkg+vn5KJVC+t
qEnqFlkDbGpwUIpxp/Tvt+788Awms21lv1+ddDbaMrlZ3BdYl0mhSoaHxrlWZw3QkoVD7vQvU9Wd
8A+aUBbSkfNLlG9DSZ4WjdeTHaeOJ6FNNG9pOy7tlUploj1CttifkgNknILHdo4tTzEzk4cpKRp/
hXf8qHeQQn+Q4/rZVJtp23UQzZH7XArC9q18kZ31p2lLGvB9Mo1SdvjFH+E9q0fY0Dq4qPlG+Ypm
f3Y99LerrJ9ztlCCcbd7z4YrTQ/x9zdjagovvO84cMYEQVvGP3XjWCGE6r4dZAW/kFv9cpOhv2g2
WigrCrM7HCHqtWr/RvptinAU6fioAgHWA/4Z7qVJYp8Zy6gJJxPORyKRp1W2JY0JK/JtS2yKyKmt
6sK6RsNg8uvP36s1AvcKyCoNY9gzQCqHfXW1E16sJzJZJpyU7GAQeOv1h6xBlUDzoc3fNU65C2zK
mnV8OaXxd/mDEYz4mtG0JuSTAJpG7WpzC8Je+NLnvstJzOw+XiVQCvWgyVcp5IPI/WJ0MXj0T0K1
iPUxTZO33U3pI0QtJzUtBZTIem8iaTsfS3Ag7B5NnAGKaC2mdBP52zawNuuwK6BmU5hWupRis5Fc
/LT0yOwEJ2W1PiR2t/cN+Ri2dEy1OPhinLl+QhePnh3eEEiZ+EUrlcWQWQcuPB9h0UmPRfcQulh5
BtiCYRt76q8GfuY4fYfZw8guUxdhb1uH/AWfAceXKIcWjek3wmvf3U5et0hxVaSsxpNvWyj8OQMs
z2/ZJX74QUFKXAwT/Zzp+sliOlzUUknonEU2KEHR+VcNs+tgYe/uNZqUsNRAfi13u/4gQ5WGvxG7
RBq0t1ZDqeCmRo+Uc90heK3hx8gDx4nciCsB4waMVPvc3ZKJXzSO+6X8n/D1w00cPz6eeTK1SyPx
UdobIInVH/NWw6A0tCPXrix+TqUE5NKEcTmNCKaoLYO8GFo5Gs/S9qTVNubbGYCumDL12OK/D3fZ
DkLtgGcA/+NbsxqU3D2jmwuBp+QDq/2kzUiBYP7G3Tw/jFh/6yn/kyNQngfUZxe5mJlObaCBSWUA
EelooVBzMkDJfkryKlbirtQNjCsSyuvgYg+52WZ4ESVvqtixZqpC/8zIIdAysfaHlg8s1YxOFfJ5
oAV0xOWTnLb63ykjS5BO/jk6E5TpkD+ugcGCLEF5K9OA6yB/2c91Yf3xBsKrifm6E1AZFOKitz4d
E6JVMG0+a/WI33HCP0X2AdrvDLCaummnvDozIB4nGLLcm3xc9dB4JjGx5IhRxxcXtk18RNui8Bg6
MW3ePDyk4dH8igI7zXHdCnBM6bFMnNGIdyGrNKubnGpk5JSuIv8awVv7oqi+JtRhGGW2iua5kOQH
2VLjhLda0lqrfnmmn5QjN7fucrz+blB1jNzHrI90bhVQu3c4Kcic3TNAkxXTttbLa4XDQmTeqfXd
6Kg3RK9iPpu/mfyfiHcbRgSp/WTOTIuZ45yhIpLsXEvTWxoZKSPn63zHdzuGBBxG5+JG/9wqPlYW
55Ld1OrdmdLjQfYDqerPyNb1zXncocqcXltHrMprVjU5QWGXLf7RADMU3xL9wF13Hc5U9+Xnq0P8
ktHSGWA97RiS47MFHTuGhlC2qO1V8yM6Lzmeft6S3LT1fauz6X9rBVQ2QGvBl+6wn4OUvK2FY1BD
5N8DWSrFkhTCgDdaQoe0Fy1P6gXUuLXd1Ywq7Y4oLxm6WJ/MRnkRSpsTyVQi3Gk1U/lfmDxbqgZ1
eXu4ADZekMvUrI8mnMhO7fCU+WpKnX74tHiadGqLaji0uibYvxVNUdnYpW4t00j9EDpeliFE+m1V
897nkP/HbuXGflpewNgsxTUTc8SHUJOt9CRvoSuvJ+5joLW04zFKB/j4YzyaTQOQmQvU/aDxrhKP
k6GX5pYaJhGvpQvr3pwBgs8AX46RTa2bI09LEke8Zsmt+07QiYnJhl9SBB13pyj/qI7OEBq6JW3M
PqT8St79b5r4p8npdyvnaSrEO3VHPFM855R/016+GeV6V2SN3+ZZUODiwzOAY2VewDQ5DTNxMLhO
K3ucac4Z4PlypSWs9ITUre668XS96Axwd6k15xQ4u2E4Pyub07pwzElO77M+5kA+LpokMeRTxxON
OOaRU7S25+I/ID2xWk+NdN1EctipjIvRyC7APLE9TGshrGQDcX6MOrMbuYBMER+vIa9VZ1M+LWQl
Q0eEqpH1M94zFY3r/p7kZK/CxroUhuo72A3J88PU8R3hcd9WCsKIPHugtXXKnEupTg4buoNpyVY+
A3zM+XLQjWXOhGA8qWy1PVVamBlaydQhqwpSN64Uat03CFD6snaMXAO3hlGQMSyYSbWdxaetSH4D
HNJ3STOlJGd3c6k6YrQ+2/NGfYO9LE16g6FPz1+ugeTdR+byU+/CkHU4DWjj84BMq4mVpa2+6Dz7
mcII8bomlDhVE3O0b79Ve318yyMDKhFJ8+mB4bbqoyTIMvnJOIwGZVV2dRcN/faytGipUNabhbV+
NsIEVkwR+fowP3ZoU0cdab7TMEbr3st/V6V0DpDzu8jtCYK1wsmsCzuNF2ngH0vSh3v67fBjRutu
yQ1mL70d5KfwBGE2T9NzFxNy63QlgcU7xLvyGyUGMQiV+8K87yN3NDmwI41jVIS9zgfZfrZN5OIL
2wDLmrjf/2mP7kHHOptK4aSpQKsNpcEw5YxR5WGTgFZiiU6Al7QQpnv3nn24Zsxgn1tmalvAeJu/
ac0G7y2ShSQFxfqenoa0912nxY5g5L0RVvdVYb7V0QiFOIt5lx+UiU9cPZNhPstxZt9z58RmRVsp
EQbWvhbktUsP+RtfhfZvIbnsaWb1wGP/DNBgxHd+c75zVU9H65WUHLdL6/PQ2QNfu4gjQRdDwduf
/uwgD3Dd0VWPajp8yZ1Tx67fLMZnVHi8QQtQZ54kv5D1+zAEuSMd6KqAbHCubV1zXXMesRe4GkxR
nX7jGt05RyatSUNcprqungFSILPNFfAG+cmxmaKuV5mbLF5vI24WNO5CE6XjHaNp+QEhFxaQOx6W
8K6QyIztGyTridsBBQ3Pw2bI/BR0jlFLXDe5L3Mzct96ZkOYlPKbMpITBQ06dD1Wc/Fw+PyxLm5V
lRN5MitD47etqNWqkBIdoIrrTn93unASpblIdB05gXxo1XpI9eLDRdmJGaVzUiJXFGmHdcs5eEJt
bTYKjxIaYquPxKwK2NnPktuRmVsl/84AsxCDYoMbGQdklePSTwtUkV2tzW5sYGUYBhEcv/zJLAV5
AJnd6G/cxLTemag+AxxogilY/jXqDHsRJfvmh9SrPzOJ5EkqlUai3ywdx52iSqxeeZ0BwLIppUi/
zsiWlZZ5cgoytOi5/dNbW8k3S8ib5NUoLJQieQYQi6H5RKsJ76zoOzv1Ucc3h4/Afz7X8CNovjt4
S7ZrB8nk3hYh2pgLozpRVh9e07/cRdN9NmXPlRUgK5VCjeQtDr90rR27ZMNLfWeA3R/mSTRxq9Qa
T1ldMjv98iQXgxnNOThu+LS1SN3nm/3vqpOY8Voa+BntPtma9RYZ3PpPko+0QLt2YMjTw9Se3egz
wEkrVc25f1J0tvUJJG7Tjgr+UHF+5eHnJNnD2Y7HrWvI7VXCk0VKyhqlNZUGu+OSdJsiyM9BZruI
mxEJKRHu//nG4TszdffyPKZNKyYbeWzSvNBm960cVz6qrtlcbCA4NimZDlj+d4UQjzHAEtGrXzby
2kekltUYV8AlQGCXghmDQHoA7iJIVhHwfCgcBK8d6KmamKJg+jo2W1tt31Q+E6IF/RY5OWyvjigW
IAKnYDFt2sy+uhbDMiGsVKtjd2Oi0tBTy64lZ2S/bI3RGSBqlPSgmfp303NizCTkExl/OIFRRrvH
91nkQbdGKzNFHl084t/qafCm4RzyKTPNu3csfZ7xTr82bVu++KqKIYv4cHylPlOFXefmr35ZMleO
dH2ntau8FvI3QePas1kztPMZAHucY09tsvnWEvalc1NBkzf+TTHNKHAeI8W3NS13oFGLlP7DtQCL
L/FkxfWZJ+mymKWRqHtOTjmvIz9sCn0azcRhL9Iy7oY4eagePChk1MIiDCuqrcqYgSubcAgc3zwD
vC1rJygRSBmtn8lveDRFF04i59/kClmRa++Upo5iY8pxBn6PrGWFkYd5xdT2RJOVVKpDm+VdE++A
RbMvLn/PAIfTCmtWnNOfWwO5ywqptIO5nr8aafDg5su+TtiF6twQRuhYRtDreo3PNCb6rcTcUNaG
72+5SOn268PyH4S0vDeifkBSNS3PAItbR5QBhbXSoavCRWEpD80ykUjvf/YgNCneVh4+e3+Hunuc
swLDrx+ftruSb9YTokIWqKuy+5h/PInS4NGILMG4KDKt6g5T8A4I/nGq10/ySnVBQ0vE3c9/qRSa
0MQcy/EUGcWZhHnEU+/2LA7dG3Mch44faLRmHq4moD8PGSxG/STPih/ikfUyHjfD2mlN13Gn7PYJ
8t7fQTxzjjvX25a2jtO6soEfngdvvhiM0+iFxrDrI7kUbBB/52UQPiqEz8HoLUk9+a+isVNw4qb0
QCRmHcmlAXvu2ZCVLNa/lUShr2ZdJ58SzwAqBJGGBs4zAOExKdeFKfBZs5kyVGFIdppG4QFHrpST
JRV24xpNUwRTX/X30YnVbo/kPxZ7GJpIHi8PYE1z9XjdfA3FTKOUhn+/gE6QmBFyqGIp6fSN13Bx
kvc/GiyFVyKoZs2u+rQxUAmSSXEBgj8SEW1LRdJ7eQ8/ozVbqRnCBC2XCuXHtFi0+I8olg0kd7Lo
ZyPIo4fkyTXmeSv0qupg3x1kKB6Nn3NIRPVYvaKKyUq13sJXgV/YV/UokwuWaHaiGh90V70I0lo7
uzEwjewXX3GETloaHLx6FX08+Mud0nna3+K8wcU39Pum5O0OS7JU0G0aQS6t3d2zZh/6q2UxXkcr
wKDuirVp3Q17K2ID5V5/h5/noP0GOAIzNeb1+WQ0IGWb031Ypi6gTnfhIVWTlt4Rz0FYWIrZQckV
CuZI8dN2qU9hTFNoj1XK1614PyNfZPX8xrkPMxXrsLS52KkBtKtmL2ZmqbCPVUENdMrj45n8BJJl
fSprzLP6GDqK2UR+BZf+JqW9EMww+6QS+SUtL7jn0BnFChm838SpVlpj3WLvThTg1zcD87z7APyp
i05RQ/GxyqEe4GJGUMtPvxVnyIVxZRFQn252CjOX3nkoB39B6u9Xcnmre71DiR1SAa99c2nIP3/Y
h24Sf6G48IUAUVRaVO7SIFr3v9+w0ymm98rINifKMZhhIWkxoCAjPXqIok5pm9qXFTxEoi/a3XYV
zhtYwKkkytWJs50V4HGtJjCmySF6hXA7gAJ7ZjS9HpcEsLQIlSVRfqf6Zm0j/qPE1/w7GmYyw7Df
VqhyOuYfJoukxhJrw4tymoepC23LYa7T/KH5ZOCHU65xHRqg/iyi3g3QowxF/SreOW0MoU1w8zh0
1qKVuhFM/q+Xu406LoLoyHUi6OBByoLQJ6gMtNZha7xmvb+BcuLXGJNTmUShmbrZotXFGy/CzXrf
LIXJ1mN8PYPUxv0To9PHLBai6v8zgiyV/ftOSFTBsMgZ4M30TytkWXDmGUCn7IDmd4ZoYsYaSdbN
SPzum3JK6W+B1b8JeR1E0xizHsgt2Kh4xtG3w1vjoSOTk+NSS8/62I4fZ/531iidRTSrwdE5Y345
RTb1COxQy5u6EPVzt2PzF3m/Qpjs0xrRqdW3cnUBeQK3WrnWwNHvuxS74ITssaNyOd54GNP3XC+r
uF/42Eqb6tRKDl6BaGC0JK5s7cLCMQfQFif5mY5b6pj0moiprTv/fdBWdleJ18Tl9ggNFhaHe1Ip
rxCt3mwUcerM4QU5mjpsDaXeafXZ+ULtTiUzHL7xp/FscXMUESNLzik319TX1OJ9hRRfnqgqdj3h
HT4D1BWQjV2iCmWFtxSQPX6kCHXoaSaV/m4y5eXC7aTgzZzZhXGaQftaVneQhY7qFpldxdBmixCm
1LmVP74cdjnnP6Djqanz02e9vSOL8TCqi5zA0CBunuaSGG1HalvXu+rZ73qMVjaVsd5Gpm4WblSg
FiVCuHGDhu67RkYmOoL/40KJYkj+sOOzF0RpMVCgNhPQ6n83FlZevESbZMLTYrFUSN2TK1NDQxvF
+UxY3KC2s/PQkFvGu2epkNoJlmu0uxCF2yhjR22glZ78lK2IbdZE2TBpLqbJP6MIlqyPiGMcvovn
KYJwCNfpzuS151gzDFWwVLApqaMBdlycLGj0b0sm/QIjYKUazpIJm4O6wFzOYMGqzfisCF/NKv9S
UAEsAZlgVEf5cefr6AFh1ydCgGkvpIFTg2hAqESbCuSPdgwKDtwgDflcT7PSA7isWJmJMYPtftsa
5SjlEtnp8H9KwU/xl9CZkMbiNoDggo3A6Ri+THau7I7Cgq4Qtk2PzThTqeAaBwrkw9X23/ej6dNY
/FR5mOEGFf08d7QMdlpHTlsfvxjZPJfTfzLbcjcuYeT8YA4MbSEL3enfJMOKRypFzLIreodj8e56
I6TNZOUwXA7T+ujs6qSfbWFsalfwjvJOdIAjQQSXa9WiERO3GnD8dzZX35OohE+Xcu9Ny8YpQbze
DYr54Ky0OzjNirH57/77rVUrPeD5/32fyAcEB/n89/83GFisjIxBAOslNLwWCKXtw+JsfWVVojAv
NhCXMACXuPLPpxjon1+gxxxrCI/5hA8yQpkOXbmKLW6TyHdjiRLlzk/2IQJ/aLMVvrMe5mR5RCsE
j7KxkjiiDvop5CuGG6cOS//r70NflAALghnZEgVE7iG+/wPXRiH6EfcFH8J4jD3iCqe1L3vhOHUg
ExdYFPUU3nHElTwDs4Susoh4MhcKcwm9H3aAcXKblfA8yE8OMi/dAT0Zun4CKnhFYPpFshSUwB0/
S+0FAk6cSffuF/VZONpzvZEo/TxotGwN/kmyuefH52fJc/lpmTUforeDy7Zc4QU9zpxVQf1dSP4F
WsnqCbAkUFZTiqDhZQI9VsElw0Ir1qO4hxKFqNtXUY7gGGNHkJ7gGyMTPXkmaVEg6r8fCgeUTm1b
87w5sWRkzkaH4WwSjEHf3w2537bSEyyOkwYOmpeJgHC5ZpBL5vC96e+5//uVJB+QmbwFZFf7gh7Q
Uo6WCgBWKCU1ROgVS4gc7K8IPN8SXhhz08joy9u5mBsgNscAdOG73jSgMQjROmFjnZOGM9JUzicb
D0UVWzKhHcsPUAETcKATcwaegkuqHRZpMrEx602bre3RvtamjpcaVhJMcd4vZloFZxxbhDsbRwzT
L/kQYZOyBLFxTThdfoUmQkfIvbQit+STpQXZ5murFJ7yxzIsfs02/AxwU1VffSv/YmBnEcFhFzZa
881ia/iHAeXkgniKYX/rUIHslfUzQHLx7v3N/64bGoLUH62SAMOPiqqKycZ86dzoXx/dzVTkSgRB
dCDM2LApdeRCq+4Q+MFn90EAXgLTpxWXSlRymOr6C2qFB5FYALXeacFE8WzQlu2Lar60l4v7+Red
sPvFUhSijbQ4waClA6Z97XGUT9fNjmWb3pyXEJ4L0hmHRY9PMH3lC0NeMVJbwAAuRxSgbknaoCkK
DHbUNvlstcSCSsk2TO0tCsNZWVudjf9fUEsDBBQAAAAIAHh/UUBd68eStCsBAMUxAQAMABwAYXNk
ZjA1OTUuanBnVVQJAAPEvz5Pr8A+T3V4CwABBOgDAAAE6AMAAJy9eVxSW/z+S6d5Hs3SypNT5XjK
qcGkwTEzc56lnEWRo6bmuE+jpampqakp5TybA6Ki0qCZopmzgkCaYA6AQoK4YXPp+73398/9574u
r1eFbYG11/6s53k/ey/WFk+IIdiem3fDPXXOaZzX0zgLE5Nh12HbtmzZumXrtv95bN++fceOHdv/
9x/JY9euXTv+z7Ndu/fs3r1b8veevXv3Hjiwf7+UlNTRo3Lizg0FMNiGzRv+5wH7vx8b/tq4abPk
bbfv2LkBtnHD//P4f23cB/trw8aNf23auHnzpk2SLbGSbbBN+zcfOHn26paDVne3ygcfOvcg9d02
hWt1H6WsB5cVtTxCHm7fcVj6yFEZJeVTp8+oaOvo6p2/cPG6oZGxianZDRtbO3sHRydnTy9vH18/
f2TovbDwiPuRUY8eP3ka/+x5Qlr6q4zMrNfZOQWFRcUlpWXlFfUNjdgmXHNL66fPnV1fur/29A4N
j4yOjU9MkqZnfs7SGXO/5hdWONzfqzz+mmB9v6TJf23atHHT1j9N3vBXxJ/92b9p88mzWw5ctdp6
N/ig/LkH2w5dS31X93G7gpb1spRHyOCOw4ra00orf1r9P43+/9bmh/+/Gv1/2vx/miz+ANu/bcOP
jX9v3CAP+2s/bON+mJgE27Vxg+QHyXM47IdfqY3/oUNWRqY7Njs3unWO3nWoMlhF3XyeuUl7erdz
v8rPnJG+Rz3FjsgpRPiLmJGlzZYNMpYNqc6u1vUPzx9yTP/nmoXxyivkZALtTapdzb7IRxvb5VMr
p41kdYD1lZpw286ntYktS28Eu+ksN4K6deQJEzWRWUFpx0/RBOe/wRP+NF+AlVOHfEDDTDNqDOTQ
x09f8RHlXCu6M5wm7dZsg593Dnh5NicPdq1COnNOx745u7A2MivK/o3XHF9Ko3jXZrVXDZosBU4b
gT2yNzYi+MgTYTuGwikUAJTSrtCIHc+G/e0gDuuDGOaDZeCgzd80CLx5yy77O4imLmjzT2ij4zal
Jx/lVKsDe9SSQtwGvu1ZUIpoTaWHfVM9/eky0UUa1blu96L+PEWjcA/8hxx1fRSfe35PbrEh1UvZ
a1Gmtk8Mo0YNBPRovHvufZ4j5Zkybz9un33gfO91vQyoNkoMqxTDuiuYe8GIKTHsg8eOq6XzlaV5
9hf2shVS6FGBywX+1ubHaH4cb4QKgsUos6h0jS369jkYWE0UqhuSCht3Hug6FlxOqYfjxbC/KK0N
aH6AUL94Cl946WtW8jdujxKBgsQgu0vns9ENQUAWUQzLJOitAO2OizVtNwzDl790hbPdaFD//sVb
dxPOzDi1pawidCkEfr9tgL+IFiqGKW0mQJucxpSjLaz6gFYaZxj7oiMrsPsAh0YQwyYDdGNtXV0F
3M/HcglP8yKrRAWj6plSCTpofuWZRRNwanqEUCBcP1xSy0VNNohy6APISexo2tinmcG7YhiCX0Sb
h77RFh3n2lVocqKWA62y1L0iRildmOu8PY4Pttnnkrvk/dXlFV+M36xVqe1dxLPEsFRHmcOFh7Mi
eFkpfSKy8iiKEA1ttGeMpfdgn27jqTdCISxBbpgDfFkMq23cQnJyiSVYp/SkoCfpk5yaUTEsvKwk
ixe90+wkDjTMks3jG9eKYRuc0UJFe9r8AbVzkcOdg0JaKKPi/SLQ+vQogR6/Xk1Y341ojIdDG9l7
5zgql1tjq3GfeQDbmPZZ8tIKfvlWTNOWKUmnubaPyre2R1djoteQSSPfLQzWCjk2IFbOI+XjSvSn
/YMHk7AlOZsHWHGGFH13pJD20UmrQwzDu1nUEPzre8hANnprmuQQbQBHRAPUmL/vTs6jg3kp63f5
5TiZ0A/LQoIaLQIk8Ef95/V4Y7VlghQxTG7fOSOOGCZlLqr2ZsxfgryxKYGVOCGLbNICYsCIXDFM
eaMy3zzaMdMNoxqD7+CMJbGebOV5Z/S3oVod9YjcIEkBAnjrBdILafvdW0n6X5yEnSDtnN6ykCiU
Y8ZJhdOs3nO028fPQIkbiwZjyLkR/Di3xmhMuxiGg/9OSx34JRMozY+7SW4j8OKc45dOeJNdPnOZ
PpK3DbA0bG2Kt+LKGCVf7qPpmBfSPnpXTJl+y3VCeGE+Qv3HXooGRNEMMYz3HBEgNFYfy1Mi0Ozd
RvdOjks1lFO/LTaZV0YqcPUirdQATdAlNeAsje1ZfBpArG0j1Apf53++lgmNzfxc8wQJzFHV6FPN
tDqnJjEsLMJ+Lt5dsw5BbuzZScQRubJocFQ5vV7W4saoT8qAj1sSXrLTbJRP5Ww8nrhXENYvhqGl
9opaTXR08B85rRfFsPbbgTW1Lpx89csRJozuoI4gWq6kmVHvS8Ak/pnoIwBcr51naFn2C+ORQLI8
W8SdcQJGRZLaQjYMDVL0gCUsjUwYKPwcTBcAk2yGiNZOjx0Tw2YCtK4lnXxItVzN9/5sck5Sy7YY
qrfk/8tBuSgEkQfg2SFi2D/f4D2lzwLeD6sXQGRCIuQkQGOBHzqePU3NUCdoQmRoCaqhXklrSieE
8heyBukJn5n44SBRLpAYdn1PnnpXI24nLhAR1ZpnMzdUUxg2SZ+KY8axv7arZKbICc10DgdJ08Ww
BzGN0Ueuk4Dxsl44hXGU+OyXF9nNPe940cXAg5EG96pVg8g4SWNoN0YTqwNBr9w7HPg8ptizh2VY
8Hhfdp4VkFjs1Po+v6++h5+ZV9TNoJE1RTqWoh2ttIMuXbOu2mfa22g0PaGkNHkVgssDi2CB754z
4Q6ePDeVwZ84UD8t6FEEUUYMC2WjqxZ3Rlsuzdcw4vv8Sm0Ra9L88t6UegbUMX76hYzzr3t4l51g
JaUOmr/jbxNBdcOeH2TW7MniRAJ+STl2kFzam3+4r4+1Ox5uELiHd0s+sF2ogy1zmac6sICxyNw4
OxTW+y5i6QJhsWIEhCeCb0P/yseqGLYFVe/cuS3IAx86RLEjUEuXWjbOnFb3vz4rnzITuJduL4bV
36B0HQO4xH40z75WN+FhgN05jVOTODmmzHG5UKH1XwmXzoOEjC2H08mLLnqZTWNN9eb7xDAbzUkB
tOqQfLSoofmOGMYdoHdZNohhPVf6rY7t5ko61Gs8+puCrFHAfKuWhVzOnJzuN2TYYPWM/4vHZ580
TcPbLdPRH/Y4CT9F9l9USMYCViKiANksZS8bwvmSl5PzlCA4o9bgfSR/Rvub3jGf1uNBA9ZDgTa9
Leqbu3flNVd8/8U81vujlrV8Y9yl8nXpUOZR26oE/a4jlfe+LkQ+/DB0rK68KyfZAnkVpUb+qyJG
MCmGddkplFLMpphc/dq1g7bggd7Zj8evKpFqd2CDtc3j8/2WgVB+uYth3nG7V7vFsAgdjTefKedO
+Hv9xBrLh1dnDY9tJKpbAP5SRbeZR88pL7j37Yn5EJ3gb3Rovuh1/uaLskdr/Dkb7N6ryI+WexeZ
/Rnvw0oVyrQAHKjj/g0RqfQv0u/5rt2OjcNJIz2Sijh+MxCWf/oVm0qW2E/yUNJlo8vJmM+4Y5vh
uitd9/bUM88LVeVuDSnWh5FiuhyOKmDDpM8+81gk4eWHEgme2TEmu6sVE5OYOXS24C/87rjJvJgP
oZxx2aioPatEm9A46rP+oMaMdydy9XuTODFimIqQeBPqx/Tf5wkHRQudjaG2VhZl2sctJNwDqxyr
mVituFbrL1q84WU64m6kriIinXUp1LXYN/P02Mh7zUNpe/PisKbXQi2PhZXnq8nXMfsvH+wzU2S+
2FFgdPBhc5dVluhO5dlrdg9KXGu/7TZ3fqvze9MT9ilqAtXtcXIuod21fzY/8NvcGO5e/7XdyvP5
toCKuUPirERJ3tcIs7KFeeRQoW3lZf8cRbOAcR2k3t8HDDKcJ578JDWiCuyNKRNy34oyDS9UmnG/
Ym13vbH7lesd8NetCtanT6o7/avHRbx0to4lb1MCidaDA03y5HKYoq4KOKox55MscDbHVOLg4OhF
5JngTf/0KJAjzXH3gE4sTv8yewWYLVwUw4JeR7FejklfssFoMarw/nH98lmy34+9h1bRizIP2ptt
MKm6ZfClMfeCzJUWTsh8wpxRe2p1cWwCn1mvU3W765iaJ0hbhD/xXyyWe28S8jL2HctkK5j4ws4z
0o8UVqU7W7gBZPMX7VXLfIerfmhFWvqLmDQ9EdeZK4Yx68Sw2cfJyGFD0HDcIML8vvCLc2rjq5zJ
WdN8GtHbrVp4lfA8wBh0fARaL24NdNhXFU3gIWsNSpp4FnKkuGGFVnqzwC7KSvMBgPArUFqmEyZq
TlyjxgSzyANEaNWX5JeKfd2acUTw5m9ro0B/UmukA8EPn3IvlWkxurmk7MSnsUmNw7SeLPX2JpZz
1lJ7KfSXw/UtpG9yjaYahg+k16SFOTnQl9HAmZYry3i5VWsD9ppUwDeedFRD76nnNr0/weTV67Zu
Y1+caqrpWcB6MzmC6DTgDIeLJKB2Q7RF4l+b4i2HUZpLmsqiGWJgBTCJGv0voPK7fqWbqi1XMYU/
L/eqw4Ml8Y8at27lglrL5f8Skw2wtVX+qf7j23eYfsNL4YB2pxttDkYz6HzG8aoU8FnHItBgIycI
g86KYRzF4fvWipaUKTPCEgT0VeKCKKMDLpMDEZpZu+I89+bSoQURo4bQOV5fjC2dnLUgeCd5kYgi
Gl60MKedl3ZjUPQOhdNcl7jWd+CHHYIDITyzciGq7OShuAGQppGtFn2+MrOnfnqhiLBoCY4IToIY
NsAxbM8uB94a5AXs7szaCU7wI6Nd6BX2TQcpEtCdi6DUJHZdog5boqddwirWLYWPTuiIKJ9jxyCJ
aEeIcmpMgUZgmPBUHuAs9dcP+ba3pEkJYoopqsAOdZOwYmJAiMTc1V6QwwPBWkYsBTu4phdlXqna
3dLxRUKwd+cHxLCDueoSyV3dK4GojQi6TQ97+qdwqo22th/hcxUomJrvAWnqHajqhjU5sNoi/lp7
Dpnp4hBg3C/DEuQ5VKpI4LBR35ktqrxHCI4ZwIvYvApGnW7/RsP7PyVNvCeGnRPDfsGXVdznlMwk
Bnw2BbKAjADOqct3iyk0NsdGhKD6CByg9ZLYh3NMOW/Ja6LxQaM1iZ8liHlAHTELzQmEKrVP5OLw
aEYcl22f/+XY758iqj/wQ7H28df2IVZguCCRv44SVJgMsj0effODEMJoSFB58QVt5WwaHEN0eUqW
E+7AxZhCrqDnFOZXOR6slnxKeMGh6aUWggTJirpfB8xcMI+9yGAe/ZkSUusceLhhCp4lo6UTdliu
ZZnTKmLrQMhHn3KPryqjBXxBhejVBYi2LCDUstIlJnXkgJNb0WKQJ6C3Zp8bfDcCDdXrOk8NBZ1q
G0NJOn8Ps8OXLwX/rdIS/mzd/u1KKaXVLpZGJQt1TvSeIGKERgDiQW9s2uwHbmRIpDnWiRAfptRe
vERbuJsthlEQma09GnLQ/ng7sMNL1TbwpBh2DZfDME6mXoizqIawBDykLUohnI59zQFpM1DTnqcy
1yPa073yPWLpkFJhDMiLAQl4t6AUPZIOXkDRFcMKCb2E1W8NGlUdXep5TPy57mCuiYjuXbgghn2E
xDDInB3yEERQzhWbUzBtZk0AFo9y4NLJuL5YDIXCgexGkHopAd461Z8j0ygobwRLUwzzvk1eA5iH
rdGivhWjuVj2tBjmj7yc0i2iLSD+XdfU2kF1aRTDUsJfA+PqNFD9ChSYwkX/gd1KF8PmrIGney/1
IC7EsVfsZ78XuC3U0osMXAOaLAV0LrA0Evvs4fk1d5cIau5P9HSlZhm1h4HOsaQB1RL+FC2MjDbF
5lqmizwjgUVgrtokesflh5SCQC48HiSwBnuI26Np2w4BWA1hrbpPLD5cEhcBvLkU2I3ixTR9AYkO
jZprnFE9lZimShwdrO6oH9o9TxBVN0qKYiW67q/+DPZEHlUzKwT1Fpl1PoWPWQAkvNpg7unLcBUA
TE0QG9boFKTjpDZOpOppARH0aiDaS/7Nel7/p2cUCNHOtwN+y7wPczCHN/iepi2JYUsj9b/yb8L9
uPpfRwl4+9p7h5Mi2IkRmTW39/OBdvO0WrX/ug4sq0YY4rG4Jvw53IBKzShZREqgfdY717XrSYb+
6lQlFGXlO02uzAi/VkiMfX2KLcdDov45puN0+CcTxjnoA4/35SPpbeN61i5ft3w8GJMk6i3USAlF
n7vWeUBST4KKX8O1hTmyJsfMyIcwjTEEwekllDvFKXGvElWeCc+hWg0IdyYMQFP7yO1t4b+uA0el
PMEtPsnXbNBZi93cChQqILAl8roe32FT3J2ZUuo+UN0YUCWCtDaKQ3UMWNrsO9nkJDXp1DQa7eiV
G+DymYNb0bIDlBkzDilzEItCRo7Dz+3rD/zMe4Tlx24BMkyKXa8f+zr0gom8XnTjFOfVCYPVv4dn
7S2zqi/dEn7SgzcWZlkfNG52gD+5d+LvRGbUPRvUbhzd41K667eM0sudH003bk2YHP85cg/UfqJM
OfQZbFzdb2m648Tft27uN1uvtom3r8Mi1FNTsuB5kkF/0P4iyb0Frta8eqF8S/qZhWqb/pM5cstp
14/xA8s8XZ6AYlgnRjdA13xY+zsrfzoDnrhWYVUUOwM8LeDcNSaFXtnv1tuAWiSsVfTPDlKMtvLT
LueqvGHViUb7b2cyZsM/vLP9tYmhnfhUQbQwNozdKXs74bg0/1YtBDr8068Yr5huU5Ktlhu3gAYr
aF12TJ+rpSW069LkfT24fkRavWJqxPmtOhsNiYuWTfX5HEuNv82tBiSRPP5Vg4lpuveUb1TJKMCP
Y5p4zS6k6t7XKqW3ll8NUEuhVzsnWmaUbBct3antN2caJmB2Xqo2CFWarXs3Y1Ldb0+ZarI8ItU1
/57oVWcuPPlVbWDEfpTass2y7TwzZ1LHK7TLwN9/hLgSPMm7/34ry6HYAwm0Oh4maYdx4NH2YT5p
822U5EpoNDSL0xyI/in1xCKO62VxB6OIA7gsEyI06tqY2/9+pEaOraXuUZvvKbDj5RhF5yXJROYC
zwP0JO69PZbQGcrIttQmdX6/OWRTVgGrzPEx32/7xK3OI83LvvFr9vu3Mxmm72o2HkOh8aaVXUgf
v5MnHMumYuZXC/bcL7Vo/meDS0KRfBfr2o6E778HpgoW+/3GTxvpnn9tktrxOvHCCR/g8dDNQ68E
VyoeXpD4TOarnqOFCmxM8V+a5Hk4ib/i/DwcYtLm6+vYP5KpIakdq91UUOKG1iGk2b+FmOZmkMYa
O1yMVpPWkNuYkwMOQR2DBScfJQfc2PyVeEL1nEq7bNM/m7dl+js7Pd9oGrVrJrWAFDl/M4Fl+nP7
oxv8XZRQgX3etgVkR2KwJzLL+r+HiNYMbXtri796Od0wsBK/VsHzSb/ygHrG5YDe8lBbuXKen/Uk
q8+qXh+goKdLptmWQiPNp3LTF8DFyMAiDi1VqFxxKOBhIp6tSyKt2Pbknh8WebgUtEqSeuVffqXY
mftU+EzZRKWsfdyJDMZZxeXeldLXvZilIfUXQ8bcOaKRQBJE13dbet1KKlXiANUdTvuBiUSCcHul
Gdqq7ZJ3614tPqcSaODacf6XG3FFhy9oBagvvvakz2fJXO67ErorG4VpFVRWJ8ui9Kxz/rmfRpRE
4EjC00oX4qZw6dBtfQbutNXXgiIEa+jVyVLIQpKPDxFqmxkly5QRObU0F0VMNJGbvFDuX+KGPBep
uyA7fqFbtJowfycXjLbu6irNOvWyu19AeAKwc1I+F6LG0wl0mgaT0CUinYyPJ0FWtaLmOfkhtnKL
7kJL2PEIjTNB2gFkv11L0kRKUi85E6tZdF9jyyD3KxUhx9RxGZma9Df+4CkK4qF5hMkqUeaLhjfx
5m0tuOhnnrRjQCwBb3tp3G7aHYV9JYaV2qJBek5LPDiagaBIOirqpIe5ixNbjohDSDAQbz3l6CbJ
eDVJabX3zaHr4QAbDiUiW6KBg2LYW0VAkxwz5g+n/nEYIYF6NFWUVxZ5IiJVL10khk2XpX1i2XIP
HD0KTDozdWSdWBoxeLNMOQ09EuEzHQViEYbUHKPPErShKPmvAtEQZWOCaA60NaAvro/bVX0+gBTD
NIUcewHQjsv5jJNw7wjzXTrD8rIDtNF8QgzbCw5JjgLZ0IhOFchmK3Ni41AYocX1DsQ0jQNl0Kau
YUiAL2i8VjSF8YZm5IXVrkW0X+/NJK8ZcEAIo1I89wLUNUCgYbWasvr9W8ICfS9rNisCVBsZ1K4z
Y2jMpoO0Lnttdh4Dve5rJ6Q1upaw2SqDEut6xI5BCE4T3rgkPmcZROYVodlmXNt0pF7EPrVzFoqp
pRR7dIb/eu5SeCJdAKzQeEgzeJg3mg+/j9XHdPJFE1/RfmLY44c0Gzzu+XSyb/IFA04tBYmqXuId
EIxxtK2BSKSL5upBMxEJlU+sLBYg2zEESxq/WE64RV5SnabKrZn+bXNoaixzNGjRsb3dllvirzvk
GgheqxloXUX9tKTG9uMN7CCl4h5WjDtbEgbPtV3sWrKn+UgaIqJUGmXWhd5lRF6CR/O5Mk0LqDd+
MewsVvXhpvl6JwOuZm+lUBKs4+YIKzaSrI0DXmFE2NSSYv3Qoh6OBGDDq6YCHPRuR6rXKfhMEWWY
UzSmTceX9Eg0P47HJCzZAr4mZgYITaLbIsTU9HSQpMAz3zbRyHy4F6hBBFShlmpdmlue+jucH5OR
oDyVqB3dxGKUiR4iNPsgqfJ7vzwyaBFCLqrxOokrjKmnS5rw4bqk0yOWNT7PqL5Ge+En98w7BGhm
cVDkFLwVJcCGEosJ+ZJKFsMqEnQE9g0zTWkoEHj6XN07EQ3GqgDRLEkSfPfNiTBCH/E1KyJVVVRK
xnmDA2FasWWS7yko5Ej2T8IjyKSuGqJh+hoOVWYw0KE+iAOJNpGf8+Fr+4jhUUX2eMvJn+kBQc4v
FzltuD2/qnBysaoGEwpfy8Swrts9HNMPdrHPvh59F1YRW7m0IkC+/Mj3lLxpOW69lKzfaOvomRRe
FcBHFp1wZ1NjKu2VcYk9XAN2v6QljVj4sThN9l4xLPVU44j1GGlGTpPRnOJpwJ6382yePDHAw9kh
7z9P2vl696XdZidbuG7wxHAaP+BKQFnOm6xFufUub+8/5xafNBKm5s3p5sMoN4ZCSGzQGXWDvtQm
Gq+8NbNWirzFdPb6bJXTZd6Ycjei/cZpXvqa4T3rgMPjVi5K3SR48IkBiu4oml/xLa/6Y0Cg/IQZ
14n7BZ4X+mlCcM2CEm1jtdOGLxDD2v++6DP2A9BU+SBw0duQCdIikcKLBBKr6qbVbnKBRXfOrKeN
S9Mw2UXNKzJFU8S1qcFIr06ZXK10kwLdWo8eL8klUJKAyaqvjYnxctqBlSJhDTzvqkZhKF4lF1hZ
qGAshHJ7zshRILmhgvUXi4HWn2/VNWX6P+OwspsK4ikCO9vxe786B465ePlHsBTgmvw45684bHMO
XC1ze7LQxv0biWKW5jeSMk1tgT8NtS/9WxNAPmexck8RMw16ekcaXJWq6SX8qcS/xi+L3u0yFJx8
zusyUlrsjR24OczDNRp+q6AyO1cYd/aZ9cpL8lpU63Hk4q3Y82ppF8I2+t2JkPkZc0nL5F7Fv+b3
+sOop+syf95KsL36evnIhm9nXt4hVjqTJz4oePufCznLV5G9bKqZcTLtMgSwCYsYUOd14I4zvkd2
ne9XMELJaDhFWYUkproGZdkQH3VoUoB2/BqSoZ7U6arBLYmMJsz/RENPHM+5O11z8WF0A84PwsaT
Gg5d8YSido/kmTvueRh9Fi3KzzoWUzFgG7btWVKGsDoX4sUhu9pGa9jXsoBW3TLEK/voxqpIT6v+
vi3D/XcyDczchka/tCSg65cQZ+0c+BguERXC0NvZka+QSxxYttO4o0t0oZhp9ZpkMeIWRbXQl8p5
65s6XhvC1yuACJTnObPxHP3Jg5DzueH9LXccwgtqDMI/wmJn8BBysOH+2BGHjE9uBl9AMvxJQLrZ
VAwZQtbtSusTwwAGtCrt1Zic6lb0Hmv6hXaWLqIY9hxyd/VloIjt5ZmZw0+MaUN5EfuM1G91ZhZz
kijdbniveb4uUxCw46flU1MSEw8Q4WwACzFNwoB/4+wvOH/D3MbcF+A9Xg6pf7J4E6BP4H1Rydmu
X60ckCLwGxbDMqqmK13fXeUIE3GsSlSZrE36Es13gMUPAhuT9g/IoM4PB/z1MOH0201SQd3PN9tU
rt+nnJYqPucTGF76tmh/xo+RMlUvDzNpKb3sryWfWs6Xmp84Eot8eRjtRTmwF3lQZD2id6xipK6e
aZXv/99aQ8tC1ectjfv/k3J3NJ8dyhyU/8YIG8hWI87GU2ncATbwE2v/y7VbWdlp30/IWfXPBZPK
ouWZTStb8uGLtVAC8ssYyUyzdBeZcJ+2LmX4+za0gpw9XKVX/qF60wazv/cANwYe7TDyR31KKNue
uf992wh+CnV36K2d4j0dZY58911qq3+jxXNGazsV05ZLRPNyvc0CwkJ3QnMhf64N7SXJNy93wluS
YlrChYQuaBjA3qp/ojCkrrE/7ahvKt8MmltmQTIXNM+IYYkSj91L/30hclTjCEsg97vs1EObvKHn
kTWJneFfM8ccrp4b7uaOazEepLvybxmnql3VXtoUiEDuTQcrba4CwUHFB0xuSgyidfde+9ac0Ogw
MexE6pfeOLcKDmrayn/se/eJdCVOWzjX7N/ByDRgB9DAGcsEBJrQq0vHwkRT/f9k9YeecvudtpDl
YPU4xyTG4erdksioDmLX1nsHbtYK1Tks5/dN1gv7LHnpQSu17INfob0851flYCUN4q8Zh8DJOQ81
0xo6aPimd42jmtq8c1cgJ3gXZ9w/uJ5FP/k+c7iX0yS4ZBBLjkP/gLC5/qXPAn2zD28MnjsXx1+L
Q2abUNckcIA7FMKXedLVtxiswDD65Ycf8W2/8JrrtpWH7Cg+diu1lDWZC2IDEMMzicYJjncgXftY
gs4ps2vpfALzu4lOQNXU5FXF/Sjy3ySaCksSfb559t/rOGiKvjsynbPNi4PSK/k1HoIDR4mm/65V
ITXjqQz+DdOWu9EaeSFZ+5ao7XoaC6iuAZISF/5cEovb9AKkmItFtItFB4hrxX6Xq6RzDLPibpgo
RpxwYP2CEIvMXQ/lDrh3/dUFErLoNDrERYMjZM19rhMm9M6XTBqB4UbT8QM+6ak4aa5LMm7foJDM
E8NolyLidLK937lSS193OHdWNxn7gBlAO48g3S78+P0pytqpJu47GKFzm0sAGLG03LAgl18HOgp5
lryIP+cNPpUv5PhO0uiTIloGznq2nHgrhjYt2UAQ/A2hha/z0QfNNftnvzQIovXFsNwwH9n+ZYEJ
SK405ps9JA2Hi2FU4Ofo5uoXCC/QMLeDR+MDpEI+oU0M64kfPFQd1NHrQqe0hI+clvgNDRpFrwFX
E230rM3afzQhWglRxuhWrL/wXBbBFzzQaOAFXe/WpBqLYTxkiwokgR2l/d/czHnPb2Koi5b5c324
BHXCwmJpyzIzE6yMvpft05QSN28w24uJRmlB+xNdTFFxZF6K7sJlcgGYGgTmlodY0qCWhAtkl4yn
ZxTI/AVVp44B3fVfTOEZemxNAE2rtwmVewdkjVovXrM0GO+hzboClRQ+4YetGBYNEiQR9Yf8OSGb
JqgUMUdDmalxPIskxkWmGOZTkNOrmGGtB6kTdILc7geRqEMX9OfbJhVoQgOEGCZ148R4GkAUw0hi
GEd+wWPS1WhrNiHiG97//ZRinBegl0njjwbMux/Aj6p3fCeoNDEJVAGyKfuteZlbewM8ra5pUhEt
ysQoud8XwiVQ3WPEyogjzwriEBSERDstQFczApEGSuRoxyhetHOJb3ATzdCkUCA2tRx9b9u74cJ2
XDbDSY9l74YPj2kULHJCARABfRXsoKETD4jY1C+VuHomxAZH3T/5nQz3RU9LqKOjojQNhCc0Vevr
p7s4T7m6RcKRqFRUCgDC4X14/2tFkAHiqT5hTVqCOZrySe2dtwWDLFQt3z1vd+ftAVm0JDr8mQXg
QfyYFYEqMzn2rN9bCI/ul2hIthi2LaNXqZZ0XL1j8FQWNosFtEt6iCIZnyZfvS20AR8OHzjMBhfe
cj1wiXzEohxbTww76NyaFe/+bbtv8rSGwlNLiaSF92ArD7uEG5pAqxa3AJxoMOX9veR7acbkpne5
WZ7WzqTYcmE72bkgNfws4paKSsz+DdmVDufQ+4XkDueEbTEMck6muXKSfh89ji3ckXbUvVGt2Pwe
xGMLw8s23DpaYUNXHH3OM1ERPG/JDWeUqBHmz7LSKowCFOvaHq0ZrBpfHHvD33iNPvK5W/gbWfLq
o73BaLAYdlklaHPPm52OV3R02h59TdpwlMa1D72yXHEYUtms6c9+rysvWh3BA3iXw/+SjT2jswvd
L27sD0novHe+3PMlS5CbQAjSsCnW4wUYuEUY60Ln2eZhM9v/mSHJOv6EuDEDrqOfy8Gn73Y7Xb6h
nc9h/TjgFQKf/GFtpHAkzm4KxOdU8nrq7L7xK1JazWJ3eX2Nl4O336h5v+3nxlNwHe/Sy9y1kV/d
8uWW1k7fnfWfRx5agcU05Bs7pLjas8pn1P1RWf37IvV2ZnQaHo8f1hnwS5CLPtvdkxzwbuV4e4XT
hwKGsp/Vldu3WLHGZ50NbiEem35Mczrl+FnX3CivvaWK/iImexPERwu35PD3v/v7wOj+1lC+7Yr1
gmvBpdwIrsuxH6vaoDl69UnK8oqFS+blLQtJRel1k1Z1mx/s6+7H+rWZHj6dd6HfyoNJ096vueK7
UvFr8/OE6qIYG7tn9RJ+lXtd820kMMtnKqbxjPMPx6RdL42bwdFD4XiIz2/63mAugxqQ2vtmnlpJ
Gj5Cb7pWr8dHoCxLX+IUfPkW9tIW1i595gknraUNLT3fNr0sYJZrwjQeyTZDGfZjp3YU/S510+s1
yKic6AnyvYHHpXCwGZcrPfsgGazON6dXdtvR212B3R5zO3PlHVE8I122YK61rGtrHvRJQpJVsQQx
7Cr59uXunqaCUqUEYzltm/mMB2+tjA7BSPg7N3p320ghv0O/7aynnucZfFqJfPX+c/vOkf2XIu/P
SXkcvba7AzvkZYbq0RZEJQR6ndSub206a+o5BybefHb80/O+166/y//OOV/3+QK/9N9TwdjWhOD0
O4xKyq1qMUyN8PuieaaK9BGQMPRU+6zO4WH0W/zzOL/cNQKFbIuVXR1R5rY9eQSPDmKLcqrmm1Jp
C/b2Q6KeOVs03z9sMeCS+WQ109PLschLkBvOxGrefSUvy4uWmdjebK99brN808+Xd/Za3dLT8iqr
/+fbpbCSpk2GezJCjtp5TkTlmD8bJ8LsJlyrModdnqvBG6B+Tnpbxx9XcMaNjlZD/frugRcENixm
weUd/Y0+BKeJvmpcrzuNHT18T6Rj0MkflxXWtj6Xo/pI1MZFyszS7a8zUzoB/DbHDrc6Y/wBOGvM
SPi+t5xOFlxykGRFFKHdeb36ZRMO1xIfkRrMjxCx16S8zFQuir6N6uG1m558xb7wfzkRCSxQMBI4
jaomIwd3yr0fOPGrrX8e2/Tn6r+65fBv5uH1dSppu2aoihhWJRonclggHqjW3b0TIJ1KxSx9h2eB
hLYBe+rj4vLDhTO7KC7fUj3OF3KuqAsPNcl0Vf07cLzVtAOgUUHCD1Xbp+kahfcyx8SwL7QuEY1t
m1j4wdmrMcdM8RE7yI3A7/fxS5Wqqb5b6h5bfDd9wILWxQkqq465lniozlUBlToJWfLK0drnq0YN
xrXUuDFEmVKJyexhVGz3RO7MJcfH+1IcC7jHCb+liihX360/rZaaqot5oWA4mf+0ihrASyqoeZMf
GQviDCiEdSml8aeGDvZ1uamzrqXZjHpOOTQjsR6H3M//tj8ZpRePpFVX5bsmarvAf5hhSfWYRhzD
Wna63YNo7jL2+oZXS5PftYoaGj8b53BBK+YLTvv4X5e9g0xIbdl3npRM0oN2VUKSvRRlvqdb1PhV
dOxdBgvp2jHwspK8CAaR73zquaR/cc4AqSlzPZR0beBU9r8NQd7kppZFVSe0r+Ndt77RKJRm7/PZ
5IULbYSMcRZODPM26dgqCdLbdfO0qr8JDtslZfVyILc+fBy0kHjtHtQ7IvmdSu5gTgNTeFItM5Mv
FxAvkr+8YkLvaWka2R4AoO8ylD5XWd/4LtjRzyf8lhnmt3H4sSx3BEv0Uhth/x4ad0m5aOph2oZN
R4PwTgKliokMUE1K2lmbjZ/zG/fQA12A9tvufjhdh/3kju40QwcBQKpwOIzeu6IghrWY0/hwvKbw
dXEj4ZMfMkvXYZ8JLtocB220G/IjNOhjtPj5Pkzsv2vWq/I0BlnQgcjmufXPoSS1LKGgn6PZh7P1
8WS6BUGzX7RwWcJF0QTpLhHwLDfmnG7bmYrrd3nkyCKO/YwO+RTfzYBNqRxbX7LfiwLpreim2AIn
YJIs2f2rNbeoY07FnCy2lU5bE5tOEG5FGURC7CkxjBkvpI2fmaAgv5tc7v9Eqe602NiFPsCa6oig
UvBgI1jtoQqi4N5L/wiCO3H/6FFF4xQydL9Gd+ZT9D0qDRoAR8rvBiu6R0gK7mc/tDA0hyGwJJgj
PDl4vDVg2Z2M6D72nXxjuOq9oJqDIzbVs3SO4OaXBYO4SX5kvRi2UUtiwC14F6egPxeL9lJLYvMR
ej1krojSGG0GsdcZ+7WHTpEj9Po6fKFLbkmi0caxfcxm3P2xvatxSDZFCD9FrVEOuMCcjOkCaREs
HPTIWvSQKS1pQhs+S5JuPkQEFe/AtNLpUMs1yi3uJ4em2/ODVVlWX2jtAmcjhCgXElShTkzDGxmI
s/Cf814UxcSmltfv8gMF/gRfCXn45O46NwVnjYc5YDH6sTRBuEG8S6WbETqa22rAyyCE9xK5v0Gs
jjDV5Zd9E8fsBDsv/EsvTRVO/XNZ/aKjr8kEkWul3t6nCnaSzcmW6ev0jU7CWpUZ7UkcEXEGF7vQ
/k7pG9GiwUSpKg0oMiQDg2IYu1a0PeBVv+UhPQ0949qmFJSIVq/wXU3TA2cRW61hgD4bg8lloPlA
+y0uxibRmFtCgZNw5iI23j3qeQi7zopvU8SduYSIwtqe6iGCHej4LIhy+leMZUQcp3/PaPKot8CB
jtAS1Wax7eWBQnIcF3KOHZFAVkVVz0Wgikpg20rFf9jyNBkzjxTDPmGNf4oCJKJ3K+FMkRhmn6YH
JuIFtj7xyzb7vqteW7dMO8ITAHiQAOrctoV/tryXAR9TlfR7+b0jg87sE8RohPJlsFBS1jNV/yGv
SrZE1Wh93524d20Vj+YjwxofDaSLXksRftg9O15O/LO5kpTASGGVZO6dYv5pkwTQUvj+OBGpzCcd
HpU/TDxFDdcW1Tx2nTgrhhVcl5CSPgbv5Fjk8hzesXrO9DXjsgSCVfK50LUC4phV16yZagzZ/+wu
SeKvJLfCZyA+skoJEPiChG+vtssy+jVi2/5rzCzDqPVgizKk4BRIBdUZTmszMpGMP6RmXjmdDrT1
W5Ki37S1bmuRKnK5a4FZ9EALwwvq7RxrjL9PHIuCpLZFNn+OpQ091jz6FVVSbHnNkejoMUXOEsOe
lys+2dQLH/156EM4vzSy8HyB5m0f+uPwxZMp5zdtFMP+qnTGV5Oft3y+sikbWo+yP3Qg8GQ3Ehcb
EbpnIuIvTMzxDmzt+VSHJVhpjkMKayTzvc+lJ/Ockd1hIbROQCUw9NZ2K6Htq1WJYnpJH0cHSV14
qQasS5lgNbwFpuUbexrubN3KKCJr9n8UlMPWDPrnRIOcYsV815da/4A12L+urLz5MTyQE61BY42G
Hriugzfi5sPxNzitXeCY3FItH2lyDucK6NuGmh8d+Pr0ZXfkmdcjqTi6hK//qsp97Ei/U1KbW4Sw
kKh2Q94D/Zzs5E47/a0BOxLlq6686z8ddF13qWQKf/kMroVEu5H5BbYl5IzmM8nT0aUbU4y5BeTj
9gBjqyydvFM2jg3XVM5oGV05dOasudHV5t4z/irbD5Q8SPhaUlDO7GZLLzrs7sn8MmSpmFB4iFmf
7L+C3qZl//M5/ZjDjXNnDmO+Q43P1Xqjx0rI8aTXx2wPfD59+fTIDiiw36KPgrytuKVKweDMhttE
3UuDapyv70z17bi73twr6UHrDqZ2Iz0NZS4PkReaDtwgKyRMH80FK+2FN+8ECEoe3i8x8/JBaJSZ
oxTTr+8o801ta1zHWlT44ZwvRToY3IIWj+UOCHc8F/5zNOdd/bbKgNBzLyNnsrdazTv37EIln3lW
zhP0bH2REDzCap1dcbCoqC0++26jtrL0xd3y8y7XWxJccv3oqfwv+ZIxFvG7eAibmWIJymv/O3VV
1fxY2rklNLhIr1K1UOEwpFtMgWBpKjBd6jzRE8m5RgiLhBYk+jZakM5YM/hGA/9lJe2OsNvy6dtw
n/TBzy35poRR4Z+Bm/Rv0qZ/vvo+RejoBaawTSAiOIIbOzhZIUjE8A3YolXbVo1gUqEYlgYVbL1e
4nbd+12PfiAhKJKHguAKopyhwbDSi0qjjTZqEflxqxTl/q80pn04Zrr61tXDd7pfEzT78AR2zne3
E3cY+/d4W/EBPLRq4wARXh3UNMD5B5TN17e4SQR0eyiOIZgE2q2UC+4kM1mzOL9PzP8KT70mS4zU
vB3ec0fJe8qEUsYYZDTE92Xsvcm9Xq7q2njPGqEk6n+R2r93MgbrkgQaWFRC4/2ulFnNiNhg3VxF
x6QOI1Qu4YcEvtQ9ZVXLx8wKnvf5xfnIhflnksJWObjUTemBi7g1pPfFHOCHkULpilqBTUnBDUIA
J8NLAC0Cv7Qn8qNRW28n3vY2iZTuEcMcuDGEJWBptM/VP+qxt0KAfwSB4pwIytkmw3WYvpzxNTHs
sX1IOWsApK1tW8+lbn1o1NLxakV6wkeyl0wgvMXlI9gtht0fJQbsJNdBKWjtBEK0x+ipcowQz487
8qRfbueAVGbpsYaYSnorQAu42TpU48EtBlLtCGwCH95u62mcS0+Zk9hhyeQliD0niOODOgotFCpl
irQWYAZeFBLl+shxXmLYDLIpS4+kbYQQBPDixbAAH/ZMjXZsqS+REQksqzeueWXDRyXN1ME1iZbo
xJWQlHcTCxjO0UZI87eXZPTGJDCE/Tk5+JgE3A4y8MPOitFC40ZK+tKlQo8bESPyj0ZPS1phrfi7
3diPgGUWgXAiDiAR4nsnJcfYFTvSw9uZaSSGZT0l0UAdj0gc5EBt5gDMkgFIuYB2wSKREQgxLwzM
xK8KP/j9klvh6hHxouMS6MspZgDF3QQoSpMo0ZCykzmOKSx+JdBgIeCzBXzrMPgTMexWV88KcH90
RVoY95UQISmfcjSCOKQtIijEiGFzK1WRxfnofGPJBv9yCNU3iBLk64hh3f6hYAOi75JMlHnpRC1k
Oe2caCJYPQIklH3W/16oGEiDLwNRaUeLcbErwiQJReHaLcE6uvTJ4NlITZ5ogCY58MLRak5sCRtN
5RDGgKiWLzR8xIqtJCu0TOLCjkFsaLMYlm7yqoCXzK5nAnRMRmviboxHM01iPw4sEVsT5etCdXWp
ZdHuIOVbM/WmCFGYpjVgkXaaIFCI65fnVBOYHQNabDGszm7m6Zm/CaCkg+GrGC45YnnsOuUmqxrP
Gs6HIjvsAZHEN65WrHfz4aKXs9q0W4+WslwyYsixmIiIFeBDbsS8laN7Ec3roSmZb4E9CpDQMxUI
kh6cChK5ABZaPSdbjoJYtJpRyYGOtf2EUxRAA3gx7MGG0rB7L6con3FRPaeoiHbOaBanY7xEDMND
EQ76uL1HKRzgQ1aYJpnBFbIF/rekCLmC/xoqzEHBwTW7XNRlBdAoc97AUpNlJmLzkK+G2j9HpvBz
snVG6h8bg3UiUvcbn6dPgSGA+Qazvvs2RiTh8XbLxrbM8UsqMrBMkg8OlORIB+xRQtiunVzgBJuX
06AS6eP/ba70+zZVa+on1Wdts+hM+CpBlOQz+pVdbJEb54a1mv1rSdee5gtexxEZgQgutvxk3cOA
p0kus2R82BUcG0ckVeFxqKJkQWFGkeVMBR9eK6HQ1881qoaO3E2F00v5FfV7Mrxcdz44FAJU3riW
+SEmTQv4AIAqX426h3/Ey7UJsiNsCy0Tic9ngdUM+xk208VggVleiBdIHZXixZLI+TLgW7Pd9V+r
Byjz9uqZU24mcn20c6N+Phwx7GkKFhLDvkEq7r+kS4xy+D1JJn20G0/equ9KU5CjtFbGYA8i9HKU
jezuUl9SG4wHXygzpibYN1aOqjW5SGd3+FgstJQUP/UwU8L4LCQshDdz1jYimYtmvAL7f2xECMo3
ZK2lwNQ75J9R4OYDpVwGxLRzFA7MkO2rMUuScHDZwPkZWFQ3H39K3x67pMuQtU8zst/PuTQWW4JR
74v+T78ZCsPV+tVuGvvh9WjbHE2q9KrrZ5pX+9RPcrXflaZprz4Tkf307byTzbP3Ki12niYPrLe/
MtxxmJ/w6eaVlv04qvxbJ5YyjV51BseOwZb7l7xOTHuC0yCF+H85wth0mnvZ0S5Mwh1XOuV5JuSW
OBYrY6Mz5UBhBLX6Hi55RHfehuHWjqzIdVRUZ+z9lNW6RT+TAwzcvdXeYB6WsjuP6OCre0HgOiLt
YD+8SRAX5oZVOOdkWYO0uatq0lHVqLJVdq+o0TlwfJ7n+POF7mzRh1qpxyx802iewd7fX2fS15pL
u+IIPgnwFlwEpdS/4e8Wrhc8/M2FIF8F+17pl/9c5yMvkU0+DlC7kJON+7c7yq1+qliQ/vc4bZXo
HchTCgrhdg6mY24MBJjpacpFNbJ0352PFdqZhVlwr/QRFp54tGhDjTrXzO68vhTHiWWzRnWb0oPd
sGXj5U2WVDR3ay9hqqQnYuvLuzRwQDAvGRD+BlcuIFEXcx1lnxsdsj0gdZmw/gvCbrbYuj4BYav3
Pj+onlwufRrr8/eHYKtP8HAs8uxHfk2hRoEG0uNdVs7jjHhRRe6lV//MW2/2X2r+XSobt0WlszTG
Lcrj5fFcB9J/io6WmbstgoOeTu0zCAwr3Q6EbzZlle/5+X1H7JHBDHpsDmixChoi1mVGqLpi2MtR
GkgD5cfcRMONZZMgIfxd26gmWpLOGL5ZooVeYO+qaOjZuwVVD43RVDT/v+rX/32Vsoo6YJ5/Jum7
SMVM+khZyo0t96DjOU6/1e2P09Tu6lZrJB3beg1/YJcYVrz3rIcY5kJH1YTTHNsbECrU2wlRNaMC
wgrJJaCnILvYgdTNDnUxDkfwliQa8F/a8MWdax6ovybIT8lzPQ39cm0cQnyYx241bfeA/8pFEG1Z
jm2XmOdfZMXYoCm3LFMaWj1F+VJnIKMDJopImetJx/We2jFnsqzOZT4dtde5xTwF9WKr75Yr0TOr
tWoYVIwaQjWGgnPY6Vt2M5MZKMu/FXFODGtsdEHqOceJYWfWgDbCpxFWNcD6M3Hns4nDnuxjMskp
Fx/V/0pvQryuISWrng9Co/9R9j2Bfq0IYpYS6KvqSOjHNbcEgQIfWBrZO6N+9Z3XXv4X2Z3YXBHj
3Yg9Ya0FYM4MjhptkvNOHtmNn5lDIwfq798jH7ceurPGjUzTbE9BfkzsjHrS0V/1JpYyWGlnO67x
I83JrsN/O014g7Ysk5NxuZDAj50ufEvANjUNo3ydiv/JEpFTQQrhiVs+us7v4Ba49vS/wCQkM6MZ
Vtl+1TPZ5nEiy7gQqSncUpLrjm/GOip6nzaw4oz01mQAbVu6H7glV0p2PKo3ir66d20tXbTQUhSQ
JXNJP3NR7jURF6rBzqg8F+nsvx3i9ztZQhJiCVd+Rl5GC58yAWYplIhcZK6a76Qxj6CW0o529Gvm
nuI3CbFzObFLrfdWpoz4Y1UuC+O6aO1BJuVcPRys5pfNjcn7+uVcrndycYJnt4aLYU74tTy9WBpr
zOfJu1P5fL09kKu07H4H9qVKexQhkTWkZPGyhy7qkWVX28d3SoeD4+BQJIbVI1qgkYZ4bbTpU+8m
YhN223RyTE711n35VkFYGjMm3El1+azLBIslWhOBsonvkj5Lq3lXD78UNPYb4FfIisJdVicGC2qY
ZIc15OXGCwpybID58fuCpq7LWgDREs+xdbZP39zx5PhSury2pAJ+YihV29vM1JrkPDgKkyJ2bthF
uQMXHdUfZ670H2iiU/D00ou09mo4g666dGVw8N7iGaxLMXhNd+J4AVloIYZNjIVX70IEPIlDt1VA
koGAlYRTW10Z2oSGVzOoj2KYNKApZIhFSpAEZdDzE3SjNEMMWwRHWsSwRyJaooR69qR8x9YSMlTJ
Nf0EDRoPPlnNPC4f/9lBk2PwC6dHhGgQcahlpwQPmEeFTPxRAt45s0MRNHizDkyOZmShs/F/SOSd
1QDLA96mibuJ/wEaNuebCOyNQIyGiLAs45PnlYN7FpM5QWgDpgVOWSLMdJXooBvUHQGc6qeIGORb
78fjPlZI+EkN3tlPZwni0Lxy7mc+nFJyPrZ2Jedich5UMg3cr4ycxRFx4WMg9vvaI2NLmmsc8w6o
EhmsBujlNrWcaTPklNDUHUSqTPiyOrlp7El3ksHgHFAghlU/9yAzYipxa5kY/ctZmmuE3w87xleF
nesGD6QncBa4sE6XDEIz1sbsvakHnqaoSnctEOD/XDK0L8CtaO8nm+zuwuXRu+m1bF0h1nnc5eGR
GnUq7d6Br/U1Y+Q6CRx5FzPb14Bxgqg52VJ0emhFN3NoEfC1NRXD/q3lVFQwyVB/KD8KMTnD1ZfY
JW6t0tJ6BU5m27N7yCBGKUuUh00NDt5Yy/opyF3LxtnHzU1C7TP9gmoUYfrAU7+fdmgc0x9Or51C
z0BzoI7608c5yUl+4JBu5vy0MVmI+JRkCzQx4e8J9dCAMj1rgBsz8JOMYzFBrEHWzH21JbVqL1wE
qD5HilCNZfMCbkUh2iD+qdUDFwsNPn1SjfVGaXpOVWp8KTLfpjQWdFIMyzRj1IthrXlnxDDyWSBA
cmC0L4lh0XORCFDdHhozZc+2JsNX8XwTCWzw/a+n8wGeGCaGIeUGxLCgF4SmDHgsiNFkQYusEWvn
qu+R38UwIryDAOqYK63Hpi/VFaIohDlwdNc4odnlvoOkZuVAC6fofD5kLgo/6mlo2JxRkKoXN09q
QLDtmOc4qtL+BuE+SenQeoVFz7vfQmPH+vsK8HZLLboAoFY6v7G6VqegIUlLKWgKr+q7StfvTwyL
RUlRcmVc17dV3zrUJ9OmpgQJ4fxVf9ft6o385sRvAl0RCemUrvlKZchNUXd3gNCFH1TQu3In2RD4
CWnOVP/B/LTnL9x0Pc/HrzVJGPm/IaO7ipUKmoarHyAvu4lV0yffc32FDZPWPeVXVrSDr9kSiF07
09eFm7wK3tg/tj93yOGnzraGmL2SURZr/6Rx5VOuSynfH/a1qiYIGNVgT09bOJ+QHT1wRWbIUhI8
qh1+l3flVdV7ceV/V+6euVCMifuJC0O0/JkD9sHacvtCxAGmaZrBZJqRlCe0z+LqFZr6qwDyvUcp
X62bWrTc1brIRK7evxNlRaNFORcOxuTmxEoOF1z9muKb+3osASnjlft0YlyGj+W2+cPzWaOKqTxW
p1WwIEvnEfQKKpLztO9aPIBR/dnLaZUZjP3k0VUyUT4lY+YBtm2ysbm+JeNYAbz+FqLDBxZnbuXc
u8nAfXtfBQWOd5iuz+H8sjwW0pq8sBP4peOsqnVGenqkq+HixPz3t5t2wUy3jucEVVcgvy4e65G+
+c5WCl88v3u/gcdd11mRf+tP/6HGC5n/DDZt+91lNJa6retNNBWxbxJVmv9ARfa55vIT5SyRO6O6
3OGW/SbXdx9/l0y5+1snlQT/R/iE6TKn1PlqcKn8fPfYnXL0m6a+eS2RLitICmJpakP2XuFfaVTu
jYc38wSyrUrqMIZFUQo/Qq5WR9YZfq1o/PrhwpLO4R+mESbYkK1imHvF1QpSFmoQsxodCRchw0u2
KJAk2df5SRXd8od8qypYeX+2STRJxiKfjJVs/vCBIv26UUQEyJ/rXo2lp/zQkSXfrMTfrY7uv34/
fdcDlzWkHFbhI7d1bxYd4oPY3P3Gl44qPijpphQ3Pufyo0dzXYp0Q64zAtFaYthxsv3vOcuGD8Xv
ey5JfsRzxhoFmpIh1Pl8yX14eBa+NOrya1kGxyx5JFI2lLtvt7VVwjn8mH6COnJdkvz7g0LSS/dc
rryAynfYLlog49PniIE/QeyGjge1hUBrM9kRbJU18Xg0Dzl6ENom/iEDT8sEkTqD+tN/p2pJZyvE
dCCgx6Puv7p4ofQlrkRfQARrpEkro6i4JGdO70DC6bcbdS4395WvVqx6TE0/qHw6a+lZh3MbVHeG
ba4iyiYRE+rHXeBPW6OOhB2Ynfa3X+TfvYx8lZ51eeEfi6s+fUTO3mL/nW68FdyRv1pW7sW8b/6m
Qml6X/fF7udL8Lb8VPcRK/M4UN3Wt9oWjKqjzBJ+2rE1ZWL2qr0t/e595kKaJn9YDLtWk96N92g/
vPIl9YvUUfvzo3Gc8XOczROm+jITK8rtvjU9vMdPHYtPV/Kz0ETDjs0QHDL0USJYrVZ/zWI4f4xP
GHn64ycrx9ReW+P9lQvzdk4dzk5BHxJPmF24jKx7dRqs7neNWt+2pH9m8xPK0yIZWmynVWVktRDO
shFeKulSb1+dIyqmSiUfIUtqEVL5usxr9y3qvld//ZKoBK7eVD+SE9eaCfg9Njk1qRHpDal0ACLF
oqQkTzNacWyBd1KQfBYRfYqlx49jBu8+IdOq2h+lPBz3MWBXXRehzyed4RPVlznTvdTTtL1jUGgp
lOP3XzO/7Uf6HpTUyQuv9EXRu3ADsW0Ccz7VGM0LsKfdqhtB65iXZWrtrqGpaHG6uQ46xYtWThPI
fdqWDFeBiwuIV7FQcHU5zX6XqedXu9+WCRKbGucQAs0u0XwMYtbMI/aEC37x/KydY00RueOkBD8+
IEVfnqYEK5U14My9pipVgOopAhVSqdUlHAonIZ2/fF6yRlNOUZHP7pf0nmHVDGrI+Gc99uiwbveZ
OkBYFQ2bJg2erG/OqE56c+CIAyPdF9IfdZa9dBRdS915v3QnVKIp8M1JNBmv1l6r7ftkeW4J2EN6
ZDwWeO9nVP32hhB4hIrolxj2Qzv0FLDOF8PSDyUemD+cTpsf43456Y/gM9GdcFa120jjkRtUtfCm
QaMgDP4+5h5m+WJfluPwDwt9FwHncmNuvlmH26iP5j5Hl+64le2K0ZQKu3GkkreGOfDDqADzCKWu
sYquo5BN/q1Kww38+Rb57jsL+57VKBktrWKnUcbD5iMQOYQTI0EQtQA8u9pz4YDi+IGv7UcrAgBi
7fKT3kPWMkEB8klEl9PwesUWDs6MwaxqVqcuoNUBUc537MjfUG/aIC6IqzeGquY6m2M4o4SWP17Y
+dTfZdKlP/p4UdCAiFE8ercJ9/JTZZNRWXUN6s7IyTwDR4gLrOggbFsSZpj0FFaDFe+upBO254w3
Hc48/F2QizM/wdYS1bJG7A/vu/wqKwTt7aT7ZypTuxVynDf+0lktqO/7lzKaBkmNfSflRnOTP/z+
UBDiD1DELM9VLwMSG/tLmgPMfv5NPB0mS9NkcEadCOwc75HbkYvHVHqEl1zWnHPfun/0jpi7CUr3
hv2ZG7P3gsE4HhA2gqMGcyyAgxbuFMNS5bjAbEly3V3/EoiuP3A2XNgvBDShS7csNEjHL8qWt/UP
S7zqP9SfZRqMaqkfgYi5a2AWUgz7pQ1WTigNqf/tBI8+zCTiwJHYBIxAE9oEpx+8OVyAT5jx10M9
WnNYq7jkcrpW8ycuKZeIBhdKhoJ+POzlXVCc4NT2rFasX/7kQvusloS1TwnNx3A44Ado/7h9U8/F
6ydWRYwvFCGcaTewdJ8wdJCfSNegZ3Qsjm7XOMiEfMSwszGU0WoeiNZlofXuhXRj5aFFK1a0Zh2P
8BtzDxCVm5sPv8U/XDBOZyRcpv6Z0GRRP/w281tAvJOi3+xEXTfENC/s39zqHpmuIqgLdC6UXpEk
zkiAP0a6PBABtYthCN4yQXAyCc0g0j/vekbj9nesKkxY7qPIByLY9nO8vCKH9zg+SkY5HcphInLK
ptwEZIVMdgxKs/9YAEdScdFrcUjXlxAAmczIrUqo41lmePpVrW6GfJccURETRgZz/Swunn771Awn
oS0GQnPNAey3pgkOok2DPM3vZ/GthORcMawezbYZEik3NVle6uEUcoopYpi6NNvmz1ngZTkG1HpA
3g9xedaFEImWkZgIFl9s+34objRUMTQIoaGLzmLHYCtF5Zs71xMF+ZaYvxRdCJMVF5M6bdy6Z/vp
0LRdMcS14Uv6hy7p0Oz6IgWWWrkY5nZGsXFCLyUbKRoZjH14vm3gHHC2A81D6jUnD5GXVnA5QyIe
JCWJdYUCMYxjlTSslsbtQ+TSk4r+XMhKVkUY+t3hFqXyoOlRgFpVInXQUtLqbU9Mcyzx/Req6bcq
neOOS6iuBb5IvdHEcRLDOjuO5iF6KXPAEra0ga8g+vFPDtUQJCa8dBpIWUU543D7LycY57v/mkPj
RV+qz+Qpu93wg9iT0xL83pHSJYpNPTbkfEsMCzsyDKuebe3PKDBSPN2Dj8h25LBzHNDtENPov9i8
WhLDkdBu40pWahGR2eWNwbMUY04cW7RwZT+bEMuP6e141WmcSnwx+hiXirfP6HuZa/xcF6gSAJTK
h9ER/rLwqM12kqEwGo0ZX7uSYpas1WwRv/PEkt3XYlwLWuOSV5fd8L6t6cGLB9Uv3bJURueKKgAi
tE9m/U34HPLzEeHpi0UDnG0vD4thXnb+KGH5/UsLI+lPW3Ava/TbCWtMwwtAbtmB7FkBL5WhSRUg
s9tb0uk9wor51P3FMbV99SpA9FzBVPex6HMd/mA9EF5Byv6aa9ioZbntFENDyz37GPLZ2z2fmgf2
Xm8yXe5p71gNJ363HV8LvBmxy0F6Rl3FuE3zyIx7KNutfN71W2GVBTqSbnbISPqddnmgE5FYcD60
R+6Jb0fu6XDriw7mBrhTWWc5KE7nJhL8t0qlcov8Z6wnjkt43hS7UKelpB3v8fbC1GfWiNwEy5ix
eXOgc4DDFcy5S3YW1WQRJvPdRdHnjyc+olsigqYwEsuJ+5UcxfhiemuolFOhHjgJljTpuHnMRNY/
exDlGWRCdLKsuNXN6l7bZXvu2Ry3WOG+vp3ZybsTIwORWsfe2KqHnvldpGzoib7x7F25c+Q2RoGG
xYa7ZxMaAk11HMIQ7/9uLt3dk0q40/luoNiKsBBwQ5vUtmc0I85Sp6pJK5mh1n32sk/O9yyRzZi/
zrd+Q3XjhRtnrb/4DBpJKT8wOmR9+rrNtUg5q9sj30Wr6wnNQb4KFbgrZQaveGU/Y8pUh6X+rnlS
F28tf5pGejO6XT71na5tzZm7+8s3Ym3Vbxz7vpmr8uhjWVH6vxU/czL89juHTW0dw+mItgwbJm9g
9KgNfUgTw/YM5NSd6v3PpDqsQ2syYveTznOf/zY/LdVxnx9EFpEyhHDwfjFB1Bq8jJNv8jjz/oTq
AZXBpq05pvvfkmX2XPhYQb3z4Wupihkdc/NNQk3kTCPjeJJo62ca2WpA4WZd5HY8egUnhnmal/xi
rEmcSW0G59qv5Lx8TXCOcqktuCqz3rDDK4GgJ+Vp2ma+XefSmRsSlZNfQmcUSswS6+wsJKyyJch5
1rFQ9xXGA3SrEcgbkyAPJmn0JSJ5dNwduVm78jUrn9bfkhGDfYSeMiILdb72+H0aYD40bWJP0tki
tmhl/nbBwy9P2pNfeeLUI1R7zjAUU1hjL6AjZ8ot/WU9VMO4SrlgOcT+XeG+3yWGSunz5Kp72jcl
WxC0MaAuaXz5W9nmbyXDtwr8JfGMARzKAISPi8Wwr51+DNa0aOFz4IAyYyI3K4hR7rO8ZAWf7Pg+
EI0TWXdzgiAGm22/OjJ43b/UInxFVHOJMoDNyJXs2X/28aSZ2Fsz9FkseJh2wYtyQkSjQCINU4Bj
LYbtuiEQJsuoK1iGPbOMEsP8Mi3ybwYHTUKrrujtKm6UTv59c8dRPkqQKxqtPm5ApUlH9K5IlE4v
rf5cDenrCyQq+nwya/PrGpd7BECUAclgwHv7jRdNHp4+mSP7NO2CC5qtMOlQtJyVcZdHwH4Rw5Zq
JfrXUWlpy8EYDg/RfyaLir3DpggqLLCfLiSEV1Em4TzpSXWqHEVLK44HzwbabXpYtpKicF6bCWnd
8iKHsuAcW/hVYqgiqiRNSKzf+RuhETzEuc5vayK77X2QOozApUNO3YRoLZUKljG06rH2RAyb8QzD
QVE63vCHGEtRcyyiPG/Hdi9DEJ/twK2uHNgVi2Fe0tD/gnUb4DDB0Xg01Cq3/guzLhXmrkLI05hN
1kWoGFricQwB0H4dOtKXdOkaiMroJ08pqm4FL+GwPkbouRt1Ylhk03jotCbmypiCQA/Y8Yc7U54q
NuJAw35J/N8pLzHCSJu17AC7baFiWMRkZ1bd83I/aZmwBaeYasVcpLqJUdYtI9+aXEcx7KWoChR2
oTA6XmuFuZi1NSdgEvGjHLFX1CkthsnfhrrvM9NQv3KzompBHd8ry1gqnhEZlNot/Wcu3nckVWJ/
v2QA0b/VtRvYoE43Pw4t+qsy7dgqAX90K+fNC2fDendRUhyH9ecSHs5ezvuexaIye8aZOmg1Pe5F
E03G8UE3VbhtfdqADafDGH3WhQ4S9PpteiBJjTciuMC9h2yz/B6DCAuahoRsn+vZVP/OZjSBJr0J
5LZ2WncDW+IOUpjfYhjog1nffa81JSdH+bkoVwbF6YiVkLe6GCbKODHHhi8fiTcM1o3ywnX4DHK6
+GSwkbY02THSROTnssZ9p2kCGJJ6o5bURpsGactyPCTv+azJzBEXrzjfCYNYGo0shr2zf/NSRFuL
JHSxQvf96yBjO8ZKbEGEonqBaBCr9atB9eKWXSs1zlpCnV/SZ8mXP2w5vS/yu2kwR9h/qt+Zfbwq
3S1912nTe1zDO0GuMQSdG8VHVcWwZxqRUjUZERGbho0J+Hi2naN6xyCeX36CxnawKTAJ2fL+pKLx
YAZsb5teeBXK4DM9c7qQq1+bJRlsyOLaJ0Do65haMUz5pMUJeo18U++WLJZnoZ2ZenEC4syrRwTU
vdbtrW5xgzXye0zv7JMUgu+ypJBdnEcrXlf5NpMI82uimWc0IkWIWAKHbd+8QqyuhLwSw2qbf+Ya
v86+Zh7EOERTHoPkRFvqV5juFa2KzmHdpPHev+Z9/K96ffrYwAce6Z7JOZHliTreZr230SjCXw2f
TFPyutTUJYEr4Y54EzFMKQW6ufXNVR9OaS7jy6PSgbFS1ImlXg+FU0RaOj8ciGrdu3cSP4ncoy5k
4Lx3ZoAlrXcDNt5/4PmTMfSq7XqJCBOekzS+Kvwv8lVr9KfEkztu5+EzC/KHTN9U7nlUi/wtW2ke
3jg0NB9TgD7urNkavNhUuej33nGqW6kMLZihcQeE67YhE+qhLxvrcphyRDKI7bclBXy/tzZEtEwO
haF1B/jVTS2m6m9dqZZ8vTjWPi1uLIA3HBoWyr/3y4zgmmlOXut+JhlNam3ypaDFzRFtfK5SspOu
fmgMURE4p4P65VBHjW3Vs/M8/zjy9D9u+1uMJDo4QlXMhy+tTXO6WpxeF22tMPngrBuvd6Xuq2EV
88nHy/+oFmJujCmY7f+kUiFcg8eoSEbHA3ulLK1PsYq3MOyIWsvm9nOTC//2yOgO6BHT5f454UDp
R0w0O3IGZX/klcrdaPA9PhK/byvEJ7p1Fad9Fj182Vn/8SKrxVMumws0icq1t919+tOZk7EtsZ+z
8d4p8lhWgxhGJnBu+80cp8cEBX5/lENN0M5ZoJfgOBQPigRDsbeatvOIFmOQg+gepLm2e1/pcofH
ri8JpsHtFhYyOSxs4pEgG5HzJk4Wn8CMJXn664bz9F6+11S06hw0yxAQ2hsk6STpxICV68fh6qGb
QXMo1y3f8zcH3kffSg4wPndajmmtjNlC7H+qy+EFSmS5nPRZK+3S9j3bdY7xxnYEt42bBRSboMuN
/839MyWSDF+rODV02KVZ/wdBy0wivV5lEKG2+easjOydYIbN0OcYtHzmydjN98bXvTQ33XFZQl/y
YWexRhMTz6IDgGPBTENOTC0Ptzd3cawxuJ6wygP6nh91lzvfkoxPdX2afeSpeeDf6qmt+F0vdrww
dHWN3bw/4M2YejW62K2+ZHrEN+fX85kWN/MboPHba7uf0wUpKTPFFudqfAeKuk/s6N+zF/jHTqvw
U5T5djGs6WEVkodqGvVMKkyUuwf8pC2rlIaWVjyHLFt76FwhvMv5/LZMxF6mxSfHAVHjjVLlxPwk
OdFvVbRtw1N/HfhURWzmqH65FtQ7pkw8/65JNFJ/yaSlKePPDBBDG+hzBi6GUO3blHQ+RHcHodhk
LwkYOmCpuXZBR/2jb9btJLOMthEQE5v5ejBeI0OX2fyxIn2CGBTe+mPcoeQ/jbfP3il8zQ0HHjYU
4V7QFKMTTbi6TDLhh45r6tFH6o+/Y6inqOtDHUn3X0b2b3ckrzW4rKdn5hD7b8bSqB6NbAT/dmSS
hG0k0nddcCZaU3Q6FmAOP8syaU9WSu+5BAwsixbMr1x3CK1QPEhBOsrqJyoJCPFrcW7YvvmxSpnY
gqsYSV2vWFhct/atq/RtdQH4ARchqsO3w62LxzV25hnQnn6dOyuGEe0pfOQFpsdr00ezKUxAg8aT
inMesvreq/GLO9bQknoz+EsfjVKVhX11Q2GSK8k/7TI8in61tZmeSmzBaYmq8XNFmDWpu/on3Gum
CXMDIZL4hleVvsVeh9w9/arhtdfTdTnbJbivV3wxwKlaDBtTJi3EnKFP0Sjmp4T1jRKb+LO+nDk+
QPP9de1+vQy1XEIk9GfWcfk9I89vfgUJHyZOFyRc0S1JLNM5rOK4UNhy4GKi5aqqTbVdA5pi92zd
/tdHlq57xu185DTbbtLg7mqJtfzfyS2ltTdyfhU++UC+bdJ/Mq2AkT91crX4qmGp37v3qjFDeRlx
iD0B+7oZl3MLUBJS2QDxSANBewBKDf/LuIFj4yShP/qeZKToDtNF4/DXhj+Y6sX5V+pqFkYbnmWp
XJzJ+pyqyO1NAwak0SDdf6yzuvtEQVrKZ9FMYhqpB32wKPGp1M2Jqci48AGKRGU198m9OUG1Raxv
tjM72qb/E2wYVfzvc8LRmg2c71ijI1knYR/7wyDZhyRZR7oPA9BK4SMvy8vKVkvyHZFG70IRGAIX
aKPFdQR4b9elStnK+wr+BaoEFta3A7ak2jJS/OD3aWGH7XUOC5Lhmim+zBw4Zp3uOtW64bt/q4Vw
per7J6a0cFUgGdu/bAVLLJQXh5GUZskaHdj+rnWwdnBS+Jpu5oKGiG6HPUew5KZcNLE4KFGEkYz8
FBuIsOHL3NaI12s6G7ij11ckYrX7HnzSPk2CA6TTtQx19iuqJ0sQYevAe4lA5KLzZHskvXkTsoOY
GohFiMKQO5O6BRN7P/fHcwowwK/YrqbR2WH1REhjjVttuuOnm9br5JlMJ/wIrL65crhsbD3ltY2q
eoWmGNZw43v8qmiwKATtGS6jIyk0eG8hOFoQo1f9oP+NSA/4ALArcKpvB1+V2PD7+dDqPdIr2l1c
ApufEnq5NpMQHfQFkfPcZlgIFz432bhLWguedaCJzUNq1rkSGXHMiW6+GDa5PsqUZPIZdIAk/gcU
DmoYdEVX9dfJERPDx0BCVGH61GOJYcOFr/bILaUL3H0zQWm6Pzw+7HornkxxvuxyrZ3DLMQ6llpm
XvwR7NT+oSFAaoqc1NqDjeOqO2Hft7dI+u++VzqaSsKWFkrY/uBtMczH8A+3IXa6Ap1fqJRZ8sEb
1ZIujc1ijU1h2iXPSoP3ZwSXIkhMbjUjZS3Om2xX0tiSKAoMwnewFtiMiFF960w9uYXDsUQ5EItA
YB/6YXcn0kX5CHYQJJNvGfq6IR5UGshgRIZEIqiQDNa7FOngDz1H6ycQuMSwIGSaCHNrWEhIvydV
N21iuWasIy1IRw2JaHz7FN+VGPdfybLeS1pM0UL/n7VorSixf1a/NeXqD/AgPnTZPePunSzoZHPO
HJpVhauhzQiAhJbLEUsH9eNuvug/hncKb6LgCW2/Q4C966D96Q9pqq+M0ozS0csNdhPaFHc//a9v
8X65YKVy7+jKTaob8brcelOyOlF4qWnciFf0fjk89ZyZdkhtHj0SoFGEwNKIGDYwsLLh44csvPC1
NVoPiuzGh51av2HewE/UpJC5aIqItBgjV78QjcsFsk+taPbStGIlnRgQ5ksSQidFc/3g2J+lUdud
Q4Ct4MxZRjI02fStwXBiXnlaOM9EVyga+CfMSWgu/3Usdvh+jTWp+s196r5unE5dCP53dqqUeRL0
IArYrXHr/pJWvwNzb16+L+ji98AnlWfE0MIt10b9RkmbYRMtJlhlQep8wi18Re3TRoW7UTivym7e
k6S9Kx6Vk3qnu8GCls9fs/b1GibK954XrCHPRpyxgDy3GzCYND0QO7aW2au0srkvy6WtauUJpLa3
3SogkXG15LxE+je4EbrNJ6nws0f0Drdm1MTMtkhoaPjq3yL/99XQwEsLnCiPHDCsb7bLxqC6Dh59
/PFWNQM3gubsaN6J7CDNmMt7+7NRCulI0ReBny3zsFbacJgT820rLvlUainYh8epK2dHRvrHKSUf
DVJin5C7X+1U8FDVPA1+z2IpFX+qjwx/ir1HvD3WrxgdMzZMjunIvuz8xo6wLCdq1E9WvR0wrSwY
8stosdJgi3IqGjkEZRP0mlSY88+NBf4LGHiWAjN9Lae+FAca5bh+1W8BfqOMJBCkutPCaUaAYpHg
fK9JSMo857e5sZ928+NAKnJCSAB1IsF36l2GHSeTcU/nG2YV46EWlgBg56Tdr3FgZCvJxu9WZi+6
WT4OGvvWu0aU0T5ntsP0SDCu3XKG/FWjEdRs6Ez9lKSiPGDEth3DBJ/at1HzRn391BNwCGWQTUKe
/2J6Ajtodvd4fuKh9C1c79SmLjzdkscTw6JyJhzO3XUzyuKbhzWI8kA/I7y1beQHPjg66uRUm1Vq
GdpsdpH5VJMPT8DsfqF+h23AbpTk77ovQ9N+s801IfsjOfCedlLJ3X8fo6kEtoOdd6FJgKiWAVQ8
VPoz6X5Bd4wDeCsCIZLQ98M2ZEP87k4BmaEnWnVeruZdtJRIhZ0/k3kwxATfl2wJLuDVwzJPqwkJ
qxhfBMjIOXiOGUR02RkmQDLb8ahpJ8KOuCTP471qVbpLII0J4N1isVVWZSdNLG9E1G09GzSwKZeH
o5DtnI9aruiEM7aJYc2EjH/IhlFvhWW8uqWtO3pUxDDZkaRgvTSbOdLopC4maCrSo5IyH87cIBv8
wJJkaPrzey+GVmlPYg61BbNo6ez+QMDXxQg5PUC1Q6bfGpx5oJDaxL47PywiNeVMZSrVVAy1/erG
sdr7Q8ed82ZD37xIdTl4VZSr+abrrKyQsKxSqDcZdmZXitrfoPX+1+tTSfyCrYutBRfbFIW8JZOG
sTbnTVrmuP4X5UsnXndIA5g++y90crL/uQTrtYffP6zsjDRmtiNA7Bs06mFIQy1YmEDL/VSXmlct
dE2Oo3tJaKFPLajDHhwM1/nbS7YyLqbptRzdbnefHznNWkXUkQ8AnHz5qrVAT29BfL9QFY9SPWSo
gVD62Yzql9CS9lK8KLh6twFJE6dhVScadsLte3QPoOewIBW3/+7xbab25ocq09g6ByhUsz2TPqFy
fBfWKGZp0Q/9w1L7BqZLDIsZpp7OkZ16nx5EW9sJhNemr4th247Wlrm94iR15sLxrZhA/pHJFh4O
a6b85v2HoMP2kgOwMJxHJpAqeVo6ReZzTCoRR/wqsMfY6Lo1EJrNY7PDOIvnFm2bby6l/lkV8K9q
CtX2Ki3ZwHQxL58WGY5O0xHDLtm/4R0y6LG28BCe5MylM8BRE9D+x82hPrZCPZPSih3uTe5SNjP4
NnSLyADqCZ/t2Nq/amrSNFtUP6QBDfg1nG07pLn4Cit7NNhd1vcAifVEDKOWUJHSDq+5FBqIrfQP
zCzhQtnXueYiiZKWhHmRi9KuQv017LOE5wRSlUAbGOcCqaY/knQTVBVuFySgTHfmhOR4X4isNGzw
GWLaBTtsnpB6JOW0N2EI8tIOENUbzBREp+Z8456JsOpnqErPNnM3q9nIh1XABlsTH94ctrhi/GG1
G+ndxc4PHWrgW7MK6I51DEYjWv8qUPZFoSVV0c6tEizjawq329fxHULLuzbXPv4dKd8U39+aJJwM
j2FKeqpUDNMoFsOCwII6otPC8PxcjFw0SzSKzoI23wgLP4DeoeV065Z/i86xLkcKfuU4/VenJMUn
1/4uUI9iqAIND/VrWUzEn+VbQ/yvGjTm9egxJZ/uDRW4EdjdshKGQo4cj7ACTfEHUVlHpioI63so
2NJliGbRNnZAdsJgsEXWA7feTpZAgPOQ9iWUSaf0yxvwMGR9P712JRCuAuBdOAN8oA2Er23TXOz7
2DrOZr3jFGfxAYrjT4RoAzKB0vv3ffM4JoQiMB3e6j4bH4sg+GObHvU+tkTxYjGhESvM2ouvYJ8a
0nAumX7+rRRe1qGXZPP6C8CYZpZskBgWHTIyRuqaxoMmpJhsXSaNLhFQfAOLySvXTjL+YaimroZi
5JsZOLVlRAIUAeFJQF36zWGdvDgSxRDRXE8514m3KjESZNFFASa8U/2ikD/z8VvfMN7N6GbdAvcB
Wvz8AL1X7yUIV+yV5MN9oxvnhm/DUnAidrtL1JeU2EuRICrmSbrEVo3IWAP0DNlt83j82JCpWvVb
rF9bI9epSfROQl/S/IqoUEBvVQwrygzWJUHFqG1PlETj1ImVL2LYugz2enSlG22A93ziqxjGqqGB
c6xx15zA8H0Dx7aj56q/0HTnHYJorJr1Uah7SAzD6TZuS+Rp6jEQFG2C0EJ6zIC/2qswEBTmgp+W
yw+lv9DsrfxzkIkOWxN00Oqe/h12CHUgVJoCsaeqd3v0Cgq1njHjeutRFBRdSGCjqlHKsrLMEw6g
mksWHZ0aAazYFv3GQJt7L99SHrBtGfbhMsleGCpJEmje2QBNGqOlKEna4kJ4OiJXCNrj4iWwHUS+
TjceJBp8cVKwFwA/7KQTUTO4Mc3D2pzxfoEd8LQQcvtsyXqQpiP7Cpc2iuCfa5pD8MoNJuGTmeOQ
UxAFcmHbATO1Ru3D1fAheOjeVJ62N2c0okrymSm3yVY7j9llFgZ7H0o1pOHT2aoqTWxw3v9kc3Tk
kB9kJs1wXhRKBwTynBt6dmlpWwnzvZDkOASvovaJ+hDEY+klHxYNw/sqsUhC1rdjH7wIz7Bb8cnc
P7SXwuqt+0IANYbNomtpNKDGWzRHJR/zJ4iYCdjKyuslFhHeaDRdkNs0dU5YQeMPEG/fT7u0E/H7
vg0/0XxJDCN/FsNmbybm3WIsbJtO982SmxL8WXiyofT+UzHsVlO0oztcHpH9068A9Qcy3UajZqik
zzeaAA1d7k8Bob215j76CuieHVxWf2q9/zmeARKi6dUX4M/ZwAuMBO56bkYD+5G6OM2wQ7R2bw6Z
LulbPLbDuTqs0pXaGpkbZ0/Betq50Vi1RDfjB29dXANCTc4Zr3xE8Z6krP1ZzvSS/XvzZ4r+J5uS
zZ1mLKdQE5IoQyWbp68B45ptTl9ptAEA7OnwQWSxKiSDXQcNxkEB236P+0H90uvFnMIpwrKS2+jY
QmYTxqc9fqmJ6hpep29gXZuTBFH/rMARVRRv0jT023x7IQ6bO5DS3+LPY5MkijRBkAQjn2TLZLjk
l3DF7BjEs2P2edVu8/AVZl0EEKWDFu1IB53nmAik4AB6ndEsSZ9xzHupfpn2uPVkMWz1tvELPCE+
AtTJKCKTkBdFbdHwYEVCOIYwYELjE35PGfGUhO03Ikhd1GLFkD5iB7z1awVmfbcjcACpieL5pOrX
rtNPsEGmQ5j//dIlGhnu7XK/0LF4sknKTrJPMoO5Zo24h+xvT/VE3xbv/0RQjaCRDH0MHpo33ox5
jr1kGtNMulzJEQ4a0zTBUaXahDBZB7W0O7qyLA09oMElxyjpsbtc2oypfI6TAopMWKEQKCX3Lc0e
WsBvd2zf+Y2gKA80t43q+LSzBeHyjIwZP6zJ/oX95eE/+zYYOY7HXFbrOZTpfdMq5Hndv6oG1G/U
WHPL4F2nT1FvIjgDIQ5GATVq8kdq7M/J+DzJg48+GRBQrpf++R4sWGjdFH+0bC3e9pX58c8l3leP
4T0NfXZONo2so595N4CXiBf7efd5n6r3sqVFmEsglryGu/6Q8/X1HaPMsy+/XvJ438iUkT1+Ubc5
QTkgMSAeReTGEIKzQGyejl//RpLm0hsrQp5SxkeBT2wfJhLpggqBxkzu0+Ftbsm6qqqa/HAs+n6o
uXFTc3uqp0ApQYcrHQGOEC/5KY2z9nVLZ3Z4quhRnEdtcJoEHrAsF/Ha4R92mHnlxIzZJuRLUafp
qIMYdrysRrMmaEjnNYsDsXv/rIz2IQC4/VD2eSA8bEdDD5akmXnGAAk8C3yXtLIJmSgbKAAG+q3Q
Is31l3DR+2+4FeXiXXGuKDnKJFQCbxHR8Fb+wa6xlfwrSbSYJ2A5tVWkdTMhrPW/K7n2g04KEvGx
h3jsdvt7T97j6vIPpWhFolpSaD7rwLZDAoSTKE0+hH9QlJF/Ps4Wnf0KaBiqLyVk/lunFWQ4Rfyz
GjLbXmhOj592SnHwBrHO/agaHaKXrRsh3FKik+lgYzU/83b87RdtaDUVuq7EjX3RIN4BWq95eElz
zVS9034cfk4IGYLAypjAuS5oqaOX5vdCLTUS08WP0BQ2eNckn5EhmyfPd54O2v7PpnjiXTFsYrjp
YUt6ZGSNv8+RUoHzuMg80kqXxndBWbkBtwfWuwINxLCc0+Q5iMNCZLbvuBQ+cm/y7w4RvXuybWQK
EwbEM6p2InZZoNG7hsw2+Z9x129fAiaLezu/BQbgoMChRsJiClsP5Q3ws1iDGpVh+u+/MqFSkbtU
eK1wK2v8RusuVeWytf3bjgT6CDKAHzruXONEZvigkLCghweiIUGpkDB++thac6QXV47tcPUwDlDz
0E1fk+h/ZYqkQCPCSd78+I6BffmHp6qFOsW7/7M41i+8hsJEMBCZec/8GooH0rcLOpyZ7y4kxWX0
+OuezDn5Bu32qfXXl9GNQ694+9ZPF9TByiRMY0+7kZn61PhMqY/qkVLmrhtsEZW26Fz21ybEHRXV
/roP9+dt3gocJuyTuL8PPn9UjdYqc55jvPfNZRCjZvCqiWFTwyeaf5Lq703OBrQUko9uCGW6aE4X
C4smGKSxW3VBsrFn9hRWaEy5mj+Zd7OVtuc7UA0zp10YqF6aKqpcQ9ak5WeIxhi5xWGjaGro+gWF
GQsfjU3s7qpgMcyuBPhkVf54gnodaN8x7hJbPD/0r8/Tg8KTCaXcEtdfdbKhh86Sv+pjWnVZFJGI
4h/9NnjnjFkhtWRsStJD3oQvlUkhBhHOJo/mxbDJoBrq5Y1E3QR5O8szbb96K7XgYGcM9kGR//1M
x5LHd1Rjf5feLczNsn1QdC4yRDUqoVpHhP041UVgU5DHL/fP1nUmJOIZPojVAIffxEuqSdfoGfCI
47UrmkQCuKqy8cLhfDVhSXy7LzxWEipp7cNd5U15MU3+cXZ3j0yQO9g9t5G6cN+HpO0eL6gCTJiC
XKioFm/+apdJ+6tlL0+Me0YhKjoymKAiFyKGDWhXRjiHdHkf6juMOEe3DbyCB9rliG5KBdd5qOv8
f6GfPXaOI5rpLXVcIN1hW7rWrgXpMwfYRiLSEoj5pIrpyKOpCnUWsg7bzwANwqcKaKgWcmZxuISw
yK7+Ruvswl8rwl4aVeIoFdH7jx99Op5G6sYC7ExBRSHyIGdSkITyP31i1TPMBHHmz+rrDa4jpXPI
OZ9K61+jp3rEMP9wHGh3dPQU19qSFVMJMS8ZP2LqDZpIeEXjz71DbHtKBAMRqk0TTAiiiTKQjt98
Enz8V7c8uFk6jLyiYtq8Vef4Zf/nacVmt8+Ua9189XyjDc72QulG89uKFAuqf0tRachzvcGOAu0d
wR5qhQ539Z5pk2l7Hf2H1HtdnSqZ3pN03YWZj9VljfcJ9R00tQGulrxxpYhUgw4BeL+OKg5vr9yO
UsOE6KHXdp/E5iF8M8ntp99L9WjTlYszx+4TxoyJ1t2eIQA9HbKtUQ5cM7dtHMRuYwfFzHFwqGR1
QmezAGcnhq2ZeTSMQpQ7aaisEOIxfJw30M4PkDUZLB7VaMOsBggtRaTXv6TlxbAlUz0t4JdOKQHE
CF+9SspauZxR3D4zYRQ8555UL2DybeBhqvm4tM7PIb4JDnmEkXpcbz4+q92f8DS5x9A9/BehTaJi
Gx3rSDci/qsGCe2GLRhRu5zw1aCswaEx+e8senOaplZYY6omqCaGdVn7kVYGsXAsk2vgtD9LlAU1
Uk6ZNeZ/m+Gw/AuTj+qinsf9WUul8hr/k4low2+2rilbGnIW0SHeQqU55c+cuGVNxqnXiitKRTL3
xjJTzcH5THt/nhAP4JuqSl8EFrU+5EVHQqOboh0Cal/RKBTXUWq+R2qaUvafMwbqgV3TFq2uWTY3
YkT4zG1/voM4qncmmgMRsigwMexxDolz5h0h2YerxLV7S24B2BUNYT+31Wjezf0qGnIRYdArEt2e
qdQzXCYvXGKktjXvb5KkCiQ2SF/2gHu3zJTe5KRT2xdQDNNcrl0e4oto8espEsLB3VCZup8wqF2u
DZr6kBU7ArTJwAqlkanVSfLJ81dUDQhutVz3w0cwyUbjT5nwBuX2J4zE3qwecjCOT2Aqk6r3Pj0Q
8Jq5v8jfWVNPAqKZ5hxWMUgD1kG4ryB2qPeiTyHKt7w7+pwpZJuPrIoGeMjETpk05DjXTT4yQDWI
7CwT/kB6ndid6sGN+5bvQPWlNOXWrHkvKXd1zCt4TxGoJOyx9NlSYcGFuvGcBcsED/B6/6yw2pcX
SwB1Qss99WgkqiuwKAtiawNKHN1MDLqz9V/jImv5ekB4+oSbeYfsilJTutRSiEvPOYoGLSNDovE0
OxezsR9DQUHKjrPos+G1/Xz7Wj/3o41twxphO1sUTWdQlZLR9svCqUlGj+zdPAkV7GWJGL/JztHC
FTFsK3RDTph6qPXFAbfuYHrs2BQZSMirXuipMPgd38OHVNqB6RTl0144X8Gs46w9tAVZWukfTopg
Cb9wHdhBkCYf6bs3FGzr2kddSHV1cnFR0WNJBy0MDcVYoAKKzIqnritUmg606pL5FbU8tX3z3yk3
B1rDpjAUBA95WcvEfKKmRi4iYwsN78DmWk5Dy4QsMUxJ3W9dKGNQwN//CTI3oUe6EOJFC05YPCpl
d5taqrkKUeUrObsD+c67SISzMvebFZGDBARKEQH7kGrn6CaGtUokq5j9P4vA/c9qdCdzHaAzjblM
C3SAombwX5/IRVMVEh1ACxXHxmW8M4q72pLHECGWWkFsnhMyubaI7N/TEC0ArQiTsTRKwbjZI/Cs
Bkt/gNZQFR23sATxx7II4ED09J81aZnGjrgV3Z6gkhz4hRoDBC/O+V3JAs1jpLCdQxjtwRPBxlb3
V1nloYq5bfgwyp87bJ0j30rg3jb3c+GjLLgQW2jw6/Cqm89Oijlz2dDT81R23eKVtYoL8nknDmuq
eIaz8Y58e93yey87WYQ2Dq0PkhlKN8RaNpa47doJ1XUsjnT1GG4PbDMJQBXnajaY3hfDnBiaK8AH
/1bLZ/LvG9sa0w5nytaQoR8VOUEZ6LCAUK0e7jXCgkS1KuIyiruBgHtiGGdIHR+Hziy/UN0qiU1K
UomZ7n8njy1svyn7A2fvOKOe0g6N6s45P/03tfugoio8lw/FiGHtTqef78oNkugfpTIr037586HE
17PpkJOOeUZ33S8ZdNLfI0FNPTuv1S50tVxuVUfef605ae3389uHngfdPaeo8+7epc9/z8u3eO8+
onB5vDrq4qK9c362/I9a1usf+XiT4kvRVVaBM0vCq8efYpRScb4idk41IWgMsbbbrnHsHZaQwzJH
630zduvwoeAJP3Q2XaPMfjZSTMKvAU/8feseXjZfAiGLkWjamjReDEt75NFRLZ0dGFM4S+74kduB
BheKRrCe5e6RFfnWEhPVbNOzc7vVe+lS95Mtns6hJG0XRUS25YoVSl30o2XKCfnvvH11sD4wr2X8
rp4WdkUQzFmtko319sh0otLkwya2MJsRIANT6pJ07ZtP3mu1Y4wGb3Le2102DWLYySwU66ffnAki
7dqtCCEZwPORVTYuTrQu7dNldX/WbypnejSFkZ9GAk9UMgt3nXWNmyuFHl13cbyJjT1nGfSym14V
oGBAayPnQhsdglavRqN8g+oCD/dg49Dtjrz36LtuxzHxLNaOCpUVftJZ2YvGpTpLqW+bDHzTZ7Vz
IYQmSA4ft84MVm9+dPSmvXu8B8lnzXt7+tAtpsv16ptFYGrsrY12rbk3c9ZJM5oXVdObhWQDjI5n
R0Pis1nHONMZzthlGqgT7n6u0Un9wL8G98m1oM6Hz97qs088i1paD7lldR6YehMZbcCC/9B5d6KB
4SyLOMXuYWgFQSpdFifYIUJCVOOdoSDPrxJQL2AcNPEtRp0l/Yih2gUlzAnhyJV9LiB20Hbk79MF
CZ1//VmJVWW3Mins0PejMhnzj07bqC46tcb2vw7l/sf+sAWnibKnXzHAEil+NceWNqVYue0LmKw2
qytHl75W0uqu9ySnOnEdXcth18j6/UsEKvLb4Yh/33zhaFzud0M5ODz8SdxzHtpyE2p84lFTpKGR
mK3wk0O2C1O/Fl3Y9kn+Dt5hl7EuOJdAQu+33NfHe9kqGsY9WrPxHtX2f2ecM2aayr8b339Fa9P9
/PX9sij7zNNtxeGKYthPQnily/1PEM3A47kj/3x/kGXpLwd7olrEw8u00H5XGQkGPQ4Out2md5iL
gn7W+I2/PSTbFXHJ2xj3oLO6pZ6gN096i1sxmXTLRt3ZMB6gkikVq38eMsP0cJOZ+JBtVe0mVzOl
BfJ39i7/GGSHyxz+2dmjnVkzVtk0LnK9SkZdPfVcn1zcer/7dXUzsKJjt7S7MZHRqdjtyLXPNUnw
V49DaN6zUK1IyaIXZjz59LNT2c/zgTRxO/xNGyDlT0amD+we+fdTam5aib0kJ7DGlL7kG3zjvNof
eavt0ZvKWBXGqx1FQd1BnMqBFbvhQcfnWm+bxzXa2pcSeY/2ZswBDa6xqz833V8hxjKg1XC9pjpW
dFh3bwo4wFd92TJcFIMj0mch7ppfmbTW9Ai8gc7VDbp7YlSSyMLufg1VkHNelDAj8yNOIB2Ymilx
skyMJt++3P+ivvQed8tWqu+rP8tMRb3PMCj+7Cln0Q4NNB9k0nBYi8OV9NyULH6EXCTyMU0x6bZM
luoh32ozq2ozp0PK/qe1p77fbvzh/3joXZG62eGiso+lCUUnjQyyzXM83i+ceXX77JdXNlq3Dm34
u6Ze7nfK7m4ZJuX45yYK7bNrgYN5qfMirgnjj40XyWhmFImGNInQKmLi5WHh2ZMPu62VhvTIYPUS
IVqUU+4P7Ckt+zNXPHV/uJCgwbYYfa5d08+VeYx1MCV+zT2eXH25rfVK0s24e6F6RKh7eRQvS76d
87e/55+55ATw4g/c8IPyoB9RBk+C/eemjOuvJfFGgbbKVk1+pTGPN2y2EqOnJ6ufohrEbseFjGP8
+NJxSBLJpbovDUc8QaHpOI7BGyEynVq7btLb4fznPBFOX3AaJIhweCIrRUCoFW5b0tDxxZqP5wRo
NjQGvuw+PJbNF8NWdJ4UIFOdycjT83v7JfsuROhBl20Rny9WndUeus6P+x3n0VAKfm1Xlc/Sh2gc
zpMOubZF4ZmyyTjO2PzPFIlj+Nuni+xnES3OZjWlGO9dWfsFifr1bZVQhfoip1a4pZmpZ9g+MpPj
F0PQ2P2OZCYlzShHC+FAqTretIzmL4bZ0PWyCSJKo0hScxQIAY3sIViPBGqoaUxz33FdWDgiSGoo
ppH05S5TWo2/ywtCTCvIWaKcH7W/c9s10aQYrIRcM+N8GAh+1hrSJfYvaIHMlMMnK4P5AUtc+BS0
eowr2U8OWnRq3ej4ibyaojPB3js/n1isvSBjgVdFotA3Y41JsollzjpJ2cUpLDT50zjG5VcWf8+i
zJ+lbGOwHoufo/Ly+nRrDwu8wXxEf2sWoUcuYp2+sWBUoyB6Z22jO9mUGiXKP11EA2tFmUXQxHvc
fWhAO84hownBjqU1V7qOjj9Zlb1/Av078rDmauUhPAnOL1dY7gc/pKNxKX1uPQfNwHExLOxMtBhG
FBLWLaGbWi5mo29TD8hdlEWr0EuclNDpAXp/JrAi3QD7pvZ2XLJsERnNr5Fm4cCM3kn/eiqluKDx
36/92JgxEr6DRXLzNG8ZZLkP/fTNlqOSuep7igRn4ltRSD1ezgtzOm7SzsmuEBLDRDqSMZU4gZIT
naBCY5dsERlxqG80JtA42svAeS1jF+SFyw2N7ujMam4gxKeUg/BxzoPvfq1JafeRvE8BzZ6ZxgIF
NGvMNz7sWSOuOYkXx4ecgb1EO23CLiryH22q1z9fCF2qf2a0xFSfk9s71ROtVLI2ZgqhszvcCEtC
bJwYBv/IA3iDv/XYq4mol0URZlrmIWnEU0Iu2dFAsTVhQTD71CvbhTXi0CpFefiJzTWBr5cgZspq
76niT7f1lAPM+v2FZdQujdS7O1wVzA4IF80LqR/3ZAO7snbKmuM8xmI7UkJ4GD+BnQsrCJ3d9Ocb
E++HfAlc3ZhKaZoPJCNpwWXL0LXUo6GfcfudF4L7tfNd/WrFsBQNlbxxYVyDIoYzLPK2CCh0o7hX
v1LtsP/fhfoiCZOVDtDxzNH9wl9B0uGU72LYxlhKtaQ4QELE9JrxiTNtD3kM3afoszHFCJDulwPt
XTJ3sW0WLYVoaQNLWMvgadnXd9LQjS4NRjuIajv5GbJi2HHkA331S/OpCwb34lzxbVgBTndAGF5K
E839z/1D9goAjtW9gK/V1ejRWTKjZKQi6nhfeM7jUFOyVdyqcl7RQLmWIsAZYFt/fDflijxTatRX
QwYmK1yFI2LYZ9Z/DW6dOppwkVecpP38TCzNvsmhI6uPmrW96bzl8o7CsvshLtvlkzROYvpRfybb
5GMiUG6ty/d4L3s6Zg5nnh4tfoSm2P+Za2pUtmFLSmjAJukAxQluIQmrnBqBRu0WWioP6KEzaayh
+Q7plo730eyz8onoXpc13pAfdCzWeWd5ppdRE/yCoKKdLUyX0OVfw+7+43odAf/WfcAbIAQBIibW
3hjLLWjOBBpxudxuHH3SzLPAIjJCqf7c9Na+1Sj2J47TAFo6v0bjmPGRWgoSN7Bi8K7ZHfmPhW8w
LOZwhncKHazEidwcEx2xAheJX7wTYYjQIhBVOBKjxou7nxx6BkdyfcYDaDq73OXSA6NTMjm1rJ9k
ifMAWPOQG5mf5NqGtVGtNa5TnyOBOSZnnD4nItXtfZotz2V7g4oukkMSoQUHVa+vBTE1Z+o3iiL6
0oC9r2jdtptR9qYaQX3PxDC1PGCypP88p/OsGFaJEEbVuP8CJvkz3wIei2E1hM/WZm+ZiVH9eH4C
JgKkLau8PHo38nh7XqdL8jzytfUnLPnq0yMlocHgVwOOANAUrbZi/AulOcY/QXaLRRdB+ErDdniY
mI0I7yd03ezA+fz78dalYJf1uNSgxVb/T3Ja6MzKlqR7qtPPjm1Q3rZpn0rkgYMXknZeyxEMGW+W
/6qUEvXbccZ0ZPNtg1cvP718a3gbdqQcqTyYvWllO4xX2v2BUVRi6+r/SudrjMggTAzzaWMdhTf0
daBXSpfHSxCeSw17ebICh9cm3sdXP3e1rx/+I0k/nIIuh8POX7vFelrjEvDv1wtHUHiLu+ovtty/
mzSrbKbLJHPtC+f/JYVFblRFCbLY9v99I1uknbG9eZGA5gfYv1evNuhCyz71oZCwdyJ16WsDN769
24U1OnfhsNHXvxNiff4uSDgNk/z5q3jiZW2Pa1WHfHuCmXQg6lFSzYWajxRp9rmU8ipz0eFvzLxx
lemm/IyqoM1HhDZe3SIVsj/0G9DxMwktRPQd1/A8J5frf2fvoutq91PXb6lPUzxx/KcLvbEydI3Z
/9TeKVw4hd4gPexXuZ/i+ut7/8Yi77jIGKrqXutBJXPTAkcxTAIrS6OZ3ynzP2Pbxv+9O3hM6yXt
IuunFCrmagXJ5bmzsUL/hP5v+1PQ5pHbCsoLlKHNuHsqB4NtuJvlMjx9FsZDvnRFCEuPq37fUq94
wo2Rn6YXcU1KT4VFFi1UR594gTL4zgt1aeC9YHXPiU5vfGZxy3H6n96hJUrzphi5sVSheSQDPbXk
ILJfknIeAbdkxW3HtcoS8GpecYUJhsvv/YSjaTsffN82ewzamlMbs+vC6lguuxs/33XRcn8ZJ9yl
ospK4FVHlKq8mPKENd2TfJjcEEHkoqoI7yOv6/1DxL0nAc6JA+9d+l4v8LoMzTai1Fv4BmwONmRK
tvQA++htPPBDJyPa4+XrmKrC84JCxeOEJLc6J1QCa+vcTOODAz79XdNGPgNsL9mIvbyO1Tv9Zf+V
0Ih9cFCPX+nM2coZfWKTa/7sxhjo0mfnwwXi6W79hqub+lrCupIdZ89CnCNtxRDTdz4HM8Hwlw2N
qaogsK1d54cF/WJYLNDQVFKPrfcS/AQy4iKFAxkuTaNV2cFnGYEtOrv9TEr6Q9s+c5kVivbnTvcf
WkiKGsnY8sBCe8H/7abiLTn+71pKHveMFZW9GinIlmf85x9s9uL2Wf/GkrT/DuefeZj536kt7Rsl
8pr61xz0CS60iJyoroZ3OqzHFk5+PrWun9SSmuEiSfcP7ETZmowrvv38imMjyWDFxf9kH1lXm+T8
+9bEaFq2pTqMcokIXXqVRJjyAbEkSqTZzwl3NJ6Bo4L4phgso0mvYYI4d42sKNflUIttv35bUOMT
qeprDQ2AhPFW7Sj7dJ4mM5dG6WdESsP9MhFrfIkqqfHEsN2R/V34Kdd+nh8Vhc/lB+CRQCSh9QyN
3JrXRcgcP6gNSMw1vMJlQU83Dp2qYMKo6dEVww78WVauSAz7nZYYJfXkW3UZeX6lhy5gcoHWypYO
BBs174Z9WpV+P9F0OBUYvMe770Hhaunxc1ek5poiHHQbqrvaUo4R+W4GnGHh4ms6aMLWH2hnxNJy
3qjEwNcOEdp5HlujgVIn5EBVDw9o6PEhtw2cs8RA64KA61bmqrVLptAAL2lsUL7nYEwdHHQJ+MYY
C7vwg6zGP+EC0NQtcKPY8zbebeM7CEtBFX+mNQoJgtPHaworrxbTppyN88OZf05MxK8FuDiOFGBH
70UaLMZiAoIkuBlA9Ghu5/K75yJpVDdy+bieNPcGwQ+83iO8xA8SnuEOUCDC8r7LcrdySLIW1mbq
UA8ecjaTUHauKI8Gqh9e7tKoLe3mARkF6N+1ubMCODuH21Oj45DIpwVwxqGoyD83nYnRcyZkNGk2
CYAlAd4ftBRmSeqDvj+gZ3LmvDWcCpR28YHFCkkf18RcE8NeUrqFW8WwK85zntEjGP6JCIwYdpMf
iRHamUTy2sWw+bg/N023wKH/3ObjlPD0AzdLnfm7HdF+cbPVxWJYFcQmuntcHBW1plAngyHepAHT
eg1eSz/NFKplwe/gjSe1D8SOItoIetClm4OomYaVY88VIgerdkvkCBs8BpDg4eNMOWakC4HnjF4P
ktCuWwswFssWRmHgBEuwsUsM6zmuURcdoVsYmIbiHA7jtBHw/LKV9IF24H6+w/IXwmfXgXWX2uwm
e6M/uUtXonMPrNQiLun3HLAgUFGjcM8scGrqwz0HtqSwdl+iQzKUZSBD+mntbDJcd75YQCDg1gL+
20fpObzqlKMkhkUjR5r20SiELL8GUxolMQwhFPKB5/vZRNEwXsKUwKdr1HtnyY2ZQZjoNQIJWtQx
+ldCA0z85+MNrm6G77tF7Nyg9RlhbmfLnwt8cyIKoduGSqJNBoI3LGRj6TRzzDQfqAm6m5f14iTe
JDraWzTyr4KFJhGkVBD440NVE3Ch9bo2XDNzuBcn939xdO7xTLf/H9/37pykE+4o7kLKsYND5bC7
g5ySJOfDKuTU7JbDnD93J4oQYiFWOeWcwzYMuwuJGTmMbLblMHLYxmQz2z77ze/x8A8bH5/r875e
7+fr2nW930td+HXC1ya3KkNXVs6UK1thu7CKEZmLKFtA3jT93mHwqpbuJ2yUkncrH9qmD/6Abi46
XoTL9CbGe93NPD8GutkwOI6myicGDl3ul8bkItKKsaFI8ixodTGWY35NI5sauYTZz3QfKUTygeTX
FwTzEshYO2xlRzNR7Z7g0YpaNFpLjFtP4NBrcJ1ZnMJFfdXM0fK6IuqqlELmxmKuFfnhWPtaQoQE
6XN6R37/bmFeLo/HhTsJ2jlECeR/tJYSfaT94huFbq8768ujtMHaHj7yI6jl/2Q24HdqiEHAkD1N
cKdFH5r60DnPuST2YM9WvV9tgXCDSmE1ePuqAIjVcFAEt/+oNpNAmMK/RtHnSv6llJYYv174k/oy
jnEsa50wXg2/Z+sTVnJY/e8PUXxWyN9rguDnStc+4ADffU35UKQEUv+7BD+sX7UHfpF1YN++8gll
UFDhSec0857GbK8LPTRKGSgwMHF7L9Qb9SKJNxf4B/iVPje4+iqU2Qtq3FG6PFVk842AhEdX/sor
qLg8tk8QrPYAxie0MCYQ92tmO64LVVLn4sB7lcYSiB/IUr13F0jUKLgn1nBKZCyBD241nB3AhYwJ
kHoLX0cinqMdG9O2qLI/JB72BVWzakZB1r34NAnkNnJzD5p/mBFjXY50++4gh62RJ+9VvWNj4Ex2
5EjHkhBNl0D2X+On5Jm0OeyMGle+M5FWPZac4oRPUz3RS7HrUSS1AjGf2OFUovWHF8P6+ht1qqSW
F1M5RLGffoMEggheFL2TQHjDn4Z9HUsZ8TWu4yUWXNBv09yMxNj2HPy6xGi5cXk0Pi09cuXF25Mw
NltA4OQtGqDl7ug0xP9d0fb8XoBCqsbwRAtchp+AIUO0DFKPe1VAVMjHRx2z4q0euJ/88O6SQ+HF
kezc6gmZYMsHP3mliRn5lYs3ixNlhTuO5TUfNY8aAgPPfbaGriykTe1iP0079+htg3P4vhvcpfT1
hDV3g1+B1Efwj1R73a97xSRNvratA/4xky/zqGBimzCbpBybDl2SZtR89hBxCzWiVK2tdUS3sCfS
q3QGlC/P6jyNwIg33ryEtQ/QGdgmVGPe4FlSOi9Il3v6iJLz5YClpdZLcuNfouu6/sqqRLfiGzyc
8zBtwzblx3Gv8Q3oyVoT213qVmgwBjtS/pdH0/WFeoMEWI/+eRg/6PVB9d/fau7lXnJxRMdkGc4u
K//w7bthScQDUORqdYpdjED0ZoCzBYfC+6/E/01S6Z0yke0Y/Rh08THlat9e172P6xF6oy4Zznak
g3A1Q+eol70dfSbYEOrtj5CBdWvWXCbd/00H09d6H2wNzSYHimyPjni7ZS11k/xl0yeDepu/F+ft
0nu9tEtkeE33j8BjiYFlp4u50Q4iqdFZz9NV317GGyv42PFXRt8/h2YABcpoUidcnmiQ5q25FG34
daB4whXzXzZWRxORa6uQGzn8ZUtdspWoC7UeR+A47DMRViOv4XcdqRM8eYhNYB+OATC32f0pH19g
g7YfYGfeHTkkgOJfhq6PndFDXZwo1j4ZcX98dklI0OOIt+ca/htr30iZMPxPaPmKgT8l9SI44nVL
y/CyJQG20KRHxiQ69E48kyqKyA2Nuod1jJAduWdI7bT0MRrgxFN6FLJOvu0weMlbbHHoTe+7M/LJ
i/Ef477wCoLa1Mk4Cxav3t4B3V5kWJZ3MHVx7L3oNFBiHVy57d8vQ8TDDHwM+wLvLwlkrbLYdao1
jcFyflXXRMPNdMS1L1j8nWf07OGOPE1stDr3639Sc3qln9GPalXTBg8oWl+tVE/qhWWcTQD4DY7A
F7tZqyE7tWbf+cb9yuSOn1ST7LcURu51+8a/pArzvErs8hllJCP3mvhPvQQS2iyBIHckw1pBQusf
1EVn+4cvv2n0xnVlrVd6q/nH1e278NJF1iyVVLntTP3PNVYX/NcNjoHDHXAFS3YsQOn7XDAMc3FC
BWt+kEMtV5Vj/FbzENOoGBYoz+BXWro+G3K60VbnGvPsZWSID0PYBZUKis9V5sMPLiinF3eEhwdy
AGbZCmLzRNUpPR2N5JPSuaD0Ia6X0KXJxzka2p3V1piF0VnXqP9ffQsX4+s8+slavXaWqLLm/vWG
xUThsEvi+HEvQuQpNSgrBNT6bOizZGyyJRoASQGubq5ef76Xyt8bBsBesskPezmjWG2d9yzIpnPk
8L8fX74el7XIstv5qsfOZbbofcLyxvB2mM1bpyiSXd5On/KRXs/vx2RPfkjerfDaMfDLvxryjKhb
fx7sUKIxsvZkdal7uFuRebWi3U3/83JJirOGlwXmJaJDEeop0Q2zqdmRrM1C66qy9ssSCOvb3php
lObou3L2brbAnOXy8X+nFu1KDnXC1x/a3ibrmg/KUdTOHRcAHMMIUGOIVWPqFRzYQEx2O7Z59i+y
Sfdi1BJbLXeY9GNBiHwgQIEbNSmeK67kWrW2NOoS6gxLkGPHQIJ/YAZVBUjx+B72+0+rGNgna579
J+P83ZRuXD/slEewmBGCmXUvafGgkZQkkD2pHj3Te2x5jHpLHi/dn2IqDd45VyxrgvwC8bFLtg+l
qLBC47gI/IQVJBHA0fXzyAyTQHAJ+rMGv6w/BLnwvP3akjaIpBdgtZcEMn4bZEWiVCwWf7kbcjg1
CsDvUhiP8CTiH/fIInH+Ryr9a37rC+OlygOLWVJilH5ZCpvjGBeCpj3WI8HmhP1Hkc8bkYRmQiJl
Fqpv78Xwc8XqWBHWF50InzRyMoo74GFHszwtZ4nCNpKUTJAhC3PqK8WE+XqLwD3n6DXjpTQ1gKHF
0CLbAgoDR25eMWw1hvpJII6zIc72wjmO49NJCaS4F0Y/KISS01qCU006CPDG/PhW/v6i+A/n+WeN
GHnv2riNvxrhNtbtw6r0VXdobjusDdusnL7fNjbMkDRxxlOA5vbbUV2k7BNZEDEVm1/bkMA+lDwm
vi2zerVSAvmjiAqwCLyleM4ibf9wmcjOgHUrIMS3RVjNJKoMaIoH8t4vl5BZXbS2rq5OtD9WoKCv
GwklcmuJOIHSfxLI05pwbDMOh8VhPNLX2r05+eAGIic/eCo/3wNx4vxdkMciGJoD4hPQ9X0HaJ6m
MeCMmLFxK57BFlS6q+6XQGbOaYrDUjaZd9bxFoARVxe5KUdy6PE0xjrLrnoRqcT63Nw0PntHnz0W
JMKgRS1lqhiSvrixdnGkt9bOLl8nn2MtzuV2iXS58QurWuP2+2GcZ+32E5dmNImiQ/HoRcFVpMoh
nK3X2dn5SJ0sjgtNTEbg3eQCefHIpU8SSEWBy2ZLqDp4nB0QrJhZCEOtSi0jI6YoPmGNmWlHbHHl
GRNF2mIGmywMiC2c65BAvqW8mo+7AqboVmdXJXgl5aGR61TkihPsz+vLH64cMTm+ueC1rNQBMghc
0wLhoJvHLIwtgWBuMhbG3NMYF3CbHTqCNKFhWWBhGDAj5XbuibXOnuDJxR1JzPs00L1RJMs8kVpD
Wo3GO87CJkE2ZWpmhO2HsYVl9aaza8iCoP7cGsY8dtid2qLjKIFUw3Q9kOI1d2mcKwsH+QAXJtrq
tX8wSm+aBWph8wC60TiBU6tVHpUsgfSPuDPC07e6QLVwdCd/QU5dI+sWx7pZ6FQZHbbJ21KXyYhJ
SRlnawpvoxeNETRwDHzitiqB7BASRChjceu5pvVnUTz+GcqXvjrr4L3rUm/FhGX9f8sl1XvLzigN
Qu6R9jj0Wekfm2XgmTVXHEb1I+CZXj1zBsG4CLnqhXOuGkkFYIoqLYUpCAwTSucV7lo4eCBRbgl+
H7QS9bgEbS6OyCWuqa6jO9Q8llZ9uFjpTxiGYc7uX4tKizM87NStNRlOoJZVhMlIs/DyNxDBJyTX
UmKliiWnD9r27ohV/27yQ3+DsJ4rHvcQE9bliO7lPATLCxb0LTNadrZHcyPHfpKCmTVG4XCI2b4h
EyC6AsGCO/080zim4sxYl1UZm9j8jJ8bwH30S0Ff2e1ZuhiWrWIUL/2pvL9XT8BfTWIqSZViHvEs
McblmH/FQuQ887POL/TSkDuD4ZFz2vY0YwwODdjxgfb8a53vH5y7vsK6EVl0lyty7wmvk/Kd9/h/
bBmRu9ic8RGG+fba7jxaSOTP+zW3u22xGUYsyBQGxdd+IdQm/4xQMWzL1PWeMqT9eVynlp/vT6d6
bX9fiy0oC1TV3KACaFDgvmpLTMHnHPQ0yDw4iJ6tlDlRhFTkbOsctOQDo2c1JZCD18DWDrOgP6sx
Xpr9uGdXPvX+TwIx084f0qlJfB9/dOHV0GVqUxVadoGS+vqRj3XxvxnN8m6V9WMPZkaqcmZpntY4
0xDGEFr/JuFKGhbNcie9jU2w8rh3K/iZyhwRWGv3J7nJHu07eKSymLC+ZmTlf6Uddg7KuqXO8c1a
+r5jHLMj498YI3JNg11b8sa2nHMj8QPssYyn7fujMzW6M6Eps+MSSOdoYVIVqex6Ve2bASfz13kH
LctXrfFHg2SUf9S+d/O5sL0sfO+ZW+wrlytDZo6kO9hXvfG/GPeFDlsLAcIlkO+jRaed1F9Byg9M
+NZXWbmlQapkWDeUP5zD3XG6i6fXY8ThE2xc0hthBr251e7MXzqpPT+1Vedd/hgcvQafwrR2XLvU
7IATlrsVHt11lF76R7nKtYS73bjtzQN1DKsbP2YQX4vrYhd9/ko8utSDaQaVyFK9FAaQ1DOhuHlR
ba4EoguMVzUzdcv3Woultg7Pr/j0+NeEIFiVA1vXsl1HsABkhAqNgWSmby7+6FpaPV/EjE8ZK34c
UGGcUNV5v1nNy/bFcL/jnkFZ6FJc6jwucoAtZpG/EBERcqTjeW8pXs92+C+zwaNUgCYc2d1tV0b7
dqyO673vXnYenGkOyxfX8oK6ct5vAQLOCvTVvKsqj7yUd9f/L723+c8qdun4M6EEsgD6KRNopZYI
Ew7FisqvjySXvghg7630zfLszLx6uFrDlTCXIwCSIpwbRp615txjftgxQL9u3+wD41WmCw27c5nZ
AgLPPcbVs3XQQpWOYgMRhJ+wyNQv3f56dfB9eP/TzJoP48zs+1xCm8NE8PMG2o1aOO8e4cSwcJQm
MglObalvxjHH2FgGDcvJq7Tz/6f8ldTJwqZg67Kwxsx5ceyHi1S5fVqBqOBjL4ojBeZ3+UFsdM24
rb+fau6e+6eU+1eNxKOISZrn8UCXW5/n/MLENEarBPJviZHM4WIvwTieCTvHnBhpK2kBTqo8N4Qb
BYYkRGGj0REDDEGoQ/8oX67+gtrs1lQP6HFW/NoXD1d70/yHn5aEJO0HNhiEX4Vu9/g0sK64DAd5
CwlDYsj8mnJ6A61M1Oic4xKoJqycLZPa+bRRr9HybZUC83sC8wcmpoTJZNUpBOeck28L3tJqxgLV
J6y35EdK5xzwH5BcKjRVbIeh6hFnsHqM/DmQZfWtJqLppufOb2fOYjthbS32ubkLtbxWc4AS1zWO
E7uscMaTm2Mnw7n0q5nGXNBNQZehKWTohg0HcE9EypLNl9PquzsV9rl5uPeErl6Eij/RRIY5etUn
hqdwtt/eofoAw7ftLPSSCHM96jJrKnU0Ctdz8HpdwmokWcgwomHkcc/Yerrv8/vToGa591JxIfEY
F9z4FktbMrzxh4ZFs4p/ATeEtqpHKakOPkMMC6nzNLm6H/ngK0ARkrMRxaTQMI3ajWY1Z0S+ODmZ
YZs3jVyOBnRt3+J3d9WyBE7YLc1mrs5fn1Vc4X1Tf33Sa43o7WZ9f13I6Gqp/WV0cEHR/DbAMufw
XDhOl0sue517N1IzZFs/ewkH0Ktkndmn1g5rONMOA20ua0fNVgI+fUOpBpvcA48YsQhnybqwv+G6
1ZZ59eIiJFE86kx1NAY2C96d2Io7GfWYrU3FBMxMFN62RfOdUR7tj2fcnnsgs/8oAtpuBl10+ZGP
eJsJpYV3TwTpG6Drvj4qhRnvprsIyaqijNBhCeR/OjA6lValPytI8GrpZm42zZZtG7k5z60Vtbai
15k3jRreiAb07PWF1AT3Ea8tx3xWCTHfo6UTmgryOPNXUGsSSNZBxKIEonF+0J7lMFy55Z7izPDO
8ufFx//VZhnslb1uYYHL+1/OpOG9yivOgbnPDjnWXYfcDNxZtnv3/+wPTdxKhkTVlH3Z2FZaHVju
5WWnpfsyiHoP1CUTXUJ/2qYELEVQ3WqOJ7EUCC2rHiGz1afia5cffaMtrcqh+EHllagXzG/EDjjI
sSm7+UfyP6W3km/tB+xwyQsLf5bmL600yA4BkS21B9e9qdIn/UDHGIdmajWi6XEuagHJq13CrvRZ
IYkf/N3UrXJ+TJHn/qxkAqnqzwWQq8B2CmOCd1sCWZyTQI4bXC+U+2TLWCKcYJZQG1gEbleIEZuK
ExKqQ5VK0D/07uOk3APH4kdWvLIY3eXxmCEN2jlXOGJ9nYpxEeIBSs3l4BRdD8fM4Ob2nq35jIc1
Ekj+ugvczl4Ylv//m+p64hmXN+TDoxu/FQIsmWg9KFKYnWaXghe3zDO/hy+2adtlKgN13t60aG+P
c0AFyButufbFVkoB/vlzGI/Xq8BizgKNbHpFeXGF3iEkBvinTsHwXM1lFqjUHpXAEcHW9/hIr7JL
0dR68towEBp89xgXGPWOI81Kp+uzoGB9GY2aDHgkD005R4/rxWOrpBa6y4mzbhteTBjByF20bh9H
1MFbsQJlBL+d5ZDeOeoSqaAwTDJscLOWQHSy8+MAWtEEXwJpI0og1IcSCO+d/d2fQnvzBessAPUH
Ub6Ghc8lPMuroK+H6K+jCOMgiZdr1HMEzhUR+GTz1S7sGA4JS1COvufq1L7Kgk1RQbIxeAC/09Ea
m6qeJ3NiYomhbfj/9YaprQSxdLwf6F2i5KQHymI6xI9NoqYlkFuD2HmYuPSjqTHC7yMRocqDEzJU
RfFe9ifmEKh1c4541TlEZF1iyxMYe34b289KhOo6Ha/IaRlN3eMMW+HLjfMa675Wbh4uj424fgH6
Gy2BBEvR9XBueE5OS/+3uy5PBm67MsFFIwYviJ8evhgsa+lXdWpPgiegJc18bigkFpVXSwGij3gH
EYg4JJ3mbOpV87mGLhhdabFkfgBXOXGVIElqcfTUwL8WwrIZ1HkjRw83a15UXGlD4H0hng8HVadq
oTUVqgcvKf4w+iKEwymqbfxfQtUx7iPCT6H2jmFM8AvdY7nvJBCn2W48s4qYIhMcD1ti+LuZk5VY
AoAcAmp8/K0vTw087d2h0ZqlSwVktFgViFoJpLQncpAN6MMJ4rOVc0lsQZvUktGloJew/3dGSWXg
qNJFy9Iqb1/ut0L4MPDrlN2KgZHCPo3G0NpcTEIEDL8ZDSbpB0pmduIUQN+FXnoIh02GI2DgiNXw
0rwKQ7gIbnwI40PZmqCtNAKwaarCwOJXVNcAZ76K51kDPI69WQOKL+XbR1W6Uv9P8HvSh3PixpE3
3fJ/UpnF9JGq1Cm+Rir2G7WCQLyQHPz3yvEAnguWcX+1fYxfvFlnBSSZAwll6/EM0Wuv/bWTP+CG
jEMeglfdR4BWQHvdrcgeJQqSO0TT6JKaWyOPsmzN7LlOPFKPMyVN7vNu7tsx4hfl3cCMgO7N+kjC
cWooyaBYX997kTjeYgd6c8R5Reh1KG2dsKy/OKldZGKvLFByv1LWIUvIHK1bohBM7cRiBmswcCbQ
fF8jPn2Jo84lzoWkixF0r03m3w790gzsW08RJrjOBoc/K7Kwz85td9rcGpJ+IJqi0Z7FCxA1KccQ
m3FsUJ8XuCrMhm5Oln+TuED4j2VswdZRpdKScw+47bcFSDioD2I0k+4PoztPcuqKMqEoPhAJ48Cr
4JqdmfORKAXv62FXQvm4EOmdBsl4+SyhKiNzlkEOu1tk6E1llInq0kGK3pXWNqvNqhs5dijVldPj
+BBaD54N/BdsubRiiyx3FwySDnRLICqxkWI0gha0mpKaMDs5namLBT0L7+kAETAhOdJegb6U/+Cf
qobuerdpWlt5LGKzYCsf6NpfkFNwtA2T36HyQwKJOCyBBPJvRUXfxbSOTHGzs3MT7vZDaTVa3V2K
kf9E3z2WBbbELxhI4cB7ftZNbX9zPmfX9kChvVht44WZnVBWozrCzjJkonv7zMPQOq92vnjVccGh
uzwwo1smpec4nlv09q3Bv6KBYRy3JtDUMVZ+BGf7ybS8bgzRgxM2ZkUl8xwgt5PlH+HevTAKc2RB
k8TxH1IlkANu/teG/C0s7nlvt5BOanCLl1lBldFZ+pWcc7KnkF//x700LjKcwyVotLdjFIaqvG9K
ID7skaIu9/c7zh5DnLwye0hAMSN0jsQipoCowisxn4eUzQzj5u8wtA/4QGP+ZmhhkCtBZ3LLni2X
QnXmxAsreLsQbr9h8tmX/7KdMoylVjeyDDdWW9QSm35akGaOQEWc4Bwi1NbfSk1b4P3ZTp2Lnz9I
8kPwE1gOUfCSJ+Ho6OKU8IeAjDGdemOZJtroGtiwrc0VQfFUJ9Hd0oGgBSEhkgxsPX58rejaaN6/
6i2Prymza4/Aa04aHRE6ocgIsFe3L4m4RRWJE5LzCU8WHZoG7JdTey1KXhxBFy72HvkN1Y0oqOwN
J/mxDDgNx+LpAShk0IKuqX8INkM7KWfOX+3PrcLB4/Cw9+Rj1tWwhLOEs4U/a02Vvq7o8r4df+H7
o+rdJ86ToWaWRyfOxQ0iCM7ixjrrsktCwxpYumrTQgatOCnEsTTpdn39M6u6gypDto3p4nzoq5pH
Ee8xV0M/bGEu75CmCA6a6bkN73ERAaDE1Yyh0uSN0T/iekpQ8/jk7x4FUoEfCj537qO6iZ7ZUN1U
Gu2gQ/PVw9ybj74nOGVIILu2JWVjDdpOjguc2m2qCo89u3Y87ae/MPPmK9eGyaGBmi/e+m+uSSAb
O+gVkBTSw5NS33E7pH1OtBsbHjU1ov7NbfK1BEK8dIohgdSTvfw7av2OFV4wpRc/4e6D0kv8pPkF
FhB5fOX6mS3aWnBSfx+Ax77PtBtDwtaYIEHIOC4i0ASVardGSgNydrhM4hJWcMbiNYdoHOBP58Ga
QD4HWK+Ajf3cAfvQAQG7ky1WW7+p2JuA0XAal2yySzctNW72f1HfGWzKRRFD9+EuvQ+O+8VFUhnw
j6Qk7kJ4IDNmAQw2JRM5Hxaojnz85ysS72QkFc0JEeQUDdUU2RZcOPFMt1iHxVSdlCIb+fNVfd/8
B8Ga+eAAvXTCcOYAC0Vy24RWm8j9DC9bf8R97reUEA6AE7OqV818dOquaAy33pVijSqfH0717NeP
I6f4JtoLZhkiO6+mdMf9srxHaggU8jXmhsuWTy64TAbLY59WPciHfsaxB0N4OOyGoyDw1KqSMYKt
NbadZzy6whwcDHxF8bLl/8/gAq4VeP2kFdOEbW9usiKr8htEL4FWgpqjAc1mZ4jfv/EcPXkJxK+1
BE70hLfnAuHmVqurcFoBwZgfpFpHw3zGctEkkGVsNBL//WKz/s8X09g371A9zQLoM/f7E+UttR6L
eV4YZmvai5D2mDqZJ6mfBLEETsVP1pIegnm6E79Z+dAEaJu/ZfeB3q1z5jVdSrgVXDBeAmGzyvmN
W+qEwA8D8VVc1hGcxz0cd/yGlMLEwUBkgwb59aU6pRN4J/H0njjG5oKVq6K7+ftAXJ+TIN+fPeMi
ILRQg3Y1Cp9Pr+6llXOxUgwH17S/FQ3pYrQDWHE5eWTHJdV4dzOp22yq5pdjUc633OZLNLDjCBAX
ViqF5IjggfuD7Ek7hv6GNPOqATv4FR7xOxzyNLIj44jNPv7i6VqhthOH4v0LbVWgUdeo2JL4ztf+
rOuM68hbOeJoffj46p7B1qlTdt357Zeyhe2YgqM172wkEBzfoX0VaDmZuB29nq0cSasWL1wokUAy
s+4toV5hRq70wbR2mjZHSaMa5AimGsNtqecNz+mjD53OP5UwQAjSQUggppRPspmNmTqZlir9zeXv
lsUkUuerXfJxH0XDaLZjaSmBeyeruUSh+JX3fObhe4z/AYbtXuhzEghDyqgYhTrgENd1yupGj1sB
at3YFs10OxCoeObbftezLWwGGhUknt0s3vdw3nFKX59Pv0uRuhwHzpMf9zH/ZAVxNHPbTMkCQhJc
D4+U7y/OLG4Pj0qR/gKSc/tcwGpcu4eOBGLU0SAcSS+yMZ9Wz09wvg0qDXwQdh/or47MJBp8mgBZ
GUA4gS2mNQZSity+ctTBkHs/XonIbr8DFSPHXDISRLb8HJRQ6Tp8oj2ERHdZgRcPOl/Y7WjbOIh9
V/f69er1rq27g8x/ixzPXN81XWl7+9Wq89Bjy6nkbYf2fk4+de7vdzt2u1+6UfxfRNAvd3k2XmeQ
+kDcl/AgVQ3u5N5d+/e6D0hwhXEC652GpML19zRCFyRqX+2vxa2j2GQbfEK+Bpyhe6sq+dPrSbuS
0hOuUh9a7FrkxZ7QqoYHJ/yJXxZ2HR3Y6FGjYYDfqtU+7oLCewK3VWgSgl5rt0KxJlxrQeCP3EQg
+KFe+5gz6eI4+bQQ/e0TIPNEMy5xIYBfkg9US8dLnINgj25jVWFvtZ6Lq1WV9a6NQMqzGwKRCATC
EG+9h4FYhY4UW+FHm7wioDjRldCjiT1K0TB/EibBicYn7HY6tswFYmn67zOK5uuCHn6r9+oIyOgm
xBG6NnusYzxuRVlD6wmNcI75UDuQgbnnJ5BAfjo9QfiDuUer0hv4iwetxYz8YMPIFtqSO3wNm/Vg
IUch6wofeNHuNYQHDjomaeLF81JbwL0l86cSOgmo+5DOUlSdf1BBelAJViL5+cKRRTlZQQ6MohgW
n0fL94XpzWUTxiWQ+20HwAUZkvd8jXnfBmLc3A2I4LfWcuLF5NzACnWKRnZb2biIGO0RFyYAQgn0
iqfm0Cd5MIF69AvAf2P2gof+LnukKbqVijiSEGwLdgu1LUVqqgGxiHq7WctQ48xq/Z5VF1hEFeVK
rGFb8SBbqFXKQfnni2zFlAHCyB27c7bSUaazQpBEJlzgghQeEpyKJfA44jbOniLNx39JIPaJJuUq
sSf57b94nQz2aHxtIrw1BdmUhzBitltNpTNhfErLx4jn0oeEOdHS8myqUPbVtSopTnOyN/v01hQk
5Bvg0nj08x/8hNfhJxiodcIKxWxArL73RPBOXX1w4J8BpiDfgygkA10xW5VkKR4dat/ab5lLJ0lg
IP14DtVhdEaoZsk0IGjHkysZ+/RZ+oi7QoMeox/Hnf2E+OxgqCBUdUWuvGvMK3gS7/ahXgJxA7MO
mnMm7Qj0mhv4WLt7Q382NiUMCjHY8KbyPwsPL2MSy+VFKNlz4vR1Hzh+QW5JBspC18WBHpbNkTip
PAesO7oOV/1FVsubh4ODYOk7kFafBEtj+dprncQK0PSgWsEqqCpuvHi2EDNJld4Fz3yciSJyzXkM
XnlL/yO/EormgFC8+fmLVBokENlLlTCqF6077MgA2BAGNKzGM8vj7CpcYQLEXl5WUKXxsoiwJFVy
FMw/zwnKlVLazFXcIOugVRpvrk/M5uBFqjQp3hkGf/E+iiVnOeBz3a105SO/EvQkkHVFofbtE2Td
4u/VLNMBehcfBYct5+D8SuYpJW2dQ9peWgIPxYeizXKFMZUTs+XLwjo+UNtouHzV7pzlp1HRFdns
9jUcvI9Bv+0kvciP2fwpW92zoxHYxmeTORdMy2BtIpi2EyCzEEm50byN1WGcpZjLT0C04oNq6mK3
0csMBhsEt2zxYfEsAnsUWJ2F8n4nYv3tpgqUbb5XF2G4HizZrbdKvnLWUkVBRNHHT4PhldC9nyu8
KAJSOJuwCCVrLp+t5VeafFVi5eDMWkfp/sQ/1KJTcLMw9nCIIfVU3LngktqCuc9qJkDYLKgUJ4F0
rl8B41Gtuh/GvX8EKdZfzjIkbHxkCnykftqt/ruBlDT2dYe8WnpWLWJoryM3zy5kvItKHuqwIXxq
ciMMtS9aigzNC6Z+6GDOs1tzuNM4LkDZHBw0o0z6UKW+O1PRZSEw6KLZ0wG/3R4lrZne0fozccQG
JPjMHTFJ1eVjCX64tJNF4r460XAIrK292a31+vNlcZ6RmDwmdcd8Aq0SvZz7d3ps2J6z8aVcs9Tm
9qubByCyL3SMAz9hG9ejrwUHUhQK5J8ymt1KuIN510BVQ6zodYDSiYLZBSP+vqpCj4R5Ar45WPnG
yoN91Gjkvh6dfCekNlyKx/nF6zXau0J8m56VrlKRvdSg5kkJ5HXX99rd5tkfiX+Md4fpEHRsNZc3
F7q+E/XycC06xmcuzRXnh/RqsvvZ5OemjgcWMmHx+cjeikoxDWMT706x/RiiQFXWWFUOE0sgvKAL
RUKCKF+kZnlpqkBndmGK8U2oE7bkZ8WrDxFi2uQxr8fg8D+fLBFLOUJ9FPiqumE9r1n2Spd12La+
/R6CywsWOfb5yL6i9cCDX1Xsc896PArTILzyG9gsI2y52V3hUdv77qP0DKX6y+1eo3sSNWg4YUm5
TvWkG2KgJ2TbyF1bSzy4xXO2YAo1vFTcwL1S2TPLARdveaznkmsUXDMdTATN4KIurPH/fbVgnwnx
igp6ymHu7F9RAPIZuFzNOeAuQ3Tas12+Ad0hP6u6nJlPuyxT7nT7w9PuZVFpm/nUL9j89oA3RzqV
V7psE6ZyL07MmQ/I96MeVtc9PrOb0JlvEb369ozK2qD34nB3sGHF8b8ipfBCD5phop4sBGndWCXw
bS+KVX3z7sVRPVgV+YSf2lzgv/KD/htxjAVftyENCaTUhhFTp4OxKmpMU8geI6L6BT601c1jt5q8
Yjmzzky7E+MJXEEwhvDTpEICEaiKsccvtqnQ9P0wh7eVPF7kV2bwzZeyb3H7POd5W8+I16idvog2
t5gQvGxpCfx8bs6f0+EPaokYFLui+mb72Nzr7iMPUvYcONfBBH7d1pRbFNarF0ogS98rv5RfbH1A
nJ3TWkeIIgt2XDTlhtwVjvRbVRELgmKLf1BDx9gjZxYedj/gdSByJJAouOEpxpu9OYdHGVfdHDkC
cvOk7AlloXYz9SGx2WknNLL5qNGUSUoE9h/mOZFJcOvgm/lXISl/mAKV1QfXCbXMAy4XdbXtksnG
tfS7ThHOaVPBAZcORz+GTpLC8nAvKSNA0afVM/xIMWX6xIquKOvw9eIeQt+A0EluSv8VeZR+CtHn
UATB2TR/o/KfwddzrhzBLXd6gKYHw6OVoT+hLJcdYVVeE9h53wES/h0sryBiSkb4UyGwYJ0nJPBJ
R0DOmqi4gJb9Eho8NEVd1cvgoXnGD6AxzTeloXf/74e9JFOqiMABtmnUPr+PbVx8yOI5Y6WvmDE6
a6WE0FtPOA0QFbPAbS7msMWRvaMT7q0TUrL+bRhPAMA8p2jdnxdTX1sKx1RjOSwaN6TmAkampHkV
HvcNJkYXlBMoxhJIwOrLzBcSSFt6Hgr6RfaoZcrPH6P8/QX1UPa8YQ+0Hm4gBNqHBGFEkC807KUx
YBNAbaYlVbyhx64t45L6sowYzS2oRpjgtDSbFhdgKwiUGP/C7wL9IyoI6Ias+dBR3ekkE1zVP0ta
1zarZUsg3k05zSMk3IkZqtjDTzpe7bBvw1s3ChrD9ON0P5g8v3pAnLLfoJePwPWCu4yXSWDvCA/0
6k6uucbkQtMiQAWpURqvfNZw8XERBodulN6tfiRDFJn/v3Y43T4P2qoYAQ0goJaSu2H+QdUnPimZ
VR6R4ZYxsqW3Kickl5V6f8l0UyfyHn73is9TPE+pwfvA1uWjf+WIerits/b3rjjuJOT5vXxRnL8e
rfO7+ZW7ZiCzM9wNfv34aHDlx0hLtThGiwTiujZAu3K2e6broLoytkFOELSGilUoCvAxPj4pt6xY
saizWl/RYGJ8IxC2IXXHRiasy1G6LPZ7C4sCnclVP6mxBKOdftW8R9/8hLfKeJdGQ3oL0AuRmn2F
MKHTHK4lskz6HtXTPapCste9ljS5M1cLXcaYRRR5n+ah2veF0yxj24PHbbXd8T7IFSDDdfk/8MFY
8oqAa1Cpao8S8apcG1OvzeqfPQ/CWglnxQyey3qlqaAuwkcwPIe6JZtv6+zc1Iw82HMk37SWJ4EQ
QFZIVAjPIzbV+UIfIlQD+wsEsgnzhQtT1ZN5C+GJ+q2/ZzBNyHAJpBCIXXcCft5ulmaf/6ybaQsX
C4qDj7b7rObbZ8MQEx4vxj387ndVUNyf+2Tdu5DpTFWdSA83dx87I0ZHeZYO85FAA05IrbgQjn9/
/BioMUGgUcWskTCv6Oyw0kay7tLf1u7QPKkvIgOR0KmgNLNr9OG+s2/q2fi42ikvKs4wDFFCq83Z
wTEdaOlZ1b3wG19C5fsKsCBnVlAR//OiEfnuI3bxCd0qKJIp5k1Q24NS16wy3WqMO3BEgZEEUi0g
JH7Kv/4WGLafFACJGb/LpXcfi6A7CYn2eZd8/sijndo3RKAZZpTvKjIYETzb6viXO/wQ5bLGDYyv
UkViVYmVZ0Zg4IfkTwo5+Xkn9y2cs7Y4seVZQCAOh7UHn6lnWDH02S0skHWzhjEJiJI2W/TphcEr
S6RkuYfwOzPrgsnwP1yFJsYskub0v2qzu3TbcvdrdGr7mt/UO+SRwMDXN0+4JVva493PHbX8Zt8Y
X0TMQGrm42dhPKSz74FovXo4A1dQzQ8ebpU+iwfDjadygVF3C36wN0yKQdSJd6EKo+7VnSbv06Z7
JJBurZf5U1Ba0FqbnU712lHDW1NWwDQZXj0Fo5mL8XyXg9MpV0FacxoNSGe6/norpZQWh2el47QF
R4Hzt2E7PrY6cOKXUjUGP2G3JdqG6m7H6BJTSJicqcFuVMthDz6MhshfD24mqwq39x/dRYhXb+gK
fUgC6Yxs6Hhluv6JNgHA4qzf802zmh8rD8DpK1tuiR9FoJBCAr3oxhAnQpEKV+7BII35wUNr1Xod
zmOO9gEz9r8NA8Z9xUNwe3x9eRTSL7v4nzISmKFlxOABbS47rzAkkB5AeAeEid78hIfj8VQU7hnS
ihBT7Rnl75iskR/0rYqqSIQzjO0ww/HJ2rr3p+Th6IAnm2VYnOZL7S4OVukOooiFuu0IEaYJwZZA
GlrKMlU40DXOnunZ5dKikMzoVESL4cSggHBxs9lEe8Fkm+Vtu+9LVHAYXtNvGx2i2fas2jcNaDBo
8NRjEdZIQXI73ScoJZ0M0/YHt6LPSCC7pabCaQn4zTiddvS34G6z0JSAT0Abuo2FK6fun06LvLaq
5mYOu1YalOElxgz5IqB9QkKXF7Tz7osHhMVepS7DpUYg+OPgf8mMpI6Gnj1ys5ZgJqEFNlW1f7Tt
jy++tnYHoBlKVl5IIExcofil94JYpsM4hrWU86m+e0Zv3hfRgg8q412v92orhs8KgBhppMdgIgq3
CwypBHpc++1KPJJegVXcH5hH4lCwCfxIBlu8IDUH4vWUojM1psZmbWUUJ74lCCQNpUhtwMDdQN4L
dRgeD49QKlmIz7zGUOXMpPSmAklw/6he31xdmt5+QiS6JV1M0ezZuRmFRZs16YLNdrF1ctjWmfLw
3nxCCoJbaX50eXFRLhz0R237wM6x57ezKRjdbpGjwifBi9kQOFHkVP7TthM3hMFEv0+KC27o83O+
T3Vih9nT1u9Iyf+z3RaWe+tFr2KiZh5Dh7BU20eSQOKGgls0sJm/Pk2Ii9YPR7IiEHwg22M5guK+
nkkJLHGdghnHZcbT8MB6RfmUcrqJR1OGuqUEYjVRr08TMrRvEwRh4snfCYlpdZNWBsFXV2skkKHW
p6heKlcqFpP2nLPDD0zPPNgwiMmmdVxu+DavQhYkwKYiwUWgwRn8C/YZCAvg8c8MKFE+gJx1WJvG
aNHWQtn6eqEnLCDN2f/JOjayaEK81DbQsB8qiPQNyNvBK6PA5ri6Cau1K06p+h1QykXCD1NSxtKq
MVwgTesN7uYHRnWrGu1uUWyfTxYCa95+mkkRTbqGhEYvGgd2LItEFcFEdtCwQvTnzd2QBNGr+Nx9
C+bKjSlLBP9MKxE1vQGXzyfQK2PKnlbpHG9JjyPqtgaBPvHjAO2jfkS+vtEYHx3A5cTNZolTyWFe
KwoFoboTGRPRYNzuchXGGtx2ggfzn0KBWfs/SEM/Vm7pgqHyC9V+Lv94LQ3Gr4DuXb8/fHuoNmSW
MWuh1ynA1vIrPLyQN+xklm5NJPCJVLAmd1Ic8mXs2ohOae6QNdMlJYgtcEY3D0CTJp8TBMfTsj5c
iijvQRi/GexWPvuVoG3EmKxEuRu93UjLD9zdCjdNRu0DwsKAmGqpjx4+Tg7h3F9VowXPfOnFY3F8
7KincaTCRkE2hWRA9xoinTsrnW5YTk6W1IduNgOPf7/mSz/1vboRFf7Mgw/HRbIYIEk6j7/M+5VZ
GtGE1ZnOWcIqhlDXtmYR60JACKG5mhT2AQRdj5YPJFYv0LU/tWK5027Q6PuvNv/0WSAS1dwjBk5+
a+TspXhGPTRh6PO5nqaw2HUgCSF0cryyzKAO8aJ9xLRaqdb/AbLs705p7wwPDj6x2kqNrW0UESII
42VuUTUUE7gNPWBWArHLetjokWBTG/b/HzDPWEj1TJ5lYOXiYqUBo8EZ7opjOIWsK/Ctadih8/Y8
7QMDTg2YkaJm6rnLlXxkHMmJvYbAeBV/BiIzQ1wXlJOaxcDPvyNiNty7Sz/t/ytDY7wNSBEvTM74
dcEXWn5ffFb34ni4Br8hpOafVwOfp7LbfpoUKF5K5ts1vio+nLnY2wNy+AC9gpLwJGSj5Esv+teg
55/YGIz7MCYqnLX9G4u+DIumw3LBqKr1uNt1E57W6sqjgX3C2ywKubYZKWKA3zYOo057eARZQEcv
zQJyfADvLIIjZHMaDM4cv/b+uMBFKrEV7iUR8fDQ6LkSQs6zhplKwH0M35TSRcl41cHz9/NiGHFa
8MEmsXX7+7e+6JRR4ZxpF4czlhNfEfNfd1/JBs0IkZVBMbbzPQcbPxL/pxzZMbbefv99nN/FI2+m
1duXgP+MyO4KguRuO7/JlbJ57PCLY6uqoa8FwGeQZCeB/CU2B5lUrXodKVX8O3ZGP63GF2cbujX2
ZlzZbEXqlDAJV0j7+WK6ACfqFDNFAWF7Hf2/ZLh7B/HDjLpdq32zzWHTIF+0/WPgvOoLwx9qUhgS
zGMSwAFesL7dyhGKL/9g19YLhfqaiOUKY36Qrqpj1o0RBZZcNp9AgeW9BZiMdYB7V9md9diE8jUf
AEwsFIk4Jg03W6VMjQ22zDs6FF2HZfDcG9fa7mnX1kXDhd+UY60PiPC4EIGxk0mlUPtpFkeQGT/L
Rc0i+Dgp+iZtrF+LyNuaM5YXP0DEHDCE6a8jdezx4MZHgwIF/U+BAtS3zMV+FFK0xs1nj52C13i5
uw747f5aNwDimOJpqenjJWiM6B5PNKQs7tioPYN8QBNTcCelsVinJoFgTVJkofaPPfjQaCBFSGie
IHsP29XlXahVZgZUtUopY1m/Taq7Ywf3Nsdvre+tBXEctiCb8NPg98r2ormes4SNLgoRx48F8A3C
xhL9pO9F1cFwIytWcaI9dBY16wcuABg3noMH7ZJmHh3JGRZvduppcNV0aip0LUQI/PjO+lkIYSO1
2pKUPrPqKJJA6jFH+vZOTdHl6uO4xigmUVgqgdzOT7hNdXa0/CR8cEbEWGFK8xyXeH9AnFs5EGLY
dm1h/K9MBE1/eYRAbSG8JrTnI1BMgKrPDqHygwSgPnKDqdgSgXX+FJ/Pj816EHpRYMdtMCCYSyDr
sm444ba2nHcr3atAcQgXvC/srav+x3kDWxR8sHvPkA6Cn5OiXe3MiPWIf4+M5+i6lQsRK3HqBZld
ZYd9bR9LBzBdA4WgS830ZksQjHP1gS8KTVyrwIP2zVxgDscQRAKY+tbVgbZVb3t6NLrb9uCCeciv
POBCAgIVyawSv+v/IqiGdfBSjjy0xd9EaGmnr9GdB9DgFsKGs2eOEfYcJXpH/6rePZqmaEVAILtA
pUo5pF/IDbFHzX68lxMhHRoYuMWyEfylkj/954Ep6u1Mw13qt6jdIPhrtJlae7a7Y7n4na32OX1x
qPssWw8DFUTFooWBUkC9/7E4Z7ms3+8HA4mkFaGFhN4d76ug9ws/O+9S9/kDfQEgXzlQO+A6epNK
j6/336eVg9CedQqUWrGau1THVHP/pqsSSHRF0puO9VQXzJaGwcydxZhm3/S+2DI36HzyZouyyI9d
6rLwaIVBtXwa6MLPgodtn7LnKOWMmpRLiV97ZOJJTWaszxb3GvVcuM6Y1G++FhYYOx5YUNVc6nyK
WsLJSCkOSUJFkhjsMa0cfiw1KH6gDSRdgOv1tXsP4xECQbn33+E83Oh3iyN7ymVAcStGWN5sVEay
9YmA+2YI2j311YWtGLgwssYY+K/ytVB+VoxP4NNAjnjNkhc/0AOO0ai29JPzP9se9yUI7wkyazcI
+UghXExJZ624p+QqE8XTce0wegQNH+ZiGr6IRq2LBlBMcE0nz69XS2rYlkUEQ8idiowbXReTMxPl
5XfJXyhdIh3bdy8/GU0s5s7vSY0hv56/+XG26n9dZy0ONVLcIe42p069SCPpGr1WgsQ/WEd4ozpw
hAcvFK5xKadrh+eqbOZNZUqowUosTDWF8wLHhvGdKwrrt/aRbPis1cOtxUnI5eqb1eh90buiTf/x
qG75upTvIs6pcs+52fi6uaRcPUfxR2/MNCYcVagzYqhsxbq/T3CztJO6m+1UE6KLbw/J/lV4cvj3
t9+yKlNfx3pW7wkI7QwOBq46CV0RQYX/xLWEhOW0nyTrfkh1QPFhC+NZYWXCVLfBBZebXinfuwdc
JqrI83IfLIuv3Mn5RKlv3E8K0+incWZFeBep7QzOXKnJ3ptV0bMHGhaEE/9utNHTjVH8/iW22b9Z
eEUCqWIQwG3OnAgT1g2gceJcjz5xdXPXWG3JglwxTaYk7cJhpD4H9VDEWBqLG3t45V1fXs0ABtZz
kNqNm7MCWhk0mtOhtxGc9SyfHPsDwebOA409/MgQUJcgfWFpLfXaGGg2m4EEItu2uH7PEh+0/pR3
Po4YAWgHh2Rj2ffvVyQcGn43/CHTWt6UV/B+gogPquUHTcqlT63HMzhb2wdg4sbJWQIhZ64/09od
4ADy9qGh5USsbXoj8B/OJbDoF8N/jN064wYd9MuFjksgQdVLj34Hv1Cxxwgc2auHI5ekOnC7Lb1Z
dXkVmJkoOm+tb4hLEfsxUCJYbAilGhFRISYiW6QTw0yKJMia+Zpfw/FofqyvBPLduTLK8C8c1y/H
Pp/k54QQb4OuV/xTxJHydZ0Eoth6dK88iU+5FseASqOuZOT9yHsqj/w2jqBfIGUkdPIMlMI/sGly
qwnPtUzb9DMkEJX9znYatl7xPy3Ro68jFbnX0sr1GJOG+RNj7+bhqj/CL6HR/HaYkMG6FckL8Up8
6KyglMoaGGepZVoDLeilkTA3L3GZ1FXmVPJz8PZ/mJZPmZSAvx1DakIWVNfzv9VHP28PRnBBHo0c
h/4sgZRlyM2C89eCZX7ccStQ3uz7ge5oKdywE/0TPWSJCa4eJczIh0invcqi1pITqI+/vvI0q1hh
AY1P6bVfV+xtfHglE7a2miMV1Jkb3mOWbS0p/akAEkxg2ZYFoFpe1uQsgrWchriPaI5hCIIbp/vg
Wz4gzfCGwesHfMGvZBRxVV1IBV7kVP74chDFD1wFnme9yu+gJHt1BzIFmSRuGWpVW5oK+aBy23BW
H0LPnhNth0cIDSeiQngnI45evNDuFtcMOoOyjMiPdJpGFb893NymcbnCUiyuXTW0b2YDsSyAytjl
bwoeICRS+7KI1qYYoIEtZo8KCbpGA1/GkJHEh6yjrQ/j6qLRXDJKiJmIymRBMfAQU4yraSoLykf1
UqQDEH/bxQUWtDxawIuahldjcGcrr6zGb5gNALT1hAFuUlt4aI7KYTw+Nl2ATB4Thw/Fk0GWmemp
WA1R5Kul/D5hfe0EVcxZl42keJdv6yqtfyXQYahpfeut1Btxoq46wfYuvPJgUK6ofa2esald1ev0
B4+OiPtjEuak8fpfG/0OiFh8zWSbntIyDYSf9RRkRsP0l3E0QUW36BhhZU1pogplVNniGrl5AqJB
XL4tWxhfMm0R3IWgwYXJjGjsaC2vUYG7gHK0RvDup4uViX6rXvlCagJCuIBit6HWRHX8a6E8b9nC
4BMtmb5JQmkkKkog7pXUdffZ4OBcRWQu4sSArou4gDwWSCnBkF+nzl1RYaYwMy1owtq8VBNXbP4N
fJpySmxsYhtDOEpt1mobWE7gbGRARRmd8xfVN1KpHgR2HGGtitHhcTDqitJLhUEr0pF6gbn/irbz
UwomaxHpoZ6qhuoRc5ZDXhB4QZjY2nH3IGxm9OCEJW/gAgX609nr9fseISFpSjoiySBCCiQ/T2wv
mkRhYp8l9SHUhAzuYAJ7cwXBEZg8hAYy6f4FTGl290Hyg4tGIoQn7xAkEJs0zkAT7JgPuBOJQEx+
4Hd+N5tAfWJ8fWXg0U5kggL0fVJ+hdnA4pLwPedPo4SjjeMBKLnQWZqxqB6WqSHEF1ZR1439qTPN
gUoyUBRfNX5+I7IuQAK5k1ubQJoBujs9PObsqO3uLYW69U0prun9Qk2KOi2Eioxn5NROzAhNJ+ql
2iCVVMxpwqTyC7ZD5jWhtiUhLJ7VmBXlzxYA+hwjEWPjwEjOhhi7zpoFJqJlD9qKYHyS+WLXmYTZ
80D0Efjmt5aNSZqg1E9R98QPJMFVbWKfm3b6+vAJ6YE1f+/T/tSyIv825opHhxrxXENWc2QFu0bf
TBxoHfv5+5IBem/3xx+XHpYTv0nnuzHtNqiVbvV9sq0tQ2p00n0BXQ8hxz3P8qWB2Jx4Pcn3X+oO
t+yEpXwJJLnhN2PfD2qPlm3rtZDCyd36fFQIhUDzqpUOMvf4KWpUTCx+vvrezrj3s8YrCQt4bUC2
u4S05eQf5/7AArt7l19G8pUmSA98uQq7LmRx4ogedLWxahZ8ysK080w65+aYzt1ZNf2vLNk2TGOQ
eeA9ejCp+At2x4XZFti+4E8LDN/b6b0B97hUaJcrN7DnsR1JqrD+fdKADz5fubpnobFNieJhkdVr
vSMj11i8JoE8fFe3TLG9o1f0g1mjZGorkml537DywCiSpUxt+HbX9XVlHEHXuX4FlnF/NOuyL6xR
5l8nnvS5YBtxm+OK272hvGvyDQsDKVYDKqgHxaQh6aUaOUsybpzpA++ebMNZKE6IqVqjVwvPZNpZ
0Q2iXySD0wBtnJ8Q9Hi6y9FwwfPK4VRF0FUszS4xz3tlUBvM/YSKqIQhW9yLP64pMO+Jx/huYQ4T
UXd09nheqZv2T/Fn2Ovy4hh0mqsLqCW81oHYiQ01fjsXyRq6fW49LfremdKb8gty05vF0JtLZwnc
u9KbxN1ghtu6Rpz8XZI2QvH5FiqB6NupXdosTCElxfqDHZBuOO9aUoAXXyVa0M5j5NR1v/QboMi2
3hd+47ZTB3Ln8QgaA/dy+K+V1M79Fn9aCEykKG8sJOsBY2viSJmCQxdtAnv+4YHXz4jrsucKnLCd
Kfh7EkjrhOP9xKHDISGTXDjF6hh8SG/mRQmitVJkOAB88eR6mDXysPz90RJIgHiWs5atKFIfEvAP
GLbhu/+pqN4hqneCtZSLaRhPCWSsTUSQk7oH618KG16NYy3wzhfK1jzLjGLwMFY8SnVzUdLAfO3B
RRM1hrVwNCEhRn9dNgy6jGKIa5Rf/yi86n1Las11sEBkUdOKl4huj2J++WQ1pBNaS2wDVx0G5ETS
wP2f0AKATfFv5Bw9MSgixpZaH87TrbPkigsO81hSGK60X8IyKDj3hyS58ZxRJ6Emih95vJ7Y0joL
vzc7jVwOEeSimDQX1a6YlM4Vdnp4RtUte6lUFMEmAxPWDi3Gose4Gbyi3oicDXnchpqlMeqPpdUP
1OYSGp8wEPRY+el44O7WnEGLCK0vldLHozckInC0+DVepo4fv75QagFZkbXs0RTgYNDprj3BM+C0
GJa79UEPflbgnha1xfB3wcV4m9nFPjGNQJFAYjFY6fPpxlb98AQ6+W7SdG0brGUs9Hbp8ex0572X
o5g2Q8ewc5tNAOjko+2YeIRpgzqhtSCSyBUvoANVkVJWDDyBfll9i+4hi460PVkM48RR29d8Awjc
/Y0SSE22vFhML9cTJtGp0lzyn8uHkf3xpWS+3voMqJTO2XFmeD35Ls9aCTrVAhcSWv+/f0NFEEon
nKQZcXcgLNIxuEHM2jSfHMcazZG41x7pUKI0NyPBLVeoIP2FdbAEEvLtRwEBm0D+59coa48NY2nz
COW91QSScW87bMV45XYmECRG819EzADRGVgnX0xzVOvACZi2UOjhL17jByz0zP5Vk0PtBb/iUp2K
EWfhdBjdRYo7sZUFHtEFxhVH0fTyn7ZV93Wl/4VSXN/eFjGr5niT63C/BGKVEhcaP2vfIP0H2+N6
/Tq/Rx/wEAtG6SRvQyGrLr/Pi0GvcaYrjw1kEcQVQR4TRDWWC50QgzJNjEgxw42397vwCT5+0unH
+H9v4xCMDN56poNrqYkKFRLYHFg20uXYzIRAaA6cfQf/9YNjef5odvWMwvevae2e+VQmyCFeb2x7
PKJ65pbZkJgsILCKXPThe8bS6/W8K9vj5//n/Gpo0Gr70MHk0NI8i11514eG7j3aI5tYeaXkFjTK
6dvAoQN6p87Y2J0IkLX4sPmxhoPFIcikl9wTTICBXcgodxqZrcISxo82Lwx//81gxV+jEAHUXE8D
wA/6JYId+4GbOlXFrvXNG7LMvOBWLECF0Ej84N24uCsll4o826rCDLtzqF6tbZubsf/L+yQcDVt/
/PlGcUnxWdeVwuAGwsq1/NgP7vME/2YJ5Gp6kNWAKmjGHVPQbiCb6gaW/FJQeoqEBuRMR4oJC4Sf
8q3RYqmIKkkg+zyvrni6ZFBkb9Bq1BtkmI0PH0yk8J0W9W+O7S0vT6E2icgT+PdCfAbwGHtvua0t
u+A1f5Bmr0HRKZE+QuZLXRHczfvkd+BTSGuBYJvTGLjNybFQW4oAvEeHUWP77f8Z6lDMUmH1KPKh
49UFiE5EzYRl2IzA5NhVCmHJWaVAoxi5X1ytZAV9oSZwHQv29ymizyulMn60dzOzPSyjfeHSaGi4
Zd1vIoFEHXme9ZUr4PEful/m37RgqguLhfhIMYkaVIBKZsPjSN+7jeZNGfnIXhLIegBbtxVe/DKu
1ij06hpRCbPHi705k1cnCJGV67AO7JiKX9eCoNCz0CWD74IUOpURBvSByXSx1MCHbPaDEUKnwLap
p3TdtlgGtgylHJ3gghIpQ/F2LSuGpK7a8Vvn77zI74t4AYwaS3+5LCpEOzWeFXKMursqs0ICkYH/
IrBHqyjyxZSIzkz3Kwj1A6JCy5UucHQU1PIsnDHjLOZvfN8bpKro3REwWtcRVMGI5cMMb2FWZFmo
LKYA2gQf5LzwgEfysDy5MCOx+ZDJziUQRgP5JKoUdZ3gf3TYZGpHjsv0aAxrW56gUZFxhGUlADHF
J3zsvHjEbrY8FEDymrHRaCnS8UnGzqOciHRtlg6hxV7XqIaRHRz21XklMKYV7Z+qiOirFEH5JI+V
kTNilHXG8VRTovp9Ch74rdTTFasL5E9u/cepuKXkl+uON4xfEsgC4UdV/xql84vs7q/TJ2tXJRC5
DRpGthj9rQhdTzZU1kblDVmrFbSvWvIXTCqFfHR/obUpw1lIHo06vqKnx0YRqWqW2gI8MC7EpFd3
6I4WKU1EhwrQ+vkiXZAM01ze7ByW+QilVx5/8bjBQJ25H4w9XFa4sWC2etgXxjFaII+pPSbfaUik
9tijwgldxkIYezQ9mb3t7T8eXxKsdbOYVOd3JbIzbWyHI0Nmou/RgXOm2iKo0edb8wyEPpMSLR1A
vMLCL5afrf6eK6FyG1+zcQDG3Xy70Jh3vzZUk6gv+g1rLwdJUP+90XEJLGiskCH+qJaao7wekgBc
0JTiK6KEUD/C4rVNhGny3W1+H92yNOaehtLo5qhLNezHUPwshaDmHC/CDtsCRzJNPh9ZFkmZUuYc
uOIIbnHskZNqsoPOzMzQGlCv2/lqIlo5YRVAChk2HrqaTm1P+h5fUJJyXrCUkxfH3gev/p3X1hrY
5hMMoMEogbZiz2bXveBy+Pvlrzmj8yc4Z7AGsA49NnKwR44ed5nff4BoPYLwi4JPxw+KJZBJJ2n6
LGeMX0ynjFJ7ALP2hdoVlw+udn482VjmqpHAQ4RuJTZIyfGj6bnQLYxxbQmkWmjK0I5fA1lHNnuX
A8v6yHyaXNwkwkD2Gml61VHs34v3QJLElHpQYWQy2VLMYKOkCRd9EWjFjLhPWOwtErJGiby18VkJ
pG3VmASSgznJh9eai3FC0wQXURwg+5WDB53R6maoNbawjv/3KhG6Z8HYufphZb0GuAqngSyNnEfI
8EybgaOtDtivmZE/8ITxGs6NLJZSeKrKbNIDE6AFnyD+m/8JNu9t16odq6N4gIMTEgA2xtwqTATl
cial8zeJl+B/TALZiS3iYXHgUiwFENwrF7MYrMgyaGIIMNiaq5annUjJ6gYrkSshCF5we77zp/B8
O5oqpf3zH9Gw/ziKjJR4F0wTlmsg1E4/0evc1JTf6+xVp6YNF7SzVOY2q4RLs/gG+AvwTtofMdns
0xj7JkSt2bWYW8LFxVU7Qyf3ocWWFDUhkD0rTp9lgGwOHo8IYrQ0xV+UScz7E85yep92cjrDjfEA
T4HxcFpra9Xn195AGxm3pfot3EEyRjcnDINlRG5kvNSW2jeL0OJa/HqC2b9Tv9E7aQuweHCATxjV
p1Mdrkwy1hiB+UuLhwpdaPQ+xlJ1pJLm878IOTTo4FTyTo1rq24OuJAJQkxlaRE8VH4ph+surmTB
8GnR8i4hNPy8EO2/uYuc1QlwAWEgyW7S9nWb8OK3QhiKQJIivDQ8NimCNEl9Q3NKAPLh4frll+aq
i1E32UKj0ZZVxV4av33NMnbK1jc2CrQ2wm10/X9BjPR/ahe/k/DLQ4CfuIXuozd63EIbF3KGD1zs
NrpsYtD06hHheXd1BIpSUt3++LvGyMGeY2oPYF+qB0iepK4Jl5iIVjcKbw4CxLxu1tcFUBII9uTY
d5Fe3mPt636X1O2Oww9LLxPhOizS0D7sl428linwBGJw4fGx9vvml/y5VxWg/jlqhNksIRFbBBx0
s/XlEQJs3bZRbWqQcF8Eaj12NOtmSp3ROccb6MttzYjc467yVCEDOgETLpRLb5i22EDdrPkVq1Y6
CsqmNBNWKG1VwfNVMJpGBb7zu4VcHqFjRtQrBChBSXZjwCc9uPnwkUyLFrgUQDBn4TScOPmNBDJD
8N1DHdjbI98woVUv8F/P9UCKVx08oyKZOuotO8f/nboL8mkIfvDlVVhdkmXmF5kkfGDNFnbAuNFV
QkSC1GRPic2WOLrTZ43R8APiAUHA62qb/bCxcZkj3TxZYakY3YFHrGyexUHzdlZX321qSi1ezQ+S
pqAGFzZGGDySJD7BZvgqmz4ntP3/niEfBzdPoqnRgr0o1lyq5rEHNrvZ8C8OBlBp+2gHbzS0N0fx
oqvx/JvWmtnNAB1cs4wusQwtN8TkCXz3CBBUhHvhsFNDPbm4Gf9sPYsEO1YUT9CnCakBqE6sjyf8
78v0m5bKALOMJF4Izr6IVKJ4P7P8rqSc4qSXaRF6/EMvep1PB1meK+bZiFJxzvkPXBqKg9Bt21yD
5H+sibMO/AcL/bWUEnzOFiek5iOJDuspMMyoef/KFQNzmyUBVkRGJgGCKItNa2UHHPjlHpJR6vbA
T3j1uw6e0LYo9RIVwwEKOe5+r1Gye8JonUMiRqw4FQNzX9EtrUPsFmdk2gaYvqGSBACdav0x6kPH
bVy9bcouU6KVaTbCZAbBw7Kk+px+WwrPY1MZLoOKBvpyFrFl1qEYt7z4jMp4RjbwWwu229XDzkQw
Oq+m250tJE/kAylS7Hlgepcne5ZOXKLm0SOzNVahbSK9fKDaeSjOXpxvmsoDzhqh+qmzcAqD8wDM
hrUIoWNf1B7a6fUY4p+PMphO15yowgIqAS+moFwHWaouuMTztwy5uQyiYD+WVSW3buMnjEMV2rDi
K2dCQHkJBCEVazuyqYuZeAJpQ/DnjiFyqlsahIc6mofLnmYwcWnTPeKlVxLIRy5fi7CMZcy5QOtY
J1C3GoH6+BwZ/yifFATlXkDCokk8B71Wc1RkHwnCckBbbe24KkYHP4EPPnG+v/Jg1SKUSfWgDvyD
D9G7t2rcS6AJ8qW56V/yqjCTD7C+S59D6u2hB+gORqDgFtR4Do3gIOFC9Fzy8HLpi8Bg+D9cg4e2
oSV2oasA8RAot67Y9pCx/MazpOxHzij1m9QgwVqpm0V4F5KJXUgjD163TAguGJGP3MgB5aQkMFYx
l0Qg8gi1i99QPKDlQZRVIzQ4Ws2+wfJQ7Sxw8GzthHtt0de8lxslQxVUVjpSeJodRPq04kR7qupv
VV3gksA4a8ZYvDiiSh1LsJg5xfzgbSRw8pFAvgPj5dIBtGIeAnirRd8P3sh3aGmy4gv2l37NYnP8
KUOs6vwUbRlqwZhqK+LspLM9P2FROs1iWufsyXrh43FUIJtA8SJKIHEYt6aVax/40KBVeT8qbibZ
EJbPicuPHGTFfwOQG3yg07xqYWZQV3fIsCmLdTZamJ0byYK1NYgrhpvStBlLzPxe4XdRNbdC6huR
oKDWqGlFnvWVcRaxBm8GIqWG9N1wbZxjOaM42ICx0O5LyeiW/khriIfeuA1wYeImOasmoZo0GOLY
RJWRKOmTcVLkx+U9ntc9LlQPFdVF27e5gGa8B6D+uiKt1rhl5UQZckeWYUdr/BhTQKCvbbZVglJj
0sfbSbwXpumCOZGBGLcmom+mNRfsuP6D7C3Rtph22JqJkYhanmWIE9mKXjGMGGswJDJ/lSMNBJej
4qJwNW7rqFT38NeTN6aOYTQyXIT4pqqQFyYeqw9WEmZ20ELDwCKhENVLsycE+9um6+yCDh0EsvmE
aYYEkuYiK7/0HajIkHoHKz0/1S6bX3sLpQS0YJTypyo+mdEnvYhYTM6uIh3BrTbCkBE3FffEDMuw
SyJ0ZS7K7T55MW3qbOWe5s3SO92oBxtVpprjxV5EkCN06ttx9/tUFgngKNWE/9176mvurYBDrxde
jvzb+HToluFfamEk+8NTlUdmy54Pp6jnJJ8s3RIY8G5Y/ZzNqcbJv+WqOTu+vQre8OjhllEUw4xt
/jPTirXya84+/gyJx5LdT4kCkBfRKn/XLSo67kgtynP2/bEggWzIPnTCla8Dt4ZGZEqU0+FCHvlc
sWdG60o3DdQXzubzPa7MevUewjw8ejY60ZIo1WTiDa8Ti/3c5CMbPKp4aajpgh7T6odvhKhyUE/P
YL5Vzeeu+H0wLx848xKArgBIZs2p3+UfIC9ts0RHRsdExyiP5xejmAf/GZDaOV1tKTtE6Cquv5j1
4syE6D9nrcko/+kuDp/X9bGN3jtEfwBdYlWlHwp2psyWHZyxRDyfortAj4va7zPmnarizuhgFyMi
DCJvfhOqBbrO2vMt+fHzuITDLQ1NUcW/ymej214CdNJFjBZUqrM20txme+1+iXwxco+u3+o09KE9
vqUFcWAx0qXO9YoPoTeRvL+I2sAndLtiKYebM6nEV4fyHBXzN09k4Ya/RI4dX/agC1bdutvGeqkt
yf8EKRAoswzBpTzGcs68y8F5ZL1Z50PXv+sMZFSY8WiWiBA7f1un1dFvlhb/3jdVo0l4WWCLB7fw
c6S5+oteTs5NUqx6Rk/oqkfXkdh2e46ZEfHLWSIvl+01jcEJSUqcyPvCikoXzipxch1gSaMu4Fox
3QCb5Ji4QFeMytn+DBdXH0f2tpeneLh6uf/oDgWzjfNY5gyUOJvqtCQ6xRM2+Tyjn1enrdpyCURw
oNoT9cU584f3hJu4SLwfiysQASxdFQlEc41EJKmK8bN7nrX6b6Fu3Wecn97GZVXZaTth61pty99n
Oifbn3HypRBshoZEJ+9jC6eYvP0Kv6ZAfX5e/RKcpTGR2REaegbAq/ZWYLy/ljXCSCclEBhv5aRh
fGBEwaWakit1VPZ2UJXN7rKf0j8ge9/EwMq8H/upyjaRwQ8yA+ySbNq4w3PX2dOi5ARCKYXq7mof
gt+6rJM0OxF0SH2+LeGwQhjQqe087bb6AL7UiqHKrThbl2I9VMgo3aQw5JWVo/3JnRaHzmpHrO76
GAF3tnNGGP6XLqxopmDCPmMjx1oKic9bZ7jq8FSQ5O9tycMztE4OmsMrUvhBzdCnhOX9v30bFlHG
p7u2VjVEx0Y2xHNQ6wCt6NZozRpCp+8gH9DvxQeNFpVR5gevwP+VfpuvuawvlPFIOI6tH4LfeaQ7
JV7SohKYpQtNn1sezqJFrRJIz1MJhNdRkO6GV4De3VNoX0rJuj6KCK89A0erIBgCZEg17aJMLHSv
DEdPM6PED/ELo/rsL1xT/OXJbGjY3hlnUGnwUgvFHvRatZVAMvY+/wpS25OZepmXM8to0yVGqy7t
rQK26qyQgYQHBg5ZlEcljvWlGgkIZ6XG7XaCVovqg+C40h8FhGic6HeV4Pj8MDnOe/a9+Gz11+ZK
eheYYTBkyQd+GrxaoODGW5/fb+Iqgm61NPnv6zUWnx6PUvYVeuaExuETOEJbcE2jlXh30jb2uT1H
icmP22wNUutnz2co6gDcOxcqTcQ2uvNwqZNsFRJVVxwTBhOyxIIhgGfN8FJ8eh3wJbPPmnalSHX+
/rvlvi8SSOfpnn+K1stbdvW+DGlX+XXfcIwq6hTaF8wCcrn4CPt/8gYyhJxGAZR1Di6qtGaXtIyx
JoWg01jPLNDmkfUgfCySI3BCRqOR4P/EFLOXZijjdQL3Jmx/FzXV8lv2+8DWjyA4Cse49GdDX0gg
nIrF8FMlwN6gV3NML3yCe0pHnlnr4BXD73tx5wS2YD9DvL3shx6ABOO7p8BlgGupO2dmH3yUJFrp
2EdTE1V6mReUuqlvdPQ+aifietM58RxekHowghWv3IPJHAsvxz9kMVbjWY2TSWXCtvYB8PqOC8gj
vKHWc3K5MWQvOpm2yFv2Ukcd/CvRYkT6sghGl9pk8lG4erIHPjb2fHvPEWDRKJ7By/610XTkTcxg
41BxSxJLJb7VluA/oLm503HM6c/Ho2N2QrM3Lat/0fQnqPh1XIPz3hS4LJk1kamqC3ea5QJtYnLJ
0rsS3Nq+U7SAsRw+4CvksiaMpJjdQDFOs3sZiQncxV6Lt4wygUlDhih12VOBG2JSW1evOuzcB1Ym
TCBNBfSPzCS8hoghxweq/7ffO/As5QeVHl3Xc0Sa6P2Fhpe35My2mDm11u6d/2eOn8zhjumpHrLP
PPja1YrRXJ+jaz7EPkHjFVCdEvhEt1APT9tX5Wr/64qkRJDfxqjk3+dezeo5QvXTITTTVuMYNBo/
KDV1yrK4+LQZgdJOPpZdDG8DncGjZHyZtU3M7wMJCxfsTzDt2UP2POwwCTP56sugLeGj/dR03nxj
/oq4ssJet6vexL1FLf4bBTH5A2NpM6oSD7uRs3GzjprafgdkyzHKw+f1/Wu/vnnpplPzYadvogX9
n2ZQv8T6RG781vvWcNo+n1nz2Za7la7qCkIG6VRFY/4N6MjmEay9mPJdQxxiK+6M1bUfRemzVHDY
4aSDQ4wE4nw4a2/uIYoZGeQ7P7awQ3+hVqoafnf38tBM0tel+K0yc718Ntefp4ZrZu0Gv3wtrYrn
hIHxHVKLv/NgoILdR69iD18ETD9EAhHFZITPh9RoJtKQAqBD5BHESZpJtyFncGyv1rFBVV4Q/Nzt
xk9k/RNZc2muJyz8YFMA/upRfRpD4HvC12t+9Qd8td1us1vsAZxoVxC9tlSctPQCQy5+dBjXo6w3
C2pQRfJGDeVU7/H575YSiM7B4KGodIfGEfMeXiQw4V6s2xwppujvZXBXJRANBYLgZEv/YwO87anW
b4yBR76Igs1dYEtSZ3hb93dKZb51yOg55tVeAp8MG8F4HL3WO6ytSfkLl0wDmrmAokhmqLyjxpv6
o+31w4SFazRQCqti8gIw87bEUF9qT2a+kmpSDkU6Z7XVUmW7+6+xCm/vpiKBNqfa1jMGyLCScutR
XUKLBJJTLNWvyEyq9yPW0lSLm5R6u9miRIq6N169rOxFXGV+CvNyCPOX/YQVAe8OzmTubDwFDs+g
dR/DA/9h4FPEudANclFlVCxLifDj96+Mg0uLanL5Kiyn6ZVthA37jXOsFko/gNf6/8/d1m12UNvH
ZiSQqidL7DaeBFIf0KZntSjmbNZFt1YfIBscbmwqknogNygejxRzR34ZhDI9GgeYmM7ndRYimPHK
COKju6CuNZKxACLoPYSIK6Ef7U3BhATE5GZLXhrVrbyjSbCXIFShDmQSiTiuwq7IHq5AOAlrJYHk
O5pJCYOKFLUmWH3txnykBFKOYC+BJ4rAA5riGeLu6s4Vgb05ZxLUrRSZ4EdCF1c7XyCOhIrRIeN/
gYcBCoLXJnS6XaAPUoUMUfraJ2LLVud0eFX5U6tB93PqZRLIUQG0ZsHuYixsiYlzO562VkNgFisn
fvWqwGNxK84J6CpZQz0HeBGisSxH2DrQPM+vUIZbw7kWjWfv2U1HcnKSbqFRy0WHgZ9Xj251vuX6
uVL5VaWp/m6ZVHy2LRAKUKoQipb1bJVDQJGFFOTMZOTa8oLXkxeu/KM+ftyzHl8UT9v0GqPe72ND
y/v88k2Ppz+Qw19dGOY5DG8wTxYHNvKudV+xO9nx8XjzkvDMHoMvpGHTmNvtjhuGp7s1+YGrpw/n
naIejkmG693Xlu3SCwxsLv6D3XUyxu+Qpy/1F+lSy1ulVwqBb2aLu4wPKcmknXrquGo9WvIvqfFZ
kOfNv8v/ePvk0Pr8ieK0PI0sB7syp0zdQ7kfsv89WUw6XHZHxX57C2KbgW3FMYAtagUULG1mtQK8
Mh45kgJvfHjyQ+7myh+fZdnlrXeBCLBhswcnreqJRkNQb28SR20XlFlIwpAWXDbaFrS92zrS6PdG
o5qb9j89cB7m42ZXybCztTuavYRt8JBNPkENNfrVDZo4K3AZ+7v4fkIVEoEFRDYZNuXoLD1svlAs
vN7cv5qXYjyo2BcZibrp8ffXq6flLup+jD+4/izS6nre7TCWhvPkzID4HNX7wpzN+gSzHVN26GIV
1i4CzOBd4kbn598H8F6HZiZ3BRAEBw7/6r6Z4jhY5Ty0U/8E7sDfy1b/7MPH1d5cf+KCyXOqTy0K
NO/YJo3HoAhB5b/DjTRLhx5MmmX3ykOpa4uPpzzm9bN7L6NOOnTfjCHbEetBwmtLL93eX3fVmrhx
AxhLox8Jdypx8riw+OCSjl2PprmlL5j5/hvd0cCzyj64Ws7s1Hk1Ibflgz86t/Kjiix555ssxBs1
hpbMM51Km7caS6BqygZz/zgA7wIU0pYnPKoc/s7w0qnCoxD0UikTW981cMdgqr94GNQXefRo9r78
iPns8cvlIcWM0XNE9cuQkVRI2EBMlu2gPxkX/fAyHpgrzgc42dWA1EohgJ+eRSayjp3OUoN/v/vI
IMk0GMzQAZBhjtBJ9eQOGzwultyWM8eGbzY9BclheenPasP5OPtM/yYJxIUpIt9b/IzDfoouDH9o
jQuzUKW7o/1d6OBvgjDE9RHi8oqmKF7cHi54N65IdD0tzoRzzahUKZJEtPvRQFIgJcpoNti+0e6s
B1uYYczYPF+Cv26/+5Js0QSMIUbx212ymZyYMcac8MggM32z8VHJjsuo52u28bcE7mqY00XRqutr
UNgIS4/1QPenuriQ5nNfG4exrA24+WsstGNO8OKZ+V1PYBpj/Nz0wvaswLuhhzin8Ukkot5EvLbh
qRYEDMMBjE8f+Vz6u8y5yj3uDLVDl3hWMH2GBXL4qXeXU2UmSc66x9dqjrqN9YYLAErFGGq/MtqI
+lB/WQKJwcVpTwp1760NuZlfnfjsI+wzGo1s8w/eNko0jJObrNY1uQWs77rnuTDIuKJYoMgpguxy
WX/tlAp4pbtyd3cx/5zaaVbn4B1gXepx2T9frBVyVUYkQ0W2PQi+eAJd5Nap2rda8gLWJyIkYjLL
e6kxYcDMF7D9mj9vSgLxBe4LLMX3xUJCcpblqLKVomqLm/mgyleB9M0G1Sokgyvlnt2ziM29wRLI
7qiYo16cGjcgNAitx8G3vH7vMAAIkBwgSXBJBOWt9P+AFVwETT7J55r7ufuxhmGerUtvJqjYMcey
9Zgxp5VtGCxDj0aIlUD+B5usvMgrCEx5Pv34T6UxMHozj9oUHDm1QGjRn72Q6uGCduXGfSObviEr
IvjO6awU1DDKblw1Q7WfoE9qwae6d9xoqBcaj7+XQNK35SpB19oRxFVjoeH2R4hAxHsPT1Mj9vCE
wS22V/+iSItAK+sRIehxpq0MOuo0MEAIn1oyDK420n5+Z1yqLzn2mR/qCU2f0AP/qhrPe3k/84MT
3Jp808VHgfB6uWYwxjFOQXfN/qDlrIUqqv4alyfC5yRtExLo0MlVIHFzq1y/c3AKujH+PWjthgsR
Yh5OO5DvP+EX+qM06Qj9EA4/H0HySpVAsiM+/rAaXSFhxR8olbiYIgApzvs+AgzpGtII8yrODBqc
ykPwAwFirUhGOtvkTtlPmS5QHUfgk2e+DDABBQZeAvmj1GNCakcrcYFAG/bi/G+XNPs9QZUzsoPZ
4rmVW66WstgkxMV+XYq1al+GPYkrJlfLS/3gQA+wV1VwRmd2Ot9RaM+mI8zaYSiO4d68qrGAal5i
M6jaRgC3eL+XzX5qNMYnREZgsOIlIN6UQcCJF2rvymKzzPOBtppWYWyO/TkxgiYIumCGEndIIKzm
6Ctrphsg0e2qM94jFU9glvErtCu9vOn6v9Mbj7NoGAJeZEiJLxxatGlqW61Rh2Evv8Tp8v0mqqjA
T8Pvi5FYFxx/d8+qx49oPOHJvbJejGnhHL9dX4hEvSnqg4frRk6pc+/mE/0EQDQOKaxsqbzyYUGK
KZWphNFoOxEUyg/Gfxrf45xXyouqHj15N9WDuerBkQJe5KcMaGNErMB04LeHs9BWC9e7Wcrmv3Lh
W6k15BivS0FxKenKFqGMg9CWIrDsd5oggqQr4uyHmVVRgryWNplb+Y6jbD0XTrQsTkyprZ4WXlOt
v+tBhE+I8IQUuF9f22c15VvLYjAffrTzs9Ip80XtkKr41vv4gQOaIkelG5wJEUlYMe2FXipfLSWR
uID8xRqDMu1deTejgjYsUsS3GuuiyxU49LMA/va9T9kdB5+PmSCh/EoPq7YMHUOZR629KUqWRpw1
W/oH2+c14dSAxzuy3WGnjZc5iOx5p9e6ygBSAjmh1JasZtkc7Zv++gfBBJA1DUDpHv/wr1Aa1fWE
GLyX5i3ca4aFitQepsPYlQnzF8bx4orvuJGqe4R9tjoqUcM1pg1cuEvWrAVikpFcY+Enjs80NJVA
hHu9BrWMD9jU5QjanSvdCYnqwypRo7AL1cu+P6p/nfPaE1OMvd9vMrzLH5+KvdbD/SCBHDR8ELRB
fpHicdYa8ZfuH18O1cytVd70zJC+IoFQr6VrKTQ8oDHbB/sjRU01KVeWJyjpG+P0iWh9dUC/hxvj
XFNe/kS9nkL0zZkdd7I92pcAE8y5G13sfzOKVZ13uPzi3nLvS4CJZbTdnh/y5AFjbRIIxH3tgozX
/9gf8uBDcOs4dDYyBMEL5LUrRxtC665Tfdz2q1gIGa1CzEiAEjvXv8RShnat/lJ5dLUEYnecxs/5
eKLhTuGxpiyWDC865EOuP6hKixtpPjZgD0pn35A0QLbeV8BM5tQ1ceEpnn40RSFD072XMBTy+3tp
VG+I/ETPlMc2col5EOmgRSgW+MkwtpmLwNdFvqJ60JRrwpjPBA75oKBKcGxprIt050JTouuWdZfA
0J+JmIZ/G9GEN03dxDopeW4L07Rp/3eXt46Ojy4/xuWucXJVSBXLd1Vd0Yh4hrtbVK1eQNzY/fGa
aSahUzs3sv1Ajq0fihho+o0PslB8W/FseSNaRq0VHZBo+wx2jh9qXUeIEMHEQWOYldKCPc6MRTXu
UjtJZzc+O38dBm5UXIQms3TpCIwgBd8/ztQX8cA1+2bS5kaemicG6D1U8w+VRvO649nOhvDq1Rqm
gDD+kW16Gg1HNHC47fDNbdB0Kja/LKpGWyrkZyMQxzweCoBYpsD5Q9OK/Uaw9fbfKesAgY+7JTwk
eNo+tiaB/JvnXLgzuvZu4qT5AA5ZoCrcic8PdqpM30PxplgNUnSfXLp4HJdLiLslHkXwKjVMEZGo
wFA+yG3nTLl4Gg9lgQea3j9Z4mX0ZVhfJBnnn5iFE/5D09wJtIev3ZqWi/F6xpZHW29atminUltn
hZh3eWY5PceaGnGJ+tp+rQTuqvqvfAqMf74qpfZw/IcdST1iBrFB/GxCGgZ/FLetRGCW6r3iX4xO
vuNmtDIy9VEhM/YceLHgQvyQW22Rh/s5d84wq70351nNTAY0hvsgxIc/ALXpGv4NGJ30e9nNbA48
kQlrPnL5cj5AD6qVQHZ5Jtknj/UIPuyJkwrOQisBf3us82z1S6N7Z+p1cEdXe2i2eWbNzdEAixWx
LWTOX+VRcJkHKSwEjuuJuptaGykIfZfSd35zqx0lpKh4fj5i5uvKlehY/z0r2hbNpl9N3urzo1me
4d4nmrgljydvsQ+rr16/xQM4cjawdVs9euAJSqGP1ge0YFpJPJIyVD5S3K7BA4qtRwLy1CNjRirD
e0xf3O/vvPbB8B6hw5lleu4OP5J/4H9n/yxtelmYimMzg1NhfwbtitT/o9N3/8585uT0/OrIufWy
W5m20ciqyzSj7iOATmy8EZ+015YfGyt1rnqw2I3Zi6nu5+8vs0jD9vIzr7z1s7ROGIVQrsOWdzM1
MoqHnfjRVWNX5hCtaCTTPXGxUxH1vA6te9yZwbRQ6aSJWZhrtuU0o3+v3uXDVZERfo5ZH0CH1fx2
dYx1YSAKdI12IIh2aWeY2QV4BrkYX3qa/vkvjLPQND+OVN0g/GF4yngw43ibPGJJ0dwePWM9M20e
Mjqezm+5rXof9T/s2/0ZbK1mmD9/59Mhp/eBJqWspMPd0w4lxdwtT01vn28fYMt/OxXkW194nXU5
9EbaV5eFnXOqqUfaizQTtM4GuV37++NOg3MOu8pO/VlqTPvYkPxKR7EU9RE57G7zt3qSwa8KhQvl
xyvU0Yd2/x04wrZyDLPQ+Gv3tkMfPu5IxvmkYzwkkLEoCeT3MSctK7TvcwbtDqCW9/F/v4BDJzIi
NJ7uq9M5XX8NIsMP7l8sWtnxgrmyu5KEUPomv+MNuqvR5XyQZvNda2tbq8dXz9faD7MLVyfF/915
85hzryKVoEfhLvxaanWsoLqJEw8f/AbO5aD5ZMSNhJlpUYeJ9vnf5OW0PD/GJ9sLTcKTAj5bgHSS
U422gxe/nYV96sZDF6E/AZbLqbuVMMoZoUHVuc/uj3kL7Fl7I2Yug1xR5g3tbeM8RyrrVpNSutvU
H1/eopfgLKVVvO+15f4nR3tCdemYHXoA863qhCod4FUmNbU3j6jLmqaee/So+y/nLPdgxy4lU8Xq
I9ZPndPsPqInbxxgprdIJ8g3CcR5y+DORI7N8sSJUZPibKMeCeQ6gYMW5zUPl1xSTc78QrmZocOI
9lh3WQ9+2xDvqa2L99x2w9qO6lyESXJoRomP2Kr/63PKZUA4IDX7BoRa9iOq96IK7MXkgbic0b5B
jRC7UPlW1YD8B6GCvXhcXD+JH9xXG952Y8zH64qWAI2McMu/Rh4av593obWa0MkQ6qq2PTsJIFnA
c3NA7XuWw2OefuPlZQGsWVDs55zeK2To3uuIhZcv4OpNB8U58oHH0+wIpoQOfuVb3HJpQ2jDA2g0
Up+juOk7WiqovxT5cupBlULsD6qU/MQUMxAQyUwJz64DXIcDUZkrEcoM2qf7d/4HcoJ+rEQw8b82
5FtIB0nb3llfheMDa4IdB/V+N08/DsXkZ3fTus0WvDw6cHl+bW2dtcrVveDSV6Rqb53nSvEUb3Y9
+doxwwZDZhurOk+BC/YXet1z+mEwF9XRUHWpnc2Zki+wfO9v8ZN15cawoWJe4Esfn78Qk5/dy6oZ
FMxCz33w7o24gckg/6Q4gw3mDLbyokXdw75oAbA7xWXQ8UaB2tnMpPWBw6qTTiQ9dyURdJcZMQZb
cre861AHH/n3lD0bJ3TSTzbMt3PSPUCbQWhpXJvAB72lq0YZkAm6GLc6JZw0Lgi0Sr73QeG2x54D
ocLRl+YDk9WoRh5iqQYQvYkFqIMHjgaNx5m3hDLmdPI3C4yoKK3It6cHxsPP2mJ/LfuAKlqymh2v
PAOrP3r2Dn6FEe0IGwdv05WXR9yZ5B/RykujGdGpDRxjaGTFh4K1mF40uEXlplbgxd/uzrXyCy+8
jp+n4meDvBy90xaCkx5fULNNFPCNTQD8jZTLmBHDRbhR7zVuSWhOSEXbAuxQYExIrpYHJTr17JlU
shhcTDDMvDGy9Ft4bHDjQFC71mPhdvr4FPS+ENpHbXdwml4x+Ccwknf8R4PHN79VZIQPSApaT+qg
3H9S1nFQgH4QGzCzCjzLbeeywCO35ltUCoIni8mIu4F2HfXTyI2SaR8tsoYjfzQmvrYJOjf+5O6U
UUOaIC77NSN+s7ISVG4x9T0sHns+x8Vr4gK49iDK428sIenWiIbXinvtt1Ru+f9XcbX+EEhJKJo6
87+nMpGH989WDCWQVmulk+LnGaZ8X3OrRSS/jtYtROvBDNXAo+SQ6a+K9R0RR0KvyFGkwtQinqsO
FtppTTt8ahRqfSFF1DulCNFSrB+rNkPYfsI9uZ2qy5JABslx6FMJ4Zvbid9Cn61IIFDQthdGGJBm
9rde6c9rHugwG5NPipqBUQDjxDJMqfR8utsxqw71cEbo4gf3KeuePMVU+BVy9HbjuK4EErf6rOiy
EWw59RLTrBVZGG159lh8V/ooJjj7wgXEn9I3vHkmgfQcySa8MDypkS3qPzE5iGIi1mUPrCc5NjU9
9mKYatefJnyRW67YcLEtjgqt4Ri61WIrKH99hRI0jK831Kd0KV3u0nlYld48EpM++THIJTl/HCb1
p7+O0N9XLyhmCM41jxd0mS/kmOaIAkNMr1QO7MjhHxD4Oe1ac/qF+R5Va2ubKLSr2SkMo9SnCxZI
ziLr95f8S/t//R0c+dgofaLaUsP2wsM2lhiglgQ83D+xgPblTq121QqhYRHOjYpPHnrsss/ltnSL
nOiwCcui9SvXjBgJUaWr5rAcO0Z0/oajaI/B+l918T+97f/p/a/2WHyF4BhLQy6AgAKeXyjAnv8z
Dxy973q1jsj3ckmUum6f/LbeP7GrfKDN+1ncsSeurcF+DLUlwe2XBQMDNiXlV+7uWXn2VVzdaLz1
wq8Lv2tCYgB5BrcWHNHpt3XEkN8nG7UrKiuLYbnf47XVM7WHTC2YEsiXMz5Nj+muFNXaYcO5rTV/
8+fpNYPP7MzYHjKOdr/jbeg7S6JoPm8QFuz/JBAFaLXl0Wd9g9EZtcThJ6LLbba3sbjm4fDV3S9q
1IYvJR9JLfkjrs8sknz0gLaHmZxNNos0glMstql8spo4XUur1rDTLKm+qxIqX9KB+Pz5iBGbPluU
t6uasefCUnx8FzIv3ME2YsqN3mfHu3agW1kCkWG2xAz75AzfWlFXbU5Vi91Xk/vn3rrfH/YnF5hI
IMTeOIbgmNXP3GK2rAGChY75bZz41drgVMjTHeFZL/5gUS6jUYYFVfS76o4+RxxSSrRPRTC4xqIG
C5Z7b7queUgCmgn6rkkt5OSfrRcRvEdnWJrK0PS04POBQ2cOmxxeh4VR2rZ7UCO+H7j16+BA5ILx
nZdw6jzpISn0yJCHzSN3g3HC+enAAZW1rucP5/j32v+UQOZP5PCRWvPtR9rabV8onny1/+1G4SLL
cR5UKFymz8I0lwIJOm/N2dnDv1pGFBViUis81c9CN9AGLGXr/gWDtiA6/WhA/IfjXw1ciSoa2vNe
+5hSJiuPZUwd0zcvUzAwwf5TWZBvSqLG6h/emH30jnb/6PPOC8cSLjf9N8CV/5URvHGHDN/i+ff+
8C/pejtQc2fToDbddSvhpxeM7m24Ml3Lcvuen3eK0CKUl8+ko6TW0CT6Lab/RbTSuUfaWq+UzfZG
DczZSiA7yb13tppgOf2MrPP92h9axoZMIq1rqkN8MhfOzVBKR7kZ2biGGF4XrH3F8DFl4dSRlW/q
8bxFHGIZ7odAcYaZ6TptTPHDF0UHrZYdWjE51pQATw/BIETRX6hFTjZ49uzvt9l0DxUYFMk0pJa9
NOhYFTCdGtd/Cs2VZ3L0Qa1mjPBG0ZGQjz5bEm446tVQCW0O7nrLvOAlYccLn6vLce6ZsBdHqnKo
kXBQl5yqmoQoXPCIeP5EjqH5zAlUCS4eEln4l1Yv0DjJ0X722dc4GVJzJW8nBfJn/6Icf/i+9KqK
PXFpVW+AF+zt7iXm+KtKXw9A4cStYbbvPKn06rYfP/Bbn/pzrgF4jxbUswc+I7rv/412uPC3EyPT
3XS2QT/u0taN9EIVH8XXx32OzaXhgx0wQriP5/AoDUY82NFq7FkG9mr9lX3DqURcBtoojDlqrX4Z
c3g6vvsDZmD8hVzTC4919xrPdSNXteYjcg01SNUgQs16ztGLzo24l3XpjorPJmpoRJEa3DfIWxPb
LLw9qNtLCm86bg08LDB+4F5LO/mi6O8ozTtpZ5eNc3e8UQb6O0I2Tw813F4y1dXowq6lGf1hkHmZ
1vqVitHCVk59rHXvt5rKvACHJwwUiFdSyWi55yHV0+P4dSeAU+gitaae76MDy+xXttxg7G9WeSKb
WmFV9zlUPet6sWd8Z7LC15E1n1uwKJvTfP37W0hvsF8kEGTwu/uiyrcqav7P1JqfsI6pr/pM9Bmd
WSwgJMnfNfWJ+eB8Z0/W+XviEf2rEkhkS1uJ4U7DoxdrhchJYR9rFh6gdPRp3rP/Mq3UFX7lF4UU
3oVGJLwekJ+P5EY997ii1CV8PpCtYv4QwHsKVtSJkXzbPVYcnNp6VEnriheL1Tn2oK64/uqrzJTN
jh/v2By3lt5+Yu34yXmq5fDeukPbHPqM4AaPzGfXhATOvcqF027WpdYGhNPJswayfzKRcrnOzddG
9RK+oy50VpxBl1hDn9fWFOosqThMfCznIkAeZagg6qOGBqFrf2xpVbsy9lMwwiy3qzPjz7F3+4Fh
eyBoHrM1kXNj+E6Gw7Hu3jeUHRv2OWWgoNYs3lmU6Hb4uf+BP8RvgMji1jFDZerdrWzTbM/jLKeq
BRvZHv3EZRv1Gukc+2lZbPxjzHGkuq9Kl7UUcnAJHxp86MwHgboq534T4XfEiIIaWHH+X6pI+erf
dYjKPFLTiGF3o8w5z50eiJsJ8EquiNHl9oydZ36F9Xlt3nXK7wLBTvavpfBLcJDsS+ioOwsw0dd7
2jOnlwQNAeBPwYsb+TgRVXpdw8RjI+a993fpZwwDy46+n0buJWtGlVzNn01t4I/W356jiwgfJ2pC
JjD453ElE4XB/v7L0ktZx5tVPbpq2ypIYo9dYHrCBUhWaQmmo5zqiODsxNK0tpejS5zuX6h27TSU
WbmV5WBseOzh8cCnea+n3vwoPpNbPvVR1np/2QHr1RuksyiDzq4Tr5SuWDu/ULU5lVuy/U2Phdm1
qR3lfxSVHROgFqAF53+NfTzKT32gY0D02KkLP/aS5H8oVXOFi/mctyiymzoK9cQ2/GjQ6MK0/iOB
1HHHVGKH0N36t74OlzeX3X+8rdZumevqGaXvcCqoME5u1S61TwJJXx57Mwb7sF5jpmnTNPwssxcH
XfzzGxkDfSiPED1dezEUBdxIVN0r842ZRp9dYBbF5iYgdA+uA+MV3uc+PREa27bdKg1+nt8X8YsK
Tf6kI7LUbTxAEdgaVmIlkOP2LWUjTvEwrybyl8p0vZMuDxw0JyzKKw1PdvGZm/tNr/9S7clVV402
j0A42/y203Ya0dGpMSy44aNPZc08ppxQkxPPy9WPyQIV2PczzOPpxBf3BAdVkRvkytQg7qJ94/CE
flbQnxabHYuFDHplqUBNX4QSQQMso3hYmUmakvzqO+OhM6jN0+GZCqDWXH9+bHEwYTwns27VdW/U
RNMACR3Ui11ReR+81ZmaRUwS38xAHpJO4qFKCQQeJBvPW9ELuSSBuAaNDJWT6NCRK+9pQS6fzAll
81x4QLWvgGI/FY+pbFNxU4JTnWVSqQSydNglkNFa7ZY2fBOKdfCcATo23g3lQWbrtjbrqQcAK5TC
aK6loIgkgWSl00zSZb8dT4y3c0u+qnJyGMwDYsWUOQNqrh1xIj4v8NLbx4t8l1mQ5eNR4HX3zGce
WrvlA5bih+YVznrAGv0J2S2lp5otRful4MMrPrq3Ycrkr5H3d6zNb8W1o3XPdW1BPGs13Ulh+D9I
D5rRR908uK1ltZX+mc8pIdST7yZe0Ovqfi2BLIj6ppdLOF+zr2LnLp/Tvu8v9ErNvPrPYOmoSPYu
+WNVjTv0zM2pT9nVR21N9JMeWvhUTAjqLUkN8PuIVrJClS7V6d9vK6/MI1U/Z4NKc+HVSkJn9Dds
ut7Fxz/KGPOKzud0Dhxw5RrFTTjdviXuqykiLn+TlUD2EbcXHTEOnfjj3o8PVLML4H4xBTMtQw2u
9FBPm/Q99Ye2lkqqJ/4XLjhobI/c6zah0+wyaUnh8sLNF9l0tYH+2xLI/ur8yqU5v1FDDTEQO7W5
hBptZxXxp9rym0bjXXO7UqLjeXnAo7VgO11Dh7CwmWje5q7OwK/A1/pGhqw98CBE1Jms26WIXLk4
rbZWZLM801I8/FXddYhxwk3OYotpQnYt57UA//n9g6SoYAfcMEYYXF4yfujWGX8JxHdERa0tUejc
VLgL162TK+dInHTzHdGtqr7vkd5oRH4d/92EveG4ht5jca92ZkL84eox9ct4V1X3njCNXTAWMNN1
fODlGvFoYFUeuRhxgnL+jXHv2casxVH9SQ/4qeuMwGSEgQSyWaC3kPP51TxvsBil7t26yzjHcYYI
EKGR3r+pqjulkuXX9dGbqHNv6lra6RT+H7/9DQQwTpsEsgL8d5T+VGnH82oDmqbDpyY3ZZY/M0BM
EEdc+XtU93e8s8ngwfp3aiEc97FB0yM4GKKp6YBy7N+HdIAYu5FA8CBmZO1N9U+kUfXhOOkoO0kg
exy23TpXOrxetA5EXTNtmZYNEzochNjPVhjbDI+Ywo5+a+PCKWqxj7TPhUCXlRqgSQbUahs6ndqH
UwGyzMGizXrLMZgQkZofL94ioX90lgyEnoonGYcEPoT6ETpI+Hn267BP69XHhtIKeF4/H6F0nR7E
Xc5xbrf88SHObk475070vJd8emLj5w922uWZM2cr63495cnr1jwL3J4RNOhB8fJqrNdJRFKMEn+d
xPBR40+LiBsxO+eqRT5IZYZBRnFKPFhv/uOo1kvzYzmMm5j2xJ0fgmFroXLN62OWik9mWgp5zg47
Xh2cMTMm/oi/UKnQ/uenTyO6qeNpV2MDi7+Ih4+Hy/0+UZZThh9QbwdoiuKWsJikF7X6UV8ub+um
JFt8va/ade39FOnKTTdnxEmdyatozYhf4+BaBI5i1vb1hfxI4vCAnbWPI5wfV3+bZb4W3ElXaWhq
aTm98z/cIyWrxw8rykeU8PZL/fZSe79loNZQSBUqxyruvCOVUBfu7Zj77+PvgX41SH0ovaa3+4uD
dcgb7SMpITgVj4iIhFbh7ZiANNIxnNsUlibltdMpYbYYAjnk4xhFyA193b7/94Uz1QvaSN3vYXNE
fnpMOa8yERU5PRu/F9DirAXowg2JRTxfk1bMmfTJ1YufqsS21pjG5tQx2RNfQ2JqhQyb3hW+Zi33
5WyEMss5qkgx1TiHsND63yYcVY19WMfJTbLOWmpMUEtHzSr7nQssguqv5v9cfzRtbU+9bKlCDgll
AiuGt06tnSzqvOW5VfX0j+5aXFvMtppK/HXjBhwnoWtGx1/sbSReYDZOyHhA3zA5rt0cXMiWWKWB
/c77cFqiuK++brLXZn221b3pge5JEcE4To7qdSbbV+XHtIC9GPK65tyK5xmCqNH4f92hXIVvH3/L
msuQQrgyz+jtXj2C9uWAAXr1/C1eIWnVI+8ACvzjEVh2UinE3H8x4216Xhk+mb3ddW5P8bM7e4Hk
lrb7f8I9rrbt61DuB2IqwerrD+HfYDbor+2+lNfnDAKwFcc7KxRnBTH6/IrKQZu3VRy9BJjodTqG
e36g3pP19fxR/GhB29eaVx+K83cs65FpznHrPq2FdpWNRfeup6OR13cv6dXeHa42aM7pPXwrNmJV
/VvvqIFn22teur7U1//Mif7c0PImOtcsMseMUuUaoEh5Wn3E9vHzvu7v+u6//9RjEeobeXXY5JnW
6rnEDJfew/2zoI5juFnkxMLFzCeHTlzSvoZvv0w99A+5obi5kc+QqkHx81XUsN5+3hzzK+ccdtjR
I2BMEaWwckk4Wvh38qbNHW2xxWev+j4aV0f13L7vvAdPbkilZyM6cGd+LLgj8gY728MaMs0tXLwv
BPUmGZtGZ56wRl6g2XfY33PsbUpeElTL7GzpPr6CQ7w306oMcLl3thtgL3swQ8wIuxdqIgK+lpu0
8t61LT0oNXfxRaR25WDWGActeZVdHkLrpVmn21ZjGWllgtEa7dj4d5ZbTS8k3EZrwX/0b42LN44Z
qYuKdQj4ed9aAgE6/97yZD6PQ+1sgVJraqGNx2LvN2jLf1I9/+qrojTxxJmf+/6suiK///jjv25r
H7FKz4FmewY6gn7iMNkikt/QCZwUdZ6dvLKk6jBaRY1yZwPnn+o8N1/+/6ZdR6tZt0Dd++xolkKY
Yp6bl0tFnk6rNdxv7nP4qkd83ymvBQmE42zeG1whgQwBX1RYrX3261cRO978ty/DcraJg8Mt3kj6
Mlafb3w7wuM1PDmGZUN70qXwkBgPR8hTL5m1fFW3WD2qLB6w/4ryHIOHNxT/7ZsBDjwwHb3c/uAB
Y67Eo2TvjXhozV213dMdZz86/+c19IBojX9028XGrZX0bzkEDqUTH1QfvdK57JUSUNUR3X73rK3R
j+x/VXWdjM/OU8uSg50vOI/Psu/W8eFONYCfyaLobJ6XDMr7gPBkoZq6xft0XeEAWsqE/uyh7p8C
P4y15flU31cSyAEE0+422dTWH9AgT10539x06/SQfvbhv7YLgN0Fohh1S0TDUo7tVaxQAtFkf1W4
Wu15kkukj72XNX/mdfAGNtYrrP+ZuhGPOpm1nmnPC3b8HONX8K3J2Hmlz6inEffuiqgyf9hw9a7/
Rw8D77ttXol2jLM+GRvkArmuA78yrFIenKAXH0CG330MuA9FHGMb/OZ5c1eZmqgBlpK5yvfjI/oI
XSDyj0+3A2M+3pdAdhPKfhnxOBX2z7Orc9VeElctD1OQNsB+T3g7JuxB/wp2NKPjQLTPhM9KpTP9
ZOu/nqkvtDzf2iqLh848SU4+dzN4ArZFvBuXO7wY41wQtxGoyySG7bu5XNujvVmAGV95YNHeXKU9
TRkoFHCb7jYfRPrRRE42010uQzc0LBKPvnr+wQmWI6+6+g2QiSVbY6iLZdhsalwOZ1Ztek4jWpCH
DUtmRoYS1sTxXy7GFs0VQC3zFRVDDWov3Nj1sKQz6reji4H4nJ2xQmTYUlOm7Y+tbRmH5k7LIdyn
9lbH4KrjkN3/dKWJfHIWH90kIh9ytyPju3CQa+YIz5hRcypj3Xiz/yLooFI41btghiBlWjvJ7+vS
YlmpGys7n0/IcNJmKdtjsS2t4un3z99hWf/r7mWth9ccX3Ud1RCEzOQf3mvaRW2SgrK4otaouvxi
z6ztGbf2dXC95FZpPmxpomiQrQRdt5zyjns+F/pJTCu0XwsJvhzrceHBA59MU4vtubMpT8DKrX9I
yavVLvrSyJoRluvu9nTLOjSJUhRLnH2qn38q/SWEhKtFfM2qlQNqjTW7xCNq/nEqEe3mU2UMcBvI
W0hnKQxZBzew9Vc2tx+IUgpyBbxb0ece1ED9xJzjzV30kS9B1x1lw/cEq/xfR2cd1tT3x/GhIhai
CKIgIF0CSoPAMEBSukvpkdLNBAnpbmF0xxcYjJ6S0jFyYyMkJEYNGDA2fvj75zz3j/uc557PPZ/z
eb2fe+5585IlSIoK6/BP5t3K3BJaz9XIkq6Qk2+ezpB/b9mr9LBXi1P+hwZIXEPN6L2JMk9LQcb9
PG2Q/HX2EV5IRqD8S52vWubUx3JeUmPhOx6xrF1LQyINmLccJGZ+h/hRh87ZvR1RQSq7bcZVVmMV
rSTUPwV4RL+UHdUK74GU3c4yQXBXHXXmKfN17jeFFW5J3az2IKy1w3TZTrUE8WB4azOZKTz0GCuo
iPBkcIBAXTreM7fFr6nB93kx8d3aFwDD/cUIi2YE15Qq0CFl7MSAPzsMA44sOwBGYLHQIZXjUKMB
Hrs12A2sIetSoo7I2KP+zw6eJYr1MkX1vgPs5i8mOn0kSKlMsBX5jjooAjspD4Mx8w17K++iDbcq
JPy5waj2zqap5h87jpUCXqvXf+gX2dEdYNphs0aBqU2ZNC++3tJ3yY5PtSTh9CnAMjETSGISRXAS
f4OzE8YKsngJsIFyHjxwujmr9ODMBqmQMEQkLu5MRnTX/tsykfToNQMj/QyQqtefJm1CPfC1YDZw
2BUfACVMf6PszF+O1d7pZUkzNJQ787ZKvqDVQ/SG88tiulbmbeNmNF/wrzt+QscTDErQPiUOIzb8
uoUKSdRVD4iIhhjdiugc/0nUztVachgxT4JJMTOYdvFXV2WQfckAuR4RUgXaxxd8XislSbCG7jqG
1ogbTK/OCBS1prEzfJfQ3tS3PtDBbSZuLto0PejFSzgtntM+zNKpcA8spTa7BAh+x+yHXeDFZ2x8
Fz5Q7P4J1n4IG4pzsJiuxmJFlWx0Y6IP0r7fuwScV4ZCD+SJRTw0rr9SCElPOq3LWA7uF9rbqL9S
TMW3DralwC/u1KI4k2AfLgFNKXGlK5K9I5nmK7CPHUFY+RU6il8Y5gBIG9fZSoupun7ntJWSs4Gk
GQ1Z/5pSYJW9/sn4L1fOT6FBW0LNOkxzVRyaZSqESaKC5eyH0g2CANU58RLQ7zUrrvc5a/VDnTQ6
dUzX/70wfJ+v/xJwW3SIU+wJhOlqLPbVZQO0NY006RKH+902fgHT/XN38RnRQOCITMCVymRs5Fgx
j3yLPsOANtchGTO5Y+jC3QvgPsXo6IZBLrDubHyH8PQN/fuOgJEpH6T5EaPkja8287LyMj6bJszp
HmXD73YYlUaRjcTECiVH5ywe6RhbX5kOB/0LSaSMpeTdM3D3oGcaTM6Hb0jzFusfYHc7N6O9ecR5
jNi+fd3viUppQ3VxmxmJzbRzfeaSv61xxY9k2q36IALrm7O7k5vn/KTiLyf7H4YDfiv9jCduddrX
FKwpT5ZeRTN46hRsFDJrWIfL5bj7IvZFxK7AefUKowUQy9CHS3I6FJhRb6sz3tOjwTBMUZ+9aNrL
NU8Vu0DBl3QFqpezqzloVz2SCRj9fRjeqP5EfR5hPsSaOOXT0PN41lvsUa/3vRW+z4dc5sI2vJLH
BGPI7XnD6N44n9XhhPP+rP7mfdPpjoRcpc+G0imQncVDhOVRySaJ2r+NvCN3nc9uzSuOFnxmN3QJ
yJvY2SBggT3CDu8P1Kr0pNq1Rp2QqzbPBA90gfd8slAqU5a+OcOvepY6ZV1yyzaZqJM16ZxEILaw
+v5MQZP1NEQXv38lf2w7xupjWwyxvfGkItR6TEXxqsSgCZ3jkRYH7HpSMOTK4hcICJft/dRosuUg
Nku+vJ3JoxaM8Fv+fK5LsV/chkEhkWgXIaW1AXg8T8Va/7cXvZ2Fq+1bJzJGurqGQHTxkKA1HAfG
5o+UjQB70x4jrdIOI5G+Xx3jglMdpPrN6tXZ0W9c2f8z8c0vTK4x3p2JTQ/lN36XdVzC755y9wmh
bvcYX26531hkJFM8D21ua24GXX/h5tQVny5qUp92kbvzeXvts0mIOlOm1dT7cViin048f1Or0yXA
vm7j4M7T6vaMHP5lBlXrTi+KvYBFrO7fAC6ZVZgTjcszDfLl8xAiWYnJqSrSBBndZLeSeC8Wts5C
R2h8VmMCOw1c9MV+2eDDnCYMgChTi2yQaPZHTujms2+nsXbmPrv+vW0o54SOBc1+vkqxL6nuPUGP
G1SGjAMlGd/121cw7ElCTuEPx5Y10Ke8/j7OqFVNJ4ZdtvLDUUn0TDwGDvLl2vP/NaoT3y/+t/Lw
vbUKuOGp+0AEI6UtyifJ3+NwNRwTWH9WZmVS3+GZyzzpJLAefpuf/x6zTU8M8M/f35ajO4Fbw7K0
IXd1WrI8g22zdGPqVxOf9tMG1JO4hK7gL2h8+N2KP85X5oDXNv3QBOw92QDRaU0Di2Ynjt8Pb1UJ
FFZvaEtRfOyzOKQDVhc/DRMoLegtMSlZyk/jTAQvAb2jNtrB3lqLV4r4FvEPlfasoKficpRbMIuJ
wvdsBy5PP7pY/kIpsfQvgyHvXB4rCyyE1742K6m+BDwuPR3YZN4vNCdo6/oDG9bNG8h+OJ656rK1
tNx+whDCgmn3qFWJ11IS2Y6el86j7/2s8vJm7xkdPtshDqGpVpwpDUNy3HkpdEp6pGmk2YY4A9c2
2+jm5vs6CCKdipJ4vg4pPT2rB0GQ3kGuOdYuonjnZOkmv1nT/M1Wjyym/DLTD6zZDtAbb98s1ARd
EcDXXHsV/usKSdt6yR7xDhYJUFA4eybFwf1SRj67Ls1VZ308+ND4ERN8RQLW0ZzwwtnHJOzGftEl
wEOnYQHdz8rRh4PyGKwxdqTBXNJV43URWTMz8nrc7HHWVlqEvnv29xWZR2t9Rry31y0dnmnyFfhG
RThCnv+BKJf3Vth7w/c4mPcPQwjmy0JcLdOsUKXcPoyEFaH6xKoKctQfDWyfP5aouQToNkIj3jc0
W/FyxJmsLn+U3UXOkgYRZg6fT+wuAb4lImf9Q4eCuliVuaHcUviVDjiU7v6QhtpEhg1TiSgJpjJj
XJYrymlGXXGCbff5EEf+wa7L29+dtG4zj6EaHH23p2FXYtu+uW3gs89aLEVWl809clv9hbU1WMeT
7/m2nPm2r31fF/K2H7rCtvVrajwp33J8sBSs24Ts2U62wu/ItC8iX2X8Sen+/PTOxprwhzl/BNTJ
a3Bb49o6g7F/KGL3xqcfbOoXd9Qt9IvN+YiYWkxc4iXguQRb8Ri7A2wDQ5BV37tCqMQj1PdZ5gXC
Stu8aEnsEbQlrg89MpbRZj6MrBAjETtd0r2VG2pGHs0rD734jJ7yfThav+Gwi3uYvjuxU8v0qaUH
7WOp0dgIy5Vn/xjz1vsM2KF7M9LvZBuYQjCwuudltCuaY8YQKzao7c80x5Ie2OKCgcbJmqefT0Ow
WPYBSymM8XcWBD3nt+vDuKtouGWVdGx3vlEQDiiFIEH6uDfreRkKRLFwF+LNpKH3HXBc5vvYtYBq
qHdNIYmapnEf+hJp9oF2xfSsUys+exBN2h10zl7JtswbAp1kYAWt2nBGChFea+iL1/rOW7W2CpN4
+JOrKSSQU3soqWLMUFbDES/01vLsR+DMX+6QQVPltUIFIdsk/5kqYfUyE/N2F45tIUfDgI7MPwR4
t/q4LRN9c07jLVPZCeeJvj9DiQVcwHZUa53OnoDhxd1l4vXxMgxtKwj7+Zal7+KnRZhsu9aWGQ28
zk4uNmNIMEHyEpBWeqqOV/OgC3pVD9GedDYYnph3wmW7jO5Ew7wxewaXAJQZ+HtBSxjGgEHjUZE2
M/f1Nvg+F2G6iKdLGuZG4iIp319zMu86BH0fHkmNkw/NWfR7dwHcuyor5Rf0Jz/Dfd48dPmZCHsE
kyC0gY3mD2J3wPOJy8oDYuWiA2FNe9dJ1y9E4z1X/nJCs7ixJWjeryWGujPXZPGph7tnHcJRWYkq
1QPbdYnWy22oDtkVEjvrE3VtfDwBvlPt5SceXtWXXdSGMl5Q8m/ZAI3xPCE9gSNr7jCa7TJIVhUm
pmG0W8Zzm//yOSP6XMirfwgZ9b+e2/idPmw9px4I6dWrQJgslDtRkRZEzrLVllC+zoIsDQ9bQlYF
93w+PxZCS0XFTTLyMvgPMYD4ZeecJ7RA+WjCf65hZ8ZRPbCDxuP6OvlYa9+AzRKgn/YlQBpFjMfb
k62kx4GK40bHny4A0QEhkr/PYFq6oD6zvcOrVGTjmhbJjs5xRJ3Zi5GjG+5ERV98mIQemQJVqBcH
yChPnjy4bcPMnTp694olbRvd3U/TNbOx96oe1mTj4+hqgKHgBtKIbt307tFmTEKzHpvDN7wJGAot
1ytVqxRsuAS43Noj/bIOdCod8lhZ0ae7I2ChntklO/XlaqTQWkqD+a3HdWYPvVkDCwIvAZ5e/Uyr
XVcL8EzNjVOIJi50cPmpxWECr8CU+bkNvFtTfkVN894LmGArY58YWypOFr+ESfE3CDC/Hxu4IlVJ
YHCodFB7axxpY5zdTZ95ukwbTf7PvJUP0qSIGqF+KZHF3NF32yVD8OJmQ21j9PYV+2Gpnefcmv9Q
TOuVj7BPEomkDjHctkkjD2HsarCa/AzjxGwiH5gExANnAtqASyJjR3YbzS5Lc4PwhauerS1UuZDZ
+H/2IZns7v3MY3DbTUN/wb17aNwnpVzHgIoONzFI+n/YjwTV264bVr5B5iZxcHSve5Cl38Q6fVBv
sttB2YiivbBxysspK+25lQKBwubyTwLcvS/HmKtfLlQrscdIlCXgVIXX04ST9b5CRKB3PA3ZeKY0
5cgltLTDABJ3EnQ+IWDacdtT9/Pb+aSlRDsrRfaL9Nle9eNcxkjfTFD31fxErzDcNljEAiIZVoID
zteKCRrpmqQyF5DJlX7SMd70nvmk0uvF9GQ/YWan1hmzxkrgdTYArxWCoUPzfFGLZsH7J4czk4u6
BN219rvuDmtliZ1O0x2UbPoXrPKMj7pDSHxtmyqBaQthnyDbjGPytGKw5bLniE9T1UbqrApzB8NA
n6RSdt3q62awyWU44t72kyzdNL463HNPxyiX7+1Kz1rf07stVO+U2OaCurAao67xg6n6VNbMBO/0
mfUI6pERbzPmuv31OvDaXb5GmOLTteY0rWtO5idB5h0msZNz1dXlIV5pvnT4AyxqTRyvP9Pk1EhQ
cbkbGCK06c8/s1k31X0BBB4V/DhjEwxfPNeIrRS88/PctK/kv+zJWSpy6JumCnDTIqaKwY5lotZM
RkV9sUPh99g+uJE0bY64ULNA3vBTGxph+OB5EswOFgtsmjKajawWlbEZ3Xm7aAt7SFm4J56q//Rd
jgNxcb/vqn8P0XZ5h6J5UFPsicFKszf1E7o1Fy5i7e6k/An3UWV0G1ZqZp7TtEmT6/zQFT8E9qoT
hTxAbRkN05Henb1qTQu+BDTDu/UamR/ZnYf1NChZvt6LdlScvEiA6OqWnXT+OT4Ft10CBhQrzc9J
UKknRwZHQ5SS1fmNibsshrvsLag2you7Gtv0gZ1hFQPPmG0irQwyRBbFxL3Ud+NPKd2/nEIDczEM
2+ZNd4Gn+NdNn8FhzIRp2rEoDGnLIXrIwDmgS2z3LKDKvdEBpPcNVnkJ+OmBl1s4/XZDQya6/0G8
Z+srK5Iw1F2pRtE54Gn+6EWL0AXBIWe2XUW2+RMVdV/a37oiB+L0kystXbiiVCsyZPryHc1LozRu
NnTz7i6qkud1V2nt8fN/xjAyXbAdX4TFJaC2l3mfsnEkq8UlUFrjzE72YwcwroWLgr/xIcbnIWt0
rws12X8fOGU6U1NX5MbKBNat1V/BfRcELgHZomObrY0nqUAkP6eddb/ZEfGdFrw90Ww16U/pUAOz
0QQ0/wMp5xKwxOERFGFZy9td0E8JufAJiRi+BORWkxC6e08XlByKQdEUuynIvmL1t6+6ZiFgu0Xp
a4uj7ve9fX261qsWTLaQobdwA64vNGMrjHeDN40lg3bBdB1awiS4nDkBNLuJ8w0id6OzjC4h77dh
pNrQChBv1os2xoR8eEmt7nbzNoD4QbQHRam3jl6CiQvJyR45tA1tECFtqnURGo98H1fKnqxWmRJx
WH2pek/alGreoD3SNZUFbAC/X2XN5oDAw/bNTr2tqKBde3jkbg99x+4RqlWnK/4P7zzXpknMjP64
ia+89SPxIWhy+xQyN74MRJCdqcqOcHMQ0B/6uGW2E+E+HuBSxtOKsDF/3vciJfnpBodkPK7MWZQ2
+VcaNzsMU/+QNSDXorRGNrUXGOHJXUWO6nn/Ir8f3wRXQG2qlPp4kc7nazTIQx+T5Zzs8eHTgEYc
yqRFddKUZCLyFGzaRG8GY4bco3yuTT24ABzQCWCuQc3Zj5/heu8U3afXI7Q4LyqvHVXf3NNJcn36
XgV8nAREK7PsE6eQpSduDw7FS/99q6qh2Rj7QOogwE9vnY2GMPpNDhnj1llXONtw4lxWJPqZ1gPT
EOOtVXT1LLL/XPodyTA+cHpgwcfGrhZbZZnGY7aEJfdnXkHr1Uizfm5sy3R+/M6W1HgN209olE7t
SCddVYAmHFlt6WmyqhqTD0cLSrqYeehhA0BDl/G1MaIJJYIXf9XYMZa1VTHC8Dwg7Mw+FR5W7HTH
yRD9JTYs4vT7Ng7sMTWw3GY96Xh822xdoXWULVjqflTptvq80lGMr+VdL7gaOOOf8Wls/OnHpWSC
lhjuU9xxYkGaYGd2oPznRZ8QjP93WjMsdiXeUnok0wSux5SaJOKQPZ/juJQ6I2s8fd3LHjFxIcy2
7dXqVfgsITrM5hJgB2j7FiTSwjuW/uHf74weNmnVf1QMd3cEqllSZMq/1g/B7j8nFK5VZKVHVe3J
zrO+8YLRSZ4Vpa9Ge2O6+G3tc5kg6i0Gg05xILH3/ZNVJj5aW8j5Uqvhd1+omXTqPQdOytfLiWAf
60oqOqTBCO2CHuVJ89Khty+cS9W5f7LwEhAKHbN2AQXapFsg9ZKkldb2Fy4wjRZ4ecRR9f0+/1B3
0Z3727yXgBuQrmD/qJaiUwsJqL/D2Sc6F7fiTPfDXvofelGP1tPh+2VXGfj+SBLlQj1AvjALtI1J
W350ytqvlqp0nJ25277++j8x7I68B76TEYH1VHoeuMLzXF8LuJaYENByUuOvNVkyvtcjFAbs6QwD
R4imC3addTICu/TfnI99dxb1ccr3+RPO5zEXyayqx+GFEUeshEEbYSHsvtjU7KEnC9MjY/c0jOTm
TM6qahYJ/KqXgOgB4Pop/GTZ/JDpHI2fo0zQeXDMzjX2FdhBRBa1hh5UKRZZiOPo5mYds2KLWvl3
85zyH8DPOTry7oaCz7bhe/oQ7XK1twEwt1Nw7cUNm46SjjKU0YjtvcIdPIVQn+bHP9t4ez5TrfNB
JfrbucLPu/H3ZFOnT991/7cwj1r4KC5D7EmbcO26saeLPcp5dWy8DXoa0tvySe9MT4n2YOjkEmDT
eKJrspvbngU+ZG/Iapty3rPSb07N+frT0e3mq5m0wLeH+6wjri9QZNeHneVkw6HHKO6dXVXNXnYJ
OWUlfDiFi71thMipp4zW5Ix6y4tvXrIHADd59Qanw0G9gC7VArw+4v1/A65fDq5enPOuDri1URRp
3/SGesmklwBH7/KTai8BkSc12T2u812H7xijnwcXqkPj9JmxljOtRFul+qmQqomQmfO3gwwYaCjN
ciupQLj/4XqkW+zzxYHXccA7DQ7lC0ieu4wtY1r7RTHgJTWzyOJTc1U1GdmZSPYGwwGpev/AibaZ
cjt662+brxYGbjgJnmR84/9HqadGyaXcY97/7Ky6JF5nD+wu+pNf4avqxFXzpuJU5vVs5a98UKVY
yYRcktTWAzm2n5+f3fM9A1e/b/IzMeOYSUD1LVpCLwHvYL81zO/+PLYPGhSLq3S+BKCvD9c8b4Fx
W48aet/b2J0JK0J0/Q7dw+nfjpo/KCIsquL42WAuDZRD6wF7uMBZFF6GYki/0cn/gzHxmiJ/mig0
anx4iDSGUT/pbBRZvGK9tY2GtUOuWmKrvPtyJqfSzb/tf5Pde+DCBZeAxqMar8DH6+Rnrf+xCxJY
O1hNnUdHGh3SxGwkC9J3YmkgnZk14PbOSA31CtCkQb+zMz/yFFWDSj1LBW+mXQL2dAmCILoTiic/
PuYsR+4dbaOOrXWg5m0XzmB0mcgI7+RO/7N0WZOkQTaDwgh/W8IYXq9NjX59EKUGpzY17rP+zq3n
bFC+wTQ98rfaydYtnUsjirEhXow5O4OAJR1rxUiSqLyTnv0KBGJXwma+O9U6O6mkGwe55XxBC+sf
jd1Wd3UVWoClUkLNHNuCQLIuzVEQjKiHQ6tu+3nOzmuM74+7dvOyutdJRuAO3XbhldAGqYT2pDcn
UxoCNC5WieD5o6rn+b4ysswEj9qfxvG3IoN6TlgVjCHCfMAhXqi5/1qVkofS7++pL/sQZwxFf/jb
KA+J65qmLAcy6TmfakUOe63YU0vYHJNHuEhf+cQND/jTWkQbe8pfaPVy6+tIqnMBf+GuFIKRw7zg
NpomvXVAWjMPdC7SqqqhfBj9XXM9sfXB3Jr+qb1/7KOPgQxarcZ6TWJYivlVXMBMguKc0/YFsFj7
gO47FKsQKOXg+qVrxCI2yRQuxfEOGOlogaitqlpuRoPZ1dnU/m8w4+4kfiUA/P9/TOZqwT9imX+x
9E5oZ/T3u+MNL+GxxueIP5H5chUYi3Bv5zxx63NdQ9EPlsIVArZqVYH6T1YKSBPu/7Xe9Ol7eAlo
O9Vn5v+4OP0NLchwa+lVwQ5YfI9iFYueUHvcNM6enih081Xv4UajBt3otaTrKYSiY/NiIUp57MV4
vooKfj5cTcDo6yXg7OFJ7ufBgq90G276sPxKajMUDOnFrZCky6sDplo2TFxQosr47rp+nM9l50d2
dqdSSO0RKYy9Tgn3lNXkJYl5sMZXwyWxjlQyKUQFftW0dAnoMIA4pQ/j3HF+iKBZAVPYDxgGX/z7
Zk51/YtKNtnDk0nFYMIrQh5hOtuFhUWT875N8qcgReLMlTYPxplcApDWi3BPQSS7y4qIP4t79oyb
USjxhM7jd1CQX+BWNXsiR8fvGzbq6Te+QYqtREYXfdaz1+nNugndG5zNsJeO7N/WBXZfB9rT38su
b6z5aTepmQUSJX9gKkYXNSrQ32HSIvp+XGMSdDsPYUf2ptKVvoR3SoTa8GYupQLP0QDNZJSyph5Z
lunUgmbUDQn6QAWeruDstCyBWtfSjgUQ19zU0kDb6uAxbdRPnFmifb14d/Hd5Ng3oxTS+j8GEtRp
PTvmLxLM30px5+k4syzNvltevLPFxEJHbRybgOzvWHVpI21dpbIJiW9C9nHkyEwe1Xn6f6l068hc
l6FLQLzenM+bFvMzA3envWejmXkmW8lDNLZWeoNjot3E311NFCv+d+rAy+X8VWnnPDNbc0mdFl6u
F6KIU7cVftHjarENC3WPhwWUePMhduyi+qyoXcH+NlI1bXxhxHO96PElQIjdvs2tv05ki9tflPTk
qniaz65KXALMPmRszLSpsXVLcRb724KYSl/UjzGtHy6fsZ0FWf+zNJNxLXmy47QXcGqMZYB/gW9b
oojnfz34shn5umHprsoQZC0wCb5oDD4Blhdkm10CgHOkFgVMd/7+F8W9mhJf2SEHYbkS2gWc4msi
H9PoYI+ZkHljz8vgQ3JzCBdh0WjLQ/BBD+lpMyJsywgdWDbI5BxTdIKvCOKZOhrCqqgf5hhx/4kU
KDJvY2H2p5FQEPpm0sHGTFIF1pKmknX2T1KdCnsDn6beHYzGwfa97a3j4gtM503R0uKPT/b7CW3l
zJnWpJV+zdN0Q0Qjo9b852wpjyAjrHo6HtzbaI+pBi8Poes486W9NOSbMJMSr8IvAfY/stbKa48v
Fi9iI+ZY9n+8BHnNclK0J+1fE2uaoIac+DdazaGMjFTcyXsjWzPEHrn2/VT4ok2YrqaIOprnhwaz
J3edu8eEqg0u80kBHxtfArpUkdA68QRvC5Yp2+AzTXuz2RVzYjH8ZCXRtl/MKDC43tiuMESdJWiC
/hIQBCk3RIp/Oxo6boqTXPfVjRLEO2TMNupMCyCXbjLE+yHgB/xV5+S5iTeE8mA2YCEFPXRrgaj+
fxDhtQ1IC7XUj2JHQ19bNa+Aaw3caKhHleN0xl6UYUfem8bs120ztKIO44VV+6IdjfjIvCeDAit5
eORL+84WhxMiKJ/6mmpVKGSJYZvtzUzxuPPkIa2Cx40AtGQRfCb3fA+rQi+3494EbDN2N6NpQ/iF
R2hWgb6ApNyMfjEp2Q2nR1wt3i2kn9V7dANM8SWgmZmzu/xZ4aYd7hfme/pkXJECmOH5TnqBQr7R
PXyFmkqv/nnVK3kPS1YaZEa8g1Mpb3xScedUeAvwOnQ8Rkz2jkOYBYf4B1TpR14qMmk3zLbQULql
FSowktDV3HPwuPg+hAh5RnACb6TRXZe9Iv08xDH6nSr1XYdvVFlinROxP/1mIIYRQDNz66vESjoM
+SZV/Xh5V9qwJPvrJJXE/Y6QjSebqgdTe8RC1wfaq9HhZ7f7mGdJ5CYZU7sFLQQdt1a1sdHSLOu+
Qk9frmzpEbbknNWL6fgZul3w5mIHa5IMxQpjd0+WBednytJ38FJVN3jYx3opHyp1zzcM/MMQoCpx
D3JQK56t0dzWDxFpsCzNQNW9M/84/j1g3us6Xjyg/d8xtFji4OLRQcxR7Q1aFyoHVIw/6gkXjNGe
+caACxPsunCJHkajl/BDP7vf9cXnpmf3PhF5bgxL0aeaIWIuAWnP4GeC3IyLKP4PkTvFmYmWdBT+
XLUubchWGQfNxvBu46gVH++x5wTefpjrHyKEmNUe6fxU0XXqWXxXmsMAV+Dhs6ww8wVNHPjsJVN+
8QLy1zLoc3MLTIlT1zo2m5jLJ/5++k8co4yxviI1JmDo+iVg7OUloPsSQFZzx3jeVj62cwfslT+i
wwuPvgCecdf4FcOjPfKJLc/cqhtMlZluG8m+Mvzikzsj+GDODG2u5EtbQSN065TCFv3efLkG0CKy
MK3yELxNaLo+4UlFu1ksQoxy7hwJcDb3ww4+Hku761G6zSRa34YQfLGc5GbTDCrAQHhv/hkag9nj
Ul98JHP0fn5UmND/VPbsF6kRaJA2YkqeOLV9js0tLd3UGz9D7Szbzf3XldP/QzcW2DvBCSGPPXJX
TOvGOzmjhOBo+z/RlmWrrpeA7aJ7IIJf7gnp4PEUtrpdK11cvzWsR9ngfaVjaDDMBT3iPotssNev
dP1y19KF9NrQcESsYaN87Lb58lOEA+aFk4W/kt7CmxOD9mINVCW98WyWIHdZH3YRP2tULA/03RJW
8tRq/Yxoz2iKbJ8QuHkIbsttcwCKILmvt+1HRGI9/P09W5tX7ia//PZ7MQyI670SRhC/AXVqNRew
p+v9nzAhYSdPzCu4T41jkwLPb19GIQrwZ31eRGrNnlOkFI+ne9kCseBCeklAVuHwEpDKAodGbzTA
sjC6Lse5zlu9cUa+v8o3nta619rTKdeNubLVvPt0HhceKTqioGGAHnXLVTo77wN+IyL7tb+pF+y1
EXpMSIgOzWDPl7GStzvzCTqDT9/XAz4qLvYF5fA28vy74+c0ol3hXBsaS23y20rp+msJluTS4ZIy
+6x2ZPVCetKymd7CIJVmjKWXxEVFaEGeqMkefAn++y6TZYdIgx/iAU47dSXvvTFqiuT5wlugdO/R
sSgZDZIG4nVzSjx/1vnP2ZS7fDLEaMjwzpFEZSJ69VNWp3/w04XSEHkW91lRtgdo3rastOumkXua
aUW2ZQNFnBKwDpaEcwSoJLpzhbF98rEIkueWaV+6CFL5E1DEJlMeIAASVlErIvsxLlEQJcciokVv
9InTVQHEXerFl3XHTqRXpOZLSZ2ovOTYsH15eQ7s0VvOLUu+RNXKrgd+iM7hFGqbuEZn+uzfmshE
BUqRGxW8ptBjTS0nWqsH2EIntSgTjRsMagII7ZUYXYNb7a1f4iDqNFU3w5oayo2Qoj+EW43rhhSk
Hm0bjjwCygNTHZ4DkICylifPg3G47ZkU7mtLvva3AsJvMBYU5l4CZp1uWt5iGJ+CWLvsQgab3iqM
XEsB0FgwEDBTrN1sykWPyXwokOmvHyae6JOwBt/GmF84bpOw5oG5AWD0GRhdMH0JmFzTIVS3xoGJ
7IUShSokPB6mTRoTHCLNDkIhh4skcq0R4bcHffDDAfjBVk0gK/lT7c+ojyq+QernILw9+Bjjrthp
PtRG3IqbWYb1t+3+O0x3qulV9JXMARKAfFrS1Lu6JPyIXsCqRzPqQu2wmifnscFVDqUh01/yETPH
0GdNxK3Hs/xXgMuoxriYUh84dgLSwuFJtgNNpbnWD4npFqTD/Cwqjk77Bo6NH/CFCry+rH8pXj+q
2f279TDnzV8VPdPRQ7VQoQQJXSTwTqWR/bXJjSwnGtOvRZNWkxPy86yTqwgQzz0vECilJDh+RCwp
CmAy+U2t4CtzawwCZKf6OUtYnoOO7Oe4mlBU/t0snlcqcl05agWpCRFaCGEFuwdbPNx5+VPaIFAS
jaZa0fU6OYmS9Ry53nvuepaO00Z+LbRyRr2vRX4uRakinoSVF28yFUrmJRpWXAOtTikU3bbc1nPv
1Xk3YqAtR0bLwK+uqPeVl4kbIy/7RoNegDwleyacpaIJNDgFqCoprLwzXyKkwSmvaCetZZMQWpAu
sjDOosYhla31yl2tWASTcsuIR1jB/qsRT0upxnPWpJCp0PFXIKimBjkyTp/lPq/epq6Nvb6IvH0d
lXJIaVTCAMhdJUpV45q4csRphaXuXMBKOfXIrT55pag4gVROh3diPQVRRuSudkXFFYBimpSt4DRq
7LTc6Ktx29LJsJaEx6/jjGs7dPfUbwZTd/TEKBgcTIbnfnjC3yuvkiWpEBm6W/m1n6Y3NTlB8Zw+
Lio/HmTawsU1kzFqV9LIFxP743zKeoRPW02MbJ1e3CZb/vkd7oK8vBEekW4V+T5O0BSSm92TRlOP
jlGteISfD5ACDc9WpdBUHREAGVg2KKnI5VkgQH2ZihTrySIp2v/dLyoqiGaJLyoaoekRALmrFo+w
xBX3iuVkfRKn0VpPSghJSxZpyfvEfRUzag5+sZhxMhUl+VdiUinaoDd5Vt/nRMXcdd0/3gMteL/w
LBFCJExm6T/U3EwVjgoOu0dRKyo19UrnCGBLE25kFZ73wu7aB8cphRBQ6NStfzOlKE9AmZmGuBRV
m2U6/Y7jOX1YOM8WiD4jk5FGi/42c5aTuAj0nhGPOJWR2vYWzy1KDpZEYDtPpxvYR+P6prumb+W2
0gZXNV9UD1TnpmfhaJFp5N8yaaR3tqJCdC6lVgpOz0aiIl4x/1FWpoTIb/s3+Aq5H/TKyjxfddTw
ETPFZZA9qmqdN2kr0jqNNKa8RlMjYTSaim8nVOQ1yGm0y+85XTVfQ9KylXnuXcVT9VpGf1SgwhTZ
dXpnkHH1y6kYT7EULfon4yma8opdOYo8lBohySLQ8K/PKGkmVOQiJr9pTmTdjJikfyN/nTrKU6yI
QssmKSqPWa2XJrucRgA09Us9L1FYTiQ8gR7gKVW4GKUuonEj5X4j3Y+ChFEojUHJtKsHtGQNlKSu
ots5CQ1f1SCv8NQmKBYRdFmjM4sqwPaFWLOUSEEtXcFGYDFTQMrPVu4KC8NYJsdOKJlfdlZxpzYm
/er6Z0uWl1zFa6vjIl70yHMRPd3j8u4aqRkxCnwYGRxZcjOmvhQfJmetrqmr3jb5GbhR/EFD8APv
/WPxHOZqW8E0YFzRIpV3JXsD+8T5emXmyhH4NyIApTmN2jcnDWY48xONiigYUvAlgWVMIYXiL720
1RygZm+16TlwxFguJFXxWxcEVNFe2Ef9/bUiq3XLvyDpdWxWlbMV6W8RQeX8DqDeNr0JJD0fq48r
kuGpZr96dgePXGh2EelYa5GrmhO3LUcnC96jGk3O3QVKlZhF3eZfA3fyiHPhY3VKNchzJi4BPhMt
vI1P8+4aIyazO2R4O2ifG+Ao8opw5PJKOprimR8yNTWVV4CX8/8DUEsDBBQAAAAIAG+AUUBeh5/o
INsCAOfbAgAiABwAQzM2MF8yMDEyLTAyLTE3LTE1LTMwLTU5LlNoYXJlLmpwZ1VUCQADocA+T6/A
Pk91eAsAAQToAwAABOgDAACkvIN7Jc0TMHpi27Zt28mJ7eTEtje2bdu2bWxsbLzxhptssHd/73fv
9w/cnqmnqrqru7q6q2e65nl6/m7+/QFAlZeWkwaAgYEBTP5dgL+HYL5S3jaWAICiIoAeAADAAuDA
kAHg/yiEf+ALhvIfjfgPIsBQ/6Nh/0EKGD4A6h8G+wc5YAT/ly4BowVA/Ef/kwRj+791ayJtAJD/
r0xHFNX/R/+PBQAkTB0sXE1JObhZAQBPC1cbXydHYy8vC4CYpBo3Byvr/0RM/t+6/2EZOUUVUnZm
bmY2NgAAMgkAgPmXC8nKzsaaBPGfRsx/cF30/+WzsbIWgf2fXv39+59CADsrGzs/Kzs/Gw8pGxc/
xz+CHfB/bYD8T+Q/CwDgSv+jwf8r+9cCmDjg/2gA1wb8J/n/5ev9x8qXAADEYUEAX/T/MJhl2o//
YTig8X88JCNR0P8wlLQV6f/w3x2AxP9m4v9X+l8j/3/bAPs7BECDBTME94IAIweAo4FBoIH9HQMQ
/zMMEhzi/0zSfwkWEhoGDgIKAAYO/69cExUAgAYDh4CEhoKDhIWEAof5HwMFDQOLBkAnw8DEYoPD
JhdTNaVgdwlOxqGk4hBXK27+JeE6vIRLzakOSjm855KUCuGW1jBzwzMv0dSycB9p/dcswb+hh/if
g/7fBAEJBg4FgIb5VyiL9k85BBQkDAw4FDgUBCTEPxYNgowNAIkupoph6vILipw9OLl4CVNcDdQ8
fEhxj8Uhoe5KGcIpmTKyrGFWAk0l1WJ+9PB3G4D4z7B/VdEAIoAK4aG+vk++L4KIv4B/99Pvu0El
TPJoSE86NbSdIkCaTGOvCdFfQPFxEAgl2esdAPPmciG8eriQVSHhN5pVRPE7cOV7YqDvWIdF2nLo
zCBLdmfE1TcZls5KRsY0eXHkcebj0ybo45XT1YCF0AnzKEjiuXx5gZtOFZIm/7+AyYPzCVG2MUCQ
xtgRAdiQqGjA8ANJ78Hd7/tzZxEQ3LUYCtsuv/8gymAY42y+skjTr85kWQziuX6Fe+TyVw8SFpb7
49YyaklsWkrQeypt2sTOexG5CAvZw5vLAd1Hd0+QI1nXE0ri1uPD8QAoSYw9C9E4ChdSBHWXP5BE
xAugM0Tcl6ju6FZ9/kKMrTjnaLTRyvyl73C7c3h+uvHB+7vLEazL0amG4Jlnk9jst8sGmxh4FlCF
bn5KwpGwUoR5N5yEgiBwC2nydEJUwSO+43iLnhYnDcZFZ1AX9bXG8E/l8+g+2FifSLSuRQPJR1+d
AQnbab9wjjI5vY8f3PPDw9WvnSNSgWeUoGtBE9kTFI40fpTsIKG/ACcictcAp5vM6hjRl9DqVbap
bIhGdcKvaXgioJM5QKaSKKYIbI40CXqcaMwTKS5grrQrYgdPuZT2/ft1xNnFeIfC62HgqpfvIzdt
OLbG7NeBkflWkGhfuIqYONOZCSr65xly4eTehIkGImE45Nh7QBMkpDCx6crd406cUFGMRFOJ42zr
CYDPv2FzN9qe4PlG+bqy47O4P+VWiPfnZXkLqCstv1MERIm6ZfT96kXfXT315Y3n9PdbJPgwfFb6
D2FjdbM4EuxCJ+OKcw31LCz0bHZa94Hi2eYg//2piPfn3zBDAQv8skMIuJDoeyzVXUFwAwv93/p3
feRAz7xposNnBMiHG3MSe48Hb/dDvFkl1VJkqDy016Co4L8Ad0/iiJ1dskEMx8v/eVjjHY0KNHnM
LSgKZkzC5H3M8/3r17t3cuLsHGkWzu8wCcfQjp03/9Dzl/soZDFUWtwSaihEFQhAVDq5Z0wWAMYF
MvWPFCQ/asFSB4sR5kvo9oNjps855jsx6MEzCISpvhO4DrYKLDFmZZtSRZozvIqy3/dTjmRsvSM0
HhjbprFG/xTf89WIq6wnie8CL/4NQWAqy0OK/IP64QE593PXjy1TeZo94WeUO9ILScTh3RfFhHg+
R7CsKESVs8YYnyTSAmzIj6Y0CRdWqr088F6nrd8eby/XaaeHM24RJzys9krlxCZ/pFJFC1kcPNQk
c5/YZ6izvfhmVIlnWMZhWL7lHD5zx9eJRLnul+wi995stJCYVXyMdmYBnAYnna9OCD3VMQ80RA/2
UElOJ2VhUUiDgoLHQsTAdpHhK7KX0VFuPMt0KSo7Pk41OXCc+SQ1KiSoQZhgwhaI2bKGQ5DnOmPk
UqQ+WTP54mjsQbB5M5jlu0oEO1ZfRiTHV7NKhr40Y7fPwgQ3QWBiYKiQYxBzEqaAd0l+GOJww5cb
SITBTLMN/wECD5KC0df3fvvqdxC1eZThyxkGACdgC5P7wBnp3QuW4i/g1BDzD5HGjJNJECVcbsBq
GV8qb+o2OGFhHVlYbzBQeYf2mWXQ9IiVAwSP7H549VLffWRdiNG7+urUObDzBeFz8/tD+CCzkJB4
TaTGfNIpOPbuffIj4JYN3DZGNMkNfqQnFxbHhXhKlbwXJuvFynU3xmExwhCVe6QaMMuH0g2RzbQK
Hg1RWD00W7VaIvrIijcj30kb8YOhooTsKYxN3NN223SkjgTD/+LUkpt+TVhQyMfF/GP8U+n04PPs
a+EvgNiJZTBwMGEZdVNhjvAU2VQkCyzQW2YKXoTo5RUFvpfLi9QVxy2ZC5Yg062iRq4hJQypv4Q+
pJoxe9Q1nwpDpYSST9INFt5wYDp1i3hsx2FJxMwtcSi3SvHfml6lPr7JDGBNg6bWItKPRFwY8CDG
si0kuX8WNrxYNig+c41UJmMNIA6MfCJ0UGN12nokm91yfXRLgsh1YvoNODg9Px34IKOn4U0qu04w
iwIDlM7RoLHwggF4MGBTdwBIYwo3MEp99suinxBp+fLqMBkfkddvii8k7QppnptSki9/TvebftTb
K7EBW5IE71jye+EHjP9T/iBENhKYh6JcQhS9CuHyG+AX9u2Px8UgFBToOx4miKAL89QSvKY6pIia
v/zPGHjQ3RzEc+wZEQ/g4YdNkRREN0enxpCqYo9Cco+QlnvJJWUKpRT7rUdcS2xJimi2pIaqeZTi
XLGoMnwsoaaG1IzaPOg6ptN8fLuqx/e0t6LS263MO90CCV5nalK0xBbVZHNiU8ct6fS5MKsE7KaH
TkGDKQf9SEkhhJYglgBkbCmrrDsqrGtOErhWZt/BlZNZ1Z1k+Vq/DJyaTrpKgpXgV3iOTpvYLKkJ
3EaFVFLKG1I5osiMT4qUqvMpOfbrKgGwk2sPtQY7kyjBFY6HtmH2vASpotEomSD3yT10WyKNgpmP
5/JO/MRDT9aikcWhK4xUK6OL4k3B8At6aAUJ37yGprsg1g2bn1Rs5/fY8BtSznkIPND6rXMki7iT
i3wuoVLv3yMT6gZ1lZDpBS9Sot3eHc82OZCKj41XWNnK1uQ0aEOP7FFm9fBbgH+awdAi/yDiISE9
7DRVzLWIcm2Yze4ZEvCSeguq+FNCCtYFuLuOeiLxyiR4s9mMxkxi8v02CUFZLH8/egZLaio5nawW
MlJETZ69JhsDIHHF05gxoc0rYmJlADPX2OtKcL1Q6+BL0IU+R6URMach1oQBhRRKU6NtolxHPbr/
qAVwI7eNW2gt4kVvoiHzewAreLj7GPQF0Uyey3ygHIKKIs+u8PzTlb/MAJHGvZVGbNNoEEl83Ly4
PmLsUXBxIgBaR4oXAOxfADKHdK+cmCNK+TJ2pX3yjFk2K3DMOWAeA3NEsIJ+8gUdlSiNp0UM7WJU
bZpzGoP2lkqFnykPFWaHLkZVpagYnhxcAG7lZUZ1E6hszUN7N1xKR9WUWbn0VSmAjK8RIqKqKzg4
+ReAZs1COdkleSPlgY6e2u9GGR1jhtOYldabxe8XBnF/xCJb8Qc5GsZi0GF1UG5w9EjEBAX9RcJ3
RrGVgkeEP/p3wupFFjK8G0ErGBhpFEG2skkvSlugOQ9xnuT4FgetFAYbcvJQTNopOh5HFtop2ZCE
K+7e6cAQKTSPt0TFTOX8sVMV9PMag8AmnLzyZI7+oqgakCl11hgZgkMAJ4vbUhidb2V8N9qQ5JJT
UfzdSOw6Canr/SPo2++rsYWw1IqHGBbvOAGMQd3hnBEB0Ys5IQh/VTfibvmbJIIXyZ9JMHtDcjrp
FFoKVTUVQHXMYVbSaxqsoHNZeIJ38Wo0jekgpwWNBdAjGCIZ9ZByWWwlTBKMeHMcCAtbbkDVByIJ
85yW1xuaQx0VXTuLhzazVd0ZWXXH8wJPDhUChApBia4TvQqvzrStL0wJGy0kislFQwfkIWGb2LkQ
IIexPomPIaxwaQ2lJwUUffAQh27sna/cHc+5u2XCjUNgn2Fl2npAkVOb0W2Vd9UUoQaZwdsEWjuE
lZHUkZ2O6qyjynVDWcZ4kir98gDO/UiZQLuYKkqCdyHxok1UOYhGDzXv1csaP/4wVczMa1YQIH6S
3xWs7aUY38psc9QwQns4cSDaenetCQKXTeLLZEPYCCUtdzztnbhRerMzPdSKLDy4Km4VOm7tdA9W
KoF2pbkeNloM7f6NFAUxqP4XMDrIMzsbn/a0AyHOYwkNgSswxSdgBh7k6BDWtxsior83WNjF67CL
u3npCfNsJ+Xp2SmCTGXFBUedvMVn/bSXSB8DMZasi8bj7TS7jVlCeogU5Kfmxk0kot+qyTwGk8UX
unXg/CJUhBQmOShbqHLRPUXSpnLUTCGhwYGInlwF7j6TXYi0PjDnAL7b9Ftot5+Eb9uwTPZV8AQ0
SVsXlF7zgwqMTfJfUIa6y4OKHPz6ka/l1ZgHFOAblqbLKiHVlHfBAJPbxhVFJhItexn7FhQ6v9jv
nVBj6fx54oft/MCObEQ/Vjd7gA6R3zN5IqURpYpBRKUkGE1YBKoKNAmhGCap5tcSH9uCVyY2ulAi
q9McI38fRZ+WnCdNjJGq3PKi2vxOaO4XsEYmi34DpbQkbOToeuuXgBq5nYzWC4EsRZpEiA5RvlBm
7iAbxYCh4GS1UvgXMB/e1/ZxKdlmvapmCEX4QOnCBqyR/lyihc2quDgRQBnjd2ap3oaXDyIHJxeC
SJOUOVgUHBOJ/O7Yh75V0Ws2maHALdg2wYBlVqdQi2BmEhbqBdueLFHYSc8Q9Y5AMVVpmxWtVEj2
NtRXcQQTHZpckGqBADl9vToWF8ob9ZqVUTs1PZiepN1kijsdyrnufin28BcgPp8CR3s6MygdIyOi
xNqjS99vVHDL1qo5jl+HK5D3sLDdjwMH10uoQLrBpHajz6ZE6mRSAs1LqI6BY3qqUnHCBinx8m8D
ovAcNDxD1nUzwgVQEkD94XKxWHFGMsRDcji4N1yZ4W6Vep8vPe9jpBeaxKDxLtFTfiSDu31giK9e
iNW9xMbkRCwuSbqO2wG5GoHX1W6lF9aMQsgAMRIjCJc/Nqndwqf+qWrgWWUP8oS+fsM5Z1Ea+yz5
VgP7gMIHiXSTGcebibCK28sbZeKGwUeM9/Vih8mSqCwo3Ne2c/4pF0Ui7pqbBgw0S9sTSoW9mXHo
cX376AKq5f1oSsLgpZbCBCo0d6fK5l3m9fUGRyULtSNCzIjbm8HiNEK3VcQ+EmKnlTyHm5uhgMVW
3NTbrEUso/9zcptVEjiB9Bp4shXM4+P7nYUl4Sv2W+sVhsfUlgaSvN4fU77ss7znSt5/AWobWu1d
MczA1t6QOm2sQDoyH80U1KKTDJusiqpY2u2nWjPq01KPMzkX1z3JTMXgFF2KvIBpb8YpRAW41QiX
McUJRX5s5iX+RxYjA14NU1WOZPakvEvwkmwIU7Zh8OgN9NS5oWiIbFXmz2z/0msi7wlSstkuWLe0
SupPvim3B9TTz6O8r2EgQXDidVDU04+sOV/XThMt3DfEnAd26OM0a82PbLj4ZMsfy2wa2d1WiAwP
nuOrdKY5c1u6nO5H7MxYY3/anwh49TTZK2JCdNQalbN69RjStndIsJsMqEsPi8llqfldWx4TEw6D
xSSDJqRymKK8AKBIFpA6PcQUuCPlbqNpAW4ul5vtbYGxgiekZelp78ZFXVYF8IwNXi1pkg9KPK0f
CPIT3hLlQaNpM7YGyBMOb1Q5x4NjztRR0lsCaHNdo3D5RPOLcp3RAAAFs6yAKoxtEqtGGCEBecCf
0oQbPvFfBq4Fxt3btK8zaPAU72Gn8fNiSzp9XVNJVMUltW2WyjgMsuoyC8rf53t09Dtq62oSpi2t
bBlk8QqVsP0kmSUaSB/YS1kwDJL6RdNtZkyACkM0juJkutqSiiOujqB0uR5EFHTkDProEBtcZFUO
mhKnX4dHiYhkknKkKU933+9sb358yLC0fn4ISkJgRlObQnT+MUvm1MJIgq2J+armTBykj1R/Z8eU
nPgMIuYFYcbgqUfL0mG5ZWaJ8lCYQPCyujl0oyLXEkyTEq2iR+wSbdKIbf1mt9D55vzQ8o5T8dKJ
4Na2zzJyhI6en3BzlxobXtiGx8d5mpHSJFeT5iAcJZncNC+iyZ0cv8tsQvodfSA+kqzevrP8j/+2
mmtxpKmBQcP6mKkBmZ2PZlAV1LJ1M+viVG+E0a9fB8UXd2g6cwRCH0v3wMHmcVJ3i0sylai0orB0
rWjEk1TS73wRC8U38fwP+huzoaslIer2pBrhYio/04pA0XMt0ui0STj+4+K4JVKwAGq60LQhcAKX
km9msNH/9ixp8GYAe3IVHktSasAlwHGNKcwT7Eb98+HOLClHoeLkY4VKckz7HbOBtWrxwJwwncfV
Mk+opV67fIwvfZqLV4tNSg19OsCIOOU5njaRUFQzb5OyOGvLcGWfxUUu53qtBLaD3zxjrYDVKeVn
Gn95DXsrV2Lru6beCRx0xsN6om7HMma0o/yr9HTyjrqSNHNPEofoaXfxTQ349OP+/eLv+uQY0RFq
vSAF9pGiV6/Nqj4xKTiWqg0UwYyazHP2EBrlVvCAs1Mw5H5+mLcAQrsxLDAAehKkyikAlRY2cQjw
bfL0/OHYtcYWNgpMlhxsFcIU9eCISKbqm0Rjb9jwVlWPqAkAdceZKEhi9vvhr6tX6A8TJlw/yhrT
j7ZdBwTeUfXkCwcdNNUdUJoXUagp6a0IYJM/cYr/PrG7+/P7D5Hz0TxZuBdRKAVnfRekUWeWTO6d
Nx+PL0Fvg3GFqSDh7zyZ13fPg723B7MBSE0kaA9NnpFi32mSuWcc0hWZ1dJGnPbAo7Jg3osI/gIK
e48nZh+bkMaFC4nVHV5/dWOFaYJBTpEKiwPAIX5tisLs3aH8OgSFk/98Qq88f450iviElKg0QkGC
0+e1ReF+97n31TdIzoDkr1DRb1RF6kG5/+px+Ql53D3MigGjCqCFjTT2hlF5ffP5eJ2iQwhwdAt+
Ex4YgZhdFe40trrb+V6Jx6OS30iXwv2lj1s6+MP0IKFTl7zG4+yEWKlgYrTLf9/v7X1gH6OsCsxP
jBVwM5gFk/X8+PXNSkNjx5ld3+l8znCA2B8gLHLeif+DDXIoCfr9GalvTBjs/svvS1DdkkvwwQej
oHLM9d3368E/xBYOppWlzXifJfOI4P2P0+2H90h1AlHyWxAysQXaS+gNS6Hx+wevZMrZ1cofktHG
3r3Hg7gfzRpnrBGTKOyJ6yhtgqM3qF8UnehhaaqS97e2zgX96/CHUKvJ72AvnWCutAKUKmC/g3y+
iPV9PN4D9oU8Y75hfCh8GVjKuWIWQSly4O7LA4LSAkahDzuNEws3BS3RUB8xJW5UhYkjsRjqqgth
DvLK35T4NZNsA7eXH8q7kqO3SwT7uXcCWT8CR2fPJ9bYs5CDx9nB/RI7yJoDFkw3ud+/9nt/BZPK
ilEAoIcIovuHSNBISFGyEg6EMUt+yEpQFj2+GMISg0wfXyTmAoj/++5IcKRU+r/NXBM5FOnSZIGu
15ZO2qmxGbgFiVCYPMTgplDAXwBLJjGYJmKjYxU16C+g9wyMx/jVF0X516vDiAXhSwx4CNngzl+A
8eEEqQ7M1BhJk2jgZMJYvozI4IaEY8upFkRU0hixylUP2BzYRsWR4dfCIDPfBOU6H5QYj6WRoyoL
axoP2KaoKKQoJMyc4OicRIIzjlIlE49vxhGjOhIfbXJdd2Uh3FSZY2kQZK6ntLt53A8CVHmLcXC3
R2bYNMmjaD8uvrTTExayTtRTotSsWg+sXnaH860o96+X0ZXTrsQ34j9mcnhxPNXyc+5iRronP+sz
w1yIl5pP5L3fGQn7ks1wnCVqdmfFR5V4WClWZX95/TT9gZ1O2+55URNNG1NVRVuTEsaGKWfyZ5o2
OwhRCmJfAgxI7Ody4bSh49yQaTdCTmcpwC+LmK8TnZOdv3cRaGyWOV7Qdn7j4AqCgkQ2BU8NrKNo
/vYX4O0bSMytWr8v12dGhD+vCwcnw6Qn3Wwek7Av2+P/NbYWqwFf8p1Q8C9gpmQ3hnbQaArpdrXG
A3IEoAYv5y8eMTr/4vf1CyVjF10P2LygxQURc0pKkL4WxzifCspB2mF+neXb6eOTo5EUcEuh+Qtg
LJalUj4y7JruGZH0m99GlPoRSVwLQM8OpiHFzv2tNid5qebeGFh5Z73Ag3uC16uQo+EgDBKfJdwb
mtOCwyE7QjNZGkHMR0yBdGTOhrBKyOU0MChLIj+ddcc80dSYsixrY4zjGD+y1GMcEavOS16xgqXd
WnFrvX4/1BYDpZsDVzFlDcDDaIu3MdpPz5n/AqTcMDjlJ1zXFLG1ahbmbWaw+bFGGhY6zUODkls7
QQvxVr+42OFnkuf9oZdJmQ5oZrJku8BkT9mDqOB718Y0LN5VdTnXfC59gVdtPbtjJ7l8tCOiceM8
xBKS32U2ytCNu4EDXqZyehzcdeu6Y089trQxdv1kUYaOaT9peazlDBBOeFvRdWWrSVC4WlBZXMgL
+jhLg2mk799DTRe3XWZvLknStLGkSq6AV0wO8CJudOjaNuuFtGvYyt/R6+4dIHFiBsxTNeeGMJxL
J8pkzznCRC/t8K1mvQgGBCaS1jKu9l3N2HzAdFOTEuN9dc6bKQvMb4f2bE72Rru8IGvcmOJuOKW8
y+HIk/KzZ7oyvTsOdCttQrbc8wc6WiziqpMvNKJ9+9aiztITxtx3GC1iNEDk+znqYyksQVxBurrU
N2ryVe6HGnwWc2q432e7G7F7krrOcwxz0STPOmOPqF/1xMxTXVykJdOz+M8Usvq5QCeW5aXJEeIr
JOjbWnxH0gJTlOq7C9vpMqbuTMPOkhI+ETdi4VX5SncVGX0KTxpSW1FyFNosGcoDGdUcF6CT9Pkb
PD9uFjzermpdBvUxR7icXoXEhLg7RzmbHKjxVBs4PJJ50uQYIw/thYHgbE39zcMHRdTTjlvzVcFy
qnZb+HKtHjljRRHKkapl/HthLPprIOj+F8POiSXNKSKyIbt0V2nWPStsmSrqj6SZRvdTmxpTbwWP
SXwSZuVTPF37HduhGzjdxrYJ5EK8oXIKE/w1g/OCTDGOOhZzEJVD81TSpdcRagWrkOGlF7bQjG96
cJ057FSdn1lE0aqz9Wx8NtAMAUYmt0RO+t82u9+O9sJjwwaLfa07X9NSQD8v2CE6OpceuzjtSVuC
6uUqIvFe/4KbOjDVccfoGc8ywMgvITgUepv0O4uDT0peGCdbvkmPeOZcKLNu5ERtW5SXqtIhDhYC
uYbfR9h4AZd5OcNccoRAmtmq4s00N1KCpjRdqUmspUREr24Rdc3PcPiyPztmkbnZafJjD72I2et+
u6WHJjgJ6Z6nmOka4Go2TdmcCc7IarDh2RK2EtjItY1eb4wJr2xCobjcpYoVz/3DM9oIfnlCMOLO
ZUgepcSfpNvUY+CWo9xpqDTo4E2upTfO5CaI0aJjGbvxVE658kqFJhMbehJaSWyeMMqVlpVXrVgx
Pfcebxk/m8SFck8X/anLw/UurdHMNXTG6cMw6HBKb8GZ9glxf6ok8qiDZ5hRO5tTDQaZjcZ76yKH
IUPefsy07w5DpGk7XpgjQpJ+XYTBOwwMb8oEXh1PWK8C75cIMDHIDFh2+4Z4/kX71SgxgZ9DuzAu
VyN4W2Acz3lgkmMv/k1I00/h59RnlwSEBVu+71KXqqjHiGangIuqJDhgtB+oumMcS2gc4g2u59Pw
9+PFZL4kq8YsJaBiqstZ8HVmvnhDbQ0dghSlMT5qbi+M0tkiOl3ccxSDh7kdlG+e5A+/tevv3+v3
TZ4bNuyYiC8TTgGA1Ztx70p6iYzQ6nwIfRmtqRGOJ4NuvX6TyqHEPIKwMKxRn81dUb8tTiwX9xE3
jl+PoZTTz0nVAxbqXeQAyinlCAvUqxhXWJiYYqHBb++3DPfenHFojfAuMT5vHr+sSo97+fOMXGvU
Wg6qm4zT38Iv3mOlfJfD2dCV0RJVzK1gyM7LwxesP8ynB4U4aLHBAjXrPnSNVgNIVufrB3SUjjGX
HQgnlvH6HXXr+6Npr7SPDpZ79ftouT7uP0AZE9hoNgcg8oyCRDIrgvxkf0Dvk+UuogIIbDQMhhFs
d+H7D/YmFyNWk6FIr/GoAV31QM+EJWq8JePTTEZLRvv1K846aPJiHXbC61G96rLrVMbqu+3xtjDx
ugddcjI3CxrBS24twZZDzUZhRWnnBcMuuhVIbxm557qUDrfWGb36m3tLvGjPT30s156l5xEfmnVv
Wu90zeiM61L8Cm+S7/Xy+PblgWR/AZEoIuhauR6Gcc5n3t+3kCfxUk+q+FyjUy/v2TTH7CqbBoRF
88L9NY32jrEpSTepQznTNd+K9pRD3OCqksdwyGYQEcGqCD3ibXsSq7Z0jct/uEGh6XGCe0wi6sTZ
hxIAOS8csNnrBTbnhK+XtSi6mmLY82+48B/gx9gAwt+Xvv8FwNMLHT/4EjCT7VNRnha+fvmgn7Eu
p+stRbVUBPbp3SDet1NvyhOq/8mDwGlBsSozs4eMyyuU1lEzEm9KPjaL0uF9U1dyExYtz9ubObR2
1+Z0kLEr3cpXMbfzr8eqeMA5+U0yrkmu3x9zZyOmb0ko2NmamSO3U6KHWQdDtxUEoQr8/GFvEEI6
WmILH2204mg06mmpzddLtb1h1LmWT3pJRl/uvda2qDtTExM7A6ySke22b8aUaxPTkBuBx5SsSVLs
IJJfk5Glu5g/QWoQX8zQdEqJBbkIL/HCSteX3qBVtZqi/3hILCC8cbDQCVOSHTHXlhMFIy/DIJL/
eTIKL2/oSMQrIVs+FturLEN1/fMl2+Pp+4fQty7OUPelfggC604cW/EVJhuPb7PsricNRcOy7XZJ
cO2WP6+L8yYq+ZmxBXfxzsooK+OIWdA/01TqtYAjhQhuL8n3CVjLEwUPJsSjTClu8ewMpNjulCA4
/DXtin3prHJzRqKn+hxRFDcPF8xvDn0vc+uOMsYyowTklwvdLsvCjCuCDviKbfPwm/XVa5fiHmBq
cjvrqc4ToP2O4uFUzxEpWHCoXPB3c6TQLJ7RXC4znMxfnoBRxPtuu8RfGrDS2A92DOetGVhp4QwK
cIiFtJ1iwYVVebFQADAqdD5s4IgE5q7HvSEJZjAYbxTZnyLEnEj6fmDVNV+jCN7s175fF2dz9Q2T
KZAq7mkUdwtPZ+dMdxI3lFTPoeFsmge2BmNp0sUBip6x4jv+UPuWnKwnZyhRMJhM8oTtk1ILSNTN
VgCI25AbdZfiPtOHgXdpJFEyPNoQnqI27i5EbUuukDGeUXNHFY2hkJKFB02rwJYYS1Z87aTb4qxR
0C1GBcN4V2v+8Oym9KtUPCHUL8jlmTkVwRxPd/LhRYtLOsnmcYbhSNoONvc3pGAPdBwOlG4x8IID
Dz161CfFI8vvk3tHwyrhkAEjG2vNcEGxHd3XcpjN7Vm7My76dkmNPVqb3r+vTQHHqY8oZbf/hoOu
0/GHA2IFjwyudpYl7jggBBt93B6ia8aMXJGEQVbxlsK+BEutPdfL0t58+2mn9NLtL0DG4UGcXCqB
bAr31/JWh+V38loYz1l3+qbZ7zNKWHmrwyAVxhz5oul061kn9OxVMj903B8TUz1cLVazQAImkfWn
eZzYm63hM6Eywwu575x+qFKL7SI1FG4pXqg+FLRHlYaSDRjh8mNu8vaZtLXXvwTM92x5p7JK4Uyt
eFNJqIyHl+4VbZet/C2SC1ISgSN5ISiE09NFY9O7yODa45w67SBnVEE0SQDvLs9TxAlszqdRboJN
1gH2uGqjErtLafO12r2V2vUzThJMyo1agWu6f59N3ZlcKixt18u4qjhqE+E5AF882l1zc2izTP2Z
vtoUtDq3VLVc1DFB83vj9PvdcDQjVVmeadm3aryAdalOiD1aBvYpTg+2925Pbj9wHkp8L1o7+3wQ
28cMw+rUk0COnPJvAtYe4qF2Me3NY5d4Otw73IW2Bb2E8gtHO8gTA4f0S94Gpdw4UHpFKksN60Cd
wpzaCR1qSlm6zRbDNPMtsRElGBcfkDACFey2p97fPz+mVWCMl4hmzh6jwwYrefwXc1lDCweLMgt7
eQ0IuIJcQbHNmBO03HHRq1dFGAmI2y0B3LVeKZPv6S4V7W3cq3ECrX246LNmhMMJV4jHppkH3Y3E
nv13kixLbPg+9jTTrKakxlT5gpWtoiXtgtNoxRxxBSrUijD8dWMj0+qY8s/fw1a8Rg/VR3x12kqt
ERjOun3tW1b4/SqP3285Bk82FTw5arhCg130i6e1wXXfDlHrFinLGgxTx4Ajesa9XNi3oqeFv54N
tRlPuHM4o6NBrtga7L/tWQq31J46PWaxIthROTx999SuCP/AMws1yFTFpGLNKruHpCX7utu2aFFQ
v5WOIs/w8DpDarXvFGoU1DIvS6N3g2lVDJStV2Ppzfp+CdnpF1DqBW3ZztlscuQp6SQpIv+k2RKh
D1OlgM1CNjzVoy5xLQf5xBdApVvmtLU7jBFU0T9TQ+fqpFZPvxRQThjhg4XqVB8JX6ftdlC7Ahot
i/ifU5N2WOOIDzc9dahIIyF5Val+VaFShUVnkibbRrn0n4Q7UfajT/L1Zg9kY2eljHLGC4iU7T98
CRWZbxrUJ2BNocVTHKZ44LOuq1NLplig932j6PK6SaiRjJVHTEhTmaHWEJ3gE5XJK46p5W3kx26E
uPxW5prS3IFph44YoqZVtDDkNt9ab5icFi2NVv/VI5ke0UoD3zMl2aconQLLoxNBinrdiq3UK18u
RFliO6fCVlKtfnRiQpoWV9EpbYkFK1mt6QHqQ2bmrCUvoa3FIF7CoM9eIQs7QQXrWTEPBBP+krYk
deDB660ze0ec+1kw82CpuGo/G35Zvy0Mh5pDuVpSzd7GwoVGahMZU7HVWVebVYZdAilmhLu4iG7d
dC6ddjb3/p6lz1b96/Dtoa2xgdEOSnzN0jQ4uGbp0CSlFXZcoiXcDHWZKy2NkrNaXYp3ak1WVNVd
gwwA4FvICWc+Iwsi3hYbwrRLCxCd8+JadpIdurVewead8q66QPCIUVtj5ppJLgJ30KhlUzTLB0z1
ZwZ0KYpRPTU5EGOKjtBu1+tSPzoFWs1+d4DfpzRo8mB8eCas00waprXAHYOP3yXdLKdll9OGjU4F
8MNVNfMAI1gVdAb0adiTk2rN+N5ny25v8viyq1dwIUMem9c2Buhr75ClYJAJWyMNfPR7yGnEMN7J
XROhQr2oALBhtCYemOG88kkaABF0MUB2WR5QtsWz9Vtj5a6owm37g9RLRaDGr/oevlVFvYJSays1
ZnbIKNq8FKcMcA77EdyCHa3yLXIcNwDA46jfo7xiM17Ygo5f0WfGdS3TY+amA84jBXI9Lq4w4Tol
VMXz46QuDVnKGDaK0sn8jPSaUFEdT4Qz/zOF2nPcOzozn4K7Y+w6LN2Cz9x25S8AzoJz7T0tlR/2
ay73pAIDgBSs2LkXypGGz+vPw5HGsOCGFXyEiEdF5d+lt55tq9MugF2vkmVqDhM0rTkQzZTrStu4
lJr1DgAyhMnKKy3TpwMowVtykrJM8FJ/Ve+mrme7mO4dUbPRCWkKQWcPvGTdLS8tZLlviX3PeleR
7mz39cKNJUqlGK819txmG20EJGvqQ7mPuzTPzczk0OcZB8Hbw2ePAVXoOlJvvhL73OJcM6zSrnGV
QYSamiOPyHYpSkwp2LBywHUGMNJa1XvPqKUcO7Qfc1Lv71TD4J03i/cQOmBqbmQjvofFP7geRi5+
dDQPdC8O0ri4tAkwlqnrPFWg8Mu4oVgyqXlWY5Xh0xLlG7Fx3zPIELhOU0MftccWtLIkzuvhWtiX
YNMdKtLlwmvzPW6dqcp8RpduwXRw8PJH/QWcpggUc0rvgbEe2NuN6fchbMFHpFCCkbuNDLF5Icqy
1/N3bEqyxk2v5/8FOCHo3QhI6+yQ9GyMUpGtD/AOafEzaWNPzk0ptNq2Ib1oWcTFnUYI95LO6Lkn
M6YrjnqptshT53pg6Odh8AE5mPwUt78Vnzj4oX2iJh5xXpDEmd6filOzrm+0srmScXK88OEXxkv1
9CpE1SR6xzsxwGcLiIOn/8JIguRegpZc8LxArLnFrg9cSIXQCHdhLnatq0OaQEZvUc+Gg40Vq2t2
zHUUJzzVxGnUjZZ1+aUYY0p7leFBknHro3WTodWspHbzhvcLKO+bykCDODbbdQE/rAkqw50etDUc
CBOonvHvj3+lJ6WC5JTjyIbxkgML7SKtQz8sAzDKQnJJSXTTZ9Vac+zqnJ86nHXjq5e6zrIfz/kk
uYRx9kvju69eJ8yAEyv21Q5+KIwyrG1tLWsX0Xw+R+u6n+EG9rDAOBVXl3q+KZNRsjpZEg2MaLE3
ecugw1UjSjTRERUtLjkZwhHpIoOSGqebt/JEw9mAJmC1uB/TgtvynnsmUdUn03YclpTOj4zax+zJ
fr3gj6GWMXtGcxAU4AGbSSXqYELFAOQ+6rTvb2DT3XYUcLFis15MlIujqIguAjYtuGdketsI0n7I
LyNjSmZJ0JLG1DTs4WBnOMWW2NNFtXXyqynw5nOiMDRzmvsLYfEZq3M/l6c+B3J0nlfSJT4pHxS3
H1NvEJlijhGdX+ZuwU1TeK6M5FNktX71lNuS/4CJYAzzCmU7wblvbSDrHQ3Uln3CUnYrUVfkt4xb
VSo1O6rCxOH0K8jOVTaVjZatOckDnHTrIEBinlclzaMKamB1p31omCZ5gM/XsjPfl5iIao5QcSGb
XmZoTW+hw0fHwJn6u7V2XS8xagxncZvHulKXtbWtdJTOLPTj51QTfeSmUo9nYwIXtICYtHGpGS4D
eqOyWtdaAqFwU7NtmLWXpwuldnlJcalOxDXgX3Q8yihoHJinyXtceZ6rVcnSc4RFbyDqPfM1Dtqw
qKQ4tQte2RHEYF5kGqsx1hlXt/owVK6Vgrc3Jz+4DUUWYrO4xFAS0Ey/XiuwcMK9BR7zrDlOLWUK
aysV+6zmutiAw4fOTkMSvVmkCeuN5Bow466xK639lERva9SCkozqgkZDYJ1R1AL6NdEo16wI7dI0
LaA5DX8qKZtqgaZRS3gEJTudh0x1yr2mG0/Xcd3uWaN9RFOsB+w3702vZFwXrRPVPizRoTLxIQMV
ev40yJamNISKqYaj1ZXMkFPLFqdVh8sUqLCLa1dHC9m4tiHDyaBitmfobDWoSK5BbacAY0ysoLlx
YVUyIygqCiZg/mJWZM8TBQw5hMYMhzYNe6PBNxXLDlVk8yIceTmjnnBeUTe/2FgeJtl34ysoSA6k
6EBOV+nmZZqlNyost3i8rAgYhNUqSQg008mZXZ67NnUnmPQkXCWc91n8BYQvbKom5ybdXoVqxYTI
gxk/bncvhX5qXMiQHTFSAjVVRl3uq43NN/9Zk6egKEMtHd0RFC8/VDRLevqnWgRhLy1KEVhSjNNU
MVdJH4H2MJBVr9mTLn6D5lR9wmsQ75RZqpm/dM74QC/UNtRV3w57gtkxrC5Gu7pnoMvNp8QBRRHV
vsQKHr9KBzL4C6i4ysjdZ7ey6TgWUJ/WZ/qqgjO7gmoR0+ImtD/Cq4+brbRq0F6I5XG0B+1zzmCW
6fp+pMhGp5mcVFum10CKocFCRWBTNufY8VADTyw9uMlNTCJb5ecNN4WMIwXqnZVaoblHu7gfQ5IU
oLVakK36zKwRTQaY8mDWBkb6HZUOKQrc5i/G/D2Nao9asbnvW7jJh+R3wOm7LunkjWvWXqNxIM4s
ZzZ1P4XCMlAyVlaFIvGUsO1UIn3EYuo41jjz5Mg0HFQq9KR5V9bn9Ok1UrlCmm0aVk3Y+R2dYNLM
eFEkGT3MpMf5RKi7Y5xkKpS20PN61Jt3fKTnpXjHb7rRXOxUIzhnzgS0FLYN0vSzo7ooIq6CynLE
i+C8qSrbGNJUEU/ijZ4TXN0X8nof6yoNJx9x4ODgH615n9Hau4PcTOvFyJjj2czT5V20LGIVpdBV
+acbqMmC6LM6o5o10ZwXy4XJ4abKANcprs62z5TQTSV7L+5RJUMaKJmBKzdmv1mu9HBUhBOu6qhu
zVC0Wz46HO1YIBJl+mlPG0QatEyP1fzlwmUp5/Xc82ps+aplqvYxcUOoBVaH5IsjIAqalzYWmWkn
XhCPE05aPLxU2LO7ny2eG6b5uJdr2iAFBSUh1MWHN9cQ1GwoGy0A6GD6qIpK+jRNJvBD0pXOSflq
TdZ0Z+oudFW6XZ336Ehltde6Mt5ju6uzWLnJqwbuQOULPp7vKWK1uHffDWtSjct/VE/6CrtkFHEY
LPDPteX2FcCMp+qKX3smca+vWSUnXXqPhUGBpqnIYIRsOnoAv2R9SpdNKfaEAZa7SgMX96ifNTVh
YUF16qpgC5jnYqwARGgglSW3Md8v7BZFSdtUxTf573TJ1E5YNttA6XjDI/4XpqxouLpQquyQSgcL
NO40V1Y3Nmbyqa9nDNIzV7XbZVs0bvGWejQyn64a3rpxjdFNl2/+cdDtApnsuAszFnEXl8eDunZc
dN4t48XhLnF996ie8WJPBD650DKtEsVoZN7J7fFCPIhFdmgNt0Tn9exbTzdY0vEzKY5Z5oTRsg3m
28/k8LgdsLA1Fukj96w2ew22c6PMM5NbTMxWT69R0WfjFDqhxNMtUdGFmvlYPWnJIxp28ftGlWnP
NLrRHUf4u4b66/ijsHZE5WtGIY8U+sYKlPVq0lsO5s9yvD15UumWqvFEwBgx2j09XWq6vno6a1lR
WSV0TIWwIMN5+dAUS0WFvsawD5mLyspCnBy2iboqtE0vJay0RrMEi6a1aNm5aFRfoEeM519ADKXV
oRULWxuczuG3OIvga1v5NV3ujGeXsA1zHz4BQ5GkSbg8IapN38k8jgG3AXFDC9MWtaWkrDvoEukE
26bk9jGy2qhTwVL+B5VLgS4K7ORzWy74Pqz4WgKQvH7BlsArguRFJvOSfVYs6d69Zrm0nG6Vp1xN
3E/pvAQ8vtxQEYrnY6MKavI5bPVNLDW2VIxrI0fHPImYQWfj6jnT2yOKGXCH0eOVIpjv1zvhFE/9
R4KiXdHoSJHoYWWPiBLJIshcWxRKFhdnDrbtiuZ9k/zxFNsBnvOe+cKbjxY4NCfaeFRY9r/tCD08
bdHlxdmlYJQKpw13N+R3F1+3lRyVuKThSG2KEhvSyTRgO4WT6lio6pB0beEEHPUiS88M5OxKVigo
LmjD2+MTbLMvZ2mUTeGSxdvSzHxI7340X0uZzRE1Bqcf/Jkfh6J++5mmQbcBVCOa7gYaOfbzfet8
77o2J8rCxlKiAnvADJOECeiHhGjcOx2JudA5SUlKS0nJVpKBWOW7pnGvQICmFOggPSOvQWCdMXYS
Zna7oFBj5YUgM7C0j6OxvOIDzxdJaGAhy+Vkinu2q7PPI6p/9z7HiAhX0yCrzOe31MzMUnkwVykH
U6lAJvT5CzBQU982TVm+hpaYxQuh30qXodp50HK+Vu8k3e8nIIARnUzLoLDpwyduVosIFVvxipEd
lR5I07dkbT9VumZcm0mdlLwJq8CAKTjdldi7Q87nDyC0schk36EGkBeHZlUA/gzfg/2OGB1UZs51
FpiUN4Ja3NPlBEx8FQPKglnNEYfWPZq5ZVe+R65Vjm0N7gA8qx8BtBQz0GcoIt6A98kTiBePi0l8
zHP1dlZqiLtdUZg/gN/+faQqQz15p1vsLzvBYT7yUK+3AtAHQmO8OouIAvYmPL1FkYV7v978C34c
E+MOP7pk+LVOXyswakr2Gv5xuN/l/vD/Cwh8QDvWuFj4EoeYcxzjRiUGQR/PEaCovL05TIyrk/zI
8vsY/ZD5fiYkkginU2KlQFkVAkpy6HIEJ/o2ACDZ+B7B/xcAO3tz9T69FlOfD3F/+8ytIwmfIkcN
TlQEcPT/GNgf3MgcjbPOqqFqjlMhCYoCfPyBvds4fzgIb5gThz6ljQ4gWxUmWxV6D0zsjWdlLJYx
H+ZIHCqBJonsCiQOvv3xUwkeJ/f7xOo2EYxggeRHt06FrjjmEIjpOU4dkMaNwjTqjDIZwFHRHXrl
KTaoVEH77fP4NTASPxLccAyLWAzpN+QYD0obxOysQ5fOnuQq0v/shhQhLn71/zJAxp3sMbHL9a/T
p1PBwuQBT5I4XhT13w/cKITDoZtsUVSr0IRwmEtK83yXFAwSvjsTZAYDU8jiRnfoJIWFvXtx+h1I
LBQMFD3npXZzOgFXRykcND3Y+/Srb8V/nH2g7qU51g7ae31c9w1bofs2RfV1LynYf/xpL2zgc4KU
zny4ICwPiBh9QRlsHDxcic+Jvjsd3NtwegT7iow3KTJ5ZIXZBidEaEyRKbgzMj/dpjGyuJqNnGMg
DMmxkA1R+zRlUUEa9HMM/p34ev9jgq7jlE3m+5RoAAnYMS7q8c7zw+Pvm5e709+fu+45eQOgKP9/
A9OJNHn/28fHBRYKU1XQr+1xo2e5LXxdP9LtU8SPHiuo4gUSETxhJFoS0WF0bwqcYnDWqbcR74Wo
V8n18RtfqP8AgdPgwenH60aFK3hJVaRxofL5R+RrpBL7Y+KQSOLbv7hl9fHd34MbfgXJg6k74rqP
eMB0PaiKrItwhASVIxllcvz1hiuBRJwOI/B3rp/IozvK8SIvMCW0K4s/SXDlERUl+9uo6du3gH8L
8ez1LwDwF8AsgN4u+HVgqBjcRIL2C3vOQ/Soki6GCliVVjoHDk4KDk1rLyQ58Au5+O44z0dVBZVN
g16Kx5aiRVyVqIMoEnTX5ddJXBioxDf0qzDqYb/gm3EYNlK8EURed37cDb/GQ4T6tAvvAfo2eq1u
vcM5qrShAuOeaRBbcHh+m2w5E4uh/f0f0VqSOSBKcsbLV9TwfBcin1usDwIfG+6ZYt3SlrD32lie
U2wB00pJbit7mRdnCEaNa/U1bDoYQKRFANZh7L2MsdR4tCdkgg994dBy7c9Jz3mWnhDz1rElOyoG
6zKlWDYA+EpUUSNqpJaHeYOxE+B6j39GwyVHGOmWWjYVut36znhdRrFqljfOHCtno57eYtfhreYK
IUFdrEQNgJzLDtqBk4TYkpb7wgFbVRoJW9NoyN/3nIxEJ797lEX9Yj0ny/T3p8Hw2Alw3jmeX7k/
djMSN/SxXm+S47/X/q5HQXyYmo7fqzoa/HHoeZuKKqBW+VkcZQL5L4R2eF2Oloezp6ZF/hInG/jy
uxn8degGleJ4U53CHmSOfTM8Y/dCX1SZSU+AC5N7YjTI4nxUjAuEVoWGQ9ThKx38tp2xrKfW4cEj
UqCzuVy4zKweMjv/63ptJud26J2Yf5oDu2orFqknY71CPvWqrMXKAwnzVB8hw5EhWqwdNoI+2gFs
F8JWBWGf7CM/rN57oFGmmzcgLZ2HTlJOaY0KP7YCxn0Z6nfIVAqI62foD/rEQDbeGgJwkkqYn1+Z
oeTNNR/GGrlDPNAOTMvrjP5RdVk9Hwtq1ZDr5ItxV/p5nLUxj+u/p6cjq0nzpxNdhFKQwHNH1sEd
aUnSY7M8qBIflnFZiLcNTqbjvGIz2wba940m19VnWx0cPIX3RqHRLgzNr6yba4fudCy25kJcmQbl
KxdGPw2Pl42Y9wizSGGTQZRBl1qViAsan/WZf3odsiKSxhRns+E6UeZL+nlMYhpce9TuNy1k0nv3
pm3CciUjBIws2zWD64eYuMvSQ+YeLuCLsqdzuzhzFlXW0am1rmImaSkrGZYDgdj0GSLVW7vCrQrV
/hTdvBvNmp3sWWfCUAjjqSSdac27+DN1uZEKgmHmz/RX/NOgVfKpvIxgKAy20hpulYknGbwLWtvT
0M7e1RP6zRibKx2IrUv7U+pk58OPk1aeoFAZ9KcOdBVs0zqioZkUVVzaYS6HYRLCsio7/ny0yPtP
fnH4QxbrCd4r+iUK8vVfzy7Xb+xyZwtl5fUiBHhbOJiPm9euzZEW4KYO1COcovJFleMNoSVjjGxq
bUVsYylyqXKxjkQ7843YmJpj2xLyGjZhGRXEGE5lnV7JbVIw2r2Sx8t6Dz4EIvok2BKsejbJzVla
ZP1HzLVCzNVELdmZOa4ptJsZ0SAX1rTbTlsxLP9g9xMSGcg4933e+mMEjbzyks8kZk6t9I+0HGd4
rtgqtia52RNdQFXy8rTaPB4WDhnhxYWF/Uyz99K24jgMbJWntNDaGf/46/o4DBJYah3Ouyvv5FhZ
vWeEunvXuftuOIZbenaI2PBaBy13N660ahlo77C3dC05nU4cTXJswf74AlGddNXCrmu9HVSmvO2q
EJct4mFjh0mdu5UerNV2xB90hMatdLXoRIFquJpn9+ajEbOFpa0TLkeRRRDDj2CJ2WWnd0oq57J2
90w9vLX/hKfyF5BY/NBx0kNcpH3H00WnQLR8D4cQTqvND0qKHgO97bYKmGpRwUlP1dtqllJzbWKd
1k/JjHfG4NlImeqjsfIloWeQjuH7Tf4mMtBqElavOoF3UDog3WbDJd+tvWWck3p2ttoSSGkXk+YN
zZfbQrTIqcUhdOUFzlQlZZU8rWt0o2hy5lX8BWDEv5Ns38a77LMYE+ugcCVbIQn5qg5XgJKb6KjN
CTuDAxZA88Jn3PyC9vB5c0fjlGPAght3LgfoSdUnwq8dAlJvRq2RcizNYvw7uhm49YvzRrHerE5E
lG/Ozyc98rr54IsjbkRU5JJ8UeZDaFiLyWbDGgxl3jZBAHgzPjCefddS52YT8ge82ZyNyKJfFSEB
lsUERCe584xq17GKbd/HaVr6OwW8+QqRyBO+vWEwGJdjEAKKMpdhH5A/ZBjh1bIqyMP4ZKbZ8ypY
/wJuwNBIWh2pPvbSted02W/SlJHQjD38mmb1C8SHfo+ZlewqTIXEtie6HxmoB8xVZ9XgqrFNqcHi
SiJsRMWNs6VLKmyhQsypomdB/ACnevgKRBaM8xhVuyMnCAWEJEmYASL8qd5j7cQkHTJWYJ2tT2IQ
Jwl0kSXGXs9Ki+NpT3pO2Zod38K/1JleHi5dPeR4Wtzzktm3sWph1eXibaAXQFhysUMUAAB/dEVA
JS28bUK+yyzG4WWBQma3lAXjvHmlLjVsisp9WowSTZIzUTAhkLRurj6SVMT4adAvVvbalu2gmCYY
MfQPTdTcdnWz3EVPfgWdniLTKhK7pdakYUc0SSEpu5eIcN5YopvL0THW4XdMVWZN9ShMTSyMU7bu
2R7bjEon1mdZfo08f9tjNP3WoS0G4lZpCj4eY38k8/uXm8vUhEpVtV4cIZa3vg932zo5LqynZEh+
4Q3icLYeAXwtNeNX64FW5IPhL4ErCyDCysv3wPdAvk8qM+qhP3o9vhIXvFD9cv1q6arTOPiaI7z2
6DSxPQX9FNtqehP9ruhuNSzkyo5HIbB4cuQogj4+vveDw1nKylsSyxipLu9xXlA4upMejFXD5Wq6
Jys5bh+5Ujw1RH+QsSBHFG1rVwflSw1bkttalvUfqC1kYu6F69jlsz+RlKmMS4uT5Pj786mjNYwD
lDWa+D/tSrRCzJr4YkR0xl3JjbdRD8I16vXP+jxy7LdjG7C78ZKZI9sHDOfS2ck+Lbhu7qZpzLy0
6xW6HMdrbHs0KUvXPJtjWmqoc8TNCIt4XnLr/QuEIEPAXm3ofuclVIxFuvU1dGaRF/x+7fRxvLQg
/wuQXRW0SXIjrqtvpMW9kL2khuk4yVEkXsLt++Srj4A/EGNK0YMGlyd7fGFcDmHs9awvlHgAYw7b
5DNTmNleMVdiSDKrM9j8jX08/XTJSO7IRWhmESY+igWlnDOtcmexNVxORkSGgnnRWsIbYmWZ4qov
4sYQpkDTbAyVpDCJHzfrHXHq27W6GBrTZtEFZ5ueICyeCMOK3qR9IVudrcP7J23X72cJX3J+qOUM
UolqSO3rafJtdI0UXI8es8psW7srFn42sprcqbt4rXs1TQLFdetyPQWUDReZ3si0lNzUuhHlc2u2
B5729mSD9BTj9XSIHOEpPAsOpeTkdXL6Q1rEbyOHCb9ED260v4Ae15WT5zOgyeFJ0zV2fuuAtTGq
We9uD98DOBV8egMVnGcS7sMKho/JTD3ml1To0USvtDwI6a4B1dLDGpwDSlAbFPTrtkrysMaqtN6+
ADcT2/ABKlNkwYwvlyqmZhs0bmzDk9CAgTqMwH16xJ4crKVW5bjLkKjze8mx0f85SU14yF98Kxe1
zoBVSLqRiXNkllNOwJ+ahlhG32EyvV6Q0WV8pKGEqn6pZngKt85cvmYaL3SYwUo0ZQTymBFpUmDz
57I3dTOBeX6l+KyscQWdSjp2SqzkzFiNrJw+YcqcyUZnkylufPoYZlxsJRy3+dc0/vjMdFeybcrS
DQ6ffUOy5NkUDeeViOiLOeXss2a6qJNXWPnz7gudXz1Iz6lUAda41nuDSH7flSjjMcFR+4I/FJJl
jjEhaP01u8PLgwj7W+2aRl0jFh4hfEiKaut8L+ZC7qm/TX6WSQ/iB+3G4X0/zKDuJ84iH3+9Br49
pi0aDzSdalLS1KyBWVbD876iCx4S76Bjn+BsqoIg5qf3DZCUCzL8TsQc0Ro3hbVDX4l2wqS9e1ye
uCH11Tbzm7W12SZVhrnUhqhoOPftyXdq0VNWz+CmGwoNB/y5tuWMnLLSbJoqVI3f3n1Mv5qVDiQ7
JoGwxQcqS61s5n1L1nErcuq9VZBVEh3k8njWI2CIpEPx7tavjslKe3mHFAhc+O3zjz/8rIgYlw4l
0K8b7FmTdTebpxLupVKXEqMcuIAicdUb9MilIGtsO8WAasL2XgpK3Csq+i/xQwvNrfKKRFBOPdpG
RF/A6pwUm4ilkdg29bQbE9sApQyREXZCp1Ws/QvPLILY0GrRttbTTTxOuG2fFAhPCwyzXO2dszyj
YWIWDwZ7v1E1BrrJgXD7XFOKAxHxbqv5lj29kj21iymCwRN2cqXJmnLawIfIxjAuzVy/mluuxBJY
QanPZK4ag85StturOBMpGoOT5Z1C3Lv2OUvw3dwG0nWug65Jhg7CsrvbNZmUhpRhIYsNdjqYvb+/
oBfxOd+/9HSfLamG3XWMoCtNUeNNzNul4WcK8/0qyY9vw4/07Mh4Qctz9SqLMIYnJP39Mly8Hl4h
LuZxqYKT4NtKsGvnf4wzZ5om1QTTs6OA5cDGBa7c8nFpSPlT71fQGeJ9elS9YV4LFFvFiwbPt90T
homnCDOgIonMpNaMlB2ZNpGKieMT/piUKzN6QO8RY60sIuW3lvgqLk+SPPVaOLxr2ll/vOOrK3f4
i3YSnTs2d82Xkw5Tj6h1cSjf69Wn9/ErMAJIJNDFsmqTdNMMH/41A89cCXlZ4Xh+pI/nVgkD/GyZ
xIgWYn2qg5Znp4Lhn2OLrrJDDM6O75vnlDcOG3HWcQKYuQt4K9OmqimO+iFhDPvuwe6SP4xWg0CS
Fwh11OCH6Lgm1ynLIydd1PZEs+sW15yiUT2SfKxID1PeKM2dq4rYlfFO67u+I0vIsxRSy5+kfLlE
yorm1lPnblGyVBgpczOFuliU5wS5eGLYXT9vQEZwCckUNeCoUrC/j9CkZJTX7p4ix/EepAN2fGtn
bAtGQ+vae5+kfD5mXFmFOYlJVxekdrWrqmOiH0fA/d9YVYIE4Gb7GXUquXyMSo8+YlMddGd4CE7o
bBS0OHKaDc/2ubMzIuXcy+w9MhIq83C/K6Ox0ZGv2zcnF/OOWPS2aev2lqWp/uRfm74SjMXRNePi
ZwLJpmB5lLN0WFia7roD2sJavPDkKBlTRF29loK854e7Z78PsjpeNnpZL0zTjmWYXPOXYXOMlJSD
a4Y1AUzTNraMPHsFrWBtZnF6nyyT7E/WW79d2GZIqGcrycuPYkKWGLAzUQ/MH8r2ffyS3n8rugjn
OCGS7SULbNakpif8hAwi2wj203Gw44q9cl3dJ+ahVNSgf8D5Y09gDBc0iScuund448r05MxhQ/gl
rPxIJz8GtIu6ZJjPlWKu+QuQGbNLK2upw4RmXcWqTpAQAA7dnCzw9dd6xDcrLyiFJZNw6eIs/YZq
aFa7JqHNtfw5jeKd4VyMJltDC0qTtCG4fkcMFaCydrDketOlA2vKGbmZ0Vplgkq5Wya9v9oyPyfo
NX9/tLKuO4nldntiQI3xExTrG2VNReYbKwJMmMvhWu27HqtNrEryzlItJg/lKMROzd4LDDxFH9vU
MoOKdJPEenkwvCHwRFR1I+W50lyoESsWTw3y98Wa5l5myhK90L0KVi8qIM/55CnAjdMNkPN+jeln
aR81zBmsXX+3bRTbHQvTv/uQJ0xIyIlJSvD/XgIJ2Dcx3YmSUKmx2tVqB9/Jt7zhXpx69rCo0pJ6
cN3Cmwv3JTcEF4RknL9Fv8VwDN7jooBSTWa35EiDzw7TAiJ+n1jeUJQ/of9imUj2rM4FhizsUs59
15EZk2w2/TrgoX3evQPNcGV+ubynVqx1vsykRvwwOhSTN2WyYYCTV1hsUtaNpiG/NcDPpTdhHKez
lHiJWuttzYxvIOGQ3L3eQj5koo+V/7TM3FSveaoO5ZT3rNUI46FUh8twOWSXPN2tvhZ03bcdaSLY
EjEMDd8WXt5V0mvWSe3TrE3VuNgeD88pOVzKUZAWVmVNjkuOlD2nr0uWWnwR7YMzTMLazfvhMMTw
NZxc4f4Ip9J8MiK7b+ej27Z7o/as3s7dunG9cEStIq7LqiXmhvWn2Y7PPi4aVVe9RXWE0hUOT2PG
9M9p/UVqcgmmD4EmPVc1oWfU+AId3HabiOQSjIu6POZIxf4QWJji7cFes++AIbm7aK9EzEZSEvgQ
5JF5UIWzuSJ46JSwp/iVe0zs2SZoGEjTqpqLcjCy4ZT0FBkWm3inTGimp3JiH1mqc0UFoqrlRCw6
KTMG1vP2gxXjsC8mLmgmcbqq0vXpqtWoU0L/VOfE/UHENWRLopN6GOo8norHubLO0H6ESzcTD9Im
luHz9MDX2agcEZCjffW6EEAvuW5m2q2LLUnHAqrDpQjhbD3bJd2gQhCJ2DbJ91IwX6aVzWc4zGZZ
f0mm3bJFJqd7gppODDGCKoSyks3jnzVIs3TVfvMybXhid4aktunzAMXlxGxvoG/7LMCrKgOuF7bU
n5U4EUkrr6kFfbBKwLUTyNOxpMSkRmXp4IeoZXF9a7LHLtmLnpJ+jOm4JtFlz0cm/8Ep+5psVkSA
PZ7biN0Ydyf0SBT3Laypc7OwM3IjlnZz4V227JvJ6u/S8BXupC/Fo+Nhtn8IIOO0vDEknPKkZTb/
IZvPbuOT/7LCZDH5euRGtt3WpjvGRjGRHonFP6CdejBR+oO8EsNHIdrzp8yjpRvddHfc4/UUEczZ
Ac65ho0yJSEQ6zlsIRjN2hhLRyMGWi7ZLZZG9HW3eLNKymwsAtl9lTxl94QVNrlLm3TnGSutpssL
V0NqvuKNsRb3Bd2NbnSkLAQKC8f7Vk/oaIIOjaajbbQC/TE6tTo7CPnDnbfTAyOGf9m3gZK/WlUf
C/2QVzMsJjnL9b6F0/7pL4Bo6OJkS6jvCCgXWYffPe5+tV7gjCWeSxJ2enLL+SBQapCbvLQJzvbI
cx4tKalx9RJpS5DeB5Qwk69dHc9ikzeFL8mZ8jYm22aze0cutMOy/RKKUOv0ip6siK0rzThTS4ao
ZbJy0TKJ9VYBBi+UxuyCrpJKqLmCEE5RrBL1WG9yhDsZ24389am0uAO6QRMvMhyaWzVPiZfxOOSM
R+d7M01f2/izyCE//wKsk/1/QQjmimDO1+maWsDGmhvNlmijMa8ku8+d8CcSE0EUIeC1gqjdulxm
6MjVcGcIi1S3Y/uKeUqa5IubkLiR1IaSzrHTgNMmEAK0fmwoeA46GNzP5wILYzmZy7i2XiKySzbQ
Y5jX87E3r7ddaa2eDngcGZ2T4hUyLMVHlemJxSvbVTFlmvFQpWvL7LaYi0Xmc2AhfwGc86AfenEq
NizEeisDp98aXeqlN4stmrSYSqfYK8ZlhpTl0gUwlHWMixW/WXpUeaY2GqQoYpCunuqycSF1dW4q
kO/lLHJApfpSOi+TjBp1pnmHhBDl3Jtjyp9u05yxkMdHFaPMEVZcEjwzsdg63rd963cdmpAH3iwl
xqfH51gxn9yhbLUmxINOMfPnej0DTVstp5lbzl/UyMY8j5MDe/cW0dCJfrDCQUUjAvCbqz1whDnu
zPU1x605Rt++M3N3fvtoQJpj+fXkmFkAmlOMypT7wKAlLMidEjDQKI1UeXBdZ5ykwRyQSm4dlyeM
HV1Vt2Ng3u8n1obSsJNL/6VrVYuOu0Or8eQR6eroOo7lNto7q8y+2g5tC1fPHa6amVxGB0eCf9mV
Su9uGKORtGIpwHtEf6jiaxYNWUKNj5Qb6FwDoXHdzhBufidvark9jcJkqCtKw8M7WU69Vp0H5oM0
RxscxAcEJ5sRoI2ZYfbjXpKT7nBm4BUrkYN3VLq/qpTB3OG2T9Q04HUONIVUo1vV+JqxYOtxcXII
b1XcpfMeQrSIVgI3VCMtaFY3NSmiXO6UCCZShZdXDz3KJ7R8fhdq4KEE6p66BqD0KJ3s8bCWip0o
Vnf9BRDsEc6aGQqrHxdMpCi618ZokNt4UCeSGzR7bms223cqlOUJlAA7HEulYrKIarXXdvNr4/Ju
MShV91QbuukDAqgfNluQadma1O6+afZGXmePycgPGLEFWkouORcWkpSEmF6MKQtOck3kYFfzxN6x
Kt8pdNlpRWXWbJqZ29/qeam67/eNX/syW2Y6HGR7hZmpubr7HRstlt/BPk6sbWPd7pDwMOiUb57j
au6NjH/njYtMS3aAvlwjtY6yTEVotW1RTbC0iLHuKiPOhzI3l2fMTrcipfvV590FQUcKuEmLdVwL
8n0fl/akiqfmb5v0qJewuTmjq9ar0rMeymYh1FucPMmUGhu/taw1FQrRpjeviMjkdE9w6S0Kvdw9
bZY6I2StlFilu29MNdUDvV0k+Jsf8Zt6GDLB+FQAZ21ds20mu4Jon05tlV2aTqLpqqeB8XmOcBIN
96vp/Ja7W7Xa7XCE4SZeBMgnN3jaarZVKZ3PxiV5g2UCiuC1KeiJ6f6+1RtWObw1rL63VHR+4Cuy
NOKxWrqc1FQVW8wl1jV7bfCN6qqSM+ZBGiwc4FsVczsJ6nY06S7pL5E6XkJoUBRMTIaW3dl8WSLk
SJSw6BdoVsgaLwTFIruaOv/zjL703rG4ll8qmCfAFMi0dHj0FWZFOe6f0ZLyVdE/hY0CVt3+Atgu
7eD2/j0V6eKK3aCmCX+EodMecOz4Msi/2vJik8meY4pkxNlXWLgk7LSoci/G7BVm89WCTVO4l3FF
sXnbXxwLHxqKmMXLqVg+5M616s7qmD4zEKsf2nRkVWLtlppG3ny3atKuzBcomRzXqhOQlRlw4jLJ
TtERtOCWaUl0PmJZdyo9Jr8I8W+ulddjb+AT4o8UoElG0jRDDdNYe3qsnhRlQCHh4j+sDVgK40Pz
rUJFtsGGIgtb2AkJfU6VzclsENOp5yYUslfqV4x14jDxOGq34dwUlX3xzy9P00eAOxAKSrhJvjmL
Upch267c5mOxNrIqZX5Sw4MDBBnSkw2PVOP4nKaysjc706j/d9K/Xp3L7hH6xO9be70fVIFexJ2E
svvtJLLs6KZhSLbpteFprID5CSjEF3e1uMySdJ/r276r1kI2PnhYXWZaxRGaQ+Mr9uMf9e72fqOf
iL+Y3IhXH4jpgho502TYJEAIwAzxqlaqKWMZbL62tQyP+QBHev/Rmn6pEFsD0yy+AtI2eN87czQA
1HxXlizYHEH07HMM2B2b/yly8R0yLP96+uN4QYLCNZHiYPC0pn1GzRXNymL6FdIEdBfz1JdrKTC9
qVTIJBLk/XssIjXa+iZts8UTKVNHnxFSC+tI0ASS1qQJDpDOagJFFEwm74FNtaU03Auv3PetEviV
v71NvaBLdWsyq8tA22e+TK1OtlvJjGx6mEed60kmQNfVyRBJTiqFDHFdQQ7N6tCEYkQWLu9qT8lP
DcaGCkY3Y4K5egPFhhRZrQGZfoL65zMnxMhRwl7ZLJ/XPK9fuWXXRn7NQq2yrU1WVntPr3hnP8NU
oy5jA+QPo30nzMY+T18cY5mgx6FLgo6ehAyPCzDfw/+B6FFwxqFBLRpopzgvALC4bgW6GXsv5UpW
sH0KexoWM9oJ32uc6b70gikTm9HMrzgTc2i79pHS1jMuKGcKlJvqIKhiBR2FGOaEgFOikgZHZlWc
sEkidD2CvZCFziFdRzkNbHZjXr/5wM1vge/28/WCsckiOJxvwUeSif4FaOed0vCwBUGuLAljT/Kt
qKQRaqflKvLXGO4Kgd7wV55qG/Vq8nDiqn7UUnPI0MFWbvBGYZaQdUUq0ewhX/Bg2Soaqq06WqRY
mU6+KjAc3Idd1MUMbVxp4cdpxvB3MznbT1VquZSwOx2TyLZbk0vKYbfEgolBQTYVxEeZDMWUSK+i
FxuQApPrKk8F2EPSIjA85xyf/9jZ5rIbS/7ABiNNyq8eZr3UCBtSWhwiklcKtMqSyMzdOsiN90tL
R2WTF4dbFg1Sj1RB05DbAqD0adzAbT2jifD5eGHguFHvlQsWS84jOVN1rvWcFm+2J8Xmej7IrWnp
gT0JXGBr9eyG6am3YPPXdqqmyHHibmprdcJP9itiRwrIQClueS9CF9HpvmRX0sleNjdkw8eskIvO
cXg+t+MJ2lHnhSzzXGGmrWJCTeDnQ8d9m+noZGGwXpChIbIW8mx3YOAF61ymkTzA1iknzQFIJLH2
wt16evqvn//vuHWAfs/a6CaJs3JaXsWuwumNa6dAKizKoOV01Ynng2ikTkBcBa9nEHVUBeEJmIoq
5GdJUJ4B3MwuwsY21lz2TBROwOIYL80cFSrEfnJFFzeemeKM8u49NqjklPAAWDYzeuyXHu61oOZi
GxzlQWRhwwMFbJeRHrSjYoCP63eJOdM9xqmbBrHfZCqypy4nF8cMZD8qyWRMVGvcD1AjfDOUIABt
5RpOrwO7yDll4ezibyvxyCdkby8smqblx+R0qW/oJKblW7xH6M797Hskwf8I05OVe6i6RZKDyXLs
agha1HevVM8qHmTctrMXtrMNs8dIqwDpggHjGDHhpFUg1zTJEdfKpxAVZBPqM1Tw52PvvWLZVb5x
VI0RZ3rrvBI3eBMxFUA5sSlmTAmoCOAoygc5BHDe3XUrmpcYt/kiUFfj1EU/rs4Na9fsBTiYMnWw
pWHi1Ft2ybXh/oq3iS+jENXjyXfhTWv5C9Dkv+/r6tIrLJWLEIwd5e0ZTbDmw4fgUG8eZi9wT2vC
Jj4XneLPyW1ZrlXBrWjweehOShydO8TdJhBwzfs5p2vAkyfyMzXovhamlFwSUFdO2g2Jg5jhxekb
Uc0MSE8dQISE7/Xp3D5gS4grikY/l7GAhwH6zN4kLcAuIioVz6m6ljjEUP1kxiQnFSqOEROtljGr
fhIH4Y7xkpK60MXEJCBLgEFKImqga7pheqJKUVQ3oVaw6hEEShPbdIsk+SQ0eqccqMZNZfZQTWz+
mfpq+6b1nUROqVWf1NK62lsXdhNWhtGsREkbK/qqF0NRBBTEsE9EKpFEHN8PKDguYMOWm7Yxjf3K
yz/9vTnR9+DP8C3fjb/HBkf4aCKDMcjDSGyujstbnnmWwy2mgasRTtoWyUuLFJtQxd3wHL0ZrFVW
1Vkij25M1BWibbMdrqipefj1e8ZlwePhwKqO+SqUFgZqDACzAo2lDSC2CRihOgDlFgGiglCSnO4u
IFd1RnLAk8Ak3OxNiIIw5EzRNmVMIPNIGw0H4t01/tRQk7ueGzD+proyozn8BpeIbjjX4dSnwTYh
VMltgzsf5ocAsS9rnbGQxmnwTUOD0j6utloOhihUZ53FmLEYv91QY+qT90I+U2tVWi6mZ2axHXZH
4XVi3r9r7fCg3yfSaUuoiQlBo7qptQINxd79lSH1J55gJA0Zbp5Bfz3BnvPiOr1dKF9zvfPPnb0j
5mk6WWTcTN9E/BzHuzvb0BY2wgGx8nTlQA7bMkUo+BCQGSWgKgsdjRVAS6XczkpNTrZApXAhCTcw
huyCbBgZbgGRG2A0t4N5TqxeIYAm0mC6yY9Z2GH609g7kkTCN2KxnHi6Qq9CpzUBZpTPsTdLxzQW
KxJMSoYESe+IybnelUG71b72xhTNQ0Qprkdm/aCccHTMQChBNS1sLdp9LktrwWWxfkWpnV3f1VJh
ZJyztgNm/PkyPUR6jSf1aNn/0Nr4yiU8MtrHcGIpxexwWriXfMFI9fdZWAPt8c/XJW0JKeLFGfjN
DDlE8SkTiRi2Wj58+a39RS7wbNu9t08vHWgOixhy6FPaSO4fpgDUU9nZXGcM91PRCp2dN0p1WgFU
SO9fpVBxMKd0SFsvRZW0TlO0EG70MKgHaWowDlKGL9czp1158AjU1P1M8iB/XvE/DE9m38ZxL6mp
D71mfp9l2Bdb1mkuT3Onapu7ojNvNwqhflpNqx5X5stOaNmEkjNS4JEhpuVcgC3dRMeJlW5TKokO
bbLrJZftQEnVa+M3TT3okncbG6t2y+9UyffGJglM0Kfgy80wNu3Iwb7l9Cxl4Pd4eDYnXMdD7R6h
IzFa9D6RN8IzlpNBYFTriJljU8KwM8oySYHrZQzsY/Zccv72dj4433uE76WSVVVBjkrGAMPhxS1R
z5s4AXdzasqafAGUCESPpkFkcR9rNUW8u5YPjjr/BYgwfRkK7aJv502s5YkVcAgzV03LyW+w3Uq2
aRSdWBF1+LEeMWPL5FMZClqbWiO/QeTBm7k9+Om7Pv/wUoEUrQGDpeb+KCKSDOwBOyMxQclUTiQO
ENpnJHcGFMHV6+kRES9EnUZq+OwYqZANNEx8/bz7iIwjqH3/C5j8yqOTzSvU4Ot43GnYcb/qeHc/
Hiz7C7j5C/gQpEqgGRJUujMyEPK0/jqcJXu42//mLRJKOE1eHQST57WZ6+j09m3yFiXi65vVphTT
0A96p2eely8Sbf+vAGOv3jjCcZ4NVJbBHe59sfOumxeXMaUWse9PtrkVQ6oQ/k4sZGgv/cN3D0iv
1y7CYEdevg+H06uvCcZOxvvK6VRAFYjqLdzR2zPm48HR70XfOt/eXBbY4P73J9oWtqDSxRJVksgk
p85//XcL1WOUHOa0/qOai4MMlG444JY7ii7vqSozrnPvuIRk6RsCqPyOclaww8FbvNdyKCw362BH
e/bOMvD+4rNDjPWBm95C0KSutRUczYTF1edmO9DJkMVNGLHoBMLTvIg6J7hrWWGlKHIwpuykjaFy
/xBpI/CJ/B49yXa6Q22qBO2rV42BeMSOTl/RHkHX+0SszBUUYgpD+GCrulolOdNjcXlkLhIyOZ5N
AUMWBFNJ3O9SLNm1b0qZQqqS6Cs2ndZd39JUgtKKajB5Q9ukZiOdNhDqH0GVurkbcS160DunwjMl
Cun1RXAzAYEZzdKE6XXTifpvnnzeI52i3ly6eIMVuqNyYr5+weJyvwdGZv2Kq64pciVogezxA5nc
DBA83M2/RuLmSmeDq/86eaCeU+iSwi6lwZwC59tlslmb5z+MCy294dhhmCfRvsVWlOSd4Ju4PoXU
0ny0Y/j6rUspoc3Rkr9r9xxoip4Eb8PnsEhK29k6VljrwHhUZW+WS2XTzFnTNpHPuLopvZSOF00A
MYmKHStSM593IiHn2mvm4f39E2T7xa3kERrVuEwbvO3PA/CXUd0K4IBHRm4YH4eCJpf8zWc1d6Ha
aD93QrKlYj8zcbsbMiMnUZUePatT5aVEqUp/k1eU6panBazY2nP1LLvTWbpOT+BfruAoMCzNZRov
N6lunWo026VdJvM7nar2mku8fC9LcyC00+hNCnfOiVoPfyhDj2zCGUgwlg7KbbNgeHUewML0ezAP
DLviUAD96IPtlaKLJ6BLS/397Gvblnq0slE85jGnmcgefscgHBkRnTTDuLMgrU7BoNzneie8zbR8
V6Sh6o0CmudHDHG5JN71E1VuxPZyHM7i4D7uFz9BEllrfvZU28u/58ZoJJ5Wcc/3TIWP9wXvZxzg
TIxVc1obZ8cWi83ybi9xpW2tkppKd7ano4fGT5roZFx9ZNWk+bWjPTnHOKNSxlq0fFV/Wpo7or47
IqTXCwOH/wd2anwZr7dJoeqW89QViVDQVSgGvkououlKN+vIVoRIdNhcby2RssfNJ768P9aC7opj
k4vymqXxvv1idb9FIwlOfK6Lqb46UXgJN1pKIxMYR4RHanDHQ+tlCs21zHS6Gb63Eq/rUnRgcK1z
qUIkWw7jvIEcmKvshluMwJmOIKPhLWhovLCKazCtP/uYorNQ4UOQdqqmNp0M+evNcBey/FIKtGyq
My6Ftrix0KoNK0kKXVuTF1zIeyQCxCvB4RjnLGMNj2k8vuHhikNXu2L9naVZ0oi7XZ5StjidvAy/
0OuVrDeQzy+tOTecqiSKKIaqAjnKhHTW4eSiRaCIRpjOu95qUpiYPQXMY2eIEqBc8Rl3YsSYemRZ
TLGhIl0VC09OQ1yhYU86gidNjweDcF5JmPxTiejC+zCo110ZW2aszJ4D/57z4W7Yu8oTTawxId7D
WM5OaMjtUpOgaZxj2q+xZuMSwREc47c36zqwZyI5iVMKksq6rKfk6Djmi9yTrgIR8sakHI8Aw3F4
Ln+tMBHoGwiFFJd9mPqsaYyvoIFq3Znzyl3yU6izFcbbsZVAZuxkesc6ER042Mwj/Ul+Wjw6O49q
A140O1sUq03l24bonEPaGUWmbH1Kee4+ubT36WPmVuVuCgKULWv8ikYBNmHYBjkOx+geOdepU2aT
UmP0qdiJBcSmLZaanDFVcDMQ2DNm+fayZksBzwNifgnr8ZVbq3U9XVLRSHjCdYjcfNn+icosR5ed
SXlZYZqxPl2t1Eta+mQ3qaUU/IfzwGOzyfLsGdnunqZJSSlti8bVWaSYjriSsIDoHI2srdO1KIYt
KLU0c+sIJXA+KAwXthYruonf7y+w9o61IQWNuqj75TSs88m23BknEsOyM8IErbeEsU6fpMlcEzkJ
HUxq4RH1Q8Clpr0K5l4oEiwc7OH0WMxFxA+VhCDNOFbqL19h1RkZigKpROqoJMnZ1DxkLA2gjzwk
2isg6OOjA+13wh5MCI9Ku+Chgb9OixWeDQNm+X7ThC/6rJCbAplIZsMQ9W2PRcjUiJbqkTB6G4Ll
fOk0WYtCPqdouco4bVy4uzq9YBH0zvfMhtHBrCinTqMC/ZvJjAtC6jd80pAscl5AObVYCLCgbKZj
qQe8y5t7BkJvBc5yxcu7vd+ma9H1K97QmIIIfcyBqy8yyvLUPJvNfMb/QyjjAAHziO8p1323KyOB
Ho7eLPuwoAxKUQL2WiJaFwufC04R34KBS0sY/DzbvCKHzt/LnMbJfmxzRFi9w/Iduw24vKBU9z44
14LU11hSoS8OE9EhhV95QQxdz9+08LL+Rt4Y08LZTt6ykHV5karllnpOy6lJ38weNVHU3g47i4Gd
MsOa7rq16zNLxEzAHL2CBiU3NzP581Qu1tbDQMNPIBe4IydtI71sIZY6XRG/WU/DmPtYzUKoCTo2
0+dNCmiajkHcIm3thFGETHC1jp1DeSoz0LpvED8x963OvETJPf0mUIeO9fnsDfHrj81Te5Vduyeq
yrZQlDizh6AiXeW84AmFxJR27UzRInrFDR0JdOpDtw2xrrXJXQvqfIFQXVzGZ5kz3Wgj75xEy8YE
Vc0OQ6rrawP2Y5w5HWblc87wHhWCU0jjXEuFBOUZVkmcDSNyMWQ7dpg/BsqCsnapsRuOc8RSdLuZ
xZB7341n02YlWxk/Pc9k8ktfMBmfAByERq50N5lJuZT8wLcz9IQZ/1nrjNrRsgXIem0x1CgwTfaY
vPpYLjHxCtCNojG7QmYL9ia+f0ouc4Nifs6sx2V7DZOPvPtfAGPumKEkd1ZMhMlSXphU8qxl/yF4
Sedy5dzBPWyUSRUbtMRThA5+qVd5OPgdpN+MS27VxcKV7gBLC776Cu0fAlJxJd1vHGwWNeNEbX2S
BLOU8gjCLV11g56lGfV7zOtwUJZaiQYz2eTky1SS8VPmcXxPkrnRg3IJpbWeshdvW+5VPcmlkjWq
suvbV1X65IwlhQX2dePSKfPHuHITr9HbFcVY6WLIjh4rZFfsv6PapaI2Sk+nGa4ivewrbPvsfPAT
lNvkTnm7r54Y7IRsmz01j6d80Lwv4h4rGCYR4/LEFqTQYSzZgICzZptSTdzv7IuXdY6IqzNbFb7y
UQtKwSkVhFNQ6XRSpa5Y4iv03abptqiu9Xm97ZMzxGp4JmJmG8QGflSQ7S+xS9GtLx4/SBH1+eYA
D7fzmwK922TFdhwxRdtgGUTeTg/YjJxIxyvdoQY3By3dM+aPF8bU023e2w4fHhXkluh3YqlyZbWv
Vb/RG6jMDbnEaBqOt9JN1eA4528UkzDNL+B9dx9xrwpGYfC8kmYZbdoFE/CgBzk4UIRIyPDcxfqq
Y+5TGizQMyg60dFTyJlHqKX6dXvDYc1zcC9GgZzBNbDxEqWVVQjhHoLhHg6c96ctzcmVcMpJCaEB
Z/Ijf6Zp55D4Y5qYi7Ypr2+P4Ezca6qp2wL5piCKSmxkePVcPc7h127bKhi0fjayP8/MXjkkdd3r
2YujPSzURWIvtrhiJOazWKEnF61iNeVdohbjU/OJWiLqr6IrQTLN3aPc/yqHLO/rHgL2nLN0Cgxu
28v/UHCoH4hoFzIvl9TTNaLf2iHcssfD7xWgwb+HzsBlqDbC8zhatx7e1QOeocVo9f1cgaSwk1eP
lESPU1Qr1KMsNHJCvsA6kolvB645vrmWs1EP9yjKVfbsPtlfWjTNT5ISTUj1XbyQkehh0CMqkarV
QKzEaE/+cZnZ6O1QGfuVjRyLuIKuTVmvTaAYsmOiQNAIrc8FSts3GmQyjsjODsC26W1zC+HX68dP
7eJ97ClQDTWfK3Jk4NeecyS7VlbrPe6J16MQbluRM69g7Fiq32qZq7YCxtrWYMr7/1jmioSsrTKn
pvoOuaW2wM6GxSoo0eZ549dPzgw5Etb0yO5FKpejbmnpupLtaWbY0JxbpS7OWnUa4ffxlcHC5s9C
Y+z+2YBoKC8NepSM7ZSaVz0pJpiQ1LbvxM8QE4f7mONLlWdG15vlQ2L9IyYGSrlfqtNvuB4jh60q
VgZSmUwo2+UEzizD8fjFuTRkmzTfGvrRWStx1xtIhys3yezbuW0OBywIr5n17paTnWzKcd4Qy+UI
nkt0YIaJ59j0cK4K9ZipPU+tFW1iKKiul1jgPLg9WES6/4lnLwf5Nsv7EY5IXddGJqaq3mfNk0Eg
0iXN4P3ALCELJbR+ZDzRc0D/ONqIt0bT9b2hA07EPQgl7BjmTWPDdt0+dBelhFfubIpY/lG2pM3R
EketFSS+zsoONJFyH2SSMvruZaCb6W2DqMvuksuG12rB3vKDyp67VtmZ1NOjXDDRf0PjLgupj7LA
NqVRZmDM1Vc5sYTO3p99ybsKuz3OB09VGbF5NFJHr9wktY/fzNoaikyH75+DXLIg50ppkHIUOjcQ
RSzzhus1q/r4RHOjdDdP25ux1dmXTxL7BrX4EIXJN7ExVn4nADMPxHWO7u5pne0zogMRCkifg8fX
CxH3RLmQKTXqmrPtEf9ONm+os+HdfhMyUaDYLlxcF/BxCWe0N2g3Oc9wliiG1seq7i5klCBfxeID
qiAzYcaFK+npPD77McpKzsyIysrKjc9568tl0AuJXWE37kabBXvaSU+VXcK2Eh32xBEnm8Na1r6Y
Dhg5oZkev1hQPktA9gLMLTncxoOYhxOi2JLmfcJsNJEwCl1+HdrlzsHJGQiR+KLmTX/H7TVTmEI6
vAbubx+u5sSPqt8qhXuDk6YuO6HWp6BTM6X7pFSlWwIusilNYTolUWpXwxkg3DKECMniml+I2m0T
qvRedGp0muf8Z/RRFHgKA2r1qAJicVDczVTSq/uT788y040FI1IpyV0r8jU9h0zIDPHNz8bbYOpW
YVqfmUTWuHis6lv9zO6XzRSWGODZNOWsNDnEphbaqNZ5X2CrqtkCyXWeEbctx+CiQgW4bBKpf1jy
rnuu5nGO+7EfX1rK1erbzdvD1L56vJCMH5OVV9ahsYaU7ZqTesKzWqLfLilXp9D53i820oohuYfI
zqK30mmc3BI65i0bQAhwOXDnagbGQs+uZLRX210eyBIxqFRl/ZGu3GdzLL9z+LmI2dm+ficXw1y9
mTShzjgN/QkDz8KFh4fbd31EybmoIGidn99mu6BKN5yvuv9T4RjRUDwHt3ai/AoFwz/tod4ljo8c
CTtOlAUjcW+Bzdkrm31Fw+cPt9oDXZi9719AEVmGH8TbHYR+Hx7Nm/C0DzH4s0SXdnPcvDT8xC0W
goQlOnrmxHfiCRo1LxEk2P39Xi3VFuYzNUPxavK12LWj2C0ug4sO1waMad4C/mgOm2i6yy3oahyH
an3TfWLXesawNj5zaSqem3f3/IUxAT60FpmSU5nk2LzqQTmMLIQRQzJv1qYwwxVy4MxsVZIcTTz9
UFMSNgiS1A5L3coEOi17WTG1be/aymi5LvuiculR08e6TGn/wvs7laj+EcPLq/5Meiv6uKwRFs5+
o7BvM2aqGJZWPEUR8LuanBQBeBlZGP2fwlTHVV0sKpuO6T91tRO3xZoZVcBpUbkwv5sPRex9HMph
9d+Fe6Qowns8hxdew24aBjSxbnrcP/WxRFiBByByClzpOcnpMfnjlHUUEAKnxvrSZau3Qp3L0dy8
a7LrZJV52FB2GIWgmUzKDB54c6KO7sUahYGFoCBT5lb5jwuV8qu35w7nUNrDWOe/gEAUDMHCDz+H
CaEjphvt1TE6eYhpOtWRWyoOFbtBeRihdAKhgkAMmNmbl+V1iAuamV+t3b79ukWzKqrj7YQ+QKVc
yXEvqZs2woC2VYpS3Zw20DJ5p74p55crXGn0uvMvZkNqD3Q8yTrwYlFpJpZ5WRKm4d8M0mQ1lDko
xIqbbq0p0OziVEUBKabcMcla1XzVVmbLeLXeuul7Pjxkrw4nhGBUUmO8jxzsTZ3ZlSe5Fi+lBg5k
Wn5qvqU5plcX8zolpfnAWel5bdGHFHNT+vmZa2RPx5mcI6Z1cOR7tuVUlqzhYdbUtNyMgDANA0E7
HpZyy5M9kuQ6ew038zUv0rfpzzC8NikrBJJNRQ4C58NW7769xqDxsBQ9lXvailD2k2TdvivT4d7R
LROAsLyJwsrNkcNTZSzHQjBCIdtNRztUTHWOt4dk/1o1J8K4MFb5cnpa2aYExM6AUmZy807eQo75
dJc4/2t7iY7u9QlBMpf80wtvQ3XeBa0dhDyD5ZY/eQRPSGiPuHk1UPbL8g7/C3kJpyVJ92sn0LHb
wXE38R1D9kLAntL5U6b8qPb+Nt11bN1s7DWRRqseV+7WorWlVtMee7v3a25GgENyzTDZYKpTdRre
BxuSL3cmD95qbnbgVhXi5w1+4Fx6LBOo6i8Af3dXfs+S6ur1tAYVRvVM1A+B3XuDQsZeI9wjzXqN
o+ZHGUUoaYoVf5E45ggSM9epM3fEZZC8uL51n1pqN0pUb6qazjaaJ2yZB9Gm6Kv+xZl7cnWdHTPv
rLeE5LyLTfYJ8BBDYda+ld3DutMtGyGdwZx0ydDwYJzz3gZm3gRvM6U+XcpCwySubXHKjwOp32rZ
l4sGQrlncIKPhjMWyCQeo7aoq4+tXCccbfmGFn89nO5h85PLcn/upWCIwzIkIVgpv5BHFGc+sl0q
humZVpJ2SynUf0qhO6ykOdLxLTzmVw+MbV6rtQwXjRz9p/cpcSvFk1lZHu3idwKsYXWsZYi55z0B
Wx5qK0SqcK5/8dr9sq6vjU6PYchm71zQ94E699TMJJMF0OsI04xLpSG4iG7fnzBrixQYaOAMKmIf
rmS96ho0ry4kLpA1qJg6Hf3BWQfwZ3vWvAOApSR8fTrY++2c8qc2m2mcYnUtYYVtWq1Igptk/2q1
9uNEgRZ5vU86KYtOr9RUL+e3MQ0/cx5NPPpTm7ihCqFifDjfX2aaHjTBJS3GpVPrH3uS2bkj6XW1
JDWIE6m5Y3lCt/hLTMaBELJ+tklB8ocZ2KYEOMxTZpYgffGkB0jl/tuGUdnMOsMkl+tvlNdPlHOG
8nscDmFV33kpykodihU9t5EXH7haliV1R5gErtgpa8VUovF2QFnjWEtnduo1L7uR1qFly0WWTNoI
GrGyP/FPbIBfRoazYb0ea/R1qYacfpQB2WJkMMksZcJjL13gTgzycSSWYpaf4u0hCBqUCvsc1YzK
5qyf+SK7RhqjvYVIivUbivinjZOXGdlcNbVCgeTL95pOtNoXW6ztGvXr1rNEJ++je6c3L5ZondXk
0qiTtyxakiuaYlgIRrY/EF/XFbGznvGAo/ylw28cqt0fORkN6sWNydUZfPFXpKOgzuV7YRL4B35j
5s7GaibSI+XH01nDCMc2VZg2n+PhjaBhJmzbYv0CoUk6EAHErKOc0kKBYGx4VvUMazNxUai2+lhc
ug1Ir5HYm7pRjzeLYWMCd+J2u+4JlfwC9z6fBOH0umAo5fUr0qyLS+tcY6KaeEC6kajafQpoJDes
lWpGxqyJXHZi7x4WOw6fnREPGj5uxYzfbiiGu+lM0Uy4bE9JKzuSRYdWBzvTsKpFy88aCuyrayFh
qdyQAHGobHHQXrIxcsjo06i61ddgKTz67jkhH19U8dJipxaA7R/nftep1YiOFd32ixbwdjc1ENPy
N6axvkfBRV5xK5clsEzyQIt4vC11weqgQFdnCjeyucrypouEZpV49UOjpH80+A5cV3g8ZIM1oyRR
6PbFJbchorxkzracYG20i9uSs+iu/okvmSd0Fk8Bw8FkxKlLheZvFd1JFOtFLbhLb0vBfhpTxtmn
C1TBgw5q8fPMbj3B3zxxVFU81p52XUZNd8LpGKKVvaJUAAllJDTn9/VGffjR4M5r5E+xtXnhALer
ciPpKJNnTNNCWpxcmJcwolBNg5zbwm1hSb6dMEdKssYXc16hgs0WEiFVHDz19a06drmRs6TbvEl7
oZl3GwSjaNYcW6XT10GE60/2RKfkZ/iDiaY065BwNpSdbm2KE2XvRDFygDLbJ75+VxOyxLEFOE9s
6+ZNozdvV7Zq1+mKAWPhF6DW2YPLiF0d4ZMlmyeB+Frfv5r06pQc1GXkEQaIeA8TVUrZuHaP521+
gk7L7Hs1xmhaJE66BTgNfXihGJz0p+T72gbttGD+RVYUaUausFQVdQzNjRT0q5EpCRBe6HWiR/hz
/EYz3myhurW+Hja8y3pll4nGS8xPszY/HFXLobAjCpwwqH+R7woDRX+2+G/y6pRAK1IA7pdefi8l
YNLaABNIgUNm6qVdnvVWptfJ94XIHqfxdZlCVxJKW/qqOaqrdep1bRw6su7nWHaljSrBNsiXvdF1
0p36RBwFVBeT0TObuLj6YlLUMUnzq2hwMhVoRBN1z7lsHVJdVgrxXvTn4JMWgotHfwEQ8elBNgTx
JUWWVL08K5lZD4YGLEy+sSLNxriwRVIS70gVccISu8w5rtf5pUqakclxRXm24TcODYxZeToq4aoM
4X8Bqzq9SHlmI5Za7DDrKGVyfXGY5dOygZUUGBQ3UAm6/YRtNlVze3IT6nziJHQ2I/VObbotxAbi
5P1hrqOCjs4R0weprkP4rgF1eeZnlxvKwnIhFZUKUxO5lYhDBuaxQ5HghCxWcLAjWuJBpPC9OGSf
x3uUL8Z8vwhPZ3OVsu+WgyvzUmVW0z3b4TLAXuRXLDlH0iLZPXLGfMjqNKoRKKrlsHJa+lkuTw3d
K8h3JxqmWmO7FFPTkyPZYF/XZTuMl+mCDTQaUQNqzTUJN/vxg0tekHFqNXCAb2Z+OQHNstyEYaRA
S5jOIUyiGuK+RxZyY63OHLMrUTT7xfVSuuVssb41EFG6GZYZFfvqmYzS2NzriFpdqweJBHq1E5YA
AVIpKb+c3qkwOF9o5oKFuhr78l7pCB5ga5PzLyAxy1ovvWoTgfE0lk7RVt4N83tZMBXZFZf8tQUx
8ll9ADffsWtXRjP5JdBcs4saJlr2RZNuUodhSZlIp2rQBgwuJq2YsgwRaiwJnYEcXA0XbLtAy2QU
r175a0/sT+oRF3cC6rJ/+6qea2mSs7m4nQzptS7f7NqDiOPqBZFXfJpjXbKWkm4LHX1rRCUprxTl
qqo4Zhlrhs2c7jvgLGNT7jn71qZKwdSQQ9okuW7pkM6RYQNuO61APivI946iNlmldYOe3S3TeiKl
bnPRqgxktkm4KP4Rxhq6nRvCWWi1oiQ3w54usKcnnJyQr2XWsvbnAg6PIoVL8jT2ijCAs+iwZ+ft
jL19wnpWakpRfkYJE1/TvPSUCN5lYaehyCWm7Tm1Vf63HPwy4lK12UzY/G8ycwWOjWvbpy5cbmRN
Z3TH0qUc99sViwzzF+FG45CIZpGsb0srsuu3hDya7Gw4DtCkqKSjQymw+kniTUFKwcsVzG5+7rym
yjHkqWk5bkq9O4Zv3a2Ve9am36REJzTPVfGoe15wCC3giaUjJtm40mzxWLulKA/LHm5SP93rGEwG
1hkS1sX7ZJ4zf85RxpPqzddoLYwtIse6ZRCsPDdyT5+0uRrUWYoOZ7Mgr0WSjK6RzPMyy4WkV6aM
2rvYDmzoT/bbAE5rVyZHvP+EJTlHspt4qENg5xgvjjveJNyzdxgICWVQP85O+oBP+lefwLhvIuKE
FmytT1xb7En0pEcxdVJxd3alt8IRjCtyMrG1Cdmr33Oh0iZuDEobBTbuN3J+uN62ZqHIzQcmZy9W
9aU5uYRy1jgrTB44/kqVTc7TZDvidl/PaZaeU5QUK4d8k1FGo6ABzzNO9tcg51YZWWVN47t+dtEC
yeMhL07X28NhQN5WnG1krKtMRD8S8wzlBFdbxOWEr49rlCI+3F83XxtgzELmXcajRUYovusrhvTD
QW5h7pIdhcz7PHRCLd2M9VfzVSBRXgYimhAQVy+1j5tX60m7j/IxIA2zGCl1+Nm76f+YC7ZgVKxg
lJXodp7TBGIJ4ADo4KMfbxZUuK8gQX1yYIHthwJKfCWXbtSSO+Jaj9lkD9QyykqvfsptU5EsLUR9
j/WlNdw05Q0DaqZtZW1hnK08yPiS5QrOnxIlqmS/1hOeLnLOuNCq6jAQrAcOewz3G2Pb/gIi2AlO
q4rNZnyERunr1RzX3LX0lEwTMGqmZJv9EPRcKBUEs4k6ta74p2qSFFGXcEVDkWRqIQEIydFbpOjm
1HrFZ+YTQyOuqp+5K9m9jlbLpjFEp+fqN82UHx5YRERSNvjp/OLri3Nrti1sL+bxSXbYnAtn9N2O
aVqbKTKJ1szkpciH4ERviM2A+/6dZW3jzksZNCsbes1o6TYHnimblj1iG0sz/j9tz/pmHHOrB1Gx
XtzF1VvYpDM64304sShmP/w7xo8QnkJNZ6Q5mg53PAWqqBLJH7lZ/R0KJ+stVwsSancucWI9wIf2
2Q0e3eR6o5p7QzlWqtzmyolzWi5xZdFVQVx9p2aJyQNGgYHfD16e3l+l7337DUvCGKli40RTbAmV
3Ohy31c4UMzI0XRc2+FVkALRj0u7c0bZbDIJLAxgrMazjim7a8wQ6yHSHgTXHlyhtakMRrAtoeXo
gRphElEzV3pezuWczrD41EYy43UoqQcdGkMgCT2jFF/iJjsfITtpePSTXGTFqKZD+1gmF3nH4TC2
a3cNCDpGDwPvPnr0yMTOGekFkWRQa5dvKiBd1aJUFNvdjkmCvjlMcoggSXAKbFVYIGIncvbX1US7
5gYJGdD/L0BH+Htil/D863fDF/JFdDUIaHjILsiy5KE0yo4SRyq72N5AVV1zdqfviTjkJ+0MGRXW
v3QmAsm2yq01t8rr0NboaG4payV4bwY91KS27ar2tJeloj/GZnnxqpxZ4UGE+1M550+J7Fl20lPa
25R7K6qvuUQKZh/KaRu9QhY6RSUhbopsn83jbGli4Eug8WVsnzd6sZ2BBOcYRfKNb+TqZabVXo6a
/15Wymn8UbcAsJfEJP+vQKJIR4yXGTeH70/6Dw93d68+n06Zn12UzKl9I0ixmFHZpEG6Q/axMGuh
y6PxkNJg04irZtLr604Jn6SPOvvI4Uoxkx5yvj0ojOi+4VrzWCg2zbYlWr7jJvmuCXpNOrnML/KZ
gL4yiZx8KsvbLcL7s+wkTz9ySxMMIYrlHgM3MOlGNVYgliUD4pmfpcFwHYEeYo/Okt9lqzLTvW1a
0hGO1kMc4+P9jQLTFqTvPPkSLea5bCmQqOlmfhuGZdJ55/7hmMTe5Q9A+PjrMdDq5uxh5+7x6OLC
bkQ1KKzGvKfCII6GQqMH+FO2PO3F2iGf4OLi3GzioO6UmCn35L6BtcYMwdKlf27X0pUDTi4XWbNe
UpHDvD6URL1FfZnKrGatHn3hmkHfQHNXenqX3Che2PrhaSWOtv1puIrvGs3VhzdOUHO5mgOBSW/Q
zE9+lr/a+PIRkU+rYSf7Ub7DAxwhIJUdriMrHc5kUxL7YqgYfs2q9sUcnHDgkKaN+Cuf5+pj8m5b
xXIKnxRSMow/+qvt5JSV4W4XEiC6A/gSQWaCfvPddiCrGmGmzP4QOMi3L5Mko2X9FUIIfF3pmVhN
6AYuKxBolbBBsQ3kNcsvPzrrmaampzSbKWguO5Tnezh2E9FppiKmffFb+nVaru/uTY/wk/MXqf1p
YehtaXf6s91xOmfBkfAwr1aZdEo8Iy5cfeKjY6nI+BoDTW43nr/cTKdPL2nblFD0F7AGLhbFV10N
dZ3Bacn/C2++yD3JvmRCdqSoCi6EGgI+QlLjRjSvRHAkE9RorQKG7mnrBnDFFaupyc+OEQcfcXNq
BiBTExvXN4tCjnb2iXKjBPZ5e2jPLqHd05bt422+WFuARoFQfwGKFEGHfLPa9Q5mb36GS90sillX
CkuvJCRqNq8dYicdwi2ieo4pL7R0029PFQ5uCx8gMep1ji0NC1oGzkLG4KzXUmdeAGPGn46vpNgw
dylbF3okMgfRZfqECw8ipbwViNSiH3sEo0dKzX1WLa1y61eFl0zU4v5xwfcnIhfeEuLFT3na8hP8
fsEyAbOXDhu5169Pvz3e/7gEy8CRXLrmvpdAdH70vg9eEjz/oCljIcdewH/RvKqwNMegg0s6Vxfw
HMEZErF8OlPs79Cjru/As6MKsVQLGKd9O97SvUJsvci+YFN3/HOjOw1Hs2wr5PMOdiB5iZLxfjMK
9C9wev0LMBy8/iaAkvh1cHg7V534Z7DkBiLQGnLw+xGBzxcRRBx8VsWfCrpOwI4p2EFjr+nVhN59
EV9UOUbje8CgZ7t9ojNvDTys0y2kTJbMNfgzSeDh7W/fM+3fcB8is3EQ1wBa1d2JP0EEUbmN10GO
1AcnEJ1KmLcEN11Ovw4aD4cyhpso6VOOtp1uD/hGib51+ZIQrYs9lX2alDnmfpoQh3Yae998CJtN
hsJSE2HSfOm/hL4EdCZ9Tfkk9la8u2yPEPlGXooKfr77+A8ys1WZEVx6Sn9dBH2bdAh1+PPx8bXA
FGbN56RksJN1dTq6+HrbaVhpDXB7YusLJkN7OJjN3CVhafM+J8Jz4VM/JzchhRg0oeLeDzi6W7kh
HvjmFrQZQkaKjQH4FBGMTj1BlXlRAxyYXhIHIg2ITL65gLpjsB3VxfmBHePVjPW2WPuGjTtqEv1c
8QxPD4wzi8qF7QxNcc5K1y2qtLS1DgkXkttJI9UzYg1BqhSfDkECDi8/iYSOV78NBFpBOiijm+tb
Ft5l+6SP8GYd420VmVBdQue3cBQ6/z8AM4DMf/rk/T8GfR0fGwDiuyafj6qa0go8mq8VNVRMFBAx
ygPrroAm79IJTCStTULy7Ojmjsd282zYsH9K7xMReAQwYMqYrpnQZ2Fx2RRM3IUyQm/dAxRN5/AN
x+W+3+XCFYxT/qzAUfeO4Bv+I/w93u42boxElBDlFUweahQ5idfiYNwD3+Y/D5ca4Vjhy7pEDn+r
v05v7u4+192/GDbWUELAdREm8QkZ8+T2G6RRvd1wLq2xHX4czuDtOOK9NSJ0o+BYISVmq+Q6ZOxZ
ZWZenBzLHAGrlSAiHqzxWOI2XPJo8qSglLWNm8bFwONjlIKSkK0ywJOVaznQtLEKRQrVCMJqFiYV
hjgs4LV/cbrlx3UrUa1+Giwb2tvN3MhvG2ziYJWRppwbcNR2RGWLKbOV+CkHkNNzS7mzyEo1h34V
Suup8IZKNaLPnUq9kCMXqzZmkVVddNm6UTTMVusJJSomkHJN+rON7Z6yVCDTypkey42xYxfKWWRk
pG51ht+npR65aQoxtRYlU/1UZTQya0iYfoSVf1e3kQ9pcL5eolyMODcRET7F7HiUkglAA/Uk/WYM
zsAHo1vP3rZLjbIXmIkSmAPly89ZnO0MErN3x/G47ynAXRrArZEc2SPr4Vi2JtrfDsopSUqsy4l2
NcM0loNvKvLA8bJqupBFNaJK5OQxkQfGslkqErWalme16eG8vSsrQFC0zp43xNYLJKxxWlnts9WI
vK9v7S4x8lFOo55YrnZLhCrtyWEq0bDquaQchK4RRyFUFspszSr7O0y0qMYqagrF6qWCSduV1mrR
WGkvD36rhxCGcST8I6T2fALJrMeJl+k9sOvBo4p0LSee6dFWHDOVavZ05rKa+J4Vjd63KUlF+6aw
43NzYGC7metK7uBbtAF+vAto1SVRXAYRQpTgKQC6Ij9JXYn2GBASM8bqcCtQWq2lNTasaHd+r+sv
3ZsPl0nP032KuBscXGWC16bIKKwG/wALy8vhDIuRKXdb0ouwjrjK1yvoWtvjyzubW4h1xr68pJov
yK2dV24VZu03E2B26xSbzGmcsbYmzvJQLF7je1aRsBSmZGFRtzuTjpO9xsNkeq21GTq2MkHVphXN
6Cz3CxqwCbVvXpGBaxhvGSPgSHtBrVhdN1isuRbbj5se8owdJrU5bJl07xsozt8hXa5yAIQGM1bo
RWcdTT1QleblZ3BwawQhyTs4DRsYqwuzHuku4XqJydbnilprNMxdM1evWGNd0SYlssuVbu5CPh2S
OMWkgZoYka2MWx3KRC17MoowSVcUt7QQW4cXfOlY5/S6PSHaeFQ+GYYCQq26x13O6RGwRIYbDSIX
90hw9WpPWb2liByFS8f6WbtdqzfWz7OOZMpVOtTtfmJ8jywV3DeMZOMna+6h4hR0ZR60lLXAta7P
u5Nq0bS7c6dfiVD14xXgyBnC60fK+n7MeUc2T+n2w6jbLMYsk8XS2JEY9tb5BqCsMxuydjbEIwmy
hB1VJVKTCfjWPrDLpKIRfOsQxAiSM0Og6zHYMByWQJJLIkLEuLarMQVSkHmJa7VHmNGuV69NX3IU
xbUnsQrbq+9ZAdnHVGbBrKvGqRAFZwkB9c30SKPcRSWQGdos0jONsSz+YkHLKlt3eKko6KuK1NVr
g5AQmzviXZCvtnDxaN9UQqyUg3WA7kFEjgUF5V0yu7iDEhQVzBxntN1cmIoTwNKmxMN3EtqvwHy5
948B3NXUbNUZ3pg0V12OuNVncjUeo5JhbnAV+XaPn9XSmsjzNrpzF6v3peDil0YxVNq9QYullE+0
IU5Q5y717kKcVVRKCaYG2ABOIFAeb6vKJtt999g2+t7uDff6W4kmkJXU9DXmTeSjDJ5cd3Kiu4NO
PjGBzte+pyTGzNpqcdTjY7L86IvKwrZMzXdwBhS9rgH1Tr7rB7G6fduTrsJ+UPa5Pebl9+3l5jtx
53pgRgtMSLDTDLBkpJIMgAJjmmlm7qjBRRIL14Cdjb0U26p1y85KrN8tsNTq9kLCOS6C4sNpcvGU
C3n30QoSA8QXQLLTCDVSxRMadoZdApVl3bUiInUXRAzwwvesbVNplzE9hlq7BT+RWKMXAakYJSVW
VqKbZ+0JJwx5FEo3JHHV+RQdxF1WqbB165w84zCaiJiOeoVpSFtHGEYnUjqIxlhKasUnTIi/yNlb
rWaBZxMs7jgiKZY7O3BtBTKyUa955GFYtycix+Zy4bohuqqmU2/QwGnec+yuGscWEsdEoy9uQC6Z
dk2FXi4SMpkGtK2m4XlxAKTUbGRjNevzRUzRcfONUjylZKY5RkWPbNw4vSaoXR0Qohh8m4NMiuu+
w8MExtltFzzIG6vNAO46M75yxnZNAWnzD8Rk+j2HJmKr1co6brlQi5oZFOkKci8RIPJNzDQwrtHo
NISZdNVZTsjyMnGnNud41FRr6xs1Y3yVhXRsyol8qlgu2NsC1SgZHq8PALR8tGWKuMu8QJZtcsVG
V2xNYdmHha3YTsyDZzu3UAig8vEQ4w0o1uw4XzHnW33ydRx3j65w+OKXLU6sBIsp6emomy2FrcJF
pJzCa8LT3jZFnGNvCxc21de2EQSZnVj3JLJvy6OmEXoyZ6sLrb7U2f3PJ0pj+j1iOgEpOtrLQzZ0
9SG2zL6XQmXhrEzYvndfKyS3gWrN0vJACTZY5DRovScXCNnBQypMAZmZrq5P/U72IiAhDstRfUDd
9G8uDuPU5mOkW/LuFbzQb3TJcYvHGCo22rM6s6iYSu3eoQMND2VzJMT1KJY2MrZNJUG8q1ipoCdm
cAUL2ZuV7WnPNHJ6QiMzxXMh1mRpJ8yR2RJG1N69OMmEOxPIov7Go4hHdL8YeSCLxhJoF8Lr3fpZ
eUQTCcUOuQpo4zTo5hcJ6XMDZ0npu4SdszpDoXKFQJEQJKBFQjlEHDaCKfx/1hfWtw3EF0ZtRCbj
lUvpEzCT2uMuo/SfT8E4/wAALtX+RHuUcvY5xhks8NOMKs0ohWuRqr4w6aVVSHcrWdA9YtX+pbIj
puYZFt+kCAcQ5uHBG6UxpIMKmHCwbq4QQODMQ+W6dkezof8AUXPUDNufWTz/AIZ1P4vpHpKLNqCe
3xm0xDI5NzHYBsSsDPyJHlOvr+eXjoGMihgDTSSgonMsk2Rr4mUSOoomUxBeGsuo0n6jsLYj1S52
vlvtLVhjC+43zRQ4SVa1GSmWr5O7S8K7gI88MSFUUbNHakVGzoECIAsad20h9iC4STPFmc9Hdex1
lTFGn+v2C4nypcn+PoC1hdIqANUSqXSHqqzaw06TrtgWmXEE3RsSyowdhRbTxU+ZTxwC9eHlJaIK
hLa0axpAoNzyF4greZbHt/tV6ja0Z8zWq6i6dkmIheu2BZnYISfQhmM5WK9J93l4KwOG9enSWB4o
mgKyk3wByIYe/KuvaLbJOHFGAbJw/u9YTnaIcKDEntYgmMg8yn7fTdZtaS8zY4xrJaqW94sqMZDZ
R06XTGNVk2UPMzJpK6SVwqc5WXjiLLX1H7Zmz9XElE1OUCAUOYo7BvwiwnnGpVrEFlx4+tY1i0f6
QGK8s12alY+wuqwWKp8dL12WijmrLe0PRnpNy5bSaTQKd3JZBwi4LajJrEOaV8W6DqBmPXBOaYKl
br+0qVNUvprVJ2NnUVL2y/JyupH2GFinyDssU/VeWxJUYydSiTy68WmoslVjIkMYsd4s01YxvOWt
QlUQLkqUgsR0iaslYpUfLViuZDscmzvFbr1ghnk4C81UW7Kuq2qbbyMiLoE7Cs2iEYk5zqogN7km
+ovShCRDWZEhSmM2SCQJzCSATXCZtIExwP7ivAbufHdaf8R6p8GQmrDV7lqdnnsDjLOFBzdU4NBS
rz8hPunGULFCScTIzkfDJz4EYMXMJPpjGrSATRFXRybAbcOE9D1mY9jcMYExRKzZoCTwPlKRkpe2
OKq6vTK1Y6mbQrNS8dRjnRCwVa0tZytQLNmuZtCSXhzuUEk5yFV2amLdEmIrhrcrum+5ZBuVfpNg
i05mEWjIZi6uBZeZpSFpaUrxpM5oZhKRD9BsjLW2GjHcTZV4VunEKqHnUwV1WHNFbSzflXtlmg8j
5IrGPcuSeEoulYkkq7GZPNYGMPablKW+QfWFVOqpUyuU2jyjhnFqrlfSD18BiiYThu3dbx0lAjbN
MOEGYuXAdToDGQJJJTnk88L2CIB/qqnJmB+Hn/bYzLp6SXDGRMrYUyisymqUbDeUrfZ5qKcUuHul
huFGslxmshxEVWJlRYnqm+7yuSJlYZeXg45OPX2f2mwpHchZmpmjXdphypj++VKCrz6tROQMSWlo
pUZqls5xWO1BzOSmV3XvLSxELLreroV51YoU1qJNd6BZ6Lca3znEoseD9GjDw0RbshXImQsk0BLI
KtfqsJihxCxV8qGPnsG2tX5Q8oKWNRKuShouOlKWzd1mouHVdaj4oVZ6QU1AAXJfQHl2XvGeKfj+
Ug7w4wbK2c88iovKtJyfgaygi5czLZqmgMWi5ctnLdwVgWc5joOEVQKKapDGrFh9MQoYRETCQAWc
KJ7KiWLmYBKjOkmtXYXN3KlvI1/xn+1W3hthgzVg+xpDZlJkG/z+Tkb9gCdwHRaG8lrdM+qK8nLV
N/ESC0hZDMYyEY1eMraTFBjWXtsI2OAJiUohtwTmRdbWBL/gGo46ni3Oxua9o2pODWtdkK2k5iqx
mmrO6+KWRYRWVlkIWOMWpNZat+usG9c3oDTZK/4R6vTc08a5tNvo9MF51x1jZOKvlinci3fGVztF
psMbb6/FwGMbjAtQe1ygSeNV3HrlZGEizHvaswxdCVVqHeCnMj7fC3H/AKNzC2TqKgnT7TYZa6J6
cp3LFlyJF3asL1+sZTpZYI8viE2KJdilcO6pkHncvVXJVEC+0sBQ68KGHeZkwYSWIUolRDMUibhm
OEjucTYkoiQ5TOQp/j6nwsEeessUG11yPomOb9J1bD9CqtSc0HE8DjpxEGsOSWkAyhrtesqOzScR
FubbcE3dhB3kSLd2O1WDvogvEMubho5HzlRVdLVA060obZZpZpb0sn5FuGQnSzmNgbMhFTMMwo2K
K4tLysdEVRCClnD1/ZE2UPKWiQUrvrI1aKPGfaznqV0dY9wXpK09ZVev7jI5HzjWYq+sZJpMVpam
MU5EO2Xog19N0aSj0F64PdlbdHFsM9LTf5rYmrFzsQQ+PhGPm8Smy1ja6JXQaqhDNssUSRYPoW30
dy+aizGzx8a0l5tq+xYLyOiWnjozASouX7FD1e7Vy3IoletpH9oJhoGwLApOLEQQFPoQZHN66A0D
YN/NXrRIlL6ghu7MyeV2ypTHek/CuEmkgvLXahZQy5d3r5CMdxdWawOQI2oERYxbt6UsnIA2PANi
mKjBn5THTKOwmABDhJc5RAgmEhu9JEFw3cAiq3Ovv2BEdjAPMt/ZFAQMp+wBuDNd4uxLP6SHeZan
A2uOyHTcqVLHV6dy9vNJVi1sbBULVKFsDOsxxIxjHOll66iRNiVcp1FAApSmN04D2KIzcSLMki8c
NWQukm7iUbJOF3sbGqf+IOUGxZYzl45Q82HLKGMb+z3DjOv6LwLygRWhuUtgm/ZYMZiYbj320oay
sOQ3J9LFdqY1AN8207T7BhPO5Nxi/FLbHz6H/J9XseQ8CrGyS6i7OEewlknH9qUcEauTuLG4bQYT
BGzgwLKgioJdVooztXNNeqTEmcLxDzNmq1ClXLyViI4UFn7wzyI8PUeNFnMqdms+jJP8+aAnucpP
pC7FAB4l3UXhfA1cwTQs342pmScYRmU7jc2+I2d5uJr66yXQKAvHNpq22dI6aZ6I6hnR643YN2wT
ZZNd/IIkE6kdHFuYAQMOlYZ2MgiSMLEKyzxkwLLTpxSjWJHX65+tMxx5tZFsQPrrqQxUyj5mD3xe
kx4XSuK8DG6R1HYZaF3zcTJnLLoBgswUrwBp+Se4cbGxjjM1SqmRdPtzkMtZdu0NjLMC18sEJJ10
ydfr8IlJQ55Ftj6EmcmywyFrs5IxI9yeyzmAjQIWiGIE+CDgT2HY49JRiOoZFwXfJ6AyXcD4tzdq
cu82eSj60vLvapm2IgI+qt4x04uss2WloOSjJd9O1OTFmydlkCKxdlAFSmGvB3oO1GQkwjV7RAR1
csMpkOAxnRYuwSMkVzl+cmOxAH+JT93ShrPTYnu8AFis4T0ZGR3i0X350j39p2uzyBoXy9jZGiu7
NZcchCX/ACE5xUxnwfZHiYmCsqR002jSxKWDHNclVWS51UyIScDB2IiplUypnMY5d3DFvqoYhi6L
IdxIzcAMRQhifrlKiBAW/wCqsaST8unfT7mxE6bNcNMwDl7AmRLbc8z5ehcaflWjpesKVWpU2uV9
jkCIi49k/wAeQQ3mxjIzUzJnmX1sTlnECuUrOLUYFIUyQjAmHs3Y0xblrS/epS+ZxvUXh/KDq+3S
JkKrX2ENXGbeShzsY/DdZVyxPOjWCwplkj3N/ZZuAjJUkdUjRwGCPfjxHGbtJ2TsD15GyXF5S3Lc
b7a8WzreqSk9IS9XuVdai9ma3PoPq9DRHOZn+dxysJO2BZRqPbpAKXt8QbQaq7v1wqdEZykNX3lr
lYyEi5OyvZBvBsnLtfurRR07YkmZWL705/Nm/coSwCuv9ClzH9niEXzpRN5MDqm8kMYZSChmerHU
iYIL0asQU3ebxFmeYG4a7z4DusE1YahaxrlmMMEiElKfkitIXGoT6tpfwFNw2wo7eTiH+PZCJZt5
+Rhq/OMHjmRQtUXXa2wiGzhGHRaO7goo3BTmk20M9AuoTHeoe7TeN8oQUMNqgnlZxDkSEs9pbJzt
cIgpMsotw6YR4qsFlU0WSxJjbtVSJkMJzlKLNsHo5c9xF3xvjllMYpvFiyLkWaxKgSm26TmmVVvV
USh5KciLW9l4WBISKSdWUyLuQhj2AiCsBLJqmKdhKhYW9bNBOaKa7xCjJzuOVm+bsiTOOq5Ku5q2
V2Li7BXvVwFn1qDItDqMu2jXvrgy7FxBwNgRV8Lccpjdgfl5EG9riFRgQnMsGIsxpINIAFpUBm4n
TBd3/nRMvdT8vr58bOqvawJLDc9hC9Ywy7mrIFoxRMXp85bZcjoCJxzFQtuZRcUhC0umwF2urhgS
xIHmT3OQUXhySpWcWaOOYDJCJK4210aaNNORcMO9NeN8xMcUV69z2T8wQN9na4vY7bbbREMKjA1+
olZTk5FQdQoTSQnDQpHk6WRshZIvjR2pVSmPXvdtP0rj1xApzuVcSqnl7FaqpJEaSOU20pTZes79
+dXauTeNoC0tI11yiEOvGVidRdco92MptwWWrvQnFY91sMNJ+B5yMtTq1v6hVq5Fzk3MrTTF/Yoe
IZuXdylZOvt6q1LKyDZzIKHh3c+MYk3WVOBCpKCWio3S74FCGFYVEpmAUjACVEUYKFS03qHtcbCu
2XlkM8Lc+NTaHZ3ONUTWwY4i8p6icplxrlmTv9gaZMawcPWq1FpyVWUQ/J7Uo/JlsELRNEinql3k
O2ioyQKnCGYdF24nd+pbVJjzNeO7hU6lCWSJVn9VWVc6sFptCGbsiU6616Fim0JJKRlkm3Q3Buik
qcXEaYrApEzm5OUptoXldMFnb1iqXxDIGKLRTbVlBziX1nYr5HM3r1qjUIh2spaG1nx3WpgWz5s3
cOEfBYCwgsggusnzJpKGLLF89HxmijW+BoaFuw/dbbNZRrWD3cTQ73NvX1dyPMRvJHxNheWWBgG4
xrQ/sTD6DCwlan9lyZM24cGWvplULZNCSC5kA8yCS3EzO+c3t36FdsvKbD5W59Szt1p6ssK6ncxV
TO8BAZUqd4eL0lnkNqeXi680g6tRomMjzM8bzUJPWGSUl5mTPNPkncuhXla0RlFKV4zwDJCMe6k8
84eyhR2cLUWN5sd9RyFZrJJ5IyBVce0eek6rMxsGm2rNrkKJLWQmS5kx2okPMWdq5WqJ4YSwJ3Q2
6dBs0M16McxYKorzIN0eVBeFY3s2PXiMC5sSE4nOk5OeRh4q71yrupWLL2qfM6bJKol5ycxw5g3E
2IZrST5FmTuTdR26aR53Dt2kkzauHH69ZZVQ5Ukip/2gnMXk8zCHAMV5hD+GrSIN5E3Q5kG8X40e
xAi7xP5UeIrPrJSNOeTYvHuurUBIy2n99OXuWn2enWYqc1R42TkJN8wm5KoXxPJTJ3bSvZ147sNg
UsJ0WaVoku/uTxp0xKzFMxdy/vfpHMaPYfOElQq9mOKvmqevK0HKZrZZmk/j3HVNurZNTNy+B6hJ
zD5E0teJpVN2zTsK0AqgKiZkyjzlEWl6VTCOnLTrl9vgrENVmYa5UdtWEJWfb2p5Z4i5UeSplfly
Ob53qVLOscqqWMlkeEVSapIng39eeFILV8zUVg3OGJ6ejpY0fXqtU6v0+5W9rmKvX6RiJGwnG1hT
bfCxbRxLNpCTljO35kElTkJHAKpk0zmABAhtpgxLwqBf71d0piXUMcSiUrJxJPZAk6pzzmZ2Fskf
GfLdz+xtPeQ9feJci4Ss2lhpiq1x+DK3SWbPAq0lZ/FciV7K1abTS0bkS52FmoYHLiy2NVMtmi2S
j2GGmKkj41MskcBFnt866e0tErHTS8g8xu7W0y3O5vTsyj2ipV4b7M49j6EpBFbuHkosamd4ryMh
4WAjN9kILeN8g8wgLBQTgrwiDduZ4so5MUiLdMy6pzF6GKRNIpjmEohsIAURL034vMX0SQ2GPR/6
nJLNNNo459qkhiyzw8vGGcOL9jWByCNX7ejWeZKIwpnUb3Z+LqOiBno9v4u27Wzh3hMRKFRTCTEi
DGQQQ7yKiEkgivaZ2zJmTMS0Q0M0Ulxm05A8/k2FrUDqd0YZaaMRZYLynXWtSwbIUWhY5gLdUqlh
iHyW9YOWBcyy1fp7RrKyNiCbmyPLaRUDLXtnDRMNNBMB2SQwBcs1OJnG1Hw/RI2Qx3iuHqcG1tdO
jrCui2yjfE5JlITmT8gpkTLHzVikZZpGRcdElbTcbW6nBV6HrSL2WdvyqybTsRnnfR/3bMbeiY1f
rN9WNbo5siry9pTy5FQXqVWXkZTI9oZr6uPaS4lHLeQdopTYvhSdJLH5iqJn4XRekWZlqJQ77+WD
EcE1ynWMkWCrRE89t8bIO2+MD2BxY0H53tbRhmZG0nFxjKpldT8q1sD140bMYJwsuiQ70FEaIi8I
NbswSrESSQA2KZADKm85PkDYEcnahALAsXFeZA211G1kVygULELG60a32K7ad7M2sOHLHCXx9AVQ
0REyyNyq1CyZBJdkrbqTFZRctrQ6hUCqzcgwXQjxmzEVIUzcpPpI8jUb1ln0YCDseU8xZQlbvn/J
Fhia/JSGTaAs4gYlLBMY3kGr1pXcXyaKMya2FICVltBLgAv1GIRe5Nyy0JZIuVUxbcXV9xJRobMl
SfWqsPbZaGEMyrtYZzz+spyV5l5SyNV4ABk6yWRBzWYa/p8qZ5nnGXKallFl5psTgMfYqyTdslVe
mQGaLZfKtS3ravTFjRasqDKwVetFwtUrEy0e5Sqjlx+lI8IKEsNjVb/nCdWMn7fC98R0mq8dUIKZ
pkXDggLBOfXdxqDmHseHDSsh4igZaPkX10bM98y7h9cumiGxtkzD0LpgtVJx3kjMzXKNhiMc5mfV
CRsFGh6tCxrPC1nskHXEJKyYpjJSHnHbCnSLl/EwxXfM0dPwOYRZEd6QSo16VztTYbBEfW9MWcm4
ozGBIO4ybdGCsTWEjIiLuFduv6TmmdwiPAGsswmm8OWNLJmTFMwKGLxutCmmzC2UqPrysmSllbRK
4T0s5duFGVr8So7rLezIRky1jr0i8m5mlSc9MsJVROYp9fewcBIMjHSmpCZLYVCtAqilVEiKroN+
UzRJQyhFXAhGHMmUPaOUWwze5C+84eyHvHfrwnEj3q67FJSCqKoYxPqqUEKDSYnsmcwCzANYmxG1
2ZJbWT1anPlYl9UupRXURP05eLpkLi/HmLcewGM8U41gH6knG1Gp19STmikdyi51HM9JT9gnnLmd
fioqfnTOK5gMUdhRUOQ4m5TFNsAGHlMA7F2J7Q7COxfpE+o9PbJ19ou5Z6XNNS+pN/lSPLkGIoLb
FeIrVm+flJ2vylnbKUjG7YZK1ognBykbYe3aVABNH95aS/rXIgJZL1SUDbghKf6PZ9k+6PIHH2fM
TWupVnTrI6pLpdXCkok9o1Uh055eYps3UDTMtCR+TYlCNi15SFkbw3hY5u8arvLGikukc6sa632K
8aLhK0jGUEsAkzxGjUU53E5TKgJQGCn5/PLG1XLpPtO07LcOfk5P+IFClOmJf3u0IYpyCG4HKYDA
AgIDxpuy9kDcwcoplVA24copGEQKoA82wpmEpgKf6oiA7COw8GvnrB8DgiVx47q+X6FmRvbYN9Y3
UXBjDOZKnTERJqtVIO5xEPZr1U2xZqNI4eINYqyzqM+0K4cTtfaJFfGsh9+kA001u86s9CeGsR07
FuJ57PWmPS+3kFahT4ai1FzknKNxvsO6vdoY0poUj1VROTiNnrOK8fP4eblZCCY8tD0ZGTUgSJ7k
s5bQP5jvnaw9Tl5t/wD28LUWm+n3ABSNygBhApim2AxUjlMYAHoUSLoHAegCVVIQHZQgik+kE3IB
SCbvIp8vTm7QpkyGLt58xTqpEEm24GUTKIbnKA24pejIf26gZIvmKssRU8GItRVf0wWuHyBUn1CS
krfa7HW60wk6c4r1wyaV0wJZXiChFpo0AmaIcguQRQVcms8LandIuN9LN4yNh63ZzeyeaMalrrJ5
CI4tWj8eWWfkIGGmJWErN1aXKbmyoV9RNTuTycpde8RFNTlE4kNyjNwiIOGIQlU5Agn3cpH3kv8A
5DvEClYeEcX+XdpxNq/ipCYxky9kYpOUT8pijyAcvMQTbbiUDl9oojtzF9oNw68ORlVXrxoVyB25
CGMoUhzGKBDGSTUVVKUwjymFNNJRRQAEezImocwAUphCzPEvo55O66OrvrNlsv42g2lPs8XXoqhy
b9d9JvFpqXJHyas3Itzd3rs9Ms1CLwsEh488syBgVl0GqZiiJ7YnxrSaljrQswjabpfXksix7PKe
STZnx5DXjI2VzXLOc7jeLx1jZd3AWMIqMqlJ/wBY1GMfIVSvu1NrGZ4M9u0B+69Bxo3bJT1gghIx
MSkL60iQMJBxENMHihEjoRmDxLZgcc6M70tQXB1daOblM4MmCh0yrFOmJfbRUUSSIsUQHqmdVZFM
hw3KZRVMhTCc5AF8QjAq7pAiiiBW6opgdUyhCpFFYS9kBlBECAKvaJ9nuICpzk5d+YN7qc7+jnod
o1ZZ3wVpyyDDVa10O0OrA3xtlNvMxlYQoS1FhrjYZdnkatpWCUnjR0jP2pmDSTpaBEqbGto576wy
RXnrLH2kLA+nYc2RU1esvYyyDVqjaoiuV7GFr9ZaG6zje7MY6CxowqqUk4bY6g5k8jaGTqwpt7Ba
TwMJFTtXaGusqRHQgdGRFezGC69sEqIIDpB7JAS8iUyVQMcgTZBcVCzMgTGYyAB+su7ewjZjnsXW
3FePcKYWoQOZ2NlW0ja8lvoZmS45CtwrTLdnX4xEDetKNHYrrIoNoluuaRmFlk0kgVOcpTATe6TY
qDZJao2WOCIm4pePav4xbnSOR0+BuItklFikODgwPGg9jt2gg6b7FHtkhN9B+vGjNaf6RC4Yx0f0
VGv5GVkKcxg6ljuuVqAgK8pM4joU0i2qcOms0gY5JdhJylsnpQ0fDJQK7R3IOlEFkFbWWCNPGnnA
Vu114pxLlickM6ZFaSefbtqYmo20jO4huMxUMd3TI9OrVWtiv+td0h4p9XXkDliRsbdihbLUFiYR
aljpT1N7ZCRLobzdLveAdmuKkqWkUSlIBJGZLVHdYcBQ2uEF0OOsKkypplM03ztR4LZZYpzJAmqV
PftDJiBwJsKZRE4hzATYVUijzCGwqJh0E4b6wSFMJSnKmBlBKBCoiAmOJ+pQIBephN+yAAO4eXF+
K+P8X5h0e6yMm5Cr+m9GSxLY8A3SnXjTliWu1ydxybLWX4asWKkPu5wdEJKuWtSSUQbVl7KzDLxc
iiAWTtyGJwI2VNB0XjbEEJqTdZkhJrT/AJYK+Jg18yjJg+UMiSDM/d1m9hqKSJqHCxdQsu69ntTr
IEq+PDh3mtVq4Ie2KsfolcM4ULC1YghiwdRQFsBmyTiLOwBc9U2Yh3uGusqkcAQPq/hasJRsqZb2
RTMHOCXsiUfpOZMvIO3kfmVSDkH2t1Uw23OAGROCKIimAgmAlD2txDcvv9oNwEPv24+ieh6etK0F
6PLVyxiHenbKuYa1hui3GwZzUn39jRp1oteUq+jXKhiZhMVVCwUAEoZdvU5u0g3jLDaMkOkIKMYq
VwxFS/PFJ7CsvsQTbeYgA9Pt2DcPs/x4zOkLqu7OC5AIEwxJKYa6SI7TMQ4IMpNaURISqqPcMnA+
7/sbavcNhDmR+k/WjzF6fJt19r7Sb/Ppwk5l+13+j2+O4bb/AG/18N9uMvOPUN0vovq+0XYf7nx8
uMPal9n2De39T2Te1/d6+192/CMNARni4/QbrF2Y1PPJ5E8SpzD/ALo3u6GL19/u+A8YjGOn5FT8
vdt08/d8tuM+yv7if4f9eE6nXfbr7I+XX48V2h0HPJ5Ex2w8xiDsTszD7wKYoj06e7f5/wAeOccE
SEDtALuPl5bj16fP+XT3cc4HawCQAHMmy4fnmpPD2gbblTDm+rv05vs69fu4KTEua6fUcGah8RW0
lkMXLaGPDQZouHh5ZtHT1NuUHbF17CZawwxEVHMYAtSeA+sJj7CUNw32GdbtA5tykDsfq7iH37b/
AG+7/DgnNHNWhLll5vDTEDC2TvmNcvvIBhYSKOa+eehcZ2qxRTh22QEXAHbJV1Jx7XtFRAFt+z9r
j21xERF4vAhoTFEcTCyUhLTk2rje1kIyyLsAwkpvNP39N9hOfr9osodMqZU1A5iEAQ9sgeZiBuO4
fMv48aYFzKibql7X672i+x5fqAEevn+zvtw5bAg4F49dgDchnTgVwTRMUUUm3+4bGL7Jh/4S7j8P
m3xAUxACpkEfh0ER+HkG+/8AW/x8/FhKQTq57v2O+nfZmEoLAdTSFA+Sfz47rEdo+y/WMEajMZZa
vLSzyFbpz6bcy8VU4uJlp+TaPKfKQaiSbSwWGuxS23jzpMwFmzbGIoUepTBwZtD10YvqiSdGWjcp
tMfVHMrvLdCdQLatxVscp2CVCTkKTY0Gt2XixpL2REOzRbzssuq7EJIsGa0bR3FcGK1qfEZGpb7K
ddk7XjtnY2cjb63BySMKtLRTX/bGhXzk5e6i6/YIJi8+3QB4t5yBg/DTHU5rOnaxWsV02uY3ouEb
zjSr3mHdP8Q1uFyqGNm1tnLTDQ0TOPZ5yyrdlPWINkhGTIqTRu+IFM4MHHq+iB0x7N/p73dyCDVp
DqjLMuaCTHUA5t4RdYcXaxSUl2wpD6SJbNsnejaVl5JyjR8ryecsi3eHs7fK19trecobKqnjGePI
MZqdTlLQa2AtOesckUtPVSOzMzb7GkFUylETmLvNGLdXrPF0lo3kYSHnFldNrK2ubdDvnxyRVwm5
6bu0i+mIcGcuVJNdSmT1ejJy2vxNPSRG6RIpuICQBZWrGg1aAygR5Q46Giajcadj3I8DHwQnLHMz
3mtw0pLp11osYzpnHJWFJWOYqvAFFRkmoVMwlIYAlzGqATOmLKGQ7rirFMDjOuxVRwZWLFXqbEmy
vJ5je2WGsx7QrbH7OWlZR6lDJKzFunpaxNoVmRJSJqB3hSGIArtAv6I15hovMBAgGWFR6x6tcmzZ
/tYi4EBcHaFxulSREz3c1nCX9IDjFzJ0RnG1nIpI2PZ58b2y2yysB+UIrfNhJ9WNi6w5bzRV1GtO
TlYc8MR5KKAkRgJkQAqYiVkE10xLZzZ6pFP8owmNbdjfH1Im75AybaHzUrKY6bLqt7WEm1ta7FjK
vhQdVt8rESbtQKuk7gjj4wnIEshGp6Gsd3jVIjVYYKunp8w6+03RU7WIpu4rt3n4bKVGxqeNez02
3Mse5LXK7WY6V1OtLI87A5Rj9gMG8O3fCERibN9M1G5VoOMLng2U1J2nHUjiemtFcewzSXx5Mo1p
jWXUGeJFohEqvGyEg6fLLlStiUGitYTNSThBV04kH/6gQHh3y7pBYsCKMMjrproZWpdYdwQP5OKh
mo1lpvHl4aeva4cMts4SedZbHmUHc1FvqpG1aCTt8RIR1ip9Rx3F4ur1cyOnIHQbzgv38E0sy8+E
VMzyhlEokGZjHKnwOkFqLh6xX8qTMalf2+Qcjw9+gYirx7+LJhusxl5n0z2qQaVqRcSziZLH1CMl
oGEYShGwHkZEkmiUVFQMawXJuD8KV7OfpF7GSKxtTy4jDC1ixsxstJ9acU0mqZPsONn1qUSxuyjJ
dvIKrQFlNXSGLWTBEoHLMn7NMwKcSFhjT/pBtOpWUZz6lKXtWbcNMpXEuIXVXkG1EqMjctN5L1M5
EPHu4eTiVnXrMmSTokQDLelKtyTUWV5ZIqBYvFYl16TXCKjfYW0Z8GJy/VcBjPud5AWI0EQtoxyk
wb3fTy3zquidTtNgNGmRNNreu2mWtuRMhVq9OLS7kGidPqwVVc5EUY6DPtMODyEGmds9KSTERIQ4
HDYpuAKXOmVURNsAB5iIiAb+e4iPQP8Ar06hxYXiCFrUnTNXGNZmtUyel69h1a50yzK02Fd3KHkK
Dfq+rYpuv3KSZIXKOI4rkXMEWZv5kGpUJApzwJU1Siav5+kkg9VRMAKJD9U5dhIYPkbqA/j5fHz4
wOkLvF2V2XeYrmO9GIFKHvzGedmoEeFJyRmwHAN58sbTzpWzSXTxnjGWa1mDydSodkTsTmJj3aEd
JTMcVpMw0o0LISIyjVuKyaqYCQBAR7UgCHtk3lOwalWLfUXa8043q5YaBt9hm5CUol1cR1xj5hjO
qg5skJPsgiUoGyt5OSEESpPmT8FYkQVKUyHtcC7UXUewtdVlnTdKQj42y193KsnfK8QcQ6cj2kq2
HxQW5RKqTY5y7dCe0b2dh4sn1wYro0/r2tOJ6d+TfCVBm1sYDEGiKu0qVBqkPaMP48tsjIFr1Ejw
j1HEw7nnZE1Rad5nlElSz0+zMQwAxAhX32aA15g/oTT15K7LA6cyYPZvZQjE2gQHLeQH2GY+louL
qXxwONdQ2P2WN5eDjsu5Lqt3qMWysrI9Vx/JQLiyHYR7CMJGi8k0V5deWZoESkz9rGtYgyYGTUR3
xH1Nwa+jOM0tqVaeeTkZmNbMpLq4nGoxbFotXJGMSrLGBNGeI9wVbWJdVOQJI9kdIDHKcSdeDEwB
i3H6+o3WTVlsU1NFlhLS9kFvjOEyBQoHIjU77G15xgghf7JFzb1zFTl6yHGNWL6ano5wds+ZWdy6
hrCZF0U6kNae5rHTytaustymKcRT9grcxR8jVqkWGgQ1rp8dR7LeZmLm4OspTciyCpEaSU7XmrWy
tYteyBFtiHCT7LlEXod2vKy5vcIZllCvV14DzsnjSSzqLn/x/PgLMPMGrSvZK0x6fsEsKHJxE9hF
CcE1+WsTJ+WbSnzEePESxiUbGrIR3f1E00FF5KWRiIY5Ft0m5imHFqJ1LV7OlMwBXY6kytQm8M4Z
peHpKwnsTKRQuCdNgwbs5DuHhppSOdmefpQnbykqcW+zgu6ex+Jsx0/xBA6Dsm5MPh7F9nyhK6ov
UB/I2qlozMpT61bca2afhW1Buck6fWaup1osE0WOESsxK/SUSUd+spDlMMh5CqWIq36N7Al/p2M8
furfdLBkjH97t7qiQhr+jJsLd41HTjK/C/GfFu0Tq6kaMAVcaqSKnGRjRoIvG4qx7NexDC/bYbvT
FKQBrk+tHLO5YsC7wyAZ0B//AF9D4mwmZq1IVnKuU6VkWOo85Uy1au4vibDFktDR3J2X8lbKMims
sV6jGxYRi71CAanfquIuUEpTpmUEAOURdb7VbXVNYTTVS1x7Ow0clkdvk9fH6FkamM8foFTfKs0r
YEZ35Vq9fKpNpHkhhIVwomkpsocpRnvWRWMb1DS5oqNRseY6hXmUtPdFs83b4WgwcPcXN8qW3rnN
O7q2fr2mfQkx352U+vIgYNuYPcDc1is8c1GH0/Uqs4+oEDBWnEOm/K7q217H8JU7k/b2DGsMzmW1
km67IN5a3rW5qirPSQP3ki6j3iZ1VZwolMYCiFeSG9rhf8ab72iOsGBQx93RUzmHBD2REgoDbMGk
93V/PmGD2ZeK9a8XjTWjZtWRscSMghMXHI91jMeJXEWqbYMkOJadNHPLAEOV85aMhctVFgPCGIkV
ygZTlBZMTMDH+pWvU7IWd56Wx8SVo2eqna6JL09OdbR8hCQ1ltcZbotnEz60bJJ94h3UA1BB8lHi
ModRMEzKCYu5W5xTxCz1eY4w8bEuKK7i6t53pjxytVcfRFTkrhQL6rXHkdWLaxrkg3aWUnh7htHJ
P3M63XOq4RRJPmOqQpiOo9YxNkf0h2Y8Ll09YSZ1uiw2pulVmPiqLXoSAOtFWjxOsWyXoAIzVTsE
3R4n80jo+LgjuH3kmmPUOKpud6RE2iL5DS4xMFfCUkdpgFaOxluLAwwasRMSl8r/AEOX1DhLTdck
XDamcUZ5eYxfPIzBlDplIx9VIi5toNdeIx1Xy1GGeXiy+DzchY30vXXBX01JRsLFgR8qIKnAx3QW
XTtdYkEtas2Jv6BYyYlzZbpXIL+g17I0nVpusX9xKPXzObhL/EQZzvUFYqQnK3ItEYgwEjpEqShQ
IsUDFnlGv4Rxgx9Hvm6SwTj27VCfil4LI0YrE1+gReTL3AWGGgJCSvdCgW7mATK3OkqkMcLyVNal
ElE7Cm0MUwcD5nGewjhrPeuupzVFrTJpZLtYmmIlY7DWPsjwONFGWVU7AUkfVLeaPjajF+rKqcIC
lIYIx4qqJt/BOc5Sjzx4N6AEUkMGJwgSIAAAJYTJGkqEsDwkwFh2UKb3HV/L6z1tgP6QGTnVLZXM
jVWdsmJ5W4Q1tq2NYC7O6krSD1dtGVurQCl1iOeTnYpCsQLauTJORRJ+3OnMKgZMxVRmSkelwvNT
TmFX2NYZ2ecyJkm7dvCPxrTdzB5JZLRlkpkyLdBV3aU4BB/GKRU7NmRnkyRSxiMwK3OJYUR0YxhD
3G751yzXKHj2Cx5iHJEbK0KsJR6j9rnJLvdPVNAs6gvBwhI+sB2cktEMnKyEtsgrPlW9niU/RxUj
T9J6sss4rlK7TdQVTs+H8kw2M7pc6wiZm3e15H1ni7elR7nGKNj2sWI9xaTiSgxUcf6OsqPx6cUj
r6UUDjWIoLEgkETAesmwvR3mJyBIEXfVQp/28+PcKOC9U8Lp9s92yZQ6I7Uy1OxVyiqbPS1zcyEL
QYOyOV0Xco0rzSIMe422Lhmrlm1k5KQSg0+7LlCDAUVAKmw1qpSwiN4t9GrMo2zVkOoT2PHWRnc8
R1FNKrZpqIdzBGVQNGioaTXYtXMaL4j0TmWbrIcwnRUKUktPOD8cZo05ZTxzbWEHXL9H6qcV0+k5
IiqNUJW4MF7VWrtEsKrarc4Qg7jLUB7MqpLu4hGamVzHUT5oDc5QNrtPeH6ZW4r0iGAL1jKmXLLO
J8XZFlWOWTiZ+StSOHMoVnHM2jRGMjFIhHGcyM67cKWYxYeeAUleZoBiG5VokO/okYomQGJArhDN
xLaGlSbGXDuwHUJVIZAN2c+6vG0IagdXELmzT5p7wmljZKDncDxLqukvx7atNL2RKdHaR54mSiEn
CQSX/kAXkpfuP9ntvxDctqGjmuFILDGP8exmPDvRdPMr5CZSaT67ZceISC0inC2OSaqRswvQYd2v
Ko1qjNncwxiVm8OnKOinVRA1pr/RZBZU01aHqLhlnjauX/P1cyNdrLbchVhtNT87Zq51c1FHJ7eO
lbpXaMh/6fU4aKcMzf2bofLgG6fjmlZSxLkfF7it1LGmTtOzeav0tm5w5l2dWulYbyZ4Flje0qJp
zL5ayzKtj8Wx60ZwoSB2tekXSiK6Ue5OkteYF7QIxBfbnrOeyQQDhHHxkzOLVgJgmbEUf/4v9S43
WiuKzzXa/pntuBoigO281kXIVRv1qvDmzLnWXl6QylImGRj62YncmzRwjOuzPTEmgIUqapjjsU+w
rCY4hugCXL8SmL08veHQP8Pw4s30vUmpXrRT6QOQmKVj+YsmLobT7ZKZblKTSwuFabSduyHFT6bS
7eBjcXPizeCaHT5JsQcEUTOXmKcgjWO4IVQxUTCCXMHsgmIbm+zYdx+Qh8fxy44vK4gWs4yCAATw
yAlycpvwYkHabPEppTab1Ibia7pztO18zj66YWwlh4sNMtj4WcZDOnMurvPz7J8a9P4WTaM2sFMv
5GBpLOCdRMakX1OZSBJFV01IHOZdIDwDHumBJdqvLoO5CJB+2cScY3eNmy0o1LsJkW6pRAW4gHmU
ogJfeHFoeTcx4UuuCc0XoME6fKjPZlvNcqOGseUKp0uJuunyHxvBLTF7vL6bgYmvWGXSyqo/jO6d
+cTCMwMUuM0dp3dTkqnWMRNXcpR2IOyYgG4HH/g2+t924efE3wRk3wRYy8ZYMHoZb+46cZWNBIf+
UkChm+k+Ra06b9I/fLjK1+xWigVd3MYwvVVt+nJpBEjICHwLExHfPFKfXodgxYtLBWbX3SveJN3r
haUje5F7UScocRJmLUdTcivIR/Vse2GovWeSX1+mXtlyZY7wvILOZKFUa1qLbu0yMq3WmaaSpzow
ZHEokVNQxhACG2DRiRICmO8OYjQ5O0WEgj2xE/8AeNw6CJP+Iu5d9w3+FiGqzRJXtNt7k8OR2YXN
7zRG2CkQreiuaieENa4zJ3/w44qE00mZtss6a7D6zBLDAnQ/+S+/Bw5Cv/SsUsiIkDJ0gVw/VuLn
W3G7wocknE7O4AyBy36/a2i1B6zF9RkdcYaTpUHVWN2z7M51VkmklJTR688s8GeDXrLVB+kkDlAe
zOQXhSiXmTULvuUQAcKdI4/otvqF0JOSF7CtWaCsjioBDSlLaSjeDfElCE9Zzycu7agVwommP6FK
AKHKT65igJw5h9H7WqBYcKRVUzQ6tjDJedrHgK4KnjStJnH9yrcjUDzi7NduEU3etgJaQOxMPQ5F
0jJ8xVS79yHo08kQGCdSmcrpIy9armH21fl8UA4GMlWea4F7eJ/H8xNpLNZwZ6pL1t3Fxj1oykGx
RkCPGahSmK4RE9ogvkAiIuGgRuyIwUcbBgweUp1eheVAoEBOZyeg+GfmTvbg0LL6y5dlquJqxodY
Qqsw0yK9yoypikq4stdj5iQD/WNdJ1IKEfENJgPQwNi9r7hHjS3DUNj2UfY3fVLCTaKJSLlL3Cws
7tfLVkQl4NJ+EeHVx+WfO17lWIIIZjyJRgJyUj27fYxwVT5hIaEau3jNs/feHslJJmLyYkCA8CKB
0fkWlE0m3suRIp7B2Ib8p/ZEoDuAHRqR0lUTAsvjlBjd7zaKPerTLxqF9RgsfyFbsVchj1pNzK43
lKvkZ87WnWp3bUjiJv8AEVZygd03KokUVkwNN0T0nFmkJyckzLTDnvMnlMycmxYiLmJoUVUMwNUP
TxzlnZn6iNUbPPMFRq16jO4JxTntscOLXZr5NZMyLa0bCSHUPUpi3WaPM9Wq1aThbEePhHb6YaSR
Hbgyb05RfjZZjyl6RK0ZJzXibUkyxlVKxm3Hc9HWufuySppkL1KVyPgq/DoeEyAojAs4GJiJtcgw
5HJZCWeikHOsfbhualtFaGAqvdZppfHlolcU5gNhnJzB3CIwrRxYH0OpZK5YaU6bTU0m5qh2kFYI
93CWIzeSBZyqiYO0AwBK+tTCdRpuO9BVnYr1hrTsv4ZbS7qQouFaHjy4GbR8jVFJGctriMmHRsjX
BZOxLHGWsMowjOXmMJtuvFim+G8COVpOLqiGeslTpo7FwQKGRGcrAUbsf5DxGYlwzdmrcG79LQVa
9VlTka1Qse1XDzWk0WrZge54sFfG8zVieWy0TkfARzBEk1IoJzFdhUWkXLrAvEN3DfspAqgH5FQE
dLknV5O3DVI41V1urtMf2s1/Z5QJCIvXFjhErlGl5zyBzSBkpAp0ye2c4sw5C7iIlAOH5qa0ODp7
ql/ftb+8tcniDNaWG8lRS8IlCxMlYrTBLWyuTlEJHzSrp6ySjWzhpamk/wBgV8KCxI4AFI4FDvE9
M/KRlLHeOAk/BRvl7qVK8XKQHKkStZpkY1dRu3DcXg91Hth5AMPY+39TqAdve1XsXQYTGIdJCiUF
KsJcGYILAvkGnZgQIKx+lOjhTAyw6aM2k7S3mHOFKysQEa9iCDxcvMW93Z7TPJWOwZIlH5pztvDY
SKcW9yhI1qsx+0ryVSuuo9ta/DYcZ5218MrffouVj8XxyXeG1vuFgetRMUsDJYyjK01ftyiTmYuZ
5LNku9hES9onvJsYSfTDnJuoHMXgicz6XGWGsd17ITu3OJptK6gcw4MkW6MSgPd4DGXgH6aKBJse
WZsXikoKdWH9Ese5u+VyXu63LNuqb0eimn2uagnjLJTyzzGnC8YugrpHrwCMLXpeHzChaHVCnKia
Pm1XLt0zbV5Fzd2NhFuLFAO1qYOycojy9vCiCJeGXHJbbOcXaSlpby247gbXKbt7iigirAVYVnTP
9zYVtXmrWY1d5xmc7TVOgKFNyUFX4uUiKxJyMuwUXiE1mKFkO7l000++mjX8ZGkYicDmWi1m4EFR
uchXZc9VbDI+E8L4McY/h6zF4Zcz5md0bS01NWGfdXVx43bF3cW/kka61Df6Rmc7IAOHtEHbrxJl
xxGwyNiv0aFaq8VQ6dd82qWrHMjb2FdYV8H9smM8+pcFM3R7VI1vKTikal7BpdNvNT6Q+yLIo9OC
ZsnorKZ3TUFG4qy5ZJW76ccnY4xjdFcjRDOKr0+9yI8CvNnNRc1SbsM3G9lYhBYO9t//AAYe8Bug
HNxKbpebqu+wExQLucKhCKmSVKKEtVi6lJSBqpMnIdVoZdoi21YfLwyfwO9wVgBxPGFTl4G+ZBcy
7FTxmKQeYjq8axCUjzckY3Vmm+cJt1HtVz7FfdwhLEUpvZP14K3NPpOspZGpGW6HbK3SJthmirV+
vXpZqtOpvHthp4OhhLoiVOSE7SxwIQDXkcbFgpDnTEII3MXeHdYOn/CulC7ZAw8xyjmSazZQQr/Z
GPj+mExpaZN5A+MWdRif1+9Ya7HkU/2RWaQlEhHyNwZXpBNKlIj9OuBNUIsz12GW0d4Tq5KbhXH1
XQlFsyzYZAnmWRMxIs3larlaxvPJLxsSewIMpexOncAs1TTOtAwxHOjEWEXWGyEKxEBM6MBEeQ0S
DnPCZsLJLgw1kPFiCYdgPll5tn52r1omteUr+mC2aS/UCoyNMuOTS5Tf2uYNIqWVC0kgIuGYFZmb
TIMjt2hIBqBjKRUwBO0T3EOYvG3zBqEfZgxRh/DRKJUK5F4lirCyrM1EeNydlmY6xvDSs4S0uJGY
fM5Eiq6ahVO4xRgA5DlHYSiABHXHUe3WS7ymgoKZ+2J7RPbS5AP2peo7pcnt84exy7GAdth4uEwx
imGn/RyanMq98jI19S8uUCIcsvyfUqek3cHLDVO6NIbIci1SuNbBf1iWGQLW3UeJA5ucAAR2i4qd
EZcaIqEuOpLgUBJQgTm8tZBgSzPabylSVhcMYyAGDSlv1n+MrB6pqamSUyk0a54ixPkR3jSozdHx
jYsgRJp59TYiXXfuiJtK+zkG9bniV2Vsij+M9co+RCUTN2qHaFEDDpoDU/Z61i6q4tsGIMT5SgMa
zdnsVDc5DrshNkrLy0JRD6XSXiDziEHYm7mwtnNl9WLAyfwJlW68R3kTpKJlK6t4O02fkPoGbLxk
a7V0cjTd/wAcVZtC0mBmo2DyPjkUp13OWI6CysyrUDpTVSiTQdZgXc2DpS2NTTYLP49PhdijRfT8
wUvB0rdbdZ4ebzi0yzao1lUWVedwkDi/CYrBaCmaS0ai5cXuyDE20Km3EBqUFy1UJF4Xuc56y6d7
gxIirwuDHK9i6UgAMaAuzMQpwTKfCVLqpf8AV6glroK5599gHwFqqyHpynr9J0qJpEzGZLrMzQr/
AESy1KKd0Sz1qU7VF3WbBVmTqLbq1dLZZFaosGARpNlUzxge2UI3ZLYcub2y2HKE9fKjPSc86kSQ
WD8Q4wb05OMMQ6hSpNJHJWPG8EYU01FAq8PVnEGJCHODkSlOIWPYX0I4Su2muw6ocqZTyDTce0fO
o4onI2sVit2yWNUZqFpyVWepN3LgoMpGus7WUllJHRFiScV9ZOKpsDIS6pAM2MdaKNNctgbLmpnJ
moyVSxDRtRBMDY/ew9Qmq2pZEVIKqWtK3zSTivW2carKxtiWaJNlIAAOIGKHUQAcIQooiwURSImx
UACaqLJkoDMSc0AE2ALaAjQFRBEC1EnUBqh/vy9huxJqbYaX3OTGunyMaXyIy/jCVxta5TOFFio+
xs4m1t5tvZYOnsKdfLBCtGEpELkYlsbtc0ysZYUitDCo6Czx1gjUZfNPctbJWjFiX8XfKbYMZXev
2ZmV/CXCkWRAIObqU6VCdFw87bmKmdeO5h5zFKPtCACR2LdM+kfI2f8AJWNGWoa32qnoxyv5Bnq9
SZ0Z9ku0qH8aQqNms18OZCCmkS7w1fUVqKdPur380cvasv8AR8SvgnT/AIFo3pH8U4QvlOzk9rrf
LWJaopSsvVnGkY/dWxSx9u9g7w1TkLRXck4ilEVO2YOoxjCI3lI51JeJRIZ4azQq73xKlRccgCSm
UwACAZOQATIg5tnYIiILddVRJhnh57jqbV65Hy+F6slcmVMX4ppLaAhouKJVqDT0YKryrJjLS9pf
yNpYFdrzlvXcOnLaG55CUkd2LhEnNyqpgabMsa9s25hzPhvO821pFYvuAomqRGOlKDWzVmBho7H8
7LTlUSdx/jazlUscLtscpTBypEctxAClVS3l02nPEuoXV7mmtY9dW2n4kozHO2Wrk2km9fezK8Xi
01mnbBC0pvGxkXWoxnOJQbOJrZZFnLkr7pVJtPePqnIQVtd0X4Vvy+jK4Uqw5GYY01M59LgWWrtv
9Wpu7VqWjrFUIBW21ychY2MiE0X58gQaSLeVjJkqqqCSaYGMYhRqbpfnnESJZkdkzNciEqJy6pOU
zbW7NQ5eWH6S5dolsOv7PNshnVZgHFPxnBzWTk80WeNxFVVKKS2ZDarRzwlotblnMvS2NaPlK4hI
sWjszcez5V0wEuxuHFf9S2XtTK84rdKFhR9cL6tBp2bIkTimILlSwqxTLwpg2RuL97LWaLSUQ9uR
k254UiZOqqhQ68EFfdFWm6u5kqGmHHmacivs7pahq9gLIA32gRhK8mazWKvwMdkSjyFenFgb1eLP
KyaKNacy5pC0qM3acoWpHbrAS3vTDpe0SYmyblCjoWaayJkPFOSQrCLCzRZpkkj4APJJIrqjSIaD
hFDqewdNjPz5im3AwAOwcHu13ixlpQpSoizhYAEliqGly1JlMywA6xZIURlXqOqC4hgJcPU5B/GU
uNNfnTk2GZ6BT32O5aUtkJRJp2lMr1NOYmi0+WdNfqSnqyZ+WIcOo/8A8icjExg/YHy3kup6t8oU
2r02uMkceyatCUVJja3W6mw90v2OiyS8i5BrR7JZXTlWHYsXUjH2CPMwbu0xm3zOaTEbq5Rlz3J+
lGwvi+SwDI6nKxd46Pl0L9F0Gt0JowcoVwIVlVxjJCGFsnAg5GyLywC77yADT9tjC+67jFWKMeY3
R1IaKsHOrHUIyEmsW4csU5h+Xxkhci54k8vRtgu2UrPfbW6Ane0oSEsbUsChOK2NOnIxsIpUhhU1
G5jbsOFgN6BvURIuwUGKGWSkMsYSzkF0gpdKvdJDPjFEaMjGXBcSDNPCZnKgfMV4VlxWtTOkM32r
+R5iDsslKPZm232trrxGXMiuzO+8EbZRykR+zteRYlqz/MoiNmp5ZlEwgArL18rYOfhlBqGs6mX4
/PbyPpB7q0koh4VJ1UYBOlOJ6IOnHxriWpzR0WOsB5CSWSn5DtVW5pa7qp2yyAxkTlYCclt0NY5z
lkvUtC6dZXIdSU065HyUpliFk6lO37HjLGkJbTDW2OEZauunc+8u8RAAKLCi2giZJVIDGjrBAkAR
4bvovrHhJx6QKMpFVx2tkXGFrr+Qo6CldQsbEvrzU2dRwJb7nIP1q/DKTdcZz85bawdE5WR7BIRl
RI4jjThJQj/1liJeRdUQ1HCj2dJ6qGxLASDhU9HeTkBp0tEO6RVs61ikzMVTPOTt9dXF3I+rPMOQ
L3lfLMrZo2PyDlaKSjLRcqnDxlWmyREdXoOBXZ1qTZqqWCkrzqCZoa1vq09i/WuMIYk0aWTKIcBX
jvK92xFeYu/Y9sErA2yCWkl46ZjHqLJbw540epyfeVW5nAvEpqDkJxq9MJjlOWRIBxHtS81oWlij
UsumP0g2pufI4iZ/F7jHVexhaImuwN1kKQlkfL56tNydXrNksEFDrP16+YauxlXkwew1hIysrXGb
wDPDWcQ8laRsrO82YkxxT5Vzl+2aj6HU8sU5ZZudpbXcba2MhOvnF7aSkm8ia7JQqMTKvJKaibdN
wjGqRkhIOVEoNk5gE0LztVw4KrmsgXcpSEBgklkKAkaBKhRtMgx0wdigQ4i1OW6wHWIcAa5/l7ai
b1lZXnGrWMNE4wr1DPOp2KaxZSMYwVJxJk+wInSm2UllbH1ZfNo7IbVGwLIuWrK8P58sQdVIQKmK
hBNo7TrYz7cq7b6Rbb6adqlxZM2L7H7tgyPSa2zjZNI0Wpj+jspT1UpT+uguiNaJU0IxSIBZLwUI
wFCcx+6OtN2l+T1oaXtMFvjojM12a3rJsjnm5RlldyOEbaNXxtkK1w2N8dNQNETdpiYWUZNkLZM3
GFZJz1gkpNGPOajTbF/aVzw9JyhhT0iM1ZpWkWmv44iqZbK9AU7E9Yq7zA9kf6h4KmMazQ5hOMhk
mjF3QlQUkYSLjWkCL1USvnViMd2NlrDgRFw7ytV8iBV3CCAycKitQSBV5EdZmYTzIsyiGlIH6YUD
rwT5zrxlK1adJ1XZBxxiHKmCq1EURWn5nZM2d/GxU2KsNlnI5GWjHkORlaZB0/elJFScE2dxvZoi
HjyiaCW7oxS8CgsUhnIJqLJkOnzCqQ5wKdUEyFVOIFMO5gIkcqh9gHYhynNsUwCNrt70F0asYRjN
ZTS53WU0j5GZSqGOYIsMT8vDy8GajTFy5KRLBfkorFMY5CK9IF0jrdNKW+q1uBiq/XnEvYGxVl1A
sqem+v0fKWfU8dWp5MYrnUsSaNnNChFoWYZzSM/WITIOo+sycRAJRcC+TeyGXaedg8uFuyDNJwcp
3WtQDhuqZU9H3iMCq9xcyDhYklJCT2pOCMM2ZmNLWUpMGkJKiWMyc5imjedqhVWnYABllEESiIAB
lTkTAREVCgACcQDcTJKgAe8U1A8yG2SLJqpjylFMRUDdUAMAiBRMUoGbBvuYBMYC7kAwbmAN9xAO
L4nzKh4j0WaFrfRRxJjfI+aZrN+Rb1bbFjpjbZ7JTqrZfmKlS8ZsZN/EzMpF1x20WTFwyZPIepKk
UTM6YWQFA3C/0q2OKpibXDmilUiuQ1RrMa1xLIq1mtxDaCrbOz2bBuO5eyOW0FHqsIyATlrHOu1n
cbEMlzRKyagKkSOUwAhfujUXO7bYRVKiOoYCAB1VYSw7RDuxDghjQh7ojlbukDv4etq5x6efT7en
CHYn+8L+If58ZVFBEAEPIfIQ6h9w7bDv8vw4Sc4pCBfolRENwApimEQ+OwcwiHz/AMg4wogwBxPk
epsXZjXnl+RPs5QMIpk2MUvmJeoAPu3EN9vv8xHjnHkRA4gUhgTMT9ZuIFFQfiG+3Nt8f8g45xFg
YN55b0+mkzCUEFO25ipBuPQDCUN/f06/y89uH9imVyLXMhVaVxEaVZZKWerwtaTr6IO5mSl7NHyF
ZdxzZqJFiO05KJsasagigioLlUewTKc48vEdq+0OxfaHcOheo+XwDh54ytS1LyLQbeVcyfq9cqtP
KKpm2WS8MscMudRH3gVNBJVdQweyRJNRUwgQhhD2UFRTfikRTDhfEGcu2VN27exsts9tCMMkipBF
ctbJspVu+027WSp5Lii169Q7hRnYoNRtEpP490kVNRVqSOhVFoVFwmRVI6iBliqkIomYxQKcgjGi
CBlFAMYqYF/eHYADbf3jsHT37jwb+uKboFl1EZStVBskJbKbaZhlaGUrArJqsiEkI2GI+QcACqy5
DtzpKkcEMYBSMmcqgFEhgAQDC1EQTLyJlN5CYwAA+YdBEQ36/wCA9eEr2uEiNs3JGpqWaek67m42
pASoXbaz2rgYCJTZp1oAZUmLeI5RVq8Zu00UQMyDYiZuVdFcOn64faDp8/v+RTFkNSdyuFUkFmls
mb7letRydWZkimJpq8VeSKWvRKjdkQokka+pF1magY57ZUUWUezjY46apauUkqAuNwFNbtXP6r4J
dQ/h0+37Q6fG4HHWaMeV42hjMORMsI2u1Y1o+YMfZLhG9ie2rJMDGXgMmQmMTMSyEi0Os+hIm7xg
CmL0FKbWI88XAFcuUzVkHei7tC2ezRe0oBYuFkmeGTE9xIbOw70QkdeEhYkRieVCaffvFq7snKZm
ol3cur24nIe6HiWzQZJu9ZHevIh/ALVQG0FIx0q5hCxbmCbuMfMVWomQjoVBeukMRBJR8V745wzq
3y/itpA43rdyn8TWu2LeG15CZhG1UnLtBsRdPJGKiZubbSUiqzYgMY6M0BYzdYOwW5DgJeCQ1U5O
w5knHWnzEVIf4sr9nq0vYoyWmagEyfGNWq9oetW8OlK3J8Kl1Seuhav7pc0kISwnaycy1iWQIquk
iKDZhC+mwtkqzT7fJ0a6lsNUjIMnh2WbO7FIUqVyPaY8KCV1WIN92MgCEjHWGxziZi16M8deR8er
PCzHkHh5F2u0O/x4YjoIjAOdoQUlgZAVGtGnYcIld1BJYPQAagVbfpbVSU9q7rVCRyjJWrIcLTZy
YZVtG2ubkMW6tj7F7xGPh4+OM4kkbFdY2gvoaLZeKSTeXRqryGctoRRws0VIRmZEyHqEdV2iyWUL
fa5CDnFjZCpUZZ7KeQBORk1kRPemdSl5N29YSlqO5bTkRYZOCC0SjBwg9Zyi6CqapjbZZLwdd9OO
HYbJcpjV48o2Pc+QOQvEYop8vHyE7tl1vWKJKrvm7wr1y4eTDyop2fw5SKUSiUJpZzyoNnBibrP+
W9PWU8SZfuiD/FqV8lqJpwi8RM4Fj4Blw1rrcbTKvl9jaSNVVkH0WlX4+5LxvenjMgVVSIZAASSy
JjdFuyV3fbQr+8QFtmVhgxSHkcW8DSrUseAEANgEg1dGsGMmhrAtWWYuvyqGUJXNGVK/Xnkexlnh
D2261SYqrdaAWdt5iQatXLFxUIiJmRc21u3bxdHiFyidN02UWIlqULq4nMxSszRpu8OMuY7asfFr
5BXCEQf1JFRi2oDEPyoKTRoqObSEk9Z0auxq8uiEiDttVGJFoNdJyY9KblrG8bmjSpmHJ+dMfXid
b4FuuKM1PJmfkbnYm9pnKblKp1kL84kO8jYYxvHz1eh3Eu4lHKMG6bpNFFElhKmMA2fJtcqliqFX
w/ZcBspPIFCax2oeOdsmaemZ/O1ax2aSxypKICkEYwWiKsjWZU5a3FLnkrO3STAFHIlAVxcYJjhR
v4CGSO3LFJ2mAzy18LN4kbMw9kltXMmb01Fh8rmHdVb3JuRcX1ev3BDJ54eYWyTW0pSDg5ucr7iM
8am2Mi/fzaasvFy8N+lkjs5OaQcRv58Qxmo9rwGcoLjtlOhfZMYqP/3DFPyGBP8AfED+wYC7iBw5
dgERDi76v6j8SWz0rNfzk+v9HiMdt0RY2TILpstC09y8iNN35LbBNJmcLoLyUbJ2APGYZAsMdF6l
9O2FQvtcU7ZSNDhdLgeGfJykIpbJ48XJgBECyrBGU3bJt0ijypFWD9V2e/aB9Tm8+EukYAVdoARf
kxhAptCkYnarSEpOHNhQERf7EMiTOTubU8O+jWYrZyCY7FMAj7thARH4bdfw2/7E1lWDz+5r1Myd
mt9Yn7O+QcZMU+fuFjZTVlma41Izg41+mxdTDu3to5Ov1busM8tjFm2XIkcGyhwTMAC61WKksksI
Iqg16KJlMUxlNvgUBER/Af4jxYJmqUotv08aTrVHXSizFrpWKXVCyDSWNiFveY11X8pXNVlHLRLm
OGRZxq1cdtSIyjh0midBygoRQyaqYmUukGDEud4WSoLgGSQosodUDgwaj+ctCIcGVBTgAW+oswsb
2fV3Y56svcaymbpmyZGiZHCdXmYKQsYPLbV0GrJ/I4trc6PaMJasRjGPg3tmi1FXTaMaRx3Mg+QR
SE4bel4p1VpX+7YUpdWvrW8TkS6HIFRhpZu3JLV+OK1l1n1rcjIxcJPVwrklbmouRlZ55Hqs5uHe
IrGQkmSi1hWmHUHjqu6p9NWaEM20KGw9DyTmgBirJEy+r5tPFZeU7sZSOjoiVlHEY4rEi+/2S+xS
zuwXZ3+kpqBRtG8bxsNI+csdwOufVdK3rJ2NUaFbcU6gMYVq4Xmyc1BUrzu2sn9Eq9edTLhid9AK
xkfBoR0CxdKtnUBHGctXqjRIVC6QuN3h/wAu8hfVBLrqTkDqAJzzFg40/wBhPid1ZczfO1cdIxrq
mtL2+6e6REXKXXq0gtaMh4sZvysI1hMVR9H0dV5YO8yXhUpJwczZzRcWUjmXWlWZypIApzlAdzWa
vquydR5vG9cico27GWGph3YbLRSlcv6RR7I7bPXsrIEgnb1NpF2RdnGyLwWsazXtotmD1cYrsmq5
yEPpKyo1g19a6dhu+OIa0XHD4r1bIVsnyNXsxkquZTi3UKjjydPY0ZN0vK1w81LRKKaTh+zdMopa
TmzAKZhz4Tzq/hdH2o+uJ5DrFOyE6zlj7JddlnNu8By1cXr2CtMLe5StyDWcGUcPFir1wqDtVgvB
qeKvgdDYxUEDWg3O4xLuy48ZK5Seb9UEuS4Z9HNKTtdZjDsISqQNTu01eVfrYelYbVXlTEyVnlG2
ULzhDED5epR0vKKTEvRqOLIGAuI6EaKLJC1bMglYsbASDj3YR4SLAXoJd8b9olt1d1LWfGdTyvfo
u/zOJoxnFY/pFrsyp3lYaxMEp4IwqtWiH0g1Wa1lqj+gorvUYarKPw7ihImc/RcGx+X1kX0WkFQ4
u8U2qXGI1QWVi5rNcuKUJkKx4kslWtzmaXmohtOrPzVmRuBWfi7VVoJ5iMioZWIhTJmbCZz6pcxV
i2+jr0XwcTa6Ca1QURNUO7VWrW6IkLulARjojuvIzcBH2VZ2yhE2pyHkSvWabtKbVI3UhSrmKTiv
sMF/+JHaYnHQYQQqsxRLChG4kcFRpf6aFl7yvl3fVqnWQKZBrWqJpB07ULk+KvqMTZDwDqmZPsSh
wGVMMbGS9UfQcis/kH0Y3kImBbSlUcPU+zlY46b6MM4bGKqO8lmmsCkWenZllWuZ65dcxgjJU29k
lZMLRkF9c2aUigutKQDhd/Lz05HroPlYORbIPHLNZJyVA6KhDiUmvTIUBZsGaK2FNsVGl2bLS3hq
IvlQpVvavnrW91Or+FhE32Ab2Vw7jJJJmPg5ljtm0kR3+aGnAVAE+HvqWz0drqc0q29nk5jWccso
/TbfLOniS3sJqIpFnb1CHg75PGj2k1aGEbe4rkXTPIv4mRnGhiOCLO0xK+CylhXa5Lb/AFeEtnEo
oFIAJBJYzLgFmmOsxvD2i/6EOW8/Lu5c0sCOZGmruiRtSHOaOS4aArbx8yoyNxfJS9Yqc0Loy0g0
q7BOQkqvWbC5mCHedwjmse9PymOCPQRBU1rGtO+5Ps8O2rWV7Rl6do42S9xSsezdWqVxnMNaxNLv
r81nmCKrinlO+ZCaRnUHDgve2oi62cpc9gutbINXmdP8nFVCzUSNnDa6bxecaROMrlFKv7PRLLE3
l8zzVMh6zST6HnJB7KFbmelk4RvGL2UqI1ZNSKApHrfsg5QouoHFuVahdMA2e05o0cY9xDkeUy3l
CPm6y7tLjGFTd5OiLZIwFmk5dO0oSFcSaxUx2UmwM6Du5N1QEvExrgqJeQIV/Sss4csGGGpFJqnQ
sSQDldEbBDcXdG0dsJKgGcOZT3d9aC1SuRLnqmx05Xr+T5i+wriw1+FZPYKxy7GWj5Kt1RVaMqUc
avqysrBtImrNm66saYY8I+DSRWPWoR4VI4l84euOp6cyNLW/CcnkGVywzgnT2VslSI1GyRFdcAzr
DoDTj5+mvWGz91IxzNFSNdqJrOn7JsQxlXSBFLiqVhzRHX7hW3dgiMSkyVdtHt8ez2HkLTUbfR6v
qBjLRQ2kM5r0/fXd+q8RcZKPTt7uPaTaco3dte+OGzdRJFYxYaY43xJac8OhRotSpFBpWnOo5Jvm
n/EmY6uCmesgQLuLh4ym2FdqXHeL4F0afk4+w3yhVd44jWTVk4d1QzxN9YTsL7CNEvOyXfUIhhht
MQBeQAnIlyBmDk72ptCT/KRrJz8J+w5Mq/aAfV7H3q9U/HMdkRhkEFvXfIlSgohgM2D2qzcg1Lc7
NCqJHi2yMU5ko1s0kkBRbprv2SQLAo7QKp6Qm9WtAWy/kkiWRYdzJzkxj/ONwlIVhKvXU9PSLmXn
6ZkW0zyT113ySdwTSTlKq6kpKMLLqplWWBcxA4sexvKLvb7qPqmaYOo3TJV9f4vz2yotQyvH1Lt6
PDtXSzfA1fybBulI+JmcfTUzVXkLQXzwrNp6nOjtPEfVuH7yREDf8b2u2ZzpNdqdCuci2xtpeHJ9
Ut6dYlWdgyNTDQFeyXMJzjuTRaW68puJWTknOTISYcS8ggzduFZcxG6pyXX0apSQf4my2dnQwYpY
VfEQXEm6pmDY0OIUf0UKoJlQ03Eacd7zqRxrYfSBSlPrFoxUhnx9Q6zJT0XRLTWmhVo6oTKx1E7T
G4vsgR6q9HI3USVTkEKGEGdsdM5HBEzENsLlgyBlAkHN0SZl7G2glrjIzlrrzgG/cJK+pSc8K7+w
SLQhXUzYYkAEW0laFHz1IAEfDg2Ha7SuqMbC5k9IMZRsfZS0r461u2Zixm0crSVWyZR4exyc9DpX
Zu0hrFCRk9VK3BCL1R4VZSLeyHUywn4FfGrbGlAyDqpreSJRTIeiaj32/UtmwfPl7PIWi0O7FMQG
O7pheLPJFMxyeaplmH81bVGsdApUqfk2y1gKM8yrtqyrzdI8Vtnfkk6kigILOwYsZCoLs7F2ELCa
QETI945lOsvznRwtxjIalV8Y5YjMRxOQn+K37OLcZudUqsJPK8qzjHsnLQAX2eboLzPhMUtPOiqL
uJOSboHIoU5wEpgAd1UxBcTCcoGT/VlEQAxuv7IeZtuvlv8AjxdN6KVN0+iNbUUs77pUprTDb4g6
stLItGHrI8JzwcV2bmbTR70JPbbud+1UJuZPmL502ORAztwJSpGBH6olMAgP2CHn5+7p7uM6+wjC
h3ZcOMpRvBDgsyewJEaMQz00sSGoJvH8pJcBxPNi0nFlalgsY14lPCT3raE2rYQjQ7qLXxd8xPGm
dd4D877v3VNRTuHNt2RDn5eQphBpFbqFEgHFJQR/2cCmA3bb8m3ZBuIqb9onty779oT94u/00420
xaZ77o1xjla7YvodWZ5B0jZanLLfosrGqhBZTxLZ63WaNJNJcHYvoqXuzmZfNHENEJrvLK5buG04
g2WRUIEN5L0W4hiNGN7fxhqlkTLFHxthrJ1NyPTIquQ0FbWlrGeDJzaONESDuZyH6neFxwzPrCg0
GE72z8RBsDhLmYi9Fx0ER03pF5iOAERCEjtBJDh6NPRLGhFiIvaEOzHiZe6dPPdaqeZvWmd7ESRY
PTZYIGYdNTJw8uvnqyTKUdIEMQh5Z1AydaRiphQh1EymYTS7YwGUIAk3MXdn5P1AZXy7dmWRslWp
5Zr638PVb2hywiYqZTaMC88er4lXFmDQHsIQAO0KBudMntFAoDvxeDrS024PomHNUljxHivHYUik
sdJ8Vh/IcbFll3UlVshMLEpaJRG4tHC5bTI+Lw7GPcmfchiP3CDRQxXCqSZtVr1wTpiolS1Hw+Nt
PL+NiKSyw3IYizZXndJp1URPYo0CLso2yK21SbzUvZ1N05FCNgnKkcbooUghtx0RERTYV7Ehpoo7
IVMnUKBGoBrSwoEQEzJNBMV7IEqbsu61Mtg1PZnuooDO3aVcqNriTIzBdmyrUEvFXpfxDt7pF+DR
rA0dfDCgw8Utlb7lM2rwOD9b5KXCMrPfpgyLqt1rWOrEh85ZG1FusWZXdM5R3XLNPWKtU+/wEWMe
rNx9ai1UGkIaJN4vFTDs0e0VjyyUnHmfwlhUetu1CFJdqVcFRVSeAQN1UiqEIdYPiyAB3VDoH6sD
fdxef6b99ML6oYGqoN5yAp8hSMeSMQwsdmfSlBTnl41lAryMRDLOncBWG1fZMIOHnWUE1XKshHGm
3ZSppCqUEJUe8ECPGUQCCJOygUtWhLkvLN50b2SDG2WGofEKuwNO5vHhar6yX/TyeHcK47wdbqbc
002zutXBXOc7a0IF2WRA5pzwt3WIhWX2TEDi0JJKbFEDCUAHcdE/zVcbo1r9Quc0VpRIm2pWY0VV
qVTquyYT01JsPFp1hB1BvUG0jYnHq+QRWnHD5obmPvNju89ZbWdYWmrDuPoSguY2nlinWOdUpsY5
Wm2dXJQa7bMeSXqj4BPmQZ3WccuKxNerFp8IyDMy7NzI/nncwWBFYSQ3rI0z0jEmOb3KVjHB65NV
vWFmOqP5JqWWQOljGSiWD7FzYjaVlJQwQ0q9qltb16dEAZSzhN8jHOHCjdwUmjHRfIYHs8XCCfdO
XVDjyLs1NWsvdjBUTjSU8Z1b6zppaP8A0geoe2ZrypZrrX6pl/G+FMszjfJtTqGQcfVrGhJawN2U
TEzNmaIVhVzE39CPQRYmQskm7mZkhbW7MLcO+uhtIpZNz3mfJ1fxZXskzsg/ruMYJxEYnjggYers
YWtOVItBZOnvIyKjEjoEWgWiJzrHUTIqommYQMYoDZPrfdzimhP0S05Y2ck9XaUDN6TxvPnlHSK6
EXZsWNIZs9I9eNXzw8hHIrO2CZxMd20RUXblOkmY4Pn0wMaW6QulvJmP6LQYvG8fpzxzGr2ugIQ8
WxCdnST8k9oUUROd8OWiKw6gXCJaxX41+FZVsq5LE5QNYoIFs+Ii8I2yYd5iK2OIAskAFBSljMEE
uWAHumZZ7ShKYfZhAd+reXlV7VT2XUZlDJbyxt8pXKx3SFyBeK5kXIEMLhnHOLnPxaTdk2fJGHlO
xBWMm3saioUAA6qKzcphOmcoSfcpfFtHhIexU3T1nTDdufljpTG2Q57Ktwad2VI4byMFL1tN1TIR
SaXGPdtH6CsRLR/aM3TZ0mYUF0lDz1e0NAsfjvQm5xfLys3b2NmfPdScdcagxULNRBLzBlL+UuJG
wSkO2B5UmNgblrNcYzkFNVqVloyfcsZSXie0s6zGtiWAwx6QZPNMTlWYu5FoVatu9QsgxumMrHbJ
ayWeexYTSI6Ss9gm4+MQoLMW05LxSbCZQZKV1dZoVF2yFfQTDHsYvAin2wkJERglfaCXA00LNhLi
U7dFC0TQ6XAds2IfdP7nO3zzXrUbk3JMQ8hbzZAmYdefk7a5Zrxdfjm6VgniLKy8sxCtxrAkE/ta
bdc+QBr/AHBS1kQWPYAlSpnEJDy/mrVzOo3tTNz/ACo1JmaZpT+9lv1XfwLa9y+PYuWZUeQdGeMG
ZJVxX4+ZeumsXDCopJtW666SaiSRzFsT1OaQMO41p2WpnDFFJe8lWuTxfE5BxWtaW9jkNAbm4NUn
jNOckIaddFuspbrU2bw6VocFlYajIQSLebVQNOJlWZWpJhnHFuObri0qWcswLYizHVrRrPzbldOT
mahN39KdI0xdWsTSt1mpi4p1GEBpZHcjaYtmaTvcwrXpqwN28I3q5pHk3XGQb3HUDiaYALYkuQFM
TQEMwJwkEggiu2giqNHrXqVPjPR62AS2WPVLXa1jaPtNZyVTKthJds4xi/DGi9CGgyL2XF60ewtt
NWoaVjpF1J/nbcslJlVXnvoEgO69jhPJ6zdS1gC1EfZdsjE10lYuzX15AJtKpYr/AGKEdLJ1iWu9
ipIQUndk45w2cS4L2x6qRNo3WdcwIpKKFtd1LYetGqLGmrfPTmK1B4NyzXs9UWvL6f77kB7aKbk+
y5MeEaRlIx/HSy1WhX1jYvBCTiJCLWsDFVvsu2IZL2uA9CsYa0hOkcG5breJsp53t2SaY8yjc3Kq
V2xngPGJJeuPH1LhlpNg1Yp5mWew0g/ypdIpg5ianT3kJVomes8oxk0+B7GJEvkYG+LCYoSFHqnZ
kpSrCCJFnTXQG0Q4sJXuMzUcOeoM/Ce+w2XvOeprIFbst1uzyzyteyL4A1ul+c49jGrTIoV0D1mD
hrpk6Kr7KQyEu0cpnZuYGZuM9DSblNRv3o6hDEDqZ1j6mbTHz0BL5bsSkTOYtjsGOoOOJBxcKTFs
YMwWFrDesModlAMWsUMtIBGrBHEmd2rkETj2KoE+iPOiFVRyNrFetW+TVtPbLRzk+xVxu6mGK2i4
MZOsMwENp2jsUwTWwmrrbIJctL5AfVKKZ1iMawL0rFOsu450KYABbzR9gt/gSx6jSYmstWy1H6UJ
C2E0XNLIyj30AczeYipLVg4CQu5L2bGjZiKdrZYyViizo2KMf2EgDB3CGVXrEu0RaEw0x4mEhKnI
ALqqlpNhZyZA4hRxayI8EllwgC9Q+WGc/r9mtX4zh8JjRwuKWj3PKsYWNRWSv6WX7oeqnmHDQGSF
jTly0wYo0Us9/NEkwdd3VdfQEEyvscNWnZP1MV3CV/xrS/XF1gCySozOQUo6lozdRVftGcDIvFpa
dSgZzwfwSPYQz5MzufR7sykGDkwkQdoKKWlaTEM1sMX6t6pnFPPqd0//AE+8zy1UlsnW+Zs+GG+K
30KC9SjaZV15F0yibM6R6UyZcWDaDnAFq6he97J8E2gbAqd60NeoieZm9Ge4FxTO39tiRtXmGiZ5
TIiYyJJaxn+pxJ1KsEJqyPKWvFR+VU7HCqubUkzrwSpX5XDTmevN3hpiBSYqgyUyQAUgsTNt6AJO
2J5AG1BEhO81CVQ2aTxz+zW+eSVz1fH9ErOLZaxD+T2qSS81W64nFQCDKDdPTsE5GVKt4aWQcOpo
9bSI9U8WEyhg2OImDbg1NI2u2BxPOtWWYD3qyYygMf5Yq1WrlXgaXa5iIk8mVmSqztNi7u9mi3sB
HCjPO5dQIaVXYnfg6A8EI+IBZa07+u3Vu92VhXCCsG6ttpXgyxZSMkE4NaSmTxCKR3IgmZMhFUjp
iQRIYipDlESnKIsMqqrcSmK4IKhlziUgKF5jAQwkPyhvzCBDhyHENwKbcBEB6cZF26WXB9oTHUVC
8ODN8ILU1DNUa52JfYCVAbMtSQFCWY67nOY0FitkNUeXmONLLhGByJYEMQWGaWnXtMWhoQrOYkCq
so2PkXPeDSkk0fN2rCDVETypTkSjjqDsRERCMovUFmKj0qUxzE3F2fH8tbUMguqLPRlZt9QVvTNv
GNk7SEDdoyeiBt4xMC2YFtoMRlROciXiXMcoDDSj10oruY6YB8RMUA8/d12+3f7x+PmUVB60TTbl
HtSEUVOZUBASpok7RU5tw9kiSf0ihh2AhA5zCBevBo19hRliJtilQoAAQOzR+ZyZ5Cg3OLCA/SSv
ieGnfxk+dpkaao84kkrs/f5Hss25yEeIVvYWUIW6xtn9W5IVK68mYe2M5OPkHsWT24EGDNkpUyhz
Mgeh149SepHNE9kuv5hmMn3GQyjVzxKtcuQzCJJyuerW/gzesrCiDGKryHMfkq0bFs40OZTaO6vP
WYcEmavbB9OTqUx/rB1IQPpDAG/UhOvMYOhf2h324cCSaQcpBAATAAFE3QF1QHyFMo+0oA+QCXmD
4deEUR7ys/8AFoE5dbg3i0uGc7SUoPuDu/2+nnYjS6nsylsR7d+UKbTnfVucpQKxqMNHR41GwGlj
WimPokhSVqap1rNYpA0jCjXlIidHxwbcxlhfxg8bGO1KZPYvMeO2ltVj/wAkc76z40iIiMgI6pUS
wd4QdetVVocDGsqhDWDxZBB94u0hHVu5YaJVGQ5eyHgYez6IB/ZGESFP+wJi9TFKbqUTB7ygIiHy
3427BEnZJuBEAKryAkcTABVBP9QCG8j8/wCwBd+b3b8Me2XnZ4toSuhTqA0nMyzvQ1Opdcj9XZ7O
Tu8/ly7vMjI2JeIzJke45fbZRXtsg6ya4ucZcfXpsZvEzprqxcd5jLUEtCCxeDbm0tu+G2g38VIX
6TxLYN+L8cJap22K8fW+byLLnbW6+lXstkXkIxpXnmRF3kMMku7sUsyJFnuL+TciKLYLKdZRwrum
kBzjtx808O7LHiDlA5UHDNZuoQUhKBhVL9YgAA784e8odS7dQDy4tQ0va9YTHMUtVMwVqZyBWxep
oNowpo6WVbMVI7s5BNu2skpIw2yBw5GAEaDzG9lMRHYOC9EdIIg33aRVlpdUiXVIIrTCTLIGYNlr
1dzE7JJYESEqAfcWEjULmFxkS92qcjDyJo+anHM3FQp3BXTBkQxecJBsyK6PHC5EntAchNxL7W+3
XiNiaoc9VtjXWsPkG3QydEjpdjQJNgeNLcaMysZFi2WNpt3eFG1UlnNkcOomWLVbOkSajFp0JYJN
KTbjZ7nsj6b8fajMJzuYMYU+Ip9nnXZZBGOYuETtnDhSY8OIxbkSEe6tTtPpilIHKZL6QNye1xRF
kCrTNcmJCDsLJGJfxrjsjlOfkTUT5e05gBTl3IJPb5g6cvtb7deL9IrvAjR4sOMvZRzNQydiGaoA
yInrO0XUJMDCtISvTgAOMpaZDisidWGfarE1uCqWXcmViHqtiPc61FVayOK8zgrccOV/a0EI2SYR
81ZHRehZ20tnEodLYAfiy/1Z4x1TVfmKnZEf5WgLOWKyRLOZZ8/vbCp0E9qBxYop9BWWRjZZ/Wmy
9VWskHIzzS3x1fdxpraMmYk2SWFZ0FngZ4QEuoCiIdkBd+cu3MbflLvv9YfcHmPuAfMdZ2oB2qxg
SAB/sxMXmEfkXzHp1Dpxlxr7eCMK1mIHY4uKQ/4nZlCEoyB0yamnDjYyoDPmRYesZFjoCx9wqmQm
7B1kCkkgairQ7U8jj8zRew4yBmOOHANFP0tFmZRmx5T9SIqbcRrL6jsxScu4m1r/AGdrMuKQbG4P
Yp2zr6jKhNU48qVErIwgx8HSaackChEkgq03jIg8WaR2jxSn3vrY0ypwydNSe+NIDKunJmjaGQYr
nkm7dr0SWdvSB3eLSP8AsKMgsCZumxh68RS5OcTcwGES/wC7Adzf8oDvt5jxqe0xNkEJiYQJuJ1C
eMpctbNhwiokxptOe4JzNGl+LP8Aq1+s1HsUfaKfMTVXsUI7byEXM1t+9hZdF+LeaaisV40mVlQF
CJVSYvTAP6SMoRMwnE5SjL9n1eZ5t8fKw1hvjqVhLHZG1ttNfSjK9D1y6WxidY0bPZKhGEIlFZNl
GykKwlhnLszsCxJRwgIsQUVT5hYWciQAIRUplB6gYpgH7eoDsPv/AK24xiuIBuOwB8READ8duM1F
8vCIceHtCRHIJJ91moKEy7rMS2W0CQ+mVB6czcnZPVZnewJWqLnskT8vA3GKb1+11uR7lKUeTh4c
/NXGyVGWBCpxziJUDxWvSETWEvVKT6w5olTcONxN6zs4TUv6zzcvVJa3kqzSkpXOSxjjRxcTVqMg
fVJvCJWxSujZGSTKpf6qxz/xcpTV39WcZb2uBD7wYoLiRQDe/wBkQN8fgI/ZwjUXMC4lMbtCdPaK
ICH/ADBuHv8Aj/jwVXSN6W2KISwYP3fVp/idFwAuqiKUA5zNirpurzNVGqVbo1dtKKtXp0u6sVGh
5yAq1nJRLC/OJpOx0Re4xVnDHllcn/S3jdTFCUPKf+eFTygW85BtuRrNMXS7WGx2+2S6gryNnts3
J2KyvznbxjUAWnJOSfyhhj4mBasWO70djHTSTDmMUBYZnG/1RBP47jy/z/rz+7Fzm+P8A/y4XiXi
NGlFiFafhNMueZiRDCKEmte70soAQEyBwEBIIdCAO4/8vn/nv14xrFMYElFATA4IbCCIgYQHp0EC
77D8hDfp5BvxjFcqe/KG/ZfU2AB3+z4/dv8Adxh5z7b8/T48xdvx34SWceTTy7vSx9odBzyeRP0H
QAKO/OAdT7bh9m/l/HjnHYiADsIgA/Aeg/gPHOItOzGp55PImX6gg3W5TiBDb+Rtij+A7D8xENh4
wpAr2xh3S2U/VDzF2S9/tbD7O3z/AIhxhWKodTlTHmN/vFehfL94dg/x/jx0Qpg33MBeu3Uduu3l
7W3X5D93Xj1ChjImUkkBwZ5P4tzmvBRvq4puB+1pyy9QK3Tq5iqRgn0pLvrfi+tZHlZCccN1UEXs
sq6RcNa4k1HlZtCLMXqRxfewVRm6IOxm6oEHJZcwb7qAHZB7ACIBzdPMAEdh8/d/14n+1ZTcXDF+
PKSvUYg8jiyGf1htfEJKcUmHMRI2OTsHhr8pJIY4ijCWn3KLBBSLA/hJDqplFEpjBAChDl+uBD/Y
IGEf6+Pl/Hil+XdxeGUkgMBvJASB4g8XtEBVeqGEwPDRqz5qqReqFETHNzk3+oA7j0+Xn8Pt9/B1
1jTdX7XpTb50ib2EjbSZpicO2CjrxLhpXasxtJxTgJd/OiUs5YVJ0/sSCkakcI83svhsBvMBEQHf
yHzH3fLg08c6kD0PTtkXT2hjyIk47JNhr9ulLcvbLQlIxFjqEimpXHMNAi/CPFRFNVI8kKKwmQIq
mZblKcoiz0Wno5EUQ4sMpEphZMiBPwcz3Taw70AsTEy2/mlazsR2oLQBK4iomRbOS0TL99iUtWLb
3VkiG0XAXlrYpiGx85nsTPGEzMTT6uQ9xSVq7+EvSNYkmbJNSUcAmCZjACmNYfH8jIPYy+flJcuX
gsI6iQeLY6vSLiXtcxNhW3cc7LLz4eEiEZ9JFt46IsSi0x9AiQzj2eCQvutK8X/HN0o83EMnthyM
0oMLku8PJ6clJewMMcvTTlXhYurSkqjXqgDpYh5eRewsar4tJlMInUUKO0O4u1AJYqzVjPNdXxtU
VHWNGMC3LVJeRfNYmySMTS/VuUmpaVZprv2TmakB9ZVVVm5DRj/6Y4pm9rh9cO4J6RC0QipDVUpQ
0m1JzPLWRgoiou4RESlKiXwgklpHPRvpWtjHvno6ZGHj8+z2NrVN5ThMaWql44pUFCpQZ7o+t81j
+v3C0N7yo7Vh65W4GoKyknCBD1Be0TLmQZvGShO8N1kyDnKaO7XA6e6bmIInIsvcMiEvMqEbGxMH
G1qr1agXZaoWItiO6mwvb+5MpVs5fSKLSrBUWdebrPXLxJoidQuyw/rcsuIyXpg+qkHd63eMvVPN
wxriwzcW5icgVKWQsDBzAz7QJyWIyBu6asV2T9AV5WGcIKhNqN1kzGfL/wBI5dZt3Ezs9jCkS13r
jrOPqhYkX8wwgopXUc3u0TYGDiqgmUbM1jQtNgloEJh8gC0m2jhbAZVRx6zkvCeh8BKUxEKJ7Adm
YPU9+bjxsRo0OaEJU7VJzajS4a7ma0Rjp/xuTTq1ze5u2S66kS1VqnV5jYqtVWiGQHaW7HJoYoYx
t6UlVYSlsiiLWcnpOFarzYd3UXBx7AbnIOmXEVHxviXOLi+ZabY1yFO2aDXrz6l1I2YGbFow7vWp
6GjIOxOKXHVy4OA7BSEkbAEkgt9E4Cxn9nhi2XUZj63UqJqklhiKd2KrY2rtHqDhxkGwL0yjpR1l
TnbhbK3jaMTi63C2LJTwky4vx2zx0uq5npSYD1huM8ylrSQFD9IRX8ftKnVq7pnoRKZA5SdZlnKF
NWVSXhl7Wjj71FaI1PxmImXNLh2LkwWdVcgz1jSeCC53xRHm4Xh3fohY2ZMQJHvu6jR6ynnvlOx2
j/AnxO71PlobDjesFUmi5romNbTO5Lg4a2MqMvamk9C10cl0N1kFJGRgoqbrRZ5OrzD+ObOW1lmG
bSeBw0gl0Y5wmnelSRho21b4Hb6c88ZJww3nVrSzoEkyZJTjiLYwq81EO4NrLqPFUI9VYzVwVV8y
AxhKGwvGoCO66QnkbL2ecb5PmqfOfkqscLIQ05Nz+Q7K5zJO3W+ZSfy84eWhiT1utTV0RoxrIycR
EtlGEKRNvGxxw3KkkblYmrLPpNTOZL1mJvVUqUlbVa2iECzmH0+hDrVWkRNARSUsDhKGeLqSMfCs
px6Q8KJxeLIKGDmVII53SMO4Ku4wQtm0nSo1GHVxUeXdY0Ba/iLjPgU+lhiSECLLchUx38gAQERH
7h8/j5+/g5pHS3W4nRjR9Ury7Tz6zXbIdjorLH6FfhQiq6Nedd9VXkbKWw965HrLd2kZeFKCzb84
JzJe3wC4mKQOcpdze4ADc34BuPu4N6u6rYJrowl9JlipLiSco5WPlWpXBhYgZo15Y0anHyEYWtSU
LKAu3dM1UlylCbEp0FU1epDlMKVxMJHt4ixFgSDJAaTSyr9LN3ip4H6CzMW02ZEhqNim8zbytw62
arGvXsY47kHMipfpuDcLdgTJb6FhUnCaVAcL/Qwb8JQZl4rum0rihw5eCQl9CUm11R0rShXsgLzu
RZu6qUKfVlqXYoFtVJGKHuMlMxxUX0yMtTVmP5xUXyZVLW5bh21lbU8ntcD6XUXI2HF0bjTIkE2s
MrRpCouce5URGOZ5Jp1RgwSZI46JYFnEm9kqNHslkT0+DmHrSPrU0qkhGvn7hQhBmSc1ZVWV1nVX
UxDVS7QsPEXeqZAnqm2s7B5YZpzV2HYOmqs6SMMybM5lfZF4ZzGyxDq7JGHn6cbMP+Ff0UmISB2y
RPqgGREtR5hg4v1G/lpyzPyv988jvs/KDoJlcl6pr1pkpeRvElcZw2QJi22p5T55rZo1jjZdJpZa
7G00X4LPLg5cuG7aNVJaTVtZddFFK1CoqUpmPifSWXL13zNXIu22NpXcOY8mchTM6wx/JTtvkYKK
t1epr6OXpKslDmYSrQltazNibKyia7ZjDundYJcEGyqicj4W1wVDG2uO/aqndPuwVa3zWWrEzx9C
2iGYS6bTI8kZ+Zm7mnUYVg8j2T15IILnGMMkkunBonMVRw2Kdm6cNUdBw3krUrY5+rXiWo2acQ5T
xVGxMC/iY+wwqF3utOtDCTtUy4cA2knMOwpj9k5M0Nu2PJpJqiQVybhdG2BSCDJkByGcPN3prmK5
CkNN4RVWKYM5fDXVvNjZn4y0qhf2WaLi3yMhAY8w/O1+qSOQI+pW6TjpiQt0jNIVeZft2bKOmWNJ
aRdc79JP3jaUsKDKwRrpWslQkGp1dvVNI0hO4Ds2pObyNWa3SYrI58URHfqzbpVe1WiPirTJIyb2
RatRjYyNlIuuoxlacuTyqLyyCWPsx6g9+h41OFs/Vuh4y1M48sR8hOAzJA1uLqjCvSzBpX46xVu2
BOtn1qar/nEsYyRgjyGZbiaHEDgIoCA8bSvaiawx0h3XTlLflCXsMtnOvZhr0kk8hz0KBYsKk+rS
kWCITo2JwtIsrKedbog2E7h4YFUynEwG4YMO4qHVhEuQ7rVqgGlCztk+os0BT9VWWQ+T05k+Wb0b
WqpaZaTqWs98g4ev5NeWJvUqyaKs6jh34I/PEKMHc2o3CKaXWUBJWcr7IY4K9IME1HzOzLNyGUDH
lbSBYsMYowvlGy3aBB7nOh1nItSqrCAl0UUq5dm/e4kfXV6UCGk4tp+c3OqlhxYMW+y9dstuT3Hh
9XbVXUbRoVxJpgVLkR9eMY5TtFvNPTikS7pLeuT0bKkNUq2i3nBnmJ2B3zQse4fQIG5nbcqf+0Jc
2x1NaqaBnHTTpQxFBflJZXvA1CPRrK9sCcW3pUg2COBYw1IY2Zm590EZIFK3Z+sUG25YcAULsgHN
xVEC4JKf0B2+s61SSGYhncks4cMHm4YyRHg9llCUzQzS58Ada77RrkTSDY8dQeTppW1M5d3iqeoc
NYATh3bGCuT6+R60tHqYesUpOSal0jgimziTTWnYevInj0FnhDGbpHUKvzTopmsDQ+Cp+3ZMxQ5r
eoWkR99a2iuJWmWgqxEPlwdChaXUDEv5CySAsv0X2VchjKi4+gABU9jiX8mau8cXag36stmmR15C
80jDtajMb2BjBNcVYym8cJoJ2Kcx8jG3abeNHb1FjJREWpX6zXjuIeVQKiJo5wnWjPO3ardNGQ8V
6IceXOrZXnyacJJZvlJq/rdQbxVxqEjIp2KZiKg+gssLzxhI2OnGN0ZtvXxl11CIT4MVDgUT367d
FJiJiXOPGLkYgeFQxlMZybN2eYYirXtChOXVctUd4/Bo1ogpugy03OP05v4fKdFjo/UzcJyj43aW
KFsVenkG0D493O1qVkTSr0+OpoA3jpsswaYfB/s1dVAeIEu2n+Vx1kvIOK8rWKOoD+gmsiS7+ZrN
rk2FxkIV8vERsbW4mPhSTh3VsAXs5VrPNFgIOIjxnHz1Xu7+MV4K19qc0+s840POsFMaiJaepWoZ
hZIGnTkHj+LoNE04V7xlaCxxjaKi8hTJo2TrEMqlEQMSUkPXUYdRODdRtdmzkIMn6p9cOnjO77Ca
7bGl2sbal52ueQ8gT1+rVCbWKy4jtWSZuVZ4t7nF5Ct3rN4RBqp1tjFP7lBVoHh02JI3tzlTGqkd
FKIO0ig1cZMxq83kJzLuM7FRDWt+omTMxrMPu+095cL8laRMo0dvh4YBNtlAM2YogMx0pjR2EnJT
MbS7SKQMm0xBOFhUiHSIrohs1VnxAVkgDcVCc0Eo1J5HePtLbY2lCmqw5LFHr0/FWB7aXsonNHQk
o5rCsIhMkc/YLkURes3p4Zy2WIdNZMhyiAHVA6rcTF1Cajsg2Or2+Wx7f8e5Lp2BIZ9X6bZ53Dic
xfq/NY1WYVudt69WrbOj1ZynW1Y+HsSoVky/q/BEdV5V09s7KzVnTG2T8x3DLdetObMXvpyj1dGK
l6VDVStS5cl+DQUJZAn0IHJMIonSJBSHm5EZmo2ZlYzyzzlGtCsflFYQ+j8Ij44pD9h2EyNS+U98
w1jIhRz24cNNGmTpV9DWX3dDdtEOUKHEWydst3ojKDqt4xljd3MMnVqVWk5vKdbmbNX5GOjI+I8Q
Z0tnWVUglG0mXtUZVQiK0IVU4FGOZ3Sbl+Gu2dscMQgLXa9PzhdK2wteev3y8jCxDljDS09QoaSO
Ry9rkWSTjQkUCIRyzIJBj3mFS7237QxLprVxvPxmTSUxjkih268f6Ojwcn16PhGltlLRiynrQl3f
WBVvd4CVVPkOVbOLUcze4ywyCrdaNtfibxI9iKzYzVjiWE1g5H1NjX8ojFKEnJ2h1aCkWVSkbLfH
KDBueNyy8rtzQTQx3M94sN0v9djZWwPn8okyieSwrS9nJMjvELoxjhXFhuxGHKSazId9C3FnJAIg
I6iXce8TN008T59wwaXdOFy1R5K/JNj61UWs2dzVrFY2aV3XsaMVPRtdhO9TLRqNdqVsTb8zYe8R
xZHcVEPpUuZP2uBqdAduuUDGAgrfWAw8oh7uu47h9vx4OrQzqVoenfVNX89ZKCxK1WIYXBvNw9Dr
UO6lJNS4wHg6DFJutP1GAbNGqfQ4A4ApPeHxBmVXQcu0DFMQ5R6AJDFMX6/Z7AJRHcef6MNh+uAF
2EenGXHF3F3uA2qyJVA3AC+A0H9J/wB+6zIRE274EksO+nPda3mLwZq31H4q0s4VPlHTx6ofkmyX
lTBuPm668RNV+nx60GFvVuk1XMfqwEE+k1gNJsYyz3RA87LAYJ1NmsAgFUhp6ZbGBEshIpNEkjsV
WqUg45SND/7eKHK8FgLR1v7EcUBKoO3KQeCHwVnlrinCeqrHiEkvDzWaq7Q6sRZpTo+yO5COqsjO
HsNfcW1e0Q7+oJLJzUGd82JD2QZMrPmUIcCgPAiqOzF7UTKAoAl5iiUwCAl/eLtzbh0+sHT59Q4t
fIsBQu0e7kjbM6HUEpIak5liHGrks7AcO7GJFwYEies/d+40zsdEjnnNNu0+T0IefxlXqC1tlGqk
/UatS4qnXnIsrGQM06q0pPFi6+3hbhG0hsomZ1PTk3HS682oRu/a2JyYC8CnIPre/h0jvz2hasqi
kVosslJ+r7kTfqwbmkVjM1hc/wDp/ZnMMdsIJ8vBKY5y/TWOjvNOFp6ZcltdpyxjK+UCNLGS60I0
ZVuLvQXNwov3sYyvnn/GIQFI6IRXNNiy2sRWXJ0s8uXpBtJtsYZYRJHWQMeWzRtW8GVXC7uiEVZU
zL0SI9nZW9VaOvyWQkFD7gJZqIsi9ykA2ArUwbbEWj2kj/WJRQHCQaYBN9xfOhYGdrFKoMXZCBDV
IGaiNPTISrJjalJ1fbksk7jHEdWiJukypvkRw7i5su4UOj25CEcmpRXDJQ6H0xCjLFMdIOcA5Njc
NKXkbRYBbyVgkLBIgmiDWLey7+Seo90MTnBBhKShjpLCKftgRFUwiT2thL14tg1da7qvdcMYlxni
CegbcMxgysU7Ua1uWNnMuWZyfWFCu22QmsndotF89tMkxAWDu6xCoyZlR7E0oJvZ4dGszXfSs3J5
TiMTzWMIvC1thcdJ0fE0tgAVMgwS0PHCWQFKUcNmtQxelHKCJAtOOrTMTUgPsFbG2AoEMBBN4wx4
Y2AUxK0zwqSASBi7aSVpbIAEJxdW/wDqRF2uyS+gJanju891qhpO03iTZnaSU1ZHyTxJqYzJzISZ
iPe7qyyEUk/JInHZsRabepQsscOycKoLkaqnOmcATS9vuk2Cracn5uSQdMoxZdpLyj94mq0iu9eC
AJVVDBIqkGUmezlC84D4olyqfnBOf6ZckekL0I5Bks+oT68RPxWTK7m6GZKTuE+9uJlI9YxQhgyP
kuatO++lrNkbZN9UpB4R2NWdTNiShFYxWVRJYwF1rahNO2YsSXmm45s1RULVsp1u54KQUq2Qy5Ci
8cTFUlo++VSctVrTFFlbCSjeAezEfDS7KpSJJeKUbubGD9oKw0XS8G7iMq/MspcIKklNQJqyLMcM
zhq1LBN7hZXSIJ/Ca9V6ZZ92dqipS62qVYxcHLWOcnouERFCEjJSadumMUkqRwo8aQbJSbMDJV4S
EZHTSRKVRUiyJiFEpyboHttnZSOYQT2ZknMRGD+jIt3LvH8TG/OPaCqdL70g/nx9HnpOpXBeL4HP
WOZeIqxrxnKg6ZrphavwlEFMlKmo2PvKeY7aIPGzWMowXQ8xBksT2pOX87cTMwJMspcxRDihiQ07
6h6zGPZqWwjlqCh4lqo/eyslSba2jGTJLqq8dP3XZtWzVL+0cqqkRJ5mOHQOEjd7yFxwmItUO8BJ
xKGEgMkuAZguWYgF33WYgLET+YAg6Jm1M6aaeVoYSWVUMIJrFIvymN2XMAKcpOTmMJN+bYvOTmHb
YOcu+3OG7nmsgW+wN4iOmLbZJxpXjIGhWEjYXkkSFdN0e5JOIFM06p4SDGM/R0eePBmArfQJiJ/Y
4+jD0oBNN+K3upbGUpEU9la8rR+l264np9BqrNOUxulGGnwzPaU3rqFhISnoZGCTiBmn9Sdv5u99
wN4qymRSMUolay8paZL7jSQicc2DFk+egZ/jbdj1pWwuUzbLLgiwRBGDmmvJbIK0oo5nWMnXe+3+
sNpWLijksEcodeeCQbiqS73WNFYLvgQkkScGRCSSQ7iZZpHEKBM7UiRFLrDFau+nLtxpam9nkK7t
3E2MXc7GK9lOzGxEjrI877Y3RXvi3by67meMpJAsv7LIynOEYboTkN04Wz+acsXSJewFpybkS4wU
is3fykRO5AnpiHkuyeqO271ODfyD+O740apKuY3xVkY50E1Fkt0yHMF2euyKoSuGcxZBpcpWbDAS
WuSMi42LgmMjHy9Sx6FQNKR+OpmGsMdV5elwMYumoSMo7VEEoZQhyy6yYlEAj/XrnLENihs7R2K2
+jCYx/fLjU3WL/AC3SezXUqzFqTjw8nRY+aau6Nhx5FMBCPt8dBvK4acVN2LFPn9kGLxd1p22K8x
V7JIKXCAXGCSpuFTNHoaFno6f7KfH/H04DutURJ5iy5Ym8YhP5GyFYU4SVSeQxJy5TMoMZKE/wDD
5GICQlnwxUunv+aSTHuSsTv7J0+uzHM5fSLlV6tJLO5NY6z0y6ckD54s4Aonk3bl27UUO/TXIUxx
UExyiUBETCAb8SU1xPk9quCrzH99gWiZjKLS9ipVhi4aGaR6He30xNSL+OQZx0eya/nDt88VRbtm
4issqRP2uLj9d2f9OMLZW+LsQ0vSrecaZWwLhqNu+TqJQatI2fHOVYaXvTG+3mhyFeg2rNre3jFj
DuHMvJKy84CEgwWO8Kk6bicUO53gkFV4iJLPiAS4IwMGJmSCZ7puSLXRs0f00mmZ3cdO6XfTIOTc
juq01op79blqZGCzdMagvbJ1xXI97FvZyWbuYyvjLjGRarJcxSx02ixdmMYQKkyEw7D07ydkWZm3
thf5AtU3b3kQeFeTslZp2VmHEBItEYYK25kVpVCSCunTXQAsWZ32Bu2S2IPaEAb2dTzj0eo6Ocu4
qwNPYcsF4qMria9Ydv7uTGby9ZaWrWa9G2iNWnZ9VlLxtvbSsZMupLGFfds4xp39Iy9fTFYRHeNb
fojlMd29m/d6eXD5z6JuEM1aIwNIaSptWqT+/HWdMhAoLq5jTAKsc7xLnuBCJNjGXKVRPdmHAWhv
9XidQSHwkmSTjrJOXWmDIgGQqspVSChMsidQ43HmbWoiDMWYTVdWjK5Vv61MUi20UpUFLnbvVgtf
A5CDDqV41l8DexIHUIQYrYyYHOQop7mKAoo/KeR6/W5SkQmQ7XCVOwNpEJ2nxFzsMLAzMLLNRhnn
isU3kF42YYuSAILsHrN6nM7CIFV2Hj6Z8v420nXbSZrGzhgnH2DHULBaU8Cs6GNapVcibtji0TMn
YVMgPiMn9e9ZqPKWZOUhjztkWjxtlwKwOZ5JtQRMPAzZWsmlV1i6AncG4z0aOq8hoUeRVxkMkW2P
qNmRzktG3yJsakXh6GgJ2bsOe1JmMi3FZu8mghPPDvWYsrSqLlDtKm6xom3BvMUbKUkpYMhK/wBR
yCHcAAZsXYlhmNAH9MZDPVIccOcm+fBVJY5iAfkKZQQAgCIbnE31QIAjuYTD9UA33HyAfcQuLdJG
asvU1TIVIjYZ3FPrXJ46hGzyy12vT91u1fgG8/J0yiw8nY0nlleHr7pq3OSEQfOizTlu2Mn3hZMh
yX0+ah9JNC0kZ9xRlrTsjkDOWRHEYGM8lixgXZIkxOm3rdJPELLQBYfCpMnw2nysPdODs0rZlw2p
QtHtte0rBdij9PjWCx3epfK9yZ1fI+FX2Ps1r5znsv4mpy8ivIWyPtVWkY+v1aYgHHrOW6xjuGe1
xRmjINLFW63CEp9rEhrLsHWkP1Ap3KgwfqklmUAGYgm4UqRKQaGvBudDuNvnafRr5k4XaPG52btq
5XZuWrlI6Dhs7aqkQctV0FSlVSct11UkXDc5SqoqqETUKUxylGW8QYHyznV9Y4rFFFkbs7p1TsN/
tJY5FI8XBVSmRyk3Jzc3Iykym3ilDlRVhq+1fqNwsbxM7Rl3lchiBdk0zdouzDfMyZhzBScSycZm
fVTNWPTK6nWHg2XWFnTShWcatqhJBKSycbo4fyCKMjeYqQsVhtD5J3eVmWP+R4Y1jjzRgwy7Ts/6
m42xX/Ftbp0hijUdULZX8cZYodHwBcb7M4wmmtEa1Kks7ZWK3a67J2NchayqpVyoQThYqL4wKqAU
RfwxQClGJBZKQsuWcVIAeZDMRKoyU5jbL13V/wAfCnLF6rsOab8v5+ezEdjCqOrAhVq6ey2eYfu4
uIrFchmpzJkmZ6w2OcZxsQ5lTkORmxkXTYXZyHKgVQxRAJPR0I6qFbpk6gvsUzMFN4kiGkvkh/Zp
WLgafExUudQlak31rkpltR5WPnzpKkhXsfLd2lTJqFYKOBIYAsq0b2Okt9IWZ9I03C41suZarqRr
WZp3Fl4u8ZTaplig1ygV6uua9E5Min8jX5KYr1pipeZcJMpldk6K/IspM7KgYT0teZsUWnC2oXEe
N79j/MWXMY6RtPWCHeHJeyxLzEuS7fUbxdZa9v6/Lzj+uOcmtanDXZFtGyyNmjmT0rCe5YYSu47Z
m7XO4mGlaoGElaUEJWSADh65qwBlUgBlEhikBXjRkKPPOkno8+/6/L5l/A2SdP1ubUzKdYQq1jfQ
UHbI0e8RMg1mq/PnXTYz0DORK09GSUM/UauU2UoxVWZOjt1yoLqGSUArTq9Mn7xbK5RqrGBL3C2T
ERVoGDiOZnJzE7ZVCpQ8GVyqAopICochEHiZR7U5ykTEwiADdnr7puKcv6iKhPTuZqPFY9wPpR0+
s86QEHeI1zIwT2Nkbmaw4B06NIt1YWshkYGTpq/r1eczrqnHuDlCUu1uYRaqfNFmnTUNhq3avyIV
TGdNwNRrBhjKum7TtCx7KMamjsmX+qzcPju55IvBXC0gN8nJCQemteTzBKPohMIGIj0ka46ayJ6+
ywUxguJeEhDOlIKd2EEKAZRlVsOdDYe0XtNps0vKRJIyoWoP2fOuLLmC8tYRcwjLIVXNDoTYy7OK
koqXhp2tOXlfFIJ6CCer8/Y49WzQgroBLxJHBpKN7ZLvrdEVCc0Zw7SYkZWOh4pm9kpeQk0I5gwj
2y7x+9kHRwI1ZNGbcijhy7cHECINUEzrLHECpkMbYB+iG833FkNgjEWmiq6bcd4nzNk7WTj3IlWw
XkS2QmVcf+qNPrdapVjyRlC3TT+VioHHWQbVWbqlKA879PPK4Fls4NTtHTRyEW5Kwth6/wBdYReg
Os4bUYWrU9WKZlHMFksCc7bMG5EnJmCa1JDDUrYKxXbbA6YISdbDY2mSKowlMgyyzQYlJuoaHhE3
fRejYJvDiMiGNHBU0g4YlyS+Fnc0ew0RlocbJKnyJVu0H7eRcuiLGWo7AtoT/LfE2ah45YyKdbtC
SrmtzzaEmrDFqPK40sTeLsVgSrT11IJKtWLaS7ou6dJqIIJqKkMQIi9LFpatFYn1dQVMxpYGeK7S
5YEdZBbMYVpEnlZZkm0izOE4mdcyscwknSqTZgoogRN44UTRbioocpR2+oPHepPDmHsl07GkDJxm
A8U5Dp0bmTIEg9rVUyzrJy3Y7qxYsLHLhXrbK3W447hL+5i4WhRkVOS7tjVV67eHYjLtH7YzY9LX
l3KDm943xS9iJvH9NcaXsFx87ToW43RSt3JeOhoaxLsrPGyVjla5NNaLNJKM4NCRZvZtnIpKITHL
JlGxFcvKkpuoufVWCzRnGMdjCCksHOLJwAADOwzCG02gJHy5ZenLWqdZ6X8+2jHpcrVvF1omsd9n
a5BtZUk0lU37GlruGtjfVdsjKnmbE0rzpm7bTjmOgXSMSu1covzt1EFClGVwoJAIZQUSAoU50zHM
UoHKn2gHOQREAMUnZK8wl3KXs1OYfYNt9amB7PgaIyNpgzdN4ssX5IazhLHkhQdQpbSpBYcwVC41
pMjX9SMFO4sYTh2kVb77bivKvLQ76HVkr1IzzZ2wQtbh8sFq+YjUZZKrcc2ZdutCapRFIs+SLnY6
lHxcOwrAoQT2yzUvHn7igop3AzeFVSQ8M5CCBFE/YApy82b0j0fButb0klkq93tEhxItIhiHcVIZ
nLaN2yygCKgnDs0kdiE5g3MPwL7xEPgG48alycpVtkzkP039kxTfd7I/9Pt4zpKbo9Nh+/y6/L7v
w+/hIr7AcpRRMf8A3gGKIfiA/wAevTfceM3bqZm8Sd3oLdHhpaUgJMNxA9PCyMTGAHBR7MDpfUUE
ShuO/uHfr93CFVYwpAAAIiYPZDbcR93QNhEfP/t7s63mt8x6fPz8vjxhHkDfc5A7L6ntAG+37vUN
/wCPBMKfi5lz+xspE6kPZiYYz7hlbEYy49sCoELuPs9mIDv8+g9f5Dtx45ij5GAfvDj0sYig8omK
kIdfbMBB3+wwgP8AXx6jrV1BHl7X2ef6vZ9RNt0HlAPrB9m/8uKWvbtYQ2HqHkHv+A9ePIq7BuIm
APiPQPx347VOmG/kHn0/r+fn18uEhzGIls3KZQfP2wER93mHmP3e/b5hxTaJ15l68uHHsxqeeTyJ
q9w+IfiHHQLmFHYBSEfgBiiPn8N/P5efz4wgAjvsG+3nt12+3by49pnEN9yED8A+38fv+fArdsxq
eeTyJ5AOYgcpwFQ/vPtzAPn7w6fx/wCvOMIAZHzMCm/7o7/y/rz+PHOOsSxjmU5V+UyYlJ+8YNi/
Hbcen3+f8uMKvX6UB3L22/ZgPtbAHnyh12+YB8fkPGc5TLfsiO+3kAj8fh/Dbbb7uEvMX94PxDj1
ILEHQvZZAwUnx4NayFqdxdvRlrt4sqiamHtR67C0FRWOkYa1bay1cxhHqJXoM3DeJknrJkudVt2b
d48at1BKs4SIes90omcQ7PYu47h5Bv8AYIefw/6cTPj+hyl5quWLO1nm8dDYmp9etUvHrqyDheYb
S16gseNWkKxZH7Jd00fS8I7O/fSCpiFZcwnAC7hDbtNRLstiE6F5h/4S/vDt5F6/W32+zivSoRFF
3vAhpQqMwKQ5CSMEwTMznP8AYSE4IuzdxrQ5enLTQJJjuAc5dx8g3ABH4ht9v8fLrwfGkEJy6Quf
sVQdJhrUa4Yes82SfPUSWK0VuZpxYmxQbaMsbwAfVyt2BtTX0aEZDIrSrteUQQTBRRdMpgNTKUqy
ImMBQDYBEwgABzfVAdxAA393x93BJ6Ysc5B1BZgrGGMWXGLpNluCViM2sVssEhEQSaMDEzNhOl3+
FGVk5B6/brJRiEKWEOus4UI3IiZQ5SiLoqIn2nrw0rYt1iRRqtwe1o6BrRh5P681sbx3TcdHxHQX
t9UuDaqq4Qy9TrfHhBQ77D1QyLW0M2KyUnkyUlJZvaq7k15kKTochUF2EWVWSSeRMJHTCx3zNFas
nwHKGNYWlZejYpzV4GxrWSGo15TBk8Qklodp6rWxeF7+mZ8kVoT/AFfTM7bnBPbxURL+s4nDG+mH
M9yqrWRSulXpteuuYnmEoKJn7DaWx7rf2KJ7Cqixjq9B2KumaoTEVGMm0jZl25Zl67aNkjqrOEkz
DrcK5a6rbXON7s+9X3VPtK1ZfN7Cu7PDVN69e92l3z5Viabfsk417+kzK1lquWSQ/OBMZP2+N3pJ
YEO6xTdVwVRmfZgkCYmHHkfOyF3gxDExrvMKIPhKmFA7N99PCyxzWWtZyHK6dspt3NkyZiXShMOh
yXRklpu+W+7XSbgM6O5irKWF20cyk1HUK7JYurMhPMU7OtFR1gkYlhX0HceYsk480sYZUw9mykSB
7CS3y1905Omt8GnwMzmaFomd4+smUqszDyKqTmFr7O7zrtHITequoyUm2SSvrIMgUh9hJoWj/OmU
jqX7DuYcd5OeMMpNMPBZqVccjKOmsvJViRmXE4vLXGsQJXVTY0U9nZ2SzmWFV22ZuDR9bKlIxBhh
asM8qucn3o1czmZm+qsDZpq7Zji7XkuJrbCvUGPRgV3Sk82il7surJKt4Cn1hRSpgVurLRbZmYa+
/aSCzse8QErC19GjsjqpxEEskO5Hq/CxUXeIj/moSuKuHHSxfymkvMGCmFoTexQZmdO5TLGEcBY9
pVLY3KEt1hiJNeLyLkjIZGCLBrAL41hCyzzGcjLu5GdRtEXDgZnXKLF1uRfa+tW7GNzwTqeu0Hih
Orz1Jxjp1Uh2TvElMdYhpF4ouTaBUpxaoyjl5Ks1pbKLSMdmlIJ3AHeWlOw3E1rQmQlUxs444Qa5
4vjhrWKBqcb0BzM3trTKjVJfLuRq46uE3elpVAjysV2pxsoog1lV3TVGwTU+o2RIq5bpuFgOskU3
Mr4I1CYkxGq3ydfwq1N9frnU6xiWZvdglHNvsdJt7mOs9nplFZsZOlM4aJt537ebsslKRso4kTWB
rHtyOZFFOzZiVJTdsQuS3JqxByJ4PQUnvtbYxf8A1UL/AKuHpywZ75ruddaaWsTVGYqVYlMt5KnH
2ohxlCOptUq6MLQ7CvZ6vWKNHOoRjGu3jTv8E0eykEzgoqv00iqSkK7cAcojC+pyAjwp2my9tYaL
jTXzTzUHzgzCMjYROQl4CxWehWOYO1i1Ve1ePHEE0kDnKQTiiokqYeQ5TCgXwtfbHjix3hLI9Gtr
fENJpk/LUhtbbJPW2h1q+zkfBQSLBg5rwU6OVWn7OJpmJibG4PBLKFI5SRUOUDczdjDNDTEGFM7X
/IzfINKyI3sdYxw4WuU5Z5yuI1eRQSmq2o0mWLklYQTsc0/O6gouRWgkXCDgirsiiSgFSvKccPB7
LEALTwktMN4fY2OhKUUU7/dtOfA2D7sEuYS/Q8xfrF5i8xftDfcPvDg/NMUZS5PSxroJK1Cpy90r
dYwVZaPbH9arcvZam2NmWv164J0ydmmj+VroLQiibFz4W9YAQyhE1dhOUo15LidJUp99jJiAKgPQ
VR+AB0Ew7+YB8uCL0zQGX7rc5ul4ivalDdylHs8jcJNtkacx/EuqRQm69wsjS2vWrtm9mq21jYRk
+Qjk28zJEkl0d9jqJ8ylwCNrHhrhpXtg5JJBBkZNwz+krNR5ncQZ8QLTRjnGNQR07ZbybH+rWQsj
GlYugEp67B0/NhmlyR1Xj7LyKT7s1/WFyvBweOq1NxZHMDW6zKWlvJrJzMnHAJL62qzjnH+FdJED
XMd48hGV+03aeMszFqg8fwdeuLmdSx94LY03Vmbv1ZWfb3c/6Tfnn38guxlvZUnSrdOAHx5H5jPd
JCoYffXN/bLI0la+7Z41mLE3dWuvsllBWiVJOJWSdzlbUOirOLKyrRGlyjBJR9Y2se3IZQJxmMY6
rr7giFyzcnd5smHqWo7pNKJaL7KzEXAwMCiwipBzR6NJ2F6SDptek5SLjvFIiPZxjN9IsGaq6bh2
3TVchgKhhaLsmGxEklREm14Cu/hYK04G/VVlVvl9Bxm2Vi0y0lhkmqzBWKiYgx5HYrJlfFVjVlKt
UWVRmrdQ782gJhjA22Hrbtu1soQyiifZ2V1Nt7JKCoTlk1OYoDN9DqeC756U9LEE/hHFEDSaxfc5
Yvr9brlQbw1RnJ+h+v8A6nTUlTWzteqKHjAhmHbxp0hRke8Ng9Xz9snzVx5IxfqbgKbj3UJlKTtC
sTOxlOe0i42S+esdnaRXdXp6LIs01rU9sdcYJwVcRl6A7lXKTdKL2frqKNPpeFFsq+rbFE1SM92B
1kyGvOSXsTKVbKLSyP5O+SFitzVi9LHOZeCslhtzW8TDKxqu3ELuEss1Ht+7Cl7XGkiPCiXsq9ki
JJSwSElgWABzbMv9cpCf/dVlkMsPpzmZeliiY4yFqi1OsJ3FmJxQpemTM8vV6hM0dhYqHG36lS1G
YJXBPH79m/gYwXTKGnHBm8Og6GpoPBVgAdJjzcRPpzd43l7Dq0ypI4ixvMrVGjMsiVXF9jg/H6jB
VaWzLXG98jqt4is/Wr7t0Z2jCRFiZi6n4+PclTI0IRZ0Fnh5ah6z8P5kYV9BllSm52y2SShGzKHc
c1tvje0ujsrXEryMQ+dIybZ49SVaWhOVkkPVx0mo3kQbKkMQGrX8Z6uITJduw9j+p3xtkK3117DX
OnQJ4M7mwVBNCJtCjSyKKFPEqVsknDMZU88znQYFQXbuTOAIqmcwYR2RJEFK5lnJFW46jT6PLD4j
4Ddz4tlYmMLr4QiNOuonLtgwzRbnOJ52qtLZViwOp07qq0C51jI60QhT5ZuQG1dlatcmcABrEz71
YHkdHGOZryEDh21qn6fq56NUuV5PHFeumQLxqBuOLXtoUezLawUSYQgl7XRHsWfswRZsoSNpzxo5
rkN3qvv/ABVAouz9unzgvSKTqik3+QcAY9q1klJgXJp3JmNoJgxUUTl6W9cRrN/YXRiqvVy1CQuS
TCMVayZCovXyTWsmkVnTglozVr/SiuVHsWAavGXSfodBsklfLVSI6uN3Taq2JoQkc6tEkRokrKoy
DZhKycUuxkpOTVRcNHbZQoKN1iEqiNDWXN3jM4MkyoAQxDkOknV90rGWMbfqqDNQCfZbPhx8Htqj
tOOKLRjetV9niilcs76M+Dz3F+FQsUxybIZfYfk88RuU7eHL0IqTpi3jrvmq8dMmcCCau9f9g2w5
ZKxpp3e+jWw7k3FuPXkXlVhntbGuTbvPyS0jMWCQ9TbNOqt2ZWsuKRKSiMOwNVmACLyPIo1M+Avb
AZSA6NeNc77HxHtQNlaTolfpE1iJO7MKgi9VicfRJmBJTH7K+NmqttjaRGHriRZCmwlgdRLMwcri
LSEOI+HM+cH2E5TFhEmj3BcLaWMrNNGmMaWNeibvKNbAhG2FxcEq2Mw0yPIQySrNhYl5ZOed9moR
u+UAhgCsdd12Qipu14SQeyEkbp0xM7sXczqBaYMOLICJQh8qYZ9zefgbOovT9giQ0taELrh2DgKL
LZQZL0fJt/usgRlFSl+hilRmrtdZxstMGrsWFk3dOBhIcW6MGPeVBK2DtOCzyNpH0v4vp/o8rRX6
1SslwNszA4wtnOztrf6wscvzSxPApmyRq8JenTZlTyv0LQeDiG6vf6pCPIGJmAQmnbYqlRVoy5qf
sOBKZj61QD5PAVSfOwo75TD8BAQjOVdHfEeFj8isos60kvJni5Mksm3mlDyh498WzgwFo4BNfI5x
1QQOI8O0eVr76q4txpdI/IOJpJTFyFVZp2wpXVqYS7e5rQ3f5NzOM2L1+pHISqqrlmzduikOg3WO
QSDd1RUoVAjJS7q6rlQIoHMhiwkZADCGAFjohxg+BeImc2+SflR2zo1rOqt6OmnM9WdqkbDVmNz0
9S971JwGNGdMlZ2Nj6vfMeSVwUiankNGZkoO4t4KtpwsgcXsW7nkXpW8KImEFUBHZhoX0/T8vjbI
bSlqLV1HSjdM4WmCq1ok4PEGSshVOYp9bXgq3YJOVC8VyspPLWWRu0u7alarIrpLNVUyKkMavexe
kI1mpzFNt8jY1aes3mLFf4xhF0VOp1q2Ob93/wBYp+Vr7dOMY3xhMDY1QRkAcA2db/RrH340U5rr
1SHe0OYeyLWoQFPgX8LV6pGUM1VxpZabYVYyfmouw0gCGgLxFWEqFaWsp3UhKN5hNsmpFicgFESr
vnR0CGIUW7xgOqHCAXMsmBLvMg1AIFXDEu3SC/8AmoSZgsF8JTJ0scuQNCdWgH2F7bQcU1bKUnn6
s3GntcfRuRrEbEmOcmY3mGsddskJ5Fi5OPWeYi7o2eqk5lRKCMy1O8cWIjtIT153ul6XnGe7dRE7
tb6PSQbtKpV7LBsmVxqjPMIy1ejFxAHE6FifafXUqzsElSrQRE+SEK64pEg7qJ2SDpU73Y6+tRMO
5cRaddoxKpK41lcWM8NJ48eweMY6lzbiGtUm8rGPomdjjoTc28rMCLyQavu0Vg3cq7McWxFDhDY6
mbLBZGaZBgMPYGpthiaAjSoSGiMRx8bA1t2KUMtG5BiIZw7cO18pIIpKretMunNTwJpqH8QApDCA
li6LE4YpJtOq2tOJdt8m4aLwohy1H/8Ajv3V/BtJenTA9VgNZ9O0z6lsfPJ9ScyYyxrPNYe5P4eQ
qrk5+QjyNfxcqq2l0zqewRRMTgY/sgPNwEN0iDQVgmIhPsgPGysyyTHmDqoymexImG49VO2+i5Pr
dr9Htz9OJXw3nqWw9luGzInXa7fLhWp5pZYf14VsbxqS3JS6abWxPBbXCLevFVzqpERZOTTRlTqp
lIQwnLvDl1n3k9NyE9JkRQdTL+RlVipCBUhcO5DxFRNsPQqhwdfRGInzGBb6MwAf2eMW8ezm7QK/
okNoqjPuyLGg7g4Id62giOHlJ5e56czax/RBp80+Z6hZBtb6vkuVcUGsXbI2oa+EsiNSrWKMVxng
w48UxLEQcvYLBk+wyXZK+Jp2mAryxuyPzAIkHaseXSbpP3AICQEkTdiQoGDcU/3ihv1L5bCAbdfP
YOJ2096lrFp8JlJKAq8FYUMt43n8bzbSalLHFpxkROfXl+WvyceDt7H/APkY1wEyp+4T3cDsZ73l
RVUx0A332ETl2EPtEduvyHit6iw4sCAiGhCFQSwSl+sGT2qT3gCTZ1YRBUiJtBFU+YYMZAcWl+0r
GphLAUFkXS5q0zY9PJO7TgiSwcnDpxE64jWzdjfJ3I8NYndiiHKYMJZtKJ11H1YWYzgpV/8A9SMQ
dgCR6X6OvP8Akeg0/JFFfYzsUdeseW7IdFhY6wTJrPZIegC1DIMJBx0vAox7KZpYvmQWKvOpozMB
eNQrlmt4uEeaINO+q4MJ4V1IYVPjavXWL1Gx+OoeSm305IwC1LVxi/uElX145BiRUZUrp1PuUnRk
ucO1TUIYeYpgAlNPnpNrTg2p4IpyGNK1aWeD67qIqccdzPSDBaxsc+GizPVHBTkKLdGleAtQTUEA
K7BQgc25yiN4SLlDDxIIBq2JR91JGdMYYuxYHRyrGgXjabXGXo2sxXSm/WVosk9CmYIPGETkyRsu
LGjawYxWzDA053f3ja9TdHiD8kq6iY5bkqUjOxhx5JGIZ2JZwyMPK5STHh22X0aurKoY7nr9L1eF
OrWMfxWWLRT20xImtNbp02mK3itgYlQFkC0aiHbOmcJM2ArdIBUVAhA346i9btQRwaniOW06V2xu
W+P3NDrj20W6csNJrNkUkU1HOSqRQpj1kJQskuiLonlJ+p2VFuQqqRlo8AUKIyVlT0nUnmCoPkLV
RrYGQVsPQuHRlIPNt2ruMhNEK+HPLUhiaCXj0SWZ02HtSLTlgmIs6P0gFEvXh/Y9EvFYKaN2nJdJ
dDBLFmZw5MizAgtaMd7l1U+KpU9B4eMT3f0deqWiYwmMvua9ATmP4qs1+6pTNasbKcPKUacSTkhy
FEQjBRw+fRUa6VSSdO2pFWLdVVNNVchzlKKbUJotlcC6dNPeeVMqY8uCObHOQT+EU+yproRDSvzU
FFpOay5TXWCyt5FvIvTza7EXCMITwAXB0gcN+be6n9dzjNWPMB0fHEPkbE8bifERMJWkoZMfSjLJ
tbZowLiHaTjaERq6b5BugYq8rFWQHtfbJGKou9KQQHhnz2sOoX/SFjPTlfsRpWC54RQu9dwrkxO1
SjEkPC36yRM/YZCRqoypYqx29nLQjJBvITKqEIWJXRVCCBFUgmSjC7AXj2dJWLuSyVKIC0sQkSdi
+FUi8iDRjdC72e3hTTIH4Xy4/alhavuZ8rZieNHeTsm5Eya/iGpWLFS/3a1XB4waIj+dRjVzYJyc
PHs0/wD04sKLoqn9kBh4LNtpn1nyOS82YSSZWmSveG6fM3PKsA2yEwM0Y0yFIid7JKyDqynYWldw
Rw3ODGKFXmKuiblEFSCYPgpNeRbrq/lgxasBWwrmjvCs1omA5Ve7mKK/5MAEBKuPYiAjuCv0e3N7
PFiVr9JnYp7H89Jw9HgKvqmyhCtaDnPUM0FQJHIWOoOOWTg45vHlMDOrW2yHcSieRJ6HItGSB20O
VmbdVABm6pX7OExYikLIEiA4LhmdpZEu4llS0SR/TmZbhNqNv7hrK2PUTov9JUqa6XLUJVcy5CJi
CArkxPXe53mQymvFVmeMcqy9fnXt3sMjIkizJqBNMK6nIlrAlMD4rUSiABtkHBeS8a16v3a1R8Wp
WLO/PGx9jrNnrlwYt5ps3hHhIqdWgbK6awsnLNAF2yYPDoO3bYBXQSUSAT8XYznpncTTQZZ7XGGS
lY+/ROpZlFNnc3BvmsaXMEXieMgGqzUXByuWLOWqdzeWncpk2gTYGTGcBcBENtVOuLCudseZcpNT
hMv1oMg5IxrlGjVGQJSTY8x1JVSCn6XP0yHZtbsUWePn0DKRDowVurMnhpOPOQTdomYA5Fzuxhpi
laEK0ERg4KQGZRrMuDISIBAt0P2iJPZIFMzunTIeYFoRzvFZBlNMun7OFn1A5Zys2zFcswNpel5K
mpywR1Nt2LGVSiZeWhzyt1mCz76zIWcT+tFh8BsDAipBFsUDlEYpv2B2FV05YNz8yty0g0zDasv1
OWqsjBoQrCnzOIhqfiriPkkZqZaWSOfjZT7LPI6ASNzgHN7Qbu7JOc8YWvSFp3wVXksiN8jYbv8A
lm7zrmbYVtGgPGuWD1Qq7GrqwticTaBq8avIEjEXkCJpM/MCPbGMAAiv2bsXzmjzAOEYBS+JZLxb
kbK15n5N7Xa3H0x40ysapEbMq3OMb4vZFjwpq8iUidkrjU0mbYpQOIAHBI5Us30PhZRGZGEAEZyo
mc8wzkMZhpzL0+mlnDlGk+kHpNIsE5lhbUKxopiRsHbm87kC0WKFbJ2hr2sGwudeY2mXkYpxLNh8
JO3t0PFKOHX5qQh1fowhq+6WtSGLqi6v9+wvfalVmpa+aTnZdnEt20SW0FTPUTWRpFzKkzXCvyKp
HMaRgGoLFVIYnOU5RNbBaPSl4JZzGsO80ejZYlbTqttGF7CFat7Gm1+q0pHGkiJ5JE83W77bJqym
lE/bSKasthWL7ReYOvAr6u9VOnvUdkfURl2oWHUxTbVmpGopRlEQNT6NjVtKwkbBp2I+QZ6v36zP
8iMYw5TFhlJCtRiQHASI7CGwQtGNv9UlEgSykkggQw293OoBSd1kv9R8CGfVTtasRF2ssqRBEpRX
Mskg2SbbKKruF1OxRRRTT3Ooqst9CkmQBOop9GQom2LxMsphDN0BdXGL7Jiq/Rt/aw7y1uqLIVl+
5sLaqR0apNyEu4im78JNGGYQ6Sss8k1GpWTWNTUfLrptSCqDxX08vq/GyFsaZ602y54CNUliM6/m
ODfz8kWObnlmbGKhZVBN68ml1kzlQZtkFHapyHBNMeUQA75X0iWNbmvO6iLrSbtJ62ZvBstgF5LN
XUMhglOIdws7TZbNCMaWcCwDkhamfoQ1SLBBVhYbTwrd3+m4oi7XUQxEimImr4VEsoFLSm4LEkvJ
gwORFxnH6SQqnakCJA03yHBzSw1W51r/AAhLFji9paoywspi6NyNYqrYW9tTTf4dp5e0q1utIuXa
q8tjisp7nikbXJvWtLIAmbxLoN+GHXNJdxtuk3IusKLstRJXMY5Vg8Sz1VPHyfrS8kbKjS5VtJN5
TfwtRNsvcECiqAiAHdtw3AViAa9q/em5032erQcLE13Ua0RbTSKUs1dQ9BbtZikHwYrSnlUUcscx
rrLV53kJI1o8L8OM3UUSPPFIaxJix4qKpeqXFsL6OrNukyTj7qnky+59gcmV58wgWctRGkFDMqs1
RYyE29uiL6LlO8wcg2K2ZxE+t27eGR5BUUblEW0WEximLEJvBAUlgcIdIlSrksaUnS3ISonrwIad
+I/L6elAwsVrBtksmFsiZ18VJG12jS0PXSt16zkJ4FlmrB4fyNmtrhYmwUuIeMfFYrtm1ttEeuiM
nHioQvfW3aRzF4wyRO1mUutdx3c5ynwQSBJ251yoTD6qQCEexGUnlJGVYILxJU4aMDxGWO4clLHM
Q727Mk33U4PHB2rDGGOdBGrbTLZDXschZyttInqqvCRKMlT2zepHbklF7JLSluhpAj2WPXpQiJUY
aUOuLKJAgHEyQcYMH6q6FQ8P/kpuM3bZaDfUbIbmDnoWEsERlLEt4ukAZrBp4fu0DfmEVO49MCSD
t7TL0hDQwS7u8TR43wR5z2Rq63Po6NGMOKuLBAZlJLvJJebe84rvcGVrRDGQJQ0F2Zyc2rw+zZPa
FMYaLs25e08Zh1T1OMjFMZ4cdQbeaB4ysK1htIyZ0k1HtWYwldsEPZ0oY6yRLKq4nSEjDHKD8UOY
OBQj4qak1XKUXHPZA/dXL9cYdo8XcmZsmyj15NPCNVlDpxrRmis7cv1ABs3bIqOFVSIkOcLPdOGs
3HuOtEepHSpeLHk6uzuXrlUZeHtFWhI2wQMHXo57Cu7exLFDdoddK12Rqis4BDlLWJ9umdaftLRM
hjBAelLV6bSzI5cZNKBSb7GZDxFmPHjFxbKFjt7aImRyPAlh4ewyc/K1+2SrumKEax/rjiqOehS7
J20944hKCjKDYgqgw0RVwzEhlicDLIJACSHJJEy85aGhJDDhRSRjSEjNi+nDnws2MeaXrrc8G2fU
JOXDHWNMNVS9QeNE7ZkOQm26Eve5aPQlm8DT4yqxVzfhPQkW6ayc7M+GRkdWI9yg8igctlk1DaXU
lpgy3pntrOq35hHyzCZptTvFevNJdPrFjq6U2/rvW1LtkFZJSKaSCsFLOY2Sbplmo2Bt7xaPfJIM
1TtVykLDF+ralDpEuOnuYm4LGmRVtSshqCirfK4Zrl4w2rDz+MqXh2fq6uPKqzkF4CaYtyLSNdeR
FPXpi0mkYkbI19RICkJ63ekYwDbM30i+TViyVLad8Xad8aYEsOmSWx3XLIlqhfUF9bZVez32nzcz
I4qpVfFaxqEZT676yZOqx9wrsO5E23DMK74oATEvMNJ6zhCkksGwgOU9dRZnLAPiUJYrxxFbsIy1
dy27JuMjam+hY6Jboyzyk5krGeLWNTqilhbSeVJicg1rG0ZKKIumGOGtSp9kn7XJvlUlEnMChXn8
RDqJqEVdpGIYAm65aRbzjqy0mu3TJWGYCOybpyR1IwdqlrLZoeuv8crKWlJhDLIWGlRt/e5AklK8
gnW6pG0OZayRxKRgsubpwYrXKWkK35azPmy35qPMScFjVg30a4zyJiOarmMMbW48hMpxGPsi0qgV
W90n1cw5IqpTdVgKTCS2NZ5NROwSJF7AcrIYhospgqxZ2UyNqh1Y1bPL+CxEOQahIXOs5duGMLjn
WFk5YtLwfkdS0UobWhiCIlm8XYZ9xCVlGDs1HcS9Zi4bnTcVshxc7iIWBZhLImVFaioySeqAfJjR
QAsttPlHjwryK8LCHlbD9kxdTsUXR7Y6XbKNm+Cs1roExTXlkKxet6tZJikz6asFdKnSLDETxJyF
kTM5NeKlGQruoVMs8B2EoXhn0ui5HyBL1GPqVSnbA5uduhceU1whFrJMn99mnrZtXqtEypHTWKQl
XT16zkwiHqh42MQdNl+8kTXSOYhMjWKvZHzXRbFnzUXT8n0ZWNNLWxDCcdkmOb0alQMzJnb4QxDX
bxTsfVOpozEek+iMeQcHHsKLDy06hI2KaOs+WNaZKr2uGntNWWnjIcbRWmJNMODMs0a7ReGsbdom
3VYU6TcuvX22MnEtGN7tnqViJIImzXp05Sdynq3FQcbIDXYiuvniMRFwMVypQiAFkYmBo0y7UafE
5WoCJdUZa7vTmbs/L+i7L2LqFkq9/lHw9lKHwncq5TMyRmMMjTVnnMXyVgcxicPJWNseCrgu49Sw
OmMCrPRcjYG0PeIV1BHXSmGizVMF15J47FI7h4osUiJmDMFnSjtNAWxedBk1K1eIPjM1Ce0QExEp
y+0XcOLprNnfE1axHqZxrG5i06SF51LPsd1HGV1wFX7RUgrTCrahjZne5P1KXaaplYlomaWhT+Dd
+rzK92AVwBEWXaABeGpmrUBpstGAZWh1SZxiXVdBtYtfUTqSb41JAx2piEh5WBYLQGnO+xcwpbqX
JpMkqu4vay2N8XrZlb1SwrM+yTfSo2TUi3WBGIBviEjGEghSCGCEqxKxKcDEFIzUFASYlVqMvQUG
Z1FJb9/2IrWjRRnqox+QaVLWejFyJjjGETmfIGAmVrsBskwtGfRdeuPf5iJJGjSZFeFpdta2eXYs
7eAOoKHdSTgPXVqq0IzKDoJzTlWlY8uFelsdxs1mFvb3eIsd2C5soDJOTWtBZSEo+c1eqeGSxlW6
qkTKQNdWkpGDTsclGv2DE7lyzcJJ2mZ71AYNmbfrDzHV8y40kcY5Q0q0XH2IoeHl26OrF9b1KZhS
tOoi4WdWOHLztnFTVcskdeELTkx4M1T1HK21lh01K8G5wVqXwdDyGmvM0s+03r0PHOK8OVy4qXtw
gpq2xHYtNtjfWCYjsMVNFvItEmWY5eOQQhpGGsD8k9E2F8rYz1VFYxjEi9EXONDC4sSDEUEhRClk
KoCQAVdUvUEmhFQ9qRFqQZJBD5nKXjWtLfOfLwszXXjyGm413DS8c6VYyEVKtF46SYPkD9muzesX
iaLpq6RP9Gs3XSTVTN7JiAI7cNp4uKTjmAUuQP7PmLv+G+/+e2w+7gqtYeV2GddS2csyVlpONK7k
3JNstke3mzotpppGTcjzsW00kErIle93T9vlayUvsQRNty9eBMcmUOAFMCYKGDcpx2ADf3RHYB6b
eQ/x48iYYBajZCg3Dz8tJlWcYmGz8WJ+m/vz8HXIYBEocwBvuIbCAfb7g2+A7dd9vkkVUEQEQFEQ
DzEDFEA3Hbbffp8d/P7OPQgsQVSF7MSj5CAgIDv8B3EB6/D7fLjB2xg7YopkAg+Rh+qP3j0EfPfb
f3/HimJWp5/b66my94QA8zRvFhbtRNQodocUziHwMA/b5b/19nGEFOzQTTUKmZREfZNuAiP2D18/
4+/jyqKhh5ANuX94OoeYe8Nw33+fTrwhUWKb6pim6gG4CA9TfVAdh8zfsB5j12+HE7Q6Dnk8icWy
AYqn1i7fDm6f5f18PemRU3DcPL4+78fgP2+f48Zdw35dw5vh7/w8+PIpqJpbFFIR+ACUR3+fX7vd
/HhfZfOfAc5cubdbIJiEBblMU32CA9Ph0ER8/nxwFzCOwFII/ABKI/h58Y91A7XcpC7+W+3XzHpv
tvuPHSYFD2+YAP09kRDm3+wR3/h9oeXBbdbKC5x8ikH7OUeOceku195SB09/4dfL7fjxzjrE2Y1P
PJ5EzIOPY/2hQ+PtAH8x/rp5+5MuqCYb8qW22+4CXbb49B8vPYd9h6cZlDGU8+y9/wC0H9f18g4R
qIAohzGUIBex23Exdt/PbcR8/h7/ALPd6qJgR7z+A04a2TtNGDMi1qlyl8Y3FnLylWyFjqZos21r
zpJSa76+k42xV54mpMdg3EkfNV9vIAcAECFMRXcCmKYYWllkXDx2LYipo9w47y2AhTGVBrz8nYlK
UNx+kECbB+17P1unBf8Ao/o+ozurjCFfvERBWep2OZslfXr1piGczASL6wUW8xNb7WDk1n0Wqo0m
ZmDcJlXZTBuZmHKG4dBuyZCP63drXWpNsUkjEWSTiHDYpBbGQQSfEcNTppGApykXQVSWQHlAFUlE
1UxMQ5REccmN0fCimRgGQFFTFXp2crBxf6vC3NbRz2pTgYTE2Bbu+4iGwN+Xbm7UR/V8u3Xn229/
E5aWMowmE9RGKMpWf1iLXqPaY+bl21VRaq2N40j1RXLHNG0hOQkWstISf5u+RTnDH8J3UOXsva4g
hdRUqAblIHZ/rd9g7T3bF3+t8vP4jxva1LwUVYYOXstd9ba5FybV/L1cJh/BeOxsX+vrwPY5JUED
Pv7J1zAKv7Im4X6OKURMZLKcMCzOW75E087HjhHxVbTQCkjn+dbSYbXJiqPkLvVAaZYicUSGoVrq
Ox7JwcfXUciQrh27ipC90qTinN09TndPnq80d19FGMsniLFs2cTTsbCkiqqUNM05jpOb7rnXLllj
7bA3y72NjYMYwFTTjpGoEK/tXiFlWub+Vm0plBPwLbuSldQclPdfz4gjHdODtylTMNSmqDVFaajT
Ma44r5MB4QzLiStyeP2UhimsJ3GF09p36WnMfxbGdJZSsK5YblYzNGUdNkbvju7CoBbcktMgC+qa
tVQ9/ipuiRcC2r19x1jvI6UHXI960jmT6bg/ErPKwUecBeQEcW0fnDNvIlTRNDfnJN2/t8ek6Qh9
IIu13MW+QVbJikHC5du00qGbEu3fbGRdYCCTgJec1K3elppwTrJrWE3+jp9GMrenHYKeXKVyxXY5
aOh2F4uVisN2WiLPEoxM8s3nLXFYvt7SsK2yzRKTxBGJdQJmha02VfElSf1m4JcxMK2rtZyO1mHd
e1HQNzycpVqk2vkqzypNnnsUNlXrjJ8lL2A+KwNUlTJyNygDRiZWikAD0qqQmiPGLU0rpSyTf7zj
DFMNi+rwtYwXTrwwqMe6yxMZfdWGAtjawOrMV2L6VaKQEZLztlcS75uCSEgSNphn6apQMawej7ol
31Us6PDmqrPT1iSU081SzEjnL6NyjYmeT8fVy21h9ZJR3DAhJObvZZlswswsZUTM2NqQCkeIFjSA
U12gdKLH/FXeMSCRjIHVGGQarPSVr+zwPgP/AFqsBCuecVr5YpeVYqUyVVZaiQeEytX9fpdcVUtt
vorWD/KfLWGMY5OjHMX6wQpTPmSlfkZ/x+RKYZ0WZwHY/bx6RHSNfbPjNScxZeRx9Rr5nqfk6O+x
9j+TirNAZXqsmnDJEZmyMeNI+iciv2VlKko0mFIYrxq5rwPiuETHGmx6Uqr+WunZMzvI4ux1p1yF
kPJKKkbjOSkq4m0SwjaDQEzjuEa3YWEjAWmeloCvV5vYpKVTYOY6Slbenzzxn7SzS1lfF2nbF+tP
PFDjcLU93heDRxtkaYsLuzXV1EYgxDK0OmTdhhI9OvyDxxKX/I1js8FFViYcTEwyc2yyRMfHitTb
TIvERH+JYNkYieOFORDbnmG1sTYXH58veO78+T52CKk5UpdMpOXYU0vYpBnlnFitX9WCViHI0i7g
0v8AF2msPzThZ/s3TdhVYJoJZjtTThJNVIgMwVOUB2Fs1D48sOiLHuAFiyy2RaLly03Zm7LCkPCM
aPPoc0iySsBZoVyO3s9u4In4KBlT/VAxtuLC8X6XNM2Tcc4hlaPjeZJC5ntmp2KjZW5Ssm8zHKjR
4C0W7GRMYJVq3ucaNTV2KrUY2vRbY/QNMFe3AGYbPmPAX48xlii5aS9VU1NY9ZtcwYQe4pk69dms
xOdtIRN/yc1rVgbKwwSY1k4M3L5kzbF7gIA4eNW4ACzhEhxREdKLE1pAAySndrw5k5QqBL9RZpl/
jz3DQtWMuUqywdQHmX3KICA8weW4dfaD4iG4e/3cF9opyJT8aZzr1iyTKOo+kOKLmOm2KSSjhne6
NrpiG81eE7KAYFUfvAF/MQb59smYCkZAofYCgPA6P23dFzB2CICj9UB5dx+wPMf4jwRekHG1By5q
PwzjXJjmaNSbpeo+BsiVal3MZYBbv3nKJ2UiukVBRMZzaPAxBMUWG4APKG3GTdoCxeLuYXXMYdbF
JmrhArmwednlKxtk4buIAz4Wd2CMjUShyOV6nNXCxVZhkmtqVaJzVjNObZTcMozmU+8NJBms+i7O
lia/V9Fujeq/HtCTKiSUPyQdhLGSggUORdQdBdej9xTgZhkWsSeSMe5evyy8dV6zY4Jd5iOxuni8
edzOWCAr6T+JlplOIePK2MuaWmgiaUexEY9xdiMFPdMi1/1M5fw5j0IamVrFk9kt1OyV7nrBOxNJ
pGNJ3weXmXzpu1lJW2S0MkH5hHRsIopKAGyZD8OfEGnrCs/jDP8AmC4XS7u6Zji81Oh0wlUCpQdr
lkrdFWl9G3a0U+VspfEXRXtfi26dQYSoxh17JOpEsoqV9yVDUhJvQRs9hCkZKxKmZB2FJEuxoC8r
LLMNZmtQ3SI93flPwtJOrnN2OMnYB0bxdEv9SsFgoOCKjj6/1+JgrDHzDKfqMIgxjYmelghI2PsL
hjFy76OOs3lJlRFdu6SOUqiawAr1D53g5zPmnm60bJFCmoSFjsCTNgYQCT+Ix9WMhVeAqUNf39ki
nkPFtnrRJONkQTWLFSpEwYPQOYvdVwTZI6UqJD6JWmq2222fdWa8ZSnsa1eGhmtZlImLUhWyjxrF
3UXVkSsoktbNlbXjt4g7I3YtnEIuaDKi5bHPzPek+pYN0zafcrubDbpq858psJkFi2RXrfqK3h5h
FFw3gQAqw2Q1srbdCKWUmytxjnqTiYUMIkSXECQ43SKFhYRBqQAwE/eAYVkomWRM2mbDC/uLyNP8
Z+ZbgNLFNXtSVUivSnQ+XgyjR5fDyGaLnPsLk9kHLPHNXx/a2ks7kG0G3fHiUo1wo1dtTzgQbF14
nNuW6EZu4WIU290p5wxnC6/9RtovWT8bmxtbsd58x9WbdeLIK+PJOqy9yhnNHp9edTrhwkpXzskl
WUdX2LRSOcwiSiraOUbEMYApz3pUr+H18JU6InLdJ5YybVcVzUpGzsVANqSCOT6jBSaLmpyUNYF5
hyghKb1sVrCi3TCIAZvfsQFXh3WLQ+1U1WVPSZRL3NyNzl72vRbjOWOrCi1hpGLIKktY4tGLl5wJ
ynLE9urREmDd85J7VxFkG48V2V5HWEOEAUAg4zhCUscQyZlFy7M2ge+x+dXLegs+tJmRYxjedaS1
svFAjpqx6e7Q1ql5tV58JLKXWLytVJCqBQbYrPoP1nj+PCekYhFMFXLJrGRjmTAzUu4ptPeWZlpp
y1iHLdoeEyTYb1jbIkFaZLJasRkC2T6Bbe0n5GvqurahNzU2kwmmihJiOYuZGXmZZ0iV8o4nYIqr
Vo2gxbJ2qy6aZKJkB6qXHTW/ztlsL2pOEbcyPjZwi0skK0ghlwYvLI6dOG7aOaFmDVBZddBFN0Ki
pCiwMR6UQzBkXM9Th7bON6vhbHlnyrYbE4x+E9Y5KBr8xDVt3BuKenNwybCabO7ceRsDBWWTct0o
iyrVdK4EWZGJZMS9QyWWl3ScJZgSUhOcgVAszAkKaZNpaD/dV/0j5X+/JDWqaGMxUd9ifTkExkyp
BP0DIWcY/IMpc5+uQU7iSoXGEmpZKfgGdmdxsXcWthXVSIg/n0bw3aGVICau5ygYSaVXbbkDTPq7
olasjKZoa2UKpkPFqcvb6nW29mWipm5RtqsVchBn4OXayp2zpqo9eLRCkLLJuG54cRIsmJhvxnpC
VyixlJ2LyQzdwhc7xWEohjUqjKWmyOn1pVO7ZZGs0KrNU2UrOKUWCSsaEkm+nJQFklEArvOQxQ9x
Wi+0Ts3qli22Q8akltL5Lk9nojxZeTsV6SpNka0uZsNLjzNEF3VdSm3zIzq0zr5F+iu8aprIlUcI
lOzeLxe4V2uxjQoX65BLAFmIIaUyHAc5sauTJ2cJ8N5iHKaUyfCG3yenC1stEuuCUcSx2Q74ZtLY
4S0WwGPJEZu3R09RKlPU+g1SsOaLC4HkDP2KN/k8lHbWGvSkFHvJdpBQE7ISBRav3KohDLxtpZ6U
8moZPi5dNvPPNP8AcqvbJ3JLrKqedkF1X8g0gKc3kpB6nTH6lfsqk1Isal3pwmmcItVMpDATgVLX
o3yPGaZqbqwYyLGz0a02eZr8gi2ipHxaoSFeeqRyr2VMkqaLRI+kUlY9E7uTTBZ6mo1IIrkMmEU1
TB768w2QpeDyXT1U8aY+iso29jLN7rDRZHk/IQEYxo7OelodMLLk1xI2xJsnXyot4qwRUPIGrtgV
SayY2JNXSV4VE2gupBAAYIfssKkTL13guJF2IN3iwv8AmoanaRUB8MpHmXdYzrPhVMg6yMU4XvVj
nsWYVuMpi5xHIT86wmYGhsp+rQ0fYVYFJSRZxlSYx3ZK19Jkm+VTS7JSVEpeQxwP3U9p/wAT5yNo
Vw7JzLPH2N8f2nKOC3Z27syko3i6NJSC9LoyMpNyTkYeYyTWKwAx77tHLpVqmZVmCqJRMHzTWDHe
TYmBg7bOVC2Q1UnGzMK3bZWFnGdfnW7pp4hCrQkyuCxFUhYfnqCjJ0oRRp+cJiZHc/BGOtJ+ZWWB
cT6hbFfabXsa5ZySNAgz2uXv0Y5r0shByc8hbZ5rKU1CJa0ZSvNXwJzEC6n1TtplqoV2ZN0kZQPt
4iqT7RdVuD1RgbrYWzEyEku9QXyFmv4fD/uw9/6hb3atk4PjvtaRrxpuS5nIukuYwPW8gwTlbTzG
USShMbW6Uh7hDM8eulEpnHI2yVlDO5aXgYZJVm6ju+ntTrs1CrI+wbaLtT9WvamQdA8lR8U13Jdz
teEqbAPcUZToUJeMhzizIAav3OoI08cCzVtcR353+UyQbR7ozX847EUvpOAJm8E5vjMXVfPFYyjD
ZCqk9m2RwrX5jHlruoSBsmihLue5s0bXDUsW0TZmzhuuaTT+jeILoqpnUIqmY3eWMCapMT6i4HDc
5f0nuZrFDVlkxl4zKswokMbkOresDaFcZDlhgxcKKtv0XKQTAZeFmHH5vDujKbk4WiXiAmLsxAik
f4TokUyY/Q2FBReQf50EM3vmgwcN3gbaa6+ouPtVjVrpktlxsdRb5ChmsPJwbB63eyEctY4VezxT
dBm6RmLPBrIJKLNZWRZpxsykmopPw7EhDGBsa+a+jUtWeomvs49sxax2WLSmg0ZtQbIJd8kudi0Z
sQKXuTJsmPOIlIVMpNjCIB1GHawyulRyCybpW8cM2eMkl2Dq5PpCdqy9WftejoXU3V2Ujaa6o2/t
ysI5QyP9oBfLh5aqMNZNwlmy748zRYGNxyDASSZ7VY0LFY7inIyjxLvCj4LDYWzWSsRQQ+mMpLJI
ACQioIgTrxlXgo9m/lpdzJ9CkU8H48LP4I22u0P2qE0dnOKaXZmyeXpQMLwd5ESCBkxOoTtEygYB
MoT829shfMxPzxoPMUBD86bDvuulzZEW25gEAEQMUTlSANzGIHmYpfrCQvvMHQvvHpwcGmLH97m6
blG6V9lpxRpVKnKBF2216jKzXppghY7eS4KVmGhXMqktNHUckhX512iKIqnI3hjdmJVUBHFkG3ZC
wVkHIlFyRgnT+0uUVYO7WKsS2IYFZrBv4z9e2iWScmSMjGr7+xCFcOirfscw7cUgXJAHtC4ynMwg
gNUBgXB07sxYu3ibbZYEkCWJy5pPT6d1p30EYRqOXcLa9V5JYiVkx7g6Bt1ZVWrNJsKypmMjNKSD
BhMzFbkJyrEcEVSN4jVXtXASqpm5+U4GGXMC+jyxLkKoaOG93v14SyNrU/Lg9o7iFfwcfTqIniMP
0c1m4aQiZOan1ZH/AM0nDycUYfIwdeK4YrP+VahLW+UoF5ncMJZAS7haa1iaxTmN6pKxXIJ/BncN
XrEEeo05AMbs3biYLygI7bBvwmr2oDNmPmcVC0jMmU6bF1zvo1yJq+QrHWGdfCZ5vFvVqMi51FjB
hM9mfv8A2DNPn5D8+/KbZmCYKX9oD6FgWkmVA3WmxJ0LAgDokOMSyohRMGrydAqaSYDjR52NBhpg
0sR2nTEuZsm5bynS5fMSeU63DGYQUXZatB3nCR005ZtPso4ytplajbDzVSJBRjFoMnAnVtpZPYz6
PDh93zQTgbEGJsVzmU9Rjyt5fzBhD8slMrUZUZiYrizpQoGhq0dGtV97JHbIc3LKPfEh7uJRFYSl
5TGBuFZ6h8rYcsnhUjc7ThbTwi2mZuGdWojin43LcZdoRo/hoCRkUGZHU0esCScNDNHY86SgLe0Q
wBoG2pTOrFCNik8zZMQZRNb9TYgFrfIuHcBSg/8AlSFdEO8cQFR8v9UIKWXi/d4YAcX290l+mmp7
weyKS7SfDebWWgJiiGiIpQlUB6AvKWVMnna6Nv6FWizr3G7GG1Az5ZjION6JPpKSeOq8mzLfsh1G
52eiQx5GEsqzr1CUYVG3MbfLuYSXtKJ3kSnTW7405Mg0EfKnoyLBjLTtacvv7+2bX3G9SxRess4j
lEkhXh63mQbSFOGMnosZtKZdKjXExWGVBuUwJn3NuBQMLEdrP1UMVIN0yz9lgi9dZVsIJct3nuSC
i60k6Y1QWpwV2dIsI2TmY0pyCJCrSiaACB1ylMiltWGo2ZgJWrTeVLnYa/Y6u1qNkibQ4jbAa0VK
FKwUi4uZk5IH60o0rxJGfPBSdkl3yVOLJmNT1IYF3Y2YCVwgYuFht8OLquQcQJIEhMHCxdmcTBde
Pd720lAaB/8AHe5/NjVn/RNSpsOSeXadmFKZjm+AIPU5WoSzVj1ePLUNyiRpOREirXZqwjCXusP1
U5Fu0ZDYK4+SUTW9aBKYDcU9L7t3GygcyLYOc5dhEFSe4xemxij8Q6fPi3bU76QZhd8F6eMO6dJX
LVGbY6wkfDWYndha1aId5GrTcsKEKxaTNWsD2clam/7lbO8USTet4s4OYPeKHvLcVBRdo4FTpTW9
yGlzO0ZWZZdzGRd7Plt/6tyVkZf7a0YSx8fFi3hGn/mkm7lQzff6UpOGVwfaI95UCUIgE4QAGKXA
BJdphlEAvUGjCyUrgttQMg7msstBKlDZbql0mV7Snc71ia3ZlZyWXqTGVmXewyGP5lhT7cjOQXjE
w3q9/Z26bkJM1eUD8zLcaXVhkhH2OfhzZz0BZIwPi+ayRZrVXUpKlz2N4HJWOXLpkjdqdOZVrshP
1BFzC128Xpku3EsTKrOQmxrO6UZIKCAkZORTgzKWq/NOXmEq1yfK1e5SM8wq8ZZcgzmNKApli0Eq
zI8TWy2PK7evev8AL9igmoY4SMo98XImcSdoBBEHleddeoTKFUt9OvcvSbKxyK2qyeRZeUxvSzWi
4zdJbPGlTt9hsTVsEnMXWNiH04wLbHD1pKpGkCJBIlFUoCphuKYCUqhhMRw4xKqSl5as7E0k4nYk
P2hPYZQ4/wCOlJkDxs98hVOm/wCgVpkvkZTqxFXtXOmonHdmtFfiCRM/aoKuV/G05AJWw7RVwjY3
8QNlOdVF2DZVsVQDKFIBg3Q5Hq9HPoW055Jj6dXoW9r5zz9j+3XKBQlE5e2wFdruNp+AJZiOJYWy
76JLZTrKpMgBRskcFDlIUwCMGzeoa7zmBqjpxlWdLLjmnWV7ca0mSnRje3s7BIrsCPnYXIXQSrwZ
6DZ19u5OWQMK5GIAInKToqm9SF4smAalpykYLHpqDTLbJ3iFkUKs6SvDKWmGrRK0KmuoTe7o8hDM
INmYQSEygRxkxEewECcY0M+24yU9YktLqlLADUh0u8s3LWvDTEXUJEsjnL132LTNfovcx4Gh8xv7
/lTAyDnDEPDTNnr430zeatx7CTnRZY3i1o1Ne0uGSftqoWeDraiRPaMQA68aPJXo1Mu4vptluE/l
zT2+Tr+DKVqDLXmlytbG3zWL7svamsE+h4maotfZyFoUc1axN3sOzmFnPbvK+iZPtHjUp45y3rWy
PnRjZFciY3wFKXK2DVk7rk0mLGP5RbKSHYdg3UmLarMyryH8eW+inj1KNjnM0qHZxE8c3QGbqz1W
3bVdY8eWq8Vej1iSxtjKDxVXGVJi5WIjmtIq0hKyUUzkmruekiLotXU47REsUD4qaqKqY7HTMBbK
u9xRBTEKATIKmoAHCmky/Wc1HVAFQTYUNEdZYsJ5TlL7V7znZ2paF9Qv5A4jUyNciBx1LXJ5VuzQ
mmp7aixawdYtKVwPFlMMYFUNHTzlmUvjfrJzFMX1VDy4tOyH6MvFuMY604eeVxScs8ThW1y7DUsp
fHLWXc6isfYjmdSsxXFMOGlyipiB/UHtRr3brJzEiKiUu3Gw86KxQ+f9vkC5BV0qENqsgUdjZlrk
1o4zsiFQLZXbeMbKWMIAVvCfWYsTAtmBpruXigGUTSF/uYoCcjr0iuW5CryKFkrFNsmaZjEjvB7j
UpOrTS+W/wAlssrORC5G7pCa8PNdX1TknlKkchkYjce5jANFJgO9tCHNBi3Yw8BUlQCVzUlplsBZ
z2HYu4U4LB2FI93jDsJCC6aEuZpd+MqM1a20DTQzmSbpw5SgZ7HNgwsTFEhlaazbD2ez/knrL+NW
fN5jEk6/ka3CWkc6KuIyPQi6NBwdhTWWt0EkjLmPMR4OZupOGdJk5paveaJ+rWuoxlboc5Rarkq5
ZQeDkHJOrQW7eXQrdBxfBJqwEtiisqydNC3C8m4Z3CiSWCePMiktywmTXPYWtdRxhC4jxnB6fnON
XtMmMHdycylQnrRIxTqDLnpzJTDl9bW2elJWY9jJBnxbOYISLhwUGuFTf8SFkLXLi/JlciI2z6Pc
YpTVS06zOnqhmiL3Z46l0szuNs6TTKNfxSkinXWt8jpyXNa38y3cv3r5xCxsWdcXhUrCUkOLdUoB
QjHEeaCEgMGYFy7tJ8y0gDKq4N5WB1sLAU/2v99KnMWIOA0JYJWxxTnrqLt8sratD161OvsruLie
hT1bv8FXr3NwVMhcCnIE/N0aFNXa6ZC1N3a0dKg+kTkdKFE48Dvpd034Xz1TUyu6lksXqNUylJ5H
zEN5psRC49stcp0xa2iUFiZo8mrdlOnwEbC1VpNqsHUPb7B4s8LFsjgr7Wxj/SGKrxlWs9uw0wnM
4Y+0sTmk6p5MaXmUgIImNZiFuFfiZZ9juLgVY11Ow57bMIokNKitKKpQyaYKHXQA0P4G1OYkwuFI
vLTAyqufsc0u5VOn5GjMhLsK/MPJ6Fn46vWy+0iRi5NxaHcW/urxu7aRthjTSMTX2CglOikBitxo
1xN47ASTkCJOXDEIS7AgBwSGDkklRqtF4WQ6mZtMsHHfrnYfsNYcvGdbm1pVFj0AAI2SsE7ZZATR
tMo+PodwKtkyDb5lsWbdU6n090Ay0o5XiJecWcAMJSq0/UAUuDc0+aJsc3XFVWvt3bZryM5yPkG7
w9Vb6eo6sLQFAx3iZOrLZRzDe5K6KoSkiiCNhcK1VNOFIU6ZTHulgjyAIgI8pqLuUdh2GxLjdFzj
SnycNLJ5iXqkg/Qd55npF7LPm0pkOWVkAfTlcaV+Sa16Cx72r2pVZvJoTLKIepTkyq1IfTbrbpWN
8V1bGmTallKwvMbZReZDx5K4zyqtj8J2CsxYp/dsN5IQSRP6046yG6r0R31jLhIPm0HI210YO6yD
A4qXSF0Qm8K24WSXbGSWMpkEgkChYjiC1ojovMmU0hR3y85eLvSyvUb6NTUdgOwXuIbN4fL8fQMn
17GryTxmM3Y5yOkMhQ9csNFdy1J7srNwkVckLgzhUHCLSdQLa4lxFNjHkG6iBNRV9G0PV8mz+Cc9
s82z2a0E60tBUXTq0xbkFrBNpAN5wchzcpbDScPMxfnJVGIgTtGQdXVkSDfifaV6WLJ9TtuWNQRa
VFWLU3mm+xy1utUpNyTfG8FhCBjISOhcZ0+jsZNyZhMqi8ka/PXd6iBkuyhJWNck7dsc0ajlrQa4
yDdbqnRNUtNdPsk1jIdMl6/d6naZ+CauECT9uoUiS1STRhJxL21KpWaMuh3Rp9zEKkZIyp0TgA2u
l26OREu64qTF2wTiSVEJSqWIgM7OHDzLlwGDh2kSJJaihmkADJkgVNXG6ueU6SHosKNA5E1cQS+f
XmT4DTLBVWWjaZhiBjLXnW3J2xXsEIM1ak1oipFNT1vob48TWMMgt9GiJD7l4bl89FBNw+UL3AU/
KSsxRsZacaXqYyUMnFGLmuHq9uCUGTxxH49r5HMFLZtTCEbjH1OQma60UC0Q/ZTgjKs+3li6+lUx
bltbWfD2rGF/xZBaoPycN6ndcWGqMtkeASoRU2ke1nEpqw11jLrWVgdM8olHTpjnmFQbmKK6nKOv
uPpZoSQzTdZakVa4VLE+QdK1d0uWCfh3MIw1BMlajD2V5AZpg5KPnGVUJkaAtc+Q7WHkJw1ekomI
iFmVogEjJHGMPRzjql8SXK1Ahv0cTYQJ/wAxncYmLhOEWHs43wDz8e76b7Vhai9MamLqDRMvVSYu
Q0W/W68Y3eVvKFeCgZgquWqAwbL3GJs9Pj5WXrzyAdwEvTJNtZG04WQmXhplSwVhiJJEbKEqqMii
fsRXSU8tgKcpvv2AR89/L4/wsV1bamYfL1Ixbiqo2TKt7r1Cf3S/W/IOeSxUplK/5mvb2Ka3qVc+
G3CzHYVqPioulMKdAObLKz8cdGXRkpsDN1ikr/XaiRUTnMBTAciYgYdhBRRwg1TTEB8jncumzche
pjLuEEQATqplNk9Iw4Yvm0REhH5AeDeRFd7jKzEO7KiTdh3bvU/i2iUXfGMoQ6pUSl+uJDrACoj1
9kfF9j+7y3+Px4wfnW6ZO3ACo/VHnDbyDy2Hr8Ogjtxs1m6iRuRUUhNsmPKIhzAColBIdgHcAUFR
ME/3xUIBdxOADrFkHhBKUoFMYyZFSgAcwmSVJ2iSgAAbimqT6RM4BynJ7RREOo5eGGo9QRHkzrUJ
9T8y4zt0QoT2etlXOX58eFvHfF+1WDtQ5zB0UAwCUfsHfYdvt+7pw44WSVUOdExwAT/U3HYVOu3s
gIbm+fLv0/g01lVB+hKkCY+9QQEpf+YQAPu38wHp5beGkmRo7THoHY/VHcA9/uH+Hn7+GMQ/uRMv
eO78eesxrQF7pZDh6WeD6REgrEUEDnEOgAICYfdsBfMfeHThqKOE1ObfbZIOm/v6b/H8Q/hxkkXq
sgp2iAESEfiIFH+P+Hl5cakFjGFYpeyMI+QFMURH3DsAb/wDqH2cFdOpy03epbiLCtznN8f4B/lx
5U6oiAdR69A6j5j7uPHal325R3+Gxt/w348A6RHyEo/YIj/I3A8CNT5bvX6ayDEVtKhuHd6Wxqqg
X6ggbYOoFHfb7QL5f18eNcLnmHlICZBBZsbYRKA7F+sOwiA7B7xAOnv+PGVQ5FVlSpHKBB8jcxRK
Pl5D5D06/wBDx4REEy7KFTOfbftdwEu397y+P2dQ4Fatsm4bAfcOY31S79R93Qv1h6fD38ZR6BuP
QPiPQPx4x8x+1EdkwBL6g7hsP90d9h+4fn048qjukIAoUR+AG6+/3B/Q+fHWJsxqeeTyJ+wKZQQ3
Hz8t/ft8Pj5+Yb/hx1zm7Tn+i5fPn3Ly7/b5eXTz+fHhJYob7mKHZfU3MHX4gHxD47b/AMuPQONx
AQBMSG6lTASiJvd0D3/YAeX4cdYds+//ANwv/PxzjD2hxHYATEfhuXf8NuOcW6nxHL7ev7ydixo9
uXfbZLfp05y7+19Xpv7/AHfH3ca52qqQ5SlKQUz/AFSB5n9/sl6839eXnwo+k7XflJt+bB7tvZ+t
1/4fIfh7/hwldqn7UR2SADbdsO5diD8EP3v/AG/y43o7ymeHOjaWz7bGtykvAWCDla/NOq9OM5Ni
dnPsX0jHO4iUV/UPmclForSyZWH9uoVACo/tiTiaNUeM8l4qzBcKJli5Nb5eorwVxP2VhY7Rbmsw
9scBXrcgsExb4+MkZYWkWsi3VNLpNuyBRMDbAcvMPInOYopkOBFlCdikvuAFSX/+oMcR2KT4nEQL
8x4J/VFlms5qyAXIkCnYgezdMxk0sYWGGiEzltVTx3TaJJPY3wywTg2KPl1qW/km7h14Ck5Qkkl0
zGTWIYzEM3ZfRF4eKoLgMyQkMqjucq+WdhrQERtqC5emUx42FJRE6h/aNsG36oehx+Hsef2dB477
JXcVN0uzBbcScwdA38x69A+Y+7pwrVKYVQV5R3HyACiO/u26efX/AKbdeOImKnsVQgnIr9Ydtyl/
vG8g+0R/y4zAh26xDsT5en00e3Lh46qI3ZZeljSHGGsCVtunYjmyXyRv+caceVxGZ9fbKrZmVEXP
NVYQk38tMtWlViDVutzD181Uk128Hi6OjirgggBIDiLctV3NOP7RGWmfvcpaJSfi1mNZypW75L2m
LsEQaJLjx9DwNzOuMkuyg64YuPkyMXapG8IYK8YCNzA+EyMSaxMZ0mL0UT8ywuFouOnJrnWFyK2d
s0e5T1Qyu6tqEA0h7KM0LqbSqUNZFWaHiEMgRtvyewI7cM3UJqOxjlPDWG8NQhHDJfH2Q7i+e2Bt
SYup1uJo9uMolGxsfT63OvEXb5wyKvZLW3aMYlWSeFXdIFsbsH1osvooqLgbqNrFixDKamrIEbmd
/GyiIcUxdmtKUjicVRlRmc2jbDmnLU7l3GEdXsfzEIGP8k3CeUgsePMqVuCLc7nQY5c9llGVEkrK
klLnaV5s5TRUfRKIpoN1zmEE0TiXjqc1Y0Wgscov8mW6uVq3ybRnHy6GRGkfZbg9xhPs6vFmcMYi
ZYXWfg6HZYd7BxE9NryTOuooQjauLvDrIEMzMNZFgcOXq+5AhrNMtrVWqJZorCNpj4rwdVC8zyqE
MjNScR204jG9zocndl4JZ3ISnqq8ViO5meiuiJiTJnfC1uwziWu5Dcwc3a6LijKlQsacjQhk8nTW
QpbKV7t+MJGoZGcRSHKwdOZWuBblZu8V5micLt4rB2AXf+slrr7IIQiLjx4JLABE0u6auZacXzNu
XDjf0UpXMSUSJONO/OQFhazJYdQ0lE1CLzDYbG4in0a5v1Tq8zIRpEG8fcHqc6ayq0sgJt4eTtqi
qU+eauUZHz8hHKEkFmloanBYZbjrNrTscueDWbzNhms74/pdikKvbaNQXsXkTGuPmrt9jmRkqzdm
Bq8aDgGdOQeVaTmkmkedrARrh8uokkU4GvknVNpct7e/ZolaRiy95EcS+nSTxTSJ/Hy7eaUf12nQ
UJk6rZjO3jCw0pX3JULSWBIjcLYg5F3AlbgYXbYFGXljU3GZNidPFxr9gxhG5RncY5Nxnmus26et
1jhI2vSFut7+vRVyWmGikYeqGgFY6YqUXHWGQkq6mpART8CkZyBBZXdSlsPSOJyPh0BmxPB9SA0z
bsUT/wBNCy95Xy8+jdWK6jd/SEsbDZqdSYe9J2GjSKNllISFx9RXJMYy9zrkjBElaw1aRilXoS1w
hbEvIJR9HZNDSTABdtyLN/pOIEr01qGY0LPFJrdOkZCrWM0cfP0mFCaSc6zY1qej7a1JcLO+7J/G
hGv64lMOPz9sDZoHe1OREO04LeXzQxlc+0ybgsh4bTZ0Wo4RStZXlhtdcwnbbXR4OFgnIUpRcW6j
5vVQbnTjxtjOEBAzVUtb8QGJj/XHbOrvjWx68M/WSKylXHmGbZQ83pL3S2TcRXoWdmbJiecaxqUQ
h3tsNgdGyCJY+BRZQTlZ2kIItCqH9ng0e7pQOp0likD1sI0yB+/fV52gQQIsBCXahJ+HnwpJqhnn
tKqnU9sw7dA6iO3XoAf9/wCQuHHt3sONLlVL5V3ibWyUyxQ1ohNiAp2kxAvfFotqYA3EWy6/svgA
NinHY4AbjSTRCitugPTYvUB3D2y85OvwMT2i7/WL7Rdw80vaOSgIkTRMskUViGLsYwqfuht5m3/Z
Dcft67+ZQ6L3AEOOpAgmRDHE5Am550ezooG0sT+QM25rXyvMZoctJfEeQ7e8c2SQUpsHK47byfj7
pOZkHy0TMvimlI6eOskLpqVNRJYFUxEDc5d9iy1KWdzA5qrCFBoK5M5ydVlLMaAi5lg8ipWnIS7l
oNHgq7Ks63DKmbzL9wQrqPKYyDdwqUBTRUMSdtWB67O6kadkjLsjZJzEGRI7GFxVGmTcZZbC+rju
iQruThqoWUmWpa8oykUlWjxB5KEM2dJKN1ikWIYoGfpeqzlDURqbmIdtHxkZeNFeUrtgJfHdjQiG
8FS1bxjqTpEPBrizbSMfIliY6DrT6OeNgsYScVKMHpbFKSylhU2YsCPAi7NF+QsEOSpQBFHJwnLM
WHDZcMRDCAOjk5jPPsz3m1YIai7OOnKM0yeqteJBRmXnOYEriq7sitzb2xeEkYJwyPvJDDkikvEW
CapzQ5UiHfMymEBcoAfdZb1VTWW8K4Ywc5oVXhgwVCu67H3CImLDK2awx02udaTQn2s1KJpLBIOU
1JhiWPIHcF0zwpAKoUyQEHp6s71TDetXIUbCv18oRz/HlolLe0YQLiKGtvJCwQt0qUnHOYJRF/Vn
42JvMz9PcFZRkoyjYR3GxgoHbqGecLJw8d6L+VtVaqDNrZHeqmYqV6tkhVoFzGPq5O49nbA3bwsk
pECqmlWZiv1ti07BYSwL2QkWte74uJk+LGF+kIn8RDvqlst4J4MauzObOBKJdQZeWH/x87B5mjUG
0zM+xAJ6I2qSmI8dYjxg7NAWiVXkLTA43YQ0dWpNysuBixEq+apKqrAeLTVOikc+wlIYwPh/qyj5
jVlXdUKePDRowV9h7vIUNnc1wTsElFx/YmjlraSJB63RerfRSCYw4cqnsLFA3QC51Ww1TitBWii1
0eppVxK+0qXhrk7Gl1SKbSturUmD9eyDIx8aq5Vt0w+AShae2M9n4TZxamcs39rhh6z0anTaTpIh
oqux8ZQLpp+015Tk5AmOanAWBR+rjjuFqBF2wdHeSZ7MmHjlnBOWUGYlA7WM53/+s/EJTHLNfUio
E8kkCtJs4ftCYcEtNmHh/XDBY11hXfVO4oEy/h7ZMZXlvyfxN7bRqTR5kxwrOljl5WQiJJu6Qbd4
lFFCGjRAhW8OYwAVVATN3TdqmpuGcl5/uktSrTO1nMGJr/iVtX4KwRrF/EBerrB2eDfO5peL8MWe
1uPqyzIAPG88gebZJgBxeIgoUeU/yTN9e+JMWS+PqSniSOzfS1E4lnien115MVC/r9pGU+RioeRj
42xVMZb81QRsC0lIKRftpiZLiSsW1vCmQPSlzWIrbiDFSFNrMvnjGlYqUfiuto1aTGnjZggpmZpJ
ZP1XE6QQTXslHreWamFRLlhA7Qg8SUL/APUQyWxSJyw5t2nTSp0nIeyRpzL08zYANPuo+tY3grpT
rBH3SIiprJ1Eyaxt2NxiY61s5TH5JqIZVA51lYtFOLk4BRN+7eiAJmfqEETCYwCM04t1f4ci80at
cp3mt5DSgdRVMyxSavUKcyrb9vWYHJl+jreDx2+fT8M2UWaua6iCpjRvsG25hKPGvqCFSl7FrIlV
aBi6Lk8cYwhpGuvi4ypc9C14lbydA0+cf1fGMx4hXK46nm7RiIGjmkeasgtYfV8XYIyvrGZmn3E+
En2vawUu7YWotqq+X9O0fPUiuzMHBv6tWZq4Ywr90YX5rTXLRvW4t+7UjJkxISFfuVKx4iQa6m7B
UBFmJDvarrBK4kCJ7OHAxzU2E0Ocg0xMcWGowVsDCjCk8Mvd3Z+m60KaZPSO4KwfgQmHrbTMl3j1
VvWV5eIapRlEGl2WuZChJWrQtZvBXlmPIspMkq8aWGVUhoGfWlZN03PDgdRdPnHzIGfdJ18xTUMb
R8fnTFkHXMVFLaKtjWmYtY1nJGpRJssh6/Xyfe5G9YbNDHYuJVJgD6IbzcVW28PEso+su1EKyaUs
J6e6XnnT/kLFysVTqtlSK1aUqlY9yK9qUU+m+436o5FMhTJi5NnQ2WMo7+ej1nBkGi9gWjD+r4jB
EM6ac8X0zC+Nq7hnW9jS50tGW1E4XfRLla6FkSSFRq1ZqeUfUawRVQYyJ0FG7l5OgKx3j3cTQv5y
Ju7+0KwR0iC4vECRALFOoOZoHfxYEsLHhw7ouqSGAoTlg866U7xscmaxMM23CJcUw9Nn4/sZnBNq
ioBzS6U1rkdN4oqKdBtbNnLR9rcSj+LvblRN/IS0pCtZpgkqRVVmUhyiO71Ha5MS5vwqrg5hGZJg
GH+k3H5RrCD+vVR1FUDHa1TnKjG4uoTVreu6IMKw1mIM1MjvCYmqiRmAnjoApQHiYMm6Nq9l3SBp
fyBhSnVOq32OwVkO4ZNBrHqQKl4icTTFfrdgsZ5ZGcWi3sws7UTkVWExGtliInIsoQpDFEa1Ml6c
z4qmISr2vJNZQsVsqeN7S2hG0LYlY13BZjZwsiyj42SBv3WZfNmCSj6ahHMbAwsizSUcxLsUCGOA
I0TpExAkJhBAPabMEVeU24FieLMP2NcightFE/CfV+/uly4aiMbv9IaGmWAlclWawQ+o99k6r3W7
1+NgBiMbjTpypRlfB9F3W1ScVZkJSZg3IRsOg5i92YCDwBKG2k1TZkxjmyYwBL06enYlxUMFYOxD
eJierMm2dpWCjUUa/Y7FEjDTK8hJRrxwAycWxRE8w5bh3hETJ+1we190K41moHJOMadG4UqdvxHG
MnVauZcjyru52qMplhqGK7PO5qq4KjG0OHuVzyDB5FTkGQpxTVBBNoWIAhicNDWVoiwpgXSlpiyZ
AFmZyan7/Zcf5tyNEWxjY2FqlI5V0vLyuLmq06DF5UXMpFXZvj52/jIO2yUT4UpaWrVFRMRHfEX6
DFSuJESFFkYUpBAJSlRBanVDzOcj1mNoMXo2fUUWZyCcgBnrIZP3TBHVzn2p6i8ixj6oVljTK1AQ
DasQ1msrQkrkezMGZ+RK9ZfuDIspYLVYpM/sO2McpNODm9kSibpw6fSO51xjqT1P3HKWJ3Ey6qs9
GVsWzifYKxEg5dxtc7vKrKM1yJqG51voVDcogVXdM2xunEcZj0/N8ToYwyLE2GOyRhnLYz85j6Yj
lZKGk7DDVqU2stelUnCQDW7eH/zLMMvH2Dz/AMhy+fE2eke044r09ZAxxFYaazkXSMg4dpmQjsrL
YHNoeNpOxf7YVFd0mkYWKX9qqUezJ+2YOMmPdr0iHeERUISIBcFJJxUM5yz8JtYwu9y2vR8XrvKQ
JIyac6N62HnSblCDxpnHHc9fGNSs+N4i0sZe31fJYTUljR62jouUBjK3esQMJcVLKtA+PugarFh5
sEBIpsYokNtC9zt03bbNM2OempOzTss8cvJKelZSZmJV66HoDlw/lZJKaMQ3uUM25fmO23Exaba9
g21ysvC5daZdsVqnV69BYWx/iNzX431xyBOTow7qPsV1sx0RrjKJT/8ACk2cLP8AjAb93Krtws1S
48xfi/NV0omI7bIXWlVWbcQjKekWndnTN6yX7rJwTdEPoHrStuvzdm+aRUSWQX+hKYynsgJSYyrp
7QEhN1DAxA+Ms1EyBq7zDkioNn8cH2nPL/tBcd5zyfU2OX0e9KoVgwJqSu12/JlEI4izLpPn3txv
sc0KERSLNLZDYXuts5JKLmX7oLGyg2biVgyomgpxuqkrEO1EzkMOY1owTbqbXkcJzGnLEtzqGoDM
c7ax1E1iutoSz46tPq7+SBF43kK9e3M5AVXw+T79WogVZWueKJeBpu+3JziJpfoWoXMYW/FuFMmP
qzGWBSsNLNRxyTJ0uCyHKy/j3gxBrMM6asbKu48Hm/C0pmOk1GPffoQKBthb2N9LGYsrNZmRrjKu
RbSKtcVQVXdwtMXRmzm6TaFgcjX68vY12SU7YI1tFxjh1DMTryLZB20VWbETcImO7CWVQbsuHdF3
jbESWCkJGFKRSocFU5eAsBZhXiNeIa7xEhCCzFKUkqmkTeQkAJGxY6HXOGnuDfSBVXJFqxBXrdbs
T0FHFbu/SECwkX1rjrHclxCnPLIU0myQIg6aqm8DcocqTlBQdiKpiar9KLkVylex8dMLNDGOQrpn
EvH7cxyHBM5QXRQUSMYhzFIYOYRKYwFENxABIvG2kXP+WG6CmPqcnOoOLTYaq4KpY6YxcJW6GKKh
62qWftDUxHsoQonrsaYAdyJAEzJBYoCPEi4JqGoe44tztaaZljPdbhNOlXhZuWr9In7IaIbNZWZf
oOYiaT9fq0eiFTWjZRJV/CxdjKRRhJpnMB20oWwoJMNJPtEGNDm8kBh2RUtm1ZybgcohwYm0ERS1
N7zMJJnLQEEynutfxp/j/R0PsGaXZO4Y/wBGkxdEKVhWBuy9iYUNG0rSGRn05E5anMhMwdolnchV
mBi4V+rYZ1N9OUJ7M2hSKkTmmUSWR6UOi+jsftsIxklibRvMOXVGwrWbDNFLSm827ksqx19Tv9nt
hm9mim1pvNaPVKYVhaZMH81Anss2WvyLs09DAp8eryVeuHajx6Jnr9w77y4cv0k3Lt4I7dURXcNW
bX/2gX/OZoHAGeLTSAyPXcOX6xY9BKTkE7bHVx8/rxWEF/t7+KO4FIqzOA/+pQWMi0/tDp+QtpQl
RUUwzGeYN3UV4S7gpDVmoEFwzODZaJCiJnHvUSGPlCSMpFzR+B+trkdRGMMXNcbwjjTviLTPbsFr
aR4aeseVrFJxcVf6/kZssohPPI3IZ5Qt0tGQDLJKpR9ek4pGuKKJnTTVE5DFDSek2t8xBaQ/RzVC
rld0et2HBD1peMfQ1nVfwrmVrJKGFbJZo9u6MwdWBgLm5mjXCDTvvPYpHxXmJAKg3qYquFbFdsL5
czpHS8OnC4kueOKnZoqSbyjmVfv8jp2aSrspGptHQxyzFo6pcilJNEpExEVZAhFC8xwAWWTG2Wl6
uhdRol7VootXrlpcVa5Y1aUeLO67i8MlMETeQzpFs+/M3CkK7FNF1s3VMRb2OLRbyiPDiQ4UOPDM
QjEtCQVOEgEGQDkEGgcsaSsPZL/qxlqkACoCU0tnkBzO1/8Aqn0uacKLpu1PXnE2I6FJ1DGGE9Ly
eEcqtlJaTczrvLxpwMtWdS0NZhdpa7cQK/XRRmZCMTjYPv78FOz5lOX5rzEBN0oAGR9ovOVADk5z
E/fAm/Ny/EwAJQ+/g0Z7PWpmSwQ5x4pCOK1hqyM6k0sk3UsSsqbF3plTHUyxrBb1e4uObtbZExL1
VJo0XKd+3l3SibdIyixyEGDl7XkiMSOR7AVhi1ZNo0HqMjg7HjQ7RvMFOeIWcunNHTBulKkTUNHK
KmKV8UhzNRVAphBS9woSY6Ts4+ABM9mzAJSC+8kKNAHMmazdyhRB2rxC0Ix8C1e7yzFradTmhGh4
u065Ydt4qEWyjgGM08T7i/YyhbTH43yZW8vx8+naLBGS9itFtJkCCrhoyOI4l4Or1BiwO7ZEWWIL
pMeFOuPT3oX064mx+AYpzRUMyZ7wnTs1Y0m6vYXUrVancU40C2KgyMVerWwWaVJIxgK8XSLebm3E
eVZiQduKYzZVyH4GFbNfbkSACPCGGuEtc+1rhYkvUYV9Bpy7mLdNFQ27okdkYsZ15QJ58ZrfkjI+
RCxRL1kG43YYls7j4ZvcbTZLEqwaqiPeYuKSlHr8zNoh/bESApEt9jgXikZcKOIqoCcSYxGIthZg
l8LZuHnKecjakKBGBIVFKXOupG8hmIFrXda2l7BOAZ/OWJcdYGzHMvsMUXG9hquo+v2qXmK4gtZo
nv8ANy97jJJ4WsQKNhe/m8VO0t8/mkFwBFBr2ns8G5rM0u4xzziM2SJok9AZbwh6L7AmdW9gYOfz
CyFRf5KUk4+Th3Dpyqq8lioz5pG6KyQToEjmJ1ExBIgD88T7O2Y5qvJ0uWzJk2Vq5UGTVvSXWSbS
7rzSPjW/emjBvWRsBodCPaNfzmMFNN8kdD6ZHdP2uNvLaj9QU344SVzvmOwqWCssKdZGcxlW9yyc
5TYs7wjGmWFg+t74bHWGSkhOkUqkgm/qCR5EhTxRTLBzMR7zBUU3dN3j4Q2Nezmo9WoZteDlpgMW
Bdryma48FncHHwausuLStAK6SqS5AAhN1FFEUwAOp1UiCoskQPMyiZA51CAAmKX2jgBd+LAXuN6/
/wDpmQeWI9RyhYDa1LXj+yRx29WWCSanwzW3sW/9YfDvW9rHowzluwLS3Nllat39dGYCJ5lk1DQl
J6jxkIGXgz4L0yM1pGDWiVpWDxaEHYI8HjDsDy7R23s6yBVgX+gFQo9FfoxNz9OIfDLGSRon5KAv
V1HF5pwlm/JqFikhoJrM5LGlVnfVHvXqyLxMkC3ijKeD8xIxQgCIJnLuk93hxkw4ZUoFsRXKRw5C
v7lzMWPhiq/nqCJP1Zz6hBD1AZ+877W9O/R26fpjGM/a6Tbssx1rHQU+10V5Cbc1ORrzVrAg7jrl
jSfRj46NfTUjOS1MlHbS1R8qavsPEhOWGKCrsbPCcHhyFe+ivyZmpoasp2OH1e1vHj1ubHtPXnAQ
UpdVnG6LPKANxyfCMT+sSyknV4aVcVdEu4qxYF4GJhYtWhMKKZoj7xl1DDRGjnSQtYfyhyRYklaf
RruwyWC1I8LFyBjZw2s4OAoJo0KWZsoRYEOyOUwxOyy/lOOxtKYiYXuxtcWWOcSs87j4kmZamy9n
YNYxAs8evgiYjZ4ENAtGYqC4Kb6RIm+5ygJLzFhxI0dUNIQiAQQUTCh7WlDKBAb/AE36tDMOXE7J
sof11eXy593LWsQsdE0ppei9rN+QY3JDKLzVDdIBG2Gp2PCWFWxxmG8fLOaGtPjKhJGw+iCMPMxw
99FMZB5KqEhebnHhgYB0Lw+bdI2ojVM4zZXqiXBjuvNxpMoxlZFOYB6P0vrO8QS/MPGAH/UjwMZ/
xT/5q7twOtPseqGFwVa5GkucmxunqMtElAWqUrzZ2SixFuyBBQcI/QCSFV6zhpa9VhlEsbW4B1Au
J1vJMYiY8UrDxCQUiFr69tqtKyLIbOypcjMNYuffx5ZllWZOcKyTkmsPKOiFLAvpRtHKpSEVHqqG
dqMlE3SCIoHKoJYjFYiJAUQQc6YgdXfDxAJOQa0BH/uqyyHy+n10NrncGYIxczidAFHdqaX2TfUS
ev5Fy8TNOPG05mTJzfK2blcAuqRgm4t6JJSNR9V63DsblTlk5+pPIi/Lt7jIzhZBVNkaE7T6MsLt
lXVTA4aytU29S0r5AvTHKMdk9KUaWnH2IqvvLFycm6ik5hPJDQIoHzdaNTCEtIHrUF32qWJ5PtrM
uCVS1I5apMHWoSGsxPD6bMPJqjSczWqlZLDjeafNe9eL4psc4ykbPj+zuZn9KsZWi2OCex0n/rwS
PJcP05w96dqM1cxEGs6x3dMutqtEWVS921aot7Q7g7JZHZlZM0vmF1CFSjLyvIt268E+bZYkZuFG
CQWhzk9SUzxIHiRrreVlcAVmOqwSMQLBiCwSwSSXJDnQUjIiy65cASDVATq+j6TpkCF0YTuOJHLu
I9P6Nd0/3en2/U5jjxC/5oxVJvMrZFrVxsVCqRKNRWEbFZEjsfIuGpZdJFxL26CcrT90IzTnTO44
iZTfR0w4KwxVtTuXYfFWPHtmYa3siac8eUrVvb2SWOcZUKkVCGzBPvDyFVdW9OYv9nXRVqUS7cLz
TRBJMzNEvMQyfFR1I1hZIx7YlrLWangCOnyXhXJEBMJ4DxupNUu4sFYkI81FehE92r0JBrQrGTaV
1gLqpJSq6AFjQWVIAqKTrSzhXjXiKtB61m+tXy5r5Rt9IzxRGWX6UtkldI7VbJTeCmV1CMr69SIe
vyU4g5hZEIohoVViFYKZ9xeAuHEi3dMIPDu/vE9t2JchgGLO0yAQXBNqru6lgTAYCmow+hsV2tvR
RHQurjE+LsAxB2LLUthvGWeW9SkFDq1TE7XJzu2xtoav7EuErLscQ0VCsp2GTl3iaKULFlGRfPG7
UorBIOkDQNjLKR8/20uTalmpHT7FUKvQEcVrYKfh295pyzPKV+BM9vb6USsL/DGP7JznmbQ8hIGf
uMQdRxFJKthfKWUALhrf1HXaIt0ZL5Ik1lcht3MbYJyPZsIqxP8AGsgxYRkfguPloMjFZhgJFvHI
qhiSFOnT+zsL84VvlWMJmThXVFkrBre3wNdcNp/HuQq45rmUMSWxSQlMdZFh3hVIBJCehyzDZwwl
2C6Sr6BuzF0naqvMpqJVeWeOCHKFfabkViGQMXUKlYakEFYaYZUwWYgElLFiIMONNjJpf/FueMsr
HZqW0cRk7aMAEx5H4mxDc8yVS+U9TFrG82+w0iz5vw9aZqkBG4euZm80w5cq9yhWVFg55zCMELPJ
x0arZln7xsgrH+HdC0vWc64yoOpaBfVJ9Z6JkDJTrDzVaZYXxpXalW7u+rx8pPmjVVhiTH92nas+
ZT1ld29rY6pXkbBZOzqjJ5HuQix3rqtUvb422tsW4tiEqHjKSxpg2p1Zg+haTp6lnLpzMrZJxtCm
sDhqpldOcUmbge/WJpNzpbSyip8ZUIcySgqIT0gGTm1rq96t0VX8o5ASpeQsR3rJFjdnNe8wYgyD
DvoB1RbjYGygKKzMcoefQaZMlG7rJAqHFEFxGMgyPnIiehlrMQXYPhLAqV2mATkQ0yTIs1CDYCEX
hB7ZM20BHVeh89xsUuS/R/VfKjLQzFaea1D03M+qEc0oT1PZ3GzX7T9ExeMLNaUyWuu5eeSEwivO
lpddRPcqzBvLOLiQ2IzrRD7bxZrv0LUPTDpV0g5Fqpb1PXrKM5meIy1bZKMskPUn01VbU6SjjV+s
2ePYydXaADF6yr0rJlRkrxXGbq/SVWRlW6yJBwzDrEsuSKHgbENMqcfibE2nwLyvjSu12yT9hszJ
/kq1yVovEvMZBnO4zU0Z66sDiFj2EWBxcMQOmkQ5SmANtn7WQXM2l/Tfp0VpVpinOn9e5HG4vsoO
rQhkBW+W2Qnp91L1uUhCASReWOwKum5Xc5MKxjMowuxAL2QZd72C4W0gwxD6xcJn1T2QCwmJAaB3
KjWqIMVJcsp2M9WSPuT3Wr6cqJj5bD7PN0Hf2f3unmX/AIvL3eQ8apU5NhP2afMHQQ3DcPtAB3Db
+PC1cyJBEDqplEOVMeY5Q2SMXnKoO4h9GYntgcfZEu4gOw9UK6xygoY6ZSlUECkMYAApxHyKQwhs
YR6bAUREdum+3GAtKD/JWtVO0AGdtOfN2WS3a++nP7G2udrmFfkROHL7hAen4/j79h/iKVNwskru
Ap8oe/mDb+I/gPGJ0qU4CoQvIb4CGw/h/H4j7h8+MQqACAmEggcPMohsYOu2wh5h9o9f58Fwn4jy
3p58XWOD4jy3DXd9HUd+L223L7/L5ee3n8ff5fPjELpA3QhQIO/1R2Af49fu8+nGvAQH6MBAVf3w
Hf8Aj/Xw8uOdontz9Obbbb9r7P8Arx2E/EeW9PPi6tlmxDgUxzFADfVFEQMBv7ol338/IOvv6B04
z7E37PmLtt57hy/jvtv8vL7uNYY6yKQhumApB7Acxdx93T47fEA9/HgHIj5Dv9g7/wAjcWt1tsKO
3mcofb0/nx1uH7g/V5/qh9T97+7/AMXl8+EAP1ih7ZSH+QbD/Ifn/XXjF311sI7k2L9GYemxUP8A
eCO/RP8A4x6fPgMOKVs4AkKcH+1r7Q6Dnk8ie2+j+AfiX/LjiRSAHtF5e3/Ubhty/YA7/wAv58ag
Haw+Rkx+w4D/ACHjtJd4TshUEhwT+oIDuBv7o77G+4R9/l5cX2ideZevLh52Y1PPJ5E94mQClDm+
sPUFB+obz32N5D5+Yb7/AGcc41PbqmHfmECF/Vl325gHoIl+PxEQAf58c4Eyf7h8Bu9RyZkJDyLi
X29fMWOIAUEdg7IR+ACQR/DfjWmMX3lFXy+qHP8Ay3/oONiuoqYvaKFTKPl9EID/ACH+vL7NOJjC
IAUopj8DByiP3CG/4+X38eoV1yH3d/7v3Wz7dCcQ23FAN/LcwBv9ntdeDFyrWWbXS/o+ssdAVtj6
00/L7ewTDGt15pY7HZafna8wK6lxs0SzcSVhZoQMzBtI48o/fEMDMCpmEChsGygnN2IFBM2/kBRA
RHbpt03+O/BSRNHzNadLcpkt3kwwYfxzkFCgReMpS02CQWa2qzIetq0hUac1jzUWEaSTDZ2+mVZe
FmzSnsmZir04JdIC1w+kIZhpCJOAo/KxPgfC0RqniPpYX3J0wFYqYKnMn+rKUomMb+6AbiO3u23+
7jBzF5+x5y+QdPZ/a6lDbffr7g9/u49rpqIqifqBg8w6gJftDpt8fkI8YSio5UAEwTKYe7cqnTlH
l89jAOwiH7XwHz24TEiNA3labWP0nHGB7xoAvdyh66/Y53xnnTHzPIl7mXjh42bU3Ja41ysoUyNb
TAgzbN4vZR+Z4QE0pndFQ3ePYAjNVWjjDdAouaGNAcQUbaNP0ViyYblgrbMzNutNNvljpVMWUyXB
SqRY6tTDi1XNteYUkQYyryvvWiTQFGjlEx66cVo5tk8cZdhMfjOOsWwEJCW/NTWNaRLWtt48ZnwW
B9ZXAC6A0X8rmHxJ8wnPpoggKyx1FdgbgJunEsycdqfnsPTN1lVp9/iyyRMVJT86pK107m2QFUsZ
KxCP7wTvHrvca3XrSyIjHSUm8kWEK/go1tW13zghEw9Iq9XBd16t2ikgj3SRNifN+AZhKyUROKLt
FRVILUDNUTyb9+IYOnCrVy1XRaguMQPMx3q+vIKsYwi4+4OqczgXiM+pKXl/JLtSKrKpRtNSVdmV
UleRrGJqPFTEakMqWwee0KYWvVezZdtOjxrZEl8z1rA2FKy+vMlEsmMo2p0BYredpJyiconcgu1g
jJipwkS9ULBBHyBJZo8OmoCg174VseawzNT5vCzZaQzDDxbtjWG9Zh44XK8ZGVS1R79UkSUVa6rz
Y6jZF9NSyccYjZVg9WcrEK1XOSZcc3fV3giwlo1XrMwhN3CSSyzHUebqcXbkHknXE3UwfI0PGPTy
McRJCFZPUVVGypkEiNHPOoBG6okno693CJD2a7rFX8xSXqJsJNwtMdC5YIqkU7IBJ7+57OKyaSI+
uYRxtaiRq5spWGKyHc700XvDEr6sUulZLuGNLFFV3GhogH82rEpVU0zcJBvIKgZkgs7bHSQSOoUg
l9F2mSVzJEwdVtVpNp2LZK/EW/US1zJi6ws6wjL00ssgaViHUGBaIRzejFraA2g7IFjmKxIJnAgl
wHDfUXnyZqVgijskLElW4i5QczfndRcy1prEPlOdkF7QxkrjHSqiMWa3TDywPCJPE0Rag+5yhspu
OOL1B5Nr+JrDTIDGlIiMeWp/SG96n2WNXLZpeV8ZPWstV4WwP3hwohVQXkWZZ10xhgPZDv0As4sx
dLhaZRF6Khvju95d2oZUw5kFgHehZ2YtYWwjf3VZafJz+ws4cp4WxljawM3ljhMytsYTLK1N6xYK
7asZZFG/WWEm+6wrKtzcdIR0FHQzZz+bSqL9jNXhsv8ARLxxD+xxs/8ARPoLzVpTNOT+63mqQl4i
ccou5uYgK2vcKraLnSK/a1qhZ4Bo5iIp4rGPpSSSdmanKs2WZuyLFIdusBdHMaw8mKEwYsTG1Dqt
Nw5e1ckUmoxFXn4imz1nlJsJ96sk+cSCwJxL4piqpNK0q2TWTMBylEogPEasNQ9iiNSrHUbZqoxe
TbPIn5TV6ojLS9ZiVJdWQRXIxaSQJnn1IZjYnDd3HqEbigLRdGFSH6UiQwUXEdqGZ/Mc8JH5k3mb
MwocVfbSlfF5s3HQ+srQvlGjOMd3u50h2t2y9Vs0/WVVN9x3g53wcjk2+wgmCf7Y7FD3iHkEbJHH
t9th3+Gw7j923T/MfiHEuZtyW5y1k685UeQURX3d7tMpZXdfrpFkmUFJzbpCZURZuF9yOmfaOmw8
xBMT85QHyWT5ojRVL2na8g7/AC3Hr5e74/5+Q8ecWFw72MTgOPNi2mcvWx4fWlTKW4WKnNengcI0
7BlmkbWabcZ6xHTsytWKNcLGxEKwsscKbWJkJxOxOF5qxtj7kM8VhWsaU/siUB2AJGxronyvf7zh
bGkPbsdsrpnOiq36CgXdgn1XlMpS9cXtsc6vsbV6tPM4Z1d6rDMZ+pxsatNWITOEHliiqgkqmqbV
Zv1M0/NWF9N+P06PLRl8wfjprjg9mUnYg8XZ6mfnEqwRAxfiSSzDslRYCEltsmcUx2IbabsG63KH
TMs6f832SlXtpkbGr9VllOx44fw7J1l2qtq+jWYt7NFWnYxFzaHMk4QC2g/lHcbZI1dGbkiMJ5Qj
A2x/9vN4brqVhDAqM5As85S8eAFjIRERD2YQCPiJLtLIbiaaHfaFqRpcu13veSMd1TJlQRTxni95
lO4yy7y4MoT1erMjXYeVYsWkLATc46moqWubWLkqdKNFGjGRjHbFzZEnKEglY09EwHf7+7yPU4/K
9BhKjiq2wsBL2Cy3i1sKJLTs6pYI1nNVtZlBTCDiNetao4VaWKdhK+1cpTLRRJwcrpETzVgDWHQ8
XajNTGWZ6MyWeoZyx5m+kQzGvjEvbozf5Os0TORXrY8krhCtXDGOhYRlImOSTlU03yyBhHmVIIwj
iDN0DSaBqLpsxL5CBllmv1KNqbWutGAxStgq9obySMhbdrfGmjgCKZSLTtISMnwAZZAm/wCcp88w
IFxiIMOJDKAC6SFKJc4Xd2Hdrlau0Og55PIm9YLTtnzI2n6dyu/yvUyYhxva52hQFaumTLGs/kLD
WIZRaVTx1FLoyUKo7OikqrX28jNQC1iTTUUZEcEIYwJL5gbUElg7F+dbvk6Bm6i9hDOcc1aTv8/K
X+CrcNJ+DkmI1lLtUIdhU42V3ZMYSBmHlmJHfUqHIPHcFqKr5dGU5pxkVrwezK6ho3LkERBBBKis
6irS5mrPGCrkLiEvGP3sgsk9TRiag5UUKqmcpTAoURfuV9T9LyRpF024QQJc1b/heSuhJVeXhohS
rL1i52IknDsa3Kku0nJShY5wokmYs7CwIJqHIQwFMYAGIiLtD6whkoxNixKownJw7gOHaZm7A3aK
3ZFNTu9fI2Z+V8VajcfVnGeoe95fCdnrLG48lqsqxylZ53LVRC/VsbPR91Xi6bpnJuqvv3dGJsjp
ZhKfRpFBXpw4rfhXV3h/IVDuB73a3OZcp2ptHQs9j7LM2+yUvkCbI1PIQVgszKwspmMujhOedHlp
SRsEmVIhFDLzZSlMIJdTmeqXmSrac2VSGyNJbF2nnF2ILkNggIhjHSFkocH3E4tm0dYJprY6+i8H
so4JSKQeHh/pk4UUPa4dV71K1qY1Z0HO0DJO0q1B3PGVumHL+DIwVj3EJGwhMhuo6AQVmzA/enIc
rMCI9oqYhilARKYAZu92uEVLxMSJChJeSdWl9XOtpQmMqeFIoxc7p/XkT13+i1rDqmY7dRmjmTYZ
Cl6VZrlfLNF5DZpQb+mRUp2lzsd7trqW7KyxLa7fmltGZK+ZrSn5m0Om73T418bjjWvX840SMpLv
JMnmy612JXoFxptrXkXk1Q3MASOYS0RfkXzhNSoPqsskBplnJqRUW1VTVFymkcphn+j6usSRGtPU
JmS0T9ieY0yUxzlH1h+MXIOY9hG5PsvrtWULXWeU514BI4drJMU4aWjiE9t/AWIOvDwcaqaAjnTR
bdKTlh1VBwjSqTS8x3mPdXGlUQ0PCOIUj+n44joSNaySVIXhElW/qiFNiokSJqB4ZsQdiIRdzdS8
SGkgP/NUA4ZgVASDs5APA2rivtMST3D5efHewb0aN1bMsjZLo2P5S5M75AWI9myekW4QTRuwt9Lt
TSopWGUmLDMtI5eTG3z7lGHl2ShbGuwIp3dmcpTBxytUzW2vJZaeU6o2yWkLBOy1Ny5KP4OvS0hY
7E1kFrLN0+UtV5Ms9tCwS7ZxJLiykZ1dNNussoUpEjmArG+dsJIZR1dNEJzDFzZZJzgnnvGc1kML
fE4zlI1GXyCZvAzr9pCN7CxnUT5FjJaGhVoolYi5OtW3xWygqf8A1iV1TPVDmtXdOybB5GwzHU6g
yOLoy2ev8pMw7NawQteQq2Sc6YfI9XeRT8y79nIvYm5uAZW2eJLN1EKcuDlMTsIuV0VCuyjeUBcc
TSIjhLYd7nPI+89bWTtU/wBCGXb3ju9T+JsGFXzDrpYYonqxTZLKDXFGOvGqdYFq5AqxyNTbzb1x
LWKruLdFMWklXBkF4RkSXYsZQ6pDrolXTKKie8aWa+6i7xjRjN2apqzNAhEYTH0blFfG8USUSRpr
dRtAVlnlk0R4udzDRCSrJdVORFVqZNRNQCCQQCyjPuo2lvdD+Tq5jHJkMlNSeu7KdhQaN7au1ybf
8P2ct5OewzsGnJ9/dR9kLMwZpQs40axbgrQBh4UQKUStfUxlSvuPRgaM6zVrFVI+cYGt0Bf6jXbg
0kLMtU1vFZpkrYaqym1Ss2E9IumsrIC+BKWinblCCUUTWWTRNk3lSEoEJN8iqZTYsKcQmkvnKgIa
rVE7NQURDEbYICPicyDCWYej8ONgZteW9UbnHa761ViXg4G7RUFFzuUz45PWbVk+vs0mr2Eb2fMD
UBkMhEfoEZz5Qscg6LYXkTCrKetXMgYc16zPqOV0947wLe8ZhV8T46uYXWCNLYxkqtLSE9Jt5d09
ZWaxPABi+SmG0y/cSBGKv6dQbuFYUDppKGKXFkpt8qOk9lD1HJDm2Waw4poObcsZQtmXUjQEHj2M
a1sahpwxDAv7dKykXba29uTGUkV0q7Dyjl1GLQSqXaoGRLH+frVOY+0XYzgbZmO55kv+rmXhs72m
UsN/l7WON65XI+djq7SmERZJ+emY6xy7W0JLXOYPIpRskjBvlI/2Ga4p9e4cM4cfSEaI5TVKRN0j
I8uO6YOz2xh+zIbVyNBTweY3tmCeVc35EzFORU1fpNabZRKa7Ct1pEAYUWtQyUimotT6DU4+WJG1
OqM01UTyULErR7N+RRMyr4wGKIyVqn1VZI1QyWO5K71GvUhtjujReP6tD1OImYmLRqsKchE1Viz0
nJO3i3aKpEDqf2lEy9BMUBlzWwyr0BWsQsrpB4wqmpRSHWNl6DxOm2UiAZF8G9WHGS0GMZH1xhlc
OyU9ZK1XV5qJa9mp3uwkAh9px9I0tPr6XvRszt3ZTbS3SuFr8xsHrKmdC1uXUFMVpuEhNA6cqC5e
lXdtUR7cgqFVdIJjsdZIpl4t0i/64LvyYjkMCQMgS0/IOz73DW0n0e8FBY/MdKevCVqnqVcnVOuF
RubUxlJKoz0HZUEm8pKwyz40FIeJFjvF4WSYTrMpXX0QyPfSlKqAJmOB+nG2vNyc3+12a6KM00lL
XOytiKwKurKMGasxIBJLd1ey8w/RkdnX0Juc83sr9GPt7hxpaUeOC4VfxOOdycStZa0zfRMU6btp
SSbDI88g2jnsh4rHuzuSe2CbeKUExNjbCXrxdLP6IccTuoz0hB75JXlzD6a4Nxdq5V4mRaxFnyF4
xIio1JIzpIBIi0a1KHOdWIgDIJlHmEwB14UhwIsVAhQ4pMCQ2LdVyQHGbEz4BqTDMSNd4K8cVLEG
YG7C0zwn5WCXSZrGdaaa9d2ENVXMnKWW24zyDHTEXaXdWeNZzGni/h0dOP4Vm+NNY/lfGX/eKU4O
0j1O7uPzseyU5d831MYksUBkHH1+xdcRoVozobOFSQpttj4K1QMo9ZEibHAP5l3GyKMy0l0FCHZS
EGeKIxKoQSHKBijwfr70WGFInKGXq9JX/Jreo0fTrSNUEB6vN4J5Zj1GQTm1rFVHh5ZRJIltMiom
swmTgEeokqmoTcpwEQwx/ps0q2qoajMuSWY8gscM4hu2IqlW361YiY+wzwZL9cO2c3BkEXb1gSrv
qobw1RoUpJTsFuzE/ZH20YCOk4SbvDh3m7CFBw4VydQUE4QRQdoTbiXBAVC7vGixonYMdicLMKF5
51ehLZ5TZoyznhXGOFs1X6/SjSOn4DVBhHM+OsSxVoZHus4WksLwi8as1bK7ePn7Aq0xCIvlGr9Z
GSVZgmcxzl2CGtLOtPGOGIDWhG5Lrt4kQ1S0IlSixx8Wrps6w5fPLlLqv1m8/Y0CqpHWnHgRCxg5
HB0VgbmOKam0mYC9HBWNQsfkperZheRk1U8k2Sm1E87j2RjIKRptVq4W22Sk7GOpVK2xsrJVL6Vl
WHLNOHnJANp1yzNw/G3ohJxXOVpwpP5oiq67cXOXqWG7YSJcqRmSrFC4/YZLmGUk2NLeL1grOKWr
qVoRhoFyZwnJvzMSkIoImBEg9JrUoRNmoyWoEESGGYIEx1cnchUjMCIxu3VIjxXkAMKay9JcBnap
yrY1hrKySlVMzYWqBlkgX8Et0re2ss2QEnaAsqDagS8SRIUx7QFDzgJiT2gNy9eD2wLrFw3ijGLX
GuQJHUJbnTKmZBqCTukysTzVSbkekKtgzKKlyqGQsb0OY/8AnSmIQEpDSXlHxo8RPpu0SIai4GmT
LLJAVd9cc1qYWYtJKlISzKIucnC+s9elPGWt1F06r0kxAGMhP+CGeVU/0cbWbab2eAOmmTmOkXbA
yiSirBy+YOhbGKcRXRNyLLtgII84Jn2Iocm4EP7JhA3AURLx0SLuLpBRAN47TFSyMRaRVSehBFWD
CzcWAmMxXFJoaA0A5PfobGBhzUDjmmaV9VWCbSS5L3rNFlwVYKTI12vVharRq+J/WcJH1udyV9hJ
JuMiFqL2fgkHYBU7dLl5u2JuaeWvSSUrIVQxvT6NZ8wYihKjpbY4JttGrmOMXTkDerTHtvDQWJOy
96SWY1t6mPiz4QhAeeIAB1YbtNzcDBp49HpkfUdD4fkqDkGgxzjNEpletVaKshbW2ShZjCyFddWe
HllodmshDNZlq7Rcwz5tFz5XiDkqzYyia7k1oddf9F1ne1vcPwKF5xGhZs4YVns402uvJrIsiDuh
1cAF5Cyz1lUzVxlYV9+sA8eSrQd//ib3cRBR0lBU5MNRWXDhImoAmQr1UHgEqYyNh3pcJgIijDau
EPTCA7y47pClp6zr6SKo5OrsVUsaWi74sx4Omiu4bmsVFwnjSzMbLeohsMc8aoTsjYEyRtPcJj4u
SzFULZRkAKJa2Jg24PXL2dcaYK0Z6cHWc65YrHOaitCN5pjWINUGsm6mMpRb+pN63c7yFndR0f4l
U4uynfMZkHUpZIFmcHNdZPEDAoNIN90JXXFLKmP79lvBdMfZFws1zVVYKyXC3s5ibqb4PzKsIS7e
iS1ZLbXg/wCy1ZKwmScf2VjP79y90laqL3pmkdSUpPLzWKMdQFcs5I61TWQ28/GVe1u5KDj5quRl
uqjOJdsnwQz4jpGjTb9A5m8MXcRVQAxoy75FhRoZQpAuxASoIHXJGzAUTRyqTEkkDMi0RLtdUzES
E8i+0I+E60lpJ7Q800j6kXbZGSbYml38W7aBJkVaT1OcmUbG+q5IZKyHA7cfcsAimPXYePoH1IZE
wHh/R3jk+aa7FS9z1Hej8o0DXoRajPZidsWZohBotG5NuMnYI08Ws/g03zJV9dZOwOr80TdtjwUS
/KukJ6WMg6Bsv4pjHi93yFg2t3JDFcHmh5ixfJMtG5EcU6zdGyKCDmDQqFrlG37UNE3WfXL70unB
v6qNCmT75px085yxbf8ALmVa4hprXzLZqhmrLr+/zNBiVVYGLtTnFsW6YM3acbGIy8Ke5tk0YtBR
NiBjDPcuxYVdBC6PhBCEJiY0saYiRe2S9GPs6TJnKmD0Il4l/wDNIEhIGfucH53NGWpzWNjdnH4z
qOMWeGcv1ezaUMe0nOZX2MFXMqwzzXpucJZcl16StjepKHyU7gn8I3UyMJ5gBJEbGldoaC74TWW8
9ej2l0NV10iBwrLY2yLp0odX084Kjcfw7e5YyzHHRakZKv2VLQrHq7j2QipYh3ilqhrO+hX4JnOZ
cwEHitC8+jb1T0Oh2u9WKnQDdCj49ics3mtNLOzXvNMo0k3F01tVthCqC3aN49qBnE6EXLTjdigA
rOzpJhzcDEywVlB3iZhm9GCOGM5TJ7zEzGTB0kJD3AlZqtqPHKsQKLrwQlVsSxjSo/QBJAJRU7To
HQ4t/ReBigwSB1gxM3KIjULu0mPZJFCLWXCusQdVcQGQkc+qCeOfcN9rMtbdtwRbJHJF/wBLlq0W
V7Bc3iPHcRFYgf0aAjMsQljJC90sTTGlYjqUtMUO7JP9pF5NEs0cmgl9OvOkT9rimpxAWBuILrV6
wM0ECGUXWcxEggikmm3F2c6iirchE0yNPzkxjiUpUPpjCCW5uLYL76MS447nbDiuw3OedZqhMSWf
KoKQdHXX07PkqXUS5Fl8foZhmpJCxr34tKOna12qdONWknKhY9RyUDFARdsUVrtYzS2OLBPakFXy
2J1Mmnq/r9a59uvg4YpSUfWMgNLvMxR6E1iElWrlyV2LdAElCqxheQwAGNckXgJvESFGuxZJAhMs
EGQUVKJM64iZkEl8phxUTCY8SNk0QBLTDiWe7gWsQUKlRX/oh7C2VkcdflNiNcZbSmyWmKc2yqnj
ccVU2GCQTjjTZZ+QrY3Vq5bgioWbeiybrFBTZFTlK2tp6Z7ThtGNsFO0zoyMr6IzLmUZR8xx/iGG
twaiKPMXmOpco0noVFhMweUY5oyilVoyHeODyaUk0UBqcjxU1prGmtIlhgtHFY1mJ3yhzNWmsrNs
YFoEG+mJG11+aCtsrCZ9YXjIVmFanypSUa5NBNyHe9hIsFewEjtEx1dD0kMctBlRvinO2PbrIYg0
43DU5elvU3IMYwGBo0OeRsVPj5OcQauRyWydpnSPKlg/BZFYh0zTJjlMAVhwyiF0ghMJCg5VjJIU
/spupSaBkqJjU7YYuA9rbJPxl5ebN9vDdY1MOwbee9DDqlSaIxi83Far6nOseRzEEspoJnWsWEnn
Ysyu+WRYxZ0FSJulEptugdJUpzlEhgK66DYrJlL0QlvqePMW4Znpulaj7qa+HGr1ivyVcxxT9NzG
ScZccyC9qhzluz53HSSMJbHwyjh8tHvUmzdUzNUE6Tq1CWqzu3cZVIuZmngxExan0ZBt5CRVJWq9
Xl5Kwz0kmqqnIuG7eOhWL96+WW7u2ZLoOl1U0FSKCW0NowzAZbF1We3Gh0TImf8AGkjk/FeHrRM3
KJyHkanJKSrOqjXmkRTJSiI2PI6zOQgMbQVtuUC7tTOWQRkkK0DlMp+gQFADFDjKZiykh5BILu9M
2Ak9M+2afjPLfjw3SlPS3IaEENMGqVPULI2FpqEl4GEa4RVTrruUUhzoSwuyrVNzGW+Naysl4jsn
b0p7u6raG3XrQXBDqY8tIClMeY00JLxx9RAUs15dVbKP5AHEY0xC5z0rmiMkphLWEzcWSvuZWjoa
dnNabWV4uwsiTvG8u7g4+wFqqnh5vnjdx0hGLrN3jR0zeIOFiuGsi3WaOUzNnRmLkqKDghFd271M
7RcClEUXRTN1AKsUSgY+EMK5mv1frlbxrnqhV+Zy9H201ZwUfKc7BXbIbWOjJZCQj04KqRFhrLNa
zDASkM0Y5CnIawWSPZxJJorUhkgFno/CcX+lTDJJoolmAEgQCAZnccRDZAjwz/fU/AapZzn9NbWi
zek3R7qkyHnO80paPxBRILWJNUbGk9SJamxWPNUECrF1V4bTxgSpvrbDRsLmNCReO2lRl2jNjTWT
q/skX6/atUCcQliVK7YclnOoeroZdwXp7Y6s5Gl460NY/m8izeT8pZ9x7E1CThqBkxNTkjS0aXaO
a1A2+eXsFtepx0u8rtOq0hPrAkYKMRaXc+5boVbt1cttSqUa0yuOKcRwt3yE4p89actFjohc1cxW
wI4kCLSwShKswGSjUWMUD1FBqMj25iJjDU5qT1Z0Cemq3L5y1H1CyRdxk5q1Q6uVchwD6CviJo5O
XlJ9gF4jHJrEdRpXiKvyJSckU7ICmngMQNqriJuMO7Q4kJMIxzNQJKgGkQZTLhRdxUAJcWH1v7y9
1N3PeNTayrC+keL1GTttznqcxtFY8jMza3qhpTUoWPpKaxBN4rylkoasvNl/Jo2oR4xavR0BeYpu
B52ZYpSNgZd2sfh8qT1i4CtroovD7NOoqgQ0uxb4k0uWa6NMn57uDSQiqPVqtTG8yz8cfx0bKmM9
u1oiFUgqdOrK7uTmpJRODjGjiBMV9wNzHU1n+LfTkpFZyzLGSVss7a52aUi8pXyNlbTbmIshjLVY
ZBjb2Uk5sbbuEHvLSLt0sTw026gdiIg2bHnfL9rjpuGtGWcl2aLtlo9c7dHWC/2ufbT1u/8A6qsL
CUnVYiesn/8AfXzmdk//AN/8ExebiIpiGGg0YMRmKly5MtA+XWNrte5M2WZ+X0+u615WkbHGibI1
B1uZDoFXn42LwDpOgoKp3/PKLG8TcRebFKzyNx1Dq4oh5yXr7Z7DtnEA/qcMwXsX5Oi1RKciiwlh
mSMVIRyHhzC+UqJo0YyVilZK+5vmsy4Nx/k/FuNYmqMMkGi7zVKVg+05SxmY8RPT8MnZZtVpe7rD
NJvK1lqbYYlBzZpeIgSvafank+60d2/fUy12WouZiFka5OLQE7JxKkjXpr/4hr80dtJruJyMl+vr
DDvGU5U7d/6xHy/Xh5BqRzatYoK2nydcXFqr1U9Q4GyPJqSLP1Wp8rhHwSoSbRyVapMeR4+T7tV3
UYgD59YJnxETWiXUmW4d/uBK8cNAxF0hycIwQ0sDOTgq/wBx1JNWVLrmW4TYj0HNLHXujm3aetU1
R02V1OoZl1jw6k6vkGnXOlVS26UISp2PFNoscdYG9uyfIQMvdHlKqajO7y0hb8dRtAqlmrz6HaSl
qc19onbstzq2P9S83pn0L4Uo+KrtqagL7e4/Leo7CVZpNDpeQo5YlumnzCjw1bDGze81/FmPy9tM
5DyFGVF/aFKPaIyOKatT4SNmr7r2rTOtXf1x3F5DkRd1CAtVKrz+cjYS1mb068MJOIulMMWdjZJw
4pk21nnMY+hJ19NRCkSRQYdgCJREN5XtY+fqlM4stNMt8bRpXDcpYJnGr2hUTH2OC1+RsRHxba7I
0oFYiEJFlLpyU/EzMfNO5xpMxkobwmAMks79ZxQ7xcxd8ISFrlI6kgTYvhozF3ebCwsS/jP7Yf8A
x87ExqQ9HNYcL1HC2SKFlerZWxxm5zkSLg5ciR4GTgLHi+0qVe1O5yNrU1ZqcsxUdpKMmUxV7S8k
ju0lGxKuKxDELWHPsTxszLw5XDZ2tHPXceoqiqmq1VBvt2D9mqQwkVbq/wBmumYyZ9tiGHg2sha4
dQ2V8Yw+FH8nDNaJW5O0XJhDUuk1moKRDiwjOTVpfRkhWI9DwCLlZEQmbhBQpl63IzYhLMHvrWPh
4ga9WOZc51DAcTB9Mpvuup9mwiYfs9/48Zl+MCE2CBFS5+ADT7MHza1YURUTNvP008+L6tU5txL9
FzB5huXcNum4hv0+Xu8+o8IFVQ+l8uvluPn/AJ/PbhQDo6hVVDJkARHpv038w9/mPyDrvwkVOIoi
YBSFTz5AMXn36h9XcR3+7z4TsPZfOfAc5cubYDCCYcoCHP7j9Nvs36B/Xw477bcNwIUQ+Pu/Hy44
Bjq/7r7xD+Yjv094fPjAuqomPOUqYp/uAIb/AIef3bbD7+B7Q6Dnk8ic7Mannk8ifR1e0HlEQA23
QB2D3h7txH+HHo5yIiIbbCHnv5h8dw6fZv0/DjB247cvKTn8ufp5fHfy2/rfjh1jACpDdkocfI5R
KYPlsYBEB6/bv1HiNodBzyeRPtmNTzyeRPN2xN+XlDm+HTf8PPjgCBkgADAIrD2JgAQEQJ5biHmB
enn5dA+XGMBOIcoAmJ9/rhsIbfaH8t99unHDHVSFICkLuH1gDz+8PPp/DgN3qOA+ht2zGp55PInm
ETp/UBMfh1AfPz8vd9oD1+7hV2xwTEo9mB0vqFEwAI/3S+Y7h8AH+Gw6zvAbCPIbYPMdh2D7R22D
jMkchCioocph/vAIj/1/n7w47Zo+M8GHyyrvPjwcllCJBOkO5w50gDYoiHNymHbflEfqj+91D577
cc4wAtvsKZREyQikYS7j2hQDcDF28w3DfcB28+o8c4Cx18uHofHdYYhtVRPhu/NjvUcJilsAFE2+
2wbCO/w2AfP4fIfhvxqFSmFYNjB7Q7F229ofgGw9R367efXby4WLuOZLsigkmr22+5jFKO3x67ez
v5iO4fDfjWAruBiAICdJbchw22ENg6lN+0Hx233+fHsYnUZp03c0svsxqeeTyJ4QEA/VqEPydExK
Ypucf+DlEeb4jtv93BjYezRUYLTFqEwXZE7EeRyVY8aXOhP4Bi1e16JnKg5OlKjZXclNQsogvKQq
ajRIsDB2A6wEMUgGAogAbOO0UAVzFIkVL6hEx2E3yAA6jt59Pu8+Cm0sEaytmyPEniIKdmJfA+XH
FVPZIdrYG7aSrDGJuTx6i0kFX6BpBrDV2yJMSkiRV7NVcxAEpFBAlxUrax4e1URGEy0wZMzyyz1N
hr69ZUpuDWHh0yTOqqJlDFAfITDsA/INx2N9w/y49N2ySQogBeoeYB1EPt28vduHXoP2776VRImu
sJSCJCKKpJpgHtHVQ/XJkAOplEf7UgbmT/b240SZTB7QmAD/ALojsYfPfpvvt1/j7tt+EELJLKGG
eU9BSWdqv+ph/ps+Np8WejfvlYndNuSWNRf5AgbTd5SsY8v2J7zU56MTc2B7FWGRl60oTHDp/Wa+
ydR0r6s2ZJWfTNNMG3gTdNR3XhepkMcC5xlqVxPTMa0uEnoemvl69i3KGN7s4UqrxzkqaWfpZNQp
KGM5gVRr0fV1n+UKtab3G2qTr0m+dwEy5IFiFtTTPBm0OU7FuRtUGIqXmZGcl8fWicfwctGRDsyS
spNyNcmWdISOu0l4rurUtpWSUdbiABFKJrD9CcphNLEWjXFL2qWiayE4XXlXWpKX0+NHjK1jUk6O
hHtV4xpOsUA5vXGxzlufxhY2GkwTeP46KXO1RVIgfk9L0ab/ABrqrZohrYO5DUZm8Mu9hZG9Jgrp
EWkBjICcxLg5Ph4VhiCUOzr9hir2wGalQmm8xFw602S10Zk475QpVKcWdkbMEvWaJkJxy2CFnp71
kayRFpsGqSoGNY2zzBher5PyhjOjTFTvOJmenqm4qwFY8jLOmcEZ1GTtWyVaW07PpuId5GknbIfJ
QJSKzxMHM1MQbUhzxT1skqDuWMbxmIs32LGt6XeyEDSshu67Yl684bDIL1+Gk/Bp8a0SZFuo1dFg
vz1iV6HMeR+pucODzpekzTdms+B0cYz2R8cyecsk5K9XYW82StT9hc4SxdV705nbeyjYuMi49o/f
SdGf1+JRtUyyI5scY/tCBjxLJydKOi4l/UgqQiFtAeyQR8Lzqz67zWxlLhKgiIVKBAEgBkB6nw42
KSmWbRY/qt60/t5vHMZR57MuLrPbHDu4ytahXNVlcVwCtnfRVijpiMNeUMb5TlJM8ezm3VuTj2jR
2MAD0G6vIOt2JgG26fMf0iKtUK+pWO6RnVFC3hkmejnUNboPKORbFj4jjEQSBFLGvkZq4rjJ3Y/V
JawyUJLkWnmjNvDlMmP8LpAcWS45CVSjLDE41qNJNfIQ7mzY+lLRdYh7L+oLVOPtzKTNQV0WVt/R
t0M1klCMaz+hK6a3TPscem2grLquK7dkuchZ41jrdyToEXjSCjI+cszed8Maz0pIW+RcT5GUNVi0
V8yeQ7inEtNwurl41Vl2aAOETG0Iy+ko1bpdk0fCon4XYtyzj3rAhoREhbT2iKDphS1U0PCf7SJG
Wq2d5/FGPcZ1TJlXUfx83je32vUPc85uJZrK3HJa8JF4yruPpSWUeZDqkJjmtlrMHcSQ0MxTbXKI
n7NJAjGVuMO4hTWHSc34/b4wXQlrJKQ2PpqYxlRMpS9niZHMWV7qEwlYb7bpOQrNnsFxcRsvepZz
WMZJkklUYqkHrsIuIyzxmRWKI3SCu6xBH5WLYJ4HTjHszfVjKVtBtSowWuTlMeOaMN5NaCv0L4V8
gs7Rbngi1mHKkoYXKXIbaP8AUDpgyHp3sha3ZmchIO2SFfXkbbEVOYRpAr2CtRFqiGVPtck4jG87
IJQ8hFxEm7GMg1UJ6LVrKwlh0DuyhvSImyESLdFQyGklyCerOYy7uOjKFwUCV4WZZpHy+h5o+vSL
qIF1N26TNGkr61gqGD5dSFK3K0dN38rhCjOJpsdqzk0m0a5UlwF8oidNNXYoqCXYBHgAyrk32SDt
B+BNjjv9heb/AKfLpxOWScbStVq+N7epZULNE5VpTu5QEgvHOmxkmUbYZCkHZvokk86QTPFTFYCM
akUc7pMkzp7FAhgCDyKCRUTJlTTANxER2Lt949N/66+7znSC4ovSTFhIhzDYSVE0y7mpUVs1AQ5E
9/iPxayoldqs36MGm3GJpNaQt1d1a2ekXK3MqrXm9rmYydpcvOV6Ns9oiGLmVn2LEXLY5Qk5B6Qp
XCJg9lUgmSvca4oqennT1dEYdG/tLzmWtPMz5SRUZOpmlrxTl4zb4Er0E8sCTuvxDirBOzE7PSEj
Alti7CNXhzLFAhwGjH9YyNYML5UnITJadYxfS7HSGlrpEhYbk3bW6duTe2Nao8aU6sR9lqz903ia
yRjIScm9bCmYhk1FAEogDZp8dkV7BX1SqTUhG1ipx8XaLwsFkfQMKMgawKMILxJm3lI9s/tUu9eT
iUWxbBMPn8PGSKrVJVBk6MnpC83YXgK9jWUsGUEmhbzeXDja7K+M+HD0Hna3QkJgi2+k+oeGZjDW
LofGtXzHfqKWvVqgRUFA2hIAn5SjoWmCayK0ZK+HRMpENXaTBkZvZ/DzlsUCzBIwA3tP9DxrfNYe
qCFlcO4tcssaYFzK9q1TfVBF7QzZGxxdKNBjKeprJ2ZsKEyENOERroR/gVaM9EtddvBMICIWR8Wa
o8dBi/UNYcpS0vfLy4x8rWbNB5Xss1mOGnb/AE5O2UqPl3i6pLDCzEtGqptE1281POXgqEIgCvOQ
DbqXwRrSxTm+BgIubuDbNmbl5yvjLUq7kXslmXduDushVeyW4smo4URPLJKv8iObO+d9qVI6q/jo
EMYGEELdrtEAyYU7J01zfLvtGzGp55PIm8NPBMNT73Vdl2w4ppc/GVdjXJ+vYtkUZJ3HRdAt1vGK
syFXkmYmIxtTFBesHgrI8P4SomynzIKCDN0KbmxtW9PEVovyxmy20wtmu83qNNi6CZoTtkTeY8j5
qh2W6V4UW5WowT9N8rBNVLAZdxMllgUTNEiYDk5oDquB9VTbJ16wlUIqSWuE5UlpbIUZEy8H4ZI4
4aPWMsM5JWOZnUIuTrp15ONLDzEasaNcnkGRWzkwu0O01lRpWqCwtsjabaRA2KWbVGyPL5keiRPg
iRI2xQzpGneNyskoJ3MpMGk5l8xiIpjLA5cRzdwDdM6aKnKNd8hxbubuLnEABBxhJxCYnMNNm3VE
2tcAS/VVlkPk37v3k5fZNwbg3H2g3A2YIeKLP5Fy2azKvrewnbGpLMZqDlu/yNX8CmmyMGnUmUH/
AOIJmVCbbXX8+kZ+wR3TjQ6pcK4SxDhfTWSqxh0snZcxLh3JczcnNumZaMWb3SomkLkazoybdFGM
TaWkTL0o9dFYjGHMo4fm7AXprKJwz+qbJuHnGN0oiw2HDOBbEq+XLFUWHPBY3mJAh1Hh5OyR8THT
ff3JElDykLJyco4IRNQy6BQIbb1fcgahMwYvx1I3mqvJPF2HYGMw9Sbe2ozGEh4thXI88cxpqt0j
DLGmHzBokqsqCp5twgikoqYhSEMIUF4QIgR7PGwPNWEiRwyOjUHHe1iw4eAMIyjRnAl2d/L8HPG8
6U9MkdqVwZp3ZOsjLv5mYrDPINnrb0bi2sUfaaT62Rc5U3hpYzyo2CSd/SSrFpBOaZDwH54s8Taf
SCzNVekTDmIobEdpiJ+w1+v2nIVuo94cRDpHJbGnR9cnVYdVCNskeMfDSdtbpJKgtRSuDM0gTUBQ
5eQ2wtWzPOo9xdKBqUlYNSkz1YGF9Qr/ABtGc1mvPvVmIPCNwaOASMwmv9X01Gxe6rL+wQwB0IYO
NjmLU/nvIVVqFbyPjGIgsbQttsOTG9da063U6Du9jt7qampywSNmM88ekzTp1CGVaQMnF+HdoQRA
nMXfRXH6KiQryn+HLSiCAMQKnUZTZmmSBnuZ7E9mvH9+Af8Ad/j+X79ZEtSND2Ociar9RunULtaY
yGxXjW/ZExxZXLligE6rSndVewqN4BXkJHx7hnY1XbxSvCukDURcHEEva4F+gaVHMxntzgW8wmUX
duk5ts0qjPF0bTJ2NcR5XaL51fpiyWmyNoSNqMKydou4x+4YpxUs1dFcIuFEl3JrO/ITX3kevZvm
M7/kVoLax3LGs7jqfrBF7WSEtNcuMfGRxXqCXiAO+0cNIFqsidMDAqidNQgmIYojqJDXRMykhexu
mOo8zG8Y5oeFWQVS5zNEsdTx9j5mrExlFYXNs38bl4e3IxEebIMdKEbR8oV02FmxEFkhMugdFpiQ
VsoiCBhSXDnMkZPmBoROVgbK+rLQUoM8zk6Z909xm+ZMSstLdyyJl/K+N8DP2+VQxvOWNgnLsJti
xlLPWYuXUj20vX4btVHEsmoySUcJOmCS6R0EzqlUEhDGB2aWNCN/1Fsc1T6XfaHW8O0q33N/a3df
I6j52601vDOpXHjV0E/FPE7cDVJVyu6UQl2ybdNRZRIEyGME04J9I1/o9TU+8xrhSqVODk8jMMlw
UZWplaNmWkUFamKdJVi0XI6bmfusOuVZGT5HEkikaUVTD9ccgDJWIfSnIY9rTmjy2IQfQR5vOTZm
nHzS7BQtFzBYVJFwwlyERIaXka8skrCpPFAUSQYpHTNCEKQwAA3W4guuNEyI6qamZDBmAADEF5lw
GDsrVeYcMQruExqdZbgimncfV5BphTSYOd4y/mqF6ax7rGeMLBk62ObBRpuAxnGDWpWC79REMgN7
CcXN5deMw3g8KNQGDdCzU7vYz8rz1lwXHR1caxpYpmq097xvYqhdMht8bNqJVJ57MXirz0jB2S1J
NroRrGNIWLWYR1PeM14NWafLojKtyHQKLhMDTVgfV3hHA0HZlIvGN+lbZY8W37H8jSrJeCTmLZuY
uEpDiwtzuuSJHzCEe1MIeP8ADmcIyYHkgdNuyKftkhMw0c+4cLojkdNq7LKb6+SOcGeaGs8WJqBK
AlIHp8nRCVRomFmCcOkZaedSRXScGPMgRRcBFMomAF4NyiISraRAp09UpDM/kRKglKdRYqBFQvHg
SToXb3a8HPnSw75mwBesTsaRY5uaq1wrGSIZvP1G80ucf2GvTrVTs++IHfysTGtnko37VPt26LNR
dIFE+0IXnLzbvLOGMj13EOHc4WrI0Rf6rmFxkFrUEI6ctkxLQStDf19nZY+ZTuUFX2qLecfz0FIp
EQLKA4SQ7YgGIZ2ezb3I+Z8fKYTxdg7FTS8HYwjyVuWU7LezMFXtvyXNer/OFer7GcnY6sVGBE5O
/N0VUmti5y+uISvMG6rJWcaDZ9K+nTBdePdntqxHdM5WCwP5Su1mFrjmPyU/p68axp7pC+TMo4PG
IQLZZVObg6+ZFE6apgKQxTCveUXRES/pQlakFnXiU7sk0DjPNq52YaJ+h1E/o0+Z8NcszllxsJcI
lMITLNaI8QRlmvLJRJo5RIXBVY1Ltzvk3UODuZMgmj9KosVoKZEvpDGAob8SutlbNDOwOrm9yXlN
tb59keNdW53fbyNjlEmvN2TaRsKs4FpsDA/ZqchuZdM3IflEeUdpu9Hk8kk9ammZOOSWUTk8sVxv
KNWwvjMXcKsr4bNouWjd68T8JFr9KsscndypfSHOBB34tXd619NGNZ+k0jJ9atEzlfGePNRuKZ/K
y1CjH0zAWy52ivyeKnEdYpuzPL44TqUTFzDVKVg274sD4gUtdUedqHNa63WEbsIovcSDE+BIQUtK
Uy7t9bTeSA36KYr1xOKlLsw1p97U10/NWpefvhGNTzlleIuuW30FQrBYFMx3CFc20rxXw1jGXyxI
zjB6ettmodqMdNP3CBUvpBJydeGGW45MxNJW6mV292OtJnlCR1haUq4PEavY3dTO8TYgmRq9bM7U
3ZnkJwkZLyQppnNIlKiqIql5pwRyZDO814JudqzA0yWlWLJTHlzsUjR5SPhoaCr9o8TkmLRZ8wcW
nIq6kT+aHf2yssRLtymOHlxqso0mUzRmrME1p5rEjkSkBcp2ejXNGi3YRsVEWOU/RKC7B8hFOG5P
9z2nIB9x5ObgMe7phowQbyhZk6jEYgdWct1K7rTAhwRNSQmhLbm113+rtOq6ktRFckn8tV805WhJ
mYkpOWkZNherKSWmJ+Vji1qblHD5Oc75KrKRBiRysxYGr+0AoYqJpEDmAnDsDVnqmezre1LZ1ypJ
2MkgSwMbK7tb9/YGT0GEZCrSkLOTLt88hHjdvANomUNWm7A0jFnTB/6ypGKI2Jejpdaf9Pw3yr63
Md47g1rpk3DJYdDPeMms04Qx/E1fLCFrkK8tYo6YPEoR9mUqPbu6sLNB867kkdQyq6JTWJQOT/Ra
y2TZUjyt6NlKvcY6r2CWcOsb1KNYRU/E4b7dU0U5Ujkm0CVzcvzWRioU7hQkjs0XIDvcnBEQukFY
gq9pBCXBcFx1JTqS8hMSmRKwI14gHs3NZmJgF8g9JZT4m1G2KtWRcSadbRQ6kW2Q2bpPOlfzHAX1
lG0h1W6irHQSMGYYn1kZvZuJtyYOWyZ39dbMI4pnCBRADLEA0YYrrNGvVIsU/ZcBZqytJVBRzJZC
yFRrvIowsKhLulHsE4mYkKvNKxiPc0lXj9aW8QTI1TUXUMCRDGLb7qTh9KsjkeWbaOq5pCl5RjnZ
g+s0femOPzY4PQ7FQaYlBxdafWF68ZVukRdjj7iebj8fsSGYuFIhNzBpqLIgIi0PJD+iej0ylL47
Wr1IvjPVim5TttMyJIQ13koNSlTVbfrxbBC1splasoIKpwTBF9HKMjEVJLEESmIoJkwCIN3i3m8Q
1bIBklQeZSBicsGcEiZ0FiBS1n9IYpPMtMM4DcO5hpYLsW6zs54If47HFFmUr8XiGxZWtGL4ywxU
RZggXGVmsfC3Qrxd0oiEmaTJXUgbgYVBjt/2eHfVvSSamaZWavXo2Vq7uQoVHs2MKHe7BX2c3kKm
0u6BvN16s2d0ogq3Sa7B3N6+Q5dg9g3Fr2gfSppWy/hLB8yNFqOQbfF421QZFzm4dPFJB+3vdIkq
zE4qr1jjn6qa54BnXp53IIxSKaVcmXyap0HqxiH2+bZ6kmk6Ogou1IZNUplCHVTKYhTJnUKY5TGA
SgZNNQ4CbYBIQ5g6FMPAr0Lzdz1VYjJQpLEZGQebKLycEl5liDBE/nw0mrzz6ufHwzsac7rqyXea
NWqRkOi4byY/pONnOJqHc8hUNtbrtVKUsbsyEr72bdOIhvLMjABI6wv4r1iEwAVNoIhtxKbv0oub
bBjKUxRda/QbNA2TDELg63PF49/Hz1qp1UftpDG03IFaSycUWw46dNpBGuljCFXfrTTYkj2p3aRT
mPgb0dmGrhoylbhantasmW7NgO856xbP4wlpl2ojI1GQ7VHGtkVlZfwabtUIQf8AWSkR9VMaKADG
fzyBdjDENkwhorx5pB0uZmypQM8wtm1N49yq2j5vHM6rMoVi84nkoeEZWFOFtdpr8OuyvRrEM1LN
CuTNGrKAkHlFgX7di4VTmJD6ThbbaX6A0ZTMQDhUMMTqOHLFIU8+skEFwLBWjo9QYwiM5KVmUzrz
LuHfLOvSRzrCorZXwXiq3ZWjcTV7EbDK9h8WlZWJiIsRFtYIKjEO3pFcuKv9laUG7h4b9lltwRkV
6XmXj8WxmKIvBlXb1qC0sWvSvF818m5dwVhanUW4UtaxZBFE5ZdRtBNXQRym7kyKqaoE7IxOF+dt
FunrClZxfWmtQ1F5TvN80qRWoL8oOPVYabgIWYk+074rLUICxsHB0SH7JQZV+hZJ20MuQ/ijaeAh
tjBsGibFmp/RNpMsALEx/kyr6Js15gRsNfq9ZSiburje04572wvzxNUlitshNwM48QFy6kEzR6KS
qxzp7qAWt4hX1EKEqLEuzFQwIQtRSGF5UknC+EDbkAlg6UipIPbPo7+0QdcZ+Xx+/wD+te2dvSZu
M7Vm7O7LTMgMsi3vDsFiSZLCZruEDiRkmyZjFSF1jMXQasfHzloXRET90uD2RjRJ7XZiG4gFbPVr
qCb4SaadUskWhPFDS3GuLWueLvCyAOHlPZ1kIDxgZ4DjUQYV0HBKB2g0wG/OqCQE5jcDm4T7MRA6
hUxKAmEDmAolKVXsTCICO4AC30Qj7lfYEQN7PB6rY2jC+jPbZhbN6gEkXWZZMbTjpXHldC8iiXE2
N5dgyY5OF+EwelNEpRq+NSE2YsiXRSdkhchGoOeVJUS+RoiFKIhMyUJTQMkUeYASDpKzCId0u7YF
qiuz4gNU1bdmdd8iasvpTkcgQ1jyDbYfJymdZvAc9iVnWIG4d00zp2yzxE9jmY1BFx84ku+hfnGN
peFixjwZdiMsx7kEz25OzBnMte+J4bTpNaTIKo5fVxw8wo6iC5Wkbs7QzYfMZ3Eu9iYuUbMbS4rE
jpZeSziNF1iCMKMYeMlbfODFDOyaTGz9yfoySq42tORajmMXxa9o7i9bLSNttHSjEHuPD+t0ZYau
vLsbrMvITIAy9PtLhiwYQlgrxzqwwJ2cTrIgMFr4xaIejmZZRa1mhhJm1qzVIfWtVjLlyoiUuF8f
zzCtt54Zjwefx60hJ57JnjZXu7wjwrhT6xZAbHpRL30glAhxVQiAQgFISWKXdOiSGUMsw0zZYi7O
6CqHQyH+OuXd922aGozCIejtf6SVhy0nlR9qLPqJQmk6LQgx6CqVDqWOlKyEoGXQuHYJyFdRcqT4
VvxQnQTVYOnEWOdRKEHpWq+DMYvbVTbZM3/J0jn6cjgJGQuWqhLRcAOOKNYJWKlFrHcq9BBFzAy9
SsENHVtqEgUYNy/BUOZzZew1jKq6Q9NeTK/Kv314ydkDOwWBZ9WVoZCUYU5HHlaha8idCYmSoR8A
xayE8SQLslIO5hssBzd6SE/iE0DZsn9I77WLGnobzG0PaBrLmB9aY4lzLHhANLd6wKR5XHh5GHhT
5k3CPPNFuAldthCo7Lp8yS0R4cWLDCg14ImZMokHqjMkuc3Z+FsG88t6fTSejuGo2s0zEcPhjS8r
e6BV7LVXf5f8gzKVdq2TsvW6x87Wfqz2XqE1KOA08xzJNBpV8dvJd0ym3Tu7yFyjWlneDG2Q7kvS
U0WcyBpDyU/IFWiNOGLcL1i544b41rdvu2QrXp+eXqUpL6kZbexZHNNgrgvdBLaWh5WDZVQ8fZys
oK2GdECxTwp6K6kU6qUCm2qJZWuyZQw+4nWWeI7JsjBP6fmy3US13irRMfiB5KkGWxLVYGlxqVvn
kSKWSYmDTqDFDvDV2ROq+A0IZtt0DCXymLUyy4reUu03a0ZohrDLHxdioKQWRPZqRk+yv4CFnIC4
V4kO1O9r6UNKyz0tqhjUdpIhLMhcPRT0nATDKihaSA0mBC0gFwGfEklyQWBeT2pihiWNQo9Pl+n2
sWGHtY+nivYLv9My1GzFw1CXiRvE5gnPR6RBWo+itvJtBNQa1U7JaU3OQmsdWLcynbQ/e4/SeMaM
MypY6JCTFtm7TNTcT1LI2MKbg2uQGJs+YUpWXshO7ZaNQeeMlVjKCucK6tJBJwzHEmI59jji3SMb
QJ6CbC8slthZ+GtVvkb5Kd8RZqRKvIr06aUsF54xTcrK0jcuMXlCw7mK3XvLD+344halXspY6o0j
kOGr0PhxGRmrzZscqsJikNXsq8cQNpA4ySajYvKoJXRi70bitwqWGkp9jl+XvGoGFq9iqt5xZB1u
w4UxNXsyW11iXDhcxy1gNB3JR1IZZibvJ5G9WmygwWOixz6v+ttxErLhlaLxAnsoYJIVNSsJOAqI
DyACUKWQliCCos/WhQgRG/VXlRIf3fq4E929nvpy1XYfiMbaVk7K406+IafBt0BkyL1FVeWsd5jI
KyZdi8sEylpbkYqOsiTPIDSNPNRcas5k6w8PaGUW/REWxk7LxXLr71CVHVDq1zXnihRk9EVLIVha
2GuRVtYxbKaZxLSGhGSJ5KKgpmYikHkpIJHkHQKzRTKJEOsPsFEwa1hpryXPZ/n9N0ASEnLvWbnY
qzOyzAZZjRIRpS5NVpY71L2BwgLuNpdejm67ucur2JRJEtUVXD+AbopHOWace6GlrbS8W2ey3Ozp
vM2X22VHHBccUD8qEXFR9OtLapWbI+T59O4VVem42a228x6aMlWYaxT6cexcCKIEK+9ZMmPd7/0x
sTsYaPZwWZR6w6pLvLSk6a2ouHd0M0dZMpEAfDz6ObVpAqcQKYAESnDchg6gcOTtNyiBdjB2f0nT
f2Pa+r14QlVAwblEhgASgIlHcAE5ElCBuAj1OmuioUPMxFkjBuVQgia+pPRLnfTNeLJTMjU9R6Wu
3NHGx7vVmjyz0qw2txDsLIhB1qTVQBx42s0loqOSi7HENn6i0mwRI3Md62KpIcP6OLMJsWR+T8ju
22ME5HUbU9MEbSbpB3F9kI93t0JXbPHTkrXEHKJK7QCsLm1YkfNpOdsBjxrtMtZEUZALHlQ7hFjf
y0AuWD5yCpNqATpxcuxtJSvEGQEsX+GnePG1b4LAZQpwMAkOQTkMAgJTkAyaYiUwdDFA6qRBOAiH
MomG+5y7+U3QAJAExQFXYUgEwAKnN5CmG4CffyDl8w+PFkbv0YeoxfWXJ6JIRCr2/JFfm67HWe31
uVnXOOqtH2hlXl2Nqsc5JVsjiFrUM1WSg5Qk1EvrfJWxVOIqLO7SRytxEfUTgq0ab80ZMwZdJKAl
rTjK2yFPssrUnci9rMg6Yb7dwevUoaSljl95ZOEbGDyEAHha93RUGEIiyEqYKZBcEOJjUEiZEtLL
Q1FYmGct5tzxtB/eCdPb8/L2g6/Z7XX7uHbR4tjY7TAwz95FQzV9LNGy84sJytGbVxt267jtDFSQ
RTD9YqoJSEEfaMHlwxRIAAkI9ADzH3B8xHy+Q7+/jhlOUN01zIKk/VmTNtz9f2RAQA3T3F3/AB24
rd4qIEQRGCzJ0k9V+rOU336dzitZbmLPenSsYRumDcK47QlZ61Hj4uVy4/ZRpZdGLj7TX7YUsZKd
uMtKJSC8XLw74ZJFsXw+QIU48ioANZ7ldQQ5QKIn8u0ABEPP3CHT7fL3ceDuTmMqUpwMYdtigO5h
+wAERHjUHUVN9VQDf3Tb/LYNh/77eY8N3m+Xi89pYTuCQdKvWlqw07Ohfj3+ptn5lf1nbIdn58va
E/lv/Hb5eXCb+05v2f3vd9b4+XHYCoZPlKUgm8uUOpvL90B32/7778dfS78u6fL+9zhy+f73l5/P
y/DhbqfF5cPXmT2t0YQS+qIfcPx89/P4fP3cYQ9sOY3QNvMwBt5/h9/HShyDvsco+yPkYB+Pz46B
RMUdgUII8vkByiPn8N+AdT4j5bvXmT9bwBij1Au4fEAAeMCSqm/KIEA37oiG/wAfIev2dPw4yiYq
a/aFMAp7bgXcBEQ28wAPd08+oeY78Yucnadpyjvtvt7tvj9nz8vv68Vt1splQHblHsuYNy8wgURD
4hzCG4efUBH3/AeOKmOG6Ym+l95t+nx8/mH4D58eAE5ebnKmftEdkthAeyH4G/dH3iA7b/D4eAVV
OAHMZIDm+qBjFATfYAiAiPzAP5cQgYKTpXcGt1swHIIqpgYglHyEDAID8NhDcB2H4dOnlx3zk5uz
6bbfd/2+flwkEpCDylMUR+ADv0Dy6biPGYDEEvaAG4+fTqG3w/rrt+HC89fLh+fHdbrLUzrGD2CF
L8eYNv8AIR/7eW3HOPCYG6+2Hz6h0+3fb+P3deOcTbrGy5dHEOUEimU/fAA2/EP49d/L3cJERDfz
DzH3h8OPKqg+z/xB7IB+18i/H57b/wCHCMVBJ9CQAEfeoXqXYf8AiDp7g6bj/hx6xcQrZwA3P3sv
bOsY6HtmN2iYeZA6iPz289g+/b+PBGaZqZfsjZgx9TMV21tRb7cnkvDwNweTM1XiMPE4OUbOWK03
AtHlni2byJavmMmWJjnJSGmGqawALpEDjKocVEfaOXyD9oPh8N/P3/Db4cTVhfJKuIso4syWcVe7
0O8VaySSbMBMutGQsv4hOtmwE3McJCM/MQAoD2h9kgAR2DiLkAm+4VKZHxy3Sak6O/0sKInA7F5E
z4A2z5Bi3lcudogZWfjbHNRs4+iJ2fjAk3Teafxi/dpTs3ttRj5Fwodz+bqFl27QwL/QmAFNy8MQ
7lNIvbKbJ/M4gTr9ptg8+m+23z93D81L5Ap1/wA1ZJvmP2E0xqVxt8nZomHsqDSPsDQJp6Eso27l
HzczFlUFYQLyeN83OYA5eYQDiFxcJrj3hU5zqf7nzS+fTqHw6befu8h4WvaocNV5S5SuCQwAHWDh
8WjVccKtZeGvHDMMgCvWclWWshl4WmHG9ps9YvFRsePXKjW5x89GKVFw1bnk129kW6xDSPYgWaVl
JAm/0bVsRVwP7KY+8zph/rPqOabpi+V8YQzEeTjbrdKROsqlOxrK1taw0mUsguICScPaJDyxomQY
PiWJyghaTSL1pyygqOEeet6rWObr81HzMDOSEJORbggxthipF9GS8YuT/YJRtJN5Fd3Gumu3tHhm
roxPeIe+1tXWTQZLOOT8gSj+FyGhmfCeFK5JDfoayydT/KTikMad9dX1gZs2sE3Azdoo8oyY3KJN
LyjCRfFk5hDwZQN/Q9DxEezDHfIkEMOwlJMwlqmnGhMiGL0ihCz+lDSZM5erB2A5YGhsHl+sWTYK
WyBWckxqLm7WGZjV7w9u0Q0l8lt5eKfkXIVtbpo7yYr65EVUlnycTYV1JRNQijwLMQxTDK9Puupn
HKOIsww9ZnYmJwvV0Usf3B1S1yVxnSJ8ZYot5SRUQLGysTahvkwUJyccNWj8ZpsVJdUXiXaNzPWQ
KtmHJDibjrNWSla43pLGx2FghbmFXmbLTKXDQssjXknbMJ90a0OklKvXJCyQbfxJwmo/uB2ipDCE
x45yvRKTpkmJB7bzX3K2S8pY6ot0xxb3cnPIQmBsUSMffIE0bESZH8G9PJSdcSgeadO8ZR7XZGuQ
ch9USXaAVX68w09ICAmCBhCcPWdq4s6U3W7D+gTs0NLM5YfQ2a8rqhycROHirLj6stKUfH8nTUMd
Na/KVuAl6lkC9EvgOmIR80adenstqUJZIAyEqoBXByRDITqGBPiao70jGbY2zyMjO4xrM4RrdceZ
Bgqg4bXOOQrNpxnR4fF1ffpd6eyVsKgeBiI9WWYy7kfE5V02RUKdZZIpjzdXvRjYNR8BqJd5EpkZ
LOciqR1IZxN4kzkdUSa05WWsRs84av5CWcYuCoXl5HxkC3BhDpwrmIcylY78o2VMQNoqmQslnvCd
dgM+z+NHOd4+wy+oJ1A5if2NauqYxmsiTEEwmrurPrwdvc36l1GvLQLe5zswrEvZONF+UwvWvasR
IURH/wCUOVcLjs7zMNV2pusOApGDBsksMwTu4/W0ITOt6y2CFRazmP4BS8RtdyvUYiwtX0nGQzOM
znZ39hnWD7HPYpx7h5W5q6SL6qvFJMTmAYBRoYQdNBUXZK1zusiYuytRZ6nSKlyzRFYLZ2CcdWsr
2t19nh5hDRjaSrNPMQzlotcW9ZgVJFTxqW7ym7lDiY5SKiBvQ2XHWt5Ww0JpV5HFkHJ57MlJZIxf
kKvRszCNJ+nx9ehIyzVxR7FTc/VWcdXEbBcJ17INGDhwALsXBQDn4giq09rM6DtYlSb48pE8pg7M
NMkatmWt0SO8fu0RM5CTgJl85v4rKObpFtIdZJ81boyxUO4qpuQHsDlUG94Vf1QhEhdIQ490FYi8
AiChMkymwrxILE2hvkGXlh9OWLgllzMFYvmINO2M67X5yOlsLVO7RklYJeUYvF7Atc77JXJ2nEot
RFxEx8YvPujNVJiUl0ychxKIcpthTdqJnMsRMAA/X2f2g8/2fMPd5B/hxaRL0iGs3oz42+NaTDN7
LQNSkjASNzCssm89MREvXVztWY28Ykr+yxjSYbOY06k5JSSKcg3WZiIOElEy1cuikKssRMnMoPkc
obgID8Ntw/rqHHmL4le02i4iohAcBQDPLwtpXeo4D6GxIYPyhTqzSc4UC4IWTuOUYCltIZ5VYaOs
SzO2U2yspZm4nmlgu8AYi5oZ5PtyFgC2I4lfbAGx+rirWboFfA9lwXbYl40jEbChfqLZKYxYs5Be
6kK+rSDPJLdObi4ux14a/ZThGzPe5uWq7w4QVaaO6oIQ4yv6OOh1G+XvUDE2mo028rR+kLMMzVYm
9VmEudeY2uCf4/mYuZJCzDRxGFkGsHHyiQmKyBQiUmkYfYXIJo7wVjyn3X8q1+vkJJ5Cb49qy8yl
jOkTjmuWuZl59Qse0udgPFpOXLPGkOrIOI29uqzIOZgVDUqAb1pKvvLS9aacIdIRrtdjCjXcmOQC
SWKaUNTKU95lK17PDOuomlZGf6e5el+OMpvFuD8EY5tTSxQMe3j3tzxZDQ0Y+WatY2wzZbHX1ZBJ
VvFjKEReLRSR1EYUyRTCE6VDVpTobX9Cak0pZ2xxz+VeeuMk5lqm4GWb1q0Npl3LtYetpGnV2kk5
aKpOhSSRK+O3UTW8b7M5TDizFhrCFG0IacsiV6oMHt0y42ur6WubqXk3s0zs1Xt/hrxkMfJkQgSV
JpB/6rvo8zgs43IISklOWAAFQdfqXxBgSk1PTDSa9HtazasmY0wFdLLk2NmZB9Dv61kmkovskWGb
iZwEF2cswvLltMRjCs95U7m4RiCkDtU0zPoT0iiJsva4LEGoFAQMsp0LODTqkWr1/hHLevMnfenj
U7iOk6ntU+QLrZo5lQco4rz3QanJyVRNMRCgWm0VCTpsaemkjpZOEbHia+2aAkZimEXzEJyk3ABh
7TvnNnTaxq7Qnr9EwNqyDSazKUSzTScy7u07kCLuRwZvKzYTJycoyk5eGTUery4t4qHVkkzgBhUK
O0yvtKWnK+67se6S6dN3GqU6OuklQr9OPrEEm7sJa14+MUeoSMsVB8wkrT4XG86TqEFavC7aeroP
u8I8+oxJpHwLlbVJnDD7ORuMNRcR41y3e1WqE3WGs5OWfG8xXK3LQ0bOSruTaTkSs7mX0jGWeQUR
mJlFu4Wkm1PIkoYsQRfoOIvDWSASSnCWJ6rln1ABpOVhPD+NVdA3uP8AU8i2opuo0kdoDyJQI/JU
HWMkSmplpeU2DOalGeTrlTZ6lzEDc5Z84jZBdV6yGwLoi/QB+o3lF1004gRVUKUztzxm2sS/o3tK
+PIC2U5jcK9YrpC3OmQdueL2RtT1ZSWtEI7n6k1lDj4baJJy1sDhR6UkmzsS6Be0CJVIQwt4bwfi
zKUtqXuL2xXOFxFhSGjZ2FGMGpKZAm29mthoCBnpaFnbK3Zy6FfiBO4treLmTpzkoZRJhusLwtl5
TdLUDK6c8m6lbTeZSv1WEy3+SLH8UzrEbISE3NIQtptDd/c0C2A6jGMVY15Bii4hAsCKh/YIYxug
BxdIezhZ2Y64IMnBLIEz8TswqT4tQ0QlduKtMsgN2Znq+ct5sWWtDLMW4xZ6OxlUrpUjQsNgPToN
urze4nu0dAXSgxddCYPaccIyYwDR3XBl5EJRKTaIrTvdXQLlP3dXlkXWdb4icwfk18ReKdKG1lw9
wocvL2prkBxk2Jn8fXmSJZqjFPZd2SrUNg6YQ6S9OVhgoqK0gxIpHFM7QBQBrhoweY40n431Q2iz
ESQzJIToUypRNbXPGuoyGllWJWNgn3RzOVLhJsU13DRrHwoVxy3I4WStCiRXxrItvOjeSoOPZ7IZ
Lcs9Sq9SxhbFZU9QeQ9LtDDJ0WZ7FR+JrmFgWfXCYjnpDlMzn4GvOU4UpnApg2KJwYES/m7X+77O
EQGGMTW4LEZ5hjWdaWqbvd3/AJkTJnP+Dc7uNraqwhL1vXD6PS+2WFiIlpkTT1h2kW9nHta7ERAW
t3hoUZOqvK81TYtknzKye28iloYsE2X+jWjE1fZ4hPN2iNWBzYo8xHkR9jCPnMU27NWWoWkEUkMp
1HHcLcUYKfr2M49m9SVkJm1zztFzDryruAVShXJXDfdBV0ezBVctF2SsdoaXjvcs0+Z/0n4+vydM
f1p1YnUPTTTL1KCbltrpJ0wCTlW5lkkF0K9HlXKqoRJ6SwnMUosvIGG8t4Oy3fqTfspNcTTNMb2R
o/yLbpnIUFH22NqtjdM004F3WELLOS8FZ38C1kaszYouG8okomtbQakOUwiTFSyQLjNsJkpzgZKm
YhmUQ5YgTGb2kwLz7l8RDEqKBl1avu8W32OHF1bhL5lzVWlmjBM/XaHYNLsNkfHFWfQVViMo+q8L
eseVun5DVVYnlkzZNnqlOu5jIU5MIs5uQWSVcM3/ACEOcsm4jwPiHE8HC1C6Umi2NGvekMq2OHNp
ToVTu90uFNstSmTscc3cJ5u3UhKQ1KoknMsoiSnF2tgUTZuIIjs4JiE1Y0katbPb4l7RM3wju627
Sx/pFxchGZMyoyuFlwOzfwS8bDyR2cS7lnEi8RmIRVpj2bYNIdwky7RJQ5C78AswyDn6l2iyrQV2
y/AWuWlxkba7q1pyFC2GSsbd0myaStncREsSYfTDB4qk0VkpVw6WRdKJoHOVVQpBJCvcG7Pt7iqJ
QsoH5QwbcDnIvUACxoUGKpmvMJNJhdXwnXdTcNZXyt9JuLNQWLMv4qr9Nx7izLsZ6RDMGKqVaqxU
6ywRjY+EgskTMVj+03GOrrKzSmO2x4p2ItmTLtSiSCHwMO3bCcY5XHte1Fo0bAGn/G2M8dZHxDpu
lITNU/ecA01n+VW84ZeeqOTLbUcwNSTFrsj+clfzhrNLRxbDOG6zzNkPAL0lzqkjMQXnOVKzhfa9
ToTLDBjboqEy/dYyyhky4xM1LN7UaCj5xk2TcuIaLmG8hbzqlnilkCAqgAKBzQwx1CZ8hUfCo/NO
TWBRiJSqgzZXaxNxcVudcFcyMEs3LNgiMDOyyib93TxdjHqkUIqMYJRAwpRIkFjeItyiJdv00pJS
TIDeNWy7rGEONL9eDl73+HPhutPEtj3FuUNOqmTqLEsMUS2FFa7U8hJ2qYmJCGzVZJ7tvAnuNEFp
STcP7vC+r8yFzg3gwtXh/FKz4muh4kx7VXOMKrb9EVbvqNGqVbttSzpI45lLRW4gyU7N11fHUNMQ
b2xKrzgt5JUiiSniJ2G4JCmcVRLyG2GGxPcxp48pTKxluCWL0FZ8mN2kqis0qRHPOmS1lq7BKQSg
3Dx4oqmS0yEY3kzWYyhCzh5QTlAXyvH6hnmnkjsY1dDT1G3FpImUjGVVj4RK9v27tswdy4wTplZp
eyPYlg+Ys5GyoPY5yZk7SR5xbLAQG1h7OOj2aIdvVRSXFGao/YGtGRDXL/UQsve0w+nLyHlCTdx8
gk+jnKqEg2OHYPkFnbeQI8N5Ls3keYh2fN7jEMXfzAdh49O5Z2/WdOXrp84eKkXUdLO1jvnTgVPq
O3LownN30+/sgY3Ob3APGSDWgyzcctam8irV0XbYbE2hHaDOcUgyjuZRhIvxlGyjoPeVMRMHXfgl
JlfR47JAlr9a1AQrQ8s1UnllLJSZo414QWEEKiaSj0u7v+Vu4HsnQmUEEFvZ5UlBLnw4C4nZiLwu
OqGIaU+fSzK1JQx7R30qJy/amhtodN+n+76oclMcSY/fVZtbZhjJSUAys87KsWU56vtu+yTOJcR0
BNgmsoz3dnRsxmpytfzgxQR9vguoj0c2p6FZyFrg7NRoOntMQJZqe5RY3echKWWjjMdlHO11Qhkb
W7nEFd0vCTVwVwV+j7Ln9njWaU88aTtMuqbDWb4RTUM5rVNlZxS3x9phqRLyT9i+gyQcaSpowljj
HbkrvtU03g2KSbgJlCFNuJygZ0zPpPs3R7+VqEpSqm8xU8xMGCXWMZKKlq2ijQ03AzbVyrIkk5e1
Jyi4e2gQ7wqipPaTAxevGhBg9HwEEqhFSwEOFqLOT1gGniAAYuzqBLsQUoyI0VvZgC+9mocu7MUl
aJ6rpqul61a4u0+5MyIxsbq5SEDHjcaJdom2CavSqHiqbamzdmeQsW7kF1/ZSQnlkFVFPZIUwjwF
9gamh5OSiTpqEFi9eswMmqIAUyZ+Q5BEB6GTOHIco7CQ+5RAB6cFBStUUDUNS2M9QdZwjSaxG4sm
ICXhMYY/FSBhFVYeL2ZuXtjduXM4Q7v/AOaJY6QTsiP/AIcyHiF5R5R73cbfYJKTNj5nMTy8zGwq
NdnLSj2DmSKZ8ikvHSSoHGDKoQ0aUgiMqByCl2gHARSjpgqGJGMILTCjmztOQHpnR+AmMmFiiRv1
Aww4UtlnXT60laQcX6WNQWcKRZL9jPF9mvVUqVgjqpKrQTWOlngz0imoqzgWMKDjxOSRcIpqKzjt
FNQYFNNRR2KBSGEHQ40TasGfizxxgvJKpoS8fkyenSrq8y9a3Ps2i3gIjGSirt2j2L9gr3XuRoPs
3rRQXwEcoicqdEWv6taIWb+tJxcjkmAlrpJ3Dxaqu5KjmdA+xpNUiPg1Y6xIJcxm9iUTmweCXcET
kcc3IYphNp36bLHrm73exIY4ylEI2+KyQyZs6/Y4dN00m7XjLFtKrsuZwMtGM05Wvz9PeTriUHZR
ohLN3ShyEcJHOZN1uSoZQhcSMwdyrCokAMAHZ95IrOVVo6o0OJhgQkBEuu5o4q0pzHnwqww+/wBc
eO2VqqeGK9kmKOwdWWn2RauURmjaopeZKCmQYVlajJjbE5GdIwh1LQwhTvHSRZBgZikkDxuKnjD2
BsvWfDrPJMZljD1BojixXuvVOMyasm3Wslox1FVqw2COh3C9JtcfH9+bzj2Lim72xCo5cIrt0CHU
TOQCs1KekTwnqNtdYfKDqTw1BU3OWWsqQ0tipxTELrJxOSmFHQFuEo4u0DG1K2QS1WXSbvY01sj0
lZtkn0M8RBQLJ3UlVpXRjWdO4S+SfXSuZ4tWTwau2bFTHpapYK3D1pGMayrO3hKGklHhHEhJNiVI
VU0iuVlSFKV+aynRsIV3EaNeFxYpIBQsJZIDBJBSHORaTOZlnNcN4i9pCUUch/lyOuo8SLDrCvcu
tQjFqovkNjHryc3HxQ1cliatkpRVBB1Z20QtWk2sYuZy2dNnE5DNhOs2QcILO0SJrJmM1p7I17sk
LXa3arhabFXqskshW4CwzspNRFfI5/WDBQkjJv4eAB9/58YFZwAdO09/H1HaIsh06V0aY2sMhFx1
IjsSaM9Vlae2l67oxIgcizdgoTaHsTeUa2BeSir2tEiVjANJeGTnXxjgkzmFhECm+eGr6Oc5ZArt
cutOrVTlo20tk5OHRHImO4OWcFV6pNJKLf3IjmOVV/s0lkkzn/YA3XdW9dGqEQhMWJGQJhS1DNXV
7JYBgCB8zFiCLRDVDV7RjhISYLYWJ6xZNe/MZNOjeKpZ9Qctg7I8/GZ0tsfjfGy9Cx9N44Pl68RB
pRDJnj3g0fV6UE8sysFZjfVdTxli6bpNmnjjLvAE74h2jVb6oNSLVq0iUNQubkGzGrv8dR0Wwyxc
0msXTZbwsZeiMGCdv2CkS/gTQZCnJk8KHtEu0jPbKIzRiXIuK4HR3q1xFdZqJbZHu98wnO4hiHsV
NyqotKCrb0cgkipdNtL16FLKKTtYSai4fQoTSjRqnP8AcjR1dB7ZPp/1Nej+DAmCKVmAmNHNzi9I
mpKmZRC143jrC5UyOraaNJ4NPMSTiLennJmKiYada0hy3NMua93wSVzw7mHgarsiJEK4l5xhJAwl
ZYgJSXE3NSmTlwRYi4RSA0GGaZnd3ZOMvAWrnWsM8/06Psvn0j6fG+N29wXwkbIEQ8ssHY2GRVKS
3kkxaRLe5LLPn52LpquWzpkPDGlnKCZVBWWTKYcF7dmmKwlG0w83YwwVOZElJiMrTkrdOkyWRISA
hUpyeYIHTB49t6cLKQ7RzJtjqR6IRxyK8vZiBTHhLHg1x6LC80p5YcWMdQTbWO2vcXEO27FvlF/j
YuOabUzLMZJVEkq6gAk2rl0ZohMKSAC2XNzfQqCVZYLXH5g0CY4r7HIWA6nPYRuefJK51W1x9Fp1
1sURZFKS9qEfi6Mr9LWnXL6Zj0lY875q8j3k+qmojOz7Q5DFCwO224xmGIDYWbrUq/DdUyraDhhe
4FE6kyf8jzsKDPVhqLZxEhDJZRugxD7C46cXLNZWOK3PgsrpzMGxdsYoFGvAeVl9zf8AioeLI+0H
eCczhb2/U6bS27xqzqky+0sOLu4yS4kiYwZLVppkByaKqC08S+JwppEk2R7CM6uecGbCHKkqizE4
HUImaToPL2ilLQ8GIZHEl1HVEjlpxbWuSIZSCRYqxJqNDRIKq25xHDZPVsZlJVwGNhY7idNQfWTm
IYAvCu+ZdPl5hnmYMcNH8RgJrowvjKbfssgwlWw0nXXuGp7G0Fp3Lp0bzJosMjFznKEt7Qpq2AKH
sRXBXSh4rnKaD0eu9IjLN+xiCVqd4YTiTgAxTxFUR+rhBMjKQICtY9yChUxUqkHDnOh5o3zdstQ+
SIzDKmCu60abox5aXkIkbdRoSyWyqHugx4Wj8ntnk2Mg/qQ2o1cSDaIQjhZ7e4eGW2s+Um2OlKEM
3kJtiiSspbw4pqclamuOH1qPENo4tuQrwvi0pewmj6kpFhYE+eRFdsu2LI9qioQtyiul7T3PYffZ
AtGPahV9WTPR3I3OP0f1y0t4OJkIAjewsGGpeeBByoWRs7SsJSMqbT1HTJnZHNYhFBSAJ5uZVxXO
mauNMOAsvYHsFVyBqPyVddNvrterkrMzVk0x6ftKTaCaoEjqlC259GwklmeCdRTuWc2dKqChXWsh
AuoQzpFpJHF9PRsWLEERd7hJIMhiDFikPMuwLCVXlUG3bQ6Dlvz5aTr1h9f2bImFann46s3TLUJj
ScxNRtQt5Gdnc3UCpyabnsQq9qNModpY6inLy8ZSbm85rbU4uYQGNlHiTpPnbkLrwuNUqcbh+Dot
LjsErUSTqGUMJFMhIVXMU9YItUZ3L9tPMO3so0zY0GTbeq1xaGIvWfV+pdwkH3hcgIXm26D05Osr
4fr2LGtjUwBP6Kn91yFWMfUSqO9G0zjljjrJq1vy1d50s01NGZ3YZKhXsSEyrV39uSM3hWx7Smss
glxXXPRln0yYzslHzrj2Vy7mrKWkeWf4nw5RMfU+QwngrBNgJPMU84ZN8DhmTMmaqsLyQs0LIM4W
cXgmCcHZpm9kmXLdocyrteEQ0mLeYS3SkphxSEqSWSUpKQ7EFgpnCS++3EpmMA0dzOg82+thbxRr
HoOMIxOxV/T1WY3MTDAWQ8FRmS4G4yUTXnDG8w8zCtb9N0prFOFpnIkHX7XHNQmFLCqxkSNK8AGO
Dln2kgYZ9IdIUumYoG1MskWjIun9u9YYhk6zkiVpuPJ+Nry7G+4RgM249Zvzp5DjcQ5jdz94TkRU
RRmIt53Qqh0TdRvr+B6bj/GkdmfUjOTFTa32u2Z5g7FFdZLGzFleZ7rLRtByO7CwEaw1Lwk5t7hU
j7Ic5KydnukfC2w0BWHJFBGxWo1XCOBa7efR04eRUwUrX9R2HMI2DI1UyNjQcg5oyrO6krxesa5G
n6ZmNKrSJcbGxhXWUU6x+zgrRVRpcjItSsAcqPFQtIE3e/xYRXHvEBCmIwpUpSSEoUqhcdgKBcdb
sntAGmFBL4Bkatmn7jz3Wq5yDrBuMvTV6rSRHHkjkdja5fU9da09VhbbqBt9yl5SQnGt0s8eiwnT
4wTjXEQxjsTdm4o0QeWtScy3IMpGgYhNOWuOn43xRhumXCTz3WJzBuUJyxV4uCJyNq1cyphO3TDK
dtuF8vIDa6+LttZbVVZoiljjouVZx9Pt6scaHLKRL0bFgqvo6XWU6ZnrNWNskQkbhbTFcblD5sfX
uPnErbWIqlSSj/x2gsqk3scTlly7ryjhGBZSM7RxWuykw2tRadV5OKuZlum9hj+t4KRyrl3HOn9t
pngslXmpW60XyIGT1RaipV6kzWVruCIcruSaVaTrVXCCiIp4S0xtTxjLP5K1EtiloBRlxS5i+OpI
WhASQlYBxM4BwkHMpUCxmygTIhxrVAWzhpDx6s38fA2nKi+lqhmttzRlfJeObRdL9n3NUPZbPU4e
3y0Vg7F+La/F1dmS+4urgWFo8c6so1hW3jqpZalYmvI1htHVFeOlHyUc/Pw1qn6QPEuPaGSiVbI2
rYr/AP08orU7OZRszWHlb7kjDkVXKnHSOMcizEdnZu7n7t3WnSqrV85eWSoy6UsVSefMSTU6LSPN
JFRoUtim2ZHv2nfFEjpuxRlaTk8vZlyva55zkaz1VxIVZ3F4P0/RsPMQqUpnZtTEXUhDLTpfVkLN
OMpq2WKmwzxA6kv4L0V4I1IaDtQd0xtAEhMpudaNPw/p4ueS7Ta4udPC3Z5UE6nji9pVl9YKa5sj
+TtAkNINGfqy4sipJElrNFHDccRESAf0+q2GhYTZIlIZ0ykWdrB2N2/sd+NW70sxn/pRzstcdly7
jVKdxfpOyNqaxDmXJ2MCUjGT2aslUx5P0w027k45kWfBzZXsRTX0h4fGWnuoysoiPi/iC5LKav8A
16Z2ruo/VjnHN9NFI9RyDdX87WCkrSVNlPAQ/wBgXl2BDisnPOuviSb1OVkf/rpuxB5Dzkan3DGF
6tWPMgwj6t3SmT8hX7PCSzoi8pAzsF/t7crggFSUQW95TlL8w4jlVzz+YgH2iAbb/Dr9u3l9/Hlr
1FWtGCIorEg5qzpPEtx+pdhCRDDAu32t4WUS5uyECgH2h9/mPwDYPhvx4VUEQESkIIJfUENth/uj
1Afh93w4QFMuQvan7M4/IQEfd8Pdv8f8OMCyipE+UoiJg8yh1EB+AgHX7d/PhcQEf3Dl7o3evnLK
wbYBVAionKICYPMAHcS/aAD02+e3nx45yKfqw5fdtsHmPl08vx/ltxhBRUSrABCCYfJQNhL9xgHb
b7+nHoCmVH6EBD5gA/h93x/Hg9rRBgpOf0IHrb12oH9o47H/AHURAxuvxAu4/wAPL+OITmAezHcA
89xAQL5/Hy2+fn93HsUwIAKF6mN9UA6ib7AD8dw32/HhKooJvq+1/d6h8Q8t+gfxH8eF2T8avAbv
x56zrbICgD5ETH7BKP8ALjCkUwBuPZAG3mIlAN/d8Pw93v4SCqBvqGAn2iAb+f8AXXy+/jvtR35P
2fPfpt8fx+/gez+Y+A5/c7m63sAERXAC7imjyph1ETj5bFDzN9gbj58e+8htvslt2O2+4bb/AA32
8/8Ah8uOzGKmAqAYvN8N9x8/Pbz6/wAOnz4SicwCBBBICm+qIiUAN19wiPX47B+Pu47aHQc8nkT6
3vYdt+0Lt8dybfjvx7ExS7gYogJ/1e4CHZB89/q/YOwD7+E6yxyI+x2RvjymA3X4dN99vh8vLjpR
TlNyH3Ob9wvU34B1+Pu2H8OJxp388+XB+tn7VLtt+m3nvuG34/4/W+XHpMBDc4gIJ/ujuG/y2932
fP5cehKoAbiUgB8RMQA/HbbjH2g9iUOu5+pQ95g+JQ36m+zfiiMJ7Zw7uJA8nnK3WWgqG6m5R6iG
w7D1+zyEQ9/8/hxzjDzKf/Z/5i/5cc4rbrGGocwiYAOAmP8ArgA3UnTzQ26iHx5eMKypSfUMU3v6
CBhAPj036e7/AB4xduTbl/b/AH9+n4+W3377cYhUSDk32DtEeVPcducfgT94fkXcOPUWXstKBDI7
FMBh28ijuO2/lsA/x8+N6cUVWq6W5REEHJRDcNwE31QEN9wE3uAeo7cNpMxT/rTF6f7oQNv/AMv3
/HfbrttxuUhU2KPMlsn+sHnAAV+Gw7+15e4fs+QUk4kkEg4hPvEvLlrQsY6yk3kB9rFVrGTgFr7B
Wap0+EqFJuuIcK2OGjq9VIKn1/lfYrx+SxHQjK+xbxykgWwx8oq6TTdmVRWk0iqgU65AMF4iomtz
lVKKe+wF5gHr09nb4/EPwDgp8hY3yGzwxhDItmugWCmZFiLaagVs8xOSZ6u3oN2e1CXjHbWSaIxc
I0GTryL+OJGOVynr2z5MBZ/ScDMqwX9wp/r9+oh5fHqPl9vTb3+fDPSZhxr5GXsko26QClJLJYCj
1MvxZSCgPUzJHkD9rI2phOHOnuU3w9/4e/bb3h5cW+Yw0qYbypN6BCw7W3DRc1Y6zM/yK8mJNo3s
s/fMISWSZOyoNnMUM4hXYy2erJKAJobvCbGpkFMeWWIYQqJbMHhB2KYhh+AD8fPoHXfr0Hbg8K7W
tXMLp8x3nhKXsdewhTL5JUvE9hazMfCO6/b3Kr1WwIUg0d2lmhIqRlpCdj3pod4zSmn8iVo79aHC
pSGY6DVBwCGuFHWAQxKGchm4yGlBlaI8OuAlExMB8hrw8DZ+aodNsFimgYlyfUpKsuYHJxrLGK1+
m2qYucLU7bWDeHSsaxuc8ki5ljS7XYF2yYKKxM7+bKkTdexxrcC03Tffo6Li743y1D2CuVzJdpyx
kdtOQZsfUeAiK9IWCkJx8OvESjh89tsmxpVXdEMYT2ebnzxNdBw+dpIKI8qwuqqit6XM5giJJOFg
3qszB1Kywlcm6LESFgWbWC0sp+gtFpWmBPWMj1kvc2Nkg495a0nbZWdSliLpGOycXtc+WqKzRH4o
pU1ZIC+xMFXMpp0+sJOWcUj+UGPt0Ewj2jJJlX66tL3OuIni0Iloqo/IAQDUqqn0PDxFyT0lHKrp
GTt2ftOl2fDwlZWHCWuHszGUACS7DdJuTaYnulCaVo+KJSouwlbHkKCqdrtc2a1w41KvV3I16bVu
pSPhZVxyY0jIhwSFa2x88iZRqxcPJRCnqvFCql4e9n9Hzcaxntrhd4e0oQy69ihvylqViLkmU3c6
1j6Zv8zD1KHY2QzYV5eRVShKeysFgbryDNVNK2pNAMUoxmnlTPtMx/OUB/jdGHTx3FRWKbFe1qjM
p2zH0ehkKuZFi6fNyasmWDjnhbSuhHwgyMY3Xcs1kitSnBQnNOoekj1Axp4myqUWrNEnWRnd8s9i
LDTBWN3sTagucTTTE0hISXcIdP1aZPIxdOoR7kSSDRzKKFBRBQ5dCOnocjqwb0pgxGH/AAkSDRt0
wMmtOzip/wCHCYmuMs1PhDWiynaMJa9Zyxtg6GyDEVeRyZRJKdg3WQoWTipeCbQ8XYX6NNkK/COL
Qm0mxd1F3yxEbMOo0YSXbOSuRbOkjnbmG9LWacvoZPQqs9G1eoY7jbWnMStjmn8PH2+yV6Dt9zfU
OhtmS8s+mrq5iayMw9bAzd1mEjCrv13CLUr5WyOepav3FLy7p9yM5xsDGs6fUJNOsUZvbZ5rLyyN
lnLxcnqkxc5BsWTfE8Rsdj8LOpDnKu2YRsGgJh5EeNni/WurjjUWfKDZLIzTCjux5Qsb3BsJlJ+S
AczOUqTaKe62FdwNWOsxsloCwMS+ACfwtVOOTAUjlKKrdGBLpRe0IZhdgn9MUmSxImHLuBORYu5D
StTOlIMpDu5ArIaWH6Ax1ki7YVyrNRuQWJ8eYJCiy8/jacnLWKxnt7uCFUrUnVK8CEnUlHjSRm3r
uTM7sRzIAgsZblBM4lFp2isR6IFOiYQDqAGKYQ2+IAO4B8x93Be03MNDqeNNS1ecNLs7l80QNQrF
fY97rr6swyMPkOlXuIdWeSkV0JmUeoIQNhjylZI9oCy6qP1+coCM5MAulFiiA84bkENhA4e8S7bg
Ie7cNw+fTjJ6Q2LforUqTMoM3hnLv3Wagw1ijOAJcA33tPulutZlvubKZjTB11laDkHInidXjZqP
uspSGrhgMcs/sUZKSsE/aSRWcjGwzFiBFUAKodw3SABMqmUyQy2W8cZSlYSn3GznyMSwydGcTmOp
ibkZK2ybqZGFGDjzxzhm9uUdYJyNilWqLxkAWNV8yLNFancoAfBpdy0xwdqCxDlyULLLwePbwxsl
gRr5GS1ilIwq/hUm1bt5Odg4uV7ZD2jFlZxtuX2hDl68T1T9R1DpWprJOXI+Ft61FvzzIAw8tBpw
lazDjyFyLOqzLO30B8rNLN61kyBhnDuBkJWJszAj6EWnqXEz3dpNu8s5Lsejxduj8cSLBp2JzLGr
9zMJzfSMMV+ynxO71PhbUtsa6xcg4ss0Q4jb/NYs0/3KUazEU5NBtYfHl8FURtEbCNTbLjYmJwNO
WlxF+sTCLYgL6SIg3DteNFdmOp2z4vxtl++1mYmMaV+Ih6FjKz2CFryUY7q9LSWiqy3Rjk1Uy2it
xEnDMY5pPS8ZJsJZ+4QZpLqOVU0zSw01H16E0r5OwjC3ifRlpbUo0yrVnasVIRE9aMfO6Nda5KPr
ZPsCqlNMzDqdr8k+i38xLrGQbprnTFMSnF7511G0HIGivS5ieDtNfXyVjY1mhcg12Bq72HeDAvFy
P6YMvYvB4mOm3aDJRNZ6RtLTJ05hQqRwBc4ALcRNxEQRERYqjITLGgY0q+VBMvkSrXFR/SQaP1iN
Hnz5zHyayNq7oOSaNq7u1YLA2qcXY3WiW+fpMc3qdjcykWlOR06xrvMjCyjGQhV0Jdi/ZtVm7uLW
SkG6p2ihFhWUfPupTAebbtmZ9R2TXJmboS0QkhW7XQpdBrPMstP4qTmG8LQUpGFFQZN01dJQZGgK
DIKtnCbQFjIqAWd9TGfK1aXukcaTdahPwNWxdpuNeaBCvZ+HokZlrG8XDpWJa0MHzeLihkmAlXhl
bQLuTkX8cRwQ0gKZXxbIR8LnypS3pXKdeprIVHvWIYrMVwlIGwTl8eKUKi1+yRE4+Uk69LzD9tBw
SJHoghJtEXTlNJwIIxYJnECcEwBv+Mju1AlPyyct3EtSbTaqIKludmnIyf5X107ntV7QMrZDxS9z
TUW+LWcnK5uqx6BZISZg7GechGjScPONyVmvsX8S/jpOOEih10JZrLLtwTOZQhAII8e6/mqyQWA7
npzPRIdyzt2VoLKq9rdSNgLYYqdjYOTgo9BtXTpeDEbLDPOk5AQUApDkUIoICUwBaFpPyDUp/Xzr
ANYLhByTA2G9TMFSLW5v7GLROMffqypUnlatsnKkPISjuuNH5Y6Rj5RZR23mGyjc6iTpMTjjpbuq
riva77aVr3zJ0JRoy3N7eaWjiNCSQ5AVjbZBqrvku42JKwNUVlp+FGXbwVwSSVPLupcpDCUl3gmJ
D2a+kEpAYyKTIkMWJkCXnuIrXlx8cIRNglMxIKJn1c6vJ+ZwbetUbq5aVsYaVT0k0R+TCy2Cyp3r
1ofyE3PL280uQWgwQEPBxLRqdy2JHiKxCHMugCO5lSAZx3bXLFzWOJKosak8JerBhnGuDpaQfWVY
9RZRuKGsDDFttKryhe+Q087TpDbsVHciVZTx6Q5BHtDbzNjW1Q0H6OHMWSYLH8C4vRdWLOtWa8S1
LrDsDVO94/sZRYwyikcYjdOAsEMxVQIkYAQWcIF9k6qfMY2P8RUSzYUx7LoUXGzuRm/Ru2eVkSeA
wTDG7G31mUx6DrJ13koyNcLf6Qznv9p5ZBNykzN4hNbTI+KxnNaFAjq9oa+p/WLKdQlQuHM5k1cB
paWmPeYcFv8ATRSCzukiXV9PO1duRNbmPbVhfRvjqvVO+NbtplfxTl9YJuRgHkZPNiT0TMSqNcYt
l+9xgsjtXItAfAAgDZfYNkVOUpbl6SDR7kayVtfJ2Cck5BgorKmcMyrOrRFY2mJdF3eW9gQplJPV
nltRg7XTqy6IeVcBLWNKLaNiGcqQREiCcsT3WMpFx9FrhrJUBhHGtPvOPtRLvG9ivlepkWWyZJjY
qoTsqLy92JdiMlMoWVf2ZCtyz97V40+xVYwhgAOPOuDTXi6MjV890BkWCpbS3YWjbzjOFiomltEV
so4xJkSEJjxGGjXcElHqsIyXavFFmh0hGQIURHtA5mRDv+xTFN7gOFFg4qZO4+JwWObColOxgEfy
6ge8oab93mdbI8A6z9OGEc1S2bPE9Tt0n8h4ey5UMjzMtXMWMXrCcss3GOq0FMjq5kdinFUiisoF
tGoPGkiVauLHTbwFWdqHKUd1XNfWnWoZXHKcbjezMJ1Sk4NqUvZn9So0rI3UKenDFzBLSVXPYzw8
ZM5RsCKio2l5LylqkVklAsEmxOQwAQNLxFp5mdfWkmMJgvHMdh7PWnLFlmY43lYKPssQ2np3Dozz
GaXBd6m6nLaynfzt7aZcEHsiPtmZqD7QjbdfRb2w+QLQ4b5DodNxoOMrjnCEsb9odFy3p9ZuKFUX
hnEMY8NHpSbWSuLJ04annQWQCKXFUhRQU5YV7ekBS413WSBJZA7RGEOHBLykTQanEFH8PRIQrwZn
ItlTwM99veKtZGE4PJmqGTMSyQOL82aj6dl+DgEqwsdonj6GuNzez+PLHVox85iSG9ULkxiWMcyU
JBn8LXSTeCKChSzM+10aS4/H/gWFcXYWocmTMucJywM8yYRTnGU9iK12exyePYVCOpxrK3tU1BxM
hFsywNxcrMEhi1iFsxewUAAeqWM8O4uyZIUW1T2HMuIyh6IEFkFzb7RAY+j4Gd/+JmTcaZBv5t9e
xEPzFimmpVj7ew6Hy4KSU0padKRIavbpkUbaNRxLlyDxpS6dCSLKPtrVhc/WPwi2umLwxGU0dT1V
hRbITEy2Kr28x2fN2S21dh0mLuCuLdogSwAxE1wguA7sKEuQHLs7OYbofcOXvH5eG9++wdYmzZjr
HWBco1bIzdpmGXuMcWGw/iyRVk3UBhiZayKiluyNNNpRJFvBO58juIPT4eiuZA8mWEUNbSNQgoPv
exxVbafA6INTlTsN+qQW7IWTsEy9DxmjJvn9rds6aXJJ7c8WhAMZGGaxpJSOOxcDKJoypZBiYhzg
6QFRk4S02mz6ws0Lj+ZQJlOssnc+2x085IxOyVdgH58alvI8VlpRwy/82MmEH3bp2wk98jYH02Uf
LmmvVXk13J2Npd9PsZQJlhBoFhPUyfh7zO2qHFo7alW8TaSTBOuo94QOJV0Q2BQpduETFvjHrpp8
I+Xdx89ZGXCuCGbETKpL+7z4uz2r8iXYsZSNlyJN3Ixsh4mdm5EvdHSwf+SW5hAotPt9j+XH0iak
tOOkXFuoWqY+yRXMb0CnJ6oopqzb1B3EVmSe4SmawzskwxtsnCyDufasmluGCh2sxZ3kc2BGQk24
LAbnJx87XZ8rhYpEW5kh8ilEo7/YBd/jv03/AMi+1BULUxYAr2W83S8vkKTyC+CPi7e5nGd2lJ2Y
RQTctopjMsT9v4ks2nK+4RYt0DulEGyapEhTEpuFrkYghlcCBFjOS+MFIc4c0zEnmDoBYqk426xF
DTg1e6yzVnVp6vVDGbyfwni/GDl7ZcnsGDzHkxDgfJTGLkYY8Y5l6fGvXasG3g00lTwiykwmnMkS
UM1MqBDiEvemCoKdE1oW5nGKv3MRI1unS7RaWskncXiKylc7B0Xxx+7cPSmQX+hXDv3Mkr9GcCnA
QEXrVpbzxU56vRNlx9MFsVtmz1WDbtJeFsjuUsECk2XlGB14d/ItW8jFIPWa6jOY7i5fou2ygpmI
4SE+itVPzXjd9AWC7Vidi5KSaumtYc3mGi7C/eFi+79qxgk5lhLgg4R7017VB5EHUT7ygJyl7ZPm
68w1xF7XZhCSzs5DlhUbs9QbRBBHsxTGUnbVZurSj/Q+FjT9GNpawLqTa6lZTOTK3ySOLaPTJynJ
VGbaRgtpS3zgxCcqoChg74s0IAdrHjzGTLvzFDYAG1VT0OOkmfqS1lgrTlyMY2lrj6m0k8gWGlFI
XIFovVkx4raLX3MxvEmQvoNo6FBoIJ7KJm39su9A+aXOX8JXifxlIXmNQkYtRmlLSWJK88x1Fzne
Fk59FnJJNoXHMzYGTQqqa0aM1AIEMmoRRIRIcojo6LmTUDZZ+qUaGzplaBVnrJARMH33K91iIeLk
nEk1UhJt6uzsajds1ip+fdWVR2qYiSDMh3xjlblMqEk3eGP4ejr3nGlRdKWwJCCUCRAcitZyyNoX
Ajx4piXeMVAe6SAnUktnLP7WtF1K+jj0+YAx5Z84nvWWpfGB6rgyfqVfimdMa3kxcynySSVVtKrl
16tuyRp6yQjc7JxykOQxQHcnEU6Uq1i6hYL9IDk614qgcjSmD7bpnRrcDnPG8Oawx1Ss0tk9jYq8
/jbE7mpSqvrQyiItxLrsXyisWhELrL9mk0VEgH2TMuoNi7lqwtnnKkuxiC+rrpZPKNwkINzD12We
khEGbF1MKoLU6JNIThY5ikBnwDIlKmO6pQNt8On1JZmtlmw5jC/XSalc8KgvfoR3eXLeFyMrVyvT
pvLxLWF62Qm0owkhOHZKyqj4hSSJTENsqUTAWUkNdoUYsUucIEhgcMHd2MwAJmTWIIcTZhBvMIt7
2IPlxH7Dul/TToPndT7KjS0TfImqvcy5XumLKKxkWjqWasHGN676yXB7a5hpLmkkE4qtTEKSiKQa
FhCblmXY2MaksTlCuaXMm0kF2qDlR02IsudiVREUnAFV/VGcEEAMUFP2BMGx9/ZEeLZ/R0Z/l8HP
5S5s8aZWy4fDMhP5nQj6nOM0qFAsnVRWr9gnbl6xpyLWtKCd/GIhPV6OiJyZVi1k3DWznbqFKD2P
pzBTODcR+UsRWe+WAr98uay1/JEhUSlbOP8AZUDQjVupFAZn5qEFwApeZ+Xgka7Q1ezMokRgHo6S
KgBuDGpcuzTIqItTMop4f7T9tJPYotFmIcc5X0mekcst1roS9pxHjfEtpxzLnlHrROvS8pZrWeeb
uIRk+IylG0sRnXzpd4RmirkYgYnOBOI4wh6OvULn3EVwztVYStRFFrVVvVu75cHb+vSV6hKE57nZ
HlOWctHbexMGzwBaN3Z5Urcjr83FQFg5OOYGyZn2mw+o+s6Z6NLTOLMvREPVsi1l1SVcrKRlQYuL
PIV+JWfOUA7s4Mwkrk9avFjEFVpBouUjGRbHUJuMaekM1P4mp9Lx3Dy1asdQp9Ru+PIJvb68nOPF
cdZFYA9tdAfS5ZtBd7XzSYeIsVjNzSiiQAumcShzDaElcOGYUaKsue01AAmWcyzOHYF5thUKNCWv
bGCx23aeqezIVlLOYffZgsdM1aU0hzWoMcv0ZSbJk+EpDGlKkvIPRZGpTq0P4BNY1Y8BNb3T90wQ
KqV16tqLwzpMLUJ2qoEk+E9E9rCnscVzIrCu10yFoxe/zPCU81ilxtq9JjEO9NXAf6tjUlJ5ZsIO
Eogl7M5UQ+lIkKY83ERYc1C23FmNrljkuKsf5SqdvsidqSa5HrK9jja1cmFdf1Lx9Bq4M/hJZwFb
k42QFhLumqgPZBiYSbvG/aEWl6S6/wAnjelUS242rFpsWMcKO8G02bNe7zV4ZSqd0CHYu5nH8BJm
gZmXryQAApzj1ss+DoJTefF/ZrlshEEIO8w6pMKyI94jSTirW68C8lhAUFzDuWbsjJ2YBhPxlapU
64goQ5g7QigiVM5dzFOb4EMHQw/Iu/8AhwTDfT+9V0hvNVJ17MtGsc3BhdRFtBRitRQXSo9esTWS
f2hOfGwt5ZdFVJyhVV6+RmqioRZOyimcphitWsUVeNXdqZC7lKt2ii7qDcUOzKN0XKJhItFJT8A/
cw4RyRwMRWTCPBIhgEp1CmAeCnruqyiRno+Lno6m6lcD3CxakWmd4i3t5OumrSLhKrUunNaa4jiu
O1IRdCnvCorm2FUJVuBN+8J82SEpgqipCllUcjECB1R1aM1XLGshYikpWA6mLB+PJ5Y2iixaOdTl
YqDy8TeIbOhTGdThLw+mU1YKcjS1SS7wMPaEW0dPKLGrqXdXfic2UwxiPdl+2dF7FTlbJ8N2RvgB
PP7iRA1XlspSGM0Yh9EWwx3z1hVoWyBNjaGhAqisUVVM8EMeWaNdwAh5YY7YonCxap+kgx3BYnf0
ZzSsiruVvRbWrQ2i8ZqVtRgbIVhsdyl4XIC6SljjUwx2rCW9mkoBtr3EpxbgTVhMjdQSjCnqWxgP
o75TSM+QyKnk5zqykNQUbIJQVTcUBSFd42oOPlIY02W9mtTGwlYx8rNC8GkFiweyaRxADLlEzF79
ju21gwExEojqIUvE6gkKYKGGXXACiCQU4mJdM6oTEQ7ISsFquGfDz3WjLIumvP2NMQY9z9b6/Px1
ZyjLXSEgHztja05pqwrKLWAkZSyd4gyNIOHnTTzpGut3tgQmJNQihGUcscpihFhsn5wLXHjcMgZR
CmvY1SvO0gs9rGoOYsYszOQrjrv0maBfMnMemo6CEFI4makOuCIpFMfgqZ3U/RYASIC3f/ekDHmF
sh3bPTC44oXzG+im0C2g5akX6YyI6gpnGkXdJWTu8M4i6dDn2GyRkJUJ+Sa+dKB8HCeK12qwuhqZ
0ho4ixk+fyOXnWSSZLeUqrC+Z171Kr9X7dIx2Hipcq9/i5h7+V8JcJ7kkCnBwBVQMJoxuabwiEqJ
FSgs8QEhiQnKY004gUFsomYHd/t9T4brO5jpY1jQOKH8EfIzmjt5bClgzyvpcfZWtNcyPasMtlh8
dt0diRF74RKMpNSpTs2SOl15GWVYwKj0seKCkcpdRJfandSr2PeMX+ozObyHc1U2MXEa6zNkh/Bk
xvIt0oIuN0WA2A6Q0pTvCCZKWVt4Uc6yJSxYmUIA3R370p2Csh5RpebRY1iuw9JwFIVVelPsVR0t
qVnMplxJbcWR8BV8sNI41YjcGquLGlY3rVS2xEgD59dVVcccz/mso4VLP2lOO0vy+KL2/wAZ3bWB
NUKxMqDqVkMTnn8dY9x5MQyrqLw/LS0v3GyNs4xzk9vjqzl5viqwRmP1bRDQLKyua/HoPQYvUC63
iGhabylEU4cUPaBkOA7qJ91mVhecx1Z2F1tB48OO/kTryz3RM7VZriK6ZmskxbSZQxOysWJbTLX1
K9O1MXxExKQzWPavyzEo8iq/HTbR+qvV0npXiCku2KpXiHcpAdoVTP8AmipxMNCVfJFvhYqBbzrO
vsW0skKlXSubMsBPxFOnUUXb2qIWRAxE51KrLRvM+OWamivzCCvF0deyfpZt+jikwuT7tgKZRpHo
9M5VZjVLKhFyWZ6lqgPcLvOYuTx64fwDe7QUhKjMwikm/jZdzGzJGhTWIjMpQMNdkbYNO+m/ENmr
5q9j/Udqay9Sxax16TdtLJhzTxTLhEGYJsI2Il2CBZrULFyZ3r6Re+GmqtGIypykRZ1isXwj0a6w
oC8RviU0DY2DPhkcRegOrEGTkDnVoPHh+eatXGlq1nN8eFtmJnOZE8S41c2iQmFKWxkBxeVRtDlt
OQAyNEQLpCo5EM7qRyNcjBd4O1jOYxOSBs/iFWMEaOjY6ycwsYShV6QZ4jukRjFvMMsex9/wbiq4
FqsbOTLixScZDFmopdg1iHViUmXwQrcr2POzZxMODAQMkmN5+nXJunq0ULRnf4GlSBaPgjHGPoTM
twa5XYYwp2IpTDNtnsiat22Q8KRk6s3ywGacRyUS2GQWh7AGRyR5oITpdkZIBuxnhrRvnCvVnJl/
LBY2yna8t5jmtJ+nyGXQqrTWrj+LkCTWJabe40FDM8eo2i5pp4zibkmeBmZiqIEx/HoOUYqAXezF
uUYEm738EJZiopGIFZTIJJMgAp2kFA6sIlp7NHFz8k5jn61s471j5Or9HouM1sV4NzHSsX3Gy5Pq
tbyhhiNv0VHWeZcV6Wsb5+k0k2jR9GqC0g4krqZijoQ8ZKRoHUSTethVfeDfSfZj0/USex3Xcd4e
sVXm8/Q2peOSla09i0ankesvalK1VtVYSrTlbg0aLHr1tIpaW8YiyTOGwOwENuLM9CuPKzi+jSVr
Pi5dzkvUZg3W5J2qXiJSzR9Uw61q1FtVMpunJtUVpx0wlL0+nk3M7GFsSruceNrBBOmjdQjBqoHz
KrlWKmmQ3MU5E0EjlEBA5VEv1iZiiG4HS6doUQAxP2gDpxndLGLczdwIm02wSVE9kbgzgsz7nEha
YacYBJZy0uNfT8TkXLWWLXmfI11ytf5Ms7esh2KVtlrkEm3cUZKwTH68CoohEg1Zh+0f2SAHmPEV
nWKfblMBt/LYQHf59B/D7/s4RrLrfW3S5/3eYvN8Pq+fu/Dy+ApDH7LshDyDzN7g+/3fP+fGDETt
KluHd6WttDpzy/Imr7wPNyb+x8fd+P8AQ+7bbrx2p7QKqFOBjD0AAEBEfjsADuO/8vuDjWdsHNy8
xOb93cOb8N9+M6SvXzDz9w/y/wAQ/wC3C+E/EeW9PPi9YgwUnPPcQPW2HtQOPMmIFJtv2e+w7fES
/D57fAfszmFQPaS3KHx67bh7t/L3fH4cJR7QgjylIOyO3TYdh+A7b7CIbbh5+fl147WUFNLlKoUT
/uAYBP8AcACI/Z+PDVoWcdZTeXcftbvtDe17YfRfU9oOu37uw9dvkI9OgcJQUFQSgl0E3QADzN5+
QAG4/wCH38YecdgHmDYfIemw/YPkPChIhSAJybGMT9WUogIm93sh5m93kA7j57cJ7P5vIc/vwaLY
fb325Cb/AA36/htxj3D4h+Icd9p9NvuG2/nuG2/x3/w8uMfaKdeifTz6l6fb06cdtDoOeTyJ9bOc
BNvygJvZ/ZDf4/DfhOUQV3R3Dcn6tQR9k3902+xv/bv9/HkVDE2WA4CBh9lMDBzCAb/VKHtD9oB7
uu3HfUoI8iqBtvPlUIbb7dh+zqP48Dt1lJVOcSpkKmYpuhTFEDAYN/2RARAevTp+HHSBTlUADGRO
YfJQpimIPw9oBEB8uMBljhuI9nyqfqRQEDAn9olEQD+g4XxpSLOEkgII7eewCPw89uofaP8APpxT
B8x5b0+mk+t7WMVBEAMPOJg3KAdRMHluHnv094bh9nGMDFEBECiIH/XCAbgUNvJv+98uXf8AzySz
gUnPY8ie5EeVMNwETj8CAH1h8ugb8IyKCRNIp/ZMUPaKPsmL8hKOwh8Q34hcPG3WKW04g/a3WUlU
SN9XlN/d5R/kI8c4TpnOcRKn2RTB7hMUBD/2+f4h/hxzgloBcA2MH9aG+6SQf8QlKH4jsH9beYcI
lFFUlThypqplDdA5NjkTAfeJg6AHz+Pv4zJKKHT5DFIU3X2TbAO2/wC6PXb+HvDjgmOAqkEEgKZH
YoiJdjG89gHfYR8ugCI8eotTZjU88nkT6jlSquOzEg7bbeQ/Pb/P5D58OdPtSmERIQC+fZeRv+X3
D8en8Q4aLFdNN2BgD2R8jBtsP39QHb7env6cbzxtFEOceVU3wKYDD7vMA33226cAFRxsOxoWDPlR
tGl7GeCZWozxbriyz3iWq9uby7IY5eFv06jN2GKcRJRGR7RkLCTO3QGT5wCVRECgC5BMJCxVgHlF
MoGEegCHXp032/wD+PBo6b7BG2HShrWozaPh17dHo4PyDWVe3jWcsaKh8ikrtujIiQfiC6KkbFKJ
vHKLcRM+aHI4VAUDlMIVKSzV0usAlUSFMRAhTAJRMb4FA2wibf3AAj068aN9ui8N1vBiwXjJ6ycU
khg7b5562UQtKY2zBcTnJ9KO3c9uJqJpq7lABD4h1D8fLr8/n8eD2w/qNgqhpYybhKfdWleyO8m4
0yNiZBozbqVKprV2cPO2lqvKvJoxoRad7M6qScVCrnckIc5AMUphAEkk0g8tunxH4/Hy+3+PBhad
G+PZuqZ+p1gpxLBkmbxFNWLF9tWdg3bUwtHkYq6zZmrQxgLKyNmgK9ZIIU0iqqsHCrhrylUIoQs9
FXqMiLs4EULYgddKQJ4XMpS101la6+vupvoGsYeoDW9jzLlF1IRLOvBFvM0PMMzlMh4+oM42ShbB
Vp6GlLjZbxMoz7hrLKPDupOIqDmHNLT7OOQhSqMK6msgBhJ03WOgUzPFOSu1+K6xOxcJ3axLwL26
xVbf26kY7mprHEU9aotiWZ9HxGR4Or1JQp2xyySMo9kSlUMcREha3ibHFkwjUIJuxx0xslowfbsh
QM6K1xVyhK2elPck221g6Yd19QGtMY1mKdUgi4vwtqJk4KQMzKLhsY4KUQ9VTvMcnaKfLZJZPGz+
JZ0+JnXcE9sNymIzwmoNyyUKi4m0yt5j85fpkaidI3VQpR41r3Dv4vt1iRY13Rt2cJIdIDGQM3FJ
8M7LwM+/7Wt4pufcHai8Lw9Y1DXCs1WxOMl5lyHmiRXeu6bPSrC1VS0zdRlqevWpdZna3tXtDWu0
1jH2aJllEmjMsiQocvNwxkJjCk1jChXRSRpcGjhmhYdcVCKXt6cwgxuUBl6sRV7h3+BZWcRYKpWq
FWsuQ5V7BVZr4zOOVci2czF9zz/DHV0b1KVms7lQWaUtXBVIwkecx5IXZI6Rcy5SLWa5OxbrIr48
kdCOpkxOu66VNYCOnMkkrVjzfhBDOQa9m0EXKg4VbXSZj5t5l2btV3ioDGUQpV2ScHDY5VUc28JG
PcvQt8y+PXElZtonU42QUNDJHkgDuRDLhow4t+RIXeArIO/y7s2ppLRxJMNHYjxE6skZlP5+urGh
rZsNesdLqs1jvJNUhLm81G2GCoVnTskdNXex1LKULHoSdnj7LFSCthptBbWGzjCTVJYjHxLaXUJG
xr1J4cERHy42eGpmcbtpmUx+tnOxs4DDWOY/J1Sr0HYMrvZbHMjEWW4SsT7MwxeV/IRW7iBtzJrI
KSg1FBaGvYv5VJQoQSz0XhZMQ2vI2O7c5v8AYKzBYilJCChoGFPH2uRyjYa9Sl6pR0fWpedcSFOs
85X63aRutei3Eu9bpPWJAcCXfRZr0f3jTQ5xd642lJKUyLG2g7pXHERI2R9XrlWbTMVaUpHYKrRR
bVdUXjtJiu3r7uOrMK8clbRji3rLOSWiLxFvcCIFm7QC4AKA5AcAzYSlqzuM2fkKQil4il9QPl9D
+GkWNvoeP7n6SjLuKKBVadJ0SWpuV/DYSDq1Zk4erS0NprnZt28aPWDNdtDBBXse6EPAHjwayv5k
YSO9kuKYpHskHAop7G7JFQpAKICJjJG7NUoFARERTP7CnvIb2TbG6cGHVsBZQY5woWHankP1Ut2Y
YWtC3lZFax08UU8hx8u9Y1zI7GFScWGBeO45w3j7HXI8JqIRUXRScuCmVIBhbyPVJKi3K3VGdVbm
mKvPS1elVkDlFIqsPKfnayZgHYAdfsG8lP2d+POdJKT712iQXB/lpxV4jX6by2jAgRqi8w905+79
AHl6WbUW4Yt5KNVepg+ZtHsU7el6JlWZs5HtHyW/kYHKYc5fccntBuHnYFmvD0bkPWXcMQ0FHGOJ
4Va7vYqnA8buK7UImulbtX8IgIRSk9ZXclKVN8yCNSBAz59JvGqbWbVUcJFNXWicwiqQOyEgj2IC
BiiAp+XMHXqQfiHTb38FXmyiZapzbFtnynkONuM3kih0nJFWbNLTK2WyRFYukTGStWNJO5BFnJQ0
0lDumLdslGyrhZQsM67IDA0V7MF1i3ZN3u4VdYsXYsxUlgqjuQGfhnMNmbZK/uqyyGWH/wAfOxJY
Yw/g3191UFvEDY5So4Dx2yliUufmXlYyDMJFyDW6La7ustWUXUOzuiZjyTZKvmmy1Lt7wgi6c2JR
gmQEVWwpgBTSnlPUBaJK3up4M5q4gxpX4l8y5qsSXoVmtNfkLjEMzRcfNM5lnBNH79ZosLKMZqJO
jwhETlOMV44i9Yl1n3jCswtsm7JmjGT1KSez8ZFFe3PFVfJESzucfzVgI6QLCs3kMxkvWw0wLaVl
125HVpsy6qYG19YjtS0jB5J0vVOqKTbKtWUcnZNpjOAg387B2GuPGtdLYpK5NllZWSGK8edQcO1Y
vg8aYJqJNu1KUxeNeHGu6P8Ak4inaqTIOl2bcCxyYVEjy4MVbPeIQZqLr2avI03U32mTMGl3GuJN
IuCs3msc1Y8i5taS80okyl4taBimsa67lI1p9GoKHkG60e82aPXD2TlTtHX5uv2avscNPUPpRp2P
WWn6kVyzzM3lTLlRw9ZXqNgUp0pRI1DLFRq0m5dwdkhpE0nHtq5KWJatxy8wWWSlIjebSOohuqLN
s2Wc/wCV8HVLET6ltV8WYDfuCxs1XqE1bPqyFjZkcvWE9elTCLZxISyhH6Ld72Sq5DkVIU5TAPCT
KGZMk5WYYbtVqx6xjK7iSs0LFNclIOKsNbibHFYzZNomtV2atPiMy2mZZujUznkjxc+o4bkbrCqU
pUT8vba6bQDZxwgv1sDF3S25mkd5lW0wcYBxLIkNM8P/AIij1zcWldz6PAll1YwukDHGQjStjTuM
tWLdYbXWG0fH12SpJHSr6Tio2vu5lrLs3xIFqeBZM3UWRiVRM0oUQMXhlUHQ/L5FzdlbEdIvCpk8
M0G7X61Sa9cmhnfBMfTNUhpWCjKXHzXaurqScsCizhg6tMZXUVEjFVsxTRcaFy3kNq3s8Fquh9Xk
3iOLbySdldXwtHi5axQlemJB7FyYSnJPyiUhNuY9wMgx+mTSOibvrQOYe8pc+6wdrIjcV57zpm+x
46kpmAzbRswVBSnRFqcw5IX8pluirAs4SmpEkkR0SukhGa8ccFBLKpLIqI9oRQhhGYd0ygNIUUQ5
cE5luGTSJeUj/hxR3DP3fdrQpjvSvaMlLZXj67lSsQ+PMUS8QnNXCVUtLasOz2WamYuuSTZKFBdW
NBduqkeXm5duVKDIomZysiU5BGf8Y6DdT2RaRj+KpGYKklSMxS2RIiq1BvfroRnNGxxJSClgPMw6
UD6qQsTOkrAHQWeyUnMuipHMmwMUhtohw1nWr43o+pOqzzG7OGebahBVqtxMJORjGBi5eDnwtRZW
xC5MC8uiWNEGgrx4mIUR5ebrtwWmlLXdjnBuOMWUa60m8m9Q8mXm8ypKHFVRWKy7B3eqSMerU8hD
N2aFNLsTyViXfA9XjLGkcoCoBhKAjw1dbrciP1caJUSXYgBqmbl/MzaxrzEvcVgCkyAbCMmE/wAa
WG6TwzqmhdLrjJNhypLq6eYfIjXFDTGjnK1nespGVMzn3DGag8eoqStdhqc0Z1NzFsnjltDHnF5h
sg3iFzrkKbe3vDmpuUoLBtZcxP8AJMXHVnHuUX+E/wApuR77aKjF2ivKNKXNTdBk030bDuo2HsVf
qjpk0VWGBkpyGjFSoOpNiitrWOb8VvMOahqHYG2QYGUzRlSoX6sRtdqdYm6JV0II91Si4945kshw
750s4VtzRN6jFwYHBSJdEOXmbKgQl6b6Qul09/PW5nDzb6xTGAqvjOXp7akU6FYEvkEXELOSuSuW
0rEveZyjMo/FblRrWLBGv1iTEkigEAC65SmmDdrkYZh3i9JhhxNKy4Dpq5IJ96UpNqbDaL8Kaams
vXuY2i6TxZrjiZXHMmXKVon7vV7JAY9r4M8pOXNqw5ZEoV4zYVSfeO3KKtHSr8XHSEe+YElCLMVG
L1FwkmZquUmezQWv5rYakg5s19yLJZPh5HGFMUZSzXKFNtVdLIOZqcpaDV5JydVVYIrQTScsLRs3
UrzFisi9evkm6hFBk6w6t8BZXsOXU725d1nH+eMmVKxWNLHmJmtdt9Agj2i3W25L2iZiHbBLJd+c
rWVaIY2E5rUwVjjqgmYUxehZXLjDVxi3G+XZ2ySuV053DMpRsuYVxBi2nwV2TiMLUa6rV9CtTc0l
OR8LGmdTiTKPfXkIFrYJy1Sqk5OTikrBoODkMq7XFYH+oSCyTJcnYZlgaHuZ2BtGK9/Clv8AEU6v
ofPWwH2QmesUXdBvbajCPrbY42GjY6vWKg0W7V2TjXzjusCyqMCLOSpTZ0dyAt2z6oJtzKuAFFIx
lA5Qe7+8atLG6zxiSQpMhZrJebS2s+bYscftlLfXbfDqyCKbNwYgGPTwj1rCukxSaJCcFeZMhecB
LwbVm104ep1WwrRqdWaDe8gVR/aWXr1SSv61Q8ZRV5uMFLwspjG22NOMuMDdaXV2rFtJyZGzJCPr
a1gjKVPPJVGV9Y17+y4xsmrjUtmKs5AxpbK22l46645x+jmKQgKblXLNqKZ+xt9ucTx2UVdazTRJ
a5h1HGflar2KThK4oAPbDKt21lXO7ri+zXe+JXDZ9qqJ1pM0gWYiYcuBVjITii1MBDyzPyv9Dy1q
j6zlzIuLK5ZqPUH56KvbjC2t0zArTELcZdglyipUVpxB+rYU6afnJ4nUopuVna+cPW93L8wbyLhP
Uba8T4f1A4lrONoOxtM+Q9ZgLldnwWKVlICuVx7JyjRhW2Uc2Ur0WuovPOipv5FyUTnTUApxEhgA
isPrQtPyFqLNny64gyDippOxsbl94QTXWw5Fscp4/wCCu8AEke7L2SfT75IeIycsFdi0uzg+1Evb
thNI/ouynmIPWq2P2BKW802W878X0iCcCjYFdvVsV3EpIgQ02vuXuTWLjyunG5ewTPuHCKrsgRLv
DN8htGHWU46oGGk2JBGedjxocRUIREQkkyzJFEzfPU+G+1PwrmMqBiJkIAm5QEdgATB+yA9A3+XU
R6AAcWi5i9IsrltOOeM8fvYqZg8z1PNVaI+thpmKr9lhWUbF3GvxkYszQTjK8uhANzsvVwjFBQhi
GIIlMA8VcuDESWWPtsmmXtkyj051P3S7/WP8ShuPx8+Lzs76WKFgjSVkqgVtBW6Xqr3TTjYbPmGS
K1ko2zOrvWLw7l4yjJMAUew+Nq9IsIdo5arTHbvHUgxQVP2rtuRWvR8aMLveBAjloCmBMNEyohMy
JgkO5GVdbHWsoSCBlTSnrnYJJnMOJsgZmxzYKAneqvMzeoWHyFY5DKlqhE6PUWi9uj5dZ5Wkol8d
tDpvZMs9LyM3Mx0pNlio+NjVGgIgQOJc9Ixm/F9nlo/DmK5uYtLTHuZs131xkNZ3BOoKQTyv6meB
Q1IPWLA+F/CQvqa+8ONOKoofpRDshHt0+ZPqY0fYrx5WtRcnjaSuyCmm3IlHoM+7vLltIo3xtkrx
/wANtdPWiQiiRK0Z6qOBVbLmEEvGWnNyg6S7QJ9M+EJnUVm/GOCoOcja3KZHny1xjYZdJR1GxbYP
/EwIyhhcuXck22/MkdxW6eyAcTHjRMHsxhoZLK2rnECwL4WaQUZcgMEwzCgRDEU8Gkgyg6Xc1FTQ
ZGxQay8sY711ar7BkXE7xWjQ1orUAZb8vTuu0xylJw7KCiSdhIQlhtLYVZVDczMpZfndE3MiChdu
IPq1WDTPmDCV8sN3pEzCx2Q4a0SL7G9lbWpeKhq3MwLuei14uNUQMqpJsDFjYVFQnM9WEqLYFTmA
vE9VvRHXcjPdMqNHyPIDAancgZPxrAmvdXik5CoXLG3q33tWzMIWwzTQEZr1wZApJwk7YJWM8LX5
qqTu6gEftS9FLk68QFPtlMyZi1Gm3HFeTctHd2VKw1d7F17GU7XKnaGvhMcSwM0n60i7RdsUxnCn
ODkDFD6V0NnXTBjQlbVECEuOC23WpSVBurISEikvWQOVbwgiE+C8RQ9QEjMjymQP3ZDhzVBp4ptz
1zTVgRVf17MFRs7nCIq1BeQfxGRDWMbJVXKzEX51adMVNnvHoS0URRkgt9FXJ6QN04m6E1B6NZH0
qLLOcQ/olV0sDA9nMGslBbNK7Ivl6L4Q7atKK1q75qu5ezI94TRlGDRVUwbkKI7cVi6jcBSWn6aq
sU4yLj3IyliqkfakXuOrAFgYwzN/5xsq5VUOjBzJvcyQPOuh23BMeF2jPDdd1D6k8UYZt0qLCt3W
0FinweIPYmSflT/2SuVeUbpTTOMcuA/2dZ4btVvJPm2DiBFviLyq6PDTFUkqVIYAkpDkkuGADvSp
Odr+z3B6reWefV4a+eTyM/0deesb4rgNY2J7zd6RU3OacNydNoVvvKEWalO7bHvt1G8tNv45+5aQ
kgRdNRuLuJlGK/MkonCGAS80JaLcu6R8LWrOJ9TeL184MJrHc5RseS9eiIKxxsRa0/8AY5WEhry7
jHUajL/+h25+Txqu/wDqjcg9QiLEemPI2Z4jJtypz6txFXxU9pcfe56wzasMzrBbe+tUXW3xVACY
bg3cSVdRj3K6xypnfbNOYXH0fEnYK0PXzKWcsl4Ut6FjrtqxJU7fNWWKgPVeWsqEnS001mULHxVm
sVcYv2YIqpKysgnMHI3TVTOuYpTlEV4UKMBDJZ4RxE4ilyAlLvLCwQJvOb6G4iQJDEqTASG7xqa+
rHxpAtuOLpp4xVRcdxLyFy7jzJ99krJOx+WQw4lAPMjzdbcY7yZd5RrLR0plWCqVMpdrgFncq3lZ
FkQW8Eo0TrdjSfL4aljHRnqDtkhcb/EVjGNRtmf8nO9MkRC+A0xzqiryrrdWgXRAWgGx7W6xMCyZ
1qxAWvs5iOsk93RdVOvuuwr/AMA6IMmahsLZvzXSpGrJQWEgrZZOvv5NFGdsbm3TRYtMkeRd8zhI
ePBvFTJ5pSUclSlE5ApokwgoAjAlJwBnfIsGNux7jS4WqvsJSRiEJ2BiyOUkpFizZTrlKNfyKpH7
2aY+JxqlhaRKE07jyyDEz5NIHaAnfud92gUFXErKVMt8SiFKwqYviaSgQCHCTIAM1bwiHIovUVDs
ZJTN2zl3Hxza4LT9jDU5g/GNOtUXi+UzvZdQ1byQ106YMYn79hDDjBQ7pXKE9nGnPVomnu5yTUlG
jjH9ZmnNoYoqR89MW2zsLI6jo8uv9GBQrnYLZCV/LlDmrHRLFgDNEthmDvVOpkpprsUVERjd4+se
QTsQ8QTtDV+6bN2krb4FxbyKrpE8QAxygNSFTU1CpVp5aKO9zI2pEMoq2cz1UlbQxgYcjkhFFGKE
vDyrWOiV36ayR36B3CSglUTMoXlOURk7ElT1D2XTznjJFBy9NV/FmAUaOyyLj5HIVvhiyLPMbl8y
ro1ijRrRWpPWjh7W0mk/HPpdsCbkvd1yAqAlCYt8gw4ZhG6rDhsWAyJIaUnDlmcOdHDV2ccNhvEB
LaLz6vpywc4l9OGMM+aPsESjVm6rOY6Po8zxnQlmjYqJTrttr+FL/kV/NRlqXTOE2a7mjYBsxqs5
IIS7BgcxE5ERMJQEAGGn6gY/xenlPUZOzFXd3+jWtxgbFEDErGyLdHSsQZhT8nW9tYU2kRS8Dnkz
GfFWQGbst3IZRWt190UXg2V5VGlappbSBe861TLllY6e8eW5bC9io7XJ17jRINyQj5VdhF48iple
lnq9jXl2hJuOSMMcc6s4VaviZBzyB9abZeL8/Rk7harJcJOOjIqHYSdln7HaZZjXWg/oqAjJCxu1
5Jk1Q/ZRI6KUA93nwG8xIIvO3RDQsdUYNDUlxOhS0nDO85F2ac1l82npTn6W+grImlnTdjq54707
wUTgeWrl/wBFMnbnac5VpSwanGd7/J9lDJcjnapXteKSi2kY3nqipWmUS7tAxvI2cMyQfaIKELUQ
noXXs2mma1b1bM2Oy4LhfF6tJubXB2KPtaWX4CGFY+KoulsUZmMsLh+jIdshd3N2golZKx9oRUxI
gDEcNag9dMjhqUuldkMoDixvjmarqj804wPLDhpN+/jrFH14j6TNkVLESr8si3sEW1bGqshEyE8p
GtuxSciUdUtVWoyPZrVVLI82SmqUqRoB8cIpoDjVWnu41w7VaOcfEaDSSvCqqzDk08eCCyhNNYmZ
GyhCnROJ467kISIca6xQRhdezdRYAHQByynmKjDmAhZifyohNJFh8DUylY17LAaW6lpqXnMxYDjM
KWTIOEXMLphja3arnLZ9umRYxBRw2z5dyTT6Cq8Tp1sduWcQappAZWfsiaky1r9fXPJxZDQc+9Gd
qbg9M07qtnoSu16kVZhSbW/rlglbFEZBZxFxEArE43rchWW7Z42ecwAo3LKmSW68nNsOym+6ydUW
ZazcLRfcd4pyIRnjFhiCx5WkdO9Wk7NQqG+EtcgWMdktywfnoU0d4cjprORrsLKtOnKikyO6MBBc
N19JNrHumIb1RskQ0NZ6JlLFkFjC0WSUx+8ZL2dKnLdjR7ytdW6RI81rg3H0TRzEAMFKrD2aMEof
pwteIlwvKIyjd4kOJAKJBJUFAKQ4L4WdJWAXLKYkGYtYIjydWn/bv3B+Bs7NRfo/CoYLxHnzTm2F
SAdaSqfnXNWOXtzkp7I1abSFwyFETuR4eEetiEWxnFpQbUJKTCVGUZc6fea6lzlDinxddZMezAUh
D5GD/Aev9fPe0JD0neRo7CKuI4nFWPkZx5pPkdFy2Te3s688tg6ZnpKXs3LWwkRhDSkueecgzflU
EzESKchy8ptqu3pDnMUHApJKmNylTIYoKGNukHKUnQxjAK6IbAAjuskG26hQHF6Uu0JcUqukElOJ
RBSpQ6pW6AWAmEsDJ3BecyXZqlJOT8eq+u/wEqWTeJKnEOY4F+ZhAP5j/wBfj7uEoPBEqqhVCiJv
IAMAiPX7R3/jx4OVYxjEKmUTlKicxADc5SuTcjcxi+YA4OPIgYwACph5UxMYeMfYLKJGBNICiXqY
NupQHsx3EPMA2VSHcf8AeJ+XMXfMTBWusIxW+NagxGHQnSXmLUdOo5b8eG6XpSQUPscxzLEEW6Kh
lnKh1FCCQCiZodZ40cFKgn+iXxpNmYJKL6HE6XkoJYZFJy3dovnqTll3fuL9JQnfGXcTCaM5BBzz
q92U/S2znvXJKddgV41Kjdwb6pCm9sqXQNw7U5BVIn/fOmAnKT6wkATlASgI8eVUjFARTAxg5hKI
lATABgE4cu4bhzB2am4D13IfcPYMAXiJjImhMRNGZSmEw1dHn+9hOjf4jdz3jUM8o3KF+gmibSCt
tohmZrA6tZE4admYcEbYpsJZgwNpxflsaY/7Vax/SUptsMkp13j1w8XVUBXtOqqpVzbDuIGdfrgM
G+wCT9sB2Eu25tvLhOVQT7pkUIYoLlETFMBgADk5yCIgYfrk9ovX2i9Q3DhKZQS/W2L/AHtw/mPF
FKjRNhtoyouwpibraPyX8LUQnBQvN5+NlKwuEFO3Olzk/cANx9/u69ev8Oo8a8igrj2Ye0Xr1DqA
ff7/AIfAfw4XlmXApbKjzD8OwHf3bdNh6fd9vXhMvKCP0JW6BDe5RHlEof8AuL08/nv9ocA2w0+u
7881jZjU88nkTSgcgqdqHUd9ugb/AMg3/j8t+MyQgA9RAPaEOogHXby+35efCMVFTr9mQpSB8R6e
f4bbcLg7USgYAIJTL8xTByiUQ+Q77D9odPnxFhrOOspv5g/a3jlN9MHMG/27/wA9vx+fThIqIbAX
mDnMPsn8gN9g+Q7fIff168LBEN1eodfZDqHU2/kHxH5efCRUT9ehA7Lbl6l9oPdsO/XyDy/D4WiR
SigBqfIG0Wwb7GSSEQAA89xDp5iO+/lv8+ny4WG9pJFIv0aoeYm9kQ+3fbbbfhCiqkRb6PlHp/bb
B09/1vl8uPKqojsQFCic31TgYBKb+6O/Xf5b7D58B2h0HPJ5E+t7EFgDcTJAHxEwAH4jxgFRPdX2
ydQ6e0Xr193Xrx0CoKJbGEAH4CIAP2be7fjz7XX9V0LzD7afQv7w/Avz8vnwNZwb5geTm1lhux1q
cWLaca0+/YnNsYeyPsj9UeUwf4e747/L37cZEVQ2KPKkIG+qO5djfDYffsPvAfkA+7hMiYxBVTUM
Bij5CAgICHwAd/u48idYgiQpCiVL6ggACBvmAh0Hf4e77uIxJ1HP7/XQ2tsxrzL8+Wk1iRAAUSD0
Jv5+77fl/Xy4dkQiZJt2ogmC3x3Df8Pf8x+73caCLSVdvktuzMiXzABAQD7dt9hH37/Pp58PchTp
DzbJgTr9HuAD0/4en+PT378cjr1lP6B7Ds05IBK7E5wSUMkG5SgJREQ6biAb7iHn1DoO/nwhKcVQ
VOIpcwh0DmDcfPqHXf7w+Pv343c0UyinbJgmX6Hl33AA5vh1+z5/5NgRAxeYggQvxEdi/bzD0+7f
7eJt1lqZ0yF3Au6g/tB16e/r1H3/AA/6c4TpLmANx7Lb48xflt79tv4fLfrxziSGJGnpaAGAGli5
aLdoAAYQA3uUEQAu/wDeHp/Xw49Kql+i9kenn0Hp7+oeYfj7uvGsaOVBSKAAmInDmIACG5g+JfiH
kG5d+nTjMCgqG5TeyPwHz+3Yeu/u/wC/Hp/6G2z+HLSvP3sPaHQc8nkTxGEN1wWECCkOxAIPURHf
oAdNx8unX5eYbYuYu+3MXf4bhv8Ahvx05XKZVUQDmAV9wEOoCHxAdthD5huHl18t+ioLnKCpCkOJ
vq8vtb/YIb7/AHBv79uF4nUbOn3f6WnZjXnl+ROcsAY/jspX1Snzk1NwrRCgZAsyzyvxsfMTqilF
q9qufhEVHy1jrkUKL5auonRSkJs/bBschTAO/EZOEwaSJOxUKZiqrzJnVMBVFC/Em4hzF925dw+A
79OJO053m8Y9zFT7Jjestb3cCt7lAwdQexkrYGliDIOPX9GkI1KEipJeTfOxhbGqvFtUUVVnEsIp
oEMsPLwz7/F2aDuE8zsdTNQpttKD36kjGzMW9hCFSFczNy0npJ86ZKlQ+mMisimcEvpBLye1xoRk
wY11gKMEJTA7KsajidhObA5+srZkS7RUXlwXp5hPqfDV7LCGKAnATBuXbmDcNw8/MPMPv4KXStR8
v5Zy5C4rwfdUqJebnF2wPHxttmpDFxERtVk7DMQs/MVpeTkJFzLNmr6NSatkZlRw4mWqBCGUdpFO
GfiDvlKrsXdP9bt/a/3R/a+XL9vl14JfSjmaKwxnzF2VrESccxFEtRZOxI1pCNGyvIqIZC4Vatzy
6zdJTvTP9FyZSgPZuPzdYCqexwK4QEe03ciIYQjgksBJmZnrLh3WPYkaThjUzfcblfx93esq68st
xolBq09dpxJ/kWyxR5a1ZKjsY18Y+RO8ctyMpFeySLhSFhrC8lUK9HgZZwmiYda0bI8/eMcY6rjl
0a3xNnYsMewqrtrDDDWVW1+LNwKFklmMazdMbB+YLJSzoFUWPQ5SkHiwGka78UVd+Ee6g8gx1HpW
oxTPGPpCDrlMfWlBrZ5erWm0Y4scfM2RKLi4qRdIu4UbfWpxeZUYTjNPuwleIgpV5l+9UnJNtyxk
sgztdu1myFKWas1CAh49SsBC2WQCQdLTM+7sTaVM4i3ggg1FrCywkWEEw2UEA41r2bmP4fHxRYqg
WwrJADG6zcTB/UvB4wQKFVlIG2L9RM95zb82PB9Ea3KZkEtlkIEchW3UrMzDYzaNfUu91vLUtjiW
lJ6RdvYxm9UrjwKdO1NR4oeUZt/VcWy54bvHZKCXb1HVVr2tsxb5ivUOfyjM022XNq+nmNCRtwYr
vGS6zLUqzQ1Vd1mUbw8W5XTdNko5j4ZYXLgzhAiSRzKpgaDMS6r6nUrng2MeykslhXHmD8l095F2
CvMJpgyy/l7FFvSvlplYPvkuS0x0hkewOTkevmcgjF4wKduZRMANXeNjStRVCoOoPHNtjJ9tC1ir
URa4WKtVEtmrWIrHqJoePbGhSn8TWoVOtuHEBMTsdSE5RyvVIxA505WFOca+is+K9jhGIwvsfBUH
AnUZmVCHPEzc2Lsl/wBiH/1H5ef26rBq+XMm40xlkuk1jGr+sqyc7XY7LmVGMHdmNtYP6jZlrdBV
B3OvnxKjjaSgrUeqqJFbRybqScFRKUh1FnBbPJ8rrelLbi/AWPst44sN9isITuRn61smL/c/EbgW
5Sk1Pv4taUbKh4dJVOcm4B42cRytiWeg1IcNw5R4MPTVrE092qlUGRz3NV41jqr7PEvmeAn5B3DQ
NtmMlWqxWFK2Q2O2raVr2XnstCty4+as7C1RPWna9ZclBFZ+xBVv3/NWG1cB3HJOKnbqnxX5JqO0
oFeNdaywjKBlKpyuLYSLZ4ywkWXXcUq3ltVcv1qnJyDUKm/rdombcvOmlbc5btW4N021226ukBEi
ghkRMIYym4Lg11qakse2Sv7EPxPy8+jdUNorV3VEc0YFvzmBvMbUcJmqZUSoT8bPZHsTGqyE1dU1
pewOTQ0WZ4RzO1+CEFovnLjZumwEO+co8D/qNztXsz5iyflOuwTyvQl4t07Y4mKfOG8k8hUHMmqK
yYSbPdk67IEFxU2MblBFUTbAkfabtUuV5+RpunjDZnUddMk0eqI3yTyfFu3dms19nc5zCOWKlV13
r9w7lpFzRoSwVyoxMeo6nHMhcEUTRyVfYGTSFm+kTYRsPqatq0VW4yltJWlYHsZa/HRMdApQTucw
XjmakIxSLjVDnaPXNhdWJxKtVUSLpKPDC4TKYw74l9h3pUG8xFX+GswJBKggBVJEzavJoaBCDf8A
DoeU9orUP9O+ekxOTtiJHHOVIRIP7AB1D7v+nv6e/g3s96n8XZOhtL72pw9pPacN4Dw3iC8QV3gm
CtVtEvjavFigXZ+B3acCcqj1A5DIsJKMRklSHKJdwMAjW8iqArdDAP2Dv+G3z3H49A4tQypUKEl6
NbSbkCqY/pcLaZzJWYa1kq7xNeikch2iZrknPycGjOWZy8764apxD2RaJhHvgDZODKXft23Ojc1X
uJcrwragLgEMkJDKpMmrTqKBrOxVbOgBl6eUzYiNOeuPANT1JyeYbLYbVG06+4CvWOrRS7BVZOxx
tFk5JlCs0sfUeKYIS8CXFcNIpKw9ViIxlDwETT01IZdjW3RDVgB/07al4KpRWrROXyDGVyyW7HMQ
tjmxyrWZLYn95hciVuVQGpzUQitY61LyVNGwqu5KYew0UZ/J1oB3PIsu1xYw0r4dNd9F2OL6renK
uou0Uq1XXJpHjeGx08x1YIbvMRQMYrNgmZmWkW7r9H5As78sJY45T9A1Zo7r/wCe8TpjjSlpqy3r
s1A4XbQc1Wcd4Ux9m+fRpyt1lWLGfvuI52Kg1KzA3NshN3KMpC8krMWoJB6y9bvzSJjAZjzolH0O
y6TQBtVXVMknqmgYHPvk9TOotmg3YEdU5e8fl/PIszYPU/Cs/R73nHzfI0JBZQmdVKl4sFabyMq1
yReMc2qjTURYpa2DGvnEdMRklNTcAu/I7mWjQTNi+EmA3JxIWq/OFJsGgvRDXKrbqQd/XKc8hMiU
Kn3wsnOxcmiSTVg7BP1GMl14BKakWDV/ZF+/tE11JmYbQftLukkjibhrCWnu/H1S5Gn5i7QWJsOJ
sn2P6nDzFfb5DWa2q6rQLGfUj3lhBvIpVgzldGeQJMKLTyk4sSLnTGhDgl7ZaU6ajo1sWrWxXuYS
eTObJjD2OadFRcC7KZ5HwB36i97eo2M8tD+tTBnbXpPAGqwtmbiEdOPWJFy3OemG9+zu0NyasCXk
7eTjvrOza48NbTKaU/2/nwNix1RZKgnGQtElXFk1tGNXGNtJU6fGsZaoe9NWknH0ajRlhp4tXxXz
KrHZnAa7M1o7NavuzgMm5ieYBOBAU1/RLt6XdljO7UWDtdEZ5MytXqhWGdXpk3BsoaQirENWfyRE
2CaC7Cog6lBqzo+7enghDCxUedshzVhZ30ex2BtO2n/MEvdJSVseoKpM8hQ9VhopsSlMoB+CwkZK
TDixmnrHZ0PBmHjqIQyFOfi4QCMe7qk5u79pLuGJ77hnHDDIqqmYsryOM2CNXfQ1srK8A+yNGVyd
YP42ZTLLP3lOSSmX0RKOmUbF2NF23cNVquVZJRMttlEIcQYRZ54iZhgaZgiYyJbIWLjhbPZlRaU2
nMJy7z4WPrS1C1PJWr7WlV7RSqxPyOPtOWfj1Jg7xtUp9zG2DFt4x1HwlvLXjs064ld1Y9uaMe2v
w0HxF7RamyjQqk2gW0tnTVJYiuFDnL3dcZY9B7K6+cTws4oxx7Xbi99S8gR1mTSxazq88g1QqmNW
x1Jkh5+ImFZ4pmkSUa0BjJFEa61o5z0y1Qu9NWKM91tXLUo1vzC9WCAuWS69CwrijvZA91r12cMo
5ezuxfzkS7coNImDsKs6dKDFNNYV2/NF9NxTmCo2TLvqPqBiKCwxhHVGQv8AkaAvWR67EvVbc57l
VmyCFShpi4SM2m9kZZoq0l4trEwzlg9bmepLNVyEi6xsBViuq4ruCFAgZOQ2tNJOAHLxd4iZkxVn
RwJF0Gs9T4WOE9XwypbfSgYub4qrqF7xqbItnpVjI/RXQoNJpmdKrUWtSpjAsYbuzwWliWMS3Oy+
P9mBhBsIcQvN6KJGH09ts4yF8g2Vhc4whM5NcXPo1A0mti20TkdVYCfhZOKnpxI7k0jLxTt83nwr
xChJx5jj+etu0Z2OtOesaYypqcoVBybJxNmxzj625Hz/AGBlkK6NIS6Vxq9in80hMTbHuknd5i6t
nsdYY+DWh0nNrdxS7iXRQ7uoYqDGmLtcuYcVP7XB322uMcuIiVocDFW6+uU3mRICAcsLLI1ejV6y
vXMpN0+vSTKAbDHwiLuqM3LEUVX6aifKAUQbtEJxdHKVhMxiWcksC1JF6UeWpNnGyjQmk3Wy6npy
4s48laXYPCUBE2y1ZWxda5Rkhjufm8ZR8i+i5x9Xbkza25xGVVWJUcWRy0iop6ybvZSbYQCLQrtt
26iYOEuYictejys1vzKpFYDXpvqdcMuExnXW89NWVqXH0xJVl1eIuBtEy7byck4QTgGL3kdwiFhE
zZo5VKIpIKmTAXKtX1OxmK67c8tomZVW+rRNMr76xxtNjso2KLp5HkfDN3LqPZGya8gGkfDLxbKc
npF8ymV2tfbIOFlGNYJIEfdMiekmxqNBf29hM1CSZ5Eq8pVUoSBpMPPz2RiVGXiK6ha4esvHz25S
3q2wkkXzNdBJ2RGURFRPkcEEzKEdHrB/0MQMGDFRZsOQme5qmxIWJbOoiYyGoH28zZv0vRFkLJuR
D4sxzk7Bl0sbSr3m1TzmGtdxUa0qJx88LBzrW4M5KhJzzSSf85SRCEZXZxZ0YwFQKcR409x06RuA
73E0jUgS8S0veKhXbBiZhgJnXrnM3KRtM0o3hXcmS0uq7NR7lRZJVFtF+rgKrKpqJpJmOQxSpYjV
DqoomeHngOHKbXcwO4/ImOsiUKhYhbVy230bUurO5AgskDW1ZC82VZXkXUO4JMNTwhCODq9gBXw2
XJX9RWfsXakMeagDaaYSPs1CgVq1VaIbHVnio14LSGkIZKeL2baQtUrP1wZONk05qUcNodrKyLEp
zkWdoc64HR8Eqa7XhBIHWGLE+czkzNnXKlokKMmSY0FRk/Wn7umfqTZ03fSjW3eobJOAsTZqo9sf
0EiBKm+tEwZgGR1UDdnOQlVPCRjiteMQJ/YfKHdrubGf2Ycpx6DHmlbTzMakMr2DDDC9hQrW3qdq
sCjWRiJaTZTTallMecr827SnWspHvikMY7Ji2a2FwJDKmKlyi9GywTiDLpcAy9mtz/EkDccku4lG
OxtP5Ci13bDHkyrI9o4vZqrNxrplN3SKJ7dVcAwUj6sX2mAPS9eJL0P6talpkzzIZ4yfCXHItlLW
bRGwUbF2KKatJZzdItTvKlsmLEd5JSH6pXcWSA79kffoQ2y8L+GxV3GIq7R0KDhmJBMpkODXJ56h
7VGOFDENMQxHaZFOy0hvzNR5jm6kW6bgElFEjAb6uyhOvzDr1+wPl5cHplPEWpSjYhw/aXmT57J2
Os44wlcgwMLVbXk62QsHQak5RZCFuhZiGhYuuEiHjlu0asO5zdcSdLood/KqoQhqs3T9cioqHETm
REwF8xERL9YADzEQ67gHl16cXTO/SIYGsOhjGGkGYg87x7mn4gmYKctFejKnBIWi/wDrC5laTES7
hrlFZWaxEzXPNEmXT2OfTT87OKBWrmMZPdbo8BQv6ELMNOIYiACWLzY78Mx5TY8XsB6t5umwR2bJ
WeJ6LhJLJNkyvbaid+xscKjkWeyDN1OTWjioHaP4xlYJQ0Uug1Iwkzxa7R7JJnJKoHRMYHCYm3Mh
qLsbRONfQmPccYmtMRIspaPyRjaKsVAuMVJpKooMDspWNlnUiU6y7hujIcjbcqq6SagAdUoCTOtX
0itT1IM8mRtIkrnVKna0Mdp1LGchiPHKUfBS9IjuSRlJTIpLzJT0SyBT2G7SsQCxJk3spgqPThn6
7db9FzZl0XmBmqTHD55yi3CIj5Wgx1JnKla4BJZpbPBWrSTBeEjra/cSsjb49EjktuSbw602SWIq
gYzUZVzN4BTe4zMA+FMicJPgRLUb2frqiIpGBUBA0U5Jym1N8/2gBpqZzYjKY8m22Q7InKYum5Gf
xuZmvEs4+ozL3wjxKYr1eIBYJs7mvBmPfVHzDmP3hvziPap8z8p2tbVNClplVrOTrC+ZVeFsuNaz
WpJBrYoR5Wciu4Za0VR9AHKm1sB7bMxMa8KvPrSBmve2py7dukJzdZaudBEhnykWK2U+Bn8OxOqr
LNgQrkhjKMWjEcLWusw0RTlJCCcLNY5zTYqaSVcFhHjKYOQyZwCCAxDbBZrMyTRblB4Gg6HD6aI+
chyXo85M4Jm5OddTgy0lRVKw7yJOvqjT49B7WiNp89YBZWSPDlmZg0lyhNNRtN9iYRf28KBCVdYo
k4owNUyJ4gPIsYpIdoCJbz8vPdwbUXWbjksmTsJqrx1M1CxVaPYQ3qHiKm0DGilZVZEIoRB7DtSM
mZVuRVI/ZLqEPyKENycpyiPWLM/ULAGcMX5owNU7bdJuiOHLhjWsvnj1EHlpdG7OFK1Uqs6t27wV
PYQRS5llDhyplEenDp9K7KwOStduYrZi6yQ2UK3cH0fZ4OZoT17bm7hmDCFQkOUY8q6KqbNZJVF0
dMxiN1UlE1RIYhihCOg1hJp61NMUc/rSzwXOV4Jio2cqTdcctowX4r2C1xcum9jn1ePFo/TpoJPH
JUEtlDcpOvC11Wu9RTCWcCymd6b9SgdJSeq2WjedEFCkYsCQse6C4lh4nLvfwlTH+sW1YwpmqGiQ
1Nr6bPUspU0p1c53ZRoiuPZqTtTZKpNBlw7soD6fdJAR8UDAuRQmwHIYAIfC3pH4eh6w806v7ziJ
aemcrRlwikanB28ImIqJsiqwsdMppOZCHk0pMyLVFVZiQpjmOimoomAkKcwJdN2n3FNtU9I3LZjr
KVhk9M6UDdqgxfWiQhW7srG2XqOk64rMQ0seTMymmk1CrNXwNxI6SanUSMcnfBss/wCBNImJ6X6Y
S/aTEm87L0+rVG+jVpEWtdm3VVRNVAkRfyJ7HGSTF45jnf0LIy24lW+jIPP7PEQIUM7ELvCxtQoK
6qZDqEt8QbC+TkjcIXHgp7MIGlXr1atLX7UFgw0larsdYcomoPDmXqXa7bi3URE43Z2EtLl4+PtM
c3xrYpm0psIV9KOmyKqLphZ55lIySAmImdpFprKFE6YC66fq3w7J4e064ryF/pBUN5pwu+Xp+Gnd
PL6tRkvYoDLE5U5cYdzOTF5g3lRewnq4lFNnUShJnSiwDYQTARF6ejgomn+96XPSETGYceTV0u1E
oeMJavytbZxEhaYdlIWIUSDjpGajJEre/Slg/Rrx0ZI7RRn9GJBDcOBh0ZaR4PU+GoZxacx1jDSu
DMSz18ZxtnNItU5aSi3HdFSPHCISwQVbRdfmyp4sXFyTcfQHYgp7HFYV4vsIyiA4FBiUprhSl2S9
UrKS/wBGNpWqAsAM0vumRfvluseOl70h2mXBuE6Ziydw/Z27x3inP+MMuS9Rp9BlWuT5zLc3BOqV
eJexztph7LKylQY1ZaLawC8e2h2684ybkeEUdtynD3AGo3F+P9KutrB9weT7a4agIrBzXHQw0AE5
FoOsWT9ymbArYn60xDJVoXh7kwGLFA853jwxfsefsD8pVYDwhhml6YdKGYJouBLnMakrrlBnkeHz
ZJWElqskDTck1TFNfqOBEIWFmDNZltFXWQnZMJlGCdN3Zq+quQgumhlBvjPR12TI0znc+M8tUFtT
tN99tNYzdP5GcvaYOJ4iGPJDWLXPliPGmtsNkKAhphk1QpMW+KM9FSTJtzumLpNJ293a8x4WNEYI
WSzMMJOP5mM1kgMA8kh0swwiAD/KGXvKPwv9PPdZy4q1JYdh/Rx6ltNtgsasVlrIObKbf6fDKw9h
lGUrX6wxiEHfazjNqZgg6XXaOkAAD7mVbLpfXRUArNqurbBUBoXyHpqmdP1Yn85WPIxrBXcuLQ0W
1CJrbmr+GJrHsR7EF2RtFblvzuNiTMS0+TDcyTpTz4mXTjoeqUrpc1MZJzbEild2ujyw6qtOzGOt
U9FWUlQi5my1eBtk/VY1otXSUy+STZd0mq9sMrOEIiuojWjdkcAgR56LzVEyw8GY3L7HcfBH06yO
qFWrL2S2etZMSR7J1JC8OqpWQp5bKWOZPHxok19ByVm0dORT7BuqciBuMdJUAUqIiJBdRH6iUIVh
DGbIAJAeigXYvaIuGhuuqgMxQdV+6flna1Cxa4dOOQq1Qsnxi2KarC420ur4kurK6ybuG1N2R7Xs
W3Olx2FaDj6LUk6ZZMfW2+3JjZIUszZghpEkWu5uDRqRuc5RSiGel8MNyMRa4DTFL6y2emu2zNMb
w7tgywElj1WGn5EJicj4aAcwctrtrCB3kkwi55FpBySTKnTyd3PPsXzPiqjEenTKeZqnlbI9VaR8
PjvD9Ge2u7XCyuwrlTbqM4oj2LpMA4TEUZO2W18om2iKY2cKNba5UIjJmQVMUonXP+i3v1QLD1Kw
Wx+lkax4gk80V2Yq9MmHuCHrVrj2fyu0xtL5LfykLJR2YT40qq1hkllqqnUU3M4xjFrKAPECqaUO
N0guFFTEhQTEuyQUQ3AUtKcAUSCHYYk4sIkVO4LWoUQKojLRMOUgVOHU55fva0Cm5KwHmD0SWtOH
wjiWUxDTanSMVQSVIYzVKdq2a8VYRmbXkVcyrmNsU2k+ZOYQZ+UnRkJqTrsLGR0az8WhZjkHTJ2I
NaGnLTPlzB6tdm9R9luenwt1y7l6etczc8G4T0xsmQnZY8wXFWSUjmbi8xMF+kDTzWkRb2Cfe3AH
eG2HilW0afc/VqxtqbL44tKc3J41PmptCJpmlXC2LTxDmYeX9JWFdS8aSFbQrR23cPpWSGNRI2cC
o4KVFXlnGc0+53rOjqnaqHeU4NfFOUMjq4uZ0iPyBY5K0Iy76DRnzPbRXYVk+rLNt6vOW28a9sSd
gBs5brDFdkuiY6ftKoMSOuMiKgXnC8PZJIBSlAASosTJJ7WIkuSWDWOCVj9KKokDNh8J8PLKWW1l
MP4c0m1WyQmpmryN91KZLxI6fYzxtWJCOXq2EG11b+GRWRsxW5rYDyD3MEOmD6fqtCgUZ2KjI2tw
UhIz3dbA1WXuUzJh3S3GZ/h8bY+q9b/IvLaELtb5yoQOJKM/xE6psBhzJU+Gez5yXkZqwMsrJ5Qi
XUUe2ulpWwFFOCamuILOGxD0p6r9E9700XGUq+YM5YMlclu6hBZFWqjCw5Xn7JbULMxF3Bx7V1L4
miGMjZJxgHhzV9Izrds0U+hSnOf2eJouWjHXdiDFmRaU5y0ZCLx7gBrmDKumaq5xtRJap4PnW8m8
dksGP4p02o7mGbM5507noTt5NszakUcPCJpFMfhhEeAm7pVFuq4RwHCUgkEHZnGx7TMJimKvWsli
iisRUjOQ+s9O+dZ2b5dBVPuGmVHWfTrJkqNwRB1x3DWmrWumFm84y2VG0V31SUptahU4yhv9NMo9
cVhBTM09e0ZKKXYz6SlCSVZuSFfjfH2D3voSbTlKLxdXY/MsDrPgsfTGXpdrGSNslEn9HgbEMPXp
RsxGVplPUSVQcJ0Bu6VbdiYqwOTJqFEK03GpHOLo6oSWYsnvFlqCtiUzl5eba7AMSO/1mLRI9nHg
fk5D30ft/Ag6iIceG+pXL8HiaTwGztxUsQyMivOP6O8qtSl4ZxZHxF4Q9hBSaZPnp5uOr8MwbMrX
4sNsAi6AFlABVPfFjXm53gjYLwMt5ABgSAAQCl2GZeczQMXCfiPlu9OZv9Atx0pacK1Go4qaYhxk
zan9ELZtTb4s20lpPUv+VRKEyRZmV6QvpRlsfmrDSQraZVKuWfFylDF7waABqAn4ZFd9GbhuEo+n
HH1jj8WXCU1LYkxpPSWTbLkqRruXaLkPU05tNUxmTFuI4tQ0bcce4mkqbGOrg1lJbvdl3nTMjj3V
1yU+Br/1Jnr8lXXV9i5Y73DzzARr9Y6ZWJ7K6GElX70z3GiOVpBk/vw1R4jITkYmxLKeJKRUiUxQ
FFUBN1W/SA5wrtYZRL4afeLhVqk+pmMs0ZDgHtvzjiCtnavYyCjsUZRm5xexVRzTiSE7MY4emTcm
x9IyJTV80MdUom0FdI9FqAB2fYZTAklTEEhyWc4S/wArEEK6tNlXrK8pU3bvPi4eXGJVrlina4u6
TdHrM5PQLlRFMCAqeFnfB03G5dtyAn5H+qO4dfgy1FSqjsJR3232ENh/iHu93TjaScgZ++XeLrmX
VcLmcuHCpg7Z28O98WfLLCbqIOlvYKY3RQ3sgIiG3Gi7wn+r6dr+9v8A4/D799uPJmpajlrFt2Y5
CBuY5Sh8TGAA/ERAOMYKGETABUxEv1gAA3L/AHg5dw+/jsphE3MqmQxev0fTmD/2/W8vlx0kcg7G
Aoc5NhVKH1lfPyDzN/Eff5bBxm4E/Grw4c93C3WwlB0YOcopmP57FEBHf7A367fx+fGwMAtEjEE4
KER+qYogYB+wQ3Afl168cTeN0/qpb/d5/b8f634wOXqRhWMBeYg+RA6mHy8gDz9/8PvLtDoOeTyJ
j2Y1PPJ5E/PMfYB2HYy3MUeUdhL+8A7bD93T5cJwU7Tbm6c3lv03HoPs7+YfZwmBcwmXTA4CB/1u
wgIhv/8AT7D7X/s34xd7JsI7BskHMQemwl/eKP7QD8d9g678ctSV1JEmpqAPXlnHbY9O17LlT22/
Xbl5N/Pbn+r/AB4Q9uYAEezJsj9Uemw/4dPcIb/LjD38neOTYOXz5vd8d/6H79+vHkFidkqAAO4+
Qbfy+O3yAfLpwLEnUc/v9dDbrKAIUdthTHm+rsIDv9nTr93GEOva7ddx7ENven+8Ah5l3Hz6h79x
9/XbEJzcgc3ZbcvL13+HLsO4+Xu34wCqCe3KID9g7+8R67D5fdxC1JXUtT6Affu7jYsNARni4/Qb
rZdw35dw5vh7/wAPPhQCxx225B5vq7DvzfZ7XX7uEnaqc3Zcpe18t+m/8/P3cLGCqKS5jql5k0vq
EEPP7A26/Hpv18h8+A7NPxnlvx4bpV2h0HPJ5E3nEtkyFKVRsiU5w2KdJcogby+qIG6/HpuAcbJU
Q2Ee0Jt168xdvf799vu8h+PThAlNN1QTHtl3AI9Sj2LhEPdtsPipd+nlt+PnxhUlmxh7MClEPLco
gIdR+ICPn/nwZCkooQZv4gDnTuNqWRSpxBIFR3ATD7KO3tG+QE+sP2gH8ONCCiQm2Dqn+6Gw9fsD
8PL7uNo8k2S+6LdJTdLqRRUogUfsMbYB+wB6caYFzKh9EmQPs2/n/wB/4htOJOo5/f66G3WUc5gH
k7MnL579Nt/wH/H/AB45x47ZXfb2N/hzBv8Ahxzghwku5nu4fnmpNmNTzyeRMm45TtOz5DAfsUeU
vIIG6+4A28x+QdfL57LAV3DlAwCfffnAQEPh5gPlt7t9+NRGKlFuCiJRAR8tg332H+Pw3DfjZiuK
YAJSEMA+QgIbD8NhDz26dAEfPjc252OxwhtXL1svsxqeeTyJoXaoGW51RAqfT2EhAfPbboAj9b3A
PUduFDeQFITGAwciX1Cbhubf90PMdviG/CRyKhvIqZv9m8hAfL63l19n9ryAPlxi7JX4p/8ANxRc
QrZwA3P3tG0Og55PInNmFMnq4wyri/I6K8mgpR8h0m2qpNxMudeNg7RDSb9sUCyxhHtolJRqIBv+
rUKPUhtpP1hXGnXHUXl20Y4n2Vqo1quElZYGTI2nRN4VLLJumzY0bNoIvjFaMVU41TYogmuomiPK
ocpRFBNBwZHsiGSIqVHZIRMBe0N8CbiAnH7N+v2dSi1BVejREpQlKNXSwcBOYTxRcTHcyE/NOJeV
sFCj5S5zC/jMi/FqdvkCMkWqLE3KJW8e+JygLVwCehCVtOjrzAIA2AcLHaU5TUUFcrZ0Za9oleMz
YNxL17vOw9g55h5yiBif7sOo/gA77+7y+W/DypNo9WLRWJ9GvRNs8Cl4uXjapORLefip52037CPd
11ZRJuu3lP8AzRO2MB9uoDxGj56kzHlTMUxunslMAm6/IB3+35hxqU3Cyi4qlA5eyVRXKqVbsFUj
NPqA36lEd/dybiI+Xv3Thx8MW7rAH6DAJdgvs9pp+GozIIaCAQC9R6fnkTv5yvA4pa6gtWT55jKG
pbqbwpp8y3gCpxmIa1PRLU4tMZ2zNsZRMOuH8NU5B2vGSFoav25X7lWv9wuIPCtu0MFirk1r0KDg
s9XmFoNOfVmCUqOM7s4qLWJRar0l1c8SY2uVsaSMdFmXj6w0ibFZTxf5mucreTMDJTkcmBIVsFp7
vT6w4JGrZbiJJ/lnE1yypW73FDb26FbZ47Z5TkLjWWS78sbPOZmJQolyjWrlmhExcjZCRjcCmqZk
7oMbZix3lLGKVfuNpl7Mq2zRVJiTRkZZzZIiamIc1pj6/PxGRYSafJTySze4RjheQQUkJM8i5LAT
cQTwFy2Mf0/SEdMW7Xcr6PVdzBIKdmFHF/xAYuJAm8Bs/wBNLSkM2CqGmNs1XhQnIsJthPhl6Gdr
EcTUDD2YMT40NmPEmPMUqap8vYpxjp8tWF4rmuEY0x/ba7Xc2SFof2hdGMbO8gSsfKN4+SkPFZlK
0yaT1OqDGrFKaPcx6SPULLkjNRWEoe741yLka54WwxjXGeQbozdFyVTp6v0ZVG4PrKwTt7ybdqRc
vJpoMnXqgo2kE3BXZk1AMYTMeVbJd3qlIja/qAhHPqjWcjZVqeIm16yeNix0enTtjmrqpE1ZKHGl
QNnn5OvzV7i21ftUdK2OJlKzcJqaay0ixQWIxinq5kMlYio7rLMsnlBV0rlyswloyA5aK4+mbBXm
9tbWa0lsMgwgY+cs1UdNbitLzLiQslginKFanmbSXWSKZ2GuEu6gm4qEhMA7tzTI1oC28+zj/wDq
YTf5T93ThzhsQLfQfp/mrjqEmmNnsLfG+IZnGuOCV6r3GvvnVfyDMY7j7dlaQlLTdnDGOsNSgbLC
3mJqteh14uUmZUkcwaEVdmIlxAmV9GGNsbzGaaI/seTnOR8DUt7N5GyChFQJ8QBKT05GkxTANHBX
PrUV1fouwUCLOv3EqwXxy8jW/PUD97HqFqGrasXKtQNbajlKV1KvH1ngalFqVPKFIzOvWJizGl5l
xV130pU5NeJtdbs7+TWkE0gYGO5sLoyNeSVULrnmQtY1+qWoKtv4W45BisgX6Als1WVSEe2aajLf
jCMlvD4ttPJu+5RKcZBN0E3EHFKuFW1QhYmrqoEggRiuKLXc1w3hXOKhSR2ElTOGebZ6DjJrVeJ/
dV5bvTlg0cP9KLBXTtNai6ld7J3Ctz9Yq54W6VGKgVbHK2Z+8RmnlGbQV9n5KVi6zPxq0Y4c2wKs
g7ZBAJxJwBy0BSDssYplqzB46vitneW+JyvRFLjESUkzVjpoGUVOSNPWZP2K87OtiqQ0jWCsm6ak
7zIxqR9wKQhtiaZZdybAae8iY9isMM4mj5LaUSHu+RmVauC0TOtcU3J0WJE67t6ejR08lOMnkTPT
8WmlZnkmzcsHDIXaCqRIyydlxS846wjjxvSkK23wxUJ+tN5fxN/LyVuc2nI8ncpiWO/kkUGRDN5+
edNGTAphMMcRQSF7Mo8Zd9u11ECMyFjb9H+2q6x6qwR1RqmVSMViwFKptVSZpUbCRPunPXuDEjB0
kvsVL3jv7A7j1+z57fz4LOvY9zbP6UrLei5UK2wPQcvQ9KZYtkLpdxZOMq2+Cd2tGcrGOXkVKVBs
ivGsHzSRmZ2Wrk6QWTsirMO7LckDiIAUQEEgMHmqIlAoB59TCO3n7t/4cE5jbK1TicB5Zw/Yk7Aa
QtmSMdX6kvazDw75mxkKDT8nQUpDvEZCwwpYxSTG6xyaTxiFgMqeOVIUTGRMAZVxhqhGMmLGWgxw
CpIAIEkdmpNBXi9tNaUxIW0KmMpDgnmn0Nomq1hzxDVeMna3abw1o2JsgwlggHyLx66rlKynIs3M
jXlK41kWsxCRN4Wj2Tx8zYwCDmacM2jl0jDHQQVUIVSFd144IzVC3Zmynkc66iUbBAtSmiavfZa8
u7/ILyVzgHsQqtLRDGzuXSDpG2RHaBJVpZF0nJtmp05ALI3ZXPkPZtO1cxJKwDiuWbHNvQtVVlqi
wYNKNbWDlB+xGXyZUVZrus7kJB4evos7x3KamZeGkpBadlGLcxzCSkHq/rKGu7Geo884+So8be63
Zp0bBVyvnsaSaikY3IqsJXIw0+qxk52VYSTyPBJAj6w+KIHm5xp3ggm9BDVclghd4jLLAB2DyDAz
cTrpPWyfs6trg2aSmRd5+79xYUKjVtUtHtmX8D1jFp5e85TrhIbItMLSWlnsyFUiZhjbm7qEXie8
12FhDupOOKnY4NdyxMeQZAVyIukO01jK/wCcDYNnNILDHzJ/XK/lF/nGeJHVaVk71XrhFx76jSfi
Ek2lFYuNg47xWKQfOHUSi3ZqyTBJwdJR43KrYVp31RYzgdVWrvIltvrCGp2VcMZ7oeP7BcY2ZXix
Rs15qVmxLXyxMCgs/hQioWuJS9ZbBFpwUeT9FPn3TlCGcGZqGv4g1id4vcXAZRu8pjOywNuf2ucZ
5CuqrWasytqSiVmrlVrOJzMBYJySlIqRJKG77YAUWT3GDEBQwoo2a73GSJELCUmpDAOa5GUwzEuW
vs1D+mjLM/J6fXSw4Zg1IXzOWC8K4YkcdxMVFaca85qMdcYVe0yEzKMXiJ3C7W4uZl+k0SN3dJRe
JSbimK6JDqIFOQpjBnv+plXIuV8KZRRqcrVVsPVnCdJlVoa3uXk1PpYXYwNcCTG2uCqHQnJmMMVR
0m4hpZweYMVESiuIF4NlbJdUa+iwr9UjHlSgb5J6sbAFtim1khZG3W+rylTlp8lse1YgnkIqOZy0
RX28bKq9nKGi2cUqk1FGztDONlrkVrrPSnoNRpbOJioud070uQurWBk6uq6VucIy7SUsnhTQ5yxM
xOwdws0hJRs0uk4mH0iwNZUmBoUopnCCWHtUaZaiJdmZnQzap1A6zM4EMxSKDX5d27nODcSa36/Q
/SFT2tCQr+R4uoT95yLaZCl1qcjpi2iOSkZJoFXPNyEvDxgNWj58wklXgiBUkXrRcxgI5ROeGKTn
+BgLrqcm3Zr9ExmcYyZZ02z1lswd3arvnGR2lranVbNrfWiNTS8c3eNJwIiyuxOM00K1Gw98QBQ9
sutsbNdXumTGMnjWMQw8ax6eLT6sK49ppp6QrWQapRX7uqSUXGM4lpIVTvoC3NUXS03F9uHZDGdo
AlCTY+pY6uOs3WzQQw5hivweH8M6mYmoRRcS1EIdm+o+VIg1av7PHwkCuT2QgrxF0myrttAs1ESO
DJlMQr8bK2IN7gxhDTfYSgQJlKQcIIYFtMRIBNHbWw0qSn+mk0zI5f00mLeHdbmLKVquzjmq3xGR
CUTLOEbnjZaMiIOuy0/Yp+wV+kNXttukSrfIWKZJz9hiJ+yTyELNWAqrt6tENgsMgd7YbK4sK68M
XU2s6TqraGU/GKaYcg26SlZEuP4O0yN0o0/ZTW4sfSDGsSadEvShoCvRMw08TYV1OIkpXxGz2COM
/rVmJ7EGH9PTbXNpJruQMK0m2UrPmljF9hhqqDJhARBcg23G3rSOS7bRY9gpBJqLPUZtFKhwb2ww
ai1xAhFxPFgUorURvgSRYPdNFaxtiWV1VyuquwU5i/ynAXVGmDQXDZ1GVSrQEtRG72NhH7m3sXhV
1XMfCqnjmbo2wkbq8l4f8TVGMODeIERJAOJRTPFQAgs4A4dYMatSH7Kufs8cGVMWqaU0Ld9pH1G6
5NIeoVWZtVhrbVRtH6WmuPqLT31EiiZUp+oGJnICRq0s3tjVkWOUx5FR8XLv3Tct9FSQZSBXQwhk
FSqCJuSc11a84stV9yXasIWvN0lc8UW6rSeH4N7X8m+MNmc05vg5MI8QjGbhWKZqpxahY57KHaOF
E263ZKHKQXlYvRc5arkL68XrLGnnHzaZWy48i4aWvkuwSj3+I7UpCWeIjl38K3A8irMJKxzBlEDZ
nJ2CahSJCUhgBVqM0P1yt6ddPGYMNuRUPPaZ6llLMtefTc7Jzybl5Jx8LYrWwSkWiUN6hJzMtFRD
tgDgARk5SPYKwxHT1sioqbx0tAIARCVMSNMtO7lrNoXCQzKJpUDUH7nwtLmuTNeJn1bVzLg7KVUr
eoe35+ewsRO4Dtjqo2eawnO1+afydjyHLUOVZzLqedWZVKKKtJumJlGqiaQGHnIUY3zPnnLuR81Y
S0j4tzm6psNjhnE6a22e4242du8yKeyTUW+vd9u9kbS7qUdV2evUA1l2lWZyfcWTQ6cSV8XnKmIy
paF8wQuOcTZZfNqwek5rutQxnXpNCQdtnDeyXGretEXEW1KbhIAIpsLT8+Rewvjvasw70QxkA5+J
UybokWh9Qcdpcw06lck5Jjp6eqViSkIuJrkbETVWcBCTNnGVZO5uGa0KVZD4y5Os/I4iKj9Asuk/
DtOGo8e+rYR4UCEfkL/CC2LQkA6UNWNYaboj3ColiXUpvdNOP0O+0lyOdJ3VlrhZyEBh3FlnxxD1
FPGs0llg8KvHw+IKGYCyeULhkg0U4fRk/DNtp9ayQbdWUezv6APWhdfQcRdoKiai99IrjGqUaFcX
/EMxkJ9BO4y10avSa05UXLCZQaPZmBkVLdGQPc11U0VFnKyJE1FCJGMU5ylNvs36FJrCWcKpgRtl
mgqP8jY3gLKxvcgrYaFR7alYYYZEsBHLFGSmBTfOwFGroWWHb92W9g4V82wcDzibH2SYfNNaxlX8
gSWFsg2iwRFQZSqk/cKyVKbnJblrrJd9Q4ySskbHqH9l5JnbppAb2TKb9OEwq8qXAhpKBskgpUEg
FQUAZ6SOldDYsPYu0JSolO0AGpKWVd1MgbBxZmQpSj5BA6JSILu9jAcvLuU3IPtb7dFPYHr0P7I+
0O3FsOnvKGmqS065JlL5psxQUcG4ZrNBbINatHzeYsxZmyjL2AiWWH+SpBolOxkbjs9TcFKxXVlk
VTTLQp9jO0eevq4VItasstDvOycyERKu4VycBKZBdxEy503KoGAdjA8USVInt+sOkchdzEMATCzx
bkaBwRHZChrW2b4rzDc5ilStUrlpfGVkrViyJi7SxRuNKO3PEAnBMrYSQpxAeyhlWbhF09A6KxDm
xbnBvEM9I4EhdJFVWajZ13luNiqGOEFmR0yyz4jwsER0XZ11Dl5DEP8AUIUeYT/3SgIibf37B/nw
cWUNFctjOIqT5HJlJvJbs+pURUHteYTrWv2t9dw+k9WZsyR2Kykf170WXXgTN/7QCcDkNXbmMoCj
XZVscExTSU+kKp/uzEL7RTj7iiAG+AefEz2rUHlqbpx6xI2ZJvAN5mGlVQrkJX6k4lZyGKmeuSD+
XrsYhKuXUURVI7WLet3SsuRRMySagHLuxdtiiHgvd2iw2niSl8xOdZ+eciA3slkBrxCTSispS8j3
zzktnNP1dxRmSNod/wAiU26Gicxt8X5FruOndxg7ImZKY7GblIk9srLfng1Vfoox8mmLRdX6NFQx
+nBKZd9GZlsuoFhirDqdZt0fesz5fxlSOzsS0g9hhxQ1QkptS+yrkE2McDOoWGtGfDFnne6SKSBH
HZqHT5gzveqDIGR7ZDX22VTGAWJpeDZHlpuCobGrSOQbGDsZk0pb5Bu5Un5pqU4CItHbxqUOURHb
YeCDrfpONRtUv1UyW29Wk7PWMy5SzYYSMVGbaYs+aa9U4m6RC540HBWsaCFcTO0KYSkOQOYu5evB
MfR8UBSoJQnV1TkjJqOzgPKlLB2a/wC69NPl9B475at9ol1c4guOIa/Q05Few6ik7AfGj7Edtm2z
W1MqlJNT219KT8c6hpEkBGkfMjy8hMps2UeR41M8WRBykJ5Y1naFdQeOMvXzH0Hf8hah4DT9iuqZ
ast8tcxJvl6bAXKO7NM8cZxZJl4xculNyIDEKOO3MAlSEw+SCpekkuuKL1T50uHyQdeiMZ5OxhP1
ix3bIM7ZbDB5iLGKTdhRtVjWev4J+QkC1PHrRKCIqlOmZIxgOG8kvPSxwt5s+SZG/YretYjNemeC
wHkdvWplF47RJRxIFXm6pGTBkY5oqUVkwfKvXA9kKpAUEOcu5bwm7GMIN3iqhqYTSBimU6uAyXm5
cyIE7LoReERMYhpPyuWy+u+jCuYP0bS7myf1KQmkGzvXGIsm5GtEdQ5uMvz2aGHZSkw38VhUrahT
zTz1NoZf2G4tgclUP7Ke48M+pv8AUo0u1nt2JrDnBxeIlUYuz3TGVhvTG0dzlF1okG0paavNqWJs
Myg3cGYEcyKYvSILGbAoCR+UxrRrhxtd/SSY81tS1OyDCVmDutEyDd6dHlrctZ3k9T47s1WtWbuL
FCRzhB4p7CQWObbdob2Sbm4YWF9ZVbw1SNV1Krj2+U+Wzdk7Gd1pVzg6XUrI+jaxj+SygpLxNshJ
K8REdEGkCZAanKnCuJ0VCIT5uUwSDcbMrChQybjt4y4bUKQmrzUXnKrHTKhMhkQ8Rgw1L+Ek5t3j
8DfYHKzk7KuJ5mSdUa/3zG0y/MlFzMjTLRZaW/fFbuO9JMJVSKsLaReOGEsPf49uq4MqJfpSE5eo
Oyg4jy5k2n5syNWGUnI1XE1fibBlqaXeoCVk0t0kpH11u/7Rw2TkEJuTSVfFi3BvzsqaiiSaoEMI
SbN0Oyas8pZcyPSrNEmCTtR3zlxk2eo2PLhKpT5CKRqzqvVd8auuk001E1CHiTCQSHIYBEpijwYO
kzOELpexNru0nZRyL+TC1ZqqmJ2NEsrPtrDjqt2KtWKdd2RCYe0yQlpdkU9XtCKbcrWHsDqXlYN+
jYJ1iszXKmBN3WXKr2gTAE9SmZrSZ0lMhnA3/wD4yx/tMuz6cyevGhagsz47ZsY2p3h/FMYeR9YK
+zkPDrC3rtgUO/MW11VlaQkfVO0pGNHyzu41gkbJSkpGwQmk1FFG3NMmIc5awI2nWefw/K25HH2J
VW1yy47qkc4a1aX9dpto1bTWoVVo+bt8mElHSEq3h2uVGFyK2Xe2FFuAqN3ZSHD6PO/aAaJWoVPP
zOn2CZu07lau5JbZkgomXi6wznKtEscC2rHMOgxkU5GLbSEfcX1utE7OoSdFKrEKxqKpV0DGjvQl
JUBTR16T2p2qy0GFuNsxRhhnjhnc7DGxc1YLNAz10mX7KoAu9bEcEYKOmvfERI4Uai5QFcqYLE3Z
2N5u8S7LVfn2zOFMEviKWSxcgMFE0wEEPQDiK2cwAZ0J4Vbi0swbRFUdZmsMuG7WyjoQtnxOyxhb
tNVst77H7mQRa44uJ3MhH4tf2+PRUg4YtQf2wkpTE3TxBSIbuEXEgmVNVM5kEz6QbI9vxg0x5eKB
TbpNV7Aaum6uZEnHllI9rtBK0k0YVCNqMRNkrStzrkLPOmcJcpKNM9JyKFlGg8pgAutIzlR/6Iz0
isEtNxaSauQ8Pv4KvyU7DIOpV/VSwMvZFIqCXnSGAWcNLQaBxaqmGSKx9rmAnQPceG0On0HZsNep
OYHWYpkiCSxcxYQoyxvUvw7s1GtfZPp1GFb1ZI4iS5zLpQ9saH9mut7cboPRY0YRtn7VD7SQ4U5L
lDkyGpBrIO5JIsRZQtnhpFO9m9PO0D5W1A2vJdeqmP20TEY1xbBQkISOxTj98rEUa12hlGKtZrLt
vhjKEa27MVhEZRlO5HszOTsQjGw0JGKFrsbWnz49E/SlWGbo6cvkGMvNnzlV8EWbB9HRZXySg8GM
1ZmpStIhcz3HGMW9Wg5TJVVoFtmYs6DNHujxJGGKJBKshzWAL1zTTIl03ssSsZdxiSwaHk7FmuKp
eNaa605vE4LH+WpjMWS8v3lzPuJKOzTB3ttUESSicE8tzNq0gBVtKRY+R2rhS0I4+vWnNPVvWXWR
65QoPF1kXmsazkawn852a8QUe+LH5Xp7F2ZCFa6T1VgjAsuQViqW5FaKyEFNrr1+CFkT01Xe9QFx
YqIyle0AJwKDFL4WbC7khiS7AibMWW2kIe5pwlh9Dlbcp6/sWQmnKd0rQdJy0ljWWwtLwieUJG6u
iZueZnkm8q4GIln8VaGbM+l1WbCHTHD0c8CNUj30zNOomyT4SLCywh/pDYbL6PpppXBbK5cphqal
NRKk0fHlMWpCzt1jGm44ZUxhPjlsbI2jkJGoPFjzydd8RIMm2D1WAXBOcl75MVLAeGrPR9U2mTEJ
c3Zk0zQT3BmOMQ4VpUJPYfiXYeAxWd88Zbb94yES0y636Vd1uHLNOJtr+dWFJkj9JxujZk0+z2ln
NGZM46V9L+JYzMGKbthPR/V8Q0co5Of5jptfPHP80SsqohFd0xdWJM/hdlmfEVJRa29tC1qt3CVO
7SsfXnbLYqWlWFQUGSkTIAJl2gyy78QHCTaCYnuDA4ALEmmHdImUxrvnHNJ1jYCbV7UaXNd4ztqp
k8p6bwx1iFDO9GhLjaMW5jkI5RA9hY3Cets4jHw1eXTOlCWCFXczBFUzppNeYolArs3+ko0vX2T1
lXuDsFpThs96FIrTbjXHx6hJxmYGmSjwIw3LkO3xyCzGTxSxIIBb0F8u28th32ShLJuHFO1W03Ku
sMjnq9Xqn49rExNzVVxdX5VnPSGRcw2NkwryoK0qsESKi/xvDy8tJR98ylKSgIxL5q6aQMLbHCCq
ZLjcveihxBjau5BxQ+d2aYylTcQXi4/lv9e2bWImsrY5w401H3CmOcSeys1xGbH0vSIVrbHQS1i8
ZNJNOy7cqiYBMS+RYezimEXSVBy0kiHiMywSkJQVMwm5zNunzrlb5snRg9nZUntm5CbGKPMbmITk
L12MbnUTJyhuPMcgbcxygPhdIXLcVDHDdqG6m4huqHsdS/vb86fl++QP2i72FzPo7s/oQ7+5RRKZ
bcXxeEC55fZfrlmOvi8tcMznxLWkbc78Gajk401FxkYWkgy8eGReNGQMO8uEkzzBqm9GlP4Xxzh7
NuJhtF/w1kvB2N8l2ybn42EbT9EseRVrU2awjuMgZ9yqhBpOK4k28WckTbd5KZuC3bEEgeZX0Dfo
aApaEwSpTAIL4jI4Q5zAJbQHQ2JDjQ1vMhuGbN9S53C1Oqhi8xUUjAoKiwNyATY/O4MRFQqBOXfd
YyTlucqQbnEjhA4FEFUxFGsusA8okLv8P2uvQPvD4/dxcXefRQZSo1olsWWq8wQZhaYZm8tMomPq
9zlMTSkRBUhXKDzGqmZnzlEG2UGePoiPurqt+qwUtv3pq1VuBEF0jHqZcwj8QKqUqQicvMTYAHmJ
+8UQ6mD/AIg6cKx+jl3YAxYYYgKBSpwUnCQQcwQZEODXMuSGUrqW3SfLXjoO6zNUXOI7B2Qj57AY
oj+G+47fy9/XhJ2iXd99w7Tf63T7f6Hy/nw5hh5AA5xRIB/gJRAfs223+W3x/HhCrEPi7KEImZMQ
6FKADv57gABvv1+H2cJRFrRRIMxUtVvW3W0+w/W5y8+/1eYOf8N99/l57cJxWKmoJgMHLtvzcwCX
lEOg777CHzEdvj79twEW9FTnBPcv7wFEQ22+IB5/Ly4RrtF0w2OjyJ9htzmKYpBHfy5jAAb/ABD5
+XCmxVqfH/Hnw3Pdk/F5cOf2Ntd2o9iBtx5x8i/tD8gDz33+X8OMfXYR5y7B5jzdA+0fdx5EoAgs
YVCgcn6sBOHMf+6G+5vuD+HHoSFBJYBENx8tx2EfsD3+Q7dB6+/jogUjJ+MtMq52BtDpzy/ImnEx
T+0mYpD+fKIgBt/PyHr5/L38ePY7LblHfm7HbYd+T97b93/i8v58cETl9pwBBP19lIQMb3+4vX+X
z+ePtQ326b/Dm6/htwuslPYdVK92mQ8ZCUrTgR8R8t3r9NZe+1Dtd9ktvPfcu3n8d/P5/D5deOlT
AQNyCBg233AQENvLfcNw29+/GLmNvtsjv8Nw3/Dffjr39nt7PY8u+3Tm+H27fPff8eKYPmPLen00
nGzGp55PInmE5CfVMUev7Jvl8f4cd8w7b8yO3x3Jt+O+3GLc+xh2S2L9YfcX+8O/T7+MyYDuB1RS
TTHcQIcxSb/YBhAdt/kPnx2D5jy3p9NJkt551dg6pdsbqU25dx+zr1D7Ovy9/HSagl+t7PTyN0+7
rt933/Zx6KY5lBOXsjkS+oYpgMUfLyEBEB9/9bccAxy7gcE1NvaEAEDbF+I7b7APx226b/HijK0P
Lfjw3SpgR8R8t3r9NZKTKqgIikYSl32FPfYwG89hL5gPy236/PfjtJcw79B6efTy2+Pnt9o7/Dpw
k2HdU3aBzmX9koCHMb7C77iPv6AIdR+9WYU0xVADkER8g5yiPl7g33/w6eXEYkZLL/fq7/vlun2B
HxHy3ev01ljEpg8zbfaIh/PjKYQDbsh5eby6+f2D03H7AHpxwgEWH65TfYYP8Pd9n+HHfOQQ5gDo
UdiCHkYfgQf2h6e7f7+O6wrLSZowO7d5aW7Aj4j5bvX6ayylJzk7UqhTdduYpimDfy8w6b/Lff38
c46OqmCIp7AP0oiHYCBugAIAPsCPT3B/045ww51PP7DwsfZjU88nkTnyBdmBokHvAvN8wL5cwhv0
APiPTbpv7uHSBlhSSACFES9RAA3EPtD7vl93TaP4JYoD2YmKBefsNxMG3IIee+/l8fd93DvScJ7b
ic4B8Q32AQ94f4/Pj0Dp1OWm71LcRZO267UP90Xy38i+Xx8/L5+XGHkN8E/xD/PhCi95XHZnKKgd
h7g36fHp/Hy8tvfx5F43bgAnOY4fvAO4fPr5fL5e/fiHS1fMNl6nxFlYhwUnLPcAfW25SMftUh2T
2THlTHcPaH4FHyEfkHUB4IW/4+yNG6e8K5ZsVurb6kXwLjD47rqUtLKWmJi8eXGWgptk6jC1/wBW
IqOTn2Uk5ZHirK5S8ElkHRR7u5Ic4mqySjoR3P2fZLbk7Iehg94ht577eYdODCkc/wBLsmjWh4Dn
GVnbZKxtla53ChziARi9Xe1C8soJ5JwB5AJwZmFVRlIibkF28Oi5MkR72xylKfmHRuS4MS79IISp
RUOjvbSGHaGHqf46GpbfJWKj9JMV5uJZVHfnYOVDm7bnWATGHyAd9+vlsG249flxkRV3HYBDf4AI
D9vTz2H+A/jxrXZjgqukJgDk+oqJgAhg6fVP5D9wj9/XjO1VAVeyAg//AJgD2Pj9fbb5ef3+7jDU
VJKShRJcHzTw/PfNtNBwH0tYdSNWOQqVSNPEjEYeryJNP5r9T6lk9wjalELVH3+SsErk2tWmRM88
GlZGThrdZm3h0esdzFFfmBRFMD9cWStUTLMF2xC4zdj61T2L8ZNbokyqnrhOP73LR93mJ23OCL5N
tjtSeUIwlJeEYMhBwJRpzLwsn6UJuEv4YzvjaO0QR+NsmXqs2iYxPqhoWaaVhuWbS9oWc40EwMb3
V4+DsDJelGSnGQg4VhX8yeAmkDAtYnjFMeYZr1m5o015IwRkKXhJuEsdqtGaYq14mcPZg1mvFWxx
Msp6SmISRYqN2TvD1OaLy0LTWdFZPl4n1qYmsBYvw0m4fR2ixbgIir/DWQAMJCGAkBPw0bJ88KOE
G9MEAcCfl55a1c+Os20SlYW1G0V1UlzZJyc5obHF+Q2CkOR/jmCaz808usAhNpr+OsK1cakckPIQ
8NIOZWdE5UrIVnzAHBVZB1T4xypinMRJ+sT0xlq+4905QFUl5uvViSjKPasUxNNq2QJ9peRs7u1n
ZZFqNMf9g2CB5E2kmkqmAorEMaNMEN08Mak2mOsnP6Bc6FQCzOYshRkXH47v8Rf4jHuOS3JvTYa0
zKSKMw2kSFCsSMA+nkawLlI1ofRljs0XGsbkTVvxvSMuadsCZDoNZq9HnbTB6m8ozEfFY5gJCuEd
Y1yjkG8Kwtyy+g+Pb4A77H8IyrtIp02wfQ0mZZFCBWgxUTKakOLfE3VkX2CpgB7smAo3IE5ZObKB
/a/+at3p9NJxpCapq9UdSeArxiySuNLxDhR3jdSsQipXDGdgIU0TEuc3NmowcrZXrkuQLeFwGaAk
oIXiMsrdV13VJ4mKksY01G0SB1pz+XI7JMZA4ZDKshfWLK6xNzXbIRVudTSM1YKtX4ZjNkjrtAwq
hGjU1iSGPlO0IRyWzCYoCqhrRT7vizDS7rS3h25Z11E5SlLrhWn41o8VR6ejjysFuOIrFW7ytFSF
cepb5EqZ51/CwktYYp/X26z20WmOiUVK6VpQmIcRXLKVtgZMceJT2JcbEd5BkIudslT053TKQ5lq
+NbG4jLYmkfJsJVsYQVpjnE68g2DlnZ7XT102Cg0eVev7QS6pvqohXCj3eI4bCohjQZd87G2YyPD
nx5E5Xs2bsKTeDHVUr9zhhj2+MM+UyUTs0lPEyTGuX2Z5TIWNa7H0JN+SmPoKeZkhWkw7TjzysYZ
5KEUUKJVQCH7raK9ZPRsY8iJO2Vo1spmoe0M6rUjWSNXuCNGn6juZ62rbCYGRRiWM99PHvnvhDQT
/q1ubpw769pv0s3XO0FhWEd2dstk+vFuuPLChb2bpvF1mTx347V6jRKunEmLkaWXvHsOBs01AOTM
Pa5RIO/Au1LBlCtODdSN5czV0jMqYAdURZzXBNDjVZqIuWWGtBccrEy/f2z2KVfMmj0niZVGrh41
brARVwkQ9b3dr2qGUGFch/ovY3EVZOGXX/y+WYtSDBD9o1PkB6WDLmMcVTn7ICD5JiJQER+IAPUe
nwD5bbb8G/o1qbS8RmrOPNU4K3S0FpUnrtVSz9UgbqvBS9YyzhBN3IxCdjYz546TcQk1JNQGtFZP
jFmmpfHPzxHnBlYQ7wKQjtt59fLb3j5bB9u3y268FbpCxRkzNeUj0jE+SG2NLS9pV1l1LC+lrHDp
P67WoxO4TVYVd1Jq8k5JCSXZEEjYGx+1GCjRApuzT2850dDjKvhVESFBPuElnBTpwMtQbOr6l2cE
ncdzfjws5cZY+r7rG+bMjO4xherrT45GAi6TyWdjMY5Vm3RGz7O9s7s/iy2FrDtYc1JhYoEphsk6
vTJ5efDVYGF9cye1YU7EePsU6RqxX6JWq7MZOwXp6yvYcnxDmZCTcp37H/Y5TJY4t+lKqPU5S7j6
3xIsid0YrbxScGU48nAY4PomX79kOUr2G5mXjJhatWd/cLmxtS9KYxeN2qKas9YrjYzykam3ozsj
ODTsMdNkkglLBJxrRvC2R29bJqy7ecQ6hXuBMdZyyRkpO14tQYylWxRB2DJczZ5iCoVWs7OsFXqM
NY3q7GCosVLSEfUmcLErMjJxz5nKlggTcoHU1YJQYe0N0WC4cMWqGynPeNcrCxRDEETaHRjTLPc3
hwsXxdNel/JeunHml+tOZfH9Mj7vbqLdHru1unat1bwJp2QqqVWnHcDKSUNK3WNdqMbc2dpA4VO4
lU40u8rEgaNcU6YsK5S1Dalqa4f3SJxtgnFd+yaEfD2OIXmpt9SL1W6fORLabm1EGcy1j29qmxY2
aTOhNWsG8R461agqjzRLZKdqpwzJYs1NvrCd/crt6j2Gj3Mr6Put1bTt7qRLNQG8rEKeKijPT2PV
UpNoyWQK8kTqEctU1kzlOO3i2OtPBmcLXBjQHhs2Z/rFtpdmrUzRK7fn91jbVPJWS+oMYoi8pENw
Uk6a4azZUDiNddMnSD/uyrZYicxo0M9i7RfdlhdqToHeUzKVmdhGM9vCyPa/xlPhy4tpaBgLGtvp
edM3O7tPw1Ax1bq7R6aggwgnV0nk7k6tcnVH1riAsortK23RgI5pIM4F7YZJGx2awyCgliYCWCf7
ltIMxVtK9V1SWKfYxcPka7WOGp9WaRL5335WtLOWqZp+ferGVa2WTbA9kGkQ3QlKy5SGcnkrMewS
Eay4Y1Yc5trsXl3AcPjN7LytxVrdjyJEBU5SetVaTxoLzwuWTaxUiudkyH1o/STxVBNBDtU+2ULz
l3zzGoG6TGmms6VSUOLNXqDkuayj60kXmpKeLOTjScZSsc7iU5hSDiolB6crRkdZZJEXJioJiKpg
ILoKTCERKEkuHTPRMq1kDnmGm4nGdOZfnkTeOV9O92wjTcN5VseR017Tk2jY4yfQ4iCbW1hMs6tk
iLPPQL6LskihFtl3cKlFxkTa45sqc1ZdPGjWuktKzhFM03MtHuoX8uUNRa7nGpp5utju/I2+UJkK
+xUpWHdQZDPTilxsL9iW5TDF8X6VlMw8bZJqwJ/SINFyhvwN+ftTrzONV09V01Ze0mZ084WqWKD2
hnZF5N7LMakwr6DC1olbEjWcOoqudNFFtDA67RU5EybnMUvEoKa6KjA6xqpqkeU2z2SFgWUOSx1W
1ScJOz0qq0xytjkzsrgjhBFZKPatnEvAKlKYh5FBcZIx1Ej7WSm5RogUpBERhIKJHuzOfd427ZRW
oOcPqfDjbdq6d9bBcl6dXVEyjYZ/KuoCLFbEmR6xli1tpeMgYsSxMpJOrVNnhLLToaHamLDSyKyz
Vq7dmKzjBKuYExiGExJq3gbtnOQRy5AVmawVn71NyFebVkBgizUzgzf2dnGz9Zk7SRaVcXJ2/rVo
kWlljoaLmnCQulkX5yJLHK+c0a3ce5Nd6THUNG5caP8AAdslJy0ZLtTWszWRbQ0d5GLbYisxqbW/
uwfRVcjFgawqclZmyafamCVAe0dhZoeyXqLrNuzlqEvlLtNireMM25fm8pI0m+Yqq1pipVw+vNrm
DxttrhLRbI9jJx0K9nkGTqDYWBYCPw5diqBuKJ7FCvTIXERKia+LkU+hOYAvd4kc/wBU/wDSnmeG
u/daK7dqIz8mMpSrfkcMgoRctdGkZO2dOu5IdMH0xMzr22SOPL5eGMzPRSNik/0kgtBuWpHaX06R
jk9rgiFspa+5PTjWoka/ZWOE2+NZCkwFyjqVHQ0vKYvaT7KRm4tvaEpVazu6u6tUfBjOTyLJSOk3
UcdKLcCqkYpSYrGsLR7GxduRxvhLDkNNhqguOQY15mLDbpSDmMDStWmoyu48VdY9Utk4u8h5ZVJ2
WizCDSkQnapmr0s+5yiOj0++kTa19llFfONix/M0xngzL+DcWViqVKSSzFDQ9smDuqnV4JsrKDVI
7F1dhk1HAg+lQsUDVkzsq+q8kimMEtDidvpAIIo2E6NXKVT30n2KK/8AIQZibn5PQ2HHIWqTU1J0
2q0bMlUZsKzLWOgZ7hiTVfcwsnepCuxJ4OOvBZUZZq6Trd6gE1Gs26g2wxzwpDlhlhApuGRknUnk
K75qvGc4aSf4kut7kZaWm18c2SzwLhg+nnXg0kSOmmzxhOixeJ9CnI+7JQB9kRDixLUTljThl3Sd
gVJ7cMWuLhRNKmCqpFS8Cuwe5Ng82QErX6xYKBLJM3StgCGQqsnYZV6dzHFFs5p8YqsUgTCYqaPO
eM8ExGFcNv8AA0vTD57hs116hEskW7rMJD2GBlqe7PU8i92cv54YRvMTjF66YTMvKklq2Zo6GXap
i3V5LXm7xorA31KuyA5DyZqE172cZ2tjShtrDSkyZifldwaMx8DaIdQGsek6jsq4OumTMZWZ3SMW
USDpdgoZ77JPJC+r1dj2MLIzU4o2bKdhKLmBGwLxxwJLqiBIo5zjsI6w+fpK16kaznjM8vcJlWMy
FCXib9SWEMtIrK1qyesrarVZhPzFbgIduZntHldvlwAVR7IB5/Z4O3UWu9rWOdCz+uY0e2u+KXPP
cYNSzYwreVMj5JcPJmjoRLO/d1FyFqo0ks/mEcbMZNvIvotWPepqGOdo4BMMdREXifGWop3GYJl4
m+w0JItiuUlYWKutcLJH/wDiKCgXM/Hvoa7NvcxfO6yBTj+rMO47CvN1vMBYiQ48FTDD1lswDCr7
ncknys2nAsYkITDp2X5y87QHlG3M7fke53CPj3UQxstvsk7HRqjtuKzdpNWSZXZE7Ew85SoIqpLb
8uwJKkU35TkEbDNJOsLC2JdPMzhDJVdmDzNgv92tDHKcHToW0TeH4Ky1eqw7GXxwtMzgO2EtYpWs
AxfKQ7Ro8jo5M3PPETIOwza86pCUXVrn+lViChq/XoTKluZRkJARbWFgWcYCvYx8e3hGyq0YCjZX
6LsisuYqnsCUDblGZdCDbBdrTdw+QapQnEdSUr3mXPFlyI+Bex2bGFciazH1Cjaf4lBdOFNkRWSa
P3zl/NLQe5JhsoM0IOkhOl0fCXDiR0GPCUIzEuoOkpZXElwWH0e1hO7gakWml/rP0+o4MxrRMe0H
D9dla3p+nseZKZ3zCPis/PZMd7f621BOvGc1F9Y5nbcchWGURcR+4/QlAeGBq31P6aUdO2G8X4ox
xpyv2QrBgyMrGWMjwlARgsgY+ya1lYiQcS7OcTrEU+duLLGNnLJMTu+0ZGQXTLsKShS1Wz0q2K5e
PBICKKwCKHJsBScoe0IjvygAAPtDv094+fEgVbFkXNaVsk5tWUK8marmOiUVZkWTeEMxhbnUbVKN
3DaOBPubxxZF6WiRvyzpzNj1zlS3NL7HH7Ze72cKNmQ5yqSavvJPAltLVXAgJAOAlwKrVp+LWwaj
Jr0cthLk0KYphmJg4yy6M3cM6xVGRNakXSV2jrynqPRiXtaRJMO42OOwhyOFWrZRGiHkGARZlDO2
wKC96QmLwnE12MCg4ypNCeOctZIYV+eqcjTisbFjaPjESRzFhDU6VlXaSbQ7luQ0raCNEiHcIlFU
DKkA0RZK9HNqCxdjibypLuMe2OnwVYot+fv6dbJF6c1Oysu6a0y3nSdwUQUG825YvW7jmEG7Fdm6
R5wUbqlLpNZ+iKwaPYnAbiZvVJuDzNmNWeQkk6NIO37NiR1y8kYzMo5ZEkokwTUD4fLyndm0/wB0
Duyy+wcFjmPDu94gRLjASIDFMQLUVKYJFCGyeRJqSWsDCP8A1MTL3U/L9P8At8C09N1Hrtc4YKnC
M2aClg0y4sB6owVjkjjNMI/kn1XpmctJME5dI4cjpBQAcom2BUpRHqFno/GOKJbV7p/gMxVRS70+
15Wx5Bng3UqzaV97JTVsho5hK26GdnkmDxi6aJKrPWjRyCfYpnUOAEIYQGbHTbJFwvlWgceoPZ29
rvkoirRxY6Ms0kRddAHaEY2ZSjV5CqIrNPzlJNNY3at9liFFP2uJlyHRdTjOdotbyFjyy1y4Tr18
5ocdFYrr9HtMu+TS8SkRim1JiWMjY5dB19EDeSSk3MGrumoVE/s8I3UoiRRfUQbwssEmGUlKHYOQ
QcQLzq4o+rG1XrzL08zra2bQ3hDGknqd1N0m34KaFxvOaWs33XGsbl7H1etkrAqwJAVbX7H57SxM
rEEXQHtYIYMGqLxL6RodQntcRxcfRRsq9dc4w7rMRGEBhjAWNNT6Eq4qbWVey2NLaCgyrUG0YrGn
cW+EEDFjk0gUrUoKhgLZzAL/ANYwEx+bXDdc0wGO6jedRjfNGXEWGKgUUyLkisz1mqk4qEcSGts1
J2VCYXqgtQ7aVYSjp1S0Ug7RdkUvUI/ltUGqOvytqbL53y/3+3VZjQrp4xcbFOK2emwn/hdcsBJ4
74ziAbeX5iANyfHrtwe9Xq7XdUExocUpghLJMOajjBUSchgJAYPUu4kvDhLWvaGMsEHsyashrJn4
0bMi4XQrX7WnmyegM/4bsePsMZEoeMY68NlXfqxd7Rk2KtNgQWra8y9rKTZpHN66jF2Azhwcrxx+
bxogpsXhPhH0e2WtQWYL1h/F9lxlKjRMgGx8yvaE/YCYtt1vJGzUwc9Ns7ODevHKBIiueKm545xy
x1hjXo/mr9qqrEumGH1PZJbZFoWA6cpkSv8AZ1SyZHrEhU6fc6QQ9YlJWs06Ykmt0ZqRUNMs3U47
Zxne3iC046SVbtQXVTOQPGNtXmovBT+SPUbAghNNcnlyS0f2iAZTStQyfDqiylJuttSnbHhZhyuA
1+5KsCMYt4zAUGQF2EvBf/t0aCYmxCCwIAUphJLPN5mZocgAz2Z2keTXpXDAndwbnQ2MD0aegCsa
ur8kTLMq+pGMrAFpq1IlIaaLB2m6ZEg62/ukmjVmSkLMRVvjq7CRTIuSexnIgGyNshDh3ckuwMvU
Y9OCpEhWS7ITkSUIi4UdHRSTX/UqKdzEAekW/sjbnKp+wJuDpwN6QzOenY9SNU4qkSI4+yDdMjUp
Ocj5NZ1jdGXB1q530LHV6dju2GbHtm1rx+jYtm3btm10soOObd0+59zv5/qx1qiaVWs+7ztrjFno
hZp4xZjwECm0CsIbGnCBPEt4Ks6s+tLP/UQ8ICXYhIsFiMi6+ef8Jamc1g0nTODkDlmSMyF0NJFN
c1NaCRVmOKpviWpYEngTS0kxYxB2gNEhgH2gwcDkyiFPL1Y8jXEcrDhckJGFLA6GjM3kDwDHxDok
+G2a48ZoRyADFw0lg7tHz+VEesa9vehwjo75RwLOCwxKlRFaadNAnULjrTUHkD2czbxS/qxBEa8K
tznKCVg/QfvHJ+EXkyHVB/cxLA3jwd9zQ1vnGG8cJRdbit9OSYIraW49XwADC33UIyXE1NCeK6fy
MjpcN0qfygA313Z4XpaaMBkGoUH3w2SKYRbEaEKrAi3F/Ud2WT7HeisITAahAO+RLuPkaI8uljQz
hiUDFjWCfkoYGiOMihIKd/mzlXKPkbVHLDN5gbmfGPj466wdQVhU8aW0ol3078wehsUXt06JCi1N
JKYBf0ZXtbaduDbQ+DF6Q7vft/78WoXIn9mgGQjSoLGh1jQDxJUSJUgFiACw0Uo5tZYHv+8ReHXL
hwYhyw6sX7/STnDH1pgyRvZdt4enoPSAzFK1i7Qnf4YsQ2s0o94Po1En3FtGTFW5dJakQNsf5kzE
adCproUGCD+VkVvvOAhNeoGnnldM95cNjdoeS9u2NLm08AAZhLx9o9aryBKV8SUR0/p28AIsKMEd
INOy5HBTWPk09t31xX/pLfAe2P5tp7koy+gxrJWt+109ASpRYMuIooNIcUKr3CW2nXeil4kYC5Cl
bfkmU0FDAckUZqeNmTujcsF/EglDmYu9dRydzYeliYupeBprLG/97c5mRqFLbL6G+bKkZG2EMa50
QWdRqrj5bFwb06kCiECU2RnvtCWvAc4q4biK9vpr3B0FDQzR/+eSZIJn1b6YKHnO8kjgBxmP6rSp
PJKGVnLJg3R5e1DVTxvNO1q5bw2ZL+yNnqNudfLt9aDklHPYWL22OkkJ6a4yZh0vLMwH8vXhH7pj
We5ZwH3C9E7t0jwrNsv00dnKpSTyD7kA5jJKZJ2HBEvKxIEZXvHu9pt0tvl48UYwaOqqhJO7eGHs
VdvybnvLiOOYS0RGcmg5FJf0aoYlR20p/FZUjbRDGISEg4CFZSaJClF2fqrAeg5voo8aBWPem35F
KnoyFDAFowvZU3GZpnPz6JsWgWEt9Wk5+g6MCsXadrRs1TLxDaac4rmG2UKbMdkqG8v4BqnNTJUf
C8EdofFYYn77fUSq8CTSGCMhSUKiYrvCUukJWWTECzBDI4IoykRmymWWwjf8RGhLRuZS/CX+B25a
1Xbr2lSm8HSuMU8mGQ3jQ8Oj/SuQJgjDyVL1GB9cNA9ykTjD4OKLZ3U1WyVRLghKjvNxE22QG+K9
3DUBM4aS1rXKC2mfth8haEij1m3G47z/nIFKC3dV0oxu5mgDLW9odg06DS8GNqlpYs0kLoGUfsTV
yv6cQaGBWjIsCYp/DAOlRd6GeCWo1X3kXFaieeo25e3bXLQVsyMz5ndWGlOPIpmq90BWMnJa2QvU
FmrnOVAilzLpSfKHKZX0r6zVznQ7d/CpWb6Dd9/OAEvqzzhm4bWXiJaNLYq0OHPywP0zLd/Rtidw
cSmGPzihpmUZl/KZsbyYXFnROhRGpuscHmZ10vWW3zVQC/q6RMUe9oXgBxKDQiQFwUS/Y28vQCRA
9mfCtkZ1fbBMLCXpS+imSEVy/VYdWAuBl1vEvlr23CGuXV0w2siN12aXNeNOjGpos9MGu60/SpHc
jp+acKbsBRaxjMoGHaIy7LzKYxMHEiwQX/+t65b62xNdGFx6UH2QVJoRq5ZTPyW3i6s6joxzU92g
8Xj/LfGbCXmBBnzLVu34DjpEWcdfL7BhI2re92qsF6ke4ZONdseUBTGrRaWcLhAP3Z16lfYpzheA
gSkO1kwbgzlSWJq4rjSHDf6fthtYuB3hrFn7bR6Jry6O1hO2BTLtU0nWo469+0VV1TH9oheP+2Lb
oqtXDDia+G1qhMw+kqtvt6IwQ7s81l5M62i7PVFN0kbJHJECvFK3S2jfnmNQT+NI/lYKE1CloSYh
JXMqqYCE991h30xBIdSEfMwqg5HQ7sSMgl/Lh5rKRMXcCXM6RovdyieAjrM6hK9mI86yRPTqsYPu
k4Lf8yeXB9LqqiuTTRML2igksoElBYUNOn6B928Z+g1MUWWMsXghAmEMTxuqMuABye/VCnOeliLi
z/KoQ/BUR01GpoYredd3VZ2wlKXAymCpt8S/tywa1kirhjAcwV3e+H3L9umZK7DAuKV3bbpKjtt5
1aPRlE5NnGbfw22lkgQ08fotPdcFrExHnzNKSzW0wtADo1Mt8zFnBzXqUie7B7UY2VENxZ387CPq
79UFv+pCuFvbgYu4rZXVdMJ5QSLHZf2ftuRnMLXfOVvLRGzRENggqYWozoPyyPuTYjXpcJxthkOC
khRFZ9m3diXPsnsMYrYQoNDimcCxDxlDBsfIXv/4MVJHvhnwOL31cco0QFEa5WsXUNuRg/tDr1yg
iaQafNSsuyii3F2oSQrU5Auu4OnCaxddS0/Lihx4s4PgGssrbryaDs6LtKqdpNEfRUpXXNWvF75D
v0zIyhtWCdsgC7n4hEXXgRZDcTosh2A9WZKWhUkdtZmKKwv30vmXNf5uZEpFcHZ0W+s2eUEtJlrN
ZGPi5W1Lk/aCJRNxwxivwOuoTgUXQt3Mq6cCyOmLDRErIViSAmfnZ5tDy/9T39qy1QBfCr8UpDES
FMUL95eeQBwKVfm+xYE0JJFQ+s0N8gWdy3+riH1ch42ohJom0fhhTSQtsC40zuOqd0zk2Xb4lv9e
kr9ylemcb/5w7+MLQKWYb8P2HvoLRvSfRVDu1bNGX63yiPkZWocP3+E0depqWpWqPezbc3C+O8MU
Xqaag78PW/4rgSqdfBUA+URTwtSCslXMsMLU843+Q4YIQHDzdKP9JD7cRk4bhaKUl0xWLAenklSG
r1EUwLlgtjRULS/QuqpskaIJjmn+TbbRiSI2fghOCVnfsQPw8u6z9+gwpf7YI4ZCGPfwVwBs75Dx
PIawy0Y2Qp4IFQWwCer5A/YYiihuphCiUQw5tHn+jco/06erBWzXzx/pny7UY0qpckUc7FxYbsBU
IY2e0jfZO1JcQyAQWeLG5vs0fHe/BXdEmkMD48jpw429fb6/ffFuGws1cVApAjCNjh2uCQKfYWD8
Q/UdvgC52DP1ih8FITteaRC2o77dIga3d0ioooxRE23+Lz640i6smI1l4RHs1blIZp9qyo1Ic0Uy
sm+d/rF7Hx42EK2w/ln97arUgftQWwIo+G19ql6Kp0SEvp9XAjFvfnreJpiYjI9WGP76DsV1ob07
BHpXDJ2+xIk3zvR+xmZ0dd35C1QYRYylr330gxsPTwD76UfXs5uncxLN5LP7TOqO4N2a/imw1lED
lHc/JNYiBVHRijKlcO9+UkCYTx44Cb73564fmq4WF0X0t4kBBd3ZZXQYsPinN68Hys+LHj8CWgRq
D8ar7e3cn/wu5wO5tdfhUZ2ntu1S9JyDY4Uu/p0vRQAiAQ8Re7dRuyzHQZglRU25v4IcRmAT5AAU
gmz2TZ9PPT+GkAMZQ8QlYjhCjBaUNzf6f9EfvAIp0xTkzZ2EJ3xL/tAIjwAv/QLE1jZf3e5uD3qx
3kJdyZckapHAQeyTPamO8qaujv5i1u2gxxAjErCdrm+BcHq5C3nz4v+D33LK72U74kqikcYlBBnl
m7MGgPE5Qsrde3RstBMhy5A8TwOQAHjCPZF2RK4J4y5GOGjjkfkiP/Y2r85W3/k/s3DX/3wBbPnx
buWOkMitPD56OjItYmHGgo+IMJk/bzqgQT072tfD2k0yolJKsEraThT4MgbPSflLIlvgYK2z20PB
7A9kOE4ow+heE1Bg+J99qPhPn11t0RiajtqlZjyxbYLAky+AbsvdSS/sjn+YCSMTfg4WLWHY7U6O
tz5nG8aoUTITypMd7sPd0zv/DtcIMbWXIv4EcesQ++bF7e7u8bv78XdRKnKiGmKpaKWl0lqutrQg
f+3Z7PcVvTCdvgMlgrHOn23+aXnkyGH+YTDQU54+b9dPEkdCqBBAKRgPf+wSlHfe0L3FPwL8pMAB
2CkAhqCyup2z/6XC0WvXCNLv3k5HxI9t7us76Arc5sPz6elWBuoI3h0/dUP8z70vAAFu0A1NAaev
u8eNo6gwqhj6EHv6Ip9Li7mdm+vUb3/4tds7QCj9p7Z9z+Z7B/LNrk7BkfIm/hvjR07v4JbAEwhp
8O3fVxhvEpvUT51SU/34Ouzfewev9tfkhzzs5cxOa1B0JTFLAfwrEzRl9itJwV+AGxiY+9vX3tEX
r2f2ptnT+0fIlWaEa9Wn1XIcOZpexeJilFC6V7OKQw2o1r8RWxUzEMmgDu+ijJkN5hTmk9FG4KES
Zgc8VRrXZmkbtOz0g0gN6BGaQ78zFlLVJYkp8Xwsf4IK5YiEHDKq9c2Y/FtiwtOIvfiDIO+QuuHh
0V5PTI8Xr8QNJAbDBj3/kFJBHlr6Z55VhQrzq1ZEZ7AIykQkwhq/XspazQGWxug6sUynM7rTJd6u
ugPYSW+nnwDw8wq2RzRXIc9eoILnk8fnCzDnEKXInJXX9mjU6rJV9Jd/nkc4pP9t6HFwX98C2q7L
FB3jd7tUXOhQAThhDOjZ22eLIiREjitAxCEVuiqn8+BBc6Af3xKMz1QNJPUxRYcPH17dlqh03MLe
9jODxv0TnWgfnM1bWNG40Lr1lDk11cmUrk5ztSnYSdigej9mdenanuD94y+6RXsisblLo6Btqdv3
lRRmz89dvNUGNItCe9mFFaAywtkjbhHtuUt6zGnzd5Uazfhf9KpJSXdeeMPsPrBilmdroDCrgwoT
eERidRo1cp0h+EckoyKveO1QX4O3qiSnj2tooJynDcQ54fEBPeOMJmy3rmeCM1U1jIRpxViJ+9rv
BEtpNy5kimLF5MjBkHFCRVgnzmS2X53GphioQY7YTN3x+miTJ5e61HNzlyNX7r9QtusKVA7TAO63
K7Oqq3i65YrQguSXdztsrRHWOF1NN4W28k7wBiwo5B4tPJX9enSxF3abJNtZfr+l1g0VbGaciAeB
NBIDZY+u46mSzPWcZYJsoQe6cGY6PsKTja480wEvsSfsE7bsno2aUU3tLZK6NdifzYlm0sCCX5IM
+hExlYGtSWd0je2bvGuyqithvuMcDSF2Vq8jmjN74VfYnaTLaauShkN38SxshbzBEbTU6dheUi1D
Jj9hRMvmGq0iLsmN4FnMoVccY+0RwEjHCniSNEgXKBMcEZYvJR/sWj2Ce49oPt0SghJSMqPlOCiF
5NwbnOYS4kWNqSSowT4wHtGE2or3spEEpQPuTY/zgV48S6oD0Kxxzgi/SEVGT6zF4UM0AbSxwBQT
UJl3wkNDKje7paNOct+9WjsWa1GTCXfTBxqBM3Xfau7oHOU72fxyIlfbbnx2shyNEa8yT/rLcB9d
+ARTAzpdXUq9XZRj0bI0f2Hqn0OGdAhMxWPNI9ypZiCFUBLP2Yy8wzRe2s43StYlq8m1w5oWtfkG
poghdtWEmNLior0pUp2V6q2pP+fzMbjzZw9nvpYz0w2HGV8AdVns7wmuILd1rOce00JGzanqX71O
lnqZlS1+FI/sRWZiTiNgoAbPOSg2Uh1PuWIzHDvtsNGNgDDj2AVr3fy9ksQmciZ63iqt6/sR3olY
WtQhT/rctWosWtYSaVei2hAJeb1Zw4xW+Ul5iUJqMyu0Vyo/+hs0bCgNibREuGMB9OLqz8o36hue
bt+MCawh8WW4VO2kT8qJJG2yEXatqK3U0hVuq7iTrCEcLC7jmOyt9VHJRqtMBVYETUuHamlswR+W
ggAwAewInMqRoGUkzLRSiqLNof3psqfahBpN+vppYhNjZiM73fWUuqJG4Mfjt6onWy27DoOhA5/p
7SlVMT5zhVeDqKkOm1ZNpvuLltpIay6Udr73baSwrhXx3mq+ZDvsjMGfOriZZS8tS9RnYsQJtjZq
6wC37zpICtjPEjSLbbtop986378A9pOa+3vkvNZ2HNN1WJKaKscUJWbF9m0NwHr135HWKL8zW4yk
RZ7l5ilFw2tFhoeAob4ZDnPC5/Ek9079BMsoaiEl2qOkwTUBRa3qApXI9JrReU+ReJVU6YnUKuzv
JYxOd35uDoifF59fAGKS+/iyVBzrmaWsoSiS71APivWlP9X0VM9YqxhT3DW1XqdTGYv0zhV5SsrC
CA0u8PJyVzWZ08Q8jC6WJYKJoxxeRwFbEBcoiF2fAvw53pLYNLc72RnXFyOuiHtW7XrhfDSJ81aH
AVE468SpGa4kAZlFp6wKkqopVjV/48mSFAXBUQaws3+g1k4IF6IEnLfzy+i3P03HqPk4zLVpMzdA
qAa+dcTPOic+93KrWKzj3DAYFjIYD66r0TgVm5eX01HUM5es0dXfnSsZcudv1OHSoU/sK5P7auzC
x+vwYnAtIU2GV1KdehHuuESGuVzoS9NWWw23y1NpaUusa6vzaVNwdlXcDRZs8DzsyCkJz6I1Qpp+
d59BomfqanwRVICrWmRssqkZGqh4FWaujDpkXP7kSZxM556W9fluZ3aaagOrvTVn1PaWvVDIIkCp
OeLEFqxkyXmK2XRwwCOGHqFXl6xzGL8vEmmvUWI5qgEMz6KMPmpgZa/Kp2lQqqJSWFyCU/m2E5yC
JoRgbOLyXPuHBFtj4vdppPAT1s0lgSq6r6GSHC/WfV3NU6+53z5KJf1MvoCY7AGFC7sE4SL8VApJ
IQ2BjyHdetlp96e9rPI9+50iM7Yb0sljquuveUSCLJ7NHKKqgWGZdeNC0nNly3Xavw1iGkd2JhLJ
RcQJCoeVj5CMvzmCH6pFAu7DJK3Y543j6bHr1pnv7j9MA72oLimS4yOtfdWYWJ9v5eMDQ+1toue0
8CLQkKg94CvE3TMaiLRp4fmWHaudBT2lOpVuhl2rLmXsfX4te/qoC+EWPOGYNqaLJTaXGzDw0qYh
zgt3wCLK/H2TKbQePhvQqZYZoNVtyg2FaplIyd6hlVaD15MJcqOIfONjoDeucm88oV4bxyhGOFph
ca7ZztDj7cEgySg9fkQidhHuLSEOKVsVKyruGEITAQhhGP9i2zMDN6jj+Ylsq8+Qf9Pq6TDzgDOi
tOIa4kwkrKa/2/QUZ902cPuyXYO52OU/Sr3/cqqlwIwSqyf1C2ZUdHzsV8EF0gLjfUURXb3gxBiZ
zy+uqb9iFldKttPGtWKmPGr5jofBoBdaBUKS3fIEl0lvvpeC+MgxiPY2iaEqBEyeYFyJJmtiB0sn
jYOGOrEyeQcc+UVfo/sAvaZtJalF8dHnYbpl7FuwhyIspX7gYAPLXDUxrZpbUFJSTATQXDzNj+gG
VSYqa6JT4U9UlVQI2g0/2uA682Y59fEd+8QRzWBTwDbJ+siUamovt8HpF0C7qIVnqFS31dH4V4tm
sSJ3HTNTebei58IvVJ5HojIDitsgDGEpUnARTKrfl+PkdBTmyrowTSRk5J1lAUgigc8CqVjEjUEX
JLTz6cVuzWGeD3aTxJ4TP5246Y6sa8+dEmIptmcEdY+MN37i8vxgYAMDrPysjt+Q5DOPjZHaUDJE
cRq7yRT4Rp9se2+u/gPk7UEe6yTHO28m1cjYuGI1F8+SwuU5qeXTQ2I3jzW1CIFrS/aWLhOhvkcv
LZqP8RA7tEId6F/ek2FwdL8e78pDmSCvWj5wVHy9DYUP9ypHZrMysEznhiV/nBrd0OEmYXDSaQ7T
qtnJVbSaI2TJOmURFEO+cHhBrluvl8uoZ9uztVY2ySmEUCJQ3hLTCIe6jKkeYtYpzp66m6852WWR
kKLeDFNC3cgqZSUlsjYxFaIBCyMe6o46vANLz522sixp67yiDOaPxY/p56jTmnfXHGyN9jvI8RPV
OR4x8NS6Lt/zF/MlYxM5vnZof6I6t7QKXUrECmOZ5ILmeKn1MDxjiNF49p+EuYVLpL0OC0FsNZmS
YGajNnW8Uz+VGfWh+xS2ST3qqMwBTA9P3uiOwOji6hY8ay+q9ojgiyyxgfpqgexQPSA9OTAsR7Ss
rF1MKWlwRXcgI7hI5VwNV007vq11yCOgNXyz0Zwrzr+oeZv4/I5Nm505s7ki2OOD6RyfQhKTzDqU
qiopwEiiEFMpPOxIS3Yloj2iX7j+GHg0LtPUl+LYpGXDlXHHpYdH1cWHtH9Z8TkAI92ei7k5LkTO
p2gi2YFRdC9pijO1trf3R+ywsAaNQVC8nZpsRnDK1eJuympmQO4OkYdbPtavvKV4JKwaqHrOPj45
AzWSvHMT8lZ4X0KHwrYO8/4Q8+Fe2FnDkULqLLa6Md+n16W51+1I6n8hM5m6sY84iuMw0nC4Muw0
ahDXbILIYyzZqcedXPhsU0LZSC4xzfqKV51MyzN+nes7fYerqbdopL2oGmCXGVRKsIloqBIl1unS
c/D8w/z6aBqVCz8JxN2xwIxYhdRATmMINynCWtzq+sMhUDexUHEvkc82n8RqhA3IGSrVhTSmSGVd
fym6lMIXPO1hljJQTi3fxWsa0XAY4Rst0c4a7xZnAmsWVCPdmmaz4DKv9mJB9UI60GAldeeSl9NG
Wk9KPpMRKTZCJ5thh0qVoJKlTzvhVDYbXRuuj7pNo9i22D1dbMYfEy3MPMzEdTCpCKtSbyhsDrSZ
tUwkz0prV/u44AKvsECpjizG+XTSqpNHeMn8YFLCGMwMhlo09ZWGQtKuaB479p0+4glXI1jUqIzP
Xhi2deVf0bAcX7QFauPIGdleL9YYLGSbrSuL8/xYgmM5whJB8ivxtaxTBDna1geDbyODRRfd2ALH
DYtGJzat1s4XKTK02gH3C/bKobYA0Vmc+VvMJ8n+obiR2h/7Yow31OpsyG6VoCFEyUFXOCIp8kha
Zk0KAuYJVODTWvqmpEZQ1q+pOCvKJkmZUaGN4yPD7deV1ODxkXYjfWyF0OYlF88Cw/AoIq8ZNxTs
ROHBlCYY6ad1lxrZ4M/QQZ+MF3TYIzw+AXVXz2RDLVhc44kzeA87yhRTeA68h0aPb+TnrMdKM3Oq
gaNVhwTJ4OPZDUibnBrokgNmPEpXUbcUMGPD1VoEOOFmId5/oi9kyaqok8HLcm0kn1ObV5jRrEay
CYtJX9/cLmRSW+BuXfdW02+3Oai5YP96G1OL6C3HUdKnjmPSKwH/ZKoNMfZdFPtQGqKjTZsMH8TR
xBsVzwhJoSApYGbeUS6pFRyxwToFu3HhTSRHVchsLFnccx+TdbnCRdA824c0OjNSy2yYdpYBu0+X
XFLOexJ95bqgeKkAUVJhQyGuqPS1q4lmeSWkKOP774g803VWm6gHXT8yLtvOWLSMr7ho+O7MHzut
0FdojYCw1C38/EXhdmpQ0zaNsE4+jNV04+08AkVHB6f890+Rd5jj0QmgSNvmV0V4avQInfGp9bky
7sYJE7vNQao5aS4UY7qu0kCmG+b670gkXgOABktgeXjOxseSq7QKd2TzEZ0HmEWtKkXhqaMNyNYY
LzhqluhsB+P9jNmQiwN+qoFgVfXp4DF0fZ93Qc7pd79HRrt3h/iIzNLZhW0CXfpaRdkOtvD2Ic3Y
yEpN82uEGvgQqVtgsi6046IcRphgXscvqT78fEiF9sH20iLZbUsS+TD0CH/FNT6Zk0ND2jZuTw3V
8SqTMzXoZEmVqR09NClhdteK8HTSgr2Gj+VBR9E/qui60MTbK6LDNOEM9zQYFV68nKcvM0+agxxb
lBgzJcm4FFqVrZnaT5jLGHW1PFKxrrgIRa5hi7oXnVjTphSYF2FhZKLFSsppMH8CLMysNLeSMo9v
peg7R+3VfK8vVzFjusL4bjTZ8Lo5Y0Z0/Qw8pnBz1183HS2XdG5KunSLbLCSVmgXU+wmZg8aq+il
ahlgvxMm//kBacPEqJoz6/zTq4fHFQoIHJBoFprHl8CfIva2GThsw7eOAsO58Qi9KG8/VxlngkHS
fV2HY2RGEt2KlFr8oSAqnFRnSOKG3D57ZaZbuKBeBq9H3LDHg8CHOKw0HOIIBa8miYW8mBNZYkhN
zXGNRsUDa3d+K2a+OJPZfXjE9Z0mrLwhmEmYaUart9kKGm1Pxt67aBl70qij2B5r+OBg3r0ocUKW
0yZvhBzn+dMSYS9uBoXuyrBkKzqyv0CYVb5BewPKImwO3FMuPnkY412jcyXDaER6QE/WvUbdbsys
yd/4fH7RjNtZPXM6/yBnVsWoittVkQoYADLcDYvU1k/sKs+rRjqUUVceaApJ6uANwtI3V3KZINAt
3ug3o2V3Xc5f43JkYmC+8Idfb+SRMlKDze90U6Yivw+s9wzFukC0ivUSO3QL8C/qo1abMvx2qhsJ
DmWSM0YGhyc6hB4SZ5rO9Tv3ubsyEVnjxpdosi2UOkY4sa1+1IOg0sxPv2bJPK+65sfq8Sw5xUAv
pW28q75FQQRFEXc4f+4xnQeSMgaMCOAHNuGCXA/LctCn5Zjd7Yzs0NjwscWWo3ZOYu3MZhnNUT+Y
I9nwD0tRUJKLzwQaiWT3I36BaB4P0qTyWsRvCP9/hpmDcZHRdWowphi1W4xDjplfF6reLcMJPoX6
VCHuDNOtHtjQ80vKwgzMTLrgIJQZLl6E1RW6yAY/cBc0Tq1NIOGn51qGMOnvxJhXxHOGNlv//WAN
Pb6y5sgJvV859yHtk6LwRThInBO4n8roMPbbQwrI4TWFGI+uFCCU5yAGH2G9Sx3CNLKuYEU71W55
QbMT16j68KOId5s43rl7huXbT5gfMrHWSTaOtAaVCUsMS/414saVAbbVbEMgdhMTJ7z9ywifRWxB
giyYK0eVz6LLFQ53JaPVtGwO2aDphv64lMiySf4sr4eEMOF159R6mdLjVymhQY8vQCB+G/BVxLGb
Fv+0lrkPpCEZlmFCoNozOIiQrZmFJyLZ5pE0lxmb1y4FNKxsSxtOkSTzSNJlVVVknZ5wTvqWW/hB
oeMa79UEqtCtJFQ6PuO8HIzL6uztaBxe1VOnwes35V6YU2RPJ9ZtJcnekkXAywrdtVNEGdS9vfHo
psHTgGMcEBnuZ5eFdYDMyl4/tCZWiF+GU0TOW/LMhdcIiawR+Gvr//AU3RjV7IZ6kAUKrL/zJgve
kvhYzgAWM/kkMDdzzImnqjFpYDEU4VFBo+OfNziIcjBPttLEfUZUa6h9l+u4mPAwqw1y8jXxdw0x
uyHFOy9SjZilt3RLHbo9ySctLfJanoKioGeaSz9b9yfLHAlWkKoMErwY2YmyAdl4pCXVmtgQu4UN
LNtwmDdvEF0+vpTcIjh72FgZP7NTRJRMyNBdNLgch9axJAeYNTpJ5ZnDJuFRUESX+BB41CBdZJc9
UvNqwjKU/ojygfdNTuthV0MNfI88I1pC1sxkgaW0GE2ivvLar0kIleih8cfebJPPzIeZkAx166An
cuMMRA0iY0GcVkzPGi5/dfoQM4178ZEPxcXU0qsx6MqKUpnh63u+XHv8AlSp7jUkM1/w7kvpI1ku
SC/Njhc1QTyU5s3bLft9b3GvCuLksiBA2mzS/iueNLbwGHhPmewyrjeximGrZEfzVC26fXhIpRa2
NrhDhQ3cjqFRjbBU8GzLh9JGtHtCJBJHqbfjAa3kmQQdgYct82d/4K97CYhaeTrRmIUDWpLT4h49
35vGVXOzcj1LjWbo28KLdEQKAa6Cihmp3u0Zk9T3NisNhOt/XEaeKxV/cHeTgdCXGr41NDDXnDGE
QI9Go5K82lxUOTHSMrJOSMhMtIlR1JiCDCcKm+LCQnVd4HKNHOc79dgLwJVddATMlfGIOrKJMMom
kS1QRjGyZJMt+3IvCbRHn3ZNMtJGHTljFdoLMYakIKv42cZTKrQlG8Gkqop4Ef4OBgbPg71Pjyu/
9tkpY/C+eiSlDUqmrdwVZ/4y4AukYIirxF4kPoDVonN1ylHRFlqeuWFXjiKlpIs+pm9z0rkWJ6ve
6flYHHNuaUl2F/3F70CHgih8kgbak2X4Eem4/MiUcavslBJZkl3xg3hgdpr+0ONFszI5APa9Mgie
anwTml496XzRe3lSFUl1TiEoFnR76RgS4b6CS2Fi9WE6JRbSwfiQadpB0BKstkv1NlphiIrLPELD
Tf4F8M25yfDm4VC1tEcBhEdwWOAN+tO3Wszv6+X9CmOAREuIqdCJsFbPMUrIeE69yXH4AoCOjUOk
5w8ZV4CJ3wjjjfFypv+eZ66ex3FFA8MLSWgdNAl0R2gMFFMg+CUXkofaTRMhwNo9cQ12w0LcpNHt
HKrYzdXZ520wlm4SM6XNpzNNYK0mKU8k6QqwJXHhruETeCimEzDDQX9KCkgLczEHndlzVbBkZImM
tz1HjXVo3cqZqg5wR3RbT468pKOq1ymJS62qQVHmPmaPDCSNBSM5YLToJt9+wIJAG5WV8hUP1wno
XZFENGcrhtUx1Y33BDQNhmvaZKS8fhYVwfRj056qbEtd1YoEcof4TPx0UMKqifROwFj9bg/6VC6u
ZKo0jrDJv005cYFwP3RIAPCuwTIZ/vuSA+QckBmR2qbfhVI/ekoHHetWVDG5hw6IZf/lr/dO3Baa
EDSUv7f3CqUCDcroDkwdGG4nw/6mueL0HoMKwNQny3PR7FJC4ww7pU5j9tS1dLxipXIdTxE0LQKx
QGBslt/7YJ9JlU7uhvc+tYjF1XIhVyi+zJB+YpCi2QQNZ49UNa2TJeFUGqfLozCaaRXj9hAqzaVC
iqAmjI2dIhJ51vwJoOF4xMl53RjCcPKXTQMoAonNOd0sUyAFGMUHuVU+JjgXvLmhjYsYBRonplsG
/Q0r9KKJMF78vX3ZjQ6Ho+jVs42RyJW2FpjUlB4tna1Zbl1NrWFOTVy2y+DjdfQTdt0lN8MKW6m7
bDS5JYEzYkrDKboE3LSrEaY1kVz0IlMLu4F5Ql2HmzZlxCYqPKOiXYeEOqmvwsgebc3MjENmSVck
Or6yYrqWVZ+JmXVnfF8pTq3iG3+kfVKW2Bo3eHtMekxjf3dsDi2pTH1Ckt96M/US/izd24mFV1k0
nykvst0Qk6uG9Ia72TqWlmvzL9cO2S8A3igtlLgqd6WZ/0SjaE5IsNGJxK/JtlQ92QFI2EGaCgOD
BS9eUDk+ujE+J7OpG0K03JKcxFQjmlVBH1WstglctFZZFIsqlAVdJJfNSDxSfmZJWJlKDquCBKQu
MfdTmTqVVUxmDntUU0CWFJ8MtVMKWAyJaL9LgDMAAkE/iBBlkdDIm3NT7TY1yaDuUFolMP63e9Zg
/NUa7BfApWEH1ichsVzF8g7Y8VD8Wv7rW0C85e+sGFL01ibZoS6xpf5jQ2yKjH19hXQBxtUT+Zt3
KKmxOPejQd7ME5wgvoX173JpdRAw2Gsv3x9C0G0KMBJsloO4C5DSpuhEi7CpiCCBWyob42YTuNt4
RlmQwzwFXASZZVHNaeapvDYiONJheLkKw6oWJTbn8auux2RFpGuqahpjE0raNKIU6WX/3g4r51V7
KFDTkEcx5HjOxYHDwJs3GEdXh9FS1cMaZoBl+xH1VkX2I43RpNNyOSSR4jtt4ceWxtsLuGyVn4Xu
pIsKjHpf8HA0FG4qQyw18PQA4ILb5+WKY0XUEtCww8av+4ZQW/TTiKd4/a5H+XdunRRLpboT29+V
SM1SFgwxkomshmSeHsHg5DQvu9DYRMmkgOjkBoyGqHD63wkm35zSMjC/AJLZwtKNWsQzKl2yXLnl
hNjt2arX/D1SIPWY40LZaHHi5I50WE+TOGieDUVzWWkWwLVx6QR+KtZTIh8JJ9RDIptsJi4tYLkk
r47delTF07G+P7oMqEnJCqLS0SXYpdmIuZCxfcEemVCQNBe6MDs29G0sLxfbs8DbrgiE0mzwTSOv
CxGt6Rs9QXyss9Zou2nlrUcVy641PGOjQeA5HV3UhhgZ7ONZ3lydTrB5o20rWEIqTLmRmDchS45M
ptb7jorDyURCgjMmXFdCm7+ERLZEHR/EBQgoJm+0EuaRqsuRl/zQztrjcXkqQkqUblm5fO4kUWfC
5XWk33DDmdg7KLg21Stng9ruaE1x78GMMkUn3CCNuqgOzhGjhYkU1NrmyKSbE6VLnwag6zAfLdw0
hXjLR5E59m3pHqitYMw3BK/rpJPKRVclHDWV24LgQVK/VjfbZddG3ME2sSNSEJTRMgNS3NQ8IPBP
4oehSJ640u9qeqzkcA43P55IZXYI55iSbFc2Y2g5k6pssFot68ewEkU1bdDVO8mCXJJ0oTb1S2jG
4qN+SCTp1v2yPJNi9BDH1DX+ixO71B2Ntpy1eboCscl699sKS438x1MUlh4zjjbRKdJPB1nVdxzy
YbWk8n3TNE1bdmUd0FoAjTraLbFwjwiV5DdaMqNv/o6CyBYS7WhuZBoxuf7uf3efI2XifRPpEom1
g9hq2qRnDMqNuGxkY5y8h/c3trulfrq3Ax1Ti28qPdAWfr7IZcs1yw0p2ztdKiWGYs1TjbMTlYUh
Gk/SGxHV4UFWFiDj1FAgKeOPy2QYrQl6RhwqmkhQXWyApUgUKKDHIT7QZlpyu/Brj++FV5hRpKdb
eP7jI6nWI+uIyQL38ykpQCtrwcnp+32RcW7TbOPr75s1tVvT0J8jQknezsCVYKRvMjQVXsJJm0gZ
oGZHdWWaZYcpPUo94ckoG5TmTYK84gvHGyTjpfHkMkzVoHKxEzhhSQvxMVPzyuDfRizdNNkIfYWG
cqlv0Ud3iJy1UHRylSLhQWDUSJWL4OlZWIljcSBu6cfjLrdF6gWFmrD6CDGwcf/OVGNA2kQAkcKm
AzrcAIy/K6qKECOS42a0TKZqHNMWDEqxoosXS0yf8lNAWCs47th2GyCCt/A+D5z6DupdP7IDC8H5
L1vUBOJ1MRoLJ+uytY0lS/rMArfah7kVwq8RuvUZydGCR/A2CVNDaxHhQM+9NlKFH4460tQbONST
GcplprZkJ2oP0enzJ1x238VfzBlN3DUm3tI86BrVi8y6wtXjGgjGgjbmkeiu03bAOo+ZEkbtjqby
F7UwIjD+8BrFhEa0rJdvj2pWQGQoSNTzNCNJK8H7P7nKfwGG294/dien3H8VRNBuXCpBfWpfrJ4/
f+SPDD9T1DKYOKU6gCFbcDD5Eq9uIOemyufi1DOJTPXhA0+J8H0J7SdnY/nQyyTQjRYPtBQclFxq
9j9bxmicP6vK43yNwBZLh3z1vgC3oIFj6kBXJOHQYVJA6L7ii33vaJQ1sGSzESN8yc8C4l3k5Zxw
Fq6U/U/qvA3xovH3GtDl3e7lbsk79f/vFJIzQ4Uh0XmvroDG4+KnR0SORugX7i/K29Vx0dsbjjs8
RnWbZ3xr+zCxtdV75xQG3TkmEhZPGVk0hQomy6RcEEFmsJZzfcTowjDr0/MFoMfAUhJC3WwiIu8V
doa+QfwC1PZxcpMWY0jJspDKme+c2+CnnmKnTX2sIKb68VTT5pO58vlbiY2/TVapHd6dLe2DvQN3
p4C7MZskxhXmSKKYGuJmw3eiJc9ggetHBN0ANySS+iSgMSYJHSSEKwOTP+TOF8C8zNln16/N/ZE5
VoxeFT+tQKw9ETK2LUvA3R/iAnq9F2oTcatVoL6JDlRV8mnwUc2ULjr5ECP8BXAfRj7iZTY9xsn8
K+GI+u9ZEYx+dwds8/wUXyCQSRI6AuDMi/IS/vjp5RB1GvIG81j4VoTC+AV45/MVsNdP/f6YPTh0
l0tn8zNt6W78QN73VL37rfX5oj703S908xKkgy+SBeFsfwBOYvspEDoZZHwBgMsZwx0bdwV7g+zx
Q74lwCIz8j8nAfDECqGA3T47RICS3/JkcE5ocbBHZmmQ2d+081RK8CNEsH0ByjCfAF7nWOkPIucw
oMhhgw/0JeCz65PXOaKaRqveiHoLsmG3k+OBhIe099SWrGaPuXObXwkQ6AC2BYBO4qvueACsuW3m
eQ3+OZLsRwqgoaxHIBAkARD35gqd3f2bLQG2gROqSdAxdR8AUhQBF+AtKugdaM908s7p2qSCsI4J
p4jxkVsE2Po9/eBTB8bQvGrX7XnRq9ucX46yHnnz7pfK7DAqPmVddCA4ubBJrLJ3BIncBPwCfLTd
bUJfIad8Gh7e3N2+vDhGi8Xw66Z97H0aX735ajueIxhumozxFNfZEBi/5d+8CcTi/+/SoY3/C8As
E5eXbkdigdfD8edxLvvu9dXjO0ESx1KQTdQXgOpEE7MivXHIBCqWZIR5CkkX+ki6oKhtooho9XFK
KQz9MYi3zSzCAG8I3z/cRwTmXNmbnSPuomUbuhbbPxj9sU+IMA0Qqx+bmvPhjsBZgg/g9fqQrTTv
vpBiqLL3oxi04aPr2x0Y94Ex1kiArt9KKNjr9jDNG9+WP2eB4EKMPk/cOBlEwFIQhfmGSvUABkCl
+gggMO6djQHvDu9kWhfc9DPf+ATr/fjk93aYxGeUtpstFTrF59/u3rlq4n3+O6+Ouw1Tavpkh9fS
UsTpMH+VrJRnt8jVGCu+F6VsO2GUOTsm6EuIxPiYK0x8ReUldEXlDV0q3+Q7y8/DFCWggiZv+FEI
5kt6REK4qh+K7aachAQlIZV7hjilp+q2exrzB+pN0G0/AFLA3Wj+9roZz5t01q2UxTuvlvEOo49s
9xRqQICQ6FPb/gqEJo09ei65Tnm5JqMUO1vy4fsFaJyNMlLGtZuD7NoRjrPvlXdjUHx22QXNucsk
jF4AkSYzP472Jr8AjEj9xzebtj2vDbJK5zhFlqXI7M2M4Zy+XNO3e7ajdkaxJAaUDGnhPnlvQ9w+
mV6fEKM5W5tkRA5r3JcUiIGgtnvA2xeA0A0GS2Mf72/SVs4dBnTqbmsTbugfgVjd64AAiiPEodw2
fPHru117v5vNGCElvn3vKm/K/X95i8VnQw7GcW0CBboFbG2UCmlnb00U2j63d/dw3jMSo+iV8fj2
VelNFKm3Czd19vgGcLtXUTGsADhJkjLEjwBAtIc+SeG6Egr8HJ0NlqQrAdW3iu/1yvt+Xr/x7Whf
D3FGaMtE4FxCf85PdrNLHjjc3+2/LWUnYdH/AZt9cENBsr+85J/zeLEfGMLQ6AtLFk7jG1AGhG7O
AXc/e3TYuUY35Wst+L6zbysTfva9fS7EDpZdNyVIcUgSUZoZMqRh9JHoXwGQ5XvtAnt2PnECarOK
GtFz+Zm9L3AZsvV0Dicz+Uj6f9kJGWiSyfGFzOC0O6wrXuZWrinxxON/AUw4zuouVkPfvLzHjbfF
aNmIkkSWFxwp5sgIqlZkB+2XESL554Z9D0M/hSUOOWN2fznuI8s5OkAGCfqDHZEQ1yFPiQpCTO5+
8tLCk/4mmEKnSs207eOgf3sXKfkCMAh0hhDv5pNgh4aLNY5UC71l3e5ZvXELg4NHIqxp+aVNqYdH
nPOhAS+AaUWrU2X9iyVVd4mYUpupAlV6BN8mm0gKpb4AXwAFVnRKocMNGMcmn1SGRntr5sVU6aat
4J9VtDiB450ySQvLLQ5RhSSVjs3K/MBn66hKC8EWFsboS0jRCAqj2999onKKd8FYF8OmgM7PWsct
373bvb6NEcRFiZILOeKWwzXR/juUuzc3xMCXxM3kKDpqwQmN5durW2NNkwOUPgBXKuhuLD1VYRnL
qsCUY72m1S2NQiNeSVX9STwq7/Aw13P4CxDdqZFI02tn3rD7GrO3gfyYzWnVZ+X0EiNO1VKN09Gw
npFNKdxVygFYECKrbFCqKi3ipewoI4a7oF575ohCD/oOzTmKd+L/SIEWFWjBBcCggsn8gy++e3n2
7v1sTXVjmnSkqkDi37LvivANgNj1hB9o1wkTK5/moL/f6r9GkqQUKsPzcpWu6BYSlTVhgpC5OLVW
FLnUnMMgr6bLhYbUsV9qPDG37noRvhoePFxdAoUlV46FkI1j3B+1DlSeUfU2Er1NRqNyPhdOE5ab
8hxzS3MZL61m7x5lcvjJ+h5c3MTX1ZIujV6+AnzyJXqAZnQCZBkr8s6eUBwyH16XfQHmtVH8yf6A
K7og8aAqMrVA2CiDhdrH9JEu2vulds4Gy3iZwz+aKCApPiV59IbZEc6Gf9K6x2+UxY20P7h9fAE4
1qPleXNEL0gprWkgGIy4TjXU7WzPv8NjUTZKiknPjsgaw0Wem8q39I9D/axsZ6ZVgbV6iFZCYxKn
N9BM8xA6EXXPuuro6n/0qEKnlGmwcvvhK9c0L7qYfSSXlkzSblwvukh9ZT0ZZaT4fSmf3IpFjSL5
MHvBFknBrIiHyIE+GPzum3ATMAIQngiQAUMMEs8DvNiQXqI+heKqHPgSt27ePl+1vnwB+Fn/3B/e
8gq23UDUIcww/7j2WVzZ/t8VYFsTGfuL77i/fo22DfZXTbMWywwlqk/2UJbQdM+yDGoRkR03fAvo
lu4e4yKSEB2ebPoZ3vmiOcwrWHw5uOGP4BzKZhyuacK7oZP2GE4oP7HKy2fqhnWHxPaeLSG+bGay
0Cv27VuSaX8SzxOb5LH0AA/2/VJ2iqykZL25BXHhQLVivMyursj3t8HWO8LD1uvTqWxPKE09ZcCl
3hY7Cv50a5ugZyyUvNxIZ9XQN/ifYoBvaE5TbXczxi3/7TjGczT42Cu2lYzL26h7oOMaS6b5QMRZ
1m4Hx4y/woBZnEfO+nxad1hJTY0My0bPrEcyyH27ZF4+M4Ya0ezvUq6MkdE7ydruA/tXK1uqSXFb
WtD4BSYqW7xCT+pW8sejU98tuRemGrumsjive8ldzYGJ0TxnmjfRKOorPRVxVkT4b8n1ZBHKXitX
4KPIny3x/MC3zIenm1aloTK8Q+nObGZXhYhIfxTkL4AdOE/uF8DA+/19+fdiqkVYX2cVp4/5EFYr
WR09LHEpjZwr2Zr2Nz8PXwi30vTWpZYSmw5VaajTmSOWscmfHkrptCVsO1IrRRYKjHdA1/jfJQbc
QRh7JVRSvxYr7yimEFDCagbY45Kqkq60CcRSbTUzdquNX1UeWdwnekVGNVOkmhga9YhGKwWllW5M
w7ZRjbbNqjWEGlMyNu+HyRvb/67lfkhKXtHT+Nsio64dfENXyK0gdSYz/KfYbwi7XWhZnj7Uignd
9DCiZ0RnEPbEYgqL1a8Y8MsaCwS+By62Kq4jnIhvIl844/F7XUvvyusWMspAQpmbUmWQvxS9nQ/Q
n4o/rHj5+yG5aR3yUbt0VNN/+G+p1h/KEzR1Wuqj/iOgdTJ2hIgYuWmhF1c5WORvowUUEwzlNWWg
bqlAg8HR5u9ESaX7SMzfOpTEksPMLzxMOvVD9Hxj7RtGsjE/h+sYRfxyxgap3BulJLO391AqRIdR
h5jkxCXZrfzhRmUCMLQboQTHGTan9W0fK6sWJY7m6Urt0BtaTlKup/yux4AJWJqUyNiNtr1LtEZx
OddIOAoc8N+0+pGtqid4ghrVDxVTw1NjVNskRyRZ/2Z1mLl2qpsTrhsBDAkd3WXxyYG6X4CNAKV0
CViAafqMzfrz2rOfvNntKo/kjwJzHKlD+MwtAUwe3eEJjaIsBQO6IcszPERbny5YDtjBGQaY9ROB
B4z9rE5u/Y3f7nQOuYWV/EdT9oLjyavPj/TV8X8aMXNgVnhYI9XrVREQgNQH8HRt4kKyOFhIfJKc
A+pztqDH8MAxZkiaisgmMKm/PMOY2k3rTBxdHEi27+9dX4D8p4f9bRehE9Riy0L0qbkGMqBkVzYc
fyFN0sSEQ9IJTbHGegpF0QBR8mTgG7Oa1ZZzOfeGfK35T8++yP1QizEggIBkPyeyu+bmexHUsmJ/
vKKgTDZfMllOPSaJPKP0mjWtKDGyRRXf0mn0i7M04t+/xoy0odYeBzWOGwopUqqBxH2Mri5RUqdH
5UppD3bjjL9o2GloZfLu7gMtlnayjQrv+9LQN/4wcpf/UCrIj+celtClirUwlEB7olgXBDIggHxz
SMRJBG5CoZKguugUsDFtBarDrh8iYLmHAzoxTXNCfDvHPLwgdrEe9pLFOnNVJuPn9ddD2+IJNBrf
mBeI+Dix40VwqAk6yvTtiKky9a5/Obv3V9ggkn4BFjG3zGSzLMy6xSc4Uidr5bC7RNpKqPTFyyXQ
XDBBiBTeysA7o5GtMGIMRdayud7qkqr8sAeWmHBZ42zDW0wpErhfODRt2R9bQ4E4LJnfndHI+rtc
kiZcNTHfuVGUAsIh2tUHkcd+d0I4VS718M6saZNuXB+pNc1q5hqfpztQk8MbtkovFtf2FvC5tyqq
tHMbbM0eDTXb42fK8bMPklG1PlQX+XEbMZtVsOmH3R2mUmznWbdrddpOeSghE2+vdbWwwLGShuhx
gY6qVfeTzHENc1OviLdMbSZ/MRvvDCa49zDwbE0ihJ+Q9XFp8xfGMasxTXBE6a1q2LsCkultp8AI
i4U91KOiTBW4YXTAuQ5D+LW+NZZOvY2fzvaLTnkJtUd2CuHj42CHZE5piGVVfyPbx/asKqDRF4RY
UCuAi/9uBaAUlvbhyLHW+Xus/fp4xMJ105yphEB703hhXJEeS6I/s4G/nW9h+fKjBVBVcbV3dDiR
UCkTYHTiYbKgKB0nGReCkkTsGs8RWgWz3dQYVZHhWTe2UtW0WZQpqf5Dl5YVMYsomMKiOJ5YDe4v
43V4vZ2E783+xzMPo3pmeTzbCdQiUGjGNzYr1bJ0HLMHwp5Pfhl+Na0kk2CXTIg/4yA2zhwak4cV
69mF6B+ZL9Es0RSKTx7ccx3UbOfl9EcwOpzx+L5ZL+GpRT5A4Nr1yhm0ZUbS6KlJzYJRKnRpH6JG
J0k6CQ3/km5WGhlBumDfHYITYae0UOBRoL9ZRYekjw8pvEFFHBBOo5oOM8AQafPk/GlUhfIYn09M
PpQgiT5Y5p2hyl5Cx1DuHR1A2w4XqxlbLj/vdGZFZUKjO4OwUIcOlT85zlMyzmaN8MmoyMJxd6ks
xVvLAeOEb5SEQh2FNo2u01IR3MukbcJUTSD6UrOo2CQ9pLycOMy2xnoSIVmIrxcUWp49pN0hOrE4
k9CsRr4+XddckRE+1Z3CJAMGfCkoz88Sr7rwNco0Y+1HeaSi0y9dapqXSDWXLFNWUlThWdH3QWlO
IZ42bC4HTi5vTfHF27I5x9vNeGis5v2yi8p2lJL25AZ1kznLNVy4zGnphdQJQ1dq0JvWyI6cyQZL
CI8xoxt164k+7K/5pmd2ZCmPFNQKl1GeDFwn+/2GHBaXEME8fcAbwypjUICMTI/QYvK7KKWb6uRp
tX8IYL2rDmmrMFZhUudVh+CKZLPUddQZx/CkLVkKqqwfX/cxNMYUlVRzRtDoY7UixTbismIOr20A
N1Be3xddjGmt9+WxLR17j5cZi6e7vyh70/Orqh86XclBWxr4fE17lIu3IG8YGQInYFoRgKGCnu97
wNSclCZZOwKvUHA60cLFXbsOcdby/1H9rM7CByenZ/1DoQL99bdfpL6SuTHTluIeRQ3TTdhycYML
r1RK2URUYitgWo2UGtoIyjXfV/pYFsEgWuG0VuVhm0mv/pK1cr8rVCpCykgSOGnosZ7JJ5EvEOVI
ywlNjy9hevQIc5KcqbxRdVJV0WCkqVnhuArEAqKDfwGQ8DfId16gaAqjrOEwDNA0ilxTQ2SZ+1Co
DRseLh07O0dUd/4E6lpx1VrSM6Au2HLRZCenLNFrj7ObGmv/ahu+wx4lUbJmhDEGjXE3/thq1AhN
3lTNz/b0IxTwp50kNYd07VyaKXxIabdmSoPH3jtFtXbhXPvJrl+vp/k7bYDpidyJXr5x0mRpsXfV
FGSKPUB/OUjoOLr8HX11yagK09Uwc4xmGUJMXeZRfz74u2yLD92r6p6ewYOZEz3Z0GI6NI7JVEIm
R6uWDTw5Lw0OqlSlasQM+PPyX8QePTV6VbPqRRSDXjNBFNRR8Wt3e7oGbfQNi7R2Teb9aGENVYcP
6cWuB9tm1RvZnlWtNuNx9mjxH4PLp8GhYeE41SMTK7L7bNTp9TLKjWIVeXsVD1jUoVgkaigNuoYd
w0QJFLp0jSTYCmAhA2d/KZY8ud2cH37ku0SXc52aUAjVGJ7RDfNboTQ6Op1j+nuLoxxRWijfNueo
9RU2om9SYdZHkRPYFeM/N2lYIv8Kb8KNt3Bt18LY8Ylf5LN6U2rRIyExuN3Ee9FqkeuZTMYODzsq
kfVH8O4i88Gi15ulP5qpJJZig6aUN6g8V/dvENtEM8U73RhWyzOiM+rf9LA2zZlw5/TS3Z5ipoXC
H53/GUnN5NA7TbLXUa9waLkng6aLvn2OWqwSwK6xOi8XJUczyvzE0RLaIjMaEj/uMhWp6qWjjqL+
c4XX1mpcBUHMOCZZFyGoyH/J6rbGnH45Y7GtSG8LMFkB8b2dAdgmRhUVxkj8iylbTFoR0nDAUpjZ
mPoK63AExq4j1uQ7hjfR5eTE2t3DqoT7JNRehegn3MAjbYjq3J3mOF5gMDmN5IaFVqkzbyAF89NS
AYUJOi2M1BSfnN5On1R4KZ50p2aEETzYUPHyZwCra5RLZg7LEVlVuWlU4fw9SGgoleot8IVTOzmQ
bLCQ3GVysXZ9in5kz1p2YLzEHzjeD15BIQ8OQaWAI5o1P+IWgXX5QzGpcXVrL11WiLt+qZOLW8eO
3mhBSewiRW1p/pfDtZLNagVB1yns5hLCjmLH/ESJuEQ2WtIP050SrHsfo82tx/z65Vhok/eOTQK+
4efDRolNHCwbH6FK2WW0GXprpmvx1PSAivFfG6S0iwnKtURLcYamaTaSTxKsfEZ6xiTnaamZHegY
VWDI68RU35XgEmBlGYsFWRjJS4ZQRKRGT+gq9K4hiLkcgR5zG8ZL7MF1wwyy7RAUxuemOfl0ay0Q
P7iTlXatatqyA+s2em9wMY9K0E2r6sq0/F74V8PpOJRD5bWtq0T8S0pLEcT4Qhyi92SO5X/eUZqf
2CjyRBvPp8VkBFUQ4wYvkp07myclDDfXw96qRjXI/ZyoK7prjvyJ80twVOLbDrf37AslvBWNXG55
RY3u0KtJ8dylJn8+WHIjzTKrYfFWxUyHBTt7RbBvLq9n51CyJeEPdWazIKeE6DMTz3IEwWp5FB5T
QeVjgOCMDImYbh5+eSdi1JSg9DYespsdMYWcIuG38HW5sGuej0eQa08JmXTF3iKaEhg6gDlLShQL
wQQRfxQRTgMZVTggUEHgonWZ3W4hJxWC6CxUGtPbOsKa8VVzoUZ4ou1oXs/W6gsg8cv5mT0W08DZ
ZRIYvMBqWgHBqvMzoa68HJN8T/FkOc4qiZFq7kCu8Qswl9GuVgL6KaTnih4Qvyj7OSoaHdYWnfCA
bNVezfRzy1a1zFMLcz0dmCLF83NLC6uBw1KzhOPVoFlzcW0LTK7ZtZxjikB4/Kgrmw2eBWsAyozb
bOzVlpZPCQN6sLyVjZDbt7mWIP8LUKpAj1zNeHSbEiGAm67rYEVjReJbajRmrWvZApPiUDbPgKLQ
0oH5Iwn4CXWMqXSEqpccdbD/BbhlZnXXehn/AlRmuR+4hIqiJaKEBcfh+afHLPiD9atk0wsO/Agn
6+8YGku5s6vp/rTPrnrSePXom1fdektwiRfUJ9+j+RbTC75Jr8gGUyMi1zWg6oJT/DPe0n7C4yj+
jNuQYp2yNN5uWx2trEhM9BJG+Tenn0w7IZ1xocnziye+WkKLYrXhaVXwylgTT+eOSsOUsrVpJcjz
lCI5oVFKdXtTOb6F5oNUjRjNKWIBWDKkyYJL3E2a7liNtB6Vf9MDWaLILDuKv+GMgcU37NhUouna
Qu+1X8c2eW6ifVxHo1yS+khhZC2Tb9L+kSzdK0fEk1N2+3FMsuLkErWJXa6FsO+UNtCpGxhTBeKV
QrXXkhpara8RCFO4TnoGVtYHk67M1RfHJPJ86wfxUBU90/l36XFz8RExlkuFoIGRKxMnsgEAHqmW
cjJyqDBSe3M8jniPjTeF69mz8372UZmzaz30l+jrgTJrE1fxDSrOG3jnQLLG+tF6RXS3ZzqORHkq
8ceTUxveYCWhKJsPqbabwZdRKGYi82/oqzYzmXcHYq/62FxD6d+0D/CMGu+a2V1PviOD/szpaLUn
J5qjfIBE+nqcXzrU3OCx+ExHG0gLqc9vDJ/spRM4Ih4NUt7T18/SO5XaxnXYMmouGiCnMwLhlTta
TVaZNxl38Ot6TJWqTXQK0Qkhhz24PJQaAngtEzlLqLGL3SpPxPpnrSSMjpb4hFct2/ZKuCnoWwYO
jacO6Vqif/yd6MyzyjAzG8lia8QcryGR+lAiho2YYeRoVCqXiZX7ISPwmRuGN6pCbiiSZmbqxITB
hL5MHgDBs09WD6lQbbz148iNXdj5SA7GKhTF/IKcAb80Kj8lnUAm7mG8Uw2x4gB3OLhGwIt9X842
GrgJv51/04lLA8H/97NG5ciWnFoiv0sUULLmUW/1nbWagZj7jOlQEhcym/bWh43/C0C6aXJMVv8F
OMl9gLLTtHy8PHfRXZb+kPNUvyGUSHM3O6Z/Ei/blTTLaLzz8dEg+8slBTJYevPWS4GMHlfZct8X
AASr7OH6AAfWuJRmSaEeLcuAVeCxKrKSB93tfWZCR8g56W6C5hVZ/vGL7O9B1BF29vGC0LWfuz+7
WgkYuYVfftDISKgHF9WRg1s6JaVA4ktLKSUFZuRRuyIKMMCd3FtuKLuWdQ2+MPBDvxdvQSBgqZjN
DefQx5abpF/pLq4whpwL/mbZ8cmxu4V7pjzGfbK3D91z9cvaNBZlyvSKI9UyjSWr59Eky8+D2iWM
pKiZZmhM2wv+S+rj8CDlOXY7SkytL+egOcXkXSWWfoaWfQo0xJ+owP5TL8QE4aNI5e8fss2O8pf0
enP3CkTUpoK2JZNq+DLTR0G/s7p81rPts+1reAlivc++2gpT7Et8uLppxFI6UVCBVIL0RxM3gsFm
Z7x4I+0ZICL4c/Z0MfLbEMme8cP30/cisHb97hZkxldRuF5FHdeLMdTpS8Tj+gXozYV5On7dD/cZ
nDIKlRdwD90esVpKXloKvF+NdXOsZ/9voYqXBmMEsa+PuDUNae+4NzcV9BiKXySG1ECV9W/EDwoj
ACrv9iAg8nFvZymBCgoEnGQsJ+DhgMAAudWeofXm6SawiUBvsebN/u7ZlxdqqOEFHBwJC3IIIe4F
owBqt7QP0s/fm38GHVNBgYMxZJfAn3DW9hMX+Rb0403MH+OUAvWQyhUV9QsQxA0TOwRRmwu7qHHI
fnQeoZe/ntYH9QVIEvfrtffd8f6/Q9BICxe8Ww907Q2oEQUYQ6ZeHbzCdo4vgAOulz6/PmhEz9mO
CFrEpSOOR/jSnoG+M+YLQPQSs+kYJqPw988w4RcA5c518xP/C0AYit2+uNm0ufFsu+oXs+Pnlnv3
J8aV93NwYPF/tccjQeDrrgTBH4bm1r1e0BUoH4XIKUlQDvfNgIi43rcOJlTe/LGHkAjUQNVgvAkG
Q7z6d9DO/gW4u70Y47/PLxz2BWh6gMDwbY27WJ3dvnlyBMqPOL05d36UDLYYct4RpeqG2vbor475
7nTRH2ufOaHnzqba2+8d9rx9bJERBfiTEUMeS/gExkH2CRgG+rx3b368e35D4J/DK/Dp8u+j2Hzr
vLrdBD1f8/yA7Re+83heN/ujKlpAlM+OCvF9A3moM/QP8SjnyO8IIlwYpD88NkQ8Dy+OM8jh3DF+
fjUhCxBQjeMEc4fo2EXgyfhRhmuAwt74IE/AxSXq7sXeJMaf7G0059SW9brfXP6KhwwiyJfn+izI
nTu8HNqxpEuCgghxHy6jYx98oE8DXv4i47FWw/Vb9lfUD8Vc6F77zy6B2eN+pkq3UN7E9nzLUaXl
UhTflYfFxivvsUeBHUqG9emeHb/HPWtBllSYOBUxkosj56Tfz/8CtuVulkLtTLqRT3bY5vJKREWV
+17C6M37BchfyR7KZBQTNZHv1a8KF/8CPP0zLbCtAjA37BVoRSwAS+Xuz+PB4dd8QdCYqoSR740M
uP4QpEhtXKh87iQcOeMbwADtXVBQ0PvjU/sLkHZ12Ir6d51sbLMRorjnC6DdcHa8+tjVYd8Kk76l
X/kwJ/IFsEjr0X7nrJmz8Di4NdWBO7gb+3O7xsoYyonJxJHSXxe715ryBWBgGAyqhBWZKofeUSDs
PP4k8OG0Z6rPFnaimQshpDfQOPzEC7x+vi5fWuhe9Uk5ujuCBuv9Alz/p23AxuCzR+px35lpi5Xv
6iLwkstXtaL8C7CNwfuxc9U769vN/hYYRFNWEEotAZvMAnVA8Qfc4ClcxGcK7AY5FGe/F5P9SMbz
6iPv/Quw93QxGsiLXhQXYCBCFjPMiO2G/Idw1t92JGvybtocvNX9bown2wHTEAyF/0/qMsop1LNT
mAvK5t7dLmiE3rj0wYv47haFcB+id7AUe7J9CQWMSQrXi4iP+wuQ8m54wa8/+pmljOP27DzGk9WJ
XrvodpxRLjMK6RHUB7nmE0v8/m95+rzb9sWJkJUxuGPT/fl27bFfPnoZzG1f3E6OD69fXjxuVt05
LlOvkW//1A2o4SVwIrkdJxdW593svRxVLHKGsn+EOVd3aKf1ihKi2/GPeQ9BgJbc/86oigpuUsDe
I8n2QV8hCxA/2x6P8G9+gt8EyxfdfQEEbj9xbRfDhOsUeDN8sY7VAkdDjzMekRAbSi/gp3jO8frb
Pn73gHrHBAj4fhhQWkEzYoiPQQoWCDDulr1D2z6Lbfr16bGcQ2t4EUECkb8AlKNPLZuTr5uR+UI/
EvlwZbmSWu8qhUCDd9POEPEYLRAkpNcQST6bb6F+vbPbd6BIfIfdelUUgLbj2uFfQtSzw6uz65fr
dDHgZlIw/dsL9PrzzdzLz8cvgL/jWv4774PTJb/PQV/1Du8t0rH2jPwOw3v/p7c78zBN1xGTlG5P
fRCg05sDP/Dq2fUWpD8jAPgUOB4hx+IOC3nv9vxQeLnxJgWp+2/POq64NlyrIB5QENa5fYqMsJRv
PG4+7E5+5uwR+u4N2C1J8ACgR32GoHcHVNQ45Ov8cnZXOw9HDQlxuqAuvWIae+b+ch3cUrSpMQ0m
i45BnwOPxY2/Z9r/nFx0fArN3eG57qqBDL6APc/8E9vEf31L/29v9U6W3VSKT/HPf+r85Ap0BPf/
fv709qmjGjvkYS/PTz8myJWjfTeWEQesi+XEV6TYdAJgi9vXcX/sAt+pbr59AXZzbxhwlrEImf2/
12z/kweNr5+cauqNr8VIme89AoAXh5nlTrII0zQ7TPta94u2H+K/j+qgNwyRr0GlsV5rcBFpgO1Y
qmRiMPa9RcPDXcMXG4jFaE5slded693SDYgPF5DFTT2KScDB62nI0VvLydV+JI0OMUpZm6WKZJvF
t/D/pfIiSVVI4NEp/x+Cbn59gm6Rzy0q6lVG8ODzKUcCf0UwVEJ/gB0Jz3tXLxJKdn/gJrGU0O4W
ofn6zacOFfXoXw+fnJyrNMBH72jt+mJEMiUZ2I6bp4/tJlP5ceJYRkGVKvsRk0ju6ZvQhSvYo+eb
0PUa51VXeV2uyUvkUn+bHcQdYitSLmGjz/MK2Z/BdS9ypDHx1NI+jre2CbiYP7jQC6HNH376sXpc
sCHx6TtexdQ3uQcpOiTOd07YMOSvmzGbfu7ihsixCshuu6HNSHqLDru274N+b95d3VvE35LWUY/u
/vo9Dx5/Aex475CNn+w/cX0yHU1EpIj/pAugzzJIw/8PmHoJw+CPBQbITSJb+Px47heDmY0X8q0c
xsdvhN3HDwL7m7Yf7+RHZ+N1tv8y4qAfPeNTou2GU6pfHT/uO/8Vwy2ongyoy1pylJr4ZJ6d4l83
1HrJR9faTejTIu0X2nu9GfsLaBKahslgxi95BwV6DNnnv0RxhrZ9EJm199t8//wC5OLJp64fURFO
zpbm3hPabSn0dmJaLPtzgc0iIXvRXgV25JG2xcbZAUgfodNC1/i9PRQ3QgiUiqAIf0a0wby8A0Q9
X2yfrzNLGSzr7HtTO21bN9/5ZxjhCtKcf4tk/vvR/ZD/ujdgFR3Jo/e/C9oj3dqMEtndv1ryxfGp
eEeRPmKLvziclppYJ2NpSnao7m9LZjrjVWIeW7W0ZzSt43B9mFg1sLWWSXaZ/fdYnKqTSeRNEPE5
Rkwk0U7xDgTtwb5dSu32BrHXO3h5+wWgh0pr+x4NpwUbDya13Rv2ap8Fy/hojT3yMV2KPJ3bslmc
8kRLbtK2XmqHhQvRKCknr3WQo0l5pMtmuicxqaEnKSvB18DJTTCP4Uf/OWCEdBiL9gAS2u0UOTfC
/mdq9/poGjbp26MIxuihUDiaLyFcCd1wkgmwOQ5lgs97avrfX11BlByLHtD/GAR6fmt99mrLLls/
37YtV8plmA2FxhBEXc9GGJTSMsMdszTvQnzdVvOtfB0u8Kz5mBAMuHVdp6xzkkKJ7VIRAz3Dlj3Z
g5l+pBiZlV4PvpGjIWMrts0WzPBTw4ZeGO2ZShoHGaAljNeFNKIntmmRGq/RaDw2/uQhe4kZLxQL
X0N3RIbzv6qKubZtf5Gebnm7+Admff4uF/UIChJwpcwLxMDty7P3Z1OOYBI8GAsd0TD8xLD2Yt8L
tWoCbAuuj9DgsDBZ2eOMBnVRA2c91SDTBIl7J21gOviC4xjV5D8F5XkqLGVvYSe4hRGdBIvCEB9G
oENaZkVIOw8KYa62vn78K7xuzRTzC6eW2LhKvfpGSYF9jNu1QY/poiAjOwNOb2rqqiJFZWJw+CjM
OHVE+1sBHATYaJmfgb1fn/h724A5hfzpfzoVTb4+O45366GjWzAwEf5CjLudDHHy/CP3j9MelM7S
ajLlzi3CS6eNi/A/VQtGI+GCJdltFGvUYhCSw4EfWbjfIqGsyV6RyGXtOosa32ybovem2X7SwRG3
64OdoEyjYpAsF2eq17b85bU2HNRYZdCN5mPxGkl7HViQLSxhK+a1hOrngEBkMa4GtR9PiUnhubad
iFH9jacAV++1E+ggDLuJJpddvNh8sRFwA93tP/mm9GxHDnbRWb0s9HQ2JkZ7sa3giFHQpnTxVFsq
EsSvl0VRc5Vgd2mrhi1mHeFll+fiD03LZCjOOLvBEgFxIn3snRTj4hrbGtkiZR+UhvYuJKivVf+C
mm7EE/Br0j+L71+vhJe36Wlh0+d6+g7P+F31+lQt9sQTOzbqa7hHmZsZxbuD7vlgodgcsYjxIQy9
jcjySmwTGYNNyxp+t1K3uz179aaObrfi05woxxMzvunp7HwBQidDC+63b5kkdQQdKlGwxWTlf5TP
2FlT6gyqtzkoJT677vVyHztidptaWmOepKpzEv4YtKLYmFW45zUHE6s2VaGKKXevGNXPyUhvmxyc
GNklK4oTFhJTwrJZA41ETkeER91v0jtdKcTgOdfUhxEZAXnATVEYr67Xut3+4aI3d1KrMFgkX3by
6uTDu7e6bS/rx6iNM0Yx/uBpyC5D6/Pbs9KHX5f+Pky8UVLcAiykV81VpWlp9FwycRqEVPbVEz8B
l9jAeISgsn+Yhz8MjP97H7TPvzn1zpbC+o8Skvp/QLeJ+l7mPr1c53aXt1rWe7Q+ez+++/ohZbkf
YwwJ9l5CPF8sXr683GRHfO8/cnPecs1O9/txjdv9LSm5L9RCmUpVwq/MKA1B2c9FikTZZ/PqDtSz
LjdqZ9cJ7HRGen/70O31OjweqYtB6jlgxMhLFb6FZnhYLNkFDdQsHr77nQx9KylK0MxaKehorfXZ
sjwenHu+bPh0FXDf8fo3TuTWWCinMjtYmm+QPaUt+H6dqzW7DP43ZVdW7+IfhaB3767/rE/Uu6r7
93R56KrWyyN5GerFHHF62y6yiRNWXf41dvWuR/45m1yOf8kGcXDSp3Wv43Dmj7G/fzpDGYBPlG8f
7EjAwH5UXID4NQlBf4uQwe1ut1b+eKTbHOrsPHWMb5evt9Zt0rdLjVUMrixd5RJs5r29ihgMI5dw
5Asg7bbxwNQKING+RWHf8hVDynx73NziBSYMEYs0UaWPXkKrdLz7bDoENnP09d6GwnM7PWZCvb14
tWz69A6e79Maaqpz9Qj0CUxG0dBAvebFd3yOhV5vPr/1eBtf0fzD2LPfahDoZXTlkf1jJnc1d/ty
M5jRezTlHxbYf6bJCYMXU9k53nJCC51dEvrJ/wz1ZXL+7jub5OHL47IL6k3dPn5v65+xj/0nXEFZ
R89fgH9koCf9H06x/iulKOPc2N9DqXkwWymOAEfI4W6bDoTuofJpN9GKa1yQiseA1/dDwHOs7qtX
96eejrHmePiB0gNyaKpub+1eK/ZvRf63pH+KhHBwr++C539y4j7KCJo5O30w76rNu3vvk0DHAU7o
ltn4EQb5do/Bnf09q/hw06flrbc2VY6lrD4wTUop1S4b4gisryVU6J+XZ9bmpO55g3rv8UJ68+nm
9nk3khQCv7MLl17iCho+RPZLuz8V4GcsyO/w6lQEcOz2PnzqeFxErzvZ6LZujgnU0ueChvFOPf7l
5dSGoRj7cxXwjxCwJ++WZ58tapkRu5ZjyBlc+54/xJOXhAKVdy8v96e/2YIFSFKvP3trm9yVCCUf
erf+AWB2u3V7EMtoEyLtjXItwHDObU16sfSfCODjPMZeePJzERiMcej87+18TeB/cP2+1v8fUEsB
Ah4DFAAAAAgAeH9RQO+fL/7gyQAAPsoAAAwAGAAAAAAAAAAAALSBAAAAAGFzZGYwNTgzLmpwZ1VU
BQADxL8+T3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAHh/UUDWMZYEwuUAAB7mAAAMABgAAAAA
AAAAAAC0gSbKAABhc2RmMDU4Ny5qcGdVVAUAA8S/Pk91eAsAAQToAwAABOgDAABQSwECHgMUAAAA
CAB4f1FARlMDoQVoAAB3aQAADAAYAAAAAAAAAAAAtIEusAEAYXNkZjA1OTQuanBnVVQFAAPEvz5P
dXgLAAEE6AMAAAToAwAAUEsBAh4DFAAAAAgAeH9RQF3rx5K0KwEAxTEBAAwAGAAAAAAAAAAAALSB
eRgCAGFzZGYwNTk1LmpwZ1VUBQADxL8+T3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAG+AUUBe
h5/oINsCAOfbAgAiABgAAAAAAAAAAACkgXNEAwBDMzYwXzIwMTItMDItMTctMTUtMzAtNTkuU2hh
cmUuanBnVVQFAAOhwD5PdXgLAAEE6AMAAAToAwAAUEsFBgAAAAAFAAUAsAEAAO8fBgAAAA==
--f46d0444040adaef0c04b92faae6
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--f46d0444040adaef0c04b92faae6--


From xen-devel-bounces@lists.xensource.com Sat Feb 18 04:58:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 04: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.xensource.com>)
	id 1RycN4-00089A-Nz; Sat, 18 Feb 2012 04:58:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RyVOx-00007R-5O
	for xen-devel@lists.xensource.com; Fri, 17 Feb 2012 21:31:36 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329514288!11944982!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14050 invoked from network); 17 Feb 2012 21:31:28 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2012 21:31:28 -0000
Received: by wibhm2 with SMTP id hm2so5973891wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 13:31:28 -0800 (PST)
Received-SPF: pass (google.com: domain of pstroud@gmail.com designates
	10.180.82.227 as permitted sender) client-ip=10.180.82.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of pstroud@gmail.com
	designates 10.180.82.227 as permitted sender)
	smtp.mail=pstroud@gmail.com;
	dkim=pass header.i=pstroud@gmail.com
Received: from mr.google.com ([10.180.82.227])
	by 10.180.82.227 with SMTP id l3mr7699813wiy.1.1329514288009 (num_hops
	= 1); Fri, 17 Feb 2012 13:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=w+PjDJXvxnLpM6xH0LvEVfLyzum/+hwSwO8tyTqRSA4=;
	b=rMbQzEmung+FKrd1AEVphSsaAgxwUC3wap/LOQfXpzK3vpE2LIPuBuW7bcV9rWbljE
	wLuINnfqe4Ohzd2/nWlIUwyBp8Vwb8I9IpRHXz1CQpmftE71HrvnLv4en9x2zaELwTvU
	NlMooDnbgWpEyAk/nGFTquaxUKjx6VYR+lRBo=
MIME-Version: 1.0
Received: by 10.180.82.227 with SMTP id l3mr6484015wiy.1.1329514287918; Fri,
	17 Feb 2012 13:31:27 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Fri, 17 Feb 2012 13:31:27 -0800 (PST)
In-Reply-To: <CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
Date: Fri, 17 Feb 2012 16:31:27 -0500
Message-ID: <CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary=f46d0444040adaef0c04b92faae6
X-Mailman-Approved-At: Sat, 18 Feb 2012 04:58:05 +0000
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--f46d0444040adaef0c04b92faae6
Content-Type: multipart/alternative; boundary=f46d0444040adaef0904b92faae4

--f46d0444040adaef0904b92faae4
Content-Type: text/plain; charset=ISO-8859-1

File attached.

On Fri, Feb 17, 2012 at 4:14 PM, Paul S <pstroud@gmail.com> wrote:

> Andrew,
> Thanks for the quick response! I was finally able to capture it and get a
> bit more information. The problem does not always happen, even on 4.1.2, I
> was able to get it to boot a few times, though I was never able to get
> 4.2-unstable to boot. There was lots of strangeness, such as after I built
> and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
> working.
>
> That being said, I caught it on video, and captured a picture of the final
> dump. I watched the video frame by frame and the boot actually got much
> further than I thought it was.
>
> I can see that even though it does not bring up two of the CPUs, the boot
> continues into the kernel and dies somewhere with a:
>
> BUG: Unable to handle paging request at FFFc7f(maybe).
>
> I have captured several images from the video that shows the progression
> of the boot before the crash. I think I have gotten things badly out of
> whack at this point, so I'm going to stop, reinstall everything and move
> back to 4.1.1 and see if I can get things working again.
>
> Let me know if anything in the pictures helps, or if you would like the
> video as well.
>
> Paul
>
> On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper <andrew.cooper3@citrix.com
> > wrote:
>
>> On 17/02/12 16:21, Paul S wrote:
>> > Environment:
>> > ASRock Z86 Extreme4 - Intel i5 2500
>> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
>> >
>> > I have installed the latest UEFI patch(1.70) and all tests were run
>> > from a reset of everything to default. I have tested with both Ubuntu
>> > 11.10 and Fedora 16 and get the same results on both, including
>> > building xen 4.2-unstable. I bought this particular MB because it had
>> > a know working vt-d implementation via VMWare.
>> >
>> > NOTE: current unstable as of last night is still affected by this
>> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
>> >
>> > However, after correcting the library error, I was able to complete
>> > the unstable build.
>> >
>> > In both cases, it either stops with a panic/blank screen, or just
>> reboots.
>> >
>> > Here are some other notes:
>> >
>> > 1) If x2apic is enabled on the motherboard, it almost immediately
>> > reboots with any of the configurations above
>>
>> There are some fairly strict set of requirements on what which MSRs you
>> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
>> early in boot which results in a protection fault.
>>
>> >
>> > 2) The boot gets to here:
>> >
>> > (XEN) HVM: VMX enabled
>> >
>> > (XEN) HVM: Hardware Assisted Paging detected.
>> >
>> >
>> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
>> > where it hangs with the blank/panic screen or reboots. This sometimes
>> > shows up on CPU 1, CPU2, or both.
>> >
>> >
>> > 3) There is no boot log written and the machine does not have a native
>> > serial port, so capturing anything may prove difficult, but I am open
>> > to suggestions.
>> >
>>
>> Try booting with noreboot - that should keep any panic message on screen
>> until you manually choose to reset the machine.  Seeing where in the
>> panic occurs would be very helpful, even if you just transcribe a few
>> lines manually.
>>
>> >
>> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
>> > is enabled, then it simply panics and reboots.
>> >
>> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
>> > being enabled, but I did check it with VT-d enabled and the boot
>> > looked the same. I can capture it again if needed.
>> >
>> >
>> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
>> > enabled(which shows working in xl) and x2apic enabled.
>> >
>> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
>> > includes logs both with and without VT-d and x2apic enabled. I did not
>> > actually create any VMs, only booted this and checked what xl reported.
>> >
>> >
>>
>> That is rather interesting - I am not aware of any XenServer specific
>> changes in this regard.
>>
>> > If there is anything else I can add, please let me know. I am going to
>> > download 4.1.1 now, build it and see if it works, because it does on
>> > Xen Server. I am open to testing anything as this is an original build
>> > on this box, so I'm willing to knock it around if it will help.
>> >
>> > #
>> >
>>
>> Knowing whether upstream 4.1.1 works will be very useful in workout out
>> whether it is a regression introduced into unstable, or whether there is
>> some XenServer specific change which we should upstream.
>>
>> > Thanks,
>> >
>> > Paul
>> >
>>
>> --
>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>> T: +44 (0)1223 225 900, http://www.citrix.com
>>
>>
>

--f46d0444040adaef0904b92faae4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

File attached.<br><br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 4:=
14 PM, Paul S <span dir=3D"ltr">&lt;<a href=3D"mailto:pstroud@gmail.com">ps=
troud@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>Andrew,<br>Thanks for the quick response!=A0I was finally able to capt=
ure it and get a bit more information. The problem does not always happen, =
even on 4.1.2, I was able to=A0get it to boot a few times, though I was nev=
er able to get 4.2-unstable to boot. There was lots of strangeness, such as=
 after I built and installed 4.1.1, it worked, but then, so did 4.1.2, now =
neither is working.</div>

<div><br></div><div>That being said, I caught it on video, and captured a p=
icture of the final dump. I watched the video frame by frame and the boot a=
ctually got much further than I thought it was.=A0</div><div><br>I can see =
that even though it does not bring up two of the CPUs, the boot continues i=
nto the kernel and dies somewhere with a:</div>

<div><br></div><div>BUG: Unable to handle paging request at FFFc7f(maybe).<=
/div><div><br></div><div>I have captured several images from the video that=
 shows the progression of the boot before the crash. I think I have gotten =
things badly out of whack at this point, so I&#39;m going to stop, reinstal=
l everything and move back to 4.1.1 and see if I can get things working aga=
in. =A0</div>

<div><br></div><div>Let me know if anything in the pictures helps, or if yo=
u would like the video as well.=A0</div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div><br></div><div>Paul</div></font></span><div class=3D"HOEn=
Zb">
<div class=3D"h5"><div><br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 =
at 11:39 AM, Andrew Cooper <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.c=
ooper3@citrix.com" target=3D"_blank">andrew.cooper3@citrix.com</a>&gt;</spa=
n> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 17/02/12 16:21, Paul S wrote:<br>
&gt; Environment:<br>
&gt; ASRock Z86 Extreme4 - Intel i5 2500<br>
&gt; <a href=3D"http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme=
4" target=3D"_blank">http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Ex=
treme4</a><br>
&gt;<br>
&gt; I have installed the latest UEFI patch(1.70) and all tests were run<br=
>
&gt; from a reset of everything to default. I have tested with both Ubuntu<=
br>
&gt; 11.10 and Fedora 16 and get the same results on both, including<br>
&gt; building xen 4.2-unstable. I bought this particular MB because it had<=
br>
&gt; a know working vt-d implementation via VMWare.<br>
&gt;<br>
&gt; NOTE: current unstable as of last night is still affected by this<br>
&gt; library error <a href=3D"http://www.gossamer-threads.com/lists/xen/dev=
el/234300" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/deve=
l/234300</a><br>
&gt;<br>
&gt; However, after correcting the library error, I was able to complete<br=
>
&gt; the unstable build.<br>
&gt;<br>
&gt; In both cases, it either stops with a panic/blank screen, or just rebo=
ots.<br>
&gt;<br>
&gt; Here are some other notes:<br>
&gt;<br>
&gt; 1) If x2apic is enabled on the motherboard, it almost immediately<br>
&gt; reboots with any of the configurations above<br>
<br>
</div>There are some fairly strict set of requirements on what which MSRs y=
ou<br>
can wrt xAPIC/x2APIC mode. =A0It is possible that we are tickling an MSR<br=
>
early in boot which results in a protection fault.<br>
<div><br>
&gt;<br>
&gt; 2) The boot gets to here:<br>
&gt;<br>
&gt; (XEN) HVM: VMX enabled<br>
&gt;<br>
&gt; (XEN) HVM: Hardware Assisted Paging detected.<br>
&gt;<br>
&gt;<br>
&gt; Then goes to a &quot;(XEN)Failed to bring up CPU x(error -5)&quot; and=
 this is<br>
&gt; where it hangs with the blank/panic screen or reboots. This sometimes<=
br>
&gt; shows up on CPU 1, CPU2, or both.<br>
&gt;<br>
&gt;<br>
&gt; 3) There is no boot log written and the machine does not have a native=
<br>
&gt; serial port, so capturing anything may prove difficult, but I am open<=
br>
&gt; to suggestions.<br>
&gt;<br>
<br>
</div>Try booting with noreboot - that should keep any panic message on scr=
een<br>
until you manually choose to reset the machine. =A0Seeing where in the<br>
panic occurs would be very helpful, even if you just transcribe a few<br>
lines manually.<br>
<div><br>
&gt;<br>
&gt; 4) Xen Live(<a href=3D"http://wiki.xen.org/wiki/LiveCD" target=3D"_bla=
nk">http://wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic<br>
&gt; is enabled, then it simply panics and reboots.<br>
&gt;<br>
&gt; The logs(xen_live.tgz) are attached. Note this was captured with VT-d<=
br>
&gt; being enabled, but I did check it with VT-d enabled and the boot<br>
&gt; looked the same. I can capture it again if needed.<br>
&gt;<br>
&gt;<br>
&gt; 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d<br>
&gt; enabled(which shows working in xl) and x2apic enabled.<br>
&gt;<br>
&gt; I have also attached(xen_server_6.0.0.tar.gz) these logs, which<br>
&gt; includes logs both with and without VT-d and x2apic enabled. I did not=
<br>
&gt; actually create any VMs, only booted this and checked what xl reported=
.<br>
&gt;<br>
&gt;<br>
<br>
</div>That is rather interesting - I am not aware of any XenServer specific=
<br>
changes in this regard.<br>
<div><br>
&gt; If there is anything else I can add, please let me know. I am going to=
<br>
&gt; download 4.1.1 now, build it and see if it works, because it does on<b=
r>
&gt; Xen Server. I am open to testing anything as this is an original build=
<br>
&gt; on this box, so I&#39;m willing to knock it around if it will help.<br=
>
&gt;<br>
</div>&gt; #<br>
&gt;<br>
<br>
Knowing whether upstream 4.1.1 works will be very useful in workout out<br>
whether it is a regression introduced into unstable, or whether there is<br=
>
some XenServer specific change which we should upstream.<br>
<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
<span><font color=3D"#888888"><br>
--<br>
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
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><br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br>

--f46d0444040adaef0904b92faae4--
--f46d0444040adaef0c04b92faae6
Content-Type: application/zip; name="images.zip"
Content-Disposition: attachment; filename="images.zip"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyrqgvei0

UEsDBBQAAAAIAHh/UUDvny/+4MkAAD7KAAAMABwAYXNkZjA1ODMuanBnVVQJAAPEvz5PrsA+T3V4
CwABBOgDAAAE6AMAAJz9VVAlXRM1DB6kcbfGadzdHZrG3d3d3Rto3N3dnYMe3N0a94O7uzU+z/vN
P9/N3ExMXlTljoyoWLsqMnOtHXtHfa1+fQJQ5Iw9TDnZmHi4mVgBX+sAMQAcDAwsDCzc/zF4eHgE
BAT4//ftP0NCQkL4vx4SMgoyMvJ/VxRUVFQMDHR0bGxsPDySryGIIgAA4hvE/zHA/2MQkFDQ3/57
LDwCIgQACuL/Y/9fQTQAJAQUFCQ01Ldv0ND/Rfz+iwGg0b9hkLKKwmAqG8OSOWOxBSYWwpH/bOjH
Vpm7oWA3cQmCR8D5jouHT0lFTUNLx8HJxc3Dyyf2S1xCUkpaRlVNXUNTS1vH1MzcwtLK2sbVzd3D
08vbJzgkNCw8IjIqKTklNS09IzOrqLiktKy8orKqsQnU3NLa1t4xMDg0PDI6Nj4xv7C4tLyyugbe
3ds/ODw6Pjk9u727f3h8ev738or+H2RIaGgoaNj/QYaA9PzffNChv5GywmCIKsMaO2OSsQXCYf1M
LGzohydnV7nBNnGZQ8Ch4NilvP0f6v8D+v83zEH/f4H+v5j/L+SvPgA6HMQO1A8oCDIAJDoACh3w
BQYgQUH8N/jPFwbsDFPCRCUWWoflSov+RPDCAifyLQ2pMK0XktVEVIBGwM2BWWu/xhPgwkv5J6oR
ijmZ5qIEM6KELTnypIEUIuL8Ezq1onoTd3HWctR4QOYfrEVSHlGEP49sKvuxN87mGIjx58R7sKTa
U5hV1j7pDp4AZTVi1QppR0v1t0/IS/4py6HkFTfxmTU4Tb0iTzLSW1N/Stz6n4GxQrrBe/y2JgKd
VqnLlCRuFdMotrGty7WmDThS6KbbXfW4HkLHQLvVf1m+rg4jNGsF08vkyfmq6r7PyNHPz5TulKDQ
La3Qk8Rnsz/rPdflu/qtmeWTlTJhrE/DgREufEHNx/de0dNjODejmcsuE71ch8+V6UP3sZKXh5gB
6YeXlzEmGS+JSRCtt9Cikqgu6mF8QT5qBoz1cdvKiab6BfeB1xpCa585jh4w9sNBT0gKrkqGAit3
HPM5DRUput/5eNPC7anT/Og1ZO1UobFS8ElYDVak2zopoAgDrqer36f49mWTZi8tNb8AzsGof9VL
o2Gz8iehVQ8QM8LIULHPufqZOL4AqGJkV7oVZpG3s7cbKznSuKpZZwwCpkg4LfUEYh3TAj/fXkkK
Dc817WEyZa4HSjYM2T6PwGtjM6or88VfgBA2i3RFrcOfzCkZG3EZ16p1EXOhF5o/Mq4MAya88S41
VIeX5+RLM4qFDPJCRQQVbLknOCSFB3Nltr1tI6TUx37k9NbCAvX94DnaLk3jwPxhVji+YQmx/dIH
TH50K+/UHmwXqoR/qtoOvgA+jeW3yGlF9ZzPOY26N2XEUFU5f6y6JGLyMU/hS22QIiCraYyKC/aa
ODb59FWu+LUauu/H94Dnr31Ltb9nS0WUiqkFUFJJwh7hHi5VEDN7Dsyu3m3Ulp4Y5pL7sob8PX75
mqqsQRP1+ahLddFWyB+ibpLLJuN3GmcTp26M7suziWRa9sXdajsv9sgsu9q+2k9d5XtY3IVW7Rav
r9xWzSYn1M8xUXbdZQlcJNu176Bmw1KBuiR3F5uXMaanhN5tVs/H9XJMmoHu55goJTHr+L5zTnGS
lGKWVpVUt98iV+ybkV9ijcEbRkEwtNLVkDo5fluBFbq/KKxceKchXpzPT/8taoB1N8CKzscSQcy7
FA6OBVNur1slBvRh+ia0Q90/Yp37j2Hjp9ujDRuagQOT9CVDQX8skR8Fq7mKRiwpHf6ZSrUuN9MA
LRiwmxZ66HFrF/RRg6jjtvWb0yThogiTpKDKuynRs3RWQmuAbi/XjCENLy4ZcxQjpyw+RY+cM8MF
hl0WEq2Jmg5Xkjyv7rUTb7otbQ2JW16HXK1vxTHuXG8d94t+dCPV1V0ripy5y7lExYOt3iTcm6OK
OqB05zNnMExYx1BrouPdVBcqc60HwhjODHljVZLks0RAqrsBnDl+7Ft6LHaNOawzlGuCv3Je16vy
7gnDlr30oRvmkPCcKQUZP1RcNw3IN+rvIfGWGikC1/5q5cyh3B3FhloxJF8MYfwg0NOf7q6OQCpp
cYQKXPEm9QUwvI7rW6perRmOicQLdTfK700O4vIEK+JVpKg/4B1/AYwyRijgZPLCsdZtNfO8dvo3
ye0JPV81K2QZNJ46fKyXnfVJaDKlM51QeBno+SWiNjWOnniSL4UdlZvIn52Ok0CLaDVOHT1Zr+r9
rf5aSPkjTbHuWzwQzZmrLIlObc5zbZd6xeUTBA08JfsFf9wqwPng7JhlfQlx0UouFezqE0iUFBRQ
p9W66qKcU2lRVOE3SkZKuG9FUTQmhLSLcwo1YEBJaUmpceH5fA5t9XwO3R7kwjBbHv0vNvNqlj+K
nOp0f+mz7JBpZJhFVXLyctRYqgrGeSuRtoLK+liGk9M4f1gl+lgU82eV6P6+G4I4sy755m1p+ixB
18akS7E0jiTdd1TFbnZDW0Y20bIbrM8U7lghRgJmGPvxe9j7crm9Qjmi9nxA80Z7+FCPRUR0nHeU
s0Qbg+dS4cx3MpPCuL6BV3kWv/jJ5UPe9mwEujtHQow5w0lSTHuG9oKOYuLXzyVJHX/S+BYbcvL2
YeqkSxUk140KXHVs5c11cM1HPpE8x4UOoMTUdDHLOA4oTRcXVM2RWQDDFqjcQquVLMdbkMiuoFGm
uugq70Dd0F48rSJO1EjfEzk4UipC6FEnuEBq4SRp59+8bb19JmIcdVHaMKV8prqoIx97Gqwnvk7Y
7OlTXBH5GdZGP7NXc46vynoozPnL+s7vLK7dzNaULEUFX1TJJpQDrCotZaxCrWMuyLecwJ5YbT0P
XJJVSHWK2sRbdXGvhv7djEQ/peP+YjPHEMdmvcZb/rN9it+SU6Od4TcFCigd1lPGOR4LSDIpFkHW
MnfY8IDd8BGNXBZJXEz3EusiM3qSca1t7kzwFgWWN9g6/yXP53EH3mYkefv1VHIRS8YvtXDxaCtq
D1llcEXtinnP6NBfas0YUGb9qZ0khvfdMTlof77+AfnnjGSzb8W63xurUkwvHfXKVmvNIyK8Oz3B
F4BFwmXEDXEgie/TzbCJftG/uuz0qZEDBiYifB1i2oVdB3mn2hqJkYColFsO/rjMq8pnIy39O7KL
I45ippxznBO7Zrph6+dyk3n2Mxlao2sfz7Wi0uyxcFNB3Bfg4joh+wlV+VTlrENr4YDV1/KGQ38G
e7pKW4/B3//jox4lQCdfb7G4u40pFzJ0ppb2HmGU0RO9vzZpRbQR3yHfmyblZeh6lNR5w0eDYYjT
A+denCrc2C55pBGWf7EeFqYEg2e92pHNE42er5LnyuOJKvlCtUD/RNVTfhDv1WdFrGTc0dqviiFJ
4vvFFVYSHOMqqs98mi19tD2euZlTjed+Bd4+x1L4hNOzBiaD7wQLyVb/6LHGwc3c52jLIhkzOX9q
KkAAYjvqnDM6W7VEfyAWj0xxMybmsgLEX5os2RAij+/taWeuYSQkNwuGjudvBb2pb2hcpmy9+biw
OavavIqdpktspwl2Jv9DWG3j2h9qAMn1aLer5rE+tx+XWp816g7vI1rrF3mJQa6ShrFuPFQkhbtc
OO3N+7ti1vIllQSwarrpE+sbuGI0UUHwksfRNy7VOQycURHYWrS6eHTyUJNcRPUWfcRBlICIddYF
HKgdhPf3ieDPl0vv1p1LvP0OqMCaMY8adAFQUcCs5ZUx+5/HRAIjI0JlRTcfIG4+YIknNJyOaFse
7JEtz1VfK0qgQAfrkhigKICmEJqklq60OaT15044Aike77X+U9nlFwDusxjublHc761Z4QYl9guw
UhMAO0TVsvz8i8LYMXWm7rfvklZxzDo5xncBFWx3e2CSosMj2ItpnvZwUS4RHtoZB+xzaP1qetpx
BbTGnmrUvdhqdILNkXCy5tmu0NuTc/E0XM48bPwCIHu+Dp4O8E96XZTsPr2UcoX2nxFgZS2B+Nw0
lFbXGM6edtdu01xbBSWcZdeKUmuc0cDyron47AlsP4MUD2jLYCVGWHzjUte98NW/r1RTKA/hz4sF
Cdm9qvuRy8arrFDFvSBJoR+sL/D7+LvLpPhGHEyMBfN+2GzW5vt6I7Wiw3jt4bmgiuqjAO1LpQFS
Jl4l90O+LWid0qNUHfT8NByT+h7znOO6/B6b8V1Sl5LUGcR6egc7CaLDOg313Ys5o3ZIcTB7EMfE
zUq35F+ALtuqG9T3ULPpvTKwkodvXcCp9h3T3hGb5RwnvTDDFCYqZ0vhZu7UCas0V3JFXzz54A81
Ei4Uj3gn+mpQYukyx6J6IhBn5wLD0uF20exWk5y5c5hMSeH7AezV/pzrB1130hWHE1dLa2vE0RZ9
JAZrOg2BDarGhTB+LVUWxs+xCddp3BXb3Z+Jp+AXDaPfQYpFeYNRuyiKGX9Rtz6JS3ziHlyE9og4
/zai5kb72aBIAa9RTk5rZhh+pa5h8rxGzTbfpL3JrlExowVKK/nrb70vuvAH84q3Zu6z0bGKOBnC
Ovhxu5VRKAztYMa1HWOvfsSgwsFD17J7TSh9W/V18Tmq+eewoMgH08SR2MR3oXJgClWmKpSql2e2
PbYrx4bhVOPE5gTf98hTcXuuPxpkb8JcTY5thm+LbXkQrJX3Y04i+8kbO5rhtM3Hd690oV6v/1qx
f8TJmvVVU9W+vOEG9Iwr51dcK2T871XlwJywFSt1bs3LatLRnvNvNAk430xXEu+ZY+afRNn3Ohs2
D2ItSJHXhScPKICKprjzbqX9Iy4D4u+F2kcT1tF98ePQI1BLmssa3LBWHhbAT9GHly9wek6fqCVH
Meyg7W5f+FTrHv5lZZ04VYMRxiOOVnYYf8Nyko3QYRge05RQtUmxPaSfvPBHqgm8QTgsoa+PsiN6
xl6RrDLyuQS9wf7PrpY7V0wTO7hPFUTMNVHCT2yKLcKOVpQ7aQSQKSOeO4pg1LGTsLLiWuusB2sf
WQqaj6t+TA9h3LFYU3trSORmVCfmCOwtcR/+IWXwuF/GCDwuYZxQqgxSrQqrIrbJimLevZDM1ajB
6uurWvKqohVEohOq2CJJ4YkN0Bid9Ocf+0EU4Pk/j2q0yhns6opTNLD2qiIeZS0mY15mdZZE1N3a
pt5Y212y0wxWDbsQvYs3VdkQepwe5sm3X9nbca4bRl+AUN3WuSsmMb6RQ81rtPL4OkIVdKUJ+AEo
eavD5OU6AqowUZJ0+jGfH7GN/sF4wqFc2kyFhv+eEr/ze3LY8T6ME9nUvEHI1+RK6EaFYosF6sMA
C/R0Vgfd5g8mINbzhnzca92Vg90L5JbNYpU97vW5YqE9uRrJJXBfLB2X23GzE5A9dNS+ezxNCbZJ
roYkLFnrJcfmTc1rII/Anz+WoksUH5Hl+gVQLg32zLZTBz5W2RMm+Sy2xeSWtCp2jlddu37MyaQp
+NkYWxRfs5DoiEwg0zf/GpvSNEeXnA1Wz3Mn+kYVosmSd5ShhOD7V1FUfTNj9ofJt19DSqIc8zQQ
7ZVoi+5kqnF7dhtzR+tkwQtR1yZCJmEGbPQzbo+DkPQt9V1qIbA78Tpn5RSJkzwtY5zuZFS8F7bh
7bzIj5wr5/gpzARkLboLX4C6+bbz4Lv8ypqzzqx+rfGEe+WjfGqduHqLdHZWeQ5Qau577M+k3Ch7
aVEFBRDYxb0qEoPzYnavdkkXT2LDBMg6XltxYTG+A8BvPEBX25/ShULMAv2K/IELU+T5cia1urNX
CNY+3RpgrPxm/ZYSVeWJQmMyQdNpQkL3HhIVhMy2d4bHhGUfJVS7AekHW1lqDS+mz4BB8YnOMhzP
yezJFtfp55+So8pEhYUvPghunt8ZKYfNz74D+qKibk0k8tDkOQ8ZxyH6Y13DS/K0cbvktqCTbF/h
aTzVxgZLV2sbDK1f6hhuhL5V/1Nu/Ql0ZTNE2hpu4/2peg3wJtGx6yHoiRgpEsiU0CQ8an0X5+i1
DyCjFdKA0cQDD7QGgOZ53f7JQB0VDAa47eWPEf6e4UxWzOONgY2E6MdaM8laP0xAs9UcSsJeuvKA
lE51juu2McQGeYdbbt0lewh6xIG0MHgjKfuBWhz6EmdrVJEiUQ5YV1CcM3q8hCsF1k0l/jiNrl2t
Gf0eZrmj5TKeGvi8v2avs3RD1RlmXanYnFWiZVMitQMRRgF5vA+1+YOeKtriwEkeKq1lGPDmf+z/
USN2UOeMq4M+FB55eJT+c+4LcD6bBRMHebd8RZO6xQ23SfggHCuOklgp/z0bS24u+U9fDOapQSiH
x/x4jU5nuJYpJSn9gJFHVQdmwc1jhV38v4w/JU5CzwE2Ycl+onr3vRfAn3uaUTRm1piUKWYso3Vi
2ncviawYGHA8gl6cZ1yFxbceRRA766xfgFH6mWYCjdTjZGiaxPYfr4s89FnACP9+D1Ld2GRv+2fD
I7B/WBrFIrQtSK6h/cW5jZ7EYaRjHPZdOc3S10F6xsSLutStQ+/V55QPmhsOr1Trd8v+odH2DAdP
bbDUnbd9rYEjsylH9wKs576y7Lepagg6AcmKsdE9+sXjhpY3w4grkaHxeomPRcKrH6hieh7tpn4f
+eaCf8fpZBBGqW8JWUnS6HhJnKz63vzGf4ZZI+TBbfZjc6Y+Xrbc2pgR9Dz1KRI/5v/Q6sd7CXy/
1U//M0at9U3tC1DAq7/K80NVKd3FwbVlpXW2K2yzVMPu+u4++XFY7GhTkjk7Ev0+dwjNVd8xrFC5
yJZbPMDvO2m4cjK45Ba7rWOegz8+heNPNQbgfexcLHTUzRXjnHuhbNycoSdj9DhKuOXxGwA+DgAW
DC/l25dsiyN6iYkd/Dfqc2n3zo1dgtMSDynjmMIvN+QQH797rZgYswOsuwKWspd55r0vbq9rHu1s
vNRQkDtIXerXhXF8AZrKI364Bf6luPDGIjQtrPUcdl2VpbC3qSIsul4V0nse3f+PEeB56mxe/jXh
ThVBIgjtH7vOavgCwEuUgoK5XDoR0ceJj7vdiNlAf3SsbgexnDPti1AmupJEymxlbXffMkDXTZKc
DeHHHiS8JnxHpQP6o66hnkx/N8ep74GCJJptcwfWRuvd6Y5Tp9q1ExbJVgNXY8SjpdoLT90HCBKi
7tA+d3SmMrIVubH8+Vjb+t6iE9RJhwsTECyj3VrZwz6hf13o7SDFB1NxGR85i/cmbW0d0XRECdEZ
DNtxwUJGfe618Tpzdhj0d/Z7LVKkigxDXS9DATiCNi8Wr5FSOw9T/vpM9BkanM4uLGvYCVrJfY8f
tj18jKFdHeKta0NhZ2w6Kk4uAQPtb/mocs+e1uhKCe141C3OsmliNFYdXR2MM2BykW1alfBC4OQ1
4aYheBwijAMDuWb1mDh1ymB13Jw1dpULwAu7XJngOhLAp8AYS4TwL9oi8SPzoFL+8Pl5w3eBIzbg
jW/raOsXxigvdKWAkQbqcpaNnlm4a9HCuyh2TOs8AxS3c8aN0Fnwpfoj0PJNAZHnD5gxoWDmd9YI
lKBwLufif3q9TuYObWcMgmhG5sSe89yLgz+Wt9jlrs2o77031bXAWYKma8h9mZi8WZcelykx047g
r0h5ulAqhwHLnxlv0lYapjFh5m8eDzBtE7RvErCOtkBxoO2rWR8WWiKBww9jzTjFUu1b/2oEv175
aIZG+a6cKwU/uL026MRiAVYSsajfyU3MWyZ+01auxmZuiWctzv+8H3a0y6zf/yawsF6rSFdap3fY
x4LuJjF1KknIgjs5xxrIrTcIyAU8njjMPyrkA4taYA4zxCaCnPT/UHiciVuf6HLQl2U9os+OTLSR
PrUTcsH4aAo08T1QqHYdO5QsiHhoGlA2t+ErveRfYL6Ee94iPVO/qMvbPMsuMjExLe/tT/02oRRt
Pc15qjXkAPFKoYqCbjljfNSbAz3ASjXH1t9ET0GvK5ScyYKDkw6NY9lxG7kbHjyEUX9fugPo0ugj
Td4aeV4JlT34cxWCBXx8tgY9fgc7o6v7twkbLG5a3M3rs01M4P2agrOfZh2fIaLPtD5Mvm5wBPKi
cozzI6vcTesSUVGkmrGE3qsRS/gE6zbY6riMuvWYpKZtoqOh90OVek9fBDzGBaRaa5Oht29xEl9w
B2xTBKv7kn7/nNWqj0eHWECQFi61P23EA3VGIBUyIZ1MTPe7FC9wJjEBi0goLMTOnL79eo25HLJp
iDeeOVbaKub/JoVSB3UlLmoHhTFI0HI/JVojlJOmfKRmeZ+xKyXgwFMrQpC5Dt0wJf+Rzu4+pZIt
hZzrqhdni4gbPv1zP271sVbZbJKYfyk727z17c71NOcLQFfZDrGXekWlraDvfG4Qv3uMbKOci8Vm
dEU+37UML/H4ulJk7eGkv8alPIn7qSJoK5UwLasCCgOfmW+Uo/iow+SqFlQy1RzKRkLhjJkI2Tiu
RiMl0ZlxqKe9mg7sqEskWfM1fNgq9TuSbCfC7ivJulrkMP+1kbB8UTyXMhJqpt+kPaHrnF7US5QT
cedEDMUaTY2VkOb4o9KnJrdWji5HLxLxmpVo3VaJpvrT/Jw3E5XICygmUMumtexX2uA6bAtsgJ+y
qRV/ZKcy3arQ457U4f5DabYhPKnMligazzGhIbBgy5oJAilrZ0VmiYmTlrGUM7KozqqLuZjZartV
FwNVGgk1olBsC+1MRguqf7w3I8TZbKffHQExRn+KwEbBIC4oe3E05HBCmNj/ybKbu1WloklwwK3q
CZKa+v2NrCDszEuWQa6PW6l7dL5WHmfJZmPOzjharHPxJ/3fRgLHDEuEzTNPDqmB1kWm4tACSUfa
OG0Y53yflaYlZvJfvywQ8SZi3DiukSaxB1syKUQ+Sm8oENNUHx9q86TsQdXVfrxkyJHpv2N6fYU+
U+aJYoJrzzCCaoeCV+iXg6s2k2J0Mz53RxVL3T5/3NV0DcNDMRR8AyBPXmsaz7udGi1wh0gjBMdf
f9gsJrIZWEIIbsww53kn825e//cNGAdxUpL85B3PG4ZNq/iqmGYHDy9nmiVrT2/XvVUkABgFdj4W
lavSQsdCJrGfN2MPQER5nc9pCEfM8pTYdqWiG/9mkTyph4osOWdl4yzGGn2LnaSCjS8AkLyHHyGR
MzpiJwhNYpXktykRfmNRnLSnvcrPR6FUE1tr+1l22pee626qrkn5dMWI2uIk71TTbT4sF0lqwTNB
4eHvXGkDS0l46HodV7iDmFmu1vUGuo6tlvfFcpPfDfjbau1oDhK0wkf1jCzreug4e/aPuFEjao16
fB8RzBNlch5GWOMnqgy9omRXkYQtozgpkpRcpK91XlESHSvE/M30Ii7x0s+jbE9atm9i1jfITDTa
75rW8a5VaSbblRdHhKg6Pmf0eWokoE/vYndej7K2qLqGo95LtC7uvE4wy7yr2f/JWKFOCTa2TO1y
GyXG3PjgC3AXAj+m5ljFnTBgKPFaLn44TQja+F0dnkR8AXYZOt/cns2YXyXEBt+hiVcr3FExZCt0
Bm3mqkahMHGJNNepK6rSXhk3HxbEHQpAMtOaPbMBA0l+UCqBpB4hqZkthQaeXM6B56qTP9qlOlq8
8AQ/hFKbC2yjiwjC7rr2BagYiPs7FpF3Y6XRN4v6Ysxf3noNZcb0p3II7aE/1fI5PPD55MmHDNd6
bWKL7kk7ph+m+bI86vYoe0CtoChmKhp4+mlFznBTU3f/i/pioT5EbhHYTjdszs9EP9NDjob6ONFB
SyfhiL34LS0dvcAr/aXvic1NST73WWf/TY0T5lmhjSX/4RecGjdyYMwSo+Lg040V2P6VPS0jQdJ8
1Mcy9J2dqoEhaFefHO4v5YXzrLqOkWHrrXqXi43DLc/3F2Hat8zHWj5JYmdySk/Phyl5T7ygPa3A
XdzAB5i06QHbl3ncxSbh8oIzG01QGxFV+x6BvcTWkAiCtE2FkEOmwhcgV+jccIFTkc52rIQbvWwe
4mMQTZivuPKfds0P7aLkGQPspy8AYt4oNvM72fJyRcOWPoibTYJC6/ZOAm4M+lbTWxDG5b7jZZ4t
Di8S9wS2VLpsItIPqn2APmh0FkqfOH830bdcT5/8sDBHrB7pavxtKb3u5LxkmwNSlGpJL/X0v/pW
iq4FvsWpM6+wWV5xlhrGnNxMPW0iyXXQ9xpUbLfXJM10II2RzAtMQbh3/xahDp08i6J4qJE1soee
FqewRoAKeJ3Dm3L7ZjoPYjSVXiZeqo0Is5WKmxqqIuZ5icOpN+5tkle4sy6zdZlvUIJIo8ITeCZc
YSfKHY80i+PV4nLS4EVV6AqMai618sz6G5d4cKEy2sN6Hmd1nG4cd4u07LL5kubiCO0iNUKw6qOB
4w3sJELRnbw1TyRo2eFG8Te0KfctmzGlHyVDb850Xb3kKb32gAzkSNnHyvUQEvTI8Xd3lZkvW7qa
qtFj+fkFSJVVbIIMs5oS8tKBJ+Y6i1H7hMVGKyEdmreIokVy4rBIxsooAPxvAKfDLl/0h5B2IIP2
UQrWImbB2jp01CJF1XogEAPBq4xRijZqcBnESHaPQhe0OMlevslTYPmrvh/uZdUf6wsgrBiJiNS5
H1rrNTHNa5oP/Gm48enOYHF+jpwjiV9AJGgT85q7gOaZVdiLtZzM0d+gI+GxIU29nANUhqQ9oysu
/M4ovtwZizm0oKUb0TM2f6E/3BSfvnKqJ14/WfGMvXXaYnOjMFQxVZeYJAIkE+Od0tXlXsGQSYwI
Juncaihty+yNWHyWqZ8iMyNkPVC3SLShbJdOXdPuSLLu0a6MCZ4vsoavRIzAxNr7jo1HleWpihaC
YIouo7bggQ89klaGqWJX1jhLhp9Iy6rCRCOFLC9kX34HTMumnW9g2B0HBjCjL9+ujl+ZGfYoHmvd
59FrvIXVZMel5kyZqHEsyMoL2lKxhVLSFCxmRcpznFmXAGjP5bAeq+IOxlYXPo1fNIpGk7X5vMkf
gGb+/7Uqs3EPO7KaqxcbDDGTUpVOq19xCqIVT++LhbdZv5w7szwhByC/8XBS52Q7K18TLrTNY5yO
gDm63U5vFW0mDODbzb8AtstVCm9V08mFPSVUudnm3fV/gdurqECCR5rmYlvW00knDDSzlNyk51hF
Y900/x/apFJXZPdmcSLntI4Z8TJD825vsi15gocW0C80PtwF1MstRjfvGgmVPZZxHgk0EaZXebFZ
pf47VzYGtjp+B7H0OkJ3BUy6h9CeJdmG0sTjA40f6RWfz/M1U7vr9FTgFQzmq8Ewq5GFUbnX+brQ
mBtJDgdc3lGFLdDA3+NHPxX6D5EN41R4PIN3/5S3D3N3QDQoNNYjXsejoVi8fDOCWAFF6LfbTLNK
7/y2IsJwq8Q+3b+dKAVRCw0jFKlr9VzpSxV4wLk+TGbBYMWatPvxe0W/FOL5F8Ce1hVSkq1RQBs8
ZFmLagjU+c5M9+evwlbOw6t6rK4svvvEgLZTH5qCD36+2lxc0g+Cpa4DzRdfB8AXQIfROT5ZLWh+
bNiqLUv57dQ3/kmy2eWYMr59yrq7JFvW7rfPJc/7GT8R8b6yt0De78LunuBWnzQOOytwDZ+NXCOk
htXvHn5n+c4VhgWpcLk4iWRugrU/I3M5yzJaGzbcrOsSrOSEpjCFSw/WHIX3Uo1Guy23wSqHFDrt
XR1lGfZyLhvNfQg/Hf68RPn4nVXu6issKPa2pXkLlFjlquUd3EBg//V2udxseHrd2b+veJJ6pxFe
uC/1XLWUL7DFAXv0Mv5txISXlth91+3QaLtlyrDjqOiautPZvv4R/Oxp+bqSB7KDh00jqsSSCfeU
Q/NRVfVYRdXoNM+WvxUcc4FOKgSEQWMUx9lOKA9pj1F77A5b90a600dQtLJDESDxxbjAAtVaFmod
kzQDERlk26dRAK/LnsmeVh4X0+n9r6nN3XmltvQRB22ih01O7I/VHY8XiP8RzD2toywqyqfcPtdz
PbI0TfS8GufTKcP2przhEBd76Ao7qDxUjo2SDnjy+hVmhoOblmQs12IBhN9DJL6wi+5TjqfgrXzc
BTCtqayryRybWUDdqKqBipg7dcVjycaOvepoAQddXRNRNH4L8sNFCQuTk+Ry629EZ+SeKmJPNfUg
JUQnCPKow+n95WQKz/dYFM8T9nmj5Uvz2WYSNilupuKEKkj2H45y9//UGW0IAtAMxLyx/6L3/YAY
7L0Wo/k8Vr3U+5HwmtUJk+/tDJ3Oas8q4XTZLQF/wiLF4crSvvFP5pWIXarHw2r7g1WJ9gcGnwNk
ezy2bgn3daMyjROJp2H3tDDCAJsMvP5oXDE1kPPIU5iV+sxVZfWZs4vMRN9nuHS9wRz66vTfSt04
Y8waNHhPs13iLd+NSbQOITYqJ0j0Efv3sB8WPT18GvdbrSvoA1mTv2XobvUhey22hM/Nx73m+w/6
636l4vy9a21i9G402+8Tu0abBO+9AwTzbeuWvalRfZYuMFISDrA9/GrIHLft/GuGhby87/KKoNQn
TE1+e1oLRWzdrnX2np8oElx5mZzVlaPW3rYdirSGb3pQcbdXBx/0U6ZpT5of6zLX8bsbuiThnPSS
Fb96u+4TpWf+4kIGELpqVAsNSpPPU7Z+AaSXNdS+AD9xtk/+KjsROBJ4lf1zoPfjY2S/OCem1o4d
nlbO1M0hJzx0PTXwIL41sv5+SSybCyRlMmU87bz6xCsNEtSQeu7Hnhz+OJDW9voCWEHSuBOcqI9x
Ggmt8xIdBHzALSGpt5PnyU/PtYP9LcCrsB/FcajLGS0LPBNDF6hOJQ+vCNFc0jpRKeuTQesEVvse
KEKZp8rYnIxaDEzW7OL8pqmboMvTHOf8OhkxfGvaPVpEe7iDx5GF/InEokSpjTj2BToJq6YLUlqa
4iwRJuu1skuyFPUfOCnKsnI/56NklGgg9kp0jLDJooykQHvOP+cvpyDr50eyp2TIy+EqtfDQsGKa
hdOlVKIhIOs4+YAQdCKAql/JOu+NtA+cc6Ujb74Vk8QiZv0PhHvtq84dII2f0YkaIWZ8rFTZB1nN
5IcdJkWUsbKQzHTJk9ikqFLkpufifyyWsEbo6EwdFgcdFrXEPWyMfeqNKsD4DNDf/hNTnEYjdFwA
ZSPScmYdNtozcURndpUROZKJZorfpWZrksm6BLDpU44kIaOVwT4uAXzjec11bS70ZHuNmY30+PY8
8xoMVjNFUXTyIRxhuVJWEEV5ILDPbCtpFo7LftS8ymjW3ya9rLVQ9mF3USuLC1b9k3sKGGCEPHmf
VOFQEqpgRNlLfJZnmkZO9KWsSghGN/+0EZ0xjq/yAeas6iKCPDnhiupurgR2/SIDYYhv6ESTEw8R
u95BPVtcKlF31zOGXaR29qyyR1hcsBhIzOt+nG8kbdSZoF6vzlj32TPR1twd9+BuQirCxHWRdkTc
uaWFW6Wpip41/jrwnecRKMvIt+dmKW6hzmPC/sfvLHXg2HmPIJIZnSxKSqA0hNX+PCdwvkjfuwZ0
SWrqznh0mWD5z3VxGfadvCNu4yPz1fLa43HEpvjUs9DTW7GVZ4ZnphQ/ll11pNXa3SeISmOjeowX
j/N7xCNcbGhqY701eYxD/6mWpoYmC482emK8iBf1qdKkPR3EET3Sw2aWPEu7jGzYlKfB9240L5c3
14IAHnuVPtZXqClnZLQpWYz/SC2Dc+cXoAP+U41iSNGvUt7TtcfEDCyxJbWDf/Zbm03G7S4UxX4X
1jZsBMvJeb7tIfRvJ0LCF2BTMIBuI14+iwJGaw3iAAe3vM6pg+8feJrA9lz/NgO55QQ3MTOj1kmQ
tzagn3sSebqsZqKw2Ci7nm1rrcreWKDhSi01MSA6qfj2VDseshgHw5733VV8Q2a7cO5kp3+PwMMl
0y75NFiL7/x62SxO+S3ZdaaM21W7VVNlpD9Jk0E4AjPx3/LvdNUJl4tpP62Dz2a2imipR6qWMHmT
PRI6ctMn+TGnHonLdlzO/JIXln++ym1ahWlS15RoV+rCTPevmt+e3j5CvOftRli7Ht7PcJsJKgYH
CSbju8Yy1x9/OMuC1ws1BKEG2U+fwbWFLsvOpLqoHX1of/l2fLJWVty6BU7TRRkLNO7mRTTxJt2H
vX9xN/WNSG0mdmCg0Fku1+WgLbSP9b90qnXEPqCoWWYM2U0UQMSPCjzWXvd5Sr5x6wbD/SWNKcox
j5whfhwqEujMVF5l3qIrCXwkL+UDX9lyMyI2Yq444r0uVqKMtSJ35hrQHEXgyY9OEf+tYx77AliC
O/1kJuAFLKFdRPJkOYQ71zNW0Rfmux7rHH5fC+oPtU+/v689TsllPT4kMwBdLvncElrp/y0c1xOP
U4eBqO5hn9xMvXK9ZiZbO141CMEW0SW6WmnN989psLF/YfzEnU73gEoHnJN53R8+8wEDov7VIPlR
A+/3JkWwZH1cvNgCx9t6t6Ff7zhCeiyuKdRC1PG7KFcmbfiFxhEMrF0wrgHPlHrL8nXNljRZaqvs
88xzeOFTFabcfXti/zjvU6XDrnPuFwD/wk3XqvRmupBplNJBlcKy9bcbTy2/h9ewrbat5rKHi84v
Z6R8L9Na6+FVZD+UdUVf7V8tJ8/xNJC2KR4R8VfIbXBbB8uSEcZBBI2J69lGsBvTos+qpy+LHllT
m1GNkszfWu3NNQnCf2Ofqzs+IuZKmDIO5Zm6Tc/yvAsPVI5rWdXmSi53fmgP9WDOQzGxDDlAFTzX
CW6e0Ht3KfoyJq2xxE8YBFuS35bkBfEHQH8BzIeA2E3VCrPC4BLzDxjbmWaaJm++0bF7ElySS+Il
pkTgTIksRX0Vxpla2GmwkngFm95HuZXFhq716YxNvlW6KMfIqp5g6cyEtq41LJFI7cgJuZcBr1r3
4EfBVZLoGGytUOq4ZCWbXnNfHNuoAPoIqk2z+x5/dbSxbSPPHnTLIi50Vp0VsJ7StKTbq+zGDaGh
xHJa4A8s1L/4ZVANOjTx99iSO0/vgA6DZELL49cVwi3q3Ie58o+s9UlCh/UZ4eWS5lvB4Rqc8YNR
0ma7geN/NrzzJ+xtzR1NDS3LFh3NGvFvauQjUazBI7Yamxd1lzXEuL+4Yr+dwv8pldiwXPRZSROO
ZKZuaQttnOTYtk4ACN0IdTurrv0b+JyGDpS5FHdig91McKErViHnumKo6d3F0eM66QV9erPemwrC
+vztmHWzYtg6LG9XjQGPhk7mO3kPW8ajy6TRmjfIWQvnPvJOw1UydWkTbe1TpnyL8YXR2uUZUXOD
ieQYrpzipuwp6+ymG4F/J2HOUCe4pI9knTnW+67xblsQbJiGzPwm8GNVT+jzBUvCWTfwBHIa7rdm
uTj+iEjjpDkWzMCrZ428xdVwWWurpjTT/HVSZSh871XWhCGuxRP4UyrZD0SsBN72MsXjjAMnjQc8
DeS85Bkr+dxn9XghE63EMg9HmkW5B7BhazMOyfw8QM0uJpy34ru4P+ErGaFR06HsGI1I/xfQBXcl
1Fbrcz9crHQv1+Hebp08eS89rgQDRdt3gFBd5hXodsn2OW4cJd5+Tc7C+zjC+37mVyLaRK6ao7fR
1YbYdoy4cFP1M590EnMhLy8lNdvTDFCuKs73B0s1lEXtjxJUWomOSVSqOAtxMxsjK04poRJ0sVVB
x6saxYKnCozUjByzfDFMbgjTvmyWnOrAQn2k8bkOK9NtVKkjptSumoutzbZUR9KW9s8E8vNrTdwT
sUTJi9O8ouzDgW4tlWYQcHU+wHIiIGR2Vo97nVk5y1ZP90HrVqU2l/QT80Utf43tC+D5UD5BFjzN
z6jpG3yqI18mxRdV+/TNZy81zAIUq8zebOCl7rvkqYaVgY2XVWy3lNxS6ALKQEOzHs+ZlZrihaPK
8aSSAEbjL7qs08XlowmXWk+CqOjdG9JV87velpKddVrzfy/Ljx81ZDbS4bOLltRkTHAoi1vYkBZz
gMAA2km5YcFvatBPnKD3ADpwpC2mwtt2qpsSk20tAa6s835UKoAjlFY5XFT+z+gfbpnYH/3VtlKw
U1ImkvDVyrq13iUxUZm4FhnNdHq6SNyzy/FB+xFa5453LwOE4h8XX4Am7ef7kJ+wPoNBT7a0ngPD
iif+RcXZKkWxsT+2y0rIW5G0eq8l33iPPZs9wO1qkZoKq8YbZQH0nz5mlp77Bt7W1VuiAk0Sb2aZ
Mu2jSj57oIdNiSPcA60SAjNhnp2DT8GzZLwTnaF1o9a7923eAj17atznapzvkbYlAw6YXtYeOU/8
HSukXwB4lPIGURqP2IILvNFSNXuTy4I7HcUErh1BFOsT9akAYgAzqdv+s43k4bDmUiLJYIcaMJ7j
2LOWnlxlqbyXFbTxYoPl902zfbGsS01yZBFXnejbdyieMIq9zhmEtRIfen0zcd5sgoa2S5h2XGjb
SYRlRYyPpLE1kT+kvBR3roqymIvzt/IhXK6DHF4bt9XsppXnWUu3HIU1DPm4zHa9mZBt65sW+lJk
4+/wID8630uXvTu4H0aFP0SKFy+vJUU3iYgTzJIHO4JaxCTY/7gOm6ydtjRZJ21Pte3tW4uq17xL
O5s7CpBCMZwHiVuCvYL2xilCyMYJwylR5RalU2In4+HWuQqhfdfIfBUFKgg/Npf+2qCfZhjbJTME
tuw2DtbSPfQwLeYdMmnFjuVpERoV7sM0OTwGCAp7Qiu1fBymt0+LS3YIKoQJfytZZk93xv7Ltfcz
5GY9/NZ3oQvK0tzpNSOL5SrNjvcEttlMet+2sC0lpivxxaXVA3dYae63mFAyxTUuEvWLtuIzu6SA
L06sPftgC3irQbDG0kwGyC3gNkMiw2mIbD37Uwd8qGOWImHfCqmgwK5OdiuQYENiF4YV/2yOB3sL
da68bXs7AREF5jm4504bpYj3qS7MDYsvGC095TtMRrP0NU84hv5BLsCtc8+tRPSy7wzZMfNPvmSo
xkjDuhBdSnpEBLdWQQI5CdBv4nz6BTircIkgMCCZTdbyfp4wlSK/x73ckHogYZt9Fcr1ZEDX1mMb
Z8iGSxPyL6B1nKg6AT908I9NRO2pr57p4pHo4ad2/UqYQlpOS1gHOfbytx4cr9jM63UGdn8B4Nzb
3txoea0vTLa+AMwTUnic3/JDhFasrd0swa0ophASUo43JcRc+iuqjA3sW5KHY+s9yokxC3bvJox2
QEbizRydaXOkcrwZnr18TqGBJnJFJO51B3sDc8WmP1rPRgEdglZCeNoOl0DG2l+xdGn8YQs4fAcq
sns8DpzwdUgKQSIFdK308a4q3FEFUZ9bV3BwVqLQrVtGkryjWC+FRg1Yn+hWO+2ZTL+C1lrGA2Pw
Z2cvdpMHsmpi8UGJY5CshIGX6vnDOCPLTzTF5ratW8PxeOcxaj6aET9A8452xFSMTi6E6IGqbgND
fJ6hB4v2QsvmahLJJh+2zJoLCqlu9pM1GYAr1cQphzXb5ZtT2/JpCnDjd2T0/uPl+mbdCKZaxD5C
KgDBtPSoT/mkcVEpCPLMau+0+89+HVVH9jXUjDnS9fGQHE1dff2GmOujgCazKZvupjj5x5KRgmCs
Wx7lSsESlba9XORb6U82STrWXzr1wYNgo7wZldREClbmW2JVohGbuPyCqcqSRgmnhjy/qi9A2OOk
INfAJ0GKR9KOsRQeSSw+TrdtGXhbjOt6u3K9Ffjr0jn18Kb0QlPaBmbv9qUwXD6vrGixS9C5TFdc
IAZhMreNOHVJbC+j1hEbuM8g3NQVnBxD6DvvNeEVF19SdrB50GCEi9H+WH51F3E/68XZabsbfR4B
PECJYupdLHYPGKiXcOIZozhO1AeWR7jddDA0gqqpsjo9UGLjdt7mpQX7HMO7eAl6GijBDrYUL8Ww
EBnuJHKavBXRlplZ39aJnWDLm91xeiiayA28zcz4ohJxlcdeE180cQzxiI/KNxVNOtBTwYPOENIj
tpWLDwSIAahrW4NpaRKD3JVTLmvIf7zxYLPOa5sZufYH67XhMy0iny9HiXygdColhpLkd4UbTpWk
WhRdOQfC7kX7RCTNz/V8i2MnJDZrJOCOo66NbsWjx8s35SmiGApXTYhIoAifjrfaLlXO8K7KskhD
Etf+PFE12XwniiWBs8Z5BX4B1sr012IjhL4AMk11Jx5gfRD6JeTDWP9igKuAmgHaEuPDlNglWwvk
SB+qimSdTNMekcmKWhi1XvY2a3S7cH9+SgDdHEfwz7TS0mh7dsXsCfoj17Y8glN9AQPshUPQQvZY
ovxwtdwzfxgZHftCZU2urXJz5xxolTyFI20nTM6FXdfJK1kubnncYPfW3uyWQ4Qkc2wnbkNtZhwm
PFuvQrsEqsA0frqo+mbU1tWZNU8MY3dNy5N3NwC/SAQ6cIEzd2g25UyEdrWMHqH5R1lFeeBPtKIy
nRiETJwMTGqOLwCd2BzuB0QlqRKyg8455BZnjESx1YgTb3FqYAjDFUkg5hdgmwo4vHspY9jp8AWI
GLbj6vKpwHtFkLxFXiOh3z9x1ig+IIPrwqvm2TCJleyKfu9YiviN7jP1th4tpdljNukPVari53Cb
nZlPch3weAa7aBmwT31LVbUlarJ5HPY5+Hy1Y/GgYIMLOlfcb3+HXCQoSa7GfKwsCoy3waCSW2zS
p1tb+pOmScTvn9rBeRAHFsUuMz0ZynuMLj1NGmdrkOh74lxhisdYlSWwV/kCcAuol9WYW7rG2MtL
UxoZ2HRl1XTjcGKXvaqMSDF0+UYFPvwL6Am+rTTHK1fpvBB5Zfz5mvpf1Uwrv8OufNJVf1ug5Cxc
GH1v1QEMpd1dvo4tKW+ZLq0uHySuoSQBlbMvBouD/6k1ZCoYFNgv+UuTXk5peCrKpH1TQWYNrFwb
Lf01TfttTKr8R38xx78Xjv12Ns6HJ+EJ0BGeTKFR8Yv6yzRGh8aIvoL/yftIo4PilM6Kodey/IzO
SGEVvQo+LbLJiEppCVZZwYZ1SWlJJaC8sEw1qZYgmdxUHs9xooMHBnzkdsrVI5Q6W9OGvYYcQ9ku
EK8e0q+TzfAo106VEhYbcXBP5/XdFX8kzEJMY697dY2sBNky2miKAoAhfRpV85riAABkRWztKkDg
PReYy74gSg3WU4EEqEsGq/T/Whzxe+n87N0SDDWTe4vkqX6Faf5IFIjRpGXzdjyPVxYfibyotf+x
qDcDibuRog4VMgMI1Feer3mQ9Uwt1p5aRvpR99r1zDkONjgdr+QcagAlIDVS+202Xeom/CujB+Xx
L1qKfRZbHQp+U/GBWJG1tLYuF3VhLDK3amJS5CVvVp1/sOdXWjjITJGYooUbenjAlnFEs/ZsWZ7l
N6j6meEOda0utkfA43Zas4dhNkHMHsQCa3otBYT16pVpXcCBwHgUbfsCeL0u6eayYZboGIx0st/V
P5Z5BeuGq4UtqXqc7CO8PGITTbdjWjut/oKHHzc9VywAsTmPA6uJ6L7fLE3NEZTK1iAtw2a5Zq3O
N7ddFvrqhlg2pYno0R4LNUtXw526MaOsjluWCTQcHt1vrjf5+Ku7/bOUUWxhdRbIk+2o9d9R8vkC
hBqvew0sgz/BFNL+g5ATUahb0DGWnIqyt5Rd3z2naH/LO9yGjWr4aIrT47NapfGF2LpiALuBre+/
kQ6zifN1Dur2mrt7ae1u1/qP7DWTy4RHOnh+i1lbJa7rwlhRjIIRURQJH2t9VX1RWw+VwbM89iUu
Ei4ir2otGmGC72RbKlHrfZ8MB/iVWZ0VAmxyIxARX4AQH4Ri7cAN3ZMs9n6kN6SnMhazFDRLyVHh
TsId/D4+qI1I6mZJX2dacYdw3h0SH/D8IzLkiK63yp64Ir39cCc90VSck496Ngm69bmjs20+Jf6F
XAjSoZgZEgIJrdThwSzTfpuufba5Q4QiVZojsg26xHwjUYXT6Fv5Vkc7p6285LCPWz2riRa9v7rv
UFYIjgYYmOlinnfynzxopAWfFEcrItqo0NDj54weIeWY+0kCRWHDHWuVN5XIqu0nfxe0FiX3c57K
u+NkOhZtyvVBL6zpCjjsl7rWAde2raNtKNDYtl4Kszscpuj7Hf4cbA+ujDs/OTKA2jZbF31Vtrxc
XsfJvMkG2vsFjAgfqDolVkDPt9ilM1nQrLoh3qh0ug70KSuc3uVtWbhXYuuZeClI+3muUyqHiOnu
wjAERFTgR0uC0m/ZRwRO/AgjrXPuBIE9NGZW4wNtbzV+kef64tPA8jMf5BxmJzJfM7+54zSeS42C
lcLPsfrWlt4gsBTqXwoiwdtz6bsnZO2RwZJNaY+WHtXrsY22A6T7fJn5W4tgnFDGLmf3JE7TaW+y
FlCuwxrl0vvpvvUhSUfb+p/9HmSl29pK64qPKC1CVjU146ti6E83bgI7eqFjkth2Bv6lk4fzSpP7
pO+0MVdQrUDl6ZsvAJeQceD2TZ1a0/KDV4EXWRo64mkQGwFBSL+/3aurNE3MzgMRm73GLanW2oIT
Sp+TUFnZ4oNm2NMTeE3HsPGgDYoC4lyfK7xiDazFgDZJqFpW3qOa8z3as24+aV+/tfUWpeDENAlx
rKsl0dfMJHwCabe4Mc+MbZSAjXZQSEjJD9Gt0lCxM0qYc9dc8dpo/752nvdBn2r7TXj6O7reBkU6
Moka3jTqfN2557KlZDco8nKdVAcJPeGP2+ts0hX5DOmCQ9kggwqLY+cfp21Fw4FEOwczCgamdQUU
CB6hsG5EyUWO2zIreIoGhsSJTwupMeJHpNZlFbANy7osgsLKUHFQdYLflJBUT4XVHsb863e4iNt2
QhpoVhIFUKvTNvTUxNj3Mj1CTcuCLUnbKu51pp0sxYaE2LsEggWhZpRin9pl1q3uujXwMVOFp9Dm
pjSWi2TbAyvjb5Z7qxX8SJcyHADVPDfUhkX7IfIRs5PrCH/UI5GkarM9vVprnNWfCRBcSUAVVGtv
s3dUbt3DUaQEnKKprthsybLAseedUav+PM/ljEy1ZxmImxmaYqq1UMFF0Ku2fGCFdXD3ww3PJE4y
/tnmoqDhCTZZrQvTHckn9lzvgsHu4O454bs3oXvNZgckr7c90w/yqdjimf8durFIk5WN2MfATqD9
YWk9KvSvFnzn2OIXRnDriN2bP5MetO664nSq+ejRiI99gI4bGbeD22PcaYQtA18dGscmjGogXcZV
GHxYeRo89ljTD11bUMVKXEAy0enH91gnQPdE65Io04pHmgF1+IrQWviRyHEOt1nwl3stIal9RFFv
tqgz5v7fZTmDEvkVkSbhp761WZBXBn1xNbeIWpBtzzxywS1X2dVNxl8GU14CT9cYNXyPOke/GpH0
hgHywG3kwBlqPI4NTWdCWbDeT+wSDXWHA0LUulLqNSat74hU/e+6uo7HMZque4ISR7a+GUnzayb3
fzQ3SvYFTIkXP5Jkyy2flcZahjBK/f/uoACIPE0fK1YlIbDYxmSKQCFICQV5gl6XyoRHoIfVLW0H
j62P8MkWCyYezNf+f8vOZ/4gEPYQ1itNgVioFDKLal/Zn0SbIZMCUQ1TrCHdUBdxuwEGSOTztGtt
dEYFUlO1b0/2vIqvXYsWe6MgOv9m+V2bmPVmCFexS5zugv+Kf1+vB9x/FKrwsPlHzFHu0JqfltwL
GHa+Mx/pNO0aLk1qMN9nz87kJdTHIxQ13SpV0ZR+MyuIwyCq+OSb6b+wuXKQSebE/Sh2s7ZO90tj
SEvfzo24WXZ74TGbrsImor9F1aQlz1UA33a2RgvRD07p5mj/G/zlg4wysKGPqU77ha3V2VPv/bVS
T7MDny6CiPG43eByVRfjtS7b2dhxBJa6tGPKF2CSs9LIHMSo1IjfzTjruAt1qk7saCMFh4f8S6XM
ml2ZffYCymMhAc26x1yIPK2ILG1kOv8Tu9RJSKbcqJgkVbvdBKeDD89QFfJ/lIVJ9wgoG99lS7V/
rYFp0fCDI0VZG6kMGSsorWCRFhkmW+5b+f/O5qFyFLexq/RLvC8feWEHmqz6bOrdZp2FjTA7E1n/
gVBtvFVf3VlC2B9hVxg4KtiU7iltSO8RoQ0TVe8asB7kGKII5+RKL5Wv1mfsEvS2EIriywocoXfs
B8f2ZFe+JOfQj8wdz7bKIJA2zds7cDI3RCc03EEDN/+cvtzqahAT0DHlHb5HAF+kcZ1J8V40z4dN
xUq7p4FP4pmYR8xHx1BWgrag7s7WlQJ8+65YAi1q/mnoN5FvvYPnakDjVTsh/BYt0tzaqNIt59Ad
P3m15ptsQ8bFBLm6g3aAaVptiPegxALQ+E62RX0y9QXGZ0mWdjq+3LAiU+AwmRz22o/Wb7BhypaY
JFkmCM/c7qV3ME7zzKbTqtRu+Y4bQ8KLIgD+gXP238g/Q+s0NgeVi14WolhV2Yya39xEXX977Gq1
1Vycr08VCy5cSqLEOfEc5KkUbYLwyO+sRZ6qbmVblLsIPbFrHYHaLGkZwtf4MMqkIpWXbpO5xi0j
XKFnFyKiF7oFVbWK/rzXw+55BHlgZhSbAb+aPccOKQ3eK/6set7qXBhf2wz7knPagY67cqHwwne6
x+ugWvvizJBx0lAxtsA4uNpopTxa+98covFeOQ6AmKrjf93C+MB9IhstJsrWyPRJdxK2/aN3SR2D
aeZK6Zyy5N1xdy8HC2nTGN279cCjovrZK8eu5Z8YuHHEGm9FHQEwkHbuU6tKs7GdbcgPpXMl2hz6
soo/oY926g2EjATZtSdo3RkJH4djXpEa9CSdscKrGo32X5f4u3/6vvwez/7r4u3ok6+0UAskl2YS
0v/47iH1GnOrXfln5+0LoCOd4tERHy6g7M3ZnXP9VPpLJDb4UCQcj6A7HFvCENLGWXdKSHmZFsFY
lCJhdUfTssYrzlffZGCArQ6pUTdpEDmw2TWNEKEJeDZvzcXtss7i+b3RedD8d9cxVLN+Ud+97BcA
edu60mFhTxiUQ3oc8wXwKVgSYPcua24cu514xgWTC2+d6odHc8JzCpJI5P3Ms5VPKoj5FCslpjTG
KS9s0K/AwFDEvRxtKB8nQBhl/QLA6e9Y/Jw8onP8z0fTs+SpdRC3yk24UUsIQHi8W++SDuCCiKzR
FvsCoG6e8FueGshXYGtv2+Q/1gg6z/hE/2KaGPxLAbEVifHLqJZFUebsnbJ09PfKdwyeNRsoby3o
8X/4p3UPfnSOaKfxIXG0xSq3OXQwUP+a5rND7PDz9A87gv7WwNai0IlP8xyf6tc2tm6Z/w0wiax5
fo9TVoVTxBVUJII71+nIcbRhKFwAvXmb+LIYIqDoMfNnW68/2qkoiRPbdYYDpULHvwCY8cf6V9GW
5va7z91561O515m/m0Uugnn6iVPVY2OyVjI40hAP3mdbNoJgt0cVf7tXHUQQWmj5zHuHt3OCbTUU
VIZ7JmLiuUTF79bShc8Itpu1l2pCwGb3OmsSgSJiBEwUrfsVAXvvdIRozTzCLHM5C0LdttVzD2/6
qr/ScJVRihqD4N+GBSHOldhTkWS/4W14EbpXp6dx43z7deBgjgTgbyMXrC67/VabXy5ZpjOKnw0y
exONcaQ4TvA4LpXdO6fZXQLdYIWkGr/ItKA45/h8Yut1YFq6RjBTTf3j93P94Fu8XdOfhM81peI8
+wj1zCOLl5jPOxo7LfjeqpLkwws4wLdImKIOKtcq0Kb8bvQNikHyuWElypppX+AL8Jcsi2jwdztM
pz2BeHO+VEuelOfUB6herm0Sesb59FqGA678lqks8RvOE50ZWLOO6PvKTfkEeSzbmARR9i0VcNLc
3RJyo809zgA7XgL4BSA4TVuONuWsJ59qmYwxPao2IFfZwpr91IB22JCnRnTHtyQlypkfphxATRR6
eagQGJnmJnk760TGGba4aWlg2vxbw5UAL1xuY4iqs8aZNtMAT0n94Vponv2R88SRKszalKiZXBug
o3Q1tZI/0jFJRGTR1Z0ywGgCGvnXcpD/LM4/BHavzQauvsD16EVjsggE51hyfPzH07Lbwq7WrTK1
2SAImsaEUvzyDvqfYkjo+T0P9j1L3b8A6Op5dzhaP0cPSe8BfcLMh2q7oM1dEp7KmXUtB7wR1hc1
UKhp4rf4W2fp+JHOc33icdLZ7xcDii0x0wd+MzdlulYt3zh3MKNhJ97uwXG/yENLITtIsK3nrJ9Z
an6hU8AdE0VCRfUNM4ZA5n3jUAvKwBihWzQpkGlGq5ISXzcfB0YYx9RxZtplcgIJoet0PNDJtPs+
9BCIByDmxQt02D3LmrNRHi6+aTMqEcNxoq71VYdthvtYJgxk/bTTVUcYvKmTmZfiStyf79qj+LFS
cCInX6SaNuTOacut3iqbgQePJ8iuox64x1PqxT0ik/og1Jy1UeaqalUjKMyqZjaXX191N+mZ37N/
y6lfy7TyqSN8ZNP/XbjBXLAKj0Ma1qbkOT3/fml0Xzn7bfvl4iGwURrUqrD005bLoJl+azOvEVOd
oiPjkbekL/Lydqu6S51++qgaBJQSw2NVblzInPo1bQ3Ipr2N4RTvWkzk0kKoiJL4zPv3Qbe5gJyq
MMHekuvehrBemLQx0vY2pa2anwU6FsiayP9fr64ImVfJsrdQ1oiiqeAgEGekBGBVL2criE3xXFEZ
NpJ065xoNrs+xd4vb9gn0FcR4EmBtj0qJpeBlpyEiUG0nQjDDvI/zjXQRWAKyI8qaVGVVQOVi5Zi
e5ms0DVMlZiOnL7zx8u5v9NZV9v2paU9+3x0KLZaSWs5nHYxT0ozSlhQpt5tMBib32e6fM99UzyP
mm0I+jcxji97hNrdyv+HyDUqae/palvXO9kzKylVNM4JhSvwVL/rjJFju1m3qKzcmeRVp3BjDuZg
V9wau8CdBQiSVxFHIUu3JYTqBOTPADXyZXqZf6BPyBkG1E0+1s7Pq/0nfP03j6yDa8IJpJF7BYfx
sderbFT16Hu+JwxW7aWPVRP7Olt7Y8lSRJwTONX44JdTNk8UJKa+t5yMXuUX1onc/m65t0rD+NWp
1vDDtHzltkafNW1/QHPEzv/s/Fm890lH0SSpfewo3dlAlPxUjbJ9kNBnAXltWOY/MWaWn0+R87pU
4npmS0l1jwvpcb+ysNUsNGh9GORu1WrKL949epjF1BkcSb/vSP1Y5Xu43cJ2LBjOKdcwTrC6z8O7
sw/uNIQA68oTfWy0bUMHdFoQpCrWCtoUO+xWTnGk+6YJCN336RGN3pRvaBkWOWbhqfnUc27YprF0
8cEUZCNOCfgbK8Qmwb+Pc5oOd5SW5Tjad7V6tkXYwV6VtwmB+NmK4vmamhbruD8SqRMk2N7YQ4nL
s+xoveZTYs2secf0juPaa3v7XFqTgWTBXwDitf26XQ0BfkLZQlt2Y/n/pLTwb+ZWn6nRvyXOmrI+
bW8yE8WtmfkLnGqY60CrM80Vz6hIGpPE5OY4W6ZSRhmO+Rkdx1yjLgHUbLvMp6N4ao0UPjYDLtRp
lgOkxw3hkc5e5PP01g6cdlf2PS+VH9mSm0oos7D1lQKcFd1X2cDNjYZ4hHYwmyhsEuCxr7rxhHx6
yOePe7RZaTg9HnJbQEf5q9oKtZoZiZX0U50Y1QXUFwCytmdGo2WxS7U0AvYVtDpUy21P2AA0xIJT
leiCz+zdM/Lk4o1fJZH5na4bOsPKF3tC4L/AtJWx5aOuen987bqcT7bzpqlYdIqvvxnocs24Kszx
I5Q/YHWazZrGO3B6za+R29T+6GqUjEV6tA2raVtfZvBv4iSzXHKifl0wsEjf5ZUTqYEx+r1uEIX/
bZGvN4QcZsKWi8nhyPxuxsHKydg1KVm9K5VLcDB1hOs4jk6KuZnBhJaaVPLmisdwsNktqy54p2Xe
rDNO7GiQJnblx25k/z4RfcCgEHHLvMaB3GF5vpw3V34Hdrjd8zACahuV96IP8LLemHC6ME4K7/xc
OcB6E+/3teD7zDWGqz4DPnLivKFKuzfXy6cKGVHbMdDwv7RgWt3eXC+pUXe75pU6k2Vyfqx08pvg
OW2OldhV19kdE2v3fitfVC1ZfqQlZ22eTBGUrHzkbNvCYDlNf/Y03/XCpaPaKnhdoetDechKgig5
OFiKtj29yJGGjiWIi6Er12Gx+aWd9LSn3fWUGpM5fe2Ttq/R02UF9t7SiCbWdqiOlylt7kY91NSU
6zRHPmhB9add/bl1lu65Q5CpowIDYbqqyvAoO4ltHuRNrnFWNQqTZZ9hhubCF6MmgUFrw3bZ0upn
R4H+d0dqPXvjdWF/+RE64y8Tgbd+yWu8mPaW2CPu6HL6JJ3Uw8Opuse381yVs1t1y4SxKpeCp5lS
vn2trvYWWW1zRgS/xX3ICpPYsnJlnEv37HUaipYolQbZ5/TlXMdaQx3qdKRSTd7R3ooqf2Xy1kOp
Bp9Pdev6hkLizgrHxPejzR+D+deoPuYjhYKT5DKHUX7zvuqCbeVG8ybMeuff0yMwvHXElQCws27l
TA2+T4YNkVKtsEKGuFOWezkQJTBDfB8PrAwmJj+d2kc0T9X3l2qLMKvGnJ1cqd/UZa3JUtHqp4WF
hGVMGPQ3J72OpHVdiR8NsfbairH+iNCei2AdYs0xZLFqkmJrsGoaES4VcFxqtPyIzdDQrzjQtC7S
luTewqtuDjFncKCxKhGsbv6caia5+6uqkO0QEFQOFse4cgIixhUV/ohb2uyJd9iMqHm7RMHdZ2rf
q1RgW9XJKSBcTq1tdrboVMW9QNZMQi5L5Hi54vY25ZdQrK8+pDr66OmliELccYGAarFa5hSmsSdh
YztYVvPR3+wysC0zFbz/lBcskwaGMMC4Dnq+qhwgZrqccR28z6khe5p9qIdacUXNx44H/4uqpgrm
+wJAVFoVNfD5BhALFRUk8ZM/W+j87hAY/KdT+b+tApVFfWxWO0QUqg9VGDXuHGkOec0Kak42Wugd
jCInoGNUJRYbEaSgQjOso01lVk4ytFI+ykGEiIbKQl5jdRzaC0etMZH3ypVaVoUmddZ4nbAHI40Z
U4pm1vL/GmLO+1KpsM9kNtB1bA39KDtLRyYwtRKZkbSSCyNhfh5fDCNVkSOlKESMSbdnGeh1pYkd
kqNe4k//C0xarKcf5aoPSc/ASXDWPmz6Sy9GFbrYwybtlXvJNZy28ikUMmdlstWBnvpvsTuTUYN9
6Xi5rv6kNd0kJpa7ALra83JdOGi35sxj2byFIfaeuyhOXmWRQeu/pAzy6Iy6ubgvGiGw6r+8R3m0
WB/+Xq836VaDOJ67BqgTrLfmNLU0Bdq/sfllgRUZi78AeYGKDFvHQDfpYuu025auMYqFQxWy5v6+
hLjPJRmm9caYw9vlUnxJNCnIkfVFDsCdok7VJ8Pi9iVeJuRGQA0AIr+81B1sH5s7Ex56AmrCYDhI
S0AxJRlU9nIYlFy2WDzMA/PsqUGIvFUoahCn6E6lJY7qe4XdXS0x6gVj+QFIlitngJuCHeBrRIz/
am6M5fm5/kqkAH+5dQehCjjEZD5Him/nqUaQXLZ56UF3xWpA0XYs0af+mZNNxwEWa5QqQ553BDde
TDlruIAoy4kTP2gUKlkzXaabvnMs3bF2IYqhr5YAu7zs3FPnN/t63w5lH/g85vj2Ujse76faje+b
puHNm3xL76KcJjp8eNoQ1Cinc7DfL+X/XmTSybouuF6VKCdw1hPaJyte6xbrdVwjFQtbv91QVHeL
vLkJRDW2PowUy8U9IjqQPJt4qR088F3BzKwvREJPTnFM+pmzvHHBie6kh7Rt7tenTOV9uq0D4U6U
eV63qzlFHTFcNv9sTOVMs5sQ3s1w6VF6xaRANX0fysKJ8+oyV/Zu+6N0rXj7JhYew0eli26lVHXF
OXNFCDKWcxUSIJioQfvnzxL0RTTJHVd9yufQK0azlshMV5efI7445L1CIOmd9TbSPJWJEdTHCL6K
R06BunZxe+qhVj49bqWiYsTE8M2HSrf/5JfeaaVLIoW5AwyRbqKuP/pNW5ZG1ivNe/uPhAHgUgRs
fnm3+aqXxrFa1sH6ZRyuGc1f7/7xHdUnF8RMH38gV75PeiLdS4Q0ID49b6nSe2/z59XW0eYydtTh
c5t6/0xDxfVvVm9rd+SOeN7Dl2QLFs0VcGvzJQJ4cnAZg40ZDJWaEpznR3vXU6PJo2EkQW+ouFLa
GIvNuOvIcDPs9AXI9xklR81bOjHAma+pBUmXpYHBkt9FHC3617eh55UuRlw98ijbQb1Z/yRCj8Tw
DPrlFalj6jIZF+kqg8TI8uts0tXnaw6XdMBDnyc/LMCIlzzHZTaxX4CwOoYrxsvb9lrWwwQe3sLK
IIr2W/fNIVXxgwJMwvZHoWY6r+UPaMr9KIk4ZhpeXEo+oyXbOoRtsBjDDBlWxG5Lzvv25gxQF3Qj
VOgJrcJF7q3U5dyqAturYH03xvGj9ZZd0p6yK+2UQ545Cz0OssV1dF9BEd9QvMKvGdrqdwNJekzt
LMs3ow1daYeL2PjUqDzfyv4PW8nBZxyuBRnHH5hhSuiKFlP0iu2aHO7C+Ns2abH2dMMN6xSBM/tn
9GmJrcmxxaf6X4Bo03m70mSFqEm7RkmUFYOumNu45mkDL4u9kdnNY1YYqNQfQf6gUrxvf4Vp/0zz
CJ4G1ktNC9rOag6iGXp5THv9lHTzTJIezYM1vtbyx1gwzdZ941z03u2H9vWdw7eT5MObucXg+aCX
YFTYYwX1SBYCSf5JHvUsOVwCv3/oskIRfsMmeg5jZiSPnKT3jm9ycA7OP/xVR1z8q8OiGjfHrwg3
kyDIWV98JtyOU1aZMz41MQmCaKbUpZWYMG2a7JqDMgVmPVnVKutjOpd6+2/ApiCdu7Er37VC28I9
YXUM6zG2dLojoWa9zrr1J+UfqZ+ZXC6s29hTJz3E8W8OXrWFyMSja6NyysYn01C2PkpQPprOvt+C
ttd0ouH2TYXG/9hVkzreAEnQTvHFa7ilD0ehRk6f/GKTzjelypKpFEZzKhwGUsVG1sMgjh/rxJvC
Re3ZdJfn7xLH0HJyHg6WUTJtLSsNp7CUg7HWu7piMny+AHQOQsaYGfBZXjHHpbptrW+MQw0uHrwk
icDu73JhFqgu/WiuzW2b/+bGkAqy3ExmZcnsPaaFC2tOyRC+ub2GVJNjK2Fj0rU91CCm4u2lJmTq
Q8atAbPtuRU71SFVCRKn90dsfzDKww8qiYkDJQdXlpHkEq/kYDCo6dQeOFNbOqfIDe2Dtu4x+mOI
BilQbf4ucrh3t6eCHv4aOYz+9qNp0CFsoT2js2g1o2BLkKwogY+Ct3JB6HZcriw4qtONs9kj15ny
N9a/+sNVZhveSBh19aBORqqgizHVQVPUvrWHEOeGQao6u5gSVoXS56q5LBYwwarxMGmM9vsLgDas
0xnfLWm3XpxMVF0qz3Mlnjt65vVGQHNBH5NFPaLRySj7KTA6326ZPjEiIc5zgTS16Y03IRD9UPq5
vFjwBUiLCdjSW87RiU14MZcg3sdm0Sc7L50ofPCnZWHTHGo9fS4OEr0meSwnwYp/sS/Xbe1oQp1v
Hg2/PB5NFmCznFsRnq7a+Keyg1QV/ECW8Fe7uZtPsdec7AvQsf8aVch4lUr9K1WoTXhWfbIb8kjg
iOsL0CNvqmc9nYNmzR9jd6dF0jbkJ67q7LBJgTVes+GzxB2ZVjZgFlfBv4hULW//iIes0o+gprob
z0CHYrNU/XsH33kjkyAtNNVHTXMqUUcJy0rcYvsLEOvwRMaf4fpc096xXPKBbDa53F7e3rgaFyiO
DdAo4dhcbKZK/z/NHnJPJcqeBx8nBj5cJhcV27BZKjyq/Ac1soSNwCyyRFEDlTX3gqu0wqFWsjvE
S5kSbSHGUZ01X/RpeqI+NSPetKCkTwGyFijwqjwOd+Q4MajimaqW+4Re64QTWVZ+kRP3SkaK1EMz
lz/5XdS/GdTDGlrGdUnyLtMHTtuVkGAPfjzV8nzF4vPbwIl3Tqf8NRVHRvHwPOozZwjLvxWRpGIP
2Hj2esEWOT/VeXva+F5YDRvFYT53tIBoINH415C2iVT6rVlnZSjLIGsl3yLMGKvlU+dKIG10S+Ao
bbK/w36ze2lia1PASboed5Zo62Gd+RvYRjPW3t7nAlr3bnJMeJMsdOpAf4ypSxF5O/zyQsiUw4WV
YSuzqqWHNFx+rqzhDybjJCY7cfACtlDpzjiom2VrYojoIluQdfu25t9v4acpzmsj+yPmx+qPCRWF
PtdRIMvCehj5bKIcZ0IGKd0aSa4Vssy1xQxItnXBe1gZMl+NHsViY00geauDBPYc51Wo8FgPB6xU
sb5C1d7z2Lo7hWXrokcawDCI5+QfzCHxATlSW11x0jpOVqww3z3y5JqfAjWrvv1P1r5n8iPrR/KF
L2vXF6Bm8zyvrWaTe2DvWbG3+77enr2PxBfvzCaFTzqp/ypL8ptrKIJHTkDzfNU93JWNl68+aH7+
Fay/JT7ikVdWOtclbVmSvYrGE3RAkuOO93Su91fH/HJLjmXsDFapJCppULSzuztuwRTGNHhURiVl
rqqh2K9qDab1jqo9Z5SsnR1DMziHRpD+v6wJWR6brBpTjl8HLrP0xHyHXqGsOOHGdx9vpfF0oOsB
xstUge336Pl/7qpesxp8P/95ZGLp6rhvi+s/NkL9l+sSAqoMbsQmLX3PVtZXd10aKZFyqGZP6vMG
+qFWZWvg7lRWDHOserHqGLeaTyEvK/ZBI6lJsvspiTUhgA7oG3V02dJrWXbmpDf0/B29xC78r0Ds
YD0nVdMePUE3z9rI3yHpI0g/3RxLcL37JimH76m9WDqcT15zBpa5hAQiQLHMWtAnyGiqM0ZTv/gc
7JcffsVxmifKEZ9qBK+suXtDGZLw89zZuUcrJhdmWvA82R7/MndIaZysOmWjILF/xIW2YrLtytor
wAA0b97FVtybV6oh+px+D/T+rQv93GE2K/H3aZsU+V2szI9dL3L+qusp0MQj0ZsO65gY9OK2PqkS
uJuI93lMpNiA9fFAMXficzkkfBNvkDQkzXmTQbpfOQ1bUeP9rmnua2/TJOsONQib3ggVSt1A4aq3
uVkGSjza432vF445gFAvmmc+ipFJu2MjFgM4+adk55uA6PSlu9cCKTB8Hs+3t5LWVv7Kb0IxC8fK
o2R7ewwbh+ZU9u8XPnAQsV1avPEGvm9fGS0zZ72xEjk07Nki5vosqAZRW+3C1SSZJlRpxk+na97q
A68y/ayCJNgnkkYMi9BclHw1ad1Lt8DeJl7aAgPQ3sfOgmG0uhK9oYiT0BEQL41CJ4/COp1yluYl
/zoGtgZG4NNEnrLjWAcxwY2gbo/lBT37n0brKO+mtYoyw/oEam6astZEhleNMUGCEXsVjdIEWM7N
4Uq+ylOUsyi9ircCHprPrTQho264PmwHeeJKPT0NKSNzggtEL84Uozk5OUi3WssnFkk8/14yoJJg
DSux2/fkiVfEshC9JqUZ5qr9b+K7JEVbwqeYAl0uj5rLZ4xmUTlLoZ7ldn7nuFF3uyKscs6iIrFZ
xVZM9fBCGZESEj7UjD3IvqDxrY9p4o2pzkdzKBythHaJgMVnrXFB8nepdcogW/7H7w2m/vMwfLED
XRYLCh3JR1qRIs6dsBBNC+cG6TtvGUqc2YfmfTsfgnSXhcq8UzKyiAQn8JgcCRs4iev56R4eUSO3
jHc23NcCDG/8qDZLtyX87hjkPxx43hWBljY+ovVBy6pJVFAUDzPNFKWrlLbJ4HOuOStVrfr8qcxW
SwEkdX2YD461kpz4DIl+wONj9conUVNjU5i3A5F5FttJiJNiqfI8x0wrY/+3wCg2f+UsXv1RP/gL
xtD3a6d9+txpoXJOX63uMKP6YeLZP0iBahwnzBls6+SNwWHkwpVA2Hkm7CGHGHPj3EIFxYX2sgUM
C/Z2soq/8JydXJkc5mLkTPuhE3mKBVUrPmo3TMc/v0nSY7Kp2/xlVRnFkXc45RPt3OaSTEab9Mk3
lv+li2Uc8op//Zu6FCR1P9br5wRxRVcbW9gC3STx0+FF7Rlvn3NNDPRDnUDkUn6NzGEadniLREt4
3tgw5WP3VE9MfMo39LFKf71LgQ0X/37KVjxcERQnImSRmFbg2T52OazbQs65MLrrq22/M1ifpqWj
6PDN3JrPqb3dyqdH6j8VHZHFZH2ernP90PY0JBTU5sfJSkMcjn2iEdlC+YrQ/puCbRhLWe9CVBxL
BZI73k8ibZc9qkFWEw8is7LulRd7WkCaCWtHU9cjcJ+sXfYczzUF9qY2QvanDjkfbYq5xHWpUvsc
leIu+U0l7FOIwMhVb6xc1me5g0gqhvqD2yeIRUJMa2N4Ik31rCT+pgIJnNu60d5uaH8RkGdbSkzZ
6s/E8P3jQHh2MR9MTNKOG8AF9TmPIcyaxUk0Nz6+J2jtxc0g+SZN8gVAV5be000S9v3WVb5Yhnoa
dcoE6mba/5Aotk2e07ucOdb+Toyfc48Xp/xxkqnlb3QrUVg4M1UDCmeGtjwdFgHHNiER+PWKadaC
6CvGP9Z4Pq+n3pu02VfHSbY0SJQCBkrLSM3y5sIncPGrLvHKQEh0sLGhsnKm04MqosRa6GpjxpoM
27BZTv8xjuW9Xwo2uff4S9Lqe4bGUWO9juc63RFSI20C+JPJQGs9t5rRc72FjSU7tpg5aSWyhPIF
2oGSRR3r0hIOHErIhPkoeMoZrIeKUZlEZFbWhzN7RshVvTn5KSYriLXSMosc2g3TYSurFVnLCrDC
tgevevyx9l5eMFUtqhK/Ic5l9yLOEaxKeqcHmg8G4KiDQLfTj1lREWWcX+BZtu1vLddom9/m0nHY
8i156AEKjupb99rBG0KaLsFBHg+lNnRdbNTahusCdvOhfaDWgyNqYOkpfmqXqg4o7Cf53+jmpq3q
ExhBEpUO3+h1vzstdnNcY8P8dKHmCdFdeQdnqrGIu89PPeT2x6Os3+zV8CHEytZ4sn+AnXT8Bxap
h+/FlvqV/4IEFQdcapIlVoidCdjv7WGDo0ZuHt/5DIKrsyO/fzc3jmPx9891BteXzHJStPqmRy7T
rNuyXthUzF+bt3LTlO6piKG5xvjEgUo2W/Atfo+6xUn+HFqgHUJz8pnfa1iU+x61EK8WiGnd0GQa
36V2/LJszk28pIlPkTjIagQYP+FDLXUTQl3aW3A0w3BKR89YixfNe5zaq7P2Ud+quEqbbE/05Obp
+4/AkjZ1tLU333xmeztiTyistIOr/E8E7mjTFsS+AHByDZkm910DMgcOI65953oxfJwfA3K3Ye5/
EklnNkeBbIxsd7qWHYaPNFLUgqPNqi4/+f0QvgAXW1i5aVriYwkXGkYo/ZfL9Q+9aLwrRu0d9Bjh
6ia5LHzJem0ePy4Zr8W7XPVkyCP1Sxz+WFJluVx8bzjBT12k30OUXSuXNrn/BziGU4ReBj5e5TPl
V41QRLwsvFSw8aEq+twTZNtWS67xdbB8YuZEBft+AZpfFo5M2097iLKlG6PGk7REfL2FlrrrxQct
cYmQXflcRUkiTdzdtUKPPJNHNh6nXAFS7zR2O3ltO2otGgtnGMAugc4bNufX+SO/ELctlizKZeo0
btkQf1FY+lcNio6ELGZaYIFCPlucz+teQXd9vpyrI/e26rSC4rG6smwOSneVarqRILXBUhcQVgGn
FT0Sh5BFA494A18RyYaMBHEzLY+yzVq2qp0g4jrwsdb1E23K9Df8Icn2D/fz2ZhF2d1YtUGKccwu
53axVooD5/nqLHErh38BhlFXx2pvdoGUaRiJf72GrXMdZUHRP6UpZctbc2PierlmFVX8qhO6bpqf
8p8Cmr+FbOyQNfQfNxDFN4sDT5q8/KXSpJU3F1kQpyGKs0SS+Ij8pS24PVnPlEFIL1rPUHfHVzu+
GiUdx9mW5eOmgjk/aTza0kloR599VzKa/8bATUPwkje80xaJncuCOfCJamO9WL0MrCReGgc909uO
r2mJKuN5WlY0pNx5DvTzvWdIHv/mff5ZwdXvtuYm0Ym36nsQFFNaIO9YqP194IFZmbeFoc3ayV+/
4bs0maupYHi5dtAprXIJF8QpUEheSFT9V2Ck2LlKHXdGMllfFhX51NC0LUIRk+vfKGPwud63w0l9
PWn+R9fkwI2l3/k6clm8q9rf7SjXXeH3iU3M8v44ENm2LdddWN4Sp3vMi7lD23QOGP0RIZL3vlPr
zFRgf8G3URxDlVly5/d26/zX9Wj/bMtBh0psWEBUuYK/6CJpzZj62AVP1LIG9Uer3kDE4PGY7kKz
shx5dVocP3D11CeHtmhbnGKCMuuSCFaiz67p8qwYDBTqtMmji7vihRJtwEpgQbQ/yEHYxVo8YVfY
a+/dwyNPVmIDbudRJOb+IZTMC96Omr8l2viuga/mrNDo7Rw7wU/irFc0cMHDUYI7DY/8UNUWlz+s
6aQvWRZRimISKUZzGbiVPLCitAZ8SRzINKLLfDxqH0CBGDtuLV/OCdkHMhmfub/iFKWB/YakbsWd
ZlKtYYlshvPKhJv3085OEWp47gEvYqalztGdy8BfoafXS3AbHb1ZexfUuT0UOY1CfK797/SS6lIO
dmtdq+8bfkt2V8+vy9AshMtLYblPYfCtvB907W4bTK4taSpSHlVJQw/DPsxhD44NfXKTk18A+MqH
XEgCzO6wo8u8pTaemlJ+q18lHAXrf1i+cbG2lJTUXDv9TMza6zKnw1URHHRKye3uq13uWhneQXz+
cUxHI04uytkthHu5IYcvBQSzZVzZoop1x23dHvvzmsAuLkO5V+Ns2kqBuNxfrbWvtL8AXYe97FlX
Rl8AjV6ZeyCdKuGfFVPHgBA8WGx7fSvx2Cy6Gu7ZyT7H7HmgBoYGVb84lhocTVGUFRyTa/1ee/Sl
ii+8wgFSbpO+6iQuCTuEFrgGR3Pugq3CeL4ldGJ2PH4oje2Ww9c/1R1TdhHGNFX0gRqmvbP7u21r
mljcSMNx0NFmmzZsGwyoOdLqiupm1jjlR7wJPfH9YFP5L9N/li8ayD2dFeCcUVe6/QZqkjrsOsf9
7p8/oCeR9j8KsD5to8wyv/voNfgdkH9CaU+v4HwBzsBqXwC3xPdYD+Z9P6bfiLn8npWahH48sI9V
R+cDWWGKuZSZgr+iE4Ryrb/NjeQqKsWX3PszSH3I05+ntw2mBDwnKj7URt1Lzpc6PgjKbBnWqr5q
qH3id54F8cJWSZW/0+qIgNl01e6F3lnzC4Y1k65gvgBpIn7I8kLp7uj8hQm+lzw1L0bmAtWoffOg
oP1Jic0G1fUBoraauxL1SV4ZlnIsudixfTeD5lw/XXrqTJRrUS3PqSm1FrhMblhEbeAyyMH/0pJb
Z0A8lgOsI6aEVJrlVXEmql1mBxNFi8yKzGERo6IE/WcxygZNXAY0h5SCzy5FU8aB1V6mshjjYb2z
aFKCNUFMd5XdXGcf/LFA5zAjZ5lVrDKyLkVeASQtZLjq8tKzGRqRDkfP8PjYUiNJbtU55SA7ltWt
Lo1+0075COl9nWHGxZv5rZk1XrW5MQo5NjwE7W32iHs645Ol7/Fpm3Glo3FvCqB9GG22nwbafouX
vplUSOP7AjzFHQlqu3iixy3Bhhy027tOWR1KIYPylJKFPWEDs/Z2bxWaSHLG+aGcYDMHCAMvPznC
h/nmEs3eZGHE6dqUWFANgqJr/3oK8it1tywKCFZ5OzPYE7C1QVUSncfciKJ+1CR9ASrf+Emyr64+
tWvd3adEydsieNecpFMCvLKAKMXu9kgJQ9oqYmnP7za6kKVH3/6unnY3vCyaJEYySJ9Zs2t/q+UX
WC5xOhWH8K0M3k9AM+WMkyey3rDWytIvnB5MnYF+xl76LdQZtKKSPW1UeLmmKWB2rxcq9ONsN6Ge
PI+u2D9YkF/2CxDJGdZKOeEtLbST+SnwMGx56jHJHMJsriTLcJlfDnRp5Ssr9MaN0iZKlEScEZW1
r7RxAnehvQTBvPXRrv/LKp1aRekUaVgI2CVOVspaM7f1dtoqsays6lC/yv8v8xmjdQcwuJI9CP65
9E5yTuuc4dd41NmiZh6w8qfQkgv9q6K5X5s6eh//cbqIrpgLHJr+Agw5fdQNPR1Zqen6AdV6LaDj
ymr1T/DdPMBvDLIpCd7Ccu7Yx+n4h4/LcxQ1b954j0T/Kle0l0okyKTxWMN4KExn82+L88dQzgfz
iEBaDMjzJWEfenFvXHHsp3pbuTYt/tRhPKOIviDTtWpiIkM1PQq28TsXyIPLVx910wq9mgG/C0qN
zc42R0MgtfAPPmaSQnmLnTxu6VdNfjPJfNQPd8UPhKLuRaa6g3smohLHa85fSXY/gseOSmX1/zzP
XC5Fa4IWdE3JwVf3MEKqTW9LyVwdYKEQy1bwtEMtDAqqxkMdxed8h4XGfb5LDO34GFav1aJDyhCQ
oTJ3WNPV9XyYa7TwlJih53MuXiy1xTvmZIiJhzJ8V2sbY9+0ok+RfMwww+1Uz9Rgk0bd0zH5KkzY
kzizJO917zyzNEmFh2C1RZgvz3OVQaOYIyxQpc9TR0zxUo6s6FALp2QfG77ye6JaLWvNIpSM0uw3
QREX9/LjrKzpkb3bKFECmT4cuq4clLKMsbFhLaPgIFRTeT2xubZKdtkn7SSKzGJjgo9lQdT5PMZD
Vvgg1nie7XdeoiaFC0YnZR0d/Vawg4oQQFC6ZmxdsLr+BhgkUOStsNp3fn0qT6oFXuQ44ZgS9Khi
pX8O491rsw0hfTUFd+RjGgC25BT0YU/1UuL8Zno5aq9UpLhVl9qqSuNsfiWowBiGLKc2xiwLYELu
aOoXWyt6aZJ4xuSoU4gR2GJKk1VV8pKXeuIr5D85ty+GPXBYv1JoxBD+GW22DaKd8NGKZLUqiupP
wCKmKTEdZttT6V0kawrNzc4b3Ooa1e1+07ukruRs3tO9p7gKbIySwh6eosfhrZJaMa55X3y6M1oS
XCLjQmbTntOdApnh93QMTXAdk7W3HZOV3TfpUM3GLi3lUmpOs7gudwgKD821wTPrPdYJsc0zXJQH
SyRR5g1+O2CvVV78JCsfqyMPV8vDQBiTEDy3WBn5zhrbiLa/+Fh6McfwwNjnWWGZqyxdK/9bFWvw
2p5jjdOQ5XejRS3HPGXKo72NemI6Dx5nyGv1MX+vTraqGLsDbJ4tpNeBjKOI3BLf4mDxHsiuS+QL
4CGShPr0h3Okqa0sOl1Gb1AQS8+K++zbYWFs73ENrONpVrVw2INunt2jIU1e4gaK8HVh1N7+EoXB
I/dTobGYM16T7y6yxLeNMMTQC5NUBcnZe73NpdypJuw0WqV4NTt/r2Ft/JoJf208/5iAkVrxPdsK
CXhp2DcbgpfF0w1D8lwLc0Gp9+Ef3W3xV7I/Xlmx5+RrtQ1u3a0RA0B/JAI4hzW4srBHN/J0PR4o
9QNGH8vSM/ILU7KOCkneW10ECY4+3U0/MeBXTaR2A6qQlsJuVrL/fm+Zj//pQXJkE/KKU4gT4KKF
uqcC934v2cMIHwCyL327qfqg8/X11Q0jcKHHkLXee7vt+BDXXTi2OlCe4mn1k7ZUYXzPwEXJqPX4
9740mxnd/0+T22ebtyp59of5Rit23pLLwRK5ltQcvDglky09FI1DOUyZSQ4IP36K26twBls7soTM
9Qc25qQyhnVZBg6p3dJQFYt7daXCQaMOq7SEtZ5oFKuE1RRbOIJTmWpaQnhUFvbWSU8N7JENqQq5
vZGkaVab1bBpx614bm28vbkxkuz9UDJHxks0Ggr7qY4PUWh4JDDpYIDMXlAyo2F0qNPPb8olfYtU
XmUC9wqteVEGTT6PC2X1Vf3g1ro1aHlrgNyakOfeyTvnefsMtduNlh6ZvPFmaaml2LOmABSETsgT
74Z4t2PqSVZt7YlmeN7SkixmSTYCzCSPFQmoIDonmxzp8MtZuUOEF14wWf2XgOI8XlXvVTUw7ctr
X4Pgl9Oyp8vw1n1q+Lcb5exeZC5tUittVeIv1oHzHctDLcGAx5yhoqcpGT1tbA4XL7SPMmrMe+mi
5gSFAWZgfnvW+DznbjHorsghT5yubk1tUeYnW90u2sYk7knt4B2nRllbyhS5lE8DxScntpmOFayA
RoyP4N/INm+tEe/cgDRbbp7iaeeR/ZeFtkgqMXg658QVWGGghzDyj6BjHUS+6rq13JZeuRW0v4o6
i7Pu5XNMwwM0pg3JJNcozW6HFvjE3XZbhB2gxa2RcbERbumMF4tpp25bHEHRaxKuyntJTIfGJAGJ
n7dtznoWuXvrU5y1Iaxl68nJiQvUnPa/rT0Je611rcRH00zu611BX4BGHqDeLJFnKHbJvLupk8bG
BwgHQuJ7XjC4fYZEIuiOMfFSDCNhdeSTb9m+N9qhoLG9GYFQb4zCox+Wd0p1WUDUuSYjy139LoEs
FHdHwzXrET3f1Oo53amfZDtLPvqROuph7MGKYwbpHI39Og8HRkWz8DTQwNTc50lTaYN6K3SwblFT
3nnfNjrCodgqBbHwbdv1XK1KMm2gwbGfK9rVr3JEqxCHzZ6c8Ha+2sv1Z+vSI2Kn99qfKO7flaOb
VE0gRYyZYnmG+pG4eVLFTB/aT7cOw4haN9/22qJfjDzm5uR/CGppVPT/rDginzynP6WlpZuB6iKx
4tRQmrmKd7sh1yzj+OMfIraNDBQUnPU2dAbXbUgcohF2W5H8i4Cb/2I2q1sTEWTJHdhCX5okWaUW
lwSES62s7Zh+HyVZtQbl8j4BUSHFjCk66r0mq4ZkrnBJnd/P89KH078jwmXxUFlpmjTFOavXvIu5
lk9RzIbCGOA532WFC3pAMF0WtC1SSX0B5vahE48+fHznY2nwjKLwVHZLnQpV44/VHR+1OeF/r/zS
+AJYBirpGsrbOhPO7XDY4fkXRYx70B95vOaHMhTN1TpgqzMB19Tq/noL2tDnkkvNXXJsc03IlndE
u8URBpX8R581CLdoF8ul0SPWmbdf/B/h92JFfiU2SZKNsGTPYgSvLrjqhzqyq4xKNeJzbpUyNkmR
d7GOorvgMgVE9x6rnPhwZdecucAzHrS2xq1OKN+xiVz4BmvhdDw+9mZVvCVpbp2Mt8sS/ysl/rFI
3v4m4gdstZhlyQ7obJ1PF064PLI+A3uERDoe4GEPtSUAvPW+AKFaPbMP675inKlNUqFi3lVDjRgw
chM+Gt+WWwWXN2pkQccHSrzPlSRDrbHQCb+jkpCE5oKsju+gihYeuvnOlvD5HdlEyqe02Wq3wpi4
NIl+B/FHYtGK4O6iqj9x+q8P8YWg0/06q6oGObHBrgAtZOYVLi7TLHipgbLJfjDuhigyXwC73EHy
sWTym2piprnLnTj6E1FFLolvAfiHblMK+zJtmOst4wDyfLFFdI1HIv97tVjT3LAlXggJGD/r+2qI
uXMNZ8ndSxx1A22U/eQ/ihaXmplJAXC/EkXKRNmdMiicn2Odk86eNXHGbSlCC+Ovyo3lW5ZqL01Z
hml/Cap5vp8ci7rOC3AXWH/XkU9JXrfQkI6JCTjNBDJfnNhdQaedJIIpWKTm0NsaMh4RDYwd6wzX
JQ+H+cnuWFBJuA2nU90vxci5MZw6/W/felKVrcJ8Dlr4BJcOnEDK14ncSEjEeanBe4ao/fblG9KE
RmyTIWDhsHZB6iEM0YBvS4N4vwzzBOnn7N2jAzAGTipBRu9l2VIVTWO5tIHewFiT4ZorMxUWNmdt
r6MCu7RvL4F1Cjfmjx3rL0wiybx4dWwxl0B++pXApYQEUSxM27y15aLEIZGGE75lpsA6yQqJissW
JUD/J92mOQqLNaYtUtge74hyIDaj2cbPZdSnCLXL/7RVhKCguLXudDp6deEYWYLOQeqMV7TWG4UF
7vpzDO+oscZjrj7HvzgUM0HYxzr+7va0MwkPysjXBWXTqAaNp50xaWqKZf47m4PdD2R1utFmfijS
aWQeQc6EKAu4ogHGmlS6STUokxyKcufV7iNVxCVHrizzQjY7nXvrsp82dZnSR6rY0cSuzD6J7vCY
7e9niUlFnlj6kUMr+O0kvlku2/3MW7XuB2WR8pqsXHzxVFsBHRN0eBy5XwDnwBrKNuO5iGqWM/bh
d+2S1QtZoVSnnNApS2nChhu1KHC0/igGk80ouMZhdApE8lulnrDnCStMVR8rSx20UYw63XTF4f39
6l6mLyaZlCP7VkXekiOgL4CuVj1cSZweJAi/vDt7wEoiprG3zLSHiykkvFVTZN1ZcZzuosOdrpfy
BahB+AJcqzWccc3Xb2JUPmJPXZdLUhFwOmcyUTseUyc4+UQdXVO8TMH/XmfNKhfojOVV2EmNum+x
qeSkACppyBValRRzkrHfK6jKDwsgpDiEuCqhq+LLIRCgw2NN1Iuzpv2xh6aqLdyrGGGx2VMSo8RS
QXBnhZehpRUp8CRSUJYvR8iOSVCJsuf1qv4TV3Y92HCaZd7992rANxWV0PTqQnD8sfqpBzdYrSUQ
dGxt9gVI/7P6sV35iqDvqta6zKGLFxySNM+KHtlzO4qHbSu+VPOb26xR8kdb2yLMWgqG0HT+vm61
u5V5Lv8An/zmQ4uJNYWV0dYh3Mi7Gzaml6Vs0t3EHEUWd9LPpmoUkRmb+VlmDj9htbY22bEBeQef
vDjJTU5tB4bLR13Zl+t5i/t1J9WBcruFo3jn09UG15sjAseW9gSQM6nV2Pm/Fcqik+XXmnudll99
rPFET0/DHg3/Glcu8S9c9K7CfjlSU8fkyxz8Zg6wNw4QvJiHvhu8UH037xZKRZFCcTiDcmQfCQiM
+pSozmr2c6JuSxNhIVoL37OpPGraMHEvB3bNPJu6PqgqJUf1wjT4Qno7t6lD4Q78V/E40dql54r5
tdAkTRc1noNBk/aammFbh54j6pGGeggDaZqZk+0bo5WPwHhEm9kTcAm3ykFRGDSzgQRdYTFURfAg
X8CTR7uTCeXlIT0qNRy7VsM/dqUcSQoXqnFN1sN2B16orVbUKLdVt02VLeokyR6/Puw+vYWLLmtj
R+JEwmjSN5oAbqiYvHydubaGdbH8hXfKijNkPsk/s4RCiopA+n+Kyt9NZqle8Dwhu2J8VsTK/+NI
uM1BZma2LaboozycibtfAOwAyzNGwcmuyIZErTsRQZ4Ka4Rh/mt4w9XRozYNgpbc7vgeG9Odc1DI
OMVy9Z0jVIAgnb2hZmOb5Jq3O78000doVFHMMUB98ZY4rWWGgGPBgrGqpphu9fO5lGOn41voTXy4
nSPHpYRvuaaVCQXqldHHxbJC9u4a5+Q48LJUnAav0bfiWtXLdWj2lOwObDU57NOJizJQc+JPsfAQ
q3J0aBRAJ7XFCXgfJO8mnKynyeQrDzueX96STOL+TuJUDcl6PWV97sMHPvFRq8anTQDMM9+mEQbw
HZd3WCQwZ1xj3ARmlwv6VRctvYubexdZg3/T9V/CTRKHO8A+lB2023UCA0RT1weq7QkZ3X3tHRaY
DjQUemOtvbhFFh4Row/yfqWPx1z2je0Lc9HlrkQ+TEnQu3eBvA2gwZ2GCH5TarPvvzo4N4fmBt/a
G7ksix6GZVIckNJmBuWrbTy5nq4E2loxNlkK3hZbt5C5ikioDqmTtAUa0H60+DnR2guoE6U+rKCJ
NfIW04zneV9nhX9i0Bhn4QELaG6njhw9GBR5h/X3jd35COJRB8u9VLwO0QUn5CcDJ74ATfnKBv7j
9X980z6Q3T0/WcKeRo5mf/XN0GY0CBLmBbXTUkwixeUKY2ZNy2N54sPkMXbxcxVijDyrbnB2SYjA
iZQntV+vLlz95nUG6k87ksvzAi+gh42hbPNGoZbrOXrRm2Oz18aCtDxfKkL27fKKz2zFPjGzk10W
MlJqWiYd6UiuaPaxZZwdjbGvBIhvAswuf+dK7fq1D+sudqEThbhcdUfI445LkOc76lR778PkaHk7
23NhOMQLwk1xK9+q6cRnXFv1uBUfJTQIJxSpRMw5Kt4chrSYWLabrFI+ManDPV5rdBEYl+vNVDBM
HnEo88rFsfB/2JKNDtubo4mD/tT/7Hw25b0an10SZB7CPPVUVcSv9l7bKg8MO6MjECcXeuLUrXyy
dMxYnSkV1eQk2PVllz+s8e0N9VEnTAY3mlBgFRWNl0P60Zb01SMLINQSnCuiWDVBzufZlt8ctbmt
/Rmd2DDzqJXGL9PGJaZLNp29eFf4ddFID7N976zX4s3pqtjmnau8Wr+DlHXuTgJf2Yw5xHoH80F3
WUAodJbFPcy5y8qquqgqCVPWZ3f6PK8rExcjCq1ZfdKRdMZVTX3r5gj0ArmYdJIg2M5a/z3n3+Mi
MfBP2Yx0bj9lKEwJYkN2bbRhPWXmoN9Igi2z+a9BxRSAxRu+AIH4e9ePvA5m1nh38jIbNlzcU0sl
TRzpDjPJzxrln5tzl23RiprP/vLON+NHLYimZzZ7o3bCy3L0anOMBAtejXMpFQuMAWjCA/UO16bt
vGij3xsR6pOszp8Px19VpF2LAxBZ32lPyEmX5DXddU7sFxQ6/CJI7qqfDTBUUTMxD/b55WXFJJH2
seF5qj3ru0GxBDFsSXBVKHslxMHP844VSCkLlKSYeLQ95j91sntyh7TuaUvvlRxLmMX7fJEWpMqu
S7al0oSSnbE25h2KdsJfwuLZsXFcpaw3GF0WPZNGn/U+3a05MzWvfy8lJksZREeNnCzuphiH0eGl
4UmoRY0wZqmlpnfzR7RSlhdWxUMxyjFN8V/SbYrjIxzCxIbS0VaHJlaWajbjwLAQqhJkJUQZV5rQ
jSstNrlXvKnVYyTMSat8w0+U58bqlIfZKNaJ8mCV59ASledQwRRhMWh24KtqtqCDN9tLy6K1hmNV
wFJRhRjIVT7KQ/5GunhYZpEH2rXobzLYlmhPG76OuNtV/WMYezwn6dP4W9CtxWnzvSaZEJDPDnXS
51YbrZVEX4dwcu4wMQX5+QJx6LeqtoUecBHt6lsl02ueTI8liSKbF/cd3BoV8dfXENqGG0MSl7W6
wztQ1uX7hkcl5U3ogQTnvYkp+QWAZO+5tnVwTh8VPToS5V8ZyCWEJIXZnDhHHTG1M1u7pe3uPdqs
A3El7KVjofEOn5Wkr6NIlsKujbXsLiCceKShBqTdDE8ZxgX5a2Zys+HUYIhzKV9pmWG1DGM1xUG4
fYHzmBjdRECEkgd9ZD4T/gSWk5H0P87TldYIcoHEU4ArAjML/YrnYep3Pc2jVx1KHhYqd7tFU5tY
JT/XbjG8vf9/Fgzplbncnw1Rdfr0XzpSSC/tnxux++1idnzynZWsP2Fsz+lt65qLostpgq3P6Otv
S7jxc/9WQw40DDs+RVJuwXwBNvNTXKfUmxfjcncRqeMn2YZdpkCJ7VBuPJfLzR31cSYkUA1dWVu6
q0WsYw3I20O6s2pZK0H7czuJ4CvuJAEL1v6jah2b5K1znLuJY9eNYtYZIt/l+HhqDJvGRiFR9Tdg
6umlzC2tT44YE/yoTDNOrqeAgZnT2PjHTkn8oRLrzutKkVWyLFOuQ6OA0ns4SkyBKclID0iHuYJr
GsLO8kciwQ4hZvAfP9ovgEkO3+hhy9NJqYK8j1AyZwyf+V8VWUS5jrg7XRI2h4N4G7N7nY1/k4pW
v5sIvsE6IDycDhNWt11deD906G8g4Evpq+WYxbGfKuoT/4uJIAndXPjn5596Skzmxfjg+4/S6nPu
6djMgJvu+4uEUCqQXkcbETE6LBZDntxhITATAaqvrCi08iDhxPOZvocHL91jc7PVB9Inv5SXg/+5
jWvg+/2fcTkXWKDHZNXpvbUHmqQ7NijRIJMQM2i8l2cfXA5aedj+J1Nb+/4gpbEyiUEcJt/dbfWM
ZuOUjo/9WD2S/GvMzKlY8ONcccgfyw+BwJrbgf1XjX8JUuC/JXlVzY62NA7vmEqkkpHtC4f9h9rk
IXBtejV4XYqJghm5ozx9ZgtgNq9AvnhAOut4hcbhcRnEBr9Pvs4pume1mfjPnId8NurqASgxcyFN
uFIVVX3X4sznvIA9bMjG+bcmRluWkPVscPHDhnLSD0IvXUbXlB+x1FJESF2hxrbpCxDiKpfo1myW
hMd0CF7+0DU+WRNko8+9KR3JtvaZ385PIb2bZoN6Wx59ikvLys29P1OdYtAkXftJFE1ScDkPktf6
35/TEVakZZMmWVmg7X6hGHqRHEfVOe4i0+nacr+xOoLkTqbyO74L0tMtDD85eyXZDlLkW7gZ/Xmi
8FGvDsA7pXcsLZZlw6X2xgvozbn9fwUgSd+2RKSsI4PWbKOyvriGP7kcrKv0BqOw02bUZfJgALYz
ye1SazfJfX1xPGCEkldlz1wTT9GuobW5WWV5EAB5Q9/f2rKOj1Gx0/hy8geNGwWlfYoU5+b0p9x4
Xvre3mncDbAcP6g+lbd34h09bixnQtI0Mwd+DgjNW9U8VaZd2moRRli1028DHRq054AjFsfBt7eQ
QTIY9s4zGM8tgcipLHwXf3PnM4ESRSGPcR/EK7a21S10jQdCunJZowzCPjPzA4yOtcwPF8E1tNZz
meNZJjIWiODyelK8OwygPB9zJfGyDJvCb85HIqlq3h2TSkV2lSQMcHafun0NaemeJdPsNVe6aKZ4
xAY0zJljx1Nc/qGo/bJpHBfazFgrHpk1PNACmQA2K6yHwZczLGRIAZIDMoI6qBk965ANlq9W1LXI
NHtNMuEKyy/2UYiqnO3cMcgdDTTiByek+E7jV9wQ7MMyqSOHK9cdKbY+F5br7WSwjS1bYzE9WzjA
rQs/G6WsNjH5eHtJGbK8BvP6hqs6BqiTvfo3lpFPMspVmw3LZO2hWJdymPBdwdQSwR0MhiEzE/wo
eefeoNX8Pf2XB5wnjk+fYUGNw9+K1tZ8WxWfiW4ubYrNH5CwsVPXA5wfaub1LXIL1GSOAxl33Fi5
NDaKSI4GMbjHXAINezaBuu9Hi80ht0f9K8Y+225to0WPEwb5n/vCvTPh/feZavE8gOCdq56CnfQR
xOrweTe3C9hIw/I4rKY4NdJ4pi238xGMMSfxJrlZWwakskM2KPtbDoaovIaaHqdRXNP7WxHWk+0k
1n+Zik8yhCuXTckHg0huW/vGqW4mjcaEDLv2jNSJISRiqMZ5rpdE0z7S4JHFWiWbHhi0Z23ScZ4H
Hauy1K8itICu4DC4LViLdWmm2+1iFZR1/CuI1jxDNeM6Bvk3H8eapvQcSDVrsXNzLIOjMxH0zxWS
5pjTZqNpOKzbFLUGem76hZ6buqRFjfSF6h30m6gRNvo3VDuo3UwJS1JuqLNGaYiUvTS1MzSZoAfv
o8yojTSaBWJt9NNRbqN1AmPppNN3UZpXE0G6k3GimmncViQSEU4TkVBTc0XAtiekMoqrmkyaV7gO
lOTTKaTRmkFhaKKKkZWAp+KYKfSLInplOk603tTGgpMUUGmJibeasRVXBqxEaBE4paQGlosToGaM
0lLSGFLSUtAxwNPFRipFrSCCxoW1zeeW8cW8pj51UEjHv6VOZ794FVvMMCH5euwH69K6lrWOw8H2
dzAqmW+dluWAyQo6fSn+ECurqdNuoh9mX5/OxgL7FvetFFMZgQXetEJ5Mlz0wm0N0/2f/rUs8uuk
Dzjc4Dcbtw+b/Gu7sZ3TxRbWaxKlrCjJHwPmwPvZqnrV4Y9TjtoSZovti+YSvCnf0p8i7FI4z/ic
LKWAn81l54bcV+nXFVYlvdziLzNx++Ezn/gWK9zWTTZtUuYfJUXCWvBwOV215dpBKeJUiAyks7o4
x/Dk1LikM5CYOrYcYNECu8irGCzswChfvZ9q3fF0EUGq3Kx42hzjFZ3h441zTPT7XF/6FShuTYuj
SdZlkuIBHM72ylrhCx/dBeCX/Gkm0++tIIZJt6x3ABTJOG98elepwvanXvEMaRlHOnuZHz1AB5A+
tYWqQya9oejrZoJpLZXWVV6qdy5z+Wa0cYhY5ZfCmruu9IGxsD8f3T0NQPoepfZZbh4XWKI4Z2yP
yr1201GKBJyDua1sY1dTjAcDlT71jatrR1vwpfy7Fi2y7VC4GQvWlyxsJo8iKN1wceuKPNkXgMw/
E1t3K3n9jW5Mca227O/jexJ798VhA81NtRl2ztby/cpbo8jDrg/zrT0eLVLTU4xbQk3MeSA44GOp
/D1FdR4RjtLbwvf3hO2b7RtZ1++F4wB3wa0dbjeS+0aXTwqyNZqzHIG5SuWBPqa0tFDZyet2Wr3b
SX10EIU/PsbgMOxqaQ6v4g0v7QWi+zWi7M5wQF7dTzWvexNdaReSszW8kcvzxHgSH1qHw3Gf+EL1
de/n7h9O9FosSuc5pfhW81S2e6jlVYkfaS3B3elUL7TLqxlMTq24fqOx/Gu68JhpfDN/HH986ghC
57DHNS6lf2snia4W3jS5CWypJnGEYDnb2JpNQ9StTzF45VPzKw+uaYS3rXZeMUVIYGHlfNyoGBNj
3rizyRn+8M/SotECUWtyyhljYg55APaiO0uHBKoxA64FetTXdrbQaWmm2lvMv2YeYxKBQ5UZ3e+a
ydCe0+wa3JJ5KSpdYjTju3O31Ape7cep599mnDBDGwY9sHNTx2M4liV1KB2C5Yepr0m+tdMudWtH
MsSj+zw2FIw0+3oareKpLK4ttOeERKyOocIRnhsc4rRclhanN+I/C1xok2z70YTd5hHDHHRaj0fw
5Fqem396ZCGs8ZjA659fSu+8R6pYT22pPJcxTrLbr9lVSDtbA/KuY8J3FtFpevRPNHE86rsDnBbH
YVPugjj4dPubt3FvDJIEJyVGQPqelJJpt5FKkDQSCRyMIR8xB7gV2vh3Vbax0W9t0khS7e9ypk6F
c9u5qa11u3XVJ5L67hlkFgY4pljASOcjjnHOKT5X1KOe8QeGho1lYTMXD3K5dD/Ce4rmMlScV3fj
HVrXUNP02OO5W4lg3CTBz+NcpLb2y2SSrcBpmbDQ/wB0etZuMbgVm1C5kQRvM7IvRScgfQdqgL+5
pjcU2iyAlBzRimKcU/dUNAKOKlMrsPmdj/wI1FSimA8U7LDBUkH2NMFOzTQxDknJOTShaWlzQ2A5
ODWxpes3GmPvhbBrG3DFIGppgb11rMl85eXljVCVw9UQ1PDUmArYplBNFAmJk0maWnxR+Y4X1p2A
aDTgCa15tAuYohJgEYzxWTu8tiCOlFgsOUFSDXQWuvC0jGzhsAfkK5yScHpVZpCapSsJo2NS1iW9
kLE8elZbSk1Dupu6k2K5NvpjNUe6mlqkLjiaTNMJpM0CHlqTNMzRmmIfmjNMzS5oFZD80ZpmaXNA
rDs0mabupCaQDiabmkzRRzBcDTc0tNoELmjNJSUXGLuo3U2kouKw8mmGjNJmgVgopabRcVhpooPW
ipYx1FGaTNAFVamFIq06majWUGo2WpTTcZpCZDigipilJsoAr4xU8VIUpYxRYTJxS0gooQtBaKTN
FACg06mUuaAHVIDUWaeDTje+gG5Ya9c2lnJaZ8yFs4Rui57ipYfEVzBpbadEFRWbcZAMOec4J61p
6Rolqnh2fV508593lxp2B/vfWl8OWunaqjaeYcX8rZim6gD0xW0Yt9RoZa+Mrm3+zt5Sl4BhXI5P
GOfWln8XzThgII0LSCQsF5LA5reg0rSLPV9P0toBNMZD9rdgdpPoParHiGHT9On+z/ZLQeZcKIyn
3lTPRsVpy+bKSOX/AOEt1AXxvQQJDH5f/AcYrNg1i6tbp7mLAlfPJGcbupFew/8ACG6E99CQqK6w
bmtT/FletecW0Fvb+IjbNGpjkmMWD2BPaocQOWuZ5LiRpJCWZySSfU022la3mjmT78bhl+o6VseK
tPj07UpoI/uqePx5rL01A97bI3KtPGCPYtUJa2EzTXXNTW4luQ0omuUKSYHVD1z7UW2qajZKzQtL
Cr5BPIVscHFemRaVYjxRf4aMj7DIVi8v/VfJ945HHrWBrtnCPC2jGNV3+bcbiBznecg985rb2Stu
CZzEerakI54wZNtxhpOD82O/0qD7dem0NsrP9n3MSvO3cxyc17DZ29isELywR7V0eBpOBnOMk/Ws
bVf7Dk8N6k+nQqFSbBfHzFs9vak6aXUdjymSeUoIjI+wdEydo/Cq4rZlFsbE4gYy55uMHb16Vkdz
ULRiZetLq9SCSOBpPJP+sC52/wDAquwXWruI2QzOqfKhGTj2BrofB8cEvhfWEZFaUMCvTeR7d66j
wgkCaZpSui+Ybi5ZlYfNjHpWto9WB5vNPql3uiYzv3ZAG/8AHgKiDanagWw86MS8eTyN+f8AZ75r
1saxpdzNq0FpbpHcRWzF32gZPNY9hG15aPe3sMf9o24KWKthTIB0fHepcew1oeZyy31gzQ75YGB+
ZASOT6gd6qrczK5cO289WBwT9avat9oa5mkugRK0h3ZHOfXFbHgfR7LVru8+2AmO2gLhf7zf1qeV
Md32OZmup58eZIz46bjn+dQ5Poa7bV7PR1Sy+zROjtcBX4wpUtjBro5fCunKdQi8sARWYmQ+5XNH
JYNTytLydPlWSRR6Amr9npmoX0cs0AZlT5nYEj867rRfCll5CJdKrNLavOrY6dcc1N4KCW1lraMN
yK2xU7nnHT6U+RPqFzzVWmZwm9s7tvU9au39hf6Z5YuNy+YoZQSehrf8WaVb2N7aNAQDceW5X+6S
RxWx4qt4bnX9Ejc/u2jiViemMDrR7OPcLs87cXOwuQdoOO+T9KvaRo13rbtHbY3KpY7jjheprv8A
XHtrf+0IIdPEkQjKrLhdq8feXuTV3wzZWOnR2ph2lp9PlMtwcblYg4Wl7OHcep5FcRtbyPGWyVJU
/UelQFmP8R/Ormqf8ftx/wBdX/8AQqp5rKS10GJvI7k0b800ijpUgKabRRQA7FJnFGcCmE5qrIZK
Gp2ahU1JS5QH7qXdTKTNK4Em6l3VFmjNFwHlqUNTKTNFwJd1KHqHNG6kBPupd1QZpwNUhEwOa1NK
tGnnTA7isyFd7Ae9d9oVpHbQ+a/pWishbmneNFa2W18H5f6V5nfENM5XgEmt/XtaNw5jRvlXj8q5
iR81LKehAxxTN1K9RUiGyXdSZqPNGaQhxppNJmmk0AOJpKTNJmgQuaAabmjNAD80ZpAaKAFzS03N
GaQDqSkzSUAOpuaM0maQrC0U2kzQIVjTc01jUe6gCfNJmog1O3U7iuPNJSZpaLjCkopKRIUUUUgF
oxSUmaYAnSg0Cg0za4w0macaaRSJDcaN1JijBpiEZuKWOmsOKIutCB3LFFIaM0CClptLmgkKM0Zo
oGOFPFMWniqhuM63SPEMSaLNpVyp2Fi6MP7xp+h6zZaNbzTxrnUskROfuqnr9aoaL4fk1G1nvGYx
28PBbuW9Km0rQYtTjuNkv+kRn93D3cetbJPvYq/kb9v4n0+SezvJw/2qKTdKwH3x7U/U/EWjXk01
wLaZ5XdWTd0XBqpB4UgjFkl1M0dxcSBWhAGUB7//AK6uat4S07TTIhnnV1KhCw4Ymi0l9oE/IfN4
3hGt2+pKjbEgEbrnknbiudXWYBrLag8ZZQ5kRR/ezx+Vdevw0jf7IyTbklQNP68jPArlJNHtoNYa
wlJ2eZ5akdcnpS5X3Hcy9a1NtUu5LlushzVK1l8ieKXr5civj/dOa1Nf0Y6RdPA3bke4NZUCCSWN
D0Z1B+hNQlqSzrovGtwutS6oIwxlhaFk7YK4zVTSvFFzpzOHRbmIklI5+iE91zXXReBrP+3ktXjI
tBaFj83Jl8sHJ74yaydQ8O2VroEF4FYyTXEiOc8KAxAx7YrVKXcL+RXj8Z3CreCRQ32pNmB0RB2X
2FUbbxFJb6Vd6eIwy3Mvmbj29vyru9H8EaVLDatKp3yaaZC2eAz4yT+dRan4N0rT9IvbiNxPLG3y
spyEz0FDT7lanms+qTSWotCFEanIwMH86oZrUns7VbITfaQ0xb/UgdB9ayjWfUll/TtTudOffA+0
9x2P1FaMninUmukuzIVkQfLgYUfhWz4M02zvtD1hpkj8xB8kj/w1Y1vQ7VNI0VIAsks4Ks8a5Lk/
zrT2em4K5y0XiK9gnnnjkAef/WHaOaLjxHqNzPDPJMS8GPLwoAXFbWp+DBZab9tEv3SFdCOVPccU
+DwTbmzt7u4vTDHcL8mRgA++aFTf8xVzlLu9u9RnaWRjJI55AXqfYCltL6802QtGWiYjB6jI9xXV
+G/DiJewXskubOK7ESNwfOcHpk/w/WtPU/DcOr+INYT/AFa20PmKBxzjpQ6TWzHqcTd61eXiKr7Q
EbcNox83rU58Tam+/dMfnjEbf7o7Vr2Pgyaexu55C6NCyqke05fceDU134NSHTpboOVeEZeM89qn
ll1YXZgL4j1KNQqzMAowDnkD0qKDXb62MrRTFTL/AKzH8X1rpNP8L6S+lQahdTOglYqewGKm0nwr
pVxBeXck+baGTYjL3quRdwOLuNQuriRZJZHZl+6WPT6VI+pXdyVMkzuV+6WOSPpWj4istNgkQafK
7ZUFt4P9ap6Bai71S0gcZDygN7jvWdtdx3JpJtU8jc7XHlH+Jt20/ieKoi+vFAVJZVUdMOQPwxXr
1zaWcp1bTSVaO1tg8EW3BjOOpauZ0rTdNktkKWwedS+4SZLED/nm33cVSpJ9Q1OAbzJCSTknqSeT
TBGxYDua7XR7Swe5vI5rVjJu/d+aC0a89DsBrN1yyFrqcMfkrCGZfkToRkcjvzQ4pDSMa+sJ9PZU
mXa5RW29wG6Z96p7Sa7vx1axw69bhIt6Mtv+79cfeHNSa/awf2dJNb2scURIwrJskj9BzjOKXInu
NnHRaVdS2jXSxkwqcF8HGfSqao3ofy/wr0zS7ppfAzw26RPL5rApgZ2+ppNFtNPtNFt5xaC6ujMf
MTgsOenPQUNQXUVmebJEzuqYPJxkjFX9Y0W40cwpOMGVQyj2PSu5sLOwvL7U7oWy20tugMdqWDoW
Pf0rP+J06XV1ZSRNuAgTLD+8B0qXZAcGi5bHviusHge/8lJA8RLweeE/iCYzkiuTj++v+9/WvT/F
uszaPb2RtSrb9MSN3T5uq9OKpShbUNzzdoJMnCk46kDio1jkcnajNjrgZxXp/hvT7BbS1aVopPtU
ErPkr8jkHap96j8L6faHTboBY2uTqqpIMgkQ7ugpezhe6YHmyxvvVGUgsQMH3q3qGnSWMwh++5UN
8vv2xXS+K444PFwjijVVW4gAXgLjjPtVvXvs0fjGwcNF5R8ncQQV7Zzjim4w7i944ZradV3GNwPU
g0gtbkjPkyYxnO09PWvUtSm0xodXVmg+W8hMeCvIJGcetaN2lp9h1e5hERiS0VY8Y4JXn8aPZQtu
FmeMAVoaNprapdx2yZy7AEgZ2/Ws6RsSNj1zXd+Dr+xtNPVzJHFdC+DSs2ATDn+GlGMU9wMDUtAm
tdQlsoQ07x9kG449Tiok0O9WeKKSCRDIwA3Cu5tNY06LWNZk82Mi7gxBN/CDnoTjiqOo6ns+zGa9
huPLfd+6wNoz0zxVNRAz/EHhl9AS3PLGTaffJ7DFPvDqQtB5dvMFCAucfdGOpq/4r8QWGpS2N3Fd
K6wtDutv4vkxuzRrPiiGdr6S11O0jhliULAIf3/T7h4qbLuVscumharcxCdbd2RgWDeoHUjNXNB8
MSa1HdOG2fZ0JxkZLDt7Vf1DU9L1S204i/W0e2t9sior+Yzeilfl/OqvhnXrLTv7RguJXSO6Qoso
zu/3j7mkrdSWYcWi3t5LKkEJk8o/Njt+ND6BqEVxHBJburycqCOo9fSum0TX9P0uz1K0F1tec/ur
ho934+tPs/E9lbXoe5vHuwbcxiUp/q2I/hHpV+6IzfE/h+HR7HTZFXEsyHzOnX8K5E12HinXrLVL
a0ihlLtBkEnvzXM3IsVt42hkkacj96rfdU/7NRJLuIpZpuaM03NZgKTSA0maTNIY/NJmm5oFK5I8
GnZqOnVVwFzRmm0tIBc0ZptLRcAzRTaWkIWmsaCaYxpgNY0ygmm0EjqbuoJpuaBEgenB6gzS5oAs
BqXNVg1PDU0MmpDTN1LmkIdmjFJS5oK0FpppaQ0ixKSlFI1FxBmk3U2ilcYM3FMQ/NQ1MT71NCZb
60tNFLmgkKSlooABThTaWmA+lHWmZpwq4jO+8L6rbtoN9o7ssbyv5iu3AOKh8Ni3s7qbUJZ1X7G5
KxZwZT7eormdM0+71BmW3UnaMsf4VHuavWmj3l4JzEd/2fO8Z549PWtlfyC52019ZaveWmq+ekDC
4UzxM3QA9af4puLXUbiSb+1oDFGENvGCMsQe9cja+Gr66hWb7iO+wbzjLH2rQufBV7bJJ5k8ANug
Ypu5wf507y8hpnUS+LbeDV9L8u5/cLCFmweAdvftXI3V7a3fiFrgTKsK3HmeZ2IVs4/GpR4G1Ux2
ThAy3h+UjkKPU/5FZlxoMtvqBsJHVZAcFu2alqTGTeLtYj1e/aaP7oAUe4Heuft22TRt6Op/Wrmq
6XcaXMYphg9R7j1FZ8a7nA9SBUJaiZ6q3jOyXxJBdmZzZ/ZGiwOhk8oDp9e9Y9n4htLmGbT9QZvs
Jld4ynUAknA7+xqRPhvfNeWVuZB5bxmRpMcL8mdp/P8ASucm0S5E0iwo8wV3X5RkAqxHNXyz7iud
nB43t1+2RtlYfsa21pjkjYMAmsbT/EsVvo9/YzszSXLhkPXge9Y1tod7c3kNrs2PIwGGBBGTUmve
HrjRJTHKQQDihxkUmVZb61NgIBbgT7s+fnt6VmZpD39q07PQtRvYxJDbs6How6UuVkml4f8AEUWk
aVf2jxlnuhgHsK0U8bRpbaSn2cM1kcHd3HrWAnh7UHlaFYX3r94YPH1p1x4dv7QxCWJgZThMDqfS
q5JDTsbN740W902exEOFlcsxLd89apah4qF7p1lYfZwn2YYD7jj61Dc+Fb20i82R4gAMsAwyv1qW
28G393FFMroVmB8sDq2OoH0pqE+47jdI8WzaXbG18lZ4/N81FJ+5J/eB71di8cXcWpPqCxRh5I9j
o33W9zVW18I3DieSZo4IoX8sySHgv/dHvTm8HXT30doCA0q7kYjAYf7PrSantcOYt3PxB1aeNkBg
j3MD8i84XoPpVeXxrfywzQtHFi5G2Q7eW4pl54LubSFZlfzszeSAoPMnTaPeukg8OR2Hhe+N1HGb
kYYd3j46H0NL2cnux8xyr+K7uXTRpnlxiJCcHb8wzVXTvEV5pUTQRFXiY5aOQblz64NbPhLSVvI9
WkxG/lxE7XGSBjqKp6N4ZGs/a5PM2LAxz9M9TRyeY1Ixb7Up7+YyvtGeAFGAAOg/Kksr2eynjuIT
tkjOVPoa7D/hAcXoh87EQhExfqdpGeO1Utf8MQaPawXCSFxMflyMfL2OP51LhJCuZreKNSMt3M03
7y8XZMwGCy46VDB4m1K0QJFOcLnGQpIz74zWbLGfmI4A/M/Sq+DSvJdRqVuhpW+vajbu7RzkFzli
QCSTUVzqV1dTCeWUvIOjHtjpiqC9aMnNLmuHMadzq99eOks87yOnCsTyAPSkm1q/uE8uW4kdP7pP
FZ5bmlzSuvMOYsx39zAhWKaRFPUK2BTrfVLqAFYriZAeuHIzVTGRTApoSuwuy7/aNyHZ/Pl3N1O4
5P19ajkvJ5sB3ZgOgY5xVbGTSlcCiXkA8Pg5qWS6nlADSyMB0DMSBVZTmnN7UkropEyXEy8CR8eg
YgVq6R4iutK3FEikJYNudcsCPQ1hg04NQkFy/qmrT6pdvdTH945zkdvTH0qp9okPVmPuSagz81P6
0cvmS5MlE75ByTg5HNbU3irUJbU2xMaxsAG2rgsB61gE4oLfLRqh3FLVJGx9TVbNPR6cbiL63RjH
BqGW7eTqarOaZSk5BcmLk00k+tN3Cmlx2qfeGO3HNLuqPrRT95CY8tzRmmZpM0a9yR2aaTRTTTAK
bS02kAUUlLQAUopppRSsA+ikopCFopKKBC0tNpM0DHZozTKKoQ4mo2NOqNjSAYTSZoNNzTJFNNop
KQBS0lLSEJTs02imSLk04NTKKY7Eoen5qvnFOD0hFvFIalIqM0G1hEXmldaUGgnNDAhKUm2paQ1n
cCIrxUI4arLVWP3qaAnHSlpo6U6qJHUUmaWgYUmaM0U0SOFPBplKKpaDPQvAt1ANB122LKLiVP3Q
OATx2NU/CcFyuos5l8qK3+a7JPVV6rjvnmuTtDcGRUty5kboqZ3H6YrRhttUZ5kRZd6jMwGc49ZP
/r1tFvsF0ehazNHrM1re2MmLGOeNWjBC4IbkgVoeOIru9uJ44beBEjiSRp96gnA5Xg815laW2qTR
M1uszQo3zGPOwN+HGa1X0PxD5RaSK+27N3zScbPXBPSru/5Skz0iLxD9gGgQZQpNbqjjIO04xn2r
hvFLLceKCIWXmVDuzxweefpWE1hqzJE+yfYx2xsd3J6YU1Xn02/S5WCQOk7dAx+b86hyk+gG74/v
be6vohCwfy4VViCOoArj4OJFz/fX+dT3tpc2shWcMH77s1UXOalPUGe3DxQLXXtKtxPEbeSzTzGL
DCnZ6+tZEl7bXGmalFZzRR3P9pswcEDcm7sfTFcfa+CtWuoYbhRH5c3+rYyAbvpzWdcWdzZzSW7M
d8bbWCnPIrS8/IXMdvr2r20WoaU0Mo3QrF58i/3uM9Kh8bXMGplr6O4WRcLtQN7YJxXDMsmdrk59
+tXb7S7iwgildgVmUMoDZOD60ndjuZmRtb1zXfaNq9vZeE5Y/tAS78zci/xADoBXM2nh+4utLm1J
SPKiOCO9Z0dvNKSI43fB/hBP8qqKaRN9TtPDXi4Q/bxduQbqPYsxGSvH6VT1DVll+zL9umuPLl3M
xXYFGf4a5tbSYzJCyMjswG1lbOPXHWtvX/DJ0OC3kLFvOQNg8YJqXKS6Fpo1NS1rTJ9Plh3yXMpH
yfKU6jGGPGcetdLp+o2unaD4dvZcqIPMxGOS2c4zXkJOBXV2Hh7UtQ0eW8eeTyoeI4iflxj8hTvJ
iuXD4strnTrqyuFZRLdGYMg5AzkCpZPHFu2v2V6Im8i2jCAfxHC45rkLTSL3UDJ5MRYRttdh91T7
mo77SbrTn2ToUJGRnuPUUNS3uF12OzfxvaNbxRCMkpfG459M5p+oeN7K6t72LY+bpc59D6VwNsga
VVboWA/M12HiXwcNOit5rUNKjRK8mOSMjNNQlJX5g5vIpeHfFcOhJeI0DSm7QpkHhQfWk0fxWdHt
79Fi3i6BH+73qHT/AAdqeowi4jjQRsxClmHX0+tN03Q5P7YSylUMQxDJnr9PWp5Guo02+h0dr4xN
5eW20C3C2XlNv79u9T+N9Ss5NK0+2idXlUMW2kHHPeuZvNEaXWGsbZSj5IC59Kku/CGoWyb/APWf
vBHwf4z270/eaGZMmq7rL7GLdMbt3nfxk+n0rKYntXYXHgm5top3eVf3CgyYGdrH+An1rkZBtYis
ZR1KI1JzyKfxXQaR4WfUdOOoB8D7SLXYOSC5HzGrv/CHbdbOleaWYx793cttzgVUaRLRyRANKRxX
Tav4W/s2xF3v3DzTH+IOK52NN8iJ6uB+ZpuFuwXY6G3mlXKRuw9QpP8ASnxWFzNnZE7dshSR+fSu
7124PhddNt7KBGWaHfJ8obcxHTdzWj4TnjTQNRnnURgXm4/KMrzyAaaih2PMRZT4dgjYjOHOPun3
ps1tNGqs6lQ43Ln+Ieo9q9OintNV0/xPdw26xowUJwM/UfXNZHjOGGHR9ECIFP2FN3r0zz780pQS
QHn6qS2BWj/Y2oeV532eTy8Z3YOMetVLdXeZREMuSAg/2s8frXfS3N9odjcW94XudRuIcNDsJjgi
I69ODjmpWgzzxvlOKfBDLcSCOJC7t0VepqOXJdvrXX/D5IPtd+0gUyrYP5Gf+ehHb3paPoFzlJre
SCQpINrr1XuKaAeldx4a0e31KTUbi+5aDcdh6ls1NJa6NdapoyQwSYlk2ygghfQ4p8l+5LPP2znF
G1/SvQvEh0O0uprBLHZc28ybGx94EjP1q94gOh6RFHbtYA/abdCJAOjsKPZeYHmAU0YNetW+iadE
2j2wtUeOeBnllP8ADkdz2/GqenaZpltpmq3TWscwtr4rFkjLID2o5VHqM8wOaQGtLW7q2url5LaM
RRn+Adj3qhatEHzMGKdwvWpk9QJrGyfULqG2jPzyuEH1Na+q+FxpLSJJe27yxfejB+YH0+tRxala
RXNtJp1ubeeOVCHkfcCR6/jXV3UbX9jrFxq9paWl5tBgkiYFpH9eOefemrCOMg0a4urCa8hG5Yfv
qOoHr9Ky+ldz4Su4LHRtYedlAmh+zxgnlnPYCuFY5Y/WlKwCHrSUhNJuqRDs0hNNopXHYXNFJikN
IQGjNJRQA6ikzRQAtLmm5padxC5pabS5oYwzSUUlIVxaKbSk1QhpNRk0rGmUhMDTKfTTQAlFFLSA
TFFBoFUhBQaM0lAmBoBpKbQA800GkzSVLJ6m0y8VA1WTUEgpmxFSZ5oJqNutJgS5pM1GXphlqRkp
NVifmpTJUYOWpdQZaWlpq06rsZsWjNJSUILsXNLmm04VQDhTqaKeKS3A7r4dQW7f2xJIqmaOyJhJ
6hj6e9VtGur5NWZYFaRrtys4b+5nktnoMVzun6hcWEm+BipPBx0I9D61oW+tXttNLcRYWSVSrHHY
+npXRCXkxpJnoOvRHSkih0pFFq8qNceUc/vMjIOO1aHi2d0itxam68+S2XhNxTbjnIFeY2uu6lbp
JHGzFZDuYY3c+vStJvGGvSL1b7mwHyuQvoDirc12ZWx6NYawlhpOgLcQhxM8SfMvKPnrXF+PS51+
UwZ3naU29c57Yrn5dV1SWOFZHk2wvujznhs5qvc31/LcCeUuZuNpIOfbANTKV+g7o6b4kPbm4tBG
VLfZk37cfe2jriuEXqtT3kl1LIWuPM3Hu+Qf1qBR3qFdvYTPU0u/sfgfRt8RdgzqDnmI84Y+lZXh
e1juEuNUndJGWZU8ljl2UnlsHsK5fzdWeCGNhdGGQ4iXDbHP+yMc1EVvtPkKHfCw6r0x9RV69mGh
0vjizt7XUka2C+WyLyvTOBxV7x1HCmn6Q6KAzWa5x64rip7y6ucebIZMdM9qfcy3zoiXDSlVHyLI
DgD2BpqVugjtfDpH/CEamrEAmQkA9wKsaM8UGhWcttHHJdGX51JHT/az2rzxLydEMayMqHqoOFP4
dKEuJkGEkZfYEgfpTdZvoNJHo1nc2suoXsl8bYXK2+IVjx5YbHTPTNU/G2owXtpYKsySNGgDhTkg
+9cDvlZuG5+p5pWWUDc3T1zSk5NBoQO238/616H4Y1aObw1c2U10sMrXQ2lj/BjpXn5gkIzg4pVg
m7K34A1Kciep32l3lqPDt1YxTpHcDUN5cnaWiU9c+4rN8a6paX91b/ZSGEduiO4/iYKAf1Fcp5Nw
x2oHc/7OT+H1o+y3O/YY334ztwd2PXHWlLnZd0OicLKhPZ1P4A16td+L9JEbsJVkU2IiEf8A0124
/SvKHs7hE3tG6jOASDjPpmt3TPClxe6Vc6iW2rAu7b6j2zQlUsO5st4os18PW9nDK6XKzGQ4BXHP
rWD4f1oWWrx3t2zOFY5bq1N0TRP7VNxlnCwIWO1M9PU9qqWukXV+8ggiZ1jJ3MBwo/2qaUgubqeI
7ZPFC6nGjtCGY46HkVrnxpHJCI44WDvqYuFDHoM1yDaBqCXCQCCTe4yox1HqPapLjQr6whE8ymMZ
wCfX2qnz2C56JrV9AdG1WWZ0jluZU2x7hk+4xXj8rjzCfepbieaQ7Wd2x6kn+dVD1rnd7judfoHi
ePTtPksXXINwtyCPVe1bugeILbVPGEF6SIk8sq5c4AIXrXmlOWRl6Ej6VSmxHZeLNfjuI10yEYit
ppGBHRizHNciJdjBh1Bz+NRPIW5JzTM5pNtjOpXxjOYo0mghmeKPy45XGWVcYqNPFdymly6cEj8q
WTzGbHO41zZOKAeKabXUOY3NO8S3mmRTwRFDDOQXjbpkVHquv3OrBBPjEabFUdAuAMD8qx1pW6U5
PqFya2uGtZkljOHQhlPoRW9N4w1OXzCzRFpU2OxjG4jGOtcuCc07JoUtB3JGbcSfWp7O+msZfMhc
o3t3+tVM0gOaXPYNDVi1q9glkljlKNL9/HQ/hTn1y+eVJjMfMj5VhgbT7Vld8Zz9KWk5y8yfkWrr
Uri7m8+ZzJLnO9vvUt1qt1ebfPlaTZ93Pb6VRZaXbip55sC8NWvQNv2mfaOMbjjHpSf2jdhDGJ5A
h6ruOD9RVTjFJQ79wuDNTc00mnA0DFBI5FStdXD8NK7D0JOKjpDRqIkM0m3buO3rjtn1xURNFNzS
YgptLSUgFzRmkpM0AOzSE0lFAMM0ZpCKSgkdS02lpgLS5pKKQx1FNooELmlptFAC0xjinUx6YxhN
JmkNJSEx1NzRmkoJuFFFGaAuJRSUlO4C0maSkpEjs000tNoAKKSjNAjfNRSYp28NUExxTbNSNqY1
AOTQxAqGyiBzURNStzTcCpAj5oXrTyRTM80IllpOlPqKM8VJWqZIhNGaSloELmlzTaUGi47jwaet
R09auHL1Fqdf4I0mDVb2UT4KwQmUKf4iO1Pg1CK21eSR7dHR2MRj28BTxlPfjtWLomszaNcedF/E
NrD1U9qvwa9b2+oNfLbK4IO2N+gc/wAX51sppDR2epWFv4btC9vD57Xm1tzLnygT932rW8QTxaZp
1nOhhDyWoHk+SMuSOvTNcJB4wuVjnFwgnWU5UN0Tn+H6VcufHUF0IPNsYnMEexNx9qrnj5lnbaQN
Hk0LS2v4kXz7jh9oH7zdwCetct8QkSx1yFoAqhVQrgCsK68WXVzZWtqI40SGfzkAH8Wc4FVdX8Q3
Gr3Mc9xGm+MKAo6Hb/eFTKa6XDQ3/GttCbLTrtVVZLqFWYr649q4RT2960tT1u61TYJsBUGFReFU
D0FZXes1J3E0e66Zf6fb6f4Zhu41Jljg8hsDiTtWLrGkW0174gv5UM3kTjZEO+R7elcEfEN/LFp6
Nk/YMeRgHjHTNWG8T6ojzSNJg3fMgI4P4Vt7Tuhm7rGk2Vgmk3sSAefsLRfwjnpVr4kbZZbRooQI
/syZkQDbnH3c+1cZfa3eX4jEsmREMIBwFpJ9W1Ce2WGZ5Gix8u4cEfWlzLsBlgfeA6A133hjT9Nb
w/eahPbea0UuBx27/wBa4ZIpHUuqMV7sASPzq5FrF/a2z2sUpSB/vRjofrT5vIR3mgf2Pqeoajdt
aKnlwqYoePnYjnaKo6zJFJ9hA05Yf3/U7f3gyflI9K4iCe6jbMTyKf8AZZhVu9j1SFUe6SdQRvTz
N3T+8uf51LlLsPQ7m+xNp900SQwbYhvR41Kg46qU5q9oNrb/ANi6BO8cW6W4dZXIAGzPfNeVnUbo
xsgmcK3BGeDXSRa9fT6ILCG3/c2/zNMp5Un1NEZdkCsdT5mn/YdZXTDCt22oDy84yYMjlM8Yp89x
p8fiTRi7w/LbgXT8bd23+IjivLDLKGYhnyTycmmM8x5Zm/M03Ve1hqx6tqF7pNxp8qSSwlV1kbVX
GfK3dvarV3q+mC01e2iniEctuotEUjoF5BHqa8fUu5A3NyQOvrWzqnh+90pITMdwmjEikZ6GhTlY
d0dD4HvrO2XWPtM6Qh4HVVb+MkdBS+E9XsbK11ZbiQR+cD5We59q4ZIJ5GwqufTAJz9MVYsrOS5u
UgDFGZscg8fhReQXPUIvEunyX9iYv3rJprRsVXOHIqt4zkjXw9peHBcuxZf4uSfvVw7JPpl40cDm
SRDgFBk/lTr+fVrmIG5WQxg8FlIGfbihuTWwFVo7H7A8hlb7VuwI/wCHb61jN1rWk0a+Kl/s8u0L
uJ2nAX1+lZTLg1g009RiCir1vpd1cwfaI42aLeI9+Pl3t0XPqfSp/wDhH783X2TyXFxjPlEfNj6U
1Rb2JMgmitW+0C90+ETTxlUJwG6jI7ZHes6KLfIif3mC/maTjy7gIB60u0noDXbz6NpGhQ2sd4jT
STx72kz9zI4wvfFanhrw7pWoaZPcmBXMdxtDO4H7vPXn2q4wXcdjzH5h2zSFs9q9Nn8OaK9vrU1u
FkW3C+SVOQG74I9KxfFekWlhpelzQrh5rYFj3Puabiktxo4nJqTDEZpIWEcyMw3AEEj1APSvSdPt
4NW0nVJpLW0AW33W6Q4MqnH3mA5FSku4HmlCnnFPdcMfTdXUeCtLt7w6ndTrv+wW5lVMfeNTyJiO
VO9DyMfWlDd66zQ/Dq+JHvrqWQQxwfMw6DmrUnhPTG1GxtoLpXW4+9tOSpFUqT/mFdnElie1GSeo
IrttY8N6PYbY4bovOtwsTx5GTlsHFW9X8KaFpiyxPdTLcmJXj3D5MuOBnp+dHsn/ADDPPs+9Lniv
RrXwdYCW3sJt7TzWZm80fdU4z06YqOy8NaN/Z0l7eeaFjuGhJXpgHGfak6VuqGedEYpM1oavDbQ3
sqWr74Q3yN6iobWGKV9skgjX+8ajYNAtLeS7lSGFTJI5wqLySfQVbu9FvrNS08LxgZzux2/GtLSp
7HRNZ066s3e8aNyzRhMdula2r29rqelXupxJcWsiTkeVLJw2487QeuParT0A40WNw0H2gRsYs434
4qoa7vQ9h8F6sZsL+9Hk7+CT321wpqJCYyig0opWEJSUppQKLCDFAU1MiiphDxmrURFTYTQEJq4i
qGwcD61dSBWH+sgH/AhVcnmK5keWRTfLJ7Vt/Z4x/wAtoP8AvrNNZIB1nh/CnyLuFzI8pqURmr7N
br/Hn6Commh7ZP4Ypcse4XZVKU3FStMlRGVaiSQDaXFMMgpvm1IyQ0w0wy0zzKYm2OIpMUnmU3zK
Qh2MUlN35o3UAOpppu6jNADulGaYTTc0E6DyaTNNzRmgQ6kNJmkzQAtFJS0AaIcih2JoxS4pGxCK
ZJUrCoXqGBGxwKhLmpmBNMMdFgItxpU61KI6TG000J7FlBxTsUxG4pxaq1MxM0ZpKSgQ/NKDUeaU
GmBLmnA1GKctOFr6miN/wzox1zUEtd23ILE+y9a0Xi0a21ZoJkYWqEo3PO8cZzWX4a1k6Hfx3WNw
GVI/2W61oXEujXWrrcvK7WrN5kibTu39cfTNdKcRHRN4bsNJgkvrzE9tcL/oCL1Ge5xW1Lomk2+m
2t59hidHty7lmw3TqK51/F9neebbXUZNmq7bYKPmjx0NXbjxXol1Z6faO11tt1YOFVQG9M803KJS
NXRPCmh6rpBkk2wySXGIpC3Tnhc1z3jvSLTQ7u0WBFwEUvjo+PX61DL4qto9L/s+3icbLjzY29Bn
NUvEviOPXXtW8tx5Maq+c5bGM4qHJD0LPi7SLWytLG8gQR/aolfZ0AyO1cbnjPsa3te8Q/2zHbQB
SkNpGEiUnlcDHNc8wJBFTGWoOx6p4XiibwqJt1tC8VzkyzRBiwHOwEg9awI7dvEerTN5SpFGNzmJ
dqKOmT2GfSqFn4pFv4ebRTb53v5hl3cg+oFQ6P4judH+0rGqulwoVwx9KcpagrFzxLoK6JcxxK4c
SoJAfYgVq+KLRYPD+kSo2Ve2/ugdumfaud1nxLLrUsDSxKhhTYNvcDipdS8V3GqWVrZSpCsVqu2P
bgEjtn8OtVFrsB0ng+MSeGNaTC5xkZAz0qDQvD2n3GmSalevhRJs2j647Vz+meIrvTLa4trcx+Xc
cSbhkn6GmWviG8sYTBGVMRbdsf5lzn0q/axW0STqY/Dul6jqKxWUkiW6webISCGyOwzWh46WEaPp
nkghFtjFgjkdvm9/auLi8R6gbjzoWxJjGI14x6YFQX+vajeRfZ7iTKBtwUgAg+1S53Ww7oymTGfz
r0jwk0EnhPUtttG8q3CL2LOMenWvNyTyeeauWGs3mnRulvIYw/3qzjPlY7o7HRtKhtvD+p3ckKT3
q3giEMmGKIDyQvtVTxvaWdsNOMAVHmtY3lVezFBnPpzXLJq17EXKTuvmHL4P3j6n3NQT3c922+WQ
ykcZJzjHanKo30GrCwnDjPZh/OvbNTS0vrWGGfyzD/ZAZZCRw4XoDXhm5hU/9oXezb9om29Nu84x
6YojUfYrQ9M0+8TTPCsNzHDavMlwR8+zeY8n5sdcVzei38d54mtZ5VihV5ct0CAfyrHs9E1XUIlZ
AxjfhN8m0Of9kE81RvLefT5mhlBSReCuelNzkGh3ySWcPjlTJJGLbzDlxjYFPqelbE2raQ1owmmh
fbqwOxfmPl7u2O1eVWUU1/MsMYZ3boOtbcvh26sVExngJV1BVXDbWPQOO1ClITPR9Ue3fS9euI3U
qVUR9sIV6fU14q5G416Re6Nr81jLC1za7TCJ3jUbSVA4+vFc4/hC7VtOVmTN+fk9hRODmFy94X1q
zt9EewuHWN/7RiuVLd1U/wD1q6DR7+31Px5HcQOGjdD+YTpXn9/odxZ3s9mgM7wtg+UC38s1VS4v
dJmDxmS3mXocYYfnQueAXOy8aatZrpSaajF51upJCcdOfumuCWYIyuByrA/XBpbm7munaWVy7sSW
Y9ST3NVt1ZSfM9Ro7u48TaNrENvcX8ci3FtHsCIDtfHABotPFFjbeH7uyUSJPPMzoV6KvYGuE49R
9KX8TRfzHc63QfFFvpmn3ljOjMlz1ZeTn3qLxJ4lg1mK0giQrHbJtGeCa5bvStiiT8xD0YLIrEZA
Oceoz0rqbTxZbWEN4llZeVJewiN2L4VeMEgdq5LdSZz1pJDJZXyTWhoetT6PLI8XKyKVkQ9HU9jW
SRRmnfzJudHpviV9Oju7dYUeC7fdJGeMYOQAfQVLbeLJ7S/hvYra2BhUqkeMqARjJ9TXLAnPUfjT
gxzjIpNvuO5q3mrTXuoNfOEWRpBJtUYXOc9Km1vxDc63Mks4VSiqo2cfd6Vi8+oP0opXfcVzpY/G
epxqMOm5Y/LVyuWCYxjNVv8AhJb4adLYbgYpGLnI/iJyTWCDzSk0MLj91G6os0ZqRFy1umtpFkTh
l6Veu9evLuHyHf8Ad53bRwM1ig0/NMZbk1CeSJYi52L0XPy8+3Sqhak6UwmqJFzRmm0VIXF3Ub6a
aSi9gJRKRVqK44xVClDYqlMGWnYu3BpjiRe5piOQRWwkUc0I/vVXxEmKZH7k00sfU1burVkOQOKq
EEVLTQ0xuT70m806m4pCE3GjdSYoxSYrBmkzS4pKkYlJRRTAKaaWkpkgDS03FLimMKM0hopEsKSl
pDTAKSlpKQWCjNJRQAoNOplKKBdTX20xqfmo2qLm4xjUZFSGomYCkIMUEVH5gFNM4oGS1DJTTcVG
ZNxpxEToakqOOpiKuzIY2ilooQgAp4FIop4qhABUiimbhTlanEDQ07T5dRuoraIZeQ4FbM2gW1nq
UdnJc4U8SycYRvSs/wAM6qmlata3Mg+RG+b6GtrXltLzWFZLmPyLp97SA8RhuufTFbrlsMuJ4MWK
W6e4m8uyijLx3JwBKccAZ4P4VpReD9HTT7K+klumS5JBK7dox3on1vTbuD+xJJvLtrZCYrrO9ZHx
0PtV5dZsX0Gw04anaxMjsJcr0TNPmj5FpIq6R4Fg1e2u57e4OI5Cke7vj196zPFXhSLw+lsS5ZpA
C4P9Kv2/iCx0jQr20t7omX7TujYcbxnqPaqPjPxHbaxDp6RyeZLHaqJfZvek3ALGfq3h6C20u31K
A/u7jjB67u9cvwK6rWtdtm0Oy0uAlzD87N6Me1cc8hNQ5RuDseleEfD+najoct3JAJp0uVjyzYAU
np+VUdW8JpNrl1ZaeBxFv2NkAccn6fWmeGPE+nad4euLCdpVmmuVlBXsFx/hVpfG9n/wkM+pNE/k
m38hVXG9vlxuNUpRYjKuPBd5AbRUeKYzyeXtjIO096cfBMhFwEuY3ktVzKgU4X2zjHFU4vEAstVW
8i8x40mMixu59emOlar+N7ZP7UeG3kSXUhhizfKD9KrmghpCR+ApXaKPzQGktzdDHQcdKi0rwdJq
FrPO8gWOKbyV9WfOORVi2+I7wrAWtg0sMRtQ2cDbjrV3w14h85JoZDCkTXwl2u2COcnmmpU30HYP
D+gRaR4ss7RgJQ6lnyOOR3qDxJ4btzDc6hE4wlyVYAcdegpfEHiWK38U/b7LZIIYwo5+UnHYnrWJ
f+Lbq90+ewMSIk0xlJAPBJz1olNWtYEonTeJbLS4vCukvDE3mFCcquWJ7lvavN+iE+9bsXiy+jsR
ZERPGqlVLJkqD/dPasI7mzhSRWF9dhuKOo8O6Bb6lo99ey7mkt5Y0VRxw3UmtW98M2Nj4msNMUHy
rmJCd39515IJ61yWl61qGmLLDan5Jsb42XcCR3x61t6f4gvH1ixvtRWSU27rgLGS2xewGM8Vonf7
IJRNfxB4c0+z0S8uYovLlt73yAT1YAlSf0rzw9a6rxTrlzq88/leatk0pdUK4G4k53e9c59iuWQy
LBKU67gp249c9Khqz2A7bRdMutLsbTVZ457uWX5dPt03FYyR99h0FcnrrXM99K9yhjmJJdT2NRrr
+qxqkSXlwqx/dUNwv09KW1s9S1uSR40kuXXl26ke5NDblsmPQ3Ph1d21nrDtcFQGtWVWboGIqTUN
K1GHz7ky7Y2uQFBb/WZbggdwKwU0e9S5WDyn848hAOeO4xWhNo2shEZ1unXeIx+83Yc9Fxng0KFR
9A5rHb+O9cl06G1W0MZ+02SI7qclflGRxmpFkgvX8J3azx7baP8Af/MPkPOc81xUnhbXWnW2kt7h
5WG4KwLYXHUnsKrL4d1ZvNWON2WIkNtJxkdQPXFaLnQrpnX2+owzajq5Wa3aGS4+VmYRy4z1Vj1F
cl4wMT337u5W5XaPugfLgdCR1qhp2k3GqXy2MbKszZwGbrjrj1xWlZeD7y9vrmyhaN5bfO/B7jtg
nNKTlLoLQ5Z81Hg10moeGb6wtDczx+WolMeCO9YBHzY681i4vsVciwaXmuwt/BLSLAJboRTXCho4
SOuenPvXNahZS6fcy28yFHjYqQfbvUuNt0HyKeaXNWLWxuL19kETyt/dRSx/SrL6JfwyJFJbyJJJ
9xCp3N9B1oUW9kF2jOzRWvceHdRtFD3FtLEpOAXQgE1PL4T1eO3+0PaSrFt3eYVO3Hrmm4tdAMHN
NpDxSVAh1JSUVQh24ijcabS0WQ7hmlzSUlJodxc0hopvelqIeKeM0wVKtUkIUio9pqwBRtFMCHbT
SKs7RTGWkwsiCkqQikxSswIyKSpGqOiwhc4q1bXbRnHaqlIOKqLsDOiSWOZMHGao3FnzkVRinZD1
rTiulkGDWi5ZIkzmjIpuytCaINyKqMhWokrDRCVpNtSEU2oGM201hUhqNmpAyOkNGaDQSJSUtNpi
FopKKACkpKWmSFFFJSAM0lFFMoSlpDQKBMKXpSZoNJiNammlPynmkJqLGtxrcCs+4bmrsjcVnTHJ
oKREXNNL0hplIQ7cafGeaip8fWnEReQ8VIGqFOlSCtCGSZozTaKEK44GlzTKWgY/NKDTKcKS3Anh
RpXVEBLMQAB3JrZn0O5tLi2tpmVHnxgE/cz/AHqp+H5o7bVbOWXGxZlLZ6YzXWeM4jd6uj27h1nK
+U4YYBPv2xXRBRsBnr4R1D7abVT91N5k/gCgZzmtODwPJLZpdNexrG0piztJAYHHWuhhuFbTl0B7
kf2mV3Pc5GCpH+r3/SrWnSSQ+GIbVY7d5RcsuHdc4J+/1q+WPkNJHHweAb67F00LrILbOcHO76VR
1bwrc6Tbw3E/y+bHkL3BzXa6DeyaDpet754zcQusijeDuzztHPNU/HOtRavpOmTBk8xozvRSMqT6
jtQ1BdhnHXfh54dOj1BH8yF+N3bd/drn2rub3Ura18JWWm+YrzmQylV52g+prhn5NYytfQbWhb0/
SbvUd7QRSSBMZ2KT1q0+jXsdwtqY385ukZBDc1s+D/GJ8LRzhYUlaQgjcOlTXfjuW41dNT8pAyD7
m0fzq/3a3EjFvfDWqWCB7i3dAxwMjvVn/hC9ZFv9oNqwj27txz0rT1z4g3WtxorIibGBAA9Kmn+K
GpS2f2TYoj8vy+nbGM5obptAjhZVaN2Q9VOD9RXa+BNNs7+01N7iPzGhhZkO4jBxXEyy+Y7OerHJ
+prqfB+v2Wiw30dyHIuIig2e9RFpMos+FNJg1TWninUGNLZn2djtHFbVzo1lqOkTSJGkci3nkxlB
jjOBms238VaTpVxDLYW7nFsySlzhnLdqR/GlrFZ/Z7e32h7kTtuOe+SK2jUh1GkdCPBFqkUunmLM
tvbee1yTzv25wB6Uzw3ZWieH7R3t4nc6j9kZmXJ2M2OtYbfEJxql3eiPK3Nt5BTdwOMbqrWHjlbC
wSy+yiXE7TiQtja+cjjvV+1ppS06D0Lj6dBp/jW3tkVDGb6JNpHy7SemK39Jjhb4h3iSxoYo1uiE
x8oUR8YHr2rz238RSxaumpyASyJN5oDHjPb8qtDxfdR6zNq0aRiWVHQr/Dh+tc8K1mnbb2v47Csj
07VLbRrnQbuSzRB5l4qzg43R/PggDtms++02d782GnyQwww2YIicf635eSOOa89Hi6+W1uLQbBHc
S+a+Pvbs54NKnjLUo0VFfDKu3zD97b/dz6U3V5lsVoY18DHczA43b2DY6Zz/AI13HwxkZYNcC53G
3wvGefbvmuAnlaeR5G+85LH6mr+la9f6PvNrL5fmDDfKDxURm0ybnsCfZv7Rs/ueculvv/vK2O/v
VfTcf2WBNncdeBUv94ru6gHtXlB16/a4NyZ380/xA4p0+v6jOF3XEnynIwcYPrx3rb6w0rWK0Pb1
8WsPFCaV5Me3ZITMRztxkAGqks9haXOhw5K+fJIz7GwpJJ5k7fnXiZ1e+877QZ3M2MeYT82PTNMl
1W8lxvuJGx0+Y8fT0qPbsPdO90mKKL4hr5W1USafBGMAH0rR8MXP2LxH4mlZ0SQQzMuSOTkkY9fw
rygXc6yeYsrh/wC/uO78+tPW7nLM5lfewwW3HJ+p6mpdV9A0PT/GOupq3hWwlaRPPE7b0GMnn7xF
eYROBKpPZgf1qNpHIwWbHpnj8qjzUc8twPZINcs557C6jmtfJihUTvIwEqbB0Qdea828T6hFqerX
NzFkI7krnrjNY28+p/Om7uacpc24cx1HhPxOPDM7ziBZiwxhhWnqHj9rzVLW++zxqITym0dfrXCb
qQtUxclswujutc+JF1rsMcbQrEI5M429QDxUmofE7UL6wNkY1WPywg2rjgDHNef5xRuNNyk92CaQ
rHNJSUVJL1FpKKSmIXNGaSigB1JSUUrjFzSUUUEhUitUdKDTAuIcilIqCN8VYzmqAKQ0UtICMrSb
aloxQMruKhNWXqs1K4gFBFC1NtyKQmQU9HKmkZcU2mnYRoQ3PY1K4VxxWUGxVmK4x1q1K4D3TbUR
qyXVxVZxik0BG5qBjTnamZqQYooNNzRmpsIWm0maKBpgaTNKaSmhMKWm5ozTAU02nGm0iWLSUUGk
ISiiikMWikpaorQ2b4bJiPSq+cirOqgrezD0aqYNJtFDJjgVnScmrtw1VcZNZ9SiHFNxV0Q5o8gU
7oaKO005VINXfKAoKAUEsbGKmC0sSiptlaIhkeylCVMBRimIj2UgjqalxRYQzy6UR08U6iwxoXFW
BPMwG6Rzt+7knj6elQ08VSuBIZ5idxkYn1JJP50ouZx0mkH0Y1DRTu+5SJGmkJyXYk9Tk80eYx6s
fzplJQMc3PemYp1ITSERtTCaVzzUZNAXHbqaWpuaKTGhc0oamGjNSMl3UFqizRmmO5Jmk3UzNGaY
h+6nBqizRQFyXdRuqPNKKWoD91JuptJSAdupweoqXNO4yTdTSabmkoC46nZqOlzQA7NJTaM0D1Fz
Rmm0UgHZozTaUUCCikpaAClpKKBjqKSkpiCkooqbiuLRRRRYYopKM0UxBRRRTAcDU0b1BTlNNMLl
zORQKiRqk6UDEY4pN9NfmojmgTHu2aganE1G1IQL1qynSqq1YjNADmXNQsuKs01lzSEVKTNSyLio
TTQWJUlIqUuGFVM04NTbAc61GeKnBBpjrUgQUtBFJTASiikqWK7CilptNEtgaKKKZSClxSUZoELR
jNNzTlagaDbSbTUm4UhYUgkR0oozTaTJOg1wY1C4H+1WWxxW54lTbqlx9RWBKahbGhDM2aiTrSsa
E60mUW16UtNXpS1Igpj9KfTX6VcQY63q2BVODqatitlsQxcUlLSUAFOFIKWgQtLRRQAUuaSigB1F
IKWmhhmgUUUBcWmmlprdKAuQuaYTSuajJoAXNFNpc1LZSCiim0gHZpM0UUwuBoFFFAC0UmaWmIWi
kozQA7NNJozRmk0O4UlFLQUgooooEFFFFCAM0UUUNgFBopKQxaWkopjClpKWgkSgUUUhi0UlFMBa
KSikAtFFFIAopKWmIKKSlpgFOFNFLQIerYqdXyKq09TimBYprJSK1SU7DKzDFRNVmUVVbrUiYCp0
qutWFFIESZppekfpVdjTESs2artSkmm0AJRmikpCHBsVIsmahop3AnYAioWGKcrUMRRcLkWaKQmk
zQIdSUm4UbxQULRRuFJuFSSFFJuFJuFMYU4UwuKPMFMB9FR+aKPNFAElJURlFKJaQrM7TxdH5eqT
H1Arl5TXW+OONR+qVx0hrKOxaIGPNSKvFMqZfu0DJE6U6mLTxTGLTH6U/NNfpQkJiQ9atiqcPWrY
rVGbHCikpaYh2aKbS5oGLSikFFADqSgUtAwopKWmIXNLSYpRQAU1uRTjTSaVwK8gqPFSSdajoGJR
S0lSUJRRSZpCFoooqtACkpKKkY6loFJTGOpDRmkJp3CwUUUmaGxWFoooqRi5pKKXFAISiiindCHU
maSloKFptGaKBDqKTNBNAIWlpmaPNFO4x1FR+YKPMFAh9LUPnKPWkNwvvUAT0VV+0+xo+0e1Ai1m
jNUzde1J9q9qoZdoNUvtR9KX7QTQMt5pc1T85qPOamSy5kUZFVPMNG80AXNwo3iqW80gZjQBoCUV
Msy1l5anAt60XBF+SVcVWMgqAk+tIBmpbKLCuM1YWVcVS2VIo96ZLLTSDFVmkUdj+HNODxDgk/lS
OYvU/l/9enoIjMg9KYZgO1IZIs9T+VMZox60hof5vtTTMfSq7XKDoDUZuB6UrjZaMppvmtVUzn0p
n2g+lK5Jd81qaZWqr5xppmNNMZa3t60m9vWqnnGk8xjQ5D0Le8+tN3H1qvvNJuNTcRb3+9Jv96qb
zRuNVcRb8z3pPM96qbzQSaXMBa80Um8VVzTwaLiJy4o8yoKBQ2UibfTvMqvThUtjP//ZUEsDBBQA
AAAIAHh/UUDWMZYEwuUAAB7mAAAMABwAYXNkZjA1ODcuanBnVVQJAAPEvz5Pr8A+T3V4CwABBOgD
AAAE6AMAAJy9U3BlX/gtumN00LFtdmynY9vmjtGxOknHtm3s2PaO07Gtjm2d3//ce8/Lfbl1R9Vc
a876Vq0aq2rOb4zxtL5Wvj4BKPIm7macbMw83MysgK91gDgAHhYWDhYO/n8DAQEBERER4f+6/Qck
JCTE/zNDQkZBRkb+74qCioqKjo6GhoWFhYdH8jUEUQgAQMBA/G8A/m9AQEJBw/z3WgTEbxAAKIj/
B/+v4ncAJAQUFCQ0FAwMNPR/Fb//agBoNBh0MlZRWAwVEzhyZ0y2wIQCeAqx+n4s1dlrSnZTlyAE
RGwcXDx8KmoaWjp6Dk4ubh5ePvGfEpJS0jKyauoamlraOrpm5haWVtZAG9dfbu4enl7ewX9CQsPC
IyITk5JTUtPSMzILi4pLSsvKKyobGpuaW1rb2jsGBoeGR8CjY+Nz8wuLS8srq2u7e/sHh0fH/05O
b27v7h8en55fXtH+owwJDQ0FDfc/lCEgPf7ne9CgYchYYdFFVeBMnDHI2QLhMcUSCur7ESjYVa+x
TF1mEbEpOXapbv6H9f8m/f+Nc9D/L9L/h/P/ofzVB0CDh9iBIoWCIAdAogGg0ABfawAkKIj/Fv/N
hQE7J8hMVNIDmcCFZEzSCmUXelbVESGTh6rfxdbiaOSlaOp1fv2qvxncMKhFKEpuXTVVJG3E8lVG
yfNWY0isOAsx0eSanTXGGTL8ZaZg0RnkRdvmLaNwi5KZ1RtFH8M9PrY52e+n3Il5xk99EhpxEog3
e9rObVPNB9RvbbQwhhKkPf5QAAU9n0qb6IiuwlJlmq64XszeVH+8y62J3+UN5O06M0yACK5XWbPj
VD6nnPPWtebHIGg+NCGNjZF8NC96I38UeCmujCWItZiQgDT3u6MyGaPXLmpWDq0pNg+vZoxsTh0u
QY4cHwamYebj1ZQPr8uYPeSd6GDy8AXwk1O+W3GcfmfUhQHqWs8H60ZcvzNa9WjYJS6JUMqMLdeu
4yXX/db2dAvIoaRp+9BE7oHn+JpT1ceVjtmLBiQXbHpEfl1ov3QecXLkahhoZQtYEPiJlT5qH0dz
Gdvcpzu+5rfhWsot6SLIrltn+2QruNAv+iabQA3DMzLKbHRDaPPKFXM4hOdbqr/Pr/gFmOvEzIV/
X6X+I2Bbun4IOHZ0NvQrOcMAXqrXHNrVbcYlLw7fUM2Bf7GEXXyra0TR8Ktwacjiri2ZuxTg9iPO
wh5d7LczPmil7tpybGDKjxtzdV6eOsa9BwVcLDc2dTSvFRsQNt71P2DlfJTRrCq0fC/gneatroS0
xNXHyLzwhSN00TlDawjdxCmbhGt2nmax2coqnykdNf9jnm0lKIwfzpaw+Uw/TcexnvxLJ25dPebs
rmB7/IN1rYNrvovNLdbUqKVU2KXqtkXrCiLaeZmzf2xvxzz4fKlepHOwiwLAH7xx3/9Uvj1caO/s
ZvmbJPlHMmg52tgsKXNWts++JsmqtnskXcUkcUvGgFKETbkFdT/y8F2KqmoGieuGUUjdR26fIPL6
m2Z1D2PL7UGaUvS6/uSAEkfd2LHwD+fYh7ia08fM5NTLhIbR8gh+jKGY+G9kJXTk0eH5mafqIdq8
iY4Mjsarw78anlGVA0tizDU9k3xqtoLx9uo43kYvmPdTKIQ72u5kzlccgjpA4kNcuiFTU8s53g0y
2P3YV5tQcYp/lEEmHOa6npann5vUOuS0RlYzTxrd7Bp5Yp3BKtguhZeagEcCP0nbAPkbomJ86Qan
n1G/qHGJJF112Z7L5PGbL8Z8/Uqp0NpJusKuS4v/JEwq5U+VnGJXuXcWxdd+y2vb32p6N9mlMH0D
URg1VltfCkdIsiep2fqTNS2sy+dymS5N5xpTEAS5Pi8NP0U0+bR0tb/9jDleLzYlKoOI3CcRASrK
pR1F1k956om2LIIeYNrlccmBFEKdtvjzEpnn4/bJL9YrmyuuZ1cGOH/cGAhILkia9V+YOKh5+g3Z
JIVSaMKaPRl/fcjOWmiX5pre8CMNNxHn7SoWJzm3vr9JyxCWHGU4W5AXh8u1buIKLD1che42XR/o
BlcxzY+aMSwgebwuPnPygB4I4Hq69IbCXXxrU4SCSpcebOVy0OVMnGLPPOfoA8ckMfMG22YEiAIg
xFX38wYSqnJi0JT55nb+Yh4lYlAbpuCdqf6QjY61+UvO+wVYzCsv+7GJmVhzAG77oNMqEfoNmw48
UJOutmhDy5T1p2sDoZFFJlgPQ/5JH0PGnJ3ii7AjLUxMLeQPhpCATMMDQWOeyqtGZgDW3JgwqzlI
sUhLI/04QiGzm5J3NX9n0G/2bNxpqIL6suJ0qwLLCINxVcRDTRTE6lF1kVb/0YuYDmE12GhlUhK6
2Aiwzy9t8jVCyCMmyl/9VaOY9qpi62IYuNMYNL+mT0IDCtlZdkSJVp60hF5SaYXXoBLuRB7uSw57
o2T4Wb/KrU/vsTc+N/AO61Ll+jjNKVGw7jvPyEadl1SeX+GP7nrh8XBqyqz8wkI3E2kZ70qSnRsm
6d3XmMn4AYJcnAFJQ7fqdSBWvm2BcMXcShvJI41Vb2O4J4aVKIuatYDIpN9r6LmGkWRKCf9KW+b+
OSqCLFFsVtlQXTnl+BaTSMu5irPRDtnmR42DVM075cH1zBL9qmUgGMvb6zmwRPReel/Dd/4edmaQ
2jJxyFJDf/3eG2OhvZU7ovfAiVfWqmtSAyTA3UuNtBc1zbSnKy5WbmY08vJvxpLB2dZdysiOafO/
kFHpf7LR1zxBM5XuWJjmKRXpWozACVSPMMPgybfiZJRJKVE/xgJ+B4/0IYY6pi9sGXEkgn/TcfDE
4z5V1j5lSB3Z+gyt2fEJcLmr5At36mSqPY2ZPCn5ajL4huO6IaEe6uqOtGKDoNFlUdfMIBAu6rz/
rkmGL83/8lFw4SlrgSRp3Jnuel85HTzT42NKzSrf2pZsGZ/ADGC+POdfIs6rWQVyXUuYK12xPibu
l1/C2J/wpaZgXZxHsZNmMgtmYdY6/+PQOXniyylp1KVU+AIwQbZuYVW47erBS5zX76Zo0Rbl0cbZ
DON4W+Q8FJ/wT5Cze8W6/kbWa7qB6VCoSI1PPzLahNqYF+9g5/CBd7jC31KsRlCy0/AT2xClGOqO
FabPk+qO3Lqoyd4tQq4L8OE0vN2fSTn4vKG5K5tk0C8DWqfx5RSrIhW1qRlgtYahE8mpS2pJm4Y3
sJ5oa7IVaz3OtQ8U/066MDB63CxfqF0tEVJfGmL2tlorOUcg/KwoE0XJM+GBiX5BRyIe6ZAWoDP5
Ra60Bbmk134OLuMMs6hYs1EJsNqWJtfGbWJHeeH8u3b2OKQYKhoIPBgYrCBVTr9nre1CxWrJcGOf
xCtUFQtCYeGZ5l/GQkmhWVk7CYdwyTc3j3Ybdlexse7gAmHO57H9HHe4ipM9UDmPSeJNVWpGIsPd
KcuvPoUNJdFfltoVhOEsvzz0MHk031BHUZprn+/nXHmGvbEnUZ2MgvexgxOM9c511hl0mVW8GkzQ
s+5do9eJmmqFK9vdxor6SPJwRJc2dalxQfwCwJ99AZZrdh9oHQX46jdl8Oi87gKXoR/6Pt0K707q
122wTxjl8JolWyhrp1eO8f7ZGjlZ30m0tlFW20yjOvHNC80I3cEjE8CMqfwTlPDw/hYljLSZ7Lkk
kXyxoeXK7O06pXF9ce7dU+bl7Proyfw5eWYfizm1TvyQ1+68MrDoy/eqj60andcscYQWq77ELs4O
ieTA+pQcK1WP9a/jYsF1ePctwpygIOmD1GECIveoxUi0xd7xYswpeDKVVwMW7lU4ZfK3innfrUZT
O5I0Ci5R+71ggLC3ErWqbArS+AoNlKCf7YI9I2N+DrVYQ/GyavVZF2YU3HIrZ1qBtugXAEHjABXn
kmvqtlUEspVCKHfhI37623iCUAZFLp8PvhljcGXdO7I7yA95q8jKzNUKydBgeXIFkDLjvbA0Kb18
PVwswyE32wch9aZTvFOtWn9UkIc7YXZTcX5+1OOMJE755kTPVFnZPuHiovUs1LzhybU1xsGke2r3
kiA8fnPb511eHo31hMHTeQa0M5pI36mtVRrk1IcVZJhtbgNZtf5lRu5dM4tHfsFNdSyvvnCAz53e
0/PRnpSjnpogXgV1F+8n6PKA2wgVhL7JXBYjIOKYrWg5A23NqFIKB8sGlpEJuurkhX3H4aYoXfz4
NJX+FLW23RCqjGG8uLD/2eCRpEGEf6w+JGHVP9piJ8B0yN+ZQwuhRNrroGpuVXCRaAvPcpp0j5Xy
79lqNtNvjIUvTOT/xUDhzNn7WijcGafrHPI31ux8npGOfUSV+63aZ0GhyaNW/Aajbwt3TkyXaIoA
o/Fo9fORf1EvANV6KZMzZPHsyqd0wlimzezZecGyaoV5x6n/23e+4zL/Zs7hkOEagX9rAtExO7GC
XjUdM4OP1HqdbeljVsCwEX9T78BTQbovAFpLTYlDVFtZEola9qEUZBr5JY1ryJr2b/qxeYcW7Ns8
gHlOWdmhyj0b7SiFg2Bj5APwQU5BCCzR1mE/+erx7rOfocgzhRZkY2gUl2/wKBCSEIYrDIKfQkMq
s0UJm+tUoBmYPd2jo3QkZ8jYtN8Y5f9VmWqIbRsFUqXT+1bGhfAFyM2pJGLhVWz+kRaY+U9AdPfM
j+Q8MnrSAWPSeHXHx0fjw2YMdI9M7CDsiZhwqKp+DkcWJytu0EWMigO54Dior5caRYhUTl2l6yl8
gb0nQ0lWnC3xnQiVh1ORa8WKrOmhZJpBS3MeJcv9Mfj415kG4/3LA0JBJFpq8nvvh3esjlC+5kH0
zlxwa/17Vc9CU5aeMGKfWHESQRdrjJPM65LXNdVKoHwjo4scRJJJH8B+9OPY0abWIr/axarUWSZ7
2Wh3CnH8cV6to80JmvUc+ldEg5N/SkbZs42fJjCkM5jwW1fbNO8/1PYTGYkNTVZnGQOYmRDHi+NQ
5KxcQyk7iI3IEreiMYeSrlEjW5OgHul3ulvWlRldNzetT9zYZcmGLp2FpvUGFDjRK52lT/zuXI54
u7UPvoeqA2t3S56ycpAtMqLXVSpcFG0ibXouJvImvRE6cBaYmdwyi0RvfzKfiX+ohZbc7LKpEwuj
ud60z/uE5bKa4a3ahmPWaPIUrnIJnDSOKhh7xJxFmo9nU2pWeIQiYfvea9hMqgmcIMaOY5bxwa8/
1ht8EnW930t/auhFK9e1hieejTeftUdP6y/OYEadIuNYEYdSQMiMrSBgnpaU+JW0BpqOcRrP4wFT
1DCkt7xsqi+rKxzllHYFfb9JCM6cRXeesNy5m8s1DRF6Q6yl2piv/yT2RvzTT/EwVmFtUdrWGncZ
vQj8kf6xOMzLqP0wpfDIIZpqTC8yDaRMAv2cra9qSE8qmNL0Apdgo+kPy9PD8B5S51tSx//eKzIT
neL4C2lZolhYWFF0Sl9IPV02eHfhBvdQMyxqMXqlz5yWbCwlLHtu2htDRhCLwqclT5nIe4i9GlZr
AXHUTjB4G3ni1rlyySOeefSDIPC++rQzU1R7ymxKKtNVzRbWYHJSTYGfIyVn6mdxmWmWqrJ6gt/u
Q/nJTTbbh81uOzp3vhgmfrJbaT+zGaFaR+Zp7IhdKyyM7DanZmR1LqDyJ5vGi1k52qd3fCpDNH4M
hUBmVXhzgux5NX0LCUesjjXEsvCpomBFwz/VtTXQ5FR98aGxsGfF1X15SfwF3knC+1n5jfnsKRef
32I9sbr7Hg1R/9M7kCMqIvoXf6A9dEVE17mJGo2jIMlcxzdhhMknIa11Cq3bn2FQ/JJ8hOqfmElv
iJMz/itysy1YZ2P7Hi0MRiJNiTNabZZCxp54aTRXkDy4HPqgyf7d+Cv8knG5rv3A4Ey7XMwuqXj3
aCuh5hKIdnxQ0wXqaqFXC8Qlqr6WZEdE5pVaszEXGI/09UZxUoFiqmD+MGfVTJjt8dI/hbCg4EUv
iEFNLPkL4CDRv1KzHmfMe6b+LkfefFAqJPl48lCQr0nLbJlCQZjGLyU4BZzYjVHeIAhgsFzYzPXC
ndnXcWeWLDD5AhhoCed4pz3Wp2l2zEd7kcPS7vwisP6nKpA1YX1AtxAcS3+gwh8P4D2H0z3BZrA1
oCdo27uzSLXcHJGN2TzVq20E5pK13OIcuEuSPtLgVRzWZfJcSFBG28WjnfcFvy4JRJDSt41cZuBO
27bfHGTV4qWSpEEdg0k8lkucbh0oWZA89ROSYlOQ9dFUVKVS5i0RrSizf0HfvKgHu7j1vds2X2+m
5GzFeXlw1pvZ7OefsgwGq550SIZVn857seZR434TsD+FK1sqAet56S8XDKTF/zKb6YaaNrfipe31
fNXSA/UXMNWQB0mXoOCQSetbLZX5CcvqURysVln+2Mpj+SikBm8J3sgMQ/L0Coav3yXEqc1307Ma
ZcjgXuWmLFl3cKZsJbl5//NY34C+H8911sobwO5d5+bqdce1F1owO1XE4fcPK6FSmrTPFt+U38Ax
2056/duov9Pwkk6YCn1zlbs4f4pPlTE7UgGZrkuQRzMuiIJqVGKDCqfNcWbf/V+StxuepHkWhUr4
AiyVnQ8cI3/b5I+jy8npsKdxfjVLUiPI+kfJy1ad3n9wBfWybLGrgMjvZc98aBdBY11IxLrOUx2A
9rP3OkmRhcuv9hrKQ7fGiKV9pqvVnpwd7ylWvZHV0c7qvmzDhtuldJXGnTh6Q0tub5NDolqPgj19
fQwaIjbfW33ZH7kF8kQjJxMXev8te875WzY9tgQPCd1OPOqZFvlCrbEMGpWbjiSh6x2q90m1AApV
5Fj08VSnFimMPoBfi7Vy3S/y0hrTt3wI6dfOEjMU5ulT7aFDzkzSZ21e+31F2XLzt/RJF33+gtP2
nf1l3GoXBYiZ61sgKZfZjVCFPfFQegghADBzvJTfsMR87rB2Scc1vjrhZ8vY4z2fUvl7EX9xTj8r
5wvQ1X8KQfiwFwXyfrzkjNjwspFBxCFs9R47jOj7xy7LA24fpjzoCKpvxwmvKWq0taswzHlyPVFq
uWFaQAMTUKpVWzEcIe0sobDZiPZVud7h1cOFX4IyD4pqmPVchybeuha8e9pdqzhU5Von43B5Rl+8
NY1L646KtBbg8PDa7bBHD5yzNaeL9rw4re3JPFOw/8L3jSiN80UOluzlbor8uxAwcLa1xaoLpbml
vGO6+03xxLCxeEFgmHr6pJxk0SR29WHuIrRA0YNqsy+i8tffd77Vj759hSgutplAbz0KDYVgolnC
lMDDIaMSvzZcTXWeibErgWT1N8GfjJld/UGHGTUl3Vwg/Hm1gBFR3or40BxnsgRGtiO0Wa3N1vVS
8dOWVA5i1K+2u36pl6KXxjsf78g7fNpj03rQXtSfjiXmozgyXbU+u0+8vk8N7IiKseJtKY/fP61I
8SenaTcztfBWbYRoWjvnYfJDUlJ3Nhxo2osXuuSsKhwyPS+jBCCpYqheYGdj/bptY3gfOHy3muaN
f72itFqZIF/k9KWNd0uImY6I9E8HIDaX2j62ACv0kK/XNy8g+j720p/h4qbb3vN0nWjaK+VR5uYN
Wup6WrPl3JwoooPm357kbwPwR3vxzfgVoO84YmVoVcSQPjkjUZfSyJOSoCrbFhmZm9KZ8oQsOkxw
nmWeQFA1a5vaJ9cSXkwZTWq3pAdviLttJUhSsoJVRNPb8sv2Zs2ZCJuLqXdTd3qpyVA6fBeLPSXl
XpWrkgAHoiooZ0GvMrqydsZu7/hh8iiPrSy+PN1WoBuSiIUc94lOlK4763pepiYUYeD2dTH5mb78
DiYMXMNDqRf71NN6L96M0Cb9Sncoa/je5qUNgqNVMhauyj8YUuhGjcNVdZ+Fw3OTf4e9iKV1cqzg
ye0cbT65iwnIfO8gunwGAxsG+vNYpm6vK+WfG2rF2hQ7XAoSR7Qn6n+MmmYyi7UKC1rb5gzpSkW4
jqGfsI7xfxXNyL8ue/gYp+HLYYaHQfESpxTLWGGxrYkdmyCJlhO/OSIWZjOmY+QtZdstd9JWxGNa
9OS0EWposo0txp3pljJotwMx7ipvDXVpELnVkWZujbbSzocWar1JLsuxdI79F/RFZiGUeVSk5/jV
rf5T9LryjIoDNcT57/2qZbDp9NYjCvDy841tv96KI9vupAdTqat01hpdGCRAddlLE6Z8Gey81Wct
e7WbvqDIiQ67BfmGAo6Nv0AGUnagdWEjJwZHsqoabtPBqVDTeAJfHEgduzChE3UDiw8xdMM3CERa
k2wKHuGtAtyXF+HZNMzuIBbLUWsZ/cAtHYLjJEZZSySnixwccFWeTj8C1dAl1rz6QVDQ78R000U8
JqGRCifz5bqjnmgy7w/gn7xLEbrrMqdhtRHQtGxT87c/CDVzcUgfY+/dpP7gnqTtPX0KbgrozBWm
Xwl6UhMjkl9dgxXhXf/Eqt0N31++EJr4lSWReCkD6PMNmGB8Ak2hBDSdRcfgxqCvJrDBEfh8ilUw
oICZOYlkwtnwPA/MiVHLy7LO+uRgnaae4niF1RaWxd24zp5Bq3MWGHEZ6s4z4gZwq03LHW0DZWvQ
RmzGxs5LIOnUODafqD/2Yyk0V995hcPL5Rqze3W35ik1FgQSI8fvkgWsgmxK2+1SlxOlSESAnQgU
jDAbnf6aM3B/FwfWqjE+qqZdKYOJrXgpztQj6DXClAe6oVTb35hKcka/3zm0B8abZ7uqsocHq3X8
/h3z95ioUXnDYIaxirE2FS5YF989g7nyDTxKVIcipP/hWbmWknRy14TE/V2K5+kik4MO84FJ9fSS
KmK7lA217AtQ2WAmpHkx/Pvd+RNr6blhaBg5ao9lTg/qraRf+IrkWGnWzqTjeit/XjLXnFHWtyeY
t9rmh7eEQfZhS6dP2fqULQKx/KZoZapuzlRMf1tI0OimIo9wiKPus6TPc3GblvZi5DkjT2WaEFZ3
84JxyxrlZhil31zPQ1YwE3nKY6eX93fpUa7sQEJj1yu14T2flaK1HsN3+zskgb0OEkwgV+onyfyh
tIolDbocttBTtxMNP4qis+o+8z7/DPKZZqq3YhFmbIzA7UuBBR5BFdq7Rrlf3SbXkrtBmCCiN35a
/xpRTbWDeRuFnZNv/uuS9z/XbRsloN2oe0x/A1fIA6XKBGm76dPQ7YZOFqf0TkTeJDnlJ1+94z5B
Uy5CS5EXV+mG9060uabbZ7Crme0j6EYJnscqOhGi2nPdHwUTaoamtUa4BCde/5SpS0uw2lSwfI/7
zkz4bjJPcVHyzODN4mkt87tOuKXRrnCMwz8hgpalpm8RKmKbYOZFUydk11lrvui0OGvywfKZBe8P
utupB+Rvr8uRBNo5NCzhBxIq4MrFmWfFGl0g1Rv9++MAJPsI4Ew7MzTEr3SIqk1iTRGKbhRuq0bf
+oY6DOZ0mDuDwngsb1M5+e893/a3s8DUcbnexpBWdEuR5xVUtehXrTybJ8TXook4LjKhc+/SHel3
CQXssIrJhCaVVB3FBd6dPPn7yhsgfvQ8hy3aRtixKit4uZn62C8dy7E0dE/Susgag1DSzybxIBt2
zXkhN8XlSqm7xZg6cN55XyhFvUgq1dgJ1hNPWF79zgtm5I+gqyKhZtC/jigL/wlaMoE5xLu6LwDO
XBZ2khfPuNhM6Ppt9G43agmNE+18pQ4TTUhLl2LY7ELFewwfgc5RggoFVfqOWW7PIp0+fChwtSb3
eFBZt2hkeZQ5AYrDHLltWLfu2lerhVWfc/1H7jomfBvN3ycQFlzPb+f7lAWlXa6guVv3JBKzAMYf
T730BZXWMaX9tvyEH6WkO96qh9ZIajKZ8WWTwaWXB07CIx08vrRpKmMHW323YLjssWjn2IzCSRQr
jo35VfdEQbqla8HJCnSkxpa/glOkeEuRzT6mr75bciyWYFKU3JECltFeL1w/CcJqWFXLvJasSPHv
c4j6+FyZPyMy2WUkAMzAgazoJVBZWPO3dTU3aL0irX5HdktkVSj+PFn9xbSGDJIJng3PL4BOLrBh
ZUM3W7FH52Ir/ftRMr6sikgYYoINqyoTC43sQmPDHcvBjqbuwoRAcMwQImBrqtgTnZtotCTxdQDi
LeUOtWKvztwutjQfbmMOr5EaxEtCvfCqgXd1eQCja0X6gFf5aUkXvZpPgGm1VKxZrlEpqh7+Y42d
MVIrdXTY/dqz42htMqx+nP5FonGbaNjZWzWtLe6Uob69wejcS4a+s/jOi6LVZhbdpVW3upVxMp+U
8pqBT6bUv9pGk7Y4zjuiWDcC5QAp2g9YSp88dqGSRl3MTKpMZ+RA9ycTCD3/PQyLAE1xBSjQAT06
Vtqs0JI+IRJuo/15XQqhCh4b5gnsLpsGDBtk2oEsdcS8F0+SEPRA0VcVIe6rrjqumbPtbyONNGc6
8nOMoZlAYHMSbYGMLC0ndZCaAl+WNAwWuRsWkaBNQTvjP7vQf8MG0mdCowm4VTdjwQbfzKilg201
Qu0ClaMxMtNT1pcyqQfrk0tJj5Im+4YZVWlPgRvujC4wzJf03DnSe0VeQroe+D9xYuEpljm+ABcZ
5o3YiZ836iYIp72yVeywcEKhzXniQYMykY87qYlXH7qvqN7ctKlM3m6Ncp4q5Lej/GlBB95LD2WR
er7szU2M/7JwA3zOdLwt4xwrdQpPjj+4P3WHwFBEkVqiJf86lNYKmhzZpFg+38xcj7wh6dPKm0nt
XdDVwWVgDATokBEXJ1fFL8CfmKVXvRmGD1N7hn+skX/b5jk6vQQCsRbYcABeieZYM7rtNMFMayrN
K+BGphneYRyijKH+io/Mk7LVtlRKVDGfWWff5VjzpCv8FEYm3ZcL/Tb+cDFhkNYCY5ZiTqHD9nhS
vEs8y8kDyE9PP/J1axObCxnfSyq3OeFbFV/BJzXUXc3E5/fyybG3JRYOn66povmyZmZbSBaO3u+U
2Ky63ONkaTMRYdB54gpLnBwLl9B/coOpKyeKJqg2/g5ijJO7cNvv14I4m7yWfgXGBx0TsASAhK3Z
rsIfrDnhmZZId/rh42jKZA2gDJub5x2aniQ3nd91ZjixG3dPmpLxNsSZvQitzvQ7qij/xOmGqZ6j
rcjV6oDLcphdGY1Y4mVQbys7AsIZ7y8keSnQBcgFo7Xfj7faX4xzzd6a3cFqTa1C2YhlVF2zPeCY
VuJgW8gAJMtSRcnIY60qz8SRJ7k3SDztYTL6YakDJUfvvdVkWDhhdqvAcxsv+9JoyBvp3/cb8DPH
KgRyQZ1d7VyvF3b+nsNi3f1ZxBjLu7M1zJr269StrBY+DgQy7+y6aw6dpUC+pjS0pjkJwUbJSUlp
RtZsLawDeZm1GLBa3FyojvI5WTDxCu97ZR5nIBFoq75Uane1aeWQvXOD48ViTdKI33WrLdRcBA11
alkosFNt0tV+MvIZ7jkQQALuJqCmF3Zfl8JbP9PhZNgsWLnoYq/RFi00XFGgC9Up1tQCpSz/qn2W
3u/BwGyVMyFoNd1c6zpWaExT7ohdYyaWgkcghFTkrdKNzeHKcHqc59LxHP0X8LroOz//+nn8DpDu
Bdm4jFuGMP95BJH9gmp28OsYCYCXsD0uz+RFoHVBVQxqFxSXTZNbISo0ncjbzA58qNRPyJ47TvZG
AXsU2binvlL9QXWp4vAIn8pl40ZRarZtqSjjyGyL2bXMm7i1/AKkmqTFCmMY6lful3rHGRkZLnoo
Ldb+GiP67oCOohJ6rfVf544tzVvSJnIcctxQMu5U/7G6vxlNvJGkj3bYkO8Gt04QYm2j23xU47se
JE1CexwYu5iuuFUcObbY1QK1ZLJ47kAjF5ID2ZLIhDAKLQ0nO3kdjbQm1FYogY6gkXILy+JFupwL
x3Nqa6Z4w/jqVv2Y8IdO+HXO/5G+dsGyNfYyP/URNvYnv71Y4w+RlVPbnDmH4eaLplshDSqYtPUF
bw0al0sZ3iI84jzFpvf+ovalX/OVW5vbETtyqu2aW+0OfPan9OdaLrrPfHAR+3cpYxROVH432cGG
3kjpcAIB3R90pVJEuHEjse4Rh/wXKM82/sSL9ptzcq2+8ecQAm8LxNyeuetyEToCo9Uj13jeNydb
bSHxteJxZZiJsnOE9ZSxB0dVa52/8DUpg8gEZsUoVYd++zt2dr5oefiUGAFTa0tPHk8HHU5qv8Wl
27/lH2feTWY7SQtt9qRYXTTiDuD4orqqHrBBjdVE9Wt9XzvTvJUbv2XIok5zUxg4di3QWeeOzOX/
G5vXY0dospJLr+Bw7Nc0uqYnia1xezxwl3Ryoi+2LUMYRX3EnE568PhUYbVwyfziRZC7Krxcgtgq
B3/lK8pZE2NrhbEyTG6w+j6J6TTs/WFDJLC+9mxKJFG9A1SYSYUC+MvHIjslGijQ08tQNJRtqm6g
5pcFWG+GRwtbp00I93dGfzBIhNvmE7Vkd9g94pcW2ENGRPfRy0VI4x3bLFb8ijKr/hduEpN6ROpA
sQYd4FEAhsq8m7Adu+i/3Sj1ow+48Cn4kXUsc4QSk+lQZcrtK0GdhZA4y9gzxcgI7SK1xTrXzpd7
9GjbssnuKFSaP2XmxGEfmjyIIfcL9K8e3CqcLgxy0Dm9KU1hitIVWIr5hTipyDrjNhjAd9A3Zdi8
yHyOY99Vynqh9Z3zXaIohvqaUsr/nwb4jRf0A//iliPb7Q396gvg3W5WvilDmlI8ERtalHukF7px
TF2bH14hQUWLlY6K+VAaqEpbCl0l04m5K9PIAcCmzlINj+GRkB0w99xL16y2K15V7BOrUqOf+1OB
iWgtMSVwniTIc6bbeufVYa0A9h51ndH4L+AkOHhVJY7+/Gn8PUB4oLaAWjh1JI524bC7IiSzGP69
kouJJ0yw/Db7kUMb9ntQkSUWa2uAuLytFZEkbV04XkXIKTgeGINNW4c1gR99sHDEqlIHGfo7sjiK
LISbvCQO5ncZ0TCFw4hoZL3LF4BJvSH8oSqpduw/Ie7IvpjZ4swS1p1r+0+ILc+0JxfJEWV1GbA5
rGYlsKgH8MUVizkAs6pUbLk5QNBYQi2QbL11rgbwYVOSSGjZbBpH3mHaxO5OuklTUBqWoGCE1qoo
TB8r536mUCj7aZYp3y08waBaiCGnEh+amFKchFtlCmnNVSOFed435TKkpeZcpXfaQdXcFEvR1gRN
K3w7f6J/MUTNmqS6DtTC+U4Q30lu6NE7jiKIsDNbPs+ngHI7L9pkO7pp1REQP5j3YOO9NJLjUTpY
sb7NtAbGqGArdW0QEx5ph/9VVWD72EUxoKRBmv0WmLnacD21OdpCZmbUFBfPDghgbloEu3poZ8+4
pNl7YdjluEsWm5dell2DfjzLUhg4STKrnUtCtD0it7RndP3wcSjJwAkODsXDe7eBu178PIwe6Ksb
3bl/nV8A1if8Z/Y7aJir0MeNnAWIbVC/n0YFeFHWf2x3oM5VEbG5t3GdCrntBNkQZMnY64PpU0xU
5yET5fes14XdFj5/alXkoYE/eu0JPVizZEwHfft+ChmpgbEOP40ENJuECBapY3mh8XSEjoV9ThTI
iHi6Q48VuloizTGi7pj3+sx9XEcr/akWit40U8fIG+nL0v95o8UWa/GlqjGGCga7ZJPYLOM7puaz
vYPXX9SaB47AUbXYl7jHQdqTZCK3T+b397UCOlDErEsdPt3M2vOuBT+FmrM7KEZB9EGmhjIq2X7O
8zfVL7wG47o5cMHHkIMavCL9nhsivI9T4gVnXE8dGz/Ko1wbuAHxrNnOYzVcHonYDAQsRNfOeSCt
rZ1L3pnaL4BhcrFB7JtOZxef33GGrR3TmsLslTMZlKDpSIBs4pLP2TqPGVAgVc4XTN4hWPW713mu
zaqlW/vnEc33VkgxApMvQKDf9lJ58+Lc5zk/vQs88hdgueJ4E8us6zqn01DHNp/RItHc+lPZa4bn
EdQO4hgE6XQVIp+VEYuofCbCAeKMQM5CxDfQHfI42LMi883j8doYbT43OtwYo3PY7mn+e1407sDx
ojJar9qPEcLyixpTDE+bi6tF38MeIRl+0fXOchLZrdi1vzMlVWCE2CsFclUNL6feM9Rur5/LWnru
nZNSRY0kx/Jyb3GdR9Ksf2GFS4R8ou9jIL/xw+93RFllUBefMYuMM3uCm123GC2JSdm+43IUOY6z
SPrx4R/N7Ssr6xAb56x6mN1QRMo4MlObe7hbKnXITAslZ6GtPs+t2rt9Y0uohKSggYrd9NH82Eox
Y1xGgyeHOBe4Xpf0nWo/MzThKvFxjeOz8jWDiZUGy+Onvan+p8jAUruY4sRNQYRCTnSo2aYPdPDo
HCDQwEEjesMK+tc0nxZMzYDZAnNhELOm6ndv42vhDw1QgWcDMhNmSnrDMYnQv/bHU2HEvq5F3b1L
uT+U7D3ns7qyMjoQsqeboEPjQcK8Y41r3Lu5an0lznmHtKQZYd0wAtsc+Og3VbUprnLx8inMrXvA
JxCZv5kKwJ0pm4Q5R4s7bmhdUgwFtB7GHOJL4lC3jBHJI1QDYt0N0xGqNeJmFGYoYv5hwkxuy4eB
zZEuzFEnxTy1LlOGjHQqRYxHBLgsRMmrqNHPQ5zS/1LZSq9SVYbOSnYvZu5JQQGyS+M+elue0rFq
mCAilCFaV2ABVySi/JsLE7yioiPL7B1uD2jH+kEyv6LKz3eyg6DMSbybieBd6Amkl6tA7BYND87S
diWOalKPdjkLc3X6Auuc57rpy+77l2C1mvTj5wBZzTnzz6sTxX6XKMMANxitxMP1OhD2vL4bbjkx
mEi6xJhdV+uhXGetdgyx1lkjR125r1IOP6JRU8+6XDsyIcFVdTinb54bMZMQe1gdPqHV9NiB3ieV
DJlrhJHZVdXQzAT0igeadvcv/S8D6ao9cGZw6w5YjoZGz8rosND+14AzykOj5+atASWGTcmVvJWh
ez5EROHE2iCe1EaOLbVbULla5FnsCKOIjTEUCrC6wKtEckbW7qeq3lEqDz3YRh23mNUstLr6W9O8
xm8sNhZ6YGipYhFiNaOtg1/MzqaAeDBpwpK+G7jb+NQ1FAaikutp+fvILAX6H+PYjYU7G1W+XljH
mOLMw5RfN0OBnyf+KzWR6zN8D0153qvht4gfm7mLx8qGG1EBjYdd0ZcjKOx6j3zNe4PfdVZ9e9v/
S1UgqfqlM4uY/Re0NhWWOyUegRu9L8AaGtjH0foU5RlC8/7FdqZssRkB57g9pf/cWWNbvYuxwSva
ABZzP54uxcVeAc+tNon3Tez+fvO9Ugnfyz4gfVSY/Ji4rdrrR43AFbfznZL/A1LiBP9lfKLPUVR4
uca1NIns/b308uCa2VS3gSk0GyEA/LbYL0GpgtRwVGPgmetTjr4OkMJ9ESn7m2wHxEagWfuR06/+
Xz6oOG7WvhFiYkZTdlOWFEqZ1D5d/u5brh203uLziZm2VjK1XiW9USsr3j73HER4go0DoZ2qSeQa
rNFFDT7HHxewO53IC+jT5DwO/0Fdr6f2pFZwX/3Bb9hdJyPGIuQ06EdPfFhkJfH33Kqup7dn5pLE
WjGsVm0rH18op2pbr7+Md9CVvI4H9yzIllzQ/3J9EkBRnOdF6GTDvscw3KYX/sepgfkvOQDJZ+Ef
fk5Po5WDAPXjTQUkQSgeVPbrcurPw09NVRYnFL6lB3BkM95uKvbq4djT74eHakxmYagEHfW8BOvL
HgJQp40aghnShD2dJkXZC5bivGSw3g3GujkY9UpvnhT/+B5kui/difP94/IPcUyebs8WTQdOhWd4
wmi2iTeJmXh58c7FNQPSYtv1Z55QQrnhelpE9SFC0/3ozjI+ltQkAu+ZAdFypFVHc+aGBKYcu0OS
4w3rpW02Cf1eWYaRSW7Yzuhu3mBmWzZ6rp0c2NDn0y3Hfpd2pK0FlYHR5UcWUnCtolBKQoFnogH5
tyhHJqpQfx0FQyP8yY6gbS9rHQzTMiKGn3vQa0shJavidKEnudqEFeJjO49YtE3onpa80GW2snpA
0Vy4pxDXtNcqoxnGfkiOmLa9JrMbEQU6jt7GWDYoP6Cr2GuhAj8qQr+PFcxCYoqO+S2KoJ+NxrW6
06ZR1Vh6tdYRmDL4E0tsfthl9aRex0v0j+pL/ttSTc4esPlb1gnXOr0h6TYEz/5nh4arVP652XPS
4M0/U6KGNAzmSx/EI3cyZRxr/jrnWBnOtefHx7ULkOrmYKUILBvqglsN66hxsLFqWz8WuoeJWT0x
5BdA5jb6mUbxTfssNqP6gnuQwQvIuS4XDjpcpVPJdo3sxYmZ+AMke5nb0K1HjuP6zrpeABJGNNCj
jqvxqs4XCNKIbgjyuUnSulxBG7V9FX5kWvnTIk5qsZ/rZ9OTYEZcEGBrdxxhgbgt27nH5PhmeWhJ
12oKTRi7+Vxd/sO8JZWu6O2Gx+KdgWNxxJ1v86Elx82j9BtBQGPliw7U8bTQU7fDv5ZHhXzgvAxy
uKQppbtK58QjdTtDHJr25ksa22rrOqVB55P5j7aSthuYrjUkXZviwH1TD6ulZg2szFu0eucyYO+K
d/T1ECiqLnyzj+m9invEnesxooyR9c+mdcg1X2KznMINkhPw7uQJXofK6S3wEtVbCcP2DDSBQW6n
rUyLdxG7oF6ezRvQB4ukrUPBAw3Jhioeu7ilrdNfqbMlkLrEOkzUOnYYUKv5IHgWpKn8TxtbeZCU
kNBqqaOKyEdmnqKDRYIu8ZSE8UqAhkjCSkminLCRFDrOVc8fY45i8QGCsG0VPQN+xqAbxrQTKlvj
4puWPf7d9MiBG+2O25pPpIeIHr6ercedlBmuhsIqWELjSmGhi8G1LDxnE3HyUzX7nhfM6SpxA1Oa
UKHEYftj9VhT8/N680Tjyo2Bzdi6uCOdqS9hKCzaSpi2zPO3gSeJSlPMAdBknNa0szdsKc9xp1ty
b403Jcnud8qGyDQ/Yt5QD1mUSpsOY8aib4mUqicP4Y3qqT9ZkD2qUkNroltbK65rNupMN4oKFDMJ
soGAy+QFpsrQId7GF+D7OYzAs5Lam8eKuyQ1LZHLClKxuVnk38Yl0LbMG8xSwDICd6xO/QxnpYCG
2UdH2i0cK1V+nODTOcO0IL39dyBhaNXuWzeVSsntCvcTgTvvpS2rF4hI9uHSPA2dNebAUoOmnhcr
t8hxV07xT2I4lSBFwNvBMtBq900lX3urJKI7V0y+PQka9ck2xcBMZWSmqU7/V9UaR0v8GNKcvhxC
rMghxG69CDkEcuM2pSQFpsVjA3HV80NFl3hxgJlButQmPZ5/aFlvT2PXcsiqGSHE4IGT4vZNeZdC
pUS1YUbBqEgBrPfN9k3Zo+RsNL2ovEpkPKJ0woQaFauEAv48pAV0LAyPKPuvmJl36IXHN+Xg6HvQ
6MMqpjF57awEJzY7IhP9a8CD+23rrIJ+3CBfY7zQGOnMUxtW0RcAAWvAb7D1BHxbvj6kdfFfIsr6
fP0CnC0WM0B6Mmg5sRPS5V3JBpMY2lhcM61VeF0xmqh8ARQ8SMYrhBrdB48y6j+f/nO3lZznc3k9
AVCKAzbDGU22tl6IBCvF4BvaCtP5pvqJjdGADdEPm8gq3oMkzZDGul2Zd7piC2q7FZkSHaJZsMDK
W3/Lb6ldXb7YLpBDpR3XyPbpmO/+P/rYmGL+4Hb4bTDFUgeTnlTEeaGIMgcFHKVlzb/kWMFmDSJS
FY1tzfSPBRVd+5KRbp0AVmWhHNT3e9HnyNBIdsUyr9X6e6xvpzhln7p54809gzbdVuF+NrykDSS3
W+z3+Uh0Dg5G1TEaGSWC2plrqfysc6LqxW/cVliMlnqO5Xpu1tKm564axebFfeV9C+b42W3lGSHS
+nFYjLxamBuRqd+/IbZhUPgPT2+o1XyeFI4B9Gc9/dX07tn10jEeONOEdefzrvAn8q40OZHRsMgK
45cYLcjkpOkURNvmZeRkVCGUFP8ze4rNThuqfAq0Fgz2KDCua+YhkgxG0301o+fGT9SpivS4x980
DtMzw5jEzbhUWmtsFhsiMDMHIz1UovHbYQsOiUU5yTmKDZKxV6HybIpf4/0TmiWY9vns10Q4kGba
TF1sS+ftmM4FGJjzCwx9MuStPOGMCZ1P9IfKKLCKLGqbm6MzXcFHQy8DCX9z7+NnQbvuzYsUn+BE
lgZ+bJ2+l8D+Uz+GsiACOSZxpflUaIuQxzGKuIewpbacHzpRCk0JJlEfTFkRvR0Z/4Rl/zH5Ktj3
jHvteqSuiejXahIublj/85VxJmoUoNRjG6PfVWXBE0yPXP6cmqfKnTiMMEerst8/hnF+zrWN7bnB
illImrSj2qaGd3cS2xeEkfoRpXJlV6MJa9Qo0RxWw0KHqb7wuGabiByudoHYth8DJkQdKbmhzsGK
eRza8TLe//i05TtTj7xTeVMTk7d4n/x1QPhQeurdlZkyKC/JBhn4r2ouPbKmHVrLr/Bk6Q6oy3vL
xE5x0WYK+wL3JjhWK3jnfWOgmbdXxWBLxIVBNG13sJ2N4teTPK9JCfxb1LPguNs0QKljMSP6vdxB
gJNizBFTgmDa4oDl5Co2xXR7OFXGr9xAtroXGF1IH2ekC25cTl16xAOnqxBQ+TWquLkkeO8P/pRw
OxytNqGZjHYfVjaC3fS6lsRz5sOLj91aATXdEGUyFzHaUjRvuZT9zp+T2v9GW1KfkRK8Tj3QtQ+b
ZQ1C0fAVduWfGQ8JiezM9XpFrMf+s+ZfUibhgq19nOCv/x0xd2NpK6VSgubxjwyUHOEdHPKG+TFu
ha+Bm6Ntxclchs5+iJq70PXJ66xFWfo8u4DaLjvRwpUF8ShFP128c0LuQofjn+q8waStMb6IJ8Jf
L35VYgHYJ7fIKg1vDgv0zn8DdXR/hJ+HZjmXGsBqMOr9cvtz4RclRSLgr17Ad+BGRL+UUqJQteGX
C9Eh7wCuKzXoQuW95cb8V7xUFtIc5YehEXkkvxOq6vxXXWwzfdShS9jN1uqxASJqijWRH02T/Nqh
hG9kHAe95t9/nph4sbbctoXthE0HbmPLVZbgY3+u4+cC069NhsHW+XGxQQTVfJKs2JTaTuP/4rJM
fqL2ptNsNncLsk79G6YaalORNMFlpd/RI4muO8gNeXjhjtm9k1dR8PQp5PJXm8Oc3t3v+pxsc9jz
AL4xvXRkJj2Zebv7UQeBIguBjOF63v2FpxqNNBh9M56ZfQOUjkct9xnhx4TcXYMWqaZ9S0+syQis
VK4fo2rJV9mqiQ6GYvwMBogzSnOmCz9a9b8VxJc7N9ssBRZav6aWuEJ6gTDdD/fXnJ8xlHXPUvFb
YuzLNkbtPkfgR0kCOH+EcTL9kF+o1Vc0C7xAkgV37reW2JcEjfzpQZ1X2MrBZazisVtPSlVlH7Fl
3h64VrIAjcvc2ZGgxQ5Z9dpUlJ5V2O7hOpi3s/+kNLtX0wOBgEtL3ntUM5nLsfgcULCVAgVmCXGD
HUXkY48BKaGHT8SLWcwHpmFkaeX3NWtLj1MgU7nOYVb4aYJPQ6b1Ob59B3xhNn2uu7Z3cBXKSGkZ
U6gGx5obVx0lnaR1ST5kYmqWqKgENbA9P+GliGOc9vuruKQ1B5IIcLUUSmkKgFnEkdwE7w+UkKR7
qYKwLi5DBMDwOEtgwjtVQJQiekdaIyRWS9JDY9mQyUucmSsMBmxe6W7fMIE3qsMXElTDdcs9mDN+
PfwX13Ve54XWzfn0yg7VM2E5SeIHAvX/crcMFiNIO8Zf1w31SpDsqgsUKcVSKLDpcTClTTmD1QwT
CoFLN+tFLzJtsSWiNd/kwn5FCg57+0XatYpeaD5SuCuiwUmoPCMevGsAqX+Ga0MtQy8b6B91VoDa
b4vDJtVel2Q6U51qbfldU8ELizr21IZHraWLF2DIuUquesetuaa2atMsIKqyDVejo+yavelKwEQu
PdzSzoUdHfxQ4kbsos6Oo7ju7Wn5JhlkpUw51BeAMTWJKHopJgz0c9TmPs2n9w9i6Z1VMxnWKl0W
vaZ3dLccRImNtqeJimMV9rMllhO1lKjZEzBtg0nJJp9aQqPXMXlpE2npiPI4tboibkpXzSpzIg1k
wmUTPkWFqSlOFyxBWlLOiSguWjoPAbx5KL9TUmyScrJ8zOSZAmaOza9Haza4Gqh44wmOpqs6q442
a+cCk1yMB7Kr2yuHK6DwE9JWF36VZ8ovQESUBcrDyoyCFBjE9Krori4Jq9HeixxVP8KOdVSdM//d
M6nC/v3BkYErxSBzTFE/cOBewKGiJzV7wYmZjafDjPl5RPFu2vHNHvabeqtcBT7voVOPNgmXoC3B
oLOeBP+p2ga9X/yl9BPA3OIfnCDyr0SD/holYCVlFFKQBro4Rezvh+NmXeiIB2TEgTnefXZFfDau
NBIKq/lmLmGYCPTFJYUJ2on9cmjn18Wr7yNuvKUmXvaPnvswWAbfePdLkRlsE/QmCqtdC6JGv3Et
QUNyPYD96bDMYhc4mhoXkKvqv3USVHAq0J5UV3qhsJUtaFxhNBickXSahFkMup/J7XVLfstgIo8O
Mv7DkKcWSfCX0fVPZKOVLdOGz6J2jXMfdTn2mUFc2LuaVQmwMg6xM+zgqZz0iEQp6YKaMma1PqdA
xnEUaSHOzBl+Mn40eDEh7SVyQwljHdmiFlolmYdnfz6/KvM4kvGBlnwVMgiU2ClSyp6SOLdD/dMB
rmY+bgYrjY5hOQ/k/fOTY/5g/nOayb0+ysFzZ/+uljc71BUMnSleX7sL4nywTP+W2sxaetP0MKz+
Rrj8dGZOCTRYd3gUyjlz7Sul6mrbGu1tI/OIh1X0s/FhYlP4od7Y0+mZgHR82cYzdiotgFhVs1+f
voVKmxZCs7WUPc7iWcmVi9vZEVECoxZkhgzOCX7nrTm+wP7bG45XHGU+dot+dnc8D5eZdpGaUBuW
hibkWzfE8wLxef0FwFdkaJsd+ieEm6blk76lEQj6dG0LoC+p+qeFbyvVHSx2zEC642f71+4njfYy
tBK8Ztghf5qDUo9z5uBNyiQTsEwvTCqVp9erKXjhTX3l7+CCAPsjstDa+0Zx0D5SJZziqrDsRtpA
5n3dWj/VdhZ0kQvqThyFQKSBPeo7eQf8eE5RNlrCnUdNC5G1eECxXhWYEodLGmGrTRWnfQaTE41i
Uiqkxhw40SFO1JnMxr05o8jArj5HoGD9BfDB7B8RVbqulWpvC/LxExvGw3frZXvhT3aQ/wKgco49
g5UaGrhiLNd9VxppUUhs0S4yw3BTzJJFDFK8HYzbL8ZqKq/6tNzjqwutS6iF2W2C45snfrIf/hbl
B1OcGa6zhpJBz40R95fYO2Ybt2z90RhMlkpfe9Y80i7KlYEWsj0PZ3sQGgEN7kwpHmwxGmNYQ5hs
3s0QPyzNkG+ceLPrtWarnjsA4jo7WigXlqYeVvNT2KIg9M2uYMCy7uE2Xtk9SAs7jXLtZit4LX/A
VxCvGnJXqIarYo2yGWonYyRX3lpVngHqfg4DCA5bbIPKFLb205joPNUTEXZlzTdiF2sa8w5GpHHq
eJ/qmeI8yOyibYt2l5cJ++qNJDw0NMRbGWX9uz5nUyynKtTPgxf0vA5tM4RLVyE4fKgRLFkyaGY1
R+D8q2fN1JAqrphdBq9lE9dyrASjt/b74gWRnQdBcj+mIplQvL88r/hlmMgcUfi3k05w7TX7ez/r
p/wc6e3IQMtUKCJma+21KNJ1p4+ONJs66jmD0f4c1UGT9T/+uMGbWTmSRdbsI469nQd0LtXJ2vOM
sK51e9MZ4w9vTqwz2pj6GmFPysPvoCweehTonioxHniF4V4tJUkzjicPJvXhcS4/8x1LtAKXNSWc
pMZxzT/oH6ZmwlDDGTN5Zu2TUVkIvTyfiqupvZ61TDoJzeOG3DCvmOoz71HRZnaBjMraPyNo3Wkc
DTNmejm9dbpIM9Wk8CUdhKZZaVxWjvN0K6js+24vJaiUaAmyiNicVUwbTNFTo9VupOFPBqLV6kVg
MNtKhpURlDAhFCHTQ/dyYSCAK/liqpH6yjAAAfVIukh6jdLfuayahVgG9AfkFWQ4F8oYU7ZUze0q
dztLbsVeIJL6esBRufjSyH+xdUKidMwE/oR8flkpOZaeuz7B+0DFmEEwEyW2GTUe4kxToeCBI1cc
EYiQet+Hbf4aeV/l+EB3X8vZpNpQu6BVpJ3dlydbYaekOmVy1mLrQQINS/zQrh8XsZdDMBmTlSc7
hdxIbIDX0xuj6ocvf185J+fx8UQSUY6/dx4wIfV+GogTUG/xeSFOHcNymleiZjsx+18E1PfnJLDB
2RR4ep8ixbbnXG5WSZwC2yRcMcfpIFQ2GGwEeCfhYaYeei96RJZ4bXbcKXOApOVNZCMSc6dtqF2l
xewqQLc19MgPlttHNnOQGbM6Y7fGC9wHaEpBbBSwlYboDFr1iRujeb9tmQ2by5w8q1sFlgVWKymK
SzjWJgtBmCrK1lyRurIAurGnEK4cvKNK/ogsXeudD1tDPnCd96JkTXqzGR1qVomqWbCW0IM4pRnH
SrV4cPTfZl4oC5GizMQIZfX0vmKJCnODooRIaNXkhSUuHJzh9xSmxivi334KWqmdwkjhvbu4S9Ce
b0pZeCRbDBcXYhKEh90xGwmyo9Vm4e+fGSAFfoUFmhhd2o0iQmYe6DdVT52azJtUFoVOwg3YtwLX
aVeD0CoKCWfTVJKbvUZwHfjJRWkqc9YOftQeVS2EZDK8ZnEMJpDUj12dQGYBkzKIFz59l+8zN2X9
uVCUcJqUjWMKnhHWOZbvE8sdWZLAB5me/89MNpYoRdHjB5Ct2sttM2UBwwu9Qieg87/t6GrLmWWf
IcvFHnxiQBI7IVUtb3YYVERrWHy/g+Izuw80fcPO7KvIAGGOwnJDtRZ5TNEUyBCW7tiIw9NlP0Hd
Vcc1JSjiyIviVRyJOXPZ2zHTWKJRfxQxBWajqsWmWGtPm3gFhcYI3cWKvVktVTybNEP5w2S5DOG5
JvYYem3GrtTsawZ96yXfVlrpsBiqpGG5ufsCYHuN4l060XZcYvMAA7/FB+gW3dULnnUvNs0gr84I
ZldRyBB6qeHXJ1F6v6RXdlBHmDgXlawPTA/cjVMsYAzj6znxFPGXQdTfc4y0J316C3/c23qM8DHy
CZXeDLCEiH+6TTYsGchSs8tKbZvFeXek8qUlMguU3cZJzZCEWFa+x8yoGDbvrsO7kcD3JRHaJyp0
R5GIqhcdyRw5b+iLTY6ubD/9pslWo844sJ+Z8F52LHj2Hth9kCnbxF9NxCJIALvACSwiK86ItLc1
ylFbAok0JTTSf9BkY6gtNMWq1JRZrOmMv5rv35ZGtS8TmDvHZt/XXBnNCvCWEWRp3M1Z/+WwTxob
cc6T1SNBAs6vWc/bGT8d1ApZ4X7S1+hF70pMXmSzY2znAgtKkvf549prReqva3JsUcoE981F+am3
vK0qwJwztpq6qjP2H+kvyBNWQt1sC93puInaG7q7B38GCFIo7Wfaim2rWgh8x3ScY7UTIi8FvHMN
SlNu7x41Zoiez/SHe2dK9QOGurgDWl3fCvm9NVzy6fROMdZD1BOS6UaVPWfmSmVqaohaMjKKTzEE
PkQq0UZqopW2p4VStp9hlzZ0bJLk8jYHb1sJ0gTB3Uq0hGYbBnqtaR3ao8cOe8KEyrp3E8AAX7Q2
q5dIkooTA4UvQNgFhe23kxp9XX1+r9hBRhzO2TMEK+HgkrdvwweDzIsWhpWCfgrqZvnERkQXC7Rm
sUBI1pffpvTanyvGyZXyS32H6ealV77mUJq7cyDKQIMHPQsgBr9vu+uzs4HRH+Pf//DP2Sy1fVdw
GDZ+jVY43xHNCCd6UdN/4zf7jSqcImRdFpjMJ0OAltBJuvNq2dpsDylIoRLEmCaDyEI0rQQyuClJ
VrFJHdfvwN2fSfcx/lV5OO/UPpFxJdDLVJxnQvLrGIild2SYUfvzplJnuBQY4ejYnEmsI2WH0vNw
fAOmnjsjYFFLFEvkedgrVKkblXHoRq31Brg7sGl/yNC8LCSMLJNe7DQaoypdg/jtyfd4d1xbbZJp
lq8Qk5uxopdDPRXH0IocpVTLbnk48WINjyOvfH2sE22ur5Dr9+N86JMC42zKKqyXsJ3Gr4tj8EQP
9R3ukqMD0L8ACK+LtyGxovmpnJq/3DTfSpJ/b4t5CoeQM981udUqpUk1L3Iwwc42HitANbkcIyKZ
PVdNZw4YNcmhw1pGx4tFf2zcDXPFV6sySCIQasRRhpIulQYWEBm+MLVewFEm/IMQnisdxhVhEeYU
xjsxYPpMKK6+sCJZS9WIp37kVUvSS/RkUAy6Oic2zzVdf8l68m0f8VZb0eShIl7olKphmOO4Apws
YyvLPqlV9ZhT4BFIOdrUcged5+c+Cl6QhkLn+Cle7RQzEPuro7yUaFB3vF3BVRroFQO6HFFz1yMg
RD41iLvzh4ulzNi+n7BdkhKtUNRyaONNpK+ytpkJso/4p7A0ta2RjCUB8Tab9onbh92FmFrm9+rn
NCnpvwDm07vTbPxvC7nf042UkNgU14tCkvVwQ8G4As3YlHuQGH8xRMX4orUsikFDxF5w56l07F4Z
V8FzdQ/ro1dXpamcaxl9T+CAkd/1ifQ/S/eKRRXQJ9AiuyEXaYet1yObfs816y6G4tiUmBEfQ3bm
/FAKH8FbwAf9cQ2kJkIo7VIj7lp2+HXm+HJEFybfKjwotyaBPo1W6LxWSPqq5fLK1PkaObrQ5HkR
qp6kICOtm/1KFMZZhRp+aaz8mw5qqZyDhuNwzqEEYtaTJlhXW0rJttprDsaFRUs4xtymowId02Ij
/0Y5iyEKIHAIlif8AoQwjYMDWkM0oYi85w6+Zfwo102alCzkxmZ6CkbspQ6mOxQRlq2gDuP7AkBU
WJtLvTH1xpGoaBxGjn6spuYxx9F+Qr1o0DWN4TwrMEAQ1vevSXCKqcfVV1A1mT9UOsTS60LURCmz
gXgHFxjx4+FH6alFFe0XMbArILg0ohxTKmv2M9vtx6qCqSU/mvI6+yu5z4VzrMlRGdF0PAZflxpW
wi8tFD2rwQJLIWDZKf/mPzE/izkyijnTLzWLOZpCixdkxeWkgUiyGgJzqrFNs0h/m7JMQFSdWJFh
sNVFmhFNcpINm/OGx5x5HTH3L2P1vzYOTP9kQ6l7zF1VHpPQlT3mw3M0GuGJTPNU97Kl+TEb15v3
2PjovUWJyTNP5Ob/ElZR51422xUUQuC4kFP9hS5jmUeekDCDxymnXJ/kCNJfpzzBQ6R5eyaZmKvW
8Uy8HGFF5x4FdcHi9T+U/eNOdTaYcHR1oHoD3hY5dY1cusC/1z8vi5afpPrjR50rIc4IzEl+msV1
hIAn/juIMfpjaSNr1f1PilNHyKDbWtH1yOJP0t5k0R5NclhYgUdBuLuatyEElPQq2pYG81QYYsUh
JBmlLtYpfMuYwq1/utYdIRSphhotO9hbKAhCC3qTc+CczTMcDy3TwzE2VCNHmyKvciXfIx3t+reu
x0fIjjhCHfGiU+AhKWJkTBMKCgswl372Yn++6exZJO4CzSvE20X5C6CmwplPqJLvraqijW6tbYOj
yf85RUHmdrsSuPIFyG22JLJ8XOMtilnVNEsD15ZPWb8LIzC3IsrgT5ZQvWhb1ddkGcyCrqqJbyh+
Jht+pGjgEH3QJ9pZkX5SL1AiZ2BeGhSn4IGXioKHuB/rvBCoKTZ7cYlcl1rggqRzQDADzX/jJln3
s814Ku6vwpZ1Q9LyHpPxXHpkcC0Bj1PqxpdwnAHVBqcOlDldI1B4+/mV0PUz3d6cZYEw2bd++aA+
aYEFoihvfL/HYMw1i4U07BtRzt7NNyEWqR4GKVQWgUXXmO7ekVamd5ly3XVxe4JAQho6sPjDlXZN
decti9bdiWFU4T/lM2JsJArRH2uoM7EirwvlnZdw9D2UvbEyJSjt6aaicSk9hVVTe99aU+kCfoEw
YPVpTwVtJScG5rc3DcQJkFNX7/CjrhAEi1P/WcThMH8nPIbOfS7d02XntHd/0g1g203yB2xExQIq
LroUAuyJsm2ZJTIm+Tv9bCWf+l10JNgFFyylfzNhszmfvai7+yPZtp2X3P2WG9Bkj/2GsnohRcvW
ZEi3oKqz7cKdN1GFFOSfArNV7+p/01XIYvbWiQMVuTrfheHK0VgF0QK3dvy6KOgomiSeC2OppWUs
inuSG5oT4oKsNsTd0YQ27GJGzhqylk6Kkr3k612y2N25TpGAkZ3yVNM6go29tKSJIRLZCeq3QzJ/
XWa3tTVhyhqjTGTc51dHTYpdyGyb3GUAwOGeXT0v5WbVGpyEDHeWy8BSSuLBXVf/LRWZ+Y3DQ9wb
XtPZrwvNF7dOnaIyVe2zHACv1NssJo90oWaQpxrJI2NEz3pbWTObdKFS2utBnLrmgDFqlnR7l9kZ
UGCo5AxLEcTZngQ/KvIH1WBx7tQfv67ueiiR0qcs1jFX/yDpH+oTffavDausKwgsT35v4ud7kAHJ
kIeuvKs47CBmGRsFUpAPftgblHIOtkRz0hGekcmpbdl1TZi9T9FpoVuERcxAdRn0kI1pMadZ9kLz
RLfsCbOlsa6Avb5vEXA/0gFUo3+mhDFVb0iFiKcFB1nSOWdR3xu7pRJzy/wNNSW5Fe5Ey1et5Atg
tS2KGUXok+B/LE98VFHKn0J1w3mw1GuZZx6OY00FuyOY1cyctYc9b+fIhM4ycHbF7axnSPfXjpHj
jQIDlXV3S4RI5kpfN4QuGyO2ZxEjLoOiMB48v8xZ4lilWF2MlkwaHR0raPvDQT2lpqzPPfXJuy12
jypBINWOW0Sk4jeBt1U09q31dBGmRDJEp/UIHFYjSEfJy/JoSLRBYiLEMP/xC/CgyfmYZeLKlJJN
Yhl7cUg24AJ53MNQMV8PtKVnawowNq6edKEx0nevarSgdoqqPXVHWxcl7xMaxaN48bdeeMWfmG82
K90a82p1bbNDda/V6Z6vrr0ImdMbZDbbjMm3irwlmKCO3bOwWIHdK7o5kQFBuQoBoxO70qFcMQLX
OQVDi5jz2KYQEMddZ8Qfyt+zb8TEU1XAyrwnzwugMU5mX3GmWVOzQKIs50TOY6Fmu+eGl+WUmOLb
994m+4+jDe/FGfQTzcfUNY80TOemhKBpPvPXBTZPi4KwyTdZ1KQAqNB9Afz5ZGvSm9ASaBn89FHt
9zrE16XLkD0Ip+V5owY8i1a0wkCyO2Qpx/z1bevv45VB/9oBgRN7GaUr6yd147fgt2te5AU/utt8
ZDnt9lBrKmjf+nRcsycLVJvjByZTn4PvozgTMY3EcJvEQTVbqc7dcUQh5qJwazWq38XSjPNzMzgi
LIsNSe/s0aetExbJbwfrXq75kJaWsmjWuHI49Er+isEeKPtndQfsYMV57NpGSV9SWY41W6Dkuwue
XsTGuNf5VW6c3/YltTnWzsVXc53eac2bvRE+Op1LMXOXuij5LnN7seuPGsx+z7tEQnxgwpda3Fkt
H2n4OYio7eJ8tdVe+yxBrPdCpTHcMA1BJKp/j3kuiEJjwauFtXq6RRzpB6y2a5GENt7fJlwSKiuQ
KY1+qZ+KLZCeIuOw+skgu2qTUnmVALHDDvGyHOBYIAo1CBFBKSWi6xqzSjEPsg63NMzu5Xln+GvH
egByeXwVGiMcciloJ/6Nf3pBfrun8vORKpW2MPLYFDHSU9WcfhwVi4kMrzKqjrBrCS95xzlzrSnQ
NARnq8z6pezPXstxB/Vaeg+Zfsiwi6sEfetEgsHFBkGo+9V/R2ipvhmKqItcKgo627Qptm9aX8EP
ZzNVRRF/qwSV4Cmgp/0zBURcUDp2O0pEIPh72ABfM8f1DmGf5IoQXx7tt4CKd9Fx0JZSpdmL8idt
SBr6Sb3VIlEvyFFmt8rL7AsglUiH+saI+lCdVYu4UftzZj7vUE4lfd5W1zzPf07jlecLgFhEtZVC
9tZI+6S8vWvwkxjn1n4oSczKw68Ecd/0C+BTYmFLjO1ZI+/eKUOL+7MrrwQJiU4xfdtdEm6TVUPH
Pk4Gbl/XyToy7fFmy7dyDnDa7R+apnF9K1fdHRPvVyD+Yx6LCy2E0tndyaYpPCecs+mToK01kfA2
cRRD6KXi4YJ5aW6Pn/Z79eRocdKym5wW3oTdEUiPDra1eRPu3Mes9U+DaKvvcflMbfMvd3xoFs5s
YSt0HDyfuMsM2ADZctWlA+mjgiSE4MwC377lIrl8MORPaHI1urcvwAbeiC2ByvU5vv8xw2P83Tjr
x8o+yKKQmj/X2XmukbijFgt4UqbPIQfGA5f6aNE+TLGrJBdG0gNA0sDAikXqNKQ5fF1xkcuR+WUQ
W3ZZJnYQNVxmjoLmDCeLgJodQquqZdEUXsWCJkmmwkgSR/I4SSaUmjWW9M+izO2/bkdzQy2X3Ov6
0YoZI1JfgFqs38iOzx6Dx7peGWPSTEV31CbLDiL7dyAyp3qhjEod4JPrRrrAnnqUqdJr6QzqMwqD
iGeJg/34KVpWe9ewtbm+OX2L+/F1JZ9DWqnh5ozDnYA1xJswiV+YhFBG1fFAvfa6AnPx0UIVBLT1
4K8MY/YXzdyHopPXII4HEux/HdWzM64WvLeg95Loj80VwrxSBuYArGHqDCsLfLbmpv67vF3kbH+N
Co+dGOp+Yy9mh9FUEh6iXtrRf0r7Kque0EYneTataczTInEfOSt7MbLtCXuO38VrjaR49aWascIO
M8OGiEkNDHGZ9g3q9WhjhCFUPZMG5fI31gem4vvl8syWipY4UOt0Rb2I5TFqlF8zI2hMsleL8Ygk
6DiXPI0GHr2nQobvG/Thmk1ClP18TPMTw0LcpJv8ZJgPVFUgCN1eqgoW3vXszgg16xvIsvVb9sd4
p+R7YKMuRlYtXxQSOr4tHBPxVGJ/Ym8Wz5RLT/ZozKQEsd5egmWbnbVnlXB1pH6tRbQGNHdJCrZ/
bLH2F8nfTGqm3gxTKrrzt8LF4zceX9e48XuauCw1IGWEkfopydZtYc2rTQr5LpORmGC/728sRT5u
fPMwFIiUIbXedfsJY5SQiGyh/5yJNX/UUherfqedeqfoc493ofOammJh4YwoTpdjTuEk7MXms3j1
3dOSSGCtpJFfhkcepa+11iYNwYOOPS1XMjlIjSkuC3D3vGxS6NnO0U2qU8x2pfNE7H8tqJkRsPvB
IK8edLRn0Wb95BXpir3Hv8Dn+Cdmw9/39oWVlQFh5nV+ff26vCmq3XR7WPNxfpuDpUHUsytmm8VR
f/FbjJa8zG4qTN5BsvT6NqOT65nmvdE3hGav6h9RpDHfKgjNfZaFK3WpQJMVuJQUKXiPHDSknO8q
ewwGLmfTIeZxvibmcAV9YNlui711Hx8mttV8s0eE6Ay4q+PWZmdTFj1KrUK9dy7bdf5v4VZfAAP8
pqzeEKUSw8J2dc9x8uVTVe39LvttskEmY5u0xzQm1NU5k8MHNi6ZmtkeEuCNvhJS4uSWQmtO8unW
QKN9F0PplpGELfTTt3aEBAOp9LJ5zO6d9rw9Iv95jfrmINoDGTKRaL14/5Qo+wopeyBnfSvKHAo1
eLK0s/jZ2vXX3FSI0oOEouvng+gXAN4+08Dv9+iImYP55lrej3RiFyGDPqvMky7OPYzCYVeHmySi
DR+83ihcMFZ9yTPf9OW4T4au/vAvk7XsbCu80tY/jKmnRxsbLfdhkxF82MKbFc6Qqc17uA7V9ow7
G1GOeTl3XccnClHD2IOiabLOHInsl+ipOz74Mr4cddallx7mGSX0CcLQNd53+u1GW3wQT36n+PET
39zYYBBvfbt8a7y9tcR3877rrugarm4W9a4TeLFeS+0rNlzbjtnEcPQYHJx1bC3DHRup+tlMh+z6
6FUJSvqkpvklZ3H9uHHVGB04cm+tLS0rFxUaqO/7juJFpsA9jH/R0+qM+ZehQkJZ/AvQqAfcJeBc
lojqTLYNYI/r4pmmb2nd5WEyDZJT4c7g6JEd+fD+uCoRthw40Pqkblw4N420tXqTd/ayeXkRAZeo
zNU0rdvTXxKUt+r3vqYR9eK3Ou8ikIfzcWcxkvpVeA1Yba+1Sg1qH2DfMn4BGEpPYP2v8KZ+WP4l
/pXHLOmzLL7rZ0iEfb0hXb1ToI/SxhnwiabHb13c0e5xq6kQiVO7MH+v8E1u4YG6FX3ShBVHUyWI
dWVeWpNW12ZW5/Rmq1reDB17vZPpOXexPJc+urQGRFj2JtrAtu16oqSEAmw0WteVOh655UWp8QJY
ZS4GhJ3YLLONCf1LxLZelJ6WAvEHeojeuCWur692qb2HYzif6GbGppXxyXiboHCZB4TXuL59U5ov
auqw6GSglFgJfTGlKLA5t3uP2qRnxZt04Ip+oODg/KWvs88+RJGr2kufaoeSreHc6jS6T5rXt+zl
XAg0WptbnZ7GyyWNRFX5oabjTz57XwXrCdIZqtwxmVG2QTdexW6uWT+N1/0Z3+GXIcIr7Bkgm/Rm
07f6AknXoOb4IyX6jbg5xquMgCqOjSFNf1ea572yPLp8s22fZ1hVrP3fGmwJVmkOXi45Nrm8Vavg
Gde+dnPbYuqe+lTHxw6c0Xi9vUVHp0Scx+Vy3C2deYwIPW/pwIFuyN+2lK7eBy9+/xQ9BWU3Av14
uOwMyt88Qs10ofnW0oKoh2qgMSu3PXtdWuLPJUbeThZs4/5kAPv6iTIqBmW9NDS/rq2Kw/OuJCw3
lYsKDWeVlRnleSdmiyIPHEmONfUvPodKMe2Bcu31RLie03O7i65099xqD5KKozoOQf43IbNjqcTB
ICnZ0zCBBZlCNx4DF5WSs8LrgjU1B5HHhxp+1Xa9ioMUUYiIK8OSPb2feUrJKRvjbAzjNUXwTkWQ
xebfs3mE/uCf2TcPW8oY4E5WNX33PNEPQrFVXGuKwpByLtlO3fE7Fuae6yj/3PtgiL5+3powKIym
JV5QXwllwlTRH0CkLfz936hkRLqQNK7ECoO+ez8jv5R+wFwpNpFksPlEI8c/ZD6niRkT2XjVkqcq
YNT8uxEz2v6Ey5njXLJZI4n4BcgrUWw4dX8HUwSefAGWqhD2+J/bMnFLSS7oYLPw2benmltZB8yj
nNbOqyXPP+ArId9UmikmOtpw95M6740lfg0O8fnm3dyYqm2x581HuirtntXH8ebTfHqTkfyNWwr8
Z7r+3HJJ26IvQ1km7GNK+CEJw6VEAEGWcZEqA1jLth9YjMpBVUrPazRaE36jGmg90+EWwu9Q1pvY
KGrrhzs5k1NGN0LX1t8EO1MVVYjhntsdfgHwfbcY5nu2lulgRlGJB3Ny83JM9U9w0NwiwO/QkdM+
WkRxZ3IqHPYyVScKzpjljpjFgaP+oq/qWh3N1a+Z21W8gwwm4CdbFOlslLDbShCBaqcYP0Et+urE
4yDqdieUk3/ejxLdlmWPFxf/+81qPS3H196RNsAfND1d+5ERzH1lVX5r359zP2PcqdElss0ujxqZ
u34mpbxpZYW4JwjUBlxpeJWgEtvmdDtm1uhhYHIP6WYsHKHHw842eSdc6a8/VD0x6RwsC8T8LJ7C
TMkZUsV8teBRz/wmIycj30RWTGTNgQg9JlohJRuuXjUXpF2Yo1CSr/dNgpujPR/OMlmNXRE2Z0Sa
of5asRHmT2vqXXyVB0IcTT2l23tVLJbLyLTP2E8nMg+hYJ4noaCmYLzeshMnmUo+uV91gw6fjum4
vrsuYnRX2ZH/mgXlFG4okQSGmn0ktPdQ+rx2tX1XHvba4X/prUeVNirE0NOZQkUbu/VfApc6kC+2
c00lhC2Fu6x4lF2jrUq9TvQMgupP+Lq+AGvYXJpLT4+yeRYqdIztSKxgkEV/Dbjk2Zt2p12yPfK+
QFmKocv1fthlv/91acElvjweW39sjHiQE+6doiMv+TYcQXodOtZpoeYN4u+72IL9A569LgK2+IFJ
OO+gsYafj0orPkpGaQS2jP0e0hDhx262lqBf8bY2h9ghkr81UvslKkjCr3hTB9pLlGxE3A3az8bC
BzMjI9b2rwCWF0xLSBWYalJZ+l28e1E7twvSxTYIc/fTa9icouc6txOrp4pha+N36fRP9PpRtfXc
oGqZmnW53U0xPObFY9vJkZI+RkEpsvAnrCGgJrpNGp3jN/LOeNinb0kXSVNAG3/sBY4hq3jKyi7h
1MPHvMf6+Zsq8fbZf2vJFIMdf+xd6se+AIxskjuCnUua8bPpvgsLP3GC9JvsnDGYA0AuWdrEMXJv
k9hgqOApjlXGMwEVrrzHM8sGzwMSspROx9FpZ11/6gUQuh/9KV5RvMRhY2Gu4oazPlN389REpWQG
03wFSK4WyUazzgt00IDSSeBs9FQ/l5VczZP12tXh3823+dHCU3h7rVzHDgs1VyNes7r2z1tejtHu
Zpq9DQUgaDulfWHnmpliljHvSfKj/vj2TJbCqoK5taw1MvrT15KXaXSGQNz+RL+0s2z9J/Hxmxje
oRfBk7RrYC5DdqtkxhInjyXPSzjJNOiMT2I6ihzspOVDayzUdOgDM45MnpccXxarJHv1oOCFoTir
unb1oa8SkaAkgkr6pkVGHezS8cs7yp6l09g11ybaJNleY78Wr6IT2gdJiHLuqLs9wXEfpul50cVb
JtaWRLGjrm6hqDtLLVLKzZV6K6hro6uzDgqSb8f4M3kJqYhKuurIfcWq+J8hTSjDhUZNrUxg7yKk
DJFrX1WZztwXoDmg6XMeV9yiDulIPM7mNvt74CvUlRjlnV/foZRm/xrPpbemfWdInPTsw5s0x1l3
GmLSmL8+xc2tw5nOJ+kCE0qvo2DM9HO/2K3V4RNeDVI90YnGB+2xGX8AsY2ykRHDur5foWDUQHbl
zV+fZULAdudC8BfgrBSOkzwXxUf59wPJs8y50GaR/ysFtOZpQ4+QhX16X6WuYSvQDLZJ9Rf6hGvP
dyWao1OG1KbrzeEh2QtK5aYiluI/wTR1r/PG15sHQWZ0b7QxQWlJIZsXZxrTfed7i/dt73JE//J+
ia228pO8AFsBqCO5PWTzZZ9TPlkhP5AnsPcDiQOi1tqOrjePc1v+If2uueKHm4BaFkpW2q0q15BX
TINYt7pscNoKzeNHWwoYULLlXdoDFqn8mHIQ25+EapHQVsJai1FTMPkFDbluMb6zT/oLXOLc6Kl6
SZsdYZooPaK7iTpddYn83dN0d1G+EQwly45kJ2T5mF9U7Oc/coRXfeAWzQTOrJYUj76vwtYdic+8
MyiOcsRtZRh4L7k5eahR/IG0lXjkgf0v73ZOEfOTk/udfDmKVj8Jj6BrR0ihp1cW8C+/qz5YvXGB
qge95Wm72V9D/PVOYb75uWe9EqGGcJipawLlMv0iTnYga9CD3uyWyEFj3doaLHmJqpvyzk9PGcqb
ahlu+dOw4qHwkfJf7Y9fb+uCQlCV1c5gh4FdAK/Zijrr2dJSh2USplpdIl5EGlGa8HgdhmhO09IC
949UBALXGcwpGvG2xW00C3UryqNME1cj5QUQzQ3bZnVGoA58/CvKQ84ef7pDM29pqBIb9wgy3w/k
TRnKSr2JWHIPealxVtXe0Bo5STJiG5npm76+U+sNIJ4H9d9CXI9L8Ezb02O5VoKe1GADlhlG9WQv
BX1s7qLwO4VjU+m9bYjBCMQyyb7aKD/uLLbhn7iRauajq8y5uME53yCp25xndYokTdLrjX2PTIWG
2OiAqBOl1E0EdnRqjga9RP5lKcfdl8X2L4Am74/YrYFmUBdfItIljB+YY15aq34M2CGwXA2J0n02
ew8iZ+LD0iDhviHxTh1UDB2DLLw706q0UA4ji+0MgWehW9D0gNbqjZtqSfFTX47fKqV0jo2W8KFM
X1k9CTb0KP+nOiVk/+nmQVl/kXeigJ0wRp99X9VycGlUDuK6vlm7gO61tv5Pl1njwFim62KoZBJp
v25q9mHh39m8FwvYAwb/HiesIJ4xZM9WH7QCpN25n/xsfwmnPU3T5hZzKEiQks4tMaFjqkiQ/mdr
MiFTrjJaD87W2r18xQWrQYSPO3cGUWwePNUKUqItPWnTVmu8cDfQqEsdZPUS8A8gcn8i38azQM2A
RrsfsP/KxHNXsRKEQ6hi5cXfRiPe9rOhtq+rXzjk2j5tZaiSjldExNoo96oVCO6ejRNSjm+wIrx2
X+aFyYSvMdSkuEBWhLmShbfdDTipsAeS+ebH7t6I5oYCHdCM1/20o3hvYfd7QYruR8P7AhUkIape
NYW4MlQq59Kfkp0HS01+khsbmytdaMeQP41lhEPXJOc4viUHSR8nKMwOiS6wjp175jPHCXwuLFAI
n5V8AQLRA3KBeoadwr5SNO0SM8eRp4fXOVWyo24MLq6/w6LfTCs3n7mkKVcGaQH8exBtQkGlkwrZ
g6f1ra8Tnl8AiMgqqsPqHIp1veVPnESE3XCuWa5F2J/r0U/edj1o1g/1JRniliyfprWtskyk7dOW
1AL4nUAIs5TyBwW+tWmD+Al2PmJx8G//0JK5I7KBfZq57J+rxf2pAvhDncKsNbmXc25/2iN+Qznv
5z+8asIMR1/W0hfQF1G+qaX2YxtvZBbbahpw3RplkFsSL2oDPWK/VaN/58vWRGcsBqZ4cUysfqMX
OdeqbdbIxSO1b2CeP1EdmjyfH5ZSRRxjN1GgwgxND82EKEwKFEEPVq0oxzwq0S3Ufp9vVMBUhqdz
VSiuwH3/72ElXTMq2E6lMDaRjpjtdA1X891vZldvlm2V9bYcdTyJbH2xfyybQoOsRCGNAuzsWlFo
NgbbwFOLvavrmRcPe626XnHynk+SVY+HwWFsQbxgVb7lbGSHW96pgZ5VHffUSwlKfNABrFSoZkzx
27NAi9eV3l2VNpegnLIVPkocup4MU3/rEJVGj9opsIO4zLnYmltVidhCrjab5+F1Obc2irO7Ms8m
y+bXoeerOvoZzm0RxYb0+DFjZ0eeN2/89PqexZBrFJy87+ML7tOwWq+5EOr8UNvdU69Rd6OAVbcL
t3fJ1M4f+fNPacSMczgb5qsr5oSfnS2kfTshJHOlSqLJMHT5DMQilN6/gcimAyMzf+4+Okv3a9fQ
u3+oqkfOGKK/t3cq//4CYPtE3n7zibA3lykwTSQbrztFbdbL0ltgDqVqT2ifoenW9YY4+VaiXVNg
YUwacmHetE2ZPo2AN3KZUdUBG1WUJVfA1OVy2eOG5CSNt0+ccmhba4NYAH3xm0UoBd8Wp+7Y/JbZ
i8dsqZLtnjisIcDqxB2EWZ4w8GYZ4h2Qa4u+Wg0CuamaWsMS8M9MUHjX2E5RLjmWrOnuqTUd+IKD
ZbgaA5xy9ZM6aZ6A494QSLu+Y/DH0MsBO5v06+ctdxvQKQ6Ua+oQ6WFvBsNec71LINFKg7WyNKTq
SO/ftjyjyF8AdB1x+5rwi31Idnqsb6MCselnutvoAO66XShUKn87j/W5Ni9OggxKHXwxA/8zbxWh
Kq9frBxT1MJdNik/Zba8LLqgHCBrJPaxifoeqh6xncBlz77rw0hbtl+AkpyC8BlTH61M5jJ38lvf
49svQHtS3HgObK2PHZcE/0i3U1lkGcdInIK9sFJE86r9HHZ7mGNimK15nuhW26aN3FgqdWdLLI6F
QDmiDHG+JrkNjuyRRMpgbjFxU5KhvmLfFAUvETfhXlJuCGWEg11Z0BpdiUEV9+Zx7a5W03YzEds/
MIcM4sfzOkHWx9ZDCtPkXGXV6GTVrMwoiZJssM89dOCJmrsgXPtLDClPqWWypnyi8UBJrAguhsbv
slpM8ji9XE837DnqUNqafTS9q+yGuEYvqUQ4wxSbN5WGntb2SCisk9irqdsGCAsKIqUSL9LONo2B
0XHB9Hn0o1+mYxQMxMXoCO8StjPGghFucgSeF+fcw4S1ZQ3pd7NfgA5kiTIjnRP3s8cmOYzHtoZ2
5LYvgI9QyoGkV2soG6vJ32NKq78LoaderD1adr8mMN5PfCThKgd9HJEfFm6H0X9q1LtIT748nslR
beD/efT4Dsacrdmcniw6X7nkraX3KjO548e6p4kUdWUxqDwHXOQKI/LmmWw8dMtpNPcGSYOGPKIT
CfuGJf1O3RfP3wvKInCmuRhwlSWnPpYFGcCpe6KJeIGCit4LURwZm22XRHdS7Of8ubXASj2gikhr
gpTdhbf5Op4qFvzIfmQg826QoMJBLO7iLn0SA/IydOYdhjOrQPv7qShHNMtQwkPhnsOxR9nn0yBO
PTspE/Ohqohp7upRkwAGO9eElYSEiOJlBrgW5DUuRyMydfIU440athO0NDrGnvO8wftBFzlyWeKM
yeDmUMg2x7WDAMA40dhdAjFqwh/Sxqo6N0vTl3QgRe42Zx1n7ta3BWbjj/hEsG/9OVc50cRP1nSS
fiKHBhIz5Rpup0N9Nu2VGYhBd6fuKdGM07vzjNw6/32qZdaL4K9/n5JPQ91YiiwZ9RCka8b9QYzw
fWg8jHHq9w3EyVaNTICjDzZawirJZf2IVC3nsbtqmnH7mUFpSmHXOlEoTo3XUW7qhvwJ0yW66+EP
fnI4ilI/+nuZQOW1NSm7dJU43QYGhKqMtigJTE3zEDKeknLmA+1dd0okusr6YhU1lQWKFoOsRZ0G
3n88V9qDhs0tq5jnJekJHYTGJAPtCjYPRykRvvFK/oszTTVK1CB8O4+qKnFTKqAueaN0p2+XFWJA
ZK2eTR3TUBqstLwFWz5EV9Ja17wrt5oaRcNTlQL6jKK9Dl5RgkU0KQlbAM78mdxHO1Il0k9q1PeW
+1r+yN0w76xpmm65RmpwPk24/djq37i90XUts0VQ+JHEO4rtRHTMmaJchVoRmsZ4eqagO11RsoU2
fmJXDbLlJWonHUmMnZ7nuDGXLFRAs9xqoeIdxVJ+ppvoAqrrXHvcxUK2M/W23QLbFkfw1QGJd7MM
fKvrHo85jEaiYFkSC66wqLwQY8jTz+pK9+tjAtcLfbeP7OjDNEr8kQzzuPrSxUD2OdMbdboWPCJu
LOFuKLrOFte10tYbTPiiC2Tomc4r0b8/npcTCULhsiO9DdnuqQsfiWb0unr+HgRJrykxXEDZYgpz
C9wftUe8U9kKv3ue1gkTMvZS+Ad82ByEVu64AAlUKc2J/WKFyyvtIRY3gWnK1o6WN5CzMl180rjc
h1Nm/560uDCqk/TtYtnzGFPHiLMjp+NUO+OOdDJc1wO+AIa1X4ABLZbwYTZx+rr+jd9Jz3PzbT3i
EqNtC8QPDnsRQnNs0V4jXpzVa6DoVo80ZyN7C2WmVCl+UTClJl7nbG3A0jp83FPhS4BsRFM3m9GD
1oiwyDhCaVp6jwR46UrzEYO5DGv0DrPRDkbD9YP+sXsPM01Lx/64RZ2hST6DcL/gqH3perMfL3IP
AWzHovkegSXmR/zIXCfzAEVxBx3JiR2mUX6Kbz+dW8UvxTmh8NlAoqQ7PX9/mGjOyn2DWqt7FO4Z
O1cmtHOjp6uxvzZaUJ8QK2Xj3P1ALVVqq+Bo5Sjg0vvDjFD//h9DVu6bfOj4Ee2j/+2shqBHXK/6
Q9ZbVn5nHilE5IGDTsbtf20kq06CONCK0YOrUAPqg0TWudEJzhMrEKUR/eSRtd/N3pa8nQ1B8vEg
d3PKle2MuzwUjQ4tIdRIRcdFISkzjK3aLVW3mP8SefjciCOPxW39C2BPTtw8ZXOBlMY4K3dUcaXB
fVTkqtOiIpaLLK6kOzBSNGFaxIYog6xFnY6BZ0OdmA6kC29HGK2SU9890UyNShyjHabCK3GGpR3G
K+IYJ6QbyFDUFaP8x27AFbw7vHD/lvVSwjKIAvHtqUFJZau9ZnH2OWAopmRtQ0eAXJumn4KHXqoA
RApVy1HllglvV/qm4hpNbxHKd6BZU7Jz3DDfs0VojxoUBgg+UTdZvrC7zG+vb6Y7IMlzHhMW16r1
tUvT9MAu3HhxvQt+p1lq6qg7t/n3KpTFHVLjcICXQgD99qopFLZrsUSae67QQDu2+dfsrjKTO1K4
EWTRmErSNEg2vZXOKVgWGVOoP9Tyj6ns9He8FNEpX2pErQAFYRpXvLY+2OkuLwuaq3/7MpH9oSbz
cmBrfgBDtPMCFfPZ9LQd7q9Z3nTb0A1Pc2fQ3ji8iWdHNEZHadtN1Yytq3XLLLm0h/C0jOYDLEgQ
2vAamnV70+BkLp9lwm5a5lzdecqlI1sOeWO2VsId6prTR2qZQAa9iTWOTWP92Oqytsx7rC19ioGX
l1FGWE1nRiVhXqZMTQYrt7BuYw5DgSN5BK94CjMZ3h8oCWzaAcLrGjRZpgZGNMQ0NQWDAPy4RZlO
dvP1IqMVzkrkSVgibEndMnE2QEzAw4lctpp6guKZNEAthL5CEEJY1lmSZCCAQiLjJ8WVelQiMIh7
80npwEahOkeUREXBqG7YxQ/YTD2/gS9GXwOJGK/K6KDI1eLH4qrq5YCCyCIUohhAL/YdP0WBfcLJ
SSXwnv6/ggvNlpRRZcL7P0h1vz8ksicc298bTHk18ARZ9WdlZK/QWvqc9OAc/NjncgBeeubW05tO
+fXgGjhOCeLok1JbbPAoYpI71NviqA2f/KOi7/C7syYHfwRjmY5vOy6FC2R9/9Ne54Vpn80SpEV0
6Ij/yYySbJU1Q666FmSCV1UatsvAoQGRV99GsdVJpklLIll7woJ3Cqm/ZbFFFMVhQ56zYXu+DfaT
Znm4iDkuxfJWVyT8oUm7aULaWz9u3AwuqJv89WjJwnNJvCk6RFOQLzgSwao6M/BYexR5xIaf4N+V
6Ua3JDfdToVgeMUWh+8l3l4CNqUq/OiVhIVf/sk8/DbTt7yUxieEC92sQDySEAZ9XtFwZRkeqIqa
H0N84/JTSI630cdbTW4Xis4YEpCs0C59JPORe/hzt74NgwyoBqUVP4sTaTdGCc505vDnkpS6aIh/
5j2NVV6UbqauH7Q7yhN+qp9TK6O4aqKd3J6kORlPICUc7Ji7CS1SZhocwBPtOpX1Pu+XABAXbqjp
qsqMMH8c9PSxKbXW8M0XztdaAYoZ++55R/wzRgIQxVD50i3Lhk3c2PmK5WUJuTwBr+hO9LyMNakW
weNmDB8LhEki8JaljmAOAr2QbL0mOyoaAr7suc3VDR1j2U7X+by58sDSg2NKf/0A+mybmdn0vcZB
B55h3c/x9oRvf3aQt54foED8dfVWb+b3Zrd/3QhkPA/8bIWIiD/vPn7CfAHkP9iXMhyLDScnq1Dp
nVz7ZkqVMC+HzeRXB4XJQrTSJGdeG2dOlIfLtjO6imNF9m+rDCUroMLX2Iau4b4A+qpm7DX3J3tE
7LH7JZa7+wLBBr6NM0DUVztyDgFHwugPSUmbDD4/sFu+FBszvCkY+v5deCShVPJhZl+v8YTrHCGm
vbq9aQwnv8Iasce4aBr8BagpSl0z/8RQjh8sL9eFbyWalyL1u+QRRNaJ0u+NaU9ucL2tf3ioDlLg
9qo6Mt77FWwYHUSMZUEj8FvRRpu52sLufETqUL/lNRdhHN/GTpHGwscV788fYyc21w+G1NRfxzWu
M18A3TyqdTYzziwGV0XVNrI0dPNFU1fF+AU3JLNGGZlMetzo9/nkeWclyBKCgrgpiZZSjmR9eDwF
9oIqSnX55KFVRmpQxV7FEP3afbE4MW0x5qkperKqaqDIJV92YZYiFjceLQgZR9FP8/PbTx42LvZ/
/Ev2tp6Oap+ji0yXoxvkAnFmuvPf8J8e+TRiq4gq2OCVL7KPjzb440T10J41pymoLgargJ0IkSLb
7Fw8eNUxwKZNOS2ZkP/5y+CvEm9wXveVXtEQn1ztI2WJlmK0Ke+K71v9Qmxpq34L5FRY6L3OfXKv
HEMGhGvn8fTCjK5/yK4BgQ73eSKHdZdEV1z8F6A5d7UkTHdu/2+SYpyKtFLWoplv8oxsGRAE5NPo
qYXpHqqmNtpsV5vw828ywJTY64XX/bfmVh0ump50xJYdird/ok7x196xibo3Ck1AmOHgN+7rnaZb
AFp/QL722kvsE1rqlrYbUfuwRusyiJEDrk5sruugKSvtD03D64JMPi/XfqQTINI8jIY8Adl0hMft
qFNBSWa+6Hokw4eoAMPAYWtVwLQtZ5ulZum/7VWXNfDqlyg94mN3qESIPycMH52lBHeKsS7KhrXu
/FlO4rBIVBo6a6uss5HPTKXSyLOZuzgH3GKoa5m799SWNW9KY5qRqD7LcRlXwigtS73VGLw/DlzL
63QuTG0szl/SXTXD3neBbN/PZc/8e5MXUt2k3nqLaD5SvXGXSJ8W4RZlIK6Coxk4raN9uV9ifbZF
Me/mo71a6CzgDP3tnRcKj1Nxo9B6t8U0m0Fstmmb3rGpOlRV2CPIPfhKZ7KPd32+2ZRCTXK2eKlm
bokca7tAkAfEpDTAzadO7cjFO9AyV5+XxQuGqigXYKoWLzplNRgnsQnwqOVkLgOBXSs+SlFZC9Ff
grjMgqedJHStzff7lxN1OPewBqgfJccbarutgSQoNQ8E0g5mqfDvM51453ABJbpZIwn6TP9uV/1X
4SXP/pC6V9gJuMKU5HTX/86jRyiEJnR7qPxrPZPWt9yiNUZwvgL7QvOJZPWikUd84t6ithpeFCGu
h7zOxwtVQ7/wKRQrcduV0HwxgP1JFq0lXOuZiGynZx8djPhinleC7hETarDcZNH6t6kMknCcDR7X
cWjR6FmC7LsEu5GZ9+Wuh1T2LzaUFK6CPT29TfLpmTH6x3eHMd53GKa0yOpzE1omgyhm+M3kk5O1
8DEqtSlrpJXrkQiiz+AAnDSC8YZkHcQgqTbOERtvcz635z8996M/WstnVPQ6lGJQEqxcoZUDarIm
Tz2Jg+qbQZZMiofMpq3fWb61mZGFX/o3M1UxQYe70TY9j3/8Hh3XSmLbR9bZ9WCBayeZrrHBz85M
KhpNIJNAhLZtMvaO063sFq3QS/au9jb3lgXG636kU1ZByVJ+69mfHhGhrtb39J9XDL3dmx+L2Lob
R6WFUevFGhTfW0Vjen/WPJJzEqggqNwvO5TNZelMcEC/gBlSE7pi6qB7BKkvmxDtebpMewSrmMdN
GghMDkEcZoTdmBa2/L3grFJYjoOZ1UsHZ8FDUbx1+WsMo+IbIswWASQTvAylrpPvix1xNsCA2EXs
YU2FL0D754NQACl/W9PzlQMzyMLaMoRi4GcklPjhk9D9cV3kyOnA2maB9PoEMkb5thPl2QzIGXVv
PbGhyZnRRZblthbJ75TnXe8XJJ6KZSqLu+w+I72DxvTWmWzjnP1K36zehEDXFP3xJ8R91Y+ik5uP
0g8ziRx7CrJRGC2eyd/ey7kSe1kNPQZ9OHRHDio0/EIZFUbDrZ/mse4pTma3X4Bgx7qTSGY4V9vi
NZv4la49/sEedR0cgG8Rv4I6nb2HffUg1ZArpdNLPv3O2lhuRg1rl8KvT+U4riByPE0UWJ839QbP
0kf1FJEgEg6TVRyYsG6Fvu3kqmeaA+1+vW3GHeSpSwX9a8U4rOwWrcToMWeMlPvbG/3C58RdO/++
up/GZolDVnmGPvOgd6VyXSlMmVbsvvCsikF3TF74rYZFe5Omroah1FsZF6UMyPuXbu9AA4nQwlfb
KL12uYoolrFtIJGCV6KtB2tnm3ZcxthGUY2rYpZBV1cOdcqtOgxUC5ydBh2ZjTd1vb2ts2NpiiM3
9+80iiMKYQ8iZ+0e1nSqe02b4Al+4Q/1GVQb1VM1StWLj1mkbI1ePGADAvb5fd/JUqiqZV4K0DHA
FlEmBK38je9jZD9Rei/1k8HW2pSlNRlpjmgWKdH1716b27IjuXLkRGwGBSNcffnuEnMRNNxO9t0M
J4TZYmHiN6JzFp0WHLAaeAskvSIduVXY5b9t0K455nt8ZtCStDdhBoxKWzv7C7EUpK+YeAt/FB4K
rvFPSXMrpwcewCH2hYy9LgtXerYXw5Dt+vks//ConBFGOsZM3VcR5J5qwhj408guld73BdCaT1SS
nz/qaW6ir8A1vYiLt4JbWM7VPX2yxw2b1v7rMcMp4B0p4m9bWyNcokdCt2m0rTvoyACo8ebLJ2h/
ddUYSnUEJJNfvdFReGwT97lNuQCrgfXoA17fuA3vwUvn3BHQSQ5EXL+FXxco/0yngs8dbUnSZTbd
bqNqewjWBSu7WNfaFwZxACxjaZd+VztTFmvNLc3kcWw7hNdD+yQp/LqzbvDkG8yTCbT/PPe3l8qD
lcF2nFOV01WHCU3756FE2W8aPvvmDUBTamOIuPHvfjP8AhGCHcsYriAbxFypbPdYFvpMW4+6IGxL
TC4j8b9uJkCirnUPL8eAHxmPjt3zMV+AGJW2HLMb2KjDkB+Hg115XWz8y6jE9R4OkycMsA7FiQEg
SU6fuk+r7PW7+NUrick1/vCcgF1Ol/04wfDxbJI0kEVXgg3+TdBOXbgB27kDxLGAjxbb2uKZ3LHX
ufnnF8A75MrS4+5b4sv05UtRugKR2zRFRyqrFW4Ic9iVc1yaoOtWa9cZK2hkN8D1AEke9VIETBYm
eye5cLnp3jQtVSCgiiz5j06J9zEX8ThaZZpZba4Wf3xP4ce46iileM/2JQUcf+u820l1TXXkekEe
Tiwxg9HD79T9yS9AIOqxoTN2iSu6F5AB5n6KwwaH1WGVzGAIXcqlHXyYpJR5sHJ/Ibs3ON4VbQps
0T3EgJghvJOB2Yxcl3JwR1DMcW6g6U/3cXioZdVbHXzJtb18mEL1YQ1gn7Tfaj9KYzl3y8yZhBp0
RIsbA175LsaEmw5OHLadTDlDmrXlKeYunDhY5l2NTsJVVJ47Pz+U2zHqKYh5vnLqxGkJj7Brl8QQ
/GsjOLpdMxmFrJpwJLgt1hQ69dbne8r/ebvaalN5zbZY4OuNj/RvUwLClacKSpWU0/zcxqFf4g87
J8FCsbr9XEl4+YcNn89DqXrIQPBcYrBM4E+1u2FuzE4FCltk8khdWUYIBRtde0izojPNuUoqPcVk
9DEYJg7VhXBWRUxVDcCuYvmdImxQ/GvqFk1bglk0tgcpgC/RhnCpNeQ4cl23IdUUGkifSlMqjF+u
U9du6Yiysa6E3NVALkMHCOrz8vp8tNm9Dlk7RbBoYzXJ48eLRlX11vgCYBUZnKHc2K87jR32eE7z
vDOUtuSY1H0OJDq5SepHBBKiCy9cPoD2Ctmzw/pK9dQ8Hs8CGGUOQxGlaQQrWrbgunozb3GtYlXs
2gnUP69zx73xz5ry2LYHrmziJagGNrDIMtzfwQQNNr1hS2eSfiYluSRNTC33xKb7QsG53vMNtHu1
Agx+JmXfxlyqeh3m4N8lRDqQGoEDL6jplf5Owod5S529aGcka1toLW1+kUdi8NBWwSfamYxjFrsx
clMWJLakP9vxeK4iQ+MJGZxsjaT/Gmk09bZrrjHubQ0u0+BWe+kdOz7FuAmhLDFdYD8OmGJc3IQP
tkpwpmMydXFyvAq81vhrW7GEv2a/LoKvGyTy10+nnJN4SWkMNVuZy6IGMynXtPKIJtNwkHlWRCGU
xEeAdxcB0Nrlnk9wploUniSKzU5Yk5vc/e5PS9geoTtla5a3v8GA+Yt3IutlNr0NI3htHg2ALzh3
r0MBTjNY/i/H4jb2URcgaPC3XxWUSirJs8xegoVq0K5OltMarBen/ZBF2TVsdqvkzMUcHs8oWNmv
il4YFszonaHT1kiJwstzYYC1VWTluHfQxg1RYMxr1Dl/W2G2cA4yXjpgK6UxO4yOPQ6ObXKlxuYl
EIbe2BA94odODjL7/XEMtVY8+06GvNlTQjU/GWOKQI9DGLu4OrbHj7lw79qBgSjVnG4WDdKYbybg
FiI3auqr4h3itbPiaMI7vJOsoKhETdEOzLNJUmp50zj4jtE6laCcsE7dzDnFtTVUEHvCjNdvifDO
W8mnHvTtTUePTNXc1C+w/JRiLmBXq3Yt6YPSLwnKC+4pAyyvoX5tmIOJozqaNHFgkC6kCgEgbivJ
G44PGNCArt/sXfk0OMtLKhPQeGlex7O7KpQ7iJ7yt1D77BdYrCDL0NUKvp+y1HsItZKIkNxc2e1d
qzq7XpqjNUXlARqKt6clxMnOzD/kMEgFawbxN1xxBFAEjrlerZVeL0fZ292XyFXkXMLMc+25iGUS
ppkkX/oylU0AK9LRluSgwkxdkG10n3/I5g6MKNErzOslmsOFUHRq4NwghzTn1qk6cl+UxbIMnmmR
3jhk2dqWDD6mktmPbyB5cGrF/DERDgU5MFFFTmXaNiXX/K8AKGXXmjP8OazfEOm2mmR20UTZn2/v
x1w1aOg63Y6f4hnvGmaO2fdt49a5/XriO81G4nhfdHI5ZT7ZrObuNFawspL+7htohl5WCqPc12d3
4Pijs7g26uZbIfvy+cE4/hzXL+Hb+LTNVs7ubOyGQM2OtdafGVtKddV3cpe5Fuo7ZHeqi0gNjTPC
+l3Gl6XK1luaZSbiXP3ce1UvDeg2Nxa6ri2W6lgnCRk8A8+9MsfF9na22i24DMLMTedz94MKq2vi
iys7PU1iDlrmcMgwBgA5puaAnuvBsFxrckMAIhhjWSVR7jO0VJD4VthqOmSiINa3TbPKl4bI6mkP
ji0Et9MEkUz2Qj47SBcZqrb+NLcRaUJVd3tH3k+uc9/Wp5xnRX3g7SobTU5IQCcgR88xEkVhXWkQ
aascC6eb2R7fc8mOVyM8VVTxjHGmsRhXP2uQMgduB3qWHxzHuSaVG85IPKPPDcYp+0XYDS8OaJBL
otzMba3kljuM/wCkL91PapvDlhourrqssltHbxReWirjiEY9/esWy8X6d9guLSdJg8tz5qkHjHpT
B4rto4dTtraFovtZj2YP9anmuM6s6BosMWmtAq3Ae8CF25DA9qo61Dp9vex2Ztbb95OiqYx8wUnk
NXP6f4sSytLCB0Yi1l88YNS3fiXT55Jp0tT58syT72bONp6CnoTY7S58P6OJLxokj3Q2ZDwnGFbb
8jCsXQLyxu7W8X7DDm0svNBYAksprCfxkv8AaN9dLESLuDyCpPQ4xnFU9H8SxaVHeIYty3MBhJ/u
5obQ0iK5ubO/vPOkj+yRMFBCDp2ziqU4jSYrESyfwsepFNt7/wCzXHnqqOvO1X5HPtUU9z5krPtw
WP3R0FK/kM3vD8zR30O1tuWAJr1TXbVbzSm7kJnP4V4tbTkOrD5MEV7LpdzHe6NjeGPl46+1V0F1
PJJl2sw9Cag3Vfv4/LmlB/vH+dZUj4qCiTzttKL1xxuP51nySHNNDmkwuapvGPeo3uM1Q8yk8w0C
uXBcsD1pxuWPeqQbNIWPvSC5dEuasQRvMwVe9U7ZGdgBXZ6TpSqFlYdOa0iiDZ8MWAhVWfggZqz4
h1OOKFlz14/OqGoazBYw7Uba+Mbe/wCVcLqWrzXj/OTinJlRK91KWkY+9VC5pGlzUZNZtikPMlN3
1CzU3fRckm3Uhao/mzjBz6Y5pH3LwQQfQjFK4iXdRuqANT807gSbqTdTSGUZZWA9SCBT1ilddyxy
Ff7wViPzxigQ0uaYXNSiGV22hHLf3QpJ/LGaRraUHaUcN/d2nP5YzRr2Ag8w0helkjeM4ZWU+jAj
+dQGgCTcKaajzRuoEx1NJpu6kJpEiljSbzSGkNO4rD/NIpROahpuafMBcEwNNeQYqrupNxpNgDnJ
pKaTRUhYWiiipGVgKcelNFOPSgsgPWijvQaZQUGimk0yWOUc1ZTpVVTVqPpSESClpBS5osLQM0Zp
KWkAUtJS0DHLUi8HOQPc1GtaWjRRTajaJNjy2mQNu6Yz3zxWkLBYkZL8LCzeaQ5AiJzz/u//AFql
ktdRjnWNkl89uQvzbz/Wul8cv9m1fy7ddscKRGEAfJ0529ia39JUS6Z/al1Ao1ZVH2ffw7Lj/WY6
k1tGCaeozh4LHXpN2yC5+U/N8zcH396DputySGPyJy+0kr82dtegeHrhzoeqve+YG+05faDu/wCA
imeFLuc6nfSuG8oWjGPzuDtA96OX+v8AuGUjzibTNQS2894nEGdu8k7c+mKiNhemAS4Yxdjzj1/C
vU/El1Zaj4T+0QRCJTMQUxj96Oprn/Caq2ga153Khl8vd16HOz2HtUSVrjPOm4PNKreg6c064UCV
sdMn+dRrWUdxWLMTPM6pkksQoznvWtf6XqGkKgudyCRN6ruP3fpWRZ5+0Q46+YnT/eFeleNrK6v7
60WKPf8A6KuOOOFH4VvCwrHnhmlZOJMLnpjv600b3yd3PevRrbR7Ky03R2SBJpLqXbOdu7Zn19Px
pZfDVsNWvmGwwWsaMVXHOccYFVyprcLHnb+cuA5Yema0E0a+l099QBJiTrmuz1vw/YPq+kxx7Ugu
1Xf6A+hPatfUEhh0G9tkUKkFwFXAGWHr7is3TQHkeyc84OOv4VJaW015MsKcFiF+ma9Tkg0zT7LT
vs9h9tkeP59mDknsx7Vm6RZWRN5qKwxrdi7WMQnB8tc9RTikNHEavo9xocywXDAsyhh17/Ws8BmI
UNgnA5PHNdz8R5Q+pL91l2DBGCM49RXCMfmXAHLAdOafKu4zc1Xw3eaRHBIxVzNCJAF5OCKyViuZ
c7Y3O3rgHivZboWcmm2sW6N7/wDs35GJXCjb0J9fasjTZ4bPQrMW0ME908zfaN5UH73fPOKpqIHm
C21wTgI5Ppg057e5jwGidSemVIzXpOitFceIbwzRW0OIT8u5dm7HBB6E1h3mu/adStopooI1iuAD
MMY27ql8o0co9pdBNzROB6lTj+VEdhdSDIhkI9Qpx+eK9Yu5NOK61Hvg8vYrJgr1x2pl3qUcdta/
2cmneWIcOzsMjjutTpr6Aed6D4efWNQNmXKYQsR3qne6c9neSWobeQ5UGuq8H3Qg8RvcSyRIuJuc
hV74A6Vh69JG+qyujDY0pO5e2T1FL3eSPcDOvdOuNPZVnAVmXcBnPFVM1payYfMTyrp7obBln6qf
7orJ57VAztoPCKJo1tez3PltdrIYx79R5lQeH/C39pQXNzPNsgt8g7R19K0da1OGbwxo8KTxmSJR
5i/xDHbFL4c1e1i8N6rbvdrHNI25FPVh6CtG4/vf8KAydM8NpqWqtZRT5jHzeZ1yo57Ut9oNnHdw
21rK0rPJsIP8BzVvwPqlvZajI9xKqKYXQOem7ms9L1V1xJjKDGLrcW7Yz1pJxtEC3r/huy0hTH5z
tPtBI7HParM3hS0sNLtrm4lYPPHuVc8A9uKr+M9Rtr/UhJbymRNoz6A1e8UavYXei6XDHceZLHHh
gOoI/hNWpRsBU0Pw1b3Wmz6hdyN5UbFRtwOlL4e8PW+rXt3GXJgtlLkjjeKn07WbCLwrcWMsxS4e
Tcqjqag8H63a6SdQ86Uok1sUXjPNS5x5tujHYij0Sx1HWbe0t5Tskz8w6x49am1rRtNs7qK0tWaJ
/PRJt3X5uslUtAvbax1i2upXxEkrszdThu/607V9Qhudde9jcvG0ysGPXCnP4UJ2hT03cgOjm8La
en26LBH2eASRXP8AebFZ2geHrDUNM1Wd3LXEUe5F/hHvWlP4o08Nqk6szi+h2CM9EJHb6Vm6Bqun
6dp17FMzBrlPLAUdB60CH6J4biksJL+RTOTIY4rYcdDitX/hCrdpvtBDCDyBL5IGPm/u5rHsPEUE
Nk2myM6J5pdZ0+9yf61onxwvmGEBjb+T5W/+P6ip5kDRYi8HwahHFMImsv3u0pnPyj3ratbWZYLi
3tgbRIvkRs5L84rl18ZixjggtFd0WUyM85yTntTW8WxQCZ7XzDLcNuYyH5Y+f4KrmQrHQnRY5Zja
PErb1Obv+Ldj061WbwrDZC3VrcXm9gWZsfugTjjNZSeLo0uPt21zc7NoXP7gH121H/wlsdx9ne7E
jSQNlQrcHB4yKRVzVufCFppwuZI40uCZ/JhjfgAKoz19B0rB8TeHntpbRrWEHzohI8Ix8ueMA9et
TyeLTeJMl4paN5xKvlnBUdBn8uazdb16TU5ImQlEiQImDzj3pMDLNjJaMHuIwIwfmGR09PWtO+0i
Ix293bf8e8rKpDdYmOMo9ZCTFpFMrM6hslSeo9K3Ptz6pLBbooit0xtiXpwep9TSiI0/FNjp+k20
NqsCZlt1l84feD4zU0thYad4fspzbCR7sEs7YyD7VS8VPJdtBI8RHlxrHn1wKpXXiJLjTrOxaIn7
J/FnrWv2JEm94e020tNJudSZUkKucbunPatDwtdQ3T3dwDxHF5gjP3RxXHJ4nWLS59LMGUnbIPfN
QaN4lOii7XZvE6FMHtSul/4KGjZsBF4i8RoJUCrkk/3SBn8KraulpdawtmI0ULOqFl+XK5rI0fXn
0rUPtcabh83yH3qObV/NvzfGID595XPHXpU/8+vMGdD4wjsrGZbGKKPiMbWAww47+tW9fSz0nS7C
KOG3f7TZglsDfvP/AC0zXL61rp1q6+0yxBHYcbelLq2vPqcFvE8QX7PF5aMvpT6sSR0lulrpnhmK
98m2mea5fcJADlf+eYo0W3t10A3IRLeWS/UebgZYE/dA9K5l9flm0uLTTADHC5kD9+euadaeIZ7O
zWz8sSRrN54Ddj2pgzo9Qhs18Z26G3DIxgPk44z6mor7Ql1rxXe2qlbaNRuJHGABXP8A/CRXP9qr
qTKrSLgBT2xUsniu7bUmvwirI67WAHUUyTRm8N6VBNZeRepK0s6o6bgc89OlXvFsUEepwaWsMexv
LHCjcucc8c1zUmvnzLeRLOBDFJ5vydz9e1N1LX59Ru1vCixSKAMqPTpzSQHY61oUT/6HaPGEtLVX
kgIBbGOu/GfwqzHZW1jFpEUEkNuJPJMiFRm683+EZrkH8X3xLErGskkflmQR/Oy/WoYvFN7DtGYZ
WQEK0nLRfTvT2JZ3epWNnpNo5tZFtWnunLSsAd218JCM9mPy/jUuoabY2Md3eoyWTvJAnnqAQgKb
yOfUjb+NeeL4m1BIxGdknzbl387DnI2fjUUfiS/jaVnk8wSf6wSjeN49AeOlJ1AsbHjOJf7P0aTK
yyvbtulUABxu4PFcQa0tR1WXUcGTOAMKFJCD6L0/KssmsxgaZTiaYaTEwzRTaKQgLUoamUlO4WJC
ajNLmkzQKwlFLTaVxWGmig9aKljHUUZpM0AVRUo6UKtOpmpGUFRstTGk20hEOKaVqfZSbKYEIGKs
x1EUxUsfShgySlpKKSJ0FopM0UAKDTqjp2aAHipUYowYHBByD71ADVqyjE9zDETgPIqk/wC8cVUb
30A1p9buLxYTJ8xgwVJ5zj+/61NN4jv57mK6D7WhACAfdGPatbxVp1noEtraQIriJVd3zzNnkj6V
r6VpOl67CmsLb+VDaD9/aqPlkK/oa3jB23KRz0Hi/VoxLtEOLg7nBjyM+uKY3inVvPMwkCEw+T8i
Y+X8q7fw2llqNrrDraW8OyXEfmKMLj603RH07UdaaG4s7d44bVslUGGx3GKrl8/69mVY8/fXNQNj
9jaVjbBt20rgZP6VXk1a+W1+xguIRzwDjJ4616drekaRF4fvJrJUIMzHdxlSO1cx4Y0+HWdM1SOV
B/ow81Wx/WoktZefKI4Vie9N5qe8QR3EiDorEfkahG09e3T61mIkikKMGBwQQQR6iuiPijXLmMA3
FwyquzIU4xjpkVzOOpr0fSkz4BmYIqyfbCN2BnH1pqNwOXh13ULddsczAZzjtmmJq2oLI8izPvl4
bB+97V0GleGYLzShfyOR/pHkEDpnPWq+oaGul61Bb5ba5jYcdOewrTk8xq5kXWp6hJsE0kilDuXd
kY9+aWXUtUkjIkll2OBjOQMe1dB4vsksdWj3eZODEhx0yOPwrV8YxWsejaWYodp+zjkDv70ez03A
4FdVv4RtS5lA/wB6o01G6jJKzOpb7x3Hn61AyM33VJ+gJpm3sRWdtRFme7uLnBldnx61XDEHI6jn
8a1vDNpDeata28oJSV9rAeldLr9jodl9otYYit2rKqEkfMTV8pRxq312P+Wj/maVbuYdGZT9cV6L
B4RsksruOdB9sgtvPVvUYzx2q34Y8N6TeaLaSXMIMk7Tfvj1AiNPlDU8vW4nZxh23McZyf51YvdN
vrBUlnXb5nKn1969LvvCGkxXAvIkColp5xte5I9KyfiIIzBpfljA+ydvp0pWQanDy2d7FCtw7fI/
Rt3J9qr7p8Z3Pj6mu412wjj8KaO4i+dhluuc+/pVmws7aXT4/KsI0l2HPmQ5E3/bXoKdkO5xlto9
9dWr3aZMSfeOeRVBlk3bDknOP/1V6p4Iitxpesx3QRYfP+5xgew/GuP8TW0keqR+XGkQYjy9uMZz
1NKUV3C5zEsEsJAkVkzyAwI/nTCMVteJFuFuYxcSxzSeWPmQggD0OO9Y2cY+tZqOqGb8Pha7l08X
zSBI2GUBP3vpTdG8NXmr+YYyESP7zn7v511euzOvhLQQm0fJzhhn8RS+F7lU8K62CERi3GSATx2H
WtJRh+86+z3A5O30C6udQ+wQ4d8/eHIx68UXmgXFpcQQeYsjTHChOoPvit/4eXCprMjMyr+4k5c4
HT1NZ9pcZ8SQkuGUXWQc8AbqhqPNSfzQFfV/DU2kxDzZYy5x8oPzDPt1FTy+E5LayjupJkUPHvVG
4Y/TNW/Hs3ma04Rkdfl5VhjOO7dDitLxzcRT6XpPlyx5jgjysbA/8BOPatIuFnf+ZiMLTPCU9/YP
qDSCGMEx5bvUOjeGW1GeeIS5SH948g5wK6S1vh/whLwiWJJROSU3Ddj6dai8BX9vbx6sssyq8lr8
m843Gpbhcdjn00BrjVILC3lWRpf4h2q1f+HFtLyG1S5V2eby3B6hs7SPzqTwfdRWviGGe4kVUDON
zHuelR6vcrP4lkeaQPCbrduB42b8n2q+gzRm8HKkd+EnPmWUYkII/dnIzgH/AAqnpvhsXmkXepvK
Abcf6gcmumutasVXW2+0o0d1AFtIxyQcdKx/Ddzbw6TqsMt4kD3K/IshwBj/ABpOwHN2ulXd4rtF
CzIpxvxgH8a0dE8OzX99LbzK0SxLubg7sVs6brNvBoX2NLmKGdJtxdxlSM9qdo2v28Wp3kt7qCnf
BtEwGAzY6VCUSbMyBoSXeoLa2UhZcncD1GOtR3uiBLpLeFZgd+ws6/KW9Aal8OazbaVrLXMkmY2a
T5/Zjwa2LnxLZW1oxjkF5ML3zl3Domar3LBZjE8HwmQ22Ljz/L3B+fL3Yzg0q+EI4GtYbqKV2uDg
yJ92D0LVZ/4S20RzepOx3JgWnTD49ajPjCC9a3nmke0aJsmBTkT46A0012CxDL4OTTkllm3Tr5ux
Ej6kIe/86yNe8PNpskPkJIyzR+bjBYrntxW1J4yg1JJoZt1kvnFkkTJYj8PWsfWvFEl5cQ/Z2KpD
EIwf7+P4iKHYZiQWrG4jjmR0Rj8xKkYHrzXa6P4aMVxFIjb4nIAY9q5qxnk1G9i+0OWUZz9D1r0C
XWLWwggVTshhwcdyam1gQeMEsbKxMOB5hHyk+tczeaFY6fo1tcygma8HyndxGcVW8Xa7DrN6ksLO
qqqgA9Pc46VDruv2+oabptlGHVrNfmYjhjUlFzS/D9ifD51a6V5NzlVB/hA71W8O6DY6il/dyK/k
2wLKPUCo28R248MrpYWYzCYvx93BqHQfEVrpun3ttMsoe5TaNnTGP4qpgTaHpFlrWutCn/HqkbSb
c44Ufd96ZLpun32twWMCGOMzBJAJPQ/1qr4b1u10a88+RJWVoXjCp975qr2WrW9trMd95czLHKXC
5+YZ9alPUk2PFNnp+n3X2GKPayMgPvmrXiXTtO0azt4REhllhRxJnkEjvXP63rMOqai12iMuSpIJ
5+U1J4i8QRa15BWBozHEIyS33sDFMDdNhp2l+HtPuZLdJTfh975/eKf+WZFSaHp1rNplhKYrdpZb
oLIbkfeTP/LFq5/UPEEN5pOnWCwlfsI4bPBqSy8WJb2lrby2wf7FKHgxxj609yWba+GNPuNfugSI
rS2nUGAsBM5/2Rmr11b6NpniHUlmW2jj+zD7MGG5FkI6kVxc3iBrjU/7QK/MZg5UdwvY1PqXiaHU
tSa7exT54whTd6d6tOy1IaNWOxSC+spdSSySycna0UY8t/QN7U3WIJSJL2BNOkskmGPJX+EdA3rW
fd+J47qGwtjaRfZ7P/lix4I9M0268Sxtp7WFrarBEzh2/eFuc9hReHYDfhuAthdXOoW9snnoEs0V
FDc4GR3rTTR7WK8s9OVrdoZF/fxuAZG3DOQa4HUtfk1JLNGUJ9kUKpHfFX4vF9yoR/KR7iNdousf
vAMY4NTcdzrZ9Js9HjtRbvFF5suXMwDb+eVX04qXUtFstGinuoRFFJLciPzJxuRRjPA7Zrh4vE90
scSyxrceS26JpBkrUf8AwlF6fNE5+0LI+/y5hlQR0x9KHKyEWfHFnHby2kiEbpraOWQrwMn/ABrk
DWhqWoz6hL5kpP3dqqOigdhWaTWLuLUCabQTSZpXACabupGNRFqQEuaM1HupQ1O4XHmkozRRcApK
KSkSFFFFIBaMUlJmmAq9KTFLSE0zYYaTNONNNIkTJoyaXFJg0xajSamTpULCpYulCBj6KQ0ZoEFL
TaXNAgpc0maKAuPFSIcEGohUi8mrhuUdPrfiCLWVgmnjxdLtDn/lmyjt+NX/APhM0tZLZbGDy7SI
Ylh6B+MZP41R1fQodGtbYXOTPIFfHYI3pWhF4RivxBPp8nmWgAN0+QGjx9fettdV2Hcv2fjHSbaL
UoPscwivW3DacEUy38X6dYTCS1smRfs5iIPUn+9mptO8I6Lfy6kYpruYWwG0IBye9LY+F9E1PVIL
KKW6XEe6UMuDn3NK0u40zKPi1W0i7sCh/fyF1b0zVOx8SjS9OmtIEO+cESTDuPSun1T4dx6dp1/c
vJnY5EW05+Xtmue0LQLbWLK5iUkTwDzvYik0+4zlGfcST1NNDYqS4TZIy+hIpiioRLAc11OneKZb
bR30nyEZHbcXPWuYRdzqMZGRx+Neur4b0IQ2rvDbwwzWW9rhn5DYzxz61cUmCOLsvE11Y2UlmqK0
TSeYM9jmo9Q8SXWpXcV5Mo8yIADHfFdJpuh2N9oN26ovmR3RRZPbOATWI3g3UBNdRZH+joZMH+Jf
anbUbKOr+JZNdZHkVUZFChl64FTN4pvJLQWr7JFVdoLDJAp58K3SWUd8WjRXk8sA88+9WLnwnHa2
/myXqb9u4Lt4PsD0pkmHZ6rPp4lWJYz5oI5HK59DVMszszEZLHPAq/8A2JeS/NGg24+8WXGc/Wu4
8FaTp39k6k2pICA5Uyd1H95TRaLKR5/ZXVxYTrcQ5V0+6affaldahOLi4bc474HWvTNW0TRrrR7M
aRGZA1zjzcfOfXrXLav4O+x2kN0khbzJAhRiPlJ+lPkDUy/+Eo1R41RrjOF257lemDT7fxFq8EIS
KVxGucYBwM+9aV/4Z0vRpFt7q5k82SESDCgoMjI962/DNpbXXha9WXaB9rjUNj5sZqXB9wuzjZvE
WpyNue4YnGPw9KqXWrXd2FE0hkC/d9q0/FHh4aBffZ/MMgZA+fYiq3hjTItV1a3tnJWNjyQMHH0N
RyK+47srvrF/NCIHnkaMdEJ4GKfFrGoRJsE7BOw3dK9Hn+G+jIknlzy8Kdo6cxis+y8EWhgmWcHz
BE80eD6etVyeYanBpq11AHRJ5MSNuYZ6mopL2a6bdJIzkdCT0rr9C8OWF/YXdzMGLWk20D2zVTxV
oltpF5AtsN25VYx+rHtScF3Gcq7setRZ9a2PEXmrLF5lklg3lj9yvTH94/WsbriotqM2o9L1O4tv
NCyGEDIJJwR/siiw0/Ub1JBb7yiff+bCj612ur3JtfCvh8W67N8XzHHPT+tR+GpFj8La5KqYkEmQ
xHJ+lUOxxcWl3c1z9miR3m5yoz2749KLrSb2wnSKQfPIcLtfPJ7D/wCtXUeAbjz9auJJU8xvIf5i
MhTjrVGzuZbjxJaechkC3WAhBO0b+po3aXcLGXeaLqNmoe4XjH8TZP0qSXQdSWyju33BHGQCe3rW
x4/upDrMkAOIw4wO3Wtfxzdvb6bpKwjYptVBx06d6ULSTfaTX3BY4+x8O6jf2z3MfES9ycZ+maZp
+hXmoTNFCfufePp9fSuytLpovAZdExJ9pPPQ4zUfgCT/AEbWpTt8w2/Xv07ev4VT5bhY5FtHu/tw
sVw8p6bTn+WasX/hy406aGKRw7TcLt5wT2wM1reBp/M8S2rvgjY/zMRgenJqtcXD/wDCViOZxBEt
+pCk/LHls9avSwhk/hO5SK5KzKXsxmdBnK5qPSfC1/qcM0yny44Rku3RseldtqF3Go8ReY0So8IE
Lqy7pT74NVvCWu/b7a5glhgiEOnMFy4HmYHfPem4x7oLnKr4dZNOF9PeC3hZ9o4zk59qWw8Mi/jv
JlvcQWibnbZ/9atHSrjUZoVVJrb7Kk7b4pSP3S7uTg1PNchdQ1NNHureOFwu+B2UIxHUDPBqW4iO
cj0uxa5SFtRCqx5cxkAfjWk3hWM2gu7O58/Mvlr8uM5PUd6seI/7Pnm0pEMIfgXjIVC8nnJHFLqG
tWun6rZw27o1hblWby2zn1+tSkk9xkB8Kb98CXO+8RdxtsHpT4PCPzW8NzM1vNcD5FAJGe2TXQjX
7W3mmvRc2bxNH+7RVAlzL/CTSv4ltruazuEuLSOKPyjPDMMzkw9oTWjcQsc0vhNraJ5NRdoVD7VK
5OcnHvVe78Ny2NyIzkoyhlbHUHpXYN4mg1SNo4JI7SRJZSDcgYaGX098dKzNd8UQRTgxMshWPbkj
cCR6VErCOfs9tlqKRuQoz1PbPrU2sw3RvoreTcUmkAjK9DmsqS+Gs3q/aHSFGOGdVAwPwrTn123e
90+1ifFtYSKfObluO+fShPQCXX9CtdJ/ciZmuU2lgehDf88zT9Q8OWen6dDNPKwnnj8xBg7T7VX8
aapbX2rPcQzGWNlTHopFT+LdYtL+z0lbe43tDFtZcdDirVrAR2Xhm1bSP7Ru5Z1V2IiEf3fx9qbo
Hhy21G2vLy4Mggtn2fL1PGcipbzWbKTwlbafHcZninyYwlN0XXLOy0DUbKWcia4O4LsJxxjr2rGe
jfexVyPRfDtvq2rT2sDy/Z0iLeYPvkDqn41ANEs7jWrezsWkPmSeTIJD8y4PJ/Dml8Ia1b6TdTz3
Ej7HgeNNq9S+eo/Kqei6laWOux3c0kojim8xsJlsZOML3960ha9O+3K+f1Jb919+hc8RaRYadffY
7VZDJ5gjk3HO44/hq94l0HT9GjFphjdbI8NnhvqKydZ1K3u9aa7jdvJM3mbuSaf4x1231u/+1WzP
/q/4hisr/wDp0behqX2iWGmaRYS3AYzXdsZA6kfKccR4qbR/DWny2OlSmMXJvZCLgvJhoR/sDvj2
rH1/XrTVLHSreISq1pbhGL9D9Mc1ctPF1pFBpEcsEm7TSxTZ91yfXNby+KVvhsiS3p/hK1u9XlTP
+gQXfl4z88vP3cdcVOvhK1OpayVRPI09ciJz149a56DxKY9Z+3kSCHz/ADzEjYzznFaUnjOGS51a
QRSfZ9SGGXOJY8e9Jva/ZW9AexTHhu8uL2ON444Ely6FSAmwe5rpNV8GafHJo0NupBuj+9fPWuU1
nxMdQW1jhR4Y7dNv3vmb8auXXjJpINJ8hDDLp2PnYmTfiq54W2IN4+F7Wb+0bf7PBF5Kk28qsC5I
/vjqKfB4V0+38PXcrKkt2gyZgRgZ/hjHtXNz+L18q78iHy571ds0vnEnH+yO1QWHilbXSr3TvJDm
7OWk3c5+myp5qfYDqYNCtrRbCJYIJROIvtJlxuxN/wA8akvPD1poqgwrDM0ss3N5jCxRHoma5aPx
Y4FqZ7dJZbZCkU5JBU9s1HJ4wmkjRLyJbrym3puJ+TnPHr+NDqU9hlTxjYRadq9xBFwqYPHTLBTx
/wB9VzpNX9U1J9Tne4kJLyHJz/Ks0msZMQUhozTSazAaxqI05jTM0CFpN1ITTc0EkgenB6gzS5oA
sBhS5qtup4emMmpKj307dSEOzRikpc0FaC0005qYaLlhSdKcBTGpXEG6jdTKKLjGu1SRNUDVJFTQ
mT0tJmjNIkKSlooABThTaWmA+nKeajFOBq4DO98U6hb67bWl9GygxRJE0GeQR39au6brOn+HLGOz
DrdfbcfbJNxxGD/hXIf2Pc21mt5NlEfG1T1OfSrb+H74JbSBQwuMbCp3AZ/vYzit1cLnb6Hd6NpE
mpxRahEv2qLMD5OcmodMvNJ0fVYLmS/EzSwOLhl7MRx+NYVv4IvZnlh8+EGBBM/zZx9fzpP+EKuZ
bq1gjvIXa6/uk5Ue9O8ijaj8WW7aNq9rNOWllmZrYHJypPFYWga1baNBezFsy3CeSsPoM9akn8Aa
hax308uVS045/j+hrM03w9JqkEzxSZmjH+o79eprOaYzCuJfMldv7zE/maYHC8f3uB/P+lOniaF2
Ruqkg/UU1VyCf7vP9P61ktxMfCwWQE9M813PibXrHU9OsYrZ5A0EQRgRjJx1rhIk8yRVBA3MBk9B
k9TXex+EdPj8uGS6fe8e/wC0Bf8AR/purSKbJZDoniWz0rQrizdXMskgfPbrWvD4yW9vJjDaOVms
/KI/izjtWFo3hKTV5LkRsAsOfmBHzY9uayH0+6ivTbRHLhsKA205+tVawjutZv7G00O1s/mL+YJS
hYbsZ5HHSsS48T2T2RhW2dyRgCR87Poaw7rStShZftKPubhQzZ3H2OcVNJ4R1VYfN+zkDbuODnA+
lVFNlGM875IVio3Z2g1uaX4ll0/SrvTmj8xbk53E521f0Xwd9v025u5ZIl8v7mWAOR2IrkZ4Gink
jOMK2BiiS5QR2Gl+M30+xtrQRKywsWJ9c+ncU3UfGLXlv9nWEKgcSLnqGFcdsbIC98A5I6Zrqda0
JLLT9OmMe1pofvhs5/wo94dx914vN4oM9pbPKIvLEh6jHfFVrPxdcWFhJYxQoUkk8wseuc5xU0Pg
e8lWJg8e54fMhTPMoxmtrw54dto9M1C+vIVka3k2kemOMUnzD5jlNa8Q3OsypLKACkYSqumatPpl
3HdRY8yM5GelbNroJ8QahcfZtsUEY3EnsKi1rwvJp1pFfJKJon43AYzis3TtrcLl9viJqzg5EPQj
p61THjjUx8uU5DAtjnB7VnTQ6eLCN42ka4I+YMMKPx6VlKueuM0rvuFzvvDXiqx03S79LiTNzO25
QIcqa5fU9audRuDNK+SPu+w7YrJ6UMpzjj9DRr3Kuie5vJrogyuZCBgFjk49Kr9xzSuVJ4G32zmm
8Zp/MV2bj3us31qiO8klvEPl+U7QPY0lrf6qbd7S3kkMT/fjXOD9a7bUZYtH8KaP5CgfaI5N5I6/
nTPCZgt/Des3wUGTcnzY7H+7VKCcZa/ZYcxw9neajp87C1LpM4wfKBJI9O9LJLfwT+a/mRTk53YI
bJ9K67wIsGp67PNOijFq7KOwYd/SqMd4uqeJLSKYZVbjbjHYN3qacF+4TfV/cO5g3o1CQrJeeaW7
SS9TT7qLVrmzDTC6khQfKDnGPY+ldD47vFbVpbIDCI6qMY4A7r61reNpxZ6fpVtCgVHtV6DGcjvS
mlGLs/tv8wWpxNna6tc2hEHnvAv8OSU/AdKZYQ6pKZLe0Ep2/fWMkdPX6V3Fs6WXguOaDiYynNRe
AX/0PX7jA84Jw3rndgD9auyv8l/w47HFpbX0VwtsI5RcOcBF4b3z3p19pN/bSpHcQsJZH+XOc7vr
XTeCrhr7xXBJON5EUnJ/hOO9Qx38114stIpZdqLfrtBGcfP0B9BRG3NH56gzLvNA1W0t3kmjIES7
pFXrGCcc/l6VV0/Rr+/jlniVvJhjLNJzgYGf0zXod+oe38VMySR7ZE+YDAkAP3Vz1z7VJ4W1WyvN
Nv4baBoI4tNcNFx88hQbj9STRyLUg85g0i8uoXnBKRpn5ieDj0zVW1sbm6ukghy8jnAxXo8f2STQ
NHhW2FwXuGEq8ZQZ/iPas61vdP0DWZ7eGEOHmjCS7gfLJPO00KCA5TUdCu7C8SzkyZnx8qf7XSl1
Lw1eaXdQ206/vZcFQOev0rqPHLlvEkDwckCP5w30649Kva7drbeIdFvJmDRrGm5twbBxjnHpTSiB
yh8KXaxnDq8ijJhXlhU9t4WvCFDukcr/AHbcj96fwrtYdUtra7v7mWGCOCRJCtyGBeb2x2pW1m1v
NSs75Ps/2dRGz3DMN68fdA61b5e5RxqeHbkRsZJvsg3bRv6Mc9qwtXsLjTJvLm3ZIyCe/wBK9Hvd
cttTiRbJYZNs86MLkqNozw/Nc14q8QWc2qSFLdLjZGqZYgjcBzismkByFtA13MkKttZzgE9M1aGk
3C3i2cgw7sFGRwc0qMmq3KKgjtecs2cRqB3rpjq9vPq2kIjIy2zrvu3I+cj1oTjzR9fvEZet+HRp
ICmcSSfKGj6Fd3pUmo+Ff7PsYp5bhVnkQOkP95T6U/xldRTeIJ5IpkdWaMAqRtGMZNXfHt/FdppS
wTRz+XbKrFGHUD2rS8eV/wCIT3M5fCoXTI76a4EXmD92uB82KTSPCw1C1uLya68q2iOzcO59/atX
XdUgn8KadbR3EZeLmSJfvCo9K1K3h8I3tsbmMSu+dmO3vUTUXKpJPsHYytJ8MjVb+a0S4zDajzXl
UfLgbsfyOaZb+Hxd6zHYWkvnLMeXPRVz834nt9K0vA+qW2mjUHnu0t/NtmWMD+J/mx/OqPhS+hsd
fS7ubhkjDNmTHUnOM0Rj7qfdCDVNBtbbUIrO1maR3kETKc5B6ZqTxF4etNGXyUkZrgbMowxnd/zz
6VDNqNu3iD7UZ/3YvPML98bs07xZqdvqeryXEEzSRfJhvYdcU1EC5qPhuy0mwtnuJJRfXFt9oA/5
YnP/ACzq7aeELWSPTjKLhzeRs32hD+5t8Dv61meLdYtNTGn/AGe4aT7PZiFlPqK2rTxVpitps251
+x2rQtBtO12I9elV6gUvD3goaheyLO7LaI7Ks3eQj/nnRbeD4ZZNVkPmyQ2E5iEeQsrEfWq+h+Kn
stWM89y4sBK8whXkDceKux+LrGT+1YH8xY7ycyLMvXBNP90SYkHhu8vL424ga2VWy4k58uPPWtLx
X4cstCuLFIiximiDvIc8nviq2teJzdXUDWG+2SGNY2KnBkUU7xL4kttdeyz5223hCvnqSMZx7017
KwFrxD4asrb+zY7IEvcoh3N3LD3q7e+EbXTvD01xgPerOoLDlV9uKyPEXiSx1W3tY7dZ42gRUGcA
8DsaE8Uonh59OKzGR5t3mM2enY070rCZpax4ThbTrWexA8w2YnuIgTuPH+sFSeGvBcFxBNNfASPL
as1vEGBKnHWUDpUTeN4vsqBYCJhp/wBkBJ4xjGce9YOheJn0qS6kl8xzPamDlshc9TisZOHQRzky
7WOOmTioDU00gck+5/Wq5NZMoCaYxpajY1IDCaTNBpuaZIpptFJSAKWkpaQhKWikpki04NTKKY7E
gen5qvnFOD0hF0imEVKwpnSmjaw5V4qNlqTdTetJgiLZSbalpDWdxkDrxTUNSydKhTrTTAnopBS1
RA6ikzS0DCkzRmimiRwqRSBj61HSg81Udxno3i+4jv8ASNLuLZgY4YFjkC9jjHStDwrfJoWnrJqL
q8d6MWi5B8sMP9b7V55DFqMtq7IkrWw+8eRGOe56dalls9SEcDzRSiNv9SWLYP8AuV0JvfuM9S8N
WdzZ6rqomZZme03qGb7wJyBVbSYJrfX7O/utkKTrJtXdwMDrXEwaT4gkfCQXW9kz8rHJX39qJ9F1
xZI1eC53ucJlj1/OndroVc9Hk8RrqWma9DPKn7t2CDIyy44x61x/gm5g0+4v72aRVg8loQhOGz9O
tYw8OasPPJikXyR+8O48fWqlvo91eRyvCWby/vKOvucVnOTYFG+kWW4lYdC7EfnVZTw3uMfqDSyK
ykg9RTFzWPUCSHG8bjgZ5PoK9N0xdOtvKWTVFuNMMPzBiNyvj7oB5615jGCzADHJxzXaW/gbU5be
CYS2oFyuYVB5bArenewrmh4Z1i3sdQ1BDLshmhZYz6Z6Gm6XcaPY6xI084l+Rikp5AmPSuRktLmO
cw4O8ZBwD1FQeRNvK4YuO2DTad7jud34l1qz1K005I5V3wSgtgc7d3+FL4o8SxkwHTro4ECwyAeu
Oa4R4p0++rjP+yw/pS/YLvb5gjfZ64OKd5ILnU+G/EVja2N/YXT+X9pO7zMc5Nc1qEtv9ocxOXTs
xGKqEv0rQ0HRptcvVtoxncOtJtyHoZeVdlbqK7TW/EVjqWk2FtGW861g2njjj3rn9W0ebTbtrVlI
IOB71FNo15aoryxMqNj5sHH0zTSZB2dr44tIRo25GJsLRo3I7nFV4PF1pHpWpWRjkzdyb1PpzUOp
eDvJ0ex1C23SGeDey+nqazPCOjR6pftb3OR8jH6ECk+a9ir+QugeJk0Y3StGWW4UqfUA+lTaz4ri
vdOttPhjIjgYtuJ657VSk0S4utSns7SMP5RPJ6YFMvfC2p2jxCSMYlO2M9ifTNJw03Hcgn1YzWSW
nlRKE5DqAGP1rM381s3XhfUbSIySCDAGSvm4bFVLOxgmt7mV5kRox8qE8sfzrOURlHdS7qYeppKg
Q+m9aTNFUgOivfEN5qdjaWUqJ5VouI8L/OnWmvXtpps+mxLG0c3XCmusu7Wz0fwxpjpEjG+hLTE4
B3Y7VH4TtrS28PalqbRJJMJCFDYOM/WtVBDOO0vWL3SJzLakK7qVPylvve2KaL+8t7wXOFWbO7Pl
lTkmuq8G2tpqmuXUzxABImkRT0DYz9OtVzLDrPia0gkSJY/P2ttI5w2MHFHJG6XcDAv7+7vrkXVy
uJOoYrj/ACKn1LV9R1WKLz8tHGAFKqQMD3rovHc0Bvxp8cMcaQzLGpUDJB4xV7xrJbaVp1lawRIB
JbDPAyCR2qZ29m7fzW+4aRxyatqU1mLSPc1uvUKmQPqRmm2Op6pbJNbWJZTKMuqpk4Hrj612Vl5e
k+C4LmCNPNnkPmMwHzD0571F4GEX2PXL5lXzY1QK2Pu/e/SqSXtKn/XpfkOxxlrcahZXR8gPHOeN
oB3c+womW++0LLMjLMzZUkEEmuu8Fzwar4rWWdV4hlbGONw6GoYb86h4rsIZQNiXnV06jPpUU43j
C/b/ANuYmjDvP+EgERe4WfyiOSTxj3/+vVfTk1Jo5XtVmCBSXK5xjvk16HqZiaw8SKAQRcL8r/dH
r5dTaDJpsmi6tbWeNi6eTI2P49pzW/sYrW5FjzWD+1GjkaJpljTJY5O0/Sq8cdzczARl5JmPRcls
/QV6YLO1bRtBtlB33jMrun1/irL0mPTfDuryQH95d+cqRN1HJpcse4zk3sNXW7W3kSRbnaCFZsFV
9TzxUl/pOrRRobkM6u21TuL/ADegNdn4j0yXUvFcpgZkCwqZWHHy45A9zVezu2W902GSIxaVAcRe
YDl2/vHPrU2g+wHLT6Bqttb73VigxlQ24j6jr+dOj8M6rNAZtuBjO0thyPZa9AtpLKCbU5ZYzAjE
ZkdspJzxtWpnvbF9dglEYaEJn7aGHlLD5XQinyU11RR5taeHL65UlcpyR+9OzJHYZNZF/a3FjM0U
oIZSP16V6zeXdleRWBt4FuFVmRmU7fIPnfePsBXJeK9Q0htZuNyecAEHyEYBFZtREcpZWVxfSeXE
csw6Z609dOuDdJahT5rsEC89at2SG41JP7MP2duCpduBjr1rq472zl8VaT5RjLRSDzpTgLKR3HbN
EbXXqBzGr+HLjTHiE8qO7HAVPvKT61JqHhi4061FxOytnbJ5bdfmHFaHie5Mnia5YEbTeLtIPuKu
/EG782/t1QqyraRg46ds/rVxacIv/p6IyLfwrPLYC/aeGBXB2Rt1YD72PpxVfS/DE+qwTXAlWGGP
5AW6PycgfT+tdH4oul/4RbQ4h5GQvO373RaZa323wNcxh4lkNxjyz/rOc1Uv+X0v5bf5iMPSvDTa
tLMqyxRLarl5PQcgH9Kjt/Db3mrJYRTRyZVmMo7Kv3q2/BWoQWOlawZZoUeSDam/7xJ3ZB/TFU/A
d7Baa08888ca/Z5VDt03NnG3+tPR+zfV0m/wGUL7QUttSis4pluTKdgcDkH3FSa54ei0QALcee/C
yJjkd+nWptKvgPFEU8jpj7Vnfxsx6+mKj8TXiXWu3MqzIw+0D515TH4cVK0p03/M9fL1EibVfC0O
k28bPOBOyozxkYB3f886uxeCoS0UEk0n2iSzF0rLzb8joT/k1B4+1O31G9hlt5hNGkUQwP4SK3R4
r0xZYJhO32RdOETWeM/vNuP1q01rcGYfh3wXJrFzIJSbeFSy+Zzh9mcBfWm2XhMyW17eSqzW8EzR
IqfeY54q34S8Vi0vf9NnKWkMcrIuOhfpUtv4ns10+5svPaNn1AzeZj7yb84qH7EgydH8MSalJcll
ljjtQWZP4yB2Ge9Gl+H7a91drWcvBFsLL5mBK5Hb0rdm8ZaY0urrHutxdKoSYcn5cc8Vh+INcs9W
ltPKYosCBGlUYc+9P91YbNe48G20sWntbI9s11NsInOeP7wqceDra4E0UETwyxEASTnKyn1ArNk8
YR28WlwW5aZLFsl3B3H6ZqU+NUtVlNvvklmcOfM5WH/ZWhTw/YkuDwZaGT7G8M+7y8i8z8u+MdMU
1PBlvbPDYSwmc3ITfeZx9nklHp3qn/wmttG8l0puftMibdj824Y/6w4qKTxskhivZElF5GuBtP8A
o57eYVqZunbRDON1O2W0uJIl6IxX8qoVcvZ2uppJj/GxNUjXOxgTUbUrGozSC4hplPppoEJRRS0g
ExRS02mgYtFGaSmSwNANJTaAHmm5pM02pF1NiRahNWXHFV24pmqG9qQNSGmZxUsCUmm5qMyVGZKQ
ySRuKiXrTGbNLHQgZYFLSClqrGbFozSUlCC7FzS5ptOFUA4U7pTRTxSW4HoesQxWnhPRWtgP3wPn
leu8jnNWvBoXUbeS31RB9ihGYHfj5+wGetcVb61dxWj2fLxMOh5259PSpf7YvJLOO0OVjibcuBg5
966IuxR6b4ee6bxDcrd7vL+ySCEL90oFOMDp0qjZXEjeIdP8oTfYVudq+YON2e1cbD4l1mOSKWOR
t0abEby8/KePSln8Q6zLsZ5SCr7lIjC/P27VfN5FI9ZutVtLxNcgWJY5bZSDIAPmrz/wHIBrFx5v
+o+zyeZnpnNc6urapG1zteQm5H73g/Pn1qrFdX0SyRw7trffKg5/GolLQehHqrI17cFMbfMbGPrW
eakfdn5utNKmsVuS2C8n0r1y61ebRvDHh+aNQ8n2bhs8rx+leSIvNb6aVrlxAmUneHb8g/gx7DpW
iuCOu8LQwXNqdSuXR5HvNrRk84J6/Sr0cGlweJ70L5ZRoM2+SNocivNWa6tiYhJJGR1QHH5irNlq
ElvMkrqZihBwx61cW10A9D1yG3jsdFkkjQBp8ynjkZ/Wl1bUSktwtrFZfYzDglyv93sPWuJ1nxJd
arDHCY/LSH7ozx+Has2TT75bb7U6yiI9CScH6dqc6mmwWKU0uZH4H3j06Vv+CtUTTdYgkkfy48Nu
PpkVzvltISAegz1pixu7BVyT7UoNsTO9vjYNr8Vze3YmgkYn92c4z0q/r2radcaBNbRzW+9JtyYP
O0dq838uQYUq+ScAYOa0NQ0S50yONp1ZRKu4ZHGDVvm5Sk0ej2fiPSzYaOTcri1siJrfPU46Y71y
3hfV7C116W5uJBBC3mbTjpnOK5NLe4kH7uNyvqAcf4UsVjdz58uN3wcHaCf5Vn7zHc7fQ/EFlp2p
asS67bncEmxwM/xVQ1TWIGW0iN/Ld7Jt+QcBBn/lnWboXh6fVb9rF90ThC2COePY1R1XSZtOlZWT
Khiocjg49zxTadgTOm1XXdPubIxiVpZtuARxj/ermbS7soYZ0mthI8n3X9PemSaXcQWy3TbRHJ93
kfy61m9ah7bjJGI3EjpTTSUVl1EJThTaKaA6zVvFVtqOl6fYCBg1kmAzdGJ7/lS6f4oW10WfTPIz
5zljJ6egrWl8M6bpeiWU1yrGa8TeJP7vGQKPDOhWX9j32p3kPnqspRP8a2jFtVGnpb3h3Mbwx4kH
h+S6cx+abiJkyT90kdRVHT9U+walFeRxKRA5ZF/DvW94Q0O01jVb6WRcwWqM6Rkj5h7io47Sy1Tx
Da2tvCI4nOHXPGdx6fhiiK550Vf31FtecQuY2saxLq2pG/kTYxYPgdMg1Z17xHLrog8xAnkqAD64
GK0/GdvYWt79ht7cRlJFQn1BPNafi3TtN0LTYIRCpkkgU7u+TzxSa92625pffpcEzlj4kvJtIXSt
i+UmcMFy/wBcjNJpWvXul21zawjctyMS5XrXXWltZ6V4WttQW3ike5bBZsdP9n/61M8HWlqNP1jU
X8rdBtMakK2M/wAqqFNc1XXan+nUfMcdpWp32kXDXFm2yQ9eN3XsRTXurxLxbttyTbsqSCvJ9M11
HgtLXWvE+6SONY1jMnl8BeOhIpkF5Fq/iq1gkgQxxzhWCqBu5+/irjTThTV/shcybvWdWuIWWXcq
P9/5Cu76nFVbDUdQsoJo7bf5cikSEKSNvuRx+dd5qkUc+j60wkWYrdRqGKAfZRnp74q3o9npiaFr
EVm8dxttcvcYHXHSp5Y/zMTZ59a6tq0cP7je0afxKCQv4jgVSimvp7gzp5ksobfuUbip9eK9FTSL
YaRo1lA7wtfg7sDPmNnufSmWGjW2iaTqQlfZcfbPswlhG47T6UcqEcTFqOsy3LNHJM07Da2Mk49D
6Ul5LrO1UufOxnK+Znk+3rXSlY/CF8Vf9+Lq0yHHMqlu/sa6eIafPD4e3KGJ3ORLgFfwPNLliB5l
cQ6z5IM/n+UOxJx+VPisNXe3LKJvKC5I3EDb9K9HsxYTTap58hKKF3rc8IJCf4M8Y+lSj7CviFVw
fKWMjg/6H9nK/lUyhAo8utLLWJI3+yLMqHg4O0N/LNZNxBLFIySqVcH5t3XP417DqC6eG0fyd2zf
Gytan92sol+fzMcYxXHeKpdHk1e9Z3J/eDmPp0/KldIDjYllJ/dhyf8AZBzj8KtWlvc3M6wxhzKe
g5B/xq3pgkl1WMaZuOGBBfpt77vaux02SzbxpY+UBuA/e7OF84DkjNVFXav1JOO1LRdQsfL89TmU
kL3JIx6/WnXfh/UtPtRc3CFI26Z4PNaurSyP4rkj5x/aQwo7HzhV34jSONYMW75PJh4XoTgZ3e44
qm04q3/P1L7mM59PDd/JZC7+XYQWGeuF64p2n+Hb6+tmuk4jGQN3Ryeu38ua6jxxcKmi6CihVP2d
SSOp4702eby/Adt/t3Pb73B7UP8A5fS/kkl97/4JJy+k+GrzU5rhYvl8kDzGf7i8kD86S08O3F9q
D2URjDRKXkb+AKOprpvCEmzwrrp/d8jP7z73Gf8AGofh5dJHeakzeV/x4OBv/H7v9fwqkvft2hzf
gBgL4euG1CGyRw7z/cKHPHvj0pdY8Py6bMkBnW4dmCbUIzn6Vo+Ebpf+EohkkdUUeYdzEBfzPFV7
y5WTxUJN6hReE78/J97r6UtPcV943bAbrHhZtFjjDTo0rlQ0fTG7pV4+CRHI9q1yReRWf2owgfJt
Pbd0p/jnUYbvXSyyI8I8vLRkYwMZ5HHFdFceIdPD6hKL23az/s4JbLxv37cYNO8db9/vBnI+HvB8
+t+c8jeTHFE0gb+/t/u+uaW08Kl7Ca/k3rGkhRNoLFsHGeOlbfg/xUkYngupraOKKxkiiGOpPSpL
HxLZ/wBmWdp9o+zbLxpLgbMh1z/KpcaW9iTnNJ8MSX8d3cT7ktrc4YBfmZ+3HWskafK1y0EKN1+U
OCpP4HFd5/wlOm41SO1kaz866WWFx3A64HvUMviXRJr2ZwgyLONYbkr0cfxGk+QDnLHwteXV+liy
+QzLvb12+oBrXHguG5Rk08SpIlx5chueh55K+1WLrxhaprNtfxHzFFsbeUgc+m6lj8ZW9gH8lmvW
kuBMWfjaveMGnGdJfZERHwVb3Jnt41kjuLXafNb/AFcnripf+ENtY7k6c8UjTKhIvv8Alh5wGSKZ
L40jtWnmgLySTlf3T/dQdcA/WmS+NYvPkvw0vnNHj7N/y7rKwwWFE60GrKIHn9wCkkin++386rE1
PM2Xb3z+e7NVnrmZQxjTaDTaQh1NzRmkpE3CiiigLiGijNJRcApuaKKCRc000tNoAWkpKM0CN41X
kIqYnIzVOQnNDZsgzUTmpO1Qsc1LYyNjTOakOKTipAjINPjpGYUiHNOJLLS06mLTjWiZImaM0lLR
qAuaXNNpQaLhccDT1PNMpwqoWb1A719Og0zwtBeIqySagxUsRnaAOx7Vb8LRQeI4f7NuIQghHmCe
JcZx2Jx3rmrfxJINJbTJV82Nf9Rn/lkfap7bxJJa6eLS3QQvu3NcL99vb6V0qajKp1XIvn/+wNHe
aLPG3iFbIwJDDDbOi7kHzAD75qK/uo5dXsdPZ7eeIXP3hGMDn7ucVztr44ltpYLj7JFJLGmwseWl
7c1WuvGKybXjs4Y2E32ncgycntT5loUeqNHo9zJrAihRLiKHa/ygZHYj8a828FBZdbktZADFKsgO
RwCOlUE8Z6gtzd3a4zdptk9AP8+tZllr1xp7TmHAabO5u4z1waz5vedl9iX/AA36jIddiWDUrmNP
upKwH0zWcWqS5leeRpHOWY5JqDFYRZLRKrdK9u0R4pNJ8MoThih8sY4Jx1NeHJ94V1lv4n1eK2ji
WUhEGE/dHoffFbwlZbAdTPotlHbapqsyCWdL/wAkKOnLe1S/8I1psmqW54VX083DRerY6VxSaxqy
lwkjkOdzIVJGfXGKQ6jqkk4fMvnBcDarZC/T0pqo/wCX8AR1GoaZYnw/Lf8AkJHLFOQi9MgH9av6
o7XfhLThbxRvgZIGPlNcTcS6vcRMk32toh8xBVtv16VWjudShgaOIziE8Hrt/OlK8ug2ZkuVdhyD
mt/wm224kD2yzAx/eOCy+4BrK/s++lR5/Jcp/E/O38+lVY7ieB8RSGM+xx+tOD5CTsvEu60mtpcw
nIXACgHr/Fitnxuft1nZyCWP7OIY88rkZAzwOa81lu7iX/WSGTHTdzUT3tw42tIxUfwknFNz7FI9
bsbXTbG3aBJIpYH0zcJGI/4+COgrM094P+EY8uzlijvPtbbmJUHG7tmvNvtlxjHmvj03GmpcOn3W
Iz6HFS6jGrHo3hu9Wz8U+bfXUR2WuGmyNpOOnvUPje/s9SihuYJo9uWBtV7HPWvPmdmOdxz9aaXb
1qJSbQ7o3LiWy/s6JUuZHm3fNEc7UX27VjHHamA5FKtY9QCinUhpgMpwqM9aXNUgO58Ra/Z3mi6R
bxGVmskw+fUjFN0zxBaQ+HLnTN0wmuH83/pmBiln8IQWmjQXk90Ekuot6D/lmcDO2m6F4Vhv9Ol1
G5kK26PsG31Hf6VoqX8V36Ln9AK/hfxDFoct5JIpZp7cwrjoM96p6NrKabq8d46EpE3GB1rQ8K+G
7bWNRvkdy8FrG0qlOQwB4BI4psei2Op6/a2Fm0hhlK+ZwcpzzwOlONH97TS+LkfL5RsBT13VItT1
Q3xHDPuA3dcHpU3iTxF/b7Qt5PleSmz726rnijS9N026Sxt0xOJgjZbpk46D1rQ8T6LpmhWUEBgb
z5IQ+4nBJP8AeHUfjRTjBU3Z+7ztdfi0uO2pht4j36DBpQjJFu2Q4bimaN4mk0mxvLWKJWF4CGLD
n8M810NloOnWPhuHUrmDznuSSMOBsX161F4T0HT7yx1XU7iFZUgOUV3AwPoa0hC852eqg+b0sFjn
NA1x9BvHuYkVmdPL+brUEGqvb6kL6AYkD78e+c10/g/S9P1zX7oYVbeGAusbeu30qO1j0zVPFFnb
LZrHGZykoiI5cH/0DFNxT9lFPVw0/UfQz7zxRe3cE8KxwwpctmQKPvH1qHTNdvNNtrm3hXMd2MSn
1rtdT0a0l0q7LRwnF2saPbAAoC2ME1eGg2i366YqwfZNnlEcfac+T5nnetQoRuScDB4q1O1jgSMI
xtgVhY/8ss0kXiTUk8yKN8pM3nFMZG76V3T6La6Ra2AhEBa4RZJfNxvn3HHlLmrd14estLguJoPK
tZGuRF5sgBWHdH0Aq+RAeZtrepSXH2iVv368BW7D6dqLjVNUnaN5S4K/cwCPyr1I6DpwWS++QzCx
UtNsXYWP8a0yw0iy1W3sZbgpcOk7fvQFGfLqXCIzzK81XVZI181nRD3KFd34mj7VrDQkYuvL28nB
xt+tek2djY6guoRzyC8CzwhVKhfKOf8AVjPapVtLRtTns/tGYvssq/ZcDYPLHyNnpQ4wsB5fBJq5
hItBdmPHOMkVi3Ak3Evu3ZOc9c17Nc29ja3Wjxwv9mB8n5UGUk5/eKSOK4bxLY6Y2q3Q+0eWDMTh
Ysj9O1ZuEU9xnJW8txDkwl1JHJTPT3xU1q14848oymZuhXO7n9a1NIeSDVI005PtYPDZUbJE7ls5
xXWeHobODxuvkgPGEYtjBVXx0/A04xvON9tfyEcPcWOp208RnhkWZ87Cxw/bP9KkvtN1SEJPeRTg
NnaWOc9M4rWe7a+8S28b58pbxSq9ly3O3HY8Vf8AiJcOuv3EKkrERH8o+726ela04c1NP+ao1+SB
7nNSaRqX2T7VLHL5HYmn2ui6pdW7TKrLEoyN3cd8flXYfEO48uLSYovkVrBM4/iwq/yz+tLqMyxe
CdGUR4Jd8v6YFTUpctKtL/n3NR/FEs5HS/D+o6ojtbjKIcHnHJz/AIUyy8O6hqF1LbRhQ1v80pc/
KvUD5u3euv0J2TwPfsiDd9qb5j3GFz+XH50eAJCLXXmcRlntBj5scDd/LiqUaUHKLWqin98b/qSz
jf7Fvxqn2CNczf7Jz0+lPvNDu7WeKAvvkuOF8k7ix6YIHv2rpfAMif8ACSJNM6keRJy7ADp6tVa2
fzfFEDkLgXucZGwDzOuemKUqcebD6q01Lm/4I3sZ1/4Vu9LeGLzI5HkYJgHlZD2Iq3L4OuI0vC8q
GSyUNOn90Eetauu3UE3iUyGWHyheIxZGBGM9QRxXS32pWzrrRlubQrJGiwFGXLD/AG8dau1F3ulu
0Kx5/pXhC61K0ubxcxJbqWIPVsegqzaeDJbqKzdrnyze58rHPA7mus0fX7c2N4txc6fERYmCNFIG
7ik0/XdMWLSNupWqrDu+2KTk59hR7OhuI5KPwa/7+S4mZIbaTZvHJdumQKtnwJcxSsZWb7MF3iRB
lyDzjFa6+J9PkiuYYLtIWN7I8TzrkMn0qw/jnTX8y0E+0eXGFnYfKGjHXbRzUVpYDnx4D8wq8bub
Nk81pj94Ae1Kngf7WIGsJHCtNtb7QuMAdetaw8eWUYW0WTcvkEfaAOA3rioE8d21gkCI/wBty53y
HggH0HtSc6XYCn/whEd3DJHYtKZYniVjcg7Tv6lc9qjuPB1v/pkQF0stvHu8w/6hzEP3mKsDx1b6
ekjwXD3sjzxsVfgLFF/yyFVbrx1bLDfzRNLJJcxlVt3T5Y/N/wBZt9aylUp9ECZwlwuyV19GIqua
WWfzGL/3iT+dQmSsW0O45lpm2jzDTTJUiFIopm7NJuoEPpKZuozQA7pRmmE0maBWHmm5puaM0CHU
hpM0maBC0UlLQBpCQ4qJuTUuKQikzYiY8VDUrVEagCFmpm81KUpvl0AR5NSw9aXy+KRTtNUhSLij
ig1Gr0u6nqQFLmm5pKBMfmlBqPNKDTES5pRUYp3NC3LR2WmaDCuhy6rcrv3/ALqAejepqxoOlWWt
QGyRdmpk/K38Lr6e1VNL8TRf2FJo10GVd3mxyKM/N/cNS6HrdnosMlxErf2kT8kp+ZQP6V1vlU1/
LyrTzHY6bT9A0GLWLDS5LYS3GNt0zAhC1O1ex02zvobI2EETSXKhGTJ/dbu/NZ1t4v0lr611S5hl
+1IcTmNNu/Ppn3puoeI9Fnne7jju2n+1K6GVshADk8e4o5ldev4FKx2kvgPRPNnmg8okQfNa7snd
t6gV514fsrafWTYyRKVuGcKT/Bj0rWHjiCPXJL1YmEc1uYtmeh29TXP6frlrY6jLfPGzPlvJwfuk
nOTUcy57pf8ALuY9Cn4jsF03UJrZTkIxArG3Yq9qd++pXUlw/V2Jqgy5rFPUGKrYNer+EdbXUbDU
1+yQR/ZLKMrJtByR615OOCPaul8PeJJtEguYY7ZZBeKQc+npWsdESzube/F9oGo6p9nhS5W4iQkK
MDnrUfiW9/sr+zLqCKMvLZLvIAOWPeuO03xPcWcMtsER7aZ9zI3TNN1PxBdaoYd6RqkACoq9MDpW
ntXZadfwA9B8RalcrBo8YVNt5CqT/IOQ1Wm0u18/+yP3X2f7GZDFj5gSM5zXnV74qvr9LVJI4l+z
EFCvX5aD4q1b7cb7f++KbN3tT9r/AHQOpS3MPhHUYY8nF8VXuSM9K8+EE0F5EDDvcvkRMPvfXPat
WDxbqltE8YYBGYt/q/4jWTqOpXmoSrcS7g4GAyjbx7Gsasm3sPQm13zTdHzbZLR9q/uo/ugevHrW
KankuJrhsyuztjGWOTj0pvlOcDaefUYqBEFFXTpl3t3+RJtxndsbGPXOKlttGvrtS0MLSKOpXnH1
p2fYDOoIJrTt9FvbmYwRws0o6p0b8jUsvh/UYWVHtnUs20ZxjPpnpRyt9GNGP2pwIwc9e31rop/B
2rW8TySQqFjG5vm5A+lRR+E9SmVWEYG5dygnBI9QKXsblGLGV/i/SkJratvC+oTDftWFd23dOQqk
9O9VNT0a60mUQTgbzyMc5+lHsZR2CxmmkqSW3lhP7xWQkZwylTj15xUY6j60l8S9RHoHi/WLO70P
RLaK4WWW3hAnUHocUWGuWVv4PurH7Sq3JnyI884/KsxfBlzBpS380qL58fmQwMcfL65puj+GJtRs
5rtpkgtwxh3MCcn0rZc3719JL3x3LngfW7XRzfyXE20zW7Iq+p7A1R0DVbaw1yG6m4jibJb1560u
geFzq95d26yBEtYyZJv7yr6UJ4eiudZtdNtbgSrOR+8/u5OOamNJ+1ptfGoPl/w21BjPEOrQajrU
13FvMUkwfftOQAe1XPGHiK0117doBMAiKjeYOflHuOlV9f0O00meG3gneWZpNjRtwc/TqPxrQ8Re
FtM0KDa9zL9p2hgGBCt/u56/hRtQ0vb23/k3UOpBfeJrW48NWemBXMsAwT0Bx0zTNC8RWthoV7YS
RMZbk546KKsxeD9Og0OHU7yeZftf+rP8KD1x3pnhXw1b32nahqV0W8q1OwDtVL/mIt9le95lLYz/
AAx4gXQbuacRiTzI3j5I44wKh0/Xn07Vo9Qjj/1TlwCe7Vq+F/D1lrOt3kQBNtFDJMFHc+lJbaVp
eoeJrSxiUrbSs4cM3AeMdB/hTfM3h+T4tbenUGR3niwTWE1nawmDz5/tDMDk7/wqVPGsq4uXtke+
SLyxeHAwfetPWtEs7bRLm6a0EE0N55Me07maLt+FU7zS9KfwXZXcMTtM11tle4wjbv8AY24zH6Yp
8jfPffTmEVLXxjcxRwpPDHcNbEmGRuoFRDxpqEhnWcJOk77/AC36A9setGjeDbrVbN7qPcPL+7kc
Pg/w+v41LovgmTVrFrxjsi3GJScjn8alqa2kGxXPivUllMocYKbPI2/udvpiom8Tag/l7GEIjOVS
L5Rk+1dR4X0C0h1a/sLsxzolmSsi849xWVfaDNoeo2zwxpdpcE/ZQwyOT95h7Ucs+sguZ8/iLUp1
2s3l5OflGwk+pPekk8Rav5WzexXGC4U7se7V07RWNzNY6PPHHJdG4U3EiADap52bq34tMsri7utP
eS0aBLaXbaouHh8odS1P2afULnmkXiHWUh2o7Mig4OzO3PXDdqxZ7qaWQvITuPU969imsLS3vtO0
+KSGOKRYl+zbMtc7hySfavL/ABPbxW2qXkcYAVZnAA6de1KdJLW5JStdRnsyzQvsLLtJHoada6pc
2UpmhkKSHqw6ms6lrLYC8uq3Md2btJMTk534HX1A6Ul3qlzeSedM5kkznceuaziaXd2o5n3Yi/ca
tdXgQTyNJsGF3EnA9KY2o3bxrG0zlF4VSSQPoDVI0uannk9G2BP9tuAuzedn93t+VILuYcB2A9Ac
VAaM0ru4FqO8mRg3mPn61O12JF5Y7qzaUGqEWgZmzhuKY7zDgmpLZuQMA/Wr9zahxndk7e1FhmT5
hpDIaWWF4zzUVIQ7e3qaaXPrS7uMYpjClqIUHPelJxUa5FKcmm2wsG6lLGmYpTSYCE0ylpKQCU2n
U00ITEopKKYhTSZpKKLCuxc0lFJRYOZ9xabRRRypDCiikoEOBpaZSg0C6mtimMaeTUbVFzcjNMIp
7cVCZRSAfikxURmFMaekBO3Sq+eaY0+aEbJq4iLC0+kjxTzVWJY2ilooRIlPApBTxxVCFAqRRUe6
nB6qG4anRaP4ce8s5b2RvLtIwfm9ZOwqzp3h9dUs5Hhn3XCsdtr3YeorS8O6vbTeG7vSHkWOQkyq
T3x2qPwpNa6c0uqyTjzLXIjtc48z1OO9arlv8iki5b+D7JX0+3urpkurhsSQL1h9Kfq3hjStOdoP
OnWbzFRN/wDFlgN4+tXYta0u91Sz1iS7WCUTjzrYjIRf7wp3iPUNP1G5luzqKyiKeN4I1XG4K68H
8Ku8br119C0i/wD8KsRJo2M26Ew7y3cPjOK4uy0e2n1eWwk6szLH/vD1rtE8aWsWupL9ozatZFWB
OQH2+lcVY6paxeI3vp5QIopGePH8RNKUo/i/+AFkZes6Z/Zd3JbsRuQkVlNWn4k1ZdVv5rlBgO5P
1FYwc1zt3YDzXqGieH9N/wCEXs799OhlfeftBLYwI+4zXlp5z/k13uleK9Kj0GHSbn7YQj7m2nGf
YmtYNKMronqdB4f0Xw7qttq0sieQv2jZGzHiAGk8QaXpXhc6c/kR3KvD97s5PRveucbxdY29rqlp
bWpC3ZBjJ/hx61n6z4oXVrSwgdGBtYthz3+lXOpFbd6X/pBR2fiK+sLHT7GVNOs915a9fKGQTW7H
p9i9jaSm3t/LewLPGEHmE47d68x1vxUmqWVnbCAp9mAG7PXHatAfEORHtCtugFtb+SBu+9x3o9q3
zf4hmnp9pp/iSGTSI0WzmtpGfcRyyhs4P4VzvjK7gaSO0tkRPssflsyjG8jgk1BpfieTTdRuL1YF
cz7srxgbqxdRvHvbmWcqF8wk4HvWU5t2/ENDQ8J6fHq+sWtpL9xz89el3+j2N5ZaxGfsgOmL+6MY
w2B/fNeS6Rqk2jXiXkA/eJ03DitL/hL9RI1FQyAagf3/AB1Gc4FUpqMdVf8AzBHq2jhXsfC8T4MU
kU6yZHYeprL0JFh03xEsAwou41TA5+929q4UeNdU+yR2isixxqVG0YPP8qgsvE+p6dHJHbTbBK25
88kn6mj2rf3f+3lXR6rFHbR+NoSmMnT8ygDHO3+dZ+v4e10hrcMIDqHVupO7p9K8yGvamtw9ys7C
Zl27uvyntz0obxBqjqqNcPtQ705+6570e1aHc9J8brcyzullBMpEa+fJn5PLwKp6fDezrZW96PLP
ln7PfRtzDx3I6VwcniLV5UIe/mYMMEbuvtRb3WryxMY5rlo14JGdq/4UvbSfQR2dlFqMAlRil/Zt
d7CCwLICfv8AqKx/F8H2bVoVS63khCJGORH+PtXNx3d4m8xzSjJ+bDkZ+vNQzG4kOZCze5OaPa3V
uV/cHMX/ABEZvtQ868jvm2L+8jxjGPunHpWMv3h9RUmxvQ/lR5bDtmo1TvZknpHjS/xoWgJE0RP2
RQ21hkPj0FM0/UI4/Ak8AkQTG85TcAxT27152xdh825tvQEn9M9K2tM8PXeqQqUmiQO2FQtyW+me
tbe1coVE1rLX7h3Oj+HeoR2M2qPNcx25e0ZB5xGM49azfC98LHxLDPNOixCZhuJGOTwc1h6lptxp
V29rK8YcD5tzdqm0Dw/da/eG3XCDy8q6ng7KUKvvQlb7Dj+A07mj4g1G3uPEL3KSh0e4DiXOQAGr
Q8c+ILHWZLY204nxGiMcdCByDWbpPhS51S3vZRIubR9u1By351avPB8WnxypLer9qQA+VnGM1H/L
iST0bf39RdS5q+tWNx4V06yS53XMHDIRwMDtTdD1+xtfDOpWEs8yTXDkoqjirFj4Dt7vT7Gdrl1k
u+VVvu/Wqc3g+OGyhuftBxJdfZ1xyDWrXO6z6Tt+aKK/gvXbPQ7m8munkjV7ZokMfU9fWqmga8mk
a7HqEgM0UcjkqevzjmrfiHwXNBqU1jYq1ysMPmP/ALVYGp6Vdabs+0J5bSrv2DtkDr+dSm/dlbWC
t/4FFf5Eu50eq+KLKTTZrKBJyZ7v7U8j/wDoIpsnifS20BdFEFzuVvOWUtwDXFFsetG6sZTk23ca
Z31v8QvIgtkW0wUgNocHhlxjOKpReL/L00WE1oHhW4MsZWbB5PQ1x2T60n1qfaMR1+l+Mhpl9e3E
NnH5d1CY3jLH5f8AcOOOfSrMvj66N3a3EUMSpbReWsbHI8vuOe/b3rh8+9BNP2j8wOqvfFLzxjyr
eGCTzfP+0KSZt2fX0p1x401CWFkX7PFJIm15k4dh71yINOGCaXMxnSL4y1IIinyneNdqysMyD6Gs
Ge5kndnkYu7sWJPqajNNNEp3EPWn7ajV6mU00SRMlJtqZhTcUrDG7aYVqximsKYEBBpMVKRTMUrC
EpmakPSojQA9ZCtaFrefwtWXShitVF2EzoJokmTI61mSWxU0lvdleCeKveYkorSykiTM2Ypu2rks
PcVWK4rOSsMZtpuKkppqShtNbpTzUbNSEyM0lBNFSSxtJS0hqhBRSUUAFJSUtMkKKKSkAUlFFMoS
lpDQKBBSiiikxGmDlaTFJGflpScVBtchnOBWc7HNXLhqz2PNAxS1MLUhptAh26pYjUFTRU4gXVNP
DVCtSCrM2PzRmm0UJi1HA0uaZS0DHU4UylXqKFvsCNnTNJutQV3hHyxjLN2H41cs9Cu7y3uJkKny
OqA5Y/St7wbPDJoWsWQZUuJOUyeSAOgqDwpBPbXslxJKI7azOZ4yeXAP+r2muhKOmvQZWsfC13cQ
20ryLB9pk8tFkPzZ9cVoah4KnsUmMl5GWtwG2f3gfTNbuoT2+rajYanYSotvHcojQlgPLI6tt/Cr
Hi9JNUuZSjQRW0WyQyKwy4Ucrx+f4VVorsOyOfk+G+oCS0wdwuE37h24zisIaCG1GSwZ9rrkKfVs
9K9UXxdFb6vpcP2iNraW3AJ3DCNt7+lefOYZvFZuBKixR3bT7iflIjPTPTmk3DyGcvqWmyabcNDL
wwqtbIsk0aMcB3VSfqcVv+M7+DUtVmmgIKdARXO265mj5x868/8AAhWatzrtcGej3/w5hhiK29wX
mFoLwhxx5RHtXJweHL+5RWWLAYkAk4DEf3fX8K9Iv/EumWSPex3kM7PpItBGDk79uDmsdNe029tN
DIuFgbT33Sr75z+NaSceby/4IHJ2vhLVbuSZIoWZofvjnitGy8Cakbq1S6i+zpM33ic4FdhZeO9J
hutXk80oJZrfaygfNt60an8RtLKnyG8wi6DgEYby8fzpv2dtLDsjMPg6xnW6gW3ktZIFysjHKyY6
mvOZ4vLndP7hI/EV38vjWwtUupIppZnuEwsbj93BkdAa89lnDu8h53lj+dYVJPoitLHeeGdBttT8
OXlw0cZmWcKJmxkZrDl8KXSakLFgeV3BhkjB9T2/GrGheLbfSNCmsGid5JZQ3HTANaEnj2I3ck7Q
fJNB5RC/eU465rSDp2ippP8A/dgZWreEptIuLWKV1C3JAV2PAz60/U/CkNhCzfacuO23huM/KelS
a14wi1b7GTCSLTGA5+8B+uabeeL4ZrJrRLX7xzukbdt4/h9Kiap3fKI5LJDEeleg+FvA1rr2lfbJ
Z2jdp/KQD1rz1jkk+tdXofjW80WyS0hjU7ZvtGTUwstwudHqHw+S1mt/KcyoVMjHPl4EfU1leIvD
NrokumurmS3ugCQoyfpUEvj7UpSpYJjaU/4Cazr/AMV3d79mEiRkWrbo+M1fNT7D0OjuvCWn2dm+
qlneN0zBbjrnHVhSeFbRZdC1x03hkJ2g9DXMv4s1Fy0jSfIwxsIyvpwKhtvFGoWUM1tbsojm/wBa
MevpxRzLcaPR/CPhbSb7Rlluo90lw7AkH/nl2PpWpeeEtDhgneK3Ct9gDxbj3zXktv4m1Kzj8qC4
eNM52j1psviXVZSC13KcDHWmq9ug7I9IbQNOj1nw9H9nVoni3yIcbS2OhroL3RtES1utlpDEz2tw
27jKmGT+teJPreoSFXNzJuXoc8j6VFJreoyAq13OwIIILk5B7U51nJWCyI52CynYCeSBweRmu58P
6M2n6XFq0ax3l5dHFqrOP9G/2iM8GvPRK/ynd93p7ZqcahdBdgmkC9doYgZ+lZLQTNDxALlNRlNy
4eUnJIOR+Bq/4N1uPR9TMsnAlQozDjHGMmuaeVpDlmLH1JyaZmmpLsFz1m31rTPCSS7bpbo308ch
2YOyInODWV4hTT9Uu7jU/tqKJEDKgI3E/wB0+leeBqCxp+0sFz1HV9eii8LadDa3qrLGuxogQW2/
h0qCw8Q6Zc6DZWc9z5U1veGWTf3G7PWvNg59aaT71HtpXC56XeeKtPn1q5mW5KRGJY8kfLNjrmud
8V6hp13LG1nK8uB8+77qn/plXKZozT55S6jvoK/3qTNNoqSGP3UZpuaKVkAZpc0ylzTEOozSUlAx
+6mlqTNJSsK45TU6PVenqapAW+tJTEepOtUAtIaSlpMBpFN2VJRSArvxUJNWJKrmkIBzQRSpUpXI
pCZDUsMxQ1Gy4ptNOwjWjmWQc0yWPPSs5JCpq5HcAjmtLpgRsMVHViTDciqz8VLVhoaxqEmh2pua
kTFopuaM1NgFptJmihhzWFNNzSmkpoHqFLSUZpiA02nGm0iWLSUUGkISiiikMWiiiqsXoXlODTmN
RCns2BWNykU7hqqYzViQ5NCJmmMrEUmKveQDSeQKd0Mo7TUsYOateUKQKAaaJY9F4qQJT41GKk21
pYzkQ7KUJU2KMUAR7KQR1NS4osIj8ulEeKkFOpjHQyywOGjcoR3BxU/2uc7j5r5f73P3vr61AoFB
qhkgmlHHmNj0yR/Knea56u3/AH0f8ahoqSiXd7n86QyE1HRQAHmkxilpDTJI2NNzQxpmaY7km4+t
NLZ5PJppNNzSaBMkDUbqipc1JZJuoLVHmkzRcLkmaTdTM0ZpiH7qfuqHNFAXJdxo3VHmlFLUB+6k
3U2kpAO3Uoao6M07jJd1NNNzSUAPzS1HS5oAdmkptLmgeoucUm6mk0UgHbqCabRRYQtOptLQAtFJ
RmmAtFJSUAONNpc0tIBKKKSgAop1NoELSim0UxkgNTxvVWpEaqTAtUUxWzT6AELYppemvURzSBjn
bNQMaeTURpCJI6sCqyGrCmgVhGXNQuuKs01lzSEVOlG4inOuKjpoCxHN605iGqoDinh6bYIGWozx
VgEEVG61I2RUUEGkpiEpaSipYrhmkpaShCbEpaKKoaCjFJRmgQtGM03NOVqBoXbSFadupC1IGMpR
RSUhXLo6fiajkbippOP1qnI1SzQhY81NFUNTR1DKJhS0lFBIVC33qmqNutXAGWoelS4qGE8VLmtu
hAuKSlpKQBThSCloELS0UUALS5ptGaBjs0U2lzTAWjNFJQA6mOeKdTJOlAiAmm5pDTadxjs0UlGa
hspBRRTaQDs0maKKYXA0CiigBaKTNLTELRSUZoAdmmk0ZozSaHcKSiloKQUUUUCDNFFFCGFFFJTb
C4tBopKkLi0tJRTGFLSUtBIUUlFIYtFJRTAWikopALRRRSAM0UlLTEFFJS0wCnCmiloESo+DU+7I
qpT1bFNMZY61G605TTjTaAqNUZqeUVXqRD0qwtQRipwKQxScUwyUP0quxpkkjNmoGoJpKACjNJSU
hD1fFShgar0oOKdwJnWoDUofNNbFFxsjzSUNSZoELSUbhRuFAxaSgMKCwpCCko3Cm7hTGhaUU3eK
TzBQIkNJUfmijzRQBJSGozLSiQUhWNCQ8mqkhqzN1NVGqDVDV5NTKMVGnWpe9ICQGlpBTqACoX61
LmopOoqooTLEPSpjVeHpVitDNiiikpaBDs0U2lzQMWlFIKKAHUlApaBhRSUtMQuaWkxSigApj9Kc
ajc0hkDUw0802gYlFLSVIwzSUUmaQC0UUVWggpM0ZpKkY6loFJTGOpDRmkJp3CwUUUmaGxWFoooq
Ri5pKKXFAISjNFFO6EOpM0lLQULSUmaKBDqKTIphmUUAmSUuKj84UecKdxj6TNRG4Wk+0JQK5MKW
ofOX3pDcL71NwJ6KrfaaPtHtQK5apM1TN17UfavamMu0lUxdH0o+0Ggot5p2apecaPOamQy5mjIq
p5ho3mgC5uFODCqOXo3tQmBorKBUnnLWWC1Oy3rTuNFuSUVB5gqA5PelC571Ay1HKoqcSrWeQQac
DjqaolluSQVAzikDxnq9MeSEfxfpRoIDIKTzfamedD6n8qY08QpFIkMvtTTLULXEY6A1EbgelK4y
15ppvnGqpuPam/aM9qVyS55xpDK1UzOfSkMxppjLXmNSF2qp5xpDMxpuQKxa3n1pN59arbzRvNTc
C0HPrQZPeqhY0m407iZb8z3pDIKqbzQSaOYRa8wUbxVUGn5ouImLik8yoaKTZSJvMpfMqGlpXKP/
2VBLAwQUAAAACAB4f1FARlMDoQVoAAB3aQAADAAcAGFzZGYwNTk0LmpwZ1VUCQADxL8+T6/APk91
eAsAAQToAwAABOgDAACd/XdcUv8bP4zjrCwzFSu13AvcijtFM/cWV44sN5iaOcqJNqzQNLdiigsU
Fcs9ymy5xYnmtpy5cw8Eb96f3+/+/nP/cz/u83iAcDiHc71e13U9B+eAZ2NnVMBl0weh7koKMqoq
MvKAs0mALuA8M/M55nPn/7dcuHCBhYXlwv/vD225dOkSy/95dIn1MisrK+3+MhsbGwcHOzsXFxc3
N//ZT7pCAICOie5/C+D/v9DRMzAy0d72AstFOgAD3f+9/D9evAKgp2NgoGdkYGJiZKS9EkV7DcDI
zsQhKK/DzGn14JxQIFAhNrngvPDtqm9c1oP/RBTdHj+7wHL12nVuHlExcQkQGKKkrKKqpq57R0/f
wNDIGGZja2fvcNfR3cPTy9sHjggKDgl98jQs/PmLl3GvXr9BpaSmpWdkZmWjC4uKsbiSUnxZdU1t
XX1DY1Pz9x8/29o7Oru6h4ZJI6O/xsYn/szNLywuLf9dWd3e2d3bPzg8Oj5hp4VMz8jIwHjuv5Dp
6J/8Nx52RiZBeWYOHatzDwI5hRRizwNvJxdUfbsgrGj9j8vt8SDLVRHIH9Ht/6L+X9D/72J+9v8p
6P8T8/8J+ewrgP083W8GAQY6IQA9O4CBHXA2AbjEQEd7QnsMBfz2KYHBgUArPYAMmFi2WNZYnmGw
TAC967lnpqprF2hcWKsocGVwYYTEAHRfKrkPino/ePBY0oQ+fYC9jTE7z6p0QghXlwIIRz2bk7vu
lqwfsYdrVytXkV9vu/0K2A7tIYqnzMRVOJ32SerGzd+UYM+QfuMcZGiZKOfrEn1PdSktlo95cBdj
HNrYixRIzoN/uqBh4DhxxbPZG7LtuUt/Da2Z3rUs9zlO7dx2id8ttu91LsryMLMreLUOY81kr7v1
4gk8MN7LHTsEn7kOcW4xbEcpUF07gfOKpgFkkJ+YiKB0Muui7n/l4hiofoeFPM/HKuXQ1VrpGTLJ
IhzhxXRGetJyLBKFz16x+HHjlp69gr2V44kS4EhJG4IBiiG1PAA/oJX25WJI4TMJevUQpZfgAYa3
+ojboKx85gGQ8YAEHVivuE3Vkn7ABwsBSLMaoR0BOhY4VAgAuOoH5FB/D6r9Y0M/vJJ2YngONppt
4XjfuK4IIbQ6bWBB8Cb4TGrzsyZ3aPrQT/kTTwWssxLeewO5bfWB0bYXDfu/Mr/jeOjARowr9P3p
L2xWq+crvIN0TO15Jvt5FR6LETacqa26EYLHNr5ttG3TbhJPGL7tSfbcFX8T7n9fcb8y1a6OFPyJ
6SlOjBsZqr0uial/XZGskGjzzLf6y6iU6GCv4nIvf7B7i9NYaozcrRIR0rMuA8cIF2F6rkeIT0ag
eSUGMdAll0DLrifXr+sQ5fSE94nQ9bxaAXD2dJlCxXTZiuHcqp7+L/aDNjlwFkIoxqaamJfuXKUk
IHwF9GJIDjIF01a1if92bqbgJuKne5DEvtKjqTfroXw3mtqnp17Ncw0r5Bb/ki10NLrMwiZ3iTNx
5Jc8n/0fl0dw4Rx8x9p3qyS5X6DSx0wh0QKPpi/7prX8ZQqynZoR8wPy+Pty6oqhJEqlQLWrfgJA
208WrTarG5mzBHyy8F01YC1+KCHI8UqXEFEzDmx49U2jUGny57k8MOzqFZ7HBksg4fxysXUrickE
W1BYoF2yWumyqQKpNhb44RdvdLqRHhyh+3pNTR8s4xMfOldZtFGWsWD3wljitntQHiJwV8HGYYlw
OzSUuVakxr+sJrcjBtwb3/gua6mUuWepIk7AeolBeY757vn90o82Ub56s3mPEIT28zfVhzwLr/c5
VvhNgS9GEzD3wMs6FvnXM9nXES+e6Tl9Zm1VXbP9FM2VNmhYbiaWgQ4fvZTfJlGMzWcqTBiSz3ez
MtKTfykNnAA4Oho7AuT14UGmEKAMHA7yARSidLQvGpkYaV80hMNZAWIS2HzrZjo4Lg+ejaPnSXpP
qs3KZ3R8WowFVtIPDeqDpgBz73hAj0DOTFjcEMrNbWjIei72ojkwCwvcpBVq7SoHnZ4mPB9Ggn3k
JNxreKa/8t5WtPxj16OenWVPSbrid+3lu9VUt6xf7CXspSdooSq0edgJ+v3kpAG12lOcksK2A+kG
b2XcU+HHguGb+ksra7CoAhjFkV4TARLPs3r7k834giB6RjX2+KVZyfUnbIo3ETU6oDV0pNX9XTMO
30k5p8EG3qATu4MWN5ngRs9EuUtmux9vvn2w8ij+zTPO52MYx+ltOhJkWu3KLTPgPCa15Axwr+y7
mmx14eMO4K5oIRvMVifDHxd7f+ldW8T+PS5wcU2P+G3EGWDM5lID316cxtPm5qH7nmEyp3nw6N4o
VseMVSVVHVuP5seq2Pvs+V+J2t/0hE0EVxGKqdp0QoVieTYkD9vzYBuRKwhBWFtXG/uU9dh6pNpj
41jK6orj9L+wuUaKKLW/oWdBOCkHGzy8duX1P4fokMGoyxEa79trc0S+VnodnZ4BXgasNrwJErNr
mhzetbNW0lM0xRJFPayy4LXzZhVv7xBF1VH5HJV3o05K7NYnH8aMph0K5sjvlUgzL2tEm4/wLCtV
ZWMvK7M5Jj5IaXU0DEIld5iDCq7KPH0RBeYNbWeOdjW++ySd+4a1lDdcqPTOacAZwCtbawprd1Em
Ytj1MdrC7R3Rgnp3NMSxWWReqGzUxVjqthoRPvF2soFz426g7VH85fRAQXRo6Jzbzz3ugsJJqx/B
2wYf2drfD2+ussIHEovOXWZ1CGMG5xizx2iewLxCzxVUjBeKeJc6L5XXdmj+3Q0yvMgeUq5Z9t4c
gVS5iYj58EiXpUCgPKi7wvxr4Ka8rUj0WMWCIxjtKSPR5tHNgZIotrTSA8ZIFKIAxsYhwK8gRUPE
rV3DC3BQdhEEaGhYpMQO8cri8McSdZsxzTE3TQx5EgboTFBWxj50tWm1/xV5bW0tYAIEB40xFWag
lBlpHCaZIFHComuYTFsZPiImr1MyDCiB0Y1jmdEgPYA6xhR4wi788haMybD2a3WBvlxQh9o+wdep
ABhhDbA4fOsh+nBCs8JHxTMJCzDLyQ5PGadu8ccx8Y+nQmcutW7RQ3NNKMUdr4suJr7iJ+hINTRA
o7JbpzspTADHxPOCZ4C7It6Udtjpm2K/2xOXXs8pRHzEOcKHjA6rW12pLcYnkfL0nmiljvJSap22
19RsD+gYqA9KhjJnwDfe/Xk8wpZHONQHSXd59aUm33JOjrtxYg+v6CnpKj6P/cz0ztNmX6yRSO95
Dcx77pa9+5yfygaPqbUBz/PzvB/V2uADqa9TNifkX/8SK9MqAF0HsFRLdWxfioI7zszcuhrSMYpN
8+L2d92Sx4VZNxDgSn2YK/NLWiO2+w4OkcnJ+1wC9leXGwvyLdWEsqUXKlW/lsUZsTFum97ZYbz3
gqdyE/MdhMtBAbjLFM0hP7QB+GvPrVB5ojNfYa+zsZ7CG2sw416E00Xm9vCRnPhHZdHpfgoyDzqj
H+xXkH/s2q70E+9mmmWUenKt1FpZMgfihngcn1sWomjcGeG6/6x8pFw+264WZ6JcdgcY9hR41PbQ
o6sQb3J5710COrJqDyf0s5+KYlKe8hI0S836WnL7UYwtnRC+37hcfdeR/R2TPVqIlIVwv1e/kW7o
nUTwuScmv1/GPTF2WJG3KDTll/v5MtSVAP8wwxZ7HHg3OfC5Y6lC/ujrDOO4kuk27Suxw8BPid+1
CQKDV4WyLx/1u0WBgwF82TiO64J7eCbl8w8/6skvL0KxdhFiCVGL0Nvgn+l0iN7BCyxzxcLMr5tK
jCXuW3/+Ft2kBPPpUNL8KrIwLORcGYiOc1Ts/r1rqGckPqPErpQQb+gHhAVZ275bVbTKwPkXCz0c
RL8KUdVk4NcDwq4U23jYpP2A4e24zfDypjg6I/NJ/QlGhVyT+re13bdRj4qBhdhYgcJYPQCtwulp
aiX2LbYNaDt2e1CPHpvgaByi/I4JaKUjqF2I8nHHk76ZmJ4bblPcxtKXXgBg8620s7Yt7tV+s5am
Fzcf+QR352m/OX17vz2sggufYU/dB/grbTyDsqecQzq6+66qxjEmUdZ5OrPT5s8pOd0ipfmaIINU
xXuFk/7M1TjqB3zunYXp76JeL6E5RZgxlh8cs2yFuPE4jfbtzudSGLl54SRXxGrl6d1yUXRt8uR6
k7X8x0StLa6+v/evPdxO79DaH1jLqMdjnUqbXn9mf/6Ra/o5tS/IfiA1Gb0ZVv0kz+h3cJm/qHsf
4kdv/DD6TaUKklVX4lXPfvFOm2prnUHjQEw0MASnNaGLfsA4fOUF6gEi+jv8UjAdO470MtAMAui1
2Y7EFTDjkpYEYIkLioXD/uZgkyYj5rK7d27v4ytVYXuEZu59OX+2Xl/lIKLr+10b0QoPxGufQtSz
hM/WwyvpTC9peo+13O4VB8HuJqKt9WSEALrSl6319BteOOm5bb6IqEOipSqh9yT1ttyI8AFOkBe/
o7D9nChwjlz7sw/ukFuIudTFTT0czf1p0ShrLSEDWMpvarykNber11PW3gj9YZSWsKETu0L0Ssra
tdvM4ku3q161eiybRbcpeQ8y/6/CgR/O7ziB0qkL37UHdnl0LanM3HvPhpV8WyW3X668U9hRuw+p
0f9iR7dUV5WbcCe5JtFX7/wDW08WZfdtLFvivqhQb9FimRRPRVRB4OirbO7ANiaHZ+JCJdPoGKZ1
hOftabDDutUnvjSK5pPcF954bLMpC8FPPHBnCMQVELj8Rd2rwIY1LzAWQzAKHk//Unee6CnUXne7
vSQ6/W65jNUuK1EUCKte13iDtoSnFb7VYOoikero0e8tr11NBdZayisPK5PS0m/z6oP2rD+2zyXA
aozQMpJvC1GgS4+wxcBaQL7XM3lt1WJxSMd92srzxiCfkkdXYCu1tV+NQYFGxr9pJS50GwUiDXyD
jxUDV92BLI+KiRJlV7bNcc/NgTGPuIRYdKylAdA6Fcg/UGQ1PEUhlUsVldmjlRbzgsXUhmpVPG56
PmapRGfonQTeHjgoNfDRr1xhmTERPFq/tKlhYJUiOHa0z3WbYabCpfcf+Mc7m9PTiNEX2dFm4mlg
L7dpJsXlvdLrs9J6guzSt4RV3HUatOKyrnB8SedVqXMka4TzwOshHDazprJ2xIYW/QG6KWseMCf6
AdH8K8vbKm0FcB7fZQS46vL1uTKNd8RPIIVa8ucNqLFnggM30SzsbcmKY8trp/ekkdvmdQUCPTy9
absOnSMX9BRQMSBrtwzU88A02GvcgGG6iFkdiUyylRJediXYPAHWqxShb8eb97bA78M+htuOkRrb
/N1J2GWTv3Cmn+W/lEresHWzPz0oFUW5bqK0dZaNSVPE0eIJarqbwB6dYY9KC6eFVD49G1fhg3eJ
I8D63QePVTfM3nI/NFqzOixXYQculbP043VJPPWZ1gIMN8ESL30NWLhusAxyoGYD0n6fAYx5bZoY
8PM08/XbJgDwDWeV55/dJEwQbAzQtVY4Jf0DcZLKl6At0H5EGkGxp2vF8H7NR3xRS7LzI+39trsf
a2QFOq8r1VEwPP8sg/8yARIfL5GJLsXRqmVvZKZ+252ePNSm/nu5V8bhpHtdOCHW2IlHLyslah2t
/bSkVwuRVOdm2975tKwdF2QVgufgtmiTmXB8ws3uaOpWLJQKjPEKK5fPA7PWKTySoDvG0lTzE160
op6oxmuaCiA5F9RaD1k9cKDpDF0a2lrS0W4CNPK5nmY9aP4bmI1D+8NjJSAwusIYfrSVKfCP9rM0
HmdrdyBg9RGOhr0N1wvfg+TNudz4mFStWR4B32VtW2P1wTY4IVsu9blCeow2hz892isAkYiSYkDb
KfHB23N0BIlqcIBW2j9NfLGYc8NfxF8USJhVqkhy8gtYkpdbRijVR9PAmDQCuVBB/BL0KoEzCes7
kJO9KJWKkePPx3ETruWL/ytBehkalSA9TP4iwRmM/H4vgp/vlk6cHqCg3R8q40HrcCc9sII5iC7x
8HHeWNkGpKTF98v78pFfu2UERuGj0dgi+d5XR2VXWdccOYq1adT11j5AJFitWCHHq2iJoOb4Itkw
RT3v8nUbNfzvxZfORl77eRu1mS9eKvn3iVpev/IYjMt/ihhZN576Gr2fLe44nLqlMlQjsuageFtd
orCYxcbKDK9y07QQlXIb+2rrw2gh3o28tl9e0oitImm3fnKsuyJUUOs6Le2iN9ec0S4k64jx8Vwq
zxi3A246D9HXTAYZvLv9DzGcvIjW06DnRwAe3zYNwy/GROWoLgMXAhdJ32LiNUtTBth7V5P94oRn
qvUQqzVhuep2hhXhGY7x6LGGP0C7W2L1+Qw+BBkjtVs21lHDe3gRZxuxt9qF3TpY+uJMgpSPw7Yp
8/npMQCbUsnVrMh62Z3fIbj414LcDMlWZtFe17s6Rkv11tSYylkbAzJbd/GiLcmvWQzEqt38+o9g
j1fE78XFFrYt9F5WXp4a9XgrErOjugabMezLy6rY2Eise09kZ3yFTngH8lizMhr66C4U2lUMnNn7
Y5SmnjBoVioRAoSZAWTgujCJspvxLHCE6Ip5foYWypPrNj+t3Vn4jcwKi3VoxSi/Z/UfsWvjXnmI
SgNr16/SpDH+ykt4VslSjg1AAgtszKexuwkKEOqDGy7TtjIvBp7UAkB7g+ZAeTb69xIwY/VhwwsA
vBU8HtahI/KGt5UFm5TPXR64wvM8uC6Vehzwr3DUVfB5YmHdsEvTgwR0MXNwNB9pUfVqL3RGELkn
ZZcWfZHU2aXcs5/+lIIAKeVUUHagPLF1oP7trjNAFI+bV8pT5UjqzkHbNfJkF57/O9r5vOnJz4df
+TOu1/TjHvtemnFW2TY6GVaU5Es6A0Ri/pWJZkxaDD94l1RrAmb4xsCIquGAXxzlXjjYlUfnv+4N
fH5se1R77Mkv9Zi/sOHIVliNpz7889V5Cr+FLcMz3F2RJdxIXflWshhqysMT+WQwCnyQ/OfgSmme
skuHuFDFEaqv2yaB+50Ca6N4MkrmJSP5RtDqk7eHVgZD8rYY688B88IrbX51LSngJZ/Vmo6S5Ww9
Iy+NezOYY/95KpOVkWgvJtyId1upWj+txZP/sA9xwXPo12anxSkDkO7Fimx5tFi5AjTIyXpqhdLA
U3aoHPMIV3wJd26o6Bvhggyh/07ZkHFJ4QDE9j5CgdXc2cYTf8kL7KMaaLlZrtwoo2jL2rsQ7Iic
UnIkx4yEdtn7G2BhJI3RD+6iTS/Ft/kR3akEX2MtgwOulKlRDhVdGiz1stikTTjqz9HcEMALG59p
QdCBfX2kUx63YLjuB9jJICQwVeRc2JELt/0BqkyMu6mX+1Jo2i/hA8E24/YIm5JojgLbNBv2Hmqy
tyFhO8GOxxkj6411rBv5Cbbvcd/QjoedNlpNkTLfVvdeXrAVLvVXI6udIuqmp2oSHn7N94oa7CoL
8QrHzxSV9liOTjeK2n0sJEiIT8g/t3vp7rioPxA0hJefyzCpFm6faX2r7SkSxF2md8mrC+8WaWt2
rATWYjXbF8hzrp4rF0puM/Xsv45bvomfupMcaCHypOy7sctStqHTuMqHlbu4Wo/XEIfl0RrnuZpk
n9jVC2xcGqTLklethUpQ/mAra4cJeYs2IKBbApKdX4BD6RqhAe/kSgK4XCFez0x4X8r8sfRKGDDS
0tMqZ4DJGrNcRYUol9LTWkXiPwfpPDTsQ7QSQjv6+xAB6ig/IGDdEq7L4mtJZ2IokX/uv6mlwXhh
MRDQWMLiBZ+LvQz8Ywj6HgOE/SIIcAklIt5lg0deZypxoGrOl7EX+EgPLD1oDLcrmVzXnhv3Fb2S
NyKevKF9ta+AnjLp8+o3iFCOHD6P3EqmcllO5nUjwfDYV5ZIsPZd9VaKgs4RDFkn4s88wFZnu6NZ
ZvjnW5kgesJDH27pXn4ZyrMvaRKcKPI9MS99uRnousJO5VphvyTAZR29wlDlDEXVDokrlKr6B7l0
rTjHNZUTb3yB6bJfHEiG0fcZrvRN0s2VG5WoV63q+ZoRjNlOss4A4MqQZf6d79Du0lTIWMOhxaJl
SzwymGpbFqkj7utg8AVc27zYg+yRMBiwPN+d0pv0B5puH+FFXSkfRgxj/sRTj8oCSnunM4oLy7UN
3C0VVArKzcIE18HnGoN+Ac/HFJR2o5MxkO/t7ypU/CweXt629C8PzZICdQQqFn78E7ZX1rBMcKlr
nzmH6COpEv0G+vGJywsp1ayIpuMbozpK/cI2kEG0Mfgc3phm+H1o4s7oNk8KdBWsnqyeVFoeN5fR
Ye/L89oee4tkyZ8c/QzHNVQvF/EuWf+PBeIFWlf0svztDaLdtP6qtstuWnDpdI8N5M9Q1mtxfhlE
ZniT2hw+ry7T+k2h0geA7vX5BqWkm3Anb65C9qdpPg6X28s524yvnUd8Yolsc/DSUZK4D67qhBSs
OIdK+18v8Td79YvLKUTBoPCPm04XPhBVzvmetIC2v8/ReXuuZsyrwvQnqnw33EpAMBqsoGiRSlCu
kRa6ZQkysbYBvmEStgRdH+LmxqXq4HgYpRUyEngAxhJt1/PfEYFuuShPAN5m2AaGB2pAVj25888N
0srvj6GeBMQrhtcUsmuaz7xrTttOR9BIT72U+bl5MX1GDNDKyLwNIAGk1efTNoB+YR4okIb58rTt
0lhCr9T+0Qauwz5mLeJhBP068IDQd1Td+bLtSyOdBkra8HHwGeCa8dBF+EzpeFsrAU5A88Vl0Xc8
SHRAoRykLKZTKnIVKfkI5eHW6dO/d9LMavl3f+2VfsaeQzUH72jAtPrrCRxE6YvxpWsDv/I/qA9R
TbKodX/LD+1XYFaaF2JOlkIa/fxz3rizTnkwuICEuX48TexKefw36NPQazGX7mq4nMppfdIul83f
qjNAOJT818590oQ6u4SoEcnfR/aOyCu61ErtyWOOrpSKDEwhg3a5MvQ6/+5EexUEqVLVzp2yYF/X
aGUnzpW2xLN4pPSdO2kvI0JmZxF6bCljqMqBeYJwj8ph2dUUXdIQnccr+gKhOK/90h40ILS7xud8
OO7GyJriLtt3tGJpcEZKUs3v+cWKabPYFftoYnr/fUmxLWHU4LqpaZe5ANSxmyD5Yd8jYtTvPtFy
giZjPMEShcmlVnpcAqKG70keNsl75W+kc0XfULpHasuuih+6fQARRtulPEYsU+150ZWwZeC3KzeG
f2HvNo8JO9sGFyvYcOMvAyACxZmxuvetcstaLJTs+pUyrVLwBF+r5LsXSXaE7DkCXeGbLNdRvDJ4
1bDgujfBa+vbUuVaY7vh9yI77lJspG1QICpu0A4SC5t5ZZVYlyXjiP5lGjEYfBVSOMFLuDuTV9h0
BlB7s2a+m4Q/XVETqCrXkFEVKr22lD+7ZdSM7QwV8cJtlnYVEyXT3j0pQfngAaUP6bPgS1k+pu6s
yu/htTTMY8LS50nQ5ejxIkytUIBXfjJgZ2u3GG4j88Jn7YPmhe8AJcNw0s//TgIJ5ttmPcRhNl+e
ri6gpUkXmkaQv2XYdgjuHxOanW1bq0wS1iPDN5TYExLl4JCrAm1Q4JZMTJ3QFVFhGbBlbUItHZMh
Ey9YOw0wADrKl4bC85lhL2UmHjmGXrEEfYXVj0js0TGpx5RANmpfqOkZFmY17eFtLK9K6dr/4TJm
d7RkqTVRIlxDDaGYhQV4CCVic0Uk1OYe+fwL3cUykYUv/SotkIlOTd9WshR0yrUb/fA39Gtr+o1/
6+cwt6xP0M/dnxPDb6A9a0C8gMoIm2G32LiBcJiZ/HWGxaUP3yqnftreGk4Kr6S5tVvQWzM6TNAI
G50G33LIBxoydGxSiPdnEUFvsj1M5yo/c6xUl7phPpW6CJCKRZde0CRqd5SRxle2eStKfe/OALvj
kI///MLEfBWjLTeE+xuZcMRg3Q3OIaru3zUYsL0rPmx0qxPKUif2Vm4dKXz3kMeXoROaLlj4+YMX
Mn6vzL9+Go3RzDbPHzF4ETuUHifyTKYXXPNi3Sf5emipIcLuSkJhkSeQgH69FONej6pDaCGwqeiB
KvIPyOCl6fqcQwGeni9QpYfNJRnnb4xybc0Q+L4xyKyfpueiW0IOfbU+esXAa60sjRyGfQqTG630
IKSYphJQadmdJTwH0Vej8DlXsMuolAGX1snQgqLJhq+pbx7idbjLXpDMXI0M7zOSyFhZRBvvypSa
q/sdlw2BRFLXVsJndNEXtGN8upt3aogB2mv1NqnylZuVGOvdxDNA9w27aHht07P2koPyvbkilZhR
P2CdSI3UZJnUsE+x5aofzXeZ44bxAGuUvAmKICVfa2WOv84SCk/DxRYE0VyE7pUhazST0R38UK4V
yrHQYNAIrah9UU8R4lXK1Ha9KEQGYUwPYuIuznf/i/PCaD9DSeRfKEwvUmMcGdu/0PoZyed7iyV8
24xu+mmEc3VU/S8r0HR7dF2A0z/XHPbmKs92xdrwkEr6axLfYr9xjR8F/NxiwLZ883qx/ewpwW3+
wY3UyVqP8kvsq2COutXww7iKfQetX94v7+fEDTXeClb9oJoxXiCiKtlF/sHflyr90LrtOj4bRG/N
KXzR+mUJUwmddYNooVx6eHvvVDe+FnNP4tlIMajuycJ8YuvbkIMP3rixGLXs3aUUtf5DJMvQxPmv
pOAja22ge8BuxbMC5+WqyrjQieI8o3P7FUKfiiEVVl5DJrbQliTJVfV5KplQHsDmiHjdYdFIt03F
6T4/UgpaO79mX4HLGPyh/8ggvFjcjXdaaM3MTUbY52Cvc42qZLihqsagWT7Q2vCgdXjxleVbkajW
Tw+DPq05L87GbUptDC17uSU/llNEXU8QdUxjsXw19J5J8jyaZahhFcrSH1dLaDcsq2K9yZyRHXyC
2tOQf53RKH3TfPHkVxScioe3vrhDMyz3v4Kx6/QOOVrp/uj5x8m2bG8uvP8wRlIj/GV3N3mwYVNp
Vahwg68uJOjL1BlgWNhF4Ylh789f86yqfHXEHjdyf4YvbjQtqgi57R7rEI/v8lmWp3eqAjZf6vP1
bTy+/GPFzMXE9nlxNZ2TL+GuSazmJ9lm0u+/KtCdf4PIVr5BQy+2UxH1j+ShC9DZBCU92TcBSBRv
0Bq5wqtZt2DlELoqK/3+JCwe0106dWRud86//QwQElt8TkW54UbJcnUMstn1ZCRMSfpWEnr8FbkS
eoRuCvlDfr1Lxs23BrRXY4cWb6x3n8zFCGXstDWLxG98K2s34Zx+dUqfI4q3E4aflhW/1mkHO7SF
vkiNo4CvSk4kF5Wiko2/u22jW31KbjHczVL6hDMEts++dIGYQBpUMhTOz1UFaG1XZqzjXwQ6E5dh
trAHBrrg9d+2DPYfWl9E2PJ8QxfUrhorWirkAnuHV3iYFDBmeDqw4UraIo6xLAz/xPYRwnRYsNCM
1FRaY86cHhMNbyouzNZtcEsNgQyi3PjRzsMgPYFLQzygIG3WQhSIQz0jxzz/gZEOlgHyNTwBFQrq
lgPh8IIvxeC11gBscYlNgh93/rCPBIg0AX7D8gg3/NLIMApopaMbVoQOAXIoo0IlaMi9UmtpWTyo
D/K5PkHr1drzUaowpluWDG1aWWArbRbwz0s6a5ax1rJchtx/+dh+FcZSeySmihPYCIijjh8fTS66
6BdtLgPs38MzXT2bUe4pwITYWfQe/tT+QUgJRDBuo1g5fEfStVqCz23wd/KK6SSqJvhr79gKOv65
pWV3sKFHiNXpHRbrdBHtOMbQJbR2SDPkQrF2Q9BLBa4/Fv8ovsqry31p3cD7Kdobd2SVjlj6Y9QH
JWz9ivLLG07puMRCMzFDpek/PEbrvyIqkk/3Kro8jPgQC3LP26SuLDVAKGImn8+7d2n+dUpRNBku
bk4WNOzqWtW4fPzB+JXxG6no7lmFuepI6MMJ0yTGGEWV7RN788t6nOzz4ZvvTkJI+L7pn/iO60qJ
Xc/vlcxrcGX8IAICzPeXHuNYRe4C5uqk1VG9W44ZUWWD0jdDn8V0fw50ab5Eh1qIhF514Fk/p2OM
+ynvU4j6SXMw+eeLX3qsSuxsN0xgiyEDN2bqhLCdtGkMqRhzr2l2c0njQ12ojLepv8Z77o8zsT1J
yt84rqO0su5U9YTTbfjpE/Bd+vo/yc8khaKYF/jRYh2t9O/tqCPPO0SeBzRRbRWeptomvF0UufnD
4Nd2xU9PsxKza93CkokFQf2kpO0yjop/ScnTyGnvthDkvwzhS84O+rOb82iUi+uPQ8M79btOmINH
P9a0Ew3IFlYxi/5erLMpBmtWJpWrBlvGN8IVGFxuZExID1La/unvZShbHY9GnjD/ySqpTzsRqVrK
/GItx++UhUFft6DUlPJaJ+T5uZfvrHAsnFYEHo1cqD2GHfHuYLu/vqn063egSUf6sn6pc3XqJk/4
vyPBpX+DjH/wGfOlF7n7Ez8FaEoKM4aPzqQ+ZmApLVLjqT5+xp/XRB56Eq005GJ4CfkySOWVrK30
G6fshhIpzZewcntxsbJRqXFaL4AB+XWi+nWiOh8nQCCJK7WgYiJ9qZ0ozNqrwPGdpeFqiHLCwNVr
EK+UVMilUDg8G5t/zisj2wII+M80psFoskgL5af+7iIqWU/OJmZE8hLMFLIDx8UIl1jpCT17h2aV
Q9Psp1eOCUqXr5ZH24doTQfXU06D0cG/pySQXoeIAmE324jAtOzCH00C9Gg9wPBLOV50gMjwW4E1
48WL9W9rqaTvcHmmWzYuq3p4ujmsIyIRtGYX85RoWBtPvMVS/vEGk6bLr6OkZeN48wupemMXRtMN
lNTqn1J30k+GQ6+EFQjptSMMvxboGeKJjq+d88QlB0g/ZBASw+hPQCW7i4mJt1APM6YWRnMJRZ8A
TMGj926ajJE+stAtnAw94pSDuDDPWwnk/wzjzULtRVw8X+F2HqX+GGHi5EAQZm8v0C7nki726v51
5cK12Odr1rfPO/ONSCtidd1NiduXtEJzVPe4T8u7KmHMLUi7+1L+dAJeCgq+nf79fQZNuHjQPHrw
I/nHv4qZIEe7KD2f2LxX+UJ+vIaakthKYf337Y3Tu3wjn5U4+VRsSELtRK57E5u8L7sbtYqGKuxu
s0gUxtBuaAZJ6zh7O5++8+e4ujHs0xNqiXpsDaWVfWa3h27FJT9WRy2FmEQpH6N9sLbu7w8IHFfe
PS03av7e7+/Wb7cOVW9+52PfulrpJhURYLFdabx8J9sy6/vH/YQFanq6EmGx6UeHkAT31Ld2JB+T
w839/jj2V52KK4m+DJb/9gae76idAWIajuwYefoKPJqehQ1480s27CyjSK861LHNp0MGyhrqO8jk
/FShubZYYV+GlWes3j2+YHrkU3nqYGXt0znJoniKMrfijJAK+/7CUn6mw7+636CDiJwn7Tps6ad/
GZJ840tbFyvKzwAMZwAe/RFZ7TOAswX5941RsgPcPntH6fpzukMvRvfJ0rLho8fwa4fWE53afYtZ
/F8voTX/HZp6j4o8ePXSYsBGurT9lPfRl31/l6vbKl7MxwYil0YD6yM5/pCCb1j7FGt6xJJDCBc1
uKIWVSv8cp72MJ+Wu5o1fdMOHy5p4oRsCk9e5/4rmdsI1QzO3IjRbAuCUebtLYW8XPjzykm/zi0p
OaCXk/PXUabDPqX0WSU2vqPFpRAWT61sbSb6d2gff3iBQqBFqQ2pxzSmCO3oeO5RcTFRmoHFEeQD
KGHxk8Ax4GtX4QUCLE9LV3SKfxqZQQrfDdHrlZDcctH5V1H+8CAdH139QB2hrPbY50qKkBeDej/V
36vDQL+3TZlp7vmFqvWwBM7ydGgpGx0iCVgF1VrTGRWmZJQW6GllWxTTmZYMg/UNeRLr+BA6RNuv
AG48gOvqRPh7q/w3T9zeX0bcWMorAW7G5JqDbZWclTQdy6QuVj32rfyXEc+18MWj8diCu1KfdC2E
r5hlr/y8Xy1FMciYcTHaOXxkl6VdPP6OVX+1fIxkttITWGNGWFa9Yde3bxVzFljx0g78N/xACiIz
G2YgC3nHEyhjSHgqIMLSNwzrkxxOTbCPwh6F5NqW/A63TfFeQfsRJ0GmMfL9dU/sPsY/HYE/iNMI
Zsm/b5OLEOkdOwExSXsJlPafy0sX9V67djHAW/gqYD4RXlDE0KbefOwXwItsSdxf5jRpRA+M+OfZ
SVnAHHqnRopsbqkoFfmssolzZfDgjEBTBoaZhIBDh4U9oQrWx36N7p+mfmncyMJHrjIGZ/CQJzsD
B5t/WcHnfO9+5JWIIoZl5iSmLTYJ4UW6vKv0gi6N7SwY0MRS2hlAGMaJ2rke8majz9rA2e4nHySH
1/PhwZpBlenzAbTNTQe29qr9t2YFsaeFF/j2+9mu6Kls7+6XVvq/WI2+H7Rluy4U5+HsKy3zRFUX
01dqVCY3XRdnER6y/9rNkCtZtLYU/pD5GWJXmH5ob2XD5WruHPz7u0VxV30G7KPHzI5uUxDv54Zs
hinkH4cou2WLnRxq+Lcf9FHq0XWYkMK/9hdzXIwKHv5LbWs9A/C51HUi4UZTQ1Et/dtuaHb8kz89
g70KTlPzBW8yMY8THkvyLVu01jP2BAjJqK8/Yju9yIuwwptxH3s+2FPygnK63vl0qe3X4Pc6jdff
pFbPM9JN+d+g6F8odsKzh5Y3kyt/I9VnedoSzgDb+w/8ZzfAftCCNnnCnmT98aWDjl/R+6eoM4Bj
zuwDblDZjBM9HvL5YBXKCWONPm4XEfy6rl2e+jRUjU45s8rob4I2okQlbl8CFv11fkQOSbiKCWRz
MZZMOFf3oiEowa7uZfrnM4D6DfY+yUzlmm+HRYFHPGODm7mu7/ScOe/0jpJg7IInv6SFvXRdrubv
XD++EU57EtmL8OjgePmtB/0Mm7PFE6+UCmEBNRUpAay5BEr1oHU6HytGuMM94gpEhm+LwOEFx6Vv
hfZxzC+8le7bOiDaGOX3YEH6Pldqa6398wv+dz0ZrV1VLTXoCp/r0T2opTGcwVKaTVgJg86dwoxY
Y0TsHT/B/GEjvISimdhzs3x6lK52ObsosNuRWR0lgQfQ2DbGyvx/lz9a6enoGIMkHK+wAVf91Ct0
TCEnD0oljJPB6uEDDEQBLORZhW7bLZv7pHhreT3D52Jo0Bye7jH3rUI2bPBJACpPoIpYb3jUCVa3
50VnKBId2VftldH+LfDmYbfu8hTAstKP1avW4/XjwKTvlU99Hai9Wd7X3RSP0BunBjiDMngr4nVQ
wy1bx4mEneGb6kpLuJDJDqySPqvhW03pn5ySJ1d8xyE5RyEXbZ52/tEWJjd+4Igz5fkbbObvoq6t
G9nSgZAx0fT5wGVV+VOBCZnGP7dhPrx/PuQ6Y7JcgNUKzMzvRqdtXJDlponuyPPH54VJsDU+UF+2
XEMOxQkz3bqnVNFbVpwCuLnC8Xo5+/7tTW2AfZ7vyad7xrcbOktiHbWEf92aux+/Sf84yjflvoP8
wrZdvGFRiJiZpRjBiLdJhKViu/mgzJ0XHZ6H0CT8RYLlEOqxwaptEuFFjSgrwfLbsmHPUnu5bJQg
XSg3z4yMolnbw1SdgEDTjGzvDSb4D+tgKnS0NLNURLDpK+6qV+do1iNz+LxVfc6WW1P7Q+s4Ae+b
Po0VfVlOE1OPbiLV48w4tIzr3KTaLHq+7RPvJlk1vmwdZThB2et4SbdnQ9QErnLp/Cix1PM3qIw7
9tRJcg6ExRO0Fu6vM5Jie64hfA19izAmz8xtX3qaFRmWSHaeJG0XMyPR8MgJ0doMxe73NozsozFS
F0vuvUhqx8XD8pQ7Q/tHa3aNPgHvfZ+acb1i/Pwy1xng0ki5mT4o6aSOqycsrqShUT4P3FIkPK6I
J3mzcgAi7GWFE+qcMrZzfdWIl+0v26GGMOhCyAobpLsrg1ZsAhIoJCIx1xKhfYqGc4EczWrp6BzB
D2Hnl2LE4wgs5ayOwCvfUaCxsit86Te1MoFA+jQrlLMlnYkRisZW2A1TLJHu0X/GCViYgsoXh7UJ
Qr7Cp/EZLyDf4Q7DitqvOM2I0kDKVxZQ7eqHR7SdjXR0/+KGyy78d/HwyxJrGOJrIITGdEoMN82w
xfkez9JgTOqxSTQaFAWISuCGUO/ENoyM8kCKNjHvbFAIAfg4jrEJS9RrzmMFGIJtVUtjsczZoo0i
PxhW7r0sPIrfqPcatWf/7dc/jNq9P1Yu17c2MFc2r7Q1byV5/RvY4l576VLz7IUOvuI7nH5q89dx
T0t+9GA7eZTAL6hAh8suN1BVNwiWXG3qWiC6safudsqKOKPzhpcUx8j2pe1zd+xvXqeH8vzL8vZ4
iF/4VQT/AqmJ+y6KCcu65MfwYV5H3KxMP2XCkJCo9QBju9SUa+GiMBmmNh5H1x/J0j4SCVOa0Xa/
sgwIt5dXWjOM9pLeVxKuGnVcVbct24y4K4Mh93fHnQGg66SVeSP3zri+ITm2Im++I49Ku6Hry4u4
nQ7yyAN+k9gzQIQwFM91Wyngln3IYxaIcixyDXNUVQHyt+0SuYQxHqAODZw7rclCv6zTFHlOTaCS
vna/29po0/5q74l1gDfnd6SKeJwBGmxDZi9GvTXN2GgMtdZgCWVIirTRi8Hmot7zFX0YLb9aPB2T
XbyHO06/gHiQkqlI35+NgiPDK10hL1fwF1LDavP87KeNmnM7xdxYDVLX2lRC5FoEp9LQDCSnv9OG
OakBpYc0ETJtBrm8iG1JV5cvl1+7rPqI1TPVTFr7bf/GeW9ecyYd0c+ygy89/DuMrRQ/hAM+ib7r
6HluKxqbWifRElISP+LPEwvsfk+qKijX+BNg/KADYcrM8+bE5oWNxdA7LleC8qs1PQEWiWJIuxUW
4pZgw5NQ+F5PbkB71R8UVoxjfNPmwGVroQT3oTmKWBNDu0vWwz5Euau5ZoWxlwtz0KDL86W4oaVY
JhXIqrEuJ+SPaQlKhVHr2VMcpxEaa1qlPvydR49LdcXm04V3G0VcoOK5D+/uPC3iElV+1+6WCVyV
oKtdlUDoManTEDiG18h62Ayg8N9pNZCeqET+OZYQ5YzYeBO0MW0zFgkcYzYW2G0JnzqHCtFn1QiR
ZwNuWzGXPLdWMB1OI9kUVJnqpeMtf4/oSBum7GrffPLSI4T0+2ehfKPHL+xR+68N9bv+n8L6/9yT
dX/snn459Hcikufgh8L0XxbbH0t8X47KA26HNM3vvMXlw5VJhxipBM0L1JBcqZhRT05KYbr/2JMy
XrzKMIPTxovD0t750ZonQ1vFTMOPp9/wv1XpF8eLb5dFrDyBsT8yRmykBdxCyVkIlTqC0r/vV+4a
DQvGXvX62mb7wv/v1Tfwq7sxgXejwb+u6LvZHSddJ+pWHCXyGtbf7lmK4Pnt/2FmVVf4xlLsG0UP
dAXRDB5kdStdiO9eTnOBDJyB57aUV05z4RT8E1GeY7OYaNCcMNRYaYQ29hNDvIBCXgyrWKFzYiik
nDa5YcT3ny/xcTloUxLLjxpDuKKh2bWLdDhr9IP8c/4d4U+zSBBLpg8qqLfveV5BhtFV58MHjUwM
6VEgeVOP68AE1XxLiiSn3R04CITLFsbXwuCX0sNHYhBlIeXCWAVuoWH8s4QBwb1u0PeYK7SsqVoD
sMC4dJ/X67R7vKLuxQt63MVEndtDwzolqY5fpcQhNs/QIyUC8l3WME6sIZNSQdYUjylPzg3rSzCJ
JD8x8EOUKYvzc6FvRVziwAlmBdS9PYKlYO3JfbxdpWjyrp7qfmEcg7wZvrGUaHLF5jXoGe5eOjvo
PDy7hNPqEGclChyCB7XJcWQCs0tQoTEAYNr6sMPg/Rug0GEbUtoVOoR23XWajHDf1u82Ha6xBnCi
HsuAdOYylW6L2H27MXrKJ/olccrpFWVsnrvSF/KbFIcghlZLco7iPWz9lvI+mM+5d5YSNUJEtV5c
IHKX2E7LmlMHHz9HxSm8vEXva2A9sPyRN0ny7sepsCg8QoHyfqm3/J+O5pq5K3vnGyH9pw+GlXq7
QGKFMzpEHzSntNGtlCqpXiSP17blNZw/RJ5zcwndC5Zuf1cn+ToMQg/WJE2PPKGPHDYq7SpmHNwA
ZGQq8ZlJy/pIcvgXFtCi0HgdDVc0JYr5cAsWi2Wj4ZDXN8xUIMP6CH+HOfinxvxhiWXOm2g/4BSp
6nJhtskdgPNwI876xkgyyfEJFx+rLOSqtIyeIvNbXBaqjNUoYWguo0pJ0KNNX88cjg0yvKOKm8OO
63frXgd/Dy7VXiq5B0pRDdQTlQZoACccjd3c4d9zzIHP5oZQcKyxcKPz9WFFi3A/5WscqCium9o6
5sVcyqoEu6/6igZKcsBfwHFdnTbDC6WfRl7csB0WfdM4l0N0GJO32ljKKcEzRg5/RJhaj7RnXbkx
CGNHe4HUPYXAuujUFraJgr/xwsxY7lIDxzo+ViBebZ1RnCCqSjm5DYJYvh8GI//g3FH3eplZ0hVN
ubyk/ArPn0ehzercUQFcHz4+Z+fPNFkkjQOzgREs93UXhz835wgloKK7szo/N+veNEvW15P1Nr0j
KG+CitaTEMqsxsnnw7aNGq03gRHg+9exbWJ/zKckDoK/MkkrhsicQENjoidCu+OJJcff01di2M26
iqLh2RUL+xLvrfIQgqKaTmhsp44CKzFhXqtu7MjJ2CenN3perTLIoFal5tIHBkLoof1HuN03y0RO
4ELKG8P+bb+5MF9+vrhGbq3jDuOBFhLrAlH49Gtqm/enSynMkqp1Uw9BoC+eguEjj7mrjogy3a+i
ZHMsDt349ORQ3tlmuxKUsWyxCVPYrW4VNDRUyNT6ZWnkD5PPwwMXPkoQdRsHU02m6P0l5gqXMtGO
FwRJQ3BFs6IpKechL5SfYaWktTQ3LhWlE7iJkCO9QHsr3Rbrg8ehL2CJZl8daSomEy3D+N4y0Owb
7veI87kFWGNpWBH63sCFp8Wlf5dihIshu2YVKF5Dc1A7Gg6USzXJk2gTk7gyEIbvMC4LaiZ0DD27
U2Kl73MxHq1LEy30LCBFE206rLGxwy90IABhnP6Li+sSYwkMPiLMkqXSY2mLkZRfHq11AgzsDY0I
JGat1Jc5z/GAQx6yxCKGPvTYmi/SpaB58tyO4cLO9WAK+Z3YiQvpk9ZDmy8ORVZX/HFb5axc8u7A
Wegu8PVF66slhloPrM1VXbFePZKwBiWFD8geFiEre/RtM03eeomMtHq6nFKiQqbS68vMOOe5/PJ3
7gGaiD9XhH7AzFebbdzQjcx1B7fBkaTIfV+qY3RwNr/s8ZbFOJ2TrAVv2cDSMya+TpapoV1rDonO
kvV8xggzXjOzd8rkIQ/rAx8PJzNVQfzTvpk9bDK8Ofjr8wfYMTi5jbdNxvi+4gPsDlGjF/jFBxK9
/gwqNbiITiUCZyFWm1dV4NgOILcErBnXqTuqOcZAQIzBLUA9H4w/wHlqLj/nwouVANlf6sYxpEha
TI8ZegQhPV2NSAYoLDLy5HnGZdOoJiW71X9T3SbvURX+wJv5bthGJx3U+Cm+Qst5iJsOl63lGMcA
+oO4OUUqNBaSa4MMHT9DO0HaHhXPQ4bgF63PAAvfFxIKU48QyilvzwDS/Ih7hSK23ZtY49cmL9vA
RnZG3p68YKh6klYS3LTQmeUymF/5XY9Bbaxw0vQhlgEVH6LROxc3IL+WuPdtFvpSrqs+Ncqi7gww
xCi7DWuczRu5CscZc1mKC8DMwZyCpb1xmAb6oASeBM6GmaJdkIr1Qf5da7AOCtucplay/8xknjkV
VbTE8yiL1Hwo8TEQ7YuOj+LGN3K0I0xZKi+DnvBEDzDhYESDuzwX9EA4ngz6IU4jQ4T2m34lN+E2
O2F0HrjQCC5RnE+fNmTN80TEdPilCnD1CR18m39GWiH2jgo9set4tcVowTAC9qV7v6Qm5+ZruCIs
KpcCiu7eiwC9jiMsU/iKrhKo+xrrj0/OAF8RI+qYbvnvOlXR6TeSmnMP3A8xi9ir41v2PZZ3mAmQ
9zKz7Whpi3+RI6q1X88AiExRk+dsmlquo4W757LuFZNBf6dXotsDqd2j8RNXDFql0al9bRrrLcqH
uOtsi0a7CfpNjq/NiLfHiis8Fe8YbmVgU/z2LxQTveTbsZynOYhLQ7Z0yv9YlTAhBvqIu7orQWZr
2nPv2EqkXtgE5w/TwyRZLFRJD+Hpwk0qaPitXhuhXBshM1KTEh88yFIjJQASoMTnQ2S4cX24gcby
6wMMh9Ze2XoAo8+Dn0nBlow5pdNWg9oc/kUhBrSVzSVvYxZGLOHkxvyLXn9jX6qWrR9vnZDUiiDn
/yOcwgr3XTOiKBdjIlFm1RMIOPGHS+QzQIZ8aJONkqBNuLUbqtBIUR+eDfEYYNg1x1kvpX+1hivq
4IbpSBMhcvv5sRdwPDBTCEAe55U2zErPn2xkWmIpV5iS8Y4JCIO/Dl213L/JXawQtbcxwgx/Yik0
rXiDlIWbe2452SZHMEKb2nwUnjSqp8EzWLtcoKTDLOP1SuFdJeBEyF2hOZTpoPFXoLVXwuB94EiL
CgV+Bng0cmtoqa4ENh5bdc2elkouiTOA08aJnX2Oyjan2e4CdZvwpeEMkEJl3OHlCPPHzB6vWkxT
+g8kGZUnXEjUer7e8YRi5Dqshjx9fAaIHRU1IRMx69S0L9V8vaT+LIyoxgY7pY8sKSqcYtF0YqPl
ovSGIaB3R4vav/+pXvwQ4S6bKZ6987CCdthXp3O1ZmljalSWDwHKQt+yjGHeCFjo88gQg/Vxs31g
4PHbOnhZHWDgmpBm7WgWEhkFS+GXPuCJ/Hjrps9BOreem7yR3cv6I9MvuaVOzj+WqOnxOGsQ2jga
HBEfIMje2mo5wOVTpBS0XvV6PgyamFkjUYL2u4eaEHKdxOoF8YhPY9dfPb4CD9Ixq+0dGpMxlsCh
6gIQu4kSxvOSaF37uWrKYca+og5fl5ZFk2MEQH5F39eOTeYO8mTZtJb8t/VT0bjIFwHFUnylvhiS
YIZL2nuJT1DDNgJ3TRx/AVhTaDbINJNDn4ykoAeHPg5m16NoaKLePZHgDHvm9QE++9jx041A6hqV
qb7eRkZXPvLVXlEn0ng0fhNKqcFDnxwk7db42X8Ux8CudYb+BSvIO2F2v1dvIef/UOs4i30MLrHK
q5ZQ0nftgvu/nAE2rTEafcfQ30DKewi71e/gNSu7lx0nmM0zQJXN0U6bt4AQvuhFq3FcnQDowKas
5PwVWzLnGWBWEx798zScZzBlTrGFk5J0Gpqz1MGfgumotjiNrjsIRn6oFUoaS/qXS8K4Qw+J98g2
j6LOAFtnACaDg9fzu1+WybwSwX933nJHrfaPN9IdzQ6VjZwWb7f1T1cI3L1xNc//DJCzGVkblbAV
SOlGjz79/ZIaHTlyBviiCZ9FJEW2Qmep6rOHWstH0IPv6mnLMe2vKbar58zqHq8GpKjSRkUOsfai
rlRGaXV2rhmsRx4jO07s/I0Irg0l2cvI+dYN2+GFVRMPpMfOQQAVevpkzeKqoBaVL3UDv4OsOuWf
Kdr4btG6Ezn7wyl6IXnWjZ8WeIgEmW37DHCZOAlv9bM4YuWf4P92yqt8BqgzORTmkypKfcAvfvhp
KCoe+e8hBdmepQTAgIeiGnrIrVuBFhNWIjnrVRQi5h/YtdqA+sH7lO2ojK0B+eSolBwgegZICpjB
bkjEumk8PQMEQ1cyDvnbLNsCstyRtANH5xzMNpK1gs1yyvjrl6kMhz4HaV+r/e4IN8xQ1RMtZOg6
ZoMdy/y7yGcAJblpNuN7o9l6WYQzwFPaipcqpC93Hj98ckzdtyY/zDk8xFHKzGd/nEIony+Ir12l
zdNc0nEorRlHXOsM4VoD+zLYny4t8W9np+eqy35mygp8K9tP6GGRwN+qsRTi1DNZVMGqdIVuGNpz
oxUtdkT2ita3VgxquKOOSrvwxTdsH7OKIRiHygOt6gw+cQmY30M7Fu6C4oy1OdAOZWJqJW02Rm6x
hqwy8BRpFYhXShYT0EoXUDIsUQJQCvH35N+U9pyrIAYtv0c/e98AaBNVzzFkUCU8bQ3DQbmS7IZ2
AmR7NhxhR2IKe05aP/Nqpw2uv6J0F6YavmfxrU06LL9LosxSAYbf0glvZz3rps8AmkPVzGZ329qh
i1jwfQSy56LVIQVRcvKpP3W0rF2cenMv8gzwFs6TgQRcrZM9OprDNdMSYeir+SL7+IQ8fNoUulzH
7noN85vpk+vRQUZ+AvGUz0X3BsziUA33elHh4T0ztlMmId8t2V7KtNYRdWka2pxu53OPW1nFMaqt
/BuP2t99zOknzNHXMvXRnOteccDZmp6KzyO1tZ2zh1coEzb7ekI+vcLRrpQJz/Uqoxpv/9q/Uowz
T6Cr+GqH16igw9Up8QfpC6BTpZsuKZ1SWv7btp+LapCIr4yOLUy/0nlLDstvhRBuag1vRHuTGdCN
l7wnPuO6w2HojdBITMfhCsZ7V2YU+Bcu627o1MMfTiDfs+Q/GJvv+0nuqi5C/TaofUFuJTh+rns2
KkihYBaGdP1YxiiFjv5ctD7d9JelfNpWXAiQjw8f/vP+62RMSRti5y2Fc/R59bkzQF7de6Gxc5ML
RNAXEbeK/sUwuegtj8QzwNEiT5YhNMhmZYaff4L6rtI7LLt4zTGlPaM+kP94Ne1uoYHH7uGswcdW
aOupKlM3e+f2HtY3G3GQFS+S2noo1FnqZzERUHgGCE/yPpVFznM7T5mtme8uTVojpMkbmOly9aad
1setQW7IvxDCpnlUSadtN9/DNsQtjQOCkdEr8/ozgH8ur/hYIZV1yzHKafYMcCHVyyP6ERmD1Tg8
A7Q11582ngEiKGcAsHqwfMdi2xmAYbJ1yw5jvdYn63O/axl5FcnzAj2modUTuEaddrNXMrbDnwFi
0u6awI2X/TSlxSbTVuw/XDXbpmA2w1zJ0kYlyQcOL1o7whzJ14POAK69zPap0so+xa94j4iOKWov
e2d3fi1jR/pPjNkOhM4AAwh+627gzL50Hy0Eja3D0nnymgPlo+eHKiNqx3Rf/1yhhprGaQ51w/c4
+bhfdvOUgIku2rW2AFukutGSciDZMPag9QNFoms3G+NGywJG/B8sDiNOPD2P6XBUcDYIxohn7mhE
nYh8SXTZFifzb0ZN3OuLQXgjvaNCozb2MPfJeXbLM6F7BNk6PWp50r7TEyTrxSdAugv3zwCfZyaR
U5Mm4w9ebmXjOjS65TXgc98MxxuP0++7tF3yr6R6y290uCTXr+pG8Hm+M76OvITcgh04uFINPS64
Fbn5u21tnAEiBw8Y4ykPxJ+YMti11rpdSnnVMU0ZhTaZqaPNPjbwan7Zl3wwSrzc+0yDi2yQsjDi
KpiQd0+tfHDGqaU/z8jYQ9Hpq8fCGeDjPmaT0k9+mmv4u7qXzF+2a9daM5/pfVp9fKCkQr4NrQ1r
nTV7a6YSeBxt318TfUDdt99EfthG7ggfdi48P3ydZ7+9Pgvr8sC0JHlP6R+3tixSVpM28BxCuhOu
istY6sBcwJbRGaCGslF7BnhsJDv2BSl+BuA/A/h6rb6eoL1pF61aDhAWG/zz4+SJ57SBPWqO3I7q
1sTyr50BjNjN56BCBhbGeddPPwXUIhvqyyB5D6YQDv6fqz52tPjyeGY8fGYh8uFQyzg4WXf5DBBE
G9KX1YaJ1l+RmDWkcVzY6bFKslOEoY+RN80sOLCR6UuhlF3rfg3iYdk1jXKWVnLgHVopf84TPSQk
7ecFHEL3+PM+auMn5hBDudasRtBfzuL/RKyRTVSi0aLBQdLBrQ9HzLOyZwBURZLWsrfGATUtLFMD
muTp2tAwxl5CsyAC1CVarT/O7tisRx4o5UUP0yLiz6QieRAGQTVvySAy8iSEsnUktADJzVwYNxGW
/PemdbmiHzx/BLeWRN/7Rc1NaJwGX20zpYCL+Hxjc+hKXVFp721Mg6w1kjlN1fDmoLcoZkU0Gvxi
eA7CYWFOVEb5mLJKFEPSPZIKs/XkkwpTIbWjv30RyQb+GeRrvHN2StmO1xoeTRtc1ToRwnrx4AEn
rHJKGkqX6OsfnjYM+2uZw47WOGoJIewBDD8WA9gOyx9CNykfji7IOBpQny+dAXi1pvf5sMwCz1zn
ouusL85f6zoDSLU2meVtlJxqbbgYYz7RnAbz7ZKE0SkOsxuuCAxGKRTrfivPXyPQjm/OSMCw9aW6
lcXUa55CCeoP3zOAGQI3u04m5qU7aozP8RoY6wYKZhL7+x3LMJ8TyHRB9teb8QEWpyYba8oRbyq1
KKouzmHRrv9sCIKWXu3pItDHsseLuyMmTln3U9OOTyeK+CfczwD2XwopS8jJspBlcrXJBC1AI6IR
8gwgsMZ/KKkAk+U9OSCK4B+rZULf3qfOHsXf4aq3mFjfuOP6bUfTzbYzmPzGfZddtfDy4SGzz0pC
RutDyhyyjFZJeE+5aTPfLxbHnrvIba5cpve/eA+Q5xyNHnonuT1BfnKKOE2mDMQ/oQGXGaf3PwNb
5JMFGtxgyGnLH9EQGggdjERLoj0L6rDYqYuBgS3UE7un5VcPAgIzOzpb28z5dC+q/XyCOgP8MGtN
92oSRYQMzcCu9n+SDYdWn7a9+0k+sPvSV7+2TmVkxodm3rOy2PQrVjGivM84A3S0hphRks4AMjTd
QRsnjQ8+WZ0BvMIM/xNzM8ggclq6ej+G/NvA7ylTUyxtVanpYPFgs2yXvX7SQhhR5bQ6CiO+bYMZ
mw08AyxmEPejuxsTxmVOyUm0sCOURDc6m1OjfAyKO9Q9tSwwAf0mlPevIiOUH7q2Uk40XwZQGr1C
2n5hLskj+8Fak9WTneNHo/nDwvE98T2zrV4r8NbxWW+LpmXkNshi3I5WHS88J1yicnrPAH7KJEvz
+zm9hNn1xoFbmE0/i8O/SaZxFmJ+mG/KtE6pDG55qS2HzSSmRmlFZMtEwyV916GIpOVxaj1/E6UL
NOuxKxaBnD52EqGN+zD4ywc5eY/mFAdr4UPOzSGDkFuujxu+9NzgcGrbeUiZ2dpSyTbLGFXlXNgZ
PvxAm6WRKFfyn41LFnXOW9MzSVqPZ/ZbRSvkAzI3tTrPAL81VgacOsS6PI5n3a2DpQ86Ni6HwsX+
7tsrfYIqKwbQSKHlWPIi10s9t3jkSmDJae24IcemA9WarFle1LG5cUjp/4ic3yPKiY9LI9c2Dn4Z
jOxRW7N6l+dUeA/EZ0slg8zY+KowBws0sZRkdyeemkxjxAq+Lz3kRSEesG/FcX/rlndureMLRYNW
3J+736Gf+W8HVDmvF2pIZnOebhJapzuCNNaPlVW2kLGHyMe55GwZt3TOQyfOw9apytYHFidkkevs
E4b6Ya6HK2eA8a28aDNMm5NC9ZSUG8Tg+IT/N83fY5YNVDOU5Fv7p5JyFovGra59cUN697d6Q2dn
TzV8qP05C+O7r8iEiWaJxSSKQVdr550zgHs4zUeoqwnXJopkdlnszwZtimcfIloybkCfBr0yTzsD
lIlZYHpoqhbWWp39/LQj0jVK3oWJsGDJNAu50XUNfG46Eas4ecfDPcyfQbjsIcMRBR7BQ0f+gVa3
ck0N4o4++Mqqrind1w+pDjioTN0Y9RPMmv7WQI59PHngt4YiUErcQr3WHlj8mUwYiZCCPo7aFScL
ZlLcqpYDOkGzY5WxDcveZGj0h66Ksd5ouEjSEpUnnuzfZ1oQljo1dOAQQirED26PtIbUIF3zktYL
yTfp7lClZ9dtqtdCs3a+f5mV9To9Hbnwy05Wmt2kpL+VymREZvpY8XWlyqI7BaM1Aa0RSo2e/f1f
w8UVqldrQx8zRFK9+03VG3lP04SRhyvIGuSO66/jVPL3jjGhXT5WzGMxyhY5kLKaSpaBKvAitx5O
y5JHjM1cKUHrlHV8AyUJs+WHOwM8pHQhF5vFZg98DrI8DxhmFXFJbKiR4Y2ByUha+qRtgxxwuva/
R0yvHEdAJyp8yNDTtEIKIQWJjepPphqEfxBx35BdFCfPrtveGbmhv0I5nG1O2jCgHHZiWgguDhGY
qSsuYRby40NlpsxngIxc6Y6sJ7/FyXWMr6KCNpbsbx9kXssNuf4/7LjpPFpMr3YGGKUp9FYapFQb
L7uLQT/BKGXhM7nRFh+9fj+M3rSoDTgD4KDIBb1ZlX/IrwiL6eNfmKk7yNSja0uUmYmf6IhsLeqJ
SMpuD2U5u/rD5Ox6pJAKMuggkyadTK5RaiYbFnHUrT6LTSnXg55NO0Gya/puwM7fnc1IzPzOGaB/
3oAmXf5RAQ+pW/3x3lPjNFHw0ocylaJTs4lEkusSpP0jW2a1ulPXGzQ0BmkiYaX/MCYspcA91QLH
fi+QJN/PxWacvnoVT68c/sDdXMJMNlM7+7LZ3Rc2+rdskm9YCvVJQGJLpe2SVThQ/j44wSB9uES+
O57ULcGOD/S8Saj73Nqm4F+x43tv0ynirVb/4ZsvEl88KhC/2E+NuAZApIkQDwECQatvZq591eLY
l8tt9Et2iF8A08/HAZT9gFdngEzMn+tkXtm9J43jS6dUR6z0/uur/6b8dmjjOEeuA16j2sjSJlAq
+xBZZzW9yhds9RWzOl+OEa92PaC5zodMV75yunAlUH3C8q67149T+ucrQJcMvDj5Zw7xGMszwG0T
100tCgk2CLU2e+0nzIPM2QlIP6AljCztXcvv9tlCCcryUL1SwFA0PvpHE1yUdOmQL/g92Q6F1fKJ
DXCiIQ6qKmzxDODp+IWYnhNVSmmoMGw1DiT1Zsx6j+Vw4GyvSVvHoyN3kR0/aA39/HQDd9fZKaxf
8QxQsRt9p+JnS2rnzrmpUuRI7l6U2+6rfaqA0qkuTdekNczusHz87/Mll7b1X+ci3w9qjvRul2Qf
npuuwMLunsTea9aE9lL7684AH/qHmrprLjU803yzlHZQVmT/zkA3gBaSD4J/agfvMqc4Dv0XlXtA
k4rOE0qk93c8aGbA+viJK/iUOvJhVHwzovXX5/NT04sdIS23PqRST8LbXGiEFzCz3Uqx3y80lLkd
Sd7estXp4HprhBb8u1+DdY6ee4pM2pK+v4yuYeSwOARZhx4xBwtbP/vVZQCFbqn4UVn3L3xJHFXT
mt+abPA+vFqdY4ZZoGruVa/8AiAZ1smTEXYzk1d0qigl53IPaB5ffHanNT6aWHeB5N4cN7u8Ux/5
gTpkK7vuTc4Z7h//1ElVf+jovTm4iJQk0gRJcxLcJX5KtqtctAMNHQmI6qY5vUFKzY0IQfLfqoez
ttBqjyTi7pc78YslSHejHWS/mIUikgxB1oZRMXLi1NHEUeh09OHy1ORK68S/ji93Zlto00xdJbmO
zTydPde/u0FdNKEkX/ryUF7juAqJ3ER+9aFJj30qgJPspVhtP7v0gbJNkwS+xyvVyK0ts3S1wRQo
+ILK8YdT+OHVpPWsDeFZ8K1W6JTFpuy2FXWQEnnrqw6l5vCwZBNzhJzG/bdntH1KjlD8wjiVph/K
W8e+uL7f2i30G8PMehdKX+VNEgtozBEJjafSfB4rX99HILROyyxZPH13K+Do3HQR2Yl3WnBcChPt
+ImSelB6BiBRcoccYJS9nM06MwrmUopZwML6HSNlk1OLBcqqZu59hda64mOtO0+SNqGH8KpVRST/
FjJpmbpPU4yeHYyDulU3oU+WoNvUXXLt7PrRBmzB0OWwh9pALqdMaKYHLLOnU0qClgJosf5DstKc
y3Lv9HDANGEX++NcLvjhLLnlE3UuAEvtf3UI0yJS7SnVsybjJCry1T8etZUtL8zWiOno/oJaVYr9
2GZ11F5l6Ef04S/rt9xKvF3uYy4H1h0hYYsls+PX+tJbqTUesofQms/9ZPjO0Ap0e76E1og7u8ok
GtblQF+ulaxST2mpWMtJyyvRuDG0fBhxOBIkc5pB2JpqK/l0+u+4wR/TTBOHkjIH/esN0eZPRqUj
eTKsxVKjQYeua7MLO2FnAFvKRKYJ6GCNpjqePCV6X2yqvfSu7ak7VTNN6lr0vT+Hkg+vn5KJVC+t
qEnqFlkDbGpwUIpxp/Tvt+788Awms21lv1+ddDbaMrlZ3BdYl0mhSoaHxrlWZw3QkoVD7vQvU9Wd
8A+aUBbSkfNLlG9DSZ4WjdeTHaeOJ6FNNG9pOy7tlUploj1CttifkgNknILHdo4tTzEzk4cpKRp/
hXf8qHeQQn+Q4/rZVJtp23UQzZH7XArC9q18kZ31p2lLGvB9Mo1SdvjFH+E9q0fY0Dq4qPlG+Ypm
f3Y99LerrJ9ztlCCcbd7z4YrTQ/x9zdjagovvO84cMYEQVvGP3XjWCGE6r4dZAW/kFv9cpOhv2g2
WigrCrM7HCHqtWr/RvptinAU6fioAgHWA/4Z7qVJYp8Zy6gJJxPORyKRp1W2JY0JK/JtS2yKyKmt
6sK6RsNg8uvP36s1AvcKyCoNY9gzQCqHfXW1E16sJzJZJpyU7GAQeOv1h6xBlUDzoc3fNU65C2zK
mnV8OaXxd/mDEYz4mtG0JuSTAJpG7WpzC8Je+NLnvstJzOw+XiVQCvWgyVcp5IPI/WJ0MXj0T0K1
iPUxTZO33U3pI0QtJzUtBZTIem8iaTsfS3Ag7B5NnAGKaC2mdBP52zawNuuwK6BmU5hWupRis5Fc
/LT0yOwEJ2W1PiR2t/cN+Ri2dEy1OPhinLl+QhePnh3eEEiZ+EUrlcWQWQcuPB9h0UmPRfcQulh5
BtiCYRt76q8GfuY4fYfZw8guUxdhb1uH/AWfAceXKIcWjek3wmvf3U5et0hxVaSsxpNvWyj8OQMs
z2/ZJX74QUFKXAwT/Zzp+sliOlzUUknonEU2KEHR+VcNs+tgYe/uNZqUsNRAfi13u/4gQ5WGvxG7
RBq0t1ZDqeCmRo+Uc90heK3hx8gDx4nciCsB4waMVPvc3ZKJXzSO+6X8n/D1w00cPz6eeTK1SyPx
UdobIInVH/NWw6A0tCPXrix+TqUE5NKEcTmNCKaoLYO8GFo5Gs/S9qTVNubbGYCumDL12OK/D3fZ
DkLtgGcA/+NbsxqU3D2jmwuBp+QDq/2kzUiBYP7G3Tw/jFh/6yn/kyNQngfUZxe5mJlObaCBSWUA
EelooVBzMkDJfkryKlbirtQNjCsSyuvgYg+52WZ4ESVvqtixZqpC/8zIIdAysfaHlg8s1YxOFfJ5
oAV0xOWTnLb63ykjS5BO/jk6E5TpkD+ugcGCLEF5K9OA6yB/2c91Yf3xBsKrifm6E1AZFOKitz4d
E6JVMG0+a/WI33HCP0X2AdrvDLCaummnvDozIB4nGLLcm3xc9dB4JjGx5IhRxxcXtk18RNui8Bg6
MW3ePDyk4dH8igI7zXHdCnBM6bFMnNGIdyGrNKubnGpk5JSuIv8awVv7oqi+JtRhGGW2iua5kOQH
2VLjhLda0lqrfnmmn5QjN7fucrz+blB1jNzHrI90bhVQu3c4Kcic3TNAkxXTttbLa4XDQmTeqfXd
6Kg3RK9iPpu/mfyfiHcbRgSp/WTOTIuZ45yhIpLsXEvTWxoZKSPn63zHdzuGBBxG5+JG/9wqPlYW
55Ld1OrdmdLjQfYDqerPyNb1zXncocqcXltHrMprVjU5QWGXLf7RADMU3xL9wF13Hc5U9+Xnq0P8
ktHSGWA97RiS47MFHTuGhlC2qO1V8yM6Lzmeft6S3LT1fauz6X9rBVQ2QGvBl+6wn4OUvK2FY1BD
5N8DWSrFkhTCgDdaQoe0Fy1P6gXUuLXd1Ywq7Y4oLxm6WJ/MRnkRSpsTyVQi3Gk1U/lfmDxbqgZ1
eXu4ADZekMvUrI8mnMhO7fCU+WpKnX74tHiadGqLaji0uibYvxVNUdnYpW4t00j9EDpeliFE+m1V
897nkP/HbuXGflpewNgsxTUTc8SHUJOt9CRvoSuvJ+5joLW04zFKB/j4YzyaTQOQmQvU/aDxrhKP
k6GX5pYaJhGvpQvr3pwBgs8AX46RTa2bI09LEke8Zsmt+07QiYnJhl9SBB13pyj/qI7OEBq6JW3M
PqT8St79b5r4p8npdyvnaSrEO3VHPFM855R/016+GeV6V2SN3+ZZUODiwzOAY2VewDQ5DTNxMLhO
K3ucac4Z4PlypSWs9ITUre668XS96Axwd6k15xQ4u2E4Pyub07pwzElO77M+5kA+LpokMeRTxxON
OOaRU7S25+I/ID2xWk+NdN1EctipjIvRyC7APLE9TGshrGQDcX6MOrMbuYBMER+vIa9VZ1M+LWQl
Q0eEqpH1M94zFY3r/p7kZK/CxroUhuo72A3J88PU8R3hcd9WCsKIPHugtXXKnEupTg4buoNpyVY+
A3zM+XLQjWXOhGA8qWy1PVVamBlaydQhqwpSN64Uat03CFD6snaMXAO3hlGQMSyYSbWdxaetSH4D
HNJ3STOlJGd3c6k6YrQ+2/NGfYO9LE16g6FPz1+ugeTdR+byU+/CkHU4DWjj84BMq4mVpa2+6Dz7
mcII8bomlDhVE3O0b79Ve318yyMDKhFJ8+mB4bbqoyTIMvnJOIwGZVV2dRcN/faytGipUNabhbV+
NsIEVkwR+fowP3ZoU0cdab7TMEbr3st/V6V0DpDzu8jtCYK1wsmsCzuNF2ngH0vSh3v67fBjRutu
yQ1mL70d5KfwBGE2T9NzFxNy63QlgcU7xLvyGyUGMQiV+8K87yN3NDmwI41jVIS9zgfZfrZN5OIL
2wDLmrjf/2mP7kHHOptK4aSpQKsNpcEw5YxR5WGTgFZiiU6Al7QQpnv3nn24Zsxgn1tmalvAeJu/
ac0G7y2ShSQFxfqenoa0912nxY5g5L0RVvdVYb7V0QiFOIt5lx+UiU9cPZNhPstxZt9z58RmRVsp
EQbWvhbktUsP+RtfhfZvIbnsaWb1wGP/DNBgxHd+c75zVU9H65WUHLdL6/PQ2QNfu4gjQRdDwduf
/uwgD3Dd0VWPajp8yZ1Tx67fLMZnVHi8QQtQZ54kv5D1+zAEuSMd6KqAbHCubV1zXXMesRe4GkxR
nX7jGt05RyatSUNcprqungFSILPNFfAG+cmxmaKuV5mbLF5vI24WNO5CE6XjHaNp+QEhFxaQOx6W
8K6QyIztGyTridsBBQ3Pw2bI/BR0jlFLXDe5L3Mzct96ZkOYlPKbMpITBQ06dD1Wc/Fw+PyxLm5V
lRN5MitD47etqNWqkBIdoIrrTn93unASpblIdB05gXxo1XpI9eLDRdmJGaVzUiJXFGmHdcs5eEJt
bTYKjxIaYquPxKwK2NnPktuRmVsl/84AsxCDYoMbGQdklePSTwtUkV2tzW5sYGUYBhEcv/zJLAV5
AJnd6G/cxLTemag+AxxogilY/jXqDHsRJfvmh9SrPzOJ5EkqlUai3ywdx52iSqxeeZ0BwLIppUi/
zsiWlZZ5cgoytOi5/dNbW8k3S8ib5NUoLJQieQYQi6H5RKsJ76zoOzv1Ucc3h4/Afz7X8CNovjt4
S7ZrB8nk3hYh2pgLozpRVh9e07/cRdN9NmXPlRUgK5VCjeQtDr90rR27ZMNLfWeA3R/mSTRxq9Qa
T1ldMjv98iQXgxnNOThu+LS1SN3nm/3vqpOY8Voa+BntPtma9RYZ3PpPko+0QLt2YMjTw9Se3egz
wEkrVc25f1J0tvUJJG7Tjgr+UHF+5eHnJNnD2Y7HrWvI7VXCk0VKyhqlNZUGu+OSdJsiyM9BZruI
mxEJKRHu//nG4TszdffyPKZNKyYbeWzSvNBm960cVz6qrtlcbCA4NimZDlj+d4UQjzHAEtGrXzby
2kekltUYV8AlQGCXghmDQHoA7iJIVhHwfCgcBK8d6KmamKJg+jo2W1tt31Q+E6IF/RY5OWyvjigW
IAKnYDFt2sy+uhbDMiGsVKtjd2Oi0tBTy64lZ2S/bI3RGSBqlPSgmfp303NizCTkExl/OIFRRrvH
91nkQbdGKzNFHl084t/qafCm4RzyKTPNu3csfZ7xTr82bVu++KqKIYv4cHylPlOFXefmr35ZMleO
dH2ntau8FvI3QePas1kztPMZAHucY09tsvnWEvalc1NBkzf+TTHNKHAeI8W3NS13oFGLlP7DtQCL
L/FkxfWZJ+mymKWRqHtOTjmvIz9sCn0azcRhL9Iy7oY4eagePChk1MIiDCuqrcqYgSubcAgc3zwD
vC1rJygRSBmtn8lveDRFF04i59/kClmRa++Upo5iY8pxBn6PrGWFkYd5xdT2RJOVVKpDm+VdE++A
RbMvLn/PAIfTCmtWnNOfWwO5ywqptIO5nr8aafDg5su+TtiF6twQRuhYRtDreo3PNCb6rcTcUNaG
72+5SOn268PyH4S0vDeifkBSNS3PAItbR5QBhbXSoavCRWEpD80ykUjvf/YgNCneVh4+e3+Hunuc
swLDrx+ftruSb9YTokIWqKuy+5h/PInS4NGILMG4KDKt6g5T8A4I/nGq10/ySnVBQ0vE3c9/qRSa
0MQcy/EUGcWZhHnEU+/2LA7dG3Mch44faLRmHq4moD8PGSxG/STPih/ikfUyHjfD2mlN13Gn7PYJ
8t7fQTxzjjvX25a2jtO6soEfngdvvhiM0+iFxrDrI7kUbBB/52UQPiqEz8HoLUk9+a+isVNw4qb0
QCRmHcmlAXvu2ZCVLNa/lUShr2ZdJ58SzwAqBJGGBs4zAOExKdeFKfBZs5kyVGFIdppG4QFHrpST
JRV24xpNUwRTX/X30YnVbo/kPxZ7GJpIHi8PYE1z9XjdfA3FTKOUhn+/gE6QmBFyqGIp6fSN13Bx
kvc/GiyFVyKoZs2u+rQxUAmSSXEBgj8SEW1LRdJ7eQ8/ozVbqRnCBC2XCuXHtFi0+I8olg0kd7Lo
ZyPIo4fkyTXmeSv0qupg3x1kKB6Nn3NIRPVYvaKKyUq13sJXgV/YV/UokwuWaHaiGh90V70I0lo7
uzEwjewXX3GETloaHLx6FX08+Mud0nna3+K8wcU39Pum5O0OS7JU0G0aQS6t3d2zZh/6q2UxXkcr
wKDuirVp3Q17K2ID5V5/h5/noP0GOAIzNeb1+WQ0IGWb031Ypi6gTnfhIVWTlt4Rz0FYWIrZQckV
CuZI8dN2qU9hTFNoj1XK1614PyNfZPX8xrkPMxXrsLS52KkBtKtmL2ZmqbCPVUENdMrj45n8BJJl
fSprzLP6GDqK2UR+BZf+JqW9EMww+6QS+SUtL7jn0BnFChm838SpVlpj3WLvThTg1zcD87z7APyp
i05RQ/GxyqEe4GJGUMtPvxVnyIVxZRFQn252CjOX3nkoB39B6u9Xcnmre71DiR1SAa99c2nIP3/Y
h24Sf6G48IUAUVRaVO7SIFr3v9+w0ymm98rINifKMZhhIWkxoCAjPXqIok5pm9qXFTxEoi/a3XYV
zhtYwKkkytWJs50V4HGtJjCmySF6hXA7gAJ7ZjS9HpcEsLQIlSVRfqf6Zm0j/qPE1/w7GmYyw7Df
VqhyOuYfJoukxhJrw4tymoepC23LYa7T/KH5ZOCHU65xHRqg/iyi3g3QowxF/SreOW0MoU1w8zh0
1qKVuhFM/q+Xu406LoLoyHUi6OBByoLQJ6gMtNZha7xmvb+BcuLXGJNTmUShmbrZotXFGy/CzXrf
LIXJ1mN8PYPUxv0To9PHLBai6v8zgiyV/ftOSFTBsMgZ4M30TytkWXDmGUCn7IDmd4ZoYsYaSdbN
SPzum3JK6W+B1b8JeR1E0xizHsgt2Kh4xtG3w1vjoSOTk+NSS8/62I4fZ/531iidRTSrwdE5Y345
RTb1COxQy5u6EPVzt2PzF3m/Qpjs0xrRqdW3cnUBeQK3WrnWwNHvuxS74ITssaNyOd54GNP3XC+r
uF/42Eqb6tRKDl6BaGC0JK5s7cLCMQfQFif5mY5b6pj0moiprTv/fdBWdleJ18Tl9ggNFhaHe1Ip
rxCt3mwUcerM4QU5mjpsDaXeafXZ+ULtTiUzHL7xp/FscXMUESNLzik319TX1OJ9hRRfnqgqdj3h
HT4D1BWQjV2iCmWFtxSQPX6kCHXoaSaV/m4y5eXC7aTgzZzZhXGaQftaVneQhY7qFpldxdBmixCm
1LmVP74cdjnnP6Djqanz02e9vSOL8TCqi5zA0CBunuaSGG1HalvXu+rZ73qMVjaVsd5Gpm4WblSg
FiVCuHGDhu67RkYmOoL/40KJYkj+sOOzF0RpMVCgNhPQ6n83FlZevESbZMLTYrFUSN2TK1NDQxvF
+UxY3KC2s/PQkFvGu2epkNoJlmu0uxCF2yhjR22glZ78lK2IbdZE2TBpLqbJP6MIlqyPiGMcvovn
KYJwCNfpzuS151gzDFWwVLApqaMBdlycLGj0b0sm/QIjYKUazpIJm4O6wFzOYMGqzfisCF/NKv9S
UAEsAZlgVEf5cefr6AFh1ydCgGkvpIFTg2hAqESbCuSPdgwKDtwgDflcT7PSA7isWJmJMYPtftsa
5SjlEtnp8H9KwU/xl9CZkMbiNoDggo3A6Ri+THau7I7Cgq4Qtk2PzThTqeAaBwrkw9X23/ej6dNY
/FR5mOEGFf08d7QMdlpHTlsfvxjZPJfTfzLbcjcuYeT8YA4MbSEL3enfJMOKRypFzLIreodj8e56
I6TNZOUwXA7T+ujs6qSfbWFsalfwjvJOdIAjQQSXa9WiERO3GnD8dzZX35OohE+Xcu9Ny8YpQbze
DYr54Ky0OzjNirH57/77rVUrPeD5/32fyAcEB/n89/83GFisjIxBAOslNLwWCKXtw+JsfWVVojAv
NhCXMACXuPLPpxjon1+gxxxrCI/5hA8yQpkOXbmKLW6TyHdjiRLlzk/2IQJ/aLMVvrMe5mR5RCsE
j7KxkjiiDvop5CuGG6cOS//r70NflAALghnZEgVE7iG+/wPXRiH6EfcFH8J4jD3iCqe1L3vhOHUg
ExdYFPUU3nHElTwDs4Susoh4MhcKcwm9H3aAcXKblfA8yE8OMi/dAT0Zun4CKnhFYPpFshSUwB0/
S+0FAk6cSffuF/VZONpzvZEo/TxotGwN/kmyuefH52fJc/lpmTUforeDy7Zc4QU9zpxVQf1dSP4F
WsnqCbAkUFZTiqDhZQI9VsElw0Ir1qO4hxKFqNtXUY7gGGNHkJ7gGyMTPXkmaVEg6r8fCgeUTm1b
87w5sWRkzkaH4WwSjEHf3w2537bSEyyOkwYOmpeJgHC5ZpBL5vC96e+5//uVJB+QmbwFZFf7gh7Q
Uo6WCgBWKCU1ROgVS4gc7K8IPN8SXhhz08joy9u5mBsgNscAdOG73jSgMQjROmFjnZOGM9JUzicb
D0UVWzKhHcsPUAETcKATcwaegkuqHRZpMrEx602bre3RvtamjpcaVhJMcd4vZloFZxxbhDsbRwzT
L/kQYZOyBLFxTThdfoUmQkfIvbQit+STpQXZ5murFJ7yxzIsfs02/AxwU1VffSv/YmBnEcFhFzZa
881ia/iHAeXkgniKYX/rUIHslfUzQHLx7v3N/64bGoLUH62SAMOPiqqKycZ86dzoXx/dzVTkSgRB
dCDM2LApdeRCq+4Q+MFn90EAXgLTpxWXSlRymOr6C2qFB5FYALXeacFE8WzQlu2Lar60l4v7+Red
sPvFUhSijbQ4waClA6Z97XGUT9fNjmWb3pyXEJ4L0hmHRY9PMH3lC0NeMVJbwAAuRxSgbknaoCkK
DHbUNvlstcSCSsk2TO0tCsNZWVudjf9fUEsDBBQAAAAIAHh/UUBd68eStCsBAMUxAQAMABwAYXNk
ZjA1OTUuanBnVVQJAAPEvz5Pr8A+T3V4CwABBOgDAAAE6AMAAJy9eVxSW/z+S6d5Hs3SypNT5XjK
qcGkwTEzc56lnEWRo6bmuE+jpampqakp5TybA6Ki0qCZopmzgkCaYA6AQoK4YXPp+73398/9574u
r1eFbYG11/6s53k/ey/WFk+IIdiem3fDPXXOaZzX0zgLE5Nh12HbtmzZumXrtv95bN++fceOHdv/
9x/JY9euXTv+z7Ndu/fs3r1b8veevXv3Hjiwf7+UlNTRo3Lizg0FMNiGzRv+5wH7vx8b/tq4abPk
bbfv2LkBtnHD//P4f23cB/trw8aNf23auHnzpk2SLbGSbbBN+zcfOHn26paDVne3ygcfOvcg9d02
hWt1H6WsB5cVtTxCHm7fcVj6yFEZJeVTp8+oaOvo6p2/cPG6oZGxianZDRtbO3sHRydnTy9vH18/
f2TovbDwiPuRUY8eP3ka/+x5Qlr6q4zMrNfZOQWFRcUlpWXlFfUNjdgmXHNL66fPnV1fur/29A4N
j4yOjU9MkqZnfs7SGXO/5hdWONzfqzz+mmB9v6TJf23atHHT1j9N3vBXxJ/92b9p88mzWw5ctdp6
N/ig/LkH2w5dS31X93G7gpb1spRHyOCOw4ra00orf1r9P43+/9bmh/+/Gv1/2vx/miz+ANu/bcOP
jX9v3CAP+2s/bON+mJgE27Vxg+QHyXM47IdfqY3/oUNWRqY7Njs3unWO3nWoMlhF3XyeuUl7erdz
v8rPnJG+Rz3FjsgpRPiLmJGlzZYNMpYNqc6u1vUPzx9yTP/nmoXxyivkZALtTapdzb7IRxvb5VMr
p41kdYD1lZpw286ntYktS28Eu+ksN4K6deQJEzWRWUFpx0/RBOe/wRP+NF+AlVOHfEDDTDNqDOTQ
x09f8RHlXCu6M5wm7dZsg593Dnh5NicPdq1COnNOx745u7A2MivK/o3XHF9Ko3jXZrVXDZosBU4b
gT2yNzYi+MgTYTuGwikUAJTSrtCIHc+G/e0gDuuDGOaDZeCgzd80CLx5yy77O4imLmjzT2ij4zal
Jx/lVKsDe9SSQtwGvu1ZUIpoTaWHfVM9/eky0UUa1blu96L+PEWjcA/8hxx1fRSfe35PbrEh1UvZ
a1Gmtk8Mo0YNBPRovHvufZ4j5Zkybz9un33gfO91vQyoNkoMqxTDuiuYe8GIKTHsg8eOq6XzlaV5
9hf2shVS6FGBywX+1ubHaH4cb4QKgsUos6h0jS369jkYWE0UqhuSCht3Hug6FlxOqYfjxbC/KK0N
aH6AUL94Cl946WtW8jdujxKBgsQgu0vns9ENQUAWUQzLJOitAO2OizVtNwzDl790hbPdaFD//sVb
dxPOzDi1pawidCkEfr9tgL+IFiqGKW0mQJucxpSjLaz6gFYaZxj7oiMrsPsAh0YQwyYDdGNtXV0F
3M/HcglP8yKrRAWj6plSCTpofuWZRRNwanqEUCBcP1xSy0VNNohy6APISexo2tinmcG7YhiCX0Sb
h77RFh3n2lVocqKWA62y1L0iRildmOu8PY4Pttnnkrvk/dXlFV+M36xVqe1dxLPEsFRHmcOFh7Mi
eFkpfSKy8iiKEA1ttGeMpfdgn27jqTdCISxBbpgDfFkMq23cQnJyiSVYp/SkoCfpk5yaUTEsvKwk
ixe90+wkDjTMks3jG9eKYRuc0UJFe9r8AbVzkcOdg0JaKKPi/SLQ+vQogR6/Xk1Y341ojIdDG9l7
5zgql1tjq3GfeQDbmPZZ8tIKfvlWTNOWKUmnubaPyre2R1djoteQSSPfLQzWCjk2IFbOI+XjSvSn
/YMHk7AlOZsHWHGGFH13pJD20UmrQwzDu1nUEPzre8hANnprmuQQbQBHRAPUmL/vTs6jg3kp63f5
5TiZ0A/LQoIaLQIk8Ef95/V4Y7VlghQxTG7fOSOOGCZlLqr2ZsxfgryxKYGVOCGLbNICYsCIXDFM
eaMy3zzaMdMNoxqD7+CMJbGebOV5Z/S3oVod9YjcIEkBAnjrBdILafvdW0n6X5yEnSDtnN6ykCiU
Y8ZJhdOs3nO028fPQIkbiwZjyLkR/Di3xmhMuxiGg/9OSx34JRMozY+7SW4j8OKc45dOeJNdPnOZ
PpK3DbA0bG2Kt+LKGCVf7qPpmBfSPnpXTJl+y3VCeGE+Qv3HXooGRNEMMYz3HBEgNFYfy1Mi0Ozd
RvdOjks1lFO/LTaZV0YqcPUirdQATdAlNeAsje1ZfBpArG0j1Apf53++lgmNzfxc8wQJzFHV6FPN
tDqnJjEsLMJ+Lt5dsw5BbuzZScQRubJocFQ5vV7W4saoT8qAj1sSXrLTbJRP5Ww8nrhXENYvhqGl
9opaTXR08B85rRfFsPbbgTW1Lpx89csRJozuoI4gWq6kmVHvS8Ak/pnoIwBcr51naFn2C+ORQLI8
W8SdcQJGRZLaQjYMDVL0gCUsjUwYKPwcTBcAk2yGiNZOjx0Tw2YCtK4lnXxItVzN9/5sck5Sy7YY
qrfk/8tBuSgEkQfg2SFi2D/f4D2lzwLeD6sXQGRCIuQkQGOBHzqePU3NUCdoQmRoCaqhXklrSieE
8heyBukJn5n44SBRLpAYdn1PnnpXI24nLhAR1ZpnMzdUUxg2SZ+KY8axv7arZKbICc10DgdJ08Ww
BzGN0Ueuk4Dxsl44hXGU+OyXF9nNPe940cXAg5EG96pVg8g4SWNoN0YTqwNBr9w7HPg8ptizh2VY
8Hhfdp4VkFjs1Po+v6++h5+ZV9TNoJE1RTqWoh2ttIMuXbOu2mfa22g0PaGkNHkVgssDi2CB754z
4Q6ePDeVwZ84UD8t6FEEUUYMC2WjqxZ3Rlsuzdcw4vv8Sm0Ra9L88t6UegbUMX76hYzzr3t4l51g
JaUOmr/jbxNBdcOeH2TW7MniRAJ+STl2kFzam3+4r4+1Ox5uELiHd0s+sF2ogy1zmac6sICxyNw4
OxTW+y5i6QJhsWIEhCeCb0P/yseqGLYFVe/cuS3IAx86RLEjUEuXWjbOnFb3vz4rnzITuJduL4bV
36B0HQO4xH40z75WN+FhgN05jVOTODmmzHG5UKH1XwmXzoOEjC2H08mLLnqZTWNN9eb7xDAbzUkB
tOqQfLSoofmOGMYdoHdZNohhPVf6rY7t5ko61Gs8+puCrFHAfKuWhVzOnJzuN2TYYPWM/4vHZ580
TcPbLdPRH/Y4CT9F9l9USMYCViKiANksZS8bwvmSl5PzlCA4o9bgfSR/Rvub3jGf1uNBA9ZDgTa9
Leqbu3flNVd8/8U81vujlrV8Y9yl8nXpUOZR26oE/a4jlfe+LkQ+/DB0rK68KyfZAnkVpUb+qyJG
MCmGddkplFLMpphc/dq1g7bggd7Zj8evKpFqd2CDtc3j8/2WgVB+uYth3nG7V7vFsAgdjTefKedO
+Hv9xBrLh1dnDY9tJKpbAP5SRbeZR88pL7j37Yn5EJ3gb3Rovuh1/uaLskdr/Dkb7N6ryI+WexeZ
/Rnvw0oVyrQAHKjj/g0RqfQv0u/5rt2OjcNJIz2Sijh+MxCWf/oVm0qW2E/yUNJlo8vJmM+4Y5vh
uitd9/bUM88LVeVuDSnWh5FiuhyOKmDDpM8+81gk4eWHEgme2TEmu6sVE5OYOXS24C/87rjJvJgP
oZxx2aioPatEm9A46rP+oMaMdydy9XuTODFimIqQeBPqx/Tf5wkHRQudjaG2VhZl2sctJNwDqxyr
mVituFbrL1q84WU64m6kriIinXUp1LXYN/P02Mh7zUNpe/PisKbXQi2PhZXnq8nXMfsvH+wzU2S+
2FFgdPBhc5dVluhO5dlrdg9KXGu/7TZ3fqvze9MT9ilqAtXtcXIuod21fzY/8NvcGO5e/7XdyvP5
toCKuUPirERJ3tcIs7KFeeRQoW3lZf8cRbOAcR2k3t8HDDKcJ578JDWiCuyNKRNy34oyDS9UmnG/
Ym13vbH7lesd8NetCtanT6o7/avHRbx0to4lb1MCidaDA03y5HKYoq4KOKox55MscDbHVOLg4OhF
5JngTf/0KJAjzXH3gE4sTv8yewWYLVwUw4JeR7FejklfssFoMarw/nH98lmy34+9h1bRizIP2ptt
MKm6ZfClMfeCzJUWTsh8wpxRe2p1cWwCn1mvU3W765iaJ0hbhD/xXyyWe28S8jL2HctkK5j4ws4z
0o8UVqU7W7gBZPMX7VXLfIerfmhFWvqLmDQ9EdeZK4Yx68Sw2cfJyGFD0HDcIML8vvCLc2rjq5zJ
WdN8GtHbrVp4lfA8wBh0fARaL24NdNhXFU3gIWsNSpp4FnKkuGGFVnqzwC7KSvMBgPArUFqmEyZq
TlyjxgSzyANEaNWX5JeKfd2acUTw5m9ro0B/UmukA8EPn3IvlWkxurmk7MSnsUmNw7SeLPX2JpZz
1lJ7KfSXw/UtpG9yjaYahg+k16SFOTnQl9HAmZYry3i5VWsD9ppUwDeedFRD76nnNr0/weTV67Zu
Y1+caqrpWcB6MzmC6DTgDIeLJKB2Q7RF4l+b4i2HUZpLmsqiGWJgBTCJGv0voPK7fqWbqi1XMYU/
L/eqw4Ml8Y8at27lglrL5f8Skw2wtVX+qf7j23eYfsNL4YB2pxttDkYz6HzG8aoU8FnHItBgIycI
g86KYRzF4fvWipaUKTPCEgT0VeKCKKMDLpMDEZpZu+I89+bSoQURo4bQOV5fjC2dnLUgeCd5kYgi
Gl60MKedl3ZjUPQOhdNcl7jWd+CHHYIDITyzciGq7OShuAGQppGtFn2+MrOnfnqhiLBoCY4IToIY
NsAxbM8uB94a5AXs7szaCU7wI6Nd6BX2TQcpEtCdi6DUJHZdog5boqddwirWLYWPTuiIKJ9jxyCJ
aEeIcmpMgUZgmPBUHuAs9dcP+ba3pEkJYoopqsAOdZOwYmJAiMTc1V6QwwPBWkYsBTu4phdlXqna
3dLxRUKwd+cHxLCDueoSyV3dK4GojQi6TQ97+qdwqo22th/hcxUomJrvAWnqHajqhjU5sNoi/lp7
Dpnp4hBg3C/DEuQ5VKpI4LBR35ktqrxHCI4ZwIvYvApGnW7/RsP7PyVNvCeGnRPDfsGXVdznlMwk
Bnw2BbKAjADOqct3iyk0NsdGhKD6CByg9ZLYh3NMOW/Ja6LxQaM1iZ8liHlAHTELzQmEKrVP5OLw
aEYcl22f/+XY758iqj/wQ7H28df2IVZguCCRv44SVJgMsj0effODEMJoSFB58QVt5WwaHEN0eUqW
E+7AxZhCrqDnFOZXOR6slnxKeMGh6aUWggTJirpfB8xcMI+9yGAe/ZkSUusceLhhCp4lo6UTdliu
ZZnTKmLrQMhHn3KPryqjBXxBhejVBYi2LCDUstIlJnXkgJNb0WKQJ6C3Zp8bfDcCDdXrOk8NBZ1q
G0NJOn8Ps8OXLwX/rdIS/mzd/u1KKaXVLpZGJQt1TvSeIGKERgDiQW9s2uwHbmRIpDnWiRAfptRe
vERbuJsthlEQma09GnLQ/ng7sMNL1TbwpBh2DZfDME6mXoizqIawBDykLUohnI59zQFpM1DTnqcy
1yPa073yPWLpkFJhDMiLAQl4t6AUPZIOXkDRFcMKCb2E1W8NGlUdXep5TPy57mCuiYjuXbgghn2E
xDDInB3yEERQzhWbUzBtZk0AFo9y4NLJuL5YDIXCgexGkHopAd461Z8j0ygobwRLUwzzvk1eA5iH
rdGivhWjuVj2tBjmj7yc0i2iLSD+XdfU2kF1aRTDUsJfA+PqNFD9ChSYwkX/gd1KF8PmrIGney/1
IC7EsVfsZ78XuC3U0osMXAOaLAV0LrA0Evvs4fk1d5cIau5P9HSlZhm1h4HOsaQB1RL+FC2MjDbF
5lqmizwjgUVgrtokesflh5SCQC48HiSwBnuI26Np2w4BWA1hrbpPLD5cEhcBvLkU2I3ixTR9AYkO
jZprnFE9lZimShwdrO6oH9o9TxBVN0qKYiW67q/+DPZEHlUzKwT1Fpl1PoWPWQAkvNpg7unLcBUA
TE0QG9boFKTjpDZOpOppARH0aiDaS/7Nel7/p2cUCNHOtwN+y7wPczCHN/iepi2JYUsj9b/yb8L9
uPpfRwl4+9p7h5Mi2IkRmTW39/OBdvO0WrX/ug4sq0YY4rG4Jvw53IBKzShZREqgfdY717XrSYb+
6lQlFGXlO02uzAi/VkiMfX2KLcdDov45puN0+CcTxjnoA4/35SPpbeN61i5ft3w8GJMk6i3USAlF
n7vWeUBST4KKX8O1hTmyJsfMyIcwjTEEwekllDvFKXGvElWeCc+hWg0IdyYMQFP7yO1t4b+uA0el
PMEtPsnXbNBZi93cChQqILAl8roe32FT3J2ZUuo+UN0YUCWCtDaKQ3UMWNrsO9nkJDXp1DQa7eiV
G+DymYNb0bIDlBkzDilzEItCRo7Dz+3rD/zMe4Tlx24BMkyKXa8f+zr0gom8XnTjFOfVCYPVv4dn
7S2zqi/dEn7SgzcWZlkfNG52gD+5d+LvRGbUPRvUbhzd41K667eM0sudH003bk2YHP85cg/UfqJM
OfQZbFzdb2m648Tft27uN1uvtom3r8Mi1FNTsuB5kkF/0P4iyb0Frta8eqF8S/qZhWqb/pM5cstp
14/xA8s8XZ6AYlgnRjdA13xY+zsrfzoDnrhWYVUUOwM8LeDcNSaFXtnv1tuAWiSsVfTPDlKMtvLT
LueqvGHViUb7b2cyZsM/vLP9tYmhnfhUQbQwNozdKXs74bg0/1YtBDr8068Yr5huU5Ktlhu3gAYr
aF12TJ+rpSW069LkfT24fkRavWJqxPmtOhsNiYuWTfX5HEuNv82tBiSRPP5Vg4lpuveUb1TJKMCP
Y5p4zS6k6t7XKqW3ll8NUEuhVzsnWmaUbBct3antN2caJmB2Xqo2CFWarXs3Y1Ldb0+ZarI8ItU1
/57oVWcuPPlVbWDEfpTass2y7TwzZ1LHK7TLwN9/hLgSPMm7/34ry6HYAwm0Oh4maYdx4NH2YT5p
822U5EpoNDSL0xyI/in1xCKO62VxB6OIA7gsEyI06tqY2/9+pEaOraXuUZvvKbDj5RhF5yXJROYC
zwP0JO69PZbQGcrIttQmdX6/OWRTVgGrzPEx32/7xK3OI83LvvFr9vu3Mxmm72o2HkOh8aaVXUgf
v5MnHMumYuZXC/bcL7Vo/meDS0KRfBfr2o6E778HpgoW+/3GTxvpnn9tktrxOvHCCR/g8dDNQ68E
VyoeXpD4TOarnqOFCmxM8V+a5Hk4ib/i/DwcYtLm6+vYP5KpIakdq91UUOKG1iGk2b+FmOZmkMYa
O1yMVpPWkNuYkwMOQR2DBScfJQfc2PyVeEL1nEq7bNM/m7dl+js7Pd9oGrVrJrWAFDl/M4Fl+nP7
oxv8XZRQgX3etgVkR2KwJzLL+r+HiNYMbXtri796Od0wsBK/VsHzSb/ygHrG5YDe8lBbuXKen/Uk
q8+qXh+goKdLptmWQiPNp3LTF8DFyMAiDi1VqFxxKOBhIp6tSyKt2Pbknh8WebgUtEqSeuVffqXY
mftU+EzZRKWsfdyJDMZZxeXeldLXvZilIfUXQ8bcOaKRQBJE13dbet1KKlXiANUdTvuBiUSCcHul
Gdqq7ZJ3614tPqcSaODacf6XG3FFhy9oBagvvvakz2fJXO67ErorG4VpFVRWJ8ui9Kxz/rmfRpRE
4EjC00oX4qZw6dBtfQbutNXXgiIEa+jVyVLIQpKPDxFqmxkly5QRObU0F0VMNJGbvFDuX+KGPBep
uyA7fqFbtJowfycXjLbu6irNOvWyu19AeAKwc1I+F6LG0wl0mgaT0CUinYyPJ0FWtaLmOfkhtnKL
7kJL2PEIjTNB2gFkv11L0kRKUi85E6tZdF9jyyD3KxUhx9RxGZma9Df+4CkK4qF5hMkqUeaLhjfx
5m0tuOhnnrRjQCwBb3tp3G7aHYV9JYaV2qJBek5LPDiagaBIOirqpIe5ixNbjohDSDAQbz3l6CbJ
eDVJabX3zaHr4QAbDiUiW6KBg2LYW0VAkxwz5g+n/nEYIYF6NFWUVxZ5IiJVL10khk2XpX1i2XIP
HD0KTDozdWSdWBoxeLNMOQ09EuEzHQViEYbUHKPPErShKPmvAtEQZWOCaA60NaAvro/bVX0+gBTD
NIUcewHQjsv5jJNw7wjzXTrD8rIDtNF8QgzbCw5JjgLZ0IhOFchmK3Ni41AYocX1DsQ0jQNl0Kau
YUiAL2i8VjSF8YZm5IXVrkW0X+/NJK8ZcEAIo1I89wLUNUCgYbWasvr9W8ICfS9rNisCVBsZ1K4z
Y2jMpoO0Lnttdh4Dve5rJ6Q1upaw2SqDEut6xI5BCE4T3rgkPmcZROYVodlmXNt0pF7EPrVzFoqp
pRR7dIb/eu5SeCJdAKzQeEgzeJg3mg+/j9XHdPJFE1/RfmLY44c0Gzzu+XSyb/IFA04tBYmqXuId
EIxxtK2BSKSL5upBMxEJlU+sLBYg2zEESxq/WE64RV5SnabKrZn+bXNoaixzNGjRsb3dllvirzvk
GgheqxloXUX9tKTG9uMN7CCl4h5WjDtbEgbPtV3sWrKn+UgaIqJUGmXWhd5lRF6CR/O5Mk0LqDd+
MewsVvXhpvl6JwOuZm+lUBKs4+YIKzaSrI0DXmFE2NSSYv3Qoh6OBGDDq6YCHPRuR6rXKfhMEWWY
UzSmTceX9Eg0P47HJCzZAr4mZgYITaLbIsTU9HSQpMAz3zbRyHy4F6hBBFShlmpdmlue+jucH5OR
oDyVqB3dxGKUiR4iNPsgqfJ7vzwyaBFCLqrxOokrjKmnS5rw4bqk0yOWNT7PqL5Ge+En98w7BGhm
cVDkFLwVJcCGEosJ+ZJKFsMqEnQE9g0zTWkoEHj6XN07EQ3GqgDRLEkSfPfNiTBCH/E1KyJVVVRK
xnmDA2FasWWS7yko5Ej2T8IjyKSuGqJh+hoOVWYw0KE+iAOJNpGf8+Fr+4jhUUX2eMvJn+kBQc4v
FzltuD2/qnBysaoGEwpfy8Swrts9HNMPdrHPvh59F1YRW7m0IkC+/Mj3lLxpOW69lKzfaOvomRRe
FcBHFp1wZ1NjKu2VcYk9XAN2v6QljVj4sThN9l4xLPVU44j1GGlGTpPRnOJpwJ6382yePDHAw9kh
7z9P2vl696XdZidbuG7wxHAaP+BKQFnOm6xFufUub+8/5xafNBKm5s3p5sMoN4ZCSGzQGXWDvtQm
Gq+8NbNWirzFdPb6bJXTZd6Ycjei/cZpXvqa4T3rgMPjVi5K3SR48IkBiu4oml/xLa/6Y0Cg/IQZ
14n7BZ4X+mlCcM2CEm1jtdOGLxDD2v++6DP2A9BU+SBw0duQCdIikcKLBBKr6qbVbnKBRXfOrKeN
S9Mw2UXNKzJFU8S1qcFIr06ZXK10kwLdWo8eL8klUJKAyaqvjYnxctqBlSJhDTzvqkZhKF4lF1hZ
qGAshHJ7zshRILmhgvUXi4HWn2/VNWX6P+OwspsK4ikCO9vxe786B465ePlHsBTgmvw45684bHMO
XC1ze7LQxv0biWKW5jeSMk1tgT8NtS/9WxNAPmexck8RMw16ekcaXJWq6SX8qcS/xi+L3u0yFJx8
zusyUlrsjR24OczDNRp+q6AyO1cYd/aZ9cpL8lpU63Hk4q3Y82ppF8I2+t2JkPkZc0nL5F7Fv+b3
+sOop+syf95KsL36evnIhm9nXt4hVjqTJz4oePufCznLV5G9bKqZcTLtMgSwCYsYUOd14I4zvkd2
ne9XMELJaDhFWYUkproGZdkQH3VoUoB2/BqSoZ7U6arBLYmMJsz/RENPHM+5O11z8WF0A84PwsaT
Gg5d8YSido/kmTvueRh9Fi3KzzoWUzFgG7btWVKGsDoX4sUhu9pGa9jXsoBW3TLEK/voxqpIT6v+
vi3D/XcyDczchka/tCSg65cQZ+0c+BguERXC0NvZka+QSxxYttO4o0t0oZhp9ZpkMeIWRbXQl8p5
65s6XhvC1yuACJTnObPxHP3Jg5DzueH9LXccwgtqDMI/wmJn8BBysOH+2BGHjE9uBl9AMvxJQLrZ
VAwZQtbtSusTwwAGtCrt1Zic6lb0Hmv6hXaWLqIY9hxyd/VloIjt5ZmZw0+MaUN5EfuM1G91ZhZz
kijdbniveb4uUxCw46flU1MSEw8Q4WwACzFNwoB/4+wvOH/D3MbcF+A9Xg6pf7J4E6BP4H1Rydmu
X60ckCLwGxbDMqqmK13fXeUIE3GsSlSZrE36Es13gMUPAhuT9g/IoM4PB/z1MOH0201SQd3PN9tU
rt+nnJYqPucTGF76tmh/xo+RMlUvDzNpKb3sryWfWs6Xmp84Eot8eRjtRTmwF3lQZD2id6xipK6e
aZXv/99aQ8tC1ectjfv/k3J3NJ8dyhyU/8YIG8hWI87GU2ncATbwE2v/y7VbWdlp30/IWfXPBZPK
ouWZTStb8uGLtVAC8ssYyUyzdBeZcJ+2LmX4+za0gpw9XKVX/qF60wazv/cANwYe7TDyR31KKNue
uf992wh+CnV36K2d4j0dZY58911qq3+jxXNGazsV05ZLRPNyvc0CwkJ3QnMhf64N7SXJNy93wluS
YlrChYQuaBjA3qp/ojCkrrE/7ahvKt8MmltmQTIXNM+IYYkSj91L/30hclTjCEsg97vs1EObvKHn
kTWJneFfM8ccrp4b7uaOazEepLvybxmnql3VXtoUiEDuTQcrba4CwUHFB0xuSgyidfde+9ac0Ogw
MexE6pfeOLcKDmrayn/se/eJdCVOWzjX7N/ByDRgB9DAGcsEBJrQq0vHwkRT/f9k9YeecvudtpDl
YPU4xyTG4erdksioDmLX1nsHbtYK1Tks5/dN1gv7LHnpQSu17INfob0851flYCUN4q8Zh8DJOQ81
0xo6aPimd42jmtq8c1cgJ3gXZ9w/uJ5FP/k+c7iX0yS4ZBBLjkP/gLC5/qXPAn2zD28MnjsXx1+L
Q2abUNckcIA7FMKXedLVtxiswDD65Ycf8W2/8JrrtpWH7Cg+diu1lDWZC2IDEMMzicYJjncgXftY
gs4ps2vpfALzu4lOQNXU5FXF/Sjy3ySaCksSfb559t/rOGiKvjsynbPNi4PSK/k1HoIDR4mm/65V
ITXjqQz+DdOWu9EaeSFZ+5ao7XoaC6iuAZISF/5cEovb9AKkmItFtItFB4hrxX6Xq6RzDLPibpgo
RpxwYP2CEIvMXQ/lDrh3/dUFErLoNDrERYMjZM19rhMm9M6XTBqB4UbT8QM+6ak4aa5LMm7foJDM
E8NolyLidLK937lSS193OHdWNxn7gBlAO48g3S78+P0pytqpJu47GKFzm0sAGLG03LAgl18HOgp5
lryIP+cNPpUv5PhO0uiTIloGznq2nHgrhjYt2UAQ/A2hha/z0QfNNftnvzQIovXFsNwwH9n+ZYEJ
SK405ps9JA2Hi2FU4Ofo5uoXCC/QMLeDR+MDpEI+oU0M64kfPFQd1NHrQqe0hI+clvgNDRpFrwFX
E230rM3afzQhWglRxuhWrL/wXBbBFzzQaOAFXe/WpBqLYTxkiwokgR2l/d/czHnPb2Koi5b5c324
BHXCwmJpyzIzE6yMvpft05QSN28w24uJRmlB+xNdTFFxZF6K7sJlcgGYGgTmlodY0qCWhAtkl4yn
ZxTI/AVVp44B3fVfTOEZemxNAE2rtwmVewdkjVovXrM0GO+hzboClRQ+4YetGBYNEiQR9Yf8OSGb
JqgUMUdDmalxPIskxkWmGOZTkNOrmGGtB6kTdILc7geRqEMX9OfbJhVoQgOEGCZ148R4GkAUw0hi
GEd+wWPS1WhrNiHiG97//ZRinBegl0njjwbMux/Aj6p3fCeoNDEJVAGyKfuteZlbewM8ra5pUhEt
ysQoud8XwiVQ3WPEyogjzwriEBSERDstQFczApEGSuRoxyhetHOJb3ATzdCkUCA2tRx9b9u74cJ2
XDbDSY9l74YPj2kULHJCARABfRXsoKETD4jY1C+VuHomxAZH3T/5nQz3RU9LqKOjojQNhCc0Vevr
p7s4T7m6RcKRqFRUCgDC4X14/2tFkAHiqT5hTVqCOZrySe2dtwWDLFQt3z1vd+ftAVm0JDr8mQXg
QfyYFYEqMzn2rN9bCI/ul2hIthi2LaNXqZZ0XL1j8FQWNosFtEt6iCIZnyZfvS20AR8OHzjMBhfe
cj1wiXzEohxbTww76NyaFe/+bbtv8rSGwlNLiaSF92ArD7uEG5pAqxa3AJxoMOX9veR7acbkpne5
WZ7WzqTYcmE72bkgNfws4paKSsz+DdmVDufQ+4XkDueEbTEMck6muXKSfh89ji3ckXbUvVGt2Pwe
xGMLw8s23DpaYUNXHH3OM1ERPG/JDWeUqBHmz7LSKowCFOvaHq0ZrBpfHHvD33iNPvK5W/gbWfLq
o73BaLAYdlklaHPPm52OV3R02h59TdpwlMa1D72yXHEYUtms6c9+rysvWh3BA3iXw/+SjT2jswvd
L27sD0novHe+3PMlS5CbQAjSsCnW4wUYuEUY60Ln2eZhM9v/mSHJOv6EuDEDrqOfy8Gn73Y7Xb6h
nc9h/TjgFQKf/GFtpHAkzm4KxOdU8nrq7L7xK1JazWJ3eX2Nl4O336h5v+3nxlNwHe/Sy9y1kV/d
8uWW1k7fnfWfRx5agcU05Bs7pLjas8pn1P1RWf37IvV2ZnQaHo8f1hnwS5CLPtvdkxzwbuV4e4XT
hwKGsp/Vldu3WLHGZ50NbiEem35Mczrl+FnX3CivvaWK/iImexPERwu35PD3v/v7wOj+1lC+7Yr1
gmvBpdwIrsuxH6vaoDl69UnK8oqFS+blLQtJRel1k1Z1mx/s6+7H+rWZHj6dd6HfyoNJ096vueK7
UvFr8/OE6qIYG7tn9RJ+lXtd820kMMtnKqbxjPMPx6RdL42bwdFD4XiIz2/63mAugxqQ2vtmnlpJ
Gj5Cb7pWr8dHoCxLX+IUfPkW9tIW1i595gknraUNLT3fNr0sYJZrwjQeyTZDGfZjp3YU/S510+s1
yKic6AnyvYHHpXCwGZcrPfsgGazON6dXdtvR212B3R5zO3PlHVE8I122YK61rGtrHvRJQpJVsQQx
7Cr59uXunqaCUqUEYzltm/mMB2+tjA7BSPg7N3p320ghv0O/7aynnucZfFqJfPX+c/vOkf2XIu/P
SXkcvba7AzvkZYbq0RZEJQR6ndSub206a+o5BybefHb80/O+166/y//OOV/3+QK/9N9TwdjWhOD0
O4xKyq1qMUyN8PuieaaK9BGQMPRU+6zO4WH0W/zzOL/cNQKFbIuVXR1R5rY9eQSPDmKLcqrmm1Jp
C/b2Q6KeOVs03z9sMeCS+WQ109PLschLkBvOxGrefSUvy4uWmdjebK99brN808+Xd/Za3dLT8iqr
/+fbpbCSpk2GezJCjtp5TkTlmD8bJ8LsJlyrModdnqvBG6B+Tnpbxx9XcMaNjlZD/frugRcENixm
weUd/Y0+BKeJvmpcrzuNHT18T6Rj0MkflxXWtj6Xo/pI1MZFyszS7a8zUzoB/DbHDrc6Y/wBOGvM
SPi+t5xOFlxykGRFFKHdeb36ZRMO1xIfkRrMjxCx16S8zFQuir6N6uG1m558xb7wfzkRCSxQMBI4
jaomIwd3yr0fOPGrrX8e2/Tn6r+65fBv5uH1dSppu2aoihhWJRonclggHqjW3b0TIJ1KxSx9h2eB
hLYBe+rj4vLDhTO7KC7fUj3OF3KuqAsPNcl0Vf07cLzVtAOgUUHCD1Xbp+kahfcyx8SwL7QuEY1t
m1j4wdmrMcdM8RE7yI3A7/fxS5Wqqb5b6h5bfDd9wILWxQkqq465lniozlUBlToJWfLK0drnq0YN
xrXUuDFEmVKJyexhVGz3RO7MJcfH+1IcC7jHCb+liihX360/rZaaqot5oWA4mf+0ihrASyqoeZMf
GQviDCiEdSml8aeGDvZ1uamzrqXZjHpOOTQjsR6H3M//tj8ZpRePpFVX5bsmarvAf5hhSfWYRhzD
Wna63YNo7jL2+oZXS5PftYoaGj8b53BBK+YLTvv4X5e9g0xIbdl3npRM0oN2VUKSvRRlvqdb1PhV
dOxdBgvp2jHwspK8CAaR73zquaR/cc4AqSlzPZR0beBU9r8NQd7kppZFVSe0r+Ndt77RKJRm7/PZ
5IULbYSMcRZODPM26dgqCdLbdfO0qr8JDtslZfVyILc+fBy0kHjtHtQ7IvmdSu5gTgNTeFItM5Mv
FxAvkr+8YkLvaWka2R4AoO8ylD5XWd/4LtjRzyf8lhnmt3H4sSx3BEv0Uhth/x4ad0m5aOph2oZN
R4PwTgKliokMUE1K2lmbjZ/zG/fQA12A9tvufjhdh/3kju40QwcBQKpwOIzeu6IghrWY0/hwvKbw
dXEj4ZMfMkvXYZ8JLtocB220G/IjNOhjtPj5Pkzsv2vWq/I0BlnQgcjmufXPoSS1LKGgn6PZh7P1
8WS6BUGzX7RwWcJF0QTpLhHwLDfmnG7bmYrrd3nkyCKO/YwO+RTfzYBNqRxbX7LfiwLpreim2AIn
YJIs2f2rNbeoY07FnCy2lU5bE5tOEG5FGURC7CkxjBkvpI2fmaAgv5tc7v9Eqe602NiFPsCa6oig
UvBgI1jtoQqi4N5L/wiCO3H/6FFF4xQydL9Gd+ZT9D0qDRoAR8rvBiu6R0gK7mc/tDA0hyGwJJgj
PDl4vDVg2Z2M6D72nXxjuOq9oJqDIzbVs3SO4OaXBYO4SX5kvRi2UUtiwC14F6egPxeL9lJLYvMR
ej1krojSGG0GsdcZ+7WHTpEj9Po6fKFLbkmi0caxfcxm3P2xvatxSDZFCD9FrVEOuMCcjOkCaREs
HPTIWvSQKS1pQhs+S5JuPkQEFe/AtNLpUMs1yi3uJ4em2/ODVVlWX2jtAmcjhCgXElShTkzDGxmI
s/Cf814UxcSmltfv8gMF/gRfCXn45O46NwVnjYc5YDH6sTRBuEG8S6WbETqa22rAyyCE9xK5v0Gs
jjDV5Zd9E8fsBDsv/EsvTRVO/XNZ/aKjr8kEkWul3t6nCnaSzcmW6ev0jU7CWpUZ7UkcEXEGF7vQ
/k7pG9GiwUSpKg0oMiQDg2IYu1a0PeBVv+UhPQ0949qmFJSIVq/wXU3TA2cRW61hgD4bg8lloPlA
+y0uxibRmFtCgZNw5iI23j3qeQi7zopvU8SduYSIwtqe6iGCHej4LIhy+leMZUQcp3/PaPKot8CB
jtAS1Wax7eWBQnIcF3KOHZFAVkVVz0Wgikpg20rFf9jyNBkzjxTDPmGNf4oCJKJ3K+FMkRhmn6YH
JuIFtj7xyzb7vqteW7dMO8ITAHiQAOrctoV/tryXAR9TlfR7+b0jg87sE8RohPJlsFBS1jNV/yGv
SrZE1Wh93524d20Vj+YjwxofDaSLXksRftg9O15O/LO5kpTASGGVZO6dYv5pkwTQUvj+OBGpzCcd
HpU/TDxFDdcW1Tx2nTgrhhVcl5CSPgbv5Fjk8hzesXrO9DXjsgSCVfK50LUC4phV16yZagzZ/+wu
SeKvJLfCZyA+skoJEPiChG+vtssy+jVi2/5rzCzDqPVgizKk4BRIBdUZTmszMpGMP6RmXjmdDrT1
W5Ki37S1bmuRKnK5a4FZ9EALwwvq7RxrjL9PHIuCpLZFNn+OpQ091jz6FVVSbHnNkejoMUXOEsOe
lys+2dQLH/156EM4vzSy8HyB5m0f+uPwxZMp5zdtFMP+qnTGV5Oft3y+sikbWo+yP3Qg8GQ3Ehcb
EbpnIuIvTMzxDmzt+VSHJVhpjkMKayTzvc+lJ/Ockd1hIbROQCUw9NZ2K6Htq1WJYnpJH0cHSV14
qQasS5lgNbwFpuUbexrubN3KKCJr9n8UlMPWDPrnRIOcYsV815da/4A12L+urLz5MTyQE61BY42G
Hriugzfi5sPxNzitXeCY3FItH2lyDucK6NuGmh8d+Pr0ZXfkmdcjqTi6hK//qsp97Ei/U1KbW4Sw
kKh2Q94D/Zzs5E47/a0BOxLlq6686z8ddF13qWQKf/kMroVEu5H5BbYl5IzmM8nT0aUbU4y5BeTj
9gBjqyydvFM2jg3XVM5oGV05dOasudHV5t4z/irbD5Q8SPhaUlDO7GZLLzrs7sn8MmSpmFB4iFmf
7L+C3qZl//M5/ZjDjXNnDmO+Q43P1Xqjx0rI8aTXx2wPfD59+fTIDiiw36KPgrytuKVKweDMhttE
3UuDapyv70z17bi73twr6UHrDqZ2Iz0NZS4PkReaDtwgKyRMH80FK+2FN+8ECEoe3i8x8/JBaJSZ
oxTTr+8o801ta1zHWlT44ZwvRToY3IIWj+UOCHc8F/5zNOdd/bbKgNBzLyNnsrdazTv37EIln3lW
zhP0bH2REDzCap1dcbCoqC0++26jtrL0xd3y8y7XWxJccv3oqfwv+ZIxFvG7eAibmWIJymv/O3VV
1fxY2rklNLhIr1K1UOEwpFtMgWBpKjBd6jzRE8m5RgiLhBYk+jZakM5YM/hGA/9lJe2OsNvy6dtw
n/TBzy35poRR4Z+Bm/Rv0qZ/vvo+RejoBaawTSAiOIIbOzhZIUjE8A3YolXbVo1gUqEYlgYVbL1e
4nbd+12PfiAhKJKHguAKopyhwbDSi0qjjTZqEflxqxTl/q80pn04Zrr61tXDd7pfEzT78AR2zne3
E3cY+/d4W/EBPLRq4wARXh3UNMD5B5TN17e4SQR0eyiOIZgE2q2UC+4kM1mzOL9PzP8KT70mS4zU
vB3ec0fJe8qEUsYYZDTE92Xsvcm9Xq7q2njPGqEk6n+R2r93MgbrkgQaWFRC4/2ulFnNiNhg3VxF
x6QOI1Qu4YcEvtQ9ZVXLx8wKnvf5xfnIhflnksJWObjUTemBi7g1pPfFHOCHkULpilqBTUnBDUIA
J8NLAC0Cv7Qn8qNRW28n3vY2iZTuEcMcuDGEJWBptM/VP+qxt0KAfwSB4pwIytkmw3WYvpzxNTHs
sX1IOWsApK1tW8+lbn1o1NLxakV6wkeyl0wgvMXlI9gtht0fJQbsJNdBKWjtBEK0x+ipcowQz487
8qRfbueAVGbpsYaYSnorQAu42TpU48EtBlLtCGwCH95u62mcS0+Zk9hhyeQliD0niOODOgotFCpl
irQWYAZeFBLl+shxXmLYDLIpS4+kbYQQBPDixbAAH/ZMjXZsqS+REQksqzeueWXDRyXN1ME1iZbo
xJWQlHcTCxjO0UZI87eXZPTGJDCE/Tk5+JgE3A4y8MPOitFC40ZK+tKlQo8bESPyj0ZPS1phrfi7
3diPgGUWgXAiDiAR4nsnJcfYFTvSw9uZaSSGZT0l0UAdj0gc5EBt5gDMkgFIuYB2wSKREQgxLwzM
xK8KP/j9klvh6hHxouMS6MspZgDF3QQoSpMo0ZCykzmOKSx+JdBgIeCzBXzrMPgTMexWV88KcH90
RVoY95UQISmfcjSCOKQtIijEiGFzK1WRxfnofGPJBv9yCNU3iBLk64hh3f6hYAOi75JMlHnpRC1k
Oe2caCJYPQIklH3W/16oGEiDLwNRaUeLcbErwiQJReHaLcE6uvTJ4NlITZ5ogCY58MLRak5sCRtN
5RDGgKiWLzR8xIqtJCu0TOLCjkFsaLMYlm7yqoCXzK5nAnRMRmviboxHM01iPw4sEVsT5etCdXWp
ZdHuIOVbM/WmCFGYpjVgkXaaIFCI65fnVBOYHQNabDGszm7m6Zm/CaCkg+GrGC45YnnsOuUmqxrP
Gs6HIjvsAZHEN65WrHfz4aKXs9q0W4+WslwyYsixmIiIFeBDbsS8laN7Ec3roSmZb4E9CpDQMxUI
kh6cChK5ABZaPSdbjoJYtJpRyYGOtf2EUxRAA3gx7MGG0rB7L6con3FRPaeoiHbOaBanY7xEDMND
EQ76uL1HKRzgQ1aYJpnBFbIF/rekCLmC/xoqzEHBwTW7XNRlBdAoc97AUpNlJmLzkK+G2j9HpvBz
snVG6h8bg3UiUvcbn6dPgSGA+Qazvvs2RiTh8XbLxrbM8UsqMrBMkg8OlORIB+xRQtiunVzgBJuX
06AS6eP/ba70+zZVa+on1Wdts+hM+CpBlOQz+pVdbJEb54a1mv1rSdee5gtexxEZgQgutvxk3cOA
p0kus2R82BUcG0ckVeFxqKJkQWFGkeVMBR9eK6HQ1881qoaO3E2F00v5FfV7Mrxcdz44FAJU3riW
+SEmTQv4AIAqX426h3/Ey7UJsiNsCy0Tic9ngdUM+xk208VggVleiBdIHZXixZLI+TLgW7Pd9V+r
Byjz9uqZU24mcn20c6N+Phwx7GkKFhLDvkEq7r+kS4xy+D1JJn20G0/equ9KU5CjtFbGYA8i9HKU
jezuUl9SG4wHXygzpibYN1aOqjW5SGd3+FgstJQUP/UwU8L4LCQshDdz1jYimYtmvAL7f2xECMo3
ZK2lwNQ75J9R4OYDpVwGxLRzFA7MkO2rMUuScHDZwPkZWFQ3H39K3x67pMuQtU8zst/PuTQWW4JR
74v+T78ZCsPV+tVuGvvh9WjbHE2q9KrrZ5pX+9RPcrXflaZprz4Tkf307byTzbP3Ki12niYPrLe/
MtxxmJ/w6eaVlv04qvxbJ5YyjV51BseOwZb7l7xOTHuC0yCF+H85wth0mnvZ0S5Mwh1XOuV5JuSW
OBYrY6Mz5UBhBLX6Hi55RHfehuHWjqzIdVRUZ+z9lNW6RT+TAwzcvdXeYB6WsjuP6OCre0HgOiLt
YD+8SRAX5oZVOOdkWYO0uatq0lHVqLJVdq+o0TlwfJ7n+POF7mzRh1qpxyx802iewd7fX2fS15pL
u+IIPgnwFlwEpdS/4e8Wrhc8/M2FIF8F+17pl/9c5yMvkU0+DlC7kJON+7c7yq1+qliQ/vc4bZXo
HchTCgrhdg6mY24MBJjpacpFNbJ0352PFdqZhVlwr/QRFp54tGhDjTrXzO68vhTHiWWzRnWb0oPd
sGXj5U2WVDR3ay9hqqQnYuvLuzRwQDAvGRD+BlcuIFEXcx1lnxsdsj0gdZmw/gvCbrbYuj4BYav3
Pj+onlwufRrr8/eHYKtP8HAs8uxHfk2hRoEG0uNdVs7jjHhRRe6lV//MW2/2X2r+XSobt0WlszTG
Lcrj5fFcB9J/io6WmbstgoOeTu0zCAwr3Q6EbzZlle/5+X1H7JHBDHpsDmixChoi1mVGqLpi2MtR
GkgD5cfcRMONZZMgIfxd26gmWpLOGL5ZooVeYO+qaOjZuwVVD43RVDT/v+rX/32Vsoo6YJ5/Jum7
SMVM+khZyo0t96DjOU6/1e2P09Tu6lZrJB3beg1/YJcYVrz3rIcY5kJH1YTTHNsbECrU2wlRNaMC
wgrJJaCnILvYgdTNDnUxDkfwliQa8F/a8MWdax6ovybIT8lzPQ39cm0cQnyYx241bfeA/8pFEG1Z
jm2XmOdfZMXYoCm3LFMaWj1F+VJnIKMDJopImetJx/We2jFnsqzOZT4dtde5xTwF9WKr75Yr0TOr
tWoYVIwaQjWGgnPY6Vt2M5MZKMu/FXFODGtsdEHqOceJYWfWgDbCpxFWNcD6M3Hns4nDnuxjMskp
Fx/V/0pvQryuISWrng9Co/9R9j2Bfq0IYpYS6KvqSOjHNbcEgQIfWBrZO6N+9Z3XXv4X2Z3YXBHj
3Yg9Ya0FYM4MjhptkvNOHtmNn5lDIwfq798jH7ceurPGjUzTbE9BfkzsjHrS0V/1JpYyWGlnO67x
I83JrsN/O014g7Ysk5NxuZDAj50ufEvANjUNo3ydiv/JEpFTQQrhiVs+us7v4Ba49vS/wCQkM6MZ
Vtl+1TPZ5nEiy7gQqSncUpLrjm/GOip6nzaw4oz01mQAbVu6H7glV0p2PKo3ir66d20tXbTQUhSQ
JXNJP3NR7jURF6rBzqg8F+nsvx3i9ztZQhJiCVd+Rl5GC58yAWYplIhcZK6a76Qxj6CW0o529Gvm
nuI3CbFzObFLrfdWpoz4Y1UuC+O6aO1BJuVcPRys5pfNjcn7+uVcrndycYJnt4aLYU74tTy9WBpr
zOfJu1P5fL09kKu07H4H9qVKexQhkTWkZPGyhy7qkWVX28d3SoeD4+BQJIbVI1qgkYZ4bbTpU+8m
YhN223RyTE711n35VkFYGjMm3El1+azLBIslWhOBsonvkj5Lq3lXD78UNPYb4FfIisJdVicGC2qY
ZIc15OXGCwpybID58fuCpq7LWgDREs+xdbZP39zx5PhSury2pAJ+YihV29vM1JrkPDgKkyJ2bthF
uQMXHdUfZ670H2iiU/D00ou09mo4g666dGVw8N7iGaxLMXhNd+J4AVloIYZNjIVX70IEPIlDt1VA
koGAlYRTW10Z2oSGVzOoj2KYNKApZIhFSpAEZdDzE3SjNEMMWwRHWsSwRyJaooR69qR8x9YSMlTJ
Nf0EDRoPPlnNPC4f/9lBk2PwC6dHhGgQcahlpwQPmEeFTPxRAt45s0MRNHizDkyOZmShs/F/SOSd
1QDLA96mibuJ/wEaNuebCOyNQIyGiLAs45PnlYN7FpM5QWgDpgVOWSLMdJXooBvUHQGc6qeIGORb
78fjPlZI+EkN3tlPZwni0Lxy7mc+nFJyPrZ2Jedich5UMg3cr4ycxRFx4WMg9vvaI2NLmmsc8w6o
EhmsBujlNrWcaTPklNDUHUSqTPiyOrlp7El3ksHgHFAghlU/9yAzYipxa5kY/ctZmmuE3w87xleF
nesGD6QncBa4sE6XDEIz1sbsvakHnqaoSnctEOD/XDK0L8CtaO8nm+zuwuXRu+m1bF0h1nnc5eGR
GnUq7d6Br/U1Y+Q6CRx5FzPb14Bxgqg52VJ0emhFN3NoEfC1NRXD/q3lVFQwyVB/KD8KMTnD1ZfY
JW6t0tJ6BU5m27N7yCBGKUuUh00NDt5Yy/opyF3LxtnHzU1C7TP9gmoUYfrAU7+fdmgc0x9Or51C
z0BzoI7608c5yUl+4JBu5vy0MVmI+JRkCzQx4e8J9dCAMj1rgBsz8JOMYzFBrEHWzH21JbVqL1wE
qD5HilCNZfMCbkUh2iD+qdUDFwsNPn1SjfVGaXpOVWp8KTLfpjQWdFIMyzRj1IthrXlnxDDyWSBA
cmC0L4lh0XORCFDdHhozZc+2JsNX8XwTCWzw/a+n8wGeGCaGIeUGxLCgF4SmDHgsiNFkQYusEWvn
qu+R38UwIryDAOqYK63Hpi/VFaIohDlwdNc4odnlvoOkZuVAC6fofD5kLgo/6mlo2JxRkKoXN09q
QLDtmOc4qtL+BuE+SenQeoVFz7vfQmPH+vsK8HZLLboAoFY6v7G6VqegIUlLKWgKr+q7StfvTwyL
RUlRcmVc17dV3zrUJ9OmpgQJ4fxVf9ft6o385sRvAl0RCemUrvlKZchNUXd3gNCFH1TQu3In2RD4
CWnOVP/B/LTnL9x0Pc/HrzVJGPm/IaO7ipUKmoarHyAvu4lV0yffc32FDZPWPeVXVrSDr9kSiF07
09eFm7wK3tg/tj93yOGnzraGmL2SURZr/6Rx5VOuSynfH/a1qiYIGNVgT09bOJ+QHT1wRWbIUhI8
qh1+l3flVdV7ceV/V+6euVCMifuJC0O0/JkD9sHacvtCxAGmaZrBZJqRlCe0z+LqFZr6qwDyvUcp
X62bWrTc1brIRK7evxNlRaNFORcOxuTmxEoOF1z9muKb+3osASnjlft0YlyGj+W2+cPzWaOKqTxW
p1WwIEvnEfQKKpLztO9aPIBR/dnLaZUZjP3k0VUyUT4lY+YBtm2ysbm+JeNYAbz+FqLDBxZnbuXc
u8nAfXtfBQWOd5iuz+H8sjwW0pq8sBP4peOsqnVGenqkq+HixPz3t5t2wUy3jucEVVcgvy4e65G+
+c5WCl88v3u/gcdd11mRf+tP/6HGC5n/DDZt+91lNJa6retNNBWxbxJVmv9ARfa55vIT5SyRO6O6
3OGW/SbXdx9/l0y5+1snlQT/R/iE6TKn1PlqcKn8fPfYnXL0m6a+eS2RLitICmJpakP2XuFfaVTu
jYc38wSyrUrqMIZFUQo/Qq5WR9YZfq1o/PrhwpLO4R+mESbYkK1imHvF1QpSFmoQsxodCRchw0u2
KJAk2df5SRXd8od8qypYeX+2STRJxiKfjJVs/vCBIv26UUQEyJ/rXo2lp/zQkSXfrMTfrY7uv34/
fdcDlzWkHFbhI7d1bxYd4oPY3P3Gl44qPijpphQ3Pufyo0dzXYp0Q64zAtFaYthxsv3vOcuGD8Xv
ey5JfsRzxhoFmpIh1Pl8yX14eBa+NOrya1kGxyx5JFI2lLtvt7VVwjn8mH6COnJdkvz7g0LSS/dc
rryAynfYLlog49PniIE/QeyGjge1hUBrM9kRbJU18Xg0Dzl6ENom/iEDT8sEkTqD+tN/p2pJZyvE
dCCgx6Puv7p4ofQlrkRfQARrpEkro6i4JGdO70DC6bcbdS4395WvVqx6TE0/qHw6a+lZh3MbVHeG
ba4iyiYRE+rHXeBPW6OOhB2Ynfa3X+TfvYx8lZ51eeEfi6s+fUTO3mL/nW68FdyRv1pW7sW8b/6m
Qml6X/fF7udL8Lb8VPcRK/M4UN3Wt9oWjKqjzBJ+2rE1ZWL2qr0t/e595kKaJn9YDLtWk96N92g/
vPIl9YvUUfvzo3Gc8XOczROm+jITK8rtvjU9vMdPHYtPV/Kz0ETDjs0QHDL0USJYrVZ/zWI4f4xP
GHn64ycrx9ReW+P9lQvzdk4dzk5BHxJPmF24jKx7dRqs7neNWt+2pH9m8xPK0yIZWmynVWVktRDO
shFeKulSb1+dIyqmSiUfIUtqEVL5usxr9y3qvld//ZKoBK7eVD+SE9eaCfg9Njk1qRHpDal0ACLF
oqQkTzNacWyBd1KQfBYRfYqlx49jBu8+IdOq2h+lPBz3MWBXXRehzyed4RPVlznTvdTTtL1jUGgp
lOP3XzO/7Uf6HpTUyQuv9EXRu3ADsW0Ccz7VGM0LsKfdqhtB65iXZWrtrqGpaHG6uQ46xYtWThPI
fdqWDFeBiwuIV7FQcHU5zX6XqedXu9+WCRKbGucQAs0u0XwMYtbMI/aEC37x/KydY00RueOkBD8+
IEVfnqYEK5U14My9pipVgOopAhVSqdUlHAonIZ2/fF6yRlNOUZHP7pf0nmHVDGrI+Gc99uiwbveZ
OkBYFQ2bJg2erG/OqE56c+CIAyPdF9IfdZa9dBRdS915v3QnVKIp8M1JNBmv1l6r7ftkeW4J2EN6
ZDwWeO9nVP32hhB4hIrolxj2Qzv0FLDOF8PSDyUemD+cTpsf43456Y/gM9GdcFa120jjkRtUtfCm
QaMgDP4+5h5m+WJfluPwDwt9FwHncmNuvlmH26iP5j5Hl+64le2K0ZQKu3GkkreGOfDDqADzCKWu
sYquo5BN/q1Kww38+Rb57jsL+57VKBktrWKnUcbD5iMQOYQTI0EQtQA8u9pz4YDi+IGv7UcrAgBi
7fKT3kPWMkEB8klEl9PwesUWDs6MwaxqVqcuoNUBUc537MjfUG/aIC6IqzeGquY6m2M4o4SWP17Y
+dTfZdKlP/p4UdCAiFE8ercJ9/JTZZNRWXUN6s7IyTwDR4gLrOggbFsSZpj0FFaDFe+upBO254w3
Hc48/F2QizM/wdYS1bJG7A/vu/wqKwTt7aT7ZypTuxVynDf+0lktqO/7lzKaBkmNfSflRnOTP/z+
UBDiD1DELM9VLwMSG/tLmgPMfv5NPB0mS9NkcEadCOwc75HbkYvHVHqEl1zWnHPfun/0jpi7CUr3
hv2ZG7P3gsE4HhA2gqMGcyyAgxbuFMNS5bjAbEly3V3/EoiuP3A2XNgvBDShS7csNEjHL8qWt/UP
S7zqP9SfZRqMaqkfgYi5a2AWUgz7pQ1WTigNqf/tBI8+zCTiwJHYBIxAE9oEpx+8OVyAT5jx10M9
WnNYq7jkcrpW8ycuKZeIBhdKhoJ+POzlXVCc4NT2rFasX/7kQvusloS1TwnNx3A44Ado/7h9U8/F
6ydWRYwvFCGcaTewdJ8wdJCfSNegZ3Qsjm7XOMiEfMSwszGU0WoeiNZlofXuhXRj5aFFK1a0Zh2P
8BtzDxCVm5sPv8U/XDBOZyRcpv6Z0GRRP/w281tAvJOi3+xEXTfENC/s39zqHpmuIqgLdC6UXpEk
zkiAP0a6PBABtYthCN4yQXAyCc0g0j/vekbj9nesKkxY7qPIByLY9nO8vCKH9zg+SkY5HcphInLK
ptwEZIVMdgxKs/9YAEdScdFrcUjXlxAAmczIrUqo41lmePpVrW6GfJccURETRgZz/Swunn771Awn
oS0GQnPNAey3pgkOok2DPM3vZ/GthORcMawezbYZEik3NVle6uEUcoopYpi6NNvmz1ngZTkG1HpA
3g9xedaFEImWkZgIFl9s+34objRUMTQIoaGLzmLHYCtF5Zs71xMF+ZaYvxRdCJMVF5M6bdy6Z/vp
0LRdMcS14Uv6hy7p0Oz6IgWWWrkY5nZGsXFCLyUbKRoZjH14vm3gHHC2A81D6jUnD5GXVnA5QyIe
JCWJdYUCMYxjlTSslsbtQ+TSk4r+XMhKVkUY+t3hFqXyoOlRgFpVInXQUtLqbU9Mcyzx/Req6bcq
neOOS6iuBb5IvdHEcRLDOjuO5iF6KXPAEra0ga8g+vFPDtUQJCa8dBpIWUU543D7LycY57v/mkPj
RV+qz+Qpu93wg9iT0xL83pHSJYpNPTbkfEsMCzsyDKuebe3PKDBSPN2Dj8h25LBzHNDtENPov9i8
WhLDkdBu40pWahGR2eWNwbMUY04cW7RwZT+bEMuP6e141WmcSnwx+hiXirfP6HuZa/xcF6gSAJTK
h9ER/rLwqM12kqEwGo0ZX7uSYpas1WwRv/PEkt3XYlwLWuOSV5fd8L6t6cGLB9Uv3bJURueKKgAi
tE9m/U34HPLzEeHpi0UDnG0vD4thXnb+KGH5/UsLI+lPW3Ava/TbCWtMwwtAbtmB7FkBL5WhSRUg
s9tb0uk9wor51P3FMbV99SpA9FzBVPex6HMd/mA9EF5Byv6aa9ioZbntFENDyz37GPLZ2z2fmgf2
Xm8yXe5p71gNJ363HV8LvBmxy0F6Rl3FuE3zyIx7KNutfN71W2GVBTqSbnbISPqddnmgE5FYcD60
R+6Jb0fu6XDriw7mBrhTWWc5KE7nJhL8t0qlcov8Z6wnjkt43hS7UKelpB3v8fbC1GfWiNwEy5ix
eXOgc4DDFcy5S3YW1WQRJvPdRdHnjyc+olsigqYwEsuJ+5UcxfhiemuolFOhHjgJljTpuHnMRNY/
exDlGWRCdLKsuNXN6l7bZXvu2Ry3WOG+vp3ZybsTIwORWsfe2KqHnvldpGzoib7x7F25c+Q2RoGG
xYa7ZxMaAk11HMIQ7/9uLt3dk0q40/luoNiKsBBwQ5vUtmc0I85Sp6pJK5mh1n32sk/O9yyRzZi/
zrd+Q3XjhRtnrb/4DBpJKT8wOmR9+rrNtUg5q9sj30Wr6wnNQb4KFbgrZQaveGU/Y8pUh6X+rnlS
F28tf5pGejO6XT71na5tzZm7+8s3Ym3Vbxz7vpmr8uhjWVH6vxU/czL89juHTW0dw+mItgwbJm9g
9KgNfUgTw/YM5NSd6v3PpDqsQ2syYveTznOf/zY/LdVxnx9EFpEyhHDwfjFB1Bq8jJNv8jjz/oTq
AZXBpq05pvvfkmX2XPhYQb3z4Wupihkdc/NNQk3kTCPjeJJo62ca2WpA4WZd5HY8egUnhnmal/xi
rEmcSW0G59qv5Lx8TXCOcqktuCqz3rDDK4GgJ+Vp2ma+XefSmRsSlZNfQmcUSswS6+wsJKyyJch5
1rFQ9xXGA3SrEcgbkyAPJmn0JSJ5dNwduVm78jUrn9bfkhGDfYSeMiILdb72+H0aYD40bWJP0tki
tmhl/nbBwy9P2pNfeeLUI1R7zjAUU1hjL6AjZ8ot/WU9VMO4SrlgOcT+XeG+3yWGSunz5Kp72jcl
WxC0MaAuaXz5W9nmbyXDtwr8JfGMARzKAISPi8Wwr51+DNa0aOFz4IAyYyI3K4hR7rO8ZAWf7Pg+
EI0TWXdzgiAGm22/OjJ43b/UInxFVHOJMoDNyJXs2X/28aSZ2Fsz9FkseJh2wYtyQkSjQCINU4Bj
LYbtuiEQJsuoK1iGPbOMEsP8Mi3ybwYHTUKrrujtKm6UTv59c8dRPkqQKxqtPm5ApUlH9K5IlE4v
rf5cDenrCyQq+nwya/PrGpd7BECUAclgwHv7jRdNHp4+mSP7NO2CC5qtMOlQtJyVcZdHwH4Rw5Zq
JfrXUWlpy8EYDg/RfyaLir3DpggqLLCfLiSEV1Em4TzpSXWqHEVLK44HzwbabXpYtpKicF6bCWnd
8iKHsuAcW/hVYqgiqiRNSKzf+RuhETzEuc5vayK77X2QOozApUNO3YRoLZUKljG06rH2RAyb8QzD
QVE63vCHGEtRcyyiPG/Hdi9DEJ/twK2uHNgVi2Fe0tD/gnUb4DDB0Xg01Cq3/guzLhXmrkLI05hN
1kWoGFricQwB0H4dOtKXdOkaiMroJ08pqm4FL+GwPkbouRt1Ylhk03jotCbmypiCQA/Y8Yc7U54q
NuJAw35J/N8pLzHCSJu17AC7baFiWMRkZ1bd83I/aZmwBaeYasVcpLqJUdYtI9+aXEcx7KWoChR2
oTA6XmuFuZi1NSdgEvGjHLFX1CkthsnfhrrvM9NQv3KzompBHd8ry1gqnhEZlNot/Wcu3nckVWJ/
v2QA0b/VtRvYoE43Pw4t+qsy7dgqAX90K+fNC2fDendRUhyH9ecSHs5ezvuexaIye8aZOmg1Pe5F
E03G8UE3VbhtfdqADafDGH3WhQ4S9PpteiBJjTciuMC9h2yz/B6DCAuahoRsn+vZVP/OZjSBJr0J
5LZ2WncDW+IOUpjfYhjog1nffa81JSdH+bkoVwbF6YiVkLe6GCbKODHHhi8fiTcM1o3ywnX4DHK6
+GSwkbY02THSROTnssZ9p2kCGJJ6o5bURpsGactyPCTv+azJzBEXrzjfCYNYGo0shr2zf/NSRFuL
JHSxQvf96yBjO8ZKbEGEonqBaBCr9atB9eKWXSs1zlpCnV/SZ8mXP2w5vS/yu2kwR9h/qt+Zfbwq
3S1912nTe1zDO0GuMQSdG8VHVcWwZxqRUjUZERGbho0J+Hi2naN6xyCeX36CxnawKTAJ2fL+pKLx
YAZsb5teeBXK4DM9c7qQq1+bJRlsyOLaJ0Do65haMUz5pMUJeo18U++WLJZnoZ2ZenEC4syrRwTU
vdbtrW5xgzXye0zv7JMUgu+ypJBdnEcrXlf5NpMI82uimWc0IkWIWAKHbd+8QqyuhLwSw2qbf+Ya
v86+Zh7EOERTHoPkRFvqV5juFa2KzmHdpPHev+Z9/K96ffrYwAce6Z7JOZHliTreZr230SjCXw2f
TFPyutTUJYEr4Y54EzFMKQW6ufXNVR9OaS7jy6PSgbFS1ImlXg+FU0RaOj8ciGrdu3cSP4ncoy5k
4Lx3ZoAlrXcDNt5/4PmTMfSq7XqJCBOekzS+Kvwv8lVr9KfEkztu5+EzC/KHTN9U7nlUi/wtW2ke
3jg0NB9TgD7urNkavNhUuej33nGqW6kMLZihcQeE67YhE+qhLxvrcphyRDKI7bclBXy/tzZEtEwO
haF1B/jVTS2m6m9dqZZ8vTjWPi1uLIA3HBoWyr/3y4zgmmlOXut+JhlNam3ypaDFzRFtfK5SspOu
fmgMURE4p4P65VBHjW3Vs/M8/zjy9D9u+1uMJDo4QlXMhy+tTXO6WpxeF22tMPngrBuvd6Xuq2EV
88nHy/+oFmJujCmY7f+kUiFcg8eoSEbHA3ulLK1PsYq3MOyIWsvm9nOTC//2yOgO6BHT5f454UDp
R0w0O3IGZX/klcrdaPA9PhK/byvEJ7p1Fad9Fj182Vn/8SKrxVMumws0icq1t919+tOZk7EtsZ+z
8d4p8lhWgxhGJnBu+80cp8cEBX5/lENN0M5ZoJfgOBQPigRDsbeatvOIFmOQg+gepLm2e1/pcofH
ri8JpsHtFhYyOSxs4pEgG5HzJk4Wn8CMJXn664bz9F6+11S06hw0yxAQ2hsk6STpxICV68fh6qGb
QXMo1y3f8zcH3kffSg4wPndajmmtjNlC7H+qy+EFSmS5nPRZK+3S9j3bdY7xxnYEt42bBRSboMuN
/839MyWSDF+rODV02KVZ/wdBy0wivV5lEKG2+easjOydYIbN0OcYtHzmydjN98bXvTQ33XFZQl/y
YWexRhMTz6IDgGPBTENOTC0Ptzd3cawxuJ6wygP6nh91lzvfkoxPdX2afeSpeeDf6qmt+F0vdrww
dHWN3bw/4M2YejW62K2+ZHrEN+fX85kWN/MboPHba7uf0wUpKTPFFudqfAeKuk/s6N+zF/jHTqvw
U5T5djGs6WEVkodqGvVMKkyUuwf8pC2rlIaWVjyHLFt76FwhvMv5/LZMxF6mxSfHAVHjjVLlxPwk
OdFvVbRtw1N/HfhURWzmqH65FtQ7pkw8/65JNFJ/yaSlKePPDBBDG+hzBi6GUO3blHQ+RHcHodhk
LwkYOmCpuXZBR/2jb9btJLOMthEQE5v5ejBeI0OX2fyxIn2CGBTe+mPcoeQ/jbfP3il8zQ0HHjYU
4V7QFKMTTbi6TDLhh45r6tFH6o+/Y6inqOtDHUn3X0b2b3ckrzW4rKdn5hD7b8bSqB6NbAT/dmSS
hG0k0nddcCZaU3Q6FmAOP8syaU9WSu+5BAwsixbMr1x3CK1QPEhBOsrqJyoJCPFrcW7YvvmxSpnY
gqsYSV2vWFhct/atq/RtdQH4ARchqsO3w62LxzV25hnQnn6dOyuGEe0pfOQFpsdr00ezKUxAg8aT
inMesvreq/GLO9bQknoz+EsfjVKVhX11Q2GSK8k/7TI8in61tZmeSmzBaYmq8XNFmDWpu/on3Gum
CXMDIZL4hleVvsVeh9w9/arhtdfTdTnbJbivV3wxwKlaDBtTJi3EnKFP0Sjmp4T1jRKb+LO+nDk+
QPP9de1+vQy1XEIk9GfWcfk9I89vfgUJHyZOFyRc0S1JLNM5rOK4UNhy4GKi5aqqTbVdA5pi92zd
/tdHlq57xu185DTbbtLg7mqJtfzfyS2ltTdyfhU++UC+bdJ/Mq2AkT91crX4qmGp37v3qjFDeRlx
iD0B+7oZl3MLUBJS2QDxSANBewBKDf/LuIFj4yShP/qeZKToDtNF4/DXhj+Y6sX5V+pqFkYbnmWp
XJzJ+pyqyO1NAwak0SDdf6yzuvtEQVrKZ9FMYhqpB32wKPGp1M2Jqci48AGKRGU198m9OUG1Raxv
tjM72qb/E2wYVfzvc8LRmg2c71ijI1knYR/7wyDZhyRZR7oPA9BK4SMvy8vKVkvyHZFG70IRGAIX
aKPFdQR4b9elStnK+wr+BaoEFta3A7ak2jJS/OD3aWGH7XUOC5Lhmim+zBw4Zp3uOtW64bt/q4Vw
per7J6a0cFUgGdu/bAVLLJQXh5GUZskaHdj+rnWwdnBS+Jpu5oKGiG6HPUew5KZcNLE4KFGEkYz8
FBuIsOHL3NaI12s6G7ij11ckYrX7HnzSPk2CA6TTtQx19iuqJ0sQYevAe4lA5KLzZHskvXkTsoOY
GohFiMKQO5O6BRN7P/fHcwowwK/YrqbR2WH1REhjjVttuuOnm9br5JlMJ/wIrL65crhsbD3ltY2q
eoWmGNZw43v8qmiwKATtGS6jIyk0eG8hOFoQo1f9oP+NSA/4ALArcKpvB1+V2PD7+dDqPdIr2l1c
ApufEnq5NpMQHfQFkfPcZlgIFz432bhLWguedaCJzUNq1rkSGXHMiW6+GDa5PsqUZPIZdIAk/gcU
DmoYdEVX9dfJERPDx0BCVGH61GOJYcOFr/bILaUL3H0zQWm6Pzw+7HornkxxvuxyrZ3DLMQ6llpm
XvwR7NT+oSFAaoqc1NqDjeOqO2Hft7dI+u++VzqaSsKWFkrY/uBtMczH8A+3IXa6Ap1fqJRZ8sEb
1ZIujc1ijU1h2iXPSoP3ZwSXIkhMbjUjZS3Om2xX0tiSKAoMwnewFtiMiFF960w9uYXDsUQ5EItA
YB/6YXcn0kX5CHYQJJNvGfq6IR5UGshgRIZEIqiQDNa7FOngDz1H6ycQuMSwIGSaCHNrWEhIvydV
N21iuWasIy1IRw2JaHz7FN+VGPdfybLeS1pM0UL/n7VorSixf1a/NeXqD/AgPnTZPePunSzoZHPO
HJpVhauhzQiAhJbLEUsH9eNuvug/hncKb6LgCW2/Q4C966D96Q9pqq+M0ozS0csNdhPaFHc//a9v
8X65YKVy7+jKTaob8brcelOyOlF4qWnciFf0fjk89ZyZdkhtHj0SoFGEwNKIGDYwsLLh44csvPC1
NVoPiuzGh51av2HewE/UpJC5aIqItBgjV78QjcsFsk+taPbStGIlnRgQ5ksSQidFc/3g2J+lUdud
Q4Ct4MxZRjI02fStwXBiXnlaOM9EVyga+CfMSWgu/3Usdvh+jTWp+s196r5unE5dCP53dqqUeRL0
IArYrXHr/pJWvwNzb16+L+ji98AnlWfE0MIt10b9RkmbYRMtJlhlQep8wi18Re3TRoW7UTivym7e
k6S9Kx6Vk3qnu8GCls9fs/b1GibK954XrCHPRpyxgDy3GzCYND0QO7aW2au0srkvy6WtauUJpLa3
3SogkXG15LxE+je4EbrNJ6nws0f0Drdm1MTMtkhoaPjq3yL/99XQwEsLnCiPHDCsb7bLxqC6Dh59
/PFWNQM3gubsaN6J7CDNmMt7+7NRCulI0ReBny3zsFbacJgT820rLvlUainYh8epK2dHRvrHKSUf
DVJin5C7X+1U8FDVPA1+z2IpFX+qjwx/ir1HvD3WrxgdMzZMjunIvuz8xo6wLCdq1E9WvR0wrSwY
8stosdJgi3IqGjkEZRP0mlSY88+NBf4LGHiWAjN9Lae+FAca5bh+1W8BfqOMJBCkutPCaUaAYpHg
fK9JSMo857e5sZ928+NAKnJCSAB1IsF36l2GHSeTcU/nG2YV46EWlgBg56Tdr3FgZCvJxu9WZi+6
WT4OGvvWu0aU0T5ntsP0SDCu3XKG/FWjEdRs6Ez9lKSiPGDEth3DBJ/at1HzRn391BNwCGWQTUKe
/2J6Ajtodvd4fuKh9C1c79SmLjzdkscTw6JyJhzO3XUzyuKbhzWI8kA/I7y1beQHPjg66uRUm1Vq
GdpsdpH5VJMPT8DsfqF+h23AbpTk77ovQ9N+s801IfsjOfCedlLJ3X8fo6kEtoOdd6FJgKiWAVQ8
VPoz6X5Bd4wDeCsCIZLQ98M2ZEP87k4BmaEnWnVeruZdtJRIhZ0/k3kwxATfl2wJLuDVwzJPqwkJ
qxhfBMjIOXiOGUR02RkmQDLb8ahpJ8KOuCTP471qVbpLII0J4N1isVVWZSdNLG9E1G09GzSwKZeH
o5DtnI9aruiEM7aJYc2EjH/IhlFvhWW8uqWtO3pUxDDZkaRgvTSbOdLopC4maCrSo5IyH87cIBv8
wJJkaPrzey+GVmlPYg61BbNo6ez+QMDXxQg5PUC1Q6bfGpx5oJDaxL47PywiNeVMZSrVVAy1/erG
sdr7Q8ed82ZD37xIdTl4VZSr+abrrKyQsKxSqDcZdmZXitrfoPX+1+tTSfyCrYutBRfbFIW8JZOG
sTbnTVrmuP4X5UsnXndIA5g++y90crL/uQTrtYffP6zsjDRmtiNA7Bs06mFIQy1YmEDL/VSXmlct
dE2Oo3tJaKFPLajDHhwM1/nbS7YyLqbptRzdbnefHznNWkXUkQ8AnHz5qrVAT29BfL9QFY9SPWSo
gVD62Yzql9CS9lK8KLh6twFJE6dhVScadsLte3QPoOewIBW3/+7xbab25ocq09g6ByhUsz2TPqFy
fBfWKGZp0Q/9w1L7BqZLDIsZpp7OkZ16nx5EW9sJhNemr4th247Wlrm94iR15sLxrZhA/pHJFh4O
a6b85v2HoMP2kgOwMJxHJpAqeVo6ReZzTCoRR/wqsMfY6Lo1EJrNY7PDOIvnFm2bby6l/lkV8K9q
CtX2Ki3ZwHQxL58WGY5O0xHDLtm/4R0y6LG28BCe5MylM8BRE9D+x82hPrZCPZPSih3uTe5SNjP4
NnSLyADqCZ/t2Nq/amrSNFtUP6QBDfg1nG07pLn4Cit7NNhd1vcAifVEDKOWUJHSDq+5FBqIrfQP
zCzhQtnXueYiiZKWhHmRi9KuQv017LOE5wRSlUAbGOcCqaY/knQTVBVuFySgTHfmhOR4X4isNGzw
GWLaBTtsnpB6JOW0N2EI8tIOENUbzBREp+Z8456JsOpnqErPNnM3q9nIh1XABlsTH94ctrhi/GG1
G+ndxc4PHWrgW7MK6I51DEYjWv8qUPZFoSVV0c6tEizjawq329fxHULLuzbXPv4dKd8U39+aJJwM
j2FKeqpUDNMoFsOCwII6otPC8PxcjFw0SzSKzoI23wgLP4DeoeV065Z/i86xLkcKfuU4/VenJMUn
1/4uUI9iqAIND/VrWUzEn+VbQ/yvGjTm9egxJZ/uDRW4EdjdshKGQo4cj7ACTfEHUVlHpioI63so
2NJliGbRNnZAdsJgsEXWA7feTpZAgPOQ9iWUSaf0yxvwMGR9P712JRCuAuBdOAN8oA2Er23TXOz7
2DrOZr3jFGfxAYrjT4RoAzKB0vv3ffM4JoQiMB3e6j4bH4sg+GObHvU+tkTxYjGhESvM2ouvYJ8a
0nAumX7+rRRe1qGXZPP6C8CYZpZskBgWHTIyRuqaxoMmpJhsXSaNLhFQfAOLySvXTjL+YaimroZi
5JsZOLVlRAIUAeFJQF36zWGdvDgSxRDRXE8514m3KjESZNFFASa8U/2ikD/z8VvfMN7N6GbdAvcB
Wvz8AL1X7yUIV+yV5MN9oxvnhm/DUnAidrtL1JeU2EuRICrmSbrEVo3IWAP0DNlt83j82JCpWvVb
rF9bI9epSfROQl/S/IqoUEBvVQwrygzWJUHFqG1PlETj1ImVL2LYugz2enSlG22A93ziqxjGqqGB
c6xx15zA8H0Dx7aj56q/0HTnHYJorJr1Uah7SAzD6TZuS+Rp6jEQFG2C0EJ6zIC/2qswEBTmgp+W
yw+lv9DsrfxzkIkOWxN00Oqe/h12CHUgVJoCsaeqd3v0Cgq1njHjeutRFBRdSGCjqlHKsrLMEw6g
mksWHZ0aAazYFv3GQJt7L99SHrBtGfbhMsleGCpJEmje2QBNGqOlKEna4kJ4OiJXCNrj4iWwHUS+
TjceJBp8cVKwFwA/7KQTUTO4Mc3D2pzxfoEd8LQQcvtsyXqQpiP7Cpc2iuCfa5pD8MoNJuGTmeOQ
UxAFcmHbATO1Ru3D1fAheOjeVJ62N2c0okrymSm3yVY7j9llFgZ7H0o1pOHT2aoqTWxw3v9kc3Tk
kB9kJs1wXhRKBwTynBt6dmlpWwnzvZDkOASvovaJ+hDEY+klHxYNw/sqsUhC1rdjH7wIz7Bb8cnc
P7SXwuqt+0IANYbNomtpNKDGWzRHJR/zJ4iYCdjKyuslFhHeaDRdkNs0dU5YQeMPEG/fT7u0E/H7
vg0/0XxJDCN/FsNmbybm3WIsbJtO982SmxL8WXiyofT+UzHsVlO0oztcHpH9068A9Qcy3UajZqik
zzeaAA1d7k8Bob215j76CuieHVxWf2q9/zmeARKi6dUX4M/ZwAuMBO56bkYD+5G6OM2wQ7R2bw6Z
LulbPLbDuTqs0pXaGpkbZ0/Betq50Vi1RDfjB29dXANCTc4Zr3xE8Z6krP1ZzvSS/XvzZ4r+J5uS
zZ1mLKdQE5IoQyWbp68B45ptTl9ptAEA7OnwQWSxKiSDXQcNxkEB236P+0H90uvFnMIpwrKS2+jY
QmYTxqc9fqmJ6hpep29gXZuTBFH/rMARVRRv0jT023x7IQ6bO5DS3+LPY5MkijRBkAQjn2TLZLjk
l3DF7BjEs2P2edVu8/AVZl0EEKWDFu1IB53nmAik4AB6ndEsSZ9xzHupfpn2uPVkMWz1tvELPCE+
AtTJKCKTkBdFbdHwYEVCOIYwYELjE35PGfGUhO03Ikhd1GLFkD5iB7z1awVmfbcjcACpieL5pOrX
rtNPsEGmQ5j//dIlGhnu7XK/0LF4sknKTrJPMoO5Zo24h+xvT/VE3xbv/0RQjaCRDH0MHpo33ox5
jr1kGtNMulzJEQ4a0zTBUaXahDBZB7W0O7qyLA09oMElxyjpsbtc2oypfI6TAopMWKEQKCX3Lc0e
WsBvd2zf+Y2gKA80t43q+LSzBeHyjIwZP6zJ/oX95eE/+zYYOY7HXFbrOZTpfdMq5Hndv6oG1G/U
WHPL4F2nT1FvIjgDIQ5GATVq8kdq7M/J+DzJg48+GRBQrpf++R4sWGjdFH+0bC3e9pX58c8l3leP
4T0NfXZONo2so595N4CXiBf7efd5n6r3sqVFmEsglryGu/6Q8/X1HaPMsy+/XvJ438iUkT1+Ubc5
QTkgMSAeReTGEIKzQGyejl//RpLm0hsrQp5SxkeBT2wfJhLpggqBxkzu0+Ftbsm6qqqa/HAs+n6o
uXFTc3uqp0ApQYcrHQGOEC/5KY2z9nVLZ3Z4quhRnEdtcJoEHrAsF/Ha4R92mHnlxIzZJuRLUafp
qIMYdrysRrMmaEjnNYsDsXv/rIz2IQC4/VD2eSA8bEdDD5akmXnGAAk8C3yXtLIJmSgbKAAG+q3Q
Is31l3DR+2+4FeXiXXGuKDnKJFQCbxHR8Fb+wa6xlfwrSbSYJ2A5tVWkdTMhrPW/K7n2g04KEvGx
h3jsdvt7T97j6vIPpWhFolpSaD7rwLZDAoSTKE0+hH9QlJF/Ps4Wnf0KaBiqLyVk/lunFWQ4Rfyz
GjLbXmhOj592SnHwBrHO/agaHaKXrRsh3FKik+lgYzU/83b87RdtaDUVuq7EjX3RIN4BWq95eElz
zVS9034cfk4IGYLAypjAuS5oqaOX5vdCLTUS08WP0BQ2eNckn5EhmyfPd54O2v7PpnjiXTFsYrjp
YUt6ZGSNv8+RUoHzuMg80kqXxndBWbkBtwfWuwINxLCc0+Q5iMNCZLbvuBQ+cm/y7w4RvXuybWQK
EwbEM6p2InZZoNG7hsw2+Z9x129fAiaLezu/BQbgoMChRsJiClsP5Q3ws1iDGpVh+u+/MqFSkbtU
eK1wK2v8RusuVeWytf3bjgT6CDKAHzruXONEZvigkLCghweiIUGpkDB++thac6QXV47tcPUwDlDz
0E1fk+h/ZYqkQCPCSd78+I6BffmHp6qFOsW7/7M41i+8hsJEMBCZec/8GooH0rcLOpyZ7y4kxWX0
+OuezDn5Bu32qfXXl9GNQ694+9ZPF9TByiRMY0+7kZn61PhMqY/qkVLmrhtsEZW26Fz21ybEHRXV
/roP9+dt3gocJuyTuL8PPn9UjdYqc55jvPfNZRCjZvCqiWFTwyeaf5Lq703OBrQUko9uCGW6aE4X
C4smGKSxW3VBsrFn9hRWaEy5mj+Zd7OVtuc7UA0zp10YqF6aKqpcQ9ak5WeIxhi5xWGjaGro+gWF
GQsfjU3s7qpgMcyuBPhkVf54gnodaN8x7hJbPD/0r8/Tg8KTCaXcEtdfdbKhh86Sv+pjWnVZFJGI
4h/9NnjnjFkhtWRsStJD3oQvlUkhBhHOJo/mxbDJoBrq5Y1E3QR5O8szbb96K7XgYGcM9kGR//1M
x5LHd1Rjf5feLczNsn1QdC4yRDUqoVpHhP041UVgU5DHL/fP1nUmJOIZPojVAIffxEuqSdfoGfCI
47UrmkQCuKqy8cLhfDVhSXy7LzxWEipp7cNd5U15MU3+cXZ3j0yQO9g9t5G6cN+HpO0eL6gCTJiC
XKioFm/+apdJ+6tlL0+Me0YhKjoymKAiFyKGDWhXRjiHdHkf6juMOEe3DbyCB9rliG5KBdd5qOv8
f6GfPXaOI5rpLXVcIN1hW7rWrgXpMwfYRiLSEoj5pIrpyKOpCnUWsg7bzwANwqcKaKgWcmZxuISw
yK7+Ruvswl8rwl4aVeIoFdH7jx99Op5G6sYC7ExBRSHyIGdSkITyP31i1TPMBHHmz+rrDa4jpXPI
OZ9K61+jp3rEMP9wHGh3dPQU19qSFVMJMS8ZP2LqDZpIeEXjz71DbHtKBAMRqk0TTAiiiTKQjt98
Enz8V7c8uFk6jLyiYtq8Vef4Zf/nacVmt8+Ua9189XyjDc72QulG89uKFAuqf0tRachzvcGOAu0d
wR5qhQ539Z5pk2l7Hf2H1HtdnSqZ3pN03YWZj9VljfcJ9R00tQGulrxxpYhUgw4BeL+OKg5vr9yO
UsOE6KHXdp/E5iF8M8ntp99L9WjTlYszx+4TxoyJ1t2eIQA9HbKtUQ5cM7dtHMRuYwfFzHFwqGR1
QmezAGcnhq2ZeTSMQpQ7aaisEOIxfJw30M4PkDUZLB7VaMOsBggtRaTXv6TlxbAlUz0t4JdOKQHE
CF+9SspauZxR3D4zYRQ8555UL2DybeBhqvm4tM7PIb4JDnmEkXpcbz4+q92f8DS5x9A9/BehTaJi
Gx3rSDci/qsGCe2GLRhRu5zw1aCswaEx+e8senOaplZYY6omqCaGdVn7kVYGsXAsk2vgtD9LlAU1
Uk6ZNeZ/m+Gw/AuTj+qinsf9WUul8hr/k4low2+2rilbGnIW0SHeQqU55c+cuGVNxqnXiitKRTL3
xjJTzcH5THt/nhAP4JuqSl8EFrU+5EVHQqOboh0Cal/RKBTXUWq+R2qaUvafMwbqgV3TFq2uWTY3
YkT4zG1/voM4qncmmgMRsigwMexxDolz5h0h2YerxLV7S24B2BUNYT+31Wjezf0qGnIRYdArEt2e
qdQzXCYvXGKktjXvb5KkCiQ2SF/2gHu3zJTe5KRT2xdQDNNcrl0e4oto8espEsLB3VCZup8wqF2u
DZr6kBU7ArTJwAqlkanVSfLJ81dUDQhutVz3w0cwyUbjT5nwBuX2J4zE3qwecjCOT2Aqk6r3Pj0Q
8Jq5v8jfWVNPAqKZ5hxWMUgD1kG4ryB2qPeiTyHKt7w7+pwpZJuPrIoGeMjETpk05DjXTT4yQDWI
7CwT/kB6ndid6sGN+5bvQPWlNOXWrHkvKXd1zCt4TxGoJOyx9NlSYcGFuvGcBcsED/B6/6yw2pcX
SwB1Qss99WgkqiuwKAtiawNKHN1MDLqz9V/jImv5ekB4+oSbeYfsilJTutRSiEvPOYoGLSNDovE0
OxezsR9DQUHKjrPos+G1/Xz7Wj/3o41twxphO1sUTWdQlZLR9svCqUlGj+zdPAkV7GWJGL/JztHC
FTFsK3RDTph6qPXFAbfuYHrs2BQZSMirXuipMPgd38OHVNqB6RTl0144X8Gs46w9tAVZWukfTopg
Cb9wHdhBkCYf6bs3FGzr2kddSHV1cnFR0WNJBy0MDcVYoAKKzIqnritUmg606pL5FbU8tX3z3yk3
B1rDpjAUBA95WcvEfKKmRi4iYwsN78DmWk5Dy4QsMUxJ3W9dKGNQwN//CTI3oUe6EOJFC05YPCpl
d5taqrkKUeUrObsD+c67SISzMvebFZGDBARKEQH7kGrn6CaGtUokq5j9P4vA/c9qdCdzHaAzjblM
C3SAombwX5/IRVMVEh1ACxXHxmW8M4q72pLHECGWWkFsnhMyubaI7N/TEC0ArQiTsTRKwbjZI/Cs
Bkt/gNZQFR23sATxx7II4ED09J81aZnGjrgV3Z6gkhz4hRoDBC/O+V3JAs1jpLCdQxjtwRPBxlb3
V1nloYq5bfgwyp87bJ0j30rg3jb3c+GjLLgQW2jw6/Cqm89Oijlz2dDT81R23eKVtYoL8nknDmuq
eIaz8Y58e93yey87WYQ2Dq0PkhlKN8RaNpa47doJ1XUsjnT1GG4PbDMJQBXnajaY3hfDnBiaK8AH
/1bLZ/LvG9sa0w5nytaQoR8VOUEZ6LCAUK0e7jXCgkS1KuIyiruBgHtiGGdIHR+Hziy/UN0qiU1K
UomZ7n8njy1svyn7A2fvOKOe0g6N6s45P/03tfugoio8lw/FiGHtTqef78oNkugfpTIr037586HE
17PpkJOOeUZ33S8ZdNLfI0FNPTuv1S50tVxuVUfef605ae3389uHngfdPaeo8+7epc9/z8u3eO8+
onB5vDrq4qK9c362/I9a1usf+XiT4kvRVVaBM0vCq8efYpRScb4idk41IWgMsbbbrnHsHZaQwzJH
630zduvwoeAJP3Q2XaPMfjZSTMKvAU/8feseXjZfAiGLkWjamjReDEt75NFRLZ0dGFM4S+74kduB
BheKRrCe5e6RFfnWEhPVbNOzc7vVe+lS95Mtns6hJG0XRUS25YoVSl30o2XKCfnvvH11sD4wr2X8
rp4WdkUQzFmtko319sh0otLkwya2MJsRIANT6pJ07ZtP3mu1Y4wGb3Le2102DWLYySwU66ffnAki
7dqtCCEZwPORVTYuTrQu7dNldX/WbypnejSFkZ9GAk9UMgt3nXWNmyuFHl13cbyJjT1nGfSym14V
oGBAayPnQhsdglavRqN8g+oCD/dg49Dtjrz36LtuxzHxLNaOCpUVftJZ2YvGpTpLqW+bDHzTZ7Vz
IYQmSA4ft84MVm9+dPSmvXu8B8lnzXt7+tAtpsv16ptFYGrsrY12rbk3c9ZJM5oXVdObhWQDjI5n
R0Pis1nHONMZzthlGqgT7n6u0Un9wL8G98m1oM6Hz97qs088i1paD7lldR6YehMZbcCC/9B5d6KB
4SyLOMXuYWgFQSpdFifYIUJCVOOdoSDPrxJQL2AcNPEtRp0l/Yih2gUlzAnhyJV9LiB20Hbk79MF
CZ1//VmJVWW3Mins0PejMhnzj07bqC46tcb2vw7l/sf+sAWnibKnXzHAEil+NceWNqVYue0LmKw2
qytHl75W0uqu9ySnOnEdXcth18j6/UsEKvLb4Yh/33zhaFzud0M5ODz8SdxzHtpyE2p84lFTpKGR
mK3wk0O2C1O/Fl3Y9kn+Dt5hl7EuOJdAQu+33NfHe9kqGsY9WrPxHtX2f2ecM2aayr8b339Fa9P9
/PX9sij7zNNtxeGKYthPQnily/1PEM3A47kj/3x/kGXpLwd7olrEw8u00H5XGQkGPQ4Out2md5iL
gn7W+I2/PSTbFXHJ2xj3oLO6pZ6gN096i1sxmXTLRt3ZMB6gkikVq38eMsP0cJOZ+JBtVe0mVzOl
BfJ39i7/GGSHyxz+2dmjnVkzVtk0LnK9SkZdPfVcn1zcer/7dXUzsKJjt7S7MZHRqdjtyLXPNUnw
V49DaN6zUK1IyaIXZjz59LNT2c/zgTRxO/xNGyDlT0amD+we+fdTam5aib0kJ7DGlL7kG3zjvNof
eavt0ZvKWBXGqx1FQd1BnMqBFbvhQcfnWm+bxzXa2pcSeY/2ZswBDa6xqz833V8hxjKg1XC9pjpW
dFh3bwo4wFd92TJcFIMj0mch7ppfmbTW9Ai8gc7VDbp7YlSSyMLufg1VkHNelDAj8yNOIB2Ymilx
skyMJt++3P+ivvQed8tWqu+rP8tMRb3PMCj+7Cln0Q4NNB9k0nBYi8OV9NyULH6EXCTyMU0x6bZM
luoh32ozq2ozp0PK/qe1p77fbvzh/3joXZG62eGiso+lCUUnjQyyzXM83i+ceXX77JdXNlq3Dm34
u6Ze7nfK7m4ZJuX45yYK7bNrgYN5qfMirgnjj40XyWhmFImGNInQKmLi5WHh2ZMPu62VhvTIYPUS
IVqUU+4P7Ckt+zNXPHV/uJCgwbYYfa5d08+VeYx1MCV+zT2eXH25rfVK0s24e6F6RKh7eRQvS76d
87e/55+55ATw4g/c8IPyoB9RBk+C/eemjOuvJfFGgbbKVk1+pTGPN2y2EqOnJ6ufohrEbseFjGP8
+NJxSBLJpbovDUc8QaHpOI7BGyEynVq7btLb4fznPBFOX3AaJIhweCIrRUCoFW5b0tDxxZqP5wRo
NjQGvuw+PJbNF8NWdJ4UIFOdycjT83v7JfsuROhBl20Rny9WndUeus6P+x3n0VAKfm1Xlc/Sh2gc
zpMOubZF4ZmyyTjO2PzPFIlj+Nuni+xnES3OZjWlGO9dWfsFifr1bZVQhfoip1a4pZmpZ9g+MpPj
F0PQ2P2OZCYlzShHC+FAqTretIzmL4bZ0PWyCSJKo0hScxQIAY3sIViPBGqoaUxz33FdWDgiSGoo
ppH05S5TWo2/ywtCTCvIWaKcH7W/c9s10aQYrIRcM+N8GAh+1hrSJfYvaIHMlMMnK4P5AUtc+BS0
eowr2U8OWnRq3ej4ibyaojPB3js/n1isvSBjgVdFotA3Y41JsollzjpJ2cUpLDT50zjG5VcWf8+i
zJ+lbGOwHoufo/Ly+nRrDwu8wXxEf2sWoUcuYp2+sWBUoyB6Z22jO9mUGiXKP11EA2tFmUXQxHvc
fWhAO84hownBjqU1V7qOjj9Zlb1/Av078rDmauUhPAnOL1dY7gc/pKNxKX1uPQfNwHExLOxMtBhG
FBLWLaGbWi5mo29TD8hdlEWr0EuclNDpAXp/JrAi3QD7pvZ2XLJsERnNr5Fm4cCM3kn/eiqluKDx
36/92JgxEr6DRXLzNG8ZZLkP/fTNlqOSuep7igRn4ltRSD1ezgtzOm7SzsmuEBLDRDqSMZU4gZIT
naBCY5dsERlxqG80JtA42svAeS1jF+SFyw2N7ujMam4gxKeUg/BxzoPvfq1JafeRvE8BzZ6ZxgIF
NGvMNz7sWSOuOYkXx4ecgb1EO23CLiryH22q1z9fCF2qf2a0xFSfk9s71ROtVLI2ZgqhszvcCEtC
bJwYBv/IA3iDv/XYq4mol0URZlrmIWnEU0Iu2dFAsTVhQTD71CvbhTXi0CpFefiJzTWBr5cgZspq
76niT7f1lAPM+v2FZdQujdS7O1wVzA4IF80LqR/3ZAO7snbKmuM8xmI7UkJ4GD+BnQsrCJ3d9Ocb
E++HfAlc3ZhKaZoPJCNpwWXL0LXUo6GfcfudF4L7tfNd/WrFsBQNlbxxYVyDIoYzLPK2CCh0o7hX
v1LtsP/fhfoiCZOVDtDxzNH9wl9B0uGU72LYxlhKtaQ4QELE9JrxiTNtD3kM3afoszHFCJDulwPt
XTJ3sW0WLYVoaQNLWMvgadnXd9LQjS4NRjuIajv5GbJi2HHkA331S/OpCwb34lzxbVgBTndAGF5K
E839z/1D9goAjtW9gK/V1ejRWTKjZKQi6nhfeM7jUFOyVdyqcl7RQLmWIsAZYFt/fDflijxTatRX
QwYmK1yFI2LYZ9Z/DW6dOppwkVecpP38TCzNvsmhI6uPmrW96bzl8o7CsvshLtvlkzROYvpRfybb
5GMiUG6ty/d4L3s6Zg5nnh4tfoSm2P+Za2pUtmFLSmjAJukAxQluIQmrnBqBRu0WWioP6KEzaayh
+Q7plo730eyz8onoXpc13pAfdCzWeWd5ppdRE/yCoKKdLUyX0OVfw+7+43odAf/WfcAbIAQBIibW
3hjLLWjOBBpxudxuHH3SzLPAIjJCqf7c9Na+1Sj2J47TAFo6v0bjmPGRWgoSN7Bi8K7ZHfmPhW8w
LOZwhncKHazEidwcEx2xAheJX7wTYYjQIhBVOBKjxou7nxx6BkdyfcYDaDq73OXSA6NTMjm1rJ9k
ifMAWPOQG5mf5NqGtVGtNa5TnyOBOSZnnD4nItXtfZotz2V7g4oukkMSoQUHVa+vBTE1Z+o3iiL6
0oC9r2jdtptR9qYaQX3PxDC1PGCypP88p/OsGFaJEEbVuP8CJvkz3wIei2E1hM/WZm+ZiVH9eH4C
JgKkLau8PHo38nh7XqdL8jzytfUnLPnq0yMlocHgVwOOANAUrbZi/AulOcY/QXaLRRdB+ErDdniY
mI0I7yd03ezA+fz78dalYJf1uNSgxVb/T3Ja6MzKlqR7qtPPjm1Q3rZpn0rkgYMXknZeyxEMGW+W
/6qUEvXbccZ0ZPNtg1cvP718a3gbdqQcqTyYvWllO4xX2v2BUVRi6+r/SudrjMggTAzzaWMdhTf0
daBXSpfHSxCeSw17ebICh9cm3sdXP3e1rx/+I0k/nIIuh8POX7vFelrjEvDv1wtHUHiLu+ovtty/
mzSrbKbLJHPtC+f/JYVFblRFCbLY9v99I1uknbG9eZGA5gfYv1evNuhCyz71oZCwdyJ16WsDN769
24U1OnfhsNHXvxNiff4uSDgNk/z5q3jiZW2Pa1WHfHuCmXQg6lFSzYWajxRp9rmU8ipz0eFvzLxx
lemm/IyqoM1HhDZe3SIVsj/0G9DxMwktRPQd1/A8J5frf2fvoutq91PXb6lPUzxx/KcLvbEydI3Z
/9TeKVw4hd4gPexXuZ/i+ut7/8Yi77jIGKrqXutBJXPTAkcxTAIrS6OZ3ynzP2Pbxv+9O3hM6yXt
IuunFCrmagXJ5bmzsUL/hP5v+1PQ5pHbCsoLlKHNuHsqB4NtuJvlMjx9FsZDvnRFCEuPq37fUq94
wo2Rn6YXcU1KT4VFFi1UR594gTL4zgt1aeC9YHXPiU5vfGZxy3H6n96hJUrzphi5sVSheSQDPbXk
ILJfknIeAbdkxW3HtcoS8GpecYUJhsvv/YSjaTsffN82ewzamlMbs+vC6lguuxs/33XRcn8ZJ9yl
ospK4FVHlKq8mPKENd2TfJjcEEHkoqoI7yOv6/1DxL0nAc6JA+9d+l4v8LoMzTai1Fv4BmwONmRK
tvQA++htPPBDJyPa4+XrmKrC84JCxeOEJLc6J1QCa+vcTOODAz79XdNGPgNsL9mIvbyO1Tv9Zf+V
0Ih9cFCPX+nM2coZfWKTa/7sxhjo0mfnwwXi6W79hqub+lrCupIdZ89CnCNtxRDTdz4HM8Hwlw2N
qaogsK1d54cF/WJYLNDQVFKPrfcS/AQy4iKFAxkuTaNV2cFnGYEtOrv9TEr6Q9s+c5kVivbnTvcf
WkiKGsnY8sBCe8H/7abiLTn+71pKHveMFZW9GinIlmf85x9s9uL2Wf/GkrT/DuefeZj536kt7Rsl
8pr61xz0CS60iJyoroZ3OqzHFk5+PrWun9SSmuEiSfcP7ETZmowrvv38imMjyWDFxf9kH1lXm+T8
+9bEaFq2pTqMcokIXXqVRJjyAbEkSqTZzwl3NJ6Bo4L4phgso0mvYYI4d42sKNflUIttv35bUOMT
qeprDQ2AhPFW7Sj7dJ4mM5dG6WdESsP9MhFrfIkqqfHEsN2R/V34Kdd+nh8Vhc/lB+CRQCSh9QyN
3JrXRcgcP6gNSMw1vMJlQU83Dp2qYMKo6dEVww78WVauSAz7nZYYJfXkW3UZeX6lhy5gcoHWypYO
BBs174Z9WpV+P9F0OBUYvMe770Hhaunxc1ek5poiHHQbqrvaUo4R+W4GnGHh4ms6aMLWH2hnxNJy
3qjEwNcOEdp5HlujgVIn5EBVDw9o6PEhtw2cs8RA64KA61bmqrVLptAAL2lsUL7nYEwdHHQJ+MYY
C7vwg6zGP+EC0NQtcKPY8zbebeM7CEtBFX+mNQoJgtPHaworrxbTppyN88OZf05MxK8FuDiOFGBH
70UaLMZiAoIkuBlA9Ghu5/K75yJpVDdy+bieNPcGwQ+83iO8xA8SnuEOUCDC8r7LcrdySLIW1mbq
UA8ecjaTUHauKI8Gqh9e7tKoLe3mARkF6N+1ubMCODuH21Oj45DIpwVwxqGoyD83nYnRcyZkNGk2
CYAlAd4ftBRmSeqDvj+gZ3LmvDWcCpR28YHFCkkf18RcE8NeUrqFW8WwK85zntEjGP6JCIwYdpMf
iRHamUTy2sWw+bg/N023wKH/3ObjlPD0AzdLnfm7HdF+cbPVxWJYFcQmuntcHBW1plAngyHepAHT
eg1eSz/NFKplwe/gjSe1D8SOItoIetClm4OomYaVY88VIgerdkvkCBs8BpDg4eNMOWakC4HnjF4P
ktCuWwswFssWRmHgBEuwsUsM6zmuURcdoVsYmIbiHA7jtBHw/LKV9IF24H6+w/IXwmfXgXWX2uwm
e6M/uUtXonMPrNQiLun3HLAgUFGjcM8scGrqwz0HtqSwdl+iQzKUZSBD+mntbDJcd75YQCDg1gL+
20fpObzqlKMkhkUjR5r20SiELL8GUxolMQwhFPKB5/vZRNEwXsKUwKdr1HtnyY2ZQZjoNQIJWtQx
+ldCA0z85+MNrm6G77tF7Nyg9RlhbmfLnwt8cyIKoduGSqJNBoI3LGRj6TRzzDQfqAm6m5f14iTe
JDraWzTyr4KFJhGkVBD440NVE3Ch9bo2XDNzuBcn939xdO7xTLf/H9/37pykE+4o7kLKsYND5bC7
g5ySJOfDKuTU7JbDnD93J4oQYiFWOeWcwzYMuwuJGTmMbLblMHLYxmQz2z77ze/x8A8bH5/r875e
7+fr2nW930td+HXC1ya3KkNXVs6UK1thu7CKEZmLKFtA3jT93mHwqpbuJ2yUkncrH9qmD/6Abi46
XoTL9CbGe93NPD8GutkwOI6myicGDl3ul8bkItKKsaFI8ixodTGWY35NI5sauYTZz3QfKUTygeTX
FwTzEshYO2xlRzNR7Z7g0YpaNFpLjFtP4NBrcJ1ZnMJFfdXM0fK6IuqqlELmxmKuFfnhWPtaQoQE
6XN6R37/bmFeLo/HhTsJ2jlECeR/tJYSfaT94huFbq8768ujtMHaHj7yI6jl/2Q24HdqiEHAkD1N
cKdFH5r60DnPuST2YM9WvV9tgXCDSmE1ePuqAIjVcFAEt/+oNpNAmMK/RtHnSv6llJYYv174k/oy
jnEsa50wXg2/Z+sTVnJY/e8PUXxWyN9rguDnStc+4ADffU35UKQEUv+7BD+sX7UHfpF1YN++8gll
UFDhSec0857GbK8LPTRKGSgwMHF7L9Qb9SKJNxf4B/iVPje4+iqU2Qtq3FG6PFVk842AhEdX/sor
qLg8tk8QrPYAxie0MCYQ92tmO64LVVLn4sB7lcYSiB/IUr13F0jUKLgn1nBKZCyBD241nB3AhYwJ
kHoLX0cinqMdG9O2qLI/JB72BVWzakZB1r34NAnkNnJzD5p/mBFjXY50++4gh62RJ+9VvWNj4Ex2
5EjHkhBNl0D2X+On5Jm0OeyMGle+M5FWPZac4oRPUz3RS7HrUSS1AjGf2OFUovWHF8P6+ht1qqSW
F1M5RLGffoMEggheFL2TQHjDn4Z9HUsZ8TWu4yUWXNBv09yMxNj2HPy6xGi5cXk0Pi09cuXF25Mw
NltA4OQtGqDl7ug0xP9d0fb8XoBCqsbwRAtchp+AIUO0DFKPe1VAVMjHRx2z4q0euJ/88O6SQ+HF
kezc6gmZYMsHP3mliRn5lYs3ixNlhTuO5TUfNY8aAgPPfbaGriykTe1iP0079+htg3P4vhvcpfT1
hDV3g1+B1Efwj1R73a97xSRNvratA/4xky/zqGBimzCbpBybDl2SZtR89hBxCzWiVK2tdUS3sCfS
q3QGlC/P6jyNwIg33ryEtQ/QGdgmVGPe4FlSOi9Il3v6iJLz5YClpdZLcuNfouu6/sqqRLfiGzyc
8zBtwzblx3Gv8Q3oyVoT213qVmgwBjtS/pdH0/WFeoMEWI/+eRg/6PVB9d/fau7lXnJxRMdkGc4u
K//w7bthScQDUORqdYpdjED0ZoCzBYfC+6/E/01S6Z0yke0Y/Rh08THlat9e172P6xF6oy4Zznak
g3A1Q+eol70dfSbYEOrtj5CBdWvWXCbd/00H09d6H2wNzSYHimyPjni7ZS11k/xl0yeDepu/F+ft
0nu9tEtkeE33j8BjiYFlp4u50Q4iqdFZz9NV317GGyv42PFXRt8/h2YABcpoUidcnmiQ5q25FG34
daB4whXzXzZWRxORa6uQGzn8ZUtdspWoC7UeR+A47DMRViOv4XcdqRM8eYhNYB+OATC32f0pH19g
g7YfYGfeHTkkgOJfhq6PndFDXZwo1j4ZcX98dklI0OOIt+ca/htr30iZMPxPaPmKgT8l9SI44nVL
y/CyJQG20KRHxiQ69E48kyqKyA2Nuod1jJAduWdI7bT0MRrgxFN6FLJOvu0weMlbbHHoTe+7M/LJ
i/Ef477wCoLa1Mk4Cxav3t4B3V5kWJZ3MHVx7L3oNFBiHVy57d8vQ8TDDHwM+wLvLwlkrbLYdao1
jcFyflXXRMPNdMS1L1j8nWf07OGOPE1stDr3639Sc3qln9GPalXTBg8oWl+tVE/qhWWcTQD4DY7A
F7tZqyE7tWbf+cb9yuSOn1ST7LcURu51+8a/pArzvErs8hllJCP3mvhPvQQS2iyBIHckw1pBQusf
1EVn+4cvv2n0xnVlrVd6q/nH1e278NJF1iyVVLntTP3PNVYX/NcNjoHDHXAFS3YsQOn7XDAMc3FC
BWt+kEMtV5Vj/FbzENOoGBYoz+BXWro+G3K60VbnGvPsZWSID0PYBZUKis9V5sMPLiinF3eEhwdy
AGbZCmLzRNUpPR2N5JPSuaD0Ia6X0KXJxzka2p3V1piF0VnXqP9ffQsX4+s8+slavXaWqLLm/vWG
xUThsEvi+HEvQuQpNSgrBNT6bOizZGyyJRoASQGubq5ef76Xyt8bBsBesskPezmjWG2d9yzIpnPk
8L8fX74el7XIstv5qsfOZbbofcLyxvB2mM1bpyiSXd5On/KRXs/vx2RPfkjerfDaMfDLvxryjKhb
fx7sUKIxsvZkdal7uFuRebWi3U3/83JJirOGlwXmJaJDEeop0Q2zqdmRrM1C66qy9ssSCOvb3php
lObou3L2brbAnOXy8X+nFu1KDnXC1x/a3ibrmg/KUdTOHRcAHMMIUGOIVWPqFRzYQEx2O7Z59i+y
Sfdi1BJbLXeY9GNBiHwgQIEbNSmeK67kWrW2NOoS6gxLkGPHQIJ/YAZVBUjx+B72+0+rGNgna579
J+P83ZRuXD/slEewmBGCmXUvafGgkZQkkD2pHj3Te2x5jHpLHi/dn2IqDd45VyxrgvwC8bFLtg+l
qLBC47gI/IQVJBHA0fXzyAyTQHAJ+rMGv6w/BLnwvP3akjaIpBdgtZcEMn4bZEWiVCwWf7kbcjg1
CsDvUhiP8CTiH/fIInH+Ryr9a37rC+OlygOLWVJilH5ZCpvjGBeCpj3WI8HmhP1Hkc8bkYRmQiJl
Fqpv78Xwc8XqWBHWF50InzRyMoo74GFHszwtZ4nCNpKUTJAhC3PqK8WE+XqLwD3n6DXjpTQ1gKHF
0CLbAgoDR25eMWw1hvpJII6zIc72wjmO49NJCaS4F0Y/KISS01qCU006CPDG/PhW/v6i+A/n+WeN
GHnv2riNvxrhNtbtw6r0VXdobjusDdusnL7fNjbMkDRxxlOA5vbbUV2k7BNZEDEVm1/bkMA+lDwm
vi2zerVSAvmjiAqwCLyleM4ibf9wmcjOgHUrIMS3RVjNJKoMaIoH8t4vl5BZXbS2rq5OtD9WoKCv
GwklcmuJOIHSfxLI05pwbDMOh8VhPNLX2r05+eAGIic/eCo/3wNx4vxdkMciGJoD4hPQ9X0HaJ6m
MeCMmLFxK57BFlS6q+6XQGbOaYrDUjaZd9bxFoARVxe5KUdy6PE0xjrLrnoRqcT63Nw0PntHnz0W
JMKgRS1lqhiSvrixdnGkt9bOLl8nn2MtzuV2iXS58QurWuP2+2GcZ+32E5dmNImiQ/HoRcFVpMoh
nK3X2dn5SJ0sjgtNTEbg3eQCefHIpU8SSEWBy2ZLqDp4nB0QrJhZCEOtSi0jI6YoPmGNmWlHbHHl
GRNF2mIGmywMiC2c65BAvqW8mo+7AqboVmdXJXgl5aGR61TkihPsz+vLH64cMTm+ueC1rNQBMghc
0wLhoJvHLIwtgWBuMhbG3NMYF3CbHTqCNKFhWWBhGDAj5XbuibXOnuDJxR1JzPs00L1RJMs8kVpD
Wo3GO87CJkE2ZWpmhO2HsYVl9aaza8iCoP7cGsY8dtid2qLjKIFUw3Q9kOI1d2mcKwsH+QAXJtrq
tX8wSm+aBWph8wC60TiBU6tVHpUsgfSPuDPC07e6QLVwdCd/QU5dI+sWx7pZ6FQZHbbJ21KXyYhJ
SRlnawpvoxeNETRwDHzitiqB7BASRChjceu5pvVnUTz+GcqXvjrr4L3rUm/FhGX9f8sl1XvLzigN
Qu6R9jj0Wekfm2XgmTVXHEb1I+CZXj1zBsG4CLnqhXOuGkkFYIoqLYUpCAwTSucV7lo4eCBRbgl+
H7QS9bgEbS6OyCWuqa6jO9Q8llZ9uFjpTxiGYc7uX4tKizM87NStNRlOoJZVhMlIs/DyNxDBJyTX
UmKliiWnD9r27ohV/27yQ3+DsJ4rHvcQE9bliO7lPATLCxb0LTNadrZHcyPHfpKCmTVG4XCI2b4h
EyC6AsGCO/080zim4sxYl1UZm9j8jJ8bwH30S0Ff2e1ZuhiWrWIUL/2pvL9XT8BfTWIqSZViHvEs
McblmH/FQuQ887POL/TSkDuD4ZFz2vY0YwwODdjxgfb8a53vH5y7vsK6EVl0lyty7wmvk/Kd9/h/
bBmRu9ic8RGG+fba7jxaSOTP+zW3u22xGUYsyBQGxdd+IdQm/4xQMWzL1PWeMqT9eVynlp/vT6d6
bX9fiy0oC1TV3KACaFDgvmpLTMHnHPQ0yDw4iJ6tlDlRhFTkbOsctOQDo2c1JZCD18DWDrOgP6sx
Xpr9uGdXPvX+TwIx084f0qlJfB9/dOHV0GVqUxVadoGS+vqRj3XxvxnN8m6V9WMPZkaqcmZpntY4
0xDGEFr/JuFKGhbNcie9jU2w8rh3K/iZyhwRWGv3J7nJHu07eKSymLC+ZmTlf6Uddg7KuqXO8c1a
+r5jHLMj498YI3JNg11b8sa2nHMj8QPssYyn7fujMzW6M6Eps+MSSOdoYVIVqex6Ve2bASfz13kH
LctXrfFHg2SUf9S+d/O5sL0sfO+ZW+wrlytDZo6kO9hXvfG/GPeFDlsLAcIlkO+jRaed1F9Byg9M
+NZXWbmlQapkWDeUP5zD3XG6i6fXY8ThE2xc0hthBr251e7MXzqpPT+1Vedd/hgcvQafwrR2XLvU
7IATlrsVHt11lF76R7nKtYS73bjtzQN1DKsbP2YQX4vrYhd9/ko8utSDaQaVyFK9FAaQ1DOhuHlR
ba4EoguMVzUzdcv3Woultg7Pr/j0+NeEIFiVA1vXsl1HsABkhAqNgWSmby7+6FpaPV/EjE8ZK34c
UGGcUNV5v1nNy/bFcL/jnkFZ6FJc6jwucoAtZpG/EBERcqTjeW8pXs92+C+zwaNUgCYc2d1tV0b7
dqyO673vXnYenGkOyxfX8oK6ct5vAQLOCvTVvKsqj7yUd9f/L723+c8qdun4M6EEsgD6KRNopZYI
Ew7FisqvjySXvghg7630zfLszLx6uFrDlTCXIwCSIpwbRp615txjftgxQL9u3+wD41WmCw27c5nZ
AgLPPcbVs3XQQpWOYgMRhJ+wyNQv3f56dfB9eP/TzJoP48zs+1xCm8NE8PMG2o1aOO8e4cSwcJQm
MglObalvxjHH2FgGDcvJq7Tz/6f8ldTJwqZg67Kwxsx5ceyHi1S5fVqBqOBjL4ojBeZ3+UFsdM24
rb+fau6e+6eU+1eNxKOISZrn8UCXW5/n/MLENEarBPJviZHM4WIvwTieCTvHnBhpK2kBTqo8N4Qb
BYYkRGGj0REDDEGoQ/8oX67+gtrs1lQP6HFW/NoXD1d70/yHn5aEJO0HNhiEX4Vu9/g0sK64DAd5
CwlDYsj8mnJ6A61M1Oic4xKoJqycLZPa+bRRr9HybZUC83sC8wcmpoTJZNUpBOeck28L3tJqxgLV
J6y35EdK5xzwH5BcKjRVbIeh6hFnsHqM/DmQZfWtJqLppufOb2fOYjthbS32ubkLtbxWc4AS1zWO
E7uscMaTm2Mnw7n0q5nGXNBNQZehKWTohg0HcE9EypLNl9PquzsV9rl5uPeErl6Eij/RRIY5etUn
hqdwtt/eofoAw7ftLPSSCHM96jJrKnU0Ctdz8HpdwmokWcgwomHkcc/Yerrv8/vToGa591JxIfEY
F9z4FktbMrzxh4ZFs4p/ATeEtqpHKakOPkMMC6nzNLm6H/ngK0ARkrMRxaTQMI3ajWY1Z0S+ODmZ
YZs3jVyOBnRt3+J3d9WyBE7YLc1mrs5fn1Vc4X1Tf33Sa43o7WZ9f13I6Gqp/WV0cEHR/DbAMufw
XDhOl0sue517N1IzZFs/ewkH0Ktkndmn1g5rONMOA20ua0fNVgI+fUOpBpvcA48YsQhnybqwv+G6
1ZZ59eIiJFE86kx1NAY2C96d2Io7GfWYrU3FBMxMFN62RfOdUR7tj2fcnnsgs/8oAtpuBl10+ZGP
eJsJpYV3TwTpG6Drvj4qhRnvprsIyaqijNBhCeR/OjA6lValPytI8GrpZm42zZZtG7k5z60Vtbai
15k3jRreiAb07PWF1AT3Ea8tx3xWCTHfo6UTmgryOPNXUGsSSNZBxKIEonF+0J7lMFy55Z7izPDO
8ufFx//VZhnslb1uYYHL+1/OpOG9yivOgbnPDjnWXYfcDNxZtnv3/+wPTdxKhkTVlH3Z2FZaHVju
5WWnpfsyiHoP1CUTXUJ/2qYELEVQ3WqOJ7EUCC2rHiGz1afia5cffaMtrcqh+EHllagXzG/EDjjI
sSm7+UfyP6W3km/tB+xwyQsLf5bmL600yA4BkS21B9e9qdIn/UDHGIdmajWi6XEuagHJq13CrvRZ
IYkf/N3UrXJ+TJHn/qxkAqnqzwWQq8B2CmOCd1sCWZyTQI4bXC+U+2TLWCKcYJZQG1gEbleIEZuK
ExKqQ5VK0D/07uOk3APH4kdWvLIY3eXxmCEN2jlXOGJ9nYpxEeIBSs3l4BRdD8fM4Ob2nq35jIc1
Ekj+ugvczl4Ylv//m+p64hmXN+TDoxu/FQIsmWg9KFKYnWaXghe3zDO/hy+2adtlKgN13t60aG+P
c0AFyButufbFVkoB/vlzGI/Xq8BizgKNbHpFeXGF3iEkBvinTsHwXM1lFqjUHpXAEcHW9/hIr7JL
0dR68towEBp89xgXGPWOI81Kp+uzoGB9GY2aDHgkD005R4/rxWOrpBa6y4mzbhteTBjByF20bh9H
1MFbsQJlBL+d5ZDeOeoSqaAwTDJscLOWQHSy8+MAWtEEXwJpI0og1IcSCO+d/d2fQnvzBessAPUH
Ub6Ghc8lPMuroK+H6K+jCOMgiZdr1HMEzhUR+GTz1S7sGA4JS1COvufq1L7Kgk1RQbIxeAC/09Ea
m6qeJ3NiYomhbfj/9YaprQSxdLwf6F2i5KQHymI6xI9NoqYlkFuD2HmYuPSjqTHC7yMRocqDEzJU
RfFe9ifmEKh1c4541TlEZF1iyxMYe34b289KhOo6Ha/IaRlN3eMMW+HLjfMa675Wbh4uj424fgH6
Gy2BBEvR9XBueE5OS/+3uy5PBm67MsFFIwYviJ8evhgsa+lXdWpPgiegJc18bigkFpVXSwGij3gH
EYg4JJ3mbOpV87mGLhhdabFkfgBXOXGVIElqcfTUwL8WwrIZ1HkjRw83a15UXGlD4H0hng8HVadq
oTUVqgcvKf4w+iKEwymqbfxfQtUx7iPCT6H2jmFM8AvdY7nvJBCn2W48s4qYIhMcD1ti+LuZk5VY
AoAcAmp8/K0vTw087d2h0ZqlSwVktFgViFoJpLQncpAN6MMJ4rOVc0lsQZvUktGloJew/3dGSWXg
qNJFy9Iqb1/ut0L4MPDrlN2KgZHCPo3G0NpcTEIEDL8ZDSbpB0pmduIUQN+FXnoIh02GI2DgiNXw
0rwKQ7gIbnwI40PZmqCtNAKwaarCwOJXVNcAZ76K51kDPI69WQOKL+XbR1W6Uv9P8HvSh3PixpE3
3fJ/UpnF9JGq1Cm+Rir2G7WCQLyQHPz3yvEAnguWcX+1fYxfvFlnBSSZAwll6/EM0Wuv/bWTP+CG
jEMeglfdR4BWQHvdrcgeJQqSO0TT6JKaWyOPsmzN7LlOPFKPMyVN7vNu7tsx4hfl3cCMgO7N+kjC
cWooyaBYX997kTjeYgd6c8R5Reh1KG2dsKy/OKldZGKvLFByv1LWIUvIHK1bohBM7cRiBmswcCbQ
fF8jPn2Jo84lzoWkixF0r03m3w790gzsW08RJrjOBoc/K7Kwz85td9rcGpJ+IJqi0Z7FCxA1KccQ
m3FsUJ8XuCrMhm5Oln+TuED4j2VswdZRpdKScw+47bcFSDioD2I0k+4PoztPcuqKMqEoPhAJ48Cr
4JqdmfORKAXv62FXQvm4EOmdBsl4+SyhKiNzlkEOu1tk6E1llInq0kGK3pXWNqvNqhs5dijVldPj
+BBaD54N/BdsubRiiyx3FwySDnRLICqxkWI0gha0mpKaMDs5namLBT0L7+kAETAhOdJegb6U/+Cf
qobuerdpWlt5LGKzYCsf6NpfkFNwtA2T36HyQwKJOCyBBPJvRUXfxbSOTHGzs3MT7vZDaTVa3V2K
kf9E3z2WBbbELxhI4cB7ftZNbX9zPmfX9kChvVht44WZnVBWozrCzjJkonv7zMPQOq92vnjVccGh
uzwwo1smpec4nlv09q3Bv6KBYRy3JtDUMVZ+BGf7ybS8bgzRgxM2ZkUl8xwgt5PlH+HevTAKc2RB
k8TxH1IlkANu/teG/C0s7nlvt5BOanCLl1lBldFZ+pWcc7KnkF//x700LjKcwyVotLdjFIaqvG9K
ID7skaIu9/c7zh5DnLwye0hAMSN0jsQipoCowisxn4eUzQzj5u8wtA/4QGP+ZmhhkCtBZ3LLni2X
QnXmxAsreLsQbr9h8tmX/7KdMoylVjeyDDdWW9QSm35akGaOQEWc4Bwi1NbfSk1b4P3ZTp2Lnz9I
8kPwE1gOUfCSJ+Ho6OKU8IeAjDGdemOZJtroGtiwrc0VQfFUJ9Hd0oGgBSEhkgxsPX58rejaaN6/
6i2Prymza4/Aa04aHRE6ocgIsFe3L4m4RRWJE5LzCU8WHZoG7JdTey1KXhxBFy72HvkN1Y0oqOwN
J/mxDDgNx+LpAShk0IKuqX8INkM7KWfOX+3PrcLB4/Cw9+Rj1tWwhLOEs4U/a02Vvq7o8r4df+H7
o+rdJ86ToWaWRyfOxQ0iCM7ixjrrsktCwxpYumrTQgatOCnEsTTpdn39M6u6gypDto3p4nzoq5pH
Ee8xV0M/bGEu75CmCA6a6bkN73ERAaDE1Yyh0uSN0T/iekpQ8/jk7x4FUoEfCj537qO6iZ7ZUN1U
Gu2gQ/PVw9ybj74nOGVIILu2JWVjDdpOjguc2m2qCo89u3Y87ae/MPPmK9eGyaGBmi/e+m+uSSAb
O+gVkBTSw5NS33E7pH1OtBsbHjU1ov7NbfK1BEK8dIohgdSTvfw7av2OFV4wpRc/4e6D0kv8pPkF
FhB5fOX6mS3aWnBSfx+Ax77PtBtDwtaYIEHIOC4i0ASVardGSgNydrhM4hJWcMbiNYdoHOBP58Ga
QD4HWK+Ajf3cAfvQAQG7ky1WW7+p2JuA0XAal2yySzctNW72f1HfGWzKRRFD9+EuvQ+O+8VFUhnw
j6Qk7kJ4IDNmAQw2JRM5Hxaojnz85ysS72QkFc0JEeQUDdUU2RZcOPFMt1iHxVSdlCIb+fNVfd/8
B8Ga+eAAvXTCcOYAC0Vy24RWm8j9DC9bf8R97reUEA6AE7OqV818dOquaAy33pVijSqfH0717NeP
I6f4JtoLZhkiO6+mdMf9srxHaggU8jXmhsuWTy64TAbLY59WPciHfsaxB0N4OOyGoyDw1KqSMYKt
NbadZzy6whwcDHxF8bLl/8/gAq4VeP2kFdOEbW9usiKr8htEL4FWgpqjAc1mZ4jfv/EcPXkJxK+1
BE70hLfnAuHmVqurcFoBwZgfpFpHw3zGctEkkGVsNBL//WKz/s8X09g371A9zQLoM/f7E+UttR6L
eV4YZmvai5D2mDqZJ6mfBLEETsVP1pIegnm6E79Z+dAEaJu/ZfeB3q1z5jVdSrgVXDBeAmGzyvmN
W+qEwA8D8VVc1hGcxz0cd/yGlMLEwUBkgwb59aU6pRN4J/H0njjG5oKVq6K7+ftAXJ+TIN+fPeMi
ILRQg3Y1Cp9Pr+6llXOxUgwH17S/FQ3pYrQDWHE5eWTHJdV4dzOp22yq5pdjUc633OZLNLDjCBAX
ViqF5IjggfuD7Ek7hv6GNPOqATv4FR7xOxzyNLIj44jNPv7i6VqhthOH4v0LbVWgUdeo2JL4ztf+
rOuM68hbOeJoffj46p7B1qlTdt357Zeyhe2YgqM172wkEBzfoX0VaDmZuB29nq0cSasWL1wokUAy
s+4toV5hRq70wbR2mjZHSaMa5AimGsNtqecNz+mjD53OP5UwQAjSQUggppRPspmNmTqZlir9zeXv
lsUkUuerXfJxH0XDaLZjaSmBeyeruUSh+JX3fObhe4z/AYbtXuhzEghDyqgYhTrgENd1yupGj1sB
at3YFs10OxCoeObbftezLWwGGhUknt0s3vdw3nFKX59Pv0uRuhwHzpMf9zH/ZAVxNHPbTMkCQhJc
D4+U7y/OLG4Pj0qR/gKSc/tcwGpcu4eOBGLU0SAcSS+yMZ9Wz09wvg0qDXwQdh/or47MJBp8mgBZ
GUA4gS2mNQZSity+ctTBkHs/XonIbr8DFSPHXDISRLb8HJRQ6Tp8oj2ERHdZgRcPOl/Y7WjbOIh9
V/f69er1rq27g8x/ixzPXN81XWl7+9Wq89Bjy6nkbYf2fk4+de7vdzt2u1+6UfxfRNAvd3k2XmeQ
+kDcl/AgVQ3u5N5d+/e6D0hwhXEC652GpML19zRCFyRqX+2vxa2j2GQbfEK+Bpyhe6sq+dPrSbuS
0hOuUh9a7FrkxZ7QqoYHJ/yJXxZ2HR3Y6FGjYYDfqtU+7oLCewK3VWgSgl5rt0KxJlxrQeCP3EQg
+KFe+5gz6eI4+bQQ/e0TIPNEMy5xIYBfkg9US8dLnINgj25jVWFvtZ6Lq1WV9a6NQMqzGwKRCATC
EG+9h4FYhY4UW+FHm7wioDjRldCjiT1K0TB/EibBicYn7HY6tswFYmn67zOK5uuCHn6r9+oIyOgm
xBG6NnusYzxuRVlD6wmNcI75UDuQgbnnJ5BAfjo9QfiDuUer0hv4iwetxYz8YMPIFtqSO3wNm/Vg
IUch6wofeNHuNYQHDjomaeLF81JbwL0l86cSOgmo+5DOUlSdf1BBelAJViL5+cKRRTlZQQ6MohgW
n0fL94XpzWUTxiWQ+20HwAUZkvd8jXnfBmLc3A2I4LfWcuLF5NzACnWKRnZb2biIGO0RFyYAQgn0
iqfm0Cd5MIF69AvAf2P2gof+LnukKbqVijiSEGwLdgu1LUVqqgGxiHq7WctQ48xq/Z5VF1hEFeVK
rGFb8SBbqFXKQfnni2zFlAHCyB27c7bSUaazQpBEJlzgghQeEpyKJfA44jbOniLNx39JIPaJJuUq
sSf57b94nQz2aHxtIrw1BdmUhzBitltNpTNhfErLx4jn0oeEOdHS8myqUPbVtSopTnOyN/v01hQk
5Bvg0nj08x/8hNfhJxiodcIKxWxArL73RPBOXX1w4J8BpiDfgygkA10xW5VkKR4dat/ab5lLJ0lg
IP14DtVhdEaoZsk0IGjHkysZ+/RZ+oi7QoMeox/Hnf2E+OxgqCBUdUWuvGvMK3gS7/ahXgJxA7MO
mnMm7Qj0mhv4WLt7Q382NiUMCjHY8KbyPwsPL2MSy+VFKNlz4vR1Hzh+QW5JBspC18WBHpbNkTip
PAesO7oOV/1FVsubh4ODYOk7kFafBEtj+dprncQK0PSgWsEqqCpuvHi2EDNJld4Fz3yciSJyzXkM
XnlL/yO/EormgFC8+fmLVBokENlLlTCqF6077MgA2BAGNKzGM8vj7CpcYQLEXl5WUKXxsoiwJFVy
FMw/zwnKlVLazFXcIOugVRpvrk/M5uBFqjQp3hkGf/E+iiVnOeBz3a105SO/EvQkkHVFofbtE2Td
4u/VLNMBehcfBYct5+D8SuYpJW2dQ9peWgIPxYeizXKFMZUTs+XLwjo+UNtouHzV7pzlp1HRFdns
9jUcvI9Bv+0kvciP2fwpW92zoxHYxmeTORdMy2BtIpi2EyCzEEm50byN1WGcpZjLT0C04oNq6mK3
0csMBhsEt2zxYfEsAnsUWJ2F8n4nYv3tpgqUbb5XF2G4HizZrbdKvnLWUkVBRNHHT4PhldC9nyu8
KAJSOJuwCCVrLp+t5VeafFVi5eDMWkfp/sQ/1KJTcLMw9nCIIfVU3LngktqCuc9qJkDYLKgUJ4F0
rl8B41Gtuh/GvX8EKdZfzjIkbHxkCnykftqt/ruBlDT2dYe8WnpWLWJoryM3zy5kvItKHuqwIXxq
ciMMtS9aigzNC6Z+6GDOs1tzuNM4LkDZHBw0o0z6UKW+O1PRZSEw6KLZ0wG/3R4lrZne0fozccQG
JPjMHTFJ1eVjCX64tJNF4r460XAIrK292a31+vNlcZ6RmDwmdcd8Aq0SvZz7d3ps2J6z8aVcs9Tm
9qubByCyL3SMAz9hG9ejrwUHUhQK5J8ymt1KuIN510BVQ6zodYDSiYLZBSP+vqpCj4R5Ar45WPnG
yoN91Gjkvh6dfCekNlyKx/nF6zXau0J8m56VrlKRvdSg5kkJ5HXX99rd5tkfiX+Md4fpEHRsNZc3
F7q+E/XycC06xmcuzRXnh/RqsvvZ5OemjgcWMmHx+cjeikoxDWMT706x/RiiQFXWWFUOE0sgvKAL
RUKCKF+kZnlpqkBndmGK8U2oE7bkZ8WrDxFi2uQxr8fg8D+fLBFLOUJ9FPiqumE9r1n2Spd12La+
/R6CywsWOfb5yL6i9cCDX1Xsc896PArTILzyG9gsI2y52V3hUdv77qP0DKX6y+1eo3sSNWg4YUm5
TvWkG2KgJ2TbyF1bSzy4xXO2YAo1vFTcwL1S2TPLARdveaznkmsUXDMdTATN4KIurPH/fbVgnwnx
igp6ymHu7F9RAPIZuFzNOeAuQ3Tas12+Ad0hP6u6nJlPuyxT7nT7w9PuZVFpm/nUL9j89oA3RzqV
V7psE6ZyL07MmQ/I96MeVtc9PrOb0JlvEb369ozK2qD34nB3sGHF8b8ipfBCD5phop4sBGndWCXw
bS+KVX3z7sVRPVgV+YSf2lzgv/KD/htxjAVftyENCaTUhhFTp4OxKmpMU8geI6L6BT601c1jt5q8
Yjmzzky7E+MJXEEwhvDTpEICEaiKsccvtqnQ9P0wh7eVPF7kV2bwzZeyb3H7POd5W8+I16idvog2
t5gQvGxpCfx8bs6f0+EPaokYFLui+mb72Nzr7iMPUvYcONfBBH7d1pRbFNarF0ogS98rv5RfbH1A
nJ3TWkeIIgt2XDTlhtwVjvRbVRELgmKLf1BDx9gjZxYedj/gdSByJJAouOEpxpu9OYdHGVfdHDkC
cvOk7AlloXYz9SGx2WknNLL5qNGUSUoE9h/mOZFJcOvgm/lXISl/mAKV1QfXCbXMAy4XdbXtksnG
tfS7ThHOaVPBAZcORz+GTpLC8nAvKSNA0afVM/xIMWX6xIquKOvw9eIeQt+A0EluSv8VeZR+CtHn
UATB2TR/o/KfwddzrhzBLXd6gKYHw6OVoT+hLJcdYVVeE9h53wES/h0sryBiSkb4UyGwYJ0nJPBJ
R0DOmqi4gJb9Eho8NEVd1cvgoXnGD6AxzTeloXf/74e9JFOqiMABtmnUPr+PbVx8yOI5Y6WvmDE6
a6WE0FtPOA0QFbPAbS7msMWRvaMT7q0TUrL+bRhPAMA8p2jdnxdTX1sKx1RjOSwaN6TmAkampHkV
HvcNJkYXlBMoxhJIwOrLzBcSSFt6Hgr6RfaoZcrPH6P8/QX1UPa8YQ+0Hm4gBNqHBGFEkC807KUx
YBNAbaYlVbyhx64t45L6sowYzS2oRpjgtDSbFhdgKwiUGP/C7wL9IyoI6Ias+dBR3ekkE1zVP0ta
1zarZUsg3k05zSMk3IkZqtjDTzpe7bBvw1s3ChrD9ON0P5g8v3pAnLLfoJePwPWCu4yXSWDvCA/0
6k6uucbkQtMiQAWpURqvfNZw8XERBodulN6tfiRDFJn/v3Y43T4P2qoYAQ0goJaSu2H+QdUnPimZ
VR6R4ZYxsqW3Kickl5V6f8l0UyfyHn73is9TPE+pwfvA1uWjf+WIerits/b3rjjuJOT5vXxRnL8e
rfO7+ZW7ZiCzM9wNfv34aHDlx0hLtThGiwTiujZAu3K2e6broLoytkFOELSGilUoCvAxPj4pt6xY
saizWl/RYGJ8IxC2IXXHRiasy1G6LPZ7C4sCnclVP6mxBKOdftW8R9/8hLfKeJdGQ3oL0AuRmn2F
MKHTHK4lskz6HtXTPapCste9ljS5M1cLXcaYRRR5n+ah2veF0yxj24PHbbXd8T7IFSDDdfk/8MFY
8oqAa1Cpao8S8apcG1OvzeqfPQ/CWglnxQyey3qlqaAuwkcwPIe6JZtv6+zc1Iw82HMk37SWJ4EQ
QFZIVAjPIzbV+UIfIlQD+wsEsgnzhQtT1ZN5C+GJ+q2/ZzBNyHAJpBCIXXcCft5ulmaf/6ybaQsX
C4qDj7b7rObbZ8MQEx4vxj387ndVUNyf+2Tdu5DpTFWdSA83dx87I0ZHeZYO85FAA05IrbgQjn9/
/BioMUGgUcWskTCv6Oyw0kay7tLf1u7QPKkvIgOR0KmgNLNr9OG+s2/q2fi42ikvKs4wDFFCq83Z
wTEdaOlZ1b3wG19C5fsKsCBnVlAR//OiEfnuI3bxCd0qKJIp5k1Q24NS16wy3WqMO3BEgZEEUi0g
JH7Kv/4WGLafFACJGb/LpXcfi6A7CYn2eZd8/sijndo3RKAZZpTvKjIYETzb6viXO/wQ5bLGDYyv
UkViVYmVZ0Zg4IfkTwo5+Xkn9y2cs7Y4seVZQCAOh7UHn6lnWDH02S0skHWzhjEJiJI2W/TphcEr
S6RkuYfwOzPrgsnwP1yFJsYskub0v2qzu3TbcvdrdGr7mt/UO+SRwMDXN0+4JVva493PHbX8Zt8Y
X0TMQGrm42dhPKSz74FovXo4A1dQzQ8ebpU+iwfDjadygVF3C36wN0yKQdSJd6EKo+7VnSbv06Z7
JJBurZf5U1Ba0FqbnU712lHDW1NWwDQZXj0Fo5mL8XyXg9MpV0FacxoNSGe6/norpZQWh2el47QF
R4Hzt2E7PrY6cOKXUjUGP2G3JdqG6m7H6BJTSJicqcFuVMthDz6MhshfD24mqwq39x/dRYhXb+gK
fUgC6Yxs6Hhluv6JNgHA4qzf802zmh8rD8DpK1tuiR9FoJBCAr3oxhAnQpEKV+7BII35wUNr1Xod
zmOO9gEz9r8NA8Z9xUNwe3x9eRTSL7v4nzISmKFlxOABbS47rzAkkB5AeAeEid78hIfj8VQU7hnS
ihBT7Rnl75iskR/0rYqqSIQzjO0ww/HJ2rr3p+Th6IAnm2VYnOZL7S4OVukOooiFuu0IEaYJwZZA
GlrKMlU40DXOnunZ5dKikMzoVESL4cSggHBxs9lEe8Fkm+Vtu+9LVHAYXtNvGx2i2fas2jcNaDBo
8NRjEdZIQXI73ScoJZ0M0/YHt6LPSCC7pabCaQn4zTiddvS34G6z0JSAT0Abuo2FK6fun06LvLaq
5mYOu1YalOElxgz5IqB9QkKXF7Tz7osHhMVepS7DpUYg+OPgf8mMpI6Gnj1ys5ZgJqEFNlW1f7Tt
jy++tnYHoBlKVl5IIExcofil94JYpsM4hrWU86m+e0Zv3hfRgg8q412v92orhs8KgBhppMdgIgq3
CwypBHpc++1KPJJegVXcH5hH4lCwCfxIBlu8IDUH4vWUojM1psZmbWUUJ74lCCQNpUhtwMDdQN4L
dRgeD49QKlmIz7zGUOXMpPSmAklw/6he31xdmt5+QiS6JV1M0ezZuRmFRZs16YLNdrF1ctjWmfLw
3nxCCoJbaX50eXFRLhz0R237wM6x57ezKRjdbpGjwifBi9kQOFHkVP7TthM3hMFEv0+KC27o83O+
T3Vih9nT1u9Iyf+z3RaWe+tFr2KiZh5Dh7BU20eSQOKGgls0sJm/Pk2Ii9YPR7IiEHwg22M5guK+
nkkJLHGdghnHZcbT8MB6RfmUcrqJR1OGuqUEYjVRr08TMrRvEwRh4snfCYlpdZNWBsFXV2skkKHW
p6heKlcqFpP2nLPDD0zPPNgwiMmmdVxu+DavQhYkwKYiwUWgwRn8C/YZCAvg8c8MKFE+gJx1WJvG
aNHWQtn6eqEnLCDN2f/JOjayaEK81DbQsB8qiPQNyNvBK6PA5ri6Cau1K06p+h1QykXCD1NSxtKq
MVwgTesN7uYHRnWrGu1uUWyfTxYCa95+mkkRTbqGhEYvGgd2LItEFcFEdtCwQvTnzd2QBNGr+Nx9
C+bKjSlLBP9MKxE1vQGXzyfQK2PKnlbpHG9JjyPqtgaBPvHjAO2jfkS+vtEYHx3A5cTNZolTyWFe
KwoFoboTGRPRYNzuchXGGtx2ggfzn0KBWfs/SEM/Vm7pgqHyC9V+Lv94LQ3Gr4DuXb8/fHuoNmSW
MWuh1ynA1vIrPLyQN+xklm5NJPCJVLAmd1Ic8mXs2ohOae6QNdMlJYgtcEY3D0CTJp8TBMfTsj5c
iijvQRi/GexWPvuVoG3EmKxEuRu93UjLD9zdCjdNRu0DwsKAmGqpjx4+Tg7h3F9VowXPfOnFY3F8
7KincaTCRkE2hWRA9xoinTsrnW5YTk6W1IduNgOPf7/mSz/1vboRFf7Mgw/HRbIYIEk6j7/M+5VZ
GtGE1ZnOWcIqhlDXtmYR60JACKG5mhT2AQRdj5YPJFYv0LU/tWK5027Q6PuvNv/0WSAS1dwjBk5+
a+TspXhGPTRh6PO5nqaw2HUgCSF0cryyzKAO8aJ9xLRaqdb/AbLs705p7wwPDj6x2kqNrW0UESII
42VuUTUUE7gNPWBWArHLetjokWBTG/b/HzDPWEj1TJ5lYOXiYqUBo8EZ7opjOIWsK/Ctadih8/Y8
7QMDTg2YkaJm6rnLlXxkHMmJvYbAeBV/BiIzQ1wXlJOaxcDPvyNiNty7Sz/t/ytDY7wNSBEvTM74
dcEXWn5ffFb34ni4Br8hpOafVwOfp7LbfpoUKF5K5ts1vio+nLnY2wNy+AC9gpLwJGSj5Esv+teg
55/YGIz7MCYqnLX9G4u+DIumw3LBqKr1uNt1E57W6sqjgX3C2ywKubYZKWKA3zYOo057eARZQEcv
zQJyfADvLIIjZHMaDM4cv/b+uMBFKrEV7iUR8fDQ6LkSQs6zhplKwH0M35TSRcl41cHz9/NiGHFa
8MEmsXX7+7e+6JRR4ZxpF4czlhNfEfNfd1/JBs0IkZVBMbbzPQcbPxL/pxzZMbbefv99nN/FI2+m
1duXgP+MyO4KguRuO7/JlbJ57PCLY6uqoa8FwGeQZCeB/CU2B5lUrXodKVX8O3ZGP63GF2cbujX2
ZlzZbEXqlDAJV0j7+WK6ACfqFDNFAWF7Hf2/ZLh7B/HDjLpdq32zzWHTIF+0/WPgvOoLwx9qUhgS
zGMSwAFesL7dyhGKL/9g19YLhfqaiOUKY36Qrqpj1o0RBZZcNp9AgeW9BZiMdYB7V9md9diE8jUf
AEwsFIk4Jg03W6VMjQ22zDs6FF2HZfDcG9fa7mnX1kXDhd+UY60PiPC4EIGxk0mlUPtpFkeQGT/L
Rc0i+Dgp+iZtrF+LyNuaM5YXP0DEHDCE6a8jdezx4MZHgwIF/U+BAtS3zMV+FFK0xs1nj52C13i5
uw747f5aNwDimOJpqenjJWiM6B5PNKQs7tioPYN8QBNTcCelsVinJoFgTVJkofaPPfjQaCBFSGie
IHsP29XlXahVZgZUtUopY1m/Taq7Ywf3Nsdvre+tBXEctiCb8NPg98r2ormes4SNLgoRx48F8A3C
xhL9pO9F1cFwIytWcaI9dBY16wcuABg3noMH7ZJmHh3JGRZvduppcNV0aip0LUQI/PjO+lkIYSO1
2pKUPrPqKJJA6jFH+vZOTdHl6uO4xigmUVgqgdzOT7hNdXa0/CR8cEbEWGFK8xyXeH9AnFs5EGLY
dm1h/K9MBE1/eYRAbSG8JrTnI1BMgKrPDqHygwSgPnKDqdgSgXX+FJ/Pj816EHpRYMdtMCCYSyDr
sm444ba2nHcr3atAcQgXvC/srav+x3kDWxR8sHvPkA6Cn5OiXe3MiPWIf4+M5+i6lQsRK3HqBZld
ZYd9bR9LBzBdA4WgS830ZksQjHP1gS8KTVyrwIP2zVxgDscQRAKY+tbVgbZVb3t6NLrb9uCCeciv
POBCAgIVyawSv+v/IqiGdfBSjjy0xd9EaGmnr9GdB9DgFsKGs2eOEfYcJXpH/6rePZqmaEVAILtA
pUo5pF/IDbFHzX68lxMhHRoYuMWyEfylkj/954Ep6u1Mw13qt6jdIPhrtJlae7a7Y7n4na32OX1x
qPssWw8DFUTFooWBUkC9/7E4Z7ms3+8HA4mkFaGFhN4d76ug9ws/O+9S9/kDfQEgXzlQO+A6epNK
j6/336eVg9CedQqUWrGau1THVHP/pqsSSHRF0puO9VQXzJaGwcydxZhm3/S+2DI36HzyZouyyI9d
6rLwaIVBtXwa6MLPgodtn7LnKOWMmpRLiV97ZOJJTWaszxb3GvVcuM6Y1G++FhYYOx5YUNVc6nyK
WsLJSCkOSUJFkhjsMa0cfiw1KH6gDSRdgOv1tXsP4xECQbn33+E83Oh3iyN7ymVAcStGWN5sVEay
9YmA+2YI2j311YWtGLgwssYY+K/ytVB+VoxP4NNAjnjNkhc/0AOO0ai29JPzP9se9yUI7wkyazcI
+UghXExJZ624p+QqE8XTce0wegQNH+ZiGr6IRq2LBlBMcE0nz69XS2rYlkUEQ8idiowbXReTMxPl
5XfJXyhdIh3bdy8/GU0s5s7vSY0hv56/+XG26n9dZy0ONVLcIe42p069SCPpGr1WgsQ/WEd4ozpw
hAcvFK5xKadrh+eqbOZNZUqowUosTDWF8wLHhvGdKwrrt/aRbPis1cOtxUnI5eqb1eh90buiTf/x
qG75upTvIs6pcs+52fi6uaRcPUfxR2/MNCYcVagzYqhsxbq/T3CztJO6m+1UE6KLbw/J/lV4cvj3
t9+yKlNfx3pW7wkI7QwOBq46CV0RQYX/xLWEhOW0nyTrfkh1QPFhC+NZYWXCVLfBBZebXinfuwdc
JqrI83IfLIuv3Mn5RKlv3E8K0+incWZFeBep7QzOXKnJ3ptV0bMHGhaEE/9utNHTjVH8/iW22b9Z
eEUCqWIQwG3OnAgT1g2gceJcjz5xdXPXWG3JglwxTaYk7cJhpD4H9VDEWBqLG3t45V1fXs0ABtZz
kNqNm7MCWhk0mtOhtxGc9SyfHPsDwebOA409/MgQUJcgfWFpLfXaGGg2m4EEItu2uH7PEh+0/pR3
Po4YAWgHh2Rj2ffvVyQcGn43/CHTWt6UV/B+gogPquUHTcqlT63HMzhb2wdg4sbJWQIhZ64/09od
4ADy9qGh5USsbXoj8B/OJbDoF8N/jN064wYd9MuFjksgQdVLj34Hv1Cxxwgc2auHI5ekOnC7Lb1Z
dXkVmJkoOm+tb4hLEfsxUCJYbAilGhFRISYiW6QTw0yKJMia+Zpfw/FofqyvBPLduTLK8C8c1y/H
Pp/k54QQb4OuV/xTxJHydZ0Eoth6dK88iU+5FseASqOuZOT9yHsqj/w2jqBfIGUkdPIMlMI/sGly
qwnPtUzb9DMkEJX9znYatl7xPy3Ro68jFbnX0sr1GJOG+RNj7+bhqj/CL6HR/HaYkMG6FckL8Up8
6KyglMoaGGepZVoDLeilkTA3L3GZ1FXmVPJz8PZ/mJZPmZSAvx1DakIWVNfzv9VHP28PRnBBHo0c
h/4sgZRlyM2C89eCZX7ccStQ3uz7ge5oKdywE/0TPWSJCa4eJczIh0invcqi1pITqI+/vvI0q1hh
AY1P6bVfV+xtfHglE7a2miMV1Jkb3mOWbS0p/akAEkxg2ZYFoFpe1uQsgrWchriPaI5hCIIbp/vg
Wz4gzfCGwesHfMGvZBRxVV1IBV7kVP74chDFD1wFnme9yu+gJHt1BzIFmSRuGWpVW5oK+aBy23BW
H0LPnhNth0cIDSeiQngnI45evNDuFtcMOoOyjMiPdJpGFb893NymcbnCUiyuXTW0b2YDsSyAytjl
bwoeICRS+7KI1qYYoIEtZo8KCbpGA1/GkJHEh6yjrQ/j6qLRXDJKiJmIymRBMfAQU4yraSoLykf1
UqQDEH/bxQUWtDxawIuahldjcGcrr6zGb5gNALT1hAFuUlt4aI7KYTw+Nl2ATB4Thw/Fk0GWmemp
WA1R5Kul/D5hfe0EVcxZl42keJdv6yqtfyXQYahpfeut1Btxoq46wfYuvPJgUK6ofa2esald1ev0
B4+OiPtjEuak8fpfG/0OiFh8zWSbntIyDYSf9RRkRsP0l3E0QUW36BhhZU1pogplVNniGrl5AqJB
XL4tWxhfMm0R3IWgwYXJjGjsaC2vUYG7gHK0RvDup4uViX6rXvlCagJCuIBit6HWRHX8a6E8b9nC
4BMtmb5JQmkkKkog7pXUdffZ4OBcRWQu4sSArou4gDwWSCnBkF+nzl1RYaYwMy1owtq8VBNXbP4N
fJpySmxsYhtDOEpt1mobWE7gbGRARRmd8xfVN1KpHgR2HGGtitHhcTDqitJLhUEr0pF6gbn/irbz
UwomaxHpoZ6qhuoRc5ZDXhB4QZjY2nH3IGxm9OCEJW/gAgX609nr9fseISFpSjoiySBCCiQ/T2wv
mkRhYp8l9SHUhAzuYAJ7cwXBEZg8hAYy6f4FTGl290Hyg4tGIoQn7xAkEJs0zkAT7JgPuBOJQEx+
4Hd+N5tAfWJ8fWXg0U5kggL0fVJ+hdnA4pLwPedPo4SjjeMBKLnQWZqxqB6WqSHEF1ZR1439qTPN
gUoyUBRfNX5+I7IuQAK5k1ubQJoBujs9PObsqO3uLYW69U0prun9Qk2KOi2Eioxn5NROzAhNJ+ql
2iCVVMxpwqTyC7ZD5jWhtiUhLJ7VmBXlzxYA+hwjEWPjwEjOhhi7zpoFJqJlD9qKYHyS+WLXmYTZ
80D0Efjmt5aNSZqg1E9R98QPJMFVbWKfm3b6+vAJ6YE1f+/T/tSyIv825opHhxrxXENWc2QFu0bf
TBxoHfv5+5IBem/3xx+XHpYTv0nnuzHtNqiVbvV9sq0tQ2p00n0BXQ8hxz3P8qWB2Jx4Pcn3X+oO
t+yEpXwJJLnhN2PfD2qPlm3rtZDCyd36fFQIhUDzqpUOMvf4KWpUTCx+vvrezrj3s8YrCQt4bUC2
u4S05eQf5/7AArt7l19G8pUmSA98uQq7LmRx4ogedLWxahZ8ysK080w65+aYzt1ZNf2vLNk2TGOQ
eeA9ejCp+At2x4XZFti+4E8LDN/b6b0B97hUaJcrN7DnsR1JqrD+fdKADz5fubpnobFNieJhkdVr
vSMj11i8JoE8fFe3TLG9o1f0g1mjZGorkml537DywCiSpUxt+HbX9XVlHEHXuX4FlnF/NOuyL6xR
5l8nnvS5YBtxm+OK272hvGvyDQsDKVYDKqgHxaQh6aUaOUsybpzpA++ebMNZKE6IqVqjVwvPZNpZ
0Q2iXySD0wBtnJ8Q9Hi6y9FwwfPK4VRF0FUszS4xz3tlUBvM/YSKqIQhW9yLP64pMO+Jx/huYQ4T
UXd09nheqZv2T/Fn2Ovy4hh0mqsLqCW81oHYiQ01fjsXyRq6fW49LfremdKb8gty05vF0JtLZwnc
u9KbxN1ghtu6Rpz8XZI2QvH5FiqB6NupXdosTCElxfqDHZBuOO9aUoAXXyVa0M5j5NR1v/QboMi2
3hd+47ZTB3Ln8QgaA/dy+K+V1M79Fn9aCEykKG8sJOsBY2viSJmCQxdtAnv+4YHXz4jrsucKnLCd
Kfh7EkjrhOP9xKHDISGTXDjF6hh8SG/mRQmitVJkOAB88eR6mDXysPz90RJIgHiWs5atKFIfEvAP
GLbhu/+pqN4hqneCtZSLaRhPCWSsTUSQk7oH618KG16NYy3wzhfK1jzLjGLwMFY8SnVzUdLAfO3B
RRM1hrVwNCEhRn9dNgy6jGKIa5Rf/yi86n1Las11sEBkUdOKl4huj2J++WQ1pBNaS2wDVx0G5ETS
wP2f0AKATfFv5Bw9MSgixpZaH87TrbPkigsO81hSGK60X8IyKDj3hyS58ZxRJ6Emih95vJ7Y0joL
vzc7jVwOEeSimDQX1a6YlM4Vdnp4RtUte6lUFMEmAxPWDi3Gose4Gbyi3oicDXnchpqlMeqPpdUP
1OYSGp8wEPRY+el44O7WnEGLCK0vldLHozckInC0+DVepo4fv75QagFZkbXs0RTgYNDprj3BM+C0
GJa79UEPflbgnha1xfB3wcV4m9nFPjGNQJFAYjFY6fPpxlb98AQ6+W7SdG0brGUs9Hbp8ex0572X
o5g2Q8ewc5tNAOjko+2YeIRpgzqhtSCSyBUvoANVkVJWDDyBfll9i+4hi460PVkM48RR29d8Awjc
/Y0SSE22vFhML9cTJtGp0lzyn8uHkf3xpWS+3voMqJTO2XFmeD35Ls9aCTrVAhcSWv+/f0NFEEon
nKQZcXcgLNIxuEHM2jSfHMcazZG41x7pUKI0NyPBLVeoIP2FdbAEEvLtRwEBm0D+59coa48NY2nz
COW91QSScW87bMV45XYmECRG819EzADRGVgnX0xzVOvACZi2UOjhL17jByz0zP5Vk0PtBb/iUp2K
EWfhdBjdRYo7sZUFHtEFxhVH0fTyn7ZV93Wl/4VSXN/eFjGr5niT63C/BGKVEhcaP2vfIP0H2+N6
/Tq/Rx/wEAtG6SRvQyGrLr/Pi0GvcaYrjw1kEcQVQR4TRDWWC50QgzJNjEgxw42397vwCT5+0unH
+H9v4xCMDN56poNrqYkKFRLYHFg20uXYzIRAaA6cfQf/9YNjef5odvWMwvevae2e+VQmyCFeb2x7
PKJ65pbZkJgsILCKXPThe8bS6/W8K9vj5//n/Gpo0Gr70MHk0NI8i11514eG7j3aI5tYeaXkFjTK
6dvAoQN6p87Y2J0IkLX4sPmxhoPFIcikl9wTTICBXcgodxqZrcISxo82Lwx//81gxV+jEAHUXE8D
wA/6JYId+4GbOlXFrvXNG7LMvOBWLECF0Ej84N24uCsll4o826rCDLtzqF6tbZubsf/L+yQcDVt/
/PlGcUnxWdeVwuAGwsq1/NgP7vME/2YJ5Gp6kNWAKmjGHVPQbiCb6gaW/FJQeoqEBuRMR4oJC4Sf
8q3RYqmIKkkg+zyvrni6ZFBkb9Bq1BtkmI0PH0yk8J0W9W+O7S0vT6E2icgT+PdCfAbwGHtvua0t
u+A1f5Bmr0HRKZE+QuZLXRHczfvkd+BTSGuBYJvTGLjNybFQW4oAvEeHUWP77f8Z6lDMUmH1KPKh
49UFiE5EzYRl2IzA5NhVCmHJWaVAoxi5X1ytZAV9oSZwHQv29ymizyulMn60dzOzPSyjfeHSaGi4
Zd1vIoFEHXme9ZUr4PEful/m37RgqguLhfhIMYkaVIBKZsPjSN+7jeZNGfnIXhLIegBbtxVe/DKu
1ij06hpRCbPHi705k1cnCJGV67AO7JiKX9eCoNCz0CWD74IUOpURBvSByXSx1MCHbPaDEUKnwLap
p3TdtlgGtgylHJ3gghIpQ/F2LSuGpK7a8Vvn77zI74t4AYwaS3+5LCpEOzWeFXKMursqs0ICkYH/
IrBHqyjyxZSIzkz3Kwj1A6JCy5UucHQU1PIsnDHjLOZvfN8bpKro3REwWtcRVMGI5cMMb2FWZFmo
LKYA2gQf5LzwgEfysDy5MCOx+ZDJziUQRgP5JKoUdZ3gf3TYZGpHjsv0aAxrW56gUZFxhGUlADHF
J3zsvHjEbrY8FEDymrHRaCnS8UnGzqOciHRtlg6hxV7XqIaRHRz21XklMKYV7Z+qiOirFEH5JI+V
kTNilHXG8VRTovp9Ch74rdTTFasL5E9u/cepuKXkl+uON4xfEsgC4UdV/xql84vs7q/TJ2tXJRC5
DRpGthj9rQhdTzZU1kblDVmrFbSvWvIXTCqFfHR/obUpw1lIHo06vqKnx0YRqWqW2gI8MC7EpFd3
6I4WKU1EhwrQ+vkiXZAM01ze7ByW+QilVx5/8bjBQJ25H4w9XFa4sWC2etgXxjFaII+pPSbfaUik
9tijwgldxkIYezQ9mb3t7T8eXxKsdbOYVOd3JbIzbWyHI0Nmou/RgXOm2iKo0edb8wyEPpMSLR1A
vMLCL5afrf6eK6FyG1+zcQDG3Xy70Jh3vzZUk6gv+g1rLwdJUP+90XEJLGiskCH+qJaao7wekgBc
0JTiK6KEUD/C4rVNhGny3W1+H92yNOaehtLo5qhLNezHUPwshaDmHC/CDtsCRzJNPh9ZFkmZUuYc
uOIIbnHskZNqsoPOzMzQGlCv2/lqIlo5YRVAChk2HrqaTm1P+h5fUJJyXrCUkxfH3gev/p3X1hrY
5hMMoMEogbZiz2bXveBy+Pvlrzmj8yc4Z7AGsA49NnKwR44ed5nff4BoPYLwi4JPxw+KJZBJJ2n6
LGeMX0ynjFJ7ALP2hdoVlw+udn482VjmqpHAQ4RuJTZIyfGj6bnQLYxxbQmkWmjK0I5fA1lHNnuX
A8v6yHyaXNwkwkD2Gml61VHs34v3QJLElHpQYWQy2VLMYKOkCRd9EWjFjLhPWOwtErJGiby18VkJ
pG3VmASSgznJh9eai3FC0wQXURwg+5WDB53R6maoNbawjv/3KhG6Z8HYufphZb0GuAqngSyNnEfI
8EybgaOtDtivmZE/8ITxGs6NLJZSeKrKbNIDE6AFnyD+m/8JNu9t16odq6N4gIMTEgA2xtwqTATl
cial8zeJl+B/TALZiS3iYXHgUiwFENwrF7MYrMgyaGIIMNiaq5annUjJ6gYrkSshCF5we77zp/B8
O5oqpf3zH9Gw/ziKjJR4F0wTlmsg1E4/0evc1JTf6+xVp6YNF7SzVOY2q4RLs/gG+AvwTtofMdns
0xj7JkSt2bWYW8LFxVU7Qyf3ocWWFDUhkD0rTp9lgGwOHo8IYrQ0xV+UScz7E85yep92cjrDjfEA
T4HxcFpra9Xn195AGxm3pfot3EEyRjcnDINlRG5kvNSW2jeL0OJa/HqC2b9Tv9E7aQuweHCATxjV
p1Mdrkwy1hiB+UuLhwpdaPQ+xlJ1pJLm878IOTTo4FTyTo1rq24OuJAJQkxlaRE8VH4ph+surmTB
8GnR8i4hNPy8EO2/uYuc1QlwAWEgyW7S9nWb8OK3QhiKQJIivDQ8NimCNEl9Q3NKAPLh4frll+aq
i1E32UKj0ZZVxV4av33NMnbK1jc2CrQ2wm10/X9BjPR/ahe/k/DLQ4CfuIXuozd63EIbF3KGD1zs
NrpsYtD06hHheXd1BIpSUt3++LvGyMGeY2oPYF+qB0iepK4Jl5iIVjcKbw4CxLxu1tcFUBII9uTY
d5Fe3mPt636X1O2Oww9LLxPhOizS0D7sl428linwBGJw4fGx9vvml/y5VxWg/jlqhNksIRFbBBx0
s/XlEQJs3bZRbWqQcF8Eaj12NOtmSp3ROccb6MttzYjc467yVCEDOgETLpRLb5i22EDdrPkVq1Y6
CsqmNBNWKG1VwfNVMJpGBb7zu4VcHqFjRtQrBChBSXZjwCc9uPnwkUyLFrgUQDBn4TScOPmNBDJD
8N1DHdjbI98woVUv8F/P9UCKVx08oyKZOuotO8f/nboL8mkIfvDlVVhdkmXmF5kkfGDNFnbAuNFV
QkSC1GRPic2WOLrTZ43R8APiAUHA62qb/bCxcZkj3TxZYakY3YFHrGyexUHzdlZX321qSi1ezQ+S
pqAGFzZGGDySJD7BZvgqmz4ntP3/niEfBzdPoqnRgr0o1lyq5rEHNrvZ8C8OBlBp+2gHbzS0N0fx
oqvx/JvWmtnNAB1cs4wusQwtN8TkCXz3CBBUhHvhsFNDPbm4Gf9sPYsEO1YUT9CnCakBqE6sjyf8
78v0m5bKALOMJF4Izr6IVKJ4P7P8rqSc4qSXaRF6/EMvep1PB1meK+bZiFJxzvkPXBqKg9Bt21yD
5H+sibMO/AcL/bWUEnzOFiek5iOJDuspMMyoef/KFQNzmyUBVkRGJgGCKItNa2UHHPjlHpJR6vbA
T3j1uw6e0LYo9RIVwwEKOe5+r1Gye8JonUMiRqw4FQNzX9EtrUPsFmdk2gaYvqGSBACdav0x6kPH
bVy9bcouU6KVaTbCZAbBw7Kk+px+WwrPY1MZLoOKBvpyFrFl1qEYt7z4jMp4RjbwWwu229XDzkQw
Oq+m250tJE/kAylS7Hlgepcne5ZOXKLm0SOzNVahbSK9fKDaeSjOXpxvmsoDzhqh+qmzcAqD8wDM
hrUIoWNf1B7a6fUY4p+PMphO15yowgIqAS+moFwHWaouuMTztwy5uQyiYD+WVSW3buMnjEMV2rDi
K2dCQHkJBCEVazuyqYuZeAJpQ/DnjiFyqlsahIc6mofLnmYwcWnTPeKlVxLIRy5fi7CMZcy5QOtY
J1C3GoH6+BwZ/yifFATlXkDCokk8B71Wc1RkHwnCckBbbe24KkYHP4EPPnG+v/Jg1SKUSfWgDvyD
D9G7t2rcS6AJ8qW56V/yqjCTD7C+S59D6u2hB+gORqDgFtR4Do3gIOFC9Fzy8HLpi8Bg+D9cg4e2
oSV2oasA8RAot67Y9pCx/MazpOxHzij1m9QgwVqpm0V4F5KJXUgjD163TAguGJGP3MgB5aQkMFYx
l0Qg8gi1i99QPKDlQZRVIzQ4Ws2+wfJQ7Sxw8GzthHtt0de8lxslQxVUVjpSeJodRPq04kR7qupv
VV3gksA4a8ZYvDiiSh1LsJg5xfzgbSRw8pFAvgPj5dIBtGIeAnirRd8P3sh3aGmy4gv2l37NYnP8
KUOs6vwUbRlqwZhqK+LspLM9P2FROs1iWufsyXrh43FUIJtA8SJKIHEYt6aVax/40KBVeT8qbibZ
EJbPicuPHGTFfwOQG3yg07xqYWZQV3fIsCmLdTZamJ0byYK1NYgrhpvStBlLzPxe4XdRNbdC6huR
oKDWqGlFnvWVcRaxBm8GIqWG9N1wbZxjOaM42ICx0O5LyeiW/khriIfeuA1wYeImOasmoZo0GOLY
RJWRKOmTcVLkx+U9ntc9LlQPFdVF27e5gGa8B6D+uiKt1rhl5UQZckeWYUdr/BhTQKCvbbZVglJj
0sfbSbwXpumCOZGBGLcmom+mNRfsuP6D7C3Rtph22JqJkYhanmWIE9mKXjGMGGswJDJ/lSMNBJej
4qJwNW7rqFT38NeTN6aOYTQyXIT4pqqQFyYeqw9WEmZ20ELDwCKhENVLsycE+9um6+yCDh0EsvmE
aYYEkuYiK7/0HajIkHoHKz0/1S6bX3sLpQS0YJTypyo+mdEnvYhYTM6uIh3BrTbCkBE3FffEDMuw
SyJ0ZS7K7T55MW3qbOWe5s3SO92oBxtVpprjxV5EkCN06ttx9/tUFgngKNWE/9176mvurYBDrxde
jvzb+HToluFfamEk+8NTlUdmy54Pp6jnJJ8s3RIY8G5Y/ZzNqcbJv+WqOTu+vQre8OjhllEUw4xt
/jPTirXya84+/gyJx5LdT4kCkBfRKn/XLSo67kgtynP2/bEggWzIPnTCla8Dt4ZGZEqU0+FCHvlc
sWdG60o3DdQXzubzPa7MevUewjw8ejY60ZIo1WTiDa8Ti/3c5CMbPKp4aajpgh7T6odvhKhyUE/P
YL5Vzeeu+H0wLx848xKArgBIZs2p3+UfIC9ts0RHRsdExyiP5xejmAf/GZDaOV1tKTtE6Cquv5j1
4syE6D9nrcko/+kuDp/X9bGN3jtEfwBdYlWlHwp2psyWHZyxRDyfortAj4va7zPmnarizuhgFyMi
DCJvfhOqBbrO2vMt+fHzuITDLQ1NUcW/ymej214CdNJFjBZUqrM20txme+1+iXwxco+u3+o09KE9
vqUFcWAx0qXO9YoPoTeRvL+I2sAndLtiKYebM6nEV4fyHBXzN09k4Ya/RI4dX/agC1bdutvGeqkt
yf8EKRAoswzBpTzGcs68y8F5ZL1Z50PXv+sMZFSY8WiWiBA7f1un1dFvlhb/3jdVo0l4WWCLB7fw
c6S5+oteTs5NUqx6Rk/oqkfXkdh2e46ZEfHLWSIvl+01jcEJSUqcyPvCikoXzipxch1gSaMu4Fox
3QCb5Ji4QFeMytn+DBdXH0f2tpeneLh6uf/oDgWzjfNY5gyUOJvqtCQ6xRM2+Tyjn1enrdpyCURw
oNoT9cU584f3hJu4SLwfiysQASxdFQlEc41EJKmK8bN7nrX6b6Fu3Wecn97GZVXZaTth61pty99n
Oifbn3HypRBshoZEJ+9jC6eYvP0Kv6ZAfX5e/RKcpTGR2REaegbAq/ZWYLy/ljXCSCclEBhv5aRh
fGBEwaWakit1VPZ2UJXN7rKf0j8ge9/EwMq8H/upyjaRwQ8yA+ySbNq4w3PX2dOi5ARCKYXq7mof
gt+6rJM0OxF0SH2+LeGwQhjQqe087bb6AL7UiqHKrThbl2I9VMgo3aQw5JWVo/3JnRaHzmpHrO76
GAF3tnNGGP6XLqxopmDCPmMjx1oKic9bZ7jq8FSQ5O9tycMztE4OmsMrUvhBzdCnhOX9v30bFlHG
p7u2VjVEx0Y2xHNQ6wCt6NZozRpCp+8gH9DvxQeNFpVR5gevwP+VfpuvuawvlPFIOI6tH4LfeaQ7
JV7SohKYpQtNn1sezqJFrRJIz1MJhNdRkO6GV4De3VNoX0rJuj6KCK89A0erIBgCZEg17aJMLHSv
DEdPM6PED/ELo/rsL1xT/OXJbGjY3hlnUGnwUgvFHvRatZVAMvY+/wpS25OZepmXM8to0yVGqy7t
rQK26qyQgYQHBg5ZlEcljvWlGgkIZ6XG7XaCVovqg+C40h8FhGic6HeV4Pj8MDnOe/a9+Gz11+ZK
eheYYTBkyQd+GrxaoODGW5/fb+Iqgm61NPnv6zUWnx6PUvYVeuaExuETOEJbcE2jlXh30jb2uT1H
icmP22wNUutnz2co6gDcOxcqTcQ2uvNwqZNsFRJVVxwTBhOyxIIhgGfN8FJ8eh3wJbPPmnalSHX+
/rvlvi8SSOfpnn+K1stbdvW+DGlX+XXfcIwq6hTaF8wCcrn4CPt/8gYyhJxGAZR1Di6qtGaXtIyx
JoWg01jPLNDmkfUgfCySI3BCRqOR4P/EFLOXZijjdQL3Jmx/FzXV8lv2+8DWjyA4Cse49GdDX0gg
nIrF8FMlwN6gV3NML3yCe0pHnlnr4BXD73tx5wS2YD9DvL3shx6ABOO7p8BlgGupO2dmH3yUJFrp
2EdTE1V6mReUuqlvdPQ+aifietM58RxekHowghWv3IPJHAsvxz9kMVbjWY2TSWXCtvYB8PqOC8gj
vKHWc3K5MWQvOpm2yFv2Ukcd/CvRYkT6sghGl9pk8lG4erIHPjb2fHvPEWDRKJ7By/610XTkTcxg
41BxSxJLJb7VluA/oLm503HM6c/Ho2N2QrM3Lat/0fQnqPh1XIPz3hS4LJk1kamqC3ea5QJtYnLJ
0rsS3Nq+U7SAsRw+4CvksiaMpJjdQDFOs3sZiQncxV6Lt4wygUlDhih12VOBG2JSW1evOuzcB1Ym
TCBNBfSPzCS8hoghxweq/7ffO/As5QeVHl3Xc0Sa6P2Fhpe35My2mDm11u6d/2eOn8zhjumpHrLP
PPja1YrRXJ+jaz7EPkHjFVCdEvhEt1APT9tX5Wr/64qkRJDfxqjk3+dezeo5QvXTITTTVuMYNBo/
KDV1yrK4+LQZgdJOPpZdDG8DncGjZHyZtU3M7wMJCxfsTzDt2UP2POwwCTP56sugLeGj/dR03nxj
/oq4ssJet6vexL1FLf4bBTH5A2NpM6oSD7uRs3GzjprafgdkyzHKw+f1/Wu/vnnpplPzYadvogX9
n2ZQv8T6RG781vvWcNo+n1nz2Za7la7qCkIG6VRFY/4N6MjmEay9mPJdQxxiK+6M1bUfRemzVHDY
4aSDQ4wE4nw4a2/uIYoZGeQ7P7awQ3+hVqoafnf38tBM0tel+K0yc718Ntefp4ZrZu0Gv3wtrYrn
hIHxHVKLv/NgoILdR69iD18ETD9EAhHFZITPh9RoJtKQAqBD5BHESZpJtyFncGyv1rFBVV4Q/Nzt
xk9k/RNZc2muJyz8YFMA/upRfRpD4HvC12t+9Qd8td1us1vsAZxoVxC9tlSctPQCQy5+dBjXo6w3
C2pQRfJGDeVU7/H575YSiM7B4KGodIfGEfMeXiQw4V6s2xwppujvZXBXJRANBYLgZEv/YwO87anW
b4yBR76Igs1dYEtSZ3hb93dKZb51yOg55tVeAp8MG8F4HL3WO6ytSfkLl0wDmrmAokhmqLyjxpv6
o+31w4SFazRQCqti8gIw87bEUF9qT2a+kmpSDkU6Z7XVUmW7+6+xCm/vpiKBNqfa1jMGyLCScutR
XUKLBJJTLNWvyEyq9yPW0lSLm5R6u9miRIq6N169rOxFXGV+CvNyCPOX/YQVAe8OzmTubDwFDs+g
dR/DA/9h4FPEudANclFlVCxLifDj96+Mg0uLanL5Kiyn6ZVthA37jXOsFko/gNf6/8/d1m12UNvH
ZiSQqidL7DaeBFIf0KZntSjmbNZFt1YfIBscbmwqknogNygejxRzR34ZhDI9GgeYmM7ndRYimPHK
COKju6CuNZKxACLoPYSIK6Ef7U3BhATE5GZLXhrVrbyjSbCXIFShDmQSiTiuwq7IHq5AOAlrJYHk
O5pJCYOKFLUmWH3txnykBFKOYC+BJ4rAA5riGeLu6s4Vgb05ZxLUrRSZ4EdCF1c7XyCOhIrRIeN/
gYcBCoLXJnS6XaAPUoUMUfraJ2LLVud0eFX5U6tB93PqZRLIUQG0ZsHuYixsiYlzO562VkNgFisn
fvWqwGNxK84J6CpZQz0HeBGisSxH2DrQPM+vUIZbw7kWjWfv2U1HcnKSbqFRy0WHgZ9Xj251vuX6
uVL5VaWp/m6ZVHy2LRAKUKoQipb1bJVDQJGFFOTMZOTa8oLXkxeu/KM+ftyzHl8UT9v0GqPe72ND
y/v88k2Ppz+Qw19dGOY5DG8wTxYHNvKudV+xO9nx8XjzkvDMHoMvpGHTmNvtjhuGp7s1+YGrpw/n
naIejkmG693Xlu3SCwxsLv6D3XUyxu+Qpy/1F+lSy1ulVwqBb2aLu4wPKcmknXrquGo9WvIvqfFZ
kOfNv8v/ePvk0Pr8ieK0PI0sB7syp0zdQ7kfsv89WUw6XHZHxX57C2KbgW3FMYAtagUULG1mtQK8
Mh45kgJvfHjyQ+7myh+fZdnlrXeBCLBhswcnreqJRkNQb28SR20XlFlIwpAWXDbaFrS92zrS6PdG
o5qb9j89cB7m42ZXybCztTuavYRt8JBNPkENNfrVDZo4K3AZ+7v4fkIVEoEFRDYZNuXoLD1svlAs
vN7cv5qXYjyo2BcZibrp8ffXq6flLup+jD+4/izS6nre7TCWhvPkzID4HNX7wpzN+gSzHVN26GIV
1i4CzOBd4kbn598H8F6HZiZ3BRAEBw7/6r6Z4jhY5Ty0U/8E7sDfy1b/7MPH1d5cf+KCyXOqTy0K
NO/YJo3HoAhB5b/DjTRLhx5MmmX3ykOpa4uPpzzm9bN7L6NOOnTfjCHbEetBwmtLL93eX3fVmrhx
AxhLox8Jdypx8riw+OCSjl2PprmlL5j5/hvd0cCzyj64Ws7s1Hk1Ibflgz86t/Kjiix555ssxBs1
hpbMM51Km7caS6BqygZz/zgA7wIU0pYnPKoc/s7w0qnCoxD0UikTW981cMdgqr94GNQXefRo9r78
iPns8cvlIcWM0XNE9cuQkVRI2EBMlu2gPxkX/fAyHpgrzgc42dWA1EohgJ+eRSayjp3OUoN/v/vI
IMk0GMzQAZBhjtBJ9eQOGzwultyWM8eGbzY9BclheenPasP5OPtM/yYJxIUpIt9b/IzDfoouDH9o
jQuzUKW7o/1d6OBvgjDE9RHi8oqmKF7cHi54N65IdD0tzoRzzahUKZJEtPvRQFIgJcpoNti+0e6s
B1uYYczYPF+Cv26/+5Js0QSMIUbx212ymZyYMcac8MggM32z8VHJjsuo52u28bcE7mqY00XRqutr
UNgIS4/1QPenuriQ5nNfG4exrA24+WsstGNO8OKZ+V1PYBpj/Nz0wvaswLuhhzin8Ukkot5EvLbh
qRYEDMMBjE8f+Vz6u8y5yj3uDLVDl3hWMH2GBXL4qXeXU2UmSc66x9dqjrqN9YYLAErFGGq/MtqI
+lB/WQKJwcVpTwp1760NuZlfnfjsI+wzGo1s8w/eNko0jJObrNY1uQWs77rnuTDIuKJYoMgpguxy
WX/tlAp4pbtyd3cx/5zaaVbn4B1gXepx2T9frBVyVUYkQ0W2PQi+eAJd5Nap2rda8gLWJyIkYjLL
e6kxYcDMF7D9mj9vSgLxBe4LLMX3xUJCcpblqLKVomqLm/mgyleB9M0G1Sokgyvlnt2ziM29wRLI
7qiYo16cGjcgNAitx8G3vH7vMAAIkBwgSXBJBOWt9P+AFVwETT7J55r7ufuxhmGerUtvJqjYMcey
9Zgxp5VtGCxDj0aIlUD+B5usvMgrCEx5Pv34T6UxMHozj9oUHDm1QGjRn72Q6uGCduXGfSObviEr
IvjO6awU1DDKblw1Q7WfoE9qwae6d9xoqBcaj7+XQNK35SpB19oRxFVjoeH2R4hAxHsPT1Mj9vCE
wS22V/+iSItAK+sRIehxpq0MOuo0MEAIn1oyDK420n5+Z1yqLzn2mR/qCU2f0AP/qhrPe3k/84MT
3Jp808VHgfB6uWYwxjFOQXfN/qDlrIUqqv4alyfC5yRtExLo0MlVIHFzq1y/c3AKujH+PWjthgsR
Yh5OO5DvP+EX+qM06Qj9EA4/H0HySpVAsiM+/rAaXSFhxR8olbiYIgApzvs+AgzpGtII8yrODBqc
ykPwAwFirUhGOtvkTtlPmS5QHUfgk2e+DDABBQZeAvmj1GNCakcrcYFAG/bi/G+XNPs9QZUzsoPZ
4rmVW66WstgkxMV+XYq1al+GPYkrJlfLS/3gQA+wV1VwRmd2Ot9RaM+mI8zaYSiO4d68qrGAal5i
M6jaRgC3eL+XzX5qNMYnREZgsOIlIN6UQcCJF2rvymKzzPOBtppWYWyO/TkxgiYIumCGEndIIKzm
6Ctrphsg0e2qM94jFU9glvErtCu9vOn6v9Mbj7NoGAJeZEiJLxxatGlqW61Rh2Evv8Tp8v0mqqjA
T8Pvi5FYFxx/d8+qx49oPOHJvbJejGnhHL9dX4hEvSnqg4frRk6pc+/mE/0EQDQOKaxsqbzyYUGK
KZWphNFoOxEUyg/Gfxrf45xXyouqHj15N9WDuerBkQJe5KcMaGNErMB04LeHs9BWC9e7Wcrmv3Lh
W6k15BivS0FxKenKFqGMg9CWIrDsd5oggqQr4uyHmVVRgryWNplb+Y6jbD0XTrQsTkyprZ4WXlOt
v+tBhE+I8IQUuF9f22c15VvLYjAffrTzs9Ip80XtkKr41vv4gQOaIkelG5wJEUlYMe2FXipfLSWR
uID8xRqDMu1deTejgjYsUsS3GuuiyxU49LMA/va9T9kdB5+PmSCh/EoPq7YMHUOZR629KUqWRpw1
W/oH2+c14dSAxzuy3WGnjZc5iOx5p9e6ygBSAjmh1JasZtkc7Zv++gfBBJA1DUDpHv/wr1Aa1fWE
GLyX5i3ca4aFitQepsPYlQnzF8bx4orvuJGqe4R9tjoqUcM1pg1cuEvWrAVikpFcY+Enjs80NJVA
hHu9BrWMD9jU5QjanSvdCYnqwypRo7AL1cu+P6p/nfPaE1OMvd9vMrzLH5+KvdbD/SCBHDR8ELRB
fpHicdYa8ZfuH18O1cytVd70zJC+IoFQr6VrKTQ8oDHbB/sjRU01KVeWJyjpG+P0iWh9dUC/hxvj
XFNe/kS9nkL0zZkdd7I92pcAE8y5G13sfzOKVZ13uPzi3nLvS4CJZbTdnh/y5AFjbRIIxH3tgozX
/9gf8uBDcOs4dDYyBMEL5LUrRxtC665Tfdz2q1gIGa1CzEiAEjvXv8RShnat/lJ5dLUEYnecxs/5
eKLhTuGxpiyWDC865EOuP6hKixtpPjZgD0pn35A0QLbeV8BM5tQ1ceEpnn40RSFD072XMBTy+3tp
VG+I/ETPlMc2col5EOmgRSgW+MkwtpmLwNdFvqJ60JRrwpjPBA75oKBKcGxprIt050JTouuWdZfA
0J+JmIZ/G9GEN03dxDopeW4L07Rp/3eXt46Ojy4/xuWucXJVSBXLd1Vd0Yh4hrtbVK1eQNzY/fGa
aSahUzs3sv1Ajq0fihho+o0PslB8W/FseSNaRq0VHZBo+wx2jh9qXUeIEMHEQWOYldKCPc6MRTXu
UjtJZzc+O38dBm5UXIQms3TpCIwgBd8/ztQX8cA1+2bS5kaemicG6D1U8w+VRvO649nOhvDq1Rqm
gDD+kW16Gg1HNHC47fDNbdB0Kja/LKpGWyrkZyMQxzweCoBYpsD5Q9OK/Uaw9fbfKesAgY+7JTwk
eNo+tiaB/JvnXLgzuvZu4qT5AA5ZoCrcic8PdqpM30PxplgNUnSfXLp4HJdLiLslHkXwKjVMEZGo
wFA+yG3nTLl4Gg9lgQea3j9Z4mX0ZVhfJBnnn5iFE/5D09wJtIev3ZqWi/F6xpZHW29atminUltn
hZh3eWY5PceaGnGJ+tp+rQTuqvqvfAqMf74qpfZw/IcdST1iBrFB/GxCGgZ/FLetRGCW6r3iX4xO
vuNmtDIy9VEhM/YceLHgQvyQW22Rh/s5d84wq70351nNTAY0hvsgxIc/ALXpGv4NGJ30e9nNbA48
kQlrPnL5cj5AD6qVQHZ5Jtknj/UIPuyJkwrOQisBf3us82z1S6N7Z+p1cEdXe2i2eWbNzdEAixWx
LWTOX+VRcJkHKSwEjuuJuptaGykIfZfSd35zqx0lpKh4fj5i5uvKlehY/z0r2hbNpl9N3urzo1me
4d4nmrgljydvsQ+rr16/xQM4cjawdVs9euAJSqGP1ge0YFpJPJIyVD5S3K7BA4qtRwLy1CNjRirD
e0xf3O/vvPbB8B6hw5lleu4OP5J/4H9n/yxtelmYimMzg1NhfwbtitT/o9N3/8585uT0/OrIufWy
W5m20ciqyzSj7iOATmy8EZ+015YfGyt1rnqw2I3Zi6nu5+8vs0jD9vIzr7z1s7ROGIVQrsOWdzM1
MoqHnfjRVWNX5hCtaCTTPXGxUxH1vA6te9yZwbRQ6aSJWZhrtuU0o3+v3uXDVZERfo5ZH0CH1fx2
dYx1YSAKdI12IIh2aWeY2QV4BrkYX3qa/vkvjLPQND+OVN0g/GF4yngw43ibPGJJ0dwePWM9M20e
Mjqezm+5rXof9T/s2/0ZbK1mmD9/59Mhp/eBJqWspMPd0w4lxdwtT01vn28fYMt/OxXkW194nXU5
9EbaV5eFnXOqqUfaizQTtM4GuV37++NOg3MOu8pO/VlqTPvYkPxKR7EU9RE57G7zt3qSwa8KhQvl
xyvU0Yd2/x04wrZyDLPQ+Gv3tkMfPu5IxvmkYzwkkLEoCeT3MSctK7TvcwbtDqCW9/F/v4BDJzIi
NJ7uq9M5XX8NIsMP7l8sWtnxgrmyu5KEUPomv+MNuqvR5XyQZvNda2tbq8dXz9faD7MLVyfF/915
85hzryKVoEfhLvxaanWsoLqJEw8f/AbO5aD5ZMSNhJlpUYeJ9vnf5OW0PD/GJ9sLTcKTAj5bgHSS
U422gxe/nYV96sZDF6E/AZbLqbuVMMoZoUHVuc/uj3kL7Fl7I2Yug1xR5g3tbeM8RyrrVpNSutvU
H1/eopfgLKVVvO+15f4nR3tCdemYHXoA863qhCod4FUmNbU3j6jLmqaee/So+y/nLPdgxy4lU8Xq
I9ZPndPsPqInbxxgprdIJ8g3CcR5y+DORI7N8sSJUZPibKMeCeQ6gYMW5zUPl1xSTc78QrmZocOI
9lh3WQ9+2xDvqa2L99x2w9qO6lyESXJoRomP2Kr/63PKZUA4IDX7BoRa9iOq96IK7MXkgbic0b5B
jRC7UPlW1YD8B6GCvXhcXD+JH9xXG952Y8zH64qWAI2McMu/Rh4av593obWa0MkQ6qq2PTsJIFnA
c3NA7XuWw2OefuPlZQGsWVDs55zeK2To3uuIhZcv4OpNB8U58oHH0+wIpoQOfuVb3HJpQ2jDA2g0
Up+juOk7WiqovxT5cupBlULsD6qU/MQUMxAQyUwJz64DXIcDUZkrEcoM2qf7d/4HcoJ+rEQw8b82
5FtIB0nb3llfheMDa4IdB/V+N08/DsXkZ3fTus0WvDw6cHl+bW2dtcrVveDSV6Rqb53nSvEUb3Y9
+doxwwZDZhurOk+BC/YXet1z+mEwF9XRUHWpnc2Zki+wfO9v8ZN15cawoWJe4Esfn78Qk5/dy6oZ
FMxCz33w7o24gckg/6Q4gw3mDLbyokXdw75oAbA7xWXQ8UaB2tnMpPWBw6qTTiQ9dyURdJcZMQZb
cre861AHH/n3lD0bJ3TSTzbMt3PSPUCbQWhpXJvAB72lq0YZkAm6GLc6JZw0Lgi0Sr73QeG2x54D
ocLRl+YDk9WoRh5iqQYQvYkFqIMHjgaNx5m3hDLmdPI3C4yoKK3It6cHxsPP2mJ/LfuAKlqymh2v
PAOrP3r2Dn6FEe0IGwdv05WXR9yZ5B/RykujGdGpDRxjaGTFh4K1mF40uEXlplbgxd/uzrXyCy+8
jp+n4meDvBy90xaCkx5fULNNFPCNTQD8jZTLmBHDRbhR7zVuSWhOSEXbAuxQYExIrpYHJTr17JlU
shhcTDDMvDGy9Ft4bHDjQFC71mPhdvr4FPS+ENpHbXdwml4x+Ccwknf8R4PHN79VZIQPSApaT+qg
3H9S1nFQgH4QGzCzCjzLbeeywCO35ltUCoIni8mIu4F2HfXTyI2SaR8tsoYjfzQmvrYJOjf+5O6U
UUOaIC77NSN+s7ISVG4x9T0sHns+x8Vr4gK49iDK428sIenWiIbXinvtt1Ru+f9XcbX+EEhJKJo6
87+nMpGH989WDCWQVmulk+LnGaZ8X3OrRSS/jtYtROvBDNXAo+SQ6a+K9R0RR0KvyFGkwtQinqsO
FtppTTt8ahRqfSFF1DulCNFSrB+rNkPYfsI9uZ2qy5JABslx6FMJ4Zvbid9Cn61IIFDQthdGGJBm
9rde6c9rHugwG5NPipqBUQDjxDJMqfR8utsxqw71cEbo4gf3KeuePMVU+BVy9HbjuK4EErf6rOiy
EWw59RLTrBVZGG159lh8V/ooJjj7wgXEn9I3vHkmgfQcySa8MDypkS3qPzE5iGIi1mUPrCc5NjU9
9mKYatefJnyRW67YcLEtjgqt4Ri61WIrKH99hRI0jK831Kd0KV3u0nlYld48EpM++THIJTl/HCb1
p7+O0N9XLyhmCM41jxd0mS/kmOaIAkNMr1QO7MjhHxD4Oe1ac/qF+R5Va2ubKLSr2SkMo9SnCxZI
ziLr95f8S/t//R0c+dgofaLaUsP2wsM2lhiglgQ83D+xgPblTq121QqhYRHOjYpPHnrsss/ltnSL
nOiwCcui9SvXjBgJUaWr5rAcO0Z0/oajaI/B+l918T+97f/p/a/2WHyF4BhLQy6AgAKeXyjAnv8z
Dxy973q1jsj3ckmUum6f/LbeP7GrfKDN+1ncsSeurcF+DLUlwe2XBQMDNiXlV+7uWXn2VVzdaLz1
wq8Lv2tCYgB5BrcWHNHpt3XEkN8nG7UrKiuLYbnf47XVM7WHTC2YEsiXMz5Nj+muFNXaYcO5rTV/
8+fpNYPP7MzYHjKOdr/jbeg7S6JoPm8QFuz/JBAFaLXl0Wd9g9EZtcThJ6LLbba3sbjm4fDV3S9q
1IYvJR9JLfkjrs8sknz0gLaHmZxNNos0glMstql8spo4XUur1rDTLKm+qxIqX9KB+Pz5iBGbPluU
t6uasefCUnx8FzIv3ME2YsqN3mfHu3agW1kCkWG2xAz75AzfWlFXbU5Vi91Xk/vn3rrfH/YnF5hI
IMTeOIbgmNXP3GK2rAGChY75bZz41drgVMjTHeFZL/5gUS6jUYYFVfS76o4+RxxSSrRPRTC4xqIG
C5Z7b7queUgCmgn6rkkt5OSfrRcRvEdnWJrK0PS04POBQ2cOmxxeh4VR2rZ7UCO+H7j16+BA5ILx
nZdw6jzpISn0yJCHzSN3g3HC+enAAZW1rucP5/j32v+UQOZP5PCRWvPtR9rabV8onny1/+1G4SLL
cR5UKFymz8I0lwIJOm/N2dnDv1pGFBViUis81c9CN9AGLGXr/gWDtiA6/WhA/IfjXw1ciSoa2vNe
+5hSJiuPZUwd0zcvUzAwwf5TWZBvSqLG6h/emH30jnb/6PPOC8cSLjf9N8CV/5URvHGHDN/i+ff+
8C/pejtQc2fToDbddSvhpxeM7m24Ml3Lcvuen3eK0CKUl8+ko6TW0CT6Lab/RbTSuUfaWq+UzfZG
DczZSiA7yb13tppgOf2MrPP92h9axoZMIq1rqkN8MhfOzVBKR7kZ2biGGF4XrH3F8DFl4dSRlW/q
8bxFHGIZ7odAcYaZ6TptTPHDF0UHrZYdWjE51pQATw/BIETRX6hFTjZ49uzvt9l0DxUYFMk0pJa9
NOhYFTCdGtd/Cs2VZ3L0Qa1mjPBG0ZGQjz5bEm446tVQCW0O7nrLvOAlYccLn6vLce6ZsBdHqnKo
kXBQl5yqmoQoXPCIeP5EjqH5zAlUCS4eEln4l1Yv0DjJ0X722dc4GVJzJW8nBfJn/6Icf/i+9KqK
PXFpVW+AF+zt7iXm+KtKXw9A4cStYbbvPKn06rYfP/Bbn/pzrgF4jxbUswc+I7rv/412uPC3EyPT
3XS2QT/u0taN9EIVH8XXx32OzaXhgx0wQriP5/AoDUY82NFq7FkG9mr9lX3DqURcBtoojDlqrX4Z
c3g6vvsDZmD8hVzTC4919xrPdSNXteYjcg01SNUgQs16ztGLzo24l3XpjorPJmpoRJEa3DfIWxPb
LLw9qNtLCm86bg08LDB+4F5LO/mi6O8ozTtpZ5eNc3e8UQb6O0I2Tw813F4y1dXowq6lGf1hkHmZ
1vqVitHCVk59rHXvt5rKvACHJwwUiFdSyWi55yHV0+P4dSeAU+gitaae76MDy+xXttxg7G9WeSKb
WmFV9zlUPet6sWd8Z7LC15E1n1uwKJvTfP37W0hvsF8kEGTwu/uiyrcqav7P1JqfsI6pr/pM9Bmd
WSwgJMnfNfWJ+eB8Z0/W+XviEf2rEkhkS1uJ4U7DoxdrhchJYR9rFh6gdPRp3rP/Mq3UFX7lF4UU
3oVGJLwekJ+P5EY997ii1CV8PpCtYv4QwHsKVtSJkXzbPVYcnNp6VEnriheL1Tn2oK64/uqrzJTN
jh/v2By3lt5+Yu34yXmq5fDeukPbHPqM4AaPzGfXhATOvcqF027WpdYGhNPJswayfzKRcrnOzddG
9RK+oy50VpxBl1hDn9fWFOosqThMfCznIkAeZagg6qOGBqFrf2xpVbsy9lMwwiy3qzPjz7F3+4Fh
eyBoHrM1kXNj+E6Gw7Hu3jeUHRv2OWWgoNYs3lmU6Hb4uf+BP8RvgMji1jFDZerdrWzTbM/jLKeq
BRvZHv3EZRv1Gukc+2lZbPxjzHGkuq9Kl7UUcnAJHxp86MwHgboq534T4XfEiIIaWHH+X6pI+erf
dYjKPFLTiGF3o8w5z50eiJsJ8EquiNHl9oydZ36F9Xlt3nXK7wLBTvavpfBLcJDsS+ioOwsw0dd7
2jOnlwQNAeBPwYsb+TgRVXpdw8RjI+a993fpZwwDy46+n0buJWtGlVzNn01t4I/W356jiwgfJ2pC
JjD453ElE4XB/v7L0ktZx5tVPbpq2ypIYo9dYHrCBUhWaQmmo5zqiODsxNK0tpejS5zuX6h27TSU
WbmV5WBseOzh8cCnea+n3vwoPpNbPvVR1np/2QHr1RuksyiDzq4Tr5SuWDu/ULU5lVuy/U2Phdm1
qR3lfxSVHROgFqAF53+NfTzKT32gY0D02KkLP/aS5H8oVXOFi/mctyiymzoK9cQ2/GjQ6MK0/iOB
1HHHVGKH0N36t74OlzeX3X+8rdZumevqGaXvcCqoME5u1S61TwJJXx57Mwb7sF5jpmnTNPwssxcH
XfzzGxkDfSiPED1dezEUBdxIVN0r842ZRp9dYBbF5iYgdA+uA+MV3uc+PREa27bdKg1+nt8X8YsK
Tf6kI7LUbTxAEdgaVmIlkOP2LWUjTvEwrybyl8p0vZMuDxw0JyzKKw1PdvGZm/tNr/9S7clVV402
j0A42/y203Ya0dGpMSy44aNPZc08ppxQkxPPy9WPyQIV2PczzOPpxBf3BAdVkRvkytQg7qJ94/CE
flbQnxabHYuFDHplqUBNX4QSQQMso3hYmUmakvzqO+OhM6jN0+GZCqDWXH9+bHEwYTwns27VdW/U
RNMACR3Ui11ReR+81ZmaRUwS38xAHpJO4qFKCQQeJBvPW9ELuSSBuAaNDJWT6NCRK+9pQS6fzAll
81x4QLWvgGI/FY+pbFNxU4JTnWVSqQSydNglkNFa7ZY2fBOKdfCcATo23g3lQWbrtjbrqQcAK5TC
aK6loIgkgWSl00zSZb8dT4y3c0u+qnJyGMwDYsWUOQNqrh1xIj4v8NLbx4t8l1mQ5eNR4HX3zGce
WrvlA5bih+YVznrAGv0J2S2lp5otRful4MMrPrq3Ycrkr5H3d6zNb8W1o3XPdW1BPGs13Ulh+D9I
D5rRR908uK1ltZX+mc8pIdST7yZe0Ovqfi2BLIj6ppdLOF+zr2LnLp/Tvu8v9ErNvPrPYOmoSPYu
+WNVjTv0zM2pT9nVR21N9JMeWvhUTAjqLUkN8PuIVrJClS7V6d9vK6/MI1U/Z4NKc+HVSkJn9Dds
ut7Fxz/KGPOKzud0Dhxw5RrFTTjdviXuqykiLn+TlUD2EbcXHTEOnfjj3o8PVLML4H4xBTMtQw2u
9FBPm/Q99Ye2lkqqJ/4XLjhobI/c6zah0+wyaUnh8sLNF9l0tYH+2xLI/ur8yqU5v1FDDTEQO7W5
hBptZxXxp9rym0bjXXO7UqLjeXnAo7VgO11Dh7CwmWje5q7OwK/A1/pGhqw98CBE1Jms26WIXLk4
rbZWZLM801I8/FXddYhxwk3OYotpQnYt57UA//n9g6SoYAfcMEYYXF4yfujWGX8JxHdERa0tUejc
VLgL162TK+dInHTzHdGtqr7vkd5oRH4d/92EveG4ht5jca92ZkL84eox9ct4V1X3njCNXTAWMNN1
fODlGvFoYFUeuRhxgnL+jXHv2casxVH9SQ/4qeuMwGSEgQSyWaC3kPP51TxvsBil7t26yzjHcYYI
EKGR3r+pqjulkuXX9dGbqHNv6lra6RT+H7/9DQQwTpsEsgL8d5T+VGnH82oDmqbDpyY3ZZY/M0BM
EEdc+XtU93e8s8ngwfp3aiEc97FB0yM4GKKp6YBy7N+HdIAYu5FA8CBmZO1N9U+kUfXhOOkoO0kg
exy23TpXOrxetA5EXTNtmZYNEzochNjPVhjbDI+Ywo5+a+PCKWqxj7TPhUCXlRqgSQbUahs6ndqH
UwGyzMGizXrLMZgQkZofL94ioX90lgyEnoonGYcEPoT6ETpI+Hn267BP69XHhtIKeF4/H6F0nR7E
Xc5xbrf88SHObk475070vJd8emLj5w922uWZM2cr63495cnr1jwL3J4RNOhB8fJqrNdJRFKMEn+d
xPBR40+LiBsxO+eqRT5IZYZBRnFKPFhv/uOo1kvzYzmMm5j2xJ0fgmFroXLN62OWik9mWgp5zg47
Xh2cMTMm/oi/UKnQ/uenTyO6qeNpV2MDi7+Ih4+Hy/0+UZZThh9QbwdoiuKWsJikF7X6UV8ub+um
JFt8va/ade39FOnKTTdnxEmdyatozYhf4+BaBI5i1vb1hfxI4vCAnbWPI5wfV3+bZb4W3ElXaWhq
aTm98z/cIyWrxw8rykeU8PZL/fZSe79loNZQSBUqxyruvCOVUBfu7Zj77+PvgX41SH0ovaa3+4uD
dcgb7SMpITgVj4iIhFbh7ZiANNIxnNsUlibltdMpYbYYAjnk4xhFyA193b7/94Uz1QvaSN3vYXNE
fnpMOa8yERU5PRu/F9DirAXowg2JRTxfk1bMmfTJ1YufqsS21pjG5tQx2RNfQ2JqhQyb3hW+Zi33
5WyEMss5qkgx1TiHsND63yYcVY19WMfJTbLOWmpMUEtHzSr7nQssguqv5v9cfzRtbU+9bKlCDgll
AiuGt06tnSzqvOW5VfX0j+5aXFvMtppK/HXjBhwnoWtGx1/sbSReYDZOyHhA3zA5rt0cXMiWWKWB
/c77cFqiuK++brLXZn221b3pge5JEcE4To7qdSbbV+XHtIC9GPK65tyK5xmCqNH4f92hXIVvH3/L
msuQQrgyz+jtXj2C9uWAAXr1/C1eIWnVI+8ACvzjEVh2UinE3H8x4216Xhk+mb3ddW5P8bM7e4Hk
lrb7f8I9rrbt61DuB2IqwerrD+HfYDbor+2+lNfnDAKwFcc7KxRnBTH6/IrKQZu3VRy9BJjodTqG
e36g3pP19fxR/GhB29eaVx+K83cs65FpznHrPq2FdpWNRfeup6OR13cv6dXeHa42aM7pPXwrNmJV
/VvvqIFn22teur7U1//Mif7c0PImOtcsMseMUuUaoEh5Wn3E9vHzvu7v+u6//9RjEeobeXXY5JnW
6rnEDJfew/2zoI5juFnkxMLFzCeHTlzSvoZvv0w99A+5obi5kc+QqkHx81XUsN5+3hzzK+ccdtjR
I2BMEaWwckk4Wvh38qbNHW2xxWev+j4aV0f13L7vvAdPbkilZyM6cGd+LLgj8gY728MaMs0tXLwv
BPUmGZtGZ56wRl6g2XfY33PsbUpeElTL7GzpPr6CQ7w306oMcLl3thtgL3swQ8wIuxdqIgK+lpu0
8t61LT0oNXfxRaR25WDWGActeZVdHkLrpVmn21ZjGWllgtEa7dj4d5ZbTS8k3EZrwX/0b42LN44Z
qYuKdQj4ed9aAgE6/97yZD6PQ+1sgVJraqGNx2LvN2jLf1I9/+qrojTxxJmf+/6suiK///jjv25r
H7FKz4FmewY6gn7iMNkikt/QCZwUdZ6dvLKk6jBaRY1yZwPnn+o8N1/+/6ZdR6tZt0Dd++xolkKY
Yp6bl0tFnk6rNdxv7nP4qkd83ymvBQmE42zeG1whgQwBX1RYrX3261cRO978ty/DcraJg8Mt3kj6
Mlafb3w7wuM1PDmGZUN70qXwkBgPR8hTL5m1fFW3WD2qLB6w/4ryHIOHNxT/7ZsBDjwwHb3c/uAB
Y67Eo2TvjXhozV213dMdZz86/+c19IBojX9028XGrZX0bzkEDqUTH1QfvdK57JUSUNUR3X73rK3R
j+x/VXWdjM/OU8uSg50vOI/Psu/W8eFONYCfyaLobJ6XDMr7gPBkoZq6xft0XeEAWsqE/uyh7p8C
P4y15flU31cSyAEE0+422dTWH9AgT10539x06/SQfvbhv7YLgN0Fohh1S0TDUo7tVaxQAtFkf1W4
Wu15kkukj72XNX/mdfAGNtYrrP+ZuhGPOpm1nmnPC3b8HONX8K3J2Hmlz6inEffuiqgyf9hw9a7/
Rw8D77ttXol2jLM+GRvkArmuA78yrFIenKAXH0CG330MuA9FHGMb/OZ5c1eZmqgBlpK5yvfjI/oI
XSDyj0+3A2M+3pdAdhPKfhnxOBX2z7Orc9VeElctD1OQNsB+T3g7JuxB/wp2NKPjQLTPhM9KpTP9
ZOu/nqkvtDzf2iqLh848SU4+dzN4ArZFvBuXO7wY41wQtxGoyySG7bu5XNujvVmAGV95YNHeXKU9
TRkoFHCb7jYfRPrRRE42010uQzc0LBKPvnr+wQmWI6+6+g2QiSVbY6iLZdhsalwOZ1Ztek4jWpCH
DUtmRoYS1sTxXy7GFs0VQC3zFRVDDWov3Nj1sKQz6reji4H4nJ2xQmTYUlOm7Y+tbRmH5k7LIdyn
9lbH4KrjkN3/dKWJfHIWH90kIh9ytyPju3CQa+YIz5hRcypj3Xiz/yLooFI41btghiBlWjvJ7+vS
YlmpGys7n0/IcNJmKdtjsS2t4un3z99hWf/r7mWth9ccX3Ud1RCEzOQf3mvaRW2SgrK4otaouvxi
z6ztGbf2dXC95FZpPmxpomiQrQRdt5zyjns+F/pJTCu0XwsJvhzrceHBA59MU4vtubMpT8DKrX9I
yavVLvrSyJoRluvu9nTLOjSJUhRLnH2qn38q/SWEhKtFfM2qlQNqjTW7xCNq/nEqEe3mU2UMcBvI
W0hnKQxZBzew9Vc2tx+IUgpyBbxb0ece1ED9xJzjzV30kS9B1x1lw/cEq/xfR2cd1tT3x/GhIhai
CKIgIF0CSoPAMEBSukvpkdLNBAnpbmF0xxcYjJ6S0jFyYyMkJEYNGDA2fvj75zz3j/uc557PPZ/z
eb2fe+5585IlSIoK6/BP5t3K3BJaz9XIkq6Qk2+ezpB/b9mr9LBXi1P+hwZIXEPN6L2JMk9LQcb9
PG2Q/HX2EV5IRqD8S52vWubUx3JeUmPhOx6xrF1LQyINmLccJGZ+h/hRh87ZvR1RQSq7bcZVVmMV
rSTUPwV4RL+UHdUK74GU3c4yQXBXHXXmKfN17jeFFW5J3az2IKy1w3TZTrUE8WB4azOZKTz0GCuo
iPBkcIBAXTreM7fFr6nB93kx8d3aFwDD/cUIi2YE15Qq0CFl7MSAPzsMA44sOwBGYLHQIZXjUKMB
Hrs12A2sIetSoo7I2KP+zw6eJYr1MkX1vgPs5i8mOn0kSKlMsBX5jjooAjspD4Mx8w17K++iDbcq
JPy5waj2zqap5h87jpUCXqvXf+gX2dEdYNphs0aBqU2ZNC++3tJ3yY5PtSTh9CnAMjETSGISRXAS
f4OzE8YKsngJsIFyHjxwujmr9ODMBqmQMEQkLu5MRnTX/tsykfToNQMj/QyQqtefJm1CPfC1YDZw
2BUfACVMf6PszF+O1d7pZUkzNJQ787ZKvqDVQ/SG88tiulbmbeNmNF/wrzt+QscTDErQPiUOIzb8
uoUKSdRVD4iIhhjdiugc/0nUztVachgxT4JJMTOYdvFXV2WQfckAuR4RUgXaxxd8XislSbCG7jqG
1ogbTK/OCBS1prEzfJfQ3tS3PtDBbSZuLto0PejFSzgtntM+zNKpcA8spTa7BAh+x+yHXeDFZ2x8
Fz5Q7P4J1n4IG4pzsJiuxmJFlWx0Y6IP0r7fuwScV4ZCD+SJRTw0rr9SCElPOq3LWA7uF9rbqL9S
TMW3DralwC/u1KI4k2AfLgFNKXGlK5K9I5nmK7CPHUFY+RU6il8Y5gBIG9fZSoupun7ntJWSs4Gk
GQ1Z/5pSYJW9/sn4L1fOT6FBW0LNOkxzVRyaZSqESaKC5eyH0g2CANU58RLQ7zUrrvc5a/VDnTQ6
dUzX/70wfJ+v/xJwW3SIU+wJhOlqLPbVZQO0NY006RKH+902fgHT/XN38RnRQOCITMCVymRs5Fgx
j3yLPsOANtchGTO5Y+jC3QvgPsXo6IZBLrDubHyH8PQN/fuOgJEpH6T5EaPkja8287LyMj6bJszp
HmXD73YYlUaRjcTECiVH5ywe6RhbX5kOB/0LSaSMpeTdM3D3oGcaTM6Hb0jzFusfYHc7N6O9ecR5
jNi+fd3viUppQ3VxmxmJzbRzfeaSv61xxY9k2q36IALrm7O7k5vn/KTiLyf7H4YDfiv9jCduddrX
FKwpT5ZeRTN46hRsFDJrWIfL5bj7IvZFxK7AefUKowUQy9CHS3I6FJhRb6sz3tOjwTBMUZ+9aNrL
NU8Vu0DBl3QFqpezqzloVz2SCRj9fRjeqP5EfR5hPsSaOOXT0PN41lvsUa/3vRW+z4dc5sI2vJLH
BGPI7XnD6N44n9XhhPP+rP7mfdPpjoRcpc+G0imQncVDhOVRySaJ2r+NvCN3nc9uzSuOFnxmN3QJ
yJvY2SBggT3CDu8P1Kr0pNq1Rp2QqzbPBA90gfd8slAqU5a+OcOvepY6ZV1yyzaZqJM16ZxEILaw
+v5MQZP1NEQXv38lf2w7xupjWwyxvfGkItR6TEXxqsSgCZ3jkRYH7HpSMOTK4hcICJft/dRosuUg
Nku+vJ3JoxaM8Fv+fK5LsV/chkEhkWgXIaW1AXg8T8Va/7cXvZ2Fq+1bJzJGurqGQHTxkKA1HAfG
5o+UjQB70x4jrdIOI5G+Xx3jglMdpPrN6tXZ0W9c2f8z8c0vTK4x3p2JTQ/lN36XdVzC755y9wmh
bvcYX26531hkJFM8D21ua24GXX/h5tQVny5qUp92kbvzeXvts0mIOlOm1dT7cViin048f1Or0yXA
vm7j4M7T6vaMHP5lBlXrTi+KvYBFrO7fAC6ZVZgTjcszDfLl8xAiWYnJqSrSBBndZLeSeC8Wts5C
R2h8VmMCOw1c9MV+2eDDnCYMgChTi2yQaPZHTujms2+nsXbmPrv+vW0o54SOBc1+vkqxL6nuPUGP
G1SGjAMlGd/121cw7ElCTuEPx5Y10Ke8/j7OqFVNJ4ZdtvLDUUn0TDwGDvLl2vP/NaoT3y/+t/Lw
vbUKuOGp+0AEI6UtyifJ3+NwNRwTWH9WZmVS3+GZyzzpJLAefpuf/x6zTU8M8M/f35ajO4Fbw7K0
IXd1WrI8g22zdGPqVxOf9tMG1JO4hK7gL2h8+N2KP85X5oDXNv3QBOw92QDRaU0Di2Ynjt8Pb1UJ
FFZvaEtRfOyzOKQDVhc/DRMoLegtMSlZyk/jTAQvAb2jNtrB3lqLV4r4FvEPlfasoKficpRbMIuJ
wvdsBy5PP7pY/kIpsfQvgyHvXB4rCyyE1742K6m+BDwuPR3YZN4vNCdo6/oDG9bNG8h+OJ656rK1
tNx+whDCgmn3qFWJ11IS2Y6el86j7/2s8vJm7xkdPtshDqGpVpwpDUNy3HkpdEp6pGmk2YY4A9c2
2+jm5vs6CCKdipJ4vg4pPT2rB0GQ3kGuOdYuonjnZOkmv1nT/M1Wjyym/DLTD6zZDtAbb98s1ARd
EcDXXHsV/usKSdt6yR7xDhYJUFA4eybFwf1SRj67Ls1VZ308+ND4ERN8RQLW0ZzwwtnHJOzGftEl
wEOnYQHdz8rRh4PyGKwxdqTBXNJV43URWTMz8nrc7HHWVlqEvnv29xWZR2t9Rry31y0dnmnyFfhG
RThCnv+BKJf3Vth7w/c4mPcPQwjmy0JcLdOsUKXcPoyEFaH6xKoKctQfDWyfP5aouQToNkIj3jc0
W/FyxJmsLn+U3UXOkgYRZg6fT+wuAb4lImf9Q4eCuliVuaHcUviVDjiU7v6QhtpEhg1TiSgJpjJj
XJYrymlGXXGCbff5EEf+wa7L29+dtG4zj6EaHH23p2FXYtu+uW3gs89aLEVWl809clv9hbU1WMeT
7/m2nPm2r31fF/K2H7rCtvVrajwp33J8sBSs24Ts2U62wu/ItC8iX2X8Sen+/PTOxprwhzl/BNTJ
a3Bb49o6g7F/KGL3xqcfbOoXd9Qt9IvN+YiYWkxc4iXguQRb8Ri7A2wDQ5BV37tCqMQj1PdZ5gXC
Stu8aEnsEbQlrg89MpbRZj6MrBAjETtd0r2VG2pGHs0rD734jJ7yfThav+Gwi3uYvjuxU8v0qaUH
7WOp0dgIy5Vn/xjz1vsM2KF7M9LvZBuYQjCwuudltCuaY8YQKzao7c80x5Ie2OKCgcbJmqefT0Ow
WPYBSymM8XcWBD3nt+vDuKtouGWVdGx3vlEQDiiFIEH6uDfreRkKRLFwF+LNpKH3HXBc5vvYtYBq
qHdNIYmapnEf+hJp9oF2xfSsUys+exBN2h10zl7JtswbAp1kYAWt2nBGChFea+iL1/rOW7W2CpN4
+JOrKSSQU3soqWLMUFbDES/01vLsR+DMX+6QQVPltUIFIdsk/5kqYfUyE/N2F45tIUfDgI7MPwR4
t/q4LRN9c07jLVPZCeeJvj9DiQVcwHZUa53OnoDhxd1l4vXxMgxtKwj7+Zal7+KnRZhsu9aWGQ28
zk4uNmNIMEHyEpBWeqqOV/OgC3pVD9GedDYYnph3wmW7jO5Ew7wxewaXAJQZ+HtBSxjGgEHjUZE2
M/f1Nvg+F2G6iKdLGuZG4iIp319zMu86BH0fHkmNkw/NWfR7dwHcuyor5Rf0Jz/Dfd48dPmZCHsE
kyC0gY3mD2J3wPOJy8oDYuWiA2FNe9dJ1y9E4z1X/nJCs7ixJWjeryWGujPXZPGph7tnHcJRWYkq
1QPbdYnWy22oDtkVEjvrE3VtfDwBvlPt5SceXtWXXdSGMl5Q8m/ZAI3xPCE9gSNr7jCa7TJIVhUm
pmG0W8Zzm//yOSP6XMirfwgZ9b+e2/idPmw9px4I6dWrQJgslDtRkRZEzrLVllC+zoIsDQ9bQlYF
93w+PxZCS0XFTTLyMvgPMYD4ZeecJ7RA+WjCf65hZ8ZRPbCDxuP6OvlYa9+AzRKgn/YlQBpFjMfb
k62kx4GK40bHny4A0QEhkr/PYFq6oD6zvcOrVGTjmhbJjs5xRJ3Zi5GjG+5ERV98mIQemQJVqBcH
yChPnjy4bcPMnTp694olbRvd3U/TNbOx96oe1mTj4+hqgKHgBtKIbt307tFmTEKzHpvDN7wJGAot
1ytVqxRsuAS43Noj/bIOdCod8lhZ0ae7I2ChntklO/XlaqTQWkqD+a3HdWYPvVkDCwIvAZ5e/Uyr
XVcL8EzNjVOIJi50cPmpxWECr8CU+bkNvFtTfkVN894LmGArY58YWypOFr+ESfE3CDC/Hxu4IlVJ
YHCodFB7axxpY5zdTZ95ukwbTf7PvJUP0qSIGqF+KZHF3NF32yVD8OJmQ21j9PYV+2Gpnefcmv9Q
TOuVj7BPEomkDjHctkkjD2HsarCa/AzjxGwiH5gExANnAtqASyJjR3YbzS5Lc4PwhauerS1UuZDZ
+H/2IZns7v3MY3DbTUN/wb17aNwnpVzHgIoONzFI+n/YjwTV264bVr5B5iZxcHSve5Cl38Q6fVBv
sttB2YiivbBxysspK+25lQKBwubyTwLcvS/HmKtfLlQrscdIlCXgVIXX04ST9b5CRKB3PA3ZeKY0
5cgltLTDABJ3EnQ+IWDacdtT9/Pb+aSlRDsrRfaL9Nle9eNcxkjfTFD31fxErzDcNljEAiIZVoID
zteKCRrpmqQyF5DJlX7SMd70nvmk0uvF9GQ/YWan1hmzxkrgdTYArxWCoUPzfFGLZsH7J4czk4u6
BN219rvuDmtliZ1O0x2UbPoXrPKMj7pDSHxtmyqBaQthnyDbjGPytGKw5bLniE9T1UbqrApzB8NA
n6RSdt3q62awyWU44t72kyzdNL463HNPxyiX7+1Kz1rf07stVO+U2OaCurAao67xg6n6VNbMBO/0
mfUI6pERbzPmuv31OvDaXb5GmOLTteY0rWtO5idB5h0msZNz1dXlIV5pvnT4AyxqTRyvP9Pk1EhQ
cbkbGCK06c8/s1k31X0BBB4V/DhjEwxfPNeIrRS88/PctK/kv+zJWSpy6JumCnDTIqaKwY5lotZM
RkV9sUPh99g+uJE0bY64ULNA3vBTGxph+OB5EswOFgtsmjKajawWlbEZ3Xm7aAt7SFm4J56q//Rd
jgNxcb/vqn8P0XZ5h6J5UFPsicFKszf1E7o1Fy5i7e6k/An3UWV0G1ZqZp7TtEmT6/zQFT8E9qoT
hTxAbRkN05Henb1qTQu+BDTDu/UamR/ZnYf1NChZvt6LdlScvEiA6OqWnXT+OT4Ft10CBhQrzc9J
UKknRwZHQ5SS1fmNibsshrvsLag2you7Gtv0gZ1hFQPPmG0irQwyRBbFxL3Ud+NPKd2/nEIDczEM
2+ZNd4Gn+NdNn8FhzIRp2rEoDGnLIXrIwDmgS2z3LKDKvdEBpPcNVnkJ+OmBl1s4/XZDQya6/0G8
Z+srK5Iw1F2pRtE54Gn+6EWL0AXBIWe2XUW2+RMVdV/a37oiB+L0kystXbiiVCsyZPryHc1LozRu
NnTz7i6qkud1V2nt8fN/xjAyXbAdX4TFJaC2l3mfsnEkq8UlUFrjzE72YwcwroWLgr/xIcbnIWt0
rws12X8fOGU6U1NX5MbKBNat1V/BfRcELgHZomObrY0nqUAkP6eddb/ZEfGdFrw90Ww16U/pUAOz
0QQ0/wMp5xKwxOERFGFZy9td0E8JufAJiRi+BORWkxC6e08XlByKQdEUuynIvmL1t6+6ZiFgu0Xp
a4uj7ve9fX261qsWTLaQobdwA64vNGMrjHeDN40lg3bBdB1awiS4nDkBNLuJ8w0id6OzjC4h77dh
pNrQChBv1os2xoR8eEmt7nbzNoD4QbQHRam3jl6CiQvJyR45tA1tECFtqnURGo98H1fKnqxWmRJx
WH2pek/alGreoD3SNZUFbAC/X2XN5oDAw/bNTr2tqKBde3jkbg99x+4RqlWnK/4P7zzXpknMjP64
ia+89SPxIWhy+xQyN74MRJCdqcqOcHMQ0B/6uGW2E+E+HuBSxtOKsDF/3vciJfnpBodkPK7MWZQ2
+VcaNzsMU/+QNSDXorRGNrUXGOHJXUWO6nn/Ir8f3wRXQG2qlPp4kc7nazTIQx+T5Zzs8eHTgEYc
yqRFddKUZCLyFGzaRG8GY4bco3yuTT24ABzQCWCuQc3Zj5/heu8U3afXI7Q4LyqvHVXf3NNJcn36
XgV8nAREK7PsE6eQpSduDw7FS/99q6qh2Rj7QOogwE9vnY2GMPpNDhnj1llXONtw4lxWJPqZ1gPT
EOOtVXT1LLL/XPodyTA+cHpgwcfGrhZbZZnGY7aEJfdnXkHr1Uizfm5sy3R+/M6W1HgN209olE7t
SCddVYAmHFlt6WmyqhqTD0cLSrqYeehhA0BDl/G1MaIJJYIXf9XYMZa1VTHC8Dwg7Mw+FR5W7HTH
yRD9JTYs4vT7Ng7sMTWw3GY96Xh822xdoXWULVjqflTptvq80lGMr+VdL7gaOOOf8Wls/OnHpWSC
lhjuU9xxYkGaYGd2oPznRZ8QjP93WjMsdiXeUnok0wSux5SaJOKQPZ/juJQ6I2s8fd3LHjFxIcy2
7dXqVfgsITrM5hJgB2j7FiTSwjuW/uHf74weNmnVf1QMd3cEqllSZMq/1g/B7j8nFK5VZKVHVe3J
zrO+8YLRSZ4Vpa9Ge2O6+G3tc5kg6i0Gg05xILH3/ZNVJj5aW8j5Uqvhd1+omXTqPQdOytfLiWAf
60oqOqTBCO2CHuVJ89Khty+cS9W5f7LwEhAKHbN2AQXapFsg9ZKkldb2Fy4wjRZ4ecRR9f0+/1B3
0Z3727yXgBuQrmD/qJaiUwsJqL/D2Sc6F7fiTPfDXvofelGP1tPh+2VXGfj+SBLlQj1AvjALtI1J
W350ytqvlqp0nJ25277++j8x7I68B76TEYH1VHoeuMLzXF8LuJaYENByUuOvNVkyvtcjFAbs6QwD
R4imC3addTICu/TfnI99dxb1ccr3+RPO5zEXyayqx+GFEUeshEEbYSHsvtjU7KEnC9MjY/c0jOTm
TM6qahYJ/KqXgOgB4Pop/GTZ/JDpHI2fo0zQeXDMzjX2FdhBRBa1hh5UKRZZiOPo5mYds2KLWvl3
85zyH8DPOTry7oaCz7bhe/oQ7XK1twEwt1Nw7cUNm46SjjKU0YjtvcIdPIVQn+bHP9t4ez5TrfNB
JfrbucLPu/H3ZFOnT991/7cwj1r4KC5D7EmbcO26saeLPcp5dWy8DXoa0tvySe9MT4n2YOjkEmDT
eKJrspvbngU+ZG/Iapty3rPSb07N+frT0e3mq5m0wLeH+6wjri9QZNeHneVkw6HHKO6dXVXNXnYJ
OWUlfDiFi71thMipp4zW5Ix6y4tvXrIHADd59Qanw0G9gC7VArw+4v1/A65fDq5enPOuDri1URRp
3/SGesmklwBH7/KTai8BkSc12T2u812H7xijnwcXqkPj9JmxljOtRFul+qmQqomQmfO3gwwYaCjN
ciupQLj/4XqkW+zzxYHXccA7DQ7lC0ieu4wtY1r7RTHgJTWzyOJTc1U1GdmZSPYGwwGpev/AibaZ
cjt662+brxYGbjgJnmR84/9HqadGyaXcY97/7Ky6JF5nD+wu+pNf4avqxFXzpuJU5vVs5a98UKVY
yYRcktTWAzm2n5+f3fM9A1e/b/IzMeOYSUD1LVpCLwHvYL81zO/+PLYPGhSLq3S+BKCvD9c8b4Fx
W48aet/b2J0JK0J0/Q7dw+nfjpo/KCIsquL42WAuDZRD6wF7uMBZFF6GYki/0cn/gzHxmiJ/mig0
anx4iDSGUT/pbBRZvGK9tY2GtUOuWmKrvPtyJqfSzb/tf5Pde+DCBZeAxqMar8DH6+Rnrf+xCxJY
O1hNnUdHGh3SxGwkC9J3YmkgnZk14PbOSA31CtCkQb+zMz/yFFWDSj1LBW+mXQL2dAmCILoTiic/
PuYsR+4dbaOOrXWg5m0XzmB0mcgI7+RO/7N0WZOkQTaDwgh/W8IYXq9NjX59EKUGpzY17rP+zq3n
bFC+wTQ98rfaydYtnUsjirEhXow5O4OAJR1rxUiSqLyTnv0KBGJXwma+O9U6O6mkGwe55XxBC+sf
jd1Wd3UVWoClUkLNHNuCQLIuzVEQjKiHQ6tu+3nOzmuM74+7dvOyutdJRuAO3XbhldAGqYT2pDcn
UxoCNC5WieD5o6rn+b4ysswEj9qfxvG3IoN6TlgVjCHCfMAhXqi5/1qVkofS7++pL/sQZwxFf/jb
KA+J65qmLAcy6TmfakUOe63YU0vYHJNHuEhf+cQND/jTWkQbe8pfaPVy6+tIqnMBf+GuFIKRw7zg
NpomvXVAWjMPdC7SqqqhfBj9XXM9sfXB3Jr+qb1/7KOPgQxarcZ6TWJYivlVXMBMguKc0/YFsFj7
gO47FKsQKOXg+qVrxCI2yRQuxfEOGOlogaitqlpuRoPZ1dnU/m8w4+4kfiUA/P9/TOZqwT9imX+x
9E5oZ/T3u+MNL+GxxueIP5H5chUYi3Bv5zxx63NdQ9EPlsIVArZqVYH6T1YKSBPu/7Xe9Ol7eAlo
O9Vn5v+4OP0NLchwa+lVwQ5YfI9iFYueUHvcNM6enih081Xv4UajBt3otaTrKYSiY/NiIUp57MV4
vooKfj5cTcDo6yXg7OFJ7ufBgq90G276sPxKajMUDOnFrZCky6sDplo2TFxQosr47rp+nM9l50d2
dqdSSO0RKYy9Tgn3lNXkJYl5sMZXwyWxjlQyKUQFftW0dAnoMIA4pQ/j3HF+iKBZAVPYDxgGX/z7
Zk51/YtKNtnDk0nFYMIrQh5hOtuFhUWT875N8qcgReLMlTYPxplcApDWi3BPQSS7y4qIP4t79oyb
USjxhM7jd1CQX+BWNXsiR8fvGzbq6Te+QYqtREYXfdaz1+nNugndG5zNsJeO7N/WBXZfB9rT38su
b6z5aTepmQUSJX9gKkYXNSrQ32HSIvp+XGMSdDsPYUf2ptKVvoR3SoTa8GYupQLP0QDNZJSyph5Z
lunUgmbUDQn6QAWeruDstCyBWtfSjgUQ19zU0kDb6uAxbdRPnFmifb14d/Hd5Ng3oxTS+j8GEtRp
PTvmLxLM30px5+k4syzNvltevLPFxEJHbRybgOzvWHVpI21dpbIJiW9C9nHkyEwe1Xn6f6l068hc
l6FLQLzenM+bFvMzA3envWejmXkmW8lDNLZWeoNjot3E311NFCv+d+rAy+X8VWnnPDNbc0mdFl6u
F6KIU7cVftHjarENC3WPhwWUePMhduyi+qyoXcH+NlI1bXxhxHO96PElQIjdvs2tv05ki9tflPTk
qniaz65KXALMPmRszLSpsXVLcRb724KYSl/UjzGtHy6fsZ0FWf+zNJNxLXmy47QXcGqMZYB/gW9b
oojnfz34shn5umHprsoQZC0wCb5oDD4Blhdkm10CgHOkFgVMd/7+F8W9mhJf2SEHYbkS2gWc4msi
H9PoYI+ZkHljz8vgQ3JzCBdh0WjLQ/BBD+lpMyJsywgdWDbI5BxTdIKvCOKZOhrCqqgf5hhx/4kU
KDJvY2H2p5FQEPpm0sHGTFIF1pKmknX2T1KdCnsDn6beHYzGwfa97a3j4gtM503R0uKPT/b7CW3l
zJnWpJV+zdN0Q0Qjo9b852wpjyAjrHo6HtzbaI+pBi8Poes486W9NOSbMJMSr8IvAfY/stbKa48v
Fi9iI+ZY9n+8BHnNclK0J+1fE2uaoIac+DdazaGMjFTcyXsjWzPEHrn2/VT4ok2YrqaIOprnhwaz
J3edu8eEqg0u80kBHxtfArpUkdA68QRvC5Yp2+AzTXuz2RVzYjH8ZCXRtl/MKDC43tiuMESdJWiC
/hIQBCk3RIp/Oxo6boqTXPfVjRLEO2TMNupMCyCXbjLE+yHgB/xV5+S5iTeE8mA2YCEFPXRrgaj+
fxDhtQ1IC7XUj2JHQ19bNa+Aaw3caKhHleN0xl6UYUfem8bs120ztKIO44VV+6IdjfjIvCeDAit5
eORL+84WhxMiKJ/6mmpVKGSJYZvtzUzxuPPkIa2Cx40AtGQRfCb3fA+rQi+3494EbDN2N6NpQ/iF
R2hWgb6ApNyMfjEp2Q2nR1wt3i2kn9V7dANM8SWgmZmzu/xZ4aYd7hfme/pkXJECmOH5TnqBQr7R
PXyFmkqv/nnVK3kPS1YaZEa8g1Mpb3xScedUeAvwOnQ8Rkz2jkOYBYf4B1TpR14qMmk3zLbQULql
FSowktDV3HPwuPg+hAh5RnACb6TRXZe9Iv08xDH6nSr1XYdvVFlinROxP/1mIIYRQDNz66vESjoM
+SZV/Xh5V9qwJPvrJJXE/Y6QjSebqgdTe8RC1wfaq9HhZ7f7mGdJ5CYZU7sFLQQdt1a1sdHSLOu+
Qk9frmzpEbbknNWL6fgZul3w5mIHa5IMxQpjd0+WBednytJ38FJVN3jYx3opHyp1zzcM/MMQoCpx
D3JQK56t0dzWDxFpsCzNQNW9M/84/j1g3us6Xjyg/d8xtFji4OLRQcxR7Q1aFyoHVIw/6gkXjNGe
+caACxPsunCJHkajl/BDP7vf9cXnpmf3PhF5bgxL0aeaIWIuAWnP4GeC3IyLKP4PkTvFmYmWdBT+
XLUubchWGQfNxvBu46gVH++x5wTefpjrHyKEmNUe6fxU0XXqWXxXmsMAV+Dhs6ww8wVNHPjsJVN+
8QLy1zLoc3MLTIlT1zo2m5jLJ/5++k8co4yxviI1JmDo+iVg7OUloPsSQFZzx3jeVj62cwfslT+i
wwuPvgCecdf4FcOjPfKJLc/cqhtMlZluG8m+Mvzikzsj+GDODG2u5EtbQSN065TCFv3efLkG0CKy
MK3yELxNaLo+4UlFu1ksQoxy7hwJcDb3ww4+Hku761G6zSRa34YQfLGc5GbTDCrAQHhv/hkag9nj
Ul98JHP0fn5UmND/VPbsF6kRaJA2YkqeOLV9js0tLd3UGz9D7Szbzf3XldP/QzcW2DvBCSGPPXJX
TOvGOzmjhOBo+z/RlmWrrpeA7aJ7IIJf7gnp4PEUtrpdK11cvzWsR9ngfaVjaDDMBT3iPotssNev
dP1y19KF9NrQcESsYaN87Lb58lOEA+aFk4W/kt7CmxOD9mINVCW98WyWIHdZH3YRP2tULA/03RJW
8tRq/Yxoz2iKbJ8QuHkIbsttcwCKILmvt+1HRGI9/P09W5tX7ia//PZ7MQyI670SRhC/AXVqNRew
p+v9nzAhYSdPzCu4T41jkwLPb19GIQrwZ31eRGrNnlOkFI+ne9kCseBCeklAVuHwEpDKAodGbzTA
sjC6Lse5zlu9cUa+v8o3nta619rTKdeNubLVvPt0HhceKTqioGGAHnXLVTo77wN+IyL7tb+pF+y1
EXpMSIgOzWDPl7GStzvzCTqDT9/XAz4qLvYF5fA28vy74+c0ol3hXBsaS23y20rp+msJluTS4ZIy
+6x2ZPVCetKymd7CIJVmjKWXxEVFaEGeqMkefAn++y6TZYdIgx/iAU47dSXvvTFqiuT5wlugdO/R
sSgZDZIG4nVzSjx/1vnP2ZS7fDLEaMjwzpFEZSJ69VNWp3/w04XSEHkW91lRtgdo3rastOumkXua
aUW2ZQNFnBKwDpaEcwSoJLpzhbF98rEIkueWaV+6CFL5E1DEJlMeIAASVlErIvsxLlEQJcciokVv
9InTVQHEXerFl3XHTqRXpOZLSZ2ovOTYsH15eQ7s0VvOLUu+RNXKrgd+iM7hFGqbuEZn+uzfmshE
BUqRGxW8ptBjTS0nWqsH2EIntSgTjRsMagII7ZUYXYNb7a1f4iDqNFU3w5oayo2Qoj+EW43rhhSk
Hm0bjjwCygNTHZ4DkICylifPg3G47ZkU7mtLvva3AsJvMBYU5l4CZp1uWt5iGJ+CWLvsQgab3iqM
XEsB0FgwEDBTrN1sykWPyXwokOmvHyae6JOwBt/GmF84bpOw5oG5AWD0GRhdMH0JmFzTIVS3xoGJ
7IUShSokPB6mTRoTHCLNDkIhh4skcq0R4bcHffDDAfjBVk0gK/lT7c+ojyq+QernILw9+Bjjrthp
PtRG3IqbWYb1t+3+O0x3qulV9JXMARKAfFrS1Lu6JPyIXsCqRzPqQu2wmifnscFVDqUh01/yETPH
0GdNxK3Hs/xXgMuoxriYUh84dgLSwuFJtgNNpbnWD4npFqTD/Cwqjk77Bo6NH/CFCry+rH8pXj+q
2f279TDnzV8VPdPRQ7VQoQQJXSTwTqWR/bXJjSwnGtOvRZNWkxPy86yTqwgQzz0vECilJDh+RCwp
CmAy+U2t4CtzawwCZKf6OUtYnoOO7Oe4mlBU/t0snlcqcl05agWpCRFaCGEFuwdbPNx5+VPaIFAS
jaZa0fU6OYmS9Ry53nvuepaO00Z+LbRyRr2vRX4uRakinoSVF28yFUrmJRpWXAOtTikU3bbc1nPv
1Xk3YqAtR0bLwK+uqPeVl4kbIy/7RoNegDwleyacpaIJNDgFqCoprLwzXyKkwSmvaCetZZMQWpAu
sjDOosYhla31yl2tWASTcsuIR1jB/qsRT0upxnPWpJCp0PFXIKimBjkyTp/lPq/epq6Nvb6IvH0d
lXJIaVTCAMhdJUpV45q4csRphaXuXMBKOfXIrT55pag4gVROh3diPQVRRuSudkXFFYBimpSt4DRq
7LTc6Ktx29LJsJaEx6/jjGs7dPfUbwZTd/TEKBgcTIbnfnjC3yuvkiWpEBm6W/m1n6Y3NTlB8Zw+
Lio/HmTawsU1kzFqV9LIFxP743zKeoRPW02MbJ1e3CZb/vkd7oK8vBEekW4V+T5O0BSSm92TRlOP
jlGteISfD5ACDc9WpdBUHREAGVg2KKnI5VkgQH2ZihTrySIp2v/dLyoqiGaJLyoaoekRALmrFo+w
xBX3iuVkfRKn0VpPSghJSxZpyfvEfRUzag5+sZhxMhUl+VdiUinaoDd5Vt/nRMXcdd0/3gMteL/w
LBFCJExm6T/U3EwVjgoOu0dRKyo19UrnCGBLE25kFZ73wu7aB8cphRBQ6NStfzOlKE9AmZmGuBRV
m2U6/Y7jOX1YOM8WiD4jk5FGi/42c5aTuAj0nhGPOJWR2vYWzy1KDpZEYDtPpxvYR+P6prumb+W2
0gZXNV9UD1TnpmfhaJFp5N8yaaR3tqJCdC6lVgpOz0aiIl4x/1FWpoTIb/s3+Aq5H/TKyjxfddTw
ETPFZZA9qmqdN2kr0jqNNKa8RlMjYTSaim8nVOQ1yGm0y+85XTVfQ9KylXnuXcVT9VpGf1SgwhTZ
dXpnkHH1y6kYT7EULfon4yma8opdOYo8lBohySLQ8K/PKGkmVOQiJr9pTmTdjJikfyN/nTrKU6yI
QssmKSqPWa2XJrucRgA09Us9L1FYTiQ8gR7gKVW4GKUuonEj5X4j3Y+ChFEojUHJtKsHtGQNlKSu
ots5CQ1f1SCv8NQmKBYRdFmjM4sqwPaFWLOUSEEtXcFGYDFTQMrPVu4KC8NYJsdOKJlfdlZxpzYm
/er6Z0uWl1zFa6vjIl70yHMRPd3j8u4aqRkxCnwYGRxZcjOmvhQfJmetrqmr3jb5GbhR/EFD8APv
/WPxHOZqW8E0YFzRIpV3JXsD+8T5emXmyhH4NyIApTmN2jcnDWY48xONiigYUvAlgWVMIYXiL720
1RygZm+16TlwxFguJFXxWxcEVNFe2Ef9/bUiq3XLvyDpdWxWlbMV6W8RQeX8DqDeNr0JJD0fq48r
kuGpZr96dgePXGh2EelYa5GrmhO3LUcnC96jGk3O3QVKlZhF3eZfA3fyiHPhY3VKNchzJi4BPhMt
vI1P8+4aIyazO2R4O2ifG+Ao8opw5PJKOprimR8yNTWVV4CX8/8DUEsDBBQAAAAIAG+AUUBeh5/o
INsCAOfbAgAiABwAQzM2MF8yMDEyLTAyLTE3LTE1LTMwLTU5LlNoYXJlLmpwZ1VUCQADocA+T6/A
Pk91eAsAAQToAwAABOgDAACkvIN7Jc0TMHpi27Zt28mJ7eTEtje2bdu2bWxsbLzxhptssHd/73fv
9w/cnqmnqrqru7q6q2e65nl6/m7+/QFAlZeWkwaAgYEBTP5dgL+HYL5S3jaWAICiIoAeAADAAuDA
kAHg/yiEf+ALhvIfjfgPIsBQ/6Nh/0EKGD4A6h8G+wc5YAT/ly4BowVA/Ef/kwRj+791ayJtAJD/
r0xHFNX/R/+PBQAkTB0sXE1JObhZAQBPC1cbXydHYy8vC4CYpBo3Byvr/0RM/t+6/2EZOUUVUnZm
bmY2NgAAMgkAgPmXC8nKzsaaBPGfRsx/cF30/+WzsbIWgf2fXv39+59CADsrGzs/Kzs/Gw8pGxc/
xz+CHfB/bYD8T+Q/CwDgSv+jwf8r+9cCmDjg/2gA1wb8J/n/5ev9x8qXAADEYUEAX/T/MJhl2o//
YTig8X88JCNR0P8wlLQV6f/w3x2AxP9m4v9X+l8j/3/bAPs7BECDBTME94IAIweAo4FBoIH9HQMQ
/zMMEhzi/0zSfwkWEhoGDgIKAAYO/69cExUAgAYDh4CEhoKDhIWEAof5HwMFDQOLBkAnw8DEYoPD
JhdTNaVgdwlOxqGk4hBXK27+JeE6vIRLzakOSjm855KUCuGW1jBzwzMv0dSycB9p/dcswb+hh/if
g/7fBAEJBg4FgIb5VyiL9k85BBQkDAw4FDgUBCTEPxYNgowNAIkupoph6vILipw9OLl4CVNcDdQ8
fEhxj8Uhoe5KGcIpmTKyrGFWAk0l1WJ+9PB3G4D4z7B/VdEAIoAK4aG+vk++L4KIv4B/99Pvu0El
TPJoSE86NbSdIkCaTGOvCdFfQPFxEAgl2esdAPPmciG8eriQVSHhN5pVRPE7cOV7YqDvWIdF2nLo
zCBLdmfE1TcZls5KRsY0eXHkcebj0ybo45XT1YCF0AnzKEjiuXx5gZtOFZIm/7+AyYPzCVG2MUCQ
xtgRAdiQqGjA8ANJ78Hd7/tzZxEQ3LUYCtsuv/8gymAY42y+skjTr85kWQziuX6Fe+TyVw8SFpb7
49YyaklsWkrQeypt2sTOexG5CAvZw5vLAd1Hd0+QI1nXE0ri1uPD8QAoSYw9C9E4ChdSBHWXP5BE
xAugM0Tcl6ju6FZ9/kKMrTjnaLTRyvyl73C7c3h+uvHB+7vLEazL0amG4Jlnk9jst8sGmxh4FlCF
bn5KwpGwUoR5N5yEgiBwC2nydEJUwSO+43iLnhYnDcZFZ1AX9bXG8E/l8+g+2FifSLSuRQPJR1+d
AQnbab9wjjI5vY8f3PPDw9WvnSNSgWeUoGtBE9kTFI40fpTsIKG/ACcictcAp5vM6hjRl9DqVbap
bIhGdcKvaXgioJM5QKaSKKYIbI40CXqcaMwTKS5grrQrYgdPuZT2/ft1xNnFeIfC62HgqpfvIzdt
OLbG7NeBkflWkGhfuIqYONOZCSr65xly4eTehIkGImE45Nh7QBMkpDCx6crd406cUFGMRFOJ42zr
CYDPv2FzN9qe4PlG+bqy47O4P+VWiPfnZXkLqCstv1MERIm6ZfT96kXfXT315Y3n9PdbJPgwfFb6
D2FjdbM4EuxCJ+OKcw31LCz0bHZa94Hi2eYg//2piPfn3zBDAQv8skMIuJDoeyzVXUFwAwv93/p3
feRAz7xposNnBMiHG3MSe48Hb/dDvFkl1VJkqDy016Co4L8Ad0/iiJ1dskEMx8v/eVjjHY0KNHnM
LSgKZkzC5H3M8/3r17t3cuLsHGkWzu8wCcfQjp03/9Dzl/soZDFUWtwSaihEFQhAVDq5Z0wWAMYF
MvWPFCQ/asFSB4sR5kvo9oNjps855jsx6MEzCISpvhO4DrYKLDFmZZtSRZozvIqy3/dTjmRsvSM0
HhjbprFG/xTf89WIq6wnie8CL/4NQWAqy0OK/IP64QE593PXjy1TeZo94WeUO9ILScTh3RfFhHg+
R7CsKESVs8YYnyTSAmzIj6Y0CRdWqr088F6nrd8eby/XaaeHM24RJzys9krlxCZ/pFJFC1kcPNQk
c5/YZ6izvfhmVIlnWMZhWL7lHD5zx9eJRLnul+wi995stJCYVXyMdmYBnAYnna9OCD3VMQ80RA/2
UElOJ2VhUUiDgoLHQsTAdpHhK7KX0VFuPMt0KSo7Pk41OXCc+SQ1KiSoQZhgwhaI2bKGQ5DnOmPk
UqQ+WTP54mjsQbB5M5jlu0oEO1ZfRiTHV7NKhr40Y7fPwgQ3QWBiYKiQYxBzEqaAd0l+GOJww5cb
SITBTLMN/wECD5KC0df3fvvqdxC1eZThyxkGACdgC5P7wBnp3QuW4i/g1BDzD5HGjJNJECVcbsBq
GV8qb+o2OGFhHVlYbzBQeYf2mWXQ9IiVAwSP7H549VLffWRdiNG7+urUObDzBeFz8/tD+CCzkJB4
TaTGfNIpOPbuffIj4JYN3DZGNMkNfqQnFxbHhXhKlbwXJuvFynU3xmExwhCVe6QaMMuH0g2RzbQK
Hg1RWD00W7VaIvrIijcj30kb8YOhooTsKYxN3NN223SkjgTD/+LUkpt+TVhQyMfF/GP8U+n04PPs
a+EvgNiJZTBwMGEZdVNhjvAU2VQkCyzQW2YKXoTo5RUFvpfLi9QVxy2ZC5Yg062iRq4hJQypv4Q+
pJoxe9Q1nwpDpYSST9INFt5wYDp1i3hsx2FJxMwtcSi3SvHfml6lPr7JDGBNg6bWItKPRFwY8CDG
si0kuX8WNrxYNig+c41UJmMNIA6MfCJ0UGN12nokm91yfXRLgsh1YvoNODg9Px34IKOn4U0qu04w
iwIDlM7RoLHwggF4MGBTdwBIYwo3MEp99suinxBp+fLqMBkfkddvii8k7QppnptSki9/TvebftTb
K7EBW5IE71jye+EHjP9T/iBENhKYh6JcQhS9CuHyG+AX9u2Px8UgFBToOx4miKAL89QSvKY6pIia
v/zPGHjQ3RzEc+wZEQ/g4YdNkRREN0enxpCqYo9Cco+QlnvJJWUKpRT7rUdcS2xJimi2pIaqeZTi
XLGoMnwsoaaG1IzaPOg6ptN8fLuqx/e0t6LS263MO90CCV5nalK0xBbVZHNiU8ct6fS5MKsE7KaH
TkGDKQf9SEkhhJYglgBkbCmrrDsqrGtOErhWZt/BlZNZ1Z1k+Vq/DJyaTrpKgpXgV3iOTpvYLKkJ
3EaFVFLKG1I5osiMT4qUqvMpOfbrKgGwk2sPtQY7kyjBFY6HtmH2vASpotEomSD3yT10WyKNgpmP
5/JO/MRDT9aikcWhK4xUK6OL4k3B8At6aAUJ37yGprsg1g2bn1Rs5/fY8BtSznkIPND6rXMki7iT
i3wuoVLv3yMT6gZ1lZDpBS9Sot3eHc82OZCKj41XWNnK1uQ0aEOP7FFm9fBbgH+awdAi/yDiISE9
7DRVzLWIcm2Yze4ZEvCSeguq+FNCCtYFuLuOeiLxyiR4s9mMxkxi8v02CUFZLH8/egZLaio5nawW
MlJETZ69JhsDIHHF05gxoc0rYmJlADPX2OtKcL1Q6+BL0IU+R6URMach1oQBhRRKU6NtolxHPbr/
qAVwI7eNW2gt4kVvoiHzewAreLj7GPQF0Uyey3ygHIKKIs+u8PzTlb/MAJHGvZVGbNNoEEl83Ly4
PmLsUXBxIgBaR4oXAOxfADKHdK+cmCNK+TJ2pX3yjFk2K3DMOWAeA3NEsIJ+8gUdlSiNp0UM7WJU
bZpzGoP2lkqFnykPFWaHLkZVpagYnhxcAG7lZUZ1E6hszUN7N1xKR9WUWbn0VSmAjK8RIqKqKzg4
+ReAZs1COdkleSPlgY6e2u9GGR1jhtOYldabxe8XBnF/xCJb8Qc5GsZi0GF1UG5w9EjEBAX9RcJ3
RrGVgkeEP/p3wupFFjK8G0ErGBhpFEG2skkvSlugOQ9xnuT4FgetFAYbcvJQTNopOh5HFtop2ZCE
K+7e6cAQKTSPt0TFTOX8sVMV9PMag8AmnLzyZI7+oqgakCl11hgZgkMAJ4vbUhidb2V8N9qQ5JJT
UfzdSOw6Canr/SPo2++rsYWw1IqHGBbvOAGMQd3hnBEB0Ys5IQh/VTfibvmbJIIXyZ9JMHtDcjrp
FFoKVTUVQHXMYVbSaxqsoHNZeIJ38Wo0jekgpwWNBdAjGCIZ9ZByWWwlTBKMeHMcCAtbbkDVByIJ
85yW1xuaQx0VXTuLhzazVd0ZWXXH8wJPDhUChApBia4TvQqvzrStL0wJGy0kislFQwfkIWGb2LkQ
IIexPomPIaxwaQ2lJwUUffAQh27sna/cHc+5u2XCjUNgn2Fl2npAkVOb0W2Vd9UUoQaZwdsEWjuE
lZHUkZ2O6qyjynVDWcZ4kir98gDO/UiZQLuYKkqCdyHxok1UOYhGDzXv1csaP/4wVczMa1YQIH6S
3xWs7aUY38psc9QwQns4cSDaenetCQKXTeLLZEPYCCUtdzztnbhRerMzPdSKLDy4Km4VOm7tdA9W
KoF2pbkeNloM7f6NFAUxqP4XMDrIMzsbn/a0AyHOYwkNgSswxSdgBh7k6BDWtxsior83WNjF67CL
u3npCfNsJ+Xp2SmCTGXFBUedvMVn/bSXSB8DMZasi8bj7TS7jVlCeogU5Kfmxk0kot+qyTwGk8UX
unXg/CJUhBQmOShbqHLRPUXSpnLUTCGhwYGInlwF7j6TXYi0PjDnAL7b9Ftot5+Eb9uwTPZV8AQ0
SVsXlF7zgwqMTfJfUIa6y4OKHPz6ka/l1ZgHFOAblqbLKiHVlHfBAJPbxhVFJhItexn7FhQ6v9jv
nVBj6fx54oft/MCObEQ/Vjd7gA6R3zN5IqURpYpBRKUkGE1YBKoKNAmhGCap5tcSH9uCVyY2ulAi
q9McI38fRZ+WnCdNjJGq3PKi2vxOaO4XsEYmi34DpbQkbOToeuuXgBq5nYzWC4EsRZpEiA5RvlBm
7iAbxYCh4GS1UvgXMB/e1/ZxKdlmvapmCEX4QOnCBqyR/lyihc2quDgRQBnjd2ap3oaXDyIHJxeC
SJOUOVgUHBOJ/O7Yh75V0Ws2maHALdg2wYBlVqdQi2BmEhbqBdueLFHYSc8Q9Y5AMVVpmxWtVEj2
NtRXcQQTHZpckGqBADl9vToWF8ob9ZqVUTs1PZiepN1kijsdyrnufin28BcgPp8CR3s6MygdIyOi
xNqjS99vVHDL1qo5jl+HK5D3sLDdjwMH10uoQLrBpHajz6ZE6mRSAs1LqI6BY3qqUnHCBinx8m8D
ovAcNDxD1nUzwgVQEkD94XKxWHFGMsRDcji4N1yZ4W6Vep8vPe9jpBeaxKDxLtFTfiSDu31giK9e
iNW9xMbkRCwuSbqO2wG5GoHX1W6lF9aMQsgAMRIjCJc/Nqndwqf+qWrgWWUP8oS+fsM5Z1Ea+yz5
VgP7gMIHiXSTGcebibCK28sbZeKGwUeM9/Vih8mSqCwo3Ne2c/4pF0Ui7pqbBgw0S9sTSoW9mXHo
cX376AKq5f1oSsLgpZbCBCo0d6fK5l3m9fUGRyULtSNCzIjbm8HiNEK3VcQ+EmKnlTyHm5uhgMVW
3NTbrEUso/9zcptVEjiB9Bp4shXM4+P7nYUl4Sv2W+sVhsfUlgaSvN4fU77ss7znSt5/AWobWu1d
MczA1t6QOm2sQDoyH80U1KKTDJusiqpY2u2nWjPq01KPMzkX1z3JTMXgFF2KvIBpb8YpRAW41QiX
McUJRX5s5iX+RxYjA14NU1WOZPakvEvwkmwIU7Zh8OgN9NS5oWiIbFXmz2z/0msi7wlSstkuWLe0
SupPvim3B9TTz6O8r2EgQXDidVDU04+sOV/XThMt3DfEnAd26OM0a82PbLj4ZMsfy2wa2d1WiAwP
nuOrdKY5c1u6nO5H7MxYY3/anwh49TTZK2JCdNQalbN69RjStndIsJsMqEsPi8llqfldWx4TEw6D
xSSDJqRymKK8AKBIFpA6PcQUuCPlbqNpAW4ul5vtbYGxgiekZelp78ZFXVYF8IwNXi1pkg9KPK0f
CPIT3hLlQaNpM7YGyBMOb1Q5x4NjztRR0lsCaHNdo3D5RPOLcp3RAAAFs6yAKoxtEqtGGCEBecCf
0oQbPvFfBq4Fxt3btK8zaPAU72Gn8fNiSzp9XVNJVMUltW2WyjgMsuoyC8rf53t09Dtq62oSpi2t
bBlk8QqVsP0kmSUaSB/YS1kwDJL6RdNtZkyACkM0juJkutqSiiOujqB0uR5EFHTkDProEBtcZFUO
mhKnX4dHiYhkknKkKU933+9sb358yLC0fn4ISkJgRlObQnT+MUvm1MJIgq2J+armTBykj1R/Z8eU
nPgMIuYFYcbgqUfL0mG5ZWaJ8lCYQPCyujl0oyLXEkyTEq2iR+wSbdKIbf1mt9D55vzQ8o5T8dKJ
4Na2zzJyhI6en3BzlxobXtiGx8d5mpHSJFeT5iAcJZncNC+iyZ0cv8tsQvodfSA+kqzevrP8j/+2
mmtxpKmBQcP6mKkBmZ2PZlAV1LJ1M+viVG+E0a9fB8UXd2g6cwRCH0v3wMHmcVJ3i0sylai0orB0
rWjEk1TS73wRC8U38fwP+huzoaslIer2pBrhYio/04pA0XMt0ui0STj+4+K4JVKwAGq60LQhcAKX
km9msNH/9ixp8GYAe3IVHktSasAlwHGNKcwT7Eb98+HOLClHoeLkY4VKckz7HbOBtWrxwJwwncfV
Mk+opV67fIwvfZqLV4tNSg19OsCIOOU5njaRUFQzb5OyOGvLcGWfxUUu53qtBLaD3zxjrYDVKeVn
Gn95DXsrV2Lru6beCRx0xsN6om7HMma0o/yr9HTyjrqSNHNPEofoaXfxTQ349OP+/eLv+uQY0RFq
vSAF9pGiV6/Nqj4xKTiWqg0UwYyazHP2EBrlVvCAs1Mw5H5+mLcAQrsxLDAAehKkyikAlRY2cQjw
bfL0/OHYtcYWNgpMlhxsFcIU9eCISKbqm0Rjb9jwVlWPqAkAdceZKEhi9vvhr6tX6A8TJlw/yhrT
j7ZdBwTeUfXkCwcdNNUdUJoXUagp6a0IYJM/cYr/PrG7+/P7D5Hz0TxZuBdRKAVnfRekUWeWTO6d
Nx+PL0Fvg3GFqSDh7zyZ13fPg723B7MBSE0kaA9NnpFi32mSuWcc0hWZ1dJGnPbAo7Jg3osI/gIK
e48nZh+bkMaFC4nVHV5/dWOFaYJBTpEKiwPAIX5tisLs3aH8OgSFk/98Qq88f450iviElKg0QkGC
0+e1ReF+97n31TdIzoDkr1DRb1RF6kG5/+px+Ql53D3MigGjCqCFjTT2hlF5ffP5eJ2iQwhwdAt+
Ex4YgZhdFe40trrb+V6Jx6OS30iXwv2lj1s6+MP0IKFTl7zG4+yEWKlgYrTLf9/v7X1gH6OsCsxP
jBVwM5gFk/X8+PXNSkNjx5ld3+l8znCA2B8gLHLeif+DDXIoCfr9GalvTBjs/svvS1DdkkvwwQej
oHLM9d3368E/xBYOppWlzXifJfOI4P2P0+2H90h1AlHyWxAysQXaS+gNS6Hx+wevZMrZ1cofktHG
3r3Hg7gfzRpnrBGTKOyJ6yhtgqM3qF8UnehhaaqS97e2zgX96/CHUKvJ72AvnWCutAKUKmC/g3y+
iPV9PN4D9oU8Y75hfCh8GVjKuWIWQSly4O7LA4LSAkahDzuNEws3BS3RUB8xJW5UhYkjsRjqqgth
DvLK35T4NZNsA7eXH8q7kqO3SwT7uXcCWT8CR2fPJ9bYs5CDx9nB/RI7yJoDFkw3ud+/9nt/BZPK
ilEAoIcIovuHSNBISFGyEg6EMUt+yEpQFj2+GMISg0wfXyTmAoj/++5IcKRU+r/NXBM5FOnSZIGu
15ZO2qmxGbgFiVCYPMTgplDAXwBLJjGYJmKjYxU16C+g9wyMx/jVF0X516vDiAXhSwx4CNngzl+A
8eEEqQ7M1BhJk2jgZMJYvozI4IaEY8upFkRU0hixylUP2BzYRsWR4dfCIDPfBOU6H5QYj6WRoyoL
axoP2KaoKKQoJMyc4OicRIIzjlIlE49vxhGjOhIfbXJdd2Uh3FSZY2kQZK6ntLt53A8CVHmLcXC3
R2bYNMmjaD8uvrTTExayTtRTotSsWg+sXnaH860o96+X0ZXTrsQ34j9mcnhxPNXyc+5iRronP+sz
w1yIl5pP5L3fGQn7ks1wnCVqdmfFR5V4WClWZX95/TT9gZ1O2+55URNNG1NVRVuTEsaGKWfyZ5o2
OwhRCmJfAgxI7Ody4bSh49yQaTdCTmcpwC+LmK8TnZOdv3cRaGyWOV7Qdn7j4AqCgkQ2BU8NrKNo
/vYX4O0bSMytWr8v12dGhD+vCwcnw6Qn3Wwek7Av2+P/NbYWqwFf8p1Q8C9gpmQ3hnbQaArpdrXG
A3IEoAYv5y8eMTr/4vf1CyVjF10P2LygxQURc0pKkL4WxzifCspB2mF+neXb6eOTo5EUcEuh+Qtg
LJalUj4y7JruGZH0m99GlPoRSVwLQM8OpiHFzv2tNid5qebeGFh5Z73Ag3uC16uQo+EgDBKfJdwb
mtOCwyE7QjNZGkHMR0yBdGTOhrBKyOU0MChLIj+ddcc80dSYsixrY4zjGD+y1GMcEavOS16xgqXd
WnFrvX4/1BYDpZsDVzFlDcDDaIu3MdpPz5n/AqTcMDjlJ1zXFLG1ahbmbWaw+bFGGhY6zUODkls7
QQvxVr+42OFnkuf9oZdJmQ5oZrJku8BkT9mDqOB718Y0LN5VdTnXfC59gVdtPbtjJ7l8tCOiceM8
xBKS32U2ytCNu4EDXqZyehzcdeu6Y089trQxdv1kUYaOaT9peazlDBBOeFvRdWWrSVC4WlBZXMgL
+jhLg2mk799DTRe3XWZvLknStLGkSq6AV0wO8CJudOjaNuuFtGvYyt/R6+4dIHFiBsxTNeeGMJxL
J8pkzznCRC/t8K1mvQgGBCaS1jKu9l3N2HzAdFOTEuN9dc6bKQvMb4f2bE72Rru8IGvcmOJuOKW8
y+HIk/KzZ7oyvTsOdCttQrbc8wc6WiziqpMvNKJ9+9aiztITxtx3GC1iNEDk+znqYyksQVxBurrU
N2ryVe6HGnwWc2q432e7G7F7krrOcwxz0STPOmOPqF/1xMxTXVykJdOz+M8Usvq5QCeW5aXJEeIr
JOjbWnxH0gJTlOq7C9vpMqbuTMPOkhI+ETdi4VX5SncVGX0KTxpSW1FyFNosGcoDGdUcF6CT9Pkb
PD9uFjzermpdBvUxR7icXoXEhLg7RzmbHKjxVBs4PJJ50uQYIw/thYHgbE39zcMHRdTTjlvzVcFy
qnZb+HKtHjljRRHKkapl/HthLPprIOj+F8POiSXNKSKyIbt0V2nWPStsmSrqj6SZRvdTmxpTbwWP
SXwSZuVTPF37HduhGzjdxrYJ5EK8oXIKE/w1g/OCTDGOOhZzEJVD81TSpdcRagWrkOGlF7bQjG96
cJ057FSdn1lE0aqz9Wx8NtAMAUYmt0RO+t82u9+O9sJjwwaLfa07X9NSQD8v2CE6OpceuzjtSVuC
6uUqIvFe/4KbOjDVccfoGc8ywMgvITgUepv0O4uDT0peGCdbvkmPeOZcKLNu5ERtW5SXqtIhDhYC
uYbfR9h4AZd5OcNccoRAmtmq4s00N1KCpjRdqUmspUREr24Rdc3PcPiyPztmkbnZafJjD72I2et+
u6WHJjgJ6Z6nmOka4Go2TdmcCc7IarDh2RK2EtjItY1eb4wJr2xCobjcpYoVz/3DM9oIfnlCMOLO
ZUgepcSfpNvUY+CWo9xpqDTo4E2upTfO5CaI0aJjGbvxVE658kqFJhMbehJaSWyeMMqVlpVXrVgx
Pfcebxk/m8SFck8X/anLw/UurdHMNXTG6cMw6HBKb8GZ9glxf6ok8qiDZ5hRO5tTDQaZjcZ76yKH
IUPefsy07w5DpGk7XpgjQpJ+XYTBOwwMb8oEXh1PWK8C75cIMDHIDFh2+4Z4/kX71SgxgZ9DuzAu
VyN4W2Acz3lgkmMv/k1I00/h59RnlwSEBVu+71KXqqjHiGangIuqJDhgtB+oumMcS2gc4g2u59Pw
9+PFZL4kq8YsJaBiqstZ8HVmvnhDbQ0dghSlMT5qbi+M0tkiOl3ccxSDh7kdlG+e5A+/tevv3+v3
TZ4bNuyYiC8TTgGA1Ztx70p6iYzQ6nwIfRmtqRGOJ4NuvX6TyqHEPIKwMKxRn81dUb8tTiwX9xE3
jl+PoZTTz0nVAxbqXeQAyinlCAvUqxhXWJiYYqHBb++3DPfenHFojfAuMT5vHr+sSo97+fOMXGvU
Wg6qm4zT38Iv3mOlfJfD2dCV0RJVzK1gyM7LwxesP8ynB4U4aLHBAjXrPnSNVgNIVufrB3SUjjGX
HQgnlvH6HXXr+6Npr7SPDpZ79ftouT7uP0AZE9hoNgcg8oyCRDIrgvxkf0Dvk+UuogIIbDQMhhFs
d+H7D/YmFyNWk6FIr/GoAV31QM+EJWq8JePTTEZLRvv1K846aPJiHXbC61G96rLrVMbqu+3xtjDx
ugddcjI3CxrBS24twZZDzUZhRWnnBcMuuhVIbxm557qUDrfWGb36m3tLvGjPT30s156l5xEfmnVv
Wu90zeiM61L8Cm+S7/Xy+PblgWR/AZEoIuhauR6Gcc5n3t+3kCfxUk+q+FyjUy/v2TTH7CqbBoRF
88L9NY32jrEpSTepQznTNd+K9pRD3OCqksdwyGYQEcGqCD3ibXsSq7Z0jct/uEGh6XGCe0wi6sTZ
hxIAOS8csNnrBTbnhK+XtSi6mmLY82+48B/gx9gAwt+Xvv8FwNMLHT/4EjCT7VNRnha+fvmgn7Eu
p+stRbVUBPbp3SDet1NvyhOq/8mDwGlBsSozs4eMyyuU1lEzEm9KPjaL0uF9U1dyExYtz9ubObR2
1+Z0kLEr3cpXMbfzr8eqeMA5+U0yrkmu3x9zZyOmb0ko2NmamSO3U6KHWQdDtxUEoQr8/GFvEEI6
WmILH2204mg06mmpzddLtb1h1LmWT3pJRl/uvda2qDtTExM7A6ySke22b8aUaxPTkBuBx5SsSVLs
IJJfk5Glu5g/QWoQX8zQdEqJBbkIL/HCSteX3qBVtZqi/3hILCC8cbDQCVOSHTHXlhMFIy/DIJL/
eTIKL2/oSMQrIVs+FturLEN1/fMl2+Pp+4fQty7OUPelfggC604cW/EVJhuPb7PsricNRcOy7XZJ
cO2WP6+L8yYq+ZmxBXfxzsooK+OIWdA/01TqtYAjhQhuL8n3CVjLEwUPJsSjTClu8ewMpNjulCA4
/DXtin3prHJzRqKn+hxRFDcPF8xvDn0vc+uOMsYyowTklwvdLsvCjCuCDviKbfPwm/XVa5fiHmBq
cjvrqc4ToP2O4uFUzxEpWHCoXPB3c6TQLJ7RXC4znMxfnoBRxPtuu8RfGrDS2A92DOetGVhp4QwK
cIiFtJ1iwYVVebFQADAqdD5s4IgE5q7HvSEJZjAYbxTZnyLEnEj6fmDVNV+jCN7s175fF2dz9Q2T
KZAq7mkUdwtPZ+dMdxI3lFTPoeFsmge2BmNp0sUBip6x4jv+UPuWnKwnZyhRMJhM8oTtk1ILSNTN
VgCI25AbdZfiPtOHgXdpJFEyPNoQnqI27i5EbUuukDGeUXNHFY2hkJKFB02rwJYYS1Z87aTb4qxR
0C1GBcN4V2v+8Oym9KtUPCHUL8jlmTkVwRxPd/LhRYtLOsnmcYbhSNoONvc3pGAPdBwOlG4x8IID
Dz161CfFI8vvk3tHwyrhkAEjG2vNcEGxHd3XcpjN7Vm7My76dkmNPVqb3r+vTQHHqY8oZbf/hoOu
0/GHA2IFjwyudpYl7jggBBt93B6ia8aMXJGEQVbxlsK+BEutPdfL0t58+2mn9NLtL0DG4UGcXCqB
bAr31/JWh+V38loYz1l3+qbZ7zNKWHmrwyAVxhz5oul061kn9OxVMj903B8TUz1cLVazQAImkfWn
eZzYm63hM6Eywwu575x+qFKL7SI1FG4pXqg+FLRHlYaSDRjh8mNu8vaZtLXXvwTM92x5p7JK4Uyt
eFNJqIyHl+4VbZet/C2SC1ISgSN5ISiE09NFY9O7yODa45w67SBnVEE0SQDvLs9TxAlszqdRboJN
1gH2uGqjErtLafO12r2V2vUzThJMyo1agWu6f59N3ZlcKixt18u4qjhqE+E5AF882l1zc2izTP2Z
vtoUtDq3VLVc1DFB83vj9PvdcDQjVVmeadm3aryAdalOiD1aBvYpTg+2925Pbj9wHkp8L1o7+3wQ
28cMw+rUk0COnPJvAtYe4qF2Me3NY5d4Otw73IW2Bb2E8gtHO8gTA4f0S94Gpdw4UHpFKksN60Cd
wpzaCR1qSlm6zRbDNPMtsRElGBcfkDACFey2p97fPz+mVWCMl4hmzh6jwwYrefwXc1lDCweLMgt7
eQ0IuIJcQbHNmBO03HHRq1dFGAmI2y0B3LVeKZPv6S4V7W3cq3ECrX246LNmhMMJV4jHppkH3Y3E
nv13kixLbPg+9jTTrKakxlT5gpWtoiXtgtNoxRxxBSrUijD8dWMj0+qY8s/fw1a8Rg/VR3x12kqt
ERjOun3tW1b4/SqP3285Bk82FTw5arhCg130i6e1wXXfDlHrFinLGgxTx4Ajesa9XNi3oqeFv54N
tRlPuHM4o6NBrtga7L/tWQq31J46PWaxIthROTx999SuCP/AMws1yFTFpGLNKruHpCX7utu2aFFQ
v5WOIs/w8DpDarXvFGoU1DIvS6N3g2lVDJStV2Ppzfp+CdnpF1DqBW3ZztlscuQp6SQpIv+k2RKh
D1OlgM1CNjzVoy5xLQf5xBdApVvmtLU7jBFU0T9TQ+fqpFZPvxRQThjhg4XqVB8JX6ftdlC7Ahot
i/ifU5N2WOOIDzc9dahIIyF5Val+VaFShUVnkibbRrn0n4Q7UfajT/L1Zg9kY2eljHLGC4iU7T98
CRWZbxrUJ2BNocVTHKZ44LOuq1NLplig932j6PK6SaiRjJVHTEhTmaHWEJ3gE5XJK46p5W3kx26E
uPxW5prS3IFph44YoqZVtDDkNt9ab5icFi2NVv/VI5ke0UoD3zMl2aconQLLoxNBinrdiq3UK18u
RFliO6fCVlKtfnRiQpoWV9EpbYkFK1mt6QHqQ2bmrCUvoa3FIF7CoM9eIQs7QQXrWTEPBBP+krYk
deDB660ze0ec+1kw82CpuGo/G35Zvy0Mh5pDuVpSzd7GwoVGahMZU7HVWVebVYZdAilmhLu4iG7d
dC6ddjb3/p6lz1b96/Dtoa2xgdEOSnzN0jQ4uGbp0CSlFXZcoiXcDHWZKy2NkrNaXYp3ak1WVNVd
gwwA4FvICWc+Iwsi3hYbwrRLCxCd8+JadpIdurVewead8q66QPCIUVtj5ppJLgJ30KhlUzTLB0z1
ZwZ0KYpRPTU5EGOKjtBu1+tSPzoFWs1+d4DfpzRo8mB8eCas00waprXAHYOP3yXdLKdll9OGjU4F
8MNVNfMAI1gVdAb0adiTk2rN+N5ny25v8viyq1dwIUMem9c2Buhr75ClYJAJWyMNfPR7yGnEMN7J
XROhQr2oALBhtCYemOG88kkaABF0MUB2WR5QtsWz9Vtj5a6owm37g9RLRaDGr/oevlVFvYJSays1
ZnbIKNq8FKcMcA77EdyCHa3yLXIcNwDA46jfo7xiM17Ygo5f0WfGdS3TY+amA84jBXI9Lq4w4Tol
VMXz46QuDVnKGDaK0sn8jPSaUFEdT4Qz/zOF2nPcOzozn4K7Y+w6LN2Cz9x25S8AzoJz7T0tlR/2
ay73pAIDgBSs2LkXypGGz+vPw5HGsOCGFXyEiEdF5d+lt55tq9MugF2vkmVqDhM0rTkQzZTrStu4
lJr1DgAyhMnKKy3TpwMowVtykrJM8FJ/Ve+mrme7mO4dUbPRCWkKQWcPvGTdLS8tZLlviX3PeleR
7mz39cKNJUqlGK819txmG20EJGvqQ7mPuzTPzczk0OcZB8Hbw2ePAVXoOlJvvhL73OJcM6zSrnGV
QYSamiOPyHYpSkwp2LBywHUGMNJa1XvPqKUcO7Qfc1Lv71TD4J03i/cQOmBqbmQjvofFP7geRi5+
dDQPdC8O0ri4tAkwlqnrPFWg8Mu4oVgyqXlWY5Xh0xLlG7Fx3zPIELhOU0MftccWtLIkzuvhWtiX
YNMdKtLlwmvzPW6dqcp8RpduwXRw8PJH/QWcpggUc0rvgbEe2NuN6fchbMFHpFCCkbuNDLF5Icqy
1/N3bEqyxk2v5/8FOCHo3QhI6+yQ9GyMUpGtD/AOafEzaWNPzk0ptNq2Ib1oWcTFnUYI95LO6Lkn
M6YrjnqptshT53pg6Odh8AE5mPwUt78Vnzj4oX2iJh5xXpDEmd6filOzrm+0srmScXK88OEXxkv1
9CpE1SR6xzsxwGcLiIOn/8JIguRegpZc8LxArLnFrg9cSIXQCHdhLnatq0OaQEZvUc+Gg40Vq2t2
zHUUJzzVxGnUjZZ1+aUYY0p7leFBknHro3WTodWspHbzhvcLKO+bykCDODbbdQE/rAkqw50etDUc
CBOonvHvj3+lJ6WC5JTjyIbxkgML7SKtQz8sAzDKQnJJSXTTZ9Vac+zqnJ86nHXjq5e6zrIfz/kk
uYRx9kvju69eJ8yAEyv21Q5+KIwyrG1tLWsX0Xw+R+u6n+EG9rDAOBVXl3q+KZNRsjpZEg2MaLE3
ecugw1UjSjTRERUtLjkZwhHpIoOSGqebt/JEw9mAJmC1uB/TgtvynnsmUdUn03YclpTOj4zax+zJ
fr3gj6GWMXtGcxAU4AGbSSXqYELFAOQ+6rTvb2DT3XYUcLFis15MlIujqIguAjYtuGdketsI0n7I
LyNjSmZJ0JLG1DTs4WBnOMWW2NNFtXXyqynw5nOiMDRzmvsLYfEZq3M/l6c+B3J0nlfSJT4pHxS3
H1NvEJlijhGdX+ZuwU1TeK6M5FNktX71lNuS/4CJYAzzCmU7wblvbSDrHQ3Uln3CUnYrUVfkt4xb
VSo1O6rCxOH0K8jOVTaVjZatOckDnHTrIEBinlclzaMKamB1p31omCZ5gM/XsjPfl5iIao5QcSGb
XmZoTW+hw0fHwJn6u7V2XS8xagxncZvHulKXtbWtdJTOLPTj51QTfeSmUo9nYwIXtICYtHGpGS4D
eqOyWtdaAqFwU7NtmLWXpwuldnlJcalOxDXgX3Q8yihoHJinyXtceZ6rVcnSc4RFbyDqPfM1Dtqw
qKQ4tQte2RHEYF5kGqsx1hlXt/owVK6Vgrc3Jz+4DUUWYrO4xFAS0Ey/XiuwcMK9BR7zrDlOLWUK
aysV+6zmutiAw4fOTkMSvVmkCeuN5Bow466xK639lERva9SCkozqgkZDYJ1R1AL6NdEo16wI7dI0
LaA5DX8qKZtqgaZRS3gEJTudh0x1yr2mG0/Xcd3uWaN9RFOsB+w3702vZFwXrRPVPizRoTLxIQMV
ev40yJamNISKqYaj1ZXMkFPLFqdVh8sUqLCLa1dHC9m4tiHDyaBitmfobDWoSK5BbacAY0ysoLlx
YVUyIygqCiZg/mJWZM8TBQw5hMYMhzYNe6PBNxXLDlVk8yIceTmjnnBeUTe/2FgeJtl34ysoSA6k
6EBOV+nmZZqlNyost3i8rAgYhNUqSQg008mZXZ67NnUnmPQkXCWc91n8BYQvbKom5ybdXoVqxYTI
gxk/bncvhX5qXMiQHTFSAjVVRl3uq43NN/9Zk6egKEMtHd0RFC8/VDRLevqnWgRhLy1KEVhSjNNU
MVdJH4H2MJBVr9mTLn6D5lR9wmsQ75RZqpm/dM74QC/UNtRV3w57gtkxrC5Gu7pnoMvNp8QBRRHV
vsQKHr9KBzL4C6i4ysjdZ7ey6TgWUJ/WZ/qqgjO7gmoR0+ImtD/Cq4+brbRq0F6I5XG0B+1zzmCW
6fp+pMhGp5mcVFum10CKocFCRWBTNufY8VADTyw9uMlNTCJb5ecNN4WMIwXqnZVaoblHu7gfQ5IU
oLVakK36zKwRTQaY8mDWBkb6HZUOKQrc5i/G/D2Nao9asbnvW7jJh+R3wOm7LunkjWvWXqNxIM4s
ZzZ1P4XCMlAyVlaFIvGUsO1UIn3EYuo41jjz5Mg0HFQq9KR5V9bn9Ok1UrlCmm0aVk3Y+R2dYNLM
eFEkGT3MpMf5RKi7Y5xkKpS20PN61Jt3fKTnpXjHb7rRXOxUIzhnzgS0FLYN0vSzo7ooIq6CynLE
i+C8qSrbGNJUEU/ijZ4TXN0X8nof6yoNJx9x4ODgH615n9Hau4PcTOvFyJjj2czT5V20LGIVpdBV
+acbqMmC6LM6o5o10ZwXy4XJ4abKANcprs62z5TQTSV7L+5RJUMaKJmBKzdmv1mu9HBUhBOu6qhu
zVC0Wz46HO1YIBJl+mlPG0QatEyP1fzlwmUp5/Xc82ps+aplqvYxcUOoBVaH5IsjIAqalzYWmWkn
XhCPE05aPLxU2LO7ny2eG6b5uJdr2iAFBSUh1MWHN9cQ1GwoGy0A6GD6qIpK+jRNJvBD0pXOSflq
TdZ0Z+oudFW6XZ336Ehltde6Mt5ju6uzWLnJqwbuQOULPp7vKWK1uHffDWtSjct/VE/6CrtkFHEY
LPDPteX2FcCMp+qKX3smca+vWSUnXXqPhUGBpqnIYIRsOnoAv2R9SpdNKfaEAZa7SgMX96ifNTVh
YUF16qpgC5jnYqwARGgglSW3Md8v7BZFSdtUxTf573TJ1E5YNttA6XjDI/4XpqxouLpQquyQSgcL
NO40V1Y3Nmbyqa9nDNIzV7XbZVs0bvGWejQyn64a3rpxjdFNl2/+cdDtApnsuAszFnEXl8eDunZc
dN4t48XhLnF996ie8WJPBD650DKtEsVoZN7J7fFCPIhFdmgNt0Tn9exbTzdY0vEzKY5Z5oTRsg3m
28/k8LgdsLA1Fukj96w2ew22c6PMM5NbTMxWT69R0WfjFDqhxNMtUdGFmvlYPWnJIxp28ftGlWnP
NLrRHUf4u4b66/ijsHZE5WtGIY8U+sYKlPVq0lsO5s9yvD15UumWqvFEwBgx2j09XWq6vno6a1lR
WSV0TIWwIMN5+dAUS0WFvsawD5mLyspCnBy2iboqtE0vJay0RrMEi6a1aNm5aFRfoEeM519ADKXV
oRULWxuczuG3OIvga1v5NV3ujGeXsA1zHz4BQ5GkSbg8IapN38k8jgG3AXFDC9MWtaWkrDvoEukE
26bk9jGy2qhTwVL+B5VLgS4K7ORzWy74Pqz4WgKQvH7BlsArguRFJvOSfVYs6d69Zrm0nG6Vp1xN
3E/pvAQ8vtxQEYrnY6MKavI5bPVNLDW2VIxrI0fHPImYQWfj6jnT2yOKGXCH0eOVIpjv1zvhFE/9
R4KiXdHoSJHoYWWPiBLJIshcWxRKFhdnDrbtiuZ9k/zxFNsBnvOe+cKbjxY4NCfaeFRY9r/tCD08
bdHlxdmlYJQKpw13N+R3F1+3lRyVuKThSG2KEhvSyTRgO4WT6lio6pB0beEEHPUiS88M5OxKVigo
LmjD2+MTbLMvZ2mUTeGSxdvSzHxI7340X0uZzRE1Bqcf/Jkfh6J++5mmQbcBVCOa7gYaOfbzfet8
77o2J8rCxlKiAnvADJOECeiHhGjcOx2JudA5SUlKS0nJVpKBWOW7pnGvQICmFOggPSOvQWCdMXYS
Zna7oFBj5YUgM7C0j6OxvOIDzxdJaGAhy+Vkinu2q7PPI6p/9z7HiAhX0yCrzOe31MzMUnkwVykH
U6lAJvT5CzBQU982TVm+hpaYxQuh30qXodp50HK+Vu8k3e8nIIARnUzLoLDpwyduVosIFVvxipEd
lR5I07dkbT9VumZcm0mdlLwJq8CAKTjdldi7Q87nDyC0schk36EGkBeHZlUA/gzfg/2OGB1UZs51
FpiUN4Ja3NPlBEx8FQPKglnNEYfWPZq5ZVe+R65Vjm0N7gA8qx8BtBQz0GcoIt6A98kTiBePi0l8
zHP1dlZqiLtdUZg/gN/+faQqQz15p1vsLzvBYT7yUK+3AtAHQmO8OouIAvYmPL1FkYV7v978C34c
E+MOP7pk+LVOXyswakr2Gv5xuN/l/vD/Cwh8QDvWuFj4EoeYcxzjRiUGQR/PEaCovL05TIyrk/zI
8vsY/ZD5fiYkkginU2KlQFkVAkpy6HIEJ/o2ACDZ+B7B/xcAO3tz9T69FlOfD3F/+8ytIwmfIkcN
TlQEcPT/GNgf3MgcjbPOqqFqjlMhCYoCfPyBvds4fzgIb5gThz6ljQ4gWxUmWxV6D0zsjWdlLJYx
H+ZIHCqBJonsCiQOvv3xUwkeJ/f7xOo2EYxggeRHt06FrjjmEIjpOU4dkMaNwjTqjDIZwFHRHXrl
KTaoVEH77fP4NTASPxLccAyLWAzpN+QYD0obxOysQ5fOnuQq0v/shhQhLn71/zJAxp3sMbHL9a/T
p1PBwuQBT5I4XhT13w/cKITDoZtsUVSr0IRwmEtK83yXFAwSvjsTZAYDU8jiRnfoJIWFvXtx+h1I
LBQMFD3npXZzOgFXRykcND3Y+/Srb8V/nH2g7qU51g7ae31c9w1bofs2RfV1LynYf/xpL2zgc4KU
zny4ICwPiBh9QRlsHDxcic+Jvjsd3NtwegT7iow3KTJ5ZIXZBidEaEyRKbgzMj/dpjGyuJqNnGMg
DMmxkA1R+zRlUUEa9HMM/p34ev9jgq7jlE3m+5RoAAnYMS7q8c7zw+Pvm5e709+fu+45eQOgKP9/
A9OJNHn/28fHBRYKU1XQr+1xo2e5LXxdP9LtU8SPHiuo4gUSETxhJFoS0WF0bwqcYnDWqbcR74Wo
V8n18RtfqP8AgdPgwenH60aFK3hJVaRxofL5R+RrpBL7Y+KQSOLbv7hl9fHd34MbfgXJg6k74rqP
eMB0PaiKrItwhASVIxllcvz1hiuBRJwOI/B3rp/IozvK8SIvMCW0K4s/SXDlERUl+9uo6du3gH8L
8ez1LwDwF8AsgN4u+HVgqBjcRIL2C3vOQ/Soki6GCliVVjoHDk4KDk1rLyQ58Au5+O44z0dVBZVN
g16Kx5aiRVyVqIMoEnTX5ddJXBioxDf0qzDqYb/gm3EYNlK8EURed37cDb/GQ4T6tAvvAfo2eq1u
vcM5qrShAuOeaRBbcHh+m2w5E4uh/f0f0VqSOSBKcsbLV9TwfBcin1usDwIfG+6ZYt3SlrD32lie
U2wB00pJbit7mRdnCEaNa/U1bDoYQKRFANZh7L2MsdR4tCdkgg994dBy7c9Jz3mWnhDz1rElOyoG
6zKlWDYA+EpUUSNqpJaHeYOxE+B6j39GwyVHGOmWWjYVut36znhdRrFqljfOHCtno57eYtfhreYK
IUFdrEQNgJzLDtqBk4TYkpb7wgFbVRoJW9NoyN/3nIxEJ797lEX9Yj0ny/T3p8Hw2Alw3jmeX7k/
djMSN/SxXm+S47/X/q5HQXyYmo7fqzoa/HHoeZuKKqBW+VkcZQL5L4R2eF2Oloezp6ZF/hInG/jy
uxn8degGleJ4U53CHmSOfTM8Y/dCX1SZSU+AC5N7YjTI4nxUjAuEVoWGQ9ThKx38tp2xrKfW4cEj
UqCzuVy4zKweMjv/63ptJud26J2Yf5oDu2orFqknY71CPvWqrMXKAwnzVB8hw5EhWqwdNoI+2gFs
F8JWBWGf7CM/rN57oFGmmzcgLZ2HTlJOaY0KP7YCxn0Z6nfIVAqI62foD/rEQDbeGgJwkkqYn1+Z
oeTNNR/GGrlDPNAOTMvrjP5RdVk9Hwtq1ZDr5ItxV/p5nLUxj+u/p6cjq0nzpxNdhFKQwHNH1sEd
aUnSY7M8qBIflnFZiLcNTqbjvGIz2wba940m19VnWx0cPIX3RqHRLgzNr6yba4fudCy25kJcmQbl
KxdGPw2Pl42Y9wizSGGTQZRBl1qViAsan/WZf3odsiKSxhRns+E6UeZL+nlMYhpce9TuNy1k0nv3
pm3CciUjBIws2zWD64eYuMvSQ+YeLuCLsqdzuzhzFlXW0am1rmImaSkrGZYDgdj0GSLVW7vCrQrV
/hTdvBvNmp3sWWfCUAjjqSSdac27+DN1uZEKgmHmz/RX/NOgVfKpvIxgKAy20hpulYknGbwLWtvT
0M7e1RP6zRibKx2IrUv7U+pk58OPk1aeoFAZ9KcOdBVs0zqioZkUVVzaYS6HYRLCsio7/ny0yPtP
fnH4QxbrCd4r+iUK8vVfzy7Xb+xyZwtl5fUiBHhbOJiPm9euzZEW4KYO1COcovJFleMNoSVjjGxq
bUVsYylyqXKxjkQ7843YmJpj2xLyGjZhGRXEGE5lnV7JbVIw2r2Sx8t6Dz4EIvok2BKsejbJzVla
ZP1HzLVCzNVELdmZOa4ptJsZ0SAX1rTbTlsxLP9g9xMSGcg4933e+mMEjbzyks8kZk6t9I+0HGd4
rtgqtia52RNdQFXy8rTaPB4WDhnhxYWF/Uyz99K24jgMbJWntNDaGf/46/o4DBJYah3Ouyvv5FhZ
vWeEunvXuftuOIZbenaI2PBaBy13N660ahlo77C3dC05nU4cTXJswf74AlGddNXCrmu9HVSmvO2q
EJct4mFjh0mdu5UerNV2xB90hMatdLXoRIFquJpn9+ajEbOFpa0TLkeRRRDDj2CJ2WWnd0oq57J2
90w9vLX/hKfyF5BY/NBx0kNcpH3H00WnQLR8D4cQTqvND0qKHgO97bYKmGpRwUlP1dtqllJzbWKd
1k/JjHfG4NlImeqjsfIloWeQjuH7Tf4mMtBqElavOoF3UDog3WbDJd+tvWWck3p2ttoSSGkXk+YN
zZfbQrTIqcUhdOUFzlQlZZU8rWt0o2hy5lX8BWDEv5Ns38a77LMYE+ugcCVbIQn5qg5XgJKb6KjN
CTuDAxZA88Jn3PyC9vB5c0fjlGPAght3LgfoSdUnwq8dAlJvRq2RcizNYvw7uhm49YvzRrHerE5E
lG/Ozyc98rr54IsjbkRU5JJ8UeZDaFiLyWbDGgxl3jZBAHgzPjCefddS52YT8ge82ZyNyKJfFSEB
lsUERCe584xq17GKbd/HaVr6OwW8+QqRyBO+vWEwGJdjEAKKMpdhH5A/ZBjh1bIqyMP4ZKbZ8ypY
/wJuwNBIWh2pPvbSted02W/SlJHQjD38mmb1C8SHfo+ZlewqTIXEtie6HxmoB8xVZ9XgqrFNqcHi
SiJsRMWNs6VLKmyhQsypomdB/ACnevgKRBaM8xhVuyMnCAWEJEmYASL8qd5j7cQkHTJWYJ2tT2IQ
Jwl0kSXGXs9Ki+NpT3pO2Zod38K/1JleHi5dPeR4Wtzzktm3sWph1eXibaAXQFhysUMUAAB/dEVA
JS28bUK+yyzG4WWBQma3lAXjvHmlLjVsisp9WowSTZIzUTAhkLRurj6SVMT4adAvVvbalu2gmCYY
MfQPTdTcdnWz3EVPfgWdniLTKhK7pdakYUc0SSEpu5eIcN5YopvL0THW4XdMVWZN9ShMTSyMU7bu
2R7bjEon1mdZfo08f9tjNP3WoS0G4lZpCj4eY38k8/uXm8vUhEpVtV4cIZa3vg932zo5LqynZEh+
4Q3icLYeAXwtNeNX64FW5IPhL4ErCyDCysv3wPdAvk8qM+qhP3o9vhIXvFD9cv1q6arTOPiaI7z2
6DSxPQX9FNtqehP9ruhuNSzkyo5HIbB4cuQogj4+vveDw1nKylsSyxipLu9xXlA4upMejFXD5Wq6
Jys5bh+5Ujw1RH+QsSBHFG1rVwflSw1bkttalvUfqC1kYu6F69jlsz+RlKmMS4uT5Pj786mjNYwD
lDWa+D/tSrRCzJr4YkR0xl3JjbdRD8I16vXP+jxy7LdjG7C78ZKZI9sHDOfS2ck+Lbhu7qZpzLy0
6xW6HMdrbHs0KUvXPJtjWmqoc8TNCIt4XnLr/QuEIEPAXm3ofuclVIxFuvU1dGaRF/x+7fRxvLQg
/wuQXRW0SXIjrqtvpMW9kL2khuk4yVEkXsLt++Srj4A/EGNK0YMGlyd7fGFcDmHs9awvlHgAYw7b
5DNTmNleMVdiSDKrM9j8jX08/XTJSO7IRWhmESY+igWlnDOtcmexNVxORkSGgnnRWsIbYmWZ4qov
4sYQpkDTbAyVpDCJHzfrHXHq27W6GBrTZtEFZ5ueICyeCMOK3qR9IVudrcP7J23X72cJX3J+qOUM
UolqSO3rafJtdI0UXI8es8psW7srFn42sprcqbt4rXs1TQLFdetyPQWUDReZ3si0lNzUuhHlc2u2
B5729mSD9BTj9XSIHOEpPAsOpeTkdXL6Q1rEbyOHCb9ED260v4Ae15WT5zOgyeFJ0zV2fuuAtTGq
We9uD98DOBV8egMVnGcS7sMKho/JTD3ml1To0USvtDwI6a4B1dLDGpwDSlAbFPTrtkrysMaqtN6+
ADcT2/ABKlNkwYwvlyqmZhs0bmzDk9CAgTqMwH16xJ4crKVW5bjLkKjze8mx0f85SU14yF98Kxe1
zoBVSLqRiXNkllNOwJ+ahlhG32EyvV6Q0WV8pKGEqn6pZngKt85cvmYaL3SYwUo0ZQTymBFpUmDz
57I3dTOBeX6l+KyscQWdSjp2SqzkzFiNrJw+YcqcyUZnkylufPoYZlxsJRy3+dc0/vjMdFeybcrS
DQ6ffUOy5NkUDeeViOiLOeXss2a6qJNXWPnz7gudXz1Iz6lUAda41nuDSH7flSjjMcFR+4I/FJJl
jjEhaP01u8PLgwj7W+2aRl0jFh4hfEiKaut8L+ZC7qm/TX6WSQ/iB+3G4X0/zKDuJ84iH3+9Br49
pi0aDzSdalLS1KyBWVbD876iCx4S76Bjn+BsqoIg5qf3DZCUCzL8TsQc0Ro3hbVDX4l2wqS9e1ye
uCH11Tbzm7W12SZVhrnUhqhoOPftyXdq0VNWz+CmGwoNB/y5tuWMnLLSbJoqVI3f3n1Mv5qVDiQ7
JoGwxQcqS61s5n1L1nErcuq9VZBVEh3k8njWI2CIpEPx7tavjslKe3mHFAhc+O3zjz/8rIgYlw4l
0K8b7FmTdTebpxLupVKXEqMcuIAicdUb9MilIGtsO8WAasL2XgpK3Csq+i/xQwvNrfKKRFBOPdpG
RF/A6pwUm4ilkdg29bQbE9sApQyREXZCp1Ws/QvPLILY0GrRttbTTTxOuG2fFAhPCwyzXO2dszyj
YWIWDwZ7v1E1BrrJgXD7XFOKAxHxbqv5lj29kj21iymCwRN2cqXJmnLawIfIxjAuzVy/mluuxBJY
QanPZK4ag85StturOBMpGoOT5Z1C3Lv2OUvw3dwG0nWug65Jhg7CsrvbNZmUhpRhIYsNdjqYvb+/
oBfxOd+/9HSfLamG3XWMoCtNUeNNzNul4WcK8/0qyY9vw4/07Mh4Qctz9SqLMIYnJP39Mly8Hl4h
LuZxqYKT4NtKsGvnf4wzZ5om1QTTs6OA5cDGBa7c8nFpSPlT71fQGeJ9elS9YV4LFFvFiwbPt90T
homnCDOgIonMpNaMlB2ZNpGKieMT/piUKzN6QO8RY60sIuW3lvgqLk+SPPVaOLxr2ll/vOOrK3f4
i3YSnTs2d82Xkw5Tj6h1cSjf69Wn9/ErMAJIJNDFsmqTdNMMH/41A89cCXlZ4Xh+pI/nVgkD/GyZ
xIgWYn2qg5Znp4Lhn2OLrrJDDM6O75vnlDcOG3HWcQKYuQt4K9OmqimO+iFhDPvuwe6SP4xWg0CS
Fwh11OCH6Lgm1ynLIydd1PZEs+sW15yiUT2SfKxID1PeKM2dq4rYlfFO67u+I0vIsxRSy5+kfLlE
yorm1lPnblGyVBgpczOFuliU5wS5eGLYXT9vQEZwCckUNeCoUrC/j9CkZJTX7p4ix/EepAN2fGtn
bAtGQ+vae5+kfD5mXFmFOYlJVxekdrWrqmOiH0fA/d9YVYIE4Gb7GXUquXyMSo8+YlMddGd4CE7o
bBS0OHKaDc/2ubMzIuXcy+w9MhIq83C/K6Ox0ZGv2zcnF/OOWPS2aev2lqWp/uRfm74SjMXRNePi
ZwLJpmB5lLN0WFia7roD2sJavPDkKBlTRF29loK854e7Z78PsjpeNnpZL0zTjmWYXPOXYXOMlJSD
a4Y1AUzTNraMPHsFrWBtZnF6nyyT7E/WW79d2GZIqGcrycuPYkKWGLAzUQ/MH8r2ffyS3n8rugjn
OCGS7SULbNakpif8hAwi2wj203Gw44q9cl3dJ+ahVNSgf8D5Y09gDBc0iScuund448r05MxhQ/gl
rPxIJz8GtIu6ZJjPlWKu+QuQGbNLK2upw4RmXcWqTpAQAA7dnCzw9dd6xDcrLyiFJZNw6eIs/YZq
aFa7JqHNtfw5jeKd4VyMJltDC0qTtCG4fkcMFaCydrDketOlA2vKGbmZ0Vplgkq5Wya9v9oyPyfo
NX9/tLKuO4nldntiQI3xExTrG2VNReYbKwJMmMvhWu27HqtNrEryzlItJg/lKMROzd4LDDxFH9vU
MoOKdJPEenkwvCHwRFR1I+W50lyoESsWTw3y98Wa5l5myhK90L0KVi8qIM/55CnAjdMNkPN+jeln
aR81zBmsXX+3bRTbHQvTv/uQJ0xIyIlJSvD/XgIJ2Dcx3YmSUKmx2tVqB9/Jt7zhXpx69rCo0pJ6
cN3Cmwv3JTcEF4RknL9Fv8VwDN7jooBSTWa35EiDzw7TAiJ+n1jeUJQ/of9imUj2rM4FhizsUs59
15EZk2w2/TrgoX3evQPNcGV+ubynVqx1vsykRvwwOhSTN2WyYYCTV1hsUtaNpiG/NcDPpTdhHKez
lHiJWuttzYxvIOGQ3L3eQj5koo+V/7TM3FSveaoO5ZT3rNUI46FUh8twOWSXPN2tvhZ03bcdaSLY
EjEMDd8WXt5V0mvWSe3TrE3VuNgeD88pOVzKUZAWVmVNjkuOlD2nr0uWWnwR7YMzTMLazfvhMMTw
NZxc4f4Ip9J8MiK7b+ej27Z7o/as3s7dunG9cEStIq7LqiXmhvWn2Y7PPi4aVVe9RXWE0hUOT2PG
9M9p/UVqcgmmD4EmPVc1oWfU+AId3HabiOQSjIu6POZIxf4QWJji7cFes++AIbm7aK9EzEZSEvgQ
5JF5UIWzuSJ46JSwp/iVe0zs2SZoGEjTqpqLcjCy4ZT0FBkWm3inTGimp3JiH1mqc0UFoqrlRCw6
KTMG1vP2gxXjsC8mLmgmcbqq0vXpqtWoU0L/VOfE/UHENWRLopN6GOo8norHubLO0H6ESzcTD9Im
luHz9MDX2agcEZCjffW6EEAvuW5m2q2LLUnHAqrDpQjhbD3bJd2gQhCJ2DbJ91IwX6aVzWc4zGZZ
f0mm3bJFJqd7gppODDGCKoSyks3jnzVIs3TVfvMybXhid4aktunzAMXlxGxvoG/7LMCrKgOuF7bU
n5U4EUkrr6kFfbBKwLUTyNOxpMSkRmXp4IeoZXF9a7LHLtmLnpJ+jOm4JtFlz0cm/8Ep+5psVkSA
PZ7biN0Ydyf0SBT3Laypc7OwM3IjlnZz4V227JvJ6u/S8BXupC/Fo+Nhtn8IIOO0vDEknPKkZTb/
IZvPbuOT/7LCZDH5euRGtt3WpjvGRjGRHonFP6CdejBR+oO8EsNHIdrzp8yjpRvddHfc4/UUEczZ
Ac65ho0yJSEQ6zlsIRjN2hhLRyMGWi7ZLZZG9HW3eLNKymwsAtl9lTxl94QVNrlLm3TnGSutpssL
V0NqvuKNsRb3Bd2NbnSkLAQKC8f7Vk/oaIIOjaajbbQC/TE6tTo7CPnDnbfTAyOGf9m3gZK/WlUf
C/2QVzMsJjnL9b6F0/7pL4Bo6OJkS6jvCCgXWYffPe5+tV7gjCWeSxJ2enLL+SBQapCbvLQJzvbI
cx4tKalx9RJpS5DeB5Qwk69dHc9ikzeFL8mZ8jYm22aze0cutMOy/RKKUOv0ip6siK0rzThTS4ao
ZbJy0TKJ9VYBBi+UxuyCrpJKqLmCEE5RrBL1WG9yhDsZ24389am0uAO6QRMvMhyaWzVPiZfxOOSM
R+d7M01f2/izyCE//wKsk/1/QQjmimDO1+maWsDGmhvNlmijMa8ku8+d8CcSE0EUIeC1gqjdulxm
6MjVcGcIi1S3Y/uKeUqa5IubkLiR1IaSzrHTgNMmEAK0fmwoeA46GNzP5wILYzmZy7i2XiKySzbQ
Y5jX87E3r7ddaa2eDngcGZ2T4hUyLMVHlemJxSvbVTFlmvFQpWvL7LaYi0Xmc2AhfwGc86AfenEq
NizEeisDp98aXeqlN4stmrSYSqfYK8ZlhpTl0gUwlHWMixW/WXpUeaY2GqQoYpCunuqycSF1dW4q
kO/lLHJApfpSOi+TjBp1pnmHhBDl3Jtjyp9u05yxkMdHFaPMEVZcEjwzsdg63rd963cdmpAH3iwl
xqfH51gxn9yhbLUmxINOMfPnej0DTVstp5lbzl/UyMY8j5MDe/cW0dCJfrDCQUUjAvCbqz1whDnu
zPU1x605Rt++M3N3fvtoQJpj+fXkmFkAmlOMypT7wKAlLMidEjDQKI1UeXBdZ5ykwRyQSm4dlyeM
HV1Vt2Ng3u8n1obSsJNL/6VrVYuOu0Or8eQR6eroOo7lNto7q8y+2g5tC1fPHa6amVxGB0eCf9mV
Su9uGKORtGIpwHtEf6jiaxYNWUKNj5Qb6FwDoXHdzhBufidvark9jcJkqCtKw8M7WU69Vp0H5oM0
RxscxAcEJ5sRoI2ZYfbjXpKT7nBm4BUrkYN3VLq/qpTB3OG2T9Q04HUONIVUo1vV+JqxYOtxcXII
b1XcpfMeQrSIVgI3VCMtaFY3NSmiXO6UCCZShZdXDz3KJ7R8fhdq4KEE6p66BqD0KJ3s8bCWip0o
Vnf9BRDsEc6aGQqrHxdMpCi618ZokNt4UCeSGzR7bms223cqlOUJlAA7HEulYrKIarXXdvNr4/Ju
MShV91QbuukDAqgfNluQadma1O6+afZGXmePycgPGLEFWkouORcWkpSEmF6MKQtOck3kYFfzxN6x
Kt8pdNlpRWXWbJqZ29/qeam67/eNX/syW2Y6HGR7hZmpubr7HRstlt/BPk6sbWPd7pDwMOiUb57j
au6NjH/njYtMS3aAvlwjtY6yTEVotW1RTbC0iLHuKiPOhzI3l2fMTrcipfvV590FQUcKuEmLdVwL
8n0fl/akiqfmb5v0qJewuTmjq9ar0rMeymYh1FucPMmUGhu/taw1FQrRpjeviMjkdE9w6S0Kvdw9
bZY6I2StlFilu29MNdUDvV0k+Jsf8Zt6GDLB+FQAZ21ds20mu4Jon05tlV2aTqLpqqeB8XmOcBIN
96vp/Ja7W7Xa7XCE4SZeBMgnN3jaarZVKZ3PxiV5g2UCiuC1KeiJ6f6+1RtWObw1rL63VHR+4Cuy
NOKxWrqc1FQVW8wl1jV7bfCN6qqSM+ZBGiwc4FsVczsJ6nY06S7pL5E6XkJoUBRMTIaW3dl8WSLk
SJSw6BdoVsgaLwTFIruaOv/zjL703rG4ll8qmCfAFMi0dHj0FWZFOe6f0ZLyVdE/hY0CVt3+Atgu
7eD2/j0V6eKK3aCmCX+EodMecOz4Msi/2vJik8meY4pkxNlXWLgk7LSoci/G7BVm89WCTVO4l3FF
sXnbXxwLHxqKmMXLqVg+5M616s7qmD4zEKsf2nRkVWLtlppG3ny3atKuzBcomRzXqhOQlRlw4jLJ
TtERtOCWaUl0PmJZdyo9Jr8I8W+ulddjb+AT4o8UoElG0jRDDdNYe3qsnhRlQCHh4j+sDVgK40Pz
rUJFtsGGIgtb2AkJfU6VzclsENOp5yYUslfqV4x14jDxOGq34dwUlX3xzy9P00eAOxAKSrhJvjmL
Upch267c5mOxNrIqZX5Sw4MDBBnSkw2PVOP4nKaysjc706j/d9K/Xp3L7hH6xO9be70fVIFexJ2E
svvtJLLs6KZhSLbpteFprID5CSjEF3e1uMySdJ/r276r1kI2PnhYXWZaxRGaQ+Mr9uMf9e72fqOf
iL+Y3IhXH4jpgho502TYJEAIwAzxqlaqKWMZbL62tQyP+QBHev/Rmn6pEFsD0yy+AtI2eN87czQA
1HxXlizYHEH07HMM2B2b/yly8R0yLP96+uN4QYLCNZHiYPC0pn1GzRXNymL6FdIEdBfz1JdrKTC9
qVTIJBLk/XssIjXa+iZts8UTKVNHnxFSC+tI0ASS1qQJDpDOagJFFEwm74FNtaU03Auv3PetEviV
v71NvaBLdWsyq8tA22e+TK1OtlvJjGx6mEed60kmQNfVyRBJTiqFDHFdQQ7N6tCEYkQWLu9qT8lP
DcaGCkY3Y4K5egPFhhRZrQGZfoL65zMnxMhRwl7ZLJ/XPK9fuWXXRn7NQq2yrU1WVntPr3hnP8NU
oy5jA+QPo30nzMY+T18cY5mgx6FLgo6ehAyPCzDfw/+B6FFwxqFBLRpopzgvALC4bgW6GXsv5UpW
sH0KexoWM9oJ32uc6b70gikTm9HMrzgTc2i79pHS1jMuKGcKlJvqIKhiBR2FGOaEgFOikgZHZlWc
sEkidD2CvZCFziFdRzkNbHZjXr/5wM1vge/28/WCsckiOJxvwUeSif4FaOed0vCwBUGuLAljT/Kt
qKQRaqflKvLXGO4Kgd7wV55qG/Vq8nDiqn7UUnPI0MFWbvBGYZaQdUUq0ewhX/Bg2Soaqq06WqRY
mU6+KjAc3Idd1MUMbVxp4cdpxvB3MznbT1VquZSwOx2TyLZbk0vKYbfEgolBQTYVxEeZDMWUSK+i
FxuQApPrKk8F2EPSIjA85xyf/9jZ5rIbS/7ABiNNyq8eZr3UCBtSWhwiklcKtMqSyMzdOsiN90tL
R2WTF4dbFg1Sj1RB05DbAqD0adzAbT2jifD5eGHguFHvlQsWS84jOVN1rvWcFm+2J8Xmej7IrWnp
gT0JXGBr9eyG6am3YPPXdqqmyHHibmprdcJP9itiRwrIQClueS9CF9HpvmRX0sleNjdkw8eskIvO
cXg+t+MJ2lHnhSzzXGGmrWJCTeDnQ8d9m+noZGGwXpChIbIW8mx3YOAF61ymkTzA1iknzQFIJLH2
wt16evqvn//vuHWAfs/a6CaJs3JaXsWuwumNa6dAKizKoOV01Ynng2ikTkBcBa9nEHVUBeEJmIoq
5GdJUJ4B3MwuwsY21lz2TBROwOIYL80cFSrEfnJFFzeemeKM8u49NqjklPAAWDYzeuyXHu61oOZi
GxzlQWRhwwMFbJeRHrSjYoCP63eJOdM9xqmbBrHfZCqypy4nF8cMZD8qyWRMVGvcD1AjfDOUIABt
5RpOrwO7yDll4ezibyvxyCdkby8smqblx+R0qW/oJKblW7xH6M797Hskwf8I05OVe6i6RZKDyXLs
agha1HevVM8qHmTctrMXtrMNs8dIqwDpggHjGDHhpFUg1zTJEdfKpxAVZBPqM1Tw52PvvWLZVb5x
VI0RZ3rrvBI3eBMxFUA5sSlmTAmoCOAoygc5BHDe3XUrmpcYt/kiUFfj1EU/rs4Na9fsBTiYMnWw
pWHi1Ft2ybXh/oq3iS+jENXjyXfhTWv5C9Dkv+/r6tIrLJWLEIwd5e0ZTbDmw4fgUG8eZi9wT2vC
Jj4XneLPyW1ZrlXBrWjweehOShydO8TdJhBwzfs5p2vAkyfyMzXovhamlFwSUFdO2g2Jg5jhxekb
Uc0MSE8dQISE7/Xp3D5gS4grikY/l7GAhwH6zN4kLcAuIioVz6m6ljjEUP1kxiQnFSqOEROtljGr
fhIH4Y7xkpK60MXEJCBLgEFKImqga7pheqJKUVQ3oVaw6hEEShPbdIsk+SQ0eqccqMZNZfZQTWz+
mfpq+6b1nUROqVWf1NK62lsXdhNWhtGsREkbK/qqF0NRBBTEsE9EKpFEHN8PKDguYMOWm7Yxjf3K
yz/9vTnR9+DP8C3fjb/HBkf4aCKDMcjDSGyujstbnnmWwy2mgasRTtoWyUuLFJtQxd3wHL0ZrFVW
1Vkij25M1BWibbMdrqipefj1e8ZlwePhwKqO+SqUFgZqDACzAo2lDSC2CRihOgDlFgGiglCSnO4u
IFd1RnLAk8Ak3OxNiIIw5EzRNmVMIPNIGw0H4t01/tRQk7ueGzD+proyozn8BpeIbjjX4dSnwTYh
VMltgzsf5ocAsS9rnbGQxmnwTUOD0j6utloOhihUZ53FmLEYv91QY+qT90I+U2tVWi6mZ2axHXZH
4XVi3r9r7fCg3yfSaUuoiQlBo7qptQINxd79lSH1J55gJA0Zbp5Bfz3BnvPiOr1dKF9zvfPPnb0j
5mk6WWTcTN9E/BzHuzvb0BY2wgGx8nTlQA7bMkUo+BCQGSWgKgsdjRVAS6XczkpNTrZApXAhCTcw
huyCbBgZbgGRG2A0t4N5TqxeIYAm0mC6yY9Z2GH609g7kkTCN2KxnHi6Qq9CpzUBZpTPsTdLxzQW
KxJMSoYESe+IybnelUG71b72xhTNQ0Qprkdm/aCccHTMQChBNS1sLdp9LktrwWWxfkWpnV3f1VJh
ZJyztgNm/PkyPUR6jSf1aNn/0Nr4yiU8MtrHcGIpxexwWriXfMFI9fdZWAPt8c/XJW0JKeLFGfjN
DDlE8SkTiRi2Wj58+a39RS7wbNu9t08vHWgOixhy6FPaSO4fpgDUU9nZXGcM91PRCp2dN0p1WgFU
SO9fpVBxMKd0SFsvRZW0TlO0EG70MKgHaWowDlKGL9czp1158AjU1P1M8iB/XvE/DE9m38ZxL6mp
D71mfp9l2Bdb1mkuT3Onapu7ojNvNwqhflpNqx5X5stOaNmEkjNS4JEhpuVcgC3dRMeJlW5TKokO
bbLrJZftQEnVa+M3TT3okncbG6t2y+9UyffGJglM0Kfgy80wNu3Iwb7l9Cxl4Pd4eDYnXMdD7R6h
IzFa9D6RN8IzlpNBYFTriJljU8KwM8oySYHrZQzsY/Zccv72dj4433uE76WSVVVBjkrGAMPhxS1R
z5s4AXdzasqafAGUCESPpkFkcR9rNUW8u5YPjjr/BYgwfRkK7aJv502s5YkVcAgzV03LyW+w3Uq2
aRSdWBF1+LEeMWPL5FMZClqbWiO/QeTBm7k9+Om7Pv/wUoEUrQGDpeb+KCKSDOwBOyMxQclUTiQO
ENpnJHcGFMHV6+kRES9EnUZq+OwYqZANNEx8/bz7iIwjqH3/C5j8yqOTzSvU4Ot43GnYcb/qeHc/
Hiz7C7j5C/gQpEqgGRJUujMyEPK0/jqcJXu42//mLRJKOE1eHQST57WZ6+j09m3yFiXi65vVphTT
0A96p2eely8Sbf+vAGOv3jjCcZ4NVJbBHe59sfOumxeXMaUWse9PtrkVQ6oQ/k4sZGgv/cN3D0iv
1y7CYEdevg+H06uvCcZOxvvK6VRAFYjqLdzR2zPm48HR70XfOt/eXBbY4P73J9oWtqDSxRJVksgk
p85//XcL1WOUHOa0/qOai4MMlG444JY7ii7vqSozrnPvuIRk6RsCqPyOclaww8FbvNdyKCw362BH
e/bOMvD+4rNDjPWBm95C0KSutRUczYTF1edmO9DJkMVNGLHoBMLTvIg6J7hrWWGlKHIwpuykjaFy
/xBpI/CJ/B49yXa6Q22qBO2rV42BeMSOTl/RHkHX+0SszBUUYgpD+GCrulolOdNjcXlkLhIyOZ5N
AUMWBFNJ3O9SLNm1b0qZQqqS6Cs2ndZd39JUgtKKajB5Q9ukZiOdNhDqH0GVurkbcS160DunwjMl
Cun1RXAzAYEZzdKE6XXTifpvnnzeI52i3ly6eIMVuqNyYr5+weJyvwdGZv2Kq64pciVogezxA5nc
DBA83M2/RuLmSmeDq/86eaCeU+iSwi6lwZwC59tlslmb5z+MCy294dhhmCfRvsVWlOSd4Ju4PoXU
0ny0Y/j6rUspoc3Rkr9r9xxoip4Eb8PnsEhK29k6VljrwHhUZW+WS2XTzFnTNpHPuLopvZSOF00A
MYmKHStSM593IiHn2mvm4f39E2T7xa3kERrVuEwbvO3PA/CXUd0K4IBHRm4YH4eCJpf8zWc1d6Ha
aD93QrKlYj8zcbsbMiMnUZUePatT5aVEqUp/k1eU6panBazY2nP1LLvTWbpOT+BfruAoMCzNZRov
N6lunWo026VdJvM7nar2mku8fC9LcyC00+hNCnfOiVoPfyhDj2zCGUgwlg7KbbNgeHUewML0ezAP
DLviUAD96IPtlaKLJ6BLS/397Gvblnq0slE85jGnmcgefscgHBkRnTTDuLMgrU7BoNzneie8zbR8
V6Sh6o0CmudHDHG5JN71E1VuxPZyHM7i4D7uFz9BEllrfvZU28u/58ZoJJ5Wcc/3TIWP9wXvZxzg
TIxVc1obZ8cWi83ybi9xpW2tkppKd7ano4fGT5roZFx9ZNWk+bWjPTnHOKNSxlq0fFV/Wpo7or47
IqTXCwOH/wd2anwZr7dJoeqW89QViVDQVSgGvkououlKN+vIVoRIdNhcby2RssfNJ768P9aC7opj
k4vymqXxvv1idb9FIwlOfK6Lqb46UXgJN1pKIxMYR4RHanDHQ+tlCs21zHS6Gb63Eq/rUnRgcK1z
qUIkWw7jvIEcmKvshluMwJmOIKPhLWhovLCKazCtP/uYorNQ4UOQdqqmNp0M+evNcBey/FIKtGyq
My6Ftrix0KoNK0kKXVuTF1zIeyQCxCvB4RjnLGMNj2k8vuHhikNXu2L9naVZ0oi7XZ5StjidvAy/
0OuVrDeQzy+tOTecqiSKKIaqAjnKhHTW4eSiRaCIRpjOu95qUpiYPQXMY2eIEqBc8Rl3YsSYemRZ
TLGhIl0VC09OQ1yhYU86gidNjweDcF5JmPxTiejC+zCo110ZW2aszJ4D/57z4W7Yu8oTTawxId7D
WM5OaMjtUpOgaZxj2q+xZuMSwREc47c36zqwZyI5iVMKksq6rKfk6Djmi9yTrgIR8sakHI8Aw3F4
Ln+tMBHoGwiFFJd9mPqsaYyvoIFq3Znzyl3yU6izFcbbsZVAZuxkesc6ER042Mwj/Ul+Wjw6O49q
A140O1sUq03l24bonEPaGUWmbH1Kee4+ubT36WPmVuVuCgKULWv8ikYBNmHYBjkOx+geOdepU2aT
UmP0qdiJBcSmLZaanDFVcDMQ2DNm+fayZksBzwNifgnr8ZVbq3U9XVLRSHjCdYjcfNn+icosR5ed
SXlZYZqxPl2t1Eta+mQ3qaUU/IfzwGOzyfLsGdnunqZJSSlti8bVWaSYjriSsIDoHI2srdO1KIYt
KLU0c+sIJXA+KAwXthYruonf7y+w9o61IQWNuqj75TSs88m23BknEsOyM8IErbeEsU6fpMlcEzkJ
HUxq4RH1Q8Clpr0K5l4oEiwc7OH0WMxFxA+VhCDNOFbqL19h1RkZigKpROqoJMnZ1DxkLA2gjzwk
2isg6OOjA+13wh5MCI9Ku+Chgb9OixWeDQNm+X7ThC/6rJCbAplIZsMQ9W2PRcjUiJbqkTB6G4Ll
fOk0WYtCPqdouco4bVy4uzq9YBH0zvfMhtHBrCinTqMC/ZvJjAtC6jd80pAscl5AObVYCLCgbKZj
qQe8y5t7BkJvBc5yxcu7vd+ma9H1K97QmIIIfcyBqy8yyvLUPJvNfMb/QyjjAAHziO8p1323KyOB
Ho7eLPuwoAxKUQL2WiJaFwufC04R34KBS0sY/DzbvCKHzt/LnMbJfmxzRFi9w/Iduw24vKBU9z44
14LU11hSoS8OE9EhhV95QQxdz9+08LL+Rt4Y08LZTt6ykHV5karllnpOy6lJ38weNVHU3g47i4Gd
MsOa7rq16zNLxEzAHL2CBiU3NzP581Qu1tbDQMNPIBe4IydtI71sIZY6XRG/WU/DmPtYzUKoCTo2
0+dNCmiajkHcIm3thFGETHC1jp1DeSoz0LpvED8x963OvETJPf0mUIeO9fnsDfHrj81Te5Vduyeq
yrZQlDizh6AiXeW84AmFxJR27UzRInrFDR0JdOpDtw2xrrXJXQvqfIFQXVzGZ5kz3Wgj75xEy8YE
Vc0OQ6rrawP2Y5w5HWblc87wHhWCU0jjXEuFBOUZVkmcDSNyMWQ7dpg/BsqCsnapsRuOc8RSdLuZ
xZB7341n02YlWxk/Pc9k8ktfMBmfAByERq50N5lJuZT8wLcz9IQZ/1nrjNrRsgXIem0x1CgwTfaY
vPpYLjHxCtCNojG7QmYL9ia+f0ouc4Nifs6sx2V7DZOPvPtfAGPumKEkd1ZMhMlSXphU8qxl/yF4
Sedy5dzBPWyUSRUbtMRThA5+qVd5OPgdpN+MS27VxcKV7gBLC776Cu0fAlJxJd1vHGwWNeNEbX2S
BLOU8gjCLV11g56lGfV7zOtwUJZaiQYz2eTky1SS8VPmcXxPkrnRg3IJpbWeshdvW+5VPcmlkjWq
suvbV1X65IwlhQX2dePSKfPHuHITr9HbFcVY6WLIjh4rZFfsv6PapaI2Sk+nGa4ivewrbPvsfPAT
lNvkTnm7r54Y7IRsmz01j6d80Lwv4h4rGCYR4/LEFqTQYSzZgICzZptSTdzv7IuXdY6IqzNbFb7y
UQtKwSkVhFNQ6XRSpa5Y4iv03abptqiu9Xm97ZMzxGp4JmJmG8QGflSQ7S+xS9GtLx4/SBH1+eYA
D7fzmwK922TFdhwxRdtgGUTeTg/YjJxIxyvdoQY3By3dM+aPF8bU023e2w4fHhXkluh3YqlyZbWv
Vb/RG6jMDbnEaBqOt9JN1eA4528UkzDNL+B9dx9xrwpGYfC8kmYZbdoFE/CgBzk4UIRIyPDcxfqq
Y+5TGizQMyg60dFTyJlHqKX6dXvDYc1zcC9GgZzBNbDxEqWVVQjhHoLhHg6c96ctzcmVcMpJCaEB
Z/Ijf6Zp55D4Y5qYi7Ypr2+P4Ezca6qp2wL5piCKSmxkePVcPc7h127bKhi0fjayP8/MXjkkdd3r
2YujPSzURWIvtrhiJOazWKEnF61iNeVdohbjU/OJWiLqr6IrQTLN3aPc/yqHLO/rHgL2nLN0Cgxu
28v/UHCoH4hoFzIvl9TTNaLf2iHcssfD7xWgwb+HzsBlqDbC8zhatx7e1QOeocVo9f1cgaSwk1eP
lESPU1Qr1KMsNHJCvsA6kolvB645vrmWs1EP9yjKVfbsPtlfWjTNT5ISTUj1XbyQkehh0CMqkarV
QKzEaE/+cZnZ6O1QGfuVjRyLuIKuTVmvTaAYsmOiQNAIrc8FSts3GmQyjsjODsC26W1zC+HX68dP
7eJ97ClQDTWfK3Jk4NeecyS7VlbrPe6J16MQbluRM69g7Fiq32qZq7YCxtrWYMr7/1jmioSsrTKn
pvoOuaW2wM6GxSoo0eZ549dPzgw5Etb0yO5FKpejbmnpupLtaWbY0JxbpS7OWnUa4ffxlcHC5s9C
Y+z+2YBoKC8NepSM7ZSaVz0pJpiQ1LbvxM8QE4f7mONLlWdG15vlQ2L9IyYGSrlfqtNvuB4jh60q
VgZSmUwo2+UEzizD8fjFuTRkmzTfGvrRWStx1xtIhys3yezbuW0OBywIr5n17paTnWzKcd4Qy+UI
nkt0YIaJ59j0cK4K9ZipPU+tFW1iKKiul1jgPLg9WES6/4lnLwf5Nsv7EY5IXddGJqaq3mfNk0Eg
0iXN4P3ALCELJbR+ZDzRc0D/ONqIt0bT9b2hA07EPQgl7BjmTWPDdt0+dBelhFfubIpY/lG2pM3R
EketFSS+zsoONJFyH2SSMvruZaCb6W2DqMvuksuG12rB3vKDyp67VtmZ1NOjXDDRf0PjLgupj7LA
NqVRZmDM1Vc5sYTO3p99ybsKuz3OB09VGbF5NFJHr9wktY/fzNoaikyH75+DXLIg50ppkHIUOjcQ
RSzzhus1q/r4RHOjdDdP25ux1dmXTxL7BrX4EIXJN7ExVn4nADMPxHWO7u5pne0zogMRCkifg8fX
CxH3RLmQKTXqmrPtEf9ONm+os+HdfhMyUaDYLlxcF/BxCWe0N2g3Oc9wliiG1seq7i5klCBfxeID
qiAzYcaFK+npPD77McpKzsyIysrKjc9568tl0AuJXWE37kabBXvaSU+VXcK2Eh32xBEnm8Na1r6Y
Dhg5oZkev1hQPktA9gLMLTncxoOYhxOi2JLmfcJsNJEwCl1+HdrlzsHJGQiR+KLmTX/H7TVTmEI6
vAbubx+u5sSPqt8qhXuDk6YuO6HWp6BTM6X7pFSlWwIusilNYTolUWpXwxkg3DKECMniml+I2m0T
qvRedGp0muf8Z/RRFHgKA2r1qAJicVDczVTSq/uT788y040FI1IpyV0r8jU9h0zIDPHNz8bbYOpW
YVqfmUTWuHis6lv9zO6XzRSWGODZNOWsNDnEphbaqNZ5X2CrqtkCyXWeEbctx+CiQgW4bBKpf1jy
rnuu5nGO+7EfX1rK1erbzdvD1L56vJCMH5OVV9ahsYaU7ZqTesKzWqLfLilXp9D53i820oohuYfI
zqK30mmc3BI65i0bQAhwOXDnagbGQs+uZLRX210eyBIxqFRl/ZGu3GdzLL9z+LmI2dm+ficXw1y9
mTShzjgN/QkDz8KFh4fbd31EybmoIGidn99mu6BKN5yvuv9T4RjRUDwHt3ai/AoFwz/tod4ljo8c
CTtOlAUjcW+Bzdkrm31Fw+cPt9oDXZi9719AEVmGH8TbHYR+Hx7Nm/C0DzH4s0SXdnPcvDT8xC0W
goQlOnrmxHfiCRo1LxEk2P39Xi3VFuYzNUPxavK12LWj2C0ug4sO1waMad4C/mgOm2i6yy3oahyH
an3TfWLXesawNj5zaSqem3f3/IUxAT60FpmSU5nk2LzqQTmMLIQRQzJv1qYwwxVy4MxsVZIcTTz9
UFMSNgiS1A5L3coEOi17WTG1be/aymi5LvuiculR08e6TGn/wvs7laj+EcPLq/5Meiv6uKwRFs5+
o7BvM2aqGJZWPEUR8LuanBQBeBlZGP2fwlTHVV0sKpuO6T91tRO3xZoZVcBpUbkwv5sPRex9HMph
9d+Fe6Qowns8hxdew24aBjSxbnrcP/WxRFiBByByClzpOcnpMfnjlHUUEAKnxvrSZau3Qp3L0dy8
a7LrZJV52FB2GIWgmUzKDB54c6KO7sUahYGFoCBT5lb5jwuV8qu35w7nUNrDWOe/gEAUDMHCDz+H
CaEjphvt1TE6eYhpOtWRWyoOFbtBeRihdAKhgkAMmNmbl+V1iAuamV+t3b79ukWzKqrj7YQ+QKVc
yXEvqZs2woC2VYpS3Zw20DJ5p74p55crXGn0uvMvZkNqD3Q8yTrwYlFpJpZ5WRKm4d8M0mQ1lDko
xIqbbq0p0OziVEUBKabcMcla1XzVVmbLeLXeuul7Pjxkrw4nhGBUUmO8jxzsTZ3ZlSe5Fi+lBg5k
Wn5qvqU5plcX8zolpfnAWel5bdGHFHNT+vmZa2RPx5mcI6Z1cOR7tuVUlqzhYdbUtNyMgDANA0E7
HpZyy5M9kuQ6ew038zUv0rfpzzC8NikrBJJNRQ4C58NW7769xqDxsBQ9lXvailD2k2TdvivT4d7R
LROAsLyJwsrNkcNTZSzHQjBCIdtNRztUTHWOt4dk/1o1J8K4MFb5cnpa2aYExM6AUmZy807eQo75
dJc4/2t7iY7u9QlBMpf80wtvQ3XeBa0dhDyD5ZY/eQRPSGiPuHk1UPbL8g7/C3kJpyVJ92sn0LHb
wXE38R1D9kLAntL5U6b8qPb+Nt11bN1s7DWRRqseV+7WorWlVtMee7v3a25GgENyzTDZYKpTdRre
BxuSL3cmD95qbnbgVhXi5w1+4Fx6LBOo6i8Af3dXfs+S6ur1tAYVRvVM1A+B3XuDQsZeI9wjzXqN
o+ZHGUUoaYoVf5E45ggSM9epM3fEZZC8uL51n1pqN0pUb6qazjaaJ2yZB9Gm6Kv+xZl7cnWdHTPv
rLeE5LyLTfYJ8BBDYda+ld3DutMtGyGdwZx0ydDwYJzz3gZm3gRvM6U+XcpCwySubXHKjwOp32rZ
l4sGQrlncIKPhjMWyCQeo7aoq4+tXCccbfmGFn89nO5h85PLcn/upWCIwzIkIVgpv5BHFGc+sl0q
humZVpJ2SynUf0qhO6ykOdLxLTzmVw+MbV6rtQwXjRz9p/cpcSvFk1lZHu3idwKsYXWsZYi55z0B
Wx5qK0SqcK5/8dr9sq6vjU6PYchm71zQ94E699TMJJMF0OsI04xLpSG4iG7fnzBrixQYaOAMKmIf
rmS96ho0ry4kLpA1qJg6Hf3BWQfwZ3vWvAOApSR8fTrY++2c8qc2m2mcYnUtYYVtWq1Igptk/2q1
9uNEgRZ5vU86KYtOr9RUL+e3MQ0/cx5NPPpTm7ihCqFifDjfX2aaHjTBJS3GpVPrH3uS2bkj6XW1
JDWIE6m5Y3lCt/hLTMaBELJ+tklB8ocZ2KYEOMxTZpYgffGkB0jl/tuGUdnMOsMkl+tvlNdPlHOG
8nscDmFV33kpykodihU9t5EXH7haliV1R5gErtgpa8VUovF2QFnjWEtnduo1L7uR1qFly0WWTNoI
GrGyP/FPbIBfRoazYb0ea/R1qYacfpQB2WJkMMksZcJjL13gTgzycSSWYpaf4u0hCBqUCvsc1YzK
5qyf+SK7RhqjvYVIivUbivinjZOXGdlcNbVCgeTL95pOtNoXW6ztGvXr1rNEJ++je6c3L5ZondXk
0qiTtyxakiuaYlgIRrY/EF/XFbGznvGAo/ylw28cqt0fORkN6sWNydUZfPFXpKOgzuV7YRL4B35j
5s7GaibSI+XH01nDCMc2VZg2n+PhjaBhJmzbYv0CoUk6EAHErKOc0kKBYGx4VvUMazNxUai2+lhc
ug1Ir5HYm7pRjzeLYWMCd+J2u+4JlfwC9z6fBOH0umAo5fUr0qyLS+tcY6KaeEC6kajafQpoJDes
lWpGxqyJXHZi7x4WOw6fnREPGj5uxYzfbiiGu+lM0Uy4bE9JKzuSRYdWBzvTsKpFy88aCuyrayFh
qdyQAHGobHHQXrIxcsjo06i61ddgKTz67jkhH19U8dJipxaA7R/nftep1YiOFd32ixbwdjc1ENPy
N6axvkfBRV5xK5clsEzyQIt4vC11weqgQFdnCjeyucrypouEZpV49UOjpH80+A5cV3g8ZIM1oyRR
6PbFJbchorxkzracYG20i9uSs+iu/okvmSd0Fk8Bw8FkxKlLheZvFd1JFOtFLbhLb0vBfhpTxtmn
C1TBgw5q8fPMbj3B3zxxVFU81p52XUZNd8LpGKKVvaJUAAllJDTn9/VGffjR4M5r5E+xtXnhALer
ciPpKJNnTNNCWpxcmJcwolBNg5zbwm1hSb6dMEdKssYXc16hgs0WEiFVHDz19a06drmRs6TbvEl7
oZl3GwSjaNYcW6XT10GE60/2RKfkZ/iDiaY065BwNpSdbm2KE2XvRDFygDLbJ75+VxOyxLEFOE9s
6+ZNozdvV7Zq1+mKAWPhF6DW2YPLiF0d4ZMlmyeB+Frfv5r06pQc1GXkEQaIeA8TVUrZuHaP521+
gk7L7Hs1xmhaJE66BTgNfXihGJz0p+T72gbttGD+RVYUaUausFQVdQzNjRT0q5EpCRBe6HWiR/hz
/EYz3myhurW+Hja8y3pll4nGS8xPszY/HFXLobAjCpwwqH+R7woDRX+2+G/y6pRAK1IA7pdefi8l
YNLaABNIgUNm6qVdnvVWptfJ94XIHqfxdZlCVxJKW/qqOaqrdep1bRw6su7nWHaljSrBNsiXvdF1
0p36RBwFVBeT0TObuLj6YlLUMUnzq2hwMhVoRBN1z7lsHVJdVgrxXvTn4JMWgotHfwEQ8elBNgTx
JUWWVL08K5lZD4YGLEy+sSLNxriwRVIS70gVccISu8w5rtf5pUqakclxRXm24TcODYxZeToq4aoM
4X8Bqzq9SHlmI5Za7DDrKGVyfXGY5dOygZUUGBQ3UAm6/YRtNlVze3IT6nziJHQ2I/VObbotxAbi
5P1hrqOCjs4R0weprkP4rgF1eeZnlxvKwnIhFZUKUxO5lYhDBuaxQ5HghCxWcLAjWuJBpPC9OGSf
x3uUL8Z8vwhPZ3OVsu+WgyvzUmVW0z3b4TLAXuRXLDlH0iLZPXLGfMjqNKoRKKrlsHJa+lkuTw3d
K8h3JxqmWmO7FFPTkyPZYF/XZTuMl+mCDTQaUQNqzTUJN/vxg0tekHFqNXCAb2Z+OQHNstyEYaRA
S5jOIUyiGuK+RxZyY63OHLMrUTT7xfVSuuVssb41EFG6GZYZFfvqmYzS2NzriFpdqweJBHq1E5YA
AVIpKb+c3qkwOF9o5oKFuhr78l7pCB5ga5PzLyAxy1ovvWoTgfE0lk7RVt4N83tZMBXZFZf8tQUx
8ll9ADffsWtXRjP5JdBcs4saJlr2RZNuUodhSZlIp2rQBgwuJq2YsgwRaiwJnYEcXA0XbLtAy2QU
r175a0/sT+oRF3cC6rJ/+6qea2mSs7m4nQzptS7f7NqDiOPqBZFXfJpjXbKWkm4LHX1rRCUprxTl
qqo4Zhlrhs2c7jvgLGNT7jn71qZKwdSQQ9okuW7pkM6RYQNuO61APivI946iNlmldYOe3S3TeiKl
bnPRqgxktkm4KP4Rxhq6nRvCWWi1oiQ3w54usKcnnJyQr2XWsvbnAg6PIoVL8jT2ijCAs+iwZ+ft
jL19wnpWakpRfkYJE1/TvPSUCN5lYaehyCWm7Tm1Vf63HPwy4lK12UzY/G8ycwWOjWvbpy5cbmRN
Z3TH0qUc99sViwzzF+FG45CIZpGsb0srsuu3hDya7Gw4DtCkqKSjQymw+kniTUFKwcsVzG5+7rym
yjHkqWk5bkq9O4Zv3a2Ve9am36REJzTPVfGoe15wCC3giaUjJtm40mzxWLulKA/LHm5SP93rGEwG
1hkS1sX7ZJ4zf85RxpPqzddoLYwtIse6ZRCsPDdyT5+0uRrUWYoOZ7Mgr0WSjK6RzPMyy4WkV6aM
2rvYDmzoT/bbAE5rVyZHvP+EJTlHspt4qENg5xgvjjveJNyzdxgICWVQP85O+oBP+lefwLhvIuKE
FmytT1xb7En0pEcxdVJxd3alt8IRjCtyMrG1Cdmr33Oh0iZuDEobBTbuN3J+uN62ZqHIzQcmZy9W
9aU5uYRy1jgrTB44/kqVTc7TZDvidl/PaZaeU5QUK4d8k1FGo6ABzzNO9tcg51YZWWVN47t+dtEC
yeMhL07X28NhQN5WnG1krKtMRD8S8wzlBFdbxOWEr49rlCI+3F83XxtgzELmXcajRUYovusrhvTD
QW5h7pIdhcz7PHRCLd2M9VfzVSBRXgYimhAQVy+1j5tX60m7j/IxIA2zGCl1+Nm76f+YC7ZgVKxg
lJXodp7TBGIJ4ADo4KMfbxZUuK8gQX1yYIHthwJKfCWXbtSSO+Jaj9lkD9QyykqvfsptU5EsLUR9
j/WlNdw05Q0DaqZtZW1hnK08yPiS5QrOnxIlqmS/1hOeLnLOuNCq6jAQrAcOewz3G2Pb/gIi2AlO
q4rNZnyERunr1RzX3LX0lEwTMGqmZJv9EPRcKBUEs4k6ta74p2qSFFGXcEVDkWRqIQEIydFbpOjm
1HrFZ+YTQyOuqp+5K9m9jlbLpjFEp+fqN82UHx5YRERSNvjp/OLri3Nrti1sL+bxSXbYnAtn9N2O
aVqbKTKJ1szkpciH4ERviM2A+/6dZW3jzksZNCsbes1o6TYHnimblj1iG0sz/j9tz/pmHHOrB1Gx
XtzF1VvYpDM64304sShmP/w7xo8QnkJNZ6Q5mg53PAWqqBLJH7lZ/R0KJ+stVwsSancucWI9wIf2
2Q0e3eR6o5p7QzlWqtzmyolzWi5xZdFVQVx9p2aJyQNGgYHfD16e3l+l7337DUvCGKli40RTbAmV
3Ohy31c4UMzI0XRc2+FVkALRj0u7c0bZbDIJLAxgrMazjim7a8wQ6yHSHgTXHlyhtakMRrAtoeXo
gRphElEzV3pezuWczrD41EYy43UoqQcdGkMgCT2jFF/iJjsfITtpePSTXGTFqKZD+1gmF3nH4TC2
a3cNCDpGDwPvPnr0yMTOGekFkWRQa5dvKiBd1aJUFNvdjkmCvjlMcoggSXAKbFVYIGIncvbX1US7
5gYJGdD/L0BH+Htil/D863fDF/JFdDUIaHjILsiy5KE0yo4SRyq72N5AVV1zdqfviTjkJ+0MGRXW
v3QmAsm2yq01t8rr0NboaG4payV4bwY91KS27ar2tJeloj/GZnnxqpxZ4UGE+1M550+J7Fl20lPa
25R7K6qvuUQKZh/KaRu9QhY6RSUhbopsn83jbGli4Eug8WVsnzd6sZ2BBOcYRfKNb+TqZabVXo6a
/15Wymn8UbcAsJfEJP+vQKJIR4yXGTeH70/6Dw93d68+n06Zn12UzKl9I0ixmFHZpEG6Q/axMGuh
y6PxkNJg04irZtLr604Jn6SPOvvI4Uoxkx5yvj0ojOi+4VrzWCg2zbYlWr7jJvmuCXpNOrnML/KZ
gL4yiZx8KsvbLcL7s+wkTz9ySxMMIYrlHgM3MOlGNVYgliUD4pmfpcFwHYEeYo/Okt9lqzLTvW1a
0hGO1kMc4+P9jQLTFqTvPPkSLea5bCmQqOlmfhuGZdJ55/7hmMTe5Q9A+PjrMdDq5uxh5+7x6OLC
bkQ1KKzGvKfCII6GQqMH+FO2PO3F2iGf4OLi3GzioO6UmCn35L6BtcYMwdKlf27X0pUDTi4XWbNe
UpHDvD6URL1FfZnKrGatHn3hmkHfQHNXenqX3Che2PrhaSWOtv1puIrvGs3VhzdOUHO5mgOBSW/Q
zE9+lr/a+PIRkU+rYSf7Ub7DAxwhIJUdriMrHc5kUxL7YqgYfs2q9sUcnHDgkKaN+Cuf5+pj8m5b
xXIKnxRSMow/+qvt5JSV4W4XEiC6A/gSQWaCfvPddiCrGmGmzP4QOMi3L5Mko2X9FUIIfF3pmVhN
6AYuKxBolbBBsQ3kNcsvPzrrmaampzSbKWguO5Tnezh2E9FppiKmffFb+nVaru/uTY/wk/MXqf1p
YehtaXf6s91xOmfBkfAwr1aZdEo8Iy5cfeKjY6nI+BoDTW43nr/cTKdPL2nblFD0F7AGLhbFV10N
dZ3Bacn/C2++yD3JvmRCdqSoCi6EGgI+QlLjRjSvRHAkE9RorQKG7mnrBnDFFaupyc+OEQcfcXNq
BiBTExvXN4tCjnb2iXKjBPZ5e2jPLqHd05bt422+WFuARoFQfwGKFEGHfLPa9Q5mb36GS90sillX
CkuvJCRqNq8dYicdwi2ieo4pL7R0029PFQ5uCx8gMep1ji0NC1oGzkLG4KzXUmdeAGPGn46vpNgw
dylbF3okMgfRZfqECw8ipbwViNSiH3sEo0dKzX1WLa1y61eFl0zU4v5xwfcnIhfeEuLFT3na8hP8
fsEyAbOXDhu5169Pvz3e/7gEy8CRXLrmvpdAdH70vg9eEjz/oCljIcdewH/RvKqwNMegg0s6Vxfw
HMEZErF8OlPs79Cjru/As6MKsVQLGKd9O97SvUJsvci+YFN3/HOjOw1Hs2wr5PMOdiB5iZLxfjMK
9C9wev0LMBy8/iaAkvh1cHg7V534Z7DkBiLQGnLw+xGBzxcRRBx8VsWfCrpOwI4p2EFjr+nVhN59
EV9UOUbje8CgZ7t9ojNvDTys0y2kTJbMNfgzSeDh7W/fM+3fcB8is3EQ1wBa1d2JP0EEUbmN10GO
1AcnEJ1KmLcEN11Ovw4aD4cyhpso6VOOtp1uD/hGib51+ZIQrYs9lX2alDnmfpoQh3Yae998CJtN
hsJSE2HSfOm/hL4EdCZ9Tfkk9la8u2yPEPlGXooKfr77+A8ys1WZEVx6Sn9dBH2bdAh1+PPx8bXA
FGbN56RksJN1dTq6+HrbaVhpDXB7YusLJkN7OJjN3CVhafM+J8Jz4VM/JzchhRg0oeLeDzi6W7kh
HvjmFrQZQkaKjQH4FBGMTj1BlXlRAxyYXhIHIg2ITL65gLpjsB3VxfmBHePVjPW2WPuGjTtqEv1c
8QxPD4wzi8qF7QxNcc5K1y2qtLS1DgkXkttJI9UzYg1BqhSfDkECDi8/iYSOV78NBFpBOiijm+tb
Ft5l+6SP8GYd420VmVBdQue3cBQ6/z8AM4DMf/rk/T8GfR0fGwDiuyafj6qa0go8mq8VNVRMFBAx
ygPrroAm79IJTCStTULy7Ojmjsd282zYsH9K7xMReAQwYMqYrpnQZ2Fx2RRM3IUyQm/dAxRN5/AN
x+W+3+XCFYxT/qzAUfeO4Bv+I/w93u42boxElBDlFUweahQ5idfiYNwD3+Y/D5ca4Vjhy7pEDn+r
v05v7u4+192/GDbWUELAdREm8QkZ8+T2G6RRvd1wLq2xHX4czuDtOOK9NSJ0o+BYISVmq+Q6ZOxZ
ZWZenBzLHAGrlSAiHqzxWOI2XPJo8qSglLWNm8bFwONjlIKSkK0ywJOVaznQtLEKRQrVCMJqFiYV
hjgs4LV/cbrlx3UrUa1+Giwb2tvN3MhvG2ziYJWRppwbcNR2RGWLKbOV+CkHkNNzS7mzyEo1h34V
Suup8IZKNaLPnUq9kCMXqzZmkVVddNm6UTTMVusJJSomkHJN+rON7Z6yVCDTypkey42xYxfKWWRk
pG51ht+npR65aQoxtRYlU/1UZTQya0iYfoSVf1e3kQ9pcL5eolyMODcRET7F7HiUkglAA/Uk/WYM
zsAHo1vP3rZLjbIXmIkSmAPly89ZnO0MErN3x/G47ynAXRrArZEc2SPr4Vi2JtrfDsopSUqsy4l2
NcM0loNvKvLA8bJqupBFNaJK5OQxkQfGslkqErWalme16eG8vSsrQFC0zp43xNYLJKxxWlnts9WI
vK9v7S4x8lFOo55YrnZLhCrtyWEq0bDquaQchK4RRyFUFspszSr7O0y0qMYqagrF6qWCSduV1mrR
WGkvD36rhxCGcST8I6T2fALJrMeJl+k9sOvBo4p0LSee6dFWHDOVavZ05rKa+J4Vjd63KUlF+6aw
43NzYGC7metK7uBbtAF+vAto1SVRXAYRQpTgKQC6Ij9JXYn2GBASM8bqcCtQWq2lNTasaHd+r+sv
3ZsPl0nP032KuBscXGWC16bIKKwG/wALy8vhDIuRKXdb0ouwjrjK1yvoWtvjyzubW4h1xr68pJov
yK2dV24VZu03E2B26xSbzGmcsbYmzvJQLF7je1aRsBSmZGFRtzuTjpO9xsNkeq21GTq2MkHVphXN
6Cz3CxqwCbVvXpGBaxhvGSPgSHtBrVhdN1isuRbbj5se8owdJrU5bJl07xsozt8hXa5yAIQGM1bo
RWcdTT1QleblZ3BwawQhyTs4DRsYqwuzHuku4XqJydbnilprNMxdM1evWGNd0SYlssuVbu5CPh2S
OMWkgZoYka2MWx3KRC17MoowSVcUt7QQW4cXfOlY5/S6PSHaeFQ+GYYCQq26x13O6RGwRIYbDSIX
90hw9WpPWb2liByFS8f6WbtdqzfWz7OOZMpVOtTtfmJ8jywV3DeMZOMna+6h4hR0ZR60lLXAta7P
u5Nq0bS7c6dfiVD14xXgyBnC60fK+n7MeUc2T+n2w6jbLMYsk8XS2JEY9tb5BqCsMxuydjbEIwmy
hB1VJVKTCfjWPrDLpKIRfOsQxAiSM0Og6zHYMByWQJJLIkLEuLarMQVSkHmJa7VHmNGuV69NX3IU
xbUnsQrbq+9ZAdnHVGbBrKvGqRAFZwkB9c30SKPcRSWQGdos0jONsSz+YkHLKlt3eKko6KuK1NVr
g5AQmzviXZCvtnDxaN9UQqyUg3WA7kFEjgUF5V0yu7iDEhQVzBxntN1cmIoTwNKmxMN3EtqvwHy5
948B3NXUbNUZ3pg0V12OuNVncjUeo5JhbnAV+XaPn9XSmsjzNrpzF6v3peDil0YxVNq9QYullE+0
IU5Q5y717kKcVVRKCaYG2ABOIFAeb6vKJtt999g2+t7uDff6W4kmkJXU9DXmTeSjDJ5cd3Kiu4NO
PjGBzte+pyTGzNpqcdTjY7L86IvKwrZMzXdwBhS9rgH1Tr7rB7G6fduTrsJ+UPa5Pebl9+3l5jtx
53pgRgtMSLDTDLBkpJIMgAJjmmlm7qjBRRIL14Cdjb0U26p1y85KrN8tsNTq9kLCOS6C4sNpcvGU
C3n30QoSA8QXQLLTCDVSxRMadoZdApVl3bUiInUXRAzwwvesbVNplzE9hlq7BT+RWKMXAakYJSVW
VqKbZ+0JJwx5FEo3JHHV+RQdxF1WqbB165w84zCaiJiOeoVpSFtHGEYnUjqIxlhKasUnTIi/yNlb
rWaBZxMs7jgiKZY7O3BtBTKyUa955GFYtycix+Zy4bohuqqmU2/QwGnec+yuGscWEsdEoy9uQC6Z
dk2FXi4SMpkGtK2m4XlxAKTUbGRjNevzRUzRcfONUjylZKY5RkWPbNw4vSaoXR0Qohh8m4NMiuu+
w8MExtltFzzIG6vNAO46M75yxnZNAWnzD8Rk+j2HJmKr1co6brlQi5oZFOkKci8RIPJNzDQwrtHo
NISZdNVZTsjyMnGnNud41FRr6xs1Y3yVhXRsyol8qlgu2NsC1SgZHq8PALR8tGWKuMu8QJZtcsVG
V2xNYdmHha3YTsyDZzu3UAig8vEQ4w0o1uw4XzHnW33ydRx3j65w+OKXLU6sBIsp6emomy2FrcJF
pJzCa8LT3jZFnGNvCxc21de2EQSZnVj3JLJvy6OmEXoyZ6sLrb7U2f3PJ0pj+j1iOgEpOtrLQzZ0
9SG2zL6XQmXhrEzYvndfKyS3gWrN0vJACTZY5DRovScXCNnBQypMAZmZrq5P/U72IiAhDstRfUDd
9G8uDuPU5mOkW/LuFbzQb3TJcYvHGCo22rM6s6iYSu3eoQMND2VzJMT1KJY2MrZNJUG8q1ipoCdm
cAUL2ZuV7WnPNHJ6QiMzxXMh1mRpJ8yR2RJG1N69OMmEOxPIov7Go4hHdL8YeSCLxhJoF8Lr3fpZ
eUQTCcUOuQpo4zTo5hcJ6XMDZ0npu4SdszpDoXKFQJEQJKBFQjlEHDaCKfx/1hfWtw3EF0ZtRCbj
lUvpEzCT2uMuo/SfT8E4/wAALtX+RHuUcvY5xhks8NOMKs0ohWuRqr4w6aVVSHcrWdA9YtX+pbIj
puYZFt+kCAcQ5uHBG6UxpIMKmHCwbq4QQODMQ+W6dkezof8AUXPUDNufWTz/AIZ1P4vpHpKLNqCe
3xm0xDI5NzHYBsSsDPyJHlOvr+eXjoGMihgDTSSgonMsk2Rr4mUSOoomUxBeGsuo0n6jsLYj1S52
vlvtLVhjC+43zRQ4SVa1GSmWr5O7S8K7gI88MSFUUbNHakVGzoECIAsad20h9iC4STPFmc9Hdex1
lTFGn+v2C4nypcn+PoC1hdIqANUSqXSHqqzaw06TrtgWmXEE3RsSyowdhRbTxU+ZTxwC9eHlJaIK
hLa0axpAoNzyF4greZbHt/tV6ja0Z8zWq6i6dkmIheu2BZnYISfQhmM5WK9J93l4KwOG9enSWB4o
mgKyk3wByIYe/KuvaLbJOHFGAbJw/u9YTnaIcKDEntYgmMg8yn7fTdZtaS8zY4xrJaqW94sqMZDZ
R06XTGNVk2UPMzJpK6SVwqc5WXjiLLX1H7Zmz9XElE1OUCAUOYo7BvwiwnnGpVrEFlx4+tY1i0f6
QGK8s12alY+wuqwWKp8dL12WijmrLe0PRnpNy5bSaTQKd3JZBwi4LajJrEOaV8W6DqBmPXBOaYKl
br+0qVNUvprVJ2NnUVL2y/JyupH2GFinyDssU/VeWxJUYydSiTy68WmoslVjIkMYsd4s01YxvOWt
QlUQLkqUgsR0iaslYpUfLViuZDscmzvFbr1ghnk4C81UW7Kuq2qbbyMiLoE7Cs2iEYk5zqogN7km
+ovShCRDWZEhSmM2SCQJzCSATXCZtIExwP7ivAbufHdaf8R6p8GQmrDV7lqdnnsDjLOFBzdU4NBS
rz8hPunGULFCScTIzkfDJz4EYMXMJPpjGrSATRFXRybAbcOE9D1mY9jcMYExRKzZoCTwPlKRkpe2
OKq6vTK1Y6mbQrNS8dRjnRCwVa0tZytQLNmuZtCSXhzuUEk5yFV2amLdEmIrhrcrum+5ZBuVfpNg
i05mEWjIZi6uBZeZpSFpaUrxpM5oZhKRD9BsjLW2GjHcTZV4VunEKqHnUwV1WHNFbSzflXtlmg8j
5IrGPcuSeEoulYkkq7GZPNYGMPablKW+QfWFVOqpUyuU2jyjhnFqrlfSD18BiiYThu3dbx0lAjbN
MOEGYuXAdToDGQJJJTnk88L2CIB/qqnJmB+Hn/bYzLp6SXDGRMrYUyisymqUbDeUrfZ5qKcUuHul
huFGslxmshxEVWJlRYnqm+7yuSJlYZeXg45OPX2f2mwpHchZmpmjXdphypj++VKCrz6tROQMSWlo
pUZqls5xWO1BzOSmV3XvLSxELLreroV51YoU1qJNd6BZ6Lca3znEoseD9GjDw0RbshXImQsk0BLI
KtfqsJihxCxV8qGPnsG2tX5Q8oKWNRKuShouOlKWzd1mouHVdaj4oVZ6QU1AAXJfQHl2XvGeKfj+
Ug7w4wbK2c88iovKtJyfgaygi5czLZqmgMWi5ctnLdwVgWc5joOEVQKKapDGrFh9MQoYRETCQAWc
KJ7KiWLmYBKjOkmtXYXN3KlvI1/xn+1W3hthgzVg+xpDZlJkG/z+Tkb9gCdwHRaG8lrdM+qK8nLV
N/ESC0hZDMYyEY1eMraTFBjWXtsI2OAJiUohtwTmRdbWBL/gGo46ni3Oxua9o2pODWtdkK2k5iqx
mmrO6+KWRYRWVlkIWOMWpNZat+usG9c3oDTZK/4R6vTc08a5tNvo9MF51x1jZOKvlinci3fGVztF
psMbb6/FwGMbjAtQe1ygSeNV3HrlZGEizHvaswxdCVVqHeCnMj7fC3H/AKNzC2TqKgnT7TYZa6J6
cp3LFlyJF3asL1+sZTpZYI8viE2KJdilcO6pkHncvVXJVEC+0sBQ68KGHeZkwYSWIUolRDMUibhm
OEjucTYkoiQ5TOQp/j6nwsEeessUG11yPomOb9J1bD9CqtSc0HE8DjpxEGsOSWkAyhrtesqOzScR
FubbcE3dhB3kSLd2O1WDvogvEMubho5HzlRVdLVA060obZZpZpb0sn5FuGQnSzmNgbMhFTMMwo2K
K4tLysdEVRCClnD1/ZE2UPKWiQUrvrI1aKPGfaznqV0dY9wXpK09ZVev7jI5HzjWYq+sZJpMVpam
MU5EO2Xog19N0aSj0F64PdlbdHFsM9LTf5rYmrFzsQQ+PhGPm8Smy1ja6JXQaqhDNssUSRYPoW30
dy+aizGzx8a0l5tq+xYLyOiWnjozASouX7FD1e7Vy3IoletpH9oJhoGwLApOLEQQFPoQZHN66A0D
YN/NXrRIlL6ghu7MyeV2ypTHek/CuEmkgvLXahZQy5d3r5CMdxdWawOQI2oERYxbt6UsnIA2PANi
mKjBn5THTKOwmABDhJc5RAgmEhu9JEFw3cAiq3Ovv2BEdjAPMt/ZFAQMp+wBuDNd4uxLP6SHeZan
A2uOyHTcqVLHV6dy9vNJVi1sbBULVKFsDOsxxIxjHOll66iRNiVcp1FAApSmN04D2KIzcSLMki8c
NWQukm7iUbJOF3sbGqf+IOUGxZYzl45Q82HLKGMb+z3DjOv6LwLygRWhuUtgm/ZYMZiYbj320oay
sOQ3J9LFdqY1AN8207T7BhPO5Nxi/FLbHz6H/J9XseQ8CrGyS6i7OEewlknH9qUcEauTuLG4bQYT
BGzgwLKgioJdVooztXNNeqTEmcLxDzNmq1ClXLyViI4UFn7wzyI8PUeNFnMqdms+jJP8+aAnucpP
pC7FAB4l3UXhfA1cwTQs342pmScYRmU7jc2+I2d5uJr66yXQKAvHNpq22dI6aZ6I6hnR643YN2wT
ZZNd/IIkE6kdHFuYAQMOlYZ2MgiSMLEKyzxkwLLTpxSjWJHX65+tMxx5tZFsQPrrqQxUyj5mD3xe
kx4XSuK8DG6R1HYZaF3zcTJnLLoBgswUrwBp+Se4cbGxjjM1SqmRdPtzkMtZdu0NjLMC18sEJJ10
ydfr8IlJQ55Ftj6EmcmywyFrs5IxI9yeyzmAjQIWiGIE+CDgT2HY49JRiOoZFwXfJ6AyXcD4tzdq
cu82eSj60vLvapm2IgI+qt4x04uss2WloOSjJd9O1OTFmydlkCKxdlAFSmGvB3oO1GQkwjV7RAR1
csMpkOAxnRYuwSMkVzl+cmOxAH+JT93ShrPTYnu8AFis4T0ZGR3i0X350j39p2uzyBoXy9jZGiu7
NZcchCX/ACE5xUxnwfZHiYmCsqR002jSxKWDHNclVWS51UyIScDB2IiplUypnMY5d3DFvqoYhi6L
IdxIzcAMRQhifrlKiBAW/wCqsaST8unfT7mxE6bNcNMwDl7AmRLbc8z5ehcaflWjpesKVWpU2uV9
jkCIi49k/wAeQQ3mxjIzUzJnmX1sTlnECuUrOLUYFIUyQjAmHs3Y0xblrS/epS+ZxvUXh/KDq+3S
JkKrX2ENXGbeShzsY/DdZVyxPOjWCwplkj3N/ZZuAjJUkdUjRwGCPfjxHGbtJ2TsD15GyXF5S3Lc
b7a8WzreqSk9IS9XuVdai9ma3PoPq9DRHOZn+dxysJO2BZRqPbpAKXt8QbQaq7v1wqdEZykNX3lr
lYyEi5OyvZBvBsnLtfurRR07YkmZWL705/Nm/coSwCuv9ClzH9niEXzpRN5MDqm8kMYZSChmerHU
iYIL0asQU3ebxFmeYG4a7z4DusE1YahaxrlmMMEiElKfkitIXGoT6tpfwFNw2wo7eTiH+PZCJZt5
+Rhq/OMHjmRQtUXXa2wiGzhGHRaO7goo3BTmk20M9AuoTHeoe7TeN8oQUMNqgnlZxDkSEs9pbJzt
cIgpMsotw6YR4qsFlU0WSxJjbtVSJkMJzlKLNsHo5c9xF3xvjllMYpvFiyLkWaxKgSm26TmmVVvV
USh5KciLW9l4WBISKSdWUyLuQhj2AiCsBLJqmKdhKhYW9bNBOaKa7xCjJzuOVm+bsiTOOq5Ku5q2
V2Li7BXvVwFn1qDItDqMu2jXvrgy7FxBwNgRV8Lccpjdgfl5EG9riFRgQnMsGIsxpINIAFpUBm4n
TBd3/nRMvdT8vr58bOqvawJLDc9hC9Ywy7mrIFoxRMXp85bZcjoCJxzFQtuZRcUhC0umwF2urhgS
xIHmT3OQUXhySpWcWaOOYDJCJK4210aaNNORcMO9NeN8xMcUV69z2T8wQN9na4vY7bbbREMKjA1+
olZTk5FQdQoTSQnDQpHk6WRshZIvjR2pVSmPXvdtP0rj1xApzuVcSqnl7FaqpJEaSOU20pTZes79
+dXauTeNoC0tI11yiEOvGVidRdco92MptwWWrvQnFY91sMNJ+B5yMtTq1v6hVq5Fzk3MrTTF/Yoe
IZuXdylZOvt6q1LKyDZzIKHh3c+MYk3WVOBCpKCWio3S74FCGFYVEpmAUjACVEUYKFS03qHtcbCu
2XlkM8Lc+NTaHZ3ONUTWwY4i8p6icplxrlmTv9gaZMawcPWq1FpyVWUQ/J7Uo/JlsELRNEinql3k
O2ioyQKnCGYdF24nd+pbVJjzNeO7hU6lCWSJVn9VWVc6sFptCGbsiU6616Fim0JJKRlkm3Q3Buik
qcXEaYrApEzm5OUptoXldMFnb1iqXxDIGKLRTbVlBziX1nYr5HM3r1qjUIh2spaG1nx3WpgWz5s3
cOEfBYCwgsggusnzJpKGLLF89HxmijW+BoaFuw/dbbNZRrWD3cTQ73NvX1dyPMRvJHxNheWWBgG4
xrQ/sTD6DCwlan9lyZM24cGWvplULZNCSC5kA8yCS3EzO+c3t36FdsvKbD5W59Szt1p6ssK6ncxV
TO8BAZUqd4eL0lnkNqeXi680g6tRomMjzM8bzUJPWGSUl5mTPNPkncuhXla0RlFKV4zwDJCMe6k8
84eyhR2cLUWN5sd9RyFZrJJ5IyBVce0eek6rMxsGm2rNrkKJLWQmS5kx2okPMWdq5WqJ4YSwJ3Q2
6dBs0M16McxYKorzIN0eVBeFY3s2PXiMC5sSE4nOk5OeRh4q71yrupWLL2qfM6bJKol5ycxw5g3E
2IZrST5FmTuTdR26aR53Dt2kkzauHH69ZZVQ5Ukip/2gnMXk8zCHAMV5hD+GrSIN5E3Q5kG8X40e
xAi7xP5UeIrPrJSNOeTYvHuurUBIy2n99OXuWn2enWYqc1R42TkJN8wm5KoXxPJTJ3bSvZ147sNg
UsJ0WaVoku/uTxp0xKzFMxdy/vfpHMaPYfOElQq9mOKvmqevK0HKZrZZmk/j3HVNurZNTNy+B6hJ
zD5E0teJpVN2zTsK0AqgKiZkyjzlEWl6VTCOnLTrl9vgrENVmYa5UdtWEJWfb2p5Z4i5UeSplfly
Ob53qVLOscqqWMlkeEVSapIng39eeFILV8zUVg3OGJ6ejpY0fXqtU6v0+5W9rmKvX6RiJGwnG1hT
bfCxbRxLNpCTljO35kElTkJHAKpk0zmABAhtpgxLwqBf71d0piXUMcSiUrJxJPZAk6pzzmZ2Fskf
GfLdz+xtPeQ9feJci4Ss2lhpiq1x+DK3SWbPAq0lZ/FciV7K1abTS0bkS52FmoYHLiy2NVMtmi2S
j2GGmKkj41MskcBFnt866e0tErHTS8g8xu7W0y3O5vTsyj2ipV4b7M49j6EpBFbuHkosamd4ryMh
4WAjN9kILeN8g8wgLBQTgrwiDduZ4so5MUiLdMy6pzF6GKRNIpjmEohsIAURL034vMX0SQ2GPR/6
nJLNNNo459qkhiyzw8vGGcOL9jWByCNX7ejWeZKIwpnUb3Z+LqOiBno9v4u27Wzh3hMRKFRTCTEi
DGQQQ7yKiEkgivaZ2zJmTMS0Q0M0Ulxm05A8/k2FrUDqd0YZaaMRZYLynXWtSwbIUWhY5gLdUqlh
iHyW9YOWBcyy1fp7RrKyNiCbmyPLaRUDLXtnDRMNNBMB2SQwBcs1OJnG1Hw/RI2Qx3iuHqcG1tdO
jrCui2yjfE5JlITmT8gpkTLHzVikZZpGRcdElbTcbW6nBV6HrSL2WdvyqybTsRnnfR/3bMbeiY1f
rN9WNbo5siry9pTy5FQXqVWXkZTI9oZr6uPaS4lHLeQdopTYvhSdJLH5iqJn4XRekWZlqJQ77+WD
EcE1ynWMkWCrRE89t8bIO2+MD2BxY0H53tbRhmZG0nFxjKpldT8q1sD140bMYJwsuiQ70FEaIi8I
NbswSrESSQA2KZADKm85PkDYEcnahALAsXFeZA211G1kVygULELG60a32K7ad7M2sOHLHCXx9AVQ
0REyyNyq1CyZBJdkrbqTFZRctrQ6hUCqzcgwXQjxmzEVIUzcpPpI8jUb1ln0YCDseU8xZQlbvn/J
Fhia/JSGTaAs4gYlLBMY3kGr1pXcXyaKMya2FICVltBLgAv1GIRe5Nyy0JZIuVUxbcXV9xJRobMl
SfWqsPbZaGEMyrtYZzz+spyV5l5SyNV4ABk6yWRBzWYa/p8qZ5nnGXKallFl5psTgMfYqyTdslVe
mQGaLZfKtS3ravTFjRasqDKwVetFwtUrEy0e5Sqjlx+lI8IKEsNjVb/nCdWMn7fC98R0mq8dUIKZ
pkXDggLBOfXdxqDmHseHDSsh4igZaPkX10bM98y7h9cumiGxtkzD0LpgtVJx3kjMzXKNhiMc5mfV
CRsFGh6tCxrPC1nskHXEJKyYpjJSHnHbCnSLl/EwxXfM0dPwOYRZEd6QSo16VztTYbBEfW9MWcm4
ozGBIO4ybdGCsTWEjIiLuFduv6TmmdwiPAGsswmm8OWNLJmTFMwKGLxutCmmzC2UqPrysmSllbRK
4T0s5duFGVr8So7rLezIRky1jr0i8m5mlSc9MsJVROYp9fewcBIMjHSmpCZLYVCtAqilVEiKroN+
UzRJQyhFXAhGHMmUPaOUWwze5C+84eyHvHfrwnEj3q67FJSCqKoYxPqqUEKDSYnsmcwCzANYmxG1
2ZJbWT1anPlYl9UupRXURP05eLpkLi/HmLcewGM8U41gH6knG1Gp19STmikdyi51HM9JT9gnnLmd
fioqfnTOK5gMUdhRUOQ4m5TFNsAGHlMA7F2J7Q7COxfpE+o9PbJ19ou5Z6XNNS+pN/lSPLkGIoLb
FeIrVm+flJ2vylnbKUjG7YZK1ognBykbYe3aVABNH95aS/rXIgJZL1SUDbghKf6PZ9k+6PIHH2fM
TWupVnTrI6pLpdXCkok9o1Uh055eYps3UDTMtCR+TYlCNi15SFkbw3hY5u8arvLGikukc6sa632K
8aLhK0jGUEsAkzxGjUU53E5TKgJQGCn5/PLG1XLpPtO07LcOfk5P+IFClOmJf3u0IYpyCG4HKYDA
AgIDxpuy9kDcwcoplVA24copGEQKoA82wpmEpgKf6oiA7COw8GvnrB8DgiVx47q+X6FmRvbYN9Y3
UXBjDOZKnTERJqtVIO5xEPZr1U2xZqNI4eINYqyzqM+0K4cTtfaJFfGsh9+kA001u86s9CeGsR07
FuJ57PWmPS+3kFahT4ai1FzknKNxvsO6vdoY0poUj1VROTiNnrOK8fP4eblZCCY8tD0ZGTUgSJ7k
s5bQP5jvnaw9Tl5t/wD28LUWm+n3ABSNygBhApim2AxUjlMYAHoUSLoHAegCVVIQHZQgik+kE3IB
SCbvIp8vTm7QpkyGLt58xTqpEEm24GUTKIbnKA24pejIf26gZIvmKssRU8GItRVf0wWuHyBUn1CS
krfa7HW60wk6c4r1wyaV0wJZXiChFpo0AmaIcguQRQVcms8LandIuN9LN4yNh63ZzeyeaMalrrJ5
CI4tWj8eWWfkIGGmJWErN1aXKbmyoV9RNTuTycpde8RFNTlE4kNyjNwiIOGIQlU5Agn3cpH3kv8A
5DvEClYeEcX+XdpxNq/ipCYxky9kYpOUT8pijyAcvMQTbbiUDl9oojtzF9oNw68ORlVXrxoVyB25
CGMoUhzGKBDGSTUVVKUwjymFNNJRRQAEezImocwAUphCzPEvo55O66OrvrNlsv42g2lPs8XXoqhy
b9d9JvFpqXJHyas3Itzd3rs9Ms1CLwsEh488syBgVl0GqZiiJ7YnxrSaljrQswjabpfXksix7PKe
STZnx5DXjI2VzXLOc7jeLx1jZd3AWMIqMqlJ/wBY1GMfIVSvu1NrGZ4M9u0B+69Bxo3bJT1gghIx
MSkL60iQMJBxENMHihEjoRmDxLZgcc6M70tQXB1daOblM4MmCh0yrFOmJfbRUUSSIsUQHqmdVZFM
hw3KZRVMhTCc5AF8QjAq7pAiiiBW6opgdUyhCpFFYS9kBlBECAKvaJ9nuICpzk5d+YN7qc7+jnod
o1ZZ3wVpyyDDVa10O0OrA3xtlNvMxlYQoS1FhrjYZdnkatpWCUnjR0jP2pmDSTpaBEqbGto576wy
RXnrLH2kLA+nYc2RU1esvYyyDVqjaoiuV7GFr9ZaG6zje7MY6CxowqqUk4bY6g5k8jaGTqwpt7Ba
TwMJFTtXaGusqRHQgdGRFezGC69sEqIIDpB7JAS8iUyVQMcgTZBcVCzMgTGYyAB+su7ewjZjnsXW
3FePcKYWoQOZ2NlW0ja8lvoZmS45CtwrTLdnX4xEDetKNHYrrIoNoluuaRmFlk0kgVOcpTATe6TY
qDZJao2WOCIm4pePav4xbnSOR0+BuItklFikODgwPGg9jt2gg6b7FHtkhN9B+vGjNaf6RC4Yx0f0
VGv5GVkKcxg6ljuuVqAgK8pM4joU0i2qcOms0gY5JdhJylsnpQ0fDJQK7R3IOlEFkFbWWCNPGnnA
Vu114pxLlickM6ZFaSefbtqYmo20jO4huMxUMd3TI9OrVWtiv+td0h4p9XXkDliRsbdihbLUFiYR
aljpT1N7ZCRLobzdLveAdmuKkqWkUSlIBJGZLVHdYcBQ2uEF0OOsKkypplM03ztR4LZZYpzJAmqV
PftDJiBwJsKZRE4hzATYVUijzCGwqJh0E4b6wSFMJSnKmBlBKBCoiAmOJ+pQIBephN+yAAO4eXF+
K+P8X5h0e6yMm5Cr+m9GSxLY8A3SnXjTliWu1ydxybLWX4asWKkPu5wdEJKuWtSSUQbVl7KzDLxc
iiAWTtyGJwI2VNB0XjbEEJqTdZkhJrT/AJYK+Jg18yjJg+UMiSDM/d1m9hqKSJqHCxdQsu69ntTr
IEq+PDh3mtVq4Ie2KsfolcM4ULC1YghiwdRQFsBmyTiLOwBc9U2Yh3uGusqkcAQPq/hasJRsqZb2
RTMHOCXsiUfpOZMvIO3kfmVSDkH2t1Uw23OAGROCKIimAgmAlD2txDcvv9oNwEPv24+ieh6etK0F
6PLVyxiHenbKuYa1hui3GwZzUn39jRp1oteUq+jXKhiZhMVVCwUAEoZdvU5u0g3jLDaMkOkIKMYq
VwxFS/PFJ7CsvsQTbeYgA9Pt2DcPs/x4zOkLqu7OC5AIEwxJKYa6SI7TMQ4IMpNaURISqqPcMnA+
7/sbavcNhDmR+k/WjzF6fJt19r7Sb/Ppwk5l+13+j2+O4bb/AG/18N9uMvOPUN0vovq+0XYf7nx8
uMPal9n2De39T2Te1/d6+192/CMNARni4/QbrF2Y1PPJ5E8SpzD/ALo3u6GL19/u+A8YjGOn5FT8
vdt08/d8tuM+yv7if4f9eE6nXfbr7I+XX48V2h0HPJ5Ex2w8xiDsTszD7wKYoj06e7f5/wAeOccE
SEDtALuPl5bj16fP+XT3cc4HawCQAHMmy4fnmpPD2gbblTDm+rv05vs69fu4KTEua6fUcGah8RW0
lkMXLaGPDQZouHh5ZtHT1NuUHbF17CZawwxEVHMYAtSeA+sJj7CUNw32GdbtA5tykDsfq7iH37b/
AG+7/DgnNHNWhLll5vDTEDC2TvmNcvvIBhYSKOa+eehcZ2qxRTh22QEXAHbJV1Jx7XtFRAFt+z9r
j21xERF4vAhoTFEcTCyUhLTk2rje1kIyyLsAwkpvNP39N9hOfr9osodMqZU1A5iEAQ9sgeZiBuO4
fMv48aYFzKibql7X672i+x5fqAEevn+zvtw5bAg4F49dgDchnTgVwTRMUUUm3+4bGL7Jh/4S7j8P
m3xAUxACpkEfh0ER+HkG+/8AW/x8/FhKQTq57v2O+nfZmEoLAdTSFA+Sfz47rEdo+y/WMEajMZZa
vLSzyFbpz6bcy8VU4uJlp+TaPKfKQaiSbSwWGuxS23jzpMwFmzbGIoUepTBwZtD10YvqiSdGWjcp
tMfVHMrvLdCdQLatxVscp2CVCTkKTY0Gt2XixpL2REOzRbzssuq7EJIsGa0bR3FcGK1qfEZGpb7K
ddk7XjtnY2cjb63BySMKtLRTX/bGhXzk5e6i6/YIJi8+3QB4t5yBg/DTHU5rOnaxWsV02uY3ouEb
zjSr3mHdP8Q1uFyqGNm1tnLTDQ0TOPZ5yyrdlPWINkhGTIqTRu+IFM4MHHq+iB0x7N/p73dyCDVp
DqjLMuaCTHUA5t4RdYcXaxSUl2wpD6SJbNsnejaVl5JyjR8ryecsi3eHs7fK19trecobKqnjGePI
MZqdTlLQa2AtOesckUtPVSOzMzb7GkFUylETmLvNGLdXrPF0lo3kYSHnFldNrK2ubdDvnxyRVwm5
6bu0i+mIcGcuVJNdSmT1ejJy2vxNPSRG6RIpuICQBZWrGg1aAygR5Q46Giajcadj3I8DHwQnLHMz
3mtw0pLp11osYzpnHJWFJWOYqvAFFRkmoVMwlIYAlzGqATOmLKGQ7rirFMDjOuxVRwZWLFXqbEmy
vJ5je2WGsx7QrbH7OWlZR6lDJKzFunpaxNoVmRJSJqB3hSGIArtAv6I15hovMBAgGWFR6x6tcmzZ
/tYi4EBcHaFxulSREz3c1nCX9IDjFzJ0RnG1nIpI2PZ58b2y2yysB+UIrfNhJ9WNi6w5bzRV1GtO
TlYc8MR5KKAkRgJkQAqYiVkE10xLZzZ6pFP8owmNbdjfH1Im75AybaHzUrKY6bLqt7WEm1ta7FjK
vhQdVt8rESbtQKuk7gjj4wnIEshGp6Gsd3jVIjVYYKunp8w6+03RU7WIpu4rt3n4bKVGxqeNez02
3Mse5LXK7WY6V1OtLI87A5Rj9gMG8O3fCERibN9M1G5VoOMLng2U1J2nHUjiemtFcewzSXx5Mo1p
jWXUGeJFohEqvGyEg6fLLlStiUGitYTNSThBV04kH/6gQHh3y7pBYsCKMMjrproZWpdYdwQP5OKh
mo1lpvHl4aeva4cMts4SedZbHmUHc1FvqpG1aCTt8RIR1ip9Rx3F4ur1cyOnIHQbzgv38E0sy8+E
VMzyhlEokGZjHKnwOkFqLh6xX8qTMalf2+Qcjw9+gYirx7+LJhusxl5n0z2qQaVqRcSziZLH1CMl
oGEYShGwHkZEkmiUVFQMawXJuD8KV7OfpF7GSKxtTy4jDC1ixsxstJ9acU0mqZPsONn1qUSxuyjJ
dvIKrQFlNXSGLWTBEoHLMn7NMwKcSFhjT/pBtOpWUZz6lKXtWbcNMpXEuIXVXkG1EqMjctN5L1M5
EPHu4eTiVnXrMmSTokQDLelKtyTUWV5ZIqBYvFYl16TXCKjfYW0Z8GJy/VcBjPud5AWI0EQtoxyk
wb3fTy3zquidTtNgNGmRNNreu2mWtuRMhVq9OLS7kGidPqwVVc5EUY6DPtMODyEGmds9KSTERIQ4
HDYpuAKXOmVURNsAB5iIiAb+e4iPQP8Ar06hxYXiCFrUnTNXGNZmtUyel69h1a50yzK02Fd3KHkK
Dfq+rYpuv3KSZIXKOI4rkXMEWZv5kGpUJApzwJU1Siav5+kkg9VRMAKJD9U5dhIYPkbqA/j5fHz4
wOkLvF2V2XeYrmO9GIFKHvzGedmoEeFJyRmwHAN58sbTzpWzSXTxnjGWa1mDydSodkTsTmJj3aEd
JTMcVpMw0o0LISIyjVuKyaqYCQBAR7UgCHtk3lOwalWLfUXa8043q5YaBt9hm5CUol1cR1xj5hjO
qg5skJPsgiUoGyt5OSEESpPmT8FYkQVKUyHtcC7UXUewtdVlnTdKQj42y193KsnfK8QcQ6cj2kq2
HxQW5RKqTY5y7dCe0b2dh4sn1wYro0/r2tOJ6d+TfCVBm1sYDEGiKu0qVBqkPaMP48tsjIFr1Ejw
j1HEw7nnZE1Rad5nlElSz0+zMQwAxAhX32aA15g/oTT15K7LA6cyYPZvZQjE2gQHLeQH2GY+louL
qXxwONdQ2P2WN5eDjsu5Lqt3qMWysrI9Vx/JQLiyHYR7CMJGi8k0V5deWZoESkz9rGtYgyYGTUR3
xH1Nwa+jOM0tqVaeeTkZmNbMpLq4nGoxbFotXJGMSrLGBNGeI9wVbWJdVOQJI9kdIDHKcSdeDEwB
i3H6+o3WTVlsU1NFlhLS9kFvjOEyBQoHIjU77G15xgghf7JFzb1zFTl6yHGNWL6ano5wds+ZWdy6
hrCZF0U6kNae5rHTytaustymKcRT9grcxR8jVqkWGgQ1rp8dR7LeZmLm4OspTciyCpEaSU7XmrWy
tYteyBFtiHCT7LlEXod2vKy5vcIZllCvV14DzsnjSSzqLn/x/PgLMPMGrSvZK0x6fsEsKHJxE9hF
CcE1+WsTJ+WbSnzEePESxiUbGrIR3f1E00FF5KWRiIY5Ft0m5imHFqJ1LV7OlMwBXY6kytQm8M4Z
peHpKwnsTKRQuCdNgwbs5DuHhppSOdmefpQnbykqcW+zgu6ex+Jsx0/xBA6Dsm5MPh7F9nyhK6ov
UB/I2qlozMpT61bca2afhW1Buck6fWaup1osE0WOESsxK/SUSUd+spDlMMh5CqWIq36N7Al/p2M8
furfdLBkjH97t7qiQhr+jJsLd41HTjK/C/GfFu0Tq6kaMAVcaqSKnGRjRoIvG4qx7NexDC/bYbvT
FKQBrk+tHLO5YsC7wyAZ0B//AF9D4mwmZq1IVnKuU6VkWOo85Uy1au4vibDFktDR3J2X8lbKMims
sV6jGxYRi71CAanfquIuUEpTpmUEAOURdb7VbXVNYTTVS1x7Ow0clkdvk9fH6FkamM8foFTfKs0r
YEZ35Vq9fKpNpHkhhIVwomkpsocpRnvWRWMb1DS5oqNRseY6hXmUtPdFs83b4WgwcPcXN8qW3rnN
O7q2fr2mfQkx352U+vIgYNuYPcDc1is8c1GH0/Uqs4+oEDBWnEOm/K7q217H8JU7k/b2DGsMzmW1
km67IN5a3rW5qirPSQP3ki6j3iZ1VZwolMYCiFeSG9rhf8ab72iOsGBQx93RUzmHBD2REgoDbMGk
93V/PmGD2ZeK9a8XjTWjZtWRscSMghMXHI91jMeJXEWqbYMkOJadNHPLAEOV85aMhctVFgPCGIkV
ygZTlBZMTMDH+pWvU7IWd56Wx8SVo2eqna6JL09OdbR8hCQ1ltcZbotnEz60bJJ94h3UA1BB8lHi
ModRMEzKCYu5W5xTxCz1eY4w8bEuKK7i6t53pjxytVcfRFTkrhQL6rXHkdWLaxrkg3aWUnh7htHJ
P3M63XOq4RRJPmOqQpiOo9YxNkf0h2Y8Ll09YSZ1uiw2pulVmPiqLXoSAOtFWjxOsWyXoAIzVTsE
3R4n80jo+LgjuH3kmmPUOKpud6RE2iL5DS4xMFfCUkdpgFaOxluLAwwasRMSl8r/AEOX1DhLTdck
XDamcUZ5eYxfPIzBlDplIx9VIi5toNdeIx1Xy1GGeXiy+DzchY30vXXBX01JRsLFgR8qIKnAx3QW
XTtdYkEtas2Jv6BYyYlzZbpXIL+g17I0nVpusX9xKPXzObhL/EQZzvUFYqQnK3ItEYgwEjpEqShQ
IsUDFnlGv4Rxgx9Hvm6SwTj27VCfil4LI0YrE1+gReTL3AWGGgJCSvdCgW7mATK3OkqkMcLyVNal
ElE7Cm0MUwcD5nGewjhrPeuupzVFrTJpZLtYmmIlY7DWPsjwONFGWVU7AUkfVLeaPjajF+rKqcIC
lIYIx4qqJt/BOc5Sjzx4N6AEUkMGJwgSIAAAJYTJGkqEsDwkwFh2UKb3HV/L6z1tgP6QGTnVLZXM
jVWdsmJ5W4Q1tq2NYC7O6krSD1dtGVurQCl1iOeTnYpCsQLauTJORRJ+3OnMKgZMxVRmSkelwvNT
TmFX2NYZ2ecyJkm7dvCPxrTdzB5JZLRlkpkyLdBV3aU4BB/GKRU7NmRnkyRSxiMwK3OJYUR0YxhD
3G751yzXKHj2Cx5iHJEbK0KsJR6j9rnJLvdPVNAs6gvBwhI+sB2cktEMnKyEtsgrPlW9niU/RxUj
T9J6sss4rlK7TdQVTs+H8kw2M7pc6wiZm3e15H1ni7elR7nGKNj2sWI9xaTiSgxUcf6OsqPx6cUj
r6UUDjWIoLEgkETAesmwvR3mJyBIEXfVQp/28+PcKOC9U8Lp9s92yZQ6I7Uy1OxVyiqbPS1zcyEL
QYOyOV0Xco0rzSIMe422Lhmrlm1k5KQSg0+7LlCDAUVAKmw1qpSwiN4t9GrMo2zVkOoT2PHWRnc8
R1FNKrZpqIdzBGVQNGioaTXYtXMaL4j0TmWbrIcwnRUKUktPOD8cZo05ZTxzbWEHXL9H6qcV0+k5
IiqNUJW4MF7VWrtEsKrarc4Qg7jLUB7MqpLu4hGamVzHUT5oDc5QNrtPeH6ZW4r0iGAL1jKmXLLO
J8XZFlWOWTiZ+StSOHMoVnHM2jRGMjFIhHGcyM67cKWYxYeeAUleZoBiG5VokO/okYomQGJArhDN
xLaGlSbGXDuwHUJVIZAN2c+6vG0IagdXELmzT5p7wmljZKDncDxLqukvx7atNL2RKdHaR54mSiEn
CQSX/kAXkpfuP9ntvxDctqGjmuFILDGP8exmPDvRdPMr5CZSaT67ZceISC0inC2OSaqRswvQYd2v
Ko1qjNncwxiVm8OnKOinVRA1pr/RZBZU01aHqLhlnjauX/P1cyNdrLbchVhtNT87Zq51c1FHJ7eO
lbpXaMh/6fU4aKcMzf2bofLgG6fjmlZSxLkfF7it1LGmTtOzeav0tm5w5l2dWulYbyZ4Flje0qJp
zL5ayzKtj8Wx60ZwoSB2tekXSiK6Ue5OkteYF7QIxBfbnrOeyQQDhHHxkzOLVgJgmbEUf/4v9S43
WiuKzzXa/pntuBoigO281kXIVRv1qvDmzLnWXl6QylImGRj62YncmzRwjOuzPTEmgIUqapjjsU+w
rCY4hugCXL8SmL08veHQP8Pw4s30vUmpXrRT6QOQmKVj+YsmLobT7ZKZblKTSwuFabSduyHFT6bS
7eBjcXPizeCaHT5JsQcEUTOXmKcgjWO4IVQxUTCCXMHsgmIbm+zYdx+Qh8fxy44vK4gWs4yCAATw
yAlycpvwYkHabPEppTab1Ibia7pztO18zj66YWwlh4sNMtj4WcZDOnMurvPz7J8a9P4WTaM2sFMv
5GBpLOCdRMakX1OZSBJFV01IHOZdIDwDHumBJdqvLoO5CJB+2cScY3eNmy0o1LsJkW6pRAW4gHmU
ogJfeHFoeTcx4UuuCc0XoME6fKjPZlvNcqOGseUKp0uJuunyHxvBLTF7vL6bgYmvWGXSyqo/jO6d
+cTCMwMUuM0dp3dTkqnWMRNXcpR2IOyYgG4HH/g2+t924efE3wRk3wRYy8ZYMHoZb+46cZWNBIf+
UkChm+k+Ra06b9I/fLjK1+xWigVd3MYwvVVt+nJpBEjICHwLExHfPFKfXodgxYtLBWbX3SveJN3r
haUje5F7UScocRJmLUdTcivIR/Vse2GovWeSX1+mXtlyZY7wvILOZKFUa1qLbu0yMq3WmaaSpzow
ZHEokVNQxhACG2DRiRICmO8OYjQ5O0WEgj2xE/8AeNw6CJP+Iu5d9w3+FiGqzRJXtNt7k8OR2YXN
7zRG2CkQreiuaieENa4zJ3/w44qE00mZtss6a7D6zBLDAnQ/+S+/Bw5Cv/SsUsiIkDJ0gVw/VuLn
W3G7wocknE7O4AyBy36/a2i1B6zF9RkdcYaTpUHVWN2z7M51VkmklJTR688s8GeDXrLVB+kkDlAe
zOQXhSiXmTULvuUQAcKdI4/otvqF0JOSF7CtWaCsjioBDSlLaSjeDfElCE9Zzycu7agVwommP6FK
AKHKT65igJw5h9H7WqBYcKRVUzQ6tjDJedrHgK4KnjStJnH9yrcjUDzi7NduEU3etgJaQOxMPQ5F
0jJ8xVS79yHo08kQGCdSmcrpIy9armH21fl8UA4GMlWea4F7eJ/H8xNpLNZwZ6pL1t3Fxj1oykGx
RkCPGahSmK4RE9ogvkAiIuGgRuyIwUcbBgweUp1eheVAoEBOZyeg+GfmTvbg0LL6y5dlquJqxodY
Qqsw0yK9yoypikq4stdj5iQD/WNdJ1IKEfENJgPQwNi9r7hHjS3DUNj2UfY3fVLCTaKJSLlL3Cws
7tfLVkQl4NJ+EeHVx+WfO17lWIIIZjyJRgJyUj27fYxwVT5hIaEau3jNs/feHslJJmLyYkCA8CKB
0fkWlE0m3suRIp7B2Ib8p/ZEoDuAHRqR0lUTAsvjlBjd7zaKPerTLxqF9RgsfyFbsVchj1pNzK43
lKvkZ87WnWp3bUjiJv8AEVZygd03KokUVkwNN0T0nFmkJyckzLTDnvMnlMycmxYiLmJoUVUMwNUP
TxzlnZn6iNUbPPMFRq16jO4JxTntscOLXZr5NZMyLa0bCSHUPUpi3WaPM9Wq1aThbEePhHb6YaSR
Hbgyb05RfjZZjyl6RK0ZJzXibUkyxlVKxm3Hc9HWufuySppkL1KVyPgq/DoeEyAojAs4GJiJtcgw
5HJZCWeikHOsfbhualtFaGAqvdZppfHlolcU5gNhnJzB3CIwrRxYH0OpZK5YaU6bTU0m5qh2kFYI
93CWIzeSBZyqiYO0AwBK+tTCdRpuO9BVnYr1hrTsv4ZbS7qQouFaHjy4GbR8jVFJGctriMmHRsjX
BZOxLHGWsMowjOXmMJtuvFim+G8COVpOLqiGeslTpo7FwQKGRGcrAUbsf5DxGYlwzdmrcG79LQVa
9VlTka1Qse1XDzWk0WrZge54sFfG8zVieWy0TkfARzBEk1IoJzFdhUWkXLrAvEN3DfspAqgH5FQE
dLknV5O3DVI41V1urtMf2s1/Z5QJCIvXFjhErlGl5zyBzSBkpAp0ye2c4sw5C7iIlAOH5qa0ODp7
ql/ftb+8tcniDNaWG8lRS8IlCxMlYrTBLWyuTlEJHzSrp6ySjWzhpamk/wBgV8KCxI4AFI4FDvE9
M/KRlLHeOAk/BRvl7qVK8XKQHKkStZpkY1dRu3DcXg91Hth5AMPY+39TqAdve1XsXQYTGIdJCiUF
KsJcGYILAvkGnZgQIKx+lOjhTAyw6aM2k7S3mHOFKysQEa9iCDxcvMW93Z7TPJWOwZIlH5pztvDY
SKcW9yhI1qsx+0ryVSuuo9ta/DYcZ5218MrffouVj8XxyXeG1vuFgetRMUsDJYyjK01ftyiTmYuZ
5LNku9hES9onvJsYSfTDnJuoHMXgicz6XGWGsd17ITu3OJptK6gcw4MkW6MSgPd4DGXgH6aKBJse
WZsXikoKdWH9Ese5u+VyXu63LNuqb0eimn2uagnjLJTyzzGnC8YugrpHrwCMLXpeHzChaHVCnKia
Pm1XLt0zbV5Fzd2NhFuLFAO1qYOycojy9vCiCJeGXHJbbOcXaSlpby247gbXKbt7iigirAVYVnTP
9zYVtXmrWY1d5xmc7TVOgKFNyUFX4uUiKxJyMuwUXiE1mKFkO7l000++mjX8ZGkYicDmWi1m4EFR
uchXZc9VbDI+E8L4McY/h6zF4Zcz5md0bS01NWGfdXVx43bF3cW/kka61Df6Rmc7IAOHtEHbrxJl
xxGwyNiv0aFaq8VQ6dd82qWrHMjb2FdYV8H9smM8+pcFM3R7VI1vKTikal7BpdNvNT6Q+yLIo9OC
ZsnorKZ3TUFG4qy5ZJW76ccnY4xjdFcjRDOKr0+9yI8CvNnNRc1SbsM3G9lYhBYO9t//AAYe8Bug
HNxKbpebqu+wExQLucKhCKmSVKKEtVi6lJSBqpMnIdVoZdoi21YfLwyfwO9wVgBxPGFTl4G+ZBcy
7FTxmKQeYjq8axCUjzckY3Vmm+cJt1HtVz7FfdwhLEUpvZP14K3NPpOspZGpGW6HbK3SJthmirV+
vXpZqtOpvHthp4OhhLoiVOSE7SxwIQDXkcbFgpDnTEII3MXeHdYOn/CulC7ZAw8xyjmSazZQQr/Z
GPj+mExpaZN5A+MWdRif1+9Ya7HkU/2RWaQlEhHyNwZXpBNKlIj9OuBNUIsz12GW0d4Tq5KbhXH1
XQlFsyzYZAnmWRMxIs3larlaxvPJLxsSewIMpexOncAs1TTOtAwxHOjEWEXWGyEKxEBM6MBEeQ0S
DnPCZsLJLgw1kPFiCYdgPll5tn52r1omteUr+mC2aS/UCoyNMuOTS5Tf2uYNIqWVC0kgIuGYFZmb
TIMjt2hIBqBjKRUwBO0T3EOYvG3zBqEfZgxRh/DRKJUK5F4lirCyrM1EeNydlmY6xvDSs4S0uJGY
fM5Eiq6ahVO4xRgA5DlHYSiABHXHUe3WS7ymgoKZ+2J7RPbS5AP2peo7pcnt84exy7GAdth4uEwx
imGn/RyanMq98jI19S8uUCIcsvyfUqek3cHLDVO6NIbIci1SuNbBf1iWGQLW3UeJA5ucAAR2i4qd
EZcaIqEuOpLgUBJQgTm8tZBgSzPabylSVhcMYyAGDSlv1n+MrB6pqamSUyk0a54ixPkR3jSozdHx
jYsgRJp59TYiXXfuiJtK+zkG9bniV2Vsij+M9co+RCUTN2qHaFEDDpoDU/Z61i6q4tsGIMT5SgMa
zdnsVDc5DrshNkrLy0JRD6XSXiDziEHYm7mwtnNl9WLAyfwJlW68R3kTpKJlK6t4O02fkPoGbLxk
a7V0cjTd/wAcVZtC0mBmo2DyPjkUp13OWI6CysyrUDpTVSiTQdZgXc2DpS2NTTYLP49PhdijRfT8
wUvB0rdbdZ4ebzi0yzao1lUWVedwkDi/CYrBaCmaS0ai5cXuyDE20Km3EBqUFy1UJF4Xuc56y6d7
gxIirwuDHK9i6UgAMaAuzMQpwTKfCVLqpf8AV6glroK5599gHwFqqyHpynr9J0qJpEzGZLrMzQr/
AESy1KKd0Sz1qU7VF3WbBVmTqLbq1dLZZFaosGARpNlUzxge2UI3ZLYcub2y2HKE9fKjPSc86kSQ
WD8Q4wb05OMMQ6hSpNJHJWPG8EYU01FAq8PVnEGJCHODkSlOIWPYX0I4Su2muw6ocqZTyDTce0fO
o4onI2sVit2yWNUZqFpyVWepN3LgoMpGus7WUllJHRFiScV9ZOKpsDIS6pAM2MdaKNNctgbLmpnJ
moyVSxDRtRBMDY/ew9Qmq2pZEVIKqWtK3zSTivW2carKxtiWaJNlIAAOIGKHUQAcIQooiwURSImx
UACaqLJkoDMSc0AE2ALaAjQFRBEC1EnUBqh/vy9huxJqbYaX3OTGunyMaXyIy/jCVxta5TOFFio+
xs4m1t5tvZYOnsKdfLBCtGEpELkYlsbtc0ysZYUitDCo6Czx1gjUZfNPctbJWjFiX8XfKbYMZXev
2ZmV/CXCkWRAIObqU6VCdFw87bmKmdeO5h5zFKPtCACR2LdM+kfI2f8AJWNGWoa32qnoxyv5Bnq9
SZ0Z9ku0qH8aQqNms18OZCCmkS7w1fUVqKdPur380cvasv8AR8SvgnT/AIFo3pH8U4QvlOzk9rrf
LWJaopSsvVnGkY/dWxSx9u9g7w1TkLRXck4ilEVO2YOoxjCI3lI51JeJRIZ4azQq73xKlRccgCSm
UwACAZOQATIg5tnYIiILddVRJhnh57jqbV65Hy+F6slcmVMX4ppLaAhouKJVqDT0YKryrJjLS9pf
yNpYFdrzlvXcOnLaG55CUkd2LhEnNyqpgabMsa9s25hzPhvO821pFYvuAomqRGOlKDWzVmBho7H8
7LTlUSdx/jazlUscLtscpTBypEctxAClVS3l02nPEuoXV7mmtY9dW2n4kozHO2Wrk2km9fezK8Xi
01mnbBC0pvGxkXWoxnOJQbOJrZZFnLkr7pVJtPePqnIQVtd0X4Vvy+jK4Uqw5GYY01M59LgWWrtv
9Wpu7VqWjrFUIBW21ychY2MiE0X58gQaSLeVjJkqqqCSaYGMYhRqbpfnnESJZkdkzNciEqJy6pOU
zbW7NQ5eWH6S5dolsOv7PNshnVZgHFPxnBzWTk80WeNxFVVKKS2ZDarRzwlotblnMvS2NaPlK4hI
sWjszcez5V0wEuxuHFf9S2XtTK84rdKFhR9cL6tBp2bIkTimILlSwqxTLwpg2RuL97LWaLSUQ9uR
k254UiZOqqhQ68EFfdFWm6u5kqGmHHmacivs7pahq9gLIA32gRhK8mazWKvwMdkSjyFenFgb1eLP
KyaKNacy5pC0qM3acoWpHbrAS3vTDpe0SYmyblCjoWaayJkPFOSQrCLCzRZpkkj4APJJIrqjSIaD
hFDqewdNjPz5im3AwAOwcHu13ixlpQpSoizhYAEliqGly1JlMywA6xZIURlXqOqC4hgJcPU5B/GU
uNNfnTk2GZ6BT32O5aUtkJRJp2lMr1NOYmi0+WdNfqSnqyZ+WIcOo/8A8icjExg/YHy3kup6t8oU
2r02uMkceyatCUVJja3W6mw90v2OiyS8i5BrR7JZXTlWHYsXUjH2CPMwbu0xm3zOaTEbq5Rlz3J+
lGwvi+SwDI6nKxd46Pl0L9F0Gt0JowcoVwIVlVxjJCGFsnAg5GyLywC77yADT9tjC+67jFWKMeY3
R1IaKsHOrHUIyEmsW4csU5h+Xxkhci54k8vRtgu2UrPfbW6Ane0oSEsbUsChOK2NOnIxsIpUhhU1
G5jbsOFgN6BvURIuwUGKGWSkMsYSzkF0gpdKvdJDPjFEaMjGXBcSDNPCZnKgfMV4VlxWtTOkM32r
+R5iDsslKPZm232trrxGXMiuzO+8EbZRykR+zteRYlqz/MoiNmp5ZlEwgArL18rYOfhlBqGs6mX4
/PbyPpB7q0koh4VJ1UYBOlOJ6IOnHxriWpzR0WOsB5CSWSn5DtVW5pa7qp2yyAxkTlYCclt0NY5z
lkvUtC6dZXIdSU065HyUpliFk6lO37HjLGkJbTDW2OEZauunc+8u8RAAKLCi2giZJVIDGjrBAkAR
4bvovrHhJx6QKMpFVx2tkXGFrr+Qo6CldQsbEvrzU2dRwJb7nIP1q/DKTdcZz85bawdE5WR7BIRl
RI4jjThJQj/1liJeRdUQ1HCj2dJ6qGxLASDhU9HeTkBp0tEO6RVs61ikzMVTPOTt9dXF3I+rPMOQ
L3lfLMrZo2PyDlaKSjLRcqnDxlWmyREdXoOBXZ1qTZqqWCkrzqCZoa1vq09i/WuMIYk0aWTKIcBX
jvK92xFeYu/Y9sErA2yCWkl46ZjHqLJbw540epyfeVW5nAvEpqDkJxq9MJjlOWRIBxHtS81oWlij
UsumP0g2pufI4iZ/F7jHVexhaImuwN1kKQlkfL56tNydXrNksEFDrP16+YauxlXkwew1hIysrXGb
wDPDWcQ8laRsrO82YkxxT5Vzl+2aj6HU8sU5ZZudpbXcba2MhOvnF7aSkm8ia7JQqMTKvJKaibdN
wjGqRkhIOVEoNk5gE0LztVw4KrmsgXcpSEBgklkKAkaBKhRtMgx0wdigQ4i1OW6wHWIcAa5/l7ai
b1lZXnGrWMNE4wr1DPOp2KaxZSMYwVJxJk+wInSm2UllbH1ZfNo7IbVGwLIuWrK8P58sQdVIQKmK
hBNo7TrYz7cq7b6Rbb6adqlxZM2L7H7tgyPSa2zjZNI0Wpj+jspT1UpT+uguiNaJU0IxSIBZLwUI
wFCcx+6OtN2l+T1oaXtMFvjojM12a3rJsjnm5RlldyOEbaNXxtkK1w2N8dNQNETdpiYWUZNkLZM3
GFZJz1gkpNGPOajTbF/aVzw9JyhhT0iM1ZpWkWmv44iqZbK9AU7E9Yq7zA9kf6h4KmMazQ5hOMhk
mjF3QlQUkYSLjWkCL1USvnViMd2NlrDgRFw7ytV8iBV3CCAycKitQSBV5EdZmYTzIsyiGlIH6YUD
rwT5zrxlK1adJ1XZBxxiHKmCq1EURWn5nZM2d/GxU2KsNlnI5GWjHkORlaZB0/elJFScE2dxvZoi
HjyiaCW7oxS8CgsUhnIJqLJkOnzCqQ5wKdUEyFVOIFMO5gIkcqh9gHYhynNsUwCNrt70F0asYRjN
ZTS53WU0j5GZSqGOYIsMT8vDy8GajTFy5KRLBfkorFMY5CK9IF0jrdNKW+q1uBiq/XnEvYGxVl1A
sqem+v0fKWfU8dWp5MYrnUsSaNnNChFoWYZzSM/WITIOo+sycRAJRcC+TeyGXaedg8uFuyDNJwcp
3WtQDhuqZU9H3iMCq9xcyDhYklJCT2pOCMM2ZmNLWUpMGkJKiWMyc5imjedqhVWnYABllEESiIAB
lTkTAREVCgACcQDcTJKgAe8U1A8yG2SLJqpjylFMRUDdUAMAiBRMUoGbBvuYBMYC7kAwbmAN9xAO
L4nzKh4j0WaFrfRRxJjfI+aZrN+Rb1bbFjpjbZ7JTqrZfmKlS8ZsZN/EzMpF1x20WTFwyZPIepKk
UTM6YWQFA3C/0q2OKpibXDmilUiuQ1RrMa1xLIq1mtxDaCrbOz2bBuO5eyOW0FHqsIyATlrHOu1n
cbEMlzRKyagKkSOUwAhfujUXO7bYRVKiOoYCAB1VYSw7RDuxDghjQh7ojlbukDv4etq5x6efT7en
CHYn+8L+If58ZVFBEAEPIfIQ6h9w7bDv8vw4Sc4pCBfolRENwApimEQ+OwcwiHz/AMg4wogwBxPk
epsXZjXnl+RPs5QMIpk2MUvmJeoAPu3EN9vv8xHjnHkRA4gUhgTMT9ZuIFFQfiG+3Nt8f8g45xFg
YN55b0+mkzCUEFO25ipBuPQDCUN/f06/y89uH9imVyLXMhVaVxEaVZZKWerwtaTr6IO5mSl7NHyF
ZdxzZqJFiO05KJsasagigioLlUewTKc48vEdq+0OxfaHcOheo+XwDh54ytS1LyLQbeVcyfq9cqtP
KKpm2WS8MscMudRH3gVNBJVdQweyRJNRUwgQhhD2UFRTfikRTDhfEGcu2VN27exsts9tCMMkipBF
ctbJspVu+027WSp5Lii169Q7hRnYoNRtEpP490kVNRVqSOhVFoVFwmRVI6iBliqkIomYxQKcgjGi
CBlFAMYqYF/eHYADbf3jsHT37jwb+uKboFl1EZStVBskJbKbaZhlaGUrArJqsiEkI2GI+QcACqy5
DtzpKkcEMYBSMmcqgFEhgAQDC1EQTLyJlN5CYwAA+YdBEQ36/wCA9eEr2uEiNs3JGpqWaek67m42
pASoXbaz2rgYCJTZp1oAZUmLeI5RVq8Zu00UQMyDYiZuVdFcOn64faDp8/v+RTFkNSdyuFUkFmls
mb7letRydWZkimJpq8VeSKWvRKjdkQokka+pF1magY57ZUUWUezjY46apauUkqAuNwFNbtXP6r4J
dQ/h0+37Q6fG4HHWaMeV42hjMORMsI2u1Y1o+YMfZLhG9ie2rJMDGXgMmQmMTMSyEi0Os+hIm7xg
CmL0FKbWI88XAFcuUzVkHei7tC2ezRe0oBYuFkmeGTE9xIbOw70QkdeEhYkRieVCaffvFq7snKZm
ol3cur24nIe6HiWzQZJu9ZHevIh/ALVQG0FIx0q5hCxbmCbuMfMVWomQjoVBeukMRBJR8V745wzq
3y/itpA43rdyn8TWu2LeG15CZhG1UnLtBsRdPJGKiZubbSUiqzYgMY6M0BYzdYOwW5DgJeCQ1U5O
w5knHWnzEVIf4sr9nq0vYoyWmagEyfGNWq9oetW8OlK3J8Kl1Seuhav7pc0kISwnaycy1iWQIquk
iKDZhC+mwtkqzT7fJ0a6lsNUjIMnh2WbO7FIUqVyPaY8KCV1WIN92MgCEjHWGxziZi16M8deR8er
PCzHkHh5F2u0O/x4YjoIjAOdoQUlgZAVGtGnYcIld1BJYPQAagVbfpbVSU9q7rVCRyjJWrIcLTZy
YZVtG2ubkMW6tj7F7xGPh4+OM4kkbFdY2gvoaLZeKSTeXRqryGctoRRws0VIRmZEyHqEdV2iyWUL
fa5CDnFjZCpUZZ7KeQBORk1kRPemdSl5N29YSlqO5bTkRYZOCC0SjBwg9Zyi6CqapjbZZLwdd9OO
HYbJcpjV48o2Pc+QOQvEYop8vHyE7tl1vWKJKrvm7wr1y4eTDyop2fw5SKUSiUJpZzyoNnBibrP+
W9PWU8SZfuiD/FqV8lqJpwi8RM4Fj4Blw1rrcbTKvl9jaSNVVkH0WlX4+5LxvenjMgVVSIZAASSy
JjdFuyV3fbQr+8QFtmVhgxSHkcW8DSrUseAEANgEg1dGsGMmhrAtWWYuvyqGUJXNGVK/Xnkexlnh
D2261SYqrdaAWdt5iQatXLFxUIiJmRc21u3bxdHiFyidN02UWIlqULq4nMxSszRpu8OMuY7asfFr
5BXCEQf1JFRi2oDEPyoKTRoqObSEk9Z0auxq8uiEiDttVGJFoNdJyY9KblrG8bmjSpmHJ+dMfXid
b4FuuKM1PJmfkbnYm9pnKblKp1kL84kO8jYYxvHz1eh3Eu4lHKMG6bpNFFElhKmMA2fJtcqliqFX
w/ZcBspPIFCax2oeOdsmaemZ/O1ax2aSxypKICkEYwWiKsjWZU5a3FLnkrO3STAFHIlAVxcYJjhR
v4CGSO3LFJ2mAzy18LN4kbMw9kltXMmb01Fh8rmHdVb3JuRcX1ev3BDJ54eYWyTW0pSDg5ucr7iM
8am2Mi/fzaasvFy8N+lkjs5OaQcRv58Qxmo9rwGcoLjtlOhfZMYqP/3DFPyGBP8AfED+wYC7iBw5
dgERDi76v6j8SWz0rNfzk+v9HiMdt0RY2TILpstC09y8iNN35LbBNJmcLoLyUbJ2APGYZAsMdF6l
9O2FQvtcU7ZSNDhdLgeGfJykIpbJ48XJgBECyrBGU3bJt0ijypFWD9V2e/aB9Tm8+EukYAVdoARf
kxhAptCkYnarSEpOHNhQERf7EMiTOTubU8O+jWYrZyCY7FMAj7thARH4bdfw2/7E1lWDz+5r1Myd
mt9Yn7O+QcZMU+fuFjZTVlma41Izg41+mxdTDu3to5Ov1busM8tjFm2XIkcGyhwTMAC61WKksksI
Iqg16KJlMUxlNvgUBER/Af4jxYJmqUotv08aTrVHXSizFrpWKXVCyDSWNiFveY11X8pXNVlHLRLm
OGRZxq1cdtSIyjh0midBygoRQyaqYmUukGDEud4WSoLgGSQosodUDgwaj+ctCIcGVBTgAW+oswsb
2fV3Y56svcaymbpmyZGiZHCdXmYKQsYPLbV0GrJ/I4trc6PaMJasRjGPg3tmi1FXTaMaRx3Mg+QR
SE4bel4p1VpX+7YUpdWvrW8TkS6HIFRhpZu3JLV+OK1l1n1rcjIxcJPVwrklbmouRlZ55Hqs5uHe
IrGQkmSi1hWmHUHjqu6p9NWaEM20KGw9DyTmgBirJEy+r5tPFZeU7sZSOjoiVlHEY4rEi+/2S+xS
zuwXZ3+kpqBRtG8bxsNI+csdwOufVdK3rJ2NUaFbcU6gMYVq4Xmyc1BUrzu2sn9Eq9edTLhid9AK
xkfBoR0CxdKtnUBHGctXqjRIVC6QuN3h/wAu8hfVBLrqTkDqAJzzFg40/wBhPid1ZczfO1cdIxrq
mtL2+6e6REXKXXq0gtaMh4sZvysI1hMVR9H0dV5YO8yXhUpJwczZzRcWUjmXWlWZypIApzlAdzWa
vquydR5vG9cico27GWGph3YbLRSlcv6RR7I7bPXsrIEgnb1NpF2RdnGyLwWsazXtotmD1cYrsmq5
yEPpKyo1g19a6dhu+OIa0XHD4r1bIVsnyNXsxkquZTi3UKjjydPY0ZN0vK1w81LRKKaTh+zdMopa
TmzAKZhz4Tzq/hdH2o+uJ5DrFOyE6zlj7JddlnNu8By1cXr2CtMLe5StyDWcGUcPFir1wqDtVgvB
qeKvgdDYxUEDWg3O4xLuy48ZK5Seb9UEuS4Z9HNKTtdZjDsISqQNTu01eVfrYelYbVXlTEyVnlG2
ULzhDED5epR0vKKTEvRqOLIGAuI6EaKLJC1bMglYsbASDj3YR4SLAXoJd8b9olt1d1LWfGdTyvfo
u/zOJoxnFY/pFrsyp3lYaxMEp4IwqtWiH0g1Wa1lqj+gorvUYarKPw7ihImc/RcGx+X1kX0WkFQ4
u8U2qXGI1QWVi5rNcuKUJkKx4kslWtzmaXmohtOrPzVmRuBWfi7VVoJ5iMioZWIhTJmbCZz6pcxV
i2+jr0XwcTa6Ca1QURNUO7VWrW6IkLulARjojuvIzcBH2VZ2yhE2pyHkSvWabtKbVI3UhSrmKTiv
sMF/+JHaYnHQYQQqsxRLChG4kcFRpf6aFl7yvl3fVqnWQKZBrWqJpB07ULk+KvqMTZDwDqmZPsSh
wGVMMbGS9UfQcis/kH0Y3kImBbSlUcPU+zlY46b6MM4bGKqO8lmmsCkWenZllWuZ65dcxgjJU29k
lZMLRkF9c2aUigutKQDhd/Lz05HroPlYORbIPHLNZJyVA6KhDiUmvTIUBZsGaK2FNsVGl2bLS3hq
IvlQpVvavnrW91Or+FhE32Ab2Vw7jJJJmPg5ljtm0kR3+aGnAVAE+HvqWz0drqc0q29nk5jWccso
/TbfLOniS3sJqIpFnb1CHg75PGj2k1aGEbe4rkXTPIv4mRnGhiOCLO0xK+CylhXa5Lb/AFeEtnEo
oFIAJBJYzLgFmmOsxvD2i/6EOW8/Lu5c0sCOZGmruiRtSHOaOS4aArbx8yoyNxfJS9Yqc0Loy0g0
q7BOQkqvWbC5mCHedwjmse9PymOCPQRBU1rGtO+5Ps8O2rWV7Rl6do42S9xSsezdWqVxnMNaxNLv
r81nmCKrinlO+ZCaRnUHDgve2oi62cpc9gutbINXmdP8nFVCzUSNnDa6bxecaROMrlFKv7PRLLE3
l8zzVMh6zST6HnJB7KFbmelk4RvGL2UqI1ZNSKApHrfsg5QouoHFuVahdMA2e05o0cY9xDkeUy3l
CPm6y7tLjGFTd5OiLZIwFmk5dO0oSFcSaxUx2UmwM6Du5N1QEvExrgqJeQIV/Sss4csGGGpFJqnQ
sSQDldEbBDcXdG0dsJKgGcOZT3d9aC1SuRLnqmx05Xr+T5i+wriw1+FZPYKxy7GWj5Kt1RVaMqUc
avqysrBtImrNm66saYY8I+DSRWPWoR4VI4l84euOp6cyNLW/CcnkGVywzgnT2VslSI1GyRFdcAzr
DoDTj5+mvWGz91IxzNFSNdqJrOn7JsQxlXSBFLiqVhzRHX7hW3dgiMSkyVdtHt8ez2HkLTUbfR6v
qBjLRQ2kM5r0/fXd+q8RcZKPTt7uPaTaco3dte+OGzdRJFYxYaY43xJac8OhRotSpFBpWnOo5Jvm
n/EmY6uCmesgQLuLh4ym2FdqXHeL4F0afk4+w3yhVd44jWTVk4d1QzxN9YTsL7CNEvOyXfUIhhht
MQBeQAnIlyBmDk72ptCT/KRrJz8J+w5Mq/aAfV7H3q9U/HMdkRhkEFvXfIlSgohgM2D2qzcg1Lc7
NCqJHi2yMU5ko1s0kkBRbprv2SQLAo7QKp6Qm9WtAWy/kkiWRYdzJzkxj/ONwlIVhKvXU9PSLmXn
6ZkW0zyT113ySdwTSTlKq6kpKMLLqplWWBcxA4sexvKLvb7qPqmaYOo3TJV9f4vz2yotQyvH1Lt6
PDtXSzfA1fybBulI+JmcfTUzVXkLQXzwrNp6nOjtPEfVuH7yREDf8b2u2ZzpNdqdCuci2xtpeHJ9
Ut6dYlWdgyNTDQFeyXMJzjuTRaW68puJWTknOTISYcS8ggzduFZcxG6pyXX0apSQf4my2dnQwYpY
VfEQXEm6pmDY0OIUf0UKoJlQ03Eacd7zqRxrYfSBSlPrFoxUhnx9Q6zJT0XRLTWmhVo6oTKx1E7T
G4vsgR6q9HI3USVTkEKGEGdsdM5HBEzENsLlgyBlAkHN0SZl7G2glrjIzlrrzgG/cJK+pSc8K7+w
SLQhXUzYYkAEW0laFHz1IAEfDg2Ha7SuqMbC5k9IMZRsfZS0r461u2Zixm0crSVWyZR4exyc9DpX
Zu0hrFCRk9VK3BCL1R4VZSLeyHUywn4FfGrbGlAyDqpreSJRTIeiaj32/UtmwfPl7PIWi0O7FMQG
O7pheLPJFMxyeaplmH81bVGsdApUqfk2y1gKM8yrtqyrzdI8Vtnfkk6kigILOwYsZCoLs7F2ELCa
QETI945lOsvznRwtxjIalV8Y5YjMRxOQn+K37OLcZudUqsJPK8qzjHsnLQAX2eboLzPhMUtPOiqL
uJOSboHIoU5wEpgAd1UxBcTCcoGT/VlEQAxuv7IeZtuvlv8AjxdN6KVN0+iNbUUs77pUprTDb4g6
stLItGHrI8JzwcV2bmbTR70JPbbud+1UJuZPmL502ORAztwJSpGBH6olMAgP2CHn5+7p7uM6+wjC
h3ZcOMpRvBDgsyewJEaMQz00sSGoJvH8pJcBxPNi0nFlalgsY14lPCT3raE2rYQjQ7qLXxd8xPGm
dd4D877v3VNRTuHNt2RDn5eQphBpFbqFEgHFJQR/2cCmA3bb8m3ZBuIqb9onty779oT94u/00420
xaZ77o1xjla7YvodWZ5B0jZanLLfosrGqhBZTxLZ63WaNJNJcHYvoqXuzmZfNHENEJrvLK5buG04
g2WRUIEN5L0W4hiNGN7fxhqlkTLFHxthrJ1NyPTIquQ0FbWlrGeDJzaONESDuZyH6neFxwzPrCg0
GE72z8RBsDhLmYi9Fx0ER03pF5iOAERCEjtBJDh6NPRLGhFiIvaEOzHiZe6dPPdaqeZvWmd7ESRY
PTZYIGYdNTJw8uvnqyTKUdIEMQh5Z1AydaRiphQh1EymYTS7YwGUIAk3MXdn5P1AZXy7dmWRslWp
5Zr638PVb2hywiYqZTaMC88er4lXFmDQHsIQAO0KBudMntFAoDvxeDrS024PomHNUljxHivHYUik
sdJ8Vh/IcbFll3UlVshMLEpaJRG4tHC5bTI+Lw7GPcmfchiP3CDRQxXCqSZtVr1wTpiolS1Hw+Nt
PL+NiKSyw3IYizZXndJp1URPYo0CLso2yK21SbzUvZ1N05FCNgnKkcbooUghtx0RERTYV7Ehpoo7
IVMnUKBGoBrSwoEQEzJNBMV7IEqbsu61Mtg1PZnuooDO3aVcqNriTIzBdmyrUEvFXpfxDt7pF+DR
rA0dfDCgw8Utlb7lM2rwOD9b5KXCMrPfpgyLqt1rWOrEh85ZG1FusWZXdM5R3XLNPWKtU+/wEWMe
rNx9ai1UGkIaJN4vFTDs0e0VjyyUnHmfwlhUetu1CFJdqVcFRVSeAQN1UiqEIdYPiyAB3VDoH6sD
fdxef6b99ML6oYGqoN5yAp8hSMeSMQwsdmfSlBTnl41lAryMRDLOncBWG1fZMIOHnWUE1XKshHGm
3ZSppCqUEJUe8ECPGUQCCJOygUtWhLkvLN50b2SDG2WGofEKuwNO5vHhar6yX/TyeHcK47wdbqbc
002zutXBXOc7a0IF2WRA5pzwt3WIhWX2TEDi0JJKbFEDCUAHcdE/zVcbo1r9Quc0VpRIm2pWY0VV
qVTquyYT01JsPFp1hB1BvUG0jYnHq+QRWnHD5obmPvNju89ZbWdYWmrDuPoSguY2nlinWOdUpsY5
Wm2dXJQa7bMeSXqj4BPmQZ3WccuKxNerFp8IyDMy7NzI/nncwWBFYSQ3rI0z0jEmOb3KVjHB65NV
vWFmOqP5JqWWQOljGSiWD7FzYjaVlJQwQ0q9qltb16dEAZSzhN8jHOHCjdwUmjHRfIYHs8XCCfdO
XVDjyLs1NWsvdjBUTjSU8Z1b6zppaP8A0geoe2ZrypZrrX6pl/G+FMszjfJtTqGQcfVrGhJawN2U
TEzNmaIVhVzE39CPQRYmQskm7mZkhbW7MLcO+uhtIpZNz3mfJ1fxZXskzsg/ruMYJxEYnjggYers
YWtOVItBZOnvIyKjEjoEWgWiJzrHUTIqommYQMYoDZPrfdzimhP0S05Y2ck9XaUDN6TxvPnlHSK6
EXZsWNIZs9I9eNXzw8hHIrO2CZxMd20RUXblOkmY4Pn0wMaW6QulvJmP6LQYvG8fpzxzGr2ugIQ8
WxCdnST8k9oUUROd8OWiKw6gXCJaxX41+FZVsq5LE5QNYoIFs+Ii8I2yYd5iK2OIAskAFBSljMEE
uWAHumZZ7ShKYfZhAd+reXlV7VT2XUZlDJbyxt8pXKx3SFyBeK5kXIEMLhnHOLnPxaTdk2fJGHlO
xBWMm3saioUAA6qKzcphOmcoSfcpfFtHhIexU3T1nTDdufljpTG2Q57Ktwad2VI4byMFL1tN1TIR
SaXGPdtH6CsRLR/aM3TZ0mYUF0lDz1e0NAsfjvQm5xfLys3b2NmfPdScdcagxULNRBLzBlL+UuJG
wSkO2B5UmNgblrNcYzkFNVqVloyfcsZSXie0s6zGtiWAwx6QZPNMTlWYu5FoVatu9QsgxumMrHbJ
ayWeexYTSI6Ss9gm4+MQoLMW05LxSbCZQZKV1dZoVF2yFfQTDHsYvAin2wkJERglfaCXA00LNhLi
U7dFC0TQ6XAds2IfdP7nO3zzXrUbk3JMQ8hbzZAmYdefk7a5Zrxdfjm6VgniLKy8sxCtxrAkE/ta
bdc+QBr/AHBS1kQWPYAlSpnEJDy/mrVzOo3tTNz/ACo1JmaZpT+9lv1XfwLa9y+PYuWZUeQdGeMG
ZJVxX4+ZeumsXDCopJtW666SaiSRzFsT1OaQMO41p2WpnDFFJe8lWuTxfE5BxWtaW9jkNAbm4NUn
jNOckIaddFuspbrU2bw6VocFlYajIQSLebVQNOJlWZWpJhnHFuObri0qWcswLYizHVrRrPzbldOT
mahN39KdI0xdWsTSt1mpi4p1GEBpZHcjaYtmaTvcwrXpqwN28I3q5pHk3XGQb3HUDiaYALYkuQFM
TQEMwJwkEggiu2giqNHrXqVPjPR62AS2WPVLXa1jaPtNZyVTKthJds4xi/DGi9CGgyL2XF60ewtt
NWoaVjpF1J/nbcslJlVXnvoEgO69jhPJ6zdS1gC1EfZdsjE10lYuzX15AJtKpYr/AGKEdLJ1iWu9
ipIQUndk45w2cS4L2x6qRNo3WdcwIpKKFtd1LYetGqLGmrfPTmK1B4NyzXs9UWvL6f77kB7aKbk+
y5MeEaRlIx/HSy1WhX1jYvBCTiJCLWsDFVvsu2IZL2uA9CsYa0hOkcG5breJsp53t2SaY8yjc3Kq
V2xngPGJJeuPH1LhlpNg1Yp5mWew0g/ypdIpg5ianT3kJVomes8oxk0+B7GJEvkYG+LCYoSFHqnZ
kpSrCCJFnTXQG0Q4sJXuMzUcOeoM/Ce+w2XvOeprIFbst1uzyzyteyL4A1ul+c49jGrTIoV0D1mD
hrpk6Kr7KQyEu0cpnZuYGZuM9DSblNRv3o6hDEDqZ1j6mbTHz0BL5bsSkTOYtjsGOoOOJBxcKTFs
YMwWFrDesModlAMWsUMtIBGrBHEmd2rkETj2KoE+iPOiFVRyNrFetW+TVtPbLRzk+xVxu6mGK2i4
MZOsMwENp2jsUwTWwmrrbIJctL5AfVKKZ1iMawL0rFOsu450KYABbzR9gt/gSx6jSYmstWy1H6UJ
C2E0XNLIyj30AczeYipLVg4CQu5L2bGjZiKdrZYyViizo2KMf2EgDB3CGVXrEu0RaEw0x4mEhKnI
ALqqlpNhZyZA4hRxayI8EllwgC9Q+WGc/r9mtX4zh8JjRwuKWj3PKsYWNRWSv6WX7oeqnmHDQGSF
jTly0wYo0Us9/NEkwdd3VdfQEEyvscNWnZP1MV3CV/xrS/XF1gCySozOQUo6lozdRVftGcDIvFpa
dSgZzwfwSPYQz5MzufR7sykGDkwkQdoKKWlaTEM1sMX6t6pnFPPqd0//AE+8zy1UlsnW+Zs+GG+K
30KC9SjaZV15F0yibM6R6UyZcWDaDnAFq6he97J8E2gbAqd60NeoieZm9Ge4FxTO39tiRtXmGiZ5
TIiYyJJaxn+pxJ1KsEJqyPKWvFR+VU7HCqubUkzrwSpX5XDTmevN3hpiBSYqgyUyQAUgsTNt6AJO
2J5AG1BEhO81CVQ2aTxz+zW+eSVz1fH9ErOLZaxD+T2qSS81W64nFQCDKDdPTsE5GVKt4aWQcOpo
9bSI9U8WEyhg2OImDbg1NI2u2BxPOtWWYD3qyYygMf5Yq1WrlXgaXa5iIk8mVmSqztNi7u9mi3sB
HCjPO5dQIaVXYnfg6A8EI+IBZa07+u3Vu92VhXCCsG6ttpXgyxZSMkE4NaSmTxCKR3IgmZMhFUjp
iQRIYipDlESnKIsMqqrcSmK4IKhlziUgKF5jAQwkPyhvzCBDhyHENwKbcBEB6cZF26WXB9oTHUVC
8ODN8ILU1DNUa52JfYCVAbMtSQFCWY67nOY0FitkNUeXmONLLhGByJYEMQWGaWnXtMWhoQrOYkCq
so2PkXPeDSkk0fN2rCDVETypTkSjjqDsRERCMovUFmKj0qUxzE3F2fH8tbUMguqLPRlZt9QVvTNv
GNk7SEDdoyeiBt4xMC2YFtoMRlROciXiXMcoDDSj10oruY6YB8RMUA8/d12+3f7x+PmUVB60TTbl
HtSEUVOZUBASpok7RU5tw9kiSf0ihh2AhA5zCBevBo19hRliJtilQoAAQOzR+ZyZ5Cg3OLCA/SSv
ieGnfxk+dpkaao84kkrs/f5Hss25yEeIVvYWUIW6xtn9W5IVK68mYe2M5OPkHsWT24EGDNkpUyhz
Mgeh149SepHNE9kuv5hmMn3GQyjVzxKtcuQzCJJyuerW/gzesrCiDGKryHMfkq0bFs40OZTaO6vP
WYcEmavbB9OTqUx/rB1IQPpDAG/UhOvMYOhf2h324cCSaQcpBAATAAFE3QF1QHyFMo+0oA+QCXmD
4deEUR7ys/8AFoE5dbg3i0uGc7SUoPuDu/2+nnYjS6nsylsR7d+UKbTnfVucpQKxqMNHR41GwGlj
WimPokhSVqap1rNYpA0jCjXlIidHxwbcxlhfxg8bGO1KZPYvMeO2ltVj/wAkc76z40iIiMgI6pUS
wd4QdetVVocDGsqhDWDxZBB94u0hHVu5YaJVGQ5eyHgYez6IB/ZGESFP+wJi9TFKbqUTB7ygIiHy
3427BEnZJuBEAKryAkcTABVBP9QCG8j8/wCwBd+b3b8Me2XnZ4toSuhTqA0nMyzvQ1Opdcj9XZ7O
Tu8/ly7vMjI2JeIzJke45fbZRXtsg6ya4ucZcfXpsZvEzprqxcd5jLUEtCCxeDbm0tu+G2g38VIX
6TxLYN+L8cJap22K8fW+byLLnbW6+lXstkXkIxpXnmRF3kMMku7sUsyJFnuL+TciKLYLKdZRwrum
kBzjtx808O7LHiDlA5UHDNZuoQUhKBhVL9YgAA784e8odS7dQDy4tQ0va9YTHMUtVMwVqZyBWxep
oNowpo6WVbMVI7s5BNu2skpIw2yBw5GAEaDzG9lMRHYOC9EdIIg33aRVlpdUiXVIIrTCTLIGYNlr
1dzE7JJYESEqAfcWEjULmFxkS92qcjDyJo+anHM3FQp3BXTBkQxecJBsyK6PHC5EntAchNxL7W+3
XiNiaoc9VtjXWsPkG3QydEjpdjQJNgeNLcaMysZFi2WNpt3eFG1UlnNkcOomWLVbOkSajFp0JYJN
KTbjZ7nsj6b8fajMJzuYMYU+Ip9nnXZZBGOYuETtnDhSY8OIxbkSEe6tTtPpilIHKZL6QNye1xRF
kCrTNcmJCDsLJGJfxrjsjlOfkTUT5e05gBTl3IJPb5g6cvtb7deL9IrvAjR4sOMvZRzNQydiGaoA
yInrO0XUJMDCtISvTgAOMpaZDisidWGfarE1uCqWXcmViHqtiPc61FVayOK8zgrccOV/a0EI2SYR
81ZHRehZ20tnEodLYAfiy/1Z4x1TVfmKnZEf5WgLOWKyRLOZZ8/vbCp0E9qBxYop9BWWRjZZ/Wmy
9VWskHIzzS3x1fdxpraMmYk2SWFZ0FngZ4QEuoCiIdkBd+cu3MbflLvv9YfcHmPuAfMdZ2oB2qxg
SAB/sxMXmEfkXzHp1Dpxlxr7eCMK1mIHY4uKQ/4nZlCEoyB0yamnDjYyoDPmRYesZFjoCx9wqmQm
7B1kCkkgairQ7U8jj8zRew4yBmOOHANFP0tFmZRmx5T9SIqbcRrL6jsxScu4m1r/AGdrMuKQbG4P
Yp2zr6jKhNU48qVErIwgx8HSaackChEkgq03jIg8WaR2jxSn3vrY0ypwydNSe+NIDKunJmjaGQYr
nkm7dr0SWdvSB3eLSP8AsKMgsCZumxh68RS5OcTcwGES/wC7Adzf8oDvt5jxqe0xNkEJiYQJuJ1C
eMpctbNhwiokxptOe4JzNGl+LP8Aq1+s1HsUfaKfMTVXsUI7byEXM1t+9hZdF+LeaaisV40mVlQF
CJVSYvTAP6SMoRMwnE5SjL9n1eZ5t8fKw1hvjqVhLHZG1ttNfSjK9D1y6WxidY0bPZKhGEIlFZNl
GykKwlhnLszsCxJRwgIsQUVT5hYWciQAIRUplB6gYpgH7eoDsPv/AK24xiuIBuOwB8READ8duM1F
8vCIceHtCRHIJJ91moKEy7rMS2W0CQ+mVB6czcnZPVZnewJWqLnskT8vA3GKb1+11uR7lKUeTh4c
/NXGyVGWBCpxziJUDxWvSETWEvVKT6w5olTcONxN6zs4TUv6zzcvVJa3kqzSkpXOSxjjRxcTVqMg
fVJvCJWxSujZGSTKpf6qxz/xcpTV39WcZb2uBD7wYoLiRQDe/wBkQN8fgI/ZwjUXMC4lMbtCdPaK
ICH/ADBuHv8Aj/jwVXSN6W2KISwYP3fVp/idFwAuqiKUA5zNirpurzNVGqVbo1dtKKtXp0u6sVGh
5yAq1nJRLC/OJpOx0Re4xVnDHllcn/S3jdTFCUPKf+eFTygW85BtuRrNMXS7WGx2+2S6gryNnts3
J2KyvznbxjUAWnJOSfyhhj4mBasWO70djHTSTDmMUBYZnG/1RBP47jy/z/rz+7Fzm+P8A/y4XiXi
NGlFiFafhNMueZiRDCKEmte70soAQEyBwEBIIdCAO4/8vn/nv14xrFMYElFATA4IbCCIgYQHp0EC
77D8hDfp5BvxjFcqe/KG/ZfU2AB3+z4/dv8Adxh5z7b8/T48xdvx34SWceTTy7vSx9odBzyeRP0H
QAKO/OAdT7bh9m/l/HjnHYiADsIgA/Aeg/gPHOItOzGp55PImX6gg3W5TiBDb+Rtij+A7D8xENh4
wpAr2xh3S2U/VDzF2S9/tbD7O3z/AIhxhWKodTlTHmN/vFehfL94dg/x/jx0Qpg33MBeu3Uduu3l
7W3X5D93Xj1ChjImUkkBwZ5P4tzmvBRvq4puB+1pyy9QK3Tq5iqRgn0pLvrfi+tZHlZCccN1UEXs
sq6RcNa4k1HlZtCLMXqRxfewVRm6IOxm6oEHJZcwb7qAHZB7ACIBzdPMAEdh8/d/14n+1ZTcXDF+
PKSvUYg8jiyGf1htfEJKcUmHMRI2OTsHhr8pJIY4ijCWn3KLBBSLA/hJDqplFEpjBAChDl+uBD/Y
IGEf6+Pl/Hil+XdxeGUkgMBvJASB4g8XtEBVeqGEwPDRqz5qqReqFETHNzk3+oA7j0+Xn8Pt9/B1
1jTdX7XpTb50ib2EjbSZpicO2CjrxLhpXasxtJxTgJd/OiUs5YVJ0/sSCkakcI83svhsBvMBEQHf
yHzH3fLg08c6kD0PTtkXT2hjyIk47JNhr9ulLcvbLQlIxFjqEimpXHMNAi/CPFRFNVI8kKKwmQIq
mZblKcoiz0Wno5EUQ4sMpEphZMiBPwcz3Taw70AsTEy2/mlazsR2oLQBK4iomRbOS0TL99iUtWLb
3VkiG0XAXlrYpiGx85nsTPGEzMTT6uQ9xSVq7+EvSNYkmbJNSUcAmCZjACmNYfH8jIPYy+flJcuX
gsI6iQeLY6vSLiXtcxNhW3cc7LLz4eEiEZ9JFt46IsSi0x9AiQzj2eCQvutK8X/HN0o83EMnthyM
0oMLku8PJ6clJewMMcvTTlXhYurSkqjXqgDpYh5eRewsar4tJlMInUUKO0O4u1AJYqzVjPNdXxtU
VHWNGMC3LVJeRfNYmySMTS/VuUmpaVZprv2TmakB9ZVVVm5DRj/6Y4pm9rh9cO4J6RC0QipDVUpQ
0m1JzPLWRgoiou4RESlKiXwgklpHPRvpWtjHvno6ZGHj8+z2NrVN5ThMaWql44pUFCpQZ7o+t81j
+v3C0N7yo7Vh65W4GoKyknCBD1Be0TLmQZvGShO8N1kyDnKaO7XA6e6bmIInIsvcMiEvMqEbGxMH
G1qr1agXZaoWItiO6mwvb+5MpVs5fSKLSrBUWdebrPXLxJoidQuyw/rcsuIyXpg+qkHd63eMvVPN
wxriwzcW5icgVKWQsDBzAz7QJyWIyBu6asV2T9AV5WGcIKhNqN1kzGfL/wBI5dZt3Ezs9jCkS13r
jrOPqhYkX8wwgopXUc3u0TYGDiqgmUbM1jQtNgloEJh8gC0m2jhbAZVRx6zkvCeh8BKUxEKJ7Adm
YPU9+bjxsRo0OaEJU7VJzajS4a7ma0Rjp/xuTTq1ze5u2S66kS1VqnV5jYqtVWiGQHaW7HJoYoYx
t6UlVYSlsiiLWcnpOFarzYd3UXBx7AbnIOmXEVHxviXOLi+ZabY1yFO2aDXrz6l1I2YGbFow7vWp
6GjIOxOKXHVy4OA7BSEkbAEkgt9E4Cxn9nhi2XUZj63UqJqklhiKd2KrY2rtHqDhxkGwL0yjpR1l
TnbhbK3jaMTi63C2LJTwky4vx2zx0uq5npSYD1huM8ylrSQFD9IRX8ftKnVq7pnoRKZA5SdZlnKF
NWVSXhl7Wjj71FaI1PxmImXNLh2LkwWdVcgz1jSeCC53xRHm4Xh3fohY2ZMQJHvu6jR6ynnvlOx2
j/AnxO71PlobDjesFUmi5romNbTO5Lg4a2MqMvamk9C10cl0N1kFJGRgoqbrRZ5OrzD+ObOW1lmG
bSeBw0gl0Y5wmnelSRho21b4Hb6c88ZJww3nVrSzoEkyZJTjiLYwq81EO4NrLqPFUI9VYzVwVV8y
AxhKGwvGoCO66QnkbL2ecb5PmqfOfkqscLIQ05Nz+Q7K5zJO3W+ZSfy84eWhiT1utTV0RoxrIycR
EtlGEKRNvGxxw3KkkblYmrLPpNTOZL1mJvVUqUlbVa2iECzmH0+hDrVWkRNARSUsDhKGeLqSMfCs
px6Q8KJxeLIKGDmVII53SMO4Ku4wQtm0nSo1GHVxUeXdY0Ba/iLjPgU+lhiSECLLchUx38gAQERH
7h8/j5+/g5pHS3W4nRjR9Ury7Tz6zXbIdjorLH6FfhQiq6Nedd9VXkbKWw965HrLd2kZeFKCzb84
JzJe3wC4mKQOcpdze4ADc34BuPu4N6u6rYJrowl9JlipLiSco5WPlWpXBhYgZo15Y0anHyEYWtSU
LKAu3dM1UlylCbEp0FU1epDlMKVxMJHt4ixFgSDJAaTSyr9LN3ip4H6CzMW02ZEhqNim8zbytw62
arGvXsY47kHMipfpuDcLdgTJb6FhUnCaVAcL/Qwb8JQZl4rum0rihw5eCQl9CUm11R0rShXsgLzu
RZu6qUKfVlqXYoFtVJGKHuMlMxxUX0yMtTVmP5xUXyZVLW5bh21lbU8ntcD6XUXI2HF0bjTIkE2s
MrRpCouce5URGOZ5Jp1RgwSZI46JYFnEm9kqNHslkT0+DmHrSPrU0qkhGvn7hQhBmSc1ZVWV1nVX
UxDVS7QsPEXeqZAnqm2s7B5YZpzV2HYOmqs6SMMybM5lfZF4ZzGyxDq7JGHn6cbMP+Ff0UmISB2y
RPqgGREtR5hg4v1G/lpyzPyv988jvs/KDoJlcl6pr1pkpeRvElcZw2QJi22p5T55rZo1jjZdJpZa
7G00X4LPLg5cuG7aNVJaTVtZddFFK1CoqUpmPifSWXL13zNXIu22NpXcOY8mchTM6wx/JTtvkYKK
t1epr6OXpKslDmYSrQltazNibKyia7ZjDundYJcEGyqicj4W1wVDG2uO/aqndPuwVa3zWWrEzx9C
2iGYS6bTI8kZ+Zm7mnUYVg8j2T15IILnGMMkkunBonMVRw2Kdm6cNUdBw3krUrY5+rXiWo2acQ5T
xVGxMC/iY+wwqF3utOtDCTtUy4cA2knMOwpj9k5M0Nu2PJpJqiQVybhdG2BSCDJkByGcPN3prmK5
CkNN4RVWKYM5fDXVvNjZn4y0qhf2WaLi3yMhAY8w/O1+qSOQI+pW6TjpiQt0jNIVeZft2bKOmWNJ
aRdc79JP3jaUsKDKwRrpWslQkGp1dvVNI0hO4Ds2pObyNWa3SYrI58URHfqzbpVe1WiPirTJIyb2
RatRjYyNlIuuoxlacuTyqLyyCWPsx6g9+h41OFs/Vuh4y1M48sR8hOAzJA1uLqjCvSzBpX46xVu2
BOtn1qar/nEsYyRgjyGZbiaHEDgIoCA8bSvaiawx0h3XTlLflCXsMtnOvZhr0kk8hz0KBYsKk+rS
kWCITo2JwtIsrKedbog2E7h4YFUynEwG4YMO4qHVhEuQ7rVqgGlCztk+os0BT9VWWQ+T05k+Wb0b
WqpaZaTqWs98g4ev5NeWJvUqyaKs6jh34I/PEKMHc2o3CKaXWUBJWcr7IY4K9IME1HzOzLNyGUDH
lbSBYsMYowvlGy3aBB7nOh1nItSqrCAl0UUq5dm/e4kfXV6UCGk4tp+c3OqlhxYMW+y9dstuT3Hh
9XbVXUbRoVxJpgVLkR9eMY5TtFvNPTikS7pLeuT0bKkNUq2i3nBnmJ2B3zQse4fQIG5nbcqf+0Jc
2x1NaqaBnHTTpQxFBflJZXvA1CPRrK9sCcW3pUg2COBYw1IY2Zm590EZIFK3Z+sUG25YcAULsgHN
xVEC4JKf0B2+s61SSGYhncks4cMHm4YyRHg9llCUzQzS58Ada77RrkTSDY8dQeTppW1M5d3iqeoc
NYATh3bGCuT6+R60tHqYesUpOSal0jgimziTTWnYevInj0FnhDGbpHUKvzTopmsDQ+Cp+3ZMxQ5r
eoWkR99a2iuJWmWgqxEPlwdChaXUDEv5CySAsv0X2VchjKi4+gABU9jiX8mau8cXag36stmmR15C
80jDtajMb2BjBNcVYym8cJoJ2Kcx8jG3abeNHb1FjJREWpX6zXjuIeVQKiJo5wnWjPO3ardNGQ8V
6IceXOrZXnyacJJZvlJq/rdQbxVxqEjIp2KZiKg+gssLzxhI2OnGN0ZtvXxl11CIT4MVDgUT367d
FJiJiXOPGLkYgeFQxlMZybN2eYYirXtChOXVctUd4/Bo1ogpugy03OP05v4fKdFjo/UzcJyj43aW
KFsVenkG0D493O1qVkTSr0+OpoA3jpsswaYfB/s1dVAeIEu2n+Vx1kvIOK8rWKOoD+gmsiS7+ZrN
rk2FxkIV8vERsbW4mPhSTh3VsAXs5VrPNFgIOIjxnHz1Xu7+MV4K19qc0+s840POsFMaiJaepWoZ
hZIGnTkHj+LoNE04V7xlaCxxjaKi8hTJo2TrEMqlEQMSUkPXUYdRODdRtdmzkIMn6p9cOnjO77Ca
7bGl2sbal52ueQ8gT1+rVCbWKy4jtWSZuVZ4t7nF5Ct3rN4RBqp1tjFP7lBVoHh02JI3tzlTGqkd
FKIO0ig1cZMxq83kJzLuM7FRDWt+omTMxrMPu+095cL8laRMo0dvh4YBNtlAM2YogMx0pjR2EnJT
MbS7SKQMm0xBOFhUiHSIrohs1VnxAVkgDcVCc0Eo1J5HePtLbY2lCmqw5LFHr0/FWB7aXsonNHQk
o5rCsIhMkc/YLkURes3p4Zy2WIdNZMhyiAHVA6rcTF1Cajsg2Or2+Wx7f8e5Lp2BIZ9X6bZ53Dic
xfq/NY1WYVudt69WrbOj1ZynW1Y+HsSoVky/q/BEdV5V09s7KzVnTG2T8x3DLdetObMXvpyj1dGK
l6VDVStS5cl+DQUJZAn0IHJMIonSJBSHm5EZmo2ZlYzyzzlGtCsflFYQ+j8Ij44pD9h2EyNS+U98
w1jIhRz24cNNGmTpV9DWX3dDdtEOUKHEWydst3ojKDqt4xljd3MMnVqVWk5vKdbmbNX5GOjI+I8Q
Z0tnWVUglG0mXtUZVQiK0IVU4FGOZ3Sbl+Gu2dscMQgLXa9PzhdK2wteev3y8jCxDljDS09QoaSO
Ry9rkWSTjQkUCIRyzIJBj3mFS7237QxLprVxvPxmTSUxjkih268f6Ojwcn16PhGltlLRiynrQl3f
WBVvd4CVVPkOVbOLUcze4ywyCrdaNtfibxI9iKzYzVjiWE1g5H1NjX8ojFKEnJ2h1aCkWVSkbLfH
KDBueNyy8rtzQTQx3M94sN0v9djZWwPn8okyieSwrS9nJMjvELoxjhXFhuxGHKSazId9C3FnJAIg
I6iXce8TN008T59wwaXdOFy1R5K/JNj61UWs2dzVrFY2aV3XsaMVPRtdhO9TLRqNdqVsTb8zYe8R
xZHcVEPpUuZP2uBqdAduuUDGAgrfWAw8oh7uu47h9vx4OrQzqVoenfVNX89ZKCxK1WIYXBvNw9Dr
UO6lJNS4wHg6DFJutP1GAbNGqfQ4A4ApPeHxBmVXQcu0DFMQ5R6AJDFMX6/Z7AJRHcef6MNh+uAF
2EenGXHF3F3uA2qyJVA3AC+A0H9J/wB+6zIRE274EksO+nPda3mLwZq31H4q0s4VPlHTx6ofkmyX
lTBuPm668RNV+nx60GFvVuk1XMfqwEE+k1gNJsYyz3RA87LAYJ1NmsAgFUhp6ZbGBEshIpNEkjsV
WqUg45SND/7eKHK8FgLR1v7EcUBKoO3KQeCHwVnlrinCeqrHiEkvDzWaq7Q6sRZpTo+yO5COqsjO
HsNfcW1e0Q7+oJLJzUGd82JD2QZMrPmUIcCgPAiqOzF7UTKAoAl5iiUwCAl/eLtzbh0+sHT59Q4t
fIsBQu0e7kjbM6HUEpIak5liHGrks7AcO7GJFwYEies/d+40zsdEjnnNNu0+T0IefxlXqC1tlGqk
/UatS4qnXnIsrGQM06q0pPFi6+3hbhG0hsomZ1PTk3HS682oRu/a2JyYC8CnIPre/h0jvz2hasqi
kVosslJ+r7kTfqwbmkVjM1hc/wDp/ZnMMdsIJ8vBKY5y/TWOjvNOFp6ZcltdpyxjK+UCNLGS60I0
ZVuLvQXNwov3sYyvnn/GIQFI6IRXNNiy2sRWXJ0s8uXpBtJtsYZYRJHWQMeWzRtW8GVXC7uiEVZU
zL0SI9nZW9VaOvyWQkFD7gJZqIsi9ykA2ArUwbbEWj2kj/WJRQHCQaYBN9xfOhYGdrFKoMXZCBDV
IGaiNPTISrJjalJ1fbksk7jHEdWiJukypvkRw7i5su4UOj25CEcmpRXDJQ6H0xCjLFMdIOcA5Njc
NKXkbRYBbyVgkLBIgmiDWLey7+Seo90MTnBBhKShjpLCKftgRFUwiT2thL14tg1da7qvdcMYlxni
CegbcMxgysU7Ua1uWNnMuWZyfWFCu22QmsndotF89tMkxAWDu6xCoyZlR7E0oJvZ4dGszXfSs3J5
TiMTzWMIvC1thcdJ0fE0tgAVMgwS0PHCWQFKUcNmtQxelHKCJAtOOrTMTUgPsFbG2AoEMBBN4wx4
Y2AUxK0zwqSASBi7aSVpbIAEJxdW/wDqRF2uyS+gJanju891qhpO03iTZnaSU1ZHyTxJqYzJzISZ
iPe7qyyEUk/JInHZsRabepQsscOycKoLkaqnOmcATS9vuk2Cracn5uSQdMoxZdpLyj94mq0iu9eC
AJVVDBIqkGUmezlC84D4olyqfnBOf6ZckekL0I5Bks+oT68RPxWTK7m6GZKTuE+9uJlI9YxQhgyP
kuatO++lrNkbZN9UpB4R2NWdTNiShFYxWVRJYwF1rahNO2YsSXmm45s1RULVsp1u54KQUq2Qy5Ci
8cTFUlo++VSctVrTFFlbCSjeAezEfDS7KpSJJeKUbubGD9oKw0XS8G7iMq/MspcIKklNQJqyLMcM
zhq1LBN7hZXSIJ/Ca9V6ZZ92dqipS62qVYxcHLWOcnouERFCEjJSadumMUkqRwo8aQbJSbMDJV4S
EZHTSRKVRUiyJiFEpyboHttnZSOYQT2ZknMRGD+jIt3LvH8TG/OPaCqdL70g/nx9HnpOpXBeL4HP
WOZeIqxrxnKg6ZrphavwlEFMlKmo2PvKeY7aIPGzWMowXQ8xBksT2pOX87cTMwJMspcxRDihiQ07
6h6zGPZqWwjlqCh4lqo/eyslSba2jGTJLqq8dP3XZtWzVL+0cqqkRJ5mOHQOEjd7yFxwmItUO8BJ
xKGEgMkuAZguWYgF33WYgLET+YAg6Jm1M6aaeVoYSWVUMIJrFIvymN2XMAKcpOTmMJN+bYvOTmHb
YOcu+3OG7nmsgW+wN4iOmLbZJxpXjIGhWEjYXkkSFdN0e5JOIFM06p4SDGM/R0eePBmArfQJiJ/Y
4+jD0oBNN+K3upbGUpEU9la8rR+l264np9BqrNOUxulGGnwzPaU3rqFhISnoZGCTiBmn9Sdv5u99
wN4qymRSMUolay8paZL7jSQicc2DFk+egZ/jbdj1pWwuUzbLLgiwRBGDmmvJbIK0oo5nWMnXe+3+
sNpWLijksEcodeeCQbiqS73WNFYLvgQkkScGRCSSQ7iZZpHEKBM7UiRFLrDFau+nLtxpam9nkK7t
3E2MXc7GK9lOzGxEjrI877Y3RXvi3by67meMpJAsv7LIynOEYboTkN04Wz+acsXSJewFpybkS4wU
is3fykRO5AnpiHkuyeqO271ODfyD+O740apKuY3xVkY50E1Fkt0yHMF2euyKoSuGcxZBpcpWbDAS
WuSMi42LgmMjHy9Sx6FQNKR+OpmGsMdV5elwMYumoSMo7VEEoZQhyy6yYlEAj/XrnLENihs7R2K2
+jCYx/fLjU3WL/AC3SezXUqzFqTjw8nRY+aau6Nhx5FMBCPt8dBvK4acVN2LFPn9kGLxd1p22K8x
V7JIKXCAXGCSpuFTNHoaFno6f7KfH/H04DutURJ5iy5Ym8YhP5GyFYU4SVSeQxJy5TMoMZKE/wDD
5GICQlnwxUunv+aSTHuSsTv7J0+uzHM5fSLlV6tJLO5NY6z0y6ckD54s4Aonk3bl27UUO/TXIUxx
UExyiUBETCAb8SU1xPk9quCrzH99gWiZjKLS9ipVhi4aGaR6He30xNSL+OQZx0eya/nDt88VRbtm
4issqRP2uLj9d2f9OMLZW+LsQ0vSrecaZWwLhqNu+TqJQatI2fHOVYaXvTG+3mhyFeg2rNre3jFj
DuHMvJKy84CEgwWO8Kk6bicUO53gkFV4iJLPiAS4IwMGJmSCZ7puSLXRs0f00mmZ3cdO6XfTIOTc
juq01op79blqZGCzdMagvbJ1xXI97FvZyWbuYyvjLjGRarJcxSx02ixdmMYQKkyEw7D07ydkWZm3
thf5AtU3b3kQeFeTslZp2VmHEBItEYYK25kVpVCSCunTXQAsWZ32Bu2S2IPaEAb2dTzj0eo6Ocu4
qwNPYcsF4qMria9Ydv7uTGby9ZaWrWa9G2iNWnZ9VlLxtvbSsZMupLGFfds4xp39Iy9fTFYRHeNb
fojlMd29m/d6eXD5z6JuEM1aIwNIaSptWqT+/HWdMhAoLq5jTAKsc7xLnuBCJNjGXKVRPdmHAWhv
9XidQSHwkmSTjrJOXWmDIgGQqspVSChMsidQ43HmbWoiDMWYTVdWjK5Vv61MUi20UpUFLnbvVgtf
A5CDDqV41l8DexIHUIQYrYyYHOQop7mKAoo/KeR6/W5SkQmQ7XCVOwNpEJ2nxFzsMLAzMLLNRhnn
isU3kF42YYuSAILsHrN6nM7CIFV2Hj6Z8v420nXbSZrGzhgnH2DHULBaU8Cs6GNapVcibtji0TMn
YVMgPiMn9e9ZqPKWZOUhjztkWjxtlwKwOZ5JtQRMPAzZWsmlV1i6AncG4z0aOq8hoUeRVxkMkW2P
qNmRzktG3yJsakXh6GgJ2bsOe1JmMi3FZu8mghPPDvWYsrSqLlDtKm6xom3BvMUbKUkpYMhK/wBR
yCHcAAZsXYlhmNAH9MZDPVIccOcm+fBVJY5iAfkKZQQAgCIbnE31QIAjuYTD9UA33HyAfcQuLdJG
asvU1TIVIjYZ3FPrXJ46hGzyy12vT91u1fgG8/J0yiw8nY0nlleHr7pq3OSEQfOizTlu2Mn3hZMh
yX0+ah9JNC0kZ9xRlrTsjkDOWRHEYGM8lixgXZIkxOm3rdJPELLQBYfCpMnw2nysPdODs0rZlw2p
QtHtte0rBdij9PjWCx3epfK9yZ1fI+FX2Ps1r5znsv4mpy8ivIWyPtVWkY+v1aYgHHrOW6xjuGe1
xRmjINLFW63CEp9rEhrLsHWkP1Ap3KgwfqklmUAGYgm4UqRKQaGvBudDuNvnafRr5k4XaPG52btq
5XZuWrlI6Dhs7aqkQctV0FSlVSct11UkXDc5SqoqqETUKUxylGW8QYHyznV9Y4rFFFkbs7p1TsN/
tJY5FI8XBVSmRyk3Jzc3Iykym3ilDlRVhq+1fqNwsbxM7Rl3lchiBdk0zdouzDfMyZhzBScSycZm
fVTNWPTK6nWHg2XWFnTShWcatqhJBKSycbo4fyCKMjeYqQsVhtD5J3eVmWP+R4Y1jjzRgwy7Ts/6
m42xX/Ftbp0hijUdULZX8cZYodHwBcb7M4wmmtEa1Kks7ZWK3a67J2NchayqpVyoQThYqL4wKqAU
RfwxQClGJBZKQsuWcVIAeZDMRKoyU5jbL13V/wAfCnLF6rsOab8v5+ezEdjCqOrAhVq6ey2eYfu4
uIrFchmpzJkmZ6w2OcZxsQ5lTkORmxkXTYXZyHKgVQxRAJPR0I6qFbpk6gvsUzMFN4kiGkvkh/Zp
WLgafExUudQlak31rkpltR5WPnzpKkhXsfLd2lTJqFYKOBIYAsq0b2Okt9IWZ9I03C41suZarqRr
WZp3Fl4u8ZTaplig1ygV6uua9E5Min8jX5KYr1pipeZcJMpldk6K/IspM7KgYT0teZsUWnC2oXEe
N79j/MWXMY6RtPWCHeHJeyxLzEuS7fUbxdZa9v6/Lzj+uOcmtanDXZFtGyyNmjmT0rCe5YYSu47Z
m7XO4mGlaoGElaUEJWSADh65qwBlUgBlEhikBXjRkKPPOkno8+/6/L5l/A2SdP1ubUzKdYQq1jfQ
UHbI0e8RMg1mq/PnXTYz0DORK09GSUM/UauU2UoxVWZOjt1yoLqGSUArTq9Mn7xbK5RqrGBL3C2T
ERVoGDiOZnJzE7ZVCpQ8GVyqAopICochEHiZR7U5ykTEwiADdnr7puKcv6iKhPTuZqPFY9wPpR0+
s86QEHeI1zIwT2Nkbmaw4B06NIt1YWshkYGTpq/r1eczrqnHuDlCUu1uYRaqfNFmnTUNhq3avyIV
TGdNwNRrBhjKum7TtCx7KMamjsmX+qzcPju55IvBXC0gN8nJCQemteTzBKPohMIGIj0ka46ayJ6+
ywUxguJeEhDOlIKd2EEKAZRlVsOdDYe0XtNps0vKRJIyoWoP2fOuLLmC8tYRcwjLIVXNDoTYy7OK
koqXhp2tOXlfFIJ6CCer8/Y49WzQgroBLxJHBpKN7ZLvrdEVCc0Zw7SYkZWOh4pm9kpeQk0I5gwj
2y7x+9kHRwI1ZNGbcijhy7cHECINUEzrLHECpkMbYB+iG833FkNgjEWmiq6bcd4nzNk7WTj3IlWw
XkS2QmVcf+qNPrdapVjyRlC3TT+VioHHWQbVWbqlKA879PPK4Fls4NTtHTRyEW5Kwth6/wBdYReg
Os4bUYWrU9WKZlHMFksCc7bMG5EnJmCa1JDDUrYKxXbbA6YISdbDY2mSKowlMgyyzQYlJuoaHhE3
fRejYJvDiMiGNHBU0g4YlyS+Fnc0ew0RlocbJKnyJVu0H7eRcuiLGWo7AtoT/LfE2ah45YyKdbtC
SrmtzzaEmrDFqPK40sTeLsVgSrT11IJKtWLaS7ou6dJqIIJqKkMQIi9LFpatFYn1dQVMxpYGeK7S
5YEdZBbMYVpEnlZZkm0izOE4mdcyscwknSqTZgoogRN44UTRbioocpR2+oPHepPDmHsl07GkDJxm
A8U5Dp0bmTIEg9rVUyzrJy3Y7qxYsLHLhXrbK3W447hL+5i4WhRkVOS7tjVV67eHYjLtH7YzY9LX
l3KDm943xS9iJvH9NcaXsFx87ToW43RSt3JeOhoaxLsrPGyVjla5NNaLNJKM4NCRZvZtnIpKITHL
JlGxFcvKkpuoufVWCzRnGMdjCCksHOLJwAADOwzCG02gJHy5ZenLWqdZ6X8+2jHpcrVvF1omsd9n
a5BtZUk0lU37GlruGtjfVdsjKnmbE0rzpm7bTjmOgXSMSu1covzt1EFClGVwoJAIZQUSAoU50zHM
UoHKn2gHOQREAMUnZK8wl3KXs1OYfYNt9amB7PgaIyNpgzdN4ssX5IazhLHkhQdQpbSpBYcwVC41
pMjX9SMFO4sYTh2kVb77bivKvLQ76HVkr1IzzZ2wQtbh8sFq+YjUZZKrcc2ZdutCapRFIs+SLnY6
lHxcOwrAoQT2yzUvHn7igop3AzeFVSQ8M5CCBFE/YApy82b0j0fButb0klkq93tEhxItIhiHcVIZ
nLaN2yygCKgnDs0kdiE5g3MPwL7xEPgG48alycpVtkzkP039kxTfd7I/9Pt4zpKbo9Nh+/y6/L7v
w+/hIr7AcpRRMf8A3gGKIfiA/wAevTfceM3bqZm8Sd3oLdHhpaUgJMNxA9PCyMTGAHBR7MDpfUUE
ShuO/uHfr93CFVYwpAAAIiYPZDbcR93QNhEfP/t7s63mt8x6fPz8vjxhHkDfc5A7L6ntAG+37vUN
/wCPBMKfi5lz+xspE6kPZiYYz7hlbEYy49sCoELuPs9mIDv8+g9f5Dtx45ij5GAfvDj0sYig8omK
kIdfbMBB3+wwgP8AXx6jrV1BHl7X2ef6vZ9RNt0HlAPrB9m/8uKWvbtYQ2HqHkHv+A9ePIq7BuIm
APiPQPx347VOmG/kHn0/r+fn18uEhzGIls3KZQfP2wER93mHmP3e/b5hxTaJ15l68uHHsxqeeTyJ
q9w+IfiHHQLmFHYBSEfgBiiPn8N/P5efz4wgAjvsG+3nt12+3by49pnEN9yED8A+38fv+fArdsxq
eeTyJ5AOYgcpwFQ/vPtzAPn7w6fx/wCvOMIAZHzMCm/7o7/y/rz+PHOOsSxjmU5V+UyYlJ+8YNi/
Hbcen3+f8uMKvX6UB3L22/ZgPtbAHnyh12+YB8fkPGc5TLfsiO+3kAj8fh/Dbbb7uEvMX94PxDj1
ILEHQvZZAwUnx4NayFqdxdvRlrt4sqiamHtR67C0FRWOkYa1bay1cxhHqJXoM3DeJknrJkudVt2b
d48at1BKs4SIes90omcQ7PYu47h5Bv8AYIefw/6cTPj+hyl5quWLO1nm8dDYmp9etUvHrqyDheYb
S16gseNWkKxZH7Jd00fS8I7O/fSCpiFZcwnAC7hDbtNRLstiE6F5h/4S/vDt5F6/W32+zivSoRFF
3vAhpQqMwKQ5CSMEwTMznP8AYSE4IuzdxrQ5enLTQJJjuAc5dx8g3ABH4ht9v8fLrwfGkEJy6Quf
sVQdJhrUa4Yes82SfPUSWK0VuZpxYmxQbaMsbwAfVyt2BtTX0aEZDIrSrteUQQTBRRdMpgNTKUqy
ImMBQDYBEwgABzfVAdxAA393x93BJ6Ysc5B1BZgrGGMWXGLpNluCViM2sVssEhEQSaMDEzNhOl3+
FGVk5B6/brJRiEKWEOus4UI3IiZQ5SiLoqIn2nrw0rYt1iRRqtwe1o6BrRh5P681sbx3TcdHxHQX
t9UuDaqq4Qy9TrfHhBQ77D1QyLW0M2KyUnkyUlJZvaq7k15kKTochUF2EWVWSSeRMJHTCx3zNFas
nwHKGNYWlZejYpzV4GxrWSGo15TBk8Qklodp6rWxeF7+mZ8kVoT/AFfTM7bnBPbxURL+s4nDG+mH
M9yqrWRSulXpteuuYnmEoKJn7DaWx7rf2KJ7Cqixjq9B2KumaoTEVGMm0jZl25Zl67aNkjqrOEkz
DrcK5a6rbXON7s+9X3VPtK1ZfN7Cu7PDVN69e92l3z5Viabfsk417+kzK1lquWSQ/OBMZP2+N3pJ
YEO6xTdVwVRmfZgkCYmHHkfOyF3gxDExrvMKIPhKmFA7N99PCyxzWWtZyHK6dspt3NkyZiXShMOh
yXRklpu+W+7XSbgM6O5irKWF20cyk1HUK7JYurMhPMU7OtFR1gkYlhX0HceYsk480sYZUw9mykSB
7CS3y1905Omt8GnwMzmaFomd4+smUqszDyKqTmFr7O7zrtHITequoyUm2SSvrIMgUh9hJoWj/OmU
jqX7DuYcd5OeMMpNMPBZqVccjKOmsvJViRmXE4vLXGsQJXVTY0U9nZ2SzmWFV22ZuDR9bKlIxBhh
asM8qucn3o1czmZm+qsDZpq7Zji7XkuJrbCvUGPRgV3Sk82il7surJKt4Cn1hRSpgVurLRbZmYa+
/aSCzse8QErC19GjsjqpxEEskO5Hq/CxUXeIj/moSuKuHHSxfymkvMGCmFoTexQZmdO5TLGEcBY9
pVLY3KEt1hiJNeLyLkjIZGCLBrAL41hCyzzGcjLu5GdRtEXDgZnXKLF1uRfa+tW7GNzwTqeu0Hih
Orz1Jxjp1Uh2TvElMdYhpF4ouTaBUpxaoyjl5Ks1pbKLSMdmlIJ3AHeWlOw3E1rQmQlUxs444Qa5
4vjhrWKBqcb0BzM3trTKjVJfLuRq46uE3elpVAjysV2pxsoog1lV3TVGwTU+o2RIq5bpuFgOskU3
Mr4I1CYkxGq3ydfwq1N9frnU6xiWZvdglHNvsdJt7mOs9nplFZsZOlM4aJt537ebsslKRso4kTWB
rHtyOZFFOzZiVJTdsQuS3JqxByJ4PQUnvtbYxf8A1UL/AKuHpywZ75ruddaaWsTVGYqVYlMt5KnH
2ohxlCOptUq6MLQ7CvZ6vWKNHOoRjGu3jTv8E0eykEzgoqv00iqSkK7cAcojC+pyAjwp2my9tYaL
jTXzTzUHzgzCMjYROQl4CxWehWOYO1i1Ve1ePHEE0kDnKQTiiokqYeQ5TCgXwtfbHjix3hLI9Gtr
fENJpk/LUhtbbJPW2h1q+zkfBQSLBg5rwU6OVWn7OJpmJibG4PBLKFI5SRUOUDczdjDNDTEGFM7X
/IzfINKyI3sdYxw4WuU5Z5yuI1eRQSmq2o0mWLklYQTsc0/O6gouRWgkXCDgirsiiSgFSvKccPB7
LEALTwktMN4fY2OhKUUU7/dtOfA2D7sEuYS/Q8xfrF5i8xftDfcPvDg/NMUZS5PSxroJK1Cpy90r
dYwVZaPbH9arcvZam2NmWv164J0ydmmj+VroLQiibFz4W9YAQyhE1dhOUo15LidJUp99jJiAKgPQ
VR+AB0Ew7+YB8uCL0zQGX7rc5ul4ivalDdylHs8jcJNtkacx/EuqRQm69wsjS2vWrtm9mq21jYRk
+Qjk28zJEkl0d9jqJ8ylwCNrHhrhpXtg5JJBBkZNwz+krNR5ncQZ8QLTRjnGNQR07ZbybH+rWQsj
GlYugEp67B0/NhmlyR1Xj7LyKT7s1/WFyvBweOq1NxZHMDW6zKWlvJrJzMnHAJL62qzjnH+FdJED
XMd48hGV+03aeMszFqg8fwdeuLmdSx94LY03Vmbv1ZWfb3c/6Tfnn38guxlvZUnSrdOAHx5H5jPd
JCoYffXN/bLI0la+7Z41mLE3dWuvsllBWiVJOJWSdzlbUOirOLKyrRGlyjBJR9Y2se3IZQJxmMY6
rr7giFyzcnd5smHqWo7pNKJaL7KzEXAwMCiwipBzR6NJ2F6SDptek5SLjvFIiPZxjN9IsGaq6bh2
3TVchgKhhaLsmGxEklREm14Cu/hYK04G/VVlVvl9Bxm2Vi0y0lhkmqzBWKiYgx5HYrJlfFVjVlKt
UWVRmrdQ782gJhjA22Hrbtu1soQyiifZ2V1Nt7JKCoTlk1OYoDN9DqeC756U9LEE/hHFEDSaxfc5
Yvr9brlQbw1RnJ+h+v8A6nTUlTWzteqKHjAhmHbxp0hRke8Ng9Xz9snzVx5IxfqbgKbj3UJlKTtC
sTOxlOe0i42S+esdnaRXdXp6LIs01rU9sdcYJwVcRl6A7lXKTdKL2frqKNPpeFFsq+rbFE1SM92B
1kyGvOSXsTKVbKLSyP5O+SFitzVi9LHOZeCslhtzW8TDKxqu3ELuEss1Ht+7Cl7XGkiPCiXsq9ki
JJSwSElgWABzbMv9cpCf/dVlkMsPpzmZeliiY4yFqi1OsJ3FmJxQpemTM8vV6hM0dhYqHG36lS1G
YJXBPH79m/gYwXTKGnHBm8Og6GpoPBVgAdJjzcRPpzd43l7Dq0ypI4ixvMrVGjMsiVXF9jg/H6jB
VaWzLXG98jqt4is/Wr7t0Z2jCRFiZi6n4+PclTI0IRZ0Fnh5ah6z8P5kYV9BllSm52y2SShGzKHc
c1tvje0ujsrXEryMQ+dIybZ49SVaWhOVkkPVx0mo3kQbKkMQGrX8Z6uITJduw9j+p3xtkK3117DX
OnQJ4M7mwVBNCJtCjSyKKFPEqVsknDMZU88znQYFQXbuTOAIqmcwYR2RJEFK5lnJFW46jT6PLD4j
4Ddz4tlYmMLr4QiNOuonLtgwzRbnOJ52qtLZViwOp07qq0C51jI60QhT5ZuQG1dlatcmcABrEz71
YHkdHGOZryEDh21qn6fq56NUuV5PHFeumQLxqBuOLXtoUezLawUSYQgl7XRHsWfswRZsoSNpzxo5
rkN3qvv/ABVAouz9unzgvSKTqik3+QcAY9q1klJgXJp3JmNoJgxUUTl6W9cRrN/YXRiqvVy1CQuS
TCMVayZCovXyTWsmkVnTglozVr/SiuVHsWAavGXSfodBsklfLVSI6uN3Taq2JoQkc6tEkRokrKoy
DZhKycUuxkpOTVRcNHbZQoKN1iEqiNDWXN3jM4MkyoAQxDkOknV90rGWMbfqqDNQCfZbPhx8Htqj
tOOKLRjetV9niilcs76M+Dz3F+FQsUxybIZfYfk88RuU7eHL0IqTpi3jrvmq8dMmcCCau9f9g2w5
ZKxpp3e+jWw7k3FuPXkXlVhntbGuTbvPyS0jMWCQ9TbNOqt2ZWsuKRKSiMOwNVmACLyPIo1M+Avb
AZSA6NeNc77HxHtQNlaTolfpE1iJO7MKgi9VicfRJmBJTH7K+NmqttjaRGHriRZCmwlgdRLMwcri
LSEOI+HM+cH2E5TFhEmj3BcLaWMrNNGmMaWNeibvKNbAhG2FxcEq2Mw0yPIQySrNhYl5ZOed9moR
u+UAhgCsdd12Qipu14SQeyEkbp0xM7sXczqBaYMOLICJQh8qYZ9zefgbOovT9giQ0taELrh2DgKL
LZQZL0fJt/usgRlFSl+hilRmrtdZxstMGrsWFk3dOBhIcW6MGPeVBK2DtOCzyNpH0v4vp/o8rRX6
1SslwNszA4wtnOztrf6wscvzSxPApmyRq8JenTZlTyv0LQeDiG6vf6pCPIGJmAQmnbYqlRVoy5qf
sOBKZj61QD5PAVSfOwo75TD8BAQjOVdHfEeFj8isos60kvJni5Mksm3mlDyh498WzgwFo4BNfI5x
1QQOI8O0eVr76q4txpdI/IOJpJTFyFVZp2wpXVqYS7e5rQ3f5NzOM2L1+pHISqqrlmzduikOg3WO
QSDd1RUoVAjJS7q6rlQIoHMhiwkZADCGAFjohxg+BeImc2+SflR2zo1rOqt6OmnM9WdqkbDVmNz0
9S971JwGNGdMlZ2Nj6vfMeSVwUiankNGZkoO4t4KtpwsgcXsW7nkXpW8KImEFUBHZhoX0/T8vjbI
bSlqLV1HSjdM4WmCq1ok4PEGSshVOYp9bXgq3YJOVC8VyspPLWWRu0u7alarIrpLNVUyKkMavexe
kI1mpzFNt8jY1aes3mLFf4xhF0VOp1q2Ob93/wBYp+Vr7dOMY3xhMDY1QRkAcA2db/RrH340U5rr
1SHe0OYeyLWoQFPgX8LV6pGUM1VxpZabYVYyfmouw0gCGgLxFWEqFaWsp3UhKN5hNsmpFicgFESr
vnR0CGIUW7xgOqHCAXMsmBLvMg1AIFXDEu3SC/8AmoSZgsF8JTJ0scuQNCdWgH2F7bQcU1bKUnn6
s3GntcfRuRrEbEmOcmY3mGsddskJ5Fi5OPWeYi7o2eqk5lRKCMy1O8cWIjtIT153ul6XnGe7dRE7
tb6PSQbtKpV7LBsmVxqjPMIy1ejFxAHE6FifafXUqzsElSrQRE+SEK64pEg7qJ2SDpU73Y6+tRMO
5cRaddoxKpK41lcWM8NJ48eweMY6lzbiGtUm8rGPomdjjoTc28rMCLyQavu0Vg3cq7McWxFDhDY6
mbLBZGaZBgMPYGpthiaAjSoSGiMRx8bA1t2KUMtG5BiIZw7cO18pIIpKretMunNTwJpqH8QApDCA
li6LE4YpJtOq2tOJdt8m4aLwohy1H/8Ajv3V/BtJenTA9VgNZ9O0z6lsfPJ9ScyYyxrPNYe5P4eQ
qrk5+QjyNfxcqq2l0zqewRRMTgY/sgPNwEN0iDQVgmIhPsgPGysyyTHmDqoymexImG49VO2+i5Pr
dr9Htz9OJXw3nqWw9luGzInXa7fLhWp5pZYf14VsbxqS3JS6abWxPBbXCLevFVzqpERZOTTRlTqp
lIQwnLvDl1n3k9NyE9JkRQdTL+RlVipCBUhcO5DxFRNsPQqhwdfRGInzGBb6MwAf2eMW8ezm7QK/
okNoqjPuyLGg7g4Id62giOHlJ5e56czax/RBp80+Z6hZBtb6vkuVcUGsXbI2oa+EsiNSrWKMVxng
w48UxLEQcvYLBk+wyXZK+Jp2mAryxuyPzAIkHaseXSbpP3AICQEkTdiQoGDcU/3ihv1L5bCAbdfP
YOJ2096lrFp8JlJKAq8FYUMt43n8bzbSalLHFpxkROfXl+WvyceDt7H/APkY1wEyp+4T3cDsZ73l
RVUx0A332ETl2EPtEduvyHit6iw4sCAiGhCFQSwSl+sGT2qT3gCTZ1YRBUiJtBFU+YYMZAcWl+0r
GphLAUFkXS5q0zY9PJO7TgiSwcnDpxE64jWzdjfJ3I8NYndiiHKYMJZtKJ11H1YWYzgpV/8A9SMQ
dgCR6X6OvP8Akeg0/JFFfYzsUdeseW7IdFhY6wTJrPZIegC1DIMJBx0vAox7KZpYvmQWKvOpozMB
eNQrlmt4uEeaINO+q4MJ4V1IYVPjavXWL1Gx+OoeSm305IwC1LVxi/uElX145BiRUZUrp1PuUnRk
ucO1TUIYeYpgAlNPnpNrTg2p4IpyGNK1aWeD67qIqccdzPSDBaxsc+GizPVHBTkKLdGleAtQTUEA
K7BQgc25yiN4SLlDDxIIBq2JR91JGdMYYuxYHRyrGgXjabXGXo2sxXSm/WVosk9CmYIPGETkyRsu
LGjawYxWzDA053f3ja9TdHiD8kq6iY5bkqUjOxhx5JGIZ2JZwyMPK5STHh22X0aurKoY7nr9L1eF
OrWMfxWWLRT20xImtNbp02mK3itgYlQFkC0aiHbOmcJM2ArdIBUVAhA346i9btQRwaniOW06V2xu
W+P3NDrj20W6csNJrNkUkU1HOSqRQpj1kJQskuiLonlJ+p2VFuQqqRlo8AUKIyVlT0nUnmCoPkLV
RrYGQVsPQuHRlIPNt2ruMhNEK+HPLUhiaCXj0SWZ02HtSLTlgmIs6P0gFEvXh/Y9EvFYKaN2nJdJ
dDBLFmZw5MizAgtaMd7l1U+KpU9B4eMT3f0deqWiYwmMvua9ATmP4qs1+6pTNasbKcPKUacSTkhy
FEQjBRw+fRUa6VSSdO2pFWLdVVNNVchzlKKbUJotlcC6dNPeeVMqY8uCObHOQT+EU+yproRDSvzU
FFpOay5TXWCyt5FvIvTza7EXCMITwAXB0gcN+be6n9dzjNWPMB0fHEPkbE8bifERMJWkoZMfSjLJ
tbZowLiHaTjaERq6b5BugYq8rFWQHtfbJGKou9KQQHhnz2sOoX/SFjPTlfsRpWC54RQu9dwrkxO1
SjEkPC36yRM/YZCRqoypYqx29nLQjJBvITKqEIWJXRVCCBFUgmSjC7AXj2dJWLuSyVKIC0sQkSdi
+FUi8iDRjdC72e3hTTIH4Xy4/alhavuZ8rZieNHeTsm5Eya/iGpWLFS/3a1XB4waIj+dRjVzYJyc
PHs0/wD04sKLoqn9kBh4LNtpn1nyOS82YSSZWmSveG6fM3PKsA2yEwM0Y0yFIid7JKyDqynYWldw
Rw3ODGKFXmKuiblEFSCYPgpNeRbrq/lgxasBWwrmjvCs1omA5Ve7mKK/5MAEBKuPYiAjuCv0e3N7
PFiVr9JnYp7H89Jw9HgKvqmyhCtaDnPUM0FQJHIWOoOOWTg45vHlMDOrW2yHcSieRJ6HItGSB20O
VmbdVABm6pX7OExYikLIEiA4LhmdpZEu4llS0SR/TmZbhNqNv7hrK2PUTov9JUqa6XLUJVcy5CJi
CArkxPXe53mQymvFVmeMcqy9fnXt3sMjIkizJqBNMK6nIlrAlMD4rUSiABtkHBeS8a16v3a1R8Wp
WLO/PGx9jrNnrlwYt5ps3hHhIqdWgbK6awsnLNAF2yYPDoO3bYBXQSUSAT8XYznpncTTQZZ7XGGS
lY+/ROpZlFNnc3BvmsaXMEXieMgGqzUXByuWLOWqdzeWncpk2gTYGTGcBcBENtVOuLCudseZcpNT
hMv1oMg5IxrlGjVGQJSTY8x1JVSCn6XP0yHZtbsUWePn0DKRDowVurMnhpOPOQTdomYA5Fzuxhpi
laEK0ERg4KQGZRrMuDISIBAt0P2iJPZIFMzunTIeYFoRzvFZBlNMun7OFn1A5Zys2zFcswNpel5K
mpywR1Nt2LGVSiZeWhzyt1mCz76zIWcT+tFh8BsDAipBFsUDlEYpv2B2FV05YNz8yty0g0zDasv1
OWqsjBoQrCnzOIhqfiriPkkZqZaWSOfjZT7LPI6ASNzgHN7Qbu7JOc8YWvSFp3wVXksiN8jYbv8A
lm7zrmbYVtGgPGuWD1Qq7GrqwticTaBq8avIEjEXkCJpM/MCPbGMAAiv2bsXzmjzAOEYBS+JZLxb
kbK15n5N7Xa3H0x40ysapEbMq3OMb4vZFjwpq8iUidkrjU0mbYpQOIAHBI5Us30PhZRGZGEAEZyo
mc8wzkMZhpzL0+mlnDlGk+kHpNIsE5lhbUKxopiRsHbm87kC0WKFbJ2hr2sGwudeY2mXkYpxLNh8
JO3t0PFKOHX5qQh1fowhq+6WtSGLqi6v9+wvfalVmpa+aTnZdnEt20SW0FTPUTWRpFzKkzXCvyKp
HMaRgGoLFVIYnOU5RNbBaPSl4JZzGsO80ejZYlbTqttGF7CFat7Gm1+q0pHGkiJ5JE83W77bJqym
lE/bSKasthWL7ReYOvAr6u9VOnvUdkfURl2oWHUxTbVmpGopRlEQNT6NjVtKwkbBp2I+QZ6v36zP
8iMYw5TFhlJCtRiQHASI7CGwQtGNv9UlEgSykkggQw293OoBSd1kv9R8CGfVTtasRF2ssqRBEpRX
Mskg2SbbKKruF1OxRRRTT3Ooqst9CkmQBOop9GQom2LxMsphDN0BdXGL7Jiq/Rt/aw7y1uqLIVl+
5sLaqR0apNyEu4im78JNGGYQ6Sss8k1GpWTWNTUfLrptSCqDxX08vq/GyFsaZ602y54CNUliM6/m
ODfz8kWObnlmbGKhZVBN68ml1kzlQZtkFHapyHBNMeUQA75X0iWNbmvO6iLrSbtJ62ZvBstgF5LN
XUMhglOIdws7TZbNCMaWcCwDkhamfoQ1SLBBVhYbTwrd3+m4oi7XUQxEimImr4VEsoFLSm4LEkvJ
gwORFxnH6SQqnakCJA03yHBzSw1W51r/AAhLFji9paoywspi6NyNYqrYW9tTTf4dp5e0q1utIuXa
q8tjisp7nikbXJvWtLIAmbxLoN+GHXNJdxtuk3IusKLstRJXMY5Vg8Sz1VPHyfrS8kbKjS5VtJN5
TfwtRNsvcECiqAiAHdtw3AViAa9q/em5032erQcLE13Ua0RbTSKUs1dQ9BbtZikHwYrSnlUUcscx
rrLV53kJI1o8L8OM3UUSPPFIaxJix4qKpeqXFsL6OrNukyTj7qnky+59gcmV58wgWctRGkFDMqs1
RYyE29uiL6LlO8wcg2K2ZxE+t27eGR5BUUblEW0WEximLEJvBAUlgcIdIlSrksaUnS3ISonrwIad
+I/L6elAwsVrBtksmFsiZ18VJG12jS0PXSt16zkJ4FlmrB4fyNmtrhYmwUuIeMfFYrtm1ttEeuiM
nHioQvfW3aRzF4wyRO1mUutdx3c5ynwQSBJ251yoTD6qQCEexGUnlJGVYILxJU4aMDxGWO4clLHM
Q727Mk33U4PHB2rDGGOdBGrbTLZDXschZyttInqqvCRKMlT2zepHbklF7JLSluhpAj2WPXpQiJUY
aUOuLKJAgHEyQcYMH6q6FQ8P/kpuM3bZaDfUbIbmDnoWEsERlLEt4ukAZrBp4fu0DfmEVO49MCSD
t7TL0hDQwS7u8TR43wR5z2Rq63Po6NGMOKuLBAZlJLvJJebe84rvcGVrRDGQJQ0F2Zyc2rw+zZPa
FMYaLs25e08Zh1T1OMjFMZ4cdQbeaB4ysK1htIyZ0k1HtWYwldsEPZ0oY6yRLKq4nSEjDHKD8UOY
OBQj4qak1XKUXHPZA/dXL9cYdo8XcmZsmyj15NPCNVlDpxrRmis7cv1ABs3bIqOFVSIkOcLPdOGs
3HuOtEepHSpeLHk6uzuXrlUZeHtFWhI2wQMHXo57Cu7exLFDdoddK12Rqis4BDlLWJ9umdaftLRM
hjBAelLV6bSzI5cZNKBSb7GZDxFmPHjFxbKFjt7aImRyPAlh4ewyc/K1+2SrumKEax/rjiqOehS7
J20944hKCjKDYgqgw0RVwzEhlicDLIJACSHJJEy85aGhJDDhRSRjSEjNi+nDnws2MeaXrrc8G2fU
JOXDHWNMNVS9QeNE7ZkOQm26Eve5aPQlm8DT4yqxVzfhPQkW6ayc7M+GRkdWI9yg8igctlk1DaXU
lpgy3pntrOq35hHyzCZptTvFevNJdPrFjq6U2/rvW1LtkFZJSKaSCsFLOY2Sbplmo2Bt7xaPfJIM
1TtVykLDF+ralDpEuOnuYm4LGmRVtSshqCirfK4Zrl4w2rDz+MqXh2fq6uPKqzkF4CaYtyLSNdeR
FPXpi0mkYkbI19RICkJ63ekYwDbM30i+TViyVLad8Xad8aYEsOmSWx3XLIlqhfUF9bZVez32nzcz
I4qpVfFaxqEZT676yZOqx9wrsO5E23DMK74oATEvMNJ6zhCkksGwgOU9dRZnLAPiUJYrxxFbsIy1
dy27JuMjam+hY6Jboyzyk5krGeLWNTqilhbSeVJicg1rG0ZKKIumGOGtSp9kn7XJvlUlEnMChXn8
RDqJqEVdpGIYAm65aRbzjqy0mu3TJWGYCOybpyR1IwdqlrLZoeuv8crKWlJhDLIWGlRt/e5AklK8
gnW6pG0OZayRxKRgsubpwYrXKWkK35azPmy35qPMScFjVg30a4zyJiOarmMMbW48hMpxGPsi0qgV
W90n1cw5IqpTdVgKTCS2NZ5NROwSJF7AcrIYhospgqxZ2UyNqh1Y1bPL+CxEOQahIXOs5duGMLjn
WFk5YtLwfkdS0UobWhiCIlm8XYZ9xCVlGDs1HcS9Zi4bnTcVshxc7iIWBZhLImVFaioySeqAfJjR
QAsttPlHjwryK8LCHlbD9kxdTsUXR7Y6XbKNm+Cs1roExTXlkKxet6tZJikz6asFdKnSLDETxJyF
kTM5NeKlGQruoVMs8B2EoXhn0ui5HyBL1GPqVSnbA5uduhceU1whFrJMn99mnrZtXqtEypHTWKQl
XT16zkwiHqh42MQdNl+8kTXSOYhMjWKvZHzXRbFnzUXT8n0ZWNNLWxDCcdkmOb0alQMzJnb4QxDX
bxTsfVOpozEek+iMeQcHHsKLDy06hI2KaOs+WNaZKr2uGntNWWnjIcbRWmJNMODMs0a7ReGsbdom
3VYU6TcuvX22MnEtGN7tnqViJIImzXp05Sdynq3FQcbIDXYiuvniMRFwMVypQiAFkYmBo0y7UafE
5WoCJdUZa7vTmbs/L+i7L2LqFkq9/lHw9lKHwncq5TMyRmMMjTVnnMXyVgcxicPJWNseCrgu49Sw
OmMCrPRcjYG0PeIV1BHXSmGizVMF15J47FI7h4osUiJmDMFnSjtNAWxedBk1K1eIPjM1Ce0QExEp
y+0XcOLprNnfE1axHqZxrG5i06SF51LPsd1HGV1wFX7RUgrTCrahjZne5P1KXaaplYlomaWhT+Dd
+rzK92AVwBEWXaABeGpmrUBpstGAZWh1SZxiXVdBtYtfUTqSb41JAx2piEh5WBYLQGnO+xcwpbqX
JpMkqu4vay2N8XrZlb1SwrM+yTfSo2TUi3WBGIBviEjGEghSCGCEqxKxKcDEFIzUFASYlVqMvQUG
Z1FJb9/2IrWjRRnqox+QaVLWejFyJjjGETmfIGAmVrsBskwtGfRdeuPf5iJJGjSZFeFpdta2eXYs
7eAOoKHdSTgPXVqq0IzKDoJzTlWlY8uFelsdxs1mFvb3eIsd2C5soDJOTWtBZSEo+c1eqeGSxlW6
qkTKQNdWkpGDTsclGv2DE7lyzcJJ2mZ71AYNmbfrDzHV8y40kcY5Q0q0XH2IoeHl26OrF9b1KZhS
tOoi4WdWOHLztnFTVcskdeELTkx4M1T1HK21lh01K8G5wVqXwdDyGmvM0s+03r0PHOK8OVy4qXtw
gpq2xHYtNtjfWCYjsMVNFvItEmWY5eOQQhpGGsD8k9E2F8rYz1VFYxjEi9EXONDC4sSDEUEhRClk
KoCQAVdUvUEmhFQ9qRFqQZJBD5nKXjWtLfOfLwszXXjyGm413DS8c6VYyEVKtF46SYPkD9muzesX
iaLpq6RP9Gs3XSTVTN7JiAI7cNp4uKTjmAUuQP7PmLv+G+/+e2w+7gqtYeV2GddS2csyVlpONK7k
3JNstke3mzotpppGTcjzsW00kErIle93T9vlayUvsQRNty9eBMcmUOAFMCYKGDcpx2ADf3RHYB6b
eQ/x48iYYBajZCg3Dz8tJlWcYmGz8WJ+m/vz8HXIYBEocwBvuIbCAfb7g2+A7dd9vkkVUEQEQFEQ
DzEDFEA3Hbbffp8d/P7OPQgsQVSF7MSj5CAgIDv8B3EB6/D7fLjB2xg7YopkAg+Rh+qP3j0EfPfb
f3/HimJWp5/b66my94QA8zRvFhbtRNQodocUziHwMA/b5b/19nGEFOzQTTUKmZREfZNuAiP2D18/
4+/jyqKhh5ANuX94OoeYe8Nw33+fTrwhUWKb6pim6gG4CA9TfVAdh8zfsB5j12+HE7Q6Dnk8icWy
AYqn1i7fDm6f5f18PemRU3DcPL4+78fgP2+f48Zdw35dw5vh7/w8+PIpqJpbFFIR+ACUR3+fX7vd
/HhfZfOfAc5cubdbIJiEBblMU32CA9Ph0ER8/nxwFzCOwFII/ABKI/h58Y91A7XcpC7+W+3XzHpv
tvuPHSYFD2+YAP09kRDm3+wR3/h9oeXBbdbKC5x8ikH7OUeOceku195SB09/4dfL7fjxzjrE2Y1P
PJ5EzIOPY/2hQ+PtAH8x/rp5+5MuqCYb8qW22+4CXbb49B8vPYd9h6cZlDGU8+y9/wC0H9f18g4R
qIAohzGUIBex23Exdt/PbcR8/h7/ALPd6qJgR7z+A04a2TtNGDMi1qlyl8Y3FnLylWyFjqZos21r
zpJSa76+k42xV54mpMdg3EkfNV9vIAcAECFMRXcCmKYYWllkXDx2LYipo9w47y2AhTGVBrz8nYlK
UNx+kECbB+17P1unBf8Ao/o+ozurjCFfvERBWep2OZslfXr1piGczASL6wUW8xNb7WDk1n0Wqo0m
ZmDcJlXZTBuZmHKG4dBuyZCP63drXWpNsUkjEWSTiHDYpBbGQQSfEcNTppGApykXQVSWQHlAFUlE
1UxMQ5REccmN0fCimRgGQFFTFXp2crBxf6vC3NbRz2pTgYTE2Bbu+4iGwN+Xbm7UR/V8u3Xn229/
E5aWMowmE9RGKMpWf1iLXqPaY+bl21VRaq2N40j1RXLHNG0hOQkWstISf5u+RTnDH8J3UOXsva4g
hdRUqAblIHZ/rd9g7T3bF3+t8vP4jxva1LwUVYYOXstd9ba5FybV/L1cJh/BeOxsX+vrwPY5JUED
Pv7J1zAKv7Im4X6OKURMZLKcMCzOW75E087HjhHxVbTQCkjn+dbSYbXJiqPkLvVAaZYicUSGoVrq
Ox7JwcfXUciQrh27ipC90qTinN09TndPnq80d19FGMsniLFs2cTTsbCkiqqUNM05jpOb7rnXLllj
7bA3y72NjYMYwFTTjpGoEK/tXiFlWub+Vm0plBPwLbuSldQclPdfz4gjHdODtylTMNSmqDVFaajT
Ma44r5MB4QzLiStyeP2UhimsJ3GF09p36WnMfxbGdJZSsK5YblYzNGUdNkbvju7CoBbcktMgC+qa
tVQ9/ipuiRcC2r19x1jvI6UHXI960jmT6bg/ErPKwUecBeQEcW0fnDNvIlTRNDfnJN2/t8ek6Qh9
IIu13MW+QVbJikHC5du00qGbEu3fbGRdYCCTgJec1K3elppwTrJrWE3+jp9GMrenHYKeXKVyxXY5
aOh2F4uVisN2WiLPEoxM8s3nLXFYvt7SsK2yzRKTxBGJdQJmha02VfElSf1m4JcxMK2rtZyO1mHd
e1HQNzycpVqk2vkqzypNnnsUNlXrjJ8lL2A+KwNUlTJyNygDRiZWikAD0qqQmiPGLU0rpSyTf7zj
DFMNi+rwtYwXTrwwqMe6yxMZfdWGAtjawOrMV2L6VaKQEZLztlcS75uCSEgSNphn6apQMawej7ol
31Us6PDmqrPT1iSU081SzEjnL6NyjYmeT8fVy21h9ZJR3DAhJObvZZlswswsZUTM2NqQCkeIFjSA
U12gdKLH/FXeMSCRjIHVGGQarPSVr+zwPgP/AFqsBCuecVr5YpeVYqUyVVZaiQeEytX9fpdcVUtt
vorWD/KfLWGMY5OjHMX6wQpTPmSlfkZ/x+RKYZ0WZwHY/bx6RHSNfbPjNScxZeRx9Rr5nqfk6O+x
9j+TirNAZXqsmnDJEZmyMeNI+iciv2VlKko0mFIYrxq5rwPiuETHGmx6Uqr+WunZMzvI4ux1p1yF
kPJKKkbjOSkq4m0SwjaDQEzjuEa3YWEjAWmeloCvV5vYpKVTYOY6Slbenzzxn7SzS1lfF2nbF+tP
PFDjcLU93heDRxtkaYsLuzXV1EYgxDK0OmTdhhI9OvyDxxKX/I1js8FFViYcTEwyc2yyRMfHitTb
TIvERH+JYNkYieOFORDbnmG1sTYXH58veO78+T52CKk5UpdMpOXYU0vYpBnlnFitX9WCViHI0i7g
0v8AF2msPzThZ/s3TdhVYJoJZjtTThJNVIgMwVOUB2Fs1D48sOiLHuAFiyy2RaLly03Zm7LCkPCM
aPPoc0iySsBZoVyO3s9u4In4KBlT/VAxtuLC8X6XNM2Tcc4hlaPjeZJC5ntmp2KjZW5Ssm8zHKjR
4C0W7GRMYJVq3ucaNTV2KrUY2vRbY/QNMFe3AGYbPmPAX48xlii5aS9VU1NY9ZtcwYQe4pk69dms
xOdtIRN/yc1rVgbKwwSY1k4M3L5kzbF7gIA4eNW4ACzhEhxREdKLE1pAAySndrw5k5QqBL9RZpl/
jz3DQtWMuUqywdQHmX3KICA8weW4dfaD4iG4e/3cF9opyJT8aZzr1iyTKOo+kOKLmOm2KSSjhne6
NrpiG81eE7KAYFUfvAF/MQb59smYCkZAofYCgPA6P23dFzB2CICj9UB5dx+wPMf4jwRekHG1By5q
PwzjXJjmaNSbpeo+BsiVal3MZYBbv3nKJ2UiukVBRMZzaPAxBMUWG4APKG3GTdoCxeLuYXXMYdbF
JmrhArmwednlKxtk4buIAz4Wd2CMjUShyOV6nNXCxVZhkmtqVaJzVjNObZTcMozmU+8NJBms+i7O
lia/V9Fujeq/HtCTKiSUPyQdhLGSggUORdQdBdej9xTgZhkWsSeSMe5evyy8dV6zY4Jd5iOxuni8
edzOWCAr6T+JlplOIePK2MuaWmgiaUexEY9xdiMFPdMi1/1M5fw5j0IamVrFk9kt1OyV7nrBOxNJ
pGNJ3weXmXzpu1lJW2S0MkH5hHRsIopKAGyZD8OfEGnrCs/jDP8AmC4XS7u6Zji81Oh0wlUCpQdr
lkrdFWl9G3a0U+VspfEXRXtfi26dQYSoxh17JOpEsoqV9yVDUhJvQRs9hCkZKxKmZB2FJEuxoC8r
LLMNZmtQ3SI93flPwtJOrnN2OMnYB0bxdEv9SsFgoOCKjj6/1+JgrDHzDKfqMIgxjYmelghI2PsL
hjFy76OOs3lJlRFdu6SOUqiawAr1D53g5zPmnm60bJFCmoSFjsCTNgYQCT+Ix9WMhVeAqUNf39ki
nkPFtnrRJONkQTWLFSpEwYPQOYvdVwTZI6UqJD6JWmq2222fdWa8ZSnsa1eGhmtZlImLUhWyjxrF
3UXVkSsoktbNlbXjt4g7I3YtnEIuaDKi5bHPzPek+pYN0zafcrubDbpq858psJkFi2RXrfqK3h5h
FFw3gQAqw2Q1srbdCKWUmytxjnqTiYUMIkSXECQ43SKFhYRBqQAwE/eAYVkomWRM2mbDC/uLyNP8
Z+ZbgNLFNXtSVUivSnQ+XgyjR5fDyGaLnPsLk9kHLPHNXx/a2ks7kG0G3fHiUo1wo1dtTzgQbF14
nNuW6EZu4WIU290p5wxnC6/9RtovWT8bmxtbsd58x9WbdeLIK+PJOqy9yhnNHp9edTrhwkpXzskl
WUdX2LRSOcwiSiraOUbEMYApz3pUr+H18JU6InLdJ5YybVcVzUpGzsVANqSCOT6jBSaLmpyUNYF5
hyghKb1sVrCi3TCIAZvfsQFXh3WLQ+1U1WVPSZRL3NyNzl72vRbjOWOrCi1hpGLIKktY4tGLl5wJ
ynLE9urREmDd85J7VxFkG48V2V5HWEOEAUAg4zhCUscQyZlFy7M2ge+x+dXLegs+tJmRYxjedaS1
svFAjpqx6e7Q1ql5tV58JLKXWLytVJCqBQbYrPoP1nj+PCekYhFMFXLJrGRjmTAzUu4ptPeWZlpp
y1iHLdoeEyTYb1jbIkFaZLJasRkC2T6Bbe0n5GvqurahNzU2kwmmihJiOYuZGXmZZ0iV8o4nYIqr
Vo2gxbJ2qy6aZKJkB6qXHTW/ztlsL2pOEbcyPjZwi0skK0ghlwYvLI6dOG7aOaFmDVBZddBFN0Ki
pCiwMR6UQzBkXM9Th7bON6vhbHlnyrYbE4x+E9Y5KBr8xDVt3BuKenNwybCabO7ceRsDBWWTct0o
iyrVdK4EWZGJZMS9QyWWl3ScJZgSUhOcgVAszAkKaZNpaD/dV/0j5X+/JDWqaGMxUd9ifTkExkyp
BP0DIWcY/IMpc5+uQU7iSoXGEmpZKfgGdmdxsXcWthXVSIg/n0bw3aGVICau5ygYSaVXbbkDTPq7
olasjKZoa2UKpkPFqcvb6nW29mWipm5RtqsVchBn4OXayp2zpqo9eLRCkLLJuG54cRIsmJhvxnpC
VyixlJ2LyQzdwhc7xWEohjUqjKWmyOn1pVO7ZZGs0KrNU2UrOKUWCSsaEkm+nJQFklEArvOQxQ9x
Wi+0Ts3qli22Q8akltL5Lk9nojxZeTsV6SpNka0uZsNLjzNEF3VdSm3zIzq0zr5F+iu8aprIlUcI
lOzeLxe4V2uxjQoX65BLAFmIIaUyHAc5sauTJ2cJ8N5iHKaUyfCG3yenC1stEuuCUcSx2Q74ZtLY
4S0WwGPJEZu3R09RKlPU+g1SsOaLC4HkDP2KN/k8lHbWGvSkFHvJdpBQE7ISBRav3KohDLxtpZ6U
8moZPi5dNvPPNP8AcqvbJ3JLrKqedkF1X8g0gKc3kpB6nTH6lfsqk1Isal3pwmmcItVMpDATgVLX
o3yPGaZqbqwYyLGz0a02eZr8gi2ipHxaoSFeeqRyr2VMkqaLRI+kUlY9E7uTTBZ6mo1IIrkMmEU1
TB768w2QpeDyXT1U8aY+iso29jLN7rDRZHk/IQEYxo7OelodMLLk1xI2xJsnXyot4qwRUPIGrtgV
SayY2JNXSV4VE2gupBAAYIfssKkTL13guJF2IN3iwv8AmoanaRUB8MpHmXdYzrPhVMg6yMU4XvVj
nsWYVuMpi5xHIT86wmYGhsp+rQ0fYVYFJSRZxlSYx3ZK19Jkm+VTS7JSVEpeQxwP3U9p/wAT5yNo
Vw7JzLPH2N8f2nKOC3Z27syko3i6NJSC9LoyMpNyTkYeYyTWKwAx77tHLpVqmZVmCqJRMHzTWDHe
TYmBg7bOVC2Q1UnGzMK3bZWFnGdfnW7pp4hCrQkyuCxFUhYfnqCjJ0oRRp+cJiZHc/BGOtJ+ZWWB
cT6hbFfabXsa5ZySNAgz2uXv0Y5r0shByc8hbZ5rKU1CJa0ZSvNXwJzEC6n1TtplqoV2ZN0kZQPt
4iqT7RdVuD1RgbrYWzEyEku9QXyFmv4fD/uw9/6hb3atk4PjvtaRrxpuS5nIukuYwPW8gwTlbTzG
USShMbW6Uh7hDM8eulEpnHI2yVlDO5aXgYZJVm6ju+ntTrs1CrI+wbaLtT9WvamQdA8lR8U13Jdz
teEqbAPcUZToUJeMhzizIAav3OoI08cCzVtcR353+UyQbR7ozX847EUvpOAJm8E5vjMXVfPFYyjD
ZCqk9m2RwrX5jHlruoSBsmihLue5s0bXDUsW0TZmzhuuaTT+jeILoqpnUIqmY3eWMCapMT6i4HDc
5f0nuZrFDVlkxl4zKswokMbkOresDaFcZDlhgxcKKtv0XKQTAZeFmHH5vDujKbk4WiXiAmLsxAik
f4TokUyY/Q2FBReQf50EM3vmgwcN3gbaa6+ouPtVjVrpktlxsdRb5ChmsPJwbB63eyEctY4VezxT
dBm6RmLPBrIJKLNZWRZpxsykmopPw7EhDGBsa+a+jUtWeomvs49sxax2WLSmg0ZtQbIJd8kudi0Z
sQKXuTJsmPOIlIVMpNjCIB1GHawyulRyCybpW8cM2eMkl2Dq5PpCdqy9WftejoXU3V2Ujaa6o2/t
ysI5QyP9oBfLh5aqMNZNwlmy748zRYGNxyDASSZ7VY0LFY7inIyjxLvCj4LDYWzWSsRQQ+mMpLJI
ACQioIgTrxlXgo9m/lpdzJ9CkU8H48LP4I22u0P2qE0dnOKaXZmyeXpQMLwd5ESCBkxOoTtEygYB
MoT829shfMxPzxoPMUBD86bDvuulzZEW25gEAEQMUTlSANzGIHmYpfrCQvvMHQvvHpwcGmLH97m6
blG6V9lpxRpVKnKBF2216jKzXppghY7eS4KVmGhXMqktNHUckhX512iKIqnI3hjdmJVUBHFkG3ZC
wVkHIlFyRgnT+0uUVYO7WKsS2IYFZrBv4z9e2iWScmSMjGr7+xCFcOirfscw7cUgXJAHtC4ynMwg
gNUBgXB07sxYu3ibbZYEkCWJy5pPT6d1p30EYRqOXcLa9V5JYiVkx7g6Bt1ZVWrNJsKypmMjNKSD
BhMzFbkJyrEcEVSN4jVXtXASqpm5+U4GGXMC+jyxLkKoaOG93v14SyNrU/Lg9o7iFfwcfTqIniMP
0c1m4aQiZOan1ZH/AM0nDycUYfIwdeK4YrP+VahLW+UoF5ncMJZAS7haa1iaxTmN6pKxXIJ/BncN
XrEEeo05AMbs3biYLygI7bBvwmr2oDNmPmcVC0jMmU6bF1zvo1yJq+QrHWGdfCZ5vFvVqMi51FjB
hM9mfv8A2DNPn5D8+/KbZmCYKX9oD6FgWkmVA3WmxJ0LAgDokOMSyohRMGrydAqaSYDjR52NBhpg
0sR2nTEuZsm5bynS5fMSeU63DGYQUXZatB3nCR005ZtPso4ytplajbDzVSJBRjFoMnAnVtpZPYz6
PDh93zQTgbEGJsVzmU9Rjyt5fzBhD8slMrUZUZiYrizpQoGhq0dGtV97JHbIc3LKPfEh7uJRFYSl
5TGBuFZ6h8rYcsnhUjc7ThbTwi2mZuGdWojin43LcZdoRo/hoCRkUGZHU0esCScNDNHY86SgLe0Q
wBoG2pTOrFCNik8zZMQZRNb9TYgFrfIuHcBSg/8AlSFdEO8cQFR8v9UIKWXi/d4YAcX290l+mmp7
weyKS7SfDebWWgJiiGiIpQlUB6AvKWVMnna6Nv6FWizr3G7GG1Az5ZjION6JPpKSeOq8mzLfsh1G
52eiQx5GEsqzr1CUYVG3MbfLuYSXtKJ3kSnTW7405Mg0EfKnoyLBjLTtacvv7+2bX3G9SxRess4j
lEkhXh63mQbSFOGMnosZtKZdKjXExWGVBuUwJn3NuBQMLEdrP1UMVIN0yz9lgi9dZVsIJct3nuSC
i60k6Y1QWpwV2dIsI2TmY0pyCJCrSiaACB1ylMiltWGo2ZgJWrTeVLnYa/Y6u1qNkibQ4jbAa0VK
FKwUi4uZk5IH60o0rxJGfPBSdkl3yVOLJmNT1IYF3Y2YCVwgYuFht8OLquQcQJIEhMHCxdmcTBde
Pd720lAaB/8AHe5/NjVn/RNSpsOSeXadmFKZjm+AIPU5WoSzVj1ePLUNyiRpOREirXZqwjCXusP1
U5Fu0ZDYK4+SUTW9aBKYDcU9L7t3GygcyLYOc5dhEFSe4xemxij8Q6fPi3bU76QZhd8F6eMO6dJX
LVGbY6wkfDWYndha1aId5GrTcsKEKxaTNWsD2clam/7lbO8USTet4s4OYPeKHvLcVBRdo4FTpTW9
yGlzO0ZWZZdzGRd7Plt/6tyVkZf7a0YSx8fFi3hGn/mkm7lQzff6UpOGVwfaI95UCUIgE4QAGKXA
BJdphlEAvUGjCyUrgttQMg7msstBKlDZbql0mV7Snc71ia3ZlZyWXqTGVmXewyGP5lhT7cjOQXjE
w3q9/Z26bkJM1eUD8zLcaXVhkhH2OfhzZz0BZIwPi+ayRZrVXUpKlz2N4HJWOXLpkjdqdOZVrshP
1BFzC128Xpku3EsTKrOQmxrO6UZIKCAkZORTgzKWq/NOXmEq1yfK1e5SM8wq8ZZcgzmNKApli0Eq
zI8TWy2PK7evev8AL9igmoY4SMo98XImcSdoBBEHleddeoTKFUt9OvcvSbKxyK2qyeRZeUxvSzWi
4zdJbPGlTt9hsTVsEnMXWNiH04wLbHD1pKpGkCJBIlFUoCphuKYCUqhhMRw4xKqSl5as7E0k4nYk
P2hPYZQ4/wCOlJkDxs98hVOm/wCgVpkvkZTqxFXtXOmonHdmtFfiCRM/aoKuV/G05AJWw7RVwjY3
8QNlOdVF2DZVsVQDKFIBg3Q5Hq9HPoW055Jj6dXoW9r5zz9j+3XKBQlE5e2wFdruNp+AJZiOJYWy
76JLZTrKpMgBRskcFDlIUwCMGzeoa7zmBqjpxlWdLLjmnWV7ca0mSnRje3s7BIrsCPnYXIXQSrwZ
6DZ19u5OWQMK5GIAInKToqm9SF4smAalpykYLHpqDTLbJ3iFkUKs6SvDKWmGrRK0KmuoTe7o8hDM
INmYQSEygRxkxEewECcY0M+24yU9YktLqlLADUh0u8s3LWvDTEXUJEsjnL132LTNfovcx4Gh8xv7
/lTAyDnDEPDTNnr430zeatx7CTnRZY3i1o1Ne0uGSftqoWeDraiRPaMQA68aPJXo1Mu4vptluE/l
zT2+Tr+DKVqDLXmlytbG3zWL7svamsE+h4maotfZyFoUc1axN3sOzmFnPbvK+iZPtHjUp45y3rWy
PnRjZFciY3wFKXK2DVk7rk0mLGP5RbKSHYdg3UmLarMyryH8eW+inj1KNjnM0qHZxE8c3QGbqz1W
3bVdY8eWq8Vej1iSxtjKDxVXGVJi5WIjmtIq0hKyUUzkmruekiLotXU47REsUD4qaqKqY7HTMBbK
u9xRBTEKATIKmoAHCmky/Wc1HVAFQTYUNEdZYsJ5TlL7V7znZ2paF9Qv5A4jUyNciBx1LXJ5VuzQ
mmp7aixawdYtKVwPFlMMYFUNHTzlmUvjfrJzFMX1VDy4tOyH6MvFuMY604eeVxScs8ThW1y7DUsp
fHLWXc6isfYjmdSsxXFMOGlyipiB/UHtRr3brJzEiKiUu3Gw86KxQ+f9vkC5BV0qENqsgUdjZlrk
1o4zsiFQLZXbeMbKWMIAVvCfWYsTAtmBpruXigGUTSF/uYoCcjr0iuW5CryKFkrFNsmaZjEjvB7j
UpOrTS+W/wAlssrORC5G7pCa8PNdX1TknlKkchkYjce5jANFJgO9tCHNBi3Yw8BUlQCVzUlplsBZ
z2HYu4U4LB2FI93jDsJCC6aEuZpd+MqM1a20DTQzmSbpw5SgZ7HNgwsTFEhlaazbD2ez/knrL+NW
fN5jEk6/ka3CWkc6KuIyPQi6NBwdhTWWt0EkjLmPMR4OZupOGdJk5paveaJ+rWuoxlboc5Rarkq5
ZQeDkHJOrQW7eXQrdBxfBJqwEtiisqydNC3C8m4Z3CiSWCePMiktywmTXPYWtdRxhC4jxnB6fnON
XtMmMHdycylQnrRIxTqDLnpzJTDl9bW2elJWY9jJBnxbOYISLhwUGuFTf8SFkLXLi/JlciI2z6Pc
YpTVS06zOnqhmiL3Z46l0szuNs6TTKNfxSkinXWt8jpyXNa38y3cv3r5xCxsWdcXhUrCUkOLdUoB
QjHEeaCEgMGYFy7tJ8y0gDKq4N5WB1sLAU/2v99KnMWIOA0JYJWxxTnrqLt8sratD161OvsruLie
hT1bv8FXr3NwVMhcCnIE/N0aFNXa6ZC1N3a0dKg+kTkdKFE48Dvpd034Xz1TUyu6lksXqNUylJ5H
zEN5psRC49stcp0xa2iUFiZo8mrdlOnwEbC1VpNqsHUPb7B4s8LFsjgr7Wxj/SGKrxlWs9uw0wnM
4Y+0sTmk6p5MaXmUgIImNZiFuFfiZZ9juLgVY11Ow57bMIokNKitKKpQyaYKHXQA0P4G1OYkwuFI
vLTAyqufsc0u5VOn5GjMhLsK/MPJ6Fn46vWy+0iRi5NxaHcW/urxu7aRthjTSMTX2CglOikBitxo
1xN47ASTkCJOXDEIS7AgBwSGDkklRqtF4WQ6mZtMsHHfrnYfsNYcvGdbm1pVFj0AAI2SsE7ZZATR
tMo+PodwKtkyDb5lsWbdU6n090Ay0o5XiJecWcAMJSq0/UAUuDc0+aJsc3XFVWvt3bZryM5yPkG7
w9Vb6eo6sLQFAx3iZOrLZRzDe5K6KoSkiiCNhcK1VNOFIU6ZTHulgjyAIgI8pqLuUdh2GxLjdFzj
SnycNLJ5iXqkg/Qd55npF7LPm0pkOWVkAfTlcaV+Sa16Cx72r2pVZvJoTLKIepTkyq1IfTbrbpWN
8V1bGmTallKwvMbZReZDx5K4zyqtj8J2CsxYp/dsN5IQSRP6046yG6r0R31jLhIPm0HI210YO6yD
A4qXSF0Qm8K24WSXbGSWMpkEgkChYjiC1ojovMmU0hR3y85eLvSyvUb6NTUdgOwXuIbN4fL8fQMn
17GryTxmM3Y5yOkMhQ9csNFdy1J7srNwkVckLgzhUHCLSdQLa4lxFNjHkG6iBNRV9G0PV8mz+Cc9
s82z2a0E60tBUXTq0xbkFrBNpAN5wchzcpbDScPMxfnJVGIgTtGQdXVkSDfifaV6WLJ9TtuWNQRa
VFWLU3mm+xy1utUpNyTfG8FhCBjISOhcZ0+jsZNyZhMqi8ka/PXd6iBkuyhJWNck7dsc0ajlrQa4
yDdbqnRNUtNdPsk1jIdMl6/d6naZ+CauECT9uoUiS1STRhJxL21KpWaMuh3Rp9zEKkZIyp0TgA2u
l26OREu64qTF2wTiSVEJSqWIgM7OHDzLlwGDh2kSJJaihmkADJkgVNXG6ueU6SHosKNA5E1cQS+f
XmT4DTLBVWWjaZhiBjLXnW3J2xXsEIM1ak1oipFNT1vob48TWMMgt9GiJD7l4bl89FBNw+UL3AU/
KSsxRsZacaXqYyUMnFGLmuHq9uCUGTxxH49r5HMFLZtTCEbjH1OQma60UC0Q/ZTgjKs+3li6+lUx
bltbWfD2rGF/xZBaoPycN6ndcWGqMtkeASoRU2ke1nEpqw11jLrWVgdM8olHTpjnmFQbmKK6nKOv
uPpZoSQzTdZakVa4VLE+QdK1d0uWCfh3MIw1BMlajD2V5AZpg5KPnGVUJkaAtc+Q7WHkJw1ekomI
iFmVogEjJHGMPRzjql8SXK1Ahv0cTYQJ/wAxncYmLhOEWHs43wDz8e76b7Vhai9MamLqDRMvVSYu
Q0W/W68Y3eVvKFeCgZgquWqAwbL3GJs9Pj5WXrzyAdwEvTJNtZG04WQmXhplSwVhiJJEbKEqqMii
fsRXSU8tgKcpvv2AR89/L4/wsV1bamYfL1Ixbiqo2TKt7r1Cf3S/W/IOeSxUplK/5mvb2Ka3qVc+
G3CzHYVqPioulMKdAObLKz8cdGXRkpsDN1ikr/XaiRUTnMBTAciYgYdhBRRwg1TTEB8jncumzche
pjLuEEQATqplNk9Iw4Yvm0REhH5AeDeRFd7jKzEO7KiTdh3bvU/i2iUXfGMoQ6pUSl+uJDrACoj1
9kfF9j+7y3+Px4wfnW6ZO3ACo/VHnDbyDy2Hr8Ogjtxs1m6iRuRUUhNsmPKIhzAColBIdgHcAUFR
ME/3xUIBdxOADrFkHhBKUoFMYyZFSgAcwmSVJ2iSgAAbimqT6RM4BynJ7RREOo5eGGo9QRHkzrUJ
9T8y4zt0QoT2etlXOX58eFvHfF+1WDtQ5zB0UAwCUfsHfYdvt+7pw44WSVUOdExwAT/U3HYVOu3s
gIbm+fLv0/g01lVB+hKkCY+9QQEpf+YQAPu38wHp5beGkmRo7THoHY/VHcA9/uH+Hn7+GMQ/uRMv
eO78eesxrQF7pZDh6WeD6REgrEUEDnEOgAICYfdsBfMfeHThqKOE1ObfbZIOm/v6b/H8Q/hxkkXq
sgp2iAESEfiIFH+P+Hl5cakFjGFYpeyMI+QFMURH3DsAb/wDqH2cFdOpy03epbiLCtznN8f4B/lx
5U6oiAdR69A6j5j7uPHal325R3+Gxt/w348A6RHyEo/YIj/I3A8CNT5bvX6ayDEVtKhuHd6Wxqqg
X6ggbYOoFHfb7QL5f18eNcLnmHlICZBBZsbYRKA7F+sOwiA7B7xAOnv+PGVQ5FVlSpHKBB8jcxRK
Pl5D5D06/wBDx4REEy7KFTOfbftdwEu397y+P2dQ4Fatsm4bAfcOY31S79R93Qv1h6fD38ZR6BuP
QPiPQPx4x8x+1EdkwBL6g7hsP90d9h+4fn048qjukIAoUR+AG6+/3B/Q+fHWJsxqeeTyJ+wKZQQ3
Hz8t/ft8Pj5+Yb/hx1zm7Tn+i5fPn3Ly7/b5eXTz+fHhJYob7mKHZfU3MHX4gHxD47b/AMuPQONx
AQBMSG6lTASiJvd0D3/YAeX4cdYds+//ANwv/PxzjD2hxHYATEfhuXf8NuOcW6nxHL7ev7ydixo9
uXfbZLfp05y7+19Xpv7/AHfH3ca52qqQ5SlKQUz/AFSB5n9/sl6839eXnwo+k7XflJt+bB7tvZ+t
1/4fIfh7/hwldqn7UR2SADbdsO5diD8EP3v/AG/y43o7ymeHOjaWz7bGtykvAWCDla/NOq9OM5Ni
dnPsX0jHO4iUV/UPmclForSyZWH9uoVACo/tiTiaNUeM8l4qzBcKJli5Nb5eorwVxP2VhY7Rbmsw
9scBXrcgsExb4+MkZYWkWsi3VNLpNuyBRMDbAcvMPInOYopkOBFlCdikvuAFSX/+oMcR2KT4nEQL
8x4J/VFlms5qyAXIkCnYgezdMxk0sYWGGiEzltVTx3TaJJPY3wywTg2KPl1qW/km7h14Ck5Qkkl0
zGTWIYzEM3ZfRF4eKoLgMyQkMqjucq+WdhrQERtqC5emUx42FJRE6h/aNsG36oehx+Hsef2dB477
JXcVN0uzBbcScwdA38x69A+Y+7pwrVKYVQV5R3HyACiO/u26efX/AKbdeOImKnsVQgnIr9Ydtyl/
vG8g+0R/y4zAh26xDsT5en00e3Lh46qI3ZZeljSHGGsCVtunYjmyXyRv+caceVxGZ9fbKrZmVEXP
NVYQk38tMtWlViDVutzD181Uk128Hi6OjirgggBIDiLctV3NOP7RGWmfvcpaJSfi1mNZypW75L2m
LsEQaJLjx9DwNzOuMkuyg64YuPkyMXapG8IYK8YCNzA+EyMSaxMZ0mL0UT8ywuFouOnJrnWFyK2d
s0e5T1Qyu6tqEA0h7KM0LqbSqUNZFWaHiEMgRtvyewI7cM3UJqOxjlPDWG8NQhHDJfH2Q7i+e2Bt
SYup1uJo9uMolGxsfT63OvEXb5wyKvZLW3aMYlWSeFXdIFsbsH1osvooqLgbqNrFixDKamrIEbmd
/GyiIcUxdmtKUjicVRlRmc2jbDmnLU7l3GEdXsfzEIGP8k3CeUgsePMqVuCLc7nQY5c9llGVEkrK
klLnaV5s5TRUfRKIpoN1zmEE0TiXjqc1Y0Wgscov8mW6uVq3ybRnHy6GRGkfZbg9xhPs6vFmcMYi
ZYXWfg6HZYd7BxE9NryTOuooQjauLvDrIEMzMNZFgcOXq+5AhrNMtrVWqJZorCNpj4rwdVC8zyqE
MjNScR204jG9zocndl4JZ3ISnqq8ViO5meiuiJiTJnfC1uwziWu5Dcwc3a6LijKlQsacjQhk8nTW
QpbKV7t+MJGoZGcRSHKwdOZWuBblZu8V5micLt4rB2AXf+slrr7IIQiLjx4JLABE0u6auZacXzNu
XDjf0UpXMSUSJONO/OQFhazJYdQ0lE1CLzDYbG4in0a5v1Tq8zIRpEG8fcHqc6ayq0sgJt4eTtqi
qU+eauUZHz8hHKEkFmloanBYZbjrNrTscueDWbzNhms74/pdikKvbaNQXsXkTGuPmrt9jmRkqzdm
Bq8aDgGdOQeVaTmkmkedrARrh8uokkU4GvknVNpct7e/ZolaRiy95EcS+nSTxTSJ/Hy7eaUf12nQ
UJk6rZjO3jCw0pX3JULSWBIjcLYg5F3AlbgYXbYFGXljU3GZNidPFxr9gxhG5RncY5Nxnmus26et
1jhI2vSFut7+vRVyWmGikYeqGgFY6YqUXHWGQkq6mpART8CkZyBBZXdSlsPSOJyPh0BmxPB9SA0z
bsUT/wBNCy95Xy8+jdWK6jd/SEsbDZqdSYe9J2GjSKNllISFx9RXJMYy9zrkjBElaw1aRilXoS1w
hbEvIJR9HZNDSTABdtyLN/pOIEr01qGY0LPFJrdOkZCrWM0cfP0mFCaSc6zY1qej7a1JcLO+7J/G
hGv64lMOPz9sDZoHe1OREO04LeXzQxlc+0ybgsh4bTZ0Wo4RStZXlhtdcwnbbXR4OFgnIUpRcW6j
5vVQbnTjxtjOEBAzVUtb8QGJj/XHbOrvjWx68M/WSKylXHmGbZQ83pL3S2TcRXoWdmbJiecaxqUQ
h3tsNgdGyCJY+BRZQTlZ2kIItCqH9ng0e7pQOp0likD1sI0yB+/fV52gQQIsBCXahJ+HnwpJqhnn
tKqnU9sw7dA6iO3XoAf9/wCQuHHt3sONLlVL5V3ibWyUyxQ1ohNiAp2kxAvfFotqYA3EWy6/svgA
NinHY4AbjSTRCitugPTYvUB3D2y85OvwMT2i7/WL7Rdw80vaOSgIkTRMskUViGLsYwqfuht5m3/Z
Dcft67+ZQ6L3AEOOpAgmRDHE5Am550ezooG0sT+QM25rXyvMZoctJfEeQ7e8c2SQUpsHK47byfj7
pOZkHy0TMvimlI6eOskLpqVNRJYFUxEDc5d9iy1KWdzA5qrCFBoK5M5ydVlLMaAi5lg8ipWnIS7l
oNHgq7Ks63DKmbzL9wQrqPKYyDdwqUBTRUMSdtWB67O6kadkjLsjZJzEGRI7GFxVGmTcZZbC+rju
iQruThqoWUmWpa8oykUlWjxB5KEM2dJKN1ikWIYoGfpeqzlDURqbmIdtHxkZeNFeUrtgJfHdjQiG
8FS1bxjqTpEPBrizbSMfIliY6DrT6OeNgsYScVKMHpbFKSylhU2YsCPAi7NF+QsEOSpQBFHJwnLM
WHDZcMRDCAOjk5jPPsz3m1YIai7OOnKM0yeqteJBRmXnOYEriq7sitzb2xeEkYJwyPvJDDkikvEW
CapzQ5UiHfMymEBcoAfdZb1VTWW8K4Ywc5oVXhgwVCu67H3CImLDK2awx02udaTQn2s1KJpLBIOU
1JhiWPIHcF0zwpAKoUyQEHp6s71TDetXIUbCv18oRz/HlolLe0YQLiKGtvJCwQt0qUnHOYJRF/Vn
42JvMz9PcFZRkoyjYR3GxgoHbqGecLJw8d6L+VtVaqDNrZHeqmYqV6tkhVoFzGPq5O49nbA3bwsk
pECqmlWZiv1ti07BYSwL2QkWte74uJk+LGF+kIn8RDvqlst4J4MauzObOBKJdQZeWH/x87B5mjUG
0zM+xAJ6I2qSmI8dYjxg7NAWiVXkLTA43YQ0dWpNysuBixEq+apKqrAeLTVOikc+wlIYwPh/qyj5
jVlXdUKePDRowV9h7vIUNnc1wTsElFx/YmjlraSJB63RerfRSCYw4cqnsLFA3QC51Ww1TitBWii1
0eppVxK+0qXhrk7Gl1SKbSturUmD9eyDIx8aq5Vt0w+AShae2M9n4TZxamcs39rhh6z0anTaTpIh
oqux8ZQLpp+015Tk5AmOanAWBR+rjjuFqBF2wdHeSZ7MmHjlnBOWUGYlA7WM53/+s/EJTHLNfUio
E8kkCtJs4ftCYcEtNmHh/XDBY11hXfVO4oEy/h7ZMZXlvyfxN7bRqTR5kxwrOljl5WQiJJu6Qbd4
lFFCGjRAhW8OYwAVVATN3TdqmpuGcl5/uktSrTO1nMGJr/iVtX4KwRrF/EBerrB2eDfO5peL8MWe
1uPqyzIAPG88gebZJgBxeIgoUeU/yTN9e+JMWS+PqSniSOzfS1E4lnien115MVC/r9pGU+RioeRj
42xVMZb81QRsC0lIKRftpiZLiSsW1vCmQPSlzWIrbiDFSFNrMvnjGlYqUfiuto1aTGnjZggpmZpJ
ZP1XE6QQTXslHreWamFRLlhA7Qg8SUL/APUQyWxSJyw5t2nTSp0nIeyRpzL08zYANPuo+tY3grpT
rBH3SIiprJ1Eyaxt2NxiY61s5TH5JqIZVA51lYtFOLk4BRN+7eiAJmfqEETCYwCM04t1f4ci80at
cp3mt5DSgdRVMyxSavUKcyrb9vWYHJl+jreDx2+fT8M2UWaua6iCpjRvsG25hKPGvqCFSl7FrIlV
aBi6Lk8cYwhpGuvi4ypc9C14lbydA0+cf1fGMx4hXK46nm7RiIGjmkeasgtYfV8XYIyvrGZmn3E+
En2vawUu7YWotqq+X9O0fPUiuzMHBv6tWZq4Ywr90YX5rTXLRvW4t+7UjJkxISFfuVKx4iQa6m7B
UBFmJDvarrBK4kCJ7OHAxzU2E0Ocg0xMcWGowVsDCjCk8Mvd3Z+m60KaZPSO4KwfgQmHrbTMl3j1
VvWV5eIapRlEGl2WuZChJWrQtZvBXlmPIspMkq8aWGVUhoGfWlZN03PDgdRdPnHzIGfdJ18xTUMb
R8fnTFkHXMVFLaKtjWmYtY1nJGpRJssh6/Xyfe5G9YbNDHYuJVJgD6IbzcVW28PEso+su1EKyaUs
J6e6XnnT/kLFysVTqtlSK1aUqlY9yK9qUU+m+436o5FMhTJi5NnQ2WMo7+ej1nBkGi9gWjD+r4jB
EM6ac8X0zC+Nq7hnW9jS50tGW1E4XfRLla6FkSSFRq1ZqeUfUawRVQYyJ0FG7l5OgKx3j3cTQv5y
Ju7+0KwR0iC4vECRALFOoOZoHfxYEsLHhw7ouqSGAoTlg866U7xscmaxMM23CJcUw9Nn4/sZnBNq
ioBzS6U1rkdN4oqKdBtbNnLR9rcSj+LvblRN/IS0pCtZpgkqRVVmUhyiO71Ha5MS5vwqrg5hGZJg
GH+k3H5RrCD+vVR1FUDHa1TnKjG4uoTVreu6IMKw1mIM1MjvCYmqiRmAnjoApQHiYMm6Nq9l3SBp
fyBhSnVOq32OwVkO4ZNBrHqQKl4icTTFfrdgsZ5ZGcWi3sws7UTkVWExGtliInIsoQpDFEa1Ml6c
z4qmISr2vJNZQsVsqeN7S2hG0LYlY13BZjZwsiyj42SBv3WZfNmCSj6ahHMbAwsizSUcxLsUCGOA
I0TpExAkJhBAPabMEVeU24FieLMP2NcightFE/CfV+/uly4aiMbv9IaGmWAlclWawQ+o99k6r3W7
1+NgBiMbjTpypRlfB9F3W1ScVZkJSZg3IRsOg5i92YCDwBKG2k1TZkxjmyYwBL06enYlxUMFYOxD
eJierMm2dpWCjUUa/Y7FEjDTK8hJRrxwAycWxRE8w5bh3hETJ+1we190K41moHJOMadG4UqdvxHG
MnVauZcjyru52qMplhqGK7PO5qq4KjG0OHuVzyDB5FTkGQpxTVBBNoWIAhicNDWVoiwpgXSlpiyZ
AFmZyan7/Zcf5tyNEWxjY2FqlI5V0vLyuLmq06DF5UXMpFXZvj52/jIO2yUT4UpaWrVFRMRHfEX6
DFSuJESFFkYUpBAJSlRBanVDzOcj1mNoMXo2fUUWZyCcgBnrIZP3TBHVzn2p6i8ixj6oVljTK1AQ
DasQ1msrQkrkezMGZ+RK9ZfuDIspYLVYpM/sO2McpNODm9kSibpw6fSO51xjqT1P3HKWJ3Ey6qs9
GVsWzifYKxEg5dxtc7vKrKM1yJqG51voVDcogVXdM2xunEcZj0/N8ToYwyLE2GOyRhnLYz85j6Yj
lZKGk7DDVqU2stelUnCQDW7eH/zLMMvH2Dz/AMhy+fE2eke044r09ZAxxFYaazkXSMg4dpmQjsrL
YHNoeNpOxf7YVFd0mkYWKX9qqUezJ+2YOMmPdr0iHeERUISIBcFJJxUM5yz8JtYwu9y2vR8XrvKQ
JIyac6N62HnSblCDxpnHHc9fGNSs+N4i0sZe31fJYTUljR62jouUBjK3esQMJcVLKtA+PugarFh5
sEBIpsYokNtC9zt03bbNM2OempOzTss8cvJKelZSZmJV66HoDlw/lZJKaMQ3uUM25fmO23Exaba9
g21ysvC5daZdsVqnV69BYWx/iNzX431xyBOTow7qPsV1sx0RrjKJT/8ACk2cLP8AjAb93Krtws1S
48xfi/NV0omI7bIXWlVWbcQjKekWndnTN6yX7rJwTdEPoHrStuvzdm+aRUSWQX+hKYynsgJSYyrp
7QEhN1DAxA+Ms1EyBq7zDkioNn8cH2nPL/tBcd5zyfU2OX0e9KoVgwJqSu12/JlEI4izLpPn3txv
sc0KERSLNLZDYXuts5JKLmX7oLGyg2biVgyomgpxuqkrEO1EzkMOY1owTbqbXkcJzGnLEtzqGoDM
c7ax1E1iutoSz46tPq7+SBF43kK9e3M5AVXw+T79WogVZWueKJeBpu+3JziJpfoWoXMYW/FuFMmP
qzGWBSsNLNRxyTJ0uCyHKy/j3gxBrMM6asbKu48Hm/C0pmOk1GPffoQKBthb2N9LGYsrNZmRrjKu
RbSKtcVQVXdwtMXRmzm6TaFgcjX68vY12SU7YI1tFxjh1DMTryLZB20VWbETcImO7CWVQbsuHdF3
jbESWCkJGFKRSocFU5eAsBZhXiNeIa7xEhCCzFKUkqmkTeQkAJGxY6HXOGnuDfSBVXJFqxBXrdbs
T0FHFbu/SECwkX1rjrHclxCnPLIU0myQIg6aqm8DcocqTlBQdiKpiar9KLkVylex8dMLNDGOQrpn
EvH7cxyHBM5QXRQUSMYhzFIYOYRKYwFENxABIvG2kXP+WG6CmPqcnOoOLTYaq4KpY6YxcJW6GKKh
62qWftDUxHsoQonrsaYAdyJAEzJBYoCPEi4JqGoe44tztaaZljPdbhNOlXhZuWr9In7IaIbNZWZf
oOYiaT9fq0eiFTWjZRJV/CxdjKRRhJpnMB20oWwoJMNJPtEGNDm8kBh2RUtm1ZybgcohwYm0ERS1
N7zMJJnLQEEynutfxp/j/R0PsGaXZO4Y/wBGkxdEKVhWBuy9iYUNG0rSGRn05E5anMhMwdolnchV
mBi4V+rYZ1N9OUJ7M2hSKkTmmUSWR6UOi+jsftsIxklibRvMOXVGwrWbDNFLSm827ksqx19Tv9nt
hm9mim1pvNaPVKYVhaZMH81Anss2WvyLs09DAp8eryVeuHajx6Jnr9w77y4cv0k3Lt4I7dURXcNW
bX/2gX/OZoHAGeLTSAyPXcOX6xY9BKTkE7bHVx8/rxWEF/t7+KO4FIqzOA/+pQWMi0/tDp+QtpQl
RUUwzGeYN3UV4S7gpDVmoEFwzODZaJCiJnHvUSGPlCSMpFzR+B+trkdRGMMXNcbwjjTviLTPbsFr
aR4aeseVrFJxcVf6/kZssohPPI3IZ5Qt0tGQDLJKpR9ek4pGuKKJnTTVE5DFDSek2t8xBaQ/RzVC
rld0et2HBD1peMfQ1nVfwrmVrJKGFbJZo9u6MwdWBgLm5mjXCDTvvPYpHxXmJAKg3qYquFbFdsL5
czpHS8OnC4kueOKnZoqSbyjmVfv8jp2aSrspGptHQxyzFo6pcilJNEpExEVZAhFC8xwAWWTG2Wl6
uhdRol7VootXrlpcVa5Y1aUeLO67i8MlMETeQzpFs+/M3CkK7FNF1s3VMRb2OLRbyiPDiQ4UOPDM
QjEtCQVOEgEGQDkEGgcsaSsPZL/qxlqkACoCU0tnkBzO1/8Aqn0uacKLpu1PXnE2I6FJ1DGGE9Ly
eEcqtlJaTczrvLxpwMtWdS0NZhdpa7cQK/XRRmZCMTjYPv78FOz5lOX5rzEBN0oAGR9ovOVADk5z
E/fAm/Ny/EwAJQ+/g0Z7PWpmSwQ5x4pCOK1hqyM6k0sk3UsSsqbF3plTHUyxrBb1e4uObtbZExL1
VJo0XKd+3l3SibdIyixyEGDl7XkiMSOR7AVhi1ZNo0HqMjg7HjQ7RvMFOeIWcunNHTBulKkTUNHK
KmKV8UhzNRVAphBS9woSY6Ts4+ABM9mzAJSC+8kKNAHMmazdyhRB2rxC0Ix8C1e7yzFradTmhGh4
u065Ydt4qEWyjgGM08T7i/YyhbTH43yZW8vx8+naLBGS9itFtJkCCrhoyOI4l4Or1BiwO7ZEWWIL
pMeFOuPT3oX064mx+AYpzRUMyZ7wnTs1Y0m6vYXUrVancU40C2KgyMVerWwWaVJIxgK8XSLebm3E
eVZiQduKYzZVyH4GFbNfbkSACPCGGuEtc+1rhYkvUYV9Bpy7mLdNFQ27okdkYsZ15QJ58ZrfkjI+
RCxRL1kG43YYls7j4ZvcbTZLEqwaqiPeYuKSlHr8zNoh/bESApEt9jgXikZcKOIqoCcSYxGIthZg
l8LZuHnKecjakKBGBIVFKXOupG8hmIFrXda2l7BOAZ/OWJcdYGzHMvsMUXG9hquo+v2qXmK4gtZo
nv8ANy97jJJ4WsQKNhe/m8VO0t8/mkFwBFBr2ns8G5rM0u4xzziM2SJok9AZbwh6L7AmdW9gYOfz
CyFRf5KUk4+Th3Dpyqq8lioz5pG6KyQToEjmJ1ExBIgD88T7O2Y5qvJ0uWzJk2Vq5UGTVvSXWSbS
7rzSPjW/emjBvWRsBodCPaNfzmMFNN8kdD6ZHdP2uNvLaj9QU344SVzvmOwqWCssKdZGcxlW9yyc
5TYs7wjGmWFg+t74bHWGSkhOkUqkgm/qCR5EhTxRTLBzMR7zBUU3dN3j4Q2Nezmo9WoZteDlpgMW
Bdryma48FncHHwausuLStAK6SqS5AAhN1FFEUwAOp1UiCoskQPMyiZA51CAAmKX2jgBd+LAXuN6/
/wDpmQeWI9RyhYDa1LXj+yRx29WWCSanwzW3sW/9YfDvW9rHowzluwLS3Nllat39dGYCJ5lk1DQl
J6jxkIGXgz4L0yM1pGDWiVpWDxaEHYI8HjDsDy7R23s6yBVgX+gFQo9FfoxNz9OIfDLGSRon5KAv
V1HF5pwlm/JqFikhoJrM5LGlVnfVHvXqyLxMkC3ijKeD8xIxQgCIJnLuk93hxkw4ZUoFsRXKRw5C
v7lzMWPhiq/nqCJP1Zz6hBD1AZ+877W9O/R26fpjGM/a6Tbssx1rHQU+10V5Cbc1ORrzVrAg7jrl
jSfRj46NfTUjOS1MlHbS1R8qavsPEhOWGKCrsbPCcHhyFe+ivyZmpoasp2OH1e1vHj1ubHtPXnAQ
UpdVnG6LPKANxyfCMT+sSyknV4aVcVdEu4qxYF4GJhYtWhMKKZoj7xl1DDRGjnSQtYfyhyRYklaf
RruwyWC1I8LFyBjZw2s4OAoJo0KWZsoRYEOyOUwxOyy/lOOxtKYiYXuxtcWWOcSs87j4kmZamy9n
YNYxAs8evgiYjZ4ENAtGYqC4Kb6RIm+5ygJLzFhxI0dUNIQiAQQUTCh7WlDKBAb/AE36tDMOXE7J
sof11eXy593LWsQsdE0ppei9rN+QY3JDKLzVDdIBG2Gp2PCWFWxxmG8fLOaGtPjKhJGw+iCMPMxw
99FMZB5KqEhebnHhgYB0Lw+bdI2ojVM4zZXqiXBjuvNxpMoxlZFOYB6P0vrO8QS/MPGAH/UjwMZ/
xT/5q7twOtPseqGFwVa5GkucmxunqMtElAWqUrzZ2SixFuyBBQcI/QCSFV6zhpa9VhlEsbW4B1Au
J1vJMYiY8UrDxCQUiFr69tqtKyLIbOypcjMNYuffx5ZllWZOcKyTkmsPKOiFLAvpRtHKpSEVHqqG
dqMlE3SCIoHKoJYjFYiJAUQQc6YgdXfDxAJOQa0BH/uqyyHy+n10NrncGYIxczidAFHdqaX2TfUS
ev5Fy8TNOPG05mTJzfK2blcAuqRgm4t6JJSNR9V63DsblTlk5+pPIi/Lt7jIzhZBVNkaE7T6MsLt
lXVTA4aytU29S0r5AvTHKMdk9KUaWnH2IqvvLFycm6ik5hPJDQIoHzdaNTCEtIHrUF32qWJ5PtrM
uCVS1I5apMHWoSGsxPD6bMPJqjSczWqlZLDjeafNe9eL4psc4ykbPj+zuZn9KsZWi2OCex0n/rwS
PJcP05w96dqM1cxEGs6x3dMutqtEWVS921aot7Q7g7JZHZlZM0vmF1CFSjLyvIt268E+bZYkZuFG
CQWhzk9SUzxIHiRrreVlcAVmOqwSMQLBiCwSwSSXJDnQUjIiy65cASDVATq+j6TpkCF0YTuOJHLu
I9P6Nd0/3en2/U5jjxC/5oxVJvMrZFrVxsVCqRKNRWEbFZEjsfIuGpZdJFxL26CcrT90IzTnTO44
iZTfR0w4KwxVtTuXYfFWPHtmYa3siac8eUrVvb2SWOcZUKkVCGzBPvDyFVdW9OYv9nXRVqUS7cLz
TRBJMzNEvMQyfFR1I1hZIx7YlrLWangCOnyXhXJEBMJ4DxupNUu4sFYkI81FehE92r0JBrQrGTaV
1gLqpJSq6AFjQWVIAqKTrSzhXjXiKtB61m+tXy5r5Rt9IzxRGWX6UtkldI7VbJTeCmV1CMr69SIe
vyU4g5hZEIohoVViFYKZ9xeAuHEi3dMIPDu/vE9t2JchgGLO0yAQXBNqru6lgTAYCmow+hsV2tvR
RHQurjE+LsAxB2LLUthvGWeW9SkFDq1TE7XJzu2xtoav7EuErLscQ0VCsp2GTl3iaKULFlGRfPG7
UorBIOkDQNjLKR8/20uTalmpHT7FUKvQEcVrYKfh295pyzPKV+BM9vb6USsL/DGP7JznmbQ8hIGf
uMQdRxFJKthfKWUALhrf1HXaIt0ZL5Ik1lcht3MbYJyPZsIqxP8AGsgxYRkfguPloMjFZhgJFvHI
qhiSFOnT+zsL84VvlWMJmThXVFkrBre3wNdcNp/HuQq45rmUMSWxSQlMdZFh3hVIBJCehyzDZwwl
2C6Sr6BuzF0naqvMpqJVeWeOCHKFfabkViGQMXUKlYakEFYaYZUwWYgElLFiIMONNjJpf/FueMsr
HZqW0cRk7aMAEx5H4mxDc8yVS+U9TFrG82+w0iz5vw9aZqkBG4euZm80w5cq9yhWVFg55zCMELPJ
x0arZln7xsgrH+HdC0vWc64yoOpaBfVJ9Z6JkDJTrDzVaZYXxpXalW7u+rx8pPmjVVhiTH92nas+
ZT1ld29rY6pXkbBZOzqjJ5HuQix3rqtUvb422tsW4tiEqHjKSxpg2p1Zg+haTp6lnLpzMrZJxtCm
sDhqpldOcUmbge/WJpNzpbSyip8ZUIcySgqIT0gGTm1rq96t0VX8o5ASpeQsR3rJFjdnNe8wYgyD
DvoB1RbjYGygKKzMcoefQaZMlG7rJAqHFEFxGMgyPnIiehlrMQXYPhLAqV2mATkQ0yTIs1CDYCEX
hB7ZM20BHVeh89xsUuS/R/VfKjLQzFaea1D03M+qEc0oT1PZ3GzX7T9ExeMLNaUyWuu5eeSEwivO
lpddRPcqzBvLOLiQ2IzrRD7bxZrv0LUPTDpV0g5Fqpb1PXrKM5meIy1bZKMskPUn01VbU6SjjV+s
2ePYydXaADF6yr0rJlRkrxXGbq/SVWRlW6yJBwzDrEsuSKHgbENMqcfibE2nwLyvjSu12yT9hszJ
/kq1yVovEvMZBnO4zU0Z66sDiFj2EWBxcMQOmkQ5SmANtn7WQXM2l/Tfp0VpVpinOn9e5HG4vsoO
rQhkBW+W2Qnp91L1uUhCASReWOwKum5Xc5MKxjMowuxAL2QZd72C4W0gwxD6xcJn1T2QCwmJAaB3
KjWqIMVJcsp2M9WSPuT3Wr6cqJj5bD7PN0Hf2f3unmX/AIvL3eQ8apU5NhP2afMHQQ3DcPtAB3Db
+PC1cyJBEDqplEOVMeY5Q2SMXnKoO4h9GYntgcfZEu4gOw9UK6xygoY6ZSlUECkMYAApxHyKQwhs
YR6bAUREdum+3GAtKD/JWtVO0AGdtOfN2WS3a++nP7G2udrmFfkROHL7hAen4/j79h/iKVNwskru
Ap8oe/mDb+I/gPGJ0qU4CoQvIb4CGw/h/H4j7h8+MQqACAmEggcPMohsYOu2wh5h9o9f58Fwn4jy
3p58XWOD4jy3DXd9HUd+L223L7/L5ee3n8ff5fPjELpA3QhQIO/1R2Af49fu8+nGvAQH6MBAVf3w
Hf8Aj/Xw8uOdontz9Obbbb9r7P8Arx2E/EeW9PPi6tlmxDgUxzFADfVFEQMBv7ol338/IOvv6B04
z7E37PmLtt57hy/jvtv8vL7uNYY6yKQhumApB7Acxdx93T47fEA9/HgHIj5Dv9g7/wAjcWt1tsKO
3mcofb0/nx1uH7g/V5/qh9T97+7/AMXl8+EAP1ih7ZSH+QbD/Ifn/XXjF311sI7k2L9GYemxUP8A
eCO/RP8A4x6fPgMOKVs4AkKcH+1r7Q6Dnk8ie2+j+AfiX/LjiRSAHtF5e3/Ubhty/YA7/wAv58ag
Haw+Rkx+w4D/ACHjtJd4TshUEhwT+oIDuBv7o77G+4R9/l5cX2ideZevLh52Y1PPJ5E94mQClDm+
sPUFB+obz32N5D5+Yb7/AGcc41PbqmHfmECF/Vl325gHoIl+PxEQAf58c4Eyf7h8Bu9RyZkJDyLi
X29fMWOIAUEdg7IR+ACQR/DfjWmMX3lFXy+qHP8Ay3/oONiuoqYvaKFTKPl9EID/ACH+vL7NOJjC
IAUopj8DByiP3CG/4+X38eoV1yH3d/7v3Wz7dCcQ23FAN/LcwBv9ntdeDFyrWWbXS/o+ssdAVtj6
00/L7ewTDGt15pY7HZafna8wK6lxs0SzcSVhZoQMzBtI48o/fEMDMCpmEChsGygnN2IFBM2/kBRA
RHbpt03+O/BSRNHzNadLcpkt3kwwYfxzkFCgReMpS02CQWa2qzIetq0hUac1jzUWEaSTDZ2+mVZe
FmzSnsmZir04JdIC1w+kIZhpCJOAo/KxPgfC0RqniPpYX3J0wFYqYKnMn+rKUomMb+6AbiO3u23+
7jBzF5+x5y+QdPZ/a6lDbffr7g9/u49rpqIqifqBg8w6gJftDpt8fkI8YSio5UAEwTKYe7cqnTlH
l89jAOwiH7XwHz24TEiNA3labWP0nHGB7xoAvdyh66/Y53xnnTHzPIl7mXjh42bU3Ja41ysoUyNb
TAgzbN4vZR+Z4QE0pndFQ3ePYAjNVWjjDdAouaGNAcQUbaNP0ViyYblgrbMzNutNNvljpVMWUyXB
SqRY6tTDi1XNteYUkQYyryvvWiTQFGjlEx66cVo5tk8cZdhMfjOOsWwEJCW/NTWNaRLWtt48ZnwW
B9ZXAC6A0X8rmHxJ8wnPpoggKyx1FdgbgJunEsycdqfnsPTN1lVp9/iyyRMVJT86pK107m2QFUsZ
KxCP7wTvHrvca3XrSyIjHSUm8kWEK/go1tW13zghEw9Iq9XBd16t2ikgj3SRNifN+AZhKyUROKLt
FRVILUDNUTyb9+IYOnCrVy1XRaguMQPMx3q+vIKsYwi4+4OqczgXiM+pKXl/JLtSKrKpRtNSVdmV
UleRrGJqPFTEakMqWwee0KYWvVezZdtOjxrZEl8z1rA2FKy+vMlEsmMo2p0BYredpJyiconcgu1g
jJipwkS9ULBBHyBJZo8OmoCg174VseawzNT5vCzZaQzDDxbtjWG9Zh44XK8ZGVS1R79UkSUVa6rz
Y6jZF9NSyccYjZVg9WcrEK1XOSZcc3fV3giwlo1XrMwhN3CSSyzHUebqcXbkHknXE3UwfI0PGPTy
McRJCFZPUVVGypkEiNHPOoBG6okno693CJD2a7rFX8xSXqJsJNwtMdC5YIqkU7IBJ7+57OKyaSI+
uYRxtaiRq5spWGKyHc700XvDEr6sUulZLuGNLFFV3GhogH82rEpVU0zcJBvIKgZkgs7bHSQSOoUg
l9F2mSVzJEwdVtVpNp2LZK/EW/US1zJi6ws6wjL00ssgaViHUGBaIRzejFraA2g7IFjmKxIJnAgl
wHDfUXnyZqVgijskLElW4i5QczfndRcy1prEPlOdkF7QxkrjHSqiMWa3TDywPCJPE0Rag+5yhspu
OOL1B5Nr+JrDTIDGlIiMeWp/SG96n2WNXLZpeV8ZPWstV4WwP3hwohVQXkWZZ10xhgPZDv0As4sx
dLhaZRF6Khvju95d2oZUw5kFgHehZ2YtYWwjf3VZafJz+ws4cp4WxljawM3ljhMytsYTLK1N6xYK
7asZZFG/WWEm+6wrKtzcdIR0FHQzZz+bSqL9jNXhsv8ARLxxD+xxs/8ARPoLzVpTNOT+63mqQl4i
ccou5uYgK2vcKraLnSK/a1qhZ4Bo5iIp4rGPpSSSdmanKs2WZuyLFIdusBdHMaw8mKEwYsTG1Dqt
Nw5e1ckUmoxFXn4imz1nlJsJ96sk+cSCwJxL4piqpNK0q2TWTMBylEogPEasNQ9iiNSrHUbZqoxe
TbPIn5TV6ojLS9ZiVJdWQRXIxaSQJnn1IZjYnDd3HqEbigLRdGFSH6UiQwUXEdqGZ/Mc8JH5k3mb
MwocVfbSlfF5s3HQ+srQvlGjOMd3u50h2t2y9Vs0/WVVN9x3g53wcjk2+wgmCf7Y7FD3iHkEbJHH
t9th3+Gw7j923T/MfiHEuZtyW5y1k685UeQURX3d7tMpZXdfrpFkmUFJzbpCZURZuF9yOmfaOmw8
xBMT85QHyWT5ojRVL2na8g7/AC3Hr5e74/5+Q8ecWFw72MTgOPNi2mcvWx4fWlTKW4WKnNengcI0
7BlmkbWabcZ6xHTsytWKNcLGxEKwsscKbWJkJxOxOF5qxtj7kM8VhWsaU/siUB2AJGxronyvf7zh
bGkPbsdsrpnOiq36CgXdgn1XlMpS9cXtsc6vsbV6tPM4Z1d6rDMZ+pxsatNWITOEHliiqgkqmqbV
Zv1M0/NWF9N+P06PLRl8wfjprjg9mUnYg8XZ6mfnEqwRAxfiSSzDslRYCEltsmcUx2IbabsG63KH
TMs6f832SlXtpkbGr9VllOx44fw7J1l2qtq+jWYt7NFWnYxFzaHMk4QC2g/lHcbZI1dGbkiMJ5Qj
A2x/9vN4brqVhDAqM5As85S8eAFjIRERD2YQCPiJLtLIbiaaHfaFqRpcu13veSMd1TJlQRTxni95
lO4yy7y4MoT1erMjXYeVYsWkLATc46moqWubWLkqdKNFGjGRjHbFzZEnKEglY09EwHf7+7yPU4/K
9BhKjiq2wsBL2Cy3i1sKJLTs6pYI1nNVtZlBTCDiNetao4VaWKdhK+1cpTLRRJwcrpETzVgDWHQ8
XajNTGWZ6MyWeoZyx5m+kQzGvjEvbozf5Os0TORXrY8krhCtXDGOhYRlImOSTlU03yyBhHmVIIwj
iDN0DSaBqLpsxL5CBllmv1KNqbWutGAxStgq9obySMhbdrfGmjgCKZSLTtISMnwAZZAm/wCcp88w
IFxiIMOJDKAC6SFKJc4Xd2Hdrlau0Og55PIm9YLTtnzI2n6dyu/yvUyYhxva52hQFaumTLGs/kLD
WIZRaVTx1FLoyUKo7OikqrX28jNQC1iTTUUZEcEIYwJL5gbUElg7F+dbvk6Bm6i9hDOcc1aTv8/K
X+CrcNJ+DkmI1lLtUIdhU42V3ZMYSBmHlmJHfUqHIPHcFqKr5dGU5pxkVrwezK6ho3LkERBBBKis
6irS5mrPGCrkLiEvGP3sgsk9TRiag5UUKqmcpTAoURfuV9T9LyRpF024QQJc1b/heSuhJVeXhohS
rL1i52IknDsa3Kku0nJShY5wokmYs7CwIJqHIQwFMYAGIiLtD6whkoxNixKownJw7gOHaZm7A3aK
3ZFNTu9fI2Z+V8VajcfVnGeoe95fCdnrLG48lqsqxylZ53LVRC/VsbPR91Xi6bpnJuqvv3dGJsjp
ZhKfRpFBXpw4rfhXV3h/IVDuB73a3OZcp2ptHQs9j7LM2+yUvkCbI1PIQVgszKwspmMujhOedHlp
SRsEmVIhFDLzZSlMIJdTmeqXmSrac2VSGyNJbF2nnF2ILkNggIhjHSFkocH3E4tm0dYJprY6+i8H
so4JSKQeHh/pk4UUPa4dV71K1qY1Z0HO0DJO0q1B3PGVumHL+DIwVj3EJGwhMhuo6AQVmzA/enIc
rMCI9oqYhilARKYAZu92uEVLxMSJChJeSdWl9XOtpQmMqeFIoxc7p/XkT13+i1rDqmY7dRmjmTYZ
Cl6VZrlfLNF5DZpQb+mRUp2lzsd7trqW7KyxLa7fmltGZK+ZrSn5m0Om73T418bjjWvX840SMpLv
JMnmy612JXoFxptrXkXk1Q3MASOYS0RfkXzhNSoPqsskBplnJqRUW1VTVFymkcphn+j6usSRGtPU
JmS0T9ieY0yUxzlH1h+MXIOY9hG5PsvrtWULXWeU514BI4drJMU4aWjiE9t/AWIOvDwcaqaAjnTR
bdKTlh1VBwjSqTS8x3mPdXGlUQ0PCOIUj+n44joSNaySVIXhElW/qiFNiokSJqB4ZsQdiIRdzdS8
SGkgP/NUA4ZgVASDs5APA2rivtMST3D5efHewb0aN1bMsjZLo2P5S5M75AWI9myekW4QTRuwt9Lt
TSopWGUmLDMtI5eTG3z7lGHl2ShbGuwIp3dmcpTBxytUzW2vJZaeU6o2yWkLBOy1Ny5KP4OvS0hY
7E1kFrLN0+UtV5Ms9tCwS7ZxJLiykZ1dNNussoUpEjmArG+dsJIZR1dNEJzDFzZZJzgnnvGc1kML
fE4zlI1GXyCZvAzr9pCN7CxnUT5FjJaGhVoolYi5OtW3xWygqf8A1iV1TPVDmtXdOybB5GwzHU6g
yOLoy2ev8pMw7NawQteQq2Sc6YfI9XeRT8y79nIvYm5uAZW2eJLN1EKcuDlMTsIuV0VCuyjeUBcc
TSIjhLYd7nPI+89bWTtU/wBCGXb3ju9T+JsGFXzDrpYYonqxTZLKDXFGOvGqdYFq5AqxyNTbzb1x
LWKruLdFMWklXBkF4RkSXYsZQ6pDrolXTKKie8aWa+6i7xjRjN2apqzNAhEYTH0blFfG8USUSRpr
dRtAVlnlk0R4udzDRCSrJdVORFVqZNRNQCCQQCyjPuo2lvdD+Tq5jHJkMlNSeu7KdhQaN7au1ybf
8P2ct5OewzsGnJ9/dR9kLMwZpQs40axbgrQBh4UQKUStfUxlSvuPRgaM6zVrFVI+cYGt0Bf6jXbg
0kLMtU1vFZpkrYaqym1Ss2E9IumsrIC+BKWinblCCUUTWWTRNk3lSEoEJN8iqZTYsKcQmkvnKgIa
rVE7NQURDEbYICPicyDCWYej8ONgZteW9UbnHa761ViXg4G7RUFFzuUz45PWbVk+vs0mr2Eb2fMD
UBkMhEfoEZz5Qscg6LYXkTCrKetXMgYc16zPqOV0947wLe8ZhV8T46uYXWCNLYxkqtLSE9Jt5d09
ZWaxPABi+SmG0y/cSBGKv6dQbuFYUDppKGKXFkpt8qOk9lD1HJDm2Waw4poObcsZQtmXUjQEHj2M
a1sahpwxDAv7dKykXba29uTGUkV0q7Dyjl1GLQSqXaoGRLH+frVOY+0XYzgbZmO55kv+rmXhs72m
UsN/l7WON65XI+djq7SmERZJ+emY6xy7W0JLXOYPIpRskjBvlI/2Ga4p9e4cM4cfSEaI5TVKRN0j
I8uO6YOz2xh+zIbVyNBTweY3tmCeVc35EzFORU1fpNabZRKa7Ct1pEAYUWtQyUimotT6DU4+WJG1
OqM01UTyULErR7N+RRMyr4wGKIyVqn1VZI1QyWO5K71GvUhtjujReP6tD1OImYmLRqsKchE1Viz0
nJO3i3aKpEDqf2lEy9BMUBlzWwyr0BWsQsrpB4wqmpRSHWNl6DxOm2UiAZF8G9WHGS0GMZH1xhlc
OyU9ZK1XV5qJa9mp3uwkAh9px9I0tPr6XvRszt3ZTbS3SuFr8xsHrKmdC1uXUFMVpuEhNA6cqC5e
lXdtUR7cgqFVdIJjsdZIpl4t0i/64LvyYjkMCQMgS0/IOz73DW0n0e8FBY/MdKevCVqnqVcnVOuF
RubUxlJKoz0HZUEm8pKwyz40FIeJFjvF4WSYTrMpXX0QyPfSlKqAJmOB+nG2vNyc3+12a6KM00lL
XOytiKwKurKMGasxIBJLd1ey8w/RkdnX0Juc83sr9GPt7hxpaUeOC4VfxOOdycStZa0zfRMU6btp
SSbDI88g2jnsh4rHuzuSe2CbeKUExNjbCXrxdLP6IccTuoz0hB75JXlzD6a4Nxdq5V4mRaxFnyF4
xIio1JIzpIBIi0a1KHOdWIgDIJlHmEwB14UhwIsVAhQ4pMCQ2LdVyQHGbEz4BqTDMSNd4K8cVLEG
YG7C0zwn5WCXSZrGdaaa9d2ENVXMnKWW24zyDHTEXaXdWeNZzGni/h0dOP4Vm+NNY/lfGX/eKU4O
0j1O7uPzseyU5d831MYksUBkHH1+xdcRoVozobOFSQpttj4K1QMo9ZEibHAP5l3GyKMy0l0FCHZS
EGeKIxKoQSHKBijwfr70WGFInKGXq9JX/Jreo0fTrSNUEB6vN4J5Zj1GQTm1rFVHh5ZRJIltMiom
swmTgEeokqmoTcpwEQwx/ps0q2qoajMuSWY8gscM4hu2IqlW361YiY+wzwZL9cO2c3BkEXb1gSrv
qobw1RoUpJTsFuzE/ZH20YCOk4SbvDh3m7CFBw4VydQUE4QRQdoTbiXBAVC7vGixonYMdicLMKF5
51ehLZ5TZoyznhXGOFs1X6/SjSOn4DVBhHM+OsSxVoZHus4WksLwi8as1bK7ePn7Aq0xCIvlGr9Z
GSVZgmcxzl2CGtLOtPGOGIDWhG5Lrt4kQ1S0IlSixx8Wrps6w5fPLlLqv1m8/Y0CqpHWnHgRCxg5
HB0VgbmOKam0mYC9HBWNQsfkperZheRk1U8k2Sm1E87j2RjIKRptVq4W22Sk7GOpVK2xsrJVL6Vl
WHLNOHnJANp1yzNw/G3ohJxXOVpwpP5oiq67cXOXqWG7YSJcqRmSrFC4/YZLmGUk2NLeL1grOKWr
qVoRhoFyZwnJvzMSkIoImBEg9JrUoRNmoyWoEESGGYIEx1cnchUjMCIxu3VIjxXkAMKay9JcBnap
yrY1hrKySlVMzYWqBlkgX8Et0re2ss2QEnaAsqDagS8SRIUx7QFDzgJiT2gNy9eD2wLrFw3ijGLX
GuQJHUJbnTKmZBqCTukysTzVSbkekKtgzKKlyqGQsb0OY/8AnSmIQEpDSXlHxo8RPpu0SIai4GmT
LLJAVd9cc1qYWYtJKlISzKIucnC+s9elPGWt1F06r0kxAGMhP+CGeVU/0cbWbab2eAOmmTmOkXbA
yiSirBy+YOhbGKcRXRNyLLtgII84Jn2Iocm4EP7JhA3AURLx0SLuLpBRAN47TFSyMRaRVSehBFWD
CzcWAmMxXFJoaA0A5PfobGBhzUDjmmaV9VWCbSS5L3rNFlwVYKTI12vVharRq+J/WcJH1udyV9hJ
JuMiFqL2fgkHYBU7dLl5u2JuaeWvSSUrIVQxvT6NZ8wYihKjpbY4JttGrmOMXTkDerTHtvDQWJOy
96SWY1t6mPiz4QhAeeIAB1YbtNzcDBp49HpkfUdD4fkqDkGgxzjNEpletVaKshbW2ShZjCyFddWe
HllodmshDNZlq7Rcwz5tFz5XiDkqzYyia7k1oddf9F1ne1vcPwKF5xGhZs4YVns402uvJrIsiDuh
1cAF5Cyz1lUzVxlYV9+sA8eSrQd//ib3cRBR0lBU5MNRWXDhImoAmQr1UHgEqYyNh3pcJgIijDau
EPTCA7y47pClp6zr6SKo5OrsVUsaWi74sx4Omiu4bmsVFwnjSzMbLeohsMc8aoTsjYEyRtPcJj4u
SzFULZRkAKJa2Jg24PXL2dcaYK0Z6cHWc65YrHOaitCN5pjWINUGsm6mMpRb+pN63c7yFndR0f4l
U4uynfMZkHUpZIFmcHNdZPEDAoNIN90JXXFLKmP79lvBdMfZFws1zVVYKyXC3s5ibqb4PzKsIS7e
iS1ZLbXg/wCy1ZKwmScf2VjP79y90laqL3pmkdSUpPLzWKMdQFcs5I61TWQ28/GVe1u5KDj5quRl
uqjOJdsnwQz4jpGjTb9A5m8MXcRVQAxoy75FhRoZQpAuxASoIHXJGzAUTRyqTEkkDMi0RLtdUzES
E8i+0I+E60lpJ7Q800j6kXbZGSbYml38W7aBJkVaT1OcmUbG+q5IZKyHA7cfcsAimPXYePoH1IZE
wHh/R3jk+aa7FS9z1Hej8o0DXoRajPZidsWZohBotG5NuMnYI08Ws/g03zJV9dZOwOr80TdtjwUS
/KukJ6WMg6Bsv4pjHi93yFg2t3JDFcHmh5ixfJMtG5EcU6zdGyKCDmDQqFrlG37UNE3WfXL70unB
v6qNCmT75px085yxbf8ALmVa4hprXzLZqhmrLr+/zNBiVVYGLtTnFsW6YM3acbGIy8Ke5tk0YtBR
NiBjDPcuxYVdBC6PhBCEJiY0saYiRe2S9GPs6TJnKmD0Il4l/wDNIEhIGfucH53NGWpzWNjdnH4z
qOMWeGcv1ezaUMe0nOZX2MFXMqwzzXpucJZcl16StjepKHyU7gn8I3UyMJ5gBJEbGldoaC74TWW8
9ej2l0NV10iBwrLY2yLp0odX084Kjcfw7e5YyzHHRakZKv2VLQrHq7j2QipYh3ilqhrO+hX4JnOZ
cwEHitC8+jb1T0Oh2u9WKnQDdCj49ics3mtNLOzXvNMo0k3F01tVthCqC3aN49qBnE6EXLTjdigA
rOzpJhzcDEywVlB3iZhm9GCOGM5TJ7zEzGTB0kJD3AlZqtqPHKsQKLrwQlVsSxjSo/QBJAJRU7To
HQ4t/ReBigwSB1gxM3KIjULu0mPZJFCLWXCusQdVcQGQkc+qCeOfcN9rMtbdtwRbJHJF/wBLlq0W
V7Bc3iPHcRFYgf0aAjMsQljJC90sTTGlYjqUtMUO7JP9pF5NEs0cmgl9OvOkT9rimpxAWBuILrV6
wM0ECGUXWcxEggikmm3F2c6iirchE0yNPzkxjiUpUPpjCCW5uLYL76MS447nbDiuw3OedZqhMSWf
KoKQdHXX07PkqXUS5Fl8foZhmpJCxr34tKOna12qdONWknKhY9RyUDFARdsUVrtYzS2OLBPakFXy
2J1Mmnq/r9a59uvg4YpSUfWMgNLvMxR6E1iElWrlyV2LdAElCqxheQwAGNckXgJvESFGuxZJAhMs
EGQUVKJM64iZkEl8phxUTCY8SNk0QBLTDiWe7gWsQUKlRX/oh7C2VkcdflNiNcZbSmyWmKc2yqnj
ccVU2GCQTjjTZZ+QrY3Vq5bgioWbeiybrFBTZFTlK2tp6Z7ThtGNsFO0zoyMr6IzLmUZR8xx/iGG
twaiKPMXmOpco0noVFhMweUY5oyilVoyHeODyaUk0UBqcjxU1prGmtIlhgtHFY1mJ3yhzNWmsrNs
YFoEG+mJG11+aCtsrCZ9YXjIVmFanypSUa5NBNyHe9hIsFewEjtEx1dD0kMctBlRvinO2PbrIYg0
43DU5elvU3IMYwGBo0OeRsVPj5OcQauRyWydpnSPKlg/BZFYh0zTJjlMAVhwyiF0ghMJCg5VjJIU
/spupSaBkqJjU7YYuA9rbJPxl5ebN9vDdY1MOwbee9DDqlSaIxi83Far6nOseRzEEspoJnWsWEnn
Ysyu+WRYxZ0FSJulEptugdJUpzlEhgK66DYrJlL0QlvqePMW4Znpulaj7qa+HGr1ivyVcxxT9NzG
ScZccyC9qhzluz53HSSMJbHwyjh8tHvUmzdUzNUE6Tq1CWqzu3cZVIuZmngxExan0ZBt5CRVJWq9
Xl5Kwz0kmqqnIuG7eOhWL96+WW7u2ZLoOl1U0FSKCW0NowzAZbF1We3Gh0TImf8AGkjk/FeHrRM3
KJyHkanJKSrOqjXmkRTJSiI2PI6zOQgMbQVtuUC7tTOWQRkkK0DlMp+gQFADFDjKZiykh5BILu9M
2Ak9M+2afjPLfjw3SlPS3IaEENMGqVPULI2FpqEl4GEa4RVTrruUUhzoSwuyrVNzGW+Naysl4jsn
b0p7u6raG3XrQXBDqY8tIClMeY00JLxx9RAUs15dVbKP5AHEY0xC5z0rmiMkphLWEzcWSvuZWjoa
dnNabWV4uwsiTvG8u7g4+wFqqnh5vnjdx0hGLrN3jR0zeIOFiuGsi3WaOUzNnRmLkqKDghFd271M
7RcClEUXRTN1AKsUSgY+EMK5mv1frlbxrnqhV+Zy9H201ZwUfKc7BXbIbWOjJZCQj04KqRFhrLNa
zDASkM0Y5CnIawWSPZxJJorUhkgFno/CcX+lTDJJoolmAEgQCAZnccRDZAjwz/fU/AapZzn9NbWi
zek3R7qkyHnO80paPxBRILWJNUbGk9SJamxWPNUECrF1V4bTxgSpvrbDRsLmNCReO2lRl2jNjTWT
q/skX6/atUCcQliVK7YclnOoeroZdwXp7Y6s5Gl460NY/m8izeT8pZ9x7E1CThqBkxNTkjS0aXaO
a1A2+eXsFtepx0u8rtOq0hPrAkYKMRaXc+5boVbt1cttSqUa0yuOKcRwt3yE4p89actFjohc1cxW
wI4kCLSwShKswGSjUWMUD1FBqMj25iJjDU5qT1Z0Cemq3L5y1H1CyRdxk5q1Q6uVchwD6CviJo5O
XlJ9gF4jHJrEdRpXiKvyJSckU7ICmngMQNqriJuMO7Q4kJMIxzNQJKgGkQZTLhRdxUAJcWH1v7y9
1N3PeNTayrC+keL1GTttznqcxtFY8jMza3qhpTUoWPpKaxBN4rylkoasvNl/Jo2oR4xavR0BeYpu
B52ZYpSNgZd2sfh8qT1i4CtroovD7NOoqgQ0uxb4k0uWa6NMn57uDSQiqPVqtTG8yz8cfx0bKmM9
u1oiFUgqdOrK7uTmpJRODjGjiBMV9wNzHU1n+LfTkpFZyzLGSVss7a52aUi8pXyNlbTbmIshjLVY
ZBjb2Uk5sbbuEHvLSLt0sTw026gdiIg2bHnfL9rjpuGtGWcl2aLtlo9c7dHWC/2ufbT1u/8A6qsL
CUnVYiesn/8AfXzmdk//AN/8ExebiIpiGGg0YMRmKly5MtA+XWNrte5M2WZ+X0+u615WkbHGibI1
B1uZDoFXn42LwDpOgoKp3/PKLG8TcRebFKzyNx1Dq4oh5yXr7Z7DtnEA/qcMwXsX5Oi1RKciiwlh
mSMVIRyHhzC+UqJo0YyVilZK+5vmsy4Nx/k/FuNYmqMMkGi7zVKVg+05SxmY8RPT8MnZZtVpe7rD
NJvK1lqbYYlBzZpeIgSvafank+60d2/fUy12WouZiFka5OLQE7JxKkjXpr/4hr80dtJruJyMl+vr
DDvGU5U7d/6xHy/Xh5BqRzatYoK2nydcXFqr1U9Q4GyPJqSLP1Wp8rhHwSoSbRyVapMeR4+T7tV3
UYgD59YJnxETWiXUmW4d/uBK8cNAxF0hycIwQ0sDOTgq/wBx1JNWVLrmW4TYj0HNLHXujm3aetU1
R02V1OoZl1jw6k6vkGnXOlVS26UISp2PFNoscdYG9uyfIQMvdHlKqajO7y0hb8dRtAqlmrz6HaSl
qc19onbstzq2P9S83pn0L4Uo+KrtqagL7e4/Leo7CVZpNDpeQo5YlumnzCjw1bDGze81/FmPy9tM
5DyFGVF/aFKPaIyOKatT4SNmr7r2rTOtXf1x3F5DkRd1CAtVKrz+cjYS1mb068MJOIulMMWdjZJw
4pk21nnMY+hJ19NRCkSRQYdgCJREN5XtY+fqlM4stNMt8bRpXDcpYJnGr2hUTH2OC1+RsRHxba7I
0oFYiEJFlLpyU/EzMfNO5xpMxkobwmAMks79ZxQ7xcxd8ISFrlI6kgTYvhozF3ebCwsS/jP7Yf8A
x87ExqQ9HNYcL1HC2SKFlerZWxxm5zkSLg5ciR4GTgLHi+0qVe1O5yNrU1ZqcsxUdpKMmUxV7S8k
ju0lGxKuKxDELWHPsTxszLw5XDZ2tHPXceoqiqmq1VBvt2D9mqQwkVbq/wBmumYyZ9tiGHg2sha4
dQ2V8Yw+FH8nDNaJW5O0XJhDUuk1moKRDiwjOTVpfRkhWI9DwCLlZEQmbhBQpl63IzYhLMHvrWPh
4ga9WOZc51DAcTB9Mpvuup9mwiYfs9/48Zl+MCE2CBFS5+ADT7MHza1YURUTNvP008+L6tU5txL9
FzB5huXcNum4hv0+Xu8+o8IFVQ+l8uvluPn/AJ/PbhQDo6hVVDJkARHpv038w9/mPyDrvwkVOIoi
YBSFTz5AMXn36h9XcR3+7z4TsPZfOfAc5cubYDCCYcoCHP7j9Nvs36B/Xw477bcNwIUQ+Pu/Hy44
Bjq/7r7xD+Yjv094fPjAuqomPOUqYp/uAIb/AIef3bbD7+B7Q6Dnk8ic7Mannk8ifR1e0HlEQA23
QB2D3h7txH+HHo5yIiIbbCHnv5h8dw6fZv0/DjB247cvKTn8ufp5fHfy2/rfjh1jACpDdkocfI5R
KYPlsYBEB6/bv1HiNodBzyeRPtmNTzyeRPN2xN+XlDm+HTf8PPjgCBkgADAIrD2JgAQEQJ5biHmB
enn5dA+XGMBOIcoAmJ9/rhsIbfaH8t99unHDHVSFICkLuH1gDz+8PPp/DgN3qOA+ht2zGp55PInm
ETp/UBMfh1AfPz8vd9oD1+7hV2xwTEo9mB0vqFEwAI/3S+Y7h8AH+Gw6zvAbCPIbYPMdh2D7R22D
jMkchCioocph/vAIj/1/n7w47Zo+M8GHyyrvPjwcllCJBOkO5w50gDYoiHNymHbflEfqj+91D577
cc4wAtvsKZREyQikYS7j2hQDcDF28w3DfcB28+o8c4Cx18uHofHdYYhtVRPhu/NjvUcJilsAFE2+
2wbCO/w2AfP4fIfhvxqFSmFYNjB7Q7F229ofgGw9R367efXby4WLuOZLsigkmr22+5jFKO3x67ez
v5iO4fDfjWAruBiAICdJbchw22ENg6lN+0Hx233+fHsYnUZp03c0svsxqeeTyJ4QEA/VqEPydExK
Ypucf+DlEeb4jtv93BjYezRUYLTFqEwXZE7EeRyVY8aXOhP4Bi1e16JnKg5OlKjZXclNQsogvKQq
ajRIsDB2A6wEMUgGAogAbOO0UAVzFIkVL6hEx2E3yAA6jt59Pu8+Cm0sEaytmyPEniIKdmJfA+XH
FVPZIdrYG7aSrDGJuTx6i0kFX6BpBrDV2yJMSkiRV7NVcxAEpFBAlxUrax4e1URGEy0wZMzyyz1N
hr69ZUpuDWHh0yTOqqJlDFAfITDsA/INx2N9w/y49N2ySQogBeoeYB1EPt28vduHXoP2776VRImu
sJSCJCKKpJpgHtHVQ/XJkAOplEf7UgbmT/b240SZTB7QmAD/ALojsYfPfpvvt1/j7tt+EELJLKGG
eU9BSWdqv+ph/ps+Np8WejfvlYndNuSWNRf5AgbTd5SsY8v2J7zU56MTc2B7FWGRl60oTHDp/Wa+
ydR0r6s2ZJWfTNNMG3gTdNR3XhepkMcC5xlqVxPTMa0uEnoemvl69i3KGN7s4UqrxzkqaWfpZNQp
KGM5gVRr0fV1n+UKtab3G2qTr0m+dwEy5IFiFtTTPBm0OU7FuRtUGIqXmZGcl8fWicfwctGRDsyS
spNyNcmWdISOu0l4rurUtpWSUdbiABFKJrD9CcphNLEWjXFL2qWiayE4XXlXWpKX0+NHjK1jUk6O
hHtV4xpOsUA5vXGxzlufxhY2GkwTeP46KXO1RVIgfk9L0ab/ABrqrZohrYO5DUZm8Mu9hZG9Jgrp
EWkBjICcxLg5Ph4VhiCUOzr9hir2wGalQmm8xFw602S10Zk475QpVKcWdkbMEvWaJkJxy2CFnp71
kayRFpsGqSoGNY2zzBher5PyhjOjTFTvOJmenqm4qwFY8jLOmcEZ1GTtWyVaW07PpuId5GknbIfJ
QJSKzxMHM1MQbUhzxT1skqDuWMbxmIs32LGt6XeyEDSshu67Yl684bDIL1+Gk/Bp8a0SZFuo1dFg
vz1iV6HMeR+pucODzpekzTdms+B0cYz2R8cyecsk5K9XYW82StT9hc4SxdV705nbeyjYuMi49o/f
SdGf1+JRtUyyI5scY/tCBjxLJydKOi4l/UgqQiFtAeyQR8Lzqz67zWxlLhKgiIVKBAEgBkB6nw42
KSmWbRY/qt60/t5vHMZR57MuLrPbHDu4ytahXNVlcVwCtnfRVijpiMNeUMb5TlJM8ezm3VuTj2jR
2MAD0G6vIOt2JgG26fMf0iKtUK+pWO6RnVFC3hkmejnUNboPKORbFj4jjEQSBFLGvkZq4rjJ3Y/V
JawyUJLkWnmjNvDlMmP8LpAcWS45CVSjLDE41qNJNfIQ7mzY+lLRdYh7L+oLVOPtzKTNQV0WVt/R
t0M1klCMaz+hK6a3TPscem2grLquK7dkuchZ41jrdyToEXjSCjI+cszed8Maz0pIW+RcT5GUNVi0
V8yeQ7inEtNwurl41Vl2aAOETG0Iy+ko1bpdk0fCon4XYtyzj3rAhoREhbT2iKDphS1U0PCf7SJG
Wq2d5/FGPcZ1TJlXUfx83je32vUPc85uJZrK3HJa8JF4yruPpSWUeZDqkJjmtlrMHcSQ0MxTbXKI
n7NJAjGVuMO4hTWHSc34/b4wXQlrJKQ2PpqYxlRMpS9niZHMWV7qEwlYb7bpOQrNnsFxcRsvepZz
WMZJkklUYqkHrsIuIyzxmRWKI3SCu6xBH5WLYJ4HTjHszfVjKVtBtSowWuTlMeOaMN5NaCv0L4V8
gs7Rbngi1mHKkoYXKXIbaP8AUDpgyHp3sha3ZmchIO2SFfXkbbEVOYRpAr2CtRFqiGVPtck4jG87
IJQ8hFxEm7GMg1UJ6LVrKwlh0DuyhvSImyESLdFQyGklyCerOYy7uOjKFwUCV4WZZpHy+h5o+vSL
qIF1N26TNGkr61gqGD5dSFK3K0dN38rhCjOJpsdqzk0m0a5UlwF8oidNNXYoqCXYBHgAyrk32SDt
B+BNjjv9heb/AKfLpxOWScbStVq+N7epZULNE5VpTu5QEgvHOmxkmUbYZCkHZvokk86QTPFTFYCM
akUc7pMkzp7FAhgCDyKCRUTJlTTANxER2Lt949N/66+7znSC4ovSTFhIhzDYSVE0y7mpUVs1AQ5E
9/iPxayoldqs36MGm3GJpNaQt1d1a2ekXK3MqrXm9rmYydpcvOV6Ns9oiGLmVn2LEXLY5Qk5B6Qp
XCJg9lUgmSvca4oqennT1dEYdG/tLzmWtPMz5SRUZOpmlrxTl4zb4Er0E8sCTuvxDirBOzE7PSEj
Alti7CNXhzLFAhwGjH9YyNYML5UnITJadYxfS7HSGlrpEhYbk3bW6duTe2Nao8aU6sR9lqz903ia
yRjIScm9bCmYhk1FAEogDZp8dkV7BX1SqTUhG1ipx8XaLwsFkfQMKMgawKMILxJm3lI9s/tUu9eT
iUWxbBMPn8PGSKrVJVBk6MnpC83YXgK9jWUsGUEmhbzeXDja7K+M+HD0Hna3QkJgi2+k+oeGZjDW
LofGtXzHfqKWvVqgRUFA2hIAn5SjoWmCayK0ZK+HRMpENXaTBkZvZ/DzlsUCzBIwA3tP9DxrfNYe
qCFlcO4tcssaYFzK9q1TfVBF7QzZGxxdKNBjKeprJ2ZsKEyENOERroR/gVaM9EtddvBMICIWR8Wa
o8dBi/UNYcpS0vfLy4x8rWbNB5Xss1mOGnb/AE5O2UqPl3i6pLDCzEtGqptE1281POXgqEIgCvOQ
DbqXwRrSxTm+BgIubuDbNmbl5yvjLUq7kXslmXduDushVeyW4smo4URPLJKv8iObO+d9qVI6q/jo
EMYGEELdrtEAyYU7J01zfLvtGzGp55PIm8NPBMNT73Vdl2w4ppc/GVdjXJ+vYtkUZJ3HRdAt1vGK
syFXkmYmIxtTFBesHgrI8P4SomynzIKCDN0KbmxtW9PEVovyxmy20wtmu83qNNi6CZoTtkTeY8j5
qh2W6V4UW5WowT9N8rBNVLAZdxMllgUTNEiYDk5oDquB9VTbJ16wlUIqSWuE5UlpbIUZEy8H4ZI4
4aPWMsM5JWOZnUIuTrp15ONLDzEasaNcnkGRWzkwu0O01lRpWqCwtsjabaRA2KWbVGyPL5keiRPg
iRI2xQzpGneNyskoJ3MpMGk5l8xiIpjLA5cRzdwDdM6aKnKNd8hxbubuLnEABBxhJxCYnMNNm3VE
2tcAS/VVlkPk37v3k5fZNwbg3H2g3A2YIeKLP5Fy2azKvrewnbGpLMZqDlu/yNX8CmmyMGnUmUH/
AOIJmVCbbXX8+kZ+wR3TjQ6pcK4SxDhfTWSqxh0snZcxLh3JczcnNumZaMWb3SomkLkazoybdFGM
TaWkTL0o9dFYjGHMo4fm7AXprKJwz+qbJuHnGN0oiw2HDOBbEq+XLFUWHPBY3mJAh1Hh5OyR8THT
ff3JElDykLJyco4IRNQy6BQIbb1fcgahMwYvx1I3mqvJPF2HYGMw9Sbe2ozGEh4thXI88cxpqt0j
DLGmHzBokqsqCp5twgikoqYhSEMIUF4QIgR7PGwPNWEiRwyOjUHHe1iw4eAMIyjRnAl2d/L8HPG8
6U9MkdqVwZp3ZOsjLv5mYrDPINnrb0bi2sUfaaT62Rc5U3hpYzyo2CSd/SSrFpBOaZDwH54s8Taf
SCzNVekTDmIobEdpiJ+w1+v2nIVuo94cRDpHJbGnR9cnVYdVCNskeMfDSdtbpJKgtRSuDM0gTUBQ
5eQ2wtWzPOo9xdKBqUlYNSkz1YGF9Qr/ABtGc1mvPvVmIPCNwaOASMwmv9X01Gxe6rL+wQwB0IYO
NjmLU/nvIVVqFbyPjGIgsbQttsOTG9da063U6Du9jt7qampywSNmM88ekzTp1CGVaQMnF+HdoQRA
nMXfRXH6KiQryn+HLSiCAMQKnUZTZmmSBnuZ7E9mvH9+Af8Ad/j+X79ZEtSND2Ociar9RunULtaY
yGxXjW/ZExxZXLligE6rSndVewqN4BXkJHx7hnY1XbxSvCukDURcHEEva4F+gaVHMxntzgW8wmUX
duk5ts0qjPF0bTJ2NcR5XaL51fpiyWmyNoSNqMKydou4x+4YpxUs1dFcIuFEl3JrO/ITX3kevZvm
M7/kVoLax3LGs7jqfrBF7WSEtNcuMfGRxXqCXiAO+0cNIFqsidMDAqidNQgmIYojqJDXRMykhexu
mOo8zG8Y5oeFWQVS5zNEsdTx9j5mrExlFYXNs38bl4e3IxEebIMdKEbR8oV02FmxEFkhMugdFpiQ
VsoiCBhSXDnMkZPmBoROVgbK+rLQUoM8zk6Z909xm+ZMSstLdyyJl/K+N8DP2+VQxvOWNgnLsJti
xlLPWYuXUj20vX4btVHEsmoySUcJOmCS6R0EzqlUEhDGB2aWNCN/1Fsc1T6XfaHW8O0q33N/a3df
I6j52601vDOpXHjV0E/FPE7cDVJVyu6UQl2ybdNRZRIEyGME04J9I1/o9TU+8xrhSqVODk8jMMlw
UZWplaNmWkUFamKdJVi0XI6bmfusOuVZGT5HEkikaUVTD9ccgDJWIfSnIY9rTmjy2IQfQR5vOTZm
nHzS7BQtFzBYVJFwwlyERIaXka8skrCpPFAUSQYpHTNCEKQwAA3W4guuNEyI6qamZDBmAADEF5lw
GDsrVeYcMQruExqdZbgimncfV5BphTSYOd4y/mqF6ax7rGeMLBk62ObBRpuAxnGDWpWC79REMgN7
CcXN5deMw3g8KNQGDdCzU7vYz8rz1lwXHR1caxpYpmq097xvYqhdMht8bNqJVJ57MXirz0jB2S1J
NroRrGNIWLWYR1PeM14NWafLojKtyHQKLhMDTVgfV3hHA0HZlIvGN+lbZY8W37H8jSrJeCTmLZuY
uEpDiwtzuuSJHzCEe1MIeP8ADmcIyYHkgdNuyKftkhMw0c+4cLojkdNq7LKb6+SOcGeaGs8WJqBK
AlIHp8nRCVRomFmCcOkZaedSRXScGPMgRRcBFMomAF4NyiISraRAp09UpDM/kRKglKdRYqBFQvHg
SToXb3a8HPnSw75mwBesTsaRY5uaq1wrGSIZvP1G80ucf2GvTrVTs++IHfysTGtnko37VPt26LNR
dIFE+0IXnLzbvLOGMj13EOHc4WrI0Rf6rmFxkFrUEI6ctkxLQStDf19nZY+ZTuUFX2qLecfz0FIp
EQLKA4SQ7YgGIZ2ezb3I+Z8fKYTxdg7FTS8HYwjyVuWU7LezMFXtvyXNer/OFer7GcnY6sVGBE5O
/N0VUmti5y+uISvMG6rJWcaDZ9K+nTBdePdntqxHdM5WCwP5Su1mFrjmPyU/p68axp7pC+TMo4PG
IQLZZVObg6+ZFE6apgKQxTCveUXRES/pQlakFnXiU7sk0DjPNq52YaJ+h1E/o0+Z8NcszllxsJcI
lMITLNaI8QRlmvLJRJo5RIXBVY1Ltzvk3UODuZMgmj9KosVoKZEvpDGAob8SutlbNDOwOrm9yXlN
tb59keNdW53fbyNjlEmvN2TaRsKs4FpsDA/ZqchuZdM3IflEeUdpu9Hk8kk9ammZOOSWUTk8sVxv
KNWwvjMXcKsr4bNouWjd68T8JFr9KsscndypfSHOBB34tXd619NGNZ+k0jJ9atEzlfGePNRuKZ/K
y1CjH0zAWy52ivyeKnEdYpuzPL44TqUTFzDVKVg274sD4gUtdUedqHNa63WEbsIovcSDE+BIQUtK
Uy7t9bTeSA36KYr1xOKlLsw1p97U10/NWpefvhGNTzlleIuuW30FQrBYFMx3CFc20rxXw1jGXyxI
zjB6ettmodqMdNP3CBUvpBJydeGGW45MxNJW6mV292OtJnlCR1haUq4PEavY3dTO8TYgmRq9bM7U
3ZnkJwkZLyQppnNIlKiqIql5pwRyZDO814JudqzA0yWlWLJTHlzsUjR5SPhoaCr9o8TkmLRZ8wcW
nIq6kT+aHf2yssRLtymOHlxqso0mUzRmrME1p5rEjkSkBcp2ejXNGi3YRsVEWOU/RKC7B8hFOG5P
9z2nIB9x5ObgMe7phowQbyhZk6jEYgdWct1K7rTAhwRNSQmhLbm113+rtOq6ktRFckn8tV805WhJ
mYkpOWkZNherKSWmJ+Vji1qblHD5Oc75KrKRBiRysxYGr+0AoYqJpEDmAnDsDVnqmezre1LZ1ypJ
2MkgSwMbK7tb9/YGT0GEZCrSkLOTLt88hHjdvANomUNWm7A0jFnTB/6ypGKI2Jejpdaf9Pw3yr63
Md47g1rpk3DJYdDPeMms04Qx/E1fLCFrkK8tYo6YPEoR9mUqPbu6sLNB867kkdQyq6JTWJQOT/Ra
y2TZUjyt6NlKvcY6r2CWcOsb1KNYRU/E4b7dU0U5Ujkm0CVzcvzWRioU7hQkjs0XIDvcnBEQukFY
gq9pBCXBcFx1JTqS8hMSmRKwI14gHs3NZmJgF8g9JZT4m1G2KtWRcSadbRQ6kW2Q2bpPOlfzHAX1
lG0h1W6irHQSMGYYn1kZvZuJtyYOWyZ39dbMI4pnCBRADLEA0YYrrNGvVIsU/ZcBZqytJVBRzJZC
yFRrvIowsKhLulHsE4mYkKvNKxiPc0lXj9aW8QTI1TUXUMCRDGLb7qTh9KsjkeWbaOq5pCl5RjnZ
g+s0femOPzY4PQ7FQaYlBxdafWF68ZVukRdjj7iebj8fsSGYuFIhNzBpqLIgIi0PJD+iej0ylL47
Wr1IvjPVim5TttMyJIQ13koNSlTVbfrxbBC1splasoIKpwTBF9HKMjEVJLEESmIoJkwCIN3i3m8Q
1bIBklQeZSBicsGcEiZ0FiBS1n9IYpPMtMM4DcO5hpYLsW6zs54If47HFFmUr8XiGxZWtGL4ywxU
RZggXGVmsfC3Qrxd0oiEmaTJXUgbgYVBjt/2eHfVvSSamaZWavXo2Vq7uQoVHs2MKHe7BX2c3kKm
0u6BvN16s2d0ogq3Sa7B3N6+Q5dg9g3Fr2gfSppWy/hLB8yNFqOQbfF421QZFzm4dPFJB+3vdIkq
zE4qr1jjn6qa54BnXp53IIxSKaVcmXyap0HqxiH2+bZ6kmk6Ogou1IZNUplCHVTKYhTJnUKY5TGA
SgZNNQ4CbYBIQ5g6FMPAr0Lzdz1VYjJQpLEZGQebKLycEl5liDBE/nw0mrzz6ufHwzsac7rqyXea
NWqRkOi4byY/pONnOJqHc8hUNtbrtVKUsbsyEr72bdOIhvLMjABI6wv4r1iEwAVNoIhtxKbv0oub
bBjKUxRda/QbNA2TDELg63PF49/Hz1qp1UftpDG03IFaSycUWw46dNpBGuljCFXfrTTYkj2p3aRT
mPgb0dmGrhoylbhantasmW7NgO856xbP4wlpl2ojI1GQ7VHGtkVlZfwabtUIQf8AWSkR9VMaKADG
fzyBdjDENkwhorx5pB0uZmypQM8wtm1N49yq2j5vHM6rMoVi84nkoeEZWFOFtdpr8OuyvRrEM1LN
CuTNGrKAkHlFgX7di4VTmJD6ThbbaX6A0ZTMQDhUMMTqOHLFIU8+skEFwLBWjo9QYwiM5KVmUzrz
LuHfLOvSRzrCorZXwXiq3ZWjcTV7EbDK9h8WlZWJiIsRFtYIKjEO3pFcuKv9laUG7h4b9lltwRkV
6XmXj8WxmKIvBlXb1qC0sWvSvF818m5dwVhanUW4UtaxZBFE5ZdRtBNXQRym7kyKqaoE7IxOF+dt
FunrClZxfWmtQ1F5TvN80qRWoL8oOPVYabgIWYk+074rLUICxsHB0SH7JQZV+hZJ20MuQ/ijaeAh
tjBsGibFmp/RNpMsALEx/kyr6Js15gRsNfq9ZSiburje04572wvzxNUlitshNwM48QFy6kEzR6KS
qxzp7qAWt4hX1EKEqLEuzFQwIQtRSGF5UknC+EDbkAlg6UipIPbPo7+0QdcZ+Xx+/wD+te2dvSZu
M7Vm7O7LTMgMsi3vDsFiSZLCZruEDiRkmyZjFSF1jMXQasfHzloXRET90uD2RjRJ7XZiG4gFbPVr
qCb4SaadUskWhPFDS3GuLWueLvCyAOHlPZ1kIDxgZ4DjUQYV0HBKB2g0wG/OqCQE5jcDm4T7MRA6
hUxKAmEDmAolKVXsTCICO4AC30Qj7lfYEQN7PB6rY2jC+jPbZhbN6gEkXWZZMbTjpXHldC8iiXE2
N5dgyY5OF+EwelNEpRq+NSE2YsiXRSdkhchGoOeVJUS+RoiFKIhMyUJTQMkUeYASDpKzCId0u7YF
qiuz4gNU1bdmdd8iasvpTkcgQ1jyDbYfJymdZvAc9iVnWIG4d00zp2yzxE9jmY1BFx84ku+hfnGN
peFixjwZdiMsx7kEz25OzBnMte+J4bTpNaTIKo5fVxw8wo6iC5Wkbs7QzYfMZ3Eu9iYuUbMbS4rE
jpZeSziNF1iCMKMYeMlbfODFDOyaTGz9yfoySq42tORajmMXxa9o7i9bLSNttHSjEHuPD+t0ZYau
vLsbrMvITIAy9PtLhiwYQlgrxzqwwJ2cTrIgMFr4xaIejmZZRa1mhhJm1qzVIfWtVjLlyoiUuF8f
zzCtt54Zjwefx60hJ57JnjZXu7wjwrhT6xZAbHpRL30glAhxVQiAQgFISWKXdOiSGUMsw0zZYi7O
6CqHQyH+OuXd922aGozCIejtf6SVhy0nlR9qLPqJQmk6LQgx6CqVDqWOlKyEoGXQuHYJyFdRcqT4
VvxQnQTVYOnEWOdRKEHpWq+DMYvbVTbZM3/J0jn6cjgJGQuWqhLRcAOOKNYJWKlFrHcq9BBFzAy9
SsENHVtqEgUYNy/BUOZzZew1jKq6Q9NeTK/Kv314ydkDOwWBZ9WVoZCUYU5HHlaha8idCYmSoR8A
xayE8SQLslIO5hssBzd6SE/iE0DZsn9I77WLGnobzG0PaBrLmB9aY4lzLHhANLd6wKR5XHh5GHhT
5k3CPPNFuAldthCo7Lp8yS0R4cWLDCg14ImZMokHqjMkuc3Z+FsG88t6fTSejuGo2s0zEcPhjS8r
e6BV7LVXf5f8gzKVdq2TsvW6x87Wfqz2XqE1KOA08xzJNBpV8dvJd0ym3Tu7yFyjWlneDG2Q7kvS
U0WcyBpDyU/IFWiNOGLcL1i544b41rdvu2QrXp+eXqUpL6kZbexZHNNgrgvdBLaWh5WDZVQ8fZys
oK2GdECxTwp6K6kU6qUCm2qJZWuyZQw+4nWWeI7JsjBP6fmy3US13irRMfiB5KkGWxLVYGlxqVvn
kSKWSYmDTqDFDvDV2ROq+A0IZtt0DCXymLUyy4reUu03a0ZohrDLHxdioKQWRPZqRk+yv4CFnIC4
V4kO1O9r6UNKyz0tqhjUdpIhLMhcPRT0nATDKihaSA0mBC0gFwGfEklyQWBeT2pihiWNQo9Pl+n2
sWGHtY+nivYLv9My1GzFw1CXiRvE5gnPR6RBWo+itvJtBNQa1U7JaU3OQmsdWLcynbQ/e4/SeMaM
MypY6JCTFtm7TNTcT1LI2MKbg2uQGJs+YUpWXshO7ZaNQeeMlVjKCucK6tJBJwzHEmI59jji3SMb
QJ6CbC8slthZ+GtVvkb5Kd8RZqRKvIr06aUsF54xTcrK0jcuMXlCw7mK3XvLD+344halXspY6o0j
kOGr0PhxGRmrzZscqsJikNXsq8cQNpA4ySajYvKoJXRi70bitwqWGkp9jl+XvGoGFq9iqt5xZB1u
w4UxNXsyW11iXDhcxy1gNB3JR1IZZibvJ5G9WmygwWOixz6v+ttxErLhlaLxAnsoYJIVNSsJOAqI
DyACUKWQliCCos/WhQgRG/VXlRIf3fq4E929nvpy1XYfiMbaVk7K406+IafBt0BkyL1FVeWsd5jI
KyZdi8sEylpbkYqOsiTPIDSNPNRcas5k6w8PaGUW/REWxk7LxXLr71CVHVDq1zXnihRk9EVLIVha
2GuRVtYxbKaZxLSGhGSJ5KKgpmYikHkpIJHkHQKzRTKJEOsPsFEwa1hpryXPZ/n9N0ASEnLvWbnY
qzOyzAZZjRIRpS5NVpY71L2BwgLuNpdejm67ucur2JRJEtUVXD+AbopHOWace6GlrbS8W2ey3Ozp
vM2X22VHHBccUD8qEXFR9OtLapWbI+T59O4VVem42a228x6aMlWYaxT6cexcCKIEK+9ZMmPd7/0x
sTsYaPZwWZR6w6pLvLSk6a2ouHd0M0dZMpEAfDz6ObVpAqcQKYAESnDchg6gcOTtNyiBdjB2f0nT
f2Pa+r14QlVAwblEhgASgIlHcAE5ElCBuAj1OmuioUPMxFkjBuVQgia+pPRLnfTNeLJTMjU9R6Wu
3NHGx7vVmjyz0qw2txDsLIhB1qTVQBx42s0loqOSi7HENn6i0mwRI3Md62KpIcP6OLMJsWR+T8ju
22ME5HUbU9MEbSbpB3F9kI93t0JXbPHTkrXEHKJK7QCsLm1YkfNpOdsBjxrtMtZEUZALHlQ7hFjf
y0AuWD5yCpNqATpxcuxtJSvEGQEsX+GnePG1b4LAZQpwMAkOQTkMAgJTkAyaYiUwdDFA6qRBOAiH
MomG+5y7+U3QAJAExQFXYUgEwAKnN5CmG4CffyDl8w+PFkbv0YeoxfWXJ6JIRCr2/JFfm67HWe31
uVnXOOqtH2hlXl2Nqsc5JVsjiFrUM1WSg5Qk1EvrfJWxVOIqLO7SRytxEfUTgq0ab80ZMwZdJKAl
rTjK2yFPssrUnci9rMg6Yb7dwevUoaSljl95ZOEbGDyEAHha93RUGEIiyEqYKZBcEOJjUEiZEtLL
Q1FYmGct5tzxtB/eCdPb8/L2g6/Z7XX7uHbR4tjY7TAwz95FQzV9LNGy84sJytGbVxt267jtDFSQ
RTD9YqoJSEEfaMHlwxRIAAkI9ADzH3B8xHy+Q7+/jhlOUN01zIKk/VmTNtz9f2RAQA3T3F3/AB24
rd4qIEQRGCzJ0k9V+rOU336dzitZbmLPenSsYRumDcK47QlZ61Hj4uVy4/ZRpZdGLj7TX7YUsZKd
uMtKJSC8XLw74ZJFsXw+QIU48ioANZ7ldQQ5QKIn8u0ABEPP3CHT7fL3ceDuTmMqUpwMYdtigO5h
+wAERHjUHUVN9VQDf3Tb/LYNh/77eY8N3m+Xi89pYTuCQdKvWlqw07Ohfj3+ptn5lf1nbIdn58va
E/lv/Hb5eXCb+05v2f3vd9b4+XHYCoZPlKUgm8uUOpvL90B32/7778dfS78u6fL+9zhy+f73l5/P
y/DhbqfF5cPXmT2t0YQS+qIfcPx89/P4fP3cYQ9sOY3QNvMwBt5/h9/HShyDvsco+yPkYB+Pz46B
RMUdgUII8vkByiPn8N+AdT4j5bvXmT9bwBij1Au4fEAAeMCSqm/KIEA37oiG/wAfIev2dPw4yiYq
a/aFMAp7bgXcBEQ28wAPd08+oeY78Yucnadpyjvtvt7tvj9nz8vv68Vt1splQHblHsuYNy8wgURD
4hzCG4efUBH3/AeOKmOG6Ym+l95t+nx8/mH4D58eAE5ebnKmftEdkthAeyH4G/dH3iA7b/D4eAVV
OAHMZIDm+qBjFATfYAiAiPzAP5cQgYKTpXcGt1swHIIqpgYglHyEDAID8NhDcB2H4dOnlx3zk5uz
6bbfd/2+flwkEpCDylMUR+ADv0Dy6biPGYDEEvaAG4+fTqG3w/rrt+HC89fLh+fHdbrLUzrGD2CF
L8eYNv8AIR/7eW3HOPCYG6+2Hz6h0+3fb+P3deOcTbrGy5dHEOUEimU/fAA2/EP49d/L3cJERDfz
DzH3h8OPKqg+z/xB7IB+18i/H57b/wCHCMVBJ9CQAEfeoXqXYf8AiDp7g6bj/hx6xcQrZwA3P3sv
bOsY6HtmN2iYeZA6iPz289g+/b+PBGaZqZfsjZgx9TMV21tRb7cnkvDwNweTM1XiMPE4OUbOWK03
AtHlni2byJavmMmWJjnJSGmGqawALpEDjKocVEfaOXyD9oPh8N/P3/Db4cTVhfJKuIso4syWcVe7
0O8VaySSbMBMutGQsv4hOtmwE3McJCM/MQAoD2h9kgAR2DiLkAm+4VKZHxy3Sak6O/0sKInA7F5E
z4A2z5Bi3lcudogZWfjbHNRs4+iJ2fjAk3Teafxi/dpTs3ttRj5Fwodz+bqFl27QwL/QmAFNy8MQ
7lNIvbKbJ/M4gTr9ptg8+m+23z93D81L5Ap1/wA1ZJvmP2E0xqVxt8nZomHsqDSPsDQJp6Eso27l
HzczFlUFYQLyeN83OYA5eYQDiFxcJrj3hU5zqf7nzS+fTqHw6befu8h4WvaocNV5S5SuCQwAHWDh
8WjVccKtZeGvHDMMgCvWclWWshl4WmHG9ps9YvFRsePXKjW5x89GKVFw1bnk129kW6xDSPYgWaVl
JAm/0bVsRVwP7KY+8zph/rPqOabpi+V8YQzEeTjbrdKROsqlOxrK1taw0mUsguICScPaJDyxomQY
PiWJyghaTSL1pyygqOEeet6rWObr81HzMDOSEJORbggxthipF9GS8YuT/YJRtJN5Fd3Gumu3tHhm
roxPeIe+1tXWTQZLOOT8gSj+FyGhmfCeFK5JDfoayydT/KTikMad9dX1gZs2sE3Azdoo8oyY3KJN
LyjCRfFk5hDwZQN/Q9DxEezDHfIkEMOwlJMwlqmnGhMiGL0ihCz+lDSZM5erB2A5YGhsHl+sWTYK
WyBWckxqLm7WGZjV7w9u0Q0l8lt5eKfkXIVtbpo7yYr65EVUlnycTYV1JRNQijwLMQxTDK9Puupn
HKOIsww9ZnYmJwvV0Usf3B1S1yVxnSJ8ZYot5SRUQLGysTahvkwUJyccNWj8ZpsVJdUXiXaNzPWQ
KtmHJDibjrNWSla43pLGx2FghbmFXmbLTKXDQssjXknbMJ90a0OklKvXJCyQbfxJwmo/uB2ipDCE
x45yvRKTpkmJB7bzX3K2S8pY6ot0xxb3cnPIQmBsUSMffIE0bESZH8G9PJSdcSgeadO8ZR7XZGuQ
ch9USXaAVX68w09ICAmCBhCcPWdq4s6U3W7D+gTs0NLM5YfQ2a8rqhycROHirLj6stKUfH8nTUMd
Na/KVuAl6lkC9EvgOmIR80adenstqUJZIAyEqoBXByRDITqGBPiao70jGbY2zyMjO4xrM4RrdceZ
Bgqg4bXOOQrNpxnR4fF1ffpd6eyVsKgeBiI9WWYy7kfE5V02RUKdZZIpjzdXvRjYNR8BqJd5EpkZ
LOciqR1IZxN4kzkdUSa05WWsRs84av5CWcYuCoXl5HxkC3BhDpwrmIcylY78o2VMQNoqmQslnvCd
dgM+z+NHOd4+wy+oJ1A5if2NauqYxmsiTEEwmrurPrwdvc36l1GvLQLe5zswrEvZONF+UwvWvasR
IURH/wCUOVcLjs7zMNV2pusOApGDBsksMwTu4/W0ITOt6y2CFRazmP4BS8RtdyvUYiwtX0nGQzOM
znZ39hnWD7HPYpx7h5W5q6SL6qvFJMTmAYBRoYQdNBUXZK1zusiYuytRZ6nSKlyzRFYLZ2CcdWsr
2t19nh5hDRjaSrNPMQzlotcW9ZgVJFTxqW7ym7lDiY5SKiBvQ2XHWt5Ww0JpV5HFkHJ57MlJZIxf
kKvRszCNJ+nx9ehIyzVxR7FTc/VWcdXEbBcJ17INGDhwALsXBQDn4giq09rM6DtYlSb48pE8pg7M
NMkatmWt0SO8fu0RM5CTgJl85v4rKObpFtIdZJ81boyxUO4qpuQHsDlUG94Vf1QhEhdIQ490FYi8
AiChMkymwrxILE2hvkGXlh9OWLgllzMFYvmINO2M67X5yOlsLVO7RklYJeUYvF7Atc77JXJ2nEot
RFxEx8YvPujNVJiUl0ychxKIcpthTdqJnMsRMAA/X2f2g8/2fMPd5B/hxaRL0iGs3oz42+NaTDN7
LQNSkjASNzCssm89MREvXVztWY28Ykr+yxjSYbOY06k5JSSKcg3WZiIOElEy1cuikKssRMnMoPkc
obgID8Ntw/rqHHmL4le02i4iohAcBQDPLwtpXeo4D6GxIYPyhTqzSc4UC4IWTuOUYCltIZ5VYaOs
SzO2U2yspZm4nmlgu8AYi5oZ5PtyFgC2I4lfbAGx+rirWboFfA9lwXbYl40jEbChfqLZKYxYs5Be
6kK+rSDPJLdObi4ux14a/ZThGzPe5uWq7w4QVaaO6oIQ4yv6OOh1G+XvUDE2mo028rR+kLMMzVYm
9VmEudeY2uCf4/mYuZJCzDRxGFkGsHHyiQmKyBQiUmkYfYXIJo7wVjyn3X8q1+vkJJ5Cb49qy8yl
jOkTjmuWuZl59Qse0udgPFpOXLPGkOrIOI29uqzIOZgVDUqAb1pKvvLS9aacIdIRrtdjCjXcmOQC
SWKaUNTKU95lK17PDOuomlZGf6e5el+OMpvFuD8EY5tTSxQMe3j3tzxZDQ0Y+WatY2wzZbHX1ZBJ
VvFjKEReLRSR1EYUyRTCE6VDVpTobX9Cak0pZ2xxz+VeeuMk5lqm4GWb1q0Npl3LtYetpGnV2kk5
aKpOhSSRK+O3UTW8b7M5TDizFhrCFG0IacsiV6oMHt0y42ur6WubqXk3s0zs1Xt/hrxkMfJkQgSV
JpB/6rvo8zgs43IISklOWAAFQdfqXxBgSk1PTDSa9HtazasmY0wFdLLk2NmZB9Dv61kmkovskWGb
iZwEF2cswvLltMRjCs95U7m4RiCkDtU0zPoT0iiJsva4LEGoFAQMsp0LODTqkWr1/hHLevMnfenj
U7iOk6ntU+QLrZo5lQco4rz3QanJyVRNMRCgWm0VCTpsaemkjpZOEbHia+2aAkZimEXzEJyk3ABh
7TvnNnTaxq7Qnr9EwNqyDSazKUSzTScy7u07kCLuRwZvKzYTJycoyk5eGTUery4t4qHVkkzgBhUK
O0yvtKWnK+67se6S6dN3GqU6OuklQr9OPrEEm7sJa14+MUeoSMsVB8wkrT4XG86TqEFavC7aeroP
u8I8+oxJpHwLlbVJnDD7ORuMNRcR41y3e1WqE3WGs5OWfG8xXK3LQ0bOSruTaTkSs7mX0jGWeQUR
mJlFu4Wkm1PIkoYsQRfoOIvDWSASSnCWJ6rln1ABpOVhPD+NVdA3uP8AU8i2opuo0kdoDyJQI/JU
HWMkSmplpeU2DOalGeTrlTZ6lzEDc5Z84jZBdV6yGwLoi/QB+o3lF1004gRVUKUztzxm2sS/o3tK
+PIC2U5jcK9YrpC3OmQdueL2RtT1ZSWtEI7n6k1lDj4baJJy1sDhR6UkmzsS6Be0CJVIQwt4bwfi
zKUtqXuL2xXOFxFhSGjZ2FGMGpKZAm29mthoCBnpaFnbK3Zy6FfiBO4treLmTpzkoZRJhusLwtl5
TdLUDK6c8m6lbTeZSv1WEy3+SLH8UzrEbISE3NIQtptDd/c0C2A6jGMVY15Bii4hAsCKh/YIYxug
BxdIezhZ2Y64IMnBLIEz8TswqT4tQ0QlduKtMsgN2Znq+ct5sWWtDLMW4xZ6OxlUrpUjQsNgPToN
urze4nu0dAXSgxddCYPaccIyYwDR3XBl5EJRKTaIrTvdXQLlP3dXlkXWdb4icwfk18ReKdKG1lw9
wocvL2prkBxk2Jn8fXmSJZqjFPZd2SrUNg6YQ6S9OVhgoqK0gxIpHFM7QBQBrhoweY40n431Q2iz
ESQzJIToUypRNbXPGuoyGllWJWNgn3RzOVLhJsU13DRrHwoVxy3I4WStCiRXxrItvOjeSoOPZ7IZ
Lcs9Sq9SxhbFZU9QeQ9LtDDJ0WZ7FR+JrmFgWfXCYjnpDlMzn4GvOU4UpnApg2KJwYES/m7X+77O
EQGGMTW4LEZ5hjWdaWqbvd3/AJkTJnP+Dc7uNraqwhL1vXD6PS+2WFiIlpkTT1h2kW9nHta7ERAW
t3hoUZOqvK81TYtknzKye28iloYsE2X+jWjE1fZ4hPN2iNWBzYo8xHkR9jCPnMU27NWWoWkEUkMp
1HHcLcUYKfr2M49m9SVkJm1zztFzDryruAVShXJXDfdBV0ezBVctF2SsdoaXjvcs0+Z/0n4+vydM
f1p1YnUPTTTL1KCbltrpJ0wCTlW5lkkF0K9HlXKqoRJ6SwnMUosvIGG8t4Oy3fqTfspNcTTNMb2R
o/yLbpnIUFH22NqtjdM004F3WELLOS8FZ38C1kaszYouG8okomtbQakOUwiTFSyQLjNsJkpzgZKm
YhmUQ5YgTGb2kwLz7l8RDEqKBl1avu8W32OHF1bhL5lzVWlmjBM/XaHYNLsNkfHFWfQVViMo+q8L
eseVun5DVVYnlkzZNnqlOu5jIU5MIs5uQWSVcM3/ACEOcsm4jwPiHE8HC1C6Umi2NGvekMq2OHNp
ToVTu90uFNstSmTscc3cJ5u3UhKQ1KoknMsoiSnF2tgUTZuIIjs4JiE1Y0katbPb4l7RM3wju627
Sx/pFxchGZMyoyuFlwOzfwS8bDyR2cS7lnEi8RmIRVpj2bYNIdwky7RJQ5C78AswyDn6l2iyrQV2
y/AWuWlxkba7q1pyFC2GSsbd0myaStncREsSYfTDB4qk0VkpVw6WRdKJoHOVVQpBJCvcG7Pt7iqJ
QsoH5QwbcDnIvUACxoUGKpmvMJNJhdXwnXdTcNZXyt9JuLNQWLMv4qr9Nx7izLsZ6RDMGKqVaqxU
6ywRjY+EgskTMVj+03GOrrKzSmO2x4p2ItmTLtSiSCHwMO3bCcY5XHte1Fo0bAGn/G2M8dZHxDpu
lITNU/ecA01n+VW84ZeeqOTLbUcwNSTFrsj+clfzhrNLRxbDOG6zzNkPAL0lzqkjMQXnOVKzhfa9
ToTLDBjboqEy/dYyyhky4xM1LN7UaCj5xk2TcuIaLmG8hbzqlnilkCAqgAKBzQwx1CZ8hUfCo/NO
TWBRiJSqgzZXaxNxcVudcFcyMEs3LNgiMDOyyib93TxdjHqkUIqMYJRAwpRIkFjeItyiJdv00pJS
TIDeNWy7rGEONL9eDl73+HPhutPEtj3FuUNOqmTqLEsMUS2FFa7U8hJ2qYmJCGzVZJ7tvAnuNEFp
STcP7vC+r8yFzg3gwtXh/FKz4muh4kx7VXOMKrb9EVbvqNGqVbttSzpI45lLRW4gyU7N11fHUNMQ
b2xKrzgt5JUiiSniJ2G4JCmcVRLyG2GGxPcxp48pTKxluCWL0FZ8mN2kqis0qRHPOmS1lq7BKQSg
3Dx4oqmS0yEY3kzWYyhCzh5QTlAXyvH6hnmnkjsY1dDT1G3FpImUjGVVj4RK9v27tswdy4wTplZp
eyPYlg+Ys5GyoPY5yZk7SR5xbLAQG1h7OOj2aIdvVRSXFGao/YGtGRDXL/UQsve0w+nLyHlCTdx8
gk+jnKqEg2OHYPkFnbeQI8N5Ls3keYh2fN7jEMXfzAdh49O5Z2/WdOXrp84eKkXUdLO1jvnTgVPq
O3LownN30+/sgY3Ob3APGSDWgyzcctam8irV0XbYbE2hHaDOcUgyjuZRhIvxlGyjoPeVMRMHXfgl
JlfR47JAlr9a1AQrQ8s1UnllLJSZo414QWEEKiaSj0u7v+Vu4HsnQmUEEFvZ5UlBLnw4C4nZiLwu
OqGIaU+fSzK1JQx7R30qJy/amhtodN+n+76oclMcSY/fVZtbZhjJSUAys87KsWU56vtu+yTOJcR0
BNgmsoz3dnRsxmpytfzgxQR9vguoj0c2p6FZyFrg7NRoOntMQJZqe5RY3echKWWjjMdlHO11Qhkb
W7nEFd0vCTVwVwV+j7Ln9njWaU88aTtMuqbDWb4RTUM5rVNlZxS3x9phqRLyT9i+gyQcaSpowljj
HbkrvtU03g2KSbgJlCFNuJygZ0zPpPs3R7+VqEpSqm8xU8xMGCXWMZKKlq2ijQ03AzbVyrIkk5e1
Jyi4e2gQ7wqipPaTAxevGhBg9HwEEqhFSwEOFqLOT1gGniAAYuzqBLsQUoyI0VvZgC+9mocu7MUl
aJ6rpqul61a4u0+5MyIxsbq5SEDHjcaJdom2CavSqHiqbamzdmeQsW7kF1/ZSQnlkFVFPZIUwjwF
9gamh5OSiTpqEFi9eswMmqIAUyZ+Q5BEB6GTOHIco7CQ+5RAB6cFBStUUDUNS2M9QdZwjSaxG4sm
ICXhMYY/FSBhFVYeL2ZuXtjduXM4Q7v/AOaJY6QTsiP/AIcyHiF5R5R73cbfYJKTNj5nMTy8zGwq
NdnLSj2DmSKZ8ikvHSSoHGDKoQ0aUgiMqByCl2gHARSjpgqGJGMILTCjmztOQHpnR+AmMmFiiRv1
Aww4UtlnXT60laQcX6WNQWcKRZL9jPF9mvVUqVgjqpKrQTWOlngz0imoqzgWMKDjxOSRcIpqKzjt
FNQYFNNRR2KBSGEHQ40TasGfizxxgvJKpoS8fkyenSrq8y9a3Ps2i3gIjGSirt2j2L9gr3XuRoPs
3rRQXwEcoicqdEWv6taIWb+tJxcjkmAlrpJ3Dxaqu5KjmdA+xpNUiPg1Y6xIJcxm9iUTmweCXcET
kcc3IYphNp36bLHrm73exIY4ylEI2+KyQyZs6/Y4dN00m7XjLFtKrsuZwMtGM05Wvz9PeTriUHZR
ohLN3ShyEcJHOZN1uSoZQhcSMwdyrCokAMAHZ95IrOVVo6o0OJhgQkBEuu5o4q0pzHnwqww+/wBc
eO2VqqeGK9kmKOwdWWn2RauURmjaopeZKCmQYVlajJjbE5GdIwh1LQwhTvHSRZBgZikkDxuKnjD2
BsvWfDrPJMZljD1BojixXuvVOMyasm3Wslox1FVqw2COh3C9JtcfH9+bzj2Lim72xCo5cIrt0CHU
TOQCs1KekTwnqNtdYfKDqTw1BU3OWWsqQ0tipxTELrJxOSmFHQFuEo4u0DG1K2QS1WXSbvY01sj0
lZtkn0M8RBQLJ3UlVpXRjWdO4S+SfXSuZ4tWTwau2bFTHpapYK3D1pGMayrO3hKGklHhHEhJNiVI
VU0iuVlSFKV+aynRsIV3EaNeFxYpIBQsJZIDBJBSHORaTOZlnNcN4i9pCUUch/lyOuo8SLDrCvcu
tQjFqovkNjHryc3HxQ1cliatkpRVBB1Z20QtWk2sYuZy2dNnE5DNhOs2QcILO0SJrJmM1p7I17sk
LXa3arhabFXqskshW4CwzspNRFfI5/WDBQkjJv4eAB9/58YFZwAdO09/H1HaIsh06V0aY2sMhFx1
IjsSaM9Vlae2l67oxIgcizdgoTaHsTeUa2BeSir2tEiVjANJeGTnXxjgkzmFhECm+eGr6Oc5ZArt
cutOrVTlo20tk5OHRHImO4OWcFV6pNJKLf3IjmOVV/s0lkkzn/YA3XdW9dGqEQhMWJGQJhS1DNXV
7JYBgCB8zFiCLRDVDV7RjhISYLYWJ6xZNe/MZNOjeKpZ9Qctg7I8/GZ0tsfjfGy9Cx9N44Pl68RB
pRDJnj3g0fV6UE8sysFZjfVdTxli6bpNmnjjLvAE74h2jVb6oNSLVq0iUNQubkGzGrv8dR0Wwyxc
0msXTZbwsZeiMGCdv2CkS/gTQZCnJk8KHtEu0jPbKIzRiXIuK4HR3q1xFdZqJbZHu98wnO4hiHsV
NyqotKCrb0cgkipdNtL16FLKKTtYSai4fQoTSjRqnP8AcjR1dB7ZPp/1Nej+DAmCKVmAmNHNzi9I
mpKmZRC143jrC5UyOraaNJ4NPMSTiLennJmKiYada0hy3NMua93wSVzw7mHgarsiJEK4l5xhJAwl
ZYgJSXE3NSmTlwRYi4RSA0GGaZnd3ZOMvAWrnWsM8/06Psvn0j6fG+N29wXwkbIEQ8ssHY2GRVKS
3kkxaRLe5LLPn52LpquWzpkPDGlnKCZVBWWTKYcF7dmmKwlG0w83YwwVOZElJiMrTkrdOkyWRISA
hUpyeYIHTB49t6cLKQ7RzJtjqR6IRxyK8vZiBTHhLHg1x6LC80p5YcWMdQTbWO2vcXEO27FvlF/j
YuOabUzLMZJVEkq6gAk2rl0ZohMKSAC2XNzfQqCVZYLXH5g0CY4r7HIWA6nPYRuefJK51W1x9Fp1
1sURZFKS9qEfi6Mr9LWnXL6Zj0lY875q8j3k+qmojOz7Q5DFCwO224xmGIDYWbrUq/DdUyraDhhe
4FE6kyf8jzsKDPVhqLZxEhDJZRugxD7C46cXLNZWOK3PgsrpzMGxdsYoFGvAeVl9zf8AioeLI+0H
eCczhb2/U6bS27xqzqky+0sOLu4yS4kiYwZLVppkByaKqC08S+JwppEk2R7CM6uecGbCHKkqizE4
HUImaToPL2ilLQ8GIZHEl1HVEjlpxbWuSIZSCRYqxJqNDRIKq25xHDZPVsZlJVwGNhY7idNQfWTm
IYAvCu+ZdPl5hnmYMcNH8RgJrowvjKbfssgwlWw0nXXuGp7G0Fp3Lp0bzJosMjFznKEt7Qpq2AKH
sRXBXSh4rnKaD0eu9IjLN+xiCVqd4YTiTgAxTxFUR+rhBMjKQICtY9yChUxUqkHDnOh5o3zdstQ+
SIzDKmCu60abox5aXkIkbdRoSyWyqHugx4Wj8ntnk2Mg/qQ2o1cSDaIQjhZ7e4eGW2s+Um2OlKEM
3kJtiiSspbw4pqclamuOH1qPENo4tuQrwvi0pewmj6kpFhYE+eRFdsu2LI9qioQtyiul7T3PYffZ
AtGPahV9WTPR3I3OP0f1y0t4OJkIAjewsGGpeeBByoWRs7SsJSMqbT1HTJnZHNYhFBSAJ5uZVxXO
mauNMOAsvYHsFVyBqPyVddNvrterkrMzVk0x6ftKTaCaoEjqlC259GwklmeCdRTuWc2dKqChXWsh
AuoQzpFpJHF9PRsWLEERd7hJIMhiDFikPMuwLCVXlUG3bQ6Dlvz5aTr1h9f2bImFann46s3TLUJj
ScxNRtQt5Gdnc3UCpyabnsQq9qNModpY6inLy8ZSbm85rbU4uYQGNlHiTpPnbkLrwuNUqcbh+Dot
LjsErUSTqGUMJFMhIVXMU9YItUZ3L9tPMO3so0zY0GTbeq1xaGIvWfV+pdwkH3hcgIXm26D05Osr
4fr2LGtjUwBP6Kn91yFWMfUSqO9G0zjljjrJq1vy1d50s01NGZ3YZKhXsSEyrV39uSM3hWx7Smss
glxXXPRln0yYzslHzrj2Vy7mrKWkeWf4nw5RMfU+QwngrBNgJPMU84ZN8DhmTMmaqsLyQs0LIM4W
cXgmCcHZpm9kmXLdocyrteEQ0mLeYS3SkphxSEqSWSUpKQ7EFgpnCS++3EpmMA0dzOg82+thbxRr
HoOMIxOxV/T1WY3MTDAWQ8FRmS4G4yUTXnDG8w8zCtb9N0prFOFpnIkHX7XHNQmFLCqxkSNK8AGO
Dln2kgYZ9IdIUumYoG1MskWjIun9u9YYhk6zkiVpuPJ+Nry7G+4RgM249Zvzp5DjcQ5jdz94TkRU
RRmIt53Qqh0TdRvr+B6bj/GkdmfUjOTFTa32u2Z5g7FFdZLGzFleZ7rLRtByO7CwEaw1Lwk5t7hU
j7Ic5KydnukfC2w0BWHJFBGxWo1XCOBa7efR04eRUwUrX9R2HMI2DI1UyNjQcg5oyrO6krxesa5G
n6ZmNKrSJcbGxhXWUU6x+zgrRVRpcjItSsAcqPFQtIE3e/xYRXHvEBCmIwpUpSSEoUqhcdgKBcdb
sntAGmFBL4Bkatmn7jz3Wq5yDrBuMvTV6rSRHHkjkdja5fU9da09VhbbqBt9yl5SQnGt0s8eiwnT
4wTjXEQxjsTdm4o0QeWtScy3IMpGgYhNOWuOn43xRhumXCTz3WJzBuUJyxV4uCJyNq1cyphO3TDK
dtuF8vIDa6+LttZbVVZoiljjouVZx9Pt6scaHLKRL0bFgqvo6XWU6ZnrNWNskQkbhbTFcblD5sfX
uPnErbWIqlSSj/x2gsqk3scTlly7ryjhGBZSM7RxWuykw2tRadV5OKuZlum9hj+t4KRyrl3HOn9t
pngslXmpW60XyIGT1RaipV6kzWVruCIcruSaVaTrVXCCiIp4S0xtTxjLP5K1EtiloBRlxS5i+OpI
WhASQlYBxM4BwkHMpUCxmygTIhxrVAWzhpDx6s38fA2nKi+lqhmttzRlfJeObRdL9n3NUPZbPU4e
3y0Vg7F+La/F1dmS+4urgWFo8c6so1hW3jqpZalYmvI1htHVFeOlHyUc/Pw1qn6QPEuPaGSiVbI2
rYr/AP08orU7OZRszWHlb7kjDkVXKnHSOMcizEdnZu7n7t3WnSqrV85eWSoy6UsVSefMSTU6LSPN
JFRoUtim2ZHv2nfFEjpuxRlaTk8vZlyva55zkaz1VxIVZ3F4P0/RsPMQqUpnZtTEXUhDLTpfVkLN
OMpq2WKmwzxA6kv4L0V4I1IaDtQd0xtAEhMpudaNPw/p4ueS7Ta4udPC3Z5UE6nji9pVl9YKa5sj
+TtAkNINGfqy4sipJElrNFHDccRESAf0+q2GhYTZIlIZ0ykWdrB2N2/sd+NW70sxn/pRzstcdly7
jVKdxfpOyNqaxDmXJ2MCUjGT2aslUx5P0w027k45kWfBzZXsRTX0h4fGWnuoysoiPi/iC5LKav8A
16Z2ruo/VjnHN9NFI9RyDdX87WCkrSVNlPAQ/wBgXl2BDisnPOuviSb1OVkf/rpuxB5Dzkan3DGF
6tWPMgwj6t3SmT8hX7PCSzoi8pAzsF/t7crggFSUQW95TlL8w4jlVzz+YgH2iAbb/Dr9u3l9/Hlr
1FWtGCIorEg5qzpPEtx+pdhCRDDAu32t4WUS5uyECgH2h9/mPwDYPhvx4VUEQESkIIJfUENth/uj
1Afh93w4QFMuQvan7M4/IQEfd8Pdv8f8OMCyipE+UoiJg8yh1EB+AgHX7d/PhcQEf3Dl7o3evnLK
wbYBVAionKICYPMAHcS/aAD02+e3nx45yKfqw5fdtsHmPl08vx/ltxhBRUSrABCCYfJQNhL9xgHb
b7+nHoCmVH6EBD5gA/h93x/Hg9rRBgpOf0IHrb12oH9o47H/AHURAxuvxAu4/wAPL+OITmAezHcA
89xAQL5/Hy2+fn93HsUwIAKF6mN9UA6ib7AD8dw32/HhKooJvq+1/d6h8Q8t+gfxH8eF2T8avAbv
x56zrbICgD5ETH7BKP8ALjCkUwBuPZAG3mIlAN/d8Pw93v4SCqBvqGAn2iAb+f8AXXy+/jvtR35P
2fPfpt8fx+/gez+Y+A5/c7m63sAERXAC7imjyph1ETj5bFDzN9gbj58e+8htvslt2O2+4bb/AA32
8/8Ah8uOzGKmAqAYvN8N9x8/Pbz6/wAOnz4SicwCBBBICm+qIiUAN19wiPX47B+Pu47aHQc8nkT6
3vYdt+0Lt8dybfjvx7ExS7gYogJ/1e4CHZB89/q/YOwD7+E6yxyI+x2RvjymA3X4dN99vh8vLjpR
TlNyH3Ob9wvU34B1+Pu2H8OJxp388+XB+tn7VLtt+m3nvuG34/4/W+XHpMBDc4gIJ/ujuG/y2932
fP5cehKoAbiUgB8RMQA/HbbjH2g9iUOu5+pQ95g+JQ36m+zfiiMJ7Zw7uJA8nnK3WWgqG6m5R6iG
w7D1+zyEQ9/8/hxzjDzKf/Z/5i/5cc4rbrGGocwiYAOAmP8ArgA3UnTzQ26iHx5eMKypSfUMU3v6
CBhAPj036e7/AB4xduTbl/b/AH9+n4+W3377cYhUSDk32DtEeVPcducfgT94fkXcOPUWXstKBDI7
FMBh28ijuO2/lsA/x8+N6cUVWq6W5REEHJRDcNwE31QEN9wE3uAeo7cNpMxT/rTF6f7oQNv/AMv3
/HfbrttxuUhU2KPMlsn+sHnAAV+Gw7+15e4fs+QUk4kkEg4hPvEvLlrQsY6yk3kB9rFVrGTgFr7B
Wap0+EqFJuuIcK2OGjq9VIKn1/lfYrx+SxHQjK+xbxykgWwx8oq6TTdmVRWk0iqgU65AMF4iomtz
lVKKe+wF5gHr09nb4/EPwDgp8hY3yGzwxhDItmugWCmZFiLaagVs8xOSZ6u3oN2e1CXjHbWSaIxc
I0GTryL+OJGOVynr2z5MBZ/ScDMqwX9wp/r9+oh5fHqPl9vTb3+fDPSZhxr5GXsko26QClJLJYCj
1MvxZSCgPUzJHkD9rI2phOHOnuU3w9/4e/bb3h5cW+Yw0qYbypN6BCw7W3DRc1Y6zM/yK8mJNo3s
s/fMISWSZOyoNnMUM4hXYy2erJKAJobvCbGpkFMeWWIYQqJbMHhB2KYhh+AD8fPoHXfr0Hbg8K7W
tXMLp8x3nhKXsdewhTL5JUvE9hazMfCO6/b3Kr1WwIUg0d2lmhIqRlpCdj3pod4zSmn8iVo79aHC
pSGY6DVBwCGuFHWAQxKGchm4yGlBlaI8OuAlExMB8hrw8DZ+aodNsFimgYlyfUpKsuYHJxrLGK1+
m2qYucLU7bWDeHSsaxuc8ki5ljS7XYF2yYKKxM7+bKkTdexxrcC03Tffo6Li743y1D2CuVzJdpyx
kdtOQZsfUeAiK9IWCkJx8OvESjh89tsmxpVXdEMYT2ebnzxNdBw+dpIKI8qwuqqit6XM5giJJOFg
3qszB1Kywlcm6LESFgWbWC0sp+gtFpWmBPWMj1kvc2Nkg495a0nbZWdSliLpGOycXtc+WqKzRH4o
pU1ZIC+xMFXMpp0+sJOWcUj+UGPt0Ewj2jJJlX66tL3OuIni0Iloqo/IAQDUqqn0PDxFyT0lHKrp
GTt2ftOl2fDwlZWHCWuHszGUACS7DdJuTaYnulCaVo+KJSouwlbHkKCqdrtc2a1w41KvV3I16bVu
pSPhZVxyY0jIhwSFa2x88iZRqxcPJRCnqvFCql4e9n9Hzcaxntrhd4e0oQy69ihvylqViLkmU3c6
1j6Zv8zD1KHY2QzYV5eRVShKeysFgbryDNVNK2pNAMUoxmnlTPtMx/OUB/jdGHTx3FRWKbFe1qjM
p2zH0ehkKuZFi6fNyasmWDjnhbSuhHwgyMY3Xcs1kitSnBQnNOoekj1Axp4myqUWrNEnWRnd8s9i
LDTBWN3sTagucTTTE0hISXcIdP1aZPIxdOoR7kSSDRzKKFBRBQ5dCOnocjqwb0pgxGH/AAkSDRt0
wMmtOzip/wCHCYmuMs1PhDWiynaMJa9Zyxtg6GyDEVeRyZRJKdg3WQoWTipeCbQ8XYX6NNkK/COL
Qm0mxd1F3yxEbMOo0YSXbOSuRbOkjnbmG9LWacvoZPQqs9G1eoY7jbWnMStjmn8PH2+yV6Dt9zfU
OhtmS8s+mrq5iayMw9bAzd1mEjCrv13CLUr5WyOepav3FLy7p9yM5xsDGs6fUJNOsUZvbZ5rLyyN
lnLxcnqkxc5BsWTfE8Rsdj8LOpDnKu2YRsGgJh5EeNni/WurjjUWfKDZLIzTCjux5Qsb3BsJlJ+S
AczOUqTaKe62FdwNWOsxsloCwMS+ACfwtVOOTAUjlKKrdGBLpRe0IZhdgn9MUmSxImHLuBORYu5D
StTOlIMpDu5ArIaWH6Ax1ki7YVyrNRuQWJ8eYJCiy8/jacnLWKxnt7uCFUrUnVK8CEnUlHjSRm3r
uTM7sRzIAgsZblBM4lFp2isR6IFOiYQDqAGKYQ2+IAO4B8x93Be03MNDqeNNS1ecNLs7l80QNQrF
fY97rr6swyMPkOlXuIdWeSkV0JmUeoIQNhjylZI9oCy6qP1+coCM5MAulFiiA84bkENhA4e8S7bg
Ie7cNw+fTjJ6Q2LforUqTMoM3hnLv3Wagw1ijOAJcA33tPulutZlvubKZjTB11laDkHInidXjZqP
uspSGrhgMcs/sUZKSsE/aSRWcjGwzFiBFUAKodw3SABMqmUyQy2W8cZSlYSn3GznyMSwydGcTmOp
ibkZK2ybqZGFGDjzxzhm9uUdYJyNilWqLxkAWNV8yLNFancoAfBpdy0xwdqCxDlyULLLwePbwxsl
gRr5GS1ilIwq/hUm1bt5Odg4uV7ZD2jFlZxtuX2hDl68T1T9R1DpWprJOXI+Ft61FvzzIAw8tBpw
lazDjyFyLOqzLO30B8rNLN61kyBhnDuBkJWJszAj6EWnqXEz3dpNu8s5Lsejxduj8cSLBp2JzLGr
9zMJzfSMMV+ynxO71PhbUtsa6xcg4ss0Q4jb/NYs0/3KUazEU5NBtYfHl8FURtEbCNTbLjYmJwNO
WlxF+sTCLYgL6SIg3DteNFdmOp2z4vxtl++1mYmMaV+Ih6FjKz2CFryUY7q9LSWiqy3Rjk1Uy2it
xEnDMY5pPS8ZJsJZ+4QZpLqOVU0zSw01H16E0r5OwjC3ifRlpbUo0yrVnasVIRE9aMfO6Nda5KPr
ZPsCqlNMzDqdr8k+i38xLrGQbprnTFMSnF7511G0HIGivS5ieDtNfXyVjY1mhcg12Bq72HeDAvFy
P6YMvYvB4mOm3aDJRNZ6RtLTJ05hQqRwBc4ALcRNxEQRERYqjITLGgY0q+VBMvkSrXFR/SQaP1iN
Hnz5zHyayNq7oOSaNq7u1YLA2qcXY3WiW+fpMc3qdjcykWlOR06xrvMjCyjGQhV0Jdi/ZtVm7uLW
SkG6p2ihFhWUfPupTAebbtmZ9R2TXJmboS0QkhW7XQpdBrPMstP4qTmG8LQUpGFFQZN01dJQZGgK
DIKtnCbQFjIqAWd9TGfK1aXukcaTdahPwNWxdpuNeaBCvZ+HokZlrG8XDpWJa0MHzeLihkmAlXhl
bQLuTkX8cRwQ0gKZXxbIR8LnypS3pXKdeprIVHvWIYrMVwlIGwTl8eKUKi1+yRE4+Uk69LzD9tBw
SJHoghJtEXTlNJwIIxYJnECcEwBv+Mju1AlPyyct3EtSbTaqIKludmnIyf5X107ntV7QMrZDxS9z
TUW+LWcnK5uqx6BZISZg7GechGjScPONyVmvsX8S/jpOOEih10JZrLLtwTOZQhAII8e6/mqyQWA7
npzPRIdyzt2VoLKq9rdSNgLYYqdjYOTgo9BtXTpeDEbLDPOk5AQUApDkUIoICUwBaFpPyDUp/Xzr
ANYLhByTA2G9TMFSLW5v7GLROMffqypUnlatsnKkPISjuuNH5Y6Rj5RZR23mGyjc6iTpMTjjpbuq
riva77aVr3zJ0JRoy3N7eaWjiNCSQ5AVjbZBqrvku42JKwNUVlp+FGXbwVwSSVPLupcpDCUl3gmJ
D2a+kEpAYyKTIkMWJkCXnuIrXlx8cIRNglMxIKJn1c6vJ+ZwbetUbq5aVsYaVT0k0R+TCy2Cyp3r
1ofyE3PL280uQWgwQEPBxLRqdy2JHiKxCHMugCO5lSAZx3bXLFzWOJKosak8JerBhnGuDpaQfWVY
9RZRuKGsDDFttKryhe+Q087TpDbsVHciVZTx6Q5BHtDbzNjW1Q0H6OHMWSYLH8C4vRdWLOtWa8S1
LrDsDVO94/sZRYwyikcYjdOAsEMxVQIkYAQWcIF9k6qfMY2P8RUSzYUx7LoUXGzuRm/Ru2eVkSeA
wTDG7G31mUx6DrJ13koyNcLf6Qznv9p5ZBNykzN4hNbTI+KxnNaFAjq9oa+p/WLKdQlQuHM5k1cB
paWmPeYcFv8ATRSCzukiXV9PO1duRNbmPbVhfRvjqvVO+NbtplfxTl9YJuRgHkZPNiT0TMSqNcYt
l+9xgsjtXItAfAAgDZfYNkVOUpbl6SDR7kayVtfJ2Cck5BgorKmcMyrOrRFY2mJdF3eW9gQplJPV
nltRg7XTqy6IeVcBLWNKLaNiGcqQREiCcsT3WMpFx9FrhrJUBhHGtPvOPtRLvG9ivlepkWWyZJjY
qoTsqLy92JdiMlMoWVf2ZCtyz97V40+xVYwhgAOPOuDTXi6MjV890BkWCpbS3YWjbzjOFiomltEV
so4xJkSEJjxGGjXcElHqsIyXavFFmh0hGQIURHtA5mRDv+xTFN7gOFFg4qZO4+JwWObColOxgEfy
6ge8oab93mdbI8A6z9OGEc1S2bPE9Tt0n8h4ey5UMjzMtXMWMXrCcss3GOq0FMjq5kdinFUiisoF
tGoPGkiVauLHTbwFWdqHKUd1XNfWnWoZXHKcbjezMJ1Sk4NqUvZn9So0rI3UKenDFzBLSVXPYzw8
ZM5RsCKio2l5LylqkVklAsEmxOQwAQNLxFp5mdfWkmMJgvHMdh7PWnLFlmY43lYKPssQ2np3Dozz
GaXBd6m6nLaynfzt7aZcEHsiPtmZqD7QjbdfRb2w+QLQ4b5DodNxoOMrjnCEsb9odFy3p9ZuKFUX
hnEMY8NHpSbWSuLJ04annQWQCKXFUhRQU5YV7ekBS413WSBJZA7RGEOHBLykTQanEFH8PRIQrwZn
ItlTwM99veKtZGE4PJmqGTMSyQOL82aj6dl+DgEqwsdonj6GuNzez+PLHVox85iSG9ULkxiWMcyU
JBn8LXSTeCKChSzM+10aS4/H/gWFcXYWocmTMucJywM8yYRTnGU9iK12exyePYVCOpxrK3tU1BxM
hFsywNxcrMEhi1iFsxewUAAeqWM8O4uyZIUW1T2HMuIyh6IEFkFzb7RAY+j4Gd/+JmTcaZBv5t9e
xEPzFimmpVj7ew6Hy4KSU0padKRIavbpkUbaNRxLlyDxpS6dCSLKPtrVhc/WPwi2umLwxGU0dT1V
hRbITEy2Kr28x2fN2S21dh0mLuCuLdogSwAxE1wguA7sKEuQHLs7OYbofcOXvH5eG9++wdYmzZjr
HWBco1bIzdpmGXuMcWGw/iyRVk3UBhiZayKiluyNNNpRJFvBO58juIPT4eiuZA8mWEUNbSNQgoPv
exxVbafA6INTlTsN+qQW7IWTsEy9DxmjJvn9rds6aXJJ7c8WhAMZGGaxpJSOOxcDKJoypZBiYhzg
6QFRk4S02mz6ws0Lj+ZQJlOssnc+2x085IxOyVdgH58alvI8VlpRwy/82MmEH3bp2wk98jYH02Uf
LmmvVXk13J2Npd9PsZQJlhBoFhPUyfh7zO2qHFo7alW8TaSTBOuo94QOJV0Q2BQpduETFvjHrpp8
I+Xdx89ZGXCuCGbETKpL+7z4uz2r8iXYsZSNlyJN3Ixsh4mdm5EvdHSwf+SW5hAotPt9j+XH0iak
tOOkXFuoWqY+yRXMb0CnJ6oopqzb1B3EVmSe4SmawzskwxtsnCyDufasmluGCh2sxZ3kc2BGQk24
LAbnJx87XZ8rhYpEW5kh8ilEo7/YBd/jv03/AMi+1BULUxYAr2W83S8vkKTyC+CPi7e5nGd2lJ2Y
RQTctopjMsT9v4ks2nK+4RYt0DulEGyapEhTEpuFrkYghlcCBFjOS+MFIc4c0zEnmDoBYqk426xF
DTg1e6yzVnVp6vVDGbyfwni/GDl7ZcnsGDzHkxDgfJTGLkYY8Y5l6fGvXasG3g00lTwiykwmnMkS
UM1MqBDiEvemCoKdE1oW5nGKv3MRI1unS7RaWskncXiKylc7B0Xxx+7cPSmQX+hXDv3Mkr9GcCnA
QEXrVpbzxU56vRNlx9MFsVtmz1WDbtJeFsjuUsECk2XlGB14d/ItW8jFIPWa6jOY7i5fou2ygpmI
4SE+itVPzXjd9AWC7Vidi5KSaumtYc3mGi7C/eFi+79qxgk5lhLgg4R7017VB5EHUT7ygJyl7ZPm
68w1xF7XZhCSzs5DlhUbs9QbRBBHsxTGUnbVZurSj/Q+FjT9GNpawLqTa6lZTOTK3ySOLaPTJynJ
VGbaRgtpS3zgxCcqoChg74s0IAdrHjzGTLvzFDYAG1VT0OOkmfqS1lgrTlyMY2lrj6m0k8gWGlFI
XIFovVkx4raLX3MxvEmQvoNo6FBoIJ7KJm39su9A+aXOX8JXifxlIXmNQkYtRmlLSWJK88x1Fzne
Fk59FnJJNoXHMzYGTQqqa0aM1AIEMmoRRIRIcojo6LmTUDZZ+qUaGzplaBVnrJARMH33K91iIeLk
nEk1UhJt6uzsajds1ip+fdWVR2qYiSDMh3xjlblMqEk3eGP4ejr3nGlRdKWwJCCUCRAcitZyyNoX
Ajx4piXeMVAe6SAnUktnLP7WtF1K+jj0+YAx5Z84nvWWpfGB6rgyfqVfimdMa3kxcynySSVVtKrl
16tuyRp6yQjc7JxykOQxQHcnEU6Uq1i6hYL9IDk614qgcjSmD7bpnRrcDnPG8Oawx1Ss0tk9jYq8
/jbE7mpSqvrQyiItxLrsXyisWhELrL9mk0VEgH2TMuoNi7lqwtnnKkuxiC+rrpZPKNwkINzD12We
khEGbF1MKoLU6JNIThY5ikBnwDIlKmO6pQNt8On1JZmtlmw5jC/XSalc8KgvfoR3eXLeFyMrVyvT
pvLxLWF62Qm0owkhOHZKyqj4hSSJTENsqUTAWUkNdoUYsUucIEhgcMHd2MwAJmTWIIcTZhBvMIt7
2IPlxH7Dul/TToPndT7KjS0TfImqvcy5XumLKKxkWjqWasHGN676yXB7a5hpLmkkE4qtTEKSiKQa
FhCblmXY2MaksTlCuaXMm0kF2qDlR02IsudiVREUnAFV/VGcEEAMUFP2BMGx9/ZEeLZ/R0Z/l8HP
5S5s8aZWy4fDMhP5nQj6nOM0qFAsnVRWr9gnbl6xpyLWtKCd/GIhPV6OiJyZVi1k3DWznbqFKD2P
pzBTODcR+UsRWe+WAr98uay1/JEhUSlbOP8AZUDQjVupFAZn5qEFwApeZ+Xgka7Q1ezMokRgHo6S
KgBuDGpcuzTIqItTMop4f7T9tJPYotFmIcc5X0mekcst1roS9pxHjfEtpxzLnlHrROvS8pZrWeeb
uIRk+IylG0sRnXzpd4RmirkYgYnOBOI4wh6OvULn3EVwztVYStRFFrVVvVu75cHb+vSV6hKE57nZ
HlOWctHbexMGzwBaN3Z5Urcjr83FQFg5OOYGyZn2mw+o+s6Z6NLTOLMvREPVsi1l1SVcrKRlQYuL
PIV+JWfOUA7s4Mwkrk9avFjEFVpBouUjGRbHUJuMaekM1P4mp9Lx3Dy1asdQp9Ru+PIJvb68nOPF
cdZFYA9tdAfS5ZtBd7XzSYeIsVjNzSiiQAumcShzDaElcOGYUaKsue01AAmWcyzOHYF5thUKNCWv
bGCx23aeqezIVlLOYffZgsdM1aU0hzWoMcv0ZSbJk+EpDGlKkvIPRZGpTq0P4BNY1Y8BNb3T90wQ
KqV16tqLwzpMLUJ2qoEk+E9E9rCnscVzIrCu10yFoxe/zPCU81ilxtq9JjEO9NXAf6tjUlJ5ZsIO
Eogl7M5UQ+lIkKY83ERYc1C23FmNrljkuKsf5SqdvsidqSa5HrK9jja1cmFdf1Lx9Bq4M/hJZwFb
k42QFhLumqgPZBiYSbvG/aEWl6S6/wAnjelUS242rFpsWMcKO8G02bNe7zV4ZSqd0CHYu5nH8BJm
gZmXryQAApzj1ss+DoJTefF/ZrlshEEIO8w6pMKyI94jSTirW68C8lhAUFzDuWbsjJ2YBhPxlapU
64goQ5g7QigiVM5dzFOb4EMHQw/Iu/8AhwTDfT+9V0hvNVJ17MtGsc3BhdRFtBRitRQXSo9esTWS
f2hOfGwt5ZdFVJyhVV6+RmqioRZOyimcphitWsUVeNXdqZC7lKt2ii7qDcUOzKN0XKJhItFJT8A/
cw4RyRwMRWTCPBIhgEp1CmAeCnruqyiRno+Lno6m6lcD3CxakWmd4i3t5OumrSLhKrUunNaa4jiu
O1IRdCnvCorm2FUJVuBN+8J82SEpgqipCllUcjECB1R1aM1XLGshYikpWA6mLB+PJ5Y2iixaOdTl
YqDy8TeIbOhTGdThLw+mU1YKcjS1SS7wMPaEW0dPKLGrqXdXfic2UwxiPdl+2dF7FTlbJ8N2RvgB
PP7iRA1XlspSGM0Yh9EWwx3z1hVoWyBNjaGhAqisUVVM8EMeWaNdwAh5YY7YonCxap+kgx3BYnf0
ZzSsiruVvRbWrQ2i8ZqVtRgbIVhsdyl4XIC6SljjUwx2rCW9mkoBtr3EpxbgTVhMjdQSjCnqWxgP
o75TSM+QyKnk5zqykNQUbIJQVTcUBSFd42oOPlIY02W9mtTGwlYx8rNC8GkFiweyaRxADLlEzF79
ju21gwExEojqIUvE6gkKYKGGXXACiCQU4mJdM6oTEQ7ISsFquGfDz3WjLIumvP2NMQY9z9b6/Px1
ZyjLXSEgHztja05pqwrKLWAkZSyd4gyNIOHnTTzpGut3tgQmJNQihGUcscpihFhsn5wLXHjcMgZR
CmvY1SvO0gs9rGoOYsYszOQrjrv0maBfMnMemo6CEFI4makOuCIpFMfgqZ3U/RYASIC3f/ekDHmF
sh3bPTC44oXzG+im0C2g5akX6YyI6gpnGkXdJWTu8M4i6dDn2GyRkJUJ+Sa+dKB8HCeK12qwuhqZ
0ho4ixk+fyOXnWSSZLeUqrC+Z171Kr9X7dIx2Hipcq9/i5h7+V8JcJ7kkCnBwBVQMJoxuabwiEqJ
FSgs8QEhiQnKY004gUFsomYHd/t9T4brO5jpY1jQOKH8EfIzmjt5bClgzyvpcfZWtNcyPasMtlh8
dt0diRF74RKMpNSpTs2SOl15GWVYwKj0seKCkcpdRJfandSr2PeMX+ozObyHc1U2MXEa6zNkh/Bk
xvIt0oIuN0WA2A6Q0pTvCCZKWVt4Uc6yJSxYmUIA3R370p2Csh5RpebRY1iuw9JwFIVVelPsVR0t
qVnMplxJbcWR8BV8sNI41YjcGquLGlY3rVS2xEgD59dVVcccz/mso4VLP2lOO0vy+KL2/wAZ3bWB
NUKxMqDqVkMTnn8dY9x5MQyrqLw/LS0v3GyNs4xzk9vjqzl5viqwRmP1bRDQLKyua/HoPQYvUC63
iGhabylEU4cUPaBkOA7qJ91mVhecx1Z2F1tB48OO/kTryz3RM7VZriK6ZmskxbSZQxOysWJbTLX1
K9O1MXxExKQzWPavyzEo8iq/HTbR+qvV0npXiCku2KpXiHcpAdoVTP8AmipxMNCVfJFvhYqBbzrO
vsW0skKlXSubMsBPxFOnUUXb2qIWRAxE51KrLRvM+OWamivzCCvF0deyfpZt+jikwuT7tgKZRpHo
9M5VZjVLKhFyWZ6lqgPcLvOYuTx64fwDe7QUhKjMwikm/jZdzGzJGhTWIjMpQMNdkbYNO+m/ENmr
5q9j/Udqay9Sxax16TdtLJhzTxTLhEGYJsI2Il2CBZrULFyZ3r6Re+GmqtGIypykRZ1isXwj0a6w
oC8RviU0DY2DPhkcRegOrEGTkDnVoPHh+eatXGlq1nN8eFtmJnOZE8S41c2iQmFKWxkBxeVRtDlt
OQAyNEQLpCo5EM7qRyNcjBd4O1jOYxOSBs/iFWMEaOjY6ycwsYShV6QZ4jukRjFvMMsex9/wbiq4
FqsbOTLixScZDFmopdg1iHViUmXwQrcr2POzZxMODAQMkmN5+nXJunq0ULRnf4GlSBaPgjHGPoTM
twa5XYYwp2IpTDNtnsiat22Q8KRk6s3ywGacRyUS2GQWh7AGRyR5oITpdkZIBuxnhrRvnCvVnJl/
LBY2yna8t5jmtJ+nyGXQqrTWrj+LkCTWJabe40FDM8eo2i5pp4zibkmeBmZiqIEx/HoOUYqAXezF
uUYEm738EJZiopGIFZTIJJMgAp2kFA6sIlp7NHFz8k5jn61s471j5Or9HouM1sV4NzHSsX3Gy5Pq
tbyhhiNv0VHWeZcV6Wsb5+k0k2jR9GqC0g4krqZijoQ8ZKRoHUSTethVfeDfSfZj0/USex3Xcd4e
sVXm8/Q2peOSla09i0ankesvalK1VtVYSrTlbg0aLHr1tIpaW8YiyTOGwOwENuLM9CuPKzi+jSVr
Pi5dzkvUZg3W5J2qXiJSzR9Uw61q1FtVMpunJtUVpx0wlL0+nk3M7GFsSruceNrBBOmjdQjBqoHz
KrlWKmmQ3MU5E0EjlEBA5VEv1iZiiG4HS6doUQAxP2gDpxndLGLczdwIm02wSVE9kbgzgsz7nEha
YacYBJZy0uNfT8TkXLWWLXmfI11ytf5Ms7esh2KVtlrkEm3cUZKwTH68CoohEg1Zh+0f2SAHmPEV
nWKfblMBt/LYQHf59B/D7/s4RrLrfW3S5/3eYvN8Pq+fu/Dy+ApDH7LshDyDzN7g+/3fP+fGDETt
KluHd6WttDpzy/Imr7wPNyb+x8fd+P8AQ+7bbrx2p7QKqFOBjD0AAEBEfjsADuO/8vuDjWdsHNy8
xOb93cOb8N9+M6SvXzDz9w/y/wAQ/wC3C+E/EeW9PPi9YgwUnPPcQPW2HtQOPMmIFJtv2e+w7fES
/D57fAfszmFQPaS3KHx67bh7t/L3fH4cJR7QgjylIOyO3TYdh+A7b7CIbbh5+fl147WUFNLlKoUT
/uAYBP8AcACI/Z+PDVoWcdZTeXcftbvtDe17YfRfU9oOu37uw9dvkI9OgcJQUFQSgl0E3QADzN5+
QAG4/wCH38YecdgHmDYfIemw/YPkPChIhSAJybGMT9WUogIm93sh5m93kA7j57cJ7P5vIc/vwaLY
fb325Cb/AA36/htxj3D4h+Icd9p9NvuG2/nuG2/x3/w8uMfaKdeifTz6l6fb06cdtDoOeTyJ9bOc
BNvygJvZ/ZDf4/DfhOUQV3R3Dcn6tQR9k3902+xv/bv9/HkVDE2WA4CBh9lMDBzCAb/VKHtD9oB7
uu3HfUoI8iqBtvPlUIbb7dh+zqP48Dt1lJVOcSpkKmYpuhTFEDAYN/2RARAevTp+HHSBTlUADGRO
YfJQpimIPw9oBEB8uMBljhuI9nyqfqRQEDAn9olEQD+g4XxpSLOEkgII7eewCPw89uofaP8APpxT
B8x5b0+mk+t7WMVBEAMPOJg3KAdRMHluHnv094bh9nGMDFEBECiIH/XCAbgUNvJv+98uXf8AzySz
gUnPY8ie5EeVMNwETj8CAH1h8ugb8IyKCRNIp/ZMUPaKPsmL8hKOwh8Q34hcPG3WKW04g/a3WUlU
SN9XlN/d5R/kI8c4TpnOcRKn2RTB7hMUBD/2+f4h/hxzgloBcA2MH9aG+6SQf8QlKH4jsH9beYcI
lFFUlThypqplDdA5NjkTAfeJg6AHz+Pv4zJKKHT5DFIU3X2TbAO2/wC6PXb+HvDjgmOAqkEEgKZH
YoiJdjG89gHfYR8ugCI8eotTZjU88nkT6jlSquOzEg7bbeQ/Pb/P5D58OdPtSmERIQC+fZeRv+X3
D8en8Q4aLFdNN2BgD2R8jBtsP39QHb7env6cbzxtFEOceVU3wKYDD7vMA33226cAFRxsOxoWDPlR
tGl7GeCZWozxbriyz3iWq9uby7IY5eFv06jN2GKcRJRGR7RkLCTO3QGT5wCVRECgC5BMJCxVgHlF
MoGEegCHXp032/wD+PBo6b7BG2HShrWozaPh17dHo4PyDWVe3jWcsaKh8ikrtujIiQfiC6KkbFKJ
vHKLcRM+aHI4VAUDlMIVKSzV0usAlUSFMRAhTAJRMb4FA2wibf3AAj068aN9ui8N1vBiwXjJ6ycU
khg7b5562UQtKY2zBcTnJ9KO3c9uJqJpq7lABD4h1D8fLr8/n8eD2w/qNgqhpYybhKfdWleyO8m4
0yNiZBozbqVKprV2cPO2lqvKvJoxoRad7M6qScVCrnckIc5AMUphAEkk0g8tunxH4/Hy+3+PBhad
G+PZuqZ+p1gpxLBkmbxFNWLF9tWdg3bUwtHkYq6zZmrQxgLKyNmgK9ZIIU0iqqsHCrhrylUIoQs9
FXqMiLs4EULYgddKQJ4XMpS101la6+vupvoGsYeoDW9jzLlF1IRLOvBFvM0PMMzlMh4+oM42ShbB
Vp6GlLjZbxMoz7hrLKPDupOIqDmHNLT7OOQhSqMK6msgBhJ03WOgUzPFOSu1+K6xOxcJ3axLwL26
xVbf26kY7mprHEU9aotiWZ9HxGR4Or1JQp2xyySMo9kSlUMcREha3ibHFkwjUIJuxx0xslowfbsh
QM6K1xVyhK2elPck221g6Yd19QGtMY1mKdUgi4vwtqJk4KQMzKLhsY4KUQ9VTvMcnaKfLZJZPGz+
JZ0+JnXcE9sNymIzwmoNyyUKi4m0yt5j85fpkaidI3VQpR41r3Dv4vt1iRY13Rt2cJIdIDGQM3FJ
8M7LwM+/7Wt4pufcHai8Lw9Y1DXCs1WxOMl5lyHmiRXeu6bPSrC1VS0zdRlqevWpdZna3tXtDWu0
1jH2aJllEmjMsiQocvNwxkJjCk1jChXRSRpcGjhmhYdcVCKXt6cwgxuUBl6sRV7h3+BZWcRYKpWq
FWsuQ5V7BVZr4zOOVci2czF9zz/DHV0b1KVms7lQWaUtXBVIwkecx5IXZI6Rcy5SLWa5OxbrIr48
kdCOpkxOu66VNYCOnMkkrVjzfhBDOQa9m0EXKg4VbXSZj5t5l2btV3ioDGUQpV2ScHDY5VUc28JG
PcvQt8y+PXElZtonU42QUNDJHkgDuRDLhow4t+RIXeArIO/y7s2ppLRxJMNHYjxE6skZlP5+urGh
rZsNesdLqs1jvJNUhLm81G2GCoVnTskdNXex1LKULHoSdnj7LFSCthptBbWGzjCTVJYjHxLaXUJG
xr1J4cERHy42eGpmcbtpmUx+tnOxs4DDWOY/J1Sr0HYMrvZbHMjEWW4SsT7MwxeV/IRW7iBtzJrI
KSg1FBaGvYv5VJQoQSz0XhZMQ2vI2O7c5v8AYKzBYilJCChoGFPH2uRyjYa9Sl6pR0fWpedcSFOs
85X63aRutei3Eu9bpPWJAcCXfRZr0f3jTQ5xd642lJKUyLG2g7pXHERI2R9XrlWbTMVaUpHYKrRR
bVdUXjtJiu3r7uOrMK8clbRji3rLOSWiLxFvcCIFm7QC4AKA5AcAzYSlqzuM2fkKQil4il9QPl9D
+GkWNvoeP7n6SjLuKKBVadJ0SWpuV/DYSDq1Zk4erS0NprnZt28aPWDNdtDBBXse6EPAHjwayv5k
YSO9kuKYpHskHAop7G7JFQpAKICJjJG7NUoFARERTP7CnvIb2TbG6cGHVsBZQY5woWHankP1Ut2Y
YWtC3lZFax08UU8hx8u9Y1zI7GFScWGBeO45w3j7HXI8JqIRUXRScuCmVIBhbyPVJKi3K3VGdVbm
mKvPS1elVkDlFIqsPKfnayZgHYAdfsG8lP2d+POdJKT712iQXB/lpxV4jX6by2jAgRqi8w905+79
AHl6WbUW4Yt5KNVepg+ZtHsU7el6JlWZs5HtHyW/kYHKYc5fccntBuHnYFmvD0bkPWXcMQ0FHGOJ
4Va7vYqnA8buK7UImulbtX8IgIRSk9ZXclKVN8yCNSBAz59JvGqbWbVUcJFNXWicwiqQOyEgj2IC
BiiAp+XMHXqQfiHTb38FXmyiZapzbFtnynkONuM3kih0nJFWbNLTK2WyRFYukTGStWNJO5BFnJQ0
0lDumLdslGyrhZQsM67IDA0V7MF1i3ZN3u4VdYsXYsxUlgqjuQGfhnMNmbZK/uqyyGWH/wAfOxJY
Yw/g3191UFvEDY5So4Dx2yliUufmXlYyDMJFyDW6La7ustWUXUOzuiZjyTZKvmmy1Lt7wgi6c2JR
gmQEVWwpgBTSnlPUBaJK3up4M5q4gxpX4l8y5qsSXoVmtNfkLjEMzRcfNM5lnBNH79ZosLKMZqJO
jwhETlOMV44i9Yl1n3jCswtsm7JmjGT1KSez8ZFFe3PFVfJESzucfzVgI6QLCs3kMxkvWw0wLaVl
125HVpsy6qYG19YjtS0jB5J0vVOqKTbKtWUcnZNpjOAg387B2GuPGtdLYpK5NllZWSGK8edQcO1Y
vg8aYJqJNu1KUxeNeHGu6P8Ak4inaqTIOl2bcCxyYVEjy4MVbPeIQZqLr2avI03U32mTMGl3GuJN
IuCs3msc1Y8i5taS80okyl4taBimsa67lI1p9GoKHkG60e82aPXD2TlTtHX5uv2avscNPUPpRp2P
WWn6kVyzzM3lTLlRw9ZXqNgUp0pRI1DLFRq0m5dwdkhpE0nHtq5KWJatxy8wWWSlIjebSOohuqLN
s2Wc/wCV8HVLET6ltV8WYDfuCxs1XqE1bPqyFjZkcvWE9elTCLZxISyhH6Ld72Sq5DkVIU5TAPCT
KGZMk5WYYbtVqx6xjK7iSs0LFNclIOKsNbibHFYzZNomtV2atPiMy2mZZujUznkjxc+o4bkbrCqU
pUT8vba6bQDZxwgv1sDF3S25mkd5lW0wcYBxLIkNM8P/AIij1zcWldz6PAll1YwukDHGQjStjTuM
tWLdYbXWG0fH12SpJHSr6Tio2vu5lrLs3xIFqeBZM3UWRiVRM0oUQMXhlUHQ/L5FzdlbEdIvCpk8
M0G7X61Sa9cmhnfBMfTNUhpWCjKXHzXaurqScsCizhg6tMZXUVEjFVsxTRcaFy3kNq3s8Fquh9Xk
3iOLbySdldXwtHi5axQlemJB7FyYSnJPyiUhNuY9wMgx+mTSOibvrQOYe8pc+6wdrIjcV57zpm+x
46kpmAzbRswVBSnRFqcw5IX8pluirAs4SmpEkkR0SukhGa8ccFBLKpLIqI9oRQhhGYd0ygNIUUQ5
cE5luGTSJeUj/hxR3DP3fdrQpjvSvaMlLZXj67lSsQ+PMUS8QnNXCVUtLasOz2WamYuuSTZKFBdW
NBduqkeXm5duVKDIomZysiU5BGf8Y6DdT2RaRj+KpGYKklSMxS2RIiq1BvfroRnNGxxJSClgPMw6
UD6qQsTOkrAHQWeyUnMuipHMmwMUhtohw1nWr43o+pOqzzG7OGebahBVqtxMJORjGBi5eDnwtRZW
xC5MC8uiWNEGgrx4mIUR5ebrtwWmlLXdjnBuOMWUa60m8m9Q8mXm8ypKHFVRWKy7B3eqSMerU8hD
N2aFNLsTyViXfA9XjLGkcoCoBhKAjw1dbrciP1caJUSXYgBqmbl/MzaxrzEvcVgCkyAbCMmE/wAa
WG6TwzqmhdLrjJNhypLq6eYfIjXFDTGjnK1nespGVMzn3DGag8eoqStdhqc0Z1NzFsnjltDHnF5h
sg3iFzrkKbe3vDmpuUoLBtZcxP8AJMXHVnHuUX+E/wApuR77aKjF2ivKNKXNTdBk030bDuo2HsVf
qjpk0VWGBkpyGjFSoOpNiitrWOb8VvMOahqHYG2QYGUzRlSoX6sRtdqdYm6JV0II91Si4945kshw
750s4VtzRN6jFwYHBSJdEOXmbKgQl6b6Qul09/PW5nDzb6xTGAqvjOXp7akU6FYEvkEXELOSuSuW
0rEveZyjMo/FblRrWLBGv1iTEkigEAC65SmmDdrkYZh3i9JhhxNKy4Dpq5IJ96UpNqbDaL8Kaams
vXuY2i6TxZrjiZXHMmXKVon7vV7JAY9r4M8pOXNqw5ZEoV4zYVSfeO3KKtHSr8XHSEe+YElCLMVG
L1FwkmZquUmezQWv5rYakg5s19yLJZPh5HGFMUZSzXKFNtVdLIOZqcpaDV5JydVVYIrQTScsLRs3
UrzFisi9evkm6hFBk6w6t8BZXsOXU725d1nH+eMmVKxWNLHmJmtdt9Agj2i3W25L2iZiHbBLJd+c
rWVaIY2E5rUwVjjqgmYUxehZXLjDVxi3G+XZ2ySuV053DMpRsuYVxBi2nwV2TiMLUa6rV9CtTc0l
OR8LGmdTiTKPfXkIFrYJy1Sqk5OTikrBoODkMq7XFYH+oSCyTJcnYZlgaHuZ2BtGK9/Clv8AEU6v
ofPWwH2QmesUXdBvbajCPrbY42GjY6vWKg0W7V2TjXzjusCyqMCLOSpTZ0dyAt2z6oJtzKuAFFIx
lA5Qe7+8atLG6zxiSQpMhZrJebS2s+bYscftlLfXbfDqyCKbNwYgGPTwj1rCukxSaJCcFeZMhecB
LwbVm104ep1WwrRqdWaDe8gVR/aWXr1SSv61Q8ZRV5uMFLwspjG22NOMuMDdaXV2rFtJyZGzJCPr
a1gjKVPPJVGV9Y17+y4xsmrjUtmKs5AxpbK22l46645x+jmKQgKblXLNqKZ+xt9ucTx2UVdazTRJ
a5h1HGflar2KThK4oAPbDKt21lXO7ri+zXe+JXDZ9qqJ1pM0gWYiYcuBVjITii1MBDyzPyv9Dy1q
j6zlzIuLK5ZqPUH56KvbjC2t0zArTELcZdglyipUVpxB+rYU6afnJ4nUopuVna+cPW93L8wbyLhP
Uba8T4f1A4lrONoOxtM+Q9ZgLldnwWKVlICuVx7JyjRhW2Uc2Ur0WuovPOipv5FyUTnTUApxEhgA
isPrQtPyFqLNny64gyDippOxsbl94QTXWw5Fscp4/wCCu8AEke7L2SfT75IeIycsFdi0uzg+1Evb
thNI/ouynmIPWq2P2BKW802W878X0iCcCjYFdvVsV3EpIgQ02vuXuTWLjyunG5ewTPuHCKrsgRLv
DN8htGHWU46oGGk2JBGedjxocRUIREQkkyzJFEzfPU+G+1PwrmMqBiJkIAm5QEdgATB+yA9A3+XU
R6AAcWi5i9IsrltOOeM8fvYqZg8z1PNVaI+thpmKr9lhWUbF3GvxkYszQTjK8uhANzsvVwjFBQhi
GIIlMA8VcuDESWWPtsmmXtkyj051P3S7/WP8ShuPx8+Lzs76WKFgjSVkqgVtBW6Xqr3TTjYbPmGS
K1ko2zOrvWLw7l4yjJMAUew+Nq9IsIdo5arTHbvHUgxQVP2rtuRWvR8aMLveBAjloCmBMNEyohMy
JgkO5GVdbHWsoSCBlTSnrnYJJnMOJsgZmxzYKAneqvMzeoWHyFY5DKlqhE6PUWi9uj5dZ5Wkol8d
tDpvZMs9LyM3Mx0pNlio+NjVGgIgQOJc9Ixm/F9nlo/DmK5uYtLTHuZs131xkNZ3BOoKQTyv6meB
Q1IPWLA+F/CQvqa+8ONOKoofpRDshHt0+ZPqY0fYrx5WtRcnjaSuyCmm3IlHoM+7vLltIo3xtkrx
/wANtdPWiQiiRK0Z6qOBVbLmEEvGWnNyg6S7QJ9M+EJnUVm/GOCoOcja3KZHny1xjYZdJR1GxbYP
/EwIyhhcuXck22/MkdxW6eyAcTHjRMHsxhoZLK2rnECwL4WaQUZcgMEwzCgRDEU8Gkgyg6Xc1FTQ
ZGxQay8sY711ar7BkXE7xWjQ1orUAZb8vTuu0xylJw7KCiSdhIQlhtLYVZVDczMpZfndE3MiChdu
IPq1WDTPmDCV8sN3pEzCx2Q4a0SL7G9lbWpeKhq3MwLuei14uNUQMqpJsDFjYVFQnM9WEqLYFTmA
vE9VvRHXcjPdMqNHyPIDAancgZPxrAmvdXik5CoXLG3q33tWzMIWwzTQEZr1wZApJwk7YJWM8LX5
qqTu6gEftS9FLk68QFPtlMyZi1Gm3HFeTctHd2VKw1d7F17GU7XKnaGvhMcSwM0n60i7RdsUxnCn
ODkDFD6V0NnXTBjQlbVECEuOC23WpSVBurISEikvWQOVbwgiE+C8RQ9QEjMjymQP3ZDhzVBp4ptz
1zTVgRVf17MFRs7nCIq1BeQfxGRDWMbJVXKzEX51adMVNnvHoS0URRkgt9FXJ6QN04m6E1B6NZH0
qLLOcQ/olV0sDA9nMGslBbNK7Ivl6L4Q7atKK1q75qu5ezI94TRlGDRVUwbkKI7cVi6jcBSWn6aq
sU4yLj3IyliqkfakXuOrAFgYwzN/5xsq5VUOjBzJvcyQPOuh23BMeF2jPDdd1D6k8UYZt0qLCt3W
0FinweIPYmSflT/2SuVeUbpTTOMcuA/2dZ4btVvJPm2DiBFviLyq6PDTFUkqVIYAkpDkkuGADvSp
Odr+z3B6reWefV4a+eTyM/0deesb4rgNY2J7zd6RU3OacNydNoVvvKEWalO7bHvt1G8tNv45+5aQ
kgRdNRuLuJlGK/MkonCGAS80JaLcu6R8LWrOJ9TeL184MJrHc5RseS9eiIKxxsRa0/8AY5WEhry7
jHUajL/+h25+Txqu/wDqjcg9QiLEemPI2Z4jJtypz6txFXxU9pcfe56wzasMzrBbe+tUXW3xVACY
bg3cSVdRj3K6xypnfbNOYXH0fEnYK0PXzKWcsl4Ut6FjrtqxJU7fNWWKgPVeWsqEnS001mULHxVm
sVcYv2YIqpKysgnMHI3TVTOuYpTlEV4UKMBDJZ4RxE4ilyAlLvLCwQJvOb6G4iQJDEqTASG7xqa+
rHxpAtuOLpp4xVRcdxLyFy7jzJ99krJOx+WQw4lAPMjzdbcY7yZd5RrLR0plWCqVMpdrgFncq3lZ
FkQW8Eo0TrdjSfL4aljHRnqDtkhcb/EVjGNRtmf8nO9MkRC+A0xzqiryrrdWgXRAWgGx7W6xMCyZ
1qxAWvs5iOsk93RdVOvuuwr/AMA6IMmahsLZvzXSpGrJQWEgrZZOvv5NFGdsbm3TRYtMkeRd8zhI
ePBvFTJ5pSUclSlE5ApokwgoAjAlJwBnfIsGNux7jS4WqvsJSRiEJ2BiyOUkpFizZTrlKNfyKpH7
2aY+JxqlhaRKE07jyyDEz5NIHaAnfud92gUFXErKVMt8SiFKwqYviaSgQCHCTIAM1bwiHIovUVDs
ZJTN2zl3Hxza4LT9jDU5g/GNOtUXi+UzvZdQ1byQ106YMYn79hDDjBQ7pXKE9nGnPVomnu5yTUlG
jjH9ZmnNoYoqR89MW2zsLI6jo8uv9GBQrnYLZCV/LlDmrHRLFgDNEthmDvVOpkpprsUVERjd4+se
QTsQ8QTtDV+6bN2krb4FxbyKrpE8QAxygNSFTU1CpVp5aKO9zI2pEMoq2cz1UlbQxgYcjkhFFGKE
vDyrWOiV36ayR36B3CSglUTMoXlOURk7ElT1D2XTznjJFBy9NV/FmAUaOyyLj5HIVvhiyLPMbl8y
ro1ijRrRWpPWjh7W0mk/HPpdsCbkvd1yAqAlCYt8gw4ZhG6rDhsWAyJIaUnDlmcOdHDV2ccNhvEB
LaLz6vpywc4l9OGMM+aPsESjVm6rOY6Po8zxnQlmjYqJTrttr+FL/kV/NRlqXTOE2a7mjYBsxqs5
IIS7BgcxE5ERMJQEAGGn6gY/xenlPUZOzFXd3+jWtxgbFEDErGyLdHSsQZhT8nW9tYU2kRS8Dnkz
GfFWQGbst3IZRWt190UXg2V5VGlappbSBe861TLllY6e8eW5bC9io7XJ17jRINyQj5VdhF48iple
lnq9jXl2hJuOSMMcc6s4VaviZBzyB9abZeL8/Rk7harJcJOOjIqHYSdln7HaZZjXWg/oqAjJCxu1
5Jk1Q/ZRI6KUA93nwG8xIIvO3RDQsdUYNDUlxOhS0nDO85F2ac1l82npTn6W+grImlnTdjq54707
wUTgeWrl/wBFMnbnac5VpSwanGd7/J9lDJcjnapXteKSi2kY3nqipWmUS7tAxvI2cMyQfaIKELUQ
noXXs2mma1b1bM2Oy4LhfF6tJubXB2KPtaWX4CGFY+KoulsUZmMsLh+jIdshd3N2golZKx9oRUxI
gDEcNag9dMjhqUuldkMoDixvjmarqj804wPLDhpN+/jrFH14j6TNkVLESr8si3sEW1bGqshEyE8p
GtuxSciUdUtVWoyPZrVVLI82SmqUqRoB8cIpoDjVWnu41w7VaOcfEaDSSvCqqzDk08eCCyhNNYmZ
GyhCnROJ467kISIca6xQRhdezdRYAHQByynmKjDmAhZifyohNJFh8DUylY17LAaW6lpqXnMxYDjM
KWTIOEXMLphja3arnLZ9umRYxBRw2z5dyTT6Cq8Tp1sduWcQappAZWfsiaky1r9fXPJxZDQc+9Gd
qbg9M07qtnoSu16kVZhSbW/rlglbFEZBZxFxEArE43rchWW7Z42ecwAo3LKmSW68nNsOym+6ydUW
ZazcLRfcd4pyIRnjFhiCx5WkdO9Wk7NQqG+EtcgWMdktywfnoU0d4cjprORrsLKtOnKikyO6MBBc
N19JNrHumIb1RskQ0NZ6JlLFkFjC0WSUx+8ZL2dKnLdjR7ytdW6RI81rg3H0TRzEAMFKrD2aMEof
pwteIlwvKIyjd4kOJAKJBJUFAKQ4L4WdJWAXLKYkGYtYIjydWn/bv3B+Bs7NRfo/CoYLxHnzTm2F
SAdaSqfnXNWOXtzkp7I1abSFwyFETuR4eEetiEWxnFpQbUJKTCVGUZc6fea6lzlDinxddZMezAUh
D5GD/Aev9fPe0JD0neRo7CKuI4nFWPkZx5pPkdFy2Te3s688tg6ZnpKXs3LWwkRhDSkueecgzflU
EzESKchy8ptqu3pDnMUHApJKmNylTIYoKGNukHKUnQxjAK6IbAAjuskG26hQHF6Uu0JcUqukElOJ
RBSpQ6pW6AWAmEsDJ3BecyXZqlJOT8eq+u/wEqWTeJKnEOY4F+ZhAP5j/wBfj7uEoPBEqqhVCiJv
IAMAiPX7R3/jx4OVYxjEKmUTlKicxADc5SuTcjcxi+YA4OPIgYwACph5UxMYeMfYLKJGBNICiXqY
NupQHsx3EPMA2VSHcf8AeJ+XMXfMTBWusIxW+NagxGHQnSXmLUdOo5b8eG6XpSQUPscxzLEEW6Kh
lnKh1FCCQCiZodZ40cFKgn+iXxpNmYJKL6HE6XkoJYZFJy3dovnqTll3fuL9JQnfGXcTCaM5BBzz
q92U/S2znvXJKddgV41Kjdwb6pCm9sqXQNw7U5BVIn/fOmAnKT6wkATlASgI8eVUjFARTAxg5hKI
lATABgE4cu4bhzB2am4D13IfcPYMAXiJjImhMRNGZSmEw1dHn+9hOjf4jdz3jUM8o3KF+gmibSCt
tohmZrA6tZE4admYcEbYpsJZgwNpxflsaY/7Vax/SUptsMkp13j1w8XVUBXtOqqpVzbDuIGdfrgM
G+wCT9sB2Eu25tvLhOVQT7pkUIYoLlETFMBgADk5yCIgYfrk9ovX2i9Q3DhKZQS/W2L/AHtw/mPF
FKjRNhtoyouwpibraPyX8LUQnBQvN5+NlKwuEFO3Olzk/cANx9/u69ev8Oo8a8igrj2Ye0Xr1DqA
ff7/AIfAfw4XlmXApbKjzD8OwHf3bdNh6fd9vXhMvKCP0JW6BDe5RHlEof8AuL08/nv9ocA2w0+u
7881jZjU88nkTSgcgqdqHUd9ugb/AMg3/j8t+MyQgA9RAPaEOogHXby+35efCMVFTr9mQpSB8R6e
f4bbcLg7USgYAIJTL8xTByiUQ+Q77D9odPnxFhrOOspv5g/a3jlN9MHMG/27/wA9vx+fThIqIbAX
mDnMPsn8gN9g+Q7fIff168LBEN1eodfZDqHU2/kHxH5efCRUT9ehA7Lbl6l9oPdsO/XyDy/D4WiR
SigBqfIG0Wwb7GSSEQAA89xDp5iO+/lv8+ny4WG9pJFIv0aoeYm9kQ+3fbbbfhCiqkRb6PlHp/bb
B09/1vl8uPKqojsQFCic31TgYBKb+6O/Xf5b7D58B2h0HPJ5E+t7EFgDcTJAHxEwAH4jxgFRPdX2
ydQ6e0Xr193Xrx0CoKJbGEAH4CIAP2be7fjz7XX9V0LzD7afQv7w/Avz8vnwNZwb5geTm1lhux1q
cWLaca0+/YnNsYeyPsj9UeUwf4e747/L37cZEVQ2KPKkIG+qO5djfDYffsPvAfkA+7hMiYxBVTUM
Bij5CAgICHwAd/u48idYgiQpCiVL6ggACBvmAh0Hf4e77uIxJ1HP7/XQ2tsxrzL8+Wk1iRAAUSD0
Jv5+77fl/Xy4dkQiZJt2ogmC3x3Df8Pf8x+73caCLSVdvktuzMiXzABAQD7dt9hH37/Pp58PchTp
DzbJgTr9HuAD0/4en+PT378cjr1lP6B7Ds05IBK7E5wSUMkG5SgJREQ6biAb7iHn1DoO/nwhKcVQ
VOIpcwh0DmDcfPqHXf7w+Pv343c0UyinbJgmX6Hl33AA5vh1+z5/5NgRAxeYggQvxEdi/bzD0+7f
7eJt1lqZ0yF3Au6g/tB16e/r1H3/AA/6c4TpLmANx7Lb48xflt79tv4fLfrxziSGJGnpaAGAGli5
aLdoAAYQA3uUEQAu/wDeHp/Xw49Kql+i9kenn0Hp7+oeYfj7uvGsaOVBSKAAmInDmIACG5g+JfiH
kG5d+nTjMCgqG5TeyPwHz+3Yeu/u/wC/Hp/6G2z+HLSvP3sPaHQc8nkTxGEN1wWECCkOxAIPURHf
oAdNx8unX5eYbYuYu+3MXf4bhv8Ahvx05XKZVUQDmAV9wEOoCHxAdthD5huHl18t+ioLnKCpCkOJ
vq8vtb/YIb7/AHBv79uF4nUbOn3f6WnZjXnl+ROcsAY/jspX1Snzk1NwrRCgZAsyzyvxsfMTqilF
q9qufhEVHy1jrkUKL5auonRSkJs/bBschTAO/EZOEwaSJOxUKZiqrzJnVMBVFC/Em4hzF925dw+A
79OJO053m8Y9zFT7Jjestb3cCt7lAwdQexkrYGliDIOPX9GkI1KEipJeTfOxhbGqvFtUUVVnEsIp
oEMsPLwz7/F2aDuE8zsdTNQpttKD36kjGzMW9hCFSFczNy0npJ86ZKlQ+mMisimcEvpBLye1xoRk
wY11gKMEJTA7KsajidhObA5+srZkS7RUXlwXp5hPqfDV7LCGKAnATBuXbmDcNw8/MPMPv4KXStR8
v5Zy5C4rwfdUqJebnF2wPHxttmpDFxERtVk7DMQs/MVpeTkJFzLNmr6NSatkZlRw4mWqBCGUdpFO
GfiDvlKrsXdP9bt/a/3R/a+XL9vl14JfSjmaKwxnzF2VrESccxFEtRZOxI1pCNGyvIqIZC4Vatzy
6zdJTvTP9FyZSgPZuPzdYCqexwK4QEe03ciIYQjgksBJmZnrLh3WPYkaThjUzfcblfx93esq68st
xolBq09dpxJ/kWyxR5a1ZKjsY18Y+RO8ctyMpFeySLhSFhrC8lUK9HgZZwmiYda0bI8/eMcY6rjl
0a3xNnYsMewqrtrDDDWVW1+LNwKFklmMazdMbB+YLJSzoFUWPQ5SkHiwGka78UVd+Ee6g8gx1HpW
oxTPGPpCDrlMfWlBrZ5erWm0Y4scfM2RKLi4qRdIu4UbfWpxeZUYTjNPuwleIgpV5l+9UnJNtyxk
sgztdu1myFKWas1CAh49SsBC2WQCQdLTM+7sTaVM4i3ggg1FrCywkWEEw2UEA41r2bmP4fHxRYqg
WwrJADG6zcTB/UvB4wQKFVlIG2L9RM95zb82PB9Ea3KZkEtlkIEchW3UrMzDYzaNfUu91vLUtjiW
lJ6RdvYxm9UrjwKdO1NR4oeUZt/VcWy54bvHZKCXb1HVVr2tsxb5ivUOfyjM022XNq+nmNCRtwYr
vGS6zLUqzQ1Vd1mUbw8W5XTdNko5j4ZYXLgzhAiSRzKpgaDMS6r6nUrng2MeykslhXHmD8l095F2
CvMJpgyy/l7FFvSvlplYPvkuS0x0hkewOTkevmcgjF4wKduZRMANXeNjStRVCoOoPHNtjJ9tC1ir
URa4WKtVEtmrWIrHqJoePbGhSn8TWoVOtuHEBMTsdSE5RyvVIxA505WFOca+is+K9jhGIwvsfBUH
AnUZmVCHPEzc2Lsl/wBiH/1H5ef26rBq+XMm40xlkuk1jGr+sqyc7XY7LmVGMHdmNtYP6jZlrdBV
B3OvnxKjjaSgrUeqqJFbRybqScFRKUh1FnBbPJ8rrelLbi/AWPst44sN9isITuRn61smL/c/EbgW
5Sk1Pv4taUbKh4dJVOcm4B42cRytiWeg1IcNw5R4MPTVrE092qlUGRz3NV41jqr7PEvmeAn5B3DQ
NtmMlWqxWFK2Q2O2raVr2XnstCty4+as7C1RPWna9ZclBFZ+xBVv3/NWG1cB3HJOKnbqnxX5JqO0
oFeNdaywjKBlKpyuLYSLZ4ywkWXXcUq3ltVcv1qnJyDUKm/rdombcvOmlbc5btW4N021226ukBEi
ghkRMIYym4Lg11qakse2Sv7EPxPy8+jdUNorV3VEc0YFvzmBvMbUcJmqZUSoT8bPZHsTGqyE1dU1
pewOTQ0WZ4RzO1+CEFovnLjZumwEO+co8D/qNztXsz5iyflOuwTyvQl4t07Y4mKfOG8k8hUHMmqK
yYSbPdk67IEFxU2MblBFUTbAkfabtUuV5+RpunjDZnUddMk0eqI3yTyfFu3dms19nc5zCOWKlV13
r9w7lpFzRoSwVyoxMeo6nHMhcEUTRyVfYGTSFm+kTYRsPqatq0VW4yltJWlYHsZa/HRMdApQTucw
XjmakIxSLjVDnaPXNhdWJxKtVUSLpKPDC4TKYw74l9h3pUG8xFX+GswJBKggBVJEzavJoaBCDf8A
DoeU9orUP9O+ekxOTtiJHHOVIRIP7AB1D7v+nv6e/g3s96n8XZOhtL72pw9pPacN4Dw3iC8QV3gm
CtVtEvjavFigXZ+B3acCcqj1A5DIsJKMRklSHKJdwMAjW8iqArdDAP2Dv+G3z3H49A4tQypUKEl6
NbSbkCqY/pcLaZzJWYa1kq7xNeikch2iZrknPycGjOWZy8764apxD2RaJhHvgDZODKXft23Ojc1X
uJcrwragLgEMkJDKpMmrTqKBrOxVbOgBl6eUzYiNOeuPANT1JyeYbLYbVG06+4CvWOrRS7BVZOxx
tFk5JlCs0sfUeKYIS8CXFcNIpKw9ViIxlDwETT01IZdjW3RDVgB/07al4KpRWrROXyDGVyyW7HMQ
tjmxyrWZLYn95hciVuVQGpzUQitY61LyVNGwqu5KYew0UZ/J1oB3PIsu1xYw0r4dNd9F2OL6renK
uou0Uq1XXJpHjeGx08x1YIbvMRQMYrNgmZmWkW7r9H5As78sJY45T9A1Zo7r/wCe8TpjjSlpqy3r
s1A4XbQc1Wcd4Ux9m+fRpyt1lWLGfvuI52Kg1KzA3NshN3KMpC8krMWoJB6y9bvzSJjAZjzolH0O
y6TQBtVXVMknqmgYHPvk9TOotmg3YEdU5e8fl/PIszYPU/Cs/R73nHzfI0JBZQmdVKl4sFabyMq1
yReMc2qjTURYpa2DGvnEdMRklNTcAu/I7mWjQTNi+EmA3JxIWq/OFJsGgvRDXKrbqQd/XKc8hMiU
Kn3wsnOxcmiSTVg7BP1GMl14BKakWDV/ZF+/tE11JmYbQftLukkjibhrCWnu/H1S5Gn5i7QWJsOJ
sn2P6nDzFfb5DWa2q6rQLGfUj3lhBvIpVgzldGeQJMKLTyk4sSLnTGhDgl7ZaU6ajo1sWrWxXuYS
eTObJjD2OadFRcC7KZ5HwB36i97eo2M8tD+tTBnbXpPAGqwtmbiEdOPWJFy3OemG9+zu0NyasCXk
7eTjvrOza48NbTKaU/2/nwNix1RZKgnGQtElXFk1tGNXGNtJU6fGsZaoe9NWknH0ajRlhp4tXxXz
KrHZnAa7M1o7NavuzgMm5ieYBOBAU1/RLt6XdljO7UWDtdEZ5MytXqhWGdXpk3BsoaQirENWfyRE
2CaC7Cog6lBqzo+7enghDCxUedshzVhZ30ex2BtO2n/MEvdJSVseoKpM8hQ9VhopsSlMoB+CwkZK
TDixmnrHZ0PBmHjqIQyFOfi4QCMe7qk5u79pLuGJ77hnHDDIqqmYsryOM2CNXfQ1srK8A+yNGVyd
YP42ZTLLP3lOSSmX0RKOmUbF2NF23cNVquVZJRMttlEIcQYRZ54iZhgaZgiYyJbIWLjhbPZlRaU2
nMJy7z4WPrS1C1PJWr7WlV7RSqxPyOPtOWfj1Jg7xtUp9zG2DFt4x1HwlvLXjs064ld1Y9uaMe2v
w0HxF7RamyjQqk2gW0tnTVJYiuFDnL3dcZY9B7K6+cTws4oxx7Xbi99S8gR1mTSxazq88g1QqmNW
x1Jkh5+ImFZ4pmkSUa0BjJFEa61o5z0y1Qu9NWKM91tXLUo1vzC9WCAuWS69CwrijvZA91r12cMo
5ezuxfzkS7coNImDsKs6dKDFNNYV2/NF9NxTmCo2TLvqPqBiKCwxhHVGQv8AkaAvWR67EvVbc57l
VmyCFShpi4SM2m9kZZoq0l4trEwzlg9bmepLNVyEi6xsBViuq4ruCFAgZOQ2tNJOAHLxd4iZkxVn
RwJF0Gs9T4WOE9XwypbfSgYub4qrqF7xqbItnpVjI/RXQoNJpmdKrUWtSpjAsYbuzwWliWMS3Oy+
P9mBhBsIcQvN6KJGH09ts4yF8g2Vhc4whM5NcXPo1A0mti20TkdVYCfhZOKnpxI7k0jLxTt83nwr
xChJx5jj+etu0Z2OtOesaYypqcoVBybJxNmxzj625Hz/AGBlkK6NIS6Vxq9in80hMTbHuknd5i6t
nsdYY+DWh0nNrdxS7iXRQ7uoYqDGmLtcuYcVP7XB322uMcuIiVocDFW6+uU3mRICAcsLLI1ejV6y
vXMpN0+vSTKAbDHwiLuqM3LEUVX6aifKAUQbtEJxdHKVhMxiWcksC1JF6UeWpNnGyjQmk3Wy6npy
4s48laXYPCUBE2y1ZWxda5Rkhjufm8ZR8i+i5x9Xbkza25xGVVWJUcWRy0iop6ybvZSbYQCLQrtt
26iYOEuYictejys1vzKpFYDXpvqdcMuExnXW89NWVqXH0xJVl1eIuBtEy7byck4QTgGL3kdwiFhE
zZo5VKIpIKmTAXKtX1OxmK67c8tomZVW+rRNMr76xxtNjso2KLp5HkfDN3LqPZGya8gGkfDLxbKc
npF8ymV2tfbIOFlGNYJIEfdMiekmxqNBf29hM1CSZ5Eq8pVUoSBpMPPz2RiVGXiK6ha4esvHz25S
3q2wkkXzNdBJ2RGURFRPkcEEzKEdHrB/0MQMGDFRZsOQme5qmxIWJbOoiYyGoH28zZv0vRFkLJuR
D4sxzk7Bl0sbSr3m1TzmGtdxUa0qJx88LBzrW4M5KhJzzSSf85SRCEZXZxZ0YwFQKcR409x06RuA
73E0jUgS8S0veKhXbBiZhgJnXrnM3KRtM0o3hXcmS0uq7NR7lRZJVFtF+rgKrKpqJpJmOQxSpYjV
DqoomeHngOHKbXcwO4/ImOsiUKhYhbVy230bUurO5AgskDW1ZC82VZXkXUO4JMNTwhCODq9gBXw2
XJX9RWfsXakMeagDaaYSPs1CgVq1VaIbHVnio14LSGkIZKeL2baQtUrP1wZONk05qUcNodrKyLEp
zkWdoc64HR8Eqa7XhBIHWGLE+czkzNnXKlokKMmSY0FRk/Wn7umfqTZ03fSjW3eobJOAsTZqo9sf
0EiBKm+tEwZgGR1UDdnOQlVPCRjiteMQJ/YfKHdrubGf2Ycpx6DHmlbTzMakMr2DDDC9hQrW3qdq
sCjWRiJaTZTTallMecr827SnWspHvikMY7Ji2a2FwJDKmKlyi9GywTiDLpcAy9mtz/EkDccku4lG
OxtP5Ci13bDHkyrI9o4vZqrNxrplN3SKJ7dVcAwUj6sX2mAPS9eJL0P6talpkzzIZ4yfCXHItlLW
bRGwUbF2KKatJZzdItTvKlsmLEd5JSH6pXcWSA79kffoQ2y8L+GxV3GIq7R0KDhmJBMpkODXJ56h
7VGOFDENMQxHaZFOy0hvzNR5jm6kW6bgElFEjAb6uyhOvzDr1+wPl5cHplPEWpSjYhw/aXmT57J2
Os44wlcgwMLVbXk62QsHQak5RZCFuhZiGhYuuEiHjlu0asO5zdcSdLood/KqoQhqs3T9cioqHETm
REwF8xERL9YADzEQ67gHl16cXTO/SIYGsOhjGGkGYg87x7mn4gmYKctFejKnBIWi/wDrC5laTES7
hrlFZWaxEzXPNEmXT2OfTT87OKBWrmMZPdbo8BQv6ELMNOIYiACWLzY78Mx5TY8XsB6t5umwR2bJ
WeJ6LhJLJNkyvbaid+xscKjkWeyDN1OTWjioHaP4xlYJQ0Uug1Iwkzxa7R7JJnJKoHRMYHCYm3Mh
qLsbRONfQmPccYmtMRIspaPyRjaKsVAuMVJpKooMDspWNlnUiU6y7hujIcjbcqq6SagAdUoCTOtX
0itT1IM8mRtIkrnVKna0Mdp1LGchiPHKUfBS9IjuSRlJTIpLzJT0SyBT2G7SsQCxJk3spgqPThn6
7db9FzZl0XmBmqTHD55yi3CIj5Wgx1JnKla4BJZpbPBWrSTBeEjra/cSsjb49EjktuSbw602SWIq
gYzUZVzN4BTe4zMA+FMicJPgRLUb2frqiIpGBUBA0U5Jym1N8/2gBpqZzYjKY8m22Q7InKYum5Gf
xuZmvEs4+ozL3wjxKYr1eIBYJs7mvBmPfVHzDmP3hvziPap8z8p2tbVNClplVrOTrC+ZVeFsuNaz
WpJBrYoR5Wciu4Za0VR9AHKm1sB7bMxMa8KvPrSBmve2py7dukJzdZaudBEhnykWK2U+Bn8OxOqr
LNgQrkhjKMWjEcLWusw0RTlJCCcLNY5zTYqaSVcFhHjKYOQyZwCCAxDbBZrMyTRblB4Gg6HD6aI+
chyXo85M4Jm5OddTgy0lRVKw7yJOvqjT49B7WiNp89YBZWSPDlmZg0lyhNNRtN9iYRf28KBCVdYo
k4owNUyJ4gPIsYpIdoCJbz8vPdwbUXWbjksmTsJqrx1M1CxVaPYQ3qHiKm0DGilZVZEIoRB7DtSM
mZVuRVI/ZLqEPyKENycpyiPWLM/ULAGcMX5owNU7bdJuiOHLhjWsvnj1EHlpdG7OFK1Uqs6t27wV
PYQRS5llDhyplEenDp9K7KwOStduYrZi6yQ2UK3cH0fZ4OZoT17bm7hmDCFQkOUY8q6KqbNZJVF0
dMxiN1UlE1RIYhihCOg1hJp61NMUc/rSzwXOV4Jio2cqTdcctowX4r2C1xcum9jn1ePFo/TpoJPH
JUEtlDcpOvC11Wu9RTCWcCymd6b9SgdJSeq2WjedEFCkYsCQse6C4lh4nLvfwlTH+sW1YwpmqGiQ
1Nr6bPUspU0p1c53ZRoiuPZqTtTZKpNBlw7soD6fdJAR8UDAuRQmwHIYAIfC3pH4eh6w806v7ziJ
aemcrRlwikanB28ImIqJsiqwsdMppOZCHk0pMyLVFVZiQpjmOimoomAkKcwJdN2n3FNtU9I3LZjr
KVhk9M6UDdqgxfWiQhW7srG2XqOk64rMQ0seTMymmk1CrNXwNxI6SanUSMcnfBss/wCBNImJ6X6Y
S/aTEm87L0+rVG+jVpEWtdm3VVRNVAkRfyJ7HGSTF45jnf0LIy24lW+jIPP7PEQIUM7ELvCxtQoK
6qZDqEt8QbC+TkjcIXHgp7MIGlXr1atLX7UFgw0larsdYcomoPDmXqXa7bi3URE43Z2EtLl4+PtM
c3xrYpm0psIV9KOmyKqLphZ55lIySAmImdpFprKFE6YC66fq3w7J4e064ryF/pBUN5pwu+Xp+Gnd
PL6tRkvYoDLE5U5cYdzOTF5g3lRewnq4lFNnUShJnSiwDYQTARF6ejgomn+96XPSETGYceTV0u1E
oeMJavytbZxEhaYdlIWIUSDjpGajJEre/Slg/Rrx0ZI7RRn9GJBDcOBh0ZaR4PU+GoZxacx1jDSu
DMSz18ZxtnNItU5aSi3HdFSPHCISwQVbRdfmyp4sXFyTcfQHYgp7HFYV4vsIyiA4FBiUprhSl2S9
UrKS/wBGNpWqAsAM0vumRfvluseOl70h2mXBuE6Ziydw/Z27x3inP+MMuS9Rp9BlWuT5zLc3BOqV
eJexztph7LKylQY1ZaLawC8e2h2684ybkeEUdtynD3AGo3F+P9KutrB9weT7a4agIrBzXHQw0AE5
FoOsWT9ymbArYn60xDJVoXh7kwGLFA853jwxfsefsD8pVYDwhhml6YdKGYJouBLnMakrrlBnkeHz
ZJWElqskDTck1TFNfqOBEIWFmDNZltFXWQnZMJlGCdN3Zq+quQgumhlBvjPR12TI0znc+M8tUFtT
tN99tNYzdP5GcvaYOJ4iGPJDWLXPliPGmtsNkKAhphk1QpMW+KM9FSTJtzumLpNJ293a8x4WNEYI
WSzMMJOP5mM1kgMA8kh0swwiAD/KGXvKPwv9PPdZy4q1JYdh/Rx6ltNtgsasVlrIObKbf6fDKw9h
lGUrX6wxiEHfazjNqZgg6XXaOkAAD7mVbLpfXRUArNqurbBUBoXyHpqmdP1Yn85WPIxrBXcuLQ0W
1CJrbmr+GJrHsR7EF2RtFblvzuNiTMS0+TDcyTpTz4mXTjoeqUrpc1MZJzbEild2ujyw6qtOzGOt
U9FWUlQi5my1eBtk/VY1otXSUy+STZd0mq9sMrOEIiuojWjdkcAgR56LzVEyw8GY3L7HcfBH06yO
qFWrL2S2etZMSR7J1JC8OqpWQp5bKWOZPHxok19ByVm0dORT7BuqciBuMdJUAUqIiJBdRH6iUIVh
DGbIAJAeigXYvaIuGhuuqgMxQdV+6flna1Cxa4dOOQq1Qsnxi2KarC420ur4kurK6ybuG1N2R7Xs
W3Olx2FaDj6LUk6ZZMfW2+3JjZIUszZghpEkWu5uDRqRuc5RSiGel8MNyMRa4DTFL6y2emu2zNMb
w7tgywElj1WGn5EJicj4aAcwctrtrCB3kkwi55FpBySTKnTyd3PPsXzPiqjEenTKeZqnlbI9VaR8
PjvD9Ge2u7XCyuwrlTbqM4oj2LpMA4TEUZO2W18om2iKY2cKNba5UIjJmQVMUonXP+i3v1QLD1Kw
Wx+lkax4gk80V2Yq9MmHuCHrVrj2fyu0xtL5LfykLJR2YT40qq1hkllqqnUU3M4xjFrKAPECqaUO
N0guFFTEhQTEuyQUQ3AUtKcAUSCHYYk4sIkVO4LWoUQKojLRMOUgVOHU55fva0Cm5KwHmD0SWtOH
wjiWUxDTanSMVQSVIYzVKdq2a8VYRmbXkVcyrmNsU2k+ZOYQZ+UnRkJqTrsLGR0az8WhZjkHTJ2I
NaGnLTPlzB6tdm9R9luenwt1y7l6etczc8G4T0xsmQnZY8wXFWSUjmbi8xMF+kDTzWkRb2Cfe3AH
eG2HilW0afc/VqxtqbL44tKc3J41PmptCJpmlXC2LTxDmYeX9JWFdS8aSFbQrR23cPpWSGNRI2cC
o4KVFXlnGc0+53rOjqnaqHeU4NfFOUMjq4uZ0iPyBY5K0Iy76DRnzPbRXYVk+rLNt6vOW28a9sSd
gBs5brDFdkuiY6ftKoMSOuMiKgXnC8PZJIBSlAASosTJJ7WIkuSWDWOCVj9KKokDNh8J8PLKWW1l
MP4c0m1WyQmpmryN91KZLxI6fYzxtWJCOXq2EG11b+GRWRsxW5rYDyD3MEOmD6fqtCgUZ2KjI2tw
UhIz3dbA1WXuUzJh3S3GZ/h8bY+q9b/IvLaELtb5yoQOJKM/xE6psBhzJU+Gez5yXkZqwMsrJ5Qi
XUUe2ulpWwFFOCamuILOGxD0p6r9E9700XGUq+YM5YMlclu6hBZFWqjCw5Xn7JbULMxF3Bx7V1L4
miGMjZJxgHhzV9Izrds0U+hSnOf2eJouWjHXdiDFmRaU5y0ZCLx7gBrmDKumaq5xtRJap4PnW8m8
dksGP4p02o7mGbM5507noTt5NszakUcPCJpFMfhhEeAm7pVFuq4RwHCUgkEHZnGx7TMJimKvWsli
iisRUjOQ+s9O+dZ2b5dBVPuGmVHWfTrJkqNwRB1x3DWmrWumFm84y2VG0V31SUptahU4yhv9NMo9
cVhBTM09e0ZKKXYz6SlCSVZuSFfjfH2D3voSbTlKLxdXY/MsDrPgsfTGXpdrGSNslEn9HgbEMPXp
RsxGVplPUSVQcJ0Bu6VbdiYqwOTJqFEK03GpHOLo6oSWYsnvFlqCtiUzl5eba7AMSO/1mLRI9nHg
fk5D30ft/Ag6iIceG+pXL8HiaTwGztxUsQyMivOP6O8qtSl4ZxZHxF4Q9hBSaZPnp5uOr8MwbMrX
4sNsAi6AFlABVPfFjXm53gjYLwMt5ABgSAAQCl2GZeczQMXCfiPlu9OZv9Atx0pacK1Go4qaYhxk
zan9ELZtTb4s20lpPUv+VRKEyRZmV6QvpRlsfmrDSQraZVKuWfFylDF7waABqAn4ZFd9GbhuEo+n
HH1jj8WXCU1LYkxpPSWTbLkqRruXaLkPU05tNUxmTFuI4tQ0bcce4mkqbGOrg1lJbvdl3nTMjj3V
1yU+Br/1Jnr8lXXV9i5Y73DzzARr9Y6ZWJ7K6GElX70z3GiOVpBk/vw1R4jITkYmxLKeJKRUiUxQ
FFUBN1W/SA5wrtYZRL4afeLhVqk+pmMs0ZDgHtvzjiCtnavYyCjsUZRm5xexVRzTiSE7MY4emTcm
x9IyJTV80MdUom0FdI9FqAB2fYZTAklTEEhyWc4S/wArEEK6tNlXrK8pU3bvPi4eXGJVrlina4u6
TdHrM5PQLlRFMCAqeFnfB03G5dtyAn5H+qO4dfgy1FSqjsJR3232ENh/iHu93TjaScgZ++XeLrmX
VcLmcuHCpg7Z28O98WfLLCbqIOlvYKY3RQ3sgIiG3Gi7wn+r6dr+9v8A4/D799uPJmpajlrFt2Y5
CBuY5Sh8TGAA/ERAOMYKGETABUxEv1gAA3L/AHg5dw+/jsphE3MqmQxev0fTmD/2/W8vlx0kcg7G
Aoc5NhVKH1lfPyDzN/Eff5bBxm4E/Grw4c93C3WwlB0YOcopmP57FEBHf7A367fx+fGwMAtEjEE4
KER+qYogYB+wQ3Afl168cTeN0/qpb/d5/b8f634wOXqRhWMBeYg+RA6mHy8gDz9/8PvLtDoOeTyJ
j2Y1PPJ5E/PMfYB2HYy3MUeUdhL+8A7bD93T5cJwU7Tbm6c3lv03HoPs7+YfZwmBcwmXTA4CB/1u
wgIhv/8AT7D7X/s34xd7JsI7BskHMQemwl/eKP7QD8d9g678ctSV1JEmpqAPXlnHbY9O17LlT22/
Xbl5N/Pbn+r/AB4Q9uYAEezJsj9Uemw/4dPcIb/LjD38neOTYOXz5vd8d/6H79+vHkFidkqAAO4+
Qbfy+O3yAfLpwLEnUc/v9dDbrKAIUdthTHm+rsIDv9nTr93GEOva7ddx7ENven+8Ah5l3Hz6h79x
9/XbEJzcgc3ZbcvL13+HLsO4+Xu34wCqCe3KID9g7+8R67D5fdxC1JXUtT6Affu7jYsNARni4/Qb
rZdw35dw5vh7/wAPPhQCxx225B5vq7DvzfZ7XX7uEnaqc3Zcpe18t+m/8/P3cLGCqKS5jql5k0vq
EEPP7A26/Hpv18h8+A7NPxnlvx4bpV2h0HPJ5E3nEtkyFKVRsiU5w2KdJcogby+qIG6/HpuAcbJU
Q2Ee0Jt168xdvf799vu8h+PThAlNN1QTHtl3AI9Sj2LhEPdtsPipd+nlt+PnxhUlmxh7MClEPLco
gIdR+ICPn/nwZCkooQZv4gDnTuNqWRSpxBIFR3ATD7KO3tG+QE+sP2gH8ONCCiQm2Dqn+6Gw9fsD
8PL7uNo8k2S+6LdJTdLqRRUogUfsMbYB+wB6caYFzKh9EmQPs2/n/wB/4htOJOo5/f66G3WUc5gH
k7MnL579Nt/wH/H/AB45x47ZXfb2N/hzBv8Ahxzghwku5nu4fnmpNmNTzyeRMm45TtOz5DAfsUeU
vIIG6+4A28x+QdfL57LAV3DlAwCfffnAQEPh5gPlt7t9+NRGKlFuCiJRAR8tg332H+Pw3DfjZiuK
YAJSEMA+QgIbD8NhDz26dAEfPjc252OxwhtXL1svsxqeeTyJoXaoGW51RAqfT2EhAfPbboAj9b3A
PUduFDeQFITGAwciX1Cbhubf90PMdviG/CRyKhvIqZv9m8hAfL63l19n9ryAPlxi7JX4p/8ANxRc
QrZwA3P3tG0Og55PInNmFMnq4wyri/I6K8mgpR8h0m2qpNxMudeNg7RDSb9sUCyxhHtolJRqIBv+
rUKPUhtpP1hXGnXHUXl20Y4n2Vqo1quElZYGTI2nRN4VLLJumzY0bNoIvjFaMVU41TYogmuomiPK
ocpRFBNBwZHsiGSIqVHZIRMBe0N8CbiAnH7N+v2dSi1BVejREpQlKNXSwcBOYTxRcTHcyE/NOJeV
sFCj5S5zC/jMi/FqdvkCMkWqLE3KJW8e+JygLVwCehCVtOjrzAIA2AcLHaU5TUUFcrZ0Za9oleMz
YNxL17vOw9g55h5yiBif7sOo/gA77+7y+W/DypNo9WLRWJ9GvRNs8Cl4uXjapORLefip52037CPd
11ZRJuu3lP8AzRO2MB9uoDxGj56kzHlTMUxunslMAm6/IB3+35hxqU3Cyi4qlA5eyVRXKqVbsFUj
NPqA36lEd/dybiI+Xv3Thx8MW7rAH6DAJdgvs9pp+GozIIaCAQC9R6fnkTv5yvA4pa6gtWT55jKG
pbqbwpp8y3gCpxmIa1PRLU4tMZ2zNsZRMOuH8NU5B2vGSFoav25X7lWv9wuIPCtu0MFirk1r0KDg
s9XmFoNOfVmCUqOM7s4qLWJRar0l1c8SY2uVsaSMdFmXj6w0ibFZTxf5mucreTMDJTkcmBIVsFp7
vT6w4JGrZbiJJ/lnE1yypW73FDb26FbZ47Z5TkLjWWS78sbPOZmJQolyjWrlmhExcjZCRjcCmqZk
7oMbZix3lLGKVfuNpl7Mq2zRVJiTRkZZzZIiamIc1pj6/PxGRYSafJTySze4RjheQQUkJM8i5LAT
cQTwFy2Mf0/SEdMW7Xcr6PVdzBIKdmFHF/xAYuJAm8Bs/wBNLSkM2CqGmNs1XhQnIsJthPhl6Gdr
EcTUDD2YMT40NmPEmPMUqap8vYpxjp8tWF4rmuEY0x/ba7Xc2SFof2hdGMbO8gSsfKN4+SkPFZlK
0yaT1OqDGrFKaPcx6SPULLkjNRWEoe741yLka54WwxjXGeQbozdFyVTp6v0ZVG4PrKwTt7ybdqRc
vJpoMnXqgo2kE3BXZk1AMYTMeVbJd3qlIja/qAhHPqjWcjZVqeIm16yeNix0enTtjmrqpE1ZKHGl
QNnn5OvzV7i21ftUdK2OJlKzcJqaay0ixQWIxinq5kMlYio7rLMsnlBV0rlyswloyA5aK4+mbBXm
9tbWa0lsMgwgY+cs1UdNbitLzLiQslginKFanmbSXWSKZ2GuEu6gm4qEhMA7tzTI1oC28+zj/wDq
YTf5T93ThzhsQLfQfp/mrjqEmmNnsLfG+IZnGuOCV6r3GvvnVfyDMY7j7dlaQlLTdnDGOsNSgbLC
3mJqteh14uUmZUkcwaEVdmIlxAmV9GGNsbzGaaI/seTnOR8DUt7N5GyChFQJ8QBKT05GkxTANHBX
PrUV1fouwUCLOv3EqwXxy8jW/PUD97HqFqGrasXKtQNbajlKV1KvH1ngalFqVPKFIzOvWJizGl5l
xV130pU5NeJtdbs7+TWkE0gYGO5sLoyNeSVULrnmQtY1+qWoKtv4W45BisgX6Als1WVSEe2aajLf
jCMlvD4ttPJu+5RKcZBN0E3EHFKuFW1QhYmrqoEggRiuKLXc1w3hXOKhSR2ElTOGebZ6DjJrVeJ/
dV5bvTlg0cP9KLBXTtNai6ld7J3Ctz9Yq54W6VGKgVbHK2Z+8RmnlGbQV9n5KVi6zPxq0Y4c2wKs
g7ZBAJxJwBy0BSDssYplqzB46vitneW+JyvRFLjESUkzVjpoGUVOSNPWZP2K87OtiqQ0jWCsm6ak
7zIxqR9wKQhtiaZZdybAae8iY9isMM4mj5LaUSHu+RmVauC0TOtcU3J0WJE67t6ejR08lOMnkTPT
8WmlZnkmzcsHDIXaCqRIyydlxS846wjjxvSkK23wxUJ+tN5fxN/LyVuc2nI8ncpiWO/kkUGRDN5+
edNGTAphMMcRQSF7Mo8Zd9u11ECMyFjb9H+2q6x6qwR1RqmVSMViwFKptVSZpUbCRPunPXuDEjB0
kvsVL3jv7A7j1+z57fz4LOvY9zbP6UrLei5UK2wPQcvQ9KZYtkLpdxZOMq2+Cd2tGcrGOXkVKVBs
ivGsHzSRmZ2Wrk6QWTsirMO7LckDiIAUQEEgMHmqIlAoB59TCO3n7t/4cE5jbK1TicB5Zw/Yk7Aa
QtmSMdX6kvazDw75mxkKDT8nQUpDvEZCwwpYxSTG6xyaTxiFgMqeOVIUTGRMAZVxhqhGMmLGWgxw
CpIAIEkdmpNBXi9tNaUxIW0KmMpDgnmn0Nomq1hzxDVeMna3abw1o2JsgwlggHyLx66rlKynIs3M
jXlK41kWsxCRN4Wj2Tx8zYwCDmacM2jl0jDHQQVUIVSFd144IzVC3Zmynkc66iUbBAtSmiavfZa8
u7/ILyVzgHsQqtLRDGzuXSDpG2RHaBJVpZF0nJtmp05ALI3ZXPkPZtO1cxJKwDiuWbHNvQtVVlqi
wYNKNbWDlB+xGXyZUVZrus7kJB4evos7x3KamZeGkpBadlGLcxzCSkHq/rKGu7Geo884+So8be63
Zp0bBVyvnsaSaikY3IqsJXIw0+qxk52VYSTyPBJAj6w+KIHm5xp3ggm9BDVclghd4jLLAB2DyDAz
cTrpPWyfs6trg2aSmRd5+79xYUKjVtUtHtmX8D1jFp5e85TrhIbItMLSWlnsyFUiZhjbm7qEXie8
12FhDupOOKnY4NdyxMeQZAVyIukO01jK/wCcDYNnNILDHzJ/XK/lF/nGeJHVaVk71XrhFx76jSfi
Ek2lFYuNg47xWKQfOHUSi3ZqyTBJwdJR43KrYVp31RYzgdVWrvIltvrCGp2VcMZ7oeP7BcY2ZXix
Rs15qVmxLXyxMCgs/hQioWuJS9ZbBFpwUeT9FPn3TlCGcGZqGv4g1id4vcXAZRu8pjOywNuf2ucZ
5CuqrWasytqSiVmrlVrOJzMBYJySlIqRJKG77YAUWT3GDEBQwoo2a73GSJELCUmpDAOa5GUwzEuW
vs1D+mjLM/J6fXSw4Zg1IXzOWC8K4YkcdxMVFaca85qMdcYVe0yEzKMXiJ3C7W4uZl+k0SN3dJRe
JSbimK6JDqIFOQpjBnv+plXIuV8KZRRqcrVVsPVnCdJlVoa3uXk1PpYXYwNcCTG2uCqHQnJmMMVR
0m4hpZweYMVESiuIF4NlbJdUa+iwr9UjHlSgb5J6sbAFtim1khZG3W+rylTlp8lse1YgnkIqOZy0
RX28bKq9nKGi2cUqk1FGztDONlrkVrrPSnoNRpbOJioud070uQurWBk6uq6VucIy7SUsnhTQ5yxM
xOwdws0hJRs0uk4mH0iwNZUmBoUopnCCWHtUaZaiJdmZnQzap1A6zM4EMxSKDX5d27nODcSa36/Q
/SFT2tCQr+R4uoT95yLaZCl1qcjpi2iOSkZJoFXPNyEvDxgNWj58wklXgiBUkXrRcxgI5ROeGKTn
+BgLrqcm3Zr9ExmcYyZZ02z1lswd3arvnGR2lranVbNrfWiNTS8c3eNJwIiyuxOM00K1Gw98QBQ9
sutsbNdXumTGMnjWMQw8ax6eLT6sK49ppp6QrWQapRX7uqSUXGM4lpIVTvoC3NUXS03F9uHZDGdo
AlCTY+pY6uOs3WzQQw5hivweH8M6mYmoRRcS1EIdm+o+VIg1av7PHwkCuT2QgrxF0myrttAs1ESO
DJlMQr8bK2IN7gxhDTfYSgQJlKQcIIYFtMRIBNHbWw0qSn+mk0zI5f00mLeHdbmLKVquzjmq3xGR
CUTLOEbnjZaMiIOuy0/Yp+wV+kNXttukSrfIWKZJz9hiJ+yTyELNWAqrt6tENgsMgd7YbK4sK68M
XU2s6TqraGU/GKaYcg26SlZEuP4O0yN0o0/ZTW4sfSDGsSadEvShoCvRMw08TYV1OIkpXxGz2COM
/rVmJ7EGH9PTbXNpJruQMK0m2UrPmljF9hhqqDJhARBcg23G3rSOS7bRY9gpBJqLPUZtFKhwb2ww
ai1xAhFxPFgUorURvgSRYPdNFaxtiWV1VyuquwU5i/ynAXVGmDQXDZ1GVSrQEtRG72NhH7m3sXhV
1XMfCqnjmbo2wkbq8l4f8TVGMODeIERJAOJRTPFQAgs4A4dYMatSH7Kufs8cGVMWqaU0Ld9pH1G6
5NIeoVWZtVhrbVRtH6WmuPqLT31EiiZUp+oGJnICRq0s3tjVkWOUx5FR8XLv3Tct9FSQZSBXQwhk
FSqCJuSc11a84stV9yXasIWvN0lc8UW6rSeH4N7X8m+MNmc05vg5MI8QjGbhWKZqpxahY57KHaOF
E263ZKHKQXlYvRc5arkL68XrLGnnHzaZWy48i4aWvkuwSj3+I7UpCWeIjl38K3A8irMJKxzBlEDZ
nJ2CahSJCUhgBVqM0P1yt6ddPGYMNuRUPPaZ6llLMtefTc7Jzybl5Jx8LYrWwSkWiUN6hJzMtFRD
tgDgARk5SPYKwxHT1sioqbx0tAIARCVMSNMtO7lrNoXCQzKJpUDUH7nwtLmuTNeJn1bVzLg7KVUr
eoe35+ewsRO4Dtjqo2eawnO1+afydjyHLUOVZzLqedWZVKKKtJumJlGqiaQGHnIUY3zPnnLuR81Y
S0j4tzm6psNjhnE6a22e4242du8yKeyTUW+vd9u9kbS7qUdV2evUA1l2lWZyfcWTQ6cSV8XnKmIy
paF8wQuOcTZZfNqwek5rutQxnXpNCQdtnDeyXGretEXEW1KbhIAIpsLT8+Rewvjvasw70QxkA5+J
UybokWh9Qcdpcw06lck5Jjp6eqViSkIuJrkbETVWcBCTNnGVZO5uGa0KVZD4y5Os/I4iKj9Asuk/
DtOGo8e+rYR4UCEfkL/CC2LQkA6UNWNYaboj3ColiXUpvdNOP0O+0lyOdJ3VlrhZyEBh3FlnxxD1
FPGs0llg8KvHw+IKGYCyeULhkg0U4fRk/DNtp9ayQbdWUezv6APWhdfQcRdoKiai99IrjGqUaFcX
/EMxkJ9BO4y10avSa05UXLCZQaPZmBkVLdGQPc11U0VFnKyJE1FCJGMU5ylNvs36FJrCWcKpgRtl
mgqP8jY3gLKxvcgrYaFR7alYYYZEsBHLFGSmBTfOwFGroWWHb92W9g4V82wcDzibH2SYfNNaxlX8
gSWFsg2iwRFQZSqk/cKyVKbnJblrrJd9Q4ySskbHqH9l5JnbppAb2TKb9OEwq8qXAhpKBskgpUEg
FQUAZ6SOldDYsPYu0JSolO0AGpKWVd1MgbBxZmQpSj5BA6JSILu9jAcvLuU3IPtb7dFPYHr0P7I+
0O3FsOnvKGmqS065JlL5psxQUcG4ZrNBbINatHzeYsxZmyjL2AiWWH+SpBolOxkbjs9TcFKxXVlk
VTTLQp9jO0eevq4VItasstDvOycyERKu4VycBKZBdxEy503KoGAdjA8USVInt+sOkchdzEMATCzx
bkaBwRHZChrW2b4rzDc5ilStUrlpfGVkrViyJi7SxRuNKO3PEAnBMrYSQpxAeyhlWbhF09A6KxDm
xbnBvEM9I4EhdJFVWajZ13luNiqGOEFmR0yyz4jwsER0XZ11Dl5DEP8AUIUeYT/3SgIibf37B/nw
cWUNFctjOIqT5HJlJvJbs+pURUHteYTrWv2t9dw+k9WZsyR2Kykf170WXXgTN/7QCcDkNXbmMoCj
XZVscExTSU+kKp/uzEL7RTj7iiAG+AefEz2rUHlqbpx6xI2ZJvAN5mGlVQrkJX6k4lZyGKmeuSD+
XrsYhKuXUURVI7WLet3SsuRRMySagHLuxdtiiHgvd2iw2niSl8xOdZ+eciA3slkBrxCTSispS8j3
zzktnNP1dxRmSNod/wAiU26Gicxt8X5FruOndxg7ImZKY7GblIk9srLfng1Vfoox8mmLRdX6NFQx
+nBKZd9GZlsuoFhirDqdZt0fesz5fxlSOzsS0g9hhxQ1QkptS+yrkE2McDOoWGtGfDFnne6SKSBH
HZqHT5gzveqDIGR7ZDX22VTGAWJpeDZHlpuCobGrSOQbGDsZk0pb5Bu5Un5pqU4CItHbxqUOURHb
YeCDrfpONRtUv1UyW29Wk7PWMy5SzYYSMVGbaYs+aa9U4m6RC540HBWsaCFcTO0KYSkOQOYu5evB
MfR8UBSoJQnV1TkjJqOzgPKlLB2a/wC69NPl9B475at9ol1c4guOIa/Q05Few6ik7AfGj7Edtm2z
W1MqlJNT219KT8c6hpEkBGkfMjy8hMps2UeR41M8WRBykJ5Y1naFdQeOMvXzH0Hf8hah4DT9iuqZ
ast8tcxJvl6bAXKO7NM8cZxZJl4xculNyIDEKOO3MAlSEw+SCpekkuuKL1T50uHyQdeiMZ5OxhP1
ix3bIM7ZbDB5iLGKTdhRtVjWev4J+QkC1PHrRKCIqlOmZIxgOG8kvPSxwt5s+SZG/YretYjNemeC
wHkdvWplF47RJRxIFXm6pGTBkY5oqUVkwfKvXA9kKpAUEOcu5bwm7GMIN3iqhqYTSBimU6uAyXm5
cyIE7LoReERMYhpPyuWy+u+jCuYP0bS7myf1KQmkGzvXGIsm5GtEdQ5uMvz2aGHZSkw38VhUrahT
zTz1NoZf2G4tgclUP7Ke48M+pv8AUo0u1nt2JrDnBxeIlUYuz3TGVhvTG0dzlF1okG0paavNqWJs
Myg3cGYEcyKYvSILGbAoCR+UxrRrhxtd/SSY81tS1OyDCVmDutEyDd6dHlrctZ3k9T47s1WtWbuL
FCRzhB4p7CQWObbdob2Sbm4YWF9ZVbw1SNV1Krj2+U+Wzdk7Gd1pVzg6XUrI+jaxj+SygpLxNshJ
K8REdEGkCZAanKnCuJ0VCIT5uUwSDcbMrChQybjt4y4bUKQmrzUXnKrHTKhMhkQ8Rgw1L+Ek5t3j
8DfYHKzk7KuJ5mSdUa/3zG0y/MlFzMjTLRZaW/fFbuO9JMJVSKsLaReOGEsPf49uq4MqJfpSE5eo
Oyg4jy5k2n5syNWGUnI1XE1fibBlqaXeoCVk0t0kpH11u/7Rw2TkEJuTSVfFi3BvzsqaiiSaoEMI
SbN0Oyas8pZcyPSrNEmCTtR3zlxk2eo2PLhKpT5CKRqzqvVd8auuk001E1CHiTCQSHIYBEpijwYO
kzOELpexNru0nZRyL+TC1ZqqmJ2NEsrPtrDjqt2KtWKdd2RCYe0yQlpdkU9XtCKbcrWHsDqXlYN+
jYJ1iszXKmBN3WXKr2gTAE9SmZrSZ0lMhnA3/wD4yx/tMuz6cyevGhagsz47ZsY2p3h/FMYeR9YK
+zkPDrC3rtgUO/MW11VlaQkfVO0pGNHyzu41gkbJSkpGwQmk1FFG3NMmIc5awI2nWefw/K25HH2J
VW1yy47qkc4a1aX9dpto1bTWoVVo+bt8mElHSEq3h2uVGFyK2Xe2FFuAqN3ZSHD6PO/aAaJWoVPP
zOn2CZu07lau5JbZkgomXi6wznKtEscC2rHMOgxkU5GLbSEfcX1utE7OoSdFKrEKxqKpV0DGjvQl
JUBTR16T2p2qy0GFuNsxRhhnjhnc7DGxc1YLNAz10mX7KoAu9bEcEYKOmvfERI4Uai5QFcqYLE3Z
2N5u8S7LVfn2zOFMEviKWSxcgMFE0wEEPQDiK2cwAZ0J4Vbi0swbRFUdZmsMuG7WyjoQtnxOyxhb
tNVst77H7mQRa44uJ3MhH4tf2+PRUg4YtQf2wkpTE3TxBSIbuEXEgmVNVM5kEz6QbI9vxg0x5eKB
TbpNV7Aaum6uZEnHllI9rtBK0k0YVCNqMRNkrStzrkLPOmcJcpKNM9JyKFlGg8pgAutIzlR/6Iz0
isEtNxaSauQ8Pv4KvyU7DIOpV/VSwMvZFIqCXnSGAWcNLQaBxaqmGSKx9rmAnQPceG0On0HZsNep
OYHWYpkiCSxcxYQoyxvUvw7s1GtfZPp1GFb1ZI4iS5zLpQ9saH9mut7cboPRY0YRtn7VD7SQ4U5L
lDkyGpBrIO5JIsRZQtnhpFO9m9PO0D5W1A2vJdeqmP20TEY1xbBQkISOxTj98rEUa12hlGKtZrLt
vhjKEa27MVhEZRlO5HszOTsQjGw0JGKFrsbWnz49E/SlWGbo6cvkGMvNnzlV8EWbB9HRZXySg8GM
1ZmpStIhcz3HGMW9Wg5TJVVoFtmYs6DNHujxJGGKJBKshzWAL1zTTIl03ssSsZdxiSwaHk7FmuKp
eNaa605vE4LH+WpjMWS8v3lzPuJKOzTB3ttUESSicE8tzNq0gBVtKRY+R2rhS0I4+vWnNPVvWXWR
65QoPF1kXmsazkawn852a8QUe+LH5Xp7F2ZCFa6T1VgjAsuQViqW5FaKyEFNrr1+CFkT01Xe9QFx
YqIyle0AJwKDFL4WbC7khiS7AibMWW2kIe5pwlh9Dlbcp6/sWQmnKd0rQdJy0ljWWwtLwieUJG6u
iZueZnkm8q4GIln8VaGbM+l1WbCHTHD0c8CNUj30zNOomyT4SLCywh/pDYbL6PpppXBbK5cphqal
NRKk0fHlMWpCzt1jGm44ZUxhPjlsbI2jkJGoPFjzydd8RIMm2D1WAXBOcl75MVLAeGrPR9U2mTEJ
c3Zk0zQT3BmOMQ4VpUJPYfiXYeAxWd88Zbb94yES0y636Vd1uHLNOJtr+dWFJkj9JxujZk0+z2ln
NGZM46V9L+JYzMGKbthPR/V8Q0co5Of5jptfPHP80SsqohFd0xdWJM/hdlmfEVJRa29tC1qt3CVO
7SsfXnbLYqWlWFQUGSkTIAJl2gyy78QHCTaCYnuDA4ALEmmHdImUxrvnHNJ1jYCbV7UaXNd4ztqp
k8p6bwx1iFDO9GhLjaMW5jkI5RA9hY3Cets4jHw1eXTOlCWCFXczBFUzppNeYolArs3+ko0vX2T1
lXuDsFpThs96FIrTbjXHx6hJxmYGmSjwIw3LkO3xyCzGTxSxIIBb0F8u28th32ShLJuHFO1W03Ku
sMjnq9Xqn49rExNzVVxdX5VnPSGRcw2NkwryoK0qsESKi/xvDy8tJR98ylKSgIxL5q6aQMLbHCCq
ZLjcveihxBjau5BxQ+d2aYylTcQXi4/lv9e2bWImsrY5w401H3CmOcSeys1xGbH0vSIVrbHQS1i8
ZNJNOy7cqiYBMS+RYezimEXSVBy0kiHiMywSkJQVMwm5zNunzrlb5snRg9nZUntm5CbGKPMbmITk
L12MbnUTJyhuPMcgbcxygPhdIXLcVDHDdqG6m4huqHsdS/vb86fl++QP2i72FzPo7s/oQ7+5RRKZ
bcXxeEC55fZfrlmOvi8tcMznxLWkbc78Gajk401FxkYWkgy8eGReNGQMO8uEkzzBqm9GlP4Xxzh7
NuJhtF/w1kvB2N8l2ybn42EbT9EseRVrU2awjuMgZ9yqhBpOK4k28WckTbd5KZuC3bEEgeZX0Dfo
aApaEwSpTAIL4jI4Q5zAJbQHQ2JDjQ1vMhuGbN9S53C1Oqhi8xUUjAoKiwNyATY/O4MRFQqBOXfd
YyTlucqQbnEjhA4FEFUxFGsusA8okLv8P2uvQPvD4/dxcXefRQZSo1olsWWq8wQZhaYZm8tMomPq
9zlMTSkRBUhXKDzGqmZnzlEG2UGePoiPurqt+qwUtv3pq1VuBEF0jHqZcwj8QKqUqQicvMTYAHmJ
+8UQ6mD/AIg6cKx+jl3YAxYYYgKBSpwUnCQQcwQZEODXMuSGUrqW3SfLXjoO6zNUXOI7B2Qj57AY
oj+G+47fy9/XhJ2iXd99w7Tf63T7f6Hy/nw5hh5AA5xRIB/gJRAfs223+W3x/HhCrEPi7KEImZMQ
6FKADv57gABvv1+H2cJRFrRRIMxUtVvW3W0+w/W5y8+/1eYOf8N99/l57cJxWKmoJgMHLtvzcwCX
lEOg777CHzEdvj79twEW9FTnBPcv7wFEQ22+IB5/Ly4RrtF0w2OjyJ9htzmKYpBHfy5jAAb/ABD5
+XCmxVqfH/Hnw3Pdk/F5cOf2Ntd2o9iBtx5x8i/tD8gDz33+X8OMfXYR5y7B5jzdA+0fdx5EoAgs
YVCgcn6sBOHMf+6G+5vuD+HHoSFBJYBENx8tx2EfsD3+Q7dB6+/jogUjJ+MtMq52BtDpzy/ImnEx
T+0mYpD+fKIgBt/PyHr5/L38ePY7LblHfm7HbYd+T97b93/i8v58cETl9pwBBP19lIQMb3+4vX+X
z+ePtQ326b/Dm6/htwuslPYdVK92mQ8ZCUrTgR8R8t3r9NZe+1Dtd9ktvPfcu3n8d/P5/D5deOlT
AQNyCBg233AQENvLfcNw29+/GLmNvtsjv8Nw3/Dffjr39nt7PY8u+3Tm+H27fPff8eKYPmPLen00
nGzGp55PInmE5CfVMUev7Jvl8f4cd8w7b8yO3x3Jt+O+3GLc+xh2S2L9YfcX+8O/T7+MyYDuB1RS
TTHcQIcxSb/YBhAdt/kPnx2D5jy3p9NJkt551dg6pdsbqU25dx+zr1D7Ovy9/HSagl+t7PTyN0+7
rt933/Zx6KY5lBOXsjkS+oYpgMUfLyEBEB9/9bccAxy7gcE1NvaEAEDbF+I7b7APx226b/HijK0P
Lfjw3SpgR8R8t3r9NZKTKqgIikYSl32FPfYwG89hL5gPy236/PfjtJcw79B6efTy2+Pnt9o7/Dpw
k2HdU3aBzmX9koCHMb7C77iPv6AIdR+9WYU0xVADkER8g5yiPl7g33/w6eXEYkZLL/fq7/vlun2B
HxHy3ev01ljEpg8zbfaIh/PjKYQDbsh5eby6+f2D03H7AHpxwgEWH65TfYYP8Pd9n+HHfOQQ5gDo
UdiCHkYfgQf2h6e7f7+O6wrLSZowO7d5aW7Aj4j5bvX6ayylJzk7UqhTdduYpimDfy8w6b/Lff38
c46OqmCIp7AP0oiHYCBugAIAPsCPT3B/045ww51PP7DwsfZjU88nkTnyBdmBokHvAvN8wL5cwhv0
APiPTbpv7uHSBlhSSACFES9RAA3EPtD7vl93TaP4JYoD2YmKBefsNxMG3IIee+/l8fd93DvScJ7b
ic4B8Q32AQ94f4/Pj0Dp1OWm71LcRZO267UP90Xy38i+Xx8/L5+XGHkN8E/xD/PhCi95XHZnKKgd
h7g36fHp/Hy8tvfx5F43bgAnOY4fvAO4fPr5fL5e/fiHS1fMNl6nxFlYhwUnLPcAfW25SMftUh2T
2THlTHcPaH4FHyEfkHUB4IW/4+yNG6e8K5ZsVurb6kXwLjD47rqUtLKWmJi8eXGWgptk6jC1/wBW
IqOTn2Uk5ZHirK5S8ElkHRR7u5Ic4mqySjoR3P2fZLbk7Iehg94ht577eYdODCkc/wBLsmjWh4Dn
GVnbZKxtla53ChziARi9Xe1C8soJ5JwB5AJwZmFVRlIibkF28Oi5MkR72xylKfmHRuS4MS79IISp
RUOjvbSGHaGHqf46GpbfJWKj9JMV5uJZVHfnYOVDm7bnWATGHyAd9+vlsG249flxkRV3HYBDf4AI
D9vTz2H+A/jxrXZjgqukJgDk+oqJgAhg6fVP5D9wj9/XjO1VAVeyAg//AJgD2Pj9fbb5ef3+7jDU
VJKShRJcHzTw/PfNtNBwH0tYdSNWOQqVSNPEjEYeryJNP5r9T6lk9wjalELVH3+SsErk2tWmRM88
GlZGThrdZm3h0esdzFFfmBRFMD9cWStUTLMF2xC4zdj61T2L8ZNbokyqnrhOP73LR93mJ23OCL5N
tjtSeUIwlJeEYMhBwJRpzLwsn6UJuEv4YzvjaO0QR+NsmXqs2iYxPqhoWaaVhuWbS9oWc40EwMb3
V4+DsDJelGSnGQg4VhX8yeAmkDAtYnjFMeYZr1m5o015IwRkKXhJuEsdqtGaYq14mcPZg1mvFWxx
Msp6SmISRYqN2TvD1OaLy0LTWdFZPl4n1qYmsBYvw0m4fR2ixbgIir/DWQAMJCGAkBPw0bJ88KOE
G9MEAcCfl55a1c+Os20SlYW1G0V1UlzZJyc5obHF+Q2CkOR/jmCaz808usAhNpr+OsK1cakckPIQ
8NIOZWdE5UrIVnzAHBVZB1T4xypinMRJ+sT0xlq+4905QFUl5uvViSjKPasUxNNq2QJ9peRs7u1n
ZZFqNMf9g2CB5E2kmkqmAorEMaNMEN08Mak2mOsnP6Bc6FQCzOYshRkXH47v8Rf4jHuOS3JvTYa0
zKSKMw2kSFCsSMA+nkawLlI1ofRljs0XGsbkTVvxvSMuadsCZDoNZq9HnbTB6m8ozEfFY5gJCuEd
Y1yjkG8Kwtyy+g+Pb4A77H8IyrtIp02wfQ0mZZFCBWgxUTKakOLfE3VkX2CpgB7smAo3IE5ZObKB
/a/+at3p9NJxpCapq9UdSeArxiySuNLxDhR3jdSsQipXDGdgIU0TEuc3NmowcrZXrkuQLeFwGaAk
oIXiMsrdV13VJ4mKksY01G0SB1pz+XI7JMZA4ZDKshfWLK6xNzXbIRVudTSM1YKtX4ZjNkjrtAwq
hGjU1iSGPlO0IRyWzCYoCqhrRT7vizDS7rS3h25Z11E5SlLrhWn41o8VR6ejjysFuOIrFW7ytFSF
cepb5EqZ51/CwktYYp/X26z20WmOiUVK6VpQmIcRXLKVtgZMceJT2JcbEd5BkIudslT053TKQ5lq
+NbG4jLYmkfJsJVsYQVpjnE68g2DlnZ7XT102Cg0eVev7QS6pvqohXCj3eI4bCohjQZd87G2YyPD
nx5E5Xs2bsKTeDHVUr9zhhj2+MM+UyUTs0lPEyTGuX2Z5TIWNa7H0JN+SmPoKeZkhWkw7TjzysYZ
5KEUUKJVQCH7raK9ZPRsY8iJO2Vo1spmoe0M6rUjWSNXuCNGn6juZ62rbCYGRRiWM99PHvnvhDQT
/q1ubpw769pv0s3XO0FhWEd2dstk+vFuuPLChb2bpvF1mTx347V6jRKunEmLkaWXvHsOBs01AOTM
Pa5RIO/Au1LBlCtODdSN5czV0jMqYAdURZzXBNDjVZqIuWWGtBccrEy/f2z2KVfMmj0niZVGrh41
brARVwkQ9b3dr2qGUGFch/ovY3EVZOGXX/y+WYtSDBD9o1PkB6WDLmMcVTn7ICD5JiJQER+IAPUe
nwD5bbb8G/o1qbS8RmrOPNU4K3S0FpUnrtVSz9UgbqvBS9YyzhBN3IxCdjYz546TcQk1JNQGtFZP
jFmmpfHPzxHnBlYQ7wKQjtt59fLb3j5bB9u3y268FbpCxRkzNeUj0jE+SG2NLS9pV1l1LC+lrHDp
P67WoxO4TVYVd1Jq8k5JCSXZEEjYGx+1GCjRApuzT2850dDjKvhVESFBPuElnBTpwMtQbOr6l2cE
ncdzfjws5cZY+r7rG+bMjO4xherrT45GAi6TyWdjMY5Vm3RGz7O9s7s/iy2FrDtYc1JhYoEphsk6
vTJ5efDVYGF9cye1YU7EePsU6RqxX6JWq7MZOwXp6yvYcnxDmZCTcp37H/Y5TJY4t+lKqPU5S7j6
3xIsid0YrbxScGU48nAY4PomX79kOUr2G5mXjJhatWd/cLmxtS9KYxeN2qKas9YrjYzykam3ozsj
ODTsMdNkkglLBJxrRvC2R29bJqy7ecQ6hXuBMdZyyRkpO14tQYylWxRB2DJczZ5iCoVWs7OsFXqM
NY3q7GCosVLSEfUmcLErMjJxz5nKlggTcoHU1YJQYe0N0WC4cMWqGynPeNcrCxRDEETaHRjTLPc3
hwsXxdNel/JeunHml+tOZfH9Mj7vbqLdHru1unat1bwJp2QqqVWnHcDKSUNK3WNdqMbc2dpA4VO4
lU40u8rEgaNcU6YsK5S1Dalqa4f3SJxtgnFd+yaEfD2OIXmpt9SL1W6fORLabm1EGcy1j29qmxY2
aTOhNWsG8R461agqjzRLZKdqpwzJYs1NvrCd/crt6j2Gj3Mr6Put1bTt7qRLNQG8rEKeKijPT2PV
UpNoyWQK8kTqEctU1kzlOO3i2OtPBmcLXBjQHhs2Z/rFtpdmrUzRK7fn91jbVPJWS+oMYoi8pENw
Uk6a4azZUDiNddMnSD/uyrZYicxo0M9i7RfdlhdqToHeUzKVmdhGM9vCyPa/xlPhy4tpaBgLGtvp
edM3O7tPw1Ax1bq7R6aggwgnV0nk7k6tcnVH1riAsortK23RgI5pIM4F7YZJGx2awyCgliYCWCf7
ltIMxVtK9V1SWKfYxcPka7WOGp9WaRL5335WtLOWqZp+ferGVa2WTbA9kGkQ3QlKy5SGcnkrMewS
Eay4Y1Yc5trsXl3AcPjN7LytxVrdjyJEBU5SetVaTxoLzwuWTaxUiudkyH1o/STxVBNBDtU+2ULz
l3zzGoG6TGmms6VSUOLNXqDkuayj60kXmpKeLOTjScZSsc7iU5hSDiolB6crRkdZZJEXJioJiKpg
ILoKTCERKEkuHTPRMq1kDnmGm4nGdOZfnkTeOV9O92wjTcN5VseR017Tk2jY4yfQ4iCbW1hMs6tk
iLPPQL6LskihFtl3cKlFxkTa45sqc1ZdPGjWuktKzhFM03MtHuoX8uUNRa7nGpp5utju/I2+UJkK
+xUpWHdQZDPTilxsL9iW5TDF8X6VlMw8bZJqwJ/SINFyhvwN+ftTrzONV09V01Ze0mZ084WqWKD2
hnZF5N7LMakwr6DC1olbEjWcOoqudNFFtDA67RU5EybnMUvEoKa6KjA6xqpqkeU2z2SFgWUOSx1W
1ScJOz0qq0xytjkzsrgjhBFZKPatnEvAKlKYh5FBcZIx1Ej7WSm5RogUpBERhIKJHuzOfd427ZRW
oOcPqfDjbdq6d9bBcl6dXVEyjYZ/KuoCLFbEmR6xli1tpeMgYsSxMpJOrVNnhLLToaHamLDSyKyz
Vq7dmKzjBKuYExiGExJq3gbtnOQRy5AVmawVn71NyFebVkBgizUzgzf2dnGz9Zk7SRaVcXJ2/rVo
kWlljoaLmnCQulkX5yJLHK+c0a3ce5Nd6THUNG5caP8AAdslJy0ZLtTWszWRbQ0d5GLbYisxqbW/
uwfRVcjFgawqclZmyafamCVAe0dhZoeyXqLrNuzlqEvlLtNireMM25fm8pI0m+Yqq1pipVw+vNrm
DxttrhLRbI9jJx0K9nkGTqDYWBYCPw5diqBuKJ7FCvTIXERKia+LkU+hOYAvd4kc/wBU/wDSnmeG
u/daK7dqIz8mMpSrfkcMgoRctdGkZO2dOu5IdMH0xMzr22SOPL5eGMzPRSNik/0kgtBuWpHaX06R
jk9rgiFspa+5PTjWoka/ZWOE2+NZCkwFyjqVHQ0vKYvaT7KRm4tvaEpVazu6u6tUfBjOTyLJSOk3
UcdKLcCqkYpSYrGsLR7GxduRxvhLDkNNhqguOQY15mLDbpSDmMDStWmoyu48VdY9Utk4u8h5ZVJ2
WizCDSkQnapmr0s+5yiOj0++kTa19llFfONix/M0xngzL+DcWViqVKSSzFDQ9smDuqnV4JsrKDVI
7F1dhk1HAg+lQsUDVkzsq+q8kimMEtDidvpAIIo2E6NXKVT30n2KK/8AIQZibn5PQ2HHIWqTU1J0
2q0bMlUZsKzLWOgZ7hiTVfcwsnepCuxJ4OOvBZUZZq6Trd6gE1Gs26g2wxzwpDlhlhApuGRknUnk
K75qvGc4aSf4kut7kZaWm18c2SzwLhg+nnXg0kSOmmzxhOixeJ9CnI+7JQB9kRDixLUTljThl3Sd
gVJ7cMWuLhRNKmCqpFS8Cuwe5Ng82QErX6xYKBLJM3StgCGQqsnYZV6dzHFFs5p8YqsUgTCYqaPO
eM8ExGFcNv8AA0vTD57hs116hEskW7rMJD2GBlqe7PU8i92cv54YRvMTjF66YTMvKklq2Zo6GXap
i3V5LXm7xorA31KuyA5DyZqE172cZ2tjShtrDSkyZifldwaMx8DaIdQGsek6jsq4OumTMZWZ3SMW
USDpdgoZ77JPJC+r1dj2MLIzU4o2bKdhKLmBGwLxxwJLqiBIo5zjsI6w+fpK16kaznjM8vcJlWMy
FCXib9SWEMtIrK1qyesrarVZhPzFbgIduZntHldvlwAVR7IB5/Z4O3UWu9rWOdCz+uY0e2u+KXPP
cYNSzYwreVMj5JcPJmjoRLO/d1FyFqo0ks/mEcbMZNvIvotWPepqGOdo4BMMdREXifGWop3GYJl4
m+w0JItiuUlYWKutcLJH/wDiKCgXM/Hvoa7NvcxfO6yBTj+rMO47CvN1vMBYiQ48FTDD1lswDCr7
ncknys2nAsYkITDp2X5y87QHlG3M7fke53CPj3UQxstvsk7HRqjtuKzdpNWSZXZE7Ew85SoIqpLb
8uwJKkU35TkEbDNJOsLC2JdPMzhDJVdmDzNgv92tDHKcHToW0TeH4Ky1eqw7GXxwtMzgO2EtYpWs
AxfKQ7Ro8jo5M3PPETIOwza86pCUXVrn+lViChq/XoTKluZRkJARbWFgWcYCvYx8e3hGyq0YCjZX
6LsisuYqnsCUDblGZdCDbBdrTdw+QapQnEdSUr3mXPFlyI+Bex2bGFciazH1Cjaf4lBdOFNkRWSa
P3zl/NLQe5JhsoM0IOkhOl0fCXDiR0GPCUIzEuoOkpZXElwWH0e1hO7gakWml/rP0+o4MxrRMe0H
D9dla3p+nseZKZ3zCPis/PZMd7f621BOvGc1F9Y5nbcchWGURcR+4/QlAeGBq31P6aUdO2G8X4ox
xpyv2QrBgyMrGWMjwlARgsgY+ya1lYiQcS7OcTrEU+duLLGNnLJMTu+0ZGQXTLsKShS1Wz0q2K5e
PBICKKwCKHJsBScoe0IjvygAAPtDv094+fEgVbFkXNaVsk5tWUK8marmOiUVZkWTeEMxhbnUbVKN
3DaOBPubxxZF6WiRvyzpzNj1zlS3NL7HH7Ze72cKNmQ5yqSavvJPAltLVXAgJAOAlwKrVp+LWwaj
Jr0cthLk0KYphmJg4yy6M3cM6xVGRNakXSV2jrynqPRiXtaRJMO42OOwhyOFWrZRGiHkGARZlDO2
wKC96QmLwnE12MCg4ypNCeOctZIYV+eqcjTisbFjaPjESRzFhDU6VlXaSbQ7luQ0raCNEiHcIlFU
DKkA0RZK9HNqCxdjibypLuMe2OnwVYot+fv6dbJF6c1Oysu6a0y3nSdwUQUG825YvW7jmEG7Fdm6
R5wUbqlLpNZ+iKwaPYnAbiZvVJuDzNmNWeQkk6NIO37NiR1y8kYzMo5ZEkokwTUD4fLyndm0/wB0
Duyy+wcFjmPDu94gRLjASIDFMQLUVKYJFCGyeRJqSWsDCP8A1MTL3U/L9P8At8C09N1Hrtc4YKnC
M2aClg0y4sB6owVjkjjNMI/kn1XpmctJME5dI4cjpBQAcom2BUpRHqFno/GOKJbV7p/gMxVRS70+
15Wx5Bng3UqzaV97JTVsho5hK26GdnkmDxi6aJKrPWjRyCfYpnUOAEIYQGbHTbJFwvlWgceoPZ29
rvkoirRxY6Ms0kRddAHaEY2ZSjV5CqIrNPzlJNNY3at9liFFP2uJlyHRdTjOdotbyFjyy1y4Tr18
5ocdFYrr9HtMu+TS8SkRim1JiWMjY5dB19EDeSSk3MGrumoVE/s8I3UoiRRfUQbwssEmGUlKHYOQ
QcQLzq4o+rG1XrzL08zra2bQ3hDGknqd1N0m34KaFxvOaWs33XGsbl7H1etkrAqwJAVbX7H57SxM
rEEXQHtYIYMGqLxL6RodQntcRxcfRRsq9dc4w7rMRGEBhjAWNNT6Eq4qbWVey2NLaCgyrUG0YrGn
cW+EEDFjk0gUrUoKhgLZzAL/ANYwEx+bXDdc0wGO6jedRjfNGXEWGKgUUyLkisz1mqk4qEcSGts1
J2VCYXqgtQ7aVYSjp1S0Ug7RdkUvUI/ltUGqOvytqbL53y/3+3VZjQrp4xcbFOK2emwn/hdcsBJ4
74ziAbeX5iANyfHrtwe9Xq7XdUExocUpghLJMOajjBUSchgJAYPUu4kvDhLWvaGMsEHsyashrJn4
0bMi4XQrX7WnmyegM/4bsePsMZEoeMY68NlXfqxd7Rk2KtNgQWra8y9rKTZpHN66jF2Azhwcrxx+
bxogpsXhPhH0e2WtQWYL1h/F9lxlKjRMgGx8yvaE/YCYtt1vJGzUwc9Ns7ODevHKBIiueKm545xy
x1hjXo/mr9qqrEumGH1PZJbZFoWA6cpkSv8AZ1SyZHrEhU6fc6QQ9YlJWs06Ykmt0ZqRUNMs3U47
Zxne3iC046SVbtQXVTOQPGNtXmovBT+SPUbAghNNcnlyS0f2iAZTStQyfDqiylJuttSnbHhZhyuA
1+5KsCMYt4zAUGQF2EvBf/t0aCYmxCCwIAUphJLPN5mZocgAz2Z2keTXpXDAndwbnQ2MD0aegCsa
ur8kTLMq+pGMrAFpq1IlIaaLB2m6ZEg62/ukmjVmSkLMRVvjq7CRTIuSexnIgGyNshDh3ckuwMvU
Y9OCpEhWS7ITkSUIi4UdHRSTX/UqKdzEAekW/sjbnKp+wJuDpwN6QzOenY9SNU4qkSI4+yDdMjUp
Ocj5NZ1jdGXB1q530LHV6dju2GbHtm1rx+jYtm3btm10soOObd0+59zv5/qx1qiaVWs+7ztrjFno
hZp4xZjwECm0CsIbGnCBPEt4Ks6s+tLP/UQ8ICXYhIsFiMi6+ef8Jamc1g0nTODkDlmSMyF0NJFN
c1NaCRVmOKpviWpYEngTS0kxYxB2gNEhgH2gwcDkyiFPL1Y8jXEcrDhckJGFLA6GjM3kDwDHxDok
+G2a48ZoRyADFw0lg7tHz+VEesa9vehwjo75RwLOCwxKlRFaadNAnULjrTUHkD2czbxS/qxBEa8K
tznKCVg/QfvHJ+EXkyHVB/cxLA3jwd9zQ1vnGG8cJRdbit9OSYIraW49XwADC33UIyXE1NCeK6fy
MjpcN0qfygA313Z4XpaaMBkGoUH3w2SKYRbEaEKrAi3F/Ud2WT7HeisITAahAO+RLuPkaI8uljQz
hiUDFjWCfkoYGiOMihIKd/mzlXKPkbVHLDN5gbmfGPj466wdQVhU8aW0ol3078wehsUXt06JCi1N
JKYBf0ZXtbaduDbQ+DF6Q7vft/78WoXIn9mgGQjSoLGh1jQDxJUSJUgFiACw0Uo5tZYHv+8ReHXL
hwYhyw6sX7/STnDH1pgyRvZdt4enoPSAzFK1i7Qnf4YsQ2s0o94Po1En3FtGTFW5dJakQNsf5kzE
adCproUGCD+VkVvvOAhNeoGnnldM95cNjdoeS9u2NLm08AAZhLx9o9aryBKV8SUR0/p28AIsKMEd
INOy5HBTWPk09t31xX/pLfAe2P5tp7koy+gxrJWt+109ASpRYMuIooNIcUKr3CW2nXeil4kYC5Cl
bfkmU0FDAckUZqeNmTujcsF/EglDmYu9dRydzYeliYupeBprLG/97c5mRqFLbL6G+bKkZG2EMa50
QWdRqrj5bFwb06kCiECU2RnvtCWvAc4q4biK9vpr3B0FDQzR/+eSZIJn1b6YKHnO8kjgBxmP6rSp
PJKGVnLJg3R5e1DVTxvNO1q5bw2ZL+yNnqNudfLt9aDklHPYWL22OkkJ6a4yZh0vLMwH8vXhH7pj
We5ZwH3C9E7t0jwrNsv00dnKpSTyD7kA5jJKZJ2HBEvKxIEZXvHu9pt0tvl48UYwaOqqhJO7eGHs
VdvybnvLiOOYS0RGcmg5FJf0aoYlR20p/FZUjbRDGISEg4CFZSaJClF2fqrAeg5voo8aBWPem35F
KnoyFDAFowvZU3GZpnPz6JsWgWEt9Wk5+g6MCsXadrRs1TLxDaac4rmG2UKbMdkqG8v4BqnNTJUf
C8EdofFYYn77fUSq8CTSGCMhSUKiYrvCUukJWWTECzBDI4IoykRmymWWwjf8RGhLRuZS/CX+B25a
1Xbr2lSm8HSuMU8mGQ3jQ8Oj/SuQJgjDyVL1GB9cNA9ykTjD4OKLZ3U1WyVRLghKjvNxE22QG+K9
3DUBM4aS1rXKC2mfth8haEij1m3G47z/nIFKC3dV0oxu5mgDLW9odg06DS8GNqlpYs0kLoGUfsTV
yv6cQaGBWjIsCYp/DAOlRd6GeCWo1X3kXFaieeo25e3bXLQVsyMz5ndWGlOPIpmq90BWMnJa2QvU
FmrnOVAilzLpSfKHKZX0r6zVznQ7d/CpWb6Dd9/OAEvqzzhm4bWXiJaNLYq0OHPywP0zLd/Rtidw
cSmGPzihpmUZl/KZsbyYXFnROhRGpuscHmZ10vWW3zVQC/q6RMUe9oXgBxKDQiQFwUS/Y28vQCRA
9mfCtkZ1fbBMLCXpS+imSEVy/VYdWAuBl1vEvlr23CGuXV0w2siN12aXNeNOjGpos9MGu60/SpHc
jp+acKbsBRaxjMoGHaIy7LzKYxMHEiwQX/+t65b62xNdGFx6UH2QVJoRq5ZTPyW3i6s6joxzU92g
8Xj/LfGbCXmBBnzLVu34DjpEWcdfL7BhI2re92qsF6ke4ZONdseUBTGrRaWcLhAP3Z16lfYpzheA
gSkO1kwbgzlSWJq4rjSHDf6fthtYuB3hrFn7bR6Jry6O1hO2BTLtU0nWo469+0VV1TH9oheP+2Lb
oqtXDDia+G1qhMw+kqtvt6IwQ7s81l5M62i7PVFN0kbJHJECvFK3S2jfnmNQT+NI/lYKE1CloSYh
JXMqqYCE991h30xBIdSEfMwqg5HQ7sSMgl/Lh5rKRMXcCXM6RovdyieAjrM6hK9mI86yRPTqsYPu
k4Lf8yeXB9LqqiuTTRML2igksoElBYUNOn6B928Z+g1MUWWMsXghAmEMTxuqMuABye/VCnOeliLi
z/KoQ/BUR01GpoYredd3VZ2wlKXAymCpt8S/tywa1kirhjAcwV3e+H3L9umZK7DAuKV3bbpKjtt5
1aPRlE5NnGbfw22lkgQ08fotPdcFrExHnzNKSzW0wtADo1Mt8zFnBzXqUie7B7UY2VENxZ387CPq
79UFv+pCuFvbgYu4rZXVdMJ5QSLHZf2ftuRnMLXfOVvLRGzRENggqYWozoPyyPuTYjXpcJxthkOC
khRFZ9m3diXPsnsMYrYQoNDimcCxDxlDBsfIXv/4MVJHvhnwOL31cco0QFEa5WsXUNuRg/tDr1yg
iaQafNSsuyii3F2oSQrU5Auu4OnCaxddS0/Lihx4s4PgGssrbryaDs6LtKqdpNEfRUpXXNWvF75D
v0zIyhtWCdsgC7n4hEXXgRZDcTosh2A9WZKWhUkdtZmKKwv30vmXNf5uZEpFcHZ0W+s2eUEtJlrN
ZGPi5W1Lk/aCJRNxwxivwOuoTgUXQt3Mq6cCyOmLDRErIViSAmfnZ5tDy/9T39qy1QBfCr8UpDES
FMUL95eeQBwKVfm+xYE0JJFQ+s0N8gWdy3+riH1ch42ohJom0fhhTSQtsC40zuOqd0zk2Xb4lv9e
kr9ylemcb/5w7+MLQKWYb8P2HvoLRvSfRVDu1bNGX63yiPkZWocP3+E0depqWpWqPezbc3C+O8MU
Xqaag78PW/4rgSqdfBUA+URTwtSCslXMsMLU843+Q4YIQHDzdKP9JD7cRk4bhaKUl0xWLAenklSG
r1EUwLlgtjRULS/QuqpskaIJjmn+TbbRiSI2fghOCVnfsQPw8u6z9+gwpf7YI4ZCGPfwVwBs75Dx
PIawy0Y2Qp4IFQWwCer5A/YYiihuphCiUQw5tHn+jco/06erBWzXzx/pny7UY0qpckUc7FxYbsBU
IY2e0jfZO1JcQyAQWeLG5vs0fHe/BXdEmkMD48jpw429fb6/ffFuGws1cVApAjCNjh2uCQKfYWD8
Q/UdvgC52DP1ih8FITteaRC2o77dIga3d0ioooxRE23+Lz640i6smI1l4RHs1blIZp9qyo1Ic0Uy
sm+d/rF7Hx42EK2w/ln97arUgftQWwIo+G19ql6Kp0SEvp9XAjFvfnreJpiYjI9WGP76DsV1ob07
BHpXDJ2+xIk3zvR+xmZ0dd35C1QYRYylr330gxsPTwD76UfXs5uncxLN5LP7TOqO4N2a/imw1lED
lHc/JNYiBVHRijKlcO9+UkCYTx44Cb73564fmq4WF0X0t4kBBd3ZZXQYsPinN68Hys+LHj8CWgRq
D8ar7e3cn/wu5wO5tdfhUZ2ntu1S9JyDY4Uu/p0vRQAiAQ8Re7dRuyzHQZglRU25v4IcRmAT5AAU
gmz2TZ9PPT+GkAMZQ8QlYjhCjBaUNzf6f9EfvAIp0xTkzZ2EJ3xL/tAIjwAv/QLE1jZf3e5uD3qx
3kJdyZckapHAQeyTPamO8qaujv5i1u2gxxAjErCdrm+BcHq5C3nz4v+D33LK72U74kqikcYlBBnl
m7MGgPE5Qsrde3RstBMhy5A8TwOQAHjCPZF2RK4J4y5GOGjjkfkiP/Y2r85W3/k/s3DX/3wBbPnx
buWOkMitPD56OjItYmHGgo+IMJk/bzqgQT072tfD2k0yolJKsEraThT4MgbPSflLIlvgYK2z20PB
7A9kOE4ow+heE1Bg+J99qPhPn11t0RiajtqlZjyxbYLAky+AbsvdSS/sjn+YCSMTfg4WLWHY7U6O
tz5nG8aoUTITypMd7sPd0zv/DtcIMbWXIv4EcesQ++bF7e7u8bv78XdRKnKiGmKpaKWl0lqutrQg
f+3Z7PcVvTCdvgMlgrHOn23+aXnkyGH+YTDQU54+b9dPEkdCqBBAKRgPf+wSlHfe0L3FPwL8pMAB
2CkAhqCyup2z/6XC0WvXCNLv3k5HxI9t7us76Arc5sPz6elWBuoI3h0/dUP8z70vAAFu0A1NAaev
u8eNo6gwqhj6EHv6Ip9Li7mdm+vUb3/4tds7QCj9p7Z9z+Z7B/LNrk7BkfIm/hvjR07v4JbAEwhp
8O3fVxhvEpvUT51SU/34Ouzfewev9tfkhzzs5cxOa1B0JTFLAfwrEzRl9itJwV+AGxiY+9vX3tEX
r2f2ptnT+0fIlWaEa9Wn1XIcOZpexeJilFC6V7OKQw2o1r8RWxUzEMmgDu+ijJkN5hTmk9FG4KES
Zgc8VRrXZmkbtOz0g0gN6BGaQ78zFlLVJYkp8Xwsf4IK5YiEHDKq9c2Y/FtiwtOIvfiDIO+QuuHh
0V5PTI8Xr8QNJAbDBj3/kFJBHlr6Z55VhQrzq1ZEZ7AIykQkwhq/XspazQGWxug6sUynM7rTJd6u
ugPYSW+nnwDw8wq2RzRXIc9eoILnk8fnCzDnEKXInJXX9mjU6rJV9Jd/nkc4pP9t6HFwX98C2q7L
FB3jd7tUXOhQAThhDOjZ22eLIiREjitAxCEVuiqn8+BBc6Af3xKMz1QNJPUxRYcPH17dlqh03MLe
9jODxv0TnWgfnM1bWNG40Lr1lDk11cmUrk5ztSnYSdigej9mdenanuD94y+6RXsisblLo6Btqdv3
lRRmz89dvNUGNItCe9mFFaAywtkjbhHtuUt6zGnzd5Uazfhf9KpJSXdeeMPsPrBilmdroDCrgwoT
eERidRo1cp0h+EckoyKveO1QX4O3qiSnj2tooJynDcQ54fEBPeOMJmy3rmeCM1U1jIRpxViJ+9rv
BEtpNy5kimLF5MjBkHFCRVgnzmS2X53GphioQY7YTN3x+miTJ5e61HNzlyNX7r9QtusKVA7TAO63
K7Oqq3i65YrQguSXdztsrRHWOF1NN4W28k7wBiwo5B4tPJX9enSxF3abJNtZfr+l1g0VbGaciAeB
NBIDZY+u46mSzPWcZYJsoQe6cGY6PsKTja480wEvsSfsE7bsno2aUU3tLZK6NdifzYlm0sCCX5IM
+hExlYGtSWd0je2bvGuyqithvuMcDSF2Vq8jmjN74VfYnaTLaauShkN38SxshbzBEbTU6dheUi1D
Jj9hRMvmGq0iLsmN4FnMoVccY+0RwEjHCniSNEgXKBMcEZYvJR/sWj2Ce49oPt0SghJSMqPlOCiF
5NwbnOYS4kWNqSSowT4wHtGE2or3spEEpQPuTY/zgV48S6oD0Kxxzgi/SEVGT6zF4UM0AbSxwBQT
UJl3wkNDKje7paNOct+9WjsWa1GTCXfTBxqBM3Xfau7oHOU72fxyIlfbbnx2shyNEa8yT/rLcB9d
+ARTAzpdXUq9XZRj0bI0f2Hqn0OGdAhMxWPNI9ypZiCFUBLP2Yy8wzRe2s43StYlq8m1w5oWtfkG
poghdtWEmNLior0pUp2V6q2pP+fzMbjzZw9nvpYz0w2HGV8AdVns7wmuILd1rOce00JGzanqX71O
lnqZlS1+FI/sRWZiTiNgoAbPOSg2Uh1PuWIzHDvtsNGNgDDj2AVr3fy9ksQmciZ63iqt6/sR3olY
WtQhT/rctWosWtYSaVei2hAJeb1Zw4xW+Ul5iUJqMyu0Vyo/+hs0bCgNibREuGMB9OLqz8o36hue
bt+MCawh8WW4VO2kT8qJJG2yEXatqK3U0hVuq7iTrCEcLC7jmOyt9VHJRqtMBVYETUuHamlswR+W
ggAwAewInMqRoGUkzLRSiqLNof3psqfahBpN+vppYhNjZiM73fWUuqJG4Mfjt6onWy27DoOhA5/p
7SlVMT5zhVeDqKkOm1ZNpvuLltpIay6Udr73baSwrhXx3mq+ZDvsjMGfOriZZS8tS9RnYsQJtjZq
6wC37zpICtjPEjSLbbtop986378A9pOa+3vkvNZ2HNN1WJKaKscUJWbF9m0NwHr135HWKL8zW4yk
RZ7l5ilFw2tFhoeAob4ZDnPC5/Ek9079BMsoaiEl2qOkwTUBRa3qApXI9JrReU+ReJVU6YnUKuzv
JYxOd35uDoifF59fAGKS+/iyVBzrmaWsoSiS71APivWlP9X0VM9YqxhT3DW1XqdTGYv0zhV5SsrC
CA0u8PJyVzWZ08Q8jC6WJYKJoxxeRwFbEBcoiF2fAvw53pLYNLc72RnXFyOuiHtW7XrhfDSJ81aH
AVE468SpGa4kAZlFp6wKkqopVjV/48mSFAXBUQaws3+g1k4IF6IEnLfzy+i3P03HqPk4zLVpMzdA
qAa+dcTPOic+93KrWKzj3DAYFjIYD66r0TgVm5eX01HUM5es0dXfnSsZcudv1OHSoU/sK5P7auzC
x+vwYnAtIU2GV1KdehHuuESGuVzoS9NWWw23y1NpaUusa6vzaVNwdlXcDRZs8DzsyCkJz6I1Qpp+
d59BomfqanwRVICrWmRssqkZGqh4FWaujDpkXP7kSZxM556W9fluZ3aaagOrvTVn1PaWvVDIIkCp
OeLEFqxkyXmK2XRwwCOGHqFXl6xzGL8vEmmvUWI5qgEMz6KMPmpgZa/Kp2lQqqJSWFyCU/m2E5yC
JoRgbOLyXPuHBFtj4vdppPAT1s0lgSq6r6GSHC/WfV3NU6+53z5KJf1MvoCY7AGFC7sE4SL8VApJ
IQ2BjyHdetlp96e9rPI9+50iM7Yb0sljquuveUSCLJ7NHKKqgWGZdeNC0nNly3Xavw1iGkd2JhLJ
RcQJCoeVj5CMvzmCH6pFAu7DJK3Y543j6bHr1pnv7j9MA72oLimS4yOtfdWYWJ9v5eMDQ+1toue0
8CLQkKg94CvE3TMaiLRp4fmWHaudBT2lOpVuhl2rLmXsfX4te/qoC+EWPOGYNqaLJTaXGzDw0qYh
zgt3wCLK/H2TKbQePhvQqZYZoNVtyg2FaplIyd6hlVaD15MJcqOIfONjoDeucm88oV4bxyhGOFph
ca7ZztDj7cEgySg9fkQidhHuLSEOKVsVKyruGEITAQhhGP9i2zMDN6jj+Ylsq8+Qf9Pq6TDzgDOi
tOIa4kwkrKa/2/QUZ902cPuyXYO52OU/Sr3/cqqlwIwSqyf1C2ZUdHzsV8EF0gLjfUURXb3gxBiZ
zy+uqb9iFldKttPGtWKmPGr5jofBoBdaBUKS3fIEl0lvvpeC+MgxiPY2iaEqBEyeYFyJJmtiB0sn
jYOGOrEyeQcc+UVfo/sAvaZtJalF8dHnYbpl7FuwhyIspX7gYAPLXDUxrZpbUFJSTATQXDzNj+gG
VSYqa6JT4U9UlVQI2g0/2uA682Y59fEd+8QRzWBTwDbJ+siUamovt8HpF0C7qIVnqFS31dH4V4tm
sSJ3HTNTebei58IvVJ5HojIDitsgDGEpUnARTKrfl+PkdBTmyrowTSRk5J1lAUgigc8CqVjEjUEX
JLTz6cVuzWGeD3aTxJ4TP5246Y6sa8+dEmIptmcEdY+MN37i8vxgYAMDrPysjt+Q5DOPjZHaUDJE
cRq7yRT4Rp9se2+u/gPk7UEe6yTHO28m1cjYuGI1F8+SwuU5qeXTQ2I3jzW1CIFrS/aWLhOhvkcv
LZqP8RA7tEId6F/ek2FwdL8e78pDmSCvWj5wVHy9DYUP9ypHZrMysEznhiV/nBrd0OEmYXDSaQ7T
qtnJVbSaI2TJOmURFEO+cHhBrluvl8uoZ9uztVY2ySmEUCJQ3hLTCIe6jKkeYtYpzp66m6852WWR
kKLeDFNC3cgqZSUlsjYxFaIBCyMe6o46vANLz522sixp67yiDOaPxY/p56jTmnfXHGyN9jvI8RPV
OR4x8NS6Lt/zF/MlYxM5vnZof6I6t7QKXUrECmOZ5ILmeKn1MDxjiNF49p+EuYVLpL0OC0FsNZmS
YGajNnW8Uz+VGfWh+xS2ST3qqMwBTA9P3uiOwOji6hY8ay+q9ojgiyyxgfpqgexQPSA9OTAsR7Ss
rF1MKWlwRXcgI7hI5VwNV007vq11yCOgNXyz0Zwrzr+oeZv4/I5Nm505s7ki2OOD6RyfQhKTzDqU
qiopwEiiEFMpPOxIS3Yloj2iX7j+GHg0LtPUl+LYpGXDlXHHpYdH1cWHtH9Z8TkAI92ei7k5LkTO
p2gi2YFRdC9pijO1trf3R+ywsAaNQVC8nZpsRnDK1eJuympmQO4OkYdbPtavvKV4JKwaqHrOPj45
AzWSvHMT8lZ4X0KHwrYO8/4Q8+Fe2FnDkULqLLa6Md+n16W51+1I6n8hM5m6sY84iuMw0nC4Muw0
ahDXbILIYyzZqcedXPhsU0LZSC4xzfqKV51MyzN+nes7fYerqbdopL2oGmCXGVRKsIloqBIl1unS
c/D8w/z6aBqVCz8JxN2xwIxYhdRATmMINynCWtzq+sMhUDexUHEvkc82n8RqhA3IGSrVhTSmSGVd
fym6lMIXPO1hljJQTi3fxWsa0XAY4Rst0c4a7xZnAmsWVCPdmmaz4DKv9mJB9UI60GAldeeSl9NG
Wk9KPpMRKTZCJ5thh0qVoJKlTzvhVDYbXRuuj7pNo9i22D1dbMYfEy3MPMzEdTCpCKtSbyhsDrSZ
tUwkz0prV/u44AKvsECpjizG+XTSqpNHeMn8YFLCGMwMhlo09ZWGQtKuaB479p0+4glXI1jUqIzP
Xhi2deVf0bAcX7QFauPIGdleL9YYLGSbrSuL8/xYgmM5whJB8ivxtaxTBDna1geDbyODRRfd2ALH
DYtGJzat1s4XKTK02gH3C/bKobYA0Vmc+VvMJ8n+obiR2h/7Yow31OpsyG6VoCFEyUFXOCIp8kha
Zk0KAuYJVODTWvqmpEZQ1q+pOCvKJkmZUaGN4yPD7deV1ODxkXYjfWyF0OYlF88Cw/AoIq8ZNxTs
ROHBlCYY6ad1lxrZ4M/QQZ+MF3TYIzw+AXVXz2RDLVhc44kzeA87yhRTeA68h0aPb+TnrMdKM3Oq
gaNVhwTJ4OPZDUibnBrokgNmPEpXUbcUMGPD1VoEOOFmId5/oi9kyaqok8HLcm0kn1ObV5jRrEay
CYtJX9/cLmRSW+BuXfdW02+3Oai5YP96G1OL6C3HUdKnjmPSKwH/ZKoNMfZdFPtQGqKjTZsMH8TR
xBsVzwhJoSApYGbeUS6pFRyxwToFu3HhTSRHVchsLFnccx+TdbnCRdA824c0OjNSy2yYdpYBu0+X
XFLOexJ95bqgeKkAUVJhQyGuqPS1q4lmeSWkKOP774g803VWm6gHXT8yLtvOWLSMr7ho+O7MHzut
0FdojYCw1C38/EXhdmpQ0zaNsE4+jNV04+08AkVHB6f890+Rd5jj0QmgSNvmV0V4avQInfGp9bky
7sYJE7vNQao5aS4UY7qu0kCmG+b670gkXgOABktgeXjOxseSq7QKd2TzEZ0HmEWtKkXhqaMNyNYY
LzhqluhsB+P9jNmQiwN+qoFgVfXp4DF0fZ93Qc7pd79HRrt3h/iIzNLZhW0CXfpaRdkOtvD2Ic3Y
yEpN82uEGvgQqVtgsi6046IcRphgXscvqT78fEiF9sH20iLZbUsS+TD0CH/FNT6Zk0ND2jZuTw3V
8SqTMzXoZEmVqR09NClhdteK8HTSgr2Gj+VBR9E/qui60MTbK6LDNOEM9zQYFV68nKcvM0+agxxb
lBgzJcm4FFqVrZnaT5jLGHW1PFKxrrgIRa5hi7oXnVjTphSYF2FhZKLFSsppMH8CLMysNLeSMo9v
peg7R+3VfK8vVzFjusL4bjTZ8Lo5Y0Z0/Qw8pnBz1183HS2XdG5KunSLbLCSVmgXU+wmZg8aq+il
ahlgvxMm//kBacPEqJoz6/zTq4fHFQoIHJBoFprHl8CfIva2GThsw7eOAsO58Qi9KG8/VxlngkHS
fV2HY2RGEt2KlFr8oSAqnFRnSOKG3D57ZaZbuKBeBq9H3LDHg8CHOKw0HOIIBa8miYW8mBNZYkhN
zXGNRsUDa3d+K2a+OJPZfXjE9Z0mrLwhmEmYaUart9kKGm1Pxt67aBl70qij2B5r+OBg3r0ocUKW
0yZvhBzn+dMSYS9uBoXuyrBkKzqyv0CYVb5BewPKImwO3FMuPnkY412jcyXDaER6QE/WvUbdbsys
yd/4fH7RjNtZPXM6/yBnVsWoittVkQoYADLcDYvU1k/sKs+rRjqUUVceaApJ6uANwtI3V3KZINAt
3ug3o2V3Xc5f43JkYmC+8Idfb+SRMlKDze90U6Yivw+s9wzFukC0ivUSO3QL8C/qo1abMvx2qhsJ
DmWSM0YGhyc6hB4SZ5rO9Tv3ubsyEVnjxpdosi2UOkY4sa1+1IOg0sxPv2bJPK+65sfq8Sw5xUAv
pW28q75FQQRFEXc4f+4xnQeSMgaMCOAHNuGCXA/LctCn5Zjd7Yzs0NjwscWWo3ZOYu3MZhnNUT+Y
I9nwD0tRUJKLzwQaiWT3I36BaB4P0qTyWsRvCP9/hpmDcZHRdWowphi1W4xDjplfF6reLcMJPoX6
VCHuDNOtHtjQ80vKwgzMTLrgIJQZLl6E1RW6yAY/cBc0Tq1NIOGn51qGMOnvxJhXxHOGNlv//WAN
Pb6y5sgJvV859yHtk6LwRThInBO4n8roMPbbQwrI4TWFGI+uFCCU5yAGH2G9Sx3CNLKuYEU71W55
QbMT16j68KOId5s43rl7huXbT5gfMrHWSTaOtAaVCUsMS/414saVAbbVbEMgdhMTJ7z9ywifRWxB
giyYK0eVz6LLFQ53JaPVtGwO2aDphv64lMiySf4sr4eEMOF159R6mdLjVymhQY8vQCB+G/BVxLGb
Fv+0lrkPpCEZlmFCoNozOIiQrZmFJyLZ5pE0lxmb1y4FNKxsSxtOkSTzSNJlVVVknZ5wTvqWW/hB
oeMa79UEqtCtJFQ6PuO8HIzL6uztaBxe1VOnwes35V6YU2RPJ9ZtJcnekkXAywrdtVNEGdS9vfHo
psHTgGMcEBnuZ5eFdYDMyl4/tCZWiF+GU0TOW/LMhdcIiawR+Gvr//AU3RjV7IZ6kAUKrL/zJgve
kvhYzgAWM/kkMDdzzImnqjFpYDEU4VFBo+OfNziIcjBPttLEfUZUa6h9l+u4mPAwqw1y8jXxdw0x
uyHFOy9SjZilt3RLHbo9ySctLfJanoKioGeaSz9b9yfLHAlWkKoMErwY2YmyAdl4pCXVmtgQu4UN
LNtwmDdvEF0+vpTcIjh72FgZP7NTRJRMyNBdNLgch9axJAeYNTpJ5ZnDJuFRUESX+BB41CBdZJc9
UvNqwjKU/ojygfdNTuthV0MNfI88I1pC1sxkgaW0GE2ivvLar0kIleih8cfebJPPzIeZkAx166An
cuMMRA0iY0GcVkzPGi5/dfoQM4178ZEPxcXU0qsx6MqKUpnh63u+XHv8AlSp7jUkM1/w7kvpI1ku
SC/Njhc1QTyU5s3bLft9b3GvCuLksiBA2mzS/iueNLbwGHhPmewyrjeximGrZEfzVC26fXhIpRa2
NrhDhQ3cjqFRjbBU8GzLh9JGtHtCJBJHqbfjAa3kmQQdgYct82d/4K97CYhaeTrRmIUDWpLT4h49
35vGVXOzcj1LjWbo28KLdEQKAa6Cihmp3u0Zk9T3NisNhOt/XEaeKxV/cHeTgdCXGr41NDDXnDGE
QI9Go5K82lxUOTHSMrJOSMhMtIlR1JiCDCcKm+LCQnVd4HKNHOc79dgLwJVddATMlfGIOrKJMMom
kS1QRjGyZJMt+3IvCbRHn3ZNMtJGHTljFdoLMYakIKv42cZTKrQlG8Gkqop4Ef4OBgbPg71Pjyu/
9tkpY/C+eiSlDUqmrdwVZ/4y4AukYIirxF4kPoDVonN1ylHRFlqeuWFXjiKlpIs+pm9z0rkWJ6ve
6flYHHNuaUl2F/3F70CHgih8kgbak2X4Eem4/MiUcavslBJZkl3xg3hgdpr+0ONFszI5APa9Mgie
anwTml496XzRe3lSFUl1TiEoFnR76RgS4b6CS2Fi9WE6JRbSwfiQadpB0BKstkv1NlphiIrLPELD
Tf4F8M25yfDm4VC1tEcBhEdwWOAN+tO3Wszv6+X9CmOAREuIqdCJsFbPMUrIeE69yXH4AoCOjUOk
5w8ZV4CJ3wjjjfFypv+eZ66ex3FFA8MLSWgdNAl0R2gMFFMg+CUXkofaTRMhwNo9cQ12w0LcpNHt
HKrYzdXZ520wlm4SM6XNpzNNYK0mKU8k6QqwJXHhruETeCimEzDDQX9KCkgLczEHndlzVbBkZImM
tz1HjXVo3cqZqg5wR3RbT468pKOq1ymJS62qQVHmPmaPDCSNBSM5YLToJt9+wIJAG5WV8hUP1wno
XZFENGcrhtUx1Y33BDQNhmvaZKS8fhYVwfRj056qbEtd1YoEcof4TPx0UMKqifROwFj9bg/6VC6u
ZKo0jrDJv005cYFwP3RIAPCuwTIZ/vuSA+QckBmR2qbfhVI/ekoHHetWVDG5hw6IZf/lr/dO3Baa
EDSUv7f3CqUCDcroDkwdGG4nw/6mueL0HoMKwNQny3PR7FJC4ww7pU5j9tS1dLxipXIdTxE0LQKx
QGBslt/7YJ9JlU7uhvc+tYjF1XIhVyi+zJB+YpCi2QQNZ49UNa2TJeFUGqfLozCaaRXj9hAqzaVC
iqAmjI2dIhJ51vwJoOF4xMl53RjCcPKXTQMoAonNOd0sUyAFGMUHuVU+JjgXvLmhjYsYBRonplsG
/Q0r9KKJMF78vX3ZjQ6Ho+jVs42RyJW2FpjUlB4tna1Zbl1NrWFOTVy2y+DjdfQTdt0lN8MKW6m7
bDS5JYEzYkrDKboE3LSrEaY1kVz0IlMLu4F5Ql2HmzZlxCYqPKOiXYeEOqmvwsgebc3MjENmSVck
Or6yYrqWVZ+JmXVnfF8pTq3iG3+kfVKW2Bo3eHtMekxjf3dsDi2pTH1Ckt96M/US/izd24mFV1k0
nykvst0Qk6uG9Ia72TqWlmvzL9cO2S8A3igtlLgqd6WZ/0SjaE5IsNGJxK/JtlQ92QFI2EGaCgOD
BS9eUDk+ujE+J7OpG0K03JKcxFQjmlVBH1WstglctFZZFIsqlAVdJJfNSDxSfmZJWJlKDquCBKQu
MfdTmTqVVUxmDntUU0CWFJ8MtVMKWAyJaL9LgDMAAkE/iBBlkdDIm3NT7TY1yaDuUFolMP63e9Zg
/NUa7BfApWEH1ichsVzF8g7Y8VD8Wv7rW0C85e+sGFL01ibZoS6xpf5jQ2yKjH19hXQBxtUT+Zt3
KKmxOPejQd7ME5wgvoX173JpdRAw2Gsv3x9C0G0KMBJsloO4C5DSpuhEi7CpiCCBWyob42YTuNt4
RlmQwzwFXASZZVHNaeapvDYiONJheLkKw6oWJTbn8auux2RFpGuqahpjE0raNKIU6WX/3g4r51V7
KFDTkEcx5HjOxYHDwJs3GEdXh9FS1cMaZoBl+xH1VkX2I43RpNNyOSSR4jtt4ceWxtsLuGyVn4Xu
pIsKjHpf8HA0FG4qQyw18PQA4ILb5+WKY0XUEtCww8av+4ZQW/TTiKd4/a5H+XdunRRLpboT29+V
SM1SFgwxkomshmSeHsHg5DQvu9DYRMmkgOjkBoyGqHD63wkm35zSMjC/AJLZwtKNWsQzKl2yXLnl
hNjt2arX/D1SIPWY40LZaHHi5I50WE+TOGieDUVzWWkWwLVx6QR+KtZTIh8JJ9RDIptsJi4tYLkk
r47delTF07G+P7oMqEnJCqLS0SXYpdmIuZCxfcEemVCQNBe6MDs29G0sLxfbs8DbrgiE0mzwTSOv
CxGt6Rs9QXyss9Zou2nlrUcVy641PGOjQeA5HV3UhhgZ7ONZ3lydTrB5o20rWEIqTLmRmDchS45M
ptb7jorDyURCgjMmXFdCm7+ERLZEHR/EBQgoJm+0EuaRqsuRl/zQztrjcXkqQkqUblm5fO4kUWfC
5XWk33DDmdg7KLg21Stng9ruaE1x78GMMkUn3CCNuqgOzhGjhYkU1NrmyKSbE6VLnwag6zAfLdw0
hXjLR5E59m3pHqitYMw3BK/rpJPKRVclHDWV24LgQVK/VjfbZddG3ME2sSNSEJTRMgNS3NQ8IPBP
4oehSJ640u9qeqzkcA43P55IZXYI55iSbFc2Y2g5k6pssFot68ewEkU1bdDVO8mCXJJ0oTb1S2jG
4qN+SCTp1v2yPJNi9BDH1DX+ixO71B2Ntpy1eboCscl699sKS438x1MUlh4zjjbRKdJPB1nVdxzy
YbWk8n3TNE1bdmUd0FoAjTraLbFwjwiV5DdaMqNv/o6CyBYS7WhuZBoxuf7uf3efI2XifRPpEom1
g9hq2qRnDMqNuGxkY5y8h/c3trulfrq3Ax1Ti28qPdAWfr7IZcs1yw0p2ztdKiWGYs1TjbMTlYUh
Gk/SGxHV4UFWFiDj1FAgKeOPy2QYrQl6RhwqmkhQXWyApUgUKKDHIT7QZlpyu/Brj++FV5hRpKdb
eP7jI6nWI+uIyQL38ykpQCtrwcnp+32RcW7TbOPr75s1tVvT0J8jQknezsCVYKRvMjQVXsJJm0gZ
oGZHdWWaZYcpPUo94ckoG5TmTYK84gvHGyTjpfHkMkzVoHKxEzhhSQvxMVPzyuDfRizdNNkIfYWG
cqlv0Ud3iJy1UHRylSLhQWDUSJWL4OlZWIljcSBu6cfjLrdF6gWFmrD6CDGwcf/OVGNA2kQAkcKm
AzrcAIy/K6qKECOS42a0TKZqHNMWDEqxoosXS0yf8lNAWCs47th2GyCCt/A+D5z6DupdP7IDC8H5
L1vUBOJ1MRoLJ+uytY0lS/rMArfah7kVwq8RuvUZydGCR/A2CVNDaxHhQM+9NlKFH4460tQbONST
GcplprZkJ2oP0enzJ1x238VfzBlN3DUm3tI86BrVi8y6wtXjGgjGgjbmkeiu03bAOo+ZEkbtjqby
F7UwIjD+8BrFhEa0rJdvj2pWQGQoSNTzNCNJK8H7P7nKfwGG294/dien3H8VRNBuXCpBfWpfrJ4/
f+SPDD9T1DKYOKU6gCFbcDD5Eq9uIOemyufi1DOJTPXhA0+J8H0J7SdnY/nQyyTQjRYPtBQclFxq
9j9bxmicP6vK43yNwBZLh3z1vgC3oIFj6kBXJOHQYVJA6L7ii33vaJQ1sGSzESN8yc8C4l3k5Zxw
Fq6U/U/qvA3xovH3GtDl3e7lbsk79f/vFJIzQ4Uh0XmvroDG4+KnR0SORugX7i/K29Vx0dsbjjs8
RnWbZ3xr+zCxtdV75xQG3TkmEhZPGVk0hQomy6RcEEFmsJZzfcTowjDr0/MFoMfAUhJC3WwiIu8V
doa+QfwC1PZxcpMWY0jJspDKme+c2+CnnmKnTX2sIKb68VTT5pO58vlbiY2/TVapHd6dLe2DvQN3
p4C7MZskxhXmSKKYGuJmw3eiJc9ggetHBN0ANySS+iSgMSYJHSSEKwOTP+TOF8C8zNln16/N/ZE5
VoxeFT+tQKw9ETK2LUvA3R/iAnq9F2oTcatVoL6JDlRV8mnwUc2ULjr5ECP8BXAfRj7iZTY9xsn8
K+GI+u9ZEYx+dwds8/wUXyCQSRI6AuDMi/IS/vjp5RB1GvIG81j4VoTC+AV45/MVsNdP/f6YPTh0
l0tn8zNt6W78QN73VL37rfX5oj703S908xKkgy+SBeFsfwBOYvspEDoZZHwBgMsZwx0bdwV7g+zx
Q74lwCIz8j8nAfDECqGA3T47RICS3/JkcE5ocbBHZmmQ2d+081RK8CNEsH0ByjCfAF7nWOkPIucw
oMhhgw/0JeCz65PXOaKaRqveiHoLsmG3k+OBhIe099SWrGaPuXObXwkQ6AC2BYBO4qvueACsuW3m
eQ3+OZLsRwqgoaxHIBAkARD35gqd3f2bLQG2gROqSdAxdR8AUhQBF+AtKugdaM908s7p2qSCsI4J
p4jxkVsE2Po9/eBTB8bQvGrX7XnRq9ucX46yHnnz7pfK7DAqPmVddCA4ubBJrLJ3BIncBPwCfLTd
bUJfIad8Gh7e3N2+vDhGi8Xw66Z97H0aX735ajueIxhumozxFNfZEBi/5d+8CcTi/+/SoY3/C8As
E5eXbkdigdfD8edxLvvu9dXjO0ESx1KQTdQXgOpEE7MivXHIBCqWZIR5CkkX+ki6oKhtooho9XFK
KQz9MYi3zSzCAG8I3z/cRwTmXNmbnSPuomUbuhbbPxj9sU+IMA0Qqx+bmvPhjsBZgg/g9fqQrTTv
vpBiqLL3oxi04aPr2x0Y94Ex1kiArt9KKNjr9jDNG9+WP2eB4EKMPk/cOBlEwFIQhfmGSvUABkCl
+gggMO6djQHvDu9kWhfc9DPf+ATr/fjk93aYxGeUtpstFTrF59/u3rlq4n3+O6+Ouw1Tavpkh9fS
UsTpMH+VrJRnt8jVGCu+F6VsO2GUOTsm6EuIxPiYK0x8ReUldEXlDV0q3+Q7y8/DFCWggiZv+FEI
5kt6REK4qh+K7aachAQlIZV7hjilp+q2exrzB+pN0G0/AFLA3Wj+9roZz5t01q2UxTuvlvEOo49s
9xRqQICQ6FPb/gqEJo09ei65Tnm5JqMUO1vy4fsFaJyNMlLGtZuD7NoRjrPvlXdjUHx22QXNucsk
jF4AkSYzP472Jr8AjEj9xzebtj2vDbJK5zhFlqXI7M2M4Zy+XNO3e7ajdkaxJAaUDGnhPnlvQ9w+
mV6fEKM5W5tkRA5r3JcUiIGgtnvA2xeA0A0GS2Mf72/SVs4dBnTqbmsTbugfgVjd64AAiiPEodw2
fPHru117v5vNGCElvn3vKm/K/X95i8VnQw7GcW0CBboFbG2UCmlnb00U2j63d/dw3jMSo+iV8fj2
VelNFKm3Czd19vgGcLtXUTGsADhJkjLEjwBAtIc+SeG6Egr8HJ0NlqQrAdW3iu/1yvt+Xr/x7Whf
D3FGaMtE4FxCf85PdrNLHjjc3+2/LWUnYdH/AZt9cENBsr+85J/zeLEfGMLQ6AtLFk7jG1AGhG7O
AXc/e3TYuUY35Wst+L6zbysTfva9fS7EDpZdNyVIcUgSUZoZMqRh9JHoXwGQ5XvtAnt2PnECarOK
GtFz+Zm9L3AZsvV0Dicz+Uj6f9kJGWiSyfGFzOC0O6wrXuZWrinxxON/AUw4zuouVkPfvLzHjbfF
aNmIkkSWFxwp5sgIqlZkB+2XESL554Z9D0M/hSUOOWN2fznuI8s5OkAGCfqDHZEQ1yFPiQpCTO5+
8tLCk/4mmEKnSs207eOgf3sXKfkCMAh0hhDv5pNgh4aLNY5UC71l3e5ZvXELg4NHIqxp+aVNqYdH
nPOhAS+AaUWrU2X9iyVVd4mYUpupAlV6BN8mm0gKpb4AXwAFVnRKocMNGMcmn1SGRntr5sVU6aat
4J9VtDiB450ySQvLLQ5RhSSVjs3K/MBn66hKC8EWFsboS0jRCAqj2999onKKd8FYF8OmgM7PWsct
373bvb6NEcRFiZILOeKWwzXR/juUuzc3xMCXxM3kKDpqwQmN5durW2NNkwOUPgBXKuhuLD1VYRnL
qsCUY72m1S2NQiNeSVX9STwq7/Aw13P4CxDdqZFI02tn3rD7GrO3gfyYzWnVZ+X0EiNO1VKN09Gw
npFNKdxVygFYECKrbFCqKi3ipewoI4a7oF575ohCD/oOzTmKd+L/SIEWFWjBBcCggsn8gy++e3n2
7v1sTXVjmnSkqkDi37LvivANgNj1hB9o1wkTK5/moL/f6r9GkqQUKsPzcpWu6BYSlTVhgpC5OLVW
FLnUnMMgr6bLhYbUsV9qPDG37noRvhoePFxdAoUlV46FkI1j3B+1DlSeUfU2Er1NRqNyPhdOE5ab
8hxzS3MZL61m7x5lcvjJ+h5c3MTX1ZIujV6+AnzyJXqAZnQCZBkr8s6eUBwyH16XfQHmtVH8yf6A
K7og8aAqMrVA2CiDhdrH9JEu2vulds4Gy3iZwz+aKCApPiV59IbZEc6Gf9K6x2+UxY20P7h9fAE4
1qPleXNEL0gprWkgGIy4TjXU7WzPv8NjUTZKiknPjsgaw0Wem8q39I9D/axsZ6ZVgbV6iFZCYxKn
N9BM8xA6EXXPuuro6n/0qEKnlGmwcvvhK9c0L7qYfSSXlkzSblwvukh9ZT0ZZaT4fSmf3IpFjSL5
MHvBFknBrIiHyIE+GPzum3ATMAIQngiQAUMMEs8DvNiQXqI+heKqHPgSt27ePl+1vnwB+Fn/3B/e
8gq23UDUIcww/7j2WVzZ/t8VYFsTGfuL77i/fo22DfZXTbMWywwlqk/2UJbQdM+yDGoRkR03fAvo
lu4e4yKSEB2ebPoZ3vmiOcwrWHw5uOGP4BzKZhyuacK7oZP2GE4oP7HKy2fqhnWHxPaeLSG+bGay
0Cv27VuSaX8SzxOb5LH0AA/2/VJ2iqykZL25BXHhQLVivMyursj3t8HWO8LD1uvTqWxPKE09ZcCl
3hY7Cv50a5ugZyyUvNxIZ9XQN/ifYoBvaE5TbXczxi3/7TjGczT42Cu2lYzL26h7oOMaS6b5QMRZ
1m4Hx4y/woBZnEfO+nxad1hJTY0My0bPrEcyyH27ZF4+M4Ya0ezvUq6MkdE7ydruA/tXK1uqSXFb
WtD4BSYqW7xCT+pW8sejU98tuRemGrumsjive8ldzYGJ0TxnmjfRKOorPRVxVkT4b8n1ZBHKXitX
4KPIny3x/MC3zIenm1aloTK8Q+nObGZXhYhIfxTkL4AdOE/uF8DA+/19+fdiqkVYX2cVp4/5EFYr
WR09LHEpjZwr2Zr2Nz8PXwi30vTWpZYSmw5VaajTmSOWscmfHkrptCVsO1IrRRYKjHdA1/jfJQbc
QRh7JVRSvxYr7yimEFDCagbY45Kqkq60CcRSbTUzdquNX1UeWdwnekVGNVOkmhga9YhGKwWllW5M
w7ZRjbbNqjWEGlMyNu+HyRvb/67lfkhKXtHT+Nsio64dfENXyK0gdSYz/KfYbwi7XWhZnj7Uignd
9DCiZ0RnEPbEYgqL1a8Y8MsaCwS+By62Kq4jnIhvIl844/F7XUvvyusWMspAQpmbUmWQvxS9nQ/Q
n4o/rHj5+yG5aR3yUbt0VNN/+G+p1h/KEzR1Wuqj/iOgdTJ2hIgYuWmhF1c5WORvowUUEwzlNWWg
bqlAg8HR5u9ESaX7SMzfOpTEksPMLzxMOvVD9Hxj7RtGsjE/h+sYRfxyxgap3BulJLO391AqRIdR
h5jkxCXZrfzhRmUCMLQboQTHGTan9W0fK6sWJY7m6Urt0BtaTlKup/yux4AJWJqUyNiNtr1LtEZx
OddIOAoc8N+0+pGtqid4ghrVDxVTw1NjVNskRyRZ/2Z1mLl2qpsTrhsBDAkd3WXxyYG6X4CNAKV0
CViAafqMzfrz2rOfvNntKo/kjwJzHKlD+MwtAUwe3eEJjaIsBQO6IcszPERbny5YDtjBGQaY9ROB
B4z9rE5u/Y3f7nQOuYWV/EdT9oLjyavPj/TV8X8aMXNgVnhYI9XrVREQgNQH8HRt4kKyOFhIfJKc
A+pztqDH8MAxZkiaisgmMKm/PMOY2k3rTBxdHEi27+9dX4D8p4f9bRehE9Riy0L0qbkGMqBkVzYc
fyFN0sSEQ9IJTbHGegpF0QBR8mTgG7Oa1ZZzOfeGfK35T8++yP1QizEggIBkPyeyu+bmexHUsmJ/
vKKgTDZfMllOPSaJPKP0mjWtKDGyRRXf0mn0i7M04t+/xoy0odYeBzWOGwopUqqBxH2Mri5RUqdH
5UppD3bjjL9o2GloZfLu7gMtlnayjQrv+9LQN/4wcpf/UCrIj+celtClirUwlEB7olgXBDIggHxz
SMRJBG5CoZKguugUsDFtBarDrh8iYLmHAzoxTXNCfDvHPLwgdrEe9pLFOnNVJuPn9ddD2+IJNBrf
mBeI+Dix40VwqAk6yvTtiKky9a5/Obv3V9ggkn4BFjG3zGSzLMy6xSc4Uidr5bC7RNpKqPTFyyXQ
XDBBiBTeysA7o5GtMGIMRdayud7qkqr8sAeWmHBZ42zDW0wpErhfODRt2R9bQ4E4LJnfndHI+rtc
kiZcNTHfuVGUAsIh2tUHkcd+d0I4VS718M6saZNuXB+pNc1q5hqfpztQk8MbtkovFtf2FvC5tyqq
tHMbbM0eDTXb42fK8bMPklG1PlQX+XEbMZtVsOmH3R2mUmznWbdrddpOeSghE2+vdbWwwLGShuhx
gY6qVfeTzHENc1OviLdMbSZ/MRvvDCa49zDwbE0ihJ+Q9XFp8xfGMasxTXBE6a1q2LsCkultp8AI
i4U91KOiTBW4YXTAuQ5D+LW+NZZOvY2fzvaLTnkJtUd2CuHj42CHZE5piGVVfyPbx/asKqDRF4RY
UCuAi/9uBaAUlvbhyLHW+Xus/fp4xMJ105yphEB703hhXJEeS6I/s4G/nW9h+fKjBVBVcbV3dDiR
UCkTYHTiYbKgKB0nGReCkkTsGs8RWgWz3dQYVZHhWTe2UtW0WZQpqf5Dl5YVMYsomMKiOJ5YDe4v
43V4vZ2E783+xzMPo3pmeTzbCdQiUGjGNzYr1bJ0HLMHwp5Pfhl+Na0kk2CXTIg/4yA2zhwak4cV
69mF6B+ZL9Es0RSKTx7ccx3UbOfl9EcwOpzx+L5ZL+GpRT5A4Nr1yhm0ZUbS6KlJzYJRKnRpH6JG
J0k6CQ3/km5WGhlBumDfHYITYae0UOBRoL9ZRYekjw8pvEFFHBBOo5oOM8AQafPk/GlUhfIYn09M
PpQgiT5Y5p2hyl5Cx1DuHR1A2w4XqxlbLj/vdGZFZUKjO4OwUIcOlT85zlMyzmaN8MmoyMJxd6ks
xVvLAeOEb5SEQh2FNo2u01IR3MukbcJUTSD6UrOo2CQ9pLycOMy2xnoSIVmIrxcUWp49pN0hOrE4
k9CsRr4+XddckRE+1Z3CJAMGfCkoz88Sr7rwNco0Y+1HeaSi0y9dapqXSDWXLFNWUlThWdH3QWlO
IZ42bC4HTi5vTfHF27I5x9vNeGis5v2yi8p2lJL25AZ1kznLNVy4zGnphdQJQ1dq0JvWyI6cyQZL
CI8xoxt164k+7K/5pmd2ZCmPFNQKl1GeDFwn+/2GHBaXEME8fcAbwypjUICMTI/QYvK7KKWb6uRp
tX8IYL2rDmmrMFZhUudVh+CKZLPUddQZx/CkLVkKqqwfX/cxNMYUlVRzRtDoY7UixTbismIOr20A
N1Be3xddjGmt9+WxLR17j5cZi6e7vyh70/Orqh86XclBWxr4fE17lIu3IG8YGQInYFoRgKGCnu97
wNSclCZZOwKvUHA60cLFXbsOcdby/1H9rM7CByenZ/1DoQL99bdfpL6SuTHTluIeRQ3TTdhycYML
r1RK2URUYitgWo2UGtoIyjXfV/pYFsEgWuG0VuVhm0mv/pK1cr8rVCpCykgSOGnosZ7JJ5EvEOVI
ywlNjy9hevQIc5KcqbxRdVJV0WCkqVnhuArEAqKDfwGQ8DfId16gaAqjrOEwDNA0ilxTQ2SZ+1Co
DRseLh07O0dUd/4E6lpx1VrSM6Au2HLRZCenLNFrj7ObGmv/ahu+wx4lUbJmhDEGjXE3/thq1AhN
3lTNz/b0IxTwp50kNYd07VyaKXxIabdmSoPH3jtFtXbhXPvJrl+vp/k7bYDpidyJXr5x0mRpsXfV
FGSKPUB/OUjoOLr8HX11yagK09Uwc4xmGUJMXeZRfz74u2yLD92r6p6ewYOZEz3Z0GI6NI7JVEIm
R6uWDTw5Lw0OqlSlasQM+PPyX8QePTV6VbPqRRSDXjNBFNRR8Wt3e7oGbfQNi7R2Teb9aGENVYcP
6cWuB9tm1RvZnlWtNuNx9mjxH4PLp8GhYeE41SMTK7L7bNTp9TLKjWIVeXsVD1jUoVgkaigNuoYd
w0QJFLp0jSTYCmAhA2d/KZY8ud2cH37ku0SXc52aUAjVGJ7RDfNboTQ6Op1j+nuLoxxRWijfNueo
9RU2om9SYdZHkRPYFeM/N2lYIv8Kb8KNt3Bt18LY8Ylf5LN6U2rRIyExuN3Ee9FqkeuZTMYODzsq
kfVH8O4i88Gi15ulP5qpJJZig6aUN6g8V/dvENtEM8U73RhWyzOiM+rf9LA2zZlw5/TS3Z5ipoXC
H53/GUnN5NA7TbLXUa9waLkng6aLvn2OWqwSwK6xOi8XJUczyvzE0RLaIjMaEj/uMhWp6qWjjqL+
c4XX1mpcBUHMOCZZFyGoyH/J6rbGnH45Y7GtSG8LMFkB8b2dAdgmRhUVxkj8iylbTFoR0nDAUpjZ
mPoK63AExq4j1uQ7hjfR5eTE2t3DqoT7JNRehegn3MAjbYjq3J3mOF5gMDmN5IaFVqkzbyAF89NS
AYUJOi2M1BSfnN5On1R4KZ50p2aEETzYUPHyZwCra5RLZg7LEVlVuWlU4fw9SGgoleot8IVTOzmQ
bLCQ3GVysXZ9in5kz1p2YLzEHzjeD15BIQ8OQaWAI5o1P+IWgXX5QzGpcXVrL11WiLt+qZOLW8eO
3mhBSewiRW1p/pfDtZLNagVB1yns5hLCjmLH/ESJuEQ2WtIP050SrHsfo82tx/z65Vhok/eOTQK+
4efDRolNHCwbH6FK2WW0GXprpmvx1PSAivFfG6S0iwnKtURLcYamaTaSTxKsfEZ6xiTnaamZHegY
VWDI68RU35XgEmBlGYsFWRjJS4ZQRKRGT+gq9K4hiLkcgR5zG8ZL7MF1wwyy7RAUxuemOfl0ay0Q
P7iTlXatatqyA+s2em9wMY9K0E2r6sq0/F74V8PpOJRD5bWtq0T8S0pLEcT4Qhyi92SO5X/eUZqf
2CjyRBvPp8VkBFUQ4wYvkp07myclDDfXw96qRjXI/ZyoK7prjvyJ80twVOLbDrf37AslvBWNXG55
RY3u0KtJ8dylJn8+WHIjzTKrYfFWxUyHBTt7RbBvLq9n51CyJeEPdWazIKeE6DMTz3IEwWp5FB5T
QeVjgOCMDImYbh5+eSdi1JSg9DYespsdMYWcIuG38HW5sGuej0eQa08JmXTF3iKaEhg6gDlLShQL
wQQRfxQRTgMZVTggUEHgonWZ3W4hJxWC6CxUGtPbOsKa8VVzoUZ4ou1oXs/W6gsg8cv5mT0W08DZ
ZRIYvMBqWgHBqvMzoa68HJN8T/FkOc4qiZFq7kCu8Qswl9GuVgL6KaTnih4Qvyj7OSoaHdYWnfCA
bNVezfRzy1a1zFMLcz0dmCLF83NLC6uBw1KzhOPVoFlzcW0LTK7ZtZxjikB4/Kgrmw2eBWsAyozb
bOzVlpZPCQN6sLyVjZDbt7mWIP8LUKpAj1zNeHSbEiGAm67rYEVjReJbajRmrWvZApPiUDbPgKLQ
0oH5Iwn4CXWMqXSEqpccdbD/BbhlZnXXehn/AlRmuR+4hIqiJaKEBcfh+afHLPiD9atk0wsO/Agn
6+8YGku5s6vp/rTPrnrSePXom1fdektwiRfUJ9+j+RbTC75Jr8gGUyMi1zWg6oJT/DPe0n7C4yj+
jNuQYp2yNN5uWx2trEhM9BJG+Tenn0w7IZ1xocnziye+WkKLYrXhaVXwylgTT+eOSsOUsrVpJcjz
lCI5oVFKdXtTOb6F5oNUjRjNKWIBWDKkyYJL3E2a7liNtB6Vf9MDWaLILDuKv+GMgcU37NhUouna
Qu+1X8c2eW6ifVxHo1yS+khhZC2Tb9L+kSzdK0fEk1N2+3FMsuLkErWJXa6FsO+UNtCpGxhTBeKV
QrXXkhpara8RCFO4TnoGVtYHk67M1RfHJPJ86wfxUBU90/l36XFz8RExlkuFoIGRKxMnsgEAHqmW
cjJyqDBSe3M8jniPjTeF69mz8372UZmzaz30l+jrgTJrE1fxDSrOG3jnQLLG+tF6RXS3ZzqORHkq
8ceTUxveYCWhKJsPqbabwZdRKGYi82/oqzYzmXcHYq/62FxD6d+0D/CMGu+a2V1PviOD/szpaLUn
J5qjfIBE+nqcXzrU3OCx+ExHG0gLqc9vDJ/spRM4Ih4NUt7T18/SO5XaxnXYMmouGiCnMwLhlTta
TVaZNxl38Ot6TJWqTXQK0Qkhhz24PJQaAngtEzlLqLGL3SpPxPpnrSSMjpb4hFct2/ZKuCnoWwYO
jacO6Vqif/yd6MyzyjAzG8lia8QcryGR+lAiho2YYeRoVCqXiZX7ISPwmRuGN6pCbiiSZmbqxITB
hL5MHgDBs09WD6lQbbz148iNXdj5SA7GKhTF/IKcAb80Kj8lnUAm7mG8Uw2x4gB3OLhGwIt9X842
GrgJv51/04lLA8H/97NG5ciWnFoiv0sUULLmUW/1nbWagZj7jOlQEhcym/bWh43/C0C6aXJMVv8F
OMl9gLLTtHy8PHfRXZb+kPNUvyGUSHM3O6Z/Ei/blTTLaLzz8dEg+8slBTJYevPWS4GMHlfZct8X
AASr7OH6AAfWuJRmSaEeLcuAVeCxKrKSB93tfWZCR8g56W6C5hVZ/vGL7O9B1BF29vGC0LWfuz+7
WgkYuYVfftDISKgHF9WRg1s6JaVA4ktLKSUFZuRRuyIKMMCd3FtuKLuWdQ2+MPBDvxdvQSBgqZjN
DefQx5abpF/pLq4whpwL/mbZ8cmxu4V7pjzGfbK3D91z9cvaNBZlyvSKI9UyjSWr59Eky8+D2iWM
pKiZZmhM2wv+S+rj8CDlOXY7SkytL+egOcXkXSWWfoaWfQo0xJ+owP5TL8QE4aNI5e8fss2O8pf0
enP3CkTUpoK2JZNq+DLTR0G/s7p81rPts+1reAlivc++2gpT7Et8uLppxFI6UVCBVIL0RxM3gsFm
Z7x4I+0ZICL4c/Z0MfLbEMme8cP30/cisHb97hZkxldRuF5FHdeLMdTpS8Tj+gXozYV5On7dD/cZ
nDIKlRdwD90esVpKXloKvF+NdXOsZ/9voYqXBmMEsa+PuDUNae+4NzcV9BiKXySG1ECV9W/EDwoj
ACrv9iAg8nFvZymBCgoEnGQsJ+DhgMAAudWeofXm6SawiUBvsebN/u7ZlxdqqOEFHBwJC3IIIe4F
owBqt7QP0s/fm38GHVNBgYMxZJfAn3DW9hMX+Rb0403MH+OUAvWQyhUV9QsQxA0TOwRRmwu7qHHI
fnQeoZe/ntYH9QVIEvfrtffd8f6/Q9BICxe8Ww907Q2oEQUYQ6ZeHbzCdo4vgAOulz6/PmhEz9mO
CFrEpSOOR/jSnoG+M+YLQPQSs+kYJqPw988w4RcA5c518xP/C0AYit2+uNm0ufFsu+oXs+Pnlnv3
J8aV93NwYPF/tccjQeDrrgTBH4bm1r1e0BUoH4XIKUlQDvfNgIi43rcOJlTe/LGHkAjUQNVgvAkG
Q7z6d9DO/gW4u70Y47/PLxz2BWh6gMDwbY27WJ3dvnlyBMqPOL05d36UDLYYct4RpeqG2vbor475
7nTRH2ufOaHnzqba2+8d9rx9bJERBfiTEUMeS/gExkH2CRgG+rx3b368e35D4J/DK/Dp8u+j2Hzr
vLrdBD1f8/yA7Re+83heN/ujKlpAlM+OCvF9A3moM/QP8SjnyO8IIlwYpD88NkQ8Dy+OM8jh3DF+
fjUhCxBQjeMEc4fo2EXgyfhRhmuAwt74IE/AxSXq7sXeJMaf7G0059SW9brfXP6KhwwiyJfn+izI
nTu8HNqxpEuCgghxHy6jYx98oE8DXv4i47FWw/Vb9lfUD8Vc6F77zy6B2eN+pkq3UN7E9nzLUaXl
UhTflYfFxivvsUeBHUqG9emeHb/HPWtBllSYOBUxkosj56Tfz/8CtuVulkLtTLqRT3bY5vJKREWV
+17C6M37BchfyR7KZBQTNZHv1a8KF/8CPP0zLbCtAjA37BVoRSwAS+Xuz+PB4dd8QdCYqoSR740M
uP4QpEhtXKh87iQcOeMbwADtXVBQ0PvjU/sLkHZ12Ir6d51sbLMRorjnC6DdcHa8+tjVYd8Kk76l
X/kwJ/IFsEjr0X7nrJmz8Di4NdWBO7gb+3O7xsoYyonJxJHSXxe715ryBWBgGAyqhBWZKofeUSDs
PP4k8OG0Z6rPFnaimQshpDfQOPzEC7x+vi5fWuhe9Uk5ujuCBuv9Alz/p23AxuCzR+px35lpi5Xv
6iLwkstXtaL8C7CNwfuxc9U769vN/hYYRFNWEEotAZvMAnVA8Qfc4ClcxGcK7AY5FGe/F5P9SMbz
6iPv/Quw93QxGsiLXhQXYCBCFjPMiO2G/Idw1t92JGvybtocvNX9bown2wHTEAyF/0/qMsop1LNT
mAvK5t7dLmiE3rj0wYv47haFcB+id7AUe7J9CQWMSQrXi4iP+wuQ8m54wa8/+pmljOP27DzGk9WJ
XrvodpxRLjMK6RHUB7nmE0v8/m95+rzb9sWJkJUxuGPT/fl27bFfPnoZzG1f3E6OD69fXjxuVt05
LlOvkW//1A2o4SVwIrkdJxdW593svRxVLHKGsn+EOVd3aKf1ihKi2/GPeQ9BgJbc/86oigpuUsDe
I8n2QV8hCxA/2x6P8G9+gt8EyxfdfQEEbj9xbRfDhOsUeDN8sY7VAkdDjzMekRAbSi/gp3jO8frb
Pn73gHrHBAj4fhhQWkEzYoiPQQoWCDDulr1D2z6Lbfr16bGcQ2t4EUECkb8AlKNPLZuTr5uR+UI/
EvlwZbmSWu8qhUCDd9POEPEYLRAkpNcQST6bb6F+vbPbd6BIfIfdelUUgLbj2uFfQtSzw6uz65fr
dDHgZlIw/dsL9PrzzdzLz8cvgL/jWv4774PTJb/PQV/1Du8t0rH2jPwOw3v/p7c78zBN1xGTlG5P
fRCg05sDP/Dq2fUWpD8jAPgUOB4hx+IOC3nv9vxQeLnxJgWp+2/POq64NlyrIB5QENa5fYqMsJRv
PG4+7E5+5uwR+u4N2C1J8ACgR32GoHcHVNQ45Ov8cnZXOw9HDQlxuqAuvWIae+b+ch3cUrSpMQ0m
i45BnwOPxY2/Z9r/nFx0fArN3eG57qqBDL6APc/8E9vEf31L/29v9U6W3VSKT/HPf+r85Ap0BPf/
fv709qmjGjvkYS/PTz8myJWjfTeWEQesi+XEV6TYdAJgi9vXcX/sAt+pbr59AXZzbxhwlrEImf2/
12z/kweNr5+cauqNr8VIme89AoAXh5nlTrII0zQ7TPta94u2H+K/j+qgNwyRr0GlsV5rcBFpgO1Y
qmRiMPa9RcPDXcMXG4jFaE5slded693SDYgPF5DFTT2KScDB62nI0VvLydV+JI0OMUpZm6WKZJvF
t/D/pfIiSVVI4NEp/x+Cbn59gm6Rzy0q6lVG8ODzKUcCf0UwVEJ/gB0Jz3tXLxJKdn/gJrGU0O4W
ofn6zacOFfXoXw+fnJyrNMBH72jt+mJEMiUZ2I6bp4/tJlP5ceJYRkGVKvsRk0ju6ZvQhSvYo+eb
0PUa51VXeV2uyUvkUn+bHcQdYitSLmGjz/MK2Z/BdS9ypDHx1NI+jre2CbiYP7jQC6HNH376sXpc
sCHx6TtexdQ3uQcpOiTOd07YMOSvmzGbfu7ihsixCshuu6HNSHqLDru274N+b95d3VvE35LWUY/u
/vo9Dx5/Aex475CNn+w/cX0yHU1EpIj/pAugzzJIw/8PmHoJw+CPBQbITSJb+Px47heDmY0X8q0c
xsdvhN3HDwL7m7Yf7+RHZ+N1tv8y4qAfPeNTou2GU6pfHT/uO/8Vwy2ongyoy1pylJr4ZJ6d4l83
1HrJR9faTejTIu0X2nu9GfsLaBKahslgxi95BwV6DNnnv0RxhrZ9EJm199t8//wC5OLJp64fURFO
zpbm3hPabSn0dmJaLPtzgc0iIXvRXgV25JG2xcbZAUgfodNC1/i9PRQ3QgiUiqAIf0a0wby8A0Q9
X2yfrzNLGSzr7HtTO21bN9/5ZxjhCtKcf4tk/vvR/ZD/ujdgFR3Jo/e/C9oj3dqMEtndv1ryxfGp
eEeRPmKLvziclppYJ2NpSnao7m9LZjrjVWIeW7W0ZzSt43B9mFg1sLWWSXaZ/fdYnKqTSeRNEPE5
Rkwk0U7xDgTtwb5dSu32BrHXO3h5+wWgh0pr+x4NpwUbDya13Rv2ap8Fy/hojT3yMV2KPJ3bslmc
8kRLbtK2XmqHhQvRKCknr3WQo0l5pMtmuicxqaEnKSvB18DJTTCP4Uf/OWCEdBiL9gAS2u0UOTfC
/mdq9/poGjbp26MIxuihUDiaLyFcCd1wkgmwOQ5lgs97avrfX11BlByLHtD/GAR6fmt99mrLLls/
37YtV8plmA2FxhBEXc9GGJTSMsMdszTvQnzdVvOtfB0u8Kz5mBAMuHVdp6xzkkKJ7VIRAz3Dlj3Z
g5l+pBiZlV4PvpGjIWMrts0WzPBTw4ZeGO2ZShoHGaAljNeFNKIntmmRGq/RaDw2/uQhe4kZLxQL
X0N3RIbzv6qKubZtf5Gebnm7+Admff4uF/UIChJwpcwLxMDty7P3Z1OOYBI8GAsd0TD8xLD2Yt8L
tWoCbAuuj9DgsDBZ2eOMBnVRA2c91SDTBIl7J21gOviC4xjV5D8F5XkqLGVvYSe4hRGdBIvCEB9G
oENaZkVIOw8KYa62vn78K7xuzRTzC6eW2LhKvfpGSYF9jNu1QY/poiAjOwNOb2rqqiJFZWJw+CjM
OHVE+1sBHATYaJmfgb1fn/h724A5hfzpfzoVTb4+O45366GjWzAwEf5CjLudDHHy/CP3j9MelM7S
ajLlzi3CS6eNi/A/VQtGI+GCJdltFGvUYhCSw4EfWbjfIqGsyV6RyGXtOosa32ybovem2X7SwRG3
64OdoEyjYpAsF2eq17b85bU2HNRYZdCN5mPxGkl7HViQLSxhK+a1hOrngEBkMa4GtR9PiUnhubad
iFH9jacAV++1E+ggDLuJJpddvNh8sRFwA93tP/mm9GxHDnbRWb0s9HQ2JkZ7sa3giFHQpnTxVFsq
EsSvl0VRc5Vgd2mrhi1mHeFll+fiD03LZCjOOLvBEgFxIn3snRTj4hrbGtkiZR+UhvYuJKivVf+C
mm7EE/Br0j+L71+vhJe36Wlh0+d6+g7P+F31+lQt9sQTOzbqa7hHmZsZxbuD7vlgodgcsYjxIQy9
jcjySmwTGYNNyxp+t1K3uz179aaObrfi05woxxMzvunp7HwBQidDC+63b5kkdQQdKlGwxWTlf5TP
2FlT6gyqtzkoJT677vVyHztidptaWmOepKpzEv4YtKLYmFW45zUHE6s2VaGKKXevGNXPyUhvmxyc
GNklK4oTFhJTwrJZA41ETkeER91v0jtdKcTgOdfUhxEZAXnATVEYr67Xut3+4aI3d1KrMFgkX3by
6uTDu7e6bS/rx6iNM0Yx/uBpyC5D6/Pbs9KHX5f+Pky8UVLcAiykV81VpWlp9FwycRqEVPbVEz8B
l9jAeISgsn+Yhz8MjP97H7TPvzn1zpbC+o8Skvp/QLeJ+l7mPr1c53aXt1rWe7Q+ez+++/ohZbkf
YwwJ9l5CPF8sXr683GRHfO8/cnPecs1O9/txjdv9LSm5L9RCmUpVwq/MKA1B2c9FikTZZ/PqDtSz
LjdqZ9cJ7HRGen/70O31OjweqYtB6jlgxMhLFb6FZnhYLNkFDdQsHr77nQx9KylK0MxaKehorfXZ
sjwenHu+bPh0FXDf8fo3TuTWWCinMjtYmm+QPaUt+H6dqzW7DP43ZVdW7+IfhaB3767/rE/Uu6r7
93R56KrWyyN5GerFHHF62y6yiRNWXf41dvWuR/45m1yOf8kGcXDSp3Wv43Dmj7G/fzpDGYBPlG8f
7EjAwH5UXID4NQlBf4uQwe1ut1b+eKTbHOrsPHWMb5evt9Zt0rdLjVUMrixd5RJs5r29ihgMI5dw
5Asg7bbxwNQKING+RWHf8hVDynx73NziBSYMEYs0UaWPXkKrdLz7bDoENnP09d6GwnM7PWZCvb14
tWz69A6e79Maaqpz9Qj0CUxG0dBAvebFd3yOhV5vPr/1eBtf0fzD2LPfahDoZXTlkf1jJnc1d/ty
M5jRezTlHxbYf6bJCYMXU9k53nJCC51dEvrJ/wz1ZXL+7jub5OHL47IL6k3dPn5v65+xj/0nXEFZ
R89fgH9koCf9H06x/iulKOPc2N9DqXkwWymOAEfI4W6bDoTuofJpN9GKa1yQiseA1/dDwHOs7qtX
96eejrHmePiB0gNyaKpub+1eK/ZvRf63pH+KhHBwr++C539y4j7KCJo5O30w76rNu3vvk0DHAU7o
ltn4EQb5do/Bnf09q/hw06flrbc2VY6lrD4wTUop1S4b4gisryVU6J+XZ9bmpO55g3rv8UJ68+nm
9nk3khQCv7MLl17iCho+RPZLuz8V4GcsyO/w6lQEcOz2PnzqeFxErzvZ6LZujgnU0ueChvFOPf7l
5dSGoRj7cxXwjxCwJ++WZ58tapkRu5ZjyBlc+54/xJOXhAKVdy8v96e/2YIFSFKvP3trm9yVCCUf
erf+AWB2u3V7EMtoEyLtjXItwHDObU16sfSfCODjPMZeePJzERiMcej87+18TeB/cP2+1v8fUEsB
Ah4DFAAAAAgAeH9RQO+fL/7gyQAAPsoAAAwAGAAAAAAAAAAAALSBAAAAAGFzZGYwNTgzLmpwZ1VU
BQADxL8+T3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAHh/UUDWMZYEwuUAAB7mAAAMABgAAAAA
AAAAAAC0gSbKAABhc2RmMDU4Ny5qcGdVVAUAA8S/Pk91eAsAAQToAwAABOgDAABQSwECHgMUAAAA
CAB4f1FARlMDoQVoAAB3aQAADAAYAAAAAAAAAAAAtIEusAEAYXNkZjA1OTQuanBnVVQFAAPEvz5P
dXgLAAEE6AMAAAToAwAAUEsBAh4DFAAAAAgAeH9RQF3rx5K0KwEAxTEBAAwAGAAAAAAAAAAAALSB
eRgCAGFzZGYwNTk1LmpwZ1VUBQADxL8+T3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAG+AUUBe
h5/oINsCAOfbAgAiABgAAAAAAAAAAACkgXNEAwBDMzYwXzIwMTItMDItMTctMTUtMzAtNTkuU2hh
cmUuanBnVVQFAAOhwD5PdXgLAAEE6AMAAAToAwAAUEsFBgAAAAAFAAUAsAEAAO8fBgAAAA==
--f46d0444040adaef0c04b92faae6
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--f46d0444040adaef0c04b92faae6--


From xen-devel-bounces@lists.xensource.com Sat Feb 18 05:55:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 05:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RydG4-0001FZ-LM; Sat, 18 Feb 2012 05:54:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RydG3-0001FU-C1
	for xen-devel@lists.xensource.com; Sat, 18 Feb 2012 05:54:55 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329544488!12383933!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27262 invoked from network); 18 Feb 2012 05:54:49 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2012 05:54:49 -0000
Received: by wgbdr13 with SMTP id dr13so2960421wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 21:54:48 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr3744774wia.3.1329544488675 (num_hops =
	1); Fri, 17 Feb 2012 21:54:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr3238370wia.3.1329544488631; Fri, 17
	Feb 2012 21:54:48 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Fri, 17 Feb 2012 21:54:48 -0800 (PST)
Date: Fri, 17 Feb 2012 21:54:48 -0800
Message-ID: <CAMrHX2WFfn5f-nS75aP1mx9UGQkUQjet=f3YjQhrVMdiWft9Sg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQkjdCf5r6ZwANBqoejEN5ekFhMu74WvZxvehaX8kZbYEZgPTeCScfl/IJnXCBuEI2xv/qY8
Subject: [Xen-devel] Mounting filesystems with blktap2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For those wanting to know how to mount filesystems through blktap2
here is how you do it, as I couldn't find it fully documented.
The instructions on the blktap2 readme file are rather out of date.


You can mount them under Dom0 like so.

e.g. to mount a vhd file,
sudo xm block-attach 0 tap2:vhd:/home/xen/xenwin7-persist.vhd  xvdb w 0

Now the device should appear under /dev

ls /dev/xvdb*
/dev/xvdb  /dev/xvdb1  /dev/xvdb2

sudo mount /dev/xvdb2 /mnt

Mounts the first partition on xvdb to the path /mnt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 05:55:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 05:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RydG4-0001FZ-LM; Sat, 18 Feb 2012 05:54:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RydG3-0001FU-C1
	for xen-devel@lists.xensource.com; Sat, 18 Feb 2012 05:54:55 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329544488!12383933!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27262 invoked from network); 18 Feb 2012 05:54:49 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2012 05:54:49 -0000
Received: by wgbdr13 with SMTP id dr13so2960421wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 17 Feb 2012 21:54:48 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr3744774wia.3.1329544488675 (num_hops =
	1); Fri, 17 Feb 2012 21:54:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr3238370wia.3.1329544488631; Fri, 17
	Feb 2012 21:54:48 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Fri, 17 Feb 2012 21:54:48 -0800 (PST)
Date: Fri, 17 Feb 2012 21:54:48 -0800
Message-ID: <CAMrHX2WFfn5f-nS75aP1mx9UGQkUQjet=f3YjQhrVMdiWft9Sg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQkjdCf5r6ZwANBqoejEN5ekFhMu74WvZxvehaX8kZbYEZgPTeCScfl/IJnXCBuEI2xv/qY8
Subject: [Xen-devel] Mounting filesystems with blktap2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For those wanting to know how to mount filesystems through blktap2
here is how you do it, as I couldn't find it fully documented.
The instructions on the blktap2 readme file are rather out of date.


You can mount them under Dom0 like so.

e.g. to mount a vhd file,
sudo xm block-attach 0 tap2:vhd:/home/xen/xenwin7-persist.vhd  xvdb w 0

Now the device should appear under /dev

ls /dev/xvdb*
/dev/xvdb  /dev/xvdb1  /dev/xvdb2

sudo mount /dev/xvdb2 /mnt

Mounts the first partition on xvdb to the path /mnt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 07:13:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 07: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.xensource.com>)
	id 1RyeSt-0001sl-TL; Sat, 18 Feb 2012 07:12:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists.xen@nuclearfallout.net>) id 1RyeSr-0001sg-9M
	for xen-devel@lists.xensource.com; Sat, 18 Feb 2012 07:12:13 +0000
Received: from [85.158.139.83:12163] by server-9.bemta-5.messagelabs.com id
	7D/6A-30171-B4F4F3F4; Sat, 18 Feb 2012 07:12:11 +0000
X-Env-Sender: lists.xen@nuclearfallout.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329549130!15038983!1
X-Originating-IP: [208.146.45.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17493 invoked from network); 18 Feb 2012 07:12:10 -0000
Received: from mail.nuclearfallout.net (HELO mail.nuclearfallout.net)
	(208.146.45.251) by server-13.tower-182.messagelabs.com with SMTP;
	18 Feb 2012 07:12:10 -0000
Message-ID: <4F3F4F43.5050107@nuclearfallout.net>
Date: Fri, 17 Feb 2012 23:12:03 -0800
From: John Weekes <lists.xen@nuclearfallout.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <CAMrHX2WFfn5f-nS75aP1mx9UGQkUQjet=f3YjQhrVMdiWft9Sg@mail.gmail.com>
In-Reply-To: <CAMrHX2WFfn5f-nS75aP1mx9UGQkUQjet=f3YjQhrVMdiWft9Sg@mail.gmail.com>
Subject: Re: [Xen-devel] Mounting filesystems with blktap2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2/17/2012 9:54 PM, Matthew Hook wrote:
> For those wanting to know how to mount filesystems through blktap2
> here is how you do it, as I couldn't find it fully documented.
> The instructions on the blktap2 readme file are rather out of date.
>
>
> You can mount them under Dom0 like so.
>
> e.g. to mount a vhd file,
> sudo xm block-attach 0 tap2:vhd:/home/xen/xenwin7-persist.vhd  xvdb w 0
>
> Now the device should appear under /dev
>
> ls /dev/xvdb*
> /dev/xvdb  /dev/xvdb1  /dev/xvdb2
>
> sudo mount /dev/xvdb2 /mnt
>
> Mounts the first partition on xvdb to the path /mnt

You can also mount with tap-ctl and kpartx, but it's a little more 
complicated:

# tap-ctl allocate
/dev/xen/blktap-2/tapdev7
# tap-ctl spawn
tapdisk spawned with pid 28746
# tap-ctl attach -p 28746 -m 7
# tap-ctl open -p 28746 -m 7 -a aio:/somewhere/some_example_image.img
# kpartx -a /dev/xen/blktap-2/tapdev7
# ls /dev/mapper/tapdev7*
/dev/mapper/tapdev7p1  /dev/mapper/tapdev7p2
# mount /dev/mapper/tapdev7p1 /mnt
# umount /mnt
# kpartx -d /dev/mapper/tapdev7p1
# tap-ctl close -p 28746 -m 7
# tap-ctl detach -p 28746 -m 7
# tap-ctl free -m 7

(Is this a better way? I don't actually know.)

Note that when using the tap-ctl method in scripts, I've found that it's 
important to intersperse "sync" commands and slight timeouts before 
umount/kpart -d/tap-ctl close, as otherwise you will sometimes end up 
with the tapdisk2 process hung in an uninterruptible disk sleep and 
unable to be queried (causing havoc when it comes to trying to trying to 
view the process list). At least, under 4.1.

-John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 07:13:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 07: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.xensource.com>)
	id 1RyeSt-0001sl-TL; Sat, 18 Feb 2012 07:12:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists.xen@nuclearfallout.net>) id 1RyeSr-0001sg-9M
	for xen-devel@lists.xensource.com; Sat, 18 Feb 2012 07:12:13 +0000
Received: from [85.158.139.83:12163] by server-9.bemta-5.messagelabs.com id
	7D/6A-30171-B4F4F3F4; Sat, 18 Feb 2012 07:12:11 +0000
X-Env-Sender: lists.xen@nuclearfallout.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329549130!15038983!1
X-Originating-IP: [208.146.45.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No 
	Received headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17493 invoked from network); 18 Feb 2012 07:12:10 -0000
Received: from mail.nuclearfallout.net (HELO mail.nuclearfallout.net)
	(208.146.45.251) by server-13.tower-182.messagelabs.com with SMTP;
	18 Feb 2012 07:12:10 -0000
Message-ID: <4F3F4F43.5050107@nuclearfallout.net>
Date: Fri, 17 Feb 2012 23:12:03 -0800
From: John Weekes <lists.xen@nuclearfallout.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <CAMrHX2WFfn5f-nS75aP1mx9UGQkUQjet=f3YjQhrVMdiWft9Sg@mail.gmail.com>
In-Reply-To: <CAMrHX2WFfn5f-nS75aP1mx9UGQkUQjet=f3YjQhrVMdiWft9Sg@mail.gmail.com>
Subject: Re: [Xen-devel] Mounting filesystems with blktap2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2/17/2012 9:54 PM, Matthew Hook wrote:
> For those wanting to know how to mount filesystems through blktap2
> here is how you do it, as I couldn't find it fully documented.
> The instructions on the blktap2 readme file are rather out of date.
>
>
> You can mount them under Dom0 like so.
>
> e.g. to mount a vhd file,
> sudo xm block-attach 0 tap2:vhd:/home/xen/xenwin7-persist.vhd  xvdb w 0
>
> Now the device should appear under /dev
>
> ls /dev/xvdb*
> /dev/xvdb  /dev/xvdb1  /dev/xvdb2
>
> sudo mount /dev/xvdb2 /mnt
>
> Mounts the first partition on xvdb to the path /mnt

You can also mount with tap-ctl and kpartx, but it's a little more 
complicated:

# tap-ctl allocate
/dev/xen/blktap-2/tapdev7
# tap-ctl spawn
tapdisk spawned with pid 28746
# tap-ctl attach -p 28746 -m 7
# tap-ctl open -p 28746 -m 7 -a aio:/somewhere/some_example_image.img
# kpartx -a /dev/xen/blktap-2/tapdev7
# ls /dev/mapper/tapdev7*
/dev/mapper/tapdev7p1  /dev/mapper/tapdev7p2
# mount /dev/mapper/tapdev7p1 /mnt
# umount /mnt
# kpartx -d /dev/mapper/tapdev7p1
# tap-ctl close -p 28746 -m 7
# tap-ctl detach -p 28746 -m 7
# tap-ctl free -m 7

(Is this a better way? I don't actually know.)

Note that when using the tap-ctl method in scripts, I've found that it's 
important to intersperse "sync" commands and slight timeouts before 
umount/kpart -d/tap-ctl close, as otherwise you will sometimes end up 
with the tapdisk2 process hung in an uninterruptible disk sleep and 
unable to be queried (causing havoc when it comes to trying to trying to 
view the process list). At least, under 4.1.

-John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 08:25:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 08: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.xensource.com>)
	id 1Ryfam-0002qw-VT; Sat, 18 Feb 2012 08:24:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blauwirbel@gmail.com>) id 1Ryfal-0002qr-Sr
	for xen-devel@lists.xen.org; Sat, 18 Feb 2012 08:24:28 +0000
X-Env-Sender: blauwirbel@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329553412!53270816!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8092 invoked from network); 18 Feb 2012 08:23:33 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2012 08:23:33 -0000
Received: by iahk25 with SMTP id k25so3953903iah.32
	for <xen-devel@lists.xen.org>; Sat, 18 Feb 2012 00:24:25 -0800 (PST)
Received-SPF: pass (google.com: domain of blauwirbel@gmail.com designates
	10.42.148.69 as permitted sender) client-ip=10.42.148.69; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of blauwirbel@gmail.com
	designates 10.42.148.69 as permitted sender)
	smtp.mail=blauwirbel@gmail.com;
	dkim=pass header.i=blauwirbel@gmail.com
Received: from mr.google.com ([10.42.148.69])
	by 10.42.148.69 with SMTP id q5mr12860745icv.24.1329553465179 (num_hops
	= 1); Sat, 18 Feb 2012 00:24:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=Q2lcIklG4P+nypQha3Y49039oQ1HqHeMha+/uTK950o=;
	b=xCyto+gO79frb+DDPTK5eHVhrHIniYGZ1Uug1S3o5gXgHuFMwblZY4QMirifc9mL1y
	k5oaYqJAzmhbD6f5Ar7b97SIhQdY18ac6Q9hztLFJ67g3yY/WMT9ut9yjfL2EtnzDc+4
	L7jWSa6w2gdhDSad4Q1CWCjBA8K1hTlw4n8KI=
Received: by 10.42.148.69 with SMTP id q5mr10144971icv.24.1329553465122; Sat,
	18 Feb 2012 00:24:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.2.10 with HTTP; Sat, 18 Feb 2012 00:24:05 -0800 (PST)
In-Reply-To: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
References: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Sat, 18 Feb 2012 08:24:05 +0000
Message-ID: <CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] build: add needed missing
	libraries libm and librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxNzowNiwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVA
ZW50ZWwudXBjLmVkdT4gd3JvdGU6Cj4gbGlibSBpcyB1c2VkIGluIGN1dGlscy5jLCBidXQgdGhl
IGxpYnJhcnkgd2FzIG5vdCBzcGVjaWZpZWQKPiB3aGVuIGxpbmtpbmcgc29tZSBiaW5hcmllcywg
dGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPgo+IGN1dGlscy5vOiBJbiBmdW5jdGlvbiBg
c3RydG9zel9zdWZmaXhfdW5pdCc6Cj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11
LXhlbi1kaXIvY3V0aWxzLmM6MzU0OiB1bmRlZmluZWQKPiByZWZlcmVuY2UgdG8gYF9faXNuYW4n
Cj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11LXhlbi1kaXIvY3V0aWxzLmM6MzU3
OiB1bmRlZmluZWQKPiByZWZlcmVuY2UgdG8gYG1vZGYnCj4gY29sbGVjdDI6IGxkIHJldHVybmVk
IDEgZXhpdCBzdGF0dXMKPgo+IEFjY29yZGluZyB0byBtb2RmIG1hbiBwYWdlIFswXSwgLWxtIHNo
b3VsZCBiZSB1c2VkIHdoZW4gbGlua2luZy4KPgo+IGxpYnJ0IGlzIHVzZWQgaW4gcWVtdS10aW1l
LmMsIGJ1dCBhZ2FpbiB0aGUgbGlicmFyeSB3YXMgbm90IHNwZWNpZmllZAo+IGF0IGxpbmsgdGlt
ZSwgdGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPgo+IC9ob21lL3JveWdlci94ZW4tY2xl
YW4vdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXIuYzo1OTc6IHVuZGVmaW5lZAo+IHJlZmVy
ZW5jZSB0byBgdGltZXJfZ2V0dGltZScKPiAvaG9tZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3Fl
bXUteGVuLWRpci9xZW11LXRpbWVyLmM6NjEwOiB1bmRlZmluZWQKPiByZWZlcmVuY2UgdG8gYHRp
bWVyX3NldHRpbWUnCj4gLi4vcWVtdS10aW1lci5vOiBJbiBmdW5jdGlvbiBgZHludGlja3Nfc3Rh
cnRfdGltZXInOgo+IC9ob21lL3JveWdlci94ZW4tY2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL3Fl
bXUtdGltZXIuYzo1NjU6IHVuZGVmaW5lZAo+IHJlZmVyZW5jZSB0byBgdGltZXJfY3JlYXRlJwo+
IC4uL3FlbXUtdGltZXIubzogSW4gZnVuY3Rpb24gYGR5bnRpY2tzX3N0b3BfdGltZXInOgo+IC9o
b21lL3JveWdlci94ZW4tY2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXIuYzo1ODM6
IHVuZGVmaW5lZAo+IHJlZmVyZW5jZSB0byBgdGltZXJfZGVsZXRlJwo+IGNvbGxlY3QyOiBsZCBy
ZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4KPiBBY2NvcmRpbmcgdG8gdGltZXJfZ2V0dHRpbWUgbWFu
IHBhZ2UgWzFdLCAtbHJ0IHNob3VsZCBiZSB1c2VkIHdoZW4KPiBsaW5raW5nLgo+Cj4gWzBdIGh0
dHA6Ly9saW51eC5kaWUubmV0L21hbi8zL21vZGYKPiBbMV0gaHR0cDovL2xpbnV4LmRpZS5uZXQv
bWFuLzIvdGltZXJfZ2V0dGltZQoKVGhpcyBpcyBMaW51eCBtYW4gcGFnZSwgaXMgdGhpcyBjb3Jy
ZWN0IGZvciBhbGwgT1Mgd2Ugc3VwcG9ydD8KCldlIGFscmVhZHkgaGF2ZSBhIHRlc3QgZm9yIC1s
cnQgaW4gY29uZmlndXJlLCBidXQgaXQgbG9va3MgbGlrZSBpdApkb2VzIG5vdCBkZXRlY3QgeW91
ciBjYXNlIGNvcnJlY3RseS4gWW91IHNob3VsZCBmaXggdGhhdCBpbnN0ZWFkLgoKPiBTaWduZWQt
b2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+IC0tLQo+
IMKgTWFrZWZpbGUgwqAgwqAgwqAgwqB8IMKgIMKgNCArKy0tCj4gwqBNYWtlZmlsZS50YXJnZXQg
fCDCoCDCoDIgKysKPiDCoDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyIGRlbGV0
aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL01ha2VmaWxlIGIvTWFrZWZpbGUKPiBpbmRleCAzMDFj
NzVlLi5lMmMzY2Q0IDEwMDY0NAo+IC0tLSBhL01ha2VmaWxlCj4gKysrIGIvTWFrZWZpbGUKPiBA
QCAtMzQsNyArMzQsNyBAQCBjb25maWd1cmU6IDsKPgo+IMKgJChjYWxsIHNldC12cGF0aCwgJChT
UkNfUEFUSCk6JChTUkNfUEFUSCkvaHcpCj4KPiAtTElCUys9LWx6ICQoTElCU19UT09MUykKPiAr
TElCUys9LWx6IC1sbSAtbHJ0ICQoTElCU19UT09MUykKPgo+IMKgaWZkZWYgQlVJTERfRE9DUwo+
IMKgRE9DUz1xZW11LWRvYy5odG1sIHFlbXUtdGVjaC5odG1sIHFlbXUuMSBxZW11LWltZy4xIHFl
bXUtbmJkLjggUU1QL3FtcC1jb21tYW5kcy50eHQKPiBAQCAtMTcwLDcgKzE3MCw3IEBAIHRlc3Qt
Y29yb3V0aW5lOiB0ZXN0LWNvcm91dGluZS5vIHFlbXUtdGltZXItY29tbW9uLm8gYXN5bmMubyAk
KGNvcm91dGluZS1vYmoteSkKPiDCoCQocWFwaS1vYmoteSk6ICQoR0VORVJBVEVEX0hFQURFUlMp
Cj4gwqBxYXBpLWRpciA6PSAkKEJVSUxEX0RJUikvcWFwaS1nZW5lcmF0ZWQKPiDCoHRlc3Qtdmlz
aXRvci5vIHRlc3QtcW1wLWNvbW1hbmRzLm8gcWVtdS1nYSQoRVhFU1VGKTogUUVNVV9DRkxBR1Mg
Kz0gLUkgJChxYXBpLWRpcikKPiAtcWVtdS1nYSQoRVhFU1VGKTogTElCUyA9ICQoTElCU19RR0Ep
Cj4gK3FlbXUtZ2EkKEVYRVNVRik6IExJQlMgPSAkKExJQlNfUUdBKSAtbG0KPgo+IMKgJChxYXBp
LWRpcikvdGVzdC1xYXBpLXR5cGVzLmMgJChxYXBpLWRpcikvdGVzdC1xYXBpLXR5cGVzLmggOlwK
PiDCoCQoU1JDX1BBVEgpL3FhcGktc2NoZW1hLXRlc3QuanNvbiAkKFNSQ19QQVRIKS9zY3JpcHRz
L3FhcGktdHlwZXMucHkKPiBkaWZmIC0tZ2l0IGEvTWFrZWZpbGUudGFyZ2V0IGIvTWFrZWZpbGUu
dGFyZ2V0Cj4gaW5kZXggYTExMTUyMS4uOTVkNmJjMCAxMDA2NDQKPiAtLS0gYS9NYWtlZmlsZS50
YXJnZXQKPiArKysgYi9NYWtlZmlsZS50YXJnZXQKPiBAQCAtMzMsNiArMzMsOCBAQCBlbmRpZgo+
IMKgUFJPR1M9JChRRU1VX1BST0cpCj4gwqBTVFBGSUxFUz0KPgo+ICtMSUJTKz0tbHJ0Cj4gKwo+
IMKgaWZuZGVmIENPTkZJR19IQUlLVQo+IMKgTElCUys9LWxtCj4gwqBlbmRpZgo+IC0tCj4gMS43
LjkKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Feb 18 08:25:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 08: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.xensource.com>)
	id 1Ryfam-0002qw-VT; Sat, 18 Feb 2012 08:24:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blauwirbel@gmail.com>) id 1Ryfal-0002qr-Sr
	for xen-devel@lists.xen.org; Sat, 18 Feb 2012 08:24:28 +0000
X-Env-Sender: blauwirbel@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329553412!53270816!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8092 invoked from network); 18 Feb 2012 08:23:33 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2012 08:23:33 -0000
Received: by iahk25 with SMTP id k25so3953903iah.32
	for <xen-devel@lists.xen.org>; Sat, 18 Feb 2012 00:24:25 -0800 (PST)
Received-SPF: pass (google.com: domain of blauwirbel@gmail.com designates
	10.42.148.69 as permitted sender) client-ip=10.42.148.69; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of blauwirbel@gmail.com
	designates 10.42.148.69 as permitted sender)
	smtp.mail=blauwirbel@gmail.com;
	dkim=pass header.i=blauwirbel@gmail.com
Received: from mr.google.com ([10.42.148.69])
	by 10.42.148.69 with SMTP id q5mr12860745icv.24.1329553465179 (num_hops
	= 1); Sat, 18 Feb 2012 00:24:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=Q2lcIklG4P+nypQha3Y49039oQ1HqHeMha+/uTK950o=;
	b=xCyto+gO79frb+DDPTK5eHVhrHIniYGZ1Uug1S3o5gXgHuFMwblZY4QMirifc9mL1y
	k5oaYqJAzmhbD6f5Ar7b97SIhQdY18ac6Q9hztLFJ67g3yY/WMT9ut9yjfL2EtnzDc+4
	L7jWSa6w2gdhDSad4Q1CWCjBA8K1hTlw4n8KI=
Received: by 10.42.148.69 with SMTP id q5mr10144971icv.24.1329553465122; Sat,
	18 Feb 2012 00:24:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.2.10 with HTTP; Sat, 18 Feb 2012 00:24:05 -0800 (PST)
In-Reply-To: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
References: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Sat, 18 Feb 2012 08:24:05 +0000
Message-ID: <CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] build: add needed missing
	libraries libm and librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxNzowNiwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVA
ZW50ZWwudXBjLmVkdT4gd3JvdGU6Cj4gbGlibSBpcyB1c2VkIGluIGN1dGlscy5jLCBidXQgdGhl
IGxpYnJhcnkgd2FzIG5vdCBzcGVjaWZpZWQKPiB3aGVuIGxpbmtpbmcgc29tZSBiaW5hcmllcywg
dGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPgo+IGN1dGlscy5vOiBJbiBmdW5jdGlvbiBg
c3RydG9zel9zdWZmaXhfdW5pdCc6Cj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11
LXhlbi1kaXIvY3V0aWxzLmM6MzU0OiB1bmRlZmluZWQKPiByZWZlcmVuY2UgdG8gYF9faXNuYW4n
Cj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11LXhlbi1kaXIvY3V0aWxzLmM6MzU3
OiB1bmRlZmluZWQKPiByZWZlcmVuY2UgdG8gYG1vZGYnCj4gY29sbGVjdDI6IGxkIHJldHVybmVk
IDEgZXhpdCBzdGF0dXMKPgo+IEFjY29yZGluZyB0byBtb2RmIG1hbiBwYWdlIFswXSwgLWxtIHNo
b3VsZCBiZSB1c2VkIHdoZW4gbGlua2luZy4KPgo+IGxpYnJ0IGlzIHVzZWQgaW4gcWVtdS10aW1l
LmMsIGJ1dCBhZ2FpbiB0aGUgbGlicmFyeSB3YXMgbm90IHNwZWNpZmllZAo+IGF0IGxpbmsgdGlt
ZSwgdGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPgo+IC9ob21lL3JveWdlci94ZW4tY2xl
YW4vdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXIuYzo1OTc6IHVuZGVmaW5lZAo+IHJlZmVy
ZW5jZSB0byBgdGltZXJfZ2V0dGltZScKPiAvaG9tZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3Fl
bXUteGVuLWRpci9xZW11LXRpbWVyLmM6NjEwOiB1bmRlZmluZWQKPiByZWZlcmVuY2UgdG8gYHRp
bWVyX3NldHRpbWUnCj4gLi4vcWVtdS10aW1lci5vOiBJbiBmdW5jdGlvbiBgZHludGlja3Nfc3Rh
cnRfdGltZXInOgo+IC9ob21lL3JveWdlci94ZW4tY2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL3Fl
bXUtdGltZXIuYzo1NjU6IHVuZGVmaW5lZAo+IHJlZmVyZW5jZSB0byBgdGltZXJfY3JlYXRlJwo+
IC4uL3FlbXUtdGltZXIubzogSW4gZnVuY3Rpb24gYGR5bnRpY2tzX3N0b3BfdGltZXInOgo+IC9o
b21lL3JveWdlci94ZW4tY2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXIuYzo1ODM6
IHVuZGVmaW5lZAo+IHJlZmVyZW5jZSB0byBgdGltZXJfZGVsZXRlJwo+IGNvbGxlY3QyOiBsZCBy
ZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4KPiBBY2NvcmRpbmcgdG8gdGltZXJfZ2V0dHRpbWUgbWFu
IHBhZ2UgWzFdLCAtbHJ0IHNob3VsZCBiZSB1c2VkIHdoZW4KPiBsaW5raW5nLgo+Cj4gWzBdIGh0
dHA6Ly9saW51eC5kaWUubmV0L21hbi8zL21vZGYKPiBbMV0gaHR0cDovL2xpbnV4LmRpZS5uZXQv
bWFuLzIvdGltZXJfZ2V0dGltZQoKVGhpcyBpcyBMaW51eCBtYW4gcGFnZSwgaXMgdGhpcyBjb3Jy
ZWN0IGZvciBhbGwgT1Mgd2Ugc3VwcG9ydD8KCldlIGFscmVhZHkgaGF2ZSBhIHRlc3QgZm9yIC1s
cnQgaW4gY29uZmlndXJlLCBidXQgaXQgbG9va3MgbGlrZSBpdApkb2VzIG5vdCBkZXRlY3QgeW91
ciBjYXNlIGNvcnJlY3RseS4gWW91IHNob3VsZCBmaXggdGhhdCBpbnN0ZWFkLgoKPiBTaWduZWQt
b2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+IC0tLQo+
IMKgTWFrZWZpbGUgwqAgwqAgwqAgwqB8IMKgIMKgNCArKy0tCj4gwqBNYWtlZmlsZS50YXJnZXQg
fCDCoCDCoDIgKysKPiDCoDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyIGRlbGV0
aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL01ha2VmaWxlIGIvTWFrZWZpbGUKPiBpbmRleCAzMDFj
NzVlLi5lMmMzY2Q0IDEwMDY0NAo+IC0tLSBhL01ha2VmaWxlCj4gKysrIGIvTWFrZWZpbGUKPiBA
QCAtMzQsNyArMzQsNyBAQCBjb25maWd1cmU6IDsKPgo+IMKgJChjYWxsIHNldC12cGF0aCwgJChT
UkNfUEFUSCk6JChTUkNfUEFUSCkvaHcpCj4KPiAtTElCUys9LWx6ICQoTElCU19UT09MUykKPiAr
TElCUys9LWx6IC1sbSAtbHJ0ICQoTElCU19UT09MUykKPgo+IMKgaWZkZWYgQlVJTERfRE9DUwo+
IMKgRE9DUz1xZW11LWRvYy5odG1sIHFlbXUtdGVjaC5odG1sIHFlbXUuMSBxZW11LWltZy4xIHFl
bXUtbmJkLjggUU1QL3FtcC1jb21tYW5kcy50eHQKPiBAQCAtMTcwLDcgKzE3MCw3IEBAIHRlc3Qt
Y29yb3V0aW5lOiB0ZXN0LWNvcm91dGluZS5vIHFlbXUtdGltZXItY29tbW9uLm8gYXN5bmMubyAk
KGNvcm91dGluZS1vYmoteSkKPiDCoCQocWFwaS1vYmoteSk6ICQoR0VORVJBVEVEX0hFQURFUlMp
Cj4gwqBxYXBpLWRpciA6PSAkKEJVSUxEX0RJUikvcWFwaS1nZW5lcmF0ZWQKPiDCoHRlc3Qtdmlz
aXRvci5vIHRlc3QtcW1wLWNvbW1hbmRzLm8gcWVtdS1nYSQoRVhFU1VGKTogUUVNVV9DRkxBR1Mg
Kz0gLUkgJChxYXBpLWRpcikKPiAtcWVtdS1nYSQoRVhFU1VGKTogTElCUyA9ICQoTElCU19RR0Ep
Cj4gK3FlbXUtZ2EkKEVYRVNVRik6IExJQlMgPSAkKExJQlNfUUdBKSAtbG0KPgo+IMKgJChxYXBp
LWRpcikvdGVzdC1xYXBpLXR5cGVzLmMgJChxYXBpLWRpcikvdGVzdC1xYXBpLXR5cGVzLmggOlwK
PiDCoCQoU1JDX1BBVEgpL3FhcGktc2NoZW1hLXRlc3QuanNvbiAkKFNSQ19QQVRIKS9zY3JpcHRz
L3FhcGktdHlwZXMucHkKPiBkaWZmIC0tZ2l0IGEvTWFrZWZpbGUudGFyZ2V0IGIvTWFrZWZpbGUu
dGFyZ2V0Cj4gaW5kZXggYTExMTUyMS4uOTVkNmJjMCAxMDA2NDQKPiAtLS0gYS9NYWtlZmlsZS50
YXJnZXQKPiArKysgYi9NYWtlZmlsZS50YXJnZXQKPiBAQCAtMzMsNiArMzMsOCBAQCBlbmRpZgo+
IMKgUFJPR1M9JChRRU1VX1BST0cpCj4gwqBTVFBGSUxFUz0KPgo+ICtMSUJTKz0tbHJ0Cj4gKwo+
IMKgaWZuZGVmIENPTkZJR19IQUlLVQo+IMKgTElCUys9LWxtCj4gwqBlbmRpZgo+IC0tCj4gMS43
LjkKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Feb 18 13:53:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 13:53:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RykiY-0004Kq-8w; Sat, 18 Feb 2012 13:52:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RykiW-0004Kl-Lg
	for xen-devel@lists.xensource.com; Sat, 18 Feb 2012 13:52:48 +0000
Received: from [85.158.139.83:59971] by server-4.bemta-5.messagelabs.com id
	DA/A9-10788-F2DAF3F4; Sat, 18 Feb 2012 13:52:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329573166!15604196!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 18 Feb 2012 13:52:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Feb 2012 13:52:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RykiS-0000d3-RZ; Sat, 18 Feb 2012 13:52:44 +0000
Date: Sat, 18 Feb 2012 13:52:44 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120218135244.GA1531@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:49 +0000 on 15 Feb (1329324592), Ian Campbell wrote:
> +struct pcpu_info {
> +    unsigned int processor_id;
> +    struct vcpu *current_vcpu;
> +};
> +
> +DECLARE_PER_CPU(struct pcpu_info, pcpu_info);

> +static inline struct pcpu_info *get_pcpu_info(void)
> +{
> +    return &this_cpu(pcpu_info);
> +}
> +

I don't think it's worth declaring a struct and accessors for this; we
should just have current_vcpu as an ordinary per-cpu variable.

Storing the CPU ID in the per-pcpu area only happens to work because
per-cpu areas are a noop right now.  I have a patch that re-enables them
properly but for that we'll need a proper way of getting the CPU id.  In
the meantime I think it would be less confusing just to hard-code it as
zero than to do this. :)

We could use the physical CPU ID register; I don't know whether it would
be faster to stash the ID on the (per-vcpu) stack and update it during
context switch.

Aside from that, this patch looks OK to me.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 13:53:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 13:53:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RykiY-0004Kq-8w; Sat, 18 Feb 2012 13:52:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RykiW-0004Kl-Lg
	for xen-devel@lists.xensource.com; Sat, 18 Feb 2012 13:52:48 +0000
Received: from [85.158.139.83:59971] by server-4.bemta-5.messagelabs.com id
	DA/A9-10788-F2DAF3F4; Sat, 18 Feb 2012 13:52:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329573166!15604196!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 18 Feb 2012 13:52:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Feb 2012 13:52:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RykiS-0000d3-RZ; Sat, 18 Feb 2012 13:52:44 +0000
Date: Sat, 18 Feb 2012 13:52:44 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120218135244.GA1531@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:49 +0000 on 15 Feb (1329324592), Ian Campbell wrote:
> +struct pcpu_info {
> +    unsigned int processor_id;
> +    struct vcpu *current_vcpu;
> +};
> +
> +DECLARE_PER_CPU(struct pcpu_info, pcpu_info);

> +static inline struct pcpu_info *get_pcpu_info(void)
> +{
> +    return &this_cpu(pcpu_info);
> +}
> +

I don't think it's worth declaring a struct and accessors for this; we
should just have current_vcpu as an ordinary per-cpu variable.

Storing the CPU ID in the per-pcpu area only happens to work because
per-cpu areas are a noop right now.  I have a patch that re-enables them
properly but for that we'll need a proper way of getting the CPU id.  In
the meantime I think it would be less confusing just to hard-code it as
zero than to do this. :)

We could use the physical CPU ID register; I don't know whether it would
be faster to stash the ID on the (per-vcpu) stack and update it during
context switch.

Aside from that, this patch looks OK to me.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Feb 18 21:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 21: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.xensource.com>)
	id 1Ryrlj-0000XU-QV; Sat, 18 Feb 2012 21:24:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1Ryn2K-0006Ca-Ub
	for xen-devel@lists.xen.org; Sat, 18 Feb 2012 16:21:25 +0000
Received: from [85.158.139.83:10268] by server-12.bemta-5.messagelabs.com id
	32/03-24595-400DF3F4; Sat, 18 Feb 2012 16:21:24 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329582083!15546583!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24085 invoked from network); 18 Feb 2012 16:21:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2012 16:21:23 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0CFD28C061;
	Sat, 18 Feb 2012 17:21:22 +0100 (CET)
Message-ID: <4F3FD001.4070703@suse.de>
Date: Sat, 18 Feb 2012 17:21:21 +0100
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@entel.upc.edu>
References: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
	<CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
In-Reply-To: <CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Sat, 18 Feb 2012 21:24:35 +0000
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] build: add needed missing
 libraries libm and librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

QW0gMTguMDIuMjAxMiAwOToyNCwgc2NocmllYiBCbHVlIFN3aXJsOgo+IE9uIFdlZCwgRmViIDgs
IDIwMTIgYXQgMTc6MDYsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+
IHdyb3RlOgo+PiBsaWJtIGlzIHVzZWQgaW4gY3V0aWxzLmMsIGJ1dCB0aGUgbGlicmFyeSB3YXMg
bm90IHNwZWNpZmllZAo+PiB3aGVuIGxpbmtpbmcgc29tZSBiaW5hcmllcywgdGhyb3dpbmcgdGhl
IGZvbGxvd2luZyBlcnJvcjoKPj4KPj4gY3V0aWxzLm86IEluIGZ1bmN0aW9uIGBzdHJ0b3N6X3N1
ZmZpeF91bml0JzoKPj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11LXhlbi1kaXIv
Y3V0aWxzLmM6MzU0OiB1bmRlZmluZWQKPj4gcmVmZXJlbmNlIHRvIGBfX2lzbmFuJwo+PiAvaG9t
ZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVuLWRpci9jdXRpbHMuYzozNTc6IHVuZGVm
aW5lZAo+PiByZWZlcmVuY2UgdG8gYG1vZGYnCj4+IGNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4
aXQgc3RhdHVzCj4+Cj4+IEFjY29yZGluZyB0byBtb2RmIG1hbiBwYWdlIFswXSwgLWxtIHNob3Vs
ZCBiZSB1c2VkIHdoZW4gbGlua2luZy4KPj4KPj4gbGlicnQgaXMgdXNlZCBpbiBxZW11LXRpbWUu
YywgYnV0IGFnYWluIHRoZSBsaWJyYXJ5IHdhcyBub3Qgc3BlY2lmaWVkCj4+IGF0IGxpbmsgdGlt
ZSwgdGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPj4KPj4gL2hvbWUvcm95Z2VyL3hlbi1j
bGVhbi90b29scy9xZW11LXhlbi1kaXIvcWVtdS10aW1lci5jOjU5NzogdW5kZWZpbmVkCj4+IHJl
ZmVyZW5jZSB0byBgdGltZXJfZ2V0dGltZScKPj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29s
cy9xZW11LXhlbi1kaXIvcWVtdS10aW1lci5jOjYxMDogdW5kZWZpbmVkCj4+IHJlZmVyZW5jZSB0
byBgdGltZXJfc2V0dGltZScKPj4gLi4vcWVtdS10aW1lci5vOiBJbiBmdW5jdGlvbiBgZHludGlj
a3Nfc3RhcnRfdGltZXInOgo+PiAvaG9tZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVu
LWRpci9xZW11LXRpbWVyLmM6NTY1OiB1bmRlZmluZWQKPj4gcmVmZXJlbmNlIHRvIGB0aW1lcl9j
cmVhdGUnCj4+IC4uL3FlbXUtdGltZXIubzogSW4gZnVuY3Rpb24gYGR5bnRpY2tzX3N0b3BfdGlt
ZXInOgo+PiAvaG9tZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRp
bWVyLmM6NTgzOiB1bmRlZmluZWQKPj4gcmVmZXJlbmNlIHRvIGB0aW1lcl9kZWxldGUnCj4+IGNv
bGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4+Cj4+IEFjY29yZGluZyB0byB0aW1l
cl9nZXR0dGltZSBtYW4gcGFnZSBbMV0sIC1scnQgc2hvdWxkIGJlIHVzZWQgd2hlbgo+PiBsaW5r
aW5nLgo+Pgo+PiBbMF0gaHR0cDovL2xpbnV4LmRpZS5uZXQvbWFuLzMvbW9kZgo+PiBbMV0gaHR0
cDovL2xpbnV4LmRpZS5uZXQvbWFuLzIvdGltZXJfZ2V0dGltZQo+IAo+IFRoaXMgaXMgTGludXgg
bWFuIHBhZ2UsIGlzIHRoaXMgY29ycmVjdCBmb3IgYWxsIE9TIHdlIHN1cHBvcnQ/CgpObywgbm90
IGZvciBIYWlrdSBvciBNYWMgT1MgWC4KCj4gV2UgYWxyZWFkeSBoYXZlIGEgdGVzdCBmb3IgLWxy
dCBpbiBjb25maWd1cmUsIGJ1dCBpdCBsb29rcyBsaWtlIGl0Cj4gZG9lcyBub3QgZGV0ZWN0IHlv
dXIgY2FzZSBjb3JyZWN0bHkuIFlvdSBzaG91bGQgZml4IHRoYXQgaW5zdGVhZC4KPiAKPj4gU2ln
bmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4g
LS0tCj4+ICBNYWtlZmlsZSAgICAgICAgfCAgICA0ICsrLS0KPj4gIE1ha2VmaWxlLnRhcmdldCB8
ICAgIDIgKysKPj4gIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9u
cygtKQo+Pgo+PiBkaWZmIC0tZ2l0IGEvTWFrZWZpbGUgYi9NYWtlZmlsZQo+PiBpbmRleCAzMDFj
NzVlLi5lMmMzY2Q0IDEwMDY0NAo+PiAtLS0gYS9NYWtlZmlsZQo+PiArKysgYi9NYWtlZmlsZQo+
PiBAQCAtMzQsNyArMzQsNyBAQCBjb25maWd1cmU6IDsKPj4KPj4gICQoY2FsbCBzZXQtdnBhdGgs
ICQoU1JDX1BBVEgpOiQoU1JDX1BBVEgpL2h3KQo+Pgo+PiAtTElCUys9LWx6ICQoTElCU19UT09M
UykKPj4gK0xJQlMrPS1seiAtbG0gLWxydCAkKExJQlNfVE9PTFMpCgpOQUNLLiBZb3UgbmVlZCB0
byBtYWtlIHN1cmUgaXQgZWl0aGVyIGxhbmRzIGluICQoTElCU19UT09MUykgb3IgaXMgYWRkZWQK
dmlhIGEgbmV3IHZhcmlhYmxlIHdpdGggaG9zdC1kZXBlbmRlbnQgY29udGVudHMuCgo+Pgo+PiAg
aWZkZWYgQlVJTERfRE9DUwo+PiAgRE9DUz1xZW11LWRvYy5odG1sIHFlbXUtdGVjaC5odG1sIHFl
bXUuMSBxZW11LWltZy4xIHFlbXUtbmJkLjggUU1QL3FtcC1jb21tYW5kcy50eHQKPj4gQEAgLTE3
MCw3ICsxNzAsNyBAQCB0ZXN0LWNvcm91dGluZTogdGVzdC1jb3JvdXRpbmUubyBxZW11LXRpbWVy
LWNvbW1vbi5vIGFzeW5jLm8gJChjb3JvdXRpbmUtb2JqLXkpCj4+ICAkKHFhcGktb2JqLXkpOiAk
KEdFTkVSQVRFRF9IRUFERVJTKQo+PiAgcWFwaS1kaXIgOj0gJChCVUlMRF9ESVIpL3FhcGktZ2Vu
ZXJhdGVkCj4+ICB0ZXN0LXZpc2l0b3IubyB0ZXN0LXFtcC1jb21tYW5kcy5vIHFlbXUtZ2EkKEVY
RVNVRik6IFFFTVVfQ0ZMQUdTICs9IC1JICQocWFwaS1kaXIpCj4+IC1xZW11LWdhJChFWEVTVUYp
OiBMSUJTID0gJChMSUJTX1FHQSkKPj4gK3FlbXUtZ2EkKEVYRVNVRik6IExJQlMgPSAkKExJQlNf
UUdBKSAtbG0KCk5BQ0suIEVpdGhlciBuZWVkcyB0byBkbyBMSUJTICs9IG9yIG11c3QgZ28gaW4g
JChMSUJTX1FHQSkgb3IgbmV3CmNvbmRpdGlvbmFsaXplZCB2YXJpYWJsZS4KCj4+Cj4+ICAkKHFh
cGktZGlyKS90ZXN0LXFhcGktdHlwZXMuYyAkKHFhcGktZGlyKS90ZXN0LXFhcGktdHlwZXMuaCA6
XAo+PiAgJChTUkNfUEFUSCkvcWFwaS1zY2hlbWEtdGVzdC5qc29uICQoU1JDX1BBVEgpL3Njcmlw
dHMvcWFwaS10eXBlcy5weQo+PiBkaWZmIC0tZ2l0IGEvTWFrZWZpbGUudGFyZ2V0IGIvTWFrZWZp
bGUudGFyZ2V0Cj4+IGluZGV4IGExMTE1MjEuLjk1ZDZiYzAgMTAwNjQ0Cj4+IC0tLSBhL01ha2Vm
aWxlLnRhcmdldAo+PiArKysgYi9NYWtlZmlsZS50YXJnZXQKPj4gQEAgLTMzLDYgKzMzLDggQEAg
ZW5kaWYKPj4gIFBST0dTPSQoUUVNVV9QUk9HKQo+PiAgU1RQRklMRVM9Cj4+Cj4+ICtMSUJTKz0t
bHJ0Cj4+ICsKCj4+ICBpZm5kZWYgQ09ORklHX0hBSUtVCj4+ICBMSUJTKz0tbG0KPj4gIGVuZGlm
CgpIZXJlJ3MgdGhlIHNwZWNpYWwgdHJlYXRtZW50IHRoYXQgYXZvaWRzIGFkZGluZyAtbG0gb24g
SGFpa3UgaG9zdApiZWNhdXNlIGl0IGRvZXNuJ3QgaGF2ZSBhIGxpYm0uc28gKGdpdC1ibGFtZSB3
b3VsZCd2ZSB0b2xkIHlvdSBpdCdzIGluCmxpYnJvb3Quc28gdGhlcmUpOyBvbiBEYXJ3aW4gdGhl
cmUncyBhIGNvbXBhdGliaWxpdHkgc3ltbGluayBidXQgaXQncyBpbgpsaWJTeXN0ZW0uZHlsaWIg
YWN0dWFsbHkgYW5kIGFuIGlmbmRlZiB3b3VsZCBiZSBhcHByb3ByaWF0ZSBhcyB3ZWxsLgpQT1NJ
WCBkb2VzIG5vdCBtYW5kYXRlIC1sbSBmb3IgbWF0aCBmdW5jdGlvbnMuCgpXb3VsZCBtb3Zpbmcg
dGhpcyBzbmlwcGV0IHRvIE1ha2VmaWxlLm9ianMgaGVscD8gV2hhdCBzeXN0ZW0gYXJlIHlvdSBv
bgphbnl3YXkgYW5kIGFyZSB5b3UgYWN0dWFsbHkgdXNpbmcgdXBzdHJlYW0gcWVtdS5naXQ/IG9w
ZW5TVVNFIDEyLjEgZG9lcwpub3QgY29tcGxhaW4sIGFuZCB3aXRob3V0IGEgdGVzdCBjYXNlIGl0
J3MgaGFyZCB0byBmaW5kIGEgc29sdXRpb24gaGVyZS4KCkFuZHJlYXMKCj4+IC0tCj4+IDEuNy45
CgotLSAKU1VTRSBMSU5VWCBQcm9kdWN0cyBHbWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xy
bmJlcmcsIEdlcm1hbnkKR0Y6IEplZmYgSGF3biwgSmVubmlmZXIgR3VpbGQsIEZlbGl4IEltZW5k
w7ZyZmZlcjsgSFJCIDE2NzQ2IEFHIE7DvHJuYmVyZwoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Sat Feb 18 21:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 18 Feb 2012 21: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.xensource.com>)
	id 1Ryrlj-0000XU-QV; Sat, 18 Feb 2012 21:24:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1Ryn2K-0006Ca-Ub
	for xen-devel@lists.xen.org; Sat, 18 Feb 2012 16:21:25 +0000
Received: from [85.158.139.83:10268] by server-12.bemta-5.messagelabs.com id
	32/03-24595-400DF3F4; Sat, 18 Feb 2012 16:21:24 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329582083!15546583!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24085 invoked from network); 18 Feb 2012 16:21:23 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2012 16:21:23 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0CFD28C061;
	Sat, 18 Feb 2012 17:21:22 +0100 (CET)
Message-ID: <4F3FD001.4070703@suse.de>
Date: Sat, 18 Feb 2012 17:21:21 +0100
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@entel.upc.edu>
References: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
	<CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
In-Reply-To: <CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
X-Enigmail-Version: 1.3.5
X-Mailman-Approved-At: Sat, 18 Feb 2012 21:24:35 +0000
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] build: add needed missing
 libraries libm and librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

QW0gMTguMDIuMjAxMiAwOToyNCwgc2NocmllYiBCbHVlIFN3aXJsOgo+IE9uIFdlZCwgRmViIDgs
IDIwMTIgYXQgMTc6MDYsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+
IHdyb3RlOgo+PiBsaWJtIGlzIHVzZWQgaW4gY3V0aWxzLmMsIGJ1dCB0aGUgbGlicmFyeSB3YXMg
bm90IHNwZWNpZmllZAo+PiB3aGVuIGxpbmtpbmcgc29tZSBiaW5hcmllcywgdGhyb3dpbmcgdGhl
IGZvbGxvd2luZyBlcnJvcjoKPj4KPj4gY3V0aWxzLm86IEluIGZ1bmN0aW9uIGBzdHJ0b3N6X3N1
ZmZpeF91bml0JzoKPj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11LXhlbi1kaXIv
Y3V0aWxzLmM6MzU0OiB1bmRlZmluZWQKPj4gcmVmZXJlbmNlIHRvIGBfX2lzbmFuJwo+PiAvaG9t
ZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVuLWRpci9jdXRpbHMuYzozNTc6IHVuZGVm
aW5lZAo+PiByZWZlcmVuY2UgdG8gYG1vZGYnCj4+IGNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4
aXQgc3RhdHVzCj4+Cj4+IEFjY29yZGluZyB0byBtb2RmIG1hbiBwYWdlIFswXSwgLWxtIHNob3Vs
ZCBiZSB1c2VkIHdoZW4gbGlua2luZy4KPj4KPj4gbGlicnQgaXMgdXNlZCBpbiBxZW11LXRpbWUu
YywgYnV0IGFnYWluIHRoZSBsaWJyYXJ5IHdhcyBub3Qgc3BlY2lmaWVkCj4+IGF0IGxpbmsgdGlt
ZSwgdGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPj4KPj4gL2hvbWUvcm95Z2VyL3hlbi1j
bGVhbi90b29scy9xZW11LXhlbi1kaXIvcWVtdS10aW1lci5jOjU5NzogdW5kZWZpbmVkCj4+IHJl
ZmVyZW5jZSB0byBgdGltZXJfZ2V0dGltZScKPj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29s
cy9xZW11LXhlbi1kaXIvcWVtdS10aW1lci5jOjYxMDogdW5kZWZpbmVkCj4+IHJlZmVyZW5jZSB0
byBgdGltZXJfc2V0dGltZScKPj4gLi4vcWVtdS10aW1lci5vOiBJbiBmdW5jdGlvbiBgZHludGlj
a3Nfc3RhcnRfdGltZXInOgo+PiAvaG9tZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVu
LWRpci9xZW11LXRpbWVyLmM6NTY1OiB1bmRlZmluZWQKPj4gcmVmZXJlbmNlIHRvIGB0aW1lcl9j
cmVhdGUnCj4+IC4uL3FlbXUtdGltZXIubzogSW4gZnVuY3Rpb24gYGR5bnRpY2tzX3N0b3BfdGlt
ZXInOgo+PiAvaG9tZS9yb3lnZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRp
bWVyLmM6NTgzOiB1bmRlZmluZWQKPj4gcmVmZXJlbmNlIHRvIGB0aW1lcl9kZWxldGUnCj4+IGNv
bGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4+Cj4+IEFjY29yZGluZyB0byB0aW1l
cl9nZXR0dGltZSBtYW4gcGFnZSBbMV0sIC1scnQgc2hvdWxkIGJlIHVzZWQgd2hlbgo+PiBsaW5r
aW5nLgo+Pgo+PiBbMF0gaHR0cDovL2xpbnV4LmRpZS5uZXQvbWFuLzMvbW9kZgo+PiBbMV0gaHR0
cDovL2xpbnV4LmRpZS5uZXQvbWFuLzIvdGltZXJfZ2V0dGltZQo+IAo+IFRoaXMgaXMgTGludXgg
bWFuIHBhZ2UsIGlzIHRoaXMgY29ycmVjdCBmb3IgYWxsIE9TIHdlIHN1cHBvcnQ/CgpObywgbm90
IGZvciBIYWlrdSBvciBNYWMgT1MgWC4KCj4gV2UgYWxyZWFkeSBoYXZlIGEgdGVzdCBmb3IgLWxy
dCBpbiBjb25maWd1cmUsIGJ1dCBpdCBsb29rcyBsaWtlIGl0Cj4gZG9lcyBub3QgZGV0ZWN0IHlv
dXIgY2FzZSBjb3JyZWN0bHkuIFlvdSBzaG91bGQgZml4IHRoYXQgaW5zdGVhZC4KPiAKPj4gU2ln
bmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4g
LS0tCj4+ICBNYWtlZmlsZSAgICAgICAgfCAgICA0ICsrLS0KPj4gIE1ha2VmaWxlLnRhcmdldCB8
ICAgIDIgKysKPj4gIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9u
cygtKQo+Pgo+PiBkaWZmIC0tZ2l0IGEvTWFrZWZpbGUgYi9NYWtlZmlsZQo+PiBpbmRleCAzMDFj
NzVlLi5lMmMzY2Q0IDEwMDY0NAo+PiAtLS0gYS9NYWtlZmlsZQo+PiArKysgYi9NYWtlZmlsZQo+
PiBAQCAtMzQsNyArMzQsNyBAQCBjb25maWd1cmU6IDsKPj4KPj4gICQoY2FsbCBzZXQtdnBhdGgs
ICQoU1JDX1BBVEgpOiQoU1JDX1BBVEgpL2h3KQo+Pgo+PiAtTElCUys9LWx6ICQoTElCU19UT09M
UykKPj4gK0xJQlMrPS1seiAtbG0gLWxydCAkKExJQlNfVE9PTFMpCgpOQUNLLiBZb3UgbmVlZCB0
byBtYWtlIHN1cmUgaXQgZWl0aGVyIGxhbmRzIGluICQoTElCU19UT09MUykgb3IgaXMgYWRkZWQK
dmlhIGEgbmV3IHZhcmlhYmxlIHdpdGggaG9zdC1kZXBlbmRlbnQgY29udGVudHMuCgo+Pgo+PiAg
aWZkZWYgQlVJTERfRE9DUwo+PiAgRE9DUz1xZW11LWRvYy5odG1sIHFlbXUtdGVjaC5odG1sIHFl
bXUuMSBxZW11LWltZy4xIHFlbXUtbmJkLjggUU1QL3FtcC1jb21tYW5kcy50eHQKPj4gQEAgLTE3
MCw3ICsxNzAsNyBAQCB0ZXN0LWNvcm91dGluZTogdGVzdC1jb3JvdXRpbmUubyBxZW11LXRpbWVy
LWNvbW1vbi5vIGFzeW5jLm8gJChjb3JvdXRpbmUtb2JqLXkpCj4+ICAkKHFhcGktb2JqLXkpOiAk
KEdFTkVSQVRFRF9IRUFERVJTKQo+PiAgcWFwaS1kaXIgOj0gJChCVUlMRF9ESVIpL3FhcGktZ2Vu
ZXJhdGVkCj4+ICB0ZXN0LXZpc2l0b3IubyB0ZXN0LXFtcC1jb21tYW5kcy5vIHFlbXUtZ2EkKEVY
RVNVRik6IFFFTVVfQ0ZMQUdTICs9IC1JICQocWFwaS1kaXIpCj4+IC1xZW11LWdhJChFWEVTVUYp
OiBMSUJTID0gJChMSUJTX1FHQSkKPj4gK3FlbXUtZ2EkKEVYRVNVRik6IExJQlMgPSAkKExJQlNf
UUdBKSAtbG0KCk5BQ0suIEVpdGhlciBuZWVkcyB0byBkbyBMSUJTICs9IG9yIG11c3QgZ28gaW4g
JChMSUJTX1FHQSkgb3IgbmV3CmNvbmRpdGlvbmFsaXplZCB2YXJpYWJsZS4KCj4+Cj4+ICAkKHFh
cGktZGlyKS90ZXN0LXFhcGktdHlwZXMuYyAkKHFhcGktZGlyKS90ZXN0LXFhcGktdHlwZXMuaCA6
XAo+PiAgJChTUkNfUEFUSCkvcWFwaS1zY2hlbWEtdGVzdC5qc29uICQoU1JDX1BBVEgpL3Njcmlw
dHMvcWFwaS10eXBlcy5weQo+PiBkaWZmIC0tZ2l0IGEvTWFrZWZpbGUudGFyZ2V0IGIvTWFrZWZp
bGUudGFyZ2V0Cj4+IGluZGV4IGExMTE1MjEuLjk1ZDZiYzAgMTAwNjQ0Cj4+IC0tLSBhL01ha2Vm
aWxlLnRhcmdldAo+PiArKysgYi9NYWtlZmlsZS50YXJnZXQKPj4gQEAgLTMzLDYgKzMzLDggQEAg
ZW5kaWYKPj4gIFBST0dTPSQoUUVNVV9QUk9HKQo+PiAgU1RQRklMRVM9Cj4+Cj4+ICtMSUJTKz0t
bHJ0Cj4+ICsKCj4+ICBpZm5kZWYgQ09ORklHX0hBSUtVCj4+ICBMSUJTKz0tbG0KPj4gIGVuZGlm
CgpIZXJlJ3MgdGhlIHNwZWNpYWwgdHJlYXRtZW50IHRoYXQgYXZvaWRzIGFkZGluZyAtbG0gb24g
SGFpa3UgaG9zdApiZWNhdXNlIGl0IGRvZXNuJ3QgaGF2ZSBhIGxpYm0uc28gKGdpdC1ibGFtZSB3
b3VsZCd2ZSB0b2xkIHlvdSBpdCdzIGluCmxpYnJvb3Quc28gdGhlcmUpOyBvbiBEYXJ3aW4gdGhl
cmUncyBhIGNvbXBhdGliaWxpdHkgc3ltbGluayBidXQgaXQncyBpbgpsaWJTeXN0ZW0uZHlsaWIg
YWN0dWFsbHkgYW5kIGFuIGlmbmRlZiB3b3VsZCBiZSBhcHByb3ByaWF0ZSBhcyB3ZWxsLgpQT1NJ
WCBkb2VzIG5vdCBtYW5kYXRlIC1sbSBmb3IgbWF0aCBmdW5jdGlvbnMuCgpXb3VsZCBtb3Zpbmcg
dGhpcyBzbmlwcGV0IHRvIE1ha2VmaWxlLm9ianMgaGVscD8gV2hhdCBzeXN0ZW0gYXJlIHlvdSBv
bgphbnl3YXkgYW5kIGFyZSB5b3UgYWN0dWFsbHkgdXNpbmcgdXBzdHJlYW0gcWVtdS5naXQ/IG9w
ZW5TVVNFIDEyLjEgZG9lcwpub3QgY29tcGxhaW4sIGFuZCB3aXRob3V0IGEgdGVzdCBjYXNlIGl0
J3MgaGFyZCB0byBmaW5kIGEgc29sdXRpb24gaGVyZS4KCkFuZHJlYXMKCj4+IC0tCj4+IDEuNy45
CgotLSAKU1VTRSBMSU5VWCBQcm9kdWN0cyBHbWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xy
bmJlcmcsIEdlcm1hbnkKR0Y6IEplZmYgSGF3biwgSmVubmlmZXIgR3VpbGQsIEZlbGl4IEltZW5k
w7ZyZmZlcjsgSFJCIDE2NzQ2IEFHIE7DvHJuYmVyZwoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Sun Feb 19 03:18:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 03: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.xensource.com>)
	id 1RyxH7-0002as-Nx; Sun, 19 Feb 2012 03:17:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RyxH6-0002an-1p
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 03:17:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329621433!3428626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQ1OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27033 invoked from network); 19 Feb 2012 03:17:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 03:17:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,444,1325462400"; d="scan'208";a="10789541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2012 03:17:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Sun, 19 Feb 2012
	03:17:12 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Sun, 19 Feb 2012 03:17:16 +0000
Thread-Topic: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
Thread-Index: Acztp0LbNEmz1pQORuC4+3pFSc6GVQBDYYwQ
Message-ID: <291EDFCB1E9E224A99088639C4762022C80EF53BF2@LONPMAILBOX01.citrite.net>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
	<91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
	<291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
	<0db5d62c10cd88eb11881a1cae41cdfe.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <0db5d62c10cd88eb11881a1cae41cdfe.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> >
> > Enabling viridian timers in Xen may be the way to go though.
> I'm looking at xen code (and various XenServer versions as well). I don't see
> any timer implementations, at least not anything from the msdn references
> (e.g. HV_X64_MSR_REFERENCE_TSC, HV_X64_MSR_STIMER0_CONFIG, etc)
> 
> Am I looking in the wrong place?

Nope. By 'enabling' I meant writing some code to implement them :-)

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 03:18:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 03: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.xensource.com>)
	id 1RyxH7-0002as-Nx; Sun, 19 Feb 2012 03:17:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RyxH6-0002an-1p
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 03:17:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329621433!3428626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQ1OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27033 invoked from network); 19 Feb 2012 03:17:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 03:17:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,444,1325462400"; d="scan'208";a="10789541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2012 03:17:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Sun, 19 Feb 2012
	03:17:12 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Sun, 19 Feb 2012 03:17:16 +0000
Thread-Topic: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
Thread-Index: Acztp0LbNEmz1pQORuC4+3pFSc6GVQBDYYwQ
Message-ID: <291EDFCB1E9E224A99088639C4762022C80EF53BF2@LONPMAILBOX01.citrite.net>
References: <mailman.3899.1329481183.1471.xen-devel@lists.xensource.com>
	<91f497056a6f40093b3dcab310125a83.squirrel@webmail.lagarcavilla.org>
	<291EDFCB1E9E224A99088639C4762022C80EF53BDE@LONPMAILBOX01.citrite.net>
	<0db5d62c10cd88eb11881a1cae41cdfe.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <0db5d62c10cd88eb11881a1cae41cdfe.squirrel@webmail.lagarcavilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Qrux <qrux.qed@gmail.com>
Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> >
> > Enabling viridian timers in Xen may be the way to go though.
> I'm looking at xen code (and various XenServer versions as well). I don't see
> any timer implementations, at least not anything from the msdn references
> (e.g. HV_X64_MSR_REFERENCE_TSC, HV_X64_MSR_STIMER0_CONFIG, etc)
> 
> Am I looking in the wrong place?

Nope. By 'enabling' I meant writing some code to implement them :-)

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 08:45:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 08:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz2Nh-0006Sg-8Q; Sun, 19 Feb 2012 08:44: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 1Rz2Ng-0006Sb-DX
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 08:44:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329641032!57305207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQ1OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15830 invoked from network); 19 Feb 2012 08:43: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;
	19 Feb 2012 08:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,445,1325462400"; d="scan'208";a="10790179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2012 08:44: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.213.0;
	Sun, 19 Feb 2012 08:44:22 +0000
Message-ID: <1329641061.5898.10.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Sun, 19 Feb 2012 08:44:21 +0000
In-Reply-To: <20120218135244.GA1531@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-18 at 13:52 +0000, Tim Deegan wrote:
> At 16:49 +0000 on 15 Feb (1329324592), Ian Campbell wrote:
> > +struct pcpu_info {
> > +    unsigned int processor_id;
> > +    struct vcpu *current_vcpu;
> > +};
> > +
> > +DECLARE_PER_CPU(struct pcpu_info, pcpu_info);
> 
> > +static inline struct pcpu_info *get_pcpu_info(void)
> > +{
> > +    return &this_cpu(pcpu_info);
> > +}
> > +
> 
> I don't think it's worth declaring a struct and accessors for this; we
> should just have current_vcpu as an ordinary per-cpu variable.

That makes sense.

> Storing the CPU ID in the per-pcpu area only happens to work because
> per-cpu areas are a noop right now.  I have a patch that re-enables them
> properly but for that we'll need a proper way of getting the CPU id.

I had imagined that we would have per pVCPU page tables so the current
CPU's per-pcpu area would always be at the same location. If that is not
(going to be) the case then I'll stash it on the VCPU stack instead.

Thinking about it now playing tricks with the PTs does make it tricky on
the rare occasions when you want to access another pCPUs per area.

Speaking of per-cpu areas -- I did notice a strange behaviour while
debugging this. It seemed that a barrier() was not sufficient to keep
the processor from caching the value of "current" in a register (i.e it
would load into r6 before the barrier and use r6 after). I figured this
was probably an unfortunate side effect of the current nobbled per-pcpu
areas and would be fixed as part of your SMP bringup stuff.

> We could use the physical CPU ID register; I don't know whether it
> would be faster to stash the ID on the (per-vcpu) stack and update it
> during context switch.

Does h/w CPU ID correspond to the s/w one in our circumstances? Might
they be very sparse or something inconvenient like that?

I'd expect pulling things from registers to be faster in the normal case
but in this specific scenario I'd imagine the base of the stack will be
pretty cache hot since it has all the guest state in it etc which we've
probably fairly recently pushed to or are about to pop from.

[...]

> Aside from that, this patch looks OK to me.

Thanks I'll repost next week with the fixes you suggest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 08:45:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 08:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz2Nh-0006Sg-8Q; Sun, 19 Feb 2012 08:44: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 1Rz2Ng-0006Sb-DX
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 08:44:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329641032!57305207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQ1OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15830 invoked from network); 19 Feb 2012 08:43: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;
	19 Feb 2012 08:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,445,1325462400"; d="scan'208";a="10790179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2012 08:44: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.213.0;
	Sun, 19 Feb 2012 08:44:22 +0000
Message-ID: <1329641061.5898.10.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Sun, 19 Feb 2012 08:44:21 +0000
In-Reply-To: <20120218135244.GA1531@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-02-18 at 13:52 +0000, Tim Deegan wrote:
> At 16:49 +0000 on 15 Feb (1329324592), Ian Campbell wrote:
> > +struct pcpu_info {
> > +    unsigned int processor_id;
> > +    struct vcpu *current_vcpu;
> > +};
> > +
> > +DECLARE_PER_CPU(struct pcpu_info, pcpu_info);
> 
> > +static inline struct pcpu_info *get_pcpu_info(void)
> > +{
> > +    return &this_cpu(pcpu_info);
> > +}
> > +
> 
> I don't think it's worth declaring a struct and accessors for this; we
> should just have current_vcpu as an ordinary per-cpu variable.

That makes sense.

> Storing the CPU ID in the per-pcpu area only happens to work because
> per-cpu areas are a noop right now.  I have a patch that re-enables them
> properly but for that we'll need a proper way of getting the CPU id.

I had imagined that we would have per pVCPU page tables so the current
CPU's per-pcpu area would always be at the same location. If that is not
(going to be) the case then I'll stash it on the VCPU stack instead.

Thinking about it now playing tricks with the PTs does make it tricky on
the rare occasions when you want to access another pCPUs per area.

Speaking of per-cpu areas -- I did notice a strange behaviour while
debugging this. It seemed that a barrier() was not sufficient to keep
the processor from caching the value of "current" in a register (i.e it
would load into r6 before the barrier and use r6 after). I figured this
was probably an unfortunate side effect of the current nobbled per-pcpu
areas and would be fixed as part of your SMP bringup stuff.

> We could use the physical CPU ID register; I don't know whether it
> would be faster to stash the ID on the (per-vcpu) stack and update it
> during context switch.

Does h/w CPU ID correspond to the s/w one in our circumstances? Might
they be very sparse or something inconvenient like that?

I'd expect pulling things from registers to be faster in the normal case
but in this specific scenario I'd imagine the base of the stack will be
pretty cache hot since it has all the guest state in it etc which we've
probably fairly recently pushed to or are about to pop from.

[...]

> Aside from that, this patch looks OK to me.

Thanks I'll repost next week with the fixes you suggest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 09:32:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 09:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz36v-0006uK-2h; Sun, 19 Feb 2012 09:31:13 +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 1Rz36t-0006uF-QC
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 09:31:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329643804!61668271!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 19 Feb 2012 09:30:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2012 09:30:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rz36p-00080B-3T; Sun, 19 Feb 2012 09:31:07 +0000
Date: Sun, 19 Feb 2012 09:31:05 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120219093105.GA30637@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329641061.5898.10.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:44 +0000 on 19 Feb (1329641061), Ian Campbell wrote:
> > Storing the CPU ID in the per-pcpu area only happens to work because
> > per-cpu areas are a noop right now.  I have a patch that re-enables them
> > properly but for that we'll need a proper way of getting the CPU id.
> 
> I had imagined that we would have per pVCPU page tables so the current
> CPU's per-pcpu area would always be at the same location. If that is not
> (going to be) the case then I'll stash it on the VCPU stack instead.

Yes I'd thought that too but then when I came to implement it up...

> Thinking about it now playing tricks with the PTs does make it tricky on
> the rare occasions when you want to access another pCPUs per area.

... I saw that and since I then had to use the normal relocation tricks
I didn't bother with the local-var special case.  Could still do it if
it turns out to be a perf win (but w/out hardware to measure, I think
I'll leave the optimizations alone for now).

> Speaking of per-cpu areas -- I did notice a strange behaviour while
> debugging this. It seemed that a barrier() was not sufficient to keep
> the processor from caching the value of "current" in a register (i.e it
> would load into r6 before the barrier and use r6 after). I figured this
> was probably an unfortunate side effect of the current nobbled per-pcpu
> areas and would be fixed as part of your SMP bringup stuff.

Wierd.  Must check that when I rebase the SMP patches.

> > We could use the physical CPU ID register; I don't know whether it
> > would be faster to stash the ID on the (per-vcpu) stack and update it
> > during context switch.
> 
> Does h/w CPU ID correspond to the s/w one in our circumstances? Might
> they be very sparse or something inconvenient like that?

It does on all the h/w we support :) but yes it could be sparse,
encoding NUMA topology.

> I'd expect pulling things from registers to be faster in the normal case
> but in this specific scenario I'd imagine the base of the stack will be
> pretty cache hot since it has all the guest state in it etc which we've
> probably fairly recently pushed to or are about to pop from.

Agreed.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 09:32:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 09:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz36v-0006uK-2h; Sun, 19 Feb 2012 09:31:13 +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 1Rz36t-0006uF-QC
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 09:31:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329643804!61668271!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2788 invoked from network); 19 Feb 2012 09:30:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2012 09:30:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rz36p-00080B-3T; Sun, 19 Feb 2012 09:31:07 +0000
Date: Sun, 19 Feb 2012 09:31:05 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120219093105.GA30637@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329641061.5898.10.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:44 +0000 on 19 Feb (1329641061), Ian Campbell wrote:
> > Storing the CPU ID in the per-pcpu area only happens to work because
> > per-cpu areas are a noop right now.  I have a patch that re-enables them
> > properly but for that we'll need a proper way of getting the CPU id.
> 
> I had imagined that we would have per pVCPU page tables so the current
> CPU's per-pcpu area would always be at the same location. If that is not
> (going to be) the case then I'll stash it on the VCPU stack instead.

Yes I'd thought that too but then when I came to implement it up...

> Thinking about it now playing tricks with the PTs does make it tricky on
> the rare occasions when you want to access another pCPUs per area.

... I saw that and since I then had to use the normal relocation tricks
I didn't bother with the local-var special case.  Could still do it if
it turns out to be a perf win (but w/out hardware to measure, I think
I'll leave the optimizations alone for now).

> Speaking of per-cpu areas -- I did notice a strange behaviour while
> debugging this. It seemed that a barrier() was not sufficient to keep
> the processor from caching the value of "current" in a register (i.e it
> would load into r6 before the barrier and use r6 after). I figured this
> was probably an unfortunate side effect of the current nobbled per-pcpu
> areas and would be fixed as part of your SMP bringup stuff.

Wierd.  Must check that when I rebase the SMP patches.

> > We could use the physical CPU ID register; I don't know whether it
> > would be faster to stash the ID on the (per-vcpu) stack and update it
> > during context switch.
> 
> Does h/w CPU ID correspond to the s/w one in our circumstances? Might
> they be very sparse or something inconvenient like that?

It does on all the h/w we support :) but yes it could be sparse,
encoding NUMA topology.

> I'd expect pulling things from registers to be faster in the normal case
> but in this specific scenario I'd imagine the base of the stack will be
> pretty cache hot since it has all the guest state in it etc which we've
> probably fairly recently pushed to or are about to pop from.

Agreed.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 11:58:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 11:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz5On-0007st-0U; Sun, 19 Feb 2012 11:57:49 +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 1Rz5Om-0007so-0p
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 11:57:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329652614!54845577!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzQ2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14091 invoked from network); 19 Feb 2012 11:56:54 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Feb 2012 11:56:54 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 19 Feb 2012 03:57:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127138576"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by fmsmga002.fm.intel.com with ESMTP; 19 Feb 2012 03:57:43 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 19 Feb 2012 19:57:42 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sun, 19 Feb 2012 19:57:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 3/3] Xen pad logic and notification
Thread-Index: AQHM7YGr1HfHeb7nTGSKH/iUASruopZEERig
Date: Sun, 19 Feb 2012 11:57:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A0869@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
	<20120217143727.GC29110@phenom.dumpdata.com>
In-Reply-To: <20120217143727.GC29110@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 08:58:38AM +0000, Liu, Jinsong wrote:
>>> From fee39804d2634dfba7b369dc82dac19b57400f84 Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Sat, 18 Feb 2012 00:46:29 +0800
>> Subject: [PATCH 3/3] Xen pad logic and notification
>> 
>> This patch implement Xen pad logic, and when getting pad device
>> notification, it hypercalls to Xen hypervisor for core parking.
> 
> CC-ing linux-acpi@vger.kernel.org and Len Brown.
> 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>  drivers/xen/xen_acpi_pad.c       |  189
>>  ++++++++++++++++++++++++++++++++++++++
>>  include/xen/interface/platform.h |   14 +++ 2 files changed, 203
>> insertions(+), 0 deletions(-) 
>> 
>> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
>> index 63ab2fb..ba66d51 100644
>> --- a/drivers/xen/xen_acpi_pad.c
>> +++ b/drivers/xen/xen_acpi_pad.c
>> @@ -1,8 +1,197 @@
>> +/*
>> + * xen_acpi_pad.c - Xen pad interface
>> + *
>> + * Copyright (c) 2012, Intel Corporation.
>> + *    Author: Liu, Jinsong <jinsong.liu@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. + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/types.h>
>> +#include <acpi/acpi_bus.h>
>> +#include <acpi/acpi_drivers.h>
>> +
>> +#include <asm/xen/hypercall.h>
>> +
>> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "xen_acpi_pad"
>> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Xen Processor
>> Aggregator" +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>> +static DEFINE_MUTEX(xen_cpu_lock);
>> +
>> +static int xen_acpi_pad_idle_cpus(int *num_cpus)
>> +{
>> +	int ret;
>> +
>> +	struct xen_platform_op op = {
>> +		.cmd = XENPF_core_parking,
>> +		.interface_version = XENPF_INTERFACE_VERSION,
>> +	};
>> +
>> +	/* set cpu nums expected to be idled */
>> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
>> +	op.u.core_parking.idle_nums = (uint32_t)*num_cpus;
>> +	ret = HYPERVISOR_dom0_op(&op);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * get cpu nums actually be idled
>> +	 * cannot get it by using hypercall once (shared with _SET)
>> +	 * because of the characteristic of Xen continue_hypercall_on_cpu
>> +	 */ +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
>> +	ret = HYPERVISOR_dom0_op(&op);
>> +	if (ret)
>> +		return ret;
>> +
>> +	*num_cpus = op.u.core_parking.idle_nums;
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Query firmware how many CPUs should be idle
>> + * return -1 on failure
>> + */
>> +static int xen_acpi_pad_pur(acpi_handle handle)
>> +{
>> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL}; +	union
>> acpi_object *package; +	int num = -1;
>> +
>> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL,
>> &buffer))) +		return num; +
>> +	if (!buffer.length || !buffer.pointer)
>> +		return num;
>> +
>> +	package = buffer.pointer;
>> +
>> +	if (package->type == ACPI_TYPE_PACKAGE &&
>> +		package->package.count == 2 &&
>> +		package->package.elements[0].integer.value == 1) /* rev 1 */ +
>> +		num = package->package.elements[1].integer.value; +
>> +	kfree(buffer.pointer);
>> +	return num;
>> +}
>> +
>> +/* Notify firmware how many CPUs are idle */
>> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
>> +	uint32_t idle_cpus) +{
>> +	union acpi_object params[3] = {
>> +		{.type = ACPI_TYPE_INTEGER,},
>> +		{.type = ACPI_TYPE_INTEGER,},
>> +		{.type = ACPI_TYPE_BUFFER,},
>> +	};
>> +	struct acpi_object_list arg_list = {3, params};
>> +
>> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
>> +	params[1].integer.value =  stat;
>> +	params[2].buffer.length = 4;
>> +	params[2].buffer.pointer = (void *)&idle_cpus;
>> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL); +}
>> +
>> +static void xen_acpi_pad_handle_notify(acpi_handle handle) +{
>> +	int ret, num_cpus;
>> +
>> +	mutex_lock(&xen_cpu_lock);
>> +	num_cpus = xen_acpi_pad_pur(handle);
>> +	if (num_cpus < 0) {
>> +		mutex_unlock(&xen_cpu_lock);
>> +		return;
>> +	}
>> +
>> +	ret = xen_acpi_pad_idle_cpus(&num_cpus);
>> +	if (ret) {
>> +		mutex_unlock(&xen_cpu_lock);
>> +		return;
>> +	}
>> +
>> +	xen_acpi_pad_ost(handle, 0, num_cpus);
>> +	mutex_unlock(&xen_cpu_lock);
>> +}
>> +
>> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
>> +	void *data) +{
>> +	switch (event) {
>> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
>> +		xen_acpi_pad_handle_notify(handle);
>> +		break;
>> +	default:
>> +		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
>> +		break; +	}
>> +}
>> +
>> +static int xen_acpi_pad_add(struct acpi_device *device) +{
>> +	acpi_status status;
>> +
>> +	strcpy(acpi_device_name(device),
>> ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
>> +	strcpy(acpi_device_class(device),
>> ACPI_PROCESSOR_AGGREGATOR_CLASS); + +	status =
>> acpi_install_notify_handler(device->handle, +		 ACPI_DEVICE_NOTIFY,
>> xen_acpi_pad_notify, device); +	if (ACPI_FAILURE(status)) +		return
>> -ENODEV; + +	return 0;
>> +}
>> +
>> +static int xen_acpi_pad_remove(struct acpi_device *device, +	int
>> type) +{
>> +	int num_cpus = 0;
>> +
>> +	mutex_lock(&xen_cpu_lock);
>> +	xen_acpi_pad_idle_cpus(&num_cpus);
>> +	mutex_unlock(&xen_cpu_lock);
>> +
>> +	acpi_remove_notify_handler(device->handle,
>> +		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
>> +	return 0;
>> +}
>> +
>> +static const struct acpi_device_id xen_pad_device_ids[] = {
>> +	{"ACPI000C", 0}, +	{"", 0},
>> +};
>> +
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +	.name = "xen_processor_aggregator",
>> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +	.ids = xen_pad_device_ids,
>> +	.ops = {
>> +		.add = xen_acpi_pad_add,
>> +		.remove = xen_acpi_pad_remove,
>> +	},
>> +};
>> +
>>  int xen_acpi_pad_init(void)
>>  {
>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> 
> How does that work when the the driver is booted under baremetal?
> Won't it kick out the native ACPI_PROCESSOR_AGGREGATOR_CLASS
> (acpi_pad.c) ? 
> 
> What about if the other ACPI_PROCESSOR_AGGREGATOR_CLASS gets called
> first? Won't this fail?
> 
> Or is the acpi_bus_register_driver smart enough to process more than
> one ACPI bus device?

When driver booted under baremetal, xen_acpi_pad.c would be disabled and native acpi_pad.c logic would work.

Thanks,
Jinsong

> 
>> +	return acpi_bus_register_driver(&xen_acpi_pad_driver); +#else
>>  	return 0;
>> +#endif
>>  }
>> 
>>  void xen_acpi_pad_exit(void)
>>  {
>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>> +	acpi_bus_unregister_driver(&xen_acpi_pad_driver); +#endif
>>  }
>> diff --git a/include/xen/interface/platform.h
>> b/include/xen/interface/platform.h index c168468..56ec72a 100644 ---
>> a/include/xen/interface/platform.h +++
>> b/include/xen/interface/platform.h @@ -297,6 +297,19 @@ struct
>>  xenpf_set_processor_pminfo {  };
>> DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); 
>> 
>> +#define XENPF_core_parking      60
>> +
>> +#define XEN_CORE_PARKING_SET    1
>> +#define XEN_CORE_PARKING_GET    2
>> +struct xenpf_core_parking {
>> +	/* IN variables */
>> +	uint32_t type;
>> +	/* IN variables:  set cpu nums expected to be idled */
>> +	/* OUT variables: get cpu nums actually be idled */ +	uint32_t
>> idle_nums; +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
>> +
>>  struct xen_platform_op {
>>  	uint32_t cmd;
>>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
>> @@ -312,6 +325,7 @@ struct xen_platform_op {
>>  		struct xenpf_change_freq       change_freq;
>>  		struct xenpf_getidletime       getidletime;
>>  		struct xenpf_set_processor_pminfo set_pminfo;
>> +		struct xenpf_core_parking      core_parking;
>>  		uint8_t                        pad[128];
>>  	} u;
>>  };
>> --
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 11:58:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 11:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz5On-0007st-0U; Sun, 19 Feb 2012 11:57:49 +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 1Rz5Om-0007so-0p
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 11:57:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329652614!54845577!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzQ2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14091 invoked from network); 19 Feb 2012 11:56:54 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-27.messagelabs.com with SMTP;
	19 Feb 2012 11:56:54 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 19 Feb 2012 03:57:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127138576"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by fmsmga002.fm.intel.com with ESMTP; 19 Feb 2012 03:57:43 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 19 Feb 2012 19:57:42 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sun, 19 Feb 2012 19:57:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 3/3] Xen pad logic and notification
Thread-Index: AQHM7YGr1HfHeb7nTGSKH/iUASruopZEERig
Date: Sun, 19 Feb 2012 11:57:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A0869@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
	<20120217143727.GC29110@phenom.dumpdata.com>
In-Reply-To: <20120217143727.GC29110@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 08:58:38AM +0000, Liu, Jinsong wrote:
>>> From fee39804d2634dfba7b369dc82dac19b57400f84 Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Sat, 18 Feb 2012 00:46:29 +0800
>> Subject: [PATCH 3/3] Xen pad logic and notification
>> 
>> This patch implement Xen pad logic, and when getting pad device
>> notification, it hypercalls to Xen hypervisor for core parking.
> 
> CC-ing linux-acpi@vger.kernel.org and Len Brown.
> 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>  drivers/xen/xen_acpi_pad.c       |  189
>>  ++++++++++++++++++++++++++++++++++++++
>>  include/xen/interface/platform.h |   14 +++ 2 files changed, 203
>> insertions(+), 0 deletions(-) 
>> 
>> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
>> index 63ab2fb..ba66d51 100644
>> --- a/drivers/xen/xen_acpi_pad.c
>> +++ b/drivers/xen/xen_acpi_pad.c
>> @@ -1,8 +1,197 @@
>> +/*
>> + * xen_acpi_pad.c - Xen pad interface
>> + *
>> + * Copyright (c) 2012, Intel Corporation.
>> + *    Author: Liu, Jinsong <jinsong.liu@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. + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/types.h>
>> +#include <acpi/acpi_bus.h>
>> +#include <acpi/acpi_drivers.h>
>> +
>> +#include <asm/xen/hypercall.h>
>> +
>> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "xen_acpi_pad"
>> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Xen Processor
>> Aggregator" +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>> +static DEFINE_MUTEX(xen_cpu_lock);
>> +
>> +static int xen_acpi_pad_idle_cpus(int *num_cpus)
>> +{
>> +	int ret;
>> +
>> +	struct xen_platform_op op = {
>> +		.cmd = XENPF_core_parking,
>> +		.interface_version = XENPF_INTERFACE_VERSION,
>> +	};
>> +
>> +	/* set cpu nums expected to be idled */
>> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
>> +	op.u.core_parking.idle_nums = (uint32_t)*num_cpus;
>> +	ret = HYPERVISOR_dom0_op(&op);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * get cpu nums actually be idled
>> +	 * cannot get it by using hypercall once (shared with _SET)
>> +	 * because of the characteristic of Xen continue_hypercall_on_cpu
>> +	 */ +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
>> +	ret = HYPERVISOR_dom0_op(&op);
>> +	if (ret)
>> +		return ret;
>> +
>> +	*num_cpus = op.u.core_parking.idle_nums;
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Query firmware how many CPUs should be idle
>> + * return -1 on failure
>> + */
>> +static int xen_acpi_pad_pur(acpi_handle handle)
>> +{
>> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL}; +	union
>> acpi_object *package; +	int num = -1;
>> +
>> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL,
>> &buffer))) +		return num; +
>> +	if (!buffer.length || !buffer.pointer)
>> +		return num;
>> +
>> +	package = buffer.pointer;
>> +
>> +	if (package->type == ACPI_TYPE_PACKAGE &&
>> +		package->package.count == 2 &&
>> +		package->package.elements[0].integer.value == 1) /* rev 1 */ +
>> +		num = package->package.elements[1].integer.value; +
>> +	kfree(buffer.pointer);
>> +	return num;
>> +}
>> +
>> +/* Notify firmware how many CPUs are idle */
>> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
>> +	uint32_t idle_cpus) +{
>> +	union acpi_object params[3] = {
>> +		{.type = ACPI_TYPE_INTEGER,},
>> +		{.type = ACPI_TYPE_INTEGER,},
>> +		{.type = ACPI_TYPE_BUFFER,},
>> +	};
>> +	struct acpi_object_list arg_list = {3, params};
>> +
>> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
>> +	params[1].integer.value =  stat;
>> +	params[2].buffer.length = 4;
>> +	params[2].buffer.pointer = (void *)&idle_cpus;
>> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL); +}
>> +
>> +static void xen_acpi_pad_handle_notify(acpi_handle handle) +{
>> +	int ret, num_cpus;
>> +
>> +	mutex_lock(&xen_cpu_lock);
>> +	num_cpus = xen_acpi_pad_pur(handle);
>> +	if (num_cpus < 0) {
>> +		mutex_unlock(&xen_cpu_lock);
>> +		return;
>> +	}
>> +
>> +	ret = xen_acpi_pad_idle_cpus(&num_cpus);
>> +	if (ret) {
>> +		mutex_unlock(&xen_cpu_lock);
>> +		return;
>> +	}
>> +
>> +	xen_acpi_pad_ost(handle, 0, num_cpus);
>> +	mutex_unlock(&xen_cpu_lock);
>> +}
>> +
>> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
>> +	void *data) +{
>> +	switch (event) {
>> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
>> +		xen_acpi_pad_handle_notify(handle);
>> +		break;
>> +	default:
>> +		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
>> +		break; +	}
>> +}
>> +
>> +static int xen_acpi_pad_add(struct acpi_device *device) +{
>> +	acpi_status status;
>> +
>> +	strcpy(acpi_device_name(device),
>> ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
>> +	strcpy(acpi_device_class(device),
>> ACPI_PROCESSOR_AGGREGATOR_CLASS); + +	status =
>> acpi_install_notify_handler(device->handle, +		 ACPI_DEVICE_NOTIFY,
>> xen_acpi_pad_notify, device); +	if (ACPI_FAILURE(status)) +		return
>> -ENODEV; + +	return 0;
>> +}
>> +
>> +static int xen_acpi_pad_remove(struct acpi_device *device, +	int
>> type) +{
>> +	int num_cpus = 0;
>> +
>> +	mutex_lock(&xen_cpu_lock);
>> +	xen_acpi_pad_idle_cpus(&num_cpus);
>> +	mutex_unlock(&xen_cpu_lock);
>> +
>> +	acpi_remove_notify_handler(device->handle,
>> +		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
>> +	return 0;
>> +}
>> +
>> +static const struct acpi_device_id xen_pad_device_ids[] = {
>> +	{"ACPI000C", 0}, +	{"", 0},
>> +};
>> +
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +	.name = "xen_processor_aggregator",
>> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +	.ids = xen_pad_device_ids,
>> +	.ops = {
>> +		.add = xen_acpi_pad_add,
>> +		.remove = xen_acpi_pad_remove,
>> +	},
>> +};
>> +
>>  int xen_acpi_pad_init(void)
>>  {
>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> 
> How does that work when the the driver is booted under baremetal?
> Won't it kick out the native ACPI_PROCESSOR_AGGREGATOR_CLASS
> (acpi_pad.c) ? 
> 
> What about if the other ACPI_PROCESSOR_AGGREGATOR_CLASS gets called
> first? Won't this fail?
> 
> Or is the acpi_bus_register_driver smart enough to process more than
> one ACPI bus device?

When driver booted under baremetal, xen_acpi_pad.c would be disabled and native acpi_pad.c logic would work.

Thanks,
Jinsong

> 
>> +	return acpi_bus_register_driver(&xen_acpi_pad_driver); +#else
>>  	return 0;
>> +#endif
>>  }
>> 
>>  void xen_acpi_pad_exit(void)
>>  {
>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>> +	acpi_bus_unregister_driver(&xen_acpi_pad_driver); +#endif
>>  }
>> diff --git a/include/xen/interface/platform.h
>> b/include/xen/interface/platform.h index c168468..56ec72a 100644 ---
>> a/include/xen/interface/platform.h +++
>> b/include/xen/interface/platform.h @@ -297,6 +297,19 @@ struct
>>  xenpf_set_processor_pminfo {  };
>> DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); 
>> 
>> +#define XENPF_core_parking      60
>> +
>> +#define XEN_CORE_PARKING_SET    1
>> +#define XEN_CORE_PARKING_GET    2
>> +struct xenpf_core_parking {
>> +	/* IN variables */
>> +	uint32_t type;
>> +	/* IN variables:  set cpu nums expected to be idled */
>> +	/* OUT variables: get cpu nums actually be idled */ +	uint32_t
>> idle_nums; +};
>> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
>> +
>>  struct xen_platform_op {
>>  	uint32_t cmd;
>>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
>> @@ -312,6 +325,7 @@ struct xen_platform_op {
>>  		struct xenpf_change_freq       change_freq;
>>  		struct xenpf_getidletime       getidletime;
>>  		struct xenpf_set_processor_pminfo set_pminfo;
>> +		struct xenpf_core_parking      core_parking;
>>  		uint8_t                        pad[128];
>>  	} u;
>>  };
>> --
>> 1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 12:01:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 12:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz5RJ-00082G-4N; Sun, 19 Feb 2012 12:00:25 +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 1Rz5RH-00081u-Le
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 12:00:23 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329652687!61933221!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11594 invoked from network); 19 Feb 2012 11:58:08 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Feb 2012 11:58:08 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rz5R9-0008Vp-Q4
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 04:00:15 -0800
Date: Sun, 19 Feb 2012 04:00:15 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329652815801-5496780.post@n5.nabble.com>
In-Reply-To: <20120217160912.GG31531@phenom.dumpdata.com>
References: <1329494799149-5493035.post@n5.nabble.com>
	<20120217160912.GG31531@phenom.dumpdata.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply and sorry for my stupid error.
Now boot but there is xl error on init startup and xl command for libxl*
missing files.
If can help I will post full build log(apparently without error after add 2
patches for solve xl problem with yajl2).


--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5496780.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 12:01:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 12:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz5RJ-00082G-4N; Sun, 19 Feb 2012 12:00:25 +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 1Rz5RH-00081u-Le
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 12:00:23 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329652687!61933221!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11594 invoked from network); 19 Feb 2012 11:58:08 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Feb 2012 11:58:08 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1Rz5R9-0008Vp-Q4
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 04:00:15 -0800
Date: Sun, 19 Feb 2012 04:00:15 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329652815801-5496780.post@n5.nabble.com>
In-Reply-To: <20120217160912.GG31531@phenom.dumpdata.com>
References: <1329494799149-5493035.post@n5.nabble.com>
	<20120217160912.GG31531@phenom.dumpdata.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply and sorry for my stupid error.
Now boot but there is xl error on init startup and xl command for libxl*
missing files.
If can help I will post full build log(apparently without error after add 2
patches for solve xl problem with yajl2).


--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5496780.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 12:15:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 12: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.xensource.com>)
	id 1Rz5fQ-0008Mc-Ow; Sun, 19 Feb 2012 12:15:00 +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 1Rz5fP-0008MX-Rp
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 12:15:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329653644!49865741!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzQ2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22782 invoked from network); 19 Feb 2012 12:14:04 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-27.messagelabs.com with SMTP;
	19 Feb 2012 12:14:04 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 19 Feb 2012 04:14:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127141417"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by fmsmga002.fm.intel.com with ESMTP; 19 Feb 2012 04:14:55 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 19 Feb 2012 20:14:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sun, 19 Feb 2012 20:14:53 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM7YOPqETlTTaR00eoPTQ1GukvM5ZEIKVQ
Date: Sun, 19 Feb 2012 12:14:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
In-Reply-To: <20120217144742.GA29454@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 09:29:09AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
>>>> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00
>>>> 2001 
>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>> Date: Fri, 10 Feb 2012 20:32:50 +0800
>>> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
>>> 
>>> This patch is PAD (Processor Aggregator Device) helper.
>>> It provides a native interface for natvie platform, and a template
>>> for paravirt platform, so that os can implicitly hook to proper ops
>>> accordingly. 
>>> The paravirt template will further redirect to Xen pv ops in later
>>>  patch for Xen core parking.
>> 
>> You need to CC the ACPI maintainer and the acpi mailing on this
>> patch. I did that for you in the CC. 
>> 
>> 
>>> 
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>>  arch/x86/include/asm/paravirt.h       |   10 +++++
>>>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>>>  arch/x86/kernel/paravirt.c            |    9 +++++
>>>  drivers/acpi/acpi_pad.c               |   15 +++-----
>>>  include/acpi/acpi_pad.h               |   61
>>>  +++++++++++++++++++++++++++++++++ 5 files changed, 93
>>>  insertions(+), 9 deletions(-) create mode 100644
>>> include/acpi/acpi_pad.h 
>>> 
>>> diff --git a/arch/x86/include/asm/paravirt.h
>>> b/arch/x86/include/asm/paravirt.h 
>>> index a7d2db9..02e6df0 100644
>>> --- a/arch/x86/include/asm/paravirt.h
>>> +++ b/arch/x86/include/asm/paravirt.h
>>> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>>>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);  }
>>> 
>>> +static inline int __acpi_pad_init(void)
>>> +{
>>> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
>>> +
>>> +static inline void __acpi_pad_exit(void)
>>> +{
>>> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
>>> +}
>>> +
>>>  static inline void write_cr0(unsigned long x)
>>>  {
>>>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
>>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>> b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..61e20de
>>> 100644 --- a/arch/x86/include/asm/paravirt_types.h +++
>>> b/arch/x86/include/asm/paravirt_types.h @@ -336,6 +336,11 @@ struct
>>>  	pv_lock_ops { void (*spin_unlock)(struct arch_spinlock *lock);
>>>  };
>>> 
>>> +struct pv_pad_ops {
>>> +	int (*acpi_pad_init)(void);
>>> +	void (*acpi_pad_exit)(void);
>>> +};
>>> +
> 
> Looking at this a bit closer I am not sure why you choose the paravirt
> interface for this? There is another one - the x86 that could have
> been 
> choosen. Or introduce a new one that is specific to ACPI.
> 
> I am curious - what was the reason for using the paravirt interface?
> I understand it does get the job done, but it seems a bit overkill
> when something simple could have been used?
> 

It uses paravirt interface to avoid some code like 'xen_...' in native code path (acpi_pad.c).
I'm not quite sure what does 'x86' here mean? Adding 2 fields (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops? seems it's much simpler.

Thanks,
Jinsong

>>>  /* This contains all the paravirt structures: we get a convenient
>>>   * number for each function using the offset which we use to
>>> indicate 
>>>   * what to patch. */
>>> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>>>  	struct pv_apic_ops pv_apic_ops;
>>>  	struct pv_mmu_ops pv_mmu_ops;
>>>  	struct pv_lock_ops pv_lock_ops;
>>> +	struct pv_pad_ops pv_pad_ops;
>>>  };
>>> 
>>>  extern struct pv_info pv_info;
>>> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>>>  extern struct pv_apic_ops pv_apic_ops;
>>>  extern struct pv_mmu_ops pv_mmu_ops;
>>>  extern struct pv_lock_ops pv_lock_ops;
>>> +extern struct pv_pad_ops pv_pad_ops;
>>> 
>>>  #define PARAVIRT_PATCH(x)					\
>>>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
>>> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
>>> index d90272e..ec778f6 100644
>>> --- a/arch/x86/kernel/paravirt.c
>>> +++ b/arch/x86/kernel/paravirt.c
>>> @@ -38,6 +38,8 @@
>>>  #include <asm/tlbflush.h>
>>>  #include <asm/timer.h>
>>> 
>>> +#include <acpi/acpi_pad.h>
>>> +
>>>  /* nop stub */
>>>  void _paravirt_nop(void)
>>>  {
>>> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>>>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>>>  		.pv_lock_ops = pv_lock_ops,
>>>  #endif
>>> +		.pv_pad_ops = pv_pad_ops,
>>>  	};
>>>  	return *((void **)&tmpl + type);
>>>  }
>>> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>>>  	.set_fixmap = native_set_fixmap,
>>>  };
>>> 
>>> +struct pv_pad_ops pv_pad_ops = {
>>> +	.acpi_pad_init = native_acpi_pad_init,
>>> +	.acpi_pad_exit = native_acpi_pad_exit,
>>> +};
>>> +
>>>  EXPORT_SYMBOL_GPL(pv_time_ops);
>>>  EXPORT_SYMBOL    (pv_cpu_ops);
>>>  EXPORT_SYMBOL    (pv_mmu_ops);
>>>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>>>  EXPORT_SYMBOL_GPL(pv_info);
>>>  EXPORT_SYMBOL    (pv_irq_ops);
>>> +EXPORT_SYMBOL_GPL(pv_pad_ops);
>>> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
>>> index a43fa1a..3f0fd27 100644
>>> --- a/drivers/acpi/acpi_pad.c
>>> +++ b/drivers/acpi/acpi_pad.c
>>> @@ -30,6 +30,7 @@
>>>  #include <linux/slab.h>
>>>  #include <acpi/acpi_bus.h>
>>>  #include <acpi/acpi_drivers.h>
>>> +#include <acpi/acpi_pad.h>
>>>  #include <asm/mwait.h>
>>> 
>>>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad" @@ -37,14
>>>  +38,14 @@ #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>>>  static DEFINE_MUTEX(isolated_cpus_lock);
>>> 
>>> -static unsigned long power_saving_mwait_eax;
>>> +unsigned long power_saving_mwait_eax;
>>> 
>>>  static unsigned char tsc_detected_unstable;
>>>  static unsigned char tsc_marked_unstable;
>>>  static unsigned char lapic_detected_unstable;
>>>  static unsigned char lapic_marked_unstable;
>>> 
>>> -static void power_saving_mwait_init(void)
>>> +void power_saving_mwait_init(void)
>>>  {
>>>  	unsigned int eax, ebx, ecx, edx;
>>>  	unsigned int highest_cstate = 0;
>>> @@ -500,7 +501,7 @@ static const struct acpi_device_id
>>>  pad_device_ids[] = {  }; MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>>> 
>>> -static struct acpi_driver acpi_pad_driver = {
>>> +struct acpi_driver acpi_pad_driver = {
>>>  	.name = "processor_aggregator",
>>>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>>>  	.ids = pad_device_ids,
>>> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>>> 
>>>  static int __init acpi_pad_init(void)
>>>  {
>>> -	power_saving_mwait_init();
>>> -	if (power_saving_mwait_eax == 0)
>>> -		return -EINVAL;
>>> -
>>> -	return acpi_bus_register_driver(&acpi_pad_driver); +	return
>>>  __acpi_pad_init(); }
>>> 
>>>  static void __exit acpi_pad_exit(void)
>>>  {
>>> -	acpi_bus_unregister_driver(&acpi_pad_driver);
>>> +	__acpi_pad_exit();
>>>  }
>>> 
>>>  module_init(acpi_pad_init);
>>> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
>>> new file mode 100644
>>> index 0000000..1a1471d
>>> --- /dev/null
>>> +++ b/include/acpi/acpi_pad.h
>>> @@ -0,0 +1,61 @@
>>> +/*
>>> + *  acpi_pad.h - pad device helper for native and paravirt
>>> platform + * + *  Copyright (C) 2012, Intel Corporation.
>>> + *     Author: 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.
>>> + */
>>> +
>>> +#ifndef __ACPI_PAD_H__
>>> +#define __ACPI_PAD_H__
>>> +
>>> +#include <acpi/acpi_bus.h>
>>> +
>>> +extern unsigned long power_saving_mwait_eax;
>>> +extern struct acpi_driver acpi_pad_driver;
>>> +extern void power_saving_mwait_init(void);
>>> +
>>> +static inline int native_acpi_pad_init(void)
>>> +{
>>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>>> +	power_saving_mwait_init();
>>> +	if (power_saving_mwait_eax == 0)
>>> +		return -EINVAL;
>>> +
>>> +	return acpi_bus_register_driver(&acpi_pad_driver); +#else
>>> +	return 0;
>>> +#endif
>>> +}
>>> +
>>> +static inline void native_acpi_pad_exit(void)
>>> +{
>>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>>> +	acpi_bus_unregister_driver(&acpi_pad_driver);
>>> +#endif
>>> +}
>>> +
>>> +#ifdef CONFIG_PARAVIRT
>>> +#include <asm/paravirt.h>
>>> +#else
>>> +static inline int __acpi_pad_init(void)
>>> +{
>>> +	return native_acpi_pad_init();
>>> +}
>>> +
>>> +static inline void __acpi_pad_exit(void)
>>> +{
>>> +	native_acpi_pad_exit();
>>> +}
>>> +#endif
>>> +
>>> +#endif /* __ACPI_PAD_H__ */
>>> --
>>> 1.7.1
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 12:15:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 12: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.xensource.com>)
	id 1Rz5fQ-0008Mc-Ow; Sun, 19 Feb 2012 12:15:00 +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 1Rz5fP-0008MX-Rp
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 12:15:00 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329653644!49865741!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwMzQ2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22782 invoked from network); 19 Feb 2012 12:14:04 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-27.messagelabs.com with SMTP;
	19 Feb 2012 12:14:04 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 19 Feb 2012 04:14:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127141417"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by fmsmga002.fm.intel.com with ESMTP; 19 Feb 2012 04:14:55 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 19 Feb 2012 20:14:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sun, 19 Feb 2012 20:14:53 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM7YOPqETlTTaR00eoPTQ1GukvM5ZEIKVQ
Date: Sun, 19 Feb 2012 12:14:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
In-Reply-To: <20120217144742.GA29454@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 09:29:09AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
>>>> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00
>>>> 2001 
>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>> Date: Fri, 10 Feb 2012 20:32:50 +0800
>>> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
>>> 
>>> This patch is PAD (Processor Aggregator Device) helper.
>>> It provides a native interface for natvie platform, and a template
>>> for paravirt platform, so that os can implicitly hook to proper ops
>>> accordingly. 
>>> The paravirt template will further redirect to Xen pv ops in later
>>>  patch for Xen core parking.
>> 
>> You need to CC the ACPI maintainer and the acpi mailing on this
>> patch. I did that for you in the CC. 
>> 
>> 
>>> 
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>>  arch/x86/include/asm/paravirt.h       |   10 +++++
>>>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>>>  arch/x86/kernel/paravirt.c            |    9 +++++
>>>  drivers/acpi/acpi_pad.c               |   15 +++-----
>>>  include/acpi/acpi_pad.h               |   61
>>>  +++++++++++++++++++++++++++++++++ 5 files changed, 93
>>>  insertions(+), 9 deletions(-) create mode 100644
>>> include/acpi/acpi_pad.h 
>>> 
>>> diff --git a/arch/x86/include/asm/paravirt.h
>>> b/arch/x86/include/asm/paravirt.h 
>>> index a7d2db9..02e6df0 100644
>>> --- a/arch/x86/include/asm/paravirt.h
>>> +++ b/arch/x86/include/asm/paravirt.h
>>> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>>>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);  }
>>> 
>>> +static inline int __acpi_pad_init(void)
>>> +{
>>> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
>>> +
>>> +static inline void __acpi_pad_exit(void)
>>> +{
>>> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
>>> +}
>>> +
>>>  static inline void write_cr0(unsigned long x)
>>>  {
>>>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
>>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>> b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..61e20de
>>> 100644 --- a/arch/x86/include/asm/paravirt_types.h +++
>>> b/arch/x86/include/asm/paravirt_types.h @@ -336,6 +336,11 @@ struct
>>>  	pv_lock_ops { void (*spin_unlock)(struct arch_spinlock *lock);
>>>  };
>>> 
>>> +struct pv_pad_ops {
>>> +	int (*acpi_pad_init)(void);
>>> +	void (*acpi_pad_exit)(void);
>>> +};
>>> +
> 
> Looking at this a bit closer I am not sure why you choose the paravirt
> interface for this? There is another one - the x86 that could have
> been 
> choosen. Or introduce a new one that is specific to ACPI.
> 
> I am curious - what was the reason for using the paravirt interface?
> I understand it does get the job done, but it seems a bit overkill
> when something simple could have been used?
> 

It uses paravirt interface to avoid some code like 'xen_...' in native code path (acpi_pad.c).
I'm not quite sure what does 'x86' here mean? Adding 2 fields (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops? seems it's much simpler.

Thanks,
Jinsong

>>>  /* This contains all the paravirt structures: we get a convenient
>>>   * number for each function using the offset which we use to
>>> indicate 
>>>   * what to patch. */
>>> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>>>  	struct pv_apic_ops pv_apic_ops;
>>>  	struct pv_mmu_ops pv_mmu_ops;
>>>  	struct pv_lock_ops pv_lock_ops;
>>> +	struct pv_pad_ops pv_pad_ops;
>>>  };
>>> 
>>>  extern struct pv_info pv_info;
>>> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>>>  extern struct pv_apic_ops pv_apic_ops;
>>>  extern struct pv_mmu_ops pv_mmu_ops;
>>>  extern struct pv_lock_ops pv_lock_ops;
>>> +extern struct pv_pad_ops pv_pad_ops;
>>> 
>>>  #define PARAVIRT_PATCH(x)					\
>>>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
>>> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
>>> index d90272e..ec778f6 100644
>>> --- a/arch/x86/kernel/paravirt.c
>>> +++ b/arch/x86/kernel/paravirt.c
>>> @@ -38,6 +38,8 @@
>>>  #include <asm/tlbflush.h>
>>>  #include <asm/timer.h>
>>> 
>>> +#include <acpi/acpi_pad.h>
>>> +
>>>  /* nop stub */
>>>  void _paravirt_nop(void)
>>>  {
>>> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>>>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>>>  		.pv_lock_ops = pv_lock_ops,
>>>  #endif
>>> +		.pv_pad_ops = pv_pad_ops,
>>>  	};
>>>  	return *((void **)&tmpl + type);
>>>  }
>>> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>>>  	.set_fixmap = native_set_fixmap,
>>>  };
>>> 
>>> +struct pv_pad_ops pv_pad_ops = {
>>> +	.acpi_pad_init = native_acpi_pad_init,
>>> +	.acpi_pad_exit = native_acpi_pad_exit,
>>> +};
>>> +
>>>  EXPORT_SYMBOL_GPL(pv_time_ops);
>>>  EXPORT_SYMBOL    (pv_cpu_ops);
>>>  EXPORT_SYMBOL    (pv_mmu_ops);
>>>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>>>  EXPORT_SYMBOL_GPL(pv_info);
>>>  EXPORT_SYMBOL    (pv_irq_ops);
>>> +EXPORT_SYMBOL_GPL(pv_pad_ops);
>>> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
>>> index a43fa1a..3f0fd27 100644
>>> --- a/drivers/acpi/acpi_pad.c
>>> +++ b/drivers/acpi/acpi_pad.c
>>> @@ -30,6 +30,7 @@
>>>  #include <linux/slab.h>
>>>  #include <acpi/acpi_bus.h>
>>>  #include <acpi/acpi_drivers.h>
>>> +#include <acpi/acpi_pad.h>
>>>  #include <asm/mwait.h>
>>> 
>>>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad" @@ -37,14
>>>  +38,14 @@ #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>>>  static DEFINE_MUTEX(isolated_cpus_lock);
>>> 
>>> -static unsigned long power_saving_mwait_eax;
>>> +unsigned long power_saving_mwait_eax;
>>> 
>>>  static unsigned char tsc_detected_unstable;
>>>  static unsigned char tsc_marked_unstable;
>>>  static unsigned char lapic_detected_unstable;
>>>  static unsigned char lapic_marked_unstable;
>>> 
>>> -static void power_saving_mwait_init(void)
>>> +void power_saving_mwait_init(void)
>>>  {
>>>  	unsigned int eax, ebx, ecx, edx;
>>>  	unsigned int highest_cstate = 0;
>>> @@ -500,7 +501,7 @@ static const struct acpi_device_id
>>>  pad_device_ids[] = {  }; MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>>> 
>>> -static struct acpi_driver acpi_pad_driver = {
>>> +struct acpi_driver acpi_pad_driver = {
>>>  	.name = "processor_aggregator",
>>>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>>>  	.ids = pad_device_ids,
>>> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>>> 
>>>  static int __init acpi_pad_init(void)
>>>  {
>>> -	power_saving_mwait_init();
>>> -	if (power_saving_mwait_eax == 0)
>>> -		return -EINVAL;
>>> -
>>> -	return acpi_bus_register_driver(&acpi_pad_driver); +	return
>>>  __acpi_pad_init(); }
>>> 
>>>  static void __exit acpi_pad_exit(void)
>>>  {
>>> -	acpi_bus_unregister_driver(&acpi_pad_driver);
>>> +	__acpi_pad_exit();
>>>  }
>>> 
>>>  module_init(acpi_pad_init);
>>> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
>>> new file mode 100644
>>> index 0000000..1a1471d
>>> --- /dev/null
>>> +++ b/include/acpi/acpi_pad.h
>>> @@ -0,0 +1,61 @@
>>> +/*
>>> + *  acpi_pad.h - pad device helper for native and paravirt
>>> platform + * + *  Copyright (C) 2012, Intel Corporation.
>>> + *     Author: 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.
>>> + */
>>> +
>>> +#ifndef __ACPI_PAD_H__
>>> +#define __ACPI_PAD_H__
>>> +
>>> +#include <acpi/acpi_bus.h>
>>> +
>>> +extern unsigned long power_saving_mwait_eax;
>>> +extern struct acpi_driver acpi_pad_driver;
>>> +extern void power_saving_mwait_init(void);
>>> +
>>> +static inline int native_acpi_pad_init(void)
>>> +{
>>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>>> +	power_saving_mwait_init();
>>> +	if (power_saving_mwait_eax == 0)
>>> +		return -EINVAL;
>>> +
>>> +	return acpi_bus_register_driver(&acpi_pad_driver); +#else
>>> +	return 0;
>>> +#endif
>>> +}
>>> +
>>> +static inline void native_acpi_pad_exit(void)
>>> +{
>>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>>> +	acpi_bus_unregister_driver(&acpi_pad_driver);
>>> +#endif
>>> +}
>>> +
>>> +#ifdef CONFIG_PARAVIRT
>>> +#include <asm/paravirt.h>
>>> +#else
>>> +static inline int __acpi_pad_init(void)
>>> +{
>>> +	return native_acpi_pad_init();
>>> +}
>>> +
>>> +static inline void __acpi_pad_exit(void)
>>> +{
>>> +	native_acpi_pad_exit();
>>> +}
>>> +#endif
>>> +
>>> +#endif /* __ACPI_PAD_H__ */
>>> --
>>> 1.7.1
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 12:38:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 12: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.xensource.com>)
	id 1Rz61k-0000Cy-DV; Sun, 19 Feb 2012 12:38:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <19890121wr@gmail.com>) id 1Rz61g-0000Cq-Qj
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 12:38:02 +0000
Received: from [85.158.139.83:32053] by server-6.bemta-5.messagelabs.com id
	54/B3-27305-82DE04F4; Sun, 19 Feb 2012 12:38:00 +0000
X-Env-Sender: 19890121wr@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329655077!15684071!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.0 required=7.0 tests=FROM_STARTS_WITH_NUMS,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19675 invoked from network); 19 Feb 2012 12:37:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 12:37:59 -0000
Received: by pbbro2 with SMTP id ro2so38751295pbb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 04:37:57 -0800 (PST)
Received-SPF: pass (google.com: domain of 19890121wr@gmail.com designates
	10.68.237.232 as permitted sender) client-ip=10.68.237.232; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of 19890121wr@gmail.com
	designates 10.68.237.232 as permitted sender)
	smtp.mail=19890121wr@gmail.com;
	dkim=pass header.i=19890121wr@gmail.com
Received: from mr.google.com ([10.68.237.232])
	by 10.68.237.232 with SMTP id vf8mr32435882pbc.50.1329655077478
	(num_hops = 1); Sun, 19 Feb 2012 04:37:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=DWSLBxzaUJRjK0sV4XMLSaJ3yDpD7EctczEPXFprDyI=;
	b=wsfUeM52pKrJRUTSei5qzRprx6P888ihfl3sjnrdtIqQuH66PhRoNF+Oc2f7KfiS53
	2xy7Jl0SF64k5dIjCvD4bmUrY/NmxyjfUwcqu4eRicogNTl0G+kFuF1XVDFJCTrHTKJ9
	FdjXD2lq9L2UmEaDGU0M/5uG0hAsn1b2OHmdo=
MIME-Version: 1.0
Received: by 10.68.237.232 with SMTP id vf8mr26820524pbc.50.1329655077453;
	Sun, 19 Feb 2012 04:37:57 -0800 (PST)
Received: by 10.142.135.4 with HTTP; Sun, 19 Feb 2012 04:37:57 -0800 (PST)
Date: Sun, 19 Feb 2012 20:37:57 +0800
Message-ID: <CAF2sySO6-g2F4xQ+CCu4QxOUBGjg34F5snSXnVCQ6QPchVjvsA@mail.gmail.com>
From: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Questions about page table updating
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, everyone
            I am newbie here. And now I am trying to understand about
Xen's memory management.
            When a Guest VM try to modify its page table. How does Xen
handle that?
            In PV it seems like Guest VM will use a hypercall
do_update_va_mapping or do_mmu_update. What's the difference?
            How about HVM
            Thanks for answering.

R

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 12:38:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 12: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.xensource.com>)
	id 1Rz61k-0000Cy-DV; Sun, 19 Feb 2012 12:38:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <19890121wr@gmail.com>) id 1Rz61g-0000Cq-Qj
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 12:38:02 +0000
Received: from [85.158.139.83:32053] by server-6.bemta-5.messagelabs.com id
	54/B3-27305-82DE04F4; Sun, 19 Feb 2012 12:38:00 +0000
X-Env-Sender: 19890121wr@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329655077!15684071!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.0 required=7.0 tests=FROM_STARTS_WITH_NUMS,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19675 invoked from network); 19 Feb 2012 12:37:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 12:37:59 -0000
Received: by pbbro2 with SMTP id ro2so38751295pbb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 04:37:57 -0800 (PST)
Received-SPF: pass (google.com: domain of 19890121wr@gmail.com designates
	10.68.237.232 as permitted sender) client-ip=10.68.237.232; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of 19890121wr@gmail.com
	designates 10.68.237.232 as permitted sender)
	smtp.mail=19890121wr@gmail.com;
	dkim=pass header.i=19890121wr@gmail.com
Received: from mr.google.com ([10.68.237.232])
	by 10.68.237.232 with SMTP id vf8mr32435882pbc.50.1329655077478
	(num_hops = 1); Sun, 19 Feb 2012 04:37:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=DWSLBxzaUJRjK0sV4XMLSaJ3yDpD7EctczEPXFprDyI=;
	b=wsfUeM52pKrJRUTSei5qzRprx6P888ihfl3sjnrdtIqQuH66PhRoNF+Oc2f7KfiS53
	2xy7Jl0SF64k5dIjCvD4bmUrY/NmxyjfUwcqu4eRicogNTl0G+kFuF1XVDFJCTrHTKJ9
	FdjXD2lq9L2UmEaDGU0M/5uG0hAsn1b2OHmdo=
MIME-Version: 1.0
Received: by 10.68.237.232 with SMTP id vf8mr26820524pbc.50.1329655077453;
	Sun, 19 Feb 2012 04:37:57 -0800 (PST)
Received: by 10.142.135.4 with HTTP; Sun, 19 Feb 2012 04:37:57 -0800 (PST)
Date: Sun, 19 Feb 2012 20:37:57 +0800
Message-ID: <CAF2sySO6-g2F4xQ+CCu4QxOUBGjg34F5snSXnVCQ6QPchVjvsA@mail.gmail.com>
From: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Questions about page table updating
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, everyone
            I am newbie here. And now I am trying to understand about
Xen's memory management.
            When a Guest VM try to modify its page table. How does Xen
handle that?
            In PV it seems like Guest VM will use a hypercall
do_update_va_mapping or do_mmu_update. What's the difference?
            How about HVM
            Thanks for answering.

R

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 13:19:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 13:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz6fK-0000hZ-GY; Sun, 19 Feb 2012 13:18:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <young.zhang.free@gmail.com>) id 1Rz6fI-0000hF-GA
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 13:18:56 +0000
X-Env-Sender: young.zhang.free@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329657510!64107170!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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26265 invoked from network); 19 Feb 2012 13:18:32 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 13:18:32 -0000
Received: by pbbro2 with SMTP id ro2so38943641pbb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 05:18:53 -0800 (PST)
Received-SPF: pass (google.com: domain of young.zhang.free@gmail.com
	designates 10.68.231.134 as permitted sender)
	client-ip=10.68.231.134; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	young.zhang.free@gmail.com designates 10.68.231.134 as
	permitted sender) smtp.mail=young.zhang.free@gmail.com;
	dkim=pass header.i=young.zhang.free@gmail.com
Received: from mr.google.com ([10.68.231.134])
	by 10.68.231.134 with SMTP id tg6mr41781979pbc.115.1329657533261
	(num_hops = 1); Sun, 19 Feb 2012 05:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=5FeL/fQ6GPvBlHc4QepUN7ZgumnS3Qa56YyNdythI6I=;
	b=E6CQkkXsv3usYqldOa/iAufOQ3Mpfcdh9GhMo4D58ltPR7Ar59/qdJKG6vJDyLF7yt
	duKbZA6BgZvQe4y2Q0RZP0nN9lrxSiCpSK0EDucfoiLwSJT2QODnTgFJN/YTxKL79PLL
	un77qEQem2mdVd0wuPTp0AM5/IhSpB/f17qc8=
MIME-Version: 1.0
Received: by 10.68.231.134 with SMTP id tg6mr34428439pbc.115.1329657533065;
	Sun, 19 Feb 2012 05:18:53 -0800 (PST)
Received: by 10.68.229.168 with HTTP; Sun, 19 Feb 2012 05:18:53 -0800 (PST)
In-Reply-To: <CAF2sySO6-g2F4xQ+CCu4QxOUBGjg34F5snSXnVCQ6QPchVjvsA@mail.gmail.com>
References: <CAF2sySO6-g2F4xQ+CCu4QxOUBGjg34F5snSXnVCQ6QPchVjvsA@mail.gmail.com>
Date: Sun, 19 Feb 2012 21:18:53 +0800
Message-ID: <CABaSDNjh0gbZLEgg0G7OeM_pmsNjj0DbdN3X2O3awP8Hha6JLg@mail.gmail.com>
From: young zhang <young.zhang.free@gmail.com>
To: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about page table updating
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Q3VycmVudGx5LCB0aGVyZSBoYXZlIHR3byB0eXBlcyBvZiB3YXkgdG8gbWFuYWdlIGd1ZXN0IG1l
bW9yeTogb25lIGlzCnVzaW5nIGhhcmR3YXJlIGFzc2lzdCBwYWdpbmcgd2hpY2gga25vd24gYXMg
RVBULCBhbmQgZm9yIHRob3NlIENQVQp3aGljaCBub3Qgc3VwcG9udCBFUFQsIHhlbiB1c2Ugc2hh
ZG93IHBhZ2UgdGFibGUuIFlvdSBjYW4gZ29vZ2xlIHRoZW0KdG8gZ2V0IG1vcmUgZGV0YWlsLgoK
MjAxMi8yLzE5LCDO4sjxIDwxOTg5MDEyMXdyQGdtYWlsLmNvbT46Cj4gSGksIGV2ZXJ5b25lCj4g
ICAgICAgICAgICAgSSBhbSBuZXdiaWUgaGVyZS4gQW5kIG5vdyBJIGFtIHRyeWluZyB0byB1bmRl
cnN0YW5kIGFib3V0Cj4gWGVuJ3MgbWVtb3J5IG1hbmFnZW1lbnQuCj4gICAgICAgICAgICAgV2hl
biBhIEd1ZXN0IFZNIHRyeSB0byBtb2RpZnkgaXRzIHBhZ2UgdGFibGUuIEhvdyBkb2VzIFhlbgo+
IGhhbmRsZSB0aGF0Pwo+ICAgICAgICAgICAgIEluIFBWIGl0IHNlZW1zIGxpa2UgR3Vlc3QgVk0g
d2lsbCB1c2UgYSBoeXBlcmNhbGwKPiBkb191cGRhdGVfdmFfbWFwcGluZyBvciBkb19tbXVfdXBk
YXRlLiBXaGF0J3MgdGhlIGRpZmZlcmVuY2U/Cj4gICAgICAgICAgICAgSG93IGFib3V0IEhWTQo+
ICAgICAgICAgICAgIFRoYW5rcyBmb3IgYW5zd2VyaW5nLgo+Cj4gUgo+Cj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwKPgoKCi0tIAp5b3VuZwoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Sun Feb 19 13:19:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 13:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz6fK-0000hZ-GY; Sun, 19 Feb 2012 13:18:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <young.zhang.free@gmail.com>) id 1Rz6fI-0000hF-GA
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 13:18:56 +0000
X-Env-Sender: young.zhang.free@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329657510!64107170!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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26265 invoked from network); 19 Feb 2012 13:18:32 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 13:18:32 -0000
Received: by pbbro2 with SMTP id ro2so38943641pbb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 05:18:53 -0800 (PST)
Received-SPF: pass (google.com: domain of young.zhang.free@gmail.com
	designates 10.68.231.134 as permitted sender)
	client-ip=10.68.231.134; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	young.zhang.free@gmail.com designates 10.68.231.134 as
	permitted sender) smtp.mail=young.zhang.free@gmail.com;
	dkim=pass header.i=young.zhang.free@gmail.com
Received: from mr.google.com ([10.68.231.134])
	by 10.68.231.134 with SMTP id tg6mr41781979pbc.115.1329657533261
	(num_hops = 1); Sun, 19 Feb 2012 05:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=5FeL/fQ6GPvBlHc4QepUN7ZgumnS3Qa56YyNdythI6I=;
	b=E6CQkkXsv3usYqldOa/iAufOQ3Mpfcdh9GhMo4D58ltPR7Ar59/qdJKG6vJDyLF7yt
	duKbZA6BgZvQe4y2Q0RZP0nN9lrxSiCpSK0EDucfoiLwSJT2QODnTgFJN/YTxKL79PLL
	un77qEQem2mdVd0wuPTp0AM5/IhSpB/f17qc8=
MIME-Version: 1.0
Received: by 10.68.231.134 with SMTP id tg6mr34428439pbc.115.1329657533065;
	Sun, 19 Feb 2012 05:18:53 -0800 (PST)
Received: by 10.68.229.168 with HTTP; Sun, 19 Feb 2012 05:18:53 -0800 (PST)
In-Reply-To: <CAF2sySO6-g2F4xQ+CCu4QxOUBGjg34F5snSXnVCQ6QPchVjvsA@mail.gmail.com>
References: <CAF2sySO6-g2F4xQ+CCu4QxOUBGjg34F5snSXnVCQ6QPchVjvsA@mail.gmail.com>
Date: Sun, 19 Feb 2012 21:18:53 +0800
Message-ID: <CABaSDNjh0gbZLEgg0G7OeM_pmsNjj0DbdN3X2O3awP8Hha6JLg@mail.gmail.com>
From: young zhang <young.zhang.free@gmail.com>
To: =?GB2312?B?zuLI8Q==?= <19890121wr@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about page table updating
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Q3VycmVudGx5LCB0aGVyZSBoYXZlIHR3byB0eXBlcyBvZiB3YXkgdG8gbWFuYWdlIGd1ZXN0IG1l
bW9yeTogb25lIGlzCnVzaW5nIGhhcmR3YXJlIGFzc2lzdCBwYWdpbmcgd2hpY2gga25vd24gYXMg
RVBULCBhbmQgZm9yIHRob3NlIENQVQp3aGljaCBub3Qgc3VwcG9udCBFUFQsIHhlbiB1c2Ugc2hh
ZG93IHBhZ2UgdGFibGUuIFlvdSBjYW4gZ29vZ2xlIHRoZW0KdG8gZ2V0IG1vcmUgZGV0YWlsLgoK
MjAxMi8yLzE5LCDO4sjxIDwxOTg5MDEyMXdyQGdtYWlsLmNvbT46Cj4gSGksIGV2ZXJ5b25lCj4g
ICAgICAgICAgICAgSSBhbSBuZXdiaWUgaGVyZS4gQW5kIG5vdyBJIGFtIHRyeWluZyB0byB1bmRl
cnN0YW5kIGFib3V0Cj4gWGVuJ3MgbWVtb3J5IG1hbmFnZW1lbnQuCj4gICAgICAgICAgICAgV2hl
biBhIEd1ZXN0IFZNIHRyeSB0byBtb2RpZnkgaXRzIHBhZ2UgdGFibGUuIEhvdyBkb2VzIFhlbgo+
IGhhbmRsZSB0aGF0Pwo+ICAgICAgICAgICAgIEluIFBWIGl0IHNlZW1zIGxpa2UgR3Vlc3QgVk0g
d2lsbCB1c2UgYSBoeXBlcmNhbGwKPiBkb191cGRhdGVfdmFfbWFwcGluZyBvciBkb19tbXVfdXBk
YXRlLiBXaGF0J3MgdGhlIGRpZmZlcmVuY2U/Cj4gICAgICAgICAgICAgSG93IGFib3V0IEhWTQo+
ICAgICAgICAgICAgIFRoYW5rcyBmb3IgYW5zd2VyaW5nLgo+Cj4gUgo+Cj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwKPgoKCi0tIAp5b3VuZwoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Sun Feb 19 13:33:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 13:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz6sV-00017z-SJ; Sun, 19 Feb 2012 13:32:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rz6sU-00017q-Gd
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 13:32:35 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329658346!15409546!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17005 invoked from network); 19 Feb 2012 13:32:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	19 Feb 2012 13:32:27 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1JDWIGW007745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 08:32:18 -0500
Received: from redhat.com (vpn-200-7.tlv.redhat.com [10.35.200.7])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1JDWC8c012480; Sun, 19 Feb 2012 08:32:13 -0500
Date: Sun, 19 Feb 2012 15:32:20 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120219133219.GA16160@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
 PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:08:42PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen_pci_passthrough.c             |   10 +
>  hw/xen_pci_passthrough.h             |    2 +
>  hw/xen_pci_passthrough_config_init.c | 1431 ++++++++++++++++++++++++++++++++++
>  3 files changed, 1443 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 3f305dd..26a3bdd 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
>      /* Handle real device's MMIO/PIO BARs */
>      pt_register_regions(s);
>  
> +    /* reinitialize each config register to be emulated */
> +    if (pt_config_init(s)) {
> +        PT_ERR(d, "PCI Config space initialisation failed.\n");
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
>      /* Bind interrupt */
>      if (!s->dev.config[PCI_INTERRUPT_PIN]) {
>          PT_LOG(d, "no pin interrupt\n");
> @@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
>          }
>      }
>  
> +    /* delete all emulated config registers */
> +    pt_config_delete(s);
> +
>      /* unregister real device's MMIO/PIO BARs */
>      pt_unregister_regions(s);
>  
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index ea6719c..7ebc793 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -61,6 +61,8 @@ typedef int (*conf_byte_read)
>  #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
>  #define PT_PCI_BAR_UNMAPPED (-1)
>  
> +#define PCI_CAP_MAX 48
> +
>  
>  typedef enum {
>      GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index 1e9de64..f1fffd1 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1,11 +1,1442 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include "qemu-timer.h"
> +#include "xen_backend.h"
>  #include "xen_pci_passthrough.h"
>  
> +#define PT_MERGE_VALUE(value, data, val_mask) \
> +    (((value) & (val_mask)) | ((data) & ~(val_mask)))
> +
> +#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
> +
> +/* prototype */
> +
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data);
> +
> +
> +/* helper */
> +
> +/* A return value of 1 means the capability should NOT be exposed to guest. */
> +static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
> +{
> +    switch (grp_id) {
> +    case PCI_CAP_ID_EXP:
> +        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0. We should not try to expose it to guest.
> +         *
> +         * The datasheet is available at
> +         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
> +         *
> +         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
> +         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0, so the Capability Version is 0 and
> +         * pt_pcie_size_init() would fail.
> +         */
> +        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
> +            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
> +            return 1;
> +        }
> +        break;
> +    }
> +    return 0;
> +}
> +
> +/*   find emulate register group entry */
>  XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
>  {
> +    XenPTRegGroup *entry = NULL;
> +
> +    /* find register group entry */
> +    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
> +        /* check address */
> +        if ((entry->base_offset <= address)
> +            && ((entry->base_offset + entry->size) > address)) {
> +            return entry;
> +        }
> +    }
> +
> +    /* group entry not found */
>      return NULL;
>  }
>  
> +/* find emulate register entry */
>  XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
>  {
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +
> +    /* find register entry */
> +    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
> +        reg = reg_entry->reg;
> +        real_offset = reg_grp->base_offset + reg->offset;
> +        /* check address */
> +        if ((real_offset <= address)
> +            && ((real_offset + reg->size) > address)) {
> +            return reg_entry;
> +        }
> +    }
> +
>      return NULL;
>  }
> +
> +/* parse BAR */
> +static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTRegion *region = NULL;
> +    PCIIORegion *r;
> +    int index = 0;
> +
> +    /* check 64bit BAR */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if ((0 < index) && (index < PCI_ROM_SLOT)) {
> +        int flags = s->real_device->io_regions[index - 1].flags;
> +
> +        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
> +            region = &s->bases[index - 1];
> +            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
> +                return PT_BAR_FLAG_UPPER;
> +            }
> +        }
> +    }
> +
> +    /* check unused BAR */
> +    r = &d->io_regions[index];
> +    if (r->size == 0) {
> +        return PT_BAR_FLAG_UNUSED;
> +    }
> +
> +    /* for ExpROM BAR */
> +    if (index == PCI_ROM_SLOT) {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +
> +    /* check BAR I/O indicator */
> +    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
> +        return PT_BAR_FLAG_IO;
> +    } else {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +}
> +
> +
> +/****************
> + * general register functions
> + */
> +
> +/* register initialization function */
> +
> +static int pt_common_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = reg->init_val;
> +    return 0;
> +}
> +
> +/* Read register functions */
> +
> +static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint8_t *value, uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t valid_emu_mask = 0;
> +
> +    /* emulate byte register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +
> +    /* emulate word register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +
> +    /* emulate long register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +
> +/* Write register functions */
> +
> +static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint8_t *value, uint8_t dev_value,
> +                             uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t writable_mask = 0;
> +    uint8_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t dev_value,
> +                             uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint32_t *value, uint32_t dev_value,
> +                             uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/********************
> + * Header Type0
> + */
> +
> +static int pt_vendor_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->vendor_id;
> +    return 0;
> +}
> +static int pt_device_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->device_id;
> +    return 0;
> +}
> +static int pt_status_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t reg_field = 0;
> +
> +    /* find Header register group */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
> +    if (reg_grp_entry) {
> +        /* find Capabilities Pointer register */
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
> +        if (reg_entry) {
> +            /* check Capabilities Pointer register */
> +            if (reg_entry->data) {
> +                reg_field |= PCI_STATUS_CAP_LIST;
> +            } else {
> +                reg_field &= ~PCI_STATUS_CAP_LIST;
> +            }
> +        } else {
> +            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
> +                                     " for Capabilities Pointer register."
> +                                     " (%s)\n", __func__);
> +            return -1;
> +        }
> +    } else {
> +        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
> +                                 " for Header. (%s)\n", __func__);
> +        return -1;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_header_type_reg_init(XenPCIPassthroughState *s,
> +                                   XenPTRegInfo *reg, uint32_t real_offset,
> +                                   uint32_t *data)
> +{
> +    /* read PCI_HEADER_TYPE */
> +    *data = reg->init_val | 0x80;
> +    return 0;
> +}
> +
> +/* initialize Interrupt Pin register */
> +static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = pci_read_intx(s);
> +    return 0;
> +}
> +
> +/* Command register */
> +static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* emulate word register */
> +    valid_emu_mask = emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t dev_value,
> +                            uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t wr_value = *value;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +
> +    if (*value & PCI_COMMAND_INTX_DISABLE) {
> +        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        if (s->machine_irq) {
> +            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +        }
> +    }
> +
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
> +                   wr_value & PCI_COMMAND_MEMORY);
> +

IMO this is a wrong way to do this. It completely ignores
things like bridge filtering memory accesses.

The right time to update your mappings is I think
when pci_update_mappings is called.
The memory API which that should have enough hooks for you I think,
at least it seems sufficient for device assignment on kvm.
I don't know much about how well it works for Xen,
worst-case, if absolutely necessary, we could
re-add the ->map call for devices.



> +    return 0;
> +}
> +
> +/* BAR */
> +#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
> +#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
> +#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
> +#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
> +
> +static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
> +{
> +    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
> +    } else {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
> +    }
> +}
> +
> +static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    int index;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
> +
> +    /* set BAR flag */
> +    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
> +        reg_field = PT_INVALID_REG;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use fixed-up value from kernel sysfs */
> +    *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* emulate BAR */
> +    valid_emu_mask = bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t dev_value,
> +                            uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = &s->dev;
> +    const PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +    uint32_t r_size = 0;
> +    int index = 0;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    r = &d->io_regions[index];
> +    base = &s->bases[index];
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    /* set emulate mask and read-only mask values depend on the BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* check whether we need to update the virtual region address or not */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        if (cfg_entry->data) {
> +            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
> +                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
> +                        "Ignore mapping. "
> +                        "(offset: 0x%02x, high address: 0x%08x)\n",
> +                        reg->offset, cfg_entry->data);
> +            }
> +        }
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* write Exp ROM BAR */
> +static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
> +                                    XenPTReg *cfg_entry, uint32_t *value,
> +                                    uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = (PCIDevice *)&s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    pcibus_t r_size = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +
> +    r = &d->io_regions[PCI_ROM_SLOT];
> +    r_size = r->size;
> +    base = &s->bases[PCI_ROM_SLOT];
> +    /* align memory type resource size */
> +    pt_get_emul_size(base->bar_flag, r_size);
> +
> +    /* set emulate mask and read-only mask */
> +    bar_emu_mask = reg->emu_mask;
> +    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
> +
> +    /* modify emulate register */
> +    writable_mask = ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR*/
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, PCI_ROM_SLOT,
> +                               reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* Header Type0 reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_VENDOR_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_vendor_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device ID reg */
> +    {
> +        .offset     = PCI_DEVICE_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_device_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Command reg */
> +    {
> +        .offset     = PCI_COMMAND,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xF880,
> +        .emu_mask   = 0x0740,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_cmd_reg_read,
> +        .u.w.write  = pt_cmd_reg_write,
> +    },
> +    /* Capabilities Pointer reg */
> +    {
> +        .offset     = PCI_CAPABILITY_LIST,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Status reg */
> +    /* use emulated Cap Ptr value to initialize,
> +     * so need to be declared after Cap Ptr reg
> +     */
> +    {
> +        .offset     = PCI_STATUS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x06FF,
> +        .emu_mask   = 0x0010,
> +        .init       = pt_status_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Cache Line Size reg */
> +    {
> +        .offset     = PCI_CACHE_LINE_SIZE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Latency Timer reg */
> +    {
> +        .offset     = PCI_LATENCY_TIMER,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Header Type reg */
> +    {
> +        .offset     = PCI_HEADER_TYPE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0x00,
> +        .init       = pt_header_type_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Line reg */
> +    {
> +        .offset     = PCI_INTERRUPT_LINE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Pin reg */
> +    {
> +        .offset     = PCI_INTERRUPT_PIN,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_irqpin_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* BAR 0 reg */
> +    /* mask of BAR need to be decided later, depends on IO/MEM type */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_0,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 1 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_1,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 2 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_2,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 3 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_3,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 4 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_4,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 5 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_5,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* Expansion ROM BAR reg */
> +    {
> +        .offset     = PCI_ROM_ADDRESS,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x000007FE,
> +        .emu_mask   = 0xFFFFF800,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_exp_rom_bar_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Vital Product Data Capability
> + */
> +
> +/* Vital Product Data Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * Vendor Specific Capability
> + */
> +
> +/* Vendor Specific Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*****************************
> + * PCI Express Capability
> + */
> +
> +static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
> +                                             uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return flags & PCI_EXP_FLAGS_VERS;
> +}
> +
> +static inline uint8_t get_device_type(XenPCIPassthroughState *s,
> +                                      uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
> +}
> +
> +/* initialize Link Control register */
> +static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of Root Complex Integrated Endpoint
> +     * with cap_ver 1.x
> +     */
> +    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Device Control 2 register */
> +static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Link Control 2 register */
> +static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint32_t reg_field = 0;
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        reg_field = PT_INVALID_REG;
> +    } else {
> +        /* set Supported Link Speed */
> +        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                                      + PCI_EXP_LNKCAP);
> +        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +/* PCI Express Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Device Capabilities reg */
> +    {
> +        .offset     = PCI_EXP_DEVCAP,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x1FFCFFFF,
> +        .emu_mask   = 0x10000000,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_long_reg_write,
> +    },
> +    /* Device Control reg */
> +    {
> +        .offset     = PCI_EXP_DEVCTL,
> +        .size       = 2,
> +        .init_val   = 0x2810,
> +        .ro_mask    = 0x8400,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control reg */
> +    {
> +        .offset     = PCI_EXP_LNKCTL,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFC34,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device Control 2 reg */
> +    {
> +        .offset     = 0x28,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFE0,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_devctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control 2 reg */
> +    {
> +        .offset     = 0x30,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xE040,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Power Management Capability
> + */
> +
> +/* read Power Management Control/Status register */
> +static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = reg->emu_mask;
> +
> +    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    valid_emu_mask = valid_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +/* write Power Management Control/Status register */
> +static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint16_t *value, uint16_t dev_value,
> +                              uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t emu_mask = reg->emu_mask;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    /* modify emulate register */
> +    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +/* Power Management Capability reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Power Management Capabilities reg */
> +    {
> +        .offset     = PCI_CAP_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xF9C8,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* PCI Power Management Control/Status reg */
> +    {
> +        .offset     = PCI_PM_CTRL,
> +        .size       = 2,
> +        .init_val   = 0x0008,
> +        .ro_mask    = 0xE1FC,
> +        .emu_mask   = 0x8100,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_pmcsr_reg_read,
> +        .u.w.write  = pt_pmcsr_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/****************************
> + * Capabilities
> + */
> +
> +/* capability structure register group size functions */
> +
> +static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
> +                                const XenPTRegGroupInfo *grp_reg,
> +                                uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +/* get Vendor Specific Capability Structure register group size */
> +static int pt_vendor_size_init(XenPCIPassthroughState *s,
> +                               const XenPTRegGroupInfo *grp_reg,
> +                               uint32_t base_offset, uint8_t *size)
> +{
> +    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
> +    return 0;
> +}
> +/* get PCI Express Capability Structure register group size */
> +static int pt_pcie_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t version = get_capability_version(s, base_offset);
> +    uint8_t type = get_device_type(s, base_offset);
> +    uint8_t pcie_size = 0;
> +
> +
> +    /* calculate size depend on capability version and device/port type */
> +    /* in case of PCI Express Base Specification Rev 1.x */
> +    if (version == 1) {
> +        /* The PCI Express Capabilities, Device Capabilities, and Device
> +         * Status/Control registers are required for all PCI Express devices.
> +         * The Link Capabilities and Link Status/Control are required for all
> +         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
> +         * are not required to implement registers other than those listed
> +         * above and terminate the capability structure.
> +         */
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +            pcie_size = 0x14;
> +            break;
> +        case PCI_EXP_TYPE_RC_END:
> +            /* has no link */
> +            pcie_size = 0x0C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    }
> +    /* in case of PCI Express Base Specification Rev 2.0 */
> +    else if (version == 2) {
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +        case PCI_EXP_TYPE_RC_END:
> +            /* For Functions that do not implement the registers,
> +             * these spaces must be hardwired to 0b.
> +             */
> +            pcie_size = 0x3C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    } else {
> +        PT_ERR(d, "Unsupported capability version %#x.\n", version);
> +        return -1;
> +    }
> +
> +    *size = pcie_size;
> +    return 0;
> +}
> +
> +static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
> +    /* Header Type0 reg group */
> +    {
> +        .grp_id      = 0xFF,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x40,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_header0_tbl,
> +    },
> +    /* PCI PowerManagement Capability reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_PM,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = PCI_PM_SIZEOF,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pm_tbl,
> +    },
> +    /* AGP Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vital Product Data Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VPD,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x08,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
> +    },
> +    /* Slot Identification reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SLOTID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x04,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI-X Capabilities List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_PCIX,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x18,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vendor Specific Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VNDR,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_vendor_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
> +    },
> +    /* SHPC Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SHPC,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SSVID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* AGP 8x Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP3,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI Express Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_EXP,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_pcie_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
> +    },
> +    {
> +        .grp_size = 0,
> +    },
> +};
> +
> +/* initialize Capabilities Pointer or Next Pointer register */
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    int i;
> +    uint8_t *config = s->dev.config;
> +    uint32_t reg_field = pci_get_byte(config + real_offset);
> +    uint8_t cap_id = 0;
> +
> +    /* find capability offset */
> +    while (reg_field) {
> +        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
> +            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
> +                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +                    goto out;
> +                }
> +                /* ignore the 0 hardwired capability, find next one */
> +                break;
> +            }
> +        }
> +
> +        /* next capability */
> +        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
> +    }
> +
> +out:
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +
> +/*************
> + * Main
> + */
> +
> +static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
> +{
> +    uint8_t id;
> +    unsigned max_cap = PCI_CAP_MAX;
> +    uint8_t pos = PCI_CAPABILITY_LIST;
> +    uint8_t status = 0;
> +
> +    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
> +        return 0;
> +    }
> +    if ((status & PCI_STATUS_CAP_LIST) == 0) {
> +        return 0;
> +    }
> +
> +    while (max_cap--) {
> +        if (host_pci_get_byte(s->real_device, pos, &pos)) {
> +            break;
> +        }
> +        if (pos < PCI_CONFIG_HEADER_SIZE) {
> +            break;
> +        }
> +
> +        pos &= ~3;
> +        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
> +            break;
> +        }
> +
> +        if (id == 0xff) {
> +            break;
> +        }
> +        if (id == cap) {
> +            return pos;
> +        }
> +
> +        pos += PCI_CAP_LIST_NEXT;
> +    }
> +    return 0;
> +}
> +
> +static int pt_config_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
> +{
> +    XenPTReg *reg_entry;
> +    uint32_t data = 0;
> +    int rc = 0;
> +
> +    reg_entry = g_new0(XenPTReg, 1);
> +    reg_entry->reg = reg;
> +
> +    if (reg->init) {
> +        /* initialize emulate register */
> +        rc = reg->init(s, reg_entry->reg,
> +                       reg_grp->base_offset + reg->offset, &data);
> +        if (rc < 0) {
> +            free(reg_entry);
> +            return rc;
> +        }
> +        if (data == PT_INVALID_REG) {
> +            /* free unused BAR register entry */
> +            free(reg_entry);
> +            return 0;
> +        }
> +        /* set register value */
> +        reg_entry->data = data;
> +    }
> +    /* list add register entry */
> +    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
> +
> +    return 0;
> +}
> +
> +int pt_config_init(XenPCIPassthroughState *s)
> +{
> +    int i, rc;
> +
> +    QLIST_INIT(&s->reg_grp_tbl);
> +
> +    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +        uint32_t reg_grp_offset = 0;
> +        XenPTRegGroup *reg_grp_entry = NULL;
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
> +
> +            if (!reg_grp_offset) {
> +                continue;
> +            }
> +        }
> +
> +        reg_grp_entry = g_new0(XenPTRegGroup, 1);
> +        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
> +        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
> +
> +        reg_grp_entry->base_offset = reg_grp_offset;
> +        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
> +        if (pt_emu_reg_grp_tbl[i].size_init) {
> +            /* get register group size */
> +            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
> +                                                 reg_grp_offset,
> +                                                 &reg_grp_entry->size);
> +            if (rc < 0) {
> +                pt_config_delete(s);
> +                return rc;
> +            }
> +        }
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
> +                int j = 0;
> +                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
> +                /* initialize capability register */
> +                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
> +                    /* initialize capability register */
> +                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
> +                    if (rc < 0) {
> +                        pt_config_delete(s);
> +                        return rc;
> +                    }
> +                }
> +            }
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* delete all emulate register */
> +void pt_config_delete(XenPCIPassthroughState *s)
> +{
> +    struct XenPTRegGroup *reg_group, *next_grp;
> +    struct XenPTReg *reg, *next_reg;
> +
> +    /* free all register group entry */
> +    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
> +        /* free all register entry */
> +        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
> +            QLIST_REMOVE(reg, entries);
> +            g_free(reg);
> +        }
> +
> +        QLIST_REMOVE(reg_group, entries);
> +        g_free(reg_group);
> +    }
> +}
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 13:33:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 13:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rz6sV-00017z-SJ; Sun, 19 Feb 2012 13:32:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rz6sU-00017q-Gd
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 13:32:35 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329658346!15409546!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17005 invoked from network); 19 Feb 2012 13:32:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	19 Feb 2012 13:32:27 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1JDWIGW007745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 08:32:18 -0500
Received: from redhat.com (vpn-200-7.tlv.redhat.com [10.35.200.7])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1JDWC8c012480; Sun, 19 Feb 2012 08:32:13 -0500
Date: Sun, 19 Feb 2012 15:32:20 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120219133219.GA16160@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
 PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:08:42PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen_pci_passthrough.c             |   10 +
>  hw/xen_pci_passthrough.h             |    2 +
>  hw/xen_pci_passthrough_config_init.c | 1431 ++++++++++++++++++++++++++++++++++
>  3 files changed, 1443 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 3f305dd..26a3bdd 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
>      /* Handle real device's MMIO/PIO BARs */
>      pt_register_regions(s);
>  
> +    /* reinitialize each config register to be emulated */
> +    if (pt_config_init(s)) {
> +        PT_ERR(d, "PCI Config space initialisation failed.\n");
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
>      /* Bind interrupt */
>      if (!s->dev.config[PCI_INTERRUPT_PIN]) {
>          PT_LOG(d, "no pin interrupt\n");
> @@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
>          }
>      }
>  
> +    /* delete all emulated config registers */
> +    pt_config_delete(s);
> +
>      /* unregister real device's MMIO/PIO BARs */
>      pt_unregister_regions(s);
>  
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index ea6719c..7ebc793 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -61,6 +61,8 @@ typedef int (*conf_byte_read)
>  #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
>  #define PT_PCI_BAR_UNMAPPED (-1)
>  
> +#define PCI_CAP_MAX 48
> +
>  
>  typedef enum {
>      GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index 1e9de64..f1fffd1 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1,11 +1,1442 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include "qemu-timer.h"
> +#include "xen_backend.h"
>  #include "xen_pci_passthrough.h"
>  
> +#define PT_MERGE_VALUE(value, data, val_mask) \
> +    (((value) & (val_mask)) | ((data) & ~(val_mask)))
> +
> +#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
> +
> +/* prototype */
> +
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data);
> +
> +
> +/* helper */
> +
> +/* A return value of 1 means the capability should NOT be exposed to guest. */
> +static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
> +{
> +    switch (grp_id) {
> +    case PCI_CAP_ID_EXP:
> +        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0. We should not try to expose it to guest.
> +         *
> +         * The datasheet is available at
> +         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
> +         *
> +         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
> +         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0, so the Capability Version is 0 and
> +         * pt_pcie_size_init() would fail.
> +         */
> +        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
> +            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
> +            return 1;
> +        }
> +        break;
> +    }
> +    return 0;
> +}
> +
> +/*   find emulate register group entry */
>  XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
>  {
> +    XenPTRegGroup *entry = NULL;
> +
> +    /* find register group entry */
> +    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
> +        /* check address */
> +        if ((entry->base_offset <= address)
> +            && ((entry->base_offset + entry->size) > address)) {
> +            return entry;
> +        }
> +    }
> +
> +    /* group entry not found */
>      return NULL;
>  }
>  
> +/* find emulate register entry */
>  XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
>  {
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +
> +    /* find register entry */
> +    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
> +        reg = reg_entry->reg;
> +        real_offset = reg_grp->base_offset + reg->offset;
> +        /* check address */
> +        if ((real_offset <= address)
> +            && ((real_offset + reg->size) > address)) {
> +            return reg_entry;
> +        }
> +    }
> +
>      return NULL;
>  }
> +
> +/* parse BAR */
> +static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTRegion *region = NULL;
> +    PCIIORegion *r;
> +    int index = 0;
> +
> +    /* check 64bit BAR */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if ((0 < index) && (index < PCI_ROM_SLOT)) {
> +        int flags = s->real_device->io_regions[index - 1].flags;
> +
> +        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
> +            region = &s->bases[index - 1];
> +            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
> +                return PT_BAR_FLAG_UPPER;
> +            }
> +        }
> +    }
> +
> +    /* check unused BAR */
> +    r = &d->io_regions[index];
> +    if (r->size == 0) {
> +        return PT_BAR_FLAG_UNUSED;
> +    }
> +
> +    /* for ExpROM BAR */
> +    if (index == PCI_ROM_SLOT) {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +
> +    /* check BAR I/O indicator */
> +    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
> +        return PT_BAR_FLAG_IO;
> +    } else {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +}
> +
> +
> +/****************
> + * general register functions
> + */
> +
> +/* register initialization function */
> +
> +static int pt_common_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = reg->init_val;
> +    return 0;
> +}
> +
> +/* Read register functions */
> +
> +static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint8_t *value, uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t valid_emu_mask = 0;
> +
> +    /* emulate byte register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +
> +    /* emulate word register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +
> +    /* emulate long register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +
> +/* Write register functions */
> +
> +static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint8_t *value, uint8_t dev_value,
> +                             uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t writable_mask = 0;
> +    uint8_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t dev_value,
> +                             uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint32_t *value, uint32_t dev_value,
> +                             uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/********************
> + * Header Type0
> + */
> +
> +static int pt_vendor_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->vendor_id;
> +    return 0;
> +}
> +static int pt_device_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->device_id;
> +    return 0;
> +}
> +static int pt_status_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t reg_field = 0;
> +
> +    /* find Header register group */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
> +    if (reg_grp_entry) {
> +        /* find Capabilities Pointer register */
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
> +        if (reg_entry) {
> +            /* check Capabilities Pointer register */
> +            if (reg_entry->data) {
> +                reg_field |= PCI_STATUS_CAP_LIST;
> +            } else {
> +                reg_field &= ~PCI_STATUS_CAP_LIST;
> +            }
> +        } else {
> +            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
> +                                     " for Capabilities Pointer register."
> +                                     " (%s)\n", __func__);
> +            return -1;
> +        }
> +    } else {
> +        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
> +                                 " for Header. (%s)\n", __func__);
> +        return -1;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_header_type_reg_init(XenPCIPassthroughState *s,
> +                                   XenPTRegInfo *reg, uint32_t real_offset,
> +                                   uint32_t *data)
> +{
> +    /* read PCI_HEADER_TYPE */
> +    *data = reg->init_val | 0x80;
> +    return 0;
> +}
> +
> +/* initialize Interrupt Pin register */
> +static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = pci_read_intx(s);
> +    return 0;
> +}
> +
> +/* Command register */
> +static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* emulate word register */
> +    valid_emu_mask = emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t dev_value,
> +                            uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t wr_value = *value;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +
> +    if (*value & PCI_COMMAND_INTX_DISABLE) {
> +        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        if (s->machine_irq) {
> +            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +        }
> +    }
> +
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
> +                   wr_value & PCI_COMMAND_MEMORY);
> +

IMO this is a wrong way to do this. It completely ignores
things like bridge filtering memory accesses.

The right time to update your mappings is I think
when pci_update_mappings is called.
The memory API which that should have enough hooks for you I think,
at least it seems sufficient for device assignment on kvm.
I don't know much about how well it works for Xen,
worst-case, if absolutely necessary, we could
re-add the ->map call for devices.



> +    return 0;
> +}
> +
> +/* BAR */
> +#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
> +#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
> +#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
> +#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
> +
> +static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
> +{
> +    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
> +    } else {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
> +    }
> +}
> +
> +static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    int index;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
> +
> +    /* set BAR flag */
> +    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
> +        reg_field = PT_INVALID_REG;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use fixed-up value from kernel sysfs */
> +    *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* emulate BAR */
> +    valid_emu_mask = bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t dev_value,
> +                            uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = &s->dev;
> +    const PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +    uint32_t r_size = 0;
> +    int index = 0;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    r = &d->io_regions[index];
> +    base = &s->bases[index];
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    /* set emulate mask and read-only mask values depend on the BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* check whether we need to update the virtual region address or not */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        if (cfg_entry->data) {
> +            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
> +                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
> +                        "Ignore mapping. "
> +                        "(offset: 0x%02x, high address: 0x%08x)\n",
> +                        reg->offset, cfg_entry->data);
> +            }
> +        }
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* write Exp ROM BAR */
> +static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
> +                                    XenPTReg *cfg_entry, uint32_t *value,
> +                                    uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = (PCIDevice *)&s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    pcibus_t r_size = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +
> +    r = &d->io_regions[PCI_ROM_SLOT];
> +    r_size = r->size;
> +    base = &s->bases[PCI_ROM_SLOT];
> +    /* align memory type resource size */
> +    pt_get_emul_size(base->bar_flag, r_size);
> +
> +    /* set emulate mask and read-only mask */
> +    bar_emu_mask = reg->emu_mask;
> +    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
> +
> +    /* modify emulate register */
> +    writable_mask = ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR*/
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, PCI_ROM_SLOT,
> +                               reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* Header Type0 reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_VENDOR_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_vendor_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device ID reg */
> +    {
> +        .offset     = PCI_DEVICE_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_device_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Command reg */
> +    {
> +        .offset     = PCI_COMMAND,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xF880,
> +        .emu_mask   = 0x0740,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_cmd_reg_read,
> +        .u.w.write  = pt_cmd_reg_write,
> +    },
> +    /* Capabilities Pointer reg */
> +    {
> +        .offset     = PCI_CAPABILITY_LIST,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Status reg */
> +    /* use emulated Cap Ptr value to initialize,
> +     * so need to be declared after Cap Ptr reg
> +     */
> +    {
> +        .offset     = PCI_STATUS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x06FF,
> +        .emu_mask   = 0x0010,
> +        .init       = pt_status_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Cache Line Size reg */
> +    {
> +        .offset     = PCI_CACHE_LINE_SIZE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Latency Timer reg */
> +    {
> +        .offset     = PCI_LATENCY_TIMER,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Header Type reg */
> +    {
> +        .offset     = PCI_HEADER_TYPE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0x00,
> +        .init       = pt_header_type_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Line reg */
> +    {
> +        .offset     = PCI_INTERRUPT_LINE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Pin reg */
> +    {
> +        .offset     = PCI_INTERRUPT_PIN,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_irqpin_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* BAR 0 reg */
> +    /* mask of BAR need to be decided later, depends on IO/MEM type */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_0,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 1 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_1,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 2 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_2,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 3 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_3,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 4 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_4,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 5 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_5,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* Expansion ROM BAR reg */
> +    {
> +        .offset     = PCI_ROM_ADDRESS,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x000007FE,
> +        .emu_mask   = 0xFFFFF800,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_exp_rom_bar_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Vital Product Data Capability
> + */
> +
> +/* Vital Product Data Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * Vendor Specific Capability
> + */
> +
> +/* Vendor Specific Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*****************************
> + * PCI Express Capability
> + */
> +
> +static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
> +                                             uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return flags & PCI_EXP_FLAGS_VERS;
> +}
> +
> +static inline uint8_t get_device_type(XenPCIPassthroughState *s,
> +                                      uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
> +}
> +
> +/* initialize Link Control register */
> +static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of Root Complex Integrated Endpoint
> +     * with cap_ver 1.x
> +     */
> +    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Device Control 2 register */
> +static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Link Control 2 register */
> +static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint32_t reg_field = 0;
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        reg_field = PT_INVALID_REG;
> +    } else {
> +        /* set Supported Link Speed */
> +        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                                      + PCI_EXP_LNKCAP);
> +        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +/* PCI Express Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Device Capabilities reg */
> +    {
> +        .offset     = PCI_EXP_DEVCAP,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x1FFCFFFF,
> +        .emu_mask   = 0x10000000,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_long_reg_write,
> +    },
> +    /* Device Control reg */
> +    {
> +        .offset     = PCI_EXP_DEVCTL,
> +        .size       = 2,
> +        .init_val   = 0x2810,
> +        .ro_mask    = 0x8400,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control reg */
> +    {
> +        .offset     = PCI_EXP_LNKCTL,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFC34,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device Control 2 reg */
> +    {
> +        .offset     = 0x28,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFE0,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_devctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control 2 reg */
> +    {
> +        .offset     = 0x30,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xE040,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Power Management Capability
> + */
> +
> +/* read Power Management Control/Status register */
> +static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = reg->emu_mask;
> +
> +    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    valid_emu_mask = valid_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +/* write Power Management Control/Status register */
> +static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint16_t *value, uint16_t dev_value,
> +                              uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t emu_mask = reg->emu_mask;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    /* modify emulate register */
> +    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +/* Power Management Capability reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Power Management Capabilities reg */
> +    {
> +        .offset     = PCI_CAP_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xF9C8,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* PCI Power Management Control/Status reg */
> +    {
> +        .offset     = PCI_PM_CTRL,
> +        .size       = 2,
> +        .init_val   = 0x0008,
> +        .ro_mask    = 0xE1FC,
> +        .emu_mask   = 0x8100,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_pmcsr_reg_read,
> +        .u.w.write  = pt_pmcsr_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/****************************
> + * Capabilities
> + */
> +
> +/* capability structure register group size functions */
> +
> +static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
> +                                const XenPTRegGroupInfo *grp_reg,
> +                                uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +/* get Vendor Specific Capability Structure register group size */
> +static int pt_vendor_size_init(XenPCIPassthroughState *s,
> +                               const XenPTRegGroupInfo *grp_reg,
> +                               uint32_t base_offset, uint8_t *size)
> +{
> +    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
> +    return 0;
> +}
> +/* get PCI Express Capability Structure register group size */
> +static int pt_pcie_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t version = get_capability_version(s, base_offset);
> +    uint8_t type = get_device_type(s, base_offset);
> +    uint8_t pcie_size = 0;
> +
> +
> +    /* calculate size depend on capability version and device/port type */
> +    /* in case of PCI Express Base Specification Rev 1.x */
> +    if (version == 1) {
> +        /* The PCI Express Capabilities, Device Capabilities, and Device
> +         * Status/Control registers are required for all PCI Express devices.
> +         * The Link Capabilities and Link Status/Control are required for all
> +         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
> +         * are not required to implement registers other than those listed
> +         * above and terminate the capability structure.
> +         */
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +            pcie_size = 0x14;
> +            break;
> +        case PCI_EXP_TYPE_RC_END:
> +            /* has no link */
> +            pcie_size = 0x0C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    }
> +    /* in case of PCI Express Base Specification Rev 2.0 */
> +    else if (version == 2) {
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +        case PCI_EXP_TYPE_RC_END:
> +            /* For Functions that do not implement the registers,
> +             * these spaces must be hardwired to 0b.
> +             */
> +            pcie_size = 0x3C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    } else {
> +        PT_ERR(d, "Unsupported capability version %#x.\n", version);
> +        return -1;
> +    }
> +
> +    *size = pcie_size;
> +    return 0;
> +}
> +
> +static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
> +    /* Header Type0 reg group */
> +    {
> +        .grp_id      = 0xFF,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x40,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_header0_tbl,
> +    },
> +    /* PCI PowerManagement Capability reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_PM,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = PCI_PM_SIZEOF,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pm_tbl,
> +    },
> +    /* AGP Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vital Product Data Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VPD,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x08,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
> +    },
> +    /* Slot Identification reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SLOTID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x04,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI-X Capabilities List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_PCIX,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x18,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vendor Specific Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VNDR,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_vendor_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
> +    },
> +    /* SHPC Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SHPC,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SSVID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* AGP 8x Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP3,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI Express Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_EXP,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_pcie_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
> +    },
> +    {
> +        .grp_size = 0,
> +    },
> +};
> +
> +/* initialize Capabilities Pointer or Next Pointer register */
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    int i;
> +    uint8_t *config = s->dev.config;
> +    uint32_t reg_field = pci_get_byte(config + real_offset);
> +    uint8_t cap_id = 0;
> +
> +    /* find capability offset */
> +    while (reg_field) {
> +        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
> +            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
> +                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +                    goto out;
> +                }
> +                /* ignore the 0 hardwired capability, find next one */
> +                break;
> +            }
> +        }
> +
> +        /* next capability */
> +        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
> +    }
> +
> +out:
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +
> +/*************
> + * Main
> + */
> +
> +static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
> +{
> +    uint8_t id;
> +    unsigned max_cap = PCI_CAP_MAX;
> +    uint8_t pos = PCI_CAPABILITY_LIST;
> +    uint8_t status = 0;
> +
> +    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
> +        return 0;
> +    }
> +    if ((status & PCI_STATUS_CAP_LIST) == 0) {
> +        return 0;
> +    }
> +
> +    while (max_cap--) {
> +        if (host_pci_get_byte(s->real_device, pos, &pos)) {
> +            break;
> +        }
> +        if (pos < PCI_CONFIG_HEADER_SIZE) {
> +            break;
> +        }
> +
> +        pos &= ~3;
> +        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
> +            break;
> +        }
> +
> +        if (id == 0xff) {
> +            break;
> +        }
> +        if (id == cap) {
> +            return pos;
> +        }
> +
> +        pos += PCI_CAP_LIST_NEXT;
> +    }
> +    return 0;
> +}
> +
> +static int pt_config_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
> +{
> +    XenPTReg *reg_entry;
> +    uint32_t data = 0;
> +    int rc = 0;
> +
> +    reg_entry = g_new0(XenPTReg, 1);
> +    reg_entry->reg = reg;
> +
> +    if (reg->init) {
> +        /* initialize emulate register */
> +        rc = reg->init(s, reg_entry->reg,
> +                       reg_grp->base_offset + reg->offset, &data);
> +        if (rc < 0) {
> +            free(reg_entry);
> +            return rc;
> +        }
> +        if (data == PT_INVALID_REG) {
> +            /* free unused BAR register entry */
> +            free(reg_entry);
> +            return 0;
> +        }
> +        /* set register value */
> +        reg_entry->data = data;
> +    }
> +    /* list add register entry */
> +    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
> +
> +    return 0;
> +}
> +
> +int pt_config_init(XenPCIPassthroughState *s)
> +{
> +    int i, rc;
> +
> +    QLIST_INIT(&s->reg_grp_tbl);
> +
> +    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +        uint32_t reg_grp_offset = 0;
> +        XenPTRegGroup *reg_grp_entry = NULL;
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
> +
> +            if (!reg_grp_offset) {
> +                continue;
> +            }
> +        }
> +
> +        reg_grp_entry = g_new0(XenPTRegGroup, 1);
> +        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
> +        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
> +
> +        reg_grp_entry->base_offset = reg_grp_offset;
> +        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
> +        if (pt_emu_reg_grp_tbl[i].size_init) {
> +            /* get register group size */
> +            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
> +                                                 reg_grp_offset,
> +                                                 &reg_grp_entry->size);
> +            if (rc < 0) {
> +                pt_config_delete(s);
> +                return rc;
> +            }
> +        }
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
> +                int j = 0;
> +                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
> +                /* initialize capability register */
> +                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
> +                    /* initialize capability register */
> +                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
> +                    if (rc < 0) {
> +                        pt_config_delete(s);
> +                        return rc;
> +                    }
> +                }
> +            }
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* delete all emulate register */
> +void pt_config_delete(XenPCIPassthroughState *s)
> +{
> +    struct XenPTRegGroup *reg_group, *next_grp;
> +    struct XenPTReg *reg, *next_reg;
> +
> +    /* free all register group entry */
> +    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
> +        /* free all register entry */
> +        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
> +            QLIST_REMOVE(reg, entries);
> +            g_free(reg);
> +        }
> +
> +        QLIST_REMOVE(reg_group, entries);
> +        g_free(reg_group);
> +    }
> +}
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 13:36:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 13: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.xensource.com>)
	id 1Rz6vi-0001Hi-NS; Sun, 19 Feb 2012 13:35:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rz6vg-0001HY-Jf
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 13:35:52 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329658527!64108120!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13462 invoked from network); 19 Feb 2012 13:35:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	19 Feb 2012 13:35:28 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1JDZjiM009041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 08:35:45 -0500
Received: from redhat.com (vpn-200-7.tlv.redhat.com [10.35.200.7])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1JDZfAA013934; Sun, 19 Feb 2012 08:35:42 -0500
Date: Sun, 19 Feb 2012 15:35:49 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120219133549.GB16160@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 06/11] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:08:40PM +0000, Anthony PERARD wrote:
> From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> 
> This function helps Xen PCI Passthrough device to check for overlap.
> 
> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

As far as I can see, this scans the bus a specific
device is on, looking for devices who have conflicting
BARs. Returns 1 if found, 0 if not.

Not sure what would devices do with this information, really:
patches posted just print out a warning which does not seem
too useful.


Just FYI, if you decided to e.g. disable device in
such a case that would be wrong: it is legal to have overlapping BARs as
long as there are no accesses.
So a legal thing for a guest to do is:

Assign BAR1 = abcde
Assign BAR2 = abcde <- overlaps temporarily
Assign BAR1 = 12345

And this means that you can't just check your device
has no conflicts when your device is touched:
it needs to be checked each time mappings are updated.

> ---
>  hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
>  hw/pci.h |    3 +++
>  2 files changed, 50 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 678a8c1..75d6529 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1985,6 +1985,53 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
>      return dev->bus->address_space_io;
>  }
>  
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type)

This lacks comments documentng what this does, parameters, return
values, etc.

> +{
> +    PCIBus *bus = dev->bus;
> +    PCIDevice *devices = NULL;
> +    PCIIORegion *r;
> +    int i, j;
> +    int rc = 0;
> +
> +    /* check Overlapped to Base Address */

Weird use of upper case. Intentional?
Also - what does this comment mean?

> +    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
> +        devices = bus->devices[i];
> +        if (!devices) {
> +            continue;
> +        }
> +
> +        /* skip itself */

itself?

> +        if (devices->devfn == dev->devfn) {
> +            continue;
> +        }
> +
> +        for (j = 0; j < PCI_NUM_REGIONS; j++) {

This ignores bridges.

> +            r = &devices->io_regions[j];
> +
> +            /* skip different resource type, but don't skip when
> +             * prefetch and non-prefetch memory are compared.
> +             */
> +            if (type != r->type) {
> +                if (type & PCI_BASE_ADDRESS_SPACE_IO ||
> +                    r->type & PCI_BASE_ADDRESS_SPACE_IO) {

Do you mean
	type & PCI_BASE_ADDRESS_SPACE_IO != r->type &
PCI_BASE_ADDRESS_SPACE_IO
?

This would not need a comment then.


> +                    continue;
> +                }
> +            }
> +
> +            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {

Can ranges_overlap be used?


> +                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
> +                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
> +                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
> +                       PCI_FUNC(devices->devfn), j, r->addr, r->size);


That's not how one should report errors.

> +                rc = 1;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> +
>  static void pci_device_class_init(ObjectClass *klass, void *data)
>  {
>      DeviceClass *k = DEVICE_CLASS(klass);
> diff --git a/hw/pci.h b/hw/pci.h
> index 33b0b18..f05fda5 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -566,4 +566,7 @@ extern const VMStateDescription vmstate_pci_device;
>      .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
>  }
>  
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type);
> +
>  #endif
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 13:36:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 13: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.xensource.com>)
	id 1Rz6vi-0001Hi-NS; Sun, 19 Feb 2012 13:35:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rz6vg-0001HY-Jf
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 13:35:52 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329658527!64108120!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13462 invoked from network); 19 Feb 2012 13:35:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	19 Feb 2012 13:35:28 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1JDZjiM009041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 08:35:45 -0500
Received: from redhat.com (vpn-200-7.tlv.redhat.com [10.35.200.7])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1JDZfAA013934; Sun, 19 Feb 2012 08:35:42 -0500
Date: Sun, 19 Feb 2012 15:35:49 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120219133549.GB16160@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 06/11] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 05:08:40PM +0000, Anthony PERARD wrote:
> From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> 
> This function helps Xen PCI Passthrough device to check for overlap.
> 
> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

As far as I can see, this scans the bus a specific
device is on, looking for devices who have conflicting
BARs. Returns 1 if found, 0 if not.

Not sure what would devices do with this information, really:
patches posted just print out a warning which does not seem
too useful.


Just FYI, if you decided to e.g. disable device in
such a case that would be wrong: it is legal to have overlapping BARs as
long as there are no accesses.
So a legal thing for a guest to do is:

Assign BAR1 = abcde
Assign BAR2 = abcde <- overlaps temporarily
Assign BAR1 = 12345

And this means that you can't just check your device
has no conflicts when your device is touched:
it needs to be checked each time mappings are updated.

> ---
>  hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
>  hw/pci.h |    3 +++
>  2 files changed, 50 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 678a8c1..75d6529 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1985,6 +1985,53 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
>      return dev->bus->address_space_io;
>  }
>  
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type)

This lacks comments documentng what this does, parameters, return
values, etc.

> +{
> +    PCIBus *bus = dev->bus;
> +    PCIDevice *devices = NULL;
> +    PCIIORegion *r;
> +    int i, j;
> +    int rc = 0;
> +
> +    /* check Overlapped to Base Address */

Weird use of upper case. Intentional?
Also - what does this comment mean?

> +    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
> +        devices = bus->devices[i];
> +        if (!devices) {
> +            continue;
> +        }
> +
> +        /* skip itself */

itself?

> +        if (devices->devfn == dev->devfn) {
> +            continue;
> +        }
> +
> +        for (j = 0; j < PCI_NUM_REGIONS; j++) {

This ignores bridges.

> +            r = &devices->io_regions[j];
> +
> +            /* skip different resource type, but don't skip when
> +             * prefetch and non-prefetch memory are compared.
> +             */
> +            if (type != r->type) {
> +                if (type & PCI_BASE_ADDRESS_SPACE_IO ||
> +                    r->type & PCI_BASE_ADDRESS_SPACE_IO) {

Do you mean
	type & PCI_BASE_ADDRESS_SPACE_IO != r->type &
PCI_BASE_ADDRESS_SPACE_IO
?

This would not need a comment then.


> +                    continue;
> +                }
> +            }
> +
> +            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {

Can ranges_overlap be used?


> +                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
> +                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
> +                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
> +                       PCI_FUNC(devices->devfn), j, r->addr, r->size);


That's not how one should report errors.

> +                rc = 1;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> +
>  static void pci_device_class_init(ObjectClass *klass, void *data)
>  {
>      DeviceClass *k = DEVICE_CLASS(klass);
> diff --git a/hw/pci.h b/hw/pci.h
> index 33b0b18..f05fda5 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -566,4 +566,7 @@ extern const VMStateDescription vmstate_pci_device;
>      .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
>  }
>  
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type);
> +
>  #endif
> -- 
> Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 19:37:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 19:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzCZ8-0006qk-B8; Sun, 19 Feb 2012 19:36:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzCZ6-0006qa-WB
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 19:36:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329680208!9779845!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUyODgx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11325 invoked from network); 19 Feb 2012 19:36:50 -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; 19 Feb 2012 19:36: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 q1JJag2A005884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 19:36:43 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
	q1JJafqO014006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 19 Feb 2012 19:36:42 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
	q1JJaego003219; Sun, 19 Feb 2012 13:36:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 19 Feb 2012 11:36:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9E42142023; Sun, 19 Feb 2012 13:23:39 -0500 (EST)
Date: Sun, 19 Feb 2012 13:23:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120219182339.GA11882@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F414F4C.0053,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >>> +struct pv_pad_ops {
> >>> +	int (*acpi_pad_init)(void);
> >>> +	void (*acpi_pad_exit)(void);
> >>> +};
> >>> +
> > 
> > Looking at this a bit closer I am not sure why you choose the paravirt
> > interface for this? There is another one - the x86 that could have
> > been 
> > choosen. Or introduce a new one that is specific to ACPI.
> > 
> > I am curious - what was the reason for using the paravirt interface?
> > I understand it does get the job done, but it seems a bit overkill
> > when something simple could have been used?
> > 
> 
> It uses paravirt interface to avoid some code like 'xen_...' in native code path (acpi_pad.c).
> I'm not quite sure what does 'x86' here mean? Adding 2 fields (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops? seems it's much simpler.

arch/x86/include/asm/x86_init.h

But before you go that way let me ask you another question - can ACPI PAD
be used on ARM or IA64? If so, wouldn't this fail compilation as this pvops
structure is not defined on IA64?

The other thing I am not comfortable about is that the pvops structure
are used for low-level code. Not for higher up, like ACPI. For that another
structure seems more prudent. Perhaps something like the x86 one, but specific
to ACPI?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 19:37:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 19:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzCZ8-0006qk-B8; Sun, 19 Feb 2012 19:36:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzCZ6-0006qa-WB
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 19:36:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329680208!9779845!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUyODgx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11325 invoked from network); 19 Feb 2012 19:36:50 -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; 19 Feb 2012 19:36: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 q1JJag2A005884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 19:36:43 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
	q1JJafqO014006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 19 Feb 2012 19:36:42 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
	q1JJaego003219; Sun, 19 Feb 2012 13:36:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 19 Feb 2012 11:36:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9E42142023; Sun, 19 Feb 2012 13:23:39 -0500 (EST)
Date: Sun, 19 Feb 2012 13:23:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120219182339.GA11882@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F414F4C.0053,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >>> +struct pv_pad_ops {
> >>> +	int (*acpi_pad_init)(void);
> >>> +	void (*acpi_pad_exit)(void);
> >>> +};
> >>> +
> > 
> > Looking at this a bit closer I am not sure why you choose the paravirt
> > interface for this? There is another one - the x86 that could have
> > been 
> > choosen. Or introduce a new one that is specific to ACPI.
> > 
> > I am curious - what was the reason for using the paravirt interface?
> > I understand it does get the job done, but it seems a bit overkill
> > when something simple could have been used?
> > 
> 
> It uses paravirt interface to avoid some code like 'xen_...' in native code path (acpi_pad.c).
> I'm not quite sure what does 'x86' here mean? Adding 2 fields (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops? seems it's much simpler.

arch/x86/include/asm/x86_init.h

But before you go that way let me ask you another question - can ACPI PAD
be used on ARM or IA64? If so, wouldn't this fail compilation as this pvops
structure is not defined on IA64?

The other thing I am not comfortable about is that the pvops structure
are used for low-level code. Not for higher up, like ACPI. For that another
structure seems more prudent. Perhaps something like the x86 one, but specific
to ACPI?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 19:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 19: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.xensource.com>)
	id 1RzCZ9-0006qr-OR; Sun, 19 Feb 2012 19:36:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzCZ7-0006qb-SI
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 19:36:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329680209!5761463!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MTc1Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9513 invoked from network); 19 Feb 2012 19:36:50 -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; 19 Feb 2012 19:36:50 -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 q1JJahhY013880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 19:36: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
	q1JJafB3018928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 19 Feb 2012 19:36: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
	q1JJafDj010496; Sun, 19 Feb 2012 13:36:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 19 Feb 2012 11:36:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7061B42024; Sun, 19 Feb 2012 13:24:28 -0500 (EST)
Date: Sun, 19 Feb 2012 13:24:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120219182428.GB11882@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
	<20120217143727.GC29110@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A0869@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A0869@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F414F4D.000A,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > 
> > How does that work when the the driver is booted under baremetal?
> > Won't it kick out the native ACPI_PROCESSOR_AGGREGATOR_CLASS
> > (acpi_pad.c) ? 
> > 
> > What about if the other ACPI_PROCESSOR_AGGREGATOR_CLASS gets called
> > first? Won't this fail?
> > 
> > Or is the acpi_bus_register_driver smart enough to process more than
> > one ACPI bus device?
> 
> When driver booted under baremetal, xen_acpi_pad.c would be disabled and native acpi_pad.c logic would work.

Ah right. It is b/c it uses the pvops indirection mechanism.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 19:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 19: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.xensource.com>)
	id 1RzCZ9-0006qr-OR; Sun, 19 Feb 2012 19:36:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzCZ7-0006qb-SI
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 19:36:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329680209!5761463!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MTc1Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9513 invoked from network); 19 Feb 2012 19:36:50 -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; 19 Feb 2012 19:36:50 -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 q1JJahhY013880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Feb 2012 19:36: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
	q1JJafB3018928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 19 Feb 2012 19:36: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
	q1JJafDj010496; Sun, 19 Feb 2012 13:36:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 19 Feb 2012 11:36:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7061B42024; Sun, 19 Feb 2012 13:24:28 -0500 (EST)
Date: Sun, 19 Feb 2012 13:24:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120219182428.GB11882@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D87E@SHSMSX101.ccr.corp.intel.com>
	<20120217143727.GC29110@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A0869@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A0869@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F414F4D.000A,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen pad logic and notification
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > 
> > How does that work when the the driver is booted under baremetal?
> > Won't it kick out the native ACPI_PROCESSOR_AGGREGATOR_CLASS
> > (acpi_pad.c) ? 
> > 
> > What about if the other ACPI_PROCESSOR_AGGREGATOR_CLASS gets called
> > first? Won't this fail?
> > 
> > Or is the acpi_bus_register_driver smart enough to process more than
> > one ACPI bus device?
> 
> When driver booted under baremetal, xen_acpi_pad.c would be disabled and native acpi_pad.c logic would work.

Ah right. It is b/c it uses the pvops indirection mechanism.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 22:13:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 22:13:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzEzK-0008Hp-GI; Sun, 19 Feb 2012 22:12:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RzEzI-0008Hk-UR
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 22:12:09 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329689504!64133387!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.6 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20696 invoked from network); 19 Feb 2012 22:11:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 22:11:44 -0000
Received: by werb14 with SMTP id b14so10854524wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 14:12:07 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.80.226 as permitted sender) client-ip=10.180.80.226; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.80.226 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.80.226])
	by 10.180.80.226 with SMTP id u2mr14418674wix.0.1329689527279 (num_hops
	= 1); Sun, 19 Feb 2012 14:12:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=FJgqZCiFhhcgv389SlhCSCrAEqZLbWYR2fwUlDxd5Iw=;
	b=ZzhY+hvhxoULLfJ6/1lTmhEzH3RG6nxzXrTwLaT1+PHjRgz1enNg4N7xCAU7QuYtbN
	lmFH4iP3pVgrbC4GkMS0jdgMue7nTJUCWRA4ZSZtuQxb5P3Z4TeBbvsYzTCAagcMbxkI
	fF/4xd40E9efn4e/IExgcTN+FBiXopMDvhbGU=
MIME-Version: 1.0
Received: by 10.180.80.226 with SMTP id u2mr12053210wix.0.1329689527241; Sun,
	19 Feb 2012 14:12:07 -0800 (PST)
Received: by 10.180.77.130 with HTTP; Sun, 19 Feb 2012 14:12:07 -0800 (PST)
Date: Sun, 19 Feb 2012 15:12:07 -0700
Message-ID: <CAHyyzzTpGXRDovrUAcJ+jb6hW_pGRP3keDvukYYPdeoh3QTSDQ@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] arch linux xen 4.2 no network
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2075026508555474129=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2075026508555474129==
Content-Type: multipart/alternative; boundary=f46d044288d2eecacf04b9587741

--f46d044288d2eecacf04b9587741
Content-Type: text/plain; charset=ISO-8859-1

I just created arch linux xen 4.2 unstable package so it compiled fine and
installs fine. When I run xl create it starts vm. I have vif devices
created but they don't attach to bridget that are created on startup . I
have xenbr0 and xenbr1 created.
If I run this I get vifi attached ro bridge. Is this xl issue or python.
# export vif=vif1.0
# export XENBUS_PATH=/local/domain/0/backend/vif/1/0
(found with `xl network-list`)
# export bridge=br0
# /etc/xen/scripts/vif-bridge add
# /etc/xen/scripts/vif-bridge online
It seems that xen has to be compileg with python 2.7 . I wonder if this
well known bug are there any patches.

--f46d044288d2eecacf04b9587741
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I just created arch linux xen 4.2=A0unstable package so it compiled fi=
ne and installs fine. When I run xl create it starts vm. I have vif devices=
 created but they don&#39;t attach to bridget that are created on startup .=
 I have xenbr0 and xenbr1 created. </div>

<div>If I run this I get vifi attached ro bridge. Is this xl issue or pytho=
n. </div>
<div># export vif=3Dvif1.0<br># export <span class=3D"searchword0">XEN</spa=
n>BUS_PATH=3D/local/domain/0/backend/vif/1/0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 (found with `xl <span class=3D"searchword1">networ=
k</span>-list`)<br># export bridge=3Dbr0<br>
# /etc/xen/scripts/vif-bridge add<br># /etc/xen/scripts/vif-bridge online</=
div>
<div>It seems that xen has to be compileg with python 2.7 . I wonder if thi=
s well known bug are there any patches.<br></div>

--f46d044288d2eecacf04b9587741--


--===============2075026508555474129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2075026508555474129==--


From xen-devel-bounces@lists.xensource.com Sun Feb 19 22:13:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 22:13:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzEzK-0008Hp-GI; Sun, 19 Feb 2012 22:12:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RzEzI-0008Hk-UR
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 22:12:09 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329689504!64133387!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.6 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20696 invoked from network); 19 Feb 2012 22:11:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 22:11:44 -0000
Received: by werb14 with SMTP id b14so10854524wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 14:12:07 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.80.226 as permitted sender) client-ip=10.180.80.226; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.80.226 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.80.226])
	by 10.180.80.226 with SMTP id u2mr14418674wix.0.1329689527279 (num_hops
	= 1); Sun, 19 Feb 2012 14:12:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=FJgqZCiFhhcgv389SlhCSCrAEqZLbWYR2fwUlDxd5Iw=;
	b=ZzhY+hvhxoULLfJ6/1lTmhEzH3RG6nxzXrTwLaT1+PHjRgz1enNg4N7xCAU7QuYtbN
	lmFH4iP3pVgrbC4GkMS0jdgMue7nTJUCWRA4ZSZtuQxb5P3Z4TeBbvsYzTCAagcMbxkI
	fF/4xd40E9efn4e/IExgcTN+FBiXopMDvhbGU=
MIME-Version: 1.0
Received: by 10.180.80.226 with SMTP id u2mr12053210wix.0.1329689527241; Sun,
	19 Feb 2012 14:12:07 -0800 (PST)
Received: by 10.180.77.130 with HTTP; Sun, 19 Feb 2012 14:12:07 -0800 (PST)
Date: Sun, 19 Feb 2012 15:12:07 -0700
Message-ID: <CAHyyzzTpGXRDovrUAcJ+jb6hW_pGRP3keDvukYYPdeoh3QTSDQ@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] arch linux xen 4.2 no network
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2075026508555474129=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2075026508555474129==
Content-Type: multipart/alternative; boundary=f46d044288d2eecacf04b9587741

--f46d044288d2eecacf04b9587741
Content-Type: text/plain; charset=ISO-8859-1

I just created arch linux xen 4.2 unstable package so it compiled fine and
installs fine. When I run xl create it starts vm. I have vif devices
created but they don't attach to bridget that are created on startup . I
have xenbr0 and xenbr1 created.
If I run this I get vifi attached ro bridge. Is this xl issue or python.
# export vif=vif1.0
# export XENBUS_PATH=/local/domain/0/backend/vif/1/0
(found with `xl network-list`)
# export bridge=br0
# /etc/xen/scripts/vif-bridge add
# /etc/xen/scripts/vif-bridge online
It seems that xen has to be compileg with python 2.7 . I wonder if this
well known bug are there any patches.

--f46d044288d2eecacf04b9587741
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I just created arch linux xen 4.2=A0unstable package so it compiled fi=
ne and installs fine. When I run xl create it starts vm. I have vif devices=
 created but they don&#39;t attach to bridget that are created on startup .=
 I have xenbr0 and xenbr1 created. </div>

<div>If I run this I get vifi attached ro bridge. Is this xl issue or pytho=
n. </div>
<div># export vif=3Dvif1.0<br># export <span class=3D"searchword0">XEN</spa=
n>BUS_PATH=3D/local/domain/0/backend/vif/1/0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 (found with `xl <span class=3D"searchword1">networ=
k</span>-list`)<br># export bridge=3Dbr0<br>
# /etc/xen/scripts/vif-bridge add<br># /etc/xen/scripts/vif-bridge online</=
div>
<div>It seems that xen has to be compileg with python 2.7 . I wonder if thi=
s well known bug are there any patches.<br></div>

--f46d044288d2eecacf04b9587741--


--===============2075026508555474129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2075026508555474129==--


From xen-devel-bounces@lists.xensource.com Sun Feb 19 22:32:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 22:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzFIE-00009z-Cy; Sun, 19 Feb 2012 22:31:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1RzFIC-00009u-Lf
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 22:31:40 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329690693!12161348!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10276 invoked from network); 19 Feb 2012 22:31:34 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 22:31:34 -0000
Received: by iaeh11 with SMTP id h11so40030866iae.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 14:31:32 -0800 (PST)
Received-SPF: pass (google.com: domain of jrnieder@gmail.com designates
	10.50.156.196 as permitted sender) client-ip=10.50.156.196; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jrnieder@gmail.com
	designates 10.50.156.196 as permitted sender)
	smtp.mail=jrnieder@gmail.com;
	dkim=pass header.i=jrnieder@gmail.com
Received: from mr.google.com ([10.50.156.196])
	by 10.50.156.196 with SMTP id wg4mr9239585igb.13.1329690692844
	(num_hops = 1); Sun, 19 Feb 2012 14:31:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=TwXgzDUgtNwtLcTY5YwaZVLcFjykIHKoZz0KUdOgopk=;
	b=djNWJWuDOpf/KbF6JAglXrb610WZ9gl7ulfkHDk2qXVguk1nHx9VnuXqI1B7HIZ8pe
	f32hz15gaztc3cdnIb8USolggyYtZhb+g1pchMEe4ZqaYSKVn5arvV6hhK1g+qRaIdNn
	HJDwKoTqvfgwEBrI9Z36IhbPscDHWYrA/Epas=
Received: by 10.50.156.196 with SMTP id wg4mr7503748igb.13.1329690692786;
	Sun, 19 Feb 2012 14:31:32 -0800 (PST)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id r18sm25585463ibh.4.2012.02.19.14.31.31
	(version=SSLv3 cipher=OTHER); Sun, 19 Feb 2012 14:31:32 -0800 (PST)
Date: Sun, 19 Feb 2012 16:31:25 -0600
From: Jonathan Nieder <jrnieder@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120219223125.GA820@burratino>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120127144737.GA27750@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Thomas Goirand <zigo@debian.org>, xen-devel@lists.xensource.com,
	William Dauchy <wdauchy@gmail.com>
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

forwarded 660554 http://thread.gmane.org/gmane.comp.emulators.xen.devel/121604
quit
(cc-ing Thomas, since he ran into the same bug)
Hi,

Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 02:31:55PM +0100, William Dauchy wrote:

>> I have some troubles loading the IOATDMA module under xen4.1.2 and a
>> linux dom0 3.3
>
> So you are using the rc1 version? What exact git commit are you using?

Broken:

 v3.2.6 + Debian patches (zigo)
 v3.3-rc2~22 (William)

Not broken:

 v3.1.8 + Debian patches, presumably (zigo)
 v3.1.5 (William)

[...]
>> Here is the call trace when loading the module in dom0:
>
> Is the problem present with baremetal (same exact kernel?)

No.

> Do you see this if you run a 64-bit dom0?

I'm guessing not, just based on the crazy coincidence that both
reports were with 32-bit kernels.  But who knows. ;-)

[...]
>> kernel BUG at /linux-3.3/drivers/dma/ioat/dma_v2.c:163!
>> invalid opcode: 0000 [#1] SMP
>> Modules linked in: ioatdma(+) dca ebt_ip6 ebt_dnat ebt_ip
>> ebtable_broute ebt_snat ebtable_nat ebtable_filter ebtables bridge stp
>> llc ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod
>> button
>> 
>> Pid: 0, comm: swapper/0 Not tainted 3.3.0-dom0-6357-i386+ #24 Dell   C6100           /0D61XP

This is

	active = ioat2_ring_active(ioat);
	for (i = 0; i < active && !seen_current; i++) {
		...
		if (tx->phys == phys_complete)
			seen_current = true;
	}
	...
	BUG_ON(active && !seen_current); /* no active descs have written a completion? */

Any hints for tracking it down?

Thanks,
Jonathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Feb 19 22:32:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 19 Feb 2012 22:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzFIE-00009z-Cy; Sun, 19 Feb 2012 22:31:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1RzFIC-00009u-Lf
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 22:31:40 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329690693!12161348!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10276 invoked from network); 19 Feb 2012 22:31:34 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2012 22:31:34 -0000
Received: by iaeh11 with SMTP id h11so40030866iae.30
	for <xen-devel@lists.xensource.com>;
	Sun, 19 Feb 2012 14:31:32 -0800 (PST)
Received-SPF: pass (google.com: domain of jrnieder@gmail.com designates
	10.50.156.196 as permitted sender) client-ip=10.50.156.196; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jrnieder@gmail.com
	designates 10.50.156.196 as permitted sender)
	smtp.mail=jrnieder@gmail.com;
	dkim=pass header.i=jrnieder@gmail.com
Received: from mr.google.com ([10.50.156.196])
	by 10.50.156.196 with SMTP id wg4mr9239585igb.13.1329690692844
	(num_hops = 1); Sun, 19 Feb 2012 14:31:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=TwXgzDUgtNwtLcTY5YwaZVLcFjykIHKoZz0KUdOgopk=;
	b=djNWJWuDOpf/KbF6JAglXrb610WZ9gl7ulfkHDk2qXVguk1nHx9VnuXqI1B7HIZ8pe
	f32hz15gaztc3cdnIb8USolggyYtZhb+g1pchMEe4ZqaYSKVn5arvV6hhK1g+qRaIdNn
	HJDwKoTqvfgwEBrI9Z36IhbPscDHWYrA/Epas=
Received: by 10.50.156.196 with SMTP id wg4mr7503748igb.13.1329690692786;
	Sun, 19 Feb 2012 14:31:32 -0800 (PST)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id r18sm25585463ibh.4.2012.02.19.14.31.31
	(version=SSLv3 cipher=OTHER); Sun, 19 Feb 2012 14:31:32 -0800 (PST)
Date: Sun, 19 Feb 2012 16:31:25 -0600
From: Jonathan Nieder <jrnieder@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120219223125.GA820@burratino>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120127144737.GA27750@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Thomas Goirand <zigo@debian.org>, xen-devel@lists.xensource.com,
	William Dauchy <wdauchy@gmail.com>
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

forwarded 660554 http://thread.gmane.org/gmane.comp.emulators.xen.devel/121604
quit
(cc-ing Thomas, since he ran into the same bug)
Hi,

Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 02:31:55PM +0100, William Dauchy wrote:

>> I have some troubles loading the IOATDMA module under xen4.1.2 and a
>> linux dom0 3.3
>
> So you are using the rc1 version? What exact git commit are you using?

Broken:

 v3.2.6 + Debian patches (zigo)
 v3.3-rc2~22 (William)

Not broken:

 v3.1.8 + Debian patches, presumably (zigo)
 v3.1.5 (William)

[...]
>> Here is the call trace when loading the module in dom0:
>
> Is the problem present with baremetal (same exact kernel?)

No.

> Do you see this if you run a 64-bit dom0?

I'm guessing not, just based on the crazy coincidence that both
reports were with 32-bit kernels.  But who knows. ;-)

[...]
>> kernel BUG at /linux-3.3/drivers/dma/ioat/dma_v2.c:163!
>> invalid opcode: 0000 [#1] SMP
>> Modules linked in: ioatdma(+) dca ebt_ip6 ebt_dnat ebt_ip
>> ebtable_broute ebt_snat ebtable_nat ebtable_filter ebtables bridge stp
>> llc ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod
>> button
>> 
>> Pid: 0, comm: swapper/0 Not tainted 3.3.0-dom0-6357-i386+ #24 Dell   C6100           /0D61XP

This is

	active = ioat2_ring_active(ioat);
	for (i = 0; i < active && !seen_current; i++) {
		...
		if (tx->phys == phys_complete)
			seen_current = true;
	}
	...
	BUG_ON(active && !seen_current); /* no active descs have written a completion? */

Any hints for tracking it down?

Thanks,
Jonathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 07:21:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 07:21:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzNXi-0002fy-CS; Mon, 20 Feb 2012 07:20:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RzNXh-0002fq-1N
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 07:20:13 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329722404!13062873!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzMDky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3131 invoked from network); 20 Feb 2012 07:20:06 -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; 20 Feb 2012 07:20:06 -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 q1K7K3M2014433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 07:20: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
	q1K7K2sH001643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 07:20:03 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
	q1K7K2In001462
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 01:20:02 -0600
Received: from [10.182.38.194] (/10.182.38.194)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 19 Feb 2012 23:20:02 -0800
Message-ID: <4F41F41F.9060601@oracle.com>
Date: Mon, 20 Feb 2012 15:19:59 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------010309020207000005030804"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F41F424.005C,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
	to tm->tm_year
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------010309020207000005030804
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi

In rtc_set_time, mktime is called to calculate seconds since 1970/01/01, 
input parameters of mktime are required to be in normal date format. 
Such as: year=1980, mon=12, day=31, hour=23, min=59, sec=59. However, 
the current input parameter of mktime is tm->tm_year, and it is the 
number of years since 1900. (For example, if current time is 2012/12/31, 
and tm->tm_year is 112). This is not suitable for requirement of mktime. 
So I think tm->tm_year should be changed to tm->tm_year+1900 when 
calling mktime. Please check the patch attached.

Thanks,
Annie

--------------010309020207000005030804
Content-Type: text/plain;
 name="rtc-timeoffset.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="rtc-timeoffset.patch"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgZjI1NDNmNDQ5YTQ5Yjg5NzliZWNiZjY4
ODhlMDA5OTczNDI3MDg5YQpodm06IGNvcnJlY3QgUlRDIHRpbWUgb2Zmc2V0IHVwZGF0ZSBl
cnJvciBkdWUgdG8gdG0tPnRtX3llYXIKCm1rdGltZSByZXF1aXJlcyBpbnB1dCB5ZWFyIGlu
IG5vcm1hbCBkYXRlIGZvcm1hdCwgaS5lLiAxOTgwLiBTbyBpdCBpcyBuZWNlc3NhcnkKdG8g
Y2hhbmdlIHRtLT50bV95ZWFyIHRvIHRtLT50bV95ZWFyKzE5MDAuIE90aGVyd2lzZSwgdGhl
IGNhbGN1bGF0aW9uIHJlc3VsdApvZiBta3RpbWUgaXMgaW5jb3JyZWN0LgoKU2lnbmVkLW9m
Zi1ieTogQW5uaWUgTGkgPGFubmllLmxpQG9yYWNsZS5jb20+CgpkaWZmIC1yIGYyNTQzZjQ0
OWE0OSB4ZW4vYXJjaC94ODYvaHZtL3J0Yy5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vcnRj
LmMJTW9uIEZlYiAxMyAxNzo1Nzo0NyAyMDEyICswMDAwCisrKyBiL3hlbi9hcmNoL3g4Ni9o
dm0vcnRjLmMJTW9uIEZlYiAyMCAxNDozOTowMCAyMDEyICswODAwCkBAIC0xNjUsNyArMTY1
LDcgQEAgc3RhdGljIHZvaWQgcnRjX3NldF90aW1lKFJUQ1N0YXRlICpzKQogICAgICAgCiAg
ICAgQVNTRVJUKHNwaW5faXNfbG9ja2VkKCZzLT5sb2NrKSk7CiAKLSAgICBiZWZvcmUgPSBt
a3RpbWUodG0tPnRtX3llYXIsIHRtLT50bV9tb24gKyAxLCB0bS0+dG1fbWRheSwKKyAgICBi
ZWZvcmUgPSBta3RpbWUodG0tPnRtX3llYXIgKyAxOTAwLCB0bS0+dG1fbW9uICsgMSwgdG0t
PnRtX21kYXksCiAJCSAgICB0bS0+dG1faG91ciwgdG0tPnRtX21pbiwgdG0tPnRtX3NlYyk7
CiAgICAgCiAgICAgdG0tPnRtX3NlYyA9IGZyb21fYmNkKHMsIHMtPmh3LmNtb3NfZGF0YVtS
VENfU0VDT05EU10pOwpAQCAtMTc5LDcgKzE3OSw3IEBAIHN0YXRpYyB2b2lkIHJ0Y19zZXRf
dGltZShSVENTdGF0ZSAqcykKICAgICB0bS0+dG1fbW9uID0gZnJvbV9iY2Qocywgcy0+aHcu
Y21vc19kYXRhW1JUQ19NT05USF0pIC0gMTsKICAgICB0bS0+dG1feWVhciA9IGZyb21fYmNk
KHMsIHMtPmh3LmNtb3NfZGF0YVtSVENfWUVBUl0pICsgMTAwOwogCi0gICAgYWZ0ZXIgPSBt
a3RpbWUodG0tPnRtX3llYXIsIHRtLT50bV9tb24gKyAxLCB0bS0+dG1fbWRheSwKKyAgICBh
ZnRlciA9IG1rdGltZSh0bS0+dG1feWVhciArIDE5MDAsIHRtLT50bV9tb24gKyAxLCB0bS0+
dG1fbWRheSwKICAgICAgICAgICAgICAgICAgICB0bS0+dG1faG91ciwgdG0tPnRtX21pbiwg
dG0tPnRtX3NlYyk7CiAKICAgICAvKiBXZSB1c2UgdGhlIGd1ZXN0J3Mgc2V0dGluZyBvZiB0
aGUgUlRDIHRvIGRlZmluZSB0aGUgbG9jYWwtdGltZSAK
--------------010309020207000005030804
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010309020207000005030804--


From xen-devel-bounces@lists.xensource.com Mon Feb 20 07:21:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 07:21:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzNXi-0002fy-CS; Mon, 20 Feb 2012 07:20:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RzNXh-0002fq-1N
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 07:20:13 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329722404!13062873!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzMDky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3131 invoked from network); 20 Feb 2012 07:20:06 -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; 20 Feb 2012 07:20:06 -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 q1K7K3M2014433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 07:20: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
	q1K7K2sH001643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 07:20:03 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
	q1K7K2In001462
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 01:20:02 -0600
Received: from [10.182.38.194] (/10.182.38.194)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 19 Feb 2012 23:20:02 -0800
Message-ID: <4F41F41F.9060601@oracle.com>
Date: Mon, 20 Feb 2012 15:19:59 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------010309020207000005030804"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F41F424.005C,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
	to tm->tm_year
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------010309020207000005030804
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi

In rtc_set_time, mktime is called to calculate seconds since 1970/01/01, 
input parameters of mktime are required to be in normal date format. 
Such as: year=1980, mon=12, day=31, hour=23, min=59, sec=59. However, 
the current input parameter of mktime is tm->tm_year, and it is the 
number of years since 1900. (For example, if current time is 2012/12/31, 
and tm->tm_year is 112). This is not suitable for requirement of mktime. 
So I think tm->tm_year should be changed to tm->tm_year+1900 when 
calling mktime. Please check the patch attached.

Thanks,
Annie

--------------010309020207000005030804
Content-Type: text/plain;
 name="rtc-timeoffset.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="rtc-timeoffset.patch"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgZjI1NDNmNDQ5YTQ5Yjg5NzliZWNiZjY4
ODhlMDA5OTczNDI3MDg5YQpodm06IGNvcnJlY3QgUlRDIHRpbWUgb2Zmc2V0IHVwZGF0ZSBl
cnJvciBkdWUgdG8gdG0tPnRtX3llYXIKCm1rdGltZSByZXF1aXJlcyBpbnB1dCB5ZWFyIGlu
IG5vcm1hbCBkYXRlIGZvcm1hdCwgaS5lLiAxOTgwLiBTbyBpdCBpcyBuZWNlc3NhcnkKdG8g
Y2hhbmdlIHRtLT50bV95ZWFyIHRvIHRtLT50bV95ZWFyKzE5MDAuIE90aGVyd2lzZSwgdGhl
IGNhbGN1bGF0aW9uIHJlc3VsdApvZiBta3RpbWUgaXMgaW5jb3JyZWN0LgoKU2lnbmVkLW9m
Zi1ieTogQW5uaWUgTGkgPGFubmllLmxpQG9yYWNsZS5jb20+CgpkaWZmIC1yIGYyNTQzZjQ0
OWE0OSB4ZW4vYXJjaC94ODYvaHZtL3J0Yy5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vcnRj
LmMJTW9uIEZlYiAxMyAxNzo1Nzo0NyAyMDEyICswMDAwCisrKyBiL3hlbi9hcmNoL3g4Ni9o
dm0vcnRjLmMJTW9uIEZlYiAyMCAxNDozOTowMCAyMDEyICswODAwCkBAIC0xNjUsNyArMTY1
LDcgQEAgc3RhdGljIHZvaWQgcnRjX3NldF90aW1lKFJUQ1N0YXRlICpzKQogICAgICAgCiAg
ICAgQVNTRVJUKHNwaW5faXNfbG9ja2VkKCZzLT5sb2NrKSk7CiAKLSAgICBiZWZvcmUgPSBt
a3RpbWUodG0tPnRtX3llYXIsIHRtLT50bV9tb24gKyAxLCB0bS0+dG1fbWRheSwKKyAgICBi
ZWZvcmUgPSBta3RpbWUodG0tPnRtX3llYXIgKyAxOTAwLCB0bS0+dG1fbW9uICsgMSwgdG0t
PnRtX21kYXksCiAJCSAgICB0bS0+dG1faG91ciwgdG0tPnRtX21pbiwgdG0tPnRtX3NlYyk7
CiAgICAgCiAgICAgdG0tPnRtX3NlYyA9IGZyb21fYmNkKHMsIHMtPmh3LmNtb3NfZGF0YVtS
VENfU0VDT05EU10pOwpAQCAtMTc5LDcgKzE3OSw3IEBAIHN0YXRpYyB2b2lkIHJ0Y19zZXRf
dGltZShSVENTdGF0ZSAqcykKICAgICB0bS0+dG1fbW9uID0gZnJvbV9iY2Qocywgcy0+aHcu
Y21vc19kYXRhW1JUQ19NT05USF0pIC0gMTsKICAgICB0bS0+dG1feWVhciA9IGZyb21fYmNk
KHMsIHMtPmh3LmNtb3NfZGF0YVtSVENfWUVBUl0pICsgMTAwOwogCi0gICAgYWZ0ZXIgPSBt
a3RpbWUodG0tPnRtX3llYXIsIHRtLT50bV9tb24gKyAxLCB0bS0+dG1fbWRheSwKKyAgICBh
ZnRlciA9IG1rdGltZSh0bS0+dG1feWVhciArIDE5MDAsIHRtLT50bV9tb24gKyAxLCB0bS0+
dG1fbWRheSwKICAgICAgICAgICAgICAgICAgICB0bS0+dG1faG91ciwgdG0tPnRtX21pbiwg
dG0tPnRtX3NlYyk7CiAKICAgICAvKiBXZSB1c2UgdGhlIGd1ZXN0J3Mgc2V0dGluZyBvZiB0
aGUgUlRDIHRvIGRlZmluZSB0aGUgbG9jYWwtdGltZSAK
--------------010309020207000005030804
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010309020207000005030804--


From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:23:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzPS6-0004wy-7K; Mon, 20 Feb 2012 09:22:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzPS4-0004wn-PQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:22:32 +0000
Received: from [85.158.139.83:46171] by server-7.bemta-5.messagelabs.com id
	6C/D4-16195-7D0124F4; Mon, 20 Feb 2012 09:22:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329729750!13061248!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 20 Feb 2012 09:22:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 09:22:31 -0000
Received: by wibhm2 with SMTP id hm2so10626997wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 01:22:30 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr3901164wei.42.1329729750689
	(num_hops = 1); Mon, 20 Feb 2012 01:22:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=+sUN5oRSt/BUawHu9rAMjw8X5yhJDAMnqagpraQcTko=;
	b=ayU5kVdGZg7OR0dZBc8c8JXiBHmBvRxuVA4/XDNIq49udxRe9OECK+fV4XBuT+SE+Q
	XFN/8SdqEBTcXz8wtne9p4MOxiHGQV1oyMm0eBJVNTxWwufcjv2vyGYNtNCU62DuL5f8
	ykmwCha55DnB+dYtURQdq1oaG852wuqXi5JMM=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr3230545wei.42.1329729750520; Mon,
	20 Feb 2012 01:22:30 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 01:22:30 -0800 (PST)
Date: Mon, 20 Feb 2012 10:22:30 +0100
X-Google-Sender-Auth: i8pS27xE4G9uBPSpy0wsqocqTFU
Message-ID: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

When compiling SeaBIOS with busybox and uclibc 0.9.33, I've hit the
following error:

  Build Kconfig config file
  Compiling whole program out/ccode.16.s
  Compiling to assembler out/asm-offsets.s
  Generating offset file out/asm-offsets.h
gen-offsets.sh: applet not found

When looking into gen-offsets.sh [0] I've realized there's a strange
shebang in the script ":", is this normal? Replacing ":" with
"#!/bin/sh" solves the problem, but I don't understand why the ":"
shebang works for some (on Debian stable it works ok) and what it
means.

Thanks, Roger.

[0] http://code.coreboot.org/p/seabios/source/tree/rel-1.6.3.1/tools/gen-offsets.sh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:23:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09:23:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzPS6-0004wy-7K; Mon, 20 Feb 2012 09:22:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzPS4-0004wn-PQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:22:32 +0000
Received: from [85.158.139.83:46171] by server-7.bemta-5.messagelabs.com id
	6C/D4-16195-7D0124F4; Mon, 20 Feb 2012 09:22:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329729750!13061248!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 20 Feb 2012 09:22:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 09:22:31 -0000
Received: by wibhm2 with SMTP id hm2so10626997wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 01:22:30 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr3901164wei.42.1329729750689
	(num_hops = 1); Mon, 20 Feb 2012 01:22:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=+sUN5oRSt/BUawHu9rAMjw8X5yhJDAMnqagpraQcTko=;
	b=ayU5kVdGZg7OR0dZBc8c8JXiBHmBvRxuVA4/XDNIq49udxRe9OECK+fV4XBuT+SE+Q
	XFN/8SdqEBTcXz8wtne9p4MOxiHGQV1oyMm0eBJVNTxWwufcjv2vyGYNtNCU62DuL5f8
	ykmwCha55DnB+dYtURQdq1oaG852wuqXi5JMM=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr3230545wei.42.1329729750520; Mon,
	20 Feb 2012 01:22:30 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 01:22:30 -0800 (PST)
Date: Mon, 20 Feb 2012 10:22:30 +0100
X-Google-Sender-Auth: i8pS27xE4G9uBPSpy0wsqocqTFU
Message-ID: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

When compiling SeaBIOS with busybox and uclibc 0.9.33, I've hit the
following error:

  Build Kconfig config file
  Compiling whole program out/ccode.16.s
  Compiling to assembler out/asm-offsets.s
  Generating offset file out/asm-offsets.h
gen-offsets.sh: applet not found

When looking into gen-offsets.sh [0] I've realized there's a strange
shebang in the script ":", is this normal? Replacing ":" with
"#!/bin/sh" solves the problem, but I don't understand why the ":"
shebang works for some (on Debian stable it works ok) and what it
means.

Thanks, Roger.

[0] http://code.coreboot.org/p/seabios/source/tree/rel-1.6.3.1/tools/gen-offsets.sh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:49:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzPrb-0005ON-MY; Mon, 20 Feb 2012 09:48:55 +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 1RzPra-0005O5-I6
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:48:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329731278!54926668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2588 invoked from network); 20 Feb 2012 09:47:58 -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;
	20 Feb 2012 09:47:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10801600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 09:48:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 09:48:50 +0000
Message-ID: <1329731328.3990.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 20 Feb 2012 09:48:48 +0000
In-Reply-To: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAyLTIwIGF0IDA5OjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IFdoZW4gY29tcGlsaW5nIFNlYUJJT1Mgd2l0aCBidXN5Ym94IGFuZCB1
Y2xpYmMgMC45LjMzLCBJJ3ZlIGhpdCB0aGUKPiBmb2xsb3dpbmcgZXJyb3I6Cj4gCj4gICBCdWls
ZCBLY29uZmlnIGNvbmZpZyBmaWxlCj4gICBDb21waWxpbmcgd2hvbGUgcHJvZ3JhbSBvdXQvY2Nv
ZGUuMTYucwo+ICAgQ29tcGlsaW5nIHRvIGFzc2VtYmxlciBvdXQvYXNtLW9mZnNldHMucwo+ICAg
R2VuZXJhdGluZyBvZmZzZXQgZmlsZSBvdXQvYXNtLW9mZnNldHMuaAo+IGdlbi1vZmZzZXRzLnNo
OiBhcHBsZXQgbm90IGZvdW5kCgpJIGd1ZXNzIHRoaXMgbWVhbnMgeW91ciBzaGVsbCBjb21lcyBm
cm9tIGJ1c3lib3g/IAoKPiBXaGVuIGxvb2tpbmcgaW50byBnZW4tb2Zmc2V0cy5zaCBbMF0gSSd2
ZSByZWFsaXplZCB0aGVyZSdzIGEgc3RyYW5nZQo+IHNoZWJhbmcgaW4gdGhlIHNjcmlwdCAiOiIs
IGlzIHRoaXMgbm9ybWFsPyBSZXBsYWNpbmcgIjoiIHdpdGgKPiAiIyEvYmluL3NoIiBzb2x2ZXMg
dGhlIHByb2JsZW0sIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSAiOiIKPiBzaGViYW5n
IHdvcmtzIGZvciBzb21lIChvbiBEZWJpYW4gc3RhYmxlIGl0IHdvcmtzIG9rKSBhbmQgd2hhdCBp
dAo+IG1lYW5zLgoKSSd2ZSBubyBpZGVhIGVpdGhlciAtLSBJJ3ZlIGNvcGllZCB0aGUgc2VhYmlv
cyBNTC4KCklhbi4KCj4gCj4gVGhhbmtzLCBSb2dlci4KPiAKPiBbMF0gaHR0cDovL2NvZGUuY29y
ZWJvb3Qub3JnL3Avc2VhYmlvcy9zb3VyY2UvdHJlZS9yZWwtMS42LjMuMS90b29scy9nZW4tb2Zm
c2V0cy5zaAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:49:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzPrb-0005ON-MY; Mon, 20 Feb 2012 09:48:55 +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 1RzPra-0005O5-I6
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:48:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329731278!54926668!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2588 invoked from network); 20 Feb 2012 09:47:58 -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;
	20 Feb 2012 09:47:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10801600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 09:48:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 09:48:50 +0000
Message-ID: <1329731328.3990.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 20 Feb 2012 09:48:48 +0000
In-Reply-To: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAyLTIwIGF0IDA5OjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IFdoZW4gY29tcGlsaW5nIFNlYUJJT1Mgd2l0aCBidXN5Ym94IGFuZCB1
Y2xpYmMgMC45LjMzLCBJJ3ZlIGhpdCB0aGUKPiBmb2xsb3dpbmcgZXJyb3I6Cj4gCj4gICBCdWls
ZCBLY29uZmlnIGNvbmZpZyBmaWxlCj4gICBDb21waWxpbmcgd2hvbGUgcHJvZ3JhbSBvdXQvY2Nv
ZGUuMTYucwo+ICAgQ29tcGlsaW5nIHRvIGFzc2VtYmxlciBvdXQvYXNtLW9mZnNldHMucwo+ICAg
R2VuZXJhdGluZyBvZmZzZXQgZmlsZSBvdXQvYXNtLW9mZnNldHMuaAo+IGdlbi1vZmZzZXRzLnNo
OiBhcHBsZXQgbm90IGZvdW5kCgpJIGd1ZXNzIHRoaXMgbWVhbnMgeW91ciBzaGVsbCBjb21lcyBm
cm9tIGJ1c3lib3g/IAoKPiBXaGVuIGxvb2tpbmcgaW50byBnZW4tb2Zmc2V0cy5zaCBbMF0gSSd2
ZSByZWFsaXplZCB0aGVyZSdzIGEgc3RyYW5nZQo+IHNoZWJhbmcgaW4gdGhlIHNjcmlwdCAiOiIs
IGlzIHRoaXMgbm9ybWFsPyBSZXBsYWNpbmcgIjoiIHdpdGgKPiAiIyEvYmluL3NoIiBzb2x2ZXMg
dGhlIHByb2JsZW0sIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSAiOiIKPiBzaGViYW5n
IHdvcmtzIGZvciBzb21lIChvbiBEZWJpYW4gc3RhYmxlIGl0IHdvcmtzIG9rKSBhbmQgd2hhdCBp
dAo+IG1lYW5zLgoKSSd2ZSBubyBpZGVhIGVpdGhlciAtLSBJJ3ZlIGNvcGllZCB0aGUgc2VhYmlv
cyBNTC4KCklhbi4KCj4gCj4gVGhhbmtzLCBSb2dlci4KPiAKPiBbMF0gaHR0cDovL2NvZGUuY29y
ZWJvb3Qub3JnL3Avc2VhYmlvcy9zb3VyY2UvdHJlZS9yZWwtMS42LjMuMS90b29scy9nZW4tb2Zm
c2V0cy5zaAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:53:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09: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.xensource.com>)
	id 1RzPvP-0005Vd-Bh; Mon, 20 Feb 2012 09:52:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzPvN-0005VS-SQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:52:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329731563!14069935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18808 invoked from network); 20 Feb 2012 09:52:43 -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;
	20 Feb 2012 09:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10801941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 09:52:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 09:52:43 +0000
Message-ID: <1329731561.3990.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Date: Mon, 20 Feb 2012 09:52:41 +0000
In-Reply-To: <CAHyyzzTpGXRDovrUAcJ+jb6hW_pGRP3keDvukYYPdeoh3QTSDQ@mail.gmail.com>
References: <CAHyyzzTpGXRDovrUAcJ+jb6hW_pGRP3keDvukYYPdeoh3QTSDQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] arch linux xen 4.2 no network
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-02-19 at 22:12 +0000, jacek burghardt wrote:
> I just created arch linux xen 4.2 unstable package so it compiled fine
> and installs fine. When I run xl create it starts vm. I have vif
> devices created but they don't attach to bridget that are created on
> startup . I have xenbr0 and xenbr1 created. 

Do you have the udev rules installed in the right place?

> If I run this I get vifi attached ro bridge. Is this xl issue or
> python. 
> # export vif=vif1.0
> # export XENBUS_PATH=/local/domain/0/backend/vif/1/0
> (found with `xl network-list`)
> # export bridge=br0

This is neither of the bridge names which you stated above.

If your bridge is called "br0" then you probably need "bridge=br0" in
your vif configuration line or to set "defaultbridge"
in /etc/xen/xl.conf.

> # /etc/xen/scripts/vif-bridge add
> # /etc/xen/scripts/vif-bridge online
> It seems that xen has to be compileg with python 2.7 . I wonder if
> this well known bug are there any patches.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:53:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09: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.xensource.com>)
	id 1RzPvP-0005Vd-Bh; Mon, 20 Feb 2012 09:52:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzPvN-0005VS-SQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:52:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329731563!14069935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18808 invoked from network); 20 Feb 2012 09:52:43 -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;
	20 Feb 2012 09:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10801941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 09:52:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 09:52:43 +0000
Message-ID: <1329731561.3990.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Date: Mon, 20 Feb 2012 09:52:41 +0000
In-Reply-To: <CAHyyzzTpGXRDovrUAcJ+jb6hW_pGRP3keDvukYYPdeoh3QTSDQ@mail.gmail.com>
References: <CAHyyzzTpGXRDovrUAcJ+jb6hW_pGRP3keDvukYYPdeoh3QTSDQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] arch linux xen 4.2 no network
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-02-19 at 22:12 +0000, jacek burghardt wrote:
> I just created arch linux xen 4.2 unstable package so it compiled fine
> and installs fine. When I run xl create it starts vm. I have vif
> devices created but they don't attach to bridget that are created on
> startup . I have xenbr0 and xenbr1 created. 

Do you have the udev rules installed in the right place?

> If I run this I get vifi attached ro bridge. Is this xl issue or
> python. 
> # export vif=vif1.0
> # export XENBUS_PATH=/local/domain/0/backend/vif/1/0
> (found with `xl network-list`)
> # export bridge=br0

This is neither of the bridge names which you stated above.

If your bridge is called "br0" then you probably need "bridge=br0" in
your vif configuration line or to set "defaultbridge"
in /etc/xen/xl.conf.

> # /etc/xen/scripts/vif-bridge add
> # /etc/xen/scripts/vif-bridge online
> It seems that xen has to be compileg with python 2.7 . I wonder if
> this well known bug are there any patches.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09: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.xensource.com>)
	id 1RzQ1k-0005hm-6m; Mon, 20 Feb 2012 09:59:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzQ1i-0005hh-U7
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:59:23 +0000
Received: from [85.158.139.83:36530] by server-6.bemta-5.messagelabs.com id
	1B/53-27305-A79124F4; Mon, 20 Feb 2012 09:59:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329731961!15713074!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9437 invoked from network); 20 Feb 2012 09:59:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 09:59:21 -0000
Received: by wibhm2 with SMTP id hm2so10700041wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 01:59:21 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr3963955wei.42.1329731961567
	(num_hops = 1); Mon, 20 Feb 2012 01:59:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=cA0a7e3V/qJHLe4tC5ykXH1cF205KTx/ZTE3ag8bojI=;
	b=A+bHhslgCWkJH/ziV7skav7hqolAYa+F+/+LPyQ/b0RLSAIXaBDwFroEN6moe85DT0
	Bm4Z+9bEn/BFF4cfust6exKIzRKSEg+aIleAnGVbt/+QZGWC/DwLj15CaTNjk3y1GIbP
	Xd+kxG5oAVVMvIQI+wj8PaEZuOW2Wvpo0oYq8=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr3273499wei.42.1329731623496; Mon,
	20 Feb 2012 01:53:43 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 01:53:43 -0800 (PST)
In-Reply-To: <1329731328.3990.1.camel@zakaz.uk.xensource.com>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
	<1329731328.3990.1.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 10:53:43 +0100
X-Google-Sender-Auth: sRLUuDDs-hAIrMDYWx75Rn--hnY
Message-ID: <CAPLaKK4QK1Ljm7KQUskzRZbDY-onazpPHxAv7fkuJGgkWtbedg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIwIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMi0yMCBhdCAwOToyMiArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
SGVsbG8sCj4+Cj4+IFdoZW4gY29tcGlsaW5nIFNlYUJJT1Mgd2l0aCBidXN5Ym94IGFuZCB1Y2xp
YmMgMC45LjMzLCBJJ3ZlIGhpdCB0aGUKPj4gZm9sbG93aW5nIGVycm9yOgo+Pgo+PiDCoCBCdWls
ZCBLY29uZmlnIGNvbmZpZyBmaWxlCj4+IMKgIENvbXBpbGluZyB3aG9sZSBwcm9ncmFtIG91dC9j
Y29kZS4xNi5zCj4+IMKgIENvbXBpbGluZyB0byBhc3NlbWJsZXIgb3V0L2FzbS1vZmZzZXRzLnMK
Pj4gwqAgR2VuZXJhdGluZyBvZmZzZXQgZmlsZSBvdXQvYXNtLW9mZnNldHMuaAo+PiBnZW4tb2Zm
c2V0cy5zaDogYXBwbGV0IG5vdCBmb3VuZAo+Cj4gSSBndWVzcyB0aGlzIG1lYW5zIHlvdXIgc2hl
bGwgY29tZXMgZnJvbSBidXN5Ym94PwoKWWVzLCB0aGUgc2hlbGwgSSdtIHVzaW5nIGlzIGFzaCBb
MF0sIHRoaXMgaXMgdGhlIGRlZmF1bHQgc2hlbGwgZm9yIGJ1c3lib3guCgpbMF0gaHR0cDovL3d3
dy5pbi11bG0uZGUvfm1hc2NoZWNrL3ZhcmlvdXMvYXNoLwoKPgo+PiBXaGVuIGxvb2tpbmcgaW50
byBnZW4tb2Zmc2V0cy5zaCBbMF0gSSd2ZSByZWFsaXplZCB0aGVyZSdzIGEgc3RyYW5nZQo+PiBz
aGViYW5nIGluIHRoZSBzY3JpcHQgIjoiLCBpcyB0aGlzIG5vcm1hbD8gUmVwbGFjaW5nICI6IiB3
aXRoCj4+ICIjIS9iaW4vc2giIHNvbHZlcyB0aGUgcHJvYmxlbSwgYnV0IEkgZG9uJ3QgdW5kZXJz
dGFuZCB3aHkgdGhlICI6Igo+PiBzaGViYW5nIHdvcmtzIGZvciBzb21lIChvbiBEZWJpYW4gc3Rh
YmxlIGl0IHdvcmtzIG9rKSBhbmQgd2hhdCBpdAo+PiBtZWFucy4KPgo+IEkndmUgbm8gaWRlYSBl
aXRoZXIgLS0gSSd2ZSBjb3BpZWQgdGhlIHNlYWJpb3MgTUwuCgpJIGNhbiBzdWJtaXQgYSBwYXRj
aCByZXBsYWNpbmcgIjoiIHdpdGggIiMhL2Jpbi9zaCIsIGJ1dCBJIGRpZG4ndCBkbwppdCBiZWNh
dXNlIEkgaGF2ZSBubyBpZGVhIHdoYXQgIjoiIG1lYW5zIGluIGEgc2hlYmFuZy4KCj4gSWFuLgo+
Cj4+Cj4+IFRoYW5rcywgUm9nZXIuCj4+Cj4+IFswXSBodHRwOi8vY29kZS5jb3JlYm9vdC5vcmcv
cC9zZWFiaW9zL3NvdXJjZS90cmVlL3JlbC0xLjYuMy4xL3Rvb2xzL2dlbi1vZmZzZXRzLnNoCj4K
PgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 09:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 09: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.xensource.com>)
	id 1RzQ1k-0005hm-6m; Mon, 20 Feb 2012 09:59:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzQ1i-0005hh-U7
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:59:23 +0000
Received: from [85.158.139.83:36530] by server-6.bemta-5.messagelabs.com id
	1B/53-27305-A79124F4; Mon, 20 Feb 2012 09:59:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329731961!15713074!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9437 invoked from network); 20 Feb 2012 09:59:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 09:59:21 -0000
Received: by wibhm2 with SMTP id hm2so10700041wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 01:59:21 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr3963955wei.42.1329731961567
	(num_hops = 1); Mon, 20 Feb 2012 01:59:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=cA0a7e3V/qJHLe4tC5ykXH1cF205KTx/ZTE3ag8bojI=;
	b=A+bHhslgCWkJH/ziV7skav7hqolAYa+F+/+LPyQ/b0RLSAIXaBDwFroEN6moe85DT0
	Bm4Z+9bEn/BFF4cfust6exKIzRKSEg+aIleAnGVbt/+QZGWC/DwLj15CaTNjk3y1GIbP
	Xd+kxG5oAVVMvIQI+wj8PaEZuOW2Wvpo0oYq8=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr3273499wei.42.1329731623496; Mon,
	20 Feb 2012 01:53:43 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 01:53:43 -0800 (PST)
In-Reply-To: <1329731328.3990.1.camel@zakaz.uk.xensource.com>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
	<1329731328.3990.1.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 10:53:43 +0100
X-Google-Sender-Auth: sRLUuDDs-hAIrMDYWx75Rn--hnY
Message-ID: <CAPLaKK4QK1Ljm7KQUskzRZbDY-onazpPHxAv7fkuJGgkWtbedg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIwIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMi0yMCBhdCAwOToyMiArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
SGVsbG8sCj4+Cj4+IFdoZW4gY29tcGlsaW5nIFNlYUJJT1Mgd2l0aCBidXN5Ym94IGFuZCB1Y2xp
YmMgMC45LjMzLCBJJ3ZlIGhpdCB0aGUKPj4gZm9sbG93aW5nIGVycm9yOgo+Pgo+PiDCoCBCdWls
ZCBLY29uZmlnIGNvbmZpZyBmaWxlCj4+IMKgIENvbXBpbGluZyB3aG9sZSBwcm9ncmFtIG91dC9j
Y29kZS4xNi5zCj4+IMKgIENvbXBpbGluZyB0byBhc3NlbWJsZXIgb3V0L2FzbS1vZmZzZXRzLnMK
Pj4gwqAgR2VuZXJhdGluZyBvZmZzZXQgZmlsZSBvdXQvYXNtLW9mZnNldHMuaAo+PiBnZW4tb2Zm
c2V0cy5zaDogYXBwbGV0IG5vdCBmb3VuZAo+Cj4gSSBndWVzcyB0aGlzIG1lYW5zIHlvdXIgc2hl
bGwgY29tZXMgZnJvbSBidXN5Ym94PwoKWWVzLCB0aGUgc2hlbGwgSSdtIHVzaW5nIGlzIGFzaCBb
MF0sIHRoaXMgaXMgdGhlIGRlZmF1bHQgc2hlbGwgZm9yIGJ1c3lib3guCgpbMF0gaHR0cDovL3d3
dy5pbi11bG0uZGUvfm1hc2NoZWNrL3ZhcmlvdXMvYXNoLwoKPgo+PiBXaGVuIGxvb2tpbmcgaW50
byBnZW4tb2Zmc2V0cy5zaCBbMF0gSSd2ZSByZWFsaXplZCB0aGVyZSdzIGEgc3RyYW5nZQo+PiBz
aGViYW5nIGluIHRoZSBzY3JpcHQgIjoiLCBpcyB0aGlzIG5vcm1hbD8gUmVwbGFjaW5nICI6IiB3
aXRoCj4+ICIjIS9iaW4vc2giIHNvbHZlcyB0aGUgcHJvYmxlbSwgYnV0IEkgZG9uJ3QgdW5kZXJz
dGFuZCB3aHkgdGhlICI6Igo+PiBzaGViYW5nIHdvcmtzIGZvciBzb21lIChvbiBEZWJpYW4gc3Rh
YmxlIGl0IHdvcmtzIG9rKSBhbmQgd2hhdCBpdAo+PiBtZWFucy4KPgo+IEkndmUgbm8gaWRlYSBl
aXRoZXIgLS0gSSd2ZSBjb3BpZWQgdGhlIHNlYWJpb3MgTUwuCgpJIGNhbiBzdWJtaXQgYSBwYXRj
aCByZXBsYWNpbmcgIjoiIHdpdGggIiMhL2Jpbi9zaCIsIGJ1dCBJIGRpZG4ndCBkbwppdCBiZWNh
dXNlIEkgaGF2ZSBubyBpZGVhIHdoYXQgIjoiIG1lYW5zIGluIGEgc2hlYmFuZy4KCj4gSWFuLgo+
Cj4+Cj4+IFRoYW5rcywgUm9nZXIuCj4+Cj4+IFswXSBodHRwOi8vY29kZS5jb3JlYm9vdC5vcmcv
cC9zZWFiaW9zL3NvdXJjZS90cmVlL3JlbC0xLjYuMy4xL3Rvb2xzL2dlbi1vZmZzZXRzLnNoCj4K
PgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:06:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQ8Q-0005uN-5d; Mon, 20 Feb 2012 10:06:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RzQ8O-0005uC-Tq
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:06:17 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329732369!15570436!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29080 invoked from network); 20 Feb 2012 10:06:10 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2012 10:06:10 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RzQ8H-0002OU-3S
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 02:06:09 -0800
Date: Mon, 20 Feb 2012 02:06:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329732369098-5498606.post@n5.nabble.com>
In-Reply-To: <1329652815801-5496780.post@n5.nabble.com>
References: <1329494799149-5493035.post@n5.nabble.com>
	<20120217160912.GG31531@phenom.dumpdata.com>
	<1329652815801-5496780.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is build log file: 
http://xen.1045712.n5.nabble.com/file/n5498606/xenbuild3.log xenbuild3.log 
About various libxl are build and installed:
ls /usr/lib64/
fs                     libvhd.so.1.0.0       libxenstat.so.0
libblktap.a            libxenctrl.a          libxenstat.so.0.0
libblktapctl.a         libxenctrl.so         libxenstore.a
libblktapctl.so        libxenctrl.so.4.2     libxenstore.so
libblktapctl.so.1.0    libxenctrl.so.4.2.0   libxenstore.so.3.0
libblktapctl.so.1.0.0  libxenguest.a         libxenstore.so.3.0.1
libblktap.so           libxenguest.so        libxenvchan.a
libblktap.so.3.0       libxenguest.so.4.2    libxenvchan.so
libblktap.so.3.0.0     libxenguest.so.4.2.0  libxenvchan.so.1.0
libfsimage.so          libxenlight.a         libxenvchan.so.1.0.0
libfsimage.so.1.0      libxenlight.so        libxlutil.a
libfsimage.so.1.0.0    libxenlight.so.2.0    libxlutil.so
libvhd.a               libxenlight.so.2.0.0  libxlutil.so.1.0
libvhd.so              libxenstat.a          libxlutil.so.1.0.0
libvhd.so.1.0          libxenstat.so         xen

But they are not considered...
xl list
xl: error while loading shared libraries: libxlutil.so.1.0: cannot open
shared object file: No such file or directory

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5498606.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:06:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQ8Q-0005uN-5d; Mon, 20 Feb 2012 10:06:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RzQ8O-0005uC-Tq
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:06:17 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329732369!15570436!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29080 invoked from network); 20 Feb 2012 10:06:10 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2012 10:06:10 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RzQ8H-0002OU-3S
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 02:06:09 -0800
Date: Mon, 20 Feb 2012 02:06:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329732369098-5498606.post@n5.nabble.com>
In-Reply-To: <1329652815801-5496780.post@n5.nabble.com>
References: <1329494799149-5493035.post@n5.nabble.com>
	<20120217160912.GG31531@phenom.dumpdata.com>
	<1329652815801-5496780.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is build log file: 
http://xen.1045712.n5.nabble.com/file/n5498606/xenbuild3.log xenbuild3.log 
About various libxl are build and installed:
ls /usr/lib64/
fs                     libvhd.so.1.0.0       libxenstat.so.0
libblktap.a            libxenctrl.a          libxenstat.so.0.0
libblktapctl.a         libxenctrl.so         libxenstore.a
libblktapctl.so        libxenctrl.so.4.2     libxenstore.so
libblktapctl.so.1.0    libxenctrl.so.4.2.0   libxenstore.so.3.0
libblktapctl.so.1.0.0  libxenguest.a         libxenstore.so.3.0.1
libblktap.so           libxenguest.so        libxenvchan.a
libblktap.so.3.0       libxenguest.so.4.2    libxenvchan.so
libblktap.so.3.0.0     libxenguest.so.4.2.0  libxenvchan.so.1.0
libfsimage.so          libxenlight.a         libxenvchan.so.1.0.0
libfsimage.so.1.0      libxenlight.so        libxlutil.a
libfsimage.so.1.0.0    libxenlight.so.2.0    libxlutil.so
libvhd.a               libxenlight.so.2.0.0  libxlutil.so.1.0
libvhd.so              libxenstat.a          libxlutil.so.1.0.0
libvhd.so.1.0          libxenstat.so         xen

But they are not considered...
xl list
xl: error while loading shared libraries: libxlutil.so.1.0: cannot open
shared object file: No such file or directory

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-unable-to-boot-on-Wheezy-tp5493035p5498606.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 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.xensource.com>)
	id 1RzQS3-0006AQ-0M; Mon, 20 Feb 2012 10:26:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQS0-0006AL-Vf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:26:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329733586!14058373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5913 invoked from network); 20 Feb 2012 10:26:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:26:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10803427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:26:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:26:26 +0000
Message-ID: <1329733585.3990.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:26:25 +0000
In-Reply-To: <1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 18:43 +0000, Ian Jackson wrote:
> Make it possible to complete an ao during its initating function.
> 
> Previously this was not generally possible because initiators did not
> have an egc.  But there is no reason why an ao initiator should not
> have an egc, so make the standard macros provide one.
> 
> Change the internal documentation comments accordingly.  (This change,
> which means that an initiator function may call a completion callback
> directly, is already consistent with the documented external API.)
> 
> We also invent of a new state flag "constructing" which indicates
> whether we are between ao__create and ao__inprogress.  This is a
> slightly optimisation which allows ao_complete to not bother poking
> the wakeup pipe, since the logic in ao__inprogress will not run the
> event loop if the ao is complete on entry.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |    8 ++++++--
>  tools/libxl/libxl_internal.h |   13 +++++++++----
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 271949a..dda9d6f 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
>  
>      if (ao->poller) {
>          assert(ao->in_initiator);
> -        libxl__poller_wakeup(egc, ao->poller);
> +        if (!ao->constructing)
> +            /* don't bother with this if we're not in the event loop */
> +            libxl__poller_wakeup(egc, ao->poller);
>      } else if (ao->how.callback) {
>          LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
>      } else {
> @@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
>      if (!ao) goto out;
>  
>      ao->magic = LIBXL__AO_MAGIC;
> +    ao->constructing = 1;
>      ao->in_initiator = 1;
>      ao->poller = 0;
>      ao->domid = domid;
> @@ -1275,7 +1278,8 @@ int libxl__ao_inprogress(libxl__ao *ao)
>      int rc;
>  
>      assert(ao->magic == LIBXL__AO_MAGIC);
> -    assert(ao->in_initiator);
> +    assert(ao->constructing && ao->in_initiator);

Doing two asserts will make it clearer which condition is not satisfied
if we ever see this.

> +    ao->constructing = 0;
>  
>      if (ao->poller) {
>          /* Caller wants it done synchronously. */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8846c68..49688e1 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -337,7 +337,7 @@ struct libxl__egc {
>  
>  struct libxl__ao {
>      uint32_t magic;
> -    unsigned in_initiator:1, complete:1, notified:1;
> +    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
>      int rc;
>      libxl__gc gc;
>      libxl_asyncop_how how;
> @@ -1185,6 +1185,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
>   * outside libxl, because they can cause reentrancy callbacks.
>   *
> + * For the same reason functions taking an ao_how may make themselves
> + * an egc with EGC_INIT (and they will generally want to, to be able
> + * to immediately complete an ao during its setup).
> + *
>   * Lifecycle of an ao:
>   *
>   * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
> @@ -1214,8 +1218,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   *   directly or indirectly, should call libxl__ao_complete (with the
>   *   ctx locked, as it will generally already be in any event callback
>   *   function).  This must happen exactly once for each ao (and not if
> - *   the ao has been destroyed, obviously), and it may not happen
> - *   until libxl__ao_inprogress has been called on the ao.
> + *   the ao has been destroyed, obviously).
>   *
>   * - Note that during callback functions, two gcs are available:
>   *    - The one in egc, whose lifetime is only this callback
> @@ -1229,12 +1232,13 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>      libxl__ctx_lock(ctx);                                       \
>      libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
>      if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
> -    AO_GC;
> +    EGC_INIT(ctx);

This means that the "gc" within a function which uses this macro is now
"&egc->gc" rather than "&ao->gc".

However the egc->gc is cleaned up in AO_INPROGRESS/AO_ABORT whereas the
ao->gc persists until the activity completes which is a meaningful
difference to think about.

Now, as it happens, none of the existing callers of AO_CREATE actually
use the gc for anything (they just pass it around a bit). If,
hypothetically, libxl__device_from_disk() were to allocate some memory
into the libxl__device passed to
libxl__initiate_device_remove(ao,device) then would
initiate_device_remove be expected to copy any part of device which it
wanted to keep until completion?

Another difference is that any function calling AO_CREATE cannot now be
called from within libxl, since it now calls LIBXL__INIT_EGC which has
this restriction. libxl_cdrom_insert does not obey this new restriction.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 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.xensource.com>)
	id 1RzQS3-0006AQ-0M; Mon, 20 Feb 2012 10:26:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQS0-0006AL-Vf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:26:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329733586!14058373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5913 invoked from network); 20 Feb 2012 10:26:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:26:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10803427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:26:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:26:26 +0000
Message-ID: <1329733585.3990.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:26:25 +0000
In-Reply-To: <1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 18:43 +0000, Ian Jackson wrote:
> Make it possible to complete an ao during its initating function.
> 
> Previously this was not generally possible because initiators did not
> have an egc.  But there is no reason why an ao initiator should not
> have an egc, so make the standard macros provide one.
> 
> Change the internal documentation comments accordingly.  (This change,
> which means that an initiator function may call a completion callback
> directly, is already consistent with the documented external API.)
> 
> We also invent of a new state flag "constructing" which indicates
> whether we are between ao__create and ao__inprogress.  This is a
> slightly optimisation which allows ao_complete to not bother poking
> the wakeup pipe, since the logic in ao__inprogress will not run the
> event loop if the ao is complete on entry.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |    8 ++++++--
>  tools/libxl/libxl_internal.h |   13 +++++++++----
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 271949a..dda9d6f 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
>  
>      if (ao->poller) {
>          assert(ao->in_initiator);
> -        libxl__poller_wakeup(egc, ao->poller);
> +        if (!ao->constructing)
> +            /* don't bother with this if we're not in the event loop */
> +            libxl__poller_wakeup(egc, ao->poller);
>      } else if (ao->how.callback) {
>          LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
>      } else {
> @@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
>      if (!ao) goto out;
>  
>      ao->magic = LIBXL__AO_MAGIC;
> +    ao->constructing = 1;
>      ao->in_initiator = 1;
>      ao->poller = 0;
>      ao->domid = domid;
> @@ -1275,7 +1278,8 @@ int libxl__ao_inprogress(libxl__ao *ao)
>      int rc;
>  
>      assert(ao->magic == LIBXL__AO_MAGIC);
> -    assert(ao->in_initiator);
> +    assert(ao->constructing && ao->in_initiator);

Doing two asserts will make it clearer which condition is not satisfied
if we ever see this.

> +    ao->constructing = 0;
>  
>      if (ao->poller) {
>          /* Caller wants it done synchronously. */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8846c68..49688e1 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -337,7 +337,7 @@ struct libxl__egc {
>  
>  struct libxl__ao {
>      uint32_t magic;
> -    unsigned in_initiator:1, complete:1, notified:1;
> +    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
>      int rc;
>      libxl__gc gc;
>      libxl_asyncop_how how;
> @@ -1185,6 +1185,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
>   * outside libxl, because they can cause reentrancy callbacks.
>   *
> + * For the same reason functions taking an ao_how may make themselves
> + * an egc with EGC_INIT (and they will generally want to, to be able
> + * to immediately complete an ao during its setup).
> + *
>   * Lifecycle of an ao:
>   *
>   * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
> @@ -1214,8 +1218,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   *   directly or indirectly, should call libxl__ao_complete (with the
>   *   ctx locked, as it will generally already be in any event callback
>   *   function).  This must happen exactly once for each ao (and not if
> - *   the ao has been destroyed, obviously), and it may not happen
> - *   until libxl__ao_inprogress has been called on the ao.
> + *   the ao has been destroyed, obviously).
>   *
>   * - Note that during callback functions, two gcs are available:
>   *    - The one in egc, whose lifetime is only this callback
> @@ -1229,12 +1232,13 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>      libxl__ctx_lock(ctx);                                       \
>      libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
>      if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
> -    AO_GC;
> +    EGC_INIT(ctx);

This means that the "gc" within a function which uses this macro is now
"&egc->gc" rather than "&ao->gc".

However the egc->gc is cleaned up in AO_INPROGRESS/AO_ABORT whereas the
ao->gc persists until the activity completes which is a meaningful
difference to think about.

Now, as it happens, none of the existing callers of AO_CREATE actually
use the gc for anything (they just pass it around a bit). If,
hypothetically, libxl__device_from_disk() were to allocate some memory
into the libxl__device passed to
libxl__initiate_device_remove(ao,device) then would
initiate_device_remove be expected to copy any part of device which it
wanted to keep until completion?

Another difference is that any function calling AO_CREATE cannot now be
called from within libxl, since it now calls LIBXL__INIT_EGC which has
this restriction. libxl_cdrom_insert does not obey this new restriction.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:31:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQWE-0006Ha-MV; Mon, 20 Feb 2012 10:30:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQWD-0006HI-Mr
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:30:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329733846!3578456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14711 invoked from network); 20 Feb 2012 10:30:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:30:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10803600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:30:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:30:22 +0000
Message-ID: <1329733820.3990.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:30:20 +0000
In-Reply-To: <1329504239-19999-4-git-send-email-ian.jackson@eu.citrix.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Fix eventloop_iteration
 over-locking
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 18:43 +0000, Ian Jackson wrote:
> eventloop_iteration's head comment says that it must be called with
> the ctx locked exactly once, and this is indeed true, and it's done
> correctly at both the call sites.
> 
> However, it takes out the lock an additional time itself.  This is
> wrong because it prevents the unlocks around poll from being
> effective.  This would mean that a multithreaded event-loop using
> program might suffer from undesired blocking, as one thread trying to
> enter libxl might end up stalled by another thread waiting for a slow
> event.  So remove those two lock calls.
> 
> Also add a couple of comments documenting the locking behaviour of
> libxl__ao_inprogress and libxl__egc_cleanup.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |    4 ----
>  tools/libxl/libxl_internal.h |    4 ++--
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index dda9d6f..522bd99 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
>      int rc;
>      struct timeval now;
>      
> -    CTX_LOCK;
> -
>      rc = libxl__gettimeofday(gc, &now);
>      if (rc) goto out;
>  
> @@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
>      afterpoll_internal(egc, poller,
>                         poller->fd_polls_allocd, poller->fd_polls, now);
>  
> -    CTX_UNLOCK;
> -
>      rc = 0;
>   out:
>      return rc;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 696c1ed..7b8d0c2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1165,7 +1165,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  _hidden void libxl__egc_cleanup(libxl__egc *egc);
>    /* Frees memory allocated within this egc's gc, and and report all
>     * occurred events via callback, if applicable.  May reenter the
> -   * application; see restrictions above. */
> +   * application; see restrictions above.  The ctx must be UNLOCKED. */
>  
>  /* convenience macros: */
>  
> @@ -1260,7 +1260,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
>  _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
>                                      const libxl_asyncop_how*);
> -_hidden int libxl__ao_inprogress(libxl__ao *ao);
> +_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
>  _hidden void libxl__ao_abort(libxl__ao *ao);
>  _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:31:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQWE-0006Ha-MV; Mon, 20 Feb 2012 10:30:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQWD-0006HI-Mr
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:30:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329733846!3578456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14711 invoked from network); 20 Feb 2012 10:30:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:30:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10803600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:30:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:30:22 +0000
Message-ID: <1329733820.3990.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:30:20 +0000
In-Reply-To: <1329504239-19999-4-git-send-email-ian.jackson@eu.citrix.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: Fix eventloop_iteration
 over-locking
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 18:43 +0000, Ian Jackson wrote:
> eventloop_iteration's head comment says that it must be called with
> the ctx locked exactly once, and this is indeed true, and it's done
> correctly at both the call sites.
> 
> However, it takes out the lock an additional time itself.  This is
> wrong because it prevents the unlocks around poll from being
> effective.  This would mean that a multithreaded event-loop using
> program might suffer from undesired blocking, as one thread trying to
> enter libxl might end up stalled by another thread waiting for a slow
> event.  So remove those two lock calls.
> 
> Also add a couple of comments documenting the locking behaviour of
> libxl__ao_inprogress and libxl__egc_cleanup.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |    4 ----
>  tools/libxl/libxl_internal.h |    4 ++--
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index dda9d6f..522bd99 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
>      int rc;
>      struct timeval now;
>      
> -    CTX_LOCK;
> -
>      rc = libxl__gettimeofday(gc, &now);
>      if (rc) goto out;
>  
> @@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
>      afterpoll_internal(egc, poller,
>                         poller->fd_polls_allocd, poller->fd_polls, now);
>  
> -    CTX_UNLOCK;
> -
>      rc = 0;
>   out:
>      return rc;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 696c1ed..7b8d0c2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1165,7 +1165,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  _hidden void libxl__egc_cleanup(libxl__egc *egc);
>    /* Frees memory allocated within this egc's gc, and and report all
>     * occurred events via callback, if applicable.  May reenter the
> -   * application; see restrictions above. */
> +   * application; see restrictions above.  The ctx must be UNLOCKED. */
>  
>  /* convenience macros: */
>  
> @@ -1260,7 +1260,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
>   * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
>  _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
>                                      const libxl_asyncop_how*);
> -_hidden int libxl__ao_inprogress(libxl__ao *ao);
> +_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
>  _hidden void libxl__ao_abort(libxl__ao *ao);
>  _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:35:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQZz-0006SS-Gs; Mon, 20 Feb 2012 10:34:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQZy-0006SF-Bs
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:34:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329734079!12224686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22255 invoked from network); 20 Feb 2012 10:34:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:34:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804097"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:34:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:34:38 +0000
Message-ID: <1329734077.3990.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Mon, 20 Feb 2012 10:34:37 +0000
In-Reply-To: <1329732369098-5498606.post@n5.nabble.com>
References: <1329494799149-5493035.post@n5.nabble.com>
	<20120217160912.GG31531@phenom.dumpdata.com>
	<1329652815801-5496780.post@n5.nabble.com>
	<1329732369098-5498606.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-20 at 10:06 +0000, Fantu wrote:
> This is build log file: 
> http://xen.1045712.n5.nabble.com/file/n5498606/xenbuild3.log xenbuild3.log 
> About various libxl are build and installed:
> ls /usr/lib64/

This is not in the library path for a Debian Wheezy (or later) systems
due to changes surrounding the implementation of multiarch. This has
been discussed on the list a couple of times this year -- please check
the archives (might have been in the context of Ubuntu which has the
same issue).

You need to override config/StdGNU.mk:LIBDIR* to build on a Debian
system. I use the following.

Hopefully this will be fixed properly by the autoconf patches.

Ian.

diff -r 6ba9b19e1d79 config/StdGNU.mk
--- a/config/StdGNU.mk	Mon Feb 20 10:33:54 2012 +0000
+++ b/config/StdGNU.mk	Mon Feb 20 10:34:05 2012 +0000
@@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
+LIBLEAFDIR_x86_64 ?= lib
 LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:35:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQZz-0006SS-Gs; Mon, 20 Feb 2012 10:34:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQZy-0006SF-Bs
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:34:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329734079!12224686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22255 invoked from network); 20 Feb 2012 10:34:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:34:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804097"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:34:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:34:38 +0000
Message-ID: <1329734077.3990.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Mon, 20 Feb 2012 10:34:37 +0000
In-Reply-To: <1329732369098-5498606.post@n5.nabble.com>
References: <1329494799149-5493035.post@n5.nabble.com>
	<20120217160912.GG31531@phenom.dumpdata.com>
	<1329652815801-5496780.post@n5.nabble.com>
	<1329732369098-5498606.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable unable to boot on Wheezy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-20 at 10:06 +0000, Fantu wrote:
> This is build log file: 
> http://xen.1045712.n5.nabble.com/file/n5498606/xenbuild3.log xenbuild3.log 
> About various libxl are build and installed:
> ls /usr/lib64/

This is not in the library path for a Debian Wheezy (or later) systems
due to changes surrounding the implementation of multiarch. This has
been discussed on the list a couple of times this year -- please check
the archives (might have been in the context of Ubuntu which has the
same issue).

You need to override config/StdGNU.mk:LIBDIR* to build on a Debian
system. I use the following.

Hopefully this will be fixed properly by the autoconf patches.

Ian.

diff -r 6ba9b19e1d79 config/StdGNU.mk
--- a/config/StdGNU.mk	Mon Feb 20 10:33:54 2012 +0000
+++ b/config/StdGNU.mk	Mon Feb 20 10:34:05 2012 +0000
@@ -34,7 +34,7 @@ BINDIR = $(PREFIX)/bin
 INCLUDEDIR = $(PREFIX)/include
 LIBLEAFDIR = lib
 LIBLEAFDIR_x86_32 = lib
-LIBLEAFDIR_x86_64 ?= lib64
+LIBLEAFDIR_x86_64 ?= lib
 LIBDIR = $(PREFIX)/$(LIBLEAFDIR)
 LIBDIR_x86_32 = $(PREFIX)/$(LIBLEAFDIR_x86_32)
 LIBDIR_x86_64 = $(PREFIX)/$(LIBLEAFDIR_x86_64)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:35:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQap-0006Vj-V8; Mon, 20 Feb 2012 10:35:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RzQan-0006Va-J1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:35:37 +0000
Received: from [85.158.139.83:5964] by server-9.bemta-5.messagelabs.com id
	AC/F2-30171-8F1224F4; Mon, 20 Feb 2012 10:35:36 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329734135!15777715!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzQ3MDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23811 invoked from network); 20 Feb 2012 10:35:35 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-3.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 10:35:35 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1KAZWTM017758;
	Mon, 20 Feb 2012 05:35:32 -0500
Date: Mon, 20 Feb 2012 05:35:32 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120217185836.GA23942@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> > > Hmm, I should maybe self-nack this. The bug that led me to
> > > writing
> > > it is likely only with older tooling, such as RHEL5's. The
> > > problem
> > > was if you attempted to detach a mounted disk twice, then the
> > > second
> > > time it would succeed. The guest had flipped to Closing on the
> > > first
> > > try, and thus didn't issue an error to xenbus on the second. I
> > > see
> > 
> > Actually, it's even worse than I thought. Just a single attempt to
> > detach the device will cause the guest grief (with RHEL5's tools
> > anyway). Once xenbus shows the device is in the Closing state, then
> > tasks accessing the device may hang.
> > 
> > > The reason I only say maybe self-nack though, is because this
> > > state
> > > change seemed to be thrown in with another fix[1]. I'm not sure
> > > if
> > > the new behavior on legacy hosts was considered or not. If not,
> > > then
> > > we can consider it now. Do we want to have deferred asynch
> > > detaches
> > > over protecting the guest from multiple detach calls on legacy
> > > hosts?
> > > 
> > 
> > I guess we can keep the feature and protect the guest with a patch
> > like
> > I'll send in a moment. It doesn't really work for me with a RHEL5
> > host
> > though. The deferred close works from the pov of the guest, but the
> > state of the block device gets left in Closed after the guest
> > unmounts
> > it, and then RHEL5's tools can't detach/reattach it. If the
> > deferred
> > close ever worked on other Xen hosts though, then I don't believe
> > this
> > patch would break it, and it will also keep the guest safe when run
> > on
> > hosts that don't treat state=Closing the way it currently expects.
> 
> There was another fix that sounds similar to this in the backend.
> 6f5986bce558e64fe867bff600a2127a3cb0c006
> 

Thanks for the pointer. It doesn't look like the upstream 2.6.18
tree has that, but it probably would be a good idea there too.
However, even with that ability to patch backends, we probably
want the frontends to be more robust on legacy backends for a while
longer. So, it probably would be best to avoid changing the state to
Closing while we're still busy, unless it's absolutely necessary.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:35:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQap-0006Vj-V8; Mon, 20 Feb 2012 10:35:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RzQan-0006Va-J1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:35:37 +0000
Received: from [85.158.139.83:5964] by server-9.bemta-5.messagelabs.com id
	AC/F2-30171-8F1224F4; Mon, 20 Feb 2012 10:35:36 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329734135!15777715!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzQ3MDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23811 invoked from network); 20 Feb 2012 10:35:35 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-3.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 10:35:35 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1KAZWTM017758;
	Mon, 20 Feb 2012 05:35:32 -0500
Date: Mon, 20 Feb 2012 05:35:32 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120217185836.GA23942@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> > > Hmm, I should maybe self-nack this. The bug that led me to
> > > writing
> > > it is likely only with older tooling, such as RHEL5's. The
> > > problem
> > > was if you attempted to detach a mounted disk twice, then the
> > > second
> > > time it would succeed. The guest had flipped to Closing on the
> > > first
> > > try, and thus didn't issue an error to xenbus on the second. I
> > > see
> > 
> > Actually, it's even worse than I thought. Just a single attempt to
> > detach the device will cause the guest grief (with RHEL5's tools
> > anyway). Once xenbus shows the device is in the Closing state, then
> > tasks accessing the device may hang.
> > 
> > > The reason I only say maybe self-nack though, is because this
> > > state
> > > change seemed to be thrown in with another fix[1]. I'm not sure
> > > if
> > > the new behavior on legacy hosts was considered or not. If not,
> > > then
> > > we can consider it now. Do we want to have deferred asynch
> > > detaches
> > > over protecting the guest from multiple detach calls on legacy
> > > hosts?
> > > 
> > 
> > I guess we can keep the feature and protect the guest with a patch
> > like
> > I'll send in a moment. It doesn't really work for me with a RHEL5
> > host
> > though. The deferred close works from the pov of the guest, but the
> > state of the block device gets left in Closed after the guest
> > unmounts
> > it, and then RHEL5's tools can't detach/reattach it. If the
> > deferred
> > close ever worked on other Xen hosts though, then I don't believe
> > this
> > patch would break it, and it will also keep the guest safe when run
> > on
> > hosts that don't treat state=Closing the way it currently expects.
> 
> There was another fix that sounds similar to this in the backend.
> 6f5986bce558e64fe867bff600a2127a3cb0c006
> 

Thanks for the pointer. It doesn't look like the upstream 2.6.18
tree has that, but it probably would be a good idea there too.
However, even with that ability to patch backends, we probably
want the frontends to be more robust on legacy backends for a while
longer. So, it probably would be best to avoid changing the state to
Closing while we're still busy, unless it's absolutely necessary.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:37:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:37:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQcK-0006dY-F7; Mon, 20 Feb 2012 10:37:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQcJ-0006d4-Fs
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:37:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329734224!13868531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6305 invoked from network); 20 Feb 2012 10:37:04 -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;
	20 Feb 2012 10:37:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804263"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:37:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:37:04 +0000
Message-ID: <1329734222.3990.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:37:02 +0000
In-Reply-To: <1329506127-30969-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/6] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> A mutex created with pthread_mutex_init, like ctx->lock, may need to
> be destroyed with pthread_mutex_destroy.
> 
> Also, previously, if libxl__init_recursive_mutex failed, the nascent
> ctx would be leaked.  Add some comments which will hopefully make
> these kind of mistakes less likely in future.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |   17 +++++++++++++----
>  1 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7735223..fd890cf 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      memset(ctx, 0, sizeof(libxl_ctx));
>      ctx->lg = lg;
>  
> -    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
> -        return ERROR_FAIL;
> -    }
> +    /* First initialise pointers (cannot fail) */
>  
>      LIBXL_TAILQ_INIT(&ctx->occurred);
>  
> @@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      LIBXL_TAILQ_INIT(&ctx->death_list);
>      libxl__ev_xswatch_init(&ctx->death_watch);
>  
> +    /* The mutex is special because we can't idempotently destroy it */
> +
> +    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
> +        free(ctx);
> +        ctx = 0;
> +    }
> +
> +    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
> +
>      rc = libxl__poller_init(ctx, &ctx->poller_app);
>      if (rc) goto out;
>  
> @@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
>  
>      discard_events(&ctx->occurred);
>  
> +    pthread_mutex_destroy(&ctx->lock);
> +
>      GC_FREE;
>      free(ctx);
>      return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:37:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:37:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQcK-0006dY-F7; Mon, 20 Feb 2012 10:37:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQcJ-0006d4-Fs
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:37:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329734224!13868531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6305 invoked from network); 20 Feb 2012 10:37:04 -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;
	20 Feb 2012 10:37:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804263"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:37:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:37:04 +0000
Message-ID: <1329734222.3990.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:37:02 +0000
In-Reply-To: <1329506127-30969-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/6] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> A mutex created with pthread_mutex_init, like ctx->lock, may need to
> be destroyed with pthread_mutex_destroy.
> 
> Also, previously, if libxl__init_recursive_mutex failed, the nascent
> ctx would be leaked.  Add some comments which will hopefully make
> these kind of mistakes less likely in future.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |   17 +++++++++++++----
>  1 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 7735223..fd890cf 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      memset(ctx, 0, sizeof(libxl_ctx));
>      ctx->lg = lg;
>  
> -    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
> -        return ERROR_FAIL;
> -    }
> +    /* First initialise pointers (cannot fail) */
>  
>      LIBXL_TAILQ_INIT(&ctx->occurred);
>  
> @@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      LIBXL_TAILQ_INIT(&ctx->death_list);
>      libxl__ev_xswatch_init(&ctx->death_watch);
>  
> +    /* The mutex is special because we can't idempotently destroy it */
> +
> +    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
> +        free(ctx);
> +        ctx = 0;
> +    }
> +
> +    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
> +
>      rc = libxl__poller_init(ctx, &ctx->poller_app);
>      if (rc) goto out;
>  
> @@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
>  
>      discard_events(&ctx->occurred);
>  
> +    pthread_mutex_destroy(&ctx->lock);
> +
>      GC_FREE;
>      free(ctx);
>      return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:38:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQdD-0006ia-U3; Mon, 20 Feb 2012 10:38:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RzQdB-0006i5-UW
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:38:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329734278!9786966!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11005 invoked from network); 20 Feb 2012 10:37:59 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.11)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Feb 2012 10:37:59 -0000
Received: from mail82-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 20 Feb 2012 10:37:55 +0000
Received: from mail82-tx2 (localhost [127.0.0.1])	by mail82-tx2-R.bigfish.com
	(Postfix) with ESMTP id 574B9140196;
	Mon, 20 Feb 2012 10:37:54 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail82-tx2 (localhost.localdomain [127.0.0.1]) by mail82-tx2
	(MessageSwitch) id 1329734272481319_30995;
	Mon, 20 Feb 2012 10:37:52 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.246])	by
	mail82-tx2.bigfish.com (Postfix) with ESMTP id 709E0240046;
	Mon, 20 Feb 2012 10:37:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id
	14.1.225.23; Mon, 20 Feb 2012 10:37:50 +0000
X-WSS-ID: 0LZOTJ3-02-0U9-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 28EF3C80A8;	Mon, 20 Feb 2012 04:37:50 -0600 (CST)
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, 20 Feb 2012 04:37:56 -0600
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.289.1;
	Mon, 20 Feb 2012 04:37:52 -0600
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; Mon, 20 Feb 2012
	05:37:51 -0500
Message-ID: <4F42227D.8090801@amd.com>
Date: Mon, 20 Feb 2012 11:37:49 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328788790.6133.148.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 12:59, Ian Campbell wrote:
> On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
>> Pass PYTHON=$(PYTHON) to gmake when building seabios.
>> This fixes seabios build error
>> 'python not found'
>> along with the patches from Kevin O'Connor.
>>
>> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
>
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>

Please apply this patch and update SeaBIOS.
Keven O'Connors patches went upstream on Feb 8th.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:38:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQdD-0006ia-U3; Mon, 20 Feb 2012 10:38:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RzQdB-0006i5-UW
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:38:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329734278!9786966!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11005 invoked from network); 20 Feb 2012 10:37:59 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.11)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Feb 2012 10:37:59 -0000
Received: from mail82-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 20 Feb 2012 10:37:55 +0000
Received: from mail82-tx2 (localhost [127.0.0.1])	by mail82-tx2-R.bigfish.com
	(Postfix) with ESMTP id 574B9140196;
	Mon, 20 Feb 2012 10:37:54 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail82-tx2 (localhost.localdomain [127.0.0.1]) by mail82-tx2
	(MessageSwitch) id 1329734272481319_30995;
	Mon, 20 Feb 2012 10:37:52 +0000 (UTC)
Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.246])	by
	mail82-tx2.bigfish.com (Postfix) with ESMTP id 709E0240046;
	Mon, 20 Feb 2012 10:37:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id
	14.1.225.23; Mon, 20 Feb 2012 10:37:50 +0000
X-WSS-ID: 0LZOTJ3-02-0U9-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 28EF3C80A8;	Mon, 20 Feb 2012 04:37:50 -0600 (CST)
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, 20 Feb 2012 04:37:56 -0600
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.289.1;
	Mon, 20 Feb 2012 04:37:52 -0600
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; Mon, 20 Feb 2012
	05:37:51 -0500
Message-ID: <4F42227D.8090801@amd.com>
Date: Mon, 20 Feb 2012 11:37:49 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
In-Reply-To: <1328788790.6133.148.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/09/12 12:59, Ian Campbell wrote:
> On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
>> Pass PYTHON=$(PYTHON) to gmake when building seabios.
>> This fixes seabios build error
>> 'python not found'
>> along with the patches from Kevin O'Connor.
>>
>> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
>
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>

Please apply this patch and update SeaBIOS.
Keven O'Connors patches went upstream on Feb 8th.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:38:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQdM-0006jv-B5; Mon, 20 Feb 2012 10:38:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQdK-0006il-1E
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329734287!9106960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9762 invoked from network); 20 Feb 2012 10:38:08 -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;
	20 Feb 2012 10:38:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:38:07 +0000
Message-ID: <1329734286.3990.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:38:06 +0000
In-Reply-To: <1329506127-30969-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> libxl's task has become too complicated (particularly in the presence
> of both forking and multithreading) to support reuse of the same
> libxl_ctx after fork.
> 
> So abolish libxl_ctx_fork.  xl instead simply initialises a new
> libxl_ctx.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:38:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQdM-0006jv-B5; Mon, 20 Feb 2012 10:38:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQdK-0006il-1E
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329734287!9106960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9762 invoked from network); 20 Feb 2012 10:38:08 -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;
	20 Feb 2012 10:38:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:38:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:38:07 +0000
Message-ID: <1329734286.3990.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:38:06 +0000
In-Reply-To: <1329506127-30969-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/6] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> libxl's task has become too complicated (particularly in the presence
> of both forking and multithreading) to support reuse of the same
> libxl_ctx after fork.
> 
> So abolish libxl_ctx_fork.  xl instead simply initialises a new
> libxl_ctx.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:45:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQk1-0007By-5J; Mon, 20 Feb 2012 10:45:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RzQk0-0007Bo-1b
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:45:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329734698!4839328!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16330 invoked from network); 20 Feb 2012 10:45:00 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:45:00 -0000
Received: by iaeh11 with SMTP id h11so42670195iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 02:44:58 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.154.200 as permitted sender) client-ip=10.50.154.200; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.154.200 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.154.200])
	by 10.50.154.200 with SMTP id vq8mr11819733igb.14.1329734698608
	(num_hops = 1); Mon, 20 Feb 2012 02:44:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=+8xXcllFB0QA+fTnyXplQNb+vqnRRguqIXU447ENkD8=;
	b=G1FCIvv8pQPaUhwa8L2JhA6MkcbaRh2t9/Y778DLLC7genp2loKVYMWzF/UKrvioFm
	b8Dt+Db6OGmXhzPLY7EG8Bc7cLEBJ9RXpYOienvVOpNY+Ke9Rq29I60SZD2ny2HMkC3C
	YKbMuSeUuWFjO2F/7pMMvj4XgFLepzRvu1CmQ=
MIME-Version: 1.0
Received: by 10.50.154.200 with SMTP id vq8mr9571063igb.14.1329734698541; Mon,
	20 Feb 2012 02:44:58 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Mon, 20 Feb 2012 02:44:58 -0800 (PST)
In-Reply-To: <1329496998.3131.131.camel@zakaz.uk.xensource.com>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 10:44:58 +0000
X-Google-Sender-Auth: hdeC-h5aJHmHZsB2hhA9pMKBiTY
Message-ID: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 4:43 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> My point is that the memory knobs should be exposed to the user of xl as
> semantically meaningful options without the need to refer to "the paging
> target" or "the balloon target" which is why there should not IMHO be
> "xl commands to adjust just ballooning and/or paging".

I disagree with this.  I agree completely that the default interface
should just be, "How much memory is my VM using", and balloon drivers
or paging shouldn't have to be of concern to them.  But there are
times when admins will need to dig in deeper and play with specific
values.  We should make the common case simple, and the complicated
case possible.

What about the following interface:

maxmem=X
memory=M
xenpaging=[off|on|delay]
pagingdelay=60
pagingdelayboot=180

xl mem-set domain M
 xenpaging off: Set balloon target to M
 xenpaging on: Set paging target to M
 xenpaging delay: Set balloon target to M, and wait for actual memory
to reach M.  If it hasn't reached it by $paging_delay seconds, set
balloon target to M.

xl mem-balloon-set domain M
 Set balloon target to M
xl mem-paging-set domain M
 Set paging target to M

Start-of-day:
 xenpaging off: Set balloon target to M, use PoD
 xenpaging on: ??
 xenpaging delay: Set balloon target to M, use PoD.  Wait
$pagingdelayboot seconds, if target not reached, set paging?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:45:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQk1-0007By-5J; Mon, 20 Feb 2012 10:45:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RzQk0-0007Bo-1b
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:45:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329734698!4839328!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16330 invoked from network); 20 Feb 2012 10:45:00 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 10:45:00 -0000
Received: by iaeh11 with SMTP id h11so42670195iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 02:44:58 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.154.200 as permitted sender) client-ip=10.50.154.200; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.154.200 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.154.200])
	by 10.50.154.200 with SMTP id vq8mr11819733igb.14.1329734698608
	(num_hops = 1); Mon, 20 Feb 2012 02:44:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=+8xXcllFB0QA+fTnyXplQNb+vqnRRguqIXU447ENkD8=;
	b=G1FCIvv8pQPaUhwa8L2JhA6MkcbaRh2t9/Y778DLLC7genp2loKVYMWzF/UKrvioFm
	b8Dt+Db6OGmXhzPLY7EG8Bc7cLEBJ9RXpYOienvVOpNY+Ke9Rq29I60SZD2ny2HMkC3C
	YKbMuSeUuWFjO2F/7pMMvj4XgFLepzRvu1CmQ=
MIME-Version: 1.0
Received: by 10.50.154.200 with SMTP id vq8mr9571063igb.14.1329734698541; Mon,
	20 Feb 2012 02:44:58 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Mon, 20 Feb 2012 02:44:58 -0800 (PST)
In-Reply-To: <1329496998.3131.131.camel@zakaz.uk.xensource.com>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 10:44:58 +0000
X-Google-Sender-Auth: hdeC-h5aJHmHZsB2hhA9pMKBiTY
Message-ID: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 4:43 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> My point is that the memory knobs should be exposed to the user of xl as
> semantically meaningful options without the need to refer to "the paging
> target" or "the balloon target" which is why there should not IMHO be
> "xl commands to adjust just ballooning and/or paging".

I disagree with this.  I agree completely that the default interface
should just be, "How much memory is my VM using", and balloon drivers
or paging shouldn't have to be of concern to them.  But there are
times when admins will need to dig in deeper and play with specific
values.  We should make the common case simple, and the complicated
case possible.

What about the following interface:

maxmem=X
memory=M
xenpaging=[off|on|delay]
pagingdelay=60
pagingdelayboot=180

xl mem-set domain M
 xenpaging off: Set balloon target to M
 xenpaging on: Set paging target to M
 xenpaging delay: Set balloon target to M, and wait for actual memory
to reach M.  If it hasn't reached it by $paging_delay seconds, set
balloon target to M.

xl mem-balloon-set domain M
 Set balloon target to M
xl mem-paging-set domain M
 Set paging target to M

Start-of-day:
 xenpaging off: Set balloon target to M, use PoD
 xenpaging on: ??
 xenpaging delay: Set balloon target to M, use PoD.  Wait
$pagingdelayboot seconds, if target not reached, set paging?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:51:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQqC-0007Sf-3g; Mon, 20 Feb 2012 10:51:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RzQqA-0007SP-UO
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:51:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329735045!53123736!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28992 invoked from network); 20 Feb 2012 10:50:46 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-12.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 10:50:46 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 8EE18D347A0;
	Mon, 20 Feb 2012 11:51:25 +0100 (CET)
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 vO9ujKwE1R+5; Mon, 20 Feb 2012 11:51:17 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 2E0D1D347C1;
	Mon, 20 Feb 2012 11:51:13 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 11:51:11 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Message-Id: <201202201151.12291.tobias.geiger@vido.info>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi!

i wanted to test these patches against 
http://xenbits.xensource.com/xen-unstable.hg but it seems to check out an 
outdated version of upstream-qemu, even with "QEMU=upstream".

Where can i check out the qemu-upstream version to which these patches apply?

Thanks and Greetings
Tobias


Am Freitag, 17. Februar 2012, 18:08:34 schrieb Anthony PERARD:
> Hi all,
> 
> This patch series introduces the PCI passthrough for Xen.
> 
> First, we have HostPCIDevice that help to access one PCI device of the
> host.
> 
> Then, there is an additions in the QEMU code, pci_check_bar_overlap.
> 
> There are also several change in pci_ids and pci_regs.
> 
> Last part, but not least, the PCI passthrough device himself. Cut in 3
> parts (or file), there is one to take care of the initialisation of a
> passthrough device. The second one handle everything about the config
> address space, there are specifics functions for every config register.
> The third one is to handle MSI.
> 
> There is a patch series on xen-devel (applied to xen-unstable) that add the
> support of setting a PCI passthrough device through QMP from libxl (xen
> tool stack). It is just a call to device_add, with the driver parametter
> hostaddr="0000:07:00.1".
> 
> 
> Change since the previous set:
>   - few fix and rebased on master
>   - remove of the power management capability, keep the minimum like if it
> is always desactivated.
>   - new patch: port of patch from the qemu-xen fork.
> 
> 
> Change v5-v6:
>   - msitraslate code have been removed.
>   - code for the power management capability is removed, but will be
> re-added for the next version of the patch series as a separate patch.
> 
>   - new patch to remove a check in pci_parse_devaddr.
>   - use pci_default_config_write, so no more hack to handle the BAR mapping
> in QEMU.
>   - improve the code in general (a bit more comprehensible).
>   - update to QOM.
> 
> 
> Change v4-v5:
>   - return -errno if there is an error in host_pci_get_*
>   - rename internal function get_value to get_hex_value (and return the
> same error value has get_resource)
> 
> Change v3-v4:
>   - host_pci_get_* can now return an error, and take an extra parameter, a
>     pointer to store the wanted value.
>   - The memory_region for the PCI BAR are handled "manualy" because calling
>     pci_default_write_config was not possible, because the XenPT handle the
>     PCIIORegion it self. This make possible to do a device_remove.
>   - Introduction of PT_ERR and PT_WARN macro to print debug and error
> messages. Also, these macro as well as PT_LOG will always print the short
> BDF of the device in the guest point of view.
>   - PT_ERR is print by default (for all error messages).
>   - Some debug/error message have been improve and should be a bit more
> useful. - hw_error have been removed from the code, and have been replaced
> by either a call to qemu_system_shudown_request() (that lead to a domain
> destroy) or a failed in the initialisation of the device.
>   - Now, every patchs should compile with no error.
> 
> Change v2-v3;
>   - in host-pci-device.c:
>     - Return more usefull error code in get_ressource().
>     - Use macro in host_pci_find_ext_cap_offset instead of raw number. But
> I still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
> was before, so it's maybe ok.
>   - All use of MSI stuff in two first pci passthrough patch have been
> removed and move to the last patch.
> 
> Change v1-v2:
>   - fix style issue (checkpatch.pl)
>   - set the original authors, add some missing copyright headers
>   - HostPCIDevice:
>     - introduce HostPCIIORegions (with base_addr, size, flags)
>     - save all flags from ./resource and store it in a separate field.
>     - fix endianess on write
>     - new host_pci_dev_put function
>     - use pci.c like interface host_pci_get/set_byte/word/long (instead of
>       host_pci_read/write_)
>   - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
>   - introduce apic-msidef.h file.
>   - no more run_one_timer, if a pci device is in the middle of a power
>     transition, just "return an error" in config read/write
>   - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
>   - add msitranslate and power-mgmt ad qdev property
> 
> 
> 
> 
> 
> Allen Kay (2):
>   Introduce Xen PCI Passthrough, qdevice (1/3)
>   Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
> 
> Anthony PERARD (6):
>   pci_ids: Add INTEL_82599_VF id.
>   pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
>   pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
>   configure: Introduce --enable-xen-pci-passthrough.
>   Introduce HostPCIDevice to access a pci device on the host.
>   Introduce apic-msidef.h
> 
> Jiang Yunhong (1):
>   Introduce Xen PCI Passthrough, MSI (3/3)
> 
> Shan Haitao (1):
>   xen passthrough: clean up MSI-X table handling
> 
> Yuji Shimada (1):
>   pci.c: Add pci_check_bar_overlap
> 
>  Makefile.target                      |    6 +
>  configure                            |   25 +
>  hw/apic-msidef.h                     |   30 +
>  hw/apic.c                            |   11 +-
>  hw/host-pci-device.c                 |  278 +++++
>  hw/host-pci-device.h                 |   75 ++
>  hw/pci.c                             |   47 +
>  hw/pci.h                             |    3 +
>  hw/pci_ids.h                         |    1 +
>  hw/pci_regs.h                        |    3 +-
>  hw/xen_common.h                      |    3 +
>  hw/xen_pci_passthrough.c             |  898 ++++++++++++++++
>  hw/xen_pci_passthrough.h             |  308 ++++++
>  hw/xen_pci_passthrough_config_init.c | 1914
> ++++++++++++++++++++++++++++++++++ hw/xen_pci_passthrough_msi.c         | 
> 618 +++++++++++
>  xen-all.c                            |   12 +
>  16 files changed, 4221 insertions(+), 11 deletions(-)
>  create mode 100644 hw/apic-msidef.h
>  create mode 100644 hw/host-pci-device.c
>  create mode 100644 hw/host-pci-device.h
>  create mode 100644 hw/xen_pci_passthrough.c
>  create mode 100644 hw/xen_pci_passthrough.h
>  create mode 100644 hw/xen_pci_passthrough_config_init.c
>  create mode 100644 hw/xen_pci_passthrough_msi.c


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:51:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzQqC-0007Sf-3g; Mon, 20 Feb 2012 10:51:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RzQqA-0007SP-UO
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:51:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329735045!53123736!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28992 invoked from network); 20 Feb 2012 10:50:46 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-12.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 10:50:46 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 8EE18D347A0;
	Mon, 20 Feb 2012 11:51:25 +0100 (CET)
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 vO9ujKwE1R+5; Mon, 20 Feb 2012 11:51:17 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 2E0D1D347C1;
	Mon, 20 Feb 2012 11:51:13 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 11:51:11 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Message-Id: <201202201151.12291.tobias.geiger@vido.info>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi!

i wanted to test these patches against 
http://xenbits.xensource.com/xen-unstable.hg but it seems to check out an 
outdated version of upstream-qemu, even with "QEMU=upstream".

Where can i check out the qemu-upstream version to which these patches apply?

Thanks and Greetings
Tobias


Am Freitag, 17. Februar 2012, 18:08:34 schrieb Anthony PERARD:
> Hi all,
> 
> This patch series introduces the PCI passthrough for Xen.
> 
> First, we have HostPCIDevice that help to access one PCI device of the
> host.
> 
> Then, there is an additions in the QEMU code, pci_check_bar_overlap.
> 
> There are also several change in pci_ids and pci_regs.
> 
> Last part, but not least, the PCI passthrough device himself. Cut in 3
> parts (or file), there is one to take care of the initialisation of a
> passthrough device. The second one handle everything about the config
> address space, there are specifics functions for every config register.
> The third one is to handle MSI.
> 
> There is a patch series on xen-devel (applied to xen-unstable) that add the
> support of setting a PCI passthrough device through QMP from libxl (xen
> tool stack). It is just a call to device_add, with the driver parametter
> hostaddr="0000:07:00.1".
> 
> 
> Change since the previous set:
>   - few fix and rebased on master
>   - remove of the power management capability, keep the minimum like if it
> is always desactivated.
>   - new patch: port of patch from the qemu-xen fork.
> 
> 
> Change v5-v6:
>   - msitraslate code have been removed.
>   - code for the power management capability is removed, but will be
> re-added for the next version of the patch series as a separate patch.
> 
>   - new patch to remove a check in pci_parse_devaddr.
>   - use pci_default_config_write, so no more hack to handle the BAR mapping
> in QEMU.
>   - improve the code in general (a bit more comprehensible).
>   - update to QOM.
> 
> 
> Change v4-v5:
>   - return -errno if there is an error in host_pci_get_*
>   - rename internal function get_value to get_hex_value (and return the
> same error value has get_resource)
> 
> Change v3-v4:
>   - host_pci_get_* can now return an error, and take an extra parameter, a
>     pointer to store the wanted value.
>   - The memory_region for the PCI BAR are handled "manualy" because calling
>     pci_default_write_config was not possible, because the XenPT handle the
>     PCIIORegion it self. This make possible to do a device_remove.
>   - Introduction of PT_ERR and PT_WARN macro to print debug and error
> messages. Also, these macro as well as PT_LOG will always print the short
> BDF of the device in the guest point of view.
>   - PT_ERR is print by default (for all error messages).
>   - Some debug/error message have been improve and should be a bit more
> useful. - hw_error have been removed from the code, and have been replaced
> by either a call to qemu_system_shudown_request() (that lead to a domain
> destroy) or a failed in the initialisation of the device.
>   - Now, every patchs should compile with no error.
> 
> Change v2-v3;
>   - in host-pci-device.c:
>     - Return more usefull error code in get_ressource().
>     - Use macro in host_pci_find_ext_cap_offset instead of raw number. But
> I still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
> was before, so it's maybe ok.
>   - All use of MSI stuff in two first pci passthrough patch have been
> removed and move to the last patch.
> 
> Change v1-v2:
>   - fix style issue (checkpatch.pl)
>   - set the original authors, add some missing copyright headers
>   - HostPCIDevice:
>     - introduce HostPCIIORegions (with base_addr, size, flags)
>     - save all flags from ./resource and store it in a separate field.
>     - fix endianess on write
>     - new host_pci_dev_put function
>     - use pci.c like interface host_pci_get/set_byte/word/long (instead of
>       host_pci_read/write_)
>   - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
>   - introduce apic-msidef.h file.
>   - no more run_one_timer, if a pci device is in the middle of a power
>     transition, just "return an error" in config read/write
>   - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
>   - add msitranslate and power-mgmt ad qdev property
> 
> 
> 
> 
> 
> Allen Kay (2):
>   Introduce Xen PCI Passthrough, qdevice (1/3)
>   Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
> 
> Anthony PERARD (6):
>   pci_ids: Add INTEL_82599_VF id.
>   pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
>   pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
>   configure: Introduce --enable-xen-pci-passthrough.
>   Introduce HostPCIDevice to access a pci device on the host.
>   Introduce apic-msidef.h
> 
> Jiang Yunhong (1):
>   Introduce Xen PCI Passthrough, MSI (3/3)
> 
> Shan Haitao (1):
>   xen passthrough: clean up MSI-X table handling
> 
> Yuji Shimada (1):
>   pci.c: Add pci_check_bar_overlap
> 
>  Makefile.target                      |    6 +
>  configure                            |   25 +
>  hw/apic-msidef.h                     |   30 +
>  hw/apic.c                            |   11 +-
>  hw/host-pci-device.c                 |  278 +++++
>  hw/host-pci-device.h                 |   75 ++
>  hw/pci.c                             |   47 +
>  hw/pci.h                             |    3 +
>  hw/pci_ids.h                         |    1 +
>  hw/pci_regs.h                        |    3 +-
>  hw/xen_common.h                      |    3 +
>  hw/xen_pci_passthrough.c             |  898 ++++++++++++++++
>  hw/xen_pci_passthrough.h             |  308 ++++++
>  hw/xen_pci_passthrough_config_init.c | 1914
> ++++++++++++++++++++++++++++++++++ hw/xen_pci_passthrough_msi.c         | 
> 618 +++++++++++
>  xen-all.c                            |   12 +
>  16 files changed, 4221 insertions(+), 11 deletions(-)
>  create mode 100644 hw/apic-msidef.h
>  create mode 100644 hw/host-pci-device.c
>  create mode 100644 hw/host-pci-device.h
>  create mode 100644 hw/xen_pci_passthrough.c
>  create mode 100644 hw/xen_pci_passthrough.h
>  create mode 100644 hw/xen_pci_passthrough_config_init.c
>  create mode 100644 hw/xen_pci_passthrough_msi.c


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:56:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQuU-0007ei-05; Mon, 20 Feb 2012 10:55:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQuS-0007eM-5j
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:55:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329735348!15510913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5498 invoked from network); 20 Feb 2012 10:55: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;
	20 Feb 2012 10:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:55:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:55:32 +0000
Message-ID: <1329735330.3990.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:55:30 +0000
In-Reply-To: <1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> We introduce a new "carefd" concept, which relates to fds that we care
> about not being inherited by long-lived children.
> 
> As yet we do not use this anywherein libxl.  Until all locations in

"anywherein"

> libxl which make such fds are converted, libxl__postfork may not work
> entirely properly.  If these locations do not use O_CLOEXEC (or use
> calls for which there is no O_CLOEXEC) then multithreaded programs may
> not work properly.
> 
> This introduces a new API call libxl_postfork_child_noexec which must
> be called by applications which make long-running non-execing
> children.  Add the appropriate call to xl's postfork function.
> 
> On Linux pthread_atfork demands compilation with -pthread, so add
> PTHREAD_CFLAGS, _LDFLAGS, _LIBS to the corresponding variables in the
> libxl Makefile.  It is not clear why we got away without these before.

Since I assume the Makefile bit could safely be split out and applied,
that bit is:
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index f889115..74a0402 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -369,6 +369,16 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
>   */
>  void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> 
> +
> +/*
> + * An application which initialises a libxl_ctx in a parent process
> + * and then forks a child which does not quickly exec, must
> + * instead libxl__postfork_child_noexec in the child.  One call
> + * for all libxl contexts is sufficient.
> + */
> +void libxl_postfork_child_noexec(libxl_ctx *ctx);

Is the ctx passed here required to be one of the existing ctx's or a
newly allocated one in this context?

> +
> +
>  #endif
> 
>  /*
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> new file mode 100644
> index 0000000..66d0ee0
> --- /dev/null
> +++ b/tools/libxl/libxl_fork.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal child process machinery for use by other parts of libxl
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * carefd arrangements
> + *
> + * carefd_begin and _unlock take out the no_forking lock, which we
> + * also take and release in our pthread_atfork handlers.  So when this
> + * lock is held the whole process cannot fork.  We therefore protect
> + * our fds from leaking into children made by other threads.
> + *
> + * We maintain a list of all the carefds, so that if the application
> + * wants to fork a long-running but non-execing child, we can close
> + * them all.
> + *
> + * So the record function sets CLOEXEC for the benefit of execing
> + * children, and makes a note of the fd for the benefit of non-execing
> + * ones.
> + */
> +
> +struct libxl__carefd {
> +    LIBXL_LIST_ENTRY(libxl__carefd) entry;
> +    int fd;
> +};
> +
> +static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;

We previously had trouble with PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
not being defined on NetBSD.

http://www.daemon-systems.org/man/pthread_mutex_init.3.html suggests
PTHREAD_MUTEX_INITIALIZER is but perhaps we should confirm?

> +static int atfork_registered;

Does pthread_atfork persist into the children?

If the parent has set this then it will be set for the child too, which
if the answer to my question is "No" is a problem.

I suspect the answer is yes though.

> +static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
> +    LIBXL_LIST_HEAD_INITIALIZER(carefds);
> +
> +static void atfork_lock(void)
> +{
> +    int r = pthread_mutex_lock(&no_forking);
> +    assert(!r);
> +}
> +
> +static void atfork_unlock(void)
> +{
> +    int r = pthread_mutex_unlock(&no_forking);
> +    assert(!r);
> +}
> +
> +int libxl__atfork_init(libxl_ctx *ctx)
> +{
> +    int r, rc;
> +
> +    atfork_lock();
> +    if (atfork_registered)

Missing an unlock?

> +        return 0;
> +
> +    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
> +    if (r) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "pthread_atfork failed");
> +        rc = ERROR_NOMEM;
> +        goto out;
> +    }
> +
> +    atfork_registered = 1;
> +    rc = 0;
> + out:
> +    atfork_unlock();
> +    return rc;
> +}
> +
> +void libxl__carefd_begin(void) { atfork_lock(); }
> +void libxl__carefd_unlock(void) { atfork_unlock(); }

This naming seems asymmetric.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 10:56:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 10: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.xensource.com>)
	id 1RzQuU-0007ei-05; Mon, 20 Feb 2012 10:55:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzQuS-0007eM-5j
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 10:55:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329735348!15510913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5498 invoked from network); 20 Feb 2012 10:55: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;
	20 Feb 2012 10:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10804874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:55:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 10:55:32 +0000
Message-ID: <1329735330.3990.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 10:55:30 +0000
In-Reply-To: <1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> We introduce a new "carefd" concept, which relates to fds that we care
> about not being inherited by long-lived children.
> 
> As yet we do not use this anywherein libxl.  Until all locations in

"anywherein"

> libxl which make such fds are converted, libxl__postfork may not work
> entirely properly.  If these locations do not use O_CLOEXEC (or use
> calls for which there is no O_CLOEXEC) then multithreaded programs may
> not work properly.
> 
> This introduces a new API call libxl_postfork_child_noexec which must
> be called by applications which make long-running non-execing
> children.  Add the appropriate call to xl's postfork function.
> 
> On Linux pthread_atfork demands compilation with -pthread, so add
> PTHREAD_CFLAGS, _LDFLAGS, _LIBS to the corresponding variables in the
> libxl Makefile.  It is not clear why we got away without these before.

Since I assume the Makefile bit could safely be split out and applied,
that bit is:
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index f889115..74a0402 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -369,6 +369,16 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
>   */
>  void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
> 
> +
> +/*
> + * An application which initialises a libxl_ctx in a parent process
> + * and then forks a child which does not quickly exec, must
> + * instead libxl__postfork_child_noexec in the child.  One call
> + * for all libxl contexts is sufficient.
> + */
> +void libxl_postfork_child_noexec(libxl_ctx *ctx);

Is the ctx passed here required to be one of the existing ctx's or a
newly allocated one in this context?

> +
> +
>  #endif
> 
>  /*
> diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
> new file mode 100644
> index 0000000..66d0ee0
> --- /dev/null
> +++ b/tools/libxl/libxl_fork.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +/*
> + * Internal child process machinery for use by other parts of libxl
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +
> +/*
> + * carefd arrangements
> + *
> + * carefd_begin and _unlock take out the no_forking lock, which we
> + * also take and release in our pthread_atfork handlers.  So when this
> + * lock is held the whole process cannot fork.  We therefore protect
> + * our fds from leaking into children made by other threads.
> + *
> + * We maintain a list of all the carefds, so that if the application
> + * wants to fork a long-running but non-execing child, we can close
> + * them all.
> + *
> + * So the record function sets CLOEXEC for the benefit of execing
> + * children, and makes a note of the fd for the benefit of non-execing
> + * ones.
> + */
> +
> +struct libxl__carefd {
> +    LIBXL_LIST_ENTRY(libxl__carefd) entry;
> +    int fd;
> +};
> +
> +static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;

We previously had trouble with PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
not being defined on NetBSD.

http://www.daemon-systems.org/man/pthread_mutex_init.3.html suggests
PTHREAD_MUTEX_INITIALIZER is but perhaps we should confirm?

> +static int atfork_registered;

Does pthread_atfork persist into the children?

If the parent has set this then it will be set for the child too, which
if the answer to my question is "No" is a problem.

I suspect the answer is yes though.

> +static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
> +    LIBXL_LIST_HEAD_INITIALIZER(carefds);
> +
> +static void atfork_lock(void)
> +{
> +    int r = pthread_mutex_lock(&no_forking);
> +    assert(!r);
> +}
> +
> +static void atfork_unlock(void)
> +{
> +    int r = pthread_mutex_unlock(&no_forking);
> +    assert(!r);
> +}
> +
> +int libxl__atfork_init(libxl_ctx *ctx)
> +{
> +    int r, rc;
> +
> +    atfork_lock();
> +    if (atfork_registered)

Missing an unlock?

> +        return 0;
> +
> +    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
> +    if (r) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "pthread_atfork failed");
> +        rc = ERROR_NOMEM;
> +        goto out;
> +    }
> +
> +    atfork_registered = 1;
> +    rc = 0;
> + out:
> +    atfork_unlock();
> +    return rc;
> +}
> +
> +void libxl__carefd_begin(void) { atfork_lock(); }
> +void libxl__carefd_unlock(void) { atfork_unlock(); }

This naming seems asymmetric.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:13:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11: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.xensource.com>)
	id 1RzRAi-00089l-DG; Mon, 20 Feb 2012 11:12:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzRAg-00089c-IA
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 11:12:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329736356!9113978!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16571 invoked from network); 20 Feb 2012 11:12:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 11:12:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329736355; l=405;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=oCqIa6aC9G1ZHjSmWxjIdzJ8//A=;
	b=hW1iCVqDYksUafsiBhmQx2aHyJ/+mEiGjDy5DoF9LKBZXnhL4ZsXLKCkzfQJgVemcL/
	Kj5U3ruz0kJvaLHzFPqHaHzyeGM2S24INubqTt5Dcx8i1TE6kpv6o73AeOvQLFn5mcZGQ
	z7qeDEb2qD2QknvZfQtZ06EO0CITOpBvTUc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo45) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 60130co1KABY7T ;
	Mon, 20 Feb 2012 12:12:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 959F818638; Mon, 20 Feb 2012 12:12:30 +0100 (CET)
Date: Mon, 20 Feb 2012 12:12:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120220111230.GA5856@aepfle.de>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, George Dunlap wrote:

> Start-of-day:
>  xenpaging off: Set balloon target to M, use PoD
>  xenpaging on: ??
>  xenpaging delay: Set balloon target to M, use PoD.  Wait
> $pagingdelayboot seconds, if target not reached, set paging?

Is the delay required?
If paging and PoD target is M, xenpaging will do nothing because the
guest can not exceed M (it will crash with OOM).

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:13:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11: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.xensource.com>)
	id 1RzRAi-00089l-DG; Mon, 20 Feb 2012 11:12:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzRAg-00089c-IA
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 11:12:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329736356!9113978!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16571 invoked from network); 20 Feb 2012 11:12:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 11:12:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329736355; l=405;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=oCqIa6aC9G1ZHjSmWxjIdzJ8//A=;
	b=hW1iCVqDYksUafsiBhmQx2aHyJ/+mEiGjDy5DoF9LKBZXnhL4ZsXLKCkzfQJgVemcL/
	Kj5U3ruz0kJvaLHzFPqHaHzyeGM2S24INubqTt5Dcx8i1TE6kpv6o73AeOvQLFn5mcZGQ
	z7qeDEb2qD2QknvZfQtZ06EO0CITOpBvTUc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo45) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 60130co1KABY7T ;
	Mon, 20 Feb 2012 12:12:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 959F818638; Mon, 20 Feb 2012 12:12:30 +0100 (CET)
Date: Mon, 20 Feb 2012 12:12:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120220111230.GA5856@aepfle.de>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, George Dunlap wrote:

> Start-of-day:
>  xenpaging off: Set balloon target to M, use PoD
>  xenpaging on: ??
>  xenpaging delay: Set balloon target to M, use PoD.  Wait
> $pagingdelayboot seconds, if target not reached, set paging?

Is the delay required?
If paging and PoD target is M, xenpaging will do nothing because the
guest can not exceed M (it will crash with OOM).

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:32:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11:32:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzRTu-0008U3-6R; Mon, 20 Feb 2012 11:32:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzRTs-0008Ty-TJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 11:32:33 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329737544!15028432!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8550 invoked from network); 20 Feb 2012 11:32:26 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 11:32:26 -0000
Received: by obcuy19 with SMTP id uy19so17687645obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 03:32:24 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.182.36.106 as permitted sender) client-ip=10.182.36.106; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.182.36.106 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.182.36.106])
	by 10.182.36.106 with SMTP id p10mr12591414obj.55.1329737544419
	(num_hops = 1); Mon, 20 Feb 2012 03:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=AI2XK27MHyhbaOCpx6ftgXnOYVr2KJjCcVLZ+E+rCtg=;
	b=QkCGwAd0U4+J0HOADEaSRygwIAdIxLzsukH8282A+w9+N4QD9G9I9aqKH/KYFyvRVe
	gGq0akWO+pm4n1nfN0OCaU4TdNgYba5efPM4vHjBPkeyKGtfB5XbrYo/Tczr9NZToO84
	tlYZS5Dsa1RWP863OQuR19rOf2T7imztkPbWo=
Received: by 10.182.36.106 with SMTP id p10mr10707714obj.55.1329737542396;
	Mon, 20 Feb 2012 03:32:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 20 Feb 2012 03:31:52 -0800 (PST)
In-Reply-To: <201202201151.12291.tobias.geiger@vido.info>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 11:31:52 +0000
X-Google-Sender-Auth: K6aYIrBUJ-UWhy6n-C0T-RFH0Mw
Message-ID: <CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 10:51, Tobias Geiger <tobias.geiger@vido.info> wrote:
> i wanted to test these patches against
> http://xenbits.xensource.com/xen-unstable.hg but it seems to check out an
> outdated version of upstream-qemu, even with "QEMU=upstream".
>
> Where can i check out the qemu-upstream version to which these patches apply?

Hi,

http://git.qemu.org/git/qemu.git or git://git.qemu.org/qemu.git

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:32:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11:32:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzRTu-0008U3-6R; Mon, 20 Feb 2012 11:32:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzRTs-0008Ty-TJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 11:32:33 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329737544!15028432!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8550 invoked from network); 20 Feb 2012 11:32:26 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 11:32:26 -0000
Received: by obcuy19 with SMTP id uy19so17687645obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 03:32:24 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.182.36.106 as permitted sender) client-ip=10.182.36.106; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.182.36.106 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.182.36.106])
	by 10.182.36.106 with SMTP id p10mr12591414obj.55.1329737544419
	(num_hops = 1); Mon, 20 Feb 2012 03:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=AI2XK27MHyhbaOCpx6ftgXnOYVr2KJjCcVLZ+E+rCtg=;
	b=QkCGwAd0U4+J0HOADEaSRygwIAdIxLzsukH8282A+w9+N4QD9G9I9aqKH/KYFyvRVe
	gGq0akWO+pm4n1nfN0OCaU4TdNgYba5efPM4vHjBPkeyKGtfB5XbrYo/Tczr9NZToO84
	tlYZS5Dsa1RWP863OQuR19rOf2T7imztkPbWo=
Received: by 10.182.36.106 with SMTP id p10mr10707714obj.55.1329737542396;
	Mon, 20 Feb 2012 03:32:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 20 Feb 2012 03:31:52 -0800 (PST)
In-Reply-To: <201202201151.12291.tobias.geiger@vido.info>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 11:31:52 +0000
X-Google-Sender-Auth: K6aYIrBUJ-UWhy6n-C0T-RFH0Mw
Message-ID: <CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 10:51, Tobias Geiger <tobias.geiger@vido.info> wrote:
> i wanted to test these patches against
> http://xenbits.xensource.com/xen-unstable.hg but it seems to check out an
> outdated version of upstream-qemu, even with "QEMU=upstream".
>
> Where can i check out the qemu-upstream version to which these patches apply?

Hi,

http://git.qemu.org/git/qemu.git or git://git.qemu.org/qemu.git

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:56:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzRqS-0000Ik-5p; Mon, 20 Feb 2012 11:55:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzRqP-0000Ib-Ra
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 11:55:50 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329738942!14082915!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10718 invoked from network); 20 Feb 2012 11:55:43 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2012 11:55:43 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzRqH-0000Z8-Jg
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 03:55:41 -0800
Date: Mon, 20 Feb 2012 03:55:41 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329738941603-5498806.post@n5.nabble.com>
In-Reply-To: <4F3E7E2F.5@vido.info>
References: <1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
	<1329478339260-5492208.post@n5.nabble.com> <4F3E7E2F.5@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi again,
Let's assume that "I/O virtualisation enabled" is the only required VT-d
option.

After using pci-stub for seize the graphic card I can see that it is
available in the assignable devices:
  root@debian:~# xm pci-list-assignable-devices
  0000:01:00.0
  0000:01:00.1
I can see it in Dom0 too:
  root@debian:~# lspci | grep nVidia
  01:00.0 VGA compatible controller: nVidia Corporation GF104 [GeForce GTX
460] (rev a1)
  01:00.1 Audio device: nVidia Corporation GF104 High Definition Audio
Controller (rev a1)
So now the nvidia card (which I understand that has an audio part too) can
be assigned to the Windows guest.
I use the following config file:
root@debian:~# cat /etc/xen/win01.cfg
  kernel = "/usr/lib/xen/boot/hvmloader"
  builder='hvm'
  vcpus = 1
  name = "winXP"
  #vif = [ 'type=ioemu, bridge=xenbr0' ]
  #viridian = 1
  gfx_passthru=0
  #pci=['01:00.0']
  pci = [ '01:00.0', '01:00.1' ]
  monitor=1
  acpi = 1
  apic = 1
  pae = 1
  disk = [ 'file:/home/xen/domains/win01/disk.img,ioemu:hda,w',
'file:/home/javier/winxpSP3.iso,hdc:cdrom,r' ]
  device_model = "/usr/lib/xen/bin/qemu-dm"
  boot="c"
  sdl=0
  vnc=1
  vncconsole=1
 #vncpasswd=''
  serial='pty'
  usbdevice='tablet'
  on_poweroff='destroy'
  on_reboot='destroy'
  on_crash='restart'

I create the guest using another PC with ssh conection (putty) because when
I create the guest the host screen goes black due to the graphic card is not
owned by Dom0 anymore. 
Well, the error appear here and the guest is not started:
  root@debian:~# xm create win01.cfg
  Using config file "/etc/xen/win01.cfg".
  Error: Timed out waiting for device model action

Just to be sure, I think my Dom0 kernel is well configured:

  root@debian:~# cat /boot/config-2.6.32.45 | grep XEN
  CONFIG_XEN=y
  CONFIG_XEN_PVHVM=y
  CONFIG_XEN_MAX_DOMAIN_MEMORY=128
  CONFIG_XEN_SAVE_RESTORE=y
  CONFIG_XEN_DEBUG_FS=y
  CONFIG_SWIOTLB_XEN=y
  CONFIG_MICROCODE_XEN=y
  CONFIG_XEN_DOM0=y
  CONFIG_XEN_PRIVILEGED_GUEST=y
  CONFIG_XEN_DOM0_PCI=y
  CONFIG_XEN_PCI_PASSTHROUGH=y
  CONFIG_PCI_XEN=y
  CONFIG_XEN_PCIDEV_FRONTEND=y
  CONFIG_XEN_BLKDEV_FRONTEND=y
  CONFIG_NETXEN_NIC=m
  CONFIG_XEN_NETDEV_FRONTEND=m
  CONFIG_XEN_KBDDEV_FRONTEND=y
  CONFIG_HVC_XEN=y
  CONFIG_XEN_WDT=y
  CONFIG_XEN_FBDEV_FRONTEND=y
  CONFIG_XEN_BALLOON=y
  CONFIG_XEN_SCRUB_PAGES=y
  CONFIG_XEN_DEV_EVTCHN=y
  CONFIG_XEN_BACKEND=y
  CONFIG_XEN_NETDEV_BACKEND=y
  CONFIG_XEN_BLKDEV_BACKEND=y
  CONFIG_XEN_BLKDEV_TAP=m
  CONFIG_XEN_BLKBACK_PAGEMAP=y
  CONFIG_XEN_PCIDEV_BACKEND=y
  # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
  CONFIG_XEN_PCIDEV_BACKEND_PASS=y
  # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
  # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
  # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
  CONFIG_XENFS=y
  CONFIG_XEN_COMPAT_XENFS=y
  CONFIG_XEN_SYS_HYPERVISOR=y
  CONFIG_XEN_XENBUS_FRONTEND=y
  CONFIG_XEN_GNTDEV=y
  CONFIG_XEN_S3=y
  CONFIG_ACPI_PROCESSOR_XEN=m
  CONFIG_XEN_PLATFORM_PCI=y
  
I can create the guest removing the pci=[] line from the win01.cfg file:
  root@debian:~# xm create win01.cfg
  Using config file "/etc/xen/win01.cfg".
  Started domain winXP (id=7)
If I try to attach the graphic card in warm mode (The guest is already
started) then I see the same error:
  root@debian:~# xm pci-attach 7 01:00.0
  Error: Timed out waiting for device model action
  Usage: xm pci-attach [-o|--options=<opt>] <Domain> <domain:bus:slot.func>
[virtual slot]
  Insert a new pass-through pci device.

That's all, sorry for the long post, I just want to provide enough
information, thank you again for your time.

James

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5498806.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:56:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzRqS-0000Ik-5p; Mon, 20 Feb 2012 11:55:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzRqP-0000Ib-Ra
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 11:55:50 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329738942!14082915!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10718 invoked from network); 20 Feb 2012 11:55:43 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2012 11:55:43 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzRqH-0000Z8-Jg
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 03:55:41 -0800
Date: Mon, 20 Feb 2012 03:55:41 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329738941603-5498806.post@n5.nabble.com>
In-Reply-To: <4F3E7E2F.5@vido.info>
References: <1323123990448-5050354.post@n5.nabble.com>
	<1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
	<1329478339260-5492208.post@n5.nabble.com> <4F3E7E2F.5@vido.info>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi again,
Let's assume that "I/O virtualisation enabled" is the only required VT-d
option.

After using pci-stub for seize the graphic card I can see that it is
available in the assignable devices:
  root@debian:~# xm pci-list-assignable-devices
  0000:01:00.0
  0000:01:00.1
I can see it in Dom0 too:
  root@debian:~# lspci | grep nVidia
  01:00.0 VGA compatible controller: nVidia Corporation GF104 [GeForce GTX
460] (rev a1)
  01:00.1 Audio device: nVidia Corporation GF104 High Definition Audio
Controller (rev a1)
So now the nvidia card (which I understand that has an audio part too) can
be assigned to the Windows guest.
I use the following config file:
root@debian:~# cat /etc/xen/win01.cfg
  kernel = "/usr/lib/xen/boot/hvmloader"
  builder='hvm'
  vcpus = 1
  name = "winXP"
  #vif = [ 'type=ioemu, bridge=xenbr0' ]
  #viridian = 1
  gfx_passthru=0
  #pci=['01:00.0']
  pci = [ '01:00.0', '01:00.1' ]
  monitor=1
  acpi = 1
  apic = 1
  pae = 1
  disk = [ 'file:/home/xen/domains/win01/disk.img,ioemu:hda,w',
'file:/home/javier/winxpSP3.iso,hdc:cdrom,r' ]
  device_model = "/usr/lib/xen/bin/qemu-dm"
  boot="c"
  sdl=0
  vnc=1
  vncconsole=1
 #vncpasswd=''
  serial='pty'
  usbdevice='tablet'
  on_poweroff='destroy'
  on_reboot='destroy'
  on_crash='restart'

I create the guest using another PC with ssh conection (putty) because when
I create the guest the host screen goes black due to the graphic card is not
owned by Dom0 anymore. 
Well, the error appear here and the guest is not started:
  root@debian:~# xm create win01.cfg
  Using config file "/etc/xen/win01.cfg".
  Error: Timed out waiting for device model action

Just to be sure, I think my Dom0 kernel is well configured:

  root@debian:~# cat /boot/config-2.6.32.45 | grep XEN
  CONFIG_XEN=y
  CONFIG_XEN_PVHVM=y
  CONFIG_XEN_MAX_DOMAIN_MEMORY=128
  CONFIG_XEN_SAVE_RESTORE=y
  CONFIG_XEN_DEBUG_FS=y
  CONFIG_SWIOTLB_XEN=y
  CONFIG_MICROCODE_XEN=y
  CONFIG_XEN_DOM0=y
  CONFIG_XEN_PRIVILEGED_GUEST=y
  CONFIG_XEN_DOM0_PCI=y
  CONFIG_XEN_PCI_PASSTHROUGH=y
  CONFIG_PCI_XEN=y
  CONFIG_XEN_PCIDEV_FRONTEND=y
  CONFIG_XEN_BLKDEV_FRONTEND=y
  CONFIG_NETXEN_NIC=m
  CONFIG_XEN_NETDEV_FRONTEND=m
  CONFIG_XEN_KBDDEV_FRONTEND=y
  CONFIG_HVC_XEN=y
  CONFIG_XEN_WDT=y
  CONFIG_XEN_FBDEV_FRONTEND=y
  CONFIG_XEN_BALLOON=y
  CONFIG_XEN_SCRUB_PAGES=y
  CONFIG_XEN_DEV_EVTCHN=y
  CONFIG_XEN_BACKEND=y
  CONFIG_XEN_NETDEV_BACKEND=y
  CONFIG_XEN_BLKDEV_BACKEND=y
  CONFIG_XEN_BLKDEV_TAP=m
  CONFIG_XEN_BLKBACK_PAGEMAP=y
  CONFIG_XEN_PCIDEV_BACKEND=y
  # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
  CONFIG_XEN_PCIDEV_BACKEND_PASS=y
  # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
  # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
  # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
  CONFIG_XENFS=y
  CONFIG_XEN_COMPAT_XENFS=y
  CONFIG_XEN_SYS_HYPERVISOR=y
  CONFIG_XEN_XENBUS_FRONTEND=y
  CONFIG_XEN_GNTDEV=y
  CONFIG_XEN_S3=y
  CONFIG_ACPI_PROCESSOR_XEN=m
  CONFIG_XEN_PLATFORM_PCI=y
  
I can create the guest removing the pci=[] line from the win01.cfg file:
  root@debian:~# xm create win01.cfg
  Using config file "/etc/xen/win01.cfg".
  Started domain winXP (id=7)
If I try to attach the graphic card in warm mode (The guest is already
started) then I see the same error:
  root@debian:~# xm pci-attach 7 01:00.0
  Error: Timed out waiting for device model action
  Usage: xm pci-attach [-o|--options=<opt>] <Domain> <domain:bus:slot.func>
[virtual slot]
  Insert a new pass-through pci device.

That's all, sorry for the long post, I just want to provide enough
information, thank you again for your time.

James

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5498806.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:57:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzRrP-0000Le-MQ; Mon, 20 Feb 2012 11:56:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzRrO-0000LD-Ac
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 11:56:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329738874!62038833!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24721 invoked from network); 20 Feb 2012 11:54:35 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 11:54:35 -0000
Received: by wibhi20 with SMTP id hi20so2545984wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 03:56:43 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr22372103wia.3.1329739003839 (num_hops
	= 1); Mon, 20 Feb 2012 03:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=Iyemd0pIJFxDJ6Ls6hlgTu/XPIFobxvUT+ls1az3jI8=;
	b=MUe9gYIHtbwtq6nwy3lNUYFzwMf7q7YQqaOJ5mcmQpXlDjqMxtONzGnG+jFQL1Pazw
	On7mSHn1vzxuo5x1W/H2dKKBNFf7QmvKuGbfFro7ZO33b4QZ1B4DVzdg9/MC5RrODJy2
	M/4mw0vSnfVbdXEDdk05y8GV+U666zgy9M7HQ=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr18716640wia.3.1329739002672; Mon,
	20 Feb 2012 03:56:42 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 03:56:42 -0800 (PST)
In-Reply-To: <4F3FD001.4070703@suse.de>
References: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
	<CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
	<4F3FD001.4070703@suse.de>
Date: Mon, 20 Feb 2012 12:56:42 +0100
X-Google-Sender-Auth: xLUK06W8i0ndHVNpGMJK-9cvddI
Message-ID: <CAPLaKK6m9zCw2LRUdm-O5mHxzjLgWCpxncWXTY_5u2twrof6gg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: =?UTF-8?Q?Andreas_F=C3=A4rber?= <afaerber@suse.de>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] build: add needed missing
	libraries libm and librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE4IEFuZHJlYXMgRsOkcmJlciA8YWZhZXJiZXJAc3VzZS5kZT46Cj4gQW0gMTguMDIu
MjAxMiAwOToyNCwgc2NocmllYiBCbHVlIFN3aXJsOgo+PiBPbiBXZWQsIEZlYiA4LCAyMDEyIGF0
IDE3OjA2LCBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3cm90ZToK
Pj4+IGxpYm0gaXMgdXNlZCBpbiBjdXRpbHMuYywgYnV0IHRoZSBsaWJyYXJ5IHdhcyBub3Qgc3Bl
Y2lmaWVkCj4+PiB3aGVuIGxpbmtpbmcgc29tZSBiaW5hcmllcywgdGhyb3dpbmcgdGhlIGZvbGxv
d2luZyBlcnJvcjoKPj4+Cj4+PiBjdXRpbHMubzogSW4gZnVuY3Rpb24gYHN0cnRvc3pfc3VmZml4
X3VuaXQnOgo+Pj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11LXhlbi1kaXIvY3V0
aWxzLmM6MzU0OiB1bmRlZmluZWQKPj4+IHJlZmVyZW5jZSB0byBgX19pc25hbicKPj4+IC9ob21l
L3JveWdlci94ZW4tY2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL2N1dGlscy5jOjM1NzogdW5kZWZp
bmVkCj4+PiByZWZlcmVuY2UgdG8gYG1vZGYnCj4+PiBjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBl
eGl0IHN0YXR1cwo+Pj4KPj4+IEFjY29yZGluZyB0byBtb2RmIG1hbiBwYWdlIFswXSwgLWxtIHNo
b3VsZCBiZSB1c2VkIHdoZW4gbGlua2luZy4KPj4+Cj4+PiBsaWJydCBpcyB1c2VkIGluIHFlbXUt
dGltZS5jLCBidXQgYWdhaW4gdGhlIGxpYnJhcnkgd2FzIG5vdCBzcGVjaWZpZWQKPj4+IGF0IGxp
bmsgdGltZSwgdGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPj4+Cj4+PiAvaG9tZS9yb3ln
ZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLmM6NTk3OiB1bmRlZmlu
ZWQKPj4+IHJlZmVyZW5jZSB0byBgdGltZXJfZ2V0dGltZScKPj4+IC9ob21lL3JveWdlci94ZW4t
Y2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXIuYzo2MTA6IHVuZGVmaW5lZAo+Pj4g
cmVmZXJlbmNlIHRvIGB0aW1lcl9zZXR0aW1lJwo+Pj4gLi4vcWVtdS10aW1lci5vOiBJbiBmdW5j
dGlvbiBgZHludGlja3Nfc3RhcnRfdGltZXInOgo+Pj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90
b29scy9xZW11LXhlbi1kaXIvcWVtdS10aW1lci5jOjU2NTogdW5kZWZpbmVkCj4+PiByZWZlcmVu
Y2UgdG8gYHRpbWVyX2NyZWF0ZScKPj4+IC4uL3FlbXUtdGltZXIubzogSW4gZnVuY3Rpb24gYGR5
bnRpY2tzX3N0b3BfdGltZXInOgo+Pj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11
LXhlbi1kaXIvcWVtdS10aW1lci5jOjU4MzogdW5kZWZpbmVkCj4+PiByZWZlcmVuY2UgdG8gYHRp
bWVyX2RlbGV0ZScKPj4+IGNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4+Pgo+
Pj4gQWNjb3JkaW5nIHRvIHRpbWVyX2dldHR0aW1lIG1hbiBwYWdlIFsxXSwgLWxydCBzaG91bGQg
YmUgdXNlZCB3aGVuCj4+PiBsaW5raW5nLgo+Pj4KPj4+IFswXSBodHRwOi8vbGludXguZGllLm5l
dC9tYW4vMy9tb2RmCj4+PiBbMV0gaHR0cDovL2xpbnV4LmRpZS5uZXQvbWFuLzIvdGltZXJfZ2V0
dGltZQo+Pgo+PiBUaGlzIGlzIExpbnV4IG1hbiBwYWdlLCBpcyB0aGlzIGNvcnJlY3QgZm9yIGFs
bCBPUyB3ZSBzdXBwb3J0Pwo+Cj4gTm8sIG5vdCBmb3IgSGFpa3Ugb3IgTWFjIE9TIFguCj4KPj4g
V2UgYWxyZWFkeSBoYXZlIGEgdGVzdCBmb3IgLWxydCBpbiBjb25maWd1cmUsIGJ1dCBpdCBsb29r
cyBsaWtlIGl0Cj4+IGRvZXMgbm90IGRldGVjdCB5b3VyIGNhc2UgY29ycmVjdGx5LiBZb3Ugc2hv
dWxkIGZpeCB0aGF0IGluc3RlYWQuCgpJJ3ZlIGZpeGVkIHRoZSBsaWJydCB0ZXN0IGluIGNvbmZp
Z3VyZSB0byB3b3JrIHByb3Blcmx5IG9uIG15IHN5c3RlbSwKdGhhdCdzIHVjbGliYyAwLjkuMzMu
Cgo+Pgo+Pj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwu
dXBjLmVkdT4KPj4+IC0tLQo+Pj4gwqBNYWtlZmlsZSDCoCDCoCDCoCDCoHwgwqAgwqA0ICsrLS0K
Pj4+IMKgTWFrZWZpbGUudGFyZ2V0IHwgwqAgwqAyICsrCj4+PiDCoDIgZmlsZXMgY2hhbmdlZCwg
NCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQo+Pj4KPj4+IGRpZmYgLS1naXQgYS9NYWtl
ZmlsZSBiL01ha2VmaWxlCj4+PiBpbmRleCAzMDFjNzVlLi5lMmMzY2Q0IDEwMDY0NAo+Pj4gLS0t
IGEvTWFrZWZpbGUKPj4+ICsrKyBiL01ha2VmaWxlCj4+PiBAQCAtMzQsNyArMzQsNyBAQCBjb25m
aWd1cmU6IDsKPj4+Cj4+PiDCoCQoY2FsbCBzZXQtdnBhdGgsICQoU1JDX1BBVEgpOiQoU1JDX1BB
VEgpL2h3KQo+Pj4KPj4+IC1MSUJTKz0tbHogJChMSUJTX1RPT0xTKQo+Pj4gK0xJQlMrPS1seiAt
bG0gLWxydCAkKExJQlNfVE9PTFMpCj4KPiBOQUNLLiBZb3UgbmVlZCB0byBtYWtlIHN1cmUgaXQg
ZWl0aGVyIGxhbmRzIGluICQoTElCU19UT09MUykgb3IgaXMgYWRkZWQKPiB2aWEgYSBuZXcgdmFy
aWFibGUgd2l0aCBob3N0LWRlcGVuZGVudCBjb250ZW50cy4KPgo+Pj4KPj4+IMKgaWZkZWYgQlVJ
TERfRE9DUwo+Pj4gwqBET0NTPXFlbXUtZG9jLmh0bWwgcWVtdS10ZWNoLmh0bWwgcWVtdS4xIHFl
bXUtaW1nLjEgcWVtdS1uYmQuOCBRTVAvcW1wLWNvbW1hbmRzLnR4dAo+Pj4gQEAgLTE3MCw3ICsx
NzAsNyBAQCB0ZXN0LWNvcm91dGluZTogdGVzdC1jb3JvdXRpbmUubyBxZW11LXRpbWVyLWNvbW1v
bi5vIGFzeW5jLm8gJChjb3JvdXRpbmUtb2JqLXkpCj4+PiDCoCQocWFwaS1vYmoteSk6ICQoR0VO
RVJBVEVEX0hFQURFUlMpCj4+PiDCoHFhcGktZGlyIDo9ICQoQlVJTERfRElSKS9xYXBpLWdlbmVy
YXRlZAo+Pj4gwqB0ZXN0LXZpc2l0b3IubyB0ZXN0LXFtcC1jb21tYW5kcy5vIHFlbXUtZ2EkKEVY
RVNVRik6IFFFTVVfQ0ZMQUdTICs9IC1JICQocWFwaS1kaXIpCj4+PiAtcWVtdS1nYSQoRVhFU1VG
KTogTElCUyA9ICQoTElCU19RR0EpCj4+PiArcWVtdS1nYSQoRVhFU1VGKTogTElCUyA9ICQoTElC
U19RR0EpIC1sbQo+Cj4gTkFDSy4gRWl0aGVyIG5lZWRzIHRvIGRvIExJQlMgKz0gb3IgbXVzdCBn
byBpbiAkKExJQlNfUUdBKSBvciBuZXcKPiBjb25kaXRpb25hbGl6ZWQgdmFyaWFibGUuCj4KPj4+
Cj4+PiDCoCQocWFwaS1kaXIpL3Rlc3QtcWFwaS10eXBlcy5jICQocWFwaS1kaXIpL3Rlc3QtcWFw
aS10eXBlcy5oIDpcCj4+PiDCoCQoU1JDX1BBVEgpL3FhcGktc2NoZW1hLXRlc3QuanNvbiAkKFNS
Q19QQVRIKS9zY3JpcHRzL3FhcGktdHlwZXMucHkKPj4+IGRpZmYgLS1naXQgYS9NYWtlZmlsZS50
YXJnZXQgYi9NYWtlZmlsZS50YXJnZXQKPj4+IGluZGV4IGExMTE1MjEuLjk1ZDZiYzAgMTAwNjQ0
Cj4+PiAtLS0gYS9NYWtlZmlsZS50YXJnZXQKPj4+ICsrKyBiL01ha2VmaWxlLnRhcmdldAo+Pj4g
QEAgLTMzLDYgKzMzLDggQEAgZW5kaWYKPj4+IMKgUFJPR1M9JChRRU1VX1BST0cpCj4+PiDCoFNU
UEZJTEVTPQo+Pj4KPj4+ICtMSUJTKz0tbHJ0Cj4+PiArCj4KPj4+IMKgaWZuZGVmIENPTkZJR19I
QUlLVQo+Pj4gwqBMSUJTKz0tbG0KPj4+IMKgZW5kaWYKPgo+IEhlcmUncyB0aGUgc3BlY2lhbCB0
cmVhdG1lbnQgdGhhdCBhdm9pZHMgYWRkaW5nIC1sbSBvbiBIYWlrdSBob3N0Cj4gYmVjYXVzZSBp
dCBkb2Vzbid0IGhhdmUgYSBsaWJtLnNvIChnaXQtYmxhbWUgd291bGQndmUgdG9sZCB5b3UgaXQn
cyBpbgo+IGxpYnJvb3Quc28gdGhlcmUpOyBvbiBEYXJ3aW4gdGhlcmUncyBhIGNvbXBhdGliaWxp
dHkgc3ltbGluayBidXQgaXQncyBpbgo+IGxpYlN5c3RlbS5keWxpYiBhY3R1YWxseSBhbmQgYW4g
aWZuZGVmIHdvdWxkIGJlIGFwcHJvcHJpYXRlIGFzIHdlbGwuCj4gUE9TSVggZG9lcyBub3QgbWFu
ZGF0ZSAtbG0gZm9yIG1hdGggZnVuY3Rpb25zLgo+Cj4gV291bGQgbW92aW5nIHRoaXMgc25pcHBl
dCB0byBNYWtlZmlsZS5vYmpzIGhlbHA/IFdoYXQgc3lzdGVtIGFyZSB5b3Ugb24KPiBhbnl3YXkg
YW5kIGFyZSB5b3UgYWN0dWFsbHkgdXNpbmcgdXBzdHJlYW0gcWVtdS5naXQ/IG9wZW5TVVNFIDEy
LjEgZG9lcwo+IG5vdCBjb21wbGFpbiwgYW5kIHdpdGhvdXQgYSB0ZXN0IGNhc2UgaXQncyBoYXJk
IHRvIGZpbmQgYSBzb2x1dGlvbiBoZXJlLgoKSSd2ZSBhZGRlZCBhIGNvbmZpZ3VyZSB0ZXN0IHRv
IGNoZWNrIGZvciBsaWJtLCBqdXN0IGxpa2UgdGhlIGxpYnJ0CnRlc3QsIHNvIHdlIG5vIGxvbmdl
ciBuZWVkIHRoZSBsaWJtIEhhaXVrdSBjb25kaXRpb25hbCBpbiB0aGUKTWFrZWZpbGUsIGRvZXMg
dGhhdCBzb3VuZCBvaz8KClJlZ2FyZHMsIFJvZ2VyLgoKPgo+IEFuZHJlYXMKPgo+Pj4gLS0KPj4+
IDEuNy45Cj4KPiAtLQo+IFNVU0UgTElOVVggUHJvZHVjdHMgR21iSCwgTWF4ZmVsZHN0ci4gNSwg
OTA0MDkgTsO8cm5iZXJnLCBHZXJtYW55Cj4gR0Y6IEplZmYgSGF3biwgSmVubmlmZXIgR3VpbGQs
IEZlbGl4IEltZW5kw7ZyZmZlcjsgSFJCIDE2NzQ2IEFHIE7DvHJuYmVyZwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 11:57:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 11:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzRrP-0000Le-MQ; Mon, 20 Feb 2012 11:56:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzRrO-0000LD-Ac
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 11:56:50 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329738874!62038833!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24721 invoked from network); 20 Feb 2012 11:54:35 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 11:54:35 -0000
Received: by wibhi20 with SMTP id hi20so2545984wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 03:56:43 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr22372103wia.3.1329739003839 (num_hops
	= 1); Mon, 20 Feb 2012 03:56:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=Iyemd0pIJFxDJ6Ls6hlgTu/XPIFobxvUT+ls1az3jI8=;
	b=MUe9gYIHtbwtq6nwy3lNUYFzwMf7q7YQqaOJ5mcmQpXlDjqMxtONzGnG+jFQL1Pazw
	On7mSHn1vzxuo5x1W/H2dKKBNFf7QmvKuGbfFro7ZO33b4QZ1B4DVzdg9/MC5RrODJy2
	M/4mw0vSnfVbdXEDdk05y8GV+U666zgy9M7HQ=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr18716640wia.3.1329739002672; Mon,
	20 Feb 2012 03:56:42 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 03:56:42 -0800 (PST)
In-Reply-To: <4F3FD001.4070703@suse.de>
References: <1328720797-29857-1-git-send-email-roger.pau@entel.upc.edu>
	<CAAu8pHttc5Ea9jQh3pcON2nEW7o_WoAors8ZcjA4t+627dEsew@mail.gmail.com>
	<4F3FD001.4070703@suse.de>
Date: Mon, 20 Feb 2012 12:56:42 +0100
X-Google-Sender-Auth: xLUK06W8i0ndHVNpGMJK-9cvddI
Message-ID: <CAPLaKK6m9zCw2LRUdm-O5mHxzjLgWCpxncWXTY_5u2twrof6gg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: =?UTF-8?Q?Andreas_F=C3=A4rber?= <afaerber@suse.de>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] build: add needed missing
	libraries libm and librt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE4IEFuZHJlYXMgRsOkcmJlciA8YWZhZXJiZXJAc3VzZS5kZT46Cj4gQW0gMTguMDIu
MjAxMiAwOToyNCwgc2NocmllYiBCbHVlIFN3aXJsOgo+PiBPbiBXZWQsIEZlYiA4LCAyMDEyIGF0
IDE3OjA2LCBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3cm90ZToK
Pj4+IGxpYm0gaXMgdXNlZCBpbiBjdXRpbHMuYywgYnV0IHRoZSBsaWJyYXJ5IHdhcyBub3Qgc3Bl
Y2lmaWVkCj4+PiB3aGVuIGxpbmtpbmcgc29tZSBiaW5hcmllcywgdGhyb3dpbmcgdGhlIGZvbGxv
d2luZyBlcnJvcjoKPj4+Cj4+PiBjdXRpbHMubzogSW4gZnVuY3Rpb24gYHN0cnRvc3pfc3VmZml4
X3VuaXQnOgo+Pj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11LXhlbi1kaXIvY3V0
aWxzLmM6MzU0OiB1bmRlZmluZWQKPj4+IHJlZmVyZW5jZSB0byBgX19pc25hbicKPj4+IC9ob21l
L3JveWdlci94ZW4tY2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL2N1dGlscy5jOjM1NzogdW5kZWZp
bmVkCj4+PiByZWZlcmVuY2UgdG8gYG1vZGYnCj4+PiBjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBl
eGl0IHN0YXR1cwo+Pj4KPj4+IEFjY29yZGluZyB0byBtb2RmIG1hbiBwYWdlIFswXSwgLWxtIHNo
b3VsZCBiZSB1c2VkIHdoZW4gbGlua2luZy4KPj4+Cj4+PiBsaWJydCBpcyB1c2VkIGluIHFlbXUt
dGltZS5jLCBidXQgYWdhaW4gdGhlIGxpYnJhcnkgd2FzIG5vdCBzcGVjaWZpZWQKPj4+IGF0IGxp
bmsgdGltZSwgdGhyb3dpbmcgdGhlIGZvbGxvd2luZyBlcnJvcjoKPj4+Cj4+PiAvaG9tZS9yb3ln
ZXIveGVuLWNsZWFuL3Rvb2xzL3FlbXUteGVuLWRpci9xZW11LXRpbWVyLmM6NTk3OiB1bmRlZmlu
ZWQKPj4+IHJlZmVyZW5jZSB0byBgdGltZXJfZ2V0dGltZScKPj4+IC9ob21lL3JveWdlci94ZW4t
Y2xlYW4vdG9vbHMvcWVtdS14ZW4tZGlyL3FlbXUtdGltZXIuYzo2MTA6IHVuZGVmaW5lZAo+Pj4g
cmVmZXJlbmNlIHRvIGB0aW1lcl9zZXR0aW1lJwo+Pj4gLi4vcWVtdS10aW1lci5vOiBJbiBmdW5j
dGlvbiBgZHludGlja3Nfc3RhcnRfdGltZXInOgo+Pj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90
b29scy9xZW11LXhlbi1kaXIvcWVtdS10aW1lci5jOjU2NTogdW5kZWZpbmVkCj4+PiByZWZlcmVu
Y2UgdG8gYHRpbWVyX2NyZWF0ZScKPj4+IC4uL3FlbXUtdGltZXIubzogSW4gZnVuY3Rpb24gYGR5
bnRpY2tzX3N0b3BfdGltZXInOgo+Pj4gL2hvbWUvcm95Z2VyL3hlbi1jbGVhbi90b29scy9xZW11
LXhlbi1kaXIvcWVtdS10aW1lci5jOjU4MzogdW5kZWZpbmVkCj4+PiByZWZlcmVuY2UgdG8gYHRp
bWVyX2RlbGV0ZScKPj4+IGNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzCj4+Pgo+
Pj4gQWNjb3JkaW5nIHRvIHRpbWVyX2dldHR0aW1lIG1hbiBwYWdlIFsxXSwgLWxydCBzaG91bGQg
YmUgdXNlZCB3aGVuCj4+PiBsaW5raW5nLgo+Pj4KPj4+IFswXSBodHRwOi8vbGludXguZGllLm5l
dC9tYW4vMy9tb2RmCj4+PiBbMV0gaHR0cDovL2xpbnV4LmRpZS5uZXQvbWFuLzIvdGltZXJfZ2V0
dGltZQo+Pgo+PiBUaGlzIGlzIExpbnV4IG1hbiBwYWdlLCBpcyB0aGlzIGNvcnJlY3QgZm9yIGFs
bCBPUyB3ZSBzdXBwb3J0Pwo+Cj4gTm8sIG5vdCBmb3IgSGFpa3Ugb3IgTWFjIE9TIFguCj4KPj4g
V2UgYWxyZWFkeSBoYXZlIGEgdGVzdCBmb3IgLWxydCBpbiBjb25maWd1cmUsIGJ1dCBpdCBsb29r
cyBsaWtlIGl0Cj4+IGRvZXMgbm90IGRldGVjdCB5b3VyIGNhc2UgY29ycmVjdGx5LiBZb3Ugc2hv
dWxkIGZpeCB0aGF0IGluc3RlYWQuCgpJJ3ZlIGZpeGVkIHRoZSBsaWJydCB0ZXN0IGluIGNvbmZp
Z3VyZSB0byB3b3JrIHByb3Blcmx5IG9uIG15IHN5c3RlbSwKdGhhdCdzIHVjbGliYyAwLjkuMzMu
Cgo+Pgo+Pj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwu
dXBjLmVkdT4KPj4+IC0tLQo+Pj4gwqBNYWtlZmlsZSDCoCDCoCDCoCDCoHwgwqAgwqA0ICsrLS0K
Pj4+IMKgTWFrZWZpbGUudGFyZ2V0IHwgwqAgwqAyICsrCj4+PiDCoDIgZmlsZXMgY2hhbmdlZCwg
NCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQo+Pj4KPj4+IGRpZmYgLS1naXQgYS9NYWtl
ZmlsZSBiL01ha2VmaWxlCj4+PiBpbmRleCAzMDFjNzVlLi5lMmMzY2Q0IDEwMDY0NAo+Pj4gLS0t
IGEvTWFrZWZpbGUKPj4+ICsrKyBiL01ha2VmaWxlCj4+PiBAQCAtMzQsNyArMzQsNyBAQCBjb25m
aWd1cmU6IDsKPj4+Cj4+PiDCoCQoY2FsbCBzZXQtdnBhdGgsICQoU1JDX1BBVEgpOiQoU1JDX1BB
VEgpL2h3KQo+Pj4KPj4+IC1MSUJTKz0tbHogJChMSUJTX1RPT0xTKQo+Pj4gK0xJQlMrPS1seiAt
bG0gLWxydCAkKExJQlNfVE9PTFMpCj4KPiBOQUNLLiBZb3UgbmVlZCB0byBtYWtlIHN1cmUgaXQg
ZWl0aGVyIGxhbmRzIGluICQoTElCU19UT09MUykgb3IgaXMgYWRkZWQKPiB2aWEgYSBuZXcgdmFy
aWFibGUgd2l0aCBob3N0LWRlcGVuZGVudCBjb250ZW50cy4KPgo+Pj4KPj4+IMKgaWZkZWYgQlVJ
TERfRE9DUwo+Pj4gwqBET0NTPXFlbXUtZG9jLmh0bWwgcWVtdS10ZWNoLmh0bWwgcWVtdS4xIHFl
bXUtaW1nLjEgcWVtdS1uYmQuOCBRTVAvcW1wLWNvbW1hbmRzLnR4dAo+Pj4gQEAgLTE3MCw3ICsx
NzAsNyBAQCB0ZXN0LWNvcm91dGluZTogdGVzdC1jb3JvdXRpbmUubyBxZW11LXRpbWVyLWNvbW1v
bi5vIGFzeW5jLm8gJChjb3JvdXRpbmUtb2JqLXkpCj4+PiDCoCQocWFwaS1vYmoteSk6ICQoR0VO
RVJBVEVEX0hFQURFUlMpCj4+PiDCoHFhcGktZGlyIDo9ICQoQlVJTERfRElSKS9xYXBpLWdlbmVy
YXRlZAo+Pj4gwqB0ZXN0LXZpc2l0b3IubyB0ZXN0LXFtcC1jb21tYW5kcy5vIHFlbXUtZ2EkKEVY
RVNVRik6IFFFTVVfQ0ZMQUdTICs9IC1JICQocWFwaS1kaXIpCj4+PiAtcWVtdS1nYSQoRVhFU1VG
KTogTElCUyA9ICQoTElCU19RR0EpCj4+PiArcWVtdS1nYSQoRVhFU1VGKTogTElCUyA9ICQoTElC
U19RR0EpIC1sbQo+Cj4gTkFDSy4gRWl0aGVyIG5lZWRzIHRvIGRvIExJQlMgKz0gb3IgbXVzdCBn
byBpbiAkKExJQlNfUUdBKSBvciBuZXcKPiBjb25kaXRpb25hbGl6ZWQgdmFyaWFibGUuCj4KPj4+
Cj4+PiDCoCQocWFwaS1kaXIpL3Rlc3QtcWFwaS10eXBlcy5jICQocWFwaS1kaXIpL3Rlc3QtcWFw
aS10eXBlcy5oIDpcCj4+PiDCoCQoU1JDX1BBVEgpL3FhcGktc2NoZW1hLXRlc3QuanNvbiAkKFNS
Q19QQVRIKS9zY3JpcHRzL3FhcGktdHlwZXMucHkKPj4+IGRpZmYgLS1naXQgYS9NYWtlZmlsZS50
YXJnZXQgYi9NYWtlZmlsZS50YXJnZXQKPj4+IGluZGV4IGExMTE1MjEuLjk1ZDZiYzAgMTAwNjQ0
Cj4+PiAtLS0gYS9NYWtlZmlsZS50YXJnZXQKPj4+ICsrKyBiL01ha2VmaWxlLnRhcmdldAo+Pj4g
QEAgLTMzLDYgKzMzLDggQEAgZW5kaWYKPj4+IMKgUFJPR1M9JChRRU1VX1BST0cpCj4+PiDCoFNU
UEZJTEVTPQo+Pj4KPj4+ICtMSUJTKz0tbHJ0Cj4+PiArCj4KPj4+IMKgaWZuZGVmIENPTkZJR19I
QUlLVQo+Pj4gwqBMSUJTKz0tbG0KPj4+IMKgZW5kaWYKPgo+IEhlcmUncyB0aGUgc3BlY2lhbCB0
cmVhdG1lbnQgdGhhdCBhdm9pZHMgYWRkaW5nIC1sbSBvbiBIYWlrdSBob3N0Cj4gYmVjYXVzZSBp
dCBkb2Vzbid0IGhhdmUgYSBsaWJtLnNvIChnaXQtYmxhbWUgd291bGQndmUgdG9sZCB5b3UgaXQn
cyBpbgo+IGxpYnJvb3Quc28gdGhlcmUpOyBvbiBEYXJ3aW4gdGhlcmUncyBhIGNvbXBhdGliaWxp
dHkgc3ltbGluayBidXQgaXQncyBpbgo+IGxpYlN5c3RlbS5keWxpYiBhY3R1YWxseSBhbmQgYW4g
aWZuZGVmIHdvdWxkIGJlIGFwcHJvcHJpYXRlIGFzIHdlbGwuCj4gUE9TSVggZG9lcyBub3QgbWFu
ZGF0ZSAtbG0gZm9yIG1hdGggZnVuY3Rpb25zLgo+Cj4gV291bGQgbW92aW5nIHRoaXMgc25pcHBl
dCB0byBNYWtlZmlsZS5vYmpzIGhlbHA/IFdoYXQgc3lzdGVtIGFyZSB5b3Ugb24KPiBhbnl3YXkg
YW5kIGFyZSB5b3UgYWN0dWFsbHkgdXNpbmcgdXBzdHJlYW0gcWVtdS5naXQ/IG9wZW5TVVNFIDEy
LjEgZG9lcwo+IG5vdCBjb21wbGFpbiwgYW5kIHdpdGhvdXQgYSB0ZXN0IGNhc2UgaXQncyBoYXJk
IHRvIGZpbmQgYSBzb2x1dGlvbiBoZXJlLgoKSSd2ZSBhZGRlZCBhIGNvbmZpZ3VyZSB0ZXN0IHRv
IGNoZWNrIGZvciBsaWJtLCBqdXN0IGxpa2UgdGhlIGxpYnJ0CnRlc3QsIHNvIHdlIG5vIGxvbmdl
ciBuZWVkIHRoZSBsaWJtIEhhaXVrdSBjb25kaXRpb25hbCBpbiB0aGUKTWFrZWZpbGUsIGRvZXMg
dGhhdCBzb3VuZCBvaz8KClJlZ2FyZHMsIFJvZ2VyLgoKPgo+IEFuZHJlYXMKPgo+Pj4gLS0KPj4+
IDEuNy45Cj4KPiAtLQo+IFNVU0UgTElOVVggUHJvZHVjdHMgR21iSCwgTWF4ZmVsZHN0ci4gNSwg
OTA0MDkgTsO8cm5iZXJnLCBHZXJtYW55Cj4gR0Y6IEplZmYgSGF3biwgSmVubmlmZXIgR3VpbGQs
IEZlbGl4IEltZW5kw7ZyZmZlcjsgSFJCIDE2NzQ2IEFHIE7DvHJuYmVyZwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:02:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzRwH-0000g1-6u; Mon, 20 Feb 2012 12:01:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzRwF-0000fl-9y
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:01:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329739279!57424683!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14999 invoked from network); 20 Feb 2012 12:01:19 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:01:19 -0000
Received: by werb14 with SMTP id b14so12141004wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 04:01:49 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr22422203wia.3.1329739309615 (num_hops
	= 1); Mon, 20 Feb 2012 04:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=tQv05zdwaVMccd0SIeD+6nCjlLYEQG6bpXsdNRfJMgo=;
	b=p97AxtptxeaGVb4jyEwXV80X3Pt8yVsh4y5NWXtvIHhyfS4F7eyvzamRcUj9dSRy5i
	bExN6FnQMMaQWvzkyYOGz1AMGqHSWslDCG47e+MmB1TzovEWuGXScub04o57U5Y2fxwG
	c2LcQZ8rCLfG8Zoe5GlLHl9zwVPOW2ztlkRWk=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr18754512wia.3.1329739308660; Mon,
	20 Feb 2012 04:01:48 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 04:01:48 -0800 (PST)
In-Reply-To: <1329735330.3990.31.camel@zakaz.uk.xensource.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
	<1329735330.3990.31.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:01:48 +0100
X-Google-Sender-Auth: 3-7AOJDajbEngrBMKMZ3RMJWMHE
Message-ID: <CAPLaKK4BSuP8BD_G=MfT2y7Np6iBm8araBgkENFBB79svyKG1w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIwIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMi0wMi0xNyBhdCAxOToxNSArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+IFdlIGlu
dHJvZHVjZSBhIG5ldyAiY2FyZWZkIiBjb25jZXB0LCB3aGljaCByZWxhdGVzIHRvIGZkcyB0aGF0
IHdlIGNhcmUKPj4gYWJvdXQgbm90IGJlaW5nIGluaGVyaXRlZCBieSBsb25nLWxpdmVkIGNoaWxk
cmVuLgo+Pgo+PiBBcyB5ZXQgd2UgZG8gbm90IHVzZSB0aGlzIGFueXdoZXJlaW4gbGlieGwuIMKg
VW50aWwgYWxsIGxvY2F0aW9ucyBpbgo+Cj4gImFueXdoZXJlaW4iCj4KPj4gbGlieGwgd2hpY2gg
bWFrZSBzdWNoIGZkcyBhcmUgY29udmVydGVkLCBsaWJ4bF9fcG9zdGZvcmsgbWF5IG5vdCB3b3Jr
Cj4+IGVudGlyZWx5IHByb3Blcmx5LiDCoElmIHRoZXNlIGxvY2F0aW9ucyBkbyBub3QgdXNlIE9f
Q0xPRVhFQyAob3IgdXNlCj4+IGNhbGxzIGZvciB3aGljaCB0aGVyZSBpcyBubyBPX0NMT0VYRUMp
IHRoZW4gbXVsdGl0aHJlYWRlZCBwcm9ncmFtcyBtYXkKPj4gbm90IHdvcmsgcHJvcGVybHkuCj4+
Cj4+IFRoaXMgaW50cm9kdWNlcyBhIG5ldyBBUEkgY2FsbCBsaWJ4bF9wb3N0Zm9ya19jaGlsZF9u
b2V4ZWMgd2hpY2ggbXVzdAo+PiBiZSBjYWxsZWQgYnkgYXBwbGljYXRpb25zIHdoaWNoIG1ha2Ug
bG9uZy1ydW5uaW5nIG5vbi1leGVjaW5nCj4+IGNoaWxkcmVuLiDCoEFkZCB0aGUgYXBwcm9wcmlh
dGUgY2FsbCB0byB4bCdzIHBvc3Rmb3JrIGZ1bmN0aW9uLgo+Pgo+PiBPbiBMaW51eCBwdGhyZWFk
X2F0Zm9yayBkZW1hbmRzIGNvbXBpbGF0aW9uIHdpdGggLXB0aHJlYWQsIHNvIGFkZAo+PiBQVEhS
RUFEX0NGTEFHUywgX0xERkxBR1MsIF9MSUJTIHRvIHRoZSBjb3JyZXNwb25kaW5nIHZhcmlhYmxl
cyBpbiB0aGUKPj4gbGlieGwgTWFrZWZpbGUuIMKgSXQgaXMgbm90IGNsZWFyIHdoeSB3ZSBnb3Qg
YXdheSB3aXRob3V0IHRoZXNlIGJlZm9yZS4KPgo+IFNpbmNlIEkgYXNzdW1lIHRoZSBNYWtlZmls
ZSBiaXQgY291bGQgc2FmZWx5IGJlIHNwbGl0IG91dCBhbmQgYXBwbGllZCwKPiB0aGF0IGJpdCBp
czoKPiBBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4KPgo+
PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZXZlbnQuaCBiL3Rvb2xzL2xpYnhsL2xp
YnhsX2V2ZW50LmgKPj4gaW5kZXggZjg4OTExNS4uNzRhMDQwMiAxMDA2NDQKPj4gLS0tIGEvdG9v
bHMvbGlieGwvbGlieGxfZXZlbnQuaAo+PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9ldmVudC5o
Cj4+IEBAIC0zNjksNiArMzY5LDE2IEBAIHZvaWQgbGlieGxfb3NldmVudF9vY2N1cnJlZF9mZChs
aWJ4bF9jdHggKmN0eCwgdm9pZCAqZm9yX2xpYnhsLAo+PiDCoCAqLwo+PiDCoHZvaWQgbGlieGxf
b3NldmVudF9vY2N1cnJlZF90aW1lb3V0KGxpYnhsX2N0eCAqY3R4LCB2b2lkICpmb3JfbGlieGwp
Owo+Pgo+PiArCj4+ICsvKgo+PiArICogQW4gYXBwbGljYXRpb24gd2hpY2ggaW5pdGlhbGlzZXMg
YSBsaWJ4bF9jdHggaW4gYSBwYXJlbnQgcHJvY2Vzcwo+PiArICogYW5kIHRoZW4gZm9ya3MgYSBj
aGlsZCB3aGljaCBkb2VzIG5vdCBxdWlja2x5IGV4ZWMsIG11c3QKPj4gKyAqIGluc3RlYWQgbGli
eGxfX3Bvc3Rmb3JrX2NoaWxkX25vZXhlYyBpbiB0aGUgY2hpbGQuIMKgT25lIGNhbGwKPj4gKyAq
IGZvciBhbGwgbGlieGwgY29udGV4dHMgaXMgc3VmZmljaWVudC4KPj4gKyAqLwo+PiArdm9pZCBs
aWJ4bF9wb3N0Zm9ya19jaGlsZF9ub2V4ZWMobGlieGxfY3R4ICpjdHgpOwo+Cj4gSXMgdGhlIGN0
eCBwYXNzZWQgaGVyZSByZXF1aXJlZCB0byBiZSBvbmUgb2YgdGhlIGV4aXN0aW5nIGN0eCdzIG9y
IGEKPiBuZXdseSBhbGxvY2F0ZWQgb25lIGluIHRoaXMgY29udGV4dD8KPgo+PiArCj4+ICsKPj4g
wqAjZW5kaWYKPj4KPj4gwqAvKgo+PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZm9y
ay5jIGIvdG9vbHMvbGlieGwvbGlieGxfZm9yay5jCj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0Cj4+
IGluZGV4IDAwMDAwMDAuLjY2ZDBlZTAKPj4gLS0tIC9kZXYvbnVsbAo+PiArKysgYi90b29scy9s
aWJ4bC9saWJ4bF9mb3JrLmMKPj4gQEAgLTAsMCArMSwxNjcgQEAKPj4gKy8qCj4+ICsgKiBDb3B5
cmlnaHQgKEMpIDIwMTIgwqAgwqAgwqBDaXRyaXggTHRkLgo+PiArICoKPj4gKyAqIFRoaXMgcHJv
Z3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5Cj4+ICsgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQ
dWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQKPj4gKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZv
dW5kYXRpb247IHZlcnNpb24gMi4xIG9ubHkuIHdpdGggdGhlIHNwZWNpYWwKPj4gKyAqIGV4Y2Vw
dGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBmaWxlIExJQ0VOU0UuCj4+ICsgKgo+PiArICog
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1
c2VmdWwsCj4+ICsgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZgo+PiArICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLiDCoFNlZSB0aGUKPj4gKyAqIEdOVSBMZXNzZXIgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgo+PiArICovCj4+ICsvKgo+PiArICog
SW50ZXJuYWwgY2hpbGQgcHJvY2VzcyBtYWNoaW5lcnkgZm9yIHVzZSBieSBvdGhlciBwYXJ0cyBv
ZiBsaWJ4bAo+PiArICovCj4+ICsKPj4gKyNpbmNsdWRlICJsaWJ4bF9vc2RlcHMuaCIgLyogbXVz
dCBjb21lIGJlZm9yZSBhbnkgb3RoZXIgaGVhZGVycyAqLwo+PiArCj4+ICsjaW5jbHVkZSAibGli
eGxfaW50ZXJuYWwuaCIKPj4gKwo+PiArLyoKPj4gKyAqIGNhcmVmZCBhcnJhbmdlbWVudHMKPj4g
KyAqCj4+ICsgKiBjYXJlZmRfYmVnaW4gYW5kIF91bmxvY2sgdGFrZSBvdXQgdGhlIG5vX2Zvcmtp
bmcgbG9jaywgd2hpY2ggd2UKPj4gKyAqIGFsc28gdGFrZSBhbmQgcmVsZWFzZSBpbiBvdXIgcHRo
cmVhZF9hdGZvcmsgaGFuZGxlcnMuIMKgU28gd2hlbiB0aGlzCj4+ICsgKiBsb2NrIGlzIGhlbGQg
dGhlIHdob2xlIHByb2Nlc3MgY2Fubm90IGZvcmsuIMKgV2UgdGhlcmVmb3JlIHByb3RlY3QKPj4g
KyAqIG91ciBmZHMgZnJvbSBsZWFraW5nIGludG8gY2hpbGRyZW4gbWFkZSBieSBvdGhlciB0aHJl
YWRzLgo+PiArICoKPj4gKyAqIFdlIG1haW50YWluIGEgbGlzdCBvZiBhbGwgdGhlIGNhcmVmZHMs
IHNvIHRoYXQgaWYgdGhlIGFwcGxpY2F0aW9uCj4+ICsgKiB3YW50cyB0byBmb3JrIGEgbG9uZy1y
dW5uaW5nIGJ1dCBub24tZXhlY2luZyBjaGlsZCwgd2UgY2FuIGNsb3NlCj4+ICsgKiB0aGVtIGFs
bC4KPj4gKyAqCj4+ICsgKiBTbyB0aGUgcmVjb3JkIGZ1bmN0aW9uIHNldHMgQ0xPRVhFQyBmb3Ig
dGhlIGJlbmVmaXQgb2YgZXhlY2luZwo+PiArICogY2hpbGRyZW4sIGFuZCBtYWtlcyBhIG5vdGUg
b2YgdGhlIGZkIGZvciB0aGUgYmVuZWZpdCBvZiBub24tZXhlY2luZwo+PiArICogb25lcy4KPj4g
KyAqLwo+PiArCj4+ICtzdHJ1Y3QgbGlieGxfX2NhcmVmZCB7Cj4+ICsgwqAgwqBMSUJYTF9MSVNU
X0VOVFJZKGxpYnhsX19jYXJlZmQpIGVudHJ5Owo+PiArIMKgIMKgaW50IGZkOwo+PiArfTsKPj4g
Kwo+PiArc3RhdGljIHB0aHJlYWRfbXV0ZXhfdCBub19mb3JraW5nID0gUFRIUkVBRF9NVVRFWF9J
TklUSUFMSVpFUjsKPgo+IFdlIHByZXZpb3VzbHkgaGFkIHRyb3VibGUgd2l0aCBQVEhSRUFEX1JF
Q1VSU0lWRV9NVVRFWF9JTklUSUFMSVpFUl9OUAo+IG5vdCBiZWluZyBkZWZpbmVkIG9uIE5ldEJT
RC4KPgo+IGh0dHA6Ly93d3cuZGFlbW9uLXN5c3RlbXMub3JnL21hbi9wdGhyZWFkX211dGV4X2lu
aXQuMy5odG1sIHN1Z2dlc3RzCj4gUFRIUkVBRF9NVVRFWF9JTklUSUFMSVpFUiBpcyBidXQgcGVy
aGFwcyB3ZSBzaG91bGQgY29uZmlybT8KCgpKdXN0IHRlc3RlZCBvbiBhIE5ldEJTRCBzeXN0ZW0s
IGFuZCBQVEhSRUFEX01VVEVYX0lOSVRJQUxJWkVSIG1hY3JvIGlzIGFsbG93ZWQuCgo+PiArc3Rh
dGljIGludCBhdGZvcmtfcmVnaXN0ZXJlZDsKPgo+IERvZXMgcHRocmVhZF9hdGZvcmsgcGVyc2lz
dCBpbnRvIHRoZSBjaGlsZHJlbj8KPgo+IElmIHRoZSBwYXJlbnQgaGFzIHNldCB0aGlzIHRoZW4g
aXQgd2lsbCBiZSBzZXQgZm9yIHRoZSBjaGlsZCB0b28sIHdoaWNoCj4gaWYgdGhlIGFuc3dlciB0
byBteSBxdWVzdGlvbiBpcyAiTm8iIGlzIGEgcHJvYmxlbS4KPgo+IEkgc3VzcGVjdCB0aGUgYW5z
d2VyIGlzIHllcyB0aG91Z2guCj4KPj4gK3N0YXRpYyBMSUJYTF9MSVNUX0hFQUQoLCBsaWJ4bF9f
Y2FyZWZkKSBjYXJlZmRzID0KPj4gKyDCoCDCoExJQlhMX0xJU1RfSEVBRF9JTklUSUFMSVpFUihj
YXJlZmRzKTsKPj4gKwo+PiArc3RhdGljIHZvaWQgYXRmb3JrX2xvY2sodm9pZCkKPj4gK3sKPj4g
KyDCoCDCoGludCByID0gcHRocmVhZF9tdXRleF9sb2NrKCZub19mb3JraW5nKTsKPj4gKyDCoCDC
oGFzc2VydCghcik7Cj4+ICt9Cj4+ICsKPj4gK3N0YXRpYyB2b2lkIGF0Zm9ya191bmxvY2sodm9p
ZCkKPj4gK3sKPj4gKyDCoCDCoGludCByID0gcHRocmVhZF9tdXRleF91bmxvY2soJm5vX2Zvcmtp
bmcpOwo+PiArIMKgIMKgYXNzZXJ0KCFyKTsKPj4gK30KPj4gKwo+PiAraW50IGxpYnhsX19hdGZv
cmtfaW5pdChsaWJ4bF9jdHggKmN0eCkKPj4gK3sKPj4gKyDCoCDCoGludCByLCByYzsKPj4gKwo+
PiArIMKgIMKgYXRmb3JrX2xvY2soKTsKPj4gKyDCoCDCoGlmIChhdGZvcmtfcmVnaXN0ZXJlZCkK
Pgo+IE1pc3NpbmcgYW4gdW5sb2NrPwo+Cj4+ICsgwqAgwqAgwqAgwqByZXR1cm4gMDsKPj4gKwo+
PiArIMKgIMKgciA9IHB0aHJlYWRfYXRmb3JrKGF0Zm9ya19sb2NrLCBhdGZvcmtfdW5sb2NrLCBh
dGZvcmtfdW5sb2NrKTsKPj4gKyDCoCDCoGlmIChyKSB7Cj4+ICsgwqAgwqAgwqAgwqBMSUJYTF9f
TE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgInB0aHJlYWRfYXRmb3JrIGZhaWxlZCIp
Owo+PiArIMKgIMKgIMKgIMKgcmMgPSBFUlJPUl9OT01FTTsKPj4gKyDCoCDCoCDCoCDCoGdvdG8g
b3V0Owo+PiArIMKgIMKgfQo+PiArCj4+ICsgwqAgwqBhdGZvcmtfcmVnaXN0ZXJlZCA9IDE7Cj4+
ICsgwqAgwqByYyA9IDA7Cj4+ICsgb3V0Ogo+PiArIMKgIMKgYXRmb3JrX3VubG9jaygpOwo+PiAr
IMKgIMKgcmV0dXJuIHJjOwo+PiArfQo+PiArCj4+ICt2b2lkIGxpYnhsX19jYXJlZmRfYmVnaW4o
dm9pZCkgeyBhdGZvcmtfbG9jaygpOyB9Cj4+ICt2b2lkIGxpYnhsX19jYXJlZmRfdW5sb2NrKHZv
aWQpIHsgYXRmb3JrX3VubG9jaygpOyB9Cj4KPiBUaGlzIG5hbWluZyBzZWVtcyBhc3ltbWV0cmlj
Lgo+Cj4gSWFuLgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNl
LmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:02:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzRwH-0000g1-6u; Mon, 20 Feb 2012 12:01:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzRwF-0000fl-9y
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:01:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329739279!57424683!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14999 invoked from network); 20 Feb 2012 12:01:19 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:01:19 -0000
Received: by werb14 with SMTP id b14so12141004wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 04:01:49 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr22422203wia.3.1329739309615 (num_hops
	= 1); Mon, 20 Feb 2012 04:01:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=tQv05zdwaVMccd0SIeD+6nCjlLYEQG6bpXsdNRfJMgo=;
	b=p97AxtptxeaGVb4jyEwXV80X3Pt8yVsh4y5NWXtvIHhyfS4F7eyvzamRcUj9dSRy5i
	bExN6FnQMMaQWvzkyYOGz1AMGqHSWslDCG47e+MmB1TzovEWuGXScub04o57U5Y2fxwG
	c2LcQZ8rCLfG8Zoe5GlLHl9zwVPOW2ztlkRWk=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr18754512wia.3.1329739308660; Mon,
	20 Feb 2012 04:01:48 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 04:01:48 -0800 (PST)
In-Reply-To: <1329735330.3990.31.camel@zakaz.uk.xensource.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
	<1329735330.3990.31.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:01:48 +0100
X-Google-Sender-Auth: 3-7AOJDajbEngrBMKMZ3RMJWMHE
Message-ID: <CAPLaKK4BSuP8BD_G=MfT2y7Np6iBm8araBgkENFBB79svyKG1w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIwIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMi0wMi0xNyBhdCAxOToxNSArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+IFdlIGlu
dHJvZHVjZSBhIG5ldyAiY2FyZWZkIiBjb25jZXB0LCB3aGljaCByZWxhdGVzIHRvIGZkcyB0aGF0
IHdlIGNhcmUKPj4gYWJvdXQgbm90IGJlaW5nIGluaGVyaXRlZCBieSBsb25nLWxpdmVkIGNoaWxk
cmVuLgo+Pgo+PiBBcyB5ZXQgd2UgZG8gbm90IHVzZSB0aGlzIGFueXdoZXJlaW4gbGlieGwuIMKg
VW50aWwgYWxsIGxvY2F0aW9ucyBpbgo+Cj4gImFueXdoZXJlaW4iCj4KPj4gbGlieGwgd2hpY2gg
bWFrZSBzdWNoIGZkcyBhcmUgY29udmVydGVkLCBsaWJ4bF9fcG9zdGZvcmsgbWF5IG5vdCB3b3Jr
Cj4+IGVudGlyZWx5IHByb3Blcmx5LiDCoElmIHRoZXNlIGxvY2F0aW9ucyBkbyBub3QgdXNlIE9f
Q0xPRVhFQyAob3IgdXNlCj4+IGNhbGxzIGZvciB3aGljaCB0aGVyZSBpcyBubyBPX0NMT0VYRUMp
IHRoZW4gbXVsdGl0aHJlYWRlZCBwcm9ncmFtcyBtYXkKPj4gbm90IHdvcmsgcHJvcGVybHkuCj4+
Cj4+IFRoaXMgaW50cm9kdWNlcyBhIG5ldyBBUEkgY2FsbCBsaWJ4bF9wb3N0Zm9ya19jaGlsZF9u
b2V4ZWMgd2hpY2ggbXVzdAo+PiBiZSBjYWxsZWQgYnkgYXBwbGljYXRpb25zIHdoaWNoIG1ha2Ug
bG9uZy1ydW5uaW5nIG5vbi1leGVjaW5nCj4+IGNoaWxkcmVuLiDCoEFkZCB0aGUgYXBwcm9wcmlh
dGUgY2FsbCB0byB4bCdzIHBvc3Rmb3JrIGZ1bmN0aW9uLgo+Pgo+PiBPbiBMaW51eCBwdGhyZWFk
X2F0Zm9yayBkZW1hbmRzIGNvbXBpbGF0aW9uIHdpdGggLXB0aHJlYWQsIHNvIGFkZAo+PiBQVEhS
RUFEX0NGTEFHUywgX0xERkxBR1MsIF9MSUJTIHRvIHRoZSBjb3JyZXNwb25kaW5nIHZhcmlhYmxl
cyBpbiB0aGUKPj4gbGlieGwgTWFrZWZpbGUuIMKgSXQgaXMgbm90IGNsZWFyIHdoeSB3ZSBnb3Qg
YXdheSB3aXRob3V0IHRoZXNlIGJlZm9yZS4KPgo+IFNpbmNlIEkgYXNzdW1lIHRoZSBNYWtlZmls
ZSBiaXQgY291bGQgc2FmZWx5IGJlIHNwbGl0IG91dCBhbmQgYXBwbGllZCwKPiB0aGF0IGJpdCBp
czoKPiBBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT4KPgo+
PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZXZlbnQuaCBiL3Rvb2xzL2xpYnhsL2xp
YnhsX2V2ZW50LmgKPj4gaW5kZXggZjg4OTExNS4uNzRhMDQwMiAxMDA2NDQKPj4gLS0tIGEvdG9v
bHMvbGlieGwvbGlieGxfZXZlbnQuaAo+PiArKysgYi90b29scy9saWJ4bC9saWJ4bF9ldmVudC5o
Cj4+IEBAIC0zNjksNiArMzY5LDE2IEBAIHZvaWQgbGlieGxfb3NldmVudF9vY2N1cnJlZF9mZChs
aWJ4bF9jdHggKmN0eCwgdm9pZCAqZm9yX2xpYnhsLAo+PiDCoCAqLwo+PiDCoHZvaWQgbGlieGxf
b3NldmVudF9vY2N1cnJlZF90aW1lb3V0KGxpYnhsX2N0eCAqY3R4LCB2b2lkICpmb3JfbGlieGwp
Owo+Pgo+PiArCj4+ICsvKgo+PiArICogQW4gYXBwbGljYXRpb24gd2hpY2ggaW5pdGlhbGlzZXMg
YSBsaWJ4bF9jdHggaW4gYSBwYXJlbnQgcHJvY2Vzcwo+PiArICogYW5kIHRoZW4gZm9ya3MgYSBj
aGlsZCB3aGljaCBkb2VzIG5vdCBxdWlja2x5IGV4ZWMsIG11c3QKPj4gKyAqIGluc3RlYWQgbGli
eGxfX3Bvc3Rmb3JrX2NoaWxkX25vZXhlYyBpbiB0aGUgY2hpbGQuIMKgT25lIGNhbGwKPj4gKyAq
IGZvciBhbGwgbGlieGwgY29udGV4dHMgaXMgc3VmZmljaWVudC4KPj4gKyAqLwo+PiArdm9pZCBs
aWJ4bF9wb3N0Zm9ya19jaGlsZF9ub2V4ZWMobGlieGxfY3R4ICpjdHgpOwo+Cj4gSXMgdGhlIGN0
eCBwYXNzZWQgaGVyZSByZXF1aXJlZCB0byBiZSBvbmUgb2YgdGhlIGV4aXN0aW5nIGN0eCdzIG9y
IGEKPiBuZXdseSBhbGxvY2F0ZWQgb25lIGluIHRoaXMgY29udGV4dD8KPgo+PiArCj4+ICsKPj4g
wqAjZW5kaWYKPj4KPj4gwqAvKgo+PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZm9y
ay5jIGIvdG9vbHMvbGlieGwvbGlieGxfZm9yay5jCj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0Cj4+
IGluZGV4IDAwMDAwMDAuLjY2ZDBlZTAKPj4gLS0tIC9kZXYvbnVsbAo+PiArKysgYi90b29scy9s
aWJ4bC9saWJ4bF9mb3JrLmMKPj4gQEAgLTAsMCArMSwxNjcgQEAKPj4gKy8qCj4+ICsgKiBDb3B5
cmlnaHQgKEMpIDIwMTIgwqAgwqAgwqBDaXRyaXggTHRkLgo+PiArICoKPj4gKyAqIFRoaXMgcHJv
Z3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k
aWZ5Cj4+ICsgKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQ
dWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQKPj4gKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZv
dW5kYXRpb247IHZlcnNpb24gMi4xIG9ubHkuIHdpdGggdGhlIHNwZWNpYWwKPj4gKyAqIGV4Y2Vw
dGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBmaWxlIExJQ0VOU0UuCj4+ICsgKgo+PiArICog
VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1
c2VmdWwsCj4+ICsgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZgo+PiArICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLiDCoFNlZSB0aGUKPj4gKyAqIEdOVSBMZXNzZXIgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgo+PiArICovCj4+ICsvKgo+PiArICog
SW50ZXJuYWwgY2hpbGQgcHJvY2VzcyBtYWNoaW5lcnkgZm9yIHVzZSBieSBvdGhlciBwYXJ0cyBv
ZiBsaWJ4bAo+PiArICovCj4+ICsKPj4gKyNpbmNsdWRlICJsaWJ4bF9vc2RlcHMuaCIgLyogbXVz
dCBjb21lIGJlZm9yZSBhbnkgb3RoZXIgaGVhZGVycyAqLwo+PiArCj4+ICsjaW5jbHVkZSAibGli
eGxfaW50ZXJuYWwuaCIKPj4gKwo+PiArLyoKPj4gKyAqIGNhcmVmZCBhcnJhbmdlbWVudHMKPj4g
KyAqCj4+ICsgKiBjYXJlZmRfYmVnaW4gYW5kIF91bmxvY2sgdGFrZSBvdXQgdGhlIG5vX2Zvcmtp
bmcgbG9jaywgd2hpY2ggd2UKPj4gKyAqIGFsc28gdGFrZSBhbmQgcmVsZWFzZSBpbiBvdXIgcHRo
cmVhZF9hdGZvcmsgaGFuZGxlcnMuIMKgU28gd2hlbiB0aGlzCj4+ICsgKiBsb2NrIGlzIGhlbGQg
dGhlIHdob2xlIHByb2Nlc3MgY2Fubm90IGZvcmsuIMKgV2UgdGhlcmVmb3JlIHByb3RlY3QKPj4g
KyAqIG91ciBmZHMgZnJvbSBsZWFraW5nIGludG8gY2hpbGRyZW4gbWFkZSBieSBvdGhlciB0aHJl
YWRzLgo+PiArICoKPj4gKyAqIFdlIG1haW50YWluIGEgbGlzdCBvZiBhbGwgdGhlIGNhcmVmZHMs
IHNvIHRoYXQgaWYgdGhlIGFwcGxpY2F0aW9uCj4+ICsgKiB3YW50cyB0byBmb3JrIGEgbG9uZy1y
dW5uaW5nIGJ1dCBub24tZXhlY2luZyBjaGlsZCwgd2UgY2FuIGNsb3NlCj4+ICsgKiB0aGVtIGFs
bC4KPj4gKyAqCj4+ICsgKiBTbyB0aGUgcmVjb3JkIGZ1bmN0aW9uIHNldHMgQ0xPRVhFQyBmb3Ig
dGhlIGJlbmVmaXQgb2YgZXhlY2luZwo+PiArICogY2hpbGRyZW4sIGFuZCBtYWtlcyBhIG5vdGUg
b2YgdGhlIGZkIGZvciB0aGUgYmVuZWZpdCBvZiBub24tZXhlY2luZwo+PiArICogb25lcy4KPj4g
KyAqLwo+PiArCj4+ICtzdHJ1Y3QgbGlieGxfX2NhcmVmZCB7Cj4+ICsgwqAgwqBMSUJYTF9MSVNU
X0VOVFJZKGxpYnhsX19jYXJlZmQpIGVudHJ5Owo+PiArIMKgIMKgaW50IGZkOwo+PiArfTsKPj4g
Kwo+PiArc3RhdGljIHB0aHJlYWRfbXV0ZXhfdCBub19mb3JraW5nID0gUFRIUkVBRF9NVVRFWF9J
TklUSUFMSVpFUjsKPgo+IFdlIHByZXZpb3VzbHkgaGFkIHRyb3VibGUgd2l0aCBQVEhSRUFEX1JF
Q1VSU0lWRV9NVVRFWF9JTklUSUFMSVpFUl9OUAo+IG5vdCBiZWluZyBkZWZpbmVkIG9uIE5ldEJT
RC4KPgo+IGh0dHA6Ly93d3cuZGFlbW9uLXN5c3RlbXMub3JnL21hbi9wdGhyZWFkX211dGV4X2lu
aXQuMy5odG1sIHN1Z2dlc3RzCj4gUFRIUkVBRF9NVVRFWF9JTklUSUFMSVpFUiBpcyBidXQgcGVy
aGFwcyB3ZSBzaG91bGQgY29uZmlybT8KCgpKdXN0IHRlc3RlZCBvbiBhIE5ldEJTRCBzeXN0ZW0s
IGFuZCBQVEhSRUFEX01VVEVYX0lOSVRJQUxJWkVSIG1hY3JvIGlzIGFsbG93ZWQuCgo+PiArc3Rh
dGljIGludCBhdGZvcmtfcmVnaXN0ZXJlZDsKPgo+IERvZXMgcHRocmVhZF9hdGZvcmsgcGVyc2lz
dCBpbnRvIHRoZSBjaGlsZHJlbj8KPgo+IElmIHRoZSBwYXJlbnQgaGFzIHNldCB0aGlzIHRoZW4g
aXQgd2lsbCBiZSBzZXQgZm9yIHRoZSBjaGlsZCB0b28sIHdoaWNoCj4gaWYgdGhlIGFuc3dlciB0
byBteSBxdWVzdGlvbiBpcyAiTm8iIGlzIGEgcHJvYmxlbS4KPgo+IEkgc3VzcGVjdCB0aGUgYW5z
d2VyIGlzIHllcyB0aG91Z2guCj4KPj4gK3N0YXRpYyBMSUJYTF9MSVNUX0hFQUQoLCBsaWJ4bF9f
Y2FyZWZkKSBjYXJlZmRzID0KPj4gKyDCoCDCoExJQlhMX0xJU1RfSEVBRF9JTklUSUFMSVpFUihj
YXJlZmRzKTsKPj4gKwo+PiArc3RhdGljIHZvaWQgYXRmb3JrX2xvY2sodm9pZCkKPj4gK3sKPj4g
KyDCoCDCoGludCByID0gcHRocmVhZF9tdXRleF9sb2NrKCZub19mb3JraW5nKTsKPj4gKyDCoCDC
oGFzc2VydCghcik7Cj4+ICt9Cj4+ICsKPj4gK3N0YXRpYyB2b2lkIGF0Zm9ya191bmxvY2sodm9p
ZCkKPj4gK3sKPj4gKyDCoCDCoGludCByID0gcHRocmVhZF9tdXRleF91bmxvY2soJm5vX2Zvcmtp
bmcpOwo+PiArIMKgIMKgYXNzZXJ0KCFyKTsKPj4gK30KPj4gKwo+PiAraW50IGxpYnhsX19hdGZv
cmtfaW5pdChsaWJ4bF9jdHggKmN0eCkKPj4gK3sKPj4gKyDCoCDCoGludCByLCByYzsKPj4gKwo+
PiArIMKgIMKgYXRmb3JrX2xvY2soKTsKPj4gKyDCoCDCoGlmIChhdGZvcmtfcmVnaXN0ZXJlZCkK
Pgo+IE1pc3NpbmcgYW4gdW5sb2NrPwo+Cj4+ICsgwqAgwqAgwqAgwqByZXR1cm4gMDsKPj4gKwo+
PiArIMKgIMKgciA9IHB0aHJlYWRfYXRmb3JrKGF0Zm9ya19sb2NrLCBhdGZvcmtfdW5sb2NrLCBh
dGZvcmtfdW5sb2NrKTsKPj4gKyDCoCDCoGlmIChyKSB7Cj4+ICsgwqAgwqAgwqAgwqBMSUJYTF9f
TE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgInB0aHJlYWRfYXRmb3JrIGZhaWxlZCIp
Owo+PiArIMKgIMKgIMKgIMKgcmMgPSBFUlJPUl9OT01FTTsKPj4gKyDCoCDCoCDCoCDCoGdvdG8g
b3V0Owo+PiArIMKgIMKgfQo+PiArCj4+ICsgwqAgwqBhdGZvcmtfcmVnaXN0ZXJlZCA9IDE7Cj4+
ICsgwqAgwqByYyA9IDA7Cj4+ICsgb3V0Ogo+PiArIMKgIMKgYXRmb3JrX3VubG9jaygpOwo+PiAr
IMKgIMKgcmV0dXJuIHJjOwo+PiArfQo+PiArCj4+ICt2b2lkIGxpYnhsX19jYXJlZmRfYmVnaW4o
dm9pZCkgeyBhdGZvcmtfbG9jaygpOyB9Cj4+ICt2b2lkIGxpYnhsX19jYXJlZmRfdW5sb2NrKHZv
aWQpIHsgYXRmb3JrX3VubG9jaygpOyB9Cj4KPiBUaGlzIG5hbWluZyBzZWVtcyBhc3ltbWV0cmlj
Lgo+Cj4gSWFuLgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNl
LmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:09:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzS3M-0000wO-UI; Mon, 20 Feb 2012 12:09:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzS3L-0000vs-Ff
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:09:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329739739!5868027!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5810 invoked from network); 20 Feb 2012 12:08:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:08:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10808661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 12:08:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 12:08:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzS38-00019z-DW;
	Mon, 20 Feb 2012 12:08:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzS38-0008Bo-Am;
	Mon, 20 Feb 2012 12:08:58 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11982-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 12:08:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11982: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11982 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11982/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 11891
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11891
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11891
 build-amd64                   2 host-install(2)         broken REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-i386-i386-pv             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-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-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  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-pv           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-win         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  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl           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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:09:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzS3M-0000wO-UI; Mon, 20 Feb 2012 12:09:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzS3L-0000vs-Ff
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:09:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329739739!5868027!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5810 invoked from network); 20 Feb 2012 12:08:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:08:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,450,1325462400"; d="scan'208";a="10808661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 12:08:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 12:08:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzS38-00019z-DW;
	Mon, 20 Feb 2012 12:08:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzS38-0008Bo-Am;
	Mon, 20 Feb 2012 12:08:58 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11982-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 12:08:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11982: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11982 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11982/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 11891
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11891
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11891
 build-amd64                   2 host-install(2)         broken REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-i386-i386-pv             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-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-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  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-pv           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-win         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  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl           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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzS5f-0001CY-10; Mon, 20 Feb 2012 12:11:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzS5c-0001C5-O8
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 12:11:34 +0000
Received: from [85.158.139.83:41485] by server-12.bemta-5.messagelabs.com id
	56/3D-24595-378324F4; Mon, 20 Feb 2012 12:11:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329739888!15795773!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19536 invoked from network); 20 Feb 2012 12:11:29 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:11:29 -0000
Received: by mail-wi0-f173.google.com with SMTP id hi20so2556592wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.132.94 as permitted sender) client-ip=10.216.132.94; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.132.94 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.132.94])
	by 10.216.132.94 with SMTP id n72mr4296618wei.4.1329739888998 (num_hops
	= 1); Mon, 20 Feb 2012 04:11:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=9uzeDS99kwbBtQD6t4MOODIo2GWXuNfcBDtw84NeUjU=;
	b=Ox2me8XQWrDWc5jfFP8DLNgCEpk8wS4Itz0TYCnIUVFVY6gsyWSNKEW6mwXjsyy2E0
	KlMPQnBkTny3eJGF1rWxSKVyLzzs1eHAFfHHcgLZO3INhCROt1aCXsQnsaCTvug4kH1W
	8xAZpcxTbxAOetY9oalHUjXDuLSti7cK7IpaU=
Received: by 10.216.132.94 with SMTP id n72mr3565344wei.4.1329739888950;
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm15310975wib.11.2012.02.20.04.11.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org,
	qemu-devel@nongnu.org
Date: Mon, 20 Feb 2012 13:11:20 +0100
Message-Id: <1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
In-Reply-To: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 2/2] build: replace librt check function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace clock_gettime with timer_gettime, since at least under
uclibc 0.9.33 the clock_getttime function can be used without linking
against librt (although the manual page states the opposite).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 configure |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 7bcd547..fb99632 100755
--- a/configure
+++ b/configure
@@ -2438,7 +2438,8 @@ fi
 cat > $TMPC <<EOF
 #include <signal.h>
 #include <time.h>
-int main(void) { clockid_t id; return clock_gettime(id, NULL); }
+int main(void) { timer_t tid; struct itimerspec it; \
+                 return timer_gettime(tid, &it); }
 EOF
 
 if compile_prog "" "" ; then
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzS5b-0001Bv-KU; Mon, 20 Feb 2012 12:11:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzS5a-0001Bg-AP
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 12:11:30 +0000
Received: from [85.158.139.83:5685] by server-6.bemta-5.messagelabs.com id
	EF/86-27305-178324F4; Mon, 20 Feb 2012 12:11:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329739888!15795773!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19521 invoked from network); 20 Feb 2012 12:11:28 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:11:28 -0000
Received: by wibhi20 with SMTP id hi20so2556592wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.181.11.227 as permitted sender) client-ip=10.181.11.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.181.11.227 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.181.11.227])
	by 10.181.11.227 with SMTP id el3mr16481443wid.18.1329739888332
	(num_hops = 1); Mon, 20 Feb 2012 04:11:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=ONaeAPHdV3XErXRDSKEOHu72b6D1+jyeIa27snLyvA8=;
	b=J1cTinshm4+YYbnP0uA9dbJw1cqtedRmpJHNFPNy/WSTCgqwQYW5Itx0KqrmQ/gYDw
	nzioKph07P/AGNYEZLTlI9TRq6upBNnbnWcqDejj4OV6Q7YoWca8ysczb+4HFaGz9s+j
	BXknTu9DVrguJAVhrwum4iqcd+mEF48Yt6v+E=
Received: by 10.181.11.227 with SMTP id el3mr13660320wid.18.1329739888269;
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm15310975wib.11.2012.02.20.04.11.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org,
	qemu-devel@nongnu.org
Date: Mon, 20 Feb 2012 13:11:19 +0100
Message-Id: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 1/2] build: check if libm is needed in configure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Remove the hardcoded use of libm and instead rely on configure to
check for it. It is needed at least for qemu-ga and qemu-system.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 Makefile.target |    4 ----
 configure       |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index a111521..1bfd419 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -33,10 +33,6 @@ endif
 PROGS=$(QEMU_PROG)
 STPFILES=
 
-ifndef CONFIG_HAIKU
-LIBS+=-lm
-endif
-
 config-target.h: config-target.h-timestamp
 config-target.h-timestamp: config-target.mak
 
diff --git a/configure b/configure
index b113f60..7bcd547 100755
--- a/configure
+++ b/configure
@@ -2447,6 +2447,20 @@ elif compile_prog "" "-lrt" ; then
   LIBS="-lrt $LIBS"
 fi
 
+##########################################
+# Do we need libm
+cat > $TMPC <<EOF
+#include <math.h>
+int main(void) { double a, b; return modf(a, &b);}
+EOF
+
+if compile_prog "" "" ; then
+  :
+elif compile_prog "" "-lm" ; then
+  LIBS="-lm $LIBS"
+  libs_qga="-lm $libs_qga"
+fi
+
 if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
         "$aix" != "yes" -a "$haiku" != "yes" ; then
     libs_softmmu="-lutil $libs_softmmu"
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzS5f-0001CY-10; Mon, 20 Feb 2012 12:11:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzS5c-0001C5-O8
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 12:11:34 +0000
Received: from [85.158.139.83:41485] by server-12.bemta-5.messagelabs.com id
	56/3D-24595-378324F4; Mon, 20 Feb 2012 12:11:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329739888!15795773!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19536 invoked from network); 20 Feb 2012 12:11:29 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:11:29 -0000
Received: by mail-wi0-f173.google.com with SMTP id hi20so2556592wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.132.94 as permitted sender) client-ip=10.216.132.94; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.132.94 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.132.94])
	by 10.216.132.94 with SMTP id n72mr4296618wei.4.1329739888998 (num_hops
	= 1); Mon, 20 Feb 2012 04:11:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=9uzeDS99kwbBtQD6t4MOODIo2GWXuNfcBDtw84NeUjU=;
	b=Ox2me8XQWrDWc5jfFP8DLNgCEpk8wS4Itz0TYCnIUVFVY6gsyWSNKEW6mwXjsyy2E0
	KlMPQnBkTny3eJGF1rWxSKVyLzzs1eHAFfHHcgLZO3INhCROt1aCXsQnsaCTvug4kH1W
	8xAZpcxTbxAOetY9oalHUjXDuLSti7cK7IpaU=
Received: by 10.216.132.94 with SMTP id n72mr3565344wei.4.1329739888950;
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm15310975wib.11.2012.02.20.04.11.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org,
	qemu-devel@nongnu.org
Date: Mon, 20 Feb 2012 13:11:20 +0100
Message-Id: <1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
In-Reply-To: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 2/2] build: replace librt check function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace clock_gettime with timer_gettime, since at least under
uclibc 0.9.33 the clock_getttime function can be used without linking
against librt (although the manual page states the opposite).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 configure |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 7bcd547..fb99632 100755
--- a/configure
+++ b/configure
@@ -2438,7 +2438,8 @@ fi
 cat > $TMPC <<EOF
 #include <signal.h>
 #include <time.h>
-int main(void) { clockid_t id; return clock_gettime(id, NULL); }
+int main(void) { timer_t tid; struct itimerspec it; \
+                 return timer_gettime(tid, &it); }
 EOF
 
 if compile_prog "" "" ; then
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzS5b-0001Bv-KU; Mon, 20 Feb 2012 12:11:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzS5a-0001Bg-AP
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 12:11:30 +0000
Received: from [85.158.139.83:5685] by server-6.bemta-5.messagelabs.com id
	EF/86-27305-178324F4; Mon, 20 Feb 2012 12:11:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329739888!15795773!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19521 invoked from network); 20 Feb 2012 12:11:28 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:11:28 -0000
Received: by wibhi20 with SMTP id hi20so2556592wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.181.11.227 as permitted sender) client-ip=10.181.11.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.181.11.227 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.181.11.227])
	by 10.181.11.227 with SMTP id el3mr16481443wid.18.1329739888332
	(num_hops = 1); Mon, 20 Feb 2012 04:11:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=ONaeAPHdV3XErXRDSKEOHu72b6D1+jyeIa27snLyvA8=;
	b=J1cTinshm4+YYbnP0uA9dbJw1cqtedRmpJHNFPNy/WSTCgqwQYW5Itx0KqrmQ/gYDw
	nzioKph07P/AGNYEZLTlI9TRq6upBNnbnWcqDejj4OV6Q7YoWca8ysczb+4HFaGz9s+j
	BXknTu9DVrguJAVhrwum4iqcd+mEF48Yt6v+E=
Received: by 10.181.11.227 with SMTP id el3mr13660320wid.18.1329739888269;
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm15310975wib.11.2012.02.20.04.11.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 04:11:28 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org,
	qemu-devel@nongnu.org
Date: Mon, 20 Feb 2012 13:11:19 +0100
Message-Id: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 1/2] build: check if libm is needed in configure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Remove the hardcoded use of libm and instead rely on configure to
check for it. It is needed at least for qemu-ga and qemu-system.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 Makefile.target |    4 ----
 configure       |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index a111521..1bfd419 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -33,10 +33,6 @@ endif
 PROGS=$(QEMU_PROG)
 STPFILES=
 
-ifndef CONFIG_HAIKU
-LIBS+=-lm
-endif
-
 config-target.h: config-target.h-timestamp
 config-target.h-timestamp: config-target.mak
 
diff --git a/configure b/configure
index b113f60..7bcd547 100755
--- a/configure
+++ b/configure
@@ -2447,6 +2447,20 @@ elif compile_prog "" "-lrt" ; then
   LIBS="-lrt $LIBS"
 fi
 
+##########################################
+# Do we need libm
+cat > $TMPC <<EOF
+#include <math.h>
+int main(void) { double a, b; return modf(a, &b);}
+EOF
+
+if compile_prog "" "" ; then
+  :
+elif compile_prog "" "-lm" ; then
+  LIBS="-lm $LIBS"
+  libs_qga="-lm $libs_qga"
+fi
+
 if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
         "$aix" != "yes" -a "$haiku" != "yes" ; then
     libs_softmmu="-lutil $libs_softmmu"
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:16:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzSAP-0001fD-Qr; Mon, 20 Feb 2012 12:16:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzSAO-0001es-3j
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:16:28 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329740180!12186731!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1808 invoked from network); 20 Feb 2012 12:16:21 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2012 12:16:21 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzSAF-00036f-TV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 04:16:19 -0800
Date: Mon, 20 Feb 2012 04:16:19 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329740179907-5498848.post@n5.nabble.com>
In-Reply-To: <1329738941603-5498806.post@n5.nabble.com>
References: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
	<1329478339260-5492208.post@n5.nabble.com> <4F3E7E2F.5@vido.info>
	<1329738941603-5498806.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I forgot to mention that only using gfx_passthru=0 option (and not
pci=[01:00.0])and with the output pci-list-assignable-devices showing the
graphic card, I cannot see the card on Windows Guest so If i try to install
the nVidia driver it reports that there isn't any compatible hardware.

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5498848.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:16:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12: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.xensource.com>)
	id 1RzSAP-0001fD-Qr; Mon, 20 Feb 2012 12:16:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzSAO-0001es-3j
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:16:28 +0000
X-Env-Sender: javiapple@hotmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329740180!12186731!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1808 invoked from network); 20 Feb 2012 12:16:21 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2012 12:16:21 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <javiapple@hotmail.com>) id 1RzSAF-00036f-TV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 04:16:19 -0800
Date: Mon, 20 Feb 2012 04:16:19 -0800 (PST)
From: Jamesffs <javiapple@hotmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1329740179907-5498848.post@n5.nabble.com>
In-Reply-To: <1329738941603-5498806.post@n5.nabble.com>
References: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1323504740494-5063848.post@n5.nabble.com>
	<1323520193389-5064245.post@n5.nabble.com>
	<1323810239102-5072769.post@n5.nabble.com>
	<201112141043.45780.tobias.geiger@vido.info>
	<1329399537084-5489530.post@n5.nabble.com>
	<201202170934.41725.tobias.geiger@vido.info>
	<1329478339260-5492208.post@n5.nabble.com> <4F3E7E2F.5@vido.info>
	<1329738941603-5498806.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
 VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I forgot to mention that only using gfx_passthru=0 option (and not
pci=[01:00.0])and with the output pci-list-assignable-devices showing the
graphic card, I cannot see the card on Windows Guest so If i try to install
the nVidia driver it reports that there isn't any compatible hardware.

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5498848.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzSEf-0001wF-OK; Mon, 20 Feb 2012 12:20:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzSEd-0001w6-VG
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:20:52 +0000
Received: from [85.158.139.83:2576] by server-9.bemta-5.messagelabs.com id
	0D/A5-30171-3AA324F4; Mon, 20 Feb 2012 12:20:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329740450!15804218!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12561 invoked from network); 20 Feb 2012 12:20:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:20:50 -0000
Received: by wibhm2 with SMTP id hm2so10982116wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 04:20:50 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr20897908wib.3.1329740450540 (num_hops
	= 1); Mon, 20 Feb 2012 04:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=oZugWe0y676rxbCeVMvYwl0S1cEbeBNOO5lPUsPri8c=;
	b=p7kScpqEoxsASU34I4WpRW3MKSNw/MuIXu/kN6Qvo6jT58DLyqBtXxhMFtISqYkB4c
	SYtKM33/bfCTiJUusOu0CRmc5zpLbnllYkVdMOOHqfNtScvanQNjevCeK57YLxWY+9oY
	8FC8vuvjcgMUBXniHW3e+x5p+uN6e2z6SEx6M=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr17414569wib.3.1329740450502; Mon,
	20 Feb 2012 04:20:50 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 04:20:50 -0800 (PST)
In-Reply-To: <20286.41164.369217.262696@mariner.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
	<20286.41164.369217.262696@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:20:50 +0100
X-Google-Sender-Auth: p-fG15AOv52PFYDWEpV6cQJ64B4
Message-ID: <CAPLaKK58M23DUo0wzDV_KSFQZKs0wJPiGHvE9FN8EaK54O8uKg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE3IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBJYW4g
SmFja3NvbiB3cml0ZXMgKCJbUEFUQ0ggMC8zXSBsaWJ4bDogUGVybWl0IGltbWVkaWF0ZSBhc3lu
Y2hyb25vdXMgY29tcGxldGlvbiIpOgo+PiBJYW4gSmFja3NvbiB3cml0ZXMgKCJSZTogW1hlbi1k
ZXZlbF0gW1BBVENIIDA4LzExXSBsaWJ4bDogQXN5bmNocm9ub3VzL2xvbmctcnVubmluZyBvcGVy
YXRpb24gaW5mcmFzdHJ1Y3R1cmUiKToKPj4gPiBZZXMsIHlvdSBhcmUgcmlnaHQsIHRoZXJlIGlz
IGEgYnVnIGluIGxpYnhsX2RldmljZV9kaXNrX3JlbW92ZSAvCj4+ID4gbGlieGxfX2luaXRpYXRl
X2RldmljZV9yZW1vdmUuIMKgSSBoYWRuJ3Qgc3BvdHRlZCB0aGF0IHRoZSAib3V0IiBwYXRoCj4+
ID4gZnJvbSB0aGUgb2xkIGRldmljZSByZW1vdmFsIGNvZGUgd2FzIHVzZWQgaW4gYSBzdWNjZXNz
IGNhc2UgdG9vLgo+PiA+Cj4+ID4gSSB3aWxsIGZpeCBpdC4KPj4KPj4gUGxlYXNlIHRha2UgYSBs
b29rIGF0IHRoZSBmb2xsb3dpbmcgMy1wYXRjaCBzZXJpZXMuIMKgSSBoYXZlIGNvbXBpbGVkCj4+
IGl0IGJ1dCBub3QgdGVzdGVkIGl0LCBidXQgSSB0aGluayBzb21ldGhpbmcgbGlrZSBpdCBzaG91
bGQgd29yay4KPgo+IFNvcnJ5LCBSb2dlciwgdGhlIHdheSBJIHNlbnQgdGhpcyBtYWlsIG9taXR0
ZWQgeW91IGZyb20gdGhlIENDLgo+Cj4+IMKgMS8zIGxpYnhsOiBhbzogYWxsb3cgaW1tZWRpYXRl
IGNvbXBsZXRpb24KPj4gwqAyLzMgbGlieGw6IGZpeCBoYW5nIGR1ZSB0byBsaWJ4bF9faW5pdGlh
dGVfZGV2aWNlX3JlbW92ZQo+PiDCoDMvMyBsaWJ4bDogRml4IGV2ZW50bG9vcF9pdGVyYXRpb24g
b3Zlci1sb2NraW5nCj4+Cj4+IEhvcGVmdWxseSAxLzMgYW5kIDIvMyB3aWxsIG1ha2UgdGhlIGlu
dGVuZGVkIGJlaGF2aW91ciwgYW5kIHRoZQo+PiBpbnRlbmRlZCB1c2FnZSBjbGVhci4gwqBTb3Jy
eSBmb3IgY29uZnVzaW5nIHlvdSB3aXRoIGEgYmFkIGV4YW1wbGUhCgpucCwgdGhhbmtzIGZvciB0
aGUgcXVpY2sgZml4LCBJIHdvdWxkIGxpa2UgdG8gdGVzdCB0aG9zZSBwYXRjaGVzIHRoaXMKYWZ0
ZXJub29uIGlmIEkgaGF2ZSBzb21lIHRpbWUgYW5kIHNoYXJlIHRoZSByZXN1bHRzLgoKPiBJYW4u
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 20 12:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 12:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzSEf-0001wF-OK; Mon, 20 Feb 2012 12:20:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzSEd-0001w6-VG
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 12:20:52 +0000
Received: from [85.158.139.83:2576] by server-9.bemta-5.messagelabs.com id
	0D/A5-30171-3AA324F4; Mon, 20 Feb 2012 12:20:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329740450!15804218!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12561 invoked from network); 20 Feb 2012 12:20:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 12:20:50 -0000
Received: by wibhm2 with SMTP id hm2so10982116wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 04:20:50 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr20897908wib.3.1329740450540 (num_hops
	= 1); Mon, 20 Feb 2012 04:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=oZugWe0y676rxbCeVMvYwl0S1cEbeBNOO5lPUsPri8c=;
	b=p7kScpqEoxsASU34I4WpRW3MKSNw/MuIXu/kN6Qvo6jT58DLyqBtXxhMFtISqYkB4c
	SYtKM33/bfCTiJUusOu0CRmc5zpLbnllYkVdMOOHqfNtScvanQNjevCeK57YLxWY+9oY
	8FC8vuvjcgMUBXniHW3e+x5p+uN6e2z6SEx6M=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr17414569wib.3.1329740450502; Mon,
	20 Feb 2012 04:20:50 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 04:20:50 -0800 (PST)
In-Reply-To: <20286.41164.369217.262696@mariner.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
	<20286.41164.369217.262696@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:20:50 +0100
X-Google-Sender-Auth: p-fG15AOv52PFYDWEpV6cQJ64B4
Message-ID: <CAPLaKK58M23DUo0wzDV_KSFQZKs0wJPiGHvE9FN8EaK54O8uKg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzE3IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBJYW4g
SmFja3NvbiB3cml0ZXMgKCJbUEFUQ0ggMC8zXSBsaWJ4bDogUGVybWl0IGltbWVkaWF0ZSBhc3lu
Y2hyb25vdXMgY29tcGxldGlvbiIpOgo+PiBJYW4gSmFja3NvbiB3cml0ZXMgKCJSZTogW1hlbi1k
ZXZlbF0gW1BBVENIIDA4LzExXSBsaWJ4bDogQXN5bmNocm9ub3VzL2xvbmctcnVubmluZyBvcGVy
YXRpb24gaW5mcmFzdHJ1Y3R1cmUiKToKPj4gPiBZZXMsIHlvdSBhcmUgcmlnaHQsIHRoZXJlIGlz
IGEgYnVnIGluIGxpYnhsX2RldmljZV9kaXNrX3JlbW92ZSAvCj4+ID4gbGlieGxfX2luaXRpYXRl
X2RldmljZV9yZW1vdmUuIMKgSSBoYWRuJ3Qgc3BvdHRlZCB0aGF0IHRoZSAib3V0IiBwYXRoCj4+
ID4gZnJvbSB0aGUgb2xkIGRldmljZSByZW1vdmFsIGNvZGUgd2FzIHVzZWQgaW4gYSBzdWNjZXNz
IGNhc2UgdG9vLgo+PiA+Cj4+ID4gSSB3aWxsIGZpeCBpdC4KPj4KPj4gUGxlYXNlIHRha2UgYSBs
b29rIGF0IHRoZSBmb2xsb3dpbmcgMy1wYXRjaCBzZXJpZXMuIMKgSSBoYXZlIGNvbXBpbGVkCj4+
IGl0IGJ1dCBub3QgdGVzdGVkIGl0LCBidXQgSSB0aGluayBzb21ldGhpbmcgbGlrZSBpdCBzaG91
bGQgd29yay4KPgo+IFNvcnJ5LCBSb2dlciwgdGhlIHdheSBJIHNlbnQgdGhpcyBtYWlsIG9taXR0
ZWQgeW91IGZyb20gdGhlIENDLgo+Cj4+IMKgMS8zIGxpYnhsOiBhbzogYWxsb3cgaW1tZWRpYXRl
IGNvbXBsZXRpb24KPj4gwqAyLzMgbGlieGw6IGZpeCBoYW5nIGR1ZSB0byBsaWJ4bF9faW5pdGlh
dGVfZGV2aWNlX3JlbW92ZQo+PiDCoDMvMyBsaWJ4bDogRml4IGV2ZW50bG9vcF9pdGVyYXRpb24g
b3Zlci1sb2NraW5nCj4+Cj4+IEhvcGVmdWxseSAxLzMgYW5kIDIvMyB3aWxsIG1ha2UgdGhlIGlu
dGVuZGVkIGJlaGF2aW91ciwgYW5kIHRoZQo+PiBpbnRlbmRlZCB1c2FnZSBjbGVhci4gwqBTb3Jy
eSBmb3IgY29uZnVzaW5nIHlvdSB3aXRoIGEgYmFkIGV4YW1wbGUhCgpucCwgdGhhbmtzIGZvciB0
aGUgcXVpY2sgZml4LCBJIHdvdWxkIGxpa2UgdG8gdGVzdCB0aG9zZSBwYXRjaGVzIHRoaXMKYWZ0
ZXJub29uIGlmIEkgaGF2ZSBzb21lIHRpbWUgYW5kIHNoYXJlIHRoZSByZXN1bHRzLgoKPiBJYW4u
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:11:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13: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.xensource.com>)
	id 1RzT1J-0002xk-E9; Mon, 20 Feb 2012 13:11:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RzT1I-0002xd-D0
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:11:08 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329743409!54966010!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31846 invoked from network); 20 Feb 2012 13:10:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 13:10:09 -0000
Received: by wibhm2 with SMTP id hm2so11080233wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 05:11:01 -0800 (PST)
Received-SPF: pass (google.com: domain of pstroud@gmail.com designates
	10.180.78.130 as permitted sender) client-ip=10.180.78.130; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of pstroud@gmail.com
	designates 10.180.78.130 as permitted sender)
	smtp.mail=pstroud@gmail.com;
	dkim=pass header.i=pstroud@gmail.com
Received: from mr.google.com ([10.180.78.130])
	by 10.180.78.130 with SMTP id b2mr18400243wix.1.1329743461346 (num_hops
	= 1); Mon, 20 Feb 2012 05:11:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=LfjJj0YHdaa7ZpfrbLAoYssH0F1CGXsieugWEvlOwLE=;
	b=QO3Hh6VJMiQpn4CL7UxGFPr/0u8XRfLPeA0eAla/bjk89OpxpXsZCrBVY8slJ5+kUa
	K55AXfMfrzKGMnzrT5i5pJQNHWvMbWc7daCNQ/9WNDof6RXU9g0YWOO46Ggo9cK72xt1
	1ZA4lhMXGgNMKMekDZ1lBn53sXK4hw/tH7sv4=
MIME-Version: 1.0
Received: by 10.180.78.130 with SMTP id b2mr15352815wix.1.1329743461250; Mon,
	20 Feb 2012 05:11:01 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Mon, 20 Feb 2012 05:11:01 -0800 (PST)
In-Reply-To: <CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
	<CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
Date: Mon, 20 Feb 2012 08:11:01 -0500
Message-ID: <CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8123549550420521161=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8123549550420521161==
Content-Type: multipart/alternative; boundary=f46d043438aca675f004b965066b

--f46d043438aca675f004b965066b
Content-Type: text/plain; charset=ISO-8859-1

So, the problem has something to do with grub2-efi. After installing
XenServer the second time, I noticed that it did not create an EFI Boot
partition. To that end, I booted the Fedora CD in normal mode, instead of
UEFI mode, created a boot bios, and once installed that way, I was able to
run 4.1.2. So, I'm not sure if the problem lies in grub or xen, or the
combination of the two, but that is where the problem exists.

On Fri, Feb 17, 2012 at 4:31 PM, Paul S <pstroud@gmail.com> wrote:

> File attached.
>
>
> On Fri, Feb 17, 2012 at 4:14 PM, Paul S <pstroud@gmail.com> wrote:
>
>> Andrew,
>> Thanks for the quick response! I was finally able to capture it and get a
>> bit more information. The problem does not always happen, even on 4.1.2, I
>> was able to get it to boot a few times, though I was never able to get
>> 4.2-unstable to boot. There was lots of strangeness, such as after I built
>> and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
>> working.
>>
>> That being said, I caught it on video, and captured a picture of the
>> final dump. I watched the video frame by frame and the boot actually got
>> much further than I thought it was.
>>
>> I can see that even though it does not bring up two of the CPUs, the boot
>> continues into the kernel and dies somewhere with a:
>>
>> BUG: Unable to handle paging request at FFFc7f(maybe).
>>
>> I have captured several images from the video that shows the progression
>> of the boot before the crash. I think I have gotten things badly out of
>> whack at this point, so I'm going to stop, reinstall everything and move
>> back to 4.1.1 and see if I can get things working again.
>>
>> Let me know if anything in the pictures helps, or if you would like the
>> video as well.
>>
>> Paul
>>
>> On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper <
>> andrew.cooper3@citrix.com> wrote:
>>
>>> On 17/02/12 16:21, Paul S wrote:
>>> > Environment:
>>> > ASRock Z86 Extreme4 - Intel i5 2500
>>> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
>>> >
>>> > I have installed the latest UEFI patch(1.70) and all tests were run
>>> > from a reset of everything to default. I have tested with both Ubuntu
>>> > 11.10 and Fedora 16 and get the same results on both, including
>>> > building xen 4.2-unstable. I bought this particular MB because it had
>>> > a know working vt-d implementation via VMWare.
>>> >
>>> > NOTE: current unstable as of last night is still affected by this
>>> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
>>> >
>>> > However, after correcting the library error, I was able to complete
>>> > the unstable build.
>>> >
>>> > In both cases, it either stops with a panic/blank screen, or just
>>> reboots.
>>> >
>>> > Here are some other notes:
>>> >
>>> > 1) If x2apic is enabled on the motherboard, it almost immediately
>>> > reboots with any of the configurations above
>>>
>>> There are some fairly strict set of requirements on what which MSRs you
>>> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
>>> early in boot which results in a protection fault.
>>>
>>> >
>>> > 2) The boot gets to here:
>>> >
>>> > (XEN) HVM: VMX enabled
>>> >
>>> > (XEN) HVM: Hardware Assisted Paging detected.
>>> >
>>> >
>>> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
>>> > where it hangs with the blank/panic screen or reboots. This sometimes
>>> > shows up on CPU 1, CPU2, or both.
>>> >
>>> >
>>> > 3) There is no boot log written and the machine does not have a native
>>> > serial port, so capturing anything may prove difficult, but I am open
>>> > to suggestions.
>>> >
>>>
>>> Try booting with noreboot - that should keep any panic message on screen
>>> until you manually choose to reset the machine.  Seeing where in the
>>> panic occurs would be very helpful, even if you just transcribe a few
>>> lines manually.
>>>
>>> >
>>> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
>>> > is enabled, then it simply panics and reboots.
>>> >
>>> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
>>> > being enabled, but I did check it with VT-d enabled and the boot
>>> > looked the same. I can capture it again if needed.
>>> >
>>> >
>>> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
>>> > enabled(which shows working in xl) and x2apic enabled.
>>> >
>>> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
>>> > includes logs both with and without VT-d and x2apic enabled. I did not
>>> > actually create any VMs, only booted this and checked what xl reported.
>>> >
>>> >
>>>
>>> That is rather interesting - I am not aware of any XenServer specific
>>> changes in this regard.
>>>
>>> > If there is anything else I can add, please let me know. I am going to
>>> > download 4.1.1 now, build it and see if it works, because it does on
>>> > Xen Server. I am open to testing anything as this is an original build
>>> > on this box, so I'm willing to knock it around if it will help.
>>> >
>>> > #
>>> >
>>>
>>> Knowing whether upstream 4.1.1 works will be very useful in workout out
>>> whether it is a regression introduced into unstable, or whether there is
>>> some XenServer specific change which we should upstream.
>>>
>>> > Thanks,
>>> >
>>> > Paul
>>> >
>>>
>>> --
>>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>>> T: +44 (0)1223 225 900, http://www.citrix.com
>>>
>>>
>>
>

--f46d043438aca675f004b965066b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So, the problem has something to do with grub2-efi. After installing XenSer=
ver the second time, I noticed that it did not create an EFI Boot partition=
. To that end, I booted the Fedora CD in normal mode, instead of UEFI mode,=
 created a boot bios, and once installed that way, I was able to run 4.1.2.=
 So, I&#39;m not sure if the problem lies in grub or xen, or the combinatio=
n of the two, but that is where the problem exists.<div>
<br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 4:31 PM, Paul S <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:pstroud@gmail.com">pstroud@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">
File attached.<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D=
"gmail_quote">On Fri, Feb 17, 2012 at 4:14 PM, Paul S <span dir=3D"ltr">&lt=
;<a href=3D"mailto:pstroud@gmail.com" target=3D"_blank">pstroud@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>Andrew,<br>Thanks for the quick response!=A0I was finally able to capt=
ure it and get a bit more information. The problem does not always happen, =
even on 4.1.2, I was able to=A0get it to boot a few times, though I was nev=
er able to get 4.2-unstable to boot. There was lots of strangeness, such as=
 after I built and installed 4.1.1, it worked, but then, so did 4.1.2, now =
neither is working.</div>


<div><br></div><div>That being said, I caught it on video, and captured a p=
icture of the final dump. I watched the video frame by frame and the boot a=
ctually got much further than I thought it was.=A0</div><div><br>I can see =
that even though it does not bring up two of the CPUs, the boot continues i=
nto the kernel and dies somewhere with a:</div>


<div><br></div><div>BUG: Unable to handle paging request at FFFc7f(maybe).<=
/div><div><br></div><div>I have captured several images from the video that=
 shows the progression of the boot before the crash. I think I have gotten =
things badly out of whack at this point, so I&#39;m going to stop, reinstal=
l everything and move back to 4.1.1 and see if I can get things working aga=
in. =A0</div>


<div><br></div><div>Let me know if anything in the pictures helps, or if yo=
u would like the video as well.=A0</div><span><font color=3D"#888888"><div>=
<br></div><div>Paul</div></font></span><div>
<div><div><br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 11:39 AM, =
Andrew Cooper <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.cooper3@citrix=
.com" target=3D"_blank">andrew.cooper3@citrix.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 17/02/12 16:21, Paul S wrote:<br>
&gt; Environment:<br>
&gt; ASRock Z86 Extreme4 - Intel i5 2500<br>
&gt; <a href=3D"http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme=
4" target=3D"_blank">http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Ex=
treme4</a><br>
&gt;<br>
&gt; I have installed the latest UEFI patch(1.70) and all tests were run<br=
>
&gt; from a reset of everything to default. I have tested with both Ubuntu<=
br>
&gt; 11.10 and Fedora 16 and get the same results on both, including<br>
&gt; building xen 4.2-unstable. I bought this particular MB because it had<=
br>
&gt; a know working vt-d implementation via VMWare.<br>
&gt;<br>
&gt; NOTE: current unstable as of last night is still affected by this<br>
&gt; library error <a href=3D"http://www.gossamer-threads.com/lists/xen/dev=
el/234300" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/deve=
l/234300</a><br>
&gt;<br>
&gt; However, after correcting the library error, I was able to complete<br=
>
&gt; the unstable build.<br>
&gt;<br>
&gt; In both cases, it either stops with a panic/blank screen, or just rebo=
ots.<br>
&gt;<br>
&gt; Here are some other notes:<br>
&gt;<br>
&gt; 1) If x2apic is enabled on the motherboard, it almost immediately<br>
&gt; reboots with any of the configurations above<br>
<br>
</div>There are some fairly strict set of requirements on what which MSRs y=
ou<br>
can wrt xAPIC/x2APIC mode. =A0It is possible that we are tickling an MSR<br=
>
early in boot which results in a protection fault.<br>
<div><br>
&gt;<br>
&gt; 2) The boot gets to here:<br>
&gt;<br>
&gt; (XEN) HVM: VMX enabled<br>
&gt;<br>
&gt; (XEN) HVM: Hardware Assisted Paging detected.<br>
&gt;<br>
&gt;<br>
&gt; Then goes to a &quot;(XEN)Failed to bring up CPU x(error -5)&quot; and=
 this is<br>
&gt; where it hangs with the blank/panic screen or reboots. This sometimes<=
br>
&gt; shows up on CPU 1, CPU2, or both.<br>
&gt;<br>
&gt;<br>
&gt; 3) There is no boot log written and the machine does not have a native=
<br>
&gt; serial port, so capturing anything may prove difficult, but I am open<=
br>
&gt; to suggestions.<br>
&gt;<br>
<br>
</div>Try booting with noreboot - that should keep any panic message on scr=
een<br>
until you manually choose to reset the machine. =A0Seeing where in the<br>
panic occurs would be very helpful, even if you just transcribe a few<br>
lines manually.<br>
<div><br>
&gt;<br>
&gt; 4) Xen Live(<a href=3D"http://wiki.xen.org/wiki/LiveCD" target=3D"_bla=
nk">http://wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic<br>
&gt; is enabled, then it simply panics and reboots.<br>
&gt;<br>
&gt; The logs(xen_live.tgz) are attached. Note this was captured with VT-d<=
br>
&gt; being enabled, but I did check it with VT-d enabled and the boot<br>
&gt; looked the same. I can capture it again if needed.<br>
&gt;<br>
&gt;<br>
&gt; 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d<br>
&gt; enabled(which shows working in xl) and x2apic enabled.<br>
&gt;<br>
&gt; I have also attached(xen_server_6.0.0.tar.gz) these logs, which<br>
&gt; includes logs both with and without VT-d and x2apic enabled. I did not=
<br>
&gt; actually create any VMs, only booted this and checked what xl reported=
.<br>
&gt;<br>
&gt;<br>
<br>
</div>That is rather interesting - I am not aware of any XenServer specific=
<br>
changes in this regard.<br>
<div><br>
&gt; If there is anything else I can add, please let me know. I am going to=
<br>
&gt; download 4.1.1 now, build it and see if it works, because it does on<b=
r>
&gt; Xen Server. I am open to testing anything as this is an original build=
<br>
&gt; on this box, so I&#39;m willing to knock it around if it will help.<br=
>
&gt;<br>
</div>&gt; #<br>
&gt;<br>
<br>
Knowing whether upstream 4.1.1 works will be very useful in workout out<br>
whether it is a regression introduced into unstable, or whether there is<br=
>
some XenServer specific change which we should upstream.<br>
<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
<span><font color=3D"#888888"><br>
--<br>
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
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><br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br></div>

--f46d043438aca675f004b965066b--


--===============8123549550420521161==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8123549550420521161==--


From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:11:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13: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.xensource.com>)
	id 1RzT1J-0002xk-E9; Mon, 20 Feb 2012 13:11:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pstroud@gmail.com>) id 1RzT1I-0002xd-D0
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:11:08 +0000
X-Env-Sender: pstroud@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329743409!54966010!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31846 invoked from network); 20 Feb 2012 13:10:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 13:10:09 -0000
Received: by wibhm2 with SMTP id hm2so11080233wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 05:11:01 -0800 (PST)
Received-SPF: pass (google.com: domain of pstroud@gmail.com designates
	10.180.78.130 as permitted sender) client-ip=10.180.78.130; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of pstroud@gmail.com
	designates 10.180.78.130 as permitted sender)
	smtp.mail=pstroud@gmail.com;
	dkim=pass header.i=pstroud@gmail.com
Received: from mr.google.com ([10.180.78.130])
	by 10.180.78.130 with SMTP id b2mr18400243wix.1.1329743461346 (num_hops
	= 1); Mon, 20 Feb 2012 05:11:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=LfjJj0YHdaa7ZpfrbLAoYssH0F1CGXsieugWEvlOwLE=;
	b=QO3Hh6VJMiQpn4CL7UxGFPr/0u8XRfLPeA0eAla/bjk89OpxpXsZCrBVY8slJ5+kUa
	K55AXfMfrzKGMnzrT5i5pJQNHWvMbWc7daCNQ/9WNDof6RXU9g0YWOO46Ggo9cK72xt1
	1ZA4lhMXGgNMKMekDZ1lBn53sXK4hw/tH7sv4=
MIME-Version: 1.0
Received: by 10.180.78.130 with SMTP id b2mr15352815wix.1.1329743461250; Mon,
	20 Feb 2012 05:11:01 -0800 (PST)
Received: by 10.216.48.69 with HTTP; Mon, 20 Feb 2012 05:11:01 -0800 (PST)
In-Reply-To: <CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
	<CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
Date: Mon, 20 Feb 2012 08:11:01 -0500
Message-ID: <CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
From: Paul S <pstroud@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8123549550420521161=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8123549550420521161==
Content-Type: multipart/alternative; boundary=f46d043438aca675f004b965066b

--f46d043438aca675f004b965066b
Content-Type: text/plain; charset=ISO-8859-1

So, the problem has something to do with grub2-efi. After installing
XenServer the second time, I noticed that it did not create an EFI Boot
partition. To that end, I booted the Fedora CD in normal mode, instead of
UEFI mode, created a boot bios, and once installed that way, I was able to
run 4.1.2. So, I'm not sure if the problem lies in grub or xen, or the
combination of the two, but that is where the problem exists.

On Fri, Feb 17, 2012 at 4:31 PM, Paul S <pstroud@gmail.com> wrote:

> File attached.
>
>
> On Fri, Feb 17, 2012 at 4:14 PM, Paul S <pstroud@gmail.com> wrote:
>
>> Andrew,
>> Thanks for the quick response! I was finally able to capture it and get a
>> bit more information. The problem does not always happen, even on 4.1.2, I
>> was able to get it to boot a few times, though I was never able to get
>> 4.2-unstable to boot. There was lots of strangeness, such as after I built
>> and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
>> working.
>>
>> That being said, I caught it on video, and captured a picture of the
>> final dump. I watched the video frame by frame and the boot actually got
>> much further than I thought it was.
>>
>> I can see that even though it does not bring up two of the CPUs, the boot
>> continues into the kernel and dies somewhere with a:
>>
>> BUG: Unable to handle paging request at FFFc7f(maybe).
>>
>> I have captured several images from the video that shows the progression
>> of the boot before the crash. I think I have gotten things badly out of
>> whack at this point, so I'm going to stop, reinstall everything and move
>> back to 4.1.1 and see if I can get things working again.
>>
>> Let me know if anything in the pictures helps, or if you would like the
>> video as well.
>>
>> Paul
>>
>> On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper <
>> andrew.cooper3@citrix.com> wrote:
>>
>>> On 17/02/12 16:21, Paul S wrote:
>>> > Environment:
>>> > ASRock Z86 Extreme4 - Intel i5 2500
>>> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
>>> >
>>> > I have installed the latest UEFI patch(1.70) and all tests were run
>>> > from a reset of everything to default. I have tested with both Ubuntu
>>> > 11.10 and Fedora 16 and get the same results on both, including
>>> > building xen 4.2-unstable. I bought this particular MB because it had
>>> > a know working vt-d implementation via VMWare.
>>> >
>>> > NOTE: current unstable as of last night is still affected by this
>>> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
>>> >
>>> > However, after correcting the library error, I was able to complete
>>> > the unstable build.
>>> >
>>> > In both cases, it either stops with a panic/blank screen, or just
>>> reboots.
>>> >
>>> > Here are some other notes:
>>> >
>>> > 1) If x2apic is enabled on the motherboard, it almost immediately
>>> > reboots with any of the configurations above
>>>
>>> There are some fairly strict set of requirements on what which MSRs you
>>> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
>>> early in boot which results in a protection fault.
>>>
>>> >
>>> > 2) The boot gets to here:
>>> >
>>> > (XEN) HVM: VMX enabled
>>> >
>>> > (XEN) HVM: Hardware Assisted Paging detected.
>>> >
>>> >
>>> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
>>> > where it hangs with the blank/panic screen or reboots. This sometimes
>>> > shows up on CPU 1, CPU2, or both.
>>> >
>>> >
>>> > 3) There is no boot log written and the machine does not have a native
>>> > serial port, so capturing anything may prove difficult, but I am open
>>> > to suggestions.
>>> >
>>>
>>> Try booting with noreboot - that should keep any panic message on screen
>>> until you manually choose to reset the machine.  Seeing where in the
>>> panic occurs would be very helpful, even if you just transcribe a few
>>> lines manually.
>>>
>>> >
>>> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
>>> > is enabled, then it simply panics and reboots.
>>> >
>>> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
>>> > being enabled, but I did check it with VT-d enabled and the boot
>>> > looked the same. I can capture it again if needed.
>>> >
>>> >
>>> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
>>> > enabled(which shows working in xl) and x2apic enabled.
>>> >
>>> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
>>> > includes logs both with and without VT-d and x2apic enabled. I did not
>>> > actually create any VMs, only booted this and checked what xl reported.
>>> >
>>> >
>>>
>>> That is rather interesting - I am not aware of any XenServer specific
>>> changes in this regard.
>>>
>>> > If there is anything else I can add, please let me know. I am going to
>>> > download 4.1.1 now, build it and see if it works, because it does on
>>> > Xen Server. I am open to testing anything as this is an original build
>>> > on this box, so I'm willing to knock it around if it will help.
>>> >
>>> > #
>>> >
>>>
>>> Knowing whether upstream 4.1.1 works will be very useful in workout out
>>> whether it is a regression introduced into unstable, or whether there is
>>> some XenServer specific change which we should upstream.
>>>
>>> > Thanks,
>>> >
>>> > Paul
>>> >
>>>
>>> --
>>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>>> T: +44 (0)1223 225 900, http://www.citrix.com
>>>
>>>
>>
>

--f46d043438aca675f004b965066b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So, the problem has something to do with grub2-efi. After installing XenSer=
ver the second time, I noticed that it did not create an EFI Boot partition=
. To that end, I booted the Fedora CD in normal mode, instead of UEFI mode,=
 created a boot bios, and once installed that way, I was able to run 4.1.2.=
 So, I&#39;m not sure if the problem lies in grub or xen, or the combinatio=
n of the two, but that is where the problem exists.<div>
<br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 4:31 PM, Paul S <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:pstroud@gmail.com">pstroud@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">
File attached.<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D=
"gmail_quote">On Fri, Feb 17, 2012 at 4:14 PM, Paul S <span dir=3D"ltr">&lt=
;<a href=3D"mailto:pstroud@gmail.com" target=3D"_blank">pstroud@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>Andrew,<br>Thanks for the quick response!=A0I was finally able to capt=
ure it and get a bit more information. The problem does not always happen, =
even on 4.1.2, I was able to=A0get it to boot a few times, though I was nev=
er able to get 4.2-unstable to boot. There was lots of strangeness, such as=
 after I built and installed 4.1.1, it worked, but then, so did 4.1.2, now =
neither is working.</div>


<div><br></div><div>That being said, I caught it on video, and captured a p=
icture of the final dump. I watched the video frame by frame and the boot a=
ctually got much further than I thought it was.=A0</div><div><br>I can see =
that even though it does not bring up two of the CPUs, the boot continues i=
nto the kernel and dies somewhere with a:</div>


<div><br></div><div>BUG: Unable to handle paging request at FFFc7f(maybe).<=
/div><div><br></div><div>I have captured several images from the video that=
 shows the progression of the boot before the crash. I think I have gotten =
things badly out of whack at this point, so I&#39;m going to stop, reinstal=
l everything and move back to 4.1.1 and see if I can get things working aga=
in. =A0</div>


<div><br></div><div>Let me know if anything in the pictures helps, or if yo=
u would like the video as well.=A0</div><span><font color=3D"#888888"><div>=
<br></div><div>Paul</div></font></span><div>
<div><div><br><div class=3D"gmail_quote">On Fri, Feb 17, 2012 at 11:39 AM, =
Andrew Cooper <span dir=3D"ltr">&lt;<a href=3D"mailto:andrew.cooper3@citrix=
.com" target=3D"_blank">andrew.cooper3@citrix.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 17/02/12 16:21, Paul S wrote:<br>
&gt; Environment:<br>
&gt; ASRock Z86 Extreme4 - Intel i5 2500<br>
&gt; <a href=3D"http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Extreme=
4" target=3D"_blank">http://www.asrock.com/mb/overview.asp?Model=3DZ68%20Ex=
treme4</a><br>
&gt;<br>
&gt; I have installed the latest UEFI patch(1.70) and all tests were run<br=
>
&gt; from a reset of everything to default. I have tested with both Ubuntu<=
br>
&gt; 11.10 and Fedora 16 and get the same results on both, including<br>
&gt; building xen 4.2-unstable. I bought this particular MB because it had<=
br>
&gt; a know working vt-d implementation via VMWare.<br>
&gt;<br>
&gt; NOTE: current unstable as of last night is still affected by this<br>
&gt; library error <a href=3D"http://www.gossamer-threads.com/lists/xen/dev=
el/234300" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/deve=
l/234300</a><br>
&gt;<br>
&gt; However, after correcting the library error, I was able to complete<br=
>
&gt; the unstable build.<br>
&gt;<br>
&gt; In both cases, it either stops with a panic/blank screen, or just rebo=
ots.<br>
&gt;<br>
&gt; Here are some other notes:<br>
&gt;<br>
&gt; 1) If x2apic is enabled on the motherboard, it almost immediately<br>
&gt; reboots with any of the configurations above<br>
<br>
</div>There are some fairly strict set of requirements on what which MSRs y=
ou<br>
can wrt xAPIC/x2APIC mode. =A0It is possible that we are tickling an MSR<br=
>
early in boot which results in a protection fault.<br>
<div><br>
&gt;<br>
&gt; 2) The boot gets to here:<br>
&gt;<br>
&gt; (XEN) HVM: VMX enabled<br>
&gt;<br>
&gt; (XEN) HVM: Hardware Assisted Paging detected.<br>
&gt;<br>
&gt;<br>
&gt; Then goes to a &quot;(XEN)Failed to bring up CPU x(error -5)&quot; and=
 this is<br>
&gt; where it hangs with the blank/panic screen or reboots. This sometimes<=
br>
&gt; shows up on CPU 1, CPU2, or both.<br>
&gt;<br>
&gt;<br>
&gt; 3) There is no boot log written and the machine does not have a native=
<br>
&gt; serial port, so capturing anything may prove difficult, but I am open<=
br>
&gt; to suggestions.<br>
&gt;<br>
<br>
</div>Try booting with noreboot - that should keep any panic message on scr=
een<br>
until you manually choose to reset the machine. =A0Seeing where in the<br>
panic occurs would be very helpful, even if you just transcribe a few<br>
lines manually.<br>
<div><br>
&gt;<br>
&gt; 4) Xen Live(<a href=3D"http://wiki.xen.org/wiki/LiveCD" target=3D"_bla=
nk">http://wiki.xen.org/wiki/LiveCD</a>) works ok, unless x2apic<br>
&gt; is enabled, then it simply panics and reboots.<br>
&gt;<br>
&gt; The logs(xen_live.tgz) are attached. Note this was captured with VT-d<=
br>
&gt; being enabled, but I did check it with VT-d enabled and the boot<br>
&gt; looked the same. I can capture it again if needed.<br>
&gt;<br>
&gt;<br>
&gt; 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d<br>
&gt; enabled(which shows working in xl) and x2apic enabled.<br>
&gt;<br>
&gt; I have also attached(xen_server_6.0.0.tar.gz) these logs, which<br>
&gt; includes logs both with and without VT-d and x2apic enabled. I did not=
<br>
&gt; actually create any VMs, only booted this and checked what xl reported=
.<br>
&gt;<br>
&gt;<br>
<br>
</div>That is rather interesting - I am not aware of any XenServer specific=
<br>
changes in this regard.<br>
<div><br>
&gt; If there is anything else I can add, please let me know. I am going to=
<br>
&gt; download 4.1.1 now, build it and see if it works, because it does on<b=
r>
&gt; Xen Server. I am open to testing anything as this is an original build=
<br>
&gt; on this box, so I&#39;m willing to knock it around if it will help.<br=
>
&gt;<br>
</div>&gt; #<br>
&gt;<br>
<br>
Knowing whether upstream 4.1.1 works will be very useful in workout out<br>
whether it is a regression introduced into unstable, or whether there is<br=
>
some XenServer specific change which we should upstream.<br>
<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
<span><font color=3D"#888888"><br>
--<br>
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
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><br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br></div>

--f46d043438aca675f004b965066b--


--===============8123549550420521161==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8123549550420521161==--


From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:32:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzTLh-0003Ix-Fb; Mon, 20 Feb 2012 13:32:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzTLg-0003Ip-4G
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:32:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329744724!10018017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 20 Feb 2012 13:32:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 13:32:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10812429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 13:32:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 13:32:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzTLY-00022X-BJ; Mon, 20 Feb 2012 13:32:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzTLY-0002HT-AJ;
	Mon, 20 Feb 2012 13:32:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.19284.270369.772434@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:32:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329733585.3990.13.camel@zakaz.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
	<1329733585.3990.13.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] [PATCH 1/3] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/3] libxl: ao: allow immediate completion"):
> On Fri, 2012-02-17 at 18:43 +0000, Ian Jackson wrote:
> > -    assert(ao->in_initiator);
> > +    assert(ao->constructing && ao->in_initiator);
> 
> Doing two asserts will make it clearer which condition is not satisfied
> if we ever see this.

Good point.  I was foolishly thinking of bitfield optimisations but
this code is not a hot path.

> > -    AO_GC;
> > +    EGC_INIT(ctx);
> 
> This means that the "gc" within a function which uses this macro is now
> "&egc->gc" rather than "&ao->gc".

You are right, and this is wrong.

> Another difference is that any function calling AO_CREATE cannot now be
> called from within libxl, since it now calls LIBXL__INIT_EGC which has
> this restriction. libxl_cdrom_insert does not obey this new restriction.

This restriction is not new.  libxl_cdrom_insert has always violated
it and needs converting to the new scheme of things.

The restriction is documented here in libxl_internal.h but sadly has a
"outside" when it should say "inside":

 * All "slow" functions (includes anything that might block on a
 * guest or an external script) need to use the asynchronous
 * operation ("ao") machinery.  The function should take a parameter
 * const libxl_asyncop_how *ao_how and must start with a call to
 * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
 * outside libxl, because they can cause reentrancy callbacks.

In practice I think libxl_cdrom_insert will not mind the reentrancy so
the bug is latent.  It doesn't take out the ctx lock, and although a
callback might involve messing with the same device there is no
difference between that and another process doing the same.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:32:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzTLh-0003Ix-Fb; Mon, 20 Feb 2012 13:32:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzTLg-0003Ip-4G
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:32:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329744724!10018017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 20 Feb 2012 13:32:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 13:32:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10812429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 13:32:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 13:32:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzTLY-00022X-BJ; Mon, 20 Feb 2012 13:32:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzTLY-0002HT-AJ;
	Mon, 20 Feb 2012 13:32:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.19284.270369.772434@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:32:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329733585.3990.13.camel@zakaz.uk.xensource.com>
References: <20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-2-git-send-email-ian.jackson@eu.citrix.com>
	<1329733585.3990.13.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] [PATCH 1/3] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/3] libxl: ao: allow immediate completion"):
> On Fri, 2012-02-17 at 18:43 +0000, Ian Jackson wrote:
> > -    assert(ao->in_initiator);
> > +    assert(ao->constructing && ao->in_initiator);
> 
> Doing two asserts will make it clearer which condition is not satisfied
> if we ever see this.

Good point.  I was foolishly thinking of bitfield optimisations but
this code is not a hot path.

> > -    AO_GC;
> > +    EGC_INIT(ctx);
> 
> This means that the "gc" within a function which uses this macro is now
> "&egc->gc" rather than "&ao->gc".

You are right, and this is wrong.

> Another difference is that any function calling AO_CREATE cannot now be
> called from within libxl, since it now calls LIBXL__INIT_EGC which has
> this restriction. libxl_cdrom_insert does not obey this new restriction.

This restriction is not new.  libxl_cdrom_insert has always violated
it and needs converting to the new scheme of things.

The restriction is documented here in libxl_internal.h but sadly has a
"outside" when it should say "inside":

 * All "slow" functions (includes anything that might block on a
 * guest or an external script) need to use the asynchronous
 * operation ("ao") machinery.  The function should take a parameter
 * const libxl_asyncop_how *ao_how and must start with a call to
 * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
 * outside libxl, because they can cause reentrancy callbacks.

In practice I think libxl_cdrom_insert will not mind the reentrancy so
the bug is latent.  It doesn't take out the ctx lock, and although a
callback might involve messing with the same device there is no
difference between that and another process doing the same.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:32:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzTLr-0003JL-Sz; Mon, 20 Feb 2012 13:32:23 +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 1RzTLq-0003JE-5E
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:32:22 +0000
Received: from [85.158.139.83:9569] by server-7.bemta-5.messagelabs.com id
	AC/B0-16195-56B424F4; Mon, 20 Feb 2012 13:32:21 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329744740!13108710!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13173 invoked from network); 20 Feb 2012 13:32:20 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-4.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 13:32:20 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 6F12FD347A0;
	Mon, 20 Feb 2012 14:32:20 +0100 (CET)
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 3QC+Vg-Ah8hR; Mon, 20 Feb 2012 14:32:14 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 18A1CD34727;
	Mon, 20 Feb 2012 14:32:14 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 14:32:12 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1329738941603-5498806.post@n5.nabble.com>
	<1329740179907-5498848.post@n5.nabble.com>
In-Reply-To: <1329740179907-5498848.post@n5.nabble.com>
MIME-Version: 1.0
Message-Id: <201202201432.13123.tobias.geiger@vido.info>
Cc: Jamesffs <javiapple@hotmail.com>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Seems to me youre trying to passthrough your primary card of dom0 - i have no 
experience with that at all, may well be this is not possible. i only pass 
through non-primary cards...
even if it is possible - with nvidia you normaly need manual corrections, 
meaning you can't pass it through withough modifications to the xen source (see 
david techers blog/homepage).

Greetings!
Tobias

Am Montag, 20. Februar 2012, 13:16:19 schrieb Jamesffs:
> I forgot to mention that only using gfx_passthru=0 option (and not
> pci=[01:00.0])and with the output pci-list-assignable-devices showing the
> graphic card, I cannot see the card on Windows Guest so If i try to install
> the nVidia driver it reports that there isn't any compatible hardware.
> 
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5498848.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:32:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzTLr-0003JL-Sz; Mon, 20 Feb 2012 13:32:23 +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 1RzTLq-0003JE-5E
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:32:22 +0000
Received: from [85.158.139.83:9569] by server-7.bemta-5.messagelabs.com id
	AC/B0-16195-56B424F4; Mon, 20 Feb 2012 13:32:21 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329744740!13108710!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13173 invoked from network); 20 Feb 2012 13:32:20 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-4.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 13:32:20 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 6F12FD347A0;
	Mon, 20 Feb 2012 14:32:20 +0100 (CET)
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 3QC+Vg-Ah8hR; Mon, 20 Feb 2012 14:32:14 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 18A1CD34727;
	Mon, 20 Feb 2012 14:32:14 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 14:32:12 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1323170568.90631.YahooMailNeo@web29813.mail.ird.yahoo.com>
	<1329738941603-5498806.post@n5.nabble.com>
	<1329740179907-5498848.post@n5.nabble.com>
In-Reply-To: <1329740179907-5498848.post@n5.nabble.com>
MIME-Version: 1.0
Message-Id: <201202201432.13123.tobias.geiger@vido.info>
Cc: Jamesffs <javiapple@hotmail.com>
Subject: Re: [Xen-devel] Re : Re : Re : Re : Re : Re : Re : Re: Patches for
	VGA-Passthrough XEN 4.2 unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Seems to me youre trying to passthrough your primary card of dom0 - i have no 
experience with that at all, may well be this is not possible. i only pass 
through non-primary cards...
even if it is possible - with nvidia you normaly need manual corrections, 
meaning you can't pass it through withough modifications to the xen source (see 
david techers blog/homepage).

Greetings!
Tobias

Am Montag, 20. Februar 2012, 13:16:19 schrieb Jamesffs:
> I forgot to mention that only using gfx_passthru=0 option (and not
> pci=[01:00.0])and with the output pci-list-assignable-devices showing the
> graphic card, I cannot see the card on Windows Guest so If i try to install
> the nVidia driver it reports that there isn't any compatible hardware.
> 
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta
> ble-tp4406265p5498848.html Sent from the Xen - Dev mailing list archive at
> Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:41:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13: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.xensource.com>)
	id 1RzTUP-0003bY-T6; Mon, 20 Feb 2012 13:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzTUO-0003bQ-Bz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:41:12 +0000
Received: from [85.158.139.83:7324] by server-9.bemta-5.messagelabs.com id
	8A/75-30171-77D424F4; Mon, 20 Feb 2012 13:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329745270!15811193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28480 invoked from network); 20 Feb 2012 13:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 13:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10812633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 13:41:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 13:41:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzTUM-0002Cw-GO; Mon, 20 Feb 2012 13:41:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzTUM-0002Je-FV;
	Mon, 20 Feb 2012 13:41:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.19830.466866.408084@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:41:10 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329735330.3990.31.camel@zakaz.uk.xensource.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
	<1329735330.3990.31.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] [PATCH 4/6] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even with forking threads"):
> On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> > As yet we do not use this anywherein libxl.  Until all locations in
> 
> "anywherein"

Fixed.

> > libxl which make such fds are converted, libxl__postfork may not work
> > entirely properly.  If these locations do not use O_CLOEXEC (or use
> > calls for which there is no O_CLOEXEC) then multithreaded programs may
> > not work properly.
> > 
> > This introduces a new API call libxl_postfork_child_noexec which must
> > be called by applications which make long-running non-execing
> > children.  Add the appropriate call to xl's postfork function.
> > 
> > On Linux pthread_atfork demands compilation with -pthread, so add
> > PTHREAD_CFLAGS, _LDFLAGS, _LIBS to the corresponding variables in the
> > libxl Makefile.  It is not clear why we got away without these before.
> 
> Since I assume the Makefile bit could safely be split out and applied,
> that bit is:
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

I'll split it out into a separate patch.

> > +/*
> > + * An application which initialises a libxl_ctx in a parent process
> > + * and then forks a child which does not quickly exec, must
> > + * instead libxl__postfork_child_noexec in the child.  One call
> > + * for all libxl contexts is sufficient.
> > + */
> > +void libxl_postfork_child_noexec(libxl_ctx *ctx);
> 
> Is the ctx passed here required to be one of the existing ctx's or a
> newly allocated one in this context?

I will clarify this comment.

> > +static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
> 
> We previously had trouble with PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
> not being defined on NetBSD.
> 
> http://www.daemon-systems.org/man/pthread_mutex_init.3.html suggests
> PTHREAD_MUTEX_INITIALIZER is but perhaps we should confirm?

PTHREAD_MUTEX_INITIALIZER is in POSIX and the _NP one isn't.  But I
see Roger has confirmed it's on BSD too, which is good.

> > +static int atfork_registered;
> 
> Does pthread_atfork persist into the children?
> 
> If the parent has set this then it will be set for the child too, which
> if the answer to my question is "No" is a problem.
> 
> I suspect the answer is yes though.

Yes.  (Although I can't find any explicit statement, I think it's
obvious.)

> > +    atfork_lock();
> > +    if (atfork_registered)
> > +        return 0;
> 
> Missing an unlock?

Silly me, I should be using "goto out" as that's what it's for.

> > +void libxl__carefd_begin(void) { atfork_lock(); }
> > +void libxl__carefd_unlock(void) { atfork_unlock(); }
> 
> This naming seems asymmetric.

It's not a symmetric situation.  The complete sequence is one of these
three:

   libxl__carefd_begin
   libxl__carefd_record
   libxl__carefd_unlock
   ...
   libxl__carefd_close

or

   libxl__carefd_begin
   libxl__carefd_opened
   ...
   libxl__carefd_close

or

   libxl__carefd_begin
   libxl__carefd_unlock

I'm open to suggestions for alternative names.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:41:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13: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.xensource.com>)
	id 1RzTUP-0003bY-T6; Mon, 20 Feb 2012 13:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzTUO-0003bQ-Bz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:41:12 +0000
Received: from [85.158.139.83:7324] by server-9.bemta-5.messagelabs.com id
	8A/75-30171-77D424F4; Mon, 20 Feb 2012 13:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329745270!15811193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28480 invoked from network); 20 Feb 2012 13:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 13:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10812633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 13:41:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 13:41:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzTUM-0002Cw-GO; Mon, 20 Feb 2012 13:41:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzTUM-0002Je-FV;
	Mon, 20 Feb 2012 13:41:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.19830.466866.408084@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:41:10 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329735330.3990.31.camel@zakaz.uk.xensource.com>
References: <1329506127-30969-1-git-send-email-ian.jackson@eu.citrix.com>
	<1329506127-30969-5-git-send-email-ian.jackson@eu.citrix.com>
	<1329735330.3990.31.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] [PATCH 4/6] libxl: Protect fds with CLOEXEC even
 with forking threads
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/6] libxl: Protect fds with CLOEXEC even with forking threads"):
> On Fri, 2012-02-17 at 19:15 +0000, Ian Jackson wrote:
> > As yet we do not use this anywherein libxl.  Until all locations in
> 
> "anywherein"

Fixed.

> > libxl which make such fds are converted, libxl__postfork may not work
> > entirely properly.  If these locations do not use O_CLOEXEC (or use
> > calls for which there is no O_CLOEXEC) then multithreaded programs may
> > not work properly.
> > 
> > This introduces a new API call libxl_postfork_child_noexec which must
> > be called by applications which make long-running non-execing
> > children.  Add the appropriate call to xl's postfork function.
> > 
> > On Linux pthread_atfork demands compilation with -pthread, so add
> > PTHREAD_CFLAGS, _LDFLAGS, _LIBS to the corresponding variables in the
> > libxl Makefile.  It is not clear why we got away without these before.
> 
> Since I assume the Makefile bit could safely be split out and applied,
> that bit is:
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

I'll split it out into a separate patch.

> > +/*
> > + * An application which initialises a libxl_ctx in a parent process
> > + * and then forks a child which does not quickly exec, must
> > + * instead libxl__postfork_child_noexec in the child.  One call
> > + * for all libxl contexts is sufficient.
> > + */
> > +void libxl_postfork_child_noexec(libxl_ctx *ctx);
> 
> Is the ctx passed here required to be one of the existing ctx's or a
> newly allocated one in this context?

I will clarify this comment.

> > +static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
> 
> We previously had trouble with PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
> not being defined on NetBSD.
> 
> http://www.daemon-systems.org/man/pthread_mutex_init.3.html suggests
> PTHREAD_MUTEX_INITIALIZER is but perhaps we should confirm?

PTHREAD_MUTEX_INITIALIZER is in POSIX and the _NP one isn't.  But I
see Roger has confirmed it's on BSD too, which is good.

> > +static int atfork_registered;
> 
> Does pthread_atfork persist into the children?
> 
> If the parent has set this then it will be set for the child too, which
> if the answer to my question is "No" is a problem.
> 
> I suspect the answer is yes though.

Yes.  (Although I can't find any explicit statement, I think it's
obvious.)

> > +    atfork_lock();
> > +    if (atfork_registered)
> > +        return 0;
> 
> Missing an unlock?

Silly me, I should be using "goto out" as that's what it's for.

> > +void libxl__carefd_begin(void) { atfork_lock(); }
> > +void libxl__carefd_unlock(void) { atfork_unlock(); }
> 
> This naming seems asymmetric.

It's not a symmetric situation.  The complete sequence is one of these
three:

   libxl__carefd_begin
   libxl__carefd_record
   libxl__carefd_unlock
   ...
   libxl__carefd_close

or

   libxl__carefd_begin
   libxl__carefd_opened
   ...
   libxl__carefd_close

or

   libxl__carefd_begin
   libxl__carefd_unlock

I'm open to suggestions for alternative names.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:45:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13: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.xensource.com>)
	id 1RzTXb-0003jH-Mf; Mon, 20 Feb 2012 13:44: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 1RzTXa-0003j6-6l
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:44:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329745435!57443379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21156 invoked from network); 20 Feb 2012 13:43:55 -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;
	20 Feb 2012 13:43:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10812718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 13:44:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 13:44:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzTXV-0002HY-Fe; Mon, 20 Feb 2012 13:44:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzTXV-00030Z-EX;
	Mon, 20 Feb 2012 13:44:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.20025.430801.661854@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:44:25 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK58M23DUo0wzDV_KSFQZKs0wJPiGHvE9FN8EaK54O8uKg@mail.gmail.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
	<20286.41164.369217.262696@mariner.uk.xensource.com>
	<CAPLaKK58M23DUo0wzDV_KSFQZKs0wJPiGHvE9FN8EaK54O8uKg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [PATCH 0/3] libxl: Permit immediate asynchro=
nous completion"):
> > Sorry, Roger, the way I sent this mail omitted you from the CC.
> >
> >> =A01/3 libxl: ao: allow immediate completion
> >> =A02/3 libxl: fix hang due to libxl__initiate_device_remove
> >> =A03/3 libxl: Fix eventloop_iteration over-locking
> >>
> >> Hopefully 1/3 and 2/3 will make the intended behaviour, and the
> >> intended usage clear. =A0Sorry for confusing you with a bad example!
> =

> np, thanks for the quick fix, I would like to test those patches this
> afternoon if I have some time and share the results.

Thank you, that would be awesome.  But note that I haven't executed
these myself yet.  You will almost certainly want the additional
patchlet below - thanks to Ian Campbell's review for spotting the bug.

Ian.

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7b8d0c2..6067dbe 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1233,7 +1233,8 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao =3D libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
-    EGC_INIT(ctx);
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
+    AO_GC;
 =

 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx =3D libxl__gc_owner(&ao->gc);          \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 13:45:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 13: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.xensource.com>)
	id 1RzTXb-0003jH-Mf; Mon, 20 Feb 2012 13:44: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 1RzTXa-0003j6-6l
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 13:44:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329745435!57443379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21156 invoked from network); 20 Feb 2012 13:43:55 -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;
	20 Feb 2012 13:43:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10812718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 13:44:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 13:44:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzTXV-0002HY-Fe; Mon, 20 Feb 2012 13:44:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzTXV-00030Z-EX;
	Mon, 20 Feb 2012 13:44:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.20025.430801.661854@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 13:44:25 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK58M23DUo0wzDV_KSFQZKs0wJPiGHvE9FN8EaK54O8uKg@mail.gmail.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
	<CAPLaKK4QDmQrTumkJL6Us-v0cw50mn6hiXsGhkuy2fQ546Moug@mail.gmail.com>
	<20283.43607.571172.475948@mariner.uk.xensource.com>
	<CAPLaKK7wZD_eSz3-RoDyWTDNfnWy9gZ5_CvUZRNpQsWW-x8DaQ@mail.gmail.com>
	<20286.31877.938411.558236@mariner.uk.xensource.com>
	<1329504239-19999-1-git-send-email-ian.jackson@eu.citrix.com>
	<20286.41164.369217.262696@mariner.uk.xensource.com>
	<CAPLaKK58M23DUo0wzDV_KSFQZKs0wJPiGHvE9FN8EaK54O8uKg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: Permit immediate asynchronous
	completion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [PATCH 0/3] libxl: Permit immediate asynchro=
nous completion"):
> > Sorry, Roger, the way I sent this mail omitted you from the CC.
> >
> >> =A01/3 libxl: ao: allow immediate completion
> >> =A02/3 libxl: fix hang due to libxl__initiate_device_remove
> >> =A03/3 libxl: Fix eventloop_iteration over-locking
> >>
> >> Hopefully 1/3 and 2/3 will make the intended behaviour, and the
> >> intended usage clear. =A0Sorry for confusing you with a bad example!
> =

> np, thanks for the quick fix, I would like to test those patches this
> afternoon if I have some time and share the results.

Thank you, that would be awesome.  But note that I haven't executed
these myself yet.  You will almost certainly want the additional
patchlet below - thanks to Ian Campbell's review for spotting the bug.

Ian.

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7b8d0c2..6067dbe 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1233,7 +1233,8 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao =3D libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
-    EGC_INIT(ctx);
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
+    AO_GC;
 =

 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx =3D libxl__gc_owner(&ao->gc);          \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:41:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:41:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUQN-0004Hs-EF; Mon, 20 Feb 2012 14:41:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RzUQL-0004Hn-64
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:41:05 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329748857!13953987!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14502 invoked from network); 20 Feb 2012 14:40:58 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 14:40:58 -0000
Received: by vbbfq11 with SMTP id fq11so12971748vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 06:40:57 -0800 (PST)
Received-SPF: pass (google.com: domain of kevin@koconnor.net designates
	10.52.27.10 as permitted sender) client-ip=10.52.27.10; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of kevin@koconnor.net
	designates 10.52.27.10 as permitted sender)
	smtp.mail=kevin@koconnor.net
Received: from mr.google.com ([10.52.27.10])
	by 10.52.27.10 with SMTP id p10mr10210734vdg.16.1329748857108 (num_hops
	= 1); Mon, 20 Feb 2012 06:40:57 -0800 (PST)
Received: by 10.52.27.10 with SMTP id p10mr8288466vdg.16.1329748856969;
	Mon, 20 Feb 2012 06:40:56 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id h8sm13653260vdj.20.2012.02.20.06.40.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 06:40:56 -0800 (PST)
Date: Mon, 20 Feb 2012 09:40:54 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120220144054.GA6547@morn.localdomain>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
	<1329731328.3990.1.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329731328.3990.1.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlAR7rRj9E3kzVizEvHN3/9CbhYGF0QPwXKe1tozkGNmBdMVEugQAEoiVO3X4Na/nPqKxT9
Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 09:48:48AM +0000, Ian Campbell wrote:
> On Mon, 2012-02-20 at 09:22 +0000, Roger Pau Monn=E9 wrote:
> > When looking into gen-offsets.sh [0] I've realized there's a strange
> > shebang in the script ":", is this normal? Replacing ":" with
> > "#!/bin/sh" solves the problem, but I don't understand why the ":"
> > shebang works for some (on Debian stable it works ok) and what it
> > means.
> =

> I've no idea either -- I've copied the seabios ML.

It's an old-style way of indicating the file is a shell script.  I
wasn't aware this creeped in there - it should be converted to the
more standard style.

-Kevin


commit 0fd9953a538b22e6087f9d4f25749e3622e40e87
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Mon Feb 20 09:33:23 2012 -0500

    Use "#!/bin/sh" instead of ":" in tools/gen-offsets.sh.
    =

    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

diff --git a/tools/gen-offsets.sh b/tools/gen-offsets.sh
index 99fdc53..73dede8 100755
--- a/tools/gen-offsets.sh
+++ b/tools/gen-offsets.sh
@@ -1,4 +1,4 @@
-:
+#!/bin/sh
 # Extract definitions from an assembler file.  This is based on code
 # from the Linux Kernel.
 INFILE=3D$1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:41:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:41:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUQN-0004Hs-EF; Mon, 20 Feb 2012 14:41:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kevin@koconnor.net>) id 1RzUQL-0004Hn-64
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:41:05 +0000
X-Env-Sender: kevin@koconnor.net
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329748857!13953987!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14502 invoked from network); 20 Feb 2012 14:40:58 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 14:40:58 -0000
Received: by vbbfq11 with SMTP id fq11so12971748vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 06:40:57 -0800 (PST)
Received-SPF: pass (google.com: domain of kevin@koconnor.net designates
	10.52.27.10 as permitted sender) client-ip=10.52.27.10; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of kevin@koconnor.net
	designates 10.52.27.10 as permitted sender)
	smtp.mail=kevin@koconnor.net
Received: from mr.google.com ([10.52.27.10])
	by 10.52.27.10 with SMTP id p10mr10210734vdg.16.1329748857108 (num_hops
	= 1); Mon, 20 Feb 2012 06:40:57 -0800 (PST)
Received: by 10.52.27.10 with SMTP id p10mr8288466vdg.16.1329748856969;
	Mon, 20 Feb 2012 06:40:56 -0800 (PST)
Received: from localhost
	(207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com.
	[207.172.165.101])
	by mx.google.com with ESMTPS id h8sm13653260vdj.20.2012.02.20.06.40.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 06:40:56 -0800 (PST)
Date: Mon, 20 Feb 2012 09:40:54 -0500
From: Kevin O'Connor <kevin@koconnor.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120220144054.GA6547@morn.localdomain>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
	<1329731328.3990.1.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329731328.3990.1.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlAR7rRj9E3kzVizEvHN3/9CbhYGF0QPwXKe1tozkGNmBdMVEugQAEoiVO3X4Na/nPqKxT9
Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org
Subject: Re: [Xen-devel] [SeaBIOS] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 09:48:48AM +0000, Ian Campbell wrote:
> On Mon, 2012-02-20 at 09:22 +0000, Roger Pau Monn=E9 wrote:
> > When looking into gen-offsets.sh [0] I've realized there's a strange
> > shebang in the script ":", is this normal? Replacing ":" with
> > "#!/bin/sh" solves the problem, but I don't understand why the ":"
> > shebang works for some (on Debian stable it works ok) and what it
> > means.
> =

> I've no idea either -- I've copied the seabios ML.

It's an old-style way of indicating the file is a shell script.  I
wasn't aware this creeped in there - it should be converted to the
more standard style.

-Kevin


commit 0fd9953a538b22e6087f9d4f25749e3622e40e87
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Mon Feb 20 09:33:23 2012 -0500

    Use "#!/bin/sh" instead of ":" in tools/gen-offsets.sh.
    =

    Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

diff --git a/tools/gen-offsets.sh b/tools/gen-offsets.sh
index 99fdc53..73dede8 100755
--- a/tools/gen-offsets.sh
+++ b/tools/gen-offsets.sh
@@ -1,4 +1,4 @@
-:
+#!/bin/sh
 # Extract definitions from an assembler file.  This is based on code
 # from the Linux Kernel.
 INFILE=3D$1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:44:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUTA-0004NA-0h; Mon, 20 Feb 2012 14:44: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 1RzUT8-0004N3-Tz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:43:59 +0000
Received: from [85.158.139.83:10691] by server-11.bemta-5.messagelabs.com id
	08/85-14397-E2C524F4; Mon, 20 Feb 2012 14:43:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329749037!15833943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25574 invoked from network); 20 Feb 2012 14:43:57 -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;
	20 Feb 2012 14:43:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10814446"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 14:43:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 14:43:57 +0000
Message-ID: <1329749035.3990.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 20 Feb 2012 14:43:55 +0000
In-Reply-To: <20120219093105.GA30637@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
	<20120219093105.GA30637@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH v2] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We do not do any lazy state switching. Outside of context_switch() the current
stack is always that of the VCPU which current returns.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/asm-offsets.c    |    4 ++
 xen/arch/arm/domain.c         |  113 ++++++++++++----------------------------
 xen/arch/arm/domain_build.c   |    3 +-
 xen/arch/arm/entry.S          |   16 ++++++
 xen/arch/arm/setup.c          |    5 +-
 xen/include/asm-arm/current.h |   35 +++++++------
 xen/include/asm-arm/domain.h  |   21 +++++++-
 xen/include/asm-arm/regs.h    |    4 +-
 xen/include/asm-arm/system.h  |    2 +
 9 files changed, 101 insertions(+), 102 deletions(-)

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
index ee5d5d4..cc1a72a 100644
--- a/xen/arch/arm/asm-offsets.c
+++ b/xen/arch/arm/asm-offsets.c
@@ -7,6 +7,7 @@
 
 #include <xen/config.h>
 #include <xen/types.h>
+#include <xen/sched.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -65,7 +66,10 @@ void __dummy__(void)
    BLANK();
 
    DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..a0b9d38 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -44,7 +44,7 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
-
+    context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
@@ -52,52 +52,36 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
 }
 
-static void __context_switch(void)
+static void schedule_tail(struct vcpu *prev)
 {
-    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
-    unsigned int          cpu = smp_processor_id();
-    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
-    struct vcpu          *n = current;
-
-    ASSERT(p != n);
-    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
-
-    if ( !is_idle_vcpu(p) )
-    {
-        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_from(p);
-    }
+    /* Re-enable interrupts before restoring state which may fault. */
+    local_irq_enable();
 
-    if ( !is_idle_vcpu(n) )
-    {
-        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_to(n);
-    }
-
-    per_cpu(curr_vcpu, cpu) = n;
+    ctxt_switch_from(prev);
 
+    /* TODO
+       update_runstate_area(current);
+    */
+    ctxt_switch_to(current);
 }
 
-static void schedule_tail(struct vcpu *v)
+static void continue_new_vcpu(struct vcpu *prev)
 {
-    if ( is_idle_vcpu(v) )
-        continue_idle_domain(v);
+    schedule_tail(prev);
+
+    if ( is_idle_vcpu(current) )
+        continue_idle_domain(current);
     else
-        continue_nonidle_domain(v);
+        continue_nonidle_domain(current);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
-    unsigned int cpu = smp_processor_id();
-
     ASSERT(local_irq_is_enabled());
-
-    printk("context switch %d:%d%s -> %d:%d%s\n",
-           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
-           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+    ASSERT(prev != next);
+    ASSERT(cpumask_empty(next->vcpu_dirty_cpumask));
 
     /* TODO
-       if (prev != next)
        update_runstate_area(prev);
     */
 
@@ -105,60 +89,19 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     set_current(next);
 
-    if ( (per_cpu(curr_vcpu, cpu) == next) ||
-         (is_idle_vcpu(next) && cpu_online(cpu)) )
-    {
-        local_irq_enable();
-    }
-    else
-    {
-        __context_switch();
-
-        /* Re-enable interrupts before restoring state which may fault. */
-        local_irq_enable();
-    }
-
-    context_saved(prev);
-
-    /* TODO
-       if (prev != next)
-       update_runstate_area(next);
-    */
-
-    schedule_tail(next);
-    BUG();
+    prev = __context_switch(prev, next);
 
+    schedule_tail(prev);
 }
 
 void continue_running(struct vcpu *same)
 {
-    schedule_tail(same);
-    BUG();
-}
-
-int __sync_local_execstate(void)
-{
-    unsigned long flags;
-    int switch_required;
-
-    local_irq_save(flags);
-
-    switch_required = (this_cpu(curr_vcpu) != current);
-
-    if ( switch_required )
-    {
-        ASSERT(current == idle_vcpu[smp_processor_id()]);
-        __context_switch();
-    }
-
-    local_irq_restore(flags);
-
-    return switch_required;
+    /* Nothing to do */
 }
 
 void sync_local_execstate(void)
 {
-    (void)__sync_local_execstate();
+    /* Nothing to do -- no lazy switching */
 }
 
 void startup_cpu_idle_loop(void)
@@ -213,6 +156,18 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    v->arch.stack = alloc_xenheap_pages(STACK_ORDER, MEMF_node(vcpu_to_node(v)));
+    if ( v->arch.stack == NULL )
+        return -ENOMEM;
+
+    v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
+                                           + STACK_SIZE
+                                           - sizeof(struct cpu_info));
+
+    memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
+    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
@@ -224,7 +179,7 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-
+    free_xenheap_pages(v->arch.stack, STACK_ORDER);
 }
 
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..9240209 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -5,6 +5,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/irq.h>
+#include <asm/regs.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -71,7 +72,7 @@ int construct_dom0(struct domain *d)
     int rc;
 
     struct vcpu *v = d->vcpu[0];
-    struct cpu_user_regs *regs = &v->arch.user_regs;
+    struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
     /* Sanity! */
     BUG_ON(d->domain_id != 0);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 16a8f36..0b9cce5 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -105,3 +105,19 @@ ENTRY(return_to_hypervisor)
 	pop {r0-r12}
 	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
 	eret
+
+/*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * r0 - prev
+ * r1 - next
+ *
+ * Returns prev in r0
+ */
+ENTRY(__context_switch)
+	add	ip, r0, #VCPU_arch_saved_context
+	stmia	ip!, {r4 - sl, fp, sp, lr}	/* Save register state */
+
+	add	r4, r1, #VCPU_arch_saved_context
+	ldmia	r4, {r4 - sl, fp, sp, pc}	/* Load registers and return */
+
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4c1d89ce..4c0244c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -42,7 +42,7 @@
 static unsigned int __initdata max_cpus = NR_CPUS;
 
 /* Xen stack for bringing up the first CPU. */
-unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
 extern char __init_begin[], __init_end[], __bss_start[];
 
@@ -61,7 +61,6 @@ static void __init init_idle_domain(void)
 {
         scheduler_init();
         set_current(idle_vcpu[0]);
-        this_cpu(curr_vcpu) = current;
         /* TODO: setup_idle_pagetable(); */
 }
 
@@ -175,7 +174,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
-    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    __set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
     set_processor_id(0); /* needed early, for smp_processor_id() */
 
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 826efa5..72d4945 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -5,49 +5,54 @@
 #include <xen/percpu.h>
 #include <public/xen.h>
 
+#include <asm/percpu.h>
+
 #ifndef __ASSEMBLY__
 
 struct vcpu;
 
+/*
+ * Which VCPU is "current" on this PCPU.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
 struct cpu_info {
     struct cpu_user_regs guest_cpu_user_regs;
     unsigned long elr;
+    /* The following are valid iff this VCPU is current */
     unsigned int processor_id;
-    struct vcpu *current_vcpu;
     unsigned long per_cpu_offset;
+    unsigned int pad;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
 {
-        register unsigned long sp asm ("sp");
-        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+    register unsigned long sp asm ("sp");
+    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
 }
 
-#define get_current()         (get_cpu_info()->current_vcpu)
-#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
-#define current               (get_current())
-
 #define get_processor_id()    (get_cpu_info()->processor_id)
 #define set_processor_id(id)  do {                                      \
     struct cpu_info *ci__ = get_cpu_info();                             \
     ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
 } while (0)
 
+#define get_current()         (this_cpu(curr_vcpu))
+#define __set_current(vcpu)   (this_cpu(curr_vcpu) = (vcpu))
+#define set_current(vcpu)     do {                                      \
+    vcpu->arch.cpu_info->processor_id = get_processor_id();             \
+    __set_current(vcpu);                                                \
+} while (0)
+#define current               (get_current())
+
 #define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
 
 #define reset_stack_and_jump(__fn)              \
     __asm__ __volatile__ (                      \
         "mov sp,%0; b "STR(__fn)      \
         : : "r" (guest_cpu_user_regs()) : "memory" )
-#endif
-
 
-/*
- * Which VCPU's state is currently running on each CPU?
- * This is not necesasrily the same as 'current' as a CPU may be
- * executing a lazy state switch.
- */
-DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+#endif
 
 #endif /* __ARM_CURRENT_H__ */
 /*
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..c1afd19 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -47,7 +47,26 @@ struct arch_domain
 
 struct arch_vcpu
 {
-    struct cpu_user_regs user_regs;
+    struct {
+        uint32_t    r4;
+        uint32_t    r5;
+        uint32_t    r6;
+        uint32_t    r7;
+        uint32_t    r8;
+        uint32_t    r9;
+        uint32_t    sl;
+        uint32_t    fp;
+        uint32_t    sp;
+        uint32_t    pc;
+    } saved_context;
+
+    void *stack;
+
+    /*
+     * Points into ->stack, more convenient than doing pointer arith
+     * all the time.
+     */
+    struct cpu_info *cpu_info;
 
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index ee095bf..54f6ed8 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -28,9 +28,7 @@
     (diff == 0);                                                              \
 })
 
-#define return_reg(v) ((v)->arch.user_regs.r0)
-
-#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+#define return_reg(v) ((v)->arch.cpu_info->guest_cpu_user_regs.r0)
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 731d89f..7963ea5 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -191,6 +191,8 @@ static inline int local_fiq_is_enabled(void)
     return !!(flags & PSR_FIQ_MASK);
 }
 
+extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
+
 #endif
 /*
  * Local variables:
-- 
1.7.2.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:44:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUTA-0004NA-0h; Mon, 20 Feb 2012 14:44: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 1RzUT8-0004N3-Tz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:43:59 +0000
Received: from [85.158.139.83:10691] by server-11.bemta-5.messagelabs.com id
	08/85-14397-E2C524F4; Mon, 20 Feb 2012 14:43:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329749037!15833943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25574 invoked from network); 20 Feb 2012 14:43:57 -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;
	20 Feb 2012 14:43:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10814446"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 14:43:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 14:43:57 +0000
Message-ID: <1329749035.3990.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 20 Feb 2012 14:43:55 +0000
In-Reply-To: <20120219093105.GA30637@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
	<20120219093105.GA30637@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH v2] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We do not do any lazy state switching. Outside of context_switch() the current
stack is always that of the VCPU which current returns.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/asm-offsets.c    |    4 ++
 xen/arch/arm/domain.c         |  113 ++++++++++++----------------------------
 xen/arch/arm/domain_build.c   |    3 +-
 xen/arch/arm/entry.S          |   16 ++++++
 xen/arch/arm/setup.c          |    5 +-
 xen/include/asm-arm/current.h |   35 +++++++------
 xen/include/asm-arm/domain.h  |   21 +++++++-
 xen/include/asm-arm/regs.h    |    4 +-
 xen/include/asm-arm/system.h  |    2 +
 9 files changed, 101 insertions(+), 102 deletions(-)

diff --git a/xen/arch/arm/asm-offsets.c b/xen/arch/arm/asm-offsets.c
index ee5d5d4..cc1a72a 100644
--- a/xen/arch/arm/asm-offsets.c
+++ b/xen/arch/arm/asm-offsets.c
@@ -7,6 +7,7 @@
 
 #include <xen/config.h>
 #include <xen/types.h>
+#include <xen/sched.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -65,7 +66,10 @@ void __dummy__(void)
    BLANK();
 
    DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
 }
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..a0b9d38 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -44,7 +44,7 @@ void idle_loop(void)
 
 static void ctxt_switch_from(struct vcpu *p)
 {
-
+    context_saved(p);
 }
 
 static void ctxt_switch_to(struct vcpu *n)
@@ -52,52 +52,36 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
 }
 
-static void __context_switch(void)
+static void schedule_tail(struct vcpu *prev)
 {
-    struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
-    unsigned int          cpu = smp_processor_id();
-    struct vcpu          *p = per_cpu(curr_vcpu, cpu);
-    struct vcpu          *n = current;
-
-    ASSERT(p != n);
-    ASSERT(cpumask_empty(n->vcpu_dirty_cpumask));
-
-    if ( !is_idle_vcpu(p) )
-    {
-        memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_from(p);
-    }
+    /* Re-enable interrupts before restoring state which may fault. */
+    local_irq_enable();
 
-    if ( !is_idle_vcpu(n) )
-    {
-        memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
-        ctxt_switch_to(n);
-    }
-
-    per_cpu(curr_vcpu, cpu) = n;
+    ctxt_switch_from(prev);
 
+    /* TODO
+       update_runstate_area(current);
+    */
+    ctxt_switch_to(current);
 }
 
-static void schedule_tail(struct vcpu *v)
+static void continue_new_vcpu(struct vcpu *prev)
 {
-    if ( is_idle_vcpu(v) )
-        continue_idle_domain(v);
+    schedule_tail(prev);
+
+    if ( is_idle_vcpu(current) )
+        continue_idle_domain(current);
     else
-        continue_nonidle_domain(v);
+        continue_nonidle_domain(current);
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
-    unsigned int cpu = smp_processor_id();
-
     ASSERT(local_irq_is_enabled());
-
-    printk("context switch %d:%d%s -> %d:%d%s\n",
-           prev->domain->domain_id, prev->vcpu_id, is_idle_vcpu(prev) ? " (idle)" : "",
-           next->domain->domain_id, next->vcpu_id, is_idle_vcpu(next) ? " (idle)" : "");
+    ASSERT(prev != next);
+    ASSERT(cpumask_empty(next->vcpu_dirty_cpumask));
 
     /* TODO
-       if (prev != next)
        update_runstate_area(prev);
     */
 
@@ -105,60 +89,19 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
     set_current(next);
 
-    if ( (per_cpu(curr_vcpu, cpu) == next) ||
-         (is_idle_vcpu(next) && cpu_online(cpu)) )
-    {
-        local_irq_enable();
-    }
-    else
-    {
-        __context_switch();
-
-        /* Re-enable interrupts before restoring state which may fault. */
-        local_irq_enable();
-    }
-
-    context_saved(prev);
-
-    /* TODO
-       if (prev != next)
-       update_runstate_area(next);
-    */
-
-    schedule_tail(next);
-    BUG();
+    prev = __context_switch(prev, next);
 
+    schedule_tail(prev);
 }
 
 void continue_running(struct vcpu *same)
 {
-    schedule_tail(same);
-    BUG();
-}
-
-int __sync_local_execstate(void)
-{
-    unsigned long flags;
-    int switch_required;
-
-    local_irq_save(flags);
-
-    switch_required = (this_cpu(curr_vcpu) != current);
-
-    if ( switch_required )
-    {
-        ASSERT(current == idle_vcpu[smp_processor_id()]);
-        __context_switch();
-    }
-
-    local_irq_restore(flags);
-
-    return switch_required;
+    /* Nothing to do */
 }
 
 void sync_local_execstate(void)
 {
-    (void)__sync_local_execstate();
+    /* Nothing to do -- no lazy switching */
 }
 
 void startup_cpu_idle_loop(void)
@@ -213,6 +156,18 @@ int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
 
+    v->arch.stack = alloc_xenheap_pages(STACK_ORDER, MEMF_node(vcpu_to_node(v)));
+    if ( v->arch.stack == NULL )
+        return -ENOMEM;
+
+    v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
+                                           + STACK_SIZE
+                                           - sizeof(struct cpu_info));
+
+    memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
+    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+
     if ( (rc = vcpu_vgic_init(v)) != 0 )
         return rc;
 
@@ -224,7 +179,7 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-
+    free_xenheap_pages(v->arch.stack, STACK_ORDER);
 }
 
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..9240209 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -5,6 +5,7 @@
 #include <xen/domain_page.h>
 #include <xen/sched.h>
 #include <asm/irq.h>
+#include <asm/regs.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -71,7 +72,7 @@ int construct_dom0(struct domain *d)
     int rc;
 
     struct vcpu *v = d->vcpu[0];
-    struct cpu_user_regs *regs = &v->arch.user_regs;
+    struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
     /* Sanity! */
     BUG_ON(d->domain_id != 0);
diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 16a8f36..0b9cce5 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -105,3 +105,19 @@ ENTRY(return_to_hypervisor)
 	pop {r0-r12}
 	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
 	eret
+
+/*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * r0 - prev
+ * r1 - next
+ *
+ * Returns prev in r0
+ */
+ENTRY(__context_switch)
+	add	ip, r0, #VCPU_arch_saved_context
+	stmia	ip!, {r4 - sl, fp, sp, lr}	/* Save register state */
+
+	add	r4, r1, #VCPU_arch_saved_context
+	ldmia	r4, {r4 - sl, fp, sp, pc}	/* Load registers and return */
+
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4c1d89ce..4c0244c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -42,7 +42,7 @@
 static unsigned int __initdata max_cpus = NR_CPUS;
 
 /* Xen stack for bringing up the first CPU. */
-unsigned char init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
+unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
 extern char __init_begin[], __init_end[], __bss_start[];
 
@@ -61,7 +61,6 @@ static void __init init_idle_domain(void)
 {
         scheduler_init();
         set_current(idle_vcpu[0]);
-        this_cpu(curr_vcpu) = current;
         /* TODO: setup_idle_pagetable(); */
 }
 
@@ -175,7 +174,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
-    set_current((struct vcpu *)0xfffff000); /* debug sanity */
+    __set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
     set_processor_id(0); /* needed early, for smp_processor_id() */
 
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 826efa5..72d4945 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -5,49 +5,54 @@
 #include <xen/percpu.h>
 #include <public/xen.h>
 
+#include <asm/percpu.h>
+
 #ifndef __ASSEMBLY__
 
 struct vcpu;
 
+/*
+ * Which VCPU is "current" on this PCPU.
+ */
+DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+
 struct cpu_info {
     struct cpu_user_regs guest_cpu_user_regs;
     unsigned long elr;
+    /* The following are valid iff this VCPU is current */
     unsigned int processor_id;
-    struct vcpu *current_vcpu;
     unsigned long per_cpu_offset;
+    unsigned int pad;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
 {
-        register unsigned long sp asm ("sp");
-        return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+    register unsigned long sp asm ("sp");
+    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
 }
 
-#define get_current()         (get_cpu_info()->current_vcpu)
-#define set_current(vcpu)     (get_cpu_info()->current_vcpu = (vcpu))
-#define current               (get_current())
-
 #define get_processor_id()    (get_cpu_info()->processor_id)
 #define set_processor_id(id)  do {                                      \
     struct cpu_info *ci__ = get_cpu_info();                             \
     ci__->per_cpu_offset = __per_cpu_offset[ci__->processor_id = (id)]; \
 } while (0)
 
+#define get_current()         (this_cpu(curr_vcpu))
+#define __set_current(vcpu)   (this_cpu(curr_vcpu) = (vcpu))
+#define set_current(vcpu)     do {                                      \
+    vcpu->arch.cpu_info->processor_id = get_processor_id();             \
+    __set_current(vcpu);                                                \
+} while (0)
+#define current               (get_current())
+
 #define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
 
 #define reset_stack_and_jump(__fn)              \
     __asm__ __volatile__ (                      \
         "mov sp,%0; b "STR(__fn)      \
         : : "r" (guest_cpu_user_regs()) : "memory" )
-#endif
-
 
-/*
- * Which VCPU's state is currently running on each CPU?
- * This is not necesasrily the same as 'current' as a CPU may be
- * executing a lazy state switch.
- */
-DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
+#endif
 
 #endif /* __ARM_CURRENT_H__ */
 /*
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..c1afd19 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -47,7 +47,26 @@ struct arch_domain
 
 struct arch_vcpu
 {
-    struct cpu_user_regs user_regs;
+    struct {
+        uint32_t    r4;
+        uint32_t    r5;
+        uint32_t    r6;
+        uint32_t    r7;
+        uint32_t    r8;
+        uint32_t    r9;
+        uint32_t    sl;
+        uint32_t    fp;
+        uint32_t    sp;
+        uint32_t    pc;
+    } saved_context;
+
+    void *stack;
+
+    /*
+     * Points into ->stack, more convenient than doing pointer arith
+     * all the time.
+     */
+    struct cpu_info *cpu_info;
 
     uint32_t sctlr;
     uint32_t ttbr0, ttbr1, ttbcr;
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index ee095bf..54f6ed8 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -28,9 +28,7 @@
     (diff == 0);                                                              \
 })
 
-#define return_reg(v) ((v)->arch.user_regs.r0)
-
-#define CTXT_SWITCH_STACK_BYTES (sizeof(struct cpu_user_regs))
+#define return_reg(v) ((v)->arch.cpu_info->guest_cpu_user_regs.r0)
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 731d89f..7963ea5 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -191,6 +191,8 @@ static inline int local_fiq_is_enabled(void)
     return !!(flags & PSR_FIQ_MASK);
 }
 
+extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
+
 #endif
 /*
  * Local variables:
-- 
1.7.2.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:49:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUXi-0004ag-NO; Mon, 20 Feb 2012 14:48:42 +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 1RzUXh-0004aa-Jj
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:48:41 +0000
Received: from [85.158.139.83:43491] by server-1.bemta-5.messagelabs.com id
	B0/EA-28458-84D524F4; Mon, 20 Feb 2012 14:48:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329749319!15817786!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7540 invoked from network); 20 Feb 2012 14:48:40 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 14:48:40 -0000
Received: by yenm7 with SMTP id m7so76656392yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 06:48:39 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.11.200 as permitted sender) client-ip=10.50.11.200; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.11.200 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.11.200])
	by 10.50.11.200 with SMTP id s8mr13137192igb.10.1329749319003 (num_hops
	= 1); Mon, 20 Feb 2012 06:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=3Poq3dXJbFU6sS4d0HMNaEei8FUr/JspLYZbWPfvhBc=;
	b=Z9ZxdzZd4Mky/if106o64qweEUfajb7qf2so4vepV9AO4rfydAbW2bVfu/9+p5srgD
	RvTQ5B6+S0alSLdUzFcu6yR7KuMEurbc8AfS1mhZYHijS1nIHvZwkVwCgZZe+9zVoYaM
	91PasWEkXiSWks127wRZIAvERfWgsDm4Vfj5c=
MIME-Version: 1.0
Received: by 10.50.11.200 with SMTP id s8mr10658320igb.10.1329749318784; Mon,
	20 Feb 2012 06:48:38 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Mon, 20 Feb 2012 06:48:38 -0800 (PST)
In-Reply-To: <20120220111230.GA5856@aepfle.de>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
Date: Mon, 20 Feb 2012 14:48:38 +0000
X-Google-Sender-Auth: NW10y2e9PM9odoqxzSe8xhfe8Pw
Message-ID: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 11:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Feb 20, George Dunlap wrote:
>
>> Start-of-day:
>> =A0xenpaging off: Set balloon target to M, use PoD
>> =A0xenpaging on: ??
>> =A0xenpaging delay: Set balloon target to M, use PoD. =A0Wait
>> $pagingdelayboot seconds, if target not reached, set paging?
>
> Is the delay required?
> If paging and PoD target is M, xenpaging will do nothing because the
> guest can not exceed M (it will crash with OOM).

Ah, of course -- you don't need paging because it already has M
memory.  Forgot about that.

It would be nice, of course, if the pager could act as a back-fill for
these PoD pages; but that's another project, I think.

So that leaves us with:

maxmem=3DX
memory=3DM
xenpaging=3D[off|on|delay]
pagingdelay=3D60

xl mem-set domain M
 xenpaging off: Set balloon target to M
 xenpaging on: Set paging target to M
 xenpaging delay: Set balloon target to M, and wait for actual memory
to reach M.  If it hasn't reached it by $paging_delay seconds, set
balloon target to M.

xl mem-balloon-set domain M
 Set balloon target to M
xl mem-paging-set domain M
 Set paging target to M

Start-of-day:
 xenpaging off/delay: Set balloon target to M, use PoD
 xenpaging on: ??

Olaf, what do you do right now for booting a guest in paging mode with
memory < maxmem?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:49:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUXi-0004ag-NO; Mon, 20 Feb 2012 14:48:42 +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 1RzUXh-0004aa-Jj
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:48:41 +0000
Received: from [85.158.139.83:43491] by server-1.bemta-5.messagelabs.com id
	B0/EA-28458-84D524F4; Mon, 20 Feb 2012 14:48:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329749319!15817786!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7540 invoked from network); 20 Feb 2012 14:48:40 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 14:48:40 -0000
Received: by yenm7 with SMTP id m7so76656392yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 06:48:39 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.11.200 as permitted sender) client-ip=10.50.11.200; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.11.200 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.11.200])
	by 10.50.11.200 with SMTP id s8mr13137192igb.10.1329749319003 (num_hops
	= 1); Mon, 20 Feb 2012 06:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=3Poq3dXJbFU6sS4d0HMNaEei8FUr/JspLYZbWPfvhBc=;
	b=Z9ZxdzZd4Mky/if106o64qweEUfajb7qf2so4vepV9AO4rfydAbW2bVfu/9+p5srgD
	RvTQ5B6+S0alSLdUzFcu6yR7KuMEurbc8AfS1mhZYHijS1nIHvZwkVwCgZZe+9zVoYaM
	91PasWEkXiSWks127wRZIAvERfWgsDm4Vfj5c=
MIME-Version: 1.0
Received: by 10.50.11.200 with SMTP id s8mr10658320igb.10.1329749318784; Mon,
	20 Feb 2012 06:48:38 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Mon, 20 Feb 2012 06:48:38 -0800 (PST)
In-Reply-To: <20120220111230.GA5856@aepfle.de>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
Date: Mon, 20 Feb 2012 14:48:38 +0000
X-Google-Sender-Auth: NW10y2e9PM9odoqxzSe8xhfe8Pw
Message-ID: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 11:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Feb 20, George Dunlap wrote:
>
>> Start-of-day:
>> =A0xenpaging off: Set balloon target to M, use PoD
>> =A0xenpaging on: ??
>> =A0xenpaging delay: Set balloon target to M, use PoD. =A0Wait
>> $pagingdelayboot seconds, if target not reached, set paging?
>
> Is the delay required?
> If paging and PoD target is M, xenpaging will do nothing because the
> guest can not exceed M (it will crash with OOM).

Ah, of course -- you don't need paging because it already has M
memory.  Forgot about that.

It would be nice, of course, if the pager could act as a back-fill for
these PoD pages; but that's another project, I think.

So that leaves us with:

maxmem=3DX
memory=3DM
xenpaging=3D[off|on|delay]
pagingdelay=3D60

xl mem-set domain M
 xenpaging off: Set balloon target to M
 xenpaging on: Set paging target to M
 xenpaging delay: Set balloon target to M, and wait for actual memory
to reach M.  If it hasn't reached it by $paging_delay seconds, set
balloon target to M.

xl mem-balloon-set domain M
 Set balloon target to M
xl mem-paging-set domain M
 Set paging target to M

Start-of-day:
 xenpaging off/delay: Set balloon target to M, use PoD
 xenpaging on: ??

Olaf, what do you do right now for booting a guest in paging mode with
memory < maxmem?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:54:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUct-0004lv-FY; Mon, 20 Feb 2012 14:54:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1RzUcr-0004le-ET
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:54:01 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329749634!15441911!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjk0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29614 invoked from network); 20 Feb 2012 14:53:54 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Feb 2012 14:53:54 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Feb 2012 06:53:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127416793"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 20 Feb 2012 06:53:52 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 20 Feb 2012 22:53:51 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 20 Feb 2012 22:53:51 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Mon, 20 Feb 2012 22:53:50 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: ANNIE LI <annie.li@oracle.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
	due	to tm->tm_year
Thread-Index: AQHM76BceJnnxrXchU2GFUXuAGsOvJZF3yDw
Date: Mon, 20 Feb 2012 14:53:49 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
References: <4F41F41F.9060601@oracle.com>
In-Reply-To: <4F41F41F.9060601@oracle.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: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due	to tm->tm_year
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of ANNIE LI
> Sent: Monday, February 20, 2012 3:20 PM
> 
> Hi
> 
> In rtc_set_time, mktime is called to calculate seconds since 1970/01/01, input
> parameters of mktime are required to be in normal date format.
> Such as: year=1980, mon=12, day=31, hour=23, min=59, sec=59. However, the
> current input parameter of mktime is tm->tm_year, and it is the number of years
> since 1900. (For example, if current time is 2012/12/31, and tm->tm_year is 112).
> This is not suitable for requirement of mktime.
> So I think tm->tm_year should be changed to tm->tm_year+1900 when calling
> mktime. Please check the patch attached.
> 
No, tm_year is the number of years since 1900, not the normal date format.

best regards
yang
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:54:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUct-0004lv-FY; Mon, 20 Feb 2012 14:54:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1RzUcr-0004le-ET
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:54:01 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329749634!15441911!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjk0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29614 invoked from network); 20 Feb 2012 14:53:54 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-216.messagelabs.com with SMTP;
	20 Feb 2012 14:53:54 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Feb 2012 06:53:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="127416793"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 20 Feb 2012 06:53:52 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 20 Feb 2012 22:53:51 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 20 Feb 2012 22:53:51 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Mon, 20 Feb 2012 22:53:50 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: ANNIE LI <annie.li@oracle.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
	due	to tm->tm_year
Thread-Index: AQHM76BceJnnxrXchU2GFUXuAGsOvJZF3yDw
Date: Mon, 20 Feb 2012 14:53:49 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
References: <4F41F41F.9060601@oracle.com>
In-Reply-To: <4F41F41F.9060601@oracle.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: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due	to tm->tm_year
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of ANNIE LI
> Sent: Monday, February 20, 2012 3:20 PM
> 
> Hi
> 
> In rtc_set_time, mktime is called to calculate seconds since 1970/01/01, input
> parameters of mktime are required to be in normal date format.
> Such as: year=1980, mon=12, day=31, hour=23, min=59, sec=59. However, the
> current input parameter of mktime is tm->tm_year, and it is the number of years
> since 1900. (For example, if current time is 2012/12/31, and tm->tm_year is 112).
> This is not suitable for requirement of mktime.
> So I think tm->tm_year should be changed to tm->tm_year+1900 when calling
> mktime. Please check the patch attached.
> 
No, tm_year is the number of years since 1900, not the normal date format.

best regards
yang
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:58:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14: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.xensource.com>)
	id 1RzUhG-0004wl-Cz; Mon, 20 Feb 2012 14:58:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RzUhF-0004we-BB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:58:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329749906!4890043!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23610 invoked from network); 20 Feb 2012 14:58:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2012 14:58:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RzUh8-000KLv-LJ; Mon, 20 Feb 2012 14:58:26 +0000
Date: Mon, 20 Feb 2012 14:58:26 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120220145826.GA78217@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
	<20120219093105.GA30637@ocelot.phlegethon.org>
	<1329749035.3990.49.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329749035.3990.49.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:43 +0000 on 20 Feb (1329749035), Ian Campbell wrote:
> We do not do any lazy state switching. Outside of context_switch() the current
> stack is always that of the VCPU which current returns.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Tim Deegan <tim@xen.org>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 14:58:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 14: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.xensource.com>)
	id 1RzUhG-0004wl-Cz; Mon, 20 Feb 2012 14:58:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RzUhF-0004we-BB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 14:58:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329749906!4890043!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23610 invoked from network); 20 Feb 2012 14:58:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2012 14:58:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RzUh8-000KLv-LJ; Mon, 20 Feb 2012 14:58:26 +0000
Date: Mon, 20 Feb 2012 14:58:26 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120220145826.GA78217@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
	<20120219093105.GA30637@ocelot.phlegethon.org>
	<1329749035.3990.49.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329749035.3990.49.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:43 +0000 on 20 Feb (1329749035), Ian Campbell wrote:
> We do not do any lazy state switching. Outside of context_switch() the current
> stack is always that of the VCPU which current returns.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Tim Deegan <tim@xen.org>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:05:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUnA-00059T-7C; Mon, 20 Feb 2012 15:04:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <young.zhang.free@gmail.com>) id 1RzUn8-00059O-Vf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:04:39 +0000
X-Env-Sender: young.zhang.free@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329750270!14140111!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7842 invoked from network); 20 Feb 2012 15:04:32 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:04:32 -0000
Received: by damc16 with SMTP id c16so43500636dam.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 07:04:29 -0800 (PST)
Received-SPF: pass (google.com: domain of young.zhang.free@gmail.com
	designates 10.68.129.137 as permitted sender)
	client-ip=10.68.129.137; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	young.zhang.free@gmail.com designates 10.68.129.137 as
	permitted sender) smtp.mail=young.zhang.free@gmail.com;
	dkim=pass header.i=young.zhang.free@gmail.com
Received: from mr.google.com ([10.68.129.137])
	by 10.68.129.137 with SMTP id nw9mr4382910pbb.73.1329750269417
	(num_hops = 1); Mon, 20 Feb 2012 07:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=MZyAoE0jCdtaBLNQoA46JrhydxOWbFuADzLtqDK1r84=;
	b=r0LDjgro1iFPIL07WLt+I4D1lPU8MdLU2Qdb26Y3TP7cXG1beLbaHav6gS/5WPn6FY
	g4ipDGRsPATb/SpOjz23i1tuxvHOeqvRiFXGybqd5nWbbqHghzzA/XIB8aX8rV6oxI6X
	f7nYAPzUO+wqjEGO103+tEWs8q4FWOq+iSnIY=
MIME-Version: 1.0
Received: by 10.68.129.137 with SMTP id nw9mr3709096pbb.73.1329750269355; Mon,
	20 Feb 2012 07:04:29 -0800 (PST)
Received: by 10.68.229.168 with HTTP; Mon, 20 Feb 2012 07:04:29 -0800 (PST)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
Date: Mon, 20 Feb 2012 23:04:29 +0800
Message-ID: <CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
From: young zhang <young.zhang.free@gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The mktime which used in xen is different from standard C. I think the
best way is change it same as normal mktime, or else, other people
will make the same mistake too.

2012/2/20, Zhang, Yang Z <yang.z.zhang@intel.com>:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of ANNIE LI
>> Sent: Monday, February 20, 2012 3:20 PM
>>
>> Hi
>>
>> In rtc_set_time, mktime is called to calculate seconds since 1970/01/01,
>> input
>> parameters of mktime are required to be in normal date format.
>> Such as: year=1980, mon=12, day=31, hour=23, min=59, sec=59. However, the
>> current input parameter of mktime is tm->tm_year, and it is the number of
>> years
>> since 1900. (For example, if current time is 2012/12/31, and tm->tm_year
>> is 112).
>> This is not suitable for requirement of mktime.
>> So I think tm->tm_year should be changed to tm->tm_year+1900 when calling
>> mktime. Please check the patch attached.
>>
> No, tm_year is the number of years since 1900, not the normal date format.
>
> best regards
> yang
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:05:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUnA-00059T-7C; Mon, 20 Feb 2012 15:04:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <young.zhang.free@gmail.com>) id 1RzUn8-00059O-Vf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:04:39 +0000
X-Env-Sender: young.zhang.free@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329750270!14140111!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7842 invoked from network); 20 Feb 2012 15:04:32 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:04:32 -0000
Received: by damc16 with SMTP id c16so43500636dam.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 07:04:29 -0800 (PST)
Received-SPF: pass (google.com: domain of young.zhang.free@gmail.com
	designates 10.68.129.137 as permitted sender)
	client-ip=10.68.129.137; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	young.zhang.free@gmail.com designates 10.68.129.137 as
	permitted sender) smtp.mail=young.zhang.free@gmail.com;
	dkim=pass header.i=young.zhang.free@gmail.com
Received: from mr.google.com ([10.68.129.137])
	by 10.68.129.137 with SMTP id nw9mr4382910pbb.73.1329750269417
	(num_hops = 1); Mon, 20 Feb 2012 07:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=MZyAoE0jCdtaBLNQoA46JrhydxOWbFuADzLtqDK1r84=;
	b=r0LDjgro1iFPIL07WLt+I4D1lPU8MdLU2Qdb26Y3TP7cXG1beLbaHav6gS/5WPn6FY
	g4ipDGRsPATb/SpOjz23i1tuxvHOeqvRiFXGybqd5nWbbqHghzzA/XIB8aX8rV6oxI6X
	f7nYAPzUO+wqjEGO103+tEWs8q4FWOq+iSnIY=
MIME-Version: 1.0
Received: by 10.68.129.137 with SMTP id nw9mr3709096pbb.73.1329750269355; Mon,
	20 Feb 2012 07:04:29 -0800 (PST)
Received: by 10.68.229.168 with HTTP; Mon, 20 Feb 2012 07:04:29 -0800 (PST)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
Date: Mon, 20 Feb 2012 23:04:29 +0800
Message-ID: <CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
From: young zhang <young.zhang.free@gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The mktime which used in xen is different from standard C. I think the
best way is change it same as normal mktime, or else, other people
will make the same mistake too.

2012/2/20, Zhang, Yang Z <yang.z.zhang@intel.com>:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of ANNIE LI
>> Sent: Monday, February 20, 2012 3:20 PM
>>
>> Hi
>>
>> In rtc_set_time, mktime is called to calculate seconds since 1970/01/01,
>> input
>> parameters of mktime are required to be in normal date format.
>> Such as: year=1980, mon=12, day=31, hour=23, min=59, sec=59. However, the
>> current input parameter of mktime is tm->tm_year, and it is the number of
>> years
>> since 1900. (For example, if current time is 2012/12/31, and tm->tm_year
>> is 112).
>> This is not suitable for requirement of mktime.
>> So I think tm->tm_year should be changed to tm->tm_year+1900 when calling
>> mktime. Please check the patch attached.
>>
> No, tm_year is the number of years since 1900, not the normal date format.
>
> best regards
> yang
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUs0-0005IZ-0G; Mon, 20 Feb 2012 15:09:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzUry-0005IN-Br
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:09:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329750572!15618301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20484 invoked from network); 20 Feb 2012 15:09:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:09:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10815268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 15:09:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 15:09:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzUrq-0003SC-Ph;
	Mon, 20 Feb 2012 15:09:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzUrq-0005Ep-PC;
	Mon, 20 Feb 2012 15:09:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11983-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 15:09:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11983: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11983 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11983/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11891
 build-i386                    2 host-install(2)         broken REGR. vs. 11891
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11891
 build-amd64                   2 host-install(2)         broken REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-i386-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  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-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-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-amd64-xl           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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:10:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzUs0-0005IZ-0G; Mon, 20 Feb 2012 15:09:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzUry-0005IN-Br
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:09:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329750572!15618301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20484 invoked from network); 20 Feb 2012 15:09:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:09:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10815268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 15:09:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 15:09:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzUrq-0003SC-Ph;
	Mon, 20 Feb 2012 15:09:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzUrq-0005Ep-PC;
	Mon, 20 Feb 2012 15:09:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11983-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 15:09:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11983: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11983 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11983/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11891
 build-i386                    2 host-install(2)         broken REGR. vs. 11891
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11891
 build-amd64                   2 host-install(2)         broken REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-i386-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  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-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-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-amd64-xl           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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:11:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15: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.xensource.com>)
	id 1RzUtA-0005N0-Fb; Mon, 20 Feb 2012 15:10:52 +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 1RzUt8-0005Mt-VB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:10:51 +0000
Received: from [85.158.139.83:49912] by server-1.bemta-5.messagelabs.com id
	D0/6D-28458-A72624F4; Mon, 20 Feb 2012 15:10:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329750647!15197786!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3663 invoked from network); 20 Feb 2012 15:10:48 -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; 20 Feb 2012 15:10:48 -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 q1KFAiuT006059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:10: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
	q1KFAih9003556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 15:10:44 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
	q1KFAhp3003348; Mon, 20 Feb 2012 09:10:43 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 07:10:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AFD6740334; Mon, 20 Feb 2012 10:07:30 -0500 (EST)
Date: Mon, 20 Feb 2012 10:07:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul S <pstroud@gmail.com>, JBeulich@suse.com
Message-ID: <20120220150730.GC22593@phenom.dumpdata.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
	<CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
	<CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F426275.00B1,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 08:11:01AM -0500, Paul S wrote:
> So, the problem has something to do with grub2-efi. After installing
> XenServer the second time, I noticed that it did not create an EFI Boot
> partition. To that end, I booted the Fedora CD in normal mode, instead of
> UEFI mode, created a boot bios, and once installed that way, I was able to
> run 4.1.2. So, I'm not sure if the problem lies in grub or xen, or the
> combination of the two, but that is where the problem exists.


Oooh, Jan, had you seen this in the past by any chance? Presumarily
using the Xen EFI instead of the GRUB-EFI would solve this problem?

> 
> On Fri, Feb 17, 2012 at 4:31 PM, Paul S <pstroud@gmail.com> wrote:
> 
> > File attached.
> >
> >
> > On Fri, Feb 17, 2012 at 4:14 PM, Paul S <pstroud@gmail.com> wrote:
> >
> >> Andrew,
> >> Thanks for the quick response! I was finally able to capture it and get a
> >> bit more information. The problem does not always happen, even on 4.1.2, I
> >> was able to get it to boot a few times, though I was never able to get
> >> 4.2-unstable to boot. There was lots of strangeness, such as after I built
> >> and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
> >> working.
> >>
> >> That being said, I caught it on video, and captured a picture of the
> >> final dump. I watched the video frame by frame and the boot actually got
> >> much further than I thought it was.
> >>
> >> I can see that even though it does not bring up two of the CPUs, the boot
> >> continues into the kernel and dies somewhere with a:
> >>
> >> BUG: Unable to handle paging request at FFFc7f(maybe).
> >>
> >> I have captured several images from the video that shows the progression
> >> of the boot before the crash. I think I have gotten things badly out of
> >> whack at this point, so I'm going to stop, reinstall everything and move
> >> back to 4.1.1 and see if I can get things working again.
> >>
> >> Let me know if anything in the pictures helps, or if you would like the
> >> video as well.
> >>
> >> Paul
> >>
> >> On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper <
> >> andrew.cooper3@citrix.com> wrote:
> >>
> >>> On 17/02/12 16:21, Paul S wrote:
> >>> > Environment:
> >>> > ASRock Z86 Extreme4 - Intel i5 2500
> >>> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
> >>> >
> >>> > I have installed the latest UEFI patch(1.70) and all tests were run
> >>> > from a reset of everything to default. I have tested with both Ubuntu
> >>> > 11.10 and Fedora 16 and get the same results on both, including
> >>> > building xen 4.2-unstable. I bought this particular MB because it had
> >>> > a know working vt-d implementation via VMWare.
> >>> >
> >>> > NOTE: current unstable as of last night is still affected by this
> >>> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
> >>> >
> >>> > However, after correcting the library error, I was able to complete
> >>> > the unstable build.
> >>> >
> >>> > In both cases, it either stops with a panic/blank screen, or just
> >>> reboots.
> >>> >
> >>> > Here are some other notes:
> >>> >
> >>> > 1) If x2apic is enabled on the motherboard, it almost immediately
> >>> > reboots with any of the configurations above
> >>>
> >>> There are some fairly strict set of requirements on what which MSRs you
> >>> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
> >>> early in boot which results in a protection fault.
> >>>
> >>> >
> >>> > 2) The boot gets to here:
> >>> >
> >>> > (XEN) HVM: VMX enabled
> >>> >
> >>> > (XEN) HVM: Hardware Assisted Paging detected.
> >>> >
> >>> >
> >>> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
> >>> > where it hangs with the blank/panic screen or reboots. This sometimes
> >>> > shows up on CPU 1, CPU2, or both.
> >>> >
> >>> >
> >>> > 3) There is no boot log written and the machine does not have a native
> >>> > serial port, so capturing anything may prove difficult, but I am open
> >>> > to suggestions.
> >>> >
> >>>
> >>> Try booting with noreboot - that should keep any panic message on screen
> >>> until you manually choose to reset the machine.  Seeing where in the
> >>> panic occurs would be very helpful, even if you just transcribe a few
> >>> lines manually.
> >>>
> >>> >
> >>> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
> >>> > is enabled, then it simply panics and reboots.
> >>> >
> >>> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
> >>> > being enabled, but I did check it with VT-d enabled and the boot
> >>> > looked the same. I can capture it again if needed.
> >>> >
> >>> >
> >>> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
> >>> > enabled(which shows working in xl) and x2apic enabled.
> >>> >
> >>> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
> >>> > includes logs both with and without VT-d and x2apic enabled. I did not
> >>> > actually create any VMs, only booted this and checked what xl reported.
> >>> >
> >>> >
> >>>
> >>> That is rather interesting - I am not aware of any XenServer specific
> >>> changes in this regard.
> >>>
> >>> > If there is anything else I can add, please let me know. I am going to
> >>> > download 4.1.1 now, build it and see if it works, because it does on
> >>> > Xen Server. I am open to testing anything as this is an original build
> >>> > on this box, so I'm willing to knock it around if it will help.
> >>> >
> >>> > #
> >>> >
> >>>
> >>> Knowing whether upstream 4.1.1 works will be very useful in workout out
> >>> whether it is a regression introduced into unstable, or whether there is
> >>> some XenServer specific change which we should upstream.
> >>>
> >>> > Thanks,
> >>> >
> >>> > Paul
> >>> >
> >>>
> >>> --
> >>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> >>> T: +44 (0)1223 225 900, http://www.citrix.com
> >>>
> >>>
> >>
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:11:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15: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.xensource.com>)
	id 1RzUtA-0005N0-Fb; Mon, 20 Feb 2012 15:10:52 +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 1RzUt8-0005Mt-VB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:10:51 +0000
Received: from [85.158.139.83:49912] by server-1.bemta-5.messagelabs.com id
	D0/6D-28458-A72624F4; Mon, 20 Feb 2012 15:10:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329750647!15197786!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3663 invoked from network); 20 Feb 2012 15:10:48 -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; 20 Feb 2012 15:10:48 -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 q1KFAiuT006059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:10: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
	q1KFAih9003556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 15:10:44 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
	q1KFAhp3003348; Mon, 20 Feb 2012 09:10:43 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 07:10:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AFD6740334; Mon, 20 Feb 2012 10:07:30 -0500 (EST)
Date: Mon, 20 Feb 2012 10:07:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul S <pstroud@gmail.com>, JBeulich@suse.com
Message-ID: <20120220150730.GC22593@phenom.dumpdata.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
	<CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
	<CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F426275.00B1,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 08:11:01AM -0500, Paul S wrote:
> So, the problem has something to do with grub2-efi. After installing
> XenServer the second time, I noticed that it did not create an EFI Boot
> partition. To that end, I booted the Fedora CD in normal mode, instead of
> UEFI mode, created a boot bios, and once installed that way, I was able to
> run 4.1.2. So, I'm not sure if the problem lies in grub or xen, or the
> combination of the two, but that is where the problem exists.


Oooh, Jan, had you seen this in the past by any chance? Presumarily
using the Xen EFI instead of the GRUB-EFI would solve this problem?

> 
> On Fri, Feb 17, 2012 at 4:31 PM, Paul S <pstroud@gmail.com> wrote:
> 
> > File attached.
> >
> >
> > On Fri, Feb 17, 2012 at 4:14 PM, Paul S <pstroud@gmail.com> wrote:
> >
> >> Andrew,
> >> Thanks for the quick response! I was finally able to capture it and get a
> >> bit more information. The problem does not always happen, even on 4.1.2, I
> >> was able to get it to boot a few times, though I was never able to get
> >> 4.2-unstable to boot. There was lots of strangeness, such as after I built
> >> and installed 4.1.1, it worked, but then, so did 4.1.2, now neither is
> >> working.
> >>
> >> That being said, I caught it on video, and captured a picture of the
> >> final dump. I watched the video frame by frame and the boot actually got
> >> much further than I thought it was.
> >>
> >> I can see that even though it does not bring up two of the CPUs, the boot
> >> continues into the kernel and dies somewhere with a:
> >>
> >> BUG: Unable to handle paging request at FFFc7f(maybe).
> >>
> >> I have captured several images from the video that shows the progression
> >> of the boot before the crash. I think I have gotten things badly out of
> >> whack at this point, so I'm going to stop, reinstall everything and move
> >> back to 4.1.1 and see if I can get things working again.
> >>
> >> Let me know if anything in the pictures helps, or if you would like the
> >> video as well.
> >>
> >> Paul
> >>
> >> On Fri, Feb 17, 2012 at 11:39 AM, Andrew Cooper <
> >> andrew.cooper3@citrix.com> wrote:
> >>
> >>> On 17/02/12 16:21, Paul S wrote:
> >>> > Environment:
> >>> > ASRock Z86 Extreme4 - Intel i5 2500
> >>> > http://www.asrock.com/mb/overview.asp?Model=Z68%20Extreme4
> >>> >
> >>> > I have installed the latest UEFI patch(1.70) and all tests were run
> >>> > from a reset of everything to default. I have tested with both Ubuntu
> >>> > 11.10 and Fedora 16 and get the same results on both, including
> >>> > building xen 4.2-unstable. I bought this particular MB because it had
> >>> > a know working vt-d implementation via VMWare.
> >>> >
> >>> > NOTE: current unstable as of last night is still affected by this
> >>> > library error http://www.gossamer-threads.com/lists/xen/devel/234300
> >>> >
> >>> > However, after correcting the library error, I was able to complete
> >>> > the unstable build.
> >>> >
> >>> > In both cases, it either stops with a panic/blank screen, or just
> >>> reboots.
> >>> >
> >>> > Here are some other notes:
> >>> >
> >>> > 1) If x2apic is enabled on the motherboard, it almost immediately
> >>> > reboots with any of the configurations above
> >>>
> >>> There are some fairly strict set of requirements on what which MSRs you
> >>> can wrt xAPIC/x2APIC mode.  It is possible that we are tickling an MSR
> >>> early in boot which results in a protection fault.
> >>>
> >>> >
> >>> > 2) The boot gets to here:
> >>> >
> >>> > (XEN) HVM: VMX enabled
> >>> >
> >>> > (XEN) HVM: Hardware Assisted Paging detected.
> >>> >
> >>> >
> >>> > Then goes to a "(XEN)Failed to bring up CPU x(error -5)" and this is
> >>> > where it hangs with the blank/panic screen or reboots. This sometimes
> >>> > shows up on CPU 1, CPU2, or both.
> >>> >
> >>> >
> >>> > 3) There is no boot log written and the machine does not have a native
> >>> > serial port, so capturing anything may prove difficult, but I am open
> >>> > to suggestions.
> >>> >
> >>>
> >>> Try booting with noreboot - that should keep any panic message on screen
> >>> until you manually choose to reset the machine.  Seeing where in the
> >>> panic occurs would be very helpful, even if you just transcribe a few
> >>> lines manually.
> >>>
> >>> >
> >>> > 4) Xen Live(http://wiki.xen.org/wiki/LiveCD) works ok, unless x2apic
> >>> > is enabled, then it simply panics and reboots.
> >>> >
> >>> > The logs(xen_live.tgz) are attached. Note this was captured with VT-d
> >>> > being enabled, but I did check it with VT-d enabled and the boot
> >>> > looked the same. I can capture it again if needed.
> >>> >
> >>> >
> >>> > 5) Xen Server 6.0.0 works, with Xen 4.1.1, with both VT-d
> >>> > enabled(which shows working in xl) and x2apic enabled.
> >>> >
> >>> > I have also attached(xen_server_6.0.0.tar.gz) these logs, which
> >>> > includes logs both with and without VT-d and x2apic enabled. I did not
> >>> > actually create any VMs, only booted this and checked what xl reported.
> >>> >
> >>> >
> >>>
> >>> That is rather interesting - I am not aware of any XenServer specific
> >>> changes in this regard.
> >>>
> >>> > If there is anything else I can add, please let me know. I am going to
> >>> > download 4.1.1 now, build it and see if it works, because it does on
> >>> > Xen Server. I am open to testing anything as this is an original build
> >>> > on this box, so I'm willing to knock it around if it will help.
> >>> >
> >>> > #
> >>> >
> >>>
> >>> Knowing whether upstream 4.1.1 works will be very useful in workout out
> >>> whether it is a regression introduced into unstable, or whether there is
> >>> some XenServer specific change which we should upstream.
> >>>
> >>> > Thanks,
> >>> >
> >>> > Paul
> >>> >
> >>>
> >>> --
> >>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> >>> T: +44 (0)1223 225 900, http://www.citrix.com
> >>>
> >>>
> >>
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:20:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzV22-0005db-Fv; Mon, 20 Feb 2012 15:20:02 +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 1RzV20-0005dW-Ex
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:20:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329751130!61817386!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2894 invoked from network); 20 Feb 2012 15:18:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 15:18:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329751195; l=245;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=2iUfN6A/opZOhqHVRT5zwX0zxXA=;
	b=lY3rgKQmnH0h3CYdyWj0/RveW8NiSbbhntWeGAYLf0uqXXRH1iuQqMGnlVWLExLKGso
	T98gHVths0UFnjF0s8vKs8ZVaq4tvJr1Bh/wui+TbUtjzBLqB0V8XeqdAEDPyN/m5inBI
	voLB3FlYfi3yU2OO6KPTtLlvZKbV3r/vMgg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by post.strato.de (mrclete mo5) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y06328o1KEM0eC ;
	Mon, 20 Feb 2012 16:19:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 30FD718638; Mon, 20 Feb 2012 16:19:44 +0100 (CET)
Date: Mon, 20 Feb 2012 16:19:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120220151943.GA14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, George Dunlap wrote:

> Olaf, what do you do right now for booting a guest in paging mode with
> memory < maxmem?

xenpaging exits because XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE returns
-EXDEV when PoD is detected.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:20:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzV22-0005db-Fv; Mon, 20 Feb 2012 15:20:02 +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 1RzV20-0005dW-Ex
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:20:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329751130!61817386!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2894 invoked from network); 20 Feb 2012 15:18:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 15:18:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329751195; l=245;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=2iUfN6A/opZOhqHVRT5zwX0zxXA=;
	b=lY3rgKQmnH0h3CYdyWj0/RveW8NiSbbhntWeGAYLf0uqXXRH1iuQqMGnlVWLExLKGso
	T98gHVths0UFnjF0s8vKs8ZVaq4tvJr1Bh/wui+TbUtjzBLqB0V8XeqdAEDPyN/m5inBI
	voLB3FlYfi3yU2OO6KPTtLlvZKbV3r/vMgg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by post.strato.de (mrclete mo5) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y06328o1KEM0eC ;
	Mon, 20 Feb 2012 16:19:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 30FD718638; Mon, 20 Feb 2012 16:19:44 +0100 (CET)
Date: Mon, 20 Feb 2012 16:19:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120220151943.GA14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, George Dunlap wrote:

> Olaf, what do you do right now for booting a guest in paging mode with
> memory < maxmem?

xenpaging exits because XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE returns
-EXDEV when PoD is detected.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzV4A-0005lc-7S; Mon, 20 Feb 2012 15:22: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 1RzV48-0005kr-E6
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:22:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329751195!62075202!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7488 invoked from network); 20 Feb 2012 15:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325480400"; d="scan'208";a="182641106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:22:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 10:22:04 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1KFM2RT028830; Mon, 20 Feb 2012 07:22:03 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 15:22:01 +0000
Message-ID: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
	from hypervisor to hypervisor.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is necessary to handle nested traps to the hypervisor more than one deep.

I've not seen an actually failure relating to this but I'm not quite sure how
we've managed to get away with not doing it (I suppose multiply nested traps
are uncommon).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/entry.S |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 0b9cce5..36f1119 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -102,6 +102,10 @@ ENTRY(return_to_guest)
 
 ENTRY(return_to_hypervisor)
 	ldr lr, [sp, #UREGS_lr]
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
 	pop {r0-r12}
 	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
 	eret
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzV4A-0005lc-7S; Mon, 20 Feb 2012 15:22: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 1RzV48-0005kr-E6
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:22:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329751195!62075202!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7488 invoked from network); 20 Feb 2012 15:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325480400"; d="scan'208";a="182641106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 10:22:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 10:22:04 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q1KFM2RT028830; Mon, 20 Feb 2012 07:22:03 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 15:22:01 +0000
Message-ID: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
	from hypervisor to hypervisor.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is necessary to handle nested traps to the hypervisor more than one deep.

I've not seen an actually failure relating to this but I'm not quite sure how
we've managed to get away with not doing it (I suppose multiply nested traps
are uncommon).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/entry.S |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 0b9cce5..36f1119 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -102,6 +102,10 @@ ENTRY(return_to_guest)
 
 ENTRY(return_to_hypervisor)
 	ldr lr, [sp, #UREGS_lr]
+	ldr r11, [sp, #UREGS_pc]
+	msr ELR_hyp, r11
+	ldr r11, [sp, #UREGS_cpsr]
+	msr SPSR_hyp, r11
 	pop {r0-r12}
 	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
 	eret
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:32:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVEB-00062P-El; Mon, 20 Feb 2012 15:32:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVEA-00062K-78
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:32:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329751946!13922344!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27232 invoked from network); 20 Feb 2012 15:32:28 -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; 20 Feb 2012 15:32: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 q1KFWBHw019647
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:32:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1KFWA7g002636
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 15:32:11 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
	q1KFW9i3001871; Mon, 20 Feb 2012 09:32:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 07:32:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9926440334; Mon, 20 Feb 2012 10:28:55 -0500 (EST)
Date: Mon, 20 Feb 2012 10:28:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Igor Mammedov <imammedo@redhat.com>
Message-ID: <20120220152855.GA25535@phenom.dumpdata.com>
References: <28a9ca8a-4696-4c9c-bd15-f2fa5558740e@zmail16.collab.prod.int.phx2.redhat.com>
	<4F3D0CB1.5070707@redhat.com> <4F3E7150.7000804@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3E7150.7000804@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F42677D.0041,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, kvm@vger.kernel.org,
	mtosatti@redhat.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, Avi Kivity <avi@redhat.com>, hpa@zytor.com,
	amit shah <amit.shah@redhat.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] BUG in pv_clock when overflow condition is
	detected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 04:25:04PM +0100, Igor Mammedov wrote:
> On 02/16/2012 03:03 PM, Avi Kivity wrote:
> >On 02/15/2012 07:18 PM, Igor Mammedov wrote:
> >>>On 02/15/2012 01:23 PM, Igor Mammedov wrote:
> >>>>>>   static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time
> >>>>>>*shadow)
> >>>>>>   {
> >>>>>>-    u64 delta = native_read_tsc() - shadow->tsc_timestamp;
> >>>>>>+    u64 delta;
> >>>>>>+    u64 tsc = native_read_tsc();
> >>>>>>+    BUG_ON(tsc<   shadow->tsc_timestamp);
> >>>>>>+    delta = tsc - shadow->tsc_timestamp;
> >>>>>>       return pvclock_scale_delta(delta, shadow->tsc_to_nsec_mul,
> >>>>>>                      shadow->tsc_shift);
> >>>>>
> >>>>>Maybe a WARN_ON_ONCE()?  Otherwise a relatively minor hypervisor
> >>>>>bug can
> >>>>>kill the guest.
> >>>>
> >>>>
> >>>>An attempt to print from this place is not perfect since it often
> >>>>leads
> >>>>to recursive calling to this very function and it hang there
> >>>>anyway.
> >>>>But if you insist I'll re-post it with WARN_ON_ONCE,
> >>>>It won't make much difference because guest will hang/stall due
> >>>>overflow
> >>>>anyway.
> >>>
> >>>Won't a BUG_ON() also result in a printk?
> >>Yes, it will. But stack will still keep failure point and poking
> >>with crash/gdb at core will always show where it's BUGged.
> >>
> >>In case it manages to print dump somehow (saw it couple times from ~
> >>30 test cycles), logs from console or from kernel message buffer
> >>(again poking with gdb) will show where it was called from.
> >>
> >>If WARN* is used, it will still totaly screwup clock and
> >>"last value" and system will become unusable, requiring looking with
> >>gdb/crash at the core any way.
> >>
> >>So I've just used more stable failure point that will leave trace
> >>everywhere it manages (maybe in console log, but for sure in stack)
> >>in case of WARN it might leave trace on console or not and probably
> >>won't reflect failure point in stack either leaving only kernel
> >>message buffer for clue.
> >>
> >
> >Makes sense.  But do get an ack from the Xen people to ensure this
> >doesn't break for them.
> >
> Konrad, Ian
> 
> Could you please review patch form point of view of xen?
> Whole thread could be found here https://lkml.org/lkml/2012/2/13/286

What are the conditions under which this happens? You should probably
include that in the git description as well? Is this something that happens
often? If there is an overflow can you synthesize a value instead of
crashing the guest?

Hm, so are you asking for review for this patch or for
http://www.spinics.net/lists/kvm/msg68440.html ?

(which would also entail a early_percpu_clock_init implementation
in the Xen code naturally).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:32:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVEB-00062P-El; Mon, 20 Feb 2012 15:32:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVEA-00062K-78
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:32:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329751946!13922344!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27232 invoked from network); 20 Feb 2012 15:32:28 -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; 20 Feb 2012 15:32: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 q1KFWBHw019647
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:32:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1KFWA7g002636
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 15:32:11 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
	q1KFW9i3001871; Mon, 20 Feb 2012 09:32:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 07:32:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9926440334; Mon, 20 Feb 2012 10:28:55 -0500 (EST)
Date: Mon, 20 Feb 2012 10:28:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Igor Mammedov <imammedo@redhat.com>
Message-ID: <20120220152855.GA25535@phenom.dumpdata.com>
References: <28a9ca8a-4696-4c9c-bd15-f2fa5558740e@zmail16.collab.prod.int.phx2.redhat.com>
	<4F3D0CB1.5070707@redhat.com> <4F3E7150.7000804@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3E7150.7000804@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F42677D.0041,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, kvm@vger.kernel.org,
	mtosatti@redhat.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, Avi Kivity <avi@redhat.com>, hpa@zytor.com,
	amit shah <amit.shah@redhat.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] BUG in pv_clock when overflow condition is
	detected
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Feb 17, 2012 at 04:25:04PM +0100, Igor Mammedov wrote:
> On 02/16/2012 03:03 PM, Avi Kivity wrote:
> >On 02/15/2012 07:18 PM, Igor Mammedov wrote:
> >>>On 02/15/2012 01:23 PM, Igor Mammedov wrote:
> >>>>>>   static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time
> >>>>>>*shadow)
> >>>>>>   {
> >>>>>>-    u64 delta = native_read_tsc() - shadow->tsc_timestamp;
> >>>>>>+    u64 delta;
> >>>>>>+    u64 tsc = native_read_tsc();
> >>>>>>+    BUG_ON(tsc<   shadow->tsc_timestamp);
> >>>>>>+    delta = tsc - shadow->tsc_timestamp;
> >>>>>>       return pvclock_scale_delta(delta, shadow->tsc_to_nsec_mul,
> >>>>>>                      shadow->tsc_shift);
> >>>>>
> >>>>>Maybe a WARN_ON_ONCE()?  Otherwise a relatively minor hypervisor
> >>>>>bug can
> >>>>>kill the guest.
> >>>>
> >>>>
> >>>>An attempt to print from this place is not perfect since it often
> >>>>leads
> >>>>to recursive calling to this very function and it hang there
> >>>>anyway.
> >>>>But if you insist I'll re-post it with WARN_ON_ONCE,
> >>>>It won't make much difference because guest will hang/stall due
> >>>>overflow
> >>>>anyway.
> >>>
> >>>Won't a BUG_ON() also result in a printk?
> >>Yes, it will. But stack will still keep failure point and poking
> >>with crash/gdb at core will always show where it's BUGged.
> >>
> >>In case it manages to print dump somehow (saw it couple times from ~
> >>30 test cycles), logs from console or from kernel message buffer
> >>(again poking with gdb) will show where it was called from.
> >>
> >>If WARN* is used, it will still totaly screwup clock and
> >>"last value" and system will become unusable, requiring looking with
> >>gdb/crash at the core any way.
> >>
> >>So I've just used more stable failure point that will leave trace
> >>everywhere it manages (maybe in console log, but for sure in stack)
> >>in case of WARN it might leave trace on console or not and probably
> >>won't reflect failure point in stack either leaving only kernel
> >>message buffer for clue.
> >>
> >
> >Makes sense.  But do get an ack from the Xen people to ensure this
> >doesn't break for them.
> >
> Konrad, Ian
> 
> Could you please review patch form point of view of xen?
> Whole thread could be found here https://lkml.org/lkml/2012/2/13/286

What are the conditions under which this happens? You should probably
include that in the git description as well? Is this something that happens
often? If there is an overflow can you synthesize a value instead of
crashing the guest?

Hm, so are you asking for review for this patch or for
http://www.spinics.net/lists/kvm/msg68440.html ?

(which would also entail a early_percpu_clock_init implementation
in the Xen code naturally).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:39:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVKM-0006CD-Bt; Mon, 20 Feb 2012 15:38:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzVKK-0006By-VS
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:38:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329752330!14145907!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5722 invoked from network); 20 Feb 2012 15:38:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 15:38:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329752330; l=1058;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/eEXKqMVfI86rgV69YfP6/4jLjQ=;
	b=SP8SqNkVqZ6LdzxtOK/MhiDlsxAC4HUkbJntNXT8qh7ddHaquxTzi7ETqyvLgayQa/V
	w37Og0RmhoCKqNhtMoS7/SXQFZvTJzv6bQ7c56LsVM+J8PVR1R69Ka3VKXKqz4n4yfPq8
	qWyWLgIrSrqQ346UW79e1SibJBoh3CIyBaE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo42) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id J01172o1KFXJ9p ;
	Mon, 20 Feb 2012 16:38:43 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 426B418638; Mon, 20 Feb 2012 16:38:41 +0100 (CET)
Date: Mon, 20 Feb 2012 16:38:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120220153841.GB14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, George Dunlap wrote:

> xl mem-set domain M
>  xenpaging off: Set balloon target to M
>  xenpaging on: Set paging target to M
>  xenpaging delay: Set balloon target to M, and wait for actual memory
> to reach M.  If it hasn't reached it by $paging_delay seconds, set
> balloon target to M.

The tristate instead of a boolean is not really needed as well.

Right now a reduction of the balloon target depends on how fast the
guests balloon driver can claim memory from the guest OS. This means it
could take an infinite amount of time to reach the requested target.
With paging the request to reduce the "footprint" can be reached as fast
as xenpaging can page-out gfns (and page-in busy gfns).

So having a delay or not seems to depend on how mem-set is supposed to
react, either now or at an (kind of) undefined time in the future. 

If "now" is not the desired mode then xenpaging can slowly work toward a
new lower target by calling its evict_pages() with low numbers and and
an adjustable delay between calls.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:39:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:39:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVKM-0006CD-Bt; Mon, 20 Feb 2012 15:38:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzVKK-0006By-VS
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:38:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329752330!14145907!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5722 invoked from network); 20 Feb 2012 15:38:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 15:38:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329752330; l=1058;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/eEXKqMVfI86rgV69YfP6/4jLjQ=;
	b=SP8SqNkVqZ6LdzxtOK/MhiDlsxAC4HUkbJntNXT8qh7ddHaquxTzi7ETqyvLgayQa/V
	w37Og0RmhoCKqNhtMoS7/SXQFZvTJzv6bQ7c56LsVM+J8PVR1R69Ka3VKXKqz4n4yfPq8
	qWyWLgIrSrqQ346UW79e1SibJBoh3CIyBaE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo42) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id J01172o1KFXJ9p ;
	Mon, 20 Feb 2012 16:38:43 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 426B418638; Mon, 20 Feb 2012 16:38:41 +0100 (CET)
Date: Mon, 20 Feb 2012 16:38:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120220153841.GB14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, George Dunlap wrote:

> xl mem-set domain M
>  xenpaging off: Set balloon target to M
>  xenpaging on: Set paging target to M
>  xenpaging delay: Set balloon target to M, and wait for actual memory
> to reach M.  If it hasn't reached it by $paging_delay seconds, set
> balloon target to M.

The tristate instead of a boolean is not really needed as well.

Right now a reduction of the balloon target depends on how fast the
guests balloon driver can claim memory from the guest OS. This means it
could take an infinite amount of time to reach the requested target.
With paging the request to reduce the "footprint" can be reached as fast
as xenpaging can page-out gfns (and page-in busy gfns).

So having a delay or not seems to depend on how mem-set is supposed to
react, either now or at an (kind of) undefined time in the future. 

If "now" is not the desired mode then xenpaging can slowly work toward a
new lower target by calling its evict_pages() with low numbers and and
an adjustable delay between calls.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:52:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15: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.xensource.com>)
	id 1RzVX3-0006Oy-OB; Mon, 20 Feb 2012 15:52: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 1RzVX2-0006Ot-7A
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:52:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329752988!53468549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4399 invoked from network); 20 Feb 2012 15:49:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 15:52:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 15:52:03 +0000
Message-ID: <1329753121.3990.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 15:52:01 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyB3ZWVrcyB1cGRhdGUuIEFzIHVzdWFsIHBsZWFzZSBwaW5nIG1lIHdpdGggYW55IHVwZGF0
ZXMuCgpoeXBlcnZpc29yLCBibG9ja2VyczoKICAgICAgKiByb3VuZC11cCBvZiB0aGUgY2xvc2lu
ZyBvZiB0aGUgc2VjdXJpdHkgaG9sZSBpbiBNU0ktWAogICAgICAgIHBhc3N0aHJvdWdoICh1bmlm
b3JtbHkgLSBpLmUuIGV2ZW4gZm9yIERvbTAgLSBkaXNhbGxvd2luZyB3cml0ZQogICAgICAgIGFj
Y2VzcyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4gQmV1bGljaCwgRE9ORSkKICAgICAgKiBk
b21jdGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBs
aWtlCiAgICAgICAgdGhlIGNyZWRpdDEgdGltZXNsaWNlIGFuZCBzY2hlZHVsZSByYXRlLiAoR2Vv
cmdlIER1bmxhcCkKICAgICAgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZvciBzaGFyaW5n
L3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCiAgICAgICAgZHVzdGVkIHNvIHRoYXQgNC4yIGlz
IGEgc3RhYmxlIEFQSSB0aGF0IHdlIGhvbGQgdG8uIChUaW0gRGVlZ2FuLAogICAgICAgIEFuZHJl
cyBMYWdhci1DYXZpbGxhIGV0IGFsKQogICAgICAgICAgICAgICogc2hhcmluZyBwYXRjaGVzIHBv
c3RlZCAoRE9ORSkKCnRvb2xzLCBibG9ja2VyczoKCiAgICAgICogbGlieGwgc3RhYmxlIEFQSSAt
LSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAgICAgd2hpY2gg
ZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBv
ZgogICAgICAgIHRoaXMgYXJlOgogICAgICAgICAgICAgICogYWRkIGxpYnhsX2RlZmJvb2wgYW5k
IGdlbmVyYWxseSB0cnkgYW5kIGFycmFuZ2UgdGhhdAogICAgICAgICAgICAgICAgbWVtc2V0KGZv
bywwLC4uLikgcmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCiAgICAgICAgICAg
ICAgICBwYXRjaGVzIHJlcG9zdGVkKQogICAgICAgICAgICAgICogU2FmZSBmb3JrIHZzLiBmZCBo
YW5kbGluZyBob29rcy4gVGhpcyBpcyBhbiBBUEkKICAgICAgICAgICAgICAgIGFkZGl0aW9uLCBz
byBtYXliZSBub3QgcmVxdWlyZWQgZnJvIHN0YWJsZSBBUEksIGJpdCBuZWVkCiAgICAgICAgICAg
ICAgICB0byBoYXZlIGZvciA0LjI/IChJYW4gSikKICAgICAgICAgICAgICAqIHhsIGZlYXR1cmUg
cGFyaXR5IHdpdGggeGVuZCB3cnQgZHJpdmVyIGRvbWFpbiBzdXBwb3J0CiAgICAgICAgICAgICAg
ICAoR2VvcmdlIER1bmxhcCkKICAgICAgICAgICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRl
IHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5CiAgICAgICAgICAgICAgICBpbiB0cmVl
LiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQKICAgICAgICAg
ICAgICAgIC1yYzEgdG8gcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAqIENvcnJlY3Qg
cGFnaW5nL3NoYXJpbmcgdG9vbHMgYnVmZmVyIG1sb2NraW5nIChUaW0sIEFuZHJlcykKICAgICAg
KiBBdXRvY29uZiAoUm9nZXIgUGF1IE1vbm7DqSAmIElhbiBKLCBibG9ja2VkIG9uIHRlc3QKICAg
ICAgICBpbmZyYXN0cnVjdHVyZSBjaGFuZ2VzLCBSb2dlciB0byByZXNwaW4gcGF0Y2ggd2hlbiB0
ZXN0IHN5c3RlbQogICAgICAgIHJlYWR5IGZvciBuZXcgZmVhdHVyZXMpCiAgICAgICogeGwgc3Vw
cG9ydCBmb3IgInJ0Y190aW1lb2Zmc2V0IiBhbmQgImxvY2FsdGltZSIgKE5vYm9keSBBRkFJQ1Qp
CgpoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6CgogICAgICAqIHNvbGlkIGltcGxlbWVudGF0aW9u
IG9mIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVudHMgKHVzaW5nIHdvcmsKICAgICAgICBxdWV1ZXMp
IChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwpCiAgICAgICogQSBsb25nIHN0YW5kaW5n
IGlzc3VlIGlzIGEgZnVsbHkgc3luY2hyb25pemVkIHAybSAobG9ja2luZwogICAgICAgIGxvb2t1
cHMpIChBbmRyZXMgTGFnYXItQ2F2aWxsYSwgcGF0Y2hlcyBwb3N0ZWQ/KQoKdG9vbHMsIG5pY2Ug
dG8gaGF2ZToKCiAgICAgICogSG90cGx1ZyBzY3JpcHQgc3R1ZmYgLS0gaW50ZXJuYWwgdG8gbGli
eGwgKEkgdGhpbmssIHRoZXJlZm9yZSBJCiAgICAgICAgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0
YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKICAgICAgICBmb3IgNC4yPyAo
Um9nZXIgUGF1IE1vbm7DqSwgcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICogQmxvY2sgc2NyaXB0IHN1
cHBvcnQgLS0gZm9sbG93cyBvbiBmcm9tIGhvdHBsdWcgc2NyaXB0IChSb2dlcgogICAgICAgIFBh
dSBNb25uw6kpCiAgICAgICogQ29uZmlndXJlL2NvbnRyb2wgcGFnaW5nIHZpYSB4bC9saWJ4bCAo
T2xhZiBIZXJyaW5nKQogICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgogICAg
ICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCAoQW50aG9u
eSBQZXJhcmQsCiAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCiAgICAgICAgICAgICAgKiBV
cHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KICAgICAg
ICAgICAgICAgIFN0YWJlbGxpbmksIHBhdGNoZXMgc2VudCwgd2FpdGluZyBmb3IgdXBzdHJlYW0g
YWNrKQogICAgICAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3VycmVudGx5IHNob3VsZCBiZSBt
YXJrZWQgZXhwZXJpbWVudGFsLAogICAgICAgIGxpa2VseSB0byByZWxlYXNlIHRoYXQgd2F5PyBD
b25zaWRlciBuZXN0ZWQtc3ZtIHNlcGFyYXRlIHRvCiAgICAgICAgbmVzdGVkLXZteC4gTmVzdGVk
LXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBS
ZW11cyAobWVtb3J5IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQogICAgICAgIChTaHJpcmFtLCBw
YXRjaGVzIHBvc3RlZCkKICAgICAgKiB4bCBzdXBwb3J0IGZvciBhdXRvc3Bhd25pbmcgdm5jdmll
d2VyICh2bmN2aWV3ZXI9MSBvciBvdGhlcndpc2UpCiAgICAgICAgKE5vYm9keSBBRkFJQ1QpCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:52:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15: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.xensource.com>)
	id 1RzVX3-0006Oy-OB; Mon, 20 Feb 2012 15:52: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 1RzVX2-0006Ot-7A
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:52:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329752988!53468549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4399 invoked from network); 20 Feb 2012 15:49:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 15:52:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 15:52:03 +0000
Message-ID: <1329753121.3990.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 15:52:01 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhpcyB3ZWVrcyB1cGRhdGUuIEFzIHVzdWFsIHBsZWFzZSBwaW5nIG1lIHdpdGggYW55IHVwZGF0
ZXMuCgpoeXBlcnZpc29yLCBibG9ja2VyczoKICAgICAgKiByb3VuZC11cCBvZiB0aGUgY2xvc2lu
ZyBvZiB0aGUgc2VjdXJpdHkgaG9sZSBpbiBNU0ktWAogICAgICAgIHBhc3N0aHJvdWdoICh1bmlm
b3JtbHkgLSBpLmUuIGV2ZW4gZm9yIERvbTAgLSBkaXNhbGxvd2luZyB3cml0ZQogICAgICAgIGFj
Y2VzcyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4gQmV1bGljaCwgRE9ORSkKICAgICAgKiBk
b21jdGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBs
aWtlCiAgICAgICAgdGhlIGNyZWRpdDEgdGltZXNsaWNlIGFuZCBzY2hlZHVsZSByYXRlLiAoR2Vv
cmdlIER1bmxhcCkKICAgICAgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZvciBzaGFyaW5n
L3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCiAgICAgICAgZHVzdGVkIHNvIHRoYXQgNC4yIGlz
IGEgc3RhYmxlIEFQSSB0aGF0IHdlIGhvbGQgdG8uIChUaW0gRGVlZ2FuLAogICAgICAgIEFuZHJl
cyBMYWdhci1DYXZpbGxhIGV0IGFsKQogICAgICAgICAgICAgICogc2hhcmluZyBwYXRjaGVzIHBv
c3RlZCAoRE9ORSkKCnRvb2xzLCBibG9ja2VyczoKCiAgICAgICogbGlieGwgc3RhYmxlIEFQSSAt
LSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAgICAgd2hpY2gg
ZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBv
ZgogICAgICAgIHRoaXMgYXJlOgogICAgICAgICAgICAgICogYWRkIGxpYnhsX2RlZmJvb2wgYW5k
IGdlbmVyYWxseSB0cnkgYW5kIGFycmFuZ2UgdGhhdAogICAgICAgICAgICAgICAgbWVtc2V0KGZv
bywwLC4uLikgcmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCiAgICAgICAgICAg
ICAgICBwYXRjaGVzIHJlcG9zdGVkKQogICAgICAgICAgICAgICogU2FmZSBmb3JrIHZzLiBmZCBo
YW5kbGluZyBob29rcy4gVGhpcyBpcyBhbiBBUEkKICAgICAgICAgICAgICAgIGFkZGl0aW9uLCBz
byBtYXliZSBub3QgcmVxdWlyZWQgZnJvIHN0YWJsZSBBUEksIGJpdCBuZWVkCiAgICAgICAgICAg
ICAgICB0byBoYXZlIGZvciA0LjI/IChJYW4gSikKICAgICAgICAgICAgICAqIHhsIGZlYXR1cmUg
cGFyaXR5IHdpdGggeGVuZCB3cnQgZHJpdmVyIGRvbWFpbiBzdXBwb3J0CiAgICAgICAgICAgICAg
ICAoR2VvcmdlIER1bmxhcCkKICAgICAgICAgICAgICAqIE1vcmUgZm9ybWFsbHkgZGVwcmVjYXRl
IHhtL3hlbmQuIE1hbnBhZ2UgcGF0Y2hlcyBhbHJlYWR5CiAgICAgICAgICAgICAgICBpbiB0cmVl
LiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQKICAgICAgICAg
ICAgICAgIC1yYzEgdG8gcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAqIENvcnJlY3Qg
cGFnaW5nL3NoYXJpbmcgdG9vbHMgYnVmZmVyIG1sb2NraW5nIChUaW0sIEFuZHJlcykKICAgICAg
KiBBdXRvY29uZiAoUm9nZXIgUGF1IE1vbm7DqSAmIElhbiBKLCBibG9ja2VkIG9uIHRlc3QKICAg
ICAgICBpbmZyYXN0cnVjdHVyZSBjaGFuZ2VzLCBSb2dlciB0byByZXNwaW4gcGF0Y2ggd2hlbiB0
ZXN0IHN5c3RlbQogICAgICAgIHJlYWR5IGZvciBuZXcgZmVhdHVyZXMpCiAgICAgICogeGwgc3Vw
cG9ydCBmb3IgInJ0Y190aW1lb2Zmc2V0IiBhbmQgImxvY2FsdGltZSIgKE5vYm9keSBBRkFJQ1Qp
CgpoeXBlcnZpc29yLCBuaWNlIHRvIGhhdmU6CgogICAgICAqIHNvbGlkIGltcGxlbWVudGF0aW9u
IG9mIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVudHMgKHVzaW5nIHdvcmsKICAgICAgICBxdWV1ZXMp
IChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwpCiAgICAgICogQSBsb25nIHN0YW5kaW5n
IGlzc3VlIGlzIGEgZnVsbHkgc3luY2hyb25pemVkIHAybSAobG9ja2luZwogICAgICAgIGxvb2t1
cHMpIChBbmRyZXMgTGFnYXItQ2F2aWxsYSwgcGF0Y2hlcyBwb3N0ZWQ/KQoKdG9vbHMsIG5pY2Ug
dG8gaGF2ZToKCiAgICAgICogSG90cGx1ZyBzY3JpcHQgc3R1ZmYgLS0gaW50ZXJuYWwgdG8gbGli
eGwgKEkgdGhpbmssIHRoZXJlZm9yZSBJCiAgICAgICAgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0
YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKICAgICAgICBmb3IgNC4yPyAo
Um9nZXIgUGF1IE1vbm7DqSwgcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICogQmxvY2sgc2NyaXB0IHN1
cHBvcnQgLS0gZm9sbG93cyBvbiBmcm9tIGhvdHBsdWcgc2NyaXB0IChSb2dlcgogICAgICAgIFBh
dSBNb25uw6kpCiAgICAgICogQ29uZmlndXJlL2NvbnRyb2wgcGFnaW5nIHZpYSB4bC9saWJ4bCAo
T2xhZiBIZXJyaW5nKQogICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgogICAg
ICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCAoQW50aG9u
eSBQZXJhcmQsCiAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCiAgICAgICAgICAgICAgKiBV
cHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KICAgICAg
ICAgICAgICAgIFN0YWJlbGxpbmksIHBhdGNoZXMgc2VudCwgd2FpdGluZyBmb3IgdXBzdHJlYW0g
YWNrKQogICAgICAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3VycmVudGx5IHNob3VsZCBiZSBt
YXJrZWQgZXhwZXJpbWVudGFsLAogICAgICAgIGxpa2VseSB0byByZWxlYXNlIHRoYXQgd2F5PyBD
b25zaWRlciBuZXN0ZWQtc3ZtIHNlcGFyYXRlIHRvCiAgICAgICAgbmVzdGVkLXZteC4gTmVzdGVk
LXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBS
ZW11cyAobWVtb3J5IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQogICAgICAgIChTaHJpcmFtLCBw
YXRjaGVzIHBvc3RlZCkKICAgICAgKiB4bCBzdXBwb3J0IGZvciBhdXRvc3Bhd25pbmcgdm5jdmll
d2VyICh2bmN2aWV3ZXI9MSBvciBvdGhlcndpc2UpCiAgICAgICAgKE5vYm9keSBBRkFJQ1QpCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:59:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVdl-0006aK-Kl; Mon, 20 Feb 2012 15:59:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzVdk-0006aC-5u
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:59:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329753533!14721133!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29016 invoked from network); 20 Feb 2012 15:58:54 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:58:54 -0000
Received: by wgbdr13 with SMTP id dr13so4295953wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 07:58:53 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr22878862wib.3.1329753533951 (num_hops
	= 1); Mon, 20 Feb 2012 07:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=vzxdLvaL4RwBpqqWoC/LFKz8+gLcyttK3F9clS4wiHY=;
	b=cf1y+4ggWzHecCZRI7mvcp3LkV2maPDQ3Nc6tqfj5pwtXUQvA/vdzIzl1hGXDKUZjp
	rBBPBv4ClmAiojFlO8TS8Otd79M5MF/bXK2V+MYGwfArXItt/Hx+v34wrMkuUUls9Hxi
	HuMuWx8m4noP45VrZEiSBqclQL+2g0U9oKydo=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr19057356wib.3.1329753533499; Mon,
	20 Feb 2012 07:58:53 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 07:58:53 -0800 (PST)
In-Reply-To: <20120220144054.GA6547@morn.localdomain>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
	<1329731328.3990.1.camel@zakaz.uk.xensource.com>
	<20120220144054.GA6547@morn.localdomain>
Date: Mon, 20 Feb 2012 16:58:53 +0100
X-Google-Sender-Auth: PJKaCEJakV82M0VRDS_pAH7sK7w
Message-ID: <CAPLaKK7=CSxoHB=RrjqMat8toEnp5FdHPe9aiE4r62T2X+4jPA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "Kevin O'Connor" <kevin@koconnor.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [SeaBIOS] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIwIEtldmluIE8nQ29ubm9yIDxrZXZpbkBrb2Nvbm5vci5uZXQ+Ogo+IE9uIE1vbiwg
RmViIDIwLCAyMDEyIGF0IDA5OjQ4OjQ4QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4g
T24gTW9uLCAyMDEyLTAyLTIwIGF0IDA5OjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+PiA+IFdoZW4gbG9va2luZyBpbnRvIGdlbi1vZmZzZXRzLnNoIFswXSBJJ3ZlIHJlYWxpemVk
IHRoZXJlJ3MgYSBzdHJhbmdlCj4+ID4gc2hlYmFuZyBpbiB0aGUgc2NyaXB0ICI6IiwgaXMgdGhp
cyBub3JtYWw/IFJlcGxhY2luZyAiOiIgd2l0aAo+PiA+ICIjIS9iaW4vc2giIHNvbHZlcyB0aGUg
cHJvYmxlbSwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlICI6Igo+PiA+IHNoZWJhbmcg
d29ya3MgZm9yIHNvbWUgKG9uIERlYmlhbiBzdGFibGUgaXQgd29ya3Mgb2spIGFuZCB3aGF0IGl0
Cj4+ID4gbWVhbnMuCj4+Cj4+IEkndmUgbm8gaWRlYSBlaXRoZXIgLS0gSSd2ZSBjb3BpZWQgdGhl
IHNlYWJpb3MgTUwuCj4KPiBJdCdzIGFuIG9sZC1zdHlsZSB3YXkgb2YgaW5kaWNhdGluZyB0aGUg
ZmlsZSBpcyBhIHNoZWxsIHNjcmlwdC4gwqBJCj4gd2Fzbid0IGF3YXJlIHRoaXMgY3JlZXBlZCBp
biB0aGVyZSAtIGl0IHNob3VsZCBiZSBjb252ZXJ0ZWQgdG8gdGhlCj4gbW9yZSBzdGFuZGFyZCBz
dHlsZS4KPgo+IC1LZXZpbgo+Cj4KPiBjb21taXQgMGZkOTk1M2E1MzhiMjJlNjA4N2Y5ZDRmMjU3
NDllMzYyMmU0MGU4Nwo+IEF1dGhvcjogS2V2aW4gTydDb25ub3IgPGtldmluQGtvY29ubm9yLm5l
dD4KPiBEYXRlOiDCoCBNb24gRmViIDIwIDA5OjMzOjIzIDIwMTIgLTA1MDAKPgo+IMKgIMKgVXNl
ICIjIS9iaW4vc2giIGluc3RlYWQgb2YgIjoiIGluIHRvb2xzL2dlbi1vZmZzZXRzLnNoLgo+Cj4g
wqAgwqBTaWduZWQtb2ZmLWJ5OiBLZXZpbiBPJ0Nvbm5vciA8a2V2aW5Aa29jb25ub3IubmV0PgoK
RG9uJ3Qga25vdyBpZiBpdCdzIG9rIHRvIEFjayB0aGlzLCBpZiBub3QgcGxlYXNlIGlnbm9yZSBp
dCBhbmQKY29uc2lkZXIgdGhpcyBhIFRlc3RlZC1ieToKCkFja2VkLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KCj4KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvZ2Vu
LW9mZnNldHMuc2ggYi90b29scy9nZW4tb2Zmc2V0cy5zaAo+IGluZGV4IDk5ZmRjNTMuLjczZGVk
ZTggMTAwNzU1Cj4gLS0tIGEvdG9vbHMvZ2VuLW9mZnNldHMuc2gKPiArKysgYi90b29scy9nZW4t
b2Zmc2V0cy5zaAo+IEBAIC0xLDQgKzEsNCBAQAo+IC06Cj4gKyMhL2Jpbi9zaAo+IMKgIyBFeHRy
YWN0IGRlZmluaXRpb25zIGZyb20gYW4gYXNzZW1ibGVyIGZpbGUuIMKgVGhpcyBpcyBiYXNlZCBv
biBjb2RlCj4gwqAjIGZyb20gdGhlIExpbnV4IEtlcm5lbC4KPiDCoElORklMRT0kMQoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 15:59:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVdl-0006aK-Kl; Mon, 20 Feb 2012 15:59:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzVdk-0006aC-5u
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 15:59:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329753533!14721133!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29016 invoked from network); 20 Feb 2012 15:58:54 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 15:58:54 -0000
Received: by wgbdr13 with SMTP id dr13so4295953wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 07:58:53 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr22878862wib.3.1329753533951 (num_hops
	= 1); Mon, 20 Feb 2012 07:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=vzxdLvaL4RwBpqqWoC/LFKz8+gLcyttK3F9clS4wiHY=;
	b=cf1y+4ggWzHecCZRI7mvcp3LkV2maPDQ3Nc6tqfj5pwtXUQvA/vdzIzl1hGXDKUZjp
	rBBPBv4ClmAiojFlO8TS8Otd79M5MF/bXK2V+MYGwfArXItt/Hx+v34wrMkuUUls9Hxi
	HuMuWx8m4noP45VrZEiSBqclQL+2g0U9oKydo=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr19057356wib.3.1329753533499; Mon,
	20 Feb 2012 07:58:53 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Mon, 20 Feb 2012 07:58:53 -0800 (PST)
In-Reply-To: <20120220144054.GA6547@morn.localdomain>
References: <CAPLaKK451m3eBp+krpZs+ahAow7-bk6TTFj1Lrj59pHKRtJ=Jg@mail.gmail.com>
	<1329731328.3990.1.camel@zakaz.uk.xensource.com>
	<20120220144054.GA6547@morn.localdomain>
Date: Mon, 20 Feb 2012 16:58:53 +0100
X-Google-Sender-Auth: PJKaCEJakV82M0VRDS_pAH7sK7w
Message-ID: <CAPLaKK7=CSxoHB=RrjqMat8toEnp5FdHPe9aiE4r62T2X+4jPA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "Kevin O'Connor" <kevin@koconnor.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	seabios@seabios.org, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [SeaBIOS] SeaBIOS build problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8yLzIwIEtldmluIE8nQ29ubm9yIDxrZXZpbkBrb2Nvbm5vci5uZXQ+Ogo+IE9uIE1vbiwg
RmViIDIwLCAyMDEyIGF0IDA5OjQ4OjQ4QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4g
T24gTW9uLCAyMDEyLTAyLTIwIGF0IDA5OjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+PiA+IFdoZW4gbG9va2luZyBpbnRvIGdlbi1vZmZzZXRzLnNoIFswXSBJJ3ZlIHJlYWxpemVk
IHRoZXJlJ3MgYSBzdHJhbmdlCj4+ID4gc2hlYmFuZyBpbiB0aGUgc2NyaXB0ICI6IiwgaXMgdGhp
cyBub3JtYWw/IFJlcGxhY2luZyAiOiIgd2l0aAo+PiA+ICIjIS9iaW4vc2giIHNvbHZlcyB0aGUg
cHJvYmxlbSwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlICI6Igo+PiA+IHNoZWJhbmcg
d29ya3MgZm9yIHNvbWUgKG9uIERlYmlhbiBzdGFibGUgaXQgd29ya3Mgb2spIGFuZCB3aGF0IGl0
Cj4+ID4gbWVhbnMuCj4+Cj4+IEkndmUgbm8gaWRlYSBlaXRoZXIgLS0gSSd2ZSBjb3BpZWQgdGhl
IHNlYWJpb3MgTUwuCj4KPiBJdCdzIGFuIG9sZC1zdHlsZSB3YXkgb2YgaW5kaWNhdGluZyB0aGUg
ZmlsZSBpcyBhIHNoZWxsIHNjcmlwdC4gwqBJCj4gd2Fzbid0IGF3YXJlIHRoaXMgY3JlZXBlZCBp
biB0aGVyZSAtIGl0IHNob3VsZCBiZSBjb252ZXJ0ZWQgdG8gdGhlCj4gbW9yZSBzdGFuZGFyZCBz
dHlsZS4KPgo+IC1LZXZpbgo+Cj4KPiBjb21taXQgMGZkOTk1M2E1MzhiMjJlNjA4N2Y5ZDRmMjU3
NDllMzYyMmU0MGU4Nwo+IEF1dGhvcjogS2V2aW4gTydDb25ub3IgPGtldmluQGtvY29ubm9yLm5l
dD4KPiBEYXRlOiDCoCBNb24gRmViIDIwIDA5OjMzOjIzIDIwMTIgLTA1MDAKPgo+IMKgIMKgVXNl
ICIjIS9iaW4vc2giIGluc3RlYWQgb2YgIjoiIGluIHRvb2xzL2dlbi1vZmZzZXRzLnNoLgo+Cj4g
wqAgwqBTaWduZWQtb2ZmLWJ5OiBLZXZpbiBPJ0Nvbm5vciA8a2V2aW5Aa29jb25ub3IubmV0PgoK
RG9uJ3Qga25vdyBpZiBpdCdzIG9rIHRvIEFjayB0aGlzLCBpZiBub3QgcGxlYXNlIGlnbm9yZSBp
dCBhbmQKY29uc2lkZXIgdGhpcyBhIFRlc3RlZC1ieToKCkFja2VkLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KCj4KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvZ2Vu
LW9mZnNldHMuc2ggYi90b29scy9nZW4tb2Zmc2V0cy5zaAo+IGluZGV4IDk5ZmRjNTMuLjczZGVk
ZTggMTAwNzU1Cj4gLS0tIGEvdG9vbHMvZ2VuLW9mZnNldHMuc2gKPiArKysgYi90b29scy9nZW4t
b2Zmc2V0cy5zaAo+IEBAIC0xLDQgKzEsNCBAQAo+IC06Cj4gKyMhL2Jpbi9zaAo+IMKgIyBFeHRy
YWN0IGRlZmluaXRpb25zIGZyb20gYW4gYXNzZW1ibGVyIGZpbGUuIMKgVGhpcyBpcyBiYXNlZCBv
biBjb2RlCj4gwqAjIGZyb20gdGhlIExpbnV4IEtlcm5lbC4KPiDCoElORklMRT0kMQoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:02:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVh4-00076X-8V; Mon, 20 Feb 2012 16:02:26 +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 1RzVh3-00076Q-6X
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:02:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329753717!64253865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27873 invoked from network); 20 Feb 2012 16:01:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:02:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVgy-0004yx-KM; Mon, 20 Feb 2012 16:02:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVgy-0003F3-IF;
	Mon, 20 Feb 2012 16:02:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28300.524665.376840@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:02:20 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7tTbqKfozAFci3TXsUiSGi7ScqgETB6xGBj1aZ7240jg@mail.gmail.com>
References: <837570e539a114f47d8a.1326258829@build.localdomain>
	<20281.20160.628074.801720@mariner.uk.xensource.com>
	<CAPLaKK7tTbqKfozAFci3TXsUiSGi7ScqgETB6xGBj1aZ7240jg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v4 RESEND] build: add aut=
oconf to replace custom checks in tools/check"):
> I'm aware, since the yajl 2 series went in, this patch needs some
> adjustments. Just drop a line when you are ready and I will update it
> to match tip.

If you could do that now, that would be great.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:02:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVh4-00076X-8V; Mon, 20 Feb 2012 16:02:26 +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 1RzVh3-00076Q-6X
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:02:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329753717!64253865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27873 invoked from network); 20 Feb 2012 16:01:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:02:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVgy-0004yx-KM; Mon, 20 Feb 2012 16:02:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVgy-0003F3-IF;
	Mon, 20 Feb 2012 16:02:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28300.524665.376840@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:02:20 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7tTbqKfozAFci3TXsUiSGi7ScqgETB6xGBj1aZ7240jg@mail.gmail.com>
References: <837570e539a114f47d8a.1326258829@build.localdomain>
	<20281.20160.628074.801720@mariner.uk.xensource.com>
	<CAPLaKK7tTbqKfozAFci3TXsUiSGi7ScqgETB6xGBj1aZ7240jg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v4 RESEND] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v4 RESEND] build: add aut=
oconf to replace custom checks in tools/check"):
> I'm aware, since the yajl 2 series went in, this patch needs some
> adjustments. Just drop a line when you are ready and I will update it
> to match tip.

If you could do that now, that would be great.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:04:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVir-0007Cs-On; Mon, 20 Feb 2012 16:04:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzViq-0007Cc-GW
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:04:16 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329753846!4903190!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9629 invoked from network); 20 Feb 2012 16:04:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:04:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325480400"; d="scan'208";a="22258853"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 11:04:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 11:04:06 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1KG43Qt028944;
	Mon, 20 Feb 2012 08:04:04 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120220153841.GB14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<20120220153841.GB14062@aepfle.de>
Date: Mon, 20 Feb 2012 16:04:00 +0000
Message-ID: <1329753840.2196.35.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-20 at 15:38 +0000, Olaf Hering wrote:
> On Mon, Feb 20, George Dunlap wrote:
> 
> > xl mem-set domain M
> >  xenpaging off: Set balloon target to M
> >  xenpaging on: Set paging target to M
> >  xenpaging delay: Set balloon target to M, and wait for actual memory
> > to reach M.  If it hasn't reached it by $paging_delay seconds, set
> > balloon target to M.
> 
> The tristate instead of a boolean is not really needed as well.
> 
> Right now a reduction of the balloon target depends on how fast the
> guests balloon driver can claim memory from the guest OS. This means it
> could take an infinite amount of time to reach the requested target.
> With paging the request to reduce the "footprint" can be reached as fast
> as xenpaging can page-out gfns (and page-in busy gfns).
> 
> So having a delay or not seems to depend on how mem-set is supposed to
> react, either now or at an (kind of) undefined time in the future. 
> 
> If "now" is not the desired mode then xenpaging can slowly work toward a
> new lower target by calling its evict_pages() with low numbers and and
> an adjustable delay between calls.

I don't think this is a good option.  Consider the following cases:
1. The guest is cooperative and the balloon driver is active, but it
will take 30s to reach the target.  
2. The guest is uncooperative, or the balloon driver is inactive /
broken / stuck / unable to get pages. 

In case 1, the paging driver will end up paging a bunch of pages out for
30s, only to page them back in again after the balloon driver reaches
its target.  Also, you're basically guaranteed to hit the double-paging
problem: the pager will find an old page and page it out; then in the
very near future, the guest OS will decide to page *that very page* out,
touch it (causing the pager to page it back in), then write it out to
disk itself -- causing at least 3 page writes per page paged out.  This
will unnecessarily slow the system down (and the balloon driver down)
and waste IO bandwidth.  The degree to which the pager messes things up
will depend on how fast you make it.  Fast => messes up a lot slow =>
doesn't mess much up.  So slow is good in this case.

In case 2, the time it takes to reach the target will depend entirely on
the rate at which you page things out.  Slow => takes a long time, fast
=> happens relatively quicly.  So slow is bad in this case.

So no matter what we choose, something is really bad.

Under the "delay" option, 1 will behave optimally -- no wasted I/O, no
double paging; and 2 will take a fixed amount of time before going
full-bore; so it is, I believe, better in both cases.

You don't have to implement the "delay" option if you don't want to; as
long as we expose the low-level controls, the administrator can do the
"fall-back" himself, and then someone (possibly me) can implement
something like that in the future (either before or after the 4.2
release).  

However, there should be a way that paging can be on but "xl mem-set"
will set the balloon target.  If we have "paging=manual", that could
mean, "I'll start the pager daemon, but you'll have to call the xl
mem-set-paging-target yourself."

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:04:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVir-0007Cs-On; Mon, 20 Feb 2012 16:04:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzViq-0007Cc-GW
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:04:16 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329753846!4903190!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwMjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9629 invoked from network); 20 Feb 2012 16:04:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:04:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325480400"; d="scan'208";a="22258853"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 11:04:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 11:04:06 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q1KG43Qt028944;
	Mon, 20 Feb 2012 08:04:04 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120220153841.GB14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<20120220153841.GB14062@aepfle.de>
Date: Mon, 20 Feb 2012 16:04:00 +0000
Message-ID: <1329753840.2196.35.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-02-20 at 15:38 +0000, Olaf Hering wrote:
> On Mon, Feb 20, George Dunlap wrote:
> 
> > xl mem-set domain M
> >  xenpaging off: Set balloon target to M
> >  xenpaging on: Set paging target to M
> >  xenpaging delay: Set balloon target to M, and wait for actual memory
> > to reach M.  If it hasn't reached it by $paging_delay seconds, set
> > balloon target to M.
> 
> The tristate instead of a boolean is not really needed as well.
> 
> Right now a reduction of the balloon target depends on how fast the
> guests balloon driver can claim memory from the guest OS. This means it
> could take an infinite amount of time to reach the requested target.
> With paging the request to reduce the "footprint" can be reached as fast
> as xenpaging can page-out gfns (and page-in busy gfns).
> 
> So having a delay or not seems to depend on how mem-set is supposed to
> react, either now or at an (kind of) undefined time in the future. 
> 
> If "now" is not the desired mode then xenpaging can slowly work toward a
> new lower target by calling its evict_pages() with low numbers and and
> an adjustable delay between calls.

I don't think this is a good option.  Consider the following cases:
1. The guest is cooperative and the balloon driver is active, but it
will take 30s to reach the target.  
2. The guest is uncooperative, or the balloon driver is inactive /
broken / stuck / unable to get pages. 

In case 1, the paging driver will end up paging a bunch of pages out for
30s, only to page them back in again after the balloon driver reaches
its target.  Also, you're basically guaranteed to hit the double-paging
problem: the pager will find an old page and page it out; then in the
very near future, the guest OS will decide to page *that very page* out,
touch it (causing the pager to page it back in), then write it out to
disk itself -- causing at least 3 page writes per page paged out.  This
will unnecessarily slow the system down (and the balloon driver down)
and waste IO bandwidth.  The degree to which the pager messes things up
will depend on how fast you make it.  Fast => messes up a lot slow =>
doesn't mess much up.  So slow is good in this case.

In case 2, the time it takes to reach the target will depend entirely on
the rate at which you page things out.  Slow => takes a long time, fast
=> happens relatively quicly.  So slow is bad in this case.

So no matter what we choose, something is really bad.

Under the "delay" option, 1 will behave optimally -- no wasted I/O, no
double paging; and 2 will take a fixed amount of time before going
full-bore; so it is, I believe, better in both cases.

You don't have to implement the "delay" option if you don't want to; as
long as we expose the low-level controls, the administrator can do the
"fall-back" himself, and then someone (possibly me) can implement
something like that in the future (either before or after the 4.2
release).  

However, there should be a way that paging can be on but "xl mem-set"
will set the balloon target.  If we have "paging=manual", that could
mean, "I'll start the pager daemon, but you'll have to call the xl
mem-set-paging-target yourself."

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVki-0007ML-HA; Mon, 20 Feb 2012 16:06:12 +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 1RzVkg-0007Ll-E9
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:06:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329753910!53497769!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12609 invoked from network); 20 Feb 2012 16:05:11 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:05:11 -0000
Received: by ghbf1 with SMTP id f1so78170837ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 08:06:03 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.15.129 as permitted sender) client-ip=10.50.15.129; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.15.129 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.15.129])
	by 10.50.15.129 with SMTP id x1mr13659144igc.14.1329753962999 (num_hops
	= 1); Mon, 20 Feb 2012 08:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=I1/v3EehHMfaUZfA1GL9TtWQ3nL1mCxBz9xnRn0Ag20=;
	b=ZoLzu9hfYUXT7d5rdUiVoFMPJZDvr59Klmy5ZmdKd9pKT7z7MFTGrMvAI5gVadzw0D
	bnVVEB2VyPH0Ir8Ohs67HhUS/Gx1O/425jF7Q33kstZpteCy888IePlOeCEQs+tCq63C
	BSCmNSHFTEWoQHkqXYwZy5BUrKE/zV+iQQtmY=
MIME-Version: 1.0
Received: by 10.50.15.129 with SMTP id x1mr11086132igc.14.1329753962959; Mon,
	20 Feb 2012 08:06:02 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Mon, 20 Feb 2012 08:06:02 -0800 (PST)
In-Reply-To: <20120220151943.GA14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<20120220151943.GA14062@aepfle.de>
Date: Mon, 20 Feb 2012 16:06:02 +0000
X-Google-Sender-Auth: VJ5mq8_cUMxmhFFqxtGB7ZiZ6XY
Message-ID: <CAFLBxZa1ET25xqnQuJGVoA8E=ABvyEVjkaY1GW6FxiaCuAq=sw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 3:19 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Feb 20, George Dunlap wrote:
>
>> Olaf, what do you do right now for booting a guest in paging mode with
>> memory < maxmem?
>
> xenpaging exits because XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE returns
> -EXDEV when PoD is detected.

OK.  So we have two options, as I see it, if someone starts a guest
with both xenpaging=yes and memory<maxmem:

* Refuse to build the domain and return an error.
* Figure out how to boot with memory<maxmem only with the pager.  I
guess this would involve building with half the memory, and telling
the pager that some pages are pre-paged out...?

If the second option is too much work before the release, we should go
with the first option.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVki-0007ML-HA; Mon, 20 Feb 2012 16:06:12 +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 1RzVkg-0007Ll-E9
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:06:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329753910!53497769!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12609 invoked from network); 20 Feb 2012 16:05:11 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:05:11 -0000
Received: by ghbf1 with SMTP id f1so78170837ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 08:06:03 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.15.129 as permitted sender) client-ip=10.50.15.129; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.15.129 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.15.129])
	by 10.50.15.129 with SMTP id x1mr13659144igc.14.1329753962999 (num_hops
	= 1); Mon, 20 Feb 2012 08:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=I1/v3EehHMfaUZfA1GL9TtWQ3nL1mCxBz9xnRn0Ag20=;
	b=ZoLzu9hfYUXT7d5rdUiVoFMPJZDvr59Klmy5ZmdKd9pKT7z7MFTGrMvAI5gVadzw0D
	bnVVEB2VyPH0Ir8Ohs67HhUS/Gx1O/425jF7Q33kstZpteCy888IePlOeCEQs+tCq63C
	BSCmNSHFTEWoQHkqXYwZy5BUrKE/zV+iQQtmY=
MIME-Version: 1.0
Received: by 10.50.15.129 with SMTP id x1mr11086132igc.14.1329753962959; Mon,
	20 Feb 2012 08:06:02 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Mon, 20 Feb 2012 08:06:02 -0800 (PST)
In-Reply-To: <20120220151943.GA14062@aepfle.de>
References: <1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<20120220151943.GA14062@aepfle.de>
Date: Mon, 20 Feb 2012 16:06:02 +0000
X-Google-Sender-Auth: VJ5mq8_cUMxmhFFqxtGB7ZiZ6XY
Message-ID: <CAFLBxZa1ET25xqnQuJGVoA8E=ABvyEVjkaY1GW6FxiaCuAq=sw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Feb 20, 2012 at 3:19 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Feb 20, George Dunlap wrote:
>
>> Olaf, what do you do right now for booting a guest in paging mode with
>> memory < maxmem?
>
> xenpaging exits because XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE returns
> -EXDEV when PoD is detected.

OK.  So we have two options, as I see it, if someone starts a guest
with both xenpaging=yes and memory<maxmem:

* Refuse to build the domain and return an error.
* Figure out how to boot with memory<maxmem only with the pager.  I
guess this would involve building with half the memory, and telling
the pager that some pages are pre-paged out...?

If the second option is too much work before the release, we should go
with the first option.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:07:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVlz-0007TM-0d; Mon, 20 Feb 2012 16:07:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVlx-0007Sh-TV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:07:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329754042!15077403!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25971 invoked from network); 20 Feb 2012 16:07:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 16:07:23 -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 q1KG7D4L023410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 16:07: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
	q1KG7Bdp020183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 16:07:11 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
	q1KG79V3012413; Mon, 20 Feb 2012 10:07:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 08:07:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 840F24035D; Mon, 20 Feb 2012 11:03:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org
Date: Mon, 20 Feb 2012 11:01:26 -0500
Message-Id: <1329753687-29218-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
References: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090207.4F426FB4.0010,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] xen/setup: Remove redundant filtering of
	PTE masks.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

commit 7347b4082e55ac4a673f06a0a0ce25c37273c9ec "xen: Allow
unprivileged Xen domains to create iomap pages" added a redundant
line in the early bootup code to filter out the PTE. That
filtering is already done a bit earlier so this extra processing
is not required.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..7c44e1b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1204,10 +1204,6 @@ asmlinkage void __init xen_start_kernel(void)
 
 	pgd = (pgd_t *)xen_start_info->pt_base;
 
-	if (!xen_initial_domain())
-		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
-
-	__supported_pte_mask |= _PAGE_IOMAP;
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:07:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVlz-0007TM-0d; Mon, 20 Feb 2012 16:07:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVlx-0007Sh-TV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:07:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329754042!15077403!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25971 invoked from network); 20 Feb 2012 16:07:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 16:07:23 -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 q1KG7D4L023410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 16:07: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
	q1KG7Bdp020183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 16:07:11 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
	q1KG79V3012413; Mon, 20 Feb 2012 10:07:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 08:07:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 840F24035D; Mon, 20 Feb 2012 11:03:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org
Date: Mon, 20 Feb 2012 11:01:26 -0500
Message-Id: <1329753687-29218-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
References: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090207.4F426FB4.0010,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] xen/setup: Remove redundant filtering of
	PTE masks.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

commit 7347b4082e55ac4a673f06a0a0ce25c37273c9ec "xen: Allow
unprivileged Xen domains to create iomap pages" added a redundant
line in the early bootup code to filter out the PTE. That
filtering is already done a bit earlier so this extra processing
is not required.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..7c44e1b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1204,10 +1204,6 @@ asmlinkage void __init xen_start_kernel(void)
 
 	pgd = (pgd_t *)xen_start_info->pt_base;
 
-	if (!xen_initial_domain())
-		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
-
-	__supported_pte_mask |= _PAGE_IOMAP;
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 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.xensource.com>)
	id 1RzVm0-0007TY-Dh; Mon, 20 Feb 2012 16:07:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVly-0007Sk-HR
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:07:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329754042!15066284!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10586 invoked from network); 20 Feb 2012 16:07: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; 20 Feb 2012 16:07: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 q1KG7DwE032321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 16:07:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1KG7BHb020178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 16:07:11 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
	q1KG79gP001075; Mon, 20 Feb 2012 10:07:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 08:07:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7A85440359; Mon, 20 Feb 2012 11:03:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org
Date: Mon, 20 Feb 2012 11:01:25 -0500
Message-Id: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F426FB2.023D,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org
Subject: [Xen-devel] [PATCH] Disable PAT support when running under Xen (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The issue at hand is that any prolonged usage of radeon or nouveau driver
ends up corrupting the file system or we end up with mysterious crashes of
applications.

There are three ways of fixing it:
 a). A proper fix: https://lkml.org/lkml/2012/2/10/228 . I posted the same
   fix for 3.2 way back in December but it got nowhere. The recent posting
   has also been meet with silence. Not being happy with this laying
   around and corrupting folks file systems (and in my case my git tree):

 b). Disable PAT when run under Xen. At least until we get the a) moving
   or alternative solutions are found.

 c). Use the 'nopat' argument on the Linux command line (which is what
   this patch set (b) forces unconditionally) and has been recommended on the
   BZs for users.

In summary this patch set:
  - fixes corruption issues
  - makes graphic drivers not able to use Write-Combine - meaning you can't
    get super-fast performance using graphic drivers.

Konrad Rzeszutek Wilk (2):
      xen/setup: Remove redundant filtering of PTE masks.
      xen/pat: Disable PAT support for now.

 arch/x86/xen/enlighten.c |    6 ++----
 arch/x86/xen/mmu.c       |    8 ++++----
 2 files changed, 6 insertions(+), 8 deletions(-)


diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..4172af8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1141,7 +1141,9 @@ asmlinkage void __init xen_start_kernel(void)
 
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
+#if 0
 	if (!xen_initial_domain())
+#endif
 		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
 
 	__supported_pte_mask |= _PAGE_IOMAP;
@@ -1204,10 +1206,6 @@ asmlinkage void __init xen_start_kernel(void)
 
 	pgd = (pgd_t *)xen_start_info->pt_base;
 
-	if (!xen_initial_domain())
-		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
-
-	__supported_pte_mask |= _PAGE_IOMAP;
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 58a0e46..95c1cf6 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -415,13 +415,13 @@ static pteval_t iomap_pte(pteval_t 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;
 
@@ -463,7 +463,7 @@ void xen_set_pat(u64 pat)
 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
@@ -476,7 +476,7 @@ static pte_t xen_make_pte(pteval_t pte)
 		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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 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.xensource.com>)
	id 1RzVm0-0007TY-Dh; Mon, 20 Feb 2012 16:07:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVly-0007Sk-HR
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:07:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329754042!15066284!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10586 invoked from network); 20 Feb 2012 16:07: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; 20 Feb 2012 16:07: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 q1KG7DwE032321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 16:07:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1KG7BHb020178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 16:07:11 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
	q1KG79gP001075; Mon, 20 Feb 2012 10:07:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 08:07:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7A85440359; Mon, 20 Feb 2012 11:03:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org
Date: Mon, 20 Feb 2012 11:01:25 -0500
Message-Id: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F426FB2.023D,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org
Subject: [Xen-devel] [PATCH] Disable PAT support when running under Xen (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The issue at hand is that any prolonged usage of radeon or nouveau driver
ends up corrupting the file system or we end up with mysterious crashes of
applications.

There are three ways of fixing it:
 a). A proper fix: https://lkml.org/lkml/2012/2/10/228 . I posted the same
   fix for 3.2 way back in December but it got nowhere. The recent posting
   has also been meet with silence. Not being happy with this laying
   around and corrupting folks file systems (and in my case my git tree):

 b). Disable PAT when run under Xen. At least until we get the a) moving
   or alternative solutions are found.

 c). Use the 'nopat' argument on the Linux command line (which is what
   this patch set (b) forces unconditionally) and has been recommended on the
   BZs for users.

In summary this patch set:
  - fixes corruption issues
  - makes graphic drivers not able to use Write-Combine - meaning you can't
    get super-fast performance using graphic drivers.

Konrad Rzeszutek Wilk (2):
      xen/setup: Remove redundant filtering of PTE masks.
      xen/pat: Disable PAT support for now.

 arch/x86/xen/enlighten.c |    6 ++----
 arch/x86/xen/mmu.c       |    8 ++++----
 2 files changed, 6 insertions(+), 8 deletions(-)


diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..4172af8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1141,7 +1141,9 @@ asmlinkage void __init xen_start_kernel(void)
 
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
+#if 0
 	if (!xen_initial_domain())
+#endif
 		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
 
 	__supported_pte_mask |= _PAGE_IOMAP;
@@ -1204,10 +1206,6 @@ asmlinkage void __init xen_start_kernel(void)
 
 	pgd = (pgd_t *)xen_start_info->pt_base;
 
-	if (!xen_initial_domain())
-		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
-
-	__supported_pte_mask |= _PAGE_IOMAP;
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 58a0e46..95c1cf6 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -415,13 +415,13 @@ static pteval_t iomap_pte(pteval_t 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;
 
@@ -463,7 +463,7 @@ void xen_set_pat(u64 pat)
 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
@@ -476,7 +476,7 @@ static pte_t xen_make_pte(pteval_t pte)
 		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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:07:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVm3-0007UB-RW; Mon, 20 Feb 2012 16:07:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVm1-0007Sz-IS
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:07:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329754045!9857714!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18246 invoked from network); 20 Feb 2012 16:07:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 16:07:27 -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 q1KG7E6R023411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 16:07: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
	q1KG7BeZ029117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 16:07:12 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1KG79TT001076; Mon, 20 Feb 2012 10:07:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 08:07:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8D6914045E; Mon, 20 Feb 2012 11:03:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org
Date: Mon, 20 Feb 2012 11:01:27 -0500
Message-Id: <1329753687-29218-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
References: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F426FB4.0013,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/pat: Disable PAT support for now.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

[Pls also look at https://lkml.org/lkml/2012/2/10/228]

Using of PAT to change pages from WB to WC works quite nicely.
Changing it back to WB - not so much. The crux of the matter is
that the code that does this (__page_change_att_set_clr) has only
limited information so when it tries to the change it gets
the "raw" unfiltered information instead of the properly filtered one -
and the "raw" one tell it that PSE bit is on (while infact it
is not).  As a result when the PTE is set to be WB from WC, we get
tons of:

:WARNING: at arch/x86/xen/mmu.c:475 xen_make_pte+0x67/0xa0()
:Hardware name: HP xw4400 Workstation
.. snip..
:Pid: 27, comm: kswapd0 Tainted: G        W    3.2.2-1.fc16.x86_64 #1
:Call Trace:
: [<ffffffff8106dd1f>] warn_slowpath_common+0x7f/0xc0
: [<ffffffff8106dd7a>] warn_slowpath_null+0x1a/0x20
: [<ffffffff81005a17>] xen_make_pte+0x67/0xa0
: [<ffffffff810051bd>] __raw_callee_save_xen_make_pte+0x11/0x1e
: [<ffffffff81040e15>] ? __change_page_attr_set_clr+0x9d5/0xc00
: [<ffffffff8114c2e8>] ? __purge_vmap_area_lazy+0x158/0x1d0
: [<ffffffff8114cca5>] ? vm_unmap_aliases+0x175/0x190
: [<ffffffff81041168>] change_page_attr_set_clr+0x128/0x4c0
: [<ffffffff81041542>] set_pages_array_wb+0x42/0xa0
: [<ffffffff8100a9b2>] ? check_events+0x12/0x20
: [<ffffffffa0074d4c>] ttm_pages_put+0x1c/0x70 [ttm]
: [<ffffffffa0074e98>] ttm_page_pool_free+0xf8/0x180 [ttm]
: [<ffffffffa0074f78>] ttm_pool_mm_shrink+0x58/0x90 [ttm]
: [<ffffffff8112ba04>] shrink_slab+0x154/0x310
: [<ffffffff8112f17a>] balance_pgdat+0x4fa/0x6c0
: [<ffffffff8112f4b8>] kswapd+0x178/0x3d0
: [<ffffffff815df134>] ? __schedule+0x3d4/0x8c0
: [<ffffffff81090410>] ? remove_wait_queue+0x50/0x50
: [<ffffffff8112f340>] ? balance_pgdat+0x6c0/0x6c0
: [<ffffffff8108fb6c>] kthread+0x8c/0xa0

for every page. The fix for this is has been posted
and is https://lkml.org/lkml/2012/2/10/228
"x86/cpa: Use pte_attrs instead of pte_flags on CPA/set_p.._wb/wc operations."
along with a detailed description of the problem and solution.

But since that posting has gone nowhere I am proposing
this band-aid solution so that at least users don't get
the page corruption (the pages that are WC don't get changed to WB
and end up being recycled for filesystem or other things causing
mysterious crashes).

The negative impact of this patch is that users of WC flag
(which are InfiniBand, radeon, nouveau drivers) won't be able
to set that flag - so they are going to see performance degradation.
But stability is more important here.

Fixes RH BZ# 742032, 787403, and 745574
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    2 ++
 arch/x86/xen/mmu.c       |    8 ++++----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 7c44e1b..4172af8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1141,7 +1141,9 @@ asmlinkage void __init xen_start_kernel(void)
 
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
+#if 0
 	if (!xen_initial_domain())
+#endif
 		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
 
 	__supported_pte_mask |= _PAGE_IOMAP;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 58a0e46..95c1cf6 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -415,13 +415,13 @@ static pteval_t iomap_pte(pteval_t 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;
 
@@ -463,7 +463,7 @@ void xen_set_pat(u64 pat)
 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
@@ -476,7 +476,7 @@ static pte_t xen_make_pte(pteval_t pte)
 		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
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:07:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:07:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVm3-0007UB-RW; Mon, 20 Feb 2012 16:07:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzVm1-0007Sz-IS
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:07:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329754045!9857714!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18246 invoked from network); 20 Feb 2012 16:07:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 16:07:27 -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 q1KG7E6R023411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 16:07: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
	q1KG7BeZ029117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 16:07:12 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1KG79TT001076; Mon, 20 Feb 2012 10:07:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 08:07:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8D6914045E; Mon, 20 Feb 2012 11:03:56 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, x86@kernel.org
Date: Mon, 20 Feb 2012 11:01:27 -0500
Message-Id: <1329753687-29218-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
References: <1329753687-29218-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F426FB4.0013,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/pat: Disable PAT support for now.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

[Pls also look at https://lkml.org/lkml/2012/2/10/228]

Using of PAT to change pages from WB to WC works quite nicely.
Changing it back to WB - not so much. The crux of the matter is
that the code that does this (__page_change_att_set_clr) has only
limited information so when it tries to the change it gets
the "raw" unfiltered information instead of the properly filtered one -
and the "raw" one tell it that PSE bit is on (while infact it
is not).  As a result when the PTE is set to be WB from WC, we get
tons of:

:WARNING: at arch/x86/xen/mmu.c:475 xen_make_pte+0x67/0xa0()
:Hardware name: HP xw4400 Workstation
.. snip..
:Pid: 27, comm: kswapd0 Tainted: G        W    3.2.2-1.fc16.x86_64 #1
:Call Trace:
: [<ffffffff8106dd1f>] warn_slowpath_common+0x7f/0xc0
: [<ffffffff8106dd7a>] warn_slowpath_null+0x1a/0x20
: [<ffffffff81005a17>] xen_make_pte+0x67/0xa0
: [<ffffffff810051bd>] __raw_callee_save_xen_make_pte+0x11/0x1e
: [<ffffffff81040e15>] ? __change_page_attr_set_clr+0x9d5/0xc00
: [<ffffffff8114c2e8>] ? __purge_vmap_area_lazy+0x158/0x1d0
: [<ffffffff8114cca5>] ? vm_unmap_aliases+0x175/0x190
: [<ffffffff81041168>] change_page_attr_set_clr+0x128/0x4c0
: [<ffffffff81041542>] set_pages_array_wb+0x42/0xa0
: [<ffffffff8100a9b2>] ? check_events+0x12/0x20
: [<ffffffffa0074d4c>] ttm_pages_put+0x1c/0x70 [ttm]
: [<ffffffffa0074e98>] ttm_page_pool_free+0xf8/0x180 [ttm]
: [<ffffffffa0074f78>] ttm_pool_mm_shrink+0x58/0x90 [ttm]
: [<ffffffff8112ba04>] shrink_slab+0x154/0x310
: [<ffffffff8112f17a>] balance_pgdat+0x4fa/0x6c0
: [<ffffffff8112f4b8>] kswapd+0x178/0x3d0
: [<ffffffff815df134>] ? __schedule+0x3d4/0x8c0
: [<ffffffff81090410>] ? remove_wait_queue+0x50/0x50
: [<ffffffff8112f340>] ? balance_pgdat+0x6c0/0x6c0
: [<ffffffff8108fb6c>] kthread+0x8c/0xa0

for every page. The fix for this is has been posted
and is https://lkml.org/lkml/2012/2/10/228
"x86/cpa: Use pte_attrs instead of pte_flags on CPA/set_p.._wb/wc operations."
along with a detailed description of the problem and solution.

But since that posting has gone nowhere I am proposing
this band-aid solution so that at least users don't get
the page corruption (the pages that are WC don't get changed to WB
and end up being recycled for filesystem or other things causing
mysterious crashes).

The negative impact of this patch is that users of WC flag
(which are InfiniBand, radeon, nouveau drivers) won't be able
to set that flag - so they are going to see performance degradation.
But stability is more important here.

Fixes RH BZ# 742032, 787403, and 745574
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    2 ++
 arch/x86/xen/mmu.c       |    8 ++++----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 7c44e1b..4172af8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1141,7 +1141,9 @@ asmlinkage void __init xen_start_kernel(void)
 
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
+#if 0
 	if (!xen_initial_domain())
+#endif
 		__supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
 
 	__supported_pte_mask |= _PAGE_IOMAP;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 58a0e46..95c1cf6 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -415,13 +415,13 @@ static pteval_t iomap_pte(pteval_t 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;
 
@@ -463,7 +463,7 @@ void xen_set_pat(u64 pat)
 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
@@ -476,7 +476,7 @@ static pte_t xen_make_pte(pteval_t pte)
 		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
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:09:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVnJ-0007kj-BJ; Mon, 20 Feb 2012 16:08:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzVnI-0007k4-HQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:08:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329754126!14138095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30249 invoked from network); 20 Feb 2012 16:08:46 -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;
	20 Feb 2012 16:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:08:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:08:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVn5-00050y-4M; Mon, 20 Feb 2012 16:08:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVn3-0007jT-Cl;
	Mon, 20 Feb 2012 16:08:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28675.613981.325668@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:08:35 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
	<alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing"):
> On Mon, 16 Jan 2012, Roger Pau Monne wrote:
> > Qemu was not reacting when setting xenstore state of a device to
> > XenbusStateClosing (5). This patch makes qemu react to this state and
> > close the appropiate device.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> Please send a version of this patch against upstream qemu and CC
> qemu-devel as well.

We are trying to avoid adding new code and new features to
qemu-xen-unstable.  Can you explain what the practical impact of this
patch is ?  When is it needed and what doesn't work without it ?

Has the thing which doesn't work without it ever worked before destroying

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:09:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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.xensource.com>)
	id 1RzVnJ-0007kj-BJ; Mon, 20 Feb 2012 16:08:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzVnI-0007k4-HQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:08:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329754126!14138095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30249 invoked from network); 20 Feb 2012 16:08:46 -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;
	20 Feb 2012 16:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:08:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:08:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVn5-00050y-4M; Mon, 20 Feb 2012 16:08:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVn3-0007jT-Cl;
	Mon, 20 Feb 2012 16:08:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28675.613981.325668@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:08:35 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
	<alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing"):
> On Mon, 16 Jan 2012, Roger Pau Monne wrote:
> > Qemu was not reacting when setting xenstore state of a device to
> > XenbusStateClosing (5). This patch makes qemu react to this state and
> > close the appropiate device.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> Please send a version of this patch against upstream qemu and CC
> qemu-devel as well.

We are trying to avoid adding new code and new features to
qemu-xen-unstable.  Can you explain what the practical impact of this
patch is ?  When is it needed and what doesn't work without it ?

Has the thing which doesn't work without it ever worked before destroying

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVps-00085z-Kk; Mon, 20 Feb 2012 16:11:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RzVpr-00084u-DU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:11:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329754282!10051269!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20172 invoked from network); 20 Feb 2012 16:11:23 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-10.tower-21.messagelabs.com with SMTP;
	20 Feb 2012 16:11:23 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 1F96CD347C5;
	Mon, 20 Feb 2012 17:11:22 +0100 (CET)
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 RNUtZu6+kHXh; Mon, 20 Feb 2012 17:11:13 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 35763D34180;
	Mon, 20 Feb 2012 17:11:13 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 17:11:11 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
In-Reply-To: <CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201202201711.11807.tobias.geiger@vido.info>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Anthony

thanks for that hint.

I checked out a fresh xen-unstable via hg, compiled it using "QEMU=upstream" , 
checked out qemu.git from where you mentioned and used the resulting qemu-
system-x86_64 binary as "device_model_override" . so far so good.

My Domu (Win7_64) boots fine, but 2 of my 6 passed-through pcidevices dont get 
passed through at all:

libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error 
message from QMP server: Device 'xen-pci-passthrough' could not be initialized
libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error 
message from QMP server: Device 'xen-pci-passthrough' could not be initialized


The other 4 PCI-Ids (USB Controller) get passed through, but the USB-Devices 
attached to them are "Not Working" according to Windows Device-Manager.

All Devices worked with the old qemu-dm (traditional).

Anything i can do to debug this further?

Greetings
Tobias


Am Montag, 20. Februar 2012, 12:31:52 schrieb Anthony PERARD:
> On Mon, Feb 20, 2012 at 10:51, Tobias Geiger <tobias.geiger@vido.info> 
wrote:
> > i wanted to test these patches against
> > http://xenbits.xensource.com/xen-unstable.hg but it seems to check out an
> > outdated version of upstream-qemu, even with "QEMU=upstream".
> > 
> > Where can i check out the qemu-upstream version to which these patches
> > apply?
> 
> Hi,
> 
> http://git.qemu.org/git/qemu.git or git://git.qemu.org/qemu.git
> 
> Regards,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVps-00085z-Kk; Mon, 20 Feb 2012 16:11:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RzVpr-00084u-DU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:11:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329754282!10051269!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20172 invoked from network); 20 Feb 2012 16:11:23 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-10.tower-21.messagelabs.com with SMTP;
	20 Feb 2012 16:11:23 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 1F96CD347C5;
	Mon, 20 Feb 2012 17:11:22 +0100 (CET)
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 RNUtZu6+kHXh; Mon, 20 Feb 2012 17:11:13 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 35763D34180;
	Mon, 20 Feb 2012 17:11:13 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 20 Feb 2012 17:11:11 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
In-Reply-To: <CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201202201711.11807.tobias.geiger@vido.info>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Anthony

thanks for that hint.

I checked out a fresh xen-unstable via hg, compiled it using "QEMU=upstream" , 
checked out qemu.git from where you mentioned and used the resulting qemu-
system-x86_64 binary as "device_model_override" . so far so good.

My Domu (Win7_64) boots fine, but 2 of my 6 passed-through pcidevices dont get 
passed through at all:

libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error 
message from QMP server: Device 'xen-pci-passthrough' could not be initialized
libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error 
message from QMP server: Device 'xen-pci-passthrough' could not be initialized


The other 4 PCI-Ids (USB Controller) get passed through, but the USB-Devices 
attached to them are "Not Working" according to Windows Device-Manager.

All Devices worked with the old qemu-dm (traditional).

Anything i can do to debug this further?

Greetings
Tobias


Am Montag, 20. Februar 2012, 12:31:52 schrieb Anthony PERARD:
> On Mon, Feb 20, 2012 at 10:51, Tobias Geiger <tobias.geiger@vido.info> 
wrote:
> > i wanted to test these patches against
> > http://xenbits.xensource.com/xen-unstable.hg but it seems to check out an
> > outdated version of upstream-qemu, even with "QEMU=upstream".
> > 
> > Where can i check out the qemu-upstream version to which these patches
> > apply?
> 
> Hi,
> 
> http://git.qemu.org/git/qemu.git or git://git.qemu.org/qemu.git
> 
> Regards,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:12:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVqR-0008Cu-2k; Mon, 20 Feb 2012 16:12:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzVqP-0008CW-Ph
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:12:05 +0000
Received: from [85.158.139.83:33792] by server-12.bemta-5.messagelabs.com id
	E1/6D-24595-5D0724F4; Mon, 20 Feb 2012 16:12:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329754324!15778805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15859 invoked from network); 20 Feb 2012 16:12:04 -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 Feb 2012 16:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:12:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:12:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVqN-000527-JW; Mon, 20 Feb 2012 16:12:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVqN-0000Gh-GV;
	Mon, 20 Feb 2012 16:12:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28883.225727.793581@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:12:03 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ce095edc4f970b7b1bd6.1326290178@probook.site>
References: <ce095edc4f970b7b1bd6.1326290178@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: mmap guest pages read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: mmap guest pages read-only"):
> xenpaging: mmap guest pages read-only
> 
> xenpaging does not write to the gfn, so map the gfn to page-out in
> read-only mode.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I adjusted it to cope with whitespace changes in xenpaging.c.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:12:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVqR-0008Cu-2k; Mon, 20 Feb 2012 16:12:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzVqP-0008CW-Ph
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:12:05 +0000
Received: from [85.158.139.83:33792] by server-12.bemta-5.messagelabs.com id
	E1/6D-24595-5D0724F4; Mon, 20 Feb 2012 16:12:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329754324!15778805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15859 invoked from network); 20 Feb 2012 16:12:04 -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 Feb 2012 16:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:12:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:12:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVqN-000527-JW; Mon, 20 Feb 2012 16:12:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVqN-0000Gh-GV;
	Mon, 20 Feb 2012 16:12:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28883.225727.793581@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:12:03 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ce095edc4f970b7b1bd6.1326290178@probook.site>
References: <ce095edc4f970b7b1bd6.1326290178@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: mmap guest pages read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: mmap guest pages read-only"):
> xenpaging: mmap guest pages read-only
> 
> xenpaging does not write to the gfn, so map the gfn to page-out in
> read-only mode.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I adjusted it to cope with whitespace changes in xenpaging.c.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:13:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVrt-0008Tw-QC; Mon, 20 Feb 2012 16:13: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 1RzVrs-0008Te-0n
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:13:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329754363!54999077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31690 invoked from network); 20 Feb 2012 16:12:43 -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 Feb 2012 16:12:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:13:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:13:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVrq-00053E-HT; Mon, 20 Feb 2012 16:13:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVrq-0000I6-G5;
	Mon, 20 Feb 2012 16:13:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28974.328634.111629@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:13:34 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
References: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	andres@gridcentric.ca, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Testing for mem event ring management
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH] Testing for mem event ring management"):
> This is example code, not meant for tree consumption. So
> that others can run tests on the ring management bits.

Is this supposed to apply to tip, and build ?

memoper.c:48: error: expected specifier-qualifier-list before 'mem_event_t'
memoper.c: In function 'wait_for_event_or_timeout':
memoper.c:66: error: 'memaccess_t' has no member named 'mem_event'
memoper.c:99: error: 'memaccess_t' has no member named 'mem_event'
...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Feb 20 16:13:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RzVrt-0008Tw-QC; Mon, 20 Feb 2012 16:13: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 1RzVrs-0008Te-0n
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:13:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329754363!54999077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31690 invoked from network); 20 Feb 2012 16:12:43 -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 Feb 2012 16:12:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:13:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:13:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVrq-00053E-HT; Mon, 20 Feb 2012 16:13:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVrq-0000I6-G5;
	Mon, 20 Feb 2012 16:13:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.28974.328634.111629@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:13:34 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
References: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	andres@gridcentric.ca, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Testing for mem event ring management
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH] Testing for mem event ring management"):
> This is example code, not meant for tree consumption. So
> that others can run tests on the ring management bits.

Is this supposed to apply to tip, and build ?

memoper.c:48: error: expected specifier-qualifier-list before 'mem_event_t'
memoper.c: In function 'wait_for_event_or_timeout':
memoper.c:66: error: 'memaccess_t' has no member named 'mem_event'
memoper.c:99: error: 'memaccess_t' has no member named 'mem_event'
...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW2Z-0000aQ-4U; Mon, 20 Feb 2012 16:24:39 +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 1RzW2Y-0000aG-1D
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:24:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329755006!61828659!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18657 invoked from network); 20 Feb 2012 16:23:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:23:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:24:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:24:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzW0A-0005VA-4F; Mon, 20 Feb 2012 16:22:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzW0A-0000pd-1O;
	Mon, 20 Feb 2012 16:22:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.29490.5277.242985@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:22:10 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config
	space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jean Guyader writes ("[Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config space"):
> Expose more host bridge config space value to make
> the driver happy for all the different revisions
> of the device.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW2Z-0000aQ-4U; Mon, 20 Feb 2012 16:24:39 +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 1RzW2Y-0000aG-1D
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:24:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329755006!61828659!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18657 invoked from network); 20 Feb 2012 16:23:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:23:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:24:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:24:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzW0A-0005VA-4F; Mon, 20 Feb 2012 16:22:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzW0A-0000pd-1O;
	Mon, 20 Feb 2012 16:22:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.29490.5277.242985@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:22:10 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config
	space
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jean Guyader writes ("[Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config space"):
> Expose more host bridge config space value to make
> the driver happy for all the different revisions
> of the device.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:25:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW2x-0000cC-Hc; Mon, 20 Feb 2012 16:25:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzW2w-0000bm-8s
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:25:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329755095!15457513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32351 invoked from network); 20 Feb 2012 16:24:56 -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;
	20 Feb 2012 16:24:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:24:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:24:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVy8-0005P7-Ry; Mon, 20 Feb 2012 16:20:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVy8-0000Ia-Q3;
	Mon, 20 Feb 2012 16:20:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.29364.583732.682392@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:20:04 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1b95948228b84c986764.1326548473@loki.upc.es>
References: <1b95948228b84c986764.1326548473@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and
 set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and set it to 5 at device_remove"):
> libxl: Atomicaly check backend state and set it to 5 at device_remove
> 
> libxl__device_remove was setting backend state to 5, which could
> create a race condition, since the previous check for state != 4 and
> setting state to 5 was not done inside the same transaction, so the
> kernel could change the state to 6 in the space between the check for
> state != 4 and setting it to 5.
> 
> The state != 4 check and setting it to 5 should happen in the same
> transaction, to assure that nobody is modifying it behind our back.

This looks like a correct fix to me.  However, the code in libxl has
changed now: libxl__device_remove is now
libxl__initiate_device_remove.

Also can you please arrange to use "goto out" style error handling ?

Eg something like:

 +     xs_transaction_t t = 0;
    ...
    out:
 +     if (t) xs_transaction_end(ctx->xsh, t, 0);
       device_remove_cleanup(gc, aorm);

TBH the meat of this function is in general rather unreconstructed.
Lots of unchecked xs_write etc.  I don't know if you want to fix that
while you're there.  I wimped out on doing that in my recent event
series.  Up to you.

Really we should have some kind of more cooked xenstore transaction
arrangements, probably in the gc, and certainly with a suitable loop
macro so we can say:
  IN_XENSTORE_TRANSACTION {
      read, write, etc.
  }
But that's a task for another day and it's not on the critical path
for 4.2 so I'm putting it off.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:25:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW2x-0000cC-Hc; Mon, 20 Feb 2012 16:25:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzW2w-0000bm-8s
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:25:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329755095!15457513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32351 invoked from network); 20 Feb 2012 16:24:56 -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;
	20 Feb 2012 16:24:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:24:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:24:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzVy8-0005P7-Ry; Mon, 20 Feb 2012 16:20:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzVy8-0000Ia-Q3;
	Mon, 20 Feb 2012 16:20:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.29364.583732.682392@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:20:04 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1b95948228b84c986764.1326548473@loki.upc.es>
References: <1b95948228b84c986764.1326548473@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and
 set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and set it to 5 at device_remove"):
> libxl: Atomicaly check backend state and set it to 5 at device_remove
> 
> libxl__device_remove was setting backend state to 5, which could
> create a race condition, since the previous check for state != 4 and
> setting state to 5 was not done inside the same transaction, so the
> kernel could change the state to 6 in the space between the check for
> state != 4 and setting it to 5.
> 
> The state != 4 check and setting it to 5 should happen in the same
> transaction, to assure that nobody is modifying it behind our back.

This looks like a correct fix to me.  However, the code in libxl has
changed now: libxl__device_remove is now
libxl__initiate_device_remove.

Also can you please arrange to use "goto out" style error handling ?

Eg something like:

 +     xs_transaction_t t = 0;
    ...
    out:
 +     if (t) xs_transaction_end(ctx->xsh, t, 0);
       device_remove_cleanup(gc, aorm);

TBH the meat of this function is in general rather unreconstructed.
Lots of unchecked xs_write etc.  I don't know if you want to fix that
while you're there.  I wimped out on doing that in my recent event
series.  Up to you.

Really we should have some kind of more cooked xenstore transaction
arrangements, probably in the gc, and certainly with a suitable loop
macro so we can say:
  IN_XENSTORE_TRANSACTION {
      read, write, etc.
  }
But that's a task for another day and it's not on the critical path
for 4.2 so I'm putting it off.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW4r-0000lR-3e; Mon, 20 Feb 2012 16:27:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RzW4p-0000kt-2o
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:26:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329755211!14129537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29577 invoked from network); 20 Feb 2012 16:26:52 -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 Feb 2012 16:26:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:26:51 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 16:26:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120217191902.GD20584@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
	<1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<20120217191902.GD20584@phenom.dumpdata.com>
Date: Mon, 20 Feb 2012 16:26:03 +0000
Message-ID: <1329755163.2203.352.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-17 at 19:19 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > Hmm, this kind of stuff should be discussed on lkml.
> > 
> > I doubt we want yet another memory allocator, with a global lock
> > (contended), and no NUMA properties.
> 
> That should be fixed. Are there any existing memory pools that could be used
> instead? I (And I think everybody) is all for using the existing APIs if  they
> can do the job. I was lookign a bit at the dmapool code, but that requires something
> we don't have  - the 'struct device'. We could manufacture a fake one, but that just
> stinks of hack.
> 

I've been thinking about this for a long time, so any recommendation is
welcomed.

It is not my intention to write yet another memory allocator. What I
need is a data structure to track pages owned by netback.

Let me state the requirements of this data structure:
     1. limits overall memory used by all vifs (this could also be met
        by the underlying allocator)
     2. provides function to tell whether a particular page is mapped
        from foreign domain -- is_in_pool() is a surrogate for that
     3. provides function to back-reference owner vif of the page

To achieve requirement 2, page pool manipulates page->mapping field. To
achieve requirement 3, page pool maintains idx <-> vif relationship
internally.

I think I can use mempool internally for page allocation. But I still
need a data structure to meet other requirements.

> It [pagepool] also should use the shrinker API I think.

This is doable, but let's make everybody happy with the page pool design
and implementation first.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW4r-0000lR-3e; Mon, 20 Feb 2012 16:27:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RzW4p-0000kt-2o
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:26:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329755211!14129537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29577 invoked from network); 20 Feb 2012 16:26:52 -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 Feb 2012 16:26:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:26:51 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 16:26:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120217191902.GD20584@phenom.dumpdata.com>
References: <1328201363-13915-1-git-send-email-wei.liu2@citrix.com>
	<1328201363-13915-2-git-send-email-wei.liu2@citrix.com>
	<1328203565.13262.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
	<20120217191902.GD20584@phenom.dumpdata.com>
Date: Mon, 20 Feb 2012 16:26:03 +0000
Message-ID: <1329755163.2203.352.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [Xen-devel] [RFC PATCH V4 01/13] netback: page pool version 1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-17 at 19:19 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > Hmm, this kind of stuff should be discussed on lkml.
> > 
> > I doubt we want yet another memory allocator, with a global lock
> > (contended), and no NUMA properties.
> 
> That should be fixed. Are there any existing memory pools that could be used
> instead? I (And I think everybody) is all for using the existing APIs if  they
> can do the job. I was lookign a bit at the dmapool code, but that requires something
> we don't have  - the 'struct device'. We could manufacture a fake one, but that just
> stinks of hack.
> 

I've been thinking about this for a long time, so any recommendation is
welcomed.

It is not my intention to write yet another memory allocator. What I
need is a data structure to track pages owned by netback.

Let me state the requirements of this data structure:
     1. limits overall memory used by all vifs (this could also be met
        by the underlying allocator)
     2. provides function to tell whether a particular page is mapped
        from foreign domain -- is_in_pool() is a surrogate for that
     3. provides function to back-reference owner vif of the page

To achieve requirement 2, page pool manipulates page->mapping field. To
achieve requirement 3, page pool maintains idx <-> vif relationship
internally.

I think I can use mempool internally for page allocation. But I still
need a data structure to meet other requirements.

> It [pagepool] also should use the shrinker API I think.

This is doable, but let's make everybody happy with the page pool design
and implementation first.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:29:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW6j-0000uo-K4; Mon, 20 Feb 2012 16:28:57 +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 1RzW6i-0000ue-Rf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:28:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329755270!61829493!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3974 invoked from network); 20 Feb 2012 16:27:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817940"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:28:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:28:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzW6g-0005j3-Tl; Mon, 20 Feb 2012 16:28:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzW6g-0000qz-SV;
	Mon, 20 Feb 2012 16:28:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.29894.869249.474721@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:28:54 +0000
To: Doug Magee <djmagee@mageenet.net>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20254.55041.872764.353017@mariner.uk.xensource.com>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
	<6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
	<20254.55041.872764.353017@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is
 assignable before adding to domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is assignable before adding to domain"):
> Doug Magee writes ("[PATCH 2 of 2] libxl_pci: verify device is assignable before adding to domain"):
> > Previously, libxl__device_pci_add only checked the device to be added against
> > the list of currently assigned devices.  This patch changes the behavior to
> > check that the device to be assigned is in the list of assignable devices,
> > which only includes those owned by pciback and not assigned to another domain.
> ...
> > +    libxl_device_pci *assignable;
> > +    int num_assignable, i, rc;
> ...
> > +    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
> > +
> 
> What about failure ?  libxl_device_pci_list_assignable might return
> NULL on failure, I think.  So you need to add a check for that.

Yes.

> And in that case it won't assign to num_assignable either, leading to
> an uninitialised variable use and possible crash in out.  I think you
> should initialise assignable and num_assignable to 0 to avoid this.

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:29:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzW6j-0000uo-K4; Mon, 20 Feb 2012 16:28:57 +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 1RzW6i-0000ue-Rf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:28:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329755270!61829493!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3974 invoked from network); 20 Feb 2012 16:27:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10817940"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:28:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:28:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzW6g-0005j3-Tl; Mon, 20 Feb 2012 16:28:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzW6g-0000qz-SV;
	Mon, 20 Feb 2012 16:28:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.29894.869249.474721@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:28:54 +0000
To: Doug Magee <djmagee@mageenet.net>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20254.55041.872764.353017@mariner.uk.xensource.com>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
	<6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
	<20254.55041.872764.353017@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is
 assignable before adding to domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is assignable before adding to domain"):
> Doug Magee writes ("[PATCH 2 of 2] libxl_pci: verify device is assignable before adding to domain"):
> > Previously, libxl__device_pci_add only checked the device to be added against
> > the list of currently assigned devices.  This patch changes the behavior to
> > check that the device to be assigned is in the list of assignable devices,
> > which only includes those owned by pciback and not assigned to another domain.
> ...
> > +    libxl_device_pci *assignable;
> > +    int num_assignable, i, rc;
> ...
> > +    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
> > +
> 
> What about failure ?  libxl_device_pci_list_assignable might return
> NULL on failure, I think.  So you need to add a check for that.

Yes.

> And in that case it won't assign to num_assignable either, leading to
> an uninitialised variable use and possible crash in out.  I think you
> should initialise assignable and num_assignable to 0 to avoid this.

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:36:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWDg-0001HT-Lh; Mon, 20 Feb 2012 16:36:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWDe-0001HO-VY
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:36:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329755760!14130862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29800 invoked from network); 20 Feb 2012 16:36:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:36:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10818162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:35:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 16:35:59 +0000
Message-ID: <1329755758.3990.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 16:35:58 +0000
In-Reply-To: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> This is necessary to handle nested traps to the hypervisor more than one deep.

A sort of corollary to this patch is the following.

The situation with the LR register when in hyp mode is a bit odd, since
this is normally a banked register but for hyp mode it actually accesses
LR_usr instead.

However, although I think the following is correct I'm not sure if it is
useful to combine LR_usr and LR like this -- in particular I fear it
might be more confusing than helpful. Making the return-to-user case a
proper superset of return-to-hypervisor (as is the case on the save
path) is nice though.

What do people think?

8<---------------------------------------------------------------

>From 3132c2976ae4c83d6d9b94ad80ee04c4880f13da Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 20 Feb 2012 15:07:09 +0000
Subject: [PATCH] arm: lr register in hyp mode is really LR_usr.

Save and restore it in the same way for both hypervisor and user stack frames
rather than saving both individually in the user stack frame.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/entry.S          |   14 ++------------
 xen/include/public/arch-arm.h |   15 ++++++++++++---
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 36f1119..0e85c3c 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -29,8 +29,6 @@
 	blne save_guest_regs
 
 save_guest_regs:
-	ldr r11, [sp, #UREGS_lr]
-	str r11, [sp, #UREGS_LR_usr]
 	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
 	str r11, [sp, #UREGS_sp]
 	SAVE_ONE_BANKED(SP_usr)
@@ -78,15 +76,11 @@ ENTRY(return_from_trap)
 	and r11, #PSR_MODE_MASK
 	cmp r11, #PSR_MODE_HYP
 	beq return_to_hypervisor
-
+	/* Fall thru */
 ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
 	bl leave_hypervisor_tail
-	ldr r11, [sp, #UREGS_pc]
-	msr ELR_hyp, r11
-	ldr r11, [sp, #UREGS_cpsr]
-	msr SPSR_hyp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	RESTORE_BANKED(svc)
 	RESTORE_BANKED(abt)
@@ -95,11 +89,7 @@ ENTRY(return_to_guest)
 	RESTORE_BANKED(fiq)
 	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
 	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
-	ldr lr, [sp, #UREGS_LR_usr]
-	pop {r0-r12}
-	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
-	eret
-
+	/* Fall thru */
 ENTRY(return_to_hypervisor)
 	ldr lr, [sp, #UREGS_lr]
 	ldr r11, [sp, #UREGS_pc]
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e3d5c08..edb78b4 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -63,7 +63,12 @@ struct cpu_user_regs
     uint32_t r12;
 
     uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
-    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+        uint32_t lr_usr;
+    };
 
     uint32_t pc; /* Return IP */
     uint32_t cpsr; /* Return mode */
@@ -73,10 +78,14 @@ struct cpu_user_regs
 
     uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
 
-    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
-    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
 
     uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
 };
 typedef struct cpu_user_regs cpu_user_regs_t;
 DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:36:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWDg-0001HT-Lh; Mon, 20 Feb 2012 16:36:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWDe-0001HO-VY
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:36:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329755760!14130862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29800 invoked from network); 20 Feb 2012 16:36:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:36:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10818162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:35:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 16:35:59 +0000
Message-ID: <1329755758.3990.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 16:35:58 +0000
In-Reply-To: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> This is necessary to handle nested traps to the hypervisor more than one deep.

A sort of corollary to this patch is the following.

The situation with the LR register when in hyp mode is a bit odd, since
this is normally a banked register but for hyp mode it actually accesses
LR_usr instead.

However, although I think the following is correct I'm not sure if it is
useful to combine LR_usr and LR like this -- in particular I fear it
might be more confusing than helpful. Making the return-to-user case a
proper superset of return-to-hypervisor (as is the case on the save
path) is nice though.

What do people think?

8<---------------------------------------------------------------

>From 3132c2976ae4c83d6d9b94ad80ee04c4880f13da Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 20 Feb 2012 15:07:09 +0000
Subject: [PATCH] arm: lr register in hyp mode is really LR_usr.

Save and restore it in the same way for both hypervisor and user stack frames
rather than saving both individually in the user stack frame.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/entry.S          |   14 ++------------
 xen/include/public/arch-arm.h |   15 ++++++++++++---
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
index 36f1119..0e85c3c 100644
--- a/xen/arch/arm/entry.S
+++ b/xen/arch/arm/entry.S
@@ -29,8 +29,6 @@
 	blne save_guest_regs
 
 save_guest_regs:
-	ldr r11, [sp, #UREGS_lr]
-	str r11, [sp, #UREGS_LR_usr]
 	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
 	str r11, [sp, #UREGS_sp]
 	SAVE_ONE_BANKED(SP_usr)
@@ -78,15 +76,11 @@ ENTRY(return_from_trap)
 	and r11, #PSR_MODE_MASK
 	cmp r11, #PSR_MODE_HYP
 	beq return_to_hypervisor
-
+	/* Fall thru */
 ENTRY(return_to_guest)
 	mov r11, sp
 	bic sp, #7 /* Align the stack pointer */
 	bl leave_hypervisor_tail
-	ldr r11, [sp, #UREGS_pc]
-	msr ELR_hyp, r11
-	ldr r11, [sp, #UREGS_cpsr]
-	msr SPSR_hyp, r11
 	RESTORE_ONE_BANKED(SP_usr)
 	RESTORE_BANKED(svc)
 	RESTORE_BANKED(abt)
@@ -95,11 +89,7 @@ ENTRY(return_to_guest)
 	RESTORE_BANKED(fiq)
 	RESTORE_ONE_BANKED(R8_fiq); RESTORE_ONE_BANKED(R9_fiq); RESTORE_ONE_BANKED(R10_fiq)
 	RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
-	ldr lr, [sp, #UREGS_LR_usr]
-	pop {r0-r12}
-	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
-	eret
-
+	/* Fall thru */
 ENTRY(return_to_hypervisor)
 	ldr lr, [sp, #UREGS_lr]
 	ldr r11, [sp, #UREGS_pc]
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e3d5c08..edb78b4 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -63,7 +63,12 @@ struct cpu_user_regs
     uint32_t r12;
 
     uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
-    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+        uint32_t lr_usr;
+    };
 
     uint32_t pc; /* Return IP */
     uint32_t cpsr; /* Return mode */
@@ -73,10 +78,14 @@ struct cpu_user_regs
 
     uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
 
-    uint32_t sp_usr, sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
-    uint32_t lr_usr, lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_svc, sp_abt, sp_und, sp_irq, sp_fiq;
+    uint32_t lr_svc, lr_abt, lr_und, lr_irq, lr_fiq;
 
     uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
 };
 typedef struct cpu_user_regs cpu_user_regs_t;
 DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:45:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzWMP-0001Sb-B2; Mon, 20 Feb 2012 16:45:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWMO-0001SQ-3P
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:45:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329756301!15459905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25267 invoked from network); 20 Feb 2012 16:45:02 -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;
	20 Feb 2012 16:45:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10818433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:45:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 16:45:01 +0000
Message-ID: <1329756300.3990.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Hook <matthew.hook@otoy.com>
Date: Mon, 20 Feb 2012 16:45:00 +0000
In-Reply-To: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
References: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-17 at 22:56 +0000, Matthew Hook wrote:
> I think this is a bug in the xl toolchain.

I agree.

Which version of Xen are you running? There have been various fixes to
the stuff in xen-unstable but from your error message (which doesn't
appear in the unstable code base AFAICT) I guess you are running 4.1.
Are you able to try unstable?

> lspci -s 0000:12:0.*
> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> 12:00.1 Audio device: ATI Technologies Inc Device aa80
> 
> sudo xm pci-list-assignable-devices

NB: it is not recommended to mix and match xm and xl. 

> 0000:13:00.0
> 0000:13:00.1
> 0000:12:00.0
> 0000:12:00.1
> 
> So there is a multi-function device (actually one ASIC of a AMD Radeon
> 6990 card).
> It has two function addresses 0 = Display controller, 1 = Audio Device.
> 
> However when running xl create where the line for pci is of the form
> pci=['12:00.*']
> Where * means pass through all devices, you get an error as below.
> 
> Parsing config file xenwin7-1.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->0000000000179830
>   TOTAL:         0000000000000000->000000007f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000003fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device
> 0:12:0.70 is not assignable
> 
> There is no function 70 on that device.

The * turns into a "LIBXL_PCI_FUNC_ALL (~0U)" in the internal
represenation, I bet this is some sort unhelpful and confusing of
formatting snafu related to that.

> In relation to that, the BDF documentation
> (http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
> you can specify
> the extended BDF notation on your kernel boot line in grub.  i.e.
> xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
> the kernel log.

That is the old wiki, the new page seems to be
http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation -- does this
still give you that impression? Please feel free to update to clarify.

> Actually, if you look at the code for pci_stub.c in the linux kernel
> (at least for Jeremy branch 2.6.32.48), extended BDF is not supported.

Right, I think that wiki page is trying to refer only to the notation
used by the toolstack. I imagine that could be clearer.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:45:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzWMP-0001Sb-B2; Mon, 20 Feb 2012 16:45:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWMO-0001SQ-3P
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:45:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329756301!15459905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25267 invoked from network); 20 Feb 2012 16:45:02 -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;
	20 Feb 2012 16:45:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10818433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:45:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 16:45:01 +0000
Message-ID: <1329756300.3990.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Hook <matthew.hook@otoy.com>
Date: Mon, 20 Feb 2012 16:45:00 +0000
In-Reply-To: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
References: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-17 at 22:56 +0000, Matthew Hook wrote:
> I think this is a bug in the xl toolchain.

I agree.

Which version of Xen are you running? There have been various fixes to
the stuff in xen-unstable but from your error message (which doesn't
appear in the unstable code base AFAICT) I guess you are running 4.1.
Are you able to try unstable?

> lspci -s 0000:12:0.*
> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> 12:00.1 Audio device: ATI Technologies Inc Device aa80
> 
> sudo xm pci-list-assignable-devices

NB: it is not recommended to mix and match xm and xl. 

> 0000:13:00.0
> 0000:13:00.1
> 0000:12:00.0
> 0000:12:00.1
> 
> So there is a multi-function device (actually one ASIC of a AMD Radeon
> 6990 card).
> It has two function addresses 0 = Display controller, 1 = Audio Device.
> 
> However when running xl create where the line for pci is of the form
> pci=['12:00.*']
> Where * means pass through all devices, you get an error as below.
> 
> Parsing config file xenwin7-1.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->0000000000179830
>   TOTAL:         0000000000000000->000000007f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000003fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device
> 0:12:0.70 is not assignable
> 
> There is no function 70 on that device.

The * turns into a "LIBXL_PCI_FUNC_ALL (~0U)" in the internal
represenation, I bet this is some sort unhelpful and confusing of
formatting snafu related to that.

> In relation to that, the BDF documentation
> (http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
> you can specify
> the extended BDF notation on your kernel boot line in grub.  i.e.
> xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
> the kernel log.

That is the old wiki, the new page seems to be
http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation -- does this
still give you that impression? Please feel free to update to clarify.

> Actually, if you look at the code for pci_stub.c in the linux kernel
> (at least for Jeremy branch 2.6.32.48), extended BDF is not supported.

Right, I think that wiki page is trying to refer only to the notation
used by the toolstack. I imagine that could be clearer.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzWN2-0001WL-PW; Mon, 20 Feb 2012 16:45: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 1RzWN0-0001Vx-VU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:45:47 +0000
Received: from [85.158.139.83:49582] by server-5.bemta-5.messagelabs.com id
	9A/7E-13566-AB8724F4; Mon, 20 Feb 2012 16:45:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329756345!15770336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3037 invoked from network); 20 Feb 2012 16:45:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:45:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10818438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:45:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:45:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWMS-0005p3-FI; Mon, 20 Feb 2012 16:45:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWMS-0000u6-Dw;
	Mon, 20 Feb 2012 16:45:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.30872.417869.36504@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:45:12 +0000
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120117183412.GA16578@andromeda.dapyr.net>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
	<D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
	<1325775922.25206.395.camel@zakaz.uk.xensource.com>
	<20120117183412.GA16578@andromeda.dapyr.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] fix build error"):
> On Thu, Jan 05, 2012 at 03:05:21PM +0000, Ian Campbell wrote:
> > Any patch which says "fix build error/warning/message" should, IMHO,
> > always include a verbatim copy of the error message being fixed.

Yes.

> > Please can one of you resubmit with the changelog corrected in that
> > manner?
> 
> Yes please. You can also add 'Tested-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>'. Thanks.

This doesn't seem to have been forthcoming and it was all pretty
obvious following this thread so I've committed it now.
Next time it would definitely be nice if we could have a good commit
message and so forth.

> > Eventually we could use autoconf to detect this stuff, although that
> > does sound rather like overkill...

This kind of irritating API instability is exactly what autoconf is
good at.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 16:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 16: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 1RzWN2-0001WL-PW; Mon, 20 Feb 2012 16:45: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 1RzWN0-0001Vx-VU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 16:45:47 +0000
Received: from [85.158.139.83:49582] by server-5.bemta-5.messagelabs.com id
	9A/7E-13566-AB8724F4; Mon, 20 Feb 2012 16:45:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329756345!15770336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3037 invoked from network); 20 Feb 2012 16:45:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 16:45:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10818438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 16:45:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 16:45:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWMS-0005p3-FI; Mon, 20 Feb 2012 16:45:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWMS-0000u6-Dw;
	Mon, 20 Feb 2012 16:45:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.30872.417869.36504@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 16:45:12 +0000
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120117183412.GA16578@andromeda.dapyr.net>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
	<D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
	<1325775922.25206.395.camel@zakaz.uk.xensource.com>
	<20120117183412.GA16578@andromeda.dapyr.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] fix build error"):
> On Thu, Jan 05, 2012 at 03:05:21PM +0000, Ian Campbell wrote:
> > Any patch which says "fix build error/warning/message" should, IMHO,
> > always include a verbatim copy of the error message being fixed.

Yes.

> > Please can one of you resubmit with the changelog corrected in that
> > manner?
> 
> Yes please. You can also add 'Tested-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>'. Thanks.

This doesn't seem to have been forthcoming and it was all pretty
obvious following this thread so I've committed it now.
Next time it would definitely be nice if we could have a good commit
message and so forth.

> > Eventually we could use autoconf to detect this stuff, although that
> > does sound rather like overkill...

This kind of irritating API instability is exactly what autoconf is
good at.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:07:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWhR-0002KR-8o; Mon, 20 Feb 2012 17:06:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzWhP-0002KK-0f
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:06:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329757604!14731627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4111 invoked from network); 20 Feb 2012 17:06:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:06:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:06:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWhI-00064c-28; Mon, 20 Feb 2012 17:06:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWhI-0000y5-11;
	Mon, 20 Feb 2012 17:06:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.32164.17091.307533@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:06:44 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK4WWNEJwBz4mWkGt4n+3OO+tnoNsXEHqRrCA5LwuXRsNg@mail.gmail.com>
References: <patchbomb.1326968579@loki.upc.es>
	<CAPLaKK4WWNEJwBz4mWkGt4n+3OO+tnoNsXEHqRrCA5LwuXRsNg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] cosmetic fix to libxc for NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 0 of 2] cosmetic fix to l=
ibxc for NetBSD"):
> I've forgot to add the Reported-by:... stuff, sorry, could someone add:
> =

> Reported-by: "Olaf Hering" <olaf@aepfle.de>
> =

> to both patches if they are to be committed to the repository?

Thanks, I have done that and applied both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:07:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWhR-0002KR-8o; Mon, 20 Feb 2012 17:06:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzWhP-0002KK-0f
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:06:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329757604!14731627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4111 invoked from network); 20 Feb 2012 17:06:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:06:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:06:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWhI-00064c-28; Mon, 20 Feb 2012 17:06:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWhI-0000y5-11;
	Mon, 20 Feb 2012 17:06:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.32164.17091.307533@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:06:44 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK4WWNEJwBz4mWkGt4n+3OO+tnoNsXEHqRrCA5LwuXRsNg@mail.gmail.com>
References: <patchbomb.1326968579@loki.upc.es>
	<CAPLaKK4WWNEJwBz4mWkGt4n+3OO+tnoNsXEHqRrCA5LwuXRsNg@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] cosmetic fix to libxc for NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 0 of 2] cosmetic fix to l=
ibxc for NetBSD"):
> I've forgot to add the Reported-by:... stuff, sorry, could someone add:
> =

> Reported-by: "Olaf Hering" <olaf@aepfle.de>
> =

> to both patches if they are to be committed to the repository?

Thanks, I have done that and applied both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:09:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWjB-0002O5-PW; Mon, 20 Feb 2012 17:08:41 +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 1RzWj9-0002Nv-Db
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:08:40 +0000
Received: from [85.158.139.83:54915] by server-1.bemta-5.messagelabs.com id
	1D/3A-28458-61E724F4; Mon, 20 Feb 2012 17:08:38 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329757716!15773684!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13772 invoked from network); 20 Feb 2012 17:08:36 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:08:36 -0000
Received: by wibhm2 with SMTP id hm2so11554648wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 09:08:35 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.180.8.226 as permitted sender) client-ip=10.180.8.226; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.180.8.226 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.180.8.226])
	by 10.180.8.226 with SMTP id u2mr18871435wia.16.1329757715306 (num_hops
	= 1); Mon, 20 Feb 2012 09:08:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=8ZmoKBPbP+pi7HdTl3J5xx1mCnXv9Yhg49qHoXLwIUo=;
	b=dN2xLoVqjBS3MrLFEG82SlY+v+ggnFwxrL7EU7l6eeLpbSBgxgiUfPjGRgHwZu8WW0
	uMBdq0uCbSY36hsvFJIIKc8emvvdq6ZMOKP8B4ZwofpRpdnNFaFOCsu/7WjO06nWS5qk
	E4Isjha4FJpN2l6T3Nl9sO5cpFcF9J73NxPT8=
Received: by 10.180.8.226 with SMTP id u2mr15668328wia.16.1329757715262; Mon,
	20 Feb 2012 09:08:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.178.143 with HTTP; Mon, 20 Feb 2012 09:08:05 -0800 (PST)
In-Reply-To: <201202201711.11807.tobias.geiger@vido.info>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 17:08:05 +0000
X-Google-Sender-Auth: dM6E0_PenojztXCYTlk37lLbgIU
Message-ID: <CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 16:11, Tobias Geiger <tobias.geiger@vido.info> wrote:
> My Domu (Win7_64) boots fine, but 2 of my 6 passed-through pcidevices dont get
> passed through at all:
>
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
> message from QMP server: Device 'xen-pci-passthrough' could not be initialized
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
> message from QMP server: Device 'xen-pci-passthrough' could not be initialized

These two errors are probably because my patch series depend on one
other patch sent earlier:
http://lists.xen.org/archives/html/xen-devel/2012-02/msg01027.html

> The other 4 PCI-Ids (USB Controller) get passed through, but the USB-Devices
> attached to them are "Not Working" according to Windows Device-Manager.
>
> All Devices worked with the old qemu-dm (traditional).
>
> Anything i can do to debug this further?

You can send the log of qemu ( /var/log/xen/qemu-dm-$vm_name.log ).
There is also a way to have more from QEMU by decommenting this two lines:
/* #define PT_LOGGING_ENABLED */
/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
in hw/xen_pci_passthrough.h

Thanks for the testing,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:09:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWjB-0002O5-PW; Mon, 20 Feb 2012 17:08:41 +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 1RzWj9-0002Nv-Db
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:08:40 +0000
Received: from [85.158.139.83:54915] by server-1.bemta-5.messagelabs.com id
	1D/3A-28458-61E724F4; Mon, 20 Feb 2012 17:08:38 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329757716!15773684!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13772 invoked from network); 20 Feb 2012 17:08:36 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:08:36 -0000
Received: by wibhm2 with SMTP id hm2so11554648wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 09:08:35 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.180.8.226 as permitted sender) client-ip=10.180.8.226; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.180.8.226 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.180.8.226])
	by 10.180.8.226 with SMTP id u2mr18871435wia.16.1329757715306 (num_hops
	= 1); Mon, 20 Feb 2012 09:08:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=8ZmoKBPbP+pi7HdTl3J5xx1mCnXv9Yhg49qHoXLwIUo=;
	b=dN2xLoVqjBS3MrLFEG82SlY+v+ggnFwxrL7EU7l6eeLpbSBgxgiUfPjGRgHwZu8WW0
	uMBdq0uCbSY36hsvFJIIKc8emvvdq6ZMOKP8B4ZwofpRpdnNFaFOCsu/7WjO06nWS5qk
	E4Isjha4FJpN2l6T3Nl9sO5cpFcF9J73NxPT8=
Received: by 10.180.8.226 with SMTP id u2mr15668328wia.16.1329757715262; Mon,
	20 Feb 2012 09:08:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.178.143 with HTTP; Mon, 20 Feb 2012 09:08:05 -0800 (PST)
In-Reply-To: <201202201711.11807.tobias.geiger@vido.info>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 17:08:05 +0000
X-Google-Sender-Auth: dM6E0_PenojztXCYTlk37lLbgIU
Message-ID: <CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 16:11, Tobias Geiger <tobias.geiger@vido.info> wrote:
> My Domu (Win7_64) boots fine, but 2 of my 6 passed-through pcidevices dont get
> passed through at all:
>
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
> message from QMP server: Device 'xen-pci-passthrough' could not be initialized
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
> message from QMP server: Device 'xen-pci-passthrough' could not be initialized

These two errors are probably because my patch series depend on one
other patch sent earlier:
http://lists.xen.org/archives/html/xen-devel/2012-02/msg01027.html

> The other 4 PCI-Ids (USB Controller) get passed through, but the USB-Devices
> attached to them are "Not Working" according to Windows Device-Manager.
>
> All Devices worked with the old qemu-dm (traditional).
>
> Anything i can do to debug this further?

You can send the log of qemu ( /var/log/xen/qemu-dm-$vm_name.log ).
There is also a way to have more from QEMU by decommenting this two lines:
/* #define PT_LOGGING_ENABLED */
/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
in hw/xen_pci_passthrough.h

Thanks for the testing,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:10:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWkC-0002Se-OJ; Mon, 20 Feb 2012 17:09:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzWkB-0002SH-8q
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:09:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329757776!2764183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9130 invoked from network); 20 Feb 2012 17:09:37 -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;
	20 Feb 2012 17:09:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:09:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:09:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWk3-00066f-Nj; Mon, 20 Feb 2012 17:09:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWk3-0000yQ-Lz;
	Mon, 20 Feb 2012 17:09:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.32335.668762.730080@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:09:35 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
References: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket"):
> When read() return 0, the current code just tries again. But this leads to an
> infinite loop if QEMU died too soon.

Right.

> Also, retry select if a signal was caught.

Why add another goto ?  I think these goto-based loops are a bad idea,
really.

> +            if (errno == EINTR)
> +                goto do_select_again;

I think this could be "continue".  Do you agree.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:10:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWkC-0002Se-OJ; Mon, 20 Feb 2012 17:09:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzWkB-0002SH-8q
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:09:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329757776!2764183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9130 invoked from network); 20 Feb 2012 17:09:37 -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;
	20 Feb 2012 17:09:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:09:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:09:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWk3-00066f-Nj; Mon, 20 Feb 2012 17:09:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWk3-0000yQ-Lz;
	Mon, 20 Feb 2012 17:09:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.32335.668762.730080@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:09:35 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
References: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket"):
> When read() return 0, the current code just tries again. But this leads to an
> infinite loop if QEMU died too soon.

Right.

> Also, retry select if a signal was caught.

Why add another goto ?  I think these goto-based loops are a bad idea,
really.

> +            if (errno == EINTR)
> +                goto do_select_again;

I think this could be "continue".  Do you agree.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:18:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWsR-0002oF-Vk; Mon, 20 Feb 2012 17:18:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzWsR-0002o4-1D
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:18:15 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329758288!13937872!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=RCVD_BY_IP,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14881 invoked from network); 20 Feb 2012 17:18:08 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:18:08 -0000
Received: by wgbdr13 with SMTP id dr13so4358215wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 09:18:08 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.180.14.73 as permitted sender) client-ip=10.180.14.73; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.180.14.73 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.180.14.73])
	by 10.180.14.73 with SMTP id n9mr19036622wic.16.1329758288291 (num_hops
	= 1); Mon, 20 Feb 2012 09:18:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5rR4/v4iIoeAS0U2mgb9/kp1Z98wRuyugb7RtsrFYbo=;
	b=Q6RhTYAwoW0NUCzFttu5kV4lG1vvaOvpDsaeZ3FFhdXQpAFu1VrpbBRddbiCUEUTkv
	0LCKR7cEaRkFI2Q5KO6Mg+l8bKhcvKOmr/34iB10vpoLH+uuts/lFw0f0VuJwDGRcdmf
	z1c6VrXlBawqcUInYxaZ1eE8fRFGeCZB780lA=
Received: by 10.180.14.73 with SMTP id n9mr15802271wic.16.1329758288231; Mon,
	20 Feb 2012 09:18:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.178.143 with HTTP; Mon, 20 Feb 2012 09:17:38 -0800 (PST)
In-Reply-To: <20290.32335.668762.730080@mariner.uk.xensource.com>
References: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
	<20290.32335.668762.730080@mariner.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 17:17:38 +0000
X-Google-Sender-Auth: QBO_zI0EhGq4xZ0Tdp41oeC_85c
Message-ID: <CAJJyHj+xy8h212SLMyHhtwusci6=1+5BmhLVW5c+TGnve2JnxQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBGZWIgMjAsIDIwMTIgYXQgMTc6MDksIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBl
dS5jaXRyaXguY29tPiB3cm90ZToKPiBBbnRob255IFBFUkFSRCB3cml0ZXMgKCJbWGVuLWRldmVs
XSBbUEFUQ0hdIGxpYnhsX3FtcDogSGFuZGxlIHVuZXhwZWN0ZWQgZW5kLW9mLXNvY2tldCIpOgo+
PiBXaGVuIHJlYWQoKSByZXR1cm4gMCwgdGhlIGN1cnJlbnQgY29kZSBqdXN0IHRyaWVzIGFnYWlu
LiBCdXQgdGhpcyBsZWFkcyB0byBhbgo+PiBpbmZpbml0ZSBsb29wIGlmIFFFTVUgZGllZCB0b28g
c29vbi4KPgo+IFJpZ2h0Lgo+Cj4+IEFsc28sIHJldHJ5IHNlbGVjdCBpZiBhIHNpZ25hbCB3YXMg
Y2F1Z2h0Lgo+Cj4gV2h5IGFkZCBhbm90aGVyIGdvdG8gPyDCoEkgdGhpbmsgdGhlc2UgZ290by1i
YXNlZCBsb29wcyBhcmUgYSBiYWQgaWRlYSwKPiByZWFsbHkuCj4KPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoGlmIChlcnJubyA9PSBFSU5UUikKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvdG8g
ZG9fc2VsZWN0X2FnYWluOwo+Cj4gSSB0aGluayB0aGlzIGNvdWxkIGJlICJjb250aW51ZSIuIMKg
RG8geW91IGFncmVlLgoKWWVzLCBJIGFncmVlLiBJJ2xsIGNoYW5nZSB0aGF0IGZvciBhIHdoaWxl
IGFuZCByZXNlbmQgaXQuCgpUaGFua3MsCgotLSAKQW50aG9ueSBQRVJBUkQKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:18:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWsR-0002oF-Vk; Mon, 20 Feb 2012 17:18:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzWsR-0002o4-1D
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:18:15 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329758288!13937872!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=2.3 required=7.0 tests=RCVD_BY_IP,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14881 invoked from network); 20 Feb 2012 17:18:08 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:18:08 -0000
Received: by wgbdr13 with SMTP id dr13so4358215wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 09:18:08 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.180.14.73 as permitted sender) client-ip=10.180.14.73; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.180.14.73 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.180.14.73])
	by 10.180.14.73 with SMTP id n9mr19036622wic.16.1329758288291 (num_hops
	= 1); Mon, 20 Feb 2012 09:18:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5rR4/v4iIoeAS0U2mgb9/kp1Z98wRuyugb7RtsrFYbo=;
	b=Q6RhTYAwoW0NUCzFttu5kV4lG1vvaOvpDsaeZ3FFhdXQpAFu1VrpbBRddbiCUEUTkv
	0LCKR7cEaRkFI2Q5KO6Mg+l8bKhcvKOmr/34iB10vpoLH+uuts/lFw0f0VuJwDGRcdmf
	z1c6VrXlBawqcUInYxaZ1eE8fRFGeCZB780lA=
Received: by 10.180.14.73 with SMTP id n9mr15802271wic.16.1329758288231; Mon,
	20 Feb 2012 09:18:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.178.143 with HTTP; Mon, 20 Feb 2012 09:17:38 -0800 (PST)
In-Reply-To: <20290.32335.668762.730080@mariner.uk.xensource.com>
References: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
	<20290.32335.668762.730080@mariner.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 17:17:38 +0000
X-Google-Sender-Auth: QBO_zI0EhGq4xZ0Tdp41oeC_85c
Message-ID: <CAJJyHj+xy8h212SLMyHhtwusci6=1+5BmhLVW5c+TGnve2JnxQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBGZWIgMjAsIDIwMTIgYXQgMTc6MDksIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBl
dS5jaXRyaXguY29tPiB3cm90ZToKPiBBbnRob255IFBFUkFSRCB3cml0ZXMgKCJbWGVuLWRldmVs
XSBbUEFUQ0hdIGxpYnhsX3FtcDogSGFuZGxlIHVuZXhwZWN0ZWQgZW5kLW9mLXNvY2tldCIpOgo+
PiBXaGVuIHJlYWQoKSByZXR1cm4gMCwgdGhlIGN1cnJlbnQgY29kZSBqdXN0IHRyaWVzIGFnYWlu
LiBCdXQgdGhpcyBsZWFkcyB0byBhbgo+PiBpbmZpbml0ZSBsb29wIGlmIFFFTVUgZGllZCB0b28g
c29vbi4KPgo+IFJpZ2h0Lgo+Cj4+IEFsc28sIHJldHJ5IHNlbGVjdCBpZiBhIHNpZ25hbCB3YXMg
Y2F1Z2h0Lgo+Cj4gV2h5IGFkZCBhbm90aGVyIGdvdG8gPyDCoEkgdGhpbmsgdGhlc2UgZ290by1i
YXNlZCBsb29wcyBhcmUgYSBiYWQgaWRlYSwKPiByZWFsbHkuCj4KPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoGlmIChlcnJubyA9PSBFSU5UUikKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvdG8g
ZG9fc2VsZWN0X2FnYWluOwo+Cj4gSSB0aGluayB0aGlzIGNvdWxkIGJlICJjb250aW51ZSIuIMKg
RG8geW91IGFncmVlLgoKWWVzLCBJIGFncmVlLiBJJ2xsIGNoYW5nZSB0aGF0IGZvciBhIHdoaWxl
IGFuZCByZXNlbmQgaXQuCgpUaGFua3MsCgotLSAKQW50aG9ueSBQRVJBUkQKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWuT-0002uM-Gr; Mon, 20 Feb 2012 17:20:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWuS-0002ts-C2
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:20:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329758413!9869559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15303 invoked from network); 20 Feb 2012 17:20:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:20:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:20:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 17:20:13 +0000
Message-ID: <1329758412.3990.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 20 Feb 2012 17:20:12 +0000
In-Reply-To: <4F3E8CE1.7030803@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
	<1329498796.3131.135.camel@zakaz.uk.xensource.com>
	<4F3E8CE1.7030803@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-17 at 17:22 +0000, David Vrabel wrote:
> On 17/02/12 17:13, Ian Campbell wrote:
> > On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> >> diff --git a/config/arm.mk b/config/arm.mk
> >> index f64f0c1..f20fd2d 100644
> >> --- a/config/arm.mk
> >> +++ b/config/arm.mk
> >> @@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
> >>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> >>  
> >>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> >> +
> >> +# XXX: When running on the model there is no bootloader to provide a
> >> +# device tree.  It must be linked into Xen.
> >> +ifndef CONFIG_DTB_FILE
> >> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a
> >> DTB)
> >> +endif 
> > 
> > This turns out to be a little aggressive -- it also triggers when you
> > are building the tools. Not a big deal, but a bit annoying, is there
> > some way we can avoid this? Put it in xen/arch/arm/Foo perhaps?
> 
> Does this do the right thing?

It seems to, thanks.

It still fails the Xen case reasonably early which was the only problem
I could foresee.

> 
> 8<---------
> arm: move check for CONFIG_DTB_FILE to xen/arch/arm/Makefile
> 
> CONFIG_DTB_FILE only needs to be set when building Xen itself.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
and queued for commit.

> ---
>  config/arm.mk         |    6 ------
>  xen/arch/arm/Makefile |    4 ++++
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/config/arm.mk b/config/arm.mk
> index f20fd2d..f64f0c1 100644
> --- a/config/arm.mk
> +++ b/config/arm.mk
> @@ -16,9 +16,3 @@ LDFLAGS_DIRECT_Linux = _linux
>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> 
>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> -
> -# XXX: When running on the model there is no bootloader to provide a
> -# device tree.  It must be linked into Xen.
> -ifndef CONFIG_DTB_FILE
> -$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
> -endif
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 168716e..da9134b 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -26,6 +26,10 @@ obj-y += vtimer.o
>  ifdef CONFIG_DTB_FILE
>  obj-y += dtb.o
>  AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
> +else
> +# XXX: When running on the model there is no bootloader to provide a
> +# device tree.  It must be linked into Xen.
> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
>  endif
> 
>  ALL_OBJS := head.o $(ALL_OBJS)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:20:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWuT-0002uM-Gr; Mon, 20 Feb 2012 17:20:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWuS-0002ts-C2
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:20:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329758413!9869559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15303 invoked from network); 20 Feb 2012 17:20:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:20:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:20:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 17:20:13 +0000
Message-ID: <1329758412.3990.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 20 Feb 2012 17:20:12 +0000
In-Reply-To: <4F3E8CE1.7030803@citrix.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
	<1329498796.3131.135.camel@zakaz.uk.xensource.com>
	<4F3E8CE1.7030803@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-17 at 17:22 +0000, David Vrabel wrote:
> On 17/02/12 17:13, Ian Campbell wrote:
> > On Mon, 2012-02-13 at 13:18 +0000, David Vrabel wrote:
> >> diff --git a/config/arm.mk b/config/arm.mk
> >> index f64f0c1..f20fd2d 100644
> >> --- a/config/arm.mk
> >> +++ b/config/arm.mk
> >> @@ -16,3 +16,9 @@ LDFLAGS_DIRECT_Linux = _linux
> >>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> >>  
> >>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> >> +
> >> +# XXX: When running on the model there is no bootloader to provide a
> >> +# device tree.  It must be linked into Xen.
> >> +ifndef CONFIG_DTB_FILE
> >> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a
> >> DTB)
> >> +endif 
> > 
> > This turns out to be a little aggressive -- it also triggers when you
> > are building the tools. Not a big deal, but a bit annoying, is there
> > some way we can avoid this? Put it in xen/arch/arm/Foo perhaps?
> 
> Does this do the right thing?

It seems to, thanks.

It still fails the Xen case reasonably early which was the only problem
I could foresee.

> 
> 8<---------
> arm: move check for CONFIG_DTB_FILE to xen/arch/arm/Makefile
> 
> CONFIG_DTB_FILE only needs to be set when building Xen itself.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
and queued for commit.

> ---
>  config/arm.mk         |    6 ------
>  xen/arch/arm/Makefile |    4 ++++
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/config/arm.mk b/config/arm.mk
> index f20fd2d..f64f0c1 100644
> --- a/config/arm.mk
> +++ b/config/arm.mk
> @@ -16,9 +16,3 @@ LDFLAGS_DIRECT_Linux = _linux
>  LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> 
>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> -
> -# XXX: When running on the model there is no bootloader to provide a
> -# device tree.  It must be linked into Xen.
> -ifndef CONFIG_DTB_FILE
> -$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
> -endif
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 168716e..da9134b 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -26,6 +26,10 @@ obj-y += vtimer.o
>  ifdef CONFIG_DTB_FILE
>  obj-y += dtb.o
>  AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
> +else
> +# XXX: When running on the model there is no bootloader to provide a
> +# device tree.  It must be linked into Xen.
> +$(error CONFIG_DTB_FILE must be set to the absolute filename of a DTB)
>  endif
> 
>  ALL_OBJS := head.o $(ALL_OBJS)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:23:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWxD-00035c-CJ; Mon, 20 Feb 2012 17:23:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWxB-00035D-79
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:23:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329758583!5930675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7530 invoked from network); 20 Feb 2012 17:23:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:23:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:23:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 17:23:02 +0000
Message-ID: <1329758581.3990.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 17:23:01 +0000
In-Reply-To: <20290.32335.668762.730080@mariner.uk.xensource.com>
References: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
	<20290.32335.668762.730080@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 17:09 +0000, Ian Jackson wrote:
> Anthony PERARD writes ("[Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket"):
> > When read() return 0, the current code just tries again. But this leads to an
> > infinite loop if QEMU died too soon.
> 
> Right.
> 
> > Also, retry select if a signal was caught.
> 
> Why add another goto ?  I think these goto-based loops are a bad idea,
> really.
> 
> > +            if (errno == EINTR)
> > +                goto do_select_again;
> 
> I think this could be "continue".  Do you agree.

Also select(2) says:
        On error, -1 is returned, and errno is set appropriately; the
               sets and timeout become undefined, so do not  rely  on  their  contents
               after an error.

So by my reading you need to reinitialise the sets anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:23:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzWxD-00035c-CJ; Mon, 20 Feb 2012 17:23:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzWxB-00035D-79
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:23:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329758583!5930675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7530 invoked from network); 20 Feb 2012 17:23:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:23:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:23:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 17:23:02 +0000
Message-ID: <1329758581.3990.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 17:23:01 +0000
In-Reply-To: <20290.32335.668762.730080@mariner.uk.xensource.com>
References: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
	<20290.32335.668762.730080@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 17:09 +0000, Ian Jackson wrote:
> Anthony PERARD writes ("[Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket"):
> > When read() return 0, the current code just tries again. But this leads to an
> > infinite loop if QEMU died too soon.
> 
> Right.
> 
> > Also, retry select if a signal was caught.
> 
> Why add another goto ?  I think these goto-based loops are a bad idea,
> really.
> 
> > +            if (errno == EINTR)
> > +                goto do_select_again;
> 
> I think this could be "continue".  Do you agree.

Also select(2) says:
        On error, -1 is returned, and errno is set appropriately; the
               sets and timeout become undefined, so do not  rely  on  their  contents
               after an error.

So by my reading you need to reinitialise the sets anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:26:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWzk-0003G3-UM; Mon, 20 Feb 2012 17:25:48 +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 1RzWzj-0003Fl-LV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:25:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329758717!53672413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18949 invoked from network); 20 Feb 2012 17:25:17 -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;
	20 Feb 2012 17:25:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:25:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:25:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWzd-0006EQ-4H; Mon, 20 Feb 2012 17:25:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWzd-00011A-3K;
	Mon, 20 Feb 2012 17:25:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.33301.89584.251547@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:25:41 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120214210851.GA21988@aepfle.de>,
	<20276.2335.273506.959266@mariner.uk.xensource.com>
References: <patchbomb.1327939163@probook.site>
	<20276.2335.273506.959266@mariner.uk.xensource.com>
	<b7906ad2815304272686.1327939169@probook.site>
	<20120214210851.GA21988@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> Olaf Hering writes ("[Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> > This series adjusts the error reporting in the various code paths, with
> > the intention that fatal errors can be detected by callers and handled
> > properly. During my performance analysis with callgrind I found and
> > fixed a few bottlenecks in the page-in code paths.
> 
> Since these are all xenpaging changes, I'm inclined to follow your
> lead and commit them soon.  If anyone has any comments, please shout!

Olaf, can you please rebase to current tip ?  The other recent
xenpaging changes conflict with these.

And then while you're there you should obviously incorporate this
change:

Olaf Hering writes ("Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in policy_choose_victim"):
> On Mon, Jan 30, Olaf Hering wrote:
> > +        if ( test_bit(current_gfn, bitmap) )
> > +            continue;
> > +
> > +        /* gfn already tested */
> > +        if ( test_bit(current_gfn, bitmap) )
> > +            continue;
> > +
> > +        /* gfn found */
> > +        break;
> 
> The second one should be "unconsumed" instead of "bitmap", otherwise
> wraparounds lead to endless loop in caller..

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:26:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzWzk-0003G3-UM; Mon, 20 Feb 2012 17:25:48 +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 1RzWzj-0003Fl-LV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:25:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329758717!53672413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18949 invoked from network); 20 Feb 2012 17:25:17 -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;
	20 Feb 2012 17:25:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:25:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:25:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzWzd-0006EQ-4H; Mon, 20 Feb 2012 17:25:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzWzd-00011A-3K;
	Mon, 20 Feb 2012 17:25:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.33301.89584.251547@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:25:41 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120214210851.GA21988@aepfle.de>,
	<20276.2335.273506.959266@mariner.uk.xensource.com>
References: <patchbomb.1327939163@probook.site>
	<20276.2335.273506.959266@mariner.uk.xensource.com>
	<b7906ad2815304272686.1327939169@probook.site>
	<20120214210851.GA21988@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> Olaf Hering writes ("[Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> > This series adjusts the error reporting in the various code paths, with
> > the intention that fatal errors can be detected by callers and handled
> > properly. During my performance analysis with callgrind I found and
> > fixed a few bottlenecks in the page-in code paths.
> 
> Since these are all xenpaging changes, I'm inclined to follow your
> lead and commit them soon.  If anyone has any comments, please shout!

Olaf, can you please rebase to current tip ?  The other recent
xenpaging changes conflict with these.

And then while you're there you should obviously incorporate this
change:

Olaf Hering writes ("Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in policy_choose_victim"):
> On Mon, Jan 30, Olaf Hering wrote:
> > +        if ( test_bit(current_gfn, bitmap) )
> > +            continue;
> > +
> > +        /* gfn already tested */
> > +        if ( test_bit(current_gfn, bitmap) )
> > +            continue;
> > +
> > +        /* gfn found */
> > +        break;
> 
> The second one should be "unconsumed" instead of "bitmap", otherwise
> wraparounds lead to endless loop in caller..

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:29:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzX2n-0003PO-H9; Mon, 20 Feb 2012 17:28:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RzX2l-0003P6-OU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:28:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329758928!14734093!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30261 invoked from network); 20 Feb 2012 17:28:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:28:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325480400"; d="scan'208";a="182656920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 12:28:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 12:28:47 -0500
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 1RzX2d-000081-DZ;
	Mon, 20 Feb 2012 17:28:47 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 17:28:36 +0000
Message-ID: <1329758916-25379-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 read() return 0, the current code just tries again. But this leads to an
infinite loop if QEMU died too soon.

Also, retry select if a signal was caught.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
change with v1:
  - remove the introduced goto in favor of a "continue".

 tools/libxl/libxl_qmp.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e0642e3..a974afe 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -390,13 +390,16 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
             LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout");
             return -1;
         } else if (ret < 0) {
+            if (errno == EINTR)
+                continue;
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error");
             return -1;
         }
 
         rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
         if (rd == 0) {
-            continue;
+            LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Unexpected end of socket");
+            return -1;
         } else if (rd < 0) {
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error");
             return rd;
-- 
tg: (75f1fb7..) fix/qmp-end-of-socket (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:29:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17: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 1RzX2n-0003PO-H9; Mon, 20 Feb 2012 17:28:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RzX2l-0003P6-OU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:28:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329758928!14734093!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30261 invoked from network); 20 Feb 2012 17:28:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:28:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325480400"; d="scan'208";a="182656920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 12:28:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 20 Feb 2012 12:28:47 -0500
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 1RzX2d-000081-DZ;
	Mon, 20 Feb 2012 17:28:47 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 17:28:36 +0000
Message-ID: <1329758916-25379-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 read() return 0, the current code just tries again. But this leads to an
infinite loop if QEMU died too soon.

Also, retry select if a signal was caught.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
change with v1:
  - remove the introduced goto in favor of a "continue".

 tools/libxl/libxl_qmp.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e0642e3..a974afe 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -390,13 +390,16 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
             LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout");
             return -1;
         } else if (ret < 0) {
+            if (errno == EINTR)
+                continue;
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error");
             return -1;
         }
 
         rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
         if (rd == 0) {
-            continue;
+            LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Unexpected end of socket");
+            return -1;
         } else if (rd < 0) {
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error");
             return rd;
-- 
tg: (75f1fb7..) fix/qmp-end-of-socket (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzX4i-0003Yb-88; Mon, 20 Feb 2012 17:30:56 +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 1RzX4g-0003YI-25
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:30:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329759004!60890128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5338 invoked from network); 20 Feb 2012 17:30:04 -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;
	20 Feb 2012 17:30:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:30:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:30:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzX4Z-0006G7-GH; Mon, 20 Feb 2012 17:30:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzX4Z-00012H-EW;
	Mon, 20 Feb 2012 17:30:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.33607.267445.673593@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:30:47 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329480628-27341-1-git-send-email-david.vrabel@citrix.com>
References: <1329480628-27341-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] xen: add more files generated
	in	xen/arch/x86/efi to .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel writes ("[Xen-devel] [PATCH] xen: add more files generated in xen/arch/x86/efi to .gitignore"):
> From: David Vrabel <david.vrabel@citrix.com>
> 
> These files were already listed in .hgignore.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzX4i-0003Yb-88; Mon, 20 Feb 2012 17:30:56 +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 1RzX4g-0003YI-25
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:30:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329759004!60890128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5338 invoked from network); 20 Feb 2012 17:30:04 -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;
	20 Feb 2012 17:30:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208";a="10819685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:30:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:30:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzX4Z-0006G7-GH; Mon, 20 Feb 2012 17:30:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzX4Z-00012H-EW;
	Mon, 20 Feb 2012 17:30:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.33607.267445.673593@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:30:47 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329480628-27341-1-git-send-email-david.vrabel@citrix.com>
References: <1329480628-27341-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] xen: add more files generated
	in	xen/arch/x86/efi to .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel writes ("[Xen-devel] [PATCH] xen: add more files generated in xen/arch/x86/efi to .gitignore"):
> From: David Vrabel <david.vrabel@citrix.com>
> 
> These files were already listed in .hgignore.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:32:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 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 1RzX5p-0003eH-QH; Mon, 20 Feb 2012 17:32:05 +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 1RzX5o-0003dt-Iz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:32:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329759088!57481816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29576 invoked from network); 20 Feb 2012 17:31:28 -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 Feb 2012 17:31:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10819713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 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.213.0; Mon, 20 Feb 2012 17:31:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzX5i-0006GZ-6d; Mon, 20 Feb 2012 17:31:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzX5i-00015z-5j;
	Mon, 20 Feb 2012 17:31:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.33678.162450.273514@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:31:58 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel writes ("[Xen-devel] [PATCH] libxc: remove tests of alloca() return value"):
> alloca() does not return NULL on an allocation failure so remove the
> unneccessary tests.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:32:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 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 1RzX5p-0003eH-QH; Mon, 20 Feb 2012 17:32:05 +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 1RzX5o-0003dt-Iz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:32:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329759088!57481816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29576 invoked from network); 20 Feb 2012 17:31:28 -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 Feb 2012 17:31:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10819713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 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.213.0; Mon, 20 Feb 2012 17:31:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzX5i-0006GZ-6d; Mon, 20 Feb 2012 17:31:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzX5i-00015z-5j;
	Mon, 20 Feb 2012 17:31:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.33678.162450.273514@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:31:58 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
References: <1329480642-27378-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Santosh Jodh <santosh.jodh@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxc: remove tests of alloca() return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

David Vrabel writes ("[Xen-devel] [PATCH] libxc: remove tests of alloca() return value"):
> alloca() does not return NULL on an allocation failure so remove the
> unneccessary tests.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:46:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXJL-0003xj-B6; Mon, 20 Feb 2012 17:46: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 1RzXJI-0003xe-EV
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 17:46:00 +0000
Received: from [85.158.139.83:39715] by server-7.bemta-5.messagelabs.com id
	69/B1-16195-7D6824F4; Mon, 20 Feb 2012 17:45:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329759959!8425924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17154 invoked from network); 20 Feb 2012 17:45:59 -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;
	20 Feb 2012 17:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:45:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:45:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXJG-0006PC-GC; Mon, 20 Feb 2012 17:45:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXJG-0001gx-FJ;
	Mon, 20 Feb 2012 17:45:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.34518.441248.907891@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:45:58 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
References: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
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] build: add autoconf to replace custom
	checks in tools/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

Roger Pau Monne writes ("[PATCH] build: add autoconf to replace custom checks in tools/check"):
> build: add autoconf to replace custom checks in tools/check

Thanks for this.  I think, though, that it has been eaten by the
mailing list because of its size.  And Citrix's mail system is still
broken so the copy that made it to my mailbox is mangled.

Can you send another copy but with the autogenerated files removed ?
I'll then rerun the autogen.sh at this end.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:46:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXJL-0003xj-B6; Mon, 20 Feb 2012 17:46: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 1RzXJI-0003xe-EV
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 17:46:00 +0000
Received: from [85.158.139.83:39715] by server-7.bemta-5.messagelabs.com id
	69/B1-16195-7D6824F4; Mon, 20 Feb 2012 17:45:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329759959!8425924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17154 invoked from network); 20 Feb 2012 17:45:59 -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;
	20 Feb 2012 17:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:45:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:45:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXJG-0006PC-GC; Mon, 20 Feb 2012 17:45:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXJG-0001gx-FJ;
	Mon, 20 Feb 2012 17:45:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.34518.441248.907891@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:45:58 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
References: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
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] build: add autoconf to replace custom
	checks in tools/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

Roger Pau Monne writes ("[PATCH] build: add autoconf to replace custom checks in tools/check"):
> build: add autoconf to replace custom checks in tools/check

Thanks for this.  I think, though, that it has been eaten by the
mailing list because of its size.  And Citrix's mail system is still
broken so the copy that made it to my mailbox is mangled.

Can you send another copy but with the autogenerated files removed ?
I'll then rerun the autogen.sh at this end.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXQm-0004BU-Bx; Mon, 20 Feb 2012 17:53: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 1RzXQk-0004BP-SP
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:53:43 +0000
Received: from [85.158.139.83:65166] by server-12.bemta-5.messagelabs.com id
	42/1A-24595-6A8824F4; Mon, 20 Feb 2012 17:53:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329760421!15862862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32358 invoked from network); 20 Feb 2012 17:53:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:53:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:53:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:53:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXQi-0006Te-U2; Mon, 20 Feb 2012 17:53:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXQi-0001kj-T5;
	Mon, 20 Feb 2012 17:53:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.34980.888263.207716@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:53:40 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329758916-25379-1-git-send-email-anthony.perard@citrix.com>
References: <1329758916-25379-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2] libxl_qmp: Handle unexpected
	end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 V2] libxl_qmp: Handle unexpected end-of-socket"):
> When read() return 0, the current code just tries again. But this leads to an
> infinite loop if QEMU died too soon.
> 
> Also, retry select if a signal was caught.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 17:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 17:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXQm-0004BU-Bx; Mon, 20 Feb 2012 17:53: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 1RzXQk-0004BP-SP
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 17:53:43 +0000
Received: from [85.158.139.83:65166] by server-12.bemta-5.messagelabs.com id
	42/1A-24595-6A8824F4; Mon, 20 Feb 2012 17:53:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329760421!15862862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32358 invoked from network); 20 Feb 2012 17:53:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:53:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 17:53:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 17:53:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXQi-0006Te-U2; Mon, 20 Feb 2012 17:53:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXQi-0001kj-T5;
	Mon, 20 Feb 2012 17:53:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.34980.888263.207716@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 17:53:40 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329758916-25379-1-git-send-email-anthony.perard@citrix.com>
References: <1329758916-25379-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2] libxl_qmp: Handle unexpected
	end-of-socket
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 V2] libxl_qmp: Handle unexpected end-of-socket"):
> When read() return 0, the current code just tries again. But this leads to an
> infinite loop if QEMU died too soon.
> 
> Also, retry select if a signal was caught.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:05:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXc4-0004eS-9Z; Mon, 20 Feb 2012 18:05:24 +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 1RzXc3-0004eK-36
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:05:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329761081!53196890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22302 invoked from network); 20 Feb 2012 18:04:41 -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;
	20 Feb 2012 18:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:05:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:05:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXc1-0006ps-Hn; Mon, 20 Feb 2012 18:05:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXc1-0005nd-Ga;
	Mon, 20 Feb 2012 18:05:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.35681.498514.432485@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:05:21 +0000
To: Fantu <fantonifabio@tiscali.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329229025787-5482548.post@n5.nabble.com>
References: <1329229025787-5482548.post@n5.nabble.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/examples: Add to makefile the xl
 configuration examples
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fantu writes ("[Xen-devel] [PATCH] tools/examples: Add to makefile the xl configuration examples"):
> tools/examples: Add to makefile the xl configuration examples

Thanks,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:05:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXc4-0004eS-9Z; Mon, 20 Feb 2012 18:05:24 +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 1RzXc3-0004eK-36
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:05:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329761081!53196890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22302 invoked from network); 20 Feb 2012 18:04:41 -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;
	20 Feb 2012 18:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:05:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:05:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXc1-0006ps-Hn; Mon, 20 Feb 2012 18:05:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXc1-0005nd-Ga;
	Mon, 20 Feb 2012 18:05:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.35681.498514.432485@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:05:21 +0000
To: Fantu <fantonifabio@tiscali.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329229025787-5482548.post@n5.nabble.com>
References: <1329229025787-5482548.post@n5.nabble.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/examples: Add to makefile the xl
 configuration examples
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fantu writes ("[Xen-devel] [PATCH] tools/examples: Add to makefile the xl configuration examples"):
> tools/examples: Add to makefile the xl configuration examples

Thanks,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:09:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:09:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXg9-0004nV-2y; Mon, 20 Feb 2012 18:09:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXg7-0004nE-FC
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:09:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329761369!14134845!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8036 invoked from network); 20 Feb 2012 18:09:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:09:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820591"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:09:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:09:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXfj-0006t6-Oj; Mon, 20 Feb 2012 18:09:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXfj-0005pT-Nd;
	Mon, 20 Feb 2012 18:09:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.35911.688773.697516@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:09:11 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <07bc9ce2378e9271405b.1329297853@probook.site>
References: <07bc9ce2378e9271405b.1329297853@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: fix xl create/cpupool-create -f help
	output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] xl: fix xl create/cpupool-create -f help output"):
> xl: fix xl create/cpupool-create -f help output

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:09:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:09:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXg9-0004nV-2y; Mon, 20 Feb 2012 18:09:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXg7-0004nE-FC
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:09:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329761369!14134845!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8036 invoked from network); 20 Feb 2012 18:09:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:09:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820591"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:09:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:09:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXfj-0006t6-Oj; Mon, 20 Feb 2012 18:09:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXfj-0005pT-Nd;
	Mon, 20 Feb 2012 18:09:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.35911.688773.697516@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:09:11 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <07bc9ce2378e9271405b.1329297853@probook.site>
References: <07bc9ce2378e9271405b.1329297853@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl: fix xl create/cpupool-create -f help
	output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] xl: fix xl create/cpupool-create -f help output"):
> xl: fix xl create/cpupool-create -f help output

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:10:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXgX-0004pq-IQ; Mon, 20 Feb 2012 18:10:01 +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 1RzXgV-0004pb-Bz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:09:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329761332!61841464!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25842 invoked from network); 20 Feb 2012 18:08:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:08:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:09:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:09:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXgT-0006tM-M3; Mon, 20 Feb 2012 18:09:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXgT-0005pv-LJ;
	Mon, 20 Feb 2012 18:09:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.35957.639800.949064@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:09:57 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5fb2aa61197db9676c11.1329298936@probook.site>
References: <5fb2aa61197db9676c11.1329298936@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.cfg: fix gfx_passthru string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] xl.cfg: fix gfx_passthru string"):
> xl.cfg: fix gfx_passthru string

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:10:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXgX-0004pq-IQ; Mon, 20 Feb 2012 18:10:01 +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 1RzXgV-0004pb-Bz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:09:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329761332!61841464!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25842 invoked from network); 20 Feb 2012 18:08:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:08:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:09:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:09:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXgT-0006tM-M3; Mon, 20 Feb 2012 18:09:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXgT-0005pv-LJ;
	Mon, 20 Feb 2012 18:09:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.35957.639800.949064@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:09:57 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5fb2aa61197db9676c11.1329298936@probook.site>
References: <5fb2aa61197db9676c11.1329298936@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.cfg: fix gfx_passthru string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] xl.cfg: fix gfx_passthru string"):
> xl.cfg: fix gfx_passthru string

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXhT-0004vq-8T; Mon, 20 Feb 2012 18:10: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 1RzXhR-0004va-DJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:10:57 +0000
Received: from [85.158.139.83:65326] by server-6.bemta-5.messagelabs.com id
	1E/0E-27305-0BC824F4; Mon, 20 Feb 2012 18:10:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329761456!15823467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19055 invoked from network); 20 Feb 2012 18:10:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:10:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:10:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXhP-0006tg-Kp; Mon, 20 Feb 2012 18:10:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXhP-0005qA-Jq;
	Mon, 20 Feb 2012 18:10:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.36015.590695.27835@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:10:55 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5a1cbd1af275e6ed1ef6.1329300091@probook.site>
References: <5a1cbd1af275e6ed1ef6.1329300091@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] man/xl.cfg: mention not yet documented
	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

Olaf Hering writes ("[Xen-devel] [PATCH] man/xl.cfg: mention not yet documented options"):
> man/xl.cfg: mention not yet documented options

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXhT-0004vq-8T; Mon, 20 Feb 2012 18:10: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 1RzXhR-0004va-DJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:10:57 +0000
Received: from [85.158.139.83:65326] by server-6.bemta-5.messagelabs.com id
	1E/0E-27305-0BC824F4; Mon, 20 Feb 2012 18:10:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329761456!15823467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19055 invoked from network); 20 Feb 2012 18:10:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:10:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:10:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXhP-0006tg-Kp; Mon, 20 Feb 2012 18:10:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXhP-0005qA-Jq;
	Mon, 20 Feb 2012 18:10:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.36015.590695.27835@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:10:55 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5a1cbd1af275e6ed1ef6.1329300091@probook.site>
References: <5a1cbd1af275e6ed1ef6.1329300091@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] man/xl.cfg: mention not yet documented
	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

Olaf Hering writes ("[Xen-devel] [PATCH] man/xl.cfg: mention not yet documented options"):
> man/xl.cfg: mention not yet documented options

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:11:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXhw-0004zv-19; Mon, 20 Feb 2012 18:11:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXht-0004yX-US
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:11:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329761477!12299660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22216 invoked from network); 20 Feb 2012 18:11:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:11:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:11:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzXhk-0006tv-Fx;
	Mon, 20 Feb 2012 18:11:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzXhj-0001Xe-CW;
	Mon, 20 Feb 2012 18:11:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11984-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 18:11:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11984: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11984 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11984/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11981
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11981
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11981
 build-i386                    2 host-install(2)         broken REGR. vs. 11981
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11981
 build-amd64                   2 host-install(2)         broken REGR. vs. 11981

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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

version targeted for testing:
 xen                  259fac235011
baseline version:
 xen                  87218bd367be

------------------------------------------------------------
People who touched revisions under test:
  Allen Kay <allen.m.kay@intel.com>
  Anthony PERARD <anthony.perard@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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:   24833:259fac235011
tag:         tip
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 17:53:33 2012 +0000
    
    libxl_qmp: Handle unexpected end-of-socket
    
    When read() return 0, the current code just tries again. But this
    leads to an infinite loop if QEMU died too soon.
    
    Also, retry select if a signal was caught.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24832:9cc7961d8f5c
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 20 17:31:49 2012 +0000
    
    libxc: remove tests of alloca() return value
    
    alloca() does not return NULL on an allocation failure on Linux so
    remove the unneccessary tests from this Linux-specific code.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Cc: Santosh Jodh <santosh.jodh@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24831:1c631e901336
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 20 17:30:18 2012 +0000
    
    gitignore: add more files generated in xen/arch/x86/efi to .gitignore
    
    These files were already listed in .hgignore.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24830:db6b998af182
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Thu Jan 19 11:17:35 2012 +0100
    
    libxc/NetBSD: return ioctl return value on error
    
    NetBSD libxc hypercall implementation was returning -errno on error,
    instead of the actual error value from ioctl. Returning error is
    easier to understand, and the caller can always check errno.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Reported-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24829:8a8c6e9a7c43
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Thu Jan 19 11:21:10 2012 +0100
    
    libxc: add comment to why NetBSD return hypercall->retval
    
    Added a comment that explains why NetBSD return hypercall->retval on
    success.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Reported-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24828:1f8ce25dc098
user:        Allen Kay <allen.m.kay@intel.com>
date:        Mon Feb 20 16:46:27 2012 +0000
    
    libxl: Fix yajl-related build error due to missing error value
    
    Some versions of yajl lack yajl_gen_no_buf.
    
    Signed-off-by: Allen Kay <allen.m.kay@intel.com>
    Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24827:fda048a41076
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Mon Feb 20 16:29:19 2012 +0000
    
    QEMU_TAG update
    
    
changeset:   24826:4173658d1af1
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 16:11:38 2012 +0000
    
    xenpaging: mmap guest pages read-only
    
    xenpaging does not write to the gfn, so map the gfn to page-out in
    read-only mode.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24825:87218bd367be
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Feb 17 12:24:38 2012 +0000
    
    arm: fix indentation level in startup_cpu_idle_loop
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:11:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXhw-0004zv-19; Mon, 20 Feb 2012 18:11:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXht-0004yX-US
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:11:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329761477!12299660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22216 invoked from network); 20 Feb 2012 18:11:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:11:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:11:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:11:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzXhk-0006tv-Fx;
	Mon, 20 Feb 2012 18:11:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzXhj-0001Xe-CW;
	Mon, 20 Feb 2012 18:11:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11984-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 18:11:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11984: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11984 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11984/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11981
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11981
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11981
 build-i386                    2 host-install(2)         broken REGR. vs. 11981
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11981
 build-amd64                   2 host-install(2)         broken REGR. vs. 11981

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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

version targeted for testing:
 xen                  259fac235011
baseline version:
 xen                  87218bd367be

------------------------------------------------------------
People who touched revisions under test:
  Allen Kay <allen.m.kay@intel.com>
  Anthony PERARD <anthony.perard@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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:   24833:259fac235011
tag:         tip
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 17:53:33 2012 +0000
    
    libxl_qmp: Handle unexpected end-of-socket
    
    When read() return 0, the current code just tries again. But this
    leads to an infinite loop if QEMU died too soon.
    
    Also, retry select if a signal was caught.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24832:9cc7961d8f5c
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 20 17:31:49 2012 +0000
    
    libxc: remove tests of alloca() return value
    
    alloca() does not return NULL on an allocation failure on Linux so
    remove the unneccessary tests from this Linux-specific code.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Cc: Santosh Jodh <santosh.jodh@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24831:1c631e901336
user:        David Vrabel <david.vrabel@citrix.com>
date:        Mon Feb 20 17:30:18 2012 +0000
    
    gitignore: add more files generated in xen/arch/x86/efi to .gitignore
    
    These files were already listed in .hgignore.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24830:db6b998af182
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Thu Jan 19 11:17:35 2012 +0100
    
    libxc/NetBSD: return ioctl return value on error
    
    NetBSD libxc hypercall implementation was returning -errno on error,
    instead of the actual error value from ioctl. Returning error is
    easier to understand, and the caller can always check errno.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Reported-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24829:8a8c6e9a7c43
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Thu Jan 19 11:21:10 2012 +0100
    
    libxc: add comment to why NetBSD return hypercall->retval
    
    Added a comment that explains why NetBSD return hypercall->retval on
    success.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Reported-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24828:1f8ce25dc098
user:        Allen Kay <allen.m.kay@intel.com>
date:        Mon Feb 20 16:46:27 2012 +0000
    
    libxl: Fix yajl-related build error due to missing error value
    
    Some versions of yajl lack yajl_gen_no_buf.
    
    Signed-off-by: Allen Kay <allen.m.kay@intel.com>
    Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24827:fda048a41076
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Mon Feb 20 16:29:19 2012 +0000
    
    QEMU_TAG update
    
    
changeset:   24826:4173658d1af1
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 16:11:38 2012 +0000
    
    xenpaging: mmap guest pages read-only
    
    xenpaging does not write to the gfn, so map the gfn to page-out in
    read-only mode.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24825:87218bd367be
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Feb 17 12:24:38 2012 +0000
    
    arm: fix indentation level in startup_cpu_idle_loop
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXjs-0005Hk-U6; Mon, 20 Feb 2012 18:13:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXjr-0005HU-Ct
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:13:27 +0000
Received: from [85.158.139.83:57346] by server-5.bemta-5.messagelabs.com id
	8D/45-13566-64D824F4; Mon, 20 Feb 2012 18:13:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329761605!15864549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15552 invoked from network); 20 Feb 2012 18:13: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 Feb 2012 18:13:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:13:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:13:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXjo-0006uU-UB; Mon, 20 Feb 2012 18:13:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXjo-0005qp-T7;
	Mon, 20 Feb 2012 18:13:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.36164.889065.270062@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:13:24 +0000
To: xen.org <ian.jackson@eu.citrix.com>
In-Reply-To: <osstest-11984-mainreport@xen.org>
References: <osstest-11984-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] 11984: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 11984: trouble: blocked/broken"):
> flight 11984 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11984/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           2 host-install(2)     broken REGR. vs. 11981
>  build-i386-oldkern            2 host-install(2)     broken REGR. vs. 11981

As is probably obvious, we have an infrastructure problem.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXjs-0005Hk-U6; Mon, 20 Feb 2012 18:13:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXjr-0005HU-Ct
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:13:27 +0000
Received: from [85.158.139.83:57346] by server-5.bemta-5.messagelabs.com id
	8D/45-13566-64D824F4; Mon, 20 Feb 2012 18:13:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329761605!15864549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15552 invoked from network); 20 Feb 2012 18:13: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 Feb 2012 18:13:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10820756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:13:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:13:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXjo-0006uU-UB; Mon, 20 Feb 2012 18:13:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXjo-0005qp-T7;
	Mon, 20 Feb 2012 18:13:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.36164.889065.270062@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:13:24 +0000
To: xen.org <ian.jackson@eu.citrix.com>
In-Reply-To: <osstest-11984-mainreport@xen.org>
References: <osstest-11984-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] 11984: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 11984: trouble: blocked/broken"):
> flight 11984 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11984/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           2 host-install(2)     broken REGR. vs. 11981
>  build-i386-oldkern            2 host-install(2)     broken REGR. vs. 11981

As is probably obvious, we have an infrastructure problem.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXln-0005Xn-0Q; Mon, 20 Feb 2012 18:15:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXll-0005XO-GJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:25 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20068 invoked from network); 20 Feb 2012 18:14:10 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:10 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPK093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 28137a4e39a3ed61511fdcc21d11760a51a566ad
Message-Id: <28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:22 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0395 (UTC)
	FILETIME=[9CD53530:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 4 v3] blkif.h: Miscelaneous style 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

  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 87218bd367be -r 28137a4e39a3 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Fri Feb 17 12:24:38 2012 +0000
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXln-0005Xn-0Q; Mon, 20 Feb 2012 18:15:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXll-0005XO-GJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:25 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20068 invoked from network); 20 Feb 2012 18:14:10 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:10 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPK093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 28137a4e39a3ed61511fdcc21d11760a51a566ad
Message-Id: <28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:22 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0395 (UTC)
	FILETIME=[9CD53530:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 4 v3] blkif.h: Miscelaneous style 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

  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 87218bd367be -r 28137a4e39a3 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Fri Feb 17 12:24:38 2012 +0000
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXls-0005Zf-Et; Mon, 20 Feb 2012 18:15:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXlq-0005Xw-R1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:31 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 20 Feb 2012 18:14:12 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:12 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPM093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 09051133e2fee4f2e3714e8cbf8d3abfbf7fddba
Message-Id: <09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:24 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0426 (UTC)
	FILETIME=[9CD9F020:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 4 v3] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring 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

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r e79902456819 -r 09051133e2fe xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
@@ -67,6 +67,9 @@
  * XenStore nodes in sections marked "PRIVATE" are solely for use by the
  * driver side whose XenBus tree contains them.
  *
+ * XenStore nodes marked "DEPRECATED" in their notes section should only be
+ * used to provide interoperability with legacy implementations.
+ *
  * See the XenBus state transition diagram below for details on when XenBus
  * nodes must be published and when they can be queried.
  *
@@ -123,12 +126,31 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -136,7 +158,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -180,10 +202,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "number of ring pages"
+ *      sized list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -191,6 +223,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * num-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -208,12 +259,26 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     For full interoperability, block front and backends should publish
+ *     identical ring parameters, adjusted for unit differences, to the
+ *     XenStore nodes used in both schemes.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -231,20 +296,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -261,20 +332,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXls-0005Zf-Et; Mon, 20 Feb 2012 18:15:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXlq-0005Xw-R1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:31 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 20 Feb 2012 18:14:12 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:12 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPM093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 09051133e2fee4f2e3714e8cbf8d3abfbf7fddba
Message-Id: <09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:24 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0426 (UTC)
	FILETIME=[9CD9F020:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 4 v3] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring 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

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r e79902456819 -r 09051133e2fe xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
@@ -67,6 +67,9 @@
  * XenStore nodes in sections marked "PRIVATE" are solely for use by the
  * driver side whose XenBus tree contains them.
  *
+ * XenStore nodes marked "DEPRECATED" in their notes section should only be
+ * used to provide interoperability with legacy implementations.
+ *
  * See the XenBus state transition diagram below for details on when XenBus
  * nodes must be published and when they can be queried.
  *
@@ -123,12 +126,31 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -136,7 +158,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -180,10 +202,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "number of ring pages"
+ *      sized list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -191,6 +223,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * num-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -208,12 +259,26 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     For full interoperability, block front and backends should publish
+ *     identical ring parameters, adjusted for unit differences, to the
+ *     XenStore nodes used in both schemes.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -231,20 +296,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -261,20 +332,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXlp-0005YY-Qa; Mon, 20 Feb 2012 18:15:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXln-0005Xm-DR
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:27 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20150 invoked from network); 20 Feb 2012 18:14:12 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:12 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPL093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: e7990245681961f475fb95c15051bbcc43e17797
Message-Id: <e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:23 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0411 (UTC)
	FILETIME=[9CD7A630:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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

  o Document the XenBus nodes used in this protocol.
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 28137a4e39a3 -r e79902456819 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,253 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------ Backend Device Identification (PRIVATE) ------------------
+ *
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      A free formatted string providing sufficient information for the
+ *      backend driver to open the backing device.  (e.g. the path to the
+ *      file or block device representing the backing store.)
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-aligment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The native sector size, in bytes, of the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of its native
+ *      sector size ("sector-size").
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint32_t>
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ *      See docs/misc/vbd-interface.txt for details on the format of this
+ *      value.
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +304,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * command on a native device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +346,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +360,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXlp-0005YY-Qa; Mon, 20 Feb 2012 18:15:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXln-0005Xm-DR
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:27 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20150 invoked from network); 20 Feb 2012 18:14:12 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:12 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPL093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: e7990245681961f475fb95c15051bbcc43e17797
Message-Id: <e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:23 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0411 (UTC)
	FILETIME=[9CD7A630:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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

  o Document the XenBus nodes used in this protocol.
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 28137a4e39a3 -r e79902456819 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,253 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------ Backend Device Identification (PRIVATE) ------------------
+ *
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      A free formatted string providing sufficient information for the
+ *      backend driver to open the backing device.  (e.g. the path to the
+ *      file or block device representing the backing store.)
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-aligment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The native sector size, in bytes, of the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of its native
+ *      sector size ("sector-size").
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint32_t>
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ *      See docs/misc/vbd-interface.txt for details on the format of this
+ *      value.
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +304,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * command on a native device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +346,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +360,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXlq-0005Yh-8I; Mon, 20 Feb 2012 18:15:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXlo-0005YC-G9
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:28 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20187 invoked from network); 20 Feb 2012 18:14:13 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:13 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPN093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: a777cbc5f48b1547eb3313939c027328f0879179
Message-Id: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:25 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0442 (UTC)
	FILETIME=[9CDC6120:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
      this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
@@ -145,6 +145,32 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the backend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
@@ -242,6 +268,33 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the frontend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -403,11 +456,28 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00040201
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
+#else
+/*
+ * Maximum scatter/gather segments per request (header block only).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#endif
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -422,9 +492,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -432,11 +518,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Mon Feb 20 11:02:53 2012 -0700
+++ b/xen/include/public/xen-compat.h	Mon Feb 20 11:03:01 2012 -0700
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXlq-0005Yh-8I; Mon, 20 Feb 2012 18:15:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXlo-0005YC-G9
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:28 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20187 invoked from network); 20 Feb 2012 18:14:13 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:13 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPN093891;
	Mon, 20 Feb 2012 11:15:23 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: a777cbc5f48b1547eb3313939c027328f0879179
Message-Id: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:25 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0442 (UTC)
	FILETIME=[9CDC6120:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
      this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
+++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
@@ -145,6 +145,32 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the backend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-aligment
@@ -242,6 +268,33 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the frontend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -403,11 +456,28 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00040201
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
+#else
+/*
+ * Maximum scatter/gather segments per request (header block only).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#endif
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -422,9 +492,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -432,11 +518,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Mon Feb 20 11:02:53 2012 -0700
+++ b/xen/include/public/xen-compat.h	Mon Feb 20 11:03:01 2012 -0700
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXln-0005Xx-CK; Mon, 20 Feb 2012 18:15:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXlm-0005XS-1M
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:26 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20127 invoked from network); 20 Feb 2012 18:14:11 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:11 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPJ093891;
	Mon, 20 Feb 2012 11:15:22 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:21 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0379 (UTC)
	FILETIME=[9CD2C430:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 4 v3] blkif.h: Document protocol and
	existing 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

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.

Changes in v3:

patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
         ring extensions.):
  o Mark the RedHat/Amazon EC2 ring extension nodes as deprecated.  While
    there is nothing fundamentally wrong with the method used there, it
    was not publicly documented (not even in patch form), and differs from
    the "page-order" large ring XenBus node convention used for other
    drivers.

patch 4 (blkif.h: Define and document the request number/size/segments
         extension.)
   o Fix typo "max-ring_pages" -> "max-ring-pages".

Changes in v2:

patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
  o Mark backend device identification section as private to the
    backend driver.
  o Refer to docs/misc/vbd-interface.txt for the format of the
    virtual-device front-end node.
  o Correct field size for the virtual-device front-end node.

patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
         ring extensions.):
  o Correct node names for the RedHat/Amazon multi-ring extension.  The
    previous patch mistakenly documented the now defunct FreeBSD extension.
  o Clarify the note on multi-page ring interoperability to indicate that
    identical ring parameters should be published to the XenStore for
    all supported schemes.

v1 patch 4 (Deleted):
  o Remove patch that added the XEN_*_MAJOR definitions.

patch 4 (blkif.h: Define and document the request number/size/segments
         extension.)
  o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
    to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

--
Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:15:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:15:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXln-0005Xx-CK; Mon, 20 Feb 2012 18:15:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzXlm-0005XS-1M
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:15:26 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329761650!62140010!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20127 invoked from network); 20 Feb 2012 18:14:11 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:14:11 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 20 Feb 2012 11:15:23 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1KIFMPJ093891;
	Mon, 20 Feb 2012 11:15:22 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 20 Feb 2012 11:07:21 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 20 Feb 2012 18:15:23.0379 (UTC)
	FILETIME=[9CD2C430:01CCEFFB]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 4 v3] blkif.h: Document protocol and
	existing 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

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.

Changes in v3:

patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
         ring extensions.):
  o Mark the RedHat/Amazon EC2 ring extension nodes as deprecated.  While
    there is nothing fundamentally wrong with the method used there, it
    was not publicly documented (not even in patch form), and differs from
    the "page-order" large ring XenBus node convention used for other
    drivers.

patch 4 (blkif.h: Define and document the request number/size/segments
         extension.)
   o Fix typo "max-ring_pages" -> "max-ring-pages".

Changes in v2:

patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
  o Mark backend device identification section as private to the
    backend driver.
  o Refer to docs/misc/vbd-interface.txt for the format of the
    virtual-device front-end node.
  o Correct field size for the virtual-device front-end node.

patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
         ring extensions.):
  o Correct node names for the RedHat/Amazon multi-ring extension.  The
    previous patch mistakenly documented the now defunct FreeBSD extension.
  o Clarify the note on multi-page ring interoperability to indicate that
    identical ring parameters should be published to the XenStore for
    all supported schemes.

v1 patch 4 (Deleted):
  o Remove patch that added the XEN_*_MAJOR definitions.

patch 4 (blkif.h: Define and document the request number/size/segments
         extension.)
  o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
    to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

--
Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:16:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXmq-0005ua-Uo; Mon, 20 Feb 2012 18:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1RzXmp-0005tS-8z
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:16:31 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329761720!61842013!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4152 invoked from network); 20 Feb 2012 18:15:21 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:15:21 -0000
Received: by yhkk6 with SMTP id k6so77489183yhk.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 10:16:25 -0800 (PST)
Received-SPF: pass (google.com: domain of jrnieder@gmail.com designates
	10.50.94.228 as permitted sender) client-ip=10.50.94.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jrnieder@gmail.com
	designates 10.50.94.228 as permitted sender)
	smtp.mail=jrnieder@gmail.com;
	dkim=pass header.i=jrnieder@gmail.com
Received: from mr.google.com ([10.50.94.228])
	by 10.50.94.228 with SMTP id df4mr14632629igb.12.1329761785974
	(num_hops = 1); Mon, 20 Feb 2012 10:16:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=3KwT7AEZUqJzm02t4jyCZ2IcZ5HBhINehzpNuyw45lo=;
	b=ltWwCP4N5qK4N6lxL2KWUFgIOJCj7FTNVSah/phdmn0P7vjBoFbqUXl2uVsGkCvmfE
	SVjSBOP19GP8riaY4DJ0Kv+tMmVkywjwzC15bleBB/zj5d0JLZt2qrhUsBh+0C1nzRb3
	8eX2yLj8kPyaHGVSrCqIn5zTaPJjVsZVbq5rc=
Received: by 10.50.94.228 with SMTP id df4mr11863062igb.12.1329761785780;
	Mon, 20 Feb 2012 10:16:25 -0800 (PST)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id r18sm29098902ibh.4.2012.02.20.10.16.24
	(version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 10:16:25 -0800 (PST)
Date: Mon, 20 Feb 2012 12:16:18 -0600
From: Jonathan Nieder <jrnieder@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120220181618.GD17566@burratino>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
	<20120219223125.GA820@burratino>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120219223125.GA820@burratino>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Thomas Goirand <zigo@debian.org>, xen-devel@lists.xensource.com,
	William Dauchy <wdauchy@gmail.com>
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Konrad Rzeszutek Wilk wrote:

>> Do you see this if you run a 64-bit dom0?

Looks like no.  Thomas reports[1]:

> I just tried with the amd64 kernel and Xen, and I didn't see any issue.
>
> However, it is important that Xen 4.1 + Linux 3.2 works with a 32 bits
> kernel, because that is the most optimized configuration (eg: 64 bits
> hypervisor, 32 bits kernel and 32 bits userland).

Maybe Andres's patches are relevant.

Hope that helps,
Jonathan

[1] http://bugs.debian.org/660554#25

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:16:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXmq-0005ua-Uo; Mon, 20 Feb 2012 18:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jrnieder@gmail.com>) id 1RzXmp-0005tS-8z
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:16:31 +0000
X-Env-Sender: jrnieder@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329761720!61842013!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4152 invoked from network); 20 Feb 2012 18:15:21 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:15:21 -0000
Received: by yhkk6 with SMTP id k6so77489183yhk.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 10:16:25 -0800 (PST)
Received-SPF: pass (google.com: domain of jrnieder@gmail.com designates
	10.50.94.228 as permitted sender) client-ip=10.50.94.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jrnieder@gmail.com
	designates 10.50.94.228 as permitted sender)
	smtp.mail=jrnieder@gmail.com;
	dkim=pass header.i=jrnieder@gmail.com
Received: from mr.google.com ([10.50.94.228])
	by 10.50.94.228 with SMTP id df4mr14632629igb.12.1329761785974
	(num_hops = 1); Mon, 20 Feb 2012 10:16:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=3KwT7AEZUqJzm02t4jyCZ2IcZ5HBhINehzpNuyw45lo=;
	b=ltWwCP4N5qK4N6lxL2KWUFgIOJCj7FTNVSah/phdmn0P7vjBoFbqUXl2uVsGkCvmfE
	SVjSBOP19GP8riaY4DJ0Kv+tMmVkywjwzC15bleBB/zj5d0JLZt2qrhUsBh+0C1nzRb3
	8eX2yLj8kPyaHGVSrCqIn5zTaPJjVsZVbq5rc=
Received: by 10.50.94.228 with SMTP id df4mr11863062igb.12.1329761785780;
	Mon, 20 Feb 2012 10:16:25 -0800 (PST)
Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9])
	by mx.google.com with ESMTPS id r18sm29098902ibh.4.2012.02.20.10.16.24
	(version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 10:16:25 -0800 (PST)
Date: Mon, 20 Feb 2012 12:16:18 -0600
From: Jonathan Nieder <jrnieder@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120220181618.GD17566@burratino>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
	<20120219223125.GA820@burratino>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120219223125.GA820@burratino>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Thomas Goirand <zigo@debian.org>, xen-devel@lists.xensource.com,
	William Dauchy <wdauchy@gmail.com>
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Konrad Rzeszutek Wilk wrote:

>> Do you see this if you run a 64-bit dom0?

Looks like no.  Thomas reports[1]:

> I just tried with the amd64 kernel and Xen, and I didn't see any issue.
>
> However, it is important that Xen 4.1 + Linux 3.2 works with a 32 bits
> kernel, because that is the most optimized configuration (eg: 64 bits
> hypervisor, 32 bits kernel and 32 bits userland).

Maybe Andres's patches are relevant.

Hope that helps,
Jonathan

[1] http://bugs.debian.org/660554#25

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXnC-00060k-Ci; Mon, 20 Feb 2012 18:16:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXnB-0005yT-Go
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:16:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329761806!14738754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12093 invoked from network); 20 Feb 2012 18:16: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;
	20 Feb 2012 18:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:16:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:16:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzXn3-0006xY-En;
	Mon, 20 Feb 2012 18:16:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzXn3-0008CA-4A;
	Mon, 20 Feb 2012 18:16:45 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11985-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 18:16:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11985: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11985 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11985/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11891
 build-i386                    2 host-install(2)         broken REGR. vs. 11891
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11891
 build-amd64                   2 host-install(2)         broken REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-i386-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-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-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-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  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-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-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-amd64-xl           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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXnC-00060k-Ci; Mon, 20 Feb 2012 18:16:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXnB-0005yT-Go
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:16:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329761806!14738754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12093 invoked from network); 20 Feb 2012 18:16: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;
	20 Feb 2012 18:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:16:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:16:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzXn3-0006xY-En;
	Mon, 20 Feb 2012 18:16:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzXn3-0008CA-4A;
	Mon, 20 Feb 2012 18:16:45 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11985-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 18:16:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11985: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11985 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11985/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11891
 build-i386                    2 host-install(2)         broken REGR. vs. 11891
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11891
 build-amd64                   2 host-install(2)         broken REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-i386-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-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-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-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  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-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-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-amd64-xl           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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:26:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXwM-0006mH-Kx; Mon, 20 Feb 2012 18:26:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RzXwL-0006mC-DI
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:26:21 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329762325!50035636!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzQ3MDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19075 invoked from network); 20 Feb 2012 18:25:26 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:25:26 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1KIQDa6011772;
	Mon, 20 Feb 2012 13:26:13 -0500
Date: Mon, 20 Feb 2012 13:26:13 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <564062b4-ee3a-46b7-b0f3-1d861175af7d@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1329497959-19427-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH v2] blkfront: don't change to closing if
	we're	busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> We just reported to xenbus that we can't close yet, because we're
> still
> in use. So we shouldn't then immediately tell xenbus that we are
> closing. If we do, then we risk bypassing the chance to complain
> again,
> if we're told to close again, and we're still in use. The reason this
> code was here was to implement a deferred close. We can still support
> this feature by adding a member to our private data, and setting that
> instead. Besides being able to complain each time, this patch fixes
> a problem when running on hosts with legacy tools that may interpret
> the lack of a complaint or state=Closing incorrectly, and then yank
> the device out from under the guest.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c
> b/drivers/block/xen-blkfront.c
> index 2f22874..d7f2e03 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -103,6 +103,7 @@ struct blkfront_info
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
>  	int is_ready;
> +	int closing;
>  };
>  
>  static DEFINE_SPINLOCK(blkif_io_lock);
> @@ -1134,7 +1135,7 @@ blkfront_closing(struct blkfront_info *info)
>  	if (bdev->bd_openers) {
>  		xenbus_dev_error(xbdev, -EBUSY,
>  				 "Device in use; refusing to close");
> -		xenbus_switch_state(xbdev, XenbusStateClosing);
> +		info->closing = 1;
>  	} else {
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(xbdev);
> @@ -1423,8 +1424,10 @@ static int blkif_release(struct gendisk *disk,
> fmode_t mode)
>  	mutex_lock(&info->mutex);
>  	xbdev = info->xbdev;
>  
> -	if (xbdev && xbdev->state == XenbusStateClosing) {
> +	if (xbdev && (xbdev->state == XenbusStateClosing || info->closing))

Ugh. This isn't right either. After discussing with Igor Mammedov, I
see that I missed that xbdev->state will now never be XenbusStateClosing.
We need the xenbus_read_driver_state() to come back for getting the
state (that was also changed with 7fd152f4b6ae).

However, I'm starting to wonder if supporting "deferred detach" is
worth the complexity. If we took a pass through xen-blkfront.c and
removed all code related to it, and perhaps also all code related to a
"forced detach", then I suspect the driver could be nicely simplified.

Do we need deferred and forced detach support? Forced seems like a bad
idea. For what would a guest use a disk that could disappear with little
notice? Deferred also seems strange. It seems like the host and guest
admins should generally better coordinate and synchronize these types
of activities. It's possible there are good usecases that I'm missing.
I'd be happy to hear examples.

Thanks,
Drew

> {
>  		/* pending switch to state closed */
> +		if (xbdev->state != XenbusStateClosing)
> +			xenbus_switch_state(xbdev, XenbusStateClosing);
>  		dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(info->xbdev);
> --
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:26:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXwM-0006mH-Kx; Mon, 20 Feb 2012 18:26:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RzXwL-0006mC-DI
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:26:21 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329762325!50035636!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzQ3MDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19075 invoked from network); 20 Feb 2012 18:25:26 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 18:25:26 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1KIQDa6011772;
	Mon, 20 Feb 2012 13:26:13 -0500
Date: Mon, 20 Feb 2012 13:26:13 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <564062b4-ee3a-46b7-b0f3-1d861175af7d@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1329497959-19427-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH v2] blkfront: don't change to closing if
	we're	busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 -----
> We just reported to xenbus that we can't close yet, because we're
> still
> in use. So we shouldn't then immediately tell xenbus that we are
> closing. If we do, then we risk bypassing the chance to complain
> again,
> if we're told to close again, and we're still in use. The reason this
> code was here was to implement a deferred close. We can still support
> this feature by adding a member to our private data, and setting that
> instead. Besides being able to complain each time, this patch fixes
> a problem when running on hosts with legacy tools that may interpret
> the lack of a complaint or state=Closing incorrectly, and then yank
> the device out from under the guest.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c
> b/drivers/block/xen-blkfront.c
> index 2f22874..d7f2e03 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -103,6 +103,7 @@ struct blkfront_info
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
>  	int is_ready;
> +	int closing;
>  };
>  
>  static DEFINE_SPINLOCK(blkif_io_lock);
> @@ -1134,7 +1135,7 @@ blkfront_closing(struct blkfront_info *info)
>  	if (bdev->bd_openers) {
>  		xenbus_dev_error(xbdev, -EBUSY,
>  				 "Device in use; refusing to close");
> -		xenbus_switch_state(xbdev, XenbusStateClosing);
> +		info->closing = 1;
>  	} else {
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(xbdev);
> @@ -1423,8 +1424,10 @@ static int blkif_release(struct gendisk *disk,
> fmode_t mode)
>  	mutex_lock(&info->mutex);
>  	xbdev = info->xbdev;
>  
> -	if (xbdev && xbdev->state == XenbusStateClosing) {
> +	if (xbdev && (xbdev->state == XenbusStateClosing || info->closing))

Ugh. This isn't right either. After discussing with Igor Mammedov, I
see that I missed that xbdev->state will now never be XenbusStateClosing.
We need the xenbus_read_driver_state() to come back for getting the
state (that was also changed with 7fd152f4b6ae).

However, I'm starting to wonder if supporting "deferred detach" is
worth the complexity. If we took a pass through xen-blkfront.c and
removed all code related to it, and perhaps also all code related to a
"forced detach", then I suspect the driver could be nicely simplified.

Do we need deferred and forced detach support? Forced seems like a bad
idea. For what would a guest use a disk that could disappear with little
notice? Deferred also seems strange. It seems like the host and guest
admins should generally better coordinate and synchronize these types
of activities. It's possible there are good usecases that I'm missing.
I'd be happy to hear examples.

Thanks,
Drew

> {
>  		/* pending switch to state closed */
> +		if (xbdev->state != XenbusStateClosing)
> +			xenbus_switch_state(xbdev, XenbusStateClosing);
>  		dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
>  		xlvbd_release_gendisk(info);
>  		xenbus_frontend_closed(info->xbdev);
> --
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:28:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:28:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXxs-0006pt-4G; Mon, 20 Feb 2012 18:27:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXxq-0006pd-IU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:27:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329762467!14167046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3935 invoked from network); 20 Feb 2012 18:27:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:27:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:27:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:27:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXxi-000729-G4; Mon, 20 Feb 2012 18:27:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXxi-0005sU-Ew;
	Mon, 20 Feb 2012 18:27:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37026.399955.178457@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:27:46 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1bdc49548c4f6ef4bff1.1329311512@nehalem1>
References: <1bdc49548c4f6ef4bff1.1329311512@nehalem1>
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] Add xlcpupool.cfg man page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Juergen Gross writes ("[Xen-devel] [PATCH] Add xlcpupool.cfg man page"):
> Add a man page describing the configuration file for creating cpupools
> via xl cpupool-create.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:28:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:28:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzXxs-0006pt-4G; Mon, 20 Feb 2012 18:27:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzXxq-0006pd-IU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:27:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329762467!14167046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3935 invoked from network); 20 Feb 2012 18:27:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:27:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:27:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:27:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXxi-000729-G4; Mon, 20 Feb 2012 18:27:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXxi-0005sU-Ew;
	Mon, 20 Feb 2012 18:27:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37026.399955.178457@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:27:46 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1bdc49548c4f6ef4bff1.1329311512@nehalem1>
References: <1bdc49548c4f6ef4bff1.1329311512@nehalem1>
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] Add xlcpupool.cfg man page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Juergen Gross writes ("[Xen-devel] [PATCH] Add xlcpupool.cfg man page"):
> Add a man page describing the configuration file for creating cpupools
> via xl cpupool-create.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXzb-0006z5-Qy; Mon, 20 Feb 2012 18:29: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 1RzXza-0006yu-P4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:29:42 +0000
Received: from [85.158.139.83:6276] by server-10.bemta-5.messagelabs.com id
	C6/30-07861-611924F4; Mon, 20 Feb 2012 18:29:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329762581!15860299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25971 invoked from network); 20 Feb 2012 18:29:41 -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 Feb 2012 18:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:29:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:29:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXzY-00072p-Ki; Mon, 20 Feb 2012 18:29:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXzY-00066A-Jn;
	Mon, 20 Feb 2012 18:29:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37140.598124.7484@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:29:40 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329323121.31256.324.camel@zakaz.uk.xensource.com>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
	<1329323121.31256.324.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] [PATCH] oxenstored: Fix spelling of "persistent"
 config variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent" config variable"):
> On Wed, 2012-02-15 at 16:10 +0000, Ian Jackson wrote:
> > commit 4e1aba5e529e1d01b02d04546496001e0da452cd
> > Author: Ian Jackson <ian.jackson@eu.citrix.com>
> > Date:   Wed Feb 15 16:09:18 2012 +0000
> > 
> >     oxenstored: Fix spelling of "persistent" config variable
> >     
> >     Change "persistant" to "persistent", in the code and the
> >     example/default config.
> >     
> >     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>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzXzb-0006z5-Qy; Mon, 20 Feb 2012 18:29: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 1RzXza-0006yu-P4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:29:42 +0000
Received: from [85.158.139.83:6276] by server-10.bemta-5.messagelabs.com id
	C6/30-07861-611924F4; Mon, 20 Feb 2012 18:29:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329762581!15860299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25971 invoked from network); 20 Feb 2012 18:29:41 -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 Feb 2012 18:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:29:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:29:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzXzY-00072p-Ki; Mon, 20 Feb 2012 18:29:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzXzY-00066A-Jn;
	Mon, 20 Feb 2012 18:29:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37140.598124.7484@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:29:40 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329323121.31256.324.camel@zakaz.uk.xensource.com>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
	<1329323121.31256.324.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] [PATCH] oxenstored: Fix spelling of "persistent"
 config variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent" config variable"):
> On Wed, 2012-02-15 at 16:10 +0000, Ian Jackson wrote:
> > commit 4e1aba5e529e1d01b02d04546496001e0da452cd
> > Author: Ian Jackson <ian.jackson@eu.citrix.com>
> > Date:   Wed Feb 15 16:09:18 2012 +0000
> > 
> >     oxenstored: Fix spelling of "persistent" config variable
> >     
> >     Change "persistant" to "persistent", in the code and the
> >     example/default config.
> >     
> >     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>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:33:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzY39-0007Cb-Hv; Mon, 20 Feb 2012 18:33:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzY38-0007C3-4Q
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 18:33:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329762795!2773725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14716 invoked from network); 20 Feb 2012 18:33:16 -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;
	20 Feb 2012 18:33:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:33:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:33:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzY30-00074A-UU; Mon, 20 Feb 2012 18:33:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzY30-00066p-TL;
	Mon, 20 Feb 2012 18:33:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37354.897419.528245@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:33:14 +0000
To: Keir Fraser <keir.xen@gmail.com>,
    xen-devel@lists.xen.org
In-Reply-To: <20290.34518.441248.907891@mariner.uk.xensource.com>
References: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
	<20290.34518.441248.907891@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] Hold off on Config.mk etc. patches (Re: [PATCH] build:
	add autoconf to replace custom checks in tools/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

Can we please hold off on applying any further nontrivial Config.mk
changes pending Roger's autoconf series ?  Roger's series seems to
have bitrotted again even though I asked him to rebase it just earlier
this afternoon.

We'll need a day or two because I need to make an associated test
system change.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:33:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzY39-0007Cb-Hv; Mon, 20 Feb 2012 18:33:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzY38-0007C3-4Q
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 18:33:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329762795!2773725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14716 invoked from network); 20 Feb 2012 18:33:16 -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;
	20 Feb 2012 18:33:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:33:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:33:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzY30-00074A-UU; Mon, 20 Feb 2012 18:33:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzY30-00066p-TL;
	Mon, 20 Feb 2012 18:33:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37354.897419.528245@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:33:14 +0000
To: Keir Fraser <keir.xen@gmail.com>,
    xen-devel@lists.xen.org
In-Reply-To: <20290.34518.441248.907891@mariner.uk.xensource.com>
References: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
	<20290.34518.441248.907891@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] Hold off on Config.mk etc. patches (Re: [PATCH] build:
	add autoconf to replace custom checks in tools/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

Can we please hold off on applying any further nontrivial Config.mk
changes pending Roger's autoconf series ?  Roger's series seems to
have bitrotted again even though I asked him to rebase it just earlier
this afternoon.

We'll need a day or two because I need to make an associated test
system change.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzY4e-0007ID-1h; Mon, 20 Feb 2012 18:34:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzY4c-0007I4-NI
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:34:54 +0000
Received: from [85.158.139.83:23598] by server-5.bemta-5.messagelabs.com id
	36/59-13566-D42924F4; Mon, 20 Feb 2012 18:34:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329762893!15225560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16676 invoked from network); 20 Feb 2012 18:34:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:34:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:34:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:34:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzY4a-00074d-PR; Mon, 20 Feb 2012 18:34:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzY4a-00068W-OV;
	Mon, 20 Feb 2012 18:34:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37448.775543.65775@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:34:48 +0000
To: rshriram@cs.ubc.ca
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ae36ea00a09cebdc5a0e.1328838324@athos.nss.cs.ubc.ca>
References: <ae36ea00a09cebdc5a0e.1328838324@athos.nss.cs.ubc.ca>
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] remus: libcheckpoint - initialize
	unused	callback fields to	NULL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH] remus: libcheckpoint - initialize unused callback fields to	NULL"):
> remus: libcheckpoint - initialize unused callback fields to NULL

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzY4e-0007ID-1h; Mon, 20 Feb 2012 18:34:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzY4c-0007I4-NI
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:34:54 +0000
Received: from [85.158.139.83:23598] by server-5.bemta-5.messagelabs.com id
	36/59-13566-D42924F4; Mon, 20 Feb 2012 18:34:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329762893!15225560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16676 invoked from network); 20 Feb 2012 18:34:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:34:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:34:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:34:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzY4a-00074d-PR; Mon, 20 Feb 2012 18:34:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzY4a-00068W-OV;
	Mon, 20 Feb 2012 18:34:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37448.775543.65775@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:34:48 +0000
To: rshriram@cs.ubc.ca
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ae36ea00a09cebdc5a0e.1328838324@athos.nss.cs.ubc.ca>
References: <ae36ea00a09cebdc5a0e.1328838324@athos.nss.cs.ubc.ca>
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] remus: libcheckpoint - initialize
	unused	callback fields to	NULL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH] remus: libcheckpoint - initialize unused callback fields to	NULL"):
> remus: libcheckpoint - initialize unused callback fields to NULL

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:35:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzY5B-0007ML-Fe; Mon, 20 Feb 2012 18:35:29 +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 1RzY59-0007Ly-K1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:35:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329762873!55015601!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5356 invoked from network); 20 Feb 2012 18:34:34 -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; 20 Feb 2012 18:34:34 -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 q1KIZKL1015088
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 18:35:21 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
	q1KIZKm0004944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 18:35:20 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
	q1KIZJOn015207; Mon, 20 Feb 2012 12:35:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 10:35:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 490A340469; Mon, 20 Feb 2012 13:32:07 -0500 (EST)
Date: Mon, 20 Feb 2012 13:32:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120220183207.GA7170@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]
X-CT-RefId: str=0001.0A090207.4F42926A.0017,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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


The combination is bit awkward so not sure why this is happening, but with
Xen 4.1.x hypervisor (64-bit), with a 32-bit dom0 (3.3-rcX or 3.2) and with a 3.3-rcX or 3.2 domU
I get this:

sh-4.1# Feb 20 17:47:41 tst006 init: reloading /etc/inittab
xl info
host                   : tst006.dumpdata.com
release                : 3.3.0-rc4
version                : #1 SMP PREEMPT Mi686
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2333
hw_caps                : bfebfbff:20100800:00000000:00000940:0000e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 4085
free_memory            : 717
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : -120220
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=0xff800000
xen_changeset          : Mon Feb 13 17:57:47 2012 +0000 23225:f2543f449a49
xen_commandline        : com1=115200,8n1 cpufreq=verbose apic=debug apic_verbosity=debug console=com1,vga loglvl=all guest_loglvl=all apic=debug
cc_compiler            : gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) 
cc_compile_by          : konrad
cc_compile_domain      : dumpdata.com
cc_compile_date        : Mon Feb 20 12:25:42 EST 2012
xend_config_format     : 4
sh-4.1# xm create /mnt/lab/latest/test.xm 
Using config file "/mnt/lab/latest/test.xm".
Error: (1, 'Internal error', 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed (rc=-3)')

And only on Intel.. and only if it is a 32-bit dom0. If I do the same test with a 64-bit dom0 I do not see this problem.

Any thoughts of what it might be or what I should try out? My thought
was to swap out the hypervisor (use a Xen 4.0) or unstable and see if I get the same result.
But maybe there is something obvious out there?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:35:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzY5B-0007ML-Fe; Mon, 20 Feb 2012 18:35:29 +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 1RzY59-0007Ly-K1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:35:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329762873!55015601!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5356 invoked from network); 20 Feb 2012 18:34:34 -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; 20 Feb 2012 18:34:34 -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 q1KIZKL1015088
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 18:35:21 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
	q1KIZKm0004944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 18:35:20 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
	q1KIZJOn015207; Mon, 20 Feb 2012 12:35:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 10:35:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 490A340469; Mon, 20 Feb 2012 13:32:07 -0500 (EST)
Date: Mon, 20 Feb 2012 13:32:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120220183207.GA7170@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]
X-CT-RefId: str=0001.0A090207.4F42926A.0017,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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


The combination is bit awkward so not sure why this is happening, but with
Xen 4.1.x hypervisor (64-bit), with a 32-bit dom0 (3.3-rcX or 3.2) and with a 3.3-rcX or 3.2 domU
I get this:

sh-4.1# Feb 20 17:47:41 tst006 init: reloading /etc/inittab
xl info
host                   : tst006.dumpdata.com
release                : 3.3.0-rc4
version                : #1 SMP PREEMPT Mi686
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2333
hw_caps                : bfebfbff:20100800:00000000:00000940:0000e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 4085
free_memory            : 717
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : -120220
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=0xff800000
xen_changeset          : Mon Feb 13 17:57:47 2012 +0000 23225:f2543f449a49
xen_commandline        : com1=115200,8n1 cpufreq=verbose apic=debug apic_verbosity=debug console=com1,vga loglvl=all guest_loglvl=all apic=debug
cc_compiler            : gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) 
cc_compile_by          : konrad
cc_compile_domain      : dumpdata.com
cc_compile_date        : Mon Feb 20 12:25:42 EST 2012
xend_config_format     : 4
sh-4.1# xm create /mnt/lab/latest/test.xm 
Using config file "/mnt/lab/latest/test.xm".
Error: (1, 'Internal error', 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed (rc=-3)')

And only on Intel.. and only if it is a 32-bit dom0. If I do the same test with a 64-bit dom0 I do not see this problem.

Any thoughts of what it might be or what I should try out? My thought
was to swap out the hypervisor (use a Xen 4.0) or unstable and see if I get the same result.
But maybe there is something obvious out there?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:37:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzY6X-0007V4-Vp; Mon, 20 Feb 2012 18:36:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil@recoil.org>) id 1RzY6W-0007Ut-Ul
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:36:53 +0000
Received: from [85.158.139.83:57176] by server-2.bemta-5.messagelabs.com id
	64/AA-20263-4C2924F4; Mon, 20 Feb 2012 18:36:52 +0000
X-Env-Sender: anil@recoil.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329763011!15006285!1
X-Originating-IP: [89.16.177.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30552 invoked from network); 20 Feb 2012 18:36:51 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-14.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 18:36:51 -0000
Received: (qmail 4004 invoked by uid 634); 20 Feb 2012 18:36:51 -0000
X-Spam-Level: *
X-Spam-Status: No, hits=-1.0 required=5.0
	tests=ALL_TRUSTED
X-Spam-Check-By: dark.recoil.org
Received: from freak-0.srg.cl.cam.ac.uk (HELO [192.168.2.8]) (128.232.32.220)
	(smtp-auth username remote@recoil.org, mechanism cram-md5)
	by dark.recoil.org (qpsmtpd/0.84) with ESMTPA;
	Mon, 20 Feb 2012 18:36:50 +0000
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Anil Madhavapeddy <anil@recoil.org>
In-Reply-To: <20283.55535.817293.121382@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:36:49 +0000
Message-Id: <9926A590-3834-401D-8D51-14A85ADAFF3F@recoil.org>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1251.1)
X-Virus-Checked: Checked by ClamAV on dark.recoil.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent"
	config variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shouldn't you also accept "persistant", so that older configs don't just break on upgrade?

-anil

On 15 Feb 2012, at 16:10, Ian Jackson wrote:

> commit 4e1aba5e529e1d01b02d04546496001e0da452cd
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Wed Feb 15 16:09:18 2012 +0000
> 
>    oxenstored: Fix spelling of "persistent" config variable
> 
>    Change "persistant" to "persistent", in the code and the
>    example/default config.
> 
>    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> 
> diff --git a/tools/ocaml/xenstored/oxenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
> index 9616d32..13ee770 100644
> --- a/tools/ocaml/xenstored/oxenstored.conf
> +++ b/tools/ocaml/xenstored/oxenstored.conf
> @@ -20,7 +20,7 @@ quota-maxwatch = 100
> quota-transaction = 10
> 
> # Activate filed base backend
> -persistant = false
> +persistent = false
> 
> # Xenstored logs
> # xenstored-log-file = /var/log/xenstored.log
> diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
> index fdea41a..64cc106 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -86,7 +86,7 @@ let parse_config filename =
> 		("quota-maxentity", Config.Set_int Quota.maxent);
> 		("quota-maxsize", Config.Set_int Quota.maxsize);
> 		("test-eagain", Config.Set_bool Transaction.test_eagain);
> -		("persistant", Config.Set_bool Disk.enable);
> +		("persistent", Config.Set_bool Disk.enable);
> 		("xenstored-log-file", Config.Set_string Logging.xenstored_log_file);
> 		("xenstored-log-level", Config.String
> 			(fun s -> Logging.xenstored_log_level := Logging.level_of_string s));
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:37:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzY6X-0007V4-Vp; Mon, 20 Feb 2012 18:36:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil@recoil.org>) id 1RzY6W-0007Ut-Ul
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:36:53 +0000
Received: from [85.158.139.83:57176] by server-2.bemta-5.messagelabs.com id
	64/AA-20263-4C2924F4; Mon, 20 Feb 2012 18:36:52 +0000
X-Env-Sender: anil@recoil.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329763011!15006285!1
X-Originating-IP: [89.16.177.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30552 invoked from network); 20 Feb 2012 18:36:51 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-14.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 18:36:51 -0000
Received: (qmail 4004 invoked by uid 634); 20 Feb 2012 18:36:51 -0000
X-Spam-Level: *
X-Spam-Status: No, hits=-1.0 required=5.0
	tests=ALL_TRUSTED
X-Spam-Check-By: dark.recoil.org
Received: from freak-0.srg.cl.cam.ac.uk (HELO [192.168.2.8]) (128.232.32.220)
	(smtp-auth username remote@recoil.org, mechanism cram-md5)
	by dark.recoil.org (qpsmtpd/0.84) with ESMTPA;
	Mon, 20 Feb 2012 18:36:50 +0000
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Anil Madhavapeddy <anil@recoil.org>
In-Reply-To: <20283.55535.817293.121382@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:36:49 +0000
Message-Id: <9926A590-3834-401D-8D51-14A85ADAFF3F@recoil.org>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailer: Apple Mail (2.1251.1)
X-Virus-Checked: Checked by ClamAV on dark.recoil.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent"
	config variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shouldn't you also accept "persistant", so that older configs don't just break on upgrade?

-anil

On 15 Feb 2012, at 16:10, Ian Jackson wrote:

> commit 4e1aba5e529e1d01b02d04546496001e0da452cd
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Wed Feb 15 16:09:18 2012 +0000
> 
>    oxenstored: Fix spelling of "persistent" config variable
> 
>    Change "persistant" to "persistent", in the code and the
>    example/default config.
> 
>    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> 
> diff --git a/tools/ocaml/xenstored/oxenstored.conf b/tools/ocaml/xenstored/oxenstored.conf
> index 9616d32..13ee770 100644
> --- a/tools/ocaml/xenstored/oxenstored.conf
> +++ b/tools/ocaml/xenstored/oxenstored.conf
> @@ -20,7 +20,7 @@ quota-maxwatch = 100
> quota-transaction = 10
> 
> # Activate filed base backend
> -persistant = false
> +persistent = false
> 
> # Xenstored logs
> # xenstored-log-file = /var/log/xenstored.log
> diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
> index fdea41a..64cc106 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -86,7 +86,7 @@ let parse_config filename =
> 		("quota-maxentity", Config.Set_int Quota.maxent);
> 		("quota-maxsize", Config.Set_int Quota.maxsize);
> 		("test-eagain", Config.Set_bool Transaction.test_eagain);
> -		("persistant", Config.Set_bool Disk.enable);
> +		("persistent", Config.Set_bool Disk.enable);
> 		("xenstored-log-file", Config.Set_string Logging.xenstored_log_file);
> 		("xenstored-log-level", Config.String
> 			(fun s -> Logging.xenstored_log_level := Logging.level_of_string s));
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYAI-0007p3-Kw; Mon, 20 Feb 2012 18:40: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 1RzYAH-0007op-1m
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:40:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329763185!57472635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18963 invoked from network); 20 Feb 2012 18:39:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821380"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:40:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzY9u-00076X-Mq; Mon, 20 Feb 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzY9u-000698-Lp;
	Mon, 20 Feb 2012 18:40:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37782.664940.367277@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:40:22 +0000
To: Anil Madhavapeddy <anil@recoil.org>
In-Reply-To: <9926A590-3834-401D-8D51-14A85ADAFF3F@recoil.org>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
	<9926A590-3834-401D-8D51-14A85ADAFF3F@recoil.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] [PATCH] oxenstored: Fix spelling of "persistent"
 config variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anil Madhavapeddy writes ("Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent" config variable"):
> Shouldn't you also accept "persistant", so that older configs don't just break on upgrade?

I don't think there can be many older configs TBH.  oxenstored hasn't
been available in xen upstream very long.

But if you would like to send a patch to do that I'd take it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYAI-0007p3-Kw; Mon, 20 Feb 2012 18:40: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 1RzYAH-0007op-1m
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:40:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329763185!57472635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18963 invoked from network); 20 Feb 2012 18:39:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821380"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:40:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:40:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzY9u-00076X-Mq; Mon, 20 Feb 2012 18:40:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzY9u-000698-Lp;
	Mon, 20 Feb 2012 18:40:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37782.664940.367277@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:40:22 +0000
To: Anil Madhavapeddy <anil@recoil.org>
In-Reply-To: <9926A590-3834-401D-8D51-14A85ADAFF3F@recoil.org>
References: <20283.55535.817293.121382@mariner.uk.xensource.com>
	<9926A590-3834-401D-8D51-14A85ADAFF3F@recoil.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] [PATCH] oxenstored: Fix spelling of "persistent"
 config variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anil Madhavapeddy writes ("Re: [Xen-devel] [PATCH] oxenstored: Fix spelling of "persistent" config variable"):
> Shouldn't you also accept "persistant", so that older configs don't just break on upgrade?

I don't think there can be many older configs TBH.  oxenstored hasn't
been available in xen upstream very long.

But if you would like to send a patch to do that I'd take it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:42:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYBS-0007ud-5H; Mon, 20 Feb 2012 18:41:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYBQ-0007uI-Q3
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:41:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329763310!14137585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10186 invoked from network); 20 Feb 2012 18:41:50 -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;
	20 Feb 2012 18:41:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:41:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:41:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYBK-000770-8N; Mon, 20 Feb 2012 18:41:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYBK-00069W-7F;
	Mon, 20 Feb 2012 18:41:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37870.207166.365954@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:41:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328788790.6133.148.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> > Pass PYTHON=$(PYTHON) to gmake when building seabios.
> > This fixes seabios build error
> > 'python not found'
> > along with the patches from Kevin O'Connor.
> > 
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Thanks for this.  I'm going to hold off on this though for the moment
in case it conflicts with Roger's autoconf patch.  Also I'm afraid it
needs a refresh anyway.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:42:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYBS-0007ud-5H; Mon, 20 Feb 2012 18:41:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYBQ-0007uI-Q3
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:41:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329763310!14137585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10186 invoked from network); 20 Feb 2012 18:41:50 -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;
	20 Feb 2012 18:41:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:41:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:41:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYBK-000770-8N; Mon, 20 Feb 2012 18:41:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYBK-00069W-7F;
	Mon, 20 Feb 2012 18:41:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.37870.207166.365954@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:41:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328788790.6133.148.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> > Pass PYTHON=$(PYTHON) to gmake when building seabios.
> > This fixes seabios build error
> > 'python not found'
> > along with the patches from Kevin O'Connor.
> > 
> > Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Thanks for this.  I'm going to hold off on this though for the moment
in case it conflicts with Roger's autoconf patch.  Also I'm afraid it
needs a refresh anyway.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:44:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYDm-00084i-Pb; Mon, 20 Feb 2012 18:44:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYDm-00084A-0W
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:44:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329763455!13986906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26376 invoked from network); 20 Feb 2012 18:44:16 -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;
	20 Feb 2012 18:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:44:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:44:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYDf-00077h-GF; Mon, 20 Feb 2012 18:44:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYDf-0006A0-FM;
	Mon, 20 Feb 2012 18:44:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38015.460233.816604@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:44:15 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F33C6C6.30005@amd.com>
References: <4F33C6C6.30005@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add 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

Christoph Egger writes ("[Xen-devel] [PATCH] libxl: add missing includes"):
> 
> include <poll.h> for struct pollfd
> include <time.h> for struct timeval
> Fixes gcc complaints about implicit declaration.

According to SuS, it should be <sys/time.h>.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:44:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYDm-00084i-Pb; Mon, 20 Feb 2012 18:44:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYDm-00084A-0W
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:44:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329763455!13986906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26376 invoked from network); 20 Feb 2012 18:44:16 -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;
	20 Feb 2012 18:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:44:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:44:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYDf-00077h-GF; Mon, 20 Feb 2012 18:44:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYDf-0006A0-FM;
	Mon, 20 Feb 2012 18:44:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38015.460233.816604@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:44:15 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F33C6C6.30005@amd.com>
References: <4F33C6C6.30005@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add 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

Christoph Egger writes ("[Xen-devel] [PATCH] libxl: add missing includes"):
> 
> include <poll.h> for struct pollfd
> include <time.h> for struct timeval
> Fixes gcc complaints about implicit declaration.

According to SuS, it should be <sys/time.h>.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYEf-0008BY-Ai; Mon, 20 Feb 2012 18:45:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzYEd-0008BG-G4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:45:15 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329763483!57488338!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23056 invoked from network); 20 Feb 2012 18:44:43 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:44:43 -0000
Received: by werb14 with SMTP id b14so12924747wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 10:45:13 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr26010310wia.3.1329763513739 (num_hops
	= 1); Mon, 20 Feb 2012 10:45:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr21734873wia.3.1329763513649; Mon,
	20 Feb 2012 10:45:13 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 10:45:13 -0800 (PST)
In-Reply-To: <1329756300.3990.78.camel@zakaz.uk.xensource.com>
References: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
	<1329756300.3990.78.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 10:45:13 -0800
Message-ID: <CAMrHX2VZKYJ8qQ+n2hAn2vmLjtDZNcguXddoYLAtZK_Lkw=Mdg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQndkcsaV99SwA0Lu0JxvJSxGMG8pdWYBsEnsGLYNUPzmhtuSwZdm/XUWpL5wkBk2SxHskRx
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6914899285301028911=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6914899285301028911==
Content-Type: multipart/alternative; boundary=90e6ba211f1bddc99f04b969b1eb

--90e6ba211f1bddc99f04b969b1eb
Content-Type: text/plain; charset=ISO-8859-1

On 20 February 2012 08:45, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-02-17 at 22:56 +0000, Matthew Hook wrote:
> > I think this is a bug in the xl toolchain.
>
> I agree.
>
> Which version of Xen are you running? There have been various fixes to
> the stuff in xen-unstable but from your error message (which doesn't
> appear in the unstable code base AFAICT) I guess you are running 4.1.
> Are you able to try unstable?


I'm running release Xen 4.1.2 with some AMD graphics patches applied.
This is the hypervisor installed onto Ubuntu 10.04 LTS with Linux Kernel
from
the jeremy branch 2.6.32.48


> lspci -s 0000:12:0.*
> > 12:00.0 Display controller: ATI Technologies Inc Device 671d
> > 12:00.1 Audio device: ATI Technologies Inc Device aa80
> >
> > sudo xm pci-list-assignable-devices
>
> NB: it is not recommended to mix and match xm and xl.
>
> I found some odd behaviour with XL in that it wouldn't clean up the
domains properly after
shutting down.  I wasn't sure whether it was a bug in XL or related to the
AMD passthru graphics
patches that I have applied.  Using XM and I wasn't having that issue.  I
will be testing this without
the patches today to narrow that issue down.


> > 0000:13:00.0
> > 0000:13:00.1
> > 0000:12:00.0
> > 0000:12:00.1
> >
> > So there is a multi-function device (actually one ASIC of a AMD Radeon
> > 6990 card).
> > It has two function addresses 0 = Display controller, 1 = Audio Device.
> >
> > However when running xl create where the line for pci is of the form
> > pci=['12:00.*']
> > Where * means pass through all devices, you get an error as below.
> >
> > Parsing config file xenwin7-1.cfg
> > xc: info: VIRTUAL MEMORY ARRANGEMENT:
> >   Loader:        0000000000100000->0000000000179830
> >   TOTAL:         0000000000000000->000000007f800000
> >   ENTRY ADDRESS: 0000000000100000
> > xc: info: PHYSICAL MEMORY ALLOCATION:
> >   4KB PAGES: 0x0000000000000200
> >   2MB PAGES: 0x00000000000003fb
> >   1GB PAGES: 0x0000000000000000
> > libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device
> > 0:12:0.70 is not assignable
> >
> > There is no function 70 on that device.
>
> The * turns into a "LIBXL_PCI_FUNC_ALL (~0U)" in the internal
> represenation, I bet this is some sort unhelpful and confusing of
> formatting snafu related to that.
>

I guess.  For this version I just have to explicitly list every PCI
address, function.


>
> > In relation to that, the BDF documentation
> > (http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
> > you can specify
> > the extended BDF notation on your kernel boot line in grub.  i.e.
> > xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
> > the kernel log.
>
> That is the old wiki, the new page seems to be
> http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation -- does this
> still give you that impression? Please feel free to update to clarify.
>
> Yes, the new wiki still gives the impression you can use the extended
notation everywhere.
It'd be useful of the kernel boot line could take the extended notation.
We are passing through many multi-function devices so the list gets quite
large.


> Actually, if you look at the code for pci_stub.c in the linux kernel
> > (at least for Jeremy branch 2.6.32.48), extended BDF is not supported.
>
> Right, I think that wiki page is trying to refer only to the notation
> used by the toolstack. I imagine that could be clearer.
>
> Ian.
>
> I might add some comments about the kernel boot line to the BDF wiki.
Thanks for your input.

Matt

--90e6ba211f1bddc99f04b969b1eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 20 February 2012 08:45, Ian Campbell <span di=
r=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citri=
x.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Fri, 2012-02-17 at 22:56 +0000, Matthew Hook wrote:<br=
>
&gt; I think this is a bug in the xl toolchain.<br>
<br>
</div>I agree.<br>
<br>
Which version of Xen are you running? There have been various fixes to<br>
the stuff in xen-unstable but from your error message (which doesn&#39;t<br=
>
appear in the unstable code base AFAICT) I guess you are running 4.1.<br>
Are you able to try unstable?</blockquote><div><br></div><div>I&#39;m runni=
ng release Xen 4.1.2 with some AMD graphics patches applied.</div><div>This=
 is the hypervisor installed onto Ubuntu 10.04 LTS with Linux Kernel from=
=A0</div>
<div>the jeremy=A0branch 2.6.32.48</div><div><br></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"><div class=3D"im">
&gt; lspci -s 0000:12:0.*<br>
&gt; 12:00.0 Display controller: ATI Technologies Inc Device 671d<br>
&gt; 12:00.1 Audio device: ATI Technologies Inc Device aa80<br>
&gt;<br>
&gt; sudo xm pci-list-assignable-devices<br>
<br>
</div>NB: it is not recommended to mix and match xm and xl.<br>
<div class=3D"im"><br></div></blockquote><div>I found some odd behaviour wi=
th XL in that it wouldn&#39;t clean up the domains properly after</div><div=
>shutting down. =A0I wasn&#39;t sure whether it was a bug in XL or related =
to the AMD passthru graphics</div>
<div>patches that I have applied. =A0Using XM and I wasn&#39;t having that =
issue. =A0I will be testing this without</div><div>the patches today to nar=
row that issue down.</div><div>=A0</div><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">
&gt; 0000:13:00.0<br>
&gt; 0000:13:00.1<br>
&gt; 0000:12:00.0<br>
&gt; 0000:12:00.1<br>
&gt;<br>
&gt; So there is a multi-function device (actually one ASIC of a AMD Radeon=
<br>
&gt; 6990 card).<br>
&gt; It has two function addresses 0 =3D Display controller, 1 =3D Audio De=
vice.<br>
&gt;<br>
&gt; However when running xl create where the line for pci is of the form<b=
r>
&gt; pci=3D[&#39;12:00.*&#39;]<br>
&gt; Where * means pass through all devices, you get an error as below.<br>
&gt;<br>
&gt; Parsing config file xenwin7-1.cfg<br>
&gt; xc: info: VIRTUAL MEMORY ARRANGEMENT:<br>
&gt; =A0 Loader: =A0 =A0 =A0 =A00000000000100000-&gt;0000000000179830<br>
&gt; =A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000-&gt;000000007f800000<br>
&gt; =A0 ENTRY ADDRESS: 0000000000100000<br>
&gt; xc: info: PHYSICAL MEMORY ALLOCATION:<br>
&gt; =A0 4KB PAGES: 0x0000000000000200<br>
&gt; =A0 2MB PAGES: 0x00000000000003fb<br>
&gt; =A0 1GB PAGES: 0x0000000000000000<br>
&gt; libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device<br>
&gt; 0:12:0.70 is not assignable<br>
&gt;<br>
&gt; There is no function 70 on that device.<br>
<br>
</div>The * turns into a &quot;LIBXL_PCI_FUNC_ALL (~0U)&quot; in the intern=
al<br>
represenation, I bet this is some sort unhelpful and confusing of<br>
formatting snafu related to that.<br></blockquote><div><br></div><div>I gue=
ss. =A0For this version I just have to=A0explicitly list every PCI address,=
 function.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br>
&gt; In relation to that, the BDF documentation<br>
&gt; (<a href=3D"http://wiki.xensource.com/xenwiki/BDFNotation" target=3D"_=
blank">http://wiki.xensource.com/xenwiki/BDFNotation</a>) seems to imply th=
at<br>
&gt; you can specify<br>
&gt; the extended BDF notation on your kernel boot line in grub. =A0i.e.<br=
>
&gt; xen-pciback.hide=3D(0000:12:00.*) does not work. =A0You&#39;ll get an =
error in<br>
&gt; the kernel log.<br>
<br>
</div>That is the old wiki, the new page seems to be<br>
<a href=3D"http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation" tar=
get=3D"_blank">http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation<=
/a> -- does this<br>
still give you that impression? Please feel free to update to clarify.<br>
<div class=3D"im"><br></div></blockquote><div>Yes, the new wiki still gives=
 the impression you can use the extended notation everywhere.</div><div>It&=
#39;d be useful of the kernel boot line could take the extended notation.</=
div>
<div>We are passing through many multi-function devices so the list gets qu=
ite large.</div><div><br></div><div><br></div><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; Actually, if you look at the code for pci_stub.c in the linux kernel<b=
r>
&gt; (at least for Jeremy branch 2.6.32.48), extended BDF is not supported.=
<br>
<br>
</div>Right, I think that wiki page is trying to refer only to the notation=
<br>
used by the toolstack. I imagine that could be clearer.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><div>I might add some comments about the k=
ernel boot line to the BDF wiki.</div><div>Thanks for your input.</div><div=
><br></div><div>Matt</div><div><br></div>

--90e6ba211f1bddc99f04b969b1eb--


--===============6914899285301028911==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============6914899285301028911==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 18:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYEf-0008BY-Ai; Mon, 20 Feb 2012 18:45:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzYEd-0008BG-G4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:45:15 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329763483!57488338!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23056 invoked from network); 20 Feb 2012 18:44:43 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:44:43 -0000
Received: by werb14 with SMTP id b14so12924747wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 10:45:13 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr26010310wia.3.1329763513739 (num_hops
	= 1); Mon, 20 Feb 2012 10:45:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr21734873wia.3.1329763513649; Mon,
	20 Feb 2012 10:45:13 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 10:45:13 -0800 (PST)
In-Reply-To: <1329756300.3990.78.camel@zakaz.uk.xensource.com>
References: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
	<1329756300.3990.78.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 10:45:13 -0800
Message-ID: <CAMrHX2VZKYJ8qQ+n2hAn2vmLjtDZNcguXddoYLAtZK_Lkw=Mdg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQndkcsaV99SwA0Lu0JxvJSxGMG8pdWYBsEnsGLYNUPzmhtuSwZdm/XUWpL5wkBk2SxHskRx
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6914899285301028911=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6914899285301028911==
Content-Type: multipart/alternative; boundary=90e6ba211f1bddc99f04b969b1eb

--90e6ba211f1bddc99f04b969b1eb
Content-Type: text/plain; charset=ISO-8859-1

On 20 February 2012 08:45, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-02-17 at 22:56 +0000, Matthew Hook wrote:
> > I think this is a bug in the xl toolchain.
>
> I agree.
>
> Which version of Xen are you running? There have been various fixes to
> the stuff in xen-unstable but from your error message (which doesn't
> appear in the unstable code base AFAICT) I guess you are running 4.1.
> Are you able to try unstable?


I'm running release Xen 4.1.2 with some AMD graphics patches applied.
This is the hypervisor installed onto Ubuntu 10.04 LTS with Linux Kernel
from
the jeremy branch 2.6.32.48


> lspci -s 0000:12:0.*
> > 12:00.0 Display controller: ATI Technologies Inc Device 671d
> > 12:00.1 Audio device: ATI Technologies Inc Device aa80
> >
> > sudo xm pci-list-assignable-devices
>
> NB: it is not recommended to mix and match xm and xl.
>
> I found some odd behaviour with XL in that it wouldn't clean up the
domains properly after
shutting down.  I wasn't sure whether it was a bug in XL or related to the
AMD passthru graphics
patches that I have applied.  Using XM and I wasn't having that issue.  I
will be testing this without
the patches today to narrow that issue down.


> > 0000:13:00.0
> > 0000:13:00.1
> > 0000:12:00.0
> > 0000:12:00.1
> >
> > So there is a multi-function device (actually one ASIC of a AMD Radeon
> > 6990 card).
> > It has two function addresses 0 = Display controller, 1 = Audio Device.
> >
> > However when running xl create where the line for pci is of the form
> > pci=['12:00.*']
> > Where * means pass through all devices, you get an error as below.
> >
> > Parsing config file xenwin7-1.cfg
> > xc: info: VIRTUAL MEMORY ARRANGEMENT:
> >   Loader:        0000000000100000->0000000000179830
> >   TOTAL:         0000000000000000->000000007f800000
> >   ENTRY ADDRESS: 0000000000100000
> > xc: info: PHYSICAL MEMORY ALLOCATION:
> >   4KB PAGES: 0x0000000000000200
> >   2MB PAGES: 0x00000000000003fb
> >   1GB PAGES: 0x0000000000000000
> > libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device
> > 0:12:0.70 is not assignable
> >
> > There is no function 70 on that device.
>
> The * turns into a "LIBXL_PCI_FUNC_ALL (~0U)" in the internal
> represenation, I bet this is some sort unhelpful and confusing of
> formatting snafu related to that.
>

I guess.  For this version I just have to explicitly list every PCI
address, function.


>
> > In relation to that, the BDF documentation
> > (http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
> > you can specify
> > the extended BDF notation on your kernel boot line in grub.  i.e.
> > xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
> > the kernel log.
>
> That is the old wiki, the new page seems to be
> http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation -- does this
> still give you that impression? Please feel free to update to clarify.
>
> Yes, the new wiki still gives the impression you can use the extended
notation everywhere.
It'd be useful of the kernel boot line could take the extended notation.
We are passing through many multi-function devices so the list gets quite
large.


> Actually, if you look at the code for pci_stub.c in the linux kernel
> > (at least for Jeremy branch 2.6.32.48), extended BDF is not supported.
>
> Right, I think that wiki page is trying to refer only to the notation
> used by the toolstack. I imagine that could be clearer.
>
> Ian.
>
> I might add some comments about the kernel boot line to the BDF wiki.
Thanks for your input.

Matt

--90e6ba211f1bddc99f04b969b1eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 20 February 2012 08:45, Ian Campbell <span di=
r=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citri=
x.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Fri, 2012-02-17 at 22:56 +0000, Matthew Hook wrote:<br=
>
&gt; I think this is a bug in the xl toolchain.<br>
<br>
</div>I agree.<br>
<br>
Which version of Xen are you running? There have been various fixes to<br>
the stuff in xen-unstable but from your error message (which doesn&#39;t<br=
>
appear in the unstable code base AFAICT) I guess you are running 4.1.<br>
Are you able to try unstable?</blockquote><div><br></div><div>I&#39;m runni=
ng release Xen 4.1.2 with some AMD graphics patches applied.</div><div>This=
 is the hypervisor installed onto Ubuntu 10.04 LTS with Linux Kernel from=
=A0</div>
<div>the jeremy=A0branch 2.6.32.48</div><div><br></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"><div class=3D"im">
&gt; lspci -s 0000:12:0.*<br>
&gt; 12:00.0 Display controller: ATI Technologies Inc Device 671d<br>
&gt; 12:00.1 Audio device: ATI Technologies Inc Device aa80<br>
&gt;<br>
&gt; sudo xm pci-list-assignable-devices<br>
<br>
</div>NB: it is not recommended to mix and match xm and xl.<br>
<div class=3D"im"><br></div></blockquote><div>I found some odd behaviour wi=
th XL in that it wouldn&#39;t clean up the domains properly after</div><div=
>shutting down. =A0I wasn&#39;t sure whether it was a bug in XL or related =
to the AMD passthru graphics</div>
<div>patches that I have applied. =A0Using XM and I wasn&#39;t having that =
issue. =A0I will be testing this without</div><div>the patches today to nar=
row that issue down.</div><div>=A0</div><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">
&gt; 0000:13:00.0<br>
&gt; 0000:13:00.1<br>
&gt; 0000:12:00.0<br>
&gt; 0000:12:00.1<br>
&gt;<br>
&gt; So there is a multi-function device (actually one ASIC of a AMD Radeon=
<br>
&gt; 6990 card).<br>
&gt; It has two function addresses 0 =3D Display controller, 1 =3D Audio De=
vice.<br>
&gt;<br>
&gt; However when running xl create where the line for pci is of the form<b=
r>
&gt; pci=3D[&#39;12:00.*&#39;]<br>
&gt; Where * means pass through all devices, you get an error as below.<br>
&gt;<br>
&gt; Parsing config file xenwin7-1.cfg<br>
&gt; xc: info: VIRTUAL MEMORY ARRANGEMENT:<br>
&gt; =A0 Loader: =A0 =A0 =A0 =A00000000000100000-&gt;0000000000179830<br>
&gt; =A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000-&gt;000000007f800000<br>
&gt; =A0 ENTRY ADDRESS: 0000000000100000<br>
&gt; xc: info: PHYSICAL MEMORY ALLOCATION:<br>
&gt; =A0 4KB PAGES: 0x0000000000000200<br>
&gt; =A0 2MB PAGES: 0x00000000000003fb<br>
&gt; =A0 1GB PAGES: 0x0000000000000000<br>
&gt; libxl: error: libxl_pci.c:790:libxl__device_pci_add PCI device<br>
&gt; 0:12:0.70 is not assignable<br>
&gt;<br>
&gt; There is no function 70 on that device.<br>
<br>
</div>The * turns into a &quot;LIBXL_PCI_FUNC_ALL (~0U)&quot; in the intern=
al<br>
represenation, I bet this is some sort unhelpful and confusing of<br>
formatting snafu related to that.<br></blockquote><div><br></div><div>I gue=
ss. =A0For this version I just have to=A0explicitly list every PCI address,=
 function.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br>
&gt; In relation to that, the BDF documentation<br>
&gt; (<a href=3D"http://wiki.xensource.com/xenwiki/BDFNotation" target=3D"_=
blank">http://wiki.xensource.com/xenwiki/BDFNotation</a>) seems to imply th=
at<br>
&gt; you can specify<br>
&gt; the extended BDF notation on your kernel boot line in grub. =A0i.e.<br=
>
&gt; xen-pciback.hide=3D(0000:12:00.*) does not work. =A0You&#39;ll get an =
error in<br>
&gt; the kernel log.<br>
<br>
</div>That is the old wiki, the new page seems to be<br>
<a href=3D"http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation" tar=
get=3D"_blank">http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation<=
/a> -- does this<br>
still give you that impression? Please feel free to update to clarify.<br>
<div class=3D"im"><br></div></blockquote><div>Yes, the new wiki still gives=
 the impression you can use the extended notation everywhere.</div><div>It&=
#39;d be useful of the kernel boot line could take the extended notation.</=
div>
<div>We are passing through many multi-function devices so the list gets qu=
ite large.</div><div><br></div><div><br></div><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; Actually, if you look at the code for pci_stub.c in the linux kernel<b=
r>
&gt; (at least for Jeremy branch 2.6.32.48), extended BDF is not supported.=
<br>
<br>
</div>Right, I think that wiki page is trying to refer only to the notation=
<br>
used by the toolstack. I imagine that could be clearer.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><div>I might add some comments about the k=
ernel boot line to the BDF wiki.</div><div>Thanks for your input.</div><div=
><br></div><div>Matt</div><div><br></div>

--90e6ba211f1bddc99f04b969b1eb--


--===============6914899285301028911==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============6914899285301028911==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 18:47:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYGS-0008Rb-1J; Mon, 20 Feb 2012 18:47:08 +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 1RzYGQ-0008Qh-Go
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:47:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329763575!60897060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3774 invoked from network); 20 Feb 2012 18:46:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:47:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:47:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYGK-00078d-4I; Mon, 20 Feb 2012 18:47:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYGK-0006H2-3M;
	Mon, 20 Feb 2012 18:47:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38180.84346.464128@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:47:00 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 0/3] Set VNC password to QEMU upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH V2 0/3] Set VNC password to QEMU upstream"):
> Anthony PERARD (3):
>   libxl_qmp: Use GC instead of CTX as parameter for _initialize.
>   Provide dm_vnc() as a in libxl helper.
>   libxl: Set VNC password through QMP

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:47:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYGS-0008Rb-1J; Mon, 20 Feb 2012 18:47:08 +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 1RzYGQ-0008Qh-Go
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:47:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329763575!60897060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3774 invoked from network); 20 Feb 2012 18:46:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:46:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:47:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:47:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYGK-00078d-4I; Mon, 20 Feb 2012 18:47:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYGK-0006H2-3M;
	Mon, 20 Feb 2012 18:47:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38180.84346.464128@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:47:00 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
References: <1328796398-2242-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 0/3] Set VNC password to QEMU upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH V2 0/3] Set VNC password to QEMU upstream"):
> Anthony PERARD (3):
>   libxl_qmp: Use GC instead of CTX as parameter for _initialize.
>   Provide dm_vnc() as a in libxl helper.
>   libxl: Set VNC password through QMP

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:48:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:48: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 1RzYHn-00009D-Ga; Mon, 20 Feb 2012 18:48:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzYHl-00008X-Vj
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:48:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329763703!14156630!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11829 invoked from network); 20 Feb 2012 18:48:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 18:48:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329763703; l=874;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=4Ix+kEMyJfLayPivVmk0rIwTVpk=;
	b=T+zWwvU158FSUMZ2NN/QUWuTidBR8VD3TAxSty6Aztk1G5hYcrdh/2wnHcv2yDBu3bf
	V8/tWTxgesyAKSB9DLoEihD4q5uSFmA0JD7ezMLmr2g0mBgc3gIZd+XcHgrQxx1r5X0pb
	BFueBlSnn89C3aMROYch6soKn9Hu1DQnX/U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo53) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2017aco1KHRp6L ;
	Mon, 20 Feb 2012 19:48:18 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0F3C018638; Mon, 20 Feb 2012 19:48:15 +0100 (CET)
Date: Mon, 20 Feb 2012 19:48:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120220184815.GA22275@aepfle.de>
References: <patchbomb.1327939163@probook.site>
	<20276.2335.273506.959266@mariner.uk.xensource.com>
	<b7906ad2815304272686.1327939169@probook.site>
	<20120214210851.GA21988@aepfle.de>
	<20290.33301.89584.251547@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20290.33301.89584.251547@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, Ian Jackson wrote:

> Ian Jackson writes ("Re: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> > Olaf Hering writes ("[Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> > > This series adjusts the error reporting in the various code paths, with
> > > the intention that fatal errors can be detected by callers and handled
> > > properly. During my performance analysis with callgrind I found and
> > > fixed a few bottlenecks in the page-in code paths.
> > 
> > Since these are all xenpaging changes, I'm inclined to follow your
> > lead and commit them soon.  If anyone has any comments, please shout!
> 
> Olaf, can you please rebase to current tip ?  The other recent
> xenpaging changes conflict with these.

I will send a rebased version of this series.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:48:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:48: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 1RzYHn-00009D-Ga; Mon, 20 Feb 2012 18:48:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzYHl-00008X-Vj
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:48:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329763703!14156630!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11829 invoked from network); 20 Feb 2012 18:48:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 18:48:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329763703; l=874;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=4Ix+kEMyJfLayPivVmk0rIwTVpk=;
	b=T+zWwvU158FSUMZ2NN/QUWuTidBR8VD3TAxSty6Aztk1G5hYcrdh/2wnHcv2yDBu3bf
	V8/tWTxgesyAKSB9DLoEihD4q5uSFmA0JD7ezMLmr2g0mBgc3gIZd+XcHgrQxx1r5X0pb
	BFueBlSnn89C3aMROYch6soKn9Hu1DQnX/U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo53) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2017aco1KHRp6L ;
	Mon, 20 Feb 2012 19:48:18 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0F3C018638; Mon, 20 Feb 2012 19:48:15 +0100 (CET)
Date: Mon, 20 Feb 2012 19:48:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120220184815.GA22275@aepfle.de>
References: <patchbomb.1327939163@probook.site>
	<20276.2335.273506.959266@mariner.uk.xensource.com>
	<b7906ad2815304272686.1327939169@probook.site>
	<20120214210851.GA21988@aepfle.de>
	<20290.33301.89584.251547@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20290.33301.89584.251547@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, Ian Jackson wrote:

> Ian Jackson writes ("Re: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> > Olaf Hering writes ("[Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and performance improvements"):
> > > This series adjusts the error reporting in the various code paths, with
> > > the intention that fatal errors can be detected by callers and handled
> > > properly. During my performance analysis with callgrind I found and
> > > fixed a few bottlenecks in the page-in code paths.
> > 
> > Since these are all xenpaging changes, I'm inclined to follow your
> > lead and commit them soon.  If anyone has any comments, please shout!
> 
> Olaf, can you please rebase to current tip ?  The other recent
> xenpaging changes conflict with these.

I will send a rebased version of this series.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYM2-0000Zw-7B; Mon, 20 Feb 2012 18:52:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYM1-0000Zm-9K
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:52:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329763966!12015504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19949 invoked from network); 20 Feb 2012 18:52:46 -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 Feb 2012 18:52:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:52:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:52:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYLt-0007AS-NK; Mon, 20 Feb 2012 18:52:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYLt-00061p-GT;
	Mon, 20 Feb 2012 18:52:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38525.59553.807190@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:52:45 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329234536.31256.259.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> I was wondering if perhaps xl/libxl should handle these events by
> default (using the same APIs as xldeviced uses) such that in the simple
> case users can continue to just use xl without worrying about
> configuring or enabling additional daemons. There would then be an
> option to disable this if you were running xldeviced (either in dom0 or
> in a driver dom). Perhaps a more DWIM extension would be to default to
> running things within xl/libxl only if the backend is in dom0 and assu,e
> xldeviced is running in backend doms != 0.

This is a good idea.  It can probably be implemented with some kind of
loopback function which either runs the script, or communicates with
the xldeviced via xenstore.

> Do you integrate with the libxl event loop? If you did wouldn't this be
> trivial to handle in xl and wouldn't the xldeviced become the trivial
> setup + run the event loop program?

That would be one way to look at it.

  void libxl_xldeviced_enter(libxl_ctx*); /* never returns */

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYM2-0000Zw-7B; Mon, 20 Feb 2012 18:52:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYM1-0000Zm-9K
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:52:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329763966!12015504!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19949 invoked from network); 20 Feb 2012 18:52:46 -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 Feb 2012 18:52:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:52:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:52:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYLt-0007AS-NK; Mon, 20 Feb 2012 18:52:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYLt-00061p-GT;
	Mon, 20 Feb 2012 18:52:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38525.59553.807190@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:52:45 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329234536.31256.259.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> I was wondering if perhaps xl/libxl should handle these events by
> default (using the same APIs as xldeviced uses) such that in the simple
> case users can continue to just use xl without worrying about
> configuring or enabling additional daemons. There would then be an
> option to disable this if you were running xldeviced (either in dom0 or
> in a driver dom). Perhaps a more DWIM extension would be to default to
> running things within xl/libxl only if the backend is in dom0 and assu,e
> xldeviced is running in backend doms != 0.

This is a good idea.  It can probably be implemented with some kind of
loopback function which either runs the script, or communicates with
the xldeviced via xenstore.

> Do you integrate with the libxl event loop? If you did wouldn't this be
> trivial to handle in xl and wouldn't the xldeviced become the trivial
> setup + run the event loop program?

That would be one way to look at it.

  void libxl_xldeviced_enter(libxl_ctx*); /* never returns */

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYOx-0000kL-Ul; Mon, 20 Feb 2012 18:55: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 1RzYOw-0000kD-8z
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:55:54 +0000
Received: from [85.158.139.83:22464] by server-7.bemta-5.messagelabs.com id
	F0/83-16195-937924F4; Mon, 20 Feb 2012 18:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329764152!8525080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30722 invoked from network); 20 Feb 2012 18:55:52 -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;
	20 Feb 2012 18:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:55:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:55:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYOt-0007Bk-Qu; Mon, 20 Feb 2012 18:55:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYOt-0003MQ-NS;
	Mon, 20 Feb 2012 18:55:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38711.670497.847758@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:55:51 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, Roger Pau =?utf-8?Q?Monn=C3=A9?=
	<roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20290.38525.59553.807190@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<20290.38525.59553.807190@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API 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 Jackson writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > Do you integrate with the libxl event loop? If you did wouldn't this be
> > trivial to handle in xl and wouldn't the xldeviced become the trivial
> > setup + run the event loop program?
> 
> That would be one way to look at it.
> 
>   void libxl_xldeviced_enter(libxl_ctx*); /* never returns */

Actually, thinking about it, the interface is probably:

   int libxl_devicedaemon_start(libxl_ctx*);
     /* Causes this libxl ctx to behave like the xl device daemon
      * whenever it is processing libxl events. */

and then the caller can do this

   rc = libxl_devicedaemon_start(ctx);
   if (rc) ...

   for (;;) {
       ... libxl_event_wait ...   
   }

In principle it would be possible for this device daemon to be part of
some other daemon this way.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYOx-0000kL-Ul; Mon, 20 Feb 2012 18:55: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 1RzYOw-0000kD-8z
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:55:54 +0000
Received: from [85.158.139.83:22464] by server-7.bemta-5.messagelabs.com id
	F0/83-16195-937924F4; Mon, 20 Feb 2012 18:55:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329764152!8525080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30722 invoked from network); 20 Feb 2012 18:55:52 -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;
	20 Feb 2012 18:55:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:55:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:55:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYOt-0007Bk-Qu; Mon, 20 Feb 2012 18:55:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYOt-0003MQ-NS;
	Mon, 20 Feb 2012 18:55:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38711.670497.847758@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:55:51 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, Roger Pau =?utf-8?Q?Monn=C3=A9?=
	<roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20290.38525.59553.807190@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<20290.38525.59553.807190@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API 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 Jackson writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > Do you integrate with the libxl event loop? If you did wouldn't this be
> > trivial to handle in xl and wouldn't the xldeviced become the trivial
> > setup + run the event loop program?
> 
> That would be one way to look at it.
> 
>   void libxl_xldeviced_enter(libxl_ctx*); /* never returns */

Actually, thinking about it, the interface is probably:

   int libxl_devicedaemon_start(libxl_ctx*);
     /* Causes this libxl ctx to behave like the xl device daemon
      * whenever it is processing libxl events. */

and then the caller can do this

   rc = libxl_devicedaemon_start(ctx);
   if (rc) ...

   for (;;) {
       ... libxl_event_wait ...   
   }

In principle it would be possible for this device daemon to be part of
some other daemon this way.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:56:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYPV-0000ns-Cf; Mon, 20 Feb 2012 18:56: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 1RzYPT-0000nb-Q9
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:56:28 +0000
Received: from [85.158.139.83:23355] by server-6.bemta-5.messagelabs.com id
	19/F6-27305-B57924F4; Mon, 20 Feb 2012 18:56:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329764186!15856312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11917 invoked from network); 20 Feb 2012 18:56:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:56:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:56:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:56:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYPR-0007Bw-Vc; Mon, 20 Feb 2012 18:56:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYPR-0003Mq-TP;
	Mon, 20 Feb 2012 18:56:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38745.869927.213411@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:56:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
	<1329145577.31256.116.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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] Mini-os fbfront.c unused variable complaint"):
> minios: Remove unused variables warnings
> 
> s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
> and always print the IRQ and MFN used by the xenbus on init.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:56:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYPV-0000ns-Cf; Mon, 20 Feb 2012 18:56: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 1RzYPT-0000nb-Q9
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:56:28 +0000
Received: from [85.158.139.83:23355] by server-6.bemta-5.messagelabs.com id
	19/F6-27305-B57924F4; Mon, 20 Feb 2012 18:56:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329764186!15856312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11917 invoked from network); 20 Feb 2012 18:56:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:56:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:56:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:56:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYPR-0007Bw-Vc; Mon, 20 Feb 2012 18:56:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYPR-0003Mq-TP;
	Mon, 20 Feb 2012 18:56:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38745.869927.213411@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:56:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1329145577.31256.116.camel@zakaz.uk.xensource.com>
References: <1328710520.6133.36.camel@zakaz.uk.xensource.com>
	<CB57D267.2A9D3%keir.xen@gmail.com>
	<20275.61332.197371.44329@mariner.uk.xensource.com>
	<1328803780.6133.210.camel@zakaz.uk.xensource.com>
	<554A6997-B8C3-41C3-8BFE-523DDF163EE6@nrl.navy.mil>
	<20276.105.622354.251001@mariner.uk.xensource.com>
	<1329136986.31256.96.camel@zakaz.uk.xensource.com>
	<DB11593E-32D6-4B1C-9870-81C47F086E1E@nrl.navy.mil>
	<1329145577.31256.116.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Mini-os fbfront.c unused variable complaint
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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] Mini-os fbfront.c unused variable complaint"):
> minios: Remove unused variables warnings
> 
> s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
> and always print the IRQ and MFN used by the xenbus on init.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:58:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYQw-0000w8-Ti; Mon, 20 Feb 2012 18:57: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 1RzYQv-0000vu-Jd
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:57:57 +0000
Received: from [85.158.139.83:21584] by server-3.bemta-5.messagelabs.com id
	82/B1-06438-4B7924F4; Mon, 20 Feb 2012 18:57:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329764270!15784099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12402 invoked from network); 20 Feb 2012 18:57:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:57:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821604"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:57:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:57:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYQj-0007CL-Mi; Mon, 20 Feb 2012 18:57:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYQj-0003NG-Kg;
	Mon, 20 Feb 2012 18:57:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38825.628134.61074@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:57:45 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c42517c528976cc5d6d6.1328806615@probook.site>
References: <c42517c528976cc5d6d6.1328806615@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mention output_format= in examples/xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] mention output_format= in examples/xl.conf"):
> mention output_format= in examples/xl.conf
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:58:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:58:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYQw-0000w8-Ti; Mon, 20 Feb 2012 18:57: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 1RzYQv-0000vu-Jd
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:57:57 +0000
Received: from [85.158.139.83:21584] by server-3.bemta-5.messagelabs.com id
	82/B1-06438-4B7924F4; Mon, 20 Feb 2012 18:57:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329764270!15784099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12402 invoked from network); 20 Feb 2012 18:57:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:57:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821604"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:57:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:57:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYQj-0007CL-Mi; Mon, 20 Feb 2012 18:57:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYQj-0003NG-Kg;
	Mon, 20 Feb 2012 18:57:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38825.628134.61074@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:57:45 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c42517c528976cc5d6d6.1328806615@probook.site>
References: <c42517c528976cc5d6d6.1328806615@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] mention output_format= in examples/xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] mention output_format= in examples/xl.conf"):
> mention output_format= in examples/xl.conf
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYRH-0000yy-AK; Mon, 20 Feb 2012 18:58: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 1RzYRF-0000yL-St
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:58:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329764226!61844971!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8192 invoked from network); 20 Feb 2012 18:57:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:57:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:57:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:57:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYQ9-0007CA-OQ; Mon, 20 Feb 2012 18:57:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYQ9-0003N3-Mk;
	Mon, 20 Feb 2012 18:57:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38786.28921.954051@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:57:06 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <151288df7766f566f49a.1328806433@probook.site>
References: <151288df7766f566f49a.1328806433@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] docs/man: correct autoballoon in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] docs/man: correct autoballoon in xl.conf"):
> docs/man: correct autoballoon in xl.conf

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18: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 1RzYRH-0000yy-AK; Mon, 20 Feb 2012 18:58: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 1RzYRF-0000yL-St
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:58:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329764226!61844971!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8192 invoked from network); 20 Feb 2012 18:57:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:57:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:57:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:57:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYQ9-0007CA-OQ; Mon, 20 Feb 2012 18:57:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYQ9-0003N3-Mk;
	Mon, 20 Feb 2012 18:57:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38786.28921.954051@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:57:06 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <151288df7766f566f49a.1328806433@probook.site>
References: <151288df7766f566f49a.1328806433@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] docs/man: correct autoballoon in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] docs/man: correct autoballoon in xl.conf"):
> docs/man: correct autoballoon in xl.conf

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:58:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYRJ-0000zX-Mt; Mon, 20 Feb 2012 18:58:21 +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 1RzYRI-0000z8-Cu
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:58:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329764233!61844980!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8432 invoked from network); 20 Feb 2012 18:57:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:57:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:58:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:58:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYRH-0007CZ-05; Mon, 20 Feb 2012 18:58:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYRG-0003NV-VR;
	Mon, 20 Feb 2012 18:58:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38858.803472.579365@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:58:18 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7dadba19566dc9e1dfaf.1328807886@probook.site>
References: <7dadba19566dc9e1dfaf.1328807886@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default
	runlevel	in xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xencommons"):
> tools/hotplug: remove 4 from default runlevel in xencommons

Thanks for the comprehensive explanation.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 18:58:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 18:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYRJ-0000zX-Mt; Mon, 20 Feb 2012 18:58:21 +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 1RzYRI-0000z8-Cu
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 18:58:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329764233!61844980!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8432 invoked from network); 20 Feb 2012 18:57:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 18:57:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821606"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 18:58:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 18:58:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYRH-0007CZ-05; Mon, 20 Feb 2012 18:58:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYRG-0003NV-VR;
	Mon, 20 Feb 2012 18:58:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38858.803472.579365@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 18:58:18 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7dadba19566dc9e1dfaf.1328807886@probook.site>
References: <7dadba19566dc9e1dfaf.1328807886@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default
	runlevel	in xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xencommons"):
> tools/hotplug: remove 4 from default runlevel in xencommons

Thanks for the comprehensive explanation.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYTg-0001Oh-FS; Mon, 20 Feb 2012 19:00:48 +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 1RzYTe-0001Nz-LB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:00:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329764390!55017464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14597 invoked from network); 20 Feb 2012 18:59:50 -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 Feb 2012 18:59:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:00:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:00:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYTN-0007DS-QT; Mon, 20 Feb 2012 19:00:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYTN-0003Qz-PF;
	Mon, 20 Feb 2012 19:00:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38989.768884.347346@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:00:29 +0000
To: <rshriram@cs.ubc.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel
	in	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resume"):
> libxl: support suspend_cancel in domain_resume

I get this:

libxl.c: In function 'libxl_domain_resume':
libxl.c:315: error: implicit declaration of function 'libxl__domain_resume_device_model'

Did you compile this ?  Did you test it ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:00:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYTg-0001Oh-FS; Mon, 20 Feb 2012 19:00:48 +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 1RzYTe-0001Nz-LB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:00:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329764390!55017464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14597 invoked from network); 20 Feb 2012 18:59:50 -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 Feb 2012 18:59:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:00:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:00:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYTN-0007DS-QT; Mon, 20 Feb 2012 19:00:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYTN-0003Qz-PF;
	Mon, 20 Feb 2012 19:00:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.38989.768884.347346@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:00:29 +0000
To: <rshriram@cs.ubc.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel
	in	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resume"):
> libxl: support suspend_cancel in domain_resume

I get this:

libxl.c: In function 'libxl_domain_resume':
libxl.c:315: error: implicit declaration of function 'libxl__domain_resume_device_model'

Did you compile this ?  Did you test it ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:04:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYXO-0001kO-BJ; Mon, 20 Feb 2012 19:04: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 1RzYXM-0001kB-DJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:04:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329764627!60898469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6558 invoked from network); 20 Feb 2012 19:03:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:03:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:04:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:04:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYXI-0007Ef-1o; Mon, 20 Feb 2012 19:04:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYXI-0003Ro-0Z;
	Mon, 20 Feb 2012 19:04:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39231.779843.969618@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:04:31 +0000
To: rshriram@cs.ubc.ca
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support"):
> This patch series introduces a basic framework to incorporate
> Remus into the libxl toolstack. The only functionality currently
> implemented is memory checkpointing.

Thanks.  I'm afraid this doesn't apply to current tip:

patching file tools/libxl/xl_cmdimpl.c
Hunk #1 FAILED at 2878
Hunk #5 FAILED at 3102
2 out of 6 hunks FAILED -- saving rejects to file tools/libxl/xl_cmdimpl.c.rej

While you're refreshing it, could you rewrap the lines in xl.pod.1 to
be within 75-80 columns ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:04:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYXO-0001kO-BJ; Mon, 20 Feb 2012 19:04: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 1RzYXM-0001kB-DJ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:04:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329764627!60898469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6558 invoked from network); 20 Feb 2012 19:03:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:03:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:04:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:04:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYXI-0007Ef-1o; Mon, 20 Feb 2012 19:04:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYXI-0003Ro-0Z;
	Mon, 20 Feb 2012 19:04:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39231.779843.969618@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:04:31 +0000
To: rshriram@cs.ubc.ca
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support"):
> This patch series introduces a basic framework to incorporate
> Remus into the libxl toolstack. The only functionality currently
> implemented is memory checkpointing.

Thanks.  I'm afraid this doesn't apply to current tip:

patching file tools/libxl/xl_cmdimpl.c
Hunk #1 FAILED at 2878
Hunk #5 FAILED at 3102
2 out of 6 hunks FAILED -- saving rejects to file tools/libxl/xl_cmdimpl.c.rej

While you're refreshing it, could you rewrap the lines in xl.pod.1 to
be within 75-80 columns ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:08:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYaz-0001t2-02; Mon, 20 Feb 2012 19:08:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYax-0001sj-Vv
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:08:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329764893!15582796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11800 invoked from network); 20 Feb 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821696"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:08:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYaq-0007Fn-So; Mon, 20 Feb 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYaq-0003SL-Rk;
	Mon, 20 Feb 2012 19:08:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39452.847449.580424@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:08:12 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 01 of 23] libxl:
	Document	_init/_dispose/_setdefault 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 ("[Xen-devel] [PATCH 01 of 23] libxl: Document _init/_dispose/_setdefault functions"):
> + * void libxl_<type>_init_<subfield>(<type> *p, subfield):
> + *
> + *    Initialise those parts of "p" which are not initialised by the
> + *    main init function due to the unknown value of "subfield". Sets
> + *    p->subfield as well as initialising any fields to their default
> + *    values.
> + *
> + *    p->subfield must not have been previously initialised.
> + *
> + *    This method is provided for any aggregate type which is used as
> + *    an input parameter.

This final sentence needs a qualification I think.

> + * void libxl_<type>_dispose(instance *p):
> + *
> + *    Frees any dynamically allocated memory used by the members of
> + *    "p" but not the storage used by "p" itself (this allows for the
> + *    allocation of arrays of types and for the composition of types).
> + *
> + *    In general this method is only provided for types where memory
> + *    can be dynamically allocated as part of that type.

Is whether dynamic allocation may happen a very stable part of the
libxl API ?  If we add a dynamically allocated member to one of these
structs, don't we inevitably introduce a memory leak into all
callers ?

I think it would be better to provide a dispose function corresponding
to every init function.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:08:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYaz-0001t2-02; Mon, 20 Feb 2012 19:08:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYax-0001sj-Vv
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:08:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329764893!15582796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11800 invoked from network); 20 Feb 2012 19:08:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:08:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821696"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:08:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:08:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYaq-0007Fn-So; Mon, 20 Feb 2012 19:08:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYaq-0003SL-Rk;
	Mon, 20 Feb 2012 19:08:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39452.847449.580424@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:08:12 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 01 of 23] libxl:
	Document	_init/_dispose/_setdefault 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 ("[Xen-devel] [PATCH 01 of 23] libxl: Document _init/_dispose/_setdefault functions"):
> + * void libxl_<type>_init_<subfield>(<type> *p, subfield):
> + *
> + *    Initialise those parts of "p" which are not initialised by the
> + *    main init function due to the unknown value of "subfield". Sets
> + *    p->subfield as well as initialising any fields to their default
> + *    values.
> + *
> + *    p->subfield must not have been previously initialised.
> + *
> + *    This method is provided for any aggregate type which is used as
> + *    an input parameter.

This final sentence needs a qualification I think.

> + * void libxl_<type>_dispose(instance *p):
> + *
> + *    Frees any dynamically allocated memory used by the members of
> + *    "p" but not the storage used by "p" itself (this allows for the
> + *    allocation of arrays of types and for the composition of types).
> + *
> + *    In general this method is only provided for types where memory
> + *    can be dynamically allocated as part of that type.

Is whether dynamic allocation may happen a very stable part of the
libxl API ?  If we add a dynamically allocated member to one of these
structs, don't we inevitably introduce a memory leak into all
callers ?

I think it would be better to provide a dispose function corresponding
to every init function.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:10:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYca-0001yu-Jj; Mon, 20 Feb 2012 19:10: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 1RzYcZ-0001yk-40
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:09:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329764945!53519226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24917 invoked from network); 20 Feb 2012 19:09:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:09:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:09:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:09:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYcX-0007Gd-LY; Mon, 20 Feb 2012 19:09:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYcX-0003Sl-KX;
	Mon, 20 Feb 2012 19:09:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39557.621488.796311@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:09:57 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <53d4e198863a29e20418.1329151968@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<53d4e198863a29e20418.1329151968@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 02 of 23] libxl: provide _init and
 _setdefault for libxl_domain_create_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

Ian Campbell writes ("[Xen-devel] [PATCH 02 of 23] libxl: provide _init and _setdefault for libxl_domain_create_info"):
> libxl: provide _init and _setdefault for libxl_domain_create_info.
> 
> Some fields require further scaffolding before they can use the
> _init/_setdefault scheme and are handled in later patches.
...
> -int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
> +void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
>  {
>      memset(c_info, '\0', sizeof(*c_info));
> -    c_info->xsdata = NULL;
> -    c_info->platformdata = NULL;
>      c_info->hap = 1;
> -    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
>      c_info->oos = 1;
> -    c_info->ssidref = 0;
> -    c_info->poolid = 0;
> +}

Is it really best to do it like this, rather than generate this
function automatically ?  AFAICT the magic "use default" values are a
property of the member types so _init is entirely formulaic.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:10:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYca-0001yu-Jj; Mon, 20 Feb 2012 19:10: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 1RzYcZ-0001yk-40
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:09:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329764945!53519226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24917 invoked from network); 20 Feb 2012 19:09:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:09:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:09:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:09:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYcX-0007Gd-LY; Mon, 20 Feb 2012 19:09:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYcX-0003Sl-KX;
	Mon, 20 Feb 2012 19:09:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39557.621488.796311@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:09:57 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <53d4e198863a29e20418.1329151968@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<53d4e198863a29e20418.1329151968@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 02 of 23] libxl: provide _init and
 _setdefault for libxl_domain_create_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

Ian Campbell writes ("[Xen-devel] [PATCH 02 of 23] libxl: provide _init and _setdefault for libxl_domain_create_info"):
> libxl: provide _init and _setdefault for libxl_domain_create_info.
> 
> Some fields require further scaffolding before they can use the
> _init/_setdefault scheme and are handled in later patches.
...
> -int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
> +void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
>  {
>      memset(c_info, '\0', sizeof(*c_info));
> -    c_info->xsdata = NULL;
> -    c_info->platformdata = NULL;
>      c_info->hap = 1;
> -    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
>      c_info->oos = 1;
> -    c_info->ssidref = 0;
> -    c_info->poolid = 0;
> +}

Is it really best to do it like this, rather than generate this
function automatically ?  AFAICT the magic "use default" values are a
property of the member types so _init is entirely formulaic.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:14:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYh5-0002Ci-Bu; Mon, 20 Feb 2012 19:14: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 1RzYh3-0002Ca-Kx
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:14:37 +0000
Received: from [85.158.139.83:18125] by server-5.bemta-5.messagelabs.com id
	EB/FA-13566-C9B924F4; Mon, 20 Feb 2012 19:14:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329765276!15869677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21983 invoked from network); 20 Feb 2012 19:14:36 -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 Feb 2012 19:14:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:14:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:14:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYh1-0007Jt-PI; Mon, 20 Feb 2012 19:14:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYh1-0003TL-OD;
	Mon, 20 Feb 2012 19:14:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39835.735877.682986@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:14:35 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in
	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

Ian Campbell writes ("[Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in type"):
> libxl: add new "defbool" built in type.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:14:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYh5-0002Ci-Bu; Mon, 20 Feb 2012 19:14: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 1RzYh3-0002Ca-Kx
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:14:37 +0000
Received: from [85.158.139.83:18125] by server-5.bemta-5.messagelabs.com id
	EB/FA-13566-C9B924F4; Mon, 20 Feb 2012 19:14:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329765276!15869677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21983 invoked from network); 20 Feb 2012 19:14:36 -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 Feb 2012 19:14:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:14:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:14:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYh1-0007Jt-PI; Mon, 20 Feb 2012 19:14:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYh1-0003TL-OD;
	Mon, 20 Feb 2012 19:14:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39835.735877.682986@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:14:35 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in
	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

Ian Campbell writes ("[Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in type"):
> libxl: add new "defbool" built in type.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:16:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:16:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYiO-0002HM-Rb; Mon, 20 Feb 2012 19:16:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYiN-0002H4-Uc
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:16:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329765352!9150524!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16585 invoked from network); 20 Feb 2012 19:15:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:15:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:15:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:15:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYiF-0007KU-Og; Mon, 20 Feb 2012 19:15:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYiF-0003Th-Nh;
	Mon, 20 Feb 2012 19:15:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39907.912639.18195@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:15:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>, stefano.stabellini@eu.citrix.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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

Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> libxl: drop 8M slack for PV guests.
> 
> As far as I can tell this serves no purpose. I think it relates to the old
> 8M to "account for backend allocations" which we used to add. This leaves a bit
> of unpopulated space in the Pseudo-physical address space which can be used by
> backends when mapping foreign memory. However 8M is not representative of that
> any more and modern kernels do not operate in this way anyway.
> 
> I suspect an argument could be made for removing this from the libxl API
> altogether but instead lets just set the overhead to 0.

I think this is plausible but I'd like to hear from Stefano, who iirc
may have some knowledge about the reason for this 8Mb.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:16:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:16:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYiO-0002HM-Rb; Mon, 20 Feb 2012 19:16:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYiN-0002H4-Uc
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:16:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329765352!9150524!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16585 invoked from network); 20 Feb 2012 19:15:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:15:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:15:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:15:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYiF-0007KU-Og; Mon, 20 Feb 2012 19:15:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYiF-0003Th-Nh;
	Mon, 20 Feb 2012 19:15:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39907.912639.18195@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:15:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>, stefano.stabellini@eu.citrix.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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

Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> libxl: drop 8M slack for PV guests.
> 
> As far as I can tell this serves no purpose. I think it relates to the old
> 8M to "account for backend allocations" which we used to add. This leaves a bit
> of unpopulated space in the Pseudo-physical address space which can be used by
> backends when mapping foreign memory. However 8M is not representative of that
> any more and modern kernels do not operate in this way anyway.
> 
> I suspect an argument could be made for removing this from the libxl API
> altogether but instead lets just set the overhead to 0.

I think this is plausible but I'd like to hear from Stefano, who iirc
may have some knowledge about the reason for this 8Mb.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:16:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYig-0002J8-8A; Mon, 20 Feb 2012 19:16:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYie-0002IC-5O
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:16:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329765369!12305152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26980 invoked from network); 20 Feb 2012 19:16:10 -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 Feb 2012 19:16:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:16:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:16:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYiX-0007Kb-C1; Mon, 20 Feb 2012 19:16:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYiX-0003Tq-B0;
	Mon, 20 Feb 2012 19:16:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39929.326021.881760@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:16:09 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d50d692ae52bca2d4094.1329151970@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d50d692ae52bca2d4094.1329151970@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 04 of 23] libxl: use an
	explicit	LIBXL_TIMER_MODE_DEFAULT value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 04 of 23] libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value"):
> libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:16:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYig-0002J8-8A; Mon, 20 Feb 2012 19:16:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYie-0002IC-5O
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:16:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329765369!12305152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26980 invoked from network); 20 Feb 2012 19:16:10 -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 Feb 2012 19:16:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:16:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:16:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYiX-0007Kb-C1; Mon, 20 Feb 2012 19:16:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYiX-0003Tq-B0;
	Mon, 20 Feb 2012 19:16:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39929.326021.881760@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:16:09 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d50d692ae52bca2d4094.1329151970@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d50d692ae52bca2d4094.1329151970@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 04 of 23] libxl: use an
	explicit	LIBXL_TIMER_MODE_DEFAULT value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 04 of 23] libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value"):
> libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:17:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYjS-0002VL-MH; Mon, 20 Feb 2012 19:17:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYjQ-0002U8-QS
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:17:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329765418!15332376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17290 invoked from network); 20 Feb 2012 19:16:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:16:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:16:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYjJ-0007Kp-Td; Mon, 20 Feb 2012 19:16:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYjJ-0003UJ-Sc;
	Mon, 20 Feb 2012 19:16:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39977.870110.650672@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:16:57 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 16 of 23] libxl: switch generation id
	control to	libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 16 of 23] libxl: switch generation id control to libxl_defbool"):
> libxl: switch generation id control to libxl_defbool.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:17:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYjS-0002VL-MH; Mon, 20 Feb 2012 19:17:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYjQ-0002U8-QS
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:17:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329765418!15332376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17290 invoked from network); 20 Feb 2012 19:16:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:16:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:16:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYjJ-0007Kp-Td; Mon, 20 Feb 2012 19:16:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYjJ-0003UJ-Sc;
	Mon, 20 Feb 2012 19:16:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.39977.870110.650672@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:16:57 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 16 of 23] libxl: switch generation id
	control to	libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 16 of 23] libxl: switch generation id control to libxl_defbool"):
> libxl: switch generation id control to libxl_defbool.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:18:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYkE-0002em-4a; Mon, 20 Feb 2012 19:17:54 +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 1RzYkD-0002e6-CM
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:17:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329765338!62103621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22409 invoked from network); 20 Feb 2012 19:15: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;
	20 Feb 2012 19:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:17:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:17:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYk7-0007LK-1l; Mon, 20 Feb 2012 19:17:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYk7-0003Uc-0y;
	Mon, 20 Feb 2012 19:17:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40027.13221.592186@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:17:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0751a69b3ef226484450.1329151987@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<0751a69b3ef226484450.1329151987@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 21 of 23] libxl: Make IDL KeyedUnion keyvar
	an	idl.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

Ian Campbell writes ("[Xen-devel] [PATCH 21 of 23] libxl: Make IDL KeyedUnion keyvar an idl.Field"):
> libxl: Make IDL KeyedUnion keyvar an idl.Field

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:18:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYkE-0002em-4a; Mon, 20 Feb 2012 19:17:54 +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 1RzYkD-0002e6-CM
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:17:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329765338!62103621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22409 invoked from network); 20 Feb 2012 19:15: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;
	20 Feb 2012 19:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:17:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:17:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYk7-0007LK-1l; Mon, 20 Feb 2012 19:17:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYk7-0003Uc-0y;
	Mon, 20 Feb 2012 19:17:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40027.13221.592186@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:17:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0751a69b3ef226484450.1329151987@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<0751a69b3ef226484450.1329151987@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 21 of 23] libxl: Make IDL KeyedUnion keyvar
	an	idl.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

Ian Campbell writes ("[Xen-devel] [PATCH 21 of 23] libxl: Make IDL KeyedUnion keyvar an idl.Field"):
> libxl: Make IDL KeyedUnion keyvar an idl.Field

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYkc-0002j4-I0; Mon, 20 Feb 2012 19:18:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYkb-0002i6-FK
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:18:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329765491!15475363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10716 invoked from network); 20 Feb 2012 19:18:11 -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;
	20 Feb 2012 19:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:18:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYkU-0007LU-Rk; Mon, 20 Feb 2012 19:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYkU-0003Uu-Qi;
	Mon, 20 Feb 2012 19:18:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40050.812754.240870@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:18:10 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a20f15f1889ba1dda88d.1329151980@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<a20f15f1889ba1dda88d.1329151980@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 14 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 14 of 23] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYkc-0002j4-I0; Mon, 20 Feb 2012 19:18:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYkb-0002i6-FK
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:18:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329765491!15475363!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10716 invoked from network); 20 Feb 2012 19:18:11 -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;
	20 Feb 2012 19:18:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821809"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:18:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYkU-0007LU-Rk; Mon, 20 Feb 2012 19:18:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYkU-0003Uu-Qi;
	Mon, 20 Feb 2012 19:18:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40050.812754.240870@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:18:10 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a20f15f1889ba1dda88d.1329151980@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<a20f15f1889ba1dda88d.1329151980@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 14 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 14 of 23] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:18:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:18:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYkv-0002no-6H; Mon, 20 Feb 2012 19:18:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYkt-0002mK-En
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:18:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329765507!14094412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31590 invoked from network); 20 Feb 2012 19:18:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:18:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19: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.213.0; Mon, 20 Feb 2012 19:18:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYkk-0007La-SG; Mon, 20 Feb 2012 19:18:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYkk-0003VA-RN;
	Mon, 20 Feb 2012 19:18:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40066.835202.532090@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:18:26 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1ace05e41c39f3620b42.1329151972@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<1ace05e41c39f3620b42.1329151972@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 06 of 23] libxl: allow specification of
	testidl	random seed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 06 of 23] libxl: allow specification of testidl random seed"):
> libxl: allow specification of testidl random seed.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:18:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:18:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYkv-0002no-6H; Mon, 20 Feb 2012 19:18:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYkt-0002mK-En
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:18:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329765507!14094412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31590 invoked from network); 20 Feb 2012 19:18:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:18:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19: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.213.0; Mon, 20 Feb 2012 19:18:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYkk-0007La-SG; Mon, 20 Feb 2012 19:18:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYkk-0003VA-RN;
	Mon, 20 Feb 2012 19:18:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40066.835202.532090@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:18:26 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1ace05e41c39f3620b42.1329151972@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<1ace05e41c39f3620b42.1329151972@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 06 of 23] libxl: allow specification of
	testidl	random seed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 06 of 23] libxl: allow specification of testidl random seed"):
> libxl: allow specification of testidl random seed.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYlK-0002uL-9k; Mon, 20 Feb 2012 19:19:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <enzinol@gmail.com>) id 1RzYlI-0002sc-3z
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:19:00 +0000
X-Env-Sender: enzinol@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329765531!12409816!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.6 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23992 invoked from network); 20 Feb 2012 19:18:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:18:51 -0000
Received: by werb14 with SMTP id b14so12982895wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 11:18:51 -0800 (PST)
Received-SPF: pass (google.com: domain of enzinol@gmail.com designates
	10.180.14.193 as permitted sender) client-ip=10.180.14.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of enzinol@gmail.com
	designates 10.180.14.193 as permitted sender)
	smtp.mail=enzinol@gmail.com;
	dkim=pass header.i=enzinol@gmail.com
Received: from mr.google.com ([10.180.14.193])
	by 10.180.14.193 with SMTP id r1mr20750006wic.9.1329765531601 (num_hops
	= 1); Mon, 20 Feb 2012 11:18:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KqLbSTe9ikLseyrwKMyNx9a0hWOHt9ZzddHQsUr3ies=;
	b=v1qW29JsewtEFQ8viA9JElb1GBNVaEZ5yK8irSRUtcYC5GbxTrIs7BUCjI/HNFD16v
	EwJlvd0kxReIKf7qXqHPT+By/MvXqvfSq1MjnEgPiK9t5zEqZFBYuq2ASMTYuaNiAOoa
	7A0Hla5ININApPFnXPSrPbvckOC6vljwgCSYA=
MIME-Version: 1.0
Received: by 10.180.14.193 with SMTP id r1mr17322292wic.9.1329765530008; Mon,
	20 Feb 2012 11:18:50 -0800 (PST)
Received: by 10.223.45.194 with HTTP; Mon, 20 Feb 2012 11:18:49 -0800 (PST)
Date: Mon, 20 Feb 2012 11:18:49 -0800
Message-ID: <CACi2erAJ_rN5o_CpwXMeXcJBMXD_6QXQDkAJguM=f+gtswp0+Q@mail.gmail.com>
From: Enzo Lombardi <enzinol@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] need help to apply a patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5109417915132668948=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5109417915132668948==
Content-Type: multipart/alternative; boundary=f46d04138a9d0cfa9c04b96a2a69

--f46d04138a9d0cfa9c04b96a2a69
Content-Type: text/plain; charset=ISO-8859-1

I am trying to apply the following patch:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html
on
top of 4.1.2 source code.
The issue is that sys/io.h is missing from the source tree and it is
required for the declaration of ioperm() call.
Question is:

   1. where do I find an appropriate sys/io.h file for the mini-os/posix?
   ...or...
   2. can somebody help me to declare this method properly?

Thanks!
-e

--f46d04138a9d0cfa9c04b96a2a69
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am trying to apply the following patch:=A0
<a href=3D"http://old-list-archives.xen.org/archives/html/xen-devel/2010-10=
/msg00284.html">http://old-list-archives.xen.org/archives/html/xen-devel/20=
10-10/msg00284.html</a>=A0on top of 4.1.2 source code.<div>The issue is tha=
t sys/io.h is missing from the source tree and it is required for the decla=
ration of ioperm() call.</div>
<div>Question is:</div><div><ol><li>where do I find an appropriate sys/io.h=
 file for the mini-os/posix? ...or...</li><li>can somebody help me to decla=
re this method properly?</li></ol><div>Thanks!</div></div><div>-e</div>

--f46d04138a9d0cfa9c04b96a2a69--


--===============5109417915132668948==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5109417915132668948==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 19:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYlK-0002uL-9k; Mon, 20 Feb 2012 19:19:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <enzinol@gmail.com>) id 1RzYlI-0002sc-3z
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:19:00 +0000
X-Env-Sender: enzinol@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329765531!12409816!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.6 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	HTML_OBFUSCATE_05_10,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23992 invoked from network); 20 Feb 2012 19:18:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:18:51 -0000
Received: by werb14 with SMTP id b14so12982895wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 11:18:51 -0800 (PST)
Received-SPF: pass (google.com: domain of enzinol@gmail.com designates
	10.180.14.193 as permitted sender) client-ip=10.180.14.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of enzinol@gmail.com
	designates 10.180.14.193 as permitted sender)
	smtp.mail=enzinol@gmail.com;
	dkim=pass header.i=enzinol@gmail.com
Received: from mr.google.com ([10.180.14.193])
	by 10.180.14.193 with SMTP id r1mr20750006wic.9.1329765531601 (num_hops
	= 1); Mon, 20 Feb 2012 11:18:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KqLbSTe9ikLseyrwKMyNx9a0hWOHt9ZzddHQsUr3ies=;
	b=v1qW29JsewtEFQ8viA9JElb1GBNVaEZ5yK8irSRUtcYC5GbxTrIs7BUCjI/HNFD16v
	EwJlvd0kxReIKf7qXqHPT+By/MvXqvfSq1MjnEgPiK9t5zEqZFBYuq2ASMTYuaNiAOoa
	7A0Hla5ININApPFnXPSrPbvckOC6vljwgCSYA=
MIME-Version: 1.0
Received: by 10.180.14.193 with SMTP id r1mr17322292wic.9.1329765530008; Mon,
	20 Feb 2012 11:18:50 -0800 (PST)
Received: by 10.223.45.194 with HTTP; Mon, 20 Feb 2012 11:18:49 -0800 (PST)
Date: Mon, 20 Feb 2012 11:18:49 -0800
Message-ID: <CACi2erAJ_rN5o_CpwXMeXcJBMXD_6QXQDkAJguM=f+gtswp0+Q@mail.gmail.com>
From: Enzo Lombardi <enzinol@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] need help to apply a patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5109417915132668948=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5109417915132668948==
Content-Type: multipart/alternative; boundary=f46d04138a9d0cfa9c04b96a2a69

--f46d04138a9d0cfa9c04b96a2a69
Content-Type: text/plain; charset=ISO-8859-1

I am trying to apply the following patch:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html
on
top of 4.1.2 source code.
The issue is that sys/io.h is missing from the source tree and it is
required for the declaration of ioperm() call.
Question is:

   1. where do I find an appropriate sys/io.h file for the mini-os/posix?
   ...or...
   2. can somebody help me to declare this method properly?

Thanks!
-e

--f46d04138a9d0cfa9c04b96a2a69
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am trying to apply the following patch:=A0
<a href=3D"http://old-list-archives.xen.org/archives/html/xen-devel/2010-10=
/msg00284.html">http://old-list-archives.xen.org/archives/html/xen-devel/20=
10-10/msg00284.html</a>=A0on top of 4.1.2 source code.<div>The issue is tha=
t sys/io.h is missing from the source tree and it is required for the decla=
ration of ioperm() call.</div>
<div>Question is:</div><div><ol><li>where do I find an appropriate sys/io.h=
 file for the mini-os/posix? ...or...</li><li>can somebody help me to decla=
re this method properly?</li></ol><div>Thanks!</div></div><div>-e</div>

--f46d04138a9d0cfa9c04b96a2a69--


--===============5109417915132668948==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5109417915132668948==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 19:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYmQ-0003Ae-TX; Mon, 20 Feb 2012 19:20:10 +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 1RzYmP-00039q-HI
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:20:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329765554!61321380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27538 invoked from network); 20 Feb 2012 19:19:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:20:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:20:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYmK-0007M8-U8; Mon, 20 Feb 2012 19:20:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYmK-0003VR-TG;
	Mon, 20 Feb 2012 19:20:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40164.889190.529383@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:20:04 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 23] libxl: make
	libxl_device_console	internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> libxl: make libxl_device_console internal
> 
> consoles are not directly exposed to users of the library and there are no API
> functions for manipluating them (only the console_exec function). Rather than
> commit to a particular API now make the type internal.

Isn't it likely that at some future point we will re-expose this
difference, for example by providing a different set of access
functions ?

The fact that all you can do with a console is exec the xenconsole
client is pretty crazy.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYmQ-0003Ae-TX; Mon, 20 Feb 2012 19:20:10 +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 1RzYmP-00039q-HI
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:20:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329765554!61321380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27538 invoked from network); 20 Feb 2012 19:19:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:20:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:20:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYmK-0007M8-U8; Mon, 20 Feb 2012 19:20:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYmK-0003VR-TG;
	Mon, 20 Feb 2012 19:20:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40164.889190.529383@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:20:04 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 23] libxl: make
	libxl_device_console	internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> libxl: make libxl_device_console internal
> 
> consoles are not directly exposed to users of the library and there are no API
> functions for manipluating them (only the console_exec function). Rather than
> commit to a particular API now make the type internal.

Isn't it likely that at some future point we will re-expose this
difference, for example by providing a different set of access
functions ?

The fact that all you can do with a console is exec the xenconsole
client is pretty crazy.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:21:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:21:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYnA-0003Lo-Ef; Mon, 20 Feb 2012 19:20:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYn8-0003KM-K2
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:20:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329765648!14126323!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30899 invoked from network); 20 Feb 2012 19:20:48 -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;
	20 Feb 2012 19:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:20:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:20:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYmZ-0007MI-I9; Mon, 20 Feb 2012 19:20:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYmZ-0003Va-Gq;
	Mon, 20 Feb 2012 19:20:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40179.505090.874022@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:20:19 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ba3ab3558a5d84fef267.1329151984@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ba3ab3558a5d84fef267.1329151984@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 18 of 23] libxl: do not explicitly
 initialise members of build info to zero
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 18 of 23] libxl: do not explicitly initialise members of build info to zero"):
> libxl: do not explicitly initialise members of build info to zero

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:21:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:21:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYnA-0003Lo-Ef; Mon, 20 Feb 2012 19:20:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYn8-0003KM-K2
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:20:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329765648!14126323!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30899 invoked from network); 20 Feb 2012 19:20:48 -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;
	20 Feb 2012 19:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:20:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:20:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYmZ-0007MI-I9; Mon, 20 Feb 2012 19:20:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYmZ-0003Va-Gq;
	Mon, 20 Feb 2012 19:20:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40179.505090.874022@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:20:19 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ba3ab3558a5d84fef267.1329151984@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ba3ab3558a5d84fef267.1329151984@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 18 of 23] libxl: do not explicitly
 initialise members of build info to zero
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 18 of 23] libxl: do not explicitly initialise members of build info to zero"):
> libxl: do not explicitly initialise members of build info to zero

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:22:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:22:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYoJ-0003ZY-Us; Mon, 20 Feb 2012 19:22: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 1RzYoH-0003Z4-VU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:22:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329765701!64277065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9608 invoked from network); 20 Feb 2012 19:21:41 -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;
	20 Feb 2012 19:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:22:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:22:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYoG-0007Ml-Lu; Mon, 20 Feb 2012 19:22:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYoG-0003Vs-Kg;
	Mon, 20 Feb 2012 19:22:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40284.326732.555384@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:22:04 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 23] libxl:
	add	libxl_domain_build_info_init_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

Ian Campbell writes ("[Xen-devel] [PATCH 20 of 23] libxl: add libxl_domain_build_info_init_type"):
> libxl: add libxl_domain_build_info_init_type

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:22:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:22:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYoJ-0003ZY-Us; Mon, 20 Feb 2012 19:22: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 1RzYoH-0003Z4-VU
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:22:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329765701!64277065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9608 invoked from network); 20 Feb 2012 19:21:41 -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;
	20 Feb 2012 19:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:22:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:22:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYoG-0007Ml-Lu; Mon, 20 Feb 2012 19:22:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYoG-0003Vs-Kg;
	Mon, 20 Feb 2012 19:22:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40284.326732.555384@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:22:04 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 23] libxl:
	add	libxl_domain_build_info_init_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

Ian Campbell writes ("[Xen-devel] [PATCH 20 of 23] libxl: add libxl_domain_build_info_init_type"):
> libxl: add libxl_domain_build_info_init_type

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:22:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYop-0003ga-Co; Mon, 20 Feb 2012 19:22:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYon-0003fI-H4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:22:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329765750!13949400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10391 invoked from network); 20 Feb 2012 19:22:30 -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;
	20 Feb 2012 19:22:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:22:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:22:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYog-0007Mw-7L; Mon, 20 Feb 2012 19:22:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYog-0003WD-6e;
	Mon, 20 Feb 2012 19:22:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40310.190338.114854@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:22:30 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d27c92eeeddc5e4c190a.1329151983@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d27c92eeeddc5e4c190a.1329151983@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 23] libxl: use defbool for
	graphics	related 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 ("[Xen-devel] [PATCH 17 of 23] libxl: use defbool for graphics related options"):
> libxl: use defbool for graphics related options

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:22:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYop-0003ga-Co; Mon, 20 Feb 2012 19:22:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYon-0003fI-H4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:22:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329765750!13949400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10391 invoked from network); 20 Feb 2012 19:22:30 -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;
	20 Feb 2012 19:22:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:22:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:22:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYog-0007Mw-7L; Mon, 20 Feb 2012 19:22:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYog-0003WD-6e;
	Mon, 20 Feb 2012 19:22:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40310.190338.114854@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:22:30 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d27c92eeeddc5e4c190a.1329151983@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d27c92eeeddc5e4c190a.1329151983@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 23] libxl: use defbool for
	graphics	related 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 ("[Xen-devel] [PATCH 17 of 23] libxl: use defbool for graphics related options"):
> libxl: use defbool for graphics related options

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:24:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYqS-0003xT-T7; Mon, 20 Feb 2012 19:24:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYqR-0003wr-4N
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:24:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329765853!15475746!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26314 invoked from network); 20 Feb 2012 19:24:13 -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;
	20 Feb 2012 19:24:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:24:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:24:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYqK-0007Pe-La; Mon, 20 Feb 2012 19:24:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYqK-0003WO-KF;
	Mon, 20 Feb 2012 19:24:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40412.612337.629579@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:24:12 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init
 and libxl_FOO_init_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

Ian Campbell writes ("[Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD"):
> libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD

Ah!  Here's what I was looking for.  Excellent.

I would like to see the autogenerated code this makes and it would be
much more convenient for me to try out this series if you could push
it to a hg or git tree somewhere for me to fetch.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:24:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzYqS-0003xT-T7; Mon, 20 Feb 2012 19:24:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYqR-0003wr-4N
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:24:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329765853!15475746!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26314 invoked from network); 20 Feb 2012 19:24:13 -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;
	20 Feb 2012 19:24:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:24:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:24:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYqK-0007Pe-La; Mon, 20 Feb 2012 19:24:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYqK-0003WO-KF;
	Mon, 20 Feb 2012 19:24:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40412.612337.629579@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:24:12 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init
 and libxl_FOO_init_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

Ian Campbell writes ("[Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD"):
> libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD

Ah!  Here's what I was looking for.  Excellent.

I would like to see the autogenerated code this makes and it would be
much more convenient for me to try out this series if you could push
it to a hg or git tree somewhere for me to fetch.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:24:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYqb-0003z4-Am; Mon, 20 Feb 2012 19:24:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYqZ-0003xj-I0
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:24:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329765861!17472506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27737 invoked from network); 20 Feb 2012 19:24:21 -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;
	20 Feb 2012 19:24:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:24:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:24:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYqT-0007Pk-8o; Mon, 20 Feb 2012 19:24:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYqT-0003WU-7E;
	Mon, 20 Feb 2012 19:24:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40421.212175.278627@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:24:21 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 23] libxl:
	add	libxl_domain_build_info_init_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

Ian Campbell writes ("[Xen-devel] [PATCH 20 of 23] libxl: add libxl_domain_build_info_init_type"):
> libxl: add libxl_domain_build_info_init_type

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:24:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:24:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYqb-0003z4-Am; Mon, 20 Feb 2012 19:24:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYqZ-0003xj-I0
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:24:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329765861!17472506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27737 invoked from network); 20 Feb 2012 19:24:21 -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;
	20 Feb 2012 19:24:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:24:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:24:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYqT-0007Pk-8o; Mon, 20 Feb 2012 19:24:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYqT-0003WU-7E;
	Mon, 20 Feb 2012 19:24:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40421.212175.278627@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:24:21 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<1adeebf9e6bd3d74a2f6.1329151986@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 23] libxl:
	add	libxl_domain_build_info_init_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

Ian Campbell writes ("[Xen-devel] [PATCH 20 of 23] libxl: add libxl_domain_build_info_init_type"):
> libxl: add libxl_domain_build_info_init_type

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:24:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYqy-00044V-Oc; Mon, 20 Feb 2012 19:24:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYqx-00042u-Or
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329765885!15656507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 20 Feb 2012 19:24:45 -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;
	20 Feb 2012 19:24:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821891"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:24:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:24:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYqr-0007Pv-AG; Mon, 20 Feb 2012 19:24:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYqr-0003Wd-9M;
	Mon, 20 Feb 2012 19:24:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40445.275737.870814@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:24:45 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2fef3eddec04dd3a56d6.1329151973@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<2fef3eddec04dd3a56d6.1329151973@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 07 of 23] libxl: introduce a descriminating
 default value for memkb fields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 07 of 23] libxl: introduce a descriminating default value for memkb fields"):
> libxl: introduce a descriminating default value for memkb fields.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:24:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYqy-00044V-Oc; Mon, 20 Feb 2012 19:24:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYqx-00042u-Or
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329765885!15656507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 20 Feb 2012 19:24:45 -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;
	20 Feb 2012 19:24:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821891"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:24:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:24:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYqr-0007Pv-AG; Mon, 20 Feb 2012 19:24:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYqr-0003Wd-9M;
	Mon, 20 Feb 2012 19:24:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40445.275737.870814@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:24:45 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2fef3eddec04dd3a56d6.1329151973@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<2fef3eddec04dd3a56d6.1329151973@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 07 of 23] libxl: introduce a descriminating
 default value for memkb fields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 07 of 23] libxl: introduce a descriminating default value for memkb fields"):
> libxl: introduce a descriminating default value for memkb fields.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:26:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYs0-0004HV-7B; Mon, 20 Feb 2012 19:25:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYrz-0004Gf-3U
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:25:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329765948!5944273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28232 invoked from network); 20 Feb 2012 19:25:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:25:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:25:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:25:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYrs-0007QG-4I; Mon, 20 Feb 2012 19:25:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYrs-0003Wt-3Q;
	Mon, 20 Feb 2012 19:25:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40508.50377.249022@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:25:48 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 15 of 23] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);

Maybe this would be easier to read like this:

 +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,       false);
 +        libxl_defbool_setdefault(&b_info->u.hvm.usb,              false);
 +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:26:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYs0-0004HV-7B; Mon, 20 Feb 2012 19:25:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzYrz-0004Gf-3U
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:25:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329765948!5944273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzQyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28232 invoked from network); 20 Feb 2012 19:25:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 19:25:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,452,1325462400"; d="scan'208";a="10821910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 19:25:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 19:25:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzYrs-0007QG-4I; Mon, 20 Feb 2012 19:25:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzYrs-0003Wt-3Q;
	Mon, 20 Feb 2012 19:25:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20290.40508.50377.249022@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 19:25:48 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 15 of 23] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> +        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);

Maybe this would be easier to read like this:

 +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,       false);
 +        libxl_defbool_setdefault(&b_info->u.hvm.usb,              false);
 +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYt9-0004Tu-QZ; Mon, 20 Feb 2012 19:27:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzYt8-0004Sr-GM
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:27:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329766020!12306022!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18673 invoked from network); 20 Feb 2012 19:27:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 19:27:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329766019; l=3458;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=zXF+kGMSEER/pvQodOLAgfcRAEk=;
	b=Wrjr+XWMJ37gF8FMxeWQ0ySLR3yq0SB8v1ZvmkHNlVLt5N6SLyT2NbXnDYbX78sycnk
	/5hyHmh0+v13kB0aAh5aSau6xEU5hhzOTls1Jg65VfjiaGC4iJLkm4YX7VMzhqvlnIdd5
	LklwVlrZHD4IPL7JZSQ4kMxtW6Od6Y9ufrQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by post.strato.de (mrclete mo37) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 405bbeo1KIY3Bg
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 20:26:57 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BCD5D18638; Mon, 20 Feb 2012 20:26:55 +0100 (CET)
Date: Mon, 20 Feb 2012 20:26:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120220192655.GA8280@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] libxenstore.so Makefile dependency 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


This is the second time I run into this linking issue. A few days ago it
happend with a make -j 4 or 8 during automated rpm package build. Now it
happend with a fresh tree. My local system is openSuSE 11.4 with make
3.82, the failed automated build was either openSUSE 11.4 or 12.1.

For some reason the libxenstore.so symlink is created after
init-xenstore-domain is about to be linked. The ln command is not
visible in this output, I saw the ln invocation in the rpm build log.

Hmm, and for some reason the symlink was not created anyway in my local
build. A second make run worked ok, libxenstore.so was created.  It
looks like I can reproduce it by running make clean in tools/xenstore.

Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
and libxenstore.so is also a target. So its not clear to me how make can
miss that, or how the dependencies should be listed.

Any idea whats going on here?

Olaf

...
gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .xenstored_posix.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -I. -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/include  -c -o xenstored_posix.o xenstored_posix.c
gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .init-xenstore-domain.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -I. -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/include -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/include  -c -o init-xenstore-domain.o init-xenstore-domain.c
gcc     -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o libxenstore.so.3.0.1 xs.opic xs_lib.opic  -lpthread
ar rcs libxenstore.a xs.o xs_lib.o
gcc     xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump
gcc     xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_linux.o xenstored_posix.o /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc/libxenctrl.so  -o xenstored
gcc     init-xenstore-domain.o libxenstore.so /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc/libxenctrl.so /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc/libxenguest.so /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/xenstore/libxenstore.so -o init-xenstore-domain
gcc: libxenstore.so: Datei oder Verzeichnis nicht gefunden
gcc: /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/xenstore/libxenstore.so: Datei oder Verzeichnis nicht gefunden
make[3]: *** [init-xenstore-domain] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[3]: Leaving directory `/work/xen/xendebug/xen-unstable.hg/tools/xenstore'
make[2]: *** [subdir-install-xenstore] Fehler 2
make[2]: Leaving directory `/work/xen/xendebug/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Fehler 2
make[1]: Leaving directory `/work/xen/xendebug/xen-unstable.hg/tools'
make: *** [install-tools] Fehler 2
make: *** Warte auf noch nicht beendete Prozesse...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzYt9-0004Tu-QZ; Mon, 20 Feb 2012 19:27:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzYt8-0004Sr-GM
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:27:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329766020!12306022!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18673 invoked from network); 20 Feb 2012 19:27:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 19:27:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329766019; l=3458;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=zXF+kGMSEER/pvQodOLAgfcRAEk=;
	b=Wrjr+XWMJ37gF8FMxeWQ0ySLR3yq0SB8v1ZvmkHNlVLt5N6SLyT2NbXnDYbX78sycnk
	/5hyHmh0+v13kB0aAh5aSau6xEU5hhzOTls1Jg65VfjiaGC4iJLkm4YX7VMzhqvlnIdd5
	LklwVlrZHD4IPL7JZSQ4kMxtW6Od6Y9ufrQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by post.strato.de (mrclete mo37) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 405bbeo1KIY3Bg
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 20:26:57 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BCD5D18638; Mon, 20 Feb 2012 20:26:55 +0100 (CET)
Date: Mon, 20 Feb 2012 20:26:55 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120220192655.GA8280@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: [Xen-devel] libxenstore.so Makefile dependency 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


This is the second time I run into this linking issue. A few days ago it
happend with a make -j 4 or 8 during automated rpm package build. Now it
happend with a fresh tree. My local system is openSuSE 11.4 with make
3.82, the failed automated build was either openSUSE 11.4 or 12.1.

For some reason the libxenstore.so symlink is created after
init-xenstore-domain is about to be linked. The ln command is not
visible in this output, I saw the ln invocation in the rpm build log.

Hmm, and for some reason the symlink was not created anyway in my local
build. A second make run worked ok, libxenstore.so was created.  It
looks like I can reproduce it by running make clean in tools/xenstore.

Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
and libxenstore.so is also a target. So its not clear to me how make can
miss that, or how the dependencies should be listed.

Any idea whats going on here?

Olaf

...
gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .xenstored_posix.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -I. -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/include  -c -o xenstored_posix.o xenstored_posix.c
gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement   -D__XEN_TOOLS__ -MMD -MF .init-xenstore-domain.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -I. -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/include -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc -I/work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/include  -c -o init-xenstore-domain.o init-xenstore-domain.c
gcc     -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o libxenstore.so.3.0.1 xs.opic xs_lib.opic  -lpthread
ar rcs libxenstore.a xs.o xs_lib.o
gcc     xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump
gcc     xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_linux.o xenstored_posix.o /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc/libxenctrl.so  -o xenstored
gcc     init-xenstore-domain.o libxenstore.so /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc/libxenctrl.so /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/libxc/libxenguest.so /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/xenstore/libxenstore.so -o init-xenstore-domain
gcc: libxenstore.so: Datei oder Verzeichnis nicht gefunden
gcc: /work/xen/xendebug/xen-unstable.hg/tools/xenstore/../../tools/xenstore/libxenstore.so: Datei oder Verzeichnis nicht gefunden
make[3]: *** [init-xenstore-domain] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[3]: Leaving directory `/work/xen/xendebug/xen-unstable.hg/tools/xenstore'
make[2]: *** [subdir-install-xenstore] Fehler 2
make[2]: Leaving directory `/work/xen/xendebug/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Fehler 2
make[1]: Leaving directory `/work/xen/xendebug/xen-unstable.hg/tools'
make: *** [install-tools] Fehler 2
make: *** Warte auf noch nicht beendete Prozesse...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:52:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZH9-00055u-59; Mon, 20 Feb 2012 19:51: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 1RzZH8-00055p-7G
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:51:54 +0000
Received: from [85.158.139.83:58989] by server-7.bemta-5.messagelabs.com id
	46/07-16195-954A24F4; Mon, 20 Feb 2012 19:51:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329767511!15860952!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10808 invoked from network); 20 Feb 2012 19:51:52 -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; 20 Feb 2012 19:51:52 -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 q1KJpmF9013775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 19:51:49 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
	q1KJpmfY007087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 19:51:48 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
	q1KJplvW012257; Mon, 20 Feb 2012 13:51:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 11:51:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C5E5F40469; Mon, 20 Feb 2012 14:48:34 -0500 (EST)
Date: Mon, 20 Feb 2012 14:48:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matthew Hook <matthew.hook@otoy.com>
Message-ID: <20120220194834.GA22650@phenom.dumpdata.com>
References: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
	<1329756300.3990.78.camel@zakaz.uk.xensource.com>
	<CAMrHX2VZKYJ8qQ+n2hAn2vmLjtDZNcguXddoYLAtZK_Lkw=Mdg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMrHX2VZKYJ8qQ+n2hAn2vmLjtDZNcguXddoYLAtZK_Lkw=Mdg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F42A455.00F7,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 relation to that, the BDF documentation
> > > (http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
> > > you can specify
> > > the extended BDF notation on your kernel boot line in grub.  i.e.
> > > xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
> > > the kernel log.
> >
> > That is the old wiki, the new page seems to be
> > http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation -- does this
> > still give you that impression? Please feel free to update to clarify.
> >
> > Yes, the new wiki still gives the impression you can use the extended
> notation everywhere.
> It'd be useful of the kernel boot line could take the extended notation.
> We are passing through many multi-function devices so the list gets quite
> large.

Patches are welcome..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:52:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZH9-00055u-59; Mon, 20 Feb 2012 19:51: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 1RzZH8-00055p-7G
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:51:54 +0000
Received: from [85.158.139.83:58989] by server-7.bemta-5.messagelabs.com id
	46/07-16195-954A24F4; Mon, 20 Feb 2012 19:51:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329767511!15860952!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1MjMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10808 invoked from network); 20 Feb 2012 19:51:52 -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; 20 Feb 2012 19:51:52 -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 q1KJpmF9013775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 19:51:49 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
	q1KJpmfY007087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Feb 2012 19:51:48 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
	q1KJplvW012257; Mon, 20 Feb 2012 13:51:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 11:51:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C5E5F40469; Mon, 20 Feb 2012 14:48:34 -0500 (EST)
Date: Mon, 20 Feb 2012 14:48:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matthew Hook <matthew.hook@otoy.com>
Message-ID: <20120220194834.GA22650@phenom.dumpdata.com>
References: <CAMrHX2XqXPj4umtPhu2KpOacRWZGN10Cm0uA__SYibJg+9D5ug@mail.gmail.com>
	<1329756300.3990.78.camel@zakaz.uk.xensource.com>
	<CAMrHX2VZKYJ8qQ+n2hAn2vmLjtDZNcguXddoYLAtZK_Lkw=Mdg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMrHX2VZKYJ8qQ+n2hAn2vmLjtDZNcguXddoYLAtZK_Lkw=Mdg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F42A455.00F7,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: error: ... PCI Device is not assignable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 relation to that, the BDF documentation
> > > (http://wiki.xensource.com/xenwiki/BDFNotation) seems to imply that
> > > you can specify
> > > the extended BDF notation on your kernel boot line in grub.  i.e.
> > > xen-pciback.hide=(0000:12:00.*) does not work.  You'll get an error in
> > > the kernel log.
> >
> > That is the old wiki, the new page seems to be
> > http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation -- does this
> > still give you that impression? Please feel free to update to clarify.
> >
> > Yes, the new wiki still gives the impression you can use the extended
> notation everywhere.
> It'd be useful of the kernel boot line could take the extended notation.
> We are passing through many multi-function devices so the list gets quite
> large.

Patches are welcome..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:55:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZJy-0005Eh-OJ; Mon, 20 Feb 2012 19:54:50 +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 1RzZJw-0005EK-Lr
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:54:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329767641!53205073!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3400 invoked from network); 20 Feb 2012 19:54:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 19:54:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329767682; l=556;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5BU/LrXkMH/Wu/n/z9mqacveBWI=;
	b=Dnv3lrHhiOSBnictiXGeDH+gTp2SnT48NfNtbqNoMhuUqmftmrTBzhgcfNzHKcBgw4v
	fE8nlmNfIIO9a1iFgtl+Nd2E52AwQMTKBT48w4QaxA+UXiIlKviX6p79DOjVtFHddq/xF
	6l9mWNZGxmdRAB5DmFKJU2SVRj64jtGcPMY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (jimi mo34) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j01a84o1KIPO7w
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 20:54:37 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7B08118638; Mon, 20 Feb 2012 20:54:35 +0100 (CET)
Date: Mon, 20 Feb 2012 20:54:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120220195435.GA22351@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120220192655.GA8280@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, Olaf Hering wrote:

> Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
> and libxenstore.so is also a target. So its not clear to me how make can
> miss that, or how the dependencies should be listed.

With this change, putting init-xenstore-domain first, I can not reproduce it anymore.


-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
+ALL_TARGETS = init-xenstore-domain libxenstore.so libxenstore.a clients xs_tdb_dump xenstored

Is this correct?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:55:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:55:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZJy-0005Eh-OJ; Mon, 20 Feb 2012 19:54:50 +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 1RzZJw-0005EK-Lr
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:54:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329767641!53205073!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3400 invoked from network); 20 Feb 2012 19:54:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 19:54:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329767682; l=556;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5BU/LrXkMH/Wu/n/z9mqacveBWI=;
	b=Dnv3lrHhiOSBnictiXGeDH+gTp2SnT48NfNtbqNoMhuUqmftmrTBzhgcfNzHKcBgw4v
	fE8nlmNfIIO9a1iFgtl+Nd2E52AwQMTKBT48w4QaxA+UXiIlKviX6p79DOjVtFHddq/xF
	6l9mWNZGxmdRAB5DmFKJU2SVRj64jtGcPMY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (jimi mo34) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j01a84o1KIPO7w
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 20:54:37 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7B08118638; Mon, 20 Feb 2012 20:54:35 +0100 (CET)
Date: Mon, 20 Feb 2012 20:54:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120220195435.GA22351@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120220192655.GA8280@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, Olaf Hering wrote:

> Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
> and libxenstore.so is also a target. So its not clear to me how make can
> miss that, or how the dependencies should be listed.

With this change, putting init-xenstore-domain first, I can not reproduce it anymore.


-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
+ALL_TARGETS = init-xenstore-domain libxenstore.so libxenstore.a clients xs_tdb_dump xenstored

Is this correct?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:58:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzZMx-0005SL-Bv; Mon, 20 Feb 2012 19:57:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RzZMv-0005SD-B0
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:57:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329767798!62147486!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU2NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13003 invoked from network); 20 Feb 2012 19:56:38 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.202) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 19:56:38 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5F0301A8076;
	Mon, 20 Feb 2012 11:57:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Hus3bFvLBKiLsW6SlHcsghvom46lhCTtaA0CZHN3zBAY
	2ZNhXFr4XUuFULldzE8ewL/Uod9HGqz+3cTW8Fd+65mqltX9uE1MCObESWsMAIQ0
	xk0muzEZIlgvvEmPO/Kp6E88dWb04cPVqGNdSrraqJ/DankIkzm+vB+HK/fFST0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=fGdWHmB2ivRTPGoXrplGxEPFsjg=; b=NU4sFddD
	VQlxJdiflezE4rBofhkpEmiwMwM/cefFFrJrkMi7IbiIIWsDJLPylRZDrLwqhgWM
	1P1RXFWxcuFOIMSLOvB7gg9Zo/k0A/IRcbZKMmXNRCctwNv6Ld6pxqPSER3fr4p2
	uXrVkhnsAQb9N5Ou56A/1xcZmaotgYezoC8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 092C21A8063; 
	Mon, 20 Feb 2012 11:57:51 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 20 Feb 2012 11:57:51 -0800
Message-ID: <bd363cfc90524cf50ea2db9a1dd6bee5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20290.28974.328634.111629@mariner.uk.xensource.com>
References: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
	<20290.28974.328634.111629@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 11:57:51 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	andres@gridcentric.ca, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Testing for mem event ring management
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH] Testing for mem event
> ring management"):
>> This is example code, not meant for tree consumption. So
>> that others can run tests on the ring management bits.
>
> Is this supposed to apply to tip, and build ?
It was, way back when.

This isn't a significant diff from tests/xen-access either -- Effecitvely,
it just sets a different mem_access type (n2rwx, instead of rw2rx)

Andres

>
> memoper.c:48: error: expected specifier-qualifier-list before
> 'mem_event_t'
> memoper.c: In function 'wait_for_event_or_timeout':
> memoper.c:66: error: 'memaccess_t' has no member named 'mem_event'
> memoper.c:99: error: 'memaccess_t' has no member named 'mem_event'
> ...
>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:58:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19: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 1RzZMx-0005SL-Bv; Mon, 20 Feb 2012 19:57:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RzZMv-0005SD-B0
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:57:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329767798!62147486!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU2NTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13003 invoked from network); 20 Feb 2012 19:56:38 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.202) by server-7.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 19:56:38 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 5F0301A8076;
	Mon, 20 Feb 2012 11:57:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Hus3bFvLBKiLsW6SlHcsghvom46lhCTtaA0CZHN3zBAY
	2ZNhXFr4XUuFULldzE8ewL/Uod9HGqz+3cTW8Fd+65mqltX9uE1MCObESWsMAIQ0
	xk0muzEZIlgvvEmPO/Kp6E88dWb04cPVqGNdSrraqJ/DankIkzm+vB+HK/fFST0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=fGdWHmB2ivRTPGoXrplGxEPFsjg=; b=NU4sFddD
	VQlxJdiflezE4rBofhkpEmiwMwM/cefFFrJrkMi7IbiIIWsDJLPylRZDrLwqhgWM
	1P1RXFWxcuFOIMSLOvB7gg9Zo/k0A/IRcbZKMmXNRCctwNv6Ld6pxqPSER3fr4p2
	uXrVkhnsAQb9N5Ou56A/1xcZmaotgYezoC8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 092C21A8063; 
	Mon, 20 Feb 2012 11:57:51 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 20 Feb 2012 11:57:51 -0800
Message-ID: <bd363cfc90524cf50ea2db9a1dd6bee5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20290.28974.328634.111629@mariner.uk.xensource.com>
References: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
	<20290.28974.328634.111629@mariner.uk.xensource.com>
Date: Mon, 20 Feb 2012 11:57:51 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	andres@gridcentric.ca, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Testing for mem event ring management
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH] Testing for mem event
> ring management"):
>> This is example code, not meant for tree consumption. So
>> that others can run tests on the ring management bits.
>
> Is this supposed to apply to tip, and build ?
It was, way back when.

This isn't a significant diff from tests/xen-access either -- Effecitvely,
it just sets a different mem_access type (n2rwx, instead of rw2rx)

Andres

>
> memoper.c:48: error: expected specifier-qualifier-list before
> 'mem_event_t'
> memoper.c: In function 'wait_for_event_or_timeout':
> memoper.c:66: error: 'memaccess_t' has no member named 'mem_event'
> memoper.c:99: error: 'memaccess_t' has no member named 'mem_event'
> ...
>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:59:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZOI-0005Xo-RB; Mon, 20 Feb 2012 19:59:18 +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 1RzZOH-0005Xh-7v
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:59:17 +0000
Received: from [85.158.139.83:17923] by server-3.bemta-5.messagelabs.com id
	9E/7A-06438-416A24F4; Mon, 20 Feb 2012 19:59:16 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329767955!15879605!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12616 invoked from network); 20 Feb 2012 19:59:15 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-5.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 19:59:15 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id D5F9FD347CA;
	Mon, 20 Feb 2012 20:59:13 +0100 (CET)
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 bzWS87vep65f; Mon, 20 Feb 2012 20:59:02 +0100 (CET)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 35E23D34747;
	Mon, 20 Feb 2012 20:58:59 +0100 (CET)
Message-ID: <4F42A601.7000701@vido.info>
Date: Mon, 20 Feb 2012 20:58:57 +0100
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
	<CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
In-Reply-To: <CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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

With the patch you mentioned, xl create looks more familiar:

libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument


This is actually "normal", at least compared to traditional qemu-dm - i 
guess due to missing FLR (Bios is capable, but Card not i assume).

Anyhow - the downside of the patch is, qemu doesnt even start :)

This is qemu-dm.log (with debugging enabled):

[00:06.0] pci_intx: intx=1
[00:06.0] pt_initfn: Real physical device 03:00.0 registered successfuly!
[00:07.0] pt_initfn: Assigning real physical device 03:00.1 to devfn 0x38
[00:07.0] pt_register_regions: IO region 0 registered (size=0x00004000 
base_addr=0xc3120000 type: 0)
[00:07.0] pci_intx: intx=2
[00:07.0] pt_initfn: Real physical device 03:00.1 registered successfuly!
[00:08.0] pt_initfn: Assigning real physical device 00:1d.0 to devfn 0x40
[00:08.0] pt_register_regions: IO region 4 registered (size=0x00000020 
base_addr=0x00005080 type: 0x1)
[00:08.0] pci_intx: intx=1
[00:08.0] pt_initfn: Real physical device 00:1d.0 registered successfuly!
[00:09.0] pt_initfn: Assigning real physical device 00:1d.1 to devfn 0x48
[00:09.0] pt_register_regions: IO region 4 registered (size=0x00000020 
base_addr=0x00005060 type: 0x1)
[00:09.0] pci_intx: intx=2
[00:09.0] pt_initfn: Real physical device 00:1d.1 registered successfuly!
[00:0a.0] pt_initfn: Assigning real physical device 00:1d.2 to devfn 0x50
[00:0a.0] pt_register_regions: IO region 4 registered (size=0x00000020 
base_addr=0x00005040 type: 0x1)
[00:0a.0] pci_intx: intx=3
[00:0a.0] pt_initfn: Real physical device 00:1d.2 registered successfuly!
[00:0b.0] pt_initfn: Assigning real physical device 00:1d.7 to devfn 0x58
[00:0b.0] pt_register_regions: IO region 0 registered (size=0x00000400 
base_addr=0xc3321000 type: 0)
[00:0b.0] pci_intx: intx=1
[00:0b.0] pt_initfn: Real physical device 00:1d.7 registered successfuly!
[00:06.0] pt_pci_read_config: address=0x000a val=0x00000300 len=2
[00:06.0] pt_pci_read_config: address=0x0000 val=0x00001002 len=2
[00:06.0] pt_pci_read_config: address=0x0002 val=0x00006718 len=2
[00:06.0] pt_pci_read_config: address=0x0010 val=0x0000000c len=4
[00:06.0] pt_pci_write_config: address=0x0010 val=0xffffffff len=4
[00:06.0] pt_iomem_map: BAR 0, e_phys=0xffffffffffffffff 
maddr=0xe0000000 len=0x10000000 first_map=1
[00:06.0] pt_pci_read_config: address=0x0010 val=0xf000000c len=4
[00:06.0] pt_pci_write_config: address=0x0010 val=0x0000000c len=4
[00:06.0] pt_iomem_map: BAR 0, e_phys=0xffffffffffffffff 
maddr=0xe0000000 len=0x10000000 first_map=0
[00:06.0] pt_pci_read_config: address=0x0018 val=0x00000004 len=4
[00:06.0] pt_pci_write_config: address=0x0018 val=0xffffffff len=4
[00:06.0] pt_iomem_map: BAR 2, e_phys=0xffffffffffffffff 
maddr=0xc3100000 len=0x20000 first_map=1
[00:06.0] pt_pci_read_config: address=0x0018 val=0xfffe0004 len=4
[00:06.0] pt_pci_write_config: address=0x0018 val=0x00000004 len=4
[00:06.0] pt_iomem_map: BAR 2, e_phys=0xffffffffffffffff 
maddr=0xc3100000 len=0x20000 first_map=0
[00:06.0] pt_pci_read_config: address=0x0020 val=0x00000001 len=4
[00:06.0] pt_pci_write_config: address=0x0020 val=0xffffffff len=4
[00:06.0] pt_ioport_map: BAR 4, e_phys=0xffffffffffffffff 
pio_base=0x2000 len=256 first_map=1
[00:06.0] pt_pci_read_config: address=0x0020 val=0xffffff01 len=4
[00:06.0] pt_pci_write_config: address=0x0020 val=0x00000001 len=4
[00:06.0] pt_ioport_map: BAR 4, e_phys=0xffffffffffffffff 
pio_base=0x2000 len=256 first_map=0
[00:06.0] pt_pci_read_config: address=0x0024 val=0x00000000 len=4
[00:06.0] pt_pci_write_config: address=0x0024 val=0xffffffff len=4
[00:06.0] pt_pci_read_config: address=0x0024 val=0x00000000 len=4
[00:06.0] pt_pci_write_config: address=0x0024 val=0x00000000 len=4
[00:06.0] pt_pci_read_config: address=0x0030 val=0x00000000 len=4
[00:06.0] pt_pci_write_config: address=0x0030 val=0xffffffff len=4
[00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff 
maddr=0xc3140000 len=0x20000 first_map=1
[00:06.0] pt_pci_read_config: address=0x0030 val=0xfffe0001 len=4
[00:06.0] pt_pci_write_config: address=0x0030 val=0x00000000 len=4
[00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff 
maddr=0xc3140000 len=0x20000 first_map=0
[00:06.0] pt_pci_read_config: address=0x003d val=0x00000001 len=1
[00:06.0] pt_pci_write_config: address=0x003c val=0x0000000b len=1
[00:06.0] pt_pci_read_config: address=0x0004 val=0x00000000 len=2
[00:06.0] pt_pci_write_config: address=0x0004 val=0x00000004 len=2
qemu-system-x86_64: 
/usr/src/xen-with-upstream-qemu-patch/upstream-qemu/qemu/memory.c:1378: 
memory_region_del_subregion: Assertion `subregion->parent == mr' failed.
Waiting for data...



Am 20.02.2012 18:08, schrieb Anthony PERARD:
> On Mon, Feb 20, 2012 at 16:11, Tobias Geiger<tobias.geiger@vido.info>  wrote:
>> My Domu (Win7_64) boots fine, but 2 of my 6 passed-through pcidevices dont get
>> passed through at all:
>>
>> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
>> /sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
>> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
>> message from QMP server: Device 'xen-pci-passthrough' could not be initialized
>> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
>> /sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
>> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
>> message from QMP server: Device 'xen-pci-passthrough' could not be initialized
> These two errors are probably because my patch series depend on one
> other patch sent earlier:
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg01027.html
>
>> The other 4 PCI-Ids (USB Controller) get passed through, but the USB-Devices
>> attached to them are "Not Working" according to Windows Device-Manager.
>>
>> All Devices worked with the old qemu-dm (traditional).
>>
>> Anything i can do to debug this further?
> You can send the log of qemu ( /var/log/xen/qemu-dm-$vm_name.log ).
> There is also a way to have more from QEMU by decommenting this two lines:
> /* #define PT_LOGGING_ENABLED */
> /* #define PT_DEBUG_PCI_CONFIG_ACCESS */
> in hw/xen_pci_passthrough.h
>
> Thanks for the testing,
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 19:59:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 19:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZOI-0005Xo-RB; Mon, 20 Feb 2012 19:59:18 +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 1RzZOH-0005Xh-7v
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 19:59:17 +0000
Received: from [85.158.139.83:17923] by server-3.bemta-5.messagelabs.com id
	9E/7A-06438-416A24F4; Mon, 20 Feb 2012 19:59:16 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329767955!15879605!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12616 invoked from network); 20 Feb 2012 19:59:15 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-5.tower-182.messagelabs.com with SMTP;
	20 Feb 2012 19:59:15 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id D5F9FD347CA;
	Mon, 20 Feb 2012 20:59:13 +0100 (CET)
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 bzWS87vep65f; Mon, 20 Feb 2012 20:59:02 +0100 (CET)
Received: from [10.18.11.10] (HSI-KBW-085-216-123-237.hsi.kabelbw.de
	[85.216.123.237])
	by mail.vido.info (Postfix) with ESMTPSA id 35E23D34747;
	Mon, 20 Feb 2012 20:58:59 +0100 (CET)
Message-ID: <4F42A601.7000701@vido.info>
Date: Mon, 20 Feb 2012 20:58:57 +0100
From: Tobias Geiger <tobias.geiger@vido.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
	<CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
In-Reply-To: <CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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

With the patch you mentioned, xl create looks more familiar:

libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to 
/sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument


This is actually "normal", at least compared to traditional qemu-dm - i 
guess due to missing FLR (Bios is capable, but Card not i assume).

Anyhow - the downside of the patch is, qemu doesnt even start :)

This is qemu-dm.log (with debugging enabled):

[00:06.0] pci_intx: intx=1
[00:06.0] pt_initfn: Real physical device 03:00.0 registered successfuly!
[00:07.0] pt_initfn: Assigning real physical device 03:00.1 to devfn 0x38
[00:07.0] pt_register_regions: IO region 0 registered (size=0x00004000 
base_addr=0xc3120000 type: 0)
[00:07.0] pci_intx: intx=2
[00:07.0] pt_initfn: Real physical device 03:00.1 registered successfuly!
[00:08.0] pt_initfn: Assigning real physical device 00:1d.0 to devfn 0x40
[00:08.0] pt_register_regions: IO region 4 registered (size=0x00000020 
base_addr=0x00005080 type: 0x1)
[00:08.0] pci_intx: intx=1
[00:08.0] pt_initfn: Real physical device 00:1d.0 registered successfuly!
[00:09.0] pt_initfn: Assigning real physical device 00:1d.1 to devfn 0x48
[00:09.0] pt_register_regions: IO region 4 registered (size=0x00000020 
base_addr=0x00005060 type: 0x1)
[00:09.0] pci_intx: intx=2
[00:09.0] pt_initfn: Real physical device 00:1d.1 registered successfuly!
[00:0a.0] pt_initfn: Assigning real physical device 00:1d.2 to devfn 0x50
[00:0a.0] pt_register_regions: IO region 4 registered (size=0x00000020 
base_addr=0x00005040 type: 0x1)
[00:0a.0] pci_intx: intx=3
[00:0a.0] pt_initfn: Real physical device 00:1d.2 registered successfuly!
[00:0b.0] pt_initfn: Assigning real physical device 00:1d.7 to devfn 0x58
[00:0b.0] pt_register_regions: IO region 0 registered (size=0x00000400 
base_addr=0xc3321000 type: 0)
[00:0b.0] pci_intx: intx=1
[00:0b.0] pt_initfn: Real physical device 00:1d.7 registered successfuly!
[00:06.0] pt_pci_read_config: address=0x000a val=0x00000300 len=2
[00:06.0] pt_pci_read_config: address=0x0000 val=0x00001002 len=2
[00:06.0] pt_pci_read_config: address=0x0002 val=0x00006718 len=2
[00:06.0] pt_pci_read_config: address=0x0010 val=0x0000000c len=4
[00:06.0] pt_pci_write_config: address=0x0010 val=0xffffffff len=4
[00:06.0] pt_iomem_map: BAR 0, e_phys=0xffffffffffffffff 
maddr=0xe0000000 len=0x10000000 first_map=1
[00:06.0] pt_pci_read_config: address=0x0010 val=0xf000000c len=4
[00:06.0] pt_pci_write_config: address=0x0010 val=0x0000000c len=4
[00:06.0] pt_iomem_map: BAR 0, e_phys=0xffffffffffffffff 
maddr=0xe0000000 len=0x10000000 first_map=0
[00:06.0] pt_pci_read_config: address=0x0018 val=0x00000004 len=4
[00:06.0] pt_pci_write_config: address=0x0018 val=0xffffffff len=4
[00:06.0] pt_iomem_map: BAR 2, e_phys=0xffffffffffffffff 
maddr=0xc3100000 len=0x20000 first_map=1
[00:06.0] pt_pci_read_config: address=0x0018 val=0xfffe0004 len=4
[00:06.0] pt_pci_write_config: address=0x0018 val=0x00000004 len=4
[00:06.0] pt_iomem_map: BAR 2, e_phys=0xffffffffffffffff 
maddr=0xc3100000 len=0x20000 first_map=0
[00:06.0] pt_pci_read_config: address=0x0020 val=0x00000001 len=4
[00:06.0] pt_pci_write_config: address=0x0020 val=0xffffffff len=4
[00:06.0] pt_ioport_map: BAR 4, e_phys=0xffffffffffffffff 
pio_base=0x2000 len=256 first_map=1
[00:06.0] pt_pci_read_config: address=0x0020 val=0xffffff01 len=4
[00:06.0] pt_pci_write_config: address=0x0020 val=0x00000001 len=4
[00:06.0] pt_ioport_map: BAR 4, e_phys=0xffffffffffffffff 
pio_base=0x2000 len=256 first_map=0
[00:06.0] pt_pci_read_config: address=0x0024 val=0x00000000 len=4
[00:06.0] pt_pci_write_config: address=0x0024 val=0xffffffff len=4
[00:06.0] pt_pci_read_config: address=0x0024 val=0x00000000 len=4
[00:06.0] pt_pci_write_config: address=0x0024 val=0x00000000 len=4
[00:06.0] pt_pci_read_config: address=0x0030 val=0x00000000 len=4
[00:06.0] pt_pci_write_config: address=0x0030 val=0xffffffff len=4
[00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff 
maddr=0xc3140000 len=0x20000 first_map=1
[00:06.0] pt_pci_read_config: address=0x0030 val=0xfffe0001 len=4
[00:06.0] pt_pci_write_config: address=0x0030 val=0x00000000 len=4
[00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff 
maddr=0xc3140000 len=0x20000 first_map=0
[00:06.0] pt_pci_read_config: address=0x003d val=0x00000001 len=1
[00:06.0] pt_pci_write_config: address=0x003c val=0x0000000b len=1
[00:06.0] pt_pci_read_config: address=0x0004 val=0x00000000 len=2
[00:06.0] pt_pci_write_config: address=0x0004 val=0x00000004 len=2
qemu-system-x86_64: 
/usr/src/xen-with-upstream-qemu-patch/upstream-qemu/qemu/memory.c:1378: 
memory_region_del_subregion: Assertion `subregion->parent == mr' failed.
Waiting for data...



Am 20.02.2012 18:08, schrieb Anthony PERARD:
> On Mon, Feb 20, 2012 at 16:11, Tobias Geiger<tobias.geiger@vido.info>  wrote:
>> My Domu (Win7_64) boots fine, but 2 of my 6 passed-through pcidevices dont get
>> passed through at all:
>>
>> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
>> /sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
>> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
>> message from QMP server: Device 'xen-pci-passthrough' could not be initialized
>> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
>> /sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
>> libxl: error: libxl_qmp.c:239:qmp_handle_error_response: received an error
>> message from QMP server: Device 'xen-pci-passthrough' could not be initialized
> These two errors are probably because my patch series depend on one
> other patch sent earlier:
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg01027.html
>
>> The other 4 PCI-Ids (USB Controller) get passed through, but the USB-Devices
>> attached to them are "Not Working" according to Windows Device-Manager.
>>
>> All Devices worked with the old qemu-dm (traditional).
>>
>> Anything i can do to debug this further?
> You can send the log of qemu ( /var/log/xen/qemu-dm-$vm_name.log ).
> There is also a way to have more from QEMU by decommenting this two lines:
> /* #define PT_LOGGING_ENABLED */
> /* #define PT_DEBUG_PCI_CONFIG_ACCESS */
> in hw/xen_pci_passthrough.h
>
> Thanks for the testing,
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:00:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZPM-0005i6-AP; Mon, 20 Feb 2012 20:00:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RzZPL-0005hQ-0H
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:00:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329768015!15590204!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0MzAx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20237 invoked from network); 20 Feb 2012 20:00:15 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-8.tower-216.messagelabs.com with SMTP;
	20 Feb 2012 20:00:15 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 320AC714070;
	Mon, 20 Feb 2012 12:00:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Z08+8zuzZ0NhJbETLSp+I7mmCmpWljYfgQD0T5HXrM1r
	cNSJmBBsqYagoXTDIgmwdHwUH6cjzJeqmK3MVyku/eqv/3VCvtA7w/m/E6aIcOiC
	HpuW8vjOTOvhUsfCZl5YtrthQCODqvBIEt+4LggoNQ1t9YXH2banAxhHwSBCuGs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Ox1+U1ZrYNvQbjDQLjkWLGVh/nk=; b=uhK77CS4
	Xck2sNyUXhntZ2MRrgL3s1Q5I0MssBnT0XH0uYrVjz24keze8i8utaCSKWuFwHLz
	wlPUR0kDEpsIGzQOCZhXhKICkRebfvZe/r9wpv8J8LumRsFbvzEq5MP/JRNo+ZnD
	q9EbPEU6C6pv2Vj5SbjRsd5kAM+HODbIjO8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id C7EC971406F; 
	Mon, 20 Feb 2012 12:00:13 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 20 Feb 2012 12:00:14 -0800
Message-ID: <6c7311172e1476307dbe478c9b0c760d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4065.1329753857.1471.xen-devel@lists.xensource.com>
References: <mailman.4065.1329753857.1471.xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 12:00:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Date: Mon, 20 Feb 2012 15:52:01 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: xen-devel <xen-devel@lists.xensource.com>
> Subject: [Xen-devel] 4.2 TODO update
> Message-ID: <1329753121.3990.67.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> This weeks update. As usual please ping me with any updates.
>
> hypervisor, blockers:
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich, DONE)
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)
>       * get the interface changes for sharing/paging/mem-events done and
>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>         Andres Lagar-Cavilla et al)
>               * sharing patches posted (DONE)
>
> tools, blockers:
>
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 patches reposted)
>               * Safe fork vs. fd handling hooks. This is an API
>                 addition, so maybe not required fro stable API, bit need
>                 to have for 4.2? (Ian J)
>               * xl feature parity with xend wrt driver domain support
>                 (George Dunlap)
>               * More formally deprecate xm/xend. Manpage patches already
>                 in tree. Needs release noting and communication around
>                 -rc1 to remind people to test xl.
>       * Correct paging/sharing tools buffer mlocking (Tim, Andres)
Will post later in the week.

>       * Autoconf (Roger Pau Monn? & Ian J, blocked on test
>         infrastructure changes, Roger to respin patch when test system
>         ready for new features)
>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>
> hypervisor, nice to have:
>
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al)
>       * A long standing issue is a fully synchronized p2m (locking
>         lookups) (Andres Lagar-Cavilla, patches posted?)
This one is DONE

Thanks,
Andres
>
> tools, nice to have:
>
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? (Roger Pau Monn?, patches posted)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monn?)
>       * Configure/control paging via xl/libxl (Olaf Herring)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 patches sent)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini, patches sent, waiting for upstream ack)
>       * Nested-virtualisation (currently should be marked experimental,
>         likely to release that way? Consider nested-svm separate to
>         nested-vmx. Nested-svm is in better shape)
>       * Initial xl support for Remus (memory checkpoint, blackholing)
>         (Shriram, patches posted)
>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
>         (Nobody AFAICT)
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:00:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZPM-0005i6-AP; Mon, 20 Feb 2012 20:00:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RzZPL-0005hQ-0H
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:00:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329768015!15590204!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0MzAx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20237 invoked from network); 20 Feb 2012 20:00:15 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-8.tower-216.messagelabs.com with SMTP;
	20 Feb 2012 20:00:15 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 320AC714070;
	Mon, 20 Feb 2012 12:00:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Z08+8zuzZ0NhJbETLSp+I7mmCmpWljYfgQD0T5HXrM1r
	cNSJmBBsqYagoXTDIgmwdHwUH6cjzJeqmK3MVyku/eqv/3VCvtA7w/m/E6aIcOiC
	HpuW8vjOTOvhUsfCZl5YtrthQCODqvBIEt+4LggoNQ1t9YXH2banAxhHwSBCuGs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Ox1+U1ZrYNvQbjDQLjkWLGVh/nk=; b=uhK77CS4
	Xck2sNyUXhntZ2MRrgL3s1Q5I0MssBnT0XH0uYrVjz24keze8i8utaCSKWuFwHLz
	wlPUR0kDEpsIGzQOCZhXhKICkRebfvZe/r9wpv8J8LumRsFbvzEq5MP/JRNo+ZnD
	q9EbPEU6C6pv2Vj5SbjRsd5kAM+HODbIjO8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id C7EC971406F; 
	Mon, 20 Feb 2012 12:00:13 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 20 Feb 2012 12:00:14 -0800
Message-ID: <6c7311172e1476307dbe478c9b0c760d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4065.1329753857.1471.xen-devel@lists.xensource.com>
References: <mailman.4065.1329753857.1471.xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 12:00:14 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.campbell@citrix.com
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Date: Mon, 20 Feb 2012 15:52:01 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: xen-devel <xen-devel@lists.xensource.com>
> Subject: [Xen-devel] 4.2 TODO update
> Message-ID: <1329753121.3990.67.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> This weeks update. As usual please ping me with any updates.
>
> hypervisor, blockers:
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich, DONE)
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)
>       * get the interface changes for sharing/paging/mem-events done and
>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>         Andres Lagar-Cavilla et al)
>               * sharing patches posted (DONE)
>
> tools, blockers:
>
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 patches reposted)
>               * Safe fork vs. fd handling hooks. This is an API
>                 addition, so maybe not required fro stable API, bit need
>                 to have for 4.2? (Ian J)
>               * xl feature parity with xend wrt driver domain support
>                 (George Dunlap)
>               * More formally deprecate xm/xend. Manpage patches already
>                 in tree. Needs release noting and communication around
>                 -rc1 to remind people to test xl.
>       * Correct paging/sharing tools buffer mlocking (Tim, Andres)
Will post later in the week.

>       * Autoconf (Roger Pau Monn? & Ian J, blocked on test
>         infrastructure changes, Roger to respin patch when test system
>         ready for new features)
>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>
> hypervisor, nice to have:
>
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al)
>       * A long standing issue is a fully synchronized p2m (locking
>         lookups) (Andres Lagar-Cavilla, patches posted?)
This one is DONE

Thanks,
Andres
>
> tools, nice to have:
>
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? (Roger Pau Monn?, patches posted)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monn?)
>       * Configure/control paging via xl/libxl (Olaf Herring)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 patches sent)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini, patches sent, waiting for upstream ack)
>       * Nested-virtualisation (currently should be marked experimental,
>         likely to release that way? Consider nested-svm separate to
>         nested-vmx. Nested-svm is in better shape)
>       * Initial xl support for Remus (memory checkpoint, blackholing)
>         (Shriram, patches posted)
>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
>         (Nobody AFAICT)
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:04:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZSh-0005zQ-7e; Mon, 20 Feb 2012 20:03:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RzZSf-0005ym-Kk
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:03:49 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329768220!14097742!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23632 invoked from network); 20 Feb 2012 20:03:42 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 20:03:42 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1KK3bdY014759
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 12:03:38 -0800
Received: by bkcjg15 with SMTP id jg15so9918675bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 12:03:36 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.152.25 as permitted sender) client-ip=10.204.152.25; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.152.25 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.152.25])
	by 10.204.152.25 with SMTP id e25mr11594781bkw.49.1329768216407
	(num_hops = 1); Mon, 20 Feb 2012 12:03:36 -0800 (PST)
Received: by 10.204.152.25 with SMTP id e25mr9351784bkw.49.1329768216329; Mon,
	20 Feb 2012 12:03:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 20 Feb 2012 12:02:56 -0800 (PST)
In-Reply-To: <20290.38989.768884.347346@mariner.uk.xensource.com>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 20 Feb 2012 12:02:56 -0800
Message-ID: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6565779234677905531=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6565779234677905531==
Content-Type: multipart/alternative; boundary=0015175cbae62aff4e04b96acae8

--0015175cbae62aff4e04b96acae8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support
> suspend_cancel in domain_resume"):
> > libxl: support suspend_cancel in domain_resume
>
> I get this:
>
> libxl.c: In function 'libxl_domain_resume':
> libxl.c:315: error: implicit declaration of function
> 'libxl__domain_resume_device_model'
>
> Did you compile this ?  Did you test it ?
>
>
Yes I did.. Did you apply the previous patch in this series, that
introduces the above (missing)  function ?

As I mentioned in the introductory email, these patches also depend on
Stefano's XC_SAVE_ID_TOOLSTACK patches.

01 Introduce a new save_id to save/restore toolstack specific extra
02 Read Qemu's physmap from xenstore and save it using toolstack_save.
03 Following the recent changes to upstream Qemu, the best monitor command
    (removes qmp_migrate and introduces qmp_save)


Then my patches:
03 libxl: QMP stop/resume & refactor QEMU suspend/resume/save
04 libxl: support suspend_cancel in domain_resume
05 libxl: refactor migrate_domain and generalize migrate_receive
06 libxl: resume instead of unpause on xl save -c

01 libxl: Remus - suspend/postflush/commit callbacks
02 libxl: Remus - xl remus command

Currently, one of stefano's patches doesnt apply cleanly - the first one.
It requires minor fix.
Barring that, all the other patches mentioned above apply cleanly.


Thanks,
> Ian.
>
>

--0015175cbae62aff4e04b96acae8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu.citrix.com">Ian.Jackso=
n@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> writes (&quot;=
[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resum=
e&quot;):<br>
<div class=3D"im">&gt; libxl: support suspend_cancel in domain_resume<br>
<br>
</div>I get this:<br>
<br>
libxl.c: In function &#39;libxl_domain_resume&#39;:<br>
libxl.c:315: error: implicit declaration of function &#39;libxl__domain_res=
ume_device_model&#39;<br>
<br>
Did you compile this ? =A0Did you test it ?<br>
<br></blockquote><div><br>Yes I did.. Did you apply the previous patch in t=
his series, that introduces the above (missing)=A0 function ?<br><br>As I m=
entioned in the introductory email, these patches also depend on Stefano&#3=
9;s XC_SAVE_ID_TOOLSTACK patches.<br>

<br>01 Introduce a new save_id to save/restore toolstack specific extra<br>=
02 Read Qemu&#39;s physmap from xenstore and save it using toolstack_save.<=
br>
03 Following the recent changes to upstream Qemu, the best monitor command<=
br>=A0=A0=A0
(removes qmp_migrate and introduces qmp_save)<br><br><br>Then my patches:<b=
r>03 libxl: QMP stop/resume &amp; refactor QEMU suspend/resume/save<br>04 l=
ibxl: support suspend_cancel in domain_resume<br>05 libxl: refactor migrate=
_domain and generalize migrate_receive<br>

06 libxl: resume instead of unpause on xl save -c<br><br>01 libxl: Remus - =
suspend/postflush/commit callbacks<br>02 libxl: Remus - xl remus command<br=
><br>Currently, one of stefano&#39;s patches doesnt apply cleanly - the fir=
st one. It requires minor fix.<br>

Barring that, all the other patches mentioned above apply cleanly.<br><br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>

--0015175cbae62aff4e04b96acae8--


--===============6565779234677905531==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============6565779234677905531==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 20:04:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZSh-0005zQ-7e; Mon, 20 Feb 2012 20:03:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RzZSf-0005ym-Kk
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:03:49 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329768220!14097742!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23632 invoked from network); 20 Feb 2012 20:03:42 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 20:03:42 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1KK3bdY014759
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 12:03:38 -0800
Received: by bkcjg15 with SMTP id jg15so9918675bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 12:03:36 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.152.25 as permitted sender) client-ip=10.204.152.25; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.152.25 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.152.25])
	by 10.204.152.25 with SMTP id e25mr11594781bkw.49.1329768216407
	(num_hops = 1); Mon, 20 Feb 2012 12:03:36 -0800 (PST)
Received: by 10.204.152.25 with SMTP id e25mr9351784bkw.49.1329768216329; Mon,
	20 Feb 2012 12:03:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 20 Feb 2012 12:02:56 -0800 (PST)
In-Reply-To: <20290.38989.768884.347346@mariner.uk.xensource.com>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 20 Feb 2012 12:02:56 -0800
Message-ID: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6565779234677905531=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6565779234677905531==
Content-Type: multipart/alternative; boundary=0015175cbae62aff4e04b96acae8

--0015175cbae62aff4e04b96acae8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support
> suspend_cancel in domain_resume"):
> > libxl: support suspend_cancel in domain_resume
>
> I get this:
>
> libxl.c: In function 'libxl_domain_resume':
> libxl.c:315: error: implicit declaration of function
> 'libxl__domain_resume_device_model'
>
> Did you compile this ?  Did you test it ?
>
>
Yes I did.. Did you apply the previous patch in this series, that
introduces the above (missing)  function ?

As I mentioned in the introductory email, these patches also depend on
Stefano's XC_SAVE_ID_TOOLSTACK patches.

01 Introduce a new save_id to save/restore toolstack specific extra
02 Read Qemu's physmap from xenstore and save it using toolstack_save.
03 Following the recent changes to upstream Qemu, the best monitor command
    (removes qmp_migrate and introduces qmp_save)


Then my patches:
03 libxl: QMP stop/resume & refactor QEMU suspend/resume/save
04 libxl: support suspend_cancel in domain_resume
05 libxl: refactor migrate_domain and generalize migrate_receive
06 libxl: resume instead of unpause on xl save -c

01 libxl: Remus - suspend/postflush/commit callbacks
02 libxl: Remus - xl remus command

Currently, one of stefano's patches doesnt apply cleanly - the first one.
It requires minor fix.
Barring that, all the other patches mentioned above apply cleanly.


Thanks,
> Ian.
>
>

--0015175cbae62aff4e04b96acae8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu.citrix.com">Ian.Jackso=
n@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> writes (&quot;=
[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resum=
e&quot;):<br>
<div class=3D"im">&gt; libxl: support suspend_cancel in domain_resume<br>
<br>
</div>I get this:<br>
<br>
libxl.c: In function &#39;libxl_domain_resume&#39;:<br>
libxl.c:315: error: implicit declaration of function &#39;libxl__domain_res=
ume_device_model&#39;<br>
<br>
Did you compile this ? =A0Did you test it ?<br>
<br></blockquote><div><br>Yes I did.. Did you apply the previous patch in t=
his series, that introduces the above (missing)=A0 function ?<br><br>As I m=
entioned in the introductory email, these patches also depend on Stefano&#3=
9;s XC_SAVE_ID_TOOLSTACK patches.<br>

<br>01 Introduce a new save_id to save/restore toolstack specific extra<br>=
02 Read Qemu&#39;s physmap from xenstore and save it using toolstack_save.<=
br>
03 Following the recent changes to upstream Qemu, the best monitor command<=
br>=A0=A0=A0
(removes qmp_migrate and introduces qmp_save)<br><br><br>Then my patches:<b=
r>03 libxl: QMP stop/resume &amp; refactor QEMU suspend/resume/save<br>04 l=
ibxl: support suspend_cancel in domain_resume<br>05 libxl: refactor migrate=
_domain and generalize migrate_receive<br>

06 libxl: resume instead of unpause on xl save -c<br><br>01 libxl: Remus - =
suspend/postflush/commit callbacks<br>02 libxl: Remus - xl remus command<br=
><br>Currently, one of stefano&#39;s patches doesnt apply cleanly - the fir=
st one. It requires minor fix.<br>

Barring that, all the other patches mentioned above apply cleanly.<br><br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>

--0015175cbae62aff4e04b96acae8--


--===============6565779234677905531==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============6565779234677905531==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 20:07:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZWB-0006A9-T6; Mon, 20 Feb 2012 20:07:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RzZWA-00069p-RV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:07:27 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329768436!12021529!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11912 invoked from network); 20 Feb 2012 20:07:18 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2012 20:07:18 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1KK7Dmf015505
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 12:07:14 -0800
Received: by bkcjg15 with SMTP id jg15so9921231bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 12:07:12 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.148.90 as permitted sender) client-ip=10.204.148.90; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.148.90 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.148.90])
	by 10.204.148.90 with SMTP id o26mr8552736bkv.121.1329768432407
	(num_hops = 1); Mon, 20 Feb 2012 12:07:12 -0800 (PST)
Received: by 10.204.148.90 with SMTP id o26mr6868254bkv.121.1329768432327;
	Mon, 20 Feb 2012 12:07:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 20 Feb 2012 12:06:32 -0800 (PST)
In-Reply-To: <20290.39231.779843.969618@mariner.uk.xensource.com>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
	<20290.39231.779843.969618@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 20 Feb 2012 12:06:32 -0800
Message-ID: <CAP8mzPN+6ftUEi4sBxznR+Yyho-+tmqwSYJ4CJDZc36V=Ukx=g@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7620619932883039796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7620619932883039796==
Content-Type: multipart/alternative; boundary=0015175cabb20ade4604b96ad7e4

--0015175cabb20ade4604b96ad7e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 20, 2012 at 11:04 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wr=
ote:

> rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 0 of 2 V4] libxl - Remus
> support"):
> > This patch series introduces a basic framework to incorporate
> > Remus into the libxl toolstack. The only functionality currently
> > implemented is memory checkpointing.
>
> Thanks.  I'm afraid this doesn't apply to current tip:
>
>
And it wont :), as these patches are not independent.
As I mentioned in the introductory email,

'These patches depend on
 1. "V3 libxl: refactor suspend/resume code" patch series (patches
1,2,3,5,6)
    (note: patches 1 & 2 have already been committed and others have been
     acked by Ian Campbell)

 2. V4 of "libxl: support suspend_cancel in domain_resume"
  (message id: 47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca)

 3. Stefano's "V4 libxl: save/resto=E2=80=8Bre qemu physmap"
 '

patching file tools/libxl/xl_cmdimpl.c
> Hunk #1 FAILED at 2878
> Hunk #5 FAILED at 3102
> 2 out of 6 hunks FAILED -- saving rejects to file
> tools/libxl/xl_cmdimpl.c.rej
>
> While you're refreshing it, could you rewrap the lines in xl.pod.1 to
> be within 75-80 columns ?
>
>
Certainly, if it comes to resending the patches.

thanks
shriram

Thanks,
> Ian.
>
>

--0015175cabb20ade4604b96ad7e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 20, 2012 at 11:04 AM, Ian Jackson <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu.citrix.com">Ian.Jackso=
n@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> writes (&quot;=
[Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support&quot;):<br>
<div class=3D"im">&gt; This patch series introduces a basic framework to in=
corporate<br>
&gt; Remus into the libxl toolstack. The only functionality currently<br>
&gt; implemented is memory checkpointing.<br>
<br>
</div>Thanks. =C2=A0I&#39;m afraid this doesn&#39;t apply to current tip:<b=
r>
<br></blockquote><div><br>And it wont :), as these patches are not independ=
ent.<br>As I mentioned in the introductory email,<br><br>&#39;These patches=
 depend on<br>
=C2=A01. &quot;V3 libxl: refactor suspend/resume code&quot; patch series (p=
atches 1,2,3,5,6)<br>
 =C2=A0 =C2=A0 (note: patches 1 &amp; 2 have already been committed and oth=
ers have been<br>
 =C2=A0 =C2=A0 =C2=A0acked by Ian Campbell)<br>
<br>
=C2=A02. V4 of &quot;libxl: support suspend_cancel in domain_resume&quot;<b=
r>
 =C2=A0 (message id: <a href=3D"mailto:47366457a52076b78c52.1328837508@atho=
s.nss.cs.ubc.ca">47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca</a>)<b=
r><div id=3D":11u">
<br>
=C2=A03. Stefano&#39;s &quot;V4 libxl: save/resto=E2=80=8Bre qemu physmap&q=
uot;<br>
</div>=C2=A0&#39;<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
patching file tools/libxl/xl_cmdimpl.c<br>
Hunk #1 FAILED at 2878<br>
Hunk #5 FAILED at 3102<br>
2 out of 6 hunks FAILED -- saving rejects to file tools/libxl/xl_cmdimpl.c.=
rej<br>
<br>
While you&#39;re refreshing it, could you rewrap the lines in xl.pod.1 to<b=
r>
be within 75-80 columns ?<br>
<br></blockquote><div><br>Certainly, if it comes to resending the patches.<=
br><br>thanks<br>shriram<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">


Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>

--0015175cabb20ade4604b96ad7e4--


--===============7620619932883039796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============7620619932883039796==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 20:07:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZWB-0006A9-T6; Mon, 20 Feb 2012 20:07:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RzZWA-00069p-RV
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:07:27 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329768436!12021529!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11912 invoked from network); 20 Feb 2012 20:07:18 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2012 20:07:18 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1KK7Dmf015505
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 20 Feb 2012 12:07:14 -0800
Received: by bkcjg15 with SMTP id jg15so9921231bkc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 12:07:12 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.148.90 as permitted sender) client-ip=10.204.148.90; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.148.90 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.148.90])
	by 10.204.148.90 with SMTP id o26mr8552736bkv.121.1329768432407
	(num_hops = 1); Mon, 20 Feb 2012 12:07:12 -0800 (PST)
Received: by 10.204.148.90 with SMTP id o26mr6868254bkv.121.1329768432327;
	Mon, 20 Feb 2012 12:07:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 20 Feb 2012 12:06:32 -0800 (PST)
In-Reply-To: <20290.39231.779843.969618@mariner.uk.xensource.com>
References: <patchbomb.1328839080@athos.nss.cs.ubc.ca>
	<20290.39231.779843.969618@mariner.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 20 Feb 2012 12:06:32 -0800
Message-ID: <CAP8mzPN+6ftUEi4sBxznR+Yyho-+tmqwSYJ4CJDZc36V=Ukx=g@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: brendan@cs.ubc.ca, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7620619932883039796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7620619932883039796==
Content-Type: multipart/alternative; boundary=0015175cabb20ade4604b96ad7e4

--0015175cabb20ade4604b96ad7e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 20, 2012 at 11:04 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wr=
ote:

> rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 0 of 2 V4] libxl - Remus
> support"):
> > This patch series introduces a basic framework to incorporate
> > Remus into the libxl toolstack. The only functionality currently
> > implemented is memory checkpointing.
>
> Thanks.  I'm afraid this doesn't apply to current tip:
>
>
And it wont :), as these patches are not independent.
As I mentioned in the introductory email,

'These patches depend on
 1. "V3 libxl: refactor suspend/resume code" patch series (patches
1,2,3,5,6)
    (note: patches 1 & 2 have already been committed and others have been
     acked by Ian Campbell)

 2. V4 of "libxl: support suspend_cancel in domain_resume"
  (message id: 47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca)

 3. Stefano's "V4 libxl: save/resto=E2=80=8Bre qemu physmap"
 '

patching file tools/libxl/xl_cmdimpl.c
> Hunk #1 FAILED at 2878
> Hunk #5 FAILED at 3102
> 2 out of 6 hunks FAILED -- saving rejects to file
> tools/libxl/xl_cmdimpl.c.rej
>
> While you're refreshing it, could you rewrap the lines in xl.pod.1 to
> be within 75-80 columns ?
>
>
Certainly, if it comes to resending the patches.

thanks
shriram

Thanks,
> Ian.
>
>

--0015175cabb20ade4604b96ad7e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 20, 2012 at 11:04 AM, Ian Jackson <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu.citrix.com">Ian.Jackso=
n@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> writes (&quot;=
[Xen-devel] [PATCH 0 of 2 V4] libxl - Remus support&quot;):<br>
<div class=3D"im">&gt; This patch series introduces a basic framework to in=
corporate<br>
&gt; Remus into the libxl toolstack. The only functionality currently<br>
&gt; implemented is memory checkpointing.<br>
<br>
</div>Thanks. =C2=A0I&#39;m afraid this doesn&#39;t apply to current tip:<b=
r>
<br></blockquote><div><br>And it wont :), as these patches are not independ=
ent.<br>As I mentioned in the introductory email,<br><br>&#39;These patches=
 depend on<br>
=C2=A01. &quot;V3 libxl: refactor suspend/resume code&quot; patch series (p=
atches 1,2,3,5,6)<br>
 =C2=A0 =C2=A0 (note: patches 1 &amp; 2 have already been committed and oth=
ers have been<br>
 =C2=A0 =C2=A0 =C2=A0acked by Ian Campbell)<br>
<br>
=C2=A02. V4 of &quot;libxl: support suspend_cancel in domain_resume&quot;<b=
r>
 =C2=A0 (message id: <a href=3D"mailto:47366457a52076b78c52.1328837508@atho=
s.nss.cs.ubc.ca">47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca</a>)<b=
r><div id=3D":11u">
<br>
=C2=A03. Stefano&#39;s &quot;V4 libxl: save/resto=E2=80=8Bre qemu physmap&q=
uot;<br>
</div>=C2=A0&#39;<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
patching file tools/libxl/xl_cmdimpl.c<br>
Hunk #1 FAILED at 2878<br>
Hunk #5 FAILED at 3102<br>
2 out of 6 hunks FAILED -- saving rejects to file tools/libxl/xl_cmdimpl.c.=
rej<br>
<br>
While you&#39;re refreshing it, could you rewrap the lines in xl.pod.1 to<b=
r>
be within 75-80 columns ?<br>
<br></blockquote><div><br>Certainly, if it comes to resending the patches.<=
br><br>thanks<br>shriram<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">


Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>

--0015175cabb20ade4604b96ad7e4--


--===============7620619932883039796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============7620619932883039796==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 20:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:27:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZpg-0006ZC-QE; Mon, 20 Feb 2012 20:27:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RzZpf-0006Z7-MN
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:27:35 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329769648!15592224!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4729 invoked from network); 20 Feb 2012 20:27:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	20 Feb 2012 20:27:29 -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 q1KKROdR025675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:27:24 -0500
Received: from redhat.com (vpn-200-14.tlv.redhat.com [10.35.200.14])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1KKRKDf003413; Mon, 20 Feb 2012 15:27:21 -0500
Date: Mon, 20 Feb 2012 22:27:28 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120220202728.GC18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-3-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 02/11] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:36PM +0000, Anthony PERARD wrote:
> Value check in PCI Express Base Specification rev 1.1
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks, applied.

> ---
>  hw/pci_regs.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/pci_regs.h b/hw/pci_regs.h
> index e8357c3..6b42515 100644
> --- a/hw/pci_regs.h
> +++ b/hw/pci_regs.h
> @@ -393,7 +393,7 @@
>  #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
>  #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
>  #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
> -#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
> +#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
>  #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
>  #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
>  #define PCI_EXP_DEVCAP		4	/* Device capabilities */
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:27:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:27:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZpg-0006ZC-QE; Mon, 20 Feb 2012 20:27:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RzZpf-0006Z7-MN
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:27:35 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329769648!15592224!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4729 invoked from network); 20 Feb 2012 20:27:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	20 Feb 2012 20:27:29 -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 q1KKROdR025675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:27:24 -0500
Received: from redhat.com (vpn-200-14.tlv.redhat.com [10.35.200.14])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1KKRKDf003413; Mon, 20 Feb 2012 15:27:21 -0500
Date: Mon, 20 Feb 2012 22:27:28 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120220202728.GC18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-3-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 02/11] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:36PM +0000, Anthony PERARD wrote:
> Value check in PCI Express Base Specification rev 1.1
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks, applied.

> ---
>  hw/pci_regs.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/pci_regs.h b/hw/pci_regs.h
> index e8357c3..6b42515 100644
> --- a/hw/pci_regs.h
> +++ b/hw/pci_regs.h
> @@ -393,7 +393,7 @@
>  #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
>  #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
>  #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
> -#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
> +#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
>  #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
>  #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
>  #define PCI_EXP_DEVCAP		4	/* Device capabilities */
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1RzZsm-0006f0-E0; Mon, 20 Feb 2012 20:30:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RzZsk-0006es-6e
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:30:46 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329769715!62108738!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30372 invoked from network); 20 Feb 2012 20:28:35 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 20:28:35 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1KKUfUA026769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:30:41 -0500
Received: from redhat.com (vpn-200-14.tlv.redhat.com [10.35.200.14])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1KKUcku011581; Mon, 20 Feb 2012 15:30:39 -0500
Date: Mon, 20 Feb 2012 22:30:46 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120220203046.GD18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 03/11] pci_regs: Add
	PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:37PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/pci_regs.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_regs.h b/hw/pci_regs.h
> index 6b42515..56a404b 100644
> --- a/hw/pci_regs.h
> +++ b/hw/pci_regs.h
> @@ -392,6 +392,7 @@
>  #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
>  #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
>  #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
> +#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */

I don't know why but linux source lacks this value, and we
try to stay in sync with that.
Please push there then we'll add here.
Meanwhile  put a define in your code.

>  #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
>  #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
>  #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1RzZsm-0006f0-E0; Mon, 20 Feb 2012 20:30:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RzZsk-0006es-6e
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:30:46 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329769715!62108738!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30372 invoked from network); 20 Feb 2012 20:28:35 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 20:28:35 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1KKUfUA026769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:30:41 -0500
Received: from redhat.com (vpn-200-14.tlv.redhat.com [10.35.200.14])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q1KKUcku011581; Mon, 20 Feb 2012 15:30:39 -0500
Date: Mon, 20 Feb 2012 22:30:46 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120220203046.GD18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 03/11] pci_regs: Add
	PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:37PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/pci_regs.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_regs.h b/hw/pci_regs.h
> index 6b42515..56a404b 100644
> --- a/hw/pci_regs.h
> +++ b/hw/pci_regs.h
> @@ -392,6 +392,7 @@
>  #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
>  #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
>  #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
> +#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */

I don't know why but linux source lacks this value, and we
try to stay in sync with that.
Please push there then we'll add here.
Meanwhile  put a define in your code.

>  #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
>  #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
>  #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:36:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZxe-0006rO-8h; Mon, 20 Feb 2012 20:35:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RzZxc-0006r8-Ja
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:35:49 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329770141!14153402!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25017 invoked from network); 20 Feb 2012 20:35:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	20 Feb 2012 20:35:41 -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 q1KKZbZB006528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:35:37 -0500
Received: from redhat.com (vpn-200-14.tlv.redhat.com [10.35.200.14])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q1KKZVYb027647; Mon, 20 Feb 2012 15:35:32 -0500
Date: Mon, 20 Feb 2012 22:35:39 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120220203538.GE18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
 PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:42PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

A lot of functionality seems to be duplicated with
kvm's device assignment code.
Makes sense to try separating generic bits so that code
can be shared?

> ---
>  hw/xen_pci_passthrough.c             |   10 +
>  hw/xen_pci_passthrough.h             |    2 +
>  hw/xen_pci_passthrough_config_init.c | 1431 ++++++++++++++++++++++++++++++++++
>  3 files changed, 1443 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 3f305dd..26a3bdd 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
>      /* Handle real device's MMIO/PIO BARs */
>      pt_register_regions(s);
>  
> +    /* reinitialize each config register to be emulated */
> +    if (pt_config_init(s)) {
> +        PT_ERR(d, "PCI Config space initialisation failed.\n");
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
>      /* Bind interrupt */
>      if (!s->dev.config[PCI_INTERRUPT_PIN]) {
>          PT_LOG(d, "no pin interrupt\n");
> @@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
>          }
>      }
>  
> +    /* delete all emulated config registers */
> +    pt_config_delete(s);
> +
>      /* unregister real device's MMIO/PIO BARs */
>      pt_unregister_regions(s);
>  
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index ea6719c..7ebc793 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -61,6 +61,8 @@ typedef int (*conf_byte_read)
>  #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
>  #define PT_PCI_BAR_UNMAPPED (-1)
>  
> +#define PCI_CAP_MAX 48
> +
>  
>  typedef enum {
>      GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index 1e9de64..f1fffd1 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1,11 +1,1442 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include "qemu-timer.h"
> +#include "xen_backend.h"
>  #include "xen_pci_passthrough.h"
>  
> +#define PT_MERGE_VALUE(value, data, val_mask) \
> +    (((value) & (val_mask)) | ((data) & ~(val_mask)))
> +
> +#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
> +
> +/* prototype */
> +
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data);
> +
> +
> +/* helper */
> +
> +/* A return value of 1 means the capability should NOT be exposed to guest. */
> +static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
> +{
> +    switch (grp_id) {
> +    case PCI_CAP_ID_EXP:
> +        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0. We should not try to expose it to guest.
> +         *
> +         * The datasheet is available at
> +         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
> +         *
> +         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
> +         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0, so the Capability Version is 0 and
> +         * pt_pcie_size_init() would fail.
> +         */
> +        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
> +            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
> +            return 1;
> +        }
> +        break;
> +    }
> +    return 0;
> +}
> +
> +/*   find emulate register group entry */
>  XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
>  {
> +    XenPTRegGroup *entry = NULL;
> +
> +    /* find register group entry */
> +    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
> +        /* check address */
> +        if ((entry->base_offset <= address)
> +            && ((entry->base_offset + entry->size) > address)) {
> +            return entry;
> +        }
> +    }
> +
> +    /* group entry not found */
>      return NULL;
>  }
>  
> +/* find emulate register entry */
>  XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
>  {
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +
> +    /* find register entry */
> +    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
> +        reg = reg_entry->reg;
> +        real_offset = reg_grp->base_offset + reg->offset;
> +        /* check address */
> +        if ((real_offset <= address)
> +            && ((real_offset + reg->size) > address)) {
> +            return reg_entry;
> +        }
> +    }
> +
>      return NULL;
>  }
> +
> +/* parse BAR */
> +static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTRegion *region = NULL;
> +    PCIIORegion *r;
> +    int index = 0;
> +
> +    /* check 64bit BAR */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if ((0 < index) && (index < PCI_ROM_SLOT)) {
> +        int flags = s->real_device->io_regions[index - 1].flags;
> +
> +        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
> +            region = &s->bases[index - 1];
> +            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
> +                return PT_BAR_FLAG_UPPER;
> +            }
> +        }
> +    }
> +
> +    /* check unused BAR */
> +    r = &d->io_regions[index];
> +    if (r->size == 0) {
> +        return PT_BAR_FLAG_UNUSED;
> +    }
> +
> +    /* for ExpROM BAR */
> +    if (index == PCI_ROM_SLOT) {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +
> +    /* check BAR I/O indicator */
> +    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
> +        return PT_BAR_FLAG_IO;
> +    } else {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +}
> +
> +
> +/****************
> + * general register functions
> + */
> +
> +/* register initialization function */
> +
> +static int pt_common_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = reg->init_val;
> +    return 0;
> +}
> +
> +/* Read register functions */
> +
> +static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint8_t *value, uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t valid_emu_mask = 0;
> +
> +    /* emulate byte register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +
> +    /* emulate word register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +
> +    /* emulate long register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +
> +/* Write register functions */
> +
> +static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint8_t *value, uint8_t dev_value,
> +                             uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t writable_mask = 0;
> +    uint8_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t dev_value,
> +                             uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint32_t *value, uint32_t dev_value,
> +                             uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/********************
> + * Header Type0
> + */
> +
> +static int pt_vendor_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->vendor_id;
> +    return 0;
> +}
> +static int pt_device_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->device_id;
> +    return 0;
> +}
> +static int pt_status_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t reg_field = 0;
> +
> +    /* find Header register group */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
> +    if (reg_grp_entry) {
> +        /* find Capabilities Pointer register */
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
> +        if (reg_entry) {
> +            /* check Capabilities Pointer register */
> +            if (reg_entry->data) {
> +                reg_field |= PCI_STATUS_CAP_LIST;
> +            } else {
> +                reg_field &= ~PCI_STATUS_CAP_LIST;
> +            }
> +        } else {
> +            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
> +                                     " for Capabilities Pointer register."
> +                                     " (%s)\n", __func__);
> +            return -1;
> +        }
> +    } else {
> +        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
> +                                 " for Header. (%s)\n", __func__);
> +        return -1;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_header_type_reg_init(XenPCIPassthroughState *s,
> +                                   XenPTRegInfo *reg, uint32_t real_offset,
> +                                   uint32_t *data)
> +{
> +    /* read PCI_HEADER_TYPE */
> +    *data = reg->init_val | 0x80;
> +    return 0;
> +}
> +
> +/* initialize Interrupt Pin register */
> +static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = pci_read_intx(s);
> +    return 0;
> +}
> +
> +/* Command register */
> +static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* emulate word register */
> +    valid_emu_mask = emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t dev_value,
> +                            uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t wr_value = *value;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +
> +    if (*value & PCI_COMMAND_INTX_DISABLE) {
> +        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        if (s->machine_irq) {
> +            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +        }
> +    }
> +
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
> +                   wr_value & PCI_COMMAND_MEMORY);
> +
> +    return 0;
> +}
> +
> +/* BAR */
> +#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
> +#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
> +#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
> +#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
> +
> +static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
> +{
> +    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
> +    } else {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
> +    }
> +}
> +
> +static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    int index;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
> +
> +    /* set BAR flag */
> +    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
> +        reg_field = PT_INVALID_REG;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use fixed-up value from kernel sysfs */
> +    *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* emulate BAR */
> +    valid_emu_mask = bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t dev_value,
> +                            uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = &s->dev;
> +    const PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +    uint32_t r_size = 0;
> +    int index = 0;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    r = &d->io_regions[index];
> +    base = &s->bases[index];
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    /* set emulate mask and read-only mask values depend on the BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* check whether we need to update the virtual region address or not */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        if (cfg_entry->data) {
> +            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
> +                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
> +                        "Ignore mapping. "
> +                        "(offset: 0x%02x, high address: 0x%08x)\n",
> +                        reg->offset, cfg_entry->data);
> +            }
> +        }
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* write Exp ROM BAR */
> +static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
> +                                    XenPTReg *cfg_entry, uint32_t *value,
> +                                    uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = (PCIDevice *)&s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    pcibus_t r_size = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +
> +    r = &d->io_regions[PCI_ROM_SLOT];
> +    r_size = r->size;
> +    base = &s->bases[PCI_ROM_SLOT];
> +    /* align memory type resource size */
> +    pt_get_emul_size(base->bar_flag, r_size);
> +
> +    /* set emulate mask and read-only mask */
> +    bar_emu_mask = reg->emu_mask;
> +    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
> +
> +    /* modify emulate register */
> +    writable_mask = ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR*/
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, PCI_ROM_SLOT,
> +                               reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* Header Type0 reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_VENDOR_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_vendor_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device ID reg */
> +    {
> +        .offset     = PCI_DEVICE_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_device_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Command reg */
> +    {
> +        .offset     = PCI_COMMAND,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xF880,
> +        .emu_mask   = 0x0740,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_cmd_reg_read,
> +        .u.w.write  = pt_cmd_reg_write,
> +    },
> +    /* Capabilities Pointer reg */
> +    {
> +        .offset     = PCI_CAPABILITY_LIST,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Status reg */
> +    /* use emulated Cap Ptr value to initialize,
> +     * so need to be declared after Cap Ptr reg
> +     */
> +    {
> +        .offset     = PCI_STATUS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x06FF,
> +        .emu_mask   = 0x0010,
> +        .init       = pt_status_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Cache Line Size reg */
> +    {
> +        .offset     = PCI_CACHE_LINE_SIZE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Latency Timer reg */
> +    {
> +        .offset     = PCI_LATENCY_TIMER,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Header Type reg */
> +    {
> +        .offset     = PCI_HEADER_TYPE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0x00,
> +        .init       = pt_header_type_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Line reg */
> +    {
> +        .offset     = PCI_INTERRUPT_LINE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Pin reg */
> +    {
> +        .offset     = PCI_INTERRUPT_PIN,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_irqpin_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* BAR 0 reg */
> +    /* mask of BAR need to be decided later, depends on IO/MEM type */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_0,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 1 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_1,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 2 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_2,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 3 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_3,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 4 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_4,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 5 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_5,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* Expansion ROM BAR reg */
> +    {
> +        .offset     = PCI_ROM_ADDRESS,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x000007FE,
> +        .emu_mask   = 0xFFFFF800,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_exp_rom_bar_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Vital Product Data Capability
> + */
> +
> +/* Vital Product Data Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * Vendor Specific Capability
> + */
> +
> +/* Vendor Specific Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*****************************
> + * PCI Express Capability
> + */
> +
> +static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
> +                                             uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return flags & PCI_EXP_FLAGS_VERS;
> +}
> +
> +static inline uint8_t get_device_type(XenPCIPassthroughState *s,
> +                                      uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
> +}
> +
> +/* initialize Link Control register */
> +static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of Root Complex Integrated Endpoint
> +     * with cap_ver 1.x
> +     */
> +    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Device Control 2 register */
> +static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Link Control 2 register */
> +static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint32_t reg_field = 0;
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        reg_field = PT_INVALID_REG;
> +    } else {
> +        /* set Supported Link Speed */
> +        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                                      + PCI_EXP_LNKCAP);
> +        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +/* PCI Express Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Device Capabilities reg */
> +    {
> +        .offset     = PCI_EXP_DEVCAP,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x1FFCFFFF,
> +        .emu_mask   = 0x10000000,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_long_reg_write,
> +    },
> +    /* Device Control reg */
> +    {
> +        .offset     = PCI_EXP_DEVCTL,
> +        .size       = 2,
> +        .init_val   = 0x2810,
> +        .ro_mask    = 0x8400,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control reg */
> +    {
> +        .offset     = PCI_EXP_LNKCTL,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFC34,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device Control 2 reg */
> +    {
> +        .offset     = 0x28,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFE0,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_devctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control 2 reg */
> +    {
> +        .offset     = 0x30,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xE040,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Power Management Capability
> + */
> +
> +/* read Power Management Control/Status register */
> +static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = reg->emu_mask;
> +
> +    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    valid_emu_mask = valid_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +/* write Power Management Control/Status register */
> +static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint16_t *value, uint16_t dev_value,
> +                              uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t emu_mask = reg->emu_mask;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    /* modify emulate register */
> +    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +/* Power Management Capability reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Power Management Capabilities reg */
> +    {
> +        .offset     = PCI_CAP_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xF9C8,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* PCI Power Management Control/Status reg */
> +    {
> +        .offset     = PCI_PM_CTRL,
> +        .size       = 2,
> +        .init_val   = 0x0008,
> +        .ro_mask    = 0xE1FC,
> +        .emu_mask   = 0x8100,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_pmcsr_reg_read,
> +        .u.w.write  = pt_pmcsr_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/****************************
> + * Capabilities
> + */
> +
> +/* capability structure register group size functions */
> +
> +static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
> +                                const XenPTRegGroupInfo *grp_reg,
> +                                uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +/* get Vendor Specific Capability Structure register group size */
> +static int pt_vendor_size_init(XenPCIPassthroughState *s,
> +                               const XenPTRegGroupInfo *grp_reg,
> +                               uint32_t base_offset, uint8_t *size)
> +{
> +    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
> +    return 0;
> +}
> +/* get PCI Express Capability Structure register group size */
> +static int pt_pcie_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t version = get_capability_version(s, base_offset);
> +    uint8_t type = get_device_type(s, base_offset);
> +    uint8_t pcie_size = 0;
> +
> +
> +    /* calculate size depend on capability version and device/port type */
> +    /* in case of PCI Express Base Specification Rev 1.x */
> +    if (version == 1) {
> +        /* The PCI Express Capabilities, Device Capabilities, and Device
> +         * Status/Control registers are required for all PCI Express devices.
> +         * The Link Capabilities and Link Status/Control are required for all
> +         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
> +         * are not required to implement registers other than those listed
> +         * above and terminate the capability structure.
> +         */
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +            pcie_size = 0x14;
> +            break;
> +        case PCI_EXP_TYPE_RC_END:
> +            /* has no link */
> +            pcie_size = 0x0C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    }
> +    /* in case of PCI Express Base Specification Rev 2.0 */
> +    else if (version == 2) {
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +        case PCI_EXP_TYPE_RC_END:
> +            /* For Functions that do not implement the registers,
> +             * these spaces must be hardwired to 0b.
> +             */
> +            pcie_size = 0x3C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    } else {
> +        PT_ERR(d, "Unsupported capability version %#x.\n", version);
> +        return -1;
> +    }
> +
> +    *size = pcie_size;
> +    return 0;
> +}
> +
> +static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
> +    /* Header Type0 reg group */
> +    {
> +        .grp_id      = 0xFF,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x40,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_header0_tbl,
> +    },
> +    /* PCI PowerManagement Capability reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_PM,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = PCI_PM_SIZEOF,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pm_tbl,
> +    },
> +    /* AGP Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vital Product Data Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VPD,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x08,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
> +    },
> +    /* Slot Identification reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SLOTID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x04,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI-X Capabilities List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_PCIX,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x18,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vendor Specific Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VNDR,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_vendor_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
> +    },
> +    /* SHPC Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SHPC,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SSVID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* AGP 8x Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP3,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI Express Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_EXP,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_pcie_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
> +    },
> +    {
> +        .grp_size = 0,
> +    },
> +};
> +
> +/* initialize Capabilities Pointer or Next Pointer register */
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    int i;
> +    uint8_t *config = s->dev.config;
> +    uint32_t reg_field = pci_get_byte(config + real_offset);
> +    uint8_t cap_id = 0;
> +
> +    /* find capability offset */
> +    while (reg_field) {
> +        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
> +            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
> +                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +                    goto out;
> +                }
> +                /* ignore the 0 hardwired capability, find next one */
> +                break;
> +            }
> +        }
> +
> +        /* next capability */
> +        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
> +    }
> +
> +out:
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +
> +/*************
> + * Main
> + */
> +
> +static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
> +{
> +    uint8_t id;
> +    unsigned max_cap = PCI_CAP_MAX;
> +    uint8_t pos = PCI_CAPABILITY_LIST;
> +    uint8_t status = 0;
> +
> +    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
> +        return 0;
> +    }
> +    if ((status & PCI_STATUS_CAP_LIST) == 0) {
> +        return 0;
> +    }
> +
> +    while (max_cap--) {
> +        if (host_pci_get_byte(s->real_device, pos, &pos)) {
> +            break;
> +        }
> +        if (pos < PCI_CONFIG_HEADER_SIZE) {
> +            break;
> +        }
> +
> +        pos &= ~3;
> +        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
> +            break;
> +        }
> +
> +        if (id == 0xff) {
> +            break;
> +        }
> +        if (id == cap) {
> +            return pos;
> +        }
> +
> +        pos += PCI_CAP_LIST_NEXT;
> +    }
> +    return 0;
> +}
> +
> +static int pt_config_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
> +{
> +    XenPTReg *reg_entry;
> +    uint32_t data = 0;
> +    int rc = 0;
> +
> +    reg_entry = g_new0(XenPTReg, 1);
> +    reg_entry->reg = reg;
> +
> +    if (reg->init) {
> +        /* initialize emulate register */
> +        rc = reg->init(s, reg_entry->reg,
> +                       reg_grp->base_offset + reg->offset, &data);
> +        if (rc < 0) {
> +            free(reg_entry);
> +            return rc;
> +        }
> +        if (data == PT_INVALID_REG) {
> +            /* free unused BAR register entry */
> +            free(reg_entry);
> +            return 0;
> +        }
> +        /* set register value */
> +        reg_entry->data = data;
> +    }
> +    /* list add register entry */
> +    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
> +
> +    return 0;
> +}
> +
> +int pt_config_init(XenPCIPassthroughState *s)
> +{
> +    int i, rc;
> +
> +    QLIST_INIT(&s->reg_grp_tbl);
> +
> +    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +        uint32_t reg_grp_offset = 0;
> +        XenPTRegGroup *reg_grp_entry = NULL;
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
> +
> +            if (!reg_grp_offset) {
> +                continue;
> +            }
> +        }
> +
> +        reg_grp_entry = g_new0(XenPTRegGroup, 1);
> +        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
> +        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
> +
> +        reg_grp_entry->base_offset = reg_grp_offset;
> +        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
> +        if (pt_emu_reg_grp_tbl[i].size_init) {
> +            /* get register group size */
> +            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
> +                                                 reg_grp_offset,
> +                                                 &reg_grp_entry->size);
> +            if (rc < 0) {
> +                pt_config_delete(s);
> +                return rc;
> +            }
> +        }
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
> +                int j = 0;
> +                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
> +                /* initialize capability register */
> +                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
> +                    /* initialize capability register */
> +                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
> +                    if (rc < 0) {
> +                        pt_config_delete(s);
> +                        return rc;
> +                    }
> +                }
> +            }
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* delete all emulate register */
> +void pt_config_delete(XenPCIPassthroughState *s)
> +{
> +    struct XenPTRegGroup *reg_group, *next_grp;
> +    struct XenPTReg *reg, *next_reg;
> +
> +    /* free all register group entry */
> +    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
> +        /* free all register entry */
> +        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
> +            QLIST_REMOVE(reg, entries);
> +            g_free(reg);
> +        }
> +
> +        QLIST_REMOVE(reg_group, entries);
> +        g_free(reg_group);
> +    }
> +}
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:36:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzZxe-0006rO-8h; Mon, 20 Feb 2012 20:35:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1RzZxc-0006r8-Ja
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:35:49 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329770141!14153402!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25017 invoked from network); 20 Feb 2012 20:35:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	20 Feb 2012 20:35:41 -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 q1KKZbZB006528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 20 Feb 2012 15:35:37 -0500
Received: from redhat.com (vpn-200-14.tlv.redhat.com [10.35.200.14])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q1KKZVYb027647; Mon, 20 Feb 2012 15:35:32 -0500
Date: Mon, 20 Feb 2012 22:35:39 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120220203538.GE18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Guy Zana <guy@neocleus.com>, Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
 PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:42PM +0000, Anthony PERARD wrote:
> From: Allen Kay <allen.m.kay@intel.com>
> 
> A more complete history can be found here:
> git://xenbits.xensource.com/qemu-xen-unstable.git
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> Signed-off-by: Guy Zana <guy@neocleus.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

A lot of functionality seems to be duplicated with
kvm's device assignment code.
Makes sense to try separating generic bits so that code
can be shared?

> ---
>  hw/xen_pci_passthrough.c             |   10 +
>  hw/xen_pci_passthrough.h             |    2 +
>  hw/xen_pci_passthrough_config_init.c | 1431 ++++++++++++++++++++++++++++++++++
>  3 files changed, 1443 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 3f305dd..26a3bdd 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -676,6 +676,13 @@ static int pt_initfn(PCIDevice *d)
>      /* Handle real device's MMIO/PIO BARs */
>      pt_register_regions(s);
>  
> +    /* reinitialize each config register to be emulated */
> +    if (pt_config_init(s)) {
> +        PT_ERR(d, "PCI Config space initialisation failed.\n");
> +        host_pci_device_put(s->real_device);
> +        return -1;
> +    }
> +
>      /* Bind interrupt */
>      if (!s->dev.config[PCI_INTERRUPT_PIN]) {
>          PT_LOG(d, "no pin interrupt\n");
> @@ -773,6 +780,9 @@ static int pt_unregister_device(PCIDevice *d)
>          }
>      }
>  
> +    /* delete all emulated config registers */
> +    pt_config_delete(s);
> +
>      /* unregister real device's MMIO/PIO BARs */
>      pt_unregister_regions(s);
>  
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index ea6719c..7ebc793 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -61,6 +61,8 @@ typedef int (*conf_byte_read)
>  #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
>  #define PT_PCI_BAR_UNMAPPED (-1)
>  
> +#define PCI_CAP_MAX 48
> +
>  
>  typedef enum {
>      GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
> diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
> index 1e9de64..f1fffd1 100644
> --- a/hw/xen_pci_passthrough_config_init.c
> +++ b/hw/xen_pci_passthrough_config_init.c
> @@ -1,11 +1,1442 @@
> +/*
> + * Copyright (c) 2007, Neocleus Corporation.
> + * Copyright (c) 2007, Intel Corporation.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Alex Novik <alex@neocleus.com>
> + * Allen Kay <allen.m.kay@intel.com>
> + * Guy Zana <guy@neocleus.com>
> + *
> + * This file implements direct PCI assignment to a HVM guest
> + */
> +
> +#include "qemu-timer.h"
> +#include "xen_backend.h"
>  #include "xen_pci_passthrough.h"
>  
> +#define PT_MERGE_VALUE(value, data, val_mask) \
> +    (((value) & (val_mask)) | ((data) & ~(val_mask)))
> +
> +#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
> +
> +/* prototype */
> +
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data);
> +
> +
> +/* helper */
> +
> +/* A return value of 1 means the capability should NOT be exposed to guest. */
> +static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
> +{
> +    switch (grp_id) {
> +    case PCI_CAP_ID_EXP:
> +        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0. We should not try to expose it to guest.
> +         *
> +         * The datasheet is available at
> +         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
> +         *
> +         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
> +         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
> +         * Controller looks trivial, e.g., the PCI Express Capabilities
> +         * Register is 0, so the Capability Version is 0 and
> +         * pt_pcie_size_init() would fail.
> +         */
> +        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
> +            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
> +            return 1;
> +        }
> +        break;
> +    }
> +    return 0;
> +}
> +
> +/*   find emulate register group entry */
>  XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
>  {
> +    XenPTRegGroup *entry = NULL;
> +
> +    /* find register group entry */
> +    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
> +        /* check address */
> +        if ((entry->base_offset <= address)
> +            && ((entry->base_offset + entry->size) > address)) {
> +            return entry;
> +        }
> +    }
> +
> +    /* group entry not found */
>      return NULL;
>  }
>  
> +/* find emulate register entry */
>  XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
>  {
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegInfo *reg = NULL;
> +    uint32_t real_offset = 0;
> +
> +    /* find register entry */
> +    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
> +        reg = reg_entry->reg;
> +        real_offset = reg_grp->base_offset + reg->offset;
> +        /* check address */
> +        if ((real_offset <= address)
> +            && ((real_offset + reg->size) > address)) {
> +            return reg_entry;
> +        }
> +    }
> +
>      return NULL;
>  }
> +
> +/* parse BAR */
> +static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
> +{
> +    PCIDevice *d = &s->dev;
> +    XenPTRegion *region = NULL;
> +    PCIIORegion *r;
> +    int index = 0;
> +
> +    /* check 64bit BAR */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if ((0 < index) && (index < PCI_ROM_SLOT)) {
> +        int flags = s->real_device->io_regions[index - 1].flags;
> +
> +        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
> +            region = &s->bases[index - 1];
> +            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
> +                return PT_BAR_FLAG_UPPER;
> +            }
> +        }
> +    }
> +
> +    /* check unused BAR */
> +    r = &d->io_regions[index];
> +    if (r->size == 0) {
> +        return PT_BAR_FLAG_UNUSED;
> +    }
> +
> +    /* for ExpROM BAR */
> +    if (index == PCI_ROM_SLOT) {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +
> +    /* check BAR I/O indicator */
> +    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
> +        return PT_BAR_FLAG_IO;
> +    } else {
> +        return PT_BAR_FLAG_MEM;
> +    }
> +}
> +
> +
> +/****************
> + * general register functions
> + */
> +
> +/* register initialization function */
> +
> +static int pt_common_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = reg->init_val;
> +    return 0;
> +}
> +
> +/* Read register functions */
> +
> +static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint8_t *value, uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t valid_emu_mask = 0;
> +
> +    /* emulate byte register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +
> +    /* emulate word register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +
> +    /* emulate long register */
> +    valid_emu_mask = reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +
> +/* Write register functions */
> +
> +static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint8_t *value, uint8_t dev_value,
> +                             uint8_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint8_t writable_mask = 0;
> +    uint8_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t dev_value,
> +                             uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint32_t *value, uint32_t dev_value,
> +                             uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +
> +    /* modify emulate register */
> +    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~reg->emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +
> +/* XenPTRegInfo declaration
> + * - only for emulated register (either a part or whole bit).
> + * - for passthrough register that need special behavior (like interacting with
> + *   other component), set emu_mask to all 0 and specify r/w func properly.
> + * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
> + */
> +
> +/********************
> + * Header Type0
> + */
> +
> +static int pt_vendor_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->vendor_id;
> +    return 0;
> +}
> +static int pt_device_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = s->real_device->device_id;
> +    return 0;
> +}
> +static int pt_status_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    uint32_t reg_field = 0;
> +
> +    /* find Header register group */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
> +    if (reg_grp_entry) {
> +        /* find Capabilities Pointer register */
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
> +        if (reg_entry) {
> +            /* check Capabilities Pointer register */
> +            if (reg_entry->data) {
> +                reg_field |= PCI_STATUS_CAP_LIST;
> +            } else {
> +                reg_field &= ~PCI_STATUS_CAP_LIST;
> +            }
> +        } else {
> +            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
> +                                     " for Capabilities Pointer register."
> +                                     " (%s)\n", __func__);
> +            return -1;
> +        }
> +    } else {
> +        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
> +                                 " for Header. (%s)\n", __func__);
> +        return -1;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_header_type_reg_init(XenPCIPassthroughState *s,
> +                                   XenPTRegInfo *reg, uint32_t real_offset,
> +                                   uint32_t *data)
> +{
> +    /* read PCI_HEADER_TYPE */
> +    *data = reg->init_val | 0x80;
> +    return 0;
> +}
> +
> +/* initialize Interrupt Pin register */
> +static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegInfo *reg, uint32_t real_offset,
> +                              uint32_t *data)
> +{
> +    *data = pci_read_intx(s);
> +    return 0;
> +}
> +
> +/* Command register */
> +static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = 0;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* emulate word register */
> +    valid_emu_mask = emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint16_t *value, uint16_t dev_value,
> +                            uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +    uint16_t wr_value = *value;
> +    uint16_t emu_mask = reg->emu_mask;
> +
> +    if (s->is_virtfn) {
> +        emu_mask |= PCI_COMMAND_MEMORY;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +
> +    if (*value & PCI_COMMAND_INTX_DISABLE) {
> +        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +    } else {
> +        if (s->machine_irq) {
> +            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
> +        }
> +    }
> +
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
> +                   wr_value & PCI_COMMAND_MEMORY);
> +
> +    return 0;
> +}
> +
> +/* BAR */
> +#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
> +#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
> +#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
> +#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
> +
> +static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
> +{
> +    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
> +    } else {
> +        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
> +    }
> +}
> +
> +static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
> +                           uint32_t real_offset, uint32_t *data)
> +{
> +    uint32_t reg_field = 0;
> +    int index;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    s->bases[index].e_physbase = PT_PCI_BAR_UNMAPPED;
> +
> +    /* set BAR flag */
> +    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
> +    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
> +        reg_field = PT_INVALID_REG;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                           uint32_t *value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint32_t valid_emu_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    int index;
> +
> +    /* get BAR index */
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    /* use fixed-up value from kernel sysfs */
> +    *value = base_address_with_flags(&s->real_device->io_regions[index]);
> +
> +    /* set emulate mask depend on BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* emulate BAR */
> +    valid_emu_mask = bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +   return 0;
> +}
> +static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                            uint32_t *value, uint32_t dev_value,
> +                            uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = &s->dev;
> +    const PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +    uint32_t r_size = 0;
> +    int index = 0;
> +
> +    index = pt_bar_offset_to_index(reg->offset);
> +    if (index < 0 || index >= PCI_NUM_REGIONS) {
> +        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
> +        return -1;
> +    }
> +
> +    r = &d->io_regions[index];
> +    base = &s->bases[index];
> +    r_size = pt_get_emul_size(base->bar_flag, r->size);
> +
> +    /* set emulate mask and read-only mask values depend on the BAR flag */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
> +        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        bar_emu_mask = PT_BAR_IO_EMU_MASK;
> +        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        bar_emu_mask = PT_BAR_ALLF;
> +        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* modify emulate register */
> +    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* check whether we need to update the virtual region address or not */
> +    switch (s->bases[index].bar_flag) {
> +    case PT_BAR_FLAG_MEM:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_IO:
> +        /* nothing to do */
> +        break;
> +    case PT_BAR_FLAG_UPPER:
> +        if (cfg_entry->data) {
> +            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
> +                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
> +                        "Ignore mapping. "
> +                        "(offset: 0x%02x, high address: 0x%08x)\n",
> +                        reg->offset, cfg_entry->data);
> +            }
> +        }
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR */
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* write Exp ROM BAR */
> +static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
> +                                    XenPTReg *cfg_entry, uint32_t *value,
> +                                    uint32_t dev_value, uint32_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    XenPTRegGroup *reg_grp_entry = NULL;
> +    XenPTReg *reg_entry = NULL;
> +    XenPTRegion *base = NULL;
> +    PCIDevice *d = (PCIDevice *)&s->dev;
> +    PCIIORegion *r;
> +    uint32_t writable_mask = 0;
> +    uint32_t throughable_mask = 0;
> +    pcibus_t r_size = 0;
> +    uint32_t bar_emu_mask = 0;
> +    uint32_t bar_ro_mask = 0;
> +
> +    r = &d->io_regions[PCI_ROM_SLOT];
> +    r_size = r->size;
> +    base = &s->bases[PCI_ROM_SLOT];
> +    /* align memory type resource size */
> +    pt_get_emul_size(base->bar_flag, r_size);
> +
> +    /* set emulate mask and read-only mask */
> +    bar_emu_mask = reg->emu_mask;
> +    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
> +
> +    /* modify emulate register */
> +    writable_mask = ~bar_ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* update the corresponding virtual region address */
> +    /*
> +     * When guest code tries to get block size of mmio, it will write all "1"s
> +     * into pci bar register. In this case, cfg_entry->data == writable_mask.
> +     * Especially for devices with large mmio, the value of writable_mask
> +     * is likely to be a guest physical address that has been mapped to ram
> +     * rather than mmio. Remapping this value to mmio should be prevented.
> +     */
> +
> +    if (cfg_entry->data != writable_mask) {
> +        r->addr = cfg_entry->data;
> +    }
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~bar_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    /* After BAR reg update, we need to remap BAR*/
> +    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
> +    if (reg_grp_entry) {
> +        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
> +        if (reg_entry) {
> +            pt_bar_mapping_one(s, PCI_ROM_SLOT,
> +                               reg_entry->data & PCI_COMMAND_IO,
> +                               reg_entry->data & PCI_COMMAND_MEMORY);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* Header Type0 reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
> +    /* Vendor ID reg */
> +    {
> +        .offset     = PCI_VENDOR_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_vendor_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device ID reg */
> +    {
> +        .offset     = PCI_DEVICE_ID,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_device_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Command reg */
> +    {
> +        .offset     = PCI_COMMAND,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xF880,
> +        .emu_mask   = 0x0740,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_cmd_reg_read,
> +        .u.w.write  = pt_cmd_reg_write,
> +    },
> +    /* Capabilities Pointer reg */
> +    {
> +        .offset     = PCI_CAPABILITY_LIST,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Status reg */
> +    /* use emulated Cap Ptr value to initialize,
> +     * so need to be declared after Cap Ptr reg
> +     */
> +    {
> +        .offset     = PCI_STATUS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0x06FF,
> +        .emu_mask   = 0x0010,
> +        .init       = pt_status_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Cache Line Size reg */
> +    {
> +        .offset     = PCI_CACHE_LINE_SIZE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Latency Timer reg */
> +    {
> +        .offset     = PCI_LATENCY_TIMER,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Header Type reg */
> +    {
> +        .offset     = PCI_HEADER_TYPE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0x00,
> +        .init       = pt_header_type_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Line reg */
> +    {
> +        .offset     = PCI_INTERRUPT_LINE,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0x00,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_common_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Interrupt Pin reg */
> +    {
> +        .offset     = PCI_INTERRUPT_PIN,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_irqpin_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* BAR 0 reg */
> +    /* mask of BAR need to be decided later, depends on IO/MEM type */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_0,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 1 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_1,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 2 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_2,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 3 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_3,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 4 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_4,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* BAR 5 reg */
> +    {
> +        .offset     = PCI_BASE_ADDRESS_5,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_bar_reg_read,
> +        .u.dw.write = pt_bar_reg_write,
> +    },
> +    /* Expansion ROM BAR reg */
> +    {
> +        .offset     = PCI_ROM_ADDRESS,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x000007FE,
> +        .emu_mask   = 0xFFFFF800,
> +        .init       = pt_bar_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_exp_rom_bar_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Vital Product Data Capability
> + */
> +
> +/* Vital Product Data Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/**************************************
> + * Vendor Specific Capability
> + */
> +
> +/* Vendor Specific Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*****************************
> + * PCI Express Capability
> + */
> +
> +static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
> +                                             uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return flags & PCI_EXP_FLAGS_VERS;
> +}
> +
> +static inline uint8_t get_device_type(XenPCIPassthroughState *s,
> +                                      uint32_t offset)
> +{
> +    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
> +    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
> +}
> +
> +/* initialize Link Control register */
> +static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of Root Complex Integrated Endpoint
> +     * with cap_ver 1.x
> +     */
> +    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Device Control 2 register */
> +static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
> +                                XenPTRegInfo *reg, uint32_t real_offset,
> +                                uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        *data = PT_INVALID_REG;
> +    }
> +
> +    *data = reg->init_val;
> +    return 0;
> +}
> +/* initialize Link Control 2 register */
> +static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
> +                                 XenPTRegInfo *reg, uint32_t real_offset,
> +                                 uint32_t *data)
> +{
> +    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
> +    uint32_t reg_field = 0;
> +
> +    /* no need to initialize in case of cap_ver 1.x */
> +    if (cap_ver == 1) {
> +        reg_field = PT_INVALID_REG;
> +    } else {
> +        /* set Supported Link Speed */
> +        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
> +                                      + PCI_EXP_LNKCAP);
> +        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
> +    }
> +
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +/* PCI Express Capability Structure reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Device Capabilities reg */
> +    {
> +        .offset     = PCI_EXP_DEVCAP,
> +        .size       = 4,
> +        .init_val   = 0x00000000,
> +        .ro_mask    = 0x1FFCFFFF,
> +        .emu_mask   = 0x10000000,
> +        .init       = pt_common_reg_init,
> +        .u.dw.read  = pt_long_reg_read,
> +        .u.dw.write = pt_long_reg_write,
> +    },
> +    /* Device Control reg */
> +    {
> +        .offset     = PCI_EXP_DEVCTL,
> +        .size       = 2,
> +        .init_val   = 0x2810,
> +        .ro_mask    = 0x8400,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control reg */
> +    {
> +        .offset     = PCI_EXP_LNKCTL,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFC34,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Device Control 2 reg */
> +    {
> +        .offset     = 0x28,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFE0,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_devctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* Link Control 2 reg */
> +    {
> +        .offset     = 0x30,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xE040,
> +        .emu_mask   = 0xFFFF,
> +        .init       = pt_linkctrl2_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/*********************************
> + * Power Management Capability
> + */
> +
> +/* read Power Management Control/Status register */
> +static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                             uint16_t *value, uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t valid_emu_mask = reg->emu_mask;
> +
> +    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    valid_emu_mask = valid_emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
> +
> +    return 0;
> +}
> +/* write Power Management Control/Status register */
> +static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> +                              uint16_t *value, uint16_t dev_value,
> +                              uint16_t valid_mask)
> +{
> +    XenPTRegInfo *reg = cfg_entry->reg;
> +    uint16_t emu_mask = reg->emu_mask;
> +    uint16_t writable_mask = 0;
> +    uint16_t throughable_mask = 0;
> +
> +    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
> +
> +    /* modify emulate register */
> +    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
> +    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
> +
> +    /* create value for writing to I/O device register */
> +    throughable_mask = ~emu_mask & valid_mask;
> +    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
> +
> +    return 0;
> +}
> +
> +/* Power Management Capability reg static infomation table */
> +static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
> +    /* Next Pointer reg */
> +    {
> +        .offset     = PCI_CAP_LIST_NEXT,
> +        .size       = 1,
> +        .init_val   = 0x00,
> +        .ro_mask    = 0xFF,
> +        .emu_mask   = 0xFF,
> +        .init       = pt_ptr_reg_init,
> +        .u.b.read   = pt_byte_reg_read,
> +        .u.b.write  = pt_byte_reg_write,
> +    },
> +    /* Power Management Capabilities reg */
> +    {
> +        .offset     = PCI_CAP_FLAGS,
> +        .size       = 2,
> +        .init_val   = 0x0000,
> +        .ro_mask    = 0xFFFF,
> +        .emu_mask   = 0xF9C8,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_word_reg_read,
> +        .u.w.write  = pt_word_reg_write,
> +    },
> +    /* PCI Power Management Control/Status reg */
> +    {
> +        .offset     = PCI_PM_CTRL,
> +        .size       = 2,
> +        .init_val   = 0x0008,
> +        .ro_mask    = 0xE1FC,
> +        .emu_mask   = 0x8100,
> +        .init       = pt_common_reg_init,
> +        .u.w.read   = pt_pmcsr_reg_read,
> +        .u.w.write  = pt_pmcsr_reg_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
> +
> +
> +/****************************
> + * Capabilities
> + */
> +
> +/* capability structure register group size functions */
> +
> +static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
> +                                const XenPTRegGroupInfo *grp_reg,
> +                                uint32_t base_offset, uint8_t *size)
> +{
> +    *size = grp_reg->grp_size;
> +    return 0;
> +}
> +/* get Vendor Specific Capability Structure register group size */
> +static int pt_vendor_size_init(XenPCIPassthroughState *s,
> +                               const XenPTRegGroupInfo *grp_reg,
> +                               uint32_t base_offset, uint8_t *size)
> +{
> +    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
> +    return 0;
> +}
> +/* get PCI Express Capability Structure register group size */
> +static int pt_pcie_size_init(XenPCIPassthroughState *s,
> +                             const XenPTRegGroupInfo *grp_reg,
> +                             uint32_t base_offset, uint8_t *size)
> +{
> +    PCIDevice *d = &s->dev;
> +    uint8_t version = get_capability_version(s, base_offset);
> +    uint8_t type = get_device_type(s, base_offset);
> +    uint8_t pcie_size = 0;
> +
> +
> +    /* calculate size depend on capability version and device/port type */
> +    /* in case of PCI Express Base Specification Rev 1.x */
> +    if (version == 1) {
> +        /* The PCI Express Capabilities, Device Capabilities, and Device
> +         * Status/Control registers are required for all PCI Express devices.
> +         * The Link Capabilities and Link Status/Control are required for all
> +         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
> +         * are not required to implement registers other than those listed
> +         * above and terminate the capability structure.
> +         */
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +            pcie_size = 0x14;
> +            break;
> +        case PCI_EXP_TYPE_RC_END:
> +            /* has no link */
> +            pcie_size = 0x0C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    }
> +    /* in case of PCI Express Base Specification Rev 2.0 */
> +    else if (version == 2) {
> +        switch (type) {
> +        case PCI_EXP_TYPE_ENDPOINT:
> +        case PCI_EXP_TYPE_LEG_END:
> +        case PCI_EXP_TYPE_RC_END:
> +            /* For Functions that do not implement the registers,
> +             * these spaces must be hardwired to 0b.
> +             */
> +            pcie_size = 0x3C;
> +            break;
> +        /* only EndPoint passthrough is supported */
> +        case PCI_EXP_TYPE_ROOT_PORT:
> +        case PCI_EXP_TYPE_UPSTREAM:
> +        case PCI_EXP_TYPE_DOWNSTREAM:
> +        case PCI_EXP_TYPE_PCI_BRIDGE:
> +        case PCI_EXP_TYPE_PCIE_BRIDGE:
> +        case PCI_EXP_TYPE_RC_EC:
> +        default:
> +            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
> +            return -1;
> +        }
> +    } else {
> +        PT_ERR(d, "Unsupported capability version %#x.\n", version);
> +        return -1;
> +    }
> +
> +    *size = pcie_size;
> +    return 0;
> +}
> +
> +static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
> +    /* Header Type0 reg group */
> +    {
> +        .grp_id      = 0xFF,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x40,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_header0_tbl,
> +    },
> +    /* PCI PowerManagement Capability reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_PM,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = PCI_PM_SIZEOF,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pm_tbl,
> +    },
> +    /* AGP Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vital Product Data Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VPD,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0x08,
> +        .size_init   = pt_reg_grp_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
> +    },
> +    /* Slot Identification reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SLOTID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x04,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI-X Capabilities List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_PCIX,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x18,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Vendor Specific Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_VNDR,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_vendor_size_init,
> +        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
> +    },
> +    /* SHPC Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SHPC,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_SSVID,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x08,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* AGP 8x Capability Structure reg group */
> +    {
> +        .grp_id     = PCI_CAP_ID_AGP3,
> +        .grp_type   = GRP_TYPE_HARDWIRED,
> +        .grp_size   = 0x30,
> +        .size_init  = pt_reg_grp_size_init,
> +    },
> +    /* PCI Express Capability Structure reg group */
> +    {
> +        .grp_id      = PCI_CAP_ID_EXP,
> +        .grp_type    = GRP_TYPE_EMU,
> +        .grp_size    = 0xFF,
> +        .size_init   = pt_pcie_size_init,
> +        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
> +    },
> +    {
> +        .grp_size = 0,
> +    },
> +};
> +
> +/* initialize Capabilities Pointer or Next Pointer register */
> +static int pt_ptr_reg_init(XenPCIPassthroughState *s,
> +                           XenPTRegInfo *reg, uint32_t real_offset,
> +                           uint32_t *data)
> +{
> +    int i;
> +    uint8_t *config = s->dev.config;
> +    uint32_t reg_field = pci_get_byte(config + real_offset);
> +    uint8_t cap_id = 0;
> +
> +    /* find capability offset */
> +    while (reg_field) {
> +        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
> +            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
> +                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +                    goto out;
> +                }
> +                /* ignore the 0 hardwired capability, find next one */
> +                break;
> +            }
> +        }
> +
> +        /* next capability */
> +        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
> +    }
> +
> +out:
> +    *data = reg_field;
> +    return 0;
> +}
> +
> +
> +/*************
> + * Main
> + */
> +
> +static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
> +{
> +    uint8_t id;
> +    unsigned max_cap = PCI_CAP_MAX;
> +    uint8_t pos = PCI_CAPABILITY_LIST;
> +    uint8_t status = 0;
> +
> +    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
> +        return 0;
> +    }
> +    if ((status & PCI_STATUS_CAP_LIST) == 0) {
> +        return 0;
> +    }
> +
> +    while (max_cap--) {
> +        if (host_pci_get_byte(s->real_device, pos, &pos)) {
> +            break;
> +        }
> +        if (pos < PCI_CONFIG_HEADER_SIZE) {
> +            break;
> +        }
> +
> +        pos &= ~3;
> +        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
> +            break;
> +        }
> +
> +        if (id == 0xff) {
> +            break;
> +        }
> +        if (id == cap) {
> +            return pos;
> +        }
> +
> +        pos += PCI_CAP_LIST_NEXT;
> +    }
> +    return 0;
> +}
> +
> +static int pt_config_reg_init(XenPCIPassthroughState *s,
> +                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
> +{
> +    XenPTReg *reg_entry;
> +    uint32_t data = 0;
> +    int rc = 0;
> +
> +    reg_entry = g_new0(XenPTReg, 1);
> +    reg_entry->reg = reg;
> +
> +    if (reg->init) {
> +        /* initialize emulate register */
> +        rc = reg->init(s, reg_entry->reg,
> +                       reg_grp->base_offset + reg->offset, &data);
> +        if (rc < 0) {
> +            free(reg_entry);
> +            return rc;
> +        }
> +        if (data == PT_INVALID_REG) {
> +            /* free unused BAR register entry */
> +            free(reg_entry);
> +            return 0;
> +        }
> +        /* set register value */
> +        reg_entry->data = data;
> +    }
> +    /* list add register entry */
> +    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
> +
> +    return 0;
> +}
> +
> +int pt_config_init(XenPCIPassthroughState *s)
> +{
> +    int i, rc;
> +
> +    QLIST_INIT(&s->reg_grp_tbl);
> +
> +    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
> +        uint32_t reg_grp_offset = 0;
> +        XenPTRegGroup *reg_grp_entry = NULL;
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
> +            if (pt_hide_dev_cap(s->real_device,
> +                                pt_emu_reg_grp_tbl[i].grp_id)) {
> +                continue;
> +            }
> +
> +            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
> +
> +            if (!reg_grp_offset) {
> +                continue;
> +            }
> +        }
> +
> +        reg_grp_entry = g_new0(XenPTRegGroup, 1);
> +        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
> +        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
> +
> +        reg_grp_entry->base_offset = reg_grp_offset;
> +        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
> +        if (pt_emu_reg_grp_tbl[i].size_init) {
> +            /* get register group size */
> +            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
> +                                                 reg_grp_offset,
> +                                                 &reg_grp_entry->size);
> +            if (rc < 0) {
> +                pt_config_delete(s);
> +                return rc;
> +            }
> +        }
> +
> +        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
> +            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
> +                int j = 0;
> +                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
> +                /* initialize capability register */
> +                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
> +                    /* initialize capability register */
> +                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
> +                    if (rc < 0) {
> +                        pt_config_delete(s);
> +                        return rc;
> +                    }
> +                }
> +            }
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* delete all emulate register */
> +void pt_config_delete(XenPCIPassthroughState *s)
> +{
> +    struct XenPTRegGroup *reg_group, *next_grp;
> +    struct XenPTReg *reg, *next_reg;
> +
> +    /* free all register group entry */
> +    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
> +        /* free all register entry */
> +        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
> +            QLIST_REMOVE(reg, entries);
> +            g_free(reg);
> +        }
> +
> +        QLIST_REMOVE(reg_group, entries);
> +        g_free(reg_group);
> +    }
> +}
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9w-0007IT-R6; Mon, 20 Feb 2012 20:48:32 +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 1Rza9v-0007GZ-Gz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329770770!53499105!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6406 invoked from network); 20 Feb 2012 20:46:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:46:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770905; l=2726;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PqtnJFLq7KiaW1rA3he3iCjSy+U=;
	b=oR3Un4Cn7JqCvnseDaNtPROoVHGngVJ8EBRbnTYK5lM/O76WN/3d/kKJFURB2IJS/eC
	ir33hoZ71RHoQ4J3u5H0h+mBmAZWJs/83qPm43HcAcdEorJ+5qROkvlIOFN6IIeuR+x7O
	UkBg6kklSUin1TO+xaRKFI7T/lVSublrl/o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo52) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B01767o1KJgQVR
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id ED0CE1863B
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1679965628f5fb2f4127edcb0fc1d449f50f32d6
Message-Id: <1679965628f5fb2f4127.1329770886@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 9] xenpaging: move nominate+evict into
	single 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 1679965628f5fb2f4127edcb0fc1d449f50f32d6
# Parent  41d398992bc05ec5c3d9c7e10f5d5156d8794725
xenpaging: move nominate+evict into single function

Move all code to evict a single gfn into one function. This simplifies
error handling in caller. The function returns -1 on fatal error, 0 on
success and 1 if the gfn cant be paged.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 41d398992bc0 -r 1679965628f5 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -571,6 +571,11 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
+/* Evict a given gfn
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if gfn can not be evicted
+ */
 static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -580,31 +585,51 @@ static int xenpaging_evict_page(struct x
 
     DECLARE_DOMCTL;
 
+    /* Nominate page */
+    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    if ( ret < 0 )
+    {
+        /* unpageable gfn is indicated by EBUSY */
+        if ( errno == EBUSY )
+            ret = 1;
+        else
+            PERROR("Error nominating page %lx", gfn);
+        goto out;
+    }
+
     /* Map page */
-    ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);
+        ret = -1;
         goto out;
     }
 
     /* Copy page */
     ret = write_page(fd, page, slot);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
+        ret = -1;
         goto out;
     }
 
+    /* Release page */
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
     ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
-        PERROR("Error evicting page %lx", gfn);
+        /* A gfn in use is indicated by EBUSY */
+        if ( errno == EBUSY )
+        {
+                ret = 1;
+                DPRINTF("Nominated page %lx busy", gfn);
+        } else
+            PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
@@ -619,6 +644,8 @@ static int xenpaging_evict_page(struct x
     /* Record number of evicted pages */
     paging->num_paged_out++;
 
+    ret = 0;
+
  out:
     return ret;
 }
@@ -753,9 +780,10 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
-        if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, gfn, fd, slot);
+
+        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        if ( ret < 0 )
+            goto out;
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9w-0007IT-R6; Mon, 20 Feb 2012 20:48:32 +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 1Rza9v-0007GZ-Gz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329770770!53499105!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6406 invoked from network); 20 Feb 2012 20:46:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:46:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770905; l=2726;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PqtnJFLq7KiaW1rA3he3iCjSy+U=;
	b=oR3Un4Cn7JqCvnseDaNtPROoVHGngVJ8EBRbnTYK5lM/O76WN/3d/kKJFURB2IJS/eC
	ir33hoZ71RHoQ4J3u5H0h+mBmAZWJs/83qPm43HcAcdEorJ+5qROkvlIOFN6IIeuR+x7O
	UkBg6kklSUin1TO+xaRKFI7T/lVSublrl/o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo52) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B01767o1KJgQVR
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id ED0CE1863B
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1679965628f5fb2f4127edcb0fc1d449f50f32d6
Message-Id: <1679965628f5fb2f4127.1329770886@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 9] xenpaging: move nominate+evict into
	single 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 1679965628f5fb2f4127edcb0fc1d449f50f32d6
# Parent  41d398992bc05ec5c3d9c7e10f5d5156d8794725
xenpaging: move nominate+evict into single function

Move all code to evict a single gfn into one function. This simplifies
error handling in caller. The function returns -1 on fatal error, 0 on
success and 1 if the gfn cant be paged.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 41d398992bc0 -r 1679965628f5 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -571,6 +571,11 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
+/* Evict a given gfn
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if gfn can not be evicted
+ */
 static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -580,31 +585,51 @@ static int xenpaging_evict_page(struct x
 
     DECLARE_DOMCTL;
 
+    /* Nominate page */
+    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    if ( ret < 0 )
+    {
+        /* unpageable gfn is indicated by EBUSY */
+        if ( errno == EBUSY )
+            ret = 1;
+        else
+            PERROR("Error nominating page %lx", gfn);
+        goto out;
+    }
+
     /* Map page */
-    ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);
+        ret = -1;
         goto out;
     }
 
     /* Copy page */
     ret = write_page(fd, page, slot);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
+        ret = -1;
         goto out;
     }
 
+    /* Release page */
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
     ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
-        PERROR("Error evicting page %lx", gfn);
+        /* A gfn in use is indicated by EBUSY */
+        if ( errno == EBUSY )
+        {
+                ret = 1;
+                DPRINTF("Nominated page %lx busy", gfn);
+        } else
+            PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
@@ -619,6 +644,8 @@ static int xenpaging_evict_page(struct x
     /* Record number of evicted pages */
     paging->num_paged_out++;
 
+    ret = 0;
+
  out:
     return ret;
 }
@@ -753,9 +780,10 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
-        if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, gfn, fd, slot);
+
+        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        if ( ret < 0 )
+            goto out;
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9p-0007GS-R9; Mon, 20 Feb 2012 20:48:25 +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 1Rza9n-0007Fs-Px
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329770846!53525764!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31912 invoked from network); 20 Feb 2012 20:47:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 20:47:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770899; l=2762;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=J/o2FBepaIsFC8C0zOI+qjLgA6c=;
	b=GUiJK6x/65ThK6KRn7v+q/b4tBVkXajNPrOGg5CMUNPzcUOjOJtPKnJEMSH9zjrbKvk
	o6UFnbAZL0LeJZ6FWQ2qibAUldxMGV5Us09ZHXop7VgkiNpYwme27WbRkAhjetH6i6qcd
	PaxTaGG6pOOohnLREjpmntS2OoHSQ9wGQhU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (cohen mo6) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z04efco1KI9wvz
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:18 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6E2BB1863C
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 58b9625f746a29db55429c337574f0852e21e06c
Message-Id: <58b9625f746a29db5542.1329770887@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 9] xenpaging: improve performance in
	policy_choose_victim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID 58b9625f746a29db55429c337574f0852e21e06c
# Parent  1679965628f5fb2f4127edcb0fc1d449f50f32d6
xenpaging: improve performance in policy_choose_victim

policy_choose_victim() is one of the bottlenecks in xenpaging. It is called
alot to find free bits in the fragmented bitmaps.

Reduce turnaround time by skipping longs with all bits set.
Adjust wrap detection in loop.

v2:
 - fix copy&paste error, bitmap was tested twice

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1679965628f5 -r 58b9625f746a tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -80,33 +80,58 @@ int policy_init(struct xenpaging *paging
 unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
-    unsigned long wrap = current_gfn;
+    unsigned long i;
 
-    do
+    /* One iteration over all possible gfns */
+    for ( i = 0; i < max_pages; i++ )
     {
+        /* Try next gfn */
         current_gfn++;
+
+        /* Restart on wrap */
         if ( current_gfn >= max_pages )
             current_gfn = 0;
-        /* Could not nominate any gfn */
-        if ( wrap == current_gfn )
+
+        if ( (current_gfn & (BITS_PER_LONG - 1)) == 0 )
         {
-            paging->use_poll_timeout = 1;
-            /* Count wrap arounds */
-            unconsumed_cleared++;
-            /* Force retry every few seconds (depends on poll() timeout) */
-            if ( unconsumed_cleared > 123)
+            /* All gfns busy */
+            if ( ~bitmap[current_gfn >> ORDER_LONG] == 0 || ~unconsumed[current_gfn >> ORDER_LONG] == 0 )
             {
-                /* Force retry of unconsumed gfns */
-                bitmap_clear(unconsumed, max_pages);
-                unconsumed_cleared = 0;
-                DPRINTF("clearing unconsumed, wrap %lx", wrap);
-                /* One more round before returning ENOSPC */
+                current_gfn += BITS_PER_LONG;
+                i += BITS_PER_LONG;
                 continue;
             }
-            return INVALID_MFN;
         }
+
+        /* gfn busy */
+        if ( test_bit(current_gfn, bitmap) )
+            continue;
+
+        /* gfn already tested */
+        if ( test_bit(current_gfn, unconsumed) )
+            continue;
+
+        /* gfn found */
+        break;
     }
-    while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
+
+    /* Could not nominate any gfn */
+    if ( i >= max_pages )
+    {
+        /* No more pages, wait in poll */
+        paging->use_poll_timeout = 1;
+        /* Count wrap arounds */
+        unconsumed_cleared++;
+        /* Force retry every few seconds (depends on poll() timeout) */
+        if ( unconsumed_cleared > 123)
+        {
+            /* Force retry of unconsumed gfns on next call */
+            bitmap_clear(unconsumed, max_pages);
+            unconsumed_cleared = 0;
+            DPRINTF("clearing unconsumed, current_gfn %lx", current_gfn);
+        }
+        return INVALID_MFN;
+    }
 
     set_bit(current_gfn, unconsumed);
     return current_gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9p-0007GS-R9; Mon, 20 Feb 2012 20:48:25 +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 1Rza9n-0007Fs-Px
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329770846!53525764!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31912 invoked from network); 20 Feb 2012 20:47:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 20:47:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770899; l=2762;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=J/o2FBepaIsFC8C0zOI+qjLgA6c=;
	b=GUiJK6x/65ThK6KRn7v+q/b4tBVkXajNPrOGg5CMUNPzcUOjOJtPKnJEMSH9zjrbKvk
	o6UFnbAZL0LeJZ6FWQ2qibAUldxMGV5Us09ZHXop7VgkiNpYwme27WbRkAhjetH6i6qcd
	PaxTaGG6pOOohnLREjpmntS2OoHSQ9wGQhU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (cohen mo6) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z04efco1KI9wvz
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:18 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6E2BB1863C
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 58b9625f746a29db55429c337574f0852e21e06c
Message-Id: <58b9625f746a29db5542.1329770887@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 9] xenpaging: improve performance in
	policy_choose_victim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID 58b9625f746a29db55429c337574f0852e21e06c
# Parent  1679965628f5fb2f4127edcb0fc1d449f50f32d6
xenpaging: improve performance in policy_choose_victim

policy_choose_victim() is one of the bottlenecks in xenpaging. It is called
alot to find free bits in the fragmented bitmaps.

Reduce turnaround time by skipping longs with all bits set.
Adjust wrap detection in loop.

v2:
 - fix copy&paste error, bitmap was tested twice

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1679965628f5 -r 58b9625f746a tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -80,33 +80,58 @@ int policy_init(struct xenpaging *paging
 unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
-    unsigned long wrap = current_gfn;
+    unsigned long i;
 
-    do
+    /* One iteration over all possible gfns */
+    for ( i = 0; i < max_pages; i++ )
     {
+        /* Try next gfn */
         current_gfn++;
+
+        /* Restart on wrap */
         if ( current_gfn >= max_pages )
             current_gfn = 0;
-        /* Could not nominate any gfn */
-        if ( wrap == current_gfn )
+
+        if ( (current_gfn & (BITS_PER_LONG - 1)) == 0 )
         {
-            paging->use_poll_timeout = 1;
-            /* Count wrap arounds */
-            unconsumed_cleared++;
-            /* Force retry every few seconds (depends on poll() timeout) */
-            if ( unconsumed_cleared > 123)
+            /* All gfns busy */
+            if ( ~bitmap[current_gfn >> ORDER_LONG] == 0 || ~unconsumed[current_gfn >> ORDER_LONG] == 0 )
             {
-                /* Force retry of unconsumed gfns */
-                bitmap_clear(unconsumed, max_pages);
-                unconsumed_cleared = 0;
-                DPRINTF("clearing unconsumed, wrap %lx", wrap);
-                /* One more round before returning ENOSPC */
+                current_gfn += BITS_PER_LONG;
+                i += BITS_PER_LONG;
                 continue;
             }
-            return INVALID_MFN;
         }
+
+        /* gfn busy */
+        if ( test_bit(current_gfn, bitmap) )
+            continue;
+
+        /* gfn already tested */
+        if ( test_bit(current_gfn, unconsumed) )
+            continue;
+
+        /* gfn found */
+        break;
     }
-    while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
+
+    /* Could not nominate any gfn */
+    if ( i >= max_pages )
+    {
+        /* No more pages, wait in poll */
+        paging->use_poll_timeout = 1;
+        /* Count wrap arounds */
+        unconsumed_cleared++;
+        /* Force retry every few seconds (depends on poll() timeout) */
+        if ( unconsumed_cleared > 123)
+        {
+            /* Force retry of unconsumed gfns on next call */
+            bitmap_clear(unconsumed, max_pages);
+            unconsumed_cleared = 0;
+            DPRINTF("clearing unconsumed, current_gfn %lx", current_gfn);
+        }
+        return INVALID_MFN;
+    }
 
     set_bit(current_gfn, unconsumed);
     return current_gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9q-0007Ge-6n; Mon, 20 Feb 2012 20:48:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rza9o-0007Fj-2U
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329770897!15339117!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1026 invoked from network); 20 Feb 2012 20:48:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770897; l=2867;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=6nC3CNXWutEbA/WPiRfozzECYOk=;
	b=XK2YyPdwg5mGif+P0YSUql/qYM9hA/JY028Lvx28MINUHM1zkwQNH1Wi9IGEW/VI3MB
	uOss7eRpvsbl2Ae8RPKEmg2rHC8qMjpNg5XX9VuDBbYuJyQ0Rs3TlxQCSlZx26hTpO63Q
	I0/EHypP2ecWixULqdeOzSKJhjKOEQiyum8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo6) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z03924o1KK26It
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9A4831863A
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 41d398992bc05ec5c3d9c7e10f5d5156d8794725
Message-Id: <41d398992bc05ec5c3d9.1329770885@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 9] xenpaging: reduce number of qemu cache
	flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 41d398992bc05ec5c3d9c7e10f5d5156d8794725
# Parent  9c678c4e4658f17325e4549cb152d610f85efad4
xenpaging: reduce number of qemu cache flushes

Currently the command to flush the qemu cache is called alot if there
are no more pages to evict. This causes churn in the logfiles, and qemu
can not release more pages anyway since the last command.

Fix this by remembering the current number of paged-out gfns, if this
number did not change since the last flush command then sending another
new flush command will not free any more gfns.

Remove return code from xenpaging_mem_paging_flush_ioemu_cache() since
errors do not matter, and will be handled elsewhere. Also failure to
send the flush command is not fatal.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9c678c4e4658 -r 41d398992bc0 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -61,18 +61,15 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
+static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
     struct xs_handle *xsh = paging->xs_handle;
     domid_t domain_id = paging->mem_event.domain_id;
     char path[80];
-    bool rc;
 
     sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
 
-    rc = xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
-
-    return rc == true ? 0 : -1;
+    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
 }
 
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
@@ -728,7 +725,7 @@ static int evict_victim(struct xenpaging
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
-    int j = 0;
+    static int num_paged_out;
     int ret;
 
     do
@@ -736,6 +733,17 @@ static int evict_victim(struct xenpaging
         gfn = policy_choose_victim(paging);
         if ( gfn == INVALID_MFN )
         {
+            /* If the number did not change after last flush command then
+             * the command did not reach qemu yet, or qemu still processes
+             * the command, or qemu has nothing to release.
+             * Right now there is no need to issue the command again.
+             */
+            if ( num_paged_out != paging->num_paged_out )
+            {
+                DPRINTF("Flushing qemu cache\n");
+                xenpaging_mem_paging_flush_ioemu_cache(paging);
+                num_paged_out = paging->num_paged_out;
+            }
             ret = -ENOSPC;
             goto out;
         }
@@ -748,12 +756,6 @@ static int evict_victim(struct xenpaging
         ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
             ret = xenpaging_evict_page(paging, gfn, fd, slot);
-        else
-        {
-            if ( j++ % 1000 == 0 )
-                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    PERROR("Error flushing ioemu cache");
-        }
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9q-0007Ge-6n; Mon, 20 Feb 2012 20:48:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rza9o-0007Fj-2U
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329770897!15339117!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1026 invoked from network); 20 Feb 2012 20:48:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770897; l=2867;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=6nC3CNXWutEbA/WPiRfozzECYOk=;
	b=XK2YyPdwg5mGif+P0YSUql/qYM9hA/JY028Lvx28MINUHM1zkwQNH1Wi9IGEW/VI3MB
	uOss7eRpvsbl2Ae8RPKEmg2rHC8qMjpNg5XX9VuDBbYuJyQ0Rs3TlxQCSlZx26hTpO63Q
	I0/EHypP2ecWixULqdeOzSKJhjKOEQiyum8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo6) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z03924o1KK26It
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9A4831863A
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 41d398992bc05ec5c3d9c7e10f5d5156d8794725
Message-Id: <41d398992bc05ec5c3d9.1329770885@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 9] xenpaging: reduce number of qemu cache
	flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 41d398992bc05ec5c3d9c7e10f5d5156d8794725
# Parent  9c678c4e4658f17325e4549cb152d610f85efad4
xenpaging: reduce number of qemu cache flushes

Currently the command to flush the qemu cache is called alot if there
are no more pages to evict. This causes churn in the logfiles, and qemu
can not release more pages anyway since the last command.

Fix this by remembering the current number of paged-out gfns, if this
number did not change since the last flush command then sending another
new flush command will not free any more gfns.

Remove return code from xenpaging_mem_paging_flush_ioemu_cache() since
errors do not matter, and will be handled elsewhere. Also failure to
send the flush command is not fatal.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9c678c4e4658 -r 41d398992bc0 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -61,18 +61,15 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
+static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
     struct xs_handle *xsh = paging->xs_handle;
     domid_t domain_id = paging->mem_event.domain_id;
     char path[80];
-    bool rc;
 
     sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
 
-    rc = xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
-
-    return rc == true ? 0 : -1;
+    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
 }
 
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
@@ -728,7 +725,7 @@ static int evict_victim(struct xenpaging
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
-    int j = 0;
+    static int num_paged_out;
     int ret;
 
     do
@@ -736,6 +733,17 @@ static int evict_victim(struct xenpaging
         gfn = policy_choose_victim(paging);
         if ( gfn == INVALID_MFN )
         {
+            /* If the number did not change after last flush command then
+             * the command did not reach qemu yet, or qemu still processes
+             * the command, or qemu has nothing to release.
+             * Right now there is no need to issue the command again.
+             */
+            if ( num_paged_out != paging->num_paged_out )
+            {
+                DPRINTF("Flushing qemu cache\n");
+                xenpaging_mem_paging_flush_ioemu_cache(paging);
+                num_paged_out = paging->num_paged_out;
+            }
             ret = -ENOSPC;
             goto out;
         }
@@ -748,12 +756,6 @@ static int evict_victim(struct xenpaging
         ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
             ret = xenpaging_evict_page(paging, gfn, fd, slot);
-        else
-        {
-            if ( j++ % 1000 == 0 )
-                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    PERROR("Error flushing ioemu cache");
-        }
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9r-0007Gq-Ji; Mon, 20 Feb 2012 20:48:27 +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 1Rza9p-0007Ft-TG
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329770845!50045620!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7092 invoked from network); 20 Feb 2012 20:47:25 -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; 20 Feb 2012 20:47:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770899; l=3325;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=J7xJ8RCZhskfiJ/n/UjFJcxM+Yw=;
	b=BTRflj6VrG1QT3z2/lUGWu7o9K4iA5MP/vSR3M5I5LXZ+p56u1AVnvfDcTq+eIVfGJJ
	xoZWSgTShOqPQ9yzbMotN6S5aA6MDpPkAfyyk23Fdf+y/rgGr9hu8KcyOzBY99+KcGZjb
	U/8kImJZfUz65P4y0y8OmJQYwf8OFNmEuQk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (jimi mo43) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Q0215ao1KIkoGz
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2E9D518639
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9c678c4e4658f17325e4549cb152d610f85efad4
Message-Id: <9c678c4e4658f17325e4.1329770884@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 9] xenpaging: no poll timeout while
 page-out is in progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 9c678c4e4658f17325e4549cb152d610f85efad4
# Parent  4b2dbd2cb9977f357a5dd754c923ed14dda2ec51
xenpaging: no poll timeout while page-out is in progress

The main loop calls xenpaging_wait_for_event_or_timeout() unconditionally
before doing any work. This function calls poll() with a timeout of 100ms. As
a result the page-out process is very slow due to the delay in poll().

Call poll() without timeout so that it returns immediately until the page-out
is done. Page-out is done when either the policy finds no more pages to
nominate or when the requested number of pages is reached.

The condition is cleared when a watch event arrives, so that processing the
new target is not delayed once again by poll().

v2:
- no poll timeout also when large number of evicts is pending

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4b2dbd2cb997 -r 9c678c4e4658 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -90,6 +90,7 @@ unsigned long policy_choose_victim(struc
         /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            paging->use_poll_timeout = 1;
             /* Count wrap arounds */
             unconsumed_cleared++;
             /* Force retry every few seconds (depends on poll() timeout) */
diff -r 4b2dbd2cb997 -r 9c678c4e4658 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -84,6 +84,7 @@ static int xenpaging_wait_for_event_or_t
     struct pollfd fd[2];
     int port;
     int rc;
+    int timeout;
 
     /* Wait for event channel and xenstore */
     fd[0].fd = xc_evtchn_fd(xce);
@@ -91,7 +92,9 @@ static int xenpaging_wait_for_event_or_t
     fd[1].fd = xs_fileno(paging->xs_handle);
     fd[1].events = POLLIN | POLLERR;
 
-    rc = poll(fd, 2, 100);
+    /* No timeout while page-out is still in progress */
+    timeout = paging->use_poll_timeout ? 100 : 0;
+    rc = poll(fd, 2, timeout);
     if ( rc < 0 )
     {
         if (errno == EINTR)
@@ -133,6 +136,8 @@ static int xenpaging_wait_for_event_or_t
                         if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
                             target_tot_pages = paging->max_pages;
                         paging->target_tot_pages = target_tot_pages;
+                        /* Disable poll() delay while new target is not yet reached */
+                        paging->use_poll_timeout = 0;
                         DPRINTF("new target_tot_pages %d\n", target_tot_pages);
                     }
                     free(val);
@@ -970,7 +975,10 @@ int main(int argc, char *argv[])
             }
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
+            {
+                paging->use_poll_timeout = 0;
                 num = 42;
+            }
             evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
@@ -984,6 +992,11 @@ int main(int argc, char *argv[])
             }
             resume_pages(paging, num);
         }
+        /* Now target was reached, enable poll() timeout */
+        else
+        {
+            paging->use_poll_timeout = 1;
+        }
 
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
diff -r 4b2dbd2cb997 -r 9c678c4e4658 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -55,6 +55,7 @@ struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int use_poll_timeout;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9r-0007Gq-Ji; Mon, 20 Feb 2012 20:48:27 +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 1Rza9p-0007Ft-TG
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329770845!50045620!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7092 invoked from network); 20 Feb 2012 20:47:25 -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; 20 Feb 2012 20:47:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770899; l=3325;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=J7xJ8RCZhskfiJ/n/UjFJcxM+Yw=;
	b=BTRflj6VrG1QT3z2/lUGWu7o9K4iA5MP/vSR3M5I5LXZ+p56u1AVnvfDcTq+eIVfGJJ
	xoZWSgTShOqPQ9yzbMotN6S5aA6MDpPkAfyyk23Fdf+y/rgGr9hu8KcyOzBY99+KcGZjb
	U/8kImJZfUz65P4y0y8OmJQYwf8OFNmEuQk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (jimi mo43) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Q0215ao1KIkoGz
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2E9D518639
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9c678c4e4658f17325e4549cb152d610f85efad4
Message-Id: <9c678c4e4658f17325e4.1329770884@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 9] xenpaging: no poll timeout while
 page-out is in progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 9c678c4e4658f17325e4549cb152d610f85efad4
# Parent  4b2dbd2cb9977f357a5dd754c923ed14dda2ec51
xenpaging: no poll timeout while page-out is in progress

The main loop calls xenpaging_wait_for_event_or_timeout() unconditionally
before doing any work. This function calls poll() with a timeout of 100ms. As
a result the page-out process is very slow due to the delay in poll().

Call poll() without timeout so that it returns immediately until the page-out
is done. Page-out is done when either the policy finds no more pages to
nominate or when the requested number of pages is reached.

The condition is cleared when a watch event arrives, so that processing the
new target is not delayed once again by poll().

v2:
- no poll timeout also when large number of evicts is pending

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4b2dbd2cb997 -r 9c678c4e4658 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -90,6 +90,7 @@ unsigned long policy_choose_victim(struc
         /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            paging->use_poll_timeout = 1;
             /* Count wrap arounds */
             unconsumed_cleared++;
             /* Force retry every few seconds (depends on poll() timeout) */
diff -r 4b2dbd2cb997 -r 9c678c4e4658 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -84,6 +84,7 @@ static int xenpaging_wait_for_event_or_t
     struct pollfd fd[2];
     int port;
     int rc;
+    int timeout;
 
     /* Wait for event channel and xenstore */
     fd[0].fd = xc_evtchn_fd(xce);
@@ -91,7 +92,9 @@ static int xenpaging_wait_for_event_or_t
     fd[1].fd = xs_fileno(paging->xs_handle);
     fd[1].events = POLLIN | POLLERR;
 
-    rc = poll(fd, 2, 100);
+    /* No timeout while page-out is still in progress */
+    timeout = paging->use_poll_timeout ? 100 : 0;
+    rc = poll(fd, 2, timeout);
     if ( rc < 0 )
     {
         if (errno == EINTR)
@@ -133,6 +136,8 @@ static int xenpaging_wait_for_event_or_t
                         if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
                             target_tot_pages = paging->max_pages;
                         paging->target_tot_pages = target_tot_pages;
+                        /* Disable poll() delay while new target is not yet reached */
+                        paging->use_poll_timeout = 0;
                         DPRINTF("new target_tot_pages %d\n", target_tot_pages);
                     }
                     free(val);
@@ -970,7 +975,10 @@ int main(int argc, char *argv[])
             }
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
+            {
+                paging->use_poll_timeout = 0;
                 num = 42;
+            }
             evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
@@ -984,6 +992,11 @@ int main(int argc, char *argv[])
             }
             resume_pages(paging, num);
         }
+        /* Now target was reached, enable poll() timeout */
+        else
+        {
+            paging->use_poll_timeout = 1;
+        }
 
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
diff -r 4b2dbd2cb997 -r 9c678c4e4658 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -55,6 +55,7 @@ struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int use_poll_timeout;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9u-0007HO-0T; Mon, 20 Feb 2012 20:48:30 +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 1Rza9r-0007Gl-Vz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:28 +0000
Received: from [85.158.139.83:17915] by server-8.bemta-5.messagelabs.com id
	CE/D5-09797-B91B24F4; Mon, 20 Feb 2012 20:48:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329770906!15321062!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2607 invoked from network); 20 Feb 2012 20:48:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770906; l=2390;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=8lmqaE5N/ce3P9Qwd49KPNr9ckc=;
	b=JzhlnMSij4D7a0IiE/AiV39IlMWh9d6IJzfpRaN3MlRmwGMJljp20mQ/+Utts5itggf
	hQN2ceJ4h+bedN+Frc+9Q1qyP+2HzdFmV64PQNItElzMKcR4L1SsLuMFJMOHrRiqASyy2
	iDEaRhWzEKEY7qBDjpQzsrsDP/XTnG0oUA0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo51) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a032f4o1KIr0db
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id ADCBA18639
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:16 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f6886348f3f6c36d080b1fd667c0327d591e7cb2
Message-Id: <f6886348f3f6c36d080b.1329770891@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 9 of 9] xenpaging: implement stack of free slots
	in pagefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID f6886348f3f6c36d080b1fd667c0327d591e7cb2
# Parent  bb3de3bbdff3ea9da31f421053cae65999d15c89
xenpaging: implement stack of free slots in pagefile

Scanning the slot_to_gfn[] array for a free slot is expensive because
evict_pages() always needs to scan the whole array. Remember the last
slots freed during page-in requests and reuse them in evict_pages().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bb3de3bbdff3 -r f6886348f3f6 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -432,6 +432,11 @@ static struct xenpaging *xenpaging_init(
     if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
         goto err;
 
+    /* Allocate stack for known free slots in pagefile */
+    paging->free_slot_stack = calloc(paging->max_pages, sizeof(*paging->free_slot_stack));
+    if ( !paging->free_slot_stack )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -483,6 +488,7 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->free_slot_stack);
         free(paging->slot_to_gfn);
         free(paging->gfn_to_slot);
         free(paging->bitmap);
@@ -807,6 +813,20 @@ static int evict_pages(struct xenpaging 
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
 
+    /* Reuse known free slots */
+    while ( paging->stack_count > 0 && num < num_pages )
+    {
+        slot = paging->free_slot_stack[--paging->stack_count];
+        rc = evict_victim(paging, slot);
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
+            return num;
+        }
+        num++;
+    }
+
+    /* Scan all slots slots for remainders */
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
@@ -930,6 +950,9 @@ int main(int argc, char *argv[])
 
                 /* Clear this pagefile slot */
                 paging->slot_to_gfn[slot] = 0;
+
+                /* Record this free slot */
+                paging->free_slot_stack[paging->stack_count++] = slot;
             }
             else
             {
diff -r bb3de3bbdff3 -r f6886348f3f6 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -60,6 +60,8 @@ struct xenpaging {
     int policy_mru_size;
     int use_poll_timeout;
     int debug;
+    int stack_count;
+    int *free_slot_stack;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1Rza9u-0007HO-0T; Mon, 20 Feb 2012 20:48:30 +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 1Rza9r-0007Gl-Vz
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:28 +0000
Received: from [85.158.139.83:17915] by server-8.bemta-5.messagelabs.com id
	CE/D5-09797-B91B24F4; Mon, 20 Feb 2012 20:48:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329770906!15321062!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMzUwNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2607 invoked from network); 20 Feb 2012 20:48:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770906; l=2390;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=8lmqaE5N/ce3P9Qwd49KPNr9ckc=;
	b=JzhlnMSij4D7a0IiE/AiV39IlMWh9d6IJzfpRaN3MlRmwGMJljp20mQ/+Utts5itggf
	hQN2ceJ4h+bedN+Frc+9Q1qyP+2HzdFmV64PQNItElzMKcR4L1SsLuMFJMOHrRiqASyy2
	iDEaRhWzEKEY7qBDjpQzsrsDP/XTnG0oUA0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo51) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a032f4o1KIr0db
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id ADCBA18639
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:16 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f6886348f3f6c36d080b1fd667c0327d591e7cb2
Message-Id: <f6886348f3f6c36d080b.1329770891@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 9 of 9] xenpaging: implement stack of free slots
	in pagefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID f6886348f3f6c36d080b1fd667c0327d591e7cb2
# Parent  bb3de3bbdff3ea9da31f421053cae65999d15c89
xenpaging: implement stack of free slots in pagefile

Scanning the slot_to_gfn[] array for a free slot is expensive because
evict_pages() always needs to scan the whole array. Remember the last
slots freed during page-in requests and reuse them in evict_pages().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bb3de3bbdff3 -r f6886348f3f6 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -432,6 +432,11 @@ static struct xenpaging *xenpaging_init(
     if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
         goto err;
 
+    /* Allocate stack for known free slots in pagefile */
+    paging->free_slot_stack = calloc(paging->max_pages, sizeof(*paging->free_slot_stack));
+    if ( !paging->free_slot_stack )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -483,6 +488,7 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->free_slot_stack);
         free(paging->slot_to_gfn);
         free(paging->gfn_to_slot);
         free(paging->bitmap);
@@ -807,6 +813,20 @@ static int evict_pages(struct xenpaging 
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
 
+    /* Reuse known free slots */
+    while ( paging->stack_count > 0 && num < num_pages )
+    {
+        slot = paging->free_slot_stack[--paging->stack_count];
+        rc = evict_victim(paging, slot);
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
+            return num;
+        }
+        num++;
+    }
+
+    /* Scan all slots slots for remainders */
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
@@ -930,6 +950,9 @@ int main(int argc, char *argv[])
 
                 /* Clear this pagefile slot */
                 paging->slot_to_gfn[slot] = 0;
+
+                /* Record this free slot */
+                paging->free_slot_stack[paging->stack_count++] = slot;
             }
             else
             {
diff -r bb3de3bbdff3 -r f6886348f3f6 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -60,6 +60,8 @@ struct xenpaging {
     int policy_mru_size;
     int use_poll_timeout;
     int debug;
+    int stack_count;
+    int *free_slot_stack;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rza9u-0007Hc-DH; Mon, 20 Feb 2012 20:48:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rza9s-0007GF-RM
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329770901!15656293!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24391 invoked from network); 20 Feb 2012 20:48:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770901; l=2256;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=8ygFdkOG4Gj0Co0yiJJW4zIKcik=;
	b=p572HhGac6yMunl+7a92rzAqTNQ4NQmKLFjehpQbRWtHjw51qxMayLDxLtcSxm+u8aw
	AUEnnwkRefM33w+MntxAEIdoNMRu/HEZjsd1MQhpwhgoDPN08F2N5yFC/gC+l4sF2WVHh
	/73cNysJMzWtrYuMOwAa3/AwSH+Lttuohuo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo1) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e07352o1KK0JAN
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9F77A18638
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:15 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bb3de3bbdff3ea9da31f421053cae65999d15c89
Message-Id: <bb3de3bbdff3ea9da31f.1329770890@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 8 of 9] xenpaging: move page_buffer into struct
	xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID bb3de3bbdff3ea9da31f421053cae65999d15c89
# Parent  c137d7bd207b7b21d69bd6470be285023a4c2baf
xenpaging: move page_buffer into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c137d7bd207b -r bb3de3bbdff3 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -44,7 +44,6 @@ static char *dom_path;
 static char watch_token[16];
 static char *filename;
 static int interrupted;
-static void *paging_buffer = NULL;
 
 static void unlink_pagefile(void)
 {
@@ -441,8 +440,8 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    paging_buffer = init_page();
-    if ( !paging_buffer )
+    paging->paging_buffer = init_page();
+    if ( !paging->paging_buffer )
     {
         PERROR("Creating page aligned load buffer");
         goto err;
@@ -465,6 +464,11 @@ static struct xenpaging *xenpaging_init(
             xs_close(paging->xs_handle);
         if ( xch )
             xc_interface_close(xch);
+        if ( paging->paging_buffer )
+        {
+            munlock(paging->paging_buffer, PAGE_SIZE);
+            free(paging->paging_buffer);
+        }
         if ( paging->mem_event.shared_page )
         {
             munlock(paging->mem_event.shared_page, PAGE_SIZE);
@@ -687,7 +691,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(paging->fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging->paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -697,8 +701,7 @@ static int xenpaging_populate_page(struc
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
-                                    paging_buffer);
+        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn, paging->paging_buffer);
         if ( ret < 0 )
         {
             if ( errno == ENOMEM )
diff -r c137d7bd207b -r bb3de3bbdff3 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -49,6 +49,8 @@ struct xenpaging {
     unsigned long *slot_to_gfn;
     int *gfn_to_slot;
 
+    void *paging_buffer;
+
     struct mem_event mem_event;
     int fd;
     /* number of pages for which data structures were allocated */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rza9u-0007Hc-DH; Mon, 20 Feb 2012 20:48:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rza9s-0007GF-RM
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329770901!15656293!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24391 invoked from network); 20 Feb 2012 20:48:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770901; l=2256;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=8ygFdkOG4Gj0Co0yiJJW4zIKcik=;
	b=p572HhGac6yMunl+7a92rzAqTNQ4NQmKLFjehpQbRWtHjw51qxMayLDxLtcSxm+u8aw
	AUEnnwkRefM33w+MntxAEIdoNMRu/HEZjsd1MQhpwhgoDPN08F2N5yFC/gC+l4sF2WVHh
	/73cNysJMzWtrYuMOwAa3/AwSH+Lttuohuo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo1) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e07352o1KK0JAN
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9F77A18638
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:15 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bb3de3bbdff3ea9da31f421053cae65999d15c89
Message-Id: <bb3de3bbdff3ea9da31f.1329770890@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 8 of 9] xenpaging: move page_buffer into struct
	xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID bb3de3bbdff3ea9da31f421053cae65999d15c89
# Parent  c137d7bd207b7b21d69bd6470be285023a4c2baf
xenpaging: move page_buffer into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c137d7bd207b -r bb3de3bbdff3 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -44,7 +44,6 @@ static char *dom_path;
 static char watch_token[16];
 static char *filename;
 static int interrupted;
-static void *paging_buffer = NULL;
 
 static void unlink_pagefile(void)
 {
@@ -441,8 +440,8 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    paging_buffer = init_page();
-    if ( !paging_buffer )
+    paging->paging_buffer = init_page();
+    if ( !paging->paging_buffer )
     {
         PERROR("Creating page aligned load buffer");
         goto err;
@@ -465,6 +464,11 @@ static struct xenpaging *xenpaging_init(
             xs_close(paging->xs_handle);
         if ( xch )
             xc_interface_close(xch);
+        if ( paging->paging_buffer )
+        {
+            munlock(paging->paging_buffer, PAGE_SIZE);
+            free(paging->paging_buffer);
+        }
         if ( paging->mem_event.shared_page )
         {
             munlock(paging->mem_event.shared_page, PAGE_SIZE);
@@ -687,7 +691,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(paging->fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging->paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -697,8 +701,7 @@ static int xenpaging_populate_page(struc
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
-                                    paging_buffer);
+        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn, paging->paging_buffer);
         if ( ret < 0 )
         {
             if ( errno == ENOMEM )
diff -r c137d7bd207b -r bb3de3bbdff3 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -49,6 +49,8 @@ struct xenpaging {
     unsigned long *slot_to_gfn;
     int *gfn_to_slot;
 
+    void *paging_buffer;
+
     struct mem_event mem_event;
     int fd;
     /* number of pages for which data structures were allocated */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzaA1-0007Kq-Df; Mon, 20 Feb 2012 20:48:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rza9z-0007JR-H4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:35 +0000
Received: from [85.158.139.83:18054] by server-11.bemta-5.messagelabs.com id
	C5/60-14397-2A1B24F4; Mon, 20 Feb 2012 20:48:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329770913!15321070!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2698 invoked from network); 20 Feb 2012 20:48:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770913; l=10609;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=IqO5cSBjTnKcEFejBehaotxCfK8=;
	b=CjCwgsAOFYJHPt7wRN8hp/cCz6ensEnHy+Yi+soEfaPkeRwWmKJG5bUVgfq8Fxbow9a
	ABROLknwLsaW0FsxvTDyrtQRbBr23V68pnWHOTlkYpVT3HYImrF3ueuiY1rFJnwoPzF81
	Y3r4wiX2688j+B421c7husZFZ+foUrkV0Ls=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo35) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a00d5eo1KK6OXC
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id BC43B18638
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4b2dbd2cb9977f357a5dd754c923ed14dda2ec51
Message-Id: <4b2dbd2cb9977f357a5d.1329770883@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 9] xenpaging: use flat index for pagefile
 and page-in requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 4b2dbd2cb9977f357a5dd754c923ed14dda2ec51
# Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
xenpaging: use flat index for pagefile and page-in requests

This change is based on an idea by <hongkaixing@huawei.com> and
<bicky.shi@huawei.com>.

Scanning the victims[] array is time consuming with a large number of
target pages. Replace the loop to find the slot in the pagefile which
holds the requested gfn with an index.

Remove the victims array and replace it with a flat array. This array
holds the gfn for a given slot in the pagefile. Adjust all users of the
victims array.

Rename variable in main() from i to slot to clearify the meaning.

Update xenpaging_evict_page() to pass a pointer to xen_pfn_t to
xc_map_foreign_pages().

Update policy_choose_victim() to return either a gfn or INVALID_MFN.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(struct xenpaging *paging);
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
+unsigned long policy_choose_victim(struct xenpaging *paging);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(struct xenpaging *paging
     return rc;
 }
 
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
+unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
@@ -102,16 +102,13 @@ int policy_choose_victim(struct xenpagin
                 /* One more round before returning ENOSPC */
                 continue;
             }
-            victim->gfn = INVALID_MFN;
-            return -ENOSPC;
+            return INVALID_MFN;
         }
     }
     while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
 
     set_bit(current_gfn, unconsumed);
-    victim->gfn = current_gfn;
-
-    return 0;
+    return current_gfn;
 }
 
 void policy_notify_paged_out(unsigned long gfn)
diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -430,6 +430,12 @@ static struct xenpaging *xenpaging_init(
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
+    /* Allocate indicies for pagefile slots */
+    paging->slot_to_gfn = calloc(paging->max_pages, sizeof(*paging->slot_to_gfn));
+    paging->gfn_to_slot = calloc(paging->max_pages, sizeof(*paging->gfn_to_slot));
+    if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -468,6 +474,8 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->slot_to_gfn);
+        free(paging->gfn_to_slot);
         free(paging->bitmap);
         free(paging);
     }
@@ -561,31 +569,29 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
-    unsigned long gfn;
+    xen_pfn_t victim = gfn;
     int ret;
 
     DECLARE_DOMCTL;
 
     /* Map page */
-    gfn = victim->gfn;
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ, &gfn, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page %lx", victim->gfn);
+        PERROR("Error mapping page %lx", gfn);
         goto out;
     }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
+    ret = write_page(fd, page, slot);
     if ( ret != 0 )
     {
-        PERROR("Error copying page %lx", victim->gfn);
+        PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -593,17 +599,20 @@ static int xenpaging_evict_page(struct x
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
+    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page %lx", victim->gfn);
+        PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
-    DPRINTF("evict_page > gfn %lx pageslot %d\n", victim->gfn, i);
+    DPRINTF("evict_page > gfn %lx pageslot %d\n", gfn, slot);
     /* Notify policy of page being paged out */
-    policy_notify_paged_out(victim->gfn);
+    policy_notify_paged_out(gfn);
+
+    /* Update index */
+    paging->slot_to_gfn[slot] = gfn;
+    paging->gfn_to_slot[gfn] = slot;
 
     /* Record number of evicted pages */
     paging->num_paged_out++;
@@ -710,19 +719,19 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
-static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
+    unsigned long gfn;
     int j = 0;
     int ret;
 
     do
     {
-        ret = policy_choose_victim(paging, victim);
-        if ( ret != 0 )
+        gfn = policy_choose_victim(paging);
+        if ( gfn == INVALID_MFN )
         {
-            if ( ret != -ENOSPC )
-                ERROR("Error choosing victim");
+            ret = -ENOSPC;
             goto out;
         }
 
@@ -731,9 +740,9 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
+        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
+            ret = xenpaging_evict_page(paging, gfn, fd, slot);
         else
         {
             if ( j++ % 1000 == 0 )
@@ -743,7 +752,7 @@ static int evict_victim(struct xenpaging
     }
     while ( ret );
 
-    if ( test_and_set_bit(victim->gfn, paging->bitmap) )
+    if ( test_and_set_bit(gfn, paging->bitmap) )
         ERROR("Page has been evicted before");
 
     ret = 0;
@@ -753,7 +762,7 @@ static int evict_victim(struct xenpaging
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -761,10 +770,10 @@ static int evict_pages(struct xenpaging 
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
-        if ( victims[slot].gfn != INVALID_MFN )
+        if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, &victims[slot], fd, slot);
+        rc = evict_victim(paging, fd, slot);
         if ( rc == -ENOSPC )
             break;
         if ( rc == -EINTR )
@@ -780,11 +789,10 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
-    int i;
+    int slot;
     int tot_pages;
     int rc = -1;
     int rc1;
@@ -813,15 +821,6 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(struct victim));
-    if ( !victims )
-        goto out;
-
-    /* Mark all slots as unallocated */
-    for ( i = 0; i < paging->max_pages; i++ )
-        victims[i].gfn = INVALID_MFN;
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -853,32 +852,35 @@ int main(int argc, char *argv[])
         {
             get_request(&paging->mem_event, &req);
 
+            if ( req.gfn > paging->max_pages )
+            {
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %lx\n", req.gfn, paging->max_pages);
+                goto out;
+            }
+
             /* Check if the page has already been paged in */
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->max_pages; i++ )
+                slot = paging->gfn_to_slot[req.gfn];
+
+                /* Sanity check */
+                if ( paging->slot_to_gfn[slot] != req.gfn )
                 {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->max_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
                     goto out;
                 }
-                
+
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
-                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, slot);
                     /* Notify policy of page being dropped */
                     policy_notify_dropped(req.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, i);
+                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
                     if ( rc != 0 )
                     {
                         PERROR("Error populating page %"PRIx64"", req.gfn);
@@ -899,7 +901,7 @@ int main(int argc, char *argv[])
                 }
 
                 /* Clear this pagefile slot */
-                victims[i].gfn = INVALID_MFN;
+                paging->slot_to_gfn[slot] = 0;
             }
             else
             {
@@ -969,7 +971,7 @@ int main(int argc, char *argv[])
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
                 num = 42;
-            evict_pages(paging, fd, victims, num);
+            evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -989,7 +991,6 @@ int main(int argc, char *argv[])
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -46,6 +46,9 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
+    unsigned long *slot_to_gfn;
+    int *gfn_to_slot;
+
     struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
@@ -56,13 +59,6 @@ struct xenpaging {
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 
-
-struct victim {
-    /* the gfn of the page to evict */
-    unsigned long gfn;
-};
-
-
 extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzaA1-0007Kq-Df; Mon, 20 Feb 2012 20:48:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rza9z-0007JR-H4
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:35 +0000
Received: from [85.158.139.83:18054] by server-11.bemta-5.messagelabs.com id
	C5/60-14397-2A1B24F4; Mon, 20 Feb 2012 20:48:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329770913!15321070!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2698 invoked from network); 20 Feb 2012 20:48:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770913; l=10609;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=IqO5cSBjTnKcEFejBehaotxCfK8=;
	b=CjCwgsAOFYJHPt7wRN8hp/cCz6ensEnHy+Yi+soEfaPkeRwWmKJG5bUVgfq8Fxbow9a
	ABROLknwLsaW0FsxvTDyrtQRbBr23V68pnWHOTlkYpVT3HYImrF3ueuiY1rFJnwoPzF81
	Y3r4wiX2688j+B421c7husZFZ+foUrkV0Ls=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (klopstock mo35) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a00d5eo1KK6OXC
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id BC43B18638
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4b2dbd2cb9977f357a5dd754c923ed14dda2ec51
Message-Id: <4b2dbd2cb9977f357a5d.1329770883@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 9] xenpaging: use flat index for pagefile
 and page-in requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID 4b2dbd2cb9977f357a5dd754c923ed14dda2ec51
# Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
xenpaging: use flat index for pagefile and page-in requests

This change is based on an idea by <hongkaixing@huawei.com> and
<bicky.shi@huawei.com>.

Scanning the victims[] array is time consuming with a large number of
target pages. Replace the loop to find the slot in the pagefile which
holds the requested gfn with an index.

Remove the victims array and replace it with a flat array. This array
holds the gfn for a given slot in the pagefile. Adjust all users of the
victims array.

Rename variable in main() from i to slot to clearify the meaning.

Update xenpaging_evict_page() to pass a pointer to xen_pfn_t to
xc_map_foreign_pages().

Update policy_choose_victim() to return either a gfn or INVALID_MFN.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(struct xenpaging *paging);
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
+unsigned long policy_choose_victim(struct xenpaging *paging);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(struct xenpaging *paging
     return rc;
 }
 
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
+unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
@@ -102,16 +102,13 @@ int policy_choose_victim(struct xenpagin
                 /* One more round before returning ENOSPC */
                 continue;
             }
-            victim->gfn = INVALID_MFN;
-            return -ENOSPC;
+            return INVALID_MFN;
         }
     }
     while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
 
     set_bit(current_gfn, unconsumed);
-    victim->gfn = current_gfn;
-
-    return 0;
+    return current_gfn;
 }
 
 void policy_notify_paged_out(unsigned long gfn)
diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -430,6 +430,12 @@ static struct xenpaging *xenpaging_init(
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
+    /* Allocate indicies for pagefile slots */
+    paging->slot_to_gfn = calloc(paging->max_pages, sizeof(*paging->slot_to_gfn));
+    paging->gfn_to_slot = calloc(paging->max_pages, sizeof(*paging->gfn_to_slot));
+    if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -468,6 +474,8 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->slot_to_gfn);
+        free(paging->gfn_to_slot);
         free(paging->bitmap);
         free(paging);
     }
@@ -561,31 +569,29 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
-    unsigned long gfn;
+    xen_pfn_t victim = gfn;
     int ret;
 
     DECLARE_DOMCTL;
 
     /* Map page */
-    gfn = victim->gfn;
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ, &gfn, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page %lx", victim->gfn);
+        PERROR("Error mapping page %lx", gfn);
         goto out;
     }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
+    ret = write_page(fd, page, slot);
     if ( ret != 0 )
     {
-        PERROR("Error copying page %lx", victim->gfn);
+        PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -593,17 +599,20 @@ static int xenpaging_evict_page(struct x
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
+    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page %lx", victim->gfn);
+        PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
-    DPRINTF("evict_page > gfn %lx pageslot %d\n", victim->gfn, i);
+    DPRINTF("evict_page > gfn %lx pageslot %d\n", gfn, slot);
     /* Notify policy of page being paged out */
-    policy_notify_paged_out(victim->gfn);
+    policy_notify_paged_out(gfn);
+
+    /* Update index */
+    paging->slot_to_gfn[slot] = gfn;
+    paging->gfn_to_slot[gfn] = slot;
 
     /* Record number of evicted pages */
     paging->num_paged_out++;
@@ -710,19 +719,19 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
-static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
+    unsigned long gfn;
     int j = 0;
     int ret;
 
     do
     {
-        ret = policy_choose_victim(paging, victim);
-        if ( ret != 0 )
+        gfn = policy_choose_victim(paging);
+        if ( gfn == INVALID_MFN )
         {
-            if ( ret != -ENOSPC )
-                ERROR("Error choosing victim");
+            ret = -ENOSPC;
             goto out;
         }
 
@@ -731,9 +740,9 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
+        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
+            ret = xenpaging_evict_page(paging, gfn, fd, slot);
         else
         {
             if ( j++ % 1000 == 0 )
@@ -743,7 +752,7 @@ static int evict_victim(struct xenpaging
     }
     while ( ret );
 
-    if ( test_and_set_bit(victim->gfn, paging->bitmap) )
+    if ( test_and_set_bit(gfn, paging->bitmap) )
         ERROR("Page has been evicted before");
 
     ret = 0;
@@ -753,7 +762,7 @@ static int evict_victim(struct xenpaging
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -761,10 +770,10 @@ static int evict_pages(struct xenpaging 
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
-        if ( victims[slot].gfn != INVALID_MFN )
+        if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, &victims[slot], fd, slot);
+        rc = evict_victim(paging, fd, slot);
         if ( rc == -ENOSPC )
             break;
         if ( rc == -EINTR )
@@ -780,11 +789,10 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
-    int i;
+    int slot;
     int tot_pages;
     int rc = -1;
     int rc1;
@@ -813,15 +821,6 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(struct victim));
-    if ( !victims )
-        goto out;
-
-    /* Mark all slots as unallocated */
-    for ( i = 0; i < paging->max_pages; i++ )
-        victims[i].gfn = INVALID_MFN;
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -853,32 +852,35 @@ int main(int argc, char *argv[])
         {
             get_request(&paging->mem_event, &req);
 
+            if ( req.gfn > paging->max_pages )
+            {
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %lx\n", req.gfn, paging->max_pages);
+                goto out;
+            }
+
             /* Check if the page has already been paged in */
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->max_pages; i++ )
+                slot = paging->gfn_to_slot[req.gfn];
+
+                /* Sanity check */
+                if ( paging->slot_to_gfn[slot] != req.gfn )
                 {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->max_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
                     goto out;
                 }
-                
+
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
-                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, slot);
                     /* Notify policy of page being dropped */
                     policy_notify_dropped(req.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, i);
+                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
                     if ( rc != 0 )
                     {
                         PERROR("Error populating page %"PRIx64"", req.gfn);
@@ -899,7 +901,7 @@ int main(int argc, char *argv[])
                 }
 
                 /* Clear this pagefile slot */
-                victims[i].gfn = INVALID_MFN;
+                paging->slot_to_gfn[slot] = 0;
             }
             else
             {
@@ -969,7 +971,7 @@ int main(int argc, char *argv[])
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
                 num = 42;
-            evict_pages(paging, fd, victims, num);
+            evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -989,7 +991,6 @@ int main(int argc, char *argv[])
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 0900b1c905f1 -r 4b2dbd2cb997 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -46,6 +46,9 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
+    unsigned long *slot_to_gfn;
+    int *gfn_to_slot;
+
     struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
@@ -56,13 +59,6 @@ struct xenpaging {
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 
-
-struct victim {
-    /* the gfn of the page to evict */
-    unsigned long gfn;
-};
-
-
 extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzaA1-0007LB-RC; Mon, 20 Feb 2012 20:48:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzaA0-0007Hu-EQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329770909!9889878!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11090 invoked from network); 20 Feb 2012 20:48:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770909; l=1071;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=PPrATZ649WU6RdLOpXw9Ccg2L18=;
	b=ExKTkf1A5+I4wenpDqTQa/+6m3f11IwlWAlllW5XMEzcXZ4MCE8Y/hFvx/kG0Ea2upL
	QzEddR0KqVdyp3zfeBcx5gj1+LtoYHilTFKaPZLnN92vEL9cYrJvI4hbMMYILK2cSVzni
	g62vgK9ciJ1tHAYTZ97L0OcEeMwyo5AJJbw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo5) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y03186o1KJqJnh
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:12 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 59E9418635
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:10 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 9] tools/xenpaging: cleanups and
	performance improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Series sent on 2012-01-31, now rebased to 24847:0900b1c905f1

This series adjusts the error reporting in the various code paths, with
the intention that fatal errors can be detected by callers and handled
properly. During my performance analysis with callgrind I found and
fixed a few bottlenecks in the page-in code paths.


Changes:
xenpaging: use flat index for pagefile and page-in requests
xenpaging: no poll timeout while page-out is in progress
xenpaging: reduce number of qemu cache flushes
xenpaging: move nominate+evict into single function
xenpaging: improve performance in policy_choose_victim
xenpaging: unify error handling
xenpaging: move pagefile filedescriptor into struct xenpaging
xenpaging: move page_buffer into struct xenpaging
xenpaging: implement stack of free slots in pagefile

 tools/xenpaging/policy.h         |    2 
 tools/xenpaging/policy_default.c |   63 ++++--
 tools/xenpaging/xenpaging.c      |  353 ++++++++++++++++++++++-----------------
 tools/xenpaging/xenpaging.h      |   16 -
 4 files changed, 261 insertions(+), 173 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzaA1-0007LB-RC; Mon, 20 Feb 2012 20:48:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzaA0-0007Hu-EQ
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329770909!9889878!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11090 invoked from network); 20 Feb 2012 20:48:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770909; l=1071;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=PPrATZ649WU6RdLOpXw9Ccg2L18=;
	b=ExKTkf1A5+I4wenpDqTQa/+6m3f11IwlWAlllW5XMEzcXZ4MCE8Y/hFvx/kG0Ea2upL
	QzEddR0KqVdyp3zfeBcx5gj1+LtoYHilTFKaPZLnN92vEL9cYrJvI4hbMMYILK2cSVzni
	g62vgK9ciJ1tHAYTZ97L0OcEeMwyo5AJJbw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo5) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y03186o1KJqJnh
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:12 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 59E9418635
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:10 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 9] tools/xenpaging: cleanups and
	performance improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Series sent on 2012-01-31, now rebased to 24847:0900b1c905f1

This series adjusts the error reporting in the various code paths, with
the intention that fatal errors can be detected by callers and handled
properly. During my performance analysis with callgrind I found and
fixed a few bottlenecks in the page-in code paths.


Changes:
xenpaging: use flat index for pagefile and page-in requests
xenpaging: no poll timeout while page-out is in progress
xenpaging: reduce number of qemu cache flushes
xenpaging: move nominate+evict into single function
xenpaging: improve performance in policy_choose_victim
xenpaging: unify error handling
xenpaging: move pagefile filedescriptor into struct xenpaging
xenpaging: move page_buffer into struct xenpaging
xenpaging: implement stack of free slots in pagefile

 tools/xenpaging/policy.h         |    2 
 tools/xenpaging/policy_default.c |   63 ++++--
 tools/xenpaging/xenpaging.c      |  353 ++++++++++++++++++++++-----------------
 tools/xenpaging/xenpaging.h      |   16 -
 4 files changed, 261 insertions(+), 173 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1RzaAC-0007Rf-8M; Mon, 20 Feb 2012 20:48:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzaAA-0007MV-7I
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329770918!12312017!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10594 invoked from network); 20 Feb 2012 20:48:38 -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; 20 Feb 2012 20:48:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770918; l=8834;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=CPVYHVe4R4T46+bc3LcAT2NMRCw=;
	b=dI0wy5rgzqJhZYTt7fvgnIk6TtSUhgvYq2dM9+AFCwIqZloK383nfUbGr55BM8BS17Q
	cHC+0K4r/5a4/UW6j3rDixzG9u3QsomSJoXOjtC00l7YEf2JNB3Q3V5yYjQC1ktweHr42
	BAcIXQdFmXrn0KisXLZP3lq0uuZYghq45Ig=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (cohen mo6) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z04efco1KI9wvy
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:18 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CB34C1863D
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e4b7da7e355998a404252777c274e8e149ce7a63
Message-Id: <e4b7da7e355998a40425.1329770888@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 9] xenpaging: unify error handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID e4b7da7e355998a404252777c274e8e149ce7a63
# Parent  58b9625f746a29db55429c337574f0852e21e06c
xenpaging: unify error handling

Update functions to return -1 on error, 0 on success.
Simplify init_page() and make sure errno is assigned.
Adjust PERROR/ERROR usage, use PERROR early because it overwrites errno.
Adjust xenpaging_populate_page() to handle gfn as unsigned long.

Update xenpaging exit code handling. xenpaging_teardown cant possible
fail. Adjust mainloop to indicate possible errors to final exit.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 58b9625f746a -r e4b7da7e3559 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -98,7 +98,7 @@ static int xenpaging_wait_for_event_or_t
             return 0;
 
         PERROR("Poll exited with an error");
-        return -errno;
+        return -1;
     }
 
     /* First check for guest shutdown */
@@ -116,6 +116,7 @@ static int xenpaging_wait_for_event_or_t
                 {
                     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
                     interrupted = SIGQUIT;
+                    /* No further poll result processing */
                     rc = 0;
                 }
             }
@@ -183,26 +184,20 @@ static int xenpaging_get_tot_pages(struc
 static void *init_page(void)
 {
     void *buffer;
-    int ret;
 
     /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
+    errno = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
+    if ( errno != 0 )
+        return NULL;
 
     /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
+    if ( mlock(buffer, PAGE_SIZE) < 0 )
+    {
+        free(buffer);
+        buffer = NULL;
+    }
 
     return buffer;
-
- out_init:
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
 }
 
 static void usage(void)
@@ -449,7 +444,7 @@ static struct xenpaging *xenpaging_init(
     paging_buffer = init_page();
     if ( !paging_buffer )
     {
-        ERROR("Creating page aligned load buffer");
+        PERROR("Creating page aligned load buffer");
         goto err;
     }
 
@@ -485,18 +480,14 @@ static struct xenpaging *xenpaging_init(
     return NULL;
 }
 
-static int xenpaging_teardown(struct xenpaging *paging)
+static void xenpaging_teardown(struct xenpaging *paging)
 {
     int rc;
-    xc_interface *xch;
-
-    if ( paging == NULL )
-        return 0;
+    xc_interface *xch = paging->xc_handle;
 
     xs_unwatch(paging->xs_handle, watch_target_tot_pages, "");
     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
 
-    xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
@@ -528,13 +519,8 @@ static int xenpaging_teardown(struct xen
     rc = xc_interface_close(xch);
     if ( rc != 0 )
     {
-        PERROR("Error closing connection to xen");
+        ERROR("Error closing connection to xen");
     }
-
-    return 0;
-
- err:
-    return -1;
 }
 
 static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
@@ -684,21 +670,19 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging,
-    xen_pfn_t gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
-    void *page;
     int ret;
     unsigned char oom = 0;
 
-    DPRINTF("populate_page < gfn %"PRI_xen_pfn" pageslot %d\n", gfn, i);
+    DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
     ret = read_page(fd, paging_buffer, i);
     if ( ret != 0 )
     {
-        ERROR("Error reading page");
+        PERROR("Error reading page");
         goto out;
     }
 
@@ -707,17 +691,18 @@ static int xenpaging_populate_page(struc
         /* Tell Xen to allocate a page for the domain */
         ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
                                     paging_buffer);
-        if ( ret != 0 )
+        if ( ret < 0 )
         {
             if ( errno == ENOMEM )
             {
                 if ( oom++ == 0 )
-                    DPRINTF("ENOMEM while preparing gfn %"PRI_xen_pfn"\n", gfn);
+                    DPRINTF("ENOMEM while preparing gfn %lx\n", gfn);
                 sleep(1);
                 continue;
             }
-            PERROR("Error loading %"PRI_xen_pfn" during page-in", gfn);
-            goto out;
+            PERROR("Error loading %lx during page-in", gfn);
+            ret = -1;
+            break;
         }
     }
     while ( ret && !interrupted );
@@ -748,6 +733,11 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
+/* Evict one gfn and write it to the given slot
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if no gfn can be evicted
+ */
 static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -771,13 +761,13 @@ static int evict_victim(struct xenpaging
                 xenpaging_mem_paging_flush_ioemu_cache(paging);
                 num_paged_out = paging->num_paged_out;
             }
-            ret = -ENOSPC;
+            ret = ENOSPC;
             goto out;
         }
 
         if ( interrupted )
         {
-            ret = -EINTR;
+            ret = EINTR;
             goto out;
         }
 
@@ -788,7 +778,7 @@ static int evict_victim(struct xenpaging
     while ( ret );
 
     if ( test_and_set_bit(gfn, paging->bitmap) )
-        ERROR("Page has been evicted before");
+        ERROR("Page %lx has been evicted before", gfn);
 
     ret = 0;
 
@@ -796,7 +786,11 @@ static int evict_victim(struct xenpaging
     return ret;
 }
 
-/* Evict a batch of pages and write them to a free slot in the paging file */
+/* Evict a batch of pages and write them to a free slot in the paging file
+ * Returns < 0 on fatal error
+ * Returns 0 if no gfn can be evicted
+ * Returns > 0 on successful evict
+ */
 static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
@@ -809,12 +803,12 @@ static int evict_pages(struct xenpaging 
             continue;
 
         rc = evict_victim(paging, fd, slot);
-        if ( rc == -ENOSPC )
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
             break;
-        if ( rc == -EINTR )
-            break;
-        if ( num && num % 100 == 0 )
-            DPRINTF("%d pages evicted\n", num);
+        }
+
         num++;
     }
     return num;
@@ -829,8 +823,7 @@ int main(int argc, char *argv[])
     int num, prev_num = 0;
     int slot;
     int tot_pages;
-    int rc = -1;
-    int rc1;
+    int rc;
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
@@ -875,7 +868,7 @@ int main(int argc, char *argv[])
         rc = xenpaging_wait_for_event_or_timeout(paging);
         if ( rc < 0 )
         {
-            PERROR("Error getting event");
+            ERROR("Error getting event");
             goto out;
         }
         else if ( rc != 0 )
@@ -885,6 +878,9 @@ int main(int argc, char *argv[])
 
         while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
         {
+            /* Indicate possible error */
+            rc = 1;
+
             get_request(&paging->mem_event, &req);
 
             if ( req.gfn > paging->max_pages )
@@ -915,10 +911,9 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
-                    if ( rc != 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
                     {
-                        PERROR("Error populating page %"PRIx64"", req.gfn);
+                        ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }
@@ -928,8 +923,7 @@ int main(int argc, char *argv[])
                 rsp.vcpu_id = req.vcpu_id;
                 rsp.flags = req.flags;
 
-                rc = xenpaging_resume_page(paging, &rsp, 1);
-                if ( rc != 0 )
+                if ( xenpaging_resume_page(paging, &rsp, 1) < 0 )
                 {
                     PERROR("Error resuming page %"PRIx64"", req.gfn);
                     goto out;
@@ -955,8 +949,7 @@ int main(int argc, char *argv[])
                     rsp.vcpu_id = req.vcpu_id;
                     rsp.flags = req.flags;
 
-                    rc = xenpaging_resume_page(paging, &rsp, 0);
-                    if ( rc != 0 )
+                    if ( xenpaging_resume_page(paging, &rsp, 0) < 0 )
                     {
                         PERROR("Error resuming page %"PRIx64"", req.gfn);
                         goto out;
@@ -983,6 +976,9 @@ int main(int argc, char *argv[])
         if ( interrupted )
             break;
 
+        /* Indicate possible error */
+        rc = 1;
+
         /* Check if the target has been reached already */
         tot_pages = xenpaging_get_tot_pages(paging);
         if ( tot_pages < 0 )
@@ -1009,7 +1005,8 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            evict_pages(paging, fd, num);
+            if ( evict_pages(paging, fd, num) < 0 )
+                goto out;
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -1029,6 +1026,10 @@ int main(int argc, char *argv[])
         }
 
     }
+
+    /* No error */
+    rc = 0;
+
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
@@ -1036,13 +1037,9 @@ int main(int argc, char *argv[])
     unlink_pagefile();
 
     /* Tear down domain paging */
-    rc1 = xenpaging_teardown(paging);
-    if ( rc1 != 0 )
-        fprintf(stderr, "Error tearing down paging");
+    xenpaging_teardown(paging);
 
-    if ( rc == 0 )
-        rc = rc1;
-    return rc;
+    return rc ? 2 : 0;
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20: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 1RzaAC-0007Rf-8M; Mon, 20 Feb 2012 20:48:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RzaAA-0007MV-7I
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329770918!12312017!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10594 invoked from network); 20 Feb 2012 20:48:38 -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; 20 Feb 2012 20:48:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770918; l=8834;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=CPVYHVe4R4T46+bc3LcAT2NMRCw=;
	b=dI0wy5rgzqJhZYTt7fvgnIk6TtSUhgvYq2dM9+AFCwIqZloK383nfUbGr55BM8BS17Q
	cHC+0K4r/5a4/UW6j3rDixzG9u3QsomSJoXOjtC00l7YEf2JNB3Q3V5yYjQC1ktweHr42
	BAcIXQdFmXrn0KisXLZP3lq0uuZYghq45Ig=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (cohen mo6) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z04efco1KI9wvy
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:18 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CB34C1863D
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e4b7da7e355998a404252777c274e8e149ce7a63
Message-Id: <e4b7da7e355998a40425.1329770888@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 9] xenpaging: unify error handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329769124 -3600
# Node ID e4b7da7e355998a404252777c274e8e149ce7a63
# Parent  58b9625f746a29db55429c337574f0852e21e06c
xenpaging: unify error handling

Update functions to return -1 on error, 0 on success.
Simplify init_page() and make sure errno is assigned.
Adjust PERROR/ERROR usage, use PERROR early because it overwrites errno.
Adjust xenpaging_populate_page() to handle gfn as unsigned long.

Update xenpaging exit code handling. xenpaging_teardown cant possible
fail. Adjust mainloop to indicate possible errors to final exit.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 58b9625f746a -r e4b7da7e3559 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -98,7 +98,7 @@ static int xenpaging_wait_for_event_or_t
             return 0;
 
         PERROR("Poll exited with an error");
-        return -errno;
+        return -1;
     }
 
     /* First check for guest shutdown */
@@ -116,6 +116,7 @@ static int xenpaging_wait_for_event_or_t
                 {
                     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
                     interrupted = SIGQUIT;
+                    /* No further poll result processing */
                     rc = 0;
                 }
             }
@@ -183,26 +184,20 @@ static int xenpaging_get_tot_pages(struc
 static void *init_page(void)
 {
     void *buffer;
-    int ret;
 
     /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
+    errno = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
+    if ( errno != 0 )
+        return NULL;
 
     /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
+    if ( mlock(buffer, PAGE_SIZE) < 0 )
+    {
+        free(buffer);
+        buffer = NULL;
+    }
 
     return buffer;
-
- out_init:
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
 }
 
 static void usage(void)
@@ -449,7 +444,7 @@ static struct xenpaging *xenpaging_init(
     paging_buffer = init_page();
     if ( !paging_buffer )
     {
-        ERROR("Creating page aligned load buffer");
+        PERROR("Creating page aligned load buffer");
         goto err;
     }
 
@@ -485,18 +480,14 @@ static struct xenpaging *xenpaging_init(
     return NULL;
 }
 
-static int xenpaging_teardown(struct xenpaging *paging)
+static void xenpaging_teardown(struct xenpaging *paging)
 {
     int rc;
-    xc_interface *xch;
-
-    if ( paging == NULL )
-        return 0;
+    xc_interface *xch = paging->xc_handle;
 
     xs_unwatch(paging->xs_handle, watch_target_tot_pages, "");
     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
 
-    xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
@@ -528,13 +519,8 @@ static int xenpaging_teardown(struct xen
     rc = xc_interface_close(xch);
     if ( rc != 0 )
     {
-        PERROR("Error closing connection to xen");
+        ERROR("Error closing connection to xen");
     }
-
-    return 0;
-
- err:
-    return -1;
 }
 
 static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
@@ -684,21 +670,19 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging,
-    xen_pfn_t gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
-    void *page;
     int ret;
     unsigned char oom = 0;
 
-    DPRINTF("populate_page < gfn %"PRI_xen_pfn" pageslot %d\n", gfn, i);
+    DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
     ret = read_page(fd, paging_buffer, i);
     if ( ret != 0 )
     {
-        ERROR("Error reading page");
+        PERROR("Error reading page");
         goto out;
     }
 
@@ -707,17 +691,18 @@ static int xenpaging_populate_page(struc
         /* Tell Xen to allocate a page for the domain */
         ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
                                     paging_buffer);
-        if ( ret != 0 )
+        if ( ret < 0 )
         {
             if ( errno == ENOMEM )
             {
                 if ( oom++ == 0 )
-                    DPRINTF("ENOMEM while preparing gfn %"PRI_xen_pfn"\n", gfn);
+                    DPRINTF("ENOMEM while preparing gfn %lx\n", gfn);
                 sleep(1);
                 continue;
             }
-            PERROR("Error loading %"PRI_xen_pfn" during page-in", gfn);
-            goto out;
+            PERROR("Error loading %lx during page-in", gfn);
+            ret = -1;
+            break;
         }
     }
     while ( ret && !interrupted );
@@ -748,6 +733,11 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
+/* Evict one gfn and write it to the given slot
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if no gfn can be evicted
+ */
 static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -771,13 +761,13 @@ static int evict_victim(struct xenpaging
                 xenpaging_mem_paging_flush_ioemu_cache(paging);
                 num_paged_out = paging->num_paged_out;
             }
-            ret = -ENOSPC;
+            ret = ENOSPC;
             goto out;
         }
 
         if ( interrupted )
         {
-            ret = -EINTR;
+            ret = EINTR;
             goto out;
         }
 
@@ -788,7 +778,7 @@ static int evict_victim(struct xenpaging
     while ( ret );
 
     if ( test_and_set_bit(gfn, paging->bitmap) )
-        ERROR("Page has been evicted before");
+        ERROR("Page %lx has been evicted before", gfn);
 
     ret = 0;
 
@@ -796,7 +786,11 @@ static int evict_victim(struct xenpaging
     return ret;
 }
 
-/* Evict a batch of pages and write them to a free slot in the paging file */
+/* Evict a batch of pages and write them to a free slot in the paging file
+ * Returns < 0 on fatal error
+ * Returns 0 if no gfn can be evicted
+ * Returns > 0 on successful evict
+ */
 static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
@@ -809,12 +803,12 @@ static int evict_pages(struct xenpaging 
             continue;
 
         rc = evict_victim(paging, fd, slot);
-        if ( rc == -ENOSPC )
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
             break;
-        if ( rc == -EINTR )
-            break;
-        if ( num && num % 100 == 0 )
-            DPRINTF("%d pages evicted\n", num);
+        }
+
         num++;
     }
     return num;
@@ -829,8 +823,7 @@ int main(int argc, char *argv[])
     int num, prev_num = 0;
     int slot;
     int tot_pages;
-    int rc = -1;
-    int rc1;
+    int rc;
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
@@ -875,7 +868,7 @@ int main(int argc, char *argv[])
         rc = xenpaging_wait_for_event_or_timeout(paging);
         if ( rc < 0 )
         {
-            PERROR("Error getting event");
+            ERROR("Error getting event");
             goto out;
         }
         else if ( rc != 0 )
@@ -885,6 +878,9 @@ int main(int argc, char *argv[])
 
         while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
         {
+            /* Indicate possible error */
+            rc = 1;
+
             get_request(&paging->mem_event, &req);
 
             if ( req.gfn > paging->max_pages )
@@ -915,10 +911,9 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
-                    if ( rc != 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
                     {
-                        PERROR("Error populating page %"PRIx64"", req.gfn);
+                        ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }
@@ -928,8 +923,7 @@ int main(int argc, char *argv[])
                 rsp.vcpu_id = req.vcpu_id;
                 rsp.flags = req.flags;
 
-                rc = xenpaging_resume_page(paging, &rsp, 1);
-                if ( rc != 0 )
+                if ( xenpaging_resume_page(paging, &rsp, 1) < 0 )
                 {
                     PERROR("Error resuming page %"PRIx64"", req.gfn);
                     goto out;
@@ -955,8 +949,7 @@ int main(int argc, char *argv[])
                     rsp.vcpu_id = req.vcpu_id;
                     rsp.flags = req.flags;
 
-                    rc = xenpaging_resume_page(paging, &rsp, 0);
-                    if ( rc != 0 )
+                    if ( xenpaging_resume_page(paging, &rsp, 0) < 0 )
                     {
                         PERROR("Error resuming page %"PRIx64"", req.gfn);
                         goto out;
@@ -983,6 +976,9 @@ int main(int argc, char *argv[])
         if ( interrupted )
             break;
 
+        /* Indicate possible error */
+        rc = 1;
+
         /* Check if the target has been reached already */
         tot_pages = xenpaging_get_tot_pages(paging);
         if ( tot_pages < 0 )
@@ -1009,7 +1005,8 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            evict_pages(paging, fd, num);
+            if ( evict_pages(paging, fd, num) < 0 )
+                goto out;
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -1029,6 +1026,10 @@ int main(int argc, char *argv[])
         }
 
     }
+
+    /* No error */
+    rc = 0;
+
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
@@ -1036,13 +1037,9 @@ int main(int argc, char *argv[])
     unlink_pagefile();
 
     /* Tear down domain paging */
-    rc1 = xenpaging_teardown(paging);
-    if ( rc1 != 0 )
-        fprintf(stderr, "Error tearing down paging");
+    xenpaging_teardown(paging);
 
-    if ( rc == 0 )
-        rc = rc1;
-    return rc;
+    return rc ? 2 : 0;
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzaAF-0007UD-Rz; Mon, 20 Feb 2012 20:48:51 +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 1RzaAE-0007RE-8B
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329770878!60905900!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTk1NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTk1NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24286 invoked from network); 20 Feb 2012 20:48:00 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770924; l=4898;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=A6Xs6jPpb3mVYVEy6ahzQEpcWyU=;
	b=v8gq9eRfdrgq1ENKTeIc2lhWWkbIhhNF/2KFz8ToqzHNMkp2xKcq5udiIuODvJUqN5M
	M1ORjZ3/o643qWOKCFsOM4GalVmTC785HwBuLkpDnYU8XU4rC7QmAiLP9+6MXlqSILkHf
	hU1BVloY+F4svpLYIDbEnzlcr9KGADG1XG0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo31) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e0247co1KJr1KR
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5CFA718635
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:13 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c137d7bd207b7b21d69bd6470be285023a4c2baf
Message-Id: <c137d7bd207b7b21d69b.1329770889@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 7 of 9] xenpaging: move pagefile filedescriptor
 into struct xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID c137d7bd207b7b21d69bd6470be285023a4c2baf
# Parent  e4b7da7e355998a404252777c274e8e149ce7a63
xenpaging: move pagefile filedescriptor into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e4b7da7e3559 -r c137d7bd207b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -448,6 +448,14 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
+    /* Open file */
+    paging->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR, S_IRUSR | S_IWUSR);
+    if ( paging->fd < 0 )
+    {
+        PERROR("failed to open file");
+        goto err;
+    }
+
     return paging;
 
  err:
@@ -562,7 +570,7 @@ static void put_response(struct mem_even
  * Returns 0 on successful evict
  * Returns > 0 if gfn can not be evicted
  */
-static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -593,7 +601,7 @@ static int xenpaging_evict_page(struct x
     }
 
     /* Copy page */
-    ret = write_page(fd, page, slot);
+    ret = write_page(paging->fd, page, slot);
     if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
@@ -670,7 +678,7 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int ret;
@@ -679,7 +687,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -738,7 +746,7 @@ static void resume_pages(struct xenpagin
  * Returns 0 on successful evict
  * Returns > 0 if no gfn can be evicted
  */
-static int evict_victim(struct xenpaging *paging, int fd, int slot)
+static int evict_victim(struct xenpaging *paging, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
@@ -771,7 +779,7 @@ static int evict_victim(struct xenpaging
             goto out;
         }
 
-        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        ret = xenpaging_evict_page(paging, gfn, slot);
         if ( ret < 0 )
             goto out;
     }
@@ -791,7 +799,7 @@ static int evict_victim(struct xenpaging
  * Returns 0 if no gfn can be evicted
  * Returns > 0 on successful evict
  */
-static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
+static int evict_pages(struct xenpaging *paging, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -802,7 +810,7 @@ static int evict_pages(struct xenpaging 
         if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, fd, slot);
+        rc = evict_victim(paging, slot);
         if ( rc )
         {
             num = rc < 0 ? -1 : num;
@@ -826,10 +834,6 @@ int main(int argc, char *argv[])
     int rc;
     xc_interface *xch;
 
-    int open_flags = O_CREAT | O_TRUNC | O_RDWR;
-    mode_t open_mode = S_IRUSR | S_IWUSR;
-    int fd;
-
     /* Initialise domain paging */
     paging = xenpaging_init(argc, argv);
     if ( paging == NULL )
@@ -841,14 +845,6 @@ int main(int argc, char *argv[])
 
     DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
 
-    /* Open file */
-    fd = open(filename, open_flags, open_mode);
-    if ( fd < 0 )
-    {
-        perror("failed to open file");
-        return 2;
-    }
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -911,7 +907,7 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, slot) < 0 )
                     {
                         ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
@@ -1005,7 +1001,7 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            if ( evict_pages(paging, fd, num) < 0 )
+            if ( evict_pages(paging, num) < 0 )
                 goto out;
         }
         /* Resume some pages if target not reached */
@@ -1033,7 +1029,7 @@ int main(int argc, char *argv[])
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
-    close(fd);
+    close(paging->fd);
     unlink_pagefile();
 
     /* Tear down domain paging */
diff -r e4b7da7e3559 -r c137d7bd207b tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -50,6 +50,7 @@ struct xenpaging {
     int *gfn_to_slot;
 
     struct mem_event mem_event;
+    int fd;
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 20:48:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 20:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzaAF-0007UD-Rz; Mon, 20 Feb 2012 20:48:51 +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 1RzaAE-0007RE-8B
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 20:48:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329770878!60905900!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTk1NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTk1NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24286 invoked from network); 20 Feb 2012 20:48:00 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 20:48:00 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329770924; l=4898;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=A6Xs6jPpb3mVYVEy6ahzQEpcWyU=;
	b=v8gq9eRfdrgq1ENKTeIc2lhWWkbIhhNF/2KFz8ToqzHNMkp2xKcq5udiIuODvJUqN5M
	M1ORjZ3/o643qWOKCFsOM4GalVmTC785HwBuLkpDnYU8XU4rC7QmAiLP9+6MXlqSILkHf
	hU1BVloY+F4svpLYIDbEnzlcr9KGADG1XG0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (fruni mo31) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e0247co1KJr1KR
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5CFA718635
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 21:48:13 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c137d7bd207b7b21d69bd6470be285023a4c2baf
Message-Id: <c137d7bd207b7b21d69b.1329770889@probook.site>
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 21:48:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 7 of 9] xenpaging: move pagefile filedescriptor
 into struct xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329769124 -3600
# Node ID c137d7bd207b7b21d69bd6470be285023a4c2baf
# Parent  e4b7da7e355998a404252777c274e8e149ce7a63
xenpaging: move pagefile filedescriptor into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e4b7da7e3559 -r c137d7bd207b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -448,6 +448,14 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
+    /* Open file */
+    paging->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR, S_IRUSR | S_IWUSR);
+    if ( paging->fd < 0 )
+    {
+        PERROR("failed to open file");
+        goto err;
+    }
+
     return paging;
 
  err:
@@ -562,7 +570,7 @@ static void put_response(struct mem_even
  * Returns 0 on successful evict
  * Returns > 0 if gfn can not be evicted
  */
-static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -593,7 +601,7 @@ static int xenpaging_evict_page(struct x
     }
 
     /* Copy page */
-    ret = write_page(fd, page, slot);
+    ret = write_page(paging->fd, page, slot);
     if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
@@ -670,7 +678,7 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int ret;
@@ -679,7 +687,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -738,7 +746,7 @@ static void resume_pages(struct xenpagin
  * Returns 0 on successful evict
  * Returns > 0 if no gfn can be evicted
  */
-static int evict_victim(struct xenpaging *paging, int fd, int slot)
+static int evict_victim(struct xenpaging *paging, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
@@ -771,7 +779,7 @@ static int evict_victim(struct xenpaging
             goto out;
         }
 
-        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        ret = xenpaging_evict_page(paging, gfn, slot);
         if ( ret < 0 )
             goto out;
     }
@@ -791,7 +799,7 @@ static int evict_victim(struct xenpaging
  * Returns 0 if no gfn can be evicted
  * Returns > 0 on successful evict
  */
-static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
+static int evict_pages(struct xenpaging *paging, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -802,7 +810,7 @@ static int evict_pages(struct xenpaging 
         if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, fd, slot);
+        rc = evict_victim(paging, slot);
         if ( rc )
         {
             num = rc < 0 ? -1 : num;
@@ -826,10 +834,6 @@ int main(int argc, char *argv[])
     int rc;
     xc_interface *xch;
 
-    int open_flags = O_CREAT | O_TRUNC | O_RDWR;
-    mode_t open_mode = S_IRUSR | S_IWUSR;
-    int fd;
-
     /* Initialise domain paging */
     paging = xenpaging_init(argc, argv);
     if ( paging == NULL )
@@ -841,14 +845,6 @@ int main(int argc, char *argv[])
 
     DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
 
-    /* Open file */
-    fd = open(filename, open_flags, open_mode);
-    if ( fd < 0 )
-    {
-        perror("failed to open file");
-        return 2;
-    }
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -911,7 +907,7 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, slot) < 0 )
                     {
                         ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
@@ -1005,7 +1001,7 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            if ( evict_pages(paging, fd, num) < 0 )
+            if ( evict_pages(paging, num) < 0 )
                 goto out;
         }
         /* Resume some pages if target not reached */
@@ -1033,7 +1029,7 @@ int main(int argc, char *argv[])
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
-    close(fd);
+    close(paging->fd);
     unlink_pagefile();
 
     /* Tear down domain paging */
diff -r e4b7da7e3559 -r c137d7bd207b tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -50,6 +50,7 @@ struct xenpaging {
     int *gfn_to_slot;
 
     struct mem_event mem_event;
+    int fd;
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 21:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 21: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 1Rzacj-0000TV-Fv; Mon, 20 Feb 2012 21:18:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzaci-0000Sr-L1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 21:18:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329772688!2789170!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27204 invoked from network); 20 Feb 2012 21:18:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 21:18:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329772688; l=2661;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=UlsjjDcvA3dtaYKHzcU25sY2sLo=;
	b=LTV9erc9LvtZvx8TdJjIR8yxqldg2n3WPZewnopom/ONrvWkEggvFfYjW6pugpr4nb2
	NEanEa5JYe/zNONcSHrk1JD/6leX1nh4PTIqz2O6im7XVPvSEGSrsp3pJgQNFJG46/AhM
	Ne8bJiusj+KFlWt5b6HKUmlU0zt1DRJONzE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by post.strato.de (mrclete mo26) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t0555fo1KLC3TL
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:06 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2471418639
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: fcb66fe4134321fa089132ee0e9b24e21600404c
Message-Id: <fcb66fe4134321fa0891.1329772682@probook.site>
In-Reply-To: <patchbomb.1329772680@probook.site>
References: <patchbomb.1329772680@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 22:18:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] mem_event: use C99 initializers for
 mem_event_request_t users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329772592 -3600
# Node ID fcb66fe4134321fa089132ee0e9b24e21600404c
# Parent  e1a866546aef8ec1395858c4d2c8f28ff0d0502f
mem_event: use C99 initializers for mem_event_request_t users

Use C99 initializers for mem_event_request_t users to make sure req is
always cleared, even with local debug patches that shuffle code around
to have a single exit point.
The common case is to use and send req, so it does not add significant
overhead to always clear req.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e1a866546aef -r fcb66fe41343 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4302,7 +4302,7 @@ static int hvm_memory_event_traps(long p
 {
     struct vcpu* v = current;
     struct domain *d = v->domain;
-    mem_event_request_t req;
+    mem_event_request_t req = { .reason = reason };
     int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
@@ -4321,9 +4321,6 @@ static int hvm_memory_event_traps(long p
     else if ( rc < 0 )
         return rc;
 
-    memset(&req, 0, sizeof(req));
-    req.reason = reason;
-
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
     {
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
diff -r e1a866546aef -r fcb66fe41343 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -913,7 +913,7 @@ int p2m_mem_paging_evict(struct domain *
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
                                 p2m_type_t p2mt)
 {
-    mem_event_request_t req;
+    mem_event_request_t req = { .gfn = gfn };
 
     /* We allow no ring in this unique case, because it won't affect
      * correctness of the guest execution at this point.  If this is the only
@@ -924,8 +924,6 @@ void p2m_mem_paging_drop_page(struct dom
         return;
 
     /* Send release notification to pager */
-    memset(&req, 0, sizeof(req));
-    req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
     /* Update stats unless the page hasn't yet been evicted */
@@ -962,7 +960,7 @@ void p2m_mem_paging_drop_page(struct dom
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .gfn = gfn };
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -980,8 +978,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( rc < 0 )
         return;
 
-    memset(&req, 0, sizeof(req));
-
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -1011,7 +1007,6 @@ void p2m_mem_paging_populate(struct doma
     }
 
     /* Send request to pager */
-    req.gfn = gfn;
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 21:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 21: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 1Rzacj-0000TV-Fv; Mon, 20 Feb 2012 21:18:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzaci-0000Sr-L1
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 21:18:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329772688!2789170!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27204 invoked from network); 20 Feb 2012 21:18:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Feb 2012 21:18:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329772688; l=2661;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=UlsjjDcvA3dtaYKHzcU25sY2sLo=;
	b=LTV9erc9LvtZvx8TdJjIR8yxqldg2n3WPZewnopom/ONrvWkEggvFfYjW6pugpr4nb2
	NEanEa5JYe/zNONcSHrk1JD/6leX1nh4PTIqz2O6im7XVPvSEGSrsp3pJgQNFJG46/AhM
	Ne8bJiusj+KFlWt5b6HKUmlU0zt1DRJONzE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by post.strato.de (mrclete mo26) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t0555fo1KLC3TL
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:06 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2471418639
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: fcb66fe4134321fa089132ee0e9b24e21600404c
Message-Id: <fcb66fe4134321fa0891.1329772682@probook.site>
In-Reply-To: <patchbomb.1329772680@probook.site>
References: <patchbomb.1329772680@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 22:18:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] mem_event: use C99 initializers for
 mem_event_request_t users
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1329772592 -3600
# Node ID fcb66fe4134321fa089132ee0e9b24e21600404c
# Parent  e1a866546aef8ec1395858c4d2c8f28ff0d0502f
mem_event: use C99 initializers for mem_event_request_t users

Use C99 initializers for mem_event_request_t users to make sure req is
always cleared, even with local debug patches that shuffle code around
to have a single exit point.
The common case is to use and send req, so it does not add significant
overhead to always clear req.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e1a866546aef -r fcb66fe41343 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4302,7 +4302,7 @@ static int hvm_memory_event_traps(long p
 {
     struct vcpu* v = current;
     struct domain *d = v->domain;
-    mem_event_request_t req;
+    mem_event_request_t req = { .reason = reason };
     int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
@@ -4321,9 +4321,6 @@ static int hvm_memory_event_traps(long p
     else if ( rc < 0 )
         return rc;
 
-    memset(&req, 0, sizeof(req));
-    req.reason = reason;
-
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
     {
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
diff -r e1a866546aef -r fcb66fe41343 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -913,7 +913,7 @@ int p2m_mem_paging_evict(struct domain *
 void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn,
                                 p2m_type_t p2mt)
 {
-    mem_event_request_t req;
+    mem_event_request_t req = { .gfn = gfn };
 
     /* We allow no ring in this unique case, because it won't affect
      * correctness of the guest execution at this point.  If this is the only
@@ -924,8 +924,6 @@ void p2m_mem_paging_drop_page(struct dom
         return;
 
     /* Send release notification to pager */
-    memset(&req, 0, sizeof(req));
-    req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
     /* Update stats unless the page hasn't yet been evicted */
@@ -962,7 +960,7 @@ void p2m_mem_paging_drop_page(struct dom
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req;
+    mem_event_request_t req = { .gfn = gfn };
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -980,8 +978,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( rc < 0 )
         return;
 
-    memset(&req, 0, sizeof(req));
-
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
@@ -1011,7 +1007,6 @@ void p2m_mem_paging_populate(struct doma
     }
 
     /* Send request to pager */
-    req.gfn = gfn;
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 21:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 21: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 1Rzacl-0000Tq-SW; Mon, 20 Feb 2012 21:18:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzack-0000T4-DX
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 21:18:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329772691!15095854!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13549 invoked from network); 20 Feb 2012 21:18:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2012 21:18:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329772691; l=3869;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=9a3iLpZGMr6Wr0E9FyF03RbhO5k=;
	b=JnpegOlOCMla7dNEG3AlDeEirx4eGBE211uxJ/W8Ask/ZcW2+bgUIenJJD5Aaym0alO
	2Jo3ESwCgsvdLzWLKBvZGu5BjpL33mnbNmbaD6ZHKHpInqh0atSsCBew8BvJwg/SnlEQi
	OPmmDCY31DQfFSYSFC2gRuSv+Mu0oVlictE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (cohen mo50) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z048a8o1KJiqfe
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B959018638
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e1a866546aef8ec1395858c4d2c8f28ff0d0502f
Message-Id: <e1a866546aef8ec13958.1329772681@probook.site>
In-Reply-To: <patchbomb.1329772680@probook.site>
References: <patchbomb.1329772680@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 22:18:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] mem_event: remove type 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>
Content-Type: text/plain; charset="us-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 1329772180 -3600
# Node ID e1a866546aef8ec1395858c4d2c8f28ff0d0502f
# Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
mem_event: remove type member

When mem_event was added the type flag should indicate who the consumer
is. But the concept of a single ring buffer for multiple event types can
not work for two reasons. One is that no multiplexer exists which
provides individual event types to the final consumer, and second is
that even if such multiplexer can not work reliable because a request
needs to be answered with a response. The response should be sent
roughly in the order of received events. But with multiple consumers one
of them can so stall all the others.

For that reason the single mem_event buffer for all types of events was
split into individual ring buffers with commit 23842:483c5f8319ad. This
commit made the type member already obsolete because the meaning of each
buffer is now obvious.

This change removes the type member and increases the flags field.

Even though this is an ABI incompatible change, it will have no practical
impact on existing binaries because the changeset referenced above already
bumped the SONAME. So these binaries have to be recompiled anyway for the
upcoming major release.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0900b1c905f1 -r e1a866546aef xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4322,7 +4322,6 @@ static int hvm_memory_event_traps(long p
         return rc;
 
     memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
 
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
diff -r 0900b1c905f1 -r e1a866546aef xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -347,7 +347,7 @@ int mem_sharing_audit(void)
 static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
+    mem_event_request_t req = { .gfn = gfn };
 
     if ( v->domain != d )
     {
@@ -369,7 +369,6 @@ static void mem_sharing_notify_helper(st
     req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     vcpu_pause_nosync(v);
 
-    req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
diff -r 0900b1c905f1 -r e1a866546aef xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -925,7 +925,6 @@ void p2m_mem_paging_drop_page(struct dom
 
     /* Send release notification to pager */
     memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
     req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
@@ -982,7 +981,6 @@ void p2m_mem_paging_populate(struct doma
         return;
 
     memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
 
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
@@ -1221,7 +1219,6 @@ bool_t p2m_mem_access_check(unsigned lon
     {
         *req_ptr = req;
         memset(req, 0, sizeof(req));
-        req->type = MEM_EVENT_TYPE_ACCESS;
         req->reason = MEM_EVENT_REASON_VIOLATION;
 
         /* Pause the current VCPU */
diff -r 0900b1c905f1 -r e1a866546aef xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -30,11 +30,6 @@
 #include "xen.h"
 #include "io/ring.h"
 
-/* Memory event type */
-#define MEM_EVENT_TYPE_SHARED   0
-#define MEM_EVENT_TYPE_PAGING   1
-#define MEM_EVENT_TYPE_ACCESS   2
-
 /* Memory event flags */
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
@@ -56,8 +51,7 @@ typedef struct mem_event_shared_page {
 } mem_event_shared_page_t;
 
 typedef struct mem_event_st {
-    uint16_t type;
-    uint16_t flags;
+    uint32_t flags;
     uint32_t vcpu_id;
 
     uint64_t gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 21:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 21: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 1Rzacl-0000Tq-SW; Mon, 20 Feb 2012 21:18:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzack-0000T4-DX
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 21:18:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329772691!15095854!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13549 invoked from network); 20 Feb 2012 21:18:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2012 21:18:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329772691; l=3869;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=9a3iLpZGMr6Wr0E9FyF03RbhO5k=;
	b=JnpegOlOCMla7dNEG3AlDeEirx4eGBE211uxJ/W8Ask/ZcW2+bgUIenJJD5Aaym0alO
	2Jo3ESwCgsvdLzWLKBvZGu5BjpL33mnbNmbaD6ZHKHpInqh0atSsCBew8BvJwg/SnlEQi
	OPmmDCY31DQfFSYSFC2gRuSv+Mu0oVlictE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (cohen mo50) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z048a8o1KJiqfe
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B959018638
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:02 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e1a866546aef8ec1395858c4d2c8f28ff0d0502f
Message-Id: <e1a866546aef8ec13958.1329772681@probook.site>
In-Reply-To: <patchbomb.1329772680@probook.site>
References: <patchbomb.1329772680@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 22:18:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] mem_event: remove type 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>
Content-Type: text/plain; charset="us-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 1329772180 -3600
# Node ID e1a866546aef8ec1395858c4d2c8f28ff0d0502f
# Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
mem_event: remove type member

When mem_event was added the type flag should indicate who the consumer
is. But the concept of a single ring buffer for multiple event types can
not work for two reasons. One is that no multiplexer exists which
provides individual event types to the final consumer, and second is
that even if such multiplexer can not work reliable because a request
needs to be answered with a response. The response should be sent
roughly in the order of received events. But with multiple consumers one
of them can so stall all the others.

For that reason the single mem_event buffer for all types of events was
split into individual ring buffers with commit 23842:483c5f8319ad. This
commit made the type member already obsolete because the meaning of each
buffer is now obvious.

This change removes the type member and increases the flags field.

Even though this is an ABI incompatible change, it will have no practical
impact on existing binaries because the changeset referenced above already
bumped the SONAME. So these binaries have to be recompiled anyway for the
upcoming major release.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0900b1c905f1 -r e1a866546aef xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4322,7 +4322,6 @@ static int hvm_memory_event_traps(long p
         return rc;
 
     memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
 
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
diff -r 0900b1c905f1 -r e1a866546aef xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -347,7 +347,7 @@ int mem_sharing_audit(void)
 static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
-    mem_event_request_t req = { .type = MEM_EVENT_TYPE_SHARED };
+    mem_event_request_t req = { .gfn = gfn };
 
     if ( v->domain != d )
     {
@@ -369,7 +369,6 @@ static void mem_sharing_notify_helper(st
     req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     vcpu_pause_nosync(v);
 
-    req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->share, &req);
diff -r 0900b1c905f1 -r e1a866546aef xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -925,7 +925,6 @@ void p2m_mem_paging_drop_page(struct dom
 
     /* Send release notification to pager */
     memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
     req.gfn = gfn;
     req.flags = MEM_EVENT_FLAG_DROP_PAGE;
 
@@ -982,7 +981,6 @@ void p2m_mem_paging_populate(struct doma
         return;
 
     memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_PAGING;
 
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
@@ -1221,7 +1219,6 @@ bool_t p2m_mem_access_check(unsigned lon
     {
         *req_ptr = req;
         memset(req, 0, sizeof(req));
-        req->type = MEM_EVENT_TYPE_ACCESS;
         req->reason = MEM_EVENT_REASON_VIOLATION;
 
         /* Pause the current VCPU */
diff -r 0900b1c905f1 -r e1a866546aef xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -30,11 +30,6 @@
 #include "xen.h"
 #include "io/ring.h"
 
-/* Memory event type */
-#define MEM_EVENT_TYPE_SHARED   0
-#define MEM_EVENT_TYPE_PAGING   1
-#define MEM_EVENT_TYPE_ACCESS   2
-
 /* Memory event flags */
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
@@ -56,8 +51,7 @@ typedef struct mem_event_shared_page {
 } mem_event_shared_page_t;
 
 typedef struct mem_event_st {
-    uint16_t type;
-    uint16_t flags;
+    uint32_t flags;
     uint32_t vcpu_id;
 
     uint64_t gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 21:18:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 21:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzacp-0000Ue-9o; Mon, 20 Feb 2012 21:18:23 +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 1Rzacn-0000UD-Pf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 21:18:21 +0000
Received: from [85.158.139.83:57301] by server-2.bemta-5.messagelabs.com id
	38/C6-20263-D98B24F4; Mon, 20 Feb 2012 21:18:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329772699!15866706!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4255 invoked from network); 20 Feb 2012 21:18:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 21:18:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329772699; l=612;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qoizkI8g2BmAXddv/lmYsKf0H1g=;
	b=Aqmt6IHEcWU4rQYDZTVEEC0uBAqGNv/c5NYWDc7m/h6izu5swBTXp6HagzCU6zGg25h
	NImolbb4Fit0a4SWQdcSlmSfZyA28DxEI+R9oiz6hKjXmFRJYEMdkI2JRMUAwR6NBBYyt
	jmeP5ZP8dC+qs1V26/rtQgLvNjVSrDRNRto=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (jimi mo54) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N0296ao1KJxLgs
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 50A9A18635
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:02 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1329772680@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 22:18:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] remove type from mem_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


The intention of the first patch was to shrink mem_event_st to make room
for more events in the ring buffer. But since type is just u16 and the
struct would need much more shrinking to get more events per ring this
goal was not reached.

Now both patches just serve as cleanup.


Changes:
mem_event: remove type member
mem_event: use C99 initializers for mem_event_request_t users

 xen/arch/x86/hvm/hvm.c         |    6 +-----
 xen/arch/x86/mm/mem_sharing.c  |    3 +--
 xen/arch/x86/mm/p2m.c          |   12 ++----------
 xen/include/public/mem_event.h |    8 +-------
 4 files changed, 5 insertions(+), 24 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 21:18:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 21:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzacp-0000Ue-9o; Mon, 20 Feb 2012 21:18:23 +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 1Rzacn-0000UD-Pf
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 21:18:21 +0000
Received: from [85.158.139.83:57301] by server-2.bemta-5.messagelabs.com id
	38/C6-20263-D98B24F4; Mon, 20 Feb 2012 21:18:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329772699!15866706!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTg2NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4255 invoked from network); 20 Feb 2012 21:18:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 21:18:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329772699; l=612;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qoizkI8g2BmAXddv/lmYsKf0H1g=;
	b=Aqmt6IHEcWU4rQYDZTVEEC0uBAqGNv/c5NYWDc7m/h6izu5swBTXp6HagzCU6zGg25h
	NImolbb4Fit0a4SWQdcSlmSfZyA28DxEI+R9oiz6hKjXmFRJYEMdkI2JRMUAwR6NBBYyt
	jmeP5ZP8dC+qs1V26/rtQgLvNjVSrDRNRto=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6KE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-2.vodafone-net.de [80.226.24.2])
	by smtp.strato.de (jimi mo54) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N0296ao1KJxLgs
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:04 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 50A9A18635
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:18:02 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1329772680@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 20 Feb 2012 22:18:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] remove type from mem_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


The intention of the first patch was to shrink mem_event_st to make room
for more events in the ring buffer. But since type is just u16 and the
struct would need much more shrinking to get more events per ring this
goal was not reached.

Now both patches just serve as cleanup.


Changes:
mem_event: remove type member
mem_event: use C99 initializers for mem_event_request_t users

 xen/arch/x86/hvm/hvm.c         |    6 +-----
 xen/arch/x86/mm/mem_sharing.c  |    3 +--
 xen/arch/x86/mm/p2m.c          |   12 ++----------
 xen/include/public/mem_event.h |    8 +-------
 4 files changed, 5 insertions(+), 24 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 22:28:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 22:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzbhn-00027c-Lf; Mon, 20 Feb 2012 22:27:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rzbhm-00027X-4X
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 22:27:34 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329776795!55031322!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30439 invoked from network); 20 Feb 2012 22:26:37 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 22:26:37 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1KMROGn031899
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 14:27:25 -0800
Received: by bkue19 with SMTP id e19so5758637bku.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 14:27:23 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.152.193 as permitted sender) client-ip=10.204.152.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.152.193 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.152.193])
	by 10.204.152.193 with SMTP id h1mr11774652bkw.85.1329776843379
	(num_hops = 1); Mon, 20 Feb 2012 14:27:23 -0800 (PST)
Received: by 10.204.152.193 with SMTP id h1mr9488364bkw.85.1329776843291; Mon,
	20 Feb 2012 14:27:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 20 Feb 2012 14:26:43 -0800 (PST)
In-Reply-To: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 20 Feb 2012 14:26:43 -0800
Message-ID: <CAP8mzPPWzutOx=RKO_kGrvvswCEa=j_qmOu9QRyTfu6qu=4wDw@mail.gmail.com>
To: stefano.stabellini@eu.citrix.com
Cc: brendan@cs.ubc.ca, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6648295739933687766=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6648295739933687766==
Content-Type: multipart/alternative; boundary=0015175d079a5ffe2c04b96ccce3

--0015175d079a5ffe2c04b96ccce3
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 20, 2012 at 12:02 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:
>
>> rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support
>> suspend_cancel in domain_resume"):
>> > libxl: support suspend_cancel in domain_resume
>>
>> I get this:
>>
>> libxl.c: In function 'libxl_domain_resume':
>> libxl.c:315: error: implicit declaration of function
>> 'libxl__domain_resume_device_model'
>>
>> Did you compile this ?  Did you test it ?
>>
>>
> Yes I did.. Did you apply the previous patch in this series, that
> introduces the above (missing)  function ?
>
> As I mentioned in the introductory email, these patches also depend on
> Stefano's XC_SAVE_ID_TOOLSTACK patches.
>
> 01 Introduce a new save_id to save/restore toolstack specific extra
> 02 Read Qemu's physmap from xenstore and save it using toolstack_save.
> 03 Following the recent changes to upstream Qemu, the best monitor command
>     (removes qmp_migrate and introduces qmp_save)
>
>
Stefano, you said a while ago, that the above patches were blocked on some
qemu related acks.
Any updates ?


>
> Then my patches:
> 03 libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 04 libxl: support suspend_cancel in domain_resume
> 05 libxl: refactor migrate_domain and generalize migrate_receive
> 06 libxl: resume instead of unpause on xl save -c
>
> 01 libxl: Remus - suspend/postflush/commit callbacks
> 02 libxl: Remus - xl remus command
>
> Currently, one of stefano's patches doesnt apply cleanly - the first one.
> It requires minor fix.
> Barring that, all the other patches mentioned above apply cleanly.
>
>
> Thanks,
>> Ian.
>>
>>
>

--0015175d079a5ffe2c04b96ccce3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 20, 2012 at 12:02 PM, Shriram Rajago=
palan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@=
cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Feb 20, 2012 at 1=
1:00 AM, Ian Jackson <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu=
.citrix.com" target=3D"_blank">Ian.Jackson@eu.citrix.com</a>&gt;</span> wro=
te:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<a href=3D"mailto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca<=
/a> writes (&quot;[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_canc=
el in domain_resume&quot;):<br>
<div>&gt; libxl: support suspend_cancel in domain_resume<br>
<br>
</div>I get this:<br>
<br>
libxl.c: In function &#39;libxl_domain_resume&#39;:<br>
libxl.c:315: error: implicit declaration of function &#39;libxl__domain_res=
ume_device_model&#39;<br>
<br>
Did you compile this ? =A0Did you test it ?<br>
<br></blockquote></div></div><div><br>Yes I did.. Did you apply the previou=
s patch in this series, that introduces the above (missing)=A0 function ?<b=
r><br>As I mentioned in the introductory email, these patches also depend o=
n Stefano&#39;s XC_SAVE_ID_TOOLSTACK patches.<br>


<br>01 Introduce a new save_id to save/restore toolstack specific extra<br>=
02 Read Qemu&#39;s physmap from xenstore and save it using toolstack_save.<=
br>
03 Following the recent changes to upstream Qemu, the best monitor command<=
br>=A0=A0=A0
(removes qmp_migrate and introduces qmp_save)<br><br></div></div></blockquo=
te><div><br>Stefano, you said a while ago, that the above patches were bloc=
ked on some qemu related acks.<br>Any updates ?<br>=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

<div class=3D"gmail_quote"><div><br>Then my patches:<br>03 libxl: QMP stop/=
resume &amp; refactor QEMU suspend/resume/save<br>04 libxl: support suspend=
_cancel in domain_resume<br>05 libxl: refactor migrate_domain and generaliz=
e migrate_receive<br>


06 libxl: resume instead of unpause on xl save -c<br><br>01 libxl: Remus - =
suspend/postflush/commit callbacks<br>02 libxl: Remus - xl remus command<br=
><br>Currently, one of stefano&#39;s patches doesnt apply cleanly - the fir=
st one. It requires minor fix.<br>


Barring that, all the other patches mentioned above apply cleanly.<br><br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>
</blockquote></div><br>

--0015175d079a5ffe2c04b96ccce3--


--===============6648295739933687766==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============6648295739933687766==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 22:28:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 22:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzbhn-00027c-Lf; Mon, 20 Feb 2012 22:27:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rzbhm-00027X-4X
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 22:27:34 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329776795!55031322!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30439 invoked from network); 20 Feb 2012 22:26:37 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2012 22:26:37 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1KMROGn031899
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 14:27:25 -0800
Received: by bkue19 with SMTP id e19so5758637bku.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 14:27:23 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.152.193 as permitted sender) client-ip=10.204.152.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.152.193 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.152.193])
	by 10.204.152.193 with SMTP id h1mr11774652bkw.85.1329776843379
	(num_hops = 1); Mon, 20 Feb 2012 14:27:23 -0800 (PST)
Received: by 10.204.152.193 with SMTP id h1mr9488364bkw.85.1329776843291; Mon,
	20 Feb 2012 14:27:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.34.134 with HTTP; Mon, 20 Feb 2012 14:26:43 -0800 (PST)
In-Reply-To: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 20 Feb 2012 14:26:43 -0800
Message-ID: <CAP8mzPPWzutOx=RKO_kGrvvswCEa=j_qmOu9QRyTfu6qu=4wDw@mail.gmail.com>
To: stefano.stabellini@eu.citrix.com
Cc: brendan@cs.ubc.ca, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6648295739933687766=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6648295739933687766==
Content-Type: multipart/alternative; boundary=0015175d079a5ffe2c04b96ccce3

--0015175d079a5ffe2c04b96ccce3
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 20, 2012 at 12:02 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:
>
>> rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support
>> suspend_cancel in domain_resume"):
>> > libxl: support suspend_cancel in domain_resume
>>
>> I get this:
>>
>> libxl.c: In function 'libxl_domain_resume':
>> libxl.c:315: error: implicit declaration of function
>> 'libxl__domain_resume_device_model'
>>
>> Did you compile this ?  Did you test it ?
>>
>>
> Yes I did.. Did you apply the previous patch in this series, that
> introduces the above (missing)  function ?
>
> As I mentioned in the introductory email, these patches also depend on
> Stefano's XC_SAVE_ID_TOOLSTACK patches.
>
> 01 Introduce a new save_id to save/restore toolstack specific extra
> 02 Read Qemu's physmap from xenstore and save it using toolstack_save.
> 03 Following the recent changes to upstream Qemu, the best monitor command
>     (removes qmp_migrate and introduces qmp_save)
>
>
Stefano, you said a while ago, that the above patches were blocked on some
qemu related acks.
Any updates ?


>
> Then my patches:
> 03 libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 04 libxl: support suspend_cancel in domain_resume
> 05 libxl: refactor migrate_domain and generalize migrate_receive
> 06 libxl: resume instead of unpause on xl save -c
>
> 01 libxl: Remus - suspend/postflush/commit callbacks
> 02 libxl: Remus - xl remus command
>
> Currently, one of stefano's patches doesnt apply cleanly - the first one.
> It requires minor fix.
> Barring that, all the other patches mentioned above apply cleanly.
>
>
> Thanks,
>> Ian.
>>
>>
>

--0015175d079a5ffe2c04b96ccce3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 20, 2012 at 12:02 PM, Shriram Rajago=
palan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@=
cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Feb 20, 2012 at 1=
1:00 AM, Ian Jackson <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Jackson@eu=
.citrix.com" target=3D"_blank">Ian.Jackson@eu.citrix.com</a>&gt;</span> wro=
te:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<a href=3D"mailto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca<=
/a> writes (&quot;[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_canc=
el in domain_resume&quot;):<br>
<div>&gt; libxl: support suspend_cancel in domain_resume<br>
<br>
</div>I get this:<br>
<br>
libxl.c: In function &#39;libxl_domain_resume&#39;:<br>
libxl.c:315: error: implicit declaration of function &#39;libxl__domain_res=
ume_device_model&#39;<br>
<br>
Did you compile this ? =A0Did you test it ?<br>
<br></blockquote></div></div><div><br>Yes I did.. Did you apply the previou=
s patch in this series, that introduces the above (missing)=A0 function ?<b=
r><br>As I mentioned in the introductory email, these patches also depend o=
n Stefano&#39;s XC_SAVE_ID_TOOLSTACK patches.<br>


<br>01 Introduce a new save_id to save/restore toolstack specific extra<br>=
02 Read Qemu&#39;s physmap from xenstore and save it using toolstack_save.<=
br>
03 Following the recent changes to upstream Qemu, the best monitor command<=
br>=A0=A0=A0
(removes qmp_migrate and introduces qmp_save)<br><br></div></div></blockquo=
te><div><br>Stefano, you said a while ago, that the above patches were bloc=
ked on some qemu related acks.<br>Any updates ?<br>=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">

<div class=3D"gmail_quote"><div><br>Then my patches:<br>03 libxl: QMP stop/=
resume &amp; refactor QEMU suspend/resume/save<br>04 libxl: support suspend=
_cancel in domain_resume<br>05 libxl: refactor migrate_domain and generaliz=
e migrate_receive<br>


06 libxl: resume instead of unpause on xl save -c<br><br>01 libxl: Remus - =
suspend/postflush/commit callbacks<br>02 libxl: Remus - xl remus command<br=
><br>Currently, one of stefano&#39;s patches doesnt apply cleanly - the fir=
st one. It requires minor fix.<br>


Barring that, all the other patches mentioned above apply cleanly.<br><br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Ian.<br>
<br>
</blockquote></div><br>
</blockquote></div><br>

--0015175d079a5ffe2c04b96ccce3--


--===============6648295739933687766==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============6648295739933687766==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 22:50:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 22: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 1Rzc3O-0002Ok-Vf; Mon, 20 Feb 2012 22:49:54 +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 1Rzc3N-0002Ob-DB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 22:49:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329778057!53506447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6485 invoked from network); 20 Feb 2012 22:47:37 -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;
	20 Feb 2012 22:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,453,1325462400"; d="scan'208";a="10825027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 22:49:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 22:49:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rzc3L-0000kH-Il;
	Mon, 20 Feb 2012 22:49:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rzc3L-0000aD-Al;
	Mon, 20 Feb 2012 22:49:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11986-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 22:49:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11986: 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 11986 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11986/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11981

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ca80eca9cfa3
baseline version:
 xen                  87218bd367be

------------------------------------------------------------
People who touched revisions under test:
  Allen Kay <allen.m.kay@intel.com>
  Anthony PERARD <anthony.perard@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Fabio Fantoni <fabio.fantoni@heliman.it>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=ca80eca9cfa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ca80eca9cfa3
+ branch=xen-unstable
+ revision=ca80eca9cfa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r ca80eca9cfa3 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 15 changesets with 17 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 22:50:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 22: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 1Rzc3O-0002Ok-Vf; Mon, 20 Feb 2012 22:49:54 +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 1Rzc3N-0002Ob-DB
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 22:49:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329778057!53506447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6485 invoked from network); 20 Feb 2012 22:47:37 -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;
	20 Feb 2012 22:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,453,1325462400"; d="scan'208";a="10825027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 22:49:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 20 Feb 2012 22:49:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rzc3L-0000kH-Il;
	Mon, 20 Feb 2012 22:49:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rzc3L-0000aD-Al;
	Mon, 20 Feb 2012 22:49:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11986-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 20 Feb 2012 22:49:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11986: 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 11986 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11986/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11981

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ca80eca9cfa3
baseline version:
 xen                  87218bd367be

------------------------------------------------------------
People who touched revisions under test:
  Allen Kay <allen.m.kay@intel.com>
  Anthony PERARD <anthony.perard@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Fabio Fantoni <fabio.fantoni@heliman.it>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=ca80eca9cfa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ca80eca9cfa3
+ branch=xen-unstable
+ revision=ca80eca9cfa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r ca80eca9cfa3 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 15 changesets with 17 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 23:32:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 23:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzciN-0003no-CL; Mon, 20 Feb 2012 23:32:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzciM-0003ng-Dg
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 23:32:14 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329780726!9171251!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23766 invoked from network); 20 Feb 2012 23:32:07 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 23:32:07 -0000
Received: by obcuy19 with SMTP id uy19so18904337obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 15:32:06 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.182.36.106 as permitted sender) client-ip=10.182.36.106; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.182.36.106 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.182.36.106])
	by 10.182.36.106 with SMTP id p10mr13979606obj.55.1329780726233
	(num_hops = 1); Mon, 20 Feb 2012 15:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=U0O2X3BHzgF1xLtylLk7RrYAj52BOA/KuLIvgithKcw=;
	b=ud26RkfDK2+HhrnLzh+q25JQWb8psOf/VV5dQEAOYS4jSpa7b2NiYLCbqDkpRcW4Yr
	M3HUNfWjY3OzeGJqUncptuv2yg60N08S6z41lHIOH8HagZ/hAVXK/Z/jptq27Nw0XLnV
	ncX6NBt2s57tE4wBFi88co7npkcBRGo6gW5Yk=
Received: by 10.182.36.106 with SMTP id p10mr11882615obj.55.1329780726181;
	Mon, 20 Feb 2012 15:32:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 20 Feb 2012 15:31:35 -0800 (PST)
In-Reply-To: <4F42A601.7000701@vido.info>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
	<CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
	<4F42A601.7000701@vido.info>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 23:31:35 +0000
X-Google-Sender-Auth: np-_cSqfA7tq3q6cWOVqPXI7sTY
Message-ID: <CAJJyHj+8M_3ZmS0un8y6d=abijXE6Y0u56m4qWubu5BdBKMo4A@mail.gmail.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 19:58, Tobias Geiger <tobias.geiger@vido.info> wrote:
> With the patch you mentioned, xl create looks more familiar:
>
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
>
>
> This is actually "normal", at least compared to traditional qemu-dm - i
> guess due to missing FLR (Bios is capable, but Card not i assume).

:-)

> Anyhow - the downside of the patch is, qemu doesnt even start :)

Nop, qemu start but exit sooner.

> This is qemu-dm.log (with debugging enabled):

This is probably only the end of the logs, but thx.

> [00:06.0] pt_pci_read_config: address=0x0030 val=0x00000000 len=4
> [00:06.0] pt_pci_write_config: address=0x0030 val=0xffffffff len=4
> [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=1
> [00:06.0] pt_pci_read_config: address=0x0030 val=0xfffe0001 len=4
> [00:06.0] pt_pci_write_config: address=0x0030 val=0x00000000 len=4
> [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=0
...
> [00:06.0] pt_pci_read_config: address=0x0004 val=0x00000000 len=2
> [00:06.0] pt_pci_write_config: address=0x0004 val=0x00000004 len=2
> qemu-system-x86_64: /usr/src/xen-with-upstream-qemu-patch/upstream-qemu/qemu/memory.c:1378: memory_region_del_subregion: Assertion `subregion->parent == mr' failed.

This last line is why QEMU fail and I thinks it's because I never try
a PCI device with a ROM pci bar. I'll try to fix this tomorrow.

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 23:32:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 23:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzciN-0003no-CL; Mon, 20 Feb 2012 23:32:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzciM-0003ng-Dg
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 23:32:14 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329780726!9171251!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23766 invoked from network); 20 Feb 2012 23:32:07 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 23:32:07 -0000
Received: by obcuy19 with SMTP id uy19so18904337obc.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 15:32:06 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.182.36.106 as permitted sender) client-ip=10.182.36.106; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.182.36.106 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.182.36.106])
	by 10.182.36.106 with SMTP id p10mr13979606obj.55.1329780726233
	(num_hops = 1); Mon, 20 Feb 2012 15:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=U0O2X3BHzgF1xLtylLk7RrYAj52BOA/KuLIvgithKcw=;
	b=ud26RkfDK2+HhrnLzh+q25JQWb8psOf/VV5dQEAOYS4jSpa7b2NiYLCbqDkpRcW4Yr
	M3HUNfWjY3OzeGJqUncptuv2yg60N08S6z41lHIOH8HagZ/hAVXK/Z/jptq27Nw0XLnV
	ncX6NBt2s57tE4wBFi88co7npkcBRGo6gW5Yk=
Received: by 10.182.36.106 with SMTP id p10mr11882615obj.55.1329780726181;
	Mon, 20 Feb 2012 15:32:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Mon, 20 Feb 2012 15:31:35 -0800 (PST)
In-Reply-To: <4F42A601.7000701@vido.info>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
	<CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
	<4F42A601.7000701@vido.info>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 20 Feb 2012 23:31:35 +0000
X-Google-Sender-Auth: np-_cSqfA7tq3q6cWOVqPXI7sTY
Message-ID: <CAJJyHj+8M_3ZmS0un8y6d=abijXE6Y0u56m4qWubu5BdBKMo4A@mail.gmail.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 19:58, Tobias Geiger <tobias.geiger@vido.info> wrote:
> With the patch you mentioned, xl create looks more familiar:
>
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.0/reset returned -1: Invalid argument
> libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to
> /sys/bus/pci/devices/0000:03:00.1/reset returned -1: Invalid argument
>
>
> This is actually "normal", at least compared to traditional qemu-dm - i
> guess due to missing FLR (Bios is capable, but Card not i assume).

:-)

> Anyhow - the downside of the patch is, qemu doesnt even start :)

Nop, qemu start but exit sooner.

> This is qemu-dm.log (with debugging enabled):

This is probably only the end of the logs, but thx.

> [00:06.0] pt_pci_read_config: address=0x0030 val=0x00000000 len=4
> [00:06.0] pt_pci_write_config: address=0x0030 val=0xffffffff len=4
> [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=1
> [00:06.0] pt_pci_read_config: address=0x0030 val=0xfffe0001 len=4
> [00:06.0] pt_pci_write_config: address=0x0030 val=0x00000000 len=4
> [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=0
...
> [00:06.0] pt_pci_read_config: address=0x0004 val=0x00000000 len=2
> [00:06.0] pt_pci_write_config: address=0x0004 val=0x00000004 len=2
> qemu-system-x86_64: /usr/src/xen-with-upstream-qemu-patch/upstream-qemu/qemu/memory.c:1378: memory_region_del_subregion: Assertion `subregion->parent == mr' failed.

This last line is why QEMU fail and I thinks it's because I never try
a PCI device with a ROM pci bar. I'll try to fix this tomorrow.

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 23:47:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 23:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzcwX-000448-RE; Mon, 20 Feb 2012 23:46:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RzcwW-000441-Dn
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 23:46:52 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329781536!62161445!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29875 invoked from network); 20 Feb 2012 23:45:36 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 23:45:36 -0000
Received: by werb14 with SMTP id b14so13395590wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 15:46:50 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.99.100 as permitted sender) client-ip=10.180.99.100; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.99.100 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.99.100])
	by 10.180.99.100 with SMTP id ep4mr21029899wib.7.1329781610182
	(num_hops = 1); Mon, 20 Feb 2012 15:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=qcc3K/rFuOcK78Kdfu6oKsvViOBG6m3rgtoePjXvQSE=;
	b=BqncPz1i8FOyb5i6mOqjVgwetlNh6h9jNY7saEjlhL9RQfNH8QYNxPVvaNJvObn1c1
	Ygl+Sfdgr2FHsn2kkhRZe6isADlKooyDEyj2GVkUiFhRGd756gMpYL7XlyqsnsPG0N2r
	Ihn3uYS83IqmaZ5WfFVLFIW088gSGCqyEFViQ=
MIME-Version: 1.0
Received: by 10.180.99.100 with SMTP id ep4mr17524720wib.7.1329781610061; Mon,
	20 Feb 2012 15:46:50 -0800 (PST)
Received: by 10.180.106.99 with HTTP; Mon, 20 Feb 2012 15:46:50 -0800 (PST)
Date: Mon, 20 Feb 2012 16:46:50 -0700
Message-ID: <CAHyyzzQ7ZAhnvWn8_Ui2jd9BFYSAvNX=V+tpbpZzVGLcT9c3Xw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen kernel crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5720716172110386231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5720716172110386231==
Content-Type: multipart/alternative; boundary=f46d04428e5c7f1d9c04b96de826

--f46d04428e5c7f1d9c04b96de826
Content-Type: text/plain; charset=ISO-8859-1

I had created package for arch linux xen 4.2 unstable and 3.3.0-rc1 linus
fixes kernel. So if I issue xl destroy domu my kernel crashes. Is there any
patch that can stop those crashes.
 7742.769113] xen-pciback[0000:02:00.0] IRQ line is not shared with other
domains. Turning ISR off
[ 7748.502978] irq 32: nobody cared (try booting with the "irqpoll" option)
[ 7748.503025] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
[ 7748.503059] Call Trace:
[ 7748.503080]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
[ 7748.503130]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
[ 7748.503165]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
[ 7748.503202]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
[ 7748.503235]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
[ 7748.503268]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
[ 7748.503302]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
[ 7748.503339]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
[ 7748.503374]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
[ 7748.503409]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.503453]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.503487]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
[ 7748.503519]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
[ 7748.503552]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
[ 7748.503584]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
[ 7748.503615]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
[ 7748.503648]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
[ 7748.503684]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
[ 7748.503717] handlers:
[ 7748.503737] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
[ 7748.503773] Disabling IRQ #32
[ 7748.652402] irq 16: nobody cared (try booting with the "irqpoll" option)
[ 7748.652445] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
[ 7748.652479] Call Trace:
[ 7748.652499]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
[ 7748.652545]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
[ 7748.652579]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
[ 7748.652616]  [<ffffffff8103eae5>] ? pvclock_clocksource_read+0x55/0xf0
[ 7748.652652]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
[ 7748.652684]  [<ffffffff8100b8e0>] ? xen_clocksource_read+0x40/0x70
[ 7748.652719]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
[ 7748.652754]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
[ 7748.652791]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
[ 7748.652826]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
[ 7748.652861]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.652903]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.652937]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
[ 7748.652969]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
[ 7748.653002]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
[ 7748.653034]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
[ 7748.653065]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
[ 7748.653098]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
[ 7748.653135]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
[ 7748.653167] handlers:
[ 7748.653194] [<ffffffffa01d7100>] azx_interrupt
[ 7748.653226] Disabling IRQ #16
[ 7752.782419] vif vif-6-0: 2 reading script
[ 7752.784350] xenbr0: port 3(vif6.0) entering forwarding state
[ 7752.784611] xenbr0: port 3(vif6.0) entering disabled state
[ 7790.687530] xen-pciback: vpci: 0000:02:00.0: assign to virtual slot 0
[ 7790.817247] device vif7.0 entered promiscuous mode
[ 7790.819947] ADDRCONF(NETDEV_UP): vif7.0: link is not ready
[ 7791.198278] xen-blkback:ring-ref 8, event-channel 8, protocol 1
(x86_64-abi)
[ 7791.234632] ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready
[ 7791.234712] xenbr0: port 3(vif7.0) entering forwarding state
[ 7791.234747] xenbr0: port 3(vif7.0) entering forwarding state
[ 7795.090689] pciback 0000:02:00.0: enabling device (0000 -> 0002)
[ 7795.090756] xen: registering gsi 32 triggering 0 polarity 1
[ 7795.090769] xen_map_pirq_gsi: returning irq 32 for gsi 32
[ 7795.090807] xen: --> pirq=32 -> irq=32 (gsi=32)
[ 7795.090811] Already setup the GSI :32
[ 7796.165112] irq 32: nobody cared (try booting with the "irqpoll" option)
[ 7796.165159] Pid: 1863, comm: kworker/0:1 Not tainted 3.3.0-rc1-xen #1
[ 7796.165201] Call Trace:
[ 7796.165229]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
[ 7796.165292]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
[ 7796.165335]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
[ 7796.165383]  [<ffffffff810749bc>] ? run_posix_cpu_timers+0x2c/0x7b0
[ 7796.165427]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
[ 7796.165469]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
[ 7796.165514]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
[ 7796.165563]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
[ 7796.165607]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
[ 7796.165650]  [<ffffffff810766a7>] ? hrtimer_interrupt+0x127/0x200
[ 7796.165695]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
[ 7796.165741]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[ 7796.165782]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[ 7796.165825]  [<ffffffff8100b5ad>] ? xen_force_evtchn_callback+0xd/0x10
[ 7796.165870]  [<ffffffff8100be12>] ? check_events+0x12/0x20
[ 7796.165893]  [<ffffffff8100bdb9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[ 7796.165893]  [<ffffffff81056dab>] ? __do_softirq+0x7b/0x280
[ 7796.165893]  [<ffffffff8100b903>] ? xen_clocksource_read+0x63/0x70
[ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
[ 7796.165893]  [<ffffffff814496dc>] ? call_softirq+0x1c/0x30
[ 7796.165893]  [<ffffffff81017755>] ? do_softirq+0x65/0xa0
[ 7796.165893]  [<ffffffff810572f6>] ? irq_exit+0xa6/0xc0
[ 7796.165893]  [<ffffffff812c72f5>] ? xen_evtchn_do_upcall+0x35/0x50
[ 7796.165893]  [<ffffffff8144972e>] ? xen_do_hypervisor_callback+0x1e/0x30
[ 7796.165893]  <EOI>  [<ffffffff81247f6b>] ? find_next_zero_bit+0x4b/0xe0
[ 7796.165893]  [<ffffffff81238f90>] ? ida_get_new_above+0x70/0x2f0
[ 7796.165893]  [<ffffffff81239722>] ? idr_pre_get+0x52/0x90
[ 7796.165893]  [<ffffffff8123921e>] ? ida_get_new+0xe/0x10
[ 7796.165893]  [<ffffffff811cecc5>] ? proc_register+0x55/0x200
[ 7796.165893]  [<ffffffff811cf36f>] ? proc_mkdir_mode+0x3f/0x60
[ 7796.165893]  [<ffffffff811cf3a6>] ? proc_mkdir+0x16/0x20
[ 7796.165893]  [<ffffffff810d14eb>] ? register_handler_proc+0x11b/0x140
[ 7796.165893]  [<ffffffff810ce391>] ? __setup_irq+0x431/0x550
[ 7796.165893]  [<ffffffff8115522b>] ? kmem_cache_alloc_trace+0x12b/0x150
[ 7796.165893]  [<ffffffff812d4940>] ? xen_pcibk_control_isr+0x120/0x120
[ 7796.165893]  [<ffffffff810ce59a>] ? request_threaded_irq+0xea/0x1a0
[ 7796.165893]  [<ffffffff812d4917>] ? xen_pcibk_control_isr+0xf7/0x120
[ 7796.165893]  [<ffffffff812d4daa>] ? xen_pcibk_do_op+0x26a/0x590
[ 7796.165893]  [<ffffffff812d4b40>] ?
xen_pcibk_test_and_schedule_op+0x80/0x80
[ 7796.165893]  [<ffffffff8106bdeb>] ? process_one_work+0x11b/0x4d0
[ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
[ 7796.165893]  [<ffffffff8106c784>] ? worker_thread+0x164/0x340
[ 7796.165893]  [<ffffffff8100bdff>] ? xen_restore_fl_direct_reloc+0x4/0x4
[ 7796.165893]  [<ffffffff8106c620>] ? manage_workers.isra.25+0x220/0x220
[ 7796.165893]  [<ffffffff810717e3>] ? kthread+0x93/0xa0
[ 7796.165893]  [<ffffffff814495e4>] ? kernel_thread_helper+0x4/0x10
[ 7796.165893]  [<ffffffff814478c0>] ? retint_restore_args+0x5/0x6
[ 7796.165893]  [<ffffffff814495e0>] ? gs_change+0x13/0x13
[ 7796.165893] handlers:
[ 7796.165893] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
[ 7796.165893] Disabling IRQ #32

--f46d04428e5c7f1d9c04b96de826
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I had created package for arch linux xen 4.2 unstable and 3.3.0-rc1 linus f=
ixes kernel. So if I issue xl destroy domu my kernel crashes. Is there any =
patch that can stop those crashes.<br>=A07742.769113] xen-pciback[0000:02:0=
0.0] IRQ line is not shared with other domains. Turning ISR off<br>
[ 7748.502978] irq 32: nobody cared (try booting with the &quot;irqpoll&quo=
t; option)<br>[ 7748.503025] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-=
xen #1<br>[ 7748.503059] Call Trace:<br>[ 7748.503080]=A0 &lt;IRQ&gt;=A0 [&=
lt;ffffffff810cedbd&gt;] __report_bad_irq+0x3d/0xe0<br>
[ 7748.503130]=A0 [&lt;ffffffff810cf059&gt;] note_interrupt+0x159/0x210<br>=
[ 7748.503165]=A0 [&lt;ffffffff810cc8a8&gt;] handle_irq_event_percpu+0xc8/0=
x280<br>[ 7748.503202]=A0 [&lt;ffffffff8123c98b&gt;] ? radix_tree_lookup+0x=
b/0x10<br>
[ 7748.503235]=A0 [&lt;ffffffff810ccaa8&gt;] handle_irq_event+0x48/0x70<br>=
[ 7748.503268]=A0 [&lt;ffffffff810cfa2a&gt;] handle_fasteoi_irq+0x5a/0xe0<b=
r>[ 7748.503302]=A0 [&lt;ffffffff812c5864&gt;] __xen_evtchn_do_upcall+0x1a4=
/0x270<br>
[ 7748.503339]=A0 [&lt;ffffffff812c72ef&gt;] xen_evtchn_do_upcall+0x2f/0x50=
<br>[ 7748.503374]=A0 [&lt;ffffffff8144972e&gt;] xen_do_hypervisor_callback=
+0x1e/0x30<br>[ 7748.503409]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff810013aa&gt;] ?=
 hypercall_page+0x3aa/0x1000<br>
[ 7748.503453]=A0 [&lt;ffffffff810013aa&gt;] ? hypercall_page+0x3aa/0x1000<=
br>[ 7748.503487]=A0 [&lt;ffffffff8100b4b0&gt;] ? xen_safe_halt+0x10/0x20<b=
r>[ 7748.503519]=A0 [&lt;ffffffff8101e8d3&gt;] ? default_idle+0x53/0x280<br=
>[ 7748.503552]=A0 [&lt;ffffffff81014246&gt;] ? cpu_idle+0xe6/0x120<br>
[ 7748.503584]=A0 [&lt;ffffffff81422072&gt;] ? rest_init+0x96/0xa4<br>[ 774=
8.503615]=A0 [&lt;ffffffff818f6c0e&gt;] ? start_kernel+0x3cf/0x3dc<br>[ 774=
8.503648]=A0 [&lt;ffffffff818f6346&gt;] ? x86_64_start_reservations+0x131/0=
x135<br>
[ 7748.503684]=A0 [&lt;ffffffff818f8a3c&gt;] ? xen_start_kernel+0x5e0/0x5e7=
<br>[ 7748.503717] handlers:<br>[ 7748.503737] [&lt;ffffffff812d4940&gt;] x=
en_pcibk_guest_interrupt<br>[ 7748.503773] Disabling IRQ #32<br>[ 7748.6524=
02] irq 16: nobody cared (try booting with the &quot;irqpoll&quot; option)<=
br>
[ 7748.652445] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1<br>[ 77=
48.652479] Call Trace:<br>[ 7748.652499]=A0 &lt;IRQ&gt;=A0 [&lt;ffffffff810=
cedbd&gt;] __report_bad_irq+0x3d/0xe0<br>[ 7748.652545]=A0 [&lt;ffffffff810=
cf059&gt;] note_interrupt+0x159/0x210<br>
[ 7748.652579]=A0 [&lt;ffffffff810cc8a8&gt;] handle_irq_event_percpu+0xc8/0=
x280<br>[ 7748.652616]=A0 [&lt;ffffffff8103eae5&gt;] ? pvclock_clocksource_=
read+0x55/0xf0<br>[ 7748.652652]=A0 [&lt;ffffffff810ccaa8&gt;] handle_irq_e=
vent+0x48/0x70<br>
[ 7748.652684]=A0 [&lt;ffffffff8100b8e0&gt;] ? xen_clocksource_read+0x40/0x=
70<br>[ 7748.652719]=A0 [&lt;ffffffff810cfa2a&gt;] handle_fasteoi_irq+0x5a/=
0xe0<br>[ 7748.652754]=A0 [&lt;ffffffff812c5864&gt;] __xen_evtchn_do_upcall=
+0x1a4/0x270<br>
[ 7748.652791]=A0 [&lt;ffffffff812c72ef&gt;] xen_evtchn_do_upcall+0x2f/0x50=
<br>[ 7748.652826]=A0 [&lt;ffffffff8144972e&gt;] xen_do_hypervisor_callback=
+0x1e/0x30<br>[ 7748.652861]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff810013aa&gt;] ?=
 hypercall_page+0x3aa/0x1000<br>
[ 7748.652903]=A0 [&lt;ffffffff810013aa&gt;] ? hypercall_page+0x3aa/0x1000<=
br>[ 7748.652937]=A0 [&lt;ffffffff8100b4b0&gt;] ? xen_safe_halt+0x10/0x20<b=
r>[ 7748.652969]=A0 [&lt;ffffffff8101e8d3&gt;] ? default_idle+0x53/0x280<br=
>[ 7748.653002]=A0 [&lt;ffffffff81014246&gt;] ? cpu_idle+0xe6/0x120<br>
[ 7748.653034]=A0 [&lt;ffffffff81422072&gt;] ? rest_init+0x96/0xa4<br>[ 774=
8.653065]=A0 [&lt;ffffffff818f6c0e&gt;] ? start_kernel+0x3cf/0x3dc<br>[ 774=
8.653098]=A0 [&lt;ffffffff818f6346&gt;] ? x86_64_start_reservations+0x131/0=
x135<br>
[ 7748.653135]=A0 [&lt;ffffffff818f8a3c&gt;] ? xen_start_kernel+0x5e0/0x5e7=
<br>[ 7748.653167] handlers:<br>[ 7748.653194] [&lt;ffffffffa01d7100&gt;] a=
zx_interrupt<br>[ 7748.653226] Disabling IRQ #16<br>[ 7752.782419] vif vif-=
6-0: 2 reading script<br>
[ 7752.784350] xenbr0: port 3(vif6.0) entering forwarding state<br>[ 7752.7=
84611] xenbr0: port 3(vif6.0) entering disabled state<br>[ 7790.687530] xen=
-pciback: vpci: 0000:02:00.0: assign to virtual slot 0<br>[ 7790.817247] de=
vice vif7.0 entered promiscuous mode<br>
[ 7790.819947] ADDRCONF(NETDEV_UP): vif7.0: link is not ready<br>[ 7791.198=
278] xen-blkback:ring-ref 8, event-channel 8, protocol 1 (x86_64-abi)<br>[ =
7791.234632] ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready<br>[ 7791.=
234712] xenbr0: port 3(vif7.0) entering forwarding state<br>
[ 7791.234747] xenbr0: port 3(vif7.0) entering forwarding state<br>[ 7795.0=
90689] pciback 0000:02:00.0: enabling device (0000 -&gt; 0002)<br>[ 7795.09=
0756] xen: registering gsi 32 triggering 0 polarity 1<br>[ 7795.090769] xen=
_map_pirq_gsi: returning irq 32 for gsi 32<br>
[ 7795.090807] xen: --&gt; pirq=3D32 -&gt; irq=3D32 (gsi=3D32)<br>[ 7795.09=
0811] Already setup the GSI :32<br>[ 7796.165112] irq 32: nobody cared (try=
 booting with the &quot;irqpoll&quot; option)<br>[ 7796.165159] Pid: 1863, =
comm: kworker/0:1 Not tainted 3.3.0-rc1-xen #1<br>
[ 7796.165201] Call Trace:<br>[ 7796.165229]=A0 &lt;IRQ&gt;=A0 [&lt;fffffff=
f810cedbd&gt;] __report_bad_irq+0x3d/0xe0<br>[ 7796.165292]=A0 [&lt;fffffff=
f810cf059&gt;] note_interrupt+0x159/0x210<br>[ 7796.165335]=A0 [&lt;fffffff=
f810cc8a8&gt;] handle_irq_event_percpu+0xc8/0x280<br>
[ 7796.165383]=A0 [&lt;ffffffff810749bc&gt;] ? run_posix_cpu_timers+0x2c/0x=
7b0<br>[ 7796.165427]=A0 [&lt;ffffffff8123c98b&gt;] ? radix_tree_lookup+0xb=
/0x10<br>[ 7796.165469]=A0 [&lt;ffffffff810ccaa8&gt;] handle_irq_event+0x48=
/0x70<br>
[ 7796.165514]=A0 [&lt;ffffffff810cfa2a&gt;] handle_fasteoi_irq+0x5a/0xe0<b=
r>[ 7796.165563]=A0 [&lt;ffffffff812c5864&gt;] __xen_evtchn_do_upcall+0x1a4=
/0x270<br>[ 7796.165607]=A0 [&lt;ffffffff812c72ef&gt;] xen_evtchn_do_upcall=
+0x2f/0x50<br>
[ 7796.165650]=A0 [&lt;ffffffff810766a7&gt;] ? hrtimer_interrupt+0x127/0x20=
0<br>[ 7796.165695]=A0 [&lt;ffffffff8144972e&gt;] xen_do_hypervisor_callbac=
k+0x1e/0x30<br>[ 7796.165741]=A0 [&lt;ffffffff8100122a&gt;] ? hypercall_pag=
e+0x22a/0x1000<br>
[ 7796.165782]=A0 [&lt;ffffffff8100122a&gt;] ? hypercall_page+0x22a/0x1000<=
br>[ 7796.165825]=A0 [&lt;ffffffff8100b5ad&gt;] ? xen_force_evtchn_callback=
+0xd/0x10<br>[ 7796.165870]=A0 [&lt;ffffffff8100be12&gt;] ? check_events+0x=
12/0x20<br>
[ 7796.165893]=A0 [&lt;ffffffff8100bdb9&gt;] ? xen_irq_enable_direct_reloc+=
0x4/0x4<br>[ 7796.165893]=A0 [&lt;ffffffff81056dab&gt;] ? __do_softirq+0x7b=
/0x280<br>[ 7796.165893]=A0 [&lt;ffffffff8100b903&gt;] ? xen_clocksource_re=
ad+0x63/0x70<br>
[ 7796.165893]=A0 [&lt;ffffffff8100be12&gt;] ? check_events+0x12/0x20<br>[ =
7796.165893]=A0 [&lt;ffffffff814496dc&gt;] ? call_softirq+0x1c/0x30<br>[ 77=
96.165893]=A0 [&lt;ffffffff81017755&gt;] ? do_softirq+0x65/0xa0<br>[ 7796.1=
65893]=A0 [&lt;ffffffff810572f6&gt;] ? irq_exit+0xa6/0xc0<br>
[ 7796.165893]=A0 [&lt;ffffffff812c72f5&gt;] ? xen_evtchn_do_upcall+0x35/0x=
50<br>[ 7796.165893]=A0 [&lt;ffffffff8144972e&gt;] ? xen_do_hypervisor_call=
back+0x1e/0x30<br>[ 7796.165893]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff81247f6b&gt=
;] ? find_next_zero_bit+0x4b/0xe0<br>
[ 7796.165893]=A0 [&lt;ffffffff81238f90&gt;] ? ida_get_new_above+0x70/0x2f0=
<br>[ 7796.165893]=A0 [&lt;ffffffff81239722&gt;] ? idr_pre_get+0x52/0x90<br=
>[ 7796.165893]=A0 [&lt;ffffffff8123921e&gt;] ? ida_get_new+0xe/0x10<br>[ 7=
796.165893]=A0 [&lt;ffffffff811cecc5&gt;] ? proc_register+0x55/0x200<br>
[ 7796.165893]=A0 [&lt;ffffffff811cf36f&gt;] ? proc_mkdir_mode+0x3f/0x60<br=
>[ 7796.165893]=A0 [&lt;ffffffff811cf3a6&gt;] ? proc_mkdir+0x16/0x20<br>[ 7=
796.165893]=A0 [&lt;ffffffff810d14eb&gt;] ? register_handler_proc+0x11b/0x1=
40<br>
[ 7796.165893]=A0 [&lt;ffffffff810ce391&gt;] ? __setup_irq+0x431/0x550<br>[=
 7796.165893]=A0 [&lt;ffffffff8115522b&gt;] ? kmem_cache_alloc_trace+0x12b/=
0x150<br>[ 7796.165893]=A0 [&lt;ffffffff812d4940&gt;] ? xen_pcibk_control_i=
sr+0x120/0x120<br>
[ 7796.165893]=A0 [&lt;ffffffff810ce59a&gt;] ? request_threaded_irq+0xea/0x=
1a0<br>[ 7796.165893]=A0 [&lt;ffffffff812d4917&gt;] ? xen_pcibk_control_isr=
+0xf7/0x120<br>[ 7796.165893]=A0 [&lt;ffffffff812d4daa&gt;] ? xen_pcibk_do_=
op+0x26a/0x590<br>
[ 7796.165893]=A0 [&lt;ffffffff812d4b40&gt;] ? xen_pcibk_test_and_schedule_=
op+0x80/0x80<br>[ 7796.165893]=A0 [&lt;ffffffff8106bdeb&gt;] ? process_one_=
work+0x11b/0x4d0<br>[ 7796.165893]=A0 [&lt;ffffffff8100be12&gt;] ? check_ev=
ents+0x12/0x20<br>
[ 7796.165893]=A0 [&lt;ffffffff8106c784&gt;] ? worker_thread+0x164/0x340<br=
>[ 7796.165893]=A0 [&lt;ffffffff8100bdff&gt;] ? xen_restore_fl_direct_reloc=
+0x4/0x4<br>[ 7796.165893]=A0 [&lt;ffffffff8106c620&gt;] ? manage_workers.i=
sra.25+0x220/0x220<br>
[ 7796.165893]=A0 [&lt;ffffffff810717e3&gt;] ? kthread+0x93/0xa0<br>[ 7796.=
165893]=A0 [&lt;ffffffff814495e4&gt;] ? kernel_thread_helper+0x4/0x10<br>[ =
7796.165893]=A0 [&lt;ffffffff814478c0&gt;] ? retint_restore_args+0x5/0x6<br=
>[ 7796.165893]=A0 [&lt;ffffffff814495e0&gt;] ? gs_change+0x13/0x13<br>
[ 7796.165893] handlers:<br>[ 7796.165893] [&lt;ffffffff812d4940&gt;] xen_p=
cibk_guest_interrupt<br>[ 7796.165893] Disabling IRQ #32<br><br>

--f46d04428e5c7f1d9c04b96de826--


--===============5720716172110386231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5720716172110386231==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 23:47:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 23:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzcwX-000448-RE; Mon, 20 Feb 2012 23:46:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1RzcwW-000441-Dn
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 23:46:52 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329781536!62161445!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29875 invoked from network); 20 Feb 2012 23:45:36 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 23:45:36 -0000
Received: by werb14 with SMTP id b14so13395590wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 15:46:50 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.99.100 as permitted sender) client-ip=10.180.99.100; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.99.100 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.99.100])
	by 10.180.99.100 with SMTP id ep4mr21029899wib.7.1329781610182
	(num_hops = 1); Mon, 20 Feb 2012 15:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=qcc3K/rFuOcK78Kdfu6oKsvViOBG6m3rgtoePjXvQSE=;
	b=BqncPz1i8FOyb5i6mOqjVgwetlNh6h9jNY7saEjlhL9RQfNH8QYNxPVvaNJvObn1c1
	Ygl+Sfdgr2FHsn2kkhRZe6isADlKooyDEyj2GVkUiFhRGd756gMpYL7XlyqsnsPG0N2r
	Ihn3uYS83IqmaZ5WfFVLFIW088gSGCqyEFViQ=
MIME-Version: 1.0
Received: by 10.180.99.100 with SMTP id ep4mr17524720wib.7.1329781610061; Mon,
	20 Feb 2012 15:46:50 -0800 (PST)
Received: by 10.180.106.99 with HTTP; Mon, 20 Feb 2012 15:46:50 -0800 (PST)
Date: Mon, 20 Feb 2012 16:46:50 -0700
Message-ID: <CAHyyzzQ7ZAhnvWn8_Ui2jd9BFYSAvNX=V+tpbpZzVGLcT9c3Xw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen kernel crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5720716172110386231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5720716172110386231==
Content-Type: multipart/alternative; boundary=f46d04428e5c7f1d9c04b96de826

--f46d04428e5c7f1d9c04b96de826
Content-Type: text/plain; charset=ISO-8859-1

I had created package for arch linux xen 4.2 unstable and 3.3.0-rc1 linus
fixes kernel. So if I issue xl destroy domu my kernel crashes. Is there any
patch that can stop those crashes.
 7742.769113] xen-pciback[0000:02:00.0] IRQ line is not shared with other
domains. Turning ISR off
[ 7748.502978] irq 32: nobody cared (try booting with the "irqpoll" option)
[ 7748.503025] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
[ 7748.503059] Call Trace:
[ 7748.503080]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
[ 7748.503130]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
[ 7748.503165]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
[ 7748.503202]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
[ 7748.503235]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
[ 7748.503268]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
[ 7748.503302]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
[ 7748.503339]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
[ 7748.503374]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
[ 7748.503409]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.503453]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.503487]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
[ 7748.503519]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
[ 7748.503552]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
[ 7748.503584]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
[ 7748.503615]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
[ 7748.503648]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
[ 7748.503684]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
[ 7748.503717] handlers:
[ 7748.503737] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
[ 7748.503773] Disabling IRQ #32
[ 7748.652402] irq 16: nobody cared (try booting with the "irqpoll" option)
[ 7748.652445] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
[ 7748.652479] Call Trace:
[ 7748.652499]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
[ 7748.652545]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
[ 7748.652579]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
[ 7748.652616]  [<ffffffff8103eae5>] ? pvclock_clocksource_read+0x55/0xf0
[ 7748.652652]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
[ 7748.652684]  [<ffffffff8100b8e0>] ? xen_clocksource_read+0x40/0x70
[ 7748.652719]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
[ 7748.652754]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
[ 7748.652791]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
[ 7748.652826]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
[ 7748.652861]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.652903]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[ 7748.652937]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
[ 7748.652969]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
[ 7748.653002]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
[ 7748.653034]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
[ 7748.653065]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
[ 7748.653098]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
[ 7748.653135]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
[ 7748.653167] handlers:
[ 7748.653194] [<ffffffffa01d7100>] azx_interrupt
[ 7748.653226] Disabling IRQ #16
[ 7752.782419] vif vif-6-0: 2 reading script
[ 7752.784350] xenbr0: port 3(vif6.0) entering forwarding state
[ 7752.784611] xenbr0: port 3(vif6.0) entering disabled state
[ 7790.687530] xen-pciback: vpci: 0000:02:00.0: assign to virtual slot 0
[ 7790.817247] device vif7.0 entered promiscuous mode
[ 7790.819947] ADDRCONF(NETDEV_UP): vif7.0: link is not ready
[ 7791.198278] xen-blkback:ring-ref 8, event-channel 8, protocol 1
(x86_64-abi)
[ 7791.234632] ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready
[ 7791.234712] xenbr0: port 3(vif7.0) entering forwarding state
[ 7791.234747] xenbr0: port 3(vif7.0) entering forwarding state
[ 7795.090689] pciback 0000:02:00.0: enabling device (0000 -> 0002)
[ 7795.090756] xen: registering gsi 32 triggering 0 polarity 1
[ 7795.090769] xen_map_pirq_gsi: returning irq 32 for gsi 32
[ 7795.090807] xen: --> pirq=32 -> irq=32 (gsi=32)
[ 7795.090811] Already setup the GSI :32
[ 7796.165112] irq 32: nobody cared (try booting with the "irqpoll" option)
[ 7796.165159] Pid: 1863, comm: kworker/0:1 Not tainted 3.3.0-rc1-xen #1
[ 7796.165201] Call Trace:
[ 7796.165229]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
[ 7796.165292]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
[ 7796.165335]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
[ 7796.165383]  [<ffffffff810749bc>] ? run_posix_cpu_timers+0x2c/0x7b0
[ 7796.165427]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
[ 7796.165469]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
[ 7796.165514]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
[ 7796.165563]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
[ 7796.165607]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
[ 7796.165650]  [<ffffffff810766a7>] ? hrtimer_interrupt+0x127/0x200
[ 7796.165695]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
[ 7796.165741]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[ 7796.165782]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[ 7796.165825]  [<ffffffff8100b5ad>] ? xen_force_evtchn_callback+0xd/0x10
[ 7796.165870]  [<ffffffff8100be12>] ? check_events+0x12/0x20
[ 7796.165893]  [<ffffffff8100bdb9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[ 7796.165893]  [<ffffffff81056dab>] ? __do_softirq+0x7b/0x280
[ 7796.165893]  [<ffffffff8100b903>] ? xen_clocksource_read+0x63/0x70
[ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
[ 7796.165893]  [<ffffffff814496dc>] ? call_softirq+0x1c/0x30
[ 7796.165893]  [<ffffffff81017755>] ? do_softirq+0x65/0xa0
[ 7796.165893]  [<ffffffff810572f6>] ? irq_exit+0xa6/0xc0
[ 7796.165893]  [<ffffffff812c72f5>] ? xen_evtchn_do_upcall+0x35/0x50
[ 7796.165893]  [<ffffffff8144972e>] ? xen_do_hypervisor_callback+0x1e/0x30
[ 7796.165893]  <EOI>  [<ffffffff81247f6b>] ? find_next_zero_bit+0x4b/0xe0
[ 7796.165893]  [<ffffffff81238f90>] ? ida_get_new_above+0x70/0x2f0
[ 7796.165893]  [<ffffffff81239722>] ? idr_pre_get+0x52/0x90
[ 7796.165893]  [<ffffffff8123921e>] ? ida_get_new+0xe/0x10
[ 7796.165893]  [<ffffffff811cecc5>] ? proc_register+0x55/0x200
[ 7796.165893]  [<ffffffff811cf36f>] ? proc_mkdir_mode+0x3f/0x60
[ 7796.165893]  [<ffffffff811cf3a6>] ? proc_mkdir+0x16/0x20
[ 7796.165893]  [<ffffffff810d14eb>] ? register_handler_proc+0x11b/0x140
[ 7796.165893]  [<ffffffff810ce391>] ? __setup_irq+0x431/0x550
[ 7796.165893]  [<ffffffff8115522b>] ? kmem_cache_alloc_trace+0x12b/0x150
[ 7796.165893]  [<ffffffff812d4940>] ? xen_pcibk_control_isr+0x120/0x120
[ 7796.165893]  [<ffffffff810ce59a>] ? request_threaded_irq+0xea/0x1a0
[ 7796.165893]  [<ffffffff812d4917>] ? xen_pcibk_control_isr+0xf7/0x120
[ 7796.165893]  [<ffffffff812d4daa>] ? xen_pcibk_do_op+0x26a/0x590
[ 7796.165893]  [<ffffffff812d4b40>] ?
xen_pcibk_test_and_schedule_op+0x80/0x80
[ 7796.165893]  [<ffffffff8106bdeb>] ? process_one_work+0x11b/0x4d0
[ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
[ 7796.165893]  [<ffffffff8106c784>] ? worker_thread+0x164/0x340
[ 7796.165893]  [<ffffffff8100bdff>] ? xen_restore_fl_direct_reloc+0x4/0x4
[ 7796.165893]  [<ffffffff8106c620>] ? manage_workers.isra.25+0x220/0x220
[ 7796.165893]  [<ffffffff810717e3>] ? kthread+0x93/0xa0
[ 7796.165893]  [<ffffffff814495e4>] ? kernel_thread_helper+0x4/0x10
[ 7796.165893]  [<ffffffff814478c0>] ? retint_restore_args+0x5/0x6
[ 7796.165893]  [<ffffffff814495e0>] ? gs_change+0x13/0x13
[ 7796.165893] handlers:
[ 7796.165893] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
[ 7796.165893] Disabling IRQ #32

--f46d04428e5c7f1d9c04b96de826
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I had created package for arch linux xen 4.2 unstable and 3.3.0-rc1 linus f=
ixes kernel. So if I issue xl destroy domu my kernel crashes. Is there any =
patch that can stop those crashes.<br>=A07742.769113] xen-pciback[0000:02:0=
0.0] IRQ line is not shared with other domains. Turning ISR off<br>
[ 7748.502978] irq 32: nobody cared (try booting with the &quot;irqpoll&quo=
t; option)<br>[ 7748.503025] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-=
xen #1<br>[ 7748.503059] Call Trace:<br>[ 7748.503080]=A0 &lt;IRQ&gt;=A0 [&=
lt;ffffffff810cedbd&gt;] __report_bad_irq+0x3d/0xe0<br>
[ 7748.503130]=A0 [&lt;ffffffff810cf059&gt;] note_interrupt+0x159/0x210<br>=
[ 7748.503165]=A0 [&lt;ffffffff810cc8a8&gt;] handle_irq_event_percpu+0xc8/0=
x280<br>[ 7748.503202]=A0 [&lt;ffffffff8123c98b&gt;] ? radix_tree_lookup+0x=
b/0x10<br>
[ 7748.503235]=A0 [&lt;ffffffff810ccaa8&gt;] handle_irq_event+0x48/0x70<br>=
[ 7748.503268]=A0 [&lt;ffffffff810cfa2a&gt;] handle_fasteoi_irq+0x5a/0xe0<b=
r>[ 7748.503302]=A0 [&lt;ffffffff812c5864&gt;] __xen_evtchn_do_upcall+0x1a4=
/0x270<br>
[ 7748.503339]=A0 [&lt;ffffffff812c72ef&gt;] xen_evtchn_do_upcall+0x2f/0x50=
<br>[ 7748.503374]=A0 [&lt;ffffffff8144972e&gt;] xen_do_hypervisor_callback=
+0x1e/0x30<br>[ 7748.503409]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff810013aa&gt;] ?=
 hypercall_page+0x3aa/0x1000<br>
[ 7748.503453]=A0 [&lt;ffffffff810013aa&gt;] ? hypercall_page+0x3aa/0x1000<=
br>[ 7748.503487]=A0 [&lt;ffffffff8100b4b0&gt;] ? xen_safe_halt+0x10/0x20<b=
r>[ 7748.503519]=A0 [&lt;ffffffff8101e8d3&gt;] ? default_idle+0x53/0x280<br=
>[ 7748.503552]=A0 [&lt;ffffffff81014246&gt;] ? cpu_idle+0xe6/0x120<br>
[ 7748.503584]=A0 [&lt;ffffffff81422072&gt;] ? rest_init+0x96/0xa4<br>[ 774=
8.503615]=A0 [&lt;ffffffff818f6c0e&gt;] ? start_kernel+0x3cf/0x3dc<br>[ 774=
8.503648]=A0 [&lt;ffffffff818f6346&gt;] ? x86_64_start_reservations+0x131/0=
x135<br>
[ 7748.503684]=A0 [&lt;ffffffff818f8a3c&gt;] ? xen_start_kernel+0x5e0/0x5e7=
<br>[ 7748.503717] handlers:<br>[ 7748.503737] [&lt;ffffffff812d4940&gt;] x=
en_pcibk_guest_interrupt<br>[ 7748.503773] Disabling IRQ #32<br>[ 7748.6524=
02] irq 16: nobody cared (try booting with the &quot;irqpoll&quot; option)<=
br>
[ 7748.652445] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1<br>[ 77=
48.652479] Call Trace:<br>[ 7748.652499]=A0 &lt;IRQ&gt;=A0 [&lt;ffffffff810=
cedbd&gt;] __report_bad_irq+0x3d/0xe0<br>[ 7748.652545]=A0 [&lt;ffffffff810=
cf059&gt;] note_interrupt+0x159/0x210<br>
[ 7748.652579]=A0 [&lt;ffffffff810cc8a8&gt;] handle_irq_event_percpu+0xc8/0=
x280<br>[ 7748.652616]=A0 [&lt;ffffffff8103eae5&gt;] ? pvclock_clocksource_=
read+0x55/0xf0<br>[ 7748.652652]=A0 [&lt;ffffffff810ccaa8&gt;] handle_irq_e=
vent+0x48/0x70<br>
[ 7748.652684]=A0 [&lt;ffffffff8100b8e0&gt;] ? xen_clocksource_read+0x40/0x=
70<br>[ 7748.652719]=A0 [&lt;ffffffff810cfa2a&gt;] handle_fasteoi_irq+0x5a/=
0xe0<br>[ 7748.652754]=A0 [&lt;ffffffff812c5864&gt;] __xen_evtchn_do_upcall=
+0x1a4/0x270<br>
[ 7748.652791]=A0 [&lt;ffffffff812c72ef&gt;] xen_evtchn_do_upcall+0x2f/0x50=
<br>[ 7748.652826]=A0 [&lt;ffffffff8144972e&gt;] xen_do_hypervisor_callback=
+0x1e/0x30<br>[ 7748.652861]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff810013aa&gt;] ?=
 hypercall_page+0x3aa/0x1000<br>
[ 7748.652903]=A0 [&lt;ffffffff810013aa&gt;] ? hypercall_page+0x3aa/0x1000<=
br>[ 7748.652937]=A0 [&lt;ffffffff8100b4b0&gt;] ? xen_safe_halt+0x10/0x20<b=
r>[ 7748.652969]=A0 [&lt;ffffffff8101e8d3&gt;] ? default_idle+0x53/0x280<br=
>[ 7748.653002]=A0 [&lt;ffffffff81014246&gt;] ? cpu_idle+0xe6/0x120<br>
[ 7748.653034]=A0 [&lt;ffffffff81422072&gt;] ? rest_init+0x96/0xa4<br>[ 774=
8.653065]=A0 [&lt;ffffffff818f6c0e&gt;] ? start_kernel+0x3cf/0x3dc<br>[ 774=
8.653098]=A0 [&lt;ffffffff818f6346&gt;] ? x86_64_start_reservations+0x131/0=
x135<br>
[ 7748.653135]=A0 [&lt;ffffffff818f8a3c&gt;] ? xen_start_kernel+0x5e0/0x5e7=
<br>[ 7748.653167] handlers:<br>[ 7748.653194] [&lt;ffffffffa01d7100&gt;] a=
zx_interrupt<br>[ 7748.653226] Disabling IRQ #16<br>[ 7752.782419] vif vif-=
6-0: 2 reading script<br>
[ 7752.784350] xenbr0: port 3(vif6.0) entering forwarding state<br>[ 7752.7=
84611] xenbr0: port 3(vif6.0) entering disabled state<br>[ 7790.687530] xen=
-pciback: vpci: 0000:02:00.0: assign to virtual slot 0<br>[ 7790.817247] de=
vice vif7.0 entered promiscuous mode<br>
[ 7790.819947] ADDRCONF(NETDEV_UP): vif7.0: link is not ready<br>[ 7791.198=
278] xen-blkback:ring-ref 8, event-channel 8, protocol 1 (x86_64-abi)<br>[ =
7791.234632] ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready<br>[ 7791.=
234712] xenbr0: port 3(vif7.0) entering forwarding state<br>
[ 7791.234747] xenbr0: port 3(vif7.0) entering forwarding state<br>[ 7795.0=
90689] pciback 0000:02:00.0: enabling device (0000 -&gt; 0002)<br>[ 7795.09=
0756] xen: registering gsi 32 triggering 0 polarity 1<br>[ 7795.090769] xen=
_map_pirq_gsi: returning irq 32 for gsi 32<br>
[ 7795.090807] xen: --&gt; pirq=3D32 -&gt; irq=3D32 (gsi=3D32)<br>[ 7795.09=
0811] Already setup the GSI :32<br>[ 7796.165112] irq 32: nobody cared (try=
 booting with the &quot;irqpoll&quot; option)<br>[ 7796.165159] Pid: 1863, =
comm: kworker/0:1 Not tainted 3.3.0-rc1-xen #1<br>
[ 7796.165201] Call Trace:<br>[ 7796.165229]=A0 &lt;IRQ&gt;=A0 [&lt;fffffff=
f810cedbd&gt;] __report_bad_irq+0x3d/0xe0<br>[ 7796.165292]=A0 [&lt;fffffff=
f810cf059&gt;] note_interrupt+0x159/0x210<br>[ 7796.165335]=A0 [&lt;fffffff=
f810cc8a8&gt;] handle_irq_event_percpu+0xc8/0x280<br>
[ 7796.165383]=A0 [&lt;ffffffff810749bc&gt;] ? run_posix_cpu_timers+0x2c/0x=
7b0<br>[ 7796.165427]=A0 [&lt;ffffffff8123c98b&gt;] ? radix_tree_lookup+0xb=
/0x10<br>[ 7796.165469]=A0 [&lt;ffffffff810ccaa8&gt;] handle_irq_event+0x48=
/0x70<br>
[ 7796.165514]=A0 [&lt;ffffffff810cfa2a&gt;] handle_fasteoi_irq+0x5a/0xe0<b=
r>[ 7796.165563]=A0 [&lt;ffffffff812c5864&gt;] __xen_evtchn_do_upcall+0x1a4=
/0x270<br>[ 7796.165607]=A0 [&lt;ffffffff812c72ef&gt;] xen_evtchn_do_upcall=
+0x2f/0x50<br>
[ 7796.165650]=A0 [&lt;ffffffff810766a7&gt;] ? hrtimer_interrupt+0x127/0x20=
0<br>[ 7796.165695]=A0 [&lt;ffffffff8144972e&gt;] xen_do_hypervisor_callbac=
k+0x1e/0x30<br>[ 7796.165741]=A0 [&lt;ffffffff8100122a&gt;] ? hypercall_pag=
e+0x22a/0x1000<br>
[ 7796.165782]=A0 [&lt;ffffffff8100122a&gt;] ? hypercall_page+0x22a/0x1000<=
br>[ 7796.165825]=A0 [&lt;ffffffff8100b5ad&gt;] ? xen_force_evtchn_callback=
+0xd/0x10<br>[ 7796.165870]=A0 [&lt;ffffffff8100be12&gt;] ? check_events+0x=
12/0x20<br>
[ 7796.165893]=A0 [&lt;ffffffff8100bdb9&gt;] ? xen_irq_enable_direct_reloc+=
0x4/0x4<br>[ 7796.165893]=A0 [&lt;ffffffff81056dab&gt;] ? __do_softirq+0x7b=
/0x280<br>[ 7796.165893]=A0 [&lt;ffffffff8100b903&gt;] ? xen_clocksource_re=
ad+0x63/0x70<br>
[ 7796.165893]=A0 [&lt;ffffffff8100be12&gt;] ? check_events+0x12/0x20<br>[ =
7796.165893]=A0 [&lt;ffffffff814496dc&gt;] ? call_softirq+0x1c/0x30<br>[ 77=
96.165893]=A0 [&lt;ffffffff81017755&gt;] ? do_softirq+0x65/0xa0<br>[ 7796.1=
65893]=A0 [&lt;ffffffff810572f6&gt;] ? irq_exit+0xa6/0xc0<br>
[ 7796.165893]=A0 [&lt;ffffffff812c72f5&gt;] ? xen_evtchn_do_upcall+0x35/0x=
50<br>[ 7796.165893]=A0 [&lt;ffffffff8144972e&gt;] ? xen_do_hypervisor_call=
back+0x1e/0x30<br>[ 7796.165893]=A0 &lt;EOI&gt;=A0 [&lt;ffffffff81247f6b&gt=
;] ? find_next_zero_bit+0x4b/0xe0<br>
[ 7796.165893]=A0 [&lt;ffffffff81238f90&gt;] ? ida_get_new_above+0x70/0x2f0=
<br>[ 7796.165893]=A0 [&lt;ffffffff81239722&gt;] ? idr_pre_get+0x52/0x90<br=
>[ 7796.165893]=A0 [&lt;ffffffff8123921e&gt;] ? ida_get_new+0xe/0x10<br>[ 7=
796.165893]=A0 [&lt;ffffffff811cecc5&gt;] ? proc_register+0x55/0x200<br>
[ 7796.165893]=A0 [&lt;ffffffff811cf36f&gt;] ? proc_mkdir_mode+0x3f/0x60<br=
>[ 7796.165893]=A0 [&lt;ffffffff811cf3a6&gt;] ? proc_mkdir+0x16/0x20<br>[ 7=
796.165893]=A0 [&lt;ffffffff810d14eb&gt;] ? register_handler_proc+0x11b/0x1=
40<br>
[ 7796.165893]=A0 [&lt;ffffffff810ce391&gt;] ? __setup_irq+0x431/0x550<br>[=
 7796.165893]=A0 [&lt;ffffffff8115522b&gt;] ? kmem_cache_alloc_trace+0x12b/=
0x150<br>[ 7796.165893]=A0 [&lt;ffffffff812d4940&gt;] ? xen_pcibk_control_i=
sr+0x120/0x120<br>
[ 7796.165893]=A0 [&lt;ffffffff810ce59a&gt;] ? request_threaded_irq+0xea/0x=
1a0<br>[ 7796.165893]=A0 [&lt;ffffffff812d4917&gt;] ? xen_pcibk_control_isr=
+0xf7/0x120<br>[ 7796.165893]=A0 [&lt;ffffffff812d4daa&gt;] ? xen_pcibk_do_=
op+0x26a/0x590<br>
[ 7796.165893]=A0 [&lt;ffffffff812d4b40&gt;] ? xen_pcibk_test_and_schedule_=
op+0x80/0x80<br>[ 7796.165893]=A0 [&lt;ffffffff8106bdeb&gt;] ? process_one_=
work+0x11b/0x4d0<br>[ 7796.165893]=A0 [&lt;ffffffff8100be12&gt;] ? check_ev=
ents+0x12/0x20<br>
[ 7796.165893]=A0 [&lt;ffffffff8106c784&gt;] ? worker_thread+0x164/0x340<br=
>[ 7796.165893]=A0 [&lt;ffffffff8100bdff&gt;] ? xen_restore_fl_direct_reloc=
+0x4/0x4<br>[ 7796.165893]=A0 [&lt;ffffffff8106c620&gt;] ? manage_workers.i=
sra.25+0x220/0x220<br>
[ 7796.165893]=A0 [&lt;ffffffff810717e3&gt;] ? kthread+0x93/0xa0<br>[ 7796.=
165893]=A0 [&lt;ffffffff814495e4&gt;] ? kernel_thread_helper+0x4/0x10<br>[ =
7796.165893]=A0 [&lt;ffffffff814478c0&gt;] ? retint_restore_args+0x5/0x6<br=
>[ 7796.165893]=A0 [&lt;ffffffff814495e0&gt;] ? gs_change+0x13/0x13<br>
[ 7796.165893] handlers:<br>[ 7796.165893] [&lt;ffffffff812d4940&gt;] xen_p=
cibk_guest_interrupt<br>[ 7796.165893] Disabling IRQ #32<br><br>

--f46d04428e5c7f1d9c04b96de826--


--===============5720716172110386231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5720716172110386231==--


From xen-devel-bounces@lists.xen.org Mon Feb 20 23:57:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 23:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzd6A-0004PH-Ai; Mon, 20 Feb 2012 23:56:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Rzd69-0004P9-EY
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 23:56:49 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329782154!53536712!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM0ODU4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20778 invoked from network); 20 Feb 2012 23:55:55 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 23:55:55 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Feb 2012 15:56:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108756339"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2012 15:56:45 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 07:54:06 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 21 Feb 2012 07:54:06 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 07:54:05 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: young zhang <young.zhang.free@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
	due to tm->tm_year
Thread-Index: AQHM7+D1YgIopIzOmU+uANcdOe+iSpZGdQtA
Date: Mon, 20 Feb 2012 23:54:05 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
In-Reply-To: <CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@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: Kurt Hackel <Kurt.Hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: young zhang [mailto:young.zhang.free@gmail.com]
> Sent: Monday, February 20, 2012 11:04 PM
> To: Zhang, Yang Z
> Cc: ANNIE LI; xen-devel@lists.xensource.com; Kurt Hackel; Dan Magenheimer;
> Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
> to tm->tm_year
> 
> The mktime which used in xen is different from standard C. I think the best way is
> change it same as normal mktime, or else, other people will make the same
> mistake too.

yes. The name will mislead the people who not look into the code, including me. :)

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 20 23:57:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 20 Feb 2012 23:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzd6A-0004PH-Ai; Mon, 20 Feb 2012 23:56:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1Rzd69-0004P9-EY
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 23:56:49 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329782154!53536712!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM0ODU4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20778 invoked from network); 20 Feb 2012 23:55:55 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 23:55:55 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Feb 2012 15:56:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108756339"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2012 15:56:45 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 07:54:06 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 21 Feb 2012 07:54:06 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 07:54:05 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: young zhang <young.zhang.free@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
	due to tm->tm_year
Thread-Index: AQHM7+D1YgIopIzOmU+uANcdOe+iSpZGdQtA
Date: Mon, 20 Feb 2012 23:54:05 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
In-Reply-To: <CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@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: Kurt Hackel <Kurt.Hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: young zhang [mailto:young.zhang.free@gmail.com]
> Sent: Monday, February 20, 2012 11:04 PM
> To: Zhang, Yang Z
> Cc: ANNIE LI; xen-devel@lists.xensource.com; Kurt Hackel; Dan Magenheimer;
> Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
> to tm->tm_year
> 
> The mktime which used in xen is different from standard C. I think the best way is
> change it same as normal mktime, or else, other people will make the same
> mistake too.

yes. The name will mislead the people who not look into the code, including me. :)

best regards
yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdKT-00055T-6F; Tue, 21 Feb 2012 00:11:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdKS-00054d-0r
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329783087!16128493!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29193 invoked from network); 21 Feb 2012 00:11:28 -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; 21 Feb 2012 00:11: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 q1L0BFaC015562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11:16 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1L0BEZA008631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:15 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
	q1L0BEww013058; Mon, 20 Feb 2012 18:11:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 527BA40482; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:48 -0500
Message-Id: <1329782868-1696-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
References: <20120214183006.GJ12984@reaktio.net>
	<1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F42E124.0078,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [PATCH 3/3] xen/processor-passthru: Remove the
	print_hex_dump - as it is difficult to decipher 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

It is much easier to just look in the hypervisor output and figure
out what went wrong. For that use, cpufreq=verbose on Xen command line.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/processor-passthru.c |   25 ++++++++-----------------
 1 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/xen/processor-passthru.c b/drivers/xen/processor-passthru.c
index 9ca2965..d731f55 100644
--- a/drivers/xen/processor-passthru.c
+++ b/drivers/xen/processor-passthru.c
@@ -119,14 +119,10 @@ static int xen_push_cxx_to_hypervisor(struct acpi_processor *_pr)
 	if (!no_hypercall && xen_initial_domain())
 		ret = HYPERVISOR_dom0_op(&op);
 
-	if (ret) {
-		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
-		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
-				     sizeof(struct xen_platform_op));
-		print_hex_dump_bytes("Cx: ", DUMP_PREFIX_NONE, xen_cx_states,
-				     _pr->power.count *
-				     sizeof(struct xen_processor_cx));
-	}
+	if (ret)
+		pr_err(DRV_NAME "(CX): Hypervisor returned (%d) for ACPI ID: %d\n",
+		       ret, _pr->acpi_id);
+
 	kfree(xen_cx_states);
 
 	return ret;
@@ -229,15 +225,10 @@ static int xen_push_pxx_to_hypervisor(struct acpi_processor *_pr)
 	if (!no_hypercall && xen_initial_domain())
 		ret = HYPERVISOR_dom0_op(&op);
 
-	if (ret) {
-		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
-		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
-				     sizeof(struct xen_platform_op));
-		if (!IS_ERR_OR_NULL(xen_states))
-			print_hex_dump_bytes("Pxx:", DUMP_PREFIX_NONE, xen_states,
-				     _pr->performance->state_count *
-				     sizeof(struct xen_processor_px));
-	}
+	if (ret)
+		pr_err(DRV_NAME "(_PXX): Hypervisor returned (%d) for ACPI ID %d\n",
+		       ret, _pr->acpi_id);
+
 	if (!IS_ERR_OR_NULL(xen_states))
 		kfree(xen_states);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdKT-00055T-6F; Tue, 21 Feb 2012 00:11:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdKS-00054d-0r
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329783087!16128493!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29193 invoked from network); 21 Feb 2012 00:11:28 -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; 21 Feb 2012 00:11: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 q1L0BFaC015562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11:16 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1L0BEZA008631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:15 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
	q1L0BEww013058; Mon, 20 Feb 2012 18:11:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 527BA40482; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:48 -0500
Message-Id: <1329782868-1696-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
References: <20120214183006.GJ12984@reaktio.net>
	<1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F42E124.0078,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [PATCH 3/3] xen/processor-passthru: Remove the
	print_hex_dump - as it is difficult to decipher 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

It is much easier to just look in the hypervisor output and figure
out what went wrong. For that use, cpufreq=verbose on Xen command line.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/processor-passthru.c |   25 ++++++++-----------------
 1 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/xen/processor-passthru.c b/drivers/xen/processor-passthru.c
index 9ca2965..d731f55 100644
--- a/drivers/xen/processor-passthru.c
+++ b/drivers/xen/processor-passthru.c
@@ -119,14 +119,10 @@ static int xen_push_cxx_to_hypervisor(struct acpi_processor *_pr)
 	if (!no_hypercall && xen_initial_domain())
 		ret = HYPERVISOR_dom0_op(&op);
 
-	if (ret) {
-		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
-		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
-				     sizeof(struct xen_platform_op));
-		print_hex_dump_bytes("Cx: ", DUMP_PREFIX_NONE, xen_cx_states,
-				     _pr->power.count *
-				     sizeof(struct xen_processor_cx));
-	}
+	if (ret)
+		pr_err(DRV_NAME "(CX): Hypervisor returned (%d) for ACPI ID: %d\n",
+		       ret, _pr->acpi_id);
+
 	kfree(xen_cx_states);
 
 	return ret;
@@ -229,15 +225,10 @@ static int xen_push_pxx_to_hypervisor(struct acpi_processor *_pr)
 	if (!no_hypercall && xen_initial_domain())
 		ret = HYPERVISOR_dom0_op(&op);
 
-	if (ret) {
-		pr_err(DRV_NAME ": Failed to send to hypervisor (rc:%d)\n", ret);
-		print_hex_dump_bytes("OP: ", DUMP_PREFIX_NONE, &op,
-				     sizeof(struct xen_platform_op));
-		if (!IS_ERR_OR_NULL(xen_states))
-			print_hex_dump_bytes("Pxx:", DUMP_PREFIX_NONE, xen_states,
-				     _pr->performance->state_count *
-				     sizeof(struct xen_processor_px));
-	}
+	if (ret)
+		pr_err(DRV_NAME "(_PXX): Hypervisor returned (%d) for ACPI ID %d\n",
+		       ret, _pr->acpi_id);
+
 	if (!IS_ERR_OR_NULL(xen_states))
 		kfree(xen_states);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdKS-00055J-Pu; Tue, 21 Feb 2012 00:11:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdKQ-00054b-Rl
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329783086!12331024!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29216 invoked from network); 21 Feb 2012 00:11:28 -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; 21 Feb 2012 00:11:28 -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 q1L0BFbM023525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1L0BEHS023267
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:14 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1L0BEru001667; Mon, 20 Feb 2012 18:11:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 492534047A; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:47 -0500
Message-Id: <1329782868-1696-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
References: <20120214183006.GJ12984@reaktio.net>
	<1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F42E124.0049,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [PATCH 2/3] xen/processor-passthru: Support vCPU !=
	pCPU - aka dom0_max_vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By enumerating the ACPI CPU ID - similar to how sprocessor_core
does it - we can extract those values and provide them to the
hypervisor. For this to work, we need to wean ourself off the
cpumask type macros as they are keyed to nr_cpu_ids (which in
turn is reset to cpu_online_cpus()). We convert the framework
to use a bitmap and set the ACPI ID in it instead of the APIC ID.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/processor-passthru.c |  129 ++++++++++++++++++++++++++++++++------
 1 files changed, 110 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/processor-passthru.c b/drivers/xen/processor-passthru.c
index abfcbe4..9ca2965 100644
--- a/drivers/xen/processor-passthru.c
+++ b/drivers/xen/processor-passthru.c
@@ -14,14 +14,6 @@
  *
  */
 
-/*
- *  Known limitations
- *
- * The driver can only handle up to  for_each_possible_cpu().
- * Meaning if you boot with dom0_max_cpus=X it will _only_ parse up to X
- * processors.
- */
-
 #include <linux/cpumask.h>
 #include <linux/cpufreq.h>
 #include <linux/kernel.h>
@@ -46,8 +38,15 @@ MODULE_PARM_DESC(off, "Inhibit the hypercall.");
 static int no_hypercall;
 module_param_named(off, no_hypercall, int, 0400);
 
-static DEFINE_MUTEX(processors_done_mutex);
-static DECLARE_BITMAP(processors_done, NR_CPUS);
+static DEFINE_MUTEX(acpi_ids_mutex);
+
+/*
+ * Don't think convert this to cpumask_var_t or use cpumask_bit - as those are
+ * keyed of cpu_present which can be less than what we want to put in
+ */
+#define NR_ACPI_CPUS NR_CPUS
+#define MAX_ACPI_BITS (BITS_TO_LONGS(NR_ACPI_CPUS))
+static unsigned long *acpi_ids_done;
 
 #define POLL_TIMER msecs_to_jiffies(5000 /* 5 sec */)
 static struct task_struct *xen_processor_thread;
@@ -249,13 +248,13 @@ static int xen_push_pxx_to_hypervisor(struct acpi_processor *_pr)
  * so that there is only one caller. This is so that we won't
  * race with the CPU hotplug code.
  */
-static int xen_process_data(struct acpi_processor *_pr, int cpu)
+static int xen_process_data(struct acpi_processor *_pr)
 {
 	int err = 0;
 
-	mutex_lock(&processors_done_mutex);
-	if (cpumask_test_cpu(cpu, to_cpumask(processors_done))) {
-		mutex_unlock(&processors_done_mutex);
+	mutex_lock(&acpi_ids_mutex);
+	if (__test_and_set_bit(_pr->acpi_id, acpi_ids_done)) {
+		mutex_unlock(&acpi_ids_mutex);
 		return -EBUSY;
 	}
 	if (_pr->flags.power)
@@ -264,14 +263,76 @@ static int xen_process_data(struct acpi_processor *_pr, int cpu)
 	if (_pr->performance && _pr->performance->states)
 		err |= xen_push_pxx_to_hypervisor(_pr);
 
-	cpumask_set_cpu(cpu, to_cpumask(processors_done));
-	mutex_unlock(&processors_done_mutex);
+	mutex_unlock(&acpi_ids_mutex);
 	return err;
 }
 
+/*
+ * Do not convert this to cpumask_var_t as that structure is limited to
+ * nr_cpu_ids and we can go beyound that.
+ */
+static unsigned long *acpi_id_present;
+
+static acpi_status
+xen_acpi_id_present(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	u32 acpi_id;
+	acpi_status status;
+	acpi_object_type acpi_type;
+	unsigned long long tmp;
+	union acpi_object object = { 0 };
+	struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
+
+	status = acpi_get_type(handle, &acpi_type);
+	if (ACPI_FAILURE(status))
+		return AE_OK;
+
+	switch (acpi_type) {
+	case ACPI_TYPE_PROCESSOR:
+		status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id = object.processor.proc_id;
+		break;
+	case ACPI_TYPE_DEVICE:
+		status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id = tmp;
+		break;
+	default:
+		return AE_OK;
+	}
+	if (acpi_id > NR_ACPI_CPUS) {
+		WARN_ONCE(1, "There are %d ACPI processors, but kernel can only do %d!\n",
+		     acpi_id, NR_ACPI_CPUS);
+		return AE_OK;
+	}
+	__set_bit(acpi_id, acpi_id_present);
+
+	return AE_OK;
+}
+static unsigned int xen_enumerate_acpi_id(void)
+{
+	unsigned int n = 0;
+
+	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+			    ACPI_UINT32_MAX,
+			    xen_acpi_id_present, NULL, NULL, NULL);
+	acpi_get_devices("ACPI0007", xen_acpi_id_present, NULL, NULL);
+
+	mutex_lock(&acpi_ids_mutex);
+	if (!bitmap_equal(acpi_id_present, acpi_ids_done, MAX_ACPI_BITS))
+		n = bitmap_weight(acpi_id_present, MAX_ACPI_BITS);
+	mutex_unlock(&acpi_ids_mutex);
+
+	return n;
+}
+
 static int xen_processor_check(void)
 {
 	struct cpufreq_policy *policy;
+	struct acpi_processor *pr_backup;
 	int cpu;
 
 	policy = cpufreq_cpu_get(smp_processor_id());
@@ -282,15 +343,40 @@ static int xen_processor_check(void)
 	for_each_online_cpu(cpu) {
 		struct acpi_processor *_pr;
 
-		_pr = per_cpu(processors, cpu);
+		_pr = per_cpu(processors, cpu /* APIC ID */);
 		if (!_pr)
 			continue;
 
-		(void)xen_process_data(_pr, cpu);
+		if (!pr_backup) {
+			pr_backup = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+			memcpy(pr_backup, _pr, sizeof(struct acpi_processor));
+		}
+		(void)xen_process_data(_pr);
 	}
 	put_online_cpus();
 
 	cpufreq_cpu_put(policy);
+
+	/* All online CPUs have been processed at this stage. Now verify
+	 * whether in fact "online CPUs" == physical CPUs.
+	 */
+	acpi_id_present = kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_KERNEL);
+	if (!acpi_id_present)
+		goto err_out;
+	memset(acpi_id_present, 0, MAX_ACPI_BITS * sizeof(unsigned long));
+
+	if (xen_enumerate_acpi_id() && pr_backup) {
+		for_each_set_bit(cpu, acpi_id_present, MAX_ACPI_BITS) {
+			pr_backup->acpi_id = cpu;
+			/* We will get -EBUSY if it has been programmed already. */
+			(void)xen_process_data(pr_backup);
+		}
+	}
+	kfree(acpi_id_present);
+	acpi_id_present = NULL;
+err_out:
+	kfree(pr_backup);
+	pr_backup = NULL;
 	return 0;
 }
 /*
@@ -329,7 +415,7 @@ static int xen_cpu_soft_notify(struct notifier_block *nfb,
 	struct acpi_processor *_pr = per_cpu(processors, cpu);
 
 	if (action == CPU_ONLINE && _pr)
-		(void)xen_process_data(_pr, cpu);
+		(void)xen_process_data(_pr);
 
 	return NOTIFY_OK;
 }
@@ -379,6 +465,10 @@ static int __init xen_processor_passthru_init(void)
 	if (rc)
 		return rc;
 
+	acpi_ids_done = kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_KERNEL);
+	if (!acpi_ids_done)
+		return -ENOMEM;
+	memset(acpi_ids_done, 0, MAX_ACPI_BITS * sizeof(unsigned long));
 	xen_processor_thread = kthread_run(xen_processor_thread_func, NULL, DRV_NAME);
 	if (IS_ERR(xen_processor_thread)) {
 		pr_err(DRV_NAME ": Failed to create thread. Aborting.\n");
@@ -392,6 +482,7 @@ static void __exit xen_processor_passthru_exit(void)
 	unregister_hotcpu_notifier(&xen_cpu_notifier);
 	if (xen_processor_thread)
 		kthread_stop(xen_processor_thread);
+	kfree(acpi_ids_done);
 }
 late_initcall(xen_processor_passthru_init);
 module_exit(xen_processor_passthru_exit);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdKS-00055J-Pu; Tue, 21 Feb 2012 00:11:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdKQ-00054b-Rl
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329783086!12331024!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29216 invoked from network); 21 Feb 2012 00:11:28 -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; 21 Feb 2012 00:11:28 -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 q1L0BFbM023525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1L0BEHS023267
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:14 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1L0BEru001667; Mon, 20 Feb 2012 18:11:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 492534047A; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:47 -0500
Message-Id: <1329782868-1696-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
References: <20120214183006.GJ12984@reaktio.net>
	<1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F42E124.0049,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [PATCH 2/3] xen/processor-passthru: Support vCPU !=
	pCPU - aka dom0_max_vcpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By enumerating the ACPI CPU ID - similar to how sprocessor_core
does it - we can extract those values and provide them to the
hypervisor. For this to work, we need to wean ourself off the
cpumask type macros as they are keyed to nr_cpu_ids (which in
turn is reset to cpu_online_cpus()). We convert the framework
to use a bitmap and set the ACPI ID in it instead of the APIC ID.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/processor-passthru.c |  129 ++++++++++++++++++++++++++++++++------
 1 files changed, 110 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/processor-passthru.c b/drivers/xen/processor-passthru.c
index abfcbe4..9ca2965 100644
--- a/drivers/xen/processor-passthru.c
+++ b/drivers/xen/processor-passthru.c
@@ -14,14 +14,6 @@
  *
  */
 
-/*
- *  Known limitations
- *
- * The driver can only handle up to  for_each_possible_cpu().
- * Meaning if you boot with dom0_max_cpus=X it will _only_ parse up to X
- * processors.
- */
-
 #include <linux/cpumask.h>
 #include <linux/cpufreq.h>
 #include <linux/kernel.h>
@@ -46,8 +38,15 @@ MODULE_PARM_DESC(off, "Inhibit the hypercall.");
 static int no_hypercall;
 module_param_named(off, no_hypercall, int, 0400);
 
-static DEFINE_MUTEX(processors_done_mutex);
-static DECLARE_BITMAP(processors_done, NR_CPUS);
+static DEFINE_MUTEX(acpi_ids_mutex);
+
+/*
+ * Don't think convert this to cpumask_var_t or use cpumask_bit - as those are
+ * keyed of cpu_present which can be less than what we want to put in
+ */
+#define NR_ACPI_CPUS NR_CPUS
+#define MAX_ACPI_BITS (BITS_TO_LONGS(NR_ACPI_CPUS))
+static unsigned long *acpi_ids_done;
 
 #define POLL_TIMER msecs_to_jiffies(5000 /* 5 sec */)
 static struct task_struct *xen_processor_thread;
@@ -249,13 +248,13 @@ static int xen_push_pxx_to_hypervisor(struct acpi_processor *_pr)
  * so that there is only one caller. This is so that we won't
  * race with the CPU hotplug code.
  */
-static int xen_process_data(struct acpi_processor *_pr, int cpu)
+static int xen_process_data(struct acpi_processor *_pr)
 {
 	int err = 0;
 
-	mutex_lock(&processors_done_mutex);
-	if (cpumask_test_cpu(cpu, to_cpumask(processors_done))) {
-		mutex_unlock(&processors_done_mutex);
+	mutex_lock(&acpi_ids_mutex);
+	if (__test_and_set_bit(_pr->acpi_id, acpi_ids_done)) {
+		mutex_unlock(&acpi_ids_mutex);
 		return -EBUSY;
 	}
 	if (_pr->flags.power)
@@ -264,14 +263,76 @@ static int xen_process_data(struct acpi_processor *_pr, int cpu)
 	if (_pr->performance && _pr->performance->states)
 		err |= xen_push_pxx_to_hypervisor(_pr);
 
-	cpumask_set_cpu(cpu, to_cpumask(processors_done));
-	mutex_unlock(&processors_done_mutex);
+	mutex_unlock(&acpi_ids_mutex);
 	return err;
 }
 
+/*
+ * Do not convert this to cpumask_var_t as that structure is limited to
+ * nr_cpu_ids and we can go beyound that.
+ */
+static unsigned long *acpi_id_present;
+
+static acpi_status
+xen_acpi_id_present(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	u32 acpi_id;
+	acpi_status status;
+	acpi_object_type acpi_type;
+	unsigned long long tmp;
+	union acpi_object object = { 0 };
+	struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
+
+	status = acpi_get_type(handle, &acpi_type);
+	if (ACPI_FAILURE(status))
+		return AE_OK;
+
+	switch (acpi_type) {
+	case ACPI_TYPE_PROCESSOR:
+		status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id = object.processor.proc_id;
+		break;
+	case ACPI_TYPE_DEVICE:
+		status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id = tmp;
+		break;
+	default:
+		return AE_OK;
+	}
+	if (acpi_id > NR_ACPI_CPUS) {
+		WARN_ONCE(1, "There are %d ACPI processors, but kernel can only do %d!\n",
+		     acpi_id, NR_ACPI_CPUS);
+		return AE_OK;
+	}
+	__set_bit(acpi_id, acpi_id_present);
+
+	return AE_OK;
+}
+static unsigned int xen_enumerate_acpi_id(void)
+{
+	unsigned int n = 0;
+
+	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+			    ACPI_UINT32_MAX,
+			    xen_acpi_id_present, NULL, NULL, NULL);
+	acpi_get_devices("ACPI0007", xen_acpi_id_present, NULL, NULL);
+
+	mutex_lock(&acpi_ids_mutex);
+	if (!bitmap_equal(acpi_id_present, acpi_ids_done, MAX_ACPI_BITS))
+		n = bitmap_weight(acpi_id_present, MAX_ACPI_BITS);
+	mutex_unlock(&acpi_ids_mutex);
+
+	return n;
+}
+
 static int xen_processor_check(void)
 {
 	struct cpufreq_policy *policy;
+	struct acpi_processor *pr_backup;
 	int cpu;
 
 	policy = cpufreq_cpu_get(smp_processor_id());
@@ -282,15 +343,40 @@ static int xen_processor_check(void)
 	for_each_online_cpu(cpu) {
 		struct acpi_processor *_pr;
 
-		_pr = per_cpu(processors, cpu);
+		_pr = per_cpu(processors, cpu /* APIC ID */);
 		if (!_pr)
 			continue;
 
-		(void)xen_process_data(_pr, cpu);
+		if (!pr_backup) {
+			pr_backup = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+			memcpy(pr_backup, _pr, sizeof(struct acpi_processor));
+		}
+		(void)xen_process_data(_pr);
 	}
 	put_online_cpus();
 
 	cpufreq_cpu_put(policy);
+
+	/* All online CPUs have been processed at this stage. Now verify
+	 * whether in fact "online CPUs" == physical CPUs.
+	 */
+	acpi_id_present = kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_KERNEL);
+	if (!acpi_id_present)
+		goto err_out;
+	memset(acpi_id_present, 0, MAX_ACPI_BITS * sizeof(unsigned long));
+
+	if (xen_enumerate_acpi_id() && pr_backup) {
+		for_each_set_bit(cpu, acpi_id_present, MAX_ACPI_BITS) {
+			pr_backup->acpi_id = cpu;
+			/* We will get -EBUSY if it has been programmed already. */
+			(void)xen_process_data(pr_backup);
+		}
+	}
+	kfree(acpi_id_present);
+	acpi_id_present = NULL;
+err_out:
+	kfree(pr_backup);
+	pr_backup = NULL;
 	return 0;
 }
 /*
@@ -329,7 +415,7 @@ static int xen_cpu_soft_notify(struct notifier_block *nfb,
 	struct acpi_processor *_pr = per_cpu(processors, cpu);
 
 	if (action == CPU_ONLINE && _pr)
-		(void)xen_process_data(_pr, cpu);
+		(void)xen_process_data(_pr);
 
 	return NOTIFY_OK;
 }
@@ -379,6 +465,10 @@ static int __init xen_processor_passthru_init(void)
 	if (rc)
 		return rc;
 
+	acpi_ids_done = kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_KERNEL);
+	if (!acpi_ids_done)
+		return -ENOMEM;
+	memset(acpi_ids_done, 0, MAX_ACPI_BITS * sizeof(unsigned long));
 	xen_processor_thread = kthread_run(xen_processor_thread_func, NULL, DRV_NAME);
 	if (IS_ERR(xen_processor_thread)) {
 		pr_err(DRV_NAME ": Failed to create thread. Aborting.\n");
@@ -392,6 +482,7 @@ static void __exit xen_processor_passthru_exit(void)
 	unregister_hotcpu_notifier(&xen_cpu_notifier);
 	if (xen_processor_thread)
 		kthread_stop(xen_processor_thread);
+	kfree(acpi_ids_done);
 }
 late_initcall(xen_processor_passthru_init);
 module_exit(xen_processor_passthru_exit);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00: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 1RzdKQ-00054i-R9; Tue, 21 Feb 2012 00:11:34 +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 1RzdKO-00054c-Vg
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329782958!62120742!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21755 invoked from network); 21 Feb 2012 00:09:19 -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 Feb 2012 00:09: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 q1L0BFOI023527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11: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
	q1L0BEkG023272
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:15 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1L0BEi0028981; Mon, 20 Feb 2012 18:11:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3E7EC4046C; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:46 -0500
Message-Id: <1329782868-1696-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
References: <20120214183006.GJ12984@reaktio.net>
	<1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F42E124.0067,ss=1,re=-2.300,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [PATCH 1/3] xen/processor-passthru: Change the name to
	processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U3VnZ2VzdGVkLWJ5OiAgUGFzaSBLw6Rya2vDpGluZW4gPHBhc2lrQGlraS5maT4KU2lnbmVkLW9m
Zi1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0K
IGRyaXZlcnMveGVuL0tjb25maWcgICAgICAgICAgICAgIHwgICAgMiArLQogZHJpdmVycy94ZW4v
TWFrZWZpbGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wcm9jZXNzb3ItaGFy
dmVzdC5jICB8ICAzOTcgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIGRy
aXZlcnMveGVuL3Byb2Nlc3Nvci1wYXNzdGhydS5jIHwgIDM5NyArKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKwogNCBmaWxlcyBjaGFuZ2VkLCAzOTkgaW5zZXJ0aW9ucygrKSwg
Mzk5IGRlbGV0aW9ucygtKQogZGVsZXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3Byb2Nlc3Nv
ci1oYXJ2ZXN0LmMKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi9wcm9jZXNzb3ItcGFz
c3RocnUuYwoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL0tjb25maWcgYi9kcml2ZXJzL3hlbi9L
Y29uZmlnCmluZGV4IDEyNjE4M2YuLmFmNWUwNjIgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL0tj
b25maWcKKysrIGIvZHJpdmVycy94ZW4vS2NvbmZpZwpAQCAtMTc4LDcgKzE3OCw3IEBAIGNvbmZp
ZyBYRU5fUFJJVkNNRAogCWRlcGVuZHMgb24gWEVOCiAJZGVmYXVsdCBtCiAKLWNvbmZpZyBYRU5f
UFJPQ0VTU09SX0hBUlZFU1QKK2NvbmZpZyBYRU5fUFJPQ0VTU09SX1BBU1NUSFJVCiAJdHJpc3Rh
dGUgIlByb2Nlc3NvciBwYXNzdGhyb3VnaCBkcml2ZXIgZm9yIFhlbiIKIAlkZXBlbmRzIG9uIFhF
TgogCWRlcGVuZHMgb24gQUNQSV9QUk9DRVNTT1IKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01h
a2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggODU2Y2ZjNi4uY2UyMzVlN2EgMTAw
NjQ0Ci0tLSBhL2RyaXZlcnMveGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxl
CkBAIC0yMCw3ICsyMCw3IEBAIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJCSs9IHN3aW90bGIt
eGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubwogb2JqLSQoQ09ORklHX1hF
Tl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05GSUdfWEVOX1BSSVZD
TUQpCQkrPSB4ZW4tcHJpdmNtZC5vCi1vYmotJChDT05GSUdfWEVOX1BST0NFU1NPUl9IQVJWRVNU
KQkrPSBwcm9jZXNzb3ItaGFydmVzdC5vCitvYmotJChDT05GSUdfWEVOX1BST0NFU1NPUl9QQVNT
VEhSVSkJKz0gcHJvY2Vzc29yLXBhc3N0aHJ1Lm8KIHhlbi1ldnRjaG4teQkJCQk6PSBldnRjaG4u
bwogeGVuLWdudGRldi15CQkJCTo9IGdudGRldi5vCiB4ZW4tZ250YWxsb2MteQkJCQk6PSBnbnRh
bGxvYy5vCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wcm9jZXNzb3ItaGFydmVzdC5jIGIvZHJp
dmVycy94ZW4vcHJvY2Vzc29yLWhhcnZlc3QuYwpkZWxldGVkIGZpbGUgbW9kZSAxMDA2NDQKaW5k
ZXggNTA2ODFlMi4uMDAwMDAwMAotLS0gYS9kcml2ZXJzL3hlbi9wcm9jZXNzb3ItaGFydmVzdC5j
CisrKyAvZGV2L251bGwKQEAgLTEsMzk3ICswLDAgQEAKLS8qCi0gKiBDb3B5cmlnaHQgMjAxMiBi
eSBPcmFjbGUgSW5jCi0gKiBBdXRob3I6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndp
bGtAb3JhY2xlLmNvbT4KLSAqCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7
IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQKLSAqIHVuZGVyIHRoZSB0
ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsCi0g
KiB2ZXJzaW9uIDIsIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
LgotICoKLSAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSBpdCB3aWxs
IGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQKLSAqIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo
ZSBpbXBsaWVkIHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBvcgotICogRklUTkVTUyBGT1Ig
QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IGZvcgotICogbW9yZSBkZXRhaWxzLgotICoKLSAqLwotCi0vKgotICogIEtub3duIGxpbWl0YXRp
b25zCi0gKgotICogVGhlIGRyaXZlciBjYW4gb25seSBoYW5kbGUgdXAgdG8gIGZvcl9lYWNoX3Bv
c3NpYmxlX2NwdSgpLgotICogTWVhbmluZyBpZiB5b3UgYm9vdCB3aXRoIGRvbTBfbWF4X2NwdXM9
WCBpdCB3aWxsIF9vbmx5XyBwYXJzZSB1cCB0byBYCi0gKiBwcm9jZXNzb3JzLgotICovCi0KLSNp
bmNsdWRlIDxsaW51eC9jcHVtYXNrLmg+Ci0jaW5jbHVkZSA8bGludXgvY3B1ZnJlcS5oPgotI2lu
Y2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgotI2luY2x1ZGUgPGxpbnV4L2t0aHJlYWQuaD4KLSNpbmNs
dWRlIDxsaW51eC9pbml0Lmg+Ci0jaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+Ci0jaW5jbHVkZSA8
bGludXgvdHlwZXMuaD4KLSNpbmNsdWRlIDxhY3BpL2FjcGlfYnVzLmg+Ci0jaW5jbHVkZSA8YWNw
aS9hY3BpX2RyaXZlcnMuaD4KLSNpbmNsdWRlIDxhY3BpL3Byb2Nlc3Nvci5oPgotCi0jaW5jbHVk
ZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgotI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxs
Lmg+Ci0KLSNkZWZpbmUgRFJWX05BTUUgInByb2Nlc3Nvci1wYXNzdGhyb3VnaC14ZW4iCi1NT0RV
TEVfQVVUSE9SKCJLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+
Iik7Ci1NT0RVTEVfREVTQ1JJUFRJT04oIkFDUEkgUG93ZXIgTWFuYWdlbWVudCBkcml2ZXIgdG8g
cGFzcyBDeCBhbmQgUHh4IGRhdGEgdG8gWGVuIGh5cGVydmlzb3IiKTsKLU1PRFVMRV9MSUNFTlNF
KCJHUEwiKTsKLQotCi1NT0RVTEVfUEFSTV9ERVNDKG9mZiwgIkluaGliaXQgdGhlIGh5cGVyY2Fs
bC4iKTsKLXN0YXRpYyBpbnQgbm9faHlwZXJjYWxsOwotbW9kdWxlX3BhcmFtX25hbWVkKG9mZiwg
bm9faHlwZXJjYWxsLCBpbnQsIDA0MDApOwotCi1zdGF0aWMgREVGSU5FX01VVEVYKHByb2Nlc3Nv
cnNfZG9uZV9tdXRleCk7Ci1zdGF0aWMgREVDTEFSRV9CSVRNQVAocHJvY2Vzc29yc19kb25lLCBO
Ul9DUFVTKTsKLQotI2RlZmluZSBQT0xMX1RJTUVSIG1zZWNzX3RvX2ppZmZpZXMoNTAwMCAvKiA1
IHNlYyAqLykKLXN0YXRpYyBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnhlbl9wcm9jZXNzb3JfdGhyZWFk
OwotCi1zdGF0aWMgaW50IHhlbl9wdXNoX2N4eF90b19oeXBlcnZpc29yKHN0cnVjdCBhY3BpX3By
b2Nlc3NvciAqX3ByKQotewotCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7Ci0JCS5jbWQJ
CQk9IFhFTlBGX3NldF9wcm9jZXNzb3JfcG1pbmZvLAotCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBY
RU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKLQkJLnUuc2V0X3BtaW5mby5pZAk9IF9wci0+YWNwaV9p
ZCwKLQkJLnUuc2V0X3BtaW5mby50eXBlCT0gWEVOX1BNX0NYLAotCX07Ci0Jc3RydWN0IHhlbl9w
cm9jZXNzb3JfY3ggKnhlbl9jeCwgKnhlbl9jeF9zdGF0ZXMgPSBOVUxMOwotCXN0cnVjdCBhY3Bp
X3Byb2Nlc3Nvcl9jeCAqY3g7Ci0JaW50IGksIG9rLCByZXQgPSAwOwotCi0JeGVuX2N4X3N0YXRl
cyA9IGtjYWxsb2MoX3ByLT5wb3dlci5jb3VudCwKLQkJCQlzaXplb2Yoc3RydWN0IHhlbl9wcm9j
ZXNzb3JfY3gpLCBHRlBfS0VSTkVMKTsKLQlpZiAoIXhlbl9jeF9zdGF0ZXMpCi0JCXJldHVybiAt
RU5PTUVNOwotCi0JZm9yIChvayA9IDAsIGkgPSAxOyBpIDw9IF9wci0+cG93ZXIuY291bnQ7IGkr
KykgewotCQljeCA9ICZfcHItPnBvd2VyLnN0YXRlc1tpXTsKLQkJaWYgKCFjeC0+dmFsaWQpCi0J
CQljb250aW51ZTsKLQotCQl4ZW5fY3ggPSAmKHhlbl9jeF9zdGF0ZXNbb2srK10pOwotCi0JCXhl
bl9jeC0+cmVnLnNwYWNlX2lkID0gQUNQSV9BRFJfU1BBQ0VfU1lTVEVNX0lPOwotCQlpZiAoY3gt
PmVudHJ5X21ldGhvZCA9PSBBQ1BJX0NTVEFURV9TWVNURU1JTykgewotCQkJeGVuX2N4LT5yZWcu
Yml0X3dpZHRoID0gODsKLQkJCXhlbl9jeC0+cmVnLmJpdF9vZmZzZXQgPSAwOwotCQkJeGVuX2N4
LT5yZWcuYWNjZXNzX3NpemUgPSAxOwotCQl9IGVsc2UgewotCQkJeGVuX2N4LT5yZWcuc3BhY2Vf
aWQgPSBBQ1BJX0FEUl9TUEFDRV9GSVhFRF9IQVJEV0FSRTsKLQkJCWlmIChjeC0+ZW50cnlfbWV0
aG9kID09IEFDUElfQ1NUQVRFX0ZGSCkgewotCQkJCS8qIE5BVElWRV9DU1RBVEVfQkVZT05EX0hB
TFQgKi8KLQkJCQl4ZW5fY3gtPnJlZy5iaXRfb2Zmc2V0ID0gMjsKLQkJCQl4ZW5fY3gtPnJlZy5i
aXRfd2lkdGggPSAxOyAvKiBWRU5ET1JfSU5URUwgKi8KLQkJCX0KLQkJCXhlbl9jeC0+cmVnLmFj
Y2Vzc19zaXplID0gMDsKLQkJfQotCQl4ZW5fY3gtPnJlZy5hZGRyZXNzID0gY3gtPmFkZHJlc3M7
Ci0KLQkJeGVuX2N4LT50eXBlID0gY3gtPnR5cGU7Ci0JCXhlbl9jeC0+bGF0ZW5jeSA9IGN4LT5s
YXRlbmN5OwotCQl4ZW5fY3gtPnBvd2VyID0gY3gtPnBvd2VyOwotCi0JCXhlbl9jeC0+ZHBjbnQg
PSAwOwotCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fY3gtPmRwLCBOVUxMKTsKLSNpZmRlZiBE
RUJVRwotCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiBDWDogSUQ6JWQgW0MlZDolc10gZW50cnk6JWRc
biIsIF9wci0+YWNwaV9pZCwKLQkJCSBjeC0+dHlwZSwgY3gtPmRlc2MsIGN4LT5lbnRyeV9tZXRo
b2QpOwotI2VuZGlmCi0JfQotCWlmICghb2spIHsKLQkJcHJfZXJyKERSVl9OQU1FICI6IE5vIGF2
YWlsYWJsZSBDeCBpbmZvIGZvciBjcHUgJWRcbiIsIF9wci0+YWNwaV9pZCk7Ci0JCWtmcmVlKHhl
bl9jeF9zdGF0ZXMpOwotCQlyZXR1cm4gLUVJTlZBTDsKLQl9Ci0Jb3AudS5zZXRfcG1pbmZvLnBv
d2VyLmNvdW50ID0gb2s7Ci0Jb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZsYWdzLmJtX2NvbnRyb2wg
PSBfcHItPmZsYWdzLmJtX2NvbnRyb2w7Ci0Jb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZsYWdzLmJt
X2NoZWNrID0gX3ByLT5mbGFncy5ibV9jaGVjazsKLQlvcC51LnNldF9wbWluZm8ucG93ZXIuZmxh
Z3MuaGFzX2NzdCA9IF9wci0+ZmxhZ3MuaGFzX2NzdDsKLQlvcC51LnNldF9wbWluZm8ucG93ZXIu
ZmxhZ3MucG93ZXJfc2V0dXBfZG9uZSA9Ci0JCV9wci0+ZmxhZ3MucG93ZXJfc2V0dXBfZG9uZTsK
LQotCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG9wLnUuc2V0X3BtaW5mby5wb3dlci5zdGF0ZXMsIHhl
bl9jeF9zdGF0ZXMpOwotCi0JaWYgKCFub19oeXBlcmNhbGwgJiYgeGVuX2luaXRpYWxfZG9tYWlu
KCkpCi0JCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwotCi0JaWYgKHJldCkgewotCQlw
cl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNlbmQgdG8gaHlwZXJ2aXNvciAocmM6JWQpXG4i
LCByZXQpOwotCQlwcmludF9oZXhfZHVtcF9ieXRlcygiT1A6ICIsIERVTVBfUFJFRklYX05PTkUs
ICZvcCwKLQkJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wKSk7Ci0JCXByaW50
X2hleF9kdW1wX2J5dGVzKCJDeDogIiwgRFVNUF9QUkVGSVhfTk9ORSwgeGVuX2N4X3N0YXRlcywK
LQkJCQkgICAgIF9wci0+cG93ZXIuY291bnQgKgotCQkJCSAgICAgc2l6ZW9mKHN0cnVjdCB4ZW5f
cHJvY2Vzc29yX2N4KSk7Ci0JfQotCWtmcmVlKHhlbl9jeF9zdGF0ZXMpOwotCi0JcmV0dXJuIHJl
dDsKLX0KLQotCi0KLXN0YXRpYyBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX2NvcHlfcHNz
X2RhdGEoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIsCi0JCQkJCQkgIHN0cnVjdCB4ZW5fcHJv
Y2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZikKLXsKLQlzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9w
eCAqeGVuX3N0YXRlcyA9IE5VTEw7Ci0JaW50IGk7Ci0KLQl4ZW5fc3RhdGVzID0ga2NhbGxvYyhf
cHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCwKLQkJCSAgICAgc2l6ZW9mKHN0cnVjdCB4ZW5f
cHJvY2Vzc29yX3B4KSwgR0ZQX0tFUk5FTCk7Ci0JaWYgKCF4ZW5fc3RhdGVzKQotCQlyZXR1cm4g
RVJSX1BUUigtRU5PTUVNKTsKLQotCXhlbl9wZXJmLT5zdGF0ZV9jb3VudCA9IF9wci0+cGVyZm9y
bWFuY2UtPnN0YXRlX2NvdW50OwotCi0JQlVJTERfQlVHX09OKHNpemVvZihzdHJ1Y3QgeGVuX3By
b2Nlc3Nvcl9weCkgIT0KLQkJICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHJvY2Vzc29yX3B4KSk7
Ci0JZm9yIChpID0gMDsgaSA8IF9wci0+cGVyZm9ybWFuY2UtPnN0YXRlX2NvdW50OyBpKyspIHsK
LQotCQkvKiBGb3J0dW5hdGx5IGZvciB1cywgdGhleSBib3RoIGhhdmUgdGhlIHNhbWUgc2l6ZSAq
LwotCQltZW1jcHkoJih4ZW5fc3RhdGVzW2ldKSwgJihfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZXNb
aV0pLAotCQkgICAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nlc3Nvcl9weCkpOwotCX0KLQly
ZXR1cm4geGVuX3N0YXRlczsKLX0KLXN0YXRpYyBpbnQgeGVuX2NvcHlfcHNkX2RhdGEoc3RydWN0
IGFjcGlfcHJvY2Vzc29yICpfcHIsCi0JCQkgICAgIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZv
cm1hbmNlICp4ZW5fcGVyZikKLXsKLQlCVUlMRF9CVUdfT04oc2l6ZW9mKHN0cnVjdCB4ZW5fcHNk
X3BhY2thZ2UpICE9Ci0JCSAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3BzZF9wYWNrYWdlKSk7Ci0K
LQlpZiAoX3ByLT5wZXJmb3JtYW5jZS0+c2hhcmVkX3R5cGUgIT0gQ1BVRlJFUV9TSEFSRURfVFlQ
RV9OT05FKSB7Ci0JCXhlbl9wZXJmLT5zaGFyZWRfdHlwZSA9IF9wci0+cGVyZm9ybWFuY2UtPnNo
YXJlZF90eXBlOwotCi0JCW1lbWNweSgmKHhlbl9wZXJmLT5kb21haW5faW5mbyksICYoX3ByLT5w
ZXJmb3JtYW5jZS0+ZG9tYWluX2luZm8pLAotCQkgICAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Bz
ZF9wYWNrYWdlKSk7Ci0JfSBlbHNlIHsKLQkJaWYgKCgmY3B1X2RhdGEoMCkpLT54ODZfdmVuZG9y
ICE9IFg4Nl9WRU5ET1JfQU1EKQotCQkJcmV0dXJuIC1FSU5WQUw7Ci0KLQkJLyogT24gQU1ELCB0
aGUgcG93ZXJub3ctazggaXMgbG9hZGVkIGJlZm9yZSBhY3BpX2NwdWZyZXEKLQkJICogbWVhbmlu
ZyB0aGF0IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZvcm1hbmNlIG5ldmVyCi0JCSAq
IGdldHMgY2FsbGVkIHdoaWNoIHdvdWxkIHBhcnNlIHRoZSBfQ1NULgotCQkgKi8KLQkJeGVuX3Bl
cmYtPnNoYXJlZF90eXBlID0gQ1BVRlJFUV9TSEFSRURfVFlQRV9BTEw7Ci0JCXhlbl9wZXJmLT5k
b21haW5faW5mby5udW1fcHJvY2Vzc29ycyA9IG51bV9vbmxpbmVfY3B1cygpOwotCX0KLQlyZXR1
cm4gMDsKLX0KLXN0YXRpYyBpbnQgeGVuX2NvcHlfcGN0X2RhdGEoc3RydWN0IGFjcGlfcGN0X3Jl
Z2lzdGVyICpwY3QsCi0JCQkgICAgIHN0cnVjdCB4ZW5fcGN0X3JlZ2lzdGVyICpfcGN0KQotewot
CS8qIEl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGp1c3QgZG8gJ21lbWNweShwY3QsIF9w
Y3QnKSBidXQKLQkgKiBzYWRseSB0aGUgWGVuIHN0cnVjdHVyZSBkaWQgbm90IGhhdmUgdGhlIHBy
b3BlciBwYWRkaW5nCi0JICogc28gdGhlIGRlc2NyaXB0b3IgZmllbGQgdGFrZXMgdHdvIChfcGN0
KSBieXRlcyBpbnN0ZWFkIG9mIG9uZSAocGN0KS4KLQkgKi8KLQlfcGN0LT5kZXNjcmlwdG9yID0g
cGN0LT5kZXNjcmlwdG9yOwotCV9wY3QtPmxlbmd0aCA9IHBjdC0+bGVuZ3RoOwotCV9wY3QtPnNw
YWNlX2lkID0gcGN0LT5zcGFjZV9pZDsKLQlfcGN0LT5iaXRfd2lkdGggPSBwY3QtPmJpdF93aWR0
aDsKLQlfcGN0LT5iaXRfb2Zmc2V0ID0gcGN0LT5iaXRfb2Zmc2V0OwotCV9wY3QtPnJlc2VydmVk
ID0gcGN0LT5yZXNlcnZlZDsKLQlfcGN0LT5hZGRyZXNzID0gcGN0LT5hZGRyZXNzOwotCXJldHVy
biAwOwotfQotc3RhdGljIGludCB4ZW5fcHVzaF9weHhfdG9faHlwZXJ2aXNvcihzdHJ1Y3QgYWNw
aV9wcm9jZXNzb3IgKl9wcikKLXsKLQlpbnQgcmV0ID0gMDsKLQlzdHJ1Y3QgeGVuX3BsYXRmb3Jt
X29wIG9wID0gewotCQkuY21kCQkJPSBYRU5QRl9zZXRfcHJvY2Vzc29yX3BtaW5mbywKLQkJLmlu
dGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCi0JCS51LnNldF9wbWlu
Zm8uaWQJPSBfcHItPmFjcGlfaWQsCi0JCS51LnNldF9wbWluZm8udHlwZQk9IFhFTl9QTV9QWCwK
LQl9OwotCXN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZjsKLQlzdHJ1
Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX3N0YXRlcyA9IE5VTEw7Ci0KLQl4ZW5fcGVyZiA9ICZv
cC51LnNldF9wbWluZm8ucGVyZjsKLQotCXhlbl9wZXJmLT5wbGF0Zm9ybV9saW1pdCA9IF9wci0+
cGVyZm9ybWFuY2VfcGxhdGZvcm1fbGltaXQ7Ci0JeGVuX3BlcmYtPmZsYWdzIHw9IFhFTl9QWF9Q
UEM7Ci0JeGVuX2NvcHlfcGN0X2RhdGEoJihfcHItPnBlcmZvcm1hbmNlLT5jb250cm9sX3JlZ2lz
dGVyKSwKLQkJCSAgJnhlbl9wZXJmLT5jb250cm9sX3JlZ2lzdGVyKTsKLQl4ZW5fY29weV9wY3Rf
ZGF0YSgmKF9wci0+cGVyZm9ybWFuY2UtPnN0YXR1c19yZWdpc3RlciksCi0JCQkgICZ4ZW5fcGVy
Zi0+c3RhdHVzX3JlZ2lzdGVyKTsKLQl4ZW5fcGVyZi0+ZmxhZ3MgfD0gWEVOX1BYX1BDVDsKLQl4
ZW5fc3RhdGVzID0geGVuX2NvcHlfcHNzX2RhdGEoX3ByLCB4ZW5fcGVyZik7Ci0JaWYgKCFJU19F
UlJfT1JfTlVMTCh4ZW5fc3RhdGVzKSkgewotCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fcGVy
Zi0+c3RhdGVzLCB4ZW5fc3RhdGVzKTsKLQkJeGVuX3BlcmYtPmZsYWdzIHw9IFhFTl9QWF9QU1M7
Ci0JfQotCWlmICgheGVuX2NvcHlfcHNkX2RhdGEoX3ByLCB4ZW5fcGVyZikpCi0JCXhlbl9wZXJm
LT5mbGFncyB8PSBYRU5fUFhfUFNEOwotCi0JaWYgKCFub19oeXBlcmNhbGwgJiYgeGVuX2luaXRp
YWxfZG9tYWluKCkpCi0JCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwotCi0JaWYgKHJl
dCkgewotCQlwcl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNlbmQgdG8gaHlwZXJ2aXNvciAo
cmM6JWQpXG4iLCByZXQpOwotCQlwcmludF9oZXhfZHVtcF9ieXRlcygiT1A6ICIsIERVTVBfUFJF
RklYX05PTkUsICZvcCwKLQkJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wKSk7
Ci0JCWlmICghSVNfRVJSX09SX05VTEwoeGVuX3N0YXRlcykpCi0JCQlwcmludF9oZXhfZHVtcF9i
eXRlcygiUHh4OiIsIERVTVBfUFJFRklYX05PTkUsIHhlbl9zdGF0ZXMsCi0JCQkJICAgICBfcHIt
PnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCAqCi0JCQkJICAgICBzaXplb2Yoc3RydWN0IHhlbl9w
cm9jZXNzb3JfcHgpKTsKLQl9Ci0JaWYgKCFJU19FUlJfT1JfTlVMTCh4ZW5fc3RhdGVzKSkKLQkJ
a2ZyZWUoeGVuX3N0YXRlcyk7Ci0KLQlyZXR1cm4gcmV0OwotfQotLyoKLSAqIFdlIHJlYWQgb3V0
IHRoZSBzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IsIGFuZCBzZXJpYWxpemUgYWNjZXNzCi0gKiBzbyB0
aGF0IHRoZXJlIGlzIG9ubHkgb25lIGNhbGxlci4gVGhpcyBpcyBzbyB0aGF0IHdlIHdvbid0Ci0g
KiByYWNlIHdpdGggdGhlIENQVSBob3RwbHVnIGNvZGUuCi0gKi8KLXN0YXRpYyBpbnQgeGVuX3By
b2Nlc3NfZGF0YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wciwgaW50IGNwdSkKLXsKLQlpbnQg
ZXJyID0gMDsKLQotCW11dGV4X2xvY2soJnByb2Nlc3NvcnNfZG9uZV9tdXRleCk7Ci0JaWYgKGNw
dW1hc2tfdGVzdF9jcHUoY3B1LCB0b19jcHVtYXNrKHByb2Nlc3NvcnNfZG9uZSkpKSB7Ci0JCW11
dGV4X3VubG9jaygmcHJvY2Vzc29yc19kb25lX211dGV4KTsKLQkJcmV0dXJuIC1FQlVTWTsKLQl9
Ci0JaWYgKF9wci0+ZmxhZ3MucG93ZXIpCi0JCWVyciA9IHhlbl9wdXNoX2N4eF90b19oeXBlcnZp
c29yKF9wcik7Ci0KLQlpZiAoX3ByLT5wZXJmb3JtYW5jZSAmJiBfcHItPnBlcmZvcm1hbmNlLT5z
dGF0ZXMpCi0JCWVyciB8PSB4ZW5fcHVzaF9weHhfdG9faHlwZXJ2aXNvcihfcHIpOwotCi0JY3B1
bWFza19zZXRfY3B1KGNwdSwgdG9fY3B1bWFzayhwcm9jZXNzb3JzX2RvbmUpKTsKLQltdXRleF91
bmxvY2soJnByb2Nlc3NvcnNfZG9uZV9tdXRleCk7Ci0JcmV0dXJuIGVycjsKLX0KLQotc3RhdGlj
IGludCB4ZW5fcHJvY2Vzc29yX2NoZWNrKHZvaWQpCi17Ci0Jc3RydWN0IGNwdWZyZXFfcG9saWN5
ICpwb2xpY3k7Ci0JaW50IGNwdTsKLQotCXBvbGljeSA9IGNwdWZyZXFfY3B1X2dldChzbXBfcHJv
Y2Vzc29yX2lkKCkpOwotCWlmICghcG9saWN5KQotCQlyZXR1cm4gLUVCVVNZOwotCi0JZ2V0X29u
bGluZV9jcHVzKCk7Ci0JZm9yX2VhY2hfb25saW5lX2NwdShjcHUpIHsKLQkJc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpfcHI7Ci0KLQkJX3ByID0gcGVyX2NwdShwcm9jZXNzb3JzLCBjcHUpOwotCQlp
ZiAoIV9wcikKLQkJCWNvbnRpbnVlOwotCi0JCSh2b2lkKXhlbl9wcm9jZXNzX2RhdGEoX3ByLCBj
cHUpOwotCX0KLQlwdXRfb25saW5lX2NwdXMoKTsKLQotCWNwdWZyZXFfY3B1X3B1dChwb2xpY3kp
OwotCXJldHVybiAwOwotfQotLyoKLSAqIFRoZSBwdXJwb3NlIG9mIHRoaXMgdGltZXIvdGhyZWFk
IGlzIHRvIHdhaXQgZm9yIHRoZSBBQ1BJIHByb2Nlc3NvcgotICogYW5kIENQVWZyZXEgZHJpdmVy
cyB0byBsb2FkIHVwIGFuZCBwYXJzZSB0aGUgUHh4IGFuZCBDeHggaW5mb3JtYXRpb24KLSAqIGJl
Zm9yZSB3ZSBhdHRlbXB0IHRvIHJlYWQgaXQuCi0gKi8KLXN0YXRpYyB2b2lkIHhlbl9wcm9jZXNz
b3JfdGltZW91dCh1bnNpZ25lZCBsb25nIGFyZykKLXsKLQl3YWtlX3VwX3Byb2Nlc3MoKHN0cnVj
dCB0YXNrX3N0cnVjdCAqKWFyZyk7Ci19Ci1zdGF0aWMgaW50IHhlbl9wcm9jZXNzb3JfdGhyZWFk
X2Z1bmModm9pZCAqZHVtbXkpCi17Ci0Jc3RydWN0IHRpbWVyX2xpc3QgdGltZXI7Ci0KLQlzZXR1
cF9kZWZlcnJhYmxlX3RpbWVyX29uX3N0YWNrKCZ0aW1lciwgeGVuX3Byb2Nlc3Nvcl90aW1lb3V0
LAotCQkJCQkodW5zaWduZWQgbG9uZyljdXJyZW50KTsKLQotCWRvIHsKLQkJX19zZXRfY3VycmVu
dF9zdGF0ZShUQVNLX0lOVEVSUlVQVElCTEUpOwotCQltb2RfdGltZXIoJnRpbWVyLCBqaWZmaWVz
ICsgUE9MTF9USU1FUik7Ci0JCXNjaGVkdWxlKCk7Ci0JCWlmICh4ZW5fcHJvY2Vzc29yX2NoZWNr
KCkgIT0gLUVCVVNZKQotCQkJYnJlYWs7Ci0JfSB3aGlsZSAoIWt0aHJlYWRfc2hvdWxkX3N0b3Ao
KSk7Ci0KLQlkZWxfdGltZXJfc3luYygmdGltZXIpOwotCWRlc3Ryb3lfdGltZXJfb25fc3RhY2so
JnRpbWVyKTsKLQlyZXR1cm4gMDsKLX0KLQotc3RhdGljIGludCB4ZW5fY3B1X3NvZnRfbm90aWZ5
KHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmZiLAotCQkJICAgICAgIHVuc2lnbmVkIGxvbmcgYWN0
aW9uLCB2b2lkICpoY3B1KQotewotCXVuc2lnbmVkIGludCBjcHUgPSAodW5zaWduZWQgbG9uZylo
Y3B1OwotCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3ByID0gcGVyX2NwdShwcm9jZXNzb3JzLCBj
cHUpOwotCi0JaWYgKGFjdGlvbiA9PSBDUFVfT05MSU5FICYmIF9wcikKLQkJKHZvaWQpeGVuX3By
b2Nlc3NfZGF0YShfcHIsIGNwdSk7Ci0KLQlyZXR1cm4gTk9USUZZX09LOwotfQotCi1zdGF0aWMg
c3RydWN0IG5vdGlmaWVyX2Jsb2NrIHhlbl9jcHVfbm90aWZpZXIgPSB7Ci0JLm5vdGlmaWVyX2Nh
bGwgPSB4ZW5fY3B1X3NvZnRfbm90aWZ5LAotCS5wcmlvcml0eSA9IC0xLCAvKiBCZSB0aGUgbGFz
dCBvbmUgKi8KLX07Ci0KLXN0YXRpYyBpbnQgX19pbml0IGNoZWNrX3ByZXJlcSh2b2lkKQotewot
CXN0cnVjdCBjcHVpbmZvX3g4NiAqYyA9ICZjcHVfZGF0YSgwKTsKLQotCWlmICgheGVuX2luaXRp
YWxfZG9tYWluKCkpCi0JCXJldHVybiAtRU5PREVWOwotCi0JaWYgKCFhY3BpX2dibF9GQURULnNt
aV9jb21tYW5kKQotCQlyZXR1cm4gLUVOT0RFVjsKLQotCWlmIChjLT54ODZfdmVuZG9yID09IFg4
Nl9WRU5ET1JfSU5URUwpIHsKLQkJaWYgKCFjcHVfaGFzKGMsIFg4Nl9GRUFUVVJFX0VTVCkpCi0J
CQlyZXR1cm4gLUVOT0RFVjsKLQotCQlyZXR1cm4gMDsKLQl9Ci0JaWYgKGMtPng4Nl92ZW5kb3Ig
PT0gWDg2X1ZFTkRPUl9BTUQpIHsKLQkJdTMyIGhpID0gMCwgbG8gPSAwOwotCQkvKiBDb3BpZWQg
ZnJvbSBwb3dlcm5vdy1rOC5oLCBjYW4ndCBpbmNsdWRlIC4uL2NwdWZyZXEvcG93ZXJub3cKLQkJ
ICogYXMgd2UgZ2V0IGNvbXBpbGUgd2FybmluZ3MgZm9yIHRoZSBzdGF0aWMgZnVuY3Rpb25zLgot
CQkgKi8KLSNkZWZpbmUgTVNSX1BTVEFURV9DVVJfTElNSVQgICAgMHhjMDAxMDA2MSAvKiBwc3Rh
dGUgY3VycmVudCBsaW1pdCBNU1IgKi8KLQkJcmRtc3IoTVNSX1BTVEFURV9DVVJfTElNSVQsIGxv
LCBoaSk7Ci0KLQkJLyogSWYgdGhlIE1TUiBjYW5ub3QgcHJvdmlkZSB0aGUgZGF0YSwgdGhlIHBv
d2Vybm93LWs4Ci0JCSAqIHdvbid0IHByb2Nlc3MgdGhlIGRhdGEgcHJvcGVybHkgZWl0aGVyLgot
CQkgKi8KLQkJaWYgKGhpIHx8IGxvKQotCQkJcmV0dXJuIDA7Ci0JfQotCXJldHVybiAtRU5PREVW
OwotfQotCi1zdGF0aWMgaW50IF9faW5pdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJvdWdoX2luaXQo
dm9pZCkKLXsKLQlpbnQgcmMgPSBjaGVja19wcmVyZXEoKTsKLQotCWlmIChyYykKLQkJcmV0dXJu
IHJjOwotCi0JeGVuX3Byb2Nlc3Nvcl90aHJlYWQgPSBrdGhyZWFkX3J1bih4ZW5fcHJvY2Vzc29y
X3RocmVhZF9mdW5jLCBOVUxMLCBEUlZfTkFNRSk7Ci0JaWYgKElTX0VSUih4ZW5fcHJvY2Vzc29y
X3RocmVhZCkpIHsKLQkJcHJfZXJyKERSVl9OQU1FICI6IEZhaWxlZCB0byBjcmVhdGUgdGhyZWFk
LiBBYm9ydGluZy5cbiIpOwotCQlyZXR1cm4gLUVOT01FTTsKLQl9Ci0JcmVnaXN0ZXJfaG90Y3B1
X25vdGlmaWVyKCZ4ZW5fY3B1X25vdGlmaWVyKTsKLQlyZXR1cm4gMDsKLX0KLXN0YXRpYyB2b2lk
IF9fZXhpdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJvdWdoX2V4aXQodm9pZCkKLXsKLQl1bnJlZ2lz
dGVyX2hvdGNwdV9ub3RpZmllcigmeGVuX2NwdV9ub3RpZmllcik7Ci0JaWYgKHhlbl9wcm9jZXNz
b3JfdGhyZWFkKQotCQlrdGhyZWFkX3N0b3AoeGVuX3Byb2Nlc3Nvcl90aHJlYWQpOwotfQotbGF0
ZV9pbml0Y2FsbCh4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJvdWdoX2luaXQpOwotbW9kdWxlX2V4aXQo
eGVuX3Byb2Nlc3Nvcl9wYXNzdGhyb3VnaF9leGl0KTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L3Byb2Nlc3Nvci1wYXNzdGhydS5jIGIvZHJpdmVycy94ZW4vcHJvY2Vzc29yLXBhc3N0aHJ1LmMK
bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uYWJmY2JlNAotLS0gL2Rldi9udWxs
CisrKyBiL2RyaXZlcnMveGVuL3Byb2Nlc3Nvci1wYXNzdGhydS5jCkBAIC0wLDAgKzEsMzk3IEBA
CisvKgorICogQ29weXJpZ2h0IDIwMTIgYnkgT3JhY2xlIEluYworICogQXV0aG9yOiBLb25yYWQg
Unplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CisgKgorICoKKyAqIFRoaXMg
cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5IGl0CisgKiB1bmRlciB0aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBH
ZW5lcmFsIFB1YmxpYyBMaWNlbnNlLAorICogdmVyc2lvbiAyLCBhcyBwdWJsaXNoZWQgYnkgdGhl
IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkg
V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFC
SUxJVFkgb3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBH
TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqCisgKi8K
KworLyoKKyAqICBLbm93biBsaW1pdGF0aW9ucworICoKKyAqIFRoZSBkcml2ZXIgY2FuIG9ubHkg
aGFuZGxlIHVwIHRvICBmb3JfZWFjaF9wb3NzaWJsZV9jcHUoKS4KKyAqIE1lYW5pbmcgaWYgeW91
IGJvb3Qgd2l0aCBkb20wX21heF9jcHVzPVggaXQgd2lsbCBfb25seV8gcGFyc2UgdXAgdG8gWAor
ICogcHJvY2Vzc29ycy4KKyAqLworCisjaW5jbHVkZSA8bGludXgvY3B1bWFzay5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdWZyZXEuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNpbmNsdWRl
IDxsaW51eC9rdGhyZWFkLmg+CisjaW5jbHVkZSA8bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxp
bnV4L21vZHVsZS5oPgorI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8YWNwaS9h
Y3BpX2J1cy5oPgorI2luY2x1ZGUgPGFjcGkvYWNwaV9kcml2ZXJzLmg+CisjaW5jbHVkZSA8YWNw
aS9wcm9jZXNzb3IuaD4KKworI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaD4KKyNp
bmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorCisjZGVmaW5lIERSVl9OQU1FICJ4ZW4tcHJv
Y2Vzc29yLXRocnUiCitNT0RVTEVfQVVUSE9SKCJLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJh
ZC53aWxrQG9yYWNsZS5jb20+Iik7CitNT0RVTEVfREVTQ1JJUFRJT04oIkFDUEkgUG93ZXIgTWFu
YWdlbWVudCBkcml2ZXIgdG8gcGFzcyBDeCBhbmQgUHh4IGRhdGEgdG8gWGVuIGh5cGVydmlzb3Ii
KTsKK01PRFVMRV9MSUNFTlNFKCJHUEwiKTsKKworCitNT0RVTEVfUEFSTV9ERVNDKG9mZiwgIklu
aGliaXQgdGhlIGh5cGVyY2FsbC4iKTsKK3N0YXRpYyBpbnQgbm9faHlwZXJjYWxsOworbW9kdWxl
X3BhcmFtX25hbWVkKG9mZiwgbm9faHlwZXJjYWxsLCBpbnQsIDA0MDApOworCitzdGF0aWMgREVG
SU5FX01VVEVYKHByb2Nlc3NvcnNfZG9uZV9tdXRleCk7CitzdGF0aWMgREVDTEFSRV9CSVRNQVAo
cHJvY2Vzc29yc19kb25lLCBOUl9DUFVTKTsKKworI2RlZmluZSBQT0xMX1RJTUVSIG1zZWNzX3Rv
X2ppZmZpZXMoNTAwMCAvKiA1IHNlYyAqLykKK3N0YXRpYyBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnhl
bl9wcm9jZXNzb3JfdGhyZWFkOworCitzdGF0aWMgaW50IHhlbl9wdXNoX2N4eF90b19oeXBlcnZp
c29yKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3ByKQoreworCXN0cnVjdCB4ZW5fcGxhdGZvcm1f
b3Agb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX3NldF9wcm9jZXNzb3JfcG1pbmZvLAorCQkuaW50
ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuc2V0X3BtaW5m
by5pZAk9IF9wci0+YWNwaV9pZCwKKwkJLnUuc2V0X3BtaW5mby50eXBlCT0gWEVOX1BNX0NYLAor
CX07CisJc3RydWN0IHhlbl9wcm9jZXNzb3JfY3ggKnhlbl9jeCwgKnhlbl9jeF9zdGF0ZXMgPSBO
VUxMOworCXN0cnVjdCBhY3BpX3Byb2Nlc3Nvcl9jeCAqY3g7CisJaW50IGksIG9rLCByZXQgPSAw
OworCisJeGVuX2N4X3N0YXRlcyA9IGtjYWxsb2MoX3ByLT5wb3dlci5jb3VudCwKKwkJCQlzaXpl
b2Yoc3RydWN0IHhlbl9wcm9jZXNzb3JfY3gpLCBHRlBfS0VSTkVMKTsKKwlpZiAoIXhlbl9jeF9z
dGF0ZXMpCisJCXJldHVybiAtRU5PTUVNOworCisJZm9yIChvayA9IDAsIGkgPSAxOyBpIDw9IF9w
ci0+cG93ZXIuY291bnQ7IGkrKykgeworCQljeCA9ICZfcHItPnBvd2VyLnN0YXRlc1tpXTsKKwkJ
aWYgKCFjeC0+dmFsaWQpCisJCQljb250aW51ZTsKKworCQl4ZW5fY3ggPSAmKHhlbl9jeF9zdGF0
ZXNbb2srK10pOworCisJCXhlbl9jeC0+cmVnLnNwYWNlX2lkID0gQUNQSV9BRFJfU1BBQ0VfU1lT
VEVNX0lPOworCQlpZiAoY3gtPmVudHJ5X21ldGhvZCA9PSBBQ1BJX0NTVEFURV9TWVNURU1JTykg
eworCQkJeGVuX2N4LT5yZWcuYml0X3dpZHRoID0gODsKKwkJCXhlbl9jeC0+cmVnLmJpdF9vZmZz
ZXQgPSAwOworCQkJeGVuX2N4LT5yZWcuYWNjZXNzX3NpemUgPSAxOworCQl9IGVsc2UgeworCQkJ
eGVuX2N4LT5yZWcuc3BhY2VfaWQgPSBBQ1BJX0FEUl9TUEFDRV9GSVhFRF9IQVJEV0FSRTsKKwkJ
CWlmIChjeC0+ZW50cnlfbWV0aG9kID09IEFDUElfQ1NUQVRFX0ZGSCkgeworCQkJCS8qIE5BVElW
RV9DU1RBVEVfQkVZT05EX0hBTFQgKi8KKwkJCQl4ZW5fY3gtPnJlZy5iaXRfb2Zmc2V0ID0gMjsK
KwkJCQl4ZW5fY3gtPnJlZy5iaXRfd2lkdGggPSAxOyAvKiBWRU5ET1JfSU5URUwgKi8KKwkJCX0K
KwkJCXhlbl9jeC0+cmVnLmFjY2Vzc19zaXplID0gMDsKKwkJfQorCQl4ZW5fY3gtPnJlZy5hZGRy
ZXNzID0gY3gtPmFkZHJlc3M7CisKKwkJeGVuX2N4LT50eXBlID0gY3gtPnR5cGU7CisJCXhlbl9j
eC0+bGF0ZW5jeSA9IGN4LT5sYXRlbmN5OworCQl4ZW5fY3gtPnBvd2VyID0gY3gtPnBvd2VyOwor
CisJCXhlbl9jeC0+ZHBjbnQgPSAwOworCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fY3gtPmRw
LCBOVUxMKTsKKyNpZmRlZiBERUJVRworCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiBDWDogSUQ6JWQg
W0MlZDolc10gZW50cnk6JWRcbiIsIF9wci0+YWNwaV9pZCwKKwkJCSBjeC0+dHlwZSwgY3gtPmRl
c2MsIGN4LT5lbnRyeV9tZXRob2QpOworI2VuZGlmCisJfQorCWlmICghb2spIHsKKwkJcHJfZXJy
KERSVl9OQU1FICI6IE5vIGF2YWlsYWJsZSBDeCBpbmZvIGZvciBjcHUgJWRcbiIsIF9wci0+YWNw
aV9pZCk7CisJCWtmcmVlKHhlbl9jeF9zdGF0ZXMpOworCQlyZXR1cm4gLUVJTlZBTDsKKwl9CisJ
b3AudS5zZXRfcG1pbmZvLnBvd2VyLmNvdW50ID0gb2s7CisJb3AudS5zZXRfcG1pbmZvLnBvd2Vy
LmZsYWdzLmJtX2NvbnRyb2wgPSBfcHItPmZsYWdzLmJtX2NvbnRyb2w7CisJb3AudS5zZXRfcG1p
bmZvLnBvd2VyLmZsYWdzLmJtX2NoZWNrID0gX3ByLT5mbGFncy5ibV9jaGVjazsKKwlvcC51LnNl
dF9wbWluZm8ucG93ZXIuZmxhZ3MuaGFzX2NzdCA9IF9wci0+ZmxhZ3MuaGFzX2NzdDsKKwlvcC51
LnNldF9wbWluZm8ucG93ZXIuZmxhZ3MucG93ZXJfc2V0dXBfZG9uZSA9CisJCV9wci0+ZmxhZ3Mu
cG93ZXJfc2V0dXBfZG9uZTsKKworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG9wLnUuc2V0X3BtaW5m
by5wb3dlci5zdGF0ZXMsIHhlbl9jeF9zdGF0ZXMpOworCisJaWYgKCFub19oeXBlcmNhbGwgJiYg
eGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwor
CisJaWYgKHJldCkgeworCQlwcl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNlbmQgdG8gaHlw
ZXJ2aXNvciAocmM6JWQpXG4iLCByZXQpOworCQlwcmludF9oZXhfZHVtcF9ieXRlcygiT1A6ICIs
IERVTVBfUFJFRklYX05PTkUsICZvcCwKKwkJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3BsYXRm
b3JtX29wKSk7CisJCXByaW50X2hleF9kdW1wX2J5dGVzKCJDeDogIiwgRFVNUF9QUkVGSVhfTk9O
RSwgeGVuX2N4X3N0YXRlcywKKwkJCQkgICAgIF9wci0+cG93ZXIuY291bnQgKgorCQkJCSAgICAg
c2l6ZW9mKHN0cnVjdCB4ZW5fcHJvY2Vzc29yX2N4KSk7CisJfQorCWtmcmVlKHhlbl9jeF9zdGF0
ZXMpOworCisJcmV0dXJuIHJldDsKK30KKworCisKK3N0YXRpYyBzdHJ1Y3QgeGVuX3Byb2Nlc3Nv
cl9weCAqeGVuX2NvcHlfcHNzX2RhdGEoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIsCisJCQkJ
CQkgIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZikKK3sKKwlzdHJ1
Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX3N0YXRlcyA9IE5VTEw7CisJaW50IGk7CisKKwl4ZW5f
c3RhdGVzID0ga2NhbGxvYyhfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCwKKwkJCSAgICAg
c2l6ZW9mKHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3B4KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCF4ZW5f
c3RhdGVzKQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKworCXhlbl9wZXJmLT5zdGF0ZV9j
b3VudCA9IF9wci0+cGVyZm9ybWFuY2UtPnN0YXRlX2NvdW50OworCisJQlVJTERfQlVHX09OKHNp
emVvZihzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCkgIT0KKwkJICAgICBzaXplb2Yoc3RydWN0IGFj
cGlfcHJvY2Vzc29yX3B4KSk7CisJZm9yIChpID0gMDsgaSA8IF9wci0+cGVyZm9ybWFuY2UtPnN0
YXRlX2NvdW50OyBpKyspIHsKKworCQkvKiBGb3J0dW5hdGx5IGZvciB1cywgdGhleSBib3RoIGhh
dmUgdGhlIHNhbWUgc2l6ZSAqLworCQltZW1jcHkoJih4ZW5fc3RhdGVzW2ldKSwgJihfcHItPnBl
cmZvcm1hbmNlLT5zdGF0ZXNbaV0pLAorCQkgICAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nl
c3Nvcl9weCkpOworCX0KKwlyZXR1cm4geGVuX3N0YXRlczsKK30KK3N0YXRpYyBpbnQgeGVuX2Nv
cHlfcHNkX2RhdGEoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIsCisJCQkgICAgIHN0cnVjdCB4
ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZikKK3sKKwlCVUlMRF9CVUdfT04oc2l6
ZW9mKHN0cnVjdCB4ZW5fcHNkX3BhY2thZ2UpICE9CisJCSAgICAgc2l6ZW9mKHN0cnVjdCBhY3Bp
X3BzZF9wYWNrYWdlKSk7CisKKwlpZiAoX3ByLT5wZXJmb3JtYW5jZS0+c2hhcmVkX3R5cGUgIT0g
Q1BVRlJFUV9TSEFSRURfVFlQRV9OT05FKSB7CisJCXhlbl9wZXJmLT5zaGFyZWRfdHlwZSA9IF9w
ci0+cGVyZm9ybWFuY2UtPnNoYXJlZF90eXBlOworCisJCW1lbWNweSgmKHhlbl9wZXJmLT5kb21h
aW5faW5mbyksICYoX3ByLT5wZXJmb3JtYW5jZS0+ZG9tYWluX2luZm8pLAorCQkgICAgICAgc2l6
ZW9mKHN0cnVjdCBhY3BpX3BzZF9wYWNrYWdlKSk7CisJfSBlbHNlIHsKKwkJaWYgKCgmY3B1X2Rh
dGEoMCkpLT54ODZfdmVuZG9yICE9IFg4Nl9WRU5ET1JfQU1EKQorCQkJcmV0dXJuIC1FSU5WQUw7
CisKKwkJLyogT24gQU1ELCB0aGUgcG93ZXJub3ctazggaXMgbG9hZGVkIGJlZm9yZSBhY3BpX2Nw
dWZyZXEKKwkJICogbWVhbmluZyB0aGF0IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZv
cm1hbmNlIG5ldmVyCisJCSAqIGdldHMgY2FsbGVkIHdoaWNoIHdvdWxkIHBhcnNlIHRoZSBfQ1NU
LgorCQkgKi8KKwkJeGVuX3BlcmYtPnNoYXJlZF90eXBlID0gQ1BVRlJFUV9TSEFSRURfVFlQRV9B
TEw7CisJCXhlbl9wZXJmLT5kb21haW5faW5mby5udW1fcHJvY2Vzc29ycyA9IG51bV9vbmxpbmVf
Y3B1cygpOworCX0KKwlyZXR1cm4gMDsKK30KK3N0YXRpYyBpbnQgeGVuX2NvcHlfcGN0X2RhdGEo
c3RydWN0IGFjcGlfcGN0X3JlZ2lzdGVyICpwY3QsCisJCQkgICAgIHN0cnVjdCB4ZW5fcGN0X3Jl
Z2lzdGVyICpfcGN0KQoreworCS8qIEl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGp1c3Qg
ZG8gJ21lbWNweShwY3QsIF9wY3QnKSBidXQKKwkgKiBzYWRseSB0aGUgWGVuIHN0cnVjdHVyZSBk
aWQgbm90IGhhdmUgdGhlIHByb3BlciBwYWRkaW5nCisJICogc28gdGhlIGRlc2NyaXB0b3IgZmll
bGQgdGFrZXMgdHdvIChfcGN0KSBieXRlcyBpbnN0ZWFkIG9mIG9uZSAocGN0KS4KKwkgKi8KKwlf
cGN0LT5kZXNjcmlwdG9yID0gcGN0LT5kZXNjcmlwdG9yOworCV9wY3QtPmxlbmd0aCA9IHBjdC0+
bGVuZ3RoOworCV9wY3QtPnNwYWNlX2lkID0gcGN0LT5zcGFjZV9pZDsKKwlfcGN0LT5iaXRfd2lk
dGggPSBwY3QtPmJpdF93aWR0aDsKKwlfcGN0LT5iaXRfb2Zmc2V0ID0gcGN0LT5iaXRfb2Zmc2V0
OworCV9wY3QtPnJlc2VydmVkID0gcGN0LT5yZXNlcnZlZDsKKwlfcGN0LT5hZGRyZXNzID0gcGN0
LT5hZGRyZXNzOworCXJldHVybiAwOworfQorc3RhdGljIGludCB4ZW5fcHVzaF9weHhfdG9faHlw
ZXJ2aXNvcihzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wcikKK3sKKwlpbnQgcmV0ID0gMDsKKwlz
dHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kCQkJPSBYRU5QRl9zZXRfcHJvY2Vz
c29yX3BtaW5mbywKKwkJLmludGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJ
T04sCisJCS51LnNldF9wbWluZm8uaWQJPSBfcHItPmFjcGlfaWQsCisJCS51LnNldF9wbWluZm8u
dHlwZQk9IFhFTl9QTV9QWCwKKwl9OworCXN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNl
ICp4ZW5fcGVyZjsKKwlzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX3N0YXRlcyA9IE5VTEw7
CisKKwl4ZW5fcGVyZiA9ICZvcC51LnNldF9wbWluZm8ucGVyZjsKKworCXhlbl9wZXJmLT5wbGF0
Zm9ybV9saW1pdCA9IF9wci0+cGVyZm9ybWFuY2VfcGxhdGZvcm1fbGltaXQ7CisJeGVuX3BlcmYt
PmZsYWdzIHw9IFhFTl9QWF9QUEM7CisJeGVuX2NvcHlfcGN0X2RhdGEoJihfcHItPnBlcmZvcm1h
bmNlLT5jb250cm9sX3JlZ2lzdGVyKSwKKwkJCSAgJnhlbl9wZXJmLT5jb250cm9sX3JlZ2lzdGVy
KTsKKwl4ZW5fY29weV9wY3RfZGF0YSgmKF9wci0+cGVyZm9ybWFuY2UtPnN0YXR1c19yZWdpc3Rl
ciksCisJCQkgICZ4ZW5fcGVyZi0+c3RhdHVzX3JlZ2lzdGVyKTsKKwl4ZW5fcGVyZi0+ZmxhZ3Mg
fD0gWEVOX1BYX1BDVDsKKwl4ZW5fc3RhdGVzID0geGVuX2NvcHlfcHNzX2RhdGEoX3ByLCB4ZW5f
cGVyZik7CisJaWYgKCFJU19FUlJfT1JfTlVMTCh4ZW5fc3RhdGVzKSkgeworCQlzZXRfeGVuX2d1
ZXN0X2hhbmRsZSh4ZW5fcGVyZi0+c3RhdGVzLCB4ZW5fc3RhdGVzKTsKKwkJeGVuX3BlcmYtPmZs
YWdzIHw9IFhFTl9QWF9QU1M7CisJfQorCWlmICgheGVuX2NvcHlfcHNkX2RhdGEoX3ByLCB4ZW5f
cGVyZikpCisJCXhlbl9wZXJmLT5mbGFncyB8PSBYRU5fUFhfUFNEOworCisJaWYgKCFub19oeXBl
cmNhbGwgJiYgeGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldCA9IEhZUEVSVklTT1JfZG9tMF9v
cCgmb3ApOworCisJaWYgKHJldCkgeworCQlwcl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNl
bmQgdG8gaHlwZXJ2aXNvciAocmM6JWQpXG4iLCByZXQpOworCQlwcmludF9oZXhfZHVtcF9ieXRl
cygiT1A6ICIsIERVTVBfUFJFRklYX05PTkUsICZvcCwKKwkJCQkgICAgIHNpemVvZihzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wKSk7CisJCWlmICghSVNfRVJSX09SX05VTEwoeGVuX3N0YXRlcykpCisJ
CQlwcmludF9oZXhfZHVtcF9ieXRlcygiUHh4OiIsIERVTVBfUFJFRklYX05PTkUsIHhlbl9zdGF0
ZXMsCisJCQkJICAgICBfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCAqCisJCQkJICAgICBz
aXplb2Yoc3RydWN0IHhlbl9wcm9jZXNzb3JfcHgpKTsKKwl9CisJaWYgKCFJU19FUlJfT1JfTlVM
TCh4ZW5fc3RhdGVzKSkKKwkJa2ZyZWUoeGVuX3N0YXRlcyk7CisKKwlyZXR1cm4gcmV0OworfQor
LyoKKyAqIFdlIHJlYWQgb3V0IHRoZSBzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IsIGFuZCBzZXJpYWxp
emUgYWNjZXNzCisgKiBzbyB0aGF0IHRoZXJlIGlzIG9ubHkgb25lIGNhbGxlci4gVGhpcyBpcyBz
byB0aGF0IHdlIHdvbid0CisgKiByYWNlIHdpdGggdGhlIENQVSBob3RwbHVnIGNvZGUuCisgKi8K
K3N0YXRpYyBpbnQgeGVuX3Byb2Nlc3NfZGF0YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wciwg
aW50IGNwdSkKK3sKKwlpbnQgZXJyID0gMDsKKworCW11dGV4X2xvY2soJnByb2Nlc3NvcnNfZG9u
ZV9tdXRleCk7CisJaWYgKGNwdW1hc2tfdGVzdF9jcHUoY3B1LCB0b19jcHVtYXNrKHByb2Nlc3Nv
cnNfZG9uZSkpKSB7CisJCW11dGV4X3VubG9jaygmcHJvY2Vzc29yc19kb25lX211dGV4KTsKKwkJ
cmV0dXJuIC1FQlVTWTsKKwl9CisJaWYgKF9wci0+ZmxhZ3MucG93ZXIpCisJCWVyciA9IHhlbl9w
dXNoX2N4eF90b19oeXBlcnZpc29yKF9wcik7CisKKwlpZiAoX3ByLT5wZXJmb3JtYW5jZSAmJiBf
cHItPnBlcmZvcm1hbmNlLT5zdGF0ZXMpCisJCWVyciB8PSB4ZW5fcHVzaF9weHhfdG9faHlwZXJ2
aXNvcihfcHIpOworCisJY3B1bWFza19zZXRfY3B1KGNwdSwgdG9fY3B1bWFzayhwcm9jZXNzb3Jz
X2RvbmUpKTsKKwltdXRleF91bmxvY2soJnByb2Nlc3NvcnNfZG9uZV9tdXRleCk7CisJcmV0dXJu
IGVycjsKK30KKworc3RhdGljIGludCB4ZW5fcHJvY2Vzc29yX2NoZWNrKHZvaWQpCit7CisJc3Ry
dWN0IGNwdWZyZXFfcG9saWN5ICpwb2xpY3k7CisJaW50IGNwdTsKKworCXBvbGljeSA9IGNwdWZy
ZXFfY3B1X2dldChzbXBfcHJvY2Vzc29yX2lkKCkpOworCWlmICghcG9saWN5KQorCQlyZXR1cm4g
LUVCVVNZOworCisJZ2V0X29ubGluZV9jcHVzKCk7CisJZm9yX2VhY2hfb25saW5lX2NwdShjcHUp
IHsKKwkJc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHI7CisKKwkJX3ByID0gcGVyX2NwdShwcm9j
ZXNzb3JzLCBjcHUpOworCQlpZiAoIV9wcikKKwkJCWNvbnRpbnVlOworCisJCSh2b2lkKXhlbl9w
cm9jZXNzX2RhdGEoX3ByLCBjcHUpOworCX0KKwlwdXRfb25saW5lX2NwdXMoKTsKKworCWNwdWZy
ZXFfY3B1X3B1dChwb2xpY3kpOworCXJldHVybiAwOworfQorLyoKKyAqIFRoZSBwdXJwb3NlIG9m
IHRoaXMgdGltZXIvdGhyZWFkIGlzIHRvIHdhaXQgZm9yIHRoZSBBQ1BJIHByb2Nlc3NvcgorICog
YW5kIENQVWZyZXEgZHJpdmVycyB0byBsb2FkIHVwIGFuZCBwYXJzZSB0aGUgUHh4IGFuZCBDeHgg
aW5mb3JtYXRpb24KKyAqIGJlZm9yZSB3ZSBhdHRlbXB0IHRvIHJlYWQgaXQuCisgKi8KK3N0YXRp
YyB2b2lkIHhlbl9wcm9jZXNzb3JfdGltZW91dCh1bnNpZ25lZCBsb25nIGFyZykKK3sKKwl3YWtl
X3VwX3Byb2Nlc3MoKHN0cnVjdCB0YXNrX3N0cnVjdCAqKWFyZyk7Cit9CitzdGF0aWMgaW50IHhl
bl9wcm9jZXNzb3JfdGhyZWFkX2Z1bmModm9pZCAqZHVtbXkpCit7CisJc3RydWN0IHRpbWVyX2xp
c3QgdGltZXI7CisKKwlzZXR1cF9kZWZlcnJhYmxlX3RpbWVyX29uX3N0YWNrKCZ0aW1lciwgeGVu
X3Byb2Nlc3Nvcl90aW1lb3V0LAorCQkJCQkodW5zaWduZWQgbG9uZyljdXJyZW50KTsKKworCWRv
IHsKKwkJX19zZXRfY3VycmVudF9zdGF0ZShUQVNLX0lOVEVSUlVQVElCTEUpOworCQltb2RfdGlt
ZXIoJnRpbWVyLCBqaWZmaWVzICsgUE9MTF9USU1FUik7CisJCXNjaGVkdWxlKCk7CisJCWlmICh4
ZW5fcHJvY2Vzc29yX2NoZWNrKCkgIT0gLUVCVVNZKQorCQkJYnJlYWs7CisJfSB3aGlsZSAoIWt0
aHJlYWRfc2hvdWxkX3N0b3AoKSk7CisKKwlkZWxfdGltZXJfc3luYygmdGltZXIpOworCWRlc3Ry
b3lfdGltZXJfb25fc3RhY2soJnRpbWVyKTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCB4
ZW5fY3B1X3NvZnRfbm90aWZ5KHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmZiLAorCQkJICAgICAg
IHVuc2lnbmVkIGxvbmcgYWN0aW9uLCB2b2lkICpoY3B1KQoreworCXVuc2lnbmVkIGludCBjcHUg
PSAodW5zaWduZWQgbG9uZyloY3B1OworCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3ByID0gcGVy
X2NwdShwcm9jZXNzb3JzLCBjcHUpOworCisJaWYgKGFjdGlvbiA9PSBDUFVfT05MSU5FICYmIF9w
cikKKwkJKHZvaWQpeGVuX3Byb2Nlc3NfZGF0YShfcHIsIGNwdSk7CisKKwlyZXR1cm4gTk9USUZZ
X09LOworfQorCitzdGF0aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2NrIHhlbl9jcHVfbm90aWZpZXIg
PSB7CisJLm5vdGlmaWVyX2NhbGwgPSB4ZW5fY3B1X3NvZnRfbm90aWZ5LAorCS5wcmlvcml0eSA9
IC0xLCAvKiBCZSB0aGUgbGFzdCBvbmUgKi8KK307CisKK3N0YXRpYyBpbnQgX19pbml0IGNoZWNr
X3ByZXJlcSh2b2lkKQoreworCXN0cnVjdCBjcHVpbmZvX3g4NiAqYyA9ICZjcHVfZGF0YSgwKTsK
KworCWlmICgheGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVWOworCisJaWYg
KCFhY3BpX2dibF9GQURULnNtaV9jb21tYW5kKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCWlmIChj
LT54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwpIHsKKwkJaWYgKCFjcHVfaGFzKGMsIFg4
Nl9GRUFUVVJFX0VTVCkpCisJCQlyZXR1cm4gLUVOT0RFVjsKKworCQlyZXR1cm4gMDsKKwl9CisJ
aWYgKGMtPng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9BTUQpIHsKKwkJdTMyIGhpID0gMCwgbG8g
PSAwOworCQkvKiBDb3BpZWQgZnJvbSBwb3dlcm5vdy1rOC5oLCBjYW4ndCBpbmNsdWRlIC4uL2Nw
dWZyZXEvcG93ZXJub3cKKwkJICogYXMgd2UgZ2V0IGNvbXBpbGUgd2FybmluZ3MgZm9yIHRoZSBz
dGF0aWMgZnVuY3Rpb25zLgorCQkgKi8KKyNkZWZpbmUgTVNSX1BTVEFURV9DVVJfTElNSVQgICAg
MHhjMDAxMDA2MSAvKiBwc3RhdGUgY3VycmVudCBsaW1pdCBNU1IgKi8KKwkJcmRtc3IoTVNSX1BT
VEFURV9DVVJfTElNSVQsIGxvLCBoaSk7CisKKwkJLyogSWYgdGhlIE1TUiBjYW5ub3QgcHJvdmlk
ZSB0aGUgZGF0YSwgdGhlIHBvd2Vybm93LWs4CisJCSAqIHdvbid0IHByb2Nlc3MgdGhlIGRhdGEg
cHJvcGVybHkgZWl0aGVyLgorCQkgKi8KKwkJaWYgKGhpIHx8IGxvKQorCQkJcmV0dXJuIDA7CisJ
fQorCXJldHVybiAtRU5PREVWOworfQorCitzdGF0aWMgaW50IF9faW5pdCB4ZW5fcHJvY2Vzc29y
X3Bhc3N0aHJ1X2luaXQodm9pZCkKK3sKKwlpbnQgcmMgPSBjaGVja19wcmVyZXEoKTsKKworCWlm
IChyYykKKwkJcmV0dXJuIHJjOworCisJeGVuX3Byb2Nlc3Nvcl90aHJlYWQgPSBrdGhyZWFkX3J1
bih4ZW5fcHJvY2Vzc29yX3RocmVhZF9mdW5jLCBOVUxMLCBEUlZfTkFNRSk7CisJaWYgKElTX0VS
Uih4ZW5fcHJvY2Vzc29yX3RocmVhZCkpIHsKKwkJcHJfZXJyKERSVl9OQU1FICI6IEZhaWxlZCB0
byBjcmVhdGUgdGhyZWFkLiBBYm9ydGluZy5cbiIpOworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisJ
cmVnaXN0ZXJfaG90Y3B1X25vdGlmaWVyKCZ4ZW5fY3B1X25vdGlmaWVyKTsKKwlyZXR1cm4gMDsK
K30KK3N0YXRpYyB2b2lkIF9fZXhpdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJ1X2V4aXQodm9pZCkK
K3sKKwl1bnJlZ2lzdGVyX2hvdGNwdV9ub3RpZmllcigmeGVuX2NwdV9ub3RpZmllcik7CisJaWYg
KHhlbl9wcm9jZXNzb3JfdGhyZWFkKQorCQlrdGhyZWFkX3N0b3AoeGVuX3Byb2Nlc3Nvcl90aHJl
YWQpOworfQorbGF0ZV9pbml0Y2FsbCh4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJ1X2luaXQpOworbW9k
dWxlX2V4aXQoeGVuX3Byb2Nlc3Nvcl9wYXNzdGhydV9leGl0KTsKLS0gCjEuNy43LjUKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00: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 1RzdKQ-00054i-R9; Tue, 21 Feb 2012 00:11:34 +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 1RzdKO-00054c-Vg
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329782958!62120742!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21755 invoked from network); 21 Feb 2012 00:09:19 -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 Feb 2012 00:09: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 q1L0BFOI023527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11: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
	q1L0BEkG023272
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:15 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1L0BEi0028981; Mon, 20 Feb 2012 18:11:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3E7EC4046C; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:46 -0500
Message-Id: <1329782868-1696-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
References: <20120214183006.GJ12984@reaktio.net>
	<1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F42E124.0067,ss=1,re=-2.300,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [PATCH 1/3] xen/processor-passthru: Change the name to
	processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

U3VnZ2VzdGVkLWJ5OiAgUGFzaSBLw6Rya2vDpGluZW4gPHBhc2lrQGlraS5maT4KU2lnbmVkLW9m
Zi1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0K
IGRyaXZlcnMveGVuL0tjb25maWcgICAgICAgICAgICAgIHwgICAgMiArLQogZHJpdmVycy94ZW4v
TWFrZWZpbGUgICAgICAgICAgICAgfCAgICAyICstCiBkcml2ZXJzL3hlbi9wcm9jZXNzb3ItaGFy
dmVzdC5jICB8ICAzOTcgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIGRy
aXZlcnMveGVuL3Byb2Nlc3Nvci1wYXNzdGhydS5jIHwgIDM5NyArKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKwogNCBmaWxlcyBjaGFuZ2VkLCAzOTkgaW5zZXJ0aW9ucygrKSwg
Mzk5IGRlbGV0aW9ucygtKQogZGVsZXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3Byb2Nlc3Nv
ci1oYXJ2ZXN0LmMKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi9wcm9jZXNzb3ItcGFz
c3RocnUuYwoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL0tjb25maWcgYi9kcml2ZXJzL3hlbi9L
Y29uZmlnCmluZGV4IDEyNjE4M2YuLmFmNWUwNjIgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL0tj
b25maWcKKysrIGIvZHJpdmVycy94ZW4vS2NvbmZpZwpAQCAtMTc4LDcgKzE3OCw3IEBAIGNvbmZp
ZyBYRU5fUFJJVkNNRAogCWRlcGVuZHMgb24gWEVOCiAJZGVmYXVsdCBtCiAKLWNvbmZpZyBYRU5f
UFJPQ0VTU09SX0hBUlZFU1QKK2NvbmZpZyBYRU5fUFJPQ0VTU09SX1BBU1NUSFJVCiAJdHJpc3Rh
dGUgIlByb2Nlc3NvciBwYXNzdGhyb3VnaCBkcml2ZXIgZm9yIFhlbiIKIAlkZXBlbmRzIG9uIFhF
TgogCWRlcGVuZHMgb24gQUNQSV9QUk9DRVNTT1IKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01h
a2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggODU2Y2ZjNi4uY2UyMzVlN2EgMTAw
NjQ0Ci0tLSBhL2RyaXZlcnMveGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxl
CkBAIC0yMCw3ICsyMCw3IEBAIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJCSs9IHN3aW90bGIt
eGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubwogb2JqLSQoQ09ORklHX1hF
Tl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05GSUdfWEVOX1BSSVZD
TUQpCQkrPSB4ZW4tcHJpdmNtZC5vCi1vYmotJChDT05GSUdfWEVOX1BST0NFU1NPUl9IQVJWRVNU
KQkrPSBwcm9jZXNzb3ItaGFydmVzdC5vCitvYmotJChDT05GSUdfWEVOX1BST0NFU1NPUl9QQVNT
VEhSVSkJKz0gcHJvY2Vzc29yLXBhc3N0aHJ1Lm8KIHhlbi1ldnRjaG4teQkJCQk6PSBldnRjaG4u
bwogeGVuLWdudGRldi15CQkJCTo9IGdudGRldi5vCiB4ZW4tZ250YWxsb2MteQkJCQk6PSBnbnRh
bGxvYy5vCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9wcm9jZXNzb3ItaGFydmVzdC5jIGIvZHJp
dmVycy94ZW4vcHJvY2Vzc29yLWhhcnZlc3QuYwpkZWxldGVkIGZpbGUgbW9kZSAxMDA2NDQKaW5k
ZXggNTA2ODFlMi4uMDAwMDAwMAotLS0gYS9kcml2ZXJzL3hlbi9wcm9jZXNzb3ItaGFydmVzdC5j
CisrKyAvZGV2L251bGwKQEAgLTEsMzk3ICswLDAgQEAKLS8qCi0gKiBDb3B5cmlnaHQgMjAxMiBi
eSBPcmFjbGUgSW5jCi0gKiBBdXRob3I6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndp
bGtAb3JhY2xlLmNvbT4KLSAqCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7
IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQKLSAqIHVuZGVyIHRoZSB0
ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsCi0g
KiB2ZXJzaW9uIDIsIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
LgotICoKLSAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSBpdCB3aWxs
IGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQKLSAqIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo
ZSBpbXBsaWVkIHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBvcgotICogRklUTkVTUyBGT1Ig
QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl
IGZvcgotICogbW9yZSBkZXRhaWxzLgotICoKLSAqLwotCi0vKgotICogIEtub3duIGxpbWl0YXRp
b25zCi0gKgotICogVGhlIGRyaXZlciBjYW4gb25seSBoYW5kbGUgdXAgdG8gIGZvcl9lYWNoX3Bv
c3NpYmxlX2NwdSgpLgotICogTWVhbmluZyBpZiB5b3UgYm9vdCB3aXRoIGRvbTBfbWF4X2NwdXM9
WCBpdCB3aWxsIF9vbmx5XyBwYXJzZSB1cCB0byBYCi0gKiBwcm9jZXNzb3JzLgotICovCi0KLSNp
bmNsdWRlIDxsaW51eC9jcHVtYXNrLmg+Ci0jaW5jbHVkZSA8bGludXgvY3B1ZnJlcS5oPgotI2lu
Y2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgotI2luY2x1ZGUgPGxpbnV4L2t0aHJlYWQuaD4KLSNpbmNs
dWRlIDxsaW51eC9pbml0Lmg+Ci0jaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+Ci0jaW5jbHVkZSA8
bGludXgvdHlwZXMuaD4KLSNpbmNsdWRlIDxhY3BpL2FjcGlfYnVzLmg+Ci0jaW5jbHVkZSA8YWNw
aS9hY3BpX2RyaXZlcnMuaD4KLSNpbmNsdWRlIDxhY3BpL3Byb2Nlc3Nvci5oPgotCi0jaW5jbHVk
ZSA8eGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oPgotI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxs
Lmg+Ci0KLSNkZWZpbmUgRFJWX05BTUUgInByb2Nlc3Nvci1wYXNzdGhyb3VnaC14ZW4iCi1NT0RV
TEVfQVVUSE9SKCJLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+
Iik7Ci1NT0RVTEVfREVTQ1JJUFRJT04oIkFDUEkgUG93ZXIgTWFuYWdlbWVudCBkcml2ZXIgdG8g
cGFzcyBDeCBhbmQgUHh4IGRhdGEgdG8gWGVuIGh5cGVydmlzb3IiKTsKLU1PRFVMRV9MSUNFTlNF
KCJHUEwiKTsKLQotCi1NT0RVTEVfUEFSTV9ERVNDKG9mZiwgIkluaGliaXQgdGhlIGh5cGVyY2Fs
bC4iKTsKLXN0YXRpYyBpbnQgbm9faHlwZXJjYWxsOwotbW9kdWxlX3BhcmFtX25hbWVkKG9mZiwg
bm9faHlwZXJjYWxsLCBpbnQsIDA0MDApOwotCi1zdGF0aWMgREVGSU5FX01VVEVYKHByb2Nlc3Nv
cnNfZG9uZV9tdXRleCk7Ci1zdGF0aWMgREVDTEFSRV9CSVRNQVAocHJvY2Vzc29yc19kb25lLCBO
Ul9DUFVTKTsKLQotI2RlZmluZSBQT0xMX1RJTUVSIG1zZWNzX3RvX2ppZmZpZXMoNTAwMCAvKiA1
IHNlYyAqLykKLXN0YXRpYyBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnhlbl9wcm9jZXNzb3JfdGhyZWFk
OwotCi1zdGF0aWMgaW50IHhlbl9wdXNoX2N4eF90b19oeXBlcnZpc29yKHN0cnVjdCBhY3BpX3By
b2Nlc3NvciAqX3ByKQotewotCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7Ci0JCS5jbWQJ
CQk9IFhFTlBGX3NldF9wcm9jZXNzb3JfcG1pbmZvLAotCQkuaW50ZXJmYWNlX3ZlcnNpb24JPSBY
RU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKLQkJLnUuc2V0X3BtaW5mby5pZAk9IF9wci0+YWNwaV9p
ZCwKLQkJLnUuc2V0X3BtaW5mby50eXBlCT0gWEVOX1BNX0NYLAotCX07Ci0Jc3RydWN0IHhlbl9w
cm9jZXNzb3JfY3ggKnhlbl9jeCwgKnhlbl9jeF9zdGF0ZXMgPSBOVUxMOwotCXN0cnVjdCBhY3Bp
X3Byb2Nlc3Nvcl9jeCAqY3g7Ci0JaW50IGksIG9rLCByZXQgPSAwOwotCi0JeGVuX2N4X3N0YXRl
cyA9IGtjYWxsb2MoX3ByLT5wb3dlci5jb3VudCwKLQkJCQlzaXplb2Yoc3RydWN0IHhlbl9wcm9j
ZXNzb3JfY3gpLCBHRlBfS0VSTkVMKTsKLQlpZiAoIXhlbl9jeF9zdGF0ZXMpCi0JCXJldHVybiAt
RU5PTUVNOwotCi0JZm9yIChvayA9IDAsIGkgPSAxOyBpIDw9IF9wci0+cG93ZXIuY291bnQ7IGkr
KykgewotCQljeCA9ICZfcHItPnBvd2VyLnN0YXRlc1tpXTsKLQkJaWYgKCFjeC0+dmFsaWQpCi0J
CQljb250aW51ZTsKLQotCQl4ZW5fY3ggPSAmKHhlbl9jeF9zdGF0ZXNbb2srK10pOwotCi0JCXhl
bl9jeC0+cmVnLnNwYWNlX2lkID0gQUNQSV9BRFJfU1BBQ0VfU1lTVEVNX0lPOwotCQlpZiAoY3gt
PmVudHJ5X21ldGhvZCA9PSBBQ1BJX0NTVEFURV9TWVNURU1JTykgewotCQkJeGVuX2N4LT5yZWcu
Yml0X3dpZHRoID0gODsKLQkJCXhlbl9jeC0+cmVnLmJpdF9vZmZzZXQgPSAwOwotCQkJeGVuX2N4
LT5yZWcuYWNjZXNzX3NpemUgPSAxOwotCQl9IGVsc2UgewotCQkJeGVuX2N4LT5yZWcuc3BhY2Vf
aWQgPSBBQ1BJX0FEUl9TUEFDRV9GSVhFRF9IQVJEV0FSRTsKLQkJCWlmIChjeC0+ZW50cnlfbWV0
aG9kID09IEFDUElfQ1NUQVRFX0ZGSCkgewotCQkJCS8qIE5BVElWRV9DU1RBVEVfQkVZT05EX0hB
TFQgKi8KLQkJCQl4ZW5fY3gtPnJlZy5iaXRfb2Zmc2V0ID0gMjsKLQkJCQl4ZW5fY3gtPnJlZy5i
aXRfd2lkdGggPSAxOyAvKiBWRU5ET1JfSU5URUwgKi8KLQkJCX0KLQkJCXhlbl9jeC0+cmVnLmFj
Y2Vzc19zaXplID0gMDsKLQkJfQotCQl4ZW5fY3gtPnJlZy5hZGRyZXNzID0gY3gtPmFkZHJlc3M7
Ci0KLQkJeGVuX2N4LT50eXBlID0gY3gtPnR5cGU7Ci0JCXhlbl9jeC0+bGF0ZW5jeSA9IGN4LT5s
YXRlbmN5OwotCQl4ZW5fY3gtPnBvd2VyID0gY3gtPnBvd2VyOwotCi0JCXhlbl9jeC0+ZHBjbnQg
PSAwOwotCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fY3gtPmRwLCBOVUxMKTsKLSNpZmRlZiBE
RUJVRwotCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiBDWDogSUQ6JWQgW0MlZDolc10gZW50cnk6JWRc
biIsIF9wci0+YWNwaV9pZCwKLQkJCSBjeC0+dHlwZSwgY3gtPmRlc2MsIGN4LT5lbnRyeV9tZXRo
b2QpOwotI2VuZGlmCi0JfQotCWlmICghb2spIHsKLQkJcHJfZXJyKERSVl9OQU1FICI6IE5vIGF2
YWlsYWJsZSBDeCBpbmZvIGZvciBjcHUgJWRcbiIsIF9wci0+YWNwaV9pZCk7Ci0JCWtmcmVlKHhl
bl9jeF9zdGF0ZXMpOwotCQlyZXR1cm4gLUVJTlZBTDsKLQl9Ci0Jb3AudS5zZXRfcG1pbmZvLnBv
d2VyLmNvdW50ID0gb2s7Ci0Jb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZsYWdzLmJtX2NvbnRyb2wg
PSBfcHItPmZsYWdzLmJtX2NvbnRyb2w7Ci0Jb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZsYWdzLmJt
X2NoZWNrID0gX3ByLT5mbGFncy5ibV9jaGVjazsKLQlvcC51LnNldF9wbWluZm8ucG93ZXIuZmxh
Z3MuaGFzX2NzdCA9IF9wci0+ZmxhZ3MuaGFzX2NzdDsKLQlvcC51LnNldF9wbWluZm8ucG93ZXIu
ZmxhZ3MucG93ZXJfc2V0dXBfZG9uZSA9Ci0JCV9wci0+ZmxhZ3MucG93ZXJfc2V0dXBfZG9uZTsK
LQotCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG9wLnUuc2V0X3BtaW5mby5wb3dlci5zdGF0ZXMsIHhl
bl9jeF9zdGF0ZXMpOwotCi0JaWYgKCFub19oeXBlcmNhbGwgJiYgeGVuX2luaXRpYWxfZG9tYWlu
KCkpCi0JCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwotCi0JaWYgKHJldCkgewotCQlw
cl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNlbmQgdG8gaHlwZXJ2aXNvciAocmM6JWQpXG4i
LCByZXQpOwotCQlwcmludF9oZXhfZHVtcF9ieXRlcygiT1A6ICIsIERVTVBfUFJFRklYX05PTkUs
ICZvcCwKLQkJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wKSk7Ci0JCXByaW50
X2hleF9kdW1wX2J5dGVzKCJDeDogIiwgRFVNUF9QUkVGSVhfTk9ORSwgeGVuX2N4X3N0YXRlcywK
LQkJCQkgICAgIF9wci0+cG93ZXIuY291bnQgKgotCQkJCSAgICAgc2l6ZW9mKHN0cnVjdCB4ZW5f
cHJvY2Vzc29yX2N4KSk7Ci0JfQotCWtmcmVlKHhlbl9jeF9zdGF0ZXMpOwotCi0JcmV0dXJuIHJl
dDsKLX0KLQotCi0KLXN0YXRpYyBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX2NvcHlfcHNz
X2RhdGEoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIsCi0JCQkJCQkgIHN0cnVjdCB4ZW5fcHJv
Y2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZikKLXsKLQlzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9w
eCAqeGVuX3N0YXRlcyA9IE5VTEw7Ci0JaW50IGk7Ci0KLQl4ZW5fc3RhdGVzID0ga2NhbGxvYyhf
cHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCwKLQkJCSAgICAgc2l6ZW9mKHN0cnVjdCB4ZW5f
cHJvY2Vzc29yX3B4KSwgR0ZQX0tFUk5FTCk7Ci0JaWYgKCF4ZW5fc3RhdGVzKQotCQlyZXR1cm4g
RVJSX1BUUigtRU5PTUVNKTsKLQotCXhlbl9wZXJmLT5zdGF0ZV9jb3VudCA9IF9wci0+cGVyZm9y
bWFuY2UtPnN0YXRlX2NvdW50OwotCi0JQlVJTERfQlVHX09OKHNpemVvZihzdHJ1Y3QgeGVuX3By
b2Nlc3Nvcl9weCkgIT0KLQkJICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHJvY2Vzc29yX3B4KSk7
Ci0JZm9yIChpID0gMDsgaSA8IF9wci0+cGVyZm9ybWFuY2UtPnN0YXRlX2NvdW50OyBpKyspIHsK
LQotCQkvKiBGb3J0dW5hdGx5IGZvciB1cywgdGhleSBib3RoIGhhdmUgdGhlIHNhbWUgc2l6ZSAq
LwotCQltZW1jcHkoJih4ZW5fc3RhdGVzW2ldKSwgJihfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZXNb
aV0pLAotCQkgICAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nlc3Nvcl9weCkpOwotCX0KLQly
ZXR1cm4geGVuX3N0YXRlczsKLX0KLXN0YXRpYyBpbnQgeGVuX2NvcHlfcHNkX2RhdGEoc3RydWN0
IGFjcGlfcHJvY2Vzc29yICpfcHIsCi0JCQkgICAgIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZv
cm1hbmNlICp4ZW5fcGVyZikKLXsKLQlCVUlMRF9CVUdfT04oc2l6ZW9mKHN0cnVjdCB4ZW5fcHNk
X3BhY2thZ2UpICE9Ci0JCSAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3BzZF9wYWNrYWdlKSk7Ci0K
LQlpZiAoX3ByLT5wZXJmb3JtYW5jZS0+c2hhcmVkX3R5cGUgIT0gQ1BVRlJFUV9TSEFSRURfVFlQ
RV9OT05FKSB7Ci0JCXhlbl9wZXJmLT5zaGFyZWRfdHlwZSA9IF9wci0+cGVyZm9ybWFuY2UtPnNo
YXJlZF90eXBlOwotCi0JCW1lbWNweSgmKHhlbl9wZXJmLT5kb21haW5faW5mbyksICYoX3ByLT5w
ZXJmb3JtYW5jZS0+ZG9tYWluX2luZm8pLAotCQkgICAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Bz
ZF9wYWNrYWdlKSk7Ci0JfSBlbHNlIHsKLQkJaWYgKCgmY3B1X2RhdGEoMCkpLT54ODZfdmVuZG9y
ICE9IFg4Nl9WRU5ET1JfQU1EKQotCQkJcmV0dXJuIC1FSU5WQUw7Ci0KLQkJLyogT24gQU1ELCB0
aGUgcG93ZXJub3ctazggaXMgbG9hZGVkIGJlZm9yZSBhY3BpX2NwdWZyZXEKLQkJICogbWVhbmlu
ZyB0aGF0IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZvcm1hbmNlIG5ldmVyCi0JCSAq
IGdldHMgY2FsbGVkIHdoaWNoIHdvdWxkIHBhcnNlIHRoZSBfQ1NULgotCQkgKi8KLQkJeGVuX3Bl
cmYtPnNoYXJlZF90eXBlID0gQ1BVRlJFUV9TSEFSRURfVFlQRV9BTEw7Ci0JCXhlbl9wZXJmLT5k
b21haW5faW5mby5udW1fcHJvY2Vzc29ycyA9IG51bV9vbmxpbmVfY3B1cygpOwotCX0KLQlyZXR1
cm4gMDsKLX0KLXN0YXRpYyBpbnQgeGVuX2NvcHlfcGN0X2RhdGEoc3RydWN0IGFjcGlfcGN0X3Jl
Z2lzdGVyICpwY3QsCi0JCQkgICAgIHN0cnVjdCB4ZW5fcGN0X3JlZ2lzdGVyICpfcGN0KQotewot
CS8qIEl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGp1c3QgZG8gJ21lbWNweShwY3QsIF9w
Y3QnKSBidXQKLQkgKiBzYWRseSB0aGUgWGVuIHN0cnVjdHVyZSBkaWQgbm90IGhhdmUgdGhlIHBy
b3BlciBwYWRkaW5nCi0JICogc28gdGhlIGRlc2NyaXB0b3IgZmllbGQgdGFrZXMgdHdvIChfcGN0
KSBieXRlcyBpbnN0ZWFkIG9mIG9uZSAocGN0KS4KLQkgKi8KLQlfcGN0LT5kZXNjcmlwdG9yID0g
cGN0LT5kZXNjcmlwdG9yOwotCV9wY3QtPmxlbmd0aCA9IHBjdC0+bGVuZ3RoOwotCV9wY3QtPnNw
YWNlX2lkID0gcGN0LT5zcGFjZV9pZDsKLQlfcGN0LT5iaXRfd2lkdGggPSBwY3QtPmJpdF93aWR0
aDsKLQlfcGN0LT5iaXRfb2Zmc2V0ID0gcGN0LT5iaXRfb2Zmc2V0OwotCV9wY3QtPnJlc2VydmVk
ID0gcGN0LT5yZXNlcnZlZDsKLQlfcGN0LT5hZGRyZXNzID0gcGN0LT5hZGRyZXNzOwotCXJldHVy
biAwOwotfQotc3RhdGljIGludCB4ZW5fcHVzaF9weHhfdG9faHlwZXJ2aXNvcihzdHJ1Y3QgYWNw
aV9wcm9jZXNzb3IgKl9wcikKLXsKLQlpbnQgcmV0ID0gMDsKLQlzdHJ1Y3QgeGVuX3BsYXRmb3Jt
X29wIG9wID0gewotCQkuY21kCQkJPSBYRU5QRl9zZXRfcHJvY2Vzc29yX3BtaW5mbywKLQkJLmlu
dGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCi0JCS51LnNldF9wbWlu
Zm8uaWQJPSBfcHItPmFjcGlfaWQsCi0JCS51LnNldF9wbWluZm8udHlwZQk9IFhFTl9QTV9QWCwK
LQl9OwotCXN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZjsKLQlzdHJ1
Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX3N0YXRlcyA9IE5VTEw7Ci0KLQl4ZW5fcGVyZiA9ICZv
cC51LnNldF9wbWluZm8ucGVyZjsKLQotCXhlbl9wZXJmLT5wbGF0Zm9ybV9saW1pdCA9IF9wci0+
cGVyZm9ybWFuY2VfcGxhdGZvcm1fbGltaXQ7Ci0JeGVuX3BlcmYtPmZsYWdzIHw9IFhFTl9QWF9Q
UEM7Ci0JeGVuX2NvcHlfcGN0X2RhdGEoJihfcHItPnBlcmZvcm1hbmNlLT5jb250cm9sX3JlZ2lz
dGVyKSwKLQkJCSAgJnhlbl9wZXJmLT5jb250cm9sX3JlZ2lzdGVyKTsKLQl4ZW5fY29weV9wY3Rf
ZGF0YSgmKF9wci0+cGVyZm9ybWFuY2UtPnN0YXR1c19yZWdpc3RlciksCi0JCQkgICZ4ZW5fcGVy
Zi0+c3RhdHVzX3JlZ2lzdGVyKTsKLQl4ZW5fcGVyZi0+ZmxhZ3MgfD0gWEVOX1BYX1BDVDsKLQl4
ZW5fc3RhdGVzID0geGVuX2NvcHlfcHNzX2RhdGEoX3ByLCB4ZW5fcGVyZik7Ci0JaWYgKCFJU19F
UlJfT1JfTlVMTCh4ZW5fc3RhdGVzKSkgewotCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fcGVy
Zi0+c3RhdGVzLCB4ZW5fc3RhdGVzKTsKLQkJeGVuX3BlcmYtPmZsYWdzIHw9IFhFTl9QWF9QU1M7
Ci0JfQotCWlmICgheGVuX2NvcHlfcHNkX2RhdGEoX3ByLCB4ZW5fcGVyZikpCi0JCXhlbl9wZXJm
LT5mbGFncyB8PSBYRU5fUFhfUFNEOwotCi0JaWYgKCFub19oeXBlcmNhbGwgJiYgeGVuX2luaXRp
YWxfZG9tYWluKCkpCi0JCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwotCi0JaWYgKHJl
dCkgewotCQlwcl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNlbmQgdG8gaHlwZXJ2aXNvciAo
cmM6JWQpXG4iLCByZXQpOwotCQlwcmludF9oZXhfZHVtcF9ieXRlcygiT1A6ICIsIERVTVBfUFJF
RklYX05PTkUsICZvcCwKLQkJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wKSk7
Ci0JCWlmICghSVNfRVJSX09SX05VTEwoeGVuX3N0YXRlcykpCi0JCQlwcmludF9oZXhfZHVtcF9i
eXRlcygiUHh4OiIsIERVTVBfUFJFRklYX05PTkUsIHhlbl9zdGF0ZXMsCi0JCQkJICAgICBfcHIt
PnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCAqCi0JCQkJICAgICBzaXplb2Yoc3RydWN0IHhlbl9w
cm9jZXNzb3JfcHgpKTsKLQl9Ci0JaWYgKCFJU19FUlJfT1JfTlVMTCh4ZW5fc3RhdGVzKSkKLQkJ
a2ZyZWUoeGVuX3N0YXRlcyk7Ci0KLQlyZXR1cm4gcmV0OwotfQotLyoKLSAqIFdlIHJlYWQgb3V0
IHRoZSBzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IsIGFuZCBzZXJpYWxpemUgYWNjZXNzCi0gKiBzbyB0
aGF0IHRoZXJlIGlzIG9ubHkgb25lIGNhbGxlci4gVGhpcyBpcyBzbyB0aGF0IHdlIHdvbid0Ci0g
KiByYWNlIHdpdGggdGhlIENQVSBob3RwbHVnIGNvZGUuCi0gKi8KLXN0YXRpYyBpbnQgeGVuX3By
b2Nlc3NfZGF0YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wciwgaW50IGNwdSkKLXsKLQlpbnQg
ZXJyID0gMDsKLQotCW11dGV4X2xvY2soJnByb2Nlc3NvcnNfZG9uZV9tdXRleCk7Ci0JaWYgKGNw
dW1hc2tfdGVzdF9jcHUoY3B1LCB0b19jcHVtYXNrKHByb2Nlc3NvcnNfZG9uZSkpKSB7Ci0JCW11
dGV4X3VubG9jaygmcHJvY2Vzc29yc19kb25lX211dGV4KTsKLQkJcmV0dXJuIC1FQlVTWTsKLQl9
Ci0JaWYgKF9wci0+ZmxhZ3MucG93ZXIpCi0JCWVyciA9IHhlbl9wdXNoX2N4eF90b19oeXBlcnZp
c29yKF9wcik7Ci0KLQlpZiAoX3ByLT5wZXJmb3JtYW5jZSAmJiBfcHItPnBlcmZvcm1hbmNlLT5z
dGF0ZXMpCi0JCWVyciB8PSB4ZW5fcHVzaF9weHhfdG9faHlwZXJ2aXNvcihfcHIpOwotCi0JY3B1
bWFza19zZXRfY3B1KGNwdSwgdG9fY3B1bWFzayhwcm9jZXNzb3JzX2RvbmUpKTsKLQltdXRleF91
bmxvY2soJnByb2Nlc3NvcnNfZG9uZV9tdXRleCk7Ci0JcmV0dXJuIGVycjsKLX0KLQotc3RhdGlj
IGludCB4ZW5fcHJvY2Vzc29yX2NoZWNrKHZvaWQpCi17Ci0Jc3RydWN0IGNwdWZyZXFfcG9saWN5
ICpwb2xpY3k7Ci0JaW50IGNwdTsKLQotCXBvbGljeSA9IGNwdWZyZXFfY3B1X2dldChzbXBfcHJv
Y2Vzc29yX2lkKCkpOwotCWlmICghcG9saWN5KQotCQlyZXR1cm4gLUVCVVNZOwotCi0JZ2V0X29u
bGluZV9jcHVzKCk7Ci0JZm9yX2VhY2hfb25saW5lX2NwdShjcHUpIHsKLQkJc3RydWN0IGFjcGlf
cHJvY2Vzc29yICpfcHI7Ci0KLQkJX3ByID0gcGVyX2NwdShwcm9jZXNzb3JzLCBjcHUpOwotCQlp
ZiAoIV9wcikKLQkJCWNvbnRpbnVlOwotCi0JCSh2b2lkKXhlbl9wcm9jZXNzX2RhdGEoX3ByLCBj
cHUpOwotCX0KLQlwdXRfb25saW5lX2NwdXMoKTsKLQotCWNwdWZyZXFfY3B1X3B1dChwb2xpY3kp
OwotCXJldHVybiAwOwotfQotLyoKLSAqIFRoZSBwdXJwb3NlIG9mIHRoaXMgdGltZXIvdGhyZWFk
IGlzIHRvIHdhaXQgZm9yIHRoZSBBQ1BJIHByb2Nlc3NvcgotICogYW5kIENQVWZyZXEgZHJpdmVy
cyB0byBsb2FkIHVwIGFuZCBwYXJzZSB0aGUgUHh4IGFuZCBDeHggaW5mb3JtYXRpb24KLSAqIGJl
Zm9yZSB3ZSBhdHRlbXB0IHRvIHJlYWQgaXQuCi0gKi8KLXN0YXRpYyB2b2lkIHhlbl9wcm9jZXNz
b3JfdGltZW91dCh1bnNpZ25lZCBsb25nIGFyZykKLXsKLQl3YWtlX3VwX3Byb2Nlc3MoKHN0cnVj
dCB0YXNrX3N0cnVjdCAqKWFyZyk7Ci19Ci1zdGF0aWMgaW50IHhlbl9wcm9jZXNzb3JfdGhyZWFk
X2Z1bmModm9pZCAqZHVtbXkpCi17Ci0Jc3RydWN0IHRpbWVyX2xpc3QgdGltZXI7Ci0KLQlzZXR1
cF9kZWZlcnJhYmxlX3RpbWVyX29uX3N0YWNrKCZ0aW1lciwgeGVuX3Byb2Nlc3Nvcl90aW1lb3V0
LAotCQkJCQkodW5zaWduZWQgbG9uZyljdXJyZW50KTsKLQotCWRvIHsKLQkJX19zZXRfY3VycmVu
dF9zdGF0ZShUQVNLX0lOVEVSUlVQVElCTEUpOwotCQltb2RfdGltZXIoJnRpbWVyLCBqaWZmaWVz
ICsgUE9MTF9USU1FUik7Ci0JCXNjaGVkdWxlKCk7Ci0JCWlmICh4ZW5fcHJvY2Vzc29yX2NoZWNr
KCkgIT0gLUVCVVNZKQotCQkJYnJlYWs7Ci0JfSB3aGlsZSAoIWt0aHJlYWRfc2hvdWxkX3N0b3Ao
KSk7Ci0KLQlkZWxfdGltZXJfc3luYygmdGltZXIpOwotCWRlc3Ryb3lfdGltZXJfb25fc3RhY2so
JnRpbWVyKTsKLQlyZXR1cm4gMDsKLX0KLQotc3RhdGljIGludCB4ZW5fY3B1X3NvZnRfbm90aWZ5
KHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmZiLAotCQkJICAgICAgIHVuc2lnbmVkIGxvbmcgYWN0
aW9uLCB2b2lkICpoY3B1KQotewotCXVuc2lnbmVkIGludCBjcHUgPSAodW5zaWduZWQgbG9uZylo
Y3B1OwotCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3ByID0gcGVyX2NwdShwcm9jZXNzb3JzLCBj
cHUpOwotCi0JaWYgKGFjdGlvbiA9PSBDUFVfT05MSU5FICYmIF9wcikKLQkJKHZvaWQpeGVuX3By
b2Nlc3NfZGF0YShfcHIsIGNwdSk7Ci0KLQlyZXR1cm4gTk9USUZZX09LOwotfQotCi1zdGF0aWMg
c3RydWN0IG5vdGlmaWVyX2Jsb2NrIHhlbl9jcHVfbm90aWZpZXIgPSB7Ci0JLm5vdGlmaWVyX2Nh
bGwgPSB4ZW5fY3B1X3NvZnRfbm90aWZ5LAotCS5wcmlvcml0eSA9IC0xLCAvKiBCZSB0aGUgbGFz
dCBvbmUgKi8KLX07Ci0KLXN0YXRpYyBpbnQgX19pbml0IGNoZWNrX3ByZXJlcSh2b2lkKQotewot
CXN0cnVjdCBjcHVpbmZvX3g4NiAqYyA9ICZjcHVfZGF0YSgwKTsKLQotCWlmICgheGVuX2luaXRp
YWxfZG9tYWluKCkpCi0JCXJldHVybiAtRU5PREVWOwotCi0JaWYgKCFhY3BpX2dibF9GQURULnNt
aV9jb21tYW5kKQotCQlyZXR1cm4gLUVOT0RFVjsKLQotCWlmIChjLT54ODZfdmVuZG9yID09IFg4
Nl9WRU5ET1JfSU5URUwpIHsKLQkJaWYgKCFjcHVfaGFzKGMsIFg4Nl9GRUFUVVJFX0VTVCkpCi0J
CQlyZXR1cm4gLUVOT0RFVjsKLQotCQlyZXR1cm4gMDsKLQl9Ci0JaWYgKGMtPng4Nl92ZW5kb3Ig
PT0gWDg2X1ZFTkRPUl9BTUQpIHsKLQkJdTMyIGhpID0gMCwgbG8gPSAwOwotCQkvKiBDb3BpZWQg
ZnJvbSBwb3dlcm5vdy1rOC5oLCBjYW4ndCBpbmNsdWRlIC4uL2NwdWZyZXEvcG93ZXJub3cKLQkJ
ICogYXMgd2UgZ2V0IGNvbXBpbGUgd2FybmluZ3MgZm9yIHRoZSBzdGF0aWMgZnVuY3Rpb25zLgot
CQkgKi8KLSNkZWZpbmUgTVNSX1BTVEFURV9DVVJfTElNSVQgICAgMHhjMDAxMDA2MSAvKiBwc3Rh
dGUgY3VycmVudCBsaW1pdCBNU1IgKi8KLQkJcmRtc3IoTVNSX1BTVEFURV9DVVJfTElNSVQsIGxv
LCBoaSk7Ci0KLQkJLyogSWYgdGhlIE1TUiBjYW5ub3QgcHJvdmlkZSB0aGUgZGF0YSwgdGhlIHBv
d2Vybm93LWs4Ci0JCSAqIHdvbid0IHByb2Nlc3MgdGhlIGRhdGEgcHJvcGVybHkgZWl0aGVyLgot
CQkgKi8KLQkJaWYgKGhpIHx8IGxvKQotCQkJcmV0dXJuIDA7Ci0JfQotCXJldHVybiAtRU5PREVW
OwotfQotCi1zdGF0aWMgaW50IF9faW5pdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJvdWdoX2luaXQo
dm9pZCkKLXsKLQlpbnQgcmMgPSBjaGVja19wcmVyZXEoKTsKLQotCWlmIChyYykKLQkJcmV0dXJu
IHJjOwotCi0JeGVuX3Byb2Nlc3Nvcl90aHJlYWQgPSBrdGhyZWFkX3J1bih4ZW5fcHJvY2Vzc29y
X3RocmVhZF9mdW5jLCBOVUxMLCBEUlZfTkFNRSk7Ci0JaWYgKElTX0VSUih4ZW5fcHJvY2Vzc29y
X3RocmVhZCkpIHsKLQkJcHJfZXJyKERSVl9OQU1FICI6IEZhaWxlZCB0byBjcmVhdGUgdGhyZWFk
LiBBYm9ydGluZy5cbiIpOwotCQlyZXR1cm4gLUVOT01FTTsKLQl9Ci0JcmVnaXN0ZXJfaG90Y3B1
X25vdGlmaWVyKCZ4ZW5fY3B1X25vdGlmaWVyKTsKLQlyZXR1cm4gMDsKLX0KLXN0YXRpYyB2b2lk
IF9fZXhpdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJvdWdoX2V4aXQodm9pZCkKLXsKLQl1bnJlZ2lz
dGVyX2hvdGNwdV9ub3RpZmllcigmeGVuX2NwdV9ub3RpZmllcik7Ci0JaWYgKHhlbl9wcm9jZXNz
b3JfdGhyZWFkKQotCQlrdGhyZWFkX3N0b3AoeGVuX3Byb2Nlc3Nvcl90aHJlYWQpOwotfQotbGF0
ZV9pbml0Y2FsbCh4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJvdWdoX2luaXQpOwotbW9kdWxlX2V4aXQo
eGVuX3Byb2Nlc3Nvcl9wYXNzdGhyb3VnaF9leGl0KTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L3Byb2Nlc3Nvci1wYXNzdGhydS5jIGIvZHJpdmVycy94ZW4vcHJvY2Vzc29yLXBhc3N0aHJ1LmMK
bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uYWJmY2JlNAotLS0gL2Rldi9udWxs
CisrKyBiL2RyaXZlcnMveGVuL3Byb2Nlc3Nvci1wYXNzdGhydS5jCkBAIC0wLDAgKzEsMzk3IEBA
CisvKgorICogQ29weXJpZ2h0IDIwMTIgYnkgT3JhY2xlIEluYworICogQXV0aG9yOiBLb25yYWQg
Unplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CisgKgorICoKKyAqIFRoaXMg
cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5IGl0CisgKiB1bmRlciB0aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBH
ZW5lcmFsIFB1YmxpYyBMaWNlbnNlLAorICogdmVyc2lvbiAyLCBhcyBwdWJsaXNoZWQgYnkgdGhl
IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJp
YnV0ZWQgaW4gdGhlIGhvcGUgaXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkg
V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFC
SUxJVFkgb3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBH
TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqCisgKi8K
KworLyoKKyAqICBLbm93biBsaW1pdGF0aW9ucworICoKKyAqIFRoZSBkcml2ZXIgY2FuIG9ubHkg
aGFuZGxlIHVwIHRvICBmb3JfZWFjaF9wb3NzaWJsZV9jcHUoKS4KKyAqIE1lYW5pbmcgaWYgeW91
IGJvb3Qgd2l0aCBkb20wX21heF9jcHVzPVggaXQgd2lsbCBfb25seV8gcGFyc2UgdXAgdG8gWAor
ICogcHJvY2Vzc29ycy4KKyAqLworCisjaW5jbHVkZSA8bGludXgvY3B1bWFzay5oPgorI2luY2x1
ZGUgPGxpbnV4L2NwdWZyZXEuaD4KKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNpbmNsdWRl
IDxsaW51eC9rdGhyZWFkLmg+CisjaW5jbHVkZSA8bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxp
bnV4L21vZHVsZS5oPgorI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8YWNwaS9h
Y3BpX2J1cy5oPgorI2luY2x1ZGUgPGFjcGkvYWNwaV9kcml2ZXJzLmg+CisjaW5jbHVkZSA8YWNw
aS9wcm9jZXNzb3IuaD4KKworI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaD4KKyNp
bmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorCisjZGVmaW5lIERSVl9OQU1FICJ4ZW4tcHJv
Y2Vzc29yLXRocnUiCitNT0RVTEVfQVVUSE9SKCJLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJh
ZC53aWxrQG9yYWNsZS5jb20+Iik7CitNT0RVTEVfREVTQ1JJUFRJT04oIkFDUEkgUG93ZXIgTWFu
YWdlbWVudCBkcml2ZXIgdG8gcGFzcyBDeCBhbmQgUHh4IGRhdGEgdG8gWGVuIGh5cGVydmlzb3Ii
KTsKK01PRFVMRV9MSUNFTlNFKCJHUEwiKTsKKworCitNT0RVTEVfUEFSTV9ERVNDKG9mZiwgIklu
aGliaXQgdGhlIGh5cGVyY2FsbC4iKTsKK3N0YXRpYyBpbnQgbm9faHlwZXJjYWxsOworbW9kdWxl
X3BhcmFtX25hbWVkKG9mZiwgbm9faHlwZXJjYWxsLCBpbnQsIDA0MDApOworCitzdGF0aWMgREVG
SU5FX01VVEVYKHByb2Nlc3NvcnNfZG9uZV9tdXRleCk7CitzdGF0aWMgREVDTEFSRV9CSVRNQVAo
cHJvY2Vzc29yc19kb25lLCBOUl9DUFVTKTsKKworI2RlZmluZSBQT0xMX1RJTUVSIG1zZWNzX3Rv
X2ppZmZpZXMoNTAwMCAvKiA1IHNlYyAqLykKK3N0YXRpYyBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnhl
bl9wcm9jZXNzb3JfdGhyZWFkOworCitzdGF0aWMgaW50IHhlbl9wdXNoX2N4eF90b19oeXBlcnZp
c29yKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3ByKQoreworCXN0cnVjdCB4ZW5fcGxhdGZvcm1f
b3Agb3AgPSB7CisJCS5jbWQJCQk9IFhFTlBGX3NldF9wcm9jZXNzb3JfcG1pbmZvLAorCQkuaW50
ZXJmYWNlX3ZlcnNpb24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuc2V0X3BtaW5m
by5pZAk9IF9wci0+YWNwaV9pZCwKKwkJLnUuc2V0X3BtaW5mby50eXBlCT0gWEVOX1BNX0NYLAor
CX07CisJc3RydWN0IHhlbl9wcm9jZXNzb3JfY3ggKnhlbl9jeCwgKnhlbl9jeF9zdGF0ZXMgPSBO
VUxMOworCXN0cnVjdCBhY3BpX3Byb2Nlc3Nvcl9jeCAqY3g7CisJaW50IGksIG9rLCByZXQgPSAw
OworCisJeGVuX2N4X3N0YXRlcyA9IGtjYWxsb2MoX3ByLT5wb3dlci5jb3VudCwKKwkJCQlzaXpl
b2Yoc3RydWN0IHhlbl9wcm9jZXNzb3JfY3gpLCBHRlBfS0VSTkVMKTsKKwlpZiAoIXhlbl9jeF9z
dGF0ZXMpCisJCXJldHVybiAtRU5PTUVNOworCisJZm9yIChvayA9IDAsIGkgPSAxOyBpIDw9IF9w
ci0+cG93ZXIuY291bnQ7IGkrKykgeworCQljeCA9ICZfcHItPnBvd2VyLnN0YXRlc1tpXTsKKwkJ
aWYgKCFjeC0+dmFsaWQpCisJCQljb250aW51ZTsKKworCQl4ZW5fY3ggPSAmKHhlbl9jeF9zdGF0
ZXNbb2srK10pOworCisJCXhlbl9jeC0+cmVnLnNwYWNlX2lkID0gQUNQSV9BRFJfU1BBQ0VfU1lT
VEVNX0lPOworCQlpZiAoY3gtPmVudHJ5X21ldGhvZCA9PSBBQ1BJX0NTVEFURV9TWVNURU1JTykg
eworCQkJeGVuX2N4LT5yZWcuYml0X3dpZHRoID0gODsKKwkJCXhlbl9jeC0+cmVnLmJpdF9vZmZz
ZXQgPSAwOworCQkJeGVuX2N4LT5yZWcuYWNjZXNzX3NpemUgPSAxOworCQl9IGVsc2UgeworCQkJ
eGVuX2N4LT5yZWcuc3BhY2VfaWQgPSBBQ1BJX0FEUl9TUEFDRV9GSVhFRF9IQVJEV0FSRTsKKwkJ
CWlmIChjeC0+ZW50cnlfbWV0aG9kID09IEFDUElfQ1NUQVRFX0ZGSCkgeworCQkJCS8qIE5BVElW
RV9DU1RBVEVfQkVZT05EX0hBTFQgKi8KKwkJCQl4ZW5fY3gtPnJlZy5iaXRfb2Zmc2V0ID0gMjsK
KwkJCQl4ZW5fY3gtPnJlZy5iaXRfd2lkdGggPSAxOyAvKiBWRU5ET1JfSU5URUwgKi8KKwkJCX0K
KwkJCXhlbl9jeC0+cmVnLmFjY2Vzc19zaXplID0gMDsKKwkJfQorCQl4ZW5fY3gtPnJlZy5hZGRy
ZXNzID0gY3gtPmFkZHJlc3M7CisKKwkJeGVuX2N4LT50eXBlID0gY3gtPnR5cGU7CisJCXhlbl9j
eC0+bGF0ZW5jeSA9IGN4LT5sYXRlbmN5OworCQl4ZW5fY3gtPnBvd2VyID0gY3gtPnBvd2VyOwor
CisJCXhlbl9jeC0+ZHBjbnQgPSAwOworCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fY3gtPmRw
LCBOVUxMKTsKKyNpZmRlZiBERUJVRworCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiBDWDogSUQ6JWQg
W0MlZDolc10gZW50cnk6JWRcbiIsIF9wci0+YWNwaV9pZCwKKwkJCSBjeC0+dHlwZSwgY3gtPmRl
c2MsIGN4LT5lbnRyeV9tZXRob2QpOworI2VuZGlmCisJfQorCWlmICghb2spIHsKKwkJcHJfZXJy
KERSVl9OQU1FICI6IE5vIGF2YWlsYWJsZSBDeCBpbmZvIGZvciBjcHUgJWRcbiIsIF9wci0+YWNw
aV9pZCk7CisJCWtmcmVlKHhlbl9jeF9zdGF0ZXMpOworCQlyZXR1cm4gLUVJTlZBTDsKKwl9CisJ
b3AudS5zZXRfcG1pbmZvLnBvd2VyLmNvdW50ID0gb2s7CisJb3AudS5zZXRfcG1pbmZvLnBvd2Vy
LmZsYWdzLmJtX2NvbnRyb2wgPSBfcHItPmZsYWdzLmJtX2NvbnRyb2w7CisJb3AudS5zZXRfcG1p
bmZvLnBvd2VyLmZsYWdzLmJtX2NoZWNrID0gX3ByLT5mbGFncy5ibV9jaGVjazsKKwlvcC51LnNl
dF9wbWluZm8ucG93ZXIuZmxhZ3MuaGFzX2NzdCA9IF9wci0+ZmxhZ3MuaGFzX2NzdDsKKwlvcC51
LnNldF9wbWluZm8ucG93ZXIuZmxhZ3MucG93ZXJfc2V0dXBfZG9uZSA9CisJCV9wci0+ZmxhZ3Mu
cG93ZXJfc2V0dXBfZG9uZTsKKworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG9wLnUuc2V0X3BtaW5m
by5wb3dlci5zdGF0ZXMsIHhlbl9jeF9zdGF0ZXMpOworCisJaWYgKCFub19oeXBlcmNhbGwgJiYg
eGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwor
CisJaWYgKHJldCkgeworCQlwcl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNlbmQgdG8gaHlw
ZXJ2aXNvciAocmM6JWQpXG4iLCByZXQpOworCQlwcmludF9oZXhfZHVtcF9ieXRlcygiT1A6ICIs
IERVTVBfUFJFRklYX05PTkUsICZvcCwKKwkJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3BsYXRm
b3JtX29wKSk7CisJCXByaW50X2hleF9kdW1wX2J5dGVzKCJDeDogIiwgRFVNUF9QUkVGSVhfTk9O
RSwgeGVuX2N4X3N0YXRlcywKKwkJCQkgICAgIF9wci0+cG93ZXIuY291bnQgKgorCQkJCSAgICAg
c2l6ZW9mKHN0cnVjdCB4ZW5fcHJvY2Vzc29yX2N4KSk7CisJfQorCWtmcmVlKHhlbl9jeF9zdGF0
ZXMpOworCisJcmV0dXJuIHJldDsKK30KKworCisKK3N0YXRpYyBzdHJ1Y3QgeGVuX3Byb2Nlc3Nv
cl9weCAqeGVuX2NvcHlfcHNzX2RhdGEoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIsCisJCQkJ
CQkgIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZikKK3sKKwlzdHJ1
Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX3N0YXRlcyA9IE5VTEw7CisJaW50IGk7CisKKwl4ZW5f
c3RhdGVzID0ga2NhbGxvYyhfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCwKKwkJCSAgICAg
c2l6ZW9mKHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3B4KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCF4ZW5f
c3RhdGVzKQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKworCXhlbl9wZXJmLT5zdGF0ZV9j
b3VudCA9IF9wci0+cGVyZm9ybWFuY2UtPnN0YXRlX2NvdW50OworCisJQlVJTERfQlVHX09OKHNp
emVvZihzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCkgIT0KKwkJICAgICBzaXplb2Yoc3RydWN0IGFj
cGlfcHJvY2Vzc29yX3B4KSk7CisJZm9yIChpID0gMDsgaSA8IF9wci0+cGVyZm9ybWFuY2UtPnN0
YXRlX2NvdW50OyBpKyspIHsKKworCQkvKiBGb3J0dW5hdGx5IGZvciB1cywgdGhleSBib3RoIGhh
dmUgdGhlIHNhbWUgc2l6ZSAqLworCQltZW1jcHkoJih4ZW5fc3RhdGVzW2ldKSwgJihfcHItPnBl
cmZvcm1hbmNlLT5zdGF0ZXNbaV0pLAorCQkgICAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nl
c3Nvcl9weCkpOworCX0KKwlyZXR1cm4geGVuX3N0YXRlczsKK30KK3N0YXRpYyBpbnQgeGVuX2Nv
cHlfcHNkX2RhdGEoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIsCisJCQkgICAgIHN0cnVjdCB4
ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICp4ZW5fcGVyZikKK3sKKwlCVUlMRF9CVUdfT04oc2l6
ZW9mKHN0cnVjdCB4ZW5fcHNkX3BhY2thZ2UpICE9CisJCSAgICAgc2l6ZW9mKHN0cnVjdCBhY3Bp
X3BzZF9wYWNrYWdlKSk7CisKKwlpZiAoX3ByLT5wZXJmb3JtYW5jZS0+c2hhcmVkX3R5cGUgIT0g
Q1BVRlJFUV9TSEFSRURfVFlQRV9OT05FKSB7CisJCXhlbl9wZXJmLT5zaGFyZWRfdHlwZSA9IF9w
ci0+cGVyZm9ybWFuY2UtPnNoYXJlZF90eXBlOworCisJCW1lbWNweSgmKHhlbl9wZXJmLT5kb21h
aW5faW5mbyksICYoX3ByLT5wZXJmb3JtYW5jZS0+ZG9tYWluX2luZm8pLAorCQkgICAgICAgc2l6
ZW9mKHN0cnVjdCBhY3BpX3BzZF9wYWNrYWdlKSk7CisJfSBlbHNlIHsKKwkJaWYgKCgmY3B1X2Rh
dGEoMCkpLT54ODZfdmVuZG9yICE9IFg4Nl9WRU5ET1JfQU1EKQorCQkJcmV0dXJuIC1FSU5WQUw7
CisKKwkJLyogT24gQU1ELCB0aGUgcG93ZXJub3ctazggaXMgbG9hZGVkIGJlZm9yZSBhY3BpX2Nw
dWZyZXEKKwkJICogbWVhbmluZyB0aGF0IGFjcGlfcHJvY2Vzc29yX3ByZXJlZ2lzdGVyX3BlcmZv
cm1hbmNlIG5ldmVyCisJCSAqIGdldHMgY2FsbGVkIHdoaWNoIHdvdWxkIHBhcnNlIHRoZSBfQ1NU
LgorCQkgKi8KKwkJeGVuX3BlcmYtPnNoYXJlZF90eXBlID0gQ1BVRlJFUV9TSEFSRURfVFlQRV9B
TEw7CisJCXhlbl9wZXJmLT5kb21haW5faW5mby5udW1fcHJvY2Vzc29ycyA9IG51bV9vbmxpbmVf
Y3B1cygpOworCX0KKwlyZXR1cm4gMDsKK30KK3N0YXRpYyBpbnQgeGVuX2NvcHlfcGN0X2RhdGEo
c3RydWN0IGFjcGlfcGN0X3JlZ2lzdGVyICpwY3QsCisJCQkgICAgIHN0cnVjdCB4ZW5fcGN0X3Jl
Z2lzdGVyICpfcGN0KQoreworCS8qIEl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGp1c3Qg
ZG8gJ21lbWNweShwY3QsIF9wY3QnKSBidXQKKwkgKiBzYWRseSB0aGUgWGVuIHN0cnVjdHVyZSBk
aWQgbm90IGhhdmUgdGhlIHByb3BlciBwYWRkaW5nCisJICogc28gdGhlIGRlc2NyaXB0b3IgZmll
bGQgdGFrZXMgdHdvIChfcGN0KSBieXRlcyBpbnN0ZWFkIG9mIG9uZSAocGN0KS4KKwkgKi8KKwlf
cGN0LT5kZXNjcmlwdG9yID0gcGN0LT5kZXNjcmlwdG9yOworCV9wY3QtPmxlbmd0aCA9IHBjdC0+
bGVuZ3RoOworCV9wY3QtPnNwYWNlX2lkID0gcGN0LT5zcGFjZV9pZDsKKwlfcGN0LT5iaXRfd2lk
dGggPSBwY3QtPmJpdF93aWR0aDsKKwlfcGN0LT5iaXRfb2Zmc2V0ID0gcGN0LT5iaXRfb2Zmc2V0
OworCV9wY3QtPnJlc2VydmVkID0gcGN0LT5yZXNlcnZlZDsKKwlfcGN0LT5hZGRyZXNzID0gcGN0
LT5hZGRyZXNzOworCXJldHVybiAwOworfQorc3RhdGljIGludCB4ZW5fcHVzaF9weHhfdG9faHlw
ZXJ2aXNvcihzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wcikKK3sKKwlpbnQgcmV0ID0gMDsKKwlz
dHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kCQkJPSBYRU5QRl9zZXRfcHJvY2Vz
c29yX3BtaW5mbywKKwkJLmludGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJ
T04sCisJCS51LnNldF9wbWluZm8uaWQJPSBfcHItPmFjcGlfaWQsCisJCS51LnNldF9wbWluZm8u
dHlwZQk9IFhFTl9QTV9QWCwKKwl9OworCXN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNl
ICp4ZW5fcGVyZjsKKwlzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCAqeGVuX3N0YXRlcyA9IE5VTEw7
CisKKwl4ZW5fcGVyZiA9ICZvcC51LnNldF9wbWluZm8ucGVyZjsKKworCXhlbl9wZXJmLT5wbGF0
Zm9ybV9saW1pdCA9IF9wci0+cGVyZm9ybWFuY2VfcGxhdGZvcm1fbGltaXQ7CisJeGVuX3BlcmYt
PmZsYWdzIHw9IFhFTl9QWF9QUEM7CisJeGVuX2NvcHlfcGN0X2RhdGEoJihfcHItPnBlcmZvcm1h
bmNlLT5jb250cm9sX3JlZ2lzdGVyKSwKKwkJCSAgJnhlbl9wZXJmLT5jb250cm9sX3JlZ2lzdGVy
KTsKKwl4ZW5fY29weV9wY3RfZGF0YSgmKF9wci0+cGVyZm9ybWFuY2UtPnN0YXR1c19yZWdpc3Rl
ciksCisJCQkgICZ4ZW5fcGVyZi0+c3RhdHVzX3JlZ2lzdGVyKTsKKwl4ZW5fcGVyZi0+ZmxhZ3Mg
fD0gWEVOX1BYX1BDVDsKKwl4ZW5fc3RhdGVzID0geGVuX2NvcHlfcHNzX2RhdGEoX3ByLCB4ZW5f
cGVyZik7CisJaWYgKCFJU19FUlJfT1JfTlVMTCh4ZW5fc3RhdGVzKSkgeworCQlzZXRfeGVuX2d1
ZXN0X2hhbmRsZSh4ZW5fcGVyZi0+c3RhdGVzLCB4ZW5fc3RhdGVzKTsKKwkJeGVuX3BlcmYtPmZs
YWdzIHw9IFhFTl9QWF9QU1M7CisJfQorCWlmICgheGVuX2NvcHlfcHNkX2RhdGEoX3ByLCB4ZW5f
cGVyZikpCisJCXhlbl9wZXJmLT5mbGFncyB8PSBYRU5fUFhfUFNEOworCisJaWYgKCFub19oeXBl
cmNhbGwgJiYgeGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldCA9IEhZUEVSVklTT1JfZG9tMF9v
cCgmb3ApOworCisJaWYgKHJldCkgeworCQlwcl9lcnIoRFJWX05BTUUgIjogRmFpbGVkIHRvIHNl
bmQgdG8gaHlwZXJ2aXNvciAocmM6JWQpXG4iLCByZXQpOworCQlwcmludF9oZXhfZHVtcF9ieXRl
cygiT1A6ICIsIERVTVBfUFJFRklYX05PTkUsICZvcCwKKwkJCQkgICAgIHNpemVvZihzdHJ1Y3Qg
eGVuX3BsYXRmb3JtX29wKSk7CisJCWlmICghSVNfRVJSX09SX05VTEwoeGVuX3N0YXRlcykpCisJ
CQlwcmludF9oZXhfZHVtcF9ieXRlcygiUHh4OiIsIERVTVBfUFJFRklYX05PTkUsIHhlbl9zdGF0
ZXMsCisJCQkJICAgICBfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudCAqCisJCQkJICAgICBz
aXplb2Yoc3RydWN0IHhlbl9wcm9jZXNzb3JfcHgpKTsKKwl9CisJaWYgKCFJU19FUlJfT1JfTlVM
TCh4ZW5fc3RhdGVzKSkKKwkJa2ZyZWUoeGVuX3N0YXRlcyk7CisKKwlyZXR1cm4gcmV0OworfQor
LyoKKyAqIFdlIHJlYWQgb3V0IHRoZSBzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IsIGFuZCBzZXJpYWxp
emUgYWNjZXNzCisgKiBzbyB0aGF0IHRoZXJlIGlzIG9ubHkgb25lIGNhbGxlci4gVGhpcyBpcyBz
byB0aGF0IHdlIHdvbid0CisgKiByYWNlIHdpdGggdGhlIENQVSBob3RwbHVnIGNvZGUuCisgKi8K
K3N0YXRpYyBpbnQgeGVuX3Byb2Nlc3NfZGF0YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wciwg
aW50IGNwdSkKK3sKKwlpbnQgZXJyID0gMDsKKworCW11dGV4X2xvY2soJnByb2Nlc3NvcnNfZG9u
ZV9tdXRleCk7CisJaWYgKGNwdW1hc2tfdGVzdF9jcHUoY3B1LCB0b19jcHVtYXNrKHByb2Nlc3Nv
cnNfZG9uZSkpKSB7CisJCW11dGV4X3VubG9jaygmcHJvY2Vzc29yc19kb25lX211dGV4KTsKKwkJ
cmV0dXJuIC1FQlVTWTsKKwl9CisJaWYgKF9wci0+ZmxhZ3MucG93ZXIpCisJCWVyciA9IHhlbl9w
dXNoX2N4eF90b19oeXBlcnZpc29yKF9wcik7CisKKwlpZiAoX3ByLT5wZXJmb3JtYW5jZSAmJiBf
cHItPnBlcmZvcm1hbmNlLT5zdGF0ZXMpCisJCWVyciB8PSB4ZW5fcHVzaF9weHhfdG9faHlwZXJ2
aXNvcihfcHIpOworCisJY3B1bWFza19zZXRfY3B1KGNwdSwgdG9fY3B1bWFzayhwcm9jZXNzb3Jz
X2RvbmUpKTsKKwltdXRleF91bmxvY2soJnByb2Nlc3NvcnNfZG9uZV9tdXRleCk7CisJcmV0dXJu
IGVycjsKK30KKworc3RhdGljIGludCB4ZW5fcHJvY2Vzc29yX2NoZWNrKHZvaWQpCit7CisJc3Ry
dWN0IGNwdWZyZXFfcG9saWN5ICpwb2xpY3k7CisJaW50IGNwdTsKKworCXBvbGljeSA9IGNwdWZy
ZXFfY3B1X2dldChzbXBfcHJvY2Vzc29yX2lkKCkpOworCWlmICghcG9saWN5KQorCQlyZXR1cm4g
LUVCVVNZOworCisJZ2V0X29ubGluZV9jcHVzKCk7CisJZm9yX2VhY2hfb25saW5lX2NwdShjcHUp
IHsKKwkJc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHI7CisKKwkJX3ByID0gcGVyX2NwdShwcm9j
ZXNzb3JzLCBjcHUpOworCQlpZiAoIV9wcikKKwkJCWNvbnRpbnVlOworCisJCSh2b2lkKXhlbl9w
cm9jZXNzX2RhdGEoX3ByLCBjcHUpOworCX0KKwlwdXRfb25saW5lX2NwdXMoKTsKKworCWNwdWZy
ZXFfY3B1X3B1dChwb2xpY3kpOworCXJldHVybiAwOworfQorLyoKKyAqIFRoZSBwdXJwb3NlIG9m
IHRoaXMgdGltZXIvdGhyZWFkIGlzIHRvIHdhaXQgZm9yIHRoZSBBQ1BJIHByb2Nlc3NvcgorICog
YW5kIENQVWZyZXEgZHJpdmVycyB0byBsb2FkIHVwIGFuZCBwYXJzZSB0aGUgUHh4IGFuZCBDeHgg
aW5mb3JtYXRpb24KKyAqIGJlZm9yZSB3ZSBhdHRlbXB0IHRvIHJlYWQgaXQuCisgKi8KK3N0YXRp
YyB2b2lkIHhlbl9wcm9jZXNzb3JfdGltZW91dCh1bnNpZ25lZCBsb25nIGFyZykKK3sKKwl3YWtl
X3VwX3Byb2Nlc3MoKHN0cnVjdCB0YXNrX3N0cnVjdCAqKWFyZyk7Cit9CitzdGF0aWMgaW50IHhl
bl9wcm9jZXNzb3JfdGhyZWFkX2Z1bmModm9pZCAqZHVtbXkpCit7CisJc3RydWN0IHRpbWVyX2xp
c3QgdGltZXI7CisKKwlzZXR1cF9kZWZlcnJhYmxlX3RpbWVyX29uX3N0YWNrKCZ0aW1lciwgeGVu
X3Byb2Nlc3Nvcl90aW1lb3V0LAorCQkJCQkodW5zaWduZWQgbG9uZyljdXJyZW50KTsKKworCWRv
IHsKKwkJX19zZXRfY3VycmVudF9zdGF0ZShUQVNLX0lOVEVSUlVQVElCTEUpOworCQltb2RfdGlt
ZXIoJnRpbWVyLCBqaWZmaWVzICsgUE9MTF9USU1FUik7CisJCXNjaGVkdWxlKCk7CisJCWlmICh4
ZW5fcHJvY2Vzc29yX2NoZWNrKCkgIT0gLUVCVVNZKQorCQkJYnJlYWs7CisJfSB3aGlsZSAoIWt0
aHJlYWRfc2hvdWxkX3N0b3AoKSk7CisKKwlkZWxfdGltZXJfc3luYygmdGltZXIpOworCWRlc3Ry
b3lfdGltZXJfb25fc3RhY2soJnRpbWVyKTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCB4
ZW5fY3B1X3NvZnRfbm90aWZ5KHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmZiLAorCQkJICAgICAg
IHVuc2lnbmVkIGxvbmcgYWN0aW9uLCB2b2lkICpoY3B1KQoreworCXVuc2lnbmVkIGludCBjcHUg
PSAodW5zaWduZWQgbG9uZyloY3B1OworCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3ByID0gcGVy
X2NwdShwcm9jZXNzb3JzLCBjcHUpOworCisJaWYgKGFjdGlvbiA9PSBDUFVfT05MSU5FICYmIF9w
cikKKwkJKHZvaWQpeGVuX3Byb2Nlc3NfZGF0YShfcHIsIGNwdSk7CisKKwlyZXR1cm4gTk9USUZZ
X09LOworfQorCitzdGF0aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2NrIHhlbl9jcHVfbm90aWZpZXIg
PSB7CisJLm5vdGlmaWVyX2NhbGwgPSB4ZW5fY3B1X3NvZnRfbm90aWZ5LAorCS5wcmlvcml0eSA9
IC0xLCAvKiBCZSB0aGUgbGFzdCBvbmUgKi8KK307CisKK3N0YXRpYyBpbnQgX19pbml0IGNoZWNr
X3ByZXJlcSh2b2lkKQoreworCXN0cnVjdCBjcHVpbmZvX3g4NiAqYyA9ICZjcHVfZGF0YSgwKTsK
KworCWlmICgheGVuX2luaXRpYWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVWOworCisJaWYg
KCFhY3BpX2dibF9GQURULnNtaV9jb21tYW5kKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCWlmIChj
LT54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwpIHsKKwkJaWYgKCFjcHVfaGFzKGMsIFg4
Nl9GRUFUVVJFX0VTVCkpCisJCQlyZXR1cm4gLUVOT0RFVjsKKworCQlyZXR1cm4gMDsKKwl9CisJ
aWYgKGMtPng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9BTUQpIHsKKwkJdTMyIGhpID0gMCwgbG8g
PSAwOworCQkvKiBDb3BpZWQgZnJvbSBwb3dlcm5vdy1rOC5oLCBjYW4ndCBpbmNsdWRlIC4uL2Nw
dWZyZXEvcG93ZXJub3cKKwkJICogYXMgd2UgZ2V0IGNvbXBpbGUgd2FybmluZ3MgZm9yIHRoZSBz
dGF0aWMgZnVuY3Rpb25zLgorCQkgKi8KKyNkZWZpbmUgTVNSX1BTVEFURV9DVVJfTElNSVQgICAg
MHhjMDAxMDA2MSAvKiBwc3RhdGUgY3VycmVudCBsaW1pdCBNU1IgKi8KKwkJcmRtc3IoTVNSX1BT
VEFURV9DVVJfTElNSVQsIGxvLCBoaSk7CisKKwkJLyogSWYgdGhlIE1TUiBjYW5ub3QgcHJvdmlk
ZSB0aGUgZGF0YSwgdGhlIHBvd2Vybm93LWs4CisJCSAqIHdvbid0IHByb2Nlc3MgdGhlIGRhdGEg
cHJvcGVybHkgZWl0aGVyLgorCQkgKi8KKwkJaWYgKGhpIHx8IGxvKQorCQkJcmV0dXJuIDA7CisJ
fQorCXJldHVybiAtRU5PREVWOworfQorCitzdGF0aWMgaW50IF9faW5pdCB4ZW5fcHJvY2Vzc29y
X3Bhc3N0aHJ1X2luaXQodm9pZCkKK3sKKwlpbnQgcmMgPSBjaGVja19wcmVyZXEoKTsKKworCWlm
IChyYykKKwkJcmV0dXJuIHJjOworCisJeGVuX3Byb2Nlc3Nvcl90aHJlYWQgPSBrdGhyZWFkX3J1
bih4ZW5fcHJvY2Vzc29yX3RocmVhZF9mdW5jLCBOVUxMLCBEUlZfTkFNRSk7CisJaWYgKElTX0VS
Uih4ZW5fcHJvY2Vzc29yX3RocmVhZCkpIHsKKwkJcHJfZXJyKERSVl9OQU1FICI6IEZhaWxlZCB0
byBjcmVhdGUgdGhyZWFkLiBBYm9ydGluZy5cbiIpOworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisJ
cmVnaXN0ZXJfaG90Y3B1X25vdGlmaWVyKCZ4ZW5fY3B1X25vdGlmaWVyKTsKKwlyZXR1cm4gMDsK
K30KK3N0YXRpYyB2b2lkIF9fZXhpdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJ1X2V4aXQodm9pZCkK
K3sKKwl1bnJlZ2lzdGVyX2hvdGNwdV9ub3RpZmllcigmeGVuX2NwdV9ub3RpZmllcik7CisJaWYg
KHhlbl9wcm9jZXNzb3JfdGhyZWFkKQorCQlrdGhyZWFkX3N0b3AoeGVuX3Byb2Nlc3Nvcl90aHJl
YWQpOworfQorbGF0ZV9pbml0Y2FsbCh4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJ1X2luaXQpOworbW9k
dWxlX2V4aXQoeGVuX3Byb2Nlc3Nvcl9wYXNzdGhydV9leGl0KTsKLS0gCjEuNy43LjUKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00: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 1RzdKS-00055C-DX; Tue, 21 Feb 2012 00:11:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdKQ-00054a-JV
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329783086!14008744!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5865 invoked from network); 21 Feb 2012 00:11:28 -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; 21 Feb 2012 00:11:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1L0BFqX023526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11: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
	q1L0BENd008634
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:15 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
	q1L0BDEj001666; Mon, 20 Feb 2012 18:11:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3719E40469; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:45 -0500
Message-Id: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <20120214183006.GJ12984@reaktio.net>
References: <20120214183006.GJ12984@reaktio.net>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F42E124.0072,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [RFC] follow-on patches to acpi processor and cpufreq
	harvester^H^H^Hpassthru (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>
MIME-Version: 1.0
Content-Type: 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 decided that passthru sounded much better so:
 [PATCH 1/3] xen/processor-passthru: Change the name to passthru

does the move to the new name, and then the next one implements the dom0_max_vcpu
support:
 [PATCH 2/3] xen/processor-passthru: Support vCPU != pCPU - aka

by enumerating the ACPI processor values directly and re-using the 'struct acpi_processor'
for the rest (the ones not enumerated by ACPI layer). I chatted with the Intel folks and
they said that it is safe to assume that the _PXX and _CXX values are the same across
all the CPUs. Not entirely sure about AMD so I need to chat with them.

The last one is just an fixup to make it easier to read:
 [PATCH 3/3] xen/processor-passthru: Remove the print_hex_dump - as


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00: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 1RzdKS-00055C-DX; Tue, 21 Feb 2012 00:11:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdKQ-00054a-JV
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:11:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329783086!14008744!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5865 invoked from network); 21 Feb 2012 00:11:28 -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; 21 Feb 2012 00:11:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1L0BFqX023526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:11: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
	q1L0BENd008634
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:11:15 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
	q1L0BDEj001666; Mon, 20 Feb 2012 18:11:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:11:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3719E40469; Mon, 20 Feb 2012 19:08:01 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: pasik@iki.fi
Date: Mon, 20 Feb 2012 19:07:45 -0500
Message-Id: <1329782868-1696-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <20120214183006.GJ12984@reaktio.net>
References: <20120214183006.GJ12984@reaktio.net>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F42E124.0072,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, ke.yu@intel.com
Subject: [Xen-devel] [RFC] follow-on patches to acpi processor and cpufreq
	harvester^H^H^Hpassthru (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>
MIME-Version: 1.0
Content-Type: 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 decided that passthru sounded much better so:
 [PATCH 1/3] xen/processor-passthru: Change the name to passthru

does the move to the new name, and then the next one implements the dom0_max_vcpu
support:
 [PATCH 2/3] xen/processor-passthru: Support vCPU != pCPU - aka

by enumerating the ACPI processor values directly and re-using the 'struct acpi_processor'
for the rest (the ones not enumerated by ACPI layer). I chatted with the Intel folks and
they said that it is safe to assume that the _PXX and _CXX values are the same across
all the CPUs. Not entirely sure about AMD so I need to chat with them.

The last one is just an fixup to make it easier to read:
 [PATCH 3/3] xen/processor-passthru: Remove the print_hex_dump - as


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:13:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdMH-0005Qq-OG; Tue, 21 Feb 2012 00:13:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdMG-0005QZ-0u
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:13:28 +0000
Received: from [85.158.139.83:35497] by server-4.bemta-5.messagelabs.com id
	64/9F-10788-7A1E24F4; Tue, 21 Feb 2012 00:13:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329783205!8453119!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4258 invoked from network); 21 Feb 2012 00:13:26 -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; 21 Feb 2012 00:13:26 -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 q1L0DMGw016628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:13:23 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
	q1L0DMUI006375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:13:22 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
	q1L0DL5R029930; Mon, 20 Feb 2012 18:13:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:13:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ECF7640469; Mon, 20 Feb 2012 19:10:08 -0500 (EST)
Date: Mon, 20 Feb 2012 19:10:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Message-ID: <20120221001008.GA1848@phenom.dumpdata.com>
References: <CAHyyzzQ7ZAhnvWn8_Ui2jd9BFYSAvNX=V+tpbpZzVGLcT9c3Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHyyzzQ7ZAhnvWn8_Ui2jd9BFYSAvNX=V+tpbpZzVGLcT9c3Xw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F42E1A3.00A6,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen kernel crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 04:46:50PM -0700, jacek burghardt wrote:
> I had created package for arch linux xen 4.2 unstable and 3.3.0-rc1 linus
> fixes kernel. So if I issue xl destroy domu my kernel crashes. Is there any
> patch that can stop those crashes.

You need to give more details. Please look at
http://wiki.xensource.com/xenwiki/XenParavirtOpsHelp.html

>  7742.769113] xen-pciback[0000:02:00.0] IRQ line is not shared with other
> domains. Turning ISR off
> [ 7748.502978] irq 32: nobody cared (try booting with the "irqpoll" option)
> [ 7748.503025] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
> [ 7748.503059] Call Trace:
> [ 7748.503080]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
> [ 7748.503130]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
> [ 7748.503165]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
> [ 7748.503202]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
> [ 7748.503235]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
> [ 7748.503268]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
> [ 7748.503302]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
> [ 7748.503339]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
> [ 7748.503374]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 7748.503409]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.503453]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.503487]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
> [ 7748.503519]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
> [ 7748.503552]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
> [ 7748.503584]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
> [ 7748.503615]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
> [ 7748.503648]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
> [ 7748.503684]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
> [ 7748.503717] handlers:
> [ 7748.503737] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
> [ 7748.503773] Disabling IRQ #32
> [ 7748.652402] irq 16: nobody cared (try booting with the "irqpoll" option)
> [ 7748.652445] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
> [ 7748.652479] Call Trace:
> [ 7748.652499]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
> [ 7748.652545]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
> [ 7748.652579]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
> [ 7748.652616]  [<ffffffff8103eae5>] ? pvclock_clocksource_read+0x55/0xf0
> [ 7748.652652]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
> [ 7748.652684]  [<ffffffff8100b8e0>] ? xen_clocksource_read+0x40/0x70
> [ 7748.652719]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
> [ 7748.652754]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
> [ 7748.652791]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
> [ 7748.652826]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 7748.652861]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.652903]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.652937]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
> [ 7748.652969]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
> [ 7748.653002]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
> [ 7748.653034]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
> [ 7748.653065]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
> [ 7748.653098]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
> [ 7748.653135]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
> [ 7748.653167] handlers:
> [ 7748.653194] [<ffffffffa01d7100>] azx_interrupt
> [ 7748.653226] Disabling IRQ #16
> [ 7752.782419] vif vif-6-0: 2 reading script
> [ 7752.784350] xenbr0: port 3(vif6.0) entering forwarding state
> [ 7752.784611] xenbr0: port 3(vif6.0) entering disabled state
> [ 7790.687530] xen-pciback: vpci: 0000:02:00.0: assign to virtual slot 0
> [ 7790.817247] device vif7.0 entered promiscuous mode
> [ 7790.819947] ADDRCONF(NETDEV_UP): vif7.0: link is not ready
> [ 7791.198278] xen-blkback:ring-ref 8, event-channel 8, protocol 1
> (x86_64-abi)
> [ 7791.234632] ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready
> [ 7791.234712] xenbr0: port 3(vif7.0) entering forwarding state
> [ 7791.234747] xenbr0: port 3(vif7.0) entering forwarding state
> [ 7795.090689] pciback 0000:02:00.0: enabling device (0000 -> 0002)
> [ 7795.090756] xen: registering gsi 32 triggering 0 polarity 1
> [ 7795.090769] xen_map_pirq_gsi: returning irq 32 for gsi 32
> [ 7795.090807] xen: --> pirq=32 -> irq=32 (gsi=32)
> [ 7795.090811] Already setup the GSI :32
> [ 7796.165112] irq 32: nobody cared (try booting with the "irqpoll" option)
> [ 7796.165159] Pid: 1863, comm: kworker/0:1 Not tainted 3.3.0-rc1-xen #1
> [ 7796.165201] Call Trace:
> [ 7796.165229]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
> [ 7796.165292]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
> [ 7796.165335]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
> [ 7796.165383]  [<ffffffff810749bc>] ? run_posix_cpu_timers+0x2c/0x7b0
> [ 7796.165427]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
> [ 7796.165469]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
> [ 7796.165514]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
> [ 7796.165563]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
> [ 7796.165607]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
> [ 7796.165650]  [<ffffffff810766a7>] ? hrtimer_interrupt+0x127/0x200
> [ 7796.165695]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 7796.165741]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [ 7796.165782]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [ 7796.165825]  [<ffffffff8100b5ad>] ? xen_force_evtchn_callback+0xd/0x10
> [ 7796.165870]  [<ffffffff8100be12>] ? check_events+0x12/0x20
> [ 7796.165893]  [<ffffffff8100bdb9>] ? xen_irq_enable_direct_reloc+0x4/0x4
> [ 7796.165893]  [<ffffffff81056dab>] ? __do_softirq+0x7b/0x280
> [ 7796.165893]  [<ffffffff8100b903>] ? xen_clocksource_read+0x63/0x70
> [ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
> [ 7796.165893]  [<ffffffff814496dc>] ? call_softirq+0x1c/0x30
> [ 7796.165893]  [<ffffffff81017755>] ? do_softirq+0x65/0xa0
> [ 7796.165893]  [<ffffffff810572f6>] ? irq_exit+0xa6/0xc0
> [ 7796.165893]  [<ffffffff812c72f5>] ? xen_evtchn_do_upcall+0x35/0x50
> [ 7796.165893]  [<ffffffff8144972e>] ? xen_do_hypervisor_callback+0x1e/0x30
> [ 7796.165893]  <EOI>  [<ffffffff81247f6b>] ? find_next_zero_bit+0x4b/0xe0
> [ 7796.165893]  [<ffffffff81238f90>] ? ida_get_new_above+0x70/0x2f0
> [ 7796.165893]  [<ffffffff81239722>] ? idr_pre_get+0x52/0x90
> [ 7796.165893]  [<ffffffff8123921e>] ? ida_get_new+0xe/0x10
> [ 7796.165893]  [<ffffffff811cecc5>] ? proc_register+0x55/0x200
> [ 7796.165893]  [<ffffffff811cf36f>] ? proc_mkdir_mode+0x3f/0x60
> [ 7796.165893]  [<ffffffff811cf3a6>] ? proc_mkdir+0x16/0x20
> [ 7796.165893]  [<ffffffff810d14eb>] ? register_handler_proc+0x11b/0x140
> [ 7796.165893]  [<ffffffff810ce391>] ? __setup_irq+0x431/0x550
> [ 7796.165893]  [<ffffffff8115522b>] ? kmem_cache_alloc_trace+0x12b/0x150
> [ 7796.165893]  [<ffffffff812d4940>] ? xen_pcibk_control_isr+0x120/0x120
> [ 7796.165893]  [<ffffffff810ce59a>] ? request_threaded_irq+0xea/0x1a0
> [ 7796.165893]  [<ffffffff812d4917>] ? xen_pcibk_control_isr+0xf7/0x120
> [ 7796.165893]  [<ffffffff812d4daa>] ? xen_pcibk_do_op+0x26a/0x590
> [ 7796.165893]  [<ffffffff812d4b40>] ?
> xen_pcibk_test_and_schedule_op+0x80/0x80
> [ 7796.165893]  [<ffffffff8106bdeb>] ? process_one_work+0x11b/0x4d0
> [ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
> [ 7796.165893]  [<ffffffff8106c784>] ? worker_thread+0x164/0x340
> [ 7796.165893]  [<ffffffff8100bdff>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [ 7796.165893]  [<ffffffff8106c620>] ? manage_workers.isra.25+0x220/0x220
> [ 7796.165893]  [<ffffffff810717e3>] ? kthread+0x93/0xa0
> [ 7796.165893]  [<ffffffff814495e4>] ? kernel_thread_helper+0x4/0x10
> [ 7796.165893]  [<ffffffff814478c0>] ? retint_restore_args+0x5/0x6
> [ 7796.165893]  [<ffffffff814495e0>] ? gs_change+0x13/0x13
> [ 7796.165893] handlers:
> [ 7796.165893] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
> [ 7796.165893] Disabling IRQ #32

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:13:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdMH-0005Qq-OG; Tue, 21 Feb 2012 00:13:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzdMG-0005QZ-0u
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:13:28 +0000
Received: from [85.158.139.83:35497] by server-4.bemta-5.messagelabs.com id
	64/9F-10788-7A1E24F4; Tue, 21 Feb 2012 00:13:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329783205!8453119!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTUzNDMy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4258 invoked from network); 21 Feb 2012 00:13:26 -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; 21 Feb 2012 00:13:26 -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 q1L0DMGw016628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 00:13:23 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
	q1L0DMUI006375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 00:13:22 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
	q1L0DL5R029930; Mon, 20 Feb 2012 18:13:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 16:13:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ECF7640469; Mon, 20 Feb 2012 19:10:08 -0500 (EST)
Date: Mon, 20 Feb 2012 19:10:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Message-ID: <20120221001008.GA1848@phenom.dumpdata.com>
References: <CAHyyzzQ7ZAhnvWn8_Ui2jd9BFYSAvNX=V+tpbpZzVGLcT9c3Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHyyzzQ7ZAhnvWn8_Ui2jd9BFYSAvNX=V+tpbpZzVGLcT9c3Xw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F42E1A3.00A6,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen kernel crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 04:46:50PM -0700, jacek burghardt wrote:
> I had created package for arch linux xen 4.2 unstable and 3.3.0-rc1 linus
> fixes kernel. So if I issue xl destroy domu my kernel crashes. Is there any
> patch that can stop those crashes.

You need to give more details. Please look at
http://wiki.xensource.com/xenwiki/XenParavirtOpsHelp.html

>  7742.769113] xen-pciback[0000:02:00.0] IRQ line is not shared with other
> domains. Turning ISR off
> [ 7748.502978] irq 32: nobody cared (try booting with the "irqpoll" option)
> [ 7748.503025] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
> [ 7748.503059] Call Trace:
> [ 7748.503080]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
> [ 7748.503130]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
> [ 7748.503165]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
> [ 7748.503202]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
> [ 7748.503235]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
> [ 7748.503268]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
> [ 7748.503302]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
> [ 7748.503339]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
> [ 7748.503374]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 7748.503409]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.503453]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.503487]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
> [ 7748.503519]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
> [ 7748.503552]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
> [ 7748.503584]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
> [ 7748.503615]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
> [ 7748.503648]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
> [ 7748.503684]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
> [ 7748.503717] handlers:
> [ 7748.503737] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
> [ 7748.503773] Disabling IRQ #32
> [ 7748.652402] irq 16: nobody cared (try booting with the "irqpoll" option)
> [ 7748.652445] Pid: 0, comm: swapper/0 Not tainted 3.3.0-rc1-xen #1
> [ 7748.652479] Call Trace:
> [ 7748.652499]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
> [ 7748.652545]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
> [ 7748.652579]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
> [ 7748.652616]  [<ffffffff8103eae5>] ? pvclock_clocksource_read+0x55/0xf0
> [ 7748.652652]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
> [ 7748.652684]  [<ffffffff8100b8e0>] ? xen_clocksource_read+0x40/0x70
> [ 7748.652719]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
> [ 7748.652754]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
> [ 7748.652791]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
> [ 7748.652826]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 7748.652861]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.652903]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [ 7748.652937]  [<ffffffff8100b4b0>] ? xen_safe_halt+0x10/0x20
> [ 7748.652969]  [<ffffffff8101e8d3>] ? default_idle+0x53/0x280
> [ 7748.653002]  [<ffffffff81014246>] ? cpu_idle+0xe6/0x120
> [ 7748.653034]  [<ffffffff81422072>] ? rest_init+0x96/0xa4
> [ 7748.653065]  [<ffffffff818f6c0e>] ? start_kernel+0x3cf/0x3dc
> [ 7748.653098]  [<ffffffff818f6346>] ? x86_64_start_reservations+0x131/0x135
> [ 7748.653135]  [<ffffffff818f8a3c>] ? xen_start_kernel+0x5e0/0x5e7
> [ 7748.653167] handlers:
> [ 7748.653194] [<ffffffffa01d7100>] azx_interrupt
> [ 7748.653226] Disabling IRQ #16
> [ 7752.782419] vif vif-6-0: 2 reading script
> [ 7752.784350] xenbr0: port 3(vif6.0) entering forwarding state
> [ 7752.784611] xenbr0: port 3(vif6.0) entering disabled state
> [ 7790.687530] xen-pciback: vpci: 0000:02:00.0: assign to virtual slot 0
> [ 7790.817247] device vif7.0 entered promiscuous mode
> [ 7790.819947] ADDRCONF(NETDEV_UP): vif7.0: link is not ready
> [ 7791.198278] xen-blkback:ring-ref 8, event-channel 8, protocol 1
> (x86_64-abi)
> [ 7791.234632] ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready
> [ 7791.234712] xenbr0: port 3(vif7.0) entering forwarding state
> [ 7791.234747] xenbr0: port 3(vif7.0) entering forwarding state
> [ 7795.090689] pciback 0000:02:00.0: enabling device (0000 -> 0002)
> [ 7795.090756] xen: registering gsi 32 triggering 0 polarity 1
> [ 7795.090769] xen_map_pirq_gsi: returning irq 32 for gsi 32
> [ 7795.090807] xen: --> pirq=32 -> irq=32 (gsi=32)
> [ 7795.090811] Already setup the GSI :32
> [ 7796.165112] irq 32: nobody cared (try booting with the "irqpoll" option)
> [ 7796.165159] Pid: 1863, comm: kworker/0:1 Not tainted 3.3.0-rc1-xen #1
> [ 7796.165201] Call Trace:
> [ 7796.165229]  <IRQ>  [<ffffffff810cedbd>] __report_bad_irq+0x3d/0xe0
> [ 7796.165292]  [<ffffffff810cf059>] note_interrupt+0x159/0x210
> [ 7796.165335]  [<ffffffff810cc8a8>] handle_irq_event_percpu+0xc8/0x280
> [ 7796.165383]  [<ffffffff810749bc>] ? run_posix_cpu_timers+0x2c/0x7b0
> [ 7796.165427]  [<ffffffff8123c98b>] ? radix_tree_lookup+0xb/0x10
> [ 7796.165469]  [<ffffffff810ccaa8>] handle_irq_event+0x48/0x70
> [ 7796.165514]  [<ffffffff810cfa2a>] handle_fasteoi_irq+0x5a/0xe0
> [ 7796.165563]  [<ffffffff812c5864>] __xen_evtchn_do_upcall+0x1a4/0x270
> [ 7796.165607]  [<ffffffff812c72ef>] xen_evtchn_do_upcall+0x2f/0x50
> [ 7796.165650]  [<ffffffff810766a7>] ? hrtimer_interrupt+0x127/0x200
> [ 7796.165695]  [<ffffffff8144972e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 7796.165741]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [ 7796.165782]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [ 7796.165825]  [<ffffffff8100b5ad>] ? xen_force_evtchn_callback+0xd/0x10
> [ 7796.165870]  [<ffffffff8100be12>] ? check_events+0x12/0x20
> [ 7796.165893]  [<ffffffff8100bdb9>] ? xen_irq_enable_direct_reloc+0x4/0x4
> [ 7796.165893]  [<ffffffff81056dab>] ? __do_softirq+0x7b/0x280
> [ 7796.165893]  [<ffffffff8100b903>] ? xen_clocksource_read+0x63/0x70
> [ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
> [ 7796.165893]  [<ffffffff814496dc>] ? call_softirq+0x1c/0x30
> [ 7796.165893]  [<ffffffff81017755>] ? do_softirq+0x65/0xa0
> [ 7796.165893]  [<ffffffff810572f6>] ? irq_exit+0xa6/0xc0
> [ 7796.165893]  [<ffffffff812c72f5>] ? xen_evtchn_do_upcall+0x35/0x50
> [ 7796.165893]  [<ffffffff8144972e>] ? xen_do_hypervisor_callback+0x1e/0x30
> [ 7796.165893]  <EOI>  [<ffffffff81247f6b>] ? find_next_zero_bit+0x4b/0xe0
> [ 7796.165893]  [<ffffffff81238f90>] ? ida_get_new_above+0x70/0x2f0
> [ 7796.165893]  [<ffffffff81239722>] ? idr_pre_get+0x52/0x90
> [ 7796.165893]  [<ffffffff8123921e>] ? ida_get_new+0xe/0x10
> [ 7796.165893]  [<ffffffff811cecc5>] ? proc_register+0x55/0x200
> [ 7796.165893]  [<ffffffff811cf36f>] ? proc_mkdir_mode+0x3f/0x60
> [ 7796.165893]  [<ffffffff811cf3a6>] ? proc_mkdir+0x16/0x20
> [ 7796.165893]  [<ffffffff810d14eb>] ? register_handler_proc+0x11b/0x140
> [ 7796.165893]  [<ffffffff810ce391>] ? __setup_irq+0x431/0x550
> [ 7796.165893]  [<ffffffff8115522b>] ? kmem_cache_alloc_trace+0x12b/0x150
> [ 7796.165893]  [<ffffffff812d4940>] ? xen_pcibk_control_isr+0x120/0x120
> [ 7796.165893]  [<ffffffff810ce59a>] ? request_threaded_irq+0xea/0x1a0
> [ 7796.165893]  [<ffffffff812d4917>] ? xen_pcibk_control_isr+0xf7/0x120
> [ 7796.165893]  [<ffffffff812d4daa>] ? xen_pcibk_do_op+0x26a/0x590
> [ 7796.165893]  [<ffffffff812d4b40>] ?
> xen_pcibk_test_and_schedule_op+0x80/0x80
> [ 7796.165893]  [<ffffffff8106bdeb>] ? process_one_work+0x11b/0x4d0
> [ 7796.165893]  [<ffffffff8100be12>] ? check_events+0x12/0x20
> [ 7796.165893]  [<ffffffff8106c784>] ? worker_thread+0x164/0x340
> [ 7796.165893]  [<ffffffff8100bdff>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [ 7796.165893]  [<ffffffff8106c620>] ? manage_workers.isra.25+0x220/0x220
> [ 7796.165893]  [<ffffffff810717e3>] ? kthread+0x93/0xa0
> [ 7796.165893]  [<ffffffff814495e4>] ? kernel_thread_helper+0x4/0x10
> [ 7796.165893]  [<ffffffff814478c0>] ? retint_restore_args+0x5/0x6
> [ 7796.165893]  [<ffffffff814495e0>] ? gs_change+0x13/0x13
> [ 7796.165893] handlers:
> [ 7796.165893] [<ffffffff812d4940>] xen_pcibk_guest_interrupt
> [ 7796.165893] Disabling IRQ #32

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:37:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdjY-0006Ml-Hm; Tue, 21 Feb 2012 00:37:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzdjX-0006Mf-8i
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:37:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329784644!14168442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4644 invoked from network); 21 Feb 2012 00:37:24 -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;
	21 Feb 2012 00:37:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325462400"; d="scan'208";a="10825717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 00:37:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 00:37:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzdjP-0001tc-NL;
	Tue, 21 Feb 2012 00:37:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzdjO-00061h-RM;
	Tue, 21 Feb 2012 00:37:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11987-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 00:37:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11987: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11987 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11987/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 00:37:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 00:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzdjY-0006Ml-Hm; Tue, 21 Feb 2012 00:37:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzdjX-0006Mf-8i
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 00:37:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329784644!14168442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4644 invoked from network); 21 Feb 2012 00:37:24 -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;
	21 Feb 2012 00:37:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325462400"; d="scan'208";a="10825717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 00:37:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 00:37:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzdjP-0001tc-NL;
	Tue, 21 Feb 2012 00:37:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzdjO-00061h-RM;
	Tue, 21 Feb 2012 00:37:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11987-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 00:37:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11987: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11987 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11987/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 01:02:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 01: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 1Rze77-0006w5-9l; Tue, 21 Feb 2012 01:01:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rostedt@goodmis.org>) id 1Rze75-0005nH-QK
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 01:01:52 +0000
X-Env-Sender: rostedt@goodmis.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329786105!9955888!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzgwMTk5\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzgwMTk5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28186 invoked from network); 21 Feb 2012 01:01:45 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-7.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 01:01:45 -0000
X-Authority-Analysis: v=2.0 cv=fNy7LOme c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17
	a=ntpRP-UOdioA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10
	a=KWw57ePhm3b483ZPotsA:9 a=PUjeQqilurYA:10
	a=ZycB6UtQUfgMyuk2+PxD7w==:117
X-Cloudmark-Score: 0
X-Originating-IP: 74.67.80.29
Received: from [74.67.80.29] ([74.67.80.29:41592] helo=[192.168.23.10])
	by hrndva-oedge03.mail.rr.com (envelope-from <rostedt@goodmis.org>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 55/D7-11045-7FCE24F4; Tue, 21 Feb 2012 01:01:45 +0000
Message-ID: <1329786103.25686.48.camel@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 20 Feb 2012 20:01:43 -0500
In-Reply-To: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-10 at 10:34 -0500, Konrad Rzeszutek Wilk wrote:
>    66 66 66 90          	data32 data32 xchg %ax,%ax
> 
> [the 66 66 .. is 'nop']. Looks good right? Well, it does work very well on Intel
> (used an i3 2100), but on AMD A8-3850 it hits a performance wall - that I found out
> is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled in (but the tracer
> is set to the default 'nop'). If I disable that specific config option the numbers
> are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on the AMD box.
> Interestingly enough I only see these on AMD machines - not on the Intel ones.

All paravirt ops should be labeled with "notrace" so that function
tracer does not trace those functions. Have you annotated your new
paravirt ops with notrace?

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 01:02:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 01: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 1Rze77-0006w5-9l; Tue, 21 Feb 2012 01:01:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rostedt@goodmis.org>) id 1Rze75-0005nH-QK
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 01:01:52 +0000
X-Env-Sender: rostedt@goodmis.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329786105!9955888!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzgwMTk5\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzgwMTk5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28186 invoked from network); 21 Feb 2012 01:01:45 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-7.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 01:01:45 -0000
X-Authority-Analysis: v=2.0 cv=fNy7LOme c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17
	a=ntpRP-UOdioA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10
	a=KWw57ePhm3b483ZPotsA:9 a=PUjeQqilurYA:10
	a=ZycB6UtQUfgMyuk2+PxD7w==:117
X-Cloudmark-Score: 0
X-Originating-IP: 74.67.80.29
Received: from [74.67.80.29] ([74.67.80.29:41592] helo=[192.168.23.10])
	by hrndva-oedge03.mail.rr.com (envelope-from <rostedt@goodmis.org>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 55/D7-11045-7FCE24F4; Tue, 21 Feb 2012 01:01:45 +0000
Message-ID: <1329786103.25686.48.camel@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 20 Feb 2012 20:01:43 -0500
In-Reply-To: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-10 at 10:34 -0500, Konrad Rzeszutek Wilk wrote:
>    66 66 66 90          	data32 data32 xchg %ax,%ax
> 
> [the 66 66 .. is 'nop']. Looks good right? Well, it does work very well on Intel
> (used an i3 2100), but on AMD A8-3850 it hits a performance wall - that I found out
> is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled in (but the tracer
> is set to the default 'nop'). If I disable that specific config option the numbers
> are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on the AMD box.
> Interestingly enough I only see these on AMD machines - not on the Intel ones.

All paravirt ops should be labeled with "notrace" so that function
tracer does not trace those functions. Have you annotated your new
paravirt ops with notrace?

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 01:40:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 01:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzehY-0002eg-La; Tue, 21 Feb 2012 01:39:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1RzehX-0002eb-Mt
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 01:39:31 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329788364!15356574!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23105 invoked from network); 21 Feb 2012 01:39:25 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 01:39:25 -0000
Received: from android.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q1L1d4cF006558
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 20 Feb 2012 17:39:05 -0800
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<1329786103.25686.48.camel@gandalf.stny.rr.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <1329786103.25686.48.camel@gandalf.stny.rr.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 20 Feb 2012 17:38:52 -0800
To: Steven Rostedt <rostedt@goodmis.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <edb0ef44-341f-4329-a1e7-1c95e164c193@email.android.com>
Cc: xen-devel@lists.xensource.com, tglx@linutronix.de, mingo@redhat.com,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Odd... given that that is the NOP recommended by AMD.

Steven Rostedt <rostedt@goodmis.org> wrote:

>On Fri, 2012-02-10 at 10:34 -0500, Konrad Rzeszutek Wilk wrote:
>>    66 66 66 90          	data32 data32 xchg %ax,%ax
>> 
>> [the 66 66 .. is 'nop']. Looks good right? Well, it does work very
>well on Intel
>> (used an i3 2100), but on AMD A8-3850 it hits a performance wall -
>that I found out
>> is a result of CONFIG_FUNCTION_TRACER (too many nops??) being
>compiled in (but the tracer
>> is set to the default 'nop'). If I disable that specific config
>option the numbers
>> are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled)
>on the AMD box.
>> Interestingly enough I only see these on AMD machines - not on the
>Intel ones.
>
>All paravirt ops should be labeled with "notrace" so that function
>tracer does not trace those functions. Have you annotated your new
>paravirt ops with notrace?
>
>-- Steve

-- 
Sent from my mobile phone. Please excuse my brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 01:40:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 01:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzehY-0002eg-La; Tue, 21 Feb 2012 01:39:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1RzehX-0002eb-Mt
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 01:39:31 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329788364!15356574!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23105 invoked from network); 21 Feb 2012 01:39:25 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 01:39:25 -0000
Received: from android.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q1L1d4cF006558
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 20 Feb 2012 17:39:05 -0800
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<1329786103.25686.48.camel@gandalf.stny.rr.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <1329786103.25686.48.camel@gandalf.stny.rr.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 20 Feb 2012 17:38:52 -0800
To: Steven Rostedt <rostedt@goodmis.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <edb0ef44-341f-4329-a1e7-1c95e164c193@email.android.com>
Cc: xen-devel@lists.xensource.com, tglx@linutronix.de, mingo@redhat.com,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Odd... given that that is the NOP recommended by AMD.

Steven Rostedt <rostedt@goodmis.org> wrote:

>On Fri, 2012-02-10 at 10:34 -0500, Konrad Rzeszutek Wilk wrote:
>>    66 66 66 90          	data32 data32 xchg %ax,%ax
>> 
>> [the 66 66 .. is 'nop']. Looks good right? Well, it does work very
>well on Intel
>> (used an i3 2100), but on AMD A8-3850 it hits a performance wall -
>that I found out
>> is a result of CONFIG_FUNCTION_TRACER (too many nops??) being
>compiled in (but the tracer
>> is set to the default 'nop'). If I disable that specific config
>option the numbers
>> are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled)
>on the AMD box.
>> Interestingly enough I only see these on AMD machines - not on the
>Intel ones.
>
>All paravirt ops should be labeled with "notrace" so that function
>tracer does not trace those functions. Have you annotated your new
>paravirt ops with notrace?
>
>-- Steve

-- 
Sent from my mobile phone. Please excuse my brevity and lack of formatting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzfSC-00041j-IF; Tue, 21 Feb 2012 02:27:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzfSB-00041e-8X
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:27:43 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329791257!9733391!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32320 invoked from network); 21 Feb 2012 02:27:37 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:27:37 -0000
Received: by wibhm2 with SMTP id hm2so12413035wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 18:27:37 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr27373136wib.3.1329791257036
	(num_hops = 1); Mon, 20 Feb 2012 18:27:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr22846292wib.3.1329791256967; Mon,
	20 Feb 2012 18:27:36 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 18:27:36 -0800 (PST)
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21D76F8D78BE@LONPMAILBOX01.citrite.net>
References: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@mail.gmail.com>
	<81A73678E76EA642801C8F2E4823AD21D76F8D78BE@LONPMAILBOX01.citrite.net>
Date: Mon, 20 Feb 2012 18:27:36 -0800
Message-ID: <CAMrHX2Xf4AL=Mo1zWbE6BNgDDhnSBrF=XZQPmtBthL23EvFrQQ@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: Dave Scott <Dave.Scott@eu.citrix.com>
X-Gm-Message-State: ALoCoQlZtdint+P6VNBcbjBkniNiLVWq3ASzVXtZfM9vGthecusX74GivQYr7iTl6pJX5F0zqiTx
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] persistent or "steady-state" style 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="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 that information.

It isn't obvious in the XCP code how this feature is being done and
I'm not wanting to use XCP at this point as it's behind without the
latest hypervisor included.

I actually created a patch where you can=A0can set the temporary flag on
the VHD features footer through vhd-util.
Traditionally in the MS world=A0is used to omdocated that the VHD can be
removed on close.
I'm using it for reset-on-boot where if the flag=A0is set during
_vhd_open it tests the flag and if set will regenerate the snapshot
from the parent VHD.

If anyone is interested in this patch right now I can send it through
as is. =A0However, I'll submit it properly once I've done a bit
more testing.

Comments are welcome.

Matt

On 17 February 2012 13:21, Dave Scott <Dave.Scott@eu.citrix.com> wrote:
>
> Hi,
>
> Matthew Hook wrote:
> > I have a requirement (and a limited timeframe) to make a Windows 7 VM d=
omain roll back to a fixed state on restart, shutdown etc.
> > Something like a Kiosk Mode. =A0I think this is a very needed part of t=
he core of xen and this functionality does
> > not appear to be part of xen already. =A0So I've been trying various wa=
ys to make this work.
>
> XCP has a feature which might do what you need.
>
> If you are using .vhd file based storage (SR types 'ext' or 'nfs') then y=
ou can do the following: (for a VM called "myvm")
>
> # 1. Ensure the .vhd chain has length 2 (a current restriction)
> xe vm-copy vm=3Dmyvm new-name-label=3Dnonpersistent.parent
> xe vm-clone vm=3Dnonpersistent.parent new-name-label=3Dnonpersistent
>
> # 2. Set the VDI on-boot=3Dreset
> xe vm-disk-list vm=3Dnonpersistent
> =A0... note the VDI uuid of the disk you want to reset ...
> xe vdi-param-set uuid=3D... on-boot=3Dreset
>
> # 3. Start the VM
> xe vm-start vm=3Dnonpersistent
>
> HTH,
> Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzfSC-00041j-IF; Tue, 21 Feb 2012 02:27:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzfSB-00041e-8X
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:27:43 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329791257!9733391!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32320 invoked from network); 21 Feb 2012 02:27:37 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:27:37 -0000
Received: by wibhm2 with SMTP id hm2so12413035wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 18:27:37 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr27373136wib.3.1329791257036
	(num_hops = 1); Mon, 20 Feb 2012 18:27:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr22846292wib.3.1329791256967; Mon,
	20 Feb 2012 18:27:36 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 18:27:36 -0800 (PST)
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21D76F8D78BE@LONPMAILBOX01.citrite.net>
References: <CAMrHX2XPSAMNoaDAQ=YE1QoSt9raU9ngrwD-Ahak83nYhMVyUw@mail.gmail.com>
	<81A73678E76EA642801C8F2E4823AD21D76F8D78BE@LONPMAILBOX01.citrite.net>
Date: Mon, 20 Feb 2012 18:27:36 -0800
Message-ID: <CAMrHX2Xf4AL=Mo1zWbE6BNgDDhnSBrF=XZQPmtBthL23EvFrQQ@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: Dave Scott <Dave.Scott@eu.citrix.com>
X-Gm-Message-State: ALoCoQlZtdint+P6VNBcbjBkniNiLVWq3ASzVXtZfM9vGthecusX74GivQYr7iTl6pJX5F0zqiTx
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] persistent or "steady-state" style 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="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 that information.

It isn't obvious in the XCP code how this feature is being done and
I'm not wanting to use XCP at this point as it's behind without the
latest hypervisor included.

I actually created a patch where you can=A0can set the temporary flag on
the VHD features footer through vhd-util.
Traditionally in the MS world=A0is used to omdocated that the VHD can be
removed on close.
I'm using it for reset-on-boot where if the flag=A0is set during
_vhd_open it tests the flag and if set will regenerate the snapshot
from the parent VHD.

If anyone is interested in this patch right now I can send it through
as is. =A0However, I'll submit it properly once I've done a bit
more testing.

Comments are welcome.

Matt

On 17 February 2012 13:21, Dave Scott <Dave.Scott@eu.citrix.com> wrote:
>
> Hi,
>
> Matthew Hook wrote:
> > I have a requirement (and a limited timeframe) to make a Windows 7 VM d=
omain roll back to a fixed state on restart, shutdown etc.
> > Something like a Kiosk Mode. =A0I think this is a very needed part of t=
he core of xen and this functionality does
> > not appear to be part of xen already. =A0So I've been trying various wa=
ys to make this work.
>
> XCP has a feature which might do what you need.
>
> If you are using .vhd file based storage (SR types 'ext' or 'nfs') then y=
ou can do the following: (for a VM called "myvm")
>
> # 1. Ensure the .vhd chain has length 2 (a current restriction)
> xe vm-copy vm=3Dmyvm new-name-label=3Dnonpersistent.parent
> xe vm-clone vm=3Dnonpersistent.parent new-name-label=3Dnonpersistent
>
> # 2. Set the VDI on-boot=3Dreset
> xe vm-disk-list vm=3Dnonpersistent
> =A0... note the VDI uuid of the disk you want to reset ...
> xe vdi-param-set uuid=3D... on-boot=3Dreset
>
> # 3. Start the VM
> xe vm-start vm=3Dnonpersistent
>
> HTH,
> Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfW3-0004Fv-8W; Tue, 21 Feb 2012 02:31:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RzfW1-0004Ff-3V
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:31:41 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329791443!55043829!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16802 invoked from network); 21 Feb 2012 02:30:45 -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; 21 Feb 2012 02:30:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1L2VXMd015918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 02:31:34 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
	q1L2VW3J013680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 02:31:33 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
	q1L2VW6v031870; Mon, 20 Feb 2012 20:31:32 -0600
Received: from [10.182.38.194] (/10.182.38.194)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 18:31:31 -0800
Message-ID: <4F430201.3040208@oracle.com>
Date: Tue, 21 Feb 2012 10:31:29 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F430206.0019,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	young zhang <young.zhang.free@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-2-21 7:54, Zhang, Yang Z wrote:
>> -----Original Message-----
>> From: young zhang [mailto:young.zhang.free@gmail.com]
>> Sent: Monday, February 20, 2012 11:04 PM
>> To: Zhang, Yang Z
>> Cc: ANNIE LI; xen-devel@lists.xensource.com; Kurt Hackel; Dan Magenheimer;
>> Konrad Rzeszutek Wilk
>> Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
>> to tm->tm_year
>>
>> The mktime which used in xen is different from standard C. I think the best way is
>> change it same as normal mktime, or else, other people will make the same
>> mistake too.
> yes. The name will mislead the people who not look into the code, including me. :)

I compared the mktime of xen with mktime of linux. The code is almost 
the same, I do not understand why xen requires the input year is 
tm->tm_year, not tm->tm_year+1900. Am I missing somthing?

See following diff file which is created between mktime of linux and 
mktime of xen, (I did some tab/space format changes for comparison)

diff linux-mktime.c xen-mktime.c
2,4c2,4
< mktime(const unsigned int year0, const unsigned int mon0,
<       const unsigned int day, const unsigned int hour,
<       const unsigned int min, const unsigned int sec)
---
 > mktime (unsigned int year, unsigned int mon,
 >       unsigned int day, unsigned int hour,
 >       unsigned int min, unsigned int sec)
6,8c6
<       unsigned int mon = mon0, year = year0;
<
<       /* 1..12 -> 11,12,1..10 */
---
 >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
10c8
<               mon += 12;      /* Puts Feb last since it has leap day */
---
 >               mon += 12;
21d18
<

Thanks
Annie
>
> best regards
> yang
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfW3-0004Fv-8W; Tue, 21 Feb 2012 02:31:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RzfW1-0004Ff-3V
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:31:41 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329791443!55043829!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16802 invoked from network); 21 Feb 2012 02:30:45 -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; 21 Feb 2012 02:30:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1L2VXMd015918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 02:31:34 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
	q1L2VW3J013680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 02:31:33 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
	q1L2VW6v031870; Mon, 20 Feb 2012 20:31:32 -0600
Received: from [10.182.38.194] (/10.182.38.194)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 18:31:31 -0800
Message-ID: <4F430201.3040208@oracle.com>
Date: Tue, 21 Feb 2012 10:31:29 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F430206.0019,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	young zhang <young.zhang.free@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-2-21 7:54, Zhang, Yang Z wrote:
>> -----Original Message-----
>> From: young zhang [mailto:young.zhang.free@gmail.com]
>> Sent: Monday, February 20, 2012 11:04 PM
>> To: Zhang, Yang Z
>> Cc: ANNIE LI; xen-devel@lists.xensource.com; Kurt Hackel; Dan Magenheimer;
>> Konrad Rzeszutek Wilk
>> Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
>> to tm->tm_year
>>
>> The mktime which used in xen is different from standard C. I think the best way is
>> change it same as normal mktime, or else, other people will make the same
>> mistake too.
> yes. The name will mislead the people who not look into the code, including me. :)

I compared the mktime of xen with mktime of linux. The code is almost 
the same, I do not understand why xen requires the input year is 
tm->tm_year, not tm->tm_year+1900. Am I missing somthing?

See following diff file which is created between mktime of linux and 
mktime of xen, (I did some tab/space format changes for comparison)

diff linux-mktime.c xen-mktime.c
2,4c2,4
< mktime(const unsigned int year0, const unsigned int mon0,
<       const unsigned int day, const unsigned int hour,
<       const unsigned int min, const unsigned int sec)
---
 > mktime (unsigned int year, unsigned int mon,
 >       unsigned int day, unsigned int hour,
 >       unsigned int min, unsigned int sec)
6,8c6
<       unsigned int mon = mon0, year = year0;
<
<       /* 1..12 -> 11,12,1..10 */
---
 >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
10c8
<               mon += 12;      /* Puts Feb last since it has leap day */
---
 >               mon += 12;
21d18
<

Thanks
Annie
>
> best regards
> yang
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:36:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfaH-0004Sy-V2; Tue, 21 Feb 2012 02:36:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzfaG-0004Sj-Kl
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:36:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329791757!10111100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23964 invoked from network); 21 Feb 2012 02:35:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325462400"; d="scan'208";a="10826053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 02:35:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 02:35:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rzfa9-0002cc-5Y;
	Tue, 21 Feb 2012 02:35:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rzfa8-0001mI-WE;
	Tue, 21 Feb 2012 02:35:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11988-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 02:35:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11988: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11988 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11988/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:36:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfaH-0004Sy-V2; Tue, 21 Feb 2012 02:36:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzfaG-0004Sj-Kl
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:36:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329791757!10111100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23964 invoked from network); 21 Feb 2012 02:35:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325462400"; d="scan'208";a="10826053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 02:35:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 02:35:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rzfa9-0002cc-5Y;
	Tue, 21 Feb 2012 02:35:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rzfa8-0001mI-WE;
	Tue, 21 Feb 2012 02:35:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11988-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 02:35:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11988: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11988 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11988/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfeY-0004eh-Qq; Tue, 21 Feb 2012 02:40:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RzfeX-0004ea-4r
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:40:29 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329792020!2814784!1
X-Originating-IP: [216.33.127.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28818 invoked from network); 21 Feb 2012 02:40:21 -0000
Received: from mta31.charter.net (HELO mta31.charter.net) (216.33.127.82)
	by server-9.tower-21.messagelabs.com with SMTP;
	21 Feb 2012 02:40:21 -0000
Received: from imp09 ([10.20.200.9]) by mta31.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120221024019.VVTY4042.mta31.charter.net@imp09>;
	Mon, 20 Feb 2012 21:40:19 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id cSgK1i00J46xN4z05SgKK5; Mon, 20 Feb 2012 21:40:19 -0500
X-Authority-Analysis: v=1.1 cv=psWcb5N98119OaOi9bjyg15qVElTHlpKZyP+LUQnThs=
	c=1 sm=1 a=PVXGLkQwnNcA:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=kj9zAlcOel0A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=SEF7xSSsAAAA:8 a=6mQg2bj1Nx-oaL5D3BwA:9 a=uEcZVbxjUJKl5wITbR0A:7
	a=CjuIK1q_8ugA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 0FA93203DD;
	Tue, 21 Feb 2012 02:40:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Kvx8wsp5kX0X; Mon, 20 Feb 2012 21:39:58 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 6DBD62033E;
	Mon, 20 Feb 2012 21:39:58 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: "'Ian Campbell'" <Ian.Campbell@citrix.com>,
	"'Anthony PERARD'" <anthony.perard@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>	<1329131119975-5478798.post@n5.nabble.com>	<CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
	<1329134175.31256.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329134175.31256.71.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 21:38:38 -0500
Message-ID: <000001ccf041$edd791d0$c986b570$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIVz/8IgaCJ5iLQhHuaq3K0uKZBWwL/0OnPAYu0CL4AcX3nvZWM+2gg
Content-Language: en-us
Cc: xen-devel@lists.xensource.com, 'Fantu' <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Ian Campbell
> Sent: Monday, February 13, 2012 6:56 AM
> To: Anthony PERARD
> Cc: xen-devel@lists.xensource.com; Fantu
> Subject: Re: [Xen-devel] 4.2 TODO update
> 
> On Mon, 2012-02-13 at 11:50 +0000, Anthony PERARD wrote:
> > On Mon, Feb 13, 2012 at 11:05, Fantu <fantonifabio@tiscali.it> wrote:
> > >         * Spice full support and build enabled by default
> > >
> > > About Spice support on qemu upstream, now is not built by default and
> on xl
> > > configuration files is minimal. Probably there are also some required
> missed
> > > options about qxl graphic needed by Spice on xl configuration files.
> > > I search on tools/libxl/libxl_dm.c but I have found nothing about qxl
now.
> >
> > About the build, QEMU should include spice support if the necessary
> > library are installed. But on Debian stable (Squeeze), the spice
> > library are too old, so forcing QEMU to have spice support will just
> > break the build.
> 
> Agreed, spice support should be conditional on the necessary support
> libraries being available. It would however be useful to document (e.g.
> in the top-level README) exactly what those requirements are.
> 
> Ian.
> 

Is it my understanding that currently there is no way to pass the -vga
option to qemu using the xl cfg file?  This seems in my mind a very trivial
thing to do, I don't want to reinvent the wheel if I'm just missing
something.
Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfeY-0004eh-Qq; Tue, 21 Feb 2012 02:40:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RzfeX-0004ea-4r
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:40:29 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329792020!2814784!1
X-Originating-IP: [216.33.127.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28818 invoked from network); 21 Feb 2012 02:40:21 -0000
Received: from mta31.charter.net (HELO mta31.charter.net) (216.33.127.82)
	by server-9.tower-21.messagelabs.com with SMTP;
	21 Feb 2012 02:40:21 -0000
Received: from imp09 ([10.20.200.9]) by mta31.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20120221024019.VVTY4042.mta31.charter.net@imp09>;
	Mon, 20 Feb 2012 21:40:19 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id cSgK1i00J46xN4z05SgKK5; Mon, 20 Feb 2012 21:40:19 -0500
X-Authority-Analysis: v=1.1 cv=psWcb5N98119OaOi9bjyg15qVElTHlpKZyP+LUQnThs=
	c=1 sm=1 a=PVXGLkQwnNcA:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=kj9zAlcOel0A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=SEF7xSSsAAAA:8 a=6mQg2bj1Nx-oaL5D3BwA:9 a=uEcZVbxjUJKl5wITbR0A:7
	a=CjuIK1q_8ugA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 0FA93203DD;
	Tue, 21 Feb 2012 02:40:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Kvx8wsp5kX0X; Mon, 20 Feb 2012 21:39:58 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 6DBD62033E;
	Mon, 20 Feb 2012 21:39:58 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: "'Ian Campbell'" <Ian.Campbell@citrix.com>,
	"'Anthony PERARD'" <anthony.perard@citrix.com>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>	<1329131119975-5478798.post@n5.nabble.com>	<CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
	<1329134175.31256.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329134175.31256.71.camel@zakaz.uk.xensource.com>
Date: Mon, 20 Feb 2012 21:38:38 -0500
Message-ID: <000001ccf041$edd791d0$c986b570$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIVz/8IgaCJ5iLQhHuaq3K0uKZBWwL/0OnPAYu0CL4AcX3nvZWM+2gg
Content-Language: en-us
Cc: xen-devel@lists.xensource.com, 'Fantu' <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Ian Campbell
> Sent: Monday, February 13, 2012 6:56 AM
> To: Anthony PERARD
> Cc: xen-devel@lists.xensource.com; Fantu
> Subject: Re: [Xen-devel] 4.2 TODO update
> 
> On Mon, 2012-02-13 at 11:50 +0000, Anthony PERARD wrote:
> > On Mon, Feb 13, 2012 at 11:05, Fantu <fantonifabio@tiscali.it> wrote:
> > >         * Spice full support and build enabled by default
> > >
> > > About Spice support on qemu upstream, now is not built by default and
> on xl
> > > configuration files is minimal. Probably there are also some required
> missed
> > > options about qxl graphic needed by Spice on xl configuration files.
> > > I search on tools/libxl/libxl_dm.c but I have found nothing about qxl
now.
> >
> > About the build, QEMU should include spice support if the necessary
> > library are installed. But on Debian stable (Squeeze), the spice
> > library are too old, so forcing QEMU to have spice support will just
> > break the build.
> 
> Agreed, spice support should be conditional on the necessary support
> libraries being available. It would however be useful to document (e.g.
> in the top-level README) exactly what those requirements are.
> 
> Ian.
> 

Is it my understanding that currently there is no way to pass the -vga
option to qemu using the xl cfg file?  This seems in my mind a very trivial
thing to do, I don't want to reinvent the wheel if I'm just missing
something.
Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzfub-0004v2-CA; Tue, 21 Feb 2012 02:57:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuZ-0004uZ-30
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:57:03 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329792949!61873016!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIyMzQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19724 invoked from network); 21 Feb 2012 02:55:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="22272202"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:57:00 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Mon, 20 Feb 2012
	21:57:00 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:59 -0500
Thread-Topic: [PATCH 3/3] SMBIOS table passthrough support
Thread-Index: AczwQNrTPDyk+eCeRFm95p9AJHNqKQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323DA@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SMBIOS tables are written into the HVM parameter and information page. The =
SMBIOS tables would normally come from system firmware where they are writt=
en by the xen toolstack. In general though, there is no limitation on where=
 the tables come from other than their following the DMTF standards. In the=
 SMBIOS building code in hvmloader, passed in tables are searched for and t=
ake precedence over default values when found.

Three new tables were added (types 2, 22 and 39) but are disabled by defaul=
t. A set of flags is used to specify inclusion of new tables so that the ex=
isting default set is preserved. In addition to the pre-defined table types=
, OEM specific tables (types 128 - 255) can also be written in. Any number =
of OEM tables can be passed in and will be surfaced in the HVM SMBIOS.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_
Content-Type: application/octet-stream; name="smbios-passthrough-03.patch"
Content-Description: smbios-passthrough-03.patch
Content-Disposition: attachment; filename="smbios-passthrough-03.patch";
	size=14595; creation-date="Tue, 21 Feb 2012 01:56:15 GMT";
	modification-date="Tue, 21 Feb 2012 01:56:15 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAwOTAwYjFjOTA1ZjEgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3NtYmlvcy5jCi0t
LSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9zbWJpb3MuYwlNb24gRmViIDIwIDE4OjU4OjA3
IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3NtYmlvcy5jCU1vbiBG
ZWIgMjAgMjA6NTY6NTggMjAxMiAtMDUwMApAQCAtNDksNiArNDksOCBAQAogc21iaW9zX3R5cGVf
MV9pbml0KHZvaWQgKnN0YXJ0LCBjb25zdCBjaGFyICp4ZW5fdmVyc2lvbiwgCiAgICAgICAgICAg
ICAgICAgICAgdWludDhfdCB1dWlkWzE2XSk7CiBzdGF0aWMgdm9pZCAqCitzbWJpb3NfdHlwZV8y
X2luaXQodm9pZCAqc3RhcnQpOworc3RhdGljIHZvaWQgKgogc21iaW9zX3R5cGVfM19pbml0KHZv
aWQgKnN0YXJ0KTsKIHN0YXRpYyB2b2lkICoKIHNtYmlvc190eXBlXzRfaW5pdCh2b2lkICpzdGFy
dCwgdW5zaWduZWQgaW50IGNwdV9udW1iZXIsCkBAIC02NCw4ICs2NiwxNCBAQAogc3RhdGljIHZv
aWQgKgogc21iaW9zX3R5cGVfMjBfaW5pdCh2b2lkICpzdGFydCwgdWludDMyX3QgbWVtb3J5X3Np
emVfbWIsIGludCBpbnN0YW5jZSk7CiBzdGF0aWMgdm9pZCAqCitzbWJpb3NfdHlwZV8yMl9pbml0
KHZvaWQgKnN0YXJ0KTsKK3N0YXRpYyB2b2lkICoKIHNtYmlvc190eXBlXzMyX2luaXQodm9pZCAq
c3RhcnQpOwogc3RhdGljIHZvaWQgKgorc21iaW9zX3R5cGVfMzlfaW5pdCh2b2lkICpzdGFydCk7
CitzdGF0aWMgdm9pZCAqCitzbWJpb3NfdHlwZV92ZW5kb3Jfb2VtX2luaXQodm9pZCAqc3RhcnQp
Oworc3RhdGljIHZvaWQgKgogc21iaW9zX3R5cGVfMTI3X2luaXQodm9pZCAqc3RhcnQpOwogCiBz
dGF0aWMgdm9pZApAQCAtODUsNiArOTMsNzcgQEAKICAgICAgICAgc3RybmNweShidWYsICJ1bmtu
b3duIiwgbGVuKTsKIH0KIAorc3RhdGljIHN0cnVjdCBodm1fc21iaW9zX3RhYmxlX2hlYWRlciAq
CitnZXRfc21iaW9zX2luZm9fYnlfdHlwZShzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpw
YV9zbWJ0LCB1aW50OF90IHR5cGUpCit7CisgICAgc3RydWN0IGh2bV9zbWJpb3NfdGFibGVfaGVh
ZGVyICpoZWFkZXI7CisgICAgdWludDMyX3QgY291bnQ7CisgICAgdWludDhfdCAqcHRyOworCisg
ICAgaGVhZGVyID0gKHN0cnVjdCBodm1fc21iaW9zX3RhYmxlX2hlYWRlciopCisgICAgICAgICgo
dWludDhfdCopcGFfc21idCArIHNpemVvZihzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlKSk7
CisKKyAgICBmb3IgKCBjb3VudCA9IDA7IGNvdW50IDwgcGFfc21idC0+Y291bnQ7IGNvdW50Kysg
KQorICAgIHsKKyAgICAgICAgaWYgKCAoaGVhZGVyLT5sZW5ndGggPiAwKSYmKGhlYWRlci0+bGVu
Z3RoIDwgSFZNX1NNQklPU19JTkZPX01BWCkgKQorICAgICAgICB7CisgICAgICAgICAgICBwdHIg
PSAoKHVpbnQ4X3QqKWhlYWRlciArIHNpemVvZihzdHJ1Y3QgaHZtX3NtYmlvc190YWJsZV9oZWFk
ZXIpKTsKKyAgICAgICAgICAgIGlmICggcHRyWzBdID09IHR5cGUgKQorICAgICAgICAgICAgICAg
IHJldHVybiBoZWFkZXI7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICB7CisgICAg
ICAgICAgICBwcmludGYoIlNNQklPUyB0YWJsZSBpbnZhbGlkIGxlbmd0aDogJWQsIGFib3J0aW5n
LiIsCisgICAgICAgICAgICAgICAgICAgKGludCloZWFkZXItPmxlbmd0aCk7CisgICAgICAgICAg
ICByZXR1cm4gTlVMTDsKKyAgICAgICAgfQorCisgICAgICAgIGhlYWRlciA9IChzdHJ1Y3QgaHZt
X3NtYmlvc190YWJsZV9oZWFkZXIqKShwdHIgKyBoZWFkZXItPmxlbmd0aCk7CisgICAgfQorCisg
ICAgcmV0dXJuIE5VTEw7Cit9CisKKyNkZWZpbmUgU1BUQVJHKHMsIHQpIHMsIHQsIHNpemVvZihz
dHJ1Y3Qgc21iaW9zX3R5cGVfIyN0KQorc3RhdGljIHVpbnQzMl90CitzbWJpb3NfcGFzc3Rocm91
Z2godm9pZCAqc3RhcnQsIHVpbnQ4X3QgdGFibGUsIHVpbnQzMl90IHN0c2l6ZSkKK3sKKyAgICBz
dHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpwYV9zbWJ0OworICAgIHN0cnVjdCBodm1fc21i
aW9zX3RhYmxlX2hlYWRlciAqaGVhZGVyOworCisgICAgcGFfc21idCA9IGdldF9odm1fc21iaW9z
X2luZm9fdGFibGUoKTsKKyAgICBpZiAoIHBhX3NtYnQgPT0gTlVMTCApCisgICAgICAgIHJldHVy
biAwOworCisgICAgaGVhZGVyID0gZ2V0X3NtYmlvc19pbmZvX2J5X3R5cGUocGFfc21idCwgdGFi
bGUpOworICAgIGlmICggaGVhZGVyID09IE5VTEwgKQorICAgICAgICByZXR1cm4gMDsKKworICAg
IGlmICggaGVhZGVyLT5sZW5ndGggPCBzdHNpemUgKQorICAgIHsKKyAgICAgICAgcHJpbnRmKCJT
TUJJT1MgdGFibGUgbGVuZ3RoIGxlc3MgdGhhbiBmaXhlZCBtaW5pbXVtIGxlbmd0aCwgc2tpcHBp
bmcuIik7CisgICAgICAgIHJldHVybiAwOworICAgIH0KKworICAgIG1lbWNweShzdGFydCwKKyAg
ICAgICAgICAgKCh1aW50OF90KiloZWFkZXIgKyBzaXplb2Yoc3RydWN0IGh2bV9zbWJpb3NfdGFi
bGVfaGVhZGVyKSksCisgICAgICAgICAgIGhlYWRlci0+bGVuZ3RoKTsKKworICAgIHJldHVybiBo
ZWFkZXItPmxlbmd0aDsKK30KKworc3RhdGljIHVpbnQzMl90CitnZXRfc21iaW9zX2luZm9fZmxh
Z3Modm9pZCkKK3sKKyAgICBzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpwYV9zbWJ0Owor
CisgICAgcGFfc21idCA9IGdldF9odm1fc21iaW9zX2luZm9fdGFibGUoKTsKKyAgICBpZiAoIHBh
X3NtYnQgIT0gTlVMTCApCisgICAgICAgIHJldHVybiBwYV9zbWJ0LT5mbGFnczsKKworICAgIHJl
dHVybiAwOworfQorCiBzdGF0aWMgaW50CiB3cml0ZV9zbWJpb3NfdGFibGVzKHZvaWQgKmVwLCB2
b2lkICpzdGFydCwKICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgdmNwdXMsIHVpbnQ2NF90
IG1lbXNpemUsCkBAIC0xMTIsNiArMTkxLDcgQEAKICAgICBkb19zdHJ1Y3Qoc21iaW9zX3R5cGVf
MF9pbml0KHAsIHhlbl92ZXJzaW9uLCB4ZW5fbWFqb3JfdmVyc2lvbiwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHhlbl9taW5vcl92ZXJzaW9uKSk7CiAgICAgZG9fc3RydWN0KHNt
Ymlvc190eXBlXzFfaW5pdChwLCB4ZW5fdmVyc2lvbiwgdXVpZCkpOworICAgIGRvX3N0cnVjdChz
bWJpb3NfdHlwZV8yX2luaXQocCkpOwogICAgIGRvX3N0cnVjdChzbWJpb3NfdHlwZV8zX2luaXQo
cCkpOwogICAgIGZvciAoIGNwdV9udW0gPSAxOyBjcHVfbnVtIDw9IHZjcHVzOyBjcHVfbnVtKysg
KQogICAgICAgICBkb19zdHJ1Y3Qoc21iaW9zX3R5cGVfNF9pbml0KHAsIGNwdV9udW0sIGNwdV9t
YW51ZmFjdHVyZXIpKTsKQEAgLTEzMCw3ICsyMTAsMTAgQEAKICAgICAgICAgZG9fc3RydWN0KHNt
Ymlvc190eXBlXzIwX2luaXQocCwgZGV2X21lbXNpemUsIGkpKTsKICAgICB9CiAKKyAgICBkb19z
dHJ1Y3Qoc21iaW9zX3R5cGVfMjJfaW5pdChwKSk7CiAgICAgZG9fc3RydWN0KHNtYmlvc190eXBl
XzMyX2luaXQocCkpOworICAgIGRvX3N0cnVjdChzbWJpb3NfdHlwZV8zOV9pbml0KHApKTsKKyAg
ICBkb19zdHJ1Y3Qoc21iaW9zX3R5cGVfdmVuZG9yX29lbV9pbml0KHApKTsKICAgICBkb19zdHJ1
Y3Qoc21iaW9zX3R5cGVfMTI3X2luaXQocCkpOwogCiAjdW5kZWYgZG9fc3RydWN0CkBAIC0yODks
NiArMzcyLDE1IEBACiAgICAgc3RydWN0IHNtYmlvc190eXBlXzAgKnAgPSAoc3RydWN0IHNtYmlv
c190eXBlXzAgKilzdGFydDsKICAgICBzdGF0aWMgY29uc3QgY2hhciAqc21iaW9zX3JlbGVhc2Vf
ZGF0ZSA9IF9fU01CSU9TX0RBVEVfXzsKICAgICBjb25zdCBjaGFyICpzOworICAgIHVpbnQzMl90
IGxlbmd0aDsKKworICAgIGxlbmd0aCA9IHNtYmlvc19wYXNzdGhyb3VnaChTUFRBUkcoc3RhcnQs
IDApKTsKKyAgICBpZiAoIGxlbmd0aCA+IDAgKQorICAgIHsKKyAgICAgICAgLyogRml4IHVwLCB1
c2UgY29uc2lzdGVudCBoYW5kbGVzICovCisgICAgICAgIHAtPmhlYWRlci5oYW5kbGUgPSAwOwor
ICAgICAgICByZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKKyAgICB9CiAKICAgICBtZW1zZXQocCwg
MCwgc2l6ZW9mKCpwKSk7CiAKQEAgLTMzOCw2ICs0MzAsMTUgQEAKICAgICBjaGFyIHV1aWRfc3Ry
WzM3XTsKICAgICBzdHJ1Y3Qgc21iaW9zX3R5cGVfMSAqcCA9IChzdHJ1Y3Qgc21iaW9zX3R5cGVf
MSAqKXN0YXJ0OwogICAgIGNvbnN0IGNoYXIgKnM7CisgICAgdWludDMyX3QgbGVuZ3RoOworCisg
ICAgbGVuZ3RoID0gc21iaW9zX3Bhc3N0aHJvdWdoKFNQVEFSRyhzdGFydCwgMSkpOworICAgIGlm
ICggbGVuZ3RoID4gMCApCisgICAgeworICAgICAgICAvKiBGaXggdXAsIHVzZSBjb25zaXN0ZW50
IGhhbmRsZXMgKi8KKyAgICAgICAgcC0+aGVhZGVyLmhhbmRsZSA9IDB4MTAwOworICAgICAgICBy
ZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKKyAgICB9CiAKICAgICBtZW1zZXQocCwgMCwgc2l6ZW9m
KCpwKSk7CiAKQEAgLTM3NiwxNSArNDc3LDg4IEBACiAgICAgc3RhcnQgKz0gc3RybGVuKHMpICsg
MTsKIAogICAgICooKHVpbnQ4X3QgKilzdGFydCkgPSAwOwotICAgIAogICAgIHJldHVybiBzdGFy
dCsxOyAKIH0KIAorLyogVHlwZSAyIC0tIFN5c3RlbSBCb2FyZCAqLworc3RhdGljIHZvaWQgKgor
c21iaW9zX3R5cGVfMl9pbml0KHZvaWQgKnN0YXJ0KQoreworICAgIHN0cnVjdCBzbWJpb3NfdHlw
ZV8yICpwID0gKHN0cnVjdCBzbWJpb3NfdHlwZV8yICopc3RhcnQ7CisgICAgdWludDhfdCAqYnB0
cjsKKyAgICBjb25zdCBjaGFyICpzOworICAgIHVpbnQzMl90IGxlbmd0aDsKKworICAgIGlmICgg
KGdldF9zbWJpb3NfaW5mb19mbGFncygpICYgSFZNX1NNQklPU19JTkNMVURFX1NZU1RFTV9CT0FS
RCkgPT0gMCApCisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIGxlbmd0aCA9IHNtYmlvc19w
YXNzdGhyb3VnaChTUFRBUkcoc3RhcnQsIDIpKTsKKyAgICBpZiAoIGxlbmd0aCA+IDAgKQorICAg
IHsKKyAgICAgICAgLyogRml4IHVwLCB1c2UgY29uc2lzdGVudCBoYW5kbGVzLCBzZXQgY2hhc3Np
cyBoYW5kbGUgKi8KKyAgICAgICAgcC0+aGVhZGVyLmhhbmRsZSA9IDB4MjAwOworCisgICAgICAg
IC8qIE5PVEU6IGlmIHRoaXMgY29kZSBpcyBlbmhhbmNlZCB0byBhbGxvdyBtdWx0aXBsZSBpbnN0
YW5jZXMgb2Ygc29tZSB0YWJsZXMgbGlrZQorICAgICAgICAgICB0aGlzIG9uZSwgY2hhc3NpcyBp
bmZvLCBldGMuIHRoZW4gd29yayB3aWxsIGhhdmUgdG8gYmUgZG9uZSB0byBtYXRjaCB0aGVzZSBo
YW5kbGVzICovCisgICAgICAgIGlmICggcC0+aGVhZGVyLmxlbmd0aCA+PSAxMyApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGJwdHIgPSAoKHVpbnQ4X3QqKXN0YXJ0KSArIDExOworICAgICAgICAg
ICAgaWYgKCooKHVpbnQxNl90KilicHRyKSAhPSAwKQorICAgICAgICAgICAgICAgICooKHVpbnQx
Nl90KilicHRyKSA9IDB4MzAwOyAvKiBjdXJyZW50IGNoYXNzaXMgaGFuZGxlICovCisgICAgICAg
IH0KKworICAgICAgICByZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKKyAgICB9CisKKyAgICBtZW1z
ZXQocCwgMCwgc2l6ZW9mKCpwKSk7CisKKyAgICBwLT5oZWFkZXIudHlwZSA9IDI7CisgICAgcC0+
aGVhZGVyLmxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc21iaW9zX3R5cGVfMik7CisgICAgcC0+aGVh
ZGVyLmhhbmRsZSA9IDB4MjAwOworCisgICAgcC0+bWFudWZhY3R1cmVyX3N0ciA9IDE7CisgICAg
cC0+cHJvZHVjdF9uYW1lX3N0ciA9IDI7CisgICAgcC0+dmVyc2lvbl9zdHIgPSAwOworICAgIHAt
PnNlcmlhbF9udW1iZXJfc3RyID0gMDsKKworICAgIHN0YXJ0ICs9IHNpemVvZihzdHJ1Y3Qgc21i
aW9zX3R5cGVfMik7CisKKyAgICBzID0geGVuc3RvcmVfcmVhZCgiYmlvcy1zdHJpbmdzL2JvYXJk
LW1hbnVmYWN0dXJlciIsICJYZW4iKTsKKyAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgcyk7Cisg
ICAgc3RhcnQgKz0gc3RybGVuKHMpICsgMTsKKworICAgIHMgPSB4ZW5zdG9yZV9yZWFkKCJiaW9z
LXN0cmluZ3MvYm9hcmQtcHJvZHVjdC1uYW1lIiwgIkhWTSBkb21VIik7CisgICAgc3RyY3B5KChj
aGFyICopc3RhcnQsIHMpOworICAgIHN0YXJ0ICs9IHN0cmxlbihzKSArIDE7CisKKyAgICAvKiBu
byBpbnRlcm5hbCBkZWZhdWx0cyBmb3IgdGhpcyBpZiB0aGUgdmFsdWUgaXMgbm90IHNldCAqLwor
ICAgIHMgPSB4ZW5zdG9yZV9yZWFkKCJiaW9zLXN0cmluZ3MvYm9hcmQtc2VyaWFsLW51bWJlciIs
IE5VTEwpOworICAgIGlmICggKHMgIT0gTlVMTCkmJigqcyAhPSAnXDAnKSApCisgICAgeworICAg
ICAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgcyk7CisgICAgICAgIHN0YXJ0ICs9IHN0cmxlbihz
KSArIDE7ICAgICAgICAKKyAgICAgICAgcC0+c2VyaWFsX251bWJlcl9zdHIgPSAzOworICAgIH0K
KworICAgICooKHVpbnQ4X3QgKilzdGFydCkgPSAwOworICAgIHJldHVybiBzdGFydCsxOworfQor
CiAvKiBUeXBlIDMgLS0gU3lzdGVtIEVuY2xvc3VyZSAqLwogc3RhdGljIHZvaWQgKgogc21iaW9z
X3R5cGVfM19pbml0KHZvaWQgKnN0YXJ0KQogewogICAgIHN0cnVjdCBzbWJpb3NfdHlwZV8zICpw
ID0gKHN0cnVjdCBzbWJpb3NfdHlwZV8zICopc3RhcnQ7CisgICAgY29uc3QgY2hhciAqczsKKyAg
ICB1aW50MzJfdCBsZW5ndGg7CisKKyAgICBsZW5ndGggPSBzbWJpb3NfcGFzc3Rocm91Z2goU1BU
QVJHKHN0YXJ0LCAzKSk7CisgICAgaWYgKCBsZW5ndGggPiAwICkKKyAgICB7CisgICAgICAgIC8q
IEZpeCB1cCwgdXNlIGNvbnNpc3RlbnQgaGFuZGxlcyAqLworICAgICAgICBwLT5oZWFkZXIuaGFu
ZGxlID0gMHgzMDA7CisgICAgICAgIHJldHVybiAoc3RhcnQgKyBsZW5ndGgpOworICAgIH0KICAg
ICAKICAgICBtZW1zZXQocCwgMCwgc2l6ZW9mKCpwKSk7CiAKQEAgLTQwMyw5ICs1NzcsMjAgQEAK
ICAgICBwLT5zZWN1cml0eV9zdGF0dXMgPSAweDAyOyAvKiB1bmtub3duICovCiAKICAgICBzdGFy
dCArPSBzaXplb2Yoc3RydWN0IHNtYmlvc190eXBlXzMpOwotICAgIAotICAgIHN0cmNweSgoY2hh
ciAqKXN0YXJ0LCAiWGVuIik7Ci0gICAgc3RhcnQgKz0gc3RybGVuKCJYZW4iKSArIDE7CisKKyAg
ICBzID0geGVuc3RvcmVfcmVhZCgiYmlvcy1zdHJpbmdzL2VuY2xvc3VyZS1tYW51ZmFjdHVyZXIi
LCAiWGVuIik7CisgICAgc3RyY3B5KChjaGFyICopc3RhcnQsIHMpOworICAgIHN0YXJ0ICs9IHN0
cmxlbihzKSArIDE7CisKKyAgICAvKiBubyBpbnRlcm5hbCBkZWZhdWx0cyBmb3IgdGhpcyBpZiB0
aGUgdmFsdWUgaXMgbm90IHNldCAqLworICAgIHMgPSB4ZW5zdG9yZV9yZWFkKCJiaW9zLXN0cmlu
Z3MvZW5jbG9zdXJlLXNlcmlhbC1udW1iZXIiLCBOVUxMKTsKKyAgICBpZiAoIChzICE9IE5VTEwp
JiYoKnMgIT0gJ1wwJykgKQorICAgIHsKKyAgICAgICAgc3RyY3B5KChjaGFyICopc3RhcnQsIHMp
OworICAgICAgICBzdGFydCArPSBzdHJsZW4ocykgKyAxOyAgICAgICAgCisgICAgICAgIHAtPnNl
cmlhbF9udW1iZXJfc3RyID0gMjsKKyAgICB9CisKICAgICAqKCh1aW50OF90ICopc3RhcnQpID0g
MDsKICAgICByZXR1cm4gc3RhcnQrMTsKIH0KQEAgLTQ2OCw2ICs2NTMsMTUgQEAKICAgICBjaGFy
IHBhdGhbMjBdID0gImJpb3Mtc3RyaW5ncy9vZW0tWFgiOwogICAgIGNvbnN0IGNoYXIgKnM7CiAg
ICAgaW50IGk7CisgICAgdWludDMyX3QgbGVuZ3RoOworCisgICAgbGVuZ3RoID0gc21iaW9zX3Bh
c3N0aHJvdWdoKFNQVEFSRyhzdGFydCwgMTEpKTsKKyAgICBpZiAoIGxlbmd0aCA+IDAgKQorICAg
IHsKKyAgICAgICAgLyogRml4IHVwLCB1c2UgY29uc2lzdGVudCBoYW5kbGVzICovCisgICAgICAg
IHAtPmhlYWRlci5oYW5kbGUgPSAweEIwMDsKKyAgICAgICAgcmV0dXJuIChzdGFydCArIGxlbmd0
aCk7CisgICAgfQogCiAgICAgcC0+aGVhZGVyLnR5cGUgPSAxMTsKICAgICBwLT5oZWFkZXIubGVu
Z3RoID0gc2l6ZW9mKHN0cnVjdCBzbWJpb3NfdHlwZV8xMSk7CkBAIC02MDksNiArODAzLDYzIEBA
CiAgICAgcmV0dXJuIHN0YXJ0KzI7CiB9CiAKKy8qIFR5cGUgMjIgLS0gUG9ydGFibGUgQmF0dGVy
eSAqLworc3RhdGljIHZvaWQgKgorc21iaW9zX3R5cGVfMjJfaW5pdCh2b2lkICpzdGFydCkKK3sK
KyAgICBzdHJ1Y3Qgc21iaW9zX3R5cGVfMjIgKnAgPSAoc3RydWN0IHNtYmlvc190eXBlXzIyICop
c3RhcnQ7CisgICAgc3RhdGljIGNvbnN0IGNoYXIgKnNtYmlvc19yZWxlYXNlX2RhdGUgPSBfX1NN
QklPU19EQVRFX187CisgICAgdWludDMyX3QgbGVuZ3RoOworCisgICAgaWYgKCAoZ2V0X3NtYmlv
c19pbmZvX2ZsYWdzKCkgJiBIVk1fU01CSU9TX0lOQ0xVREVfUE9SVEFCTEVfQkFUVEVSWSkgPT0g
MCApCisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIGxlbmd0aCA9IHNtYmlvc19wYXNzdGhy
b3VnaChTUFRBUkcoc3RhcnQsIDIyKSk7CisgICAgaWYgKCBsZW5ndGggPiAwICkKKyAgICB7Cisg
ICAgICAgIC8qIEZpeCB1cCwgdXNlIGNvbnNpc3RlbnQgaGFuZGxlcyAqLworICAgICAgICBwLT5o
ZWFkZXIuaGFuZGxlID0gMHgxNjAwOworCisgICAgICAgIHJldHVybiAoc3RhcnQgKyBsZW5ndGgp
OworICAgIH0KKworICAgIG1lbXNldChwLCAwLCBzaXplb2YoKnApKTsKKworICAgIHAtPmhlYWRl
ci50eXBlID0gMjI7CisgICAgcC0+aGVhZGVyLmxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc21iaW9z
X3R5cGVfMjIpOworICAgIHAtPmhlYWRlci5oYW5kbGUgPSAweDE2MDA7CisKKyAgICBwLT5sb2Nh
dGlvbl9zdHIgPSAxOworICAgIHAtPm1hbnVmYWN0dXJlcl9zdHIgPSAyOworICAgIHAtPm1hbnVm
YWN0dXJlcl9kYXRlX3N0ciA9IDM7CisgICAgcC0+c2VyaWFsX251bWJlcl9zdHIgPSAwOworICAg
IHAtPmRldmljZV9uYW1lX3N0ciA9IDQ7CisgICAgcC0+ZGV2aWNlX2NoZW1pc3RyeSA9IDB4Mjsg
LyogVW5rbm93biAqLworICAgIHAtPmRldmljZV9jYXBhY2l0eSA9IDA7IC8qIFVua25vd24gKi8K
KyAgICBwLT5kZXZpY2Vfdm9sdGFnZSA9IDA7IC8qIFVua25vd24gKi8KKyAgICBwLT5zYmRzX3Zl
cnNpb25fbnVtYmVyID0gMDsKKyAgICBwLT5tYXhfZXJyb3IgPSAweGZmOyAvKiBVbmtub3duICov
CisgICAgcC0+c2Jkc19zZXJpYWxfbnVtYmVyID0gMDsKKyAgICBwLT5zYmRzX21hbnVmYWN0dXJl
cl9kYXRlID0gMDsKKyAgICBwLT5zYmRzX2RldmljZV9jaGVtaXN0cnkgPSAwOworICAgIHAtPmRl
c2lnbl9jYXBhY2l0eV9tdWx0aXBsaWVyID0gMDsKKyAgICBwLT5vZW1fc3BlY2lmaWMgPSAwOwor
CisgICAgc3RhcnQgKz0gc2l6ZW9mKHN0cnVjdCBzbWJpb3NfdHlwZV8yMik7CisKKyAgICBzdHJj
cHkoKGNoYXIgKilzdGFydCwgIlByaW1hcnkiKTsKKyAgICBzdGFydCArPSBzdHJsZW4oIlByaW1h
cnkiKSArIDE7CisgICAgc3RyY3B5KChjaGFyICopc3RhcnQsICJYZW4iKTsKKyAgICBzdGFydCAr
PSBzdHJsZW4oIlhlbiIpICsgMTsKKyAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgc21iaW9zX3Jl
bGVhc2VfZGF0ZSk7CisgICAgc3RhcnQgKz0gc3RybGVuKHNtYmlvc19yZWxlYXNlX2RhdGUpICsg
MTsKKyAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgIlhFTi1WQkFUIik7CisgICAgc3RhcnQgKz0g
c3RybGVuKCJYRU4tVkJBVCIpICsgMTsKKworICAgICooKHVpbnQ4X3QgKilzdGFydCkgPSAwOwor
ICAgIHJldHVybiBzdGFydCsxOyAKK30KKwogLyogVHlwZSAzMiAtLSBTeXN0ZW0gQm9vdCBJbmZv
cm1hdGlvbiAqLwogc3RhdGljIHZvaWQgKgogc21iaW9zX3R5cGVfMzJfaW5pdCh2b2lkICpzdGFy
dCkKQEAgLTYyOCw2ICs4NzksNzUgQEAKICAgICByZXR1cm4gc3RhcnQrMjsKIH0KIAorLyogVHlw
ZSAzOSAtLSBQb3dlciBTdXBwbHkgKi8KK3N0YXRpYyB2b2lkICoKK3NtYmlvc190eXBlXzM5X2lu
aXQodm9pZCAqc3RhcnQpCit7CisgICAgc3RydWN0IHNtYmlvc190eXBlXzM5ICpwID0gKHN0cnVj
dCBzbWJpb3NfdHlwZV8zOSAqKXN0YXJ0OworICAgIHVpbnQzMl90IGxlbmd0aDsKKworICAgIGlm
ICggKGdldF9zbWJpb3NfaW5mb19mbGFncygpICYgSFZNX1NNQklPU19JTkNMVURFX1BPV0VSX1NV
UFBMWSkgPT0gMCApCisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIC8qIE5vIGRlZmF1bHQg
dmFsdWVzIC0gb25seSBwcmVzZW50IGlmIHRoZSB0YWJsZSBpcyBwYXNzZWQgaW4gKi8KKyAgICBs
ZW5ndGggPSBzbWJpb3NfcGFzc3Rocm91Z2goU1BUQVJHKHN0YXJ0LCAzOSkpOworICAgIGlmICgg
bGVuZ3RoID09IDAgKQorICAgICAgICByZXR1cm4gc3RhcnQ7CisKKyAgICAvKiBGaXggdXAsIHVz
ZSBjb25zaXN0ZW50IGhhbmRsZXMgKi8KKyAgICBwLT5oZWFkZXIuaGFuZGxlID0gMHgyNzAwOwor
CisgICAgLyogVGhlc2UgZGV2aWNlcyBhcmUgbm90IHByZXNlbnQgKi8KKyAgICBwLT5pbnB1dF92
b2x0YWdlX3Byb2JlX2hhbmRsZSA9IDB4RkZGRjsKKyAgICBwLT5jb29saW5nX2RldmljZV9oYW5k
bGUgPSAweEZGRkY7CisgICAgcC0+aW5wdXRfY3VycmVudF9wcm9iZV9oYW5kbGUgPSAweEZGRkY7
CisKKyAgICByZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKK30KKworc3RhdGljIHZvaWQgKgorc21i
aW9zX3R5cGVfdmVuZG9yX29lbV9pbml0KHZvaWQgKnN0YXJ0KQoreworICAgIHN0cnVjdCBodm1f
c21iaW9zX2luZm9fdGFibGUgKnBhX3NtYnQ7CisgICAgc3RydWN0IGh2bV9zbWJpb3NfdGFibGVf
aGVhZGVyICpoZWFkZXI7CisgICAgdWludDMyX3QgY291bnQ7CisgICAgdWludDhfdCAqcHRyOyAg
ICAKKworICAgIHBhX3NtYnQgPSBnZXRfaHZtX3NtYmlvc19pbmZvX3RhYmxlKCk7CisgICAgaWYg
KCBwYV9zbWJ0ID09IE5VTEwgKQorICAgICAgICByZXR1cm4gc3RhcnQ7CisgICAgCisgICAgaWYg
KCAocGFfc21idC0+ZmxhZ3MgJiBIVk1fU01CSU9TX0lOQ0xVREVfVkVORE9SX09FTSkgPT0gMCAp
CisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIGhlYWRlciA9IChzdHJ1Y3QgaHZtX3NtYmlv
c190YWJsZV9oZWFkZXIqKQorICAgICAgICAoKHVpbnQ4X3QqKXBhX3NtYnQgKyBzaXplb2Yoc3Ry
dWN0IGh2bV9zbWJpb3NfaW5mb190YWJsZSkpOworCisgICAgZm9yICggY291bnQgPSAwOyBjb3Vu
dCA8IHBhX3NtYnQtPmNvdW50OyBjb3VudCsrICkKKyAgICB7CisgICAgICAgIGlmICggaGVhZGVy
LT5sZW5ndGggIT0gMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHB0ciA9ICgodWludDhfdCop
aGVhZGVyICsgc2l6ZW9mKHN0cnVjdCBodm1fc21iaW9zX3RhYmxlX2hlYWRlcikpOworICAgICAg
ICAgICAgaWYgKCBwdHJbMF0gPj0gU01CSU9TX1ZFTkRPUl9PRU1fVEFCTEVfTUlOICkKKyAgICAg
ICAgICAgIHsKKyAgICAgICAgICAgICAgICAvKiBWZW5kb3IvT0VNIHRhYmxlLCBjb3B5IGl0IGlu
LiBOb3RlIHRoZSBoYW5kbGUgdmFsdWVzIGNhbm5vdAorICAgICAgICAgICAgICAgICAgIGJlIGNo
YW5nZWQgc2luY2UgaXQgaXMgdW5rbm93biB3aGF0IGlzIGluIGVhY2ggb2YgdGhlc2UgdGFibGVz
CisgICAgICAgICAgICAgICAgICAgYnV0IHRoZXkgY291bGQgY29udGFpbiBoYW5kbGUgcmVmZXJl
bmNlcyB0byBvdGhlciB0YWJsZXMuIFRoaXMKKyAgICAgICAgICAgICAgICAgICBtZWFucyBhIHNs
aWdodCByaXNrIG9mIGNvbGxpc2lvbiB3aXRoIHRoZSB0YWJsZXMgYWJvdmUgYnV0IHRoYXQKKyAg
ICAgICAgICAgICAgICAgICB3b3VsZCBoYXZlIHRvIGJlIGRlYWx0IHdpdGggb24gYSBjYXNlIGJ5
IGNhc2UgYmFzaXMuICovCisgICAgICAgICAgICAgICAgbWVtY3B5KHN0YXJ0LCBwdHIsIGhlYWRl
ci0+bGVuZ3RoKTsKKyAgICAgICAgICAgICAgICBzdGFydCArPSBoZWFkZXItPmxlbmd0aDsKKyAg
ICAgICAgICAgIH0KKyAgICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICBwcmludGYo
IkVtcHR5IFNNQklPUyBPRU0gdGFibGUgcGFzc2VkIHRvIEhWTSBsb2FkZXIsIHNraXBwaW5nLiIp
OworCisgICAgICAgIGhlYWRlciA9IChzdHJ1Y3QgaHZtX3NtYmlvc190YWJsZV9oZWFkZXIqKShw
dHIgKyBoZWFkZXItPmxlbmd0aCk7CisgICAgfQorCisgICAgcmV0dXJuIHN0YXJ0OworfQorCiAv
KiBUeXBlIDEyNyAtLSBFbmQgb2YgVGFibGUgKi8KIHN0YXRpYyB2b2lkICoKIHNtYmlvc190eXBl
XzEyN19pbml0KHZvaWQgKnN0YXJ0KQpkaWZmIC1yIDA5MDBiMWM5MDVmMSB0b29scy9maXJtd2Fy
ZS9odm1sb2FkZXIvc21iaW9zX3R5cGVzLmgKLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L3NtYmlvc190eXBlcy5oCU1vbiBGZWIgMjAgMTg6NTg6MDcgMjAxMiArMDAwMAorKysgYi90b29s
cy9maXJtd2FyZS9odm1sb2FkZXIvc21iaW9zX3R5cGVzLmgJTW9uIEZlYiAyMCAyMDo1Njo1OCAy
MDEyIC0wNTAwCkBAIC0yOCw2ICsyOCw5IEBACiAKICNpbmNsdWRlIDxzdGRpbnQuaD4KIAorI2Rl
ZmluZSBTTUJJT1NfVkVORE9SX09FTV9UQUJMRV9NSU4gMTI4CisjZGVmaW5lIFNNQklPU19WRU5E
T1JfT0VNX1RBQkxFX01BWCAyNTUKKwogLyogU01CSU9TIGVudHJ5IHBvaW50IC0tIG11c3QgYmUg
d3JpdHRlbiB0byBhIDE2LWJpdCBhbGlnbmVkIGFkZHJlc3MKICAgIGJldHdlZW4gMHhmMDAwMCBh
bmQgMHhmZmZmZi4gCiAgKi8KQEAgLTg0LDYgKzg3LDE1IEBACiAgICAgdWludDhfdCBmYW1pbHlf
c3RyOwogfSBfX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7CiAKKy8qIFNNQklPUyB0eXBlIDIgLSBC
YXNlIEJvYXJkIEluZm9ybWF0aW9uICovCitzdHJ1Y3Qgc21iaW9zX3R5cGVfMiB7CisgICAgc3Ry
dWN0IHNtYmlvc19zdHJ1Y3R1cmVfaGVhZGVyIGhlYWRlcjsKKyAgICB1aW50OF90IG1hbnVmYWN0
dXJlcl9zdHI7CisgICAgdWludDhfdCBwcm9kdWN0X25hbWVfc3RyOworICAgIHVpbnQ4X3QgdmVy
c2lvbl9zdHI7CisgICAgdWludDhfdCBzZXJpYWxfbnVtYmVyX3N0cjsKK30gX19hdHRyaWJ1dGVf
XyAoKHBhY2tlZCkpOworCiAvKiBTTUJJT1MgdHlwZSAzIC0gU3lzdGVtIEVuY2xvc3VyZSAqLwog
c3RydWN0IHNtYmlvc190eXBlXzMgewogICAgIHN0cnVjdCBzbWJpb3Nfc3RydWN0dXJlX2hlYWRl
ciBoZWFkZXI7CkBAIC0xNzMsNiArMTg1LDI2IEBACiAgICAgdWludDhfdCBpbnRlcmxlYXZlZF9k
YXRhX2RlcHRoOwogfSBfX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7CiAKKy8qIFNNQklPUyB0eXBl
IDIyIC0gUG9ydGFibGUgYmF0dGVyeSAqLworc3RydWN0IHNtYmlvc190eXBlXzIyIHsKKyAgICBz
dHJ1Y3Qgc21iaW9zX3N0cnVjdHVyZV9oZWFkZXIgaGVhZGVyOworICAgIHVpbnQ4X3QgbG9jYXRp
b25fc3RyOworICAgIHVpbnQ4X3QgbWFudWZhY3R1cmVyX3N0cjsKKyAgICB1aW50OF90IG1hbnVm
YWN0dXJlcl9kYXRlX3N0cjsKKyAgICB1aW50OF90IHNlcmlhbF9udW1iZXJfc3RyOworICAgIHVp
bnQ4X3QgZGV2aWNlX25hbWVfc3RyOworICAgIHVpbnQ4X3QgZGV2aWNlX2NoZW1pc3RyeTsKKyAg
ICB1aW50MTZfdCBkZXZpY2VfY2FwYWNpdHk7CisgICAgdWludDE2X3QgZGV2aWNlX3ZvbHRhZ2U7
CisgICAgdWludDhfdCBzYmRzX3ZlcnNpb25fbnVtYmVyOworICAgIHVpbnQ4X3QgbWF4X2Vycm9y
OworICAgIHVpbnQxNl90IHNiZHNfc2VyaWFsX251bWJlcjsKKyAgICB1aW50MTZfdCBzYmRzX21h
bnVmYWN0dXJlcl9kYXRlOworICAgIHVpbnQ4X3Qgc2Jkc19kZXZpY2VfY2hlbWlzdHJ5OworICAg
IHVpbnQ4X3QgZGVzaWduX2NhcGFjaXR5X211bHRpcGxpZXI7CisgICAgdWludDMyX3Qgb2VtX3Nw
ZWNpZmljOworfSBfX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7CisKIC8qIFNNQklPUyB0eXBlIDMy
IC0gU3lzdGVtIEJvb3QgSW5mb3JtYXRpb24gKi8KIHN0cnVjdCBzbWJpb3NfdHlwZV8zMiB7CiAg
ICAgc3RydWN0IHNtYmlvc19zdHJ1Y3R1cmVfaGVhZGVyIGhlYWRlcjsKQEAgLTE4MCw2ICsyMTIs
MjQgQEAKICAgICB1aW50OF90IGJvb3Rfc3RhdHVzOwogfSBfX2F0dHJpYnV0ZV9fICgocGFja2Vk
KSk7CiAKKy8qIFNNQklPUyB0eXBlIDM5IC0gUG93ZXIgU3VwcGx5ICovCitzdHJ1Y3Qgc21iaW9z
X3R5cGVfMzkgeworICAgIHN0cnVjdCBzbWJpb3Nfc3RydWN0dXJlX2hlYWRlciBoZWFkZXI7Cisg
ICAgdWludDhfdCBwb3dlcl91bml0X2dyb3VwOworICAgIHVpbnQ4X3QgbG9jYXRpb25fc3RyOwor
ICAgIHVpbnQ4X3QgZGV2aWNlX25hbWVfc3RyOworICAgIHVpbnQ4X3QgbWFudWZhY3R1cmVyX3N0
cjsKKyAgICB1aW50OF90IHNlcmlhbF9udW1iZXJfc3RyOworICAgIHVpbnQ4X3QgYXNzZXRfdGFn
X251bWJlcl9zdHI7CisgICAgdWludDhfdCBtb2RlbF9wYXJ0X251bWJlcl9zdHI7CisgICAgdWlu
dDhfdCByZXZpc2lvbl9sZXZlbF9zdHI7CisgICAgdWludDE2X3QgbWF4X2NhcGFjaXR5OworICAg
IHVpbnQxNl90IGNoYXJhY3RlcmlzdGljczsKKyAgICB1aW50MTZfdCBpbnB1dF92b2x0YWdlX3By
b2JlX2hhbmRsZTsKKyAgICB1aW50MTZfdCBjb29saW5nX2RldmljZV9oYW5kbGU7CisgICAgdWlu
dDE2X3QgaW5wdXRfY3VycmVudF9wcm9iZV9oYW5kbGU7Cit9IF9fYXR0cmlidXRlX18gKChwYWNr
ZWQpKTsKKwogLyogU01CSU9TIHR5cGUgMTI3IC0tIEVuZC1vZi10YWJsZSAqLwogc3RydWN0IHNt
Ymlvc190eXBlXzEyNyB7CiAgICAgc3RydWN0IHNtYmlvc19zdHJ1Y3R1cmVfaGVhZGVyIGhlYWRl
cjsK

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzfub-0004v2-CA; Tue, 21 Feb 2012 02:57:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuZ-0004uZ-30
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:57:03 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329792949!61873016!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIyMzQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19724 invoked from network); 21 Feb 2012 02:55:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="22272202"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:57:00 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Mon, 20 Feb 2012
	21:57:00 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:59 -0500
Thread-Topic: [PATCH 3/3] SMBIOS table passthrough support
Thread-Index: AczwQNrTPDyk+eCeRFm95p9AJHNqKQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323DA@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SMBIOS tables are written into the HVM parameter and information page. The =
SMBIOS tables would normally come from system firmware where they are writt=
en by the xen toolstack. In general though, there is no limitation on where=
 the tables come from other than their following the DMTF standards. In the=
 SMBIOS building code in hvmloader, passed in tables are searched for and t=
ake precedence over default values when found.

Three new tables were added (types 2, 22 and 39) but are disabled by defaul=
t. A set of flags is used to specify inclusion of new tables so that the ex=
isting default set is preserved. In addition to the pre-defined table types=
, OEM specific tables (types 128 - 255) can also be written in. Any number =
of OEM tables can be passed in and will be surfaced in the HVM SMBIOS.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_
Content-Type: application/octet-stream; name="smbios-passthrough-03.patch"
Content-Description: smbios-passthrough-03.patch
Content-Disposition: attachment; filename="smbios-passthrough-03.patch";
	size=14595; creation-date="Tue, 21 Feb 2012 01:56:15 GMT";
	modification-date="Tue, 21 Feb 2012 01:56:15 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAwOTAwYjFjOTA1ZjEgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3NtYmlvcy5jCi0t
LSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9zbWJpb3MuYwlNb24gRmViIDIwIDE4OjU4OjA3
IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3NtYmlvcy5jCU1vbiBG
ZWIgMjAgMjA6NTY6NTggMjAxMiAtMDUwMApAQCAtNDksNiArNDksOCBAQAogc21iaW9zX3R5cGVf
MV9pbml0KHZvaWQgKnN0YXJ0LCBjb25zdCBjaGFyICp4ZW5fdmVyc2lvbiwgCiAgICAgICAgICAg
ICAgICAgICAgdWludDhfdCB1dWlkWzE2XSk7CiBzdGF0aWMgdm9pZCAqCitzbWJpb3NfdHlwZV8y
X2luaXQodm9pZCAqc3RhcnQpOworc3RhdGljIHZvaWQgKgogc21iaW9zX3R5cGVfM19pbml0KHZv
aWQgKnN0YXJ0KTsKIHN0YXRpYyB2b2lkICoKIHNtYmlvc190eXBlXzRfaW5pdCh2b2lkICpzdGFy
dCwgdW5zaWduZWQgaW50IGNwdV9udW1iZXIsCkBAIC02NCw4ICs2NiwxNCBAQAogc3RhdGljIHZv
aWQgKgogc21iaW9zX3R5cGVfMjBfaW5pdCh2b2lkICpzdGFydCwgdWludDMyX3QgbWVtb3J5X3Np
emVfbWIsIGludCBpbnN0YW5jZSk7CiBzdGF0aWMgdm9pZCAqCitzbWJpb3NfdHlwZV8yMl9pbml0
KHZvaWQgKnN0YXJ0KTsKK3N0YXRpYyB2b2lkICoKIHNtYmlvc190eXBlXzMyX2luaXQodm9pZCAq
c3RhcnQpOwogc3RhdGljIHZvaWQgKgorc21iaW9zX3R5cGVfMzlfaW5pdCh2b2lkICpzdGFydCk7
CitzdGF0aWMgdm9pZCAqCitzbWJpb3NfdHlwZV92ZW5kb3Jfb2VtX2luaXQodm9pZCAqc3RhcnQp
Oworc3RhdGljIHZvaWQgKgogc21iaW9zX3R5cGVfMTI3X2luaXQodm9pZCAqc3RhcnQpOwogCiBz
dGF0aWMgdm9pZApAQCAtODUsNiArOTMsNzcgQEAKICAgICAgICAgc3RybmNweShidWYsICJ1bmtu
b3duIiwgbGVuKTsKIH0KIAorc3RhdGljIHN0cnVjdCBodm1fc21iaW9zX3RhYmxlX2hlYWRlciAq
CitnZXRfc21iaW9zX2luZm9fYnlfdHlwZShzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpw
YV9zbWJ0LCB1aW50OF90IHR5cGUpCit7CisgICAgc3RydWN0IGh2bV9zbWJpb3NfdGFibGVfaGVh
ZGVyICpoZWFkZXI7CisgICAgdWludDMyX3QgY291bnQ7CisgICAgdWludDhfdCAqcHRyOworCisg
ICAgaGVhZGVyID0gKHN0cnVjdCBodm1fc21iaW9zX3RhYmxlX2hlYWRlciopCisgICAgICAgICgo
dWludDhfdCopcGFfc21idCArIHNpemVvZihzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlKSk7
CisKKyAgICBmb3IgKCBjb3VudCA9IDA7IGNvdW50IDwgcGFfc21idC0+Y291bnQ7IGNvdW50Kysg
KQorICAgIHsKKyAgICAgICAgaWYgKCAoaGVhZGVyLT5sZW5ndGggPiAwKSYmKGhlYWRlci0+bGVu
Z3RoIDwgSFZNX1NNQklPU19JTkZPX01BWCkgKQorICAgICAgICB7CisgICAgICAgICAgICBwdHIg
PSAoKHVpbnQ4X3QqKWhlYWRlciArIHNpemVvZihzdHJ1Y3QgaHZtX3NtYmlvc190YWJsZV9oZWFk
ZXIpKTsKKyAgICAgICAgICAgIGlmICggcHRyWzBdID09IHR5cGUgKQorICAgICAgICAgICAgICAg
IHJldHVybiBoZWFkZXI7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICB7CisgICAg
ICAgICAgICBwcmludGYoIlNNQklPUyB0YWJsZSBpbnZhbGlkIGxlbmd0aDogJWQsIGFib3J0aW5n
LiIsCisgICAgICAgICAgICAgICAgICAgKGludCloZWFkZXItPmxlbmd0aCk7CisgICAgICAgICAg
ICByZXR1cm4gTlVMTDsKKyAgICAgICAgfQorCisgICAgICAgIGhlYWRlciA9IChzdHJ1Y3QgaHZt
X3NtYmlvc190YWJsZV9oZWFkZXIqKShwdHIgKyBoZWFkZXItPmxlbmd0aCk7CisgICAgfQorCisg
ICAgcmV0dXJuIE5VTEw7Cit9CisKKyNkZWZpbmUgU1BUQVJHKHMsIHQpIHMsIHQsIHNpemVvZihz
dHJ1Y3Qgc21iaW9zX3R5cGVfIyN0KQorc3RhdGljIHVpbnQzMl90CitzbWJpb3NfcGFzc3Rocm91
Z2godm9pZCAqc3RhcnQsIHVpbnQ4X3QgdGFibGUsIHVpbnQzMl90IHN0c2l6ZSkKK3sKKyAgICBz
dHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpwYV9zbWJ0OworICAgIHN0cnVjdCBodm1fc21i
aW9zX3RhYmxlX2hlYWRlciAqaGVhZGVyOworCisgICAgcGFfc21idCA9IGdldF9odm1fc21iaW9z
X2luZm9fdGFibGUoKTsKKyAgICBpZiAoIHBhX3NtYnQgPT0gTlVMTCApCisgICAgICAgIHJldHVy
biAwOworCisgICAgaGVhZGVyID0gZ2V0X3NtYmlvc19pbmZvX2J5X3R5cGUocGFfc21idCwgdGFi
bGUpOworICAgIGlmICggaGVhZGVyID09IE5VTEwgKQorICAgICAgICByZXR1cm4gMDsKKworICAg
IGlmICggaGVhZGVyLT5sZW5ndGggPCBzdHNpemUgKQorICAgIHsKKyAgICAgICAgcHJpbnRmKCJT
TUJJT1MgdGFibGUgbGVuZ3RoIGxlc3MgdGhhbiBmaXhlZCBtaW5pbXVtIGxlbmd0aCwgc2tpcHBp
bmcuIik7CisgICAgICAgIHJldHVybiAwOworICAgIH0KKworICAgIG1lbWNweShzdGFydCwKKyAg
ICAgICAgICAgKCh1aW50OF90KiloZWFkZXIgKyBzaXplb2Yoc3RydWN0IGh2bV9zbWJpb3NfdGFi
bGVfaGVhZGVyKSksCisgICAgICAgICAgIGhlYWRlci0+bGVuZ3RoKTsKKworICAgIHJldHVybiBo
ZWFkZXItPmxlbmd0aDsKK30KKworc3RhdGljIHVpbnQzMl90CitnZXRfc21iaW9zX2luZm9fZmxh
Z3Modm9pZCkKK3sKKyAgICBzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpwYV9zbWJ0Owor
CisgICAgcGFfc21idCA9IGdldF9odm1fc21iaW9zX2luZm9fdGFibGUoKTsKKyAgICBpZiAoIHBh
X3NtYnQgIT0gTlVMTCApCisgICAgICAgIHJldHVybiBwYV9zbWJ0LT5mbGFnczsKKworICAgIHJl
dHVybiAwOworfQorCiBzdGF0aWMgaW50CiB3cml0ZV9zbWJpb3NfdGFibGVzKHZvaWQgKmVwLCB2
b2lkICpzdGFydCwKICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgdmNwdXMsIHVpbnQ2NF90
IG1lbXNpemUsCkBAIC0xMTIsNiArMTkxLDcgQEAKICAgICBkb19zdHJ1Y3Qoc21iaW9zX3R5cGVf
MF9pbml0KHAsIHhlbl92ZXJzaW9uLCB4ZW5fbWFqb3JfdmVyc2lvbiwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHhlbl9taW5vcl92ZXJzaW9uKSk7CiAgICAgZG9fc3RydWN0KHNt
Ymlvc190eXBlXzFfaW5pdChwLCB4ZW5fdmVyc2lvbiwgdXVpZCkpOworICAgIGRvX3N0cnVjdChz
bWJpb3NfdHlwZV8yX2luaXQocCkpOwogICAgIGRvX3N0cnVjdChzbWJpb3NfdHlwZV8zX2luaXQo
cCkpOwogICAgIGZvciAoIGNwdV9udW0gPSAxOyBjcHVfbnVtIDw9IHZjcHVzOyBjcHVfbnVtKysg
KQogICAgICAgICBkb19zdHJ1Y3Qoc21iaW9zX3R5cGVfNF9pbml0KHAsIGNwdV9udW0sIGNwdV9t
YW51ZmFjdHVyZXIpKTsKQEAgLTEzMCw3ICsyMTAsMTAgQEAKICAgICAgICAgZG9fc3RydWN0KHNt
Ymlvc190eXBlXzIwX2luaXQocCwgZGV2X21lbXNpemUsIGkpKTsKICAgICB9CiAKKyAgICBkb19z
dHJ1Y3Qoc21iaW9zX3R5cGVfMjJfaW5pdChwKSk7CiAgICAgZG9fc3RydWN0KHNtYmlvc190eXBl
XzMyX2luaXQocCkpOworICAgIGRvX3N0cnVjdChzbWJpb3NfdHlwZV8zOV9pbml0KHApKTsKKyAg
ICBkb19zdHJ1Y3Qoc21iaW9zX3R5cGVfdmVuZG9yX29lbV9pbml0KHApKTsKICAgICBkb19zdHJ1
Y3Qoc21iaW9zX3R5cGVfMTI3X2luaXQocCkpOwogCiAjdW5kZWYgZG9fc3RydWN0CkBAIC0yODks
NiArMzcyLDE1IEBACiAgICAgc3RydWN0IHNtYmlvc190eXBlXzAgKnAgPSAoc3RydWN0IHNtYmlv
c190eXBlXzAgKilzdGFydDsKICAgICBzdGF0aWMgY29uc3QgY2hhciAqc21iaW9zX3JlbGVhc2Vf
ZGF0ZSA9IF9fU01CSU9TX0RBVEVfXzsKICAgICBjb25zdCBjaGFyICpzOworICAgIHVpbnQzMl90
IGxlbmd0aDsKKworICAgIGxlbmd0aCA9IHNtYmlvc19wYXNzdGhyb3VnaChTUFRBUkcoc3RhcnQs
IDApKTsKKyAgICBpZiAoIGxlbmd0aCA+IDAgKQorICAgIHsKKyAgICAgICAgLyogRml4IHVwLCB1
c2UgY29uc2lzdGVudCBoYW5kbGVzICovCisgICAgICAgIHAtPmhlYWRlci5oYW5kbGUgPSAwOwor
ICAgICAgICByZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKKyAgICB9CiAKICAgICBtZW1zZXQocCwg
MCwgc2l6ZW9mKCpwKSk7CiAKQEAgLTMzOCw2ICs0MzAsMTUgQEAKICAgICBjaGFyIHV1aWRfc3Ry
WzM3XTsKICAgICBzdHJ1Y3Qgc21iaW9zX3R5cGVfMSAqcCA9IChzdHJ1Y3Qgc21iaW9zX3R5cGVf
MSAqKXN0YXJ0OwogICAgIGNvbnN0IGNoYXIgKnM7CisgICAgdWludDMyX3QgbGVuZ3RoOworCisg
ICAgbGVuZ3RoID0gc21iaW9zX3Bhc3N0aHJvdWdoKFNQVEFSRyhzdGFydCwgMSkpOworICAgIGlm
ICggbGVuZ3RoID4gMCApCisgICAgeworICAgICAgICAvKiBGaXggdXAsIHVzZSBjb25zaXN0ZW50
IGhhbmRsZXMgKi8KKyAgICAgICAgcC0+aGVhZGVyLmhhbmRsZSA9IDB4MTAwOworICAgICAgICBy
ZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKKyAgICB9CiAKICAgICBtZW1zZXQocCwgMCwgc2l6ZW9m
KCpwKSk7CiAKQEAgLTM3NiwxNSArNDc3LDg4IEBACiAgICAgc3RhcnQgKz0gc3RybGVuKHMpICsg
MTsKIAogICAgICooKHVpbnQ4X3QgKilzdGFydCkgPSAwOwotICAgIAogICAgIHJldHVybiBzdGFy
dCsxOyAKIH0KIAorLyogVHlwZSAyIC0tIFN5c3RlbSBCb2FyZCAqLworc3RhdGljIHZvaWQgKgor
c21iaW9zX3R5cGVfMl9pbml0KHZvaWQgKnN0YXJ0KQoreworICAgIHN0cnVjdCBzbWJpb3NfdHlw
ZV8yICpwID0gKHN0cnVjdCBzbWJpb3NfdHlwZV8yICopc3RhcnQ7CisgICAgdWludDhfdCAqYnB0
cjsKKyAgICBjb25zdCBjaGFyICpzOworICAgIHVpbnQzMl90IGxlbmd0aDsKKworICAgIGlmICgg
KGdldF9zbWJpb3NfaW5mb19mbGFncygpICYgSFZNX1NNQklPU19JTkNMVURFX1NZU1RFTV9CT0FS
RCkgPT0gMCApCisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIGxlbmd0aCA9IHNtYmlvc19w
YXNzdGhyb3VnaChTUFRBUkcoc3RhcnQsIDIpKTsKKyAgICBpZiAoIGxlbmd0aCA+IDAgKQorICAg
IHsKKyAgICAgICAgLyogRml4IHVwLCB1c2UgY29uc2lzdGVudCBoYW5kbGVzLCBzZXQgY2hhc3Np
cyBoYW5kbGUgKi8KKyAgICAgICAgcC0+aGVhZGVyLmhhbmRsZSA9IDB4MjAwOworCisgICAgICAg
IC8qIE5PVEU6IGlmIHRoaXMgY29kZSBpcyBlbmhhbmNlZCB0byBhbGxvdyBtdWx0aXBsZSBpbnN0
YW5jZXMgb2Ygc29tZSB0YWJsZXMgbGlrZQorICAgICAgICAgICB0aGlzIG9uZSwgY2hhc3NpcyBp
bmZvLCBldGMuIHRoZW4gd29yayB3aWxsIGhhdmUgdG8gYmUgZG9uZSB0byBtYXRjaCB0aGVzZSBo
YW5kbGVzICovCisgICAgICAgIGlmICggcC0+aGVhZGVyLmxlbmd0aCA+PSAxMyApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGJwdHIgPSAoKHVpbnQ4X3QqKXN0YXJ0KSArIDExOworICAgICAgICAg
ICAgaWYgKCooKHVpbnQxNl90KilicHRyKSAhPSAwKQorICAgICAgICAgICAgICAgICooKHVpbnQx
Nl90KilicHRyKSA9IDB4MzAwOyAvKiBjdXJyZW50IGNoYXNzaXMgaGFuZGxlICovCisgICAgICAg
IH0KKworICAgICAgICByZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKKyAgICB9CisKKyAgICBtZW1z
ZXQocCwgMCwgc2l6ZW9mKCpwKSk7CisKKyAgICBwLT5oZWFkZXIudHlwZSA9IDI7CisgICAgcC0+
aGVhZGVyLmxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc21iaW9zX3R5cGVfMik7CisgICAgcC0+aGVh
ZGVyLmhhbmRsZSA9IDB4MjAwOworCisgICAgcC0+bWFudWZhY3R1cmVyX3N0ciA9IDE7CisgICAg
cC0+cHJvZHVjdF9uYW1lX3N0ciA9IDI7CisgICAgcC0+dmVyc2lvbl9zdHIgPSAwOworICAgIHAt
PnNlcmlhbF9udW1iZXJfc3RyID0gMDsKKworICAgIHN0YXJ0ICs9IHNpemVvZihzdHJ1Y3Qgc21i
aW9zX3R5cGVfMik7CisKKyAgICBzID0geGVuc3RvcmVfcmVhZCgiYmlvcy1zdHJpbmdzL2JvYXJk
LW1hbnVmYWN0dXJlciIsICJYZW4iKTsKKyAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgcyk7Cisg
ICAgc3RhcnQgKz0gc3RybGVuKHMpICsgMTsKKworICAgIHMgPSB4ZW5zdG9yZV9yZWFkKCJiaW9z
LXN0cmluZ3MvYm9hcmQtcHJvZHVjdC1uYW1lIiwgIkhWTSBkb21VIik7CisgICAgc3RyY3B5KChj
aGFyICopc3RhcnQsIHMpOworICAgIHN0YXJ0ICs9IHN0cmxlbihzKSArIDE7CisKKyAgICAvKiBu
byBpbnRlcm5hbCBkZWZhdWx0cyBmb3IgdGhpcyBpZiB0aGUgdmFsdWUgaXMgbm90IHNldCAqLwor
ICAgIHMgPSB4ZW5zdG9yZV9yZWFkKCJiaW9zLXN0cmluZ3MvYm9hcmQtc2VyaWFsLW51bWJlciIs
IE5VTEwpOworICAgIGlmICggKHMgIT0gTlVMTCkmJigqcyAhPSAnXDAnKSApCisgICAgeworICAg
ICAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgcyk7CisgICAgICAgIHN0YXJ0ICs9IHN0cmxlbihz
KSArIDE7ICAgICAgICAKKyAgICAgICAgcC0+c2VyaWFsX251bWJlcl9zdHIgPSAzOworICAgIH0K
KworICAgICooKHVpbnQ4X3QgKilzdGFydCkgPSAwOworICAgIHJldHVybiBzdGFydCsxOworfQor
CiAvKiBUeXBlIDMgLS0gU3lzdGVtIEVuY2xvc3VyZSAqLwogc3RhdGljIHZvaWQgKgogc21iaW9z
X3R5cGVfM19pbml0KHZvaWQgKnN0YXJ0KQogewogICAgIHN0cnVjdCBzbWJpb3NfdHlwZV8zICpw
ID0gKHN0cnVjdCBzbWJpb3NfdHlwZV8zICopc3RhcnQ7CisgICAgY29uc3QgY2hhciAqczsKKyAg
ICB1aW50MzJfdCBsZW5ndGg7CisKKyAgICBsZW5ndGggPSBzbWJpb3NfcGFzc3Rocm91Z2goU1BU
QVJHKHN0YXJ0LCAzKSk7CisgICAgaWYgKCBsZW5ndGggPiAwICkKKyAgICB7CisgICAgICAgIC8q
IEZpeCB1cCwgdXNlIGNvbnNpc3RlbnQgaGFuZGxlcyAqLworICAgICAgICBwLT5oZWFkZXIuaGFu
ZGxlID0gMHgzMDA7CisgICAgICAgIHJldHVybiAoc3RhcnQgKyBsZW5ndGgpOworICAgIH0KICAg
ICAKICAgICBtZW1zZXQocCwgMCwgc2l6ZW9mKCpwKSk7CiAKQEAgLTQwMyw5ICs1NzcsMjAgQEAK
ICAgICBwLT5zZWN1cml0eV9zdGF0dXMgPSAweDAyOyAvKiB1bmtub3duICovCiAKICAgICBzdGFy
dCArPSBzaXplb2Yoc3RydWN0IHNtYmlvc190eXBlXzMpOwotICAgIAotICAgIHN0cmNweSgoY2hh
ciAqKXN0YXJ0LCAiWGVuIik7Ci0gICAgc3RhcnQgKz0gc3RybGVuKCJYZW4iKSArIDE7CisKKyAg
ICBzID0geGVuc3RvcmVfcmVhZCgiYmlvcy1zdHJpbmdzL2VuY2xvc3VyZS1tYW51ZmFjdHVyZXIi
LCAiWGVuIik7CisgICAgc3RyY3B5KChjaGFyICopc3RhcnQsIHMpOworICAgIHN0YXJ0ICs9IHN0
cmxlbihzKSArIDE7CisKKyAgICAvKiBubyBpbnRlcm5hbCBkZWZhdWx0cyBmb3IgdGhpcyBpZiB0
aGUgdmFsdWUgaXMgbm90IHNldCAqLworICAgIHMgPSB4ZW5zdG9yZV9yZWFkKCJiaW9zLXN0cmlu
Z3MvZW5jbG9zdXJlLXNlcmlhbC1udW1iZXIiLCBOVUxMKTsKKyAgICBpZiAoIChzICE9IE5VTEwp
JiYoKnMgIT0gJ1wwJykgKQorICAgIHsKKyAgICAgICAgc3RyY3B5KChjaGFyICopc3RhcnQsIHMp
OworICAgICAgICBzdGFydCArPSBzdHJsZW4ocykgKyAxOyAgICAgICAgCisgICAgICAgIHAtPnNl
cmlhbF9udW1iZXJfc3RyID0gMjsKKyAgICB9CisKICAgICAqKCh1aW50OF90ICopc3RhcnQpID0g
MDsKICAgICByZXR1cm4gc3RhcnQrMTsKIH0KQEAgLTQ2OCw2ICs2NTMsMTUgQEAKICAgICBjaGFy
IHBhdGhbMjBdID0gImJpb3Mtc3RyaW5ncy9vZW0tWFgiOwogICAgIGNvbnN0IGNoYXIgKnM7CiAg
ICAgaW50IGk7CisgICAgdWludDMyX3QgbGVuZ3RoOworCisgICAgbGVuZ3RoID0gc21iaW9zX3Bh
c3N0aHJvdWdoKFNQVEFSRyhzdGFydCwgMTEpKTsKKyAgICBpZiAoIGxlbmd0aCA+IDAgKQorICAg
IHsKKyAgICAgICAgLyogRml4IHVwLCB1c2UgY29uc2lzdGVudCBoYW5kbGVzICovCisgICAgICAg
IHAtPmhlYWRlci5oYW5kbGUgPSAweEIwMDsKKyAgICAgICAgcmV0dXJuIChzdGFydCArIGxlbmd0
aCk7CisgICAgfQogCiAgICAgcC0+aGVhZGVyLnR5cGUgPSAxMTsKICAgICBwLT5oZWFkZXIubGVu
Z3RoID0gc2l6ZW9mKHN0cnVjdCBzbWJpb3NfdHlwZV8xMSk7CkBAIC02MDksNiArODAzLDYzIEBA
CiAgICAgcmV0dXJuIHN0YXJ0KzI7CiB9CiAKKy8qIFR5cGUgMjIgLS0gUG9ydGFibGUgQmF0dGVy
eSAqLworc3RhdGljIHZvaWQgKgorc21iaW9zX3R5cGVfMjJfaW5pdCh2b2lkICpzdGFydCkKK3sK
KyAgICBzdHJ1Y3Qgc21iaW9zX3R5cGVfMjIgKnAgPSAoc3RydWN0IHNtYmlvc190eXBlXzIyICop
c3RhcnQ7CisgICAgc3RhdGljIGNvbnN0IGNoYXIgKnNtYmlvc19yZWxlYXNlX2RhdGUgPSBfX1NN
QklPU19EQVRFX187CisgICAgdWludDMyX3QgbGVuZ3RoOworCisgICAgaWYgKCAoZ2V0X3NtYmlv
c19pbmZvX2ZsYWdzKCkgJiBIVk1fU01CSU9TX0lOQ0xVREVfUE9SVEFCTEVfQkFUVEVSWSkgPT0g
MCApCisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIGxlbmd0aCA9IHNtYmlvc19wYXNzdGhy
b3VnaChTUFRBUkcoc3RhcnQsIDIyKSk7CisgICAgaWYgKCBsZW5ndGggPiAwICkKKyAgICB7Cisg
ICAgICAgIC8qIEZpeCB1cCwgdXNlIGNvbnNpc3RlbnQgaGFuZGxlcyAqLworICAgICAgICBwLT5o
ZWFkZXIuaGFuZGxlID0gMHgxNjAwOworCisgICAgICAgIHJldHVybiAoc3RhcnQgKyBsZW5ndGgp
OworICAgIH0KKworICAgIG1lbXNldChwLCAwLCBzaXplb2YoKnApKTsKKworICAgIHAtPmhlYWRl
ci50eXBlID0gMjI7CisgICAgcC0+aGVhZGVyLmxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc21iaW9z
X3R5cGVfMjIpOworICAgIHAtPmhlYWRlci5oYW5kbGUgPSAweDE2MDA7CisKKyAgICBwLT5sb2Nh
dGlvbl9zdHIgPSAxOworICAgIHAtPm1hbnVmYWN0dXJlcl9zdHIgPSAyOworICAgIHAtPm1hbnVm
YWN0dXJlcl9kYXRlX3N0ciA9IDM7CisgICAgcC0+c2VyaWFsX251bWJlcl9zdHIgPSAwOworICAg
IHAtPmRldmljZV9uYW1lX3N0ciA9IDQ7CisgICAgcC0+ZGV2aWNlX2NoZW1pc3RyeSA9IDB4Mjsg
LyogVW5rbm93biAqLworICAgIHAtPmRldmljZV9jYXBhY2l0eSA9IDA7IC8qIFVua25vd24gKi8K
KyAgICBwLT5kZXZpY2Vfdm9sdGFnZSA9IDA7IC8qIFVua25vd24gKi8KKyAgICBwLT5zYmRzX3Zl
cnNpb25fbnVtYmVyID0gMDsKKyAgICBwLT5tYXhfZXJyb3IgPSAweGZmOyAvKiBVbmtub3duICov
CisgICAgcC0+c2Jkc19zZXJpYWxfbnVtYmVyID0gMDsKKyAgICBwLT5zYmRzX21hbnVmYWN0dXJl
cl9kYXRlID0gMDsKKyAgICBwLT5zYmRzX2RldmljZV9jaGVtaXN0cnkgPSAwOworICAgIHAtPmRl
c2lnbl9jYXBhY2l0eV9tdWx0aXBsaWVyID0gMDsKKyAgICBwLT5vZW1fc3BlY2lmaWMgPSAwOwor
CisgICAgc3RhcnQgKz0gc2l6ZW9mKHN0cnVjdCBzbWJpb3NfdHlwZV8yMik7CisKKyAgICBzdHJj
cHkoKGNoYXIgKilzdGFydCwgIlByaW1hcnkiKTsKKyAgICBzdGFydCArPSBzdHJsZW4oIlByaW1h
cnkiKSArIDE7CisgICAgc3RyY3B5KChjaGFyICopc3RhcnQsICJYZW4iKTsKKyAgICBzdGFydCAr
PSBzdHJsZW4oIlhlbiIpICsgMTsKKyAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgc21iaW9zX3Jl
bGVhc2VfZGF0ZSk7CisgICAgc3RhcnQgKz0gc3RybGVuKHNtYmlvc19yZWxlYXNlX2RhdGUpICsg
MTsKKyAgICBzdHJjcHkoKGNoYXIgKilzdGFydCwgIlhFTi1WQkFUIik7CisgICAgc3RhcnQgKz0g
c3RybGVuKCJYRU4tVkJBVCIpICsgMTsKKworICAgICooKHVpbnQ4X3QgKilzdGFydCkgPSAwOwor
ICAgIHJldHVybiBzdGFydCsxOyAKK30KKwogLyogVHlwZSAzMiAtLSBTeXN0ZW0gQm9vdCBJbmZv
cm1hdGlvbiAqLwogc3RhdGljIHZvaWQgKgogc21iaW9zX3R5cGVfMzJfaW5pdCh2b2lkICpzdGFy
dCkKQEAgLTYyOCw2ICs4NzksNzUgQEAKICAgICByZXR1cm4gc3RhcnQrMjsKIH0KIAorLyogVHlw
ZSAzOSAtLSBQb3dlciBTdXBwbHkgKi8KK3N0YXRpYyB2b2lkICoKK3NtYmlvc190eXBlXzM5X2lu
aXQodm9pZCAqc3RhcnQpCit7CisgICAgc3RydWN0IHNtYmlvc190eXBlXzM5ICpwID0gKHN0cnVj
dCBzbWJpb3NfdHlwZV8zOSAqKXN0YXJ0OworICAgIHVpbnQzMl90IGxlbmd0aDsKKworICAgIGlm
ICggKGdldF9zbWJpb3NfaW5mb19mbGFncygpICYgSFZNX1NNQklPU19JTkNMVURFX1BPV0VSX1NV
UFBMWSkgPT0gMCApCisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIC8qIE5vIGRlZmF1bHQg
dmFsdWVzIC0gb25seSBwcmVzZW50IGlmIHRoZSB0YWJsZSBpcyBwYXNzZWQgaW4gKi8KKyAgICBs
ZW5ndGggPSBzbWJpb3NfcGFzc3Rocm91Z2goU1BUQVJHKHN0YXJ0LCAzOSkpOworICAgIGlmICgg
bGVuZ3RoID09IDAgKQorICAgICAgICByZXR1cm4gc3RhcnQ7CisKKyAgICAvKiBGaXggdXAsIHVz
ZSBjb25zaXN0ZW50IGhhbmRsZXMgKi8KKyAgICBwLT5oZWFkZXIuaGFuZGxlID0gMHgyNzAwOwor
CisgICAgLyogVGhlc2UgZGV2aWNlcyBhcmUgbm90IHByZXNlbnQgKi8KKyAgICBwLT5pbnB1dF92
b2x0YWdlX3Byb2JlX2hhbmRsZSA9IDB4RkZGRjsKKyAgICBwLT5jb29saW5nX2RldmljZV9oYW5k
bGUgPSAweEZGRkY7CisgICAgcC0+aW5wdXRfY3VycmVudF9wcm9iZV9oYW5kbGUgPSAweEZGRkY7
CisKKyAgICByZXR1cm4gKHN0YXJ0ICsgbGVuZ3RoKTsKK30KKworc3RhdGljIHZvaWQgKgorc21i
aW9zX3R5cGVfdmVuZG9yX29lbV9pbml0KHZvaWQgKnN0YXJ0KQoreworICAgIHN0cnVjdCBodm1f
c21iaW9zX2luZm9fdGFibGUgKnBhX3NtYnQ7CisgICAgc3RydWN0IGh2bV9zbWJpb3NfdGFibGVf
aGVhZGVyICpoZWFkZXI7CisgICAgdWludDMyX3QgY291bnQ7CisgICAgdWludDhfdCAqcHRyOyAg
ICAKKworICAgIHBhX3NtYnQgPSBnZXRfaHZtX3NtYmlvc19pbmZvX3RhYmxlKCk7CisgICAgaWYg
KCBwYV9zbWJ0ID09IE5VTEwgKQorICAgICAgICByZXR1cm4gc3RhcnQ7CisgICAgCisgICAgaWYg
KCAocGFfc21idC0+ZmxhZ3MgJiBIVk1fU01CSU9TX0lOQ0xVREVfVkVORE9SX09FTSkgPT0gMCAp
CisgICAgICAgIHJldHVybiBzdGFydDsKKworICAgIGhlYWRlciA9IChzdHJ1Y3QgaHZtX3NtYmlv
c190YWJsZV9oZWFkZXIqKQorICAgICAgICAoKHVpbnQ4X3QqKXBhX3NtYnQgKyBzaXplb2Yoc3Ry
dWN0IGh2bV9zbWJpb3NfaW5mb190YWJsZSkpOworCisgICAgZm9yICggY291bnQgPSAwOyBjb3Vu
dCA8IHBhX3NtYnQtPmNvdW50OyBjb3VudCsrICkKKyAgICB7CisgICAgICAgIGlmICggaGVhZGVy
LT5sZW5ndGggIT0gMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHB0ciA9ICgodWludDhfdCop
aGVhZGVyICsgc2l6ZW9mKHN0cnVjdCBodm1fc21iaW9zX3RhYmxlX2hlYWRlcikpOworICAgICAg
ICAgICAgaWYgKCBwdHJbMF0gPj0gU01CSU9TX1ZFTkRPUl9PRU1fVEFCTEVfTUlOICkKKyAgICAg
ICAgICAgIHsKKyAgICAgICAgICAgICAgICAvKiBWZW5kb3IvT0VNIHRhYmxlLCBjb3B5IGl0IGlu
LiBOb3RlIHRoZSBoYW5kbGUgdmFsdWVzIGNhbm5vdAorICAgICAgICAgICAgICAgICAgIGJlIGNo
YW5nZWQgc2luY2UgaXQgaXMgdW5rbm93biB3aGF0IGlzIGluIGVhY2ggb2YgdGhlc2UgdGFibGVz
CisgICAgICAgICAgICAgICAgICAgYnV0IHRoZXkgY291bGQgY29udGFpbiBoYW5kbGUgcmVmZXJl
bmNlcyB0byBvdGhlciB0YWJsZXMuIFRoaXMKKyAgICAgICAgICAgICAgICAgICBtZWFucyBhIHNs
aWdodCByaXNrIG9mIGNvbGxpc2lvbiB3aXRoIHRoZSB0YWJsZXMgYWJvdmUgYnV0IHRoYXQKKyAg
ICAgICAgICAgICAgICAgICB3b3VsZCBoYXZlIHRvIGJlIGRlYWx0IHdpdGggb24gYSBjYXNlIGJ5
IGNhc2UgYmFzaXMuICovCisgICAgICAgICAgICAgICAgbWVtY3B5KHN0YXJ0LCBwdHIsIGhlYWRl
ci0+bGVuZ3RoKTsKKyAgICAgICAgICAgICAgICBzdGFydCArPSBoZWFkZXItPmxlbmd0aDsKKyAg
ICAgICAgICAgIH0KKyAgICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICBwcmludGYo
IkVtcHR5IFNNQklPUyBPRU0gdGFibGUgcGFzc2VkIHRvIEhWTSBsb2FkZXIsIHNraXBwaW5nLiIp
OworCisgICAgICAgIGhlYWRlciA9IChzdHJ1Y3QgaHZtX3NtYmlvc190YWJsZV9oZWFkZXIqKShw
dHIgKyBoZWFkZXItPmxlbmd0aCk7CisgICAgfQorCisgICAgcmV0dXJuIHN0YXJ0OworfQorCiAv
KiBUeXBlIDEyNyAtLSBFbmQgb2YgVGFibGUgKi8KIHN0YXRpYyB2b2lkICoKIHNtYmlvc190eXBl
XzEyN19pbml0KHZvaWQgKnN0YXJ0KQpkaWZmIC1yIDA5MDBiMWM5MDVmMSB0b29scy9maXJtd2Fy
ZS9odm1sb2FkZXIvc21iaW9zX3R5cGVzLmgKLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L3NtYmlvc190eXBlcy5oCU1vbiBGZWIgMjAgMTg6NTg6MDcgMjAxMiArMDAwMAorKysgYi90b29s
cy9maXJtd2FyZS9odm1sb2FkZXIvc21iaW9zX3R5cGVzLmgJTW9uIEZlYiAyMCAyMDo1Njo1OCAy
MDEyIC0wNTAwCkBAIC0yOCw2ICsyOCw5IEBACiAKICNpbmNsdWRlIDxzdGRpbnQuaD4KIAorI2Rl
ZmluZSBTTUJJT1NfVkVORE9SX09FTV9UQUJMRV9NSU4gMTI4CisjZGVmaW5lIFNNQklPU19WRU5E
T1JfT0VNX1RBQkxFX01BWCAyNTUKKwogLyogU01CSU9TIGVudHJ5IHBvaW50IC0tIG11c3QgYmUg
d3JpdHRlbiB0byBhIDE2LWJpdCBhbGlnbmVkIGFkZHJlc3MKICAgIGJldHdlZW4gMHhmMDAwMCBh
bmQgMHhmZmZmZi4gCiAgKi8KQEAgLTg0LDYgKzg3LDE1IEBACiAgICAgdWludDhfdCBmYW1pbHlf
c3RyOwogfSBfX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7CiAKKy8qIFNNQklPUyB0eXBlIDIgLSBC
YXNlIEJvYXJkIEluZm9ybWF0aW9uICovCitzdHJ1Y3Qgc21iaW9zX3R5cGVfMiB7CisgICAgc3Ry
dWN0IHNtYmlvc19zdHJ1Y3R1cmVfaGVhZGVyIGhlYWRlcjsKKyAgICB1aW50OF90IG1hbnVmYWN0
dXJlcl9zdHI7CisgICAgdWludDhfdCBwcm9kdWN0X25hbWVfc3RyOworICAgIHVpbnQ4X3QgdmVy
c2lvbl9zdHI7CisgICAgdWludDhfdCBzZXJpYWxfbnVtYmVyX3N0cjsKK30gX19hdHRyaWJ1dGVf
XyAoKHBhY2tlZCkpOworCiAvKiBTTUJJT1MgdHlwZSAzIC0gU3lzdGVtIEVuY2xvc3VyZSAqLwog
c3RydWN0IHNtYmlvc190eXBlXzMgewogICAgIHN0cnVjdCBzbWJpb3Nfc3RydWN0dXJlX2hlYWRl
ciBoZWFkZXI7CkBAIC0xNzMsNiArMTg1LDI2IEBACiAgICAgdWludDhfdCBpbnRlcmxlYXZlZF9k
YXRhX2RlcHRoOwogfSBfX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7CiAKKy8qIFNNQklPUyB0eXBl
IDIyIC0gUG9ydGFibGUgYmF0dGVyeSAqLworc3RydWN0IHNtYmlvc190eXBlXzIyIHsKKyAgICBz
dHJ1Y3Qgc21iaW9zX3N0cnVjdHVyZV9oZWFkZXIgaGVhZGVyOworICAgIHVpbnQ4X3QgbG9jYXRp
b25fc3RyOworICAgIHVpbnQ4X3QgbWFudWZhY3R1cmVyX3N0cjsKKyAgICB1aW50OF90IG1hbnVm
YWN0dXJlcl9kYXRlX3N0cjsKKyAgICB1aW50OF90IHNlcmlhbF9udW1iZXJfc3RyOworICAgIHVp
bnQ4X3QgZGV2aWNlX25hbWVfc3RyOworICAgIHVpbnQ4X3QgZGV2aWNlX2NoZW1pc3RyeTsKKyAg
ICB1aW50MTZfdCBkZXZpY2VfY2FwYWNpdHk7CisgICAgdWludDE2X3QgZGV2aWNlX3ZvbHRhZ2U7
CisgICAgdWludDhfdCBzYmRzX3ZlcnNpb25fbnVtYmVyOworICAgIHVpbnQ4X3QgbWF4X2Vycm9y
OworICAgIHVpbnQxNl90IHNiZHNfc2VyaWFsX251bWJlcjsKKyAgICB1aW50MTZfdCBzYmRzX21h
bnVmYWN0dXJlcl9kYXRlOworICAgIHVpbnQ4X3Qgc2Jkc19kZXZpY2VfY2hlbWlzdHJ5OworICAg
IHVpbnQ4X3QgZGVzaWduX2NhcGFjaXR5X211bHRpcGxpZXI7CisgICAgdWludDMyX3Qgb2VtX3Nw
ZWNpZmljOworfSBfX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7CisKIC8qIFNNQklPUyB0eXBlIDMy
IC0gU3lzdGVtIEJvb3QgSW5mb3JtYXRpb24gKi8KIHN0cnVjdCBzbWJpb3NfdHlwZV8zMiB7CiAg
ICAgc3RydWN0IHNtYmlvc19zdHJ1Y3R1cmVfaGVhZGVyIGhlYWRlcjsKQEAgLTE4MCw2ICsyMTIs
MjQgQEAKICAgICB1aW50OF90IGJvb3Rfc3RhdHVzOwogfSBfX2F0dHJpYnV0ZV9fICgocGFja2Vk
KSk7CiAKKy8qIFNNQklPUyB0eXBlIDM5IC0gUG93ZXIgU3VwcGx5ICovCitzdHJ1Y3Qgc21iaW9z
X3R5cGVfMzkgeworICAgIHN0cnVjdCBzbWJpb3Nfc3RydWN0dXJlX2hlYWRlciBoZWFkZXI7Cisg
ICAgdWludDhfdCBwb3dlcl91bml0X2dyb3VwOworICAgIHVpbnQ4X3QgbG9jYXRpb25fc3RyOwor
ICAgIHVpbnQ4X3QgZGV2aWNlX25hbWVfc3RyOworICAgIHVpbnQ4X3QgbWFudWZhY3R1cmVyX3N0
cjsKKyAgICB1aW50OF90IHNlcmlhbF9udW1iZXJfc3RyOworICAgIHVpbnQ4X3QgYXNzZXRfdGFn
X251bWJlcl9zdHI7CisgICAgdWludDhfdCBtb2RlbF9wYXJ0X251bWJlcl9zdHI7CisgICAgdWlu
dDhfdCByZXZpc2lvbl9sZXZlbF9zdHI7CisgICAgdWludDE2X3QgbWF4X2NhcGFjaXR5OworICAg
IHVpbnQxNl90IGNoYXJhY3RlcmlzdGljczsKKyAgICB1aW50MTZfdCBpbnB1dF92b2x0YWdlX3By
b2JlX2hhbmRsZTsKKyAgICB1aW50MTZfdCBjb29saW5nX2RldmljZV9oYW5kbGU7CisgICAgdWlu
dDE2X3QgaW5wdXRfY3VycmVudF9wcm9iZV9oYW5kbGU7Cit9IF9fYXR0cmlidXRlX18gKChwYWNr
ZWQpKTsKKwogLyogU01CSU9TIHR5cGUgMTI3IC0tIEVuZC1vZi10YWJsZSAqLwogc3RydWN0IHNt
Ymlvc190eXBlXzEyNyB7CiAgICAgc3RydWN0IHNtYmlvc19zdHJ1Y3R1cmVfaGVhZGVyIGhlYWRl
cjsK

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323DAFTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzfuV-0004uD-J5; Tue, 21 Feb 2012 02:56:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuT-0004u8-Aj
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:56:57 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329792949!61873016!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIyMzQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19585 invoked from network); 21 Feb 2012 02:55:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:55:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="22272199"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:56:54 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Mon, 20 Feb 2012
	21:56:54 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:54 -0500
Thread-Topic: [PATCH 0/3] SMBIOS table passthrough support
Thread-Index: AczwQMOnU+rA7rPxRh21F3R06VgOXw==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D7@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SMBIOS table pass-through is useful in supporting vendor/OEM specific functionality in HVM guests. There are numerous OEM software packages and drivers that depend on having certain SMBIOS tables surfaced in a guest for their proper functioning. This also includes drivers and software needed for device pass-through. This series of patches introduces support for SMBIOS pass-through in the hvmloader. Both DMTF defined and OEM specific table pass-through is supported.

1: changes to hvm_info_table.h
2: utility support routines to validate input SMBIOS tables
3: core functionality to load passed in SMBIOS tables

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzfuV-0004uD-J5; Tue, 21 Feb 2012 02:56:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuT-0004u8-Aj
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:56:57 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329792949!61873016!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIyMzQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19585 invoked from network); 21 Feb 2012 02:55:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:55:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="22272199"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:56:54 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Mon, 20 Feb 2012
	21:56:54 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:54 -0500
Thread-Topic: [PATCH 0/3] SMBIOS table passthrough support
Thread-Index: AczwQMOnU+rA7rPxRh21F3R06VgOXw==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D7@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SMBIOS table pass-through is useful in supporting vendor/OEM specific functionality in HVM guests. There are numerous OEM software packages and drivers that depend on having certain SMBIOS tables surfaced in a guest for their proper functioning. This also includes drivers and software needed for device pass-through. This series of patches introduces support for SMBIOS pass-through in the hvmloader. Both DMTF defined and OEM specific table pass-through is supported.

1: changes to hvm_info_table.h
2: utility support routines to validate input SMBIOS tables
3: core functionality to load passed in SMBIOS tables

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzfub-0004vA-PG; Tue, 21 Feb 2012 02:57:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuZ-0004uL-Gs
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:57:03 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329792949!61873016!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIyMzQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19658 invoked from network); 21 Feb 2012 02:55:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="22272201"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:56:58 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Mon, 20 Feb 2012
	21:56:58 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:57 -0500
Thread-Topic: [PATCH 2/3] SMBIOS table passthrough support
Thread-Index: AczwQNBwJHYVRvDJT6WByDefdNo2yA==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Utility routines in hvmloader for SMBIOS table validation.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_
Content-Type: application/octet-stream; name="smbios-passthrough-02.patch"
Content-Description: smbios-passthrough-02.patch
Content-Disposition: attachment; filename="smbios-passthrough-02.patch";
	size=3362; creation-date="Tue, 21 Feb 2012 01:50:19 GMT";
	modification-date="Tue, 21 Feb 2012 01:56:15 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAwOTAwYjFjOTA1ZjEgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3V0aWwuYwotLS0g
YS90b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jCU1vbiBGZWIgMjAgMTg6NTg6MDcgMjAx
MiArMDAwMAorKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jCU1vbiBGZWIgMjAg
MjA6Mzc6MTIgMjAxMiAtMDUwMApAQCAtNzA5LDM3ICs3MDksMzggQEAKICAgICBjcmFzaCgpOwog
fQogCi1zdGF0aWMgdm9pZCB2YWxpZGF0ZV9odm1faW5mbyhzdHJ1Y3QgaHZtX2luZm9fdGFibGUg
KnQpCitzdGF0aWMgaW50IHZhbGlkYXRlX2h2bV9pbmZvX3RhYmxlKHVpbnQ4X3QgKnRhYmxlLCB1
aW50MzJfdCB0YWJsZV9sZW5ndGgsCisgICAgY29uc3QgY2hhciAqdGFibGVfc2lnLCBjb25zdCBj
aGFyICpzaWcpCiB7Ci0gICAgdWludDhfdCAqcHRyID0gKHVpbnQ4X3QgKil0OwogICAgIHVpbnQ4
X3Qgc3VtID0gMDsKICAgICBpbnQgaTsKIAotICAgIGlmICggc3RybmNtcCh0LT5zaWduYXR1cmUs
ICJIVk0gSU5GTyIsIDgpICkKKyAgICBpZiAodGFibGVfbGVuZ3RoID09IDApCisgICAgICAgIHBy
aW50ZigiRW1wdHkgSFZNIGluZm8gdGFibGU6ICUuKnNcbiIsIDgsIHNpZyk7CisKKyAgICAvKiBO
T1RFIG1hZGUgdGhpcyBhIGNvbW1vbiByb3V0aW5lIHRvIHZhbGlkYXRlIGFsbCBIVk0gdGFibGVz
LiBSZW1vdmVkIAorICAgICAgIEJVRygpIG9uIGZhaWx1cmUgaW4gaGVyZSAtIGxldCB0aGUgY2Fs
bGVyIGRlY2lkZSBpZiBhIGNoZWNrc3VtIGZhaWx1cmUKKyAgICAgICB3YXJyYW50cyB0aGF0ICov
CisKKyAgICAvKiBzdHJuY21wKHQtPnNpZ25hdHVyZSwgc2lnbmF0dXJlLCA4KSAqLworICAgIGZv
ciAoIGkgPSAwOyBpIDwgODsgaSsrICkKICAgICB7Ci0gICAgICAgIHByaW50ZigiQmFkIGh2bSBp
bmZvIHNpZ25hdHVyZVxuIik7Ci0gICAgICAgIEJVRygpOworICAgICAgICBpZiAoIHRhYmxlX3Np
Z1tpXSAhPSBzaWdbaV0gKQorICAgICAgICB7CisgICAgICAgICAgICBwcmludGYoIkJhZCBIVk0g
aW5mbyBzaWduYXR1cmUgZm9yOiAlLipzXG4iLCA4LCBzaWcpOworICAgICAgICAgICAgcmV0dXJu
IDA7CisgICAgICAgIH0KICAgICB9CiAKLSAgICBpZiAoIHQtPmxlbmd0aCA8IHNpemVvZihzdHJ1
Y3QgaHZtX2luZm9fdGFibGUpICkKLSAgICB7Ci0gICAgICAgIHByaW50ZigiQmFkIGh2bSBpbmZv
IGxlbmd0aFxuIik7Ci0gICAgICAgIEJVRygpOwotICAgIH0KKyAgICBmb3IgKCBpID0gMDsgaSA8
IHRhYmxlX2xlbmd0aDsgaSsrICkKKyAgICAgICAgc3VtICs9IHRhYmxlW2ldOwogCi0gICAgZm9y
ICggaSA9IDA7IGkgPCB0LT5sZW5ndGg7IGkrKyApCi0gICAgICAgIHN1bSArPSBwdHJbaV07Ci0K
LSAgICBpZiAoIHN1bSAhPSAwICkKLSAgICB7Ci0gICAgICAgIHByaW50ZigiQmFkIGh2bSBpbmZv
IGNoZWNrc3VtXG4iKTsKLSAgICAgICAgQlVHKCk7Ci0gICAgfQorICAgIHJldHVybiAoc3VtID09
IDApOwogfQogCiBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKmdldF9odm1faW5mb190YWJsZSh2b2lk
KQogewotICAgIHN0YXRpYyBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKnRhYmxlOworICAgIHN0YXRp
YyBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKnRhYmxlID0gTlVMTDsKICAgICBzdHJ1Y3QgaHZtX2lu
Zm9fdGFibGUgKnQ7CiAKICAgICBpZiAoIHRhYmxlICE9IE5VTEwgKQpAQCAtNzQ3LDEzICs3NDgs
NDQgQEAKIAogICAgIHQgPSAoc3RydWN0IGh2bV9pbmZvX3RhYmxlICopSFZNX0lORk9fUEFERFI7
CiAKLSAgICB2YWxpZGF0ZV9odm1faW5mbyh0KTsKKyAgICBpZiAoICF2YWxpZGF0ZV9odm1faW5m
b190YWJsZSgodWludDhfdCopdCwgdC0+bGVuZ3RoLCB0LT5zaWduYXR1cmUsICJIVk0gSU5GTyIp
ICkKKyAgICB7CisgICAgICAgIHByaW50ZigiQmFkIEhWTSBpbmZvIHRhYmxlXG4iKTsKKyAgICAg
ICAgQlVHKCk7CisgICAgfQogCiAgICAgdGFibGUgPSB0OwogCiAgICAgcmV0dXJuIHRhYmxlOwog
fQogCitzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpnZXRfaHZtX3NtYmlvc19pbmZvX3Rh
YmxlKHZvaWQpCit7CisgICAgc3RhdGljIHN0cnVjdCBodm1fc21iaW9zX2luZm9fdGFibGUgKnRh
YmxlID0gTlVMTDsKKyAgICBzdGF0aWMgaW50IHZhbGlkYXRlZCA9IDA7CisgICAgc3RydWN0IGh2
bV9zbWJpb3NfaW5mb190YWJsZSAqdDsKKworICAgIGlmICggdmFsaWRhdGVkICkKKyAgICAgICAg
cmV0dXJuIHRhYmxlOworCisgICAgdCA9IChzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICop
SFZNX1NNQklPU19JTkZPX1BBRERSOworCisgICAgaWYgKCAodC0+bGVuZ3RoID09IDApICYmICh0
LT5jb3VudCA9PSAwKSApCisgICAgeworICAgICAgICBwcmludGYoIkVtcHR5IEhWTSBTTUJJT1Mg
aW5mbyB0YWJsZVxuIik7CisgICAgICAgIHZhbGlkYXRlZCA9IDE7CisgICAgICAgIHJldHVybiB0
YWJsZTsKKyAgICB9CisKKyAgICBpZiAoIHZhbGlkYXRlX2h2bV9pbmZvX3RhYmxlKCh1aW50OF90
Kil0LCB0LT5sZW5ndGgsIHQtPnNpZ25hdHVyZSwgIlNNQklPU1BUIikgKQorICAgICAgICB0YWJs
ZSA9IHQ7CisgICAgZWxzZQorICAgICAgICBwcmludGYoIkJhZCBvciBtaXNzaW5nIEhWTSBTTUJJ
T1MgaW5mbyB0YWJsZVxuIik7CisgICAgdmFsaWRhdGVkID0gMTsKKworICAgIHJldHVybiB0YWJs
ZTsKK30KKwogc3RydWN0IHNoYXJlZF9pbmZvICpnZXRfc2hhcmVkX2luZm8odm9pZCkgCiB7CiAg
ICAgc3RhdGljIHN0cnVjdCBzaGFyZWRfaW5mbyAqc2hhcmVkX2luZm8gPSBOVUxMOwpkaWZmIC1y
IDA5MDBiMWM5MDVmMSB0b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5oCi0tLSBhL3Rvb2xz
L2Zpcm13YXJlL2h2bWxvYWRlci91dGlsLmgJTW9uIEZlYiAyMCAxODo1ODowNyAyMDEyICswMDAw
CisrKyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci91dGlsLmgJTW9uIEZlYiAyMCAyMDozNzox
MiAyMDEyIC0wNTAwCkBAIC0xNDUsNiArMTQ1LDggQEAKIC8qIEhWTS1idWlsZGVyIGluZm8uICov
CiBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKmdldF9odm1faW5mb190YWJsZSh2b2lkKSBfX2F0dHJp
YnV0ZV9fICgoY29uc3QpKTsKICNkZWZpbmUgaHZtX2luZm8gKGdldF9odm1faW5mb190YWJsZSgp
KQorc3RydWN0IGh2bV9zbWJpb3NfaW5mb190YWJsZSAqZ2V0X2h2bV9zbWJpb3NfaW5mb190YWJs
ZSh2b2lkKSBfX2F0dHJpYnV0ZV9fICgoY29uc3QpKTsKKyNkZWZpbmUgaHZtX3NtYmlvc19pbmZv
IChnZXRfaHZtX3NtYmlvc19pbmZvX3RhYmxlKCkpCiAKIC8qIFN0cmluZyBhbmQgbWVtb3J5IGZ1
bmN0aW9ucyAqLwogaW50IHN0cmNtcChjb25zdCBjaGFyICpjcywgY29uc3QgY2hhciAqY3QpOwo=

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzfub-0004vA-PG; Tue, 21 Feb 2012 02:57:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuZ-0004uL-Gs
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:57:03 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329792949!61873016!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIyMzQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19658 invoked from network); 21 Feb 2012 02:55:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 02:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="22272201"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:56:58 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Mon, 20 Feb 2012
	21:56:58 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:57 -0500
Thread-Topic: [PATCH 2/3] SMBIOS table passthrough support
Thread-Index: AczwQNBwJHYVRvDJT6WByDefdNo2yA==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Utility routines in hvmloader for SMBIOS table validation.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_
Content-Type: application/octet-stream; name="smbios-passthrough-02.patch"
Content-Description: smbios-passthrough-02.patch
Content-Disposition: attachment; filename="smbios-passthrough-02.patch";
	size=3362; creation-date="Tue, 21 Feb 2012 01:50:19 GMT";
	modification-date="Tue, 21 Feb 2012 01:56:15 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAwOTAwYjFjOTA1ZjEgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3V0aWwuYwotLS0g
YS90b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jCU1vbiBGZWIgMjAgMTg6NTg6MDcgMjAx
MiArMDAwMAorKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jCU1vbiBGZWIgMjAg
MjA6Mzc6MTIgMjAxMiAtMDUwMApAQCAtNzA5LDM3ICs3MDksMzggQEAKICAgICBjcmFzaCgpOwog
fQogCi1zdGF0aWMgdm9pZCB2YWxpZGF0ZV9odm1faW5mbyhzdHJ1Y3QgaHZtX2luZm9fdGFibGUg
KnQpCitzdGF0aWMgaW50IHZhbGlkYXRlX2h2bV9pbmZvX3RhYmxlKHVpbnQ4X3QgKnRhYmxlLCB1
aW50MzJfdCB0YWJsZV9sZW5ndGgsCisgICAgY29uc3QgY2hhciAqdGFibGVfc2lnLCBjb25zdCBj
aGFyICpzaWcpCiB7Ci0gICAgdWludDhfdCAqcHRyID0gKHVpbnQ4X3QgKil0OwogICAgIHVpbnQ4
X3Qgc3VtID0gMDsKICAgICBpbnQgaTsKIAotICAgIGlmICggc3RybmNtcCh0LT5zaWduYXR1cmUs
ICJIVk0gSU5GTyIsIDgpICkKKyAgICBpZiAodGFibGVfbGVuZ3RoID09IDApCisgICAgICAgIHBy
aW50ZigiRW1wdHkgSFZNIGluZm8gdGFibGU6ICUuKnNcbiIsIDgsIHNpZyk7CisKKyAgICAvKiBO
T1RFIG1hZGUgdGhpcyBhIGNvbW1vbiByb3V0aW5lIHRvIHZhbGlkYXRlIGFsbCBIVk0gdGFibGVz
LiBSZW1vdmVkIAorICAgICAgIEJVRygpIG9uIGZhaWx1cmUgaW4gaGVyZSAtIGxldCB0aGUgY2Fs
bGVyIGRlY2lkZSBpZiBhIGNoZWNrc3VtIGZhaWx1cmUKKyAgICAgICB3YXJyYW50cyB0aGF0ICov
CisKKyAgICAvKiBzdHJuY21wKHQtPnNpZ25hdHVyZSwgc2lnbmF0dXJlLCA4KSAqLworICAgIGZv
ciAoIGkgPSAwOyBpIDwgODsgaSsrICkKICAgICB7Ci0gICAgICAgIHByaW50ZigiQmFkIGh2bSBp
bmZvIHNpZ25hdHVyZVxuIik7Ci0gICAgICAgIEJVRygpOworICAgICAgICBpZiAoIHRhYmxlX3Np
Z1tpXSAhPSBzaWdbaV0gKQorICAgICAgICB7CisgICAgICAgICAgICBwcmludGYoIkJhZCBIVk0g
aW5mbyBzaWduYXR1cmUgZm9yOiAlLipzXG4iLCA4LCBzaWcpOworICAgICAgICAgICAgcmV0dXJu
IDA7CisgICAgICAgIH0KICAgICB9CiAKLSAgICBpZiAoIHQtPmxlbmd0aCA8IHNpemVvZihzdHJ1
Y3QgaHZtX2luZm9fdGFibGUpICkKLSAgICB7Ci0gICAgICAgIHByaW50ZigiQmFkIGh2bSBpbmZv
IGxlbmd0aFxuIik7Ci0gICAgICAgIEJVRygpOwotICAgIH0KKyAgICBmb3IgKCBpID0gMDsgaSA8
IHRhYmxlX2xlbmd0aDsgaSsrICkKKyAgICAgICAgc3VtICs9IHRhYmxlW2ldOwogCi0gICAgZm9y
ICggaSA9IDA7IGkgPCB0LT5sZW5ndGg7IGkrKyApCi0gICAgICAgIHN1bSArPSBwdHJbaV07Ci0K
LSAgICBpZiAoIHN1bSAhPSAwICkKLSAgICB7Ci0gICAgICAgIHByaW50ZigiQmFkIGh2bSBpbmZv
IGNoZWNrc3VtXG4iKTsKLSAgICAgICAgQlVHKCk7Ci0gICAgfQorICAgIHJldHVybiAoc3VtID09
IDApOwogfQogCiBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKmdldF9odm1faW5mb190YWJsZSh2b2lk
KQogewotICAgIHN0YXRpYyBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKnRhYmxlOworICAgIHN0YXRp
YyBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKnRhYmxlID0gTlVMTDsKICAgICBzdHJ1Y3QgaHZtX2lu
Zm9fdGFibGUgKnQ7CiAKICAgICBpZiAoIHRhYmxlICE9IE5VTEwgKQpAQCAtNzQ3LDEzICs3NDgs
NDQgQEAKIAogICAgIHQgPSAoc3RydWN0IGh2bV9pbmZvX3RhYmxlICopSFZNX0lORk9fUEFERFI7
CiAKLSAgICB2YWxpZGF0ZV9odm1faW5mbyh0KTsKKyAgICBpZiAoICF2YWxpZGF0ZV9odm1faW5m
b190YWJsZSgodWludDhfdCopdCwgdC0+bGVuZ3RoLCB0LT5zaWduYXR1cmUsICJIVk0gSU5GTyIp
ICkKKyAgICB7CisgICAgICAgIHByaW50ZigiQmFkIEhWTSBpbmZvIHRhYmxlXG4iKTsKKyAgICAg
ICAgQlVHKCk7CisgICAgfQogCiAgICAgdGFibGUgPSB0OwogCiAgICAgcmV0dXJuIHRhYmxlOwog
fQogCitzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICpnZXRfaHZtX3NtYmlvc19pbmZvX3Rh
YmxlKHZvaWQpCit7CisgICAgc3RhdGljIHN0cnVjdCBodm1fc21iaW9zX2luZm9fdGFibGUgKnRh
YmxlID0gTlVMTDsKKyAgICBzdGF0aWMgaW50IHZhbGlkYXRlZCA9IDA7CisgICAgc3RydWN0IGh2
bV9zbWJpb3NfaW5mb190YWJsZSAqdDsKKworICAgIGlmICggdmFsaWRhdGVkICkKKyAgICAgICAg
cmV0dXJuIHRhYmxlOworCisgICAgdCA9IChzdHJ1Y3QgaHZtX3NtYmlvc19pbmZvX3RhYmxlICop
SFZNX1NNQklPU19JTkZPX1BBRERSOworCisgICAgaWYgKCAodC0+bGVuZ3RoID09IDApICYmICh0
LT5jb3VudCA9PSAwKSApCisgICAgeworICAgICAgICBwcmludGYoIkVtcHR5IEhWTSBTTUJJT1Mg
aW5mbyB0YWJsZVxuIik7CisgICAgICAgIHZhbGlkYXRlZCA9IDE7CisgICAgICAgIHJldHVybiB0
YWJsZTsKKyAgICB9CisKKyAgICBpZiAoIHZhbGlkYXRlX2h2bV9pbmZvX3RhYmxlKCh1aW50OF90
Kil0LCB0LT5sZW5ndGgsIHQtPnNpZ25hdHVyZSwgIlNNQklPU1BUIikgKQorICAgICAgICB0YWJs
ZSA9IHQ7CisgICAgZWxzZQorICAgICAgICBwcmludGYoIkJhZCBvciBtaXNzaW5nIEhWTSBTTUJJ
T1MgaW5mbyB0YWJsZVxuIik7CisgICAgdmFsaWRhdGVkID0gMTsKKworICAgIHJldHVybiB0YWJs
ZTsKK30KKwogc3RydWN0IHNoYXJlZF9pbmZvICpnZXRfc2hhcmVkX2luZm8odm9pZCkgCiB7CiAg
ICAgc3RhdGljIHN0cnVjdCBzaGFyZWRfaW5mbyAqc2hhcmVkX2luZm8gPSBOVUxMOwpkaWZmIC1y
IDA5MDBiMWM5MDVmMSB0b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5oCi0tLSBhL3Rvb2xz
L2Zpcm13YXJlL2h2bWxvYWRlci91dGlsLmgJTW9uIEZlYiAyMCAxODo1ODowNyAyMDEyICswMDAw
CisrKyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci91dGlsLmgJTW9uIEZlYiAyMCAyMDozNzox
MiAyMDEyIC0wNTAwCkBAIC0xNDUsNiArMTQ1LDggQEAKIC8qIEhWTS1idWlsZGVyIGluZm8uICov
CiBzdHJ1Y3QgaHZtX2luZm9fdGFibGUgKmdldF9odm1faW5mb190YWJsZSh2b2lkKSBfX2F0dHJp
YnV0ZV9fICgoY29uc3QpKTsKICNkZWZpbmUgaHZtX2luZm8gKGdldF9odm1faW5mb190YWJsZSgp
KQorc3RydWN0IGh2bV9zbWJpb3NfaW5mb190YWJsZSAqZ2V0X2h2bV9zbWJpb3NfaW5mb190YWJs
ZSh2b2lkKSBfX2F0dHJpYnV0ZV9fICgoY29uc3QpKTsKKyNkZWZpbmUgaHZtX3NtYmlvc19pbmZv
IChnZXRfaHZtX3NtYmlvc19pbmZvX3RhYmxlKCkpCiAKIC8qIFN0cmluZyBhbmQgbWVtb3J5IGZ1
bmN0aW9ucyAqLwogaW50IHN0cmNtcChjb25zdCBjaGFyICpjcywgY29uc3QgY2hhciAqY3QpOwo=

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D9FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfuX-0004uQ-VR; Tue, 21 Feb 2012 02:57:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuW-0004uJ-Ah
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:57:00 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329792964!53546281!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY3MTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15993 invoked from network); 21 Feb 2012 02:56:05 -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;
	21 Feb 2012 02:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="182695161"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:56:57 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Mon, 20 Feb 2012
	21:56:57 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:56 -0500
Thread-Topic: [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwQMeKjMMBX2CPRpih3BdESm407w==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updates to the layout of the HVM parameter and information page defined in =
hvm_info_table.h. The SMBIOS pass-through tables are written to the bottom =
half of this page.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>



--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_
Content-Type: application/octet-stream; name="smbios-passthrough-01.patch"
Content-Description: smbios-passthrough-01.patch
Content-Disposition: attachment; filename="smbios-passthrough-01.patch";
	size=1882; creation-date="Tue, 21 Feb 2012 01:50:19 GMT";
	modification-date="Tue, 21 Feb 2012 01:56:15 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAwOTAwYjFjOTA1ZjEgeGVuL2luY2x1ZGUvcHVibGljL2h2bS9odm1faW5mb190YWJs
ZS5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vaHZtX2luZm9fdGFibGUuaAlNb24gRmVi
IDIwIDE4OjU4OjA3IDIwMTIgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2h2bS9odm1f
aW5mb190YWJsZS5oCU1vbiBGZWIgMjAgMjA6MzU6MzYgMjAxMiAtMDUwMApAQCAtMjUsMTIgKzI1
LDE1IEBACiAjaWZuZGVmIF9fWEVOX1BVQkxJQ19IVk1fSFZNX0lORk9fVEFCTEVfSF9fCiAjZGVm
aW5lIF9fWEVOX1BVQkxJQ19IVk1fSFZNX0lORk9fVEFCTEVfSF9fCiAKLSNkZWZpbmUgSFZNX0lO
Rk9fUEZOICAgICAgICAgMHgwOUYKLSNkZWZpbmUgSFZNX0lORk9fT0ZGU0VUICAgICAgMHg4MDAK
LSNkZWZpbmUgSFZNX0lORk9fUEFERFIgICAgICAgKChIVk1fSU5GT19QRk4gPDwgMTIpICsgSFZN
X0lORk9fT0ZGU0VUKQorI2RlZmluZSBIVk1fSU5GT19QRk4gICAgICAgICAgIDB4MDlGCisjZGVm
aW5lIEhWTV9JTkZPX09GRlNFVCAgICAgICAgMHg4MDAKKyNkZWZpbmUgSFZNX0lORk9fUEFERFIg
ICAgICAgICAoKEhWTV9JTkZPX1BGTiA8PCAxMikgKyBIVk1fSU5GT19PRkZTRVQpCisjZGVmaW5l
IEhWTV9TTUJJT1NfSU5GT19PRkZTRVQgMHgwCisjZGVmaW5lIEhWTV9TTUJJT1NfSU5GT19QQURE
UiAgKChIVk1fSU5GT19QRk4gPDwgMTIpICsgSFZNX1NNQklPU19JTkZPX09GRlNFVCkKKyNkZWZp
bmUgSFZNX1NNQklPU19JTkZPX01BWCAgICAweDgwMAogCiAvKiBNYXhpbXVtIHdlIGNhbiBzdXBw
b3J0IHdpdGggY3VycmVudCB2TEFQSUMgSUQgbWFwcGluZy4gKi8KLSNkZWZpbmUgSFZNX01BWF9W
Q1BVUyAgICAgICAgMTI4CisjZGVmaW5lIEhWTV9NQVhfVkNQVVMgICAgICAgICAgMTI4CiAKIHN0
cnVjdCBodm1faW5mb190YWJsZSB7CiAgICAgY2hhciAgICAgICAgc2lnbmF0dXJlWzhdOyAvKiAi
SFZNIElORk8iICovCkBAIC02OSw0ICs3MiwzMSBAQAogICAgIHVpbnQ4X3QgICAgIHZjcHVfb25s
aW5lWyhIVk1fTUFYX1ZDUFVTICsgNykvOF07CiB9OwogCitzdHJ1Y3QgaHZtX3NtYmlvc190YWJs
ZV9oZWFkZXIgeworICAgIC8qCisgICAgICogQmVnaW5uaW5nIGFmdGVyIHRoaXMgc3R1Y3R1cmUs
IGluY2x1ZGVzIGZpeGVkIHRhYmxlIHNpemUgCisgICAgICogc3RyaW5nIGxpc3QsIGFuZCB0ZXJt
aW5hdG9yLgorICAgICAqLworICAgIHVpbnQzMl90ICAgIGxlbmd0aDsKK307CisKKyNkZWZpbmUg
SFZNX1NNQklPU19JTkNMVURFX1NZU1RFTV9CT0FSRCAgICAgMHgwMDAwMDAwMQorI2RlZmluZSBI
Vk1fU01CSU9TX0lOQ0xVREVfUE9SVEFCTEVfQkFUVEVSWSAweDAwMDAwMDAyCisjZGVmaW5lIEhW
TV9TTUJJT1NfSU5DTFVERV9QT1dFUl9TVVBQTFkgICAgIDB4MDAwMDAwMDQKKyNkZWZpbmUgSFZN
X1NNQklPU19JTkNMVURFX1ZFTkRPUl9PRU0gICAgICAgMHgwMDAwMDAwOAorCitzdHJ1Y3QgaHZt
X3NtYmlvc19pbmZvX3RhYmxlIHsKKyAgICBjaGFyICAgICAgICBzaWduYXR1cmVbOF07IC8qICJT
TUJJT1NQVCIgKi8KKyAgICB1aW50MzJfdCAgICBsZW5ndGg7IC8qIGFsbCB0YWJsZXMgKyB0aGlz
IHN0cnVjdCAqLworICAgIHVpbnQ4X3QgICAgIGNoZWNrc3VtOworCisgICAgLyogQ29udHJvbCBm
bGFncyBmb3IgdGFibGUgb3B0aW9ucyAqLworICAgIHVpbnQzMl90ICAgIGZsYWdzOworCisgICAg
LyogQ291bnQgb2YgdGFibGUgaGVhZGVycyB0aGF0IGZvbGxvd2luZyB0aGlzIHN0dWN0dXJlLiAq
LworICAgIHVpbnQzMl90ICAgIGNvdW50OworCisgICAgLyogQmVnaW4gU01CSU9TIHRhYmxlcyAq
LworfTsKKwogI2VuZGlmIC8qIF9fWEVOX1BVQkxJQ19IVk1fSFZNX0lORk9fVEFCTEVfSF9fICov
Cg==

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Feb 21 02:57:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 02: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 1RzfuX-0004uQ-VR; Tue, 21 Feb 2012 02:57:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzfuW-0004uJ-Ah
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 02:57:00 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329792964!53546281!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY3MTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15993 invoked from network); 21 Feb 2012 02:56:05 -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;
	21 Feb 2012 02:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="182695161"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2012 21:56:57 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Mon, 20 Feb 2012
	21:56:57 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 20 Feb 2012 21:56:56 -0500
Thread-Topic: [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwQMeKjMMBX2CPRpih3BdESm407w==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updates to the layout of the HVM parameter and information page defined in =
hvm_info_table.h. The SMBIOS pass-through tables are written to the bottom =
half of this page.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>



--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_
Content-Type: application/octet-stream; name="smbios-passthrough-01.patch"
Content-Description: smbios-passthrough-01.patch
Content-Disposition: attachment; filename="smbios-passthrough-01.patch";
	size=1882; creation-date="Tue, 21 Feb 2012 01:50:19 GMT";
	modification-date="Tue, 21 Feb 2012 01:56:15 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciAwOTAwYjFjOTA1ZjEgeGVuL2luY2x1ZGUvcHVibGljL2h2bS9odm1faW5mb190YWJs
ZS5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vaHZtX2luZm9fdGFibGUuaAlNb24gRmVi
IDIwIDE4OjU4OjA3IDIwMTIgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2h2bS9odm1f
aW5mb190YWJsZS5oCU1vbiBGZWIgMjAgMjA6MzU6MzYgMjAxMiAtMDUwMApAQCAtMjUsMTIgKzI1
LDE1IEBACiAjaWZuZGVmIF9fWEVOX1BVQkxJQ19IVk1fSFZNX0lORk9fVEFCTEVfSF9fCiAjZGVm
aW5lIF9fWEVOX1BVQkxJQ19IVk1fSFZNX0lORk9fVEFCTEVfSF9fCiAKLSNkZWZpbmUgSFZNX0lO
Rk9fUEZOICAgICAgICAgMHgwOUYKLSNkZWZpbmUgSFZNX0lORk9fT0ZGU0VUICAgICAgMHg4MDAK
LSNkZWZpbmUgSFZNX0lORk9fUEFERFIgICAgICAgKChIVk1fSU5GT19QRk4gPDwgMTIpICsgSFZN
X0lORk9fT0ZGU0VUKQorI2RlZmluZSBIVk1fSU5GT19QRk4gICAgICAgICAgIDB4MDlGCisjZGVm
aW5lIEhWTV9JTkZPX09GRlNFVCAgICAgICAgMHg4MDAKKyNkZWZpbmUgSFZNX0lORk9fUEFERFIg
ICAgICAgICAoKEhWTV9JTkZPX1BGTiA8PCAxMikgKyBIVk1fSU5GT19PRkZTRVQpCisjZGVmaW5l
IEhWTV9TTUJJT1NfSU5GT19PRkZTRVQgMHgwCisjZGVmaW5lIEhWTV9TTUJJT1NfSU5GT19QQURE
UiAgKChIVk1fSU5GT19QRk4gPDwgMTIpICsgSFZNX1NNQklPU19JTkZPX09GRlNFVCkKKyNkZWZp
bmUgSFZNX1NNQklPU19JTkZPX01BWCAgICAweDgwMAogCiAvKiBNYXhpbXVtIHdlIGNhbiBzdXBw
b3J0IHdpdGggY3VycmVudCB2TEFQSUMgSUQgbWFwcGluZy4gKi8KLSNkZWZpbmUgSFZNX01BWF9W
Q1BVUyAgICAgICAgMTI4CisjZGVmaW5lIEhWTV9NQVhfVkNQVVMgICAgICAgICAgMTI4CiAKIHN0
cnVjdCBodm1faW5mb190YWJsZSB7CiAgICAgY2hhciAgICAgICAgc2lnbmF0dXJlWzhdOyAvKiAi
SFZNIElORk8iICovCkBAIC02OSw0ICs3MiwzMSBAQAogICAgIHVpbnQ4X3QgICAgIHZjcHVfb25s
aW5lWyhIVk1fTUFYX1ZDUFVTICsgNykvOF07CiB9OwogCitzdHJ1Y3QgaHZtX3NtYmlvc190YWJs
ZV9oZWFkZXIgeworICAgIC8qCisgICAgICogQmVnaW5uaW5nIGFmdGVyIHRoaXMgc3R1Y3R1cmUs
IGluY2x1ZGVzIGZpeGVkIHRhYmxlIHNpemUgCisgICAgICogc3RyaW5nIGxpc3QsIGFuZCB0ZXJt
aW5hdG9yLgorICAgICAqLworICAgIHVpbnQzMl90ICAgIGxlbmd0aDsKK307CisKKyNkZWZpbmUg
SFZNX1NNQklPU19JTkNMVURFX1NZU1RFTV9CT0FSRCAgICAgMHgwMDAwMDAwMQorI2RlZmluZSBI
Vk1fU01CSU9TX0lOQ0xVREVfUE9SVEFCTEVfQkFUVEVSWSAweDAwMDAwMDAyCisjZGVmaW5lIEhW
TV9TTUJJT1NfSU5DTFVERV9QT1dFUl9TVVBQTFkgICAgIDB4MDAwMDAwMDQKKyNkZWZpbmUgSFZN
X1NNQklPU19JTkNMVURFX1ZFTkRPUl9PRU0gICAgICAgMHgwMDAwMDAwOAorCitzdHJ1Y3QgaHZt
X3NtYmlvc19pbmZvX3RhYmxlIHsKKyAgICBjaGFyICAgICAgICBzaWduYXR1cmVbOF07IC8qICJT
TUJJT1NQVCIgKi8KKyAgICB1aW50MzJfdCAgICBsZW5ndGg7IC8qIGFsbCB0YWJsZXMgKyB0aGlz
IHN0cnVjdCAqLworICAgIHVpbnQ4X3QgICAgIGNoZWNrc3VtOworCisgICAgLyogQ29udHJvbCBm
bGFncyBmb3IgdGFibGUgb3B0aW9ucyAqLworICAgIHVpbnQzMl90ICAgIGZsYWdzOworCisgICAg
LyogQ291bnQgb2YgdGFibGUgaGVhZGVycyB0aGF0IGZvbGxvd2luZyB0aGlzIHN0dWN0dXJlLiAq
LworICAgIHVpbnQzMl90ICAgIGNvdW50OworCisgICAgLyogQmVnaW4gU01CSU9TIHRhYmxlcyAq
LworfTsKKwogI2VuZGlmIC8qIF9fWEVOX1BVQkxJQ19IVk1fSFZNX0lORk9fVEFCTEVfSF9fICov
Cg==

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--_002_831D55AF5A11D64C9B4B43F59EEBF720724EC323D8FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Feb 21 03:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 03:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzgWP-0005y4-VN; Tue, 21 Feb 2012 03:36:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzgWN-0005xv-Qi
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 03:36:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329795360!15687658!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30486 invoked from network); 21 Feb 2012 03:36:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 03:36: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 q1L3ZlCA021035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 03:35:48 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1L3Zjqm000779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 03:35:45 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
	q1L3ZieK013324; Mon, 20 Feb 2012 21:35:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 19:35:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 239B540469; Mon, 20 Feb 2012 22:32:31 -0500 (EST)
Date: Mon, 20 Feb 2012 22:32:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Rostedt <rostedt@goodmis.org>
Message-ID: <20120221033231.GA3776@phenom.dumpdata.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<1329786103.25686.48.camel@gandalf.stny.rr.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329786103.25686.48.camel@gandalf.stny.rr.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F431115.0050,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 08:01:43PM -0500, Steven Rostedt wrote:
> On Fri, 2012-02-10 at 10:34 -0500, Konrad Rzeszutek Wilk wrote:
> >    66 66 66 90          	data32 data32 xchg %ax,%ax
> > 
> > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very well on Intel
> > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - that I found out
> > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled in (but the tracer
> > is set to the default 'nop'). If I disable that specific config option the numbers
> > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on the AMD box.
> > Interestingly enough I only see these on AMD machines - not on the Intel ones.
> 
> All paravirt ops should be labeled with "notrace" so that function
> tracer does not trace those functions. Have you annotated your new
> paravirt ops with notrace?

No. I hadn't realized that flag existed until your email a couple of days ago - I hadn't
had a chance to see if the notrace would solve this. But let me do that and get
back on this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 03:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 03:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzgWP-0005y4-VN; Tue, 21 Feb 2012 03:36:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzgWN-0005xv-Qi
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 03:36:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329795360!15687658!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NDEzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30486 invoked from network); 21 Feb 2012 03:36:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 03:36: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 q1L3ZlCA021035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 03:35:48 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1L3Zjqm000779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 03:35:45 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
	q1L3ZieK013324; Mon, 20 Feb 2012 21:35:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 20 Feb 2012 19:35:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 239B540469; Mon, 20 Feb 2012 22:32:31 -0500 (EST)
Date: Mon, 20 Feb 2012 22:32:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Rostedt <rostedt@goodmis.org>
Message-ID: <20120221033231.GA3776@phenom.dumpdata.com>
References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com>
	<1329786103.25686.48.camel@gandalf.stny.rr.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329786103.25686.48.camel@gandalf.stny.rr.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F431115.0050,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 08:01:43PM -0500, Steven Rostedt wrote:
> On Fri, 2012-02-10 at 10:34 -0500, Konrad Rzeszutek Wilk wrote:
> >    66 66 66 90          	data32 data32 xchg %ax,%ax
> > 
> > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very well on Intel
> > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - that I found out
> > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled in (but the tracer
> > is set to the default 'nop'). If I disable that specific config option the numbers
> > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on the AMD box.
> > Interestingly enough I only see these on AMD machines - not on the Intel ones.
> 
> All paravirt ops should be labeled with "notrace" so that function
> tracer does not trace those functions. Have you annotated your new
> paravirt ops with notrace?

No. I hadn't realized that flag existed until your email a couple of days ago - I hadn't
had a chance to see if the notrace would solve this. But let me do that and get
back on this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 04:59:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 04: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 1RzhoW-0006lC-5G; Tue, 21 Feb 2012 04:58:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzhoT-0006l7-Vq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 04:58:54 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329800327!3722397!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2465 invoked from network); 21 Feb 2012 04:58:47 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 04:58:47 -0000
Received: by wgbdr13 with SMTP id dr13so4673805wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 20:58:47 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr28099643wib.3.1329800327619 (num_hops
	= 1); Mon, 20 Feb 2012 20:58:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr23436898wib.3.1329800327525; Mon,
	20 Feb 2012 20:58:47 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 20:58:47 -0800 (PST)
Date: Mon, 20 Feb 2012 20:58:47 -0800
Message-ID: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQkX1Q84cGcTG//icLP8N0azA1w5y4tQsKJGWojS6BYTD+TMJOlt8GNgarxqf4dZzwKn4xM4
Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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

Is it possible in Xen that with a dual GPU graphics card which appears
as two separately addressable PCI devices to pass each
GPU to a separate guest?  Although I didn't think this was initially
possible, VMWare supports it.
It's useful under xen for increasing virtual server density when
providing virtual desktops or similar.
Although not many Dual GPU cards are on the market at the moment, it
seems likely that Dual or Quad GPU cards will become the norm in the
near future.

For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
I have successfully managed to passthru one of the GPU's on the card
with success.  However I get a BSOD on the second one.

I'm wondering if compiling in the VGA BIOS may help?
If so, where is a good resource on how I could do that?


Cards show in lspci as follows:

12:00.0 Display controller: ATI Technologies Inc Device 671d
12:00.1 Audio device: ATI Technologies Inc Device aa80
13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
13:00.1 Audio device: ATI Technologies Inc Device aa80


ATI Technologies Inc Device aa80
             +-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-04.0-[0000:10-13]----00.0-[0000:11-13]--+-04.0-[0000:13]--+-00.0
 ATI Technologies Inc Device 671d
             |                                         |
                          |                 \-00.1  ATI Technologies
Inc Device aa80
             |                                         |
                          \-08.0-[0000:12]--+-00.0  ATI Technologies
Inc Device 671d
             |                                         |
                                            \-00.1  ATI Technologies
Inc Device aa80


More details on the devices themselves.

12:00.0 Display controller: ATI Technologies Inc Device 671d
        Subsystem: ATI Technologies Inc Device 1b2a
        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-
        Interrupt: pin A routed to IRQ 30
        Region 0: Memory at 80000000 (64-bit, prefetchable) [disabled]
[size=256M]
        Region 2: Memory at fb6c0000 (64-bit, non-prefetchable)
[disabled] [size=128K]
        Region 4: I/O ports at 9000 [disabled] [size=256]
        Expansion ROM at fb6a0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr- TransPend-
                LnkCap: Port #8, Speed 2.5GT/s, Width x16, ASPM L0s
L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [100] Vendor Specific Information <?>
        Capabilities: [150] Advanced Error Reporting <?>
        Kernel driver in use: pciback


13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
        Subsystem: ATI Technologies Inc Device 0b2a
        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-
        Interrupt: pin A routed to IRQ 30
        Region 0: Memory at 90000000 (64-bit, prefetchable) [disabled]
[size=256M]
        Region 2: Memory at fb7c0000 (64-bit, non-prefetchable)
[disabled] [size=128K]
        Region 4: I/O ports at a000 [disabled] [size=256]
        Expansion ROM at fb7a0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr- TransPend-
                LnkCap: Port #4, Speed 2.5GT/s, Width x16, ASPM L0s
L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [100] Vendor Specific Information <?>
        Capabilities: [150] Advanced Error Reporting <?>
        Kernel driver in use: pciback

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 04:59:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 04: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 1RzhoW-0006lC-5G; Tue, 21 Feb 2012 04:58:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzhoT-0006l7-Vq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 04:58:54 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329800327!3722397!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2465 invoked from network); 21 Feb 2012 04:58:47 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 04:58:47 -0000
Received: by wgbdr13 with SMTP id dr13so4673805wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 20:58:47 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr28099643wib.3.1329800327619 (num_hops
	= 1); Mon, 20 Feb 2012 20:58:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr23436898wib.3.1329800327525; Mon,
	20 Feb 2012 20:58:47 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 20:58:47 -0800 (PST)
Date: Mon, 20 Feb 2012 20:58:47 -0800
Message-ID: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQkX1Q84cGcTG//icLP8N0azA1w5y4tQsKJGWojS6BYTD+TMJOlt8GNgarxqf4dZzwKn4xM4
Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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

Is it possible in Xen that with a dual GPU graphics card which appears
as two separately addressable PCI devices to pass each
GPU to a separate guest?  Although I didn't think this was initially
possible, VMWare supports it.
It's useful under xen for increasing virtual server density when
providing virtual desktops or similar.
Although not many Dual GPU cards are on the market at the moment, it
seems likely that Dual or Quad GPU cards will become the norm in the
near future.

For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
I have successfully managed to passthru one of the GPU's on the card
with success.  However I get a BSOD on the second one.

I'm wondering if compiling in the VGA BIOS may help?
If so, where is a good resource on how I could do that?


Cards show in lspci as follows:

12:00.0 Display controller: ATI Technologies Inc Device 671d
12:00.1 Audio device: ATI Technologies Inc Device aa80
13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
13:00.1 Audio device: ATI Technologies Inc Device aa80


ATI Technologies Inc Device aa80
             +-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-04.0-[0000:10-13]----00.0-[0000:11-13]--+-04.0-[0000:13]--+-00.0
 ATI Technologies Inc Device 671d
             |                                         |
                          |                 \-00.1  ATI Technologies
Inc Device aa80
             |                                         |
                          \-08.0-[0000:12]--+-00.0  ATI Technologies
Inc Device 671d
             |                                         |
                                            \-00.1  ATI Technologies
Inc Device aa80


More details on the devices themselves.

12:00.0 Display controller: ATI Technologies Inc Device 671d
        Subsystem: ATI Technologies Inc Device 1b2a
        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-
        Interrupt: pin A routed to IRQ 30
        Region 0: Memory at 80000000 (64-bit, prefetchable) [disabled]
[size=256M]
        Region 2: Memory at fb6c0000 (64-bit, non-prefetchable)
[disabled] [size=128K]
        Region 4: I/O ports at 9000 [disabled] [size=256]
        Expansion ROM at fb6a0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr- TransPend-
                LnkCap: Port #8, Speed 2.5GT/s, Width x16, ASPM L0s
L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [100] Vendor Specific Information <?>
        Capabilities: [150] Advanced Error Reporting <?>
        Kernel driver in use: pciback


13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
        Subsystem: ATI Technologies Inc Device 0b2a
        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-
        Interrupt: pin A routed to IRQ 30
        Region 0: Memory at 90000000 (64-bit, prefetchable) [disabled]
[size=256M]
        Region 2: Memory at fb7c0000 (64-bit, non-prefetchable)
[disabled] [size=128K]
        Region 4: I/O ports at a000 [disabled] [size=256]
        Expansion ROM at fb7a0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr- TransPend-
                LnkCap: Port #4, Speed 2.5GT/s, Width x16, ASPM L0s
L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [100] Vendor Specific Information <?>
        Capabilities: [150] Advanced Error Reporting <?>
        Kernel driver in use: pciback

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 05:52:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 05:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzidg-0007ue-Rw; Tue, 21 Feb 2012 05:51:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Rzidf-0007uW-9p
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 05:51:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329803500!14181723!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM0ODU4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11162 invoked from network); 21 Feb 2012 05:51:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 05:51:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Feb 2012 21:51:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108823105"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2012 21:51:37 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 13:50:01 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 21 Feb 2012 13:50:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 13:49:59 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM7zOZqETlTTaR00eoPTQ1GukvM5ZG0aeQ
Date: Tue, 21 Feb 2012 05:49:58 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
In-Reply-To: <20120219182339.GA11882@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>>>> +struct pv_pad_ops {
>>>>> +	int (*acpi_pad_init)(void);
>>>>> +	void (*acpi_pad_exit)(void);
>>>>> +};
>>>>> +
>>> 
>>> Looking at this a bit closer I am not sure why you choose the
>>> paravirt interface for this? There is another one - the x86 that
>>> could have been choosen. Or introduce a new one that is specific to
>>> ACPI. 
>>> 
>>> I am curious - what was the reason for using the paravirt interface?
>>> I understand it does get the job done, but it seems a bit overkill
>>> when something simple could have been used?
>>> 
>> 
>> It uses paravirt interface to avoid some code like 'xen_...' in
>> native code path (acpi_pad.c). 
>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>> seems it's much simpler.  
> 
> arch/x86/include/asm/x86_init.h
> 
> But before you go that way let me ask you another question - can ACPI
> PAD 
> be used on ARM or IA64? If so, wouldn't this fail compilation as this
> pvops structure is not defined on IA64?

Ideally ACPI PAD is not bound to some arch, so IMO it could be used at least on IA64 (through currently no real PAD on IA64 platform as far as I know).
However, in native acpi_pad implementation, it indeed depends on X86 for reason like mwait.
So for xen acpi_pad, I think it's OK to choose x86, defining an acpi_pad_ops at x86_init.c which would be overwritten when xen init.

Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as 'bool', which would disable native acpi_pad module.

Your opinion?

Thanks,
Jinsong

> 
> The other thing I am not comfortable about is that the pvops structure
> are used for low-level code. Not for higher up, like ACPI. For that
> another structure seems more prudent. Perhaps something like the x86
> one, but specific to ACPI?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 05:52:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 05:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzidg-0007ue-Rw; Tue, 21 Feb 2012 05:51:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1Rzidf-0007uW-9p
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 05:51:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329803500!14181723!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM0ODU4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11162 invoked from network); 21 Feb 2012 05:51:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 05:51:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Feb 2012 21:51:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108823105"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2012 21:51:37 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 13:50:01 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 21 Feb 2012 13:50:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 13:49:59 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM7zOZqETlTTaR00eoPTQ1GukvM5ZG0aeQ
Date: Tue, 21 Feb 2012 05:49:58 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
In-Reply-To: <20120219182339.GA11882@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>>>> +struct pv_pad_ops {
>>>>> +	int (*acpi_pad_init)(void);
>>>>> +	void (*acpi_pad_exit)(void);
>>>>> +};
>>>>> +
>>> 
>>> Looking at this a bit closer I am not sure why you choose the
>>> paravirt interface for this? There is another one - the x86 that
>>> could have been choosen. Or introduce a new one that is specific to
>>> ACPI. 
>>> 
>>> I am curious - what was the reason for using the paravirt interface?
>>> I understand it does get the job done, but it seems a bit overkill
>>> when something simple could have been used?
>>> 
>> 
>> It uses paravirt interface to avoid some code like 'xen_...' in
>> native code path (acpi_pad.c). 
>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>> seems it's much simpler.  
> 
> arch/x86/include/asm/x86_init.h
> 
> But before you go that way let me ask you another question - can ACPI
> PAD 
> be used on ARM or IA64? If so, wouldn't this fail compilation as this
> pvops structure is not defined on IA64?

Ideally ACPI PAD is not bound to some arch, so IMO it could be used at least on IA64 (through currently no real PAD on IA64 platform as far as I know).
However, in native acpi_pad implementation, it indeed depends on X86 for reason like mwait.
So for xen acpi_pad, I think it's OK to choose x86, defining an acpi_pad_ops at x86_init.c which would be overwritten when xen init.

Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as 'bool', which would disable native acpi_pad module.

Your opinion?

Thanks,
Jinsong

> 
> The other thing I am not comfortable about is that the pvops structure
> are used for low-level code. Not for higher up, like ACPI. For that
> another structure seems more prudent. Perhaps something like the x86
> one, but specific to ACPI?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:08:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:08:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzitZ-00089w-PD; Tue, 21 Feb 2012 06:08:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzitY-00089o-NW
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329804485!15139595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11517 invoked from network); 21 Feb 2012 06:08:06 -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;
	21 Feb 2012 06:08:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,455,1325462400"; d="scan'208";a="10826837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 06:08:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 06:08:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzitR-0004Eg-4W;
	Tue, 21 Feb 2012 06:08:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzitR-0005To-3I;
	Tue, 21 Feb 2012 06:08:05 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11990-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 06:08:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11990: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11990 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11990/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:08:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:08:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzitZ-00089w-PD; Tue, 21 Feb 2012 06:08:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzitY-00089o-NW
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329804485!15139595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11517 invoked from network); 21 Feb 2012 06:08:06 -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;
	21 Feb 2012 06:08:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,455,1325462400"; d="scan'208";a="10826837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 06:08:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 06:08:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzitR-0004Eg-4W;
	Tue, 21 Feb 2012 06:08:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzitR-0005To-3I;
	Tue, 21 Feb 2012 06:08:05 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11990-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 06:08:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11990: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11990 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11990/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzjCN-0008Ox-5F; Tue, 21 Feb 2012 06:27:39 +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 1RzjCL-0008Os-4O
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:27:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329805605!61360898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21583 invoked from network); 21 Feb 2012 06:26:45 -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;
	21 Feb 2012 06:26:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,455,1325462400"; d="scan'208";a="10826948"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 06:26:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 06:26:33 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzjBJ-0004Ni-5R;
	Tue, 21 Feb 2012 06:26:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzjBJ-0006WL-4Y;
	Tue, 21 Feb 2012 06:26:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11991-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 06:26:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11991: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11991 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11991/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11988

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzjCN-0008Ox-5F; Tue, 21 Feb 2012 06:27:39 +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 1RzjCL-0008Os-4O
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:27:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329805605!61360898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21583 invoked from network); 21 Feb 2012 06:26:45 -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;
	21 Feb 2012 06:26:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,455,1325462400"; d="scan'208";a="10826948"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 06:26:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 06:26:33 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzjBJ-0004Ni-5R;
	Tue, 21 Feb 2012 06:26:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzjBJ-0006WL-4Y;
	Tue, 21 Feb 2012 06:26:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11991-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 06:26:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11991: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11991 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11991/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11988

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:35:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzjJp-00007D-3e; Tue, 21 Feb 2012 06:35:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzjJn-000077-Un
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:35:20 +0000
Received: from [85.158.139.83:58382] by server-11.bemta-5.messagelabs.com id
	9C/65-14397-72B334F4; Tue, 21 Feb 2012 06:35:19 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329806118!15830280!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13442 invoked from network); 21 Feb 2012 06:35:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 06:35:18 -0000
Received: by werb14 with SMTP id b14so13948822wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:35:17 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.101.37 as permitted sender) client-ip=10.180.101.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.101.37 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.101.37])
	by 10.180.101.37 with SMTP id fd5mr26494054wib.1.1329806117930
	(num_hops = 1); Mon, 20 Feb 2012 22:35:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.101.37 with SMTP id fd5mr22077356wib.1.1329806117821; Mon,
	20 Feb 2012 22:35:17 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 22:35:17 -0800 (PST)
Date: Mon, 20 Feb 2012 22:35:17 -0800
Message-ID: <CAMrHX2UmxH7-qR-BLSqN3hscFM8o9T6ZoWhm6aUCTfFyvsMpsg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQkx/MuF9Xj+vTGOkjdyGXpDsJvpQdbe2tWs11iADQLpaUIoZVTQY7nRz7fFglC3Ymsrgs63
Subject: [Xen-devel] VGA Passthru 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

I see a lot of changes in for vga passthru graphics in xen-unstable vs xen 4.1.2

What is the current status of VGA passthru in general?

The wiki may be out of date.  I may be able to help updating that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:35:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzjJp-00007D-3e; Tue, 21 Feb 2012 06:35:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzjJn-000077-Un
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:35:20 +0000
Received: from [85.158.139.83:58382] by server-11.bemta-5.messagelabs.com id
	9C/65-14397-72B334F4; Tue, 21 Feb 2012 06:35:19 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329806118!15830280!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13442 invoked from network); 21 Feb 2012 06:35:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 06:35:18 -0000
Received: by werb14 with SMTP id b14so13948822wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 20 Feb 2012 22:35:17 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.101.37 as permitted sender) client-ip=10.180.101.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.101.37 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.101.37])
	by 10.180.101.37 with SMTP id fd5mr26494054wib.1.1329806117930
	(num_hops = 1); Mon, 20 Feb 2012 22:35:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.101.37 with SMTP id fd5mr22077356wib.1.1329806117821; Mon,
	20 Feb 2012 22:35:17 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Mon, 20 Feb 2012 22:35:17 -0800 (PST)
Date: Mon, 20 Feb 2012 22:35:17 -0800
Message-ID: <CAMrHX2UmxH7-qR-BLSqN3hscFM8o9T6ZoWhm6aUCTfFyvsMpsg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQkx/MuF9Xj+vTGOkjdyGXpDsJvpQdbe2tWs11iADQLpaUIoZVTQY7nRz7fFglC3Ymsrgs63
Subject: [Xen-devel] VGA Passthru 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

I see a lot of changes in for vga passthru graphics in xen-unstable vs xen 4.1.2

What is the current status of VGA passthru in general?

The wiki may be out of date.  I may be able to help updating that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzjcP-0000Jm-Sq; Tue, 21 Feb 2012 06:54:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RzjcO-0000Jh-3T
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:54:32 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329807264!15695065!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM0ODU4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8129 invoked from network); 21 Feb 2012 06:54:25 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-216.messagelabs.com with SMTP;
	21 Feb 2012 06:54:25 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Feb 2012 22:54:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108838571"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2012 22:54:23 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 14:54:05 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 14:54:02 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Matthew Hook <matthew.hook@otoy.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
Thread-Index: AQHM8FX50QDHd0kQ0kulzqAWlZYHAZZG6C3A
Date: Tue, 21 Feb 2012 06:54:03 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
References: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
In-Reply-To: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@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
Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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

If the card has two  full-fledged  PCI-e graphics functions, I think you can follow the link(http://wiki.xen.org/wiki/Xen_VGA_Passthrough) to do your passthru work. It depends on Intel's VT-d or AMD's IOMMU technology, so please make sure all required components are ready in your system.   I think Xen's mailing list archive also has some detailed discussions about how to passthru one graphics device to the guest and what's difference compared with general PCIe device assignment. 
Xiantao

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Matthew Hook
> Sent: Tuesday, February 21, 2012 12:59 PM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
> 
> Is it possible in Xen that with a dual GPU graphics card which appears as two
> separately addressable PCI devices to pass each GPU to a separate guest?
> Although I didn't think this was initially possible, VMWare supports it.
> It's useful under xen for increasing virtual server density when providing
> virtual desktops or similar.
> Although not many Dual GPU cards are on the market at the moment, it
> seems likely that Dual or Quad GPU cards will become the norm in the near
> future.
> 
> For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
> I have successfully managed to passthru one of the GPU's on the card with
> success.  However I get a BSOD on the second one.
> 
> I'm wondering if compiling in the VGA BIOS may help?
> If so, where is a good resource on how I could do that?
> 
> 
> Cards show in lspci as follows:
> 
> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> 12:00.1 Audio device: ATI Technologies Inc Device aa80
> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
> 13:00.1 Audio device: ATI Technologies Inc Device aa80
> 
> 
> ATI Technologies Inc Device aa80
>              +-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-04.0-[0000:10-13]----00.0-
> [0000:11-13]--+-04.0-[0000:13]--+-00.0
>  ATI Technologies Inc Device 671d
>              |                                         |
>                           |                 \-00.1  ATI Technologies
> Inc Device aa80
>              |                                         |
>                           \-08.0-[0000:12]--+-00.0  ATI Technologies Inc Device 671d
>              |                                         |
>                                             \-00.1  ATI Technologies Inc Device aa80
> 
> 
> More details on the devices themselves.
> 
> 12:00.0 Display controller: ATI Technologies Inc Device 671d
>         Subsystem: ATI Technologies Inc Device 1b2a
>         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-
>         Interrupt: pin A routed to IRQ 30
>         Region 0: Memory at 80000000 (64-bit, prefetchable) [disabled]
> [size=256M]
>         Region 2: Memory at fb6c0000 (64-bit, non-prefetchable) [disabled]
> [size=128K]
>         Region 4: I/O ports at 9000 [disabled] [size=256]
>         Expansion ROM at fb6a0000 [disabled] [size=128K]
>         Capabilities: [50] Power Management version 3
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1
> unlimited
>                         ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
> AuxPwr- TransPend-
>                 LnkCap: Port #8, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0
> <64ns, L1 <1us
>                         ClockPM- Suprise- LLActRep- BwNot-
>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                 Address: 0000000000000000  Data: 0000
>         Capabilities: [100] Vendor Specific Information <?>
>         Capabilities: [150] Advanced Error Reporting <?>
>         Kernel driver in use: pciback
> 
> 
> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
>         Subsystem: ATI Technologies Inc Device 0b2a
>         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-
>         Interrupt: pin A routed to IRQ 30
>         Region 0: Memory at 90000000 (64-bit, prefetchable) [disabled]
> [size=256M]
>         Region 2: Memory at fb7c0000 (64-bit, non-prefetchable) [disabled]
> [size=128K]
>         Region 4: I/O ports at a000 [disabled] [size=256]
>         Expansion ROM at fb7a0000 [disabled] [size=128K]
>         Capabilities: [50] Power Management version 3
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1
> unlimited
>                         ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
> AuxPwr- TransPend-
>                 LnkCap: Port #4, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0
> <64ns, L1 <1us
>                         ClockPM- Suprise- LLActRep- BwNot-
>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                 Address: 0000000000000000  Data: 0000
>         Capabilities: [100] Vendor Specific Information <?>
>         Capabilities: [150] Advanced Error Reporting <?>
>         Kernel driver in use: pciback
> 
> Matt
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 06:55:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 06:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzjcP-0000Jm-Sq; Tue, 21 Feb 2012 06:54:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1RzjcO-0000Jh-3T
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 06:54:32 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329807264!15695065!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM0ODU4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8129 invoked from network); 21 Feb 2012 06:54:25 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-216.messagelabs.com with SMTP;
	21 Feb 2012 06:54:25 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Feb 2012 22:54:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108838571"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2012 22:54:23 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 14:54:05 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 14:54:02 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Matthew Hook <matthew.hook@otoy.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
Thread-Index: AQHM8FX50QDHd0kQ0kulzqAWlZYHAZZG6C3A
Date: Tue, 21 Feb 2012 06:54:03 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
References: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
In-Reply-To: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@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
Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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

If the card has two  full-fledged  PCI-e graphics functions, I think you can follow the link(http://wiki.xen.org/wiki/Xen_VGA_Passthrough) to do your passthru work. It depends on Intel's VT-d or AMD's IOMMU technology, so please make sure all required components are ready in your system.   I think Xen's mailing list archive also has some detailed discussions about how to passthru one graphics device to the guest and what's difference compared with general PCIe device assignment. 
Xiantao

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Matthew Hook
> Sent: Tuesday, February 21, 2012 12:59 PM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
> 
> Is it possible in Xen that with a dual GPU graphics card which appears as two
> separately addressable PCI devices to pass each GPU to a separate guest?
> Although I didn't think this was initially possible, VMWare supports it.
> It's useful under xen for increasing virtual server density when providing
> virtual desktops or similar.
> Although not many Dual GPU cards are on the market at the moment, it
> seems likely that Dual or Quad GPU cards will become the norm in the near
> future.
> 
> For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
> I have successfully managed to passthru one of the GPU's on the card with
> success.  However I get a BSOD on the second one.
> 
> I'm wondering if compiling in the VGA BIOS may help?
> If so, where is a good resource on how I could do that?
> 
> 
> Cards show in lspci as follows:
> 
> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> 12:00.1 Audio device: ATI Technologies Inc Device aa80
> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
> 13:00.1 Audio device: ATI Technologies Inc Device aa80
> 
> 
> ATI Technologies Inc Device aa80
>              +-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-04.0-[0000:10-13]----00.0-
> [0000:11-13]--+-04.0-[0000:13]--+-00.0
>  ATI Technologies Inc Device 671d
>              |                                         |
>                           |                 \-00.1  ATI Technologies
> Inc Device aa80
>              |                                         |
>                           \-08.0-[0000:12]--+-00.0  ATI Technologies Inc Device 671d
>              |                                         |
>                                             \-00.1  ATI Technologies Inc Device aa80
> 
> 
> More details on the devices themselves.
> 
> 12:00.0 Display controller: ATI Technologies Inc Device 671d
>         Subsystem: ATI Technologies Inc Device 1b2a
>         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-
>         Interrupt: pin A routed to IRQ 30
>         Region 0: Memory at 80000000 (64-bit, prefetchable) [disabled]
> [size=256M]
>         Region 2: Memory at fb6c0000 (64-bit, non-prefetchable) [disabled]
> [size=128K]
>         Region 4: I/O ports at 9000 [disabled] [size=256]
>         Expansion ROM at fb6a0000 [disabled] [size=128K]
>         Capabilities: [50] Power Management version 3
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1
> unlimited
>                         ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
> AuxPwr- TransPend-
>                 LnkCap: Port #8, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0
> <64ns, L1 <1us
>                         ClockPM- Suprise- LLActRep- BwNot-
>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                 Address: 0000000000000000  Data: 0000
>         Capabilities: [100] Vendor Specific Information <?>
>         Capabilities: [150] Advanced Error Reporting <?>
>         Kernel driver in use: pciback
> 
> 
> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
>         Subsystem: ATI Technologies Inc Device 0b2a
>         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-
>         Interrupt: pin A routed to IRQ 30
>         Region 0: Memory at 90000000 (64-bit, prefetchable) [disabled]
> [size=256M]
>         Region 2: Memory at fb7c0000 (64-bit, non-prefetchable) [disabled]
> [size=128K]
>         Region 4: I/O ports at a000 [disabled] [size=256]
>         Expansion ROM at fb7a0000 [disabled] [size=128K]
>         Capabilities: [50] Power Management version 3
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1
> unlimited
>                         ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
> AuxPwr- TransPend-
>                 LnkCap: Port #4, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0
> <64ns, L1 <1us
>                         ClockPM- Suprise- LLActRep- BwNot-
>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train-
> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                 Address: 0000000000000000  Data: 0000
>         Capabilities: [100] Vendor Specific Information <?>
>         Capabilities: [150] Advanced Error Reporting <?>
>         Kernel driver in use: pciback
> 
> Matt
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:04:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzkhZ-00027M-Gm; Tue, 21 Feb 2012 08:03:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RzkhY-00027D-0i
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 08:03:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329811429!4997183!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4470 invoked from network); 21 Feb 2012 08:03:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 08:03:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 08:03:48 +0000
Message-Id: <4F435DED0200007800074080@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 08:03:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad RzeszutekWilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> Core parking is a power control feature and it can co-work with NPTM
>>> to control system power budget through online/offline some CPUs in
>>> the system. These patches implement core parking feature for xen.
>>> They consist of 2 
>>> parts: dom0 patches and xen hypervisor patches.
>>> 
>>> At dom0 side, patches include
>>> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic,
>>> providing a native interface for natvie platform and a paravirt
>>> template for paravirt platform, so that os can implicitly hook to
>>> proper ops accordingly; [Patch 2/3] redirect paravirt template to
>>> Xen pv ops; [Patch 3/3] implement Xen pad logic, and when getting
>>> pad device 
>>> notification, it hypercalls to Xen hypervisor for core parking. Due
>>> to the characteristic of xen continue_hypercall_on_cpu, dom0
>>> seperately send/get 
>>> core parking request/result;
>>> 
>>> At Xen hypervisor side, patches include
>>> [Patch 1/2] implement hypercall through which dom0 send core parking
>>> request, and get core parking result;
>>> [Patch 2/2] implement Xen core parking. Different core parking
>>> sequence has different power/performance result, due to cpu
>>> socket/core/thread topology. This patch provide power-first and
>>> performance-first policies, users can choose core parking policy on
>>> their own demand, considering power and performance tradeoff.
>> 
>> Does this really need to be implemented in the hypervisor? All this
>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>> have hypercall interfaces already. So I'd rather see this as being
>> an extension to Dom0's pCPU management patches (which aren't
>> upstream afaict)...
>> 
>> Jan
> 
> It's a design choice. Core parking is not only a wrapper around cpu_down/up, 
> it also involves policy algorithms which depend on physical cpu topology and 
> cpu_online/present_map, etc. Implement core parking at dom0 side need expose 
> all those information to dom0, with potential issues (like coherence), while 
> dom0 still need do same work as hypervisor.
> Our idea is to keep dom0 as ACPI parser, then hypercall and do rest things 
> at hypervisor side.

Actually, after some more thought, I don't even think this ought to
be implemented in the Dom0 kernel, but in user space altogether.
Afaict all information necessary is already being exposed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:04:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzkhZ-00027M-Gm; Tue, 21 Feb 2012 08:03:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RzkhY-00027D-0i
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 08:03:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329811429!4997183!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4470 invoked from network); 21 Feb 2012 08:03:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 08:03:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 08:03:48 +0000
Message-Id: <4F435DED0200007800074080@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 08:03:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad RzeszutekWilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> Core parking is a power control feature and it can co-work with NPTM
>>> to control system power budget through online/offline some CPUs in
>>> the system. These patches implement core parking feature for xen.
>>> They consist of 2 
>>> parts: dom0 patches and xen hypervisor patches.
>>> 
>>> At dom0 side, patches include
>>> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic,
>>> providing a native interface for natvie platform and a paravirt
>>> template for paravirt platform, so that os can implicitly hook to
>>> proper ops accordingly; [Patch 2/3] redirect paravirt template to
>>> Xen pv ops; [Patch 3/3] implement Xen pad logic, and when getting
>>> pad device 
>>> notification, it hypercalls to Xen hypervisor for core parking. Due
>>> to the characteristic of xen continue_hypercall_on_cpu, dom0
>>> seperately send/get 
>>> core parking request/result;
>>> 
>>> At Xen hypervisor side, patches include
>>> [Patch 1/2] implement hypercall through which dom0 send core parking
>>> request, and get core parking result;
>>> [Patch 2/2] implement Xen core parking. Different core parking
>>> sequence has different power/performance result, due to cpu
>>> socket/core/thread topology. This patch provide power-first and
>>> performance-first policies, users can choose core parking policy on
>>> their own demand, considering power and performance tradeoff.
>> 
>> Does this really need to be implemented in the hypervisor? All this
>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>> have hypercall interfaces already. So I'd rather see this as being
>> an extension to Dom0's pCPU management patches (which aren't
>> upstream afaict)...
>> 
>> Jan
> 
> It's a design choice. Core parking is not only a wrapper around cpu_down/up, 
> it also involves policy algorithms which depend on physical cpu topology and 
> cpu_online/present_map, etc. Implement core parking at dom0 side need expose 
> all those information to dom0, with potential issues (like coherence), while 
> dom0 still need do same work as hypervisor.
> Our idea is to keep dom0 as ACPI parser, then hypercall and do rest things 
> at hypervisor side.

Actually, after some more thought, I don't even think this ought to
be implemented in the Dom0 kernel, but in user space altogether.
Afaict all information necessary is already being exposed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:48:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzlNI-0003Dn-Lm; Tue, 21 Feb 2012 08:47: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 1RzlNH-0003De-3x
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329813968!61378929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22595 invoked from network); 21 Feb 2012 08:46:08 -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;
	21 Feb 2012 08:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10829587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:46:58 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:46:58 +0000
Message-ID: <1329814018.25232.3.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 21 Feb 2012 08:46:58 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> Updates to the layout of the HVM parameter and information page
> defined in hvm_info_table.h. The SMBIOS pass-through tables are
> written to the bottom half of this page.

We would like to eventually get rid of the HVM info page and would
certainly like to avoid adding anything further there. Could this data
not be supplied via xenstore? Certainly they could and should be for the
ones controlled by the flags entry which you add.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:48:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzlNI-0003Dn-Lm; Tue, 21 Feb 2012 08:47: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 1RzlNH-0003De-3x
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329813968!61378929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22595 invoked from network); 21 Feb 2012 08:46:08 -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;
	21 Feb 2012 08:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10829587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:46:58 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:46:58 +0000
Message-ID: <1329814018.25232.3.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 21 Feb 2012 08:46:58 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> Updates to the layout of the HVM parameter and information page
> defined in hvm_info_table.h. The SMBIOS pass-through tables are
> written to the bottom half of this page.

We would like to eventually get rid of the HVM info page and would
certainly like to avoid adding anything further there. Could this data
not be supplied via xenstore? Certainly they could and should be for the
ones controlled by the flags entry which you add.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:49:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzlOO-0003G4-Fr; Tue, 21 Feb 2012 08:48:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzlOM-0003Fj-NQ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:48:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329814082!6017546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9421 invoked from network); 21 Feb 2012 08:48:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 08:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10829634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:48:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:48:02 +0000
Message-ID: <1329814082.25232.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 21 Feb 2012 08:48:02 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -static void validate_hvm_info(struct hvm_info_table *t)
> +static int validate_hvm_info_table(uint8_t *table, uint32_t
> table_length,
> +    const char *table_sig, const char *sig)
>  {
> -    uint8_t *ptr = (uint8_t *)t;
>      uint8_t sum = 0;
>      int i;
>  
> -    if ( strncmp(t->signature, "HVM INFO", 8) )
> +    if (table_length == 0)
> +        printf("Empty HVM info table: %.*s\n", 8, sig);
> +
> +    /* NOTE made this a common routine to validate all HVM tables.
> Removed 
> +       BUG() on failure in here - let the caller decide if a checksum
> failure
> +       warrants that */

I think comments about what code looked like historically, what changed
and why belong in the commit message, not inline in the code.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:49:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzlOO-0003G4-Fr; Tue, 21 Feb 2012 08:48:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzlOM-0003Fj-NQ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:48:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329814082!6017546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9421 invoked from network); 21 Feb 2012 08:48:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 08:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10829634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:48:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:48:02 +0000
Message-ID: <1329814082.25232.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 21 Feb 2012 08:48:02 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -static void validate_hvm_info(struct hvm_info_table *t)
> +static int validate_hvm_info_table(uint8_t *table, uint32_t
> table_length,
> +    const char *table_sig, const char *sig)
>  {
> -    uint8_t *ptr = (uint8_t *)t;
>      uint8_t sum = 0;
>      int i;
>  
> -    if ( strncmp(t->signature, "HVM INFO", 8) )
> +    if (table_length == 0)
> +        printf("Empty HVM info table: %.*s\n", 8, sig);
> +
> +    /* NOTE made this a common routine to validate all HVM tables.
> Removed 
> +       BUG() on failure in here - let the caller decide if a checksum
> failure
> +       warrants that */

I think comments about what code looked like historically, what changed
and why belong in the commit message, not inline in the code.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08: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 1RzlS1-0003St-U5; Tue, 21 Feb 2012 08:51:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzlS0-0003SG-Dx
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329814310!9278506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3275 invoked from network); 21 Feb 2012 08:51:50 -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;
	21 Feb 2012 08:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10829739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:51:50 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:51:50 +0000
Message-ID: <1329814309.25232.8.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Date: Tue, 21 Feb 2012 08:51:49 +0000
In-Reply-To: <000001ccf041$edd791d0$c986b570$@ark-net.org>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
	<CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
	<1329134175.31256.71.camel@zakaz.uk.xensource.com>
	<000001ccf041$edd791d0$c986b570$@ark-net.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	'Fantu' <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 02:38 +0000, Michael A. Collins wrote:
> Is it my understanding that currently there is no way to pass the -vga
> option to qemu using the xl cfg file?  This seems in my mind a very trivial
> thing to do, I don't want to reinvent the wheel if I'm just missing
> something.

It seems you can arrange for "-std-vga" or "-vga std" (depending on if
you are using traditional or upstream qemu) or nothing but nothing more
complex than that.

What is it that you are trying to do by passing such an option?

Do you know if this this option was exposed in xend? If so then how?

(as a workaround there is an device_model_args{,_pv,_hvm} trio of
options in xl which allows arbitrary option to be passed to qemu)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 08:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 08: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 1RzlS1-0003St-U5; Tue, 21 Feb 2012 08:51:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzlS0-0003SG-Dx
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329814310!9278506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3275 invoked from network); 21 Feb 2012 08:51:50 -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;
	21 Feb 2012 08:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10829739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:51:50 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:51:50 +0000
Message-ID: <1329814309.25232.8.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Date: Tue, 21 Feb 2012 08:51:49 +0000
In-Reply-To: <000001ccf041$edd791d0$c986b570$@ark-net.org>
References: <1329128265.31256.24.camel@zakaz.uk.xensource.com>
	<1329131119975-5478798.post@n5.nabble.com>
	<CAJJyHjKUP=gs6-hprzO5Dgx-hWRetJcxuCwi7VD8QCneOHgP5Q@mail.gmail.com>
	<1329134175.31256.71.camel@zakaz.uk.xensource.com>
	<000001ccf041$edd791d0$c986b570$@ark-net.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	'Fantu' <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] 4.2 TODO update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 02:38 +0000, Michael A. Collins wrote:
> Is it my understanding that currently there is no way to pass the -vga
> option to qemu using the xl cfg file?  This seems in my mind a very trivial
> thing to do, I don't want to reinvent the wheel if I'm just missing
> something.

It seems you can arrange for "-std-vga" or "-vga std" (depending on if
you are using traditional or upstream qemu) or nothing but nothing more
complex than that.

What is it that you are trying to do by passing such an option?

Do you know if this this option was exposed in xend? If so then how?

(as a workaround there is an device_model_args{,_pv,_hvm} trio of
options in xl which allows arbitrary option to be passed to qemu)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzlZY-0003nz-TG; Tue, 21 Feb 2012 08:59:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzlZW-0003nq-QF
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:59:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329814776!2856243!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19044 invoked from network); 21 Feb 2012 08:59:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 08:59:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="c'?scan'208";a="10830296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:59: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.213.0;
	Tue, 21 Feb 2012 08:59:36 +0000
Message-ID: <1329814775.25232.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 21 Feb 2012 08:59:35 +0000
In-Reply-To: <20120220183207.GA7170@phenom.dumpdata.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Type: multipart/mixed; boundary="=-n13xQx9TYwojMRl8WiQl"
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=-n13xQx9TYwojMRl8WiQl
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On Mon, 2012-02-20 at 18:32 +0000, Konrad Rzeszutek Wilk wrote:
[...]
> sh-4.1# xm create /mnt/lab/latest/test.xm 
> Using config file "/mnt/lab/latest/test.xm".
> Error: (1, 'Internal error', 'panic: xc_dom_core.c:273:
> xc_dom_do_gunzip: inflate failed (rc=-3)')

-3 == ESRCH? Seems unlikely...

Aha, in this context it is the return value of inflate() and therefore
it is Z_DATA_ERROR.

> And only on Intel.. and only if it is a 32-bit dom0. If I do the same
> test with a 64-bit dom0 I do not see this problem.

Different decompression libraries in your root filesystems perhaps? Can
you decompress the bzImage by hand? (perhaps using the attached bzeplode
to extract the compressed data payload)

Does it work with xl?

> Any thoughts of what it might be or what I should try out? My thought
> was to swap out the hypervisor (use a Xen 4.0) or unstable and see if
> I get the same result.

It is unlikely to be the hypervisor, more likely to be one of the
userspace components of the toolstack.

> But maybe there is something obvious out there?
> 


--=-n13xQx9TYwojMRl8WiQl
Content-Disposition: attachment; filename="bzexplode.c"
Content-Type: text/x-csrc; name="bzexplode.c"; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

#include <stdio.h>
#include <fcntl.h>
#include <stdint.h>
#include <unistd.h>

#include <inttypes.h>

#include <err.h>

#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>

int main(int argc, char **argv)
{
	int fd;
	struct stat sb;
	void *p;
	uint8_t *hdr;
	int setup_sectors;
	uint32_t compressed_payload_offset;
	uint32_t compressed_payload_length;

	if (argc != 2)
		errx(1, "usage: bzexplode <bzImage>");

	fd = open(argv[1], O_RDONLY);
	if (fd < 0)
		err(1, "open");

	if (fstat(fd, &sb) < 0)
		err(1, "fstat");

	p = mmap(0, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);
	if (p == MAP_FAILED)
		err(1, "mmap");

	hdr = p;
	setup_sectors = hdr[0x1f1];
	compressed_payload_offset = *(uint32_t*)&hdr[0x248];

	fprintf(stderr, "setup sectors %d\n", setup_sectors);

	compressed_payload_offset += (setup_sectors+1) * 512;

	//compressed_payload_length = *(uint32_t*)(p + compressed_payload_offset - 4);
	compressed_payload_length = *(uint32_t*)&hdr[0x24c];

	fprintf(stderr, "compressed_payload_offset %"PRIx32" (abs)\n",
		compressed_payload_offset);
	fprintf(stderr, "compressed_payload_length %"PRIx32"\n",
		compressed_payload_length);

	write(1,
	      p + compressed_payload_offset,
	      compressed_payload_length);
	return 0;
}

--=-n13xQx9TYwojMRl8WiQl
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--=-n13xQx9TYwojMRl8WiQl--


From xen-devel-bounces@lists.xen.org Tue Feb 21 09:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzlZY-0003nz-TG; Tue, 21 Feb 2012 08:59:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzlZW-0003nq-QF
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 08:59:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329814776!2856243!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19044 invoked from network); 21 Feb 2012 08:59:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 08:59:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="c'?scan'208";a="10830296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:59: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.213.0;
	Tue, 21 Feb 2012 08:59:36 +0000
Message-ID: <1329814775.25232.13.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 21 Feb 2012 08:59:35 +0000
In-Reply-To: <20120220183207.GA7170@phenom.dumpdata.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
Content-Type: multipart/mixed; boundary="=-n13xQx9TYwojMRl8WiQl"
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=-n13xQx9TYwojMRl8WiQl
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On Mon, 2012-02-20 at 18:32 +0000, Konrad Rzeszutek Wilk wrote:
[...]
> sh-4.1# xm create /mnt/lab/latest/test.xm 
> Using config file "/mnt/lab/latest/test.xm".
> Error: (1, 'Internal error', 'panic: xc_dom_core.c:273:
> xc_dom_do_gunzip: inflate failed (rc=-3)')

-3 == ESRCH? Seems unlikely...

Aha, in this context it is the return value of inflate() and therefore
it is Z_DATA_ERROR.

> And only on Intel.. and only if it is a 32-bit dom0. If I do the same
> test with a 64-bit dom0 I do not see this problem.

Different decompression libraries in your root filesystems perhaps? Can
you decompress the bzImage by hand? (perhaps using the attached bzeplode
to extract the compressed data payload)

Does it work with xl?

> Any thoughts of what it might be or what I should try out? My thought
> was to swap out the hypervisor (use a Xen 4.0) or unstable and see if
> I get the same result.

It is unlikely to be the hypervisor, more likely to be one of the
userspace components of the toolstack.

> But maybe there is something obvious out there?
> 


--=-n13xQx9TYwojMRl8WiQl
Content-Disposition: attachment; filename="bzexplode.c"
Content-Type: text/x-csrc; name="bzexplode.c"; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

#include <stdio.h>
#include <fcntl.h>
#include <stdint.h>
#include <unistd.h>

#include <inttypes.h>

#include <err.h>

#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>

int main(int argc, char **argv)
{
	int fd;
	struct stat sb;
	void *p;
	uint8_t *hdr;
	int setup_sectors;
	uint32_t compressed_payload_offset;
	uint32_t compressed_payload_length;

	if (argc != 2)
		errx(1, "usage: bzexplode <bzImage>");

	fd = open(argv[1], O_RDONLY);
	if (fd < 0)
		err(1, "open");

	if (fstat(fd, &sb) < 0)
		err(1, "fstat");

	p = mmap(0, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);
	if (p == MAP_FAILED)
		err(1, "mmap");

	hdr = p;
	setup_sectors = hdr[0x1f1];
	compressed_payload_offset = *(uint32_t*)&hdr[0x248];

	fprintf(stderr, "setup sectors %d\n", setup_sectors);

	compressed_payload_offset += (setup_sectors+1) * 512;

	//compressed_payload_length = *(uint32_t*)(p + compressed_payload_offset - 4);
	compressed_payload_length = *(uint32_t*)&hdr[0x24c];

	fprintf(stderr, "compressed_payload_offset %"PRIx32" (abs)\n",
		compressed_payload_offset);
	fprintf(stderr, "compressed_payload_length %"PRIx32"\n",
		compressed_payload_length);

	write(1,
	      p + compressed_payload_offset,
	      compressed_payload_length);
	return 0;
}

--=-n13xQx9TYwojMRl8WiQl
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--=-n13xQx9TYwojMRl8WiQl--


From xen-devel-bounces@lists.xen.org Tue Feb 21 09:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzley-00042A-TR; Tue, 21 Feb 2012 09:05:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzlex-00041u-Qc
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:05:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329815111!5008139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13417 invoked from network); 21 Feb 2012 09:05:11 -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 Feb 2012 09:05:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10830451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 09:05:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 09:05:10 +0000
Message-ID: <1329815109.25232.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 21 Feb 2012 09:05:09 +0000
In-Reply-To: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 10:44 +0000, George Dunlap wrote:
> On Fri, Feb 17, 2012 at 4:43 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > My point is that the memory knobs should be exposed to the user of xl as
> > semantically meaningful options without the need to refer to "the paging
> > target" or "the balloon target" which is why there should not IMHO be
> > "xl commands to adjust just ballooning and/or paging".
> 
> I disagree with this.  I agree completely that the default interface
> should just be, "How much memory is my VM using", and balloon drivers
> or paging shouldn't have to be of concern to them.  But there are
> times when admins will need to dig in deeper and play with specific
> values.  We should make the common case simple, and the complicated
> case possible.

yes, that seems reasonable. My main concern was that we appeared to be
about to expose the complicated case as the primary interface that we
would recommend people use in the common case / by default. I guess
that's what I was really trying to say when I said these advanced
options should be debug only (i.e. for debug read "advanced" too).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzley-00042A-TR; Tue, 21 Feb 2012 09:05:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzlex-00041u-Qc
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:05:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329815111!5008139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13417 invoked from network); 21 Feb 2012 09:05:11 -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 Feb 2012 09:05:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,456,1325462400"; d="scan'208";a="10830451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 09:05:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 09:05:10 +0000
Message-ID: <1329815109.25232.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 21 Feb 2012 09:05:09 +0000
In-Reply-To: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
References: <d368cf36d66c1e8df60b.1329378421@probook.site>
	<1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 10:44 +0000, George Dunlap wrote:
> On Fri, Feb 17, 2012 at 4:43 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > My point is that the memory knobs should be exposed to the user of xl as
> > semantically meaningful options without the need to refer to "the paging
> > target" or "the balloon target" which is why there should not IMHO be
> > "xl commands to adjust just ballooning and/or paging".
> 
> I disagree with this.  I agree completely that the default interface
> should just be, "How much memory is my VM using", and balloon drivers
> or paging shouldn't have to be of concern to them.  But there are
> times when admins will need to dig in deeper and play with specific
> values.  We should make the common case simple, and the complicated
> case possible.

yes, that seems reasonable. My main concern was that we appeared to be
about to expose the complicated case as the primary interface that we
would recommend people use in the common case / by default. I guess
that's what I was really trying to say when I said these advanced
options should be debug only (i.e. for debug read "advanced" too).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:14:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzlnn-0004Hs-UF; Tue, 21 Feb 2012 09:14:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rzlnm-0004Hk-Ng
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:14:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329815660!15397556!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28080 invoked from network); 21 Feb 2012 09:14:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:14:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:14:19 +0000
Message-Id: <4F436E75020000780007409F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:14:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Andrew Jones" <drjones@redhat.com>
References: <20120217185836.GA23942@phenom.dumpdata.com>
	<2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:

> 
> ----- Original Message -----
>> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
>> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
>> > > Hmm, I should maybe self-nack this. The bug that led me to
>> > > writing
>> > > it is likely only with older tooling, such as RHEL5's. The
>> > > problem
>> > > was if you attempted to detach a mounted disk twice, then the
>> > > second
>> > > time it would succeed. The guest had flipped to Closing on the
>> > > first
>> > > try, and thus didn't issue an error to xenbus on the second. I
>> > > see
>> > 
>> > Actually, it's even worse than I thought. Just a single attempt to
>> > detach the device will cause the guest grief (with RHEL5's tools
>> > anyway). Once xenbus shows the device is in the Closing state, then
>> > tasks accessing the device may hang.
>> > 
>> > > The reason I only say maybe self-nack though, is because this
>> > > state
>> > > change seemed to be thrown in with another fix[1]. I'm not sure
>> > > if
>> > > the new behavior on legacy hosts was considered or not. If not,
>> > > then
>> > > we can consider it now. Do we want to have deferred asynch
>> > > detaches
>> > > over protecting the guest from multiple detach calls on legacy
>> > > hosts?
>> > > 
>> > 
>> > I guess we can keep the feature and protect the guest with a patch
>> > like
>> > I'll send in a moment. It doesn't really work for me with a RHEL5
>> > host
>> > though. The deferred close works from the pov of the guest, but the
>> > state of the block device gets left in Closed after the guest
>> > unmounts
>> > it, and then RHEL5's tools can't detach/reattach it. If the
>> > deferred
>> > close ever worked on other Xen hosts though, then I don't believe
>> > this
>> > patch would break it, and it will also keep the guest safe when run
>> > on
>> > hosts that don't treat state=Closing the way it currently expects.
>> 
>> There was another fix that sounds similar to this in the backend.
>> 6f5986bce558e64fe867bff600a2127a3cb0c006
>> 
> 
> Thanks for the pointer. It doesn't look like the upstream 2.6.18
> tree has that, but it probably would be a good idea there too.

While I had seen the change and considered pulling it in, I wasn't
really convinced this is the right behavior here: After all, if the host
admin requested a resource to be removed from a guest, it shouldn't
depend on the guest whether and when to honor that request, yet
by deferring the disconnect you basically allow the guest to continue
using the disk indefinitely.

Jan

> However, even with that ability to patch backends, we probably
> want the frontends to be more robust on legacy backends for a while
> longer. So, it probably would be best to avoid changing the state to
> Closing while we're still busy, unless it's absolutely necessary.
> 
> Drew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:14:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzlnn-0004Hs-UF; Tue, 21 Feb 2012 09:14:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rzlnm-0004Hk-Ng
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:14:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329815660!15397556!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28080 invoked from network); 21 Feb 2012 09:14:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:14:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:14:19 +0000
Message-Id: <4F436E75020000780007409F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:14:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Andrew Jones" <drjones@redhat.com>
References: <20120217185836.GA23942@phenom.dumpdata.com>
	<2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:

> 
> ----- Original Message -----
>> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
>> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
>> > > Hmm, I should maybe self-nack this. The bug that led me to
>> > > writing
>> > > it is likely only with older tooling, such as RHEL5's. The
>> > > problem
>> > > was if you attempted to detach a mounted disk twice, then the
>> > > second
>> > > time it would succeed. The guest had flipped to Closing on the
>> > > first
>> > > try, and thus didn't issue an error to xenbus on the second. I
>> > > see
>> > 
>> > Actually, it's even worse than I thought. Just a single attempt to
>> > detach the device will cause the guest grief (with RHEL5's tools
>> > anyway). Once xenbus shows the device is in the Closing state, then
>> > tasks accessing the device may hang.
>> > 
>> > > The reason I only say maybe self-nack though, is because this
>> > > state
>> > > change seemed to be thrown in with another fix[1]. I'm not sure
>> > > if
>> > > the new behavior on legacy hosts was considered or not. If not,
>> > > then
>> > > we can consider it now. Do we want to have deferred asynch
>> > > detaches
>> > > over protecting the guest from multiple detach calls on legacy
>> > > hosts?
>> > > 
>> > 
>> > I guess we can keep the feature and protect the guest with a patch
>> > like
>> > I'll send in a moment. It doesn't really work for me with a RHEL5
>> > host
>> > though. The deferred close works from the pov of the guest, but the
>> > state of the block device gets left in Closed after the guest
>> > unmounts
>> > it, and then RHEL5's tools can't detach/reattach it. If the
>> > deferred
>> > close ever worked on other Xen hosts though, then I don't believe
>> > this
>> > patch would break it, and it will also keep the guest safe when run
>> > on
>> > hosts that don't treat state=Closing the way it currently expects.
>> 
>> There was another fix that sounds similar to this in the backend.
>> 6f5986bce558e64fe867bff600a2127a3cb0c006
>> 
> 
> Thanks for the pointer. It doesn't look like the upstream 2.6.18
> tree has that, but it probably would be a good idea there too.

While I had seen the change and considered pulling it in, I wasn't
really convinced this is the right behavior here: After all, if the host
admin requested a resource to be removed from a guest, it shouldn't
depend on the guest whether and when to honor that request, yet
by deferring the disconnect you basically allow the guest to continue
using the disk indefinitely.

Jan

> However, even with that ability to patch backends, we probably
> want the frontends to be more robust on legacy backends for a while
> longer. So, it probably would be best to avoid changing the state to
> Closing while we're still busy, unless it's absolutely necessary.
> 
> Drew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:19:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzls7-0004TT-K3; Tue, 21 Feb 2012 09:18:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Rzls5-0004TE-Bx
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:18:53 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329815926!9964280!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28021 invoked from network); 21 Feb 2012 09:18:47 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.207)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Feb 2012 09:18:47 -0000
Received: from mail62-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 21 Feb 2012 09:18:42 +0000
Received: from mail62-am1 (localhost [127.0.0.1])	by mail62-am1-R.bigfish.com
	(Postfix) with ESMTP id 0821D460299;
	Tue, 21 Feb 2012 09:18:42 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail62-am1 (localhost.localdomain [127.0.0.1]) by mail62-am1
	(MessageSwitch) id 1329815920879823_14521;
	Tue, 21 Feb 2012 09:18:40 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.227])	by
	mail62-am1.bigfish.com (Postfix) with ESMTP id D2C7D3E0045;
	Tue, 21 Feb 2012 09:18:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Tue, 21 Feb 2012 09:18:39 +0000
X-WSS-ID: 0LZQKJ6-01-0VX-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 22B711028086;	Tue, 21 Feb 2012 03:18:42 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 21 Feb 2012 03:18:49 -0600
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, 21 Feb 2012 03:18:42 -0600
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, 21 Feb 2012
	04:18:40 -0500
Message-ID: <4F43616F.9060902@amd.com>
Date: Tue, 21 Feb 2012 10:18:39 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F33C6C6.30005@amd.com>
	<20290.38015.460233.816604@mariner.uk.xensource.com>
In-Reply-To: <20290.38015.460233.816604@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/20/12 19:44, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] libxl: add missing includes"):
>>
>> include<poll.h>  for struct pollfd
>> include<time.h>  for struct timeval
>> Fixes gcc complaints about implicit declaration.
>
> According to SuS, it should be<sys/time.h>.

Yes, sorry. Should I resend?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:19:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzls7-0004TT-K3; Tue, 21 Feb 2012 09:18:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1Rzls5-0004TE-Bx
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:18:53 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329815926!9964280!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28021 invoked from network); 21 Feb 2012 09:18:47 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.207)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Feb 2012 09:18:47 -0000
Received: from mail62-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 21 Feb 2012 09:18:42 +0000
Received: from mail62-am1 (localhost [127.0.0.1])	by mail62-am1-R.bigfish.com
	(Postfix) with ESMTP id 0821D460299;
	Tue, 21 Feb 2012 09:18:42 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail62-am1 (localhost.localdomain [127.0.0.1]) by mail62-am1
	(MessageSwitch) id 1329815920879823_14521;
	Tue, 21 Feb 2012 09:18:40 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.227])	by
	mail62-am1.bigfish.com (Postfix) with ESMTP id D2C7D3E0045;
	Tue, 21 Feb 2012 09:18:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Tue, 21 Feb 2012 09:18:39 +0000
X-WSS-ID: 0LZQKJ6-01-0VX-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 22B711028086;	Tue, 21 Feb 2012 03:18:42 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 21 Feb 2012 03:18:49 -0600
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, 21 Feb 2012 03:18:42 -0600
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, 21 Feb 2012
	04:18:40 -0500
Message-ID: <4F43616F.9060902@amd.com>
Date: Tue, 21 Feb 2012 10:18:39 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F33C6C6.30005@amd.com>
	<20290.38015.460233.816604@mariner.uk.xensource.com>
In-Reply-To: <20290.38015.460233.816604@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/20/12 19:44, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] libxl: add missing includes"):
>>
>> include<poll.h>  for struct pollfd
>> include<time.h>  for struct timeval
>> Fixes gcc complaints about implicit declaration.
>
> According to SuS, it should be<sys/time.h>.

Yes, sorry. Should I resend?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:24:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzlww-0004gy-BZ; Tue, 21 Feb 2012 09:23:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rzlwu-0004gn-VA
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:23:53 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329816226!6025189!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjg0NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7063 invoked from network); 21 Feb 2012 09:23:46 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-16.tower-21.messagelabs.com with SMTP;
	21 Feb 2012 09:23:46 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1L9Nexv005983;
	Tue, 21 Feb 2012 04:23:40 -0500
Date: Tue, 21 Feb 2012 04:23:40 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4F436E75020000780007409F@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



----- Original Message -----
> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
> 
> > 
> > ----- Original Message -----
> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> >> > > Hmm, I should maybe self-nack this. The bug that led me to
> >> > > writing
> >> > > it is likely only with older tooling, such as RHEL5's. The
> >> > > problem
> >> > > was if you attempted to detach a mounted disk twice, then the
> >> > > second
> >> > > time it would succeed. The guest had flipped to Closing on the
> >> > > first
> >> > > try, and thus didn't issue an error to xenbus on the second. I
> >> > > see
> >> > 
> >> > Actually, it's even worse than I thought. Just a single attempt
> >> > to
> >> > detach the device will cause the guest grief (with RHEL5's tools
> >> > anyway). Once xenbus shows the device is in the Closing state,
> >> > then
> >> > tasks accessing the device may hang.
> >> > 
> >> > > The reason I only say maybe self-nack though, is because this
> >> > > state
> >> > > change seemed to be thrown in with another fix[1]. I'm not
> >> > > sure
> >> > > if
> >> > > the new behavior on legacy hosts was considered or not. If
> >> > > not,
> >> > > then
> >> > > we can consider it now. Do we want to have deferred asynch
> >> > > detaches
> >> > > over protecting the guest from multiple detach calls on legacy
> >> > > hosts?
> >> > > 
> >> > 
> >> > I guess we can keep the feature and protect the guest with a
> >> > patch
> >> > like
> >> > I'll send in a moment. It doesn't really work for me with a
> >> > RHEL5
> >> > host
> >> > though. The deferred close works from the pov of the guest, but
> >> > the
> >> > state of the block device gets left in Closed after the guest
> >> > unmounts
> >> > it, and then RHEL5's tools can't detach/reattach it. If the
> >> > deferred
> >> > close ever worked on other Xen hosts though, then I don't
> >> > believe
> >> > this
> >> > patch would break it, and it will also keep the guest safe when
> >> > run
> >> > on
> >> > hosts that don't treat state=Closing the way it currently
> >> > expects.
> >> 
> >> There was another fix that sounds similar to this in the backend.
> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >> 
> > 
> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> > tree has that, but it probably would be a good idea there too.
> 
> While I had seen the change and considered pulling it in, I wasn't
> really convinced this is the right behavior here: After all, if the
> host
> admin requested a resource to be removed from a guest, it shouldn't
> depend on the guest whether and when to honor that request, yet
> by deferring the disconnect you basically allow the guest to continue
> using the disk indefinitely.
> 

I agree. Yesterday I wrote[1] asking if "deferred detach" is really
something we want. At the moment, Igor and I are poking through
xen-blkfront.c, and currently we'd rather see the feature dropped
in favor of a simplified driver. One that has less release paths,
and/or release paths with more consistent locking behavior.

Drew

[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html


> Jan
> 
> > However, even with that ability to patch backends, we probably
> > want the frontends to be more robust on legacy backends for a while
> > longer. So, it probably would be best to avoid changing the state
> > to
> > Closing while we're still busy, unless it's absolutely necessary.
> > 
> > Drew
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:24:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzlww-0004gy-BZ; Tue, 21 Feb 2012 09:23:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rzlwu-0004gn-VA
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:23:53 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329816226!6025189!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjg0NjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7063 invoked from network); 21 Feb 2012 09:23:46 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-16.tower-21.messagelabs.com with SMTP;
	21 Feb 2012 09:23:46 -0000
Received: from zmail17.collab.prod.int.phx2.redhat.com
	(zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1L9Nexv005983;
	Tue, 21 Feb 2012 04:23:40 -0500
Date: Tue, 21 Feb 2012 04:23:40 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4F436E75020000780007409F@nat28.tlf.novell.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
	busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



----- Original Message -----
> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
> 
> > 
> > ----- Original Message -----
> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> >> > > Hmm, I should maybe self-nack this. The bug that led me to
> >> > > writing
> >> > > it is likely only with older tooling, such as RHEL5's. The
> >> > > problem
> >> > > was if you attempted to detach a mounted disk twice, then the
> >> > > second
> >> > > time it would succeed. The guest had flipped to Closing on the
> >> > > first
> >> > > try, and thus didn't issue an error to xenbus on the second. I
> >> > > see
> >> > 
> >> > Actually, it's even worse than I thought. Just a single attempt
> >> > to
> >> > detach the device will cause the guest grief (with RHEL5's tools
> >> > anyway). Once xenbus shows the device is in the Closing state,
> >> > then
> >> > tasks accessing the device may hang.
> >> > 
> >> > > The reason I only say maybe self-nack though, is because this
> >> > > state
> >> > > change seemed to be thrown in with another fix[1]. I'm not
> >> > > sure
> >> > > if
> >> > > the new behavior on legacy hosts was considered or not. If
> >> > > not,
> >> > > then
> >> > > we can consider it now. Do we want to have deferred asynch
> >> > > detaches
> >> > > over protecting the guest from multiple detach calls on legacy
> >> > > hosts?
> >> > > 
> >> > 
> >> > I guess we can keep the feature and protect the guest with a
> >> > patch
> >> > like
> >> > I'll send in a moment. It doesn't really work for me with a
> >> > RHEL5
> >> > host
> >> > though. The deferred close works from the pov of the guest, but
> >> > the
> >> > state of the block device gets left in Closed after the guest
> >> > unmounts
> >> > it, and then RHEL5's tools can't detach/reattach it. If the
> >> > deferred
> >> > close ever worked on other Xen hosts though, then I don't
> >> > believe
> >> > this
> >> > patch would break it, and it will also keep the guest safe when
> >> > run
> >> > on
> >> > hosts that don't treat state=Closing the way it currently
> >> > expects.
> >> 
> >> There was another fix that sounds similar to this in the backend.
> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >> 
> > 
> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> > tree has that, but it probably would be a good idea there too.
> 
> While I had seen the change and considered pulling it in, I wasn't
> really convinced this is the right behavior here: After all, if the
> host
> admin requested a resource to be removed from a guest, it shouldn't
> depend on the guest whether and when to honor that request, yet
> by deferring the disconnect you basically allow the guest to continue
> using the disk indefinitely.
> 

I agree. Yesterday I wrote[1] asking if "deferred detach" is really
something we want. At the moment, Igor and I are poking through
xen-blkfront.c, and currently we'd rather see the feature dropped
in favor of a simplified driver. One that has less release paths,
and/or release paths with more consistent locking behavior.

Drew

[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html


> Jan
> 
> > However, even with that ability to patch backends, we probably
> > want the frontends to be more robust on legacy backends for a while
> > longer. So, it probably would be best to avoid changing the state
> > to
> > Closing while we're still busy, unless it's absolutely necessary.
> > 
> > Drew
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:27:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzlzl-0004rG-3E; Tue, 21 Feb 2012 09:26:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rzlzj-0004r1-DC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:26:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329816400!12375211!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25841 invoked from network); 21 Feb 2012 09:26:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:26:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:26:40 +0000
Message-Id: <4F43715D02000078000740B3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:26:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul S" <pstroud@gmail.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
	<CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
	<CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
	<20120220150730.GC22593@phenom.dumpdata.com>
In-Reply-To: <20120220150730.GC22593@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.02.12 at 16:07, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 20, 2012 at 08:11:01AM -0500, Paul S wrote:
>> So, the problem has something to do with grub2-efi. After installing
>> XenServer the second time, I noticed that it did not create an EFI Boot
>> partition. To that end, I booted the Fedora CD in normal mode, instead of
>> UEFI mode, created a boot bios, and once installed that way, I was able to
>> run 4.1.2. So, I'm not sure if the problem lies in grub or xen, or the
>> combination of the two, but that is where the problem exists.
> 
> 
> Oooh, Jan, had you seen this in the past by any chance? Presumarily
> using the Xen EFI instead of the GRUB-EFI would solve this problem?

No, I hadn't (and I never played with grub-efi), but yes, using *any*
boot loader is, while theoretically possibly, a pretty pointless business
now that we have xen.efi.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:27:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzlzl-0004rG-3E; Tue, 21 Feb 2012 09:26:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rzlzj-0004r1-DC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:26:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329816400!12375211!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25841 invoked from network); 21 Feb 2012 09:26:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:26:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:26:40 +0000
Message-Id: <4F43715D02000078000740B3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:26:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul S" <pstroud@gmail.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAEpZYZayKHZWL7CR4uH_G3Gn+=Qeo4VWN+7fSzuwnvKxNMwWQA@mail.gmail.com>
	<4F3E82A8.4060204@citrix.com>
	<CAEpZYZbAhyyKE1g1LjyFCUKfVkMBDCO+8VLWiGXGYr0gkoV+-A@mail.gmail.com>
	<CAEpZYZYPerhMUHbaezQiy-2O8EnhJv1mH848DvjCmGWu9CQKhA@mail.gmail.com>
	<CAEpZYZZdmbGG7bsjcX8q-AkzTw0P39rQb53VoP=83J9cBhhq1Q@mail.gmail.com>
	<20120220150730.GC22593@phenom.dumpdata.com>
In-Reply-To: <20120220150730.GC22593@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Reboots and Panics(4.1.2/4.2-unstable)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.02.12 at 16:07, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 20, 2012 at 08:11:01AM -0500, Paul S wrote:
>> So, the problem has something to do with grub2-efi. After installing
>> XenServer the second time, I noticed that it did not create an EFI Boot
>> partition. To that end, I booted the Fedora CD in normal mode, instead of
>> UEFI mode, created a boot bios, and once installed that way, I was able to
>> run 4.1.2. So, I'm not sure if the problem lies in grub or xen, or the
>> combination of the two, but that is where the problem exists.
> 
> 
> Oooh, Jan, had you seen this in the past by any chance? Presumarily
> using the Xen EFI instead of the GRUB-EFI would solve this problem?

No, I hadn't (and I never played with grub-efi), but yes, using *any*
boot loader is, while theoretically possibly, a pretty pointless business
now that we have xen.efi.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzm3X-00054R-PU; Tue, 21 Feb 2012 09:30:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzm3V-000546-PH
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 09:30:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329816633!9079880!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10118 invoked from network); 21 Feb 2012 09:30:33 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:30:33 -0000
Received: by wibhi20 with SMTP id hi20so3285987wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 01:30:32 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr6101002wei.42.1329816632988
	(num_hops = 1); Tue, 21 Feb 2012 01:30:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=TfAOhltCKjhGSj7Cm+0kkqRwf+wL3FXYPaWp5WO/p5M=;
	b=YeedzpwvBTUe5Sikwknbkdm6IO7zIDYp+kj25/d5M/r1r88DW3G+vx+86z62sq0uuf
	xfkKzpvjNwIushfKSRJ09n1vOTOUnF8XHh9MutmON2tG3MdX5zj9GQCyaYLekg+wem8/
	KHz9f/w0uuVdu2yBMLU9SikSwY/Gr36uwDS1c=
Received: by 10.216.134.30 with SMTP id r30mr5073305wei.42.1329816632912;
	Tue, 21 Feb 2012 01:30:32 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id p10sm21753718wic.0.2012.02.21.01.30.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 01:30:32 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============5260582694761208521=="
MIME-Version: 1.0
X-Mercurial-Node: dd87b09e93aa539f4b72ab695a83e5f3ce372d53
Message-Id: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 20 Feb 2012 23:18:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH v5] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5260582694761208521==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    2 -
 README                            |    4 +
 autogen.sh                        |    8 +
 config/Tools.mk.in                |   50 +++++++
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  193 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 54 files changed, 843 insertions(+), 511 deletions(-)



--===============5260582694761208521==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzc2MjgxIC0zNjAwCiMgTm9kZSBJRCBkZDg3YjA5ZTkz
YWE1MzlmNGI3MmFiNjk1YTgzZTVmM2NlMzcyZDUzCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY0OgoKICogVXBkYXRlZCB0
byB0aXAuCgogKiBJbmNsdWRlIGNvbmZpZy5oIGZyb20gY29tcGlsZXIgY29tbWFuZCBsaW5lIHdo
ZW4gYnVpbGRpbmcgbGlieGwgYW5kCiAgIHhsIHRvIGFzc3VyZSB5YWpsX3ZlcnNpb24uaCBwcmVz
ZW5jZSBhbmQgY29ycmVjdGx5IGRldGVjdCB5YWpsCiAgIHZlcnNpb24uCgogKiBBZGRlZCBnbGli
LTIuMCBjaGVjayB3aXRoIGFwcHJvcGlhdGUgbTQgbWFjcm9zLgoKICogUHVyZ2VkIGNvbmZpZy5o
LmluIGZyb20gdW5uZWNlc3NhcnkgZGVmaW5lcyB0aGF0IGNvdWxkIG1lc3Mgd2l0aAogICB0aGUg
YnVpbGQgc3lzdGVtLgoKICogUmVtb3ZlZCB0b29scy9jb25maWcuc3ViLCB0b29scy9jb25maWcu
Z3Vlc3MsIHRvb2xzL2NvbmZpZ3VyZSBhbmQKICAgY29uZmlndXJlIHRvIG1ha2UgdGhlIHBhdGNo
IGZpdCBtYWlsaW5nIGxpc3QgbGltaXQuCgpDaGFuZ2VzIHNpbmNlIHYzOgoKICogQ29waWVkIGNv
bmZpZy5ndWVzcyBhbmQgY29uZmlnLnN1YiBmcm9tIGF1dG9tYWtlIDEuMTEuCgogKiBBZGRlZCBh
IHRlc3QgdG8gY2hlY2sgZm9yIHV1aWQuaCBvbiBCU0QgYW5kIHV1aWQvdXVpZC5oIG9uIExpbnV4
LgoKQ2hhbmdlcyBzaW5jZSB2MjoKCiAqIENoYW5nZWQgb3JkZXIgb2YgY29uZmlnL1Rvb2xzLm1r
IGluY2x1ZGUuCgogKiBBZGRlZCAiLWUiIHRvIGF1dG9nZW4uc2ggc2hlYmFuZy4KCiAqIEFkZGVk
IG5lY2Vzc2FyeSBmaWxlcyAoY29uZmlnLiopIGFuZCBvdXRwdXQgZnJvbSBBdXRvaGVhZGVyIGFu
ZAogICBBdXRvY29uZi4KCiAqIFJlbW92ZWQgQXV0b2NvbmYgZnJvbSBidWlsZCBkZXBlbmRlbmNp
ZXMgYW5kIHVwZGF0ZWQgUkVBRE1FLgoKQ2hhbmdlcyBzaW5jZSB2MToKCiAqIE1vdmVkIGF1dG9j
b25mIHN0dWZmIGluc2lkZSB0b29scyBmb2xkZXIuCgogKiBBZGQgTWFrZWZpbGUgcnVsZXMgZm9y
IGNsZWFuaW5nLgoKICogUmVtb3ZlZCBBdXRvbWFrZSBkZXBlbmRlbmN5LgoKICogQ3JlYXRlIGF1
dG9nZW4uc2ggdG8gYXV0b21hdGljYWxseSBjcmVhdGUgY29uZmlndXJlIHNjcmlwdCB3aGVuCiAg
IGJ1aWxkaW5nIGZyb20gc291cmNlIHJlcG9zaXRvcnkuCgogKiBDYWNoZWQgdmFsdWVzIG9mIG9w
dGlvbnMgcGFzc2VkIGZyb20gY29tbWFuZCBsaW5lLgoKICogQWRkIG5lY2Vzc2FyeSBpZ25vcmVz
IHRvIC5oZ2lnbm9yZS4KCiAqIEFkZGVkIEF1dG9jb25mIHRvIHRoZSBsaXN0IG9mIGRlcGVuZGVu
Y2llcy4KCiAqIENoYW5nZWQgaHlwZW4gdG8gdW5kZXJzY29yZSBpbiBYTUwyIGFuZCBDVVJMIHZh
cmlhYmxlIG5hbWVzLgoKICogQWRkZWQgc2NyaXB0IHRvIGdldCB2ZXJzaW9uIGZyb20geGVuL01h
a2VmaWxlLgoKICogU2V0IE9jYW1sIHRvb2xzIHRvIG9wdGlvbmFsLgoKICogQWRkZWQgcHJvY2Vk
ZW5jZSBvZiBtNC9vY2FtbC5tNC4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkz
YWEgLmhnaWdub3JlCi0tLSBhLy5oZ2lnbm9yZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIGIvLmhnaWdub3JlCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMzAz
LDYgKzMwMywxMiBAQAogXnRvb2xzL29jYW1sL2xpYnMveGwveGVubGlnaHRcLm1sJAogXnRvb2xz
L29jYW1sL2xpYnMveGwveGVubGlnaHRcLm1saSQKIF50b29scy9vY2FtbC94ZW5zdG9yZWQvb3hl
bnN0b3JlZCQKK150b29scy9hdXRvbTR0ZVwuY2FjaGUkCitedG9vbHMvY29uZmlnXC5oJAorXnRv
b2xzL2NvbmZpZ1wubG9nJAorXnRvb2xzL2NvbmZpZ1wuc3RhdHVzJAorXnRvb2xzL2NvbmZpZ1wu
Y2FjaGUkCiteY29uZmlnL1Rvb2xzXC5tayQKIF54ZW4vXC5iYW5uZXIuKiQKIF54ZW4vQkxPRyQK
IF54ZW4vU3lzdGVtLm1hcCQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIENv
bmZpZy5tawotLS0gYS9Db25maWcubWsJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyBiL0NvbmZpZy5tawlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTcwLDkgKzcw
LDYgQEAgRVhUUkFfSU5DTFVERVMgKz0gJChFWFRSQV9QUkVGSVgpL2luY2x1ZAogRVhUUkFfTElC
ICs9ICQoRVhUUkFfUFJFRklYKS8kKExJQkxFQUZESVIpCiBlbmRpZgogCi1CSVNPTgk/PSBiaXNv
bgotRkxFWAk/PSBmbGV4Ci0KIFBZVEhPTiAgICAgID89IHB5dGhvbgogUFlUSE9OX1BSRUZJWF9B
UkcgPz0gLS1wcmVmaXg9IiQoUFJFRklYKSIKICMgVGhlIGFib3ZlIHJlcXVpcmVzIHRoYXQgUFJF
RklYIGNvbnRhaW5zICpubyBzcGFjZXMqLiBUaGlzIHZhcmlhYmxlIGlzIGhlcmUKQEAgLTE3NSwz
MiArMTcyLDkgQEAgQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKFBSRVBFTkRfSU5DTFVERQogQVBQ
RU5EX0xERkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0xJQiksIC1MJChpKSkKIEFQUEVO
RF9DRkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0lOQ0xVREVTKSwgLUkkKGkpKQogCi1D
SEVDS19MSUIgPSAkKEVYVFJBX0xJQikgJChQUkVQRU5EX0xJQikgJChBUFBFTkRfTElCKQotQ0hF
Q0tfSU5DTFVERVMgPSAkKEVYVFJBX0lOQ0xVREVTKSAkKFBSRVBFTkRfSU5DTFVERVMpICQoQVBQ
RU5EX0lOQ0xVREVTKQotCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgOj0gLW5vcGllIC1mbm8tc3Rh
Y2stcHJvdGVjdG9yIC1mbm8tc3RhY2stcHJvdGVjdG9yLWFsbAogRU1CRURERURfRVhUUkFfQ0ZM
QUdTICs9IC1mbm8tZXhjZXB0aW9ucwogCi1DT05GSUdfTElCSUNPTlYgICA6PSAkKHNoZWxsIGV4
cG9ydCBPUz0iYHVuYW1lIC1zYCI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgZXhwb3J0IENI
RUNLX0xJQj0iJChDSEVDS19MSUIpIjsgXAotICAgICAgICAgICAgICAgICAgICAgICAuICQoWEVO
X1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNoOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGhh
c19saWIgbGliaWNvbnYuc28gJiYgZWNobyAneScgfHwgZWNobyAnbicpCi0KLUNPTkZJR19ZQUpM
X1ZFUlNJT04gOj0gJChzaGVsbCBleHBvcnQgT1M9ImB1bmFtZSAtc2AiOyBcCi0gICAgICAgICAg
ICAgICAgICAgICAgIGV4cG9ydCBDSEVDS19JTkNMVURFUz0iJChDSEVDS19JTkNMVURFUykiOyBc
Ci0gICAgICAgICAgICAgICAgICAgICAgIC4gJChYRU5fUk9PVCkvdG9vbHMvY2hlY2svZnVuY3Mu
c2g7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgaGFzX2hlYWRlciB5YWpsL3lhamxfdmVyc2lv
bi5oICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi0jIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9k
dWxlIChieSBkZWZhdWx0LCBGbGFzaykuCi1YU01fRU5BQkxFID89IG4KLUZMQVNLX0VOQUJMRSA/
PSAkKFhTTV9FTkFCTEUpCi0KLSMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBv
ciBHSVQncyBvd24gcHJvdG9jb2w/Ci0jIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9y
ZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKLSMgbWF5IGJsb2NrIGl0
KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93
bmxvYWRzCi0jIGZhaWwgb3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3Vy
IGVudmlyb25tZW50LgotR0lUX0hUVFAgPz0gbgotCiBYRU5fRVhURklMRVNfVVJMPWh0dHA6Ly94
ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzCiAjIEFsbCB0aGUgZmlsZXMgYXQgdGhh
dCBsb2NhdGlvbiB3ZXJlIGRvd25sb2FkZWQgZnJvbSBlbHNld2hlcmUgb24KICMgdGhlIGludGVy
bmV0LiAgVGhlIG9yaWdpbmFsIGRvd25sb2FkIFVSTCBpcyBwcmVzZXJ2ZWQgYXMgYSBjb21tZW50
CkBAIC0yMzksMTcgKzIxMyw0IEBAIFFFTVVfVEFHID89IDEyOGRlMjU0OWM1ZjI0ZTRhNDM3Yjg2
YmQyZTQKICMgU2hvcnQgYW5zd2VyIC0tIGRvIG5vdCBlbmFibGUgdGhpcyB1bmxlc3MgeW91IGtu
b3cgd2hhdCB5b3UgYXJlCiAjIGRvaW5nIGFuZCBhcmUgcHJlcGFyZWQgZm9yIHNvbWUgcGFpbi4K
IAotIyBPcHRpb25hbCBjb21wb25lbnRzCi1YRU5TVEFUX1hFTlRPUCAgICAgPz0geQotVlRQTV9U
T09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQSV9CSU5ESU5HUyA/PSBuCi1QWVRIT05fVE9PTFMg
ICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAgICAgID89IHkKLUNPTkZJR19NSU5JVEVSTSAgICA/
PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0gbgotQ09ORklHX1NZU1RFTV9MSUJBSU8gPz0geQog
Q09ORklHX1RFU1RTICAgICAgID89IHkKLQotaWZlcSAoJChPQ0FNTF9UT09MUykseSkKLU9DQU1M
X1RPT0xTIDo9ICQoc2hlbGwgb2NhbWxvcHQgLXYgPiAvZGV2L251bGwgMj4mMSAmJiBlY2hvICJ5
IiB8fCBlY2hvICJuIikKLWVuZGlmCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNh
YSBNYWtlZmlsZQotLS0gYS9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAK
KysrIGIvTWFrZWZpbGUJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC00MCwxMSAr
NDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdDogZGlzdC14ZW4g
ZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRpc3QtZG9jcyBkaXN0LW1pc2MK
IAogZGlzdC1taXNjOgotCSQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hlY2sKIAkkKElOU1RB
TExfREFUQSkgLi9DT1BZSU5HICQoRElTVERJUikKIAkkKElOU1RBTExfREFUQSkgLi9SRUFETUUg
JChESVNURElSKQogCSQoSU5TVEFMTF9QUk9HKSAuL2luc3RhbGwuc2ggJChESVNURElSKQotCSQo
SU5TVEFMTF9QUk9HKSB0b29scy9jaGVjay9jaGsgdG9vbHMvY2hlY2svY2hlY2tfKiB0b29scy9j
aGVjay9mdW5jcy5zaCAkKERJU1RESVIpL2NoZWNrCiBkaXN0LSU6IERFU1RESVI9JChESVNURElS
KS9pbnN0YWxsCiBkaXN0LSU6IGluc3RhbGwtJQogCUA6ICMgZG8gbm90aGluZwpkaWZmIC1yIGNh
ODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgUkVBRE1FCi0tLSBhL1JFQURNRQlNb24gRmViIDIw
IDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvUkVBRE1FCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAx
MiArMDEwMApAQCAtODksOSArODksMTMgQEAgMi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0
ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5IGZpcnN0IGJ1aWxkLCBvciBpZiB5b3Ugd2FudCB0
byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgog
CisgICAgIyAuL2NvbmZpZ3VyZQogICAgICMgbWFrZSB3b3JsZAogICAgICMgbWFrZSBpbnN0YWxs
CiAKKyAgIElmIHlvdSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAtLWhlbHAgdG8gc2Vl
IHRoZSBsaXN0IG9mCisgICBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25zIHdoZW4gYnVpbGRpbmcg
YW5kIGluc3RhbGxpbmcgWGVuLgorCiAgICBUaGlzIHdpbGwgY3JlYXRlIGFuZCBpbnN0YWxsIG9u
dG8gdGhlIGxvY2FsIG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQKICAgIHRoZSB4ZW4gYmluYXJ5ICh4
ZW4uZ3opLCB0aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgogCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGRkODdiMDllOTNhYSBhdXRvZ2VuLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL2F1dG9nZW4uc2gJTW9uIEZlYiAyMCAyMzoxODow
MSAyMDEyICswMTAwCkBAIC0wLDAgKzEsOCBAQAorIyEvYmluL3NoIC1lCitybSAtcmYgY29uZmln
dXJlCitjZCB0b29scworYXV0b2NvbmYKK2NkIC4uCitlY2hvICIjIS9iaW4vc2ggLWUiID4+IGNv
bmZpZ3VyZQorZWNobyAiY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgXCRAIiA+PiBjb25maWd1cmUK
K2NobW9kICt4IGNvbmZpZ3VyZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEg
Y29uZmlnL1Rvb2xzLm1rLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL2NvbmZpZy9Ub29scy5tay5pbglNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIg
KzAxMDAKQEAgLTAsMCArMSw1MCBAQAorIyBQcmVmaXggYW5kIGluc3RhbGwgZm9sZGVyCitQUkVG
SVggICAgICAgICAgICAgIDo9IEBwcmVmaXhACitMSUJMRUFGRElSX3g4Nl82NCAgIDo9IEBMSUJf
UEFUSEAKKworIyBBIGRlYnVnIGJ1aWxkIG9mIHRvb2xzPworZGVidWcgICAgICAgICAgICAgICA6
PSBAZGVidWdACisKKyMgVG9vbHMgcGF0aAorQklTT04gICAgICAgICAgICAgICA6PSBAQklTT05A
CitGTEVYICAgICAgICAgICAgICAgIDo9IEBGTEVYQAorUFlUSE9OICAgICAgICAgICAgICA6PSBA
UFlUSE9OQAorUFlUSE9OX1BBVEggICAgICAgICA6PSBAUFlUSE9OUEFUSEAKK1BFUkwgICAgICAg
ICAgICAgICAgOj0gQFBFUkxACitCUkNUTCAgICAgICAgICAgICAgIDo9IEBCUkNUTEAKK0lQICAg
ICAgICAgICAgICAgICAgOj0gQElQQAorQ1VSTF9DT05GSUcgICAgICAgICA6PSBAQ1VSTEAKK1hN
TDJfQ09ORklHICAgICAgICAgOj0gQFhNTEAKK0JBU0ggICAgICAgICAgICAgICAgOj0gQEJBU0hA
CitYR0VUVFRFWFQgICAgICAgICAgIDo9IEBYR0VUVEVYVEAKKworIyBFeHRyYSBmb2xkZXIgZm9y
IGxpYnMvaW5jbHVkZXMKK1BSRVBFTkRfSU5DTFVERVMgICAgOj0gQFBSRVBFTkRfSU5DTFVERVNA
CitQUkVQRU5EX0xJQiAgICAgICAgIDo9IEBQUkVQRU5EX0xJQkAKK0FQUEVORF9JTkNMVURFUyAg
ICAgOj0gQEFQUEVORF9JTkNMVURFU0AKK0FQUEVORF9MSUIgICAgICAgICAgOj0gQEFQUEVORF9M
SUJACisKKyMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4K
K1hTTV9FTkFCTEUgICAgICAgICAgOj0gQHhzbUAKK0ZMQVNLX0VOQUJMRSAgICAgICAgOj0gQHhz
bUAKKworIyBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBw
cm90b2NvbD8KKyMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hl
biBpdCB3b3JrcyBhdCBhbGwgKGZpcmV3YWxscworIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0
IHRoZSBkZWZhdWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKKyMgZmFp
bCBvciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQu
CitHSVRfSFRUUCAgICAgICAgICAgIDo9IEBnaXRodHRwQAorCisjIE9wdGlvbmFsIGNvbXBvbmVu
dHMKK1hFTlNUQVRfWEVOVE9QICAgICAgOj0gQG1vbml0b3JzQAorVlRQTV9UT09MUyAgICAgICAg
ICA6PSBAdnRwbUAKK0xJQlhFTkFQSV9CSU5ESU5HUyAgOj0gQHhhcGlACitQWVRIT05fVE9PTFMg
ICAgICAgIDo9IEBweXRob250b29sc0AKK09DQU1MX1RPT0xTICAgICAgICAgOj0gQG9jYW1sdG9v
bHNACitDT05GSUdfTUlOSVRFUk0gICAgIDo9IEBtaW5pdGVybUAKK0NPTkZJR19MT01PVU5UICAg
ICAgOj0gQGxvbW91bnRACisKKyNTeXN0ZW0gb3B0aW9ucworQ09ORklHX1NZU1RFTV9MSUJBSU86
PSBAc3lzdGVtX2Fpb0AKK0NPTkZJR19MSUJJQ09OViAgICAgOj0gQGxpYmljb252QAorQ09ORklH
X0dDUllQVCAgICAgICA6PSBAbGliZ2NyeXB0QAorQ09ORklHX0VYVDJGUyAgICAgICA6PSBAbGli
ZXh0MmZzQApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvTWFrZWZp
bGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyBiL3Rvb2xzL01ha2VmaWxlCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtNiw3
ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlvCiBlbmRpZgogCiBTVUJESVJTLXkgOj0K
LVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9IGluY2x1ZGUKIFNVQkRJUlMteSArPSBs
aWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2ICs3OCw4IEBAIGNsZWFuOiBzdWJkaXJz
LWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNsZWFuCiAJcm0gLXJmIHFlbXUteGVuLXRy
YWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtb3RlCiAJcm0gLXJmIHFl
bXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJcm0gLXJmIC4uL2NvbmZpZy9Ub29scy5t
ayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAorCQljb25maWcuY2FjaGUgYXV0
b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJTEVfQVJDSCksJChYRU5fVEFSR0VUX0FS
Q0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0tY3B1PSQoWEVOX1RBUkdFVF9BUkNIKSBc
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9SdWxlcy5tawotLS0g
YS90b29scy9SdWxlcy5tawlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvdG9v
bHMvUnVsZXMubWsJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC00LDYgKzQsNyBA
QAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5taworaW5jbHVkZSAkKFhFTl9S
T09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5TVEFMTCkKIElO
U1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1pbnN0YWxsCkBAIC04MCw4ICs4MSw2IEBA
IGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2MtdmVyLWNoZWMKICAgICAgICAgICAgICAg
ICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3QgZ2NjLTMuNCIpCiAkKGV2YWwgJChjaGVj
ay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwgd2hpY2ggJChQWVRIT04pKQotUFlUSE9O
X1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxMX1BZVEhPTl9QUk9HID0gXAogCSQoWEVO
X1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAgIiQoUFlUSE9OX1BBVEgpIiAkKElOU1RB
TExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1YmRpci1hbGwtJSBzdWJkaXItY2xlYW4t
JSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVhbi0lOiAucGhvbnkKIAkkKE1BS0UpIC1D
ICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9Ub29scy5tazoKKwlAZWNobyAiWW91IGhh
dmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWlsZGluZyBvciBpbnN0YWxsaW5nIHRoZSB0
b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29s
cy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9NYWtl
ZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvYmxrdGFwL2Ry
aXZlcnMvTWFrZWZpbGUJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0xMyw3ICsx
Myw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKQogQ0ZMQUdTICAgKz0gLUkg
JChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05VX1NPVVJDRQogCi1pZmVxICgkKHNoZWxs
IC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lmZXEgKCRDT05GSUdfR0NSWVBULHkpCiBD
RkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIgOj0gLWxnY3J5cHQKIGVsc2UKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNr
X2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAotCi1jYXQgPiAuZ2NyeXB0LmMg
PDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQgbWFpbih2b2lkKSB7IHJldHVybiAwOyB9
Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0LmMgLWxnY3J5cHQgMj4vZGV2L251bGwg
OyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNobyAibm8iCi1maQotCi1ybSAtZiAuZ2Ny
eXB0KgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svTWFr
ZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uCi1pbmNsdWRlICQoWEVOX1JP
T1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRoZSBuZWNlc3NhcnkgZW52aXJvbm1lbnQg
dmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQWVRIT04KLWV4cG9ydCBMSUJYRU5BUElf
QklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwotZXhwb3J0IENIRUNLX0xJQgotZXhwb3J0
IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTogYWxsIGluc3RhbGwKLWFsbCBpbnN0YWxs
OiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgYnVpbGRpbmcg
b24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1idWlsZDoKLQkuL2NoayBidWlsZAotCi0j
IENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5zdGFsbGluZyBvbi4KLS5QSE9OWTogY2hl
Y2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2NoayBpbnN0YWxsCi0KLS5QSE9OWTogY2xl
YW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDll
OTNhYSB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9vbHMvY2hlY2svUkVBRE1FCU1vbiBGZWIg
MjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVja3MgZm9yIHRoZSBzdWl0YWJpbGl0eSBv
ZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLgotVG8gY2hlY2sgZm9yIGJ1aWxk
IHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGJ1aWxkCi0KLVRvIGNoZWNrIGZvciBp
bnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGluc3RhbGwKLQotVGhlIGNo
ayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMgZGlyZWN0b3J5IGFuZCBwcmludAotdGhl
IG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3RoaW5nIGlmIGNoZWNrcyBzdWNjZWVkLgot
VGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1Y2Nlc3MgYW5kIDEgb24gZmFpbHVyZS4K
LQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxlIGZpbGVzIGluIHRoaXMgZGlyZWN0b3J5
IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18nLiBGaWxlcyBjb250YWluaW5nIENIRUNL
LUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hlY2ssIGFuZCBmaWxlcyBjb250YWluaW5n
IENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBpbnN0YWxsIGNoZWNrLgotCi1EZXRhaWxl
ZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBpcyBpbiAuY2hrYnVpbGQgZm9yIGJ1aWxk
Ci1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmls
ZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svY2hlY2tf
YnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwJTW9uIEZlYiAyMCAxODozNDoxNCAy
MDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBA
IC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5z
aAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBi
cmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwgYnJjdGwgOzsKLSopCi0JZmFpbCAidW5r
bm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRv
b2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfY3J5cHRv
X2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAotIyEvYmluL3NoCi0jIENI
RUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1G
cmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7OwotZXNhYwotCi1oYXNfbGliIGxpYmNy
eXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0by5zbyIKZGlmZiAtciBjYTgwZWNhOWNm
YTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX2N1cmwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfY3VybAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmlu
L3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsg
IiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0aGVuCi0JZWNobyAtbiAidW51c2VkLCAi
Ci0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJsLWNvbmZpZwotY3VybF9saWJzPWBjdXJs
LWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29uZmlnIC0tbGlicyBmYWlsZWQiCi10ZXN0
X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxpYnJhcmllcyBmb3IgY3VybCBh
cmUgbWlzc2luZyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2No
ZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfaXByb3V0ZQlNb24gRmVi
IDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwK
LQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBBVEgKLQotY2FzZSAkT1MgaW4KLU9wZW5C
U0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgaWZjb25maWcgOzsKLUxpbnV4KQotCWhh
c19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2FjCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2
ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNz
LnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7IHRoZW4KLSAg
ICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGliYWlvLmggOyB0aGVuCi0gICAgZmFpbCAi
Y2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFsbCBsaWJhaW8gZGV2ZWwgcGFja2FnZSBv
ciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZpCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGRkODdiMDllOTNhYSB0b29scy9jaGVjay9jaGVja19saWJhaW9fbGliCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX2xpYmFpb19saWIJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDkgKzAsMCBAQAot
IyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0K
LWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7IHRoZW4KLSAgICBleGl0
IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIGxpYmFpbyIKZGlm
ZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX29wZW5z
c2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAlNb24gRmViIDIw
IDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAu
L2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9tZDUuaCB8fCBmYWlsICJtaXNzaW5nIG9w
ZW5zc2wgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xz
L2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9jaGVjay9jaGVja19weXRob24JTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBD
SEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhl
bgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhPTn0gLWMgJwotaW1wb3J0IHN5cwotc3lz
LmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Igc3lzLnZlcnNpb25faW5mb1sxXSA8IDMp
Ci0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24gPj0gMi4zIgpkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX2RldmVsCi0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1p
ZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotaGFzX29yX2Zh
aWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgb3MucGF0aCwgc3lzCi1mb3Ig
cCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZpbGUi
KToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0nIHx8IGZhaWwgImNhbid0IGZpbmQgcHl0
aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9v
bHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90b29scy9jaGVjay9jaGVja19weXRob25f
eG1sCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4K
LSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0ke1BZVEhPTn0g
LWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rldi9udWxsIHx8IFwKLWZhaWwgImNhbid0
IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDll
OTNhYSB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3VkZXYJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1J
TlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJl
ZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7Ci1MaW51eCkKLQloYXMgL3NiaW4vdWRl
dmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZhZG0gaW5mbyAtViB8IGF3ayAne3ByaW50
ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhhc19vcl9mYWlsIHVkZXZpbmZvICYmIFwK
LQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbICIkdWRldnZl
ciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQloYXMgaG90cGx1ZyB8fCBcCi0JCWZhaWwg
InVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVyIgotCTs7Ci0q
KQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
ZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfdXVpZF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNyArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgdXVp
ZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmggfHwgZmFpbCAibWlzc2luZyB1dWlkIGhl
YWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5
ZTkzYWEgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3gxMV9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0jIS9iaW4vc2gK
LSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgWDExL2tleXN5bWRl
Zi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8
fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAot
d2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
ZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0Ci0tLSBhL3Rvb2xzL2NoZWNr
L2NoZWNrX3hnZXR0ZXh0CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw2ICswLDAgQEAKLSMhL2Jp
bi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX29yX2ZhaWwgeGdldHRl
eHQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNr
X3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1sMglNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQSV9CSU5ESU5HUyIgPSAieSIgXQotdGhl
bgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4aXQgMAotZmkKLQotaGFzX29yX2ZhaWwg
eG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25maWcgLS1saWJzYCB8fCBmYWlsICJ4bWwy
LWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICR4bWwyX2xpYnMgfHwgZmFpbCAiZGVw
ZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1pc3NpbmciCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9jaGVjay9jaGVja195YWpsX2RldmVsCi0tLSBhL3Rv
b2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDggKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVh
ZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95YWpsX3BhcnNl
LmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8fCBmYWlsICJjYW4ndCBmaW5kIHlhamwv
eWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIGxpYnlh
amwuc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9jaGVjay9j
aGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJfZGV2ZWwJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBmYWlsICJjYW4ndCBmaW5kIHps
aWIgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2No
ZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCU1vbiBG
ZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0
QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJ6LnNvIHx8IGZh
aWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2Fh
IHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJTW9uIEZlYiAyMCAxODozNDox
NCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3VzYWdlICgpCi17Ci0gICAgZWNo
byAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFsbHxjbGVhbl0iCi0gICAgZWNo
bwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4gYnVpbGQgb3IgaW5zdGFsbC4i
Ci0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90LiIKLSAgICBlY2hvCi0gICAg
ZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5lcmF0ZWQgZmlsZXMuIgotICAg
IGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2JpbgotT1M9YHVuYW1lIC1zYAot
ZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIgXTsgdGhlbgotCWV4aXQgMAot
ZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBjaGVjaz0iQ0hFQ0stQlVJTEQi
Ci0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hlY2s9IkNIRUNLLUlOU1RBTEwi
Ci0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQgMAotICAgICAgICA7OwotICAg
ICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVzYWMKLQotZmFpbGVkPTAKLQot
ZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBjaGVja18qIDsgZG8KLSAgICBj
YXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29udGludWUKLSAgICAgICAgICAg
IDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVzYWMKLSAgICBpZiAhIFsgLXgg
JGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAgIGlmICEgZ3JlcCAtRnEg
IiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0gICAgZmkKLSAgICBlY2hvIC1u
ICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRoZW4KLSAgICAgICAgZWNobyBP
SwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQotZG9uZQotCi1leGl0ICR7ZmFp
bGVkfQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svZnVu
Y3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGljaCwgZXhjZXB0IGl0IGhhbmRs
ZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAteiAiJENST1NTX0NPTVBJTEUi
IF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVybiAkPwotCWZpCi0KLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBpbiAkUEFUSDsgZG8KLQkJaWYg
WyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0JCQllY2hvICIkQ1JPU1NfU1lT
X1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUKLQlyZXR1cm4gMQotCSkKLX0K
LQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVsbCB8fCBmYWlsICJjYW4ndCBm
aW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5c19yb290IHx8IHJldHVybiAx
Ci0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JP
T1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAwCi0JCWZpCi0JCWZvciBwYXRo
IGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAiJENST1NTX1NZU19ST09UJHtw
YXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQotCQlkb25lCi0JCTs7Ci0JZXNh
YwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVja19zeXNfcm9vdCB8fCByZXR1
cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBlbnZp
cm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAjIGZvciBsZGNvbmZpZwotCUxJ
QlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhpcyByZWxhdGl2ZWx5IGNvbW1v
biBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0Ci0JIyBsZGNvbmZpZyBoYXNu
J3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3JrLgotCWlmIFsgIiRPUyIgPSBM
aW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNvLmNhY2hlIiBdOyB0aGVuCi0J
ICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JPU1NfU1lTX1JPT1RcIiB0byBn
ZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91Z2g7IGxkY29uZmlnIHRlc3Qg
YmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJMaW51eCIgXTsgdGhlbgot
CQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JPU1NfU1lTX1JPT1QifSB8IGdy
ZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIke09TfSIgPSAiTmV0QlNEIiBd
OyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/
Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkgewotCSMgc3Vic2hlbGwgdG8g
dHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1wZmlsZQotCXRyYXAgJ3JtIC1m
ICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1gbWt0ZW1wYCB8fCByZXR1cm4g
MQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+JjEKLQlyZXR1cm4gJD8KLQkp
Ci19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5IGFib3ZlCi1jaGVja19zeXNf
cm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiByZXR1cm4gMAotCWlmIFsgLXog
IiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVhc2Ugc2V0IENST1NTX1NZU19S
T09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlmaQotCWlmIFsgISAtZCAiJENS
T1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1yb290IGZvdW5kIGF0ICRDUk9T
U19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJuaW5nKCkgewotCWVjaG8KLQll
Y2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAkKn0iCi19Ci0KLWZhaWwoKSB7
Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLQll
eGl0IDEKLX0KZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NvbmZp
Zy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL2NvbmZpZy5oLmluCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMCww
ICsxLDE2IEBACisvKgorICogQ29weXJpZ2h0IChDKSAyMDEyCisgKgorICogVGhpcyBwcm9ncmFt
IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkK
KyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBM
aWNlbnNlIGFzIHB1Ymxpc2hlZAorICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsg
dmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lhbAorICogZXhjZXB0aW9uIG9uIGxpbmtp
bmcgZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlz
dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlCisgKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0
YWlscy4KKyAqLworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92
ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05f
SApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY29uZmlndXJlLmFj
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L2NvbmZpZ3VyZS5hYwlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwx
OTMgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0q
LSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBhdXRvY29uZiB0byBwcm9k
dWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsyLjY3XSkKK0FDX0lOSVQoW1hl
biBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVyc2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVd
KSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb21dKQorQUNfQ09ORklHX1NSQ0RJ
UihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklMRVMoWy4uL2NvbmZpZy9Ub29scy5ta10p
CitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQorQUNfUFJFRklYX0RFRkFVTFQoWy91c3Jd
KQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENoZWNrIGlmIENGTEFHUywgTERGTEFHUywg
TElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCisKK0FTX0lG
KFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElCUyRDUFBGTEFHUyRDUFAiXSwgWworICAg
IEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxB
R1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBS
RVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVu
IHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVNX0VYVEVOU0lPTlMKK0FDX0NBTk9OSUNB
TF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200X2luY2x1ZGUoW200L2VuYWJsZV9mZWF0
dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVfZmVhdHVyZS5tNF0pCittNF9pbmNsdWRl
KFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX3htbC5tNF0pCitt
NF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25f
ZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5tNF0pCittNF9pbmNsdWRlKFttNC9vY2Ft
bC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xpYi5tNF0pCittNF9pbmNsdWRlKFttNC9z
ZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVkZShbbTQvdXVpZC5tNF0pCittNF9pbmNs
dWRlKFttNC9wa2cubTRdKQorCisjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKK0FYX0FSR19FTkFC
TEVfQU5EX0VYUE9SVChbeHNtXSwKKyAgICBbRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5
IGRlZmF1bHQsIEZsYXNrKV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW2dpdGh0dHBdLCBb
RG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUF0pCitBWF9BUkdfRElTQUJMRV9BTkRf
RVhQT1JUKFttb25pdG9yc10sCisgICAgW0Rpc2FibGUgeGVuc3RhdCBhbmQgeGVudG9wIG1vbml0
b3JpbmcgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt2dHBtXSwgW0VuYWJsZSBW
aXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9S
VChbeGFwaV0sIFtFbmFibGUgWGVuIEFQSSBCaW5kaW5nc10pCitBWF9BUkdfRElTQUJMRV9BTkRf
RVhQT1JUKFtweXRob250b29sc10sIFtEaXNhYmxlIFB5dGhvbiB0b29sc10pCitBWF9BUkdfRElT
QUJMRV9BTkRfRVhQT1JUKFtvY2FtbHRvb2xzXSwgW0Rpc2FibGUgT2NhbWwgdG9vbHNdKQorQVhf
QVJHX0VOQUJMRV9BTkRfRVhQT1JUKFttaW5pdGVybV0sIFtFbmFibGUgbWluaXRlcm1dKQorQVhf
QVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtsb21vdW50XSwgW0VuYWJsZSBsb21vdW50XSkKK0FYX0FS
R19ESVNBQkxFX0FORF9FWFBPUlQoW2RlYnVnXSwgW0Rpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVu
IGFuZCB0b29sc10pCisKK0FDX0FSR19WQVIoW1BSRVBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0
IG9mIGluY2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQor
QUNfQVJHX1ZBUihbUFJFUEVORF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0
byBwcmVwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9J
TkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIGFwcGVuZCB0byBDRkxB
R1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9MSUJdLAorICAgIFtMaXN0IG9m
IGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCldKQorCitB
WF9TRVRfRkxBR1MKKworQUNfQVJHX1ZBUihbUFlUSE9OXSwgW1BhdGggdG8gdGhlIFB5dGhvbiBw
YXJzZXJdKQorQUNfQVJHX1ZBUihbUEVSTF0sIFtQYXRoIHRvIFBlcmwgcGFyc2VyXSkKK0FDX0FS
R19WQVIoW0JSQ1RMXSwgW1BhdGggdG8gYnJjdGwgdG9vbF0pCitBQ19BUkdfVkFSKFtJUF0sIFtQ
YXRoIHRvIGlwIHRvb2xdKQorQUNfQVJHX1ZBUihbQklTT05dLCBbUGF0aCB0byBCaXNvbiBwYXJz
ZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0ZMRVhdLCBbUGF0aCB0byBGbGV4IGxleGljYWwg
YW5hbHlzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0NVUkxdLCBbUGF0aCB0byBjdXJsLWNv
bmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW1hNTF0sIFtQYXRoIHRvIHhtbDItY29uZmlnIHRvb2xd
KQorQUNfQVJHX1ZBUihbQkFTSF0sIFtQYXRoIHRvIGJhc2ggc2hlbGxdKQorQUNfQVJHX1ZBUihb
WEdFVFRFWFRdLCBbUGF0aCB0byB4Z2V0dHRleHQgdG9vbF0pCisKKyMgQ2hlY2tzIGZvciBwcm9n
cmFtcy4KK0FDX1BST0dfU0VECitBQ19QUk9HX0NDCitBQ19QUk9HX0xOX1MKK0FDX1BST0dfTUFL
RV9TRVQKK0FDX1BST0dfSU5TVEFMTAorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVy
bF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQlJDVExdLCBbYnJjdGxdKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0lQXSwgW2lwXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCSVNPTl0sIFtiaXNv
bl0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbRkxFWF0sIFtmbGV4XSkKK0FTX0lGKFt0ZXN0ICJ4
JHhhcGkiID0gInh5Il0sIFsKKyAgICBBWF9QQVRIX1BST0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJs
LWNvbmZpZ10pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10p
CitdKQorQVNfSUYoW3Rlc3QgIngkb2NhbWx0b29scyIgPSAieHkiXSwgWworICAgIEFDX1BST0df
T0NBTUwKKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMiID0gInhubyJdLCBbCisgICAgICAgIEFT
X0lGKFt0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIl0sIFsKKyAgICAgICAgICAg
IEFDX01TR19FUlJPUihbT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9j
YW1sXSldKQorICAgICAgICBvY2FtbHRvb2xzPSJuIgorICAgIF0pCitdKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihbdGVzdCAieCRweXRob250b29scyIgPSAi
eHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIl0sIFsKKyAg
ICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhP
TlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJdLCBbUFlUSE9OPSJweXRob24iXSwKKyAg
ICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRl
IHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BZVEhPTlBBVEhdLCBbJFBZVEhP
Tl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04oWzJdLCBbM10pCisgICAgQVhfQ0hFQ0tf
UFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMKCkKK10pCitBWF9QQVRIX1BS
T0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRdKQorQVhfQ0hFQ0tfVURFVihbNTldKQor
QVhfQ0hFQ0tfVVVJRAorUEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwgZ2xpYi0yLjApCisKKyMgQ2hl
Y2sgbGlicmFyeSBwYXRoCitBWF9ERUZBVUxUX0xJQgorCisjIENoZWNrcyBmb3IgbGlicmFyaWVz
LgorQUNfQ0hFQ0tfTElCKFthaW9dLCBbaW9fc2V0dXBdLCBbc3lzdGVtX2Fpbz0ieSJdLCBbc3lz
dGVtX2Fpbz0ibiJdKQorQUNfU1VCU1Qoc3lzdGVtX2FpbykKK0FDX0NIRUNLX0xJQihbY3J5cHRv
XSwgW01ENV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJjcnlwdG9dKV0p
CitBQ19DSEVDS19MSUIoW2V4dDJmc10sIFtleHQyZnNfb3BlbjJdLCBbbGliZXh0MmZzPSJ5Il0s
IFtsaWJleHQyZnM9Im4iXSkKK0FDX1NVQlNUKGxpYmV4dDJmcykKK0FDX0NIRUNLX0xJQihbZ2Ny
eXB0XSwgW2djcnlfbWRfaGFzaF9idWZmZXJdLCBbbGliZ2NyeXB0PSJ5Il0sIFtsaWJnY3J5cHQ9
Im4iXSkKK0FDX1NVQlNUKGxpYmdjcnlwdCkKK0FDX0NIRUNLX0xJQihbcHRocmVhZF0sIFtwdGhy
ZWFkX2NyZWF0ZV0sIFtdICwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJw
dGhyZWFkXSldKQorQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1lXSkKK0FDX0NIRUNL
X0xJQihbdXVpZF0sIFt1dWlkX2NsZWFyXSwgW10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQg
bm90IGZpbmQgbGlidXVpZF0pXSkKK0FDX0NIRUNLX0xJQihbeWFqbF0sIFt5YWpsX2FsbG9jXSwg
W10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgeWFqbF0pXSkKK0FDX0NIRUNL
X0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmlu
ZCB6bGliXSldKQorQUNfQ0hFQ0tfTElCKFtpY29udl0sIFtsaWJpY29udl9vcGVuXSwgW2xpYmlj
b252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQorQUNfU1VCU1QobGliaWNvbnYpCisKKyMgQXV0b3Nj
YW4gc3R1ZmYgKGV4Y2VwdCBmb3IgeWFqbC95YWpsX3ZlcnNpb24uaCBjaGVjaykKKyMgQ2hlY2tz
IGZvciBoZWFkZXIgZmlsZXMuCitBQ19GVU5DX0FMTE9DQQorQUNfQ0hFQ0tfSEVBREVSUyhbIFwK
KyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGludHR5cGVzLmggbGliaW50bC5o
IGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAgICAgICBuZXRkYi5oIG5ldGluZXQvaW4u
aCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCisgICAgICAgICAgICAgICAg
c3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21vdW50Lmggc3lzL3BhcmFtLmgg
XAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3RhdHZmcy5oIHN5cy90aW1lLmgg
c3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAgICAgICB1bmlzdGQuaCB5YWpsL3lhamxf
dmVyc2lvbi5oIFwKKyAgICAgICAgICAgICAgICBdKQorCisjIENoZWNrcyBmb3IgdHlwZWRlZnMs
IHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCitBQ19IRUFERVJfU1RE
Qk9PTAorQUNfVFlQRV9VSURfVAorQUNfQ19JTkxJTkUKK0FDX1RZUEVfSU5UMTZfVAorQUNfVFlQ
RV9JTlQzMl9UCitBQ19UWVBFX0lOVDY0X1QKK0FDX1RZUEVfSU5UOF9UCitBQ19UWVBFX01PREVf
VAorQUNfVFlQRV9PRkZfVAorQUNfVFlQRV9QSURfVAorQUNfQ19SRVNUUklDVAorQUNfVFlQRV9T
SVpFX1QKK0FDX1RZUEVfU1NJWkVfVAorQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3Rf
Ymxrc2l6ZV0pCitBQ19TVFJVQ1RfU1RfQkxPQ0tTCitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qg
c3RhdC5zdF9yZGV2XSkKK0FDX1RZUEVfVUlOVDE2X1QKK0FDX1RZUEVfVUlOVDMyX1QKK0FDX1RZ
UEVfVUlOVDY0X1QKK0FDX1RZUEVfVUlOVDhfVAorQUNfQ0hFQ0tfVFlQRVMoW3B0cmRpZmZfdF0p
CisKKyMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KK0FDX0ZVTkNfRVJST1JfQVRfTElO
RQorQUNfRlVOQ19GT1JLCitBQ19GVU5DX0ZTRUVLTworQUNfRlVOQ19MU1RBVF9GT0xMT1dTX1NM
QVNIRURfU1lNTElOSworQUNfSEVBREVSX01BSk9SCitBQ19GVU5DX01BTExPQworQUNfRlVOQ19N
S1RJTUUKK0FDX0ZVTkNfTU1BUAorQUNfRlVOQ19SRUFMTE9DCitBQ19GVU5DX1NUUk5MRU4KK0FD
X0ZVTkNfU1RSVE9ECitBQ19DSEVDS19GVU5DUyhbIFwKKyAgICAgICAgICAgICAgICBhbGFybSBh
dGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3luYyBmdHJ1bmNhdGUgXAorICAg
ICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhvc3RuYW1lIGdldHBhZ2VzaXpl
IGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAgaW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0
aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKKyAgICAgICAgICAgICAgICBta2Zp
Zm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2VsZWN0IHNldGVudiBc
CisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVw
IHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAgICAgIHN0cnBicmsgc3RycmNociBzdHJz
cG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0IFwKKyAgICAgICAgICAgICAg
ICB1bmFtZSBcCisgICAgICAgICAgICAgICAgXSkKKworQUNfT1VUUFVUKCkKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxl
Ci0tLSBhL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgYi90b29scy9kZWJ1Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQlNb24g
RmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTIxLDcgKzIxLDYgQEAgeGdfYWxsLmE6ICQo
WEdfT0JKUykgTWFrZWZpbGUgJChYR19IRFJTKQogIwkkKENDKSAtbTMyIC1jIC1vICRAICReCiAK
IHhlbi1oZWFkZXJzOgotCSQoTUFLRSkgLUMgLi4vLi4vLi4vY2hlY2sgCiAJJChNQUtFKSAtQyAu
Li8uLi8uLi9pbmNsdWRlCiAKICMgeGdfbWFpbi5vOiB4Z19tYWluLmMgTWFrZWZpbGUgJChYR19I
RFJTKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvaW5zdGFsbC5z
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29s
cy9pbnN0YWxsLnNoCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEg
QEAKKy4uL2luc3RhbGwuc2gKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIgY2E4
MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9saWJmc2ltYWdlL01ha2VmaWxlCi0tLSBh
L3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEy
ICswMTAwCkBAIC0zLDcgKzMsMTEgQEAgaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5t
awogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNlcmZzIGlzbzk2NjAgZmF0IHpmcwogU1VC
RElSUy0kKENPTkZJR19YODYpICs9IHhmcwotU1VCRElSUy15ICs9ICQoc2hlbGwgZW52IENDPSIk
KENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgkKENPTkZJR19FWFQyRlMpLCB5KQorICAg
IFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisgICAgU1VCRElSUy15ICs9IGV4dDJmcwor
ZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFsbAogYWxsIGNsZWFuIGluc3RhbGw6ICU6
IHN1YmRpcnMtJQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbGli
ZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJl
eHQyZnMJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIxICswLDAgQEAKLSMhL2Jpbi9zaAotCi1j
YXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8ZXh0MmZzL2V4dDJmcy5oPgotCi1pbnQg
bWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9GCi0KLSR7Q0MtZ2NjfSAtbyBleHQyLXRl
c3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVsbCAyPiYxCi1pZiBbICQ/ID0gMCBdOyB0
aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNobyBleHQyZnMKLWZpCi0KLXJtIC1mIGV4
dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4
N2IwOWU5M2FhIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQotLS0gYS90b29scy9saWJ4ZW4vTWFrZWZp
bGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhlbi9NYWtl
ZmlsZQlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTIyLDEyICsyMiwxMiBAQCBN
QUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtSWluY2x1ZGUgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwyLWNvbmZpZyAtLWNmbGFncykgXAotICAg
ICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxhZ3MpIFwKKyAgICAgICAgICAkKHNoZWxs
ICQoWE1MMl9DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAkKENVUkxfQ09O
RklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElDCiAKLUxERkxBR1MgKz0gJChzaGVsbCB4
bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAgJChzaGVsbCBjdXJsLWNvbmZpZyAtLWxp
YnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyX0NPTkZJRykgLS1saWJzKSBcCisgICAgICAg
ICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1saWJzKQogCiBMSUJYRU5BUElfSERSUyA9ICQo
d2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5jbHVkZS94ZW4vYXBpL3hlbl9hbGwuaAog
TElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywgJS5vLCAkKHdpbGRjYXJkIHNyYy8qLmMp
KQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbGlieGwvTWFrZWZp
bGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiAr
MDEwMApAQCAtMTksMTAgKzE5LDYgQEAgaWZlcSAoJChDT05GSUdfTGludXgpLHkpCiBMSUJVVUlE
X0xJQlMgKz0gLWx1dWlkCiBlbmRpZgogCi1pZmVxICgkKENPTkZJR19ZQUpMX1ZFUlNJT04pLHkp
Ci1DRkxBR1MgKz0gLURIQVZFX1lBSkxfVkVSU0lPTgotZW5kaWYKLQogTElCWExfTElCUyA9CiBM
SUJYTF9MSUJTID0gJChMRExJQlNfbGlieGVuY3RybCkgJChMRExJQlNfbGlieGVuZ3Vlc3QpICQo
TERMSUJTX2xpYnhlbnN0b3JlKSAkKExETElCU19saWJibGt0YXBjdGwpICQoVVRJTF9MSUJTKSAk
KExJQlVVSURfTElCUykKIApAQCAtNTYsNyArNTIsNyBAQCBMSUJYTF9PQkpTID0gZmxleGFycmF5
Lm8gbGlieGwubyBsaWJ4bF9jCiAJCQlsaWJ4bF9xbXAubyBsaWJ4bF9ldmVudC5vICQoTElCWExf
T0JKUy15KQogTElCWExfT0JKUyArPSBfbGlieGxfdHlwZXMubyBsaWJ4bF9mbGFzay5vIF9saWJ4
bF90eXBlc19pbnRlcm5hbC5vCiAKLSQoTElCWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19s
aWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxBR1NfbGlieGVuc3RvcmUpICQo
Q0ZMQUdTX2xpYmJsa3RhcGN0bCkKKyQoTElCWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19s
aWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxBR1NfbGlieGVuc3RvcmUpICQo
Q0ZMQUdTX2xpYmJsa3RhcGN0bCkgLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvY29uZmlnLmgK
IAogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhsdV9jZmdfbC5oIF9saWJ4bF9saXN0LmgK
IEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVfY2ZnX2wuYwpAQCAtNjksNiArNjUsNyBA
QCBDTElFTlRTID0geGwgdGVzdGlkbAogWExfT0JKUyA9IHhsLm8geGxfY21kaW1wbC5vIHhsX2Nt
ZHRhYmxlLm8geGxfc3hwLm8KICQoWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5j
dHJsKSAjIEZvciB4ZW50b29sbG9nLmgKICQoWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19s
aWJ4ZW5saWdodCkKKyQoWExfT0JKUyk6IENGTEFHUyArPSAtaW5jbHVkZSAkKFhFTl9ST09UKS90
b29scy9jb25maWcuaCAjIGxpYnhsX2pzb24uaCBuZWVkcyBpdC4KIAogdGVzdGlkbC5vOiBDRkxB
R1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxBR1NfbGlieGVubGlnaHQpCiB0ZXN0aWRs
LmM6IGxpYnhsX3R5cGVzLmlkbCBnZW50ZXN0LnB5IGxpYnhsLmggJChBVVRPSU5DUykKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2xpYnhsL2xpYnhsX2pzb24uaAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF9qc29uLmgJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24uaAlNb24gRmViIDIwIDIzOjE4OjAxIDIw
MTIgKzAxMDAKQEAgLTE4LDcgKzE4LDcgQEAKICNpbmNsdWRlIDx5YWpsL3lhamxfZ2VuLmg+CiAj
aW5jbHVkZSA8eWFqbC95YWpsX3BhcnNlLmg+CiAKLSNpZmRlZiBIQVZFX1lBSkxfVkVSU0lPTgor
I2lmZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAogIyAgaW5jbHVkZSA8eWFqbC95YWpsX3Zl
cnNpb24uaD4KICNlbmRpZgogCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0
b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0X2xpYi5tNAlNb24gRmViIDIwIDIzOjE4
OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitBQ19ERUZVTihbQVhfREVGQVVMVF9MSUJd
LAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0Il0sIFsKKyAgICBMSUJfUEFUSD0ibGli
NjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkKK0FDX1NVQlNUKExJQl9QQVRIKV0pCisK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL200L2Rpc2FibGVfZmVh
dHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JU
XSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0k
MV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAg
YXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInh5ZXMiXSwgWworICAgIGF4
X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4X2N2XyQxPSJ5Igor
XSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
ZGQ4N2IwOWU5M2FhIHRvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2VuYWJsZV9mZWF0dXJl
Lm00CU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEzIEBACitBQ19E
RUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisg
ICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4
JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVzdCAieCRl
bmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAteiAkYXhf
Y3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJTVCgk
MSldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbTQvb2NhbWwu
bTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9v
bHMvbTQvb2NhbWwubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEs
MjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAorZG5sIGZyb20gaHR0cDovL2Zv
cmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFJpY2hh
cmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgU3RlZmFubyBaYWNjaGly
b2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBPbGl2aWVyIEFuZHJpZXUKK2RubCBDb3B5
cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3BoZSBGaWxsacOidHJlCitkbmwgQ29weXJp
Z2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8KK2RubAorZG5sIEZvciBkb2N1bWVudGF0
aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFuIHBhZ2UuCisKK0FDX0RFRlVOKFtBQ19Q
Uk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIEFDX0NIRUNLX1RP
T0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8i
OyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZl
cnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCB2ZXJzaW9u
IGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0Cisg
ICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgorICAgICAgICBPQ0FNTExJQj1gJE9D
QU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAnICcg
LWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0dfUkVTVUxUKFtPQ0FNTExJQiBwcmV2aW91
c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBmaQorICAgICBBQ19NU0dfUkVTVUxUKFtP
Q2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkKKworICAgICBBQ19TVUJTVChbT0NBTUxW
RVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElCXSkKKworICAgICAjIGNoZWNraW5nIGZv
ciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTE9QVF0sW29jYW1sb3B0XSxbbm9d
KQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsg
dGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGls
YXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwgc2Vk
IC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJT
SU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNp
b25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC5dKQorCSAgICBPQ0FN
TE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCisKKyAgICAg
QUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAor
ICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRdLFtvY2FtbGMub3B0XSxbbm9dKQorICAg
ICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9D
QU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAK
KwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICBB
Q19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRp
c2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBm
aQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NB
TUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRET1RPUFRdLFtv
Y2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0
aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4q
dmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAi
JE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbiBkaWZm
ZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLl0pCisJICAgZWxzZQorCSAg
ICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZpCisgICAgICAgIGZpCisgICAgIGZp
CisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAgZmkKKworICBBQ19TVUJTVChbT0NBTUxD
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAorICBBQ19DSEVDS19UT09MKFtP
Q0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIEFDX0NI
RUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Ig
b2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LVE9QXSxbb2NhbWxta3RvcF0sW25v
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCisgIEFDX0NIRUNLX1RPT0woW09DQU1M
TUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisg
IEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxkb2NdLFtub10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEJVSUxEXSxbb2NhbWxidWls
ZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxMRVhdLAorW2RubAorICAj
IGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWF0sW29jYW1s
bGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgiICE9ICJubyI7IHRoZW4KKyAgICBBQ19D
SEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1sbGV4Lm9wdF0sW25vXSkKKyAgICBpZiB0
ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRoZW4KKwlPQ0FNTExFWD0kT0NBTUxMRVhE
T1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChbT0NBTUxMRVhdKQorXSkKKworQUNfREVG
VU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxZQUND
XSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChbT0NBTUxZQUNDXSkKK10pCisKKworQUNf
REVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FN
TF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0CisgIEFDX0NIRUNLX1RPT0woW0NBTUxQ
NF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENBTUxQNCIgIT0gIm5vIjsgdGhlbgorICAg
ICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24gKlwo
LipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lP
TiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sY10p
CisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBmaQorICBBQ19TVUJTVChbQ0FNTFA0XSkK
KworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9vbHMKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FN
TFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9dLFtj
YW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPRl0sW2NhbWxwNG9mXSxbbm9d
KQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtjYW1scDRvb2ZdLFtub10pCisgIEFDX0NI
RUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChb
Q0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJd
LFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRSRl0sW2NhbWxwNHJmXSxb
bm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisgIEFDX1NVQlNUKFtDQU1MUDRPXSkKKyAg
QUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9PRl0pCisgIEFDX1NVQlNU
KFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0UFJPRl0pCisgIEFDX1NVQlNUKFtDQU1M
UDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0df
RklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEZJTkRdLFtvY2Ft
bGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJTkRdKQorXSkKKworCitkbmwgVGhhbmtz
IHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlzIG5leHQgYml0IG91dCBmb3IgdXMuCitk
bmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0ggaWYgaXQncyBub3QgZGVmaW5lZCBhbHJl
YWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4KK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FN
TF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX0ZJTkRMSUJdKWRubAorCisgIEFD
X01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIgcGFja2FnZSAkMV0pCisKKyAgdW5zZXQg
Zm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisgIGZvciBwa2cgaW4gJDEgJDIgOyBkbwor
ICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVu
CisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisgICAgICBBU19UUl9TSChbT0NBTUxfUEtH
XyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRvbmUK
KyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm90
IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9bm8KKyAgZmkKKworICBBQ19T
VUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitdKQorCisKK0FDX0RFRlVOKFtBQ19DSEVD
S19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBtb2R1
bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCitvcGVuICQzCitFT0YKKyAgdW5z
ZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRvCisgICAgaWYgJE9DQU1MQyAtYyAtSSAi
JCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4KKyAgICAgIGZvdW5kPXllcworICAgICAg
YnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVzdCAiJGZvdW5kIiA7IHRoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5k
XSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChbJDFdKQorXSkKKworCitkbmwgWFhYIENy
b3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1dPUkRfU0laRV0sCitbZG5s
CisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2Zv
ciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgor
ICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5cy53b3JkX3NpemUpCisgIEVPRgorICBP
Q0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9D
QU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9XT1JEX1NJWkVdKQorXSkKKworQUNf
REVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19Q
Uk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtPQ2FtbCBTeXMub3NfdHlwZV0pCisK
KyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfc3RyaW5nKFN5cy5vc190eXBlKTs7
CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01TR19S
RVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VCU1QoW09DQU1MX09TX1RZUEVdKQorXSkK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL200L3BhdGhfb3JfZmFp
bC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9wYXRoX29yX2ZhaWwubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhfUFJPR19PUl9GQUlMXSwKK1tBQ19QQVRI
X1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3QgeCIkeyQxfSIgPT0geCJubyIgCit0aGVu
CisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCAkMiwgcGxlYXNlIGluc3RhbGwgJDJd
KQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbTQvcGtn
Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL200L3BrZy5tNAlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwx
NTcgQEAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQgdXRpbGlzZSBwa2ctY29uZmln
LiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgc2VyaWFsIDEgKHBrZy1jb25maWctMC4y
NCkKKyMgCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVzIFJlbW5hbnQgPHNjb3R0QG5l
dHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisjIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisjIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9y
CisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisjCisjIFRoaXMgcHJvZ3Jh
bSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQK
KyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50
eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFp
bHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy
aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ
bGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuCisjCisjIEFzIGEg
c3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5
b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250
YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwgeW91
IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0
IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KKworIyBQS0dfUFJPR19QS0df
Q09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KK0FDX0RFRlVOKFtQS0dfUFJPR19QS0dfQ09ORklHXSwKK1ttNF9wYXR0ZXJuX2ZvcmJpZChb
Xl8/UEtHX1tBLVpfXSskXSkKK200X3BhdHRlcm5fYWxsb3coW15QS0dfQ09ORklHKF9QQVRIKT8k
XSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUddLCBbcGF0aCB0byBwa2ctY29uZmlnIHV0aWxpdHld
KQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19QQVRIXSwgW2RpcmVjdG9yaWVzIHRvIGFkZCB0byBw
a2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGhdKQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19MSUJESVJd
LCBbcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBidWlsdC1pbiBzZWFyY2ggcGF0aF0pCisK
K2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05GSUdfc2V0IiAhPSAieHNldCI7IHRoZW4KKwlB
Q19QQVRIX1RPT0woW1BLR19DT05GSUddLCBbcGtnLWNvbmZpZ10pCitmaQoraWYgdGVzdCAtbiAi
JFBLR19DT05GSUciOyB0aGVuCisJX3BrZ19taW5fdmVyc2lvbj1tNF9kZWZhdWx0KFskMV0sIFsw
LjkuMF0pCisJQUNfTVNHX0NIRUNLSU5HKFtwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24g
JF9wa2dfbWluX3ZlcnNpb25dKQorCWlmICRQS0dfQ09ORklHIC0tYXRsZWFzdC1wa2djb25maWct
dmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgorCQlBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
CWVsc2UKKwkJQUNfTVNHX1JFU1VMVChbbm9dKQorCQlQS0dfQ09ORklHPSIiCisJZmkKK2ZpW11k
bmwKK10pIyBQS0dfUFJPR19QS0dfQ09ORklHCisKKyMgUEtHX0NIRUNLX0VYSVNUUyhNT0RVTEVT
LCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQorIworIyBDaGVjayB0
byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMgZXhpc3RzLiAgU2ltaWxh
cgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBub3Qgc2V0IHZhcmlhYmxlcyBv
ciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1lbWJlciB0aGF0IG00IGV4cGFuZHMgQUNf
UkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisjIG9ubHkgYXQgdGhlIGZpcnN0IG9jY3Vy
ZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBwbGFjZQorIyBpdCdzIGNhbGxl
ZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdpdGhpbiBhbiAiaWYiLCB5b3UK
KyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFsbHkKKyMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RF
RlVOKFtQS0dfQ0hFQ0tfRVhJU1RTXSwKK1tBQ19SRVFVSVJFKFtQS0dfUFJPR19QS0dfQ09ORklH
XSlkbmwKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCisgICAgQUNfUlVOX0xPRyhbJFBL
R19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgIiQxIl0pOyB0aGVuCisgIG00X2RlZmF1
bHQoWyQyXSwgWzpdKQorbTRfaWZ2YWxuKFskM10sIFtlbHNlCisgICQzXSlkbmwKK2ZpXSkKKwor
IyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFORF0sIFtNT0RVTEVTXSkKKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCittNF9kZWZpbmUoW19QS0df
Q09ORklHXSwKK1tpZiB0ZXN0IC1uICIkJDEiOyB0aGVuCisgICAgcGtnX2N2X1tdJDE9IiQkMSIK
KyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorICAgIFBLR19DSEVDS19FWElTVFMo
WyQzXSwKKyAgICAgICAgICAgICAgICAgICAgIFtwa2dfY3ZfW10kMT1gJFBLR19DT05GSUcgLS1b
XSQyICIkMyIgMj4vZGV2L251bGxgXSwKKwkJICAgICBbcGtnX2ZhaWxlZD15ZXNdKQorIGVsc2UK
KyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2ZpW11kbmwKK10pIyBfUEtHX0NPTkZJRworCisjIF9Q
S0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorQUNfREVGVU4oW19QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRF0sCitbQUNfUkVRVUlSRShb
UEtHX1BST0dfUEtHX0NPTkZJR10pCitpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtnY29uZmln
LXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9
eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZD1ubworZmlbXWRu
bAorXSkjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorCisKKyMgUEtHX0NIRUNLX01PRFVM
RVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwKKyMgW0FDVElP
Ti1JRi1OT1QtRk9VTkRdKQorIworIworIyBOb3RlIHRoYXQgaWYgdGhlcmUgaXMgYSBwb3NzaWJp
bGl0eSB0aGUgZmlyc3QgY2FsbCB0bworIyBQS0dfQ0hFQ0tfTU9EVUxFUyBtaWdodCBub3QgaGFw
cGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgorIyBleHBsaWNpdCBjYWxsIHRv
IFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25maWd1cmUuYWMKKyMKKyMKKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
K0FDX0RFRlVOKFtQS0dfQ0hFQ0tfTU9EVUxFU10sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtH
X0NPTkZJR10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0NGTEFHU10sIFtDIGNvbXBpbGVyIGZsYWdz
IGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlkbmwKK0FDX0FSR19WQVIoWyQxXVtfTElC
U10sIFtsaW5rZXIgZmxhZ3MgZm9yICQxLCBvdmVycmlkaW5nIHBrZy1jb25maWddKWRubAorCitw
a2dfZmFpbGVkPW5vCitBQ19NU0dfQ0hFQ0tJTkcoW2ZvciAkMV0pCisKK19QS0dfQ09ORklHKFsk
MV1bX0NGTEFHU10sIFtjZmxhZ3NdLCBbJDJdKQorX1BLR19DT05GSUcoWyQxXVtfTElCU10sIFts
aWJzXSwgWyQyXSkKKworbTRfZGVmaW5lKFtfUEtHX1RFWFRdLCBbQWx0ZXJuYXRpdmVseSwgeW91
IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyAkMVtdX0NGTEFHUworYW5kICQxW11f
TElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBjYWxsIHBrZy1jb25maWcuCitTZWUgdGhlIHBrZy1j
b25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy5dKQorCitpZiB0ZXN0ICRwa2dfZmFpbGVk
ID0geWVzOyB0aGVuCisgICAJQUNfTVNHX1JFU1VMVChbbm9dKQorICAgICAgICBfUEtHX1NIT1JU
X0VSUk9SU19TVVBQT1JURUQKKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3Vw
cG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICAkMVtdX1BLR19FUlJPUlM9YCRQS0dfQ09ORklH
IC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICIkMiIgMj4mMWAKKyAgICAgICAgZWxzZSAK
KwkgICAgICAgICQxW11fUEtHX0VSUk9SUz1gJFBLR19DT05GSUcgLS1wcmludC1lcnJvcnMgIiQy
IiAyPiYxYAorICAgICAgICBmaQorCSMgUHV0IHRoZSBuYXN0eSBlcnJvciBtZXNzYWdlIGluIGNv
bmZpZy5sb2cgd2hlcmUgaXQgYmVsb25ncworCWVjaG8gIiQkMVtdX1BLR19FUlJPUlMiID4mQVNf
TUVTU0FHRV9MT0dfRkQKKworCW00X2RlZmF1bHQoWyQ0XSwgW0FDX01TR19FUlJPUigKK1tQYWNr
YWdlIHJlcXVpcmVtZW50cyAoJDIpIHdlcmUgbm90IG1ldDoKKworJCQxX1BLR19FUlJPUlMKKwor
Q29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1lbnQgdmFyaWFi
bGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJlZml4Lgor
CitfUEtHX1RFWFRdKWRubAorICAgICAgICBdKQorZWxpZiB0ZXN0ICRwa2dfZmFpbGVkID0gdW50
cmllZDsgdGhlbgorICAgICAJQUNfTVNHX1JFU1VMVChbbm9dKQorCW00X2RlZmF1bHQoWyQ0XSwg
W0FDX01TR19GQUlMVVJFKAorW1RoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91
bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9yIHNldCB0
aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0aCB0byBw
a2ctY29uZmlnLgorCitfUEtHX1RFWFQKKworVG8gZ2V0IHBrZy1jb25maWcsIHNlZSA8aHR0cDov
L3BrZy1jb25maWcuZnJlZWRlc2t0b3Aub3JnLz4uXSlkbmwKKyAgICAgICAgXSkKK2Vsc2UKKwkk
MVtdX0NGTEFHUz0kcGtnX2N2X1tdJDFbXV9DRkxBR1MKKwkkMVtdX0xJQlM9JHBrZ19jdl9bXSQx
W11fTElCUworICAgICAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorCSQzCitmaVtdZG5sCitdKSMg
UEtHX0NIRUNLX01PRFVMRVMKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRv
b2xzL200L3B5dGhvbl9kZXZlbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25fZGV2ZWwubTQJTW9uIEZlYiAyMCAyMzox
ODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTggQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRI
T05fREVWRUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhvbiBkZXZlbF0pCisKK2AkUFlU
SE9OIC1jICcKK2ltcG9ydCBvcy5wYXRoLCBzeXMKK2ZvciBwIGluIHN5cy5wYXRoOgorICAgIGlm
IG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIpOgorICAgICAgICBzeXMuZXhp
dCgwKQorc3lzLmV4aXQoMSkKKycgPiAvZGV2L251bGwgMj4mMWAKKworaWYgdGVzdCAiJD8iICE9
ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoW1B5
dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZF0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChb
eWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL200
L3B5dGhvbl92ZXJzaW9uLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00CU1vbiBGZWIgMjAgMjM6MTg6
MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEyIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9O
X1ZFUlNJT05dLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhvbiB2ZXJzaW9uID49ICQxLiQy
IF0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZv
IDwgKCQxLCAkMikiKSknYAoraWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92
ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFgCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFD
X01TR19FUlJPUigKKyAgICAgICAgWyRweXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVt
IHJlcXVpcmVkIHZlcnNpb24gaXMgJDEuJDJdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3ll
c10pCitmaV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9tNC9w
eXRob25feG1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3Rvb2xzL200L3B5dGhvbl94bWwubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fWE1MXSwKK1tB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24geG1sLmRvbS5taW5pZG9tXSkKK2AkUFlUSE9OIC1j
ICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAg
ICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCB4
bWwuZG9tLm1pbmlkb20gbW9kdWxlXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
ZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbTQvc2V0X2Nm
bGFnc19sZGZsYWdzLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5tNAlNb24gRmViIDIwIDIzOjE4
OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyMCBAQAorQUNfREVGVU4oW0FYX1NFVF9GTEFHU10s
CitbZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCitkbworICAgIFBSRVBFTkRfQ0ZMQUdT
Kz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIKK2RvCisgICAg
UFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5E
X0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3Ig
bGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxh
ZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1Mi
CitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFHUyJdKQor
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9tNC91ZGV2Lm00Ci0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200
L3VkZXYubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMzIgQEAK
K0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGlu
dXgtZ251IgordGhlbgorICAgIEFDX1BBVEhfUFJPRyhbVURFVkFETV0sIFt1ZGV2YWRtXSwgW25v
XSkKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJubyIgCisgICAgdGhlbgorICAgICAg
ICBBQ19QQVRIX1BST0coW1VERVZJTkZPXSwgW3VkZXZpbmZvXSwgW25vXSkKKyAgICAgICAgaWYg
dGVzdCB4IiR7VURFVklORk99IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBB
Q19NU0dfRVJST1IoCisgICAgICAgICAgICAgICAgW1VuYWJsZSB0byBmaW5kIHVkZXZhZG0gb3Ig
dWRldmluZm8sIHBsZWFzZSBpbnN0YWxsIHVkZXZdKQorICAgICAgICBmaQorICAgICAgICB1ZGV2
dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGVsc2UKKyAgICAg
ICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCisgICAg
ZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAgdGhlbgorICAgICAgICBBQ19Q
QVRIX1BST0coW0hPVFBMVUddLCBbaG90cGx1Z10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIk
e0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBBQ19NU0dfRVJS
T1IoW3VkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVyXSkKKyAg
ICAgICAgZmkKKyAgICBmaQorZWxzZQorICAgIEFDX1BBVEhfUFJPRyhbVk5DT05GSUddLCBbdm5j
b25maWddLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1ZOQ09ORklHfSIgPT0geCJubyIKKyAgICB0
aGVuCisgICAgICAgIEFDX01TR19FUlJPUihbTm90IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUg
dG8gZmluZCB2bmRdKQorICAgIGZpCitmaQorXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4
N2IwOWU5M2FhIHRvb2xzL200L3V1aWQubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdXVpZC5tNAlNb24gRmViIDIwIDIzOjE4OjAx
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1VVSURdLAor
W2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0aGVuCisgICAgQUNfQ0hFQ0tf
SEVBREVSKFt1dWlkL3V1aWQuaF0sLAorCSAgICBbQUNfTVNHX0VSUk9SKFtjYW5ub3QgZmluZCB1
dWlkIGhlYWRlcnNdKV0pCitlbHNlCisgICAgQUNfQ0hFQ0tfSEVBREVSKFt1dWlkLmhdLCwKKwkg
ICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzXSldKQorZmkKK10pCmRp
ZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB2ZXJzaW9uLnNoCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3ZlcnNpb24uc2gJTW9uIEZl
YiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNSBAQAorIyEvYmluL3NoCisKK01B
Sk9SPWBncmVwICJleHBvcnQgWEVOX1ZFUlNJT04iICQxIHwgc2VkICdzLy4qPS8vZycgfCB0ciAt
cyAiICJgCitNSU5PUj1gZ3JlcCAiZXhwb3J0IFhFTl9TVUJWRVJTSU9OIiAkMSB8IHNlZCAncy8u
Kj0vL2cnIHwgdHIgLXMgIiAiYAorcHJpbnRmICIlZC4lZCIgJE1BSk9SICRNSU5PUgo=

--===============5260582694761208521==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5260582694761208521==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 09:30:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzm3X-00054R-PU; Tue, 21 Feb 2012 09:30:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzm3V-000546-PH
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 09:30:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329816633!9079880!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10118 invoked from network); 21 Feb 2012 09:30:33 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:30:33 -0000
Received: by wibhi20 with SMTP id hi20so3285987wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 01:30:32 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr6101002wei.42.1329816632988
	(num_hops = 1); Tue, 21 Feb 2012 01:30:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=TfAOhltCKjhGSj7Cm+0kkqRwf+wL3FXYPaWp5WO/p5M=;
	b=YeedzpwvBTUe5Sikwknbkdm6IO7zIDYp+kj25/d5M/r1r88DW3G+vx+86z62sq0uuf
	xfkKzpvjNwIushfKSRJ09n1vOTOUnF8XHh9MutmON2tG3MdX5zj9GQCyaYLekg+wem8/
	KHz9f/w0uuVdu2yBMLU9SikSwY/Gr36uwDS1c=
Received: by 10.216.134.30 with SMTP id r30mr5073305wei.42.1329816632912;
	Tue, 21 Feb 2012 01:30:32 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id p10sm21753718wic.0.2012.02.21.01.30.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 01:30:32 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============5260582694761208521=="
MIME-Version: 1.0
X-Mercurial-Node: dd87b09e93aa539f4b72ab695a83e5f3ce372d53
Message-Id: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 20 Feb 2012 23:18:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH v5] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5260582694761208521==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    2 -
 README                            |    4 +
 autogen.sh                        |    8 +
 config/Tools.mk.in                |   50 +++++++
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  193 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 54 files changed, 843 insertions(+), 511 deletions(-)



--===============5260582694761208521==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzc2MjgxIC0zNjAwCiMgTm9kZSBJRCBkZDg3YjA5ZTkz
YWE1MzlmNGI3MmFiNjk1YTgzZTVmM2NlMzcyZDUzCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY0OgoKICogVXBkYXRlZCB0
byB0aXAuCgogKiBJbmNsdWRlIGNvbmZpZy5oIGZyb20gY29tcGlsZXIgY29tbWFuZCBsaW5lIHdo
ZW4gYnVpbGRpbmcgbGlieGwgYW5kCiAgIHhsIHRvIGFzc3VyZSB5YWpsX3ZlcnNpb24uaCBwcmVz
ZW5jZSBhbmQgY29ycmVjdGx5IGRldGVjdCB5YWpsCiAgIHZlcnNpb24uCgogKiBBZGRlZCBnbGli
LTIuMCBjaGVjayB3aXRoIGFwcHJvcGlhdGUgbTQgbWFjcm9zLgoKICogUHVyZ2VkIGNvbmZpZy5o
LmluIGZyb20gdW5uZWNlc3NhcnkgZGVmaW5lcyB0aGF0IGNvdWxkIG1lc3Mgd2l0aAogICB0aGUg
YnVpbGQgc3lzdGVtLgoKICogUmVtb3ZlZCB0b29scy9jb25maWcuc3ViLCB0b29scy9jb25maWcu
Z3Vlc3MsIHRvb2xzL2NvbmZpZ3VyZSBhbmQKICAgY29uZmlndXJlIHRvIG1ha2UgdGhlIHBhdGNo
IGZpdCBtYWlsaW5nIGxpc3QgbGltaXQuCgpDaGFuZ2VzIHNpbmNlIHYzOgoKICogQ29waWVkIGNv
bmZpZy5ndWVzcyBhbmQgY29uZmlnLnN1YiBmcm9tIGF1dG9tYWtlIDEuMTEuCgogKiBBZGRlZCBh
IHRlc3QgdG8gY2hlY2sgZm9yIHV1aWQuaCBvbiBCU0QgYW5kIHV1aWQvdXVpZC5oIG9uIExpbnV4
LgoKQ2hhbmdlcyBzaW5jZSB2MjoKCiAqIENoYW5nZWQgb3JkZXIgb2YgY29uZmlnL1Rvb2xzLm1r
IGluY2x1ZGUuCgogKiBBZGRlZCAiLWUiIHRvIGF1dG9nZW4uc2ggc2hlYmFuZy4KCiAqIEFkZGVk
IG5lY2Vzc2FyeSBmaWxlcyAoY29uZmlnLiopIGFuZCBvdXRwdXQgZnJvbSBBdXRvaGVhZGVyIGFu
ZAogICBBdXRvY29uZi4KCiAqIFJlbW92ZWQgQXV0b2NvbmYgZnJvbSBidWlsZCBkZXBlbmRlbmNp
ZXMgYW5kIHVwZGF0ZWQgUkVBRE1FLgoKQ2hhbmdlcyBzaW5jZSB2MToKCiAqIE1vdmVkIGF1dG9j
b25mIHN0dWZmIGluc2lkZSB0b29scyBmb2xkZXIuCgogKiBBZGQgTWFrZWZpbGUgcnVsZXMgZm9y
IGNsZWFuaW5nLgoKICogUmVtb3ZlZCBBdXRvbWFrZSBkZXBlbmRlbmN5LgoKICogQ3JlYXRlIGF1
dG9nZW4uc2ggdG8gYXV0b21hdGljYWxseSBjcmVhdGUgY29uZmlndXJlIHNjcmlwdCB3aGVuCiAg
IGJ1aWxkaW5nIGZyb20gc291cmNlIHJlcG9zaXRvcnkuCgogKiBDYWNoZWQgdmFsdWVzIG9mIG9w
dGlvbnMgcGFzc2VkIGZyb20gY29tbWFuZCBsaW5lLgoKICogQWRkIG5lY2Vzc2FyeSBpZ25vcmVz
IHRvIC5oZ2lnbm9yZS4KCiAqIEFkZGVkIEF1dG9jb25mIHRvIHRoZSBsaXN0IG9mIGRlcGVuZGVu
Y2llcy4KCiAqIENoYW5nZWQgaHlwZW4gdG8gdW5kZXJzY29yZSBpbiBYTUwyIGFuZCBDVVJMIHZh
cmlhYmxlIG5hbWVzLgoKICogQWRkZWQgc2NyaXB0IHRvIGdldCB2ZXJzaW9uIGZyb20geGVuL01h
a2VmaWxlLgoKICogU2V0IE9jYW1sIHRvb2xzIHRvIG9wdGlvbmFsLgoKICogQWRkZWQgcHJvY2Vk
ZW5jZSBvZiBtNC9vY2FtbC5tNC4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkz
YWEgLmhnaWdub3JlCi0tLSBhLy5oZ2lnbm9yZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIGIvLmhnaWdub3JlCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMzAz
LDYgKzMwMywxMiBAQAogXnRvb2xzL29jYW1sL2xpYnMveGwveGVubGlnaHRcLm1sJAogXnRvb2xz
L29jYW1sL2xpYnMveGwveGVubGlnaHRcLm1saSQKIF50b29scy9vY2FtbC94ZW5zdG9yZWQvb3hl
bnN0b3JlZCQKK150b29scy9hdXRvbTR0ZVwuY2FjaGUkCitedG9vbHMvY29uZmlnXC5oJAorXnRv
b2xzL2NvbmZpZ1wubG9nJAorXnRvb2xzL2NvbmZpZ1wuc3RhdHVzJAorXnRvb2xzL2NvbmZpZ1wu
Y2FjaGUkCiteY29uZmlnL1Rvb2xzXC5tayQKIF54ZW4vXC5iYW5uZXIuKiQKIF54ZW4vQkxPRyQK
IF54ZW4vU3lzdGVtLm1hcCQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIENv
bmZpZy5tawotLS0gYS9Db25maWcubWsJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyBiL0NvbmZpZy5tawlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTcwLDkgKzcw
LDYgQEAgRVhUUkFfSU5DTFVERVMgKz0gJChFWFRSQV9QUkVGSVgpL2luY2x1ZAogRVhUUkFfTElC
ICs9ICQoRVhUUkFfUFJFRklYKS8kKExJQkxFQUZESVIpCiBlbmRpZgogCi1CSVNPTgk/PSBiaXNv
bgotRkxFWAk/PSBmbGV4Ci0KIFBZVEhPTiAgICAgID89IHB5dGhvbgogUFlUSE9OX1BSRUZJWF9B
UkcgPz0gLS1wcmVmaXg9IiQoUFJFRklYKSIKICMgVGhlIGFib3ZlIHJlcXVpcmVzIHRoYXQgUFJF
RklYIGNvbnRhaW5zICpubyBzcGFjZXMqLiBUaGlzIHZhcmlhYmxlIGlzIGhlcmUKQEAgLTE3NSwz
MiArMTcyLDkgQEAgQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKFBSRVBFTkRfSU5DTFVERQogQVBQ
RU5EX0xERkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0xJQiksIC1MJChpKSkKIEFQUEVO
RF9DRkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0lOQ0xVREVTKSwgLUkkKGkpKQogCi1D
SEVDS19MSUIgPSAkKEVYVFJBX0xJQikgJChQUkVQRU5EX0xJQikgJChBUFBFTkRfTElCKQotQ0hF
Q0tfSU5DTFVERVMgPSAkKEVYVFJBX0lOQ0xVREVTKSAkKFBSRVBFTkRfSU5DTFVERVMpICQoQVBQ
RU5EX0lOQ0xVREVTKQotCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgOj0gLW5vcGllIC1mbm8tc3Rh
Y2stcHJvdGVjdG9yIC1mbm8tc3RhY2stcHJvdGVjdG9yLWFsbAogRU1CRURERURfRVhUUkFfQ0ZM
QUdTICs9IC1mbm8tZXhjZXB0aW9ucwogCi1DT05GSUdfTElCSUNPTlYgICA6PSAkKHNoZWxsIGV4
cG9ydCBPUz0iYHVuYW1lIC1zYCI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgZXhwb3J0IENI
RUNLX0xJQj0iJChDSEVDS19MSUIpIjsgXAotICAgICAgICAgICAgICAgICAgICAgICAuICQoWEVO
X1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNoOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGhh
c19saWIgbGliaWNvbnYuc28gJiYgZWNobyAneScgfHwgZWNobyAnbicpCi0KLUNPTkZJR19ZQUpM
X1ZFUlNJT04gOj0gJChzaGVsbCBleHBvcnQgT1M9ImB1bmFtZSAtc2AiOyBcCi0gICAgICAgICAg
ICAgICAgICAgICAgIGV4cG9ydCBDSEVDS19JTkNMVURFUz0iJChDSEVDS19JTkNMVURFUykiOyBc
Ci0gICAgICAgICAgICAgICAgICAgICAgIC4gJChYRU5fUk9PVCkvdG9vbHMvY2hlY2svZnVuY3Mu
c2g7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgaGFzX2hlYWRlciB5YWpsL3lhamxfdmVyc2lv
bi5oICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi0jIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9k
dWxlIChieSBkZWZhdWx0LCBGbGFzaykuCi1YU01fRU5BQkxFID89IG4KLUZMQVNLX0VOQUJMRSA/
PSAkKFhTTV9FTkFCTEUpCi0KLSMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBv
ciBHSVQncyBvd24gcHJvdG9jb2w/Ci0jIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9y
ZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKLSMgbWF5IGJsb2NrIGl0
KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93
bmxvYWRzCi0jIGZhaWwgb3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3Vy
IGVudmlyb25tZW50LgotR0lUX0hUVFAgPz0gbgotCiBYRU5fRVhURklMRVNfVVJMPWh0dHA6Ly94
ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzCiAjIEFsbCB0aGUgZmlsZXMgYXQgdGhh
dCBsb2NhdGlvbiB3ZXJlIGRvd25sb2FkZWQgZnJvbSBlbHNld2hlcmUgb24KICMgdGhlIGludGVy
bmV0LiAgVGhlIG9yaWdpbmFsIGRvd25sb2FkIFVSTCBpcyBwcmVzZXJ2ZWQgYXMgYSBjb21tZW50
CkBAIC0yMzksMTcgKzIxMyw0IEBAIFFFTVVfVEFHID89IDEyOGRlMjU0OWM1ZjI0ZTRhNDM3Yjg2
YmQyZTQKICMgU2hvcnQgYW5zd2VyIC0tIGRvIG5vdCBlbmFibGUgdGhpcyB1bmxlc3MgeW91IGtu
b3cgd2hhdCB5b3UgYXJlCiAjIGRvaW5nIGFuZCBhcmUgcHJlcGFyZWQgZm9yIHNvbWUgcGFpbi4K
IAotIyBPcHRpb25hbCBjb21wb25lbnRzCi1YRU5TVEFUX1hFTlRPUCAgICAgPz0geQotVlRQTV9U
T09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQSV9CSU5ESU5HUyA/PSBuCi1QWVRIT05fVE9PTFMg
ICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAgICAgID89IHkKLUNPTkZJR19NSU5JVEVSTSAgICA/
PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0gbgotQ09ORklHX1NZU1RFTV9MSUJBSU8gPz0geQog
Q09ORklHX1RFU1RTICAgICAgID89IHkKLQotaWZlcSAoJChPQ0FNTF9UT09MUykseSkKLU9DQU1M
X1RPT0xTIDo9ICQoc2hlbGwgb2NhbWxvcHQgLXYgPiAvZGV2L251bGwgMj4mMSAmJiBlY2hvICJ5
IiB8fCBlY2hvICJuIikKLWVuZGlmCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNh
YSBNYWtlZmlsZQotLS0gYS9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAK
KysrIGIvTWFrZWZpbGUJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC00MCwxMSAr
NDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdDogZGlzdC14ZW4g
ZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRpc3QtZG9jcyBkaXN0LW1pc2MK
IAogZGlzdC1taXNjOgotCSQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hlY2sKIAkkKElOU1RB
TExfREFUQSkgLi9DT1BZSU5HICQoRElTVERJUikKIAkkKElOU1RBTExfREFUQSkgLi9SRUFETUUg
JChESVNURElSKQogCSQoSU5TVEFMTF9QUk9HKSAuL2luc3RhbGwuc2ggJChESVNURElSKQotCSQo
SU5TVEFMTF9QUk9HKSB0b29scy9jaGVjay9jaGsgdG9vbHMvY2hlY2svY2hlY2tfKiB0b29scy9j
aGVjay9mdW5jcy5zaCAkKERJU1RESVIpL2NoZWNrCiBkaXN0LSU6IERFU1RESVI9JChESVNURElS
KS9pbnN0YWxsCiBkaXN0LSU6IGluc3RhbGwtJQogCUA6ICMgZG8gbm90aGluZwpkaWZmIC1yIGNh
ODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgUkVBRE1FCi0tLSBhL1JFQURNRQlNb24gRmViIDIw
IDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvUkVBRE1FCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAx
MiArMDEwMApAQCAtODksOSArODksMTMgQEAgMi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0
ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5IGZpcnN0IGJ1aWxkLCBvciBpZiB5b3Ugd2FudCB0
byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgog
CisgICAgIyAuL2NvbmZpZ3VyZQogICAgICMgbWFrZSB3b3JsZAogICAgICMgbWFrZSBpbnN0YWxs
CiAKKyAgIElmIHlvdSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAtLWhlbHAgdG8gc2Vl
IHRoZSBsaXN0IG9mCisgICBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25zIHdoZW4gYnVpbGRpbmcg
YW5kIGluc3RhbGxpbmcgWGVuLgorCiAgICBUaGlzIHdpbGwgY3JlYXRlIGFuZCBpbnN0YWxsIG9u
dG8gdGhlIGxvY2FsIG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQKICAgIHRoZSB4ZW4gYmluYXJ5ICh4
ZW4uZ3opLCB0aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgogCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGRkODdiMDllOTNhYSBhdXRvZ2VuLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL2F1dG9nZW4uc2gJTW9uIEZlYiAyMCAyMzoxODow
MSAyMDEyICswMTAwCkBAIC0wLDAgKzEsOCBAQAorIyEvYmluL3NoIC1lCitybSAtcmYgY29uZmln
dXJlCitjZCB0b29scworYXV0b2NvbmYKK2NkIC4uCitlY2hvICIjIS9iaW4vc2ggLWUiID4+IGNv
bmZpZ3VyZQorZWNobyAiY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgXCRAIiA+PiBjb25maWd1cmUK
K2NobW9kICt4IGNvbmZpZ3VyZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEg
Y29uZmlnL1Rvb2xzLm1rLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL2NvbmZpZy9Ub29scy5tay5pbglNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIg
KzAxMDAKQEAgLTAsMCArMSw1MCBAQAorIyBQcmVmaXggYW5kIGluc3RhbGwgZm9sZGVyCitQUkVG
SVggICAgICAgICAgICAgIDo9IEBwcmVmaXhACitMSUJMRUFGRElSX3g4Nl82NCAgIDo9IEBMSUJf
UEFUSEAKKworIyBBIGRlYnVnIGJ1aWxkIG9mIHRvb2xzPworZGVidWcgICAgICAgICAgICAgICA6
PSBAZGVidWdACisKKyMgVG9vbHMgcGF0aAorQklTT04gICAgICAgICAgICAgICA6PSBAQklTT05A
CitGTEVYICAgICAgICAgICAgICAgIDo9IEBGTEVYQAorUFlUSE9OICAgICAgICAgICAgICA6PSBA
UFlUSE9OQAorUFlUSE9OX1BBVEggICAgICAgICA6PSBAUFlUSE9OUEFUSEAKK1BFUkwgICAgICAg
ICAgICAgICAgOj0gQFBFUkxACitCUkNUTCAgICAgICAgICAgICAgIDo9IEBCUkNUTEAKK0lQICAg
ICAgICAgICAgICAgICAgOj0gQElQQAorQ1VSTF9DT05GSUcgICAgICAgICA6PSBAQ1VSTEAKK1hN
TDJfQ09ORklHICAgICAgICAgOj0gQFhNTEAKK0JBU0ggICAgICAgICAgICAgICAgOj0gQEJBU0hA
CitYR0VUVFRFWFQgICAgICAgICAgIDo9IEBYR0VUVEVYVEAKKworIyBFeHRyYSBmb2xkZXIgZm9y
IGxpYnMvaW5jbHVkZXMKK1BSRVBFTkRfSU5DTFVERVMgICAgOj0gQFBSRVBFTkRfSU5DTFVERVNA
CitQUkVQRU5EX0xJQiAgICAgICAgIDo9IEBQUkVQRU5EX0xJQkAKK0FQUEVORF9JTkNMVURFUyAg
ICAgOj0gQEFQUEVORF9JTkNMVURFU0AKK0FQUEVORF9MSUIgICAgICAgICAgOj0gQEFQUEVORF9M
SUJACisKKyMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4K
K1hTTV9FTkFCTEUgICAgICAgICAgOj0gQHhzbUAKK0ZMQVNLX0VOQUJMRSAgICAgICAgOj0gQHhz
bUAKKworIyBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBw
cm90b2NvbD8KKyMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hl
biBpdCB3b3JrcyBhdCBhbGwgKGZpcmV3YWxscworIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0
IHRoZSBkZWZhdWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKKyMgZmFp
bCBvciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQu
CitHSVRfSFRUUCAgICAgICAgICAgIDo9IEBnaXRodHRwQAorCisjIE9wdGlvbmFsIGNvbXBvbmVu
dHMKK1hFTlNUQVRfWEVOVE9QICAgICAgOj0gQG1vbml0b3JzQAorVlRQTV9UT09MUyAgICAgICAg
ICA6PSBAdnRwbUAKK0xJQlhFTkFQSV9CSU5ESU5HUyAgOj0gQHhhcGlACitQWVRIT05fVE9PTFMg
ICAgICAgIDo9IEBweXRob250b29sc0AKK09DQU1MX1RPT0xTICAgICAgICAgOj0gQG9jYW1sdG9v
bHNACitDT05GSUdfTUlOSVRFUk0gICAgIDo9IEBtaW5pdGVybUAKK0NPTkZJR19MT01PVU5UICAg
ICAgOj0gQGxvbW91bnRACisKKyNTeXN0ZW0gb3B0aW9ucworQ09ORklHX1NZU1RFTV9MSUJBSU86
PSBAc3lzdGVtX2Fpb0AKK0NPTkZJR19MSUJJQ09OViAgICAgOj0gQGxpYmljb252QAorQ09ORklH
X0dDUllQVCAgICAgICA6PSBAbGliZ2NyeXB0QAorQ09ORklHX0VYVDJGUyAgICAgICA6PSBAbGli
ZXh0MmZzQApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvTWFrZWZp
bGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyBiL3Rvb2xzL01ha2VmaWxlCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtNiw3
ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlvCiBlbmRpZgogCiBTVUJESVJTLXkgOj0K
LVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9IGluY2x1ZGUKIFNVQkRJUlMteSArPSBs
aWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2ICs3OCw4IEBAIGNsZWFuOiBzdWJkaXJz
LWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNsZWFuCiAJcm0gLXJmIHFlbXUteGVuLXRy
YWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtb3RlCiAJcm0gLXJmIHFl
bXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJcm0gLXJmIC4uL2NvbmZpZy9Ub29scy5t
ayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAorCQljb25maWcuY2FjaGUgYXV0
b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJTEVfQVJDSCksJChYRU5fVEFSR0VUX0FS
Q0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0tY3B1PSQoWEVOX1RBUkdFVF9BUkNIKSBc
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9SdWxlcy5tawotLS0g
YS90b29scy9SdWxlcy5tawlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvdG9v
bHMvUnVsZXMubWsJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC00LDYgKzQsNyBA
QAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5taworaW5jbHVkZSAkKFhFTl9S
T09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5TVEFMTCkKIElO
U1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1pbnN0YWxsCkBAIC04MCw4ICs4MSw2IEBA
IGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2MtdmVyLWNoZWMKICAgICAgICAgICAgICAg
ICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3QgZ2NjLTMuNCIpCiAkKGV2YWwgJChjaGVj
ay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwgd2hpY2ggJChQWVRIT04pKQotUFlUSE9O
X1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxMX1BZVEhPTl9QUk9HID0gXAogCSQoWEVO
X1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAgIiQoUFlUSE9OX1BBVEgpIiAkKElOU1RB
TExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1YmRpci1hbGwtJSBzdWJkaXItY2xlYW4t
JSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVhbi0lOiAucGhvbnkKIAkkKE1BS0UpIC1D
ICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9Ub29scy5tazoKKwlAZWNobyAiWW91IGhh
dmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWlsZGluZyBvciBpbnN0YWxsaW5nIHRoZSB0
b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29s
cy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9NYWtl
ZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvYmxrdGFwL2Ry
aXZlcnMvTWFrZWZpbGUJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0xMyw3ICsx
Myw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKQogQ0ZMQUdTICAgKz0gLUkg
JChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05VX1NPVVJDRQogCi1pZmVxICgkKHNoZWxs
IC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lmZXEgKCRDT05GSUdfR0NSWVBULHkpCiBD
RkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIgOj0gLWxnY3J5cHQKIGVsc2UKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNr
X2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAotCi1jYXQgPiAuZ2NyeXB0LmMg
PDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQgbWFpbih2b2lkKSB7IHJldHVybiAwOyB9
Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0LmMgLWxnY3J5cHQgMj4vZGV2L251bGwg
OyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNobyAibm8iCi1maQotCi1ybSAtZiAuZ2Ny
eXB0KgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svTWFr
ZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uCi1pbmNsdWRlICQoWEVOX1JP
T1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRoZSBuZWNlc3NhcnkgZW52aXJvbm1lbnQg
dmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQWVRIT04KLWV4cG9ydCBMSUJYRU5BUElf
QklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwotZXhwb3J0IENIRUNLX0xJQgotZXhwb3J0
IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTogYWxsIGluc3RhbGwKLWFsbCBpbnN0YWxs
OiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgYnVpbGRpbmcg
b24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1idWlsZDoKLQkuL2NoayBidWlsZAotCi0j
IENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5zdGFsbGluZyBvbi4KLS5QSE9OWTogY2hl
Y2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2NoayBpbnN0YWxsCi0KLS5QSE9OWTogY2xl
YW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDll
OTNhYSB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9vbHMvY2hlY2svUkVBRE1FCU1vbiBGZWIg
MjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVja3MgZm9yIHRoZSBzdWl0YWJpbGl0eSBv
ZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLgotVG8gY2hlY2sgZm9yIGJ1aWxk
IHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGJ1aWxkCi0KLVRvIGNoZWNrIGZvciBp
bnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGluc3RhbGwKLQotVGhlIGNo
ayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMgZGlyZWN0b3J5IGFuZCBwcmludAotdGhl
IG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3RoaW5nIGlmIGNoZWNrcyBzdWNjZWVkLgot
VGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1Y2Nlc3MgYW5kIDEgb24gZmFpbHVyZS4K
LQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxlIGZpbGVzIGluIHRoaXMgZGlyZWN0b3J5
IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18nLiBGaWxlcyBjb250YWluaW5nIENIRUNL
LUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hlY2ssIGFuZCBmaWxlcyBjb250YWluaW5n
IENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBpbnN0YWxsIGNoZWNrLgotCi1EZXRhaWxl
ZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBpcyBpbiAuY2hrYnVpbGQgZm9yIGJ1aWxk
Ci1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmls
ZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svY2hlY2tf
YnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwJTW9uIEZlYiAyMCAxODozNDoxNCAy
MDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBA
IC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5z
aAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBi
cmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwgYnJjdGwgOzsKLSopCi0JZmFpbCAidW5r
bm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRv
b2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfY3J5cHRv
X2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFu
IDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAotIyEvYmluL3NoCi0jIENI
RUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1G
cmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7OwotZXNhYwotCi1oYXNfbGliIGxpYmNy
eXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0by5zbyIKZGlmZiAtciBjYTgwZWNhOWNm
YTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX2N1cmwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfY3VybAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmlu
L3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsg
IiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0aGVuCi0JZWNobyAtbiAidW51c2VkLCAi
Ci0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJsLWNvbmZpZwotY3VybF9saWJzPWBjdXJs
LWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29uZmlnIC0tbGlicyBmYWlsZWQiCi10ZXN0
X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxpYnJhcmllcyBmb3IgY3VybCBh
cmUgbWlzc2luZyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2No
ZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfaXByb3V0ZQlNb24gRmVi
IDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwK
LQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBBVEgKLQotY2FzZSAkT1MgaW4KLU9wZW5C
U0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgaWZjb25maWcgOzsKLUxpbnV4KQotCWhh
c19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2FjCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2
ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNz
LnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7IHRoZW4KLSAg
ICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGliYWlvLmggOyB0aGVuCi0gICAgZmFpbCAi
Y2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFsbCBsaWJhaW8gZGV2ZWwgcGFja2FnZSBv
ciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZpCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGRkODdiMDllOTNhYSB0b29scy9jaGVjay9jaGVja19saWJhaW9fbGliCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX2xpYmFpb19saWIJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDkgKzAsMCBAQAot
IyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0K
LWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7IHRoZW4KLSAgICBleGl0
IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIGxpYmFpbyIKZGlm
ZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX29wZW5z
c2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAlNb24gRmViIDIw
IDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAu
L2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9tZDUuaCB8fCBmYWlsICJtaXNzaW5nIG9w
ZW5zc2wgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xz
L2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9jaGVjay9jaGVja19weXRob24JTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBD
SEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhl
bgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhPTn0gLWMgJwotaW1wb3J0IHN5cwotc3lz
LmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Igc3lzLnZlcnNpb25faW5mb1sxXSA8IDMp
Ci0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24gPj0gMi4zIgpkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX2RldmVsCi0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1p
ZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotaGFzX29yX2Zh
aWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgb3MucGF0aCwgc3lzCi1mb3Ig
cCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZpbGUi
KToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0nIHx8IGZhaWwgImNhbid0IGZpbmQgcHl0
aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9v
bHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90b29scy9jaGVjay9jaGVja19weXRob25f
eG1sCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4K
LSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0ke1BZVEhPTn0g
LWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rldi9udWxsIHx8IFwKLWZhaWwgImNhbid0
IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDll
OTNhYSB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3VkZXYJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1J
TlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJl
ZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7Ci1MaW51eCkKLQloYXMgL3NiaW4vdWRl
dmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZhZG0gaW5mbyAtViB8IGF3ayAne3ByaW50
ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhhc19vcl9mYWlsIHVkZXZpbmZvICYmIFwK
LQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbICIkdWRldnZl
ciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQloYXMgaG90cGx1ZyB8fCBcCi0JCWZhaWwg
InVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVyIgotCTs7Ci0q
KQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
ZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfdXVpZF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNyArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgdXVp
ZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmggfHwgZmFpbCAibWlzc2luZyB1dWlkIGhl
YWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5
ZTkzYWEgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3gxMV9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0jIS9iaW4vc2gK
LSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgWDExL2tleXN5bWRl
Zi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8
fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAot
d2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
ZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0Ci0tLSBhL3Rvb2xzL2NoZWNr
L2NoZWNrX3hnZXR0ZXh0CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw2ICswLDAgQEAKLSMhL2Jp
bi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX29yX2ZhaWwgeGdldHRl
eHQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NoZWNrL2NoZWNr
X3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1sMglNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQSV9CSU5ESU5HUyIgPSAieSIgXQotdGhl
bgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4aXQgMAotZmkKLQotaGFzX29yX2ZhaWwg
eG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25maWcgLS1saWJzYCB8fCBmYWlsICJ4bWwy
LWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICR4bWwyX2xpYnMgfHwgZmFpbCAiZGVw
ZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1pc3NpbmciCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9jaGVjay9jaGVja195YWpsX2RldmVsCi0tLSBhL3Rv
b2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDggKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVh
ZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95YWpsX3BhcnNl
LmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8fCBmYWlsICJjYW4ndCBmaW5kIHlhamwv
eWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIGxpYnlh
amwuc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9jaGVjay9j
aGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJfZGV2ZWwJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBmYWlsICJjYW4ndCBmaW5kIHps
aWIgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2No
ZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCU1vbiBG
ZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0
QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJ6LnNvIHx8IGZh
aWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2Fh
IHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJTW9uIEZlYiAyMCAxODozNDox
NCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3VzYWdlICgpCi17Ci0gICAgZWNo
byAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFsbHxjbGVhbl0iCi0gICAgZWNo
bwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4gYnVpbGQgb3IgaW5zdGFsbC4i
Ci0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90LiIKLSAgICBlY2hvCi0gICAg
ZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5lcmF0ZWQgZmlsZXMuIgotICAg
IGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2JpbgotT1M9YHVuYW1lIC1zYAot
ZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIgXTsgdGhlbgotCWV4aXQgMAot
ZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBjaGVjaz0iQ0hFQ0stQlVJTEQi
Ci0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hlY2s9IkNIRUNLLUlOU1RBTEwi
Ci0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQgMAotICAgICAgICA7OwotICAg
ICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVzYWMKLQotZmFpbGVkPTAKLQot
ZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBjaGVja18qIDsgZG8KLSAgICBj
YXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29udGludWUKLSAgICAgICAgICAg
IDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVzYWMKLSAgICBpZiAhIFsgLXgg
JGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAgIGlmICEgZ3JlcCAtRnEg
IiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0gICAgZmkKLSAgICBlY2hvIC1u
ICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRoZW4KLSAgICAgICAgZWNobyBP
SwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQotZG9uZQotCi1leGl0ICR7ZmFp
bGVkfQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY2hlY2svZnVu
Y3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGljaCwgZXhjZXB0IGl0IGhhbmRs
ZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAteiAiJENST1NTX0NPTVBJTEUi
IF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVybiAkPwotCWZpCi0KLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBpbiAkUEFUSDsgZG8KLQkJaWYg
WyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0JCQllY2hvICIkQ1JPU1NfU1lT
X1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUKLQlyZXR1cm4gMQotCSkKLX0K
LQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVsbCB8fCBmYWlsICJjYW4ndCBm
aW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5c19yb290IHx8IHJldHVybiAx
Ci0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JP
T1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAwCi0JCWZpCi0JCWZvciBwYXRo
IGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAiJENST1NTX1NZU19ST09UJHtw
YXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQotCQlkb25lCi0JCTs7Ci0JZXNh
YwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVja19zeXNfcm9vdCB8fCByZXR1
cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBlbnZp
cm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAjIGZvciBsZGNvbmZpZwotCUxJ
QlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhpcyByZWxhdGl2ZWx5IGNvbW1v
biBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0Ci0JIyBsZGNvbmZpZyBoYXNu
J3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3JrLgotCWlmIFsgIiRPUyIgPSBM
aW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNvLmNhY2hlIiBdOyB0aGVuCi0J
ICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JPU1NfU1lTX1JPT1RcIiB0byBn
ZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91Z2g7IGxkY29uZmlnIHRlc3Qg
YmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJMaW51eCIgXTsgdGhlbgot
CQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JPU1NfU1lTX1JPT1QifSB8IGdy
ZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIke09TfSIgPSAiTmV0QlNEIiBd
OyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/
Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkgewotCSMgc3Vic2hlbGwgdG8g
dHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1wZmlsZQotCXRyYXAgJ3JtIC1m
ICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1gbWt0ZW1wYCB8fCByZXR1cm4g
MQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+JjEKLQlyZXR1cm4gJD8KLQkp
Ci19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5IGFib3ZlCi1jaGVja19zeXNf
cm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiByZXR1cm4gMAotCWlmIFsgLXog
IiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVhc2Ugc2V0IENST1NTX1NZU19S
T09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlmaQotCWlmIFsgISAtZCAiJENS
T1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1yb290IGZvdW5kIGF0ICRDUk9T
U19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJuaW5nKCkgewotCWVjaG8KLQll
Y2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAkKn0iCi19Ci0KLWZhaWwoKSB7
Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLQll
eGl0IDEKLX0KZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2NvbmZp
Zy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL2NvbmZpZy5oLmluCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMCww
ICsxLDE2IEBACisvKgorICogQ29weXJpZ2h0IChDKSAyMDEyCisgKgorICogVGhpcyBwcm9ncmFt
IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkK
KyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBM
aWNlbnNlIGFzIHB1Ymxpc2hlZAorICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsg
dmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lhbAorICogZXhjZXB0aW9uIG9uIGxpbmtp
bmcgZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlz
dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRI
T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisg
KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT
ZWUgdGhlCisgKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0
YWlscy4KKyAqLworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92
ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05f
SApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvY29uZmlndXJlLmFj
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L2NvbmZpZ3VyZS5hYwlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwx
OTMgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0q
LSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBhdXRvY29uZiB0byBwcm9k
dWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsyLjY3XSkKK0FDX0lOSVQoW1hl
biBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVyc2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVd
KSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb21dKQorQUNfQ09ORklHX1NSQ0RJ
UihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklMRVMoWy4uL2NvbmZpZy9Ub29scy5ta10p
CitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQorQUNfUFJFRklYX0RFRkFVTFQoWy91c3Jd
KQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENoZWNrIGlmIENGTEFHUywgTERGTEFHUywg
TElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCisKK0FTX0lG
KFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElCUyRDUFBGTEFHUyRDUFAiXSwgWworICAg
IEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxB
R1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBS
RVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVu
IHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVNX0VYVEVOU0lPTlMKK0FDX0NBTk9OSUNB
TF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200X2luY2x1ZGUoW200L2VuYWJsZV9mZWF0
dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVfZmVhdHVyZS5tNF0pCittNF9pbmNsdWRl
KFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX3htbC5tNF0pCitt
NF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25f
ZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5tNF0pCittNF9pbmNsdWRlKFttNC9vY2Ft
bC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xpYi5tNF0pCittNF9pbmNsdWRlKFttNC9z
ZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVkZShbbTQvdXVpZC5tNF0pCittNF9pbmNs
dWRlKFttNC9wa2cubTRdKQorCisjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKK0FYX0FSR19FTkFC
TEVfQU5EX0VYUE9SVChbeHNtXSwKKyAgICBbRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5
IGRlZmF1bHQsIEZsYXNrKV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW2dpdGh0dHBdLCBb
RG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUF0pCitBWF9BUkdfRElTQUJMRV9BTkRf
RVhQT1JUKFttb25pdG9yc10sCisgICAgW0Rpc2FibGUgeGVuc3RhdCBhbmQgeGVudG9wIG1vbml0
b3JpbmcgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt2dHBtXSwgW0VuYWJsZSBW
aXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9S
VChbeGFwaV0sIFtFbmFibGUgWGVuIEFQSSBCaW5kaW5nc10pCitBWF9BUkdfRElTQUJMRV9BTkRf
RVhQT1JUKFtweXRob250b29sc10sIFtEaXNhYmxlIFB5dGhvbiB0b29sc10pCitBWF9BUkdfRElT
QUJMRV9BTkRfRVhQT1JUKFtvY2FtbHRvb2xzXSwgW0Rpc2FibGUgT2NhbWwgdG9vbHNdKQorQVhf
QVJHX0VOQUJMRV9BTkRfRVhQT1JUKFttaW5pdGVybV0sIFtFbmFibGUgbWluaXRlcm1dKQorQVhf
QVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtsb21vdW50XSwgW0VuYWJsZSBsb21vdW50XSkKK0FYX0FS
R19ESVNBQkxFX0FORF9FWFBPUlQoW2RlYnVnXSwgW0Rpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVu
IGFuZCB0b29sc10pCisKK0FDX0FSR19WQVIoW1BSRVBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0
IG9mIGluY2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQor
QUNfQVJHX1ZBUihbUFJFUEVORF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0
byBwcmVwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9J
TkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIGFwcGVuZCB0byBDRkxB
R1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9MSUJdLAorICAgIFtMaXN0IG9m
IGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCldKQorCitB
WF9TRVRfRkxBR1MKKworQUNfQVJHX1ZBUihbUFlUSE9OXSwgW1BhdGggdG8gdGhlIFB5dGhvbiBw
YXJzZXJdKQorQUNfQVJHX1ZBUihbUEVSTF0sIFtQYXRoIHRvIFBlcmwgcGFyc2VyXSkKK0FDX0FS
R19WQVIoW0JSQ1RMXSwgW1BhdGggdG8gYnJjdGwgdG9vbF0pCitBQ19BUkdfVkFSKFtJUF0sIFtQ
YXRoIHRvIGlwIHRvb2xdKQorQUNfQVJHX1ZBUihbQklTT05dLCBbUGF0aCB0byBCaXNvbiBwYXJz
ZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0ZMRVhdLCBbUGF0aCB0byBGbGV4IGxleGljYWwg
YW5hbHlzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0NVUkxdLCBbUGF0aCB0byBjdXJsLWNv
bmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW1hNTF0sIFtQYXRoIHRvIHhtbDItY29uZmlnIHRvb2xd
KQorQUNfQVJHX1ZBUihbQkFTSF0sIFtQYXRoIHRvIGJhc2ggc2hlbGxdKQorQUNfQVJHX1ZBUihb
WEdFVFRFWFRdLCBbUGF0aCB0byB4Z2V0dHRleHQgdG9vbF0pCisKKyMgQ2hlY2tzIGZvciBwcm9n
cmFtcy4KK0FDX1BST0dfU0VECitBQ19QUk9HX0NDCitBQ19QUk9HX0xOX1MKK0FDX1BST0dfTUFL
RV9TRVQKK0FDX1BST0dfSU5TVEFMTAorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVy
bF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQlJDVExdLCBbYnJjdGxdKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0lQXSwgW2lwXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCSVNPTl0sIFtiaXNv
bl0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbRkxFWF0sIFtmbGV4XSkKK0FTX0lGKFt0ZXN0ICJ4
JHhhcGkiID0gInh5Il0sIFsKKyAgICBBWF9QQVRIX1BST0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJs
LWNvbmZpZ10pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10p
CitdKQorQVNfSUYoW3Rlc3QgIngkb2NhbWx0b29scyIgPSAieHkiXSwgWworICAgIEFDX1BST0df
T0NBTUwKKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMiID0gInhubyJdLCBbCisgICAgICAgIEFT
X0lGKFt0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVzIl0sIFsKKyAgICAgICAgICAg
IEFDX01TR19FUlJPUihbT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9j
YW1sXSldKQorICAgICAgICBvY2FtbHRvb2xzPSJuIgorICAgIF0pCitdKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihbdGVzdCAieCRweXRob250b29scyIgPSAi
eHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIl0sIFsKKyAg
ICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhP
TlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJdLCBbUFlUSE9OPSJweXRob24iXSwKKyAg
ICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRl
IHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BZVEhPTlBBVEhdLCBbJFBZVEhP
Tl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04oWzJdLCBbM10pCisgICAgQVhfQ0hFQ0tf
UFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMKCkKK10pCitBWF9QQVRIX1BS
T0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRdKQorQVhfQ0hFQ0tfVURFVihbNTldKQor
QVhfQ0hFQ0tfVVVJRAorUEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwgZ2xpYi0yLjApCisKKyMgQ2hl
Y2sgbGlicmFyeSBwYXRoCitBWF9ERUZBVUxUX0xJQgorCisjIENoZWNrcyBmb3IgbGlicmFyaWVz
LgorQUNfQ0hFQ0tfTElCKFthaW9dLCBbaW9fc2V0dXBdLCBbc3lzdGVtX2Fpbz0ieSJdLCBbc3lz
dGVtX2Fpbz0ibiJdKQorQUNfU1VCU1Qoc3lzdGVtX2FpbykKK0FDX0NIRUNLX0xJQihbY3J5cHRv
XSwgW01ENV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJjcnlwdG9dKV0p
CitBQ19DSEVDS19MSUIoW2V4dDJmc10sIFtleHQyZnNfb3BlbjJdLCBbbGliZXh0MmZzPSJ5Il0s
IFtsaWJleHQyZnM9Im4iXSkKK0FDX1NVQlNUKGxpYmV4dDJmcykKK0FDX0NIRUNLX0xJQihbZ2Ny
eXB0XSwgW2djcnlfbWRfaGFzaF9idWZmZXJdLCBbbGliZ2NyeXB0PSJ5Il0sIFtsaWJnY3J5cHQ9
Im4iXSkKK0FDX1NVQlNUKGxpYmdjcnlwdCkKK0FDX0NIRUNLX0xJQihbcHRocmVhZF0sIFtwdGhy
ZWFkX2NyZWF0ZV0sIFtdICwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJw
dGhyZWFkXSldKQorQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1lXSkKK0FDX0NIRUNL
X0xJQihbdXVpZF0sIFt1dWlkX2NsZWFyXSwgW10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQg
bm90IGZpbmQgbGlidXVpZF0pXSkKK0FDX0NIRUNLX0xJQihbeWFqbF0sIFt5YWpsX2FsbG9jXSwg
W10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgeWFqbF0pXSkKK0FDX0NIRUNL
X0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmlu
ZCB6bGliXSldKQorQUNfQ0hFQ0tfTElCKFtpY29udl0sIFtsaWJpY29udl9vcGVuXSwgW2xpYmlj
b252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQorQUNfU1VCU1QobGliaWNvbnYpCisKKyMgQXV0b3Nj
YW4gc3R1ZmYgKGV4Y2VwdCBmb3IgeWFqbC95YWpsX3ZlcnNpb24uaCBjaGVjaykKKyMgQ2hlY2tz
IGZvciBoZWFkZXIgZmlsZXMuCitBQ19GVU5DX0FMTE9DQQorQUNfQ0hFQ0tfSEVBREVSUyhbIFwK
KyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGludHR5cGVzLmggbGliaW50bC5o
IGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAgICAgICBuZXRkYi5oIG5ldGluZXQvaW4u
aCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCisgICAgICAgICAgICAgICAg
c3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21vdW50Lmggc3lzL3BhcmFtLmgg
XAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3RhdHZmcy5oIHN5cy90aW1lLmgg
c3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAgICAgICB1bmlzdGQuaCB5YWpsL3lhamxf
dmVyc2lvbi5oIFwKKyAgICAgICAgICAgICAgICBdKQorCisjIENoZWNrcyBmb3IgdHlwZWRlZnMs
IHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCitBQ19IRUFERVJfU1RE
Qk9PTAorQUNfVFlQRV9VSURfVAorQUNfQ19JTkxJTkUKK0FDX1RZUEVfSU5UMTZfVAorQUNfVFlQ
RV9JTlQzMl9UCitBQ19UWVBFX0lOVDY0X1QKK0FDX1RZUEVfSU5UOF9UCitBQ19UWVBFX01PREVf
VAorQUNfVFlQRV9PRkZfVAorQUNfVFlQRV9QSURfVAorQUNfQ19SRVNUUklDVAorQUNfVFlQRV9T
SVpFX1QKK0FDX1RZUEVfU1NJWkVfVAorQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3Rf
Ymxrc2l6ZV0pCitBQ19TVFJVQ1RfU1RfQkxPQ0tTCitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qg
c3RhdC5zdF9yZGV2XSkKK0FDX1RZUEVfVUlOVDE2X1QKK0FDX1RZUEVfVUlOVDMyX1QKK0FDX1RZ
UEVfVUlOVDY0X1QKK0FDX1RZUEVfVUlOVDhfVAorQUNfQ0hFQ0tfVFlQRVMoW3B0cmRpZmZfdF0p
CisKKyMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KK0FDX0ZVTkNfRVJST1JfQVRfTElO
RQorQUNfRlVOQ19GT1JLCitBQ19GVU5DX0ZTRUVLTworQUNfRlVOQ19MU1RBVF9GT0xMT1dTX1NM
QVNIRURfU1lNTElOSworQUNfSEVBREVSX01BSk9SCitBQ19GVU5DX01BTExPQworQUNfRlVOQ19N
S1RJTUUKK0FDX0ZVTkNfTU1BUAorQUNfRlVOQ19SRUFMTE9DCitBQ19GVU5DX1NUUk5MRU4KK0FD
X0ZVTkNfU1RSVE9ECitBQ19DSEVDS19GVU5DUyhbIFwKKyAgICAgICAgICAgICAgICBhbGFybSBh
dGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3luYyBmdHJ1bmNhdGUgXAorICAg
ICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhvc3RuYW1lIGdldHBhZ2VzaXpl
IGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAgaW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0
aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKKyAgICAgICAgICAgICAgICBta2Zp
Zm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2VsZWN0IHNldGVudiBc
CisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVw
IHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAgICAgIHN0cnBicmsgc3RycmNociBzdHJz
cG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0IFwKKyAgICAgICAgICAgICAg
ICB1bmFtZSBcCisgICAgICAgICAgICAgICAgXSkKKworQUNfT1VUUFVUKCkKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxl
Ci0tLSBhL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgYi90b29scy9kZWJ1Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQlNb24g
RmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTIxLDcgKzIxLDYgQEAgeGdfYWxsLmE6ICQo
WEdfT0JKUykgTWFrZWZpbGUgJChYR19IRFJTKQogIwkkKENDKSAtbTMyIC1jIC1vICRAICReCiAK
IHhlbi1oZWFkZXJzOgotCSQoTUFLRSkgLUMgLi4vLi4vLi4vY2hlY2sgCiAJJChNQUtFKSAtQyAu
Li8uLi8uLi9pbmNsdWRlCiAKICMgeGdfbWFpbi5vOiB4Z19tYWluLmMgTWFrZWZpbGUgJChYR19I
RFJTKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvaW5zdGFsbC5z
aAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29s
cy9pbnN0YWxsLnNoCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEg
QEAKKy4uL2luc3RhbGwuc2gKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIgY2E4
MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9saWJmc2ltYWdlL01ha2VmaWxlCi0tLSBh
L3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEy
ICswMTAwCkBAIC0zLDcgKzMsMTEgQEAgaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5t
awogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNlcmZzIGlzbzk2NjAgZmF0IHpmcwogU1VC
RElSUy0kKENPTkZJR19YODYpICs9IHhmcwotU1VCRElSUy15ICs9ICQoc2hlbGwgZW52IENDPSIk
KENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgkKENPTkZJR19FWFQyRlMpLCB5KQorICAg
IFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisgICAgU1VCRElSUy15ICs9IGV4dDJmcwor
ZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFsbAogYWxsIGNsZWFuIGluc3RhbGw6ICU6
IHN1YmRpcnMtJQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbGli
ZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJl
eHQyZnMJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIxICswLDAgQEAKLSMhL2Jpbi9zaAotCi1j
YXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8ZXh0MmZzL2V4dDJmcy5oPgotCi1pbnQg
bWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9GCi0KLSR7Q0MtZ2NjfSAtbyBleHQyLXRl
c3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVsbCAyPiYxCi1pZiBbICQ/ID0gMCBdOyB0
aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNobyBleHQyZnMKLWZpCi0KLXJtIC1mIGV4
dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4
N2IwOWU5M2FhIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQotLS0gYS90b29scy9saWJ4ZW4vTWFrZWZp
bGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhlbi9NYWtl
ZmlsZQlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTIyLDEyICsyMiwxMiBAQCBN
QUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtSWluY2x1ZGUgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwyLWNvbmZpZyAtLWNmbGFncykgXAotICAg
ICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxhZ3MpIFwKKyAgICAgICAgICAkKHNoZWxs
ICQoWE1MMl9DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAkKENVUkxfQ09O
RklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElDCiAKLUxERkxBR1MgKz0gJChzaGVsbCB4
bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAgJChzaGVsbCBjdXJsLWNvbmZpZyAtLWxp
YnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyX0NPTkZJRykgLS1saWJzKSBcCisgICAgICAg
ICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1saWJzKQogCiBMSUJYRU5BUElfSERSUyA9ICQo
d2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5jbHVkZS94ZW4vYXBpL3hlbl9hbGwuaAog
TElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywgJS5vLCAkKHdpbGRjYXJkIHNyYy8qLmMp
KQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbGlieGwvTWFrZWZp
bGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiAr
MDEwMApAQCAtMTksMTAgKzE5LDYgQEAgaWZlcSAoJChDT05GSUdfTGludXgpLHkpCiBMSUJVVUlE
X0xJQlMgKz0gLWx1dWlkCiBlbmRpZgogCi1pZmVxICgkKENPTkZJR19ZQUpMX1ZFUlNJT04pLHkp
Ci1DRkxBR1MgKz0gLURIQVZFX1lBSkxfVkVSU0lPTgotZW5kaWYKLQogTElCWExfTElCUyA9CiBM
SUJYTF9MSUJTID0gJChMRExJQlNfbGlieGVuY3RybCkgJChMRExJQlNfbGlieGVuZ3Vlc3QpICQo
TERMSUJTX2xpYnhlbnN0b3JlKSAkKExETElCU19saWJibGt0YXBjdGwpICQoVVRJTF9MSUJTKSAk
KExJQlVVSURfTElCUykKIApAQCAtNTYsNyArNTIsNyBAQCBMSUJYTF9PQkpTID0gZmxleGFycmF5
Lm8gbGlieGwubyBsaWJ4bF9jCiAJCQlsaWJ4bF9xbXAubyBsaWJ4bF9ldmVudC5vICQoTElCWExf
T0JKUy15KQogTElCWExfT0JKUyArPSBfbGlieGxfdHlwZXMubyBsaWJ4bF9mbGFzay5vIF9saWJ4
bF90eXBlc19pbnRlcm5hbC5vCiAKLSQoTElCWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19s
aWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxBR1NfbGlieGVuc3RvcmUpICQo
Q0ZMQUdTX2xpYmJsa3RhcGN0bCkKKyQoTElCWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19s
aWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxBR1NfbGlieGVuc3RvcmUpICQo
Q0ZMQUdTX2xpYmJsa3RhcGN0bCkgLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvY29uZmlnLmgK
IAogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhsdV9jZmdfbC5oIF9saWJ4bF9saXN0LmgK
IEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVfY2ZnX2wuYwpAQCAtNjksNiArNjUsNyBA
QCBDTElFTlRTID0geGwgdGVzdGlkbAogWExfT0JKUyA9IHhsLm8geGxfY21kaW1wbC5vIHhsX2Nt
ZHRhYmxlLm8geGxfc3hwLm8KICQoWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5j
dHJsKSAjIEZvciB4ZW50b29sbG9nLmgKICQoWExfT0JKUyk6IENGTEFHUyArPSAkKENGTEFHU19s
aWJ4ZW5saWdodCkKKyQoWExfT0JKUyk6IENGTEFHUyArPSAtaW5jbHVkZSAkKFhFTl9ST09UKS90
b29scy9jb25maWcuaCAjIGxpYnhsX2pzb24uaCBuZWVkcyBpdC4KIAogdGVzdGlkbC5vOiBDRkxB
R1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxBR1NfbGlieGVubGlnaHQpCiB0ZXN0aWRs
LmM6IGxpYnhsX3R5cGVzLmlkbCBnZW50ZXN0LnB5IGxpYnhsLmggJChBVVRPSU5DUykKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL2xpYnhsL2xpYnhsX2pzb24uaAot
LS0gYS90b29scy9saWJ4bC9saWJ4bF9qc29uLmgJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24uaAlNb24gRmViIDIwIDIzOjE4OjAxIDIw
MTIgKzAxMDAKQEAgLTE4LDcgKzE4LDcgQEAKICNpbmNsdWRlIDx5YWpsL3lhamxfZ2VuLmg+CiAj
aW5jbHVkZSA8eWFqbC95YWpsX3BhcnNlLmg+CiAKLSNpZmRlZiBIQVZFX1lBSkxfVkVSU0lPTgor
I2lmZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAogIyAgaW5jbHVkZSA8eWFqbC95YWpsX3Zl
cnNpb24uaD4KICNlbmRpZgogCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0
b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0X2xpYi5tNAlNb24gRmViIDIwIDIzOjE4
OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitBQ19ERUZVTihbQVhfREVGQVVMVF9MSUJd
LAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0Il0sIFsKKyAgICBMSUJfUEFUSD0ibGli
NjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkKK0FDX1NVQlNUKExJQl9QQVRIKV0pCisK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL200L2Rpc2FibGVfZmVh
dHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JU
XSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0k
MV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAg
YXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInh5ZXMiXSwgWworICAgIGF4
X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4X2N2XyQxPSJ5Igor
XSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
ZGQ4N2IwOWU5M2FhIHRvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2VuYWJsZV9mZWF0dXJl
Lm00CU1vbiBGZWIgMjAgMjM6MTg6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEzIEBACitBQ19E
RUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisg
ICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4
JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVzdCAieCRl
bmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAteiAkYXhf
Y3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJTVCgk
MSldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbTQvb2NhbWwu
bTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9v
bHMvbTQvb2NhbWwubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEs
MjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAorZG5sIGZyb20gaHR0cDovL2Zv
cmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFJpY2hh
cmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgU3RlZmFubyBaYWNjaGly
b2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBPbGl2aWVyIEFuZHJpZXUKK2RubCBDb3B5
cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3BoZSBGaWxsacOidHJlCitkbmwgQ29weXJp
Z2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8KK2RubAorZG5sIEZvciBkb2N1bWVudGF0
aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFuIHBhZ2UuCisKK0FDX0RFRlVOKFtBQ19Q
Uk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIEFDX0NIRUNLX1RP
T0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8i
OyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZl
cnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCB2ZXJzaW9u
IGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0Cisg
ICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgorICAgICAgICBPQ0FNTExJQj1gJE9D
QU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAnICcg
LWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0dfUkVTVUxUKFtPQ0FNTExJQiBwcmV2aW91
c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBmaQorICAgICBBQ19NU0dfUkVTVUxUKFtP
Q2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkKKworICAgICBBQ19TVUJTVChbT0NBTUxW
RVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElCXSkKKworICAgICAjIGNoZWNraW5nIGZv
ciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTE9QVF0sW29jYW1sb3B0XSxbbm9d
KQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsg
dGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGls
YXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwgc2Vk
IC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJT
SU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNp
b25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC5dKQorCSAgICBPQ0FN
TE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCisKKyAgICAg
QUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAor
ICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRdLFtvY2FtbGMub3B0XSxbbm9dKQorICAg
ICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9D
QU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAK
KwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICBB
Q19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRp
c2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBm
aQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NB
TUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRET1RPUFRdLFtv
Y2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0
aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4q
dmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAi
JE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbiBkaWZm
ZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLl0pCisJICAgZWxzZQorCSAg
ICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZpCisgICAgICAgIGZpCisgICAgIGZp
CisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAgZmkKKworICBBQ19TVUJTVChbT0NBTUxD
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAorICBBQ19DSEVDS19UT09MKFtP
Q0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIEFDX0NI
RUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Ig
b2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LVE9QXSxbb2NhbWxta3RvcF0sW25v
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCisgIEFDX0NIRUNLX1RPT0woW09DQU1M
TUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisg
IEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxkb2NdLFtub10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEJVSUxEXSxbb2NhbWxidWls
ZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxMRVhdLAorW2RubAorICAj
IGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWF0sW29jYW1s
bGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgiICE9ICJubyI7IHRoZW4KKyAgICBBQ19D
SEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1sbGV4Lm9wdF0sW25vXSkKKyAgICBpZiB0
ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRoZW4KKwlPQ0FNTExFWD0kT0NBTUxMRVhE
T1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChbT0NBTUxMRVhdKQorXSkKKworQUNfREVG
VU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxZQUND
XSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChbT0NBTUxZQUNDXSkKK10pCisKKworQUNf
REVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FN
TF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0CisgIEFDX0NIRUNLX1RPT0woW0NBTUxQ
NF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENBTUxQNCIgIT0gIm5vIjsgdGhlbgorICAg
ICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24gKlwo
LipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lP
TiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sY10p
CisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBmaQorICBBQ19TVUJTVChbQ0FNTFA0XSkK
KworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9vbHMKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FN
TFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9dLFtj
YW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPRl0sW2NhbWxwNG9mXSxbbm9d
KQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtjYW1scDRvb2ZdLFtub10pCisgIEFDX0NI
RUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChb
Q0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJd
LFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRSRl0sW2NhbWxwNHJmXSxb
bm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisgIEFDX1NVQlNUKFtDQU1MUDRPXSkKKyAg
QUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9PRl0pCisgIEFDX1NVQlNU
KFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0UFJPRl0pCisgIEFDX1NVQlNUKFtDQU1M
UDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0df
RklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEZJTkRdLFtvY2Ft
bGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJTkRdKQorXSkKKworCitkbmwgVGhhbmtz
IHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlzIG5leHQgYml0IG91dCBmb3IgdXMuCitk
bmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0ggaWYgaXQncyBub3QgZGVmaW5lZCBhbHJl
YWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4KK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FN
TF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX0ZJTkRMSUJdKWRubAorCisgIEFD
X01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIgcGFja2FnZSAkMV0pCisKKyAgdW5zZXQg
Zm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisgIGZvciBwa2cgaW4gJDEgJDIgOyBkbwor
ICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVu
CisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisgICAgICBBU19UUl9TSChbT0NBTUxfUEtH
XyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRvbmUK
KyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm90
IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9bm8KKyAgZmkKKworICBBQ19T
VUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitdKQorCisKK0FDX0RFRlVOKFtBQ19DSEVD
S19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBtb2R1
bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCitvcGVuICQzCitFT0YKKyAgdW5z
ZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRvCisgICAgaWYgJE9DQU1MQyAtYyAtSSAi
JCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4KKyAgICAgIGZvdW5kPXllcworICAgICAg
YnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVzdCAiJGZvdW5kIiA7IHRoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5k
XSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChbJDFdKQorXSkKKworCitkbmwgWFhYIENy
b3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1dPUkRfU0laRV0sCitbZG5s
CisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2Zv
ciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgor
ICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5cy53b3JkX3NpemUpCisgIEVPRgorICBP
Q0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9D
QU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9XT1JEX1NJWkVdKQorXSkKKworQUNf
REVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19Q
Uk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtPQ2FtbCBTeXMub3NfdHlwZV0pCisK
KyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfc3RyaW5nKFN5cy5vc190eXBlKTs7
CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01TR19S
RVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VCU1QoW09DQU1MX09TX1RZUEVdKQorXSkK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL200L3BhdGhfb3JfZmFp
bC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9wYXRoX29yX2ZhaWwubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhfUFJPR19PUl9GQUlMXSwKK1tBQ19QQVRI
X1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3QgeCIkeyQxfSIgPT0geCJubyIgCit0aGVu
CisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCAkMiwgcGxlYXNlIGluc3RhbGwgJDJd
KQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbTQvcGtn
Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL200L3BrZy5tNAlNb24gRmViIDIwIDIzOjE4OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwx
NTcgQEAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQgdXRpbGlzZSBwa2ctY29uZmln
LiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgc2VyaWFsIDEgKHBrZy1jb25maWctMC4y
NCkKKyMgCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVzIFJlbW5hbnQgPHNjb3R0QG5l
dHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisjIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CisjIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9y
CisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisjCisjIFRoaXMgcHJvZ3Jh
bSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQK
KyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50
eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFp
bHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy
aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ
bGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuCisjCisjIEFzIGEg
c3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5
b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250
YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwgeW91
IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0
IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KKworIyBQS0dfUFJPR19QS0df
Q09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KK0FDX0RFRlVOKFtQS0dfUFJPR19QS0dfQ09ORklHXSwKK1ttNF9wYXR0ZXJuX2ZvcmJpZChb
Xl8/UEtHX1tBLVpfXSskXSkKK200X3BhdHRlcm5fYWxsb3coW15QS0dfQ09ORklHKF9QQVRIKT8k
XSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUddLCBbcGF0aCB0byBwa2ctY29uZmlnIHV0aWxpdHld
KQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19QQVRIXSwgW2RpcmVjdG9yaWVzIHRvIGFkZCB0byBw
a2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGhdKQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19MSUJESVJd
LCBbcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBidWlsdC1pbiBzZWFyY2ggcGF0aF0pCisK
K2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05GSUdfc2V0IiAhPSAieHNldCI7IHRoZW4KKwlB
Q19QQVRIX1RPT0woW1BLR19DT05GSUddLCBbcGtnLWNvbmZpZ10pCitmaQoraWYgdGVzdCAtbiAi
JFBLR19DT05GSUciOyB0aGVuCisJX3BrZ19taW5fdmVyc2lvbj1tNF9kZWZhdWx0KFskMV0sIFsw
LjkuMF0pCisJQUNfTVNHX0NIRUNLSU5HKFtwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24g
JF9wa2dfbWluX3ZlcnNpb25dKQorCWlmICRQS0dfQ09ORklHIC0tYXRsZWFzdC1wa2djb25maWct
dmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgorCQlBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
CWVsc2UKKwkJQUNfTVNHX1JFU1VMVChbbm9dKQorCQlQS0dfQ09ORklHPSIiCisJZmkKK2ZpW11k
bmwKK10pIyBQS0dfUFJPR19QS0dfQ09ORklHCisKKyMgUEtHX0NIRUNLX0VYSVNUUyhNT0RVTEVT
LCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQorIworIyBDaGVjayB0
byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMgZXhpc3RzLiAgU2ltaWxh
cgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBub3Qgc2V0IHZhcmlhYmxlcyBv
ciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1lbWJlciB0aGF0IG00IGV4cGFuZHMgQUNf
UkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisjIG9ubHkgYXQgdGhlIGZpcnN0IG9jY3Vy
ZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBwbGFjZQorIyBpdCdzIGNhbGxl
ZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdpdGhpbiBhbiAiaWYiLCB5b3UK
KyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFsbHkKKyMgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RF
RlVOKFtQS0dfQ0hFQ0tfRVhJU1RTXSwKK1tBQ19SRVFVSVJFKFtQS0dfUFJPR19QS0dfQ09ORklH
XSlkbmwKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCisgICAgQUNfUlVOX0xPRyhbJFBL
R19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgIiQxIl0pOyB0aGVuCisgIG00X2RlZmF1
bHQoWyQyXSwgWzpdKQorbTRfaWZ2YWxuKFskM10sIFtlbHNlCisgICQzXSlkbmwKK2ZpXSkKKwor
IyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFORF0sIFtNT0RVTEVTXSkKKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCittNF9kZWZpbmUoW19QS0df
Q09ORklHXSwKK1tpZiB0ZXN0IC1uICIkJDEiOyB0aGVuCisgICAgcGtnX2N2X1tdJDE9IiQkMSIK
KyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorICAgIFBLR19DSEVDS19FWElTVFMo
WyQzXSwKKyAgICAgICAgICAgICAgICAgICAgIFtwa2dfY3ZfW10kMT1gJFBLR19DT05GSUcgLS1b
XSQyICIkMyIgMj4vZGV2L251bGxgXSwKKwkJICAgICBbcGtnX2ZhaWxlZD15ZXNdKQorIGVsc2UK
KyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2ZpW11kbmwKK10pIyBfUEtHX0NPTkZJRworCisjIF9Q
S0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQorQUNfREVGVU4oW19QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRF0sCitbQUNfUkVRVUlSRShb
UEtHX1BST0dfUEtHX0NPTkZJR10pCitpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtnY29uZmln
LXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9
eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZD1ubworZmlbXWRu
bAorXSkjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorCisKKyMgUEtHX0NIRUNLX01PRFVM
RVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwKKyMgW0FDVElP
Ti1JRi1OT1QtRk9VTkRdKQorIworIworIyBOb3RlIHRoYXQgaWYgdGhlcmUgaXMgYSBwb3NzaWJp
bGl0eSB0aGUgZmlyc3QgY2FsbCB0bworIyBQS0dfQ0hFQ0tfTU9EVUxFUyBtaWdodCBub3QgaGFw
cGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgorIyBleHBsaWNpdCBjYWxsIHRv
IFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25maWd1cmUuYWMKKyMKKyMKKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
K0FDX0RFRlVOKFtQS0dfQ0hFQ0tfTU9EVUxFU10sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtH
X0NPTkZJR10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0NGTEFHU10sIFtDIGNvbXBpbGVyIGZsYWdz
IGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlkbmwKK0FDX0FSR19WQVIoWyQxXVtfTElC
U10sIFtsaW5rZXIgZmxhZ3MgZm9yICQxLCBvdmVycmlkaW5nIHBrZy1jb25maWddKWRubAorCitw
a2dfZmFpbGVkPW5vCitBQ19NU0dfQ0hFQ0tJTkcoW2ZvciAkMV0pCisKK19QS0dfQ09ORklHKFsk
MV1bX0NGTEFHU10sIFtjZmxhZ3NdLCBbJDJdKQorX1BLR19DT05GSUcoWyQxXVtfTElCU10sIFts
aWJzXSwgWyQyXSkKKworbTRfZGVmaW5lKFtfUEtHX1RFWFRdLCBbQWx0ZXJuYXRpdmVseSwgeW91
IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyAkMVtdX0NGTEFHUworYW5kICQxW11f
TElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBjYWxsIHBrZy1jb25maWcuCitTZWUgdGhlIHBrZy1j
b25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy5dKQorCitpZiB0ZXN0ICRwa2dfZmFpbGVk
ID0geWVzOyB0aGVuCisgICAJQUNfTVNHX1JFU1VMVChbbm9dKQorICAgICAgICBfUEtHX1NIT1JU
X0VSUk9SU19TVVBQT1JURUQKKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3Vw
cG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICAkMVtdX1BLR19FUlJPUlM9YCRQS0dfQ09ORklH
IC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICIkMiIgMj4mMWAKKyAgICAgICAgZWxzZSAK
KwkgICAgICAgICQxW11fUEtHX0VSUk9SUz1gJFBLR19DT05GSUcgLS1wcmludC1lcnJvcnMgIiQy
IiAyPiYxYAorICAgICAgICBmaQorCSMgUHV0IHRoZSBuYXN0eSBlcnJvciBtZXNzYWdlIGluIGNv
bmZpZy5sb2cgd2hlcmUgaXQgYmVsb25ncworCWVjaG8gIiQkMVtdX1BLR19FUlJPUlMiID4mQVNf
TUVTU0FHRV9MT0dfRkQKKworCW00X2RlZmF1bHQoWyQ0XSwgW0FDX01TR19FUlJPUigKK1tQYWNr
YWdlIHJlcXVpcmVtZW50cyAoJDIpIHdlcmUgbm90IG1ldDoKKworJCQxX1BLR19FUlJPUlMKKwor
Q29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1lbnQgdmFyaWFi
bGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJlZml4Lgor
CitfUEtHX1RFWFRdKWRubAorICAgICAgICBdKQorZWxpZiB0ZXN0ICRwa2dfZmFpbGVkID0gdW50
cmllZDsgdGhlbgorICAgICAJQUNfTVNHX1JFU1VMVChbbm9dKQorCW00X2RlZmF1bHQoWyQ0XSwg
W0FDX01TR19GQUlMVVJFKAorW1RoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91
bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9yIHNldCB0
aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0aCB0byBw
a2ctY29uZmlnLgorCitfUEtHX1RFWFQKKworVG8gZ2V0IHBrZy1jb25maWcsIHNlZSA8aHR0cDov
L3BrZy1jb25maWcuZnJlZWRlc2t0b3Aub3JnLz4uXSlkbmwKKyAgICAgICAgXSkKK2Vsc2UKKwkk
MVtdX0NGTEFHUz0kcGtnX2N2X1tdJDFbXV9DRkxBR1MKKwkkMVtdX0xJQlM9JHBrZ19jdl9bXSQx
W11fTElCUworICAgICAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorCSQzCitmaVtdZG5sCitdKSMg
UEtHX0NIRUNLX01PRFVMRVMKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRv
b2xzL200L3B5dGhvbl9kZXZlbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25fZGV2ZWwubTQJTW9uIEZlYiAyMCAyMzox
ODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTggQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRI
T05fREVWRUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhvbiBkZXZlbF0pCisKK2AkUFlU
SE9OIC1jICcKK2ltcG9ydCBvcy5wYXRoLCBzeXMKK2ZvciBwIGluIHN5cy5wYXRoOgorICAgIGlm
IG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIpOgorICAgICAgICBzeXMuZXhp
dCgwKQorc3lzLmV4aXQoMSkKKycgPiAvZGV2L251bGwgMj4mMWAKKworaWYgdGVzdCAiJD8iICE9
ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoW1B5
dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZF0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChb
eWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4N2IwOWU5M2FhIHRvb2xzL200
L3B5dGhvbl92ZXJzaW9uLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00CU1vbiBGZWIgMjAgMjM6MTg6
MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDEyIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9O
X1ZFUlNJT05dLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhvbiB2ZXJzaW9uID49ICQxLiQy
IF0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZv
IDwgKCQxLCAkMikiKSknYAoraWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92
ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFgCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFD
X01TR19FUlJPUigKKyAgICAgICAgWyRweXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVt
IHJlcXVpcmVkIHZlcnNpb24gaXMgJDEuJDJdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3ll
c10pCitmaV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9tNC9w
eXRob25feG1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3Rvb2xzL200L3B5dGhvbl94bWwubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fWE1MXSwKK1tB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24geG1sLmRvbS5taW5pZG9tXSkKK2AkUFlUSE9OIC1j
ICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAg
ICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCB4
bWwuZG9tLm1pbmlkb20gbW9kdWxlXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
ZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBkZDg3YjA5ZTkzYWEgdG9vbHMvbTQvc2V0X2Nm
bGFnc19sZGZsYWdzLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5tNAlNb24gRmViIDIwIDIzOjE4
OjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyMCBAQAorQUNfREVGVU4oW0FYX1NFVF9GTEFHU10s
CitbZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCitkbworICAgIFBSRVBFTkRfQ0ZMQUdT
Kz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIKK2RvCisgICAg
UFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5E
X0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3Ig
bGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxh
ZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1Mi
CitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFHUyJdKQor
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB0b29scy9tNC91ZGV2Lm00Ci0t
LSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200
L3VkZXYubTQJTW9uIEZlYiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMzIgQEAK
K0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGlu
dXgtZ251IgordGhlbgorICAgIEFDX1BBVEhfUFJPRyhbVURFVkFETV0sIFt1ZGV2YWRtXSwgW25v
XSkKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJubyIgCisgICAgdGhlbgorICAgICAg
ICBBQ19QQVRIX1BST0coW1VERVZJTkZPXSwgW3VkZXZpbmZvXSwgW25vXSkKKyAgICAgICAgaWYg
dGVzdCB4IiR7VURFVklORk99IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBB
Q19NU0dfRVJST1IoCisgICAgICAgICAgICAgICAgW1VuYWJsZSB0byBmaW5kIHVkZXZhZG0gb3Ig
dWRldmluZm8sIHBsZWFzZSBpbnN0YWxsIHVkZXZdKQorICAgICAgICBmaQorICAgICAgICB1ZGV2
dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGVsc2UKKyAgICAg
ICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCisgICAg
ZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAgdGhlbgorICAgICAgICBBQ19Q
QVRIX1BST0coW0hPVFBMVUddLCBbaG90cGx1Z10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIk
e0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBBQ19NU0dfRVJS
T1IoW3VkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVyXSkKKyAg
ICAgICAgZmkKKyAgICBmaQorZWxzZQorICAgIEFDX1BBVEhfUFJPRyhbVk5DT05GSUddLCBbdm5j
b25maWddLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1ZOQ09ORklHfSIgPT0geCJubyIKKyAgICB0
aGVuCisgICAgICAgIEFDX01TR19FUlJPUihbTm90IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUg
dG8gZmluZCB2bmRdKQorICAgIGZpCitmaQorXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgZGQ4
N2IwOWU5M2FhIHRvb2xzL200L3V1aWQubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdXVpZC5tNAlNb24gRmViIDIwIDIzOjE4OjAx
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1VVSURdLAor
W2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0aGVuCisgICAgQUNfQ0hFQ0tf
SEVBREVSKFt1dWlkL3V1aWQuaF0sLAorCSAgICBbQUNfTVNHX0VSUk9SKFtjYW5ub3QgZmluZCB1
dWlkIGhlYWRlcnNdKV0pCitlbHNlCisgICAgQUNfQ0hFQ0tfSEVBREVSKFt1dWlkLmhdLCwKKwkg
ICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzXSldKQorZmkKK10pCmRp
ZmYgLXIgY2E4MGVjYTljZmEzIC1yIGRkODdiMDllOTNhYSB2ZXJzaW9uLnNoCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3ZlcnNpb24uc2gJTW9uIEZl
YiAyMCAyMzoxODowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNSBAQAorIyEvYmluL3NoCisKK01B
Sk9SPWBncmVwICJleHBvcnQgWEVOX1ZFUlNJT04iICQxIHwgc2VkICdzLy4qPS8vZycgfCB0ciAt
cyAiICJgCitNSU5PUj1gZ3JlcCAiZXhwb3J0IFhFTl9TVUJWRVJTSU9OIiAkMSB8IHNlZCAncy8u
Kj0vL2cnIHwgdHIgLXMgIiAiYAorcHJpbnRmICIlZC4lZCIgJE1BSk9SICRNSU5PUgo=

--===============5260582694761208521==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5260582694761208521==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 09:34:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09: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 1Rzm6w-0005Gi-Ow; Tue, 21 Feb 2012 09:34:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rzm6v-0005GN-7G
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:34:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329816846!15654048!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18833 invoked from network); 21 Feb 2012 09:34:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:34:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:34:05 +0000
Message-Id: <4F43731A02000078000740BA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:34:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shan Haitao <maillists.shan@gmail.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 11/11] xen passthrough: clean up MSI-X
 table 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 17.02.12 at 18:08, Anthony PERARD <anthony.perard@citrix.com> wrote:

Wouldn't thus much better be merged into the prior patch(es)? After
all you're not trying to reconstruct the Xen-side history of this code
anyway.

Jan

> From: Shan Haitao <maillists.shan@gmail.com>
> 
> This patch does cleaning up of QEMU MSI handling. The fixes are:
> 1. Changes made to MSI-X table mapping handling to eliminate the small
> windows in which guest could have access to physical MSI-X table.
> 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
> already in Xen now.
> 3. For registers that coexists inside the MSI-X table (this could be
> only PBA I think), value read from physical page would be returned.
> 
> Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
> 
> Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen_pci_passthrough.c     |   80 ++++++++++++++++++++++++++++++++----------
>  hw/xen_pci_passthrough.h     |   11 +++++-
>  hw/xen_pci_passthrough_msi.c |   62 ++++----------------------------
>  3 files changed, 78 insertions(+), 75 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 6ea2c45..fab9fbe 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -356,6 +356,53 @@ out:
>      }
>  }
>  
> +static int pt_iomem_helper(XenPCIPassthroughState *s, int i,
> +                           pcibus_t e_base, pcibus_t e_size, int op)
> +{
> +    uint64_t msix_last_pfn = 0;
> +    pcibus_t bar_last_pfn = 0;
> +    pcibus_t msix_table_size = 0;
> +    XenPTMSIX *msix = s->msix;
> +    int rc = 0;
> +
> +    if (!pt_has_msix_mapping(s, i)) {
> +        return xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                        PFN(e_base),
> +                                        PFN(s->bases[i].access.maddr),
> +                                        PFN(e_size + XC_PAGE_SIZE - 1),
> +                                        op);
> +
> +    }
> +
> +    if (msix->table_off) {
> +        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                      PFN(e_base),
> +                                      PFN(s->bases[i].access.maddr),
> +                                      PFN(msix->mmio_base_addr) - PFN(e_base),
> +                                      op);
> +    }
> +
> +    msix_table_size = msix->total_entries * PCI_MSIX_ENTRY_SIZE;
> +    msix_last_pfn = PFN(msix->mmio_base_addr + msix_table_size - 1);
> +    bar_last_pfn = PFN(e_base + e_size - 1);
> +
> +    if (rc == 0 && msix_last_pfn != bar_last_pfn) {
> +        assert(msix_last_pfn < bar_last_pfn);
> +
> +        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                      msix_last_pfn + 1,
> +                                      PFN(s->bases[i].access.maddr
> +                                          + msix->table_off
> +                                          + msix_table_size
> +                                          + XC_PAGE_SIZE - 1),
> +                                      bar_last_pfn - msix_last_pfn,
> +                                      op);
> +    }
> +
> +    return rc;
> +}
> +
> +
>  /* ioport/iomem space*/
>  static void pt_iomem_map(XenPCIPassthroughState *s, int i,
>                           pcibus_t e_phys, pcibus_t e_size)
> @@ -376,13 +423,10 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>      }
>  
>      if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> -        pt_add_msix_mapping(s, i);
> -        /* Remove old mapping */
> -        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> -                               old_ebase >> XC_PAGE_SHIFT,
> -                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> -                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> -                               DPCI_REMOVE_MAPPING);
> +        if (pt_has_msix_mapping(s, i)) {
> +            memory_region_set_enabled(&s->msix->mmio, false);
> +        }
> +        rc = pt_iomem_helper(s, i, old_ebase, e_size, DPCI_REMOVE_MAPPING);
>          if (rc) {
>              PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
>              return;
> @@ -391,21 +435,19 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>  
>      /* map only valid guest address */
>      if (e_phys != PCI_BAR_UNMAPPED) {
> -        /* Create new mapping */
> -        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> -                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
> -                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> -                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
> -                                   DPCI_ADD_MAPPING);
> +        if (pt_has_msix_mapping(s, i)) {
> +            XenPTMSIX *msix = s->msix;
>  
> -        if (rc) {
> -            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
> +            msix->mmio_base_addr = s->bases[i].e_physbase + msix->table_off;
> +
> +            memory_region_set_enabled(&msix->mmio, true);
>          }
>  
> -        rc = pt_remove_msix_mapping(s, i);
> -        if (rc != 0) {
> -            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
> -                   rc);
> +        rc = pt_iomem_helper(s, i, e_phys, e_size, DPCI_ADD_MAPPING);
> +
> +        if (rc) {
> +            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
> +            return;
>          }
>  
>          if (old_ebase != e_phys && old_ebase != -1) {
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index 3d41e04..f36e0d2 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -30,6 +30,9 @@ void pt_log(const PCIDevice *d, const char *f, ...) 
> GCC_FMT_ATTR(2, 3);
>  #endif
>  
>  
> +/* Helper */
> +#define PFN(x) ((x) >> XC_PAGE_SHIFT)
> +
>  typedef struct XenPTRegInfo XenPTRegInfo;
>  typedef struct XenPTReg XenPTReg;
>  
> @@ -295,7 +298,11 @@ void pt_msix_delete(XenPCIPassthroughState *s);
>  int pt_msix_update(XenPCIPassthroughState *s);
>  int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
>  void pt_msix_disable(XenPCIPassthroughState *s);
> -int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> -int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +
> +static inline bool pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
> +{
> +    return s->msix && s->msix->bar_index == bar;
> +}
> +
>  
>  #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
> index e848c61..e775d21 100644
> --- a/hw/xen_pci_passthrough_msi.c
> +++ b/hw/xen_pci_passthrough_msi.c
> @@ -300,16 +300,6 @@ static int msix_set_enable(XenPCIPassthroughState *s, 
> bool enabled)
>                             enabled);
>  }
>  
> -static void mask_physical_msix_entry(XenPCIPassthroughState *s,
> -                                     int entry_nr, int mask)
> -{
> -    void *phys_off;
> -
> -    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
> -        + PCI_MSIX_ENTRY_VECTOR_CTRL;
> -    *(uint32_t *)phys_off = mask;
> -}
> -
>  static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
>  {
>      XenPTMSIXEntry *entry = NULL;
> @@ -480,8 +470,6 @@ static void pci_msix_write(void *opaque, 
> target_phys_addr_t addr,
>          if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>              pt_msix_update_one(s, entry_nr);
>          }
> -        mask_physical_msix_entry(s, entry_nr,
> -            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
>      }
>  }
>  
> @@ -493,14 +481,19 @@ static uint64_t pci_msix_read(void *opaque, 
> target_phys_addr_t addr,
>      int entry_nr, offset;
>  
>      entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
> -    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
> +    if (entry_nr < 0) {
>          PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
>          return 0;
>      }
>  
>      offset = addr % PCI_MSIX_ENTRY_SIZE;
>  
> -    return get_entry_value(&msix->msix_entry[entry_nr], offset);
> +    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
> +        return get_entry_value(&msix->msix_entry[entry_nr], offset);
> +    } else {
> +        /* Pending Bit Array (PBA) */
> +        return *(uint32_t *)(msix->phys_iomem_base + addr);
> +    }
>  }
>  
>  static const MemoryRegionOps pci_msix_ops = {
> @@ -514,45 +507,6 @@ static const MemoryRegionOps pci_msix_ops = {
>      },
>  };
>  
> -int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> -{
> -    XenPTMSIX *msix = s->msix;
> -
> -    if (!(s->msix && s->msix->bar_index == bar_index)) {
> -        return 0;
> -    }
> -
> -    memory_region_set_enabled(&msix->mmio, false);
> -    return xc_domain_memory_mapping(xen_xc, xen_domid,
> -         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> -         (s->bases[bar_index].access.maddr + s->msix->table_off)
> -           >> XC_PAGE_SHIFT,
> -         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> -           >> XC_PAGE_SHIFT,
> -         DPCI_ADD_MAPPING);
> -}
> -
> -int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> -{
> -    XenPTMSIX *msix = s->msix;
> -
> -    if (!(msix && msix->bar_index == bar_index)) {
> -        return 0;
> -    }
> -
> -    memory_region_set_enabled(&msix->mmio, true);
> -
> -    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
> -
> -    return xc_domain_memory_mapping(xen_xc, xen_domid,
> -         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> -         (s->bases[bar_index].access.maddr + s->msix->table_off)
> -             >> XC_PAGE_SHIFT,
> -         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> -             >> XC_PAGE_SHIFT,
> -         DPCI_REMOVE_MAPPING);
> -}
> -
>  int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
>  {
>      uint8_t id = 0;
> @@ -609,7 +563,7 @@ int pt_msix_init(XenPCIPassthroughState *s, uint32_t 
> base)
>      msix->phys_iomem_base =
>          mmap(NULL,
>               total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
> -             PROT_WRITE | PROT_READ,
> +             PROT_READ,
>               MAP_SHARED | MAP_LOCKED,
>               fd,
>               msix->table_base + table_off - msix->table_offset_adjust);
> -- 
> Anthony PERARD



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:34:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09: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 1Rzm6w-0005Gi-Ow; Tue, 21 Feb 2012 09:34:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rzm6v-0005GN-7G
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:34:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1329816846!15654048!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18833 invoked from network); 21 Feb 2012 09:34:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:34:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:34:05 +0000
Message-Id: <4F43731A02000078000740BA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:34:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Anthony PERARD" <anthony.perard@citrix.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shan Haitao <maillists.shan@gmail.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 11/11] xen passthrough: clean up MSI-X
 table 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 17.02.12 at 18:08, Anthony PERARD <anthony.perard@citrix.com> wrote:

Wouldn't thus much better be merged into the prior patch(es)? After
all you're not trying to reconstruct the Xen-side history of this code
anyway.

Jan

> From: Shan Haitao <maillists.shan@gmail.com>
> 
> This patch does cleaning up of QEMU MSI handling. The fixes are:
> 1. Changes made to MSI-X table mapping handling to eliminate the small
> windows in which guest could have access to physical MSI-X table.
> 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is
> already in Xen now.
> 3. For registers that coexists inside the MSI-X table (this could be
> only PBA I think), value read from physical page would be returned.
> 
> Signed-off-by:  Shan Haitao <maillists.shan@gmail.com>
> 
> Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen_pci_passthrough.c     |   80 ++++++++++++++++++++++++++++++++----------
>  hw/xen_pci_passthrough.h     |   11 +++++-
>  hw/xen_pci_passthrough_msi.c |   62 ++++----------------------------
>  3 files changed, 78 insertions(+), 75 deletions(-)
> 
> diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
> index 6ea2c45..fab9fbe 100644
> --- a/hw/xen_pci_passthrough.c
> +++ b/hw/xen_pci_passthrough.c
> @@ -356,6 +356,53 @@ out:
>      }
>  }
>  
> +static int pt_iomem_helper(XenPCIPassthroughState *s, int i,
> +                           pcibus_t e_base, pcibus_t e_size, int op)
> +{
> +    uint64_t msix_last_pfn = 0;
> +    pcibus_t bar_last_pfn = 0;
> +    pcibus_t msix_table_size = 0;
> +    XenPTMSIX *msix = s->msix;
> +    int rc = 0;
> +
> +    if (!pt_has_msix_mapping(s, i)) {
> +        return xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                        PFN(e_base),
> +                                        PFN(s->bases[i].access.maddr),
> +                                        PFN(e_size + XC_PAGE_SIZE - 1),
> +                                        op);
> +
> +    }
> +
> +    if (msix->table_off) {
> +        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                      PFN(e_base),
> +                                      PFN(s->bases[i].access.maddr),
> +                                      PFN(msix->mmio_base_addr) - PFN(e_base),
> +                                      op);
> +    }
> +
> +    msix_table_size = msix->total_entries * PCI_MSIX_ENTRY_SIZE;
> +    msix_last_pfn = PFN(msix->mmio_base_addr + msix_table_size - 1);
> +    bar_last_pfn = PFN(e_base + e_size - 1);
> +
> +    if (rc == 0 && msix_last_pfn != bar_last_pfn) {
> +        assert(msix_last_pfn < bar_last_pfn);
> +
> +        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                                      msix_last_pfn + 1,
> +                                      PFN(s->bases[i].access.maddr
> +                                          + msix->table_off
> +                                          + msix_table_size
> +                                          + XC_PAGE_SIZE - 1),
> +                                      bar_last_pfn - msix_last_pfn,
> +                                      op);
> +    }
> +
> +    return rc;
> +}
> +
> +
>  /* ioport/iomem space*/
>  static void pt_iomem_map(XenPCIPassthroughState *s, int i,
>                           pcibus_t e_phys, pcibus_t e_size)
> @@ -376,13 +423,10 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>      }
>  
>      if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
> -        pt_add_msix_mapping(s, i);
> -        /* Remove old mapping */
> -        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> -                               old_ebase >> XC_PAGE_SHIFT,
> -                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> -                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
> -                               DPCI_REMOVE_MAPPING);
> +        if (pt_has_msix_mapping(s, i)) {
> +            memory_region_set_enabled(&s->msix->mmio, false);
> +        }
> +        rc = pt_iomem_helper(s, i, old_ebase, e_size, DPCI_REMOVE_MAPPING);
>          if (rc) {
>              PT_ERR(&s->dev, "remove old mapping failed! (rc: %i)\n", rc);
>              return;
> @@ -391,21 +435,19 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int 
> i,
>  
>      /* map only valid guest address */
>      if (e_phys != PCI_BAR_UNMAPPED) {
> -        /* Create new mapping */
> -        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> -                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
> -                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
> -                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
> -                                   DPCI_ADD_MAPPING);
> +        if (pt_has_msix_mapping(s, i)) {
> +            XenPTMSIX *msix = s->msix;
>  
> -        if (rc) {
> -            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
> +            msix->mmio_base_addr = s->bases[i].e_physbase + msix->table_off;
> +
> +            memory_region_set_enabled(&msix->mmio, true);
>          }
>  
> -        rc = pt_remove_msix_mapping(s, i);
> -        if (rc != 0) {
> -            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed! (rc: %d)\n",
> -                   rc);
> +        rc = pt_iomem_helper(s, i, e_phys, e_size, DPCI_ADD_MAPPING);
> +
> +        if (rc) {
> +            PT_ERR(&s->dev, "create new mapping failed! (rc: %i)\n", rc);
> +            return;
>          }
>  
>          if (old_ebase != e_phys && old_ebase != -1) {
> diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
> index 3d41e04..f36e0d2 100644
> --- a/hw/xen_pci_passthrough.h
> +++ b/hw/xen_pci_passthrough.h
> @@ -30,6 +30,9 @@ void pt_log(const PCIDevice *d, const char *f, ...) 
> GCC_FMT_ATTR(2, 3);
>  #endif
>  
>  
> +/* Helper */
> +#define PFN(x) ((x) >> XC_PAGE_SHIFT)
> +
>  typedef struct XenPTRegInfo XenPTRegInfo;
>  typedef struct XenPTReg XenPTReg;
>  
> @@ -295,7 +298,11 @@ void pt_msix_delete(XenPCIPassthroughState *s);
>  int pt_msix_update(XenPCIPassthroughState *s);
>  int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
>  void pt_msix_disable(XenPCIPassthroughState *s);
> -int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> -int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
> +
> +static inline bool pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
> +{
> +    return s->msix && s->msix->bar_index == bar;
> +}
> +
>  
>  #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
> diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
> index e848c61..e775d21 100644
> --- a/hw/xen_pci_passthrough_msi.c
> +++ b/hw/xen_pci_passthrough_msi.c
> @@ -300,16 +300,6 @@ static int msix_set_enable(XenPCIPassthroughState *s, 
> bool enabled)
>                             enabled);
>  }
>  
> -static void mask_physical_msix_entry(XenPCIPassthroughState *s,
> -                                     int entry_nr, int mask)
> -{
> -    void *phys_off;
> -
> -    phys_off = s->msix->phys_iomem_base + PCI_MSIX_ENTRY_SIZE * entry_nr
> -        + PCI_MSIX_ENTRY_VECTOR_CTRL;
> -    *(uint32_t *)phys_off = mask;
> -}
> -
>  static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
>  {
>      XenPTMSIXEntry *entry = NULL;
> @@ -480,8 +470,6 @@ static void pci_msix_write(void *opaque, 
> target_phys_addr_t addr,
>          if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>              pt_msix_update_one(s, entry_nr);
>          }
> -        mask_physical_msix_entry(s, entry_nr,
> -            entry->vector_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT);
>      }
>  }
>  
> @@ -493,14 +481,19 @@ static uint64_t pci_msix_read(void *opaque, 
> target_phys_addr_t addr,
>      int entry_nr, offset;
>  
>      entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
> -    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
> +    if (entry_nr < 0) {
>          PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
>          return 0;
>      }
>  
>      offset = addr % PCI_MSIX_ENTRY_SIZE;
>  
> -    return get_entry_value(&msix->msix_entry[entry_nr], offset);
> +    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
> +        return get_entry_value(&msix->msix_entry[entry_nr], offset);
> +    } else {
> +        /* Pending Bit Array (PBA) */
> +        return *(uint32_t *)(msix->phys_iomem_base + addr);
> +    }
>  }
>  
>  static const MemoryRegionOps pci_msix_ops = {
> @@ -514,45 +507,6 @@ static const MemoryRegionOps pci_msix_ops = {
>      },
>  };
>  
> -int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> -{
> -    XenPTMSIX *msix = s->msix;
> -
> -    if (!(s->msix && s->msix->bar_index == bar_index)) {
> -        return 0;
> -    }
> -
> -    memory_region_set_enabled(&msix->mmio, false);
> -    return xc_domain_memory_mapping(xen_xc, xen_domid,
> -         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> -         (s->bases[bar_index].access.maddr + s->msix->table_off)
> -           >> XC_PAGE_SHIFT,
> -         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> -           >> XC_PAGE_SHIFT,
> -         DPCI_ADD_MAPPING);
> -}
> -
> -int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
> -{
> -    XenPTMSIX *msix = s->msix;
> -
> -    if (!(msix && msix->bar_index == bar_index)) {
> -        return 0;
> -    }
> -
> -    memory_region_set_enabled(&msix->mmio, true);
> -
> -    msix->mmio_base_addr = s->bases[bar_index].e_physbase + msix->table_off;
> -
> -    return xc_domain_memory_mapping(xen_xc, xen_domid,
> -         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
> -         (s->bases[bar_index].access.maddr + s->msix->table_off)
> -             >> XC_PAGE_SHIFT,
> -         (s->msix->total_entries * PCI_MSIX_ENTRY_SIZE + XC_PAGE_SIZE - 1)
> -             >> XC_PAGE_SHIFT,
> -         DPCI_REMOVE_MAPPING);
> -}
> -
>  int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
>  {
>      uint8_t id = 0;
> @@ -609,7 +563,7 @@ int pt_msix_init(XenPCIPassthroughState *s, uint32_t 
> base)
>      msix->phys_iomem_base =
>          mmap(NULL,
>               total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
> -             PROT_WRITE | PROT_READ,
> +             PROT_READ,
>               MAP_SHARED | MAP_LOCKED,
>               fd,
>               msix->table_base + table_off - msix->table_offset_adjust);
> -- 
> Anthony PERARD



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:39:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmBT-0005VE-MK; Tue, 21 Feb 2012 09:38:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RzmBS-0005Uy-CL
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 09:38:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329817127!15720092!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20284 invoked from network); 21 Feb 2012 09:38:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:38:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:38:47 +0000
Message-Id: <4F43743102000078000740C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:38:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Andrew Jones" <drjones@redhat.com>
References: <4F436E75020000780007409F@nat28.tlf.novell.com>
	<0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel <xen-devel@lists.xen.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
>> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
>> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
>> >> There was another fix that sounds similar to this in the backend.
>> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
>> >> 
>> > 
>> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
>> > tree has that, but it probably would be a good idea there too.
>> 
>> While I had seen the change and considered pulling it in, I wasn't
>> really convinced this is the right behavior here: After all, if the
>> host
>> admin requested a resource to be removed from a guest, it shouldn't
>> depend on the guest whether and when to honor that request, yet
>> by deferring the disconnect you basically allow the guest to continue
>> using the disk indefinitely.
>> 
> 
> I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> something we want. At the moment, Igor and I are poking through
> xen-blkfront.c, and currently we'd rather see the feature dropped
> in favor of a simplified driver. One that has less release paths,
> and/or release paths with more consistent locking behavior.

I must have missed this, or it's one more instance of delayed mail
delivery via xen-devel.

Konrad - care to revert that original change as having barked up
the wrong tree?

Jan

> [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:39:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmBT-0005VE-MK; Tue, 21 Feb 2012 09:38:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RzmBS-0005Uy-CL
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 09:38:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329817127!15720092!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20284 invoked from network); 21 Feb 2012 09:38:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 09:38:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 09:38:47 +0000
Message-Id: <4F43743102000078000740C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 09:38:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Andrew Jones" <drjones@redhat.com>
References: <4F436E75020000780007409F@nat28.tlf.novell.com>
	<0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
In-Reply-To: <0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel <xen-devel@lists.xen.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
>> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
>> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
>> >> There was another fix that sounds similar to this in the backend.
>> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
>> >> 
>> > 
>> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
>> > tree has that, but it probably would be a good idea there too.
>> 
>> While I had seen the change and considered pulling it in, I wasn't
>> really convinced this is the right behavior here: After all, if the
>> host
>> admin requested a resource to be removed from a guest, it shouldn't
>> depend on the guest whether and when to honor that request, yet
>> by deferring the disconnect you basically allow the guest to continue
>> using the disk indefinitely.
>> 
> 
> I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> something we want. At the moment, Igor and I are poking through
> xen-blkfront.c, and currently we'd rather see the feature dropped
> in favor of a simplified driver. One that has less release paths,
> and/or release paths with more consistent locking behavior.

I must have missed this, or it's one more instance of delayed mail
delivery via xen-devel.

Konrad - care to revert that original change as having barked up
the wrong tree?

Jan

> [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:46:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmIx-0005lA-Kh; Tue, 21 Feb 2012 09:46:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmIv-0005kg-Ec
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:46:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329817590!10007197!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24910 invoked from network); 21 Feb 2012 09:46:31 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:46:31 -0000
Received: by werb14 with SMTP id b14so14287930wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 01:46:30 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr31867617wia.3.1329817590537 (num_hops
	= 1); Tue, 21 Feb 2012 01:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=l3JXzsCVToSjVmhD2jSAY1P/c8jzeAaLvxRTD4tfCZg=;
	b=EJ4iQ4d3mgjuTNhF73XhKMFcf3i16FIYZ3qXdm3zzAp9cUJqLlgEAAYNC7Vr95DwWL
	MiY7kJxsnVaPT4YejpltDPCzGI0UILgVO4nP47K5wfiBj8r7UPykt6goBikxHJL7LD53
	1h/ZoPRG/AgUx3xjPn1aZq9VG7lH8J0s4cjzw=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr26637460wia.3.1329817590502; Tue,
	21 Feb 2012 01:46:30 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 01:46:30 -0800 (PST)
In-Reply-To: <20290.29364.583732.682392@mariner.uk.xensource.com>
References: <1b95948228b84c986764.1326548473@loki.upc.es>
	<20290.29364.583732.682392@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 10:46:30 +0100
X-Google-Sender-Auth: Y_tXdJW9PoIVMUTSx3gPXWuTjpo
Message-ID: <CAPLaKK4unmG7hLcsNxHjH=bn2+xPT5VAqyxqhdNpzW3fTb5TqQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and
 set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIwIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDogQXRvbWlj
YWx5IGNoZWNrIGJhY2tlbmQgc3RhdGUgYW5kIHNldCBpdCB0byA1IGF0IGRldmljZV9yZW1vdmUi
KToKPj4gbGlieGw6IEF0b21pY2FseSBjaGVjayBiYWNrZW5kIHN0YXRlIGFuZCBzZXQgaXQgdG8g
NSBhdCBkZXZpY2VfcmVtb3ZlCj4+Cj4+IGxpYnhsX19kZXZpY2VfcmVtb3ZlIHdhcyBzZXR0aW5n
IGJhY2tlbmQgc3RhdGUgdG8gNSwgd2hpY2ggY291bGQKPj4gY3JlYXRlIGEgcmFjZSBjb25kaXRp
b24sIHNpbmNlIHRoZSBwcmV2aW91cyBjaGVjayBmb3Igc3RhdGUgIT0gNCBhbmQKPj4gc2V0dGlu
ZyBzdGF0ZSB0byA1IHdhcyBub3QgZG9uZSBpbnNpZGUgdGhlIHNhbWUgdHJhbnNhY3Rpb24sIHNv
IHRoZQo+PiBrZXJuZWwgY291bGQgY2hhbmdlIHRoZSBzdGF0ZSB0byA2IGluIHRoZSBzcGFjZSBi
ZXR3ZWVuIHRoZSBjaGVjayBmb3IKPj4gc3RhdGUgIT0gNCBhbmQgc2V0dGluZyBpdCB0byA1Lgo+
Pgo+PiBUaGUgc3RhdGUgIT0gNCBjaGVjayBhbmQgc2V0dGluZyBpdCB0byA1IHNob3VsZCBoYXBw
ZW4gaW4gdGhlIHNhbWUKPj4gdHJhbnNhY3Rpb24sIHRvIGFzc3VyZSB0aGF0IG5vYm9keSBpcyBt
b2RpZnlpbmcgaXQgYmVoaW5kIG91ciBiYWNrLgo+Cj4gVGhpcyBsb29rcyBsaWtlIGEgY29ycmVj
dCBmaXggdG8gbWUuIMKgSG93ZXZlciwgdGhlIGNvZGUgaW4gbGlieGwgaGFzCj4gY2hhbmdlZCBu
b3c6IGxpYnhsX19kZXZpY2VfcmVtb3ZlIGlzIG5vdwo+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2Vf
cmVtb3ZlLgo+Cj4gQWxzbyBjYW4geW91IHBsZWFzZSBhcnJhbmdlIHRvIHVzZSAiZ290byBvdXQi
IHN0eWxlIGVycm9yIGhhbmRsaW5nID8KPgo+IEVnIHNvbWV0aGluZyBsaWtlOgo+Cj4gwqArIMKg
IMKgIHhzX3RyYW5zYWN0aW9uX3QgdCA9IDA7Cj4gwqAgwqAuLi4KPiDCoCDCoG91dDoKPiDCoCsg
wqAgwqAgaWYgKHQpIHhzX3RyYW5zYWN0aW9uX2VuZChjdHgtPnhzaCwgdCwgMCk7Cj4gwqAgwqAg
wqAgZGV2aWNlX3JlbW92ZV9jbGVhbnVwKGdjLCBhb3JtKTsKCkkgd2lsbCBjb21taXQgYW4gdXBk
YXRlZCB2ZXJzaW9uIG9mIHRoaXMgcGF0Y2ggd2l0aCBteSBob3RwbHVnIHNlcmllcywKdGhhdCBt
YXRjaGVzIHRoZSBjdXJyZW50IHN0YXRlIG9mIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3Zl
LgoKPgo+IFRCSCB0aGUgbWVhdCBvZiB0aGlzIGZ1bmN0aW9uIGlzIGluIGdlbmVyYWwgcmF0aGVy
IHVucmVjb25zdHJ1Y3RlZC4KPiBMb3RzIG9mIHVuY2hlY2tlZCB4c193cml0ZSBldGMuIMKgSSBk
b24ndCBrbm93IGlmIHlvdSB3YW50IHRvIGZpeCB0aGF0Cj4gd2hpbGUgeW91J3JlIHRoZXJlLiDC
oEkgd2ltcGVkIG91dCBvbiBkb2luZyB0aGF0IGluIG15IHJlY2VudCBldmVudAo+IHNlcmllcy4g
wqBVcCB0byB5b3UuCgpXaWxsIGRlY2lkZSB0aGF0IGxhdGVyLCBkZXBlbmRpbmcgb24gdGhlIHRp
bWUgZnJhbWUuCgo+IFJlYWxseSB3ZSBzaG91bGQgaGF2ZSBzb21lIGtpbmQgb2YgbW9yZSBjb29r
ZWQgeGVuc3RvcmUgdHJhbnNhY3Rpb24KPiBhcnJhbmdlbWVudHMsIHByb2JhYmx5IGluIHRoZSBn
YywgYW5kIGNlcnRhaW5seSB3aXRoIGEgc3VpdGFibGUgbG9vcAo+IG1hY3JvIHNvIHdlIGNhbiBz
YXk6Cj4gwqBJTl9YRU5TVE9SRV9UUkFOU0FDVElPTiB7Cj4gwqAgwqAgwqByZWFkLCB3cml0ZSwg
ZXRjLgo+IMKgfQo+IEJ1dCB0aGF0J3MgYSB0YXNrIGZvciBhbm90aGVyIGRheSBhbmQgaXQncyBu
b3Qgb24gdGhlIGNyaXRpY2FsIHBhdGgKPiBmb3IgNC4yIHNvIEknbSBwdXR0aW5nIGl0IG9mZi4K
CkFsc28gSSd2ZSBmb3VuZCBteXNlbGYgdXNpbmcgYSBsb3QgYSBjb25zdHJ1Y3Rpb24gbGlrZSB0
aGUgZm9sbG93aW5nOgoKLSBjaGVjayB4ZW5zdG9yZSBwYXRoCi0gSWYgcGF0aCB2YWx1ZSBpcyBk
aWZmZXJlbnQgdGhhbiB4Ci0gU2V0IHVwIGEgd2F0Y2gKLSBXYWl0IGZvciBldmVudHMuCgpBbmQg
SSdtIGFmcmFpZCBpdCdzIG5vdCBjb25jdXJyZW50IHNhZmUsIHNpbmNlIHNvbWVvbmUgY2FuIHBl
cmZvcm0gYQpidW5jaCBvZiB4ZW5zdG9yZSBjaGFuZ2VzIGluIHRoZSBzcGFjZSBiZXR3ZWVuIHNl
dHRpbmcgdGhlIHdhdGNoLCBhbmQKd2FpdCBmb3IgZXZlbnRzLiBUaGUgd2F0Y2hlciB3aWxsIG9u
bHkgZ2V0IG5vdGlmaWVkIG9mIHRoZSBsYXN0CnhlbnN0b3JlIGNoYW5nZSwgYnV0IG5vdCBhbGwg
Y2hhbmdlcyB0aGF0IGhhcHBlbmVkIGJldHdlZW4uCgo+IFRoYW5rcywKPiBJYW4uCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29t
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:46:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmIx-0005lA-Kh; Tue, 21 Feb 2012 09:46:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmIv-0005kg-Ec
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:46:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329817590!10007197!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24910 invoked from network); 21 Feb 2012 09:46:31 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:46:31 -0000
Received: by werb14 with SMTP id b14so14287930wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 01:46:30 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr31867617wia.3.1329817590537 (num_hops
	= 1); Tue, 21 Feb 2012 01:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=l3JXzsCVToSjVmhD2jSAY1P/c8jzeAaLvxRTD4tfCZg=;
	b=EJ4iQ4d3mgjuTNhF73XhKMFcf3i16FIYZ3qXdm3zzAp9cUJqLlgEAAYNC7Vr95DwWL
	MiY7kJxsnVaPT4YejpltDPCzGI0UILgVO4nP47K5wfiBj8r7UPykt6goBikxHJL7LD53
	1h/ZoPRG/AgUx3xjPn1aZq9VG7lH8J0s4cjzw=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr26637460wia.3.1329817590502; Tue,
	21 Feb 2012 01:46:30 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 01:46:30 -0800 (PST)
In-Reply-To: <20290.29364.583732.682392@mariner.uk.xensource.com>
References: <1b95948228b84c986764.1326548473@loki.upc.es>
	<20290.29364.583732.682392@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 10:46:30 +0100
X-Google-Sender-Auth: Y_tXdJW9PoIVMUTSx3gPXWuTjpo
Message-ID: <CAPLaKK4unmG7hLcsNxHjH=bn2+xPT5VAqyxqhdNpzW3fTb5TqQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and
 set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIwIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDogQXRvbWlj
YWx5IGNoZWNrIGJhY2tlbmQgc3RhdGUgYW5kIHNldCBpdCB0byA1IGF0IGRldmljZV9yZW1vdmUi
KToKPj4gbGlieGw6IEF0b21pY2FseSBjaGVjayBiYWNrZW5kIHN0YXRlIGFuZCBzZXQgaXQgdG8g
NSBhdCBkZXZpY2VfcmVtb3ZlCj4+Cj4+IGxpYnhsX19kZXZpY2VfcmVtb3ZlIHdhcyBzZXR0aW5n
IGJhY2tlbmQgc3RhdGUgdG8gNSwgd2hpY2ggY291bGQKPj4gY3JlYXRlIGEgcmFjZSBjb25kaXRp
b24sIHNpbmNlIHRoZSBwcmV2aW91cyBjaGVjayBmb3Igc3RhdGUgIT0gNCBhbmQKPj4gc2V0dGlu
ZyBzdGF0ZSB0byA1IHdhcyBub3QgZG9uZSBpbnNpZGUgdGhlIHNhbWUgdHJhbnNhY3Rpb24sIHNv
IHRoZQo+PiBrZXJuZWwgY291bGQgY2hhbmdlIHRoZSBzdGF0ZSB0byA2IGluIHRoZSBzcGFjZSBi
ZXR3ZWVuIHRoZSBjaGVjayBmb3IKPj4gc3RhdGUgIT0gNCBhbmQgc2V0dGluZyBpdCB0byA1Lgo+
Pgo+PiBUaGUgc3RhdGUgIT0gNCBjaGVjayBhbmQgc2V0dGluZyBpdCB0byA1IHNob3VsZCBoYXBw
ZW4gaW4gdGhlIHNhbWUKPj4gdHJhbnNhY3Rpb24sIHRvIGFzc3VyZSB0aGF0IG5vYm9keSBpcyBt
b2RpZnlpbmcgaXQgYmVoaW5kIG91ciBiYWNrLgo+Cj4gVGhpcyBsb29rcyBsaWtlIGEgY29ycmVj
dCBmaXggdG8gbWUuIMKgSG93ZXZlciwgdGhlIGNvZGUgaW4gbGlieGwgaGFzCj4gY2hhbmdlZCBu
b3c6IGxpYnhsX19kZXZpY2VfcmVtb3ZlIGlzIG5vdwo+IGxpYnhsX19pbml0aWF0ZV9kZXZpY2Vf
cmVtb3ZlLgo+Cj4gQWxzbyBjYW4geW91IHBsZWFzZSBhcnJhbmdlIHRvIHVzZSAiZ290byBvdXQi
IHN0eWxlIGVycm9yIGhhbmRsaW5nID8KPgo+IEVnIHNvbWV0aGluZyBsaWtlOgo+Cj4gwqArIMKg
IMKgIHhzX3RyYW5zYWN0aW9uX3QgdCA9IDA7Cj4gwqAgwqAuLi4KPiDCoCDCoG91dDoKPiDCoCsg
wqAgwqAgaWYgKHQpIHhzX3RyYW5zYWN0aW9uX2VuZChjdHgtPnhzaCwgdCwgMCk7Cj4gwqAgwqAg
wqAgZGV2aWNlX3JlbW92ZV9jbGVhbnVwKGdjLCBhb3JtKTsKCkkgd2lsbCBjb21taXQgYW4gdXBk
YXRlZCB2ZXJzaW9uIG9mIHRoaXMgcGF0Y2ggd2l0aCBteSBob3RwbHVnIHNlcmllcywKdGhhdCBt
YXRjaGVzIHRoZSBjdXJyZW50IHN0YXRlIG9mIGxpYnhsX19pbml0aWF0ZV9kZXZpY2VfcmVtb3Zl
LgoKPgo+IFRCSCB0aGUgbWVhdCBvZiB0aGlzIGZ1bmN0aW9uIGlzIGluIGdlbmVyYWwgcmF0aGVy
IHVucmVjb25zdHJ1Y3RlZC4KPiBMb3RzIG9mIHVuY2hlY2tlZCB4c193cml0ZSBldGMuIMKgSSBk
b24ndCBrbm93IGlmIHlvdSB3YW50IHRvIGZpeCB0aGF0Cj4gd2hpbGUgeW91J3JlIHRoZXJlLiDC
oEkgd2ltcGVkIG91dCBvbiBkb2luZyB0aGF0IGluIG15IHJlY2VudCBldmVudAo+IHNlcmllcy4g
wqBVcCB0byB5b3UuCgpXaWxsIGRlY2lkZSB0aGF0IGxhdGVyLCBkZXBlbmRpbmcgb24gdGhlIHRp
bWUgZnJhbWUuCgo+IFJlYWxseSB3ZSBzaG91bGQgaGF2ZSBzb21lIGtpbmQgb2YgbW9yZSBjb29r
ZWQgeGVuc3RvcmUgdHJhbnNhY3Rpb24KPiBhcnJhbmdlbWVudHMsIHByb2JhYmx5IGluIHRoZSBn
YywgYW5kIGNlcnRhaW5seSB3aXRoIGEgc3VpdGFibGUgbG9vcAo+IG1hY3JvIHNvIHdlIGNhbiBz
YXk6Cj4gwqBJTl9YRU5TVE9SRV9UUkFOU0FDVElPTiB7Cj4gwqAgwqAgwqByZWFkLCB3cml0ZSwg
ZXRjLgo+IMKgfQo+IEJ1dCB0aGF0J3MgYSB0YXNrIGZvciBhbm90aGVyIGRheSBhbmQgaXQncyBu
b3Qgb24gdGhlIGNyaXRpY2FsIHBhdGgKPiBmb3IgNC4yIHNvIEknbSBwdXR0aW5nIGl0IG9mZi4K
CkFsc28gSSd2ZSBmb3VuZCBteXNlbGYgdXNpbmcgYSBsb3QgYSBjb25zdHJ1Y3Rpb24gbGlrZSB0
aGUgZm9sbG93aW5nOgoKLSBjaGVjayB4ZW5zdG9yZSBwYXRoCi0gSWYgcGF0aCB2YWx1ZSBpcyBk
aWZmZXJlbnQgdGhhbiB4Ci0gU2V0IHVwIGEgd2F0Y2gKLSBXYWl0IGZvciBldmVudHMuCgpBbmQg
SSdtIGFmcmFpZCBpdCdzIG5vdCBjb25jdXJyZW50IHNhZmUsIHNpbmNlIHNvbWVvbmUgY2FuIHBl
cmZvcm0gYQpidW5jaCBvZiB4ZW5zdG9yZSBjaGFuZ2VzIGluIHRoZSBzcGFjZSBiZXR3ZWVuIHNl
dHRpbmcgdGhlIHdhdGNoLCBhbmQKd2FpdCBmb3IgZXZlbnRzLiBUaGUgd2F0Y2hlciB3aWxsIG9u
bHkgZ2V0IG5vdGlmaWVkIG9mIHRoZSBsYXN0CnhlbnN0b3JlIGNoYW5nZSwgYnV0IG5vdCBhbGwg
Y2hhbmdlcyB0aGF0IGhhcHBlbmVkIGJldHdlZW4uCgo+IFRoYW5rcywKPiBJYW4uCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29t
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:55:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmRC-00062i-LR; Tue, 21 Feb 2012 09:55:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmRB-00062W-UZ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:55:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329818103!14818961!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10011 invoked from network); 21 Feb 2012 09:55:03 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:55:03 -0000
Received: by wgbdr13 with SMTP id dr13so4852229wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 01:55:03 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr30249576wib.3.1329818103123 (num_hops
	= 1); Tue, 21 Feb 2012 01:55:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=cc8TEjlSQ36aY5b9lfwT8arcJ54I6NoiCKZQrgPeNmg=;
	b=hkJw1oJ/mQfxibWvSEjM+ussVwXjUsfwtp0C84tpKTlcNB6ZF04NbfMNQY9Nvyw6RN
	pmhiY0NtERrlkYXHlDcVe9MXEOO5rwfApn9HPzeMZUyXjarONOY1RfsU1QA3Qpxoqk62
	vijJabUmTVbsP9VY41Lj+fCKX9eWTH/XK7Tjg=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr25225742wib.3.1329818103059; Tue,
	21 Feb 2012 01:55:03 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 01:55:03 -0800 (PST)
In-Reply-To: <20290.28675.613981.325668@mariner.uk.xensource.com>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
	<alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
	<20290.28675.613981.325668@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 10:55:03 +0100
X-Google-Sender-Auth: ajsOCBY6ad0WpMe2saHkPU59Y6k
Message-ID: <CAPLaKK4sw=hHD2Rk6a=HMhE9Q+5-wsNZ95dQuA_oit_-q-BvHA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIwIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBTdGVm
YW5vIFN0YWJlbGxpbmkgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFtQQVRDSF0gcWVtdTogcmVh
Y3QgdG8gWGVuYnVzU3RhdGVDbG9zaW5nIik6Cj4+IE9uIE1vbiwgMTYgSmFuIDIwMTIsIFJvZ2Vy
IFBhdSBNb25uZSB3cm90ZToKPj4gPiBRZW11IHdhcyBub3QgcmVhY3Rpbmcgd2hlbiBzZXR0aW5n
IHhlbnN0b3JlIHN0YXRlIG9mIGEgZGV2aWNlIHRvCj4+ID4gWGVuYnVzU3RhdGVDbG9zaW5nICg1
KS4gVGhpcyBwYXRjaCBtYWtlcyBxZW11IHJlYWN0IHRvIHRoaXMgc3RhdGUgYW5kCj4+ID4gY2xv
c2UgdGhlIGFwcHJvcGlhdGUgZGV2aWNlLgo+PiA+Cj4+ID4gU2lnbmVkLW9mZi1ieTogUm9nZXIg
UGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gUGxlYXNlIHNlbmQgYSB2
ZXJzaW9uIG9mIHRoaXMgcGF0Y2ggYWdhaW5zdCB1cHN0cmVhbSBxZW11IGFuZCBDQwo+PiBxZW11
LWRldmVsIGFzIHdlbGwuCj4KPiBXZSBhcmUgdHJ5aW5nIHRvIGF2b2lkIGFkZGluZyBuZXcgY29k
ZSBhbmQgbmV3IGZlYXR1cmVzIHRvCj4gcWVtdS14ZW4tdW5zdGFibGUuIMKgQ2FuIHlvdSBleHBs
YWluIHdoYXQgdGhlIHByYWN0aWNhbCBpbXBhY3Qgb2YgdGhpcwo+IHBhdGNoIGlzID8gwqBXaGVu
IGlzIGl0IG5lZWRlZCBhbmQgd2hhdCBkb2Vzbid0IHdvcmsgd2l0aG91dCBpdCA/CgpUaGlzIGlz
IG5vdCByZWFsbHkgbmVlZGVkIG5vdywgcWRpc2sgYmFja2VuZHMgYXJlIGRlc3Ryb3llZCB0aGUg
aGFyZAp3YXkgKHJlbW92ZSB4ZW5zdG9yZSBiYWNrZW5kIGFuZCBzaWduYWwgcWVtdS1kbSkuIFRo
ZSBub3JtYWwgcHJvY2Vzcwpmb3IgZGVzdHJveWluZyBhIGJhY2tlbmQgaG93ZXZlciBzaG91bGQg
YmUgdG8gd2FpdCBmb3IgaXQgdG8gcmVhY2gKc3RhdGUgNiwgYW5kIHFlbXUtZG0gYmFja2VuZCBp
bXBsZW1lbnRhdGlvbiBkb2Vzbid0IHJlYWN0IHRvIHNldHRpbmcKYmFja2VuZCBzdGF0ZSB0byA1
LCBhcyBtb3N0IGJhY2tlbmRzIGRvLiBUaGlzIHBhdGNoIHdhcyB0cnlpbmcgdG8gZml4CnRoaXMg
YnkgbWFraW5nIHFlbXUtZG0gYXdhcmUgb2YgYSBjbG9zZSByZXF1ZXN0LgoKPiBIYXMgdGhlIHRo
aW5nIHdoaWNoIGRvZXNuJ3Qgd29yayB3aXRob3V0IGl0IGV2ZXIgd29ya2VkIGJlZm9yZSBkZXN0
cm95aW5nCgpBcyBzYWlkIGJlZm9yZSwgZGV2aWNlIHNodXRkb3duL2Rlc3RydWN0aW9uIGluIGxp
YnhsIGlzIGZvcmNlZCByaWdodApub3csIHRoZSBmcm9udGVuZC9iYWNrZW5kIGlzIGRlc3Ryb3ll
ZCBhbmQgdGhlIGRldmljZSBtb2RlbCBzaWduYWxlZAooaWYgdGhlcmUncyBhIGRldmljZSBtb2Rl
bCkuIFRoaXMgd2lsbCBjaGFuZ2Ugd2l0aCB0aGUgaG90cGx1Zy9kZXZpY2UKZG9tYWluIHNlcmll
cywgc2luY2Ugd2UgY2FuIG5vIGxvbmdlciBkZXN0cm95IHRoZSBiYWNrZW5kIHhlbnN0b3JlCmVu
dHJpZXMgYmVmb3JlIHVucGx1Z2dpbmcgdGhlIGRldmljZSBiZWNhdXNlIHdlIGhhdmUgdG8gY2Fs
bCBob3RwbHVnCnNjcmlwdHMgd2hlbiB0aGUgZGV2aWNlIGhhcyByZWFjaGVkIGEgY2xvc2VkIHN0
YXRlICg2KS4KCldlIGNvdWxkIG1ha2UgYW4gZXhjZXB0aW9uIHdpdGggcWVtdSBkZXZpY2VzLCBi
dXQgSSB3b3VsZCBwcmVmZXIgdG8KYXZvaWQgdGhhdCBhbmQgdXNlIHRoZSBzYW1lIHVucGx1ZyBw
YXRoIGZvciBhbGwgZGV2aWNlIHR5cGVzLgoKPiBUaGFua3MsCj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:55:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmRC-00062i-LR; Tue, 21 Feb 2012 09:55:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmRB-00062W-UZ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:55:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329818103!14818961!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10011 invoked from network); 21 Feb 2012 09:55:03 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:55:03 -0000
Received: by wgbdr13 with SMTP id dr13so4852229wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 01:55:03 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr30249576wib.3.1329818103123 (num_hops
	= 1); Tue, 21 Feb 2012 01:55:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=cc8TEjlSQ36aY5b9lfwT8arcJ54I6NoiCKZQrgPeNmg=;
	b=hkJw1oJ/mQfxibWvSEjM+ussVwXjUsfwtp0C84tpKTlcNB6ZF04NbfMNQY9Nvyw6RN
	pmhiY0NtERrlkYXHlDcVe9MXEOO5rwfApn9HPzeMZUyXjarONOY1RfsU1QA3Qpxoqk62
	vijJabUmTVbsP9VY41Lj+fCKX9eWTH/XK7Tjg=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr25225742wib.3.1329818103059; Tue,
	21 Feb 2012 01:55:03 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 01:55:03 -0800 (PST)
In-Reply-To: <20290.28675.613981.325668@mariner.uk.xensource.com>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
	<alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
	<20290.28675.613981.325668@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 10:55:03 +0100
X-Google-Sender-Auth: ajsOCBY6ad0WpMe2saHkPU59Y6k
Message-ID: <CAPLaKK4sw=hHD2Rk6a=HMhE9Q+5-wsNZ95dQuA_oit_-q-BvHA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIwIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBTdGVm
YW5vIFN0YWJlbGxpbmkgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFtQQVRDSF0gcWVtdTogcmVh
Y3QgdG8gWGVuYnVzU3RhdGVDbG9zaW5nIik6Cj4+IE9uIE1vbiwgMTYgSmFuIDIwMTIsIFJvZ2Vy
IFBhdSBNb25uZSB3cm90ZToKPj4gPiBRZW11IHdhcyBub3QgcmVhY3Rpbmcgd2hlbiBzZXR0aW5n
IHhlbnN0b3JlIHN0YXRlIG9mIGEgZGV2aWNlIHRvCj4+ID4gWGVuYnVzU3RhdGVDbG9zaW5nICg1
KS4gVGhpcyBwYXRjaCBtYWtlcyBxZW11IHJlYWN0IHRvIHRoaXMgc3RhdGUgYW5kCj4+ID4gY2xv
c2UgdGhlIGFwcHJvcGlhdGUgZGV2aWNlLgo+PiA+Cj4+ID4gU2lnbmVkLW9mZi1ieTogUm9nZXIg
UGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gUGxlYXNlIHNlbmQgYSB2
ZXJzaW9uIG9mIHRoaXMgcGF0Y2ggYWdhaW5zdCB1cHN0cmVhbSBxZW11IGFuZCBDQwo+PiBxZW11
LWRldmVsIGFzIHdlbGwuCj4KPiBXZSBhcmUgdHJ5aW5nIHRvIGF2b2lkIGFkZGluZyBuZXcgY29k
ZSBhbmQgbmV3IGZlYXR1cmVzIHRvCj4gcWVtdS14ZW4tdW5zdGFibGUuIMKgQ2FuIHlvdSBleHBs
YWluIHdoYXQgdGhlIHByYWN0aWNhbCBpbXBhY3Qgb2YgdGhpcwo+IHBhdGNoIGlzID8gwqBXaGVu
IGlzIGl0IG5lZWRlZCBhbmQgd2hhdCBkb2Vzbid0IHdvcmsgd2l0aG91dCBpdCA/CgpUaGlzIGlz
IG5vdCByZWFsbHkgbmVlZGVkIG5vdywgcWRpc2sgYmFja2VuZHMgYXJlIGRlc3Ryb3llZCB0aGUg
aGFyZAp3YXkgKHJlbW92ZSB4ZW5zdG9yZSBiYWNrZW5kIGFuZCBzaWduYWwgcWVtdS1kbSkuIFRo
ZSBub3JtYWwgcHJvY2Vzcwpmb3IgZGVzdHJveWluZyBhIGJhY2tlbmQgaG93ZXZlciBzaG91bGQg
YmUgdG8gd2FpdCBmb3IgaXQgdG8gcmVhY2gKc3RhdGUgNiwgYW5kIHFlbXUtZG0gYmFja2VuZCBp
bXBsZW1lbnRhdGlvbiBkb2Vzbid0IHJlYWN0IHRvIHNldHRpbmcKYmFja2VuZCBzdGF0ZSB0byA1
LCBhcyBtb3N0IGJhY2tlbmRzIGRvLiBUaGlzIHBhdGNoIHdhcyB0cnlpbmcgdG8gZml4CnRoaXMg
YnkgbWFraW5nIHFlbXUtZG0gYXdhcmUgb2YgYSBjbG9zZSByZXF1ZXN0LgoKPiBIYXMgdGhlIHRo
aW5nIHdoaWNoIGRvZXNuJ3Qgd29yayB3aXRob3V0IGl0IGV2ZXIgd29ya2VkIGJlZm9yZSBkZXN0
cm95aW5nCgpBcyBzYWlkIGJlZm9yZSwgZGV2aWNlIHNodXRkb3duL2Rlc3RydWN0aW9uIGluIGxp
YnhsIGlzIGZvcmNlZCByaWdodApub3csIHRoZSBmcm9udGVuZC9iYWNrZW5kIGlzIGRlc3Ryb3ll
ZCBhbmQgdGhlIGRldmljZSBtb2RlbCBzaWduYWxlZAooaWYgdGhlcmUncyBhIGRldmljZSBtb2Rl
bCkuIFRoaXMgd2lsbCBjaGFuZ2Ugd2l0aCB0aGUgaG90cGx1Zy9kZXZpY2UKZG9tYWluIHNlcmll
cywgc2luY2Ugd2UgY2FuIG5vIGxvbmdlciBkZXN0cm95IHRoZSBiYWNrZW5kIHhlbnN0b3JlCmVu
dHJpZXMgYmVmb3JlIHVucGx1Z2dpbmcgdGhlIGRldmljZSBiZWNhdXNlIHdlIGhhdmUgdG8gY2Fs
bCBob3RwbHVnCnNjcmlwdHMgd2hlbiB0aGUgZGV2aWNlIGhhcyByZWFjaGVkIGEgY2xvc2VkIHN0
YXRlICg2KS4KCldlIGNvdWxkIG1ha2UgYW4gZXhjZXB0aW9uIHdpdGggcWVtdSBkZXZpY2VzLCBi
dXQgSSB3b3VsZCBwcmVmZXIgdG8KYXZvaWQgdGhhdCBhbmQgdXNlIHRoZSBzYW1lIHVucGx1ZyBw
YXRoIGZvciBhbGwgZGV2aWNlIHR5cGVzLgoKPiBUaGFua3MsCj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:59:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmVI-0006Cj-Cj; Tue, 21 Feb 2012 09:59: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 1RzmVG-0006CZ-TN
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:59:23 +0000
Received: from [85.158.139.83:64782] by server-9.bemta-5.messagelabs.com id
	B7/27-30171-AFA634F4; Tue, 21 Feb 2012 09:59:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329818359!15391829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23830 invoked from network); 21 Feb 2012 09:59:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 09:59:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 09:59:19 +0000
Message-ID: <1329818358.25232.64.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 21 Feb 2012 09:59:18 +0000
In-Reply-To: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 14:48 +0000, George Dunlap wrote:
> On Mon, Feb 20, 2012 at 11:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Feb 20, George Dunlap wrote:
> >
> >> Start-of-day:
> >>  xenpaging off: Set balloon target to M, use PoD
> >>  xenpaging on: ??
> >>  xenpaging delay: Set balloon target to M, use PoD.  Wait
> >> $pagingdelayboot seconds, if target not reached, set paging?
> >
> > Is the delay required?
> > If paging and PoD target is M, xenpaging will do nothing because the
> > guest can not exceed M (it will crash with OOM).
> 
> Ah, of course -- you don't need paging because it already has M
> memory.  Forgot about that.
> 
> It would be nice, of course, if the pager could act as a back-fill for
> these PoD pages; but that's another project, I think.
> 
> So that leaves us with:
> 
> maxmem=X
> memory=M
> xenpaging=[off|on|delay]
> pagingdelay=60

FWIW these two can be expressed as:
xenpaging=[off|on]
pagingdelay=[0|60]

(and lets drop the "xen" prefix)

[...]
> xl mem-set domain M
>  xenpaging off: Set balloon target to M
>  xenpaging on: Set paging target to M
>  xenpaging delay: Set balloon target to M, and wait for actual memory
> to reach M.  If it hasn't reached it by $paging_delay seconds, set
> balloon target to M.

Did you mean "paging target" the second time you said "balloon target"
in this one? I'll assume so. I would also suggest 
	s/If it hasn't reached it by/After/
since I think that will simplify things somewhat and setting page target
to M makes no odds if the guest has ballooned to M.

I don't really like mem-set having such completely different behaviour
depending on whether paging is on or off.

As you described before having paging on == set paging and balloon
target to M results in fairly suboptimal behaviour and the name would
also lead to people thinking it is the one they should use.

So why not make the "on" case the same as your "delay" case and do away
with the distinction? If advanced users really want what you describe as
"on" then they can set the delay to 0.

If the paging daemon could be start/stopped on demand (rather than being
a domain build time choice) we could even consider making paging the
default.

> xl mem-balloon-set domain M
>  Set balloon target to M
> xl mem-paging-set domain M
>  Set paging target to M

How do these interact with mem-set. Especially in the delay case?

e.g. would mem-paging-set disable the after delay behaviour of mem-set?
Should we have "mem-paging-set domain auto" to turn that back on?

We also need to consider the behaviour of mem-set to increase things.
Obviously you don't want to leave paging target set to the smaller value
for a minute after setting the balloon target. I think we want to set it
straight away in that case, if not before setting the balloon.

How about the following? I've tried to include the "user facing"
description as well as the actual implementation. I think the "user
facing" portion is actually where we disagree but I also suspect that we
may not actually disagree -- it's just that we are talking in terms of
implementation so we don't see that the user facing interface is the
same in what we are each thinking of ;-)

maxmem=X			# maximum RAM the domain can ever see
memory=M			# current amount of RAM seen by the domain
paging=[off|on]			# allow the amount of memory a guest 
				# thinks it has to differ from the
				# amount actually available to it (its
				# "footprint")
pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
				# "footprint" for guests which do not
				# voluntarily obey changes to memory=M 
pagingdelay=60			# amount of time to give a guest to 
				# voluntarily comply before enforcing a 
				# footprint

xl mem-set domain M
        Sets the amount of RAM which the guest believes it has available
        to M. The guest should arrange to use only that much RAM and
        return the rest to the hypervisor (e.g. by using a balloon
        driver). If the guest does not do so then the host may use
        technical means to enforce the guest's footprint of M. The guest
        may suffer a performance penalty for this enforcement.

	paging off:	set balloon target to M.
	paging on: 	set balloon target to M.
			if pagingauto:
				wait delay IFF new target < old
				set paging target to M
				support -t <delay> to override default?

xl mem-paging-set domain N
        Overrides the amount of RAM which the guest actually has
        available (its "footprint") to N. The host will use technical
        means to continue to provide the illusion to the guest that it
        has memory=M (as adjusted by mem-set). There may be a
        performance penalty for this.
        
	paging off:	error
	paging on:	set paging target
			set pagingauto=off

xl mem-paging-set domain auto
        Automatically manage paging. Request that the guest uses
        memory=M (current value of memory, as adjusted by mem-set)
        enforced when the guest is uncooperative (as described in
        "mem-set")
        
	paging off:	error
	paging on:	set paging target to M
			set pagingauto=on

No need for a separate balloon-set since that == mem-set with
pagingauto=off.

Perhaps a separate "mem-paging-set domain manual" would be handy to
enable that mode without having to remember M so you can use it as N 

We could consider making "mem-paging-set domain N" fail with an error
unless you previously set manual, to prevent users accidentally
disabling the recommended automatic behaviour e.g. by typing
mem-paging-set when they mean mem-set.

I liked Andres' suggestions of footprint as a term here BTW so I would
prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
not 100% on that). If we don't have balloon-set then avoiding the name
paging seems like a good idea too. Other possible names might be
"mem-override-set" or something.

I don't really like the extra configuration option for pagingauto but I
think pagingauto and mem-{paging,footprint}-set should be considered
advanced options and by default we would recommend that folks just set
"paging=on" and use mem-set. It should be reasonably clear to users that
if they disable auto mode then they are expected to understand what is
happening sufficiently to make their own choices about paging targets
etc.

We can probably think of more useful algorithms than raw pagingdelay
(i.e. based on rate of progress or something) which might be useful for
larger domains making large changes to the balloon -- lets leave that
aside for now though. Likewise "auto" mode allows scope for us to
implement improved algorithms in the future.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 09:59:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 09:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmVI-0006Cj-Cj; Tue, 21 Feb 2012 09:59: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 1RzmVG-0006CZ-TN
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 09:59:23 +0000
Received: from [85.158.139.83:64782] by server-9.bemta-5.messagelabs.com id
	B7/27-30171-AFA634F4; Tue, 21 Feb 2012 09:59:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329818359!15391829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23830 invoked from network); 21 Feb 2012 09:59:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 09:59:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 09:59:19 +0000
Message-ID: <1329818358.25232.64.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 21 Feb 2012 09:59:18 +0000
In-Reply-To: <CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 14:48 +0000, George Dunlap wrote:
> On Mon, Feb 20, 2012 at 11:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Feb 20, George Dunlap wrote:
> >
> >> Start-of-day:
> >>  xenpaging off: Set balloon target to M, use PoD
> >>  xenpaging on: ??
> >>  xenpaging delay: Set balloon target to M, use PoD.  Wait
> >> $pagingdelayboot seconds, if target not reached, set paging?
> >
> > Is the delay required?
> > If paging and PoD target is M, xenpaging will do nothing because the
> > guest can not exceed M (it will crash with OOM).
> 
> Ah, of course -- you don't need paging because it already has M
> memory.  Forgot about that.
> 
> It would be nice, of course, if the pager could act as a back-fill for
> these PoD pages; but that's another project, I think.
> 
> So that leaves us with:
> 
> maxmem=X
> memory=M
> xenpaging=[off|on|delay]
> pagingdelay=60

FWIW these two can be expressed as:
xenpaging=[off|on]
pagingdelay=[0|60]

(and lets drop the "xen" prefix)

[...]
> xl mem-set domain M
>  xenpaging off: Set balloon target to M
>  xenpaging on: Set paging target to M
>  xenpaging delay: Set balloon target to M, and wait for actual memory
> to reach M.  If it hasn't reached it by $paging_delay seconds, set
> balloon target to M.

Did you mean "paging target" the second time you said "balloon target"
in this one? I'll assume so. I would also suggest 
	s/If it hasn't reached it by/After/
since I think that will simplify things somewhat and setting page target
to M makes no odds if the guest has ballooned to M.

I don't really like mem-set having such completely different behaviour
depending on whether paging is on or off.

As you described before having paging on == set paging and balloon
target to M results in fairly suboptimal behaviour and the name would
also lead to people thinking it is the one they should use.

So why not make the "on" case the same as your "delay" case and do away
with the distinction? If advanced users really want what you describe as
"on" then they can set the delay to 0.

If the paging daemon could be start/stopped on demand (rather than being
a domain build time choice) we could even consider making paging the
default.

> xl mem-balloon-set domain M
>  Set balloon target to M
> xl mem-paging-set domain M
>  Set paging target to M

How do these interact with mem-set. Especially in the delay case?

e.g. would mem-paging-set disable the after delay behaviour of mem-set?
Should we have "mem-paging-set domain auto" to turn that back on?

We also need to consider the behaviour of mem-set to increase things.
Obviously you don't want to leave paging target set to the smaller value
for a minute after setting the balloon target. I think we want to set it
straight away in that case, if not before setting the balloon.

How about the following? I've tried to include the "user facing"
description as well as the actual implementation. I think the "user
facing" portion is actually where we disagree but I also suspect that we
may not actually disagree -- it's just that we are talking in terms of
implementation so we don't see that the user facing interface is the
same in what we are each thinking of ;-)

maxmem=X			# maximum RAM the domain can ever see
memory=M			# current amount of RAM seen by the domain
paging=[off|on]			# allow the amount of memory a guest 
				# thinks it has to differ from the
				# amount actually available to it (its
				# "footprint")
pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
				# "footprint" for guests which do not
				# voluntarily obey changes to memory=M 
pagingdelay=60			# amount of time to give a guest to 
				# voluntarily comply before enforcing a 
				# footprint

xl mem-set domain M
        Sets the amount of RAM which the guest believes it has available
        to M. The guest should arrange to use only that much RAM and
        return the rest to the hypervisor (e.g. by using a balloon
        driver). If the guest does not do so then the host may use
        technical means to enforce the guest's footprint of M. The guest
        may suffer a performance penalty for this enforcement.

	paging off:	set balloon target to M.
	paging on: 	set balloon target to M.
			if pagingauto:
				wait delay IFF new target < old
				set paging target to M
				support -t <delay> to override default?

xl mem-paging-set domain N
        Overrides the amount of RAM which the guest actually has
        available (its "footprint") to N. The host will use technical
        means to continue to provide the illusion to the guest that it
        has memory=M (as adjusted by mem-set). There may be a
        performance penalty for this.
        
	paging off:	error
	paging on:	set paging target
			set pagingauto=off

xl mem-paging-set domain auto
        Automatically manage paging. Request that the guest uses
        memory=M (current value of memory, as adjusted by mem-set)
        enforced when the guest is uncooperative (as described in
        "mem-set")
        
	paging off:	error
	paging on:	set paging target to M
			set pagingauto=on

No need for a separate balloon-set since that == mem-set with
pagingauto=off.

Perhaps a separate "mem-paging-set domain manual" would be handy to
enable that mode without having to remember M so you can use it as N 

We could consider making "mem-paging-set domain N" fail with an error
unless you previously set manual, to prevent users accidentally
disabling the recommended automatic behaviour e.g. by typing
mem-paging-set when they mean mem-set.

I liked Andres' suggestions of footprint as a term here BTW so I would
prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
not 100% on that). If we don't have balloon-set then avoiding the name
paging seems like a good idea too. Other possible names might be
"mem-override-set" or something.

I don't really like the extra configuration option for pagingauto but I
think pagingauto and mem-{paging,footprint}-set should be considered
advanced options and by default we would recommend that folks just set
"paging=on" and use mem-set. It should be reasonably clear to users that
if they disable auto mode then they are expected to understand what is
happening sufficiently to make their own choices about paging targets
etc.

We can probably think of more useful algorithms than raw pagingdelay
(i.e. based on rate of progress or something) which might be useful for
larger domains making large changes to the balloon -- lets leave that
aside for now though. Likewise "auto" mode allows scope for us to
implement improved algorithms in the future.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1RzmX2-0006P3-2h; Tue, 21 Feb 2012 10:01:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmX0-0006OW-Du
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:01:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329818398!61920516!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18328 invoked from network); 21 Feb 2012 09:59:58 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:59:58 -0000
Received: by werh12 with SMTP id h12so4881760wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 02:01:04 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr30300092wib.3.1329818464304 (num_hops
	= 1); Tue, 21 Feb 2012 02:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=DPXBgyWfF2IPAdG5I6+47XpIMsNQix+sipiTTQvNHk0=;
	b=FtrgfV6CgRTw/Mii3qYGwi/qTz51SYqfdJS/j/4TC1v3+sWY7bnKzoQjWPg+NrE8J4
	Lu5+qwgMq8uIUlAXTZr9Cv19BNqM2ZFsXHwAkYqOWtkOVbWYOvR2fbPzN4kDisxQ15Ek
	UODLstQP77Xi+bswEqzcIQBN+JCdFUTPTbz1U=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr25268499wib.3.1329818464262; Tue,
	21 Feb 2012 02:01:04 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 02:01:04 -0800 (PST)
In-Reply-To: <20290.37354.897419.528245@mariner.uk.xensource.com>
References: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
	<20290.34518.441248.907891@mariner.uk.xensource.com>
	<20290.37354.897419.528245@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 11:01:04 +0100
X-Google-Sender-Auth: 1qXmTTuynJDvkMtMtqu_YeVax80
Message-ID: <CAPLaKK4baTTMShieJzk8+ZmHRV_UTYNpE-o01U8iJX441ouGVw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Hold off on Config.mk etc. patches (Re: [PATCH]
 build: add autoconf to replace custom checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIwIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBDYW4g
d2UgcGxlYXNlIGhvbGQgb2ZmIG9uIGFwcGx5aW5nIGFueSBmdXJ0aGVyIG5vbnRyaXZpYWwgQ29u
ZmlnLm1rCj4gY2hhbmdlcyBwZW5kaW5nIFJvZ2VyJ3MgYXV0b2NvbmYgc2VyaWVzID8gwqBSb2dl
cidzIHNlcmllcyBzZWVtcyB0bwo+IGhhdmUgYml0cm90dGVkIGFnYWluIGV2ZW4gdGhvdWdoIEkg
YXNrZWQgaGltIHRvIHJlYmFzZSBpdCBqdXN0IGVhcmxpZXIKPiB0aGlzIGFmdGVybm9vbi4KCkkn
dmUgcG9zdGVkIHRoZSBwYXRjaCwgdGhpcyB0aW1lIHdpdGhvdXQgY29uZmlnLnN1YiwgY29uZmln
Lmd1ZXNzIG9yCnRoZSBnZW5lcmF0ZWQgY29uZmlndXJlIHNjcmlwdC4gWW91IHdpbGwgaGF2ZSB0
byBjb3B5IGNvbmZpZy5zdWIgYW5kCmNvbmZpZy5ndWVzcyBmcm9tIHlvdXIgYXV0b21ha2UgdG8g
dG9vbHMvLCBydW4gYXV0b2dlbi5zaCBhbmQgYWRkCmNvbmZpZ3VyZSwgdG9vbHMvY29uZmlndXJl
LCB0b29scy9jb25maWcuc3ViIGFuZCB0b29scy9jb25maWcuZ3Vlc3MKYmVmb3JlIGNvbW1pdHRp
bmcgdGhlIHBhdGNoLgoKVGhhbmtzLCBSb2dlci4KCj4gV2UnbGwgbmVlZCBhIGRheSBvciB0d28g
YmVjYXVzZSBJIG5lZWQgdG8gbWFrZSBhbiBhc3NvY2lhdGVkIHRlc3QKPiBzeXN0ZW0gY2hhbmdl
Lgo+Cj4gVGhhbmtzLAo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1RzmX2-0006P3-2h; Tue, 21 Feb 2012 10:01:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmX0-0006OW-Du
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:01:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329818398!61920516!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18328 invoked from network); 21 Feb 2012 09:59:58 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 09:59:58 -0000
Received: by werh12 with SMTP id h12so4881760wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 02:01:04 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr30300092wib.3.1329818464304 (num_hops
	= 1); Tue, 21 Feb 2012 02:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=DPXBgyWfF2IPAdG5I6+47XpIMsNQix+sipiTTQvNHk0=;
	b=FtrgfV6CgRTw/Mii3qYGwi/qTz51SYqfdJS/j/4TC1v3+sWY7bnKzoQjWPg+NrE8J4
	Lu5+qwgMq8uIUlAXTZr9Cv19BNqM2ZFsXHwAkYqOWtkOVbWYOvR2fbPzN4kDisxQ15Ek
	UODLstQP77Xi+bswEqzcIQBN+JCdFUTPTbz1U=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr25268499wib.3.1329818464262; Tue,
	21 Feb 2012 02:01:04 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 02:01:04 -0800 (PST)
In-Reply-To: <20290.37354.897419.528245@mariner.uk.xensource.com>
References: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
	<20290.34518.441248.907891@mariner.uk.xensource.com>
	<20290.37354.897419.528245@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 11:01:04 +0100
X-Google-Sender-Auth: 1qXmTTuynJDvkMtMtqu_YeVax80
Message-ID: <CAPLaKK4baTTMShieJzk8+ZmHRV_UTYNpE-o01U8iJX441ouGVw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Hold off on Config.mk etc. patches (Re: [PATCH]
 build: add autoconf to replace custom checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIwIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBDYW4g
d2UgcGxlYXNlIGhvbGQgb2ZmIG9uIGFwcGx5aW5nIGFueSBmdXJ0aGVyIG5vbnRyaXZpYWwgQ29u
ZmlnLm1rCj4gY2hhbmdlcyBwZW5kaW5nIFJvZ2VyJ3MgYXV0b2NvbmYgc2VyaWVzID8gwqBSb2dl
cidzIHNlcmllcyBzZWVtcyB0bwo+IGhhdmUgYml0cm90dGVkIGFnYWluIGV2ZW4gdGhvdWdoIEkg
YXNrZWQgaGltIHRvIHJlYmFzZSBpdCBqdXN0IGVhcmxpZXIKPiB0aGlzIGFmdGVybm9vbi4KCkkn
dmUgcG9zdGVkIHRoZSBwYXRjaCwgdGhpcyB0aW1lIHdpdGhvdXQgY29uZmlnLnN1YiwgY29uZmln
Lmd1ZXNzIG9yCnRoZSBnZW5lcmF0ZWQgY29uZmlndXJlIHNjcmlwdC4gWW91IHdpbGwgaGF2ZSB0
byBjb3B5IGNvbmZpZy5zdWIgYW5kCmNvbmZpZy5ndWVzcyBmcm9tIHlvdXIgYXV0b21ha2UgdG8g
dG9vbHMvLCBydW4gYXV0b2dlbi5zaCBhbmQgYWRkCmNvbmZpZ3VyZSwgdG9vbHMvY29uZmlndXJl
LCB0b29scy9jb25maWcuc3ViIGFuZCB0b29scy9jb25maWcuZ3Vlc3MKYmVmb3JlIGNvbW1pdHRp
bmcgdGhlIHBhdGNoLgoKVGhhbmtzLCBSb2dlci4KCj4gV2UnbGwgbmVlZCBhIGRheSBvciB0d28g
YmVjYXVzZSBJIG5lZWQgdG8gbWFrZSBhbiBhc3NvY2lhdGVkIHRlc3QKPiBzeXN0ZW0gY2hhbmdl
Lgo+Cj4gVGhhbmtzLAo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:04:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmZc-0006Zl-L2; Tue, 21 Feb 2012 10:03:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzmZb-0006ZI-0f
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:03:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329818624!12399079!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1642 invoked from network); 21 Feb 2012 10:03:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:03:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:03:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:03:43 +0000
Message-ID: <1329818622.25232.65.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 10:03:42 +0000
In-Reply-To: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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 Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
> 
> +echo "#!/bin/sh -e" >> configure
> +echo "cd tools && ./configure \$@" >> configure
> +chmod +x configure 

why not check this in as a script rather than generating it from
autogen.sh?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:04:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmZc-0006Zl-L2; Tue, 21 Feb 2012 10:03:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzmZb-0006ZI-0f
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:03:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329818624!12399079!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1642 invoked from network); 21 Feb 2012 10:03:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:03:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:03:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:03:43 +0000
Message-ID: <1329818622.25232.65.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 10:03:42 +0000
In-Reply-To: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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 Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
> 
> +echo "#!/bin/sh -e" >> configure
> +echo "cd tools && ./configure \$@" >> configure
> +chmod +x configure 

why not check this in as a script rather than generating it from
autogen.sh?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:05:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmai-0006fz-4K; Tue, 21 Feb 2012 10:05:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzmag-0006fN-71
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:04:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329818691!14228701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13930 invoked from network); 21 Feb 2012 10:04:52 -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;
	21 Feb 2012 10:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:04:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:04:51 +0000
Date: Tue, 21 Feb 2012 10:10:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20290.39907.912639.18195@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 Mon, 20 Feb 2012, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> > libxl: drop 8M slack for PV guests.
> > 
> > As far as I can tell this serves no purpose. I think it relates to the old
> > 8M to "account for backend allocations" which we used to add. This leaves a bit
> > of unpopulated space in the Pseudo-physical address space which can be used by
> > backends when mapping foreign memory. However 8M is not representative of that
> > any more and modern kernels do not operate in this way anyway.
> > 
> > I suspect an argument could be made for removing this from the libxl API
> > altogether but instead lets just set the overhead to 0.
> 
> I think this is plausible but I'd like to hear from Stefano, who iirc
> may have some knowledge about the reason for this 8Mb.

It comes from XenD (and XAPI too, if I recall correctly), see this
comment in tools/python/xen/xend/image.py:


class X86_Linux_ImageHandler(LinuxImageHandler):

    def buildDomain(self):
        # set physical mapping limit
        # add an 8MB slack to balance backend allocations.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:05:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmai-0006fz-4K; Tue, 21 Feb 2012 10:05:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzmag-0006fN-71
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:04:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329818691!14228701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13930 invoked from network); 21 Feb 2012 10:04:52 -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;
	21 Feb 2012 10:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:04:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:04:51 +0000
Date: Tue, 21 Feb 2012 10:10:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20290.39907.912639.18195@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 Mon, 20 Feb 2012, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> > libxl: drop 8M slack for PV guests.
> > 
> > As far as I can tell this serves no purpose. I think it relates to the old
> > 8M to "account for backend allocations" which we used to add. This leaves a bit
> > of unpopulated space in the Pseudo-physical address space which can be used by
> > backends when mapping foreign memory. However 8M is not representative of that
> > any more and modern kernels do not operate in this way anyway.
> > 
> > I suspect an argument could be made for removing this from the libxl API
> > altogether but instead lets just set the overhead to 0.
> 
> I think this is plausible but I'd like to hear from Stefano, who iirc
> may have some knowledge about the reason for this 8Mb.

It comes from XenD (and XAPI too, if I recall correctly), see this
comment in tools/python/xen/xend/image.py:


class X86_Linux_ImageHandler(LinuxImageHandler):

    def buildDomain(self):
        # set physical mapping limit
        # add an 8MB slack to balance backend allocations.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:07:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1RzmcU-0006po-Kc; Tue, 21 Feb 2012 10:06:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RzmcS-0006p8-F6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:06:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329818800!12399900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17998 invoked from network); 21 Feb 2012 10:06:40 -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;
	21 Feb 2012 10:06:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:06:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:06:39 +0000
Date: Tue, 21 Feb 2012 10:12:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202211011400.23091@kaball-desktop>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1321825165-1329819137=:23091"
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-1321825165-1329819137=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 20 Feb 2012, Shriram Rajagopalan wrote:
> On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>       rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resume"):
>       > libxl: support suspend_cancel in domain_resume
> 
> I get this:
> 
> libxl.c: In function 'libxl_domain_resume':
> libxl.c:315: error: implicit declaration of function 'libxl__domain_resume_device_model'
> 
> Did you compile this ?  Did you test it ?
> 
> 
> Yes I did.. Did you apply the previous patch in this series, that introduces the above (missing)  function ?
> 
> As I mentioned in the introductory email, these patches also depend on Stefano's XC_SAVE_ID_TOOLSTACK patches.
> 
> 01 Introduce a new save_id to save/restore toolstack specific extra
> 02 Read Qemu's physmap from xenstore and save it using toolstack_save.
> 03 Following the recent changes to upstream Qemu, the best monitor command
>     (removes qmp_migrate and introduces qmp_save)
> 
> 
> Then my patches:
> 03 libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 04 libxl: support suspend_cancel in domain_resume
> 05 libxl: refactor migrate_domain and generalize migrate_receive
> 06 libxl: resume instead of unpause on xl save -c
> 
> 01 libxl: Remus - suspend/postflush/commit callbacks
> 02 libxl: Remus - xl remus command
> 
> Currently, one of stefano's patches doesnt apply cleanly - the first one. It requires minor fix.
> Barring that, all the other patches mentioned above apply cleanly.
> 

I can rebase and resend if it is needed.
--8323329-1321825165-1329819137=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-1321825165-1329819137=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:07:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1RzmcU-0006po-Kc; Tue, 21 Feb 2012 10:06:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RzmcS-0006p8-F6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:06:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329818800!12399900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17998 invoked from network); 21 Feb 2012 10:06:40 -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;
	21 Feb 2012 10:06:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:06:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:06:39 +0000
Date: Tue, 21 Feb 2012 10:12:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202211011400.23091@kaball-desktop>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1321825165-1329819137=:23091"
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-1321825165-1329819137=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 20 Feb 2012, Shriram Rajagopalan wrote:
> On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>       rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resume"):
>       > libxl: support suspend_cancel in domain_resume
> 
> I get this:
> 
> libxl.c: In function 'libxl_domain_resume':
> libxl.c:315: error: implicit declaration of function 'libxl__domain_resume_device_model'
> 
> Did you compile this ?  Did you test it ?
> 
> 
> Yes I did.. Did you apply the previous patch in this series, that introduces the above (missing)  function ?
> 
> As I mentioned in the introductory email, these patches also depend on Stefano's XC_SAVE_ID_TOOLSTACK patches.
> 
> 01 Introduce a new save_id to save/restore toolstack specific extra
> 02 Read Qemu's physmap from xenstore and save it using toolstack_save.
> 03 Following the recent changes to upstream Qemu, the best monitor command
>     (removes qmp_migrate and introduces qmp_save)
> 
> 
> Then my patches:
> 03 libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 04 libxl: support suspend_cancel in domain_resume
> 05 libxl: refactor migrate_domain and generalize migrate_receive
> 06 libxl: resume instead of unpause on xl save -c
> 
> 01 libxl: Remus - suspend/postflush/commit callbacks
> 02 libxl: Remus - xl remus command
> 
> Currently, one of stefano's patches doesnt apply cleanly - the first one. It requires minor fix.
> Barring that, all the other patches mentioned above apply cleanly.
> 

I can rebase and resend if it is needed.
--8323329-1321825165-1329819137=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-1321825165-1329819137=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:07:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:07:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmcs-0006sj-1s; Tue, 21 Feb 2012 10:07:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmcr-0006s1-9N
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:07:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329818825!14218952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31910 invoked from network); 21 Feb 2012 10:07:06 -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;
	21 Feb 2012 10:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:07:05 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:07:04 +0000
Message-ID: <1329818824.25232.66.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 10:07:04 +0000
In-Reply-To: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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 Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
> 
> +# Autoscan stuff (except for yajl/yajl_version.h check)

I don't understand this comment, the following AC_CHECK_HEADERS _does_
check for yajl_version.

> +# Checks for header files.
> +AC_FUNC_ALLOCA
> +AC_CHECK_HEADERS([ \
> +                arpa/inet.h fcntl.h inttypes.h libintl.h limits.h malloc.h \
> +                netdb.h netinet/in.h stddef.h stdint.h stdlib.h string.h \
> +                strings.h sys/file.h sys/ioctl.h sys/mount.h sys/param.h \
> +                sys/socket.h sys/statvfs.h sys/time.h syslog.h termios.h \
> +                unistd.h yajl/yajl_version.h \
> +                ]) 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:07:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:07:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmcs-0006sj-1s; Tue, 21 Feb 2012 10:07:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmcr-0006s1-9N
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:07:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329818825!14218952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31910 invoked from network); 21 Feb 2012 10:07:06 -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;
	21 Feb 2012 10:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:07:05 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:07:04 +0000
Message-ID: <1329818824.25232.66.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 10:07:04 +0000
In-Reply-To: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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 Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
> 
> +# Autoscan stuff (except for yajl/yajl_version.h check)

I don't understand this comment, the following AC_CHECK_HEADERS _does_
check for yajl_version.

> +# Checks for header files.
> +AC_FUNC_ALLOCA
> +AC_CHECK_HEADERS([ \
> +                arpa/inet.h fcntl.h inttypes.h libintl.h limits.h malloc.h \
> +                netdb.h netinet/in.h stddef.h stdint.h stdlib.h string.h \
> +                strings.h sys/file.h sys/ioctl.h sys/mount.h sys/param.h \
> +                sys/socket.h sys/statvfs.h sys/time.h syslog.h termios.h \
> +                unistd.h yajl/yajl_version.h \
> +                ]) 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzme4-00072k-H0; Tue, 21 Feb 2012 10:08:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzme2-000729-NG
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:08:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329818899!14241413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20835 invoked from network); 21 Feb 2012 10:08:20 -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;
	21 Feb 2012 10:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:08:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:08:19 +0000
Date: Tue, 21 Feb 2012 10:13:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPPWzutOx=RKO_kGrvvswCEa=j_qmOu9QRyTfu6qu=4wDw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202211013120.23091@kaball-desktop>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
	<CAP8mzPPWzutOx=RKO_kGrvvswCEa=j_qmOu9QRyTfu6qu=4wDw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-588781894-1329819237=:23091"
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-588781894-1329819237=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 20 Feb 2012, Shriram Rajagopalan wrote:
> On Mon, Feb 20, 2012 at 12:02 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
>       On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>             rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
>             domain_resume"):
>             > libxl: support suspend_cancel in domain_resume
> 
> I get this:
> 
> libxl.c: In function 'libxl_domain_resume':
> libxl.c:315: error: implicit declaration of function 'libxl__domain_resume_device_model'
> 
> Did you compile this ?  Did you test it ?
> 
> 
> Yes I did.. Did you apply the previous patch in this series, that introduces the above (missing)  function ?
> 
> As I mentioned in the introductory email, these patches also depend on Stefano's XC_SAVE_ID_TOOLSTACK patches.
> 
> 01 Introduce a new save_id to save/restore toolstack specific extra
> 02 Read Qemu's physmap from xenstore and save it using toolstack_save.
> 03 Following the recent changes to upstream Qemu, the best monitor command
>     (removes qmp_migrate and introduces qmp_save)
> 
> 
> Stefano, you said a while ago, that the above patches were blocked on some qemu related acks.
> Any updates ?

None unfortunately. I'll try to get an answer by the end of the week.
--8323329-588781894-1329819237=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-588781894-1329819237=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzme4-00072k-H0; Tue, 21 Feb 2012 10:08:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzme2-000729-NG
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:08:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329818899!14241413!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20835 invoked from network); 21 Feb 2012 10:08:20 -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;
	21 Feb 2012 10:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10833953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:08:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:08:19 +0000
Date: Tue, 21 Feb 2012 10:13:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPPWzutOx=RKO_kGrvvswCEa=j_qmOu9QRyTfu6qu=4wDw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202211013120.23091@kaball-desktop>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
	<CAP8mzPPWzutOx=RKO_kGrvvswCEa=j_qmOu9QRyTfu6qu=4wDw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-588781894-1329819237=:23091"
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-588781894-1329819237=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Mon, 20 Feb 2012, Shriram Rajagopalan wrote:
> On Mon, Feb 20, 2012 at 12:02 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
>       On Mon, Feb 20, 2012 at 11:00 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>             rshriram@cs.ubc.ca writes ("[Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in
>             domain_resume"):
>             > libxl: support suspend_cancel in domain_resume
> 
> I get this:
> 
> libxl.c: In function 'libxl_domain_resume':
> libxl.c:315: error: implicit declaration of function 'libxl__domain_resume_device_model'
> 
> Did you compile this ?  Did you test it ?
> 
> 
> Yes I did.. Did you apply the previous patch in this series, that introduces the above (missing)  function ?
> 
> As I mentioned in the introductory email, these patches also depend on Stefano's XC_SAVE_ID_TOOLSTACK patches.
> 
> 01 Introduce a new save_id to save/restore toolstack specific extra
> 02 Read Qemu's physmap from xenstore and save it using toolstack_save.
> 03 Following the recent changes to upstream Qemu, the best monitor command
>     (removes qmp_migrate and introduces qmp_save)
> 
> 
> Stefano, you said a while ago, that the above patches were blocked on some qemu related acks.
> Any updates ?

None unfortunately. I'll try to get an answer by the end of the week.
--8323329-588781894-1329819237=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-588781894-1329819237=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzmge-0007Jq-4p; Tue, 21 Feb 2012 10:11:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmgc-0007Jf-Es
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:11:06 +0000
Received: from [85.158.139.83:60238] by server-3.bemta-5.messagelabs.com id
	25/D8-06438-9BD634F4; Tue, 21 Feb 2012 10:11:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329819064!15943022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31823 invoked from network); 21 Feb 2012 10:11:05 -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;
	21 Feb 2012 10:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:10:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:10:46 +0000
Message-ID: <1329819046.25232.69.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:10:46 +0000
In-Reply-To: <alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> > > libxl: drop 8M slack for PV guests.
> > > 
> > > As far as I can tell this serves no purpose. I think it relates to the old
> > > 8M to "account for backend allocations" which we used to add. This leaves a bit
> > > of unpopulated space in the Pseudo-physical address space which can be used by
> > > backends when mapping foreign memory. However 8M is not representative of that
> > > any more and modern kernels do not operate in this way anyway.
> > > 
> > > I suspect an argument could be made for removing this from the libxl API
> > > altogether but instead lets just set the overhead to 0.
> > 
> > I think this is plausible but I'd like to hear from Stefano, who iirc
> > may have some knowledge about the reason for this 8Mb.
> 
> It comes from XenD (and XAPI too, if I recall correctly), see this
> comment in tools/python/xen/xend/image.py:

That doesn't answer the "why" though.

I think I should just be more assertive since I believe I do actually
know why the 8 is there (or certainly nobody appears to know any
better). I'll update the changelog to read:

        This serves no purpose. It relates to the old 8M to "account for
        backend allocations" which we used to add. This leaves a bit of
        unpopulated space in the Pseudo-physical address space which can
        be used by backends when mapping foreign memory. However 8M is
        not representative of that any more and modern kernels do not
        operate in this way anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzmge-0007Jq-4p; Tue, 21 Feb 2012 10:11:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmgc-0007Jf-Es
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:11:06 +0000
Received: from [85.158.139.83:60238] by server-3.bemta-5.messagelabs.com id
	25/D8-06438-9BD634F4; Tue, 21 Feb 2012 10:11:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329819064!15943022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31823 invoked from network); 21 Feb 2012 10:11:05 -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;
	21 Feb 2012 10:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:10:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:10:46 +0000
Message-ID: <1329819046.25232.69.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:10:46 +0000
In-Reply-To: <alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> > > libxl: drop 8M slack for PV guests.
> > > 
> > > As far as I can tell this serves no purpose. I think it relates to the old
> > > 8M to "account for backend allocations" which we used to add. This leaves a bit
> > > of unpopulated space in the Pseudo-physical address space which can be used by
> > > backends when mapping foreign memory. However 8M is not representative of that
> > > any more and modern kernels do not operate in this way anyway.
> > > 
> > > I suspect an argument could be made for removing this from the libxl API
> > > altogether but instead lets just set the overhead to 0.
> > 
> > I think this is plausible but I'd like to hear from Stefano, who iirc
> > may have some knowledge about the reason for this 8Mb.
> 
> It comes from XenD (and XAPI too, if I recall correctly), see this
> comment in tools/python/xen/xend/image.py:

That doesn't answer the "why" though.

I think I should just be more assertive since I believe I do actually
know why the 8 is there (or certainly nobody appears to know any
better). I'll update the changelog to read:

        This serves no purpose. It relates to the old 8M to "account for
        backend allocations" which we used to add. This leaves a bit of
        unpopulated space in the Pseudo-physical address space which can
        be used by backends when mapping foreign memory. However 8M is
        not representative of that any more and modern kernels do not
        operate in this way anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:11:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:11:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmgg-0007KO-I2; Tue, 21 Feb 2012 10:11:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzmge-0007Jv-S1
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:11:09 +0000
Received: from [85.158.139.83:43770] by server-4.bemta-5.messagelabs.com id
	C8/25-10788-CBD634F4; Tue, 21 Feb 2012 10:11:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329819064!15943022!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32014 invoked from network); 21 Feb 2012 10:11:07 -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;
	21 Feb 2012 10:11:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:10:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:10:52 +0000
Date: Tue, 21 Feb 2012 10:16:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4sw=hHD2Rk6a=HMhE9Q+5-wsNZ95dQuA_oit_-q-BvHA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202211015010.23091@kaball-desktop>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
	<alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
	<20290.28675.613981.325668@mariner.uk.xensource.com>
	<CAPLaKK4sw=hHD2Rk6a=HMhE9Q+5-wsNZ95dQuA_oit_-q-BvHA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-324981304-1329819390=:23091"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-324981304-1329819390=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Tue, 21 Feb 2012, Roger Pau Monné wrote:
> 2012/2/20 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing"):
> >> On Mon, 16 Jan 2012, Roger Pau Monne wrote:
> >> > Qemu was not reacting when setting xenstore state of a device to
> >> > XenbusStateClosing (5). This patch makes qemu react to this state and
> >> > close the appropiate device.
> >> >
> >> > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> >>
> >> Please send a version of this patch against upstream qemu and CC
> >> qemu-devel as well.
> >
> > We are trying to avoid adding new code and new features to
> > qemu-xen-unstable.  Can you explain what the practical impact of this
> > patch is ?  When is it needed and what doesn't work without it ?
> 
> This is not really needed now, qdisk backends are destroyed the hard
> way (remove xenstore backend and signal qemu-dm). The normal process
> for destroying a backend however should be to wait for it to reach
> state 6, and qemu-dm backend implementation doesn't react to setting
> backend state to 5, as most backends do. This patch was trying to fix
> this by making qemu-dm aware of a close request.

I would consider it a bug that should be fixed


> > Has the thing which doesn't work without it ever worked before destroying
> 
> As said before, device shutdown/destruction in libxl is forced right
> now, the frontend/backend is destroyed and the device model signaled
> (if there's a device model). This will change with the hotplug/device
> domain series, since we can no longer destroy the backend xenstore
> entries before unplugging the device because we have to call hotplug
> scripts when the device has reached a closed state (6).
> 
> We could make an exception with qemu devices, but I would prefer to
> avoid that and use the same unplug path for all device types.
 
I agree
--8323329-324981304-1329819390=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-324981304-1329819390=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:11:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:11:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmgg-0007KO-I2; Tue, 21 Feb 2012 10:11:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzmge-0007Jv-S1
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:11:09 +0000
Received: from [85.158.139.83:43770] by server-4.bemta-5.messagelabs.com id
	C8/25-10788-CBD634F4; Tue, 21 Feb 2012 10:11:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329819064!15943022!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32014 invoked from network); 21 Feb 2012 10:11:07 -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;
	21 Feb 2012 10:11:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:10:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:10:52 +0000
Date: Tue, 21 Feb 2012 10:16:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4sw=hHD2Rk6a=HMhE9Q+5-wsNZ95dQuA_oit_-q-BvHA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202211015010.23091@kaball-desktop>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
	<alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
	<20290.28675.613981.325668@mariner.uk.xensource.com>
	<CAPLaKK4sw=hHD2Rk6a=HMhE9Q+5-wsNZ95dQuA_oit_-q-BvHA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-324981304-1329819390=:23091"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-324981304-1329819390=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Tue, 21 Feb 2012, Roger Pau Monné wrote:
> 2012/2/20 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing"):
> >> On Mon, 16 Jan 2012, Roger Pau Monne wrote:
> >> > Qemu was not reacting when setting xenstore state of a device to
> >> > XenbusStateClosing (5). This patch makes qemu react to this state and
> >> > close the appropiate device.
> >> >
> >> > Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> >>
> >> Please send a version of this patch against upstream qemu and CC
> >> qemu-devel as well.
> >
> > We are trying to avoid adding new code and new features to
> > qemu-xen-unstable.  Can you explain what the practical impact of this
> > patch is ?  When is it needed and what doesn't work without it ?
> 
> This is not really needed now, qdisk backends are destroyed the hard
> way (remove xenstore backend and signal qemu-dm). The normal process
> for destroying a backend however should be to wait for it to reach
> state 6, and qemu-dm backend implementation doesn't react to setting
> backend state to 5, as most backends do. This patch was trying to fix
> this by making qemu-dm aware of a close request.

I would consider it a bug that should be fixed


> > Has the thing which doesn't work without it ever worked before destroying
> 
> As said before, device shutdown/destruction in libxl is forced right
> now, the frontend/backend is destroyed and the device model signaled
> (if there's a device model). This will change with the hotplug/device
> domain series, since we can no longer destroy the backend xenstore
> entries before unplugging the device because we have to call hotplug
> scripts when the device has reached a closed state (6).
> 
> We could make an exception with qemu devices, but I would prefer to
> avoid that and use the same unplug path for all device types.
 
I agree
--8323329-324981304-1329819390=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-324981304-1329819390=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:11:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmhA-0007R2-6S; Tue, 21 Feb 2012 10:11: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 1Rzmh8-0007PR-Vp
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:11:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329819047!60970494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18891 invoked from network); 21 Feb 2012 10:10:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:10:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:11:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:11:32 +0000
Message-ID: <1329819092.25232.70.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:11:32 +0000
In-Reply-To: <20290.40412.612337.629579@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
	<20290.40412.612337.629579@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init
 and libxl_FOO_init_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 Mon, 2012-02-20 at 19:24 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD"):
> > libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD
> 
> Ah!  Here's what I was looking for.  Excellent.
> 
> I would like to see the autogenerated code this makes and it would be
> much more convenient for me to try out this series if you could push
> it to a hg or git tree somewhere for me to fetch.

I'll process your acks and other comments and resend including a git
url.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:11:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmhA-0007R2-6S; Tue, 21 Feb 2012 10:11: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 1Rzmh8-0007PR-Vp
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:11:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329819047!60970494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18891 invoked from network); 21 Feb 2012 10:10:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:10:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:11:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:11:32 +0000
Message-ID: <1329819092.25232.70.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:11:32 +0000
In-Reply-To: <20290.40412.612337.629579@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<50c87c40031ca9126581.1329151989@cosworth.uk.xensource.com>
	<20290.40412.612337.629579@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init
 and libxl_FOO_init_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 Mon, 2012-02-20 at 19:24 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 23 of 23] libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD"):
> > libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD
> 
> Ah!  Here's what I was looking for.  Excellent.
> 
> I would like to see the autogenerated code this makes and it would be
> much more convenient for me to try out this series if you could push
> it to a hg or git tree somewhere for me to fetch.

I'll process your acks and other comments and resend including a git
url.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:13:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1Rzmip-0007iM-Q3; Tue, 21 Feb 2012 10:13:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzmio-0007hH-6L
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:13:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329819195!14220298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29243 invoked from network); 21 Feb 2012 10:13:16 -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;
	21 Feb 2012 10:13:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:13:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:13:15 +0000
Date: Tue, 21 Feb 2012 10:18:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120220203538.GE18751@redhat.com>
Message-ID: <alpine.DEB.2.00.1202211017360.23091@kaball-desktop>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
	<20120220203538.GE18751@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Allen Kay <allen.m.kay@intel.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Guy Zana <guy@neocleus.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
 PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 20 Feb 2012, Michael S. Tsirkin wrote:
> On Fri, Feb 17, 2012 at 05:08:42PM +0000, Anthony PERARD wrote:
> > From: Allen Kay <allen.m.kay@intel.com>
> >
> > A more complete history can be found here:
> > git://xenbits.xensource.com/qemu-xen-unstable.git
> >
> > Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> > Signed-off-by: Guy Zana <guy@neocleus.com>
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> A lot of functionality seems to be duplicated with
> kvm's device assignment code.
> Makes sense to try separating generic bits so that code
> can be shared?

We had this discussion a while back, see Avi's suggestion to merge both
and abstracting them later:

http://marc.info/?l=qemu-devel&m=131805825314072&w=2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:13:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1Rzmip-0007iM-Q3; Tue, 21 Feb 2012 10:13:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzmio-0007hH-6L
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:13:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329819195!14220298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29243 invoked from network); 21 Feb 2012 10:13:16 -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;
	21 Feb 2012 10:13:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:13:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:13:15 +0000
Date: Tue, 21 Feb 2012 10:18:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "Michael S. Tsirkin" <mst@redhat.com>
In-Reply-To: <20120220203538.GE18751@redhat.com>
Message-ID: <alpine.DEB.2.00.1202211017360.23091@kaball-desktop>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-9-git-send-email-anthony.perard@citrix.com>
	<20120220203538.GE18751@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Allen Kay <allen.m.kay@intel.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Guy Zana <guy@neocleus.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 08/11] Introduce Xen PCI Passthrough,
 PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 20 Feb 2012, Michael S. Tsirkin wrote:
> On Fri, Feb 17, 2012 at 05:08:42PM +0000, Anthony PERARD wrote:
> > From: Allen Kay <allen.m.kay@intel.com>
> >
> > A more complete history can be found here:
> > git://xenbits.xensource.com/qemu-xen-unstable.git
> >
> > Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> > Signed-off-by: Guy Zana <guy@neocleus.com>
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> A lot of functionality seems to be duplicated with
> kvm's device assignment code.
> Makes sense to try separating generic bits so that code
> can be shared?

We had this discussion a while back, see Avi's suggestion to merge both
and abstracting them later:

http://marc.info/?l=qemu-devel&m=131805825314072&w=2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:16:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1RzmlP-0007yn-FY; Tue, 21 Feb 2012 10:16:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmlN-0007y9-VJ
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:16:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329819355!16186713!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32400 invoked from network); 21 Feb 2012 10:15:55 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:15:55 -0000
Received: by wibhi20 with SMTP id hi20so3320510wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 02:15:55 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr30608517wib.3.1329819355113
	(num_hops = 1); Tue, 21 Feb 2012 02:15:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=N/1GLrlTkW3E6ffgarkAbIs49EkDCmxjfZ9ygvUE2M8=;
	b=qj7D9XbVVyjjS06Yvnq/zuYwhgdmQ2iNK7/3JcBzsrmdiqZcufkSPFaSpfGn73yTGM
	VUEHRG+PdmyWBu39CZORwmlAPEjIhLMofLYBds7SD37Rpozo0DxxvhDKCLBXsXrLbAKD
	BTcEb1B8GzOm14rOisUIggN9NHdYbNKnfUv10=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr25543205wib.3.1329819355069; Tue,
	21 Feb 2012 02:15:55 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 02:15:55 -0800 (PST)
In-Reply-To: <1329818622.25232.65.camel@dagon.hellion.org.uk>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
	<1329818622.25232.65.camel@dagon.hellion.org.uk>
Date: Tue, 21 Feb 2012 11:15:55 +0100
X-Google-Sender-Auth: lnYPyVMY6iAKzOj2GDOlKa0w6Ew
Message-ID: <CAPLaKK4_NSLB6+ew+s+Ok=G6FuNmLxe9cYtZOPCvXdj=8ajmww@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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

2012/2/21 Ian Campbell <Ian.Campbell@citrix.com>:
> On Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
>>
>> +echo "#!/bin/sh -e" >> configure
>> +echo "cd tools && ./configure \$@" >> configure
>> +chmod +x configure
>
> why not check this in as a script rather than generating it from
> autogen.sh?

This is a left over from previous versions, when I assumed the
end-user would perform the ./autogen.sh stuff, to prevent people from
trying to run configure before executing autogen, but it's useless
now, I will add it to the patch and resend.

Thanks.

> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:16:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1RzmlP-0007yn-FY; Tue, 21 Feb 2012 10:16:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzmlN-0007y9-VJ
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:16:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329819355!16186713!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32400 invoked from network); 21 Feb 2012 10:15:55 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:15:55 -0000
Received: by wibhi20 with SMTP id hi20so3320510wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 02:15:55 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr30608517wib.3.1329819355113
	(num_hops = 1); Tue, 21 Feb 2012 02:15:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=N/1GLrlTkW3E6ffgarkAbIs49EkDCmxjfZ9ygvUE2M8=;
	b=qj7D9XbVVyjjS06Yvnq/zuYwhgdmQ2iNK7/3JcBzsrmdiqZcufkSPFaSpfGn73yTGM
	VUEHRG+PdmyWBu39CZORwmlAPEjIhLMofLYBds7SD37Rpozo0DxxvhDKCLBXsXrLbAKD
	BTcEb1B8GzOm14rOisUIggN9NHdYbNKnfUv10=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr25543205wib.3.1329819355069; Tue,
	21 Feb 2012 02:15:55 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 02:15:55 -0800 (PST)
In-Reply-To: <1329818622.25232.65.camel@dagon.hellion.org.uk>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
	<1329818622.25232.65.camel@dagon.hellion.org.uk>
Date: Tue, 21 Feb 2012 11:15:55 +0100
X-Google-Sender-Auth: lnYPyVMY6iAKzOj2GDOlKa0w6Ew
Message-ID: <CAPLaKK4_NSLB6+ew+s+Ok=G6FuNmLxe9cYtZOPCvXdj=8ajmww@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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

2012/2/21 Ian Campbell <Ian.Campbell@citrix.com>:
> On Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
>>
>> +echo "#!/bin/sh -e" >> configure
>> +echo "cd tools && ./configure \$@" >> configure
>> +chmod +x configure
>
> why not check this in as a script rather than generating it from
> autogen.sh?

This is a left over from previous versions, when I assumed the
end-user would perform the ./autogen.sh stuff, to prevent people from
trying to run configure before executing autogen, but it's useless
now, I will add it to the patch and resend.

Thanks.

> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:17:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmmu-00089j-Vt; Tue, 21 Feb 2012 10:17:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzmmt-00089W-3Y
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:17:35 +0000
Received: from [85.158.139.83:5528] by server-11.bemta-5.messagelabs.com id
	F9/AC-14397-E3F634F4; Tue, 21 Feb 2012 10:17:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329819453!8608300!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21247 invoked from network); 21 Feb 2012 10:17:33 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:17:33 -0000
Received: by wibhi20 with SMTP id hi20so3321879wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 02:17:33 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr32140723wia.3.1329819453265 (num_hops
	= 1); Tue, 21 Feb 2012 02:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=c5NaplqNSRY8D/dwzq1GRKIFv5W4T0q1Owo4uuTAKMw=;
	b=O8ljpjjlkD2rIeK2BziYPE9HbLYih834kcHCtwWASNovp/66/v74Tb/2dSiTRoHA/n
	1TTxwf/xJLkm77fGFGiVk1/DZrAsBSE1YYNceFVEca20D9kkabKGuUtLe04Tbukostr+
	MCs5hcBHSsEP3wE2qGAO19sgOF98l9dI5XYBE=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr26864592wia.3.1329819453233; Tue,
	21 Feb 2012 02:17:33 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 02:17:33 -0800 (PST)
In-Reply-To: <1329818824.25232.66.camel@dagon.hellion.org.uk>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
	<1329818824.25232.66.camel@dagon.hellion.org.uk>
Date: Tue, 21 Feb 2012 11:17:33 +0100
X-Google-Sender-Auth: 8k-B_uS7L-nak_FCyUO7zi19Nvc
Message-ID: <CAPLaKK50Bh_WSMR53taWsxTNGKvU-edLfnbS3oz2NX305gqmTA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMi0yMCBhdCAyMjoxOCArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+Pgo+
PiArIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNr
KQo+Cj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgY29tbWVudCwgdGhlIGZvbGxvd2luZyBBQ19D
SEVDS19IRUFERVJTIF9kb2VzXwo+IGNoZWNrIGZvciB5YWpsX3ZlcnNpb24uCgpTb3JyeSwgdGhl
IGNvbW1lbnQgaXMgbWlzbGVhZGluZywgd2hhdCBJIG1lYW4gaXMgdGhhdCBldmVyeXRoaW5nIGhl
cmUKaXMgZGV0ZWN0ZWQgYnkgYXV0b3NjYW4sIGV4Y2VwdCBmb3IgdGhlIHlhamxfdmVyc2lvbi5o
IHRlc3QgdGhhdCBJJ3ZlCmFkZGVkIG15c2VsZi4gU2hvdWxkIEkgY2hhbmdlIHRoZSBjb21tZW50
PwoKPgo+PiArIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KPj4gK0FDX0ZVTkNfQUxMT0NBCj4+
ICtBQ19DSEVDS19IRUFERVJTKFsgXAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXJwYS9p
bmV0LmggZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCj4+
ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBz
dGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBz
dHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBc
Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBz
eXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoF0pCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:17:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmmu-00089j-Vt; Tue, 21 Feb 2012 10:17:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzmmt-00089W-3Y
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 10:17:35 +0000
Received: from [85.158.139.83:5528] by server-11.bemta-5.messagelabs.com id
	F9/AC-14397-E3F634F4; Tue, 21 Feb 2012 10:17:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329819453!8608300!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21247 invoked from network); 21 Feb 2012 10:17:33 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:17:33 -0000
Received: by wibhi20 with SMTP id hi20so3321879wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 02:17:33 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr32140723wia.3.1329819453265 (num_hops
	= 1); Tue, 21 Feb 2012 02:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=c5NaplqNSRY8D/dwzq1GRKIFv5W4T0q1Owo4uuTAKMw=;
	b=O8ljpjjlkD2rIeK2BziYPE9HbLYih834kcHCtwWASNovp/66/v74Tb/2dSiTRoHA/n
	1TTxwf/xJLkm77fGFGiVk1/DZrAsBSE1YYNceFVEca20D9kkabKGuUtLe04Tbukostr+
	MCs5hcBHSsEP3wE2qGAO19sgOF98l9dI5XYBE=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr26864592wia.3.1329819453233; Tue,
	21 Feb 2012 02:17:33 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 02:17:33 -0800 (PST)
In-Reply-To: <1329818824.25232.66.camel@dagon.hellion.org.uk>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
	<1329818824.25232.66.camel@dagon.hellion.org.uk>
Date: Tue, 21 Feb 2012 11:17:33 +0100
X-Google-Sender-Auth: 8k-B_uS7L-nak_FCyUO7zi19Nvc
Message-ID: <CAPLaKK50Bh_WSMR53taWsxTNGKvU-edLfnbS3oz2NX305gqmTA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMi0yMCBhdCAyMjoxOCArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+Pgo+
PiArIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNr
KQo+Cj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgY29tbWVudCwgdGhlIGZvbGxvd2luZyBBQ19D
SEVDS19IRUFERVJTIF9kb2VzXwo+IGNoZWNrIGZvciB5YWpsX3ZlcnNpb24uCgpTb3JyeSwgdGhl
IGNvbW1lbnQgaXMgbWlzbGVhZGluZywgd2hhdCBJIG1lYW4gaXMgdGhhdCBldmVyeXRoaW5nIGhl
cmUKaXMgZGV0ZWN0ZWQgYnkgYXV0b3NjYW4sIGV4Y2VwdCBmb3IgdGhlIHlhamxfdmVyc2lvbi5o
IHRlc3QgdGhhdCBJJ3ZlCmFkZGVkIG15c2VsZi4gU2hvdWxkIEkgY2hhbmdlIHRoZSBjb21tZW50
PwoKPgo+PiArIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KPj4gK0FDX0ZVTkNfQUxMT0NBCj4+
ICtBQ19DSEVDS19IRUFERVJTKFsgXAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXJwYS9p
bmV0LmggZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCj4+
ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBz
dGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBz
dHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBc
Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBz
eXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoF0pCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:17:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzmn2-0008Ae-CF; Tue, 21 Feb 2012 10:17:44 +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 1Rzmn0-00089p-HM
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:17:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329819411!60972117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21418 invoked from network); 21 Feb 2012 10:16:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:17:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:17:36 +0000
Date: Tue, 21 Feb 2012 10:22:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202131220310.7456@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1202211020580.23091@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
	<alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
	<alpine.DEB.2.00.1202131220310.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 13 Feb 2012, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Stefano Stabellini wrote:
> > On Wed, 25 Jan 2012, Stefano Stabellini wrote:
> > > Hi all,
> > > this is the fourth version of the Xen save/restore patch series.
> > > We have been discussing this issue for quite a while on #qemu and
> > > qemu-devel:
> > > 
> > > 
> > > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > > http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> > > 
> > > 
> > > The principal changes in the this version are:
> > > 
> > > - Following Anthony's suggestion I have introduced a new monitor command
> > > to save the non-ram device state to file.
> > > 
> > > - I have also removed the hack not to reset the cirrus videoram on
> > > restore, because it turns out that the videoram doesn't need to be
> > > reset in the reset handler at all (tested on Win2K, where the problem
> > > was found in the first place).
> > > 
> > 
> > Is everybody happy enough with this series?
> > Do you have any additional comments?
> > 
> 
> ping
> 

Can we at least agree on the basic approach (especially for patch #1,
#2 and #5 that are not xen specific), so that we can check in the
libxl side of the series?
It is currently blocking other patch series from being merged into
xen-unstable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:17:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzmn2-0008Ae-CF; Tue, 21 Feb 2012 10:17:44 +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 1Rzmn0-00089p-HM
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:17:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329819411!60972117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21418 invoked from network); 21 Feb 2012 10:16:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:17:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:17:36 +0000
Date: Tue, 21 Feb 2012 10:22:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1202131220310.7456@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1202211020580.23091@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
	<alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
	<alpine.DEB.2.00.1202131220310.7456@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 13 Feb 2012, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Stefano Stabellini wrote:
> > On Wed, 25 Jan 2012, Stefano Stabellini wrote:
> > > Hi all,
> > > this is the fourth version of the Xen save/restore patch series.
> > > We have been discussing this issue for quite a while on #qemu and
> > > qemu-devel:
> > > 
> > > 
> > > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > > http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> > > 
> > > 
> > > The principal changes in the this version are:
> > > 
> > > - Following Anthony's suggestion I have introduced a new monitor command
> > > to save the non-ram device state to file.
> > > 
> > > - I have also removed the hack not to reset the cirrus videoram on
> > > restore, because it turns out that the videoram doesn't need to be
> > > reset in the reset handler at all (tested on Win2K, where the problem
> > > was found in the first place).
> > > 
> > 
> > Is everybody happy enough with this series?
> > Do you have any additional comments?
> > 
> 
> ping
> 

Can we at least agree on the basic approach (especially for patch #1,
#2 and #5 that are not xen specific), so that we can check in the
libxl side of the series?
It is currently blocking other patch series from being merged into
xen-unstable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzmnw-0008JO-Ge; Tue, 21 Feb 2012 10:18:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmnv-0008Ih-2Z
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:18:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329819512!15734865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20409 invoked from network); 21 Feb 2012 10:18:33 -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;
	21 Feb 2012 10:18:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:18:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:18:32 +0000
Message-ID: <1329819511.25232.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:18:31 +0000
In-Reply-To: <20290.39452.847449.580424@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
	<20290.39452.847449.580424@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01 of 23] libxl: Document
 _init/_dispose/_setdefault 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-02-20 at 19:08 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 01 of 23] libxl: Document _init/_dispose/_setdefault functions"):
> > + * void libxl_<type>_init_<subfield>(<type> *p, subfield):
> > + *
> > + *    Initialise those parts of "p" which are not initialised by the
> > + *    main init function due to the unknown value of "subfield". Sets
> > + *    p->subfield as well as initialising any fields to their default
> > + *    values.
> > + *
> > + *    p->subfield must not have been previously initialised.
> > + *
> > + *    This method is provided for any aggregate type which is used as
> > + *    an input parameter.
> 
> This final sentence needs a qualification I think.

I struggled a bit to express what I meant.

What I was trying to say is that they are produced only for types
declared in the idl with dir=IN|BOTH. There are some output only types
which a user cannot reasonably create.

Maybe I should just declare that the distinction is irrelevant and
always generate an _init? (I think I introduced it because of some issue
I was having with the code generation, I'll try again and see if I trip
over it again)

> > + * void libxl_<type>_dispose(instance *p):
> > + *
> > + *    Frees any dynamically allocated memory used by the members of
> > + *    "p" but not the storage used by "p" itself (this allows for the
> > + *    allocation of arrays of types and for the composition of types).
> > + *
> > + *    In general this method is only provided for types where memory
> > + *    can be dynamically allocated as part of that type.
> 
> Is whether dynamic allocation may happen a very stable part of the
> libxl API ?  If we add a dynamically allocated member to one of these
> structs, don't we inevitably introduce a memory leak into all
> callers ?
> 
> I think it would be better to provide a dispose function corresponding
> to every init function.

I think the _dispose functions should be a strict superset since you
need to be able to dispose of output-only functions too. I _think_ that
means we should have a _dispose for every type.

I expect we'll uncover a mass of latent bugs whenever we add dynamic
allocation to a type which previously did not do so. But at least the
bug fix will be compatible with older versions of the library too, so I
will go ahead and add a dispose everywhere.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10: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 1Rzmnw-0008JO-Ge; Tue, 21 Feb 2012 10:18:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmnv-0008Ih-2Z
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:18:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329819512!15734865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20409 invoked from network); 21 Feb 2012 10:18:33 -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;
	21 Feb 2012 10:18:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:18:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:18:32 +0000
Message-ID: <1329819511.25232.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:18:31 +0000
In-Reply-To: <20290.39452.847449.580424@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<d50c4dc752717e2742a7.1329151967@cosworth.uk.xensource.com>
	<20290.39452.847449.580424@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01 of 23] libxl: Document
 _init/_dispose/_setdefault 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-02-20 at 19:08 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 01 of 23] libxl: Document _init/_dispose/_setdefault functions"):
> > + * void libxl_<type>_init_<subfield>(<type> *p, subfield):
> > + *
> > + *    Initialise those parts of "p" which are not initialised by the
> > + *    main init function due to the unknown value of "subfield". Sets
> > + *    p->subfield as well as initialising any fields to their default
> > + *    values.
> > + *
> > + *    p->subfield must not have been previously initialised.
> > + *
> > + *    This method is provided for any aggregate type which is used as
> > + *    an input parameter.
> 
> This final sentence needs a qualification I think.

I struggled a bit to express what I meant.

What I was trying to say is that they are produced only for types
declared in the idl with dir=IN|BOTH. There are some output only types
which a user cannot reasonably create.

Maybe I should just declare that the distinction is irrelevant and
always generate an _init? (I think I introduced it because of some issue
I was having with the code generation, I'll try again and see if I trip
over it again)

> > + * void libxl_<type>_dispose(instance *p):
> > + *
> > + *    Frees any dynamically allocated memory used by the members of
> > + *    "p" but not the storage used by "p" itself (this allows for the
> > + *    allocation of arrays of types and for the composition of types).
> > + *
> > + *    In general this method is only provided for types where memory
> > + *    can be dynamically allocated as part of that type.
> 
> Is whether dynamic allocation may happen a very stable part of the
> libxl API ?  If we add a dynamically allocated member to one of these
> structs, don't we inevitably introduce a memory leak into all
> callers ?
> 
> I think it would be better to provide a dispose function corresponding
> to every init function.

I think the _dispose functions should be a strict superset since you
need to be able to dispose of output-only functions too. I _think_ that
means we should have a _dispose for every type.

I expect we'll uncover a mass of latent bugs whenever we add dynamic
allocation to a type which previously did not do so. But at least the
bug fix will be compatible with older versions of the library too, so I
will go ahead and add a dispose everywhere.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmsb-0000Yu-IW; Tue, 21 Feb 2012 10:23:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmsa-0000YL-QA
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:23:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329819801!12403675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8186 invoked from network); 21 Feb 2012 10:23:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:23:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:23:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:23:19 +0000
Message-ID: <1329819798.25232.80.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:23:18 +0000
In-Reply-To: <20290.40164.889190.529383@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
	<20290.40164.889190.529383@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console
 internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 19:20 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> > libxl: make libxl_device_console internal
> > 
> > consoles are not directly exposed to users of the library and there are no API
> > functions for manipluating them (only the console_exec function). Rather than
> > commit to a particular API now make the type internal.
> 
> Isn't it likely that at some future point we will re-expose this
> difference, for example by providing a different set of access
> functions ?

Very likely. However I didn't want to design or commit to an API in the
total absence of users.

When a user does come along it is much easier to add a completely new
API rather than to fix an existing broken one. It's easier to do this in
a manner which users of the library can cope with in a compatible way
e.g. adding a new API is easier to check for with ./configure.

> The fact that all you can do with a console is exec the xenconsole
> client is pretty crazy.

Yup.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzmsb-0000Yu-IW; Tue, 21 Feb 2012 10:23:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzmsa-0000YL-QA
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:23:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329819801!12403675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8186 invoked from network); 21 Feb 2012 10:23:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:23:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:23:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:23:19 +0000
Message-ID: <1329819798.25232.80.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:23:18 +0000
In-Reply-To: <20290.40164.889190.529383@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
	<20290.40164.889190.529383@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console
 internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 19:20 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> > libxl: make libxl_device_console internal
> > 
> > consoles are not directly exposed to users of the library and there are no API
> > functions for manipluating them (only the console_exec function). Rather than
> > commit to a particular API now make the type internal.
> 
> Isn't it likely that at some future point we will re-expose this
> difference, for example by providing a different set of access
> functions ?

Very likely. However I didn't want to design or commit to an API in the
total absence of users.

When a user does come along it is much easier to add a completely new
API rather than to fix an existing broken one. It's easier to do this in
a manner which users of the library can cope with in a compatible way
e.g. adding a new API is easier to check for with ./configure.

> The fact that all you can do with a console is exec the xenconsole
> client is pretty crazy.

Yup.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:24:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:24:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmtB-0000dL-06; Tue, 21 Feb 2012 10:24: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 1Rzmt9-0000d5-V6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:24:04 +0000
Received: from [85.158.139.83:38358] by server-11.bemta-5.messagelabs.com id
	D6/6B-14397-3C0734F4; Tue, 21 Feb 2012 10:24:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329819842!15945796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26659 invoked from network); 21 Feb 2012 10:24:02 -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;
	21 Feb 2012 10:24:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:24:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:24:01 +0000
Message-ID: <1329819841.25232.81.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:24:01 +0000
In-Reply-To: <20290.39835.735877.682986@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
	<20290.39835.735877.682986@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in
 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 Mon, 2012-02-20 at 19:14 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in type"):
> > libxl: add new "defbool" built in type.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Again ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:24:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:24:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzmtB-0000dL-06; Tue, 21 Feb 2012 10:24: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 1Rzmt9-0000d5-V6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:24:04 +0000
Received: from [85.158.139.83:38358] by server-11.bemta-5.messagelabs.com id
	D6/6B-14397-3C0734F4; Tue, 21 Feb 2012 10:24:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329819842!15945796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26659 invoked from network); 21 Feb 2012 10:24:02 -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;
	21 Feb 2012 10:24:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10834715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:24:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:24:01 +0000
Message-ID: <1329819841.25232.81.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:24:01 +0000
In-Reply-To: <20290.39835.735877.682986@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<41738bf7d28dd74018a1.1329151979@cosworth.uk.xensource.com>
	<20290.39835.735877.682986@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in
 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 Mon, 2012-02-20 at 19:14 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 13 of 23] libxl: add new "defbool" built in type"):
> > libxl: add new "defbool" built in type.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Again ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:33:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzn1l-000141-4d; Tue, 21 Feb 2012 10:32:57 +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 1Rzn1i-00013o-TQ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:32:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329820316!55100124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16056 invoked from network); 21 Feb 2012 10:31:57 -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;
	21 Feb 2012 10:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10835617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:32:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:32:48 +0000
Date: Tue, 21 Feb 2012 10:38:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329234536.31256.259.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-679958368-1329820706=:23091"
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-679958368-1329820706=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Tue, 14 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-14 at 14:23 +0000, Roger Pau Monné wrote:
> > 2012/2/8 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > > Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > >> libxl: introduce libxl hotplug public API functions
> > >>
> > >> These functions mimic the name used by the local device functions,
> > >> following the nomenclature:
> > >
> > > I think these should be private functions.  Your new device daemon is,
> > > I think, part of the implementation of libxl, not something that
> > > another toolstack on top of libxl will reasonably want to replace.
> > >
> > > This is a new departure for libxl, which doesn't currently have any
> > > internal executables.
> > 
> > Not sure about the best approach here, I though that xldeviced will be
> > like xl, but that's something we can discuss about.
> 
> I was wondering if perhaps xl/libxl should handle these events by
> default (using the same APIs as xldeviced uses) such that in the simple
> case users can continue to just use xl without worrying about
> configuring or enabling additional daemons. There would then be an
> option to disable this if you were running xldeviced (either in dom0 or
> in a driver dom). Perhaps a more DWIM extension would be to default to
> running things within xl/libxl only if the backend is in dom0 and assu,e
> xldeviced is running in backend doms != 0.

While I understand that technically is not difficult to achieve and
doesn't add much complexity in terms of lines of code; starting daemons
is cheap and is taken care by xencommons. I am not sure if it is worth
introducing yet another way of doing the same thing.
--8323329-679958368-1329820706=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-679958368-1329820706=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:33:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:33:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzn1l-000141-4d; Tue, 21 Feb 2012 10:32:57 +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 1Rzn1i-00013o-TQ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:32:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329820316!55100124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16056 invoked from network); 21 Feb 2012 10:31:57 -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;
	21 Feb 2012 10:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10835617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:32:48 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:32:48 +0000
Date: Tue, 21 Feb 2012 10:38:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329234536.31256.259.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-679958368-1329820706=:23091"
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-679958368-1329820706=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Tue, 14 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-14 at 14:23 +0000, Roger Pau Monné wrote:
> > 2012/2/8 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > > Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > >> libxl: introduce libxl hotplug public API functions
> > >>
> > >> These functions mimic the name used by the local device functions,
> > >> following the nomenclature:
> > >
> > > I think these should be private functions.  Your new device daemon is,
> > > I think, part of the implementation of libxl, not something that
> > > another toolstack on top of libxl will reasonably want to replace.
> > >
> > > This is a new departure for libxl, which doesn't currently have any
> > > internal executables.
> > 
> > Not sure about the best approach here, I though that xldeviced will be
> > like xl, but that's something we can discuss about.
> 
> I was wondering if perhaps xl/libxl should handle these events by
> default (using the same APIs as xldeviced uses) such that in the simple
> case users can continue to just use xl without worrying about
> configuring or enabling additional daemons. There would then be an
> option to disable this if you were running xldeviced (either in dom0 or
> in a driver dom). Perhaps a more DWIM extension would be to default to
> running things within xl/libxl only if the backend is in dom0 and assu,e
> xldeviced is running in backend doms != 0.

While I understand that technically is not difficult to achieve and
doesn't add much complexity in terms of lines of code; starting daemons
is cheap and is taken care by xencommons. I am not sure if it is worth
introducing yet another way of doing the same thing.
--8323329-679958368-1329820706=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--8323329-679958368-1329820706=:23091--


From xen-devel-bounces@lists.xen.org Tue Feb 21 10:48:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznGU-0001Tm-RT; Tue, 21 Feb 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1RznGU-0001TX-36
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:48:10 +0000
Received: from [85.158.139.83:24644] by server-2.bemta-5.messagelabs.com id
	2D/97-20263-966734F4; Tue, 21 Feb 2012 10:48:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329821288!15096335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6254 invoked from network); 21 Feb 2012 10:48:08 -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;
	21 Feb 2012 10:48:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10836603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:48:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:48:07 +0000
Date: Tue, 21 Feb 2012 10:53:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329755758.3990.72.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<1329755758.3990.72.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Mon, 20 Feb 2012, Ian Campbell wrote:
> On Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> > This is necessary to handle nested traps to the hypervisor more than one deep.
> 
> A sort of corollary to this patch is the following.
> 
> The situation with the LR register when in hyp mode is a bit odd, since
> this is normally a banked register but for hyp mode it actually accesses
> LR_usr instead.
> 
> However, although I think the following is correct I'm not sure if it is
> useful to combine LR_usr and LR like this -- in particular I fear it
> might be more confusing than helpful. Making the return-to-user case a
> proper superset of return-to-hypervisor (as is the case on the save
> path) is nice though.
> 
> What do people think?

I am OK with this.

> 8<---------------------------------------------------------------
> 
> >From 3132c2976ae4c83d6d9b94ad80ee04c4880f13da Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 20 Feb 2012 15:07:09 +0000
> Subject: [PATCH] arm: lr register in hyp mode is really LR_usr.
> 
> Save and restore it in the same way for both hypervisor and user stack frames
> rather than saving both individually in the user stack frame.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/entry.S          |   14 ++------------
>  xen/include/public/arch-arm.h |   15 ++++++++++++---
>  2 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index 36f1119..0e85c3c 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -29,8 +29,6 @@
>  	blne save_guest_regs
>  
>  save_guest_regs:
> -	ldr r11, [sp, #UREGS_lr]
> -	str r11, [sp, #UREGS_LR_usr]
>  	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
>  	str r11, [sp, #UREGS_sp]

It would be nice to have a comment here saying "no need to save LR again
because LR_usr and LR are the same physical register"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:48:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznGU-0001Tm-RT; Tue, 21 Feb 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1RznGU-0001TX-36
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:48:10 +0000
Received: from [85.158.139.83:24644] by server-2.bemta-5.messagelabs.com id
	2D/97-20263-966734F4; Tue, 21 Feb 2012 10:48:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329821288!15096335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6254 invoked from network); 21 Feb 2012 10:48:08 -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;
	21 Feb 2012 10:48:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10836603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:48:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 10:48:07 +0000
Date: Tue, 21 Feb 2012 10:53:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329755758.3990.72.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<1329755758.3990.72.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Mon, 20 Feb 2012, Ian Campbell wrote:
> On Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> > This is necessary to handle nested traps to the hypervisor more than one deep.
> 
> A sort of corollary to this patch is the following.
> 
> The situation with the LR register when in hyp mode is a bit odd, since
> this is normally a banked register but for hyp mode it actually accesses
> LR_usr instead.
> 
> However, although I think the following is correct I'm not sure if it is
> useful to combine LR_usr and LR like this -- in particular I fear it
> might be more confusing than helpful. Making the return-to-user case a
> proper superset of return-to-hypervisor (as is the case on the save
> path) is nice though.
> 
> What do people think?

I am OK with this.

> 8<---------------------------------------------------------------
> 
> >From 3132c2976ae4c83d6d9b94ad80ee04c4880f13da Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 20 Feb 2012 15:07:09 +0000
> Subject: [PATCH] arm: lr register in hyp mode is really LR_usr.
> 
> Save and restore it in the same way for both hypervisor and user stack frames
> rather than saving both individually in the user stack frame.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/entry.S          |   14 ++------------
>  xen/include/public/arch-arm.h |   15 ++++++++++++---
>  2 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index 36f1119..0e85c3c 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -29,8 +29,6 @@
>  	blne save_guest_regs
>  
>  save_guest_regs:
> -	ldr r11, [sp, #UREGS_lr]
> -	str r11, [sp, #UREGS_LR_usr]
>  	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
>  	str r11, [sp, #UREGS_sp]

It would be nice to have a comment here saying "no need to save LR again
because LR_usr and LR are the same physical register"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:53:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznLN-0001ix-MY; Tue, 21 Feb 2012 10:53:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RznLL-0001ig-Ul
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:53:12 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329821584!9987140!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8599 invoked from network); 21 Feb 2012 10:53:05 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:53:05 -0000
Received: by ghbf1 with SMTP id f1so82372640ghb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 02:53:04 -0800 (PST)
Received-SPF: pass (google.com: domain of d.vrabel.98@gmail.com designates
	10.236.153.104 as permitted sender) client-ip=10.236.153.104; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of d.vrabel.98@gmail.com
	designates 10.236.153.104 as permitted sender)
	smtp.mail=d.vrabel.98@gmail.com;
	dkim=pass header.i=d.vrabel.98@gmail.com
Received: from mr.google.com ([10.236.153.104])
	by 10.236.153.104 with SMTP id e68mr33344002yhk.74.1329821584259
	(num_hops = 1); Tue, 21 Feb 2012 02:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=KdP4mN33jGCunOgVRgjfmQBVrMwazNApXYP1yK6Qc3Y=;
	b=PlZV4FMHDWKe9+PdoIvUT3lKj8FXkXmLjXysfI2lS+AAUJcDqNRYa+pfyYQkS2nTup
	aRSa/GxWcoos+0U5sSR2rUfqYw6wBmVclgge2EE/ER7NpP6esyn3Rvk1dzKVWK4eU1wN
	rNTmYq3sUOZ5Lx0hnHY4AGExhfbmlDb/raY28=
Received: by 10.236.153.104 with SMTP id e68mr25733768yhk.74.1329821584203;
	Tue, 21 Feb 2012 02:53:04 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id b12sm53508418yhj.4.2012.02.21.02.53.02
	(version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 02:53:03 -0800 (PST)
Message-ID: <4F43778D.2080507@cantab.net>
Date: Tue, 21 Feb 2012 10:53:01 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>	<20290.39907.912639.18195@mariner.uk.xensource.com>	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
	<1329819046.25232.69.camel@dagon.hellion.org.uk>
In-Reply-To: <1329819046.25232.69.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 21/02/12 10:10, Ian Campbell wrote:
> On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
>> On Mon, 20 Feb 2012, Ian Jackson wrote:
>>> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
>>>> libxl: drop 8M slack for PV guests.
>>>>
>>>> As far as I can tell this serves no purpose. I think it relates to the old
>>>> 8M to "account for backend allocations" which we used to add. This leaves a bit
>>>> of unpopulated space in the Pseudo-physical address space which can be used by
>>>> backends when mapping foreign memory. However 8M is not representative of that
>>>> any more and modern kernels do not operate in this way anyway.
>>>>
>>>> I suspect an argument could be made for removing this from the libxl API
>>>> altogether but instead lets just set the overhead to 0.
>>>
>>> I think this is plausible but I'd like to hear from Stefano, who iirc
>>> may have some knowledge about the reason for this 8Mb.
>>
>> It comes from XenD (and XAPI too, if I recall correctly), see this
>> comment in tools/python/xen/xend/image.py:
> 
> That doesn't answer the "why" though.
> 
> I think I should just be more assertive since I believe I do actually
> know why the 8 is there (or certainly nobody appears to know any
> better). I'll update the changelog to read:
> 
>         This serves no purpose. It relates to the old 8M to "account for
>         backend allocations" which we used to add. This leaves a bit of
>         unpopulated space in the Pseudo-physical address space which can
>         be used by backends when mapping foreign memory. However 8M is
>         not representative of that any more and modern kernels do not
>         operate in this way anyway.

Should a similar fix be applied to Xen as well for dom0?

Daid

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:53:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznLN-0001ix-MY; Tue, 21 Feb 2012 10:53:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RznLL-0001ig-Ul
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:53:12 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329821584!9987140!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8599 invoked from network); 21 Feb 2012 10:53:05 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 10:53:05 -0000
Received: by ghbf1 with SMTP id f1so82372640ghb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 02:53:04 -0800 (PST)
Received-SPF: pass (google.com: domain of d.vrabel.98@gmail.com designates
	10.236.153.104 as permitted sender) client-ip=10.236.153.104; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of d.vrabel.98@gmail.com
	designates 10.236.153.104 as permitted sender)
	smtp.mail=d.vrabel.98@gmail.com;
	dkim=pass header.i=d.vrabel.98@gmail.com
Received: from mr.google.com ([10.236.153.104])
	by 10.236.153.104 with SMTP id e68mr33344002yhk.74.1329821584259
	(num_hops = 1); Tue, 21 Feb 2012 02:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=KdP4mN33jGCunOgVRgjfmQBVrMwazNApXYP1yK6Qc3Y=;
	b=PlZV4FMHDWKe9+PdoIvUT3lKj8FXkXmLjXysfI2lS+AAUJcDqNRYa+pfyYQkS2nTup
	aRSa/GxWcoos+0U5sSR2rUfqYw6wBmVclgge2EE/ER7NpP6esyn3Rvk1dzKVWK4eU1wN
	rNTmYq3sUOZ5Lx0hnHY4AGExhfbmlDb/raY28=
Received: by 10.236.153.104 with SMTP id e68mr25733768yhk.74.1329821584203;
	Tue, 21 Feb 2012 02:53:04 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id b12sm53508418yhj.4.2012.02.21.02.53.02
	(version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 02:53:03 -0800 (PST)
Message-ID: <4F43778D.2080507@cantab.net>
Date: Tue, 21 Feb 2012 10:53:01 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>	<20290.39907.912639.18195@mariner.uk.xensource.com>	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
	<1329819046.25232.69.camel@dagon.hellion.org.uk>
In-Reply-To: <1329819046.25232.69.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 21/02/12 10:10, Ian Campbell wrote:
> On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
>> On Mon, 20 Feb 2012, Ian Jackson wrote:
>>> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
>>>> libxl: drop 8M slack for PV guests.
>>>>
>>>> As far as I can tell this serves no purpose. I think it relates to the old
>>>> 8M to "account for backend allocations" which we used to add. This leaves a bit
>>>> of unpopulated space in the Pseudo-physical address space which can be used by
>>>> backends when mapping foreign memory. However 8M is not representative of that
>>>> any more and modern kernels do not operate in this way anyway.
>>>>
>>>> I suspect an argument could be made for removing this from the libxl API
>>>> altogether but instead lets just set the overhead to 0.
>>>
>>> I think this is plausible but I'd like to hear from Stefano, who iirc
>>> may have some knowledge about the reason for this 8Mb.
>>
>> It comes from XenD (and XAPI too, if I recall correctly), see this
>> comment in tools/python/xen/xend/image.py:
> 
> That doesn't answer the "why" though.
> 
> I think I should just be more assertive since I believe I do actually
> know why the 8 is there (or certainly nobody appears to know any
> better). I'll update the changelog to read:
> 
>         This serves no purpose. It relates to the old 8M to "account for
>         backend allocations" which we used to add. This leaves a bit of
>         unpopulated space in the Pseudo-physical address space which can
>         be used by backends when mapping foreign memory. However 8M is
>         not representative of that any more and modern kernels do not
>         operate in this way anyway.

Should a similar fix be applied to Xen as well for dom0?

Daid

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznQn-0001vx-F3; Tue, 21 Feb 2012 10:58:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznQl-0001ve-8r
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:58:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329821920!16195068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2051 invoked from network); 21 Feb 2012 10:58:41 -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;
	21 Feb 2012 10:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:58:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:58:40 +0000
Message-ID: <1329821920.25232.83.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:58:40 +0000
In-Reply-To: <20290.40508.50377.249022@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
	<20290.40508.50377.249022@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 19:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 15 of 23] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> > libxl: make boolean members of libxl_domain_create_info into libxl_defbool

NB: should have said build_info here.

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > +        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
> 
> Maybe this would be easier to read like this:
> 
>  +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,       false);
>  +        libxl_defbool_setdefault(&b_info->u.hvm.usb,              false);
>  +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);

Seems like an improvement. I'll make that change.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznQn-0001vx-F3; Tue, 21 Feb 2012 10:58:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznQl-0001ve-8r
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:58:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329821920!16195068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2051 invoked from network); 21 Feb 2012 10:58:41 -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;
	21 Feb 2012 10:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:58:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:58:40 +0000
Message-ID: <1329821920.25232.83.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 10:58:40 +0000
In-Reply-To: <20290.40508.50377.249022@mariner.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<ca432f4ad9f58b0a0a87.1329151981@cosworth.uk.xensource.com>
	<20290.40508.50377.249022@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 15 of 23] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 19:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 15 of 23] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> > libxl: make boolean members of libxl_domain_create_info into libxl_defbool

NB: should have said build_info here.

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > +        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
> 
> Maybe this would be easier to read like this:
> 
>  +        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,       false);
>  +        libxl_defbool_setdefault(&b_info->u.hvm.usb,              false);
>  +        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);

Seems like an improvement. I'll make that change.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:59:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznRe-000208-J5; Tue, 21 Feb 2012 10:59:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznRc-0001zf-VC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:59:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329821974!15185964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 21 Feb 2012 10:59:34 -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;
	21 Feb 2012 10:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:59:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:59:34 +0000
Message-ID: <1329821973.25232.84.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Tue, 21 Feb 2012 10:59:33 +0000
In-Reply-To: <4F43778D.2080507@cantab.net>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
	<1329819046.25232.69.camel@dagon.hellion.org.uk>
	<4F43778D.2080507@cantab.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 Tue, 2012-02-21 at 10:53 +0000, David Vrabel wrote:
> On 21/02/12 10:10, Ian Campbell wrote:
> > On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
> >> On Mon, 20 Feb 2012, Ian Jackson wrote:
> >>> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> >>>> libxl: drop 8M slack for PV guests.
> >>>>
> >>>> As far as I can tell this serves no purpose. I think it relates to the old
> >>>> 8M to "account for backend allocations" which we used to add. This leaves a bit
> >>>> of unpopulated space in the Pseudo-physical address space which can be used by
> >>>> backends when mapping foreign memory. However 8M is not representative of that
> >>>> any more and modern kernels do not operate in this way anyway.
> >>>>
> >>>> I suspect an argument could be made for removing this from the libxl API
> >>>> altogether but instead lets just set the overhead to 0.
> >>>
> >>> I think this is plausible but I'd like to hear from Stefano, who iirc
> >>> may have some knowledge about the reason for this 8Mb.
> >>
> >> It comes from XenD (and XAPI too, if I recall correctly), see this
> >> comment in tools/python/xen/xend/image.py:
> > 
> > That doesn't answer the "why" though.
> > 
> > I think I should just be more assertive since I believe I do actually
> > know why the 8 is there (or certainly nobody appears to know any
> > better). I'll update the changelog to read:
> > 
> >         This serves no purpose. It relates to the old 8M to "account for
> >         backend allocations" which we used to add. This leaves a bit of
> >         unpopulated space in the Pseudo-physical address space which can
> >         be used by backends when mapping foreign memory. However 8M is
> >         not representative of that any more and modern kernels do not
> >         operate in this way anyway.
> 
> Should a similar fix be applied to Xen as well for dom0?

I don't think it is harmful to have the extra 8, but yes we could
consider doing so.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 10:59:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 10:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznRe-000208-J5; Tue, 21 Feb 2012 10:59:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznRc-0001zf-VC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 10:59:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329821974!15185964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3741 invoked from network); 21 Feb 2012 10:59:34 -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;
	21 Feb 2012 10:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 10:59:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 10:59:34 +0000
Message-ID: <1329821973.25232.84.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Tue, 21 Feb 2012 10:59:33 +0000
In-Reply-To: <4F43778D.2080507@cantab.net>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
	<1329819046.25232.69.camel@dagon.hellion.org.uk>
	<4F43778D.2080507@cantab.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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 Tue, 2012-02-21 at 10:53 +0000, David Vrabel wrote:
> On 21/02/12 10:10, Ian Campbell wrote:
> > On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
> >> On Mon, 20 Feb 2012, Ian Jackson wrote:
> >>> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> >>>> libxl: drop 8M slack for PV guests.
> >>>>
> >>>> As far as I can tell this serves no purpose. I think it relates to the old
> >>>> 8M to "account for backend allocations" which we used to add. This leaves a bit
> >>>> of unpopulated space in the Pseudo-physical address space which can be used by
> >>>> backends when mapping foreign memory. However 8M is not representative of that
> >>>> any more and modern kernels do not operate in this way anyway.
> >>>>
> >>>> I suspect an argument could be made for removing this from the libxl API
> >>>> altogether but instead lets just set the overhead to 0.
> >>>
> >>> I think this is plausible but I'd like to hear from Stefano, who iirc
> >>> may have some knowledge about the reason for this 8Mb.
> >>
> >> It comes from XenD (and XAPI too, if I recall correctly), see this
> >> comment in tools/python/xen/xend/image.py:
> > 
> > That doesn't answer the "why" though.
> > 
> > I think I should just be more assertive since I believe I do actually
> > know why the 8 is there (or certainly nobody appears to know any
> > better). I'll update the changelog to read:
> > 
> >         This serves no purpose. It relates to the old 8M to "account for
> >         backend allocations" which we used to add. This leaves a bit of
> >         unpopulated space in the Pseudo-physical address space which can
> >         be used by backends when mapping foreign memory. However 8M is
> >         not representative of that any more and modern kernels do not
> >         operate in this way anyway.
> 
> Should a similar fix be applied to Xen as well for dom0?

I don't think it is harmful to have the extra 8, but yes we could
consider doing so.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:01:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznTL-0002EV-2M; Tue, 21 Feb 2012 11:01: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 1RznTJ-0002EG-K6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:01:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329822061!64364801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14972 invoked from network); 21 Feb 2012 11:01:01 -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 Feb 2012 11:01:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:01: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.213.0;
	Tue, 21 Feb 2012 11:01:24 +0000
Message-ID: <1329822083.25232.85.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 21 Feb 2012 11:01:23 +0000
In-Reply-To: <42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 16 of 23] libxl: switch generation id
 control to libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-13 at 16:53 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329150447 0
> # Node ID 42c448aa641537798f4b09a6db55f3a5ee4082cd
> # Parent  ca432f4ad9f58b0a0a87045a680e37a123bbda11
> libxl: switch generation id control to libxl_defbool.
> 
> This allows it to be set via the _init/_setdefault methods.
> 
> Also switch the sense of the variable in the libxl API, since once you add
> defbool to the mix the double negatives become even more confusing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Paul Durrant <Paul.Durrant@citrix.com>

hg email doesn't obey these -- cc'ing Paul this time.

> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -88,7 +88,6 @@ void libxl_domain_build_info_init(libxl_
>      case LIBXL_DOMAIN_TYPE_HVM:
>          b_info->u.hvm.firmware = NULL;
>          b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
> -        b_info->u.hvm.no_incr_generationid = 0;
>  
>          b_info->u.hvm.stdvga = 0;
>          b_info->u.hvm.vnc.enable = 1;
> @@ -150,6 +149,8 @@ int libxl__domain_build_info_setdefault(
>          libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
>          libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
>          libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.incr_generationid, false);
> +
>          libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
>          libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
>  
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -406,7 +406,7 @@ int libxl__domain_restore_common(libxl__
>          hvm = 1;
>          superpages = 1;
>          pae = libxl_defbool_val(info->u.hvm.pae);
> -        no_incr_generationid = info->u.hvm.no_incr_generationid;
> +        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:27 2012 +0000
> @@ -243,7 +243,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align",        libxl_defbool),
>                                         ("timer_mode",       libxl_timer_mode),
>                                         ("nested_hvm",       libxl_defbool),
> -                                       ("no_incr_generationid", bool),
> +                                       ("incr_generationid",libxl_defbool),
>                                         ("nographic",        bool),
>                                         ("stdvga",           bool),
>                                         ("vnc",              libxl_vnc_info),
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -1350,7 +1350,7 @@ struct domain_create {
>      const char *restore_file;
>      int migrate_fd; /* -1 means none */
>      char **migration_domname_r; /* from malloc */
> -    int no_incr_generationid;
> +    int incr_generationid;
>  };
>  
>  static int freemem(libxl_domain_build_info *b_info)
> @@ -1601,8 +1601,8 @@ static int create_domain(struct domain_c
>      }
>  
>      if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
> -        d_config.b_info.u.hvm.no_incr_generationid =
> -            dom_info->no_incr_generationid;
> +        libxl_defbool_set(&d_config.b_info.u.hvm.incr_generationid,
> +                          dom_info->incr_generationid);
>  
>      if (debug || dom_info->dryrun)
>          printf_info(default_output_format, -1, &d_config);
> @@ -2877,7 +2877,7 @@ static void migrate_receive(int debug, i
>      dom_info.restore_file = "incoming migration stream";
>      dom_info.migrate_fd = 0; /* stdin */
>      dom_info.migration_domname_r = &migration_domname;
> -    dom_info.no_incr_generationid = 1;
> +    dom_info.incr_generationid = 0;
>  
>      rc = create_domain(&dom_info);
>      if (rc < 0) {
> @@ -3002,6 +3002,7 @@ int main_restore(int argc, char **argv)
>      dom_info.restore_file = checkpoint_file;
>      dom_info.migrate_fd = -1;
>      dom_info.console_autoconnect = console_autoconnect;
> +    dom_info.incr_generationid = 1;
>  
>      rc = create_domain(&dom_info);
>      if (rc < 0)
> @@ -3384,6 +3385,7 @@ int main_create(int argc, char **argv)
>      dom_info.extra_config = extra_config;
>      dom_info.migrate_fd = -1;
>      dom_info.console_autoconnect = console_autoconnect;
> +    dom_info.incr_generationid = 0;
>  
>      rc = create_domain(&dom_info);
>      if (rc < 0)
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -108,8 +108,8 @@ void printf_info_sexp(int domid, libxl_d
>                 libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
>          printf("\t\t\t(nestedhvm %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
> -        printf("\t\t\t(no_incr_generationid %d)\n",
> -                    b_info->u.hvm.no_incr_generationid);
> +        printf("\t\t\t(no_incr_generationid %s)\n",
> +               libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
>  
>          printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
>          printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:01:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznTL-0002EV-2M; Tue, 21 Feb 2012 11:01: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 1RznTJ-0002EG-K6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:01:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329822061!64364801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14972 invoked from network); 21 Feb 2012 11:01:01 -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 Feb 2012 11:01:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:01: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.213.0;
	Tue, 21 Feb 2012 11:01:24 +0000
Message-ID: <1329822083.25232.85.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 21 Feb 2012 11:01:23 +0000
In-Reply-To: <42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<42c448aa641537798f4b.1329151982@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 16 of 23] libxl: switch generation id
 control to libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-13 at 16:53 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1329150447 0
> # Node ID 42c448aa641537798f4b09a6db55f3a5ee4082cd
> # Parent  ca432f4ad9f58b0a0a87045a680e37a123bbda11
> libxl: switch generation id control to libxl_defbool.
> 
> This allows it to be set via the _init/_setdefault methods.
> 
> Also switch the sense of the variable in the libxl API, since once you add
> defbool to the mix the double negatives become even more confusing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Paul Durrant <Paul.Durrant@citrix.com>

hg email doesn't obey these -- cc'ing Paul this time.

> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -88,7 +88,6 @@ void libxl_domain_build_info_init(libxl_
>      case LIBXL_DOMAIN_TYPE_HVM:
>          b_info->u.hvm.firmware = NULL;
>          b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
> -        b_info->u.hvm.no_incr_generationid = 0;
>  
>          b_info->u.hvm.stdvga = 0;
>          b_info->u.hvm.vnc.enable = 1;
> @@ -150,6 +149,8 @@ int libxl__domain_build_info_setdefault(
>          libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
>          libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
>          libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> +        libxl_defbool_setdefault(&b_info->u.hvm.incr_generationid, false);
> +
>          libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
>          libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
>  
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -406,7 +406,7 @@ int libxl__domain_restore_common(libxl__
>          hvm = 1;
>          superpages = 1;
>          pae = libxl_defbool_val(info->u.hvm.pae);
> -        no_incr_generationid = info->u.hvm.no_incr_generationid;
> +        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Mon Feb 13 16:27:27 2012 +0000
> @@ -243,7 +243,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align",        libxl_defbool),
>                                         ("timer_mode",       libxl_timer_mode),
>                                         ("nested_hvm",       libxl_defbool),
> -                                       ("no_incr_generationid", bool),
> +                                       ("incr_generationid",libxl_defbool),
>                                         ("nographic",        bool),
>                                         ("stdvga",           bool),
>                                         ("vnc",              libxl_vnc_info),
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -1350,7 +1350,7 @@ struct domain_create {
>      const char *restore_file;
>      int migrate_fd; /* -1 means none */
>      char **migration_domname_r; /* from malloc */
> -    int no_incr_generationid;
> +    int incr_generationid;
>  };
>  
>  static int freemem(libxl_domain_build_info *b_info)
> @@ -1601,8 +1601,8 @@ static int create_domain(struct domain_c
>      }
>  
>      if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
> -        d_config.b_info.u.hvm.no_incr_generationid =
> -            dom_info->no_incr_generationid;
> +        libxl_defbool_set(&d_config.b_info.u.hvm.incr_generationid,
> +                          dom_info->incr_generationid);
>  
>      if (debug || dom_info->dryrun)
>          printf_info(default_output_format, -1, &d_config);
> @@ -2877,7 +2877,7 @@ static void migrate_receive(int debug, i
>      dom_info.restore_file = "incoming migration stream";
>      dom_info.migrate_fd = 0; /* stdin */
>      dom_info.migration_domname_r = &migration_domname;
> -    dom_info.no_incr_generationid = 1;
> +    dom_info.incr_generationid = 0;
>  
>      rc = create_domain(&dom_info);
>      if (rc < 0) {
> @@ -3002,6 +3002,7 @@ int main_restore(int argc, char **argv)
>      dom_info.restore_file = checkpoint_file;
>      dom_info.migrate_fd = -1;
>      dom_info.console_autoconnect = console_autoconnect;
> +    dom_info.incr_generationid = 1;
>  
>      rc = create_domain(&dom_info);
>      if (rc < 0)
> @@ -3384,6 +3385,7 @@ int main_create(int argc, char **argv)
>      dom_info.extra_config = extra_config;
>      dom_info.migrate_fd = -1;
>      dom_info.console_autoconnect = console_autoconnect;
> +    dom_info.incr_generationid = 0;
>  
>      rc = create_domain(&dom_info);
>      if (rc < 0)
> diff -r ca432f4ad9f5 -r 42c448aa6415 tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Mon Feb 13 15:49:01 2012 +0000
> +++ b/tools/libxl/xl_sxp.c	Mon Feb 13 16:27:27 2012 +0000
> @@ -108,8 +108,8 @@ void printf_info_sexp(int domid, libxl_d
>                 libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
>          printf("\t\t\t(nestedhvm %s)\n",
>                 libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
> -        printf("\t\t\t(no_incr_generationid %d)\n",
> -                    b_info->u.hvm.no_incr_generationid);
> +        printf("\t\t\t(no_incr_generationid %s)\n",
> +               libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
>  
>          printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
>          printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:04:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznWV-0002cr-RP; Tue, 21 Feb 2012 11:04:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznWU-0002cJ-4Y
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:04:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329822274!14248567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28221 invoked from network); 21 Feb 2012 11:04:34 -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;
	21 Feb 2012 11:04:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:04: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.213.0;
	Tue, 21 Feb 2012 11:04:33 +0000
Message-ID: <1329822272.25232.86.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 11:04:32 +0000
In-Reply-To: <20290.38711.670497.847758@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<20290.38525.59553.807190@mariner.uk.xensource.com>
	<20290.38711.670497.847758@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API 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-02-20 at 18:55 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > Do you integrate with the libxl event loop? If you did wouldn't this be
> > > trivial to handle in xl and wouldn't the xldeviced become the trivial
> > > setup + run the event loop program?
> > 
> > That would be one way to look at it.
> > 
> >   void libxl_xldeviced_enter(libxl_ctx*); /* never returns */
> 
> Actually, thinking about it, the interface is probably:
> 
>    int libxl_devicedaemon_start(libxl_ctx*);
>      /* Causes this libxl ctx to behave like the xl device daemon
>       * whenever it is processing libxl events. */
> 
> and then the caller can do this
> 
>    rc = libxl_devicedaemon_start(ctx);
>    if (rc) ...
> 
>    for (;;) {
>        ... libxl_event_wait ...   
>    }

This is the sort of thing I was imagining too.

> In principle it would be possible for this device daemon to be part of
> some other daemon this way.

Yes.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:04:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RznWV-0002cr-RP; Tue, 21 Feb 2012 11:04:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznWU-0002cJ-4Y
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:04:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329822274!14248567!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28221 invoked from network); 21 Feb 2012 11:04:34 -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;
	21 Feb 2012 11:04:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:04: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.213.0;
	Tue, 21 Feb 2012 11:04:33 +0000
Message-ID: <1329822272.25232.86.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 11:04:32 +0000
In-Reply-To: <20290.38711.670497.847758@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<20290.38525.59553.807190@mariner.uk.xensource.com>
	<20290.38711.670497.847758@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API 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-02-20 at 18:55 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > > Do you integrate with the libxl event loop? If you did wouldn't this be
> > > trivial to handle in xl and wouldn't the xldeviced become the trivial
> > > setup + run the event loop program?
> > 
> > That would be one way to look at it.
> > 
> >   void libxl_xldeviced_enter(libxl_ctx*); /* never returns */
> 
> Actually, thinking about it, the interface is probably:
> 
>    int libxl_devicedaemon_start(libxl_ctx*);
>      /* Causes this libxl ctx to behave like the xl device daemon
>       * whenever it is processing libxl events. */
> 
> and then the caller can do this
> 
>    rc = libxl_devicedaemon_start(ctx);
>    if (rc) ...
> 
>    for (;;) {
>        ... libxl_event_wait ...   
>    }

This is the sort of thing I was imagining too.

> In principle it would be possible for this device daemon to be part of
> some other daemon this way.

Yes.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11: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 1RznY1-0002ml-0u; Tue, 21 Feb 2012 11:06:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznY0-0002m6-3D
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 11:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329822364!12413806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32678 invoked from network); 21 Feb 2012 11:06:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 11:06:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:06:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 11:06:04 +0000
Message-ID: <1329822364.25232.87.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 11:06:04 +0000
In-Reply-To: <CAPLaKK50Bh_WSMR53taWsxTNGKvU-edLfnbS3oz2NX305gqmTA@mail.gmail.com>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
	<1329818824.25232.66.camel@dagon.hellion.org.uk>
	<CAPLaKK50Bh_WSMR53taWsxTNGKvU-edLfnbS3oz2NX305gqmTA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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="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-02-21 at 10:17 +0000, Roger Pau Monn=E9 wrote:
> 2012/2/21 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
> >>
> >> +# Autoscan stuff (except for yajl/yajl_version.h check)
> >
> > I don't understand this comment, the following AC_CHECK_HEADERS _does_
> > check for yajl_version.
> =

> Sorry, the comment is misleading, what I mean is that everything here
> is detected by autoscan, except for the yajl_version.h test that I've
> added myself. Should I change the comment?

I'd be tempted to just remove it. No one will update it when they add
another check not covered by autoscan.

> >
> >> +# Checks for header files.
> >> +AC_FUNC_ALLOCA
> >> +AC_CHECK_HEADERS([ \
> >> +                arpa/inet.h fcntl.h inttypes.h libintl.h limits.h mal=
loc.h \
> >> +                netdb.h netinet/in.h stddef.h stdint.h stdlib.h strin=
g.h \
> >> +                strings.h sys/file.h sys/ioctl.h sys/mount.h sys/para=
m.h \
> >> +                sys/socket.h sys/statvfs.h sys/time.h syslog.h termio=
s.h \
> >> +                unistd.h yajl/yajl_version.h \
> >> +                ])
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11: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 1RznY1-0002ml-0u; Tue, 21 Feb 2012 11:06:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RznY0-0002m6-3D
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 11:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329822364!12413806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32678 invoked from network); 21 Feb 2012 11:06:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 11:06:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:06:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 11:06:04 +0000
Message-ID: <1329822364.25232.87.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 11:06:04 +0000
In-Reply-To: <CAPLaKK50Bh_WSMR53taWsxTNGKvU-edLfnbS3oz2NX305gqmTA@mail.gmail.com>
References: <dd87b09e93aa539f4b72.1329776284@build.localdomain>
	<1329818824.25232.66.camel@dagon.hellion.org.uk>
	<CAPLaKK50Bh_WSMR53taWsxTNGKvU-edLfnbS3oz2NX305gqmTA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v5] build: add autoconf to replace custom
 checks in tools/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="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-02-21 at 10:17 +0000, Roger Pau Monn=E9 wrote:
> 2012/2/21 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Mon, 2012-02-20 at 22:18 +0000, Roger Pau Monne wrote:
> >>
> >> +# Autoscan stuff (except for yajl/yajl_version.h check)
> >
> > I don't understand this comment, the following AC_CHECK_HEADERS _does_
> > check for yajl_version.
> =

> Sorry, the comment is misleading, what I mean is that everything here
> is detected by autoscan, except for the yajl_version.h test that I've
> added myself. Should I change the comment?

I'd be tempted to just remove it. No one will update it when they add
another check not covered by autoscan.

> >
> >> +# Checks for header files.
> >> +AC_FUNC_ALLOCA
> >> +AC_CHECK_HEADERS([ \
> >> +                arpa/inet.h fcntl.h inttypes.h libintl.h limits.h mal=
loc.h \
> >> +                netdb.h netinet/in.h stddef.h stdint.h stdlib.h strin=
g.h \
> >> +                strings.h sys/file.h sys/ioctl.h sys/mount.h sys/para=
m.h \
> >> +                sys/socket.h sys/statvfs.h sys/time.h syslog.h termio=
s.h \
> >> +                unistd.h yajl/yajl_version.h \
> >> +                ])
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzngV-0003Bt-Cg; Tue, 21 Feb 2012 11:15:03 +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 1RzngU-0003Bo-Cq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:15:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329822843!57564001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5725 invoked from network); 21 Feb 2012 11:14:03 -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;
	21 Feb 2012 11:14:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:15:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 11:15:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzngS-0006mo-O1;
	Tue, 21 Feb 2012 11:15:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzngS-0002k6-I6;
	Tue, 21 Feb 2012 11:15:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11994-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 11:15:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11994: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11994 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11994/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11990

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:15:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzngV-0003Bt-Cg; Tue, 21 Feb 2012 11:15:03 +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 1RzngU-0003Bo-Cq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:15:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329822843!57564001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5725 invoked from network); 21 Feb 2012 11:14:03 -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;
	21 Feb 2012 11:14:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10837806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:15:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 11:15:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzngS-0006mo-O1;
	Tue, 21 Feb 2012 11:15:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzngS-0002k6-I6;
	Tue, 21 Feb 2012 11:15:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11994-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 11:15:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11994: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11994 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11994/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11990

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:21:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznmp-0003ZL-8h; Tue, 21 Feb 2012 11:21: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 1Rznmn-0003Z3-Tm
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:21:34 +0000
Received: from [85.158.139.83:64000] by server-6.bemta-5.messagelabs.com id
	B6/AE-27305-D3E734F4; Tue, 21 Feb 2012 11:21:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329823292!8621864!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9603 invoked from network); 21 Feb 2012 11:21:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 11:21:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10838159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:21:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 11:21:32 +0000
Message-ID: <1329823291.25232.94.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 21 Feb 2012 11:21:31 +0000
In-Reply-To: <20120220192655.GA8280@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 19:26 +0000, Olaf Hering wrote:
> This is the second time I run into this linking issue. A few days ago it
> happend with a make -j 4 or 8 during automated rpm package build. Now it
> happend with a fresh tree. My local system is openSuSE 11.4 with make
> 3.82, the failed automated build was either openSUSE 11.4 or 12.1.
> 
> For some reason the libxenstore.so symlink is created after
> init-xenstore-domain is about to be linked. The ln command is not
> visible in this output, I saw the ln invocation in the rpm build log.
> 
> Hmm, and for some reason the symlink was not created anyway in my local
> build. A second make run worked ok, libxenstore.so was created.  It
> looks like I can reproduce it by running make clean in tools/xenstore.
> 
> Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
> and libxenstore.so is also a target. So its not clear to me how make can
> miss that, or how the dependencies should be listed.
> 
> Any idea whats going on here?

It's pretty odd isn't it.

I tried:
        $ make -C tools/xenstore/ clean
        $ make -C tools/xenstore/ -j12
and couldn't reproduce. I see the ln before the link lines, even with
bigger and smaller -jN.

"make -d" will tell you make's thought processes, might give a hint?

Could it be your filesystem? Something odd to do with timestamps on
symlinks which upsets your version of make perhaps? (I'm on ext3)

I'm really grasping at straws there...

The chain of rules for making the symlinks is a bit convoluted. I'd be
inclined to have:
        libxenstore.so libxenstore.so.$(MAJOR) libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
        	$(CC)....
        	ln -sf libxenstore.so.$(MAJOR).$(MINOR) libxenstore.so.$(MAJOR)
        	ln -sf libxenstore.so.$(MAJOR) libxenstore.so

But I don't see why it would help or matter in practice.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:21:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznmp-0003ZL-8h; Tue, 21 Feb 2012 11:21: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 1Rznmn-0003Z3-Tm
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:21:34 +0000
Received: from [85.158.139.83:64000] by server-6.bemta-5.messagelabs.com id
	B6/AE-27305-D3E734F4; Tue, 21 Feb 2012 11:21:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329823292!8621864!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9603 invoked from network); 21 Feb 2012 11:21:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 11:21:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10838159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:21:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 11:21:32 +0000
Message-ID: <1329823291.25232.94.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 21 Feb 2012 11:21:31 +0000
In-Reply-To: <20120220192655.GA8280@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 19:26 +0000, Olaf Hering wrote:
> This is the second time I run into this linking issue. A few days ago it
> happend with a make -j 4 or 8 during automated rpm package build. Now it
> happend with a fresh tree. My local system is openSuSE 11.4 with make
> 3.82, the failed automated build was either openSUSE 11.4 or 12.1.
> 
> For some reason the libxenstore.so symlink is created after
> init-xenstore-domain is about to be linked. The ln command is not
> visible in this output, I saw the ln invocation in the rpm build log.
> 
> Hmm, and for some reason the symlink was not created anyway in my local
> build. A second make run worked ok, libxenstore.so was created.  It
> looks like I can reproduce it by running make clean in tools/xenstore.
> 
> Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
> and libxenstore.so is also a target. So its not clear to me how make can
> miss that, or how the dependencies should be listed.
> 
> Any idea whats going on here?

It's pretty odd isn't it.

I tried:
        $ make -C tools/xenstore/ clean
        $ make -C tools/xenstore/ -j12
and couldn't reproduce. I see the ln before the link lines, even with
bigger and smaller -jN.

"make -d" will tell you make's thought processes, might give a hint?

Could it be your filesystem? Something odd to do with timestamps on
symlinks which upsets your version of make perhaps? (I'm on ext3)

I'm really grasping at straws there...

The chain of rules for making the symlinks is a bit convoluted. I'd be
inclined to have:
        libxenstore.so libxenstore.so.$(MAJOR) libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
        	$(CC)....
        	ln -sf libxenstore.so.$(MAJOR).$(MINOR) libxenstore.so.$(MAJOR)
        	ln -sf libxenstore.so.$(MAJOR) libxenstore.so

But I don't see why it would help or matter in practice.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11: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 1Rznqn-0003mC-UI; Tue, 21 Feb 2012 11:25:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rznqk-0003lv-F0
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:25:41 +0000
Received: from [85.158.139.83:35491] by server-12.bemta-5.messagelabs.com id
	5F/E2-24595-13F734F4; Tue, 21 Feb 2012 11:25:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329823535!13250695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18322 invoked from network); 21 Feb 2012 11:25:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 11:25:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182733558"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 06:25:11 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 06:25:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1RznqD-0006FY-45; Tue, 21 Feb 2012 11:25:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 21 Feb 2012 11:30:42 +0000
Message-ID: <1329823842-10085-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] hvc_xen: introduce HVC_XEN_FRONTEND
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new config option HVC_XEN_FRONTEND to enable/disable the
xenbus based pv console frontend.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/Kconfig   |    8 +++
 drivers/tty/hvc/hvc_xen.c |  116 ++++++++++++++++++++++++---------------------
 2 files changed, 70 insertions(+), 54 deletions(-)

diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 4222035..192e21e 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -76,6 +76,14 @@ config HVC_XEN
 	help
 	  Xen virtual console device driver
 
+config HVC_XEN_FRONTEND
+	bool "Xen Hypervisor Multiple Consoles support"
+	depends on HVC_XEN
+	select XEN_XENBUS_FRONTEND
+	default y
+	help
+	  Xen driver for secondary virtual consoles
+
 config HVC_UDBG
        bool "udbg based fake hypervisor console"
        depends on PPC && EXPERIMENTAL
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 26090c7..83d5c88 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -55,7 +55,6 @@ struct xencons_info {
 
 static LIST_HEAD(xenconsoles);
 static DEFINE_SPINLOCK(xencons_lock);
-static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
@@ -298,53 +297,6 @@ static int xen_initial_domain_console_init(void)
 	return 0;
 }
 
-static int __init xen_hvc_init(void)
-{
-	int r;
-	struct xencons_info *info;
-	const struct hv_ops *ops;
-
-	if (!xen_domain())
-		return -ENODEV;
-
-	if (xen_initial_domain()) {
-		ops = &dom0_hvc_ops;
-		r = xen_initial_domain_console_init();
-		if (r < 0)
-			return r;
-		info = vtermno_to_xencons(HVC_COOKIE);
-	} else {
-		ops = &domU_hvc_ops;
-		if (xen_hvm_domain())
-			r = xen_hvm_console_init();
-		else
-			r = xen_pv_console_init();
-		if (r < 0)
-			return r;
-
-		info = vtermno_to_xencons(HVC_COOKIE);
-		info->irq = bind_evtchn_to_irq(info->evtchn);
-	}
-	if (info->irq < 0)
-		info->irq = 0; /* NO_IRQ */
-	else
-		irq_set_noprobe(info->irq);
-
-	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
-	if (IS_ERR(info->hvc)) {
-		r = PTR_ERR(info->hvc);
-		spin_lock(&xencons_lock);
-		list_del(&info->list);
-		spin_unlock(&xencons_lock);
-		if (info->irq)
-			unbind_from_irqhandler(info->irq, NULL);
-		kfree(info);
-		return r;
-	}
-
-	return xenbus_register_frontend(&xencons_driver);
-}
-
 void xen_console_resume(void)
 {
 	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
@@ -392,6 +344,9 @@ static int xen_console_remove(struct xencons_info *info)
 	return 0;
 }
 
+#ifdef CONFIG_HVC_XEN_FRONTEND
+static struct xenbus_driver xencons_driver;
+
 static int xencons_remove(struct xenbus_device *dev)
 {
 	return xen_console_remove(dev_get_drvdata(&dev->dev));
@@ -543,6 +498,65 @@ static const struct xenbus_device_id xencons_ids[] = {
 };
 
 
+static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+);
+#endif /* CONFIG_HVC_XEN_FRONTEND */
+
+static int __init xen_hvc_init(void)
+{
+	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	if (xen_initial_domain()) {
+		ops = &dom0_hvc_ops;
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
+	} else {
+		ops = &domU_hvc_ops;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
+		else
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
+	}
+
+	r = 0;
+#ifdef CONFIG_HVC_XEN_FRONTEND
+	r = xenbus_register_frontend(&xencons_driver);
+#endif
+	return r;
+}
+
 static void __exit xen_hvc_fini(void)
 {
 	struct xencons_info *entry, *next;
@@ -580,12 +594,6 @@ static int xen_cons_init(void)
 	return 0;
 }
 
-static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
-	.probe = xencons_probe,
-	.remove = xencons_remove,
-	.resume = xencons_resume,
-	.otherend_changed = xencons_backend_changed,
-);
 
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11: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 1Rznqn-0003mC-UI; Tue, 21 Feb 2012 11:25:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rznqk-0003lv-F0
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:25:41 +0000
Received: from [85.158.139.83:35491] by server-12.bemta-5.messagelabs.com id
	5F/E2-24595-13F734F4; Tue, 21 Feb 2012 11:25:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329823535!13250695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18322 invoked from network); 21 Feb 2012 11:25:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 11:25:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182733558"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 06:25:11 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 06:25:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1RznqD-0006FY-45; Tue, 21 Feb 2012 11:25:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: konrad.wilk@oracle.com
Date: Tue, 21 Feb 2012 11:30:42 +0000
Message-ID: <1329823842-10085-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] hvc_xen: introduce HVC_XEN_FRONTEND
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new config option HVC_XEN_FRONTEND to enable/disable the
xenbus based pv console frontend.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/Kconfig   |    8 +++
 drivers/tty/hvc/hvc_xen.c |  116 ++++++++++++++++++++++++---------------------
 2 files changed, 70 insertions(+), 54 deletions(-)

diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 4222035..192e21e 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -76,6 +76,14 @@ config HVC_XEN
 	help
 	  Xen virtual console device driver
 
+config HVC_XEN_FRONTEND
+	bool "Xen Hypervisor Multiple Consoles support"
+	depends on HVC_XEN
+	select XEN_XENBUS_FRONTEND
+	default y
+	help
+	  Xen driver for secondary virtual consoles
+
 config HVC_UDBG
        bool "udbg based fake hypervisor console"
        depends on PPC && EXPERIMENTAL
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 26090c7..83d5c88 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -55,7 +55,6 @@ struct xencons_info {
 
 static LIST_HEAD(xenconsoles);
 static DEFINE_SPINLOCK(xencons_lock);
-static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
@@ -298,53 +297,6 @@ static int xen_initial_domain_console_init(void)
 	return 0;
 }
 
-static int __init xen_hvc_init(void)
-{
-	int r;
-	struct xencons_info *info;
-	const struct hv_ops *ops;
-
-	if (!xen_domain())
-		return -ENODEV;
-
-	if (xen_initial_domain()) {
-		ops = &dom0_hvc_ops;
-		r = xen_initial_domain_console_init();
-		if (r < 0)
-			return r;
-		info = vtermno_to_xencons(HVC_COOKIE);
-	} else {
-		ops = &domU_hvc_ops;
-		if (xen_hvm_domain())
-			r = xen_hvm_console_init();
-		else
-			r = xen_pv_console_init();
-		if (r < 0)
-			return r;
-
-		info = vtermno_to_xencons(HVC_COOKIE);
-		info->irq = bind_evtchn_to_irq(info->evtchn);
-	}
-	if (info->irq < 0)
-		info->irq = 0; /* NO_IRQ */
-	else
-		irq_set_noprobe(info->irq);
-
-	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
-	if (IS_ERR(info->hvc)) {
-		r = PTR_ERR(info->hvc);
-		spin_lock(&xencons_lock);
-		list_del(&info->list);
-		spin_unlock(&xencons_lock);
-		if (info->irq)
-			unbind_from_irqhandler(info->irq, NULL);
-		kfree(info);
-		return r;
-	}
-
-	return xenbus_register_frontend(&xencons_driver);
-}
-
 void xen_console_resume(void)
 {
 	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
@@ -392,6 +344,9 @@ static int xen_console_remove(struct xencons_info *info)
 	return 0;
 }
 
+#ifdef CONFIG_HVC_XEN_FRONTEND
+static struct xenbus_driver xencons_driver;
+
 static int xencons_remove(struct xenbus_device *dev)
 {
 	return xen_console_remove(dev_get_drvdata(&dev->dev));
@@ -543,6 +498,65 @@ static const struct xenbus_device_id xencons_ids[] = {
 };
 
 
+static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+);
+#endif /* CONFIG_HVC_XEN_FRONTEND */
+
+static int __init xen_hvc_init(void)
+{
+	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	if (xen_initial_domain()) {
+		ops = &dom0_hvc_ops;
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
+	} else {
+		ops = &domU_hvc_ops;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
+		else
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
+	}
+
+	r = 0;
+#ifdef CONFIG_HVC_XEN_FRONTEND
+	r = xenbus_register_frontend(&xencons_driver);
+#endif
+	return r;
+}
+
 static void __exit xen_hvc_fini(void)
 {
 	struct xencons_info *entry, *next;
@@ -580,12 +594,6 @@ static int xen_cons_init(void)
 	return 0;
 }
 
-static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
-	.probe = xencons_probe,
-	.remove = xencons_remove,
-	.resume = xencons_resume,
-	.otherend_changed = xencons_backend_changed,
-);
 
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznsq-0003ss-FK; Tue, 21 Feb 2012 11:27:48 +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 1Rznso-0003sR-64
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:27:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329823609!61415333!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30261 invoked from network); 21 Feb 2012 11:26:49 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 11:26:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329823659; l=415;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qoHpR0db/yWBtE2lMP6IyI/LV1w=;
	b=xYdUVNQsutU5oqwhWewfQXwlomofXKn0dTCDRImVWI02DKiG0jGUe9TC4WR/9t9A579
	AKmJRusbV/NvtPf+0a51din+CFgqguPPLz3WOcJu4Uo4UciVaf1AHFvaEowm4KdqiUSe5
	waL55+4vZCSvkP0fuINzWU2XIL8chylF4x0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo13) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y01662o1LActWu ;
	Tue, 21 Feb 2012 12:27:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1849E18638; Tue, 21 Feb 2012 12:27:29 +0100 (CET)
Date: Tue, 21 Feb 2012 12:27:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221112728.GA6339@aepfle.de>
References: <20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329818358.25232.64.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, Ian Campbell wrote:

> If the paging daemon could be start/stopped on demand (rather than being
> a domain build time choice) we could even consider making paging the
> default.

It would be nice to allow starting paging on demand by xl mem-paging-set.
xl could watch memory/target-tot_pages, if it changes and the pager
wasnt started during creation, it could start it on request.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznsq-0003ss-FK; Tue, 21 Feb 2012 11:27:48 +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 1Rznso-0003sR-64
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:27:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329823609!61415333!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30261 invoked from network); 21 Feb 2012 11:26:49 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 11:26:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329823659; l=415;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qoHpR0db/yWBtE2lMP6IyI/LV1w=;
	b=xYdUVNQsutU5oqwhWewfQXwlomofXKn0dTCDRImVWI02DKiG0jGUe9TC4WR/9t9A579
	AKmJRusbV/NvtPf+0a51din+CFgqguPPLz3WOcJu4Uo4UciVaf1AHFvaEowm4KdqiUSe5
	waL55+4vZCSvkP0fuINzWU2XIL8chylF4x0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo13) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y01662o1LActWu ;
	Tue, 21 Feb 2012 12:27:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1849E18638; Tue, 21 Feb 2012 12:27:29 +0100 (CET)
Date: Tue, 21 Feb 2012 12:27:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221112728.GA6339@aepfle.de>
References: <20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329818358.25232.64.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, Ian Campbell wrote:

> If the paging daemon could be start/stopped on demand (rather than being
> a domain build time choice) we could even consider making paging the
> default.

It would be nice to allow starting paging on demand by xl mem-paging-set.
xl could watch memory/target-tot_pages, if it changes and the pager
wasnt started during creation, it could start it on request.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:34:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:34:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznyi-0004Cm-93; Tue, 21 Feb 2012 11:33:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rznyh-0004CU-Is
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:33:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329824023!5040550!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18029 invoked from network); 21 Feb 2012 11:33:44 -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 Feb 2012 11:33:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10838692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:33:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 11:33:43 +0000
Message-ID: <1329824022.25232.103.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Tue, 21 Feb 2012 11:33:42 +0000
In-Reply-To: <4F42227D.8090801@amd.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 10:37 +0000, Christoph Egger wrote:
> On 02/09/12 12:59, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> >> This fixes seabios build error
> >> 'python not found'
> >> along with the patches from Kevin O'Connor.
> >>
> >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> >
> > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> 
> Please apply this patch and update SeaBIOS.
> Keven O'Connors patches went upstream on Feb 8th.

I was hoping to track SeaBIOS stable branches so I am reluctant to
simply update to a random commit on the development branch.

Currently we are tracking the upstream 1.6.3-stable branch in the
xen-unstable branch of our seabios.git. In hindsight this might have
been an error since it means that our branch will only be non-rebasing
until we switch to 1.6.4 or 1.7.0 (whichever comes next).

I'm not sure how best to approach this, obviously I could create a
1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
what approach I should take when the upstream latest-stable branch
changes first though.

My immediate thought is that I should remove the "xen-unstable" branch
from our tree and instead push upstream's 1.6.3-stable branch and then
push my 1.6.3-stable-xen branch and switch to that. When new stable
branch X.Y.Z-stable happens upstream I will simply create a new
X.Y.Z-stable-xen based on it.

However I am not sure what to do with the "master" branch of our tree.
Previously I just omitted it since it has no real meaning but that
caused confusion and people wanted me to put something there.

I don't want to track the upstream devel branch since I don't want users
who clone our tree to think we support that as is. I don't want to push
the currently supported stable branch because that would necessarily
make master a rebasing branch.

The xen-unstable build system itself uses explicit commit numbers or
tags so isn't really effected.

IanJ -- what do you think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:34:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:34:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznyi-0004Cm-93; Tue, 21 Feb 2012 11:33:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rznyh-0004CU-Is
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:33:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329824023!5040550!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18029 invoked from network); 21 Feb 2012 11:33:44 -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 Feb 2012 11:33:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10838692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:33:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 11:33:43 +0000
Message-ID: <1329824022.25232.103.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Tue, 21 Feb 2012 11:33:42 +0000
In-Reply-To: <4F42227D.8090801@amd.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 10:37 +0000, Christoph Egger wrote:
> On 02/09/12 12:59, Ian Campbell wrote:
> > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> >> This fixes seabios build error
> >> 'python not found'
> >> along with the patches from Kevin O'Connor.
> >>
> >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> >
> > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> 
> Please apply this patch and update SeaBIOS.
> Keven O'Connors patches went upstream on Feb 8th.

I was hoping to track SeaBIOS stable branches so I am reluctant to
simply update to a random commit on the development branch.

Currently we are tracking the upstream 1.6.3-stable branch in the
xen-unstable branch of our seabios.git. In hindsight this might have
been an error since it means that our branch will only be non-rebasing
until we switch to 1.6.4 or 1.7.0 (whichever comes next).

I'm not sure how best to approach this, obviously I could create a
1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
what approach I should take when the upstream latest-stable branch
changes first though.

My immediate thought is that I should remove the "xen-unstable" branch
from our tree and instead push upstream's 1.6.3-stable branch and then
push my 1.6.3-stable-xen branch and switch to that. When new stable
branch X.Y.Z-stable happens upstream I will simply create a new
X.Y.Z-stable-xen based on it.

However I am not sure what to do with the "master" branch of our tree.
Previously I just omitted it since it has no real meaning but that
caused confusion and people wanted me to put something there.

I don't want to track the upstream devel branch since I don't want users
who clone our tree to think we support that as is. I don't want to push
the currently supported stable branch because that would necessarily
make master a rebasing branch.

The xen-unstable build system itself uses explicit commit numbers or
tags so isn't really effected.

IanJ -- what do you think?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:35:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznzp-0004IR-VN; Tue, 21 Feb 2012 11:35: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 1Rznzn-0004Hw-UG
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329824040!53613976!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7789 invoked from network); 21 Feb 2012 11:34:00 -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;
	21 Feb 2012 11:34:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10838848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:34: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.213.0;
	Tue, 21 Feb 2012 11:34:53 +0000
Message-ID: <1329824093.25232.104.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 21 Feb 2012 11:34:53 +0000
In-Reply-To: <20120221112728.GA6339@aepfle.de>
References: <20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<20120221112728.GA6339@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 11:27 +0000, Olaf Hering wrote:
> On Tue, Feb 21, Ian Campbell wrote:
> 
> > If the paging daemon could be start/stopped on demand (rather than being
> > a domain build time choice) we could even consider making paging the
> > default.
> 
> It would be nice to allow starting paging on demand by xl mem-paging-set.
> xl could watch memory/target-tot_pages, if it changes and the pager
> wasnt started during creation, it could start it on request.

Does it need the watch? Can't the xl which is doing the "mem-set" (or
whichever) just start the pager?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:35:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11:35:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rznzp-0004IR-VN; Tue, 21 Feb 2012 11:35: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 1Rznzn-0004Hw-UG
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329824040!53613976!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7789 invoked from network); 21 Feb 2012 11:34:00 -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;
	21 Feb 2012 11:34:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10838848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 11:34: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.213.0;
	Tue, 21 Feb 2012 11:34:53 +0000
Message-ID: <1329824093.25232.104.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 21 Feb 2012 11:34:53 +0000
In-Reply-To: <20120221112728.GA6339@aepfle.de>
References: <20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<20120221112728.GA6339@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 11:27 +0000, Olaf Hering wrote:
> On Tue, Feb 21, Ian Campbell wrote:
> 
> > If the paging daemon could be start/stopped on demand (rather than being
> > a domain build time choice) we could even consider making paging the
> > default.
> 
> It would be nice to allow starting paging on demand by xl mem-paging-set.
> xl could watch memory/target-tot_pages, if it changes and the pager
> wasnt started during creation, it could start it on request.

Does it need the watch? Can't the xl which is doing the "mem-set" (or
whichever) just start the pager?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:36:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11: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 1Rzo0x-0004Ph-Dw; Tue, 21 Feb 2012 11:36:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1Rzo0v-0004P0-3k
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:36:09 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329824160!9106251!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21147 invoked from network); 21 Feb 2012 11:36:01 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 11:36:01 -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 q1LBZls0024941
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 06:35:47 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1LBZkEZ018760; Tue, 21 Feb 2012 06:35:47 -0500
Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com
	[10.34.1.247])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q1LBZgPg014461;
	Tue, 21 Feb 2012 06:35:43 -0500
Message-ID: <4F43818E.4010407@redhat.com>
Date: Tue, 21 Feb 2012 12:35:42 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <28a9ca8a-4696-4c9c-bd15-f2fa5558740e@zmail16.collab.prod.int.phx2.redhat.com>
	<4F3D0CB1.5070707@redhat.com> <4F3E7150.7000804@redhat.com>
	<20120220152855.GA25535@phenom.dumpdata.com>
In-Reply-To: <20120220152855.GA25535@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, kvm@vger.kernel.org,
	mtosatti@redhat.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, Avi Kivity <avi@redhat.com>, hpa@zytor.com,
	amit shah <amit.shah@redhat.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] BUG in pv_clock when overflow condition is
	detected
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/20/2012 04:28 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 04:25:04PM +0100, Igor Mammedov wrote:
>> On 02/16/2012 03:03 PM, Avi Kivity wrote:
>>> On 02/15/2012 07:18 PM, Igor Mammedov wrote:
>>>>> On 02/15/2012 01:23 PM, Igor Mammedov wrote:
>>>>>>>>    static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time
>>>>>>>> *shadow)
>>>>>>>>    {
>>>>>>>> -    u64 delta = native_read_tsc() - shadow->tsc_timestamp;
>>>>>>>> +    u64 delta;
>>>>>>>> +    u64 tsc = native_read_tsc();
>>>>>>>> +    BUG_ON(tsc<    shadow->tsc_timestamp);
>>>>>>>> +    delta = tsc - shadow->tsc_timestamp;
>>>>>>>>        return pvclock_scale_delta(delta, shadow->tsc_to_nsec_mul,
>>>>>>>>                       shadow->tsc_shift);
>>>>>>>
>>>>>>> Maybe a WARN_ON_ONCE()?  Otherwise a relatively minor hypervisor
>>>>>>> bug can
>>>>>>> kill the guest.
>>>>>>
>>>>>>
>>>>>> An attempt to print from this place is not perfect since it often
>>>>>> leads
>>>>>> to recursive calling to this very function and it hang there
>>>>>> anyway.
>>>>>> But if you insist I'll re-post it with WARN_ON_ONCE,
>>>>>> It won't make much difference because guest will hang/stall due
>>>>>> overflow
>>>>>> anyway.
>>>>>
>>>>> Won't a BUG_ON() also result in a printk?
>>>> Yes, it will. But stack will still keep failure point and poking
>>>> with crash/gdb at core will always show where it's BUGged.
>>>>
>>>> In case it manages to print dump somehow (saw it couple times from ~
>>>> 30 test cycles), logs from console or from kernel message buffer
>>>> (again poking with gdb) will show where it was called from.
>>>>
>>>> If WARN* is used, it will still totaly screwup clock and
>>>> "last value" and system will become unusable, requiring looking with
>>>> gdb/crash at the core any way.
>>>>
>>>> So I've just used more stable failure point that will leave trace
>>>> everywhere it manages (maybe in console log, but for sure in stack)
>>>> in case of WARN it might leave trace on console or not and probably
>>>> won't reflect failure point in stack either leaving only kernel
>>>> message buffer for clue.
>>>>
>>>
>>> Makes sense.  But do get an ack from the Xen people to ensure this
>>> doesn't break for them.
>>>
>> Konrad, Ian
>>
>> Could you please review patch form point of view of xen?
>> Whole thread could be found here https://lkml.org/lkml/2012/2/13/286
>
> What are the conditions under which this happens?
> You should probably include that in the git description as well?
This happens on cpu hot-plug in kvm guest:
https://lkml.org/lkml/2012/2/7/222

It probably doesn't affect xen pv guest but issue might affect hvm one.
I'm certainly not xen expert to say it for sure after a cursory look
at the code. If you can confirm that it affects xen hvm I will write
early_percpu_clock_init patch for it as well.

> Is this something that happens often?
Very seldom and unlikely.

> Hm, so are you asking for review for this patch
I was asking for review of subj patch
   "BUG in pv_clock when overflow condition is detected"
I'll update patch description and re-spin it.

>  If there is an overflow can you synthesize a value instead of
> crashing the guest?
> or for http://www.spinics.net/lists/kvm/msg68440.html ?
Probably could, but there was argument that it is fixing the symptoms
and not the root cause. It seems that you've already found patch that
proposes this "pvclock: Make pv_clock more robust and fixup it if overflow happens"

>
> (which would also entail a early_percpu_clock_init implementation
> in the Xen code naturally).
>

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 11:36:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 11: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 1Rzo0x-0004Ph-Dw; Tue, 21 Feb 2012 11:36:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1Rzo0v-0004P0-3k
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 11:36:09 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329824160!9106251!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21147 invoked from network); 21 Feb 2012 11:36:01 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 11:36:01 -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 q1LBZls0024941
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 06:35:47 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q1LBZkEZ018760; Tue, 21 Feb 2012 06:35:47 -0500
Received: from nial.usersys.redhat.com (dhcp-1-247.brq.redhat.com
	[10.34.1.247])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q1LBZgPg014461;
	Tue, 21 Feb 2012 06:35:43 -0500
Message-ID: <4F43818E.4010407@redhat.com>
Date: Tue, 21 Feb 2012 12:35:42 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <28a9ca8a-4696-4c9c-bd15-f2fa5558740e@zmail16.collab.prod.int.phx2.redhat.com>
	<4F3D0CB1.5070707@redhat.com> <4F3E7150.7000804@redhat.com>
	<20120220152855.GA25535@phenom.dumpdata.com>
In-Reply-To: <20120220152855.GA25535@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, kvm@vger.kernel.org,
	mtosatti@redhat.com, linux-kernel@vger.kernel.org,
	mingo@redhat.com, Avi Kivity <avi@redhat.com>, hpa@zytor.com,
	amit shah <amit.shah@redhat.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] BUG in pv_clock when overflow condition is
	detected
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/20/2012 04:28 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2012 at 04:25:04PM +0100, Igor Mammedov wrote:
>> On 02/16/2012 03:03 PM, Avi Kivity wrote:
>>> On 02/15/2012 07:18 PM, Igor Mammedov wrote:
>>>>> On 02/15/2012 01:23 PM, Igor Mammedov wrote:
>>>>>>>>    static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time
>>>>>>>> *shadow)
>>>>>>>>    {
>>>>>>>> -    u64 delta = native_read_tsc() - shadow->tsc_timestamp;
>>>>>>>> +    u64 delta;
>>>>>>>> +    u64 tsc = native_read_tsc();
>>>>>>>> +    BUG_ON(tsc<    shadow->tsc_timestamp);
>>>>>>>> +    delta = tsc - shadow->tsc_timestamp;
>>>>>>>>        return pvclock_scale_delta(delta, shadow->tsc_to_nsec_mul,
>>>>>>>>                       shadow->tsc_shift);
>>>>>>>
>>>>>>> Maybe a WARN_ON_ONCE()?  Otherwise a relatively minor hypervisor
>>>>>>> bug can
>>>>>>> kill the guest.
>>>>>>
>>>>>>
>>>>>> An attempt to print from this place is not perfect since it often
>>>>>> leads
>>>>>> to recursive calling to this very function and it hang there
>>>>>> anyway.
>>>>>> But if you insist I'll re-post it with WARN_ON_ONCE,
>>>>>> It won't make much difference because guest will hang/stall due
>>>>>> overflow
>>>>>> anyway.
>>>>>
>>>>> Won't a BUG_ON() also result in a printk?
>>>> Yes, it will. But stack will still keep failure point and poking
>>>> with crash/gdb at core will always show where it's BUGged.
>>>>
>>>> In case it manages to print dump somehow (saw it couple times from ~
>>>> 30 test cycles), logs from console or from kernel message buffer
>>>> (again poking with gdb) will show where it was called from.
>>>>
>>>> If WARN* is used, it will still totaly screwup clock and
>>>> "last value" and system will become unusable, requiring looking with
>>>> gdb/crash at the core any way.
>>>>
>>>> So I've just used more stable failure point that will leave trace
>>>> everywhere it manages (maybe in console log, but for sure in stack)
>>>> in case of WARN it might leave trace on console or not and probably
>>>> won't reflect failure point in stack either leaving only kernel
>>>> message buffer for clue.
>>>>
>>>
>>> Makes sense.  But do get an ack from the Xen people to ensure this
>>> doesn't break for them.
>>>
>> Konrad, Ian
>>
>> Could you please review patch form point of view of xen?
>> Whole thread could be found here https://lkml.org/lkml/2012/2/13/286
>
> What are the conditions under which this happens?
> You should probably include that in the git description as well?
This happens on cpu hot-plug in kvm guest:
https://lkml.org/lkml/2012/2/7/222

It probably doesn't affect xen pv guest but issue might affect hvm one.
I'm certainly not xen expert to say it for sure after a cursory look
at the code. If you can confirm that it affects xen hvm I will write
early_percpu_clock_init patch for it as well.

> Is this something that happens often?
Very seldom and unlikely.

> Hm, so are you asking for review for this patch
I was asking for review of subj patch
   "BUG in pv_clock when overflow condition is detected"
I'll update patch description and re-spin it.

>  If there is an overflow can you synthesize a value instead of
> crashing the guest?
> or for http://www.spinics.net/lists/kvm/msg68440.html ?
Probably could, but there was argument that it is fixing the symptoms
and not the root cause. It seems that you've already found patch that
proposes this "pvclock: Make pv_clock more robust and fixup it if overflow happens"

>
> (which would also entail a early_percpu_clock_init implementation
> in the Xen code naturally).
>

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:00:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12: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 1RzoOb-0005W5-Iu; Tue, 21 Feb 2012 12:00:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzoOa-0005VY-Aj
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:00:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329825627!16206308!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2161 invoked from network); 21 Feb 2012 12:00:27 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:00:27 -0000
Received: by wgbdy1 with SMTP id dy1so4148994wgb.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:00:27 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.86.198 as permitted sender) client-ip=10.180.86.198; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.86.198 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.86.198])
	by 10.180.86.198 with SMTP id r6mr25993091wiz.22.1329825627491
	(num_hops = 1); Tue, 21 Feb 2012 04:00:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=jdpDwKU732YCTKZM/VrV5cNZh4umpufXsl7bRsjQQqc=;
	b=Obqx6tVvSLjhZGNgpLn0RhGc+yIi2rGA9ew4ciwOOkzz2E2kLueL8a0w/85QzXbXtb
	3IfcEzp9AX8TTHyxWCfxlrUwwNwTuz1VgmdAKDSI575V26BB4uGMJN5aXomUc47X8j0o
	xWO/0NgDZ4NYgfr3dyE2+ehV9z8BHXiaM22BU=
Received: by 10.180.86.198 with SMTP id r6mr21756242wiz.22.1329825627417;
	Tue, 21 Feb 2012 04:00:27 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm54565342wib.8.2012.02.21.04.00.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 04:00:26 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============5240906552094329370=="
MIME-Version: 1.0
X-Mercurial-Node: b6071c710f6cb6200aaf134a46e80bc937382f7a
Message-Id: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 02:01:27 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH v6] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5240906552094329370==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v5:

 * Remove dummy configure generation from autogen.sh since it's
   already on the source tree.

 * Removed autogen.sh since it was only a wrapper for calling
   autoconf.

 * Remove comment regarding yajl_version.h from configure.ac.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    2 -
 README                            |    4 +
 config/Tools.mk.in                |   50 +++++++
 configure                         |    2 +
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  192 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 54 files changed, 836 insertions(+), 511 deletions(-)



--===============5240906552094329370==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzg0ODA0IC0zNjAwCiMgTm9kZSBJRCBiNjA3MWM3MTBm
NmNiNjIwMGFhZjEzNGE0NmU4MGJjOTM3MzgyZjdhCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY1OgoKICogUmVtb3ZlIGR1
bW15IGNvbmZpZ3VyZSBnZW5lcmF0aW9uIGZyb20gYXV0b2dlbi5zaCBzaW5jZSBpdCdzCiAgIGFs
cmVhZHkgb24gdGhlIHNvdXJjZSB0cmVlLgoKICogUmVtb3ZlZCBhdXRvZ2VuLnNoIHNpbmNlIGl0
IHdhcyBvbmx5IGEgd3JhcHBlciBmb3IgY2FsbGluZwogICBhdXRvY29uZi4KCiAqIFJlbW92ZSBj
b21tZW50IHJlZ2FyZGluZyB5YWpsX3ZlcnNpb24uaCBmcm9tIGNvbmZpZ3VyZS5hYy4KCkNoYW5n
ZXMgc2luY2UgdjQ6CgogKiBVcGRhdGVkIHRvIHRpcC4KCiAqIEluY2x1ZGUgY29uZmlnLmggZnJv
bSBjb21waWxlciBjb21tYW5kIGxpbmUgd2hlbiBidWlsZGluZyBsaWJ4bCBhbmQKICAgeGwgdG8g
YXNzdXJlIHlhamxfdmVyc2lvbi5oIHByZXNlbmNlIGFuZCBjb3JyZWN0bHkgZGV0ZWN0IHlhamwK
ICAgdmVyc2lvbi4KCiAqIEFkZGVkIGdsaWItMi4wIGNoZWNrIHdpdGggYXBwcm9waWF0ZSBtNCBt
YWNyb3MuCgogKiBQdXJnZWQgY29uZmlnLmguaW4gZnJvbSB1bm5lY2Vzc2FyeSBkZWZpbmVzIHRo
YXQgY291bGQgbWVzcyB3aXRoCiAgIHRoZSBidWlsZCBzeXN0ZW0uCgogKiBSZW1vdmVkIHRvb2xz
L2NvbmZpZy5zdWIsIHRvb2xzL2NvbmZpZy5ndWVzcywgdG9vbHMvY29uZmlndXJlIGFuZAogICBj
b25maWd1cmUgdG8gbWFrZSB0aGUgcGF0Y2ggZml0IG1haWxpbmcgbGlzdCBsaW1pdC4KCkNoYW5n
ZXMgc2luY2UgdjM6CgogKiBDb3BpZWQgY29uZmlnLmd1ZXNzIGFuZCBjb25maWcuc3ViIGZyb20g
YXV0b21ha2UgMS4xMS4KCiAqIEFkZGVkIGEgdGVzdCB0byBjaGVjayBmb3IgdXVpZC5oIG9uIEJT
RCBhbmQgdXVpZC91dWlkLmggb24gTGludXguCgpDaGFuZ2VzIHNpbmNlIHYyOgoKICogQ2hhbmdl
ZCBvcmRlciBvZiBjb25maWcvVG9vbHMubWsgaW5jbHVkZS4KCiAqIEFkZGVkICItZSIgdG8gYXV0
b2dlbi5zaCBzaGViYW5nLgoKICogQWRkZWQgbmVjZXNzYXJ5IGZpbGVzIChjb25maWcuKikgYW5k
IG91dHB1dCBmcm9tIEF1dG9oZWFkZXIgYW5kCiAgIEF1dG9jb25mLgoKICogUmVtb3ZlZCBBdXRv
Y29uZiBmcm9tIGJ1aWxkIGRlcGVuZGVuY2llcyBhbmQgdXBkYXRlZCBSRUFETUUuCgpDaGFuZ2Vz
IHNpbmNlIHYxOgoKICogTW92ZWQgYXV0b2NvbmYgc3R1ZmYgaW5zaWRlIHRvb2xzIGZvbGRlci4K
CiAqIEFkZCBNYWtlZmlsZSBydWxlcyBmb3IgY2xlYW5pbmcuCgogKiBSZW1vdmVkIEF1dG9tYWtl
IGRlcGVuZGVuY3kuCgogKiBDcmVhdGUgYXV0b2dlbi5zaCB0byBhdXRvbWF0aWNhbGx5IGNyZWF0
ZSBjb25maWd1cmUgc2NyaXB0IHdoZW4KICAgYnVpbGRpbmcgZnJvbSBzb3VyY2UgcmVwb3NpdG9y
eS4KCiAqIENhY2hlZCB2YWx1ZXMgb2Ygb3B0aW9ucyBwYXNzZWQgZnJvbSBjb21tYW5kIGxpbmUu
CgogKiBBZGQgbmVjZXNzYXJ5IGlnbm9yZXMgdG8gLmhnaWdub3JlLgoKICogQWRkZWQgQXV0b2Nv
bmYgdG8gdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVzLgoKICogQ2hhbmdlZCBoeXBlbiB0byB1bmRl
cnNjb3JlIGluIFhNTDIgYW5kIENVUkwgdmFyaWFibGUgbmFtZXMuCgogKiBBZGRlZCBzY3JpcHQg
dG8gZ2V0IHZlcnNpb24gZnJvbSB4ZW4vTWFrZWZpbGUuCgogKiBTZXQgT2NhbWwgdG9vbHMgdG8g
b3B0aW9uYWwuCgogKiBBZGRlZCBwcm9jZWRlbmNlIG9mIG00L29jYW1sLm00LgoKU2lnbmVkLW9m
Zi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyAuaGdpZ25vcmUKLS0tIGEvLmhnaWdub3JlCU1v
biBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi8uaGdpZ25vcmUJVHVlIEZlYiAyMSAw
MTo0MDowNCAyMDEyICswMTAwCkBAIC0zMDMsNiArMzAzLDEyIEBACiBedG9vbHMvb2NhbWwvbGli
cy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWxpJAog
XnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3RvcmVkJAorXnRvb2xzL2F1dG9tNHRlXC5jYWNo
ZSQKK150b29scy9jb25maWdcLmgkCitedG9vbHMvY29uZmlnXC5sb2ckCitedG9vbHMvY29uZmln
XC5zdGF0dXMkCitedG9vbHMvY29uZmlnXC5jYWNoZSQKK15jb25maWcvVG9vbHNcLm1rJAogXnhl
bi9cLmJhbm5lci4qJAogXnhlbi9CTE9HJAogXnhlbi9TeXN0ZW0ubWFwJApkaWZmIC1yIGNhODBl
Y2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMgQ29uZmlnLm1rCi0tLSBhL0NvbmZpZy5tawlNb24gRmVi
IDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvQ29uZmlnLm1rCVR1ZSBGZWIgMjEgMDE6NDA6
MDQgMjAxMiArMDEwMApAQCAtNzAsOSArNzAsNiBAQCBFWFRSQV9JTkNMVURFUyArPSAkKEVYVFJB
X1BSRUZJWCkvaW5jbHVkCiBFWFRSQV9MSUIgKz0gJChFWFRSQV9QUkVGSVgpLyQoTElCTEVBRkRJ
UikKIGVuZGlmCiAKLUJJU09OCT89IGJpc29uCi1GTEVYCT89IGZsZXgKLQogUFlUSE9OICAgICAg
Pz0gcHl0aG9uCiBQWVRIT05fUFJFRklYX0FSRyA/PSAtLXByZWZpeD0iJChQUkVGSVgpIgogIyBU
aGUgYWJvdmUgcmVxdWlyZXMgdGhhdCBQUkVGSVggY29udGFpbnMgKm5vIHNwYWNlcyouIFRoaXMg
dmFyaWFibGUgaXMgaGVyZQpAQCAtMTc1LDMyICsxNzIsOSBAQCBDRkxBR1MgKz0gJChmb3JlYWNo
IGksICQoUFJFUEVORF9JTkNMVURFCiBBUFBFTkRfTERGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChB
UFBFTkRfTElCKSwgLUwkKGkpKQogQVBQRU5EX0NGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChBUFBF
TkRfSU5DTFVERVMpLCAtSSQoaSkpCiAKLUNIRUNLX0xJQiA9ICQoRVhUUkFfTElCKSAkKFBSRVBF
TkRfTElCKSAkKEFQUEVORF9MSUIpCi1DSEVDS19JTkNMVURFUyA9ICQoRVhUUkFfSU5DTFVERVMp
ICQoUFJFUEVORF9JTkNMVURFUykgJChBUFBFTkRfSU5DTFVERVMpCi0KIEVNQkVEREVEX0VYVFJB
X0NGTEFHUyA6PSAtbm9waWUgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1zdGFjay1wcm90ZWN0
b3ItYWxsCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgKz0gLWZuby1leGNlcHRpb25zCiAKLUNPTkZJ
R19MSUJJQ09OViAgIDo9ICQoc2hlbGwgZXhwb3J0IE9TPSJgdW5hbWUgLXNgIjsgXAotICAgICAg
ICAgICAgICAgICAgICAgICBleHBvcnQgQ0hFQ0tfTElCPSIkKENIRUNLX0xJQikiOyBcCi0gICAg
ICAgICAgICAgICAgICAgICAgIC4gJChYRU5fUk9PVCkvdG9vbHMvY2hlY2svZnVuY3Muc2g7IFwK
LSAgICAgICAgICAgICAgICAgICAgICAgaGFzX2xpYiBsaWJpY29udi5zbyAmJiBlY2hvICd5JyB8
fCBlY2hvICduJykKLQotQ09ORklHX1lBSkxfVkVSU0lPTiA6PSAkKHNoZWxsIGV4cG9ydCBPUz0i
YHVuYW1lIC1zYCI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgZXhwb3J0IENIRUNLX0lOQ0xV
REVTPSIkKENIRUNLX0lOQ0xVREVTKSI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgLiAkKFhF
Tl9ST09UKS90b29scy9jaGVjay9mdW5jcy5zaDsgXAotICAgICAgICAgICAgICAgICAgICAgICBo
YXNfaGVhZGVyIHlhamwveWFqbF92ZXJzaW9uLmggJiYgZWNobyAneScgfHwgZWNobyAnbicpCi0K
LSMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4KLVhTTV9F
TkFCTEUgPz0gbgotRkxBU0tfRU5BQkxFID89ICQoWFNNX0VOQUJMRSkKLQotIyBEb3dubG9hZCBH
SVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KLSMgR0lUJ3Mg
cHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3JrcyBhdCBhbGwg
KGZpcmV3YWxscwotIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZhdWx0LCBidXQg
aWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKLSMgZmFpbCBvciBoYW5nLCBwbGVhc2Ug
c3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCi1HSVRfSFRUUCA/PSBuCi0K
IFhFTl9FWFRGSUxFU19VUkw9aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS94ZW4tZXh0Zmls
ZXMKICMgQWxsIHRoZSBmaWxlcyBhdCB0aGF0IGxvY2F0aW9uIHdlcmUgZG93bmxvYWRlZCBmcm9t
IGVsc2V3aGVyZSBvbgogIyB0aGUgaW50ZXJuZXQuICBUaGUgb3JpZ2luYWwgZG93bmxvYWQgVVJM
IGlzIHByZXNlcnZlZCBhcyBhIGNvbW1lbnQKQEAgLTIzOSwxNyArMjEzLDQgQEAgUUVNVV9UQUcg
Pz0gMTI4ZGUyNTQ5YzVmMjRlNGE0MzdiODZiZDJlNAogIyBTaG9ydCBhbnN3ZXIgLS0gZG8gbm90
IGVuYWJsZSB0aGlzIHVubGVzcyB5b3Uga25vdyB3aGF0IHlvdSBhcmUKICMgZG9pbmcgYW5kIGFy
ZSBwcmVwYXJlZCBmb3Igc29tZSBwYWluLgogCi0jIE9wdGlvbmFsIGNvbXBvbmVudHMKLVhFTlNU
QVRfWEVOVE9QICAgICA/PSB5Ci1WVFBNX1RPT0xTICAgICAgICAgPz0gbgotTElCWEVOQVBJX0JJ
TkRJTkdTID89IG4KLVBZVEhPTl9UT09MUyAgICAgICA/PSB5Ci1PQ0FNTF9UT09MUyAgICAgICAg
Pz0geQotQ09ORklHX01JTklURVJNICAgID89IG4KLUNPTkZJR19MT01PVU5UICAgICA/PSBuCi1D
T05GSUdfU1lTVEVNX0xJQkFJTyA/PSB5CiBDT05GSUdfVEVTVFMgICAgICAgPz0geQotCi1pZmVx
ICgkKE9DQU1MX1RPT0xTKSx5KQotT0NBTUxfVE9PTFMgOj0gJChzaGVsbCBvY2FtbG9wdCAtdiA+
IC9kZXYvbnVsbCAyPiYxICYmIGVjaG8gInkiIHx8IGVjaG8gIm4iKQotZW5kaWYKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIE1ha2VmaWxlCi0tLSBhL01ha2VmaWxlCU1vbiBG
ZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi9NYWtlZmlsZQlUdWUgRmViIDIxIDAxOjQw
OjA0IDIwMTIgKzAxMDAKQEAgLTQwLDExICs0MCw5IEBAIGRpc3Q6IERFU1RESVI9JChESVNURElS
KS9pbnN0YWxsCiBkaXN0OiBkaXN0LXhlbiBkaXN0LWtlcm5lbHMgZGlzdC10b29scyBkaXN0LXN0
dWJkb20gZGlzdC1kb2NzIGRpc3QtbWlzYwogCiBkaXN0LW1pc2M6Ci0JJChJTlNUQUxMX0RJUikg
JChESVNURElSKS9jaGVjawogCSQoSU5TVEFMTF9EQVRBKSAuL0NPUFlJTkcgJChESVNURElSKQog
CSQoSU5TVEFMTF9EQVRBKSAuL1JFQURNRSAkKERJU1RESVIpCiAJJChJTlNUQUxMX1BST0cpIC4v
aW5zdGFsbC5zaCAkKERJU1RESVIpCi0JJChJTlNUQUxMX1BST0cpIHRvb2xzL2NoZWNrL2NoayB0
b29scy9jaGVjay9jaGVja18qIHRvb2xzL2NoZWNrL2Z1bmNzLnNoICQoRElTVERJUikvY2hlY2sK
IGRpc3QtJTogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRpc3QtJTogaW5zdGFsbC0lCiAJ
QDogIyBkbyBub3RoaW5nCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyBSRUFE
TUUKLS0tIGEvUkVBRE1FCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi9SRUFE
TUUJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC04OSw5ICs4OSwxMyBAQCAyLiBj
ZCB0byB4ZW4tdW5zdGFibGUgKG9yIHdoYXRldmVyIHlvdSBzCiAzLiBGb3IgdGhlIHZlcnkgZmly
c3QgYnVpbGQsIG9yIGlmIHlvdSB3YW50IHRvIGRlc3Ryb3kgYnVpbGQgdHJlZXMsCiAgICBwZXJm
b3JtIHRoZSBmb2xsb3dpbmcgc3RlcHM6CiAKKyAgICAjIC4vY29uZmlndXJlCiAgICAgIyBtYWtl
IHdvcmxkCiAgICAgIyBtYWtlIGluc3RhbGwKIAorICAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVu
IC4vY29uZmlndXJlIC0taGVscCB0byBzZWUgdGhlIGxpc3Qgb2YKKyAgIG9wdGlvbnMgYXZhaWxh
YmxlIG9wdGlvbnMgd2hlbiBidWlsZGluZyBhbmQgaW5zdGFsbGluZyBYZW4uCisKICAgIFRoaXMg
d2lsbCBjcmVhdGUgYW5kIGluc3RhbGwgb250byB0aGUgbG9jYWwgbWFjaGluZS4gSXQgd2lsbCBi
dWlsZAogICAgdGhlIHhlbiBiaW5hcnkgKHhlbi5neiksIHRoZSB0b29scyBhbmQgdGhlIGRvY3Vt
ZW50YXRpb24uCiAKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIGNvbmZpZy9U
b29scy5tay5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi9jb25maWcvVG9vbHMubWsuaW4JVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBA
IC0wLDAgKzEsNTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklYICAgICAg
ICAgICAgICA6PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BBVEhACisK
KyMgQSBkZWJ1ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0gQGRlYnVn
QAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAorRkxFWCAg
ICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZVEhPTkAK
K1BZVEhPTl9QQVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAgICAgICAg
IDo9IEBQRVJMQAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAgICAgICAg
ICAgICAgIDo9IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwyX0NPTkZJ
RyAgICAgICAgIDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAorWEdFVFRU
RVhUICAgICAgICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBsaWJzL2lu
Y2x1ZGVzCitQUkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAorUFJFUEVO
RF9MSUIgICAgICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAgIDo9IEBB
UFBFTkRfSU5DTFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElCQAorCisj
IEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitYU01fRU5B
QkxFICAgICAgICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21ACisKKyMg
RG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJvdG9jb2w/
CisjIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4gaXQgd29y
a3MgYXQgYWxsIChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVm
YXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwgb3IgaGFu
ZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50LgorR0lUX0hU
VFAgICAgICAgICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRzCitYRU5T
VEFUX1hFTlRPUCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAgOj0gQHZ0
cG1ACitMSUJYRU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAgICAgICA6
PSBAcHl0aG9udG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xzQAorQ09O
RklHX01JTklURVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAgIDo9IEBs
b21vdW50QAorCisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0gQHN5c3Rl
bV9haW9ACitDT05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19HQ1JZUFQg
ICAgICAgOj0gQGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4dDJmc0AK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIGNvbmZpZ3VyZQotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJVHVlIEZl
YiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3NoIC1lCitj
ZCB0b29scyAmJiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3
MTBmNmMgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODoz
NDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDE6NDA6MDQg
MjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlvCiBlbmRp
ZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9IGluY2x1
ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2ICs3OCw4
IEBAIGNsZWFuOiBzdWJkaXJzLWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNsZWFuCiAJ
cm0gLXJmIHFlbXUteGVuLXRyYWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25hbC1kaXIt
cmVtb3RlCiAJcm0gLXJmIHFlbXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJcm0gLXJm
IC4uL2NvbmZpZy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAor
CQljb25maWcuY2FjaGUgYXV0b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJTEVfQVJD
SCksJChYRU5fVEFSR0VUX0FSQ0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0tY3B1PSQo
WEVOX1RBUkdFVF9BUkNIKSBcCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0
b29scy9SdWxlcy5tawotLS0gYS90b29scy9SdWxlcy5tawlNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIGIvdG9vbHMvUnVsZXMubWsJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICsw
MTAwCkBAIC00LDYgKzQsNyBAQAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5t
aworaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9JTlNUQUxM
IDo9ICQoSU5TVEFMTCkKIElOU1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1pbnN0YWxs
CkBAIC04MCw4ICs4MSw2IEBAIGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2MtdmVyLWNo
ZWMKICAgICAgICAgICAgICAgICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3QgZ2NjLTMu
NCIpCiAkKGV2YWwgJChjaGVjay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwgd2hpY2gg
JChQWVRIT04pKQotUFlUSE9OX1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxMX1BZVEhP
Tl9QUk9HID0gXAogCSQoWEVOX1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAgIiQoUFlU
SE9OX1BBVEgpIiAkKElOU1RBTExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1YmRpci1h
bGwtJSBzdWJkaXItY2xlYW4tJSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVhbi0lOiAu
cGhvbnkKIAkkKE1BS0UpIC1DICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9Ub29scy5t
azoKKwlAZWNobyAiWW91IGhhdmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWlsZGluZyBv
ciBpbnN0YWxsaW5nIHRoZSB0b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGI2MDcxYzcxMGY2YyB0b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90b29scy9i
bGt0YXAvZHJpdmVycy9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEy
ICswMTAwCkBAIC0xMyw3ICsxMyw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhlbnN0b3Jl
KQogQ0ZMQUdTICAgKz0gLUkgJChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05VX1NPVVJD
RQogCi1pZmVxICgkKHNoZWxsIC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lmZXEgKCRD
T05GSUdfR0NSWVBULHkpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIgOj0gLWxn
Y3J5cHQKIGVsc2UKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2Js
a3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9jaGVj
a19nY3J5cHQJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAot
Ci1jYXQgPiAuZ2NyeXB0LmMgPDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQgbWFpbih2
b2lkKSB7IHJldHVybiAwOyB9Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0LmMgLWxn
Y3J5cHQgMj4vZGV2L251bGwgOyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNobyAibm8i
Ci1maQotCi1ybSAtZiAuZ2NyeXB0KgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvY2hlY2svTWFrZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIpLy4uLy4u
Ci1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRoZSBuZWNl
c3NhcnkgZW52aXJvbm1lbnQgdmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQWVRIT04K
LWV4cG9ydCBMSUJYRU5BUElfQklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwotZXhwb3J0
IENIRUNLX0xJQgotZXhwb3J0IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTogYWxsIGlu
c3RhbGwKLWFsbCBpbnN0YWxsOiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBp
cyBPSyBmb3IgYnVpbGRpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1idWlsZDoK
LQkuL2NoayBidWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5zdGFsbGlu
ZyBvbi4KLS5QSE9OWTogY2hlY2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2NoayBpbnN0
YWxsCi0KLS5QSE9OWTogY2xlYW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9vbHMvY2hl
Y2svUkVBRE1FCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVja3MgZm9y
IHRoZSBzdWl0YWJpbGl0eSBvZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLgot
VG8gY2hlY2sgZm9yIGJ1aWxkIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGJ1aWxk
Ci0KLVRvIGNoZWNrIGZvciBpbnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hr
IGluc3RhbGwKLQotVGhlIGNoayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMgZGlyZWN0
b3J5IGFuZCBwcmludAotdGhlIG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3RoaW5nIGlm
IGNoZWNrcyBzdWNjZWVkLgotVGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1Y2Nlc3Mg
YW5kIDEgb24gZmFpbHVyZS4KLQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxlIGZpbGVz
IGluIHRoaXMgZGlyZWN0b3J5IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18nLiBGaWxl
cyBjb250YWluaW5nIENIRUNLLUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hlY2ssIGFu
ZCBmaWxlcyBjb250YWluaW5nIENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBpbnN0YWxs
IGNoZWNrLgotCi1EZXRhaWxlZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBpcyBpbiAu
Y2hrYnVpbGQgZm9yIGJ1aWxkCi1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwgTm8gbmV3
bGluZSBhdCBlbmQgb2YgZmlsZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMg
dG9vbHMvY2hlY2svY2hlY2tfYnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNU
QUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJT
RCkKLQloYXNfb3JfZmFpbCBicmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwgYnJjdGwg
OzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEvdG9vbHMv
Y2hlY2svY2hlY2tfY3J5cHRvX2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBA
QAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNo
Ci0KLWNhc2UgJE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7OwotZXNh
YwotCi1oYXNfbGliIGxpYmNyeXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0by5zbyIK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX2N1
cmwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfY3VybAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAu
L2Z1bmNzLnNoCi0KLWlmIFsgIiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0aGVuCi0J
ZWNobyAtbiAidW51c2VkLCAiCi0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJsLWNvbmZp
ZwotY3VybF9saWJzPWBjdXJsLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29uZmlnIC0t
bGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxp
YnJhcmllcyBmb3IgY3VybCBhcmUgbWlzc2luZyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYw
NzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hlY2svY2hl
Y2tfaXByb3V0ZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBBVEgKLQot
Y2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgaWZjb25m
aWcgOzsKLUxpbnV4KQotCWhhc19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1Mi
IDs7Ci1lc2FjCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVj
ay9jaGVja19saWJhaW9fZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVs
CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0st
QlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9
IFgieSIgXSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGliYWlvLmgg
OyB0aGVuCi0gICAgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFsbCBsaWJh
aW8gZGV2ZWwgcGFja2FnZSBvciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZpCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9jaGVja19saWJhaW9f
bGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIJTW9uIEZlYiAyMCAxODozNDox
NCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwK
LQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIg
XSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWlsICJjYW4n
dCBmaW5kIGxpYmFpbyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xz
L2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNz
bF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMg
Q0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9tZDUuaCB8
fCBmYWlsICJtaXNzaW5nIG9wZW5zc2wgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
YjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9jaGVjay9j
aGVja19weXRob24JTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9z
aAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0
IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhPTn0gLWMg
JwotaW1wb3J0IHN5cwotc3lzLmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Igc3lzLnZl
cnNpb25faW5mb1sxXSA8IDMpCi0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24gPj0gMi4z
IgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMgdG9vbHMvY2hlY2svY2hlY2tf
cHl0aG9uX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlNb24gRmVi
IDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsMTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0
aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQg
b3MucGF0aCwgc3lzCi1mb3IgcCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0cyhwICsg
Ii9jb25maWcvTWFrZWZpbGUiKToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0nIHx8IGZh
aWwgImNhbid0IGZpbmQgcHl0aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAt
ciBiNjA3MWM3MTBmNmMgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90b29scy9j
aGVjay9jaGVja19weXRob25feG1sCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAt
eiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlU
SE9OfQotCi0ke1BZVEhPTn0gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rldi9udWxs
IHx8IFwKLWZhaWwgImNhbid0IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX3VkZXYJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgot
T3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7Ci1MaW51
eCkKLQloYXMgL3NiaW4vdWRldmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZhZG0gaW5m
byAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhhc19vcl9m
YWlsIHVkZXZpbmZvICYmIFwKLQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3twcmludCAk
TkZ9J2AKLQlbICIkdWRldnZlciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQloYXMgaG90
cGx1ZyB8fCBcCi0JCWZhaWwgInVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5
IG9yIGxhdGVyIgotCTs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2
ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsNyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNo
Ci0KLWhhc19oZWFkZXIgdXVpZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmggfHwgZmFp
bCAibWlzc2luZyB1dWlkIGhlYWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1yIGNhODBl
Y2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVsCi0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX3gxMV9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19o
ZWFkZXIgWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9pbmNsdWRl
L1gxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVkZS9YMTEv
a2V5c3ltZGVmLmggfHwgXAotd2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAx
MiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQot
aGFzX29yX2ZhaWwgeGdldHRleHQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZj
IHRvb2xzL2NoZWNrL2NoZWNrX3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1sMglNb24g
RmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxE
IENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQSV9CSU5E
SU5HUyIgPSAieSIgXQotdGhlbgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4aXQgMAot
ZmkKLQotaGFzX29yX2ZhaWwgeG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25maWcgLS1s
aWJzYCB8fCBmYWlsICJ4bWwyLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICR4bWwy
X2xpYnMgfHwgZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1pc3Npbmci
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9jaGVja195
YWpsX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDggKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9m
dW5jcy5zaAotCi1oYXNfaGVhZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNhbid0IGZp
bmQgeWFqbC95YWpsX3BhcnNlLmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8fCBmYWls
ICJjYW4ndCBmaW5kIHlhamwveWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8fCBmYWls
ICJjYW4ndCBmaW5kIGxpYnlhamwuc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcx
MGY2YyB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3psaWJfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBm
YWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYw
NzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3psaWJfbGliCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAk
T1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFz
X2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciBjYTgwZWNhOWNm
YTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3Vz
YWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFs
bHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90
LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5l
cmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2Jp
bgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIg
XTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBj
aGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hl
Y2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQg
MAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVz
YWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBj
aGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29u
dGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVz
YWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQot
ICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0g
ICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRo
ZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQot
ZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGlj
aCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAt
eiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVy
biAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0
byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBp
biAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0J
CQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUK
LQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVs
bCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5
c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBb
IC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAw
Ci0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAi
JENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQot
CQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAj
IGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhp
cyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0
Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3Jr
LgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNv
LmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JP
U1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91
Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9
ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JP
U1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIk
e09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZx
ICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkg
ewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1w
ZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1g
bWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+
JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5
IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiBy
ZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVh
c2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlm
aQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1y
b290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJu
aW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAk
Kn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZB
SUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFj
NzEwZjZjIHRvb2xzL2NvbmZpZy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5oLmluCVR1ZSBGZWIgMjEgMDE6NDA6MDQg
MjAxMiArMDEwMApAQCAtMCwwICsxLDE2IEBACisvKgorICogQ29weXJpZ2h0IChDKSAyMDEyCisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3Nl
ciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAorICogYnkgdGhlIEZyZWUgU29m
dHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lhbAorICog
ZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KKyAqCisgKiBU
aGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVz
ZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs
aWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJU
SUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqLworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
WUFKTF9ZQUpMX1ZFUlNJT05fSApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMg
dG9vbHMvY29uZmlndXJlLmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxOTIgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0
aCBhdXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsy
LjY3XSkKK0FDX0lOSVQoW1hlbiBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVyc2lvbi5z
aCAuLi94ZW4vTWFrZWZpbGVdKSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb21d
KQorQUNfQ09ORklHX1NSQ0RJUihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklMRVMoWy4u
L2NvbmZpZy9Ub29scy5ta10pCitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQorQUNfUFJF
RklYX0RFRkFVTFQoWy91c3JdKQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENoZWNrIGlm
IENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQg
YSB3YXJuaW5nCisKK0FTX0lGKFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElCUyRDUFBG
TEFHUyRDUFAiXSwgWworICAgIEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFHUywgTERG
TEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBS
RVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVO
RF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVNX0VYVEVO
U0lPTlMKK0FDX0NBTk9OSUNBTF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200X2luY2x1
ZGUoW200L2VuYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVfZmVhdHVy
ZS5tNF0pCittNF9pbmNsdWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVkZShbbTQv
cHl0aG9uX3htbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0pCittNF9p
bmNsdWRlKFttNC9weXRob25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5tNF0pCitt
NF9pbmNsdWRlKFttNC9vY2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xpYi5tNF0p
CittNF9pbmNsdWRlKFttNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVkZShbbTQv
dXVpZC5tNF0pCittNF9pbmNsdWRlKFttNC9wa2cubTRdKQorCisjIEVuYWJsZS9kaXNhYmxlIG9w
dGlvbnMKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeHNtXSwKKyAgICBbRW5hYmxlIFhTTSBz
ZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0pCitBWF9BUkdfRU5BQkxFX0FORF9F
WFBPUlQoW2dpdGh0dHBdLCBbRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUF0pCitB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFttb25pdG9yc10sCisgICAgW0Rpc2FibGUgeGVuc3Rh
dCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JU
KFt2dHBtXSwgW0VuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlXSkKK0FYX0FS
R19FTkFCTEVfQU5EX0VYUE9SVChbeGFwaV0sIFtFbmFibGUgWGVuIEFQSSBCaW5kaW5nc10pCitB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtweXRob250b29sc10sIFtEaXNhYmxlIFB5dGhvbiB0
b29sc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtvY2FtbHRvb2xzXSwgW0Rpc2FibGUg
T2NhbWwgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFttaW5pdGVybV0sIFtFbmFi
bGUgbWluaXRlcm1dKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtsb21vdW50XSwgW0VuYWJs
ZSBsb21vdW50XSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW2RlYnVnXSwgW0Rpc2FibGUg
ZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29sc10pCisKK0FDX0FSR19WQVIoW1BSRVBFTkRfSU5D
TFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRvIENGTEFH
UyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbUFJFUEVORF9MSUJdLAorICAgIFtMaXN0IG9m
IGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKK0FD
X0FSR19WQVIoW0FQUEVORF9JTkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJz
IHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9M
SUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAo
d2l0aG91dCAtTCldKQorCitBWF9TRVRfRkxBR1MKKworQUNfQVJHX1ZBUihbUFlUSE9OXSwgW1Bh
dGggdG8gdGhlIFB5dGhvbiBwYXJzZXJdKQorQUNfQVJHX1ZBUihbUEVSTF0sIFtQYXRoIHRvIFBl
cmwgcGFyc2VyXSkKK0FDX0FSR19WQVIoW0JSQ1RMXSwgW1BhdGggdG8gYnJjdGwgdG9vbF0pCitB
Q19BUkdfVkFSKFtJUF0sIFtQYXRoIHRvIGlwIHRvb2xdKQorQUNfQVJHX1ZBUihbQklTT05dLCBb
UGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0ZMRVhdLCBbUGF0
aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0NVUkxd
LCBbUGF0aCB0byBjdXJsLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW1hNTF0sIFtQYXRoIHRv
IHhtbDItY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZBUihbQkFTSF0sIFtQYXRoIHRvIGJhc2ggc2hl
bGxdKQorQUNfQVJHX1ZBUihbWEdFVFRFWFRdLCBbUGF0aCB0byB4Z2V0dHRleHQgdG9vbF0pCisK
KyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK0FDX1BST0dfU0VECitBQ19QUk9HX0NDCitBQ19QUk9H
X0xOX1MKK0FDX1BST0dfTUFLRV9TRVQKK0FDX1BST0dfSU5TVEFMTAorQVhfUEFUSF9QUk9HX09S
X0ZBSUwoW1BFUkxdLCBbcGVybF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQlJDVExdLCBbYnJj
dGxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQXSwgW2lwXSkKK0FYX1BBVEhfUFJPR19PUl9G
QUlMKFtCSVNPTl0sIFtiaXNvbl0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbRkxFWF0sIFtmbGV4
XSkKK0FTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5Il0sIFsKKyAgICBBWF9QQVRIX1BST0dfT1Jf
RkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hN
TF0sIFt4bWwyLWNvbmZpZ10pCitdKQorQVNfSUYoW3Rlc3QgIngkb2NhbWx0b29scyIgPSAieHki
XSwgWworICAgIEFDX1BST0dfT0NBTUwKKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMiID0gInhu
byJdLCBbCisgICAgICAgIEFTX0lGKFt0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVz
Il0sIFsKKyAgICAgICAgICAgIEFDX01TR19FUlJPUihbT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0
IHVuYWJsZSB0byBmaW5kIE9jYW1sXSldKQorICAgICAgICBvY2FtbHRvb2xzPSJuIgorICAgIF0p
CitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihbdGVzdCAi
eCRweXRob250b29scyIgPSAieHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9OIiB8IGdy
ZXAgLXEgIl4vIl0sIFsKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhP
Tj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJdLCBbUFlU
SE9OPSJweXRob24iXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVkLCBidXQg
aXMgbm90IGFuIGFic29sdXRlIHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BZ
VEhPTlBBVEhdLCBbJFBZVEhPTl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04oWzJdLCBb
M10pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9OX0RFVkVM
KCkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRdKQorQVhf
Q0hFQ0tfVURFVihbNTldKQorQVhfQ0hFQ0tfVVVJRAorUEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwg
Z2xpYi0yLjApCisKKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitBWF9ERUZBVUxUX0xJQgorCisjIENo
ZWNrcyBmb3IgbGlicmFyaWVzLgorQUNfQ0hFQ0tfTElCKFthaW9dLCBbaW9fc2V0dXBdLCBbc3lz
dGVtX2Fpbz0ieSJdLCBbc3lzdGVtX2Fpbz0ibiJdKQorQUNfU1VCU1Qoc3lzdGVtX2FpbykKK0FD
X0NIRUNLX0xJQihbY3J5cHRvXSwgW01ENV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3Qg
ZmluZCBsaWJjcnlwdG9dKV0pCitBQ19DSEVDS19MSUIoW2V4dDJmc10sIFtleHQyZnNfb3BlbjJd
LCBbbGliZXh0MmZzPSJ5Il0sIFtsaWJleHQyZnM9Im4iXSkKK0FDX1NVQlNUKGxpYmV4dDJmcykK
K0FDX0NIRUNLX0xJQihbZ2NyeXB0XSwgW2djcnlfbWRfaGFzaF9idWZmZXJdLCBbbGliZ2NyeXB0
PSJ5Il0sIFtsaWJnY3J5cHQ9Im4iXSkKK0FDX1NVQlNUKGxpYmdjcnlwdCkKK0FDX0NIRUNLX0xJ
QihbcHRocmVhZF0sIFtwdGhyZWFkX2NyZWF0ZV0sIFtdICwKKyAgICBbQUNfTVNHX0VSUk9SKFtD
b3VsZCBub3QgZmluZCBsaWJwdGhyZWFkXSldKQorQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19n
ZXR0aW1lXSkKK0FDX0NIRUNLX0xJQihbdXVpZF0sIFt1dWlkX2NsZWFyXSwgW10sCisgICAgW0FD
X01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGlidXVpZF0pXSkKK0FDX0NIRUNLX0xJQihbeWFq
bF0sIFt5YWpsX2FsbG9jXSwgW10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQg
eWFqbF0pXSkKK0FDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNfTVNHX0VS
Uk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQorQUNfQ0hFQ0tfTElCKFtpY29udl0sIFtsaWJp
Y29udl9vcGVuXSwgW2xpYmljb252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQorQUNfU1VCU1QobGli
aWNvbnYpCisKKyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCitBQ19GVU5DX0FMTE9DQQorQUNf
Q0hFQ0tfSEVBREVSUyhbIFwKKyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGlu
dHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAgICAgICBu
ZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBc
CisgICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21v
dW50Lmggc3lzL3BhcmFtLmggXAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3Rh
dHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAgICAgICB1
bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKyAgICAgICAgICAgICAgICBdKQorCisjIENo
ZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3Rp
Y3MuCitBQ19IRUFERVJfU1REQk9PTAorQUNfVFlQRV9VSURfVAorQUNfQ19JTkxJTkUKK0FDX1RZ
UEVfSU5UMTZfVAorQUNfVFlQRV9JTlQzMl9UCitBQ19UWVBFX0lOVDY0X1QKK0FDX1RZUEVfSU5U
OF9UCitBQ19UWVBFX01PREVfVAorQUNfVFlQRV9PRkZfVAorQUNfVFlQRV9QSURfVAorQUNfQ19S
RVNUUklDVAorQUNfVFlQRV9TSVpFX1QKK0FDX1RZUEVfU1NJWkVfVAorQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCitBQ19TVFJVQ1RfU1RfQkxPQ0tTCitBQ19DSEVD
S19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9yZGV2XSkKK0FDX1RZUEVfVUlOVDE2X1QKK0FDX1RZ
UEVfVUlOVDMyX1QKK0FDX1RZUEVfVUlOVDY0X1QKK0FDX1RZUEVfVUlOVDhfVAorQUNfQ0hFQ0tf
VFlQRVMoW3B0cmRpZmZfdF0pCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KK0FD
X0ZVTkNfRVJST1JfQVRfTElORQorQUNfRlVOQ19GT1JLCitBQ19GVU5DX0ZTRUVLTworQUNfRlVO
Q19MU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSworQUNfSEVBREVSX01BSk9SCitBQ19GVU5D
X01BTExPQworQUNfRlVOQ19NS1RJTUUKK0FDX0ZVTkNfTU1BUAorQUNfRlVOQ19SRUFMTE9DCitB
Q19GVU5DX1NUUk5MRU4KK0FDX0ZVTkNfU1RSVE9ECitBQ19DSEVDS19GVU5DUyhbIFwKKyAgICAg
ICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3lu
YyBmdHJ1bmNhdGUgXAorICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhv
c3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAgaW5ldF9u
dG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKKyAg
ICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1k
aXIgc2VsZWN0IHNldGVudiBcCisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3Ry
Y2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAgICAgIHN0
cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0
IFwKKyAgICAgICAgICAgICAgICB1bmFtZSBcCisgICAgICAgICAgICAgICAgXSkKKworQUNfT1VU
UFVUKCkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2RlYnVnZ2Vy
L2dkYnN4L3hnL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxl
CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9kZWJ1Z2dlci9nZGJz
eC94Zy9NYWtlZmlsZQlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTIxLDcgKzIx
LDYgQEAgeGdfYWxsLmE6ICQoWEdfT0JKUykgTWFrZWZpbGUgJChYR19IRFJTKQogIwkkKENDKSAt
bTMyIC1jIC1vICRAICReCiAKIHhlbi1oZWFkZXJzOgotCSQoTUFLRSkgLUMgLi4vLi4vLi4vY2hl
Y2sgCiAJJChNQUtFKSAtQyAuLi8uLi8uLi9pbmNsdWRlCiAKICMgeGdfbWFpbi5vOiB4Z19tYWlu
LmMgTWFrZWZpbGUgJChYR19IRFJTKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvaW5zdGFsbC5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi90b29scy9pbnN0YWxsLnNoCVR1ZSBGZWIgMjEgMDE6NDA6MDQgMjAxMiAr
MDEwMApAQCAtMCwwICsxLDEgQEAKKy4uL2luc3RhbGwuc2gKXCBObyBuZXdsaW5lIGF0IGVuZCBv
ZiBmaWxlCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9saWJmc2lt
YWdlL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJVHVlIEZl
YiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0zLDcgKzMsMTEgQEAgaW5jbHVkZSAkKFhFTl9S
T09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNlcmZzIGlz
bzk2NjAgZmF0IHpmcwogU1VCRElSUy0kKENPTkZJR19YODYpICs9IHhmcwotU1VCRElSUy15ICs9
ICQoc2hlbGwgZW52IENDPSIkKENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgkKENPTkZJ
R19FWFQyRlMpLCB5KQorICAgIFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisgICAgU1VC
RElSUy15ICs9IGV4dDJmcworZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFsbAogYWxs
IGNsZWFuIGluc3RhbGw6ICU6IHN1YmRpcnMtJQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3
MWM3MTBmNmMgdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9vbHMvbGli
ZnNpbWFnZS9jaGVjay1saWJleHQyZnMJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIxICswLDAg
QEAKLSMhL2Jpbi9zaAotCi1jYXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8ZXh0MmZz
L2V4dDJmcy5oPgotCi1pbnQgbWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9GCi0KLSR7
Q0MtZ2NjfSAtbyBleHQyLXRlc3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVsbCAyPiYx
Ci1pZiBbICQ/ID0gMCBdOyB0aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNobyBleHQy
ZnMKLWZpCi0KLXJtIC1mIGV4dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQotLS0gYS90
b29scy9saWJ4ZW4vTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBi
L3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAg
LTIyLDEyICsyMiwxMiBAQCBNQUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtSWlu
Y2x1ZGUgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwyLWNvbmZp
ZyAtLWNmbGFncykgXAotICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxhZ3MpIFwK
KyAgICAgICAgICAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAgICAgICAg
JChzaGVsbCAkKENVUkxfQ09ORklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElDCiAKLUxE
RkxBR1MgKz0gJChzaGVsbCB4bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAgJChzaGVs
bCBjdXJsLWNvbmZpZyAtLWxpYnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyX0NPTkZJRykg
LS1saWJzKSBcCisgICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1saWJzKQogCiBM
SUJYRU5BUElfSERSUyA9ICQod2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5jbHVkZS94
ZW4vYXBpL3hlbl9hbGwuaAogTElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywgJS5vLCAk
KHdpbGRjYXJkIHNyYy8qLmMpKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMg
dG9vbHMvbGlieGwvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCVR1ZSBGZWIg
MjEgMDE6NDA6MDQgMjAxMiArMDEwMApAQCAtMTksMTAgKzE5LDYgQEAgaWZlcSAoJChDT05GSUdf
TGludXgpLHkpCiBMSUJVVUlEX0xJQlMgKz0gLWx1dWlkCiBlbmRpZgogCi1pZmVxICgkKENPTkZJ
R19ZQUpMX1ZFUlNJT04pLHkpCi1DRkxBR1MgKz0gLURIQVZFX1lBSkxfVkVSU0lPTgotZW5kaWYK
LQogTElCWExfTElCUyA9CiBMSUJYTF9MSUJTID0gJChMRExJQlNfbGlieGVuY3RybCkgJChMRExJ
QlNfbGlieGVuZ3Vlc3QpICQoTERMSUJTX2xpYnhlbnN0b3JlKSAkKExETElCU19saWJibGt0YXBj
dGwpICQoVVRJTF9MSUJTKSAkKExJQlVVSURfTElCUykKIApAQCAtNTYsNyArNTIsNyBAQCBMSUJY
TF9PQkpTID0gZmxleGFycmF5Lm8gbGlieGwubyBsaWJ4bF9jCiAJCQlsaWJ4bF9xbXAubyBsaWJ4
bF9ldmVudC5vICQoTElCWExfT0JKUy15KQogTElCWExfT0JKUyArPSBfbGlieGxfdHlwZXMubyBs
aWJ4bF9mbGFzay5vIF9saWJ4bF90eXBlc19pbnRlcm5hbC5vCiAKLSQoTElCWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxB
R1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkKKyQoTElCWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxB
R1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkgLWluY2x1ZGUgJChYRU5fUk9P
VCkvdG9vbHMvY29uZmlnLmgKIAogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhsdV9jZmdf
bC5oIF9saWJ4bF9saXN0LmgKIEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVfY2ZnX2wu
YwpAQCAtNjksNiArNjUsNyBAQCBDTElFTlRTID0geGwgdGVzdGlkbAogWExfT0JKUyA9IHhsLm8g
eGxfY21kaW1wbC5vIHhsX2NtZHRhYmxlLm8geGxfc3hwLm8KICQoWExfT0JKUyk6IENGTEFHUyAr
PSAkKENGTEFHU19saWJ4ZW5jdHJsKSAjIEZvciB4ZW50b29sbG9nLmgKICQoWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5saWdodCkKKyQoWExfT0JKUyk6IENGTEFHUyArPSAtaW5j
bHVkZSAkKFhFTl9ST09UKS90b29scy9jb25maWcuaCAjIGxpYnhsX2pzb24uaCBuZWVkcyBpdC4K
IAogdGVzdGlkbC5vOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxBR1NfbGli
eGVubGlnaHQpCiB0ZXN0aWRsLmM6IGxpYnhsX3R5cGVzLmlkbCBnZW50ZXN0LnB5IGxpYnhsLmgg
JChBVVRPSU5DUykKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2xp
YnhsL2xpYnhsX2pzb24uaAotLS0gYS90b29scy9saWJ4bC9saWJ4bF9qc29uLmgJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24uaAlUdWUg
RmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTE4LDcgKzE4LDcgQEAKICNpbmNsdWRlIDx5
YWpsL3lhamxfZ2VuLmg+CiAjaW5jbHVkZSA8eWFqbC95YWpsX3BhcnNlLmg+CiAKLSNpZmRlZiBI
QVZFX1lBSkxfVkVSU0lPTgorI2lmZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAogIyAgaW5j
bHVkZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4KICNlbmRpZgogCmRpZmYgLXIgY2E4MGVjYTljZmEz
IC1yIGI2MDcxYzcxMGY2YyB0b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0X2xpYi5t
NAlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitBQ19ERUZV
TihbQVhfREVGQVVMVF9MSUJdLAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0Il0sIFsK
KyAgICBMSUJfUEFUSD0ibGliNjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkKK0FDX1NV
QlNUKExJQl9QQVRIKV0pCisKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRv
b2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJVHVlIEZlYiAy
MSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdf
RElTQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9T
VFJJTkcoWy0tZGlzYWJsZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEi
ID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0g
Inh5ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWwor
ICAgIGF4X2N2XyQxPSJ5IgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L200L2VuYWJsZV9mZWF0dXJlLm00CVR1ZSBGZWIgMjEgMDE6NDA6MDQgMjAxMiArMDEwMApAQCAt
MCwwICsxLDEzIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19B
UkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwgWyQyXSkp
CisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9
InkiCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4i
CitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQorJDE9JGF4
X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvbTQvb2NhbWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvb2NhbWwubTQJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAor
ZG5sIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5cmlnaHQg
wqkgMjAwOSAgICAgIFJpY2hhcmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAyMDA5ICAg
ICAgU3RlZmFubyBaYWNjaGlyb2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBPbGl2aWVy
IEFuZHJpZXUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3BoZSBGaWxs
acOidHJlCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8KK2RubAor
ZG5sIEZvciBkb2N1bWVudGF0aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFuIHBhZ2Uu
CisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2Nh
bWxjCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBpZiB0ZXN0
ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8
IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19NU0dfUkVT
VUxUKFtPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9DQU1MTElC
IGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgorICAg
ICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0
YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0dfUkVTVUxU
KFtPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBmaQorICAg
ICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkKKworICAg
ICBBQ19TVUJTVChbT0NBTUxWRVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElCXSkKKwor
ICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTE9Q
VF0sW29jYW1sb3B0XSxbbm9dKQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0ZXN0ICIk
T0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBvY2FtbG9w
dDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1g
JE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAor
CWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFD
X01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2Nh
cmRlZC5dKQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZp
CisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxjLm9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRdLFtvY2Ft
bGMub3B0XSxbbm9dKQorICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVu
CisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24q
ICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJ
T04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2Nh
bWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENE
T1RPUFQKKwlmaQorICAgICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAor
ICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tfVE9PTChb
T0NBTUxPUFRET1RPUFRdLFtvY2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9DQU1MT1BU
RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12
IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3Qg
IiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNfTVNHX1JF
U1VMVChbdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVk
Ll0pCisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZpCisg
ICAgICAgIGZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAgZmkKKwor
ICBBQ19TVUJTVChbT0NBTUxDXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAor
ICBBQ19DSEVDS19UT09MKFtPQ0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9y
IG9jYW1sZGVwCisgIEFDX0NIRUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtub10pCisK
KyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LVE9Q
XSxbb2NhbWxta3RvcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCisgIEFD
X0NIRUNLX1RPT0woW09DQU1MTUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZG9jCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxkb2NdLFtu
b10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09MKFtPQ0FN
TEJVSUxEXSxbb2NhbWxidWlsZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfT0NB
TUxMRVhdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTExFWF0sW29jYW1sbGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgiICE9ICJu
byI7IHRoZW4KKyAgICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1sbGV4Lm9w
dF0sW25vXSkKKyAgICBpZiB0ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRoZW4KKwlP
Q0FNTExFWD0kT0NBTUxMRVhET1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChbT0NBTUxM
RVhdKQorXSkKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAgQUNfQ0hF
Q0tfVE9PTChbT0NBTUxZQUNDXSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChbT0NBTUxZ
QUNDXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAgQUNfUkVR
VUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0CisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENBTUxQNCIg
IT0gIm5vIjsgdGhlbgorICAgICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNlZCAtbiAt
ZSAnc3wuKnZlcnNpb24gKlwoLipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9O
IiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlm
ZmVycyBmcm9tIG9jYW1sY10pCisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBmaQorICBB
Q19TVUJTVChbQ0FNTFA0XSkKKworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9vbHMKKyAg
QUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFDX0NIRUNL
X1RPT0woW0NBTUxQNE9dLFtjYW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRP
Rl0sW2NhbWxwNG9mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtjYW1scDRv
b2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0sW25vXSkK
KyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisgIEFDX0NI
RUNLX1RPT0woW0NBTUxQNFJdLFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1M
UDRSRl0sW2NhbWxwNHJmXSxbbm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisgIEFDX1NV
QlNUKFtDQU1MUDRPXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQ
NE9PRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0UFJPRl0p
CisgIEFDX1NVQlNUKFtDQU1MUDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10pCisKKwor
QUNfREVGVU4oW0FDX1BST0dfRklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0df
T0NBTUxdKWRubAorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTEZJTkRdLFtvY2FtbGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJTkRdKQor
XSkKKworCitkbmwgVGhhbmtzIHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlzIG5leHQg
Yml0IG91dCBmb3IgdXMuCitkbmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0ggaWYgaXQn
cyBub3QgZGVmaW5lZCBhbHJlYWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4KK0FDX0RF
RlVOKFtBQ19DSEVDS19PQ0FNTF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX0ZJ
TkRMSUJdKWRubAorCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIgcGFja2Fn
ZSAkMV0pCisKKyAgdW5zZXQgZm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisgIGZvciBw
a2cgaW4gJDEgJDIgOyBkbworICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rldi9udWxs
IDI+L2Rldi9udWxsOyB0aGVuCisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisgICAgICBB
U19UUl9TSChbT0NBTUxfUEtHXyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAgICBicmVh
aworICAgIGZpCisgIGRvbmUKKyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVuCisgICAg
QUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9
bm8KKyAgZmkKKworICBBQ19TVUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitdKQorCisK
K0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0dfQ0hFQ0tJ
TkcoW2ZvciBPQ2FtbCBtb2R1bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCitv
cGVuICQzCitFT0YKKyAgdW5zZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRvCisgICAg
aWYgJE9DQU1MQyAtYyAtSSAiJCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4KKyAgICAg
IGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVzdCAiJGZv
dW5kIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAgQUNfTVNH
X1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChbJDFdKQor
XSkKKworCitkbmwgWFhYIENyb3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1M
X1dPUkRfU0laRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBjYXQgPiBj
b25mdGVzdC5tbCA8PEVPRgorICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5cy53b3Jk
X3NpemUpCisgIEVPRgorICBPQ0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAg
QUNfTVNHX1JFU1VMVChbJE9DQU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9XT1JE
X1NJWkVdKQorXSkKKworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAorW2RubAor
ICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtPQ2Ft
bCBTeXMub3NfdHlwZV0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfc3Ry
aW5nKFN5cy5vc190eXBlKTs7CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwgY29uZnRl
c3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VCU1QoW09D
QU1MX09TX1RZUEVdKQorXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRv
b2xzL200L3BhdGhfb3JfZmFpbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9wYXRoX29yX2ZhaWwubTQJVHVlIEZlYiAyMSAwMTo0
MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhfUFJPR19P
Ul9GQUlMXSwKK1tBQ19QQVRIX1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3QgeCIkeyQx
fSIgPT0geCJubyIgCit0aGVuCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCAkMiwg
cGxlYXNlIGluc3RhbGwgJDJdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3
MTBmNmMgdG9vbHMvbTQvcGtnLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL3Rvb2xzL200L3BrZy5tNAlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxNTcgQEAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQg
dXRpbGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgc2VyaWFs
IDEgKHBrZy1jb25maWctMC4yNCkKKyMgCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVz
IFJlbW5hbnQgPHNjb3R0QG5ldHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisjIGl0IHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlz
aGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIg
b2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24u
CisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdp
bGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1Ig
QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv
cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGggdGhpcyBw
cm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5kYXRpb24s
IEluYy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3
LCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBh
IHByb2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRl
ZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3Ry
aWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4K
KworIyBQS0dfUFJPR19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfUFJPR19QS0dfQ09ORklHXSwKK1tt
NF9wYXR0ZXJuX2ZvcmJpZChbXl8/UEtHX1tBLVpfXSskXSkKK200X3BhdHRlcm5fYWxsb3coW15Q
S0dfQ09ORklHKF9QQVRIKT8kXSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUddLCBbcGF0aCB0byBw
a2ctY29uZmlnIHV0aWxpdHldKQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19QQVRIXSwgW2RpcmVj
dG9yaWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGhdKQorQUNfQVJHX1ZBUihb
UEtHX0NPTkZJR19MSUJESVJdLCBbcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBidWlsdC1p
biBzZWFyY2ggcGF0aF0pCisKK2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05GSUdfc2V0IiAh
PSAieHNldCI7IHRoZW4KKwlBQ19QQVRIX1RPT0woW1BLR19DT05GSUddLCBbcGtnLWNvbmZpZ10p
CitmaQoraWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisJX3BrZ19taW5fdmVyc2lvbj1t
NF9kZWZhdWx0KFskMV0sIFswLjkuMF0pCisJQUNfTVNHX0NIRUNLSU5HKFtwa2ctY29uZmlnIGlz
IGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb25dKQorCWlmICRQS0dfQ09ORklHIC0t
YXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgorCQlBQ19N
U0dfUkVTVUxUKFt5ZXNdKQorCWVsc2UKKwkJQUNfTVNHX1JFU1VMVChbbm9dKQorCQlQS0dfQ09O
RklHPSIiCisJZmkKK2ZpW11kbmwKK10pIyBQS0dfUFJPR19QS0dfQ09ORklHCisKKyMgUEtHX0NI
RUNLX0VYSVNUUyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9V
TkRdKQorIworIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVs
ZXMgZXhpc3RzLiAgU2ltaWxhcgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBu
b3Qgc2V0IHZhcmlhYmxlcyBvciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1lbWJlciB0
aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisjIG9ubHkg
YXQgdGhlIGZpcnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBw
bGFjZQorIyBpdCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdp
dGhpbiBhbiAiaWYiLCB5b3UKKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFs
bHkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfRVhJU1RTXSwKK1tBQ19SRVFVSVJFKFtQ
S0dfUFJPR19QS0dfQ09ORklHXSlkbmwKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCisg
ICAgQUNfUlVOX0xPRyhbJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgIiQxIl0p
OyB0aGVuCisgIG00X2RlZmF1bHQoWyQyXSwgWzpdKQorbTRfaWZ2YWxuKFskM10sIFtlbHNlCisg
ICQzXSlkbmwKK2ZpXSkKKworIyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFORF0sIFtN
T0RVTEVTXSkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CittNF9kZWZpbmUoW19QS0dfQ09ORklHXSwKK1tpZiB0ZXN0IC1uICIkJDEiOyB0aGVuCisgICAg
cGtnX2N2X1tdJDE9IiQkMSIKKyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorICAg
IFBLR19DSEVDS19FWElTVFMoWyQzXSwKKyAgICAgICAgICAgICAgICAgICAgIFtwa2dfY3ZfW10k
MT1gJFBLR19DT05GSUcgLS1bXSQyICIkMyIgMj4vZGV2L251bGxgXSwKKwkJICAgICBbcGtnX2Zh
aWxlZD15ZXNdKQorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2ZpW11kbmwKK10pIyBf
UEtHX0NPTkZJRworCisjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQorQUNfREVGVU4oW19QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRF
RF0sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCitpZiAkUEtHX0NPTkZJRyAt
LWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0
X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1
cHBvcnRlZD1ubworZmlbXWRubAorXSkjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorCisK
KyMgUEtHX0NIRUNLX01PRFVMRVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNUSU9OLUlG
LUZPVU5EXSwKKyMgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQorIworIworIyBOb3RlIHRoYXQgaWYg
dGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bworIyBQS0dfQ0hFQ0tfTU9E
VUxFUyBtaWdodCBub3QgaGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgor
IyBleHBsaWNpdCBjYWxsIHRvIFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25maWd1cmUu
YWMKKyMKKyMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfTU9EVUxFU10sCitbQUNfUkVR
VUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0NGTEFHU10s
IFtDIGNvbXBpbGVyIGZsYWdzIGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlkbmwKK0FD
X0FSR19WQVIoWyQxXVtfTElCU10sIFtsaW5rZXIgZmxhZ3MgZm9yICQxLCBvdmVycmlkaW5nIHBr
Zy1jb25maWddKWRubAorCitwa2dfZmFpbGVkPW5vCitBQ19NU0dfQ0hFQ0tJTkcoW2ZvciAkMV0p
CisKK19QS0dfQ09ORklHKFskMV1bX0NGTEFHU10sIFtjZmxhZ3NdLCBbJDJdKQorX1BLR19DT05G
SUcoWyQxXVtfTElCU10sIFtsaWJzXSwgWyQyXSkKKworbTRfZGVmaW5lKFtfUEtHX1RFWFRdLCBb
QWx0ZXJuYXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyAkMVtd
X0NGTEFHUworYW5kICQxW11fTElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBjYWxsIHBrZy1jb25m
aWcuCitTZWUgdGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy5dKQorCitp
ZiB0ZXN0ICRwa2dfZmFpbGVkID0geWVzOyB0aGVuCisgICAJQUNfTVNHX1JFU1VMVChbbm9dKQor
ICAgICAgICBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKKyAgICAgICAgaWYgdGVzdCAkX3Br
Z19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICAkMVtdX1BLR19F
UlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICIkMiIgMj4m
MWAKKyAgICAgICAgZWxzZSAKKwkgICAgICAgICQxW11fUEtHX0VSUk9SUz1gJFBLR19DT05GSUcg
LS1wcmludC1lcnJvcnMgIiQyIiAyPiYxYAorICAgICAgICBmaQorCSMgUHV0IHRoZSBuYXN0eSBl
cnJvciBtZXNzYWdlIGluIGNvbmZpZy5sb2cgd2hlcmUgaXQgYmVsb25ncworCWVjaG8gIiQkMVtd
X1BLR19FUlJPUlMiID4mQVNfTUVTU0FHRV9MT0dfRkQKKworCW00X2RlZmF1bHQoWyQ0XSwgW0FD
X01TR19FUlJPUigKK1tQYWNrYWdlIHJlcXVpcmVtZW50cyAoJDIpIHdlcmUgbm90IG1ldDoKKwor
JCQxX1BLR19FUlJPUlMKKworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEgg
ZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24t
c3RhbmRhcmQgcHJlZml4LgorCitfUEtHX1RFWFRdKWRubAorICAgICAgICBdKQorZWxpZiB0ZXN0
ICRwa2dfZmFpbGVkID0gdW50cmllZDsgdGhlbgorICAgICAJQUNfTVNHX1JFU1VMVChbbm9dKQor
CW00X2RlZmF1bHQoWyQ0XSwgW0FDX01TR19GQUlMVVJFKAorW1RoZSBwa2ctY29uZmlnIHNjcmlw
dCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4g
eW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0
aGUgZnVsbAorcGF0aCB0byBwa2ctY29uZmlnLgorCitfUEtHX1RFWFQKKworVG8gZ2V0IHBrZy1j
b25maWcsIHNlZSA8aHR0cDovL3BrZy1jb25maWcuZnJlZWRlc2t0b3Aub3JnLz4uXSlkbmwKKyAg
ICAgICAgXSkKK2Vsc2UKKwkkMVtdX0NGTEFHUz0kcGtnX2N2X1tdJDFbXV9DRkxBR1MKKwkkMVtd
X0xJQlM9JHBrZ19jdl9bXSQxW11fTElCUworICAgICAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
CSQzCitmaVtdZG5sCitdKSMgUEtHX0NIRUNLX01PRFVMRVMKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgYjYwNzFjNzEwZjZjIHRvb2xzL200L3B5dGhvbl9kZXZlbC5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25fZGV2ZWwu
bTQJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTggQEAKK0FDX0RF
RlVOKFtBWF9DSEVDS19QWVRIT05fREVWRUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhv
biBkZXZlbF0pCisKK2AkUFlUSE9OIC1jICcKK2ltcG9ydCBvcy5wYXRoLCBzeXMKK2ZvciBwIGlu
IHN5cy5wYXRoOgorICAgIGlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIp
OgorICAgICAgICBzeXMuZXhpdCgwKQorc3lzLmV4aXQoMSkKKycgPiAvZGV2L251bGwgMj4mMWAK
KworaWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAg
ICBBQ19NU0dfRVJST1IoW1B5dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZF0pCitlbHNlCisg
ICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYw
NzFjNzEwZjZjIHRvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00Ci0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00
CVR1ZSBGZWIgMjEgMDE6NDA6MDQgMjAxMiArMDEwMApAQCAtMCwwICsxLDEyIEBACitBQ19ERUZV
TihbQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT05dLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhv
biB2ZXJzaW9uID49ICQxLiQyIF0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgZXhpdChldmFs
KCJzeXMudmVyc2lvbl9pbmZvIDwgKCQxLCAkMikiKSknYAoraWYgdGVzdCAiJD8iICE9ICIwIgor
dGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFgCisgICAgQUNfTVNHX1JF
U1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUigKKyAgICAgICAgWyRweXRob25fdmVyc2lvbiBp
cyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgJDEuJDJdKQorZWxzZQorICAg
IEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcx
YzcxMGY2YyB0b29scy9tNC9weXRob25feG1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl94bWwubTQJVHVlIEZlYiAy
MSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9DSEVD
S19QWVRIT05fWE1MXSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24geG1sLmRvbS5taW5p
ZG9tXSkKK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRlc3QgIiQ/
IiAhPSAiMCIKK3RoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9S
KFtVbmFibGUgdG8gZmluZCB4bWwuZG9tLm1pbmlkb20gbW9kdWxlXSkKK2Vsc2UKKyAgICBBQ19N
U0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvbTQvc2V0X2NmbGFnc19sZGZsYWdzLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5t
NAlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyMCBAQAorQUNfREVG
VU4oW0FYX1NFVF9GTEFHU10sCitbZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCitkbwor
ICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkUFJF
UEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2Zv
ciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkk
Y2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9M
REZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxB
R1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRB
UFBFTkRfTERGTEFHUyJdKQorCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0
b29scy9tNC91ZGV2Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL200L3VkZXYubTQJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMzIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0ZXN0ICJ4
JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgIEFDX1BBVEhfUFJPRyhbVURFVkFE
TV0sIFt1ZGV2YWRtXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJubyIg
CisgICAgdGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW1VERVZJTkZPXSwgW3VkZXZpbmZvXSwg
W25vXSkKKyAgICAgICAgaWYgdGVzdCB4IiR7VURFVklORk99IiA9PSB4Im5vIgorICAgICAgICB0
aGVuCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoCisgICAgICAgICAgICAgICAgW1VuYWJsZSB0
byBmaW5kIHVkZXZhZG0gb3IgdWRldmluZm8sIHBsZWFzZSBpbnN0YWxsIHVkZXZdKQorICAgICAg
ICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0n
YAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAg
dGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW0hPVFBMVUddLCBbaG90cGx1Z10sIFtub10pCisg
ICAgICAgIGlmIHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAg
ICAgICAgICBBQ19NU0dfRVJST1IoW3VkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9u
IDU5IG9yIGxhdGVyXSkKKyAgICAgICAgZmkKKyAgICBmaQorZWxzZQorICAgIEFDX1BBVEhfUFJP
RyhbVk5DT05GSUddLCBbdm5jb25maWddLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1ZOQ09ORklH
fSIgPT0geCJubyIKKyAgICB0aGVuCisgICAgICAgIEFDX01TR19FUlJPUihbTm90IGEgTGludXgg
c3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmRdKQorICAgIGZpCitmaQorXSkKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL200L3V1aWQubTQKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdXVpZC5tNAlU
dWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNfREVGVU4o
W0FYX0NIRUNLX1VVSURdLAorW2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0
aGVuCisgICAgQUNfQ0hFQ0tfSEVBREVSKFt1dWlkL3V1aWQuaF0sLAorCSAgICBbQUNfTVNHX0VS
Uk9SKFtjYW5ub3QgZmluZCB1dWlkIGhlYWRlcnNdKV0pCitlbHNlCisgICAgQUNfQ0hFQ0tfSEVB
REVSKFt1dWlkLmhdLCwKKwkgICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFk
ZXJzXSldKQorZmkKK10pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB2ZXJz
aW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3ZlcnNpb24uc2gJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsNSBA
QAorIyEvYmluL3NoCisKK01BSk9SPWBncmVwICJleHBvcnQgWEVOX1ZFUlNJT04iICQxIHwgc2Vk
ICdzLy4qPS8vZycgfCB0ciAtcyAiICJgCitNSU5PUj1gZ3JlcCAiZXhwb3J0IFhFTl9TVUJWRVJT
SU9OIiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorcHJpbnRmICIlZC4lZCIgJE1B
Sk9SICRNSU5PUgo=

--===============5240906552094329370==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5240906552094329370==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 12:00:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12: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 1RzoOb-0005W5-Iu; Tue, 21 Feb 2012 12:00:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzoOa-0005VY-Aj
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:00:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329825627!16206308!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2161 invoked from network); 21 Feb 2012 12:00:27 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:00:27 -0000
Received: by wgbdy1 with SMTP id dy1so4148994wgb.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:00:27 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.86.198 as permitted sender) client-ip=10.180.86.198; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.86.198 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.86.198])
	by 10.180.86.198 with SMTP id r6mr25993091wiz.22.1329825627491
	(num_hops = 1); Tue, 21 Feb 2012 04:00:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=jdpDwKU732YCTKZM/VrV5cNZh4umpufXsl7bRsjQQqc=;
	b=Obqx6tVvSLjhZGNgpLn0RhGc+yIi2rGA9ew4ciwOOkzz2E2kLueL8a0w/85QzXbXtb
	3IfcEzp9AX8TTHyxWCfxlrUwwNwTuz1VgmdAKDSI575V26BB4uGMJN5aXomUc47X8j0o
	xWO/0NgDZ4NYgfr3dyE2+ehV9z8BHXiaM22BU=
Received: by 10.180.86.198 with SMTP id r6mr21756242wiz.22.1329825627417;
	Tue, 21 Feb 2012 04:00:27 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm54565342wib.8.2012.02.21.04.00.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 04:00:26 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============5240906552094329370=="
MIME-Version: 1.0
X-Mercurial-Node: b6071c710f6cb6200aaf134a46e80bc937382f7a
Message-Id: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 02:01:27 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH v6] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5240906552094329370==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v5:

 * Remove dummy configure generation from autogen.sh since it's
   already on the source tree.

 * Removed autogen.sh since it was only a wrapper for calling
   autoconf.

 * Remove comment regarding yajl_version.h from configure.ac.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    2 -
 README                            |    4 +
 config/Tools.mk.in                |   50 +++++++
 configure                         |    2 +
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  192 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 54 files changed, 836 insertions(+), 511 deletions(-)



--===============5240906552094329370==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzg0ODA0IC0zNjAwCiMgTm9kZSBJRCBiNjA3MWM3MTBm
NmNiNjIwMGFhZjEzNGE0NmU4MGJjOTM3MzgyZjdhCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY1OgoKICogUmVtb3ZlIGR1
bW15IGNvbmZpZ3VyZSBnZW5lcmF0aW9uIGZyb20gYXV0b2dlbi5zaCBzaW5jZSBpdCdzCiAgIGFs
cmVhZHkgb24gdGhlIHNvdXJjZSB0cmVlLgoKICogUmVtb3ZlZCBhdXRvZ2VuLnNoIHNpbmNlIGl0
IHdhcyBvbmx5IGEgd3JhcHBlciBmb3IgY2FsbGluZwogICBhdXRvY29uZi4KCiAqIFJlbW92ZSBj
b21tZW50IHJlZ2FyZGluZyB5YWpsX3ZlcnNpb24uaCBmcm9tIGNvbmZpZ3VyZS5hYy4KCkNoYW5n
ZXMgc2luY2UgdjQ6CgogKiBVcGRhdGVkIHRvIHRpcC4KCiAqIEluY2x1ZGUgY29uZmlnLmggZnJv
bSBjb21waWxlciBjb21tYW5kIGxpbmUgd2hlbiBidWlsZGluZyBsaWJ4bCBhbmQKICAgeGwgdG8g
YXNzdXJlIHlhamxfdmVyc2lvbi5oIHByZXNlbmNlIGFuZCBjb3JyZWN0bHkgZGV0ZWN0IHlhamwK
ICAgdmVyc2lvbi4KCiAqIEFkZGVkIGdsaWItMi4wIGNoZWNrIHdpdGggYXBwcm9waWF0ZSBtNCBt
YWNyb3MuCgogKiBQdXJnZWQgY29uZmlnLmguaW4gZnJvbSB1bm5lY2Vzc2FyeSBkZWZpbmVzIHRo
YXQgY291bGQgbWVzcyB3aXRoCiAgIHRoZSBidWlsZCBzeXN0ZW0uCgogKiBSZW1vdmVkIHRvb2xz
L2NvbmZpZy5zdWIsIHRvb2xzL2NvbmZpZy5ndWVzcywgdG9vbHMvY29uZmlndXJlIGFuZAogICBj
b25maWd1cmUgdG8gbWFrZSB0aGUgcGF0Y2ggZml0IG1haWxpbmcgbGlzdCBsaW1pdC4KCkNoYW5n
ZXMgc2luY2UgdjM6CgogKiBDb3BpZWQgY29uZmlnLmd1ZXNzIGFuZCBjb25maWcuc3ViIGZyb20g
YXV0b21ha2UgMS4xMS4KCiAqIEFkZGVkIGEgdGVzdCB0byBjaGVjayBmb3IgdXVpZC5oIG9uIEJT
RCBhbmQgdXVpZC91dWlkLmggb24gTGludXguCgpDaGFuZ2VzIHNpbmNlIHYyOgoKICogQ2hhbmdl
ZCBvcmRlciBvZiBjb25maWcvVG9vbHMubWsgaW5jbHVkZS4KCiAqIEFkZGVkICItZSIgdG8gYXV0
b2dlbi5zaCBzaGViYW5nLgoKICogQWRkZWQgbmVjZXNzYXJ5IGZpbGVzIChjb25maWcuKikgYW5k
IG91dHB1dCBmcm9tIEF1dG9oZWFkZXIgYW5kCiAgIEF1dG9jb25mLgoKICogUmVtb3ZlZCBBdXRv
Y29uZiBmcm9tIGJ1aWxkIGRlcGVuZGVuY2llcyBhbmQgdXBkYXRlZCBSRUFETUUuCgpDaGFuZ2Vz
IHNpbmNlIHYxOgoKICogTW92ZWQgYXV0b2NvbmYgc3R1ZmYgaW5zaWRlIHRvb2xzIGZvbGRlci4K
CiAqIEFkZCBNYWtlZmlsZSBydWxlcyBmb3IgY2xlYW5pbmcuCgogKiBSZW1vdmVkIEF1dG9tYWtl
IGRlcGVuZGVuY3kuCgogKiBDcmVhdGUgYXV0b2dlbi5zaCB0byBhdXRvbWF0aWNhbGx5IGNyZWF0
ZSBjb25maWd1cmUgc2NyaXB0IHdoZW4KICAgYnVpbGRpbmcgZnJvbSBzb3VyY2UgcmVwb3NpdG9y
eS4KCiAqIENhY2hlZCB2YWx1ZXMgb2Ygb3B0aW9ucyBwYXNzZWQgZnJvbSBjb21tYW5kIGxpbmUu
CgogKiBBZGQgbmVjZXNzYXJ5IGlnbm9yZXMgdG8gLmhnaWdub3JlLgoKICogQWRkZWQgQXV0b2Nv
bmYgdG8gdGhlIGxpc3Qgb2YgZGVwZW5kZW5jaWVzLgoKICogQ2hhbmdlZCBoeXBlbiB0byB1bmRl
cnNjb3JlIGluIFhNTDIgYW5kIENVUkwgdmFyaWFibGUgbmFtZXMuCgogKiBBZGRlZCBzY3JpcHQg
dG8gZ2V0IHZlcnNpb24gZnJvbSB4ZW4vTWFrZWZpbGUuCgogKiBTZXQgT2NhbWwgdG9vbHMgdG8g
b3B0aW9uYWwuCgogKiBBZGRlZCBwcm9jZWRlbmNlIG9mIG00L29jYW1sLm00LgoKU2lnbmVkLW9m
Zi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyAuaGdpZ25vcmUKLS0tIGEvLmhnaWdub3JlCU1v
biBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi8uaGdpZ25vcmUJVHVlIEZlYiAyMSAw
MTo0MDowNCAyMDEyICswMTAwCkBAIC0zMDMsNiArMzAzLDEyIEBACiBedG9vbHMvb2NhbWwvbGli
cy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWxpJAog
XnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3RvcmVkJAorXnRvb2xzL2F1dG9tNHRlXC5jYWNo
ZSQKK150b29scy9jb25maWdcLmgkCitedG9vbHMvY29uZmlnXC5sb2ckCitedG9vbHMvY29uZmln
XC5zdGF0dXMkCitedG9vbHMvY29uZmlnXC5jYWNoZSQKK15jb25maWcvVG9vbHNcLm1rJAogXnhl
bi9cLmJhbm5lci4qJAogXnhlbi9CTE9HJAogXnhlbi9TeXN0ZW0ubWFwJApkaWZmIC1yIGNhODBl
Y2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMgQ29uZmlnLm1rCi0tLSBhL0NvbmZpZy5tawlNb24gRmVi
IDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvQ29uZmlnLm1rCVR1ZSBGZWIgMjEgMDE6NDA6
MDQgMjAxMiArMDEwMApAQCAtNzAsOSArNzAsNiBAQCBFWFRSQV9JTkNMVURFUyArPSAkKEVYVFJB
X1BSRUZJWCkvaW5jbHVkCiBFWFRSQV9MSUIgKz0gJChFWFRSQV9QUkVGSVgpLyQoTElCTEVBRkRJ
UikKIGVuZGlmCiAKLUJJU09OCT89IGJpc29uCi1GTEVYCT89IGZsZXgKLQogUFlUSE9OICAgICAg
Pz0gcHl0aG9uCiBQWVRIT05fUFJFRklYX0FSRyA/PSAtLXByZWZpeD0iJChQUkVGSVgpIgogIyBU
aGUgYWJvdmUgcmVxdWlyZXMgdGhhdCBQUkVGSVggY29udGFpbnMgKm5vIHNwYWNlcyouIFRoaXMg
dmFyaWFibGUgaXMgaGVyZQpAQCAtMTc1LDMyICsxNzIsOSBAQCBDRkxBR1MgKz0gJChmb3JlYWNo
IGksICQoUFJFUEVORF9JTkNMVURFCiBBUFBFTkRfTERGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChB
UFBFTkRfTElCKSwgLUwkKGkpKQogQVBQRU5EX0NGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChBUFBF
TkRfSU5DTFVERVMpLCAtSSQoaSkpCiAKLUNIRUNLX0xJQiA9ICQoRVhUUkFfTElCKSAkKFBSRVBF
TkRfTElCKSAkKEFQUEVORF9MSUIpCi1DSEVDS19JTkNMVURFUyA9ICQoRVhUUkFfSU5DTFVERVMp
ICQoUFJFUEVORF9JTkNMVURFUykgJChBUFBFTkRfSU5DTFVERVMpCi0KIEVNQkVEREVEX0VYVFJB
X0NGTEFHUyA6PSAtbm9waWUgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZuby1zdGFjay1wcm90ZWN0
b3ItYWxsCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgKz0gLWZuby1leGNlcHRpb25zCiAKLUNPTkZJ
R19MSUJJQ09OViAgIDo9ICQoc2hlbGwgZXhwb3J0IE9TPSJgdW5hbWUgLXNgIjsgXAotICAgICAg
ICAgICAgICAgICAgICAgICBleHBvcnQgQ0hFQ0tfTElCPSIkKENIRUNLX0xJQikiOyBcCi0gICAg
ICAgICAgICAgICAgICAgICAgIC4gJChYRU5fUk9PVCkvdG9vbHMvY2hlY2svZnVuY3Muc2g7IFwK
LSAgICAgICAgICAgICAgICAgICAgICAgaGFzX2xpYiBsaWJpY29udi5zbyAmJiBlY2hvICd5JyB8
fCBlY2hvICduJykKLQotQ09ORklHX1lBSkxfVkVSU0lPTiA6PSAkKHNoZWxsIGV4cG9ydCBPUz0i
YHVuYW1lIC1zYCI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgZXhwb3J0IENIRUNLX0lOQ0xV
REVTPSIkKENIRUNLX0lOQ0xVREVTKSI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgLiAkKFhF
Tl9ST09UKS90b29scy9jaGVjay9mdW5jcy5zaDsgXAotICAgICAgICAgICAgICAgICAgICAgICBo
YXNfaGVhZGVyIHlhamwveWFqbF92ZXJzaW9uLmggJiYgZWNobyAneScgfHwgZWNobyAnbicpCi0K
LSMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4KLVhTTV9F
TkFCTEUgPz0gbgotRkxBU0tfRU5BQkxFID89ICQoWFNNX0VOQUJMRSkKLQotIyBEb3dubG9hZCBH
SVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KLSMgR0lUJ3Mg
cHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3JrcyBhdCBhbGwg
KGZpcmV3YWxscwotIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZhdWx0LCBidXQg
aWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKLSMgZmFpbCBvciBoYW5nLCBwbGVhc2Ug
c3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCi1HSVRfSFRUUCA/PSBuCi0K
IFhFTl9FWFRGSUxFU19VUkw9aHR0cDovL3hlbmJpdHMueGVuc291cmNlLmNvbS94ZW4tZXh0Zmls
ZXMKICMgQWxsIHRoZSBmaWxlcyBhdCB0aGF0IGxvY2F0aW9uIHdlcmUgZG93bmxvYWRlZCBmcm9t
IGVsc2V3aGVyZSBvbgogIyB0aGUgaW50ZXJuZXQuICBUaGUgb3JpZ2luYWwgZG93bmxvYWQgVVJM
IGlzIHByZXNlcnZlZCBhcyBhIGNvbW1lbnQKQEAgLTIzOSwxNyArMjEzLDQgQEAgUUVNVV9UQUcg
Pz0gMTI4ZGUyNTQ5YzVmMjRlNGE0MzdiODZiZDJlNAogIyBTaG9ydCBhbnN3ZXIgLS0gZG8gbm90
IGVuYWJsZSB0aGlzIHVubGVzcyB5b3Uga25vdyB3aGF0IHlvdSBhcmUKICMgZG9pbmcgYW5kIGFy
ZSBwcmVwYXJlZCBmb3Igc29tZSBwYWluLgogCi0jIE9wdGlvbmFsIGNvbXBvbmVudHMKLVhFTlNU
QVRfWEVOVE9QICAgICA/PSB5Ci1WVFBNX1RPT0xTICAgICAgICAgPz0gbgotTElCWEVOQVBJX0JJ
TkRJTkdTID89IG4KLVBZVEhPTl9UT09MUyAgICAgICA/PSB5Ci1PQ0FNTF9UT09MUyAgICAgICAg
Pz0geQotQ09ORklHX01JTklURVJNICAgID89IG4KLUNPTkZJR19MT01PVU5UICAgICA/PSBuCi1D
T05GSUdfU1lTVEVNX0xJQkFJTyA/PSB5CiBDT05GSUdfVEVTVFMgICAgICAgPz0geQotCi1pZmVx
ICgkKE9DQU1MX1RPT0xTKSx5KQotT0NBTUxfVE9PTFMgOj0gJChzaGVsbCBvY2FtbG9wdCAtdiA+
IC9kZXYvbnVsbCAyPiYxICYmIGVjaG8gInkiIHx8IGVjaG8gIm4iKQotZW5kaWYKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIE1ha2VmaWxlCi0tLSBhL01ha2VmaWxlCU1vbiBG
ZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi9NYWtlZmlsZQlUdWUgRmViIDIxIDAxOjQw
OjA0IDIwMTIgKzAxMDAKQEAgLTQwLDExICs0MCw5IEBAIGRpc3Q6IERFU1RESVI9JChESVNURElS
KS9pbnN0YWxsCiBkaXN0OiBkaXN0LXhlbiBkaXN0LWtlcm5lbHMgZGlzdC10b29scyBkaXN0LXN0
dWJkb20gZGlzdC1kb2NzIGRpc3QtbWlzYwogCiBkaXN0LW1pc2M6Ci0JJChJTlNUQUxMX0RJUikg
JChESVNURElSKS9jaGVjawogCSQoSU5TVEFMTF9EQVRBKSAuL0NPUFlJTkcgJChESVNURElSKQog
CSQoSU5TVEFMTF9EQVRBKSAuL1JFQURNRSAkKERJU1RESVIpCiAJJChJTlNUQUxMX1BST0cpIC4v
aW5zdGFsbC5zaCAkKERJU1RESVIpCi0JJChJTlNUQUxMX1BST0cpIHRvb2xzL2NoZWNrL2NoayB0
b29scy9jaGVjay9jaGVja18qIHRvb2xzL2NoZWNrL2Z1bmNzLnNoICQoRElTVERJUikvY2hlY2sK
IGRpc3QtJTogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRpc3QtJTogaW5zdGFsbC0lCiAJ
QDogIyBkbyBub3RoaW5nCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyBSRUFE
TUUKLS0tIGEvUkVBRE1FCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi9SRUFE
TUUJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC04OSw5ICs4OSwxMyBAQCAyLiBj
ZCB0byB4ZW4tdW5zdGFibGUgKG9yIHdoYXRldmVyIHlvdSBzCiAzLiBGb3IgdGhlIHZlcnkgZmly
c3QgYnVpbGQsIG9yIGlmIHlvdSB3YW50IHRvIGRlc3Ryb3kgYnVpbGQgdHJlZXMsCiAgICBwZXJm
b3JtIHRoZSBmb2xsb3dpbmcgc3RlcHM6CiAKKyAgICAjIC4vY29uZmlndXJlCiAgICAgIyBtYWtl
IHdvcmxkCiAgICAgIyBtYWtlIGluc3RhbGwKIAorICAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVu
IC4vY29uZmlndXJlIC0taGVscCB0byBzZWUgdGhlIGxpc3Qgb2YKKyAgIG9wdGlvbnMgYXZhaWxh
YmxlIG9wdGlvbnMgd2hlbiBidWlsZGluZyBhbmQgaW5zdGFsbGluZyBYZW4uCisKICAgIFRoaXMg
d2lsbCBjcmVhdGUgYW5kIGluc3RhbGwgb250byB0aGUgbG9jYWwgbWFjaGluZS4gSXQgd2lsbCBi
dWlsZAogICAgdGhlIHhlbiBiaW5hcnkgKHhlbi5neiksIHRoZSB0b29scyBhbmQgdGhlIGRvY3Vt
ZW50YXRpb24uCiAKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIGNvbmZpZy9U
b29scy5tay5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi9jb25maWcvVG9vbHMubWsuaW4JVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBA
IC0wLDAgKzEsNTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklYICAgICAg
ICAgICAgICA6PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BBVEhACisK
KyMgQSBkZWJ1ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0gQGRlYnVn
QAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAorRkxFWCAg
ICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZVEhPTkAK
K1BZVEhPTl9QQVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAgICAgICAg
IDo9IEBQRVJMQAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAgICAgICAg
ICAgICAgIDo9IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwyX0NPTkZJ
RyAgICAgICAgIDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAorWEdFVFRU
RVhUICAgICAgICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBsaWJzL2lu
Y2x1ZGVzCitQUkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAorUFJFUEVO
RF9MSUIgICAgICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAgIDo9IEBB
UFBFTkRfSU5DTFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElCQAorCisj
IEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitYU01fRU5B
QkxFICAgICAgICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21ACisKKyMg
RG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJvdG9jb2w/
CisjIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4gaXQgd29y
a3MgYXQgYWxsIChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVm
YXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwgb3IgaGFu
ZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50LgorR0lUX0hU
VFAgICAgICAgICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRzCitYRU5T
VEFUX1hFTlRPUCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAgOj0gQHZ0
cG1ACitMSUJYRU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAgICAgICA6
PSBAcHl0aG9udG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xzQAorQ09O
RklHX01JTklURVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAgIDo9IEBs
b21vdW50QAorCisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0gQHN5c3Rl
bV9haW9ACitDT05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19HQ1JZUFQg
ICAgICAgOj0gQGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4dDJmc0AK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIGNvbmZpZ3VyZQotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJVHVlIEZl
YiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3NoIC1lCitj
ZCB0b29scyAmJiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3
MTBmNmMgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODoz
NDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDE6NDA6MDQg
MjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlvCiBlbmRp
ZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9IGluY2x1
ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2ICs3OCw4
IEBAIGNsZWFuOiBzdWJkaXJzLWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNsZWFuCiAJ
cm0gLXJmIHFlbXUteGVuLXRyYWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25hbC1kaXIt
cmVtb3RlCiAJcm0gLXJmIHFlbXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJcm0gLXJm
IC4uL2NvbmZpZy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAor
CQljb25maWcuY2FjaGUgYXV0b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJTEVfQVJD
SCksJChYRU5fVEFSR0VUX0FSQ0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0tY3B1PSQo
WEVOX1RBUkdFVF9BUkNIKSBcCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0
b29scy9SdWxlcy5tawotLS0gYS90b29scy9SdWxlcy5tawlNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIGIvdG9vbHMvUnVsZXMubWsJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICsw
MTAwCkBAIC00LDYgKzQsNyBAQAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5t
aworaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9JTlNUQUxM
IDo9ICQoSU5TVEFMTCkKIElOU1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1pbnN0YWxs
CkBAIC04MCw4ICs4MSw2IEBAIGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2MtdmVyLWNo
ZWMKICAgICAgICAgICAgICAgICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3QgZ2NjLTMu
NCIpCiAkKGV2YWwgJChjaGVjay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwgd2hpY2gg
JChQWVRIT04pKQotUFlUSE9OX1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxMX1BZVEhP
Tl9QUk9HID0gXAogCSQoWEVOX1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAgIiQoUFlU
SE9OX1BBVEgpIiAkKElOU1RBTExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1YmRpci1h
bGwtJSBzdWJkaXItY2xlYW4tJSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVhbi0lOiAu
cGhvbnkKIAkkKE1BS0UpIC1DICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9Ub29scy5t
azoKKwlAZWNobyAiWW91IGhhdmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWlsZGluZyBv
ciBpbnN0YWxsaW5nIHRoZSB0b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGI2MDcxYzcxMGY2YyB0b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90b29scy9i
bGt0YXAvZHJpdmVycy9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEy
ICswMTAwCkBAIC0xMyw3ICsxMyw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhlbnN0b3Jl
KQogQ0ZMQUdTICAgKz0gLUkgJChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05VX1NPVVJD
RQogCi1pZmVxICgkKHNoZWxsIC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lmZXEgKCRD
T05GSUdfR0NSWVBULHkpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIgOj0gLWxn
Y3J5cHQKIGVsc2UKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2Js
a3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9jaGVj
a19nY3J5cHQJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAot
Ci1jYXQgPiAuZ2NyeXB0LmMgPDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQgbWFpbih2
b2lkKSB7IHJldHVybiAwOyB9Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0LmMgLWxn
Y3J5cHQgMj4vZGV2L251bGwgOyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNobyAibm8i
Ci1maQotCi1ybSAtZiAuZ2NyeXB0KgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvY2hlY2svTWFrZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIpLy4uLy4u
Ci1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRoZSBuZWNl
c3NhcnkgZW52aXJvbm1lbnQgdmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQWVRIT04K
LWV4cG9ydCBMSUJYRU5BUElfQklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwotZXhwb3J0
IENIRUNLX0xJQgotZXhwb3J0IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTogYWxsIGlu
c3RhbGwKLWFsbCBpbnN0YWxsOiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBp
cyBPSyBmb3IgYnVpbGRpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1idWlsZDoK
LQkuL2NoayBidWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5zdGFsbGlu
ZyBvbi4KLS5QSE9OWTogY2hlY2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2NoayBpbnN0
YWxsCi0KLS5QSE9OWTogY2xlYW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9vbHMvY2hl
Y2svUkVBRE1FCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVja3MgZm9y
IHRoZSBzdWl0YWJpbGl0eSBvZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLgot
VG8gY2hlY2sgZm9yIGJ1aWxkIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGJ1aWxk
Ci0KLVRvIGNoZWNrIGZvciBpbnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hr
IGluc3RhbGwKLQotVGhlIGNoayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMgZGlyZWN0
b3J5IGFuZCBwcmludAotdGhlIG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3RoaW5nIGlm
IGNoZWNrcyBzdWNjZWVkLgotVGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1Y2Nlc3Mg
YW5kIDEgb24gZmFpbHVyZS4KLQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxlIGZpbGVz
IGluIHRoaXMgZGlyZWN0b3J5IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18nLiBGaWxl
cyBjb250YWluaW5nIENIRUNLLUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hlY2ssIGFu
ZCBmaWxlcyBjb250YWluaW5nIENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBpbnN0YWxs
IGNoZWNrLgotCi1EZXRhaWxlZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBpcyBpbiAu
Y2hrYnVpbGQgZm9yIGJ1aWxkCi1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwgTm8gbmV3
bGluZSBhdCBlbmQgb2YgZmlsZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMg
dG9vbHMvY2hlY2svY2hlY2tfYnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNU
QUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJT
RCkKLQloYXNfb3JfZmFpbCBicmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwgYnJjdGwg
OzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEvdG9vbHMv
Y2hlY2svY2hlY2tfY3J5cHRvX2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBA
QAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNo
Ci0KLWNhc2UgJE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7OwotZXNh
YwotCi1oYXNfbGliIGxpYmNyeXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0by5zbyIK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX2N1
cmwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfY3VybAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAu
L2Z1bmNzLnNoCi0KLWlmIFsgIiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0aGVuCi0J
ZWNobyAtbiAidW51c2VkLCAiCi0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJsLWNvbmZp
ZwotY3VybF9saWJzPWBjdXJsLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29uZmlnIC0t
bGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxp
YnJhcmllcyBmb3IgY3VybCBhcmUgbWlzc2luZyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYw
NzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hlY2svY2hl
Y2tfaXByb3V0ZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBBVEgKLQot
Y2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgaWZjb25m
aWcgOzsKLUxpbnV4KQotCWhhc19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1Mi
IDs7Ci1lc2FjCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVj
ay9jaGVja19saWJhaW9fZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVs
CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0st
QlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9
IFgieSIgXSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGliYWlvLmgg
OyB0aGVuCi0gICAgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFsbCBsaWJh
aW8gZGV2ZWwgcGFja2FnZSBvciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZpCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9jaGVja19saWJhaW9f
bGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIJTW9uIEZlYiAyMCAxODozNDox
NCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwK
LQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIg
XSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWlsICJjYW4n
dCBmaW5kIGxpYmFpbyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xz
L2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNz
bF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUg
SmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMg
Q0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9tZDUuaCB8
fCBmYWlsICJtaXNzaW5nIG9wZW5zc2wgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
YjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9jaGVjay9j
aGVja19weXRob24JTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9z
aAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0
IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhPTn0gLWMg
JwotaW1wb3J0IHN5cwotc3lzLmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Igc3lzLnZl
cnNpb25faW5mb1sxXSA8IDMpCi0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24gPj0gMi4z
IgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMgdG9vbHMvY2hlY2svY2hlY2tf
cHl0aG9uX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlNb24gRmVi
IDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAw
IDE5NzAgKzAwMDAKQEAgLTEsMTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0
aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQg
b3MucGF0aCwgc3lzCi1mb3IgcCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0cyhwICsg
Ii9jb25maWcvTWFrZWZpbGUiKToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0nIHx8IGZh
aWwgImNhbid0IGZpbmQgcHl0aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAt
ciBiNjA3MWM3MTBmNmMgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90b29scy9j
aGVjay9jaGVja19weXRob25feG1sCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAt
eiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlU
SE9OfQotCi0ke1BZVEhPTn0gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rldi9udWxs
IHx8IFwKLWZhaWwgImNhbid0IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX3VkZXYJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgot
T3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7Ci1MaW51
eCkKLQloYXMgL3NiaW4vdWRldmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZhZG0gaW5m
byAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhhc19vcl9m
YWlsIHVkZXZpbmZvICYmIFwKLQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3twcmludCAk
TkZ9J2AKLQlbICIkdWRldnZlciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQloYXMgaG90
cGx1ZyB8fCBcCi0JCWZhaWwgInVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5
IG9yIGxhdGVyIgotCTs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2
ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsNyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNo
Ci0KLWhhc19oZWFkZXIgdXVpZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmggfHwgZmFp
bCAibWlzc2luZyB1dWlkIGhlYWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1yIGNhODBl
Y2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVsCi0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX3gxMV9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19o
ZWFkZXIgWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9pbmNsdWRl
L1gxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVkZS9YMTEv
a2V5c3ltZGVmLmggfHwgXAotd2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAx
MiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQot
aGFzX29yX2ZhaWwgeGdldHRleHQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZj
IHRvb2xzL2NoZWNrL2NoZWNrX3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1sMglNb24g
RmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxE
IENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQSV9CSU5E
SU5HUyIgPSAieSIgXQotdGhlbgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4aXQgMAot
ZmkKLQotaGFzX29yX2ZhaWwgeG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25maWcgLS1s
aWJzYCB8fCBmYWlsICJ4bWwyLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICR4bWwy
X2xpYnMgfHwgZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1pc3Npbmci
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9jaGVjay9jaGVja195
YWpsX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDggKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9m
dW5jcy5zaAotCi1oYXNfaGVhZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNhbid0IGZp
bmQgeWFqbC95YWpsX3BhcnNlLmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8fCBmYWls
ICJjYW4ndCBmaW5kIHlhamwveWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8fCBmYWls
ICJjYW4ndCBmaW5kIGxpYnlhamwuc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcx
MGY2YyB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3psaWJfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBm
YWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYw
NzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3psaWJfbGliCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAk
T1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFz
X2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciBjYTgwZWNhOWNm
YTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3Vz
YWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFs
bHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90
LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5l
cmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2Jp
bgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIg
XTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBj
aGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hl
Y2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQg
MAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVz
YWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBj
aGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29u
dGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVz
YWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQot
ICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0g
ICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRo
ZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQot
ZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGlj
aCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAt
eiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVy
biAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0
byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBp
biAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0J
CQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUK
LQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVs
bCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5
c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBb
IC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAw
Ci0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAi
JENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQot
CQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAj
IGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhp
cyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0
Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3Jr
LgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNv
LmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JP
U1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91
Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9
ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JP
U1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIk
e09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZx
ICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkg
ewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1w
ZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1g
bWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+
JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5
IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiBy
ZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVh
c2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlm
aQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1y
b290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJu
aW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAk
Kn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZB
SUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFj
NzEwZjZjIHRvb2xzL2NvbmZpZy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5oLmluCVR1ZSBGZWIgMjEgMDE6NDA6MDQg
MjAxMiArMDEwMApAQCAtMCwwICsxLDE2IEBACisvKgorICogQ29weXJpZ2h0IChDKSAyMDEyCisg
KgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl
IGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3Nl
ciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAorICogYnkgdGhlIEZyZWUgU29m
dHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lhbAorICog
ZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KKyAqCisgKiBU
aGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVz
ZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs
aWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJU
SUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqLworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
WUFKTF9ZQUpMX1ZFUlNJT05fSApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMg
dG9vbHMvY29uZmlndXJlLmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxOTIgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0
aCBhdXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsy
LjY3XSkKK0FDX0lOSVQoW1hlbiBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVyc2lvbi5z
aCAuLi94ZW4vTWFrZWZpbGVdKSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb21d
KQorQUNfQ09ORklHX1NSQ0RJUihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklMRVMoWy4u
L2NvbmZpZy9Ub29scy5ta10pCitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQorQUNfUFJF
RklYX0RFRkFVTFQoWy91c3JdKQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENoZWNrIGlm
IENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQg
YSB3YXJuaW5nCisKK0FTX0lGKFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElCUyRDUFBG
TEFHUyRDUFAiXSwgWworICAgIEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFHUywgTERG
TEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBS
RVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVO
RF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVNX0VYVEVO
U0lPTlMKK0FDX0NBTk9OSUNBTF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200X2luY2x1
ZGUoW200L2VuYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVfZmVhdHVy
ZS5tNF0pCittNF9pbmNsdWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVkZShbbTQv
cHl0aG9uX3htbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0pCittNF9p
bmNsdWRlKFttNC9weXRob25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5tNF0pCitt
NF9pbmNsdWRlKFttNC9vY2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xpYi5tNF0p
CittNF9pbmNsdWRlKFttNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVkZShbbTQv
dXVpZC5tNF0pCittNF9pbmNsdWRlKFttNC9wa2cubTRdKQorCisjIEVuYWJsZS9kaXNhYmxlIG9w
dGlvbnMKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeHNtXSwKKyAgICBbRW5hYmxlIFhTTSBz
ZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0pCitBWF9BUkdfRU5BQkxFX0FORF9F
WFBPUlQoW2dpdGh0dHBdLCBbRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUF0pCitB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFttb25pdG9yc10sCisgICAgW0Rpc2FibGUgeGVuc3Rh
dCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JU
KFt2dHBtXSwgW0VuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlXSkKK0FYX0FS
R19FTkFCTEVfQU5EX0VYUE9SVChbeGFwaV0sIFtFbmFibGUgWGVuIEFQSSBCaW5kaW5nc10pCitB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtweXRob250b29sc10sIFtEaXNhYmxlIFB5dGhvbiB0
b29sc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtvY2FtbHRvb2xzXSwgW0Rpc2FibGUg
T2NhbWwgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFttaW5pdGVybV0sIFtFbmFi
bGUgbWluaXRlcm1dKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtsb21vdW50XSwgW0VuYWJs
ZSBsb21vdW50XSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW2RlYnVnXSwgW0Rpc2FibGUg
ZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29sc10pCisKK0FDX0FSR19WQVIoW1BSRVBFTkRfSU5D
TFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRvIENGTEFH
UyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbUFJFUEVORF9MSUJdLAorICAgIFtMaXN0IG9m
IGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKK0FD
X0FSR19WQVIoW0FQUEVORF9JTkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJz
IHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9M
SUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAo
d2l0aG91dCAtTCldKQorCitBWF9TRVRfRkxBR1MKKworQUNfQVJHX1ZBUihbUFlUSE9OXSwgW1Bh
dGggdG8gdGhlIFB5dGhvbiBwYXJzZXJdKQorQUNfQVJHX1ZBUihbUEVSTF0sIFtQYXRoIHRvIFBl
cmwgcGFyc2VyXSkKK0FDX0FSR19WQVIoW0JSQ1RMXSwgW1BhdGggdG8gYnJjdGwgdG9vbF0pCitB
Q19BUkdfVkFSKFtJUF0sIFtQYXRoIHRvIGlwIHRvb2xdKQorQUNfQVJHX1ZBUihbQklTT05dLCBb
UGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0ZMRVhdLCBbUGF0
aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0NVUkxd
LCBbUGF0aCB0byBjdXJsLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW1hNTF0sIFtQYXRoIHRv
IHhtbDItY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZBUihbQkFTSF0sIFtQYXRoIHRvIGJhc2ggc2hl
bGxdKQorQUNfQVJHX1ZBUihbWEdFVFRFWFRdLCBbUGF0aCB0byB4Z2V0dHRleHQgdG9vbF0pCisK
KyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK0FDX1BST0dfU0VECitBQ19QUk9HX0NDCitBQ19QUk9H
X0xOX1MKK0FDX1BST0dfTUFLRV9TRVQKK0FDX1BST0dfSU5TVEFMTAorQVhfUEFUSF9QUk9HX09S
X0ZBSUwoW1BFUkxdLCBbcGVybF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQlJDVExdLCBbYnJj
dGxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQXSwgW2lwXSkKK0FYX1BBVEhfUFJPR19PUl9G
QUlMKFtCSVNPTl0sIFtiaXNvbl0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbRkxFWF0sIFtmbGV4
XSkKK0FTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5Il0sIFsKKyAgICBBWF9QQVRIX1BST0dfT1Jf
RkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hN
TF0sIFt4bWwyLWNvbmZpZ10pCitdKQorQVNfSUYoW3Rlc3QgIngkb2NhbWx0b29scyIgPSAieHki
XSwgWworICAgIEFDX1BST0dfT0NBTUwKKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMiID0gInhu
byJdLCBbCisgICAgICAgIEFTX0lGKFt0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4eWVz
Il0sIFsKKyAgICAgICAgICAgIEFDX01TR19FUlJPUihbT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0
IHVuYWJsZSB0byBmaW5kIE9jYW1sXSldKQorICAgICAgICBvY2FtbHRvb2xzPSJuIgorICAgIF0p
CitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihbdGVzdCAi
eCRweXRob250b29scyIgPSAieHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9OIiB8IGdy
ZXAgLXEgIl4vIl0sIFsKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhP
Tj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJdLCBbUFlU
SE9OPSJweXRob24iXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVkLCBidXQg
aXMgbm90IGFuIGFic29sdXRlIHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BZ
VEhPTlBBVEhdLCBbJFBZVEhPTl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04oWzJdLCBb
M10pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9OX0RFVkVM
KCkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRdKQorQVhf
Q0hFQ0tfVURFVihbNTldKQorQVhfQ0hFQ0tfVVVJRAorUEtHX0NIRUNLX01PRFVMRVMoZ2xpYiwg
Z2xpYi0yLjApCisKKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitBWF9ERUZBVUxUX0xJQgorCisjIENo
ZWNrcyBmb3IgbGlicmFyaWVzLgorQUNfQ0hFQ0tfTElCKFthaW9dLCBbaW9fc2V0dXBdLCBbc3lz
dGVtX2Fpbz0ieSJdLCBbc3lzdGVtX2Fpbz0ibiJdKQorQUNfU1VCU1Qoc3lzdGVtX2FpbykKK0FD
X0NIRUNLX0xJQihbY3J5cHRvXSwgW01ENV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3Qg
ZmluZCBsaWJjcnlwdG9dKV0pCitBQ19DSEVDS19MSUIoW2V4dDJmc10sIFtleHQyZnNfb3BlbjJd
LCBbbGliZXh0MmZzPSJ5Il0sIFtsaWJleHQyZnM9Im4iXSkKK0FDX1NVQlNUKGxpYmV4dDJmcykK
K0FDX0NIRUNLX0xJQihbZ2NyeXB0XSwgW2djcnlfbWRfaGFzaF9idWZmZXJdLCBbbGliZ2NyeXB0
PSJ5Il0sIFtsaWJnY3J5cHQ9Im4iXSkKK0FDX1NVQlNUKGxpYmdjcnlwdCkKK0FDX0NIRUNLX0xJ
QihbcHRocmVhZF0sIFtwdGhyZWFkX2NyZWF0ZV0sIFtdICwKKyAgICBbQUNfTVNHX0VSUk9SKFtD
b3VsZCBub3QgZmluZCBsaWJwdGhyZWFkXSldKQorQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19n
ZXR0aW1lXSkKK0FDX0NIRUNLX0xJQihbdXVpZF0sIFt1dWlkX2NsZWFyXSwgW10sCisgICAgW0FD
X01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGlidXVpZF0pXSkKK0FDX0NIRUNLX0xJQihbeWFq
bF0sIFt5YWpsX2FsbG9jXSwgW10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQg
eWFqbF0pXSkKK0FDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNfTVNHX0VS
Uk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQorQUNfQ0hFQ0tfTElCKFtpY29udl0sIFtsaWJp
Y29udl9vcGVuXSwgW2xpYmljb252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQorQUNfU1VCU1QobGli
aWNvbnYpCisKKyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCitBQ19GVU5DX0FMTE9DQQorQUNf
Q0hFQ0tfSEVBREVSUyhbIFwKKyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGlu
dHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAgICAgICBu
ZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBc
CisgICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21v
dW50Lmggc3lzL3BhcmFtLmggXAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3Rh
dHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAgICAgICB1
bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKyAgICAgICAgICAgICAgICBdKQorCisjIENo
ZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3Rp
Y3MuCitBQ19IRUFERVJfU1REQk9PTAorQUNfVFlQRV9VSURfVAorQUNfQ19JTkxJTkUKK0FDX1RZ
UEVfSU5UMTZfVAorQUNfVFlQRV9JTlQzMl9UCitBQ19UWVBFX0lOVDY0X1QKK0FDX1RZUEVfSU5U
OF9UCitBQ19UWVBFX01PREVfVAorQUNfVFlQRV9PRkZfVAorQUNfVFlQRV9QSURfVAorQUNfQ19S
RVNUUklDVAorQUNfVFlQRV9TSVpFX1QKK0FDX1RZUEVfU1NJWkVfVAorQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCitBQ19TVFJVQ1RfU1RfQkxPQ0tTCitBQ19DSEVD
S19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9yZGV2XSkKK0FDX1RZUEVfVUlOVDE2X1QKK0FDX1RZ
UEVfVUlOVDMyX1QKK0FDX1RZUEVfVUlOVDY0X1QKK0FDX1RZUEVfVUlOVDhfVAorQUNfQ0hFQ0tf
VFlQRVMoW3B0cmRpZmZfdF0pCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9ucy4KK0FD
X0ZVTkNfRVJST1JfQVRfTElORQorQUNfRlVOQ19GT1JLCitBQ19GVU5DX0ZTRUVLTworQUNfRlVO
Q19MU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSworQUNfSEVBREVSX01BSk9SCitBQ19GVU5D
X01BTExPQworQUNfRlVOQ19NS1RJTUUKK0FDX0ZVTkNfTU1BUAorQUNfRlVOQ19SRUFMTE9DCitB
Q19GVU5DX1NUUk5MRU4KK0FDX0ZVTkNfU1RSVE9ECitBQ19DSEVDS19GVU5DUyhbIFwKKyAgICAg
ICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRhc3lu
YyBmdHJ1bmNhdGUgXAorICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1lIGdldGhv
c3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAgaW5ldF9u
dG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGlyIFwKKyAg
ICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1k
aXIgc2VsZWN0IHNldGVudiBcCisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2VjbXAgc3Ry
Y2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAgICAgIHN0
cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxsIHR6c2V0
IFwKKyAgICAgICAgICAgICAgICB1bmFtZSBcCisgICAgICAgICAgICAgICAgXSkKKworQUNfT1VU
UFVUKCkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2RlYnVnZ2Vy
L2dkYnN4L3hnL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxl
CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9kZWJ1Z2dlci9nZGJz
eC94Zy9NYWtlZmlsZQlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTIxLDcgKzIx
LDYgQEAgeGdfYWxsLmE6ICQoWEdfT0JKUykgTWFrZWZpbGUgJChYR19IRFJTKQogIwkkKENDKSAt
bTMyIC1jIC1vICRAICReCiAKIHhlbi1oZWFkZXJzOgotCSQoTUFLRSkgLUMgLi4vLi4vLi4vY2hl
Y2sgCiAJJChNQUtFKSAtQyAuLi8uLi8uLi9pbmNsdWRlCiAKICMgeGdfbWFpbi5vOiB4Z19tYWlu
LmMgTWFrZWZpbGUgJChYR19IRFJTKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvaW5zdGFsbC5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi90b29scy9pbnN0YWxsLnNoCVR1ZSBGZWIgMjEgMDE6NDA6MDQgMjAxMiAr
MDEwMApAQCAtMCwwICsxLDEgQEAKKy4uL2luc3RhbGwuc2gKXCBObyBuZXdsaW5lIGF0IGVuZCBv
ZiBmaWxlCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0b29scy9saWJmc2lt
YWdlL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJVHVlIEZl
YiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0zLDcgKzMsMTEgQEAgaW5jbHVkZSAkKFhFTl9S
T09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNlcmZzIGlz
bzk2NjAgZmF0IHpmcwogU1VCRElSUy0kKENPTkZJR19YODYpICs9IHhmcwotU1VCRElSUy15ICs9
ICQoc2hlbGwgZW52IENDPSIkKENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgkKENPTkZJ
R19FWFQyRlMpLCB5KQorICAgIFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisgICAgU1VC
RElSUy15ICs9IGV4dDJmcworZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFsbAogYWxs
IGNsZWFuIGluc3RhbGw6ICU6IHN1YmRpcnMtJQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3
MWM3MTBmNmMgdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9vbHMvbGli
ZnNpbWFnZS9jaGVjay1saWJleHQyZnMJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIxICswLDAg
QEAKLSMhL2Jpbi9zaAotCi1jYXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8ZXh0MmZz
L2V4dDJmcy5oPgotCi1pbnQgbWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9GCi0KLSR7
Q0MtZ2NjfSAtbyBleHQyLXRlc3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVsbCAyPiYx
Ci1pZiBbICQ/ID0gMCBdOyB0aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNobyBleHQy
ZnMKLWZpCi0KLXJtIC1mIGV4dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQotLS0gYS90
b29scy9saWJ4ZW4vTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBi
L3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAg
LTIyLDEyICsyMiwxMiBAQCBNQUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtSWlu
Y2x1ZGUgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwyLWNvbmZp
ZyAtLWNmbGFncykgXAotICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxhZ3MpIFwK
KyAgICAgICAgICAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAgICAgICAg
JChzaGVsbCAkKENVUkxfQ09ORklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElDCiAKLUxE
RkxBR1MgKz0gJChzaGVsbCB4bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAgJChzaGVs
bCBjdXJsLWNvbmZpZyAtLWxpYnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyX0NPTkZJRykg
LS1saWJzKSBcCisgICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1saWJzKQogCiBM
SUJYRU5BUElfSERSUyA9ICQod2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5jbHVkZS94
ZW4vYXBpL3hlbl9hbGwuaAogTElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywgJS5vLCAk
KHdpbGRjYXJkIHNyYy8qLmMpKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBmNmMg
dG9vbHMvbGlieGwvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCVR1ZSBGZWIg
MjEgMDE6NDA6MDQgMjAxMiArMDEwMApAQCAtMTksMTAgKzE5LDYgQEAgaWZlcSAoJChDT05GSUdf
TGludXgpLHkpCiBMSUJVVUlEX0xJQlMgKz0gLWx1dWlkCiBlbmRpZgogCi1pZmVxICgkKENPTkZJ
R19ZQUpMX1ZFUlNJT04pLHkpCi1DRkxBR1MgKz0gLURIQVZFX1lBSkxfVkVSU0lPTgotZW5kaWYK
LQogTElCWExfTElCUyA9CiBMSUJYTF9MSUJTID0gJChMRExJQlNfbGlieGVuY3RybCkgJChMRExJ
QlNfbGlieGVuZ3Vlc3QpICQoTERMSUJTX2xpYnhlbnN0b3JlKSAkKExETElCU19saWJibGt0YXBj
dGwpICQoVVRJTF9MSUJTKSAkKExJQlVVSURfTElCUykKIApAQCAtNTYsNyArNTIsNyBAQCBMSUJY
TF9PQkpTID0gZmxleGFycmF5Lm8gbGlieGwubyBsaWJ4bF9jCiAJCQlsaWJ4bF9xbXAubyBsaWJ4
bF9ldmVudC5vICQoTElCWExfT0JKUy15KQogTElCWExfT0JKUyArPSBfbGlieGxfdHlwZXMubyBs
aWJ4bF9mbGFzay5vIF9saWJ4bF90eXBlc19pbnRlcm5hbC5vCiAKLSQoTElCWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxB
R1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkKKyQoTElCWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkgJChDRkxB
R1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkgLWluY2x1ZGUgJChYRU5fUk9P
VCkvdG9vbHMvY29uZmlnLmgKIAogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhsdV9jZmdf
bC5oIF9saWJ4bF9saXN0LmgKIEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVfY2ZnX2wu
YwpAQCAtNjksNiArNjUsNyBAQCBDTElFTlRTID0geGwgdGVzdGlkbAogWExfT0JKUyA9IHhsLm8g
eGxfY21kaW1wbC5vIHhsX2NtZHRhYmxlLm8geGxfc3hwLm8KICQoWExfT0JKUyk6IENGTEFHUyAr
PSAkKENGTEFHU19saWJ4ZW5jdHJsKSAjIEZvciB4ZW50b29sbG9nLmgKICQoWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5saWdodCkKKyQoWExfT0JKUyk6IENGTEFHUyArPSAtaW5j
bHVkZSAkKFhFTl9ST09UKS90b29scy9jb25maWcuaCAjIGxpYnhsX2pzb24uaCBuZWVkcyBpdC4K
IAogdGVzdGlkbC5vOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxBR1NfbGli
eGVubGlnaHQpCiB0ZXN0aWRsLmM6IGxpYnhsX3R5cGVzLmlkbCBnZW50ZXN0LnB5IGxpYnhsLmgg
JChBVVRPSU5DUykKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL2xp
YnhsL2xpYnhsX2pzb24uaAotLS0gYS90b29scy9saWJ4bC9saWJ4bF9qc29uLmgJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24uaAlUdWUg
RmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTE4LDcgKzE4LDcgQEAKICNpbmNsdWRlIDx5
YWpsL3lhamxfZ2VuLmg+CiAjaW5jbHVkZSA8eWFqbC95YWpsX3BhcnNlLmg+CiAKLSNpZmRlZiBI
QVZFX1lBSkxfVkVSU0lPTgorI2lmZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAogIyAgaW5j
bHVkZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4KICNlbmRpZgogCmRpZmYgLXIgY2E4MGVjYTljZmEz
IC1yIGI2MDcxYzcxMGY2YyB0b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0X2xpYi5t
NAlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitBQ19ERUZV
TihbQVhfREVGQVVMVF9MSUJdLAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0Il0sIFsK
KyAgICBMSUJfUEFUSD0ibGliNjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkKK0FDX1NV
QlNUKExJQl9QQVRIKV0pCisKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRv
b2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJVHVlIEZlYiAy
MSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdf
RElTQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9T
VFJJTkcoWy0tZGlzYWJsZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEi
ID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0g
Inh5ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWwor
ICAgIGF4X2N2XyQxPSJ5IgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00
Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xz
L200L2VuYWJsZV9mZWF0dXJlLm00CVR1ZSBGZWIgMjEgMDE6NDA6MDQgMjAxMiArMDEwMApAQCAt
MCwwICsxLDEzIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19B
UkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwgWyQyXSkp
CisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9
InkiCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4i
CitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQorJDE9JGF4
X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvbTQvb2NhbWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvb2NhbWwubTQJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAor
ZG5sIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5cmlnaHQg
wqkgMjAwOSAgICAgIFJpY2hhcmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAyMDA5ICAg
ICAgU3RlZmFubyBaYWNjaGlyb2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBPbGl2aWVy
IEFuZHJpZXUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3BoZSBGaWxs
acOidHJlCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8KK2RubAor
ZG5sIEZvciBkb2N1bWVudGF0aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFuIHBhZ2Uu
CisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2Nh
bWxjCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBpZiB0ZXN0
ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8
IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19NU0dfUkVT
VUxUKFtPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9DQU1MTElC
IGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgorICAg
ICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0
YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0dfUkVTVUxU
KFtPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBmaQorICAg
ICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkKKworICAg
ICBBQ19TVUJTVChbT0NBTUxWRVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElCXSkKKwor
ICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTE9Q
VF0sW29jYW1sb3B0XSxbbm9dKQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0ZXN0ICIk
T0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBvY2FtbG9w
dDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1g
JE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAor
CWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFD
X01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2Nh
cmRlZC5dKQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZp
CisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxjLm9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRdLFtvY2Ft
bGMub3B0XSxbbm9dKQorICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVu
CisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24q
ICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJ
T04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2Nh
bWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENE
T1RPUFQKKwlmaQorICAgICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAor
ICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tfVE9PTChb
T0NBTUxPUFRET1RPUFRdLFtvY2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9DQU1MT1BU
RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12
IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3Qg
IiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNfTVNHX1JF
U1VMVChbdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVk
Ll0pCisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZpCisg
ICAgICAgIGZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAgZmkKKwor
ICBBQ19TVUJTVChbT0NBTUxDXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAor
ICBBQ19DSEVDS19UT09MKFtPQ0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9y
IG9jYW1sZGVwCisgIEFDX0NIRUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtub10pCisK
KyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LVE9Q
XSxbb2NhbWxta3RvcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCisgIEFD
X0NIRUNLX1RPT0woW09DQU1MTUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZG9jCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxkb2NdLFtu
b10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09MKFtPQ0FN
TEJVSUxEXSxbb2NhbWxidWlsZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfT0NB
TUxMRVhdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTExFWF0sW29jYW1sbGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgiICE9ICJu
byI7IHRoZW4KKyAgICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1sbGV4Lm9w
dF0sW25vXSkKKyAgICBpZiB0ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRoZW4KKwlP
Q0FNTExFWD0kT0NBTUxMRVhET1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChbT0NBTUxM
RVhdKQorXSkKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAgQUNfQ0hF
Q0tfVE9PTChbT0NBTUxZQUNDXSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChbT0NBTUxZ
QUNDXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAgQUNfUkVR
VUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0CisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENBTUxQNCIg
IT0gIm5vIjsgdGhlbgorICAgICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNlZCAtbiAt
ZSAnc3wuKnZlcnNpb24gKlwoLipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9O
IiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlm
ZmVycyBmcm9tIG9jYW1sY10pCisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBmaQorICBB
Q19TVUJTVChbQ0FNTFA0XSkKKworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9vbHMKKyAg
QUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFDX0NIRUNL
X1RPT0woW0NBTUxQNE9dLFtjYW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRP
Rl0sW2NhbWxwNG9mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtjYW1scDRv
b2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0sW25vXSkK
KyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisgIEFDX0NI
RUNLX1RPT0woW0NBTUxQNFJdLFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1M
UDRSRl0sW2NhbWxwNHJmXSxbbm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisgIEFDX1NV
QlNUKFtDQU1MUDRPXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQ
NE9PRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0UFJPRl0p
CisgIEFDX1NVQlNUKFtDQU1MUDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10pCisKKwor
QUNfREVGVU4oW0FDX1BST0dfRklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0df
T0NBTUxdKWRubAorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTEZJTkRdLFtvY2FtbGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJTkRdKQor
XSkKKworCitkbmwgVGhhbmtzIHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlzIG5leHQg
Yml0IG91dCBmb3IgdXMuCitkbmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0ggaWYgaXQn
cyBub3QgZGVmaW5lZCBhbHJlYWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4KK0FDX0RF
RlVOKFtBQ19DSEVDS19PQ0FNTF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX0ZJ
TkRMSUJdKWRubAorCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIgcGFja2Fn
ZSAkMV0pCisKKyAgdW5zZXQgZm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisgIGZvciBw
a2cgaW4gJDEgJDIgOyBkbworICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rldi9udWxs
IDI+L2Rldi9udWxsOyB0aGVuCisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisgICAgICBB
U19UUl9TSChbT0NBTUxfUEtHXyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAgICBicmVh
aworICAgIGZpCisgIGRvbmUKKyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVuCisgICAg
QUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9
bm8KKyAgZmkKKworICBBQ19TVUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitdKQorCisK
K0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0dfQ0hFQ0tJ
TkcoW2ZvciBPQ2FtbCBtb2R1bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCitv
cGVuICQzCitFT0YKKyAgdW5zZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRvCisgICAg
aWYgJE9DQU1MQyAtYyAtSSAiJCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4KKyAgICAg
IGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVzdCAiJGZv
dW5kIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAgQUNfTVNH
X1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChbJDFdKQor
XSkKKworCitkbmwgWFhYIENyb3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1M
X1dPUkRfU0laRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBB
Q19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBjYXQgPiBj
b25mdGVzdC5tbCA8PEVPRgorICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5cy53b3Jk
X3NpemUpCisgIEVPRgorICBPQ0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAg
QUNfTVNHX1JFU1VMVChbJE9DQU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9XT1JE
X1NJWkVdKQorXSkKKworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAorW2RubAor
ICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtPQ2Ft
bCBTeXMub3NfdHlwZV0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfc3Ry
aW5nKFN5cy5vc190eXBlKTs7CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwgY29uZnRl
c3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VCU1QoW09D
QU1MX09TX1RZUEVdKQorXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRv
b2xzL200L3BhdGhfb3JfZmFpbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9wYXRoX29yX2ZhaWwubTQJVHVlIEZlYiAyMSAwMTo0
MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhfUFJPR19P
Ul9GQUlMXSwKK1tBQ19QQVRIX1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3QgeCIkeyQx
fSIgPT0geCJubyIgCit0aGVuCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCAkMiwg
cGxlYXNlIGluc3RhbGwgJDJdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3
MTBmNmMgdG9vbHMvbTQvcGtnLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL3Rvb2xzL200L3BrZy5tNAlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxNTcgQEAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQg
dXRpbGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgc2VyaWFs
IDEgKHBrZy1jb25maWctMC4yNCkKKyMgCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVz
IFJlbW5hbnQgPHNjb3R0QG5ldHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisjIGl0IHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlz
aGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIg
b2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24u
CisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdp
bGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1Ig
QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv
cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGggdGhpcyBw
cm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5kYXRpb24s
IEluYy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3
LCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBh
IHByb2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRl
ZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3Ry
aWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4K
KworIyBQS0dfUFJPR19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfUFJPR19QS0dfQ09ORklHXSwKK1tt
NF9wYXR0ZXJuX2ZvcmJpZChbXl8/UEtHX1tBLVpfXSskXSkKK200X3BhdHRlcm5fYWxsb3coW15Q
S0dfQ09ORklHKF9QQVRIKT8kXSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUddLCBbcGF0aCB0byBw
a2ctY29uZmlnIHV0aWxpdHldKQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19QQVRIXSwgW2RpcmVj
dG9yaWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGhdKQorQUNfQVJHX1ZBUihb
UEtHX0NPTkZJR19MSUJESVJdLCBbcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBidWlsdC1p
biBzZWFyY2ggcGF0aF0pCisKK2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05GSUdfc2V0IiAh
PSAieHNldCI7IHRoZW4KKwlBQ19QQVRIX1RPT0woW1BLR19DT05GSUddLCBbcGtnLWNvbmZpZ10p
CitmaQoraWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisJX3BrZ19taW5fdmVyc2lvbj1t
NF9kZWZhdWx0KFskMV0sIFswLjkuMF0pCisJQUNfTVNHX0NIRUNLSU5HKFtwa2ctY29uZmlnIGlz
IGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb25dKQorCWlmICRQS0dfQ09ORklHIC0t
YXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgorCQlBQ19N
U0dfUkVTVUxUKFt5ZXNdKQorCWVsc2UKKwkJQUNfTVNHX1JFU1VMVChbbm9dKQorCQlQS0dfQ09O
RklHPSIiCisJZmkKK2ZpW11kbmwKK10pIyBQS0dfUFJPR19QS0dfQ09ORklHCisKKyMgUEtHX0NI
RUNLX0VYSVNUUyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9V
TkRdKQorIworIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVs
ZXMgZXhpc3RzLiAgU2ltaWxhcgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBu
b3Qgc2V0IHZhcmlhYmxlcyBvciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1lbWJlciB0
aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisjIG9ubHkg
YXQgdGhlIGZpcnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBw
bGFjZQorIyBpdCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdp
dGhpbiBhbiAiaWYiLCB5b3UKKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFs
bHkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfRVhJU1RTXSwKK1tBQ19SRVFVSVJFKFtQ
S0dfUFJPR19QS0dfQ09ORklHXSlkbmwKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCisg
ICAgQUNfUlVOX0xPRyhbJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgIiQxIl0p
OyB0aGVuCisgIG00X2RlZmF1bHQoWyQyXSwgWzpdKQorbTRfaWZ2YWxuKFskM10sIFtlbHNlCisg
ICQzXSlkbmwKK2ZpXSkKKworIyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFORF0sIFtN
T0RVTEVTXSkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CittNF9kZWZpbmUoW19QS0dfQ09ORklHXSwKK1tpZiB0ZXN0IC1uICIkJDEiOyB0aGVuCisgICAg
cGtnX2N2X1tdJDE9IiQkMSIKKyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorICAg
IFBLR19DSEVDS19FWElTVFMoWyQzXSwKKyAgICAgICAgICAgICAgICAgICAgIFtwa2dfY3ZfW10k
MT1gJFBLR19DT05GSUcgLS1bXSQyICIkMyIgMj4vZGV2L251bGxgXSwKKwkJICAgICBbcGtnX2Zh
aWxlZD15ZXNdKQorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2ZpW11kbmwKK10pIyBf
UEtHX0NPTkZJRworCisjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQorQUNfREVGVU4oW19QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRF
RF0sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCitpZiAkUEtHX0NPTkZJRyAt
LWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0
X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1
cHBvcnRlZD1ubworZmlbXWRubAorXSkjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorCisK
KyMgUEtHX0NIRUNLX01PRFVMRVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNUSU9OLUlG
LUZPVU5EXSwKKyMgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQorIworIworIyBOb3RlIHRoYXQgaWYg
dGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bworIyBQS0dfQ0hFQ0tfTU9E
VUxFUyBtaWdodCBub3QgaGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgor
IyBleHBsaWNpdCBjYWxsIHRvIFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25maWd1cmUu
YWMKKyMKKyMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfTU9EVUxFU10sCitbQUNfUkVR
VUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0NGTEFHU10s
IFtDIGNvbXBpbGVyIGZsYWdzIGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlkbmwKK0FD
X0FSR19WQVIoWyQxXVtfTElCU10sIFtsaW5rZXIgZmxhZ3MgZm9yICQxLCBvdmVycmlkaW5nIHBr
Zy1jb25maWddKWRubAorCitwa2dfZmFpbGVkPW5vCitBQ19NU0dfQ0hFQ0tJTkcoW2ZvciAkMV0p
CisKK19QS0dfQ09ORklHKFskMV1bX0NGTEFHU10sIFtjZmxhZ3NdLCBbJDJdKQorX1BLR19DT05G
SUcoWyQxXVtfTElCU10sIFtsaWJzXSwgWyQyXSkKKworbTRfZGVmaW5lKFtfUEtHX1RFWFRdLCBb
QWx0ZXJuYXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyAkMVtd
X0NGTEFHUworYW5kICQxW11fTElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBjYWxsIHBrZy1jb25m
aWcuCitTZWUgdGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy5dKQorCitp
ZiB0ZXN0ICRwa2dfZmFpbGVkID0geWVzOyB0aGVuCisgICAJQUNfTVNHX1JFU1VMVChbbm9dKQor
ICAgICAgICBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKKyAgICAgICAgaWYgdGVzdCAkX3Br
Z19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICAkMVtdX1BLR19F
UlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICIkMiIgMj4m
MWAKKyAgICAgICAgZWxzZSAKKwkgICAgICAgICQxW11fUEtHX0VSUk9SUz1gJFBLR19DT05GSUcg
LS1wcmludC1lcnJvcnMgIiQyIiAyPiYxYAorICAgICAgICBmaQorCSMgUHV0IHRoZSBuYXN0eSBl
cnJvciBtZXNzYWdlIGluIGNvbmZpZy5sb2cgd2hlcmUgaXQgYmVsb25ncworCWVjaG8gIiQkMVtd
X1BLR19FUlJPUlMiID4mQVNfTUVTU0FHRV9MT0dfRkQKKworCW00X2RlZmF1bHQoWyQ0XSwgW0FD
X01TR19FUlJPUigKK1tQYWNrYWdlIHJlcXVpcmVtZW50cyAoJDIpIHdlcmUgbm90IG1ldDoKKwor
JCQxX1BLR19FUlJPUlMKKworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEgg
ZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24t
c3RhbmRhcmQgcHJlZml4LgorCitfUEtHX1RFWFRdKWRubAorICAgICAgICBdKQorZWxpZiB0ZXN0
ICRwa2dfZmFpbGVkID0gdW50cmllZDsgdGhlbgorICAgICAJQUNfTVNHX1JFU1VMVChbbm9dKQor
CW00X2RlZmF1bHQoWyQ0XSwgW0FDX01TR19GQUlMVVJFKAorW1RoZSBwa2ctY29uZmlnIHNjcmlw
dCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4g
eW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0
aGUgZnVsbAorcGF0aCB0byBwa2ctY29uZmlnLgorCitfUEtHX1RFWFQKKworVG8gZ2V0IHBrZy1j
b25maWcsIHNlZSA8aHR0cDovL3BrZy1jb25maWcuZnJlZWRlc2t0b3Aub3JnLz4uXSlkbmwKKyAg
ICAgICAgXSkKK2Vsc2UKKwkkMVtdX0NGTEFHUz0kcGtnX2N2X1tdJDFbXV9DRkxBR1MKKwkkMVtd
X0xJQlM9JHBrZ19jdl9bXSQxW11fTElCUworICAgICAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
CSQzCitmaVtdZG5sCitdKSMgUEtHX0NIRUNLX01PRFVMRVMKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgYjYwNzFjNzEwZjZjIHRvb2xzL200L3B5dGhvbl9kZXZlbC5tNAotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25fZGV2ZWwu
bTQJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTggQEAKK0FDX0RF
RlVOKFtBWF9DSEVDS19QWVRIT05fREVWRUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhv
biBkZXZlbF0pCisKK2AkUFlUSE9OIC1jICcKK2ltcG9ydCBvcy5wYXRoLCBzeXMKK2ZvciBwIGlu
IHN5cy5wYXRoOgorICAgIGlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIp
OgorICAgICAgICBzeXMuZXhpdCgwKQorc3lzLmV4aXQoMSkKKycgPiAvZGV2L251bGwgMj4mMWAK
KworaWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAg
ICBBQ19NU0dfRVJST1IoW1B5dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZF0pCitlbHNlCisg
ICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYjYw
NzFjNzEwZjZjIHRvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00Ci0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00
CVR1ZSBGZWIgMjEgMDE6NDA6MDQgMjAxMiArMDEwMApAQCAtMCwwICsxLDEyIEBACitBQ19ERUZV
TihbQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT05dLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhv
biB2ZXJzaW9uID49ICQxLiQyIF0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgZXhpdChldmFs
KCJzeXMudmVyc2lvbl9pbmZvIDwgKCQxLCAkMikiKSknYAoraWYgdGVzdCAiJD8iICE9ICIwIgor
dGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFgCisgICAgQUNfTVNHX1JF
U1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUigKKyAgICAgICAgWyRweXRob25fdmVyc2lvbiBp
cyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgJDEuJDJdKQorZWxzZQorICAg
IEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcx
YzcxMGY2YyB0b29scy9tNC9weXRob25feG1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl94bWwubTQJVHVlIEZlYiAy
MSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9DSEVD
S19QWVRIT05fWE1MXSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24geG1sLmRvbS5taW5p
ZG9tXSkKK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRlc3QgIiQ/
IiAhPSAiMCIKK3RoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9S
KFtVbmFibGUgdG8gZmluZCB4bWwuZG9tLm1pbmlkb20gbW9kdWxlXSkKK2Vsc2UKKyAgICBBQ19N
U0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBiNjA3MWM3MTBm
NmMgdG9vbHMvbTQvc2V0X2NmbGFnc19sZGZsYWdzLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5t
NAlUdWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyMCBAQAorQUNfREVG
VU4oW0FYX1NFVF9GTEFHU10sCitbZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCitkbwor
ICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkUFJF
UEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2Zv
ciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkk
Y2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9M
REZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxB
R1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRB
UFBFTkRfTERGTEFHUyJdKQorCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB0
b29scy9tNC91ZGV2Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL200L3VkZXYubTQJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMzIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0ZXN0ICJ4
JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgIEFDX1BBVEhfUFJPRyhbVURFVkFE
TV0sIFt1ZGV2YWRtXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJubyIg
CisgICAgdGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW1VERVZJTkZPXSwgW3VkZXZpbmZvXSwg
W25vXSkKKyAgICAgICAgaWYgdGVzdCB4IiR7VURFVklORk99IiA9PSB4Im5vIgorICAgICAgICB0
aGVuCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoCisgICAgICAgICAgICAgICAgW1VuYWJsZSB0
byBmaW5kIHVkZXZhZG0gb3IgdWRldmluZm8sIHBsZWFzZSBpbnN0YWxsIHVkZXZdKQorICAgICAg
ICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0n
YAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAg
dGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW0hPVFBMVUddLCBbaG90cGx1Z10sIFtub10pCisg
ICAgICAgIGlmIHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAg
ICAgICAgICBBQ19NU0dfRVJST1IoW3VkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9u
IDU5IG9yIGxhdGVyXSkKKyAgICAgICAgZmkKKyAgICBmaQorZWxzZQorICAgIEFDX1BBVEhfUFJP
RyhbVk5DT05GSUddLCBbdm5jb25maWddLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1ZOQ09ORklH
fSIgPT0geCJubyIKKyAgICB0aGVuCisgICAgICAgIEFDX01TR19FUlJPUihbTm90IGEgTGludXgg
c3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmRdKQorICAgIGZpCitmaQorXSkKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYjYwNzFjNzEwZjZjIHRvb2xzL200L3V1aWQubTQKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdXVpZC5tNAlU
dWUgRmViIDIxIDAxOjQwOjA0IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNfREVGVU4o
W0FYX0NIRUNLX1VVSURdLAorW2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0
aGVuCisgICAgQUNfQ0hFQ0tfSEVBREVSKFt1dWlkL3V1aWQuaF0sLAorCSAgICBbQUNfTVNHX0VS
Uk9SKFtjYW5ub3QgZmluZCB1dWlkIGhlYWRlcnNdKV0pCitlbHNlCisgICAgQUNfQ0hFQ0tfSEVB
REVSKFt1dWlkLmhdLCwKKwkgICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFk
ZXJzXSldKQorZmkKK10pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGI2MDcxYzcxMGY2YyB2ZXJz
aW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3ZlcnNpb24uc2gJVHVlIEZlYiAyMSAwMTo0MDowNCAyMDEyICswMTAwCkBAIC0wLDAgKzEsNSBA
QAorIyEvYmluL3NoCisKK01BSk9SPWBncmVwICJleHBvcnQgWEVOX1ZFUlNJT04iICQxIHwgc2Vk
ICdzLy4qPS8vZycgfCB0ciAtcyAiICJgCitNSU5PUj1gZ3JlcCAiZXhwb3J0IFhFTl9TVUJWRVJT
SU9OIiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorcHJpbnRmICIlZC4lZCIgJE1B
Sk9SICRNSU5PUgo=

--===============5240906552094329370==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

--===============5240906552094329370==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 12:20:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzohZ-0006RY-MM; Tue, 21 Feb 2012 12:20:13 +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 1RzohZ-0006RT-5c
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:20:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329826682!62207641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25012 invoked from network); 21 Feb 2012 12:18:03 -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;
	21 Feb 2012 12:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12: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.213.0; Tue, 21 Feb 2012 12:20:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzohX-0007RC-IS; Tue, 21 Feb 2012 12:20:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzohX-0004NE-GB;
	Tue, 21 Feb 2012 12:20:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.35835.487535.480954@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:20:11 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
References: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] build: add autoconf to replace custom
 checks in tools/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

Roger Pau Monne writes ("[PATCH v6] build: add autoconf to replace custom checks in tools/check"):
> Changes since v5:
> 
>  * Remove dummy configure generation from autogen.sh since it's
>    already on the source tree.

But it doesn't seem to exist in the patch.  Did you forget to add it ?

>  * Removed autogen.sh since it was only a wrapper for calling
>    autoconf.

I would keep this because it makes it clear how to run autoconf.
This is useful even if the invocation is very vanilla.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:20:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzohZ-0006RY-MM; Tue, 21 Feb 2012 12:20:13 +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 1RzohZ-0006RT-5c
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:20:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329826682!62207641!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25012 invoked from network); 21 Feb 2012 12:18:03 -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;
	21 Feb 2012 12:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12: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.213.0; Tue, 21 Feb 2012 12:20:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzohX-0007RC-IS; Tue, 21 Feb 2012 12:20:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzohX-0004NE-GB;
	Tue, 21 Feb 2012 12:20:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.35835.487535.480954@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:20:11 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
References: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] build: add autoconf to replace custom
 checks in tools/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

Roger Pau Monne writes ("[PATCH v6] build: add autoconf to replace custom checks in tools/check"):
> Changes since v5:
> 
>  * Remove dummy configure generation from autogen.sh since it's
>    already on the source tree.

But it doesn't seem to exist in the patch.  Did you forget to add it ?

>  * Removed autogen.sh since it was only a wrapper for calling
>    autoconf.

I would keep this because it makes it clear how to run autoconf.
This is useful even if the invocation is very vanilla.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:21:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzoiq-0006XB-6q; Tue, 21 Feb 2012 12:21:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzoio-0006Wk-KN
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:21:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329826883!15140796!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17284 invoked from network); 21 Feb 2012 12:21:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 12:21:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329826882; l=756;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vY57uZoBiDq6NURExvFUjkrn9Y4=;
	b=AYq/fDaB4tvASsZVcOx0LVaoBmzXnfP+Vw6FrgldkJ5H4LuQpbesRwRZlK86iIalIvh
	YSJ98fLtDb8cqcuT2zp3FDH7YgWHU5+yLo2xVdH6LXfZomVFP2Sj3KwEuV4WmVhHYB2/P
	5ShlXAuGpYWsqo4Le6QteFdf/x51MlLUaFg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jimi mo16) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L00d1co1LCJWwn ;
	Tue, 21 Feb 2012 13:21:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7433C18638; Tue, 21 Feb 2012 13:21:06 +0100 (CET)
Date: Tue, 21 Feb 2012 13:21:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221122106.GA6713@aepfle.de>
References: <20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<20120221112728.GA6339@aepfle.de>
	<1329824093.25232.104.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329824093.25232.104.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, Ian Campbell wrote:

> On Tue, 2012-02-21 at 11:27 +0000, Olaf Hering wrote:
> > On Tue, Feb 21, Ian Campbell wrote:
> > 
> > > If the paging daemon could be start/stopped on demand (rather than being
> > > a domain build time choice) we could even consider making paging the
> > > default.
> > 
> > It would be nice to allow starting paging on demand by xl mem-paging-set.
> > xl could watch memory/target-tot_pages, if it changes and the pager
> > wasnt started during creation, it could start it on request.
> 
> Does it need the watch? Can't the xl which is doing the "mem-set" (or
> whichever) just start the pager?

Then xenpaging would belong to the xl monitoring process. But yes,
either way is fine with me.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:21:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzoiq-0006XB-6q; Tue, 21 Feb 2012 12:21:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzoio-0006Wk-KN
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:21:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329826883!15140796!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17284 invoked from network); 21 Feb 2012 12:21:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 12:21:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329826882; l=756;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vY57uZoBiDq6NURExvFUjkrn9Y4=;
	b=AYq/fDaB4tvASsZVcOx0LVaoBmzXnfP+Vw6FrgldkJ5H4LuQpbesRwRZlK86iIalIvh
	YSJ98fLtDb8cqcuT2zp3FDH7YgWHU5+yLo2xVdH6LXfZomVFP2Sj3KwEuV4WmVhHYB2/P
	5ShlXAuGpYWsqo4Le6QteFdf/x51MlLUaFg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (jimi mo16) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L00d1co1LCJWwn ;
	Tue, 21 Feb 2012 13:21:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7433C18638; Tue, 21 Feb 2012 13:21:06 +0100 (CET)
Date: Tue, 21 Feb 2012 13:21:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221122106.GA6713@aepfle.de>
References: <20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<20120221112728.GA6339@aepfle.de>
	<1329824093.25232.104.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329824093.25232.104.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, Ian Campbell wrote:

> On Tue, 2012-02-21 at 11:27 +0000, Olaf Hering wrote:
> > On Tue, Feb 21, Ian Campbell wrote:
> > 
> > > If the paging daemon could be start/stopped on demand (rather than being
> > > a domain build time choice) we could even consider making paging the
> > > default.
> > 
> > It would be nice to allow starting paging on demand by xl mem-paging-set.
> > xl could watch memory/target-tot_pages, if it changes and the pager
> > wasnt started during creation, it could start it on request.
> 
> Does it need the watch? Can't the xl which is doing the "mem-set" (or
> whichever) just start the pager?

Then xenpaging would belong to the xl monitoring process. But yes,
either way is fine with me.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:22:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzoiw-0006Xw-JM; Tue, 21 Feb 2012 12:21:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzoiu-0006X5-N1
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:21:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329826886!9326268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22676 invoked from network); 21 Feb 2012 12:21:27 -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;
	21 Feb 2012 12:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:21:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:21:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzoik-0007SP-Ga; Tue, 21 Feb 2012 12:21:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzoik-0004NW-Fc;
	Tue, 21 Feb 2012 12:21:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.35910.438137.390890@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:21:26 +0000
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"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 4 of 6 V4] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resume"):
> As I mentioned in the introductory email, these patches also depend on Stefano's XC_SAVE_ID_TOOLSTACK patches.

Sorry, I didn't spot that.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:22:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzoiw-0006Xw-JM; Tue, 21 Feb 2012 12:21:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzoiu-0006X5-N1
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:21:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329826886!9326268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22676 invoked from network); 21 Feb 2012 12:21:27 -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;
	21 Feb 2012 12:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:21:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:21:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzoik-0007SP-Ga; Tue, 21 Feb 2012 12:21:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzoik-0004NW-Fc;
	Tue, 21 Feb 2012 12:21:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.35910.438137.390890@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:21:26 +0000
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
References: <1328817372.13189.93.camel@dagon.hellion.org.uk>
	<47366457a52076b78c52.1328837508@athos.nss.cs.ubc.ca>
	<20290.38989.768884.347346@mariner.uk.xensource.com>
	<CAP8mzPO21LpjbjWnGUSb9BesoWqxXABrBj8UTKETK-ROjbLdpw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"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 4 of 6 V4] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Shriram Rajagopalan writes ("Re: [Xen-devel] [PATCH 4 of 6 V4] libxl: support suspend_cancel in domain_resume"):
> As I mentioned in the introductory email, these patches also depend on Stefano's XC_SAVE_ID_TOOLSTACK patches.

Sorry, I didn't spot that.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:23:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzok3-0006im-PE; Tue, 21 Feb 2012 12:22:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzok2-0006hk-0Y
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:22:46 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329826959!14848995!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19408 invoked from network); 21 Feb 2012 12:22:39 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:22:39 -0000
Received: by werh12 with SMTP id h12so4988745wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:22:38 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr31596990wib.3.1329826958752 (num_hops
	= 1); Tue, 21 Feb 2012 04:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=oPdXHLpTd/g7BfRYgZE5Ob81zwDp2kYSBftmeC6owPQ=;
	b=lp9KuEn92mTW3jYOLQW2dw8zY2185cxCVpYjGeYnLbdbtvN5U+UdRLOhztsV8hm0NZ
	CUZegb35nyMwJk7ofB9HTyQyS6lFU87VWAxDDbQVb27g0n8A/9CiQIFrIHNoLCvN0GPq
	4yY+ot97ouvg0H5J/QLNP12EFz2krvNc2VOMs=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr26337416wib.3.1329826958625; Tue,
	21 Feb 2012 04:22:38 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 04:22:38 -0800 (PST)
In-Reply-To: <20291.35835.487535.480954@mariner.uk.xensource.com>
References: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
	<20291.35835.487535.480954@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 13:22:38 +0100
X-Google-Sender-Auth: soip-UDXwiilHweeZ0cmPjqLp44
Message-ID: <CAPLaKK4t4SypGk8zeyRV+iKx3Xn-SmkVr3Vt1PbPysEXmtF6sQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] build: add autoconf to replace custom
	checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY2XSBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJl
cGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVjayIpOgo+PiBDaGFuZ2VzIHNpbmNlIHY1
Ogo+Pgo+PiDCoCogUmVtb3ZlIGR1bW15IGNvbmZpZ3VyZSBnZW5lcmF0aW9uIGZyb20gYXV0b2dl
bi5zaCBzaW5jZSBpdCdzCj4+IMKgIMKgYWxyZWFkeSBvbiB0aGUgc291cmNlIHRyZWUuCj4KPiBC
dXQgaXQgZG9lc24ndCBzZWVtIHRvIGV4aXN0IGluIHRoZSBwYXRjaC4gwqBEaWQgeW91IGZvcmdl
dCB0byBhZGQgaXQgPwo+Cj4+IMKgKiBSZW1vdmVkIGF1dG9nZW4uc2ggc2luY2UgaXQgd2FzIG9u
bHkgYSB3cmFwcGVyIGZvciBjYWxsaW5nCj4+IMKgIMKgYXV0b2NvbmYuCj4KPiBJIHdvdWxkIGtl
ZXAgdGhpcyBiZWNhdXNlIGl0IG1ha2VzIGl0IGNsZWFyIGhvdyB0byBydW4gYXV0b2NvbmYuCj4g
VGhpcyBpcyB1c2VmdWwgZXZlbiBpZiB0aGUgaW52b2NhdGlvbiBpcyB2ZXJ5IHZhbmlsbGEuCgpJ
J3ZlIHJlbW92ZWQgaXQgYmVjYXVzZSBpdCBvbmx5IGNvbnRhaW5lZCBhIGBjZCB0b29scyAmJiBh
dXRvY29uZmAsCmJ1dCBJIHdpbGwgcmUtYWRkIGl0IGFuZCBzZW5kIHRoZSBwYXRjaC4KCj4KPiBJ
YW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:23:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzok3-0006im-PE; Tue, 21 Feb 2012 12:22:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzok2-0006hk-0Y
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:22:46 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329826959!14848995!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19408 invoked from network); 21 Feb 2012 12:22:39 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:22:39 -0000
Received: by werh12 with SMTP id h12so4988745wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:22:38 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr31596990wib.3.1329826958752 (num_hops
	= 1); Tue, 21 Feb 2012 04:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=oPdXHLpTd/g7BfRYgZE5Ob81zwDp2kYSBftmeC6owPQ=;
	b=lp9KuEn92mTW3jYOLQW2dw8zY2185cxCVpYjGeYnLbdbtvN5U+UdRLOhztsV8hm0NZ
	CUZegb35nyMwJk7ofB9HTyQyS6lFU87VWAxDDbQVb27g0n8A/9CiQIFrIHNoLCvN0GPq
	4yY+ot97ouvg0H5J/QLNP12EFz2krvNc2VOMs=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr26337416wib.3.1329826958625; Tue,
	21 Feb 2012 04:22:38 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 04:22:38 -0800 (PST)
In-Reply-To: <20291.35835.487535.480954@mariner.uk.xensource.com>
References: <b6071c710f6cb6200aaf.1329786087@build.localdomain>
	<20291.35835.487535.480954@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 13:22:38 +0100
X-Google-Sender-Auth: soip-UDXwiilHweeZ0cmPjqLp44
Message-ID: <CAPLaKK4t4SypGk8zeyRV+iKx3Xn-SmkVr3Vt1PbPysEXmtF6sQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v6] build: add autoconf to replace custom
	checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY2XSBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJl
cGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVjayIpOgo+PiBDaGFuZ2VzIHNpbmNlIHY1
Ogo+Pgo+PiDCoCogUmVtb3ZlIGR1bW15IGNvbmZpZ3VyZSBnZW5lcmF0aW9uIGZyb20gYXV0b2dl
bi5zaCBzaW5jZSBpdCdzCj4+IMKgIMKgYWxyZWFkeSBvbiB0aGUgc291cmNlIHRyZWUuCj4KPiBC
dXQgaXQgZG9lc24ndCBzZWVtIHRvIGV4aXN0IGluIHRoZSBwYXRjaC4gwqBEaWQgeW91IGZvcmdl
dCB0byBhZGQgaXQgPwo+Cj4+IMKgKiBSZW1vdmVkIGF1dG9nZW4uc2ggc2luY2UgaXQgd2FzIG9u
bHkgYSB3cmFwcGVyIGZvciBjYWxsaW5nCj4+IMKgIMKgYXV0b2NvbmYuCj4KPiBJIHdvdWxkIGtl
ZXAgdGhpcyBiZWNhdXNlIGl0IG1ha2VzIGl0IGNsZWFyIGhvdyB0byBydW4gYXV0b2NvbmYuCj4g
VGhpcyBpcyB1c2VmdWwgZXZlbiBpZiB0aGUgaW52b2NhdGlvbiBpcyB2ZXJ5IHZhbmlsbGEuCgpJ
J3ZlIHJlbW92ZWQgaXQgYmVjYXVzZSBpdCBvbmx5IGNvbnRhaW5lZCBhIGBjZCB0b29scyAmJiBh
dXRvY29uZmAsCmJ1dCBJIHdpbGwgcmUtYWRkIGl0IGFuZCBzZW5kIHRoZSBwYXRjaC4KCj4KPiBJ
YW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:28:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzopF-0007P0-Ip; Tue, 21 Feb 2012 12:28:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzopD-0007OT-GR
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:28:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329827281!6983405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3026 invoked from network); 21 Feb 2012 12:28: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;
	21 Feb 2012 12:28:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841615"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:28:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:28:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzop6-0007VJ-Dv; Tue, 21 Feb 2012 12:28:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzop6-0004Qo-Cw;
	Tue, 21 Feb 2012 12:28:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.36304.150241.181511@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:28:00 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4unmG7hLcsNxHjH=bn2+xPT5VAqyxqhdNpzW3fTb5TqQ@mail.gmail.com>
References: <1b95948228b84c986764.1326548473@loki.upc.es>
	<20290.29364.583732.682392@mariner.uk.xensource.com>
	<CAPLaKK4unmG7hLcsNxHjH=bn2+xPT5VAqyxqhdNpzW3fTb5TqQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and
 set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: Atomicaly chec=
k backend state and set it to 5 at device_remove"):
> Also I've found myself using a lot a construction like the following:
> =

> - check xenstore path
> - If path value is different than x
> - Set up a watch
> - Wait for events.
> =

> And I'm afraid it's not concurrent safe, since someone can perform a
> bunch of xenstore changes in the space between setting the watch, and
> wait for events. The watcher will only get notified of the last
> xenstore change, but not all changes that happened between.

xenstore is not a message-passing protocol in that way.  There is no
way to be sure that you see all the intermediate values of a
particular xenstore node.  The required approach is for the protocol
not to care about intermediate values, or for the "sender" to
coordinate with the "receiver" somehow.

If all you mean is that you worry about the path changing between the
first read and the setting up of the watch, then you're fine: every
watch is guaranteed to fire once right after you set it up, so your
watch handler function will definitely read the path again and you
won't sit waiting for an event that never comes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:28:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzopF-0007P0-Ip; Tue, 21 Feb 2012 12:28:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzopD-0007OT-GR
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:28:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329827281!6983405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3026 invoked from network); 21 Feb 2012 12:28: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;
	21 Feb 2012 12:28:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841615"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:28:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:28:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzop6-0007VJ-Dv; Tue, 21 Feb 2012 12:28:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzop6-0004Qo-Cw;
	Tue, 21 Feb 2012 12:28:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.36304.150241.181511@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:28:00 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4unmG7hLcsNxHjH=bn2+xPT5VAqyxqhdNpzW3fTb5TqQ@mail.gmail.com>
References: <1b95948228b84c986764.1326548473@loki.upc.es>
	<20290.29364.583732.682392@mariner.uk.xensource.com>
	<CAPLaKK4unmG7hLcsNxHjH=bn2+xPT5VAqyxqhdNpzW3fTb5TqQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and
 set it to 5 at device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: Atomicaly chec=
k backend state and set it to 5 at device_remove"):
> Also I've found myself using a lot a construction like the following:
> =

> - check xenstore path
> - If path value is different than x
> - Set up a watch
> - Wait for events.
> =

> And I'm afraid it's not concurrent safe, since someone can perform a
> bunch of xenstore changes in the space between setting the watch, and
> wait for events. The watcher will only get notified of the last
> xenstore change, but not all changes that happened between.

xenstore is not a message-passing protocol in that way.  There is no
way to be sure that you see all the intermediate values of a
particular xenstore node.  The required approach is for the protocol
not to care about intermediate values, or for the "sender" to
coordinate with the "receiver" somehow.

If all you mean is that you worry about the path changing between the
first read and the setting up of the watch, then you're fine: every
watch is guaranteed to fire once right after you set it up, so your
watch handler function will definitely read the path again and you
won't sit waiting for an event that never comes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzosl-0007cZ-87; Tue, 21 Feb 2012 12:31:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzosk-0007cQ-IO
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:31:46 +0000
Received: from [85.158.139.83:16525] by server-11.bemta-5.messagelabs.com id
	04/D4-14397-1BE834F4; Tue, 21 Feb 2012 12:31:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329827504!12045772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14456 invoked from network); 21 Feb 2012 12:31:45 -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 Feb 2012 12:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:31:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:31:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzosi-0007bB-5P; Tue, 21 Feb 2012 12:31:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzosi-0004Ru-4S;
	Tue, 21 Feb 2012 12:31:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.36528.122485.121423@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:31:44 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329819798.25232.80.camel@dagon.hellion.org.uk>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
	<20290.40164.889190.529383@mariner.uk.xensource.com>
	<1329819798.25232.80.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console
 internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> On Mon, 2012-02-20 at 19:20 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> > > libxl: make libxl_device_console internal
...
> > Isn't it likely that at some future point we will re-expose this
> > difference, for example by providing a different set of access
> > functions ?
> 
> Very likely. However I didn't want to design or commit to an API in the
> total absence of users.
> 
> When a user does come along it is much easier to add a completely new
> API rather than to fix an existing broken one. It's easier to do this in
> a manner which users of the library can cope with in a compatible way
> e.g. adding a new API is easier to check for with ./configure.

Good point.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzosl-0007cZ-87; Tue, 21 Feb 2012 12:31:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzosk-0007cQ-IO
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:31:46 +0000
Received: from [85.158.139.83:16525] by server-11.bemta-5.messagelabs.com id
	04/D4-14397-1BE834F4; Tue, 21 Feb 2012 12:31:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329827504!12045772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14456 invoked from network); 21 Feb 2012 12:31:45 -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 Feb 2012 12:31:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:31:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:31:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzosi-0007bB-5P; Tue, 21 Feb 2012 12:31:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzosi-0004Ru-4S;
	Tue, 21 Feb 2012 12:31:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.36528.122485.121423@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:31:44 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329819798.25232.80.camel@dagon.hellion.org.uk>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<b2934eb211360cdc6f99.1329151977@cosworth.uk.xensource.com>
	<20290.40164.889190.529383@mariner.uk.xensource.com>
	<1329819798.25232.80.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console
 internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> On Mon, 2012-02-20 at 19:20 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 11 of 23] libxl: make libxl_device_console internal"):
> > > libxl: make libxl_device_console internal
...
> > Isn't it likely that at some future point we will re-expose this
> > difference, for example by providing a different set of access
> > functions ?
> 
> Very likely. However I didn't want to design or commit to an API in the
> total absence of users.
> 
> When a user does come along it is much easier to add a completely new
> API rather than to fix an existing broken one. It's easier to do this in
> a manner which users of the library can cope with in a compatible way
> e.g. adding a new API is easier to check for with ./configure.

Good point.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:32:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzot2-0007eV-Me; Tue, 21 Feb 2012 12:32:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzot0-0007eC-Hw
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:32:03 +0000
Received: from [85.158.139.83:18016] by server-11.bemta-5.messagelabs.com id
	60/E5-14397-1CE834F4; Tue, 21 Feb 2012 12:32:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329827518!15118221!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11209 invoked from network); 21 Feb 2012 12:31:58 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:31:58 -0000
Received: by werh12 with SMTP id h12so4995801wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:31:58 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.227 as permitted sender) client-ip=10.180.92.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.227 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.227])
	by 10.180.92.227 with SMTP id cp3mr25502817wib.13.1329827518079
	(num_hops = 1); Tue, 21 Feb 2012 04:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=YoeFB7z2+iUGxDd5CW3hoFqYSOqYLR/gdfG5HmWQ/oU=;
	b=DrmGy4hW4y7eOBOldPr9HvnX38sSbQws94lMfifmd2MP9hvO12x5PF1YKHP/2DAjmB
	5SqwdzFmq0qzZC9cLApIc4rHuLmX7pXnKBum/EOBeuMiovA6ffBKWRKaod2hFYLwoDaA
	SzZhPIS+fpgQGuyHZBpqgx4hbqSZ81axhEykM=
Received: by 10.180.92.227 with SMTP id cp3mr21232612wib.13.1329827517972;
	Tue, 21 Feb 2012 04:31:57 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54885159wib.10.2012.02.21.04.31.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 04:31:57 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============3706650461757472180=="
MIME-Version: 1.0
X-Mercurial-Node: 3bd6a7f9d07d888f40967ef739d393f805fcbfea
Message-Id: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 02:35:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH v7] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3706650461757472180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v6:

 * Readded autogen.sh.

Changes since v5:

 * Remove dummy configure generation from autogen.sh since it's
   already on the source tree.

 * Removed autogen.sh since it was only a wrapper for calling
   autoconf.

 * Remove comment regarding yajl_version.h from configure.ac.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    2 -
 README                            |    4 +
 autogen.sh                        |    3 +
 config/Tools.mk.in                |   50 +++++++
 configure                         |    2 +
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  192 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 55 files changed, 839 insertions(+), 511 deletions(-)



--===============3706650461757472180==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzg3NzQ2IC0zNjAwCiMgTm9kZSBJRCAzYmQ2YTdmOWQw
N2Q4ODhmNDA5NjdlZjczOWQzOTNmODA1ZmNiZmVhCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY2OgoKICogUmVhZGRlZCBh
dXRvZ2VuLnNoLgoKQ2hhbmdlcyBzaW5jZSB2NToKCiAqIFJlbW92ZSBkdW1teSBjb25maWd1cmUg
Z2VuZXJhdGlvbiBmcm9tIGF1dG9nZW4uc2ggc2luY2UgaXQncwogICBhbHJlYWR5IG9uIHRoZSBz
b3VyY2UgdHJlZS4KCiAqIFJlbW92ZWQgYXV0b2dlbi5zaCBzaW5jZSBpdCB3YXMgb25seSBhIHdy
YXBwZXIgZm9yIGNhbGxpbmcKICAgYXV0b2NvbmYuCgogKiBSZW1vdmUgY29tbWVudCByZWdhcmRp
bmcgeWFqbF92ZXJzaW9uLmggZnJvbSBjb25maWd1cmUuYWMuCgpDaGFuZ2VzIHNpbmNlIHY0OgoK
ICogVXBkYXRlZCB0byB0aXAuCgogKiBJbmNsdWRlIGNvbmZpZy5oIGZyb20gY29tcGlsZXIgY29t
bWFuZCBsaW5lIHdoZW4gYnVpbGRpbmcgbGlieGwgYW5kCiAgIHhsIHRvIGFzc3VyZSB5YWpsX3Zl
cnNpb24uaCBwcmVzZW5jZSBhbmQgY29ycmVjdGx5IGRldGVjdCB5YWpsCiAgIHZlcnNpb24uCgog
KiBBZGRlZCBnbGliLTIuMCBjaGVjayB3aXRoIGFwcHJvcGlhdGUgbTQgbWFjcm9zLgoKICogUHVy
Z2VkIGNvbmZpZy5oLmluIGZyb20gdW5uZWNlc3NhcnkgZGVmaW5lcyB0aGF0IGNvdWxkIG1lc3Mg
d2l0aAogICB0aGUgYnVpbGQgc3lzdGVtLgoKICogUmVtb3ZlZCB0b29scy9jb25maWcuc3ViLCB0
b29scy9jb25maWcuZ3Vlc3MsIHRvb2xzL2NvbmZpZ3VyZSBhbmQKICAgY29uZmlndXJlIHRvIG1h
a2UgdGhlIHBhdGNoIGZpdCBtYWlsaW5nIGxpc3QgbGltaXQuCgpDaGFuZ2VzIHNpbmNlIHYzOgoK
ICogQ29waWVkIGNvbmZpZy5ndWVzcyBhbmQgY29uZmlnLnN1YiBmcm9tIGF1dG9tYWtlIDEuMTEu
CgogKiBBZGRlZCBhIHRlc3QgdG8gY2hlY2sgZm9yIHV1aWQuaCBvbiBCU0QgYW5kIHV1aWQvdXVp
ZC5oIG9uIExpbnV4LgoKQ2hhbmdlcyBzaW5jZSB2MjoKCiAqIENoYW5nZWQgb3JkZXIgb2YgY29u
ZmlnL1Rvb2xzLm1rIGluY2x1ZGUuCgogKiBBZGRlZCAiLWUiIHRvIGF1dG9nZW4uc2ggc2hlYmFu
Zy4KCiAqIEFkZGVkIG5lY2Vzc2FyeSBmaWxlcyAoY29uZmlnLiopIGFuZCBvdXRwdXQgZnJvbSBB
dXRvaGVhZGVyIGFuZAogICBBdXRvY29uZi4KCiAqIFJlbW92ZWQgQXV0b2NvbmYgZnJvbSBidWls
ZCBkZXBlbmRlbmNpZXMgYW5kIHVwZGF0ZWQgUkVBRE1FLgoKQ2hhbmdlcyBzaW5jZSB2MToKCiAq
IE1vdmVkIGF1dG9jb25mIHN0dWZmIGluc2lkZSB0b29scyBmb2xkZXIuCgogKiBBZGQgTWFrZWZp
bGUgcnVsZXMgZm9yIGNsZWFuaW5nLgoKICogUmVtb3ZlZCBBdXRvbWFrZSBkZXBlbmRlbmN5LgoK
ICogQ3JlYXRlIGF1dG9nZW4uc2ggdG8gYXV0b21hdGljYWxseSBjcmVhdGUgY29uZmlndXJlIHNj
cmlwdCB3aGVuCiAgIGJ1aWxkaW5nIGZyb20gc291cmNlIHJlcG9zaXRvcnkuCgogKiBDYWNoZWQg
dmFsdWVzIG9mIG9wdGlvbnMgcGFzc2VkIGZyb20gY29tbWFuZCBsaW5lLgoKICogQWRkIG5lY2Vz
c2FyeSBpZ25vcmVzIHRvIC5oZ2lnbm9yZS4KCiAqIEFkZGVkIEF1dG9jb25mIHRvIHRoZSBsaXN0
IG9mIGRlcGVuZGVuY2llcy4KCiAqIENoYW5nZWQgaHlwZW4gdG8gdW5kZXJzY29yZSBpbiBYTUwy
IGFuZCBDVVJMIHZhcmlhYmxlIG5hbWVzLgoKICogQWRkZWQgc2NyaXB0IHRvIGdldCB2ZXJzaW9u
IGZyb20geGVuL01ha2VmaWxlLgoKICogU2V0IE9jYW1sIHRvb2xzIHRvIG9wdGlvbmFsLgoKICog
QWRkZWQgcHJvY2VkZW5jZSBvZiBtNC9vY2FtbC5tNC4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBh
dSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAt
ciAzYmQ2YTdmOWQwN2QgLmhnaWdub3JlCi0tLSBhLy5oZ2lnbm9yZQlNb24gRmViIDIwIDE4OjM0
OjE0IDIwMTIgKzAwMDAKKysrIGIvLmhnaWdub3JlCVR1ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiAr
MDEwMApAQCAtMzAzLDYgKzMwMywxMiBAQAogXnRvb2xzL29jYW1sL2xpYnMveGwveGVubGlnaHRc
Lm1sJAogXnRvb2xzL29jYW1sL2xpYnMveGwveGVubGlnaHRcLm1saSQKIF50b29scy9vY2FtbC94
ZW5zdG9yZWQvb3hlbnN0b3JlZCQKK150b29scy9hdXRvbTR0ZVwuY2FjaGUkCitedG9vbHMvY29u
ZmlnXC5oJAorXnRvb2xzL2NvbmZpZ1wubG9nJAorXnRvb2xzL2NvbmZpZ1wuc3RhdHVzJAorXnRv
b2xzL2NvbmZpZ1wuY2FjaGUkCiteY29uZmlnL1Rvb2xzXC5tayQKIF54ZW4vXC5iYW5uZXIuKiQK
IF54ZW4vQkxPRyQKIF54ZW4vU3lzdGVtLm1hcCQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2Jk
NmE3ZjlkMDdkIENvbmZpZy5tawotLS0gYS9Db25maWcubWsJTW9uIEZlYiAyMCAxODozNDoxNCAy
MDEyICswMDAwCisrKyBiL0NvbmZpZy5tawlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAK
QEAgLTcwLDkgKzcwLDYgQEAgRVhUUkFfSU5DTFVERVMgKz0gJChFWFRSQV9QUkVGSVgpL2luY2x1
ZAogRVhUUkFfTElCICs9ICQoRVhUUkFfUFJFRklYKS8kKExJQkxFQUZESVIpCiBlbmRpZgogCi1C
SVNPTgk/PSBiaXNvbgotRkxFWAk/PSBmbGV4Ci0KIFBZVEhPTiAgICAgID89IHB5dGhvbgogUFlU
SE9OX1BSRUZJWF9BUkcgPz0gLS1wcmVmaXg9IiQoUFJFRklYKSIKICMgVGhlIGFib3ZlIHJlcXVp
cmVzIHRoYXQgUFJFRklYIGNvbnRhaW5zICpubyBzcGFjZXMqLiBUaGlzIHZhcmlhYmxlIGlzIGhl
cmUKQEAgLTE3NSwzMiArMTcyLDkgQEAgQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKFBSRVBFTkRf
SU5DTFVERQogQVBQRU5EX0xERkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0xJQiksIC1M
JChpKSkKIEFQUEVORF9DRkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0lOQ0xVREVTKSwg
LUkkKGkpKQogCi1DSEVDS19MSUIgPSAkKEVYVFJBX0xJQikgJChQUkVQRU5EX0xJQikgJChBUFBF
TkRfTElCKQotQ0hFQ0tfSU5DTFVERVMgPSAkKEVYVFJBX0lOQ0xVREVTKSAkKFBSRVBFTkRfSU5D
TFVERVMpICQoQVBQRU5EX0lOQ0xVREVTKQotCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgOj0gLW5v
cGllIC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tc3RhY2stcHJvdGVjdG9yLWFsbAogRU1CRURE
RURfRVhUUkFfQ0ZMQUdTICs9IC1mbm8tZXhjZXB0aW9ucwogCi1DT05GSUdfTElCSUNPTlYgICA6
PSAkKHNoZWxsIGV4cG9ydCBPUz0iYHVuYW1lIC1zYCI7IFwKLSAgICAgICAgICAgICAgICAgICAg
ICAgZXhwb3J0IENIRUNLX0xJQj0iJChDSEVDS19MSUIpIjsgXAotICAgICAgICAgICAgICAgICAg
ICAgICAuICQoWEVOX1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNoOyBcCi0gICAgICAgICAgICAg
ICAgICAgICAgIGhhc19saWIgbGliaWNvbnYuc28gJiYgZWNobyAneScgfHwgZWNobyAnbicpCi0K
LUNPTkZJR19ZQUpMX1ZFUlNJT04gOj0gJChzaGVsbCBleHBvcnQgT1M9ImB1bmFtZSAtc2AiOyBc
Ci0gICAgICAgICAgICAgICAgICAgICAgIGV4cG9ydCBDSEVDS19JTkNMVURFUz0iJChDSEVDS19J
TkNMVURFUykiOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIC4gJChYRU5fUk9PVCkvdG9vbHMv
Y2hlY2svZnVuY3Muc2g7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgaGFzX2hlYWRlciB5YWps
L3lhamxfdmVyc2lvbi5oICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi0jIEVuYWJsZSBYU00g
c2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCi1YU01fRU5BQkxFID89IG4KLUZM
QVNLX0VOQUJMRSA/PSAkKFhTTV9FTkFCTEUpCi0KLSMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmll
cyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJvdG9jb2w/Ci0jIEdJVCdzIHByb3RvY29sIGlzIGZh
c3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKLSMg
bWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJl
cG9zaXRvcnkgZG93bmxvYWRzCi0jIGZhaWwgb3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hU
VFA9eSBpbiB5b3VyIGVudmlyb25tZW50LgotR0lUX0hUVFAgPz0gbgotCiBYRU5fRVhURklMRVNf
VVJMPWh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzCiAjIEFsbCB0aGUg
ZmlsZXMgYXQgdGhhdCBsb2NhdGlvbiB3ZXJlIGRvd25sb2FkZWQgZnJvbSBlbHNld2hlcmUgb24K
ICMgdGhlIGludGVybmV0LiAgVGhlIG9yaWdpbmFsIGRvd25sb2FkIFVSTCBpcyBwcmVzZXJ2ZWQg
YXMgYSBjb21tZW50CkBAIC0yMzksMTcgKzIxMyw0IEBAIFFFTVVfVEFHID89IDEyOGRlMjU0OWM1
ZjI0ZTRhNDM3Yjg2YmQyZTQKICMgU2hvcnQgYW5zd2VyIC0tIGRvIG5vdCBlbmFibGUgdGhpcyB1
bmxlc3MgeW91IGtub3cgd2hhdCB5b3UgYXJlCiAjIGRvaW5nIGFuZCBhcmUgcHJlcGFyZWQgZm9y
IHNvbWUgcGFpbi4KIAotIyBPcHRpb25hbCBjb21wb25lbnRzCi1YRU5TVEFUX1hFTlRPUCAgICAg
Pz0geQotVlRQTV9UT09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQSV9CSU5ESU5HUyA/PSBuCi1Q
WVRIT05fVE9PTFMgICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAgICAgID89IHkKLUNPTkZJR19N
SU5JVEVSTSAgICA/PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0gbgotQ09ORklHX1NZU1RFTV9M
SUJBSU8gPz0geQogQ09ORklHX1RFU1RTICAgICAgID89IHkKLQotaWZlcSAoJChPQ0FNTF9UT09M
UykseSkKLU9DQU1MX1RPT0xTIDo9ICQoc2hlbGwgb2NhbWxvcHQgLXYgPiAvZGV2L251bGwgMj4m
MSAmJiBlY2hvICJ5IiB8fCBlY2hvICJuIikKLWVuZGlmCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IDNiZDZhN2Y5ZDA3ZCBNYWtlZmlsZQotLS0gYS9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0
IDIwMTIgKzAwMDAKKysrIGIvTWFrZWZpbGUJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAw
CkBAIC00MCwxMSArNDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlz
dDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRpc3QtZG9j
cyBkaXN0LW1pc2MKIAogZGlzdC1taXNjOgotCSQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hl
Y2sKIAkkKElOU1RBTExfREFUQSkgLi9DT1BZSU5HICQoRElTVERJUikKIAkkKElOU1RBTExfREFU
QSkgLi9SRUFETUUgJChESVNURElSKQogCSQoSU5TVEFMTF9QUk9HKSAuL2luc3RhbGwuc2ggJChE
SVNURElSKQotCSQoSU5TVEFMTF9QUk9HKSB0b29scy9jaGVjay9jaGsgdG9vbHMvY2hlY2svY2hl
Y2tfKiB0b29scy9jaGVjay9mdW5jcy5zaCAkKERJU1RESVIpL2NoZWNrCiBkaXN0LSU6IERFU1RE
SVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0LSU6IGluc3RhbGwtJQogCUA6ICMgZG8gbm90aGlu
ZwpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgUkVBRE1FCi0tLSBhL1JFQURN
RQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvUkVBRE1FCVR1ZSBGZWIgMjEg
MDI6Mjk6MDYgMjAxMiArMDEwMApAQCAtODksOSArODksMTMgQEAgMi4gY2QgdG8geGVuLXVuc3Rh
YmxlIChvciB3aGF0ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5IGZpcnN0IGJ1aWxkLCBvciBp
ZiB5b3Ugd2FudCB0byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAgcGVyZm9ybSB0aGUgZm9sbG93
aW5nIHN0ZXBzOgogCisgICAgIyAuL2NvbmZpZ3VyZQogICAgICMgbWFrZSB3b3JsZAogICAgICMg
bWFrZSBpbnN0YWxsCiAKKyAgIElmIHlvdSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAt
LWhlbHAgdG8gc2VlIHRoZSBsaXN0IG9mCisgICBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25zIHdo
ZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxpbmcgWGVuLgorCiAgICBUaGlzIHdpbGwgY3JlYXRlIGFu
ZCBpbnN0YWxsIG9udG8gdGhlIGxvY2FsIG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQKICAgIHRoZSB4
ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgogCmRp
ZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCBhdXRvZ2VuLnNoCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL2F1dG9nZW4uc2gJVHVlIEZl
YiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMyBAQAorIyEvYmluL3NoIC1lCitj
ZCB0b29scworYXV0b2NvbmYKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIGNv
bmZpZy9Ub29scy5tay5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9jb25maWcvVG9vbHMubWsuaW4JVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsNTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklY
ICAgICAgICAgICAgICA6PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BB
VEhACisKKyMgQSBkZWJ1ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0g
QGRlYnVnQAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAor
RkxFWCAgICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZ
VEhPTkAKK1BZVEhPTl9QQVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAg
ICAgICAgIDo9IEBQRVJMQAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAg
ICAgICAgICAgICAgIDo9IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwy
X0NPTkZJRyAgICAgICAgIDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAor
WEdFVFRURVhUICAgICAgICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBs
aWJzL2luY2x1ZGVzCitQUkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAor
UFJFUEVORF9MSUIgICAgICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAg
IDo9IEBBUFBFTkRfSU5DTFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElC
QAorCisjIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitY
U01fRU5BQkxFICAgICAgICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21A
CisKKyMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJv
dG9jb2w/CisjIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4g
aXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0
aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwg
b3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50Lgor
R0lUX0hUVFAgICAgICAgICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRz
CitYRU5TVEFUX1hFTlRPUCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAg
Oj0gQHZ0cG1ACitMSUJYRU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAg
ICAgICA6PSBAcHl0aG9udG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xz
QAorQ09ORklHX01JTklURVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAg
IDo9IEBsb21vdW50QAorCisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0g
QHN5c3RlbV9haW9ACitDT05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19H
Q1JZUFQgICAgICAgOj0gQGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4
dDJmc0AKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIGNvbmZpZ3VyZQotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJ
VHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3No
IC1lCitjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAz
YmQ2YTdmOWQwN2QgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDI6
Mjk6MDYgMjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlv
CiBlbmRpZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9
IGluY2x1ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2
ICs3OCw4IEBAIGNsZWFuOiBzdWJkaXJzLWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNs
ZWFuCiAJcm0gLXJmIHFlbXUteGVuLXRyYWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25h
bC1kaXItcmVtb3RlCiAJcm0gLXJmIHFlbXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJ
cm0gLXJmIC4uL2NvbmZpZy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0
dXMgXAorCQljb25maWcuY2FjaGUgYXV0b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJ
TEVfQVJDSCksJChYRU5fVEFSR0VUX0FSQ0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0t
Y3B1PSQoWEVOX1RBUkdFVF9BUkNIKSBcCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5
ZDA3ZCB0b29scy9SdWxlcy5tawotLS0gYS90b29scy9SdWxlcy5tawlNb24gRmViIDIwIDE4OjM0
OjE0IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvUnVsZXMubWsJVHVlIEZlYiAyMSAwMjoyOTowNiAy
MDEyICswMTAwCkBAIC00LDYgKzQsNyBAQAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0Nv
bmZpZy5taworaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9J
TlNUQUxMIDo9ICQoSU5TVEFMTCkKIElOU1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1p
bnN0YWxsCkBAIC04MCw4ICs4MSw2IEBAIGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2Mt
dmVyLWNoZWMKICAgICAgICAgICAgICAgICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3Qg
Z2NjLTMuNCIpCiAkKGV2YWwgJChjaGVjay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwg
d2hpY2ggJChQWVRIT04pKQotUFlUSE9OX1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxM
X1BZVEhPTl9QUk9HID0gXAogCSQoWEVOX1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAg
IiQoUFlUSE9OX1BBVEgpIiAkKElOU1RBTExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1
YmRpci1hbGwtJSBzdWJkaXItY2xlYW4tJSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVh
bi0lOiAucGhvbnkKIAkkKE1BS0UpIC1DICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9U
b29scy5tazoKKwlAZWNobyAiWW91IGhhdmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWls
ZGluZyBvciBpbnN0YWxsaW5nIHRoZSB0b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90
b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIGIvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVHVlIEZlYiAyMSAwMjoyOTow
NiAyMDEyICswMTAwCkBAIC0xMyw3ICsxMyw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhl
bnN0b3JlKQogQ0ZMQUdTICAgKz0gLUkgJChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05V
X1NPVVJDRQogCi1pZmVxICgkKHNoZWxsIC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lm
ZXEgKCRDT05GSUdfR0NSWVBULHkpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIg
Oj0gLWxnY3J5cHQKIGVsc2UKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRv
b2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVy
cy9jaGVja19nY3J5cHQJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jp
bi9zaAotCi1jYXQgPiAuZ2NyeXB0LmMgPDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQg
bWFpbih2b2lkKSB7IHJldHVybiAwOyB9Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0
LmMgLWxnY3J5cHQgMj4vZGV2L251bGwgOyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNo
byAibm8iCi1maQotCi1ybSAtZiAuZ2NyeXB0KgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvY2hlY2svTWFrZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIp
Ly4uLy4uCi1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRo
ZSBuZWNlc3NhcnkgZW52aXJvbm1lbnQgdmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQ
WVRIT04KLWV4cG9ydCBMSUJYRU5BUElfQklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwot
ZXhwb3J0IENIRUNLX0xJQgotZXhwb3J0IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTog
YWxsIGluc3RhbGwKLWFsbCBpbnN0YWxsOiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFj
aGluZSBpcyBPSyBmb3IgYnVpbGRpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1i
dWlsZDoKLQkuL2NoayBidWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5z
dGFsbGluZyBvbi4KLS5QSE9OWTogY2hlY2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2No
ayBpbnN0YWxsCi0KLS5QSE9OWTogY2xlYW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9v
bHMvY2hlY2svUkVBRE1FCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVj
a3MgZm9yIHRoZSBzdWl0YWJpbGl0eSBvZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0
YWxsLgotVG8gY2hlY2sgZm9yIGJ1aWxkIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hr
IGJ1aWxkCi0KLVRvIGNoZWNrIGZvciBpbnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAg
IC4vY2hrIGluc3RhbGwKLQotVGhlIGNoayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMg
ZGlyZWN0b3J5IGFuZCBwcmludAotdGhlIG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3Ro
aW5nIGlmIGNoZWNrcyBzdWNjZWVkLgotVGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1
Y2Nlc3MgYW5kIDEgb24gZmFpbHVyZS4KLQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxl
IGZpbGVzIGluIHRoaXMgZGlyZWN0b3J5IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18n
LiBGaWxlcyBjb250YWluaW5nIENIRUNLLUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hl
Y2ssIGFuZCBmaWxlcyBjb250YWluaW5nIENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBp
bnN0YWxsIGNoZWNrLgotCi1EZXRhaWxlZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBp
cyBpbiAuY2hrYnVpbGQgZm9yIGJ1aWxkCi1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwg
Tm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdm
OWQwN2QgdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJj
dGwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8
RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBicmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwg
YnJjdGwgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfY3J5cHRvX2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEg
KzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1
bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7
OwotZXNhYwotCi1oYXNfbGliIGxpYmNyeXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0
by5zbyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2No
ZWNrX2N1cmwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfY3VybAlNb24gRmViIDIwIDE4OjM0OjE0
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwK
LQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgIiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0
aGVuCi0JZWNobyAtbiAidW51c2VkLCAiCi0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJs
LWNvbmZpZwotY3VybF9saWJzPWBjdXJsLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29u
ZmlnIC0tbGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRl
bmN5IGxpYnJhcmllcyBmb3IgY3VybCBhcmUgbWlzc2luZyIKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfaXByb3V0ZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBB
VEgKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwg
aWZjb25maWcgOzsKLUxpbnV4KQotCWhhc19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25v
d24gT1MiIDs7Ci1lc2FjCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29s
cy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlv
X2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMg
Q0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJB
SU99ICE9IFgieSIgXSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGli
YWlvLmggOyB0aGVuCi0gICAgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFs
bCBsaWJhaW8gZGV2ZWwgcGFja2FnZSBvciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZp
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9jaGVja19s
aWJhaW9fbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlO
U1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9
IFgieSIgXSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWls
ICJjYW4ndCBmaW5kIGxpYmFpbyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdk
IHRvb2xzL2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
b3BlbnNzbF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9t
ZDUuaCB8fCBmYWlsICJtaXNzaW5nIG9wZW5zc2wgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNm
YTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9j
aGVjay9jaGVja19weXRob24JTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1p
ZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhP
Tn0gLWMgJwotaW1wb3J0IHN5cwotc3lzLmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Ig
c3lzLnZlcnNpb25faW5mb1sxXSA8IDMpCi0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24g
Pj0gMi4zIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgdG9vbHMvY2hlY2sv
Y2hlY2tfcHl0aG9uX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlN
b24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJV
SUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRI
T049cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1p
bXBvcnQgb3MucGF0aCwgc3lzCi1mb3IgcCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0
cyhwICsgIi9jb25maWcvTWFrZWZpbGUiKToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0n
IHx8IGZhaWwgImNhbid0IGZpbmQgcHl0aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90
b29scy9jaGVjay9jaGVja19weXRob25feG1sCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAw
MAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYg
dGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWls
ICR7UFlUSE9OfQotCi0ke1BZVEhPTn0gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rl
di9udWxsIHx8IFwKLWZhaWwgImNhbid0IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX3VkZXYJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAg
QEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRP
UyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7
Ci1MaW51eCkKLQloYXMgL3NiaW4vdWRldmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZh
ZG0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhh
c19vcl9mYWlsIHVkZXZpbmZvICYmIFwKLQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3tw
cmludCAkTkZ9J2AKLQlbICIkdWRldnZlciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQlo
YXMgaG90cGx1ZyB8fCBcCi0JCWZhaWwgInVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJz
aW9uIDU5IG9yIGxhdGVyIgotCTs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3V1
aWRfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAlNb24gRmViIDIwIDE4
OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsNyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1
bmNzLnNoCi0KLWhhc19oZWFkZXIgdXVpZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmgg
fHwgZmFpbCAibWlzc2luZyB1dWlkIGhlYWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1y
IGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVs
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3gxMV9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsOSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0K
LWhhc19oZWFkZXIgWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9p
bmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVk
ZS9YMTEva2V5c3ltZGVmLmggfHwgXAotd2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3hn
ZXR0ZXh0Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0CU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Mu
c2gKLQotaGFzX29yX2ZhaWwgeGdldHRleHQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3
ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1s
MglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQ
SV9CSU5ESU5HUyIgPSAieSIgXQotdGhlbgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4
aXQgMAotZmkKLQotaGFzX29yX2ZhaWwgeG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25m
aWcgLS1saWJzYCB8fCBmYWlsICJ4bWwyLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5r
ICR4bWwyX2xpYnMgfHwgZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1p
c3NpbmciCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9j
aGVja195YWpsX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDggKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNh
bid0IGZpbmQgeWFqbC95YWpsX3BhcnNlLmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8
fCBmYWlsICJjYW4ndCBmaW5kIHlhamwveWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8
fCBmYWlsICJjYW4ndCBmaW5kIGxpYnlhamwuc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNi
ZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNr
L2NoZWNrX3psaWJfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIu
aCB8fCBmYWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3psaWJfbGliCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQot
Y2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMK
LQotaGFzX2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVj
ay9jaGsJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1m
dW5jX3VzYWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8
aW5zdGFsbHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZv
ciBYZW4gYnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEg
aWYgbm90LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3Zl
cyBnZW5lcmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91
c3Ivc2JpbgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJT
dW5PUyIgXTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAg
ICAgICBjaGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAg
ICAgY2hlY2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAg
IGV4aXQgMAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAg
OzsKLWVzYWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3Ig
ZiBpbiBjaGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAg
ICAgY29udGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7Owot
ICAgIGVzYWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAg
ICBmaQotICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRp
bnVlCi0gICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4m
MSA7IHRoZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAg
ICBmaQotZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBh
cyB3aGljaCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0J
aWYgWyAteiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0J
CXJldHVybiAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJz
aGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlm
b3IgcCBpbiAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0
aGVuCi0JCQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQot
CWRvbmUKLQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9k
ZXYvbnVsbCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNo
ZWNrX3N5c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQot
CQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJl
dHVybiAwCi0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYg
WyAtciAiJENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0J
CQlmaQotCQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsK
LQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBv
bGx1dGlvbiBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAg
ICAgICAjIGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQot
CSMgVGhpcyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxs
ZWQgYnV0Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24n
dCB3b3JrLgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRj
L2xkLnNvLmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIg
XCIkQ1JPU1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxs
IHRocm91Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7
T1N9IiA9ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1y
ICIkQ1JPU1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlp
ZiBbICIke09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdy
ZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9s
aW5rKCkgewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5z
ZXQgdG1wZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1w
ZmlsZT1gbWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9u
dWxsIDI+JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNv
bW1vbmx5IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIg
XSAmJiByZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hv
ICJwbGVhc2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJu
IDEKLQlmaQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5v
IHN5cy1yb290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQot
Ci13YXJuaW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQk
eyorOiAkKn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIk
MCJgIEZBSUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
M2JkNmE3ZjlkMDdkIHRvb2xzL2NvbmZpZy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5oLmluCVR1ZSBGZWIgMjEgMDI6
Mjk6MDYgMjAxMiArMDEwMApAQCAtMCwwICsxLDE2IEBACisvKgorICogQ29weXJpZ2h0IChDKSAy
MDEyCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0
cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAorICogYnkgdGhlIEZy
ZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lh
bAorICogZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KKyAq
CisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxs
IGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo
ZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1Ig
QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqLworCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVm
IEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdm
OWQwN2QgdG9vbHMvY29uZmlndXJlLmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwlUdWUgRmViIDIxIDAyOjI5OjA2
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxOTIgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZp
bGUgd2l0aCBhdXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJF
UkVRKFsyLjY3XSkKK0FDX0lOSVQoW1hlbiBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVy
c2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVdKSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb21dKQorQUNfQ09ORklHX1NSQ0RJUihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklM
RVMoWy4uL2NvbmZpZy9Ub29scy5ta10pCitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQor
QUNfUFJFRklYX0RFRkFVTFQoWy91c3JdKQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENo
ZWNrIGlmIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQg
cHJpbnQgYSB3YXJuaW5nCisKK0FTX0lGKFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElC
UyRDUFBGTEFHUyRDUFAiXSwgWworICAgIEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFH
UywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwg
dXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5k
IEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVN
X0VYVEVOU0lPTlMKK0FDX0NBTk9OSUNBTF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200
X2luY2x1ZGUoW200L2VuYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVf
ZmVhdHVyZS5tNF0pCittNF9pbmNsdWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVk
ZShbbTQvcHl0aG9uX3htbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0p
CittNF9pbmNsdWRlKFttNC9weXRob25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5t
NF0pCittNF9pbmNsdWRlKFttNC9vY2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xp
Yi5tNF0pCittNF9pbmNsdWRlKFttNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVk
ZShbbTQvdXVpZC5tNF0pCittNF9pbmNsdWRlKFttNC9wa2cubTRdKQorCisjIEVuYWJsZS9kaXNh
YmxlIG9wdGlvbnMKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeHNtXSwKKyAgICBbRW5hYmxl
IFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0pCitBWF9BUkdfRU5BQkxF
X0FORF9FWFBPUlQoW2dpdGh0dHBdLCBbRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRU
UF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFttb25pdG9yc10sCisgICAgW0Rpc2FibGUg
eGVuc3RhdCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRf
RVhQT1JUKFt2dHBtXSwgW0VuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlXSkK
K0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeGFwaV0sIFtFbmFibGUgWGVuIEFQSSBCaW5kaW5n
c10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtweXRob250b29sc10sIFtEaXNhYmxlIFB5
dGhvbiB0b29sc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtvY2FtbHRvb2xzXSwgW0Rp
c2FibGUgT2NhbWwgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFttaW5pdGVybV0s
IFtFbmFibGUgbWluaXRlcm1dKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtsb21vdW50XSwg
W0VuYWJsZSBsb21vdW50XSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW2RlYnVnXSwgW0Rp
c2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29sc10pCisKK0FDX0FSR19WQVIoW1BSRVBF
TkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRv
IENGTEFHUyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbUFJFUEVORF9MSUJdLAorICAgIFtM
aXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwp
XSkKK0FDX0FSR19WQVIoW0FQUEVORF9JTkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBm
b2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW0FQ
UEVORF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERG
TEFHUyAod2l0aG91dCAtTCldKQorCitBWF9TRVRfRkxBR1MKKworQUNfQVJHX1ZBUihbUFlUSE9O
XSwgW1BhdGggdG8gdGhlIFB5dGhvbiBwYXJzZXJdKQorQUNfQVJHX1ZBUihbUEVSTF0sIFtQYXRo
IHRvIFBlcmwgcGFyc2VyXSkKK0FDX0FSR19WQVIoW0JSQ1RMXSwgW1BhdGggdG8gYnJjdGwgdG9v
bF0pCitBQ19BUkdfVkFSKFtJUF0sIFtQYXRoIHRvIGlwIHRvb2xdKQorQUNfQVJHX1ZBUihbQklT
T05dLCBbUGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0ZMRVhd
LCBbUGF0aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIo
W0NVUkxdLCBbUGF0aCB0byBjdXJsLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW1hNTF0sIFtQ
YXRoIHRvIHhtbDItY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZBUihbQkFTSF0sIFtQYXRoIHRvIGJh
c2ggc2hlbGxdKQorQUNfQVJHX1ZBUihbWEdFVFRFWFRdLCBbUGF0aCB0byB4Z2V0dHRleHQgdG9v
bF0pCisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK0FDX1BST0dfU0VECitBQ19QUk9HX0NDCitB
Q19QUk9HX0xOX1MKK0FDX1BST0dfTUFLRV9TRVQKK0FDX1BST0dfSU5TVEFMTAorQVhfUEFUSF9Q
Uk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVybF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQlJDVExd
LCBbYnJjdGxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQXSwgW2lwXSkKK0FYX1BBVEhfUFJP
R19PUl9GQUlMKFtCSVNPTl0sIFtiaXNvbl0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbRkxFWF0s
IFtmbGV4XSkKK0FTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5Il0sIFsKKyAgICBBWF9QQVRIX1BS
T0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZB
SUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10pCitdKQorQVNfSUYoW3Rlc3QgIngkb2NhbWx0b29scyIg
PSAieHkiXSwgWworICAgIEFDX1BST0dfT0NBTUwKKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMi
ID0gInhubyJdLCBbCisgICAgICAgIEFTX0lGKFt0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9
ICJ4eWVzIl0sIFsKKyAgICAgICAgICAgIEFDX01TR19FUlJPUihbT2NhbWwgdG9vbHMgZW5hYmxl
ZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sXSldKQorICAgICAgICBvY2FtbHRvb2xzPSJuIgor
ICAgIF0pCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihb
dGVzdCAieCRweXRob250b29scyIgPSAieHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9O
IiB8IGdyZXAgLXEgIl4vIl0sIFsKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAg
IFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJd
LCBbUFlUSE9OPSJweXRob24iXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVk
LCBidXQgaXMgbm90IGFuIGFic29sdXRlIHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZB
SUwoW1BZVEhPTlBBVEhdLCBbJFBZVEhPTl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04o
WzJdLCBbM10pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9O
X0RFVkVMKCkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRd
KQorQVhfQ0hFQ0tfVURFVihbNTldKQorQVhfQ0hFQ0tfVVVJRAorUEtHX0NIRUNLX01PRFVMRVMo
Z2xpYiwgZ2xpYi0yLjApCisKKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitBWF9ERUZBVUxUX0xJQgor
CisjIENoZWNrcyBmb3IgbGlicmFyaWVzLgorQUNfQ0hFQ0tfTElCKFthaW9dLCBbaW9fc2V0dXBd
LCBbc3lzdGVtX2Fpbz0ieSJdLCBbc3lzdGVtX2Fpbz0ibiJdKQorQUNfU1VCU1Qoc3lzdGVtX2Fp
bykKK0FDX0NIRUNLX0xJQihbY3J5cHRvXSwgW01ENV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3Vs
ZCBub3QgZmluZCBsaWJjcnlwdG9dKV0pCitBQ19DSEVDS19MSUIoW2V4dDJmc10sIFtleHQyZnNf
b3BlbjJdLCBbbGliZXh0MmZzPSJ5Il0sIFtsaWJleHQyZnM9Im4iXSkKK0FDX1NVQlNUKGxpYmV4
dDJmcykKK0FDX0NIRUNLX0xJQihbZ2NyeXB0XSwgW2djcnlfbWRfaGFzaF9idWZmZXJdLCBbbGli
Z2NyeXB0PSJ5Il0sIFtsaWJnY3J5cHQ9Im4iXSkKK0FDX1NVQlNUKGxpYmdjcnlwdCkKK0FDX0NI
RUNLX0xJQihbcHRocmVhZF0sIFtwdGhyZWFkX2NyZWF0ZV0sIFtdICwKKyAgICBbQUNfTVNHX0VS
Uk9SKFtDb3VsZCBub3QgZmluZCBsaWJwdGhyZWFkXSldKQorQUNfQ0hFQ0tfTElCKFtydF0sIFtj
bG9ja19nZXR0aW1lXSkKK0FDX0NIRUNLX0xJQihbdXVpZF0sIFt1dWlkX2NsZWFyXSwgW10sCisg
ICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGlidXVpZF0pXSkKK0FDX0NIRUNLX0xJ
QihbeWFqbF0sIFt5YWpsX2FsbG9jXSwgW10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90
IGZpbmQgeWFqbF0pXSkKK0FDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNf
TVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQorQUNfQ0hFQ0tfTElCKFtpY29udl0s
IFtsaWJpY29udl9vcGVuXSwgW2xpYmljb252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQorQUNfU1VC
U1QobGliaWNvbnYpCisKKyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCitBQ19GVU5DX0FMTE9D
QQorQUNfQ0hFQ0tfSEVBREVSUyhbIFwKKyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250
bC5oIGludHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAg
ICAgICBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJp
bmcuaCBcCisgICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmgg
c3lzL21vdW50Lmggc3lzL3BhcmFtLmggXAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBz
eXMvc3RhdHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAg
ICAgICB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKyAgICAgICAgICAgICAgICBdKQor
CisjIENoZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0
ZXJpc3RpY3MuCitBQ19IRUFERVJfU1REQk9PTAorQUNfVFlQRV9VSURfVAorQUNfQ19JTkxJTkUK
K0FDX1RZUEVfSU5UMTZfVAorQUNfVFlQRV9JTlQzMl9UCitBQ19UWVBFX0lOVDY0X1QKK0FDX1RZ
UEVfSU5UOF9UCitBQ19UWVBFX01PREVfVAorQUNfVFlQRV9PRkZfVAorQUNfVFlQRV9QSURfVAor
QUNfQ19SRVNUUklDVAorQUNfVFlQRV9TSVpFX1QKK0FDX1RZUEVfU1NJWkVfVAorQUNfQ0hFQ0tf
TUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCitBQ19TVFJVQ1RfU1RfQkxPQ0tTCitB
Q19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9yZGV2XSkKK0FDX1RZUEVfVUlOVDE2X1QK
K0FDX1RZUEVfVUlOVDMyX1QKK0FDX1RZUEVfVUlOVDY0X1QKK0FDX1RZUEVfVUlOVDhfVAorQUNf
Q0hFQ0tfVFlQRVMoW3B0cmRpZmZfdF0pCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9u
cy4KK0FDX0ZVTkNfRVJST1JfQVRfTElORQorQUNfRlVOQ19GT1JLCitBQ19GVU5DX0ZTRUVLTwor
QUNfRlVOQ19MU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSworQUNfSEVBREVSX01BSk9SCitB
Q19GVU5DX01BTExPQworQUNfRlVOQ19NS1RJTUUKK0FDX0ZVTkNfTU1BUAorQUNfRlVOQ19SRUFM
TE9DCitBQ19GVU5DX1NUUk5MRU4KK0FDX0ZVTkNfU1RSVE9ECitBQ19DSEVDS19GVU5DUyhbIFwK
KyAgICAgICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZk
YXRhc3luYyBmdHJ1bmNhdGUgXAorICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1l
IGdldGhvc3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAg
aW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGly
IFwKKyAgICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2Nv
bXAgcm1kaXIgc2VsZWN0IHNldGVudiBcCisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2Vj
bXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAg
ICAgIHN0cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxs
IHR6c2V0IFwKKyAgICAgICAgICAgICAgICB1bmFtZSBcCisgICAgICAgICAgICAgICAgXSkKKwor
QUNfT1VUUFVUKCkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2Rl
YnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01h
a2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9kZWJ1Z2dl
ci9nZGJzeC94Zy9NYWtlZmlsZQlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTIx
LDcgKzIxLDYgQEAgeGdfYWxsLmE6ICQoWEdfT0JKUykgTWFrZWZpbGUgJChYR19IRFJTKQogIwkk
KENDKSAtbTMyIC1jIC1vICRAICReCiAKIHhlbi1oZWFkZXJzOgotCSQoTUFLRSkgLUMgLi4vLi4v
Li4vY2hlY2sgCiAJJChNQUtFKSAtQyAuLi8uLi8uLi9pbmNsdWRlCiAKICMgeGdfbWFpbi5vOiB4
Z19tYWluLmMgTWFrZWZpbGUgJChYR19IRFJTKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvaW5zdGFsbC5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9pbnN0YWxsLnNoCVR1ZSBGZWIgMjEgMDI6Mjk6MDYg
MjAxMiArMDEwMApAQCAtMCwwICsxLDEgQEAKKy4uL2luc3RhbGwuc2gKXCBObyBuZXdsaW5lIGF0
IGVuZCBvZiBmaWxlCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9s
aWJmc2ltYWdlL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJ
VHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0zLDcgKzMsMTEgQEAgaW5jbHVkZSAk
KFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNl
cmZzIGlzbzk2NjAgZmF0IHpmcwogU1VCRElSUy0kKENPTkZJR19YODYpICs9IHhmcwotU1VCRElS
Uy15ICs9ICQoc2hlbGwgZW52IENDPSIkKENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgk
KENPTkZJR19FWFQyRlMpLCB5KQorICAgIFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisg
ICAgU1VCRElSUy15ICs9IGV4dDJmcworZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFs
bAogYWxsIGNsZWFuIGluc3RhbGw6ICU6IHN1YmRpcnMtJQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAt
ciAzYmQ2YTdmOWQwN2QgdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9v
bHMvbGliZnNpbWFnZS9jaGVjay1saWJleHQyZnMJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIx
ICswLDAgQEAKLSMhL2Jpbi9zaAotCi1jYXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8
ZXh0MmZzL2V4dDJmcy5oPgotCi1pbnQgbWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9G
Ci0KLSR7Q0MtZ2NjfSAtbyBleHQyLXRlc3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVs
bCAyPiYxCi1pZiBbICQ/ID0gMCBdOyB0aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNo
byBleHQyZnMKLWZpCi0KLXJtIC1mIGV4dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlm
ZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQot
LS0gYS90b29scy9saWJ4ZW4vTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyBiL3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAx
MDAKQEAgLTIyLDEyICsyMiwxMiBAQCBNQUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyAr
PSAtSWluY2x1ZGUgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwy
LWNvbmZpZyAtLWNmbGFncykgXAotICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxh
Z3MpIFwKKyAgICAgICAgICAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAg
ICAgICAgJChzaGVsbCAkKENVUkxfQ09ORklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElD
CiAKLUxERkxBR1MgKz0gJChzaGVsbCB4bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAg
JChzaGVsbCBjdXJsLWNvbmZpZyAtLWxpYnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyX0NP
TkZJRykgLS1saWJzKSBcCisgICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1saWJz
KQogCiBMSUJYRU5BUElfSERSUyA9ICQod2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5j
bHVkZS94ZW4vYXBpL3hlbl9hbGwuaAogTElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywg
JS5vLCAkKHdpbGRjYXJkIHNyYy8qLmMpKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdm
OWQwN2QgdG9vbHMvbGlieGwvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCVR1
ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiArMDEwMApAQCAtMTksMTAgKzE5LDYgQEAgaWZlcSAoJChD
T05GSUdfTGludXgpLHkpCiBMSUJVVUlEX0xJQlMgKz0gLWx1dWlkCiBlbmRpZgogCi1pZmVxICgk
KENPTkZJR19ZQUpMX1ZFUlNJT04pLHkpCi1DRkxBR1MgKz0gLURIQVZFX1lBSkxfVkVSU0lPTgot
ZW5kaWYKLQogTElCWExfTElCUyA9CiBMSUJYTF9MSUJTID0gJChMRExJQlNfbGlieGVuY3RybCkg
JChMRExJQlNfbGlieGVuZ3Vlc3QpICQoTERMSUJTX2xpYnhlbnN0b3JlKSAkKExETElCU19saWJi
bGt0YXBjdGwpICQoVVRJTF9MSUJTKSAkKExJQlVVSURfTElCUykKIApAQCAtNTYsNyArNTIsNyBA
QCBMSUJYTF9PQkpTID0gZmxleGFycmF5Lm8gbGlieGwubyBsaWJ4bF9jCiAJCQlsaWJ4bF9xbXAu
byBsaWJ4bF9ldmVudC5vICQoTElCWExfT0JKUy15KQogTElCWExfT0JKUyArPSBfbGlieGxfdHlw
ZXMubyBsaWJ4bF9mbGFzay5vIF9saWJ4bF90eXBlc19pbnRlcm5hbC5vCiAKLSQoTElCWExfT0JK
Uyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkg
JChDRkxBR1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkKKyQoTElCWExfT0JK
Uyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkg
JChDRkxBR1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkgLWluY2x1ZGUgJChY
RU5fUk9PVCkvdG9vbHMvY29uZmlnLmgKIAogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhs
dV9jZmdfbC5oIF9saWJ4bF9saXN0LmgKIEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVf
Y2ZnX2wuYwpAQCAtNjksNiArNjUsNyBAQCBDTElFTlRTID0geGwgdGVzdGlkbAogWExfT0JKUyA9
IHhsLm8geGxfY21kaW1wbC5vIHhsX2NtZHRhYmxlLm8geGxfc3hwLm8KICQoWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAjIEZvciB4ZW50b29sbG9nLmgKICQoWExfT0JK
Uyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5saWdodCkKKyQoWExfT0JKUyk6IENGTEFHUyAr
PSAtaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9jb25maWcuaCAjIGxpYnhsX2pzb24uaCBuZWVk
cyBpdC4KIAogdGVzdGlkbC5vOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxB
R1NfbGlieGVubGlnaHQpCiB0ZXN0aWRsLmM6IGxpYnhsX3R5cGVzLmlkbCBnZW50ZXN0LnB5IGxp
YnhsLmggJChBVVRPSU5DUykKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRv
b2xzL2xpYnhsL2xpYnhsX2pzb24uaAotLS0gYS90b29scy9saWJ4bC9saWJ4bF9qc29uLmgJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24u
aAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTE4LDcgKzE4LDcgQEAKICNpbmNs
dWRlIDx5YWpsL3lhamxfZ2VuLmg+CiAjaW5jbHVkZSA8eWFqbC95YWpsX3BhcnNlLmg+CiAKLSNp
ZmRlZiBIQVZFX1lBSkxfVkVSU0lPTgorI2lmZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAog
IyAgaW5jbHVkZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4KICNlbmRpZgogCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0
X2xpYi5tNAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitB
Q19ERUZVTihbQVhfREVGQVVMVF9MSUJdLAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0
Il0sIFsKKyAgICBMSUJfUEFUSD0ibGliNjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkK
K0FDX1NVQlNUKExJQl9QQVRIKV0pCisKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3Zjlk
MDdkIHRvb2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJVHVl
IEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNf
SEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFi
bGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVf
JDEiID0gInh5ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQx
XSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L2VuYWJsZV9mZWF0
dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00CVR1ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiArMDEw
MApAQCAtMCwwICsxLDEzIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwK
K1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwg
WyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhf
Y3ZfJDE9InkiCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3Zf
JDE9Im4iCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQor
JDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvbTQvb2NhbWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvb2NhbWwubTQJVHVlIEZlYiAyMSAwMjoyOTow
NiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBP
Q2FtbAorZG5sIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5
cmlnaHQgwqkgMjAwOSAgICAgIFJpY2hhcmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAy
MDA5ICAgICAgU3RlZmFubyBaYWNjaGlyb2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBP
bGl2aWVyIEFuZHJpZXUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3Bo
ZSBGaWxsacOidHJlCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8K
K2RubAorZG5sIEZvciBkb2N1bWVudGF0aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFu
IHBhZ2UuCisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBm
b3Igb2NhbWxjCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBp
ZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1M
QyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19N
U0dfUkVTVUxUKFtPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9D
QU1MTElCIGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhl
bgorICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1M
QyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0df
UkVTVUxUKFtPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBm
aQorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkK
KworICAgICBBQ19TVUJTVChbT0NBTUxWRVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElC
XSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtP
Q0FNTE9QVF0sW29jYW1sb3B0XSxbbm9dKQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0
ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBv
Y2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVS
U0lPTj1gJE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8
cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJ
ICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0
IGRpc2NhcmRlZC5dKQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9w
dAorCWZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBj
aGVja2luZyBmb3Igb2NhbWxjLm9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRd
LFtvY2FtbGMub3B0XSxbbm9dKQorICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8i
OyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZl
cnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FN
TFZFUlNJT04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZy
b20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRP
Q0FNTENET1RPUFQKKwlmaQorICAgICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0
Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tf
VE9PTChbT0NBTUxPUFRET1RPUFRdLFtvY2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9D
QU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9U
T1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlm
IHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNf
TVNHX1JFU1VMVChbdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlz
Y2FyZGVkLl0pCisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAg
IGZpCisgICAgICAgIGZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAg
ZmkKKworICBBQ19TVUJTVChbT0NBTUxDXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3Bs
ZXZlbAorICBBQ19DSEVDS19UT09MKFtPQ0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZGVwCisgIEFDX0NIRUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtu
b10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FN
TE1LVE9QXSxbb2NhbWxta3RvcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGli
CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxk
b2NdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTEJVSUxEXSxbb2NhbWxidWlsZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BS
T0dfT0NBTUxMRVhdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVD
S19UT09MKFtPQ0FNTExFWF0sW29jYW1sbGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgi
ICE9ICJubyI7IHRoZW4KKyAgICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1s
bGV4Lm9wdF0sW25vXSkKKyAgICBpZiB0ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRo
ZW4KKwlPQ0FNTExFWD0kT0NBTUxMRVhET1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChb
T0NBTUxMRVhdKQorXSkKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAg
QUNfQ0hFQ0tfVE9PTChbT0NBTUxZQUNDXSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChb
T0NBTUxZQUNDXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0
CisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENB
TUxQNCIgIT0gIm5vIjsgdGhlbgorICAgICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNl
ZCAtbiAtZSAnc3wuKnZlcnNpb24gKlwoLipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBW
RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lv
bnMgZGlmZmVycyBmcm9tIG9jYW1sY10pCisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBm
aQorICBBQ19TVUJTVChbQ0FNTFA0XSkKKworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9v
bHMKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNE9dLFtjYW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtD
QU1MUDRPRl0sW2NhbWxwNG9mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtj
YW1scDRvb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0s
W25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisg
IEFDX0NIRUNLX1RPT0woW0NBTUxQNFJdLFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09M
KFtDQU1MUDRSRl0sW2NhbWxwNHJmXSxbbm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisg
IEFDX1NVQlNUKFtDQU1MUDRPXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1Qo
W0NBTUxQNE9PRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0
UFJPRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10p
CisKKworQUNfREVGVU4oW0FDX1BST0dfRklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FD
X1BST0dfT0NBTUxdKWRubAorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVD
S19UT09MKFtPQ0FNTEZJTkRdLFtvY2FtbGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJ
TkRdKQorXSkKKworCitkbmwgVGhhbmtzIHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlz
IG5leHQgYml0IG91dCBmb3IgdXMuCitkbmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0gg
aWYgaXQncyBub3QgZGVmaW5lZCBhbHJlYWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4K
K0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19Q
Uk9HX0ZJTkRMSUJdKWRubAorCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIg
cGFja2FnZSAkMV0pCisKKyAgdW5zZXQgZm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisg
IGZvciBwa2cgaW4gJDEgJDIgOyBkbworICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rl
di9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisg
ICAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAg
ICBicmVhaworICAgIGZpCisgIGRvbmUKKyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVu
CisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtH
XyQxXSk9bm8KKyAgZmkKKworICBBQ19TVUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitd
KQorCisKK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0df
Q0hFQ0tJTkcoW2ZvciBPQ2FtbCBtb2R1bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8
RU9GCitvcGVuICQzCitFT0YKKyAgdW5zZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRv
CisgICAgaWYgJE9DQU1MQyAtYyAtSSAiJCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4K
KyAgICAgIGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVz
dCAiJGZvdW5kIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAg
QUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChb
JDFdKQorXSkKKworCitkbmwgWFhYIENyb3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNL
X09DQU1MX1dPUkRfU0laRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRu
bAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBj
YXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5
cy53b3JkX3NpemUpCisgIEVPRgorICBPQ0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5t
bGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FN
TF9XT1JEX1NJWkVdKQorXSkKKworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAor
W2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5H
KFtPQ2FtbCBTeXMub3NfdHlwZV0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJp
bnRfc3RyaW5nKFN5cy5vc190eXBlKTs7CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwg
Y29uZnRlc3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VC
U1QoW09DQU1MX09TX1RZUEVdKQorXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3Zjlk
MDdkIHRvb2xzL200L3BhdGhfb3JfZmFpbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9wYXRoX29yX2ZhaWwubTQJVHVlIEZlYiAy
MSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhf
UFJPR19PUl9GQUlMXSwKK1tBQ19QQVRIX1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3Qg
eCIkeyQxfSIgPT0geCJubyIgCit0aGVuCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmlu
ZCAkMiwgcGxlYXNlIGluc3RhbGwgJDJdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAz
YmQ2YTdmOWQwN2QgdG9vbHMvbTQvcGtnLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3BrZy5tNAlUdWUgRmViIDIxIDAyOjI5OjA2
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxNTcgQEAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0
ZSBhbmQgdXRpbGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMg
c2VyaWFsIDEgKHBrZy1jb25maWctMC4yNCkKKyMgCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0
IEphbWVzIFJlbW5hbnQgPHNjb3R0QG5ldHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBp
cyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Cisj
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJz
aW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZl
cnNpb24uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0
IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVT
UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZl
ZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGgg
dGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5k
YXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjEx
MS0xMzA3LCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFy
dCBvZiBhIHByb2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdl
bmVyYXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1l
IGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJv
Z3JhbS4KKworIyBQS0dfUFJPR19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfUFJPR19QS0dfQ09ORklH
XSwKK1ttNF9wYXR0ZXJuX2ZvcmJpZChbXl8/UEtHX1tBLVpfXSskXSkKK200X3BhdHRlcm5fYWxs
b3coW15QS0dfQ09ORklHKF9QQVRIKT8kXSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUddLCBbcGF0
aCB0byBwa2ctY29uZmlnIHV0aWxpdHldKQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19QQVRIXSwg
W2RpcmVjdG9yaWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGhdKQorQUNfQVJH
X1ZBUihbUEtHX0NPTkZJR19MSUJESVJdLCBbcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBi
dWlsdC1pbiBzZWFyY2ggcGF0aF0pCisKK2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05GSUdf
c2V0IiAhPSAieHNldCI7IHRoZW4KKwlBQ19QQVRIX1RPT0woW1BLR19DT05GSUddLCBbcGtnLWNv
bmZpZ10pCitmaQoraWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisJX3BrZ19taW5fdmVy
c2lvbj1tNF9kZWZhdWx0KFskMV0sIFswLjkuMF0pCisJQUNfTVNHX0NIRUNLSU5HKFtwa2ctY29u
ZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb25dKQorCWlmICRQS0dfQ09O
RklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgor
CQlBQ19NU0dfUkVTVUxUKFt5ZXNdKQorCWVsc2UKKwkJQUNfTVNHX1JFU1VMVChbbm9dKQorCQlQ
S0dfQ09ORklHPSIiCisJZmkKK2ZpW11kbmwKK10pIyBQS0dfUFJPR19QS0dfQ09ORklHCisKKyMg
UEtHX0NIRUNLX0VYSVNUUyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1O
T1QtRk9VTkRdKQorIworIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9m
IG1vZHVsZXMgZXhpc3RzLiAgU2ltaWxhcgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQg
ZG9lcyBub3Qgc2V0IHZhcmlhYmxlcyBvciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1l
bWJlciB0aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisj
IG9ubHkgYXQgdGhlIGZpcnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBm
aXJzdCBwbGFjZQorIyBpdCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0
IGlzIHdpdGhpbiBhbiAiaWYiLCB5b3UKKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMg
bWFudWFsbHkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfRVhJU1RTXSwKK1tBQ19SRVFV
SVJFKFtQS0dfUFJPR19QS0dfQ09ORklHXSlkbmwKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAm
JiBcCisgICAgQUNfUlVOX0xPRyhbJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMg
IiQxIl0pOyB0aGVuCisgIG00X2RlZmF1bHQoWyQyXSwgWzpdKQorbTRfaWZ2YWxuKFskM10sIFtl
bHNlCisgICQzXSlkbmwKK2ZpXSkKKworIyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFO
RF0sIFtNT0RVTEVTXSkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCittNF9kZWZpbmUoW19QS0dfQ09ORklHXSwKK1tpZiB0ZXN0IC1uICIkJDEiOyB0aGVu
CisgICAgcGtnX2N2X1tdJDE9IiQkMSIKKyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhl
bgorICAgIFBLR19DSEVDS19FWElTVFMoWyQzXSwKKyAgICAgICAgICAgICAgICAgICAgIFtwa2df
Y3ZfW10kMT1gJFBLR19DT05GSUcgLS1bXSQyICIkMyIgMj4vZGV2L251bGxgXSwKKwkJICAgICBb
cGtnX2ZhaWxlZD15ZXNdKQorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2ZpW11kbmwK
K10pIyBfUEtHX0NPTkZJRworCisjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorQUNfREVGVU4oW19QS0dfU0hPUlRfRVJST1JTX1NV
UFBPUlRFRF0sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCitpZiAkUEtHX0NP
TkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtn
X3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJy
b3JzX3N1cHBvcnRlZD1ubworZmlbXWRubAorXSkjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRF
RAorCisKKyMgUEtHX0NIRUNLX01PRFVMRVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNU
SU9OLUlGLUZPVU5EXSwKKyMgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQorIworIworIyBOb3RlIHRo
YXQgaWYgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bworIyBQS0dfQ0hF
Q0tfTU9EVUxFUyBtaWdodCBub3QgaGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVk
ZSBhbgorIyBleHBsaWNpdCBjYWxsIHRvIFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25m
aWd1cmUuYWMKKyMKKyMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfTU9EVUxFU10sCitb
QUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0NG
TEFHU10sIFtDIGNvbXBpbGVyIGZsYWdzIGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlk
bmwKK0FDX0FSR19WQVIoWyQxXVtfTElCU10sIFtsaW5rZXIgZmxhZ3MgZm9yICQxLCBvdmVycmlk
aW5nIHBrZy1jb25maWddKWRubAorCitwa2dfZmFpbGVkPW5vCitBQ19NU0dfQ0hFQ0tJTkcoW2Zv
ciAkMV0pCisKK19QS0dfQ09ORklHKFskMV1bX0NGTEFHU10sIFtjZmxhZ3NdLCBbJDJdKQorX1BL
R19DT05GSUcoWyQxXVtfTElCU10sIFtsaWJzXSwgWyQyXSkKKworbTRfZGVmaW5lKFtfUEtHX1RF
WFRdLCBbQWx0ZXJuYXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxl
cyAkMVtdX0NGTEFHUworYW5kICQxW11fTElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBjYWxsIHBr
Zy1jb25maWcuCitTZWUgdGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy5d
KQorCitpZiB0ZXN0ICRwa2dfZmFpbGVkID0geWVzOyB0aGVuCisgICAJQUNfTVNHX1JFU1VMVChb
bm9dKQorICAgICAgICBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKKyAgICAgICAgaWYgdGVz
dCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICAkMVtd
X1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICIk
MiIgMj4mMWAKKyAgICAgICAgZWxzZSAKKwkgICAgICAgICQxW11fUEtHX0VSUk9SUz1gJFBLR19D
T05GSUcgLS1wcmludC1lcnJvcnMgIiQyIiAyPiYxYAorICAgICAgICBmaQorCSMgUHV0IHRoZSBu
YXN0eSBlcnJvciBtZXNzYWdlIGluIGNvbmZpZy5sb2cgd2hlcmUgaXQgYmVsb25ncworCWVjaG8g
IiQkMVtdX1BLR19FUlJPUlMiID4mQVNfTUVTU0FHRV9MT0dfRkQKKworCW00X2RlZmF1bHQoWyQ0
XSwgW0FDX01TR19FUlJPUigKK1tQYWNrYWdlIHJlcXVpcmVtZW50cyAoJDIpIHdlcmUgbm90IG1l
dDoKKworJCQxX1BLR19FUlJPUlMKKworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklH
X1BBVEggZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4g
YSBub24tc3RhbmRhcmQgcHJlZml4LgorCitfUEtHX1RFWFRdKWRubAorICAgICAgICBdKQorZWxp
ZiB0ZXN0ICRwa2dfZmFpbGVkID0gdW50cmllZDsgdGhlbgorICAgICAJQUNfTVNHX1JFU1VMVChb
bm9dKQorCW00X2RlZmF1bHQoWyQ0XSwgW0FDX01TR19GQUlMVVJFKAorW1RoZSBwa2ctY29uZmln
IHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAor
aXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJs
ZSB0byB0aGUgZnVsbAorcGF0aCB0byBwa2ctY29uZmlnLgorCitfUEtHX1RFWFQKKworVG8gZ2V0
IHBrZy1jb25maWcsIHNlZSA8aHR0cDovL3BrZy1jb25maWcuZnJlZWRlc2t0b3Aub3JnLz4uXSlk
bmwKKyAgICAgICAgXSkKK2Vsc2UKKwkkMVtdX0NGTEFHUz0kcGtnX2N2X1tdJDFbXV9DRkxBR1MK
KwkkMVtdX0xJQlM9JHBrZ19jdl9bXSQxW11fTElCUworICAgICAgICBBQ19NU0dfUkVTVUxUKFt5
ZXNdKQorCSQzCitmaVtdZG5sCitdKSMgUEtHX0NIRUNLX01PRFVMRVMKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L3B5dGhvbl9kZXZlbC5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25f
ZGV2ZWwubTQJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTggQEAK
K0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fREVWRUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9y
IHB5dGhvbiBkZXZlbF0pCisKK2AkUFlUSE9OIC1jICcKK2ltcG9ydCBvcy5wYXRoLCBzeXMKK2Zv
ciBwIGluIHN5cy5wYXRoOgorICAgIGlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtl
ZmlsZSIpOgorICAgICAgICBzeXMuZXhpdCgwKQorc3lzLmV4aXQoMSkKKycgPiAvZGV2L251bGwg
Mj4mMWAKKworaWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25v
XSkKKyAgICBBQ19NU0dfRVJST1IoW1B5dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZF0pCitl
bHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl92ZXJz
aW9uLm00CVR1ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiArMDEwMApAQCAtMCwwICsxLDEyIEBACitB
Q19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT05dLAorW0FDX01TR19DSEVDS0lORyhbZm9y
IHB5dGhvbiB2ZXJzaW9uID49ICQxLiQyIF0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgZXhp
dChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKCQxLCAkMikiKSknYAoraWYgdGVzdCAiJD8iICE9
ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFgCisgICAgQUNf
TVNHX1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUigKKyAgICAgICAgWyRweXRob25fdmVy
c2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgJDEuJDJdKQorZWxz
ZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IDNiZDZhN2Y5ZDA3ZCB0b29scy9tNC9weXRob25feG1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl94bWwubTQJVHVl
IEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtB
WF9DSEVDS19QWVRIT05fWE1MXSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24geG1sLmRv
bS5taW5pZG9tXSkKK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRl
c3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNH
X0VSUk9SKFtVbmFibGUgdG8gZmluZCB4bWwuZG9tLm1pbmlkb20gbW9kdWxlXSkKK2Vsc2UKKyAg
ICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvbTQvc2V0X2NmbGFnc19sZGZsYWdzLm00Ci0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3NldF9jZmxhZ3NfbGRm
bGFncy5tNAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyMCBAQAor
QUNfREVGVU4oW0FYX1NFVF9GTEFHU10sCitbZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVT
CitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2Rv
bmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1Mr
PSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQ
UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdT
ICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZM
QUdTICRBUFBFTkRfTERGTEFHUyJdKQorCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5
ZDA3ZCB0b29scy9tNC91ZGV2Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL3Rvb2xzL200L3VkZXYubTQJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMzIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0
ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgIEFDX1BBVEhfUFJPRyhb
VURFVkFETV0sIFt1ZGV2YWRtXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0g
eCJubyIgCisgICAgdGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW1VERVZJTkZPXSwgW3VkZXZp
bmZvXSwgW25vXSkKKyAgICAgICAgaWYgdGVzdCB4IiR7VURFVklORk99IiA9PSB4Im5vIgorICAg
ICAgICB0aGVuCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoCisgICAgICAgICAgICAgICAgW1Vu
YWJsZSB0byBmaW5kIHVkZXZhZG0gb3IgdWRldmluZm8sIHBsZWFzZSBpbnN0YWxsIHVkZXZdKQor
ICAgICAgICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50
ICRORn0nYAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwg
YXdrICd7cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5
CisgICAgdGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW0hPVFBMVUddLCBbaG90cGx1Z10sIFtu
b10pCisgICAgICAgIGlmIHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVu
CisgICAgICAgICAgICBBQ19NU0dfRVJST1IoW3VkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2
ZXJzaW9uIDU5IG9yIGxhdGVyXSkKKyAgICAgICAgZmkKKyAgICBmaQorZWxzZQorICAgIEFDX1BB
VEhfUFJPRyhbVk5DT05GSUddLCBbdm5jb25maWddLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1ZO
Q09ORklHfSIgPT0geCJubyIKKyAgICB0aGVuCisgICAgICAgIEFDX01TR19FUlJPUihbTm90IGEg
TGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmRdKQorICAgIGZpCitmaQorXSkKZGlm
ZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L3V1aWQubTQKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdXVp
ZC5tNAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNf
REVGVU4oW0FYX0NIRUNLX1VVSURdLAorW2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1n
bnUiCit0aGVuCisgICAgQUNfQ0hFQ0tfSEVBREVSKFt1dWlkL3V1aWQuaF0sLAorCSAgICBbQUNf
TVNHX0VSUk9SKFtjYW5ub3QgZmluZCB1dWlkIGhlYWRlcnNdKV0pCitlbHNlCisgICAgQUNfQ0hF
Q0tfSEVBREVSKFt1dWlkLmhdLCwKKwkgICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVp
ZCBoZWFkZXJzXSldKQorZmkKK10pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3
ZCB2ZXJzaW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3ZlcnNpb24uc2gJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAg
KzEsNSBAQAorIyEvYmluL3NoCisKK01BSk9SPWBncmVwICJleHBvcnQgWEVOX1ZFUlNJT04iICQx
IHwgc2VkICdzLy4qPS8vZycgfCB0ciAtcyAiICJgCitNSU5PUj1gZ3JlcCAiZXhwb3J0IFhFTl9T
VUJWRVJTSU9OIiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorcHJpbnRmICIlZC4l
ZCIgJE1BSk9SICRNSU5PUgo=

--===============3706650461757472180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3706650461757472180==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 12:32:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzot2-0007eV-Me; Tue, 21 Feb 2012 12:32:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzot0-0007eC-Hw
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:32:03 +0000
Received: from [85.158.139.83:18016] by server-11.bemta-5.messagelabs.com id
	60/E5-14397-1CE834F4; Tue, 21 Feb 2012 12:32:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329827518!15118221!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11209 invoked from network); 21 Feb 2012 12:31:58 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:31:58 -0000
Received: by werh12 with SMTP id h12so4995801wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:31:58 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.227 as permitted sender) client-ip=10.180.92.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.227 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.227])
	by 10.180.92.227 with SMTP id cp3mr25502817wib.13.1329827518079
	(num_hops = 1); Tue, 21 Feb 2012 04:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=YoeFB7z2+iUGxDd5CW3hoFqYSOqYLR/gdfG5HmWQ/oU=;
	b=DrmGy4hW4y7eOBOldPr9HvnX38sSbQws94lMfifmd2MP9hvO12x5PF1YKHP/2DAjmB
	5SqwdzFmq0qzZC9cLApIc4rHuLmX7pXnKBum/EOBeuMiovA6ffBKWRKaod2hFYLwoDaA
	SzZhPIS+fpgQGuyHZBpqgx4hbqSZ81axhEykM=
Received: by 10.180.92.227 with SMTP id cp3mr21232612wib.13.1329827517972;
	Tue, 21 Feb 2012 04:31:57 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54885159wib.10.2012.02.21.04.31.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 04:31:57 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============3706650461757472180=="
MIME-Version: 1.0
X-Mercurial-Node: 3bd6a7f9d07d888f40967ef739d393f805fcbfea
Message-Id: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 02:35:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH v7] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3706650461757472180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v6:

 * Readded autogen.sh.

Changes since v5:

 * Remove dummy configure generation from autogen.sh since it's
   already on the source tree.

 * Removed autogen.sh since it was only a wrapper for calling
   autoconf.

 * Remove comment regarding yajl_version.h from configure.ac.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    2 -
 README                            |    4 +
 autogen.sh                        |    3 +
 config/Tools.mk.in                |   50 +++++++
 configure                         |    2 +
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  192 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 55 files changed, 839 insertions(+), 511 deletions(-)



--===============3706650461757472180==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzg3NzQ2IC0zNjAwCiMgTm9kZSBJRCAzYmQ2YTdmOWQw
N2Q4ODhmNDA5NjdlZjczOWQzOTNmODA1ZmNiZmVhCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY2OgoKICogUmVhZGRlZCBh
dXRvZ2VuLnNoLgoKQ2hhbmdlcyBzaW5jZSB2NToKCiAqIFJlbW92ZSBkdW1teSBjb25maWd1cmUg
Z2VuZXJhdGlvbiBmcm9tIGF1dG9nZW4uc2ggc2luY2UgaXQncwogICBhbHJlYWR5IG9uIHRoZSBz
b3VyY2UgdHJlZS4KCiAqIFJlbW92ZWQgYXV0b2dlbi5zaCBzaW5jZSBpdCB3YXMgb25seSBhIHdy
YXBwZXIgZm9yIGNhbGxpbmcKICAgYXV0b2NvbmYuCgogKiBSZW1vdmUgY29tbWVudCByZWdhcmRp
bmcgeWFqbF92ZXJzaW9uLmggZnJvbSBjb25maWd1cmUuYWMuCgpDaGFuZ2VzIHNpbmNlIHY0OgoK
ICogVXBkYXRlZCB0byB0aXAuCgogKiBJbmNsdWRlIGNvbmZpZy5oIGZyb20gY29tcGlsZXIgY29t
bWFuZCBsaW5lIHdoZW4gYnVpbGRpbmcgbGlieGwgYW5kCiAgIHhsIHRvIGFzc3VyZSB5YWpsX3Zl
cnNpb24uaCBwcmVzZW5jZSBhbmQgY29ycmVjdGx5IGRldGVjdCB5YWpsCiAgIHZlcnNpb24uCgog
KiBBZGRlZCBnbGliLTIuMCBjaGVjayB3aXRoIGFwcHJvcGlhdGUgbTQgbWFjcm9zLgoKICogUHVy
Z2VkIGNvbmZpZy5oLmluIGZyb20gdW5uZWNlc3NhcnkgZGVmaW5lcyB0aGF0IGNvdWxkIG1lc3Mg
d2l0aAogICB0aGUgYnVpbGQgc3lzdGVtLgoKICogUmVtb3ZlZCB0b29scy9jb25maWcuc3ViLCB0
b29scy9jb25maWcuZ3Vlc3MsIHRvb2xzL2NvbmZpZ3VyZSBhbmQKICAgY29uZmlndXJlIHRvIG1h
a2UgdGhlIHBhdGNoIGZpdCBtYWlsaW5nIGxpc3QgbGltaXQuCgpDaGFuZ2VzIHNpbmNlIHYzOgoK
ICogQ29waWVkIGNvbmZpZy5ndWVzcyBhbmQgY29uZmlnLnN1YiBmcm9tIGF1dG9tYWtlIDEuMTEu
CgogKiBBZGRlZCBhIHRlc3QgdG8gY2hlY2sgZm9yIHV1aWQuaCBvbiBCU0QgYW5kIHV1aWQvdXVp
ZC5oIG9uIExpbnV4LgoKQ2hhbmdlcyBzaW5jZSB2MjoKCiAqIENoYW5nZWQgb3JkZXIgb2YgY29u
ZmlnL1Rvb2xzLm1rIGluY2x1ZGUuCgogKiBBZGRlZCAiLWUiIHRvIGF1dG9nZW4uc2ggc2hlYmFu
Zy4KCiAqIEFkZGVkIG5lY2Vzc2FyeSBmaWxlcyAoY29uZmlnLiopIGFuZCBvdXRwdXQgZnJvbSBB
dXRvaGVhZGVyIGFuZAogICBBdXRvY29uZi4KCiAqIFJlbW92ZWQgQXV0b2NvbmYgZnJvbSBidWls
ZCBkZXBlbmRlbmNpZXMgYW5kIHVwZGF0ZWQgUkVBRE1FLgoKQ2hhbmdlcyBzaW5jZSB2MToKCiAq
IE1vdmVkIGF1dG9jb25mIHN0dWZmIGluc2lkZSB0b29scyBmb2xkZXIuCgogKiBBZGQgTWFrZWZp
bGUgcnVsZXMgZm9yIGNsZWFuaW5nLgoKICogUmVtb3ZlZCBBdXRvbWFrZSBkZXBlbmRlbmN5LgoK
ICogQ3JlYXRlIGF1dG9nZW4uc2ggdG8gYXV0b21hdGljYWxseSBjcmVhdGUgY29uZmlndXJlIHNj
cmlwdCB3aGVuCiAgIGJ1aWxkaW5nIGZyb20gc291cmNlIHJlcG9zaXRvcnkuCgogKiBDYWNoZWQg
dmFsdWVzIG9mIG9wdGlvbnMgcGFzc2VkIGZyb20gY29tbWFuZCBsaW5lLgoKICogQWRkIG5lY2Vz
c2FyeSBpZ25vcmVzIHRvIC5oZ2lnbm9yZS4KCiAqIEFkZGVkIEF1dG9jb25mIHRvIHRoZSBsaXN0
IG9mIGRlcGVuZGVuY2llcy4KCiAqIENoYW5nZWQgaHlwZW4gdG8gdW5kZXJzY29yZSBpbiBYTUwy
IGFuZCBDVVJMIHZhcmlhYmxlIG5hbWVzLgoKICogQWRkZWQgc2NyaXB0IHRvIGdldCB2ZXJzaW9u
IGZyb20geGVuL01ha2VmaWxlLgoKICogU2V0IE9jYW1sIHRvb2xzIHRvIG9wdGlvbmFsLgoKICog
QWRkZWQgcHJvY2VkZW5jZSBvZiBtNC9vY2FtbC5tNC4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBh
dSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAt
ciAzYmQ2YTdmOWQwN2QgLmhnaWdub3JlCi0tLSBhLy5oZ2lnbm9yZQlNb24gRmViIDIwIDE4OjM0
OjE0IDIwMTIgKzAwMDAKKysrIGIvLmhnaWdub3JlCVR1ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiAr
MDEwMApAQCAtMzAzLDYgKzMwMywxMiBAQAogXnRvb2xzL29jYW1sL2xpYnMveGwveGVubGlnaHRc
Lm1sJAogXnRvb2xzL29jYW1sL2xpYnMveGwveGVubGlnaHRcLm1saSQKIF50b29scy9vY2FtbC94
ZW5zdG9yZWQvb3hlbnN0b3JlZCQKK150b29scy9hdXRvbTR0ZVwuY2FjaGUkCitedG9vbHMvY29u
ZmlnXC5oJAorXnRvb2xzL2NvbmZpZ1wubG9nJAorXnRvb2xzL2NvbmZpZ1wuc3RhdHVzJAorXnRv
b2xzL2NvbmZpZ1wuY2FjaGUkCiteY29uZmlnL1Rvb2xzXC5tayQKIF54ZW4vXC5iYW5uZXIuKiQK
IF54ZW4vQkxPRyQKIF54ZW4vU3lzdGVtLm1hcCQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2Jk
NmE3ZjlkMDdkIENvbmZpZy5tawotLS0gYS9Db25maWcubWsJTW9uIEZlYiAyMCAxODozNDoxNCAy
MDEyICswMDAwCisrKyBiL0NvbmZpZy5tawlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAK
QEAgLTcwLDkgKzcwLDYgQEAgRVhUUkFfSU5DTFVERVMgKz0gJChFWFRSQV9QUkVGSVgpL2luY2x1
ZAogRVhUUkFfTElCICs9ICQoRVhUUkFfUFJFRklYKS8kKExJQkxFQUZESVIpCiBlbmRpZgogCi1C
SVNPTgk/PSBiaXNvbgotRkxFWAk/PSBmbGV4Ci0KIFBZVEhPTiAgICAgID89IHB5dGhvbgogUFlU
SE9OX1BSRUZJWF9BUkcgPz0gLS1wcmVmaXg9IiQoUFJFRklYKSIKICMgVGhlIGFib3ZlIHJlcXVp
cmVzIHRoYXQgUFJFRklYIGNvbnRhaW5zICpubyBzcGFjZXMqLiBUaGlzIHZhcmlhYmxlIGlzIGhl
cmUKQEAgLTE3NSwzMiArMTcyLDkgQEAgQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKFBSRVBFTkRf
SU5DTFVERQogQVBQRU5EX0xERkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0xJQiksIC1M
JChpKSkKIEFQUEVORF9DRkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0lOQ0xVREVTKSwg
LUkkKGkpKQogCi1DSEVDS19MSUIgPSAkKEVYVFJBX0xJQikgJChQUkVQRU5EX0xJQikgJChBUFBF
TkRfTElCKQotQ0hFQ0tfSU5DTFVERVMgPSAkKEVYVFJBX0lOQ0xVREVTKSAkKFBSRVBFTkRfSU5D
TFVERVMpICQoQVBQRU5EX0lOQ0xVREVTKQotCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgOj0gLW5v
cGllIC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tc3RhY2stcHJvdGVjdG9yLWFsbAogRU1CRURE
RURfRVhUUkFfQ0ZMQUdTICs9IC1mbm8tZXhjZXB0aW9ucwogCi1DT05GSUdfTElCSUNPTlYgICA6
PSAkKHNoZWxsIGV4cG9ydCBPUz0iYHVuYW1lIC1zYCI7IFwKLSAgICAgICAgICAgICAgICAgICAg
ICAgZXhwb3J0IENIRUNLX0xJQj0iJChDSEVDS19MSUIpIjsgXAotICAgICAgICAgICAgICAgICAg
ICAgICAuICQoWEVOX1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNoOyBcCi0gICAgICAgICAgICAg
ICAgICAgICAgIGhhc19saWIgbGliaWNvbnYuc28gJiYgZWNobyAneScgfHwgZWNobyAnbicpCi0K
LUNPTkZJR19ZQUpMX1ZFUlNJT04gOj0gJChzaGVsbCBleHBvcnQgT1M9ImB1bmFtZSAtc2AiOyBc
Ci0gICAgICAgICAgICAgICAgICAgICAgIGV4cG9ydCBDSEVDS19JTkNMVURFUz0iJChDSEVDS19J
TkNMVURFUykiOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIC4gJChYRU5fUk9PVCkvdG9vbHMv
Y2hlY2svZnVuY3Muc2g7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgaGFzX2hlYWRlciB5YWps
L3lhamxfdmVyc2lvbi5oICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi0jIEVuYWJsZSBYU00g
c2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCi1YU01fRU5BQkxFID89IG4KLUZM
QVNLX0VOQUJMRSA/PSAkKFhTTV9FTkFCTEUpCi0KLSMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmll
cyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJvdG9jb2w/Ci0jIEdJVCdzIHByb3RvY29sIGlzIGZh
c3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKLSMg
bWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJl
cG9zaXRvcnkgZG93bmxvYWRzCi0jIGZhaWwgb3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hU
VFA9eSBpbiB5b3VyIGVudmlyb25tZW50LgotR0lUX0hUVFAgPz0gbgotCiBYRU5fRVhURklMRVNf
VVJMPWh0dHA6Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzCiAjIEFsbCB0aGUg
ZmlsZXMgYXQgdGhhdCBsb2NhdGlvbiB3ZXJlIGRvd25sb2FkZWQgZnJvbSBlbHNld2hlcmUgb24K
ICMgdGhlIGludGVybmV0LiAgVGhlIG9yaWdpbmFsIGRvd25sb2FkIFVSTCBpcyBwcmVzZXJ2ZWQg
YXMgYSBjb21tZW50CkBAIC0yMzksMTcgKzIxMyw0IEBAIFFFTVVfVEFHID89IDEyOGRlMjU0OWM1
ZjI0ZTRhNDM3Yjg2YmQyZTQKICMgU2hvcnQgYW5zd2VyIC0tIGRvIG5vdCBlbmFibGUgdGhpcyB1
bmxlc3MgeW91IGtub3cgd2hhdCB5b3UgYXJlCiAjIGRvaW5nIGFuZCBhcmUgcHJlcGFyZWQgZm9y
IHNvbWUgcGFpbi4KIAotIyBPcHRpb25hbCBjb21wb25lbnRzCi1YRU5TVEFUX1hFTlRPUCAgICAg
Pz0geQotVlRQTV9UT09MUyAgICAgICAgID89IG4KLUxJQlhFTkFQSV9CSU5ESU5HUyA/PSBuCi1Q
WVRIT05fVE9PTFMgICAgICAgPz0geQotT0NBTUxfVE9PTFMgICAgICAgID89IHkKLUNPTkZJR19N
SU5JVEVSTSAgICA/PSBuCi1DT05GSUdfTE9NT1VOVCAgICAgPz0gbgotQ09ORklHX1NZU1RFTV9M
SUJBSU8gPz0geQogQ09ORklHX1RFU1RTICAgICAgID89IHkKLQotaWZlcSAoJChPQ0FNTF9UT09M
UykseSkKLU9DQU1MX1RPT0xTIDo9ICQoc2hlbGwgb2NhbWxvcHQgLXYgPiAvZGV2L251bGwgMj4m
MSAmJiBlY2hvICJ5IiB8fCBlY2hvICJuIikKLWVuZGlmCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IDNiZDZhN2Y5ZDA3ZCBNYWtlZmlsZQotLS0gYS9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0
IDIwMTIgKzAwMDAKKysrIGIvTWFrZWZpbGUJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAw
CkBAIC00MCwxMSArNDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlz
dDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRpc3QtZG9j
cyBkaXN0LW1pc2MKIAogZGlzdC1taXNjOgotCSQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hl
Y2sKIAkkKElOU1RBTExfREFUQSkgLi9DT1BZSU5HICQoRElTVERJUikKIAkkKElOU1RBTExfREFU
QSkgLi9SRUFETUUgJChESVNURElSKQogCSQoSU5TVEFMTF9QUk9HKSAuL2luc3RhbGwuc2ggJChE
SVNURElSKQotCSQoSU5TVEFMTF9QUk9HKSB0b29scy9jaGVjay9jaGsgdG9vbHMvY2hlY2svY2hl
Y2tfKiB0b29scy9jaGVjay9mdW5jcy5zaCAkKERJU1RESVIpL2NoZWNrCiBkaXN0LSU6IERFU1RE
SVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0LSU6IGluc3RhbGwtJQogCUA6ICMgZG8gbm90aGlu
ZwpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgUkVBRE1FCi0tLSBhL1JFQURN
RQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIGIvUkVBRE1FCVR1ZSBGZWIgMjEg
MDI6Mjk6MDYgMjAxMiArMDEwMApAQCAtODksOSArODksMTMgQEAgMi4gY2QgdG8geGVuLXVuc3Rh
YmxlIChvciB3aGF0ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5IGZpcnN0IGJ1aWxkLCBvciBp
ZiB5b3Ugd2FudCB0byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAgcGVyZm9ybSB0aGUgZm9sbG93
aW5nIHN0ZXBzOgogCisgICAgIyAuL2NvbmZpZ3VyZQogICAgICMgbWFrZSB3b3JsZAogICAgICMg
bWFrZSBpbnN0YWxsCiAKKyAgIElmIHlvdSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAt
LWhlbHAgdG8gc2VlIHRoZSBsaXN0IG9mCisgICBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25zIHdo
ZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxpbmcgWGVuLgorCiAgICBUaGlzIHdpbGwgY3JlYXRlIGFu
ZCBpbnN0YWxsIG9udG8gdGhlIGxvY2FsIG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQKICAgIHRoZSB4
ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgogCmRp
ZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCBhdXRvZ2VuLnNoCi0tLSAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL2F1dG9nZW4uc2gJVHVlIEZl
YiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMyBAQAorIyEvYmluL3NoIC1lCitj
ZCB0b29scworYXV0b2NvbmYKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIGNv
bmZpZy9Ub29scy5tay5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9jb25maWcvVG9vbHMubWsuaW4JVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsNTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklY
ICAgICAgICAgICAgICA6PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BB
VEhACisKKyMgQSBkZWJ1ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0g
QGRlYnVnQAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAor
RkxFWCAgICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZ
VEhPTkAKK1BZVEhPTl9QQVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAg
ICAgICAgIDo9IEBQRVJMQAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAg
ICAgICAgICAgICAgIDo9IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwy
X0NPTkZJRyAgICAgICAgIDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAor
WEdFVFRURVhUICAgICAgICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBs
aWJzL2luY2x1ZGVzCitQUkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAor
UFJFUEVORF9MSUIgICAgICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAg
IDo9IEBBUFBFTkRfSU5DTFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElC
QAorCisjIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitY
U01fRU5BQkxFICAgICAgICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21A
CisKKyMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJv
dG9jb2w/CisjIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4g
aXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0
aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwg
b3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50Lgor
R0lUX0hUVFAgICAgICAgICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRz
CitYRU5TVEFUX1hFTlRPUCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAg
Oj0gQHZ0cG1ACitMSUJYRU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAg
ICAgICA6PSBAcHl0aG9udG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xz
QAorQ09ORklHX01JTklURVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAg
IDo9IEBsb21vdW50QAorCisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0g
QHN5c3RlbV9haW9ACitDT05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19H
Q1JZUFQgICAgICAgOj0gQGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4
dDJmc0AKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIGNvbmZpZ3VyZQotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJ
VHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3No
IC1lCitjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAz
YmQ2YTdmOWQwN2QgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJTW9uIEZlYiAy
MCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDI6
Mjk6MDYgMjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlv
CiBlbmRpZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9
IGluY2x1ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2
ICs3OCw4IEBAIGNsZWFuOiBzdWJkaXJzLWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNs
ZWFuCiAJcm0gLXJmIHFlbXUteGVuLXRyYWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25h
bC1kaXItcmVtb3RlCiAJcm0gLXJmIHFlbXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJ
cm0gLXJmIC4uL2NvbmZpZy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0
dXMgXAorCQljb25maWcuY2FjaGUgYXV0b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJ
TEVfQVJDSCksJChYRU5fVEFSR0VUX0FSQ0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0t
Y3B1PSQoWEVOX1RBUkdFVF9BUkNIKSBcCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5
ZDA3ZCB0b29scy9SdWxlcy5tawotLS0gYS90b29scy9SdWxlcy5tawlNb24gRmViIDIwIDE4OjM0
OjE0IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvUnVsZXMubWsJVHVlIEZlYiAyMSAwMjoyOTowNiAy
MDEyICswMTAwCkBAIC00LDYgKzQsNyBAQAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0Nv
bmZpZy5taworaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9J
TlNUQUxMIDo9ICQoSU5TVEFMTCkKIElOU1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1p
bnN0YWxsCkBAIC04MCw4ICs4MSw2IEBAIGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2Mt
dmVyLWNoZWMKICAgICAgICAgICAgICAgICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3Qg
Z2NjLTMuNCIpCiAkKGV2YWwgJChjaGVjay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwg
d2hpY2ggJChQWVRIT04pKQotUFlUSE9OX1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxM
X1BZVEhPTl9QUk9HID0gXAogCSQoWEVOX1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAg
IiQoUFlUSE9OX1BBVEgpIiAkKElOU1RBTExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1
YmRpci1hbGwtJSBzdWJkaXItY2xlYW4tJSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVh
bi0lOiAucGhvbnkKIAkkKE1BS0UpIC1DICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9U
b29scy5tazoKKwlAZWNobyAiWW91IGhhdmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWls
ZGluZyBvciBpbnN0YWxsaW5nIHRoZSB0b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90
b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIGIvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVHVlIEZlYiAyMSAwMjoyOTow
NiAyMDEyICswMTAwCkBAIC0xMyw3ICsxMyw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhl
bnN0b3JlKQogQ0ZMQUdTICAgKz0gLUkgJChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05V
X1NPVVJDRQogCi1pZmVxICgkKHNoZWxsIC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lm
ZXEgKCRDT05GSUdfR0NSWVBULHkpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIg
Oj0gLWxnY3J5cHQKIGVsc2UKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRv
b2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVy
cy9jaGVja19nY3J5cHQJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jp
bi9zaAotCi1jYXQgPiAuZ2NyeXB0LmMgPDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQg
bWFpbih2b2lkKSB7IHJldHVybiAwOyB9Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0
LmMgLWxnY3J5cHQgMj4vZGV2L251bGwgOyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNo
byAibm8iCi1maQotCi1ybSAtZiAuZ2NyeXB0KgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvY2hlY2svTWFrZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIp
Ly4uLy4uCi1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRo
ZSBuZWNlc3NhcnkgZW52aXJvbm1lbnQgdmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQ
WVRIT04KLWV4cG9ydCBMSUJYRU5BUElfQklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwot
ZXhwb3J0IENIRUNLX0xJQgotZXhwb3J0IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTog
YWxsIGluc3RhbGwKLWFsbCBpbnN0YWxsOiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFj
aGluZSBpcyBPSyBmb3IgYnVpbGRpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1i
dWlsZDoKLQkuL2NoayBidWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5z
dGFsbGluZyBvbi4KLS5QSE9OWTogY2hlY2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2No
ayBpbnN0YWxsCi0KLS5QSE9OWTogY2xlYW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9v
bHMvY2hlY2svUkVBRE1FCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVj
a3MgZm9yIHRoZSBzdWl0YWJpbGl0eSBvZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0
YWxsLgotVG8gY2hlY2sgZm9yIGJ1aWxkIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hr
IGJ1aWxkCi0KLVRvIGNoZWNrIGZvciBpbnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAg
IC4vY2hrIGluc3RhbGwKLQotVGhlIGNoayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMg
ZGlyZWN0b3J5IGFuZCBwcmludAotdGhlIG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3Ro
aW5nIGlmIGNoZWNrcyBzdWNjZWVkLgotVGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1
Y2Nlc3MgYW5kIDEgb24gZmFpbHVyZS4KLQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxl
IGZpbGVzIGluIHRoaXMgZGlyZWN0b3J5IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18n
LiBGaWxlcyBjb250YWluaW5nIENIRUNLLUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hl
Y2ssIGFuZCBmaWxlcyBjb250YWluaW5nIENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBp
bnN0YWxsIGNoZWNrLgotCi1EZXRhaWxlZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBp
cyBpbiAuY2hrYnVpbGQgZm9yIGJ1aWxkCi1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwg
Tm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdm
OWQwN2QgdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJj
dGwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8
RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBicmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwg
YnJjdGwgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfY3J5cHRvX2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEg
KzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1
bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7
OwotZXNhYwotCi1oYXNfbGliIGxpYmNyeXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0
by5zbyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2No
ZWNrX2N1cmwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfY3VybAlNb24gRmViIDIwIDE4OjM0OjE0
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwK
LQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgIiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0
aGVuCi0JZWNobyAtbiAidW51c2VkLCAiCi0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJs
LWNvbmZpZwotY3VybF9saWJzPWBjdXJsLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29u
ZmlnIC0tbGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRl
bmN5IGxpYnJhcmllcyBmb3IgY3VybCBhcmUgbWlzc2luZyIKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfaXByb3V0ZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBB
VEgKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwg
aWZjb25maWcgOzsKLUxpbnV4KQotCWhhc19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25v
d24gT1MiIDs7Ci1lc2FjCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29s
cy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlv
X2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMg
Q0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJB
SU99ICE9IFgieSIgXSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGli
YWlvLmggOyB0aGVuCi0gICAgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFs
bCBsaWJhaW8gZGV2ZWwgcGFja2FnZSBvciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZp
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9jaGVja19s
aWJhaW9fbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlO
U1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9
IFgieSIgXSA7IHRoZW4KLSAgICBleGl0IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWls
ICJjYW4ndCBmaW5kIGxpYmFpbyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdk
IHRvb2xzL2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
b3BlbnNzbF9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9t
ZDUuaCB8fCBmYWlsICJtaXNzaW5nIG9wZW5zc2wgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNm
YTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9j
aGVjay9jaGVja19weXRob24JTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1p
ZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhP
Tn0gLWMgJwotaW1wb3J0IHN5cwotc3lzLmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Ig
c3lzLnZlcnNpb25faW5mb1sxXSA8IDMpCi0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24g
Pj0gMi4zIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgdG9vbHMvY2hlY2sv
Y2hlY2tfcHl0aG9uX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlN
b24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJV
SUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRI
T049cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1p
bXBvcnQgb3MucGF0aCwgc3lzCi1mb3IgcCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0
cyhwICsgIi9jb25maWcvTWFrZWZpbGUiKToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0n
IHx8IGZhaWwgImNhbid0IGZpbmQgcHl0aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90
b29scy9jaGVjay9jaGVja19weXRob25feG1sCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAw
MAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYg
dGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWls
ICR7UFlUSE9OfQotCi0ke1BZVEhPTn0gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rl
di9udWxsIHx8IFwKLWZhaWwgImNhbid0IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX3VkZXYJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAg
QEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRP
UyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7
Ci1MaW51eCkKLQloYXMgL3NiaW4vdWRldmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZh
ZG0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhh
c19vcl9mYWlsIHVkZXZpbmZvICYmIFwKLQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3tw
cmludCAkTkZ9J2AKLQlbICIkdWRldnZlciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQlo
YXMgaG90cGx1ZyB8fCBcCi0JCWZhaWwgInVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJz
aW9uIDU5IG9yIGxhdGVyIgotCTs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3V1
aWRfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAlNb24gRmViIDIwIDE4
OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsNyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1
bmNzLnNoCi0KLWhhc19oZWFkZXIgdXVpZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmgg
fHwgZmFpbCAibWlzc2luZyB1dWlkIGhlYWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1y
IGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdmOWQwN2QgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVs
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3gxMV9kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsOSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0K
LWhhc19oZWFkZXIgWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9p
bmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVk
ZS9YMTEva2V5c3ltZGVmLmggfHwgXAotd2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3hn
ZXR0ZXh0Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0CU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Mu
c2gKLQotaGFzX29yX2ZhaWwgeGdldHRleHQKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3
ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1s
MglNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQ
SV9CSU5ESU5HUyIgPSAieSIgXQotdGhlbgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4
aXQgMAotZmkKLQotaGFzX29yX2ZhaWwgeG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25m
aWcgLS1saWJzYCB8fCBmYWlsICJ4bWwyLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5r
ICR4bWwyX2xpYnMgfHwgZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1p
c3NpbmciCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9j
aGVja195YWpsX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDggKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNh
bid0IGZpbmQgeWFqbC95YWpsX3BhcnNlLmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8
fCBmYWlsICJjYW4ndCBmaW5kIHlhamwveWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8
fCBmYWlsICJjYW4ndCBmaW5kIGxpYnlhamwuc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNi
ZDZhN2Y5ZDA3ZCB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNr
L2NoZWNrX3psaWJfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEv
YmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIu
aCB8fCBmYWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3psaWJfbGliCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQot
Y2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMK
LQotaGFzX2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVj
ay9jaGsJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1m
dW5jX3VzYWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8
aW5zdGFsbHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZv
ciBYZW4gYnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEg
aWYgbm90LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3Zl
cyBnZW5lcmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91
c3Ivc2JpbgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJT
dW5PUyIgXTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAg
ICAgICBjaGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAg
ICAgY2hlY2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAg
IGV4aXQgMAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAg
OzsKLWVzYWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3Ig
ZiBpbiBjaGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAg
ICAgY29udGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7Owot
ICAgIGVzYWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAg
ICBmaQotICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRp
bnVlCi0gICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4m
MSA7IHRoZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAg
ICBmaQotZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBh
cyB3aGljaCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0J
aWYgWyAteiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0J
CXJldHVybiAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJz
aGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlm
b3IgcCBpbiAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0
aGVuCi0JCQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQot
CWRvbmUKLQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9k
ZXYvbnVsbCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNo
ZWNrX3N5c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQot
CQlpZiBbIC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJl
dHVybiAwCi0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYg
WyAtciAiJENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0J
CQlmaQotCQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsK
LQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBv
bGx1dGlvbiBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAg
ICAgICAjIGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQot
CSMgVGhpcyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxs
ZWQgYnV0Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24n
dCB3b3JrLgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRj
L2xkLnNvLmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIg
XCIkQ1JPU1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxs
IHRocm91Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7
T1N9IiA9ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1y
ICIkQ1JPU1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlp
ZiBbICIke09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdy
ZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9s
aW5rKCkgewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5z
ZXQgdG1wZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1w
ZmlsZT1gbWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9u
dWxsIDI+JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNv
bW1vbmx5IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIg
XSAmJiByZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hv
ICJwbGVhc2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJu
IDEKLQlmaQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5v
IHN5cy1yb290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQot
Ci13YXJuaW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQk
eyorOiAkKn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIk
MCJgIEZBSUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIg
M2JkNmE3ZjlkMDdkIHRvb2xzL2NvbmZpZy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5oLmluCVR1ZSBGZWIgMjEgMDI6
Mjk6MDYgMjAxMiArMDEwMApAQCAtMCwwICsxLDE2IEBACisvKgorICogQ29weXJpZ2h0IChDKSAy
MDEyCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0
cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZAorICogYnkgdGhlIEZy
ZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4gd2l0aCB0aGUgc3BlY2lh
bAorICogZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGluIGZpbGUgTElDRU5TRS4KKyAq
CisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxs
IGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo
ZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1Ig
QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgTGVzc2VyIEdlbmVyYWwgUHVi
bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqLworCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVm
IEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdm
OWQwN2QgdG9vbHMvY29uZmlndXJlLmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwlUdWUgRmViIDIxIDAyOjI5OjA2
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxOTIgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZp
bGUgd2l0aCBhdXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJF
UkVRKFsyLjY3XSkKK0FDX0lOSVQoW1hlbiBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVy
c2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVdKSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb21dKQorQUNfQ09ORklHX1NSQ0RJUihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklM
RVMoWy4uL2NvbmZpZy9Ub29scy5ta10pCitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQor
QUNfUFJFRklYX0RFRkFVTFQoWy91c3JdKQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENo
ZWNrIGlmIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQg
cHJpbnQgYSB3YXJuaW5nCisKK0FTX0lGKFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElC
UyRDUFBGTEFHUyRDUFAiXSwgWworICAgIEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFH
UywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwg
dXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5k
IEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVN
X0VYVEVOU0lPTlMKK0FDX0NBTk9OSUNBTF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200
X2luY2x1ZGUoW200L2VuYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVf
ZmVhdHVyZS5tNF0pCittNF9pbmNsdWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVk
ZShbbTQvcHl0aG9uX3htbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0p
CittNF9pbmNsdWRlKFttNC9weXRob25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5t
NF0pCittNF9pbmNsdWRlKFttNC9vY2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xp
Yi5tNF0pCittNF9pbmNsdWRlKFttNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVk
ZShbbTQvdXVpZC5tNF0pCittNF9pbmNsdWRlKFttNC9wa2cubTRdKQorCisjIEVuYWJsZS9kaXNh
YmxlIG9wdGlvbnMKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeHNtXSwKKyAgICBbRW5hYmxl
IFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0pCitBWF9BUkdfRU5BQkxF
X0FORF9FWFBPUlQoW2dpdGh0dHBdLCBbRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRU
UF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFttb25pdG9yc10sCisgICAgW0Rpc2FibGUg
eGVuc3RhdCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRf
RVhQT1JUKFt2dHBtXSwgW0VuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlXSkK
K0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeGFwaV0sIFtFbmFibGUgWGVuIEFQSSBCaW5kaW5n
c10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtweXRob250b29sc10sIFtEaXNhYmxlIFB5
dGhvbiB0b29sc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtvY2FtbHRvb2xzXSwgW0Rp
c2FibGUgT2NhbWwgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFttaW5pdGVybV0s
IFtFbmFibGUgbWluaXRlcm1dKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtsb21vdW50XSwg
W0VuYWJsZSBsb21vdW50XSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW2RlYnVnXSwgW0Rp
c2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29sc10pCisKK0FDX0FSR19WQVIoW1BSRVBF
TkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRv
IENGTEFHUyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbUFJFUEVORF9MSUJdLAorICAgIFtM
aXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwp
XSkKK0FDX0FSR19WQVIoW0FQUEVORF9JTkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBm
b2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW0FQ
UEVORF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERG
TEFHUyAod2l0aG91dCAtTCldKQorCitBWF9TRVRfRkxBR1MKKworQUNfQVJHX1ZBUihbUFlUSE9O
XSwgW1BhdGggdG8gdGhlIFB5dGhvbiBwYXJzZXJdKQorQUNfQVJHX1ZBUihbUEVSTF0sIFtQYXRo
IHRvIFBlcmwgcGFyc2VyXSkKK0FDX0FSR19WQVIoW0JSQ1RMXSwgW1BhdGggdG8gYnJjdGwgdG9v
bF0pCitBQ19BUkdfVkFSKFtJUF0sIFtQYXRoIHRvIGlwIHRvb2xdKQorQUNfQVJHX1ZBUihbQklT
T05dLCBbUGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIoW0ZMRVhd
LCBbUGF0aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9yXSkKK0FDX0FSR19WQVIo
W0NVUkxdLCBbUGF0aCB0byBjdXJsLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW1hNTF0sIFtQ
YXRoIHRvIHhtbDItY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZBUihbQkFTSF0sIFtQYXRoIHRvIGJh
c2ggc2hlbGxdKQorQUNfQVJHX1ZBUihbWEdFVFRFWFRdLCBbUGF0aCB0byB4Z2V0dHRleHQgdG9v
bF0pCisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK0FDX1BST0dfU0VECitBQ19QUk9HX0NDCitB
Q19QUk9HX0xOX1MKK0FDX1BST0dfTUFLRV9TRVQKK0FDX1BST0dfSU5TVEFMTAorQVhfUEFUSF9Q
Uk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVybF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQlJDVExd
LCBbYnJjdGxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQXSwgW2lwXSkKK0FYX1BBVEhfUFJP
R19PUl9GQUlMKFtCSVNPTl0sIFtiaXNvbl0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbRkxFWF0s
IFtmbGV4XSkKK0FTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5Il0sIFsKKyAgICBBWF9QQVRIX1BS
T0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZB
SUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10pCitdKQorQVNfSUYoW3Rlc3QgIngkb2NhbWx0b29scyIg
PSAieHkiXSwgWworICAgIEFDX1BST0dfT0NBTUwKKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMi
ID0gInhubyJdLCBbCisgICAgICAgIEFTX0lGKFt0ZXN0ICJ4JGVuYWJsZV9vY2FtbHRvb2xzIiA9
ICJ4eWVzIl0sIFsKKyAgICAgICAgICAgIEFDX01TR19FUlJPUihbT2NhbWwgdG9vbHMgZW5hYmxl
ZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sXSldKQorICAgICAgICBvY2FtbHRvb2xzPSJuIgor
ICAgIF0pCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihb
dGVzdCAieCRweXRob250b29scyIgPSAieHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9O
IiB8IGdyZXAgLXEgIl4vIl0sIFsKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAg
IFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJd
LCBbUFlUSE9OPSJweXRob24iXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVk
LCBidXQgaXMgbm90IGFuIGFic29sdXRlIHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZB
SUwoW1BZVEhPTlBBVEhdLCBbJFBZVEhPTl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04o
WzJdLCBbM10pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9O
X0RFVkVMKCkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRd
KQorQVhfQ0hFQ0tfVURFVihbNTldKQorQVhfQ0hFQ0tfVVVJRAorUEtHX0NIRUNLX01PRFVMRVMo
Z2xpYiwgZ2xpYi0yLjApCisKKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitBWF9ERUZBVUxUX0xJQgor
CisjIENoZWNrcyBmb3IgbGlicmFyaWVzLgorQUNfQ0hFQ0tfTElCKFthaW9dLCBbaW9fc2V0dXBd
LCBbc3lzdGVtX2Fpbz0ieSJdLCBbc3lzdGVtX2Fpbz0ibiJdKQorQUNfU1VCU1Qoc3lzdGVtX2Fp
bykKK0FDX0NIRUNLX0xJQihbY3J5cHRvXSwgW01ENV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3Vs
ZCBub3QgZmluZCBsaWJjcnlwdG9dKV0pCitBQ19DSEVDS19MSUIoW2V4dDJmc10sIFtleHQyZnNf
b3BlbjJdLCBbbGliZXh0MmZzPSJ5Il0sIFtsaWJleHQyZnM9Im4iXSkKK0FDX1NVQlNUKGxpYmV4
dDJmcykKK0FDX0NIRUNLX0xJQihbZ2NyeXB0XSwgW2djcnlfbWRfaGFzaF9idWZmZXJdLCBbbGli
Z2NyeXB0PSJ5Il0sIFtsaWJnY3J5cHQ9Im4iXSkKK0FDX1NVQlNUKGxpYmdjcnlwdCkKK0FDX0NI
RUNLX0xJQihbcHRocmVhZF0sIFtwdGhyZWFkX2NyZWF0ZV0sIFtdICwKKyAgICBbQUNfTVNHX0VS
Uk9SKFtDb3VsZCBub3QgZmluZCBsaWJwdGhyZWFkXSldKQorQUNfQ0hFQ0tfTElCKFtydF0sIFtj
bG9ja19nZXR0aW1lXSkKK0FDX0NIRUNLX0xJQihbdXVpZF0sIFt1dWlkX2NsZWFyXSwgW10sCisg
ICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGlidXVpZF0pXSkKK0FDX0NIRUNLX0xJ
QihbeWFqbF0sIFt5YWpsX2FsbG9jXSwgW10sCisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90
IGZpbmQgeWFqbF0pXSkKK0FDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRlQ29weV0sIFtdLCBbQUNf
TVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQorQUNfQ0hFQ0tfTElCKFtpY29udl0s
IFtsaWJpY29udl9vcGVuXSwgW2xpYmljb252PSJ5Il0sIFtsaWJpY29udj0ibiJdKQorQUNfU1VC
U1QobGliaWNvbnYpCisKKyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCitBQ19GVU5DX0FMTE9D
QQorQUNfQ0hFQ0tfSEVBREVSUyhbIFwKKyAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250
bC5oIGludHR5cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKKyAgICAgICAgICAg
ICAgICBuZXRkYi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJp
bmcuaCBcCisgICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmgg
c3lzL21vdW50Lmggc3lzL3BhcmFtLmggXAorICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBz
eXMvc3RhdHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKKyAgICAgICAgICAg
ICAgICB1bmlzdGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKyAgICAgICAgICAgICAgICBdKQor
CisjIENoZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0
ZXJpc3RpY3MuCitBQ19IRUFERVJfU1REQk9PTAorQUNfVFlQRV9VSURfVAorQUNfQ19JTkxJTkUK
K0FDX1RZUEVfSU5UMTZfVAorQUNfVFlQRV9JTlQzMl9UCitBQ19UWVBFX0lOVDY0X1QKK0FDX1RZ
UEVfSU5UOF9UCitBQ19UWVBFX01PREVfVAorQUNfVFlQRV9PRkZfVAorQUNfVFlQRV9QSURfVAor
QUNfQ19SRVNUUklDVAorQUNfVFlQRV9TSVpFX1QKK0FDX1RZUEVfU1NJWkVfVAorQUNfQ0hFQ0tf
TUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfYmxrc2l6ZV0pCitBQ19TVFJVQ1RfU1RfQkxPQ0tTCitB
Q19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9yZGV2XSkKK0FDX1RZUEVfVUlOVDE2X1QK
K0FDX1RZUEVfVUlOVDMyX1QKK0FDX1RZUEVfVUlOVDY0X1QKK0FDX1RZUEVfVUlOVDhfVAorQUNf
Q0hFQ0tfVFlQRVMoW3B0cmRpZmZfdF0pCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1bmN0aW9u
cy4KK0FDX0ZVTkNfRVJST1JfQVRfTElORQorQUNfRlVOQ19GT1JLCitBQ19GVU5DX0ZTRUVLTwor
QUNfRlVOQ19MU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSworQUNfSEVBREVSX01BSk9SCitB
Q19GVU5DX01BTExPQworQUNfRlVOQ19NS1RJTUUKK0FDX0ZVTkNfTU1BUAorQUNfRlVOQ19SRUFM
TE9DCitBQ19GVU5DX1NUUk5MRU4KK0FDX0ZVTkNfU1RSVE9ECitBQ19DSEVDS19GVU5DUyhbIFwK
KyAgICAgICAgICAgICAgICBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZk
YXRhc3luYyBmdHJ1bmNhdGUgXAorICAgICAgICAgICAgICAgIGdldGN3ZCBnZXRob3N0YnluYW1l
IGdldGhvc3RuYW1lIGdldHBhZ2VzaXplIGdldHRpbWVvZmRheSBcCisgICAgICAgICAgICAgICAg
aW5ldF9udG9hIGlzYXNjaWkgbG9jYWx0aW1lX3IgbWVtY2hyIG1lbW1vdmUgbWVtc2V0IG1rZGly
IFwKKyAgICAgICAgICAgICAgICBta2ZpZm8gbXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2Nv
bXAgcm1kaXIgc2VsZWN0IHNldGVudiBcCisgICAgICAgICAgICAgICAgc29ja2V0IHN0cmNhc2Vj
bXAgc3RyY2hyIHN0cmNzcG4gc3RyZHVwIHN0cmVycm9yIHN0cm5kdXAgXAorICAgICAgICAgICAg
ICAgIHN0cnBicmsgc3RycmNociBzdHJzcG4gc3Ryc3RyIHN0cnRvbCBzdHJ0b3VsIHN0cnRvdWxs
IHR6c2V0IFwKKyAgICAgICAgICAgICAgICB1bmFtZSBcCisgICAgICAgICAgICAgICAgXSkKKwor
QUNfT1VUUFVUKCkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2Rl
YnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01h
a2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9kZWJ1Z2dl
ci9nZGJzeC94Zy9NYWtlZmlsZQlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTIx
LDcgKzIxLDYgQEAgeGdfYWxsLmE6ICQoWEdfT0JKUykgTWFrZWZpbGUgJChYR19IRFJTKQogIwkk
KENDKSAtbTMyIC1jIC1vICRAICReCiAKIHhlbi1oZWFkZXJzOgotCSQoTUFLRSkgLUMgLi4vLi4v
Li4vY2hlY2sgCiAJJChNQUtFKSAtQyAuLi8uLi8uLi9pbmNsdWRlCiAKICMgeGdfbWFpbi5vOiB4
Z19tYWluLmMgTWFrZWZpbGUgJChYR19IRFJTKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvaW5zdGFsbC5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9pbnN0YWxsLnNoCVR1ZSBGZWIgMjEgMDI6Mjk6MDYg
MjAxMiArMDEwMApAQCAtMCwwICsxLDEgQEAKKy4uL2luc3RhbGwuc2gKXCBObyBuZXdsaW5lIGF0
IGVuZCBvZiBmaWxlCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9s
aWJmc2ltYWdlL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJ
VHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0zLDcgKzMsMTEgQEAgaW5jbHVkZSAk
KFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJTLXkgPSBjb21tb24gdWZzIHJlaXNl
cmZzIGlzbzk2NjAgZmF0IHpmcwogU1VCRElSUy0kKENPTkZJR19YODYpICs9IHhmcwotU1VCRElS
Uy15ICs9ICQoc2hlbGwgZW52IENDPSIkKENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgk
KENPTkZJR19FWFQyRlMpLCB5KQorICAgIFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisg
ICAgU1VCRElSUy15ICs9IGV4dDJmcworZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFs
bAogYWxsIGNsZWFuIGluc3RhbGw6ICU6IHN1YmRpcnMtJQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAt
ciAzYmQ2YTdmOWQwN2QgdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9v
bHMvbGliZnNpbWFnZS9jaGVjay1saWJleHQyZnMJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIx
ICswLDAgQEAKLSMhL2Jpbi9zaAotCi1jYXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8
ZXh0MmZzL2V4dDJmcy5oPgotCi1pbnQgbWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9G
Ci0KLSR7Q0MtZ2NjfSAtbyBleHQyLXRlc3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVs
bCAyPiYxCi1pZiBbICQ/ID0gMCBdOyB0aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNo
byBleHQyZnMKLWZpCi0KLXJtIC1mIGV4dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlm
ZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQot
LS0gYS90b29scy9saWJ4ZW4vTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyBiL3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAx
MDAKQEAgLTIyLDEyICsyMiwxMiBAQCBNQUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyAr
PSAtSWluY2x1ZGUgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwy
LWNvbmZpZyAtLWNmbGFncykgXAotICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxh
Z3MpIFwKKyAgICAgICAgICAkKHNoZWxsICQoWE1MMl9DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAg
ICAgICAgJChzaGVsbCAkKENVUkxfQ09ORklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElD
CiAKLUxERkxBR1MgKz0gJChzaGVsbCB4bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAg
JChzaGVsbCBjdXJsLWNvbmZpZyAtLWxpYnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyX0NP
TkZJRykgLS1saWJzKSBcCisgICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1saWJz
KQogCiBMSUJYRU5BUElfSERSUyA9ICQod2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5j
bHVkZS94ZW4vYXBpL3hlbl9hbGwuaAogTElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywg
JS5vLCAkKHdpbGRjYXJkIHNyYy8qLmMpKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2YTdm
OWQwN2QgdG9vbHMvbGlieGwvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGwvTWFrZWZpbGUJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlCVR1
ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiArMDEwMApAQCAtMTksMTAgKzE5LDYgQEAgaWZlcSAoJChD
T05GSUdfTGludXgpLHkpCiBMSUJVVUlEX0xJQlMgKz0gLWx1dWlkCiBlbmRpZgogCi1pZmVxICgk
KENPTkZJR19ZQUpMX1ZFUlNJT04pLHkpCi1DRkxBR1MgKz0gLURIQVZFX1lBSkxfVkVSU0lPTgot
ZW5kaWYKLQogTElCWExfTElCUyA9CiBMSUJYTF9MSUJTID0gJChMRExJQlNfbGlieGVuY3RybCkg
JChMRExJQlNfbGlieGVuZ3Vlc3QpICQoTERMSUJTX2xpYnhlbnN0b3JlKSAkKExETElCU19saWJi
bGt0YXBjdGwpICQoVVRJTF9MSUJTKSAkKExJQlVVSURfTElCUykKIApAQCAtNTYsNyArNTIsNyBA
QCBMSUJYTF9PQkpTID0gZmxleGFycmF5Lm8gbGlieGwubyBsaWJ4bF9jCiAJCQlsaWJ4bF9xbXAu
byBsaWJ4bF9ldmVudC5vICQoTElCWExfT0JKUy15KQogTElCWExfT0JKUyArPSBfbGlieGxfdHlw
ZXMubyBsaWJ4bF9mbGFzay5vIF9saWJ4bF90eXBlc19pbnRlcm5hbC5vCiAKLSQoTElCWExfT0JK
Uyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkg
JChDRkxBR1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkKKyQoTElCWExfT0JK
Uyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAkKENGTEFHU19saWJ4ZW5ndWVzdCkg
JChDRkxBR1NfbGlieGVuc3RvcmUpICQoQ0ZMQUdTX2xpYmJsa3RhcGN0bCkgLWluY2x1ZGUgJChY
RU5fUk9PVCkvdG9vbHMvY29uZmlnLmgKIAogQVVUT0lOQ1M9IGxpYnhsdV9jZmdfeS5oIGxpYnhs
dV9jZmdfbC5oIF9saWJ4bF9saXN0LmgKIEFVVE9TUkNTPSBsaWJ4bHVfY2ZnX3kuYyBsaWJ4bHVf
Y2ZnX2wuYwpAQCAtNjksNiArNjUsNyBAQCBDTElFTlRTID0geGwgdGVzdGlkbAogWExfT0JKUyA9
IHhsLm8geGxfY21kaW1wbC5vIHhsX2NtZHRhYmxlLm8geGxfc3hwLm8KICQoWExfT0JKUyk6IENG
TEFHUyArPSAkKENGTEFHU19saWJ4ZW5jdHJsKSAjIEZvciB4ZW50b29sbG9nLmgKICQoWExfT0JK
Uyk6IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5saWdodCkKKyQoWExfT0JKUyk6IENGTEFHUyAr
PSAtaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9jb25maWcuaCAjIGxpYnhsX2pzb24uaCBuZWVk
cyBpdC4KIAogdGVzdGlkbC5vOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxB
R1NfbGlieGVubGlnaHQpCiB0ZXN0aWRsLmM6IGxpYnhsX3R5cGVzLmlkbCBnZW50ZXN0LnB5IGxp
YnhsLmggJChBVVRPSU5DUykKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRv
b2xzL2xpYnhsL2xpYnhsX2pzb24uaAotLS0gYS90b29scy9saWJ4bC9saWJ4bF9qc29uLmgJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2pzb24u
aAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTE4LDcgKzE4LDcgQEAKICNpbmNs
dWRlIDx5YWpsL3lhamxfZ2VuLmg+CiAjaW5jbHVkZSA8eWFqbC95YWpsX3BhcnNlLmg+CiAKLSNp
ZmRlZiBIQVZFX1lBSkxfVkVSU0lPTgorI2lmZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAog
IyAgaW5jbHVkZSA8eWFqbC95YWpsX3ZlcnNpb24uaD4KICNlbmRpZgogCmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIDNiZDZhN2Y5ZDA3ZCB0b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0
X2xpYi5tNAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitB
Q19ERUZVTihbQVhfREVGQVVMVF9MSUJdLAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0
Il0sIFsKKyAgICBMSUJfUEFUSD0ibGliNjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkK
K0FDX1NVQlNUKExJQl9QQVRIKV0pCisKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3Zjlk
MDdkIHRvb2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJVHVl
IEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtB
WF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNf
SEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFi
bGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVf
JDEiID0gInh5ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQx
XSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L2VuYWJsZV9mZWF0
dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00CVR1ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiArMDEw
MApAQCAtMCwwICsxLDEzIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwK
K1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwg
WyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhf
Y3ZfJDE9InkiCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3Zf
JDE9Im4iCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQor
JDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvbTQvb2NhbWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvb2NhbWwubTQJVHVlIEZlYiAyMSAwMjoyOTow
NiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBP
Q2FtbAorZG5sIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5
cmlnaHQgwqkgMjAwOSAgICAgIFJpY2hhcmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAy
MDA5ICAgICAgU3RlZmFubyBaYWNjaGlyb2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBP
bGl2aWVyIEFuZHJpZXUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3Bo
ZSBGaWxsacOidHJlCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8K
K2RubAorZG5sIEZvciBkb2N1bWVudGF0aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFu
IHBhZ2UuCisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBm
b3Igb2NhbWxjCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBp
ZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1M
QyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19N
U0dfUkVTVUxUKFtPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9D
QU1MTElCIGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhl
bgorICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1M
QyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0df
UkVTVUxUKFtPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBm
aQorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkK
KworICAgICBBQ19TVUJTVChbT0NBTUxWRVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElC
XSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtP
Q0FNTE9QVF0sW29jYW1sb3B0XSxbbm9dKQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0
ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBv
Y2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVS
U0lPTj1gJE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8
cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJ
ICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0
IGRpc2NhcmRlZC5dKQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9w
dAorCWZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBj
aGVja2luZyBmb3Igb2NhbWxjLm9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRd
LFtvY2FtbGMub3B0XSxbbm9dKQorICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8i
OyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZl
cnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FN
TFZFUlNJT04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZy
b20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRP
Q0FNTENET1RPUFQKKwlmaQorICAgICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0
Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tf
VE9PTChbT0NBTUxPUFRET1RPUFRdLFtvY2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9D
QU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9U
T1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlm
IHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNf
TVNHX1JFU1VMVChbdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlz
Y2FyZGVkLl0pCisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAg
IGZpCisgICAgICAgIGZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAg
ZmkKKworICBBQ19TVUJTVChbT0NBTUxDXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3Bs
ZXZlbAorICBBQ19DSEVDS19UT09MKFtPQ0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZGVwCisgIEFDX0NIRUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtu
b10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FN
TE1LVE9QXSxbb2NhbWxta3RvcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGli
CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxk
b2NdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTEJVSUxEXSxbb2NhbWxidWlsZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BS
T0dfT0NBTUxMRVhdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVD
S19UT09MKFtPQ0FNTExFWF0sW29jYW1sbGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgi
ICE9ICJubyI7IHRoZW4KKyAgICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1s
bGV4Lm9wdF0sW25vXSkKKyAgICBpZiB0ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRo
ZW4KKwlPQ0FNTExFWD0kT0NBTUxMRVhET1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChb
T0NBTUxMRVhdKQorXSkKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAg
QUNfQ0hFQ0tfVE9PTChbT0NBTUxZQUNDXSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChb
T0NBTUxZQUNDXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0
CisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENB
TUxQNCIgIT0gIm5vIjsgdGhlbgorICAgICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNl
ZCAtbiAtZSAnc3wuKnZlcnNpb24gKlwoLipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBW
RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lv
bnMgZGlmZmVycyBmcm9tIG9jYW1sY10pCisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBm
aQorICBBQ19TVUJTVChbQ0FNTFA0XSkKKworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9v
bHMKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNE9dLFtjYW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtD
QU1MUDRPRl0sW2NhbWxwNG9mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtj
YW1scDRvb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0s
W25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisg
IEFDX0NIRUNLX1RPT0woW0NBTUxQNFJdLFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09M
KFtDQU1MUDRSRl0sW2NhbWxwNHJmXSxbbm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisg
IEFDX1NVQlNUKFtDQU1MUDRPXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1Qo
W0NBTUxQNE9PRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0
UFJPRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10p
CisKKworQUNfREVGVU4oW0FDX1BST0dfRklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FD
X1BST0dfT0NBTUxdKWRubAorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVD
S19UT09MKFtPQ0FNTEZJTkRdLFtvY2FtbGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJ
TkRdKQorXSkKKworCitkbmwgVGhhbmtzIHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlz
IG5leHQgYml0IG91dCBmb3IgdXMuCitkbmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0gg
aWYgaXQncyBub3QgZGVmaW5lZCBhbHJlYWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4K
K0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19Q
Uk9HX0ZJTkRMSUJdKWRubAorCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIg
cGFja2FnZSAkMV0pCisKKyAgdW5zZXQgZm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisg
IGZvciBwa2cgaW4gJDEgJDIgOyBkbworICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rl
di9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisg
ICAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAg
ICBicmVhaworICAgIGZpCisgIGRvbmUKKyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVu
CisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtH
XyQxXSk9bm8KKyAgZmkKKworICBBQ19TVUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitd
KQorCisKK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0df
Q0hFQ0tJTkcoW2ZvciBPQ2FtbCBtb2R1bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8
RU9GCitvcGVuICQzCitFT0YKKyAgdW5zZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRv
CisgICAgaWYgJE9DQU1MQyAtYyAtSSAiJCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4K
KyAgICAgIGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVz
dCAiJGZvdW5kIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAg
QUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChb
JDFdKQorXSkKKworCitkbmwgWFhYIENyb3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNL
X09DQU1MX1dPUkRfU0laRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRu
bAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBj
YXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5
cy53b3JkX3NpemUpCisgIEVPRgorICBPQ0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5t
bGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FN
TF9XT1JEX1NJWkVdKQorXSkKKworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAor
W2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5H
KFtPQ2FtbCBTeXMub3NfdHlwZV0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJp
bnRfc3RyaW5nKFN5cy5vc190eXBlKTs7CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwg
Y29uZnRlc3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VC
U1QoW09DQU1MX09TX1RZUEVdKQorXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3Zjlk
MDdkIHRvb2xzL200L3BhdGhfb3JfZmFpbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9wYXRoX29yX2ZhaWwubTQJVHVlIEZlYiAy
MSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhf
UFJPR19PUl9GQUlMXSwKK1tBQ19QQVRIX1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3Qg
eCIkeyQxfSIgPT0geCJubyIgCit0aGVuCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmlu
ZCAkMiwgcGxlYXNlIGluc3RhbGwgJDJdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAz
YmQ2YTdmOWQwN2QgdG9vbHMvbTQvcGtnLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3BrZy5tNAlUdWUgRmViIDIxIDAyOjI5OjA2
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxNTcgQEAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0
ZSBhbmQgdXRpbGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMg
c2VyaWFsIDEgKHBrZy1jb25maWctMC4yNCkKKyMgCisjIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0
IEphbWVzIFJlbW5hbnQgPHNjb3R0QG5ldHNwbGl0LmNvbT4uCisjCisjIFRoaXMgcHJvZ3JhbSBp
cyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Cisj
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJz
aW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZl
cnNpb24uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0
IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVT
UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1Ymxp
YyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZl
ZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdpdGgg
dGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZvdW5k
YXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjEx
MS0xMzA3LCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFy
dCBvZiBhIHByb2dyYW0gdGhhdCBjb250YWlucyBhCisjIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdl
bmVyYXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCisjIHRoZSBzYW1l
IGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJv
Z3JhbS4KKworIyBQS0dfUFJPR19QS0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCisjIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfUFJPR19QS0dfQ09ORklH
XSwKK1ttNF9wYXR0ZXJuX2ZvcmJpZChbXl8/UEtHX1tBLVpfXSskXSkKK200X3BhdHRlcm5fYWxs
b3coW15QS0dfQ09ORklHKF9QQVRIKT8kXSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUddLCBbcGF0
aCB0byBwa2ctY29uZmlnIHV0aWxpdHldKQorQUNfQVJHX1ZBUihbUEtHX0NPTkZJR19QQVRIXSwg
W2RpcmVjdG9yaWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGhdKQorQUNfQVJH
X1ZBUihbUEtHX0NPTkZJR19MSUJESVJdLCBbcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBi
dWlsdC1pbiBzZWFyY2ggcGF0aF0pCisKK2lmIHRlc3QgIngkYWNfY3ZfZW52X1BLR19DT05GSUdf
c2V0IiAhPSAieHNldCI7IHRoZW4KKwlBQ19QQVRIX1RPT0woW1BLR19DT05GSUddLCBbcGtnLWNv
bmZpZ10pCitmaQoraWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisJX3BrZ19taW5fdmVy
c2lvbj1tNF9kZWZhdWx0KFskMV0sIFswLjkuMF0pCisJQUNfTVNHX0NIRUNLSU5HKFtwa2ctY29u
ZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb25dKQorCWlmICRQS0dfQ09O
RklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgor
CQlBQ19NU0dfUkVTVUxUKFt5ZXNdKQorCWVsc2UKKwkJQUNfTVNHX1JFU1VMVChbbm9dKQorCQlQ
S0dfQ09ORklHPSIiCisJZmkKK2ZpW11kbmwKK10pIyBQS0dfUFJPR19QS0dfQ09ORklHCisKKyMg
UEtHX0NIRUNLX0VYSVNUUyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1O
T1QtRk9VTkRdKQorIworIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9m
IG1vZHVsZXMgZXhpc3RzLiAgU2ltaWxhcgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQg
ZG9lcyBub3Qgc2V0IHZhcmlhYmxlcyBvciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1l
bWJlciB0aGF0IG00IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisj
IG9ubHkgYXQgdGhlIGZpcnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBm
aXJzdCBwbGFjZQorIyBpdCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0
IGlzIHdpdGhpbiBhbiAiaWYiLCB5b3UKKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMg
bWFudWFsbHkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfRVhJU1RTXSwKK1tBQ19SRVFV
SVJFKFtQS0dfUFJPR19QS0dfQ09ORklHXSlkbmwKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAm
JiBcCisgICAgQUNfUlVOX0xPRyhbJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMg
IiQxIl0pOyB0aGVuCisgIG00X2RlZmF1bHQoWyQyXSwgWzpdKQorbTRfaWZ2YWxuKFskM10sIFtl
bHNlCisgICQzXSlkbmwKK2ZpXSkKKworIyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFO
RF0sIFtNT0RVTEVTXSkKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tCittNF9kZWZpbmUoW19QS0dfQ09ORklHXSwKK1tpZiB0ZXN0IC1uICIkJDEiOyB0aGVu
CisgICAgcGtnX2N2X1tdJDE9IiQkMSIKKyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhl
bgorICAgIFBLR19DSEVDS19FWElTVFMoWyQzXSwKKyAgICAgICAgICAgICAgICAgICAgIFtwa2df
Y3ZfW10kMT1gJFBLR19DT05GSUcgLS1bXSQyICIkMyIgMj4vZGV2L251bGxgXSwKKwkJICAgICBb
cGtnX2ZhaWxlZD15ZXNdKQorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2ZpW11kbmwK
K10pIyBfUEtHX0NPTkZJRworCisjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAorIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorQUNfREVGVU4oW19QS0dfU0hPUlRfRVJST1JTX1NV
UFBPUlRFRF0sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCitpZiAkUEtHX0NP
TkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtn
X3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJy
b3JzX3N1cHBvcnRlZD1ubworZmlbXWRubAorXSkjIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRF
RAorCisKKyMgUEtHX0NIRUNLX01PRFVMRVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNU
SU9OLUlGLUZPVU5EXSwKKyMgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQorIworIworIyBOb3RlIHRo
YXQgaWYgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bworIyBQS0dfQ0hF
Q0tfTU9EVUxFUyBtaWdodCBub3QgaGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVk
ZSBhbgorIyBleHBsaWNpdCBjYWxsIHRvIFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25m
aWd1cmUuYWMKKyMKKyMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtQS0dfQ0hFQ0tfTU9EVUxFU10sCitb
QUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0NG
TEFHU10sIFtDIGNvbXBpbGVyIGZsYWdzIGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlk
bmwKK0FDX0FSR19WQVIoWyQxXVtfTElCU10sIFtsaW5rZXIgZmxhZ3MgZm9yICQxLCBvdmVycmlk
aW5nIHBrZy1jb25maWddKWRubAorCitwa2dfZmFpbGVkPW5vCitBQ19NU0dfQ0hFQ0tJTkcoW2Zv
ciAkMV0pCisKK19QS0dfQ09ORklHKFskMV1bX0NGTEFHU10sIFtjZmxhZ3NdLCBbJDJdKQorX1BL
R19DT05GSUcoWyQxXVtfTElCU10sIFtsaWJzXSwgWyQyXSkKKworbTRfZGVmaW5lKFtfUEtHX1RF
WFRdLCBbQWx0ZXJuYXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZhcmlhYmxl
cyAkMVtdX0NGTEFHUworYW5kICQxW11fTElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBjYWxsIHBr
Zy1jb25maWcuCitTZWUgdGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0YWlscy5d
KQorCitpZiB0ZXN0ICRwa2dfZmFpbGVkID0geWVzOyB0aGVuCisgICAJQUNfTVNHX1JFU1VMVChb
bm9dKQorICAgICAgICBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKKyAgICAgICAgaWYgdGVz
dCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCisJICAgICAgICAkMVtd
X1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICIk
MiIgMj4mMWAKKyAgICAgICAgZWxzZSAKKwkgICAgICAgICQxW11fUEtHX0VSUk9SUz1gJFBLR19D
T05GSUcgLS1wcmludC1lcnJvcnMgIiQyIiAyPiYxYAorICAgICAgICBmaQorCSMgUHV0IHRoZSBu
YXN0eSBlcnJvciBtZXNzYWdlIGluIGNvbmZpZy5sb2cgd2hlcmUgaXQgYmVsb25ncworCWVjaG8g
IiQkMVtdX1BLR19FUlJPUlMiID4mQVNfTUVTU0FHRV9MT0dfRkQKKworCW00X2RlZmF1bHQoWyQ0
XSwgW0FDX01TR19FUlJPUigKK1tQYWNrYWdlIHJlcXVpcmVtZW50cyAoJDIpIHdlcmUgbm90IG1l
dDoKKworJCQxX1BLR19FUlJPUlMKKworQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklH
X1BBVEggZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQgc29mdHdhcmUgaW4g
YSBub24tc3RhbmRhcmQgcHJlZml4LgorCitfUEtHX1RFWFRdKWRubAorICAgICAgICBdKQorZWxp
ZiB0ZXN0ICRwa2dfZmFpbGVkID0gdW50cmllZDsgdGhlbgorICAgICAJQUNfTVNHX1JFU1VMVChb
bm9dKQorCW00X2RlZmF1bHQoWyQ0XSwgW0FDX01TR19GQUlMVVJFKAorW1RoZSBwa2ctY29uZmln
IHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAor
aXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJs
ZSB0byB0aGUgZnVsbAorcGF0aCB0byBwa2ctY29uZmlnLgorCitfUEtHX1RFWFQKKworVG8gZ2V0
IHBrZy1jb25maWcsIHNlZSA8aHR0cDovL3BrZy1jb25maWcuZnJlZWRlc2t0b3Aub3JnLz4uXSlk
bmwKKyAgICAgICAgXSkKK2Vsc2UKKwkkMVtdX0NGTEFHUz0kcGtnX2N2X1tdJDFbXV9DRkxBR1MK
KwkkMVtdX0xJQlM9JHBrZ19jdl9bXSQxW11fTElCUworICAgICAgICBBQ19NU0dfUkVTVUxUKFt5
ZXNdKQorCSQzCitmaVtdZG5sCitdKSMgUEtHX0NIRUNLX01PRFVMRVMKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L3B5dGhvbl9kZXZlbC5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9weXRob25f
ZGV2ZWwubTQJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTggQEAK
K0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fREVWRUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9y
IHB5dGhvbiBkZXZlbF0pCisKK2AkUFlUSE9OIC1jICcKK2ltcG9ydCBvcy5wYXRoLCBzeXMKK2Zv
ciBwIGluIHN5cy5wYXRoOgorICAgIGlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtl
ZmlsZSIpOgorICAgICAgICBzeXMuZXhpdCgwKQorc3lzLmV4aXQoMSkKKycgPiAvZGV2L251bGwg
Mj4mMWAKKworaWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25v
XSkKKyAgICBBQ19NU0dfRVJST1IoW1B5dGhvbiBkZXZlbCBwYWNrYWdlIG5vdCBmb3VuZF0pCitl
bHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgwZWNhOWNmYTMg
LXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L3B5dGhvbl92ZXJzaW9uLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl92ZXJz
aW9uLm00CVR1ZSBGZWIgMjEgMDI6Mjk6MDYgMjAxMiArMDEwMApAQCAtMCwwICsxLDEyIEBACitB
Q19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT05dLAorW0FDX01TR19DSEVDS0lORyhbZm9y
IHB5dGhvbiB2ZXJzaW9uID49ICQxLiQyIF0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgZXhp
dChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKCQxLCAkMikiKSknYAoraWYgdGVzdCAiJD8iICE9
ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFgCisgICAgQUNf
TVNHX1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUigKKyAgICAgICAgWyRweXRob25fdmVy
c2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgJDEuJDJdKQorZWxz
ZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IDNiZDZhN2Y5ZDA3ZCB0b29scy9tNC9weXRob25feG1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl94bWwubTQJVHVl
IEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtB
WF9DSEVDS19QWVRIT05fWE1MXSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24geG1sLmRv
bS5taW5pZG9tXSkKK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRl
c3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNH
X0VSUk9SKFtVbmFibGUgdG8gZmluZCB4bWwuZG9tLm1pbmlkb20gbW9kdWxlXSkKK2Vsc2UKKyAg
ICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciAzYmQ2
YTdmOWQwN2QgdG9vbHMvbTQvc2V0X2NmbGFnc19sZGZsYWdzLm00Ci0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3NldF9jZmxhZ3NfbGRm
bGFncy5tNAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwyMCBAQAor
QUNfREVGVU4oW0FYX1NFVF9GTEFHU10sCitbZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVT
CitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2Rv
bmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1Mr
PSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQ
UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdT
ICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZM
QUdTICRBUFBFTkRfTERGTEFHUyJdKQorCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5
ZDA3ZCB0b29scy9tNC91ZGV2Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL3Rvb2xzL200L3VkZXYubTQJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMzIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0
ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgIEFDX1BBVEhfUFJPRyhb
VURFVkFETV0sIFt1ZGV2YWRtXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0g
eCJubyIgCisgICAgdGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW1VERVZJTkZPXSwgW3VkZXZp
bmZvXSwgW25vXSkKKyAgICAgICAgaWYgdGVzdCB4IiR7VURFVklORk99IiA9PSB4Im5vIgorICAg
ICAgICB0aGVuCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoCisgICAgICAgICAgICAgICAgW1Vu
YWJsZSB0byBmaW5kIHVkZXZhZG0gb3IgdWRldmluZm8sIHBsZWFzZSBpbnN0YWxsIHVkZXZdKQor
ICAgICAgICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50
ICRORn0nYAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwg
YXdrICd7cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5
CisgICAgdGhlbgorICAgICAgICBBQ19QQVRIX1BST0coW0hPVFBMVUddLCBbaG90cGx1Z10sIFtu
b10pCisgICAgICAgIGlmIHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVu
CisgICAgICAgICAgICBBQ19NU0dfRVJST1IoW3VkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2
ZXJzaW9uIDU5IG9yIGxhdGVyXSkKKyAgICAgICAgZmkKKyAgICBmaQorZWxzZQorICAgIEFDX1BB
VEhfUFJPRyhbVk5DT05GSUddLCBbdm5jb25maWddLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1ZO
Q09ORklHfSIgPT0geCJubyIKKyAgICB0aGVuCisgICAgICAgIEFDX01TR19FUlJPUihbTm90IGEg
TGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmRdKQorICAgIGZpCitmaQorXSkKZGlm
ZiAtciBjYTgwZWNhOWNmYTMgLXIgM2JkNmE3ZjlkMDdkIHRvb2xzL200L3V1aWQubTQKLS0tIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdXVp
ZC5tNAlUdWUgRmViIDIxIDAyOjI5OjA2IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNf
REVGVU4oW0FYX0NIRUNLX1VVSURdLAorW2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1n
bnUiCit0aGVuCisgICAgQUNfQ0hFQ0tfSEVBREVSKFt1dWlkL3V1aWQuaF0sLAorCSAgICBbQUNf
TVNHX0VSUk9SKFtjYW5ub3QgZmluZCB1dWlkIGhlYWRlcnNdKV0pCitlbHNlCisgICAgQUNfQ0hF
Q0tfSEVBREVSKFt1dWlkLmhdLCwKKwkgICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVp
ZCBoZWFkZXJzXSldKQorZmkKK10pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIDNiZDZhN2Y5ZDA3
ZCB2ZXJzaW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3ZlcnNpb24uc2gJVHVlIEZlYiAyMSAwMjoyOTowNiAyMDEyICswMTAwCkBAIC0wLDAg
KzEsNSBAQAorIyEvYmluL3NoCisKK01BSk9SPWBncmVwICJleHBvcnQgWEVOX1ZFUlNJT04iICQx
IHwgc2VkICdzLy4qPS8vZycgfCB0ciAtcyAiICJgCitNSU5PUj1gZ3JlcCAiZXhwb3J0IFhFTl9T
VUJWRVJTSU9OIiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorcHJpbnRmICIlZC4l
ZCIgJE1BSk9SICRNSU5PUgo=

--===============3706650461757472180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3706650461757472180==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 12:35:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzove-0007vT-Ll; Tue, 21 Feb 2012 12:34:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzovc-0007un-L3
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:34:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329827675!15579711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14539 invoked from network); 21 Feb 2012 12:34:37 -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;
	21 Feb 2012 12:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:34:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:34:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzovR-0007e3-DR; Tue, 21 Feb 2012 12:34:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzovR-0004SD-CZ;
	Tue, 21 Feb 2012 12:34:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.36697.376087.225279@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:34:33 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329824022.25232.103.camel@dagon.hellion.org.uk>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> However I am not sure what to do with the "master" branch of our tree.
> Previously I just omitted it since it has no real meaning but that
> caused confusion and people wanted me to put something there.
> 
> I don't want to track the upstream devel branch since I don't want users
> who clone our tree to think we support that as is. I don't want to push
> the currently supported stable branch because that would necessarily
> make master a rebasing branch.
> 
> The xen-unstable build system itself uses explicit commit numbers or
> tags so isn't really effected.
> 
> IanJ -- what do you think?

Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
xen-unstable's Config.mk ?  That's what I do with
qemu-xen-unstable.git.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:35:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzove-0007vT-Ll; Tue, 21 Feb 2012 12:34:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzovc-0007un-L3
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 12:34:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329827675!15579711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14539 invoked from network); 21 Feb 2012 12:34:37 -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;
	21 Feb 2012 12:34:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10841945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:34:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:34:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzovR-0007e3-DR; Tue, 21 Feb 2012 12:34:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzovR-0004SD-CZ;
	Tue, 21 Feb 2012 12:34:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.36697.376087.225279@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:34:33 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329824022.25232.103.camel@dagon.hellion.org.uk>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> However I am not sure what to do with the "master" branch of our tree.
> Previously I just omitted it since it has no real meaning but that
> caused confusion and people wanted me to put something there.
> 
> I don't want to track the upstream devel branch since I don't want users
> who clone our tree to think we support that as is. I don't want to push
> the currently supported stable branch because that would necessarily
> make master a rebasing branch.
> 
> The xen-unstable build system itself uses explicit commit numbers or
> tags so isn't really effected.
> 
> IanJ -- what do you think?

Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
xen-unstable's Config.mk ?  That's what I do with
qemu-xen-unstable.git.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:51:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:51:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpBP-000058-94; Tue, 21 Feb 2012 12:51: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 1RzpBN-00004v-TU
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:51:02 +0000
Received: from [85.158.139.83:37440] by server-10.bemta-5.messagelabs.com id
	48/2C-07861-333934F4; Tue, 21 Feb 2012 12:50:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329828659!15985647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16792 invoked from network); 21 Feb 2012 12:50:59 -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;
	21 Feb 2012 12:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10842593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:50:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:50:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzpBA-0008Dz-1F; Tue, 21 Feb 2012 12:50:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzpB9-0008Jf-WB;
	Tue, 21 Feb 2012 12:50:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.37671.962922.464807@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:50:47 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
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 v7] build: add autoconf to replace custom
 checks in tools/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

Roger Pau Monne writes ("[PATCH v7] build: add autoconf to replace custom checks in tools/check"):
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script, config/Tools.mk
> and config.h.
> 
> conf/Tools.mk is included by tools/Rules.mk, and contains most of the
> options previously defined in .config, that can now be set passing
> parameters or defining environment variables when executing configure
> script.
> 
> config.h is only used by libxl/xl to detect yajl_version.h.

Thanks.  Unfortunately this doesn't seem to work for me.  What I did
was:

  hg clean --all && cp ../.config .
  Apply your patch
  chmod +x ./autogen.sh ./version.sh 
  ./autogen.sh 
  chmod +x ./configure 
  cp /usr/share/misc/config.{sub,guess} tools/
  chmod +x tools/config.{sub,guess}

This produces the tree which I would check in.  I then ran:

  ./configure 
  (make -j4 && echo ok.) 2>&1 | tee ../log

This did not work correctly.  It failed like this:

  [ -d /u/iwj/work/xen-unstable-tools.hg/dist/install/boot ] || install -d -m0755 -p /u/iwj/work/xen-unstable-tools.hg/dist/install/boot
  install: cannot create directory `/u/iwj/work/xen-unstable-tools.hg/dist': Not a directory
  make[2]: *** [_install] Error 1
  make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/xen'
  make[1]: *** [install] Error 2
  make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/xen'
  make: *** [install-xen] Error 2
  make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/docs/xen-api'
  rm -f *.aux *.dvi *.bbl *.blg *.glo *.idx *.ilg *.log *.ind *.toc
  rm -rf /u/iwj/work/xen-unstable-tools.hg/dist/install/usr/share/doc/xen
  install -d -m0755 -p /u/iwj/work/xen-unstable-tools.hg/dist/install/usr/share/doc/xen
  install: cannot create directory `/u/iwj/work/xen-unstable-tools.hg/dist': Not a directory
  make[1]: *** [install] Error 1
  make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/docs'

I looked at "dist" and it is indeed a file, not a directory.  It
contains a copy of install.sh.

My .config contains this:

  CONFIG_QEMU=/u/iwj/work/1/qemu-iwj.git
  QEMU_UPSTREAM_URL=/u/iwj/work/1/qemu-upstream-unstable.git

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 12:51:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 12:51:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpBP-000058-94; Tue, 21 Feb 2012 12:51: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 1RzpBN-00004v-TU
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:51:02 +0000
Received: from [85.158.139.83:37440] by server-10.bemta-5.messagelabs.com id
	48/2C-07861-333934F4; Tue, 21 Feb 2012 12:50:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329828659!15985647!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16792 invoked from network); 21 Feb 2012 12:50:59 -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;
	21 Feb 2012 12:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10842593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:50:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 12:50:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzpBA-0008Dz-1F; Tue, 21 Feb 2012 12:50:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzpB9-0008Jf-WB;
	Tue, 21 Feb 2012 12:50:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.37671.962922.464807@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 12:50:47 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
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 v7] build: add autoconf to replace custom
 checks in tools/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

Roger Pau Monne writes ("[PATCH v7] build: add autoconf to replace custom checks in tools/check"):
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script, config/Tools.mk
> and config.h.
> 
> conf/Tools.mk is included by tools/Rules.mk, and contains most of the
> options previously defined in .config, that can now be set passing
> parameters or defining environment variables when executing configure
> script.
> 
> config.h is only used by libxl/xl to detect yajl_version.h.

Thanks.  Unfortunately this doesn't seem to work for me.  What I did
was:

  hg clean --all && cp ../.config .
  Apply your patch
  chmod +x ./autogen.sh ./version.sh 
  ./autogen.sh 
  chmod +x ./configure 
  cp /usr/share/misc/config.{sub,guess} tools/
  chmod +x tools/config.{sub,guess}

This produces the tree which I would check in.  I then ran:

  ./configure 
  (make -j4 && echo ok.) 2>&1 | tee ../log

This did not work correctly.  It failed like this:

  [ -d /u/iwj/work/xen-unstable-tools.hg/dist/install/boot ] || install -d -m0755 -p /u/iwj/work/xen-unstable-tools.hg/dist/install/boot
  install: cannot create directory `/u/iwj/work/xen-unstable-tools.hg/dist': Not a directory
  make[2]: *** [_install] Error 1
  make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/xen'
  make[1]: *** [install] Error 2
  make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/xen'
  make: *** [install-xen] Error 2
  make[2]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/docs/xen-api'
  rm -f *.aux *.dvi *.bbl *.blg *.glo *.idx *.ilg *.log *.ind *.toc
  rm -rf /u/iwj/work/xen-unstable-tools.hg/dist/install/usr/share/doc/xen
  install -d -m0755 -p /u/iwj/work/xen-unstable-tools.hg/dist/install/usr/share/doc/xen
  install: cannot create directory `/u/iwj/work/xen-unstable-tools.hg/dist': Not a directory
  make[1]: *** [install] Error 1
  make[1]: Leaving directory `/u/iwj/work/xen-unstable-tools.hg/docs'

I looked at "dist" and it is indeed a file, not a directory.  It
contains a copy of install.sh.

My .config contains this:

  CONFIG_QEMU=/u/iwj/work/1/qemu-iwj.git
  QEMU_UPSTREAM_URL=/u/iwj/work/1/qemu-upstream-unstable.git

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpJv-0000O9-Ex; Tue, 21 Feb 2012 12:59:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzpJt-0000Nv-P0
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:59:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329829183!15196209!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27071 invoked from network); 21 Feb 2012 12:59:43 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:59:43 -0000
Received: by wibhi20 with SMTP id hi20so3445969wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:59:43 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr32093791wib.3.1329829183295
	(num_hops = 1); Tue, 21 Feb 2012 04:59:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=OzlbE2qv3zGg+WDt5+//HoPYzogbqofGPlXqhj0ioYw=;
	b=jfY3ZTni85eYV2ESSpYR4I73hTZ6Tu+nD2unufpWrcjNYDk9qGxbA1UMX7N3Gl5DG6
	7AgsQNu0XSw9lmfM61Q/iKyF+D3tfEGT+2oUrCoL5wFjVzGWRkSLAm90XpkTeoLnzmrE
	qsd9C3NJV9Sotu3WX8/Zi5LcVF0Jsx8mwB/UA=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr26770185wib.3.1329829183213; Tue,
	21 Feb 2012 04:59:43 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 04:59:43 -0800 (PST)
In-Reply-To: <20291.37671.962922.464807@mariner.uk.xensource.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 13:59:43 +0100
X-Google-Sender-Auth: 9OM8GCVVlyphHg5ijwlDqK3lsns
Message-ID: <CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
	checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY3XSBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJl
cGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVjayIpOgo+PiBBZGRlZCBhdXRvdG9vbHMg
bWFnaWMgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCj4+IGNo
ZWNrcyBoYXZlIGJlZW4gcG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9u
ZXMgaGF2ZQo+PiBiZWVuIGFkZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcg
YXV0b3NjYW4pLiBUd28gZmlsZXMgYXJlCj4+IGNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVj
dXRpbmcgY29uZmlndXJlIHNjcmlwdCwgY29uZmlnL1Rvb2xzLm1rCj4+IGFuZCBjb25maWcuaC4K
Pj4KPj4gY29uZi9Ub29scy5tayBpcyBpbmNsdWRlZCBieSB0b29scy9SdWxlcy5taywgYW5kIGNv
bnRhaW5zIG1vc3Qgb2YgdGhlCj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZpbmVkIGluIC5jb25m
aWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+PiBwYXJhbWV0ZXJzIG9yIGRlZmluaW5n
IGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1cmUKPj4gc2NyaXB0
Lgo+Pgo+PiBjb25maWcuaCBpcyBvbmx5IHVzZWQgYnkgbGlieGwveGwgdG8gZGV0ZWN0IHlhamxf
dmVyc2lvbi5oLgo+Cj4gVGhhbmtzLiDCoFVuZm9ydHVuYXRlbHkgdGhpcyBkb2Vzbid0IHNlZW0g
dG8gd29yayBmb3IgbWUuIMKgV2hhdCBJIGRpZAo+IHdhczoKPgo+IMKgaGcgY2xlYW4gLS1hbGwg
JiYgY3AgLi4vLmNvbmZpZyAuCj4gwqBBcHBseSB5b3VyIHBhdGNoCj4gwqBjaG1vZCAreCAuL2F1
dG9nZW4uc2ggLi92ZXJzaW9uLnNoCj4gwqAuL2F1dG9nZW4uc2gKPiDCoGNobW9kICt4IC4vY29u
ZmlndXJlCj4gwqBjcCAvdXNyL3NoYXJlL21pc2MvY29uZmlnLntzdWIsZ3Vlc3N9IHRvb2xzLwo+
IMKgY2htb2QgK3ggdG9vbHMvY29uZmlnLntzdWIsZ3Vlc3N9Cj4KPiBUaGlzIHByb2R1Y2VzIHRo
ZSB0cmVlIHdoaWNoIEkgd291bGQgY2hlY2sgaW4uIMKgSSB0aGVuIHJhbjoKPgo+IMKgLi9jb25m
aWd1cmUKPiDCoChtYWtlIC1qNCAmJiBlY2hvIG9rLikgMj4mMSB8IHRlZSAuLi9sb2cKPgo+IFRo
aXMgZGlkIG5vdCB3b3JrIGNvcnJlY3RseS4gwqBJdCBmYWlsZWQgbGlrZSB0aGlzOgo+Cj4gwqBb
IC1kIC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5oZy9kaXN0L2luc3RhbGwvYm9vdCBd
IHx8IGluc3RhbGwgLWQgLW0wNzU1IC1wIC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5o
Zy9kaXN0L2luc3RhbGwvYm9vdAo+IMKgaW5zdGFsbDogY2Fubm90IGNyZWF0ZSBkaXJlY3Rvcnkg
YC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5oZy9kaXN0JzogTm90IGEgZGlyZWN0b3J5
Cj4gwqBtYWtlWzJdOiAqKiogW19pbnN0YWxsXSBFcnJvciAxCj4gwqBtYWtlWzJdOiBMZWF2aW5n
IGRpcmVjdG9yeSBgL3UvaXdqL3dvcmsveGVuLXVuc3RhYmxlLXRvb2xzLmhnL3hlbicKPiDCoG1h
a2VbMV06ICoqKiBbaW5zdGFsbF0gRXJyb3IgMgo+IMKgbWFrZVsxXTogTGVhdmluZyBkaXJlY3Rv
cnkgYC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5oZy94ZW4nCj4gwqBtYWtlOiAqKiog
W2luc3RhbGwteGVuXSBFcnJvciAyCj4gwqBtYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Uv
aXdqL3dvcmsveGVuLXVuc3RhYmxlLXRvb2xzLmhnL2RvY3MveGVuLWFwaScKPiDCoHJtIC1mICou
YXV4ICouZHZpICouYmJsICouYmxnICouZ2xvICouaWR4ICouaWxnICoubG9nICouaW5kICoudG9j
Cj4gwqBybSAtcmYgL3UvaXdqL3dvcmsveGVuLXVuc3RhYmxlLXRvb2xzLmhnL2Rpc3QvaW5zdGFs
bC91c3Ivc2hhcmUvZG9jL3hlbgo+IMKgaW5zdGFsbCAtZCAtbTA3NTUgLXAgL3UvaXdqL3dvcmsv
eGVuLXVuc3RhYmxlLXRvb2xzLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvZG9jL3hlbgo+IMKg
aW5zdGFsbDogY2Fubm90IGNyZWF0ZSBkaXJlY3RvcnkgYC91L2l3ai93b3JrL3hlbi11bnN0YWJs
ZS10b29scy5oZy9kaXN0JzogTm90IGEgZGlyZWN0b3J5Cj4gwqBtYWtlWzFdOiAqKiogW2luc3Rh
bGxdIEVycm9yIDEKPiDCoG1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvdS9pd2ovd29yay94
ZW4tdW5zdGFibGUtdG9vbHMuaGcvZG9jcycKPgo+IEkgbG9va2VkIGF0ICJkaXN0IiBhbmQgaXQg
aXMgaW5kZWVkIGEgZmlsZSwgbm90IGEgZGlyZWN0b3J5LiDCoEl0Cj4gY29udGFpbnMgYSBjb3B5
IG9mIGluc3RhbGwuc2guCj4KPiBNeSAuY29uZmlnIGNvbnRhaW5zIHRoaXM6Cj4KPiDCoENPTkZJ
R19RRU1VPS91L2l3ai93b3JrLzEvcWVtdS1pd2ouZ2l0Cj4gwqBRRU1VX1VQU1RSRUFNX1VSTD0v
dS9pd2ovd29yay8xL3FlbXUtdXBzdHJlYW0tdW5zdGFibGUuZ2l0CgpJJ20gZG9pbmcgYSBmcmVz
aCBjaGVja291dCBhbmQgSSB3aWxsIHRyeSB0byByZXByb2R1Y2UgdGhlIGVycm9yLApmb2xsb3dp
bmcgdGhlIHNhbWUgc3RlcHMuCgo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpJv-0000O9-Ex; Tue, 21 Feb 2012 12:59:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzpJt-0000Nv-P0
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 12:59:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329829183!15196209!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27071 invoked from network); 21 Feb 2012 12:59:43 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 12:59:43 -0000
Received: by wibhi20 with SMTP id hi20so3445969wib.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 04:59:43 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr32093791wib.3.1329829183295
	(num_hops = 1); Tue, 21 Feb 2012 04:59:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=OzlbE2qv3zGg+WDt5+//HoPYzogbqofGPlXqhj0ioYw=;
	b=jfY3ZTni85eYV2ESSpYR4I73hTZ6Tu+nD2unufpWrcjNYDk9qGxbA1UMX7N3Gl5DG6
	7AgsQNu0XSw9lmfM61Q/iKyF+D3tfEGT+2oUrCoL5wFjVzGWRkSLAm90XpkTeoLnzmrE
	qsd9C3NJV9Sotu3WX8/Zi5LcVF0Jsx8mwB/UA=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr26770185wib.3.1329829183213; Tue,
	21 Feb 2012 04:59:43 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 04:59:43 -0800 (PST)
In-Reply-To: <20291.37671.962922.464807@mariner.uk.xensource.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 13:59:43 +0100
X-Google-Sender-Auth: 9OM8GCVVlyphHg5ijwlDqK3lsns
Message-ID: <CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
	checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY3XSBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJl
cGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVjayIpOgo+PiBBZGRlZCBhdXRvdG9vbHMg
bWFnaWMgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCj4+IGNo
ZWNrcyBoYXZlIGJlZW4gcG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9u
ZXMgaGF2ZQo+PiBiZWVuIGFkZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcg
YXV0b3NjYW4pLiBUd28gZmlsZXMgYXJlCj4+IGNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVj
dXRpbmcgY29uZmlndXJlIHNjcmlwdCwgY29uZmlnL1Rvb2xzLm1rCj4+IGFuZCBjb25maWcuaC4K
Pj4KPj4gY29uZi9Ub29scy5tayBpcyBpbmNsdWRlZCBieSB0b29scy9SdWxlcy5taywgYW5kIGNv
bnRhaW5zIG1vc3Qgb2YgdGhlCj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZpbmVkIGluIC5jb25m
aWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+PiBwYXJhbWV0ZXJzIG9yIGRlZmluaW5n
IGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1cmUKPj4gc2NyaXB0
Lgo+Pgo+PiBjb25maWcuaCBpcyBvbmx5IHVzZWQgYnkgbGlieGwveGwgdG8gZGV0ZWN0IHlhamxf
dmVyc2lvbi5oLgo+Cj4gVGhhbmtzLiDCoFVuZm9ydHVuYXRlbHkgdGhpcyBkb2Vzbid0IHNlZW0g
dG8gd29yayBmb3IgbWUuIMKgV2hhdCBJIGRpZAo+IHdhczoKPgo+IMKgaGcgY2xlYW4gLS1hbGwg
JiYgY3AgLi4vLmNvbmZpZyAuCj4gwqBBcHBseSB5b3VyIHBhdGNoCj4gwqBjaG1vZCAreCAuL2F1
dG9nZW4uc2ggLi92ZXJzaW9uLnNoCj4gwqAuL2F1dG9nZW4uc2gKPiDCoGNobW9kICt4IC4vY29u
ZmlndXJlCj4gwqBjcCAvdXNyL3NoYXJlL21pc2MvY29uZmlnLntzdWIsZ3Vlc3N9IHRvb2xzLwo+
IMKgY2htb2QgK3ggdG9vbHMvY29uZmlnLntzdWIsZ3Vlc3N9Cj4KPiBUaGlzIHByb2R1Y2VzIHRo
ZSB0cmVlIHdoaWNoIEkgd291bGQgY2hlY2sgaW4uIMKgSSB0aGVuIHJhbjoKPgo+IMKgLi9jb25m
aWd1cmUKPiDCoChtYWtlIC1qNCAmJiBlY2hvIG9rLikgMj4mMSB8IHRlZSAuLi9sb2cKPgo+IFRo
aXMgZGlkIG5vdCB3b3JrIGNvcnJlY3RseS4gwqBJdCBmYWlsZWQgbGlrZSB0aGlzOgo+Cj4gwqBb
IC1kIC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5oZy9kaXN0L2luc3RhbGwvYm9vdCBd
IHx8IGluc3RhbGwgLWQgLW0wNzU1IC1wIC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5o
Zy9kaXN0L2luc3RhbGwvYm9vdAo+IMKgaW5zdGFsbDogY2Fubm90IGNyZWF0ZSBkaXJlY3Rvcnkg
YC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5oZy9kaXN0JzogTm90IGEgZGlyZWN0b3J5
Cj4gwqBtYWtlWzJdOiAqKiogW19pbnN0YWxsXSBFcnJvciAxCj4gwqBtYWtlWzJdOiBMZWF2aW5n
IGRpcmVjdG9yeSBgL3UvaXdqL3dvcmsveGVuLXVuc3RhYmxlLXRvb2xzLmhnL3hlbicKPiDCoG1h
a2VbMV06ICoqKiBbaW5zdGFsbF0gRXJyb3IgMgo+IMKgbWFrZVsxXTogTGVhdmluZyBkaXJlY3Rv
cnkgYC91L2l3ai93b3JrL3hlbi11bnN0YWJsZS10b29scy5oZy94ZW4nCj4gwqBtYWtlOiAqKiog
W2luc3RhbGwteGVuXSBFcnJvciAyCj4gwqBtYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Uv
aXdqL3dvcmsveGVuLXVuc3RhYmxlLXRvb2xzLmhnL2RvY3MveGVuLWFwaScKPiDCoHJtIC1mICou
YXV4ICouZHZpICouYmJsICouYmxnICouZ2xvICouaWR4ICouaWxnICoubG9nICouaW5kICoudG9j
Cj4gwqBybSAtcmYgL3UvaXdqL3dvcmsveGVuLXVuc3RhYmxlLXRvb2xzLmhnL2Rpc3QvaW5zdGFs
bC91c3Ivc2hhcmUvZG9jL3hlbgo+IMKgaW5zdGFsbCAtZCAtbTA3NTUgLXAgL3UvaXdqL3dvcmsv
eGVuLXVuc3RhYmxlLXRvb2xzLmhnL2Rpc3QvaW5zdGFsbC91c3Ivc2hhcmUvZG9jL3hlbgo+IMKg
aW5zdGFsbDogY2Fubm90IGNyZWF0ZSBkaXJlY3RvcnkgYC91L2l3ai93b3JrL3hlbi11bnN0YWJs
ZS10b29scy5oZy9kaXN0JzogTm90IGEgZGlyZWN0b3J5Cj4gwqBtYWtlWzFdOiAqKiogW2luc3Rh
bGxdIEVycm9yIDEKPiDCoG1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvdS9pd2ovd29yay94
ZW4tdW5zdGFibGUtdG9vbHMuaGcvZG9jcycKPgo+IEkgbG9va2VkIGF0ICJkaXN0IiBhbmQgaXQg
aXMgaW5kZWVkIGEgZmlsZSwgbm90IGEgZGlyZWN0b3J5LiDCoEl0Cj4gY29udGFpbnMgYSBjb3B5
IG9mIGluc3RhbGwuc2guCj4KPiBNeSAuY29uZmlnIGNvbnRhaW5zIHRoaXM6Cj4KPiDCoENPTkZJ
R19RRU1VPS91L2l3ai93b3JrLzEvcWVtdS1pd2ouZ2l0Cj4gwqBRRU1VX1VQU1RSRUFNX1VSTD0v
dS9pd2ovd29yay8xL3FlbXUtdXBzdHJlYW0tdW5zdGFibGUuZ2l0CgpJJ20gZG9pbmcgYSBmcmVz
aCBjaGVja291dCBhbmQgSSB3aWxsIHRyeSB0byByZXByb2R1Y2UgdGhlIGVycm9yLApmb2xsb3dp
bmcgdGhlIHNhbWUgc3RlcHMuCgo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzpif-00011D-Tw; Tue, 21 Feb 2012 13:25:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzpie-00010s-KW
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:25:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329830718!5065457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3060 invoked from network); 21 Feb 2012 13:25:18 -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;
	21 Feb 2012 13:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:25:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 13:25:18 +0000
Date: Tue, 21 Feb 2012 13:30:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329824022.25232.103.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1202211330150.23091@kaball-desktop>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 21 Feb 2012, Ian Campbell wrote:
> On Mon, 2012-02-20 at 10:37 +0000, Christoph Egger wrote:
> > On 02/09/12 12:59, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> > >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> > >> This fixes seabios build error
> > >> 'python not found'
> > >> along with the patches from Kevin O'Connor.
> > >>
> > >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> > >
> > > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> > >
> > 
> > Please apply this patch and update SeaBIOS.
> > Keven O'Connors patches went upstream on Feb 8th.
> 
> I was hoping to track SeaBIOS stable branches so I am reluctant to
> simply update to a random commit on the development branch.
> 
> Currently we are tracking the upstream 1.6.3-stable branch in the
> xen-unstable branch of our seabios.git. In hindsight this might have
> been an error since it means that our branch will only be non-rebasing
> until we switch to 1.6.4 or 1.7.0 (whichever comes next).
> 
> I'm not sure how best to approach this, obviously I could create a
> 1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
> what approach I should take when the upstream latest-stable branch
> changes first though.

Have you tried to ask Kevin to backport the commit to stable?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzpif-00011D-Tw; Tue, 21 Feb 2012 13:25:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rzpie-00010s-KW
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:25:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329830718!5065457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3060 invoked from network); 21 Feb 2012 13:25:18 -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;
	21 Feb 2012 13:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:25:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 13:25:18 +0000
Date: Tue, 21 Feb 2012 13:30:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329824022.25232.103.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1202211330150.23091@kaball-desktop>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 21 Feb 2012, Ian Campbell wrote:
> On Mon, 2012-02-20 at 10:37 +0000, Christoph Egger wrote:
> > On 02/09/12 12:59, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> > >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> > >> This fixes seabios build error
> > >> 'python not found'
> > >> along with the patches from Kevin O'Connor.
> > >>
> > >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> > >
> > > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> > >
> > 
> > Please apply this patch and update SeaBIOS.
> > Keven O'Connors patches went upstream on Feb 8th.
> 
> I was hoping to track SeaBIOS stable branches so I am reluctant to
> simply update to a random commit on the development branch.
> 
> Currently we are tracking the upstream 1.6.3-stable branch in the
> xen-unstable branch of our seabios.git. In hindsight this might have
> been an error since it means that our branch will only be non-rebasing
> until we switch to 1.6.4 or 1.7.0 (whichever comes next).
> 
> I'm not sure how best to approach this, obviously I could create a
> 1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
> what approach I should take when the upstream latest-stable branch
> changes first though.

Have you tried to ask Kevin to backport the commit to stable?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvT-0001KY-7Y; Tue, 21 Feb 2012 13:38:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvR-0001JW-FN
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23972 invoked from network); 21 Feb 2012 13:38:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753394"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-9L;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:06 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 10] Allow user to configure credit
	scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series introduces hypercalls to allow the timeslice
and ratelimit parameters of the credit scheduler to be read and
tweaked, and plumbed all the way through to the xl command-line.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvT-0001KY-7Y; Tue, 21 Feb 2012 13:38:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvR-0001JW-FN
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23972 invoked from network); 21 Feb 2012 13:38:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753394"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-9L;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:06 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 10] Allow user to configure credit
	scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series introduces hypercalls to allow the timeslice
and ratelimit parameters of the credit scheduler to be read and
tweaked, and plumbed all the way through to the xl command-line.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvT-0001Kp-K8; Tue, 21 Feb 2012 13:38:39 +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 1RzpvR-0001Jc-SO
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329831480!57610672!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29962 invoked from network); 21 Feb 2012 13:38:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753404"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:29 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-C3;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 5e3ca9be617e7c82d305bffd2b8d000b5b8ae22f
Message-ID: <5e3ca9be617e7c82d305.1329831251@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:11 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 10] libxc: Implement SCHEDOP sysctl for
	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 4ce1812b0249 -r 5e3ca9be617e tools/libxc/xc_csched.c
--- a/tools/libxc/xc_csched.c	Tue Feb 21 12:14:18 2012 +0000
+++ b/tools/libxc/xc_csched.c	Tue Feb 21 12:14:32 2012 +0000
@@ -61,3 +61,47 @@ xc_sched_credit_domain_get(
 
     return err;
 }
+
+int
+xc_sched_credit_param_set(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
+
+    sysctl.u.scheduler_op.u.sched_credit = *schedule;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
+
+int
+xc_sched_credit_param_get(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
diff -r 4ce1812b0249 -r 5e3ca9be617e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Tue Feb 21 12:14:18 2012 +0000
+++ b/tools/libxc/xenctrl.h	Tue Feb 21 12:14:32 2012 +0000
@@ -668,7 +668,12 @@ int xc_sched_credit_domain_set(xc_interf
 int xc_sched_credit_domain_get(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit *sdom);
-
+int xc_sched_credit_param_set(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
+int xc_sched_credit_param_get(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
 int xc_sched_credit2_domain_set(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit2 *sdom);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvT-0001Kp-K8; Tue, 21 Feb 2012 13:38:39 +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 1RzpvR-0001Jc-SO
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329831480!57610672!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29962 invoked from network); 21 Feb 2012 13:38:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753404"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:29 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-C3;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 5e3ca9be617e7c82d305bffd2b8d000b5b8ae22f
Message-ID: <5e3ca9be617e7c82d305.1329831251@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:11 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 10] libxc: Implement SCHEDOP sysctl for
	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 4ce1812b0249 -r 5e3ca9be617e tools/libxc/xc_csched.c
--- a/tools/libxc/xc_csched.c	Tue Feb 21 12:14:18 2012 +0000
+++ b/tools/libxc/xc_csched.c	Tue Feb 21 12:14:32 2012 +0000
@@ -61,3 +61,47 @@ xc_sched_credit_domain_get(
 
     return err;
 }
+
+int
+xc_sched_credit_param_set(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
+
+    sysctl.u.scheduler_op.u.sched_credit = *schedule;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
+
+int
+xc_sched_credit_param_get(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
diff -r 4ce1812b0249 -r 5e3ca9be617e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Tue Feb 21 12:14:18 2012 +0000
+++ b/tools/libxc/xenctrl.h	Tue Feb 21 12:14:32 2012 +0000
@@ -668,7 +668,12 @@ int xc_sched_credit_domain_set(xc_interf
 int xc_sched_credit_domain_get(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit *sdom);
-
+int xc_sched_credit_param_set(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
+int xc_sched_credit_param_get(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
 int xc_sched_credit2_domain_set(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit2 *sdom);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvP-0001Ji-9I; Tue, 21 Feb 2012 13:38:35 +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 1RzpvO-0001JY-43
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329831480!57610672!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29875 invoked from network); 21 Feb 2012 13:38:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753399"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-BC;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4ce1812b024997b9684b7d6cf1984dbad01a1379
Message-ID: <4ce1812b024997b9684b.1329831250@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:10 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 10] xen: Implement SCHEDOP sysctl for
	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow tslice_ms and ratelimit_us to be modified.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 38e532667238 -r 4ce1812b0249 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Feb 21 11:44:19 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Feb 21 12:14:18 2012 +0000
@@ -833,6 +833,36 @@ csched_dom_cntl(
     return 0;
 }
 
+static int
+csched_sys_cntl(const struct scheduler *ops,
+                        struct xen_sysctl_scheduler_op *sc)
+{
+    int rc = -EINVAL;
+    xen_sysctl_credit_schedule_t *params = &sc->u.sched_credit;
+    struct csched_private *prv = CSCHED_PRIV(ops);
+
+    switch ( sc->cmd )
+    {
+    case XEN_SYSCTL_SCHEDOP_putinfo:
+        if (params->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+            || params->tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN 
+            || params->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+            || params->ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN 
+            || MICROSECS(params->ratelimit_us) > MILLISECS(params->tslice_ms) )
+                goto out;
+        prv->tslice_ms = params->tslice_ms;
+        prv->ratelimit_us = params->ratelimit_us;
+        /* FALLTHRU */
+    case XEN_SYSCTL_SCHEDOP_getinfo:
+        params->tslice_ms = prv->tslice_ms;
+        params->ratelimit_us = prv->ratelimit_us;
+        rc = 0;
+        break;
+    }
+    out:
+    return rc;
+}
+
 static void *
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
 {
@@ -1566,6 +1596,28 @@ csched_init(struct scheduler *ops)
     INIT_LIST_HEAD(&prv->active_sdom);
     prv->master = UINT_MAX;
 
+    if ( sched_credit_tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+         || sched_credit_tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN )
+    {
+        printk("WARNING: sched_credit_tslice_ms outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_CSCHED_TSLICE_MIN,
+               XEN_SYSCTL_CSCHED_TSLICE_MAX,
+               CSCHED_DEFAULT_TSLICE_MS);
+        sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
+    }
+
+    if ( sched_ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+         || sched_ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN )
+    {
+        printk("WARNING: sched_ratelimit_us outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+               XEN_SYSCTL_SCHED_RATELIMIT_MAX,
+               SCHED_DEFAULT_RATELIMIT_US);
+        sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
+    }
+
     prv->tslice_ms = sched_credit_tslice_ms;
     prv->ticks_per_tslice = CSCHED_TICKS_PER_TSLICE;
     if ( prv->tslice_ms < prv->ticks_per_tslice )
@@ -1641,6 +1693,7 @@ const struct scheduler sched_credit_def 
     .yield          = csched_vcpu_yield,
 
     .adjust         = csched_dom_cntl,
+    .adjust_global  = csched_sys_cntl,
 
     .pick_cpu       = csched_cpu_pick,
     .do_schedule    = csched_schedule,
diff -r 38e532667238 -r 4ce1812b0249 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h	Tue Feb 21 11:44:19 2012 +0000
+++ b/xen/include/public/sysctl.h	Tue Feb 21 12:14:18 2012 +0000
@@ -564,6 +564,19 @@ struct xen_sysctl_arinc653_schedule {
 typedef struct xen_sysctl_arinc653_schedule xen_sysctl_arinc653_schedule_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_arinc653_schedule_t);
 
+struct xen_sysctl_credit_schedule {
+    /* Length of timeslice in milliseconds */
+#define XEN_SYSCTL_CSCHED_TSLICE_MAX 1000
+#define XEN_SYSCTL_CSCHED_TSLICE_MIN 1
+    unsigned tslice_ms;
+    /* Rate limit (minimum timeslice) in microseconds */
+#define XEN_SYSCTL_SCHED_RATELIMIT_MAX 500000
+#define XEN_SYSCTL_SCHED_RATELIMIT_MIN 100
+    unsigned ratelimit_us;
+};
+typedef struct xen_sysctl_credit_schedule xen_sysctl_credit_schedule_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_credit_schedule_t);
+
 /* XEN_SYSCTL_scheduler_op */
 /* Set or get info? */
 #define XEN_SYSCTL_SCHEDOP_putinfo 0
@@ -576,6 +589,7 @@ struct xen_sysctl_scheduler_op {
         struct xen_sysctl_sched_arinc653 {
             XEN_GUEST_HANDLE_64(xen_sysctl_arinc653_schedule_t) schedule;
         } sched_arinc653;
+        struct xen_sysctl_credit_schedule sched_credit;
     } u;
 };
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvP-0001Ji-9I; Tue, 21 Feb 2012 13:38:35 +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 1RzpvO-0001JY-43
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329831480!57610672!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29875 invoked from network); 21 Feb 2012 13:38:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753399"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-BC;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4ce1812b024997b9684b7d6cf1984dbad01a1379
Message-ID: <4ce1812b024997b9684b.1329831250@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:10 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 10] xen: Implement SCHEDOP sysctl for
	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow tslice_ms and ratelimit_us to be modified.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 38e532667238 -r 4ce1812b0249 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Feb 21 11:44:19 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Feb 21 12:14:18 2012 +0000
@@ -833,6 +833,36 @@ csched_dom_cntl(
     return 0;
 }
 
+static int
+csched_sys_cntl(const struct scheduler *ops,
+                        struct xen_sysctl_scheduler_op *sc)
+{
+    int rc = -EINVAL;
+    xen_sysctl_credit_schedule_t *params = &sc->u.sched_credit;
+    struct csched_private *prv = CSCHED_PRIV(ops);
+
+    switch ( sc->cmd )
+    {
+    case XEN_SYSCTL_SCHEDOP_putinfo:
+        if (params->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+            || params->tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN 
+            || params->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+            || params->ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN 
+            || MICROSECS(params->ratelimit_us) > MILLISECS(params->tslice_ms) )
+                goto out;
+        prv->tslice_ms = params->tslice_ms;
+        prv->ratelimit_us = params->ratelimit_us;
+        /* FALLTHRU */
+    case XEN_SYSCTL_SCHEDOP_getinfo:
+        params->tslice_ms = prv->tslice_ms;
+        params->ratelimit_us = prv->ratelimit_us;
+        rc = 0;
+        break;
+    }
+    out:
+    return rc;
+}
+
 static void *
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
 {
@@ -1566,6 +1596,28 @@ csched_init(struct scheduler *ops)
     INIT_LIST_HEAD(&prv->active_sdom);
     prv->master = UINT_MAX;
 
+    if ( sched_credit_tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+         || sched_credit_tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN )
+    {
+        printk("WARNING: sched_credit_tslice_ms outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_CSCHED_TSLICE_MIN,
+               XEN_SYSCTL_CSCHED_TSLICE_MAX,
+               CSCHED_DEFAULT_TSLICE_MS);
+        sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
+    }
+
+    if ( sched_ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+         || sched_ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN )
+    {
+        printk("WARNING: sched_ratelimit_us outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+               XEN_SYSCTL_SCHED_RATELIMIT_MAX,
+               SCHED_DEFAULT_RATELIMIT_US);
+        sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
+    }
+
     prv->tslice_ms = sched_credit_tslice_ms;
     prv->ticks_per_tslice = CSCHED_TICKS_PER_TSLICE;
     if ( prv->tslice_ms < prv->ticks_per_tslice )
@@ -1641,6 +1693,7 @@ const struct scheduler sched_credit_def 
     .yield          = csched_vcpu_yield,
 
     .adjust         = csched_dom_cntl,
+    .adjust_global  = csched_sys_cntl,
 
     .pick_cpu       = csched_cpu_pick,
     .do_schedule    = csched_schedule,
diff -r 38e532667238 -r 4ce1812b0249 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h	Tue Feb 21 11:44:19 2012 +0000
+++ b/xen/include/public/sysctl.h	Tue Feb 21 12:14:18 2012 +0000
@@ -564,6 +564,19 @@ struct xen_sysctl_arinc653_schedule {
 typedef struct xen_sysctl_arinc653_schedule xen_sysctl_arinc653_schedule_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_arinc653_schedule_t);
 
+struct xen_sysctl_credit_schedule {
+    /* Length of timeslice in milliseconds */
+#define XEN_SYSCTL_CSCHED_TSLICE_MAX 1000
+#define XEN_SYSCTL_CSCHED_TSLICE_MIN 1
+    unsigned tslice_ms;
+    /* Rate limit (minimum timeslice) in microseconds */
+#define XEN_SYSCTL_SCHED_RATELIMIT_MAX 500000
+#define XEN_SYSCTL_SCHED_RATELIMIT_MIN 100
+    unsigned ratelimit_us;
+};
+typedef struct xen_sysctl_credit_schedule xen_sysctl_credit_schedule_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_credit_schedule_t);
+
 /* XEN_SYSCTL_scheduler_op */
 /* Set or get info? */
 #define XEN_SYSCTL_SCHEDOP_putinfo 0
@@ -576,6 +589,7 @@ struct xen_sysctl_scheduler_op {
         struct xen_sysctl_sched_arinc653 {
             XEN_GUEST_HANDLE_64(xen_sysctl_arinc653_schedule_t) schedule;
         } sched_arinc653;
+        struct xen_sysctl_credit_schedule sched_credit;
     } u;
 };
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvX-0001Mf-Nj; Tue, 21 Feb 2012 13:38:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvW-0001Jv-21
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24303 invoked from network); 21 Feb 2012 13:38:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753420"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-Cw;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 127b33c09db2bcf9b11a5795e47562fd9599b6f4
Message-ID: <127b33c09db2bcf9b11a.1329831253@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to include
	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for introducing a schedule parameter-based structure,
rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
@@ -2975,7 +2975,7 @@ int libxl_get_sched_id(libxl_ctx *ctx)
     return sched;
 }
 
-int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     int rc;
@@ -2992,7 +2992,7 @@ int libxl_sched_credit_domain_get(libxl_
     return 0;
 }
 
-int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     xc_domaininfo_t domaininfo;
@@ -3033,7 +3033,7 @@ int libxl_sched_credit_domain_set(libxl_
 }
 
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     int rc;
@@ -3051,7 +3051,7 @@ int libxl_sched_credit2_domain_get(libxl
 }
 
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     xc_domaininfo_t domaininfo;
@@ -3086,7 +3086,7 @@ int libxl_sched_credit2_domain_set(libxl
 }
 
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     uint64_t period;
     uint64_t slice;
@@ -3112,7 +3112,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 }
 
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     xc_domaininfo_t domaininfo;
     int rc;
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.h	Tue Feb 21 12:14:32 2012 +0000
@@ -588,17 +588,17 @@ int libxl_get_sched_id(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Feb 21 12:14:32 2012 +0000
@@ -390,16 +390,16 @@ libxl_cputopology = Struct("cputopology"
     ("node", uint32),
     ])
 
-libxl_sched_credit = Struct("sched_credit", [
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
 
-libxl_sched_credit2 = Struct("sched_credit2", [
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)
 
-libxl_sched_sedf = Struct("sched_sedf", [
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
     ("period", integer),
     ("slice", integer),
     ("latency", integer),
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:14:32 2012 +0000
@@ -3913,7 +3913,7 @@ int main_sharing(int argc, char **argv)
 }
 
 static int sched_credit_domain_get(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3925,7 +3925,7 @@ static int sched_credit_domain_get(
 }
 
 static int sched_credit_domain_set(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3940,7 +3940,7 @@ static int sched_credit_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -3961,7 +3961,7 @@ static int sched_credit_domain_output(
 }
 
 static int sched_credit2_domain_get(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3973,7 +3973,7 @@ static int sched_credit2_domain_get(
 }
 
 static int sched_credit2_domain_set(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3988,7 +3988,7 @@ static int sched_credit2_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4008,7 +4008,7 @@ static int sched_credit2_domain_output(
 }
 
 static int sched_sedf_domain_get(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4020,7 +4020,7 @@ static int sched_sedf_domain_get(
 }
 
 static int sched_sedf_domain_set(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4035,7 +4035,7 @@ static int sched_sedf_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4116,7 +4116,7 @@ static int sched_domain_output(
 
 int main_sched_credit(int argc, char **argv)
 {
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
@@ -4198,7 +4198,7 @@ int main_sched_credit(int argc, char **a
 
 int main_sched_credit2(int argc, char **argv)
 {
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, opt_w = 0;
@@ -4272,7 +4272,7 @@ int main_sched_credit2(int argc, char **
 
 int main_sched_sedf(int argc, char **argv)
 {
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int period = 0, opt_p = 0;
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Feb 21 12:14:32 2012 +0000
@@ -473,7 +473,7 @@ value stub_xl_sched_credit_domain_get(va
 {
 	CAMLparam1(domid);
 	CAMLlocal1(scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
@@ -483,18 +483,18 @@ value stub_xl_sched_credit_domain_get(va
 		failwith_xl("sched_credit_domain_get", &lg);
 	FREE_CTX();
 
-	scinfo = Val_sched_credit(&gc, &lg, &c_scinfo);
+	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
 	CAMLreturn(scinfo);
 }
 
 value stub_xl_sched_credit_domain_set(value domid, value scinfo)
 {
 	CAMLparam2(domid, scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
-	sched_credit_val(&gc, &lg, &c_scinfo, scinfo);
+	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
 
 	INIT_CTX();
 	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvX-0001Mf-Nj; Tue, 21 Feb 2012 13:38:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvW-0001Jv-21
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24303 invoked from network); 21 Feb 2012 13:38:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753420"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-Cw;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 127b33c09db2bcf9b11a5795e47562fd9599b6f4
Message-ID: <127b33c09db2bcf9b11a.1329831253@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to include
	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for introducing a schedule parameter-based structure,
rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
@@ -2975,7 +2975,7 @@ int libxl_get_sched_id(libxl_ctx *ctx)
     return sched;
 }
 
-int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     int rc;
@@ -2992,7 +2992,7 @@ int libxl_sched_credit_domain_get(libxl_
     return 0;
 }
 
-int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     xc_domaininfo_t domaininfo;
@@ -3033,7 +3033,7 @@ int libxl_sched_credit_domain_set(libxl_
 }
 
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     int rc;
@@ -3051,7 +3051,7 @@ int libxl_sched_credit2_domain_get(libxl
 }
 
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     xc_domaininfo_t domaininfo;
@@ -3086,7 +3086,7 @@ int libxl_sched_credit2_domain_set(libxl
 }
 
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     uint64_t period;
     uint64_t slice;
@@ -3112,7 +3112,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 }
 
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     xc_domaininfo_t domaininfo;
     int rc;
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.h	Tue Feb 21 12:14:32 2012 +0000
@@ -588,17 +588,17 @@ int libxl_get_sched_id(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Feb 21 12:14:32 2012 +0000
@@ -390,16 +390,16 @@ libxl_cputopology = Struct("cputopology"
     ("node", uint32),
     ])
 
-libxl_sched_credit = Struct("sched_credit", [
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
 
-libxl_sched_credit2 = Struct("sched_credit2", [
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)
 
-libxl_sched_sedf = Struct("sched_sedf", [
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
     ("period", integer),
     ("slice", integer),
     ("latency", integer),
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:14:32 2012 +0000
@@ -3913,7 +3913,7 @@ int main_sharing(int argc, char **argv)
 }
 
 static int sched_credit_domain_get(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3925,7 +3925,7 @@ static int sched_credit_domain_get(
 }
 
 static int sched_credit_domain_set(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3940,7 +3940,7 @@ static int sched_credit_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -3961,7 +3961,7 @@ static int sched_credit_domain_output(
 }
 
 static int sched_credit2_domain_get(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3973,7 +3973,7 @@ static int sched_credit2_domain_get(
 }
 
 static int sched_credit2_domain_set(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3988,7 +3988,7 @@ static int sched_credit2_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4008,7 +4008,7 @@ static int sched_credit2_domain_output(
 }
 
 static int sched_sedf_domain_get(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4020,7 +4020,7 @@ static int sched_sedf_domain_get(
 }
 
 static int sched_sedf_domain_set(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4035,7 +4035,7 @@ static int sched_sedf_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4116,7 +4116,7 @@ static int sched_domain_output(
 
 int main_sched_credit(int argc, char **argv)
 {
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
@@ -4198,7 +4198,7 @@ int main_sched_credit(int argc, char **a
 
 int main_sched_credit2(int argc, char **argv)
 {
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, opt_w = 0;
@@ -4272,7 +4272,7 @@ int main_sched_credit2(int argc, char **
 
 int main_sched_sedf(int argc, char **argv)
 {
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int period = 0, opt_p = 0;
diff -r 0f97e5c69eeb -r 127b33c09db2 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Feb 21 12:14:32 2012 +0000
@@ -473,7 +473,7 @@ value stub_xl_sched_credit_domain_get(va
 {
 	CAMLparam1(domid);
 	CAMLlocal1(scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
@@ -483,18 +483,18 @@ value stub_xl_sched_credit_domain_get(va
 		failwith_xl("sched_credit_domain_get", &lg);
 	FREE_CTX();
 
-	scinfo = Val_sched_credit(&gc, &lg, &c_scinfo);
+	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
 	CAMLreturn(scinfo);
 }
 
 value stub_xl_sched_credit_domain_set(value domid, value scinfo)
 {
 	CAMLparam2(domid, scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
-	sched_credit_val(&gc, &lg, &c_scinfo, scinfo);
+	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
 
 	INIT_CTX();
 	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvU-0001Kx-05; Tue, 21 Feb 2012 13:38:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvS-0001JX-Dh
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24034 invoked from network); 21 Feb 2012 13:38:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753396"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-AI;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: c91f3f39e7df66bcd0b642de5b009b9c7df3e39e
Message-ID: <c91f3f39e7df66bcd0b6.1329831248@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 10] xen: Add a #define for the default
	ratelimit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0402fc3aeaf3 -r c91f3f39e7df xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Feb 21 11:25:21 2012 +0000
+++ b/xen/common/schedule.c	Tue Feb 21 11:26:37 2012 +0000
@@ -50,7 +50,7 @@ boolean_param("sched_smt_power_savings",
 /* Default scheduling rate limit: 1ms 
  * The behavior when sched_ratelimit_us is greater than sched_credit_tslice_ms is undefined
  * */
-int sched_ratelimit_us = 1000;
+int sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
 integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
diff -r 0402fc3aeaf3 -r c91f3f39e7df xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Tue Feb 21 11:25:21 2012 +0000
+++ b/xen/include/xen/sched-if.h	Tue Feb 21 11:26:37 2012 +0000
@@ -18,6 +18,7 @@ extern cpumask_t cpupool_free_cpus;
 
 /* Scheduler generic parameters
  * */
+#define SCHED_DEFAULT_RATELIMIT_US 1000
 extern int sched_ratelimit_us;
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvU-0001Kx-05; Tue, 21 Feb 2012 13:38:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvS-0001JX-Dh
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24034 invoked from network); 21 Feb 2012 13:38:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753396"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-AI;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: c91f3f39e7df66bcd0b642de5b009b9c7df3e39e
Message-ID: <c91f3f39e7df66bcd0b6.1329831248@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 10] xen: Add a #define for the default
	ratelimit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0402fc3aeaf3 -r c91f3f39e7df xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Feb 21 11:25:21 2012 +0000
+++ b/xen/common/schedule.c	Tue Feb 21 11:26:37 2012 +0000
@@ -50,7 +50,7 @@ boolean_param("sched_smt_power_savings",
 /* Default scheduling rate limit: 1ms 
  * The behavior when sched_ratelimit_us is greater than sched_credit_tslice_ms is undefined
  * */
-int sched_ratelimit_us = 1000;
+int sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
 integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
diff -r 0402fc3aeaf3 -r c91f3f39e7df xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Tue Feb 21 11:25:21 2012 +0000
+++ b/xen/include/xen/sched-if.h	Tue Feb 21 11:26:37 2012 +0000
@@ -18,6 +18,7 @@ extern cpumask_t cpupool_free_cpus;
 
 /* Scheduler generic parameters
  * */
+#define SCHED_DEFAULT_RATELIMIT_US 1000
 extern int sched_ratelimit_us;
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvW-0001M0-A2; Tue, 21 Feb 2012 13:38:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvV-0001Jq-7o
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:41 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329831511!9289808!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9687 invoked from network); 21 Feb 2012 13:38:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753408"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:29 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-Ak;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 38e53266723815e8445ff25374f7e8aaa9b5af66
Message-ID: <38e53266723815e8445f.1329831249@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 10] xen: Print ratelimit in scheduler
	debugkey
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r c91f3f39e7df -r 38e532667238 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Feb 21 11:26:37 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Feb 21 11:44:19 2012 +0000
@@ -1504,6 +1504,7 @@ csched_dump(const struct scheduler *ops)
            "\trunq_sort          = %u\n"
            "\tdefault-weight     = %d\n"
            "\ttslice             = %dms\n"
+           "\tratelimit          = %dus\n"
            "\tcredits per msec   = %d\n"
            "\tticks per tslice   = %d\n"
            "\tmigration delay    = %uus\n",
@@ -1515,6 +1516,7 @@ csched_dump(const struct scheduler *ops)
            prv->runq_sort,
            CSCHED_DEFAULT_WEIGHT,
            prv->tslice_ms,
+           prv->ratelimit_us,
            CSCHED_CREDITS_PER_MSEC,
            prv->ticks_per_tslice,
            vcpu_migration_delay);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvW-0001M0-A2; Tue, 21 Feb 2012 13:38:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvV-0001Jq-7o
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:41 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329831511!9289808!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9687 invoked from network); 21 Feb 2012 13:38:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753408"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:29 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-Ak;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 38e53266723815e8445ff25374f7e8aaa9b5af66
Message-ID: <38e53266723815e8445f.1329831249@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 10] xen: Print ratelimit in scheduler
	debugkey
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r c91f3f39e7df -r 38e532667238 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Feb 21 11:26:37 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Feb 21 11:44:19 2012 +0000
@@ -1504,6 +1504,7 @@ csched_dump(const struct scheduler *ops)
            "\trunq_sort          = %u\n"
            "\tdefault-weight     = %d\n"
            "\ttslice             = %dms\n"
+           "\tratelimit          = %dus\n"
            "\tcredits per msec   = %d\n"
            "\tticks per tslice   = %d\n"
            "\tmigration delay    = %uus\n",
@@ -1515,6 +1516,7 @@ csched_dump(const struct scheduler *ops)
            prv->runq_sort,
            CSCHED_DEFAULT_WEIGHT,
            prv->tslice_ms,
+           prv->ratelimit_us,
            CSCHED_CREDITS_PER_MSEC,
            prv->ticks_per_tslice,
            vcpu_migration_delay);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpvV-0001Li-UB; Tue, 21 Feb 2012 13:38:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvU-0001Jh-A0
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:40 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24220 invoked from network); 21 Feb 2012 13:38:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753410"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:29 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-CV;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0f97e5c69eeb0c00d1f75cb1d02e407eb44bea21
Message-ID: <0f97e5c69eeb0c00d1f7.1329831252@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 10] libxl: cleanup: Remove pointless
	ERRNOVAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 call LIBXL__LOG rather than passing a meaningless ERRNOVAL.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5e3ca9be617e -r 0f97e5c69eeb tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
@@ -3008,13 +3008,13 @@ int libxl_sched_credit_domain_set(libxl_
 
 
     if (scinfo->weight < 1 || scinfo->weight > 65535) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
             "Cpu weight out of range, valid values are within range from 1 to 65535");
         return ERROR_INVAL;
     }
 
     if (scinfo->cap < 0 || scinfo->cap > (domaininfo.max_vcpu_id + 1) * 100) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
             "Cpu cap out of range, valid range is from 0 to %d for specified number of vcpus",
             ((domaininfo.max_vcpu_id + 1) * 100));
         return ERROR_INVAL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpvV-0001Li-UB; Tue, 21 Feb 2012 13:38:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvU-0001Jh-A0
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:40 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24220 invoked from network); 21 Feb 2012 13:38:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753410"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:29 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-CV;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0f97e5c69eeb0c00d1f75cb1d02e407eb44bea21
Message-ID: <0f97e5c69eeb0c00d1f7.1329831252@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 10] libxl: cleanup: Remove pointless
	ERRNOVAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 call LIBXL__LOG rather than passing a meaningless ERRNOVAL.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5e3ca9be617e -r 0f97e5c69eeb tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
@@ -3008,13 +3008,13 @@ int libxl_sched_credit_domain_set(libxl_
 
 
     if (scinfo->weight < 1 || scinfo->weight > 65535) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
             "Cpu weight out of range, valid values are within range from 1 to 65535");
         return ERROR_INVAL;
     }
 
     if (scinfo->cap < 0 || scinfo->cap > (domaininfo.max_vcpu_id + 1) * 100) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
             "Cpu cap out of range, valid range is from 0 to %d for specified number of vcpus",
             ((domaininfo.max_vcpu_id + 1) * 100));
         return ERROR_INVAL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpvY-0001Mw-54; Tue, 21 Feb 2012 13:38:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvW-0001Jw-6I
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329831511!9289808!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9715 invoked from network); 21 Feb 2012 13:38:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753417"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-Ds;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6dc39f1a7167b3a981788e51fc7fea26002a6f41
Message-ID: <6dc39f1a7167b3a98178.1329831255@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:15 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 10] xl: Refactor sched_domain_output to
 have a callback for pool information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a scheduler to provide a callback to display pool-wide information,
providing a default.  This is in preparation for displaying pool-wide
scheduler parameters on this line.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r d70161aab13e -r 6dc39f1a7167 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:12 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:15 2012 +0000
@@ -4059,13 +4059,24 @@ static int sched_sedf_domain_output(
     return 0;
 }
 
+static int sched_default_pool_output(
+    uint32_t poolid)
+{
+    char *poolname;
+
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    printf("Cpupool %s:\n",
+           poolname);
+    free(poolname);
+    return 0;
+}
+
 static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+    uint32_t sched, int (*output)(int), int (*pooloutput)(uint32_t), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
     uint32_t poolid;
-    char *poolname;
     int nb_domain, n_pools = 0, i, p;
     int rc = 0;
 
@@ -4093,9 +4104,7 @@ static int sched_domain_output(
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
-        poolname = libxl_cpupoolid_to_name(ctx, poolinfo[p].poolid);
-        printf("Cpupool %s:\n", poolname);
-        free(poolname);
+        pooloutput(poolinfo[p].poolid);
 
         output(-1);
         for (i = 0; i < nb_domain; i++) {
@@ -4171,7 +4180,9 @@ int main_sched_credit(int argc, char **a
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
-                                    sched_credit_domain_output, cpupool);
+                                    sched_credit_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4247,7 +4258,9 @@ int main_sched_credit2(int argc, char **
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
-                                    sched_credit2_domain_output, cpupool);
+                                    sched_credit2_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4349,7 +4362,9 @@ int main_sched_sedf(int argc, char **arg
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_SEDF,
-                                    sched_sedf_domain_output, cpupool);
+                                    sched_sedf_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzpvY-0001Mw-54; Tue, 21 Feb 2012 13:38:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvW-0001Jw-6I
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329831511!9289808!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9715 invoked from network); 21 Feb 2012 13:38:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753417"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-Ds;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6dc39f1a7167b3a981788e51fc7fea26002a6f41
Message-ID: <6dc39f1a7167b3a98178.1329831255@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:15 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 10] xl: Refactor sched_domain_output to
 have a callback for pool information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a scheduler to provide a callback to display pool-wide information,
providing a default.  This is in preparation for displaying pool-wide
scheduler parameters on this line.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r d70161aab13e -r 6dc39f1a7167 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:12 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:15 2012 +0000
@@ -4059,13 +4059,24 @@ static int sched_sedf_domain_output(
     return 0;
 }
 
+static int sched_default_pool_output(
+    uint32_t poolid)
+{
+    char *poolname;
+
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    printf("Cpupool %s:\n",
+           poolname);
+    free(poolname);
+    return 0;
+}
+
 static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+    uint32_t sched, int (*output)(int), int (*pooloutput)(uint32_t), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
     uint32_t poolid;
-    char *poolname;
     int nb_domain, n_pools = 0, i, p;
     int rc = 0;
 
@@ -4093,9 +4104,7 @@ static int sched_domain_output(
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
-        poolname = libxl_cpupoolid_to_name(ctx, poolinfo[p].poolid);
-        printf("Cpupool %s:\n", poolname);
-        free(poolname);
+        pooloutput(poolinfo[p].poolid);
 
         output(-1);
         for (i = 0; i < nb_domain; i++) {
@@ -4171,7 +4180,9 @@ int main_sched_credit(int argc, char **a
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
-                                    sched_credit_domain_output, cpupool);
+                                    sched_credit_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4247,7 +4258,9 @@ int main_sched_credit2(int argc, char **
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
-                                    sched_credit2_domain_output, cpupool);
+                                    sched_credit2_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4349,7 +4362,9 @@ int main_sched_sedf(int argc, char **arg
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_SEDF,
-                                    sched_sedf_domain_output, cpupool);
+                                    sched_sedf_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvR-0001K0-LO; Tue, 21 Feb 2012 13:38:37 +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 1RzpvP-0001Jm-TC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:36 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329831480!57610672!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30011 invoked from network); 21 Feb 2012 13:38:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753414"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-DP;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: d70161aab13edea6f2f4f255939f6d9204762847
Message-ID: <d70161aab13edea6f2f4.1329831254@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:14 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 10] libxl: Implement
	libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement functions to set credit scheduler global parameters.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 127b33c09db2 -r d70161aab13e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Feb 21 12:17:12 2012 +0000
@@ -3032,6 +3032,65 @@ int libxl_sched_credit_domain_set(libxl_
     return 0;
 }
 
+int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc;
+
+    rc = xc_sched_credit_param_get(ctx->xch, poolid, &sparam);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
+int libxl_sched_credit_param_set(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc=0;
+
+    if (scinfo->tslice_ms <  XEN_SYSCTL_CSCHED_TSLICE_MIN
+        || scinfo->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Time slice out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_CSCHED_TSLICE_MIN,
+                            XEN_SYSCTL_CSCHED_TSLICE_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us <  XEN_SYSCTL_SCHED_RATELIMIT_MIN
+        || scinfo->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Ratelimit out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+                            XEN_SYSCTL_SCHED_RATELIMIT_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us > scinfo->tslice_ms*1000) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "Ratelimit cannot be greater than timeslice\n");
+        return ERROR_INVAL;
+    }
+
+    sparam.tslice_ms = scinfo->tslice_ms;
+    sparam.ratelimit_us = scinfo->ratelimit_us;
+
+    rc = xc_sched_credit_param_set(ctx->xch, poolid, &sparam);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo)
 {
diff -r 127b33c09db2 -r d70161aab13e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.h	Tue Feb 21 12:17:12 2012 +0000
@@ -591,6 +591,10 @@ int libxl_sched_credit_domain_get(libxl_
                                   libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
                                   libxl_sched_credit_domain *scinfo);
+int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_param *scinfo);
+int libxl_sched_credit_param_set(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_param *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
diff -r 127b33c09db2 -r d70161aab13e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Feb 21 12:17:12 2012 +0000
@@ -395,6 +395,11 @@ libxl_sched_credit_domain = Struct("sche
     ("cap", integer),
     ], dispose_fn=None)
 
+libxl_sched_credit_param = Struct("sched_credit_param", [
+    ("tslice_ms", integer),
+    ("ratelimit_us", integer),
+    ], dispose_fn=None)
+
 libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvR-0001K0-LO; Tue, 21 Feb 2012 13:38:37 +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 1RzpvP-0001Jm-TC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:36 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329831480!57610672!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30011 invoked from network); 21 Feb 2012 13:38:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753414"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-DP;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: d70161aab13edea6f2f4f255939f6d9204762847
Message-ID: <d70161aab13edea6f2f4.1329831254@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:14 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 10] libxl: Implement
	libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement functions to set credit scheduler global parameters.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 127b33c09db2 -r d70161aab13e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Feb 21 12:17:12 2012 +0000
@@ -3032,6 +3032,65 @@ int libxl_sched_credit_domain_set(libxl_
     return 0;
 }
 
+int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc;
+
+    rc = xc_sched_credit_param_get(ctx->xch, poolid, &sparam);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
+int libxl_sched_credit_param_set(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc=0;
+
+    if (scinfo->tslice_ms <  XEN_SYSCTL_CSCHED_TSLICE_MIN
+        || scinfo->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Time slice out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_CSCHED_TSLICE_MIN,
+                            XEN_SYSCTL_CSCHED_TSLICE_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us <  XEN_SYSCTL_SCHED_RATELIMIT_MIN
+        || scinfo->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Ratelimit out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+                            XEN_SYSCTL_SCHED_RATELIMIT_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us > scinfo->tslice_ms*1000) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "Ratelimit cannot be greater than timeslice\n");
+        return ERROR_INVAL;
+    }
+
+    sparam.tslice_ms = scinfo->tslice_ms;
+    sparam.ratelimit_us = scinfo->ratelimit_us;
+
+    rc = xc_sched_credit_param_set(ctx->xch, poolid, &sparam);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo)
 {
diff -r 127b33c09db2 -r d70161aab13e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl.h	Tue Feb 21 12:17:12 2012 +0000
@@ -591,6 +591,10 @@ int libxl_sched_credit_domain_get(libxl_
                                   libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
                                   libxl_sched_credit_domain *scinfo);
+int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_param *scinfo);
+int libxl_sched_credit_param_set(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_param *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
diff -r 127b33c09db2 -r d70161aab13e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Feb 21 12:14:32 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Feb 21 12:17:12 2012 +0000
@@ -395,6 +395,11 @@ libxl_sched_credit_domain = Struct("sche
     ("cap", integer),
     ], dispose_fn=None)
 
+libxl_sched_credit_param = Struct("sched_credit_param", [
+    ("tslice_ms", integer),
+    ("ratelimit_us", integer),
+    ], dispose_fn=None)
+
 libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvV-0001LS-F2; Tue, 21 Feb 2012 13:38:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvT-0001JZ-6h
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24110 invoked from network); 21 Feb 2012 13:38:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753401"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-9q;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0402fc3aeaf31726ddecc4f2a86e865798586c14
Message-ID: <0402fc3aeaf31726ddec.1329831247@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:07 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 10] cleanup: Remove dependency files in
 efi directory during a make clean
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 87218bd367be -r 0402fc3aeaf3 xen/arch/x86/Makefile
--- a/xen/arch/x86/Makefile	Fri Feb 17 12:24:38 2012 +0000
+++ b/xen/arch/x86/Makefile	Tue Feb 21 11:25:21 2012 +0000
@@ -168,5 +168,5 @@ efi/mkreloc: efi/mkreloc.c
 clean::
 	rm -f asm-offsets.s xen.lds boot/*.o boot/*~ boot/core boot/mkelf32
 	rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc
+	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc efi/.*.d
 	rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpvV-0001LS-F2; Tue, 21 Feb 2012 13:38:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RzpvT-0001JZ-6h
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:38:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329831509!17587568!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24110 invoked from network); 21 Feb 2012 13:38:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:38:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="182753401"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:38:28 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:38:27 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-9q;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0402fc3aeaf31726ddecc4f2a86e865798586c14
Message-ID: <0402fc3aeaf31726ddec.1329831247@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:07 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 10] cleanup: Remove dependency files in
 efi directory during a make clean
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 87218bd367be -r 0402fc3aeaf3 xen/arch/x86/Makefile
--- a/xen/arch/x86/Makefile	Fri Feb 17 12:24:38 2012 +0000
+++ b/xen/arch/x86/Makefile	Tue Feb 21 11:25:21 2012 +0000
@@ -168,5 +168,5 @@ efi/mkreloc: efi/mkreloc.c
 clean::
 	rm -f asm-offsets.s xen.lds boot/*.o boot/*~ boot/core boot/mkelf32
 	rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc
+	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc efi/.*.d
 	rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzpyz-0002S5-4s; Tue, 21 Feb 2012 13:42:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1Rzpyx-0002RN-P9
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:42:15 +0000
Received: from [85.158.139.83:16595] by server-2.bemta-5.messagelabs.com id
	D7/86-20263-73F934F4; Tue, 21 Feb 2012 13:42:15 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329831732!15992646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18469 invoked from network); 21 Feb 2012 13:42:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:42:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291514"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:42:12 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Tue, 21 Feb 2012
	08:42:12 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 21 Feb 2012 08:42:12 -0500
Thread-Topic: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwdWAapsDfmHI3SUaalZu6NI+xsgAKAhjg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
In-Reply-To: <1329814018.25232.3.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, February 21, 2012 3:47 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> 
> On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > Updates to the layout of the HVM parameter and information page
> > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > written to the bottom half of this page.
> 
> We would like to eventually get rid of the HVM info page and would
> certainly like to avoid adding anything further there. Could this data
> not be supplied via xenstore? Certainly they could and should be for the
> ones controlled by the flags entry which you add.
> 
> Ian.
> 

Ah I did not realize that. The original incarnation of this code came from 2+ years ago. I have no objection to using xenstore but I did not think xenstore was suitable for passing arbitrary blocks of binary data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in this assumption.

I am not sure what other mechanisms could be employed. In other code I use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime. I use a little DMAish interface I built into qemu to push the SSDT to hvmloader while it is building the ACPI tables. Something like this could be used but I don't really want to get qemu involved in this operation.

I guess a third option might be to have a facility to load extra modules/files into the new domain at start time and specify their gpa's in xenstore. They could then be discarded after the initial domain setup is complete.

Anyway, any thoughts or suggestions are most welcome, thanks.

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzpyz-0002S5-4s; Tue, 21 Feb 2012 13:42:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1Rzpyx-0002RN-P9
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:42:15 +0000
Received: from [85.158.139.83:16595] by server-2.bemta-5.messagelabs.com id
	D7/86-20263-73F934F4; Tue, 21 Feb 2012 13:42:15 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329831732!15992646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18469 invoked from network); 21 Feb 2012 13:42:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:42:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291514"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:42:12 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Tue, 21 Feb 2012
	08:42:12 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 21 Feb 2012 08:42:12 -0500
Thread-Topic: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwdWAapsDfmHI3SUaalZu6NI+xsgAKAhjg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
In-Reply-To: <1329814018.25232.3.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, February 21, 2012 3:47 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> 
> On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > Updates to the layout of the HVM parameter and information page
> > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > written to the bottom half of this page.
> 
> We would like to eventually get rid of the HVM info page and would
> certainly like to avoid adding anything further there. Could this data
> not be supplied via xenstore? Certainly they could and should be for the
> ones controlled by the flags entry which you add.
> 
> Ian.
> 

Ah I did not realize that. The original incarnation of this code came from 2+ years ago. I have no objection to using xenstore but I did not think xenstore was suitable for passing arbitrary blocks of binary data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in this assumption.

I am not sure what other mechanisms could be employed. In other code I use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime. I use a little DMAish interface I built into qemu to push the SSDT to hvmloader while it is building the ACPI tables. Something like this could be used but I don't really want to get qemu involved in this operation.

I guess a third option might be to have a facility to load extra modules/files into the new domain at start time and specify their gpa's in xenstore. They could then be discarded after the initial domain setup is complete.

Anyway, any thoughts or suggestions are most welcome, thanks.

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpzT-0002bu-JW; Tue, 21 Feb 2012 13:42:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzpzS-0002aC-1c
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:42:46 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329831757!12424703!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 798 invoked from network); 21 Feb 2012 13:42:39 -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;
	21 Feb 2012 13:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:42:37 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 21 Feb 2012
	08:42:37 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 21 Feb 2012 08:42:38 -0500
Thread-Topic: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
Thread-Index: AczwdYY9xvGg3RgCRNqEyet2h8qf6wAKRmFg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323F1@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
	<1329814082.25232.4.camel@dagon.hellion.org.uk>
In-Reply-To: <1329814082.25232.4.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, February 21, 2012 3:48 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
> 
> 
> > -static void validate_hvm_info(struct hvm_info_table *t)
> > +static int validate_hvm_info_table(uint8_t *table, uint32_t
> > table_length,
> > +    const char *table_sig, const char *sig)
> >  {
> > -    uint8_t *ptr = (uint8_t *)t;
> >      uint8_t sum = 0;
> >      int i;
> >
> > -    if ( strncmp(t->signature, "HVM INFO", 8) )
> > +    if (table_length == 0)
> > +        printf("Empty HVM info table: %.*s\n", 8, sig);
> > +
> > +    /* NOTE made this a common routine to validate all HVM tables.
> > Removed
> > +       BUG() on failure in here - let the caller decide if a checksum
> > failure
> > +       warrants that */
> 
> I think comments about what code looked like historically, what changed
> and why belong in the commit message, not inline in the code.
> 

Wilco

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzpzT-0002bu-JW; Tue, 21 Feb 2012 13:42:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RzpzS-0002aC-1c
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:42:46 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329831757!12424703!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 798 invoked from network); 21 Feb 2012 13:42:39 -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;
	21 Feb 2012 13:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:42:37 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 21 Feb 2012
	08:42:37 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 21 Feb 2012 08:42:38 -0500
Thread-Topic: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
Thread-Index: AczwdYY9xvGg3RgCRNqEyet2h8qf6wAKRmFg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EC323F1@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D9@FTLPMAILBOX02.citrite.net>
	<1329814082.25232.4.camel@dagon.hellion.org.uk>
In-Reply-To: <1329814082.25232.4.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, February 21, 2012 3:48 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2/3] SMBIOS table passthrough support
> 
> 
> > -static void validate_hvm_info(struct hvm_info_table *t)
> > +static int validate_hvm_info_table(uint8_t *table, uint32_t
> > table_length,
> > +    const char *table_sig, const char *sig)
> >  {
> > -    uint8_t *ptr = (uint8_t *)t;
> >      uint8_t sum = 0;
> >      int i;
> >
> > -    if ( strncmp(t->signature, "HVM INFO", 8) )
> > +    if (table_length == 0)
> > +        printf("Empty HVM info table: %.*s\n", 8, sig);
> > +
> > +    /* NOTE made this a common routine to validate all HVM tables.
> > Removed
> > +       BUG() on failure in here - let the caller decide if a checksum
> > failure
> > +       warrants that */
> 
> I think comments about what code looked like historically, what changed
> and why belong in the commit message, not inline in the code.
> 

Wilco

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:43:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq0E-0002pS-1y; Tue, 21 Feb 2012 13:43: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 1Rzq0C-0002ov-Va
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:43:33 +0000
Received: from [85.158.139.83:62486] by server-8.bemta-5.messagelabs.com id
	82/8C-09797-48F934F4; Tue, 21 Feb 2012 13:43:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329831811!12121916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18839 invoked from network); 21 Feb 2012 13:43:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:43:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:43:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:43:31 +0000
Message-ID: <1329831808.3990.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 13:43:28 +0000
In-Reply-To: <20291.36697.376087.225279@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > However I am not sure what to do with the "master" branch of our tree.
> > Previously I just omitted it since it has no real meaning but that
> > caused confusion and people wanted me to put something there.
> > 
> > I don't want to track the upstream devel branch since I don't want users
> > who clone our tree to think we support that as is. I don't want to push
> > the currently supported stable branch because that would necessarily
> > make master a rebasing branch.
> > 
> > The xen-unstable build system itself uses explicit commit numbers or
> > tags so isn't really effected.
> > 
> > IanJ -- what do you think?
> 
> Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> xen-unstable's Config.mk ?  That's what I do with
> qemu-xen-unstable.git.

That would make master rebasing. I'm happy to do that if there is
consensus that it is ok.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:43:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq0E-0002pS-1y; Tue, 21 Feb 2012 13:43: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 1Rzq0C-0002ov-Va
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:43:33 +0000
Received: from [85.158.139.83:62486] by server-8.bemta-5.messagelabs.com id
	82/8C-09797-48F934F4; Tue, 21 Feb 2012 13:43:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329831811!12121916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18839 invoked from network); 21 Feb 2012 13:43:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:43:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:43:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:43:31 +0000
Message-ID: <1329831808.3990.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 13:43:28 +0000
In-Reply-To: <20291.36697.376087.225279@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > However I am not sure what to do with the "master" branch of our tree.
> > Previously I just omitted it since it has no real meaning but that
> > caused confusion and people wanted me to put something there.
> > 
> > I don't want to track the upstream devel branch since I don't want users
> > who clone our tree to think we support that as is. I don't want to push
> > the currently supported stable branch because that would necessarily
> > make master a rebasing branch.
> > 
> > The xen-unstable build system itself uses explicit commit numbers or
> > tags so isn't really effected.
> > 
> > IanJ -- what do you think?
> 
> Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> xen-unstable's Config.mk ?  That's what I do with
> qemu-xen-unstable.git.

That would make master rebasing. I'm happy to do that if there is
consensus that it is ok.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq0U-0002tg-FL; Tue, 21 Feb 2012 13:43:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rzq0T-0002rv-0g
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:43:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329831821!15704097!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21045 invoked from network); 21 Feb 2012 13:43:42 -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;
	21 Feb 2012 13:43:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291539"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:43:40 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:43:40 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1Rzq0K-0008EG-4b;
	Tue, 21 Feb 2012 13:43:40 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329818358.25232.64.camel@dagon.hellion.org.uk>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
Date: Tue, 21 Feb 2012 12:20:41 +0000
Message-ID: <1329826841.2196.85.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 09:59 +0000, Ian Campbell wrote:
> On Mon, 2012-02-20 at 14:48 +0000, George Dunlap wrote:
> > On Mon, Feb 20, 2012 at 11:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Mon, Feb 20, George Dunlap wrote:
> > >
> > >> Start-of-day:
> > >>  xenpaging off: Set balloon target to M, use PoD
> > >>  xenpaging on: ??
> > >>  xenpaging delay: Set balloon target to M, use PoD.  Wait
> > >> $pagingdelayboot seconds, if target not reached, set paging?
> > >
> > > Is the delay required?
> > > If paging and PoD target is M, xenpaging will do nothing because the
> > > guest can not exceed M (it will crash with OOM).
> > 
> > Ah, of course -- you don't need paging because it already has M
> > memory.  Forgot about that.
> > 
> > It would be nice, of course, if the pager could act as a back-fill for
> > these PoD pages; but that's another project, I think.
> > 
> > So that leaves us with:
> > 
> > maxmem=X
> > memory=M
> > xenpaging=[off|on|delay]
> > pagingdelay=60
> 
> FWIW these two can be expressed as:
> xenpaging=[off|on]
> pagingdelay=[0|60]
> 
> (and lets drop the "xen" prefix)
> 
> [...]
> > xl mem-set domain M
> >  xenpaging off: Set balloon target to M
> >  xenpaging on: Set paging target to M
> >  xenpaging delay: Set balloon target to M, and wait for actual memory
> > to reach M.  If it hasn't reached it by $paging_delay seconds, set
> > balloon target to M.
> 
> Did you mean "paging target" the second time you said "balloon target"
> in this one? I'll assume so. 

Er, yes, that's what I meant. :-)

> I would also suggest 
> 	s/If it hasn't reached it by/After/
> since I think that will simplify things somewhat and setting page target
> to M makes no odds if the guest has ballooned to M.
> 
> I don't really like mem-set having such completely different behaviour
> depending on whether paging is on or off.
> 
> As you described before having paging on == set paging and balloon
> target to M results in fairly suboptimal behaviour and the name would
> also lead to people thinking it is the one they should use.
> 
> So why not make the "on" case the same as your "delay" case and do away
> with the distinction? If advanced users really want what you describe as
> "on" then they can set the delay to 0.

The only thing with this is that then the command will by default pause
until we reach the target, which may be several seconds.  We should make
sure to print a message saying that's what we're doing, so users don't
get confused.

> If the paging daemon could be start/stopped on demand (rather than being
> a domain build time choice) we could even consider making paging the
> default.
> 
> > xl mem-balloon-set domain M
> >  Set balloon target to M
> > xl mem-paging-set domain M
> >  Set paging target to M
> 
> How do these interact with mem-set. Especially in the delay case?

My idea was that "xl mem-paging-set domain M" would basically be
equivalent to xenstore-write /local/[whatever]/[whatever]: that is, no
attempt at synchronization.  If I do "xl mem-set" with a delay in one
window, then do "xl mem-paging-set" in another window, the first one
will take effect immediately, then the other one will take effect after
the delay.  If that's not what you want, either Ctrl-C the first one or
wait for it to finish. :-)

> e.g. would mem-paging-set disable the after delay behaviour of mem-set?
> Should we have "mem-paging-set domain auto" to turn that back on?

That's one of the reasons I conceived having mem-balloon-set: if you
want to switch to full-manual, you just switch to using full-manual
commands.  If/when you have stuff in a state that the simpler command
will work again, you can switch back.

> We also need to consider the behaviour of mem-set to increase things.
> Obviously you don't want to leave paging target set to the smaller value
> for a minute after setting the balloon target. I think we want to set it
> straight away in that case, if not before setting the balloon.

Yes; if we're increasing the target, we should set paging-target
immediately.

> How about the following? I've tried to include the "user facing"
> description as well as the actual implementation. I think the "user
> facing" portion is actually where we disagree but I also suspect that we
> may not actually disagree -- it's just that we are talking in terms of
> implementation so we don't see that the user facing interface is the
> same in what we are each thinking of ;-)
> 
> maxmem=X			# maximum RAM the domain can ever see
> memory=M			# current amount of RAM seen by the domain
> paging=[off|on]			# allow the amount of memory a guest 
> 				# thinks it has to differ from the
> 				# amount actually available to it (its
> 				# "footprint")
> pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> 				# "footprint" for guests which do not
> 				# voluntarily obey changes to memory=M 
> pagingdelay=60			# amount of time to give a guest to 
> 				# voluntarily comply before enforcing a 
> 				# footprint
> 
> xl mem-set domain M
>         Sets the amount of RAM which the guest believes it has available
>         to M. The guest should arrange to use only that much RAM and
>         return the rest to the hypervisor (e.g. by using a balloon
>         driver). If the guest does not do so then the host may use
>         technical means to enforce the guest's footprint of M. The guest
>         may suffer a performance penalty for this enforcement.
> 
> 	paging off:	set balloon target to M.
> 	paging on: 	set balloon target to M.
> 			if pagingauto:
> 				wait delay IFF new target < old
> 				set paging target to M
> 				support -t <delay> to override default?
> 
> xl mem-paging-set domain N
>         Overrides the amount of RAM which the guest actually has
>         available (its "footprint") to N. The host will use technical
>         means to continue to provide the illusion to the guest that it
>         has memory=M (as adjusted by mem-set). There may be a
>         performance penalty for this.
>         
> 	paging off:	error
> 	paging on:	set paging target
> 			set pagingauto=off
> 
> xl mem-paging-set domain auto
>         Automatically manage paging. Request that the guest uses
>         memory=M (current value of memory, as adjusted by mem-set)
>         enforced when the guest is uncooperative (as described in
>         "mem-set")
>         
> 	paging off:	error
> 	paging on:	set paging target to M
> 			set pagingauto=on
> 
> No need for a separate balloon-set since that == mem-set with
> pagingauto=off.
> 
> Perhaps a separate "mem-paging-set domain manual" would be handy to
> enable that mode without having to remember M so you can use it as N 

I'd be OK with this.

> We could consider making "mem-paging-set domain N" fail with an error
> unless you previously set manual, to prevent users accidentally
> disabling the recommended automatic behaviour e.g. by typing
> mem-paging-set when they mean mem-set.
> 
> I liked Andres' suggestions of footprint as a term here BTW so I would
> prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
> not 100% on that). If we don't have balloon-set then avoiding the name
> paging seems like a good idea too. Other possible names might be
> "mem-override-set" or something.

Well for one, "footprint" to me would imply "I don't care how you got
there, just make it take this much memory".  So saying in the docs that
"xl mem-set" would attempt to set the memory footprint would be OK.  But
I definitely don't think we should use "footprint" to mean "paging
target".  Even apart from the fact that the name to me means something
else, the config options are called "paging".  In any case, if it's
supposed to be an "advanced feature", it should be OK to expect the user
to know (or find out) what paging means.

> I don't really like the extra configuration option for pagingauto but I
> think pagingauto and mem-{paging,footprint}-set should be considered
> advanced options and by default we would recommend that folks just set
> "paging=on" and use mem-set. It should be reasonably clear to users that
> if they disable auto mode then they are expected to understand what is
> happening sufficiently to make their own choices about paging targets
> etc.
> 
> We can probably think of more useful algorithms than raw pagingdelay
> (i.e. based on rate of progress or something) which might be useful for
> larger domains making large changes to the balloon -- lets leave that
> aside for now though. Likewise "auto" mode allows scope for us to
> implement improved algorithms in the future.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq0U-0002tg-FL; Tue, 21 Feb 2012 13:43:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rzq0T-0002rv-0g
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:43:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329831821!15704097!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21045 invoked from network); 21 Feb 2012 13:43:42 -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;
	21 Feb 2012 13:43:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291539"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:43:40 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:43:40 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1Rzq0K-0008EG-4b;
	Tue, 21 Feb 2012 13:43:40 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329818358.25232.64.camel@dagon.hellion.org.uk>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
Date: Tue, 21 Feb 2012 12:20:41 +0000
Message-ID: <1329826841.2196.85.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 09:59 +0000, Ian Campbell wrote:
> On Mon, 2012-02-20 at 14:48 +0000, George Dunlap wrote:
> > On Mon, Feb 20, 2012 at 11:12 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Mon, Feb 20, George Dunlap wrote:
> > >
> > >> Start-of-day:
> > >>  xenpaging off: Set balloon target to M, use PoD
> > >>  xenpaging on: ??
> > >>  xenpaging delay: Set balloon target to M, use PoD.  Wait
> > >> $pagingdelayboot seconds, if target not reached, set paging?
> > >
> > > Is the delay required?
> > > If paging and PoD target is M, xenpaging will do nothing because the
> > > guest can not exceed M (it will crash with OOM).
> > 
> > Ah, of course -- you don't need paging because it already has M
> > memory.  Forgot about that.
> > 
> > It would be nice, of course, if the pager could act as a back-fill for
> > these PoD pages; but that's another project, I think.
> > 
> > So that leaves us with:
> > 
> > maxmem=X
> > memory=M
> > xenpaging=[off|on|delay]
> > pagingdelay=60
> 
> FWIW these two can be expressed as:
> xenpaging=[off|on]
> pagingdelay=[0|60]
> 
> (and lets drop the "xen" prefix)
> 
> [...]
> > xl mem-set domain M
> >  xenpaging off: Set balloon target to M
> >  xenpaging on: Set paging target to M
> >  xenpaging delay: Set balloon target to M, and wait for actual memory
> > to reach M.  If it hasn't reached it by $paging_delay seconds, set
> > balloon target to M.
> 
> Did you mean "paging target" the second time you said "balloon target"
> in this one? I'll assume so. 

Er, yes, that's what I meant. :-)

> I would also suggest 
> 	s/If it hasn't reached it by/After/
> since I think that will simplify things somewhat and setting page target
> to M makes no odds if the guest has ballooned to M.
> 
> I don't really like mem-set having such completely different behaviour
> depending on whether paging is on or off.
> 
> As you described before having paging on == set paging and balloon
> target to M results in fairly suboptimal behaviour and the name would
> also lead to people thinking it is the one they should use.
> 
> So why not make the "on" case the same as your "delay" case and do away
> with the distinction? If advanced users really want what you describe as
> "on" then they can set the delay to 0.

The only thing with this is that then the command will by default pause
until we reach the target, which may be several seconds.  We should make
sure to print a message saying that's what we're doing, so users don't
get confused.

> If the paging daemon could be start/stopped on demand (rather than being
> a domain build time choice) we could even consider making paging the
> default.
> 
> > xl mem-balloon-set domain M
> >  Set balloon target to M
> > xl mem-paging-set domain M
> >  Set paging target to M
> 
> How do these interact with mem-set. Especially in the delay case?

My idea was that "xl mem-paging-set domain M" would basically be
equivalent to xenstore-write /local/[whatever]/[whatever]: that is, no
attempt at synchronization.  If I do "xl mem-set" with a delay in one
window, then do "xl mem-paging-set" in another window, the first one
will take effect immediately, then the other one will take effect after
the delay.  If that's not what you want, either Ctrl-C the first one or
wait for it to finish. :-)

> e.g. would mem-paging-set disable the after delay behaviour of mem-set?
> Should we have "mem-paging-set domain auto" to turn that back on?

That's one of the reasons I conceived having mem-balloon-set: if you
want to switch to full-manual, you just switch to using full-manual
commands.  If/when you have stuff in a state that the simpler command
will work again, you can switch back.

> We also need to consider the behaviour of mem-set to increase things.
> Obviously you don't want to leave paging target set to the smaller value
> for a minute after setting the balloon target. I think we want to set it
> straight away in that case, if not before setting the balloon.

Yes; if we're increasing the target, we should set paging-target
immediately.

> How about the following? I've tried to include the "user facing"
> description as well as the actual implementation. I think the "user
> facing" portion is actually where we disagree but I also suspect that we
> may not actually disagree -- it's just that we are talking in terms of
> implementation so we don't see that the user facing interface is the
> same in what we are each thinking of ;-)
> 
> maxmem=X			# maximum RAM the domain can ever see
> memory=M			# current amount of RAM seen by the domain
> paging=[off|on]			# allow the amount of memory a guest 
> 				# thinks it has to differ from the
> 				# amount actually available to it (its
> 				# "footprint")
> pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> 				# "footprint" for guests which do not
> 				# voluntarily obey changes to memory=M 
> pagingdelay=60			# amount of time to give a guest to 
> 				# voluntarily comply before enforcing a 
> 				# footprint
> 
> xl mem-set domain M
>         Sets the amount of RAM which the guest believes it has available
>         to M. The guest should arrange to use only that much RAM and
>         return the rest to the hypervisor (e.g. by using a balloon
>         driver). If the guest does not do so then the host may use
>         technical means to enforce the guest's footprint of M. The guest
>         may suffer a performance penalty for this enforcement.
> 
> 	paging off:	set balloon target to M.
> 	paging on: 	set balloon target to M.
> 			if pagingauto:
> 				wait delay IFF new target < old
> 				set paging target to M
> 				support -t <delay> to override default?
> 
> xl mem-paging-set domain N
>         Overrides the amount of RAM which the guest actually has
>         available (its "footprint") to N. The host will use technical
>         means to continue to provide the illusion to the guest that it
>         has memory=M (as adjusted by mem-set). There may be a
>         performance penalty for this.
>         
> 	paging off:	error
> 	paging on:	set paging target
> 			set pagingauto=off
> 
> xl mem-paging-set domain auto
>         Automatically manage paging. Request that the guest uses
>         memory=M (current value of memory, as adjusted by mem-set)
>         enforced when the guest is uncooperative (as described in
>         "mem-set")
>         
> 	paging off:	error
> 	paging on:	set paging target to M
> 			set pagingauto=on
> 
> No need for a separate balloon-set since that == mem-set with
> pagingauto=off.
> 
> Perhaps a separate "mem-paging-set domain manual" would be handy to
> enable that mode without having to remember M so you can use it as N 

I'd be OK with this.

> We could consider making "mem-paging-set domain N" fail with an error
> unless you previously set manual, to prevent users accidentally
> disabling the recommended automatic behaviour e.g. by typing
> mem-paging-set when they mean mem-set.
> 
> I liked Andres' suggestions of footprint as a term here BTW so I would
> prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
> not 100% on that). If we don't have balloon-set then avoiding the name
> paging seems like a good idea too. Other possible names might be
> "mem-override-set" or something.

Well for one, "footprint" to me would imply "I don't care how you got
there, just make it take this much memory".  So saying in the docs that
"xl mem-set" would attempt to set the memory footprint would be OK.  But
I definitely don't think we should use "footprint" to mean "paging
target".  Even apart from the fact that the name to me means something
else, the config options are called "paging".  In any case, if it's
supposed to be an "advanced feature", it should be OK to expect the user
to know (or find out) what paging means.

> I don't really like the extra configuration option for pagingauto but I
> think pagingauto and mem-{paging,footprint}-set should be considered
> advanced options and by default we would recommend that folks just set
> "paging=on" and use mem-set. It should be reasonably clear to users that
> if they disable auto mode then they are expected to understand what is
> happening sufficiently to make their own choices about paging targets
> etc.
> 
> We can probably think of more useful algorithms than raw pagingdelay
> (i.e. based on rate of progress or something) which might be useful for
> larger domains making large changes to the balloon -- lets leave that
> aside for now though. Likewise "auto" mode allows scope for us to
> implement improved algorithms in the future.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:44:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq0m-0002yk-Sm; Tue, 21 Feb 2012 13:44:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzq0k-0002wS-PJ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:44:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329831840!13340507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9652 invoked from network); 21 Feb 2012 13:44:00 -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;
	21 Feb 2012 13:44:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:43:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:44:00 +0000
Message-ID: <1329831838.3990.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 13:43:58 +0000
In-Reply-To: <alpine.DEB.2.00.1202211330150.23091@kaball-desktop>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202211330150.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 13:30 +0000, Stefano Stabellini wrote:
> On Tue, 21 Feb 2012, Ian Campbell wrote:
> > On Mon, 2012-02-20 at 10:37 +0000, Christoph Egger wrote:
> > > On 02/09/12 12:59, Ian Campbell wrote:
> > > > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> > > >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> > > >> This fixes seabios build error
> > > >> 'python not found'
> > > >> along with the patches from Kevin O'Connor.
> > > >>
> > > >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> > > >
> > > > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> > > >
> > > 
> > > Please apply this patch and update SeaBIOS.
> > > Keven O'Connors patches went upstream on Feb 8th.
> > 
> > I was hoping to track SeaBIOS stable branches so I am reluctant to
> > simply update to a random commit on the development branch.
> > 
> > Currently we are tracking the upstream 1.6.3-stable branch in the
> > xen-unstable branch of our seabios.git. In hindsight this might have
> > been an error since it means that our branch will only be non-rebasing
> > until we switch to 1.6.4 or 1.7.0 (whichever comes next).
> > 
> > I'm not sure how best to approach this, obviously I could create a
> > 1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
> > what approach I should take when the upstream latest-stable branch
> > changes first though.
> 
> Have you tried to ask Kevin to backport the commit to stable?

Not yet, I was more interested in the general problem than this specific
commit right at the moment.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:44:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq0m-0002yk-Sm; Tue, 21 Feb 2012 13:44:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzq0k-0002wS-PJ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:44:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329831840!13340507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9652 invoked from network); 21 Feb 2012 13:44:00 -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;
	21 Feb 2012 13:44:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:43:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:44:00 +0000
Message-ID: <1329831838.3990.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 13:43:58 +0000
In-Reply-To: <alpine.DEB.2.00.1202211330150.23091@kaball-desktop>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1202211330150.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 13:30 +0000, Stefano Stabellini wrote:
> On Tue, 21 Feb 2012, Ian Campbell wrote:
> > On Mon, 2012-02-20 at 10:37 +0000, Christoph Egger wrote:
> > > On 02/09/12 12:59, Ian Campbell wrote:
> > > > On Thu, 2012-02-09 at 11:27 +0000, Christoph Egger wrote:
> > > >> Pass PYTHON=$(PYTHON) to gmake when building seabios.
> > > >> This fixes seabios build error
> > > >> 'python not found'
> > > >> along with the patches from Kevin O'Connor.
> > > >>
> > > >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> > > >
> > > > Acked-by: Ian Campbell<ian.campbell@citrix.com>
> > > >
> > > 
> > > Please apply this patch and update SeaBIOS.
> > > Keven O'Connors patches went upstream on Feb 8th.
> > 
> > I was hoping to track SeaBIOS stable branches so I am reluctant to
> > simply update to a random commit on the development branch.
> > 
> > Currently we are tracking the upstream 1.6.3-stable branch in the
> > xen-unstable branch of our seabios.git. In hindsight this might have
> > been an error since it means that our branch will only be non-rebasing
> > until we switch to 1.6.4 or 1.7.0 (whichever comes next).
> > 
> > I'm not sure how best to approach this, obviously I could create a
> > 1.6.3-stable-xen branch and backport your fix to it. I'd like to decide
> > what approach I should take when the upstream latest-stable branch
> > changes first though.
> 
> Have you tried to ask Kevin to backport the commit to stable?

Not yet, I was more interested in the general problem than this specific
commit right at the moment.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:47:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq4D-0003d6-A6; Tue, 21 Feb 2012 13:47:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <T.Weyergraf@virtfinity.de>) id 1RywPp-0001po-DM
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 02:22:17 +0000
Received: from [85.158.139.83:32332] by server-6.bemta-5.messagelabs.com id
	89/EA-27305-8DC504F4; Sun, 19 Feb 2012 02:22:16 +0000
X-Env-Sender: T.Weyergraf@virtfinity.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329618135!15641849!1
X-Originating-IP: [188.40.209.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3640 invoked from network); 19 Feb 2012 02:22:15 -0000
Received: from static.145.209.40.188.clients.your-server.de (HELO
	v231591281.yourvserver.net) (188.40.209.145)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2012 02:22:15 -0000
Received: from bitbang.virtfinity.local (ip-178-201-160-244.unitymediagroup.de
	[178.201.160.244]) (authenticated bits=0)
	by v231591281.yourvserver.net (8.13.8/8.13.8) with ESMTP id
	q1J2M9M2009675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Sun, 19 Feb 2012 03:22:14 +0100
Message-ID: <4F405CD0.2060002@virtfinity.de>
Date: Sun, 19 Feb 2012 03:22:08 +0100
From: Thomas Weyergraf <T.Weyergraf@virtfinity.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Subject: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 am working as a system administrator at an internet platform 
service provider, and I am currently seeking to re-new our Xen 
virtualization infrastructure for which I am mostly responsible for.
Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0 with 
CentOS 5.x pv-guests.

Based on my experiments, I am currently looking into Xen 4.1.2 on 
RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as Dom0 
and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.

Our DomU's have their disk-devices on iscsi-storage backends (EMC, 
netapp, Linux IET), we attach the disks to Dom0 via open-iscsi initiator 
and pass them as 'phy'-type blockdevices, using blkfront/back.

As this is the time for a major overhaul anyway, I looked at 'pvscsi', 
which is very attractive to me for a bunch of (administrative) reasons. 
I have created a working pvscsi-setup with the following steps:
1. Use CentOS 6.2 as base system
2. Add Xen hypervisor from Michael Young's repository [1]. This is stock 
4.1.2 with a patch from 4.1-testing pulled-in and various patches fixing 
compile-time issues, toolchain problems and system service management on 
RHEL-alike systems. (Nice work, btw!)
3. Use a vanilla 3.2.0 kernel from kernel.org and a .config based on a 
Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know, 
Fedora 16 supports Dom0 operation and the only changes to the config are 
non-Xen related or add the Xen pvscsi config. I refrained from attaching 
the config to avoid mailinglist-clutter, but can do so on demand.
4. I pulled and applied the pvscsi-patch found in this post [2] from 
Konrad Rzeszutek Wilk.

Putting it all together yielded a "working setup" in which I am able to 
pass an Dom0-attached iscsi target to a DomU as a vscsi-device. In DomU 
context, I could partition the device, create a filesystem on it and 
copy/read/verify some 10gig of data to it. Very basic testing until now, 
essentially. However, the whole issue raised some questions:

- I pvscsi actively maintained? Is someone working on this or even 
prepare it for upstream inclusion in the pv-ops framework of the 3.x series?
- Has anybody started on adding the vscsi-semantics to the xl toolstack?
- Using 'xm', I was only able to add a device via its SCSI tupel (HCTL, 
e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other device-node, 
such as '/dev/sde' or the '/dev/disk/by-path/<iscsi-iqn>' link. For 
these invocations, an "Error: Cannot find device <device>" message is 
given. I have not yet looked at the issue in detail (in 
/usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this a 
known issue?

Is there any developer(s) working on getting pvscsi ready for kernel.org 
3.x upstream inclusion? Should i better retool my efforts using pv-ops 
xen/stable 2.6.32 series?

If applicable, I'd be more than happy to provide assistance to move 
forward pvscsi. Maybe, as a start, provide a short, practical howto 
about what I did above to get pvscsi working and reference it by the Xen 
PVSCSI wiki page [3]?

Regards,
Thomas Weyergraf

[1] http://xenbits.xen.org/people/mayoung/EL6.xen/
[2] http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
[3] http://wiki.xen.org/xenwiki/XenPVSCSI



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:47:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq4D-0003d6-A6; Tue, 21 Feb 2012 13:47:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <T.Weyergraf@virtfinity.de>) id 1RywPp-0001po-DM
	for xen-devel@lists.xensource.com; Sun, 19 Feb 2012 02:22:17 +0000
Received: from [85.158.139.83:32332] by server-6.bemta-5.messagelabs.com id
	89/EA-27305-8DC504F4; Sun, 19 Feb 2012 02:22:16 +0000
X-Env-Sender: T.Weyergraf@virtfinity.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329618135!15641849!1
X-Originating-IP: [188.40.209.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3640 invoked from network); 19 Feb 2012 02:22:15 -0000
Received: from static.145.209.40.188.clients.your-server.de (HELO
	v231591281.yourvserver.net) (188.40.209.145)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2012 02:22:15 -0000
Received: from bitbang.virtfinity.local (ip-178-201-160-244.unitymediagroup.de
	[178.201.160.244]) (authenticated bits=0)
	by v231591281.yourvserver.net (8.13.8/8.13.8) with ESMTP id
	q1J2M9M2009675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Sun, 19 Feb 2012 03:22:14 +0100
Message-ID: <4F405CD0.2060002@virtfinity.de>
Date: Sun, 19 Feb 2012 03:22:08 +0100
From: Thomas Weyergraf <T.Weyergraf@virtfinity.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Subject: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 am working as a system administrator at an internet platform 
service provider, and I am currently seeking to re-new our Xen 
virtualization infrastructure for which I am mostly responsible for.
Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0 with 
CentOS 5.x pv-guests.

Based on my experiments, I am currently looking into Xen 4.1.2 on 
RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as Dom0 
and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.

Our DomU's have their disk-devices on iscsi-storage backends (EMC, 
netapp, Linux IET), we attach the disks to Dom0 via open-iscsi initiator 
and pass them as 'phy'-type blockdevices, using blkfront/back.

As this is the time for a major overhaul anyway, I looked at 'pvscsi', 
which is very attractive to me for a bunch of (administrative) reasons. 
I have created a working pvscsi-setup with the following steps:
1. Use CentOS 6.2 as base system
2. Add Xen hypervisor from Michael Young's repository [1]. This is stock 
4.1.2 with a patch from 4.1-testing pulled-in and various patches fixing 
compile-time issues, toolchain problems and system service management on 
RHEL-alike systems. (Nice work, btw!)
3. Use a vanilla 3.2.0 kernel from kernel.org and a .config based on a 
Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know, 
Fedora 16 supports Dom0 operation and the only changes to the config are 
non-Xen related or add the Xen pvscsi config. I refrained from attaching 
the config to avoid mailinglist-clutter, but can do so on demand.
4. I pulled and applied the pvscsi-patch found in this post [2] from 
Konrad Rzeszutek Wilk.

Putting it all together yielded a "working setup" in which I am able to 
pass an Dom0-attached iscsi target to a DomU as a vscsi-device. In DomU 
context, I could partition the device, create a filesystem on it and 
copy/read/verify some 10gig of data to it. Very basic testing until now, 
essentially. However, the whole issue raised some questions:

- I pvscsi actively maintained? Is someone working on this or even 
prepare it for upstream inclusion in the pv-ops framework of the 3.x series?
- Has anybody started on adding the vscsi-semantics to the xl toolstack?
- Using 'xm', I was only able to add a device via its SCSI tupel (HCTL, 
e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other device-node, 
such as '/dev/sde' or the '/dev/disk/by-path/<iscsi-iqn>' link. For 
these invocations, an "Error: Cannot find device <device>" message is 
given. I have not yet looked at the issue in detail (in 
/usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this a 
known issue?

Is there any developer(s) working on getting pvscsi ready for kernel.org 
3.x upstream inclusion? Should i better retool my efforts using pv-ops 
xen/stable 2.6.32 series?

If applicable, I'd be more than happy to provide assistance to move 
forward pvscsi. Maybe, as a start, provide a short, practical howto 
about what I did above to get pvscsi working and reference it by the Xen 
PVSCSI wiki page [3]?

Regards,
Thomas Weyergraf

[1] http://xenbits.xen.org/people/mayoung/EL6.xen/
[2] http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
[3] http://wiki.xen.org/xenwiki/XenPVSCSI



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:47:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq4E-0003dG-6V; Tue, 21 Feb 2012 13:47:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1RzP6s-0004b6-Np
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:00:39 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329728413!64174925!1
X-Originating-IP: [137.65.248.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3573 invoked from network); 20 Feb 2012 09:00:13 -0000
Received: from novprvlin0050.provo.novell.com (HELO
	novprvlin0050.provo.novell.com) (137.65.248.33)
	by server-15.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 09:00:13 -0000
Received: from INET-PRV1-MTA by novprvlin0050.provo.novell.com
	with Novell_GroupWise; Mon, 20 Feb 2012 02:00:35 -0700
Message-Id: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 20 Feb 2012 02:00:27 -0700
From: "Bamvor Jian Zhang" <bjzhang@suse.com>
To: <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD5FBD5BB.0__="
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Subject: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD5FBD5BB.0__=
Content-Type: multipart/alternative; boundary="=__PartD5FBD5BB.1__="

--=__PartD5FBD5BB.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable



a, libxl_event.h is included in libxl.h. So, the former one also need to =
be installed. =20
b, define __XEN_TOOLS__ in libxl.h:=20
the head file "xen/sysctl.h" need check this macro. =20
It is the same way used by the xen libxc public headers(tools/libxc/xenctrl=
.h and tools/libxc/xenctrlosdep.h). =20

Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>=20

diff -r 87218bd367be tools/libxl/Makefile=20
--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/MakefileMon Feb 20 15:36:09 2012 +0800=20
@@ -163,7 +163,7 @@=20
 ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.=
so.$(XLUMAJOR)=20
 ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so=20
 $(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR)=20
-$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)=20
+$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h libxl_event.h $(DESTDIR)$(INCLUDED=
IR)=20
 $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh=20
 =20
 .PHONY: clean=20

diff -r 87218bd367be tools/libxl/libxl.h=20
--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/libxl.hMon Feb 20 15:36:09 2012 +0800=20
@@ -127,6 +127,11 @@=20
 #ifndef LIBXL_H=20
 #define LIBXL_H=20
 =20
+/* Tell the Xen public headers we are a user-space tools build. */=20
+#ifndef __XEN_TOOLS__=20
+#define __XEN_TOOLS__ 1=20
+#endif =20
+=20
 #include <stdbool.h>=20
 #include <stdint.h>=20
 #include <stdarg.h> 

--=__PartD5FBD5BB.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html>=0A  <head>=0A=0A  </head>=0A  <body style=3D"margin-bottom: 1px; =
margin-top: 4px; margin-right: 4px; margin-left: 4px; line-height: normal; =
font-variant: normal">=0A<br>      =0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">a&#4=
4; libxl_event.h is included in libxl.h. So&#44; the former one also need =
to be installed. </font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">b&#4=
4; define __XEN_TOOLS__ in libxl.h:</font>    </p>=0A    <p style=3D"margin=
-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">the head file &quot;xen/sysctl.h&quot; need check this macro. =
</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A     =
 <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">It is the same way used by =
the xen libxc public headers&#40;tools/libxc/xenctrl.h and tools/libxc/xenc=
trlosdep.h&#41;. </font>    </p>=0A<br>      =0A    <p style=3D"margin-bott=
om: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">Signed-off-by: Bamvor Jian Zhang &lt;bjzhang@suse.com&gt;</font>=
    </p>=0A<br>      =0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/Makefile</font>    </p>=0A    <p style=3D"margin-b=
ottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 &#43;0000</fo=
nt>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/MakefileMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -163&#44;7 &#43;163&#44;7 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;ln -sf libxlutil.so.&#36;&#4=
0;XLUMAJOR&#41;.&#36;&#40;XLUMINOR&#41; &#36;&#40;DESTDIR&#41;&#36;&#40;LIB=
DIR&#41;/libxlutil.so.&#36;&#40;XLUMAJOR&#41;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&nbsp;ln -sf libxlutil.so.&#36;&#40;XLUMAJOR&#41=
; &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;/libxlutil.so</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#36;&#40;INSTALL_DATA&#41; =
libxlutil.a &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;</font>    </p>=0A  =
  <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR =
PL ShanHeiSun Uni" size=3D"4">-&#36;&#40;INSTALL_DATA&#41; libxl.h =
libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h libxl_utils.h=
 libxl_uuid.h &#36;&#40;DESTDIR&#41;&#36;&#40;INCLUDEDIR&#41;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#36;&#40;INSTALL_DATA&#41; =
libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h =
libxl_utils.h libxl_uuid.h libxl_event.h &#36;&#40;DESTDIR&#41;&#36;&#40;IN=
CLUDEDIR&#41;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top=
: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#36;&#4=
0;INSTALL_DATA&#41; bash-completion &#36;&#40;DESTDIR&#41;&#36;&#40;BASH_CO=
MPLETION_DIR&#41;/xl.sh</font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbs=
p;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A   =
   <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;.PHONY: clean</font=
>    </p>=0A<br>      =0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/libxl.h</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 &#43;0000</fon=
t>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/libxl.hMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -127&#44;6 &#43;127&#44;11 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;ifndef LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;define LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;/&#42; Tell the Xen public headers we are =
a user-space tools build. &#42;/</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">&#43;&#35;ifndef __XEN_TOOLS__</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;&#35;define __XEN_TOOLS__ 1</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#35;endif </font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&nbsp;&#35;include &lt;stdbool.h&gt;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;include &lt;stdint.h&gt=
;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A    =
  <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;include =
&lt;stdarg.h&gt;</font>    </p>=0A  </body>=0A</html>=0A

--=__PartD5FBD5BB.1__=--

--=__PartD5FBD5BB.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

--=__PartD5FBD5BB.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:47:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq4E-0003dG-6V; Tue, 21 Feb 2012 13:47:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1RzP6s-0004b6-Np
	for xen-devel@lists.xensource.com; Mon, 20 Feb 2012 09:00:39 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329728413!64174925!1
X-Originating-IP: [137.65.248.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3573 invoked from network); 20 Feb 2012 09:00:13 -0000
Received: from novprvlin0050.provo.novell.com (HELO
	novprvlin0050.provo.novell.com) (137.65.248.33)
	by server-15.tower-27.messagelabs.com with SMTP;
	20 Feb 2012 09:00:13 -0000
Received: from INET-PRV1-MTA by novprvlin0050.provo.novell.com
	with Novell_GroupWise; Mon, 20 Feb 2012 02:00:35 -0700
Message-Id: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 20 Feb 2012 02:00:27 -0700
From: "Bamvor Jian Zhang" <bjzhang@suse.com>
To: <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD5FBD5BB.0__="
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Subject: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD5FBD5BB.0__=
Content-Type: multipart/alternative; boundary="=__PartD5FBD5BB.1__="

--=__PartD5FBD5BB.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable



a, libxl_event.h is included in libxl.h. So, the former one also need to =
be installed. =20
b, define __XEN_TOOLS__ in libxl.h:=20
the head file "xen/sysctl.h" need check this macro. =20
It is the same way used by the xen libxc public headers(tools/libxc/xenctrl=
.h and tools/libxc/xenctrlosdep.h). =20

Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>=20

diff -r 87218bd367be tools/libxl/Makefile=20
--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/MakefileMon Feb 20 15:36:09 2012 +0800=20
@@ -163,7 +163,7 @@=20
 ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.=
so.$(XLUMAJOR)=20
 ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so=20
 $(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR)=20
-$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)=20
+$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h libxl_event.h $(DESTDIR)$(INCLUDED=
IR)=20
 $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh=20
 =20
 .PHONY: clean=20

diff -r 87218bd367be tools/libxl/libxl.h=20
--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/libxl.hMon Feb 20 15:36:09 2012 +0800=20
@@ -127,6 +127,11 @@=20
 #ifndef LIBXL_H=20
 #define LIBXL_H=20
 =20
+/* Tell the Xen public headers we are a user-space tools build. */=20
+#ifndef __XEN_TOOLS__=20
+#define __XEN_TOOLS__ 1=20
+#endif =20
+=20
 #include <stdbool.h>=20
 #include <stdint.h>=20
 #include <stdarg.h> 

--=__PartD5FBD5BB.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html>=0A  <head>=0A=0A  </head>=0A  <body style=3D"margin-bottom: 1px; =
margin-top: 4px; margin-right: 4px; margin-left: 4px; line-height: normal; =
font-variant: normal">=0A<br>      =0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">a&#4=
4; libxl_event.h is included in libxl.h. So&#44; the former one also need =
to be installed. </font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">b&#4=
4; define __XEN_TOOLS__ in libxl.h:</font>    </p>=0A    <p style=3D"margin=
-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">the head file &quot;xen/sysctl.h&quot; need check this macro. =
</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A     =
 <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">It is the same way used by =
the xen libxc public headers&#40;tools/libxc/xenctrl.h and tools/libxc/xenc=
trlosdep.h&#41;. </font>    </p>=0A<br>      =0A    <p style=3D"margin-bott=
om: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">Signed-off-by: Bamvor Jian Zhang &lt;bjzhang@suse.com&gt;</font>=
    </p>=0A<br>      =0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/Makefile</font>    </p>=0A    <p style=3D"margin-b=
ottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 &#43;0000</fo=
nt>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/MakefileMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -163&#44;7 &#43;163&#44;7 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;ln -sf libxlutil.so.&#36;&#4=
0;XLUMAJOR&#41;.&#36;&#40;XLUMINOR&#41; &#36;&#40;DESTDIR&#41;&#36;&#40;LIB=
DIR&#41;/libxlutil.so.&#36;&#40;XLUMAJOR&#41;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&nbsp;ln -sf libxlutil.so.&#36;&#40;XLUMAJOR&#41=
; &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;/libxlutil.so</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#36;&#40;INSTALL_DATA&#41; =
libxlutil.a &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;</font>    </p>=0A  =
  <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR =
PL ShanHeiSun Uni" size=3D"4">-&#36;&#40;INSTALL_DATA&#41; libxl.h =
libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h libxl_utils.h=
 libxl_uuid.h &#36;&#40;DESTDIR&#41;&#36;&#40;INCLUDEDIR&#41;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#36;&#40;INSTALL_DATA&#41; =
libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h =
libxl_utils.h libxl_uuid.h libxl_event.h &#36;&#40;DESTDIR&#41;&#36;&#40;IN=
CLUDEDIR&#41;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top=
: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#36;&#4=
0;INSTALL_DATA&#41; bash-completion &#36;&#40;DESTDIR&#41;&#36;&#40;BASH_CO=
MPLETION_DIR&#41;/xl.sh</font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbs=
p;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A   =
   <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;.PHONY: clean</font=
>    </p>=0A<br>      =0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/libxl.h</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 &#43;0000</fon=
t>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/libxl.hMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -127&#44;6 &#43;127&#44;11 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;ifndef LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;define LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;/&#42; Tell the Xen public headers we are =
a user-space tools build. &#42;/</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">&#43;&#35;ifndef __XEN_TOOLS__</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;&#35;define __XEN_TOOLS__ 1</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#35;endif </font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&nbsp;&#35;include &lt;stdbool.h&gt;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;include &lt;stdint.h&gt=
;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A    =
  <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&nbsp;&#35;include =
&lt;stdarg.h&gt;</font>    </p>=0A  </body>=0A</html>=0A

--=__PartD5FBD5BB.1__=--

--=__PartD5FBD5BB.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

--=__PartD5FBD5BB.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq4E-0003da-Or; Tue, 21 Feb 2012 13:47:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzWvG-0002yU-2t
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 17:21:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329758416!55008265!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27502 invoked from network); 20 Feb 2012 17:20:16 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:20:16 -0000
Received: by wibhi20 with SMTP id hi20so2797393wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 09:21:08 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.107.67 as permitted sender) client-ip=10.180.107.67; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.107.67 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.107.67])
	by 10.180.107.67 with SMTP id ha3mr18850394wib.8.1329758468300
	(num_hops = 1); Mon, 20 Feb 2012 09:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=8ZVYTL1+wmeB4p1PV7BJB+zFyGjS01MYEsGbyKCD1IM=;
	b=vQhNlaz3My2yrEEfGH3Phdh3lI0cvq+8esL7rzvwP0PFMZq24yWMJlgp4/t2YDwwEd
	jfXjlBdGvBfeTlT9d78jr5ii0G8CxaNdWTUsCspYasgyi4OwCSq6E8eHt5IsH2Q5HiyO
	gIGG5uIVq8JUjt4fuvCqfy+2OKMAwDZkmXJyo=
Received: by 10.180.107.67 with SMTP id ha3mr15655793wib.8.1329758468032;
	Mon, 20 Feb 2012 09:21:08 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id hs6sm8176629wib.2.2012.02.20.09.21.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 09:21:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ccdf9ed8a9141d2f5293580040605e95c6908b43
Message-Id: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 20 Feb 2012 18:20:45 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] build: add autoconf to replace custom checks in
	tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5NzU4NDI5IC0zNjAwCiMgTm9kZSBJRCBjY2RmOWVkOGE5
MTQxZDJmNTI5MzU4MDA0MDYwNWU5NWM2OTA4YjQzCiMgUGFyZW50ICA4NzIxOGJkMzY3YmVmY2E3
ZDM0ODhiYTFjZjRmZWIyYjEwZDVmMTRlCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdoZXJl
LCBhbmQgaXMgYXV0b21hdGljYWxseSBjcmVhdGVkIGJ5CmF1dG9oZWFkZXIsIGFsdG91Z2ggdGhp
cyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvIGluY2x1ZGUgdGhpcwpmaWxlLgoKSnVzdCBh
IGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJ
IGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjQ6CgogKiBVcGRhdGVkIHRvIHRp
cC4KCiAqIEluY2x1ZGUgY29uZmlnLmggZnJvbSBjb21waWxlciBjb21tYW5kIGxpbmUgd2hlbiBi
dWlsZGluZyBsaWJ4bCBhbmQKICAgeGwgdG8gYXNzdXJlIHlhamxfdmVyc2lvbi5oIHByZXNlbmNl
IGFuZCBjb3JyZWN0bHkgZGV0ZWN0IHlhamwKICAgdmVyc2lvbi4KCiAqIEFkZGVkIGdsaWItMi4w
IGNoZWNrLgoKQ2hhbmdlcyBzaW5jZSB2MzoKCiAqIENvcGllZCBjb25maWcuZ3Vlc3MgYW5kIGNv
bmZpZy5zdWIgZnJvbSBhdXRvbWFrZSAxLjExLgoKICogQWRkZWQgYSB0ZXN0IHRvIGNoZWNrIGZv
ciB1dWlkLmggb24gQlNEIGFuZCB1dWlkL3V1aWQuaCBvbiBMaW51eC4KCkNoYW5nZXMgc2luY2Ug
djI6CgogKiBDaGFuZ2VkIG9yZGVyIG9mIGNvbmZpZy9Ub29scy5tayBpbmNsdWRlLgoKICogQWRk
ZWQgIi1lIiB0byBhdXRvZ2VuLnNoIHNoZWJhbmcuCgogKiBBZGRlZCBuZWNlc3NhcnkgZmlsZXMg
KGNvbmZpZy4qKSBhbmQgb3V0cHV0IGZyb20gQXV0b2hlYWRlciBhbmQKICAgQXV0b2NvbmYuCgog
KiBSZW1vdmVkIEF1dG9jb25mIGZyb20gYnVpbGQgZGVwZW5kZW5jaWVzIGFuZCB1cGRhdGVkIFJF
QURNRS4KCkNoYW5nZXMgc2luY2UgdjE6CgogKiBNb3ZlZCBhdXRvY29uZiBzdHVmZiBpbnNpZGUg
dG9vbHMgZm9sZGVyLgoKICogQWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBjbGVhbmluZy4KCiAqIFJl
bW92ZWQgQXV0b21ha2UgZGVwZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRvZ2VuLnNoIHRvIGF1dG9t
YXRpY2FsbHkgY3JlYXRlIGNvbmZpZ3VyZSBzY3JpcHQgd2hlbgogICBidWlsZGluZyBmcm9tIHNv
dXJjZSByZXBvc2l0b3J5LgoKICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRpb25zIHBhc3NlZCBmcm9t
IGNvbW1hbmQgbGluZS4KCiAqIEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0byAuaGdpZ25vcmUuCgog
KiBBZGRlZCBBdXRvY29uZiB0byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNpZXMuCgogKiBDaGFuZ2Vk
IGh5cGVuIHRvIHVuZGVyc2NvcmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJpYWJsZSBuYW1lcy4KCiAq
IEFkZGVkIHNjcmlwdCB0byBnZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtlZmlsZS4KCiAqIFNldCBP
Y2FtbCB0b29scyB0byBvcHRpb25hbC4KCiAqIEFkZGVkIHByb2NlZGVuY2Ugb2YgbTQvb2NhbWwu
bTQuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMu
ZWR1PgoKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IC5oZ2lnbm9yZQotLS0g
YS8uaGdpZ25vcmUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiLy5oZ2lnbm9y
ZQlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTMwMyw2ICszMDMsMTIgQEAKIF50
b29scy9vY2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbCQKIF50b29scy9vY2FtbC9saWJzL3hsL3hl
bmxpZ2h0XC5tbGkkCiBedG9vbHMvb2NhbWwveGVuc3RvcmVkL294ZW5zdG9yZWQkCitedG9vbHMv
YXV0b200dGVcLmNhY2hlJAorXnRvb2xzL2NvbmZpZ1wuaCQKK150b29scy9jb25maWdcLmxvZyQK
K150b29scy9jb25maWdcLnN0YXR1cyQKK150b29scy9jb25maWdcLmNhY2hlJAorXmNvbmZpZy9U
b29sc1wubWskCiBeeGVuL1wuYmFubmVyLiokCiBeeGVuL0JMT0ckCiBeeGVuL1N5c3RlbS5tYXAk
CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCBDb25maWcubWsKLS0tIGEvQ29u
ZmlnLm1rCUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgYi9Db25maWcubWsJTW9u
IEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC03MCw5ICs3MCw2IEBAIEVYVFJBX0lOQ0xV
REVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVYVFJBX1BSRUZJ
WCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJPz0gZmxleAot
CiBQWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0tcHJlZml4PSIk
KFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250YWlucyAqbm8g
c3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCkBAIC0xNzUsMzIgKzE3Miw5IEBAIENGTEFH
UyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9MREZMQUdTICs9ICQo
Zm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZMQUdTICs9ICQoZm9y
ZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tfTElCID0gJChFWFRS
QV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lOQ0xVREVTID0gJChF
WFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9JTkNMVURFUykKLQog
RU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyArPSAtZm5vLWV4Y2Vw
dGlvbnMKIAotQ09ORklHX0xJQklDT05WICAgOj0gJChzaGVsbCBleHBvcnQgT1M9ImB1bmFtZSAt
c2AiOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGV4cG9ydCBDSEVDS19MSUI9IiQoQ0hFQ0tf
TElCKSI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgLiAkKFhFTl9ST09UKS90b29scy9jaGVj
ay9mdW5jcy5zaDsgXAotICAgICAgICAgICAgICAgICAgICAgICBoYXNfbGliIGxpYmljb252LnNv
ICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi1DT05GSUdfWUFKTF9WRVJTSU9OIDo9ICQoc2hl
bGwgZXhwb3J0IE9TPSJgdW5hbWUgLXNgIjsgXAotICAgICAgICAgICAgICAgICAgICAgICBleHBv
cnQgQ0hFQ0tfSU5DTFVERVM9IiQoQ0hFQ0tfSU5DTFVERVMpIjsgXAotICAgICAgICAgICAgICAg
ICAgICAgICAuICQoWEVOX1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNoOyBcCi0gICAgICAgICAg
ICAgICAgICAgICAgIGhhc19oZWFkZXIgeWFqbC95YWpsX3ZlcnNpb24uaCAmJiBlY2hvICd5JyB8
fCBlY2hvICduJykKLQotIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwg
Rmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1GTEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxFKQot
Ci0jIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHByb3Rv
Y29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVuIGl0
IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0jIG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQgdGhl
IGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWlsIG9y
IGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4KLUdJ
VF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVTX1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhlIGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2VyZSBk
b3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9uCiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmlnaW5h
bCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVkIGFzIGEgY29tbWVudApAQCAtMjM5LDE3ICsyMTMs
NCBAQCBRRU1VX1RBRyA/PSA0MTRiODc4ZThlYTE3YzY1Y2QwZDdmOWRmYzM4CiAjIFNob3J0IGFu
c3dlciAtLSBkbyBub3QgZW5hYmxlIHRoaXMgdW5sZXNzIHlvdSBrbm93IHdoYXQgeW91IGFyZQog
IyBkb2luZyBhbmQgYXJlIHByZXBhcmVkIGZvciBzb21lIHBhaW4uCiAKLSMgT3B0aW9uYWwgY29t
cG9uZW50cwotWEVOU1RBVF9YRU5UT1AgICAgID89IHkKLVZUUE1fVE9PTFMgICAgICAgICA/PSBu
Ci1MSUJYRU5BUElfQklORElOR1MgPz0gbgotUFlUSE9OX1RPT0xTICAgICAgID89IHkKLU9DQU1M
X1RPT0xTICAgICAgICA/PSB5Ci1DT05GSUdfTUlOSVRFUk0gICAgPz0gbgotQ09ORklHX0xPTU9V
TlQgICAgID89IG4KLUNPTkZJR19TWVNURU1fTElCQUlPID89IHkKIENPTkZJR19URVNUUyAgICAg
ICA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9PTFMpLHkpCi1PQ0FNTF9UT09MUyA6PSAkKHNoZWxs
IG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyAieSIgfHwgZWNobyAibiIpCi1l
bmRpZgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgTWFrZWZpbGUKLS0tIGEv
TWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiL01ha2VmaWxlCU1v
biBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDogREVT
VERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRpc3Q6IGRpc3QteGVuIGRpc3Qta2VybmVscyBkaXN0
LXRvb2xzIGRpc3Qtc3R1YmRvbSBkaXN0LWRvY3MgZGlzdC1taXNjCiAKIGRpc3QtbWlzYzoKLQkk
KElOU1RBTExfRElSKSAkKERJU1RESVIpL2NoZWNrCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09QWUlO
RyAkKERJU1RESVIpCiAJJChJTlNUQUxMX0RBVEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkkKElO
U1RBTExfUFJPRykgLi9pbnN0YWxsLnNoICQoRElTVERJUikKLQkkKElOU1RBTExfUFJPRykgdG9v
bHMvY2hlY2svY2hrIHRvb2xzL2NoZWNrL2NoZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2ggJChE
SVNURElSKS9jaGVjawogZGlzdC0lOiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdC0l
OiBpbnN0YWxsLSUKIAlAOiAjIGRvIG5vdGhpbmcKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2Nk
ZjllZDhhOTE0IFJFQURNRQotLS0gYS9SRUFETUUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICsw
MDAwCisrKyBiL1JFQURNRQlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTg5LDkg
Kzg5LDEzIEBAIDIuIGNkIHRvIHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKIDMuIEZv
ciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWlsZCB0
cmVlcywKICAgIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwczoKIAorICAgICMgLi9jb25maWd1
cmUKICAgICAjIG1ha2Ugd29ybGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ugd2Fu
dCwgeW91IGNhbiBydW4gLi9jb25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgorICAg
b3B0aW9ucyBhdmFpbGFibGUgb3B0aW9ucyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5nIFhl
bi4KKwogICAgVGhpcyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBtYWNo
aW5lLiBJdCB3aWxsIGJ1aWxkCiAgICB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRvb2xz
IGFuZCB0aGUgZG9jdW1lbnRhdGlvbi4KIApkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVk
OGE5MTQgYXV0b2dlbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9hdXRvZ2VuLnNoCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAt
MCwwICsxLDggQEAKKyMhL2Jpbi9zaCAtZQorcm0gLXJmIGNvbmZpZ3VyZQorY2QgdG9vbHMKK2F1
dG9jb25mCitjZCAuLgorZWNobyAiIyEvYmluL3NoIC1lIiA+PiBjb25maWd1cmUKK2VjaG8gImNk
IHRvb2xzICYmIC4vY29uZmlndXJlIFwkQCIgPj4gY29uZmlndXJlCitjaG1vZCAreCBjb25maWd1
cmUKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IGNvbmZpZy9Ub29scy5tay5p
bgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25m
aWcvVG9vbHMubWsuaW4JTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEs
NTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklYICAgICAgICAgICAgICA6
PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BBVEhACisKKyMgQSBkZWJ1
ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0gQGRlYnVnQAorCisjIFRv
b2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAorRkxFWCAgICAgICAgICAg
ICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZVEhPTkAKK1BZVEhPTl9Q
QVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAgICAgICAgIDo9IEBQRVJM
QAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAgICAgICAgICAgICAgIDo9
IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwyX0NPTkZJRyAgICAgICAg
IDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAorWEdFVFRURVhUICAgICAg
ICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBsaWJzL2luY2x1ZGVzCitQ
UkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAorUFJFUEVORF9MSUIgICAg
ICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAgIDo9IEBBUFBFTkRfSU5D
TFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElCQAorCisjIEVuYWJsZSBY
U00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitYU01fRU5BQkxFICAgICAg
ICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21ACisKKyMgRG93bmxvYWQg
R0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJvdG9jb2w/CisjIEdJVCdz
IHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxs
IChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0
IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwgb3IgaGFuZywgcGxlYXNl
IHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50LgorR0lUX0hUVFAgICAgICAg
ICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRzCitYRU5TVEFUX1hFTlRP
UCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAgOj0gQHZ0cG1ACitMSUJY
RU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAgICAgICA6PSBAcHl0aG9u
dG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xzQAorQ09ORklHX01JTklU
RVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAgIDo9IEBsb21vdW50QAor
CisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0gQHN5c3RlbV9haW9ACitD
T05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19HQ1JZUFQgICAgICAgOj0g
QGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4dDJmc0AKZGlmZiAtciA4
NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IGNvbmZpZ3VyZQotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJTW9uIEZlYiAyMCAxODoy
MDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3NoIC1lCitjZCB0b29scyAm
JiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9v
bHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEy
ICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEw
MApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlvCiBlbmRpZgogCiBTVUJE
SVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9IGluY2x1ZGUKIFNVQkRJ
UlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2ICs3OCw4IEBAIGNsZWFu
OiBzdWJkaXJzLWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNsZWFuCiAJcm0gLXJmIHFl
bXUteGVuLXRyYWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtb3RlCiAJ
cm0gLXJmIHFlbXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJcm0gLXJmIC4uL2NvbmZp
Zy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAorCQljb25maWcu
Y2FjaGUgYXV0b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJTEVfQVJDSCksJChYRU5f
VEFSR0VUX0FSQ0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0tY3B1PSQoWEVOX1RBUkdF
VF9BUkNIKSBcCmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9SdWxl
cy5tawotLS0gYS90b29scy9SdWxlcy5tawlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAK
KysrIGIvdG9vbHMvUnVsZXMubWsJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC00
LDYgKzQsNyBAQAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5taworaW5jbHVk
ZSAkKFhFTl9ST09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5T
VEFMTCkKIElOU1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1pbnN0YWxsCkBAIC04MCw4
ICs4MSw2IEBAIGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2MtdmVyLWNoZWMKICAgICAg
ICAgICAgICAgICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3QgZ2NjLTMuNCIpCiAkKGV2
YWwgJChjaGVjay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwgd2hpY2ggJChQWVRIT04p
KQotUFlUSE9OX1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxMX1BZVEhPTl9QUk9HID0g
XAogCSQoWEVOX1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAgIiQoUFlUSE9OX1BBVEgp
IiAkKElOU1RBTExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1YmRpci1hbGwtJSBzdWJk
aXItY2xlYW4tJSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVhbi0lOiAucGhvbnkKIAkk
KE1BS0UpIC1DICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9Ub29scy5tazoKKwlAZWNo
byAiWW91IGhhdmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWlsZGluZyBvciBpbnN0YWxs
aW5nIHRoZSB0b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4
YTkxNCB0b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90b29scy9ibGt0YXAvZHJp
dmVycy9NYWtlZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMv
YmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBA
IC0xMyw3ICsxMyw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKQogQ0ZMQUdT
ICAgKz0gLUkgJChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05VX1NPVVJDRQogCi1pZmVx
ICgkKHNoZWxsIC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lmZXEgKCRDT05GSUdfR0NS
WVBULHkpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIgOj0gLWxnY3J5cHQKIGVs
c2UKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2Jsa3RhcC9kcml2
ZXJzL2NoZWNrX2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQJ
RnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAotCi1jYXQgPiAu
Z2NyeXB0LmMgPDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQgbWFpbih2b2lkKSB7IHJl
dHVybiAwOyB9Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0LmMgLWxnY3J5cHQgMj4v
ZGV2L251bGwgOyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNobyAibm8iCi1maQotCi1y
bSAtZiAuZ2NyeXB0KgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMv
Y2hlY2svTWFrZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoy
NDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uCi1pbmNsdWRl
ICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRoZSBuZWNlc3NhcnkgZW52
aXJvbm1lbnQgdmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQWVRIT04KLWV4cG9ydCBM
SUJYRU5BUElfQklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwotZXhwb3J0IENIRUNLX0xJ
QgotZXhwb3J0IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTogYWxsIGluc3RhbGwKLWFs
bCBpbnN0YWxsOiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3Ig
YnVpbGRpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1idWlsZDoKLQkuL2NoayBi
dWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5zdGFsbGluZyBvbi4KLS5Q
SE9OWTogY2hlY2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2NoayBpbnN0YWxsCi0KLS5Q
SE9OWTogY2xlYW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9vbHMvY2hlY2svUkVBRE1F
CUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVja3MgZm9yIHRoZSBzdWl0
YWJpbGl0eSBvZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLgotVG8gY2hlY2sg
Zm9yIGJ1aWxkIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGJ1aWxkCi0KLVRvIGNo
ZWNrIGZvciBpbnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGluc3RhbGwK
LQotVGhlIGNoayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMgZGlyZWN0b3J5IGFuZCBw
cmludAotdGhlIG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3RoaW5nIGlmIGNoZWNrcyBz
dWNjZWVkLgotVGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1Y2Nlc3MgYW5kIDEgb24g
ZmFpbHVyZS4KLQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxlIGZpbGVzIGluIHRoaXMg
ZGlyZWN0b3J5IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18nLiBGaWxlcyBjb250YWlu
aW5nIENIRUNLLUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hlY2ssIGFuZCBmaWxlcyBj
b250YWluaW5nIENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBpbnN0YWxsIGNoZWNrLgot
Ci1EZXRhaWxlZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBpcyBpbiAuY2hrYnVpbGQg
Zm9yIGJ1aWxkCi1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwgTm8gbmV3bGluZSBhdCBl
bmQgb2YgZmlsZQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY2hl
Y2svY2hlY2tfYnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwJRnJpIEZlYiAxNyAx
MjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4g
Li9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNf
b3JfZmFpbCBicmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwgYnJjdGwgOzsKLSopCi0J
ZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjll
ZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hl
Y2tfY3J5cHRvX2xpYglGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAotIyEvYmlu
L3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2Ug
JE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7OwotZXNhYwotCi1oYXNf
bGliIGxpYmNyeXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0by5zbyIKZGlmZiAtciA4
NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX2N1cmwKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfY3VybAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAsMCBA
QAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNo
Ci0KLWlmIFsgIiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0aGVuCi0JZWNobyAtbiAi
dW51c2VkLCAiCi0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJsLWNvbmZpZwotY3VybF9s
aWJzPWBjdXJsLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29uZmlnIC0tbGlicyBmYWls
ZWQiCi10ZXN0X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxpYnJhcmllcyBm
b3IgY3VybCBhcmUgbWlzc2luZyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0
IHRvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfaXByb3V0
ZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBBVEgKLQotY2FzZSAkT1Mg
aW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgaWZjb25maWcgOzsKLUxp
bnV4KQotCWhhc19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2Fj
CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja19s
aWJhaW9fZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCUZyaSBGZWIg
MTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQot
LiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7
IHRoZW4KLSAgICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGliYWlvLmggOyB0aGVuCi0g
ICAgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFsbCBsaWJhaW8gZGV2ZWwg
cGFja2FnZSBvciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZpCmRpZmYgLXIgODcyMThi
ZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja19saWJhaW9fbGliCi0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDkg
KzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1
bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7IHRoZW4K
LSAgICBleGl0IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIGxp
YmFpbyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2No
ZWNrX29wZW5zc2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAlG
cmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJ
TEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9tZDUuaCB8fCBmYWlsICJt
aXNzaW5nIG9wZW5zc2wgaGVhZGVycyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhh
OTE0IHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9jaGVjay9jaGVja19weXRo
b24JRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlU
SE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhPTn0gLWMgJwotaW1wb3J0
IHN5cwotc3lzLmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Igc3lzLnZlcnNpb25faW5m
b1sxXSA8IDMpCi0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24gPj0gMi4zIgpkaWZmIC1y
IDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX2Rl
dmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlGcmkgRmViIDE3IDEyOjI0
OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5j
cy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQot
aGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgb3MucGF0aCwg
c3lzCi1mb3IgcCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcv
TWFrZWZpbGUiKToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0nIHx8IGZhaWwgImNhbid0
IGZpbmQgcHl0aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVk
OGE5MTQgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90b29scy9jaGVjay9jaGVj
a19weXRob25feG1sCUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhP
Tn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0k
e1BZVEhPTn0gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rldi9udWxsIHx8IFwKLWZh
aWwgImNhbid0IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3VkZXYJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxO
ZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7Ci1MaW51eCkKLQloYXMg
L3NiaW4vdWRldmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZhZG0gaW5mbyAtViB8IGF3
ayAne3ByaW50ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhhc19vcl9mYWlsIHVkZXZp
bmZvICYmIFwKLQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlb
ICIkdWRldnZlciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQloYXMgaG90cGx1ZyB8fCBc
Ci0JCWZhaWwgInVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVy
IgotCTs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMKZGlmZiAtciA4NzIxOGJk
MzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNyAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19o
ZWFkZXIgdXVpZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmggfHwgZmFpbCAibWlzc2lu
ZyB1dWlkIGhlYWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAt
ciBjY2RmOWVkOGE5MTQgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3gxMV9kZXZlbAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgWDEx
L2tleXN5bWRlZi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9pbmNsdWRlL1gxMS9rZXlz
eW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVkZS9YMTEva2V5c3ltZGVm
LmggfHwgXAotd2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIKZGlmZiAtciA4NzIxOGJk
MzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0Ci0tLSBhL3Rv
b2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0CUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw2ICswLDAg
QEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX29yX2Zh
aWwgeGdldHRleHQKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2No
ZWNrL2NoZWNrX3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1sMglGcmkgRmViIDE3IDEy
OjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlO
U1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQSV9CSU5ESU5HUyIgPSAi
eSIgXQotdGhlbgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4aXQgMAotZmkKLQotaGFz
X29yX2ZhaWwgeG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25maWcgLS1saWJzYCB8fCBm
YWlsICJ4bWwyLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICR4bWwyX2xpYnMgfHwg
ZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1pc3NpbmciCmRpZmYgLXIg
ODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja195YWpsX2RldmVs
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJRnJpIEZlYiAxNyAxMjoyNDozOCAy
MDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBA
IC0xLDggKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAot
Ci1oYXNfaGVhZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95
YWpsX3BhcnNlLmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8fCBmYWlsICJjYW4ndCBm
aW5kIHlhamwveWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8fCBmYWlsICJjYW4ndCBm
aW5kIGxpYnlhamwuc28iCmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29s
cy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJfZGV2
ZWwJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBmYWlsICJjYW4n
dCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0
IHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJf
bGliCUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZy
ZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJ6
LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2Nk
ZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJRnJpIEZlYiAx
NyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3VzYWdlICgpCi17
Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFsbHxjbGVhbl0i
Ci0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4gYnVpbGQgb3Ig
aW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90LiIKLSAgICBl
Y2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5lcmF0ZWQgZmls
ZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2JpbgotT1M9YHVu
YW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIgXTsgdGhlbgot
CWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBjaGVjaz0iQ0hF
Q0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hlY2s9IkNIRUNL
LUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQgMAotICAgICAg
ICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVzYWMKLQotZmFp
bGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBjaGVja18qIDsg
ZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29udGludWUKLSAg
ICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVzYWMKLSAgICBp
ZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAgIGlmICEg
Z3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0gICAgZmkKLSAg
ICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRoZW4KLSAgICAg
ICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQotZG9uZQotCi1l
eGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMv
Y2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJRnJpIEZlYiAxNyAxMjoy
NDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGljaCwgZXhjZXB0
IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAteiAiJENST1NT
X0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVybiAkPwotCWZp
Ci0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50
IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBpbiAkUEFUSDsg
ZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0JCQllY2hvICIk
Q1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUKLQlyZXR1cm4g
MQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVsbCB8fCBmYWls
ICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5c19yb290IHx8
IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBbIC1yICIkQ1JP
U1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAwCi0JCWZpCi0J
CWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAiJENST1NTX1NZ
U19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQotCQlkb25lCi0J
CTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVja19zeXNfcm9v
dCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxs
ZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAjIGZvciBsZGNv
bmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhpcyByZWxhdGl2
ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0Ci0JIyBsZGNv
bmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3JrLgotCWlmIFsg
IiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNvLmNhY2hlIiBd
OyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JPU1NfU1lTX1JP
T1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91Z2g7IGxkY29u
ZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJMaW51eCIg
XTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JPU1NfU1lTX1JP
T1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIke09TfSIgPSAi
TmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZxICIkMSIKLQkJ
cmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkgewotCSMgc3Vi
c2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1wZmlsZQotCXRy
YXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1gbWt0ZW1wYCB8
fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+JjEKLQlyZXR1
cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5IGFib3ZlCi1j
aGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiByZXR1cm4gMAot
CWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVhc2Ugc2V0IENS
T1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlmaQotCWlmIFsg
ISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1yb290IGZvdW5k
IGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJuaW5nKCkgewot
CWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAkKn0iCi19Ci0K
LWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6
ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRv
b2xzL2NvbmZpZy5ndWVzcwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi90b29scy9jb25maWcuZ3Vlc3MJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTUyMiBAQAorIyEgL2Jpbi9zaAorIyBBdHRlbXB0IHRvIGd1ZXNzIGEg
Y2Fub25pY2FsIHN5c3RlbSBuYW1lLgorIyAgIENvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5
NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwKKyMgICAyMDAwLCAyMDAxLCAyMDAyLCAy
MDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEwLAorIyAgIDIwMTEg
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3RpbWVzdGFtcD0nMjAxMS0xMS0xMScK
KworIyBUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeSBpdAorIyB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRp
b24pIGFueSBsYXRlciB2ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJVEhPVVQgQU5ZIFdB
UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRB
QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUK
KyMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hv
dWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZQorIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBT
b2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQgLSBGaWZ0aCBG
bG9vciwgQm9zdG9uLCBNQQorIyAwMjExMC0xMzAxLCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBl
eGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlz
dHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250YWlucyBhCisj
IGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNs
dWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2Ug
Zm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KKworCisjIE9yaWdpbmFsbHkgd3JpdHRlbiBi
eSBQZXIgQm90aG5lci4gIFBsZWFzZSBzZW5kIHBhdGNoZXMgKGNvbnRleHQKKyMgZGlmZiBmb3Jt
YXQpIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPiBhbmQgaW5jbHVkZSBhIENoYW5nZUxvZwor
IyBlbnRyeS4KKyMKKyMgVGhpcyBzY3JpcHQgYXR0ZW1wdHMgdG8gZ3Vlc3MgYSBjYW5vbmljYWwg
c3lzdGVtIG5hbWUgc2ltaWxhciB0bworIyBjb25maWcuc3ViLiAgSWYgaXQgc3VjY2VlZHMsIGl0
IHByaW50cyB0aGUgc3lzdGVtIG5hbWUgb24gc3Rkb3V0LCBhbmQKKyMgZXhpdHMgd2l0aCAwLiAg
T3RoZXJ3aXNlLCBpdCBleGl0cyB3aXRoIDEuCisjCisjIFlvdSBjYW4gZ2V0IHRoZSBsYXRlc3Qg
dmVyc2lvbiBvZiB0aGlzIHNjcmlwdCBmcm9tOgorIyBodHRwOi8vZ2l0LnNhdmFubmFoLmdudS5v
cmcvZ2l0d2ViLz9wPWNvbmZpZy5naXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmlnLmd1ZXNzO2hiPUhF
QUQKKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdlPSJcCitVc2Fn
ZTogJDAgW09QVElPTl0KKworT3V0cHV0IHRoZSBjb25maWd1cmF0aW9uIG5hbWUgb2YgdGhlIHN5
c3RlbSBcYCRtZScgaXMgcnVuIG9uLgorCitPcGVyYXRpb24gbW9kZXM6CisgIC1oLCAtLWhlbHAg
ICAgICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtdCwgLS10aW1lLXN0YW1wICAg
cHJpbnQgZGF0ZSBvZiBsYXN0IG1vZGlmaWNhdGlvbiwgdGhlbiBleGl0CisgIC12LCAtLXZlcnNp
b24gICAgICBwcmludCB2ZXJzaW9uIG51bWJlciwgdGhlbiBleGl0CisKK1JlcG9ydCBidWdzIGFu
ZCBwYXRjaGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4iCisKK3ZlcnNpb249IlwKK0dO
VSBjb25maWcuZ3Vlc3MgKCR0aW1lc3RhbXApCisKK09yaWdpbmFsbHkgd3JpdHRlbiBieSBQZXIg
Qm90aG5lci4KK0NvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5
NywgMTk5OCwgMTk5OSwgMjAwMCwKKzIwMDEsIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYs
IDIwMDcsIDIwMDgsIDIwMDksIDIwMTAsIDIwMTEgRnJlZQorU29mdHdhcmUgRm91bmRhdGlvbiwg
SW5jLgorCitUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUgc291cmNlIGZvciBjb3B5aW5n
IGNvbmRpdGlvbnMuICBUaGVyZSBpcyBOTword2FycmFudHk7IG5vdCBldmVuIGZvciBNRVJDSEFO
VEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIgorCitoZWxwPSIK
K1RyeSBcYCRtZSAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uLiIKKworIyBQYXJzZSBjb21t
YW5kIGxpbmUKK3doaWxlIHRlc3QgJCMgLWd0IDAgOyBkbworICBjYXNlICQxIGluCisgICAgLS10
aW1lLXN0YW1wIHwgLS10aW1lKiB8IC10ICkKKyAgICAgICBlY2hvICIkdGltZXN0YW1wIiA7IGV4
aXQgOzsKKyAgICAtLXZlcnNpb24gfCAtdiApCisgICAgICAgZWNobyAiJHZlcnNpb24iIDsgZXhp
dCA7OworICAgIC0taGVscCB8IC0taCogfCAtaCApCisgICAgICAgZWNobyAiJHVzYWdlIjsgZXhp
dCA7OworICAgIC0tICkgICAgICMgU3RvcCBvcHRpb24gcHJvY2Vzc2luZworICAgICAgIHNoaWZ0
OyBicmVhayA7OworICAgIC0gKQkjIFVzZSBzdGRpbiBhcyBpbnB1dC4KKyAgICAgICBicmVhayA7
OworICAgIC0qICkKKyAgICAgICBlY2hvICIkbWU6IGludmFsaWQgb3B0aW9uICQxJGhlbHAiID4m
MgorICAgICAgIGV4aXQgMSA7OworICAgICogKQorICAgICAgIGJyZWFrIDs7CisgIGVzYWMKK2Rv
bmUKKworaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgIGVjaG8gIiRtZTogdG9vIG1hbnkgYXJndW1l
bnRzJGhlbHAiID4mMgorICBleGl0IDEKK2ZpCisKK3RyYXAgJ2V4aXQgMScgMSAyIDE1CisKKyMg
Q0NfRk9SX0JVSUxEIC0tIGNvbXBpbGVyIHVzZWQgYnkgdGhpcyBzY3JpcHQuIE5vdGUgdGhhdCB0
aGUgdXNlIG9mIGEKKyMgY29tcGlsZXIgdG8gYWlkIGluIHN5c3RlbSBkZXRlY3Rpb24gaXMgZGlz
Y291cmFnZWQgYXMgaXQgcmVxdWlyZXMKKyMgdGVtcG9yYXJ5IGZpbGVzIHRvIGJlIGNyZWF0ZWQg
YW5kLCBhcyB5b3UgY2FuIHNlZSBiZWxvdywgaXQgaXMgYQorIyBoZWFkYWNoZSB0byBkZWFsIHdp
dGggaW4gYSBwb3J0YWJsZSBmYXNoaW9uLgorCisjIEhpc3RvcmljYWxseSwgYENDX0ZPUl9CVUlM
RCcgdXNlZCB0byBiZSBuYW1lZCBgSE9TVF9DQycuIFdlIHN0aWxsCisjIHVzZSBgSE9TVF9DQycg
aWYgZGVmaW5lZCwgYnV0IGl0IGlzIGRlcHJlY2F0ZWQuCisKKyMgUG9ydGFibGUgdG1wIGRpcmVj
dG9yeSBjcmVhdGlvbiBpbnNwaXJlZCBieSB0aGUgQXV0b2NvbmYgdGVhbS4KKworc2V0X2NjX2Zv
cl9idWlsZD0nCit0cmFwICJleGl0Y29kZT1cJD87IChybSAtZiBcJHRtcGZpbGVzIDI+L2Rldi9u
dWxsOyBybWRpciBcJHRtcCAyPi9kZXYvbnVsbCkgJiYgZXhpdCBcJGV4aXRjb2RlIiAwIDsKK3Ry
YXAgInJtIC1mIFwkdG1wZmlsZXMgMj4vZGV2L251bGw7IHJtZGlyIFwkdG1wIDI+L2Rldi9udWxs
OyBleGl0IDEiIDEgMiAxMyAxNSA7Cis6ICR7VE1QRElSPS90bXB9IDsKKyB7IHRtcD1gKHVtYXNr
IDA3NyAmJiBta3RlbXAgLWQgIiRUTVBESVIvY2dYWFhYWFgiKSAyPi9kZXYvbnVsbGAgJiYgdGVz
dCAtbiAiJHRtcCIgJiYgdGVzdCAtZCAiJHRtcCIgOyB9IHx8CisgeyB0ZXN0IC1uICIkUkFORE9N
IiAmJiB0bXA9JFRNUERJUi9jZyQkLSRSQU5ET00gJiYgKHVtYXNrIDA3NyAmJiBta2RpciAkdG1w
KSA7IH0gfHwKKyB7IHRtcD0kVE1QRElSL2NnLSQkICYmICh1bWFzayAwNzcgJiYgbWtkaXIgJHRt
cCkgJiYgZWNobyAiV2FybmluZzogY3JlYXRpbmcgaW5zZWN1cmUgdGVtcCBkaXJlY3RvcnkiID4m
MiA7IH0gfHwKKyB7IGVjaG8gIiRtZTogY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFyeSBkaXJlY3Rv
cnkgaW4gJFRNUERJUiIgPiYyIDsgZXhpdCAxIDsgfSA7CitkdW1teT0kdG1wL2R1bW15IDsKK3Rt
cGZpbGVzPSIkZHVtbXkuYyAkZHVtbXkubyAkZHVtbXkucmVsICRkdW1teSIgOworY2FzZSAkQ0Nf
Rk9SX0JVSUxELCRIT1NUX0NDLCRDQyBpbgorICwsKSAgICBlY2hvICJpbnQgeDsiID4gJGR1bW15
LmMgOworCWZvciBjIGluIGNjIGdjYyBjODkgYzk5IDsgZG8KKwkgIGlmICgkYyAtYyAtbyAkZHVt
bXkubyAkZHVtbXkuYykgPi9kZXYvbnVsbCAyPiYxIDsgdGhlbgorCSAgICAgQ0NfRk9SX0JVSUxE
PSIkYyI7IGJyZWFrIDsKKwkgIGZpIDsKKwlkb25lIDsKKwlpZiB0ZXN0IHgiJENDX0ZPUl9CVUlM
RCIgPSB4IDsgdGhlbgorCSAgQ0NfRk9SX0JVSUxEPW5vX2NvbXBpbGVyX2ZvdW5kIDsKKwlmaQor
CTs7CisgLCwqKSAgIENDX0ZPUl9CVUlMRD0kQ0MgOzsKKyAsKiwqKSAgQ0NfRk9SX0JVSUxEPSRI
T1NUX0NDIDs7Citlc2FjIDsgc2V0X2NjX2Zvcl9idWlsZD0gOycKKworIyBUaGlzIGlzIG5lZWRl
ZCB0byBmaW5kIHVuYW1lIG9uIGEgUHlyYW1pZCBPU3ggd2hlbiBydW4gaW4gdGhlIEJTRCB1bml2
ZXJzZS4KKyMgKGdoYXppQG5vYy5ydXRnZXJzLmVkdSAxOTk0LTA4LTI0KQoraWYgKHRlc3QgLWYg
Ly5hdHRiaW4vdW5hbWUpID4vZGV2L251bGwgMj4mMSA7IHRoZW4KKwlQQVRIPSRQQVRIOi8uYXR0
YmluIDsgZXhwb3J0IFBBVEgKK2ZpCisKK1VOQU1FX01BQ0hJTkU9YCh1bmFtZSAtbSkgMj4vZGV2
L251bGxgIHx8IFVOQU1FX01BQ0hJTkU9dW5rbm93bgorVU5BTUVfUkVMRUFTRT1gKHVuYW1lIC1y
KSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfUkVMRUFTRT11bmtub3duCitVTkFNRV9TWVNURU09YCh1
bmFtZSAtcykgMj4vZGV2L251bGxgICB8fCBVTkFNRV9TWVNURU09dW5rbm93bgorVU5BTUVfVkVS
U0lPTj1gKHVuYW1lIC12KSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfVkVSU0lPTj11bmtub3duCisK
KyMgTm90ZTogb3JkZXIgaXMgc2lnbmlmaWNhbnQgLSB0aGUgY2FzZSBicmFuY2hlcyBhcmUgbm90
IGV4Y2x1c2l2ZS4KKworY2FzZSAiJHtVTkFNRV9NQUNISU5FfToke1VOQU1FX1NZU1RFTX06JHtV
TkFNRV9SRUxFQVNFfToke1VOQU1FX1ZFUlNJT059IiBpbgorICAgICo6TmV0QlNEOio6KikKKwkj
IE5ldEJTRCAobmJzZCkgdGFyZ2V0cyBzaG91bGQgKHdoZXJlIGFwcGxpY2FibGUpIG1hdGNoIG9u
ZSBvcgorCSMgbW9yZSBvZiB0aGUgdHVwcGxlczogKi0qLW5ldGJzZGVsZiosICotKi1uZXRic2Rh
b3V0KiwKKwkjICotKi1uZXRic2RlY29mZiogYW5kICotKi1uZXRic2QqLiAgRm9yIHRhcmdldHMg
dGhhdCByZWNlbnRseQorCSMgc3dpdGNoZWQgdG8gRUxGLCAqLSotbmV0YnNkKiB3b3VsZCBzZWxl
Y3QgdGhlIG9sZAorCSMgb2JqZWN0IGZpbGUgZm9ybWF0LiAgVGhpcyBwcm92aWRlcyBib3RoIGZv
cndhcmQKKwkjIGNvbXBhdGliaWxpdHkgYW5kIGEgY29uc2lzdGVudCBtZWNoYW5pc20gZm9yIHNl
bGVjdGluZyB0aGUKKwkjIG9iamVjdCBmaWxlIGZvcm1hdC4KKwkjCisJIyBOb3RlOiBOZXRCU0Qg
ZG9lc24ndCBwYXJ0aWN1bGFybHkgY2FyZSBhYm91dCB0aGUgdmVuZG9yCisJIyBwb3J0aW9uIG9m
IHRoZSBuYW1lLiAgV2UgYWx3YXlzIHNldCBpdCB0byAidW5rbm93biIuCisJc3lzY3RsPSJzeXNj
dGwgLW4gaHcubWFjaGluZV9hcmNoIgorCVVOQU1FX01BQ0hJTkVfQVJDSD1gKC9zYmluLyRzeXNj
dGwgMj4vZGV2L251bGwgfHwgXAorCSAgICAvdXNyL3NiaW4vJHN5c2N0bCAyPi9kZXYvbnVsbCB8
fCBlY2hvIHVua25vd24pYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORV9BUkNIfSIgaW4KKwkgICAg
YXJtZWIpIG1hY2hpbmU9YXJtZWItdW5rbm93biA7OworCSAgICBhcm0qKSBtYWNoaW5lPWFybS11
bmtub3duIDs7CisJICAgIHNoM2VsKSBtYWNoaW5lPXNobC11bmtub3duIDs7CisJICAgIHNoM2Vi
KSBtYWNoaW5lPXNoLXVua25vd24gOzsKKwkgICAgc2g1ZWwpIG1hY2hpbmU9c2g1bGUtdW5rbm93
biA7OworCSAgICAqKSBtYWNoaW5lPSR7VU5BTUVfTUFDSElORV9BUkNIfS11bmtub3duIDs7CisJ
ZXNhYworCSMgVGhlIE9wZXJhdGluZyBTeXN0ZW0gaW5jbHVkaW5nIG9iamVjdCBmb3JtYXQsIGlm
IGl0IGhhcyBzd2l0Y2hlZAorCSMgdG8gRUxGIHJlY2VudGx5LCBvciB3aWxsIGluIHRoZSBmdXR1
cmUuCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FX0FSQ0h9IiBpbgorCSAgICBhcm0qfGkzODZ8bTY4
a3xuczMya3xzaDMqfHNwYXJjfHZheCkKKwkJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorCQlpZiBl
Y2hvIF9fRUxGX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwgXAorCQkJfCBncmVw
IC1xIF9fRUxGX18KKwkJdGhlbgorCQkgICAgIyBPbmNlIGFsbCB1dGlsaXRpZXMgY2FuIGJlIEVD
T0ZGIChuZXRic2RlY29mZikgb3IgYS5vdXQgKG5ldGJzZGFvdXQpLgorCQkgICAgIyBSZXR1cm4g
bmV0YnNkIGZvciBlaXRoZXIuICBGSVg/CisJCSAgICBvcz1uZXRic2QKKwkJZWxzZQorCQkgICAg
b3M9bmV0YnNkZWxmCisJCWZpCisJCTs7CisJICAgICopCisJCW9zPW5ldGJzZAorCQk7OworCWVz
YWMKKwkjIFRoZSBPUyByZWxlYXNlCisJIyBEZWJpYW4gR05VL05ldEJTRCBtYWNoaW5lcyBoYXZl
IGEgZGlmZmVyZW50IHVzZXJsYW5kLCBhbmQKKwkjIHRodXMsIG5lZWQgYSBkaXN0aW5jdCB0cmlw
bGV0LiBIb3dldmVyLCB0aGV5IGRvIG5vdCBuZWVkCisJIyBrZXJuZWwgdmVyc2lvbiBpbmZvcm1h
dGlvbiwgc28gaXQgY2FuIGJlIHJlcGxhY2VkIHdpdGggYQorCSMgc3VpdGFibGUgdGFnLCBpbiB0
aGUgc3R5bGUgb2YgbGludXgtZ251LgorCWNhc2UgIiR7VU5BTUVfVkVSU0lPTn0iIGluCisJICAg
IERlYmlhbiopCisJCXJlbGVhc2U9Jy1nbnUnCisJCTs7CisJICAgICopCisJCXJlbGVhc2U9YGVj
aG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy1fXS4qL1wuLydgCisJCTs7CisJZXNhYwor
CSMgU2luY2UgQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVSQVRJTkdfU1lTVEVNOgor
CSMgY29udGFpbnMgcmVkdW5kYW50IGluZm9ybWF0aW9uLCB0aGUgc2hvcnRlciBmb3JtOgorCSMg
Q1BVX1RZUEUtTUFOVUZBQ1RVUkVSLU9QRVJBVElOR19TWVNURU0gaXMgdXNlZC4KKwllY2hvICIk
e21hY2hpbmV9LSR7b3N9JHtyZWxlYXNlfSIKKwlleGl0IDs7CisgICAgKjpPcGVuQlNEOio6KikK
KwlVTkFNRV9NQUNISU5FX0FSQ0g9YGFyY2ggfCBzZWQgJ3MvT3BlbkJTRC4vLydgCisJZWNobyAk
e1VOQU1FX01BQ0hJTkVfQVJDSH0tdW5rbm93bi1vcGVuYnNkJHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICAqOmVra29CU0Q6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3du
LWVra29ic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6U29saWRCU0Q6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXNvbGlkYnNkJHtVTkFNRV9SRUxFQVNFfQor
CWV4aXQgOzsKKyAgICBtYWNwcGM6TWlyQlNEOio6KikKKwllY2hvIHBvd2VycGMtdW5rbm93bi1t
aXJic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6TWlyQlNEOio6KikKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1taXJic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGFscGhhOk9TRjE6KjoqKQorCWNhc2UgJFVOQU1FX1JFTEVBU0UgaW4KKwkqNC4wKQor
CQlVTkFNRV9SRUxFQVNFPWAvdXNyL3NiaW4vc2l6ZXIgLXYgfCBhd2sgJ3twcmludCAkM30nYAor
CQk7OworCSo1LiopCisJCVVOQU1FX1JFTEVBU0U9YC91c3Ivc2Jpbi9zaXplciAtdiB8IGF3ayAn
e3ByaW50ICQ0fSdgCisJCTs7CisJZXNhYworCSMgQWNjb3JkaW5nIHRvIENvbXBhcSwgL3Vzci9z
YmluL3BzcmluZm8gaGFzIGJlZW4gYXZhaWxhYmxlIG9uCisJIyBPU0YvMSBhbmQgVHJ1NjQgc3lz
dGVtcyBwcm9kdWNlZCBzaW5jZSAxOTk1LiAgSSBob3BlIHRoYXQKKwkjIGNvdmVycyBtb3N0IHN5
c3RlbXMgcnVubmluZyB0b2RheS4gIFRoaXMgY29kZSBwaXBlcyB0aGUgQ1BVCisJIyB0eXBlcyB0
aHJvdWdoIGhlYWQgLW4gMSwgc28gd2Ugb25seSBkZXRlY3QgdGhlIHR5cGUgb2YgQ1BVIDAuCisJ
QUxQSEFfQ1BVX1RZUEU9YC91c3Ivc2Jpbi9wc3JpbmZvIC12IHwgc2VkIC1uIC1lICdzL14gIFRo
ZSBhbHBoYSBcKC4qXCkgcHJvY2Vzc29yLiokL1wxL3AnIHwgaGVhZCAtbiAxYAorCWNhc2UgIiRB
TFBIQV9DUFVfVFlQRSIgaW4KKwkgICAgIkVWNCAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0i
YWxwaGEiIDs7CisJICAgICJFVjQuNSAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGEi
IDs7CisJICAgICJMQ0E0ICgyMTA2Ni8yMTA2OCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIg
OzsKKwkgICAgIkVWNSAoMjExNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjUiIDs7CisJ
ICAgICJFVjUuNiAoMjExNjRBKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY1NiIgOzsKKwkg
ICAgIkVWNS42ICgyMTE2NFBDKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhcGNhNTYiIDs7CisJ
ICAgICJFVjUuNyAoMjExNjRQQykiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYXBjYTU3IiA7Owor
CSAgICAiRVY2ICgyMTI2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NiIgOzsKKwkgICAg
IkVWNi43ICgyMTI2NEEpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY3IiA7OworCSAgICAi
RVY2LjhDQiAoMjEyNjRDKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OCIgOzsKKwkgICAg
IkVWNi44QUwgKDIxMjY0QikiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjgiIDs7CisJICAg
ICJFVjYuOENYICgyMTI2NEQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY4IiA7OworCSAg
ICAiRVY2LjlBICgyMTI2NC9FVjY5QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjkiIDs7
CisJICAgICJFVjcgKDIxMzY0KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY3IiA7OworCSAg
ICAiRVY3LjkgKDIxMzY0QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NzkiIDs7CisJZXNh
YworCSMgQSBQbi5uIHZlcnNpb24gaXMgYSBwYXRjaGVkIHZlcnNpb24uCisJIyBBIFZuLm4gdmVy
c2lvbiBpcyBhIHJlbGVhc2VkIHZlcnNpb24uCisJIyBBIFRuLm4gdmVyc2lvbiBpcyBhIHJlbGVh
c2VkIGZpZWxkIHRlc3QgdmVyc2lvbi4KKwkjIEEgWG4ubiB2ZXJzaW9uIGlzIGFuIHVucmVsZWFz
ZWQgZXhwZXJpbWVudGFsIGJhc2VsZXZlbC4KKwkjIDEuMiB1c2VzICIxLjIiIGZvciB1bmFtZSAt
ci4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tZGVjLW9zZmBlY2hvICR7VU5BTUVfUkVMRUFTRX0g
fCBzZWQgLWUgJ3MvXltQVlRYXS8vJyB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicg
J2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6J2AKKwkjIFJlc2V0IEVYSVQgdHJhcCBiZWZvcmUg
ZXhpdGluZyB0byBhdm9pZCBzcHVyaW91cyBub24temVybyBleGl0IGNvZGUuCisJZXhpdGNvZGU9
JD8KKwl0cmFwICcnIDAKKwlleGl0ICRleGl0Y29kZSA7OworICAgIEFscGhhXCAqOldpbmRvd3Nf
TlQqOiopCisJIyBIb3cgZG8gd2Uga25vdyBpdCdzIEludGVyaXggcmF0aGVyIHRoYW4gdGhlIGdl
bmVyaWMgUE9TSVggc3Vic3lzdGVtPworCSMgU2hvdWxkIHdlIGNoYW5nZSBVTkFNRV9NQUNISU5F
IGJhc2VkIG9uIHRoZSBvdXRwdXQgb2YgdW5hbWUgaW5zdGVhZAorCSMgb2YgdGhlIHNwZWNpZmlj
IEFscGhhIG1vZGVsPworCWVjaG8gYWxwaGEtcGMtaW50ZXJpeAorCWV4aXQgOzsKKyAgICAyMTA2
NDpXaW5kb3dzX05UOjUwOjMpCisJZWNobyBhbHBoYS1kZWMtd2lubnQzLjUKKwlleGl0IDs7Cisg
ICAgQW1pZ2EqOlVOSVhfU3lzdGVtX1Y6NC4wOiopCisJZWNobyBtNjhrLXVua25vd24tc3lzdjQK
KwlleGl0IDs7CisgICAgKjpbQWFdbWlnYVtPb11bU3NdOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1hbWlnYW9zCisJZXhpdCA7OworICAgICo6W01tXW9ycGhbT29dW1NzXToq
OiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbW9ycGhvcworCWV4aXQgOzsKKyAg
ICAqOk9TLzM5MDoqOiopCisJZWNobyBpMzcwLWlibS1vcGVuZWRpdGlvbgorCWV4aXQgOzsKKyAg
ICAqOnovVk06KjoqKQorCWVjaG8gczM5MC1pYm0tenZtb2UKKwlleGl0IDs7CisgICAgKjpPUzQw
MDoqOiopCisJZWNobyBwb3dlcnBjLWlibS1vczQwMAorCWV4aXQgOzsKKyAgICBhcm06UklTQyo6
MS5bMDEyXSo6Knxhcm06cmlzY2l4OjEuWzAxMl0qOiopCisJZWNobyBhcm0tYWNvcm4tcmlzY2l4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBhcm06cmlzY29zOio6Knxhcm06UklTQ09T
Oio6KikKKwllY2hvIGFybS11bmtub3duLXJpc2NvcworCWV4aXQgOzsKKyAgICBTUjI/MDE6SEkt
VVgvTVBQOio6KiB8IFNSODAwMDpISS1VWC9NUFA6KjoqKQorCWVjaG8gaHBwYTEuMS1oaXRhY2hp
LWhpdXhtcHAKKwlleGl0IDs7CisgICAgUHlyYW1pZCo6T1N4KjoqOiogfCBNSVMqOk9TeCo6Kjoq
IHwgTUlTKjpTTVBfREMtT1N4KjoqOiopCisJIyBha2VlQHdwZGlzMDMud3BhZmIuYWYubWlsIChF
YXJsZSBGLiBBa2UpIGNvbnRyaWJ1dGVkIE1JUyBhbmQgTklMRS4KKwlpZiB0ZXN0ICJgKC9iaW4v
dW5pdmVyc2UpIDI+L2Rldi9udWxsYCIgPSBhdHQgOyB0aGVuCisJCWVjaG8gcHlyYW1pZC1weXJh
bWlkLXN5c3YzCisJZWxzZQorCQllY2hvIHB5cmFtaWQtcHlyYW1pZC1ic2QKKwlmaQorCWV4aXQg
OzsKKyAgICBOSUxFKjoqOio6ZGNvc3gpCisJZWNobyBweXJhbWlkLXB5cmFtaWQtc3ZyNAorCWV4
aXQgOzsKKyAgICBEUlM/NjAwMDp1bml4OjQuMDo2KikKKwllY2hvIHNwYXJjLWljbC1ueDYKKwll
eGl0IDs7CisgICAgRFJTPzYwMDA6VU5JWF9TVjo0LjIqOjcqIHwgRFJTPzYwMDA6aXNpczo0LjIq
OjcqKQorCWNhc2UgYC91c3IvYmluL3VuYW1lIC1wYCBpbgorCSAgICBzcGFyYykgZWNobyBzcGFy
Yy1pY2wtbng3OyBleGl0IDs7CisJZXNhYyA7OworICAgIHMzOTB4OlN1bk9TOio6KikKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0taWJtLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQg
LWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjRIOlN1bk9TOjUuKjoqKQorCWVjaG8g
c3BhcmMtaGFsLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSov
LydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjUuKjoqIHwgdGFkcG9sZSo6U3VuT1M6NS4q
OiopCisJZWNobyBzcGFyYy1zdW4tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgaTg2cGM6QXVyb3JhVVg6NS4qOiogfCBpODZ4
ZW46QXVyb3JhVVg6NS4qOiopCisJZWNobyBpMzg2LXBjLWF1cm9yYXV4JHtVTkFNRV9SRUxFQVNF
fQorCWV4aXQgOzsKKyAgICBpODZwYzpTdW5PUzo1Lio6KiB8IGk4NnhlbjpTdW5PUzo1Lio6KikK
KwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJU1VOX0FSQ0g9ImkzODYiCisJIyBJZiB0aGVyZSBp
cyBhIGNvbXBpbGVyLCBzZWUgaWYgaXQgaXMgY29uZmlndXJlZCBmb3IgNjQtYml0IG9iamVjdHMu
CisJIyBOb3RlIHRoYXQgdGhlIFN1biBjYyBkb2VzIG5vdCB0dXJuIF9fTFA2NF9fIGludG8gMSBs
aWtlIGdjYyBkb2VzLgorCSMgVGhpcyB0ZXN0IHdvcmtzIGZvciBib3RoIGNvbXBpbGVycy4KKwlp
ZiBbICIkQ0NfRk9SX0JVSUxEIiAhPSAnbm9fY29tcGlsZXJfZm91bmQnIF07IHRoZW4KKwkgICAg
aWYgKGVjaG8gJyNpZmRlZiBfX2FtZDY0JzsgZWNobyBJU182NEJJVF9BUkNIOyBlY2hvICcjZW5k
aWYnKSB8IFwKKwkJKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8IFwK
KwkJZ3JlcCBJU182NEJJVF9BUkNIID4vZGV2L251bGwKKwkgICAgdGhlbgorCQlTVU5fQVJDSD0i
eDg2XzY0IgorCSAgICBmaQorCWZpCisJZWNobyAke1NVTl9BUkNIfS1wYy1zb2xhcmlzMmBlY2hv
ICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsKKyAgICBzdW40
KjpTdW5PUzo2KjoqKQorCSMgQWNjb3JkaW5nIHRvIGNvbmZpZy5zdWIsIHRoaXMgaXMgdGhlIHBy
b3BlciB3YXkgdG8gY2Fub25pY2FsaXplCisJIyBTdW5PUzYuICBIYXJkIHRvIGd1ZXNzIGV4YWN0
bHkgd2hhdCBTdW5PUzYgd2lsbCBiZSBsaWtlLCBidXQKKwkjIGl0J3MgbGlrZWx5IHRvIGJlIG1v
cmUgbGlrZSBTb2xhcmlzIHRoYW4gU3VuT1M0LgorCWVjaG8gc3BhcmMtc3VuLXNvbGFyaXMzYGVj
aG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1
bjQqOlN1bk9TOio6KikKKwljYXNlICJgL3Vzci9iaW4vYXJjaCAta2AiIGluCisJICAgIFNlcmll
cyp8UzQqKQorCQlVTkFNRV9SRUxFQVNFPWB1bmFtZSAtdmAKKwkJOzsKKwllc2FjCisJIyBKYXBh
bmVzZSBMYW5ndWFnZSB2ZXJzaW9ucyBoYXZlIGEgdmVyc2lvbiBudW1iZXIgbGlrZSBgNC4xLjMt
SkwnLgorCWVjaG8gc3BhcmMtc3VuLXN1bm9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvLS9fLydgCisJZXhpdCA7OworICAgIHN1bjMqOlN1bk9TOio6KikKKwllY2hvIG02OGstc3Vu
LXN1bm9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBzdW4qOio6NC4yQlNEOiopCisJ
VU5BTUVfUkVMRUFTRT1gKHNlZCAxcSAvZXRjL21vdGQgfCBhd2sgJ3twcmludCBzdWJzdHIoJDUs
MSwzKX0nKSAyPi9kZXYvbnVsbGAKKwl0ZXN0ICJ4JHtVTkFNRV9SRUxFQVNFfSIgPSAieCIgJiYg
VU5BTUVfUkVMRUFTRT0zCisJY2FzZSAiYC9iaW4vYXJjaGAiIGluCisJICAgIHN1bjMpCisJCWVj
aG8gbTY4ay1zdW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJCTs7CisJICAgIHN1bjQpCisJCWVj
aG8gc3BhcmMtc3VuLXN1bm9zJHtVTkFNRV9SRUxFQVNFfQorCQk7OworCWVzYWMKKwlleGl0IDs7
CisgICAgYXVzaHA6U3VuT1M6KjoqKQorCWVjaG8gc3BhcmMtYXVzcGV4LXN1bm9zJHtVTkFNRV9S
RUxFQVNFfQorCWV4aXQgOzsKKyAgICAjIFRoZSBzaXR1YXRpb24gZm9yIE1pTlQgaXMgYSBsaXR0
bGUgY29uZnVzaW5nLiAgVGhlIG1hY2hpbmUgbmFtZQorICAgICMgY2FuIGJlIHZpcnR1YWxseSBl
dmVyeXRoaW5nIChldmVyeXRoaW5nIHdoaWNoIGlzIG5vdAorICAgICMgImF0YXJpc3QiIG9yICJh
dGFyaXN0ZSIgYXQgbGVhc3Qgc2hvdWxkIGhhdmUgYSBwcm9jZXNzb3IKKyAgICAjID4gbTY4MDAw
KS4gIFRoZSBzeXN0ZW0gbmFtZSByYW5nZXMgZnJvbSAiTWlOVCIgb3ZlciAiRnJlZU1pTlQiCisg
ICAgIyB0byB0aGUgbG93ZXJjYXNlIHZlcnNpb24gIm1pbnQiIChvciAiZnJlZW1pbnQiKS4gIEZp
bmFsbHkKKyAgICAjIHRoZSBzeXN0ZW0gbmFtZSAiVE9TIiBkZW5vdGVzIGEgc3lzdGVtIHdoaWNo
IGlzIGFjdHVhbGx5IG5vdAorICAgICMgTWlOVC4gIEJ1dCBNaU5UIGlzIGRvd253YXJkIGNvbXBh
dGlibGUgdG8gVE9TLCBzbyB0aGlzIHNob3VsZAorICAgICMgYmUgbm8gcHJvYmxlbS4KKyAgICBh
dGFyaXN0W2VdOipNaU5UOio6KiB8IGF0YXJpc3RbZV06Km1pbnQ6KjoqIHwgYXRhcmlzdFtlXToq
VE9TOio6KikKKwllY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgYXRhcmkqOipNaU5UOio6KiB8IGF0YXJpKjoqbWludDoqOiogfCBhdGFyaXN0W2VdOipU
T1M6KjoqKQorCWVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsK
KyAgICAqZmFsY29uKjoqTWlOVDoqOiogfCAqZmFsY29uKjoqbWludDoqOiogfCAqZmFsY29uKjoq
VE9TOio6KikKKwllY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgbWlsYW4qOipNaU5UOio6KiB8IG1pbGFuKjoqbWludDoqOiogfCAqbWlsYW4qOipUT1M6
KjoqKQorCWVjaG8gbTY4ay1taWxhbi1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAg
ICBoYWRlcyo6Kk1pTlQ6KjoqIHwgaGFkZXMqOiptaW50Oio6KiB8ICpoYWRlcyo6KlRPUzoqOiop
CisJZWNobyBtNjhrLWhhZGVzLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6
Kk1pTlQ6KjoqIHwgKjoqbWludDoqOiogfCAqOipUT1M6KjoqKQorCWVjaG8gbTY4ay11bmtub3du
LW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG02OGs6bWFjaHRlbjoqOiopCisJ
ZWNobyBtNjhrLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHBv
d2VycGM6bWFjaHRlbjoqOiopCisJZWNobyBwb3dlcnBjLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIFJJU0MqOk1hY2g6KjoqKQorCWVjaG8gbWlwcy1kZWMtbWFj
aF9ic2Q0LjMKKwlleGl0IDs7CisgICAgUklTQyo6VUxUUklYOio6KikKKwllY2hvIG1pcHMtZGVj
LXVsdHJpeCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgVkFYKjpVTFRSSVgqOio6KikK
KwllY2hvIHZheC1kZWMtdWx0cml4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAyMDIw
OkNMSVg6KjoqIHwgMjQzMDpDTElYOio6KikKKwllY2hvIGNsaXBwZXItaW50ZXJncmFwaC1jbGl4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBtaXBzOio6KjpVTUlQUyB8IG1pcHM6Kjoq
OlJJU0NvcykKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+
JGR1bW15LmMKKyNpZmRlZiBfX2NwbHVzcGx1cworI2luY2x1ZGUgPHN0ZGlvLmg+ICAvKiBmb3Ig
cHJpbnRmKCkgcHJvdG90eXBlICovCisJaW50IG1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10p
IHsKKyNlbHNlCisJaW50IG1haW4gKGFyZ2MsIGFyZ3YpIGludCBhcmdjOyBjaGFyICphcmd2W107
IHsKKyNlbmRpZgorCSNpZiBkZWZpbmVkIChob3N0X21pcHMpICYmIGRlZmluZWQgKE1JUFNFQikK
KwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9TWVNWKQorCSAgcHJpbnRmICgibWlwcy1taXBzLXJpc2Nv
cyVzc3lzdlxuIiwgYXJndlsxXSk7IGV4aXQgKDApOworCSNlbmRpZgorCSNpZiBkZWZpbmVkIChT
WVNUWVBFX1NWUjQpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzdnI0XG4iLCBhcmd2
WzFdKTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfQlNENDMpIHx8
IGRlZmluZWQoU1lTVFlQRV9CU0QpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNic2Rc
biIsIGFyZ3ZbMV0pOyBleGl0ICgwKTsKKwkjZW5kaWYKKwkjZW5kaWYKKwkgIGV4aXQgKC0xKTsK
Kwl9CitFT0YKKwkkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAmJgorCSAgZHVtbXlh
cmc9YGVjaG8gIiR7VU5BTUVfUkVMRUFTRX0iIHwgc2VkIC1uICdzL1woWzAtOV0qXCkuKi9cMS9w
J2AgJiYKKwkgIFNZU1RFTV9OQU1FPWAkZHVtbXkgJGR1bW15YXJnYCAmJgorCSAgICB7IGVjaG8g
IiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKwllY2hvIG1pcHMtbWlwcy1yaXNjb3Mke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIE1vdG9yb2xhOlBvd2VyTUFYX09TOio6KikKKwllY2hvIHBv
d2VycGMtbW90b3JvbGEtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTW90b3JvbGE6Kjo0LjM6UEw4
LSopCisJZWNobyBwb3dlcnBjLWhhcnJpcy1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBOaWdodF9I
YXdrOio6KjpQb3dlck1BWF9PUyB8IFN5bmVyZ3k6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93
ZXJwYy1oYXJyaXMtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTmlnaHRfSGF3azpQb3dlcl9VTklY
Oio6KikKKwllY2hvIHBvd2VycGMtaGFycmlzLXBvd2VydW5peAorCWV4aXQgOzsKKyAgICBtODhr
OkNYL1VYOjcqOiopCisJZWNobyBtODhrLWhhcnJpcy1jeHV4NworCWV4aXQgOzsKKyAgICBtODhr
Oio6NCo6UjQqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2NAorCWV4aXQgOzsKKyAgICBtODhr
Oio6Myo6UjMqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2MworCWV4aXQgOzsKKyAgICBBVmlp
T046ZGd1eDoqOiopCisJIyBERy9VWCByZXR1cm5zIEFWaWlPTiBmb3IgYWxsIGFyY2hpdGVjdHVy
ZXMKKwlVTkFNRV9QUk9DRVNTT1I9YC91c3IvYmluL3VuYW1lIC1wYAorCWlmIFsgJFVOQU1FX1BS
T0NFU1NPUiA9IG1jODgxMDAgXSB8fCBbICRVTkFNRV9QUk9DRVNTT1IgPSBtYzg4MTEwIF0KKwl0
aGVuCisJICAgIGlmIFsgJHtUQVJHRVRfQklOQVJZX0lOVEVSRkFDRX14ID0gbTg4a2RndXhlbGZ4
IF0gfHwgXAorCSAgICAgICBbICR7VEFSR0VUX0JJTkFSWV9JTlRFUkZBQ0V9eCA9IHggXQorCSAg
ICB0aGVuCisJCWVjaG8gbTg4ay1kZy1kZ3V4JHtVTkFNRV9SRUxFQVNFfQorCSAgICBlbHNlCisJ
CWVjaG8gbTg4ay1kZy1kZ3V4YmNzJHtVTkFNRV9SRUxFQVNFfQorCSAgICBmaQorCWVsc2UKKwkg
ICAgZWNobyBpNTg2LWRnLWRndXgke1VOQU1FX1JFTEVBU0V9CisJZmkKKwlleGl0IDs7CisgICAg
TTg4KjpEb2xwaGluT1M6KjoqKQkjIERvbHBoaW5PUyAoU1ZSMykKKwllY2hvIG04OGstZG9scGhp
bi1zeXN2MworCWV4aXQgOzsKKyAgICBNODgqOio6UjMqOiopCisJIyBEZWx0YSA4OGsgc3lzdGVt
IHJ1bm5pbmcgU1ZSMworCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2MworCWV4aXQgOzsKKyAgICBY
RDg4KjoqOio6KikgIyBUZWt0cm9uaXggWEQ4OCBzeXN0ZW0gcnVubmluZyBVVGVrViAoU1ZSMykK
KwllY2hvIG04OGstdGVrdHJvbml4LXN5c3YzCisJZXhpdCA7OworICAgIFRlazQzWzAtOV1bMC05
XTpVVGVrOio6KikgIyBUZWt0cm9uaXggNDMwMCBzeXN0ZW0gcnVubmluZyBVVGVrIChCU0QpCisJ
ZWNobyBtNjhrLXRla3Ryb25peC1ic2QKKwlleGl0IDs7CisgICAgKjpJUklYKjoqOiopCisJZWNo
byBtaXBzLXNnaS1pcml4YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvLS9fL2cnYAor
CWV4aXQgOzsKKyAgICA/Pz8/Pz8/PzpBSVg/OlsxMl0uMToyKSAgICMgQUlYIDIuMi4xIG9yIEFJ
WCAyLjEuMSBpcyBSVC9QQyBBSVguCisJZWNobyByb21wLWlibS1haXggICAgICMgdW5hbWUgLW0g
Z2l2ZXMgYW4gOCBoZXgtY29kZSBDUFUgaWQKKwlleGl0IDs7ICAgICAgICAgICAgICAgIyBOb3Rl
IHRoYXQ6IGVjaG8gIidgdW5hbWUgLXNgJyIgZ2l2ZXMgJ0FJWCAnCisgICAgaSo4NjpBSVg6Kjoq
KQorCWVjaG8gaTM4Ni1pYm0tYWl4CisJZXhpdCA7OworICAgIGlhNjQ6QUlYOio6KikKKwlpZiBb
IC14IC91c3IvYmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1gL3Vzci9iaW4vb3NsZXZl
bGAKKwllbHNlCisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VOQU1FX1JFTEVBU0V9CisJ
ZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0taWJtLWFpeCR7SUJNX1JFVn0KKwlleGl0IDs7Cisg
ICAgKjpBSVg6MjozKQorCWlmIGdyZXAgYm9zMzI1IC91c3IvaW5jbHVkZS9zdGRpby5oID4vZGV2
L251bGwgMj4mMTsgdGhlbgorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCXNlZCAncy9eCQkv
LycgPDwgRU9GID4kZHVtbXkuYworCQkjaW5jbHVkZSA8c3lzL3N5c3RlbWNmZy5oPgorCisJCW1h
aW4oKQorCQkJeworCQkJaWYgKCFfX3Bvd2VyX3BjKCkpCisJCQkJZXhpdCgxKTsKKwkJCXB1dHMo
InBvd2VycGMtaWJtLWFpeDMuMi41Iik7CisJCQlleGl0KDApOworCQkJfQorRU9GCisJCWlmICRD
Q19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmIFNZU1RFTV9OQU1FPWAkZHVtbXlgCisJ
CXRoZW4KKwkJCWVjaG8gIiRTWVNURU1fTkFNRSIKKwkJZWxzZQorCQkJZWNobyByczYwMDAtaWJt
LWFpeDMuMi41CisJCWZpCisJZWxpZiBncmVwIGJvczMyNCAvdXNyL2luY2x1ZGUvc3RkaW8uaCA+
L2Rldi9udWxsIDI+JjE7IHRoZW4KKwkJZWNobyByczYwMDAtaWJtLWFpeDMuMi40CisJZWxzZQor
CQllY2hvIHJzNjAwMC1pYm0tYWl4My4yCisJZmkKKwlleGl0IDs7CisgICAgKjpBSVg6KjpbNDU2
N10pCisJSUJNX0NQVV9JRD1gL3Vzci9zYmluL2xzZGV2IC1DIC1jIHByb2Nlc3NvciAtUyBhdmFp
bGFibGUgfCBzZWQgMXEgfCBhd2sgJ3sgcHJpbnQgJDEgfSdgCisJaWYgL3Vzci9zYmluL2xzYXR0
ciAtRWwgJHtJQk1fQ1BVX0lEfSB8IGdyZXAgJyBQT1dFUicgPi9kZXYvbnVsbCAyPiYxOyB0aGVu
CisJCUlCTV9BUkNIPXJzNjAwMAorCWVsc2UKKwkJSUJNX0FSQ0g9cG93ZXJwYworCWZpCisJaWYg
WyAteCAvdXNyL2Jpbi9vc2xldmVsIF0gOyB0aGVuCisJCUlCTV9SRVY9YC91c3IvYmluL29zbGV2
ZWxgCisJZWxzZQorCQlJQk1fUkVWPSR7VU5BTUVfVkVSU0lPTn0uJHtVTkFNRV9SRUxFQVNFfQor
CWZpCisJZWNobyAke0lCTV9BUkNIfS1pYm0tYWl4JHtJQk1fUkVWfQorCWV4aXQgOzsKKyAgICAq
OkFJWDoqOiopCisJZWNobyByczYwMDAtaWJtLWFpeAorCWV4aXQgOzsKKyAgICBpYm1ydDo0LjRC
U0Q6Knxyb21wLWlibTpCU0Q6KikKKwllY2hvIHJvbXAtaWJtLWJzZDQuNAorCWV4aXQgOzsKKyAg
ICBpYm1ydDoqQlNEOip8cm9tcC1pYm06QlNEOiopICAgICAgICAgICAgIyBjb3ZlcnMgUlQvUEMg
QlNEIGFuZAorCWVjaG8gcm9tcC1pYm0tYnNkJHtVTkFNRV9SRUxFQVNFfSAgICMgNC4zIHdpdGgg
dW5hbWUgYWRkZWQgdG8KKwlleGl0IDs7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHJl
cG9ydDogcm9tcC1pYm0gQlNEIDQuMworICAgICo6Qk9TWDoqOiopCisJZWNobyByczYwMDAtYnVs
bC1ib3N4CisJZXhpdCA7OworICAgIERQWC8yPzAwOkIuTy5TLjoqOiopCisJZWNobyBtNjhrLWJ1
bGwtc3lzdjMKKwlleGl0IDs7CisgICAgOTAwMC9bMzRdPz86NC4zYnNkOjEuKjoqKQorCWVjaG8g
bTY4ay1ocC1ic2QKKwlleGl0IDs7CisgICAgaHAzMDA6NC40QlNEOio6KiB8IDkwMDAvWzM0XT8/
OjQuM2JzZDoyLio6KikKKwllY2hvIG02OGstaHAtYnNkNC40CisJZXhpdCA7OworICAgIDkwMDAv
WzM0Njc4XT8/OkhQLVVYOio6KikKKwlIUFVYX1JFVj1gZWNobyAke1VOQU1FX1JFTEVBU0V9fHNl
ZCAtZSAncy9bXi5dKi5bMEJdKi8vJ2AKKwljYXNlICIke1VOQU1FX01BQ0hJTkV9IiBpbgorCSAg
ICA5MDAwLzMxPyApICAgICAgICAgICAgSFBfQVJDSD1tNjgwMDAgOzsKKwkgICAgOTAwMC9bMzRd
Pz8gKSAgICAgICAgIEhQX0FSQ0g9bTY4ayA7OworCSAgICA5MDAwL1s2NzhdWzAtOV1bMC05XSkK
KwkJaWYgWyAteCAvdXNyL2Jpbi9nZXRjb25mIF07IHRoZW4KKwkJICAgIHNjX2NwdV92ZXJzaW9u
PWAvdXNyL2Jpbi9nZXRjb25mIFNDX0NQVV9WRVJTSU9OIDI+L2Rldi9udWxsYAorCQkgICAgc2Nf
a2VybmVsX2JpdHM9YC91c3IvYmluL2dldGNvbmYgU0NfS0VSTkVMX0JJVFMgMj4vZGV2L251bGxg
CisJCSAgICBjYXNlICIke3NjX2NwdV92ZXJzaW9ufSIgaW4KKwkJICAgICAgNTIzKSBIUF9BUkNI
PSJocHBhMS4wIiA7OyAjIENQVV9QQV9SSVNDMV8wCisJCSAgICAgIDUyOCkgSFBfQVJDSD0iaHBw
YTEuMSIgOzsgIyBDUFVfUEFfUklTQzFfMQorCQkgICAgICA1MzIpICAgICAgICAgICAgICAgICAg
ICAgICMgQ1BVX1BBX1JJU0MyXzAKKwkJCWNhc2UgIiR7c2Nfa2VybmVsX2JpdHN9IiBpbgorCQkJ
ICAzMikgSFBfQVJDSD0iaHBwYTIuMG4iIDs7CisJCQkgIDY0KSBIUF9BUkNIPSJocHBhMi4wdyIg
OzsKKwkJCSAgJycpIEhQX0FSQ0g9ImhwcGEyLjAiIDs7ICAgIyBIUC1VWCAxMC4yMAorCQkJZXNh
YyA7OworCQkgICAgZXNhYworCQlmaQorCQlpZiBbICIke0hQX0FSQ0h9IiA9ICIiIF07IHRoZW4K
KwkJICAgIGV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJICAgIHNlZCAncy9eCQkvLycgPDwgRU9G
ID4kZHVtbXkuYworCisJCSNkZWZpbmUgX0hQVVhfU09VUkNFCisJCSNpbmNsdWRlIDxzdGRsaWIu
aD4KKwkJI2luY2x1ZGUgPHVuaXN0ZC5oPgorCisJCWludCBtYWluICgpCisJCXsKKwkJI2lmIGRl
ZmluZWQoX1NDX0tFUk5FTF9CSVRTKQorCQkgICAgbG9uZyBiaXRzID0gc3lzY29uZihfU0NfS0VS
TkVMX0JJVFMpOworCQkjZW5kaWYKKwkJICAgIGxvbmcgY3B1ICA9IHN5c2NvbmYgKF9TQ19DUFVf
VkVSU0lPTik7CisKKwkJICAgIHN3aXRjaCAoY3B1KQorCQkJeworCQkJY2FzZSBDUFVfUEFfUklT
QzFfMDogcHV0cyAoImhwcGExLjAiKTsgYnJlYWs7CisJCQljYXNlIENQVV9QQV9SSVNDMV8xOiBw
dXRzICgiaHBwYTEuMSIpOyBicmVhazsKKwkJCWNhc2UgQ1BVX1BBX1JJU0MyXzA6CisJCSNpZiBk
ZWZpbmVkKF9TQ19LRVJORUxfQklUUykKKwkJCSAgICBzd2l0Y2ggKGJpdHMpCisJCQkJeworCQkJ
CWNhc2UgNjQ6IHB1dHMgKCJocHBhMi4wdyIpOyBicmVhazsKKwkJCQljYXNlIDMyOiBwdXRzICgi
aHBwYTIuMG4iKTsgYnJlYWs7CisJCQkJZGVmYXVsdDogcHV0cyAoImhwcGEyLjAiKTsgYnJlYWs7
CisJCQkJfSBicmVhazsKKwkJI2Vsc2UgIC8qICFkZWZpbmVkKF9TQ19LRVJORUxfQklUUykgKi8K
KwkJCSAgICBwdXRzICgiaHBwYTIuMCIpOyBicmVhazsKKwkJI2VuZGlmCisJCQlkZWZhdWx0OiBw
dXRzICgiaHBwYTEuMCIpOyBicmVhazsKKwkJCX0KKwkJICAgIGV4aXQgKDApOworCQl9CitFT0YK
KwkJICAgIChDQ09QVFM9ICRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jIDI+L2Rldi9u
dWxsKSAmJiBIUF9BUkNIPWAkZHVtbXlgCisJCSAgICB0ZXN0IC16ICIkSFBfQVJDSCIgJiYgSFBf
QVJDSD1ocHBhCisJCWZpIDs7CisJZXNhYworCWlmIFsgJHtIUF9BUkNIfSA9ICJocHBhMi4wdyIg
XQorCXRoZW4KKwkgICAgZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorCisJICAgICMgaHBwYTIuMHct
aHAtaHB1eCogaGFzIGEgNjQtYml0IGtlcm5lbCBhbmQgYSBjb21waWxlciBnZW5lcmF0aW5nCisJ
ICAgICMgMzItYml0IGNvZGUuICBocHBhNjQtaHAtaHB1eCogaGFzIHRoZSBzYW1lIGtlcm5lbCBh
bmQgYSBjb21waWxlcgorCSAgICAjIGdlbmVyYXRpbmcgNjQtYml0IGNvZGUuICBHTlUgYW5kIEhQ
IHVzZSBkaWZmZXJlbnQgbm9tZW5jbGF0dXJlOgorCSAgICAjCisJICAgICMgJCBDQ19GT1JfQlVJ
TEQ9Y2MgLi9jb25maWcuZ3Vlc3MKKwkgICAgIyA9PiBocHBhMi4wdy1ocC1ocHV4MTEuMjMKKwkg
ICAgIyAkIENDX0ZPUl9CVUlMRD0iY2MgK0RBMi4wdyIgLi9jb25maWcuZ3Vlc3MKKwkgICAgIyA9
PiBocHBhNjQtaHAtaHB1eDExLjIzCisKKwkgICAgaWYgZWNobyBfX0xQNjRfXyB8IChDQ09QVFM9
ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCkgfAorCQlncmVwIC1xIF9fTFA2NF9fCisJ
ICAgIHRoZW4KKwkJSFBfQVJDSD0iaHBwYTIuMHciCisJICAgIGVsc2UKKwkJSFBfQVJDSD0iaHBw
YTY0IgorCSAgICBmaQorCWZpCisJZWNobyAke0hQX0FSQ0h9LWhwLWhwdXgke0hQVVhfUkVWfQor
CWV4aXQgOzsKKyAgICBpYTY0OkhQLVVYOio6KikKKwlIUFVYX1JFVj1gZWNobyAke1VOQU1FX1JF
TEVBU0V9fHNlZCAtZSAncy9bXi5dKi5bMEJdKi8vJ2AKKwllY2hvIGlhNjQtaHAtaHB1eCR7SFBV
WF9SRVZ9CisJZXhpdCA7OworICAgIDMwNTAqOkhJLVVYOio6KikKKwlldmFsICRzZXRfY2NfZm9y
X2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+JGR1bW15LmMKKwkjaW5jbHVkZSA8dW5pc3Rk
Lmg+CisJaW50CisJbWFpbiAoKQorCXsKKwkgIGxvbmcgY3B1ID0gc3lzY29uZiAoX1NDX0NQVV9W
RVJTSU9OKTsKKwkgIC8qIFRoZSBvcmRlciBtYXR0ZXJzLCBiZWNhdXNlIENQVV9JU19IUF9NQzY4
SyBlcnJvbmVvdXNseSByZXR1cm5zCisJICAgICB0cnVlIGZvciBDUFVfUEFfUklTQzFfMC4gIENQ
VV9JU19QQV9SSVNDIHJldHVybnMgY29ycmVjdAorCSAgICAgcmVzdWx0cywgaG93ZXZlci4gICov
CisJICBpZiAoQ1BVX0lTX1BBX1JJU0MgKGNwdSkpCisJICAgIHsKKwkgICAgICBzd2l0Y2ggKGNw
dSkKKwkJeworCQkgIGNhc2UgQ1BVX1BBX1JJU0MxXzA6IHB1dHMgKCJocHBhMS4wLWhpdGFjaGkt
aGl1eHdlMiIpOyBicmVhazsKKwkJICBjYXNlIENQVV9QQV9SSVNDMV8xOiBwdXRzICgiaHBwYTEu
MS1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJCSAgY2FzZSBDUFVfUEFfUklTQzJfMDogcHV0
cyAoImhwcGEyLjAtaGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQkgIGRlZmF1bHQ6IHB1dHMg
KCJocHBhLWhpdGFjaGktaGl1eHdlMiIpOyBicmVhazsKKwkJfQorCSAgICB9CisJICBlbHNlIGlm
IChDUFVfSVNfSFBfTUM2OEsgKGNwdSkpCisJICAgIHB1dHMgKCJtNjhrLWhpdGFjaGktaGl1eHdl
MiIpOworCSAgZWxzZSBwdXRzICgidW5rbm93bi1oaXRhY2hpLWhpdXh3ZTIiKTsKKwkgIGV4aXQg
KDApOworCX0KK0VPRgorCSRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmIFNZU1RF
TV9OQU1FPWAkZHVtbXlgICYmCisJCXsgZWNobyAiJFNZU1RFTV9OQU1FIjsgZXhpdDsgfQorCWVj
aG8gdW5rbm93bi1oaXRhY2hpLWhpdXh3ZTIKKwlleGl0IDs7CisgICAgOTAwMC83Pz86NC4zYnNk
Oio6KiB8IDkwMDAvOD9bNzldOjQuM2JzZDoqOiogKQorCWVjaG8gaHBwYTEuMS1ocC1ic2QKKwll
eGl0IDs7CisgICAgOTAwMC84Pz86NC4zYnNkOio6KikKKwllY2hvIGhwcGExLjAtaHAtYnNkCisJ
ZXhpdCA7OworICAgICo5Pz8qOk1QRS9pWDoqOiogfCAqMzAwMCo6TVBFL2lYOio6KikKKwllY2hv
IGhwcGExLjAtaHAtbXBlaXgKKwlleGl0IDs7CisgICAgaHA3Pz86T1NGMToqOiogfCBocDg/Wzc5
XTpPU0YxOio6KiApCisJZWNobyBocHBhMS4xLWhwLW9zZgorCWV4aXQgOzsKKyAgICBocDg/PzpP
U0YxOio6KikKKwllY2hvIGhwcGExLjAtaHAtb3NmCisJZXhpdCA7OworICAgIGkqODY6T1NGMToq
OiopCisJaWYgWyAteCAvdXNyL3NiaW4vc3lzdmVyc2lvbiBdIDsgdGhlbgorCSAgICBlY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1vc2YxbWsKKwllbHNlCisJICAgIGVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLW9zZjEKKwlmaQorCWV4aXQgOzsKKyAgICBwYXJpc2MqOkxpdGVzKjoq
OiopCisJZWNobyBocHBhMS4xLWhwLWxpdGVzCisJZXhpdCA7OworICAgIEMxKjpDb252ZXhPUzoq
OiogfCBjb252ZXg6Q29udmV4T1M6QzEqOiopCisJZWNobyBjMS1jb252ZXgtYnNkCisJZXhpdCA7
OworICAgIEMyKjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzIqOiopCisJaWYgZ2V0
c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhlbiBlY2hvIGMzMi1jb252ZXgtYnNkCisJZWxzZSBl
Y2hvIGMyLWNvbnZleC1ic2QKKwlmaQorCWV4aXQgOzsKKyAgICBDMzQqOkNvbnZleE9TOio6KiB8
IGNvbnZleDpDb252ZXhPUzpDMzQqOiopCisJZWNobyBjMzQtY29udmV4LWJzZAorCWV4aXQgOzsK
KyAgICBDMzgqOkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMzgqOiopCisJZWNobyBj
MzgtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBDNCo6Q29udmV4T1M6KjoqIHwgY29udmV4OkNv
bnZleE9TOkM0KjoqKQorCWVjaG8gYzQtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBDUkFZKlkt
TVA6KjoqOiopCisJZWNobyB5bXAtY3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1l
ICdzL1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpbQS1aXTkwOio6KjoqKQorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS1jcmF5LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gXAorCXwgc2Vk
IC1lICdzL0NSQVkuKlwoW0EtWl05MFwpL1wxLycgXAorCSAgICAgIC1lIHkvQUJDREVGR0hJSktM
TU5PUFFSU1RVVldYWVovYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXovIFwKKwkgICAgICAtZSAn
cy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIENSQVkqVFM6KjoqOiopCisJZWNobyB0OTAt
Y3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwll
eGl0IDs7CisgICAgQ1JBWSpUM0U6KjoqOiopCisJZWNobyBhbHBoYWV2NS1jcmF5LXVuaWNvc21r
JHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAg
IENSQVkqU1YxOio6KjoqKQorCWVjaG8gc3YxLWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8
IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgICo6VU5JQ09TL21wOio6KikK
KwllY2hvIGNyYXludi1jcmF5LXVuaWNvc21wJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9c
LlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIEYzMFswMV06VU5JWF9TeXN0ZW1fVjoqOiogfCBG
NzAwOlVOSVhfU3lzdGVtX1Y6KjoqKQorCUZVSklUU1VfUFJPQz1gdW5hbWUgLW0gfCB0ciAnQUJD
REVGR0hJSktMTU5PUFFSU1RVVldYWVonICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eidgCisJ
RlVKSVRTVV9TWVM9YHVuYW1lIC1wIHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAn
YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHwgc2VkIC1lICdzL1wvLy8nYAorCUZVSklUU1Vf
UkVMPWBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvIC9fLydgCisJZWNobyAiJHtG
VUpJVFNVX1BST0N9LWZ1aml0c3UtJHtGVUpJVFNVX1NZU30ke0ZVSklUU1VfUkVMfSIKKwlleGl0
IDs7CisgICAgNTAwMDpVTklYX1N5c3RlbV9WOjQuKjoqKQorCUZVSklUU1VfU1lTPWB1bmFtZSAt
cCB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0
dXZ3eHl6JyB8IHNlZCAtZSAncy9cLy8vJ2AKKwlGVUpJVFNVX1JFTD1gZWNobyAke1VOQU1FX1JF
TEVBU0V9IHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5v
cHFyc3R1dnd4eXonIHwgc2VkIC1lICdzLyAvXy8nYAorCWVjaG8gInNwYXJjLWZ1aml0c3UtJHtG
VUpJVFNVX1NZU30ke0ZVSklUU1VfUkVMfSIKKwlleGl0IDs7CisgICAgaSo4NjpCU0QvMzg2Oio6
KiB8IGkqODY6QlNEL09TOio6KiB8ICo6QXNjZW5kXCBFbWJlZGRlZC9PUzoqOiopCisJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXBjLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHNw
YXJjKjpCU0QvT1M6KjoqKQorCWVjaG8gc3BhcmMtdW5rbm93bi1ic2RpJHtVTkFNRV9SRUxFQVNF
fQorCWV4aXQgOzsKKyAgICAqOkJTRC9PUzoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpGcmVlQlNEOio6KikK
KwlVTkFNRV9QUk9DRVNTT1I9YC91c3IvYmluL3VuYW1lIC1wYAorCWNhc2UgJHtVTkFNRV9QUk9D
RVNTT1J9IGluCisJICAgIGFtZDY0KQorCQllY2hvIHg4Nl82NC11bmtub3duLWZyZWVic2RgZWNo
byAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgIDs7CisJICAgICopCisJCWVj
aG8gJHtVTkFNRV9QUk9DRVNTT1J9LXVua25vd24tZnJlZWJzZGBlY2hvICR7VU5BTUVfUkVMRUFT
RX18c2VkIC1lICdzL1stKF0uKi8vJ2AgOzsKKwllc2FjCisJZXhpdCA7OworICAgIGkqOkNZR1dJ
Tio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtY3lnd2luCisJZXhpdCA7OworICAgICo6
TUlOR1cqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW1pbmd3MzIKKwlleGl0IDs7Cisg
ICAgaSo6TVNZUyo6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbXN5cworCWV4aXQgOzsK
KyAgICBpKjp3aW5kb3dzMzIqOiopCisJIyB1bmFtZSAtbSBpbmNsdWRlcyAiLXBjIiBvbiB0aGlz
IHN5c3RlbS4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tbWluZ3czMgorCWV4aXQgOzsKKyAgICBp
KjpQVyo6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtcHczMgorCWV4aXQgOzsKKyAgICAq
OkludGVyaXgqOiopCisJY2FzZSAke1VOQU1FX01BQ0hJTkV9IGluCisJICAgIHg4NikKKwkJZWNo
byBpNTg2LXBjLWludGVyaXgke1VOQU1FX1JFTEVBU0V9CisJCWV4aXQgOzsKKwkgICAgYXV0aGVu
dGljYW1kIHwgZ2VudWluZWludGVsIHwgRU02NFQpCisJCWVjaG8geDg2XzY0LXVua25vd24taW50
ZXJpeCR7VU5BTUVfUkVMRUFTRX0KKwkJZXhpdCA7OworCSAgICBJQTY0KQorCQllY2hvIGlhNjQt
dW5rbm93bi1pbnRlcml4JHtVTkFNRV9SRUxFQVNFfQorCQlleGl0IDs7CisJZXNhYyA7OworICAg
IFszNDVdODY6V2luZG93c185NToqIHwgWzM0NV04NjpXaW5kb3dzXzk4OiogfCBbMzQ1XTg2Oldp
bmRvd3NfTlQ6KikKKwllY2hvIGkke1VOQU1FX01BQ0hJTkV9LXBjLW1rcworCWV4aXQgOzsKKyAg
ICA4NjY0OldpbmRvd3NfTlQ6KikKKwllY2hvIHg4Nl82NC1wYy1ta3MKKwlleGl0IDs7CisgICAg
aSo6V2luZG93c19OVCo6KiB8IFBlbnRpdW0qOldpbmRvd3NfTlQqOiopCisJIyBIb3cgZG8gd2Ug
a25vdyBpdCdzIEludGVyaXggcmF0aGVyIHRoYW4gdGhlIGdlbmVyaWMgUE9TSVggc3Vic3lzdGVt
PworCSMgSXQgYWxzbyBjb25mbGljdHMgd2l0aCBwcmUtMi4wIHZlcnNpb25zIG9mIEFUJlQgVVdJ
Ti4gU2hvdWxkIHdlCisJIyBVTkFNRV9NQUNISU5FIGJhc2VkIG9uIHRoZSBvdXRwdXQgb2YgdW5h
bWUgaW5zdGVhZCBvZiBpMzg2PworCWVjaG8gaTU4Ni1wYy1pbnRlcml4CisJZXhpdCA7OworICAg
IGkqOlVXSU4qOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXV3aW4KKwlleGl0IDs7Cisg
ICAgYW1kNjQ6Q1lHV0lOKjoqOiogfCB4ODZfNjQ6Q1lHV0lOKjoqOiopCisJZWNobyB4ODZfNjQt
dW5rbm93bi1jeWd3aW4KKwlleGl0IDs7CisgICAgcCo6Q1lHV0lOKjoqKQorCWVjaG8gcG93ZXJw
Y2xlLXVua25vd24tY3lnd2luCisJZXhpdCA7OworICAgIHByZXAqOlN1bk9TOjUuKjoqKQorCWVj
aG8gcG93ZXJwY2xlLXVua25vd24tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgKjpHTlU6KjoqKQorCSMgdGhlIEdOVSBzeXN0
ZW0KKwllY2hvIGBlY2hvICR7VU5BTUVfTUFDSElORX18c2VkIC1lICdzLFstL10uKiQsLCdgLXVu
a25vd24tZ251YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MsLy4qJCwsJ2AKKwlleGl0
IDs7CisgICAgKjpHTlUvKjoqOiopCisJIyBvdGhlciBzeXN0ZW1zIHdpdGggR05VIGxpYmMgYW5k
IHVzZXJsYW5kCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tYGVjaG8gJHtVTkFNRV9T
WVNURU19IHwgc2VkICdzLF5bXi9dKi8sLCcgfCB0ciAnW0EtWl0nICdbYS16XSdgYGVjaG8gJHtV
TkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy0oXS4qLy8nYC1nbnUKKwlleGl0IDs7CisgICAgaSo4
NjpNaW5peDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW1pbml4CisJZXhpdCA7Owor
ICAgIGFscGhhOkxpbnV4Oio6KikKKwljYXNlIGBzZWQgLW4gJy9eY3B1IG1vZGVsL3MvXi4qOiBc
KC4qXCkvXDEvcCcgPCAvcHJvYy9jcHVpbmZvYCBpbgorCSAgRVY1KSAgIFVOQU1FX01BQ0hJTkU9
YWxwaGFldjUgOzsKKwkgIEVWNTYpICBVTkFNRV9NQUNISU5FPWFscGhhZXY1NiA7OworCSAgUENB
NTYpIFVOQU1FX01BQ0hJTkU9YWxwaGFwY2E1NiA7OworCSAgUENBNTcpIFVOQU1FX01BQ0hJTkU9
YWxwaGFwY2E1NiA7OworCSAgRVY2KSAgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjYgOzsKKwkgIEVW
NjcpICBVTkFNRV9NQUNISU5FPWFscGhhZXY2NyA7OworCSAgRVY2OCopIFVOQU1FX01BQ0hJTkU9
YWxwaGFldjY4IDs7CisJZXNhYworCW9iamR1bXAgLS1wcml2YXRlLWhlYWRlcnMgL2Jpbi9zaCB8
IGdyZXAgLXEgbGQuc28uMQorCWlmIHRlc3QgIiQ/IiA9IDAgOyB0aGVuIExJQkM9ImxpYmMxIiA7
IGVsc2UgTElCQz0iIiA7IGZpCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgt
Z251JHtMSUJDfQorCWV4aXQgOzsKKyAgICBhcm0qOkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2Nf
Zm9yX2J1aWxkCisJaWYgZWNobyBfX0FSTV9FQUJJX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4v
ZGV2L251bGwgXAorCSAgICB8IGdyZXAgLXEgX19BUk1fRUFCSV9fCisJdGhlbgorCSAgICBlY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwllbHNlCisJICAgIGlmIGVjaG8g
X19BUk1fUENTX1ZGUCB8ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCBcCisJCXwgZ3Jl
cCAtcSBfX0FSTV9QQ1NfVkZQCisJICAgIHRoZW4KKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tbGludXgtZ251ZWFiaQorCSAgICBlbHNlCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11
bmtub3duLWxpbnV4LWdudWVhYmloZgorCSAgICBmaQorCWZpCisJZXhpdCA7OworICAgIGF2cjMy
KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJ
ZXhpdCA7OworICAgIGNyaXM6TGludXg6KjoqKQorCWVjaG8gY3Jpcy1heGlzLWxpbnV4LWdudQor
CWV4aXQgOzsKKyAgICBjcmlzdjMyOkxpbnV4Oio6KikKKwllY2hvIGNyaXN2MzItYXhpcy1saW51
eC1nbnUKKwlleGl0IDs7CisgICAgZnJ2OkxpbnV4Oio6KikKKwllY2hvIGZydi11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBoZXhhZ29uOkxpbnV4Oio6KikKKwllY2hvIGhleGFnb24t
dW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgaSo4NjpMaW51eDoqOiopCisJTElCQz1n
bnUKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+JGR1bW15
LmMKKwkjaWZkZWYgX19kaWV0bGliY19fCisJTElCQz1kaWV0bGliYworCSNlbmRpZgorRU9GCisJ
ZXZhbCBgJENDX0ZPUl9CVUlMRCAtRSAkZHVtbXkuYyAyPi9kZXYvbnVsbCB8IGdyZXAgJ15MSUJD
J2AKKwllY2hvICIke1VOQU1FX01BQ0hJTkV9LXBjLWxpbnV4LSR7TElCQ30iCisJZXhpdCA7Owor
ICAgIGlhNjQ6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4
LWdudQorCWV4aXQgOzsKKyAgICBtMzJyKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJ
TkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIG02OCo6TGludXg6KjoqKQorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBtaXBz
OkxpbnV4Oio6KiB8IG1pcHM2NDpMaW51eDoqOiopCisJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAor
CXNlZCAncy9eCS8vJyA8PCBFT0YgPiRkdW1teS5jCisJI3VuZGVmIENQVQorCSN1bmRlZiAke1VO
QU1FX01BQ0hJTkV9CisJI3VuZGVmICR7VU5BTUVfTUFDSElORX1lbAorCSNpZiBkZWZpbmVkKF9f
TUlQU0VMX18pIHx8IGRlZmluZWQoX19NSVBTRUwpIHx8IGRlZmluZWQoX01JUFNFTCkgfHwgZGVm
aW5lZChNSVBTRUwpCisJQ1BVPSR7VU5BTUVfTUFDSElORX1lbAorCSNlbHNlCisJI2lmIGRlZmlu
ZWQoX19NSVBTRUJfXykgfHwgZGVmaW5lZChfX01JUFNFQikgfHwgZGVmaW5lZChfTUlQU0VCKSB8
fCBkZWZpbmVkKE1JUFNFQikKKwlDUFU9JHtVTkFNRV9NQUNISU5FfQorCSNlbHNlCisJQ1BVPQor
CSNlbmRpZgorCSNlbmRpZgorRU9GCisJZXZhbCBgJENDX0ZPUl9CVUlMRCAtRSAkZHVtbXkuYyAy
Pi9kZXYvbnVsbCB8IGdyZXAgJ15DUFUnYAorCXRlc3QgeCIke0NQVX0iICE9IHggJiYgeyBlY2hv
ICIke0NQVX0tdW5rbm93bi1saW51eC1nbnUiOyBleGl0OyB9CisJOzsKKyAgICBvcjMyOkxpbnV4
Oio6KikKKwllY2hvIG9yMzItdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgcGFkcmU6
TGludXg6KjoqKQorCWVjaG8gc3BhcmMtdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAg
cGFyaXNjNjQ6TGludXg6KjoqIHwgaHBwYTY0OkxpbnV4Oio6KikKKwllY2hvIGhwcGE2NC11bmtu
b3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYXJpc2M6TGludXg6KjoqIHwgaHBwYTpMaW51
eDoqOiopCisJIyBMb29rIGZvciBDUFUgbGV2ZWwKKwljYXNlIGBncmVwICdeY3B1W15hLXpdKjon
IC9wcm9jL2NwdWluZm8gMj4vZGV2L251bGwgfCBjdXQgLWQnICcgLWYyYCBpbgorCSAgUEE3Kikg
ZWNobyBocHBhMS4xLXVua25vd24tbGludXgtZ251IDs7CisJICBQQTgqKSBlY2hvIGhwcGEyLjAt
dW5rbm93bi1saW51eC1nbnUgOzsKKwkgICopICAgIGVjaG8gaHBwYS11bmtub3duLWxpbnV4LWdu
dSA7OworCWVzYWMKKwlleGl0IDs7CisgICAgcHBjNjQ6TGludXg6KjoqKQorCWVjaG8gcG93ZXJw
YzY0LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHBwYzpMaW51eDoqOiopCisJZWNo
byBwb3dlcnBjLXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHMzOTA6TGludXg6Kjoq
IHwgczM5MHg6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1pYm0tbGludXgKKwll
eGl0IDs7CisgICAgc2g2NCo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtu
b3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBzaCo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFN
RV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBzcGFyYzpMaW51eDoq
OiogfCBzcGFyYzY0OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1s
aW51eC1nbnUKKwlleGl0IDs7CisgICAgdGlsZSo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB2YXg6TGludXg6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1kZWMtbGludXgtZ251CisJZXhpdCA7OworICAgIHg4Nl82
NDpMaW51eDoqOiopCisJZWNobyB4ODZfNjQtdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7Cisg
ICAgeHRlbnNhKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGlu
dXgtZ251CisJZXhpdCA7OworICAgIGkqODY6RFlOSVgvcHR4OjQqOiopCisJIyBwdHggNC4wIGRv
ZXMgdW5hbWUgLXMgY29ycmVjdGx5LCB3aXRoIERZTklYL3B0eCBpbiB0aGVyZS4KKwkjIGVhcmxp
ZXIgdmVyc2lvbnMgYXJlIG1lc3NlZCB1cCBhbmQgcHV0IHRoZSBub2RlbmFtZSBpbiBib3RoCisJ
IyBzeXNuYW1lIGFuZCBub2RlbmFtZS4KKwllY2hvIGkzODYtc2VxdWVudC1zeXN2NAorCWV4aXQg
OzsKKyAgICBpKjg2OlVOSVhfU1Y6NC4yTVA6Mi4qKQorCSMgVW5peHdhcmUgaXMgYW4gb2Zmc2hv
b3Qgb2YgU1ZSNCwgYnV0IGl0IGhhcyBpdHMgb3duIHZlcnNpb24KKwkjIG51bWJlciBzZXJpZXMg
c3RhcnRpbmcgd2l0aCAyLi4uCisJIyBJIGFtIG5vdCBwb3NpdGl2ZSB0aGF0IG90aGVyIFNWUjQg
c3lzdGVtcyB3b24ndCBtYXRjaCB0aGlzLAorCSMgSSBqdXN0IGhhdmUgdG8gaG9wZS4gIC0tIHJt
cy4KKwkjIFVzZSBzeXN2NC4ydXcuLi4gc28gdGhhdCBzeXN2NCogbWF0Y2hlcyBpdC4KKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tcGMtc3lzdjQuMnV3JHtVTkFNRV9WRVJTSU9OfQorCWV4aXQgOzsK
KyAgICBpKjg2Ok9TLzI6KjoqKQorCSMgSWYgd2Ugd2VyZSBhYmxlIHRvIGZpbmQgYHVuYW1lJywg
dGhlbiBFTVggVW5peCBjb21wYXRpYmlsaXR5CisJIyBpcyBwcm9iYWJseSBpbnN0YWxsZWQuCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW9zMi1lbXgKKwlleGl0IDs7CisgICAgaSo4NjpYVFMt
MzAwOio6U1RPUCkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zdG9wCisJZXhpdCA7
OworICAgIGkqODY6YXRoZW9zOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1h
dGhlb3MKKwlleGl0IDs7CisgICAgaSo4NjpzeWxsYWJsZToqOiopCisJZWNobyAke1VOQU1FX01B
Q0hJTkV9LXBjLXN5bGxhYmxlCisJZXhpdCA7OworICAgIGkqODY6THlueE9TOjIuKjoqIHwgaSo4
NjpMeW54T1M6My5bMDFdKjoqIHwgaSo4NjpMeW54T1M6NC5bMDJdKjoqKQorCWVjaG8gaTM4Ni11
bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgaSo4NjoqRE9TOio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbXNkb3NkamdwcAorCWV4aXQgOzsKKyAgICBp
Kjg2Oio6NC4qOiogfCBpKjg2OlNZU1RFTV9WOjQuKjoqKQorCVVOQU1FX1JFTD1gZWNobyAke1VO
QU1FX1JFTEVBU0V9IHwgc2VkICdzL1wvTVAkLy8nYAorCWlmIGdyZXAgTm92ZWxsIC91c3IvaW5j
bHVkZS9saW5rLmggPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbgorCQllY2hvICR7VU5BTUVf
TUFDSElORX0tdW5pdmVsLXN5c3Yke1VOQU1FX1JFTH0KKwllbHNlCisJCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1wYy1zeXN2JHtVTkFNRV9SRUx9CisJZmkKKwlleGl0IDs7CisgICAgaSo4NjoqOjU6
WzY3OF0qKQorCSMgVW5peFdhcmUgNy54LCBPcGVuVU5JWCBhbmQgT3BlblNlcnZlciA2LgorCWNh
c2UgYC9iaW4vdW5hbWUgLVggfCBncmVwICJeTWFjaGluZSJgIGluCisJICAgICo0ODYqKQkgICAg
IFVOQU1FX01BQ0hJTkU9aTQ4NiA7OworCSAgICAqUGVudGl1bSkJICAgICBVTkFNRV9NQUNISU5F
PWk1ODYgOzsKKwkgICAgKlBlbnQqfCpDZWxlcm9uKSBVTkFNRV9NQUNISU5FPWk2ODYgOzsKKwll
c2FjCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFTRX0k
e1VOQU1FX1NZU1RFTX0ke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6KjozLjI6
KikKKwlpZiB0ZXN0IC1mIC91c3Ivb3B0aW9ucy9jYi5uYW1lOyB0aGVuCisJCVVOQU1FX1JFTD1g
c2VkIC1uICdzLy4qVmVyc2lvbiAvL3AnIDwvdXNyL29wdGlvbnMvY2IubmFtZWAKKwkJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXBjLWlzYyRVTkFNRV9SRUwKKwllbGlmIC9iaW4vdW5hbWUgLVggMj4v
ZGV2L251bGwgPi9kZXYvbnVsbCA7IHRoZW4KKwkJVU5BTUVfUkVMPWAoL2Jpbi91bmFtZSAtWHxn
cmVwIFJlbGVhc2V8c2VkIC1lICdzLy4qPSAvLycpYAorCQkoL2Jpbi91bmFtZSAtWHxncmVwIGk4
MDQ4NiA+L2Rldi9udWxsKSAmJiBVTkFNRV9NQUNISU5FPWk0ODYKKwkJKC9iaW4vdW5hbWUgLVh8
Z3JlcCAnXk1hY2hpbmUuKlBlbnRpdW0nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJ
TkU9aTU4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFjaGluZS4qUGVudCAqSUknID4vZGV2
L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTY4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVw
ICdeTWFjaGluZS4qUGVudGl1bSBQcm8nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJ
TkU9aTY4NgorCQllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc2NvJFVOQU1FX1JFTAorCWVsc2UK
KwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXN5c3YzMgorCWZpCisJZXhpdCA7OworICAgIHBj
Oio6KjoqKQorCSMgTGVmdCBoZXJlIGZvciBjb21wYXRpYmlsaXR5OgorCSMgdW5hbWUgLW0gcHJp
bnRzIGZvciBESkdQUCBhbHdheXMgJ3BjJywgYnV0IGl0IHByaW50cyBub3RoaW5nIGFib3V0CisJ
IyB0aGUgcHJvY2Vzc29yLCBzbyB3ZSBwbGF5IHNhZmUgYnkgYXNzdW1pbmcgaTU4Ni4KKwkjIE5v
dGU6IHdoYXRldmVyIHRoaXMgaXMsIGl0IE1VU1QgYmUgdGhlIHNhbWUgYXMgd2hhdCBjb25maWcu
c3ViCisJIyBwcmludHMgZm9yIHRoZSAiZGpncHAiIGhvc3QsIG9yIGVsc2UgR0RCIGNvbmZpZ3Vy
eSB3aWxsIGRlY2lkZSB0aGF0CisJIyB0aGlzIGlzIGEgY3Jvc3MtYnVpbGQuCisJZWNobyBpNTg2
LXBjLW1zZG9zZGpncHAKKwlleGl0IDs7CisgICAgSW50ZWw6TWFjaDozKjoqKQorCWVjaG8gaTM4
Ni1wYy1tYWNoMworCWV4aXQgOzsKKyAgICBwYXJhZ29uOio6KjoqKQorCWVjaG8gaTg2MC1pbnRl
bC1vc2YxCisJZXhpdCA7OworICAgIGk4NjA6Kjo0Lio6KikgIyBpODYwLVNWUjQKKwlpZiBncmVw
IFN0YXJkZW50IC91c3IvaW5jbHVkZS9zeXMvdWFkbWluLmggPi9kZXYvbnVsbCAyPiYxIDsgdGhl
bgorCSAgZWNobyBpODYwLXN0YXJkZW50LXN5c3Yke1VOQU1FX1JFTEVBU0V9ICMgU3RhcmRlbnQg
VmlzdHJhIGk4NjAtU1ZSNAorCWVsc2UgIyBBZGQgb3RoZXIgaTg2MC1TVlI0IHZlbmRvcnMgYmVs
b3cgYXMgdGhleSBhcmUgZGlzY292ZXJlZC4KKwkgIGVjaG8gaTg2MC11bmtub3duLXN5c3Yke1VO
QU1FX1JFTEVBU0V9ICAjIFVua25vd24gaTg2MC1TVlI0CisJZmkKKwlleGl0IDs7CisgICAgbWlu
aSo6Q1RJWDpTWVMqNToqKQorCSMgIm1pbmlmcmFtZSIKKwllY2hvIG02ODAxMC1jb252ZXJnZW50
LXN5c3YKKwlleGl0IDs7CisgICAgbWM2OGs6VU5JWDpTWVNURU01OjMuNTFtKQorCWVjaG8gbTY4
ay1jb252ZXJnZW50LXN5c3YKKwlleGl0IDs7CisgICAgTTY4MD8wOkQtTklYOjUuMzoqKQorCWVj
aG8gbTY4ay1kaWFiLWRuaXgKKwlleGl0IDs7CisgICAgTTY4KjoqOlIzVls1Njc4XSo6KikKKwl0
ZXN0IC1yIC9zeXNWNjggJiYgeyBlY2hvICdtNjhrLW1vdG9yb2xhLXN5c3YnOyBleGl0OyB9IDs7
CisgICAgM1szNDVdPz86Kjo0LjA6My4wIHwgM1szNF0/P0E6Kjo0LjA6My4wIHwgM1szNF0/Pywq
Oio6NC4wOjMuMCB8IDNbMzRdPz8vKjoqOjQuMDozLjAgfCA0NDAwOio6NC4wOjMuMCB8IDQ4NTA6
Kjo0LjA6My4wIHwgU0tBNDA6Kjo0LjA6My4wIHwgU0RTMjoqOjQuMDozLjAgfCBTSEcyOio6NC4w
OjMuMCB8IFM3NTAxKjoqOjQuMDozLjApCisJT1NfUkVMPScnCisJdGVzdCAtciAvZXRjLy5yZWxp
ZCBcCisJJiYgT1NfUkVMPS5gc2VkIC1uICdzL1teIF0qIFteIF0qIFwoWzAtOV1bMC05XVwpLiov
XDEvcCcgPCAvZXRjLy5yZWxpZGAKKwkvYmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4
NiA+L2Rldi9udWxsIFwKKwkgICYmIHsgZWNobyBpNDg2LW5jci1zeXN2NC4zJHtPU19SRUx9OyBl
eGl0OyB9CisJL2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVsbCB8IC9iaW4vZ3JlcCBlbnRpdW0gPi9k
ZXYvbnVsbCBcCisJICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsg
fSA7OworICAgIDNbMzRdPz86Kjo0LjA6KiB8IDNbMzRdPz8sKjoqOjQuMDoqKQorCS9iaW4vdW5h
bWUgLXAgMj4vZGV2L251bGwgfCBncmVwIDg2ID4vZGV2L251bGwgXAorCSAgJiYgeyBlY2hvIGk0
ODYtbmNyLXN5c3Y0OyBleGl0OyB9IDs7CisgICAgTkNSKjoqOjQuMjoqIHwgTVBSQVMqOio6NC4y
OiopCisJT1NfUkVMPScuMycKKwl0ZXN0IC1yIC9ldGMvLnJlbGlkIFwKKwkgICAgJiYgT1NfUkVM
PS5gc2VkIC1uICdzL1teIF0qIFteIF0qIFwoWzAtOV1bMC05XVwpLiovXDEvcCcgPCAvZXRjLy5y
ZWxpZGAKKwkvYmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4NiA+L2Rldi9udWxsIFwK
KwkgICAgJiYgeyBlY2hvIGk0ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmlu
L3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIGVudGl1bSA+L2Rldi9udWxsIFwKKwkg
ICAgJiYgeyBlY2hvIGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmluL3Vu
YW1lIC1wIDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIHB0ZXJvbiA+L2Rldi9udWxsIFwKKwkgICAg
JiYgeyBlY2hvIGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0gOzsKKyAgICBtNjgq
Okx5bnhPUzoyLio6KiB8IG02OCo6THlueE9TOjMuMCo6KikKKwllY2hvIG02OGstdW5rbm93bi1s
eW54b3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG1jNjgwMzA6VU5JWF9TeXN0ZW1f
Vjo0Lio6KikKKwllY2hvIG02OGstYXRhcmktc3lzdjQKKwlleGl0IDs7CisgICAgVFNVTkFNSTpM
eW54T1M6Mi4qOiopCisJZWNobyBzcGFyYy11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0K
KwlleGl0IDs7CisgICAgcnM2MDAwOkx5bnhPUzoyLio6KikKKwllY2hvIHJzNjAwMC11bmtub3du
LWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgUG93ZXJQQzpMeW54T1M6Mi4q
OiogfCBQb3dlclBDOkx5bnhPUzozLlswMV0qOiogfCBQb3dlclBDOkx5bnhPUzo0LlswMl0qOiop
CisJZWNobyBwb3dlcnBjLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsK
KyAgICBTTVtCRV1TOlVOSVhfU1Y6KjoqKQorCWVjaG8gbWlwcy1kZGUtc3lzdiR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgUk0qOlJlbGlhbnRVTklYLSo6KjoqKQorCWVjaG8gbWlwcy1z
bmktc3lzdjQKKwlleGl0IDs7CisgICAgUk0qOlNJTklYLSo6KjoqKQorCWVjaG8gbWlwcy1zbmkt
c3lzdjQKKwlleGl0IDs7CisgICAgKjpTSU5JWC0qOio6KikKKwlpZiB1bmFtZSAtcCAyPi9kZXYv
bnVsbCA+L2Rldi9udWxsIDsgdGhlbgorCQlVTkFNRV9NQUNISU5FPWAodW5hbWUgLXApIDI+L2Rl
di9udWxsYAorCQllY2hvICR7VU5BTUVfTUFDSElORX0tc25pLXN5c3Y0CisJZWxzZQorCQllY2hv
IG5zMzJrLXNuaS1zeXN2CisJZmkKKwlleGl0IDs7CisgICAgUEVOVElVTToqOjQuMCo6KikJIyBV
bmlzeXMgYENsZWFyUGF0aCBITVAgSVggNDAwMCcgU1ZSNC9NUCBlZmZvcnQKKwkJCSMgc2F5cyA8
UmljaGFyZC5NLkJhcnRlbEBjY01haWwuQ2Vuc3VzLkdPVj4KKwllY2hvIGk1ODYtdW5pc3lzLXN5
c3Y0CisJZXhpdCA7OworICAgICo6VU5JWF9TeXN0ZW1fVjo0KjpGVFgqKQorCSMgRnJvbSBHZXJh
bGQgSGV3ZXMgPGhld2VzQG9wZW5tYXJrZXQuY29tPi4KKwkjIEhvdyBhYm91dCBkaWZmZXJlbnRp
YXRpbmcgYmV0d2VlbiBzdHJhdHVzIGFyY2hpdGVjdHVyZXM/IC1kam0KKwllY2hvIGhwcGExLjEt
c3RyYXR1cy1zeXN2NAorCWV4aXQgOzsKKyAgICAqOio6KjpGVFgqKQorCSMgRnJvbSBzZWFuZkBz
d2RjLnN0cmF0dXMuY29tLgorCWVjaG8gaTg2MC1zdHJhdHVzLXN5c3Y0CisJZXhpdCA7OworICAg
IGkqODY6Vk9TOio6KikKKwkjIEZyb20gUGF1bC5HcmVlbkBzdHJhdHVzLmNvbS4KKwllY2hvICR7
VU5BTUVfTUFDSElORX0tc3RyYXR1cy12b3MKKwlleGl0IDs7CisgICAgKjpWT1M6KjoqKQorCSMg
RnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVjaG8gaHBwYTEuMS1zdHJhdHVzLXZvcwor
CWV4aXQgOzsKKyAgICBtYzY4KjpBL1VYOio6KikKKwllY2hvIG02OGstYXBwbGUtYXV4JHtVTkFN
RV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBuZXdzKjpORVdTLU9TOjYqOiopCisJZWNobyBtaXBz
LXNvbnktbmV3c29zNgorCWV4aXQgOzsKKyAgICBSWzM0XTAwMDoqU3lzdGVtX1YqOio6KiB8IFI0
MDAwOlVOSVhfU1lTVjoqOiogfCBSKjAwMDpVTklYX1NWOio6KikKKwlpZiBbIC1kIC91c3IvbmVj
IF07IHRoZW4KKwkJZWNobyBtaXBzLW5lYy1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWVsc2UKKwkJ
ZWNobyBtaXBzLXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFTRX0KKwlmaQorCWV4aXQgOzsKKyAg
ICBCZUJveDpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcgb24gaGFyZHdhcmUgbWFkZSBieSBCZSwg
UFBDIG9ubHkuCisJZWNobyBwb3dlcnBjLWJlLWJlb3MKKwlleGl0IDs7CisgICAgQmVNYWM6QmVP
UzoqOiopCSMgQmVPUyBydW5uaW5nIG9uIE1hYyBvciBNYWMgY2xvbmUsIFBQQyBvbmx5LgorCWVj
aG8gcG93ZXJwYy1hcHBsZS1iZW9zCisJZXhpdCA7OworICAgIEJlUEM6QmVPUzoqOiopCSMgQmVP
UyBydW5uaW5nIG9uIEludGVsIFBDIGNvbXBhdGlibGUuCisJZWNobyBpNTg2LXBjLWJlb3MKKwll
eGl0IDs7CisgICAgQmVQQzpIYWlrdToqOiopCSMgSGFpa3UgcnVubmluZyBvbiBJbnRlbCBQQyBj
b21wYXRpYmxlLgorCWVjaG8gaTU4Ni1wYy1oYWlrdQorCWV4aXQgOzsKKyAgICBTWC00OlNVUEVS
LVVYOio6KikKKwllY2hvIHN4NC1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgU1gtNTpTVVBFUi1VWDoqOiopCisJZWNobyBzeDUtbmVjLXN1cGVydXgke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIFNYLTY6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g2LW5lYy1z
dXBlcnV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC03OlNVUEVSLVVYOio6KikK
KwllY2hvIHN4Ny1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gt
ODpTVVBFUi1VWDoqOiopCisJZWNobyBzeDgtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgIFNYLThSOlNVUEVSLVVYOio6KikKKwllY2hvIHN4OHItbmVjLXN1cGVydXgk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFBvd2VyKjpSaGFwc29keToqOiopCisJZWNo
byBwb3dlcnBjLWFwcGxlLXJoYXBzb2R5JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAq
OlJoYXBzb2R5Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tYXBwbGUtcmhhcHNvZHkke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6RGFyd2luOio6KikKKwlVTkFNRV9QUk9DRVNT
T1I9YHVuYW1lIC1wYCB8fCBVTkFNRV9QUk9DRVNTT1I9dW5rbm93bgorCWNhc2UgJFVOQU1FX1BS
T0NFU1NPUiBpbgorCSAgICBpMzg2KQorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCWlmIFsg
IiRDQ19GT1JfQlVJTEQiICE9ICdub19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCQkgIGlmIChl
Y2hvICcjaWZkZWYgX19MUDY0X18nOyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicp
IHwgXAorCQkgICAgICAoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwg
XAorCQkgICAgICBncmVwIElTXzY0QklUX0FSQ0ggPi9kZXYvbnVsbAorCQkgIHRoZW4KKwkJICAg
ICAgVU5BTUVfUFJPQ0VTU09SPSJ4ODZfNjQiCisJCSAgZmkKKwkJZmkgOzsKKwkgICAgdW5rbm93
bikgVU5BTUVfUFJPQ0VTU09SPXBvd2VycGMgOzsKKwllc2FjCisJZWNobyAke1VOQU1FX1BST0NF
U1NPUn0tYXBwbGUtZGFyd2luJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOnByb2Nu
dG8qOio6KiB8ICo6UU5YOlswMTIzNDU2Nzg5XSo6KikKKwlVTkFNRV9QUk9DRVNTT1I9YHVuYW1l
IC1wYAorCWlmIHRlc3QgIiRVTkFNRV9QUk9DRVNTT1IiID0gIng4NiI7IHRoZW4KKwkJVU5BTUVf
UFJPQ0VTU09SPWkzODYKKwkJVU5BTUVfTUFDSElORT1wYworCWZpCisJZWNobyAke1VOQU1FX1BS
T0NFU1NPUn0tJHtVTkFNRV9NQUNISU5FfS1udG8tcW54JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQg
OzsKKyAgICAqOlFOWDoqOjQqKQorCWVjaG8gaTM4Ni1wYy1xbngKKwlleGl0IDs7CisgICAgTkVP
LT86Tk9OU1RPUF9LRVJORUw6KjoqKQorCWVjaG8gbmVvLXRhbmRlbS1uc2ske1VOQU1FX1JFTEVB
U0V9CisJZXhpdCA7OworICAgIE5TRS0/Ok5PTlNUT1BfS0VSTkVMOio6KikKKwllY2hvIG5zZS10
YW5kZW0tbnNrJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBOU1ItPzpOT05TVE9QX0tF
Uk5FTDoqOiopCisJZWNobyBuc3ItdGFuZGVtLW5zayR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgKjpOb25TdG9wLVVYOio6KikKKwllY2hvIG1pcHMtY29tcGFxLW5vbnN0b3B1eAorCWV4
aXQgOzsKKyAgICBCUzIwMDA6UE9TSVgqOio6KikKKwllY2hvIGJzMjAwMC1zaWVtZW5zLXN5c3YK
KwlleGl0IDs7CisgICAgRFMvKjpVTklYX1N5c3RlbV9WOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tJHtVTkFNRV9TWVNURU19LSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpQ
bGFuOToqOiopCisJIyAidW5hbWUgLW0iIGlzIG5vdCBjb25zaXN0ZW50LCBzbyB1c2UgJGNwdXR5
cGUgaW5zdGVhZC4gMzg2CisJIyBpcyBjb252ZXJ0ZWQgdG8gaTM4NiBmb3IgY29uc2lzdGVuY3kg
d2l0aCBvdGhlciB4ODYKKwkjIG9wZXJhdGluZyBzeXN0ZW1zLgorCWlmIHRlc3QgIiRjcHV0eXBl
IiA9ICIzODYiOyB0aGVuCisJICAgIFVOQU1FX01BQ0hJTkU9aTM4NgorCWVsc2UKKwkgICAgVU5B
TUVfTUFDSElORT0iJGNwdXR5cGUiCisJZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93
bi1wbGFuOQorCWV4aXQgOzsKKyAgICAqOlRPUFMtMTA6KjoqKQorCWVjaG8gcGRwMTAtdW5rbm93
bi10b3BzMTAKKwlleGl0IDs7CisgICAgKjpURU5FWDoqOiopCisJZWNobyBwZHAxMC11bmtub3du
LXRlbmV4CisJZXhpdCA7OworICAgIEtTMTA6VE9QUy0yMDoqOiogfCBLTDEwOlRPUFMtMjA6Kjoq
IHwgVFlQRTQ6VE9QUy0yMDoqOiopCisJZWNobyBwZHAxMC1kZWMtdG9wczIwCisJZXhpdCA7Owor
ICAgIFhLTC0xOlRPUFMtMjA6KjoqIHwgVFlQRTU6VE9QUy0yMDoqOiopCisJZWNobyBwZHAxMC14
a2wtdG9wczIwCisJZXhpdCA7OworICAgICo6VE9QUy0yMDoqOiopCisJZWNobyBwZHAxMC11bmtu
b3duLXRvcHMyMAorCWV4aXQgOzsKKyAgICAqOklUUzoqOiopCisJZWNobyBwZHAxMC11bmtub3du
LWl0cworCWV4aXQgOzsKKyAgICBTRUk6KjoqOlNFSVVYKQorCWVjaG8gbWlwcy1zZWktc2VpdXgk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6RHJhZ29uRmx5Oio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1kcmFnb25mbHlgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNl
ZCAtZSAncy9bLShdLiovLydgCisJZXhpdCA7OworICAgICo6KlZNUzoqOiopCisJVU5BTUVfTUFD
SElORT1gKHVuYW1lIC1wKSAyPi9kZXYvbnVsbGAKKwljYXNlICIke1VOQU1FX01BQ0hJTkV9IiBp
bgorCSAgICBBKikgZWNobyBhbHBoYS1kZWMtdm1zIDsgZXhpdCA7OworCSAgICBJKikgZWNobyBp
YTY0LWRlYy12bXMgOyBleGl0IDs7CisJICAgIFYqKSBlY2hvIHZheC1kZWMtdm1zIDsgZXhpdCA7
OworCWVzYWMgOzsKKyAgICAqOlhFTklYOio6U3lzVikKKwllY2hvIGkzODYtcGMteGVuaXgKKwll
eGl0IDs7CisgICAgaSo4Njpza3lvczoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXNr
eW9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfWAgfCBzZWQgLWUgJ3MvIC4qJC8vJworCWV4aXQgOzsK
KyAgICBpKjg2OnJkb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1yZG9zCisJZXhp
dCA7OworICAgIGkqODY6QVJPUzoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLWFyb3MK
KwlleGl0IDs7Citlc2FjCisKKyNlY2hvICcoTm8gdW5hbWUgY29tbWFuZCBvciB1bmFtZSBvdXRw
dXQgbm90IHJlY29nbml6ZWQuKScgMT4mMgorI2VjaG8gIiR7VU5BTUVfTUFDSElORX06JHtVTkFN
RV9TWVNURU19OiR7VU5BTUVfUkVMRUFTRX06JHtVTkFNRV9WRVJTSU9OfSIgMT4mMgorCitldmFs
ICRzZXRfY2NfZm9yX2J1aWxkCitjYXQgPiRkdW1teS5jIDw8RU9GCisjaWZkZWYgX1NFUVVFTlRf
CisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorIyBpbmNsdWRlIDxzeXMvdXRzbmFtZS5oPgorI2Vu
ZGlmCittYWluICgpCit7CisjaWYgZGVmaW5lZCAoc29ueSkKKyNpZiBkZWZpbmVkIChNSVBTRUIp
CisgIC8qIEJGRCB3YW50cyAiYnNkIiBpbnN0ZWFkIG9mICJuZXdzb3MiLiAgUGVyaGFwcyBCRkQg
c2hvdWxkIGJlIGNoYW5nZWQsCisgICAgIEkgZG9uJ3Qga25vdy4uLi4gICovCisgIHByaW50ZiAo
Im1pcHMtc29ueS1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbHNlCisjaW5jbHVkZSA8c3lzL3BhcmFt
Lmg+CisgIHByaW50ZiAoIm02OGstc29ueS1uZXdzb3Mlc1xuIiwKKyNpZmRlZiBORVdTT1M0CisJ
IjQiCisjZWxzZQorCSIiCisjZW5kaWYKKwkpOyBleGl0ICgwKTsKKyNlbmRpZgorI2VuZGlmCisK
KyNpZiBkZWZpbmVkIChfX2FybSkgJiYgZGVmaW5lZCAoX19hY29ybikgJiYgZGVmaW5lZCAoX191
bml4KQorICBwcmludGYgKCJhcm0tYWNvcm4tcmlzY2l4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYK
KworI2lmIGRlZmluZWQgKGhwMzAwKSAmJiAhZGVmaW5lZCAoaHB1eCkKKyAgcHJpbnRmICgibTY4
ay1ocC1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoTmVYVCkKKyNp
ZiAhZGVmaW5lZCAoX19BUkNISVRFQ1RVUkVfXykKKyNkZWZpbmUgX19BUkNISVRFQ1RVUkVfXyAi
bTY4ayIKKyNlbmRpZgorICBpbnQgdmVyc2lvbjsKKyAgdmVyc2lvbj1gKGhvc3RpbmZvIHwgc2Vk
IC1uICdzLy4qTmVYVCBNYWNoIFwoWzAtOV0qXCkuKi9cMS9wJykgMj4vZGV2L251bGxgOworICBp
ZiAodmVyc2lvbiA8IDQpCisgICAgcHJpbnRmICgiJXMtbmV4dC1uZXh0c3RlcCVkXG4iLCBfX0FS
Q0hJVEVDVFVSRV9fLCB2ZXJzaW9uKTsKKyAgZWxzZQorICAgIHByaW50ZiAoIiVzLW5leHQtb3Bl
bnN0ZXAlZFxuIiwgX19BUkNISVRFQ1RVUkVfXywgdmVyc2lvbik7CisgIGV4aXQgKDApOworI2Vu
ZGlmCisKKyNpZiBkZWZpbmVkIChNVUxUSU1BWCkgfHwgZGVmaW5lZCAobjE2KQorI2lmIGRlZmlu
ZWQgKFVNQVhWKQorICBwcmludGYgKCJuczMyay1lbmNvcmUtc3lzdlxuIik7IGV4aXQgKDApOwor
I2Vsc2UKKyNpZiBkZWZpbmVkIChDTVUpCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1tYWNoXG4i
KTsgZXhpdCAoMCk7CisjZWxzZQorICBwcmludGYgKCJuczMyay1lbmNvcmUtYnNkXG4iKTsgZXhp
dCAoMCk7CisjZW5kaWYKKyNlbmRpZgorI2VuZGlmCisKKyNpZiBkZWZpbmVkIChfXzM4NkJTRF9f
KQorICBwcmludGYgKCJpMzg2LXBjLWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBk
ZWZpbmVkIChzZXF1ZW50KQorI2lmIGRlZmluZWQgKGkzODYpCisgIHByaW50ZiAoImkzODYtc2Vx
dWVudC1keW5peFxuIik7IGV4aXQgKDApOworI2VuZGlmCisjaWYgZGVmaW5lZCAobnMzMjAwMCkK
KyAgcHJpbnRmICgibnMzMmstc2VxdWVudC1keW5peFxuIik7IGV4aXQgKDApOworI2VuZGlmCisj
ZW5kaWYKKworI2lmIGRlZmluZWQgKF9TRVFVRU5UXykKKyAgICBzdHJ1Y3QgdXRzbmFtZSB1bjsK
KworICAgIHVuYW1lKCZ1bik7CisKKyAgICBpZiAoc3RybmNtcCh1bi52ZXJzaW9uLCAiVjIiLCAy
KSA9PSAwKSB7CisJcHJpbnRmICgiaTM4Ni1zZXF1ZW50LXB0eDJcbiIpOyBleGl0ICgwKTsKKyAg
ICB9CisgICAgaWYgKHN0cm5jbXAodW4udmVyc2lvbiwgIlYxIiwgMikgPT0gMCkgeyAvKiBYWFgg
aXMgVjEgY29ycmVjdD8gKi8KKwlwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4MVxuIik7IGV4aXQg
KDApOworICAgIH0KKyAgICBwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4XG4iKTsgZXhpdCAoMCk7
CisKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAodmF4KQorIyBpZiAhZGVmaW5lZCAodWx0cml4KQor
IyAgaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjICBpZiBkZWZpbmVkIChCU0QpCisjICAgaWYgQlNE
ID09IDQzCisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZDQuM1xuIik7IGV4aXQgKDApOworIyAg
IGVsc2UKKyMgICAgaWYgQlNEID09IDE5OTAwNgorICAgICAgcHJpbnRmICgidmF4LWRlYy1ic2Q0
LjNyZW5vXG4iKTsgZXhpdCAoMCk7CisjICAgIGVsc2UKKyAgICAgIHByaW50ZiAoInZheC1kZWMt
YnNkXG4iKTsgZXhpdCAoMCk7CisjICAgIGVuZGlmCisjICAgZW5kaWYKKyMgIGVsc2UKKyAgICBw
cmludGYgKCJ2YXgtZGVjLWJzZFxuIik7IGV4aXQgKDApOworIyAgZW5kaWYKKyMgZWxzZQorICAg
IHByaW50ZiAoInZheC1kZWMtdWx0cml4XG4iKTsgZXhpdCAoMCk7CisjIGVuZGlmCisjZW5kaWYK
KworI2lmIGRlZmluZWQgKGFsbGlhbnQpICYmIGRlZmluZWQgKGk4NjApCisgIHByaW50ZiAoImk4
NjAtYWxsaWFudC1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisgIGV4aXQgKDEpOworfQor
RU9GCisKKyRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jIDI+L2Rldi9udWxsICYmIFNZ
U1RFTV9OQU1FPWAkZHVtbXlgICYmCisJeyBlY2hvICIkU1lTVEVNX05BTUUiOyBleGl0OyB9CisK
KyMgQXBvbGxvcyBwdXQgdGhlIHN5c3RlbSB0eXBlIGluIHRoZSBlbnZpcm9ubWVudC4KKwordGVz
dCAtZCAvdXNyL2Fwb2xsbyAmJiB7IGVjaG8gJHtJU1B9LWFwb2xsby0ke1NZU1RZUEV9OyBleGl0
OyB9CisKKyMgQ29udmV4IHZlcnNpb25zIHRoYXQgcHJlZGF0ZSB1bmFtZSBjYW4gdXNlIGdldHN5
c2luZm8oMSkKKworaWYgWyAteCAvdXNyL2NvbnZleC9nZXRzeXNpbmZvIF0KK3RoZW4KKyAgICBj
YXNlIGBnZXRzeXNpbmZvIC1mIGNwdV90eXBlYCBpbgorICAgIGMxKikKKwllY2hvIGMxLWNvbnZl
eC1ic2QKKwlleGl0IDs7CisgICAgYzIqKQorCWlmIGdldHN5c2luZm8gLWYgc2NhbGFyX2FjYwor
CXRoZW4gZWNobyBjMzItY29udmV4LWJzZAorCWVsc2UgZWNobyBjMi1jb252ZXgtYnNkCisJZmkK
KwlleGl0IDs7CisgICAgYzM0KikKKwllY2hvIGMzNC1jb252ZXgtYnNkCisJZXhpdCA7OworICAg
IGMzOCopCisJZWNobyBjMzgtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBjNCopCisJZWNobyBj
NC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGVzYWMKK2ZpCisKK2NhdCA+JjIgPDxFT0YKKyQw
OiB1bmFibGUgdG8gZ3Vlc3Mgc3lzdGVtIHR5cGUKKworVGhpcyBzY3JpcHQsIGxhc3QgbW9kaWZp
ZWQgJHRpbWVzdGFtcCwgaGFzIGZhaWxlZCB0byByZWNvZ25pemUKK3RoZSBvcGVyYXRpbmcgc3lz
dGVtIHlvdSBhcmUgdXNpbmcuIEl0IGlzIGFkdmlzZWQgdGhhdCB5b3UKK2Rvd25sb2FkIHRoZSBt
b3N0IHVwIHRvIGRhdGUgdmVyc2lvbiBvZiB0aGUgY29uZmlnIHNjcmlwdHMgZnJvbQorCisgIGh0
dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxh
aW47Zj1jb25maWcuZ3Vlc3M7aGI9SEVBRAorYW5kCisgIGh0dHA6Ly9naXQuc2F2YW5uYWguZ251
Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47Zj1jb25maWcuc3ViO2hiPUhF
QUQKKworSWYgdGhlIHZlcnNpb24geW91IHJ1biAoJDApIGlzIGFscmVhZHkgdXAgdG8gZGF0ZSwg
cGxlYXNlCitzZW5kIHRoZSBmb2xsb3dpbmcgZGF0YSBhbmQgYW55IGluZm9ybWF0aW9uIHlvdSB0
aGluayBtaWdodCBiZQorcGVydGluZW50IHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPiBpbiBv
cmRlciB0byBwcm92aWRlIHRoZSBuZWVkZWQKK2luZm9ybWF0aW9uIHRvIGhhbmRsZSB5b3VyIHN5
c3RlbS4KKworY29uZmlnLmd1ZXNzIHRpbWVzdGFtcCA9ICR0aW1lc3RhbXAKKwordW5hbWUgLW0g
PSBgKHVuYW1lIC1tKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtciA9IGAo
dW5hbWUgLXIpIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1zID0gYCh1bmFt
ZSAtcykgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXYgPSBgKHVuYW1lIC12
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCisKKy91c3IvYmluL3VuYW1lIC1wID0gYCgv
dXNyL2Jpbi91bmFtZSAtcCkgMj4vZGV2L251bGxgCisvYmluL3VuYW1lIC1YICAgICA9IGAoL2Jp
bi91bmFtZSAtWCkgMj4vZGV2L251bGxgCisKK2hvc3RpbmZvICAgICAgICAgICAgICAgPSBgKGhv
c3RpbmZvKSAyPi9kZXYvbnVsbGAKKy9iaW4vdW5pdmVyc2UgICAgICAgICAgPSBgKC9iaW4vdW5p
dmVyc2UpIDI+L2Rldi9udWxsYAorL3Vzci9iaW4vYXJjaCAtayAgICAgICA9IGAoL3Vzci9iaW4v
YXJjaCAtaykgMj4vZGV2L251bGxgCisvYmluL2FyY2ggICAgICAgICAgICAgID0gYCgvYmluL2Fy
Y2gpIDI+L2Rldi9udWxsYAorL3Vzci9iaW4vb3NsZXZlbCAgICAgICA9IGAoL3Vzci9iaW4vb3Ns
ZXZlbCkgMj4vZGV2L251bGxgCisvdXNyL2NvbnZleC9nZXRzeXNpbmZvID0gYCgvdXNyL2NvbnZl
eC9nZXRzeXNpbmZvKSAyPi9kZXYvbnVsbGAKKworVU5BTUVfTUFDSElORSA9ICR7VU5BTUVfTUFD
SElORX0KK1VOQU1FX1JFTEVBU0UgPSAke1VOQU1FX1JFTEVBU0V9CitVTkFNRV9TWVNURU0gID0g
JHtVTkFNRV9TWVNURU19CitVTkFNRV9WRVJTSU9OID0gJHtVTkFNRV9WRVJTSU9OfQorRU9GCisK
K2V4aXQgMQorCisjIExvY2FsIHZhcmlhYmxlczoKKyMgZXZhbDogKGFkZC1ob29rICd3cml0ZS1m
aWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1lLXN0YW1wLXN0YXJ0OiAidGltZXN0YW1wPSci
CisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0tJTAyZCIKKyMgdGltZS1zdGFtcC1lbmQ6
ICInIgorIyBFbmQ6CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9j
b25maWcuaC5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi90b29scy9jb25maWcuaC5pbglNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSw0NDYgQEAKKy8qIGNvbmZpZy5oLmluLiAgR2VuZXJhdGVkIGZyb20gY29uZmlndXJl
LmFjIGJ5IGF1dG9oZWFkZXIuICAqLworCisvKiBEZWZpbmUgdG8gb25lIG9mIGBfZ2V0YjY3Jywg
YEdFVEI2NycsIGBnZXRiNjcnIGZvciBDcmF5LTIgYW5kIENyYXktWU1QCisgICBzeXN0ZW1zLiBU
aGlzIGZ1bmN0aW9uIGlzIHJlcXVpcmVkIGZvciBgYWxsb2NhLmMnIHN1cHBvcnQgb24gdGhvc2Ug
c3lzdGVtcy4KKyAgICovCisjdW5kZWYgQ1JBWV9TVEFDS1NFR19FTkQKKworLyogRGVmaW5lIHRv
IDEgaWYgdXNpbmcgYGFsbG9jYS5jJy4gKi8KKyN1bmRlZiBDX0FMTE9DQQorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGFsYXJtJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0FM
QVJNCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIGBhbGxvY2EnLCBhcyBhIGZ1bmN0aW9u
IG9yIG1hY3JvLiAqLworI3VuZGVmIEhBVkVfQUxMT0NBCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIDxhbGxvY2EuaD4gYW5kIGl0IHNob3VsZCBiZSB1c2VkIChub3Qgb24gVWx0cml4KS4K
KyAgICovCisjdW5kZWYgSEFWRV9BTExPQ0FfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPGFycGEvaW5ldC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0FSUEFfSU5F
VF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgYXRleGl0JyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX0FURVhJVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YGJ6ZXJvJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0JaRVJPCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgY2xvY2tfZ2V0dGltZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFW
RV9DTE9DS19HRVRUSU1FCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZHVwMicg
ZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9EVVAyCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSA8ZmNudGwuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9GQ05UTF9ICisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZmRhdGFzeW5jJyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX0ZEQVRBU1lOQworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YGZvcmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfRk9SSworCisvKiBEZWZpbmUgdG8gMSBp
ZiBmc2Vla28gKGFuZCBwcmVzdW1hYmx5IGZ0ZWxsbykgZXhpc3RzIGFuZCBpcyBkZWNsYXJlZC4g
Ki8KKyN1bmRlZiBIQVZFX0ZTRUVLTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YGZ0cnVuY2F0ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9GVFJVTkNBVEUKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRjd2QnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfR0VUQ1dECisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZ2V0aG9zdGJ5bmFt
ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRIT1NUQllOQU1FCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSBgZ2V0aG9zdG5hbWUnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfR0VUSE9TVE5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRwYWdl
c2l6ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRQQUdFU0laRQorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldHRpbWVvZmRheScgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9HRVRUSU1FT0ZEQVkKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBpbmV0
X250b2EnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfSU5FVF9OVE9BCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8aW50dHlwZXMuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYg
SEFWRV9JTlRUWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgaXNhc2Np
aScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9JU0FTQ0lJCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgY3J5cHRvJyBsaWJyYXJ5ICgtbGNyeXB0bykuICovCisjdW5kZWYgSEFW
RV9MSUJDUllQVE8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxsaWJpbnRsLmg+
IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTElCSU5UTF9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgcnQnIGxpYnJhcnkgKC1scnQpLiAqLworI3VuZGVmIEhBVkVfTElC
UlQKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB1dWlkJyBsaWJyYXJ5ICgtbHV1
aWQpLiAqLworI3VuZGVmIEhBVkVfTElCVVVJRAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHlhamwnIGxpYnJhcnkgKC1seWFqbCkuICovCisjdW5kZWYgSEFWRV9MSUJZQUpMCisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgeicgbGlicmFyeSAoLWx6KS4gKi8KKyN1
bmRlZiBIQVZFX0xJQloKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxsaW1pdHMu
aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9MSU1JVFNfSAorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgaGF2ZSB0aGUgYGxvY2FsdGltZV9yJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X0xPQ0FMVElNRV9SCisKKy8qIERlZmluZSB0byAxIGlmIHlvdXIgc3lzdGVtIGhhcyBhIEdOVSBs
aWJjIGNvbXBhdGlibGUgYG1hbGxvYycgZnVuY3Rpb24sIGFuZAorICAgdG8gMCBvdGhlcndpc2Uu
ICovCisjdW5kZWYgSEFWRV9NQUxMT0MKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IDxtYWxsb2MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9NQUxMT0NfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbWNocicgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9NRU1DSFIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBtZW1tb3ZlJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01FTU1PVkUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxtZW1vcnkuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9NRU1PUllf
SAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbXNldCcgZnVuY3Rpb24uICov
CisjdW5kZWYgSEFWRV9NRU1TRVQKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBt
a2RpcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NS0RJUgorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYG1rZmlmbycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NS0ZJRk8K
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgYSB3b3JraW5nIGBtbWFwJyBzeXN0ZW0gY2Fs
bC4gKi8KKyN1bmRlZiBIQVZFX01NQVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IGBtdW5tYXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTVVOTUFQCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8bmV0ZGIuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFW
RV9ORVREQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bmV0aW5ldC9pbi5o
PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX05FVElORVRfSU5fSAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHBhdGhjb25mJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X1BBVEhDT05GCisKKy8qIERlZmluZSB0byAxIGlmIHRoZSBzeXN0ZW0gaGFzIHRoZSB0eXBlIGBw
dHJkaWZmX3QnLiAqLworI3VuZGVmIEhBVkVfUFRSRElGRl9UCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdXIgc3lzdGVtIGhhcyBhIEdOVSBsaWJjIGNvbXBhdGlibGUgYHJlYWxsb2MnIGZ1bmN0aW9u
LAorICAgYW5kIHRvIDAgb3RoZXJ3aXNlLiAqLworI3VuZGVmIEhBVkVfUkVBTExPQworCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJlYWxwYXRoJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1JFQUxQQVRICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgcmVnY29t
cCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9SRUdDT01QCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgcm1kaXInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUk1ESVIKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzZWxlY3QnIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfU0VMRUNUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc2V0ZW52
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NFVEVOVgorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgYHNvY2tldCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TT0NLRVQKKwor
LyogRGVmaW5lIHRvIDEgaWYgc3RkYm9vbC5oIGNvbmZvcm1zIHRvIEM5OS4gKi8KKyN1bmRlZiBI
QVZFX1NUREJPT0xfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGRlZi5o
PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURERFRl9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8c3RkaW50Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1RESU5UX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdGRsaWIuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERMSUJfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgYHN0cmNhc2VjbXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ0FT
RUNNUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmNocicgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9TVFJDSFIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IGBzdHJjc3BuJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUkNTUE4KKworLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJkdXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVf
U1RSRFVQCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyZXJyb3InIGZ1bmN0
aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSRVJST1IKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzdHJpbmdzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1RSSU5HU19I
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5nLmg+IGhlYWRlciBmaWxl
LiAqLworI3VuZGVmIEhBVkVfU1RSSU5HX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBzdHJuZHVwJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUk5EVVAKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJwYnJrJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBI
QVZFX1NUUlBCUksKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJyY2hyJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlJDSFIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBzdHJzcG4nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSU1BOCisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3Ryc3RyJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1NUUlNUUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnRvbCcg
ZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJUT0wKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBzdHJ0b3VsJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlRPVUwKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJ0b3VsbCcgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9TVFJUT1VMTAorCisvKiBEZWZpbmUgdG8gMSBpZiBgc3RfYmxrc2l6ZScgaXMg
YSBtZW1iZXIgb2YgYHN0cnVjdCBzdGF0Jy4gKi8KKyN1bmRlZiBIQVZFX1NUUlVDVF9TVEFUX1NU
X0JMS1NJWkUKKworLyogRGVmaW5lIHRvIDEgaWYgYHN0X2Jsb2NrcycgaXMgYSBtZW1iZXIgb2Yg
YHN0cnVjdCBzdGF0Jy4gKi8KKyN1bmRlZiBIQVZFX1NUUlVDVF9TVEFUX1NUX0JMT0NLUworCisv
KiBEZWZpbmUgdG8gMSBpZiBgc3RfcmRldicgaXMgYSBtZW1iZXIgb2YgYHN0cnVjdCBzdGF0Jy4g
Ki8KKyN1bmRlZiBIQVZFX1NUUlVDVF9TVEFUX1NUX1JERVYKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91ciBgc3RydWN0IHN0YXQnIGhhcyBgc3RfYmxvY2tzJy4gRGVwcmVjYXRlZCwgdXNlCisgICBg
SEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MnIGluc3RlYWQuICovCisjdW5kZWYgSEFWRV9TVF9C
TE9DS1MKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXNsb2cuaD4gaGVhZGVy
IGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNMT0dfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug
aGF2ZSB0aGUgPHN5cy9maWxlLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX0ZJ
TEVfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9pb2N0bC5oPiBoZWFk
ZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19JT0NUTF9ICisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSA8c3lzL21vdW50Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1lTX01PVU5UX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvcGFyYW0u
aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfUEFSQU1fSAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zb2NrZXQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9TWVNfU09DS0VUX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxz
eXMvc3RhdHZmcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19TVEFUVkZTX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvc3RhdC5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19TVEFUX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzeXMvdGltZS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19USU1F
X0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvdHlwZXMuaD4gaGVhZGVy
IGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfVFlQRVNfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPHRlcm1pb3MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9URVJN
SU9TX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB0enNldCcgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9UWlNFVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHVuYW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1VOQU1FCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8dW5pc3RkLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
VU5JU1REX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB2Zm9yaycgZnVuY3Rp
b24uICovCisjdW5kZWYgSEFWRV9WRk9SSworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHZmb3JrLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfVkZPUktfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiBgZm9yaycgd29ya3MuICovCisjdW5kZWYgSEFWRV9XT1JLSU5HX0ZPUksK
KworLyogRGVmaW5lIHRvIDEgaWYgYHZmb3JrJyB3b3Jrcy4gKi8KKyN1bmRlZiBIQVZFX1dPUktJ
TkdfVkZPUksKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx5YWpsL3lhamxfdmVy
c2lvbi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1lBSkxfWUFKTF9WRVJTSU9OX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgdGhlIHN5c3RlbSBoYXMgdGhlIHR5cGUgYF9Cb29sJy4gKi8K
KyN1bmRlZiBIQVZFX19CT09MCisKKy8qIERlZmluZSB0byAxIGlmIGBsc3RhdCcgZGVyZWZlcmVu
Y2VzIGEgc3ltbGluayBzcGVjaWZpZWQgd2l0aCBhIHRyYWlsaW5nCisgICBzbGFzaC4gKi8KKyN1
bmRlZiBMU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSworCisvKiBEZWZpbmUgdG8gMSBpZiBg
bWFqb3InLCBgbWlub3InLCBhbmQgYG1ha2VkZXYnIGFyZSBkZWNsYXJlZCBpbiA8bWtkZXYuaD4u
CisgICAqLworI3VuZGVmIE1BSk9SX0lOX01LREVWCisKKy8qIERlZmluZSB0byAxIGlmIGBtYWpv
cicsIGBtaW5vcicsIGFuZCBgbWFrZWRldicgYXJlIGRlY2xhcmVkIGluCisgICA8c3lzbWFjcm9z
Lmg+LiAqLworI3VuZGVmIE1BSk9SX0lOX1NZU01BQ1JPUworCisvKiBEZWZpbmUgdG8gdGhlIGFk
ZHJlc3Mgd2hlcmUgYnVnIHJlcG9ydHMgZm9yIHRoaXMgcGFja2FnZSBzaG91bGQgYmUgc2VudC4g
Ki8KKyN1bmRlZiBQQUNLQUdFX0JVR1JFUE9SVAorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFt
ZSBvZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9OQU1FCisKKy8qIERlZmluZSB0
byB0aGUgZnVsbCBuYW1lIGFuZCB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQ
QUNLQUdFX1NUUklORworCisvKiBEZWZpbmUgdG8gdGhlIG9uZSBzeW1ib2wgc2hvcnQgbmFtZSBv
ZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9UQVJOQU1FCisKKy8qIERlZmluZSB0
byB0aGUgaG9tZSBwYWdlIGZvciB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9VUkwK
KworLyogRGVmaW5lIHRvIHRoZSB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQ
QUNLQUdFX1ZFUlNJT04KKworLyogSWYgdXNpbmcgdGhlIEMgaW1wbGVtZW50YXRpb24gb2YgYWxs
b2NhLCBkZWZpbmUgaWYgeW91IGtub3cgdGhlCisgICBkaXJlY3Rpb24gb2Ygc3RhY2sgZ3Jvd3Ro
IGZvciB5b3VyIHN5c3RlbTsgb3RoZXJ3aXNlIGl0IHdpbGwgYmUKKyAgIGF1dG9tYXRpY2FsbHkg
ZGVkdWNlZCBhdCBydW50aW1lLgorCVNUQUNLX0RJUkVDVElPTiA+IDAgPT4gZ3Jvd3MgdG93YXJk
IGhpZ2hlciBhZGRyZXNzZXMKKwlTVEFDS19ESVJFQ1RJT04gPCAwID0+IGdyb3dzIHRvd2FyZCBs
b3dlciBhZGRyZXNzZXMKKwlTVEFDS19ESVJFQ1RJT04gPSAwID0+IGRpcmVjdGlvbiBvZiBncm93
dGggdW5rbm93biAqLworI3VuZGVmIFNUQUNLX0RJUkVDVElPTgorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgQU5TSSBDIGhlYWRlciBmaWxlcy4gKi8KKyN1bmRlZiBTVERDX0hFQURF
UlMKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGNhbiBzYWZlbHkgaW5jbHVkZSBib3RoIDxzeXMv
dGltZS5oPiBhbmQgPHRpbWUuaD4uICovCisjdW5kZWYgVElNRV9XSVRIX1NZU19USU1FCisKKy8q
IERlZmluZSB0byAxIHRvIG1ha2UgZnNlZWtvIHZpc2libGUgb24gc29tZSBob3N0cyAoZS5nLiBn
bGliYyAyLjIpLiAqLworI3VuZGVmIF9MQVJHRUZJTEVfU09VUkNFCisKKy8qIERlZmluZSB0byAx
IGlmIG9uIE1JTklYLiAqLworI3VuZGVmIF9NSU5JWAorCisvKiBEZWZpbmUgdG8gMiBpZiB0aGUg
c3lzdGVtIGRvZXMgbm90IHByb3ZpZGUgUE9TSVguMSBmZWF0dXJlcyBleGNlcHQgd2l0aAorICAg
dGhpcyBkZWZpbmVkLiAqLworI3VuZGVmIF9QT1NJWF8xX1NPVVJDRQorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgbmVlZCB0byBpbiBvcmRlciBmb3IgYHN0YXQnIGFuZCBvdGhlciB0aGluZ3MgdG8g
d29yay4gKi8KKyN1bmRlZiBfUE9TSVhfU09VUkNFCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAy
LjUuMSBzbyB0aGUgdWludDMyX3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisgICA8cHRo
cmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVkZWYgd2Vy
ZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50YXggZXJy
b3IuICovCisjdW5kZWYgX1VJTlQzMl9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAyLjUuMSBz
byB0aGUgdWludDY0X3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisgICA8cHRocmVhZC5o
Piwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVkZWYgd2VyZSBhbGxv
d2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50YXggZXJyb3IuICov
CisjdW5kZWYgX1VJTlQ2NF9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAyLjUuMSBzbyB0aGUg
dWludDhfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+LCBvciA8
c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93ZWQsIHRo
ZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8KKyN1bmRl
ZiBfVUlOVDhfVAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2Vzbid0
IGRlZmluZS4gKi8KKyN1bmRlZiBnaWRfdAorCisvKiBEZWZpbmUgdG8gYF9faW5saW5lX18nIG9y
IGBfX2lubGluZScgaWYgdGhhdCdzIHdoYXQgdGhlIEMgY29tcGlsZXIKKyAgIGNhbGxzIGl0LCBv
ciB0byBub3RoaW5nIGlmICdpbmxpbmUnIGlzIG5vdCBzdXBwb3J0ZWQgdW5kZXIgYW55IG5hbWUu
ICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cworI3VuZGVmIGlubGluZQorI2VuZGlmCisKKy8qIERl
ZmluZSB0byB0aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3Rs
eSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNs
dWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIGludDE2X3QKKworLyogRGVmaW5lIHRv
IHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDMyIGJp
dHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRv
IG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MzJfdAorCisvKiBEZWZpbmUgdG8gdGhlIHR5
cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkgNjQgYml0cyBpZgor
ICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRl
ZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQ2NF90CisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBh
IHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMgaWYgc3VjaAorICAg
YSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5vdCBkZWZpbmUgaXQu
ICovCisjdW5kZWYgaW50OF90CisKKy8qIERlZmluZSB0byBycGxfbWFsbG9jIGlmIHRoZSByZXBs
YWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiBtYWxsb2MKKworLyog
RGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVmaW5lLiAqLworI3Vu
ZGVmIG1vZGVfdAorCisvKiBEZWZpbmUgdG8gYGxvbmcgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRv
ZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBvZmZfdAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYg
PHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgcGlkX3QKKworLyogRGVm
aW5lIHRvIHJwbF9yZWFsbG9jIGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUg
dXNlZC4gKi8KKyN1bmRlZiByZWFsbG9jCisKKy8qIERlZmluZSB0byB0aGUgZXF1aXZhbGVudCBv
ZiB0aGUgQzk5ICdyZXN0cmljdCcga2V5d29yZCwgb3IgdG8KKyAgIG5vdGhpbmcgaWYgdGhpcyBp
cyBub3Qgc3VwcG9ydGVkLiAgRG8gbm90IGRlZmluZSBpZiByZXN0cmljdCBpcworICAgc3VwcG9y
dGVkIGRpcmVjdGx5LiAgKi8KKyN1bmRlZiByZXN0cmljdAorLyogV29yayBhcm91bmQgYSBidWcg
aW4gU3VuIEMrKzogaXQgZG9lcyBub3Qgc3VwcG9ydCBfUmVzdHJpY3Qgb3IKKyAgIF9fcmVzdHJp
Y3RfXywgZXZlbiB0aG91Z2ggdGhlIGNvcnJlc3BvbmRpbmcgU3VuIEMgY29tcGlsZXIgZW5kcyB1
cCB3aXRoCisgICAiI2RlZmluZSByZXN0cmljdCBfUmVzdHJpY3QiIG9yICIjZGVmaW5lIHJlc3Ry
aWN0IF9fcmVzdHJpY3RfXyIgaW4gdGhlCisgICBwcmV2aW91cyBsaW5lLiAgUGVyaGFwcyBzb21l
IGZ1dHVyZSB2ZXJzaW9uIG9mIFN1biBDKysgd2lsbCB3b3JrIHdpdGgKKyAgIHJlc3RyaWN0OyBp
ZiBzbywgaG9wZWZ1bGx5IGl0IGRlZmluZXMgX19SRVNUUklDVCBsaWtlIFN1biBDIGRvZXMuICAq
LworI2lmIGRlZmluZWQgX19TVU5QUk9fQ0MgJiYgIWRlZmluZWQgX19SRVNUUklDVAorIyBkZWZp
bmUgX1Jlc3RyaWN0CisjIGRlZmluZSBfX3Jlc3RyaWN0X18KKyNlbmRpZgorCisvKiBEZWZpbmUg
dG8gYHVuc2lnbmVkIGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisj
dW5kZWYgc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXMg
bm90IGRlZmluZS4gKi8KKyN1bmRlZiBzc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8
c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5lLiAqLworI3VuZGVmIHVpZF90CisKKy8qIERlZmlu
ZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3Rs
eSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNs
dWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQxNl90CisKKy8qIERlZmluZSB0
byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSAz
MiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNsdWRl
cyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQzMl90CisKKy8qIERlZmluZSB0byB0
aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA2NCBi
aXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNsdWRlcyBk
byBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQ2NF90CisKKy8qIERlZmluZSB0byB0aGUg
dHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMg
aWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5v
dCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDhfdAorCisvKiBEZWZpbmUgYXMgYGZvcmsnIGlm
IGB2Zm9yaycgZG9lcyBub3Qgd29yay4gKi8KKyN1bmRlZiB2Zm9yawpkaWZmIC1yIDg3MjE4YmQz
NjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY29uZmlnLnN1YgotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuc3ViCU1vbiBGZWIg
MjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDE3NzEgQEAKKyMhIC9iaW4vc2gKKyMg
Q29uZmlndXJhdGlvbiB2YWxpZGF0aW9uIHN1YnJvdXRpbmUgc2NyaXB0LgorIyAgIENvcHlyaWdo
dCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwKKyMg
ICAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAy
MDA5LCAyMDEwLAorIyAgIDIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3Rp
bWVzdGFtcD0nMjAxMS0xMS0xMScKKworIyBUaGlzIGZpbGUgaXMgKGluIHByaW5jaXBsZSkgY29t
bW9uIHRvIEFMTCBHTlUgc29mdHdhcmUuCisjIFRoZSBwcmVzZW5jZSBvZiBhIG1hY2hpbmUgaW4g
dGhpcyBmaWxlIHN1Z2dlc3RzIHRoYXQgU09NRSBHTlUgc29mdHdhcmUKKyMgY2FuIGhhbmRsZSB0
aGF0IG1hY2hpbmUuICBJdCBkb2VzIG5vdCBpbXBseSBBTEwgR05VIHNvZnR3YXJlIGNhbi4KKyMK
KyMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu
ZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
bjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIgb3B0aW9u
KSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisjIGJ1dCBXSVRIT1VUIEFOWSBXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyMgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91IHNob3Vs
ZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK
KyMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3RyZWV0IC0gRmlmdGggRmxv
b3IsIEJvc3RvbiwgTUEKKyMgMDIxMTAtMTMwMSwgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhj
ZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3Ry
aWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBj
b25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVk
ZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZv
ciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKworIyBQbGVhc2Ugc2VuZCBwYXRjaGVzIHRv
IDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4gIFN1Ym1pdCBhIGNvbnRleHQKKyMgZGlmZiBhbmQg
YSBwcm9wZXJseSBmb3JtYXR0ZWQgR05VIENoYW5nZUxvZyBlbnRyeS4KKyMKKyMgQ29uZmlndXJh
dGlvbiBzdWJyb3V0aW5lIHRvIHZhbGlkYXRlIGFuZCBjYW5vbmljYWxpemUgYSBjb25maWd1cmF0
aW9uIHR5cGUuCisjIFN1cHBseSB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24gdHlwZSBhcyBh
biBhcmd1bWVudC4KKyMgSWYgaXQgaXMgaW52YWxpZCwgd2UgcHJpbnQgYW4gZXJyb3IgbWVzc2Fn
ZSBvbiBzdGRlcnIgYW5kIGV4aXQgd2l0aCBjb2RlIDEuCisjIE90aGVyd2lzZSwgd2UgcHJpbnQg
dGhlIGNhbm9uaWNhbCBjb25maWcgdHlwZSBvbiBzdGRvdXQgYW5kIHN1Y2NlZWQuCisKKyMgWW91
IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgc2NyaXB0IGZyb206CisjIGh0dHA6
Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47
Zj1jb25maWcuc3ViO2hiPUhFQUQKKworIyBUaGlzIGZpbGUgaXMgc3VwcG9zZWQgdG8gYmUgdGhl
IHNhbWUgZm9yIGFsbCBHTlUgcGFja2FnZXMKKyMgYW5kIHJlY29nbml6ZSBhbGwgdGhlIENQVSB0
eXBlcywgc3lzdGVtIHR5cGVzIGFuZCBhbGlhc2VzCisjIHRoYXQgYXJlIG1lYW5pbmdmdWwgd2l0
aCAqYW55KiBHTlUgc29mdHdhcmUuCisjIEVhY2ggcGFja2FnZSBpcyByZXNwb25zaWJsZSBmb3Ig
cmVwb3J0aW5nIHdoaWNoIHZhbGlkIGNvbmZpZ3VyYXRpb25zCisjIGl0IGRvZXMgbm90IHN1cHBv
cnQuICBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaAorIyBhIGZhaWx1cmUg
dG8gc3VwcG9ydCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZnJvbSBhIG1lYW5pbmdsZXNzCisjIGNv
bmZpZ3VyYXRpb24uCisKKyMgVGhlIGdvYWwgb2YgdGhpcyBmaWxlIGlzIHRvIG1hcCBhbGwgdGhl
IHZhcmlvdXMgdmFyaWF0aW9ucyBvZiBhIGdpdmVuCisjIG1hY2hpbmUgc3BlY2lmaWNhdGlvbiBp
bnRvIGEgc2luZ2xlIHNwZWNpZmljYXRpb24gaW4gdGhlIGZvcm06CisjCUNQVV9UWVBFLU1BTlVG
QUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNCisjIG9yIGluIHNvbWUgY2FzZXMsIHRoZSBuZXdlciBm
b3VyLXBhcnQgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVSQVRJTkdf
U1lTVEVNCisjIEl0IGlzIHdyb25nIHRvIGVjaG8gYW55IG90aGVyIHR5cGUgb2Ygc3BlY2lmaWNh
dGlvbi4KKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdlPSJcCitV
c2FnZTogJDAgW09QVElPTl0gQ1BVLU1GUi1PUFNZUworICAgICAgICQwIFtPUFRJT05dIEFMSUFT
CisKK0Nhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gbmFtZS4KKworT3BlcmF0aW9uIG1vZGVz
OgorICAtaCwgLS1oZWxwICAgICAgICAgcHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQKKyAgLXQs
IC0tdGltZS1zdGFtcCAgIHByaW50IGRhdGUgb2YgbGFzdCBtb2RpZmljYXRpb24sIHRoZW4gZXhp
dAorICAtdiwgLS12ZXJzaW9uICAgICAgcHJpbnQgdmVyc2lvbiBudW1iZXIsIHRoZW4gZXhpdAor
CitSZXBvcnQgYnVncyBhbmQgcGF0Y2hlcyB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9yZz4uIgor
Cit2ZXJzaW9uPSJcCitHTlUgY29uZmlnLnN1YiAoJHRpbWVzdGFtcCkKKworQ29weXJpZ2h0IChD
KSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LCAyMDAwLAor
MjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCwgMjAwOSwgMjAx
MCwgMjAxMSBGcmVlCitTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1RoaXMgaXMgZnJlZSBz
b2Z0d2FyZTsgc2VlIHRoZSBzb3VyY2UgZm9yIGNvcHlpbmcgY29uZGl0aW9ucy4gIFRoZXJlIGlz
IE5PCit3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iCisKK2hlbHA9IgorVHJ5IFxgJG1lIC0taGVscCcgZm9y
IG1vcmUgaW5mb3JtYXRpb24uIgorCisjIFBhcnNlIGNvbW1hbmQgbGluZQord2hpbGUgdGVzdCAk
IyAtZ3QgMCA7IGRvCisgIGNhc2UgJDEgaW4KKyAgICAtLXRpbWUtc3RhbXAgfCAtLXRpbWUqIHwg
LXQgKQorICAgICAgIGVjaG8gIiR0aW1lc3RhbXAiIDsgZXhpdCA7OworICAgIC0tdmVyc2lvbiB8
IC12ICkKKyAgICAgICBlY2hvICIkdmVyc2lvbiIgOyBleGl0IDs7CisgICAgLS1oZWxwIHwgLS1o
KiB8IC1oICkKKyAgICAgICBlY2hvICIkdXNhZ2UiOyBleGl0IDs7CisgICAgLS0gKSAgICAgIyBT
dG9wIG9wdGlvbiBwcm9jZXNzaW5nCisgICAgICAgc2hpZnQ7IGJyZWFrIDs7CisgICAgLSApCSMg
VXNlIHN0ZGluIGFzIGlucHV0LgorICAgICAgIGJyZWFrIDs7CisgICAgLSogKQorICAgICAgIGVj
aG8gIiRtZTogaW52YWxpZCBvcHRpb24gJDEkaGVscCIKKyAgICAgICBleGl0IDEgOzsKKworICAg
ICpsb2NhbCopCisgICAgICAgIyBGaXJzdCBwYXNzIHRocm91Z2ggYW55IGxvY2FsIG1hY2hpbmUg
dHlwZXMuCisgICAgICAgZWNobyAkMQorICAgICAgIGV4aXQgOzsKKworICAgICogKQorICAgICAg
IGJyZWFrIDs7CisgIGVzYWMKK2RvbmUKKworY2FzZSAkIyBpbgorIDApIGVjaG8gIiRtZTogbWlz
c2luZyBhcmd1bWVudCRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworIDEpIDs7CisgKikgZWNobyAi
JG1lOiB0b28gbWFueSBhcmd1bWVudHMkaGVscCIgPiYyCisgICAgZXhpdCAxOzsKK2VzYWMKKwor
IyBTZXBhcmF0ZSB3aGF0IHRoZSB1c2VyIGdhdmUgaW50byBDUFUtQ09NUEFOWSBhbmQgT1Mgb3Ig
S0VSTkVMLU9TIChpZiBhbnkpLgorIyBIZXJlIHdlIG11c3QgcmVjb2duaXplIGFsbCB0aGUgdmFs
aWQgS0VSTkVMLU9TIGNvbWJpbmF0aW9ucy4KK21heWJlX29zPWBlY2hvICQxIHwgc2VkICdzL15c
KC4qXCktXChbXi1dKi1bXi1dKlwpJC9cMi8nYAorY2FzZSAkbWF5YmVfb3MgaW4KKyAgbnRvLXFu
eCogfCBsaW51eC1nbnUqIHwgbGludXgtYW5kcm9pZCogfCBsaW51eC1kaWV0bGliYyB8IGxpbnV4
LW5ld2xpYiogfCBcCisgIGxpbnV4LXVjbGliYyogfCB1Y2xpbnV4LXVjbGliYyogfCB1Y2xpbnV4
LWdudSogfCBrZnJlZWJzZCotZ251KiB8IFwKKyAga25ldGJzZCotZ251KiB8IG5ldGJzZCotZ251
KiB8IFwKKyAga29wZW5zb2xhcmlzKi1nbnUqIHwgXAorICBzdG9ybS1jaGFvcyogfCBvczItZW14
KiB8IHJ0bWstbm92YSopCisgICAgb3M9LSRtYXliZV9vcworICAgIGJhc2ljX21hY2hpbmU9YGVj
aG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0qXCkkL1wxLydgCisgICAgOzsKKyAg
KikKKyAgICBiYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzLy1bXi1dKiQvLydgCisgICAg
aWYgWyAkYmFzaWNfbWFjaGluZSAhPSAkMSBdCisgICAgdGhlbiBvcz1gZWNobyAkMSB8IHNlZCAn
cy8uKi0vLS8nYAorICAgIGVsc2Ugb3M9OyBmaQorICAgIDs7Citlc2FjCisKKyMjIyBMZXQncyBy
ZWNvZ25pemUgY29tbW9uIG1hY2hpbmVzIGFzIG5vdCBiZWluZyBvcGVyYXRpbmcgc3lzdGVtcyBz
bworIyMjIHRoYXQgdGhpbmdzIGxpa2UgY29uZmlnLnN1YiBkZWNzdGF0aW9uLTMxMDAgd29yay4g
IFdlIGFsc28KKyMjIyByZWNvZ25pemUgc29tZSBtYW51ZmFjdHVyZXJzIGFzIG5vdCBiZWluZyBv
cGVyYXRpbmcgc3lzdGVtcywgc28gd2UKKyMjIyBjYW4gcHJvdmlkZSBkZWZhdWx0IG9wZXJhdGlu
ZyBzeXN0ZW1zIGJlbG93LgorY2FzZSAkb3MgaW4KKwktc3VuKm9zKikKKwkJIyBQcmV2ZW50IGZv
bGxvd2luZyBjbGF1c2UgZnJvbSBoYW5kbGluZyB0aGlzIGludmFsaWQgaW5wdXQuCisJCTs7CisJ
LWRlYyogfCAtbWlwcyogfCAtc2VxdWVudCogfCAtZW5jb3JlKiB8IC1wYzUzMiogfCAtc2dpKiB8
IC1zb255KiB8IFwKKwktYXR0KiB8IC03MzAwKiB8IC0zMzAwKiB8IC1kZWx0YSogfCAtbW90b3Jv
bGEqIHwgLXN1blsyMzRdKiB8IFwKKwktdW5pY29tKiB8IC1pYm0qIHwgLW5leHQgfCAtaHAgfCAt
aXNpKiB8IC1hcG9sbG8gfCAtYWx0b3MqIHwgXAorCS1jb252ZXJnZW50KiB8IC1uY3IqIHwgLW5l
d3MgfCAtMzIqIHwgLTM2MDAqIHwgLTMxMDAqIHwgLWhpdGFjaGkqIHxcCisJLWNbMTIzXSogfCAt
Y29udmV4KiB8IC1zdW4gfCAtY3JkcyB8IC1vbXJvbiogfCAtZGcgfCAtdWx0cmEgfCAtdHRpKiB8
IFwKKwktaGFycmlzIHwgLWRvbHBoaW4gfCAtaGlnaGxldmVsIHwgLWdvdWxkIHwgLWNibSB8IC1u
cyB8IC1tYXNzY29tcCB8IFwKKwktYXBwbGUgfCAtYXhpcyB8IC1rbnV0aCB8IC1jcmF5IHwgLW1p
Y3JvYmxhemUpCisJCW9zPQorCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWJsdWVnZW5lKikK
KwkJb3M9LWNuaworCQk7OworCS1zaW0gfCAtY2lzY28gfCAtb2tpIHwgLXdlYyB8IC13aW5ib25k
KQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7OworCS1zY291dCkKKwkJOzsKKwktd3Jz
KQorCQlvcz0tdnh3b3JrcworCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWNob3J1c29zKikK
KwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktY2hvcnVzcmRiKQor
CQlvcz0tY2hvcnVzcmRiCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktaGl1eCopCisJCW9z
PS1oaXV4d2UyCisJCTs7CisJLXNjbzYpCisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281KQorCQlvcz0t
c2NvMy4ydjUKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1w
Yy8nYAorCQk7OworCS1zY280KQorCQlvcz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQtOV0qKQor
CQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJhc2ljX21h
Y2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktc2NvMy4y
dls0LTldKikKKwkJIyBEb24ndCBmb3JnZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBvciBuZXdl
ci4KKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAor
CQk7OworCS1zY281djYqKQorCQkjIERvbid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlzIDMuMnY0
IG9yIG5ld2VyLgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2
LXBjLydgCisJCTs7CisJLXNjbyopCisJCW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNoaW5lPWBl
Y2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXVkayopCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktaXNj
KQorCQlvcz0taXNjMi4yCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYt
LiovODYtcGMvJ2AKKwkJOzsKKwktY2xpeCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBlci1pbnRl
cmdyYXBoCisJCTs7CisJLWlzYyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktbHlueCopCisJCW9zPS1seW54b3MKKwkJOzsKKwkt
cHR4KikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1zZXF1
ZW50LydgCisJCTs7CisJLXdpbmRvd3NudCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAncy93
aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsKKwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7CisJLW1p
bnQgfCAtbWludFswLTldKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9zPS1taW50
CisJCTs7Citlc2FjCisKKyMgRGVjb2RlIGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNPTVBBTlkg
Y29tYmluYXRpb25zLgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXplIHRoZSBi
YXNpYyBDUFUgdHlwZXMgd2l0aG91dCBjb21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBvbWl0dGVk
IGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUgc3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkxNzUwYSB8
IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFscGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFldjU2IHwg
YWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2NGV2WzQt
OF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhhNjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjddIFwKKwl8
IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFybSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBhcm12WzIz
NDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2ciB8IGF2cjMyIFwKKyAgICAgICAgfCBiZTMyIHwgYmU2
NCBcCisJfCBiZmluIFwKKwl8IGM0eCB8IGNsaXBwZXIgXAorCXwgZDEwdiB8IGQzMHYgfCBkbHgg
fCBkc3AxNnh4IFwKKwl8IGVwaXBoYW55IFwKKwl8IGZpZG8gfCBmcjMwIHwgZnJ2IFwKKwl8IGg4
MzAwIHwgaDg1MDAgfCBocHBhIHwgaHBwYTEuWzAxXSB8IGhwcGEyLjAgfCBocHBhMi4wW253XSB8
IGhwcGE2NCBcCisJfCBoZXhhZ29uIFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlhNjQgXAor
CXwgaXAyayB8IGlxMjAwMCBcCisJfCBsZTMyIHwgbGU2NCBcCisJfCBsbTMyIFwKKwl8IG0zMmMg
fCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsgXAorCXwgbWF4cSB8IG1iIHwg
bWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwgbWlwcyB8IG1pcHNiZSB8IG1p
cHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAorCXwgbWlwczY0IHwgbWlwczY0
ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwgXAorCXwgbWlwczY0b3Jpb24g
fCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlwczY0cjU5MDBlbCBcCisJfCBt
aXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAwIHwgbWlwczY0dnI0MTAwZWwg
XAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAorCXwgbWlwczY0dnI1MDAwIHwg
bWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlwczY0dnI1OTAwZWwgXAorCXwg
bWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMycjIgfCBtaXBzaXNhMzJyMmVs
IFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1pcHNpc2E2NHIyIHwgbWlwc2lz
YTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRzYjFlbCBcCisJfCBtaXBzaXNh
NjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4MzkgfCBtaXBzdHgzOWVsIFwK
Kwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8IG10IFwKKwl8IG1zcDQzMCBc
CisJfCBuZHMzMiB8IG5kczMybGUgfCBuZHMzMmJlIFwKKwl8IG5pb3MgfCBuaW9zMiBcCisJfCBu
czE2ayB8IG5zMzJrIFwKKwl8IG9wZW44IFwKKwl8IG9yMzIgXAorCXwgcGRwMTAgfCBwZHAxMSB8
IHBqIHwgcGpsIFwKKwl8IHBvd2VycGMgfCBwb3dlcnBjNjQgfCBwb3dlcnBjNjRsZSB8IHBvd2Vy
cGNsZSBcCisJfCBweXJhbWlkIFwKKwl8IHJsNzggfCByeCBcCisJfCBzY29yZSBcCisJfCBzaCB8
IHNoWzEyMzRdIHwgc2hbMjRdYSB8IHNoWzI0XWFlYiB8IHNoWzIzXWUgfCBzaFszNF1lYiB8IHNo
ZWIgfCBzaGJlIHwgc2hsZSB8IHNoWzEyMzRdbGUgfCBzaDNlbGUgXAorCXwgc2g2NCB8IHNoNjRs
ZSBcCisJfCBzcGFyYyB8IHNwYXJjNjQgfCBzcGFyYzY0YiB8IHNwYXJjNjR2IHwgc3BhcmM4Nngg
fCBzcGFyY2xldCB8IHNwYXJjbGl0ZSBcCisJfCBzcGFyY3Y4IHwgc3BhcmN2OSB8IHNwYXJjdjli
IHwgc3BhcmN2OXYgXAorCXwgc3B1IFwKKwl8IHRhaG9lIHwgdGljNHggfCB0aWM1NHggfCB0aWM1
NXggfCB0aWM2eCB8IHRpYzgwIHwgdHJvbiBcCisJfCB1Ymljb20zMiBcCisJfCB2ODUwIHwgdjg1
MGUgfCB2ODUwZTEgfCB2ODUwZTIgfCB2ODUwZXMgfCB2ODUwZTJ2MyBcCisJfCB3ZTMyayBcCisJ
fCB4ODYgfCB4YzE2eCB8IHhzdG9ybXkxNiB8IHh0ZW5zYSBcCisJfCB6OGsgfCB6ODApCisJCWJh
c2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93bgorCQk7OworCWM1NHgpCisJCWJhc2lj
X21hY2hpbmU9dGljNTR4LXVua25vd24KKwkJOzsKKwljNTV4KQorCQliYXNpY19tYWNoaW5lPXRp
YzU1eC11bmtub3duCisJCTs7CisJYzZ4KQorCQliYXNpY19tYWNoaW5lPXRpYzZ4LXVua25vd24K
KwkJOzsKKwltNjgxMSB8IG02OGhjMTEgfCBtNjgxMiB8IG02OGhjMTIgfCBwaWNvY2hpcCkKKwkJ
IyBNb3Rvcm9sYSA2OEhDMTEvMTIuCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5r
bm93bgorCQlvcz0tbm9uZQorCQk7OworCW04ODExMCB8IG02ODBbMTIzNDZdMCB8IG02ODM/MiB8
IG02ODM2MCB8IG01MjAwIHwgdjcwIHwgdzY1IHwgejhrKQorCQk7OworCW1zMSkKKwkJYmFzaWNf
bWFjaGluZT1tdC11bmtub3duCisJCTs7CisKKwlzdHJvbmdhcm0gfCB0aHVtYiB8IHhzY2FsZSkK
KwkJYmFzaWNfbWFjaGluZT1hcm0tdW5rbm93bgorCQk7OworCisJeHNjYWxlZWIpCisJCWJhc2lj
X21hY2hpbmU9YXJtZWItdW5rbm93bgorCQk7OworCisJeHNjYWxlZWwpCisJCWJhc2ljX21hY2hp
bmU9YXJtZWwtdW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhhbiBgdW5r
bm93bicKKwkjIGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJlLCBhbmQK
KwkjICgyKSB0aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5pbmcgdXNl
cnMuCisJaSo4NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtcGMK
KwkgIDs7CisJIyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29yZC4KKwkq
LSotKikKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5lIFxgJGJh
c2ljX21hY2hpbmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworCSMgUmVj
b2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgwLSogXAor
CXwgYTI5ay0qIFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1Ni0qIHwg
YWxwaGFldjZbNzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8IGFscGhh
NjRldjU2LSogfCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8IGFscGhh
NjRwY2E1WzY3XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxlLSogfCBh
cm1lYi0qIHwgYXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmUzMi0qIHwgYmU2
NC0qIFwKKwl8IGJmaW4tKiB8IGJzMjAwMC0qIFwKKwl8IGNbMTIzXSogfCBjMzAtKiB8IFtjanRd
OTAtKiB8IGM0eC0qIFwKKwl8IGNsaXBwZXItKiB8IGNyYXludi0qIHwgY3lkcmEtKiBcCisJfCBk
MTB2LSogfCBkMzB2LSogfCBkbHgtKiBcCisJfCBlbHhzaS0qIFwKKwl8IGYzMFswMV0tKiB8IGY3
MDAtKiB8IGZpZG8tKiB8IGZyMzAtKiB8IGZydi0qIHwgZng4MC0qIFwKKwl8IGg4MzAwLSogfCBo
ODUwMC0qIFwKKwl8IGhwcGEtKiB8IGhwcGExLlswMV0tKiB8IGhwcGEyLjAtKiB8IGhwcGEyLjBb
bnddLSogfCBocHBhNjQtKiBcCisJfCBoZXhhZ29uLSogXAorCXwgaSo4Ni0qIHwgaTg2MC0qIHwg
aTk2MC0qIHwgaWE2NC0qIFwKKwl8IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxlMzItKiB8IGxl
NjQtKiBcCisJfCBsbTMyLSogXAorCXwgbTMyYy0qIHwgbTMyci0qIHwgbTMycmxlLSogXAorCXwg
bTY4MDAwLSogfCBtNjgwWzAxMjM0Nl0wLSogfCBtNjgzNjAtKiB8IG02ODM/Mi0qIHwgbTY4ay0q
IFwKKwl8IG04ODExMC0qIHwgbTg4ay0qIHwgbWF4cS0qIHwgbWNvcmUtKiB8IG1ldGFnLSogfCBt
aWNyb2JsYXplLSogXAorCXwgbWlwcy0qIHwgbWlwc2JlLSogfCBtaXBzZWItKiB8IG1pcHNlbC0q
IHwgbWlwc2xlLSogXAorCXwgbWlwczE2LSogXAorCXwgbWlwczY0LSogfCBtaXBzNjRlbC0qIFwK
Kwl8IG1pcHM2NG9jdGVvbi0qIHwgbWlwczY0b2N0ZW9uZWwtKiBcCisJfCBtaXBzNjRvcmlvbi0q
IHwgbWlwczY0b3Jpb25lbC0qIFwKKwl8IG1pcHM2NHI1OTAwLSogfCBtaXBzNjRyNTkwMGVsLSog
XAorCXwgbWlwczY0dnItKiB8IG1pcHM2NHZyZWwtKiBcCisJfCBtaXBzNjR2cjQxMDAtKiB8IG1p
cHM2NHZyNDEwMGVsLSogXAorCXwgbWlwczY0dnI0MzAwLSogfCBtaXBzNjR2cjQzMDBlbC0qIFwK
Kwl8IG1pcHM2NHZyNTAwMC0qIHwgbWlwczY0dnI1MDAwZWwtKiBcCisJfCBtaXBzNjR2cjU5MDAt
KiB8IG1pcHM2NHZyNTkwMGVsLSogXAorCXwgbWlwc2lzYTMyLSogfCBtaXBzaXNhMzJlbC0qIFwK
Kwl8IG1pcHNpc2EzMnIyLSogfCBtaXBzaXNhMzJyMmVsLSogXAorCXwgbWlwc2lzYTY0LSogfCBt
aXBzaXNhNjRlbC0qIFwKKwl8IG1pcHNpc2E2NHIyLSogfCBtaXBzaXNhNjRyMmVsLSogXAorCXwg
bWlwc2lzYTY0c2IxLSogfCBtaXBzaXNhNjRzYjFlbC0qIFwKKwl8IG1pcHNpc2E2NHNyNzFrLSog
fCBtaXBzaXNhNjRzcjcxa2VsLSogXAorCXwgbWlwc3R4MzktKiB8IG1pcHN0eDM5ZWwtKiBcCisJ
fCBtbWl4LSogXAorCXwgbXQtKiBcCisJfCBtc3A0MzAtKiBcCisJfCBuZHMzMi0qIHwgbmRzMzJs
ZS0qIHwgbmRzMzJiZS0qIFwKKwl8IG5pb3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0qIHwgbnAx
LSogfCBuczE2ay0qIHwgbnMzMmstKiBcCisJfCBvcGVuOC0qIFwKKwl8IG9yaW9uLSogXAorCXwg
cGRwMTAtKiB8IHBkcDExLSogfCBwai0qIHwgcGpsLSogfCBwbi0qIHwgcG93ZXItKiBcCisJfCBw
b3dlcnBjLSogfCBwb3dlcnBjNjQtKiB8IHBvd2VycGM2NGxlLSogfCBwb3dlcnBjbGUtKiBcCisJ
fCBweXJhbWlkLSogXAorCXwgcmw3OC0qIHwgcm9tcC0qIHwgcnM2MDAwLSogfCByeC0qIFwKKwl8
IHNoLSogfCBzaFsxMjM0XS0qIHwgc2hbMjRdYS0qIHwgc2hbMjRdYWViLSogfCBzaFsyM11lLSog
fCBzaFszNF1lYi0qIHwgc2hlYi0qIHwgc2hiZS0qIFwKKwl8IHNobGUtKiB8IHNoWzEyMzRdbGUt
KiB8IHNoM2VsZS0qIHwgc2g2NC0qIHwgc2g2NGxlLSogXAorCXwgc3BhcmMtKiB8IHNwYXJjNjQt
KiB8IHNwYXJjNjRiLSogfCBzcGFyYzY0di0qIHwgc3BhcmM4NngtKiB8IHNwYXJjbGV0LSogXAor
CXwgc3BhcmNsaXRlLSogXAorCXwgc3BhcmN2OC0qIHwgc3BhcmN2OS0qIHwgc3BhcmN2OWItKiB8
IHNwYXJjdjl2LSogfCBzdjEtKiB8IHN4Py0qIFwKKwl8IHRhaG9lLSogXAorCXwgdGljMzAtKiB8
IHRpYzR4LSogfCB0aWM1NHgtKiB8IHRpYzU1eC0qIHwgdGljNngtKiB8IHRpYzgwLSogXAorCXwg
dGlsZSotKiBcCisJfCB0cm9uLSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSogfCB2ODUw
ZS0qIHwgdjg1MGUxLSogfCB2ODUwZXMtKiB8IHY4NTBlMi0qIHwgdjg1MGUydjMtKiBcCisJfCB2
YXgtKiBcCisJfCB3ZTMyay0qIFwKKwl8IHg4Ni0qIHwgeDg2XzY0LSogfCB4YzE2eC0qIHwgeHBz
MTAwLSogXAorCXwgeHN0b3JteTE2LSogfCB4dGVuc2EqLSogXAorCXwgeW1wLSogXAorCXwgejhr
LSogfCB6ODAtKikKKwkJOzsKKwkjIFJlY29nbml6ZSB0aGUgYmFzaWMgQ1BVIHR5cGVzIHdpdGhv
dXQgY29tcGFueSBuYW1lLCB3aXRoIGdsb2IgbWF0Y2guCisJeHRlbnNhKikKKwkJYmFzaWNfbWFj
aGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJIyBSZWNvZ25pemUgdGhlIHZhcmlv
dXMgbWFjaGluZSBuYW1lcyBhbmQgYWxpYXNlcyB3aGljaCBzdGFuZAorCSMgZm9yIGEgQ1BVIHR5
cGUgYW5kIGEgY29tcGFueSBhbmQgc29tZXRpbWVzIGV2ZW4gYW4gT1MuCisJMzg2YnNkKQorCQli
YXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tYnNkCisJCTs7CisJM2IxIHwgNzMwMCB8
IDczMDAtYXR0IHwgYXR0LTczMDAgfCBwYzczMDAgfCBzYWZhcmkgfCB1bml4cGMpCisJCWJhc2lj
X21hY2hpbmU9bTY4MDAwLWF0dAorCQk7OworCTNiKikKKwkJYmFzaWNfbWFjaGluZT13ZTMyay1h
dHQKKwkJOzsKKwlhMjlraGlmKQorCQliYXNpY19tYWNoaW5lPWEyOWstYW1kCisJCW9zPS11ZGkK
KwkJOzsKKwlhYmFjdXMpCisJCWJhc2ljX21hY2hpbmU9YWJhY3VzLXVua25vd24KKwkJOzsKKwlh
ZG9iZTY4aykKKwkJYmFzaWNfbWFjaGluZT1tNjgwMTAtYWRvYmUKKwkJb3M9LXNjb3V0CisJCTs7
CisJYWxsaWFudCB8IGZ4ODApCisJCWJhc2ljX21hY2hpbmU9Zng4MC1hbGxpYW50CisJCTs7CisJ
YWx0b3MgfCBhbHRvczMwNjgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hbHRvcworCQk7OworCWFt
MjlrKQorCQliYXNpY19tYWNoaW5lPWEyOWstbm9uZQorCQlvcz0tYnNkCisJCTs7CisJYW1kNjQp
CisJCWJhc2ljX21hY2hpbmU9eDg2XzY0LXBjCisJCTs7CisJYW1kNjQtKikKKwkJYmFzaWNfbWFj
aGluZT14ODZfNjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJ
OzsKKwlhbWRhaGwpCisJCWJhc2ljX21hY2hpbmU9NTgwLWFtZGFobAorCQlvcz0tc3lzdgorCQk7
OworCWFtaWdhIHwgYW1pZ2EtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXVua25vd24KKwkJOzsK
KwlhbWlnYW9zIHwgYW1pZ2Fkb3MpCisJCWJhc2ljX21hY2hpbmU9bTY4ay11bmtub3duCisJCW9z
PS1hbWlnYW9zCisJCTs7CisJYW1pZ2F1bml4IHwgYW1peCkKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LXVua25vd24KKwkJb3M9LXN5c3Y0CisJCTs7CisJYXBvbGxvNjgpCisJCWJhc2ljX21hY2hpbmU9
bTY4ay1hcG9sbG8KKwkJb3M9LXN5c3YKKwkJOzsKKwlhcG9sbG82OGJzZCkKKwkJYmFzaWNfbWFj
aGluZT1tNjhrLWFwb2xsbworCQlvcz0tYnNkCisJCTs7CisJYXJvcykKKwkJYmFzaWNfbWFjaGlu
ZT1pMzg2LXBjCisJCW9zPS1hcm9zCisJCTs7CisJYXV4KQorCQliYXNpY19tYWNoaW5lPW02OGst
YXBwbGUKKwkJb3M9LWF1eAorCQk7OworCWJhbGFuY2UpCisJCWJhc2ljX21hY2hpbmU9bnMzMmst
c2VxdWVudAorCQlvcz0tZHluaXgKKwkJOzsKKwlibGFja2ZpbikKKwkJYmFzaWNfbWFjaGluZT1i
ZmluLXVua25vd24KKwkJb3M9LWxpbnV4CisJCTs7CisJYmxhY2tmaW4tKikKKwkJYmFzaWNfbWFj
aGluZT1iZmluLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9z
PS1saW51eAorCQk7OworCWJsdWVnZW5lKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWlibQor
CQlvcz0tY25rCisJCTs7CisJYzU0eC0qKQorCQliYXNpY19tYWNoaW5lPXRpYzU0eC1gZWNobyAk
YmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM1NXgtKikKKwkJYmFz
aWNfbWFjaGluZT10aWM1NXgtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJOzsKKwljNngtKikKKwkJYmFzaWNfbWFjaGluZT10aWM2eC1gZWNobyAkYmFzaWNfbWFj
aGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM5MCkKKwkJYmFzaWNfbWFjaGluZT1j
OTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY2VnY2MpCisJCWJhc2ljX21hY2hpbmU9YXJt
LXVua25vd24KKwkJb3M9LWNlZ2NjCisJCTs7CisJY29udmV4LWMxKQorCQliYXNpY19tYWNoaW5l
PWMxLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMyKQorCQliYXNpY19tYWNoaW5l
PWMyLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMzMikKKwkJYmFzaWNfbWFjaGlu
ZT1jMzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzM0KQorCQliYXNpY19tYWNo
aW5lPWMzNC1jb252ZXgKKwkJb3M9LWJzZAorCQk7OworCWNvbnZleC1jMzgpCisJCWJhc2ljX21h
Y2hpbmU9YzM4LWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY3JheSB8IGo5MCkKKwkJYmFzaWNf
bWFjaGluZT1qOTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY3JheW52KQorCQliYXNpY19t
YWNoaW5lPWNyYXludi1jcmF5CisJCW9zPS11bmljb3NtcAorCQk7OworCWNyMTYgfCBjcjE2LSop
CisJCWJhc2ljX21hY2hpbmU9Y3IxNi11bmtub3duCisJCW9zPS1lbGYKKwkJOzsKKwljcmRzIHwg
dW5vcykKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWNyZHMKKwkJOzsKKwljcmlzdjMyIHwgY3Jpc3Yz
Mi0qIHwgZXRyYXhmcyopCisJCWJhc2ljX21hY2hpbmU9Y3Jpc3YzMi1heGlzCisJCTs7CisJY3Jp
cyB8IGNyaXMtKiB8IGV0cmF4KikKKwkJYmFzaWNfbWFjaGluZT1jcmlzLWF4aXMKKwkJOzsKKwlj
cngpCisJCWJhc2ljX21hY2hpbmU9Y3J4LXVua25vd24KKwkJb3M9LWVsZgorCQk7OworCWRhMzAg
fCBkYTMwLSopCisJCWJhc2ljX21hY2hpbmU9bTY4ay1kYTMwCisJCTs7CisJZGVjc3RhdGlvbiB8
IGRlY3N0YXRpb24tMzEwMCB8IHBtYXggfCBwbWF4LSogfCBwbWluIHwgZGVjMzEwMCB8IGRlY3N0
YXRuKQorCQliYXNpY19tYWNoaW5lPW1pcHMtZGVjCisJCTs7CisJZGVjc3lzdGVtMTAqIHwgZGVj
MTAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlvcz0tdG9wczEwCisJCTs7CisJZGVj
c3lzdGVtMjAqIHwgZGVjMjAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlvcz0tdG9w
czIwCisJCTs7CisJZGVsdGEgfCAzMzAwIHwgbW90b3JvbGEtMzMwMCB8IG1vdG9yb2xhLWRlbHRh
IFwKKwkgICAgICB8IDMzMDAtbW90b3JvbGEgfCBkZWx0YS1tb3Rvcm9sYSkKKwkJYmFzaWNfbWFj
aGluZT1tNjhrLW1vdG9yb2xhCisJCTs7CisJZGVsdGE4OCkKKwkJYmFzaWNfbWFjaGluZT1tODhr
LW1vdG9yb2xhCisJCW9zPS1zeXN2MworCQk7OworCWRpY29zKQorCQliYXNpY19tYWNoaW5lPWk2
ODYtcGMKKwkJb3M9LWRpY29zCisJCTs7CisJZGpncHApCisJCWJhc2ljX21hY2hpbmU9aTU4Ni1w
YworCQlvcz0tbXNkb3NkamdwcAorCQk7OworCWRweDIwIHwgZHB4MjAtKikKKwkJYmFzaWNfbWFj
aGluZT1yczYwMDAtYnVsbAorCQlvcz0tYm9zeAorCQk7OworCWRweDIqIHwgZHB4MiotYnVsbCkK
KwkJYmFzaWNfbWFjaGluZT1tNjhrLWJ1bGwKKwkJb3M9LXN5c3YzCisJCTs7CisJZWJtb24yOWsp
CisJCWJhc2ljX21hY2hpbmU9YTI5ay1hbWQKKwkJb3M9LWVibW9uCisJCTs7CisJZWx4c2kpCisJ
CWJhc2ljX21hY2hpbmU9ZWx4c2ktZWx4c2kKKwkJb3M9LWJzZAorCQk7OworCWVuY29yZSB8IHVt
YXggfCBtbWF4KQorCQliYXNpY19tYWNoaW5lPW5zMzJrLWVuY29yZQorCQk7OworCWVzMTgwMCB8
IE9TRTY4ayB8IG9zZTY4ayB8IG9zZSB8IE9TRSkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWVyaWNz
c29uCisJCW9zPS1vc2UKKwkJOzsKKwlmeDI4MDApCisJCWJhc2ljX21hY2hpbmU9aTg2MC1hbGxp
YW50CisJCTs7CisJZ2VuaXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstbnMKKwkJOzsKKwlnbWlj
cm8pCisJCWJhc2ljX21hY2hpbmU9dHJvbi1nbWljcm8KKwkJb3M9LXN5c3YKKwkJOzsKKwlnbzMy
KQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWdvMzIKKwkJOzsKKwloMzA1MHIqIHwg
aGl1eCopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRhY2hpCisJCW9zPS1oaXV4d2UyCisJ
CTs7CisJaDgzMDBobXMpCisJCWJhc2ljX21hY2hpbmU9aDgzMDAtaGl0YWNoaQorCQlvcz0taG1z
CisJCTs7CisJaDgzMDB4cmF5KQorCQliYXNpY19tYWNoaW5lPWg4MzAwLWhpdGFjaGkKKwkJb3M9
LXhyYXkKKwkJOzsKKwloODUwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODUwMC1oaXRhY2hpCisJ
CW9zPS1obXMKKwkJOzsKKwloYXJyaXMpCisJCWJhc2ljX21hY2hpbmU9bTg4ay1oYXJyaXMKKwkJ
b3M9LXN5c3YzCisJCTs7CisJaHAzMDAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhwCisJCTs7
CisJaHAzMDBic2QpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlvcz0tYnNkCisJCTs7CisJ
aHAzMDBocHV4KQorCQliYXNpY19tYWNoaW5lPW02OGstaHAKKwkJb3M9LWhwdXgKKwkJOzsKKwlo
cDNrOVswLTldWzAtOV0gfCBocDlbMC05XVswLTldKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjAt
aHAKKwkJOzsKKwlocDlrMlswLTldWzAtOV0gfCBocDlrMzFbMC05XSkKKwkJYmFzaWNfbWFjaGlu
ZT1tNjgwMDAtaHAKKwkJOzsKKwlocDlrM1syLTldWzAtOV0pCisJCWJhc2ljX21hY2hpbmU9bTY4
ay1ocAorCQk7OworCWhwOWs2WzAtOV1bMC05XSB8IGhwNlswLTldWzAtOV0pCisJCWJhc2ljX21h
Y2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwOWs3WzAtNzldWzAtOV0gfCBocDdbMC03OV1bMC05
XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azc4WzAtOV0gfCBocDc4
WzAtOV0pCisJCSMgRklYTUU6IHJlYWxseSBocHBhMi4wLWhwCisJCWJhc2ljX21hY2hpbmU9aHBw
YTEuMS1ocAorCQk7OworCWhwOWs4WzY3XTEgfCBocDhbNjddMSB8IGhwOWs4MFsyNF0gfCBocDgw
WzI0XSB8IGhwOWs4Wzc4XTkgfCBocDhbNzhdOSB8IGhwOWs4OTMgfCBocDg5MykKKwkJIyBGSVhN
RTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJ
aHA5azhbMC05XVsxMzY3OV0gfCBocDhbMC05XVsxMzY3OV0pCisJCWJhc2ljX21hY2hpbmU9aHBw
YTEuMS1ocAorCQk7OworCWhwOWs4WzAtOV1bMC05XSB8IGhwOFswLTldWzAtOV0pCisJCWJhc2lj
X21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwcGEtbmV4dCkKKwkJb3M9LW5leHRzdGVwMwor
CQk7OworCWhwcGFvc2YpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0tb3NmCisJ
CTs7CisJaHBwcm8pCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0tcHJvZWxmCisJ
CTs7CisJaTM3MC1pYm0qIHwgaWJtKikKKwkJYmFzaWNfbWFjaGluZT1pMzcwLWlibQorCQk7Owor
IyBJJ20gbm90IHN1cmUgd2hhdCAiU3lzdjMyIiBtZWFucy4gIFNob3VsZCB0aGlzIGJlIHN5c3Yz
LjI/CisJaSo4NnYzMikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni4q
Lzg2LXBjLydgCisJCW9zPS1zeXN2MzIKKwkJOzsKKwlpKjg2djQqKQorCQliYXNpY19tYWNoaW5l
PWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXN5c3Y0CisJCTs7CisJ
aSo4NnYpCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8n
YAorCQlvcz0tc3lzdgorCQk7OworCWkqODZzb2wyKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICQx
IHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXNvbGFyaXMyCisJCTs7CisJaTM4Nm1h
Y2gpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1tYWNoCisJCW9zPS1tYWNoCisJCTs7CisJaTM4Ni12
c3RhIHwgdnN0YSkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJb3M9LXZzdGEKKwkJ
OzsKKwlpcmlzIHwgaXJpczRkKQorCQliYXNpY19tYWNoaW5lPW1pcHMtc2dpCisJCWNhc2UgJG9z
IGluCisJCSAgICAtaXJpeCopCisJCQk7OworCQkgICAgKikKKwkJCW9zPS1pcml4NAorCQkJOzsK
KwkJZXNhYworCQk7OworCWlzaTY4IHwgaXNpKQorCQliYXNpY19tYWNoaW5lPW02OGstaXNpCisJ
CW9zPS1zeXN2CisJCTs7CisJbTY4a25vbW11KQorCQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93
bgorCQlvcz0tbGludXgKKwkJOzsKKwltNjhrbm9tbXUtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9zPS1saW51eAor
CQk7OworCW04OGstb21yb24qKQorCQliYXNpY19tYWNoaW5lPW04OGstb21yb24KKwkJOzsKKwlt
YWdudW0gfCBtMzIzMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLW1pcHMKKwkJb3M9LXN5c3YKKwkJ
OzsKKwltZXJsaW4pCisJCWJhc2ljX21hY2hpbmU9bnMzMmstdXRlaworCQlvcz0tc3lzdgorCQk7
OworCW1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9bWljcm9ibGF6ZS14aWxpbngKKwkJOzsK
KwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LW1pbmd3MzIKKwkJOzsK
KwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJtLXVua25vd24KKwkJb3M9LW1pbmd3MzJj
ZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtY29udmVyZ2VudAor
CQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlOVCB8ICpNaU5UWzAtOV0qKQorCQliYXNp
Y19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQKKwkJOzsKKwltaXBzMyotKikKKwkJYmFz
aWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAtZSAncy9taXBzMy9taXBzNjQv
J2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2ljX21hY2hpbmUg
fCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25vd24KKwkJOzsKKwltb25pdG9yKQorCQli
YXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJbW9ycGhvcykKKwkJ
YmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJb3M9LW1vcnBob3MKKwkJOzsKKwltc2Rv
cykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc2RvcworCQk7OworCW1zMS0qKQor
CQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkIC1lICdzL21zMS0vbXQt
LydgCisJCTs7CisJbXN5cykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc3lzCisJ
CTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCW9zPS1tdnMKKwkJOzsKKwlu
YWNsKQorCQliYXNpY19tYWNoaW5lPWxlMzItdW5rbm93bgorCQlvcz0tbmFjbAorCQk7OworCW5j
cjMwMDApCisJCWJhc2ljX21hY2hpbmU9aTQ4Ni1uY3IKKwkJb3M9LXN5c3Y0CisJCTs7CisJbmV0
YnNkMzg2KQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tbmV0YnNkCisJCTs7
CisJbmV0d2luZGVyKQorCQliYXNpY19tYWNoaW5lPWFybXY0bC1yZWJlbAorCQlvcz0tbGludXgK
KwkJOzsKKwluZXdzIHwgbmV3czcwMCB8IG5ld3M4MDAgfCBuZXdzOTAwKQorCQliYXNpY19tYWNo
aW5lPW02OGstc29ueQorCQlvcz0tbmV3c29zCisJCTs7CisJbmV3czEwMDApCisJCWJhc2ljX21h
Y2hpbmU9bTY4MDMwLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5ld3MtMzYwMCB8IHJpc2Mt
bmV3cykKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5l
Y3Y3MCkKKwkJYmFzaWNfbWFjaGluZT12NzAtbmVjCisJCW9zPS1zeXN2CisJCTs7CisJbmV4dCB8
IG0qLW5leHQgKQorCQliYXNpY19tYWNoaW5lPW02OGstbmV4dAorCQljYXNlICRvcyBpbgorCQkg
ICAgLW5leHRzdGVwKiApCisJCQk7OworCQkgICAgLW5zMiopCisJCSAgICAgIG9zPS1uZXh0c3Rl
cDIKKwkJCTs7CisJCSAgICAqKQorCQkgICAgICBvcz0tbmV4dHN0ZXAzCisJCQk7OworCQllc2Fj
CisJCTs7CisJbmgzMDAwKQorCQliYXNpY19tYWNoaW5lPW02OGstaGFycmlzCisJCW9zPS1jeHV4
CisJCTs7CisJbmhbNDVdMDAwKQorCQliYXNpY19tYWNoaW5lPW04OGstaGFycmlzCisJCW9zPS1j
eHV4CisJCTs7CisJbmluZHk5NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAorCQlvcz0t
bmluZHkKKwkJOzsKKwltb245NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAorCQlvcz0t
bW9uOTYwCisJCTs7CisJbm9uc3RvcHV4KQorCQliYXNpY19tYWNoaW5lPW1pcHMtY29tcGFxCisJ
CW9zPS1ub25zdG9wdXgKKwkJOzsKKwlucDEpCisJCWJhc2ljX21hY2hpbmU9bnAxLWdvdWxkCisJ
CTs7CisJbmVvLXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uZW8tdGFuZGVtCisJCTs7CisJbnNl
LXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uc2UtdGFuZGVtCisJCTs7CisJbnNyLXRhbmRlbSkK
KwkJYmFzaWNfbWFjaGluZT1uc3ItdGFuZGVtCisJCTs7CisJb3A1MG4tKiB8IG9wNjBjLSopCisJ
CWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJb3M9LXByb2VsZgorCQk7OworCW9wZW5yaXNj
IHwgb3BlbnJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1vcjMyLXVua25vd24KKwkJOzsKKwlvczQw
MCkKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWlibQorCQlvcz0tb3M0MDAKKwkJOzsKKwlPU0U2
ODAwMCB8IG9zZTY4MDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1lcmljc3NvbgorCQlvcz0t
b3NlCisJCTs7CisJb3M2OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ub25lCisJCW9zPS1vczY4
aworCQk7OworCXBhLWhpdGFjaGkpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRhY2hpCisJ
CW9zPS1oaXV4d2UyCisJCTs7CisJcGFyYWdvbikKKwkJYmFzaWNfbWFjaGluZT1pODYwLWludGVs
CisJCW9zPS1vc2YKKwkJOzsKKwlwYXJpc2MpCisJCWJhc2ljX21hY2hpbmU9aHBwYS11bmtub3du
CisJCW9zPS1saW51eAorCQk7OworCXBhcmlzYy0qKQorCQliYXNpY19tYWNoaW5lPWhwcGEtYGVj
aG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4CisJCTs7
CisJcGJkKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXR0aQorCQk7OworCXBiYikKKwkJYmFzaWNf
bWFjaGluZT1tNjhrLXR0aQorCQk7OworCXBjNTMyIHwgcGM1MzItKikKKwkJYmFzaWNfbWFjaGlu
ZT1uczMyay1wYzUzMgorCQk7OworCXBjOTgpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1wYworCQk7
OworCXBjOTgtKikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LWBlY2hvICRiYXNpY19tYWNoaW5lIHwg
c2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcGVudGl1bSB8IHA1IHwgazUgfCBrNiB8IG5leGdl
biB8IHZpYWMzKQorCQliYXNpY19tYWNoaW5lPWk1ODYtcGMKKwkJOzsKKwlwZW50aXVtcHJvIHwg
cDYgfCA2eDg2IHwgYXRobG9uIHwgYXRobG9uXyopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1wYwor
CQk7OworCXBlbnRpdW1paSB8IHBlbnRpdW0yIHwgcGVudGl1bWlpaSB8IHBlbnRpdW0zKQorCQli
YXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlwZW50aXVtNCkKKwkJYmFzaWNfbWFjaGluZT1p
Nzg2LXBjCisJCTs7CisJcGVudGl1bS0qIHwgcDUtKiB8IGs1LSogfCBrNi0qIHwgbmV4Z2VuLSog
fCB2aWFjMy0qKQorCQliYXNpY19tYWNoaW5lPWk1ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBz
ZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtcHJvLSogfCBwNi0qIHwgNng4Ni0qIHwg
YXRobG9uLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNl
ZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW1paS0qIHwgcGVudGl1bTItKiB8IHBlbnRp
dW1paWktKiB8IHBlbnRpdW0zLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAkYmFzaWNf
bWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW00LSopCisJCWJhc2lj
X21hY2hpbmU9aTc4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAor
CQk7OworCXBuKQorCQliYXNpY19tYWNoaW5lPXBuLWdvdWxkCisJCTs7CisJcG93ZXIpCWJhc2lj
X21hY2hpbmU9cG93ZXItaWJtCisJCTs7CisJcHBjIHwgcHBjYmUpCWJhc2ljX21hY2hpbmU9cG93
ZXJwYy11bmtub3duCisJCTs7CisJcHBjLSogfCBwcGNiZS0qKQorCQliYXNpY19tYWNoaW5lPXBv
d2VycGMtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlw
cGNsZSB8IHBvd2VycGNsaXR0bGUgfCBwcGMtbGUgfCBwb3dlcnBjLWxpdHRsZSkKKwkJYmFzaWNf
bWFjaGluZT1wb3dlcnBjbGUtdW5rbm93bgorCQk7OworCXBwY2xlLSogfCBwb3dlcnBjbGl0dGxl
LSopCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2Vk
ICdzL15bXi1dKi0vLydgCisJCTs7CisJcHBjNjQpCWJhc2ljX21hY2hpbmU9cG93ZXJwYzY0LXVu
a25vd24KKwkJOzsKKwlwcGM2NC0qKSBiYXNpY19tYWNoaW5lPXBvd2VycGM2NC1gZWNobyAkYmFz
aWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0bGUgfCBwb3dlcnBj
NjRsaXR0bGUgfCBwcGM2NC1sZSB8IHBvd2VycGM2NC1saXR0bGUpCisJCWJhc2ljX21hY2hpbmU9
cG93ZXJwYzY0bGUtdW5rbm93bgorCQk7OworCXBwYzY0bGUtKiB8IHBvd2VycGM2NGxpdHRsZS0q
KQorCQliYXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2Vk
ICdzL15bXi1dKi0vLydgCisJCTs7CisJcHMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtaWJtCisJ
CTs7CisJcHczMikKKwkJYmFzaWNfbWFjaGluZT1pNTg2LXVua25vd24KKwkJb3M9LXB3MzIKKwkJ
OzsKKwlyZG9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LXJkb3MKKwkJOzsKKwly
b202OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1yb202OGsKKwkJb3M9LWNvZmYKKwkJOzsKKwly
bVs0Nl0wMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNpZW1lbnMKKwkJOzsKKwlydHBjIHwgcnRw
Yy0qKQorCQliYXNpY19tYWNoaW5lPXJvbXAtaWJtCisJCTs7CisJczM5MCB8IHMzOTAtKikKKwkJ
YmFzaWNfbWFjaGluZT1zMzkwLWlibQorCQk7OworCXMzOTB4IHwgczM5MHgtKikKKwkJYmFzaWNf
bWFjaGluZT1zMzkweC1pYm0KKwkJOzsKKwlzYTI5MjAwKQorCQliYXNpY19tYWNoaW5lPWEyOWst
YW1kCisJCW9zPS11ZGkKKwkJOzsKKwlzYjEpCisJCWJhc2ljX21hY2hpbmU9bWlwc2lzYTY0c2Ix
LXVua25vd24KKwkJOzsKKwlzYjFlbCkKKwkJYmFzaWNfbWFjaGluZT1taXBzaXNhNjRzYjFlbC11
bmtub3duCisJCTs7CisJc2RlKQorCQliYXNpY19tYWNoaW5lPW1pcHNpc2EzMi1zZGUKKwkJb3M9
LWVsZgorCQk7OworCXNlaSkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNlaQorCQlvcz0tc2VpdXgK
KwkJOzsKKwlzZXF1ZW50KQorCQliYXNpY19tYWNoaW5lPWkzODYtc2VxdWVudAorCQk7OworCXNo
KQorCQliYXNpY19tYWNoaW5lPXNoLWhpdGFjaGkKKwkJb3M9LWhtcworCQk7OworCXNoNWVsKQor
CQliYXNpY19tYWNoaW5lPXNoNWxlLXVua25vd24KKwkJOzsKKwlzaDY0KQorCQliYXNpY19tYWNo
aW5lPXNoNjQtdW5rbm93bgorCQk7OworCXNwYXJjbGl0ZS13cnMgfCBzaW1zby13cnMpCisJCWJh
c2ljX21hY2hpbmU9c3BhcmNsaXRlLXdycworCQlvcz0tdnh3b3JrcworCQk7OworCXNwczcpCisJ
CWJhc2ljX21hY2hpbmU9bTY4ay1idWxsCisJCW9zPS1zeXN2MgorCQk7OworCXNwdXIpCisJCWJh
c2ljX21hY2hpbmU9c3B1ci11bmtub3duCisJCTs7CisJc3QyMDAwKQorCQliYXNpY19tYWNoaW5l
PW02OGstdGFuZGVtCisJCTs7CisJc3RyYXR1cykKKwkJYmFzaWNfbWFjaGluZT1pODYwLXN0cmF0
dXMKKwkJb3M9LXN5c3Y0CisJCTs7CisJc3Ryb25nYXJtLSogfCB0aHVtYi0qKQorCQliYXNpY19t
YWNoaW5lPWFybS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7
OworCXN1bjIpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJvczMpCisJ
CWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuMm9zNCkK
KwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW4zb3Mz
KQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlzdW4zb3M0
KQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW40b3Mz
KQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuNG9z
NCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7OworCXN1bjRz
b2wyKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlz
dW4zIHwgc3VuMy0qKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCTs7CisJc3VuNCkKKwkJ
YmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwgcm9hZHJ1
bm5lcikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFzaWNfbWFj
aGluZT1zdjEtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJhc2ljX21h
Y2hpbmU9aTM4Ni1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCXQzZSkKKwkJYmFzaWNfbWFj
aGluZT1hbHBoYWV2NS1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJhc2ljX21h
Y2hpbmU9dDkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworCXRpbGUqKQorCQliYXNpY19tYWNo
aW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9LWxpbnV4LWdudQorCQk7OworCXR4Mzkp
CisJCWJhc2ljX21hY2hpbmU9bWlwc3R4MzktdW5rbm93bgorCQk7OworCXR4MzllbCkKKwkJYmFz
aWNfbWFjaGluZT1taXBzdHgzOWVsLXVua25vd24KKwkJOzsKKwl0b2FkMSkKKwkJYmFzaWNfbWFj
aGluZT1wZHAxMC14a2wKKwkJb3M9LXRvcHMyMAorCQk7OworCXRvd2VyIHwgdG93ZXItMzIpCisJ
CWJhc2ljX21hY2hpbmU9bTY4ay1uY3IKKwkJOzsKKwl0cGYpCisJCWJhc2ljX21hY2hpbmU9czM5
MHgtaWJtCisJCW9zPS10cGYKKwkJOzsKKwl1ZGkyOWspCisJCWJhc2ljX21hY2hpbmU9YTI5ay1h
bWQKKwkJb3M9LXVkaQorCQk7OworCXVsdHJhMykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLW55dQor
CQlvcz0tc3ltMQorCQk7OworCXY4MTAgfCBuZWN2ODEwKQorCQliYXNpY19tYWNoaW5lPXY4MTAt
bmVjCisJCW9zPS1ub25lCisJCTs7CisJdmF4dikKKwkJYmFzaWNfbWFjaGluZT12YXgtZGVjCisJ
CW9zPS1zeXN2CisJCTs7CisJdm1zKQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJb3M9LXZt
cworCQk7OworCXZwcCp8dnh8dngtKikKKwkJYmFzaWNfbWFjaGluZT1mMzAxLWZ1aml0c3UKKwkJ
OzsKKwl2eHdvcmtzOTYwKQorCQliYXNpY19tYWNoaW5lPWk5NjAtd3JzCisJCW9zPS12eHdvcmtz
CisJCTs7CisJdnh3b3JrczY4KQorCQliYXNpY19tYWNoaW5lPW02OGstd3JzCisJCW9zPS12eHdv
cmtzCisJCTs7CisJdnh3b3JrczI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLXdycworCQlvcz0t
dnh3b3JrcworCQk7OworCXc2NSopCisJCWJhc2ljX21hY2hpbmU9dzY1LXdkYworCQlvcz0tbm9u
ZQorCQk7OworCXc4OWstKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLXdpbmJvbmQKKwkJb3M9
LXByb2VsZgorCQk7OworCXhib3gpCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1wYworCQlvcz0tbWlu
Z3czMgorCQk7OworCXhwcyB8IHhwczEwMCkKKwkJYmFzaWNfbWFjaGluZT14cHMxMDAtaG9uZXl3
ZWxsCisJCTs7CisJeHNjYWxlLSogfCB4c2NhbGVlW2JsXS0qKQorCQliYXNpY19tYWNoaW5lPWBl
Y2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL154c2NhbGUvYXJtLydgCisJCTs7CisJeW1wKQor
CQliYXNpY19tYWNoaW5lPXltcC1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl6OGstKi1jb2Zm
KQorCQliYXNpY19tYWNoaW5lPXo4ay11bmtub3duCisJCW9zPS1zaW0KKwkJOzsKKwl6ODAtKi1j
b2ZmKQorCQliYXNpY19tYWNoaW5lPXo4MC11bmtub3duCisJCW9zPS1zaW0KKwkJOzsKKwlub25l
KQorCQliYXNpY19tYWNoaW5lPW5vbmUtbm9uZQorCQlvcz0tbm9uZQorCQk7OworCisjIEhlcmUg
d2UgaGFuZGxlIHRoZSBkZWZhdWx0IG1hbnVmYWN0dXJlciBvZiBjZXJ0YWluIENQVSB0eXBlcy4g
IEl0IGlzIGluCisjIHNvbWUgY2FzZXMgdGhlIG9ubHkgbWFudWZhY3R1cmVyLCBpbiBvdGhlcnMs
IGl0IGlzIHRoZSBtb3N0IHBvcHVsYXIuCisJdzg5aykKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4x
LXdpbmJvbmQKKwkJOzsKKwlvcDUwbikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLW9raQorCQk7
OworCW9wNjBjKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtb2tpCisJCTs7CisJcm9tcCkKKwkJ
YmFzaWNfbWFjaGluZT1yb21wLWlibQorCQk7OworCW1taXgpCisJCWJhc2ljX21hY2hpbmU9bW1p
eC1rbnV0aAorCQk7OworCXJzNjAwMCkKKwkJYmFzaWNfbWFjaGluZT1yczYwMDAtaWJtCisJCTs7
CisJdmF4KQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJOzsKKwlwZHAxMCkKKwkJIyB0aGVy
ZSBhcmUgbWFueSBjbG9uZXMsIHNvIERFQyBpcyBub3QgYSBzYWZlIGJldAorCQliYXNpY19tYWNo
aW5lPXBkcDEwLXVua25vd24KKwkJOzsKKwlwZHAxMSkKKwkJYmFzaWNfbWFjaGluZT1wZHAxMS1k
ZWMKKwkJOzsKKwl3ZTMyaykKKwkJYmFzaWNfbWFjaGluZT13ZTMyay1hdHQKKwkJOzsKKwlzaFsx
MjM0XSB8IHNoWzI0XWEgfCBzaFsyNF1hZWIgfCBzaFszNF1lYiB8IHNoWzEyMzRdbGUgfCBzaFsy
M11lbGUpCisJCWJhc2ljX21hY2hpbmU9c2gtdW5rbm93bgorCQk7OworCXNwYXJjIHwgc3BhcmN2
OCB8IHNwYXJjdjkgfCBzcGFyY3Y5YiB8IHNwYXJjdjl2KQorCQliYXNpY19tYWNoaW5lPXNwYXJj
LXN1bgorCQk7OworCWN5ZHJhKQorCQliYXNpY19tYWNoaW5lPWN5ZHJhLWN5ZHJvbWUKKwkJOzsK
KwlvcmlvbikKKwkJYmFzaWNfbWFjaGluZT1vcmlvbi1oaWdobGV2ZWwKKwkJOzsKKwlvcmlvbjEw
NSkKKwkJYmFzaWNfbWFjaGluZT1jbGlwcGVyLWhpZ2hsZXZlbAorCQk7OworCW1hYyB8IG1wdyB8
IG1hYy1tcHcpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQk7OworCXBtYWMgfCBwbWFj
LW1wdykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWFwcGxlCisJCTs7CisJKi11bmtub3duKQor
CQkjIE1ha2Ugc3VyZSB0byBtYXRjaCBhbiBhbHJlYWR5LWNhbm9uaWNhbGl6ZWQgbWFjaGluZSBu
YW1lLgorCQk7OworCSopCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFcJzogbWFj
aGluZSBcYCRiYXNpY19tYWNoaW5lXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJ
OzsKK2VzYWMKKworIyBIZXJlIHdlIGNhbm9uaWNhbGl6ZSBjZXJ0YWluIGFsaWFzZXMgZm9yIG1h
bnVmYWN0dXJlcnMuCitjYXNlICRiYXNpY19tYWNoaW5lIGluCisJKi1kaWdpdGFsKikKKwkJYmFz
aWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9kaWdpdGFsLiovZGVjLydg
CisJCTs7CisJKi1jb21tb2RvcmUqKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNo
aW5lIHwgc2VkICdzL2NvbW1vZG9yZS4qL2NibS8nYAorCQk7OworCSopCisJCTs7Citlc2FjCisK
KyMgRGVjb2RlIG1hbnVmYWN0dXJlci1zcGVjaWZpYyBhbGlhc2VzIGZvciBjZXJ0YWluIG9wZXJh
dGluZyBzeXN0ZW1zLgorCitpZiBbIHgiJG9zIiAhPSB4IiIgXQordGhlbgorY2FzZSAkb3MgaW4K
KwkjIEZpcnN0IG1hdGNoIHNvbWUgc3lzdGVtIHR5cGUgYWxpYXNlcworCSMgdGhhdCBtaWdodCBn
ZXQgY29uZnVzZWQgd2l0aCB2YWxpZCBzeXN0ZW0gdHlwZXMuCisJIyAtc29sYXJpcyogaXMgYSBi
YXNpYyBzeXN0ZW0gdHlwZSwgd2l0aCB0aGlzIG9uZSBleGNlcHRpb24uCisJLWF1cm9yYXV4KQor
CQlvcz0tYXVyb3JhdXgKKwkJOzsKKwktc29sYXJpczEgfCAtc29sYXJpczEuKikKKwkJb3M9YGVj
aG8gJG9zIHwgc2VkIC1lICdzfHNvbGFyaXMxfHN1bm9zNHwnYAorCQk7OworCS1zb2xhcmlzKQor
CQlvcz0tc29sYXJpczIKKwkJOzsKKwktc3ZyNCopCisJCW9zPS1zeXN2NAorCQk7OworCS11bml4
d2FyZSopCisJCW9zPS1zeXN2NC4ydXcKKwkJOzsKKwktZ251L2xpbnV4KikKKwkJb3M9YGVjaG8g
JG9zIHwgc2VkIC1lICdzfGdudS9saW51eHxsaW51eC1nbnV8J2AKKwkJOzsKKwkjIEZpcnN0IGFj
Y2VwdCB0aGUgYmFzaWMgc3lzdGVtIHR5cGVzLgorCSMgVGhlIHBvcnRhYmxlIHN5c3RlbXMgY29t
ZXMgZmlyc3QuCisJIyBFYWNoIGFsdGVybmF0aXZlIE1VU1QgRU5EIElOIEEgKiwgdG8gbWF0Y2gg
YSB2ZXJzaW9uIG51bWJlci4KKwkjIC1zeXN2KiBpcyBub3QgaGVyZSBiZWNhdXNlIGl0IGNvbWVz
IGxhdGVyLCBhZnRlciBzeXN2cjQuCisJLWdudSogfCAtYnNkKiB8IC1tYWNoKiB8IC1taW5peCog
fCAtZ2VuaXgqIHwgLXVsdHJpeCogfCAtaXJpeCogXAorCSAgICAgIHwgLSp2bXMqIHwgLXNjbyog
fCAtZXNpeCogfCAtaXNjKiB8IC1haXgqIHwgLWNuayogfCAtc3Vub3MgfCAtc3Vub3NbMzRdKlwK
KwkgICAgICB8IC1ocHV4KiB8IC11bm9zKiB8IC1vc2YqIHwgLWx1bmEqIHwgLWRndXgqIHwgLWF1
cm9yYXV4KiB8IC1zb2xhcmlzKiBcCisJICAgICAgfCAtc3ltKiB8IC1rb3BlbnNvbGFyaXMqIFwK
KwkgICAgICB8IC1hbWlnYW9zKiB8IC1hbWlnYWRvcyogfCAtbXNkb3MqIHwgLW5ld3NvcyogfCAt
dW5pY29zKiB8IC1hb2YqIFwKKwkgICAgICB8IC1hb3MqIHwgLWFyb3MqIFwKKwkgICAgICB8IC1u
aW5keSogfCAtdnhzaW0qIHwgLXZ4d29ya3MqIHwgLWVibW9uKiB8IC1obXMqIHwgLW12cyogXAor
CSAgICAgIHwgLWNsaXgqIHwgLXJpc2NvcyogfCAtdW5pcGx1cyogfCAtaXJpcyogfCAtcnR1KiB8
IC14ZW5peCogXAorCSAgICAgIHwgLWhpdXgqIHwgLTM4NmJzZCogfCAta25ldGJzZCogfCAtbWly
YnNkKiB8IC1uZXRic2QqIFwKKwkgICAgICB8IC1vcGVuYnNkKiB8IC1zb2xpZGJzZCogXAorCSAg
ICAgIHwgLWVra29ic2QqIHwgLWtmcmVlYnNkKiB8IC1mcmVlYnNkKiB8IC1yaXNjaXgqIHwgLWx5
bnhvcyogXAorCSAgICAgIHwgLWJvc3gqIHwgLW5leHRzdGVwKiB8IC1jeHV4KiB8IC1hb3V0KiB8
IC1lbGYqIHwgLW9hYmkqIFwKKwkgICAgICB8IC1wdHgqIHwgLWNvZmYqIHwgLWVjb2ZmKiB8IC13
aW5udCogfCAtZG9tYWluKiB8IC12c3RhKiBcCisJICAgICAgfCAtdWRpKiB8IC1lYWJpKiB8IC1s
aXRlcyogfCAtaWVlZSogfCAtZ28zMiogfCAtYXV4KiBcCisJICAgICAgfCAtY2hvcnVzb3MqIHwg
LWNob3J1c3JkYiogfCAtY2VnY2MqIFwKKwkgICAgICB8IC1jeWd3aW4qIHwgLW1zeXMqIHwgLXBl
KiB8IC1wc29zKiB8IC1tb3NzKiB8IC1wcm9lbGYqIHwgLXJ0ZW1zKiBcCisJICAgICAgfCAtbWlu
Z3czMiogfCAtbGludXgtZ251KiB8IC1saW51eC1hbmRyb2lkKiBcCisJICAgICAgfCAtbGludXgt
bmV3bGliKiB8IC1saW51eC11Y2xpYmMqIFwKKwkgICAgICB8IC11eHB2KiB8IC1iZW9zKiB8IC1t
cGVpeCogfCAtdWRrKiBcCisJICAgICAgfCAtaW50ZXJpeCogfCAtdXdpbiogfCAtbWtzKiB8IC1y
aGFwc29keSogfCAtZGFyd2luKiB8IC1vcGVuZWQqIFwKKwkgICAgICB8IC1vcGVuc3RlcCogfCAt
b3NraXQqIHwgLWNvbml4KiB8IC1wdzMyKiB8IC1ub25zdG9wdXgqIFwKKwkgICAgICB8IC1zdG9y
bS1jaGFvcyogfCAtdG9wczEwKiB8IC10ZW5leCogfCAtdG9wczIwKiB8IC1pdHMqIFwKKwkgICAg
ICB8IC1vczIqIHwgLXZvcyogfCAtcGFsbW9zKiB8IC11Y2xpbnV4KiB8IC1udWNsZXVzKiBcCisJ
ICAgICAgfCAtbW9ycGhvcyogfCAtc3VwZXJ1eCogfCAtcnRtayogfCAtcnRtay1ub3ZhKiB8IC13
aW5kaXNzKiBcCisJICAgICAgfCAtcG93ZXJtYXgqIHwgLWRuaXgqIHwgLW54NiB8IC1ueDcgfCAt
c2VpKiB8IC1kcmFnb25mbHkqIFwKKwkgICAgICB8IC1za3lvcyogfCAtaGFpa3UqIHwgLXJkb3Mq
IHwgLXRvcHBlcnMqIHwgLWRyb3BzKiB8IC1lcyopCisJIyBSZW1lbWJlciwgZWFjaCBhbHRlcm5h
dGl2ZSBNVVNUIEVORCBJTiAqLCB0byBtYXRjaCBhIHZlcnNpb24gbnVtYmVyLgorCQk7OworCS1x
bngqKQorCQljYXNlICRiYXNpY19tYWNoaW5lIGluCisJCSAgICB4ODYtKiB8IGkqODYtKikKKwkJ
CTs7CisJCSAgICAqKQorCQkJb3M9LW50byRvcworCQkJOzsKKwkJZXNhYworCQk7OworCS1udG8t
cW54KikKKwkJOzsKKwktbnRvKikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfG50b3xudG8t
cW54fCdgCisJCTs7CisJLXNpbSB8IC1lczE4MDAqIHwgLWhtcyogfCAteHJheSB8IC1vczY4ayog
fCAtbm9uZSogfCAtdjg4ciogXAorCSAgICAgIHwgLXdpbmRvd3MqIHwgLW9zeCB8IC1hYnVnIHwg
LW5ldHdhcmUqIHwgLW9zOSogfCAtYmVvcyogfCAtaGFpa3UqIFwKKwkgICAgICB8IC1tYWNvcyog
fCAtbXB3KiB8IC1tYWdpYyogfCAtbW1peHdhcmUqIHwgLW1vbjk2MCogfCAtbG5ld3MqKQorCQk7
OworCS1tYWMqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bWFjfG1hY29zfCdgCisJCTs7
CisJLWxpbnV4LWRpZXRsaWJjKQorCQlvcz0tbGludXgtZGlldGxpYmMKKwkJOzsKKwktbGludXgq
KQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bGludXh8bGludXgtZ251fCdgCisJCTs7CisJ
LXN1bm9zNSopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzdW5vczV8c29sYXJpczJ8J2AK
KwkJOzsKKwktc3Vub3M2KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHN1bm9zNnxzb2xh
cmlzM3wnYAorCQk7OworCS1vcGVuZWQqKQorCQlvcz0tb3BlbmVkaXRpb24KKwkJOzsKKwktb3M0
MDAqKQorCQlvcz0tb3M0MDAKKwkJOzsKKwktd2luY2UqKQorCQlvcz0td2luY2UKKwkJOzsKKwkt
b3Nmcm9zZSopCisJCW9zPS1vc2Zyb3NlCisJCTs7CisJLW9zZiopCisJCW9zPS1vc2YKKwkJOzsK
KwktdXRlayopCisJCW9zPS1ic2QKKwkJOzsKKwktZHluaXgqKQorCQlvcz0tYnNkCisJCTs7CisJ
LWFjaXMqKQorCQlvcz0tYW9zCisJCTs7CisJLWF0aGVvcyopCisJCW9zPS1hdGhlb3MKKwkJOzsK
Kwktc3lsbGFibGUqKQorCQlvcz0tc3lsbGFibGUKKwkJOzsKKwktMzg2YnNkKQorCQlvcz0tYnNk
CisJCTs7CisJLWN0aXgqIHwgLXV0cyopCisJCW9zPS1zeXN2CisJCTs7CisJLW5vdmEqKQorCQlv
cz0tcnRtay1ub3ZhCisJCTs7CisJLW5zMiApCisJCW9zPS1uZXh0c3RlcDIKKwkJOzsKKwktbnNr
KikKKwkJb3M9LW5zaworCQk7OworCSMgUHJlc2VydmUgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHNp
bml4NS4KKwktc2luaXg1LiopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzaW5peHxzeXN2
fCdgCisJCTs7CisJLXNpbml4KikKKwkJb3M9LXN5c3Y0CisJCTs7CisJLXRwZiopCisJCW9zPS10
cGYKKwkJOzsKKwktdHJpdG9uKikKKwkJb3M9LXN5c3YzCisJCTs7CisJLW9zcyopCisJCW9zPS1z
eXN2MworCQk7OworCS1zdnI0KQorCQlvcz0tc3lzdjQKKwkJOzsKKwktc3ZyMykKKwkJb3M9LXN5
c3YzCisJCTs7CisJLXN5c3ZyNCkKKwkJb3M9LXN5c3Y0CisJCTs7CisJIyBUaGlzIG11c3QgY29t
ZSBhZnRlciAtc3lzdnI0LgorCS1zeXN2KikKKwkJOzsKKwktb3NlKikKKwkJb3M9LW9zZQorCQk7
OworCS1lczE4MDAqKQorCQlvcz0tb3NlCisJCTs7CisJLXhlbml4KQorCQlvcz0teGVuaXgKKwkJ
OzsKKwktKm1pbnQgfCAtbWludFswLTldKiB8IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQorCQlvcz0t
bWludAorCQk7OworCS1hcm9zKikKKwkJb3M9LWFyb3MKKwkJOzsKKwkta2FvcyopCisJCW9zPS1r
YW9zCisJCTs7CisJLXp2bW9lKQorCQlvcz0tenZtb2UKKwkJOzsKKwktZGljb3MqKQorCQlvcz0t
ZGljb3MKKwkJOzsKKwktbmFjbCopCisJCTs7CisJLW5vbmUpCisJCTs7CisJKikKKwkJIyBHZXQg
cmlkIG9mIHRoZSBgLScgYXQgdGhlIGJlZ2lubmluZyBvZiAkb3MuCisJCW9zPWBlY2hvICRvcyB8
IHNlZCAncy9bXi1dKi0vLydgCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFcJzog
c3lzdGVtIFxgJG9zXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJOzsKK2VzYWMK
K2Vsc2UKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVtcyB0
aGF0IGNvbWUgd2l0aCB2YXJpb3VzIG1hY2hpbmVzLgorIyBUaGUgdmFsdWUgc2hvdWxkIGJlIHdo
YXQgdGhlIHZlbmRvciBjdXJyZW50bHkgc2hpcHMgb3V0IHRoZSBkb29yIHdpdGggdGhlaXIKKyMg
bWFjaGluZSBvciBwdXQgYW5vdGhlciB3YXksIHRoZSBtb3N0IHBvcHVsYXIgb3MgcHJvdmlkZWQg
d2l0aCB0aGUgbWFjaGluZS4KKworIyBOb3RlIHRoYXQgaWYgeW91J3JlIGdvaW5nIHRvIHRyeSB0
byBtYXRjaCAiLU1BTlVGQUNUVVJFUiIgaGVyZSAoc2F5LAorIyAiLXN1biIpLCB0aGVuIHlvdSBo
YXZlIHRvIHRlbGwgdGhlIGNhc2Ugc3RhdGVtZW50IHVwIHRvd2FyZHMgdGhlIHRvcAorIyB0aGF0
IE1BTlVGQUNUVVJFUiBpc24ndCBhbiBvcGVyYXRpbmcgc3lzdGVtLiAgT3RoZXJ3aXNlLCBjb2Rl
IGFib3ZlCisjIHdpbGwgc2lnbmFsIGFuIGVycm9yIHNheWluZyB0aGF0IE1BTlVGQUNUVVJFUiBp
c24ndCBhbiBvcGVyYXRpbmcKKyMgc3lzdGVtLCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IHRvIHRoaXMg
cG9pbnQuCisKK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwlzY29yZS0qKQorCQlvcz0tZWxmCisJ
CTs7CisJc3B1LSopCisJCW9zPS1lbGYKKwkJOzsKKwkqLWFjb3JuKQorCQlvcz0tcmlzY2l4MS4y
CisJCTs7CisJYXJtKi1yZWJlbCkKKwkJb3M9LWxpbnV4CisJCTs7CisJYXJtKi1zZW1pKQorCQlv
cz0tYW91dAorCQk7OworCWM0eC0qIHwgdGljNHgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM1
NHgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM1NXgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0
aWM2eC0qKQorCQlvcz0tY29mZgorCQk7OworCSMgVGhpcyBtdXN0IGNvbWUgYmVmb3JlIHRoZSAq
LWRlYyBlbnRyeS4KKwlwZHAxMC0qKQorCQlvcz0tdG9wczIwCisJCTs7CisJcGRwMTEtKikKKwkJ
b3M9LW5vbmUKKwkJOzsKKwkqLWRlYyB8IHZheC0qKQorCQlvcz0tdWx0cml4NC4yCisJCTs7CisJ
bTY4Ki1hcG9sbG8pCisJCW9zPS1kb21haW4KKwkJOzsKKwlpMzg2LXN1bikKKwkJb3M9LXN1bm9z
NC4wLjIKKwkJOzsKKwltNjgwMDAtc3VuKQorCQlvcz0tc3Vub3MzCisJCSMgVGhpcyBhbHNvIGV4
aXN0cyBpbiB0aGUgY29uZmlndXJlIHByb2dyYW0sIGJ1dCB3YXMgbm90IHRoZQorCQkjIGRlZmF1
bHQuCisJCSMgb3M9LXN1bm9zNAorCQk7OworCW02OCotY2lzY28pCisJCW9zPS1hb3V0CisJCTs7
CisJbWVwLSopCisJCW9zPS1lbGYKKwkJOzsKKwltaXBzKi1jaXNjbykKKwkJb3M9LWVsZgorCQk7
OworCW1pcHMqLSopCisJCW9zPS1lbGYKKwkJOzsKKwlvcjMyLSopCisJCW9zPS1jb2ZmCisJCTs7
CisJKi10dGkpCSMgbXVzdCBiZSBiZWZvcmUgc3BhcmMgZW50cnkgb3Igd2UgZ2V0IHRoZSB3cm9u
ZyBvcy4KKwkJb3M9LXN5c3YzCisJCTs7CisJc3BhcmMtKiB8ICotc3VuKQorCQlvcz0tc3Vub3M0
LjEuMQorCQk7OworCSotYmUpCisJCW9zPS1iZW9zCisJCTs7CisJKi1oYWlrdSkKKwkJb3M9LWhh
aWt1CisJCTs7CisJKi1pYm0pCisJCW9zPS1haXgKKwkJOzsKKwkqLWtudXRoKQorCQlvcz0tbW1p
eHdhcmUKKwkJOzsKKwkqLXdlYykKKwkJb3M9LXByb2VsZgorCQk7OworCSotd2luYm9uZCkKKwkJ
b3M9LXByb2VsZgorCQk7OworCSotb2tpKQorCQlvcz0tcHJvZWxmCisJCTs7CisJKi1ocCkKKwkJ
b3M9LWhwdXgKKwkJOzsKKwkqLWhpdGFjaGkpCisJCW9zPS1oaXV4CisJCTs7CisJaTg2MC0qIHwg
Ki1hdHQgfCAqLW5jciB8ICotYWx0b3MgfCAqLW1vdG9yb2xhIHwgKi1jb252ZXJnZW50KQorCQlv
cz0tc3lzdgorCQk7OworCSotY2JtKQorCQlvcz0tYW1pZ2FvcworCQk7OworCSotZGcpCisJCW9z
PS1kZ3V4CisJCTs7CisJKi1kb2xwaGluKQorCQlvcz0tc3lzdjMKKwkJOzsKKwltNjhrLWNjdXIp
CisJCW9zPS1ydHUKKwkJOzsKKwltODhrLW9tcm9uKikKKwkJb3M9LWx1bmEKKwkJOzsKKwkqLW5l
eHQgKQorCQlvcz0tbmV4dHN0ZXAKKwkJOzsKKwkqLXNlcXVlbnQpCisJCW9zPS1wdHgKKwkJOzsK
KwkqLWNyZHMpCisJCW9zPS11bm9zCisJCTs7CisJKi1ucykKKwkJb3M9LWdlbml4CisJCTs7CisJ
aTM3MC0qKQorCQlvcz0tbXZzCisJCTs7CisJKi1uZXh0KQorCQlvcz0tbmV4dHN0ZXAzCisJCTs7
CisJKi1nb3VsZCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWhpZ2hsZXZlbCkKKwkJb3M9LWJzZAor
CQk7OworCSotZW5jb3JlKQorCQlvcz0tYnNkCisJCTs7CisJKi1zZ2kpCisJCW9zPS1pcml4CisJ
CTs7CisJKi1zaWVtZW5zKQorCQlvcz0tc3lzdjQKKwkJOzsKKwkqLW1hc3Njb21wKQorCQlvcz0t
cnR1CisJCTs7CisJZjMwWzAxXS1mdWppdHN1IHwgZjcwMC1mdWppdHN1KQorCQlvcz0tdXhwdgor
CQk7OworCSotcm9tNjhrKQorCQlvcz0tY29mZgorCQk7OworCSotKmJ1ZykKKwkJb3M9LWNvZmYK
KwkJOzsKKwkqLWFwcGxlKQorCQlvcz0tbWFjb3MKKwkJOzsKKwkqLWF0YXJpKikKKwkJb3M9LW1p
bnQKKwkJOzsKKwkqKQorCQlvcz0tbm9uZQorCQk7OworZXNhYworZmkKKworIyBIZXJlIHdlIGhh
bmRsZSB0aGUgY2FzZSB3aGVyZSB3ZSBrbm93IHRoZSBvcywgYW5kIHRoZSBDUFUgdHlwZSwgYnV0
IG5vdCB0aGUKKyMgbWFudWZhY3R1cmVyLiAgV2UgcGljayB0aGUgbG9naWNhbCBtYW51ZmFjdHVy
ZXIuCit2ZW5kb3I9dW5rbm93bgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSotdW5rbm93bikK
KwkJY2FzZSAkb3MgaW4KKwkJCS1yaXNjaXgqKQorCQkJCXZlbmRvcj1hY29ybgorCQkJCTs7CisJ
CQktc3Vub3MqKQorCQkJCXZlbmRvcj1zdW4KKwkJCQk7OworCQkJLWNuayp8LWFpeCopCisJCQkJ
dmVuZG9yPWlibQorCQkJCTs7CisJCQktYmVvcyopCisJCQkJdmVuZG9yPWJlCisJCQkJOzsKKwkJ
CS1ocHV4KikKKwkJCQl2ZW5kb3I9aHAKKwkJCQk7OworCQkJLW1wZWl4KikKKwkJCQl2ZW5kb3I9
aHAKKwkJCQk7OworCQkJLWhpdXgqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsKKwkJCS11
bm9zKikKKwkJCQl2ZW5kb3I9Y3JkcworCQkJCTs7CisJCQktZGd1eCopCisJCQkJdmVuZG9yPWRn
CisJCQkJOzsKKwkJCS1sdW5hKikKKwkJCQl2ZW5kb3I9b21yb24KKwkJCQk7OworCQkJLWdlbml4
KikKKwkJCQl2ZW5kb3I9bnMKKwkJCQk7OworCQkJLW12cyogfCAtb3BlbmVkKikKKwkJCQl2ZW5k
b3I9aWJtCisJCQkJOzsKKwkJCS1vczQwMCopCisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQkt
cHR4KikKKwkJCQl2ZW5kb3I9c2VxdWVudAorCQkJCTs7CisJCQktdHBmKikKKwkJCQl2ZW5kb3I9
aWJtCisJCQkJOzsKKwkJCS12eHNpbSogfCAtdnh3b3JrcyogfCAtd2luZGlzcyopCisJCQkJdmVu
ZG9yPXdycworCQkJCTs7CisJCQktYXV4KikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7OworCQkJ
LWhtcyopCisJCQkJdmVuZG9yPWhpdGFjaGkKKwkJCQk7OworCQkJLW1wdyogfCAtbWFjb3MqKQor
CQkJCXZlbmRvcj1hcHBsZQorCQkJCTs7CisJCQktKm1pbnQgfCAtbWludFswLTldKiB8IC0qTWlO
VCB8IC1NaU5UWzAtOV0qKQorCQkJCXZlbmRvcj1hdGFyaQorCQkJCTs7CisJCQktdm9zKikKKwkJ
CQl2ZW5kb3I9c3RyYXR1cworCQkJCTs7CisJCWVzYWMKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAk
YmFzaWNfbWFjaGluZSB8IHNlZCAicy91bmtub3duLyR2ZW5kb3IvImAKKwkJOzsKK2VzYWMKKwor
ZWNobyAkYmFzaWNfbWFjaGluZSRvcworZXhpdAorCisjIExvY2FsIHZhcmlhYmxlczoKKyMgZXZh
bDogKGFkZC1ob29rICd3cml0ZS1maWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1lLXN0YW1w
LXN0YXJ0OiAidGltZXN0YW1wPSciCisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0tJTAy
ZCIKKyMgdGltZS1zdGFtcC1lbmQ6ICInIgorIyBFbmQ6CmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9jb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlndXJlCU1vbiBGZWIgMjAgMTg6MjA6
MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwNDI5IEBACisjISAvYmluL3NoCisjIEd1ZXNzIHZh
bHVlcyBmb3Igc3lzdGVtLWRlcGVuZGVudCB2YXJpYWJsZXMgYW5kIGNyZWF0ZSBNYWtlZmlsZXMu
CisjIEdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OCBmb3IgWGVuIEh5cGVydmlzb3IgNC4y
LgorIworIyBSZXBvcnQgYnVncyB0byA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20+Lgor
IworIworIyBDb3B5cmlnaHQgKEMpIDE5OTIsIDE5OTMsIDE5OTQsIDE5OTUsIDE5OTYsIDE5OTgs
IDE5OTksIDIwMDAsIDIwMDEsCisjIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYsIDIwMDcs
IDIwMDgsIDIwMDksIDIwMTAgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuCisjCisj
CisjIFRoaXMgY29uZmlndXJlIHNjcmlwdCBpcyBmcmVlIHNvZnR3YXJlOyB0aGUgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uCisjIGdpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNvcHksIGRp
c3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4KKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBN
NHNoIEluaXRpYWxpemF0aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKworIyBC
ZSBtb3JlIEJvdXJuZSBjb21wYXRpYmxlCitEVUFMQ0FTRT0xOyBleHBvcnQgRFVBTENBU0UgIyBm
b3IgTUtTIHNoCitpZiB0ZXN0IC1uICIke1pTSF9WRVJTSU9OK3NldH0iICYmIChlbXVsYXRlIHNo
KSA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAj
IFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uICR7MSsiJEAifSwg
d2hpY2gKKyAgIyBpcyBjb250cmFyeSB0byBvdXIgdXNhZ2UuICBEaXNhYmxlIHRoaXMgZmVhdHVy
ZS4KKyAgYWxpYXMgLWcgJyR7MSsiJEAifSc9JyIkQCInCisgIHNldG9wdCBOT19HTE9CX1NVQlNU
CitlbHNlCisgIGNhc2UgYChzZXQgLW8pIDI+L2Rldi9udWxsYCBpbiAjKAorICAqcG9zaXgqKSA6
CisgICAgc2V0IC1vIHBvc2l4IDs7ICMoCisgICopIDoKKyAgICAgOzsKK2VzYWMKK2ZpCisKKwor
YXNfbmw9JworJworZXhwb3J0IGFzX25sCisjIFByaW50aW5nIGEgbG9uZyBzdHJpbmcgY3Jhc2hl
cyBTb2xhcmlzIDcgL3Vzci9iaW4vcHJpbnRmLgorYXNfZWNobz0nXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXCcKK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRh
c19lY2hvJGFzX2VjaG8kYXNfZWNobworYXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8k
YXNfZWNobyRhc19lY2hvJGFzX2VjaG8KKyMgUHJlZmVyIGEga3NoIHNoZWxsIGJ1aWx0aW4gb3Zl
ciBhbiBleHRlcm5hbCBwcmludGYgcHJvZ3JhbSBvbiBTb2xhcmlzLAorIyBidXQgd2l0aG91dCB3
YXN0aW5nIGZvcmtzIGZvciBiYXNoIG9yIHpzaC4KK2lmIHRlc3QgLXogIiRCQVNIX1ZFUlNJT04k
WlNIX1ZFUlNJT04iIFwKKyAgICAmJiAodGVzdCAiWGBwcmludCAtciAtLSAkYXNfZWNob2AiID0g
IlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50IC1yIC0tJwor
ICBhc19lY2hvX249J3ByaW50IC1ybiAtLScKK2VsaWYgKHRlc3QgIlhgcHJpbnRmICVzICRhc19l
Y2hvYCIgPSAiWCRhc19lY2hvIikgMj4vZGV2L251bGw7IHRoZW4KKyAgYXNfZWNobz0ncHJpbnRm
ICVzXG4nCisgIGFzX2VjaG9fbj0ncHJpbnRmICVzJworZWxzZQorICBpZiB0ZXN0ICJYYCgvdXNy
L3VjYi9lY2hvIC1uIC1uICRhc19lY2hvKSAyPi9kZXYvbnVsbGAiID0gIlgtbiAkYXNfZWNobyI7
IHRoZW4KKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgL3Vzci91Y2IvZWNobyAtbiAiJDEkYXNfbmwi
JworICAgIGFzX2VjaG9fbj0nL3Vzci91Y2IvZWNobyAtbicKKyAgZWxzZQorICAgIGFzX2VjaG9f
Ym9keT0nZXZhbCBleHByICJYJDEiIDogIlhcXCguKlxcKSInCisgICAgYXNfZWNob19uX2JvZHk9
J2V2YWwKKyAgICAgIGFyZz0kMTsKKyAgICAgIGNhc2UgJGFyZyBpbiAjKAorICAgICAgKiIkYXNf
bmwiKikKKwlleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpJGFzX25sIjsKKwlhcmc9YGV4cHIgIlgk
YXJnIiA6ICIuKiRhc19ubFxcKC4qXFwpImA7OworICAgICAgZXNhYzsKKyAgICAgIGV4cHIgIlgk
YXJnIiA6ICJYXFwoLipcXCkiIHwgdHIgLWQgIiRhc19ubCIKKyAgICAnCisgICAgZXhwb3J0IGFz
X2VjaG9fbl9ib2R5CisgICAgYXNfZWNob19uPSdzaCAtYyAkYXNfZWNob19uX2JvZHkgYXNfZWNo
bycKKyAgZmkKKyAgZXhwb3J0IGFzX2VjaG9fYm9keQorICBhc19lY2hvPSdzaCAtYyAkYXNfZWNo
b19ib2R5IGFzX2VjaG8nCitmaQorCisjIFRoZSB1c2VyIGlzIGFsd2F5cyByaWdodC4KK2lmIHRl
c3QgIiR7UEFUSF9TRVBBUkFUT1Irc2V0fSIgIT0gc2V0OyB0aGVuCisgIFBBVEhfU0VQQVJBVE9S
PToKKyAgKFBBVEg9Jy9iaW47L2Jpbic7IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rldi9udWxs
IDI+JjEgJiYgeworICAgIChQQVRIPScvYmluOi9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikg
Pi9kZXYvbnVsbCAyPiYxIHx8CisgICAgICBQQVRIX1NFUEFSQVRPUj0nOycKKyAgfQorZmkKKwor
CisjIElGUworIyBXZSBuZWVkIHNwYWNlLCB0YWIgYW5kIG5ldyBsaW5lLCBpbiBwcmVjaXNlbHkg
dGhhdCBvcmRlci4gIFF1b3RpbmcgaXMKKyMgdGhlcmUgdG8gcHJldmVudCBlZGl0b3JzIGZyb20g
Y29tcGxhaW5pbmcgYWJvdXQgc3BhY2UtdGFiLgorIyAoSWYgX0FTX1BBVEhfV0FMSyB3ZXJlIGNh
bGxlZCB3aXRoIElGUyB1bnNldCwgaXQgd291bGQgZGlzYWJsZSB3b3JkCisjIHNwbGl0dGluZyBi
eSBzZXR0aW5nIElGUyB0byBlbXB0eSB2YWx1ZS4pCitJRlM9IiAiIgkkYXNfbmwiCisKKyMgRmlu
ZCB3aG8gd2UgYXJlLiAgTG9vayBpbiB0aGUgcGF0aCBpZiB3ZSBjb250YWluIG5vIGRpcmVjdG9y
eSBzZXBhcmF0b3IuCithc19teXNlbGY9CitjYXNlICQwIGluICMoKAorICAqW1xcL10qICkgYXNf
bXlzZWxmPSQwIDs7CisgICopIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICB0ZXN0IC1yICIkYXNfZGlyLyQwIiAmJiBhc19teXNl
bGY9JGFzX2Rpci8kMCAmJiBicmVhaworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgICAg
OzsKK2VzYWMKKyMgV2UgZGlkIG5vdCBmaW5kIG91cnNlbHZlcywgbW9zdCBwcm9iYWJseSB3ZSB3
ZXJlIHJ1biBhcyBgc2ggQ09NTUFORCcKKyMgaW4gd2hpY2ggY2FzZSB3ZSBhcmUgbm90IHRvIGJl
IGZvdW5kIGluIHRoZSBwYXRoLgoraWYgdGVzdCAieCRhc19teXNlbGYiID0geDsgdGhlbgorICBh
c19teXNlbGY9JDAKK2ZpCitpZiB0ZXN0ICEgLWYgIiRhc19teXNlbGYiOyB0aGVuCisgICRhc19l
Y2hvICIkYXNfbXlzZWxmOiBlcnJvcjogY2Fubm90IGZpbmQgbXlzZWxmOyByZXJ1biB3aXRoIGFu
IGFic29sdXRlIGZpbGUgbmFtZSIgPiYyCisgIGV4aXQgMQorZmkKKworIyBVbnNldCB2YXJpYWJs
ZXMgdGhhdCB3ZSBkbyBub3QgbmVlZCBhbmQgd2hpY2ggY2F1c2UgYnVncyAoZS5nLiBpbgorIyBw
cmUtMy4wIFVXSU4ga3NoKS4gIEJ1dCBkbyBub3QgY2F1c2UgYnVncyBpbiBiYXNoIDIuMDE7IHRo
ZSAifHwgZXhpdCAxIgorIyBzdXBwcmVzc2VzIGFueSAiU2VnbWVudGF0aW9uIGZhdWx0IiBtZXNz
YWdlIHRoZXJlLiAgJygoJyBjb3VsZAorIyB0cmlnZ2VyIGEgYnVnIGluIHBka3NoIDUuMi4xNC4K
K2ZvciBhc192YXIgaW4gQkFTSF9FTlYgRU5WIE1BSUwgTUFJTFBBVEgKK2RvIGV2YWwgdGVzdCB4
XCR7JGFzX3ZhcitzZXR9ID0geHNldCBcCisgICYmICggKHVuc2V0ICRhc192YXIpIHx8IGV4aXQg
MSkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0ICRhc192YXIgfHwgOgorZG9uZQorUFMxPSckICcK
K1BTMj0nPiAnCitQUzQ9JysgJworCisjIE5MUyBudWlzYW5jZXMuCitMQ19BTEw9QworZXhwb3J0
IExDX0FMTAorTEFOR1VBR0U9QworZXhwb3J0IExBTkdVQUdFCisKKyMgQ0RQQVRILgorKHVuc2V0
IENEUEFUSCkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IENEUEFUSAorCitpZiB0ZXN0ICJ4JENP
TkZJR19TSEVMTCIgPSB4OyB0aGVuCisgIGFzX2JvdXJuZV9jb21wYXRpYmxlPSJpZiB0ZXN0IC1u
IFwiXCR7WlNIX1ZFUlNJT04rc2V0fVwiICYmIChlbXVsYXRlIHNoKSA+L2Rldi9udWxsIDI+JjE7
IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAjIFByZS00LjIgdmVyc2lvbnMg
b2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uIFwkezErXCJcJEBcIn0sIHdoaWNoCisgICMgaXMg
Y29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1n
ICdcJHsxK1wiXCRAXCJ9Jz0nXCJcJEBcIicKKyAgc2V0b3B0IE5PX0dMT0JfU1VCU1QKK2Vsc2UK
KyAgY2FzZSBcYChzZXQgLW8pIDI+L2Rldi9udWxsXGAgaW4gIygKKyAgKnBvc2l4KikgOgorICAg
IHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorIgorICBhc19y
ZXF1aXJlZD0iYXNfZm5fcmV0dXJuICgpIHsgKGV4aXQgXCQxKTsgfQorYXNfZm5fc3VjY2VzcyAo
KSB7IGFzX2ZuX3JldHVybiAwOyB9Cithc19mbl9mYWlsdXJlICgpIHsgYXNfZm5fcmV0dXJuIDE7
IH0KK2FzX2ZuX3JldF9zdWNjZXNzICgpIHsgcmV0dXJuIDA7IH0KK2FzX2ZuX3JldF9mYWlsdXJl
ICgpIHsgcmV0dXJuIDE7IH0KKworZXhpdGNvZGU9MAorYXNfZm5fc3VjY2VzcyB8fCB7IGV4aXRj
b2RlPTE7IGVjaG8gYXNfZm5fc3VjY2VzcyBmYWlsZWQuOyB9Cithc19mbl9mYWlsdXJlICYmIHsg
ZXhpdGNvZGU9MTsgZWNobyBhc19mbl9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2FzX2ZuX3JldF9z
dWNjZXNzIHx8IHsgZXhpdGNvZGU9MTsgZWNobyBhc19mbl9yZXRfc3VjY2VzcyBmYWlsZWQuOyB9
Cithc19mbl9yZXRfZmFpbHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fcmV0X2ZhaWx1
cmUgc3VjY2VlZGVkLjsgfQoraWYgKCBzZXQgeDsgYXNfZm5fcmV0X3N1Y2Nlc3MgeSAmJiB0ZXN0
IHggPSBcIlwkMVwiICk7IHRoZW4gOgorCitlbHNlCisgIGV4aXRjb2RlPTE7IGVjaG8gcG9zaXRp
b25hbCBwYXJhbWV0ZXJzIHdlcmUgbm90IHNhdmVkLgorZmkKK3Rlc3QgeFwkZXhpdGNvZGUgPSB4
MCB8fCBleGl0IDEiCisgIGFzX3N1Z2dlc3RlZD0iICBhc19saW5lbm9fMT0iO2FzX3N1Z2dlc3Rl
ZD0kYXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCIgYXNfbGlu
ZW5vXzFhPVwkTElORU5PCisgIGFzX2xpbmVub18yPSI7YXNfc3VnZ2VzdGVkPSRhc19zdWdnZXN0
ZWQkTElORU5PO2FzX3N1Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkIiBhc19saW5lbm9fMmE9XCRMSU5F
Tk8KKyAgZXZhbCAndGVzdCBcInhcJGFzX2xpbmVub18xJ1wkYXNfcnVuJ1wiICE9IFwieFwkYXNf
bGluZW5vXzInXCRhc19ydW4nXCIgJiYKKyAgdGVzdCBcInhcYGV4cHIgXCRhc19saW5lbm9fMSdc
JGFzX3J1bicgKyAxXGBcIiA9IFwieFwkYXNfbGluZW5vXzInXCRhc19ydW4nXCInIHx8IGV4aXQg
MQordGVzdCBcJCgoIDEgKyAxICkpID0gMiB8fCBleGl0IDEiCisgIGlmIChldmFsICIkYXNfcmVx
dWlyZWQiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGFzX2hhdmVfcmVxdWlyZWQ9eWVzCitlbHNl
CisgIGFzX2hhdmVfcmVxdWlyZWQ9bm8KK2ZpCisgIGlmIHRlc3QgeCRhc19oYXZlX3JlcXVpcmVk
ID0geHllcyAmJiAoZXZhbCAiJGFzX3N1Z2dlc3RlZCIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKwor
ZWxzZQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCithc19mb3VuZD1m
YWxzZQorZm9yIGFzX2RpciBpbiAvYmluJFBBVEhfU0VQQVJBVE9SL3Vzci9iaW4kUEFUSF9TRVBB
UkFUT1IkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgorICBhc19mb3VuZD06CisgIGNhc2UgJGFzX2RpciBpbiAjKAorCSAvKikKKwkg
ICBmb3IgYXNfYmFzZSBpbiBzaCBiYXNoIGtzaCBzaDU7IGRvCisJICAgICAjIFRyeSBvbmx5IHNo
ZWxscyB0aGF0IGV4aXN0LCB0byBzYXZlIHNldmVyYWwgZm9ya3MuCisJICAgICBhc19zaGVsbD0k
YXNfZGlyLyRhc19iYXNlCisJICAgICBpZiB7IHRlc3QgLWYgIiRhc19zaGVsbCIgfHwgdGVzdCAt
ZiAiJGFzX3NoZWxsLmV4ZSI7IH0gJiYKKwkJICAgIHsgJGFzX2VjaG8gIiRhc19ib3VybmVfY29t
cGF0aWJsZSIiJGFzX3JlcXVpcmVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9IDI+L2Rldi9u
dWxsOyB0aGVuIDoKKyAgQ09ORklHX1NIRUxMPSRhc19zaGVsbCBhc19oYXZlX3JlcXVpcmVkPXll
cworCQkgICBpZiB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUiIiRhc19zdWdnZXN0
ZWQiIHwgYXNfcnVuPWEgIiRhc19zaGVsbCI7IH0gMj4vZGV2L251bGw7IHRoZW4gOgorICBicmVh
ayAyCitmaQorZmkKKwkgICBkb25lOzsKKyAgICAgICBlc2FjCisgIGFzX2ZvdW5kPWZhbHNlCitk
b25lCiskYXNfZm91bmQgfHwgeyBpZiB7IHRlc3QgLWYgIiRTSEVMTCIgfHwgdGVzdCAtZiAiJFNI
RUxMLmV4ZSI7IH0gJiYKKwkgICAgICB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUi
IiRhc19yZXF1aXJlZCIgfCBhc19ydW49YSAiJFNIRUxMIjsgfSAyPi9kZXYvbnVsbDsgdGhlbiA6
CisgIENPTkZJR19TSEVMTD0kU0hFTEwgYXNfaGF2ZV9yZXF1aXJlZD15ZXMKK2ZpOyB9CitJRlM9
JGFzX3NhdmVfSUZTCisKKworICAgICAgaWYgdGVzdCAieCRDT05GSUdfU0hFTEwiICE9IHg7IHRo
ZW4gOgorICAjIFdlIGNhbm5vdCB5ZXQgYXNzdW1lIGEgZGVjZW50IHNoZWxsLCBzbyB3ZSBoYXZl
IHRvIHByb3ZpZGUgYQorCSMgbmV1dHJhbGl6YXRpb24gdmFsdWUgZm9yIHNoZWxscyB3aXRob3V0
IHVuc2V0OyBhbmQgdGhpcyBhbHNvCisJIyB3b3JrcyBhcm91bmQgc2hlbGxzIHRoYXQgY2Fubm90
IHVuc2V0IG5vbmV4aXN0ZW50IHZhcmlhYmxlcy4KKwkjIFByZXNlcnZlIC12IGFuZCAteCB0byB0
aGUgcmVwbGFjZW1lbnQgc2hlbGwuCisJQkFTSF9FTlY9L2Rldi9udWxsCisJRU5WPS9kZXYvbnVs
bAorCSh1bnNldCBCQVNIX0VOVikgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IEJBU0hfRU5WIEVO
VgorCWV4cG9ydCBDT05GSUdfU0hFTEwKKwljYXNlICQtIGluICMgKCgoKAorCSAgKnYqeCogfCAq
eCp2KiApIGFzX29wdHM9LXZ4IDs7CisJICAqdiogKSBhc19vcHRzPS12IDs7CisJICAqeCogKSBh
c19vcHRzPS14IDs7CisJICAqICkgYXNfb3B0cz0gOzsKKwllc2FjCisJZXhlYyAiJENPTkZJR19T
SEVMTCIgJGFzX29wdHMgIiRhc19teXNlbGYiICR7MSsiJEAifQorZmkKKworICAgIGlmIHRlc3Qg
eCRhc19oYXZlX3JlcXVpcmVkID0geG5vOyB0aGVuIDoKKyAgJGFzX2VjaG8gIiQwOiBUaGlzIHNj
cmlwdCByZXF1aXJlcyBhIHNoZWxsIG1vcmUgbW9kZXJuIHRoYW4gYWxsIgorICAkYXNfZWNobyAi
JDA6IHRoZSBzaGVsbHMgdGhhdCBJIGZvdW5kIG9uIHlvdXIgc3lzdGVtLiIKKyAgaWYgdGVzdCB4
JHtaU0hfVkVSU0lPTitzZXR9ID0geHNldCA7IHRoZW4KKyAgICAkYXNfZWNobyAiJDA6IEluIHBh
cnRpY3VsYXIsIHpzaCAkWlNIX1ZFUlNJT04gaGFzIGJ1Z3MgYW5kIHNob3VsZCIKKyAgICAkYXNf
ZWNobyAiJDA6IGJlIHVwZ3JhZGVkIHRvIHpzaCA0LjMuNCBvciBsYXRlci4iCisgIGVsc2UKKyAg
ICAkYXNfZWNobyAiJDA6IFBsZWFzZSB0ZWxsIGJ1Zy1hdXRvY29uZkBnbnUub3JnIGFuZAorJDA6
IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIGFib3V0IHlvdXIgc3lzdGVtLAorJDA6IGlu
Y2x1ZGluZyBhbnkgZXJyb3IgcG9zc2libHkgb3V0cHV0IGJlZm9yZSB0aGlzCiskMDogbWVzc2Fn
ZS4gVGhlbiBpbnN0YWxsIGEgbW9kZXJuIHNoZWxsLCBvciBtYW51YWxseSBydW4KKyQwOiB0aGUg
c2NyaXB0IHVuZGVyIHN1Y2ggYSBzaGVsbCBpZiB5b3UgZG8gaGF2ZSBvbmUuIgorICBmaQorICBl
eGl0IDEKK2ZpCitmaQorZmkKK1NIRUxMPSR7Q09ORklHX1NIRUxMLS9iaW4vc2h9CitleHBvcnQg
U0hFTEwKKyMgVW5zZXQgbW9yZSB2YXJpYWJsZXMga25vd24gdG8gaW50ZXJmZXJlIHdpdGggYmVo
YXZpb3Igb2YgY29tbW9uIHRvb2xzLgorQ0xJQ09MT1JfRk9SQ0U9IEdSRVBfT1BUSU9OUz0KK3Vu
c2V0IENMSUNPTE9SX0ZPUkNFIEdSRVBfT1BUSU9OUworCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0gIyMKKyMjIE00c2ggU2hlbGwgRnVuY3Rpb25zLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICMjCisjIGFzX2ZuX3Vuc2V0IFZBUgorIyAtLS0tLS0tLS0tLS0tLS0KKyMgUG9ydGFibHkg
dW5zZXQgVkFSLgorYXNfZm5fdW5zZXQgKCkKK3sKKyAgeyBldmFsICQxPTsgdW5zZXQgJDE7fQor
fQorYXNfdW5zZXQ9YXNfZm5fdW5zZXQKKworIyBhc19mbl9zZXRfc3RhdHVzIFNUQVRVUworIyAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBTZXQgJD8gdG8gU1RBVFVTLCB3aXRob3V0IGZvcmtp
bmcuCithc19mbl9zZXRfc3RhdHVzICgpCit7CisgIHJldHVybiAkMQorfSAjIGFzX2ZuX3NldF9z
dGF0dXMKKworIyBhc19mbl9leGl0IFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLQorIyBFeGl0
IHRoZSBzaGVsbCB3aXRoIFNUQVRVUywgZXZlbiBpbiBhICJ0cmFwIDAiIG9yICJzZXQgLWUiIGNv
bnRleHQuCithc19mbl9leGl0ICgpCit7CisgIHNldCArZQorICBhc19mbl9zZXRfc3RhdHVzICQx
CisgIGV4aXQgJDEKK30gIyBhc19mbl9leGl0CisKKyMgYXNfZm5fbWtkaXJfcAorIyAtLS0tLS0t
LS0tLS0tCisjIENyZWF0ZSAiJGFzX2RpciIgYXMgYSBkaXJlY3RvcnksIGluY2x1ZGluZyBwYXJl
bnRzIGlmIG5lY2Vzc2FyeS4KK2FzX2ZuX21rZGlyX3AgKCkKK3sKKworICBjYXNlICRhc19kaXIg
aW4gIygKKyAgLSopIGFzX2Rpcj0uLyRhc19kaXI7OworICBlc2FjCisgIHRlc3QgLWQgIiRhc19k
aXIiIHx8IGV2YWwgJGFzX21rZGlyX3AgfHwgeworICAgIGFzX2RpcnM9CisgICAgd2hpbGUgOjsg
ZG8KKyAgICAgIGNhc2UgJGFzX2RpciBpbiAjKAorICAgICAgKlwnKikgYXNfcWRpcj1gJGFzX2Vj
aG8gIiRhc19kaXIiIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgIycoCisgICAgICAqKSBh
c19xZGlyPSRhc19kaXI7OworICAgICAgZXNhYworICAgICAgYXNfZGlycz0iJyRhc19xZGlyJyAk
YXNfZGlycyIKKyAgICAgIGFzX2Rpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19kaXIiIHx8CiskYXNf
ZXhwciBYIiRhc19kaXIiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgi
JGFzX2RpciIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpJCcg
XHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2Vj
aG8gWCIkYXNfZGlyIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyok
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkg
ICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wxLwor
CSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9
CisJICBzLy4qLy4vOyBxJ2AKKyAgICAgIHRlc3QgLWQgIiRhc19kaXIiICYmIGJyZWFrCisgICAg
ZG9uZQorICAgIHRlc3QgLXogIiRhc19kaXJzIiB8fCBldmFsICJta2RpciAkYXNfZGlycyIKKyAg
fSB8fCB0ZXN0IC1kICIkYXNfZGlyIiB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBk
aXJlY3RvcnkgJGFzX2RpciIKKworCit9ICMgYXNfZm5fbWtkaXJfcAorIyBhc19mbl9hcHBlbmQg
VkFSIFZBTFVFCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgQXBwZW5kIHRoZSB0ZXh0IGlu
IFZBTFVFIHRvIHRoZSBlbmQgb2YgdGhlIGRlZmluaXRpb24gY29udGFpbmVkIGluIFZBUi4gVGFr
ZQorIyBhZHZhbnRhZ2Ugb2YgYW55IHNoZWxsIG9wdGltaXphdGlvbnMgdGhhdCBhbGxvdyBhbW9y
dGl6ZWQgbGluZWFyIGdyb3d0aCBvdmVyCisjIHJlcGVhdGVkIGFwcGVuZHMsIGluc3RlYWQgb2Yg
dGhlIHR5cGljYWwgcXVhZHJhdGljIGdyb3d0aCBwcmVzZW50IGluIG5haXZlCisjIGltcGxlbWVu
dGF0aW9ucy4KK2lmIChldmFsICJhc192YXI9MTsgYXNfdmFyKz0yOyB0ZXN0IHhcJGFzX3ZhciA9
IHgxMiIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXBwZW5kICgpCisgIHsK
KyAgICBldmFsICQxKz1cJDIKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXBwZW5kICgpCisgIHsKKyAg
ICBldmFsICQxPVwkJDFcJDIKKyAgfQorZmkgIyBhc19mbl9hcHBlbmQKKworIyBhc19mbl9hcml0
aCBBUkcuLi4KKyMgLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBlcmZvcm0gYXJpdGhtZXRpYyBldmFs
dWF0aW9uIG9uIHRoZSBBUkdzLCBhbmQgc3RvcmUgdGhlIHJlc3VsdCBpbiB0aGUKKyMgZ2xvYmFs
ICRhc192YWwuIFRha2UgYWR2YW50YWdlIG9mIHNoZWxscyB0aGF0IGNhbiBhdm9pZCBmb3Jrcy4g
VGhlIGFyZ3VtZW50cworIyBtdXN0IGJlIHBvcnRhYmxlIGFjcm9zcyAkKCgpKSBhbmQgZXhwci4K
K2lmIChldmFsICJ0ZXN0IFwkKCggMSArIDEgKSkgPSAyIikgMj4vZGV2L251bGw7IHRoZW4gOgor
ICBldmFsICdhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPSQoKCAkKiApKQorICB9Jwor
ZWxzZQorICBhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPWBleHByICIkQCIgfHwgdGVz
dCAkPyAtZXEgMWAKKyAgfQorZmkgIyBhc19mbl9hcml0aAorCisKKyMgYXNfZm5fZXJyb3IgU1RB
VFVTIEVSUk9SIFtMSU5FTk8gTE9HX0ZEXQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCisjIE91dHB1dCAiYGJhc2VuYW1lICQwYDogZXJyb3I6IEVSUk9SIiB0byBz
dGRlcnIuIElmIExJTkVOTyBhbmQgTE9HX0ZEIGFyZQorIyBwcm92aWRlZCwgYWxzbyBvdXRwdXQg
dGhlIGVycm9yIHRvIExPR19GRCwgcmVmZXJlbmNpbmcgTElORU5PLiBUaGVuIGV4aXQgdGhlCisj
IHNjcmlwdCB3aXRoIFNUQVRVUywgdXNpbmcgMSBpZiB0aGF0IHdhcyAwLgorYXNfZm5fZXJyb3Ig
KCkKK3sKKyAgYXNfc3RhdHVzPSQxOyB0ZXN0ICRhc19zdGF0dXMgLWVxIDAgJiYgYXNfc3RhdHVz
PTEKKyAgaWYgdGVzdCAiJDQiOyB0aGVuCisgICAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMyJ9
IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiAkMiIgPiYkNAorICBm
aQorICAkYXNfZWNobyAiJGFzX21lOiBlcnJvcjogJDIiID4mMgorICBhc19mbl9leGl0ICRhc19z
dGF0dXMKK30gIyBhc19mbl9lcnJvcgorCitpZiBleHByIGEgOiAnXChhXCknID4vZGV2L251bGwg
Mj4mMSAmJgorICAgdGVzdCAiWGBleHByIDAwMDAxIDogJy4qXCguLi5cKSdgIiA9IFgwMDE7IHRo
ZW4KKyAgYXNfZXhwcj1leHByCitlbHNlCisgIGFzX2V4cHI9ZmFsc2UKK2ZpCisKK2lmIChiYXNl
bmFtZSAtLSAvKSA+L2Rldi9udWxsIDI+JjEgJiYgdGVzdCAiWGBiYXNlbmFtZSAtLSAvIDI+JjFg
IiA9ICJYLyI7IHRoZW4KKyAgYXNfYmFzZW5hbWU9YmFzZW5hbWUKK2Vsc2UKKyAgYXNfYmFzZW5h
bWU9ZmFsc2UKK2ZpCisKK2lmIChhc19kaXI9YGRpcm5hbWUgLS0gL2AgJiYgdGVzdCAiWCRhc19k
aXIiID0gWC8pID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBhc19kaXJuYW1lPWRpcm5hbWUKK2Vs
c2UKKyAgYXNfZGlybmFtZT1mYWxzZQorZmkKKworYXNfbWU9YCRhc19iYXNlbmFtZSAtLSAiJDAi
IHx8CiskYXNfZXhwciBYLyIkMCIgOiAnLiovXChbXi9dW14vXSpcKS8qJCcgXHwgXAorCSBYIiQw
IiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiQwIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2L251bGwg
fHwKKyRhc19lY2hvIFgvIiQwIiB8CisgICAgc2VkICcvXi4qXC9cKFteL11bXi9dKlwpXC8qJC97
CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cL1wpJC97CisJICAgIHMv
L1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cKS4qL3sKKwkgICAgcy8vXDEvCisJICAg
IHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorCisjIEF2b2lkIGRlcGVuZGluZyB1cG9uIENoYXJh
Y3RlciBSYW5nZXMuCithc19jcl9sZXR0ZXJzPSdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eicK
K2FzX2NyX0xFVFRFUlM9J0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJworYXNfY3JfTGV0dGVy
cz0kYXNfY3JfbGV0dGVycyRhc19jcl9MRVRURVJTCithc19jcl9kaWdpdHM9JzAxMjM0NTY3ODkn
Cithc19jcl9hbG51bT0kYXNfY3JfTGV0dGVycyRhc19jcl9kaWdpdHMKKworCisgIGFzX2xpbmVu
b18xPSRMSU5FTk8gYXNfbGluZW5vXzFhPSRMSU5FTk8KKyAgYXNfbGluZW5vXzI9JExJTkVOTyBh
c19saW5lbm9fMmE9JExJTkVOTworICBldmFsICd0ZXN0ICJ4JGFzX2xpbmVub18xJyRhc19ydW4n
IiAhPSAieCRhc19saW5lbm9fMickYXNfcnVuJyIgJiYKKyAgdGVzdCAieGBleHByICRhc19saW5l
bm9fMSckYXNfcnVuJyArIDFgIiA9ICJ4JGFzX2xpbmVub18yJyRhc19ydW4nIicgfHwgeworICAj
IEJsYW1lIExlZSBFLiBNY01haG9uICgxOTMxLTE5ODkpIGZvciBzZWQncyBzeW50YXguICA6LSkK
KyAgc2VkIC1uICcKKyAgICBwCisgICAgL1skXUxJTkVOTy89CisgICcgPCRhc19teXNlbGYgfAor
ICAgIHNlZCAnCisgICAgICBzL1skXUxJTkVOTy4qLyYtLworICAgICAgdCBsaW5lbm8KKyAgICAg
IGIKKyAgICAgIDpsaW5lbm8KKyAgICAgIE4KKyAgICAgIDpsb29wCisgICAgICBzL1skXUxJTkVO
T1woW14nJGFzX2NyX2FsbnVtJ19dLipcblwpXCguKlwpL1wyXDFcMi8KKyAgICAgIHQgbG9vcAor
ICAgICAgcy8tXG4uKi8vCisgICAgJyA+JGFzX21lLmxpbmVubyAmJgorICBjaG1vZCAreCAiJGFz
X21lLmxpbmVubyIgfHwKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjYW5ub3QgY3Jl
YXRlICRhc19tZS5saW5lbm87IHJlcnVuIHdpdGggYSBQT1NJWCBzaGVsbCIgPiYyOyBhc19mbl9l
eGl0IDE7IH0KKworICAjIERvbid0IHRyeSB0byBleGVjIGFzIGl0IGNoYW5nZXMgJFswXSwgY2F1
c2luZyBhbGwgc29ydCBvZiBwcm9ibGVtcworICAjICh0aGUgZGlybmFtZSBvZiAkWzBdIGlzIG5v
dCB0aGUgcGxhY2Ugd2hlcmUgd2UgbWlnaHQgZmluZCB0aGUKKyAgIyBvcmlnaW5hbCBhbmQgc28g
b24uICBBdXRvY29uZiBpcyBlc3BlY2lhbGx5IHNlbnNpdGl2ZSB0byB0aGlzKS4KKyAgLiAiLi8k
YXNfbWUubGluZW5vIgorICAjIEV4aXQgc3RhdHVzIGlzIHRoYXQgb2YgdGhlIGxhc3QgY29tbWFu
ZC4KKyAgZXhpdAorfQorCitFQ0hPX0M9IEVDSE9fTj0gRUNIT19UPQorY2FzZSBgZWNobyAtbiB4
YCBpbiAjKCgoKCgKKy1uKikKKyAgY2FzZSBgZWNobyAneHlcYydgIGluCisgICpjKikgRUNIT19U
PScJJzs7CSMgRUNIT19UIGlzIHNpbmdsZSB0YWIgY2hhcmFjdGVyLgorICB4eSkgIEVDSE9fQz0n
XGMnOzsKKyAgKikgICBlY2hvIGBlY2hvIGtzaDg4IGJ1ZyBvbiBBSVggNi4xYCA+IC9kZXYvbnVs
bAorICAgICAgIEVDSE9fVD0nCSc7OworICBlc2FjOzsKKyopCisgIEVDSE9fTj0nLW4nOzsKK2Vz
YWMKKworcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmZpbGUKK2lmIHRlc3QgLWQgY29u
ZiQkLmRpcjsgdGhlbgorICBybSAtZiBjb25mJCQuZGlyL2NvbmYkJC5maWxlCitlbHNlCisgIHJt
IC1mIGNvbmYkJC5kaXIKKyAgbWtkaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAorZmkKK2lmIChl
Y2hvID5jb25mJCQuZmlsZSkgMj4vZGV2L251bGw7IHRoZW4KKyAgaWYgbG4gLXMgY29uZiQkLmZp
bGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz0nbG4gLXMnCisgICAgIyAu
Li4gYnV0IHRoZXJlIGFyZSB0d28gZ290Y2hhczoKKyAgICAjIDEpIE9uIE1TWVMsIGJvdGggYGxu
IC1zIGZpbGUgZGlyJyBhbmQgYGxuIGZpbGUgZGlyJyBmYWlsLgorICAgICMgMikgREpHUFAgPCAy
LjA0IGhhcyBubyBzeW1saW5rczsgYGxuIC1zJyBjcmVhdGVzIGEgd3JhcHBlciBleGVjdXRhYmxl
LgorICAgICMgSW4gYm90aCBjYXNlcywgd2UgaGF2ZSB0byBkZWZhdWx0IHRvIGBjcCAtcCcuCisg
ICAgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQkLmRpciAyPi9kZXYvbnVsbCAmJiB0ZXN0ICEgLWYg
Y29uZiQkLmV4ZSB8fAorICAgICAgYXNfbG5fcz0nY3AgLXAnCisgIGVsaWYgbG4gY29uZiQkLmZp
bGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz1sbgorICBlbHNlCisgICAg
YXNfbG5fcz0nY3AgLXAnCisgIGZpCitlbHNlCisgIGFzX2xuX3M9J2NwIC1wJworZmkKK3JtIC1m
IGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5kaXIvY29uZiQkLmZpbGUgY29uZiQkLmZpbGUKK3Jt
ZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwKKworaWYgbWtkaXIgLXAgLiAyPi9kZXYvbnVsbDsg
dGhlbgorICBhc19ta2Rpcl9wPSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRlc3QgLWQg
Li8tcCAmJiBybWRpciAuLy1wCisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRlc3QgLXgg
LyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxzZQorICBp
ZiBscyAtZEwgLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlvbj1MCisg
IGVsc2UKKyAgICBhc19sc19MX29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAgICBldmFs
IHNoIC1jICdcJycKKyAgICAgIGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQgIiQxLy4i
OworICAgICAgZWxzZQorCWNhc2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwllc2FjOwor
CWNhc2UgYGxzIC1sZCckYXNfbHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGluICMoKAor
CT8/P1tzeF0qKTo7OyopZmFsc2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2ZpCithc19l
eGVjdXRhYmxlX3A9JGFzX3Rlc3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmlu
ZyBvbnRvIGEgdmFsaWQgQ1BQIG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSokYXNfY3Jf
bGV0dGVycyVQJGFzX2NyX0xFVFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisjIFNl
ZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUgbmFtZS4K
K2FzX3RyX3NoPSJldmFsIHNlZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisK
KwordGVzdCAtbiAiJERKRElSIiB8fCBleGVjIDc8JjAgPC9kZXYvbnVsbAorZXhlYyA2PiYxCisK
KyMgTmFtZSBvZiB0aGUgaG9zdC4KKyMgaG9zdG5hbWUgb24gc29tZSBzeXN0ZW1zIChTVlIzLjIs
IG9sZCBHTlUvTGludXgpIHJldHVybnMgYSBib2d1cyBleGl0IHN0YXR1cywKKyMgc28gdW5hbWUg
Z2V0cyBydW4gdG9vLgorYWNfaG9zdG5hbWU9YChob3N0bmFtZSB8fCB1bmFtZSAtbikgMj4vZGV2
L251bGwgfCBzZWQgMXFgCisKKyMKKyMgSW5pdGlhbGl6YXRpb25zLgorIworYWNfZGVmYXVsdF9w
cmVmaXg9L3Vzci9sb2NhbAorYWNfY2xlYW5fZmlsZXM9CithY19jb25maWdfbGlib2JqX2Rpcj0u
CitMSUJPQkpTPQorY3Jvc3NfY29tcGlsaW5nPW5vCitzdWJkaXJzPQorTUZMQUdTPQorTUFLRUZM
QUdTPQorCisjIElkZW50aXR5IG9mIHRoaXMgcGFja2FnZS4KK1BBQ0tBR0VfTkFNRT0nWGVuIEh5
cGVydmlzb3InCitQQUNLQUdFX1RBUk5BTUU9J3hlbi1oeXBlcnZpc29yJworUEFDS0FHRV9WRVJT
SU9OPSc0LjInCitQQUNLQUdFX1NUUklORz0nWGVuIEh5cGVydmlzb3IgNC4yJworUEFDS0FHRV9C
VUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tJworUEFDS0FHRV9VUkw9JycK
KworYWNfdW5pcXVlX2ZpbGU9ImxpYnhsL2xpYnhsLmMiCithY19kZWZhdWx0X3ByZWZpeD0vdXNy
CisjIEZhY3RvcmluZyBkZWZhdWx0IGhlYWRlcnMgZm9yIG1vc3QgdGVzdHMuCithY19pbmNsdWRl
c19kZWZhdWx0PSJcCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpZmRlZiBIQVZFX1NZU19UWVBFU19I
CisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TWVNfU1RBVF9I
CisjIGluY2x1ZGUgPHN5cy9zdGF0Lmg+CisjZW5kaWYKKyNpZmRlZiBTVERDX0hFQURFUlMKKyMg
aW5jbHVkZSA8c3RkbGliLmg+CisjIGluY2x1ZGUgPHN0ZGRlZi5oPgorI2Vsc2UKKyMgaWZkZWYg
SEFWRV9TVERMSUJfSAorIyAgaW5jbHVkZSA8c3RkbGliLmg+CisjIGVuZGlmCisjZW5kaWYKKyNp
ZmRlZiBIQVZFX1NUUklOR19ICisjIGlmICFkZWZpbmVkIFNURENfSEVBREVSUyAmJiBkZWZpbmVk
IEhBVkVfTUVNT1JZX0gKKyMgIGluY2x1ZGUgPG1lbW9yeS5oPgorIyBlbmRpZgorIyBpbmNsdWRl
IDxzdHJpbmcuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RSSU5HU19ICisjIGluY2x1ZGUgPHN0
cmluZ3MuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfSU5UVFlQRVNfSAorIyBpbmNsdWRlIDxpbnR0
eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TVERJTlRfSAorIyBpbmNsdWRlIDxzdGRpbnQu
aD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3RkLmg+Cisj
ZW5kaWYiCisKK2FjX2hlYWRlcl9saXN0PQorYWNfZnVuY19saXN0PQorYWNfc3Vic3RfdmFycz0n
TFRMSUJPQkpTCitQT1dfTElCCitMSUJPQkpTCitBTExPQ0EKK2xpYmljb252CitsaWJnY3J5cHQK
K2xpYmV4dDJmcworc3lzdGVtX2FpbworTElCX1BBVEgKK2dsaWJfTElCUworZ2xpYl9DRkxBR1MK
K1BLR19DT05GSUdfTElCRElSCitQS0dfQ09ORklHX1BBVEgKK1BLR19DT05GSUcKK1ZOQ09ORklH
CitIT1RQTFVHCitVREVWSU5GTworVURFVkFETQorUFlUSE9OUEFUSAorT0NBTUxCVUlMRAorT0NB
TUxET0MKK09DQU1MTUtMSUIKK09DQU1MTUtUT1AKK09DQU1MREVQCitPQ0FNTAorT0NBTUxPUFRE
T1RPUFQKK09DQU1MQ0RPVE9QVAorT0NBTUxCRVNUCitPQ0FNTE9QVAorT0NBTUxMSUIKK09DQU1M
VkVSU0lPTgorT0NBTUxDCitJTlNUQUxMX0RBVEEKK0lOU1RBTExfU0NSSVBUCitJTlNUQUxMX1BS
T0dSQU0KK1NFVF9NQUtFCitMTl9TCitTRUQKK1hHRVRURVhUCitCQVNICitYTUwKK0NVUkwKK0ZM
RVgKK0JJU09OCitJUAorQlJDVEwKK1BFUkwKK1BZVEhPTgorQVBQRU5EX0xJQgorQVBQRU5EX0lO
Q0xVREVTCitQUkVQRU5EX0xJQgorUFJFUEVORF9JTkNMVURFUworZGVidWcKK2xvbW91bnQKK21p
bml0ZXJtCitvY2FtbHRvb2xzCitweXRob250b29scworeGFwaQordnRwbQorbW9uaXRvcnMKK2dp
dGh0dHAKK3hzbQoraG9zdF9vcworaG9zdF92ZW5kb3IKK2hvc3RfY3B1Citob3N0CitidWlsZF9v
cworYnVpbGRfdmVuZG9yCitidWlsZF9jcHUKK2J1aWxkCitFR1JFUAorR1JFUAorQ1BQCitPQkpF
WFQKK0VYRUVYVAorYWNfY3RfQ0MKK0NQUEZMQUdTCitMREZMQUdTCitDRkxBR1MKK0NDCit0YXJn
ZXRfYWxpYXMKK2hvc3RfYWxpYXMKK2J1aWxkX2FsaWFzCitMSUJTCitFQ0hPX1QKK0VDSE9fTgor
RUNIT19DCitERUZTCittYW5kaXIKK2xvY2FsZWRpcgorbGliZGlyCitwc2RpcgorcGRmZGlyCitk
dmlkaXIKK2h0bWxkaXIKK2luZm9kaXIKK2RvY2Rpcgorb2xkaW5jbHVkZWRpcgoraW5jbHVkZWRp
cgorbG9jYWxzdGF0ZWRpcgorc2hhcmVkc3RhdGVkaXIKK3N5c2NvbmZkaXIKK2RhdGFkaXIKK2Rh
dGFyb290ZGlyCitsaWJleGVjZGlyCitzYmluZGlyCitiaW5kaXIKK3Byb2dyYW1fdHJhbnNmb3Jt
X25hbWUKK3ByZWZpeAorZXhlY19wcmVmaXgKK1BBQ0tBR0VfVVJMCitQQUNLQUdFX0JVR1JFUE9S
VAorUEFDS0FHRV9TVFJJTkcKK1BBQ0tBR0VfVkVSU0lPTgorUEFDS0FHRV9UQVJOQU1FCitQQUNL
QUdFX05BTUUKK1BBVEhfU0VQQVJBVE9SCitTSEVMTCcKK2FjX3N1YnN0X2ZpbGVzPScnCithY191
c2VyX29wdHM9JworZW5hYmxlX29wdGlvbl9jaGVja2luZworZW5hYmxlX3hzbQorZW5hYmxlX2dp
dGh0dHAKK2VuYWJsZV9tb25pdG9ycworZW5hYmxlX3Z0cG0KK2VuYWJsZV94YXBpCitlbmFibGVf
cHl0aG9udG9vbHMKK2VuYWJsZV9vY2FtbHRvb2xzCitlbmFibGVfbWluaXRlcm0KK2VuYWJsZV9s
b21vdW50CitlbmFibGVfZGVidWcKKycKKyAgICAgIGFjX3ByZWNpb3VzX3ZhcnM9J2J1aWxkX2Fs
aWFzCitob3N0X2FsaWFzCit0YXJnZXRfYWxpYXMKK0NDCitDRkxBR1MKK0xERkxBR1MKK0xJQlMK
K0NQUEZMQUdTCitDUFAKK1BSRVBFTkRfSU5DTFVERVMKK1BSRVBFTkRfTElCCitBUFBFTkRfSU5D
TFVERVMKK0FQUEVORF9MSUIKK1BZVEhPTgorUEVSTAorQlJDVEwKK0lQCitCSVNPTgorRkxFWAor
Q1VSTAorWE1MCitCQVNICitYR0VUVEVYVAorUEtHX0NPTkZJRworUEtHX0NPTkZJR19QQVRICitQ
S0dfQ09ORklHX0xJQkRJUgorZ2xpYl9DRkxBR1MKK2dsaWJfTElCUycKKworCisjIEluaXRpYWxp
emUgc29tZSB2YXJpYWJsZXMgc2V0IGJ5IG9wdGlvbnMuCithY19pbml0X2hlbHA9CithY19pbml0
X3ZlcnNpb249ZmFsc2UKK2FjX3VucmVjb2duaXplZF9vcHRzPQorYWNfdW5yZWNvZ25pemVkX3Nl
cD0KKyMgVGhlIHZhcmlhYmxlcyBoYXZlIHRoZSBzYW1lIG5hbWVzIGFzIHRoZSBvcHRpb25zLCB3
aXRoCisjIGRhc2hlcyBjaGFuZ2VkIHRvIHVuZGVybGluZXMuCitjYWNoZV9maWxlPS9kZXYvbnVs
bAorZXhlY19wcmVmaXg9Tk9ORQorbm9fY3JlYXRlPQorbm9fcmVjdXJzaW9uPQorcHJlZml4PU5P
TkUKK3Byb2dyYW1fcHJlZml4PU5PTkUKK3Byb2dyYW1fc3VmZml4PU5PTkUKK3Byb2dyYW1fdHJh
bnNmb3JtX25hbWU9cyx4LHgsCitzaWxlbnQ9CitzaXRlPQorc3JjZGlyPQordmVyYm9zZT0KK3hf
aW5jbHVkZXM9Tk9ORQoreF9saWJyYXJpZXM9Tk9ORQorCisjIEluc3RhbGxhdGlvbiBkaXJlY3Rv
cnkgb3B0aW9ucy4KKyMgVGhlc2UgYXJlIGxlZnQgdW5leHBhbmRlZCBzbyB1c2VycyBjYW4gIm1h
a2UgaW5zdGFsbCBleGVjX3ByZWZpeD0vZm9vIgorIyBhbmQgYWxsIHRoZSB2YXJpYWJsZXMgdGhh
dCBhcmUgc3VwcG9zZWQgdG8gYmUgYmFzZWQgb24gZXhlY19wcmVmaXgKKyMgYnkgZGVmYXVsdCB3
aWxsIGFjdHVhbGx5IGNoYW5nZS4KKyMgVXNlIGJyYWNlcyBpbnN0ZWFkIG9mIHBhcmVucyBiZWNh
dXNlIHNoLCBwZXJsLCBldGMuIGFsc28gYWNjZXB0IHRoZW0uCisjIChUaGUgbGlzdCBmb2xsb3dz
IHRoZSBzYW1lIG9yZGVyIGFzIHRoZSBHTlUgQ29kaW5nIFN0YW5kYXJkcy4pCitiaW5kaXI9JyR7
ZXhlY19wcmVmaXh9L2JpbicKK3NiaW5kaXI9JyR7ZXhlY19wcmVmaXh9L3NiaW4nCitsaWJleGVj
ZGlyPScke2V4ZWNfcHJlZml4fS9saWJleGVjJworZGF0YXJvb3RkaXI9JyR7cHJlZml4fS9zaGFy
ZScKK2RhdGFkaXI9JyR7ZGF0YXJvb3RkaXJ9Jworc3lzY29uZmRpcj0nJHtwcmVmaXh9L2V0YycK
K3NoYXJlZHN0YXRlZGlyPScke3ByZWZpeH0vY29tJworbG9jYWxzdGF0ZWRpcj0nJHtwcmVmaXh9
L3ZhcicKK2luY2x1ZGVkaXI9JyR7cHJlZml4fS9pbmNsdWRlJworb2xkaW5jbHVkZWRpcj0nL3Vz
ci9pbmNsdWRlJworZG9jZGlyPScke2RhdGFyb290ZGlyfS9kb2MvJHtQQUNLQUdFX1RBUk5BTUV9
JworaW5mb2Rpcj0nJHtkYXRhcm9vdGRpcn0vaW5mbycKK2h0bWxkaXI9JyR7ZG9jZGlyfScKK2R2
aWRpcj0nJHtkb2NkaXJ9JworcGRmZGlyPScke2RvY2Rpcn0nCitwc2Rpcj0nJHtkb2NkaXJ9Jwor
bGliZGlyPScke2V4ZWNfcHJlZml4fS9saWInCitsb2NhbGVkaXI9JyR7ZGF0YXJvb3RkaXJ9L2xv
Y2FsZScKK21hbmRpcj0nJHtkYXRhcm9vdGRpcn0vbWFuJworCithY19wcmV2PQorYWNfZGFzaGRh
c2g9Citmb3IgYWNfb3B0aW9uCitkbworICAjIElmIHRoZSBwcmV2aW91cyBvcHRpb24gbmVlZHMg
YW4gYXJndW1lbnQsIGFzc2lnbiBpdC4KKyAgaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisg
ICAgZXZhbCAkYWNfcHJldj1cJGFjX29wdGlvbgorICAgIGFjX3ByZXY9CisgICAgY29udGludWUK
KyAgZmkKKworICBjYXNlICRhY19vcHRpb24gaW4KKyAgKj0/KikgYWNfb3B0YXJnPWBleHByICJY
JGFjX29wdGlvbiIgOiAnW149XSo9XCguKlwpJ2AgOzsKKyAgKj0pICAgYWNfb3B0YXJnPSA7Owor
ICAqKSAgICBhY19vcHRhcmc9eWVzIDs7CisgIGVzYWMKKworICAjIEFjY2VwdCB0aGUgaW1wb3J0
YW50IEN5Z251cyBjb25maWd1cmUgb3B0aW9ucywgc28gd2UgY2FuIGRpYWdub3NlIHR5cG9zLgor
CisgIGNhc2UgJGFjX2Rhc2hkYXNoJGFjX29wdGlvbiBpbgorICAtLSkKKyAgICBhY19kYXNoZGFz
aD15ZXMgOzsKKworICAtYmluZGlyIHwgLS1iaW5kaXIgfCAtLWJpbmRpIHwgLS1iaW5kIHwgLS1i
aW4gfCAtLWJpKQorICAgIGFjX3ByZXY9YmluZGlyIDs7CisgIC1iaW5kaXI9KiB8IC0tYmluZGly
PSogfCAtLWJpbmRpPSogfCAtLWJpbmQ9KiB8IC0tYmluPSogfCAtLWJpPSopCisgICAgYmluZGly
PSRhY19vcHRhcmcgOzsKKworICAtYnVpbGQgfCAtLWJ1aWxkIHwgLS1idWlsIHwgLS1idWkgfCAt
LWJ1KQorICAgIGFjX3ByZXY9YnVpbGRfYWxpYXMgOzsKKyAgLWJ1aWxkPSogfCAtLWJ1aWxkPSog
fCAtLWJ1aWw9KiB8IC0tYnVpPSogfCAtLWJ1PSopCisgICAgYnVpbGRfYWxpYXM9JGFjX29wdGFy
ZyA7OworCisgIC1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWwgfCAtLWNh
Y2hlLWZpIFwKKyAgfCAtLWNhY2hlLWYgfCAtLWNhY2hlLSB8IC0tY2FjaGUgfCAtLWNhY2ggfCAt
LWNhYyB8IC0tY2EgfCAtLWMpCisgICAgYWNfcHJldj1jYWNoZV9maWxlIDs7CisgIC1jYWNoZS1m
aWxlPSogfCAtLWNhY2hlLWZpbGU9KiB8IC0tY2FjaGUtZmlsPSogfCAtLWNhY2hlLWZpPSogXAor
ICB8IC0tY2FjaGUtZj0qIHwgLS1jYWNoZS09KiB8IC0tY2FjaGU9KiB8IC0tY2FjaD0qIHwgLS1j
YWM9KiB8IC0tY2E9KiB8IC0tYz0qKQorICAgIGNhY2hlX2ZpbGU9JGFjX29wdGFyZyA7OworCisg
IC0tY29uZmlnLWNhY2hlIHwgLUMpCisgICAgY2FjaGVfZmlsZT1jb25maWcuY2FjaGUgOzsKKwor
ICAtZGF0YWRpciB8IC0tZGF0YWRpciB8IC0tZGF0YWRpIHwgLS1kYXRhZCkKKyAgICBhY19wcmV2
PWRhdGFkaXIgOzsKKyAgLWRhdGFkaXI9KiB8IC0tZGF0YWRpcj0qIHwgLS1kYXRhZGk9KiB8IC0t
ZGF0YWQ9KikKKyAgICBkYXRhZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGF0YXJvb3RkaXIgfCAt
LWRhdGFyb290ZGlyIHwgLS1kYXRhcm9vdGRpIHwgLS1kYXRhcm9vdGQgfCAtLWRhdGFyb290IFwK
KyAgfCAtLWRhdGFyb28gfCAtLWRhdGFybyB8IC0tZGF0YXIpCisgICAgYWNfcHJldj1kYXRhcm9v
dGRpciA7OworICAtZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3Rk
aT0qIHwgLS1kYXRhcm9vdGQ9KiBcCisgIHwgLS1kYXRhcm9vdD0qIHwgLS1kYXRhcm9vPSogfCAt
LWRhdGFybz0qIHwgLS1kYXRhcj0qKQorICAgIGRhdGFyb290ZGlyPSRhY19vcHRhcmcgOzsKKwor
ICAtZGlzYWJsZS0qIHwgLS1kaXNhYmxlLSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19v
cHRpb24iIDogJ3gtKmRpc2FibGUtXCguKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFy
ZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0
IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vy
cm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUgbmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9w
dF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0
IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAg
KiIKKyJlbmFibGVfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXpl
ZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZGlzYWJs
ZS0kYWNfdXNlcm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVz
YWMKKyAgICBldmFsIGVuYWJsZV8kYWNfdXNlcm9wdD1ubyA7OworCisgIC1kb2NkaXIgfCAtLWRv
Y2RpciB8IC0tZG9jZGkgfCAtLWRvYyB8IC0tZG8pCisgICAgYWNfcHJldj1kb2NkaXIgOzsKKyAg
LWRvY2Rpcj0qIHwgLS1kb2NkaXI9KiB8IC0tZG9jZGk9KiB8IC0tZG9jPSogfCAtLWRvPSopCisg
ICAgZG9jZGlyPSRhY19vcHRhcmcgOzsKKworICAtZHZpZGlyIHwgLS1kdmlkaXIgfCAtLWR2aWRp
IHwgLS1kdmlkIHwgLS1kdmkgfCAtLWR2KQorICAgIGFjX3ByZXY9ZHZpZGlyIDs7CisgIC1kdmlk
aXI9KiB8IC0tZHZpZGlyPSogfCAtLWR2aWRpPSogfCAtLWR2aWQ9KiB8IC0tZHZpPSogfCAtLWR2
PSopCisgICAgZHZpZGlyPSRhY19vcHRhcmcgOzsKKworICAtZW5hYmxlLSogfCAtLWVuYWJsZS0q
KQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSplbmFibGUtXChbXj1d
KlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFi
bGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51
bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUg
bmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAg
YWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAor
ICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQi
CisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVk
X29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZW5hYmxlLSRhY191c2Vyb3B0X29yaWciCisJIGFj
X3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAgZXNhYworICAgIGV2YWwgZW5hYmxlXyRhY191
c2Vyb3B0PVwkYWNfb3B0YXJnIDs7CisKKyAgLWV4ZWMtcHJlZml4IHwgLS1leGVjX3ByZWZpeCB8
IC0tZXhlYy1wcmVmaXggfCAtLWV4ZWMtcHJlZmkgXAorICB8IC0tZXhlYy1wcmVmIHwgLS1leGVj
LXByZSB8IC0tZXhlYy1wciB8IC0tZXhlYy1wIHwgLS1leGVjLSBcCisgIHwgLS1leGVjIHwgLS1l
eGUgfCAtLWV4KQorICAgIGFjX3ByZXY9ZXhlY19wcmVmaXggOzsKKyAgLWV4ZWMtcHJlZml4PSog
fCAtLWV4ZWNfcHJlZml4PSogfCAtLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWMtcHJlZmk9KiBcCisg
IHwgLS1leGVjLXByZWY9KiB8IC0tZXhlYy1wcmU9KiB8IC0tZXhlYy1wcj0qIHwgLS1leGVjLXA9
KiB8IC0tZXhlYy09KiBcCisgIHwgLS1leGVjPSogfCAtLWV4ZT0qIHwgLS1leD0qKQorICAgIGV4
ZWNfcHJlZml4PSRhY19vcHRhcmcgOzsKKworICAtZ2FzIHwgLS1nYXMgfCAtLWdhIHwgLS1nKQor
ICAgICMgT2Jzb2xldGU7IHVzZSAtLXdpdGgtZ2FzLgorICAgIHdpdGhfZ2FzPXllcyA7OworCisg
IC1oZWxwIHwgLS1oZWxwIHwgLS1oZWwgfCAtLWhlIHwgLWgpCisgICAgYWNfaW5pdF9oZWxwPWxv
bmcgOzsKKyAgLWhlbHA9ciogfCAtLWhlbHA9ciogfCAtLWhlbD1yKiB8IC0taGU9ciogfCAtaHIq
KQorICAgIGFjX2luaXRfaGVscD1yZWN1cnNpdmUgOzsKKyAgLWhlbHA9cyogfCAtLWhlbHA9cyog
fCAtLWhlbD1zKiB8IC0taGU9cyogfCAtaHMqKQorICAgIGFjX2luaXRfaGVscD1zaG9ydCA7Owor
CisgIC1ob3N0IHwgLS1ob3N0IHwgLS1ob3MgfCAtLWhvKQorICAgIGFjX3ByZXY9aG9zdF9hbGlh
cyA7OworICAtaG9zdD0qIHwgLS1ob3N0PSogfCAtLWhvcz0qIHwgLS1obz0qKQorICAgIGhvc3Rf
YWxpYXM9JGFjX29wdGFyZyA7OworCisgIC1odG1sZGlyIHwgLS1odG1sZGlyIHwgLS1odG1sZGkg
fCAtLWh0bWxkIHwgLS1odG1sIHwgLS1odG0gfCAtLWh0KQorICAgIGFjX3ByZXY9aHRtbGRpciA7
OworICAtaHRtbGRpcj0qIHwgLS1odG1sZGlyPSogfCAtLWh0bWxkaT0qIHwgLS1odG1sZD0qIHwg
LS1odG1sPSogfCAtLWh0bT0qIFwKKyAgfCAtLWh0PSopCisgICAgaHRtbGRpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaSB8IC0taW5j
bHVkZWQgfCAtLWluY2x1ZGUgXAorICB8IC0taW5jbHVkIHwgLS1pbmNsdSB8IC0taW5jbCB8IC0t
aW5jKQorICAgIGFjX3ByZXY9aW5jbHVkZWRpciA7OworICAtaW5jbHVkZWRpcj0qIHwgLS1pbmNs
dWRlZGlyPSogfCAtLWluY2x1ZGVkaT0qIHwgLS1pbmNsdWRlZD0qIHwgLS1pbmNsdWRlPSogXAor
ICB8IC0taW5jbHVkPSogfCAtLWluY2x1PSogfCAtLWluY2w9KiB8IC0taW5jPSopCisgICAgaW5j
bHVkZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWluZm9kaXIgfCAtLWluZm9kaXIgfCAtLWluZm9k
aSB8IC0taW5mb2QgfCAtLWluZm8gfCAtLWluZikKKyAgICBhY19wcmV2PWluZm9kaXIgOzsKKyAg
LWluZm9kaXI9KiB8IC0taW5mb2Rpcj0qIHwgLS1pbmZvZGk9KiB8IC0taW5mb2Q9KiB8IC0taW5m
bz0qIHwgLS1pbmY9KikKKyAgICBpbmZvZGlyPSRhY19vcHRhcmcgOzsKKworICAtbGliZGlyIHwg
LS1saWJkaXIgfCAtLWxpYmRpIHwgLS1saWJkKQorICAgIGFjX3ByZXY9bGliZGlyIDs7CisgIC1s
aWJkaXI9KiB8IC0tbGliZGlyPSogfCAtLWxpYmRpPSogfCAtLWxpYmQ9KikKKyAgICBsaWJkaXI9
JGFjX29wdGFyZyA7OworCisgIC1saWJleGVjZGlyIHwgLS1saWJleGVjZGlyIHwgLS1saWJleGVj
ZGkgfCAtLWxpYmV4ZWNkIHwgLS1saWJleGVjIFwKKyAgfCAtLWxpYmV4ZSB8IC0tbGliZXggfCAt
LWxpYmUpCisgICAgYWNfcHJldj1saWJleGVjZGlyIDs7CisgIC1saWJleGVjZGlyPSogfCAtLWxp
YmV4ZWNkaXI9KiB8IC0tbGliZXhlY2RpPSogfCAtLWxpYmV4ZWNkPSogfCAtLWxpYmV4ZWM9KiBc
CisgIHwgLS1saWJleGU9KiB8IC0tbGliZXg9KiB8IC0tbGliZT0qKQorICAgIGxpYmV4ZWNkaXI9
JGFjX29wdGFyZyA7OworCisgIC1sb2NhbGVkaXIgfCAtLWxvY2FsZWRpciB8IC0tbG9jYWxlZGkg
fCAtLWxvY2FsZWQgfCAtLWxvY2FsZSkKKyAgICBhY19wcmV2PWxvY2FsZWRpciA7OworICAtbG9j
YWxlZGlyPSogfCAtLWxvY2FsZWRpcj0qIHwgLS1sb2NhbGVkaT0qIHwgLS1sb2NhbGVkPSogfCAt
LWxvY2FsZT0qKQorICAgIGxvY2FsZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWxvY2Fsc3RhdGVk
aXIgfCAtLWxvY2Fsc3RhdGVkaXIgfCAtLWxvY2Fsc3RhdGVkaSB8IC0tbG9jYWxzdGF0ZWQgXAor
ICB8IC0tbG9jYWxzdGF0ZSB8IC0tbG9jYWxzdGF0IHwgLS1sb2NhbHN0YSB8IC0tbG9jYWxzdCB8
IC0tbG9jYWxzKQorICAgIGFjX3ByZXY9bG9jYWxzdGF0ZWRpciA7OworICAtbG9jYWxzdGF0ZWRp
cj0qIHwgLS1sb2NhbHN0YXRlZGlyPSogfCAtLWxvY2Fsc3RhdGVkaT0qIHwgLS1sb2NhbHN0YXRl
ZD0qIFwKKyAgfCAtLWxvY2Fsc3RhdGU9KiB8IC0tbG9jYWxzdGF0PSogfCAtLWxvY2Fsc3RhPSog
fCAtLWxvY2Fsc3Q9KiB8IC0tbG9jYWxzPSopCisgICAgbG9jYWxzdGF0ZWRpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLW1hbmRpciB8IC0tbWFuZGlyIHwgLS1tYW5kaSB8IC0tbWFuZCB8IC0tbWFuIHwg
LS1tYSB8IC0tbSkKKyAgICBhY19wcmV2PW1hbmRpciA7OworICAtbWFuZGlyPSogfCAtLW1hbmRp
cj0qIHwgLS1tYW5kaT0qIHwgLS1tYW5kPSogfCAtLW1hbj0qIHwgLS1tYT0qIHwgLS1tPSopCisg
ICAgbWFuZGlyPSRhY19vcHRhcmcgOzsKKworICAtbmZwIHwgLS1uZnAgfCAtLW5mKQorICAgICMg
T2Jzb2xldGU7IHVzZSAtLXdpdGhvdXQtZnAuCisgICAgd2l0aF9mcD1ubyA7OworCisgIC1uby1j
cmVhdGUgfCAtLW5vLWNyZWF0ZSB8IC0tbm8tY3JlYXQgfCAtLW5vLWNyZWEgfCAtLW5vLWNyZSBc
CisgIHwgLS1uby1jciB8IC0tbm8tYyB8IC1uKQorICAgIG5vX2NyZWF0ZT15ZXMgOzsKKworICAt
bm8tcmVjdXJzaW9uIHwgLS1uby1yZWN1cnNpb24gfCAtLW5vLXJlY3Vyc2lvIHwgLS1uby1yZWN1
cnNpIFwKKyAgfCAtLW5vLXJlY3VycyB8IC0tbm8tcmVjdXIgfCAtLW5vLXJlY3UgfCAtLW5vLXJl
YyB8IC0tbm8tcmUgfCAtLW5vLXIpCisgICAgbm9fcmVjdXJzaW9uPXllcyA7OworCisgIC1vbGRp
bmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRlZGkgfCAtLW9sZGluY2x1
ZGVkIFwKKyAgfCAtLW9sZGluY2x1ZGUgfCAtLW9sZGluY2x1ZCB8IC0tb2xkaW5jbHUgfCAtLW9s
ZGluY2wgfCAtLW9sZGluYyBcCisgIHwgLS1vbGRpbiB8IC0tb2xkaSB8IC0tb2xkIHwgLS1vbCB8
IC0tbykKKyAgICBhY19wcmV2PW9sZGluY2x1ZGVkaXIgOzsKKyAgLW9sZGluY2x1ZGVkaXI9KiB8
IC0tb2xkaW5jbHVkZWRpcj0qIHwgLS1vbGRpbmNsdWRlZGk9KiB8IC0tb2xkaW5jbHVkZWQ9KiBc
CisgIHwgLS1vbGRpbmNsdWRlPSogfCAtLW9sZGluY2x1ZD0qIHwgLS1vbGRpbmNsdT0qIHwgLS1v
bGRpbmNsPSogfCAtLW9sZGluYz0qIFwKKyAgfCAtLW9sZGluPSogfCAtLW9sZGk9KiB8IC0tb2xk
PSogfCAtLW9sPSogfCAtLW89KikKKyAgICBvbGRpbmNsdWRlZGlyPSRhY19vcHRhcmcgOzsKKwor
ICAtcHJlZml4IHwgLS1wcmVmaXggfCAtLXByZWZpIHwgLS1wcmVmIHwgLS1wcmUgfCAtLXByIHwg
LS1wKQorICAgIGFjX3ByZXY9cHJlZml4IDs7CisgIC1wcmVmaXg9KiB8IC0tcHJlZml4PSogfCAt
LXByZWZpPSogfCAtLXByZWY9KiB8IC0tcHJlPSogfCAtLXByPSogfCAtLXA9KikKKyAgICBwcmVm
aXg9JGFjX29wdGFyZyA7OworCisgIC1wcm9ncmFtLXByZWZpeCB8IC0tcHJvZ3JhbS1wcmVmaXgg
fCAtLXByb2dyYW0tcHJlZmkgfCAtLXByb2dyYW0tcHJlZiBcCisgIHwgLS1wcm9ncmFtLXByZSB8
IC0tcHJvZ3JhbS1wciB8IC0tcHJvZ3JhbS1wKQorICAgIGFjX3ByZXY9cHJvZ3JhbV9wcmVmaXgg
OzsKKyAgLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0t
cHJlZmk9KiBcCisgIHwgLS1wcm9ncmFtLXByZWY9KiB8IC0tcHJvZ3JhbS1wcmU9KiB8IC0tcHJv
Z3JhbS1wcj0qIHwgLS1wcm9ncmFtLXA9KikKKyAgICBwcm9ncmFtX3ByZWZpeD0kYWNfb3B0YXJn
IDs7CisKKyAgLXByb2dyYW0tc3VmZml4IHwgLS1wcm9ncmFtLXN1ZmZpeCB8IC0tcHJvZ3JhbS1z
dWZmaSB8IC0tcHJvZ3JhbS1zdWZmIFwKKyAgfCAtLXByb2dyYW0tc3VmIHwgLS1wcm9ncmFtLXN1
IHwgLS1wcm9ncmFtLXMpCisgICAgYWNfcHJldj1wcm9ncmFtX3N1ZmZpeCA7OworICAtcHJvZ3Jh
bS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaT0qIFwKKyAg
fCAtLXByb2dyYW0tc3VmZj0qIHwgLS1wcm9ncmFtLXN1Zj0qIHwgLS1wcm9ncmFtLXN1PSogfCAt
LXByb2dyYW0tcz0qKQorICAgIHByb2dyYW1fc3VmZml4PSRhY19vcHRhcmcgOzsKKworICAtcHJv
Z3JhbS10cmFuc2Zvcm0tbmFtZSB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSBcCisgIHwgLS1w
cm9ncmFtLXRyYW5zZm9ybS1uYW0gfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hIFwKKyAgfCAtLXBy
b2dyYW0tdHJhbnNmb3JtLW4gfCAtLXByb2dyYW0tdHJhbnNmb3JtLSBcCisgIHwgLS1wcm9ncmFt
LXRyYW5zZm9ybSB8IC0tcHJvZ3JhbS10cmFuc2ZvciBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm8g
fCAtLXByb2dyYW0tdHJhbnNmIFwKKyAgfCAtLXByb2dyYW0tdHJhbnMgfCAtLXByb2dyYW0tdHJh
biBcCisgIHwgLS1wcm9nci10cmEgfCAtLXByb2dyYW0tdHIgfCAtLXByb2dyYW0tdCkKKyAgICBh
Y19wcmV2PXByb2dyYW1fdHJhbnNmb3JtX25hbWUgOzsKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5h
bWU9KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNm
b3JtLW5hbT0qIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYT0qIFwKKyAgfCAtLXByb2dyYW0tdHJh
bnNmb3JtLW49KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tPSogXAorICB8IC0tcHJvZ3JhbS10cmFu
c2Zvcm09KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmbz0q
IHwgLS1wcm9ncmFtLXRyYW5zZj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnM9KiB8IC0tcHJvZ3Jh
bS10cmFuPSogXAorICB8IC0tcHJvZ3ItdHJhPSogfCAtLXByb2dyYW0tdHI9KiB8IC0tcHJvZ3Jh
bS10PSopCisgICAgcHJvZ3JhbV90cmFuc2Zvcm1fbmFtZT0kYWNfb3B0YXJnIDs7CisKKyAgLXBk
ZmRpciB8IC0tcGRmZGlyIHwgLS1wZGZkaSB8IC0tcGRmZCB8IC0tcGRmIHwgLS1wZCkKKyAgICBh
Y19wcmV2PXBkZmRpciA7OworICAtcGRmZGlyPSogfCAtLXBkZmRpcj0qIHwgLS1wZGZkaT0qIHwg
LS1wZGZkPSogfCAtLXBkZj0qIHwgLS1wZD0qKQorICAgIHBkZmRpcj0kYWNfb3B0YXJnIDs7CisK
KyAgLXBzZGlyIHwgLS1wc2RpciB8IC0tcHNkaSB8IC0tcHNkIHwgLS1wcykKKyAgICBhY19wcmV2
PXBzZGlyIDs7CisgIC1wc2Rpcj0qIHwgLS1wc2Rpcj0qIHwgLS1wc2RpPSogfCAtLXBzZD0qIHwg
LS1wcz0qKQorICAgIHBzZGlyPSRhY19vcHRhcmcgOzsKKworICAtcSB8IC1xdWlldCB8IC0tcXVp
ZXQgfCAtLXF1aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVu
dCB8IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCkKKyAgICBzaWxlbnQ9eWVzIDs7CisKKyAgLXNi
aW5kaXIgfCAtLXNiaW5kaXIgfCAtLXNiaW5kaSB8IC0tc2JpbmQgfCAtLXNiaW4gfCAtLXNiaSB8
IC0tc2IpCisgICAgYWNfcHJldj1zYmluZGlyIDs7CisgIC1zYmluZGlyPSogfCAtLXNiaW5kaXI9
KiB8IC0tc2JpbmRpPSogfCAtLXNiaW5kPSogfCAtLXNiaW49KiBcCisgIHwgLS1zYmk9KiB8IC0t
c2I9KikKKyAgICBzYmluZGlyPSRhY19vcHRhcmcgOzsKKworICAtc2hhcmVkc3RhdGVkaXIgfCAt
LXNoYXJlZHN0YXRlZGlyIHwgLS1zaGFyZWRzdGF0ZWRpIFwKKyAgfCAtLXNoYXJlZHN0YXRlZCB8
IC0tc2hhcmVkc3RhdGUgfCAtLXNoYXJlZHN0YXQgfCAtLXNoYXJlZHN0YSBcCisgIHwgLS1zaGFy
ZWRzdCB8IC0tc2hhcmVkcyB8IC0tc2hhcmVkIHwgLS1zaGFyZSB8IC0tc2hhciBcCisgIHwgLS1z
aGEgfCAtLXNoKQorICAgIGFjX3ByZXY9c2hhcmVkc3RhdGVkaXIgOzsKKyAgLXNoYXJlZHN0YXRl
ZGlyPSogfCAtLXNoYXJlZHN0YXRlZGlyPSogfCAtLXNoYXJlZHN0YXRlZGk9KiBcCisgIHwgLS1z
aGFyZWRzdGF0ZWQ9KiB8IC0tc2hhcmVkc3RhdGU9KiB8IC0tc2hhcmVkc3RhdD0qIHwgLS1zaGFy
ZWRzdGE9KiBcCisgIHwgLS1zaGFyZWRzdD0qIHwgLS1zaGFyZWRzPSogfCAtLXNoYXJlZD0qIHwg
LS1zaGFyZT0qIHwgLS1zaGFyPSogXAorICB8IC0tc2hhPSogfCAtLXNoPSopCisgICAgc2hhcmVk
c3RhdGVkaXI9JGFjX29wdGFyZyA7OworCisgIC1zaXRlIHwgLS1zaXRlIHwgLS1zaXQpCisgICAg
YWNfcHJldj1zaXRlIDs7CisgIC1zaXRlPSogfCAtLXNpdGU9KiB8IC0tc2l0PSopCisgICAgc2l0
ZT0kYWNfb3B0YXJnIDs7CisKKyAgLXNyY2RpciB8IC0tc3JjZGlyIHwgLS1zcmNkaSB8IC0tc3Jj
ZCB8IC0tc3JjIHwgLS1zcikKKyAgICBhY19wcmV2PXNyY2RpciA7OworICAtc3JjZGlyPSogfCAt
LXNyY2Rpcj0qIHwgLS1zcmNkaT0qIHwgLS1zcmNkPSogfCAtLXNyYz0qIHwgLS1zcj0qKQorICAg
IHNyY2Rpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaXIgfCAt
LXN5c2NvbmZkaSB8IC0tc3lzY29uZmQgfCAtLXN5c2NvbmYgXAorICB8IC0tc3lzY29uIHwgLS1z
eXNjbyB8IC0tc3lzYyB8IC0tc3lzIHwgLS1zeSkKKyAgICBhY19wcmV2PXN5c2NvbmZkaXIgOzsK
KyAgLXN5c2NvbmZkaXI9KiB8IC0tc3lzY29uZmRpcj0qIHwgLS1zeXNjb25mZGk9KiB8IC0tc3lz
Y29uZmQ9KiB8IC0tc3lzY29uZj0qIFwKKyAgfCAtLXN5c2Nvbj0qIHwgLS1zeXNjbz0qIHwgLS1z
eXNjPSogfCAtLXN5cz0qIHwgLS1zeT0qKQorICAgIHN5c2NvbmZkaXI9JGFjX29wdGFyZyA7Owor
CisgIC10YXJnZXQgfCAtLXRhcmdldCB8IC0tdGFyZ2UgfCAtLXRhcmcgfCAtLXRhciB8IC0tdGEg
fCAtLXQpCisgICAgYWNfcHJldj10YXJnZXRfYWxpYXMgOzsKKyAgLXRhcmdldD0qIHwgLS10YXJn
ZXQ9KiB8IC0tdGFyZ2U9KiB8IC0tdGFyZz0qIHwgLS10YXI9KiB8IC0tdGE9KiB8IC0tdD0qKQor
ICAgIHRhcmdldF9hbGlhcz0kYWNfb3B0YXJnIDs7CisKKyAgLXYgfCAtdmVyYm9zZSB8IC0tdmVy
Ym9zZSB8IC0tdmVyYm9zIHwgLS12ZXJibyB8IC0tdmVyYikKKyAgICB2ZXJib3NlPXllcyA7Owor
CisgIC12ZXJzaW9uIHwgLS12ZXJzaW9uIHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwg
LVYpCisgICAgYWNfaW5pdF92ZXJzaW9uPTogOzsKKworICAtd2l0aC0qIHwgLS13aXRoLSopCisg
ICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19vcHRpb24iIDogJ3gtKndpdGgtXChbXj1dKlwpJ2AK
KyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFt
ZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4v
ZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHBhY2thZ2UgbmFtZTog
JGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNl
cm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNh
c2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJ3aXRoXyRhY191c2Vyb3B0IgorIiopIDs7
CisgICAgICAqKSBhY191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFj
X3VucmVjb2duaXplZF9zZXAtLXdpdGgtJGFjX3VzZXJvcHRfb3JpZyIKKwkgYWNfdW5yZWNvZ25p
emVkX3NlcD0nLCAnOzsKKyAgICBlc2FjCisgICAgZXZhbCB3aXRoXyRhY191c2Vyb3B0PVwkYWNf
b3B0YXJnIDs7CisKKyAgLXdpdGhvdXQtKiB8IC0td2l0aG91dC0qKQorICAgIGFjX3VzZXJvcHQ9
YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSp3aXRob3V0LVwoLipcKSdgCisgICAgIyBSZWplY3Qg
bmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIg
IngkYWNfdXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisg
ICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0Igor
ICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hv
ICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29w
dHMgaW4KKyAgICAgICoiCisid2l0aF8kYWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNf
dW5yZWNvZ25pemVkX29wdHM9IiRhY191bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRf
c2VwLS13aXRob3V0LSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9Jywg
Jzs7CisgICAgZXNhYworICAgIGV2YWwgd2l0aF8kYWNfdXNlcm9wdD1ubyA7OworCisgIC0teCkK
KyAgICAjIE9ic29sZXRlOyB1c2UgLS13aXRoLXguCisgICAgd2l0aF94PXllcyA7OworCisgIC14
LWluY2x1ZGVzIHwgLS14LWluY2x1ZGVzIHwgLS14LWluY2x1ZGUgfCAtLXgtaW5jbHVkIHwgLS14
LWluY2x1IFwKKyAgfCAtLXgtaW5jbCB8IC0teC1pbmMgfCAtLXgtaW4gfCAtLXgtaSkKKyAgICBh
Y19wcmV2PXhfaW5jbHVkZXMgOzsKKyAgLXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlcz0qIHwg
LS14LWluY2x1ZGU9KiB8IC0teC1pbmNsdWQ9KiB8IC0teC1pbmNsdT0qIFwKKyAgfCAtLXgtaW5j
bD0qIHwgLS14LWluYz0qIHwgLS14LWluPSogfCAtLXgtaT0qKQorICAgIHhfaW5jbHVkZXM9JGFj
X29wdGFyZyA7OworCisgIC14LWxpYnJhcmllcyB8IC0teC1saWJyYXJpZXMgfCAtLXgtbGlicmFy
aWUgfCAtLXgtbGlicmFyaSBcCisgIHwgLS14LWxpYnJhciB8IC0teC1saWJyYSB8IC0teC1saWJy
IHwgLS14LWxpYiB8IC0teC1saSB8IC0teC1sKQorICAgIGFjX3ByZXY9eF9saWJyYXJpZXMgOzsK
KyAgLXgtbGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWU9KiB8IC0t
eC1saWJyYXJpPSogXAorICB8IC0teC1saWJyYXI9KiB8IC0teC1saWJyYT0qIHwgLS14LWxpYnI9
KiB8IC0teC1saWI9KiB8IC0teC1saT0qIHwgLS14LWw9KikKKyAgICB4X2xpYnJhcmllcz0kYWNf
b3B0YXJnIDs7CisKKyAgLSopIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uOiBc
YCRhY19vcHRpb24nCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uIgorICAg
IDs7CisKKyAgKj0qKQorICAgIGFjX2VudnZhcj1gZXhwciAieCRhY19vcHRpb24iIDogJ3hcKFte
PV0qXCk9J2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFy
aWFibGUgbmFtZXMuCisgICAgY2FzZSAkYWNfZW52dmFyIGluICMoCisgICAgICAnJyB8IFswLTld
KiB8ICpbIV8kYXNfY3JfYWxudW1dKiApCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2
YXJpYWJsZSBuYW1lOiBcYCRhY19lbnZ2YXInIiA7OworICAgIGVzYWMKKyAgICBldmFsICRhY19l
bnZ2YXI9XCRhY19vcHRhcmcKKyAgICBleHBvcnQgJGFjX2VudnZhciA7OworCisgICopCisgICAg
IyBGSVhNRTogc2hvdWxkIGJlIHJlbW92ZWQgaW4gYXV0b2NvbmYgMy4wLgorICAgICRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHlvdSBzaG91bGQgdXNlIC0tYnVpbGQsIC0taG9zdCwgLS10YXJn
ZXQiID4mMgorICAgIGV4cHIgIngkYWNfb3B0aW9uIiA6ICIuKlteLS5fJGFzX2NyX2FsbnVtXSIg
Pi9kZXYvbnVsbCAmJgorICAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaW52YWxpZCBo
b3N0IHR5cGU6ICRhY19vcHRpb24iID4mMgorICAgIDogIiR7YnVpbGRfYWxpYXM9JGFjX29wdGlv
bn0gJHtob3N0X2FsaWFzPSRhY19vcHRpb259ICR7dGFyZ2V0X2FsaWFzPSRhY19vcHRpb259Igor
ICAgIDs7CisKKyAgZXNhYworZG9uZQorCitpZiB0ZXN0IC1uICIkYWNfcHJldiI7IHRoZW4KKyAg
YWNfb3B0aW9uPS0tYGVjaG8gJGFjX3ByZXYgfCBzZWQgJ3MvXy8tL2cnYAorICBhc19mbl9lcnJv
ciAkPyAibWlzc2luZyBhcmd1bWVudCB0byAkYWNfb3B0aW9uIgorZmkKKworaWYgdGVzdCAtbiAi
JGFjX3VucmVjb2duaXplZF9vcHRzIjsgdGhlbgorICBjYXNlICRlbmFibGVfb3B0aW9uX2NoZWNr
aW5nIGluCisgICAgbm8pIDs7CisgICAgZmF0YWwpIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6
ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXplZF9vcHRzIiA7OworICAgICopICAgICAkYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiB1bnJlY29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXpl
ZF9vcHRzIiA+JjIgOzsKKyAgZXNhYworZmkKKworIyBDaGVjayBhbGwgZGlyZWN0b3J5IGFyZ3Vt
ZW50cyBmb3IgY29uc2lzdGVuY3kuCitmb3IgYWNfdmFyIGluCWV4ZWNfcHJlZml4IHByZWZpeCBi
aW5kaXIgc2JpbmRpciBsaWJleGVjZGlyIGRhdGFyb290ZGlyIFwKKwkJZGF0YWRpciBzeXNjb25m
ZGlyIHNoYXJlZHN0YXRlZGlyIGxvY2Fsc3RhdGVkaXIgaW5jbHVkZWRpciBcCisJCW9sZGluY2x1
ZGVkaXIgZG9jZGlyIGluZm9kaXIgaHRtbGRpciBkdmlkaXIgcGRmZGlyIHBzZGlyIFwKKwkJbGli
ZGlyIGxvY2FsZWRpciBtYW5kaXIKK2RvCisgIGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAjIFJl
bW92ZSB0cmFpbGluZyBzbGFzaGVzLgorICBjYXNlICRhY192YWwgaW4KKyAgICAqLyApCisgICAg
ICBhY192YWw9YGV4cHIgIlgkYWNfdmFsIiA6ICdYXCguKlteL11cKScgXHwgIlgkYWNfdmFsIiA6
ICdYXCguKlwpJ2AKKyAgICAgIGV2YWwgJGFjX3Zhcj1cJGFjX3ZhbDs7CisgIGVzYWMKKyAgIyBC
ZSBzdXJlIHRvIGhhdmUgYWJzb2x1dGUgZGlyZWN0b3J5IG5hbWVzLgorICBjYXNlICRhY192YWwg
aW4KKyAgICBbXFwvJF0qIHwgPzpbXFwvXSogKSAgY29udGludWU7OworICAgIE5PTkUgfCAnJyAp
IGNhc2UgJGFjX3ZhciBpbiAqcHJlZml4ICkgY29udGludWU7OyBlc2FjOzsKKyAgZXNhYworICBh
c19mbl9lcnJvciAkPyAiZXhwZWN0ZWQgYW4gYWJzb2x1dGUgZGlyZWN0b3J5IG5hbWUgZm9yIC0t
JGFjX3ZhcjogJGFjX3ZhbCIKK2RvbmUKKworIyBUaGVyZSBtaWdodCBiZSBwZW9wbGUgd2hvIGRl
cGVuZCBvbiB0aGUgb2xkIGJyb2tlbiBiZWhhdmlvcjogYCRob3N0JworIyB1c2VkIHRvIGhvbGQg
dGhlIGFyZ3VtZW50IG9mIC0taG9zdCBldGMuCisjIEZJWE1FOiBUbyByZW1vdmUgc29tZSBkYXku
CitidWlsZD0kYnVpbGRfYWxpYXMKK2hvc3Q9JGhvc3RfYWxpYXMKK3RhcmdldD0kdGFyZ2V0X2Fs
aWFzCisKKyMgRklYTUU6IFRvIHJlbW92ZSBzb21lIGRheS4KK2lmIHRlc3QgIngkaG9zdF9hbGlh
cyIgIT0geDsgdGhlbgorICBpZiB0ZXN0ICJ4JGJ1aWxkX2FsaWFzIiA9IHg7IHRoZW4KKyAgICBj
cm9zc19jb21waWxpbmc9bWF5YmUKKyAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBpZiB5
b3Ugd2FudGVkIHRvIHNldCB0aGUgLS1idWlsZCB0eXBlLCBkb24ndCB1c2UgLS1ob3N0LgorICAg
IElmIGEgY3Jvc3MgY29tcGlsZXIgaXMgZGV0ZWN0ZWQgdGhlbiBjcm9zcyBjb21waWxlIG1vZGUg
d2lsbCBiZSB1c2VkIiA+JjIKKyAgZWxpZiB0ZXN0ICJ4JGJ1aWxkX2FsaWFzIiAhPSAieCRob3N0
X2FsaWFzIjsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGluZz15ZXMKKyAgZmkKK2ZpCisKK2FjX3Rv
b2xfcHJlZml4PQordGVzdCAtbiAiJGhvc3RfYWxpYXMiICYmIGFjX3Rvb2xfcHJlZml4PSRob3N0
X2FsaWFzLQorCit0ZXN0ICIkc2lsZW50IiA9IHllcyAmJiBleGVjIDY+L2Rldi9udWxsCisKKwor
YWNfcHdkPWBwd2RgICYmIHRlc3QgLW4gIiRhY19wd2QiICYmCithY19sc19kaT1gbHMgLWRpIC5g
ICYmCithY19wd2RfbHNfZGk9YGNkICIkYWNfcHdkIiAmJiBscyAtZGkgLmAgfHwKKyAgYXNfZm5f
ZXJyb3IgJD8gIndvcmtpbmcgZGlyZWN0b3J5IGNhbm5vdCBiZSBkZXRlcm1pbmVkIgordGVzdCAi
WCRhY19sc19kaSIgPSAiWCRhY19wd2RfbHNfZGkiIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJwd2Qg
ZG9lcyBub3QgcmVwb3J0IG5hbWUgb2Ygd29ya2luZyBkaXJlY3RvcnkiCisKKworIyBGaW5kIHRo
ZSBzb3VyY2UgZmlsZXMsIGlmIGxvY2F0aW9uIHdhcyBub3Qgc3BlY2lmaWVkLgoraWYgdGVzdCAt
eiAiJHNyY2RpciI7IHRoZW4KKyAgYWNfc3JjZGlyX2RlZmF1bHRlZD15ZXMKKyAgIyBUcnkgdGhl
IGRpcmVjdG9yeSBjb250YWluaW5nIHRoaXMgc2NyaXB0LCB0aGVuIHRoZSBwYXJlbnQgZGlyZWN0
b3J5LgorICBhY19jb25mZGlyPWAkYXNfZGlybmFtZSAtLSAiJGFzX215c2VsZiIgfHwKKyRhc19l
eHByIFgiJGFzX215c2VsZiIgOiAnWFwoLipbXi9dXCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkg
WCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wpW14vXScgXHwgXAorCSBYIiRhc19teXNlbGYiIDogJ1hc
KC8vXCkkJyBcfCBcCisJIFgiJGFzX215c2VsZiIgOiAnWFwoL1wpJyBcfCAuIDI+L2Rldi9udWxs
IHx8CiskYXNfZWNobyBYIiRhc19teXNlbGYiIHwKKyAgICBzZWQgJy9eWFwoLipbXi9dXClcL1wv
KlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wv
XClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wvXCkkL3sK
KwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cKS4qL3sKKwkgICAgcy8vXDEv
CisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICBzcmNkaXI9JGFjX2NvbmZkaXIKKyAg
aWYgdGVzdCAhIC1yICIkc3JjZGlyLyRhY191bmlxdWVfZmlsZSI7IHRoZW4KKyAgICBzcmNkaXI9
Li4KKyAgZmkKK2Vsc2UKKyAgYWNfc3JjZGlyX2RlZmF1bHRlZD1ubworZmkKK2lmIHRlc3QgISAt
ciAiJHNyY2Rpci8kYWNfdW5pcXVlX2ZpbGUiOyB0aGVuCisgIHRlc3QgIiRhY19zcmNkaXJfZGVm
YXVsdGVkIiA9IHllcyAmJiBzcmNkaXI9IiRhY19jb25mZGlyIG9yIC4uIgorICBhc19mbl9lcnJv
ciAkPyAiY2Fubm90IGZpbmQgc291cmNlcyAoJGFjX3VuaXF1ZV9maWxlKSBpbiAkc3JjZGlyIgor
ZmkKK2FjX21zZz0ic291cmNlcyBhcmUgaW4gJHNyY2RpciwgYnV0IFxgY2QgJHNyY2RpcicgZG9l
cyBub3Qgd29yayIKK2FjX2Fic19jb25mZGlyPWAoCisJY2QgIiRzcmNkaXIiICYmIHRlc3QgLXIg
Ii4vJGFjX3VuaXF1ZV9maWxlIiB8fCBhc19mbl9lcnJvciAkPyAiJGFjX21zZyIKKwlwd2QpYAor
IyBXaGVuIGJ1aWxkaW5nIGluIHBsYWNlLCBzZXQgc3JjZGlyPS4KK2lmIHRlc3QgIiRhY19hYnNf
Y29uZmRpciIgPSAiJGFjX3B3ZCI7IHRoZW4KKyAgc3JjZGlyPS4KK2ZpCisjIFJlbW92ZSB1bm5l
Y2Vzc2FyeSB0cmFpbGluZyBzbGFzaGVzIGZyb20gc3JjZGlyLgorIyBEb3VibGUgc2xhc2hlcyBp
biBmaWxlIG5hbWVzIGluIG9iamVjdCBmaWxlIGRlYnVnZ2luZyBpbmZvCisjIG1lc3MgdXAgTS14
IGdkYiBpbiBFbWFjcy4KK2Nhc2UgJHNyY2RpciBpbgorKi8pIHNyY2Rpcj1gZXhwciAiWCRzcmNk
aXIiIDogJ1hcKC4qW14vXVwpJyBcfCAiWCRzcmNkaXIiIDogJ1hcKC4qXCknYDs7Citlc2FjCitm
b3IgYWNfdmFyIGluICRhY19wcmVjaW91c192YXJzOyBkbworICBldmFsIGFjX2Vudl8ke2FjX3Zh
cn1fc2V0PVwkeyR7YWNfdmFyfStzZXR9CisgIGV2YWwgYWNfZW52XyR7YWNfdmFyfV92YWx1ZT1c
JCR7YWNfdmFyfQorICBldmFsIGFjX2N2X2Vudl8ke2FjX3Zhcn1fc2V0PVwkeyR7YWNfdmFyfStz
ZXR9CisgIGV2YWwgYWNfY3ZfZW52XyR7YWNfdmFyfV92YWx1ZT1cJCR7YWNfdmFyfQorZG9uZQor
CisjCisjIFJlcG9ydCB0aGUgLS1oZWxwIG1lc3NhZ2UuCisjCitpZiB0ZXN0ICIkYWNfaW5pdF9o
ZWxwIiA9ICJsb25nIjsgdGhlbgorICAjIE9taXQgc29tZSBpbnRlcm5hbCBvciBvYnNvbGV0ZSBv
cHRpb25zIHRvIG1ha2UgdGhlIGxpc3QgbGVzcyBpbXBvc2luZy4KKyAgIyBUaGlzIG1lc3NhZ2Ug
aXMgdG9vIGxvbmcgdG8gYmUgYSBzdHJpbmcgaW4gdGhlIEEvVVggMy4xIHNoLgorICBjYXQgPDxf
QUNFT0YKK1xgY29uZmlndXJlJyBjb25maWd1cmVzIFhlbiBIeXBlcnZpc29yIDQuMiB0byBhZGFw
dCB0byBtYW55IGtpbmRzIG9mIHN5c3RlbXMuCisKK1VzYWdlOiAkMCBbT1BUSU9OXS4uLiBbVkFS
PVZBTFVFXS4uLgorCitUbyBhc3NpZ24gZW52aXJvbm1lbnQgdmFyaWFibGVzIChlLmcuLCBDQywg
Q0ZMQUdTLi4uKSwgc3BlY2lmeSB0aGVtIGFzCitWQVI9VkFMVUUuICBTZWUgYmVsb3cgZm9yIGRl
c2NyaXB0aW9ucyBvZiBzb21lIG9mIHRoZSB1c2VmdWwgdmFyaWFibGVzLgorCitEZWZhdWx0cyBm
b3IgdGhlIG9wdGlvbnMgYXJlIHNwZWNpZmllZCBpbiBicmFja2V0cy4KKworQ29uZmlndXJhdGlv
bjoKKyAgLWgsIC0taGVscCAgICAgICAgICAgICAgZGlzcGxheSB0aGlzIGhlbHAgYW5kIGV4aXQK
KyAgICAgIC0taGVscD1zaG9ydCAgICAgICAgZGlzcGxheSBvcHRpb25zIHNwZWNpZmljIHRvIHRo
aXMgcGFja2FnZQorICAgICAgLS1oZWxwPXJlY3Vyc2l2ZSAgICBkaXNwbGF5IHRoZSBzaG9ydCBo
ZWxwIG9mIGFsbCB0aGUgaW5jbHVkZWQgcGFja2FnZXMKKyAgLVYsIC0tdmVyc2lvbiAgICAgICAg
ICAgZGlzcGxheSB2ZXJzaW9uIGluZm9ybWF0aW9uIGFuZCBleGl0CisgIC1xLCAtLXF1aWV0LCAt
LXNpbGVudCAgIGRvIG5vdCBwcmludCBcYGNoZWNraW5nIC4uLicgbWVzc2FnZXMKKyAgICAgIC0t
Y2FjaGUtZmlsZT1GSUxFICAgY2FjaGUgdGVzdCByZXN1bHRzIGluIEZJTEUgW2Rpc2FibGVkXQor
ICAtQywgLS1jb25maWctY2FjaGUgICAgICBhbGlhcyBmb3IgXGAtLWNhY2hlLWZpbGU9Y29uZmln
LmNhY2hlJworICAtbiwgLS1uby1jcmVhdGUgICAgICAgICBkbyBub3QgY3JlYXRlIG91dHB1dCBm
aWxlcworICAgICAgLS1zcmNkaXI9RElSICAgICAgICBmaW5kIHRoZSBzb3VyY2VzIGluIERJUiBb
Y29uZmlndXJlIGRpciBvciBcYC4uJ10KKworSW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVzOgorICAt
LXByZWZpeD1QUkVGSVggICAgICAgICBpbnN0YWxsIGFyY2hpdGVjdHVyZS1pbmRlcGVuZGVudCBm
aWxlcyBpbiBQUkVGSVgKKyAgICAgICAgICAgICAgICAgICAgICAgICAgWyRhY19kZWZhdWx0X3By
ZWZpeF0KKyAgLS1leGVjLXByZWZpeD1FUFJFRklYICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtZGVw
ZW5kZW50IGZpbGVzIGluIEVQUkVGSVgKKyAgICAgICAgICAgICAgICAgICAgICAgICAgW1BSRUZJ
WF0KKworQnkgZGVmYXVsdCwgXGBtYWtlIGluc3RhbGwnIHdpbGwgaW5zdGFsbCBhbGwgdGhlIGZp
bGVzIGluCitcYCRhY19kZWZhdWx0X3ByZWZpeC9iaW4nLCBcYCRhY19kZWZhdWx0X3ByZWZpeC9s
aWInIGV0Yy4gIFlvdSBjYW4gc3BlY2lmeQorYW4gaW5zdGFsbGF0aW9uIHByZWZpeCBvdGhlciB0
aGFuIFxgJGFjX2RlZmF1bHRfcHJlZml4JyB1c2luZyBcYC0tcHJlZml4JywKK2ZvciBpbnN0YW5j
ZSBcYC0tcHJlZml4PVwkSE9NRScuCisKK0ZvciBiZXR0ZXIgY29udHJvbCwgdXNlIHRoZSBvcHRp
b25zIGJlbG93LgorCitGaW5lIHR1bmluZyBvZiB0aGUgaW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVz
OgorICAtLWJpbmRpcj1ESVIgICAgICAgICAgICB1c2VyIGV4ZWN1dGFibGVzIFtFUFJFRklYL2Jp
bl0KKyAgLS1zYmluZGlyPURJUiAgICAgICAgICAgc3lzdGVtIGFkbWluIGV4ZWN1dGFibGVzIFtF
UFJFRklYL3NiaW5dCisgIC0tbGliZXhlY2Rpcj1ESVIgICAgICAgIHByb2dyYW0gZXhlY3V0YWJs
ZXMgW0VQUkVGSVgvbGliZXhlY10KKyAgLS1zeXNjb25mZGlyPURJUiAgICAgICAgcmVhZC1vbmx5
IHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BSRUZJWC9ldGNdCisgIC0tc2hhcmVkc3RhdGVkaXI9RElS
ICAgIG1vZGlmaWFibGUgYXJjaGl0ZWN0dXJlLWluZGVwZW5kZW50IGRhdGEgW1BSRUZJWC9jb21d
CisgIC0tbG9jYWxzdGF0ZWRpcj1ESVIgICAgIG1vZGlmaWFibGUgc2luZ2xlLW1hY2hpbmUgZGF0
YSBbUFJFRklYL3Zhcl0KKyAgLS1saWJkaXI9RElSICAgICAgICAgICAgb2JqZWN0IGNvZGUgbGli
cmFyaWVzIFtFUFJFRklYL2xpYl0KKyAgLS1pbmNsdWRlZGlyPURJUiAgICAgICAgQyBoZWFkZXIg
ZmlsZXMgW1BSRUZJWC9pbmNsdWRlXQorICAtLW9sZGluY2x1ZGVkaXI9RElSICAgICBDIGhlYWRl
ciBmaWxlcyBmb3Igbm9uLWdjYyBbL3Vzci9pbmNsdWRlXQorICAtLWRhdGFyb290ZGlyPURJUiAg
ICAgICByZWFkLW9ubHkgYXJjaC4taW5kZXBlbmRlbnQgZGF0YSByb290IFtQUkVGSVgvc2hhcmVd
CisgIC0tZGF0YWRpcj1ESVIgICAgICAgICAgIHJlYWQtb25seSBhcmNoaXRlY3R1cmUtaW5kZXBl
bmRlbnQgZGF0YSBbREFUQVJPT1RESVJdCisgIC0taW5mb2Rpcj1ESVIgICAgICAgICAgIGluZm8g
ZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RESVIvaW5mb10KKyAgLS1sb2NhbGVkaXI9RElSICAgICAg
ICAgbG9jYWxlLWRlcGVuZGVudCBkYXRhIFtEQVRBUk9PVERJUi9sb2NhbGVdCisgIC0tbWFuZGly
PURJUiAgICAgICAgICAgIG1hbiBkb2N1bWVudGF0aW9uIFtEQVRBUk9PVERJUi9tYW5dCisgIC0t
ZG9jZGlyPURJUiAgICAgICAgICAgIGRvY3VtZW50YXRpb24gcm9vdCBbREFUQVJPT1RESVIvZG9j
L3hlbi1oeXBlcnZpc29yXQorICAtLWh0bWxkaXI9RElSICAgICAgICAgICBodG1sIGRvY3VtZW50
YXRpb24gW0RPQ0RJUl0KKyAgLS1kdmlkaXI9RElSICAgICAgICAgICAgZHZpIGRvY3VtZW50YXRp
b24gW0RPQ0RJUl0KKyAgLS1wZGZkaXI9RElSICAgICAgICAgICAgcGRmIGRvY3VtZW50YXRpb24g
W0RPQ0RJUl0KKyAgLS1wc2Rpcj1ESVIgICAgICAgICAgICAgcHMgZG9jdW1lbnRhdGlvbiBbRE9D
RElSXQorX0FDRU9GCisKKyAgY2F0IDw8XF9BQ0VPRgorCitTeXN0ZW0gdHlwZXM6CisgIC0tYnVp
bGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBmb3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCisg
IC0taG9zdD1IT1NUICAgICAgIGNyb3NzLWNvbXBpbGUgdG8gYnVpbGQgcHJvZ3JhbXMgdG8gcnVu
IG9uIEhPU1QgW0JVSUxEXQorX0FDRU9GCitmaQorCitpZiB0ZXN0IC1uICIkYWNfaW5pdF9oZWxw
IjsgdGhlbgorICBjYXNlICRhY19pbml0X2hlbHAgaW4KKyAgICAgc2hvcnQgfCByZWN1cnNpdmUg
KSBlY2hvICJDb25maWd1cmF0aW9uIG9mIFhlbiBIeXBlcnZpc29yIDQuMjoiOzsKKyAgIGVzYWMK
KyAgY2F0IDw8XF9BQ0VPRgorCitPcHRpb25hbCBGZWF0dXJlczoKKyAgLS1kaXNhYmxlLW9wdGlv
bi1jaGVja2luZyAgaWdub3JlIHVucmVjb2duaXplZCAtLWVuYWJsZS8tLXdpdGggb3B0aW9ucwor
ICAtLWRpc2FibGUtRkVBVFVSRSAgICAgICBkbyBub3QgaW5jbHVkZSBGRUFUVVJFIChzYW1lIGFz
IC0tZW5hYmxlLUZFQVRVUkU9bm8pCisgIC0tZW5hYmxlLUZFQVRVUkVbPUFSR10gIGluY2x1ZGUg
RkVBVFVSRSBbQVJHPXllc10KKyAgLS1lbmFibGUteHNtICAgICAgICAgICAgRW5hYmxlIFhTTSBz
ZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKQorICAtLWVuYWJsZS1naXRodHRwICAg
ICAgICBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQCisgIC0tZGlzYWJsZS1tb25p
dG9ycyAgICAgIERpc2FibGUgeGVuc3RhdCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHMKKyAg
LS1lbmFibGUtdnRwbSAgICAgICAgICAgRW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9ybSBN
b2R1bGUKKyAgLS1lbmFibGUteGFwaSAgICAgICAgICAgRW5hYmxlIFhlbiBBUEkgQmluZGluZ3MK
KyAgLS1kaXNhYmxlLXB5dGhvbnRvb2xzICAgRGlzYWJsZSBQeXRob24gdG9vbHMKKyAgLS1kaXNh
YmxlLW9jYW1sdG9vbHMgICAgRGlzYWJsZSBPY2FtbCB0b29scworICAtLWVuYWJsZS1taW5pdGVy
bSAgICAgICBFbmFibGUgbWluaXRlcm0KKyAgLS1lbmFibGUtbG9tb3VudCAgICAgICAgRW5hYmxl
IGxvbW91bnQKKyAgLS1kaXNhYmxlLWRlYnVnICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBv
ZiBYZW4gYW5kIHRvb2xzCisKK1NvbWUgaW5mbHVlbnRpYWwgZW52aXJvbm1lbnQgdmFyaWFibGVz
OgorICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQKKyAgQ0ZMQUdTICAgICAgQyBjb21w
aWxlciBmbGFncworICBMREZMQUdTICAgICBsaW5rZXIgZmxhZ3MsIGUuZy4gLUw8bGliIGRpcj4g
aWYgeW91IGhhdmUgbGlicmFyaWVzIGluIGEKKyAgICAgICAgICAgICAgbm9uc3RhbmRhcmQgZGly
ZWN0b3J5IDxsaWIgZGlyPgorICBMSUJTICAgICAgICBsaWJyYXJpZXMgdG8gcGFzcyB0byB0aGUg
bGlua2VyLCBlLmcuIC1sPGxpYnJhcnk+CisgIENQUEZMQUdTICAgIChPYmplY3RpdmUpIEMvQysr
IHByZXByb2Nlc3NvciBmbGFncywgZS5nLiAtSTxpbmNsdWRlIGRpcj4gaWYKKyAgICAgICAgICAg
ICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBk
aXI+CisgIENQUCAgICAgICAgIEMgcHJlcHJvY2Vzc29yCisgIFBSRVBFTkRfSU5DTFVERVMKKyAg
ICAgICAgICAgICAgTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1Mg
KHdpdGhvdXQgLUkpCisgIFBSRVBFTkRfTElCIExpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIHBy
ZXBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCkKKyAgQVBQRU5EX0lOQ0xVREVTCisgICAgICAg
ICAgICAgIExpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhv
dXQgLUkpCisgIEFQUEVORF9MSUIgIExpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFwcGVuZCB0
byBMREZMQUdTICh3aXRob3V0IC1MKQorICBQWVRIT04gICAgICBQYXRoIHRvIHRoZSBQeXRob24g
cGFyc2VyCisgIFBFUkwgICAgICAgIFBhdGggdG8gUGVybCBwYXJzZXIKKyAgQlJDVEwgICAgICAg
UGF0aCB0byBicmN0bCB0b29sCisgIElQICAgICAgICAgIFBhdGggdG8gaXAgdG9vbAorICBCSVNP
TiAgICAgICBQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3IKKyAgRkxFWCAgICAgICAgUGF0
aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9yCisgIENVUkwgICAgICAgIFBhdGgg
dG8gY3VybC1jb25maWcgdG9vbAorICBYTUwgICAgICAgICBQYXRoIHRvIHhtbDItY29uZmlnIHRv
b2wKKyAgQkFTSCAgICAgICAgUGF0aCB0byBiYXNoIHNoZWxsCisgIFhHRVRURVhUICAgIFBhdGgg
dG8geGdldHR0ZXh0IHRvb2wKKyAgUEtHX0NPTkZJRyAgcGF0aCB0byBwa2ctY29uZmlnIHV0aWxp
dHkKKyAgUEtHX0NPTkZJR19QQVRICisgICAgICAgICAgICAgIGRpcmVjdG9yaWVzIHRvIGFkZCB0
byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGgKKyAgUEtHX0NPTkZJR19MSUJESVIKKyAgICAgICAg
ICAgICAgcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBidWlsdC1pbiBzZWFyY2ggcGF0aAor
ICBnbGliX0NGTEFHUyBDIGNvbXBpbGVyIGZsYWdzIGZvciBnbGliLCBvdmVycmlkaW5nIHBrZy1j
b25maWcKKyAgZ2xpYl9MSUJTICAgbGlua2VyIGZsYWdzIGZvciBnbGliLCBvdmVycmlkaW5nIHBr
Zy1jb25maWcKKworVXNlIHRoZXNlIHZhcmlhYmxlcyB0byBvdmVycmlkZSB0aGUgY2hvaWNlcyBt
YWRlIGJ5IGBjb25maWd1cmUnIG9yIHRvIGhlbHAKK2l0IHRvIGZpbmQgbGlicmFyaWVzIGFuZCBw
cm9ncmFtcyB3aXRoIG5vbnN0YW5kYXJkIG5hbWVzL2xvY2F0aW9ucy4KKworUmVwb3J0IGJ1Z3Mg
dG8gPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPi4KK19BQ0VPRgorYWNfc3RhdHVzPSQ/
CitmaQorCitpZiB0ZXN0ICIkYWNfaW5pdF9oZWxwIiA9ICJyZWN1cnNpdmUiOyB0aGVuCisgICMg
SWYgdGhlcmUgYXJlIHN1YmRpcnMsIHJlcG9ydCB0aGVpciBzcGVjaWZpYyAtLWhlbHAuCisgIGZv
ciBhY19kaXIgaW4gOiAkYWNfc3ViZGlyc19hbGw7IGRvIHRlc3QgIngkYWNfZGlyIiA9IHg6ICYm
IGNvbnRpbnVlCisgICAgdGVzdCAtZCAiJGFjX2RpciIgfHwKKyAgICAgIHsgY2QgIiRzcmNkaXIi
ICYmIGFjX3B3ZD1gcHdkYCAmJiBzcmNkaXI9LiAmJiB0ZXN0IC1kICIkYWNfZGlyIjsgfSB8fAor
ICAgICAgY29udGludWUKKyAgICBhY19idWlsZGRpcj0uCisKK2Nhc2UgIiRhY19kaXIiIGluCisu
KSBhY19kaXJfc3VmZml4PSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZp
eD0gOzsKKyopCisgIGFjX2Rpcl9zdWZmaXg9L2AkYXNfZWNobyAiJGFjX2RpciIgfCBzZWQgJ3N8
XlwuW1xcL118fCdgCisgICMgQSAiLi4iIGZvciBlYWNoIGRpcmVjdG9yeSBpbiAkYWNfZGlyX3N1
ZmZpeC4KKyAgYWNfdG9wX2J1aWxkZGlyX3N1Yj1gJGFzX2VjaG8gIiRhY19kaXJfc3VmZml4IiB8
IHNlZCAnc3wvW15cXC9dKnwvLi58ZztzfC98fCdgCisgIGNhc2UgJGFjX3RvcF9idWlsZGRpcl9z
dWIgaW4KKyAgIiIpIGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4PSA7
OworICAqKSAgYWNfdG9wX2J1aWxkX3ByZWZpeD0kYWNfdG9wX2J1aWxkZGlyX3N1Yi8gOzsKKyAg
ZXNhYyA7OworZXNhYworYWNfYWJzX3RvcF9idWlsZGRpcj0kYWNfcHdkCithY19hYnNfYnVpbGRk
aXI9JGFjX3B3ZCRhY19kaXJfc3VmZml4CisjIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Ogor
YWNfdG9wX2J1aWxkZGlyPSRhY190b3BfYnVpbGRfcHJlZml4CisKK2Nhc2UgJHNyY2RpciBpbgor
ICAuKSAgIyBXZSBhcmUgYnVpbGRpbmcgaW4gcGxhY2UuCisgICAgYWNfc3JjZGlyPS4KKyAgICBh
Y190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRkaXJfc3ViCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9
JGFjX3B3ZCA7OworICBbXFwvXSogfCA/OltcXC9dKiApICAjIEFic29sdXRlIG5hbWUuCisgICAg
YWNfc3JjZGlyPSRzcmNkaXIkYWNfZGlyX3N1ZmZpeDsKKyAgICBhY190b3Bfc3JjZGlyPSRzcmNk
aXIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0kc3JjZGlyIDs7CisgICopICMgUmVsYXRpdmUgbmFt
ZS4KKyAgICBhY19zcmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyJGFjX2Rpcl9zdWZm
aXgKKyAgICBhY190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpcgorICAgIGFj
X2Fic190b3Bfc3JjZGlyPSRhY19wd2QvJHNyY2RpciA7OworZXNhYworYWNfYWJzX3NyY2Rpcj0k
YWNfYWJzX3RvcF9zcmNkaXIkYWNfZGlyX3N1ZmZpeAorCisgICAgY2QgIiRhY19kaXIiIHx8IHsg
YWNfc3RhdHVzPSQ/OyBjb250aW51ZTsgfQorICAgICMgQ2hlY2sgZm9yIGd1ZXN0ZWQgY29uZmln
dXJlLgorICAgIGlmIHRlc3QgLWYgIiRhY19zcmNkaXIvY29uZmlndXJlLmdudSI7IHRoZW4KKyAg
ICAgIGVjaG8gJiYKKyAgICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUuZ251IiAtLWhl
bHA9cmVjdXJzaXZlCisgICAgZWxpZiB0ZXN0IC1mICIkYWNfc3JjZGlyL2NvbmZpZ3VyZSI7IHRo
ZW4KKyAgICAgIGVjaG8gJiYKKyAgICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUiIC0t
aGVscD1yZWN1cnNpdmUKKyAgICBlbHNlCisgICAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiBubyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGlzIGluICRhY19kaXIiID4mMgorICAgIGZp
IHx8IGFjX3N0YXR1cz0kPworICAgIGNkICIkYWNfcHdkIiB8fCB7IGFjX3N0YXR1cz0kPzsgYnJl
YWs7IH0KKyAgZG9uZQorZmkKKwordGVzdCAtbiAiJGFjX2luaXRfaGVscCIgJiYgZXhpdCAkYWNf
c3RhdHVzCitpZiAkYWNfaW5pdF92ZXJzaW9uOyB0aGVuCisgIGNhdCA8PFxfQUNFT0YKK1hlbiBI
eXBlcnZpc29yIGNvbmZpZ3VyZSA0LjIKK2dlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OAor
CitDb3B5cmlnaHQgKEMpIDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCitUaGlz
IGNvbmZpZ3VyZSBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbgorZ2l2ZXMgdW5saW1pdGVkIHBlcm1pc3Npb24gdG8gY29weSwgZGlzdHJpYnV0ZSBh
bmQgbW9kaWZ5IGl0LgorX0FDRU9GCisgIGV4aXQKK2ZpCisKKyMjIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSAjIworIyMgQXV0b2NvbmYgaW5pdGlhbGl6YXRpb24uICMjCisjIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gIyMKKworIyBhY19mbl9jX3RyeV9jb21waWxlIExJTkVOTworIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gY29tcGlsZSBjb25mdGVzdC4kYWNfZXh0
LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19mbl9jX3RyeV9jb21waWxl
ICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf
bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29uZnRlc3QuJGFjX29iamV4
dAorICBpZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAg
KlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9l
Y2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9
ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPmNvbmZ0ZXN0LmVycgorICBhY19zdGF0dXM9
JD8KKyAgaWYgdGVzdCAtcyBjb25mdGVzdC5lcnI7IHRoZW4KKyAgICBncmVwIC12ICdeICorJyBj
b25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1CisgICAg
bXYgLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICBmaQorICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfSAmJiB7CisJIHRlc3QgLXogIiRhY19jX3dlcnJvcl9mbGFnIiB8fAorCSB0
ZXN0ICEgLXMgY29uZnRlc3QuZXJyCisgICAgICAgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LiRhY19v
YmpleHQ7IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBm
YWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+
JjUKKworCWFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGlu
ZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0
dmFsCisKK30gIyBhY19mbl9jX3RyeV9jb21waWxlCisKKyMgYWNfZm5fY190cnlfY3BwIExJTkVO
TworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyeSB0byBwcmVwcm9jZXNzIGNvbmZ0ZXN0
LiRhY19leHQsIGFuZCByZXR1cm4gd2hldGhlciB0aGlzIHN1Y2NlZWRlZC4KK2FjX2ZuX2NfdHJ5
X2NwcCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNr
PWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIHsgeyBhY190cnk9IiRhY19j
cHAgY29uZnRlc3QuJGFjX2V4dCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCog
fCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7
OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZh
bCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVz
PSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycg
Y29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAg
IG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFj
X3N0YXR1cyA9IDA7IH0gPiBjb25mdGVzdC5pICYmIHsKKwkgdGVzdCAteiAiJGFjX2NfcHJlcHJv
Y193YXJuX2ZsYWckYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVy
cgorICAgICAgIH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFz
X21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFj
X2V4dCA+JjUKKworICAgIGFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7
ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1
cyAkYWNfcmV0dmFsCisKK30gIyBhY19mbl9jX3RyeV9jcHAKKworIyBhY19mbl9jX2NoZWNrX2hl
YWRlcl9tb25ncmVsIExJTkVOTyBIRUFERVIgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhl
ciBIRUFERVIgZXhpc3RzLCBnaXZpbmcgYSB3YXJuaW5nIGlmIGl0IGNhbm5vdCBiZSBjb21waWxl
ZCB1c2luZworIyB0aGUgaW5jbHVkZSBmaWxlcyBpbiBJTkNMVURFUyBhbmQgc2V0dGluZyB0aGUg
Y2FjaGUgdmFyaWFibGUgVkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19oZWFkZXJf
bW9uZ3JlbCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0
YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIGV2YWwgXCR7JDMrOn0g
ZmFsc2U7IHRoZW4gOgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+
JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8g
IiRhY19yZXMiID4mNjsgfQorZWxzZQorICAjIElzIHRoZSBoZWFkZXIgY29tcGlsYWJsZT8KK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIgdXNhYmls
aXR5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nICQyIHVzYWJpbGl0eS4uLiAiID4mNjsgfQor
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworJDQKKyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19oZWFkZXJfY29tcGlsZXI9eWVzCitlbHNlCisg
IGFjX2hlYWRlcl9jb21waWxlcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19oZWFkZXJfY29tcGlsZXIiID4mNQorJGFzX2Vj
aG8gIiRhY19oZWFkZXJfY29tcGlsZXIiID4mNjsgfQorCisjIElzIHRoZSBoZWFkZXIgcHJlc2Vu
dD8KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIg
cHJlc2VuY2UiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgJDIgcHJlc2VuY2UuLi4gIiA+JjY7
IH0KK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3Bw
ICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2hlYWRlcl9wcmVwcm9jPXllcworZWxzZQorICBhY19o
ZWFkZXJfcHJlcHJvYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0
ZXN0LiRhY19leHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfaGVhZGVyX3ByZXByb2MiID4mNQorJGFzX2VjaG8gIiRhY19oZWFkZXJfcHJlcHJv
YyIgPiY2OyB9CisKKyMgU28/ICBXaGF0IGFib3V0IHRoaXMgaGVhZGVyPworY2FzZSAkYWNfaGVh
ZGVyX2NvbXBpbGVyOiRhY19oZWFkZXJfcHJlcHJvYzokYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBp
biAjKCgKKyAgeWVzOm5vOiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiAkMjogYWNjZXB0ZWQgYnkgdGhlIGNvbXBpbGVyLCByZWplY3RlZCBi
eSB0aGUgcHJlcHJvY2Vzc29yISIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjog
YWNjZXB0ZWQgYnkgdGhlIGNvbXBpbGVyLCByZWplY3RlZCBieSB0aGUgcHJlcHJvY2Vzc29yISIg
PiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5J
Tkc6ICQyOiBwcm9jZWVkaW5nIHdpdGggdGhlIGNvbXBpbGVyJ3MgcmVzdWx0IiA+JjUKKyRhc19l
Y2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiBwcm9jZWVkaW5nIHdpdGggdGhlIGNvbXBpbGVyJ3Mg
cmVzdWx0IiA+JjI7fQorICAgIDs7CisgIG5vOnllczoqICkKKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3Qg
YmUgY29tcGlsZWQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHByZXNlbnQg
YnV0IGNhbm5vdCBiZSBjb21waWxlZCIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiAgICAgY2hlY2sgZm9yIG1pc3NpbmcgcHJl
cmVxdWlzaXRlIGhlYWRlcnM/IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiAg
ICAgY2hlY2sgZm9yIG1pc3NpbmcgcHJlcmVxdWlzaXRlIGhlYWRlcnM/IiA+JjI7fQorICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6IHNlZSB0
aGUgQXV0b2NvbmYgZG9jdW1lbnRhdGlvbiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiAkMjogc2VlIHRoZSBBdXRvY29uZiBkb2N1bWVudGF0aW9uIiA+JjI7fQorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6ICAgICBzZWN0aW9u
IFwiUHJlc2VudCBCdXQgQ2Fubm90IEJlIENvbXBpbGVkXCIiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogJDI6ICAgICBzZWN0aW9uIFwiUHJlc2VudCBCdXQgQ2Fubm90IEJlIENvbXBp
bGVkXCIiID4mMjt9CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1
CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21w
aWxlcidzIHJlc3VsdCIgPiYyO30KKyggJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBSZXBvcnQgdGhpcyB0byB4ZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbSAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gIyMiCisgICAgICkgfCBzZWQgInMvXi8kYXNfbWU6IFdBUk5JTkc6ICAg
ICAvIiA+JjIKKyAgICA7OworZXNhYworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JDIuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIkMz1cJGFjX2hlYWRlcl9jb21waWxl
ciIKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVz
IiA+JjY7IH0KK2ZpCisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6
Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbAor
CisjIGFjX2ZuX2NfdHJ5X3J1biBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBU
cnkgdG8gbGluayBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNj
ZWVkZWQuIEFzc3VtZXMKKyMgdGhhdCBleGVjdXRhYmxlcyAqY2FuKiBiZSBydW4uCithY19mbl9j
X3RyeV9ydW4gKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19z
dGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiB7IHsgYWNfdHJ5PSIk
YWNfbGluayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190
cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZh
bCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2Vj
aG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsi
KSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfSAm
JiB7IGFjX3RyeT0nLi9jb25mdGVzdCRhY19leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnki
IGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBh
Y190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9l
Y2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgfTsgdGhlbiA6CisgIGFjX3JldHZhbD0wCitl
bHNlCisgICRhc19lY2hvICIkYXNfbWU6IHByb2dyYW0gZXhpdGVkIHdpdGggc3RhdHVzICRhY19z
dGF0dXMiID4mNQorICAgICAgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoi
ID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCisgICAgICAgYWNfcmV0
dmFsPSRhY19zdGF0dXMKK2ZpCisgIHJtIC1yZiBjb25mdGVzdC5kU1lNIGNvbmZ0ZXN0X2lwYThf
Y29uZnRlc3Qub28KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazor
On0gdW5zZXQgYXNfbGluZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMg
YWNfZm5fY190cnlfcnVuCisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSBMSU5FTk8g
SEVBREVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4aXN0cyBhbmQg
Y2FuIGJlIGNvbXBpbGVkIHVzaW5nIHRoZSBpbmNsdWRlIGZpbGVzIGluCisjIElOQ0xVREVTLCBz
ZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCithY19mbl9jX2NoZWNr
X2hlYWRlcl9jb21waWxlICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19s
aW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworJDQKKyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAi
JExJTkVOTyI7IHRoZW4gOgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu
JGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRh
Y19yZXMiID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNr
Ois6fSB1bnNldCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUK
KworIyBhY19mbl9jX3RyeV9saW5rIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQor
IyBUcnkgdG8gbGluayBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBz
dWNjZWVkZWQuCithY19mbl9jX3RyeV9saW5rICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVu
by0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sK
KyAgcm0gLWYgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdCRhY19leGVleHQKKyAgaWYgeyB7
IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwg
KlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsK
K2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
JGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwg
IiRhY19saW5rIikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMg
Y29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25m
dGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVy
MSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYg
eworCSB0ZXN0IC16ICIkYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0
LmVycgorICAgICAgIH0gJiYgdGVzdCAtcyBjb25mdGVzdCRhY19leGVleHQgJiYgeworCSB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllcyB8fAorCSAkYXNfdGVzdF94IGNvbmZ0ZXN0JGFjX2V4
ZWV4dAorICAgICAgIH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAi
JGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3Qu
JGFjX2V4dCA+JjUKKworCWFjX3JldHZhbD0xCitmaQorICAjIERlbGV0ZSB0aGUgSVBBL0lQTyAo
SW50ZXIgUHJvY2VkdXJhbCBBbmFseXNpcy9PcHRpbWl6YXRpb24pIGluZm9ybWF0aW9uCisgICMg
Y3JlYXRlZCBieSB0aGUgUEdJIGNvbXBpbGVyIChjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vKSwg
YXMgaXQgd291bGQKKyAgIyBpbnRlcmZlcmUgd2l0aCB0aGUgbmV4dCBsaW5rIGNvbW1hbmQ7IGFs
c28gZGVsZXRlIGEgZGlyZWN0b3J5IHRoYXQgaXMKKyAgIyBsZWZ0IGJlaGluZCBieSBBcHBsZSdz
IGNvbXBpbGVyLiAgV2UgZG8gdGhpcyBiZWZvcmUgZXhlY3V0aW5nIHRoZSBhY3Rpb25zLgorICBy
bSAtcmYgY29uZnRlc3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwgJGFz
X2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworICBh
c19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5X2xpbmsKKworIyBh
Y19mbl9jX2NoZWNrX3R5cGUgTElORU5PIFRZUEUgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhlciBUWVBFIGV4
aXN0cyBhZnRlciBoYXZpbmcgaW5jbHVkZWQgSU5DTFVERVMsIHNldHRpbmcgY2FjaGUKKyMgdmFy
aWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja190eXBlICgpCit7CisgIGFzX2xp
bmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRh
c19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIg
PiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgZXZhbCAiJDM9bm8iCisgIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0CitpbnQK
K21haW4gKCkKK3sKK2lmIChzaXplb2YgKCQyKSkKKwkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNv
bmZkZWZzLmguICAqLworJDQKK2ludAorbWFpbiAoKQoreworaWYgKHNpemVvZiAoKCQyKSkpCisJ
ICAgIHJldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgZXZhbCAiJDM9eWVzIgorZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj
X2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29u
ZnRlc3QuJGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2Vj
aG8gIiRhY19yZXMiID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5v
X3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfdHlwZQorCisj
IGFjX2ZuX2NfY2hlY2tfZnVuYyBMSU5FTk8gRlVOQyBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3RzLCBzZXR0aW5nIHRo
ZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkKK2FjX2ZuX2NfY2hlY2tfZnVuYyAoKQor
eworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVu
b19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIERlZmluZSAkMiB0
byBhbiBpbm5vY3VvdXMgdmFyaWFudCwgaW4gY2FzZSA8bGltaXRzLmg+IGRlY2xhcmVzICQyLgor
ICAgRm9yIGV4YW1wbGUsIEhQLVVYIDExaSA8bGltaXRzLmg+IGRlY2xhcmVzIGdldHRpbWVvZmRh
eS4gICovCisjZGVmaW5lICQyIGlubm9jdW91c18kMgorCisvKiBTeXN0ZW0gaGVhZGVyIHRvIGRl
ZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCisgICAgd2hp
Y2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciAkMiAoKTsgYmVsb3cuCisgICAgUHJlZmVyIDxsaW1p
dHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAgIDxs
aW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4gICovCisKKyNp
ZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFz
c2VydC5oPgorI2VuZGlmCisKKyN1bmRlZiAkMgorCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBf
X2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyICQyICgpOworLyogVGhlIEdOVSBD
IGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cwor
ICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVh
bGx5IG5hbWVkCisgICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwg
bmFtZSBpcyBhbiBhbGlhcy4gICovCisjaWYgZGVmaW5lZCBfX3N0dWJfJDIgfHwgZGVmaW5lZCBf
X3N0dWJfX18kMgorY2hva2UgbWUKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAk
MiAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkMwor
CSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVu
b19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNf
Zm5fY19jaGVja19mdW5jCisKKyMgYWNfZm5fY19maW5kX2ludFhfdCBMSU5FTk8gQklUUyBWQVIK
KyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgRmluZHMgYSBzaWduZWQg
aW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIK
KyMgYWNjb3JkaW5nbHkuCithY19mbl9jX2ZpbmRfaW50WF90ICgpCit7CisgIGFzX2xpbmVubz0k
e2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5l
bm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgaW50JDJfdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW50JDJfdC4u
LiAiID4mNjsgfQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICAgICAjIE9yZGVyIGlzIGlt
cG9ydGFudCAtIG5ldmVyIGNoZWNrIGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIK
KyAgICAgIyB0aGFuIGhhbGYgb2YgdGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KKyAgICAgZm9y
IGFjX3R5cGUgaW4gaW50JDJfdCAnaW50JyAnbG9uZyBpbnQnIFwKKwkgJ2xvbmcgbG9uZyBpbnQn
ICdzaG9ydCBpbnQnICdzaWduZWQgY2hhcic7IGRvCisgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQKKwkgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWlu
ICgpCit7CitzdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAo
KCgoKCRhY190eXBlKSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsKK3Rlc3RfYXJyYXkg
WzBdID0gMAorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2Nv
bXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1
bHQKKwkgICAgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7Citz
dGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUp
IDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAxKQorCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5
cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAyKSldOwordGVzdF9hcnJheSBbMF0gPSAwCisK
KyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGNhc2UgJGFjX3R5cGUgaW4gIygKKyAgaW50JDJfdCkg
OgorICAgIGV2YWwgIiQzPXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlw
ZSIgOzsKK2VzYWMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQi
JDMiXCIgPSB4Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2Zp
CitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7
IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQg
YXNfbGluZW5vCisKK30gIyBhY19mbl9jX2ZpbmRfaW50WF90CisKKyMgYWNfZm5fY19jaGVja19t
ZW1iZXIgTElORU5PIEFHR1IgTUVNQkVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyaWVzIHRvIGZpbmQgaWYg
dGhlIGZpZWxkIE1FTUJFUiBleGlzdHMgaW4gdHlwZSBBR0dSLCBhZnRlciBpbmNsdWRpbmcKKyMg
SU5DTFVERVMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5f
Y19jaGVja19tZW1iZXIgKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xp
bmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMi4kMyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuJDMuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDQr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCiskNQoraW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChh
Y19hZ2dyLiQzKQorcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDQ9eWVzIgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCiskNQoraW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsK
K2lmIChzaXplb2YgYWNfYWdnci4kMykKK3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQor
X0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwg
IiQ0PXllcyIKK2Vsc2UKKyAgZXZhbCAiJDQ9bm8iCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZh
bCBhY19yZXM9XCQkNAorCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Cisg
IGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xp
bmVubworCit9ICMgYWNfZm5fY19jaGVja19tZW1iZXIKKworIyBhY19mbl9jX2ZpbmRfdWludFhf
dCBMSU5FTk8gQklUUyBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CisjIEZpbmRzIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRoIEJJVFMsIHNldHRp
bmcgY2FjaGUgdmFyaWFibGUgVkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19maW5kX3VpbnRY
X3QgKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1h
c19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgdWludCQyX3QuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIk
Mz1ubyIKKyAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhh
dCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCisgICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3Rl
ZCB0YXJnZXQgd2lkdGguCisgICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90ICd1bnNpZ25lZCBp
bnQnICd1bnNpZ25lZCBsb25nIGludCcgXAorCSAndW5zaWduZWQgbG9uZyBsb25nIGludCcgJ3Vu
c2lnbmVkIHNob3J0IGludCcgJ3Vuc2lnbmVkIGNoYXInOyBkbworICAgICAgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK21haW4gKCkKK3sKK3N0YXRpYyBpbnQgdGVzdF9h
cnJheSBbMSAtIDIgKiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8g
MiAtIDEpID09IDMpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2Fz
ZSAkYWNfdHlwZSBpbiAjKAorICB1aW50JDJfdCkgOgorICAgIGV2YWwgIiQzPXllcyIgOzsgIygK
KyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2ZpCitybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAg
ICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJl
YWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRh
c19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xp
bmVub19zdGFjazorOn0gdW5zZXQgYXNfbGluZW5vCisKK30gIyBhY19mbl9jX2ZpbmRfdWludFhf
dAorY2F0ID5jb25maWcubG9nIDw8X0FDRU9GCitUaGlzIGZpbGUgY29udGFpbnMgYW55IG1lc3Nh
Z2VzIHByb2R1Y2VkIGJ5IGNvbXBpbGVycyB3aGlsZQorcnVubmluZyBjb25maWd1cmUsIHRvIGFp
ZCBkZWJ1Z2dpbmcgaWYgY29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KKworSXQgd2FzIGNyZWF0
ZWQgYnkgWGVuIEh5cGVydmlzb3IgJGFzX21lIDQuMiwgd2hpY2ggd2FzCitnZW5lcmF0ZWQgYnkg
R05VIEF1dG9jb25mIDIuNjguICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICAkICQw
ICRACisKK19BQ0VPRgorZXhlYyA1Pj5jb25maWcubG9nCit7CitjYXQgPDxfQVNVTkFNRQorIyMg
LS0tLS0tLS0tICMjCisjIyBQbGF0Zm9ybS4gIyMKKyMjIC0tLS0tLS0tLSAjIworCitob3N0bmFt
ZSA9IGAoaG9zdG5hbWUgfHwgdW5hbWUgLW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAordW5hbWUg
LW0gPSBgKHVuYW1lIC1tKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtciA9
IGAodW5hbWUgLXIpIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1zID0gYCh1
bmFtZSAtcykgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXYgPSBgKHVuYW1l
IC12KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCisKKy91c3IvYmluL3VuYW1lIC1wID0g
YCgvdXNyL2Jpbi91bmFtZSAtcCkgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAorL2Jpbi91
bmFtZSAtWCAgICAgPSBgKC9iaW4vdW5hbWUgLVgpIDI+L2Rldi9udWxsICAgICB8fCBlY2hvIHVu
a25vd25gCisKKy9iaW4vYXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkgMj4vZGV2L251
bGwgICAgICAgICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL2FyY2ggLWsgICAgICAg
PSBgKC91c3IvYmluL2FyY2ggLWspIDI+L2Rldi9udWxsICAgICAgIHx8IGVjaG8gdW5rbm93bmAK
Ky91c3IvY29udmV4L2dldHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dldHN5c2luZm8pIDI+L2Rl
di9udWxsIHx8IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL2hvc3RpbmZvICAgICAgPSBgKC91c3Iv
YmluL2hvc3RpbmZvKSAyPi9kZXYvbnVsbCAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vbWFj
aGluZSAgICAgICAgICAgPSBgKC9iaW4vbWFjaGluZSkgMj4vZGV2L251bGwgICAgICAgICAgIHx8
IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL29zbGV2ZWwgICAgICAgPSBgKC91c3IvYmluL29zbGV2
ZWwpIDI+L2Rldi9udWxsICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vdW5pdmVyc2UgICAg
ICAgICAgPSBgKC9iaW4vdW5pdmVyc2UpIDI+L2Rldi9udWxsICAgICAgICAgIHx8IGVjaG8gdW5r
bm93bmAKKworX0FTVU5BTUUKKworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgICRhc19lY2hvICJQQVRIOiAkYXNfZGlyIgorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK30gPiY1CisKK2NhdCA+JjUgPDxfQUNFT0YKKworCisj
IyAtLS0tLS0tLS0tLSAjIworIyMgQ29yZSB0ZXN0cy4gIyMKKyMjIC0tLS0tLS0tLS0tICMjCisK
K19BQ0VPRgorCisKKyMgS2VlcCBhIHRyYWNlIG9mIHRoZSBjb21tYW5kIGxpbmUuCisjIFN0cmlw
IG91dCAtLW5vLWNyZWF0ZSBhbmQgLS1uby1yZWN1cnNpb24gc28gdGhleSBkbyBub3QgcGlsZSB1
cC4KKyMgU3RyaXAgb3V0IC0tc2lsZW50IGJlY2F1c2Ugd2UgZG9uJ3Qgd2FudCB0byByZWNvcmQg
aXQgZm9yIGZ1dHVyZSBydW5zLgorIyBBbHNvIHF1b3RlIGFueSBhcmdzIGNvbnRhaW5pbmcgc2hl
bGwgbWV0YS1jaGFyYWN0ZXJzLgorIyBNYWtlIHR3byBwYXNzZXMgdG8gYWxsb3cgZm9yIHByb3Bl
ciBkdXBsaWNhdGUtYXJndW1lbnQgc3VwcHJlc3Npb24uCithY19jb25maWd1cmVfYXJncz0KK2Fj
X2NvbmZpZ3VyZV9hcmdzMD0KK2FjX2NvbmZpZ3VyZV9hcmdzMT0KK2FjX211c3Rfa2VlcF9uZXh0
PWZhbHNlCitmb3IgYWNfcGFzcyBpbiAxIDIKK2RvCisgIGZvciBhY19hcmcKKyAgZG8KKyAgICBj
YXNlICRhY19hcmcgaW4KKyAgICAtbm8tY3JlYXRlIHwgLS1uby1jKiB8IC1uIHwgLW5vLXJlY3Vy
c2lvbiB8IC0tbm8tciopIGNvbnRpbnVlIDs7CisgICAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwg
LS1xdWllIHwgLS1xdWkgfCAtLXF1IHwgLS1xIFwKKyAgICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8
IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCkKKyAgICAgIGNvbnRpbnVlIDs7CisgICAgKlwnKikK
KyAgICAgIGFjX2FyZz1gJGFzX2VjaG8gIiRhY19hcmciIHwgc2VkICJzLycvJ1xcXFxcXFxcJycv
ZyJgIDs7CisgICAgZXNhYworICAgIGNhc2UgJGFjX3Bhc3MgaW4KKyAgICAxKSBhc19mbl9hcHBl
bmQgYWNfY29uZmlndXJlX2FyZ3MwICIgJyRhY19hcmcnIiA7OworICAgIDIpCisgICAgICBhc19m
bl9hcHBlbmQgYWNfY29uZmlndXJlX2FyZ3MxICIgJyRhY19hcmcnIgorICAgICAgaWYgdGVzdCAk
YWNfbXVzdF9rZWVwX25leHQgPSB0cnVlOyB0aGVuCisJYWNfbXVzdF9rZWVwX25leHQ9ZmFsc2Ug
IyBHb3QgdmFsdWUsIGJhY2sgdG8gbm9ybWFsLgorICAgICAgZWxzZQorCWNhc2UgJGFjX2FyZyBp
bgorCSAgKj0qIHwgLS1jb25maWctY2FjaGUgfCAtQyB8IC1kaXNhYmxlLSogfCAtLWRpc2FibGUt
KiBcCisJICB8IC1lbmFibGUtKiB8IC0tZW5hYmxlLSogfCAtZ2FzIHwgLS1nKiB8IC1uZnAgfCAt
LW5mKiBcCisJICB8IC1xIHwgLXF1aWV0IHwgLS1xKiB8IC1zaWxlbnQgfCAtLXNpbCogfCAtdiB8
IC12ZXJiKiBcCisJICB8IC13aXRoLSogfCAtLXdpdGgtKiB8IC13aXRob3V0LSogfCAtLXdpdGhv
dXQtKiB8IC0teCkKKwkgICAgY2FzZSAiJGFjX2NvbmZpZ3VyZV9hcmdzMCAiIGluCisJICAgICAg
IiRhY19jb25maWd1cmVfYXJnczEiKiIgJyRhY19hcmcnICIqICkgY29udGludWUgOzsKKwkgICAg
ZXNhYworCSAgICA7OworCSAgLSogKSBhY19tdXN0X2tlZXBfbmV4dD10cnVlIDs7CisJZXNhYwor
ICAgICAgZmkKKyAgICAgIGFzX2ZuX2FwcGVuZCBhY19jb25maWd1cmVfYXJncyAiICckYWNfYXJn
JyIKKyAgICAgIDs7CisgICAgZXNhYworICBkb25lCitkb25lCit7IGFjX2NvbmZpZ3VyZV9hcmdz
MD07IHVuc2V0IGFjX2NvbmZpZ3VyZV9hcmdzMDt9Cit7IGFjX2NvbmZpZ3VyZV9hcmdzMT07IHVu
c2V0IGFjX2NvbmZpZ3VyZV9hcmdzMTt9CisKKyMgV2hlbiBpbnRlcnJ1cHRlZCBvciBleGl0J2Qs
IGNsZWFudXAgdGVtcG9yYXJ5IGZpbGVzLCBhbmQgY29tcGxldGUKKyMgY29uZmlnLmxvZy4gIFdl
IHJlbW92ZSBjb21tZW50cyBiZWNhdXNlIGFueXdheSB0aGUgcXVvdGVzIGluIHRoZXJlCisjIHdv
dWxkIGNhdXNlIHByb2JsZW1zIG9yIGxvb2sgdWdseS4KKyMgV0FSTklORzogVXNlICdcJycgdG8g
cmVwcmVzZW50IGFuIGFwb3N0cm9waGUgd2l0aGluIHRoZSB0cmFwLgorIyBXQVJOSU5HOiBEbyBu
b3Qgc3RhcnQgdGhlIHRyYXAgY29kZSB3aXRoIGEgbmV3bGluZSwgZHVlIHRvIGEgRnJlZUJTRCA0
LjAgYnVnLgordHJhcCAnZXhpdF9zdGF0dXM9JD8KKyAgIyBTYXZlIGludG8gY29uZmlnLmxvZyBz
b21lIGluZm9ybWF0aW9uIHRoYXQgbWlnaHQgaGVscCBpbiBkZWJ1Z2dpbmcuCisgIHsKKyAgICBl
Y2hvCisKKyAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgQ2FjaGUgdmFy
aWFibGVzLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisgICAgIyBUaGUg
Zm9sbG93aW5nIHdheSBvZiB3cml0aW5nIHRoZSBjYWNoZSBtaXNoYW5kbGVzIG5ld2xpbmVzIGlu
IHZhbHVlcywKKygKKyAgZm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAtbiAnXCcncy9e
XChbYS16QS1aX11bYS16QS1aMC05X10qXCk9LiovXDEvcCdcJydgOyBkbworICAgIGV2YWwgYWNf
dmFsPVwkJGFjX3ZhcgorICAgIGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSopCisg
ICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNv
bnRhaW5zIGEgbmV3bGluZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNoZSB2
YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVzYWMK
KyAgICAgIGNhc2UgJGFjX3ZhciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAjKAor
ICAgICAgQkFTSF9BUkdWIHwgQkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAgICAg
ICopIHsgZXZhbCAkYWNfdmFyPTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7Cisg
ICAgZXNhYworICBkb25lCisgIChzZXQpIDI+JjEgfAorICAgIGNhc2UgJGFzX25sYChhY19zcGFj
ZT0nXCcnICdcJyc7IHNldCkgMj4mMWAgaW4gIygKKyAgICAqJHthc19ubH1hY19zcGFjZT1cICop
CisgICAgICBzZWQgLW4gXAorCSJzLydcJycvJ1wnJ1xcXFwnXCcnJ1wnJy9nOworCSAgcy9eXFwo
W18kYXNfY3JfYWxudW1dKl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwpL1xcMT0nXCcn
XFwyJ1wnJy9wIgorICAgICAgOzsgIygKKyAgICAqKQorICAgICAgc2VkIC1uICIvXltfJGFzX2Ny
X2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKj0vcCIKKyAgICAgIDs7CisgICAgZXNhYyB8Cisg
ICAgc29ydAorKQorICAgIGVjaG8KKworICAgICRhc19lY2hvICIjIyAtLS0tLS0tLS0tLS0tLS0t
LSAjIworIyMgT3V0cHV0IHZhcmlhYmxlcy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tICMjIgor
ICAgIGVjaG8KKyAgICBmb3IgYWNfdmFyIGluICRhY19zdWJzdF92YXJzCisgICAgZG8KKyAgICAg
IGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAgICAgY2FzZSAkYWNfdmFsIGluCisgICAgICAqXCdc
JycqKSBhY192YWw9YCRhc19lY2hvICIkYWNfdmFsIiB8IHNlZCAicy8nXCcnLydcJydcXFxcXFxc
XCdcJycnXCcnL2ciYDs7CisgICAgICBlc2FjCisgICAgICAkYXNfZWNobyAiJGFjX3Zhcj0nXCcn
JGFjX3ZhbCdcJyciCisgICAgZG9uZSB8IHNvcnQKKyAgICBlY2hvCisKKyAgICBpZiB0ZXN0IC1u
ICIkYWNfc3Vic3RfZmlsZXMiOyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0t
LS0tLS0tLSAjIworIyMgRmlsZSBzdWJzdGl0dXRpb25zLiAjIworIyMgLS0tLS0tLS0tLS0tLS0t
LS0tLSAjIyIKKyAgICAgIGVjaG8KKyAgICAgIGZvciBhY192YXIgaW4gJGFjX3N1YnN0X2ZpbGVz
CisgICAgICBkbworCWV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorCWNhc2UgJGFjX3ZhbCBpbgorCSpc
J1wnJyopIGFjX3ZhbD1gJGFzX2VjaG8gIiRhY192YWwiIHwgc2VkICJzLydcJycvJ1wnJ1xcXFxc
XFxcJ1wnJydcJycvZyJgOzsKKwllc2FjCisJJGFzX2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwn
XCcnIgorICAgICAgZG9uZSB8IHNvcnQKKyAgICAgIGVjaG8KKyAgICBmaQorCisgICAgaWYgdGVz
dCAtcyBjb25mZGVmcy5oOyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0gIyMK
KyMjIGNvbmZkZWZzLmguICMjCisjIyAtLS0tLS0tLS0tLSAjIyIKKyAgICAgIGVjaG8KKyAgICAg
IGNhdCBjb25mZGVmcy5oCisgICAgICBlY2hvCisgICAgZmkKKyAgICB0ZXN0ICIkYWNfc2lnbmFs
IiAhPSAwICYmCisgICAgICAkYXNfZWNobyAiJGFzX21lOiBjYXVnaHQgc2lnbmFsICRhY19zaWdu
YWwiCisgICAgJGFzX2VjaG8gIiRhc19tZTogZXhpdCAkZXhpdF9zdGF0dXMiCisgIH0gPiY1Cisg
IHJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiAmJgorICAgIHJtIC1mIC1yIGNvbmZ0
ZXN0KiBjb25mZGVmcyogY29uZiQkKiAkYWNfY2xlYW5fZmlsZXMgJiYKKyAgICBleGl0ICRleGl0
X3N0YXR1cworJyAwCitmb3IgYWNfc2lnbmFsIGluIDEgMiAxMyAxNTsgZG8KKyAgdHJhcCAnYWNf
c2lnbmFsPSckYWNfc2lnbmFsJzsgYXNfZm5fZXhpdCAxJyAkYWNfc2lnbmFsCitkb25lCithY19z
aWduYWw9MAorCisjIGNvbmZkZWZzLmggYXZvaWRzIE9TIGNvbW1hbmQgbGluZSBsZW5ndGggbGlt
aXRzIHRoYXQgREVGUyBjYW4gZXhjZWVkLgorcm0gLWYgLXIgY29uZnRlc3QqIGNvbmZkZWZzLmgK
KworJGFzX2VjaG8gIi8qIGNvbmZkZWZzLmggKi8iID4gY29uZmRlZnMuaAorCisjIFByZWRlZmlu
ZWQgcHJlcHJvY2Vzc29yIHZhcmlhYmxlcy4KKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBQQUNLQUdFX05BTUUgIiRQQUNLQUdFX05BTUUiCitfQUNFT0YKKworY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgIiRQQUNLQUdFX1RBUk5B
TUUiCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdF
X1ZFUlNJT04gIiRQQUNLQUdFX1ZFUlNJT04iCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1NUUklORyAiJFBBQ0tBR0VfU1RSSU5HIgorX0FDRU9G
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9CVUdSRVBPUlQg
IiRQQUNLQUdFX0JVR1JFUE9SVCIKK19BQ0VPRgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjZGVmaW5lIFBBQ0tBR0VfVVJMICIkUEFDS0FHRV9VUkwiCitfQUNFT0YKKworCisjIExldCB0
aGUgc2l0ZSBmaWxlIHNlbGVjdCBhbiBhbHRlcm5hdGUgY2FjaGUgZmlsZSBpZiBpdCB3YW50cyB0
by4KKyMgUHJlZmVyIGFuIGV4cGxpY2l0bHkgc2VsZWN0ZWQgZmlsZSB0byBhdXRvbWF0aWNhbGx5
IHNlbGVjdGVkIG9uZXMuCithY19zaXRlX2ZpbGUxPU5PTkUKK2FjX3NpdGVfZmlsZTI9Tk9ORQor
aWYgdGVzdCAtbiAiJENPTkZJR19TSVRFIjsgdGhlbgorICAjIFdlIGRvIG5vdCB3YW50IGEgUEFU
SCBzZWFyY2ggZm9yIGNvbmZpZy5zaXRlLgorICBjYXNlICRDT05GSUdfU0lURSBpbiAjKCgKKyAg
ICAtKikgIGFjX3NpdGVfZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICAgICovKikgYWNfc2l0ZV9m
aWxlMT0kQ09ORklHX1NJVEU7OworICAgICopICAgYWNfc2l0ZV9maWxlMT0uLyRDT05GSUdfU0lU
RTs7CisgIGVzYWMKK2VsaWYgdGVzdCAieCRwcmVmaXgiICE9IHhOT05FOyB0aGVuCisgIGFjX3Np
dGVfZmlsZTE9JHByZWZpeC9zaGFyZS9jb25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUyPSRwcmVm
aXgvZXRjL2NvbmZpZy5zaXRlCitlbHNlCisgIGFjX3NpdGVfZmlsZTE9JGFjX2RlZmF1bHRfcHJl
Zml4L3NoYXJlL2NvbmZpZy5zaXRlCisgIGFjX3NpdGVfZmlsZTI9JGFjX2RlZmF1bHRfcHJlZml4
L2V0Yy9jb25maWcuc2l0ZQorZmkKK2ZvciBhY19zaXRlX2ZpbGUgaW4gIiRhY19zaXRlX2ZpbGUx
IiAiJGFjX3NpdGVfZmlsZTIiCitkbworICB0ZXN0ICJ4JGFjX3NpdGVfZmlsZSIgPSB4Tk9ORSAm
JiBjb250aW51ZQorICBpZiB0ZXN0IC9kZXYvbnVsbCAhPSAiJGFjX3NpdGVfZmlsZSIgJiYgdGVz
dCAtciAiJGFjX3NpdGVfZmlsZSI7IHRoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGxvYWRpbmcgc2l0ZSBzY3JpcHQgJGFjX3NpdGVfZmlsZSIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUiID4mNjt9
CisgICAgc2VkICdzL14vfCAvJyAiJGFjX3NpdGVfZmlsZSIgPiY1CisgICAgLiAiJGFjX3NpdGVf
ZmlsZSIgXAorICAgICAgfHwgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiZmFpbGVkIHRvIGxvYWQgc2l0
ZSBzY3JpcHQgJGFjX3NpdGVfZmlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWls
cyIgIiRMSU5FTk8iIDU7IH0KKyAgZmkKK2RvbmUKKworaWYgdGVzdCAtciAiJGNhY2hlX2ZpbGUi
OyB0aGVuCisgICMgU29tZSB2ZXJzaW9ucyBvZiBiYXNoIHdpbGwgZmFpbCB0byBzb3VyY2UgL2Rl
di9udWxsIChzcGVjaWFsIGZpbGVzCisgICMgYWN0dWFsbHkpLCBzbyB3ZSBhdm9pZCBkb2luZyB0
aGF0LiAgREpHUFAgZW11bGF0ZXMgaXQgYXMgYSByZWd1bGFyIGZpbGUuCisgIGlmIHRlc3QgL2Rl
di9udWxsICE9ICIkY2FjaGVfZmlsZSIgJiYgdGVzdCAtZiAiJGNhY2hlX2ZpbGUiOyB0aGVuCisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBsb2FkaW5nIGNhY2hl
ICRjYWNoZV9maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGxvYWRpbmcgY2FjaGUgJGNhY2hl
X2ZpbGUiID4mNjt9CisgICAgY2FzZSAkY2FjaGVfZmlsZSBpbgorICAgICAgW1xcL10qIHwgPzpb
XFwvXSogKSAuICIkY2FjaGVfZmlsZSI7OworICAgICAgKikgICAgICAgICAgICAgICAgICAgICAg
LiAiLi8kY2FjaGVfZmlsZSI7OworICAgIGVzYWMKKyAgZmkKK2Vsc2UKKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30K
KyAgPiRjYWNoZV9maWxlCitmaQorCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMv
dGltZS5oIgorYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCithc19mbl9h
cHBlbmQgYWNfZnVuY19saXN0ICIgYWxhcm0iCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3Qg
IiBzdGRsaWIuaCIKK2FzX2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgor
IyBDaGVjayB0aGF0IHRoZSBwcmVjaW91cyB2YXJpYWJsZXMgc2F2ZWQgaW4gdGhlIGNhY2hlIGhh
dmUga2VwdCB0aGUgc2FtZQorIyB2YWx1ZS4KK2FjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQorZm9y
IGFjX3ZhciBpbiAkYWNfcHJlY2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19vbGRfc2V0PVwkYWNf
Y3ZfZW52XyR7YWNfdmFyfV9zZXQKKyAgZXZhbCBhY19uZXdfc2V0PVwkYWNfZW52XyR7YWNfdmFy
fV9zZXQKKyAgZXZhbCBhY19vbGRfdmFsPVwkYWNfY3ZfZW52XyR7YWNfdmFyfV92YWx1ZQorICBl
dmFsIGFjX25ld192YWw9XCRhY19lbnZfJHthY192YXJ9X3ZhbHVlCisgIGNhc2UgJGFjX29sZF9z
ZXQsJGFjX25ld19zZXQgaW4KKyAgICBzZXQsKQorICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgc2V0IHRvIFxgJGFjX29s
ZF92YWwnIGluIHRoZSBwcmV2aW91cyBydW4iID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6
IFxgJGFjX3Zhcicgd2FzIHNldCB0byBcYCRhY19vbGRfdmFsJyBpbiB0aGUgcHJldmlvdXMgcnVu
IiA+JjI7fQorICAgICAgYWNfY2FjaGVfY29ycnVwdGVkPTogOzsKKyAgICAsc2V0KQorICAgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFy
JyB3YXMgbm90IHNldCBpbiB0aGUgcHJldmlvdXMgcnVuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6
IGVycm9yOiBcYCRhY192YXInIHdhcyBub3Qgc2V0IGluIHRoZSBwcmV2aW91cyBydW4iID4mMjt9
CisgICAgICBhY19jYWNoZV9jb3JydXB0ZWQ9OiA7OworICAgICwpOzsKKyAgICAqKQorICAgICAg
aWYgdGVzdCAieCRhY19vbGRfdmFsIiAhPSAieCRhY19uZXdfdmFsIjsgdGhlbgorCSMgZGlmZmVy
ZW5jZXMgaW4gd2hpdGVzcGFjZSBkbyBub3QgbGVhZCB0byBmYWlsdXJlLgorCWFjX29sZF92YWxf
dz1gZWNobyB4ICRhY19vbGRfdmFsYAorCWFjX25ld192YWxfdz1gZWNobyB4ICRhY19uZXdfdmFs
YAorCWlmIHRlc3QgIiRhY19vbGRfdmFsX3ciICE9ICIkYWNfbmV3X3ZhbF93IjsgdGhlbgorCSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFy
JyBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogXGAkYWNfdmFyJyBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgcnVu
OiIgPiYyO30KKwkgIGFjX2NhY2hlX2NvcnJ1cHRlZD06CisJZWxzZQorCSAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiB3YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNl
IGNoYW5nZXMgaW4gXGAkYWNfdmFyJyBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiB3YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gXGAk
YWNfdmFyJyBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiYyO30KKwkgIGV2YWwgJGFjX3Zhcj1c
JGFjX29sZF92YWwKKwlmaQorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogICBmb3JtZXIgdmFsdWU6ICBcYCRhY19vbGRfdmFsJyIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiAgIGZvcm1lciB2YWx1ZTogIFxgJGFjX29sZF92YWwnIiA+JjI7fQorCXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogICBjdXJyZW50IHZhbHVlOiBcYCRhY19uZXdfdmFs
JyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAgIGN1cnJlbnQgdmFsdWU6IFxgJGFjX25ld192YWwn
IiA+JjI7fQorICAgICAgZmk7OworICBlc2FjCisgICMgUGFzcyBwcmVjaW91cyB2YXJpYWJsZXMg
dG8gY29uZmlnLnN0YXR1cy4KKyAgaWYgdGVzdCAiJGFjX25ld19zZXQiID0gc2V0OyB0aGVuCisg
ICAgY2FzZSAkYWNfbmV3X3ZhbCBpbgorICAgICpcJyopIGFjX2FyZz0kYWNfdmFyPWAkYXNfZWNo
byAiJGFjX25ld192YWwiIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgIDs7CisgICAgKikgYWNf
YXJnPSRhY192YXI9JGFjX25ld192YWwgOzsKKyAgICBlc2FjCisgICAgY2FzZSAiICRhY19jb25m
aWd1cmVfYXJncyAiIGluCisgICAgICAqIiAnJGFjX2FyZycgIiopIDs7ICMgQXZvaWQgZHVwcy4g
IFVzZSBvZiBxdW90ZXMgZW5zdXJlcyBhY2N1cmFjeS4KKyAgICAgICopIGFzX2ZuX2FwcGVuZCBh
Y19jb25maWd1cmVfYXJncyAiICckYWNfYXJnJyIgOzsKKyAgICBlc2FjCisgIGZpCitkb25lCitp
ZiAkYWNfY2FjaGVfY29ycnVwdGVkOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogY2hhbmdlcyBpbiB0aGUgZW52aXJvbm1lbnQgY2Fu
IGNvbXByb21pc2UgdGhlIGJ1aWxkIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjaGFu
Z2VzIGluIHRoZSBlbnZpcm9ubWVudCBjYW4gY29tcHJvbWlzZSB0aGUgYnVpbGQiID4mMjt9Cisg
IGFzX2ZuX2Vycm9yICQ/ICJydW4gXGBtYWtlIGRpc3RjbGVhbicgYW5kL29yIFxgcm0gJGNhY2hl
X2ZpbGUnIGFuZCBzdGFydCBvdmVyIiAiJExJTkVOTyIgNQorZmkKKyMjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tICMjCisjIyBNYWluIGJvZHkgb2Ygc2NyaXB0LiAjIworIyMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0gIyMKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxl
PSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5r
PSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNv
bmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBp
bGVyX2dudQorCisKKworYWNfY29uZmlnX2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIC4uL2NvbmZp
Zy9Ub29scy5tayIKKworYWNfY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVhZGVycyBjb25m
aWcuaCIKKworCithY19hdXhfZGlyPQorZm9yIGFjX2RpciBpbiAuICIkc3JjZGlyIi8uOyBkbwor
ICBpZiB0ZXN0IC1mICIkYWNfZGlyL2luc3RhbGwtc2giOyB0aGVuCisgICAgYWNfYXV4X2Rpcj0k
YWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvaW5zdGFsbC1zaCAtYyIKKyAg
ICBicmVhaworICBlbGlmIHRlc3QgLWYgIiRhY19kaXIvaW5zdGFsbC5zaCI7IHRoZW4KKyAgICBh
Y19hdXhfZGlyPSRhY19kaXIKKyAgICBhY19pbnN0YWxsX3NoPSIkYWNfYXV4X2Rpci9pbnN0YWxs
LnNoIC1jIgorICAgIGJyZWFrCisgIGVsaWYgdGVzdCAtZiAiJGFjX2Rpci9zaHRvb2wiOyB0aGVu
CisgICAgYWNfYXV4X2Rpcj0kYWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIv
c2h0b29sIGluc3RhbGwgLWMiCisgICAgYnJlYWsKKyAgZmkKK2RvbmUKK2lmIHRlc3QgLXogIiRh
Y19hdXhfZGlyIjsgdGhlbgorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgaW5zdGFsbC1z
aCwgaW5zdGFsbC5zaCwgb3Igc2h0b29sIGluIC4gXCIkc3JjZGlyXCIvLiIgIiRMSU5FTk8iIDUK
K2ZpCisKKyMgVGhlc2UgdGhyZWUgdmFyaWFibGVzIGFyZSB1bmRvY3VtZW50ZWQgYW5kIHVuc3Vw
cG9ydGVkLAorIyBhbmQgYXJlIGludGVuZGVkIHRvIGJlIHdpdGhkcmF3biBpbiBhIGZ1dHVyZSBB
dXRvY29uZiByZWxlYXNlLgorIyBUaGV5IGNhbiBjYXVzZSBzZXJpb3VzIHByb2JsZW1zIGlmIGEg
YnVpbGRlcidzIHNvdXJjZSB0cmVlIGlzIGluIGEgZGlyZWN0b3J5CisjIHdob3NlIGZ1bGwgbmFt
ZSBjb250YWlucyB1bnVzdWFsIGNoYXJhY3RlcnMuCithY19jb25maWdfZ3Vlc3M9IiRTSEVMTCAk
YWNfYXV4X2Rpci9jb25maWcuZ3Vlc3MiICAjIFBsZWFzZSBkb24ndCB1c2UgdGhpcyB2YXIuCith
Y19jb25maWdfc3ViPSIkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgICMgUGxlYXNlIGRv
bid0IHVzZSB0aGlzIHZhci4KK2FjX2NvbmZpZ3VyZT0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZp
Z3VyZSIgICMgUGxlYXNlIGRvbid0IHVzZSB0aGlzIHZhci4KKworCisKKyMgQ2hlY2sgaWYgQ0ZM
QUdTLCBMREZMQUdTLCBMSUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdh
cm5pbmcKKworaWYgdGVzdCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQ
IjsgdGhlbiA6CisKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFdBUk5JTkc6IFNldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3Ig
Q1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRf
TElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3Np
YmxlLiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBTZXR0aW5nIENDLCBDRkxBR1Ms
IExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVz
ZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBB
UFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS4iID4mMjt9CisKK2ZpCisKK2FjX2V4dD1j
CithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQ
UEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFj
X2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJT
ID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK2lmIHRlc3QgLW4g
IiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1nY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2
X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X0ND
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNf
Y3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iZ2NjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X0NDPSRhY19j
dl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQor
JGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBl
bHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIENDPSRh
Y19jdF9DQworICBmaQorZWxzZQorICBDQz0iJGFjX2N2X3Byb2dfQ0MiCitmaQorCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4Ijsg
dGhlbgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1j
YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHth
Y190b29sX3ByZWZpeH1jYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1u
ICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNo
byAibm8iID4mNjsgfQorZmkKKworCisgIGZpCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9
bm8KK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGlm
IHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhl
bgorICAgICAgIGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29udGludWUKKyAgICAgZmkK
KyAgICBhY19jdl9wcm9nX0NDPSJjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworaWYgdGVzdCAk
YWNfcHJvZ19yZWplY3RlZCA9IHllczsgdGhlbgorICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhl
IHBhdGgsIHNvIG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCisgIHNldCBkdW1teSAkYWNfY3Zf
cHJvZ19DQworICBzaGlmdAorICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KKyAgICAjIFdlIGNob3Nl
IGEgZGlmZmVyZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KKyAgICAjIEhvd2V2ZXIs
IGl0IGhhcyB0aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCisg
ICAgIyBmaXJzdCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVs
bCBmaWxlIG5hbWUuCisgICAgc2hpZnQKKyAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193
b3JkJHsxKycgJ30kQCIKKyAgZmkKK2ZpCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cisk
YXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgor
ICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNs
LmV4ZQorICBkbworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJl
Zml4JGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15ICRhY190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zf
cHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3By
ZWZpeCRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9w
cm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgdGVzdCAtbiAiJEND
IiAmJiBicmVhaworICBkb25lCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBhY19jdF9D
Qz0kQ0MKKyAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCitkbworICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAkYWNfcHJvZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNf
Y3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X2FjX2N0X0NDPSIkYWNfcHJvZyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh
ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19j
dF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0
X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKworICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCitkb25l
CisKKyAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKKyAgZWxzZQor
ICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBDQz0kYWNfY3Rf
Q0MKKyAgZmkKK2ZpCisKK2ZpCisKKwordGVzdCAteiAiJENDIiAmJiB7IHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRh
c19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9y
ICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQQVRICitTZWUgXGBjb25m
aWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorCisjIFByb3ZpZGUgc29t
ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCiskYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciB2ZXJzaW9uIiA+JjUKK3Nl
dCBYICRhY19jb21waWxlCithY19jb21waWxlcj0kMgorZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNp
b24gLXYgLVYgLXF2ZXJzaW9uOyBkbworICB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZXIgJGFjX29w
dGlvbiA+JjUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNf
dHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2
YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9l
Y2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jb21w
aWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBp
ZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgorICAgIHNlZCAnMTBhXAorLi4uIHJlc3Qgb2Yg
c3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgorICAgICAgICAgMTBxJyBjb25mdGVzdC5lcnIgPmNv
bmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1CisgIGZpCisgIHJtIC1mIGNvbmZ0
ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KK2Rv
bmUKKworY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOwor
fQorX0FDRU9GCithY19jbGVhbl9maWxlc19zYXZlPSRhY19jbGVhbl9maWxlcworYWNfY2xlYW5f
ZmlsZXM9IiRhY19jbGVhbl9maWxlcyBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGIub3V0IgorIyBU
cnkgdG8gY3JlYXRlIGFuIGV4ZWN1dGFibGUgd2l0aG91dCAtbyBmaXJzdCwgZGlzcmVnYXJkIGEu
b3V0LgorIyBJdCB3aWxsIGhlbHAgdXMgZGlhZ25vc2UgYnJva2VuIGNvbXBpbGVycywgYW5kIGZp
bmRpbmcgb3V0IGFuIGludHVpdGlvbgorIyBvZiBleGVleHQuCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29y
a3MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jr
cy4uLiAiID4mNjsgfQorYWNfbGlua19kZWZhdWx0PWAkYXNfZWNobyAiJGFjX2xpbmsiIHwgc2Vk
ICdzLyAtbyAqY29uZnRlc3RbXiBdKi8vJ2AKKworIyBUaGUgcG9zc2libGUgb3V0cHV0IGZpbGVz
OgorYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBhLmV4ZSBhX291dC5leGUg
Yi5vdXQgY29uZnRlc3QuKiIKKworYWNfcm1maWxlcz0KK2ZvciBhY19maWxlIGluICRhY19maWxl
cworZG8KKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRk
cyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8
ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKKyAgICAqICkgYWNfcm1maWxlcz0iJGFjX3JtZmls
ZXMgJGFjX2ZpbGUiOzsKKyAgZXNhYworZG9uZQorcm0gLWYgJGFjX3JtZmlsZXMKKworaWYgeyB7
IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8
ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRh
Y190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQor
ICAoZXZhbCAiJGFjX2xpbmtfZGVmYXVsdCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQor
ICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBBdXRvY29uZi0yLjEzIGNvdWxk
IHNldCB0aGUgYWNfY3ZfZXhlZXh0IHZhcmlhYmxlIHRvIGBubycuCisjIFNvIGlnbm9yZSBhIHZh
bHVlIG9mIGBubycsIG90aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQgdG8gYEVYRUVYVCA9IG5vJwor
IyBpbiBhIE1ha2VmaWxlLiAgV2Ugc2hvdWxkIG5vdCBvdmVycmlkZSBhY19jdl9leGVleHQgaWYg
aXQgd2FzIGNhY2hlZCwKKyMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlz
IHRlc3QgZm9yIGNvbXBpbGVycyB1bmtub3duIHRvCisjIEF1dG9jb25mLgorZm9yIGFjX2ZpbGUg
aW4gJGFjX2ZpbGVzICcnCitkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAg
Y2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8
ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8
ICoubyB8ICoub2JqICkKKwk7OworICAgIFthYl0ub3V0ICkKKwkjIFdlIGZvdW5kIHRoZSBkZWZh
dWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMgbW9zdAorCSMgY2VydGFpbmx5IHJpZ2h0
LgorCWJyZWFrOzsKKyAgICAqLiogKQorCWlmIHRlc3QgIiR7YWNfY3ZfZXhlZXh0K3NldH0iID0g
c2V0ICYmIHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5vOworCXRoZW4gOjsgZWxzZQorCSAgIGFj
X2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAorCWZpCisJIyBX
ZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUgYmVjYXVzZSB0aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMg
bm90CisJIyBzYWZlOiBjcm9zcyBjb21waWxlcnMgbWF5IG5vdCBhZGQgdGhlIHN1ZmZpeCBpZiBn
aXZlbiBhbiBgLW8nCisJIyBhcmd1bWVudCwgc28gd2UgbWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0
aGF0IHBvaW50IGFscmVhZHkuCisJIyBFdmVuIGlmIHRoaXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6
IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCisJIyBhY3R1YWxseSB3b3JraW5nLgorCWJyZWFrOzsK
KyAgICAqICkKKwlicmVhazs7CisgIGVzYWMKK2RvbmUKK3Rlc3QgIiRhY19jdl9leGVleHQiID0g
bm8gJiYgYWNfY3ZfZXhlZXh0PQorCitlbHNlCisgIGFjX2ZpbGU9JycKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfZmlsZSI7IHRoZW4gOgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyRhc19lY2hvICIk
YXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4k
YWNfZXh0ID4mNQorCit7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yIDc3ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVh
dGUgZXhlY3V0YWJsZXMKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElO
RU5PIiA1OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBk
ZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMg
Y29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lLi4uICIgPiY2OyB9Cit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQorJGFz
X2VjaG8gIiRhY19maWxlIiA+JjY7IH0KK2FjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0CisKK3JtIC1m
IC1yIGEub3V0IGEub3V0LmRTWU0gYS5leGUgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGIub3V0Cith
Y19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMuLi4gIiA+
JjY7IH0KK2lmIHsgeyBhY190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAq
XCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2Vj
aG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0g
PiY1CisgIChldmFsICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0
ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBJZiBib3RoIGBjb25mdGVzdC5leGUn
IGFuZCBgY29uZnRlc3QnIGFyZSBgcHJlc2VudCcgKHdlbGwsIG9ic2VydmFibGUpCisjIGNhdGNo
IGBjb25mdGVzdC5leGUnLiAgRm9yIGluc3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3Qn
IHdpbGwKKyMgd29yayBwcm9wZXJseSAoaS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScpLCB3
aGlsZSBpdCB3b24ndCB3aXRoCisjIGBybScuCitmb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUg
Y29uZnRlc3QgY29uZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVl
CisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAq
LmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRT
WU0gfCAqLm8gfCAqLm9iaiApIDs7CisgICAgKi4qICkgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNf
ZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCisJICBicmVhazs7CisgICAgKiApIGJyZWFrOzsKKyAg
ZXNhYworZG9uZQorZWxzZQorICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9y
OiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBz
dWZmaXggb2YgZXhlY3V0YWJsZXM6IGNhbm5vdCBjb21waWxlIGFuZCBsaW5rCitTZWUgXGBjb25m
aWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorZmkKK3JtIC1mIGNvbmZ0
ZXN0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9leGVleHQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9l
eGVleHQiID4mNjsgfQorCitybSAtZiBjb25mdGVzdC4kYWNfZXh0CitFWEVFWFQ9JGFjX2N2X2V4
ZWV4dAorYWNfZXhlZXh0PSRFWEVFWFQKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRpby5oPgor
aW50CittYWluICgpCit7CitGSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5vdXQiLCAidyIpOwor
IHJldHVybiBmZXJyb3IgKGYpIHx8IGZjbG9zZSAoZikgIT0gMDsKKworICA7CisgIHJldHVybiAw
OworfQorX0FDRU9GCithY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGNvbmZ0ZXN0Lm91
dCIKKyMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIgcHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2Fu
IHJ1bi4gIElmIG5vdCwgZWl0aGVyCisjIHRoZSBjb21waWxlciBpcyBicm9rZW4sIG9yIHdlIGNy
b3NzIGNvbXBpbGUuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZyIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciICE9IHllczsgdGhlbgorICB7IHsgYWNfdHJ5PSIkYWNfbGlu
ayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNo
bz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190
cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIK
KyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1
CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorICBpZiB7
IGFjX3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnki
IGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBh
Y190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9l
Y2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgfTsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGlu
Zz1ubworICBlbHNlCisgICAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSBtYXliZTsgdGhl
bgorCWNyb3NzX2NvbXBpbGluZz15ZXMKKyAgICBlbHNlCisJeyB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAi
Y2Fubm90IHJ1biBDIGNvbXBpbGVkIHByb2dyYW1zLgorSWYgeW91IG1lYW50IHRvIGNyb3NzIGNv
bXBpbGUsIHVzZSBcYC0taG9zdCcuCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxz
IiAiJExJTkVOTyIgNTsgfQorICAgIGZpCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRjcm9zc19jb21waWxpbmciID4mNQorJGFzX2Vj
aG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQorCitybSAtZiBjb25mdGVzdC4kYWNfZXh0IGNv
bmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5vdXQKK2FjX2NsZWFuX2ZpbGVzPSRhY19jbGVh
bl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X29i
amV4dCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgorcm0gLWYgY29uZnRlc3QubyBjb25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRh
Y19jb21waWxlIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFj
X3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitl
dmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlf
ZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29t
cGlsZSIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAw
OyB9OyB0aGVuIDoKKyAgZm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29u
ZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRh
Y19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIg
fCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAg
ICAqKSBhY19jdl9vYmpleHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAg
ICBicmVhazs7CisgIGVzYWMKK2RvbmUKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVk
IHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisK
K3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmls
ZXM6IGNhbm5vdCBjb21waWxlCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAi
JExJTkVOTyIgNTsgfQorZmkKK3JtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3Qu
JGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3Zfb2JqZXh0IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0K
K09CSkVYVD0kYWNfY3Zfb2JqZXh0CithY19vYmpleHQ9JE9CSkVYVAoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0
aGUgR05VIEMgY29tcGlsZXIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBh
cmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfY29t
cGlsZXJfZ251Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKyNpZm5kZWYgX19HTlVDX18K
KyAgICAgICBjaG9rZSBtZQorI2VuZGlmCisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jb21waWxlcl9n
bnU9eWVzCitlbHNlCisgIGFjX2NvbXBpbGVyX2dudT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorYWNfY3ZfY19jb21w
aWxlcl9nbnU9JGFjX2NvbXBpbGVyX2dudQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY1CiskYXNf
ZWNobyAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2NvbXBpbGVy
X2dudSA9IHllczsgdGhlbgorICBHQ0M9eWVzCitlbHNlCisgIEdDQz0KK2ZpCithY190ZXN0X0NG
TEFHUz0ke0NGTEFHUytzZXR9CithY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMg
LWciID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZy4uLiAi
ID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2NjX2crOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9JGFjX2Nf
d2Vycm9yX2ZsYWcKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCisgICBhY19jdl9wcm9nX2NjX2c9
bm8KKyAgIENGTEFHUz0iLWciCisgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19nPXllcworZWxzZQorICBDRkxBR1M9IiIKKyAg
ICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNl
CisgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZworCSBDRkxBR1M9Ii1n
IgorCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNf
Y3ZfcHJvZ19jY19nPXllcworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgYWNfY193ZXJy
b3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQoraWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9
IHNldDsgdGhlbgorICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCitlbGlmIHRlc3QgJGFjX2N2X3By
b2dfY2NfZyA9IHllczsgdGhlbgorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENG
TEFHUz0iLWcgLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPSItZyIKKyAgZmkKK2Vsc2UKKyAgaWYg
dGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1PMiIKKyAgZWxzZQorICAgIENG
TEFHUz0KKyAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9
CitpZiAke2FjX2N2X3Byb2dfY2NfYzg5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3NhdmVfQ0M9
JENDCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4K
KyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyogTW9zdCBv
ZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYu
c2guICAqLworc3RydWN0IGJ1ZiB7IGludCB4OyB9OworRklMRSAqICgqcmNzb3BlbikgKHN0cnVj
dCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBpKQorICAg
ICBjaGFyICoqcDsKKyAgICAgaW50IGk7Cit7CisgIHJldHVybiBwW2ldOworfQorc3RhdGljIGNo
YXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQoreworICBj
aGFyICpzOworICB2YV9saXN0IHY7CisgIHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAocCwgdmFf
YXJnICh2LGludCkpOworICB2YV9lbmQgKHYpOworICByZXR1cm4gczsKK30KKworLyogT1NGIDQu
MCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBo
YXMKKyAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXgg
Y2hhcmFjdGVyIGNvbnN0YW50cy4KKyAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5m
b3J0dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gnLiAgVGhl
IGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAor
ICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMg
b3V0IHRydWUsIGZvciBhbgorICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5
IHRvIHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1ZSBvbmx5
IHdpdGggLXN0ZC4gICovCitpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFd
OworCisvKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0
IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0
ZXIgY29uc3RhbnRzLiAgKi8KKyNkZWZpbmUgRk9PKHgpICd4JworaW50IHhsYzZfY2NfYXJyYXlb
Rk9PKGEpID09ICd4JyA/IDEgOiAtMV07CisKK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOwor
c3RydWN0IHMxIHtpbnQgKCpmKSAoaW50IGEpO307CitzdHJ1Y3QgczIge2ludCAoKmYpIChkb3Vi
bGUgYSk7fTsKK2ludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBi
dWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOworaW50IGFyZ2M7CitjaGFyICoq
YXJndjsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0g
IHx8ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitmb3IgYWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0
ZCBcCisJLUFlICItQWEgLURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKK2Rv
CisgIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgorICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19hcmcKK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0CisgIHRlc3QgIngkYWNfY3ZfcHJv
Z19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCitkb25lCitybSAtZiBjb25mdGVzdC4kYWNfZXh0
CitDQz0kYWNfc2F2ZV9DQworCitmaQorIyBBQ19DQUNIRV9WQUwKK2Nhc2UgIngkYWNfY3ZfcHJv
Z19jY19jODkiIGluCisgIHgpCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vbmUgbmVlZGVkIiA+JjUKKyRhc19lY2hvICJub25lIG5lZWRlZCIg
PiY2OyB9IDs7CisgIHhubykKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogdW5zdXBwb3J0ZWQiID4mNQorJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+
JjY7IH0gOzsKKyAgKikKKyAgICBDQz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2df
Y2NfYzg5IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7OworZXNh
YworaWYgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0aGVuIDoKKworZmkKKwor
YWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENG
TEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29u
ZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19l
eHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisK
K2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRD
RkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG93IHRvIHJ1
biB0aGUgQyBwcmVwcm9jZXNzb3IiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1
biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4gIiA+JjY7IH0KKyMgT24gU3Vucywgc29tZXRpbWVzICRD
UFAgbmFtZXMgYSBkaXJlY3RvcnkuCitpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIkQ1BQ
IjsgdGhlbgorICBDUFA9CitmaQoraWYgdGVzdCAteiAiJENQUCI7IHRoZW4KKyAgaWYgJHthY19j
dl9wcm9nX0NQUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgICAgICAjIERvdWJsZSBxdW90ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhw
YW5kZWQKKyAgICBmb3IgQ1BQIGluICIkQ0MgLUUiICIkQ0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIg
Ii9saWIvY3BwIgorICAgIGRvCisgICAgICBhY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19w
cmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhh
dCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2gg
Y3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5o
PiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2
ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVu
cyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0
aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNl
CisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlmCisJCSAgICAgU3ludGF4IGVycm9yCitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgICMgQnJv
a2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitmaQorcm0gLWYgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNhbmUg
Y2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2FuIGJl
IGRldGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlzdGVu
dC5oPgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAgIyBC
cm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMgUGFz
c2VzIGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFrCitmaQorcm0gLWYgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCitkb25lCisjIEJlY2F1c2Ugb2Yg
YGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4K
K3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKK2lmICRhY19w
cmVwcm9jX29rOyB0aGVuIDoKKyAgYnJlYWsKK2ZpCisKKyAgICBkb25lCisgICAgYWNfY3ZfcHJv
Z19DUFA9JENQUAorCitmaQorICBDUFA9JGFjX2N2X3Byb2dfQ1BQCitlbHNlCisgIGFjX2N2X3By
b2dfQ1BQPSRDUFAKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENQUCIgPiY1CiskYXNfZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29r
PWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNl
IGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMK
KyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1p
dHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxs
aW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0
aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNl
ciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBj
YXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRl
IDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlmCisJCSAgICAg
U3ludGF4IGVycm9yCitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4g
OgorCitlbHNlCisgICMgQnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitm
aQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMg
T0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBo
ZWFkZXJzCisgICMgY2FuIGJlIGRldGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxhY19ub25leGlzdGVudC5oPgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRp
bnVlCitlbHNlCisgICMgUGFzc2VzIGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFr
CitmaQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCitk
b25lCisjIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcg
Y29kZSB3YXMgc2tpcHBlZC4KK3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19leHQKK2lmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKKworZWxzZQorICB7IHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2Zu
X2Vycm9yICQ/ICJDIHByZXByb2Nlc3NvciBcIiRDUFBcIiBmYWlscyBzYW5pdHkgY2hlY2sKK1Nl
ZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9CitmaQorCith
Y19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZM
QUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25m
dGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4
dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKwor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3Jl
cCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9Citp
ZiAke2FjX2N2X3BhdGhfR1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgorICBhY19wYXRoX0dS
RVBfZm91bmQ9ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0
IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9i
aW4KK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfcHJvZyBpbiBncmVwIGdncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9HUkVQ
PSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0
aF9HUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBjb250aW51ZQorIyBD
aGVjayBmb3IgR05VIGFjX3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgor
ICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAorY2FzZSBgIiRhY19wYXRoX0dSRVAiIC0t
dmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JF
UCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19u
IDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29u
ZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0
LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgor
ICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX0dSRVAi
IC1lICdHUkVQJCcgLWUgJy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0
ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJj
b25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFj
X2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0
ICR7YWNfcGF0aF9HUkVQX21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNh
dmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBhY19jdl9wYXRo
X0dSRVA9IiRhY19wYXRoX0dSRVAiCisgICAgICBhY19wYXRoX0dSRVBfbWF4PSRhY19jb3VudAor
ICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVu
b3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25lCisgIHJtIC1m
IGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNh
YworCisgICAgICAkYWNfcGF0aF9HUkVQX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9H
UkVQIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGdyZXAgY291bGQg
YmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIg
NQorICBmaQorZWxzZQorICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKK2ZpCisKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JF
UCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2
X3BhdGhfR1JFUCIKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZWdyZXAu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9FR1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIGVjaG8gYSB8ICRHUkVQIC1FICco
YXxiKScgPi9kZXYvbnVsbCAyPiYxCisgICB0aGVuIGFjX2N2X3BhdGhfRUdSRVA9IiRHUkVQIC1F
IgorICAgZWxzZQorICAgICBpZiB0ZXN0IC16ICIkRUdSRVAiOyB0aGVuCisgIGFjX3BhdGhfRUdS
RVBfZm91bmQ9ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0
IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9i
aW4KK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfcHJvZyBpbiBlZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfRUdSRVA9IiRh
c19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0VH
UkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9FR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hl
Y2sgZm9yIEdOVSBhY19wYXRoX0VHUkVQIGFuZCBzZWxlY3QgaXQgaWYgaXQgaXMgZm91bmQuCisg
ICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9FR1JFUAorY2FzZSBgIiRhY19wYXRoX0VHUkVQIiAt
LXZlcnNpb24gMj4mMWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9F
R1JFUCIgYWNfcGF0aF9FR1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2Vj
aG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQg
ImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25m
dGVzdC50bXAiICJjb25mdGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5u
bCIKKyAgICAkYXNfZWNobyAnRUdSRVAnID4+ICJjb25mdGVzdC5ubCIKKyAgICAiJGFjX3BhdGhf
RUdSRVAiICdFR1JFUCQnIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251
bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYv
bnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19j
b3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9FR1JFUF9t
YXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxv
b2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhf
RUdSRVAiCisgICAgICBhY19wYXRoX0VHUkVQX21heD0kYWNfY291bnQKKyAgICBmaQorICAgICMg
MTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0ZXN0
ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5pbiBj
b25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAgJGFj
X3BhdGhfRUdSRVBfZm91bmQgJiYgYnJlYWsgMworICAgIGRvbmUKKyAgZG9uZQorICBkb25lCitJ
RlM9JGFzX3NhdmVfSUZTCisgIGlmIHRlc3QgLXogIiRhY19jdl9wYXRoX0VHUkVQIjsgdGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGVncmVwIGNvdWxkIGJlIGZvdW5kIGlu
ICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKK2Vs
c2UKKyAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAKK2ZpCisKKyAgIGZpCitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0VHUkVQ
IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcGF0aF9FR1JFUCIgPiY2OyB9CisgRUdSRVA9IiRhY19j
dl9wYXRoX0VHUkVQIgorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVh
ZGVyX3N0ZGMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl
bmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RkYXJn
Lmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8ZmxvYXQuaD4KKworaW50CittYWlu
ICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3RkYz15ZXMKK2Vsc2UKKyAg
YWNfY3ZfaGVhZGVyX3N0ZGM9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0
ZGMgPSB5ZXM7IHRoZW4KKyAgIyBTdW5PUyA0Lnggc3RyaW5nLmggZG9lcyBub3QgZGVjbGFyZSBt
ZW0qLCBjb250cmFyeSB0byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RyaW5nLmg+
CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAor
ICAkRUdSRVAgIm1lbWNociIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKworZWxzZQorICBhY19j
dl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQorCitpZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2Vz
IG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxzdGRsaWIuaD4KKworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNf
ZXh0IikgMj4mNSB8CisgICRFR1JFUCAiZnJlZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKwor
ZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQor
CitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4vY2MgaW4g
SXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2ku
CisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgorZWxzZQor
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u
ZmRlZnMuaC4gICovCisjaW5jbHVkZSA8Y3R5cGUuaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNp
ZiAoKCcgJyAmIDB4MEZGKSA9PSAweDAyMCkKKyMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAo
YykgJiYgKGMpIDw9ICd6JykKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAnQScg
KyAoKGMpIC0gJ2EnKSA6IChjKSkKKyNlbHNlCisjIGRlZmluZSBJU0xPV0VSKGMpIFwKKwkJICAg
KCgnYScgPD0gKGMpICYmIChjKSA8PSAnaScpIFwKKwkJICAgICB8fCAoJ2onIDw9IChjKSAmJiAo
YykgPD0gJ3InKSBcCisJCSAgICAgfHwgKCdzJyA8PSAoYykgJiYgKGMpIDw9ICd6JykpCisjIGRl
ZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gKChjKSB8IDB4NDApIDogKGMpKQorI2VuZGlm
CisKKyNkZWZpbmUgWE9SKGUsIGYpICgoKGUpICYmICEoZikpIHx8ICghKGUpICYmIChmKSkpCitp
bnQKK21haW4gKCkKK3sKKyAgaW50IGk7CisgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKKyAg
ICBpZiAoWE9SIChpc2xvd2VyIChpKSwgSVNMT1dFUiAoaSkpCisJfHwgdG91cHBlciAoaSkgIT0g
VE9VUFBFUiAoaSkpCisgICAgICByZXR1cm4gMjsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRl
cl9zdGRjPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0
IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUK
KyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfaGVh
ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEi
ID4+Y29uZmRlZnMuaAorCitmaQorCisjIE9uIElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5
cGVzLmggYXJlIGNvbmZsaWN0aW5nLgorZm9yIGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMv
c3RhdC5oIHN0ZGxpYi5oIHN0cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBcCisJCSAgaW50dHlw
ZXMuaCBzdGRpbnQuaCB1bmlzdGQuaAorZG8gOgorICBhc19hY19IZWFkZXI9YCRhc19lY2hvICJh
Y19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2hlYWRl
cl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5j
bHVkZXNfZGVmYXVsdAorIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4
InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNf
ZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorCitk
b25lCisKKworCisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJtaW5p
eC9jb25maWcuaCIgImFjX2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giID0geHllczsg
dGhlbiA6CisgIE1JTklYPXllcworZWxzZQorICBNSU5JWD0KK2ZpCisKKworICBpZiB0ZXN0ICIk
TUlOSVgiID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIg
Pj5jb25mZGVmcy5oCisKKworJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+
Y29uZmRlZnMuaAorCisKKyRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZkZWZzLmgK
KworICBmaQorCisKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkZWZpbmUgX19FWFRF
TlNJT05TX18uLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNp
b25zX18rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKKyMJICBkZWZpbmUgX19FWFRFTlNJT05TX18gMQorCSAgJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9Citf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zf
c2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX189eWVzCitlbHNlCisgIGFjX2N2X3NhZmVfdG9f
ZGVmaW5lX19fZXh0ZW5zaW9uc19fPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4
dGVuc2lvbnNfXyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5z
aW9uc19fIiA+JjY7IH0KKyAgdGVzdCAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25z
X18gPSB5ZXMgJiYKKyAgICAkYXNfZWNobyAiI2RlZmluZSBfX0VYVEVOU0lPTlNfXyAxIiA+PmNv
bmZkZWZzLmgKKworICAkYXNfZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNvbmZkZWZz
LmgKKworICAkYXNfZWNobyAiI2RlZmluZSBfR05VX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKKwor
ICAkYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MgMSIgPj5jb25mZGVm
cy5oCisKKyAgJGFzX2VjaG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5o
CisKKworIyBNYWtlIHN1cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgorJFNIRUxMICIkYWNfYXV4
X2Rpci9jb25maWcuc3ViIiBzdW40ID4vZGV2L251bGwgMj4mMSB8fAorICBhc19mbl9lcnJvciAk
PyAiY2Fubm90IHJ1biAkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgIiRMSU5FTk8iIDUK
KworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBidWls
ZCBzeXN0ZW0gdHlwZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlw
ZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9idWlsZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2J1aWxkX2FsaWFzPSRidWlsZF9hbGlh
cwordGVzdCAieCRhY19idWlsZF9hbGlhcyIgPSB4ICYmCisgIGFjX2J1aWxkX2FsaWFzPWAkU0hF
TEwgIiRhY19hdXhfZGlyL2NvbmZpZy5ndWVzcyJgCit0ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9
IHggJiYKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBndWVzcyBidWlsZCB0eXBlOyB5b3UgbXVz
dCBzcGVjaWZ5IG9uZSIgIiRMSU5FTk8iIDUKK2FjX2N2X2J1aWxkPWAkU0hFTEwgIiRhY19hdXhf
ZGlyL2NvbmZpZy5zdWIiICRhY19idWlsZF9hbGlhc2AgfHwKKyAgYXNfZm5fZXJyb3IgJD8gIiRT
SEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViICRhY19idWlsZF9hbGlhcyBmYWlsZWQiICIkTElO
RU5PIiA1CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2J1aWxkIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfYnVpbGQiID4mNjsgfQor
Y2FzZSAkYWNfY3ZfYnVpbGQgaW4KKyotKi0qKSA7OworKikgYXNfZm5fZXJyb3IgJD8gImludmFs
aWQgdmFsdWUgb2YgY2Fub25pY2FsIGJ1aWxkIiAiJExJTkVOTyIgNTs7Citlc2FjCitidWlsZD0k
YWNfY3ZfYnVpbGQKK2FjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4ICRhY19jdl9idWls
ZAorc2hpZnQKK2J1aWxkX2NwdT0kMQorYnVpbGRfdmVuZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMg
UmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQq
LAorIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgorYnVpbGRfb3M9JCoKK0lGUz0kYWNfc2F2ZV9J
RlMKK2Nhc2UgJGJ1aWxkX29zIGluICpcICopIGJ1aWxkX29zPWBlY2hvICIkYnVpbGRfb3MiIHwg
c2VkICdzLyAvLS9nJ2A7OyBlc2FjCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaG9zdCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgIngkaG9zdF9hbGlhcyIgPSB4OyB0aGVuCisgIGFjX2N2X2hvc3Q9JGFjX2N2X2J1aWxkCitl
bHNlCisgIGFjX2N2X2hvc3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhvc3Rf
YWxpYXNgIHx8CisgICAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWcu
c3ViICRob3N0X2FsaWFzIGZhaWxlZCIgIiRMSU5FTk8iIDUKK2ZpCisKK2ZpCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hvc3QiID4mNQor
JGFzX2VjaG8gIiRhY19jdl9ob3N0IiA+JjY7IH0KK2Nhc2UgJGFjX2N2X2hvc3QgaW4KKyotKi0q
KSA7OworKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGhvc3Qi
ICIkTElORU5PIiA1OzsKK2VzYWMKK2hvc3Q9JGFjX2N2X2hvc3QKK2FjX3NhdmVfSUZTPSRJRlM7
IElGUz0nLScKK3NldCB4ICRhY19jdl9ob3N0CitzaGlmdAoraG9zdF9jcHU9JDEKK2hvc3RfdmVu
ZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2Yg
SUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAorIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgoraG9z
dF9vcz0kKgorSUZTPSRhY19zYXZlX0lGUworY2FzZSAkaG9zdF9vcyBpbiAqXCAqKSBob3N0X29z
PWBlY2hvICIkaG9zdF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKworCisKKyMgTTQgTWFj
cm8gaW5jbHVkZXMKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKwor
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKyMgRW5h
YmxlL2Rpc2FibGUgb3B0aW9ucworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhzbSB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV94c20rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2
YWw9JGVuYWJsZV94c207CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieHllcyI7
IHRoZW4gOgorCisgICAgYXhfY3ZfeHNtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hzbSIg
PSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl94c209Im4iCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfeHNtOyB0aGVuIDoKKworICAgIGF4X2N2X3hzbT0ibiIKKworZmkKK3hzbT0kYXhfY3ZfeHNt
CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3Qg
IiR7ZW5hYmxlX2dpdGh0dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJs
ZV9naXRodHRwOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsg
dGhlbiA6CisKKyAgICBheF9jdl9naXRodHRwPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2dp
dGh0dHAiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKKworZWxpZiB0
ZXN0IC16ICRheF9jdl9naXRodHRwOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9Im4iCisK
K2ZpCitnaXRodHRwPSRheF9jdl9naXRodHRwCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1t
b25pdG9ycyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNl
dDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX21vbml0b3JzOworZmkKKworCitpZiB0ZXN0
ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9y
cz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgor
CisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7
IHRoZW4gOgorCisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCisKK2ZpCittb25pdG9ycz0kYXhfY3Zf
bW9uaXRvcnMKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgoraWYg
dGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX3Z0cG07CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVu
IDoKKworICAgIGF4X2N2X3Z0cG09InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl92dHBtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2
X3Z0cG07IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ibiIKKworZmkKK3Z0cG09JGF4X2N2X3Z0
cG0KKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhhcGkgd2FzIGdpdmVuLgoraWYgdGVzdCAi
JHtlbmFibGVfeGFwaStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hh
cGk7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hhcGkiID0gInh5ZXMiOyB0aGVuIDoKKwor
ICAgIGF4X2N2X3hhcGk9InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieG5vIjsg
dGhlbiA6CisKKyAgICBheF9jdl94YXBpPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hhcGk7
IHRoZW4gOgorCisgICAgYXhfY3ZfeGFwaT0ibiIKKworZmkKK3hhcGk9JGF4X2N2X3hhcGkKKwor
IyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3Qg
IiR7ZW5hYmxlX3B5dGhvbnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRl
bmFibGVfcHl0aG9udG9vbHM7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xz
IiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJuIgorCitlbGlmIHRl
c3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9w
eXRob250b29scz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250b29sczsgdGhlbiA6
CisKKyAgICBheF9jdl9weXRob250b29scz0ieSIKKworZmkKK3B5dGhvbnRvb2xzPSRheF9jdl9w
eXRob250b29scworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg
ZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVf
b2NhbWx0b29scyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgor
CitlbGlmIHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAg
IGF4X2N2X29jYW1sdG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsg
dGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgorCitmaQorb2NhbWx0b29scz0kYXhf
Y3Zfb2NhbWx0b29scworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdp
dmVuLgoraWYgdGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBl
bmFibGV2YWw9JGVuYWJsZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWlu
aXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5IgorCitlbGlm
IHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X21p
bml0ZXJtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAg
IGF4X2N2X21pbml0ZXJtPSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKyMg
Q2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5h
YmxlX2xvbW91bnQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21v
dW50OworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6
CisKKyAgICBheF9jdl9sb21vdW50PSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQi
ID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIKKworZWxpZiB0ZXN0IC16
ICRheF9jdl9sb21vdW50OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9Im4iCisKK2ZpCits
b21vdW50PSRheF9jdl9sb21vdW50CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3
YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9kZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6Cisg
IGVuYWJsZXZhbD0kZW5hYmxlX2RlYnVnOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1
ZyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9kZWJ1ZyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisK
K2VsaWYgdGVzdCAteiAkYXhfY3ZfZGVidWc7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9Inki
CisKK2ZpCitkZWJ1Zz0kYXhfY3ZfZGVidWcKKworCisKKworCisKKworZm9yIGNmbGFnIGluICRQ
UkVQRU5EX0lOQ0xVREVTCitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9u
ZQorZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0i
IC1MJGxkZmxhZyIKK2RvbmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAg
IEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRf
TElCCitkbworICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0i
JFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVO
RF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFHUyIKKworCisKKworCisKKworCisKKwor
CisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0
cHV0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRy
dW5jYXRlIG91dHB1dC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1NFRCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAgICAgICBh
Y19zY3JpcHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJi
YmJiYmJiYmJiYmJiYmJiYmJiYmJiYmIvCisgICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7
IGRvCisgICAgICAgYWNfc2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKKyAgICAg
ZG9uZQorICAgICBlY2hvICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0
ZXN0LnNlZAorICAgICB7IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9CisgICAgIGlmIHRl
c3QgLXogIiRTRUQiOyB0aGVuCisgIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0
aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNU
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfU0VE
PSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0
aF9TRUQiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKKyMgQ2hl
Y2sgZm9yIEdOVSBhY19wYXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAj
IENoZWNrIGZvciBHTlUgJGFjX3BhdGhfU0VECitjYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNp
b24gMj4mMWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19w
YXRoX1NFRF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2
Nzg5ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0Lmlu
IiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJj
b25mdGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNf
ZWNobyAnJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Qu
c2VkIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsK
KyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8
IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFs
CisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCisg
ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl
dHRlciBvbmUKKyAgICAgIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCisgICAgICBhY19w
YXRoX1NFRF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBp
bnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYm
IGJyZWFrCisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0
Lm5sIGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBi
cmVhayAzCisgICAgZG9uZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYg
dGVzdCAteiAiJGFjX2N2X3BhdGhfU0VEIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBh
Y2NlcHRhYmxlIHNlZCBjb3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1CisgIGZp
CitlbHNlCisgIGFjX2N2X3BhdGhfU0VEPSRTRUQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKKyRh
c19lY2hvICIkYWNfY3ZfcGF0aF9TRUQiID4mNjsgfQorIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgor
ICBybSAtZiBjb25mdGVzdC5zZWQKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1Mn
CithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+
JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdT
ICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRh
Y19jdl9jX2NvbXBpbGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xf
cHJlZml4fWdjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm
b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k
YXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgor
ICBhY19jdF9DQz0kQ0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0
aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3Qg
LW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNf
Y3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNlCisgIEND
PSIkYWNfY3ZfcHJvZ19DQyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgICAgICAg
ICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2Fz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgK
K2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
KyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
KyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3By
b2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNo
byAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAg
ZmkKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15IGNjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKKyAgYWNfcHJvZ19yZWplY3RlZD1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3Rl
ZD15ZXMKKyAgICAgICBjb250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0
aGVuCisgICMgV2UgZm91bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5l
dmVyIHVzZSBpdC4KKyAgc2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRl
c3QgJCMgIT0gMDsgdGhlbgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJv
bSB0aGUgYm9ndXMgb25lLgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1l
LCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0
byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAor
ICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQorZmkK
K2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Cisk
YXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQor
CisKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCisgIGRvCisgICAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFj
X3Byb2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcHJvZ19DQz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFz
X3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIg
PiY2OyB9CitmaQorCisKKyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitp
ZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBj
bC5leGUKK2RvCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBh
Y193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9D
QyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0ND
CitpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19j
dF9DQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRl
c3QgLW4gIiRhY19jdF9DQyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0ND
IiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5n
OiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGgg
aG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2Fy
bmVkPXllcyA7OworZXNhYworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0
ZXN0IC16ICIkQ0MiICYmIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGlu
IFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21w
aWxlciBmb3VuZCBpbiBcJFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMi
ICIkTElORU5PIiA1OyB9CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBj
b21waWxlci4KKyRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBp
bGVyPSQyCitmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisg
IHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3Ry
eSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICop
IGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5
X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5j
b25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0
aGVuCisgICAgc2VkICcxMGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4u
CisgICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0
ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBH
TlUgQyBjb21waWxlciIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1
c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19jb21waWxl
cl9nbnUrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworI2lmbmRlZiBfX0dOVUNfXworICAg
ICAgIGNob2tlIG1lCisjZW5kaWYKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2NvbXBpbGVyX2dudT15
ZXMKK2Vsc2UKKyAgYWNfY29tcGlsZXJfZ251PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9jX2NvbXBpbGVy
X2dudT0kYWNfY29tcGlsZXJfZ251CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251
ID0geWVzOyB0aGVuCisgIEdDQz15ZXMKK2Vsc2UKKyAgR0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdT
PSR7Q0ZMQUdTK3NldH0KK2FjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3Byb2dfY2NfZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJy
b3JfZmxhZworICAgYWNfY193ZXJyb3JfZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubwor
ICAgQ0ZMQUdTPSItZyIKKyAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOwor
ICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAg
YWNfY193ZXJyb3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJ
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19B
Q0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9w
cm9nX2NjX2c9eWVzCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9m
bGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X3Byb2dfY2NfZyIgPiY2OyB9CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0
OyB0aGVuCisgIENGTEFHUz0kYWNfc2F2ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19j
Y19nID0geWVzOyB0aGVuCisgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdT
PSItZyAtTzIiCisgIGVsc2UKKyAgICBDRkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0
ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdT
PQorICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19jY19jODkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MK
K2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2lu
Y2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRo
ZSBmb2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4g
ICovCitzdHJ1Y3QgYnVmIHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1
ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNo
YXIgKipwOworICAgICBpbnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAq
ZiAoY2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIg
KnM7CisgIHZhX2xpc3QgdjsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcg
KHYsaW50KSk7CisgIHZhX2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENv
bXBhcSBjYyBpcyBzb21lIHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcwor
ICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFy
YWN0ZXIgY29uc3RhbnRzLgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1
bmF0ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9s
bG93aW5nIGluZHVjZXMgYW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBw
cm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQg
dHJ1ZSwgZm9yIGFuCisgICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8g
d3JpdGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0
aCAtc3RkLiAgKi8KK2ludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisK
Ky8qIElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVw
bGFjZXMgbWFjcm8gcGFyYW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBj
b25zdGFudHMuICAqLworI2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08o
YSkgPT0gJ3gnID8gMSA6IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1
Y3QgczEge2ludCAoKmYpIChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBh
KTt9OworaW50IHBhaXJuYW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAq
LCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2
OworaW50CittYWluICgpCit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwg
IGYgKGUsIGFyZ3YsIDEpICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2ZvciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwK
KwktQWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAg
Q0M9IiRhY19zYXZlX0NDICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2Nj
X2M4OSIgIT0gInhubyIgJiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0ND
PSRhY19zYXZlX0NDCisKK2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2Nj
X2M4OSIgaW4KKyAgeCkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7
IH0gOzsKKyAgeG5vKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsg
fSA7OworICAqKQorICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19j
ODkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitp
ZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19l
eHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdT
ICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVz
dCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAk
TElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAt
cyB3b3JrcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4u
ICIgPiY2OyB9CitMTl9TPSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMi
ID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2Vj
aG8gIm5vLCB1c2luZyAkTE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQo
TUFLRSkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0
cyBcJChNQUtFKS4uLiAiID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNf
ZWNobyAiJDIiIHwgc2VkICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwg
XCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9B
Q0VPRgorU0hFTEwgPSAvYmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUl
JScKK19BQ0VPRgorIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmlu
ZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNv
bmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUlKikKKyAgICBl
dmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQorICAgIGV2YWwg
YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1mIGNvbmZ0ZXN0
Lm1ha2UKK2ZpCitpZiBldmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQg
PSB5ZXM7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0i
CitmaQorCisjIEZpbmQgYSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJv
Z3JhbSAoZmFzdGVyKSwKKyMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBC
dXQgYXZvaWQgdGhlIGJyb2tlbiBvcgorIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6CisjIFN5c1Yg
L2V0Yy9pbnN0YWxsLCAvdXNyL3NiaW4vaW5zdGFsbAorIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxs
CisjIElSSVggL3NiaW4vaW5zdGFsbAorIyBBSVggL2Jpbi9pbnN0YWxsCisjIEFtaWdhT1MgL0Mv
aW5zdGFsbCwgd2hpY2ggaW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKKyMgQUlY
IDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBm
bGFnCisjIEFGUyAvdXNyL2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4
aXN0ZW50IGFyZ3MKKyMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2Ug
dGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiIKKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3
aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYworIyAuL2luc3RhbGwsIHdo
aWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2gu
CisjIFJlamVjdCBpbnN0YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUg
ZmlsZXMuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQoraWYgdGVzdCAteiAiJElO
U1RBTEwiOyB0aGVuCitpZiAke2FjX2N2X3BhdGhfaW5zdGFsbCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAjIEFjY291bnQgZm9y
IHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KK2Nhc2Ug
JGFzX2Rpci8gaW4gIygoCisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0Yy8qIHwgL3Vz
ci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCisg
ID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11JTlNUQUxMW1xc
L10qIHwgXAorICAvdXNyL3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5kIFNDTyBPRFQg
My4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9uJ3QgdXNlIGlu
c3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9vdAorICAgICMg
YnkgZGVmYXVsdC4KKyAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0IGluc3RhbGw7
IGRvCisgICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKwlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVuCisJICBpZiB0
ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFzX2Rpci8kYWNf
cHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgQUlYIGluc3Rh
bGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KKwkgICAgOgor
CSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3cGx1cyAiJGFz
X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMg
cHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3Qg
dXNlLgorCSAgICA6CisJICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3Qu
dHdvIGNvbmZ0ZXN0LmRpcgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQorCSAgICBlY2hv
IHR3byA+IGNvbmZ0ZXN0LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkgICAgaWYgIiRh
c19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28g
ImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0
ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0
ZXN0Lm9uZSAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0LnR3bworCSAg
ICB0aGVuCisJICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4
ZWNfZXh0IC1jIgorCSAgICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkKKyAgICAgIGRv
bmUKKyAgICBkb25lCisgICAgOzsKK2VzYWMKKworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
K3JtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCitmaQorICBp
ZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgorICAgIElOU1RB
TEw9JGFjX2N2X3BhdGhfaW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1
c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMgdmFsdWUgZm9y
IElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKKyAg
ICAjIGJyZWFrIG90aGVyIHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0IGRpcmVjdG9y
eSBpcworICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUgbmFtZS4K
KyAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIk
SU5TVEFMTCIgPiY2OyB9CisKKyMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFu
ZGxlcyBicmFjZXMgaW4gJHt2YXItdmFsfS4KKyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBi
cmFjZSBlbmRzIHRoZSB2YXJpYWJsZSBzdWJzdGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9Q
Uk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNU
QUxMX1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJ
TlNUQUxMX0RBVEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Bh
dGhfUEVSTCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGNhc2UgJFBFUkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhf
UEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRo
LgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm
b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KKyAgICBhY19jdl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYg
YWNfY3ZfcGF0aF9QRVJMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitQRVJMPSRhY19jdl9wYXRoX1BF
UkwKK2lmIHRlc3QgLW4gIiRQRVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke1BF
Ukx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBw
ZXJsLCBwbGVhc2UgaW5zdGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiYnJjdGwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IGJyY3RsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9CUkNU
TCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGNhc2UgJEJSQ1RMIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JSQ1RM
PSIkQlJDVEwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor
ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KKyAgICBhY19jdl9wYXRoX0JSQ1RMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JSQ1RMIiAmJiBh
Y19jdl9wYXRoX0JSQ1RMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCUkNUTD0kYWNfY3ZfcGF0aF9C
UkNUTAoraWYgdGVzdCAtbiAiJEJSQ1RMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEJSQ1RMIiA+JjUKKyRhc19lY2hvICIkQlJDVEwi
ID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4
IiR7QlJDVEx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8g
ZmluZCBicmN0bCwgcGxlYXNlIGluc3RhbGwgYnJjdGwiICIkTElORU5PIiA1CitmaQorIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJpcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgaXA7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0lQ
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkSVAgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSVA9IiRJUCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICop
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFj
X2N2X3BhdGhfSVA9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfSVAiICYmIGFjX2N2X3BhdGhfSVA9Im5v
IgorICA7OworZXNhYworZmkKK0lQPSRhY19jdl9wYXRoX0lQCitpZiB0ZXN0IC1uICIkSVAiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
SVAiID4mNQorJGFzX2VjaG8gIiRJUCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKKworCitpZiB0ZXN0IHgiJHtJUH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5f
ZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGlwLCBwbGVhc2UgaW5zdGFsbCBpcCIgIiRMSU5FTk8i
IDUKK2ZpCisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
CitpZiAke2FjX2N2X3BhdGhfQklTT04rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9d
KikKKyAgYWNfY3ZfcGF0aF9CSVNPTj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CSVNPTj0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh
ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIk
YWNfY3ZfcGF0aF9CSVNPTiIgJiYgYWNfY3ZfcGF0aF9CSVNPTj0ibm8iCisgIDs7Citlc2FjCitm
aQorQklTT049JGFjX2N2X3BhdGhfQklTT04KK2lmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIg
PiY1CiskYXNfZWNobyAiJEJJU09OIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JJU09OfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19m
bl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmlzb24sIHBsZWFzZSBpbnN0YWxsIGJpc29uIiAi
JExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgZmxleDsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3BhdGhfRkxFWCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEZMRVggaW4KKyAgW1xcL10qIHwgPzpb
XFwvXSopCisgIGFjX2N2X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAi
JGFjX2N2X3BhdGhfRkxFWCIgJiYgYWNfY3ZfcGF0aF9GTEVYPSJubyIKKyAgOzsKK2VzYWMKK2Zp
CitGTEVYPSRhY19jdl9wYXRoX0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQor
JGFzX2VjaG8gIiRGTEVYIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9Citm
aQorCisKK2lmIHRlc3QgeCIke0ZMRVh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9y
ICQ/ICJVbmFibGUgdG8gZmluZCBmbGV4LCBwbGVhc2UgaW5zdGFsbCBmbGV4IiAiJExJTkVOTyIg
NQorZmkKK2lmIHRlc3QgIngkeGFwaSIgPSAieHkiOyB0aGVuIDoKKworICAgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcGF0aF9DVVJMKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgY2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNf
Y3ZfcGF0aF9DVVJMPSIkQ1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0
aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitk
b25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9D
VVJMIiAmJiBhY19jdl9wYXRoX0NVUkw9Im5vIgorICA7OworZXNhYworZmkKK0NVUkw9JGFjX2N2
X3BhdGhfQ1VSTAoraWYgdGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENV
UkwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVz
dCB4IiR7Q1VSTH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8i
IDUKK2ZpCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25m
aWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1hNTCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhNTCBpbgorICBbXFwv
XSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hNTD0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMK
K2ZpCitYTUw9JGFjX2N2X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1Cisk
YXNfZWNobyAiJFhNTCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworCitpZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/
ICJVbmFibGUgdG8gZmluZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWci
ICIkTElORU5PIiA1CitmaQorCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRo
ZW4gOgorCisgICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgaWYgdGVzdCAtbiAiJGFjX3Rv
b2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
K3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3Byb2dfT0NBTUxDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19P
Q0FNTEM9IiRPQ0FNTEMiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQor
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU
SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf
cHJvZ19PQ0FNTEM9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK09DQU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FN
TEMiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkT0NBTUxDIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19P
Q0FNTEMiOyB0aGVuCisgIGFjX2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBvY2FtbGM7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDPSIkYWNfY3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSJvY2FtbGMiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKK2ZpCitmaQorYWNfY3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19j
dF9PQ0FNTEMiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9PQ0FNTEMiID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCisgIGVs
c2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBj
cm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxD
PSRhY19jdF9PQ0FNTEMKKyAgZmkKK2Vsc2UKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMi
CitmaQorCisKKyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZF
UlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxw
J2AKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IE9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVy
c2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQs
IHVzZSBpdAorICAgICBpZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NB
TUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxj
dXQgLWQgJyAnIC1mIDRgCisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVz
ZXJ2aW5nIGl0LiIgPiY1CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNl
cnZpbmcgaXQuIiA+JjY7IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIi
ID4mNQorJGFzX2VjaG8gIk9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQor
CisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRh
Y190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNf
d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0K
K2lmICR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19PQ0FNTE9QVD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NB
TUxPUFQKK2lmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAi
JE9DQU1MT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
K2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NB
TUxPUFQ9JE9DQU1MT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1s
b3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0i
JGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4m
NQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitm
aQorZmkKK2FjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRh
Y19jdF9PQ0FNTE9QVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0i
bm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisg
ICAgT0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCisgIGZpCitlbHNlCisgIE9DQU1MT1BUPSIkYWNf
Y3ZfcHJvZ19PQ0FNTE9QVCIKK2ZpCisKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVz
dCAiJE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21w
aWxhdGlvbiBvbmx5LiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmlu
ZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UK
KwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCgu
KlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7
IHRoZW4KKwkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4m
NQorJGFzX2VjaG8gInZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2Nh
cmRlZC4iID4mNjsgfQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9w
dAorCWZpCisgICAgIGZpCisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAg
ICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2Ft
bGMub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9D
QU1MQ0RPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X09DQU1MQ0RPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0IgorICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19z
YXZlX0lGUworCitmaQorZmkKK09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQK
K2lmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hv
ICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9Citm
aQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCisg
IGFjX2N0X09DQU1MQ0RPVE9QVD0kT0NBTUxDRE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgb2NhbWxjLm9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2df
YWNfY3RfT0NBTUxDRE9UT1BUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENE
T1RPUFQ9Im9jYW1sYy5vcHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3Rf
T0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8g
IiRhY19jdF9PQ0FNTENET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgorICAg
IE9DQU1MQ0RPVE9QVD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFj
X3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9v
bHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9
eWVzIDs7Citlc2FjCisgICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKKyAgZmkK
K2Vsc2UKKyAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCitmaQorCisg
ICAgIGlmIHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAk
T0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcg
YAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9u
cyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2Vj
aG8gInZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIg
PiY2OyB9CisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisK
KyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9Q
VCIgIT0gIm5vIiA7IHRoZW4KKwlpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5v
cHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJv
Z19PQ0FNTE9QVERPVE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxvcHQub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1M
T1BURE9UT1BUPSRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxP
UFRET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkT0NBTUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVERPVE9Q
VCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
Im9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE9QVERPVE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BU
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFRET1RPUFQ9Im9jYW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2Zp
CithY19jdF9PQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAor
aWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BU
IiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor
JGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERP
VE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg
PiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRh
Y19jdF9PQ0FNTE9QVERPVE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2
X3Byb2dfT0NBTUxPUFRET1RPUFQiCitmaQorCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAh
PSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1u
IC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJT
SU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1s
Yzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb24gZGlmZmVy
cyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgIGVsc2UK
KwkgICAgICBPQ0FNTE9QVD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAg
ICBmaQorCisKKyAgZmkKKworCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dv
cmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi
ID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgor
ICBhY19jdl9wcm9nX09DQU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcHJvZ19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKKyAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k
YXNfc2F2ZV9JRlMKKworZmkKK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAt
biAiJE9DQU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJE9DQU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9w
cm9nX09DQU1MIjsgdGhlbgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgb2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MPSIkYWNfY3RfT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgor
ZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBp
biAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0ib2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorYWNfY3RfT0NBTUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRh
Y19jdF9PQ0FNTCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngk
YWNfY3RfT0NBTUwiID0geDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2Ug
JGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJO
SU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4m
Mjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwK
KyAgZmkKK2Vsc2UKKyAgT0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgorZmkKKworCisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sZGVwCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVw
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FN
TERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0i
JE9DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
T0NBTUxERVA9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKK2ZpCitmaQorT0NBTUxERVA9JGFjX2N2X3Byb2dfT0NBTUxERVAKK2lmIHRlc3QgLW4gIiRP
Q0FNTERFUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRPQ0FNTERFUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNf
Y3ZfcHJvZ19PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7
IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9
Im9jYW1sZGVwIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MREVQ
PSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAi
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3RfT0NBTUxERVAiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0
X09DQU1MREVQIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNl
ICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09D
QU1MREVQCisgIGZpCitlbHNlCisgIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKK2Zp
CisKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sbWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Citp
ZiAke2FjX2N2X3Byb2dfT0NBTUxNS1RPUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgor
ICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29sX3ByZWZpeH1v
Y2FtbG1rdG9wIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MTUtUT1A9JGFj
X2N2X3Byb2dfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RP
UCIgPiY1CiskYXNfZWNobyAiJE9DQU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtU
T1AiOyB0aGVuCisgIGFjX2N0X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICJvY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0
aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0X09DQU1MTUtUT1AiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1L
VE9QPSJvY2FtbG1rdG9wIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09D
QU1MTUtUT1A9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJGFjX2N0
X09DQU1MTUtUT1AiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09D
QU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJu
byIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4K
K3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6
IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAg
ICBPQ0FNTE1LVE9QPSRhY19jdF9PQ0FNTE1LVE9QCisgIGZpCitlbHNlCisgIE9DQU1MTUtUT1A9
IiRhY19jdl9wcm9nX09DQU1MTUtUT1AiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxt
a2xpYgorICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4
fW9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MTUtMSUIrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0
ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NB
TUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09D
QU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKKworZmkKK2ZpCitPQ0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKK2lmIHRlc3Qg
LW4gIiRPQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LTElC
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LTElC
PSRPQ0FNTE1LTElCCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta2xpYiIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxt
a2xpYjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh
Y193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQis6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
TUtMSUI9IiRhY19jdF9PQ0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09D
QU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtM
SUIiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS0xJQiIg
PSB4OyB0aGVuCisgICAgT0NBTUxNS0xJQj0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19j
b21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNp
bmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNf
dG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxNS0xJQj0kYWNfY3RfT0NBTUxNS0xJ
QgorICBmaQorZWxzZQorICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIgorZmkK
KworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sZG9jIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJv
Z19PQ0FNTERPQz0iJE9DQU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9
JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lm
IHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9D
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxET0M9JE9D
QU1MRE9DCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZG9jOyBhY193
b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19j
dF9PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09D
QU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxET0M9Im9jYW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2Fj
X2N0X09DQU1MRE9DPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxET0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FN
TERPQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0
ZXN0ICJ4JGFjX2N0X09DQU1MRE9DIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERPQz0ibm8iCisgIGVs
c2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBj
cm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxE
T0M9JGFjX2N0X09DQU1MRE9DCisgIGZpCitlbHNlCisgIE9DQU1MRE9DPSIkYWNfY3ZfcHJvZ19P
Q0FNTERPQyIKK2ZpCisKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNf
d29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfT0NBTUxCVUlMRCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJV
SUxEIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190
b29sX3ByZWZpeH1vY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09D
QU1MQlVJTEQ9JGFjX2N2X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQi
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9w
cm9nX09DQU1MQlVJTEQiOyB0aGVuCisgIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEKzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQlVJTEQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09D
QU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8K
KyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK2FjX2N0X09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNo
byAiJGFjX2N0X09DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBP
Q0FNTEJVSUxEPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9v
bF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp
cGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMg
OzsKK2VzYWMKKyAgICBPQ0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisg
IE9DQU1MQlVJTEQ9IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiCitmaQorCisKKyAgICBpZiB0ZXN0
ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICAgICAgaWYgdGVzdCAieCRlbmFibGVf
b2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgICAgICAgICBhc19mbl9lcnJvciAk
PyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVO
TyIgNQorZmkKKyAgICAgICAgb2NhbWx0b29scz0ibiIKKworZmkKKworZmkKKyMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCitzZXQgZHVtbXkgYmFzaDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfQkFT
SCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGNhc2UgJEJBU0ggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkFTSD0i
JEJBU0giICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7
OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNf
ZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
KyAgICBhY19jdl9wYXRoX0JBU0g9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJ
RlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkFTSCIgJiYgYWNfY3Zf
cGF0aF9CQVNIPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCQVNIPSRhY19jdl9wYXRoX0JBU0gKK2lm
IHRlc3QgLW4gIiRCQVNIIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJEJBU0giID4mNQorJGFzX2VjaG8gIiRCQVNIIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JBU0h9IiA9
PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBw
bGVhc2UgaW5zdGFsbCBiYXNoIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkcHl0aG9udG9v
bHMiID0gInh5IjsgdGhlbiA6CisKKyAgICBpZiBlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4v
IjsgdGhlbiA6CisKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1g
YmFzZW5hbWUgJFBZVEhPTlBBVEhgCisKK2VsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgor
ICBQWVRIT049InB5dGhvbiIKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZp
ZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcGF0aF9QWVRIT05QQVRIKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/Oltc
XC9dKikKKyAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUFlU
SE9OUEFUSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZ
VEhPTlBBVEg9Im5vIgorICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlU
SE9OUEFUSAoraWYgdGVzdCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNf
ZWNobyAiJFBZVEhPTlBBVEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0K
K2ZpCisKKworaWYgdGVzdCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNf
Zm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRI
T04iICIkTElORU5PIiA1CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2Ak
UFlUSE9OIC1jICdpbXBvcnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwg
MykiKSknYAoraWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAk
UFlUSE9OIC1WIDI+JjFgCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgICAgYXNfZm5fZXJy
b3IgJD8gIiRweXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNp
b24gaXMgMi4zIiAiJExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9
CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHB5dGhvbiB4bWwuZG9tLm1pbmlkb20iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiB4bWwuZG9tLm1pbmlkb20uLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBv
cnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1s
LmRvbS5taW5pZG9tIG1vZHVsZSIgIiRMSU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5
ZXMiID4mNjsgfQorZmkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBweXRob24gZGV2ZWwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiBkZXZlbC4uLiAiID4mNjsgfQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3Mu
cGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsg
Ii9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisn
ID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiUHl0aG9uIGRldmVsIHBhY2th
Z2Ugbm90IGZvdW5kIiAiJExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2
OyB9CitmaQorCitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7
IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1hHRVRURVhUKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkWEdFVFRFWFQgaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICop
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFj
X2N2X3BhdGhfWEdFVFRFWFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9
JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2
X3BhdGhfWEdFVFRFWFQ9Im5vIgorICA7OworZXNhYworZmkKK1hHRVRURVhUPSRhY19jdl9wYXRo
X1hHRVRURVhUCitpZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQorJGFzX2Vj
aG8gIiRYR0VUVEVYVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworCitpZiB0ZXN0IHgiJHtYR0VUVEVYVH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJy
b3IgJD8gIlVuYWJsZSB0byBmaW5kIHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIg
IiRMSU5FTk8iIDUKK2ZpCitpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhl
bgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmFkbSIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgdWRldmFkbTsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3BhdGhfVURFVkFETSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFVERVZBRE0gaW4KKyAgW1xcL10qIHwg
PzpbXFwvXSopCisgIGFjX2N2X3BhdGhfVURFVkFETT0iJFVERVZBRE0iICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZB
RE09IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfVURFVkFETSIgJiYgYWNfY3ZfcGF0aF9VREVWQURNPSJu
byIKKyAgOzsKK2VzYWMKK2ZpCitVREVWQURNPSRhY19jdl9wYXRoX1VERVZBRE0KK2lmIHRlc3Qg
LW4gIiRVREVWQURNIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJFVERVZBRE0iID4mNQorJGFzX2VjaG8gIiRVREVWQURNIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtV
REVWQURNfSIgPT0geCJubyIKKyAgICB0aGVuCisgICAgICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAidWRldmluZm8iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15IHVkZXZpbmZvOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9VREVW
SU5GTys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhc2UgJFVERVZJTkZPIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRo
X1VERVZJTkZPPSIkVURFVklORk8iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdp
dGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRh
Y19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZJTkZPPSIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9w
YXRoX1VERVZJTkZPIiAmJiBhY19jdl9wYXRoX1VERVZJTkZPPSJubyIKKyAgOzsKK2VzYWMKK2Zp
CitVREVWSU5GTz0kYWNfY3ZfcGF0aF9VREVWSU5GTworaWYgdGVzdCAtbiAiJFVERVZJTkZPIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFVERVZJTkZPIiA+JjUKKyRhc19lY2hvICIkVURFVklORk8iID4mNjsgfQorZWxzZQorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30i
ID09IHgibm8iCisgICAgICAgIHRoZW4KKyAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2IiAiJExJ
TkVOTyIgNQorICAgICAgICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3
ayAne3ByaW50ICRORn0nYAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBp
bmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZl
cn0gLWx0IDU5CisgICAgdGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
ImhvdHBsdWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15IGhvdHBsdWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0hPVFBMVUcrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRI
T1RQTFVHIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0hPVFBMVUc9IiRI
T1RQTFVHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAg
OzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcGF0aF9IT1RQTFVHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0hPVFBMVUciICYm
IGFjX2N2X3BhdGhfSE9UUExVRz0ibm8iCisgIDs7Citlc2FjCitmaQorSE9UUExVRz0kYWNfY3Zf
cGF0aF9IT1RQTFVHCitpZiB0ZXN0IC1uICIkSE9UUExVRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRIT1RQTFVHIiA+JjUKKyRhc19l
Y2hvICIkSE9UUExVRyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworCisgICAgICAgIGlmIHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVu
CisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAidWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRv
IHZlcnNpb24gNTkgb3IgbGF0ZXIiICIkTElORU5PIiA1CisgICAgICAgIGZpCisgICAgZmkKK2Vs
c2UKKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInZuY29uZmlnIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB2bmNvbmZpZzsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3BhdGhfVk5DT05GSUcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRWTkNPTkZJRyBpbgorICBbXFwv
XSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJFZOQ09ORklHIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9WTkNPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9WTkNPTkZJRyIgJiYgYWNfY3ZfcGF0aF9W
TkNPTkZJRz0ibm8iCisgIDs7Citlc2FjCitmaQorVk5DT05GSUc9JGFjX2N2X3BhdGhfVk5DT05G
SUcKK2lmIHRlc3QgLW4gIiRWTkNPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRWTkNPTkZJRyIgPiY1CiskYXNfZWNobyAiJFZO
Q09ORklHIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAg
ICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBhc19m
bl9lcnJvciAkPyAiTm90IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmQiICIk
TElORU5PIiA1CisgICAgZmkKK2ZpCisKK2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1n
bnUiCit0aGVuCisgICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1
aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoK
KworZWxzZQorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJ
TkVOTyIgNQorZmkKKworCitlbHNlCisgICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi
JExJTkVOTyIgInV1aWQuaCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoKKwor
ZWxzZQorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJTkVO
TyIgNQorZmkKKworCitmaQorCisKKworCisKKworCitpZiB0ZXN0ICJ4JGFjX2N2X2Vudl9QS0df
Q09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcGF0aF9QS0dfQ09ORklHKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9d
KikKKyAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUEtHX0NP
TkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK
KworICA7OworZXNhYworZmkKK1BLR19DT05GSUc9JGFjX2N2X3BhdGhfUEtHX0NPTkZJRworaWYg
dGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJFBLR19D
T05GSUciID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworZmkK
K2lmIHRlc3QgLXogIiRhY19jdl9wYXRoX1BLR19DT05GSUciOyB0aGVuCisgIGFjX3B0X1BLR19D
T05GSUc9JFBLR19DT05GSUcKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwa2ctY29u
ZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBw
a2ctY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm
b3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklH
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkYWNfcHRfUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYWNfcHRfUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfYWNfcHRf
UEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworICA7OworZXNhYworZmkKK2FjX3B0X1BLR19DT05GSUc9JGFjX2N2X3BhdGhfYWNf
cHRfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAiJGFjX3B0X1BLR19DT05GSUciOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcHRfUEtH
X0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJGFjX3B0X1BLR19DT05GSUciID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19wdF9QS0dfQ09O
RklHIiA9IHg7IHRoZW4KKyAgICBQS0dfQ09ORklHPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9z
c19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQor
YWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgUEtHX0NPTkZJRz0kYWNfcHRfUEtHX0NP
TkZJRworICBmaQorZWxzZQorICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgor
ZmkKKworZmkKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorCV9wa2dfbWluX3ZlcnNp
b249MC45LjAKKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIHBrZy1jb25maWcgaXMgYXQgbGVhc3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbiIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9w
a2dfbWluX3ZlcnNpb24uLi4gIiA+JjY7IH0KKwlpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtn
Y29uZmlnLXZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb247IHRoZW4KKwkJeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVz
IiA+JjY7IH0KKwllbHNlCisJCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCQlQS0dfQ09ORklHPSIi
CisJZmkKK2ZpCisKK3BrZ19mYWlsZWQ9bm8KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdsaWIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGdsaWIuLi4gIiA+JjY7IH0KKworaWYgdGVzdCAtbiAiJGdsaWJfQ0ZMQUdTIjsgdGhlbgor
ICAgIHBrZ19jdl9nbGliX0NGTEFHUz0iJGdsaWJfQ0ZMQUdTIgorIGVsaWYgdGVzdCAtbiAiJFBL
R19DT05GSUciOyB0aGVuCisgICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwKKyAgICB7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09ORklHIC0t
ZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1CisgICgkUEtHX0NPTkZJ
RyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1CisgIGFjX3N0YXR1cz0k
PworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgorICBwa2dfY3ZfZ2xpYl9D
RkxBR1M9YCRQS0dfQ09ORklHIC0tY2ZsYWdzICJnbGliLTIuMCIgMj4vZGV2L251bGxgCitlbHNl
CisgIHBrZ19mYWlsZWQ9eWVzCitmaQorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2Zp
CitpZiB0ZXN0IC1uICIkZ2xpYl9MSUJTIjsgdGhlbgorICAgIHBrZ19jdl9nbGliX0xJQlM9IiRn
bGliX0xJQlMiCisgZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgICBpZiB0ZXN0
IC1uICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGli
LTIuMFwiIjsgfSA+JjUKKyAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzICJn
bGliLTIuMCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMg
PSAwOyB9OyB0aGVuCisgIHBrZ19jdl9nbGliX0xJQlM9YCRQS0dfQ09ORklHIC0tbGlicyAiZ2xp
Yi0yLjAiIDI+L2Rldi9udWxsYAorZWxzZQorICBwa2dfZmFpbGVkPXllcworZmkKKyBlbHNlCisg
ICAgcGtnX2ZhaWxlZD11bnRyaWVkCitmaQorCisKKworaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHll
czsgdGhlbgorICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCitpZiAkUEtHX0NPTkZJRyAtLWF0
bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0X2Vy
cm9yc19zdXBwb3J0ZWQ9eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBv
cnRlZD1ubworZmkKKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVk
ID0geWVzOyB0aGVuCisJICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hv
cnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKKyAgICAgICAgZWxzZQor
CSAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xp
Yi0yLjAiIDI+JjFgCisgICAgICAgIGZpCisJIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2Ug
aW4gY29uZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdzCisJZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIg
PiY1CisKKwlhc19mbl9lcnJvciAkPyAiUGFja2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3
ZXJlIG5vdCBtZXQ6CisKKyRnbGliX1BLR19FUlJPUlMKKworQ29uc2lkZXIgYWRqdXN0aW5nIHRo
ZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQg
c29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJlZml4LgorCitBbHRlcm5hdGl2ZWx5LCB5b3Ug
bWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xpYl9M
SUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtnLWNv
bmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKK2VsaWYgdGVzdCAk
cGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KKyAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQor
CXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUg
Zm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9yIHNl
dCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0aCB0
byBwa2ctY29uZmlnLgorCitBbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1l
bnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVk
IHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9y
ZSBkZXRhaWxzLgorCitUbyBnZXQgcGtnLWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5m
cmVlZGVza3RvcC5vcmcvPi4KK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIk
TElORU5PIiA1OyB9CitlbHNlCisJZ2xpYl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUworCWds
aWJfTElCUz0kcGtnX2N2X2dsaWJfTElCUworICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsg
fQorCitmaQorCisjIENoZWNrIGxpYnJhcnkgcGF0aAoraWYgdGVzdCAtZCAiJHByZWZpeC9saWI2
NCI7IHRoZW4gOgorCisgICAgTElCX1BBVEg9ImxpYjY0IgorCitlbHNlCisKKyAgICBMSUJfUEFU
SD0ibGliIgorCitmaQorCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFp
byIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8uLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfbGliX2Fpb19pb19zZXR1cCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9
JExJQlMKK0xJQlM9Ii1sYWlvICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
CisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBpb19zZXR1cCAo
KTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGlvX3NldHVwICgpOworICA7CisgIHJldHVybiAw
OworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFj
X2N2X2xpYl9haW9faW9fc2V0dXA9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9
bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAg
ICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGli
X3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xp
Yl9haW9faW9fc2V0dXAiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfYWlvX2lvX3NldHVw
IiA9IHh5ZXM7IHRoZW4gOgorICBzeXN0ZW1fYWlvPSJ5IgorZWxzZQorICBzeXN0ZW1fYWlvPSJu
IgorZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIE1E
NSBpbiAtbGNyeXB0by4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfY3J5cHRvX01ENSs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sY3J5cHRvICAkTElCUyIKK2NhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg
Ki8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g
ZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5
cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3
b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNl
bmRpZgorY2hhciBNRDUgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBNRDUgKCk7CisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9jcnlw
dG9fTUQ1PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfY3J5cHRvX01E
NSIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBI
QVZFX0xJQkNSWVBUTyAxCitfQUNFT0YKKworICBMSUJTPSItbGNyeXB0byAkTElCUyIKKworZWxz
ZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAiJExJTkVOTyIg
NQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGli
X2V4dDJmc19leHQyZnNfb3BlbjIrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSIt
bGV4dDJmcyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJu
YWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQg
bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVu
IGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9f
Y3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0MmZzX29wZW4yICgpOworaW50
CittYWluICgpCit7CityZXR1cm4gZXh0MmZzX29wZW4yICgpOworICA7CisgIHJldHVybiAwOwor
fQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2
X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcworZWxzZQorICBhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjY7IH0KK2lmIHRlc3Qg
IngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID0geHllczsgdGhlbiA6CisgIGxpYmV4
dDJmcz0ieSIKK2Vsc2UKKyAgbGliZXh0MmZzPSJuIgorZmkKKworCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBnY3J5X21kX2hhc2hfYnVmZmVy
IGluIC1sZ2NyeXB0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBnY3J5X21kX2hhc2hf
YnVmZmVyIGluIC1sZ2NyeXB0Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlcis6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sZ2Ny
eXB0ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1
c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwor
aW50CittYWluICgpCit7CityZXR1cm4gZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9eWVzCitlbHNlCisgIGFj
X2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubworZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2Ny
eXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID0geHllczsgdGhlbiA6CisgIGxpYmdjcnlwdD0ieSIKK2Vs
c2UKKyAgbGliZ2NyeXB0PSJuIgorZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFkX2NyZWF0ZSBpbiAtbHB0aHJlYWQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB0aHJlYWRfY3JlYXRlIGluIC1scHRocmVhZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNr
X2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1scHRocmVhZCAgJExJQlMiCitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy
cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl
IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k
aWYKK2NoYXIgcHRocmVhZF9jcmVhdGUgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBwdGhy
ZWFkX2NyZWF0ZSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2Ny
ZWF0ZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGU9bm8KK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVf
TElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlIiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisgIGFzX2Zu
X2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJwdGhyZWFkIiAiJExJTkVOTyIgNQorZmkKKwor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgY2xv
Y2tfZ2V0dGltZSBpbiAtbHJ0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbG9ja19n
ZXR0aW1lIGluIC1scnQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRp
bWUrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQor
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHJ0ICAkTElCUyIKK2NhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIK
KyNlbmRpZgorY2hhciBjbG9ja19nZXR0aW1lICgpOworaW50CittYWluICgpCit7CityZXR1cm4g
Y2xvY2tfZ2V0dGltZSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGlt
ZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9bm8KK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX3J0X2Nsb2NrX2dldHRpbWUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfcnRfY2xvY2tf
Z2V0dGltZSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA9
IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
TElCUlQgMQorX0FDRU9GCisKKyAgTElCUz0iLWxydCAkTElCUyIKKworZmkKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdXVpZF9jbGVhciBp
biAtbHV1aWQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIgaW4gLWx1
dWlkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHV1aWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisv
KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K
KyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh
IEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0
aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitj
aGFyIHV1aWRfY2xlYXIgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiB1dWlkX2NsZWFyICgp
OworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXI9eWVzCitlbHNlCisgIGFj
X2N2X2xpYl91dWlkX3V1aWRfY2xlYXI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVh
ciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCVVVJRCAxCitfQUNFT0YKKwor
ICBMSUJTPSItbHV1aWQgJExJQlMiCisKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5v
dCBmaW5kIGxpYnV1aWQiICIkTElORU5PIiA1CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB5YWpsX2FsbG9jIGluIC1seWFqbCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYys6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9
JExJQlMKK0xJQlM9Ii1seWFqbCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFu
eSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIg
YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWls
dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq
LworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgeWFqbF9hbGxv
YyAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHlhamxfYWxsb2MgKCk7CisgIDsKKyAgcmV0
dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYz15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3lhamxf
eWFqbF9hbGxvYz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2
X2xpYl95YWpsX3lhamxfYWxsb2MiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKK19BQ0VPRgorCisgIExJQlM9Ii1seWFq
bCAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgeWFqbCIg
IiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1seiIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl96
X2RlZmxhdGVDb3B5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx6ICAkTElC
UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg
dG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0
aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50
IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4
dGVybiAiQyIKKyNlbmRpZgorY2hhciBkZWZsYXRlQ29weSAoKTsKK2ludAorbWFpbiAoKQorewor
cmV0dXJuIGRlZmxhdGVDb3B5ICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl96X2RlZmxhdGVD
b3B5PXllcworZWxzZQorICBhY19jdl9saWJfel9kZWZsYXRlQ29weT1ubworZmkKK3JtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9s
aWJfel9kZWZsYXRlQ29weSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5
IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID0geHllczsgdGhl
biA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJaIDEKK19B
Q0VPRgorCisgIExJQlM9Ii1seiAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291
bGQgbm90IGZpbmQgemxpYiIgIiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29u
diIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252
Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxpY29udiAgJExJQlMiCitjYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisK
Ky8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9y
LgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m
IGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQg
c3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYK
K2NoYXIgbGliaWNvbnZfb3BlbiAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGxpYmljb252
X29wZW4gKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xp
bmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49eWVz
CitlbHNlCisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPW5vCitmaQorcm0gLWYgY29y
ZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhl
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xp
Yl9pY29udl9saWJpY29udl9vcGVuIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2ljb252X2xp
Ymljb252X29wZW4iID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZf
b3BlbiIgPSB4eWVzOyB0aGVuIDoKKyAgbGliaWNvbnY9InkiCitlbHNlCisgIGxpYmljb252PSJu
IgorZmkKKworCisKKyMgQXV0b3NjYW4gc3R1ZmYgKGV4Y2VwdCBmb3IgeWFqbC95YWpsX3ZlcnNp
b24uaCBjaGVjaykKKyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCithY19mbl9jX2NoZWNrX3R5
cGUgIiRMSU5FTk8iICJzaXplX3QiICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3NpemVfdCIgPSB4eWVzOyB0aGVuIDoKKwor
ZWxzZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHNpemVfdCB1bnNpZ25l
ZCBpbnQKK19BQ0VPRgorCitmaQorCisjIFRoZSBVbHRyaXggNC4yIG1pcHMgYnVpbHRpbiBhbGxv
Y2EgZGVjbGFyZWQgYnkgYWxsb2NhLmggb25seSB3b3JrcworIyBmb3IgY29uc3RhbnQgYXJndW1l
bnRzLiAgVXNlbGVzcyEKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmgiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHdvcmtpbmcgYWxsb2NhLmguLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zfd29ya2luZ19hbGxv
Y2FfaCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhbGxvY2EuaD4KK2ludAorbWFpbiAoKQoreworY2hh
ciAqcCA9IChjaGFyICopIGFsbG9jYSAoMiAqIHNpemVvZiAoaW50KSk7CisJCQkgIGlmIChwKSBy
ZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGlu
ayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl93b3JraW5nX2FsbG9jYV9oPXllcworZWxzZQor
ICBhY19jdl93b3JraW5nX2FsbG9jYV9oPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3dvcmtpbmdfYWxsb2NhX2giID4mNQorJGFzX2VjaG8gIiRhY19jdl93b3JraW5n
X2FsbG9jYV9oIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X3dvcmtpbmdfYWxsb2NhX2ggPSB5ZXM7
IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9BTExPQ0FfSCAxIiA+PmNvbmZkZWZzLmgK
KworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgYWxsb2NhIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBhbGxvY2EuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19H
TlVDX18KKyMgZGVmaW5lIGFsbG9jYSBfX2J1aWx0aW5fYWxsb2NhCisjZWxzZQorIyBpZmRlZiBf
TVNDX1ZFUgorIyAgaW5jbHVkZSA8bWFsbG9jLmg+CisjICBkZWZpbmUgYWxsb2NhIF9hbGxvY2EK
KyMgZWxzZQorIyAgaWZkZWYgSEFWRV9BTExPQ0FfSAorIyAgIGluY2x1ZGUgPGFsbG9jYS5oPgor
IyAgZWxzZQorIyAgIGlmZGVmIF9BSVgKKyAjcHJhZ21hIGFsbG9jYQorIyAgIGVsc2UKKyMgICAg
aWZuZGVmIGFsbG9jYSAvKiBwcmVkZWZpbmVkIGJ5IEhQIGNjICtPbGliY2FsbHMgKi8KK3ZvaWQg
KmFsbG9jYSAoc2l6ZV90KTsKKyMgICAgZW5kaWYKKyMgICBlbmRpZgorIyAgZW5kaWYKKyMgZW5k
aWYKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK2NoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2Eg
KDEpOworCQkJCSAgICBpZiAocCkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19h
bGxvY2Ffd29ya3M9eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPW5vCitmaQor
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjUK
KyRhc19lY2hvICIkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MiID4mNjsgfQorCitpZiB0ZXN0ICRh
Y19jdl9mdW5jX2FsbG9jYV93b3JrcyA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBI
QVZFX0FMTE9DQSAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQorICAjIFRoZSBTVlIzIGxpYlBXIGFu
ZCBTVlI0IGxpYnVjYiBib3RoIGNvbnRhaW4gaW5jb21wYXRpYmxlIGZ1bmN0aW9ucworIyB0aGF0
IGNhdXNlIHRyb3VibGUuICBTb21lIHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2Nh
IG9yCisjIGNvbnRhaW4gYSBidWdneSB2ZXJzaW9uLiAgSWYgeW91IHN0aWxsIHdhbnQgdG8gdXNl
IHRoZWlyIGFsbG9jYSwKKyMgdXNlIGFyIHRvIGV4dHJhY3QgYWxsb2NhLm8gZnJvbSB0aGVtIGlu
c3RlYWQgb2YgY29tcGlsaW5nIGFsbG9jYS5jLgorCitBTExPQ0E9XCR7TElCT0JKRElSfWFsbG9j
YS4kYWNfb2JqZXh0CisKKyRhc19lY2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMu
aAorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
d2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcy4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9vc19jcmF5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmIGRlZmluZWQgQ1JBWSAmJiAhIGRlZmlu
ZWQgQ1JBWTIKK3dlYmVjcmF5CisjZWxzZQord2Vub3RiZWNyYXkKKyNlbmRpZgorCitfQUNFT0YK
K2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVHUkVQICJ3
ZWJlY3JheSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgYWNfY3Zfb3NfY3JheT15ZXMKK2Vs
c2UKKyAgYWNfY3Zfb3NfY3JheT1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9vc19jcmF5
IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfb3NfY3JheSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9v
c19jcmF5ID0geWVzOyB0aGVuCisgIGZvciBhY19mdW5jIGluIF9nZXRiNjcgR0VUQjY3IGdldGI2
NzsgZG8KKyAgICBhc19hY192YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRh
c190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2Fj
X3ZhciIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoK
KworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBDUkFZX1NUQUNLU0VHX0VORCAk
YWNfZnVuYworX0FDRU9GCisKKyAgICBicmVhaworZmkKKworICBkb25lCitmaQorCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHN0YWNrIGRpcmVjdGlv
biBmb3IgQyBhbGxvY2EiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9u
IGZvciBDIGFsbG9jYS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX3N0YWNrX2RpcmVjdGlvbis6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlm
IHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfY19zdGFja19k
aXJlY3Rpb249MAorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50
CitmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKQoreworICBzdGF0aWMgY2hhciAqYWRkciA9IDA7Cisg
IGF1dG8gY2hhciBkdW1teTsKKyAgaWYgKGFkZHIgPT0gMCkKKyAgICB7CisgICAgICBhZGRyID0g
JmR1bW15OworICAgICAgcmV0dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpOworICAgIH0KKyAg
ZWxzZQorICAgIHJldHVybiAoJmR1bW15ID4gYWRkcikgPyAxIDogLTE7Cit9CisKK2ludAorbWFp
biAoKQoreworICByZXR1cm4gZmluZF9zdGFja19kaXJlY3Rpb24gKCkgPCAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19zdGFja19k
aXJlY3Rpb249MQorZWxzZQorICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0tMQorZmkKK3JtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
Y19zdGFja19kaXJlY3Rpb24iID4mNjsgfQorY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2Rl
ZmluZSBTVEFDS19ESVJFQ1RJT04gJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uCitfQUNFT0YKKwor
CitmaQorCitmb3IgYWNfaGVhZGVyIGluICBcCisgICAgICAgICAgICAgICAgYXJwYS9pbmV0Lmgg
ZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCisgICAgICAg
ICAgICAgICAgbmV0ZGIuaCBuZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50Lmggc3RkbGliLmgg
c3RyaW5nLmggXAorICAgICAgICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0
bC5oIHN5cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKKyAgICAgICAgICAgICAgICBzeXMvc29ja2V0
Lmggc3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCisgICAgICAg
ICAgICAgICAgdW5pc3RkLmggeWFqbC95YWpsX3ZlcnNpb24uaCBcCisKK2RvIDoKKyAgYXNfYWNf
SGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAor
YWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNf
YWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFz
X2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQor
X0FDRU9GCisKK2ZpCisKK2RvbmUKKworCisjIENoZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVy
ZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0
byBDOTkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZv
cm1zIHRvIEM5OS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9oZWFkZXJfc3RkYm9vbF9oKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCisjaW5jbHVkZSA8c3RkYm9vbC5oPgorI2lmbmRlZiBib29sCisgImVycm9yOiBib29s
IGlzIG5vdCBkZWZpbmVkIgorI2VuZGlmCisjaWZuZGVmIGZhbHNlCisgImVycm9yOiBmYWxzZSBp
cyBub3QgZGVmaW5lZCIKKyNlbmRpZgorI2lmIGZhbHNlCisgImVycm9yOiBmYWxzZSBpcyBub3Qg
MCIKKyNlbmRpZgorI2lmbmRlZiB0cnVlCisgImVycm9yOiB0cnVlIGlzIG5vdCBkZWZpbmVkIgor
I2VuZGlmCisjaWYgdHJ1ZSAhPSAxCisgImVycm9yOiB0cnVlIGlzIG5vdCAxIgorI2VuZGlmCisj
aWZuZGVmIF9fYm9vbF90cnVlX2ZhbHNlX2FyZV9kZWZpbmVkCisgImVycm9yOiBfX2Jvb2xfdHJ1
ZV9mYWxzZV9hcmVfZGVmaW5lZCBpcyBub3QgZGVmaW5lZCIKKyNlbmRpZgorCisJc3RydWN0IHMg
eyBfQm9vbCBzOiAxOyBfQm9vbCB0OyB9IHM7CisKKwljaGFyIGFbdHJ1ZSA9PSAxID8gMSA6IC0x
XTsKKwljaGFyIGJbZmFsc2UgPT0gMCA/IDEgOiAtMV07CisJY2hhciBjW19fYm9vbF90cnVlX2Zh
bHNlX2FyZV9kZWZpbmVkID09IDEgPyAxIDogLTFdOworCWNoYXIgZFsoYm9vbCkgMC41ID09IHRy
dWUgPyAxIDogLTFdOworCS8qIFNlZSBib2R5IG9mIG1haW4gcHJvZ3JhbSBmb3IgJ2UnLiAgKi8K
KwljaGFyIGZbKF9Cb29sKSAwLjAgPT0gZmFsc2UgPyAxIDogLTFdOworCWNoYXIgZ1t0cnVlXTsK
KwljaGFyIGhbc2l6ZW9mIChfQm9vbCldOworCWNoYXIgaVtzaXplb2Ygcy50XTsKKwllbnVtIHsg
aiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAyNTYgfTsK
KwkvKiBUaGUgZm9sbG93aW5nIGZhaWxzIGZvcgorCSAgIEhQIGFDKysvQU5TSSBDIEIzOTEwQiBB
LjA1LjU1IFtEZWMgMDQgMjAwM10uICovCisJX0Jvb2wgblttXTsKKwljaGFyIG9bc2l6ZW9mIG4g
PT0gbSAqIHNpemVvZiBuWzBdID8gMSA6IC0xXTsKKwljaGFyIHBbLTEgLSAoX0Jvb2wpIDAgPCAw
ICYmIC0xIC0gKGJvb2wpIDAgPCAwID8gMSA6IC0xXTsKKwkvKiBDYXRjaCBhIGJ1ZyBpbiBhbiBI
UC1VWCBDIGNvbXBpbGVyLiAgU2VlCisJICAgaHR0cDovL2djYy5nbnUub3JnL21sL2djYy1wYXRj
aGVzLzIwMDMtMTIvbXNnMDIzMDMuaHRtbAorCSAgIGh0dHA6Ly9saXN0cy5nbnUub3JnL2FyY2hp
dmUvaHRtbC9idWctY29yZXV0aWxzLzIwMDUtMTEvbXNnMDAxNjEuaHRtbAorCSAqLworCV9Cb29s
IHEgPSB0cnVlOworCV9Cb29sICpwcSA9ICZxOworCitpbnQKK21haW4gKCkKK3sKKworCWJvb2wg
ZSA9ICZzOworCSpwcSB8PSBxOworCSpwcSB8PSAhIHE7CisJLyogUmVmZXIgdG8gZXZlcnkgZGVj
bGFyZWQgdmFsdWUsIHRvIGF2b2lkIGNvbXBpbGVyIG9wdGltaXphdGlvbnMuICAqLworCXJldHVy
biAoIWEgKyAhYiArICFjICsgIWQgKyAhZSArICFmICsgIWcgKyAhaCArICFpICsgISFqICsgIWsg
KyAhIWwKKwkJKyAhbSArICFuICsgIW8gKyAhcCArICFxICsgIXBxKTsKKworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2hlYWRlcl9zdGRib29sX2g9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRi
b29sX2g9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRib29sX2giID4mNQorJGFzX2VjaG8gIiRh
Y19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjY7IH0KK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVO
TyIgIl9Cb29sIiAiYWNfY3ZfdHlwZV9fQm9vbCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYg
dGVzdCAieCRhY19jdl90eXBlX19Cb29sIiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfX0JPT0wgMQorX0FDRU9GCisKKworZmkKKworaWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2Rl
ZmluZSBIQVZFX1NUREJPT0xfSCAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5
cGVzLmgiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5o
Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X3R5cGVfdWlkX3QrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8
c3lzL3R5cGVzLmg+CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4
dCIpIDI+JjUgfAorICAkRUdSRVAgInVpZF90IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBh
Y19jdl90eXBlX3VpZF90PXllcworZWxzZQorICBhY19jdl90eXBlX3VpZF90PW5vCitmaQorcm0g
LWYgY29uZnRlc3QqCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3R5cGVfdWlkX3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl90eXBl
X3VpZF90IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgorCisk
YXNfZWNobyAiI2RlZmluZSB1aWRfdCBpbnQiID4+Y29uZmRlZnMuaAorCisKKyRhc19lY2hvICIj
ZGVmaW5lIGdpZF90IGludCIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgaW5saW5lLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfaW5saW5l
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
YWNfY3ZfY19pbmxpbmU9bm8KK2ZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxpbmVfXyBfX2lubGlu
ZTsgZG8KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cwordHlwZWRlZiBpbnQgZm9v
X3Q7CitzdGF0aWMgJGFjX2t3IGZvb190IHN0YXRpY19mb28gKCkge3JldHVybiAwOyB9CiskYWNf
a3cgZm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQorI2VuZGlmCisKK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9jX2lubGluZT0kYWNfa3cK
K2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0
LiRhY19leHQKKyAgdGVzdCAiJGFjX2N2X2NfaW5saW5lIiAhPSBubyAmJiBicmVhaworZG9uZQor
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9jX2lubGluZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2NfaW5saW5lIiA+JjY7IH0KKwor
Y2FzZSAkYWNfY3ZfY19pbmxpbmUgaW4KKyAgaW5saW5lIHwgeWVzKSA7OworICAqKQorICAgIGNh
c2UgJGFjX2N2X2NfaW5saW5lIGluCisgICAgICBubykgYWNfdmFsPTs7CisgICAgICAqKSBhY192
YWw9JGFjX2N2X2NfaW5saW5lOzsKKyAgICBlc2FjCisgICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2lmbmRlZiBfX2NwbHVzcGx1cworI2RlZmluZSBpbmxpbmUgJGFjX3ZhbAorI2VuZGlm
CitfQUNFT0YKKyAgICA7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAi
MTYiICJhY19jdl9jX2ludDE2X3QiCitjYXNlICRhY19jdl9jX2ludDE2X3QgaW4gIygKKyAgbm98
eWVzKSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGlu
dDE2X3QgJGFjX2N2X2NfaW50MTZfdAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRf
aW50WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX2ludDMyX3QiCitjYXNlICRhY19jdl9jX2lu
dDMyX3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIGludDMyX3QgJGFjX2N2X2NfaW50MzJfdAorX0FDRU9GCis7OworZXNh
YworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0X3Qi
CitjYXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDY0X3QgJGFjX2N2X2NfaW50NjRf
dAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIg
ImFjX2N2X2NfaW50OF90IgorY2FzZSAkYWNfY3ZfY19pbnQ4X3QgaW4gIygKKyAgbm98eWVzKSA7
OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDhfdCAk
YWNfY3ZfY19pbnQ4X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19jaGVja190eXBlICIk
TElORU5PIiAibW9kZV90IiAiYWNfY3ZfdHlwZV9tb2RlX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9tb2RlX3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UK
KworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBtb2RlX3QgaW50CitfQUNFT0YK
KworZmkKKworYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAib2ZmX3QiICJhY19jdl90eXBl
X29mZl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfb2Zm
X3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBvZmZfdCBsb25nIGludAorX0FDRU9GCisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfdHlw
ZSAiJExJTkVOTyIgInBpZF90IiAiYWNfY3ZfdHlwZV9waWRfdCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3BpZF90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNl
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgcGlkX3QgaW50CitfQUNFT0YK
KworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm
b3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX3Jlc3Ry
aWN0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgYWNfY3ZfY19yZXN0cmljdD1ubworICAgIyBUaGUgb3JkZXIgaGVyZSBjYXRlcnMgdG8gdGhl
IGZhY3QgdGhhdCBDKysgZG9lcyBub3QgcmVxdWlyZSByZXN0cmljdC4KKyAgIGZvciBhY19rdyBp
biBfX3Jlc3RyaWN0IF9fcmVzdHJpY3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7IGRvCisgICAgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KK3R5cGVkZWYgaW50ICogaW50X3B0cjsKKwlpbnQgZm9vIChpbnRfcHRyICRhY19r
dyBpcCkgeworCXJldHVybiBpcFswXTsKKyAgICAgICB9CitpbnQKK21haW4gKCkKK3sKK2ludCBz
WzFdOworCWludCAqICRhY19rdyB0ID0gczsKKwl0WzBdID0gMDsKKwlyZXR1cm4gZm9vKHQpCisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19yZXN0cmljdD0kYWNfa3cKK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgdGVz
dCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJyZWFrCisgICBkb25lCisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfcmVz
dHJpY3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX3Jlc3RyaWN0IiA+JjY7IH0KKworIGNhc2Ug
JGFjX2N2X2NfcmVzdHJpY3QgaW4KKyAgIHJlc3RyaWN0KSA7OworICAgbm8pICRhc19lY2hvICIj
ZGVmaW5lIHJlc3RyaWN0IC8qKi8iID4+Y29uZmRlZnMuaAorIDs7CisgICAqKSAgY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSByZXN0cmljdCAkYWNfY3ZfY19yZXN0cmljdAorX0FD
RU9GCisgOzsKKyBlc2FjCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInNpemVfdCIg
ImFjX2N2X3R5cGVfc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFj
X2N2X3R5cGVfc2l6ZV90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKKyNkZWZpbmUgc2l6ZV90IHVuc2lnbmVkIGludAorX0FDRU9GCisKK2ZpCisK
K2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInNzaXplX3QiICJhY19jdl90eXBlX3NzaXpl
X3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9zc2l6ZV90
IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgc3NpemVfdCBpbnQKK19BQ0VPRgorCitmaQorCithY19mbl9jX2NoZWNrX21lbWJlciAi
JExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxrc2l6ZSIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rf
c3RhdF9zdF9ibGtzaXplIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2
X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxLU0laRSAx
CitfQUNFT0YKKworCitmaQorCithY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVj
dCBzdGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsb2NrcyIg
IiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0
YXRfc3RfYmxvY2tzIiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTIDEKK19BQ0VPRgorCisKKyRhc19l
Y2hvICIjZGVmaW5lIEhBVkVfU1RfQkxPQ0tTIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgIGNh
c2UgIiAkTElCT0JKUyAiIGluCisgICoiIGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiApIDs7Cisg
ICopIExJQk9CSlM9IiRMSUJPQkpTIGZpbGVibG9ja3MuJGFjX29iamV4dCIKKyA7OworZXNhYwor
CitmaQorCisKK2FjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0YXQiICJz
dF9yZGV2IiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiICIkYWNfaW5jbHVkZXNf
ZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiID0g
eHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9T
VFJVQ1RfU1RBVF9TVF9SREVWIDEKK19BQ0VPRgorCisKK2ZpCisKK2FjX2ZuX2NfZmluZF91aW50
WF90ICIkTElORU5PIiAiMTYiICJhY19jdl9jX3VpbnQxNl90IgorY2FzZSAkYWNfY3ZfY191aW50
MTZfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSB1aW50MTZfdCAkYWNfY3ZfY191aW50MTZfdAorX0FDRU9GCis7Owor
ICBlc2FjCisKK2FjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX3Vp
bnQzMl90IgorY2FzZSAkYWNfY3ZfY191aW50MzJfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisg
ICopCisKKyRhc19lY2hvICIjZGVmaW5lIF9VSU5UMzJfVCAxIiA+PmNvbmZkZWZzLmgKKworCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHVpbnQzMl90ICRhY19jdl9jX3VpbnQz
Ml90CitfQUNFT0YKKzs7CisgIGVzYWMKKworYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8i
ICI2NCIgImFjX2N2X2NfdWludDY0X3QiCitjYXNlICRhY19jdl9jX3VpbnQ2NF90IGluICMoCisg
IG5vfHllcykgOzsgIygKKyAgKikKKworJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ2NF9UIDEiID4+
Y29uZmRlZnMuaAorCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgdWludDY0
X3QgJGFjX2N2X2NfdWludDY0X3QKK19BQ0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2ZpbmRf
dWludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX3VpbnQ4X3QiCitjYXNlICRhY19jdl9jX3Vp
bnQ4X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBf
VUlOVDhfVCAxIiA+PmNvbmZkZWZzLmgKKworCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIHVpbnQ4X3QgJGFjX2N2X2NfdWludDhfdAorX0FDRU9GCis7OworICBlc2FjCisKK2Fj
X2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVfcHRyZGlm
Zl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcHRyZGlm
Zl90IiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IEhBVkVfUFRSRElGRl9UIDEKK19BQ0VPRgorCisKK2ZpCisKKworIyBDaGVja3MgZm9yIGxpYnJh
cnkgZnVuY3Rpb25zLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
ZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfZXJyb3JfYXRfbGluZSs6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KKyNpbmNsdWRlIDxlcnJvci5oPgoraW50CittYWluICgpCit7CitlcnJvcl9hdF9s
aW5lICgwLCAwLCAiIiwgMCwgImFuIGVycm9yIG9jY3VycmVkIik7CisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNf
Y3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5l
PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9lcnJvcl9hdF9s
aW5lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUiID4mNjsgfQoraWYg
dGVzdCAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9C
SlMgIiBpbgorICAqIiBlcnJvci4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJ
Qk9CSlMgZXJyb3IuJGFjX29iamV4dCIKKyA7OworZXNhYworCitmaQorCitmb3IgYWNfaGVhZGVy
IGluIHZmb3JrLmgKK2RvIDoKKyAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVO
TyIgInZmb3JrLmgiICJhY19jdl9oZWFkZXJfdmZvcmtfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0
IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdmZvcmtfaCIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1ZGT1JLX0ggMQorX0FDRU9GCisK
K2ZpCisKK2RvbmUKKworZm9yIGFjX2Z1bmMgaW4gZm9yayB2Zm9yaworZG8gOgorICBhc19hY192
YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKK2FjX2ZuX2Nf
Y2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKK2lmIGV2YWwgdGVz
dCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1bmMiIHwgJGFzX3RyX2Nw
cGAgMQorX0FDRU9GCisKK2ZpCitkb25lCisKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrIiA9
IHh5ZXM7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3Igd29ya2luZyBmb3JrIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3
b3JraW5nIGZvcmsuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19mb3JrX3dvcmtzKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX2Zvcmtfd29y
a3M9Y3Jvc3MKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2ludAor
bWFpbiAoKQoreworCisJICAvKiBCeSBSdWVkaWdlciBLdWhsbWFubi4gKi8KKwkgIHJldHVybiBm
b3JrICgpIDwgMDsKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPXllcworZWxz
ZQorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3Jl
LmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9m
dW5jX2Zvcmtfd29ya3MiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID4m
NjsgfQorCitlbHNlCisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz0kYWNfY3ZfZnVuY19mb3JrCitm
aQoraWYgdGVzdCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geGNyb3NzOyB0aGVuCisgIGNh
c2UgJGhvc3QgaW4KKyAgICAqLSotYW1pZ2FvcyogfCAqLSotbXNkb3NkamdwcCopCisgICAgICAj
IE92ZXJyaWRlLCBhcyB0aGVzZSBzeXN0ZW1zIGhhdmUgb25seSBhIGR1bW15IGZvcmsoKSBzdHVi
CisgICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KKyAgICAgIDs7CisgICAgKikKKyAgICAg
IGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKKyAgICAgIDs7CisgIGVzYWMKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX2Zvcmtfd29ya3Mg
Z3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7fQorZmkKK2FjX2N2X2Z1
bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1bmNfdmZvcmsKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY192
Zm9yayIgPSB4eWVzOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgdmZvcmsiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIHdvcmtpbmcgdmZvcmsuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY192Zm9ya193
b3Jrcys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y192Zm9ya193b3Jrcz1jcm9zcworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisvKiBUaGFua3MgdG8gUGF1
bCBFZ2dlcnQgZm9yIHRoaXMgdGVzdC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAorI2luY2x1
ZGUgPHN5cy93YWl0Lmg+CisjaWZkZWYgSEFWRV9WRk9SS19ICisjIGluY2x1ZGUgPHZmb3JrLmg+
CisjZW5kaWYKKy8qIE9uIHNvbWUgc3BhcmMgc3lzdGVtcywgY2hhbmdlcyBieSB0aGUgY2hpbGQg
dG8gbG9jYWwgYW5kIGluY29taW5nCisgICBhcmd1bWVudCByZWdpc3RlcnMgYXJlIHByb3BhZ2F0
ZWQgYmFjayB0byB0aGUgcGFyZW50LiAgVGhlIGNvbXBpbGVyCisgICBpcyB0b2xkIGFib3V0IHRo
aXMgd2l0aCAjaW5jbHVkZSA8dmZvcmsuaD4sIGJ1dCBzb21lIGNvbXBpbGVycworICAgKGUuZy4g
Z2NjIC1PKSBkb24ndCBncm9rIDx2Zm9yay5oPi4gIFRlc3QgZm9yIHRoaXMgYnkgdXNpbmcgYQor
ICAgc3RhdGljIHZhcmlhYmxlIHdob3NlIGFkZHJlc3MgaXMgcHV0IGludG8gYSByZWdpc3RlciB0
aGF0IGlzCisgICBjbG9iYmVyZWQgYnkgdGhlIHZmb3JrLiAgKi8KK3N0YXRpYyB2b2lkCisjaWZk
ZWYgX19jcGx1c3BsdXMKK3NwYXJjX2FkZHJlc3NfdGVzdCAoaW50IGFyZykKKyMgZWxzZQorc3Bh
cmNfYWRkcmVzc190ZXN0IChhcmcpIGludCBhcmc7CisjZW5kaWYKK3sKKyAgc3RhdGljIHBpZF90
IGNoaWxkOworICBpZiAoIWNoaWxkKSB7CisgICAgY2hpbGQgPSB2Zm9yayAoKTsKKyAgICBpZiAo
Y2hpbGQgPCAwKSB7CisgICAgICBwZXJyb3IgKCJ2Zm9yayIpOworICAgICAgX2V4aXQoMik7Cisg
ICAgfQorICAgIGlmICghY2hpbGQpIHsKKyAgICAgIGFyZyA9IGdldHBpZCgpOworICAgICAgd3Jp
dGUoLTEsICIiLCAwKTsKKyAgICAgIF9leGl0IChhcmcpOworICAgIH0KKyAgfQorfQorCitpbnQK
K21haW4gKCkKK3sKKyAgcGlkX3QgcGFyZW50ID0gZ2V0cGlkICgpOworICBwaWRfdCBjaGlsZDsK
KworICBzcGFyY19hZGRyZXNzX3Rlc3QgKDApOworCisgIGNoaWxkID0gdmZvcmsgKCk7CisKKyAg
aWYgKGNoaWxkID09IDApIHsKKyAgICAvKiBIZXJlIGlzIGFub3RoZXIgdGVzdCBmb3Igc3BhcmMg
dmZvcmsgcmVnaXN0ZXIgcHJvYmxlbXMuICBUaGlzCisgICAgICAgdGVzdCB1c2VzIGxvdHMgb2Yg
bG9jYWwgdmFyaWFibGVzLCBhdCBsZWFzdCBhcyBtYW55IGxvY2FsCisgICAgICAgdmFyaWFibGVz
IGFzIG1haW4gaGFzIGFsbG9jYXRlZCBzbyBmYXIgaW5jbHVkaW5nIGNvbXBpbGVyCisgICAgICAg
dGVtcG9yYXJpZXMuICA0IGxvY2FscyBhcmUgZW5vdWdoIGZvciBnY2MgMS40MC4zIG9uIGEgU29s
YXJpcworICAgICAgIDQuMS4zIHNwYXJjLCBidXQgd2UgdXNlIDggdG8gYmUgc2FmZS4gIEEgYnVn
Z3kgY29tcGlsZXIgc2hvdWxkCisgICAgICAgcmV1c2UgdGhlIHJlZ2lzdGVyIG9mIHBhcmVudCBm
b3Igb25lIG9mIHRoZSBsb2NhbCB2YXJpYWJsZXMsCisgICAgICAgc2luY2UgaXQgd2lsbCB0aGlu
ayB0aGF0IHBhcmVudCBjYW4ndCBwb3NzaWJseSBiZSB1c2VkIGFueSBtb3JlCisgICAgICAgaW4g
dGhpcyByb3V0aW5lLiAgQXNzaWduaW5nIHRvIHRoZSBsb2NhbCB2YXJpYWJsZSB3aWxsIHRodXMK
KyAgICAgICBtdW5nZSBwYXJlbnQgaW4gdGhlIHBhcmVudCBwcm9jZXNzLiAgKi8KKyAgICBwaWRf
dAorICAgICAgcCA9IGdldHBpZCgpLCBwMSA9IGdldHBpZCgpLCBwMiA9IGdldHBpZCgpLCBwMyA9
IGdldHBpZCgpLAorICAgICAgcDQgPSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwgcDYgPSBnZXRw
aWQoKSwgcDcgPSBnZXRwaWQoKTsKKyAgICAvKiBDb252aW5jZSB0aGUgY29tcGlsZXIgdGhhdCBw
Li5wNyBhcmUgbGl2ZTsgb3RoZXJ3aXNlLCBpdCBtaWdodAorICAgICAgIHVzZSB0aGUgc2FtZSBo
YXJkd2FyZSByZWdpc3RlciBmb3IgYWxsIDggbG9jYWwgdmFyaWFibGVzLiAgKi8KKyAgICBpZiAo
cCAhPSBwMSB8fCBwICE9IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNAorCXx8IHAgIT0gcDUgfHwg
cCAhPSBwNiB8fCBwICE9IHA3KQorICAgICAgX2V4aXQoMSk7CisKKyAgICAvKiBPbiBzb21lIHN5
c3RlbXMgKGUuZy4gSVJJWCAzLjMpLCB2Zm9yayBkb2Vzbid0IHNlcGFyYXRlIHBhcmVudAorICAg
ICAgIGZyb20gY2hpbGQgZmlsZSBkZXNjcmlwdG9ycy4gIElmIHRoZSBjaGlsZCBjbG9zZXMgYSBk
ZXNjcmlwdG9yCisgICAgICAgYmVmb3JlIGl0IGV4ZWNzIG9yIGV4aXRzLCB0aGlzIG11bmdlcyB0
aGUgcGFyZW50J3MgZGVzY3JpcHRvcgorICAgICAgIGFzIHdlbGwuICBUZXN0IGZvciB0aGlzIGJ5
IGNsb3Npbmcgc3Rkb3V0IGluIHRoZSBjaGlsZC4gICovCisgICAgX2V4aXQoY2xvc2UoZmlsZW5v
KHN0ZG91dCkpICE9IDApOworICB9IGVsc2UgeworICAgIGludCBzdGF0dXM7CisgICAgc3RydWN0
IHN0YXQgc3Q7CisKKyAgICB3aGlsZSAod2FpdCgmc3RhdHVzKSAhPSBjaGlsZCkKKyAgICAgIDsK
KyAgICByZXR1cm4gKAorCSAvKiBXYXMgdGhlcmUgc29tZSBwcm9ibGVtIHdpdGggdmZvcmtpbmc/
ICAqLworCSBjaGlsZCA8IDAKKworCSAvKiBEaWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91
bGRuJ3QgaGFwcGVuLikgICovCisJIHx8IHN0YXR1cworCisJIC8qIERpZCB0aGUgdmZvcmsvY29t
cGlsZXIgYnVnIG9jY3VyPyAgKi8KKwkgfHwgcGFyZW50ICE9IGdldHBpZCgpCisKKwkgLyogRGlk
IHRoZSBmaWxlIGRlc2NyaXB0b3IgYnVnIG9jY3VyPyAgKi8KKwkgfHwgZnN0YXQoZmlsZW5vKHN0
ZG91dCksICZzdCkgIT0gMAorCSApOworICB9Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPXllcworZWxzZQor
ICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29yZS5j
b25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVu
Y192Zm9ya193b3JrcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID4m
NjsgfQorCitmaTsKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsg
dGhlbgorICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19j
dl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfdmZvcmtf
d29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7fQorZmkKKwor
aWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KKworJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX1ZGT1JLIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisK
KyRhc19lY2hvICIjZGVmaW5lIHZmb3JrIGZvcmsiID4+Y29uZmRlZnMuaAorCitmaQoraWYgdGVz
dCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geHllczsgdGhlbgorCiskYXNfZWNobyAiI2Rl
ZmluZSBIQVZFX1dPUktJTkdfRk9SSyAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgX0xBUkdFRklMRV9T
T1VSQ0UgdmFsdWUgbmVlZGVkIGZvciBsYXJnZSBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgX0xBUkdFRklMRV9TT1VSQ0UgdmFsdWUgbmVlZGVkIGZvciBsYXJnZSBmaWxlcy4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIHdoaWxlIDo7IGRvCisg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCisgICAg
ICNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgpCit7CitpbnQgKCpmcCkgKEZJTEUgKiwg
b2ZmX3QsIGludCkgPSBmc2Vla287CisgICAgIHJldHVybiBmc2Vla28gKHN0ZGluLCAwLCAwKSAm
JiBmcCAoc3RkaW4sIDAsIDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3N5c19sYXJnZWZpbGVfc291
cmNlPW5vOyBicmVhaworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKyNkZWZpbmUgX0xBUkdFRklMRV9TT1VSQ0UgMQorI2luY2x1ZGUgPHN5cy90eXBlcy5o
PiAvKiBmb3Igb2ZmX3QgKi8KKyAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkK
K3sKK2ludCAoKmZwKSAoRklMRSAqLCBvZmZfdCwgaW50KSA9IGZzZWVrbzsKKyAgICAgcmV0dXJu
IGZzZWVrbyAoc3RkaW4sIDAsIDApICYmIGZwIChzdGRpbiwgMCwgMCk7CisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9MTsgYnJlYWsKK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29u
ZnRlc3QuJGFjX2V4dAorICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT11bmtub3duCisgIGJy
ZWFrCitkb25lCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjY7IH0KK2Nhc2UgJGFjX2N2X3N5c19sYXJnZWZpbGVf
c291cmNlIGluICMoCisgIG5vIHwgdW5rbm93bikgOzsKKyAgKikKK2NhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgX0xBUkdFRklMRV9TT1VSQ0UgJGFjX2N2X3N5c19sYXJnZWZpbGVf
c291cmNlCitfQUNFT0YKKzs7Citlc2FjCitybSAtcmYgY29uZnRlc3QqCisKKyMgV2UgdXNlZCB0
byB0cnkgZGVmaW5pbmcgX1hPUEVOX1NPVVJDRT01MDAgdG9vLCB0byB3b3JrIGFyb3VuZCBhIGJ1
ZworIyBpbiBnbGliYyAyLjEuMywgYnV0IHRoYXQgYnJlYWtzIHRvbyBtYW55IG90aGVyIHRoaW5n
cy4KKyMgSWYgeW91IHdhbnQgZnNlZWtvIGFuZCBmdGVsbG8gd2l0aCBnbGliYywgdXBncmFkZSB0
byBhIGZpeGVkIGdsaWJjLgoraWYgdGVzdCAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UgIT0g
dW5rbm93bjsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX0ZTRUVLTyAxIiA+PmNvbmZk
ZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVzIHRyYWlsaW5nIHNsYXNoIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMg
dHJhaWxpbmcgc2xhc2guLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVy
ZW5jZXNfc2xhc2hlZF9zeW1saW5rKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgcm0gLWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0LmZpbGUKK2Vj
aG8gPmNvbmZ0ZXN0LmZpbGUKK2lmIHRlc3QgIiRhc19sbl9zIiA9ICJsbiAtcyIgJiYgbG4gLXMg
Y29uZnRlc3QuZmlsZSBjb25mdGVzdC5zeW07IHRoZW4KKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBp
bGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFz
aGVkX3N5bWxpbms9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQK
K2ludAorbWFpbiAoKQoreworc3RydWN0IHN0YXQgc2J1ZjsKKyAgICAgLyogTGludXggd2lsbCBk
ZXJlZmVyZW5jZSB0aGUgc3ltbGluayBhbmQgZmFpbCwgYXMgcmVxdWlyZWQgYnkgUE9TSVguCisJ
VGhhdCBpcyBiZXR0ZXIgaW4gdGhlIHNlbnNlIHRoYXQgaXQgbWVhbnMgd2Ugd2lsbCBub3QKKwlo
YXZlIHRvIGNvbXBpbGUgYW5kIHVzZSB0aGUgbHN0YXQgd3JhcHBlci4gICovCisgICAgIHJldHVy
biBsc3RhdCAoImNvbmZ0ZXN0LnN5bS8iLCAmc2J1ZikgPT0gMDsKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2
X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz15ZXMKK2Vsc2UKKyAgYWNf
Y3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCitmaQorcm0gLWYg
Y29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19l
eGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAorZmkKKworZWxzZQorICAjIElmIHRoZSBgbG4gLXMnIGNvbW1hbmQgZmFpbGVkLCB0aGVu
IHdlIHByb2JhYmx5IGRvbid0IGV2ZW4KKyAgIyBoYXZlIGFuIGxzdGF0IGZ1bmN0aW9uLgorICBh
Y19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KK2ZpCitybSAt
ZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNl
c19zbGFzaGVkX3N5bWxpbmsiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX2xzdGF0X2RlcmVm
ZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID4mNjsgfQorCit0ZXN0ICRhY19jdl9mdW5jX2xzdGF0
X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsgPSB5ZXMgJiYKKworY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgorI2RlZmluZSBMU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSyAxCitfQUNF
T0YKKworCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRf
c3ltbGluayIgPSB4bm87IHRoZW4KKyAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbHN0YXQu
JGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIGxzdGF0LiRhY19vYmpl
eHQiCisgOzsKK2VzYWMKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldiIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRl
di4uLiAiID4mNjsgfQoraWYgJHthY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldis6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KK2ludAorbWFpbiAoKQoreworcmV0dXJuIG1h
a2VkZXYoMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2Vk
ZXY9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2PW5vCitmaQor
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21h
a2VkZXYiID4mNQorJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIg
PiY2OyB9CisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2ID0gbm87
IHRoZW4KK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvbWtkZXYu
aCIgImFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYg
dGVzdCAieCRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2giID0geHllczsgdGhlbiA6CisKKyRhc19l
Y2hvICIjZGVmaW5lIE1BSk9SX0lOX01LREVWIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKwor
ICBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2ggPSBubzsgdGhlbgorICAgIGFjX2Zu
X2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvc3lzbWFjcm9zLmgiICJhY19j
dl9oZWFkZXJfc3lzX3N5c21hY3Jvc19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X2hlYWRlcl9zeXNfc3lzbWFjcm9zX2giID0geHllczsgdGhlbiA6CisKKyRhc19l
Y2hvICIjZGVmaW5lIE1BSk9SX0lOX1NZU01BQ1JPUyAxIiA+PmNvbmZkZWZzLmgKKworZmkKKwor
CisgIGZpCitmaQorCitmb3IgYWNfaGVhZGVyIGluIHN0ZGxpYi5oCitkbyA6CisgIGFjX2ZuX2Nf
Y2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9z
dGRsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJf
c3RkbGliX2giID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgSEFWRV9TVERMSUJfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21w
YXRpYmxlIG1hbGxvYyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29t
cGF0aWJsZSBtYWxsb2MuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u
dWxsKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5j
X21hbGxvY18wX25vbm51bGw9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmIGRlZmluZWQgU1RE
Q19IRUFERVJTIHx8IGRlZmluZWQgSEFWRV9TVERMSUJfSAorIyBpbmNsdWRlIDxzdGRsaWIuaD4K
KyNlbHNlCitjaGFyICptYWxsb2MgKCk7CisjZW5kaWYKKworaW50CittYWluICgpCit7CityZXR1
cm4gISBtYWxsb2MgKDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9j
X3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxs
PXllcworZWxzZQorICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9bm8KK2ZpCitybSAtZiBj
b3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNf
ZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19tYWxs
b2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxM
T0MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxM
T0MgMCIgPj5jb25mZGVmcy5oCisKKyAgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIG1hbGxv
Yy4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgbWFsbG9jLiRhY19v
YmpleHQiCisgOzsKK2VzYWMKKworCiskYXNfZWNobyAiI2RlZmluZSBtYWxsb2MgcnBsX21hbGxv
YyIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90
aCBiZSBpbmNsdWRlZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBh
bmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZC4uLiAiID4mNjsgfQoraWYgJHthY19j
dl9oZWFkZXJfdGltZSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRl
IDxzeXMvdGltZS5oPgorI2luY2x1ZGUgPHRpbWUuaD4KKworaW50CittYWluICgpCit7CitpZiAo
KHN0cnVjdCB0bSAqKSAwKQorcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfaGVhZGVy
X3RpbWU9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRlcl90aW1lPW5vCitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFk
ZXJfdGltZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl90aW1lIiA+JjY7IH0KK2lmIHRl
c3QgJGFjX2N2X2hlYWRlcl90aW1lID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIFRJ
TUVfV0lUSF9TWVNfVElNRSAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisKKworICBmb3IgYWNf
aGVhZGVyIGluICRhY19oZWFkZXJfbGlzdAorZG8gOgorICBhc19hY19IZWFkZXI9YCRhc19lY2hv
ICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2hl
YWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNf
aW5jbHVkZXNfZGVmYXVsdAorIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIg
PSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAk
YXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQor
Citkb25lCisKKworCisKKworCisKKworICBmb3IgYWNfZnVuYyBpbiAkYWNfZnVuY19saXN0Citk
byA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3Ry
X3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFy
IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfZnVu
YyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKK2RvbmUKKworCisKKworCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1r
dGltZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBta3RpbWUuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfZnVuY193b3JraW5nX21rdGltZSs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21w
aWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubworZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisvKiBUZXN0IHByb2dyYW0gZnJvbSBQYXVsIEVnZ2VydCBhbmQgVG9u
eSBMZW5laXMuICAqLworI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQorIyBpbmNsdWRlIDxzeXMv
dGltZS5oPgorIyBpbmNsdWRlIDx0aW1lLmg+CisjZWxzZQorIyBpZmRlZiBIQVZFX1NZU19USU1F
X0gKKyMgIGluY2x1ZGUgPHN5cy90aW1lLmg+CisjIGVsc2UKKyMgIGluY2x1ZGUgPHRpbWUuaD4K
KyMgZW5kaWYKKyNlbmRpZgorCisjaW5jbHVkZSA8bGltaXRzLmg+CisjaW5jbHVkZSA8c3RkbGli
Lmg+CisKKyNpZmRlZiBIQVZFX1VOSVNURF9ICisjIGluY2x1ZGUgPHVuaXN0ZC5oPgorI2VuZGlm
CisKKyNpZm5kZWYgSEFWRV9BTEFSTQorIyBkZWZpbmUgYWxhcm0oWCkgLyogZW1wdHkgKi8KKyNl
bmRpZgorCisvKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24gdG8gcnBsX3B1dGVudiBieSBvdGhl
ciBjb25maWcgdGVzdHMuICAqLworI3VuZGVmIHB1dGVudgorCitzdGF0aWMgdGltZV90IHRpbWVf
dF9tYXg7CitzdGF0aWMgdGltZV90IHRpbWVfdF9taW47CisKKy8qIFZhbHVlcyB3ZSdsbCB1c2Ug
dG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4gICovCitzdGF0aWMgY29uc3QgY2hh
ciAqdHpfc3RyaW5nc1tdID0geworICAoY29uc3QgY2hhciAqKSAwLCAiVFo9R01UMCIsICJUWj1K
U1QtOSIsCisgICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6MDA6MDAsTTIuMy4wLzAwOjAwOjAw
IgorfTsKKyNkZWZpbmUgTl9TVFJJTkdTIChzaXplb2YgKHR6X3N0cmluZ3MpIC8gc2l6ZW9mICh0
el9zdHJpbmdzWzBdKSkKKworLyogUmV0dXJuIDAgaWYgbWt0aW1lIGZhaWxzIHRvIGNvbnZlcnQg
YSBkYXRlIGluIHRoZSBzcHJpbmctZm9yd2FyZCBnYXAuCisgICBCYXNlZCBvbiBhIHByb2JsZW0g
cmVwb3J0IGZyb20gQW5kcmVhcyBKYWVnZXIuICAqLworc3RhdGljIGludAorc3ByaW5nX2Zvcndh
cmRfZ2FwICgpCit7CisgIC8qIGdsaWJjICh1cCB0byBhYm91dCAxOTk4LTEwLTA3KSBmYWlsZWQg
dGhpcyB0ZXN0LiAqLworICBzdHJ1Y3QgdG0gdG07CisKKyAgLyogVXNlIHRoZSBwb3J0YWJsZSBQ
T1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCisgICAgIGlu
c3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBkZXRlY3QgdGhlIGJ1
ZyBldmVuCisgICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBleHRl
bnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCisgICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGluc3Rh
bGxlZC4gICovCisgIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIp
OworCisgIHRtLnRtX3llYXIgPSA5ODsKKyAgdG0udG1fbW9uID0gMzsKKyAgdG0udG1fbWRheSA9
IDU7CisgIHRtLnRtX2hvdXIgPSAyOworICB0bS50bV9taW4gPSAwOworICB0bS50bV9zZWMgPSAw
OworICB0bS50bV9pc2RzdCA9IC0xOworICByZXR1cm4gbWt0aW1lICgmdG0pICE9ICh0aW1lX3Qp
IC0xOworfQorCitzdGF0aWMgaW50Citta3RpbWVfdGVzdDEgKHRpbWVfdCBub3cpCit7CisgIHN0
cnVjdCB0bSAqbHQ7CisgIHJldHVybiAhIChsdCA9IGxvY2FsdGltZSAoJm5vdykpIHx8IG1rdGlt
ZSAobHQpID09IG5vdzsKK30KKworc3RhdGljIGludAorbWt0aW1lX3Rlc3QgKHRpbWVfdCBub3cp
Cit7CisgIHJldHVybiAobWt0aW1lX3Rlc3QxIChub3cpCisJICAmJiBta3RpbWVfdGVzdDEgKCh0
aW1lX3QpICh0aW1lX3RfbWF4IC0gbm93KSkKKwkgICYmIG1rdGltZV90ZXN0MSAoKHRpbWVfdCkg
KHRpbWVfdF9taW4gKyBub3cpKSk7Cit9CisKK3N0YXRpYyBpbnQKK2lyaXhfNl80X2J1ZyAoKQor
eworICAvKiBCYXNlZCBvbiBjb2RlIGZyb20gQXJpZWwgRmFpZ29uLiAgKi8KKyAgc3RydWN0IHRt
IHRtOworICB0bS50bV95ZWFyID0gOTY7CisgIHRtLnRtX21vbiA9IDM7CisgIHRtLnRtX21kYXkg
PSAwOworICB0bS50bV9ob3VyID0gMDsKKyAgdG0udG1fbWluID0gMDsKKyAgdG0udG1fc2VjID0g
MDsKKyAgdG0udG1faXNkc3QgPSAtMTsKKyAgbWt0aW1lICgmdG0pOworICByZXR1cm4gdG0udG1f
bW9uID09IDIgJiYgdG0udG1fbWRheSA9PSAzMTsKK30KKworc3RhdGljIGludAorYmlndGltZV90
ZXN0IChpbnQgaikKK3sKKyAgc3RydWN0IHRtIHRtOworICB0aW1lX3Qgbm93OworICB0bS50bV95
ZWFyID0gdG0udG1fbW9uID0gdG0udG1fbWRheSA9IHRtLnRtX2hvdXIgPSB0bS50bV9taW4gPSB0
bS50bV9zZWMgPSBqOworICBub3cgPSBta3RpbWUgKCZ0bSk7CisgIGlmIChub3cgIT0gKHRpbWVf
dCkgLTEpCisgICAgeworICAgICAgc3RydWN0IHRtICpsdCA9IGxvY2FsdGltZSAoJm5vdyk7Cisg
ICAgICBpZiAoISAobHQKKwkgICAgICYmIGx0LT50bV95ZWFyID09IHRtLnRtX3llYXIKKwkgICAg
ICYmIGx0LT50bV9tb24gPT0gdG0udG1fbW9uCisJICAgICAmJiBsdC0+dG1fbWRheSA9PSB0bS50
bV9tZGF5CisJICAgICAmJiBsdC0+dG1faG91ciA9PSB0bS50bV9ob3VyCisJICAgICAmJiBsdC0+
dG1fbWluID09IHRtLnRtX21pbgorCSAgICAgJiYgbHQtPnRtX3NlYyA9PSB0bS50bV9zZWMKKwkg
ICAgICYmIGx0LT50bV95ZGF5ID09IHRtLnRtX3lkYXkKKwkgICAgICYmIGx0LT50bV93ZGF5ID09
IHRtLnRtX3dkYXkKKwkgICAgICYmICgobHQtPnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IGx0LT50
bV9pc2RzdCkKKwkJICA9PSAodG0udG1faXNkc3QgPCAwID8gLTEgOiAwIDwgdG0udG1faXNkc3Qp
KSkpCisJcmV0dXJuIDA7CisgICAgfQorICByZXR1cm4gMTsKK30KKworc3RhdGljIGludAoreWVh
cl8yMDUwX3Rlc3QgKCkKK3sKKyAgLyogVGhlIGNvcnJlY3QgYW5zd2VyIGZvciAyMDUwLTAyLTAx
IDAwOjAwOjAwIGluIFBhY2lmaWMgdGltZSwKKyAgICAgaWdub3JpbmcgbGVhcCBzZWNvbmRzLiAg
Ki8KKyAgdW5zaWduZWQgbG9uZyBpbnQgYW5zd2VyID0gMjUyNzMxNTIwMFVMOworCisgIHN0cnVj
dCB0bSB0bTsKKyAgdGltZV90IHQ7CisgIHRtLnRtX3llYXIgPSAyMDUwIC0gMTkwMDsKKyAgdG0u
dG1fbW9uID0gMiAtIDE7CisgIHRtLnRtX21kYXkgPSAxOworICB0bS50bV9ob3VyID0gdG0udG1f
bWluID0gdG0udG1fc2VjID0gMDsKKyAgdG0udG1faXNkc3QgPSAtMTsKKworICAvKiBVc2UgdGhl
IHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUu
MCIKKyAgICAgaW5zdGVhZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRl
dGVjdCB0aGUgYnVnIGV2ZW4KKyAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhl
IE9sc29uIGV4dGVuc2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUKKyAgICAgZnVsbCB6b25laW5mbyB0
YWJsZXMgaW5zdGFsbGVkLiAgKi8KKyAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEu
MCxNMTAuNS4wIik7CisKKyAgdCA9IG1rdGltZSAoJnRtKTsKKworICAvKiBDaGVjayB0aGF0IHRo
ZSByZXN1bHQgaXMgZWl0aGVyIGEgZmFpbHVyZSwgb3IgY2xvc2UgZW5vdWdoCisgICAgIHRvIHRo
ZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdlIGNhbiBhc3N1bWUgdGhlIGRpc2NyZXBhbmN5IGlzCisg
ICAgIGR1ZSB0byBsZWFwIHNlY29uZHMuICAqLworICByZXR1cm4gKHQgPT0gKHRpbWVfdCkgLTEK
KwkgIHx8ICgwIDwgdCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAmJiB0IDw9IGFuc3dlciArIDEyMCkp
OworfQorCitpbnQKK21haW4gKCkKK3sKKyAgdGltZV90IHQsIGRlbHRhOworICBpbnQgaSwgajsK
KworICAvKiBUaGlzIHRlc3QgbWFrZXMgc29tZSBidWdneSBta3RpbWUgaW1wbGVtZW50YXRpb25z
IGxvb3AuCisgICAgIEdpdmUgdXAgYWZ0ZXIgNjAgc2Vjb25kczsgYSBta3RpbWUgc2xvd2VyIHRo
YW4gdGhhdAorICAgICBpc24ndCB3b3J0aCB1c2luZyBhbnl3YXkuICAqLworICBhbGFybSAoNjAp
OworCisgIGZvciAoOzspCisgICAgeworICAgICAgdCA9ICh0aW1lX3RfbWF4IDw8IDEpICsgMTsK
KyAgICAgIGlmICh0IDw9IHRpbWVfdF9tYXgpCisJYnJlYWs7CisgICAgICB0aW1lX3RfbWF4ID0g
dDsKKyAgICB9CisgIHRpbWVfdF9taW4gPSAtICgodGltZV90KSB+ICh0aW1lX3QpIDAgPT0gKHRp
bWVfdCkgLTEpIC0gdGltZV90X21heDsKKworICBkZWx0YSA9IHRpbWVfdF9tYXggLyA5OTc7IC8q
IGEgc3VpdGFibGUgcHJpbWUgbnVtYmVyICovCisgIGZvciAoaSA9IDA7IGkgPCBOX1NUUklOR1M7
IGkrKykKKyAgICB7CisgICAgICBpZiAodHpfc3RyaW5nc1tpXSkKKwlwdXRlbnYgKChjaGFyKikg
dHpfc3RyaW5nc1tpXSk7CisKKyAgICAgIGZvciAodCA9IDA7IHQgPD0gdGltZV90X21heCAtIGRl
bHRhOyB0ICs9IGRlbHRhKQorCWlmICghIG1rdGltZV90ZXN0ICh0KSkKKwkgIHJldHVybiAxOwor
ICAgICAgaWYgKCEgKG1rdGltZV90ZXN0ICgodGltZV90KSAxKQorCSAgICAgJiYgbWt0aW1lX3Rl
c3QgKCh0aW1lX3QpICg2MCAqIDYwKSkKKwkgICAgICYmIG1rdGltZV90ZXN0ICgodGltZV90KSAo
NjAgKiA2MCAqIDI0KSkpKQorCXJldHVybiAxOworCisgICAgICBmb3IgKGogPSAxOyA7IGogPDw9
IDEpCisJaWYgKCEgYmlndGltZV90ZXN0IChqKSkKKwkgIHJldHVybiAxOworCWVsc2UgaWYgKElO
VF9NQVggLyAyIDwgaikKKwkgIGJyZWFrOworICAgICAgaWYgKCEgYmlndGltZV90ZXN0IChJTlRf
TUFYKSkKKwlyZXR1cm4gMTsKKyAgICB9CisgIHJldHVybiAhIChpcml4XzZfNF9idWcgKCkgJiYg
c3ByaW5nX2ZvcndhcmRfZ2FwICgpICYmIHllYXJfMjA1MF90ZXN0ICgpKTsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfd29ya2lu
Z19ta3RpbWU9eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWU9bm8KK2ZpCity
bSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVz
dC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjUKKyRhc19lY2hvICIk
YWNfY3ZfZnVuY193b3JraW5nX21rdGltZSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX3dv
cmtpbmdfbWt0aW1lID0gbm87IHRoZW4KKyAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbWt0
aW1lLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBta3RpbWUuJGFj
X29iamV4dCIKKyA7OworZXNhYworCitmaQorCisKKworCisKKworZm9yIGFjX2Z1bmMgaW4gZ2V0
cGFnZXNpemUKK2RvIDoKKyAgYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiZ2V0cGFnZXNp
emUiICJhY19jdl9mdW5jX2dldHBhZ2VzaXplIgoraWYgdGVzdCAieCRhY19jdl9mdW5jX2dldHBh
Z2VzaXplIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVm
aW5lIEhBVkVfR0VUUEFHRVNJWkUgMQorX0FDRU9GCisKK2ZpCitkb25lCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBtbWFwLi4uICIgPiY2OyB9Citp
ZiAke2FjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5n
IiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9bm8KK2Vsc2UK
KyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNv
bmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKy8qIG1hbGxvYyBtaWdodCBoYXZl
IGJlZW4gcmVuYW1lZCBhcyBycGxfbWFsbG9jLiAqLworI3VuZGVmIG1hbGxvYworCisvKiBUaGFu
a3MgdG8gTWlrZSBIYWVydGVsIGFuZCBKaW0gQXZlcmEgZm9yIHRoaXMgdGVzdC4KKyAgIEhlcmUg
aXMgYSBtYXRyaXggb2YgbW1hcCBwb3NzaWJpbGl0aWVzOgorCW1tYXAgcHJpdmF0ZSBub3QgZml4
ZWQKKwltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJlbnRseSB1bm1hcHBlZAor
CW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKKwltbWFwIHNo
YXJlZCBub3QgZml4ZWQKKwltbWFwIHNoYXJlZCBmaXhlZCBhdCBzb21ld2hlcmUgY3VycmVudGx5
IHVubWFwcGVkCisJbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVk
CisgICBGb3IgcHJpdmF0ZSBtYXBwaW5ncywgd2Ugc2hvdWxkIHZlcmlmeSB0aGF0IGNoYW5nZXMg
Y2Fubm90IGJlIHJlYWQoKQorICAgYmFjayBmcm9tIHRoZSBmaWxlLCBub3IgbW1hcCdzIGJhY2sg
ZnJvbSB0aGUgZmlsZSBhdCBhIGRpZmZlcmVudAorICAgYWRkcmVzcy4gIChUaGVyZSBoYXZlIGJl
ZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRlIHdhcyBub3QgY29ycmVjdGx5CisgICBpbXBsZW1lbnRl
ZCBsaWtlIHRoZSBpbmZhbW91cyBpMzg2IHN2cjQuMCwgYW5kIHN5c3RlbXMgd2hlcmUgdGhlCisg
ICBWTSBwYWdlIGNhY2hlIHdhcyBub3QgY29oZXJlbnQgd2l0aCB0aGUgZmlsZSBzeXN0ZW0gYnVm
ZmVyIGNhY2hlCisgICBsaWtlIGVhcmx5IHZlcnNpb25zIG9mIEZyZWVCU0QgYW5kIHBvc3NpYmx5
IGNvbnRlbXBvcmFyeSBOZXRCU0QuKQorICAgRm9yIHNoYXJlZCBtYXBwaW5ncywgd2Ugc2hvdWxk
IGNvbnZlcnNlbHkgdmVyaWZ5IHRoYXQgY2hhbmdlcyBnZXQKKyAgIHByb3BhZ2F0ZWQgYmFjayB0
byBhbGwgdGhlIHBsYWNlcyB0aGV5J3JlIHN1cHBvc2VkIHRvIGJlLgorCisgICBHcmVwIHdhbnRz
IHByaXZhdGUgZml4ZWQgYWxyZWFkeSBtYXBwZWQuCisgICBUaGUgbWFpbiB0aGluZ3MgZ3JlcCBu
ZWVkcyB0byBrbm93IGFib3V0IG1tYXAgYXJlOgorICAgKiBkb2VzIGl0IGV4aXN0IGFuZCBpcyBp
dCBzYWZlIHRvIHdyaXRlIGludG8gdGhlIG1tYXAnZCBhcmVhCisgICAqIGhvdyB0byB1c2UgaXQg
KEJTRCB2YXJpYW50cykgICovCisKKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPHN5cy9t
bWFuLmg+CisKKyNpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgIWRlZmluZWQgSEFWRV9TVERM
SUJfSAorY2hhciAqbWFsbG9jICgpOworI2VuZGlmCisKKy8qIFRoaXMgbWVzcyB3YXMgY29waWVk
IGZyb20gdGhlIEdOVSBnZXRwYWdlc2l6ZS5oLiAgKi8KKyNpZm5kZWYgSEFWRV9HRVRQQUdFU0la
RQorIyBpZmRlZiBfU0NfUEFHRVNJWkUKKyMgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIHN5c2NvbmYo
X1NDX1BBR0VTSVpFKQorIyBlbHNlIC8qIG5vIF9TQ19QQUdFU0laRSAqLworIyAgaWZkZWYgSEFW
RV9TWVNfUEFSQU1fSAorIyAgIGluY2x1ZGUgPHN5cy9wYXJhbS5oPgorIyAgIGlmZGVmIEVYRUNf
UEFHRVNJWkUKKyMgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgRVhFQ19QQUdFU0laRQorIyAgIGVs
c2UgLyogbm8gRVhFQ19QQUdFU0laRSAqLworIyAgICBpZmRlZiBOQlBHCisjICAgICBkZWZpbmUg
Z2V0cGFnZXNpemUoKSBOQlBHICogQ0xTSVpFCisjICAgICBpZm5kZWYgQ0xTSVpFCisjICAgICAg
ZGVmaW5lIENMU0laRSAxCisjICAgICBlbmRpZiAvKiBubyBDTFNJWkUgKi8KKyMgICAgZWxzZSAv
KiBubyBOQlBHICovCisjICAgICBpZmRlZiBOQlBDCisjICAgICAgZGVmaW5lIGdldHBhZ2VzaXpl
KCkgTkJQQworIyAgICAgZWxzZSAvKiBubyBOQlBDICovCisjICAgICAgaWZkZWYgUEFHRVNJWkUK
KyMgICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgUEFHRVNJWkUKKyMgICAgICBlbmRpZiAvKiBQ
QUdFU0laRSAqLworIyAgICAgZW5kaWYgLyogbm8gTkJQQyAqLworIyAgICBlbmRpZiAvKiBubyBO
QlBHICovCisjICAgZW5kaWYgLyogbm8gRVhFQ19QQUdFU0laRSAqLworIyAgZWxzZSAvKiBubyBI
QVZFX1NZU19QQVJBTV9IICovCisjICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgODE5MgkvKiBwdW50
IHRvdGFsbHkgKi8KKyMgIGVuZGlmIC8qIG5vIEhBVkVfU1lTX1BBUkFNX0ggKi8KKyMgZW5kaWYg
Lyogbm8gX1NDX1BBR0VTSVpFICovCisKKyNlbmRpZiAvKiBubyBIQVZFX0dFVFBBR0VTSVpFICov
CisKK2ludAorbWFpbiAoKQoreworICBjaGFyICpkYXRhLCAqZGF0YTIsICpkYXRhMzsKKyAgY29u
c3QgY2hhciAqY2RhdGEyOworICBpbnQgaSwgcGFnZXNpemU7CisgIGludCBmZCwgZmQyOworCisg
IHBhZ2VzaXplID0gZ2V0cGFnZXNpemUgKCk7CisKKyAgLyogRmlyc3QsIG1ha2UgYSBmaWxlIHdp
dGggc29tZSBrbm93biBnYXJiYWdlIGluIGl0LiAqLworICBkYXRhID0gKGNoYXIgKikgbWFsbG9j
IChwYWdlc2l6ZSk7CisgIGlmICghZGF0YSkKKyAgICByZXR1cm4gMTsKKyAgZm9yIChpID0gMDsg
aSA8IHBhZ2VzaXplOyArK2kpCisgICAgKihkYXRhICsgaSkgPSByYW5kICgpOworICB1bWFzayAo
MCk7CisgIGZkID0gY3JlYXQgKCJjb25mdGVzdC5tbWFwIiwgMDYwMCk7CisgIGlmIChmZCA8IDAp
CisgICAgcmV0dXJuIDI7CisgIGlmICh3cml0ZSAoZmQsIGRhdGEsIHBhZ2VzaXplKSAhPSBwYWdl
c2l6ZSkKKyAgICByZXR1cm4gMzsKKyAgY2xvc2UgKGZkKTsKKworICAvKiBOZXh0LCBjaGVjayB0
aGF0IHRoZSB0YWlsIG9mIGEgcGFnZSBpcyB6ZXJvLWZpbGxlZC4gIEZpbGUgbXVzdCBoYXZlCisg
ICAgIG5vbi16ZXJvIGxlbmd0aCwgb3RoZXJ3aXNlIHdlIHJpc2sgU0lHQlVTIGZvciBlbnRpcmUg
cGFnZS4gICovCisgIGZkMiA9IG9wZW4gKCJjb25mdGVzdC50eHQiLCBPX1JEV1IgfCBPX0NSRUFU
IHwgT19UUlVOQywgMDYwMCk7CisgIGlmIChmZDIgPCAwKQorICAgIHJldHVybiA0OworICBjZGF0
YTIgPSAiIjsKKyAgaWYgKHdyaXRlIChmZDIsIGNkYXRhMiwgMSkgIT0gMSkKKyAgICByZXR1cm4g
NTsKKyAgZGF0YTIgPSAoY2hhciAqKSBtbWFwICgwLCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJP
VF9XUklURSwgTUFQX1NIQVJFRCwgZmQyLCAwTCk7CisgIGlmIChkYXRhMiA9PSBNQVBfRkFJTEVE
KQorICAgIHJldHVybiA2OworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAgICBp
ZiAoKihkYXRhMiArIGkpKQorICAgICAgcmV0dXJuIDc7CisgIGNsb3NlIChmZDIpOworICBpZiAo
bXVubWFwIChkYXRhMiwgcGFnZXNpemUpKQorICAgIHJldHVybiA4OworCisgIC8qIE5leHQsIHRy
eSB0byBtbWFwIHRoZSBmaWxlIGF0IGEgZml4ZWQgYWRkcmVzcyB3aGljaCBhbHJlYWR5IGhhcwor
ICAgICBzb21ldGhpbmcgZWxzZSBhbGxvY2F0ZWQgYXQgaXQuICBJZiB3ZSBjYW4sIGFsc28gbWFr
ZSBzdXJlIHRoYXQKKyAgICAgd2Ugc2VlIHRoZSBzYW1lIGdhcmJhZ2UuICAqLworICBmZCA9IG9w
ZW4gKCJjb25mdGVzdC5tbWFwIiwgT19SRFdSKTsKKyAgaWYgKGZkIDwgMCkKKyAgICByZXR1cm4g
OTsKKyAgaWYgKGRhdGEyICE9IG1tYXAgKGRhdGEyLCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJP
VF9XUklURSwKKwkJICAgICBNQVBfUFJJVkFURSB8IE1BUF9GSVhFRCwgZmQsIDBMKSkKKyAgICBy
ZXR1cm4gMTA7CisgIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgIGlmICgqKGRh
dGEgKyBpKSAhPSAqKGRhdGEyICsgaSkpCisgICAgICByZXR1cm4gMTE7CisKKyAgLyogRmluYWxs
eSwgbWFrZSBzdXJlIHRoYXQgY2hhbmdlcyB0byB0aGUgbWFwcGVkIGFyZWEgZG8gbm90CisgICAg
IHBlcmNvbGF0ZSBiYWNrIHRvIHRoZSBmaWxlIGFzIHNlZW4gYnkgcmVhZCgpLiAgKFRoaXMgaXMg
YSBidWcgb24KKyAgICAgc29tZSB2YXJpYW50cyBvZiBpMzg2IHN2cjQuMC4pICAqLworICBmb3Ig
KGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAgICAqKGRhdGEyICsgaSkgPSAqKGRhdGEyICsg
aSkgKyAxOworICBkYXRhMyA9IChjaGFyICopIG1hbGxvYyAocGFnZXNpemUpOworICBpZiAoIWRh
dGEzKQorICAgIHJldHVybiAxMjsKKyAgaWYgKHJlYWQgKGZkLCBkYXRhMywgcGFnZXNpemUpICE9
IHBhZ2VzaXplKQorICAgIHJldHVybiAxMzsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyAr
K2kpCisgICAgaWYgKCooZGF0YSArIGkpICE9ICooZGF0YTMgKyBpKSkKKyAgICAgIHJldHVybiAx
NDsKKyAgY2xvc2UgKGZkKTsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5
X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPXll
cworZWxzZQorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCitmaQorcm0gLWYgY29y
ZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVl
eHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4
dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19tbWFw
X2ZpeGVkX21hcHBlZCA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX01NQVAg
MSIgPj5jb25mZGVmcy5oCisKK2ZpCitybSAtZiBjb25mdGVzdC5tbWFwIGNvbmZ0ZXN0LnR4dAor
Citmb3IgYWNfaGVhZGVyIGluIHN0ZGxpYi5oCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgIiRh
Y19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3RkbGliX2giID0g
eHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9T
VERMSUJfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIHJlYWxs
b2MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgcmVh
bGxvYy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3JlYWxsb2Nf
MF9ub25udWxsPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBkZWZpbmVkIFNURENfSEVBREVS
UyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKKyMgaW5jbHVkZSA8c3RkbGliLmg+CisjZWxzZQor
Y2hhciAqcmVhbGxvYyAoKTsKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAhIHJl
YWxsb2MgKDAsIDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15
ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD1ubworZmkKK3JtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l
eHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfcmVh
bGxvY18wX25vbm51bGwgPSB5ZXM7IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX1JF
QUxMT0MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9S
RUFMTE9DIDAiID4+Y29uZmRlZnMuaAorCisgICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBy
ZWFsbG9jLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyByZWFsbG9j
LiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworCiskYXNfZWNobyAiI2RlZmluZSByZWFsbG9jIHJw
bF9yZWFsbG9jIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBzdHJubGVuIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4uLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHll
czsgdGhlbiA6CisgICMgR3Vlc3Mgbm8gb24gQUlYIHN5c3RlbXMsIHllcyBvdGhlcndpc2UuCisJ
CWNhc2UgIiRob3N0X29zIiBpbgorCQkgIGFpeCopIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5n
PW5vOzsKKwkJICAqKSAgICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXM7OworCQllc2Fj
CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK21haW4gKCkK
K3sKKworI2RlZmluZSBTICJmb29iYXIiCisjZGVmaW5lIFNfTEVOIChzaXplb2YgUyAtIDEpCisK
KyAgLyogQXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uIGlzIGJ1Z2d5OiB0aGF0IG9mIEFJWCA0
LjMgd291bGQKKyAgICAgZ2l2ZSBzdHJubGVuIChTLCAxKSA9PSAzLiAgKi8KKworICBpbnQgaTsK
KyAgZm9yIChpID0gMDsgaSA8IFNfTEVOICsgMTsgKytpKQorICAgIHsKKyAgICAgIGludCBleHBl
Y3RlZCA9IGkgPD0gU19MRU4gPyBpIDogU19MRU47CisgICAgICBpZiAoc3RybmxlbiAoUywgaSkg
IT0gZXhwZWN0ZWQpCisJcmV0dXJuIDE7CisgICAgfQorICByZXR1cm4gMDsKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfc3Ry
bmxlbl93b3JraW5nPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdt
b24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJubGVuX3dv
cmtpbmciID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyIgPiY2OyB9
Cit0ZXN0ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyA9IG5vICYmIGNhc2UgIiAkTElCT0JK
UyAiIGluCisgICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRM
SUJPQkpTIHN0cm5sZW4uJGFjX29iamV4dCIKKyA7OworZXNhYworCisKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9kIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9mdW5jX3N0cnRvZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKKyAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCiskYWNf
aW5jbHVkZXNfZGVmYXVsdAorI2lmbmRlZiBzdHJ0b2QKK2RvdWJsZSBzdHJ0b2QgKCk7CisjZW5k
aWYKK2ludAorbWFpbigpCit7CisgIHsKKyAgICAvKiBTb21lIHZlcnNpb25zIG9mIExpbnV4IHN0
cnRvZCBtaXMtcGFyc2Ugc3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KKyAgICBjaGFyICpz
dHJpbmcgPSAiICs2OSI7CisgICAgY2hhciAqdGVybTsKKyAgICBkb3VibGUgdmFsdWU7CisgICAg
dmFsdWUgPSBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOworICAgIGlmICh2YWx1ZSAhPSA2OSB8fCB0
ZXJtICE9IChzdHJpbmcgKyA0KSkKKyAgICAgIHJldHVybiAxOworICB9CisKKyAgeworICAgIC8q
IFVuZGVyIFNvbGFyaXMgMi40LCBzdHJ0b2QgcmV0dXJucyB0aGUgd3JvbmcgdmFsdWUgZm9yIHRo
ZQorICAgICAgIHRlcm1pbmF0aW5nIGNoYXJhY3RlciB1bmRlciBzb21lIGNvbmRpdGlvbnMuICAq
LworICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOworICAgIGNoYXIgKnRlcm07CisgICAgc3RydG9k
IChzdHJpbmcsICZ0ZXJtKTsKKyAgICBpZiAodGVybSAhPSBzdHJpbmcgJiYgKih0ZXJtIC0gMSkg
PT0gMCkKKyAgICAgIHJldHVybiAxOworICB9CisgIHJldHVybiAwOworfQorCitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3N0cnRvZD15
ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBj
b3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9mdW5jX3N0cnRvZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3RydG9kIiA+JjY7IH0K
K2lmIHRlc3QgJGFjX2N2X2Z1bmNfc3RydG9kID0gbm87IHRoZW4KKyAgY2FzZSAiICRMSUJPQkpT
ICIgaW4KKyAgKiIgc3RydG9kLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElC
T0JKUyBzdHJ0b2QuJGFjX29iamV4dCIKKyA7OworZXNhYworCithY19mbl9jX2NoZWNrX2Z1bmMg
IiRMSU5FTk8iICJwb3ciICJhY19jdl9mdW5jX3BvdyIKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19w
b3ciID0geHllczsgdGhlbiA6CisKK2ZpCisKK2lmIHRlc3QgJGFjX2N2X2Z1bmNfcG93ID0gbm87
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgcG93IGluIC1sbSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgcG93IGluIC1s
bS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfbV9wb3crOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJT
PSRMSUJTCitMSUJTPSItbG0gICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkg
R0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJl
Y2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRp
biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8K
KyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIHBvdyAoKTsKK2lu
dAorbWFpbiAoKQoreworcmV0dXJuIHBvdyAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VP
RgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfbV9w
b3c9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9tX3Bvdz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25m
dGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbV9wb3ci
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfbV9wb3ciID4mNjsgfQoraWYgdGVzdCAieCRhY19j
dl9saWJfbV9wb3ciID0geHllczsgdGhlbiA6CisgIFBPV19MSUI9LWxtCitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogY2Fubm90IGZpbmQg
bGlicmFyeSBjb250YWluaW5nIGRlZmluaXRpb24gb2YgcG93IiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IFdBUk5JTkc6IGNhbm5vdCBmaW5kIGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9m
IHBvdyIgPiYyO30KK2ZpCisKK2ZpCisKK2ZpCisKK2ZvciBhY19mdW5jIGluICBcCisgICAgICAg
ICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBmZGF0YXN5bmMg
ZnRydW5jYXRlIFwKKyAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0
bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAorICAgICAgICAgICAgICAgIGluZXRfbnRv
YSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3ZlIG1lbXNldCBta2RpciBcCisgICAg
ICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0aCByZWdjb21wIHJtZGly
IHNlbGVjdCBzZXRlbnYgXAorICAgICAgICAgICAgICAgIHNvY2tldCBzdHJjYXNlY21wIHN0cmNo
ciBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKKyAgICAgICAgICAgICAgICBzdHJw
YnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNldCBc
CisgICAgICAgICAgICAgICAgdW5hbWUgXAorCitkbyA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8g
ImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19mdW5jICIk
TElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19h
Y192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YK
KworZmkKK2RvbmUKKworCitjYXQgPmNvbmZjYWNoZSA8PFxfQUNFT0YKKyMgVGhpcyBmaWxlIGlz
IGEgc2hlbGwgc2NyaXB0IHRoYXQgY2FjaGVzIHRoZSByZXN1bHRzIG9mIGNvbmZpZ3VyZQorIyB0
ZXN0cyBydW4gb24gdGhpcyBzeXN0ZW0gc28gdGhleSBjYW4gYmUgc2hhcmVkIGJldHdlZW4gY29u
ZmlndXJlCisjIHNjcmlwdHMgYW5kIGNvbmZpZ3VyZSBydW5zLCBzZWUgY29uZmlndXJlJ3Mgb3B0
aW9uIC0tY29uZmlnLWNhY2hlLgorIyBJdCBpcyBub3QgdXNlZnVsIG9uIG90aGVyIHN5c3RlbXMu
ICBJZiBpdCBjb250YWlucyByZXN1bHRzIHlvdSBkb24ndAorIyB3YW50IHRvIGtlZXAsIHlvdSBt
YXkgcmVtb3ZlIG9yIGVkaXQgaXQuCisjCisjIGNvbmZpZy5zdGF0dXMgb25seSBwYXlzIGF0dGVu
dGlvbiB0byB0aGUgY2FjaGUgZmlsZSBpZiB5b3UgZ2l2ZSBpdAorIyB0aGUgLS1yZWNoZWNrIG9w
dGlvbiB0byByZXJ1biBjb25maWd1cmUuCisjCisjIGBhY19jdl9lbnZfZm9vJyB2YXJpYWJsZXMg
KHNldCBvciB1bnNldCkgd2lsbCBiZSBvdmVycmlkZGVuIHdoZW4KKyMgbG9hZGluZyB0aGlzIGZp
bGUsIG90aGVyICp1bnNldCogYGFjX2N2X2Zvbycgd2lsbCBiZSBhc3NpZ25lZCB0aGUKKyMgZm9s
bG93aW5nIHZhbHVlcy4KKworX0FDRU9GCisKKyMgVGhlIGZvbGxvd2luZyB3YXkgb2Ygd3JpdGlu
ZyB0aGUgY2FjaGUgbWlzaGFuZGxlcyBuZXdsaW5lcyBpbiB2YWx1ZXMsCisjIGJ1dCB3ZSBrbm93
IG9mIG5vIHdvcmthcm91bmQgdGhhdCBpcyBzaW1wbGUsIHBvcnRhYmxlLCBhbmQgZWZmaWNpZW50
LgorIyBTbywgd2Uga2lsbCB2YXJpYWJsZXMgY29udGFpbmluZyBuZXdsaW5lcy4KKyMgVWx0cml4
IHNoIHNldCB3cml0ZXMgdG8gc3RkZXJyIGFuZCBjYW4ndCBiZSByZWRpcmVjdGVkIGRpcmVjdGx5
LAorIyBhbmQgc2V0cyB0aGUgaGlnaCBiaXQgaW4gdGhlIGNhY2hlIGZpbGUgdW5sZXNzIHdlIGFz
c2lnbiB0byB0aGUgdmFycy4KKygKKyAgZm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAt
biAncy9eXChbYS16QS1aX11bYS16QS1aMC05X10qXCk9LiovXDEvcCdgOyBkbworICAgIGV2YWwg
YWNfdmFsPVwkJGFjX3ZhcgorICAgIGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSop
CisgICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFy
IGNvbnRhaW5zIGEgbmV3bGluZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNo
ZSB2YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVz
YWMKKyAgICAgIGNhc2UgJGFjX3ZhciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAj
KAorICAgICAgQkFTSF9BUkdWIHwgQkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAg
ICAgICopIHsgZXZhbCAkYWNfdmFyPTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7
CisgICAgZXNhYworICBkb25lCisKKyAgKHNldCkgMj4mMSB8CisgICAgY2FzZSAkYXNfbmxgKGFj
X3NwYWNlPScgJzsgc2V0KSAyPiYxYCBpbiAjKAorICAgICoke2FzX25sfWFjX3NwYWNlPVwgKikK
KyAgICAgICMgYHNldCcgZG9lcyBub3QgcXVvdGUgY29ycmVjdGx5LCBzbyBhZGQgcXVvdGVzOiBk
b3VibGUtcXVvdGUKKyAgICAgICMgc3Vic3RpdHV0aW9uIHR1cm5zIFxcXFwgaW50byBcXCwgYW5k
IHNlZCB0dXJucyBcXCBpbnRvIFwuCisgICAgICBzZWQgLW4gXAorCSJzLycvJ1xcXFwnJy9nOwor
CSAgcy9eXFwoW18kYXNfY3JfYWxudW1dKl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwp
L1xcMT0nXFwyJy9wIgorICAgICAgOzsgIygKKyAgICAqKQorICAgICAgIyBgc2V0JyBxdW90ZXMg
Y29ycmVjdGx5IGFzIHJlcXVpcmVkIGJ5IFBPU0lYLCBzbyBkbyBub3QgYWRkIHF1b3Rlcy4KKyAg
ICAgIHNlZCAtbiAiL15bXyRhc19jcl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisg
ICAgICA7OworICAgIGVzYWMgfAorICAgIHNvcnQKKykgfAorICBzZWQgJworICAgICAvXmFjX2N2
X2Vudl8vYiBlbmQKKyAgICAgdCBjbGVhcgorICAgICA6Y2xlYXIKKyAgICAgcy9eXChbXj1dKlwp
PVwoLipbe31dLipcKSQvdGVzdCAiJHtcMStzZXR9IiA9IHNldCB8fCAmLworICAgICB0IGVuZAor
ICAgICBzL15cKFtePV0qXCk9XCguKlwpJC9cMT0ke1wxPVwyfS8KKyAgICAgOmVuZCcgPj5jb25m
Y2FjaGUKK2lmIGRpZmYgIiRjYWNoZV9maWxlIiBjb25mY2FjaGUgPi9kZXYvbnVsbCAyPiYxOyB0
aGVuIDo7IGVsc2UKKyAgaWYgdGVzdCAtdyAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICAgaWYgdGVz
dCAieCRjYWNoZV9maWxlIiAhPSAieC9kZXYvbnVsbCI7IHRoZW4KKyAgICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogdXBkYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUi
ID4mNQorJGFzX2VjaG8gIiRhc19tZTogdXBkYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9
CisgICAgICBpZiB0ZXN0ICEgLWYgIiRjYWNoZV9maWxlIiB8fCB0ZXN0IC1oICIkY2FjaGVfZmls
ZSI7IHRoZW4KKwljYXQgY29uZmNhY2hlID4iJGNhY2hlX2ZpbGUiCisgICAgICBlbHNlCisgICAg
ICAgIGNhc2UgJGNhY2hlX2ZpbGUgaW4gIygKKyAgICAgICAgKi8qIHwgPzoqKQorCSAgbXYgLWYg
Y29uZmNhY2hlICIkY2FjaGVfZmlsZSIkJCAmJgorCSAgbXYgLWYgIiRjYWNoZV9maWxlIiQkICIk
Y2FjaGVfZmlsZSIgOzsgIygKKyAgICAgICAgKikKKwkgIG12IC1mIGNvbmZjYWNoZSAiJGNhY2hl
X2ZpbGUiIDs7CisJZXNhYworICAgICAgZmkKKyAgICBmaQorICBlbHNlCisgICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBub3QgdXBkYXRpbmcgdW53cml0YWJsZSBj
YWNoZSAkY2FjaGVfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBub3QgdXBkYXRpbmcgdW53
cml0YWJsZSBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAgZmkKK2ZpCitybSAtZiBjb25mY2Fj
aGUKKwordGVzdCAieCRwcmVmaXgiID0geE5PTkUgJiYgcHJlZml4PSRhY19kZWZhdWx0X3ByZWZp
eAorIyBMZXQgbWFrZSBleHBhbmQgZXhlY19wcmVmaXguCit0ZXN0ICJ4JGV4ZWNfcHJlZml4IiA9
IHhOT05FICYmIGV4ZWNfcHJlZml4PScke3ByZWZpeH0nCisKK0RFRlM9LURIQVZFX0NPTkZJR19I
CisKK2FjX2xpYm9ianM9CithY19sdGxpYm9ianM9CitVPQorZm9yIGFjX2kgaW4gOiAkTElCT0JK
UzsgZG8gdGVzdCAieCRhY19pIiA9IHg6ICYmIGNvbnRpbnVlCisgICMgMS4gUmVtb3ZlIHRoZSBl
eHRlbnNpb24sIGFuZCAkVSBpZiBhbHJlYWR5IGluc3RhbGxlZC4KKyAgYWNfc2NyaXB0PSdzL1wk
VVwuLy4vO3MvXC5vJC8vO3MvXC5vYmokLy8nCisgIGFjX2k9YCRhc19lY2hvICIkYWNfaSIgfCBz
ZWQgIiRhY19zY3JpcHQiYAorICAjIDIuIFByZXBlbmQgTElCT0JKRElSLiAgV2hlbiB1c2VkIHdp
dGggYXV0b21ha2U+PTEuMTAgTElCT0JKRElSCisgICMgICAgd2lsbCBiZSBzZXQgdG8gdGhlIGRp
cmVjdG9yeSB3aGVyZSBMSUJPQkpTIG9iamVjdHMgYXJlIGJ1aWx0LgorICBhc19mbl9hcHBlbmQg
YWNfbGlib2JqcyAiIFwke0xJQk9CSkRJUn0kYWNfaVwkVS4kYWNfb2JqZXh0IgorICBhc19mbl9h
cHBlbmQgYWNfbHRsaWJvYmpzICIgXCR7TElCT0JKRElSfSRhY19pIickVS5sbycKK2RvbmUKK0xJ
Qk9CSlM9JGFjX2xpYm9ianMKKworTFRMSUJPQkpTPSRhY19sdGxpYm9ianMKKworCisKKzogIiR7
Q09ORklHX1NUQVRVUz0uL2NvbmZpZy5zdGF0dXN9IgorYWNfd3JpdGVfZmFpbD0wCithY19jbGVh
bl9maWxlc19zYXZlPSRhY19jbGVhbl9maWxlcworYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9m
aWxlcyAkQ09ORklHX1NUQVRVUyIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY3JlYXRpbmcgJENPTkZJR19TVEFUVVMiID4mNQorJGFzX2VjaG8gIiRhc19tZTogY3Jl
YXRpbmcgJENPTkZJR19TVEFUVVMiID4mNjt9Cithc193cml0ZV9mYWlsPTAKK2NhdCA+JENPTkZJ
R19TVEFUVVMgPDxfQVNFT0YgfHwgYXNfd3JpdGVfZmFpbD0xCisjISAkU0hFTEwKKyMgR2VuZXJh
dGVkIGJ5ICRhc19tZS4KKyMgUnVuIHRoaXMgZmlsZSB0byByZWNyZWF0ZSB0aGUgY3VycmVudCBj
b25maWd1cmF0aW9uLgorIyBDb21waWxlciBvdXRwdXQgcHJvZHVjZWQgYnkgY29uZmlndXJlLCB1
c2VmdWwgZm9yIGRlYnVnZ2luZworIyBjb25maWd1cmUsIGlzIGluIGNvbmZpZy5sb2cgaWYgaXQg
ZXhpc3RzLgorCitkZWJ1Zz1mYWxzZQorYWNfY3NfcmVjaGVjaz1mYWxzZQorYWNfY3Nfc2lsZW50
PWZhbHNlCisKK1NIRUxMPVwke0NPTkZJR19TSEVMTC0kU0hFTEx9CitleHBvcnQgU0hFTEwKK19B
U0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FTRU9GIHx8IGFzX3dyaXRlX2ZhaWw9MQor
IyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE00c2ggSW5pdGlhbGl6YXRpb24uICMjCisj
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworCisjIEJlIG1vcmUgQm91cm5lIGNvbXBhdGlibGUK
K0RVQUxDQVNFPTE7IGV4cG9ydCBEVUFMQ0FTRSAjIGZvciBNS1Mgc2gKK2lmIHRlc3QgLW4gIiR7
WlNIX1ZFUlNJT04rc2V0fSIgJiYgKGVtdWxhdGUgc2gpID4vZGV2L251bGwgMj4mMTsgdGhlbiA6
CisgIGVtdWxhdGUgc2gKKyAgTlVMTENNRD06CisgICMgUHJlLTQuMiB2ZXJzaW9ucyBvZiBac2gg
ZG8gd29yZCBzcGxpdHRpbmcgb24gJHsxKyIkQCJ9LCB3aGljaAorICAjIGlzIGNvbnRyYXJ5IHRv
IG91ciB1c2FnZS4gIERpc2FibGUgdGhpcyBmZWF0dXJlLgorICBhbGlhcyAtZyAnJHsxKyIkQCJ9
Jz0nIiRAIicKKyAgc2V0b3B0IE5PX0dMT0JfU1VCU1QKK2Vsc2UKKyAgY2FzZSBgKHNldCAtbykg
Mj4vZGV2L251bGxgIGluICMoCisgICpwb3NpeCopIDoKKyAgICBzZXQgLW8gcG9zaXggOzsgIygK
KyAgKikgOgorICAgICA7OworZXNhYworZmkKKworCithc19ubD0nCisnCitleHBvcnQgYXNfbmwK
KyMgUHJpbnRpbmcgYSBsb25nIHN0cmluZyBjcmFzaGVzIFNvbGFyaXMgNyAvdXNyL2Jpbi9wcmlu
dGYuCithc19lY2hvPSdcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcJworYXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCith
c19lY2hvPSRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobwor
IyBQcmVmZXIgYSBrc2ggc2hlbGwgYnVpbHRpbiBvdmVyIGFuIGV4dGVybmFsIHByaW50ZiBwcm9n
cmFtIG9uIFNvbGFyaXMsCisjIGJ1dCB3aXRob3V0IHdhc3RpbmcgZm9ya3MgZm9yIGJhc2ggb3Ig
enNoLgoraWYgdGVzdCAteiAiJEJBU0hfVkVSU0lPTiRaU0hfVkVSU0lPTiIgXAorICAgICYmICh0
ZXN0ICJYYHByaW50IC1yIC0tICRhc19lY2hvYCIgPSAiWCRhc19lY2hvIikgMj4vZGV2L251bGw7
IHRoZW4KKyAgYXNfZWNobz0ncHJpbnQgLXIgLS0nCisgIGFzX2VjaG9fbj0ncHJpbnQgLXJuIC0t
JworZWxpZiAodGVzdCAiWGBwcmludGYgJXMgJGFzX2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9k
ZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmludGYgJXNcbicKKyAgYXNfZWNob19uPSdwcmlu
dGYgJXMnCitlbHNlCisgIGlmIHRlc3QgIlhgKC91c3IvdWNiL2VjaG8gLW4gLW4gJGFzX2VjaG8p
IDI+L2Rldi9udWxsYCIgPSAiWC1uICRhc19lY2hvIjsgdGhlbgorICAgIGFzX2VjaG9fYm9keT0n
ZXZhbCAvdXNyL3VjYi9lY2hvIC1uICIkMSRhc19ubCInCisgICAgYXNfZWNob19uPScvdXNyL3Vj
Yi9lY2hvIC1uJworICBlbHNlCisgICAgYXNfZWNob19ib2R5PSdldmFsIGV4cHIgIlgkMSIgOiAi
WFxcKC4qXFwpIicKKyAgICBhc19lY2hvX25fYm9keT0nZXZhbAorICAgICAgYXJnPSQxOworICAg
ICAgY2FzZSAkYXJnIGluICMoCisgICAgICAqIiRhc19ubCIqKQorCWV4cHIgIlgkYXJnIiA6ICJY
XFwoLipcXCkkYXNfbmwiOworCWFyZz1gZXhwciAiWCRhcmciIDogIi4qJGFzX25sXFwoLipcXCki
YDs7CisgICAgICBlc2FjOworICAgICAgZXhwciAiWCRhcmciIDogIlhcXCguKlxcKSIgfCB0ciAt
ZCAiJGFzX25sIgorICAgICcKKyAgICBleHBvcnQgYXNfZWNob19uX2JvZHkKKyAgICBhc19lY2hv
X249J3NoIC1jICRhc19lY2hvX25fYm9keSBhc19lY2hvJworICBmaQorICBleHBvcnQgYXNfZWNo
b19ib2R5CisgIGFzX2VjaG89J3NoIC1jICRhc19lY2hvX2JvZHkgYXNfZWNobycKK2ZpCisKKyMg
VGhlIHVzZXIgaXMgYWx3YXlzIHJpZ2h0LgoraWYgdGVzdCAiJHtQQVRIX1NFUEFSQVRPUitzZXR9
IiAhPSBzZXQ7IHRoZW4KKyAgUEFUSF9TRVBBUkFUT1I9OgorICAoUEFUSD0nL2JpbjsvYmluJzsg
RlBBVEg9JFBBVEg7IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSAmJiB7CisgICAgKFBBVEg9Jy9i
aW46L2Jpbic7IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rldi9udWxsIDI+JjEgfHwKKyAgICAg
IFBBVEhfU0VQQVJBVE9SPSc7JworICB9CitmaQorCisKKyMgSUZTCisjIFdlIG5lZWQgc3BhY2Us
IHRhYiBhbmQgbmV3IGxpbmUsIGluIHByZWNpc2VseSB0aGF0IG9yZGVyLiAgUXVvdGluZyBpcwor
IyB0aGVyZSB0byBwcmV2ZW50IGVkaXRvcnMgZnJvbSBjb21wbGFpbmluZyBhYm91dCBzcGFjZS10
YWIuCisjIChJZiBfQVNfUEFUSF9XQUxLIHdlcmUgY2FsbGVkIHdpdGggSUZTIHVuc2V0LCBpdCB3
b3VsZCBkaXNhYmxlIHdvcmQKKyMgc3BsaXR0aW5nIGJ5IHNldHRpbmcgSUZTIHRvIGVtcHR5IHZh
bHVlLikKK0lGUz0iICIiCSRhc19ubCIKKworIyBGaW5kIHdobyB3ZSBhcmUuICBMb29rIGluIHRo
ZSBwYXRoIGlmIHdlIGNvbnRhaW4gbm8gZGlyZWN0b3J5IHNlcGFyYXRvci4KK2FzX215c2VsZj0K
K2Nhc2UgJDAgaW4gIygoCisgICpbXFwvXSogKSBhc19teXNlbGY9JDAgOzsKKyAgKikgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8K
KyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAg
IHRlc3QgLXIgIiRhc19kaXIvJDAiICYmIGFzX215c2VsZj0kYXNfZGlyLyQwICYmIGJyZWFrCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICAgICA7OworZXNhYworIyBXZSBkaWQgbm90IGZp
bmQgb3Vyc2VsdmVzLCBtb3N0IHByb2JhYmx5IHdlIHdlcmUgcnVuIGFzIGBzaCBDT01NQU5EJwor
IyBpbiB3aGljaCBjYXNlIHdlIGFyZSBub3QgdG8gYmUgZm91bmQgaW4gdGhlIHBhdGguCitpZiB0
ZXN0ICJ4JGFzX215c2VsZiIgPSB4OyB0aGVuCisgIGFzX215c2VsZj0kMAorZmkKK2lmIHRlc3Qg
ISAtZiAiJGFzX215c2VsZiI7IHRoZW4KKyAgJGFzX2VjaG8gIiRhc19teXNlbGY6IGVycm9yOiBj
YW5ub3QgZmluZCBteXNlbGY7IHJlcnVuIHdpdGggYW4gYWJzb2x1dGUgZmlsZSBuYW1lIiA+JjIK
KyAgZXhpdCAxCitmaQorCisjIFVuc2V0IHZhcmlhYmxlcyB0aGF0IHdlIGRvIG5vdCBuZWVkIGFu
ZCB3aGljaCBjYXVzZSBidWdzIChlLmcuIGluCisjIHByZS0zLjAgVVdJTiBrc2gpLiAgQnV0IGRv
IG5vdCBjYXVzZSBidWdzIGluIGJhc2ggMi4wMTsgdGhlICJ8fCBleGl0IDEiCisjIHN1cHByZXNz
ZXMgYW55ICJTZWdtZW50YXRpb24gZmF1bHQiIG1lc3NhZ2UgdGhlcmUuICAnKCgnIGNvdWxkCisj
IHRyaWdnZXIgYSBidWcgaW4gcGRrc2ggNS4yLjE0LgorZm9yIGFzX3ZhciBpbiBCQVNIX0VOViBF
TlYgTUFJTCBNQUlMUEFUSAorZG8gZXZhbCB0ZXN0IHhcJHskYXNfdmFyK3NldH0gPSB4c2V0IFwK
KyAgJiYgKCAodW5zZXQgJGFzX3ZhcikgfHwgZXhpdCAxKSA+L2Rldi9udWxsIDI+JjEgJiYgdW5z
ZXQgJGFzX3ZhciB8fCA6Citkb25lCitQUzE9JyQgJworUFMyPSc+ICcKK1BTND0nKyAnCisKKyMg
TkxTIG51aXNhbmNlcy4KK0xDX0FMTD1DCitleHBvcnQgTENfQUxMCitMQU5HVUFHRT1DCitleHBv
cnQgTEFOR1VBR0UKKworIyBDRFBBVEguCisodW5zZXQgQ0RQQVRIKSA+L2Rldi9udWxsIDI+JjEg
JiYgdW5zZXQgQ0RQQVRICisKKworIyBhc19mbl9lcnJvciBTVEFUVVMgRVJST1IgW0xJTkVOTyBM
T0dfRkRdCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgT3V0
cHV0ICJgYmFzZW5hbWUgJDBgOiBlcnJvcjogRVJST1IiIHRvIHN0ZGVyci4gSWYgTElORU5PIGFu
ZCBMT0dfRkQgYXJlCisjIHByb3ZpZGVkLCBhbHNvIG91dHB1dCB0aGUgZXJyb3IgdG8gTE9HX0ZE
LCByZWZlcmVuY2luZyBMSU5FTk8uIFRoZW4gZXhpdCB0aGUKKyMgc2NyaXB0IHdpdGggU1RBVFVT
LCB1c2luZyAxIGlmIHRoYXQgd2FzIDAuCithc19mbl9lcnJvciAoKQoreworICBhc19zdGF0dXM9
JDE7IHRlc3QgJGFzX3N0YXR1cyAtZXEgMCAmJiBhc19zdGF0dXM9MQorICBpZiB0ZXN0ICIkNCI7
IHRoZW4KKyAgICBhc19saW5lbm89JHthc19saW5lbm8tIiQzIn0gYXNfbGluZW5vX3N0YWNrPWFz
X2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZXJyb3I6ICQyIiA+JiQ0CisgIGZpCisgICRhc19lY2hvICIkYXNf
bWU6IGVycm9yOiAkMiIgPiYyCisgIGFzX2ZuX2V4aXQgJGFzX3N0YXR1cworfSAjIGFzX2ZuX2Vy
cm9yCisKKworIyBhc19mbl9zZXRfc3RhdHVzIFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQorIyBTZXQgJD8gdG8gU1RBVFVTLCB3aXRob3V0IGZvcmtpbmcuCithc19mbl9zZXRfc3Rh
dHVzICgpCit7CisgIHJldHVybiAkMQorfSAjIGFzX2ZuX3NldF9zdGF0dXMKKworIyBhc19mbl9l
eGl0IFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLQorIyBFeGl0IHRoZSBzaGVsbCB3aXRoIFNU
QVRVUywgZXZlbiBpbiBhICJ0cmFwIDAiIG9yICJzZXQgLWUiIGNvbnRleHQuCithc19mbl9leGl0
ICgpCit7CisgIHNldCArZQorICBhc19mbl9zZXRfc3RhdHVzICQxCisgIGV4aXQgJDEKK30gIyBh
c19mbl9leGl0CisKKyMgYXNfZm5fdW5zZXQgVkFSCisjIC0tLS0tLS0tLS0tLS0tLQorIyBQb3J0
YWJseSB1bnNldCBWQVIuCithc19mbl91bnNldCAoKQoreworICB7IGV2YWwgJDE9OyB1bnNldCAk
MTt9Cit9Cithc191bnNldD1hc19mbl91bnNldAorIyBhc19mbl9hcHBlbmQgVkFSIFZBTFVFCisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgQXBwZW5kIHRoZSB0ZXh0IGluIFZBTFVFIHRvIHRo
ZSBlbmQgb2YgdGhlIGRlZmluaXRpb24gY29udGFpbmVkIGluIFZBUi4gVGFrZQorIyBhZHZhbnRh
Z2Ugb2YgYW55IHNoZWxsIG9wdGltaXphdGlvbnMgdGhhdCBhbGxvdyBhbW9ydGl6ZWQgbGluZWFy
IGdyb3d0aCBvdmVyCisjIHJlcGVhdGVkIGFwcGVuZHMsIGluc3RlYWQgb2YgdGhlIHR5cGljYWwg
cXVhZHJhdGljIGdyb3d0aCBwcmVzZW50IGluIG5haXZlCisjIGltcGxlbWVudGF0aW9ucy4KK2lm
IChldmFsICJhc192YXI9MTsgYXNfdmFyKz0yOyB0ZXN0IHhcJGFzX3ZhciA9IHgxMiIpIDI+L2Rl
di9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXBwZW5kICgpCisgIHsKKyAgICBldmFsICQx
Kz1cJDIKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXBwZW5kICgpCisgIHsKKyAgICBldmFsICQxPVwk
JDFcJDIKKyAgfQorZmkgIyBhc19mbl9hcHBlbmQKKworIyBhc19mbl9hcml0aCBBUkcuLi4KKyMg
LS0tLS0tLS0tLS0tLS0tLS0tCisjIFBlcmZvcm0gYXJpdGhtZXRpYyBldmFsdWF0aW9uIG9uIHRo
ZSBBUkdzLCBhbmQgc3RvcmUgdGhlIHJlc3VsdCBpbiB0aGUKKyMgZ2xvYmFsICRhc192YWwuIFRh
a2UgYWR2YW50YWdlIG9mIHNoZWxscyB0aGF0IGNhbiBhdm9pZCBmb3Jrcy4gVGhlIGFyZ3VtZW50
cworIyBtdXN0IGJlIHBvcnRhYmxlIGFjcm9zcyAkKCgpKSBhbmQgZXhwci4KK2lmIChldmFsICJ0
ZXN0IFwkKCggMSArIDEgKSkgPSAyIikgMj4vZGV2L251bGw7IHRoZW4gOgorICBldmFsICdhc19m
bl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPSQoKCAkKiApKQorICB9JworZWxzZQorICBhc19m
bl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPWBleHByICIkQCIgfHwgdGVzdCAkPyAtZXEgMWAK
KyAgfQorZmkgIyBhc19mbl9hcml0aAorCisKK2lmIGV4cHIgYSA6ICdcKGFcKScgPi9kZXYvbnVs
bCAyPiYxICYmCisgICB0ZXN0ICJYYGV4cHIgMDAwMDEgOiAnLipcKC4uLlwpJ2AiID0gWDAwMTsg
dGhlbgorICBhc19leHByPWV4cHIKK2Vsc2UKKyAgYXNfZXhwcj1mYWxzZQorZmkKKworaWYgKGJh
c2VuYW1lIC0tIC8pID4vZGV2L251bGwgMj4mMSAmJiB0ZXN0ICJYYGJhc2VuYW1lIC0tIC8gMj4m
MWAiID0gIlgvIjsgdGhlbgorICBhc19iYXNlbmFtZT1iYXNlbmFtZQorZWxzZQorICBhc19iYXNl
bmFtZT1mYWxzZQorZmkKKworaWYgKGFzX2Rpcj1gZGlybmFtZSAtLSAvYCAmJiB0ZXN0ICJYJGFz
X2RpciIgPSBYLykgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgIGFzX2Rpcm5hbWU9ZGlybmFtZQor
ZWxzZQorICBhc19kaXJuYW1lPWZhbHNlCitmaQorCithc19tZT1gJGFzX2Jhc2VuYW1lIC0tICIk
MCIgfHwKKyRhc19leHByIFgvIiQwIiA6ICcuKi9cKFteL11bXi9dKlwpLyokJyBcfCBcCisJIFgi
JDAiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJDAiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVs
bCB8fAorJGFzX2VjaG8gWC8iJDAiIHwKKyAgICBzZWQgJy9eLipcL1woW14vXVteL10qXClcLyok
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwvXChcL1wvXCkkL3sKKwkgICAg
cy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwvXChcL1wpLioveworCSAgICBzLy9cMS8KKwkg
ICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisKKyMgQXZvaWQgZGVwZW5kaW5nIHVwb24gQ2hh
cmFjdGVyIFJhbmdlcy4KK2FzX2NyX2xldHRlcnM9J2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6
JworYXNfY3JfTEVUVEVSUz0nQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVonCithc19jcl9MZXR0
ZXJzPSRhc19jcl9sZXR0ZXJzJGFzX2NyX0xFVFRFUlMKK2FzX2NyX2RpZ2l0cz0nMDEyMzQ1Njc4
OScKK2FzX2NyX2FsbnVtPSRhc19jcl9MZXR0ZXJzJGFzX2NyX2RpZ2l0cworCitFQ0hPX0M9IEVD
SE9fTj0gRUNIT19UPQorY2FzZSBgZWNobyAtbiB4YCBpbiAjKCgoKCgKKy1uKikKKyAgY2FzZSBg
ZWNobyAneHlcYydgIGluCisgICpjKikgRUNIT19UPScJJzs7CSMgRUNIT19UIGlzIHNpbmdsZSB0
YWIgY2hhcmFjdGVyLgorICB4eSkgIEVDSE9fQz0nXGMnOzsKKyAgKikgICBlY2hvIGBlY2hvIGtz
aDg4IGJ1ZyBvbiBBSVggNi4xYCA+IC9kZXYvbnVsbAorICAgICAgIEVDSE9fVD0nCSc7OworICBl
c2FjOzsKKyopCisgIEVDSE9fTj0nLW4nOzsKK2VzYWMKKworcm0gLWYgY29uZiQkIGNvbmYkJC5l
eGUgY29uZiQkLmZpbGUKK2lmIHRlc3QgLWQgY29uZiQkLmRpcjsgdGhlbgorICBybSAtZiBjb25m
JCQuZGlyL2NvbmYkJC5maWxlCitlbHNlCisgIHJtIC1mIGNvbmYkJC5kaXIKKyAgbWtkaXIgY29u
ZiQkLmRpciAyPi9kZXYvbnVsbAorZmkKK2lmIChlY2hvID5jb25mJCQuZmlsZSkgMj4vZGV2L251
bGw7IHRoZW4KKyAgaWYgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVu
CisgICAgYXNfbG5fcz0nbG4gLXMnCisgICAgIyAuLi4gYnV0IHRoZXJlIGFyZSB0d28gZ290Y2hh
czoKKyAgICAjIDEpIE9uIE1TWVMsIGJvdGggYGxuIC1zIGZpbGUgZGlyJyBhbmQgYGxuIGZpbGUg
ZGlyJyBmYWlsLgorICAgICMgMikgREpHUFAgPCAyLjA0IGhhcyBubyBzeW1saW5rczsgYGxuIC1z
JyBjcmVhdGVzIGEgd3JhcHBlciBleGVjdXRhYmxlLgorICAgICMgSW4gYm90aCBjYXNlcywgd2Ug
aGF2ZSB0byBkZWZhdWx0IHRvIGBjcCAtcCcuCisgICAgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQk
LmRpciAyPi9kZXYvbnVsbCAmJiB0ZXN0ICEgLWYgY29uZiQkLmV4ZSB8fAorICAgICAgYXNfbG5f
cz0nY3AgLXAnCisgIGVsaWYgbG4gY29uZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVu
CisgICAgYXNfbG5fcz1sbgorICBlbHNlCisgICAgYXNfbG5fcz0nY3AgLXAnCisgIGZpCitlbHNl
CisgIGFzX2xuX3M9J2NwIC1wJworZmkKK3JtIC1mIGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5k
aXIvY29uZiQkLmZpbGUgY29uZiQkLmZpbGUKK3JtZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwK
KworCisjIGFzX2ZuX21rZGlyX3AKKyMgLS0tLS0tLS0tLS0tLQorIyBDcmVhdGUgIiRhc19kaXIi
IGFzIGEgZGlyZWN0b3J5LCBpbmNsdWRpbmcgcGFyZW50cyBpZiBuZWNlc3NhcnkuCithc19mbl9t
a2Rpcl9wICgpCit7CisKKyAgY2FzZSAkYXNfZGlyIGluICMoCisgIC0qKSBhc19kaXI9Li8kYXNf
ZGlyOzsKKyAgZXNhYworICB0ZXN0IC1kICIkYXNfZGlyIiB8fCBldmFsICRhc19ta2Rpcl9wIHx8
IHsKKyAgICBhc19kaXJzPQorICAgIHdoaWxlIDo7IGRvCisgICAgICBjYXNlICRhc19kaXIgaW4g
IygKKyAgICAgICpcJyopIGFzX3FkaXI9YCRhc19lY2hvICIkYXNfZGlyIiB8IHNlZCAicy8nLydc
XFxcXFxcXCcnL2ciYDs7ICMnKAorICAgICAgKikgYXNfcWRpcj0kYXNfZGlyOzsKKyAgICAgIGVz
YWMKKyAgICAgIGFzX2RpcnM9IickYXNfcWRpcicgJGFzX2RpcnMiCisgICAgICBhc19kaXI9YCRh
c19kaXJuYW1lIC0tICIkYXNfZGlyIiB8fAorJGFzX2V4cHIgWCIkYXNfZGlyIiA6ICdYXCguKlte
L11cKS8vKlteL11bXi9dKi8qJCcgXHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXClbXi9dJyBc
fCBcCisJIFgiJGFzX2RpciIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgv
XCknIFx8IC4gMj4vZGV2L251bGwgfHwKKyRhc19lY2hvIFgiJGFzX2RpciIgfAorICAgIHNlZCAn
L15YXCguKlteL11cKVwvXC8qW14vXVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJ
ICB9CisJICAvXlhcKFwvXC9cKVteL10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJ
ICAvXlhcKFwvXC9cKSQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wp
LioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgICAgICB0
ZXN0IC1kICIkYXNfZGlyIiAmJiBicmVhaworICAgIGRvbmUKKyAgICB0ZXN0IC16ICIkYXNfZGly
cyIgfHwgZXZhbCAibWtkaXIgJGFzX2RpcnMiCisgIH0gfHwgdGVzdCAtZCAiJGFzX2RpciIgfHwg
YXNfZm5fZXJyb3IgJD8gImNhbm5vdCBjcmVhdGUgZGlyZWN0b3J5ICRhc19kaXIiCisKKworfSAj
IGFzX2ZuX21rZGlyX3AKK2lmIG1rZGlyIC1wIC4gMj4vZGV2L251bGw7IHRoZW4KKyAgYXNfbWtk
aXJfcD0nbWtkaXIgLXAgIiRhc19kaXIiJworZWxzZQorICB0ZXN0IC1kIC4vLXAgJiYgcm1kaXIg
Li8tcAorICBhc19ta2Rpcl9wPWZhbHNlCitmaQorCitpZiB0ZXN0IC14IC8gPi9kZXYvbnVsbCAy
PiYxOyB0aGVuCisgIGFzX3Rlc3RfeD0ndGVzdCAteCcKK2Vsc2UKKyAgaWYgbHMgLWRMIC8gPi9k
ZXYvbnVsbCAyPiYxOyB0aGVuCisgICAgYXNfbHNfTF9vcHRpb249TAorICBlbHNlCisgICAgYXNf
bHNfTF9vcHRpb249CisgIGZpCisgIGFzX3Rlc3RfeD0nCisgICAgZXZhbCBzaCAtYyAnXCcnCisg
ICAgICBpZiB0ZXN0IC1kICIkMSI7IHRoZW4KKwl0ZXN0IC1kICIkMS8uIjsKKyAgICAgIGVsc2UK
KwljYXNlICQxIGluICMoCisJLSopc2V0ICIuLyQxIjs7CisJZXNhYzsKKwljYXNlIGBscyAtbGQn
JGFzX2xzX0xfb3B0aW9uJyAiJDEiIDI+L2Rldi9udWxsYCBpbiAjKCgKKwk/Pz9bc3hdKik6Ozsq
KWZhbHNlOztlc2FjO2ZpCisgICAgJ1wnJyBzaAorICAnCitmaQorYXNfZXhlY3V0YWJsZV9wPSRh
c190ZXN0X3gKKworIyBTZWQgZXhwcmVzc2lvbiB0byBtYXAgYSBzdHJpbmcgb250byBhIHZhbGlk
IENQUCBuYW1lLgorYXNfdHJfY3BwPSJldmFsIHNlZCAneSUqJGFzX2NyX2xldHRlcnMlUCRhc19j
cl9MRVRURVJTJTtzJVteXyRhc19jcl9hbG51bV0lXyVnJyIKKworIyBTZWQgZXhwcmVzc2lvbiB0
byBtYXAgYSBzdHJpbmcgb250byBhIHZhbGlkIHZhcmlhYmxlIG5hbWUuCithc190cl9zaD0iZXZh
bCBzZWQgJ3klKislcHAlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisKK2V4ZWMgNj4mMQor
IyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE1haW4gYm9keSBv
ZiAkQ09ORklHX1NUQVRVUyBzY3JpcHQuICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSAjIworX0FTRU9GCit0ZXN0ICRhc193cml0ZV9mYWlsID0gMCAmJiBjaG1vZCAr
eCAkQ09ORklHX1NUQVRVUyB8fCBhY193cml0ZV9mYWlsPTEKKworY2F0ID4+JENPTkZJR19TVEFU
VVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBTYXZlIHRoZSBsb2cgbWVzc2FnZSwg
dG8ga2VlcCAkMCBhbmQgc28gb24gbWVhbmluZ2Z1bCwgYW5kIHRvCisjIHJlcG9ydCBhY3R1YWwg
aW5wdXQgdmFsdWVzIG9mIENPTkZJR19GSUxFUyBldGMuIGluc3RlYWQgb2YgdGhlaXIKKyMgdmFs
dWVzIGFmdGVyIG9wdGlvbnMgaGFuZGxpbmcuCithY19sb2c9IgorVGhpcyBmaWxlIHdhcyBleHRl
bmRlZCBieSBYZW4gSHlwZXJ2aXNvciAkYXNfbWUgNC4yLCB3aGljaCB3YXMKK2dlbmVyYXRlZCBi
eSBHTlUgQXV0b2NvbmYgMi42OC4gIEludm9jYXRpb24gY29tbWFuZCBsaW5lIHdhcworCisgIENP
TkZJR19GSUxFUyAgICA9ICRDT05GSUdfRklMRVMKKyAgQ09ORklHX0hFQURFUlMgID0gJENPTkZJ
R19IRUFERVJTCisgIENPTkZJR19MSU5LUyAgICA9ICRDT05GSUdfTElOS1MKKyAgQ09ORklHX0NP
TU1BTkRTID0gJENPTkZJR19DT01NQU5EUworICAkICQwICRACisKK29uIGAoaG9zdG5hbWUgfHwg
dW5hbWUgLW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAorIgorCitfQUNFT0YKKworY2FzZSAkYWNf
Y29uZmlnX2ZpbGVzIGluICoiCisiKikgc2V0IHggJGFjX2NvbmZpZ19maWxlczsgc2hpZnQ7IGFj
X2NvbmZpZ19maWxlcz0kKjs7Citlc2FjCisKK2Nhc2UgJGFjX2NvbmZpZ19oZWFkZXJzIGluICoi
CisiKikgc2V0IHggJGFjX2NvbmZpZ19oZWFkZXJzOyBzaGlmdDsgYWNfY29uZmlnX2hlYWRlcnM9
JCo7OworZXNhYworCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRl
X2ZhaWw9MQorIyBGaWxlcyB0aGF0IGNvbmZpZy5zdGF0dXMgd2FzIG1hZGUgZm9yLgorY29uZmln
X2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIgorY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVh
ZGVycyIKKworX0FDRU9GCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193
cml0ZV9mYWlsPTEKK2FjX2NzX3VzYWdlPSJcCitcYCRhc19tZScgaW5zdGFudGlhdGVzIGZpbGVz
IGFuZCBvdGhlciBjb25maWd1cmF0aW9uIGFjdGlvbnMKK2Zyb20gdGVtcGxhdGVzIGFjY29yZGlu
ZyB0byB0aGUgY3VycmVudCBjb25maWd1cmF0aW9uLiAgVW5sZXNzIHRoZSBmaWxlcworYW5kIGFj
dGlvbnMgYXJlIHNwZWNpZmllZCBhcyBUQUdzLCBhbGwgYXJlIGluc3RhbnRpYXRlZCBieSBkZWZh
dWx0LgorCitVc2FnZTogJDAgW09QVElPTl0uLi4gW1RBR10uLi4KKworICAtaCwgLS1oZWxwICAg
ICAgIHByaW50IHRoaXMgaGVscCwgdGhlbiBleGl0CisgIC1WLCAtLXZlcnNpb24gICAgcHJpbnQg
dmVyc2lvbiBudW1iZXIgYW5kIGNvbmZpZ3VyYXRpb24gc2V0dGluZ3MsIHRoZW4gZXhpdAorICAg
ICAgLS1jb25maWcgICAgIHByaW50IGNvbmZpZ3VyYXRpb24sIHRoZW4gZXhpdAorICAtcSwgLS1x
dWlldCwgLS1zaWxlbnQKKyAgICAgICAgICAgICAgICAgICBkbyBub3QgcHJpbnQgcHJvZ3Jlc3Mg
bWVzc2FnZXMKKyAgLWQsIC0tZGVidWcgICAgICBkb24ndCByZW1vdmUgdGVtcG9yYXJ5IGZpbGVz
CisgICAgICAtLXJlY2hlY2sgICAgdXBkYXRlICRhc19tZSBieSByZWNvbmZpZ3VyaW5nIGluIHRo
ZSBzYW1lIGNvbmRpdGlvbnMKKyAgICAgIC0tZmlsZT1GSUxFWzpURU1QTEFURV0KKyAgICAgICAg
ICAgICAgICAgICBpbnN0YW50aWF0ZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlIEZJTEUKKyAgICAg
IC0taGVhZGVyPUZJTEVbOlRFTVBMQVRFXQorICAgICAgICAgICAgICAgICAgIGluc3RhbnRpYXRl
IHRoZSBjb25maWd1cmF0aW9uIGhlYWRlciBGSUxFCisKK0NvbmZpZ3VyYXRpb24gZmlsZXM6Cisk
Y29uZmlnX2ZpbGVzCisKK0NvbmZpZ3VyYXRpb24gaGVhZGVyczoKKyRjb25maWdfaGVhZGVycwor
CitSZXBvcnQgYnVncyB0byA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20+LiIKKworX0FD
RU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2Fj
X2NzX2NvbmZpZz0iYCRhc19lY2hvICIkYWNfY29uZmlndXJlX2FyZ3MiIHwgc2VkICdzL14gLy87
IHMvW1xcIiJcYFwkXS9cXFxcJi9nJ2AiCithY19jc192ZXJzaW9uPSJcXAorWGVuIEh5cGVydmlz
b3IgY29uZmlnLnN0YXR1cyA0LjIKK2NvbmZpZ3VyZWQgYnkgJDAsIGdlbmVyYXRlZCBieSBHTlUg
QXV0b2NvbmYgMi42OCwKKyAgd2l0aCBvcHRpb25zIFxcIlwkYWNfY3NfY29uZmlnXFwiCisKK0Nv
cHlyaWdodCAoQykgMjAxMCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KK1RoaXMgY29u
ZmlnLnN0YXR1cyBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbgorZ2l2ZXMgdW5saW1pdGVkIHBlcm1pc3Npb24gdG8gY29weSwgZGlzdHJpYnV0ZSBh
bmQgbW9kaWZ5IGl0LiIKKworYWNfcHdkPSckYWNfcHdkJworc3JjZGlyPSckc3JjZGlyJworSU5T
VEFMTD0nJElOU1RBTEwnCit0ZXN0IC1uICJcJEFXSyIgfHwgQVdLPWF3aworX0FDRU9GCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyMgVGhlIGRl
ZmF1bHQgbGlzdHMgYXBwbHkgaWYgdGhlIHVzZXIgZG9lcyBub3Qgc3BlY2lmeSBhbnkgZmlsZS4K
K2FjX25lZWRfZGVmYXVsdHM9Ogord2hpbGUgdGVzdCAkIyAhPSAwCitkbworICBjYXNlICQxIGlu
CisgIC0tKj0/KikKKyAgICBhY19vcHRpb249YGV4cHIgIlgkMSIgOiAnWFwoW149XSpcKT0nYAor
ICAgIGFjX29wdGFyZz1gZXhwciAiWCQxIiA6ICdYW149XSo9XCguKlwpJ2AKKyAgICBhY19zaGlm
dD06CisgICAgOzsKKyAgLS0qPSkKKyAgICBhY19vcHRpb249YGV4cHIgIlgkMSIgOiAnWFwoW149
XSpcKT0nYAorICAgIGFjX29wdGFyZz0KKyAgICBhY19zaGlmdD06CisgICAgOzsKKyAgKikKKyAg
ICBhY19vcHRpb249JDEKKyAgICBhY19vcHRhcmc9JDIKKyAgICBhY19zaGlmdD1zaGlmdAorICAg
IDs7CisgIGVzYWMKKworICBjYXNlICRhY19vcHRpb24gaW4KKyAgIyBIYW5kbGluZyBvZiB0aGUg
b3B0aW9ucy4KKyAgLXJlY2hlY2sgfCAtLXJlY2hlY2sgfCAtLXJlY2hlYyB8IC0tcmVjaGUgfCAt
LXJlY2ggfCAtLXJlYyB8IC0tcmUgfCAtLXIpCisgICAgYWNfY3NfcmVjaGVjaz06IDs7CisgIC0t
dmVyc2lvbiB8IC0tdmVyc2lvIHwgLS12ZXJzaSB8IC0tdmVycyB8IC0tdmVyIHwgLS12ZSB8IC0t
diB8IC1WICkKKyAgICAkYXNfZWNobyAiJGFjX2NzX3ZlcnNpb24iOyBleGl0IDs7CisgIC0tY29u
ZmlnIHwgLS1jb25maSB8IC0tY29uZiB8IC0tY29uIHwgLS1jbyB8IC0tYyApCisgICAgJGFzX2Vj
aG8gIiRhY19jc19jb25maWciOyBleGl0IDs7CisgIC0tZGVidWcgfCAtLWRlYnUgfCAtLWRlYiB8
IC0tZGUgfCAtLWQgfCAtZCApCisgICAgZGVidWc9OiA7OworICAtLWZpbGUgfCAtLWZpbCB8IC0t
ZmkgfCAtLWYgKQorICAgICRhY19zaGlmdAorICAgIGNhc2UgJGFjX29wdGFyZyBpbgorICAgICpc
JyopIGFjX29wdGFyZz1gJGFzX2VjaG8gIiRhY19vcHRhcmciIHwgc2VkICJzLycvJ1xcXFxcXFxc
JycvZyJgIDs7CisgICAgJycpIGFzX2ZuX2Vycm9yICQ/ICJtaXNzaW5nIGZpbGUgYXJndW1lbnQi
IDs7CisgICAgZXNhYworICAgIGFzX2ZuX2FwcGVuZCBDT05GSUdfRklMRVMgIiAnJGFjX29wdGFy
ZyciCisgICAgYWNfbmVlZF9kZWZhdWx0cz1mYWxzZTs7CisgIC0taGVhZGVyIHwgLS1oZWFkZSB8
IC0taGVhZCB8IC0taGVhICkKKyAgICAkYWNfc2hpZnQKKyAgICBjYXNlICRhY19vcHRhcmcgaW4K
KyAgICAqXCcqKSBhY19vcHRhcmc9YCRhc19lY2hvICIkYWNfb3B0YXJnIiB8IHNlZCAicy8nLydc
XFxcXFxcXCcnL2ciYCA7OworICAgIGVzYWMKKyAgICBhc19mbl9hcHBlbmQgQ09ORklHX0hFQURF
UlMgIiAnJGFjX29wdGFyZyciCisgICAgYWNfbmVlZF9kZWZhdWx0cz1mYWxzZTs7CisgIC0taGUg
fCAtLWgpCisgICAgIyBDb25mbGljdCBiZXR3ZWVuIC0taGVscCBhbmQgLS1oZWFkZXIKKyAgICBh
c19mbl9lcnJvciAkPyAiYW1iaWd1b3VzIG9wdGlvbjogXGAkMScKK1RyeSBcYCQwIC0taGVscCcg
Zm9yIG1vcmUgaW5mb3JtYXRpb24uIjs7CisgIC0taGVscCB8IC0taGVsIHwgLWggKQorICAgICRh
c19lY2hvICIkYWNfY3NfdXNhZ2UiOyBleGl0IDs7CisgIC1xIHwgLXF1aWV0IHwgLS1xdWlldCB8
IC0tcXVpZSB8IC0tcXVpIHwgLS1xdSB8IC0tcSBcCisgIHwgLXNpbGVudCB8IC0tc2lsZW50IHwg
LS1zaWxlbiB8IC0tc2lsZSB8IC0tc2lsIHwgLS1zaSB8IC0tcykKKyAgICBhY19jc19zaWxlbnQ9
OiA7OworCisgICMgVGhpcyBpcyBhbiBlcnJvci4KKyAgLSopIGFzX2ZuX2Vycm9yICQ/ICJ1bnJl
Y29nbml6ZWQgb3B0aW9uOiBcYCQxJworVHJ5IFxgJDAgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1h
dGlvbi4iIDs7CisKKyAgKikgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ190YXJnZXRzICIgJDEiCisg
ICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2UgOzsKKworICBlc2FjCisgIHNoaWZ0Citkb25lCisK
K2FjX2NvbmZpZ3VyZV9leHRyYV9hcmdzPQorCitpZiAkYWNfY3Nfc2lsZW50OyB0aGVuCisgIGV4
ZWMgNj4vZGV2L251bGwKKyAgYWNfY29uZmlndXJlX2V4dHJhX2FyZ3M9IiRhY19jb25maWd1cmVf
ZXh0cmFfYXJncyAtLXNpbGVudCIKK2ZpCisKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMg
PDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitpZiBcJGFjX2NzX3JlY2hlY2s7IHRoZW4KKyAg
c2V0IFggJyRTSEVMTCcgJyQwJyAkYWNfY29uZmlndXJlX2FyZ3MgXCRhY19jb25maWd1cmVfZXh0
cmFfYXJncyAtLW5vLWNyZWF0ZSAtLW5vLXJlY3Vyc2lvbgorICBzaGlmdAorICBcJGFzX2VjaG8g
InJ1bm5pbmcgQ09ORklHX1NIRUxMPSRTSEVMTCBcJCoiID4mNgorICBDT05GSUdfU0hFTEw9JyRT
SEVMTCcKKyAgZXhwb3J0IENPTkZJR19TSEVMTAorICBleGVjICJcJEAiCitmaQorCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2V4ZWMg
NT4+Y29uZmlnLmxvZworeworICBlY2hvCisgIHNlZCAnaDtzLy4vLS9nO3MvXi4uLi8jIyAvO3Mv
Li4uJC8gIyMvO3A7eDtwO3gnIDw8X0FTQk9YCisjIyBSdW5uaW5nICRhc19tZS4gIyMKK19BU0JP
WAorICAkYXNfZWNobyAiJGFjX2xvZyIKK30gPiY1CisKK19BQ0VPRgorY2F0ID4+JENPTkZJR19T
VEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitfQUNFT0YKKworY2F0ID4+JENPTkZJ
R19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorCisjIEhhbmRsaW5nIG9mIGFy
Z3VtZW50cy4KK2ZvciBhY19jb25maWdfdGFyZ2V0IGluICRhY19jb25maWdfdGFyZ2V0cworZG8K
KyAgY2FzZSAkYWNfY29uZmlnX3RhcmdldCBpbgorICAgICIuLi9jb25maWcvVG9vbHMubWsiKSBD
T05GSUdfRklMRVM9IiRDT05GSUdfRklMRVMgLi4vY29uZmlnL1Rvb2xzLm1rIiA7OworICAgICJj
b25maWcuaCIpIENPTkZJR19IRUFERVJTPSIkQ09ORklHX0hFQURFUlMgY29uZmlnLmgiIDs7CisK
KyAgKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgYXJndW1lbnQ6IFxgJGFjX2NvbmZpZ190YXJn
ZXQnIiAiJExJTkVOTyIgNTs7CisgIGVzYWMKK2RvbmUKKworCisjIElmIHRoZSB1c2VyIGRpZCBu
b3QgdXNlIHRoZSBhcmd1bWVudHMgdG8gc3BlY2lmeSB0aGUgaXRlbXMgdG8gaW5zdGFudGlhdGUs
CisjIHRoZW4gdGhlIGVudnZhciBpbnRlcmZhY2UgaXMgdXNlZC4gIFNldCBvbmx5IHRob3NlIHRo
YXQgYXJlIG5vdC4KKyMgV2UgdXNlIHRoZSBsb25nIGZvcm0gZm9yIHRoZSBkZWZhdWx0IGFzc2ln
bm1lbnQgYmVjYXVzZSBvZiBhbiBleHRyZW1lbHkKKyMgYml6YXJyZSBidWcgb24gU3VuT1MgNC4x
LjMuCitpZiAkYWNfbmVlZF9kZWZhdWx0czsgdGhlbgorICB0ZXN0ICIke0NPTkZJR19GSUxFUytz
ZXR9IiA9IHNldCB8fCBDT05GSUdfRklMRVM9JGNvbmZpZ19maWxlcworICB0ZXN0ICIke0NPTkZJ
R19IRUFERVJTK3NldH0iID0gc2V0IHx8IENPTkZJR19IRUFERVJTPSRjb25maWdfaGVhZGVycwor
ZmkKKworIyBIYXZlIGEgdGVtcG9yYXJ5IGRpcmVjdG9yeSBmb3IgY29udmVuaWVuY2UuICBNYWtl
IGl0IGluIHRoZSBidWlsZCB0cmVlCisjIHNpbXBseSBiZWNhdXNlIHRoZXJlIGlzIG5vIHJlYXNv
biBhZ2FpbnN0IGhhdmluZyBpdCBoZXJlLCBhbmQgaW4gYWRkaXRpb24sCisjIGNyZWF0aW5nIGFu
ZCBtb3ZpbmcgZmlsZXMgZnJvbSAvdG1wIGNhbiBzb21ldGltZXMgY2F1c2UgcHJvYmxlbXMuCisj
IEhvb2sgZm9yIGl0cyByZW1vdmFsIHVubGVzcyBkZWJ1Z2dpbmcuCisjIE5vdGUgdGhhdCB0aGVy
ZSBpcyBhIHNtYWxsIHdpbmRvdyBpbiB3aGljaCB0aGUgZGlyZWN0b3J5IHdpbGwgbm90IGJlIGNs
ZWFuZWQ6CisjIGFmdGVyIGl0cyBjcmVhdGlvbiBidXQgYmVmb3JlIGl0cyBuYW1lIGhhcyBiZWVu
IGFzc2lnbmVkIHRvIGAkdG1wJy4KKyRkZWJ1ZyB8fAoreworICB0bXA9IGFjX3RtcD0KKyAgdHJh
cCAnZXhpdF9zdGF0dXM9JD8KKyAgOiAiJHthY190bXA6PSR0bXB9IgorICB7IHRlc3QgISAtZCAi
JGFjX3RtcCIgfHwgcm0gLWZyICIkYWNfdG1wIjsgfSAmJiBleGl0ICRleGl0X3N0YXR1cworJyAw
CisgIHRyYXAgJ2FzX2ZuX2V4aXQgMScgMSAyIDEzIDE1Cit9CisjIENyZWF0ZSBhIChzZWN1cmUp
IHRtcCBkaXJlY3RvcnkgZm9yIHRtcCBmaWxlcy4KKworeworICB0bXA9YCh1bWFzayAwNzcgJiYg
bWt0ZW1wIC1kICIuL2NvbmZYWFhYWFgiKSAyPi9kZXYvbnVsbGAgJiYKKyAgdGVzdCAtZCAiJHRt
cCIKK30gIHx8Cit7CisgIHRtcD0uL2NvbmYkJC0kUkFORE9NCisgICh1bWFzayAwNzcgJiYgbWtk
aXIgIiR0bXAiKQorfSB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFy
eSBkaXJlY3RvcnkgaW4gLiIgIiRMSU5FTk8iIDUKK2FjX3RtcD0kdG1wCisKKyMgU2V0IHVwIHRo
ZSBzY3JpcHRzIGZvciBDT05GSUdfRklMRVMgc2VjdGlvbi4KKyMgTm8gbmVlZCB0byBnZW5lcmF0
ZSB0aGVtIGlmIHRoZXJlIGFyZSBubyBDT05GSUdfRklMRVMuCisjIFRoaXMgaGFwcGVucyBmb3Ig
aW5zdGFuY2Ugd2l0aCBgLi9jb25maWcuc3RhdHVzIGNvbmZpZy5oJy4KK2lmIHRlc3QgLW4gIiRD
T05GSUdfRklMRVMiOyB0aGVuCisKKworYWNfY3I9YGVjaG8gWCB8IHRyIFggJ1wwMTUnYAorIyBP
biBjeWd3aW4sIGJhc2ggY2FuIGVhdCBcciBpbnNpZGUgYGAgaWYgdGhlIHVzZXIgcmVxdWVzdGVk
IGlnbmNyLgorIyBCdXQgd2Uga25vdyBvZiBubyBvdGhlciBzaGVsbCB3aGVyZSBhY19jciB3b3Vs
ZCBiZSBlbXB0eSBhdCB0aGlzCisjIHBvaW50LCBzbyB3ZSBjYW4gdXNlIGEgYmFzaGlzbSBhcyBh
IGZhbGxiYWNrLgoraWYgdGVzdCAieCRhY19jciIgPSB4OyB0aGVuCisgIGV2YWwgYWNfY3I9XCRc
J1xcclwnCitmaQorYWNfY3NfYXdrX2NyPWAkQVdLICdCRUdJTiB7IHByaW50ICJhXHJiIiB9JyA8
L2Rldi9udWxsIDI+L2Rldi9udWxsYAoraWYgdGVzdCAiJGFjX2NzX2F3a19jciIgPSAiYSR7YWNf
Y3J9YiI7IHRoZW4KKyAgYWNfY3NfYXdrX2NyPSdcXHInCitlbHNlCisgIGFjX2NzX2F3a19jcj0k
YWNfY3IKK2ZpCisKK2VjaG8gJ0JFR0lOIHsnID4iJGFjX3RtcC9zdWJzMS5hd2siICYmCitfQUNF
T0YKKworCit7CisgIGVjaG8gImNhdCA+Y29uZiQkc3Vicy5hd2sgPDxfQUNFT0YiICYmCisgIGVj
aG8gIiRhY19zdWJzdF92YXJzIiB8IHNlZCAncy8uKi8mISQmJGFjX2RlbGltLycgJiYKKyAgZWNo
byAiX0FDRU9GIgorfSA+Y29uZiQkc3Vicy5zaCB8fAorICBhc19mbl9lcnJvciAkPyAiY291bGQg
bm90IG1ha2UgJENPTkZJR19TVEFUVVMiICIkTElORU5PIiA1CithY19kZWxpbV9udW09YGVjaG8g
IiRhY19zdWJzdF92YXJzIiB8IGdyZXAgLWMgJ14nYAorYWNfZGVsaW09JyUhXyEjICcKK2ZvciBh
Y19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSA6OyBkbworICAuIC4v
Y29uZiQkc3Vicy5zaCB8fAorICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFrZSAkQ09O
RklHX1NUQVRVUyIgIiRMSU5FTk8iIDUKKworICBhY19kZWxpbV9uPWBzZWQgLW4gInMvLiokYWNf
ZGVsaW1cJC9YL3AiIGNvbmYkJHN1YnMuYXdrIHwgZ3JlcCAtYyBYYAorICBpZiB0ZXN0ICRhY19k
ZWxpbV9uID0gJGFjX2RlbGltX251bTsgdGhlbgorICAgIGJyZWFrCisgIGVsaWYgJGFjX2xhc3Rf
dHJ5OyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05GSUdfU1RB
VFVTIiAiJExJTkVOTyIgNQorICBlbHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEkYWNfZGVs
aW0gXyRhY19kZWxpbSEhICIKKyAgZmkKK2RvbmUKK3JtIC1mIGNvbmYkJHN1YnMuc2gKKworY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitjYXQgPj4iXCRh
Y190bXAvc3ViczEuYXdrIiA8PFxcX0FDQVdLICYmCitfQUNFT0YKK3NlZCAtbiAnCitoCitzL14v
U1siLzsgcy8hLiovIl09LworcAorZworcy9eW14hXSohLy8KKzpyZXBsCit0IHJlcGwKK3MvJyIk
YWNfZGVsaW0iJyQvLwordCBkZWxpbQorOm5sCitoCitzL1woLlx7MTQ4XH1cKS4uKi9cMS8KK3Qg
bW9yZTEKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kL1xcbiJcXC8KK3AKK24KK2IgcmVwbAor
Om1vcmUxCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0OFx9
Ly8KK3QgbmwKKzpkZWxpbQoraAorcy9cKC5cezE0OFx9XCkuLiovXDEvCit0IG1vcmUyCitzL1si
XFxdL1xcJi9nOyBzL14vIi87IHMvJC8iLworcAorYgorOm1vcmUyCitzL1siXFxdL1xcJi9nOyBz
L14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0OFx9Ly8KK3QgZGVsaW0KKycgPGNvbmYkJHN1
YnMuYXdrIHwgc2VkICcKKy9eW14iIl0veworICBOCisgIHMvXG4vLworfQorJyA+PiRDT05GSUdf
U1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorcm0gLWYgY29uZiQkc3Vicy5hd2sKK2NhdCA+PiRD
T05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorX0FDQVdLCitjYXQgPj4i
XCRhY190bXAvc3ViczEuYXdrIiA8PF9BQ0FXSyAmJgorICBmb3IgKGtleSBpbiBTKSBTX2lzX3Nl
dFtrZXldID0gMQorICBGUyA9ICIHIgorCit9Cit7CisgIGxpbmUgPSAkIDAKKyAgbmZpZWxkcyA9
IHNwbGl0KGxpbmUsIGZpZWxkLCAiQCIpCisgIHN1YnN0ZWQgPSAwCisgIGxlbiA9IGxlbmd0aChm
aWVsZFsxXSkKKyAgZm9yIChpID0gMjsgaSA8IG5maWVsZHM7IGkrKykgeworICAgIGtleSA9IGZp
ZWxkW2ldCisgICAga2V5bGVuID0gbGVuZ3RoKGtleSkKKyAgICBpZiAoU19pc19zZXRba2V5XSkg
eworICAgICAgdmFsdWUgPSBTW2tleV0KKyAgICAgIGxpbmUgPSBzdWJzdHIobGluZSwgMSwgbGVu
KSAiIiB2YWx1ZSAiIiBzdWJzdHIobGluZSwgbGVuICsga2V5bGVuICsgMykKKyAgICAgIGxlbiAr
PSBsZW5ndGgodmFsdWUpICsgbGVuZ3RoKGZpZWxkWysraV0pCisgICAgICBzdWJzdGVkID0gMQor
ICAgIH0gZWxzZQorICAgICAgbGVuICs9IDEgKyBrZXlsZW4KKyAgfQorCisgIHByaW50IGxpbmUK
K30KKworX0FDQVdLCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBh
Y193cml0ZV9mYWlsPTEKK2lmIHNlZCAicy8kYWNfY3IvLyIgPCAvZGV2L251bGwgPiAvZGV2L251
bGwgMj4mMTsgdGhlbgorICBzZWQgInMvJGFjX2NyXCQvLzsgcy8kYWNfY3IvJGFjX2NzX2F3a19j
ci9nIgorZWxzZQorICBjYXQKK2ZpIDwgIiRhY190bXAvc3ViczEuYXdrIiA+ICIkYWNfdG1wL3N1
YnMuYXdrIiBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGZp
bGVzIG1hY2hpbmVyeSIgIiRMSU5FTk8iIDUKK19BQ0VPRgorCisjIFZQQVRIIG1heSBjYXVzZSB0
cm91YmxlIHdpdGggc29tZSBtYWtlcywgc28gd2UgcmVtb3ZlIHNvbGUgJChzcmNkaXIpLAorIyAk
e3NyY2Rpcn0gYW5kIEBzcmNkaXJAIGVudHJpZXMgZnJvbSBWUEFUSCBpZiBzcmNkaXIgaXMgIi4i
LCBzdHJpcCBsZWFkaW5nIGFuZAorIyB0cmFpbGluZyBjb2xvbnMgYW5kIHRoZW4gcmVtb3ZlIHRo
ZSB3aG9sZSBsaW5lIGlmIFZQQVRIIGJlY29tZXMgZW1wdHkKKyMgKGFjdHVhbGx5IHdlIGxlYXZl
IGFuIGVtcHR5IGxpbmUgdG8gcHJlc2VydmUgbGluZSBudW1iZXJzKS4KK2lmIHRlc3QgIngkc3Jj
ZGlyIiA9IHguOyB0aGVuCisgIGFjX3Zwc3ViPScvXlsJIF0qVlBBVEhbCSBdKj1bCSBdKi97Cito
CitzLy8vCitzL14vOi8KK3MvWwkgXSokLzovCitzLzpcJChzcmNkaXIpOi86L2cKK3MvOlwke3Ny
Y2Rpcn06LzovZworcy86QHNyY2RpckA6LzovZworcy9eOiovLworcy86KiQvLworeAorcy9cKD1b
CSBdKlwpLiovXDEvCitHCitzL1xuLy8KK3MvXltePV0qPVsJIF0qJC8vCit9JworZmkKKworY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorZmkgIyB0ZXN0
IC1uICIkQ09ORklHX0ZJTEVTIgorCisjIFNldCB1cCB0aGUgc2NyaXB0cyBmb3IgQ09ORklHX0hF
QURFUlMgc2VjdGlvbi4KKyMgTm8gbmVlZCB0byBnZW5lcmF0ZSB0aGVtIGlmIHRoZXJlIGFyZSBu
byBDT05GSUdfSEVBREVSUy4KKyMgVGhpcyBoYXBwZW5zIGZvciBpbnN0YW5jZSB3aXRoIGAuL2Nv
bmZpZy5zdGF0dXMgTWFrZWZpbGUnLgoraWYgdGVzdCAtbiAiJENPTkZJR19IRUFERVJTIjsgdGhl
bgorY2F0ID4iJGFjX3RtcC9kZWZpbmVzLmF3ayIgPDxcX0FDQVdLIHx8CitCRUdJTiB7CitfQUNF
T0YKKworIyBUcmFuc2Zvcm0gY29uZmRlZnMuaCBpbnRvIGFuIGF3ayBzY3JpcHQgYGRlZmluZXMu
YXdrJywgZW1iZWRkZWQgYXMKKyMgaGVyZS1kb2N1bWVudCBpbiBjb25maWcuc3RhdHVzLCB0aGF0
IHN1YnN0aXR1dGVzIHRoZSBwcm9wZXIgdmFsdWVzIGludG8KKyMgY29uZmlnLmguaW4gdG8gcHJv
ZHVjZSBjb25maWcuaC4KKworIyBDcmVhdGUgYSBkZWxpbWl0ZXIgc3RyaW5nIHRoYXQgZG9lcyBu
b3QgZXhpc3QgaW4gY29uZmRlZnMuaCwgdG8gZWFzZQorIyBoYW5kbGluZyBvZiBsb25nIGxpbmVz
LgorYWNfZGVsaW09JyUhXyEjICcKK2ZvciBhY19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSA6OyBk
bworICBhY190dD1gc2VkIC1uICIvJGFjX2RlbGltL3AiIGNvbmZkZWZzLmhgCisgIGlmIHRlc3Qg
LXogIiRhY190dCI7IHRoZW4KKyAgICBicmVhaworICBlbGlmICRhY19sYXN0X3RyeTsgdGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFrZSAkQ09ORklHX0hFQURFUlMiICIkTElO
RU5PIiA1CisgIGVsc2UKKyAgICBhY19kZWxpbT0iJGFjX2RlbGltISRhY19kZWxpbSBfJGFjX2Rl
bGltISEgIgorICBmaQorZG9uZQorCisjIEZvciB0aGUgYXdrIHNjcmlwdCwgRCBpcyBhbiBhcnJh
eSBvZiBtYWNybyB2YWx1ZXMga2V5ZWQgYnkgbmFtZSwKKyMgbGlrZXdpc2UgUCBjb250YWlucyBt
YWNybyBwYXJhbWV0ZXJzIGlmIGFueS4gIFByZXNlcnZlIGJhY2tzbGFzaAorIyBuZXdsaW5lIHNl
cXVlbmNlcy4KKworYWNfd29yZF9yZT1bXyRhc19jcl9MZXR0ZXJzXVtfJGFzX2NyX2FsbnVtXSoK
K3NlZCAtbiAnCitzLy5cezE0OFx9LyYnIiRhY19kZWxpbSInL2cKK3QgcnNldAorOnJzZXQKK3Mv
XlsJIF0qI1sJIF0qZGVmaW5lWwkgXVsJIF0qLyAvCit0IGRlZgorZAorOmRlZgorcy9cXCQvLwor
dCBic25sCitzL1siXFxdL1xcJi9nCitzL14gXCgnIiRhY193b3JkX3JlIidcKVwoKFteKCldKilc
KVsJIF0qXCguKlwpL1BbIlwxIl09IlwyIlwKK0RbIlwxIl09IiBcMyIvcAorcy9eIFwoJyIkYWNf
d29yZF9yZSInXClbCSBdKlwoLipcKS9EWyJcMSJdPSIgXDIiL3AKK2QKKzpic25sCitzL1siXFxd
L1xcJi9nCitzL14gXCgnIiRhY193b3JkX3JlIidcKVwoKFteKCldKilcKVsJIF0qXCguKlwpL1Bb
IlwxIl09IlwyIlwKK0RbIlwxIl09IiBcM1xcXFxcXG4iXFwvcAordCBjb250CitzL14gXCgnIiRh
Y193b3JkX3JlIidcKVsJIF0qXCguKlwpL0RbIlwxIl09IiBcMlxcXFxcXG4iXFwvcAordCBjb250
CitkCis6Y29udAorbgorcy8uXHsxNDhcfS8mJyIkYWNfZGVsaW0iJy9nCit0IGNsZWFyCis6Y2xl
YXIKK3MvXFwkLy8KK3QgYnNubGMKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kLyIvcAorZAor
OmJzbmxjCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC9cXFxcXFxuIlxcL3AKK2IgY29udAor
JyA8Y29uZmRlZnMuaCB8IHNlZCAnCitzLyciJGFjX2RlbGltIicvIlxcXAorIi9nJyA+PiRDT05G
SUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9B
Q0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyAgZm9yIChrZXkgaW4gRCkgRF9pc19zZXRba2V5XSA9
IDEKKyAgRlMgPSAiByIKK30KKy9eW1x0IF0qI1tcdCBdKihkZWZpbmV8dW5kZWYpW1x0IF0rJGFj
X3dvcmRfcmUoW1x0IChdfFwkKS8geworICBsaW5lID0gXCQgMAorICBzcGxpdChsaW5lLCBhcmcs
ICIgIikKKyAgaWYgKGFyZ1sxXSA9PSAiIyIpIHsKKyAgICBkZWZ1bmRlZiA9IGFyZ1syXQorICAg
IG1hYzEgPSBhcmdbM10KKyAgfSBlbHNlIHsKKyAgICBkZWZ1bmRlZiA9IHN1YnN0cihhcmdbMV0s
IDIpCisgICAgbWFjMSA9IGFyZ1syXQorICB9CisgIHNwbGl0KG1hYzEsIG1hYzIsICIoIikgIykK
KyAgbWFjcm8gPSBtYWMyWzFdCisgIHByZWZpeCA9IHN1YnN0cihsaW5lLCAxLCBpbmRleChsaW5l
LCBkZWZ1bmRlZikgLSAxKQorICBpZiAoRF9pc19zZXRbbWFjcm9dKSB7CisgICAgIyBQcmVzZXJ2
ZSB0aGUgd2hpdGUgc3BhY2Ugc3Vycm91bmRpbmcgdGhlICIjIi4KKyAgICBwcmludCBwcmVmaXgg
ImRlZmluZSIsIG1hY3JvIFBbbWFjcm9dIERbbWFjcm9dCisgICAgbmV4dAorICB9IGVsc2Ugewor
ICAgICMgUmVwbGFjZSAjdW5kZWYgd2l0aCBjb21tZW50cy4gIFRoaXMgaXMgbmVjZXNzYXJ5LCBm
b3IgZXhhbXBsZSwKKyAgICAjIGluIHRoZSBjYXNlIG9mIF9QT1NJWF9TT1VSQ0UsIHdoaWNoIGlz
IHByZWRlZmluZWQgYW5kIHJlcXVpcmVkCisgICAgIyBvbiBzb21lIHN5c3RlbXMgd2hlcmUgY29u
ZmlndXJlIHdpbGwgbm90IGRlY2lkZSB0byBkZWZpbmUgaXQuCisgICAgaWYgKGRlZnVuZGVmID09
ICJ1bmRlZiIpIHsKKyAgICAgIHByaW50ICIvKiIsIHByZWZpeCBkZWZ1bmRlZiwgbWFjcm8sICIq
LyIKKyAgICAgIG5leHQKKyAgICB9CisgIH0KK30KK3sgcHJpbnQgfQorX0FDQVdLCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyAgYXNf
Zm5fZXJyb3IgJD8gImNvdWxkIG5vdCBzZXR1cCBjb25maWcgaGVhZGVycyBtYWNoaW5lcnkiICIk
TElORU5PIiA1CitmaSAjIHRlc3QgLW4gIiRDT05GSUdfSEVBREVSUyIKKworCitldmFsIHNldCBY
ICIgIDpGICRDT05GSUdfRklMRVMgIDpIICRDT05GSUdfSEVBREVSUyAgICAiCitzaGlmdAorZm9y
IGFjX3RhZworZG8KKyAgY2FzZSAkYWNfdGFnIGluCisgIDpbRkhMQ10pIGFjX21vZGU9JGFjX3Rh
ZzsgY29udGludWU7OworICBlc2FjCisgIGNhc2UgJGFjX21vZGUkYWNfdGFnIGluCisgIDpbRkhM
XSo6Kik7OworICA6TCogfCA6Qyo6KikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdGFnIFxgJGFj
X3RhZyciICIkTElORU5PIiA1OzsKKyAgOltGSF0tKSBhY190YWc9LTotOzsKKyAgOltGSF0qKSBh
Y190YWc9JGFjX3RhZzokYWNfdGFnLmluOzsKKyAgZXNhYworICBhY19zYXZlX0lGUz0kSUZTCisg
IElGUz06CisgIHNldCB4ICRhY190YWcKKyAgSUZTPSRhY19zYXZlX0lGUworICBzaGlmdAorICBh
Y19maWxlPSQxCisgIHNoaWZ0CisKKyAgY2FzZSAkYWNfbW9kZSBpbgorICA6TCkgYWNfc291cmNl
PSQxOzsKKyAgOltGSF0pCisgICAgYWNfZmlsZV9pbnB1dHM9CisgICAgZm9yIGFjX2YKKyAgICBk
bworICAgICAgY2FzZSAkYWNfZiBpbgorICAgICAgLSkgYWNfZj0iJGFjX3RtcC9zdGRpbiI7Owor
ICAgICAgKikgIyBMb29rIGZvciB0aGUgZmlsZSBmaXJzdCBpbiB0aGUgYnVpbGQgdHJlZSwgdGhl
biBpbiB0aGUgc291cmNlIHRyZWUKKwkgIyAoaWYgdGhlIHBhdGggaXMgbm90IGFic29sdXRlKS4g
IFRoZSBhYnNvbHV0ZSBwYXRoIGNhbm5vdCBiZSBET1Mtc3R5bGUsCisJICMgYmVjYXVzZSAkYWNf
ZiBjYW5ub3QgY29udGFpbiBgOicuCisJIHRlc3QgLWYgIiRhY19mIiB8fAorCSAgIGNhc2UgJGFj
X2YgaW4KKwkgICBbXFwvJF0qKSBmYWxzZTs7CisJICAgKikgdGVzdCAtZiAiJHNyY2Rpci8kYWNf
ZiIgJiYgYWNfZj0iJHNyY2Rpci8kYWNfZiI7OworCSAgIGVzYWMgfHwKKwkgICBhc19mbl9lcnJv
ciAxICJjYW5ub3QgZmluZCBpbnB1dCBmaWxlOiBcYCRhY19mJyIgIiRMSU5FTk8iIDU7OworICAg
ICAgZXNhYworICAgICAgY2FzZSAkYWNfZiBpbiAqXCcqKSBhY19mPWAkYXNfZWNobyAiJGFjX2Yi
IHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgZXNhYworICAgICAgYXNfZm5fYXBwZW5kIGFj
X2ZpbGVfaW5wdXRzICIgJyRhY19mJyIKKyAgICBkb25lCisKKyAgICAjIExldCdzIHN0aWxsIHBy
ZXRlbmQgaXQgaXMgYGNvbmZpZ3VyZScgd2hpY2ggaW5zdGFudGlhdGVzIChpLmUuLCBkb24ndAor
ICAgICMgdXNlICRhc19tZSksIHBlb3BsZSB3b3VsZCBiZSBzdXJwcmlzZWQgdG8gcmVhZDoKKyAg
ICAjICAgIC8qIGNvbmZpZy5oLiAgR2VuZXJhdGVkIGJ5IGNvbmZpZy5zdGF0dXMuICAqLworICAg
IGNvbmZpZ3VyZV9pbnB1dD0nR2VuZXJhdGVkIGZyb20gJ2AKKwkgICRhc19lY2hvICIkKiIgfCBz
ZWQgJ3N8XlteOl0qL3x8O3N8OlteOl0qL3wsIHxnJworCWAnIGJ5IGNvbmZpZ3VyZS4nCisgICAg
aWYgdGVzdCB4IiRhY19maWxlIiAhPSB4LTsgdGhlbgorICAgICAgY29uZmlndXJlX2lucHV0PSIk
YWNfZmlsZS4gICRjb25maWd1cmVfaW5wdXQiCisgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNyZWF0aW5nICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IGNyZWF0aW5nICRhY19maWxlIiA+JjY7fQorICAgIGZpCisgICAgIyBOZXV0cmFsaXplIHNw
ZWNpYWwgY2hhcmFjdGVycyBpbnRlcnByZXRlZCBieSBzZWQgaW4gcmVwbGFjZW1lbnQgc3RyaW5n
cy4KKyAgICBjYXNlICRjb25maWd1cmVfaW5wdXQgaW4gIygKKyAgICAqXCYqIHwgKlx8KiB8ICpc
XCogKQorICAgICAgIGFjX3NlZF9jb25mX2lucHV0PWAkYXNfZWNobyAiJGNvbmZpZ3VyZV9pbnB1
dCIgfAorICAgICAgIHNlZCAncy9bXFxcXCZ8XS9cXFxcJi9nJ2A7OyAjKAorICAgICopIGFjX3Nl
ZF9jb25mX2lucHV0PSRjb25maWd1cmVfaW5wdXQ7OworICAgIGVzYWMKKworICAgIGNhc2UgJGFj
X3RhZyBpbgorICAgICo6LToqIHwgKjotKSBjYXQgPiIkYWNfdG1wL3N0ZGluIiBcCisgICAgICB8
fCBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUg
OzsKKyAgICBlc2FjCisgICAgOzsKKyAgZXNhYworCisgIGFjX2Rpcj1gJGFzX2Rpcm5hbWUgLS0g
IiRhY19maWxlIiB8fAorJGFzX2V4cHIgWCIkYWNfZmlsZSIgOiAnWFwoLipbXi9dXCkvLypbXi9d
W14vXSovKiQnIFx8IFwKKwkgWCIkYWNfZmlsZSIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIk
YWNfZmlsZSIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkYWNfZmlsZSIgOiAnWFwoL1wpJyBcfCAu
IDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhY19maWxlIiB8CisgICAgc2VkICcvXlhcKC4q
W14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkg
IC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwo
XC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJ
ICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgYXNfZGlyPSIkYWNf
ZGlyIjsgYXNfZm5fbWtkaXJfcAorICBhY19idWlsZGRpcj0uCisKK2Nhc2UgIiRhY19kaXIiIGlu
CisuKSBhY19kaXJfc3VmZml4PSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3By
ZWZpeD0gOzsKKyopCisgIGFjX2Rpcl9zdWZmaXg9L2AkYXNfZWNobyAiJGFjX2RpciIgfCBzZWQg
J3N8XlwuW1xcL118fCdgCisgICMgQSAiLi4iIGZvciBlYWNoIGRpcmVjdG9yeSBpbiAkYWNfZGly
X3N1ZmZpeC4KKyAgYWNfdG9wX2J1aWxkZGlyX3N1Yj1gJGFzX2VjaG8gIiRhY19kaXJfc3VmZml4
IiB8IHNlZCAnc3wvW15cXC9dKnwvLi58ZztzfC98fCdgCisgIGNhc2UgJGFjX3RvcF9idWlsZGRp
cl9zdWIgaW4KKyAgIiIpIGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4
PSA7OworICAqKSAgYWNfdG9wX2J1aWxkX3ByZWZpeD0kYWNfdG9wX2J1aWxkZGlyX3N1Yi8gOzsK
KyAgZXNhYyA7OworZXNhYworYWNfYWJzX3RvcF9idWlsZGRpcj0kYWNfcHdkCithY19hYnNfYnVp
bGRkaXI9JGFjX3B3ZCRhY19kaXJfc3VmZml4CisjIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5
OgorYWNfdG9wX2J1aWxkZGlyPSRhY190b3BfYnVpbGRfcHJlZml4CisKK2Nhc2UgJHNyY2RpciBp
bgorICAuKSAgIyBXZSBhcmUgYnVpbGRpbmcgaW4gcGxhY2UuCisgICAgYWNfc3JjZGlyPS4KKyAg
ICBhY190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRkaXJfc3ViCisgICAgYWNfYWJzX3RvcF9zcmNk
aXI9JGFjX3B3ZCA7OworICBbXFwvXSogfCA/OltcXC9dKiApICAjIEFic29sdXRlIG5hbWUuCisg
ICAgYWNfc3JjZGlyPSRzcmNkaXIkYWNfZGlyX3N1ZmZpeDsKKyAgICBhY190b3Bfc3JjZGlyPSRz
cmNkaXIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0kc3JjZGlyIDs7CisgICopICMgUmVsYXRpdmUg
bmFtZS4KKyAgICBhY19zcmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyJGFjX2Rpcl9z
dWZmaXgKKyAgICBhY190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpcgorICAg
IGFjX2Fic190b3Bfc3JjZGlyPSRhY19wd2QvJHNyY2RpciA7OworZXNhYworYWNfYWJzX3NyY2Rp
cj0kYWNfYWJzX3RvcF9zcmNkaXIkYWNfZGlyX3N1ZmZpeAorCisKKyAgY2FzZSAkYWNfbW9kZSBp
bgorICA6RikKKyAgIworICAjIENPTkZJR19GSUxFCisgICMKKworICBjYXNlICRJTlNUQUxMIGlu
CisgIFtcXC8kXSogfCA/OltcXC9dKiApIGFjX0lOU1RBTEw9JElOU1RBTEwgOzsKKyAgKikgYWNf
SU5TVEFMTD0kYWNfdG9wX2J1aWxkX3ByZWZpeCRJTlNUQUxMIDs7CisgIGVzYWMKK19BQ0VPRgor
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIElm
IHRoZSB0ZW1wbGF0ZSBkb2VzIG5vdCBrbm93IGFib3V0IGRhdGFyb290ZGlyLCBleHBhbmQgaXQu
CisjIEZJWE1FOiBUaGlzIGhhY2sgc2hvdWxkIGJlIHJlbW92ZWQgYSBmZXcgeWVhcnMgYWZ0ZXIg
Mi42MC4KK2FjX2RhdGFyb290ZGlyX2hhY2s9OyBhY19kYXRhcm9vdGRpcl9zZWVuPQorYWNfc2Vk
X2RhdGFyb290PScKKy9kYXRhcm9vdGRpci8geworICBwCisgIHEKK30KKy9AZGF0YWRpckAvcAor
L0Bkb2NkaXJAL3AKKy9AaW5mb2RpckAvcAorL0Bsb2NhbGVkaXJAL3AKKy9AbWFuZGlyQC9wJwor
Y2FzZSBgZXZhbCAic2VkIC1uIFwiXCRhY19zZWRfZGF0YXJvb3RcIiAkYWNfZmlsZV9pbnB1dHMi
YCBpbgorKmRhdGFyb290ZGlyKikgYWNfZGF0YXJvb3RkaXJfc2Vlbj15ZXM7OworKkBkYXRhZGly
QCp8KkBkb2NkaXJAKnwqQGluZm9kaXJAKnwqQGxvY2FsZWRpckAqfCpAbWFuZGlyQCopCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJGFjX2ZpbGVf
aW5wdXRzIHNlZW1zIHRvIGlnbm9yZSB0aGUgLS1kYXRhcm9vdGRpciBzZXR0aW5nIiA+JjUKKyRh
c19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICRhY19maWxlX2lucHV0cyBzZWVtcyB0byBpZ25vcmUg
dGhlIC0tZGF0YXJvb3RkaXIgc2V0dGluZyIgPiYyO30KK19BQ0VPRgorY2F0ID4+JENPTkZJR19T
VEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGFjX2RhdGFyb290ZGlyX2hhY2s9
JworICBzJkBkYXRhZGlyQCYkZGF0YWRpciZnCisgIHMmQGRvY2RpckAmJGRvY2RpciZnCisgIHMm
QGluZm9kaXJAJiRpbmZvZGlyJmcKKyAgcyZAbG9jYWxlZGlyQCYkbG9jYWxlZGlyJmcKKyAgcyZA
bWFuZGlyQCYkbWFuZGlyJmcKKyAgcyZcXFwke2RhdGFyb290ZGlyfSYkZGF0YXJvb3RkaXImZycg
OzsKK2VzYWMKK19BQ0VPRgorCisjIE5ldXRyYWxpemUgVlBBVEggd2hlbiBgJHNyY2RpcicgPSBg
LicuCisjIFNoZWxsIGNvZGUgaW4gY29uZmlndXJlLmFjIG1pZ2h0IHNldCBleHRyYXN1Yi4KKyMg
RklYTUU6IGRvIHdlIHJlYWxseSB3YW50IHRvIG1haW50YWluIHRoaXMgZmVhdHVyZT8KK2NhdCA+
PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorYWNfc2VkX2V4dHJh
PSIkYWNfdnBzdWIKKyRleHRyYXN1YgorX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxf
QUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCis6dAorL0BbYS16QS1aX11bYS16QS1aXzAtOV0qQC8h
Ygorc3xAY29uZmlndXJlX2lucHV0QHwkYWNfc2VkX2NvbmZfaW5wdXR8O3QgdAorcyZAdG9wX2J1
aWxkZGlyQCYkYWNfdG9wX2J1aWxkZGlyX3N1YiY7dCB0CitzJkB0b3BfYnVpbGRfcHJlZml4QCYk
YWNfdG9wX2J1aWxkX3ByZWZpeCY7dCB0CitzJkBzcmNkaXJAJiRhY19zcmNkaXImO3QgdAorcyZA
YWJzX3NyY2RpckAmJGFjX2Fic19zcmNkaXImO3QgdAorcyZAdG9wX3NyY2RpckAmJGFjX3RvcF9z
cmNkaXImO3QgdAorcyZAYWJzX3RvcF9zcmNkaXJAJiRhY19hYnNfdG9wX3NyY2RpciY7dCB0Citz
JkBidWlsZGRpckAmJGFjX2J1aWxkZGlyJjt0IHQKK3MmQGFic19idWlsZGRpckAmJGFjX2Fic19i
dWlsZGRpciY7dCB0CitzJkBhYnNfdG9wX2J1aWxkZGlyQCYkYWNfYWJzX3RvcF9idWlsZGRpciY7
dCB0CitzJkBJTlNUQUxMQCYkYWNfSU5TVEFMTCY7dCB0CiskYWNfZGF0YXJvb3RkaXJfaGFjawor
IgorZXZhbCBzZWQgXCJcJGFjX3NlZF9leHRyYVwiICIkYWNfZmlsZV9pbnB1dHMiIHwgJEFXSyAt
ZiAiJGFjX3RtcC9zdWJzLmF3ayIgXAorICA+JGFjX3RtcC9vdXQgfHwgYXNfZm5fZXJyb3IgJD8g
ImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisKK3Rlc3QgLXogIiRhY19k
YXRhcm9vdGRpcl9oYWNrJGFjX2RhdGFyb290ZGlyX3NlZW4iICYmCisgIHsgYWNfb3V0PWBzZWQg
LW4gJy9cJHtkYXRhcm9vdGRpcn0vcCcgIiRhY190bXAvb3V0ImA7IHRlc3QgLW4gIiRhY19vdXQi
OyB9ICYmCisgIHsgYWNfb3V0PWBzZWQgLW4gJy9eWwkgXSpkYXRhcm9vdGRpclsJIF0qOio9L3An
IFwKKyAgICAgICIkYWNfdG1wL291dCJgOyB0ZXN0IC16ICIkYWNfb3V0IjsgfSAmJgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICRhY19maWxlIGNv
bnRhaW5zIGEgcmVmZXJlbmNlIHRvIHRoZSB2YXJpYWJsZSBcYGRhdGFyb290ZGlyJword2hpY2gg
c2VlbXMgdG8gYmUgdW5kZWZpbmVkLiAgUGxlYXNlIG1ha2Ugc3VyZSBpdCBpcyBkZWZpbmVkIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICRhY19maWxlIGNvbnRhaW5zIGEgcmVmZXJl
bmNlIHRvIHRoZSB2YXJpYWJsZSBcYGRhdGFyb290ZGlyJword2hpY2ggc2VlbXMgdG8gYmUgdW5k
ZWZpbmVkLiAgUGxlYXNlIG1ha2Ugc3VyZSBpdCBpcyBkZWZpbmVkIiA+JjI7fQorCisgIHJtIC1m
ICIkYWNfdG1wL3N0ZGluIgorICBjYXNlICRhY19maWxlIGluCisgIC0pIGNhdCAiJGFjX3RtcC9v
dXQiICYmIHJtIC1mICIkYWNfdG1wL291dCI7OworICAqKSBybSAtZiAiJGFjX2ZpbGUiICYmIG12
ICIkYWNfdG1wL291dCIgIiRhY19maWxlIjs7CisgIGVzYWMgXAorICB8fCBhc19mbl9lcnJvciAk
PyAiY291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUKKyA7OworICA6SCkKKyAg
IworICAjIENPTkZJR19IRUFERVIKKyAgIworICBpZiB0ZXN0IHgiJGFjX2ZpbGUiICE9IHgtOyB0
aGVuCisgICAgeworICAgICAgJGFzX2VjaG8gIi8qICRjb25maWd1cmVfaW5wdXQgICovIiBcCisg
ICAgICAmJiBldmFsICckQVdLIC1mICIkYWNfdG1wL2RlZmluZXMuYXdrIicgIiRhY19maWxlX2lu
cHV0cyIKKyAgICB9ID4iJGFjX3RtcC9jb25maWcuaCIgXAorICAgICAgfHwgYXNfZm5fZXJyb3Ig
JD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgICAgaWYgZGlmZiAi
JGFjX2ZpbGUiICIkYWNfdG1wL2NvbmZpZy5oIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX2ZpbGUgaXMgdW5j
aGFuZ2VkIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6ICRhY19maWxlIGlzIHVuY2hhbmdlZCIgPiY2
O30KKyAgICBlbHNlCisgICAgICBybSAtZiAiJGFjX2ZpbGUiCisgICAgICBtdiAiJGFjX3RtcC9j
b25maWcuaCIgIiRhY19maWxlIiBcCisJfHwgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBjcmVh
dGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgICAgZmkKKyAgZWxzZQorICAgICRhc19lY2hvICIv
KiAkY29uZmlndXJlX2lucHV0ICAqLyIgXAorICAgICAgJiYgZXZhbCAnJEFXSyAtZiAiJGFjX3Rt
cC9kZWZpbmVzLmF3ayInICIkYWNfZmlsZV9pbnB1dHMiIFwKKyAgICAgIHx8IGFzX2ZuX2Vycm9y
ICQ/ICJjb3VsZCBub3QgY3JlYXRlIC0iICIkTElORU5PIiA1CisgIGZpCisgOzsKKworCisgIGVz
YWMKKworZG9uZSAjIGZvciBhY190YWcKKworCithc19mbl9leGl0IDAKK19BQ0VPRgorYWNfY2xl
YW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKKwordGVzdCAkYWNfd3JpdGVfZmFpbCA9IDAg
fHwKKyAgYXNfZm5fZXJyb3IgJD8gIndyaXRlIGZhaWx1cmUgY3JlYXRpbmcgJENPTkZJR19TVEFU
VVMiICIkTElORU5PIiA1CisKKworIyBjb25maWd1cmUgaXMgd3JpdGluZyB0byBjb25maWcubG9n
LCBhbmQgdGhlbiBjYWxscyBjb25maWcuc3RhdHVzLgorIyBjb25maWcuc3RhdHVzIGRvZXMgaXRz
IG93biByZWRpcmVjdGlvbiwgYXBwZW5kaW5nIHRvIGNvbmZpZy5sb2cuCisjIFVuZm9ydHVuYXRl
bHksIG9uIERPUyB0aGlzIGZhaWxzLCBhcyBjb25maWcubG9nIGlzIHN0aWxsIGtlcHQgb3Blbgor
IyBieSBjb25maWd1cmUsIHNvIGNvbmZpZy5zdGF0dXMgd29uJ3QgYmUgYWJsZSB0byB3cml0ZSB0
byBpdDsgaXRzCisjIG91dHB1dCBpcyBzaW1wbHkgZGlzY2FyZGVkLiAgU28gd2UgZXhlYyB0aGUg
RkQgdG8gL2Rldi9udWxsLAorIyBlZmZlY3RpdmVseSBjbG9zaW5nIGNvbmZpZy5sb2csIHNvIGl0
IGNhbiBiZSBwcm9wZXJseSAocmUpb3BlbmVkIGFuZAorIyBhcHBlbmRlZCB0byBieSBjb25maWcu
c3RhdHVzLiAgV2hlbiBjb21pbmcgYmFjayB0byBjb25maWd1cmUsIHdlCisjIG5lZWQgdG8gbWFr
ZSB0aGUgRkQgYXZhaWxhYmxlIGFnYWluLgoraWYgdGVzdCAiJG5vX2NyZWF0ZSIgIT0geWVzOyB0
aGVuCisgIGFjX2NzX3N1Y2Nlc3M9OgorICBhY19jb25maWdfc3RhdHVzX2FyZ3M9CisgIHRlc3Qg
IiRzaWxlbnQiID0geWVzICYmCisgICAgYWNfY29uZmlnX3N0YXR1c19hcmdzPSIkYWNfY29uZmln
X3N0YXR1c19hcmdzIC0tcXVpZXQiCisgIGV4ZWMgNT4vZGV2L251bGwKKyAgJFNIRUxMICRDT05G
SUdfU1RBVFVTICRhY19jb25maWdfc3RhdHVzX2FyZ3MgfHwgYWNfY3Nfc3VjY2Vzcz1mYWxzZQor
ICBleGVjIDU+PmNvbmZpZy5sb2cKKyAgIyBVc2UgfHwsIG5vdCAmJiwgdG8gYXZvaWQgZXhpdGlu
ZyBmcm9tIHRoZSBpZiB3aXRoICQ/ID0gMSwgd2hpY2gKKyAgIyB3b3VsZCBtYWtlIGNvbmZpZ3Vy
ZSBmYWlsIGlmIHRoaXMgaXMgdGhlIGxhc3QgaW5zdHJ1Y3Rpb24uCisgICRhY19jc19zdWNjZXNz
IHx8IGFzX2ZuX2V4aXQgMQorZmkKK2lmIHRlc3QgLW4gIiRhY191bnJlY29nbml6ZWRfb3B0cyIg
JiYgdGVzdCAiJGVuYWJsZV9vcHRpb25fY2hlY2tpbmciICE9IG5vOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdW5yZWNvZ25pemVkIG9w
dGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJO
SU5HOiB1bnJlY29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXplZF9vcHRzIiA+JjI7fQor
ZmkKKwpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY29uZmlndXJl
LmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL2NvbmZpZ3VyZS5hYwlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTAsMCAr
MSwxOTIgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBhdXRvY29uZiB0byBw
cm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsyLjY3XSkKK0FDX0lOSVQo
W1hlbiBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVyc2lvbi5zaCAuLi94ZW4vTWFrZWZp
bGVdKSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb21dKQorQUNfQ09ORklHX1NS
Q0RJUihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklMRVMoWy4uL2NvbmZpZy9Ub29scy5t
a10pCitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQorQUNfUFJFRklYX0RFRkFVTFQoWy91
c3JdKQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENoZWNrIGlmIENGTEFHUywgTERGTEFH
UywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCisKK0FT
X0lGKFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElCUyRDUFBGTEFHUyRDUFAiXSwgWwor
ICAgIEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQ
RkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMs
IFBSRVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3
aGVuIHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVNX0VYVEVOU0lPTlMKK0FDX0NBTk9O
SUNBTF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200X2luY2x1ZGUoW200L2VuYWJsZV9m
ZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVfZmVhdHVyZS5tNF0pCittNF9pbmNs
dWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX3htbC5tNF0p
CittNF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0pCittNF9pbmNsdWRlKFttNC9weXRo
b25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5tNF0pCittNF9pbmNsdWRlKFttNC9v
Y2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xpYi5tNF0pCittNF9pbmNsdWRlKFtt
NC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVkZShbbTQvdXVpZC5tNF0pCisKKyMg
RW5hYmxlL2Rpc2FibGUgb3B0aW9ucworQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt4c21dLAor
ICAgIFtFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spXSkKK0FY
X0FSR19FTkFCTEVfQU5EX0VYUE9SVChbZ2l0aHR0cF0sIFtEb3dubG9hZCBHSVQgcmVwb3NpdG9y
aWVzIHZpYSBIVFRQXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW21vbml0b3JzXSwKKyAg
ICBbRGlzYWJsZSB4ZW5zdGF0IGFuZCB4ZW50b3AgbW9uaXRvcmluZyB0b29sc10pCitBWF9BUkdf
RU5BQkxFX0FORF9FWFBPUlQoW3Z0cG1dLCBbRW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9y
bSBNb2R1bGVdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt4YXBpXSwgW0VuYWJsZSBYZW4g
QVBJIEJpbmRpbmdzXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW3B5dGhvbnRvb2xzXSwg
W0Rpc2FibGUgUHl0aG9uIHRvb2xzXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW29jYW1s
dG9vbHNdLCBbRGlzYWJsZSBPY2FtbCB0b29sc10pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQo
W21pbml0ZXJtXSwgW0VuYWJsZSBtaW5pdGVybV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQo
W2xvbW91bnRdLCBbRW5hYmxlIGxvbW91bnRdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChb
ZGVidWddLCBbRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzXSkKKworQUNfQVJH
X1ZBUihbUFJFUEVORF9JTkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRv
IHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtQUkVQRU5EX0xJ
Ql0sCisgICAgW0xpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAo
d2l0aG91dCAtTCldKQorQUNfQVJHX1ZBUihbQVBQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBv
ZiBpbmNsdWRlIGZvbGRlcnMgdG8gYXBwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQorQUNf
QVJHX1ZBUihbQVBQRU5EX0xJQl0sCisgICAgW0xpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFw
cGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKV0pCisKK0FYX1NFVF9GTEFHUworCitBQ19BUkdf
VkFSKFtQWVRIT05dLCBbUGF0aCB0byB0aGUgUHl0aG9uIHBhcnNlcl0pCitBQ19BUkdfVkFSKFtQ
RVJMXSwgW1BhdGggdG8gUGVybCBwYXJzZXJdKQorQUNfQVJHX1ZBUihbQlJDVExdLCBbUGF0aCB0
byBicmN0bCB0b29sXSkKK0FDX0FSR19WQVIoW0lQXSwgW1BhdGggdG8gaXAgdG9vbF0pCitBQ19B
UkdfVkFSKFtCSVNPTl0sIFtQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQorQUNfQVJH
X1ZBUihbRkxFWF0sIFtQYXRoIHRvIEZsZXggbGV4aWNhbCBhbmFseXNlciBnZW5lcmF0b3JdKQor
QUNfQVJHX1ZBUihbQ1VSTF0sIFtQYXRoIHRvIGN1cmwtY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZB
UihbWE1MXSwgW1BhdGggdG8geG1sMi1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtCQVNIXSwg
W1BhdGggdG8gYmFzaCBzaGVsbF0pCitBQ19BUkdfVkFSKFtYR0VUVEVYVF0sIFtQYXRoIHRvIHhn
ZXR0dGV4dCB0b29sXSkKKworIyBDaGVja3MgZm9yIHByb2dyYW1zLgorQUNfUFJPR19TRUQKK0FD
X1BST0dfQ0MKK0FDX1BST0dfTE5fUworQUNfUFJPR19NQUtFX1NFVAorQUNfUFJPR19JTlNUQUxM
CitBWF9QQVRIX1BST0dfT1JfRkFJTChbUEVSTF0sIFtwZXJsXSkKK0FYX1BBVEhfUFJPR19PUl9G
QUlMKFtCUkNUTF0sIFticmN0bF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbSVBdLCBbaXBdKQor
QVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JJU09OXSwgW2Jpc29uXSkKK0FYX1BBVEhfUFJPR19PUl9G
QUlMKFtGTEVYXSwgW2ZsZXhdKQorQVNfSUYoW3Rlc3QgIngkeGFwaSIgPSAieHkiXSwgWworICAg
IEFYX1BBVEhfUFJPR19PUl9GQUlMKFtDVVJMXSwgW2N1cmwtY29uZmlnXSkKKyAgICBBWF9QQVRI
X1BST0dfT1JfRkFJTChbWE1MXSwgW3htbDItY29uZmlnXSkKK10pCitBU19JRihbdGVzdCAieCRv
Y2FtbHRvb2xzIiA9ICJ4eSJdLCBbCisgICAgQUNfUFJPR19PQ0FNTAorICAgIEFTX0lGKFt0ZXN0
ICJ4JE9DQU1MQyIgPSAieG5vIl0sIFsKKyAgICAgICAgQVNfSUYoW3Rlc3QgIngkZW5hYmxlX29j
YW1sdG9vbHMiID0gInh5ZXMiXSwgWworICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFtPY2FtbCB0
b29scyBlbmFibGVkLCBidXQgdW5hYmxlIHRvIGZpbmQgT2NhbWxdKV0pCisgICAgICAgIG9jYW1s
dG9vbHM9Im4iCisgICAgXSkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQkFTSF0sIFtiYXNo
XSkKK0FTX0lGKFt0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSJdLCBbCisgICAgQVNfSUYoW2Vj
aG8gIiRQWVRIT04iIHwgZ3JlcCAtcSAiXi8iXSwgWworICAgICAgICBQWVRIT05QQVRIPSRQWVRI
T04KKyAgICAgICAgUFlUSE9OPWBiYXNlbmFtZSAkUFlUSE9OUEFUSGAKKyAgICBdLFt0ZXN0IC16
ICIkUFlUSE9OIl0sIFtQWVRIT049InB5dGhvbiJdLAorICAgIFtBQ19NU0dfRVJST1IoW1BZVEhP
TiBzcGVjaWZpZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1dGUgcGF0aF0pXSkKKyAgICBBWF9QQVRI
X1BST0dfT1JfRkFJTChbUFlUSE9OUEFUSF0sIFskUFlUSE9OXSkKKyAgICBBWF9DSEVDS19QWVRI
T05fVkVSU0lPTihbMl0sIFszXSkKKyAgICBBWF9DSEVDS19QWVRIT05fWE1MKCkKKyAgICBBWF9D
SEVDS19QWVRIT05fREVWRUwoKQorXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtYR0VUVEVYVF0s
IFt4Z2V0dGV4dF0pCitBWF9DSEVDS19VREVWKFs1OV0pCitBWF9DSEVDS19VVUlECitQS0dfQ0hF
Q0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RF
RkFVTFRfTElCCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10s
IFtpb19zZXR1cF0sIFtzeXN0ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJT
VChzeXN0ZW1fYWlvKQorQUNfQ0hFQ0tfTElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0df
RVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZz
XSwgW2V4dDJmc19vcGVuMl0sIFtsaWJleHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNf
U1VCU1QobGliZXh0MmZzKQorQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1
ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2Ny
eXB0KQorQUNfQ0hFQ0tfTElCKFtwdGhyZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAg
IFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19M
SUIoW3J0XSwgW2Nsb2NrX2dldHRpbWVdKQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xl
YXJdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQor
QUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9S
KFtDb3VsZCBub3QgZmluZCB5YWpsXSldKQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5
XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19M
SUIoW2ljb252XSwgW2xpYmljb252X29wZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJu
Il0pCitBQ19TVUJTVChsaWJpY29udikKKworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5
YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNrKQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FD
X0ZVTkNfQUxMT0NBCitBQ19DSEVDS19IRUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEv
aW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAor
ICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0
ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBz
eXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lz
L3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAor
ICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAg
ICAgICAgIF0pCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBp
bGVyIGNoYXJhY3RlcmlzdGljcy4KK0FDX0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitB
Q19DX0lOTElORQorQUNfVFlQRV9JTlQxNl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5U
NjRfVAorQUNfVFlQRV9JTlQ4X1QKK0FDX1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19U
WVBFX1BJRF9UCitBQ19DX1JFU1RSSUNUCitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9U
CitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9T
VF9CTE9DS1MKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQ
RV9VSU5UMTZfVAorQUNfVFlQRV9VSU5UMzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9V
SU5UOF9UCitBQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJh
cnkgZnVuY3Rpb25zLgorQUNfRlVOQ19FUlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZV
TkNfRlNFRUtPCitBQ19GVU5DX0xTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFE
RVJfTUFKT1IKK0FDX0ZVTkNfTUFMTE9DCitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitB
Q19GVU5DX1JFQUxMT0MKK0FDX0ZVTkNfU1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNL
X0ZVTkNTKFsgXAorICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0
aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdl
dGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAg
ICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBt
ZW1zZXQgbWtkaXIgXAorICAgICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVh
bHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2Nr
ZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisg
ICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRv
dWwgc3RydG91bGwgdHpzZXQgXAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAg
ICAgICBdKQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5
MTQgdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUKLS0tIGEvdG9vbHMvZGVidWdnZXIv
Z2Ric3gveGcvTWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiL3Rv
b2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiAr
MDEwMApAQCAtMjEsNyArMjEsNiBAQCB4Z19hbGwuYTogJChYR19PQkpTKSBNYWtlZmlsZSAkKFhH
X0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMgLW8gJEAgJF4KIAogeGVuLWhlYWRlcnM6Ci0JJChNQUtF
KSAtQyAuLi8uLi8uLi9jaGVjayAKIAkkKE1BS0UpIC1DIC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4
Z19tYWluLm86IHhnX21haW4uYyBNYWtlZmlsZSAkKFhHX0hEUlMpCmRpZmYgLXIgODcyMThiZDM2
N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9pbnN0YWxsLnNoCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2luc3RhbGwuc2gJTW9uIEZlYiAy
MCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMSBAQAorLi4vaW5zdGFsbC5zaApcIE5v
IG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhh
OTE0IHRvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9NYWtl
ZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGliZnNpbWFn
ZS9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTMsNyArMywxMSBA
QCBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCiAKIFNVQkRJUlMteSA9IGNvbW1v
biB1ZnMgcmVpc2VyZnMgaXNvOTY2MCBmYXQgemZzCiBTVUJESVJTLSQoQ09ORklHX1g4NikgKz0g
eGZzCi1TVUJESVJTLXkgKz0gJChzaGVsbCBlbnYgQ0M9IiQoQ0MpIiAuL2NoZWNrLWxpYmV4dDJm
cykKK2lmZXEgKCQoQ09ORklHX0VYVDJGUyksIHkpCisgICAgU1VCRElSUy15ICs9IGV4dDJmcy1s
aWIKK2Vsc2UKKyAgICBTVUJESVJTLXkgKz0gZXh0MmZzCitlbmRpZgogCiAuUEhPTlk6IGFsbCBj
bGVhbiBpbnN0YWxsCiBhbGwgY2xlYW4gaW5zdGFsbDogJTogc3ViZGlycy0lCmRpZmYgLXIgODcy
MThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9saWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJm
cwotLS0gYS90b29scy9saWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJmcwlGcmkgRmViIDE3IDEyOjI0
OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMjEgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+ZXh0Mi10ZXN0LmMgPDxFT0YK
LSNpbmNsdWRlIDxleHQyZnMvZXh0MmZzLmg+Ci0KLWludCBtYWluKCkKLXsKLQlleHQyZnNfb3Bl
bjI7Ci19Ci1FT0YKLQotJHtDQy1nY2N9IC1vIGV4dDItdGVzdCBleHQyLXRlc3QuYyAtbGV4dDJm
cyA+L2Rldi9udWxsIDI+JjEKLWlmIFsgJD8gPSAwIF07IHRoZW4KLQllY2hvIGV4dDJmcy1saWIK
LWVsc2UKLQllY2hvIGV4dDJmcwotZmkKLQotcm0gLWYgZXh0Mi10ZXN0IGV4dDItdGVzdC5jCi0K
LWV4aXQgMApkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbGlieGVu
L01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4
IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGVuL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MjA6
MjkgMjAxMiArMDEwMApAQCAtMjIsMTIgKzIyLDEyIEBAIE1BSk9SID0gMS4wCiBNSU5PUiA9IDAK
IAogQ0ZMQUdTICs9IC1JaW5jbHVkZSAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAk
KHNoZWxsIHhtbDItY29uZmlnIC0tY2ZsYWdzKSBcCi0gICAgICAgICAgJChzaGVsbCBjdXJsLWNv
bmZpZyAtLWNmbGFncykgXAorICAgICAgICAgICQoc2hlbGwgJChYTUwyX0NPTkZJRykgLS1jZmxh
Z3MpIFwKKyAgICAgICAgICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tY2ZsYWdzKSBcCiAgICAg
ICAgICAgLWZQSUMKIAotTERGTEFHUyArPSAkKHNoZWxsIHhtbDItY29uZmlnIC0tbGlicykgXAot
ICAgICAgICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tbGlicykKK0xERkxBR1MgKz0gJChzaGVs
bCAkKFhNTDJfQ09ORklHKSAtLWxpYnMpIFwKKyAgICAgICAgICAgJChzaGVsbCAkKENVUkxfQ09O
RklHKSAtLWxpYnMpCiAKIExJQlhFTkFQSV9IRFJTID0gJCh3aWxkY2FyZCBpbmNsdWRlL3hlbi9h
cGkvKi5oKSBpbmNsdWRlL3hlbi9hcGkveGVuX2FsbC5oCiBMSUJYRU5BUElfT0JKUyA9ICQocGF0
c3Vic3QgJS5jLCAlLm8sICQod2lsZGNhcmQgc3JjLyouYykpCmRpZmYgLXIgODcyMThiZDM2N2Jl
IC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9saWJ4bC9NYWtlZmlsZQotLS0gYS90b29scy9saWJ4bC9N
YWtlZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwv
TWFrZWZpbGUJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0xOSwxMCArMTksNiBA
QCBpZmVxICgkKENPTkZJR19MaW51eCkseSkKIExJQlVVSURfTElCUyArPSAtbHV1aWQKIGVuZGlm
CiAKLWlmZXEgKCQoQ09ORklHX1lBSkxfVkVSU0lPTikseSkKLUNGTEFHUyArPSAtREhBVkVfWUFK
TF9WRVJTSU9OCi1lbmRpZgotCiBMSUJYTF9MSUJTID0KIExJQlhMX0xJQlMgPSAkKExETElCU19s
aWJ4ZW5jdHJsKSAkKExETElCU19saWJ4ZW5ndWVzdCkgJChMRExJQlNfbGlieGVuc3RvcmUpICQo
TERMSUJTX2xpYmJsa3RhcGN0bCkgJChVVElMX0xJQlMpICQoTElCVVVJRF9MSUJTKQogCkBAIC01
Niw3ICs1Miw3IEBAIExJQlhMX09CSlMgPSBmbGV4YXJyYXkubyBsaWJ4bC5vIGxpYnhsX2MKIAkJ
CWxpYnhsX3FtcC5vIGxpYnhsX2V2ZW50Lm8gJChMSUJYTF9PQkpTLXkpCiBMSUJYTF9PQkpTICs9
IF9saWJ4bF90eXBlcy5vIGxpYnhsX2ZsYXNrLm8gX2xpYnhsX3R5cGVzX2ludGVybmFsLm8KIAot
JChMSUJYTF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICQoQ0ZMQUdTX2xp
Ynhlbmd1ZXN0KSAkKENGTEFHU19saWJ4ZW5zdG9yZSkgJChDRkxBR1NfbGliYmxrdGFwY3RsKQor
JChMSUJYTF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICQoQ0ZMQUdTX2xp
Ynhlbmd1ZXN0KSAkKENGTEFHU19saWJ4ZW5zdG9yZSkgJChDRkxBR1NfbGliYmxrdGFwY3RsKSAt
aW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9jb25maWcuaAogCiBBVVRPSU5DUz0gbGlieGx1X2Nm
Z195LmggbGlieGx1X2NmZ19sLmggX2xpYnhsX2xpc3QuaAogQVVUT1NSQ1M9IGxpYnhsdV9jZmdf
eS5jIGxpYnhsdV9jZmdfbC5jCkBAIC02OSw2ICs2NSw3IEBAIENMSUVOVFMgPSB4bCB0ZXN0aWRs
CiBYTF9PQkpTID0geGwubyB4bF9jbWRpbXBsLm8geGxfY21kdGFibGUubyB4bF9zeHAubwogJChY
TF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICMgRm9yIHhlbnRvb2xsb2cu
aAogJChYTF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmxpZ2h0KQorJChYTF9PQkpT
KTogQ0ZMQUdTICs9IC1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL2NvbmZpZy5oICMgbGlieGxf
anNvbi5oIG5lZWRzIGl0LgogCiB0ZXN0aWRsLm86IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5j
dHJsKSAkKENGTEFHU19saWJ4ZW5saWdodCkKIHRlc3RpZGwuYzogbGlieGxfdHlwZXMuaWRsIGdl
bnRlc3QucHkgbGlieGwuaCAkKEFVVE9JTkNTKQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2Rm
OWVkOGE5MTQgdG9vbHMvbGlieGwvbGlieGxfanNvbi5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhs
X2pzb24uaAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwv
bGlieGxfanNvbi5oCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMTgsNyArMTgs
NyBAQAogI2luY2x1ZGUgPHlhamwveWFqbF9nZW4uaD4KICNpbmNsdWRlIDx5YWpsL3lhamxfcGFy
c2UuaD4KIAotI2lmZGVmIEhBVkVfWUFKTF9WRVJTSU9OCisjaWZkZWYgSEFWRV9ZQUpMX1lBSkxf
VkVSU0lPTl9ICiAjICBpbmNsdWRlIDx5YWpsL3lhamxfdmVyc2lvbi5oPgogI2VuZGlmCiAKZGlm
ZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2xpYnhsL2xpYnhsdV9jZmdf
eS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9jZmdfeS5jCUZyaSBGZWIgMTcgMTI6MjQ6Mzgg
MjAxMiArMDAwMAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfY2ZnX3kuYwlNb24gRmViIDIwIDE4
OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTEsMjQgKzEsMjEgQEAKLS8qIEEgQmlzb24gcGFyc2VyLCBt
YWRlIGJ5IEdOVSBCaXNvbiAyLjMuICAqLworLyogQSBCaXNvbiBwYXJzZXIsIG1hZGUgYnkgR05V
IEJpc29uIDIuNS4gICovCiAKLS8qIFNrZWxldG9uIGltcGxlbWVudGF0aW9uIGZvciBCaXNvbidz
IFlhY2MtbGlrZSBwYXJzZXJzIGluIEMKLQotICAgQ29weXJpZ2h0IChDKSAxOTg0LCAxOTg5LCAx
OTkwLCAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2Ci0gICBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KLQotICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKy8qIEJpc29uIGltcGxl
bWVudGF0aW9uIGZvciBZYWNjLWxpa2UgcGFyc2VycyBpbiBDCisgICAKKyAgICAgIENvcHlyaWdo
dCAoQykgMTk4NCwgMTk4OS0xOTkwLCAyMDAwLTIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
LCBJbmMuCisgICAKKyAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOiB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CiAgICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQotICAgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0IHlvdXIgb3B0aW9u
KQotICAgYW55IGxhdGVyIHZlcnNpb24uCi0KKyAgIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24sIGVpdGhlciB2ZXJzaW9uIDMgb2YgdGhlIExpY2Vuc2UsIG9yCisgICAoYXQgeW91ciBvcHRp
b24pIGFueSBsYXRlciB2ZXJzaW9uLgorICAgCiAgICBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0
ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKICAgIGJ1dCBXSVRIT1VUIEFO
WSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiAgICBNRVJD
SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhl
CiAgICBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgotCisgICAK
ICAgIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlCi0gICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0
byB0aGUgRnJlZSBTb2Z0d2FyZQotICAgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3Ry
ZWV0LCBGaWZ0aCBGbG9vciwKLSAgIEJvc3RvbiwgTUEgMDIxMTAtMTMwMSwgVVNBLiAgKi8KKyAg
IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9y
Zy9saWNlbnNlcy8+LiAgKi8KIAogLyogQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiwgeW91IG1heSBj
cmVhdGUgYSBsYXJnZXIgd29yayB0aGF0IGNvbnRhaW5zCiAgICBwYXJ0IG9yIGFsbCBvZiB0aGUg
Qmlzb24gcGFyc2VyIHNrZWxldG9uIGFuZCBkaXN0cmlidXRlIHRoYXQgd29yawpAQCAtMjksNyAr
MjYsNyBAQAogICAgc3BlY2lhbCBleGNlcHRpb24sIHdoaWNoIHdpbGwgY2F1c2UgdGhlIHNrZWxl
dG9uIGFuZCB0aGUgcmVzdWx0aW5nCiAgICBCaXNvbiBvdXRwdXQgZmlsZXMgdG8gYmUgbGljZW5z
ZWQgdW5kZXIgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYwogICAgTGljZW5zZSB3aXRob3V0IHRoaXMg
c3BlY2lhbCBleGNlcHRpb24uCi0KKyAgIAogICAgVGhpcyBzcGVjaWFsIGV4Y2VwdGlvbiB3YXMg
YWRkZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiBpbgogICAgdmVyc2lvbiAyLjIg
b2YgQmlzb24uICAqLwogCkBAIC00Nyw3ICs0NCw3IEBACiAjZGVmaW5lIFlZQklTT04gMQogCiAv
KiBCaXNvbiB2ZXJzaW9uLiAgKi8KLSNkZWZpbmUgWVlCSVNPTl9WRVJTSU9OICIyLjMiCisjZGVm
aW5lIFlZQklTT05fVkVSU0lPTiAiMi41IgogCiAvKiBTa2VsZXRvbiBuYW1lLiAgKi8KICNkZWZp
bmUgWVlTS0VMRVRPTl9OQU1FICJ5YWNjLmMiCkBAIC01NSw0MSArNTIsMjggQEAKIC8qIFB1cmUg
cGFyc2Vycy4gICovCiAjZGVmaW5lIFlZUFVSRSAxCiAKKy8qIFB1c2ggcGFyc2Vycy4gICovCisj
ZGVmaW5lIFlZUFVTSCAwCisKKy8qIFB1bGwgcGFyc2Vycy4gICovCisjZGVmaW5lIFlZUFVMTCAx
CisKIC8qIFVzaW5nIGxvY2F0aW9ucy4gICovCiAjZGVmaW5lIFlZTFNQX05FRURFRCAxCiAKIC8q
IFN1YnN0aXR1dGUgdGhlIHZhcmlhYmxlIGFuZCBmdW5jdGlvbiBuYW1lcy4gICovCi0jZGVmaW5l
IHl5cGFyc2UgeGx1X19jZmdfeXlwYXJzZQotI2RlZmluZSB5eWxleCAgIHhsdV9fY2ZnX3l5bGV4
Ci0jZGVmaW5lIHl5ZXJyb3IgeGx1X19jZmdfeXllcnJvcgotI2RlZmluZSB5eWx2YWwgIHhsdV9f
Y2ZnX3l5bHZhbAotI2RlZmluZSB5eWNoYXIgIHhsdV9fY2ZnX3l5Y2hhcgotI2RlZmluZSB5eWRl
YnVnIHhsdV9fY2ZnX3l5ZGVidWcKLSNkZWZpbmUgeXluZXJycyB4bHVfX2NmZ195eW5lcnJzCi0j
ZGVmaW5lIHl5bGxvYyB4bHVfX2NmZ195eWxsb2MKLQotLyogVG9rZW5zLiAgKi8KLSNpZm5kZWYg
WVlUT0tFTlRZUEUKLSMgZGVmaW5lIFlZVE9LRU5UWVBFCi0gICAvKiBQdXQgdGhlIHRva2VucyBp
bnRvIHRoZSBzeW1ib2wgdGFibGUsIHNvIHRoYXQgR0RCIGFuZCBvdGhlciBkZWJ1Z2dlcnMKLSAg
ICAgIGtub3cgYWJvdXQgdGhlbS4gICovCi0gICBlbnVtIHl5dG9rZW50eXBlIHsKLSAgICAgSURF
TlQgPSAyNTgsCi0gICAgIFNUUklORyA9IDI1OSwKLSAgICAgTlVNQkVSID0gMjYwLAotICAgICBO
RVdMSU5FID0gMjYxCi0gICB9OwotI2VuZGlmCi0vKiBUb2tlbnMuICAqLwotI2RlZmluZSBJREVO
VCAyNTgKLSNkZWZpbmUgU1RSSU5HIDI1OQotI2RlZmluZSBOVU1CRVIgMjYwCi0jZGVmaW5lIE5F
V0xJTkUgMjYxCi0KLQotCisjZGVmaW5lIHl5cGFyc2UgICAgICAgICB4bHVfX2NmZ195eXBhcnNl
CisjZGVmaW5lIHl5bGV4ICAgICAgICAgICB4bHVfX2NmZ195eWxleAorI2RlZmluZSB5eWVycm9y
ICAgICAgICAgeGx1X19jZmdfeXllcnJvcgorI2RlZmluZSB5eWx2YWwgICAgICAgICAgeGx1X19j
ZmdfeXlsdmFsCisjZGVmaW5lIHl5Y2hhciAgICAgICAgICB4bHVfX2NmZ195eWNoYXIKKyNkZWZp
bmUgeXlkZWJ1ZyAgICAgICAgIHhsdV9fY2ZnX3l5ZGVidWcKKyNkZWZpbmUgeXluZXJycyAgICAg
ICAgIHhsdV9fY2ZnX3l5bmVycnMKKyNkZWZpbmUgeXlsbG9jICAgICAgICAgIHhsdV9fY2ZnX3l5
bGxvYwogCiAvKiBDb3B5IHRoZSBmaXJzdCBwYXJ0IG9mIHVzZXIgZGVjbGFyYXRpb25zLiAgKi8K
KworLyogTGluZSAyNjggb2YgeWFjYy5jICAqLwogI2xpbmUgMTkgImxpYnhsdV9jZmdfeS55Igog
CiAjZGVmaW5lIFlZTEVYX1BBUkFNIGN0eC0+c2Nhbm5lcgpAQCAtOTcsNiArODEsOSBAQAogI2lu
Y2x1ZGUgImxpYnhsdV9jZmdfbC5oIgogCiAKKy8qIExpbmUgMjY4IG9mIHlhY2MuYyAgKi8KKyNs
aW5lIDg2ICJsaWJ4bHVfY2ZnX3kuYyIKKwogLyogRW5hYmxpbmcgdHJhY2VzLiAgKi8KICNpZm5k
ZWYgWVlERUJVRwogIyBkZWZpbmUgWVlERUJVRyAwCkBAIC0xMTUsMTkgKzEwMiw0MCBAQAogIyBk
ZWZpbmUgWVlUT0tFTl9UQUJMRSAwCiAjZW5kaWYKIAorCisvKiBUb2tlbnMuICAqLworI2lmbmRl
ZiBZWVRPS0VOVFlQRQorIyBkZWZpbmUgWVlUT0tFTlRZUEUKKyAgIC8qIFB1dCB0aGUgdG9rZW5z
IGludG8gdGhlIHN5bWJvbCB0YWJsZSwgc28gdGhhdCBHREIgYW5kIG90aGVyIGRlYnVnZ2Vycwor
ICAgICAga25vdyBhYm91dCB0aGVtLiAgKi8KKyAgIGVudW0geXl0b2tlbnR5cGUgeworICAgICBJ
REVOVCA9IDI1OCwKKyAgICAgU1RSSU5HID0gMjU5LAorICAgICBOVU1CRVIgPSAyNjAsCisgICAg
IE5FV0xJTkUgPSAyNjEKKyAgIH07CisjZW5kaWYKKworCisKICNpZiAhIGRlZmluZWQgWVlTVFlQ
RSAmJiAhIGRlZmluZWQgWVlTVFlQRV9JU19ERUNMQVJFRAogdHlwZWRlZiB1bmlvbiBZWVNUWVBF
Cit7CisKKy8qIExpbmUgMjkzIG9mIHlhY2MuYyAgKi8KICNsaW5lIDI1ICJsaWJ4bHVfY2ZnX3ku
eSIKLXsKKwogICBjaGFyICpzdHJpbmc7CiAgIFhMVV9Db25maWdTZXR0aW5nICpzZXR0aW5nOwot
fQotLyogTGluZSAxODcgb2YgeWFjYy5jLiAgKi8KLSNsaW5lIDEyNyAibGlieGx1X2NmZ195LmMi
Ci0JWVlTVFlQRTsKKworCisKKy8qIExpbmUgMjkzIG9mIHlhY2MuYyAgKi8KKyNsaW5lIDEzNSAi
bGlieGx1X2NmZ195LmMiCit9IFlZU1RZUEU7CisjIGRlZmluZSBZWVNUWVBFX0lTX1RSSVZJQUwg
MQogIyBkZWZpbmUgeXlzdHlwZSBZWVNUWVBFIC8qIG9ic29sZXNjZW50OyB3aWxsIGJlIHdpdGhk
cmF3biAqLwogIyBkZWZpbmUgWVlTVFlQRV9JU19ERUNMQVJFRCAxCi0jIGRlZmluZSBZWVNUWVBF
X0lTX1RSSVZJQUwgMQogI2VuZGlmCiAKICNpZiAhIGRlZmluZWQgWVlMVFlQRSAmJiAhIGRlZmlu
ZWQgWVlMVFlQRV9JU19ERUNMQVJFRApAQCAtMTQ3LDggKzE1NSw4IEBAIHR5cGVkZWYgc3RydWN0
IFlZTFRZUEUKIC8qIENvcHkgdGhlIHNlY29uZCBwYXJ0IG9mIHVzZXIgZGVjbGFyYXRpb25zLiAg
Ki8KIAogCi0vKiBMaW5lIDIxNiBvZiB5YWNjLmMuICAqLwotI2xpbmUgMTUyICJsaWJ4bHVfY2Zn
X3kuYyIKKy8qIExpbmUgMzQzIG9mIHlhY2MuYyAgKi8KKyNsaW5lIDE2MCAibGlieGx1X2NmZ195
LmMiCiAKICNpZmRlZiBzaG9ydAogIyB1bmRlZiBzaG9ydApAQCAtMTk4LDcgKzIwNiw3IEBAIHR5
cGVkZWYgc2hvcnQgaW50IHl5dHlwZV9pbnQxNjsKICNkZWZpbmUgWVlTSVpFX01BWElNVU0gKChZ
WVNJWkVfVCkgLTEpCiAKICNpZm5kZWYgWVlfCi0jIGlmIFlZRU5BQkxFX05MUworIyBpZiBkZWZp
bmVkIFlZRU5BQkxFX05MUyAmJiBZWUVOQUJMRV9OTFMKICMgIGlmIEVOQUJMRV9OTFMKICMgICBp
bmNsdWRlIDxsaWJpbnRsLmg+IC8qIElORlJJTkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KICMg
ICBkZWZpbmUgWVlfKG1zZ2lkKSBkZ2V0dGV4dCAoImJpc29uLXJ1bnRpbWUiLCBtc2dpZCkKQEAg
LTIyMywxNCArMjMxLDE0IEBAIHR5cGVkZWYgc2hvcnQgaW50IHl5dHlwZV9pbnQxNjsKICNpZiAo
ZGVmaW5lZCBfX1NURENfXyB8fCBkZWZpbmVkIF9fQzk5X19GVU5DX18gXAogICAgICB8fCBkZWZp
bmVkIF9fY3BsdXNwbHVzIHx8IGRlZmluZWQgX01TQ19WRVIpCiBzdGF0aWMgaW50Ci1ZWUlEIChp
bnQgaSkKK1lZSUQgKGludCB5eWkpCiAjZWxzZQogc3RhdGljIGludAotWVlJRCAoaSkKLSAgICBp
bnQgaTsKK1lZSUQgKHl5aSkKKyAgICBpbnQgeXlpOwogI2VuZGlmCiB7Ci0gIHJldHVybiBpOwor
ICByZXR1cm4geXlpOwogfQogI2VuZGlmCiAKQEAgLTI1MSwxMSArMjU5LDExIEBAIFlZSUQgKGkp
CiAjICAgIGRlZmluZSBhbGxvY2EgX2FsbG9jYQogIyAgIGVsc2UKICMgICAgZGVmaW5lIFlZU1RB
Q0tfQUxMT0MgYWxsb2NhCi0jICAgIGlmICEgZGVmaW5lZCBfQUxMT0NBX0ggJiYgISBkZWZpbmVk
IF9TVERMSUJfSCAmJiAoZGVmaW5lZCBfX1NURENfXyB8fCBkZWZpbmVkIF9fQzk5X19GVU5DX18g
XAorIyAgICBpZiAhIGRlZmluZWQgX0FMTE9DQV9IICYmICEgZGVmaW5lZCBFWElUX1NVQ0NFU1Mg
JiYgKGRlZmluZWQgX19TVERDX18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKICAgICAgfHwg
ZGVmaW5lZCBfX2NwbHVzcGx1cyB8fCBkZWZpbmVkIF9NU0NfVkVSKQogIyAgICAgaW5jbHVkZSA8
c3RkbGliLmg+IC8qIElORlJJTkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KLSMgICAgIGlmbmRl
ZiBfU1RETElCX0gKLSMgICAgICBkZWZpbmUgX1NURExJQl9IIDEKKyMgICAgIGlmbmRlZiBFWElU
X1NVQ0NFU1MKKyMgICAgICBkZWZpbmUgRVhJVF9TVUNDRVNTIDAKICMgICAgIGVuZGlmCiAjICAg
IGVuZGlmCiAjICAgZW5kaWYKQEAgLTI3OCwyNCArMjg2LDI0IEBAIFlZSUQgKGkpCiAjICBpZm5k
ZWYgWVlTVEFDS19BTExPQ19NQVhJTVVNCiAjICAgZGVmaW5lIFlZU1RBQ0tfQUxMT0NfTUFYSU1V
TSBZWVNJWkVfTUFYSU1VTQogIyAgZW5kaWYKLSMgIGlmIChkZWZpbmVkIF9fY3BsdXNwbHVzICYm
ICEgZGVmaW5lZCBfU1RETElCX0ggXAorIyAgaWYgKGRlZmluZWQgX19jcGx1c3BsdXMgJiYgISBk
ZWZpbmVkIEVYSVRfU1VDQ0VTUyBcCiAgICAgICAgJiYgISAoKGRlZmluZWQgWVlNQUxMT0MgfHwg
ZGVmaW5lZCBtYWxsb2MpIFwKIAkgICAgICYmIChkZWZpbmVkIFlZRlJFRSB8fCBkZWZpbmVkIGZy
ZWUpKSkKICMgICBpbmNsdWRlIDxzdGRsaWIuaD4gLyogSU5GUklOR0VTIE9OIFVTRVIgTkFNRSBT
UEFDRSAqLwotIyAgIGlmbmRlZiBfU1RETElCX0gKLSMgICAgZGVmaW5lIF9TVERMSUJfSCAxCisj
ICAgaWZuZGVmIEVYSVRfU1VDQ0VTUworIyAgICBkZWZpbmUgRVhJVF9TVUNDRVNTIDAKICMgICBl
bmRpZgogIyAgZW5kaWYKICMgIGlmbmRlZiBZWU1BTExPQwogIyAgIGRlZmluZSBZWU1BTExPQyBt
YWxsb2MKLSMgICBpZiAhIGRlZmluZWQgbWFsbG9jICYmICEgZGVmaW5lZCBfU1RETElCX0ggJiYg
KGRlZmluZWQgX19TVERDX18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKKyMgICBpZiAhIGRl
ZmluZWQgbWFsbG9jICYmICEgZGVmaW5lZCBFWElUX1NVQ0NFU1MgJiYgKGRlZmluZWQgX19TVERD
X18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKICAgICAgfHwgZGVmaW5lZCBfX2NwbHVzcGx1
cyB8fCBkZWZpbmVkIF9NU0NfVkVSKQogdm9pZCAqbWFsbG9jIChZWVNJWkVfVCk7IC8qIElORlJJ
TkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KICMgICBlbmRpZgogIyAgZW5kaWYKICMgIGlmbmRl
ZiBZWUZSRUUKICMgICBkZWZpbmUgWVlGUkVFIGZyZWUKLSMgICBpZiAhIGRlZmluZWQgZnJlZSAm
JiAhIGRlZmluZWQgX1NURExJQl9IICYmIChkZWZpbmVkIF9fU1REQ19fIHx8IGRlZmluZWQgX19D
OTlfX0ZVTkNfXyBcCisjICAgaWYgISBkZWZpbmVkIGZyZWUgJiYgISBkZWZpbmVkIEVYSVRfU1VD
Q0VTUyAmJiAoZGVmaW5lZCBfX1NURENfXyB8fCBkZWZpbmVkIF9fQzk5X19GVU5DX18gXAogICAg
ICB8fCBkZWZpbmVkIF9fY3BsdXNwbHVzIHx8IGRlZmluZWQgX01TQ19WRVIpCiB2b2lkIGZyZWUg
KHZvaWQgKik7IC8qIElORlJJTkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KICMgICBlbmRpZgpA
QCAtMzEyLDkgKzMyMCw5IEBAIHZvaWQgZnJlZSAodm9pZCAqKTsgLyogSU5GUklOR0VTIE9OIFVT
RVIKIC8qIEEgdHlwZSB0aGF0IGlzIHByb3Blcmx5IGFsaWduZWQgZm9yIGFueSBzdGFjayBtZW1i
ZXIuICAqLwogdW5pb24geXlhbGxvYwogewotICB5eXR5cGVfaW50MTYgeXlzczsKLSAgWVlTVFlQ
RSB5eXZzOwotICAgIFlZTFRZUEUgeXlsczsKKyAgeXl0eXBlX2ludDE2IHl5c3NfYWxsb2M7Cisg
IFlZU1RZUEUgeXl2c19hbGxvYzsKKyAgWVlMVFlQRSB5eWxzX2FsbG9jOwogfTsKIAogLyogVGhl
IHNpemUgb2YgdGhlIG1heGltdW0gZ2FwIGJldHdlZW4gb25lIGFsaWduZWQgc3RhY2sgYW5kIHRo
ZSBuZXh0LiAgKi8KQEAgLTMyNiw2ICszMzQsMjcgQEAgdW5pb24geXlhbGxvYwogICAgICAoKE4p
ICogKHNpemVvZiAoeXl0eXBlX2ludDE2KSArIHNpemVvZiAoWVlTVFlQRSkgKyBzaXplb2YgKFlZ
TFRZUEUpKSBcCiAgICAgICArIDIgKiBZWVNUQUNLX0dBUF9NQVhJTVVNKQogCisjIGRlZmluZSBZ
WUNPUFlfTkVFREVEIDEKKworLyogUmVsb2NhdGUgU1RBQ0sgZnJvbSBpdHMgb2xkIGxvY2F0aW9u
IHRvIHRoZSBuZXcgb25lLiAgVGhlCisgICBsb2NhbCB2YXJpYWJsZXMgWVlTSVpFIGFuZCBZWVNU
QUNLU0laRSBnaXZlIHRoZSBvbGQgYW5kIG5ldyBudW1iZXIgb2YKKyAgIGVsZW1lbnRzIGluIHRo
ZSBzdGFjaywgYW5kIFlZUFRSIGdpdmVzIHRoZSBuZXcgbG9jYXRpb24gb2YgdGhlCisgICBzdGFj
ay4gIEFkdmFuY2UgWVlQVFIgdG8gYSBwcm9wZXJseSBhbGlnbmVkIGxvY2F0aW9uIGZvciB0aGUg
bmV4dAorICAgc3RhY2suICAqLworIyBkZWZpbmUgWVlTVEFDS19SRUxPQ0FURShTdGFja19hbGxv
YywgU3RhY2spCQkJCVwKKyAgICBkbwkJCQkJCQkJCVwKKyAgICAgIHsJCQkJCQkJCQlcCisJWVlT
SVpFX1QgeXluZXdieXRlczsJCQkJCQlcCisJWVlDT1BZICgmeXlwdHItPlN0YWNrX2FsbG9jLCBT
dGFjaywgeXlzaXplKTsJCQlcCisJU3RhY2sgPSAmeXlwdHItPlN0YWNrX2FsbG9jOwkJCQkJXAor
CXl5bmV3Ynl0ZXMgPSB5eXN0YWNrc2l6ZSAqIHNpemVvZiAoKlN0YWNrKSArIFlZU1RBQ0tfR0FQ
X01BWElNVU07IFwKKwl5eXB0ciArPSB5eW5ld2J5dGVzIC8gc2l6ZW9mICgqeXlwdHIpOwkJCQlc
CisgICAgICB9CQkJCQkJCQkJXAorICAgIHdoaWxlIChZWUlEICgwKSkKKworI2VuZGlmCisKKyNp
ZiBkZWZpbmVkIFlZQ09QWV9ORUVERUQgJiYgWVlDT1BZX05FRURFRAogLyogQ29weSBDT1VOVCBv
YmplY3RzIGZyb20gRlJPTSB0byBUTy4gIFRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGRvCiAg
ICBub3Qgb3ZlcmxhcC4gICovCiAjIGlmbmRlZiBZWUNPUFkKQEAgLTM0MywyNCArMzcyLDcgQEAg
dW5pb24geXlhbGxvYwogICAgICAgd2hpbGUgKFlZSUQgKDApKQogIyAgZW5kaWYKICMgZW5kaWYK
LQotLyogUmVsb2NhdGUgU1RBQ0sgZnJvbSBpdHMgb2xkIGxvY2F0aW9uIHRvIHRoZSBuZXcgb25l
LiAgVGhlCi0gICBsb2NhbCB2YXJpYWJsZXMgWVlTSVpFIGFuZCBZWVNUQUNLU0laRSBnaXZlIHRo
ZSBvbGQgYW5kIG5ldyBudW1iZXIgb2YKLSAgIGVsZW1lbnRzIGluIHRoZSBzdGFjaywgYW5kIFlZ
UFRSIGdpdmVzIHRoZSBuZXcgbG9jYXRpb24gb2YgdGhlCi0gICBzdGFjay4gIEFkdmFuY2UgWVlQ
VFIgdG8gYSBwcm9wZXJseSBhbGlnbmVkIGxvY2F0aW9uIGZvciB0aGUgbmV4dAotICAgc3RhY2su
ICAqLwotIyBkZWZpbmUgWVlTVEFDS19SRUxPQ0FURShTdGFjaykJCQkJCVwKLSAgICBkbwkJCQkJ
CQkJCVwKLSAgICAgIHsJCQkJCQkJCQlcCi0JWVlTSVpFX1QgeXluZXdieXRlczsJCQkJCQlcCi0J
WVlDT1BZICgmeXlwdHItPlN0YWNrLCBTdGFjaywgeXlzaXplKTsJCQkJXAotCVN0YWNrID0gJnl5
cHRyLT5TdGFjazsJCQkJCQlcCi0JeXluZXdieXRlcyA9IHl5c3RhY2tzaXplICogc2l6ZW9mICgq
U3RhY2spICsgWVlTVEFDS19HQVBfTUFYSU1VTTsgXAotCXl5cHRyICs9IHl5bmV3Ynl0ZXMgLyBz
aXplb2YgKCp5eXB0cik7CQkJCVwKLSAgICAgIH0JCQkJCQkJCQlcCi0gICAgd2hpbGUgKFlZSUQg
KDApKQotCi0jZW5kaWYKKyNlbmRpZiAvKiAhWVlDT1BZX05FRURFRCAqLwogCiAvKiBZWUZJTkFM
IC0tIFN0YXRlIG51bWJlciBvZiB0aGUgdGVybWluYXRpb24gc3RhdGUuICAqLwogI2RlZmluZSBZ
WUZJTkFMICAyCkBAIC00NTEsNyArNDYzLDcgQEAgc3RhdGljIGNvbnN0IHl5dHlwZV91aW50OCB5
eXJsaW5lW10gPQogc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHl5dG5hbWVbXSA9CiB7CiAgICIk
ZW5kIiwgImVycm9yIiwgIiR1bmRlZmluZWQiLCAiSURFTlQiLCAiU1RSSU5HIiwgIk5VTUJFUiIs
ICJORVdMSU5FIiwKLSAgIic9JyIsICInOyciLCAiJ1snIiwgIiddJyIsICInLCciLCAiJGFjY2Vw
dCIsICJmaWxlIiwgInNldHRpbmciLCAiQDEiLAorICAiJz0nIiwgIic7JyIsICInWyciLCAiJ10n
IiwgIicsJyIsICIkYWNjZXB0IiwgImZpbGUiLCAic2V0dGluZyIsICIkQDEiLAogICAiZW5kc3Rt
dCIsICJ2YWx1ZSIsICJhdG9tIiwgInZhbHVlbGlzdCIsICJ2YWx1ZXMiLCAibmxvayIsIDAKIH07
CiAjZW5kaWYKQEAgLTQ4Miw4ICs0OTQsOCBAQCBzdGF0aWMgY29uc3QgeXl0eXBlX3VpbnQ4IHl5
cjJbXSA9CiAgICAgICAgMgogfTsKIAotLyogWVlERUZBQ1RbU1RBVEUtTkFNRV0gLS0gRGVmYXVs
dCBydWxlIHRvIHJlZHVjZSB3aXRoIGluIHN0YXRlCi0gICBTVEFURS1OVU0gd2hlbiBZWVRBQkxF
IGRvZXNuJ3Qgc3BlY2lmeSBzb21ldGhpbmcgZWxzZSB0byBkby4gIFplcm8KKy8qIFlZREVGQUNU
W1NUQVRFLU5BTUVdIC0tIERlZmF1bHQgcmVkdWN0aW9uIG51bWJlciBpbiBzdGF0ZSBTVEFURS1O
VU0uCisgICBQZXJmb3JtZWQgd2hlbiBZWVRBQkxFIGRvZXNuJ3Qgc3BlY2lmeSBzb21ldGhpbmcg
ZWxzZSB0byBkby4gIFplcm8KICAgIG1lYW5zIHRoZSBkZWZhdWx0IGlzIGFuIGVycm9yLiAgKi8K
IHN0YXRpYyBjb25zdCB5eXR5cGVfdWludDggeXlkZWZhY3RbXSA9CiB7CkBAIC01MTYsOCArNTI4
LDcgQEAgc3RhdGljIGNvbnN0IHl5dHlwZV9pbnQ4IHl5cGdvdG9bXSA9CiAKIC8qIFlZVEFCTEVb
WVlQQUNUW1NUQVRFLU5VTV1dLiAgV2hhdCB0byBkbyBpbiBzdGF0ZSBTVEFURS1OVU0uICBJZgog
ICAgcG9zaXRpdmUsIHNoaWZ0IHRoYXQgdG9rZW4uICBJZiBuZWdhdGl2ZSwgcmVkdWNlIHRoZSBy
dWxlIHdoaWNoCi0gICBudW1iZXIgaXMgdGhlIG9wcG9zaXRlLiAgSWYgemVybywgZG8gd2hhdCBZ
WURFRkFDVCBzYXlzLgotICAgSWYgWVlUQUJMRV9OSU5GLCBzeW50YXggZXJyb3IuICAqLworICAg
bnVtYmVyIGlzIHRoZSBvcHBvc2l0ZS4gIElmIFlZVEFCTEVfTklORiwgc3ludGF4IGVycm9yLiAg
Ki8KICNkZWZpbmUgWVlUQUJMRV9OSU5GIC0xCiBzdGF0aWMgY29uc3QgeXl0eXBlX3VpbnQ4IHl5
dGFibGVbXSA9CiB7CkBAIC01MjYsNiArNTM3LDEyIEBAIHN0YXRpYyBjb25zdCB5eXR5cGVfdWlu
dDggeXl0YWJsZVtdID0KICAgICAgIDI1LCAgICAyNCwgICAgMTgsICAgIDIyCiB9OwogCisjZGVm
aW5lIHl5cGFjdF92YWx1ZV9pc19kZWZhdWx0KHl5c3RhdGUpIFwKKyAgKCh5eXN0YXRlKSA9PSAo
LTE3KSkKKworI2RlZmluZSB5eXRhYmxlX3ZhbHVlX2lzX2Vycm9yKHl5dGFibGVfdmFsdWUpIFwK
KyAgWVlJRCAoMCkKKwogc3RhdGljIGNvbnN0IHl5dHlwZV91aW50OCB5eWNoZWNrW10gPQogewog
ICAgICAgMTYsICAgICAwLCAgICAgMSwgICAgIDYsICAgICAzLCAgICAxOSwgICAgIDYsICAgICA2
LCAgICAgOCwgICAgIDgsCkBAIC01NTQsOSArNTcxLDE4IEBAIHN0YXRpYyBjb25zdCB5eXR5cGVf
dWludDggeXlzdG9zW10gPQogCiAvKiBMaWtlIFlZRVJST1IgZXhjZXB0IGRvIGNhbGwgeXllcnJv
ci4gIFRoaXMgcmVtYWlucyBoZXJlIHRlbXBvcmFyaWx5CiAgICB0byBlYXNlIHRoZSB0cmFuc2l0
aW9uIHRvIHRoZSBuZXcgbWVhbmluZyBvZiBZWUVSUk9SLCBmb3IgR0NDLgotICAgT25jZSBHQ0Mg
dmVyc2lvbiAyIGhhcyBzdXBwbGFudGVkIHZlcnNpb24gMSwgdGhpcyBjYW4gZ28uICAqLworICAg
T25jZSBHQ0MgdmVyc2lvbiAyIGhhcyBzdXBwbGFudGVkIHZlcnNpb24gMSwgdGhpcyBjYW4gZ28u
ICBIb3dldmVyLAorICAgWVlGQUlMIGFwcGVhcnMgdG8gYmUgaW4gdXNlLiAgTmV2ZXJ0aGVsZXNz
LCBpdCBpcyBmb3JtYWxseSBkZXByZWNhdGVkCisgICBpbiBCaXNvbiAyLjQuMidzIE5FV1MgZW50
cnksIHdoZXJlIGEgcGxhbiB0byBwaGFzZSBpdCBvdXQgaXMKKyAgIGRpc2N1c3NlZC4gICovCiAK
ICNkZWZpbmUgWVlGQUlMCQlnb3RvIHl5ZXJybGFiCisjaWYgZGVmaW5lZCBZWUZBSUwKKyAgLyog
VGhpcyBpcyBoZXJlIHRvIHN1cHByZXNzIHdhcm5pbmdzIGZyb20gdGhlIEdDQyBjcHAncworICAg
ICAtV3VudXNlZC1tYWNyb3MuICBOb3JtYWxseSB3ZSBkb24ndCB3b3JyeSBhYm91dCB0aGF0IHdh
cm5pbmcsIGJ1dAorICAgICBzb21lIHVzZXJzIGRvLCBhbmQgd2Ugd2FudCB0byBtYWtlIGl0IGVh
c3kgZm9yIHVzZXJzIHRvIHJlbW92ZQorICAgICBZWUZBSUwgdXNlcywgd2hpY2ggd2lsbCBwcm9k
dWNlIHdhcm5pbmdzIGZyb20gQmlzb24gMi41LiAgKi8KKyNlbmRpZgogCiAjZGVmaW5lIFlZUkVD
T1ZFUklORygpICAoISF5eWVycnN0YXR1cykKIApAQCAtNTY2LDcgKzU5Miw2IEBAIGRvCQkJCQkJ
CQlcCiAgICAgewkJCQkJCQkJXAogICAgICAgeXljaGFyID0gKFRva2VuKTsJCQkJCQlcCiAgICAg
ICB5eWx2YWwgPSAoVmFsdWUpOwkJCQkJCVwKLSAgICAgIHl5dG9rZW4gPSBZWVRSQU5TTEFURSAo
eXljaGFyKTsJCQkJXAogICAgICAgWVlQT1BTVEFDSyAoMSk7CQkJCQkJXAogICAgICAgZ290byB5
eWJhY2t1cDsJCQkJCQlcCiAgICAgfQkJCQkJCQkJXApAQCAtNjEzLDcgKzYzOCw3IEBAIHdoaWxl
IChZWUlEICgwKSkKICAgIHdlIHdvbid0IGJyZWFrIHVzZXIgY29kZTogd2hlbiB0aGVzZSBhcmUg
dGhlIGxvY2F0aW9ucyB3ZSBrbm93LiAgKi8KIAogI2lmbmRlZiBZWV9MT0NBVElPTl9QUklOVAot
IyBpZiBZWUxUWVBFX0lTX1RSSVZJQUwKKyMgaWYgZGVmaW5lZCBZWUxUWVBFX0lTX1RSSVZJQUwg
JiYgWVlMVFlQRV9JU19UUklWSUFMCiAjICBkZWZpbmUgWVlfTE9DQVRJT05fUFJJTlQoRmlsZSwg
TG9jKQkJCVwKICAgICAgZnByaW50ZiAoRmlsZSwgIiVkLiVkLSVkLiVkIiwJCQlcCiAJICAgICAg
KExvYykuZmlyc3RfbGluZSwgKExvYykuZmlyc3RfY29sdW1uLAlcCkBAIC03MzIsMTcgKzc1Nywy
MCBAQCB5eV9zeW1ib2xfcHJpbnQgKHl5b3V0cHV0LCB5eXR5cGUsIHl5dmFsCiAjaWYgKGRlZmlu
ZWQgX19TVERDX18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKICAgICAgfHwgZGVmaW5lZCBf
X2NwbHVzcGx1cyB8fCBkZWZpbmVkIF9NU0NfVkVSKQogc3RhdGljIHZvaWQKLXl5X3N0YWNrX3By
aW50ICh5eXR5cGVfaW50MTYgKmJvdHRvbSwgeXl0eXBlX2ludDE2ICp0b3ApCit5eV9zdGFja19w
cmludCAoeXl0eXBlX2ludDE2ICp5eWJvdHRvbSwgeXl0eXBlX2ludDE2ICp5eXRvcCkKICNlbHNl
CiBzdGF0aWMgdm9pZAoteXlfc3RhY2tfcHJpbnQgKGJvdHRvbSwgdG9wKQotICAgIHl5dHlwZV9p
bnQxNiAqYm90dG9tOwotICAgIHl5dHlwZV9pbnQxNiAqdG9wOworeXlfc3RhY2tfcHJpbnQgKHl5
Ym90dG9tLCB5eXRvcCkKKyAgICB5eXR5cGVfaW50MTYgKnl5Ym90dG9tOworICAgIHl5dHlwZV9p
bnQxNiAqeXl0b3A7CiAjZW5kaWYKIHsKICAgWVlGUFJJTlRGIChzdGRlcnIsICJTdGFjayBub3ci
KTsKLSAgZm9yICg7IGJvdHRvbSA8PSB0b3A7ICsrYm90dG9tKQotICAgIFlZRlBSSU5URiAoc3Rk
ZXJyLCAiICVkIiwgKmJvdHRvbSk7CisgIGZvciAoOyB5eWJvdHRvbSA8PSB5eXRvcDsgeXlib3R0
b20rKykKKyAgICB7CisgICAgICBpbnQgeXlib3QgPSAqeXlib3R0b207CisgICAgICBZWUZQUklO
VEYgKHN0ZGVyciwgIiAlZCIsIHl5Ym90KTsKKyAgICB9CiAgIFlZRlBSSU5URiAoc3RkZXJyLCAi
XG4iKTsKIH0KIApAQCAtNzc4LDExICs4MDYsMTEgQEAgeXlfcmVkdWNlX3ByaW50ICh5eXZzcCwg
eXlsc3AsIHl5cnVsZSwgYwogICAvKiBUaGUgc3ltYm9scyBiZWluZyByZWR1Y2VkLiAgKi8KICAg
Zm9yICh5eWkgPSAwOyB5eWkgPCB5eW5yaHM7IHl5aSsrKQogICAgIHsKLSAgICAgIGZwcmludGYg
KHN0ZGVyciwgIiAgICQlZCA9ICIsIHl5aSArIDEpOworICAgICAgWVlGUFJJTlRGIChzdGRlcnIs
ICIgICAkJWQgPSAiLCB5eWkgKyAxKTsKICAgICAgIHl5X3N5bWJvbF9wcmludCAoc3RkZXJyLCB5
eXJoc1t5eXByaHNbeXlydWxlXSArIHl5aV0sCiAJCSAgICAgICAmKHl5dnNwWyh5eWkgKyAxKSAt
ICh5eW5yaHMpXSkKIAkJICAgICAgICwgJih5eWxzcFsoeXlpICsgMSkgLSAoeXlucmhzKV0pCQkg
ICAgICAgLCBjdHgpOwotICAgICAgZnByaW50ZiAoc3RkZXJyLCAiXG4iKTsKKyAgICAgIFlZRlBS
SU5URiAoc3RkZXJyLCAiXG4iKTsKICAgICB9CiB9CiAKQEAgLTgyMCw3ICs4NDgsNiBAQCBpbnQg
eXlkZWJ1ZzsKICNlbmRpZgogCiAKLQogI2lmIFlZRVJST1JfVkVSQk9TRQogCiAjIGlmbmRlZiB5
eXN0cmxlbgpAQCAtOTIyLDExNiArOTQ5LDE0MyBAQCB5eXRuYW1lcnIgKGNoYXIgKnl5cmVzLCBj
b25zdCBjaGFyICp5eXN0CiB9CiAjIGVuZGlmCiAKLS8qIENvcHkgaW50byBZWVJFU1VMVCBhbiBl
cnJvciBtZXNzYWdlIGFib3V0IHRoZSB1bmV4cGVjdGVkIHRva2VuCi0gICBZWUNIQVIgd2hpbGUg
aW4gc3RhdGUgWVlTVEFURS4gIFJldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIGNvcGllZCwKLSAg
IGluY2x1ZGluZyB0aGUgdGVybWluYXRpbmcgbnVsbCBieXRlLiAgSWYgWVlSRVNVTFQgaXMgbnVs
bCwgZG8gbm90Ci0gICBjb3B5IGFueXRoaW5nOyBqdXN0IHJldHVybiB0aGUgbnVtYmVyIG9mIGJ5
dGVzIHRoYXQgd291bGQgYmUKLSAgIGNvcGllZC4gIEFzIGEgc3BlY2lhbCBjYXNlLCByZXR1cm4g
MCBpZiBhbiBvcmRpbmFyeSAic3ludGF4IGVycm9yIgotICAgbWVzc2FnZSB3aWxsIGRvLiAgUmV0
dXJuIFlZU0laRV9NQVhJTVVNIGlmIG92ZXJmbG93IG9jY3VycyBkdXJpbmcKLSAgIHNpemUgY2Fs
Y3VsYXRpb24uICAqLwotc3RhdGljIFlZU0laRV9UCi15eXN5bnRheF9lcnJvciAoY2hhciAqeXly
ZXN1bHQsIGludCB5eXN0YXRlLCBpbnQgeXljaGFyKQorLyogQ29weSBpbnRvICpZWU1TRywgd2hp
Y2ggaXMgb2Ygc2l6ZSAqWVlNU0dfQUxMT0MsIGFuIGVycm9yIG1lc3NhZ2UKKyAgIGFib3V0IHRo
ZSB1bmV4cGVjdGVkIHRva2VuIFlZVE9LRU4gZm9yIHRoZSBzdGF0ZSBzdGFjayB3aG9zZSB0b3Ag
aXMKKyAgIFlZU1NQLgorCisgICBSZXR1cm4gMCBpZiAqWVlNU0cgd2FzIHN1Y2Nlc3NmdWxseSB3
cml0dGVuLiAgUmV0dXJuIDEgaWYgKllZTVNHIGlzCisgICBub3QgbGFyZ2UgZW5vdWdoIHRvIGhv
bGQgdGhlIG1lc3NhZ2UuICBJbiB0aGF0IGNhc2UsIGFsc28gc2V0CisgICAqWVlNU0dfQUxMT0Mg
dG8gdGhlIHJlcXVpcmVkIG51bWJlciBvZiBieXRlcy4gIFJldHVybiAyIGlmIHRoZQorICAgcmVx
dWlyZWQgbnVtYmVyIG9mIGJ5dGVzIGlzIHRvbyBsYXJnZSB0byBzdG9yZS4gICovCitzdGF0aWMg
aW50Cit5eXN5bnRheF9lcnJvciAoWVlTSVpFX1QgKnl5bXNnX2FsbG9jLCBjaGFyICoqeXltc2cs
CisgICAgICAgICAgICAgICAgeXl0eXBlX2ludDE2ICp5eXNzcCwgaW50IHl5dG9rZW4pCiB7Ci0g
IGludCB5eW4gPSB5eXBhY3RbeXlzdGF0ZV07CisgIFlZU0laRV9UIHl5c2l6ZTAgPSB5eXRuYW1l
cnIgKDAsIHl5dG5hbWVbeXl0b2tlbl0pOworICBZWVNJWkVfVCB5eXNpemUgPSB5eXNpemUwOwor
ICBZWVNJWkVfVCB5eXNpemUxOworICBlbnVtIHsgWVlFUlJPUl9WRVJCT1NFX0FSR1NfTUFYSU1V
TSA9IDUgfTsKKyAgLyogSW50ZXJuYXRpb25hbGl6ZWQgZm9ybWF0IHN0cmluZy4gKi8KKyAgY29u
c3QgY2hhciAqeXlmb3JtYXQgPSAwOworICAvKiBBcmd1bWVudHMgb2YgeXlmb3JtYXQuICovCisg
IGNoYXIgY29uc3QgKnl5YXJnW1lZRVJST1JfVkVSQk9TRV9BUkdTX01BWElNVU1dOworICAvKiBO
dW1iZXIgb2YgcmVwb3J0ZWQgdG9rZW5zIChvbmUgZm9yIHRoZSAidW5leHBlY3RlZCIsIG9uZSBw
ZXIKKyAgICAgImV4cGVjdGVkIikuICovCisgIGludCB5eWNvdW50ID0gMDsKIAotICBpZiAoISAo
WVlQQUNUX05JTkYgPCB5eW4gJiYgeXluIDw9IFlZTEFTVCkpCi0gICAgcmV0dXJuIDA7Ci0gIGVs
c2UKKyAgLyogVGhlcmUgYXJlIG1hbnkgcG9zc2liaWxpdGllcyBoZXJlIHRvIGNvbnNpZGVyOgor
ICAgICAtIEFzc3VtZSBZWUZBSUwgaXMgbm90IHVzZWQuICBJdCdzIHRvbyBmbGF3ZWQgdG8gY29u
c2lkZXIuICBTZWUKKyAgICAgICA8aHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2Jp
c29uLXBhdGNoZXMvMjAwOS0xMi9tc2cwMDAyNC5odG1sPgorICAgICAgIGZvciBkZXRhaWxzLiAg
WVlFUlJPUiBpcyBmaW5lIGFzIGl0IGRvZXMgbm90IGludm9rZSB0aGlzCisgICAgICAgZnVuY3Rp
b24uCisgICAgIC0gSWYgdGhpcyBzdGF0ZSBpcyBhIGNvbnNpc3RlbnQgc3RhdGUgd2l0aCBhIGRl
ZmF1bHQgYWN0aW9uLCB0aGVuCisgICAgICAgdGhlIG9ubHkgd2F5IHRoaXMgZnVuY3Rpb24gd2Fz
IGludm9rZWQgaXMgaWYgdGhlIGRlZmF1bHQgYWN0aW9uCisgICAgICAgaXMgYW4gZXJyb3IgYWN0
aW9uLiAgSW4gdGhhdCBjYXNlLCBkb24ndCBjaGVjayBmb3IgZXhwZWN0ZWQKKyAgICAgICB0b2tl
bnMgYmVjYXVzZSB0aGVyZSBhcmUgbm9uZS4KKyAgICAgLSBUaGUgb25seSB3YXkgdGhlcmUgY2Fu
IGJlIG5vIGxvb2thaGVhZCBwcmVzZW50IChpbiB5eWNoYXIpIGlzIGlmCisgICAgICAgdGhpcyBz
dGF0ZSBpcyBhIGNvbnNpc3RlbnQgc3RhdGUgd2l0aCBhIGRlZmF1bHQgYWN0aW9uLiAgVGh1cywK
KyAgICAgICBkZXRlY3RpbmcgdGhlIGFic2VuY2Ugb2YgYSBsb29rYWhlYWQgaXMgc3VmZmljaWVu
dCB0byBkZXRlcm1pbmUKKyAgICAgICB0aGF0IHRoZXJlIGlzIG5vIHVuZXhwZWN0ZWQgb3IgZXhw
ZWN0ZWQgdG9rZW4gdG8gcmVwb3J0LiAgSW4gdGhhdAorICAgICAgIGNhc2UsIGp1c3QgcmVwb3J0
IGEgc2ltcGxlICJzeW50YXggZXJyb3IiLgorICAgICAtIERvbid0IGFzc3VtZSB0aGVyZSBpc24n
dCBhIGxvb2thaGVhZCBqdXN0IGJlY2F1c2UgdGhpcyBzdGF0ZSBpcyBhCisgICAgICAgY29uc2lz
dGVudCBzdGF0ZSB3aXRoIGEgZGVmYXVsdCBhY3Rpb24uICBUaGVyZSBtaWdodCBoYXZlIGJlZW4g
YQorICAgICAgIHByZXZpb3VzIGluY29uc2lzdGVudCBzdGF0ZSwgY29uc2lzdGVudCBzdGF0ZSB3
aXRoIGEgbm9uLWRlZmF1bHQKKyAgICAgICBhY3Rpb24sIG9yIHVzZXIgc2VtYW50aWMgYWN0aW9u
IHRoYXQgbWFuaXB1bGF0ZWQgeXljaGFyLgorICAgICAtIE9mIGNvdXJzZSwgdGhlIGV4cGVjdGVk
IHRva2VuIGxpc3QgZGVwZW5kcyBvbiBzdGF0ZXMgdG8gaGF2ZQorICAgICAgIGNvcnJlY3QgbG9v
a2FoZWFkIGluZm9ybWF0aW9uLCBhbmQgaXQgZGVwZW5kcyBvbiB0aGUgcGFyc2VyIG5vdAorICAg
ICAgIHRvIHBlcmZvcm0gZXh0cmEgcmVkdWN0aW9ucyBhZnRlciBmZXRjaGluZyBhIGxvb2thaGVh
ZCBmcm9tIHRoZQorICAgICAgIHNjYW5uZXIgYW5kIGJlZm9yZSBkZXRlY3RpbmcgYSBzeW50YXgg
ZXJyb3IuICBUaHVzLCBzdGF0ZSBtZXJnaW5nCisgICAgICAgKGZyb20gTEFMUiBvciBJRUxSKSBh
bmQgZGVmYXVsdCByZWR1Y3Rpb25zIGNvcnJ1cHQgdGhlIGV4cGVjdGVkCisgICAgICAgdG9rZW4g
bGlzdC4gIEhvd2V2ZXIsIHRoZSBsaXN0IGlzIGNvcnJlY3QgZm9yIGNhbm9uaWNhbCBMUiB3aXRo
CisgICAgICAgb25lIGV4Y2VwdGlvbjogaXQgd2lsbCBzdGlsbCBjb250YWluIGFueSB0b2tlbiB0
aGF0IHdpbGwgbm90IGJlCisgICAgICAgYWNjZXB0ZWQgZHVlIHRvIGFuIGVycm9yIGFjdGlvbiBp
biBhIGxhdGVyIHN0YXRlLgorICAqLworICBpZiAoeXl0b2tlbiAhPSBZWUVNUFRZKQogICAgIHsK
LSAgICAgIGludCB5eXR5cGUgPSBZWVRSQU5TTEFURSAoeXljaGFyKTsKLSAgICAgIFlZU0laRV9U
IHl5c2l6ZTAgPSB5eXRuYW1lcnIgKDAsIHl5dG5hbWVbeXl0eXBlXSk7Ci0gICAgICBZWVNJWkVf
VCB5eXNpemUgPSB5eXNpemUwOwotICAgICAgWVlTSVpFX1QgeXlzaXplMTsKLSAgICAgIGludCB5
eXNpemVfb3ZlcmZsb3cgPSAwOwotICAgICAgZW51bSB7IFlZRVJST1JfVkVSQk9TRV9BUkdTX01B
WElNVU0gPSA1IH07Ci0gICAgICBjaGFyIGNvbnN0ICp5eWFyZ1tZWUVSUk9SX1ZFUkJPU0VfQVJH
U19NQVhJTVVNXTsKLSAgICAgIGludCB5eXg7CisgICAgICBpbnQgeXluID0geXlwYWN0Wyp5eXNz
cF07CisgICAgICB5eWFyZ1t5eWNvdW50KytdID0geXl0bmFtZVt5eXRva2VuXTsKKyAgICAgIGlm
ICgheXlwYWN0X3ZhbHVlX2lzX2RlZmF1bHQgKHl5bikpCisgICAgICAgIHsKKyAgICAgICAgICAv
KiBTdGFydCBZWVggYXQgLVlZTiBpZiBuZWdhdGl2ZSB0byBhdm9pZCBuZWdhdGl2ZSBpbmRleGVz
IGluCisgICAgICAgICAgICAgWVlDSEVDSy4gIEluIG90aGVyIHdvcmRzLCBza2lwIHRoZSBmaXJz
dCAtWVlOIGFjdGlvbnMgZm9yCisgICAgICAgICAgICAgdGhpcyBzdGF0ZSBiZWNhdXNlIHRoZXkg
YXJlIGRlZmF1bHQgYWN0aW9ucy4gICovCisgICAgICAgICAgaW50IHl5eGJlZ2luID0geXluIDwg
MCA/IC15eW4gOiAwOworICAgICAgICAgIC8qIFN0YXkgd2l0aGluIGJvdW5kcyBvZiBib3RoIHl5
Y2hlY2sgYW5kIHl5dG5hbWUuICAqLworICAgICAgICAgIGludCB5eWNoZWNrbGltID0gWVlMQVNU
IC0geXluICsgMTsKKyAgICAgICAgICBpbnQgeXl4ZW5kID0geXljaGVja2xpbSA8IFlZTlRPS0VO
UyA/IHl5Y2hlY2tsaW0gOiBZWU5UT0tFTlM7CisgICAgICAgICAgaW50IHl5eDsKIAotIyBpZiAw
Ci0gICAgICAvKiBUaGlzIGlzIHNvIHhnZXR0ZXh0IHNlZXMgdGhlIHRyYW5zbGF0YWJsZSBmb3Jt
YXRzIHRoYXQgYXJlCi0JIGNvbnN0cnVjdGVkIG9uIHRoZSBmbHkuICAqLwotICAgICAgWVlfKCJz
eW50YXggZXJyb3IsIHVuZXhwZWN0ZWQgJXMiKTsKLSAgICAgIFlZXygic3ludGF4IGVycm9yLCB1
bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMiKTsKLSAgICAgIFlZXygic3ludGF4IGVycm9yLCB1
bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMiKTsKLSAgICAgIFlZXygic3ludGF4IGVy
cm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMgb3IgJXMiKTsKLSAgICAgIFlZ
Xygic3ludGF4IGVycm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMgb3IgJXMg
b3IgJXMiKTsKLSMgZW5kaWYKLSAgICAgIGNoYXIgKnl5Zm10OwotICAgICAgY2hhciBjb25zdCAq
eXlmOwotICAgICAgc3RhdGljIGNoYXIgY29uc3QgeXl1bmV4cGVjdGVkW10gPSAic3ludGF4IGVy
cm9yLCB1bmV4cGVjdGVkICVzIjsKLSAgICAgIHN0YXRpYyBjaGFyIGNvbnN0IHl5ZXhwZWN0aW5n
W10gPSAiLCBleHBlY3RpbmcgJXMiOwotICAgICAgc3RhdGljIGNoYXIgY29uc3QgeXlvcltdID0g
IiBvciAlcyI7Ci0gICAgICBjaGFyIHl5Zm9ybWF0W3NpemVvZiB5eXVuZXhwZWN0ZWQKLQkJICAg
ICsgc2l6ZW9mIHl5ZXhwZWN0aW5nIC0gMQotCQkgICAgKyAoKFlZRVJST1JfVkVSQk9TRV9BUkdT
X01BWElNVU0gLSAyKQotCQkgICAgICAgKiAoc2l6ZW9mIHl5b3IgLSAxKSldOwotICAgICAgY2hh
ciBjb25zdCAqeXlwcmVmaXggPSB5eWV4cGVjdGluZzsKKyAgICAgICAgICBmb3IgKHl5eCA9IHl5
eGJlZ2luOyB5eXggPCB5eXhlbmQ7ICsreXl4KQorICAgICAgICAgICAgaWYgKHl5Y2hlY2tbeXl4
ICsgeXluXSA9PSB5eXggJiYgeXl4ICE9IFlZVEVSUk9SCisgICAgICAgICAgICAgICAgJiYgIXl5
dGFibGVfdmFsdWVfaXNfZXJyb3IgKHl5dGFibGVbeXl4ICsgeXluXSkpCisgICAgICAgICAgICAg
IHsKKyAgICAgICAgICAgICAgICBpZiAoeXljb3VudCA9PSBZWUVSUk9SX1ZFUkJPU0VfQVJHU19N
QVhJTVVNKQorICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICB5eWNvdW50
ID0gMTsKKyAgICAgICAgICAgICAgICAgICAgeXlzaXplID0geXlzaXplMDsKKyAgICAgICAgICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgeXlh
cmdbeXljb3VudCsrXSA9IHl5dG5hbWVbeXl4XTsKKyAgICAgICAgICAgICAgICB5eXNpemUxID0g
eXlzaXplICsgeXl0bmFtZXJyICgwLCB5eXRuYW1lW3l5eF0pOworICAgICAgICAgICAgICAgIGlm
ICghICh5eXNpemUgPD0geXlzaXplMQorICAgICAgICAgICAgICAgICAgICAgICAmJiB5eXNpemUx
IDw9IFlZU1RBQ0tfQUxMT0NfTUFYSU1VTSkpCisgICAgICAgICAgICAgICAgICByZXR1cm4gMjsK
KyAgICAgICAgICAgICAgICB5eXNpemUgPSB5eXNpemUxOworICAgICAgICAgICAgICB9CisgICAg
ICAgIH0KKyAgICB9CiAKLSAgICAgIC8qIFN0YXJ0IFlZWCBhdCAtWVlOIGlmIG5lZ2F0aXZlIHRv
IGF2b2lkIG5lZ2F0aXZlIGluZGV4ZXMgaW4KLQkgWVlDSEVDSy4gICovCi0gICAgICBpbnQgeXl4
YmVnaW4gPSB5eW4gPCAwID8gLXl5biA6IDA7CisgIHN3aXRjaCAoeXljb3VudCkKKyAgICB7Cisj
IGRlZmluZSBZWUNBU0VfKE4sIFMpICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgIGNhc2Ug
TjogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICB5eWZvcm1hdCA9IFM7
ICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICBicmVhaworICAgICAgWVlDQVNFXygwLCBZ
WV8oInN5bnRheCBlcnJvciIpKTsKKyAgICAgIFlZQ0FTRV8oMSwgWVlfKCJzeW50YXggZXJyb3Is
IHVuZXhwZWN0ZWQgJXMiKSk7CisgICAgICBZWUNBU0VfKDIsIFlZXygic3ludGF4IGVycm9yLCB1
bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMiKSk7CisgICAgICBZWUNBU0VfKDMsIFlZXygic3lu
dGF4IGVycm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMiKSk7CisgICAgICBZ
WUNBU0VfKDQsIFlZXygic3ludGF4IGVycm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMg
b3IgJXMgb3IgJXMiKSk7CisgICAgICBZWUNBU0VfKDUsIFlZXygic3ludGF4IGVycm9yLCB1bmV4
cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMgb3IgJXMgb3IgJXMiKSk7CisjIHVuZGVmIFlZ
Q0FTRV8KKyAgICB9CiAKLSAgICAgIC8qIFN0YXkgd2l0aGluIGJvdW5kcyBvZiBib3RoIHl5Y2hl
Y2sgYW5kIHl5dG5hbWUuICAqLwotICAgICAgaW50IHl5Y2hlY2tsaW0gPSBZWUxBU1QgLSB5eW4g
KyAxOwotICAgICAgaW50IHl5eGVuZCA9IHl5Y2hlY2tsaW0gPCBZWU5UT0tFTlMgPyB5eWNoZWNr
bGltIDogWVlOVE9LRU5TOwotICAgICAgaW50IHl5Y291bnQgPSAxOworICB5eXNpemUxID0geXlz
aXplICsgeXlzdHJsZW4gKHl5Zm9ybWF0KTsKKyAgaWYgKCEgKHl5c2l6ZSA8PSB5eXNpemUxICYm
IHl5c2l6ZTEgPD0gWVlTVEFDS19BTExPQ19NQVhJTVVNKSkKKyAgICByZXR1cm4gMjsKKyAgeXlz
aXplID0geXlzaXplMTsKIAotICAgICAgeXlhcmdbMF0gPSB5eXRuYW1lW3l5dHlwZV07Ci0gICAg
ICB5eWZtdCA9IHl5c3RwY3B5ICh5eWZvcm1hdCwgeXl1bmV4cGVjdGVkKTsKKyAgaWYgKCp5eW1z
Z19hbGxvYyA8IHl5c2l6ZSkKKyAgICB7CisgICAgICAqeXltc2dfYWxsb2MgPSAyICogeXlzaXpl
OworICAgICAgaWYgKCEgKHl5c2l6ZSA8PSAqeXltc2dfYWxsb2MKKyAgICAgICAgICAgICAmJiAq
eXltc2dfYWxsb2MgPD0gWVlTVEFDS19BTExPQ19NQVhJTVVNKSkKKyAgICAgICAgKnl5bXNnX2Fs
bG9jID0gWVlTVEFDS19BTExPQ19NQVhJTVVNOworICAgICAgcmV0dXJuIDE7CisgICAgfQogCi0g
ICAgICBmb3IgKHl5eCA9IHl5eGJlZ2luOyB5eXggPCB5eXhlbmQ7ICsreXl4KQotCWlmICh5eWNo
ZWNrW3l5eCArIHl5bl0gPT0geXl4ICYmIHl5eCAhPSBZWVRFUlJPUikKLQkgIHsKLQkgICAgaWYg
KHl5Y291bnQgPT0gWVlFUlJPUl9WRVJCT1NFX0FSR1NfTUFYSU1VTSkKLQkgICAgICB7Ci0JCXl5
Y291bnQgPSAxOwotCQl5eXNpemUgPSB5eXNpemUwOwotCQl5eWZvcm1hdFtzaXplb2YgeXl1bmV4
cGVjdGVkIC0gMV0gPSAnXDAnOwotCQlicmVhazsKLQkgICAgICB9Ci0JICAgIHl5YXJnW3l5Y291
bnQrK10gPSB5eXRuYW1lW3l5eF07Ci0JICAgIHl5c2l6ZTEgPSB5eXNpemUgKyB5eXRuYW1lcnIg
KDAsIHl5dG5hbWVbeXl4XSk7Ci0JICAgIHl5c2l6ZV9vdmVyZmxvdyB8PSAoeXlzaXplMSA8IHl5
c2l6ZSk7Ci0JICAgIHl5c2l6ZSA9IHl5c2l6ZTE7Ci0JICAgIHl5Zm10ID0geXlzdHBjcHkgKHl5
Zm10LCB5eXByZWZpeCk7Ci0JICAgIHl5cHJlZml4ID0geXlvcjsKLQkgIH0KLQotICAgICAgeXlm
ID0gWVlfKHl5Zm9ybWF0KTsKLSAgICAgIHl5c2l6ZTEgPSB5eXNpemUgKyB5eXN0cmxlbiAoeXlm
KTsKLSAgICAgIHl5c2l6ZV9vdmVyZmxvdyB8PSAoeXlzaXplMSA8IHl5c2l6ZSk7Ci0gICAgICB5
eXNpemUgPSB5eXNpemUxOwotCi0gICAgICBpZiAoeXlzaXplX292ZXJmbG93KQotCXJldHVybiBZ
WVNJWkVfTUFYSU1VTTsKLQotICAgICAgaWYgKHl5cmVzdWx0KQotCXsKLQkgIC8qIEF2b2lkIHNw
cmludGYsIGFzIHRoYXQgaW5mcmluZ2VzIG9uIHRoZSB1c2VyJ3MgbmFtZSBzcGFjZS4KLQkgICAg
IERvbid0IGhhdmUgdW5kZWZpbmVkIGJlaGF2aW9yIGV2ZW4gaWYgdGhlIHRyYW5zbGF0aW9uCi0J
ICAgICBwcm9kdWNlZCBhIHN0cmluZyB3aXRoIHRoZSB3cm9uZyBudW1iZXIgb2YgIiVzInMuICAq
LwotCSAgY2hhciAqeXlwID0geXlyZXN1bHQ7Ci0JICBpbnQgeXlpID0gMDsKLQkgIHdoaWxlICgo
Knl5cCA9ICp5eWYpICE9ICdcMCcpCi0JICAgIHsKLQkgICAgICBpZiAoKnl5cCA9PSAnJScgJiYg
eXlmWzFdID09ICdzJyAmJiB5eWkgPCB5eWNvdW50KQotCQl7Ci0JCSAgeXlwICs9IHl5dG5hbWVy
ciAoeXlwLCB5eWFyZ1t5eWkrK10pOwotCQkgIHl5ZiArPSAyOwotCQl9Ci0JICAgICAgZWxzZQot
CQl7Ci0JCSAgeXlwKys7Ci0JCSAgeXlmKys7Ci0JCX0KLQkgICAgfQotCX0KLSAgICAgIHJldHVy
biB5eXNpemU7Ci0gICAgfQorICAvKiBBdm9pZCBzcHJpbnRmLCBhcyB0aGF0IGluZnJpbmdlcyBv
biB0aGUgdXNlcidzIG5hbWUgc3BhY2UuCisgICAgIERvbid0IGhhdmUgdW5kZWZpbmVkIGJlaGF2
aW9yIGV2ZW4gaWYgdGhlIHRyYW5zbGF0aW9uCisgICAgIHByb2R1Y2VkIGEgc3RyaW5nIHdpdGgg
dGhlIHdyb25nIG51bWJlciBvZiAiJXMicy4gICovCisgIHsKKyAgICBjaGFyICp5eXAgPSAqeXlt
c2c7CisgICAgaW50IHl5aSA9IDA7CisgICAgd2hpbGUgKCgqeXlwID0gKnl5Zm9ybWF0KSAhPSAn
XDAnKQorICAgICAgaWYgKCp5eXAgPT0gJyUnICYmIHl5Zm9ybWF0WzFdID09ICdzJyAmJiB5eWkg
PCB5eWNvdW50KQorICAgICAgICB7CisgICAgICAgICAgeXlwICs9IHl5dG5hbWVyciAoeXlwLCB5
eWFyZ1t5eWkrK10pOworICAgICAgICAgIHl5Zm9ybWF0ICs9IDI7CisgICAgICAgIH0KKyAgICAg
IGVsc2UKKyAgICAgICAgeworICAgICAgICAgIHl5cCsrOworICAgICAgICAgIHl5Zm9ybWF0Kys7
CisgICAgICAgIH0KKyAgfQorICByZXR1cm4gMDsKIH0KICNlbmRpZiAvKiBZWUVSUk9SX1ZFUkJP
U0UgKi8KIAotCiAvKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLgogfCBSZWxlYXNlIHRoZSBtZW1vcnkgYXNzb2NpYXRlZCB0byB0aGlzIHN5bWJvbC4gIHwK
IGAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovCkBAIC0x
MDYyLDM5ICsxMTE2LDY3IEBAIHl5ZGVzdHJ1Y3QgKHl5bXNnLCB5eXR5cGUsIHl5dmFsdWVwLCB5
eWwKICAgc3dpdGNoICh5eXR5cGUpCiAgICAgewogICAgICAgY2FzZSAzOiAvKiAiSURFTlQiICov
CisKKy8qIExpbmUgMTM5MSBvZiB5YWNjLmMgICovCiAjbGluZSA0MCAibGlieGx1X2NmZ195Lnki
CiAJeyBmcmVlKCh5eXZhbHVlcC0+c3RyaW5nKSk7IH07Ci0jbGluZSAxMDY4ICJsaWJ4bHVfY2Zn
X3kuYyIKKworLyogTGluZSAxMzkxIG9mIHlhY2MuYyAgKi8KKyNsaW5lIDExMjYgImxpYnhsdV9j
ZmdfeS5jIgogCWJyZWFrOwogICAgICAgY2FzZSA0OiAvKiAiU1RSSU5HIiAqLworCisvKiBMaW5l
IDEzOTEgb2YgeWFjYy5jICAqLwogI2xpbmUgNDAgImxpYnhsdV9jZmdfeS55IgogCXsgZnJlZSgo
eXl2YWx1ZXAtPnN0cmluZykpOyB9OwotI2xpbmUgMTA3MyAibGlieGx1X2NmZ195LmMiCisKKy8q
IExpbmUgMTM5MSBvZiB5YWNjLmMgICovCisjbGluZSAxMTM1ICJsaWJ4bHVfY2ZnX3kuYyIKIAli
cmVhazsKICAgICAgIGNhc2UgNTogLyogIk5VTUJFUiIgKi8KKworLyogTGluZSAxMzkxIG9mIHlh
Y2MuYyAgKi8KICNsaW5lIDQwICJsaWJ4bHVfY2ZnX3kueSIKIAl7IGZyZWUoKHl5dmFsdWVwLT5z
dHJpbmcpKTsgfTsKLSNsaW5lIDEwNzggImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDEzOTEg
b2YgeWFjYy5jICAqLworI2xpbmUgMTE0NCAibGlieGx1X2NmZ195LmMiCiAJYnJlYWs7CiAgICAg
ICBjYXNlIDE3OiAvKiAidmFsdWUiICovCisKKy8qIExpbmUgMTM5MSBvZiB5YWNjLmMgICovCiAj
bGluZSA0MyAibGlieGx1X2NmZ195LnkiCiAJeyB4bHVfX2NmZ19zZXRfZnJlZSgoeXl2YWx1ZXAt
PnNldHRpbmcpKTsgfTsKLSNsaW5lIDEwODMgImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDEz
OTEgb2YgeWFjYy5jICAqLworI2xpbmUgMTE1MyAibGlieGx1X2NmZ195LmMiCiAJYnJlYWs7CiAg
ICAgICBjYXNlIDE4OiAvKiAiYXRvbSIgKi8KKworLyogTGluZSAxMzkxIG9mIHlhY2MuYyAgKi8K
ICNsaW5lIDQwICJsaWJ4bHVfY2ZnX3kueSIKIAl7IGZyZWUoKHl5dmFsdWVwLT5zdHJpbmcpKTsg
fTsKLSNsaW5lIDEwODggImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDEzOTEgb2YgeWFjYy5j
ICAqLworI2xpbmUgMTE2MiAibGlieGx1X2NmZ195LmMiCiAJYnJlYWs7CiAgICAgICBjYXNlIDE5
OiAvKiAidmFsdWVsaXN0IiAqLworCisvKiBMaW5lIDEzOTEgb2YgeWFjYy5jICAqLwogI2xpbmUg
NDMgImxpYnhsdV9jZmdfeS55IgogCXsgeGx1X19jZmdfc2V0X2ZyZWUoKHl5dmFsdWVwLT5zZXR0
aW5nKSk7IH07Ci0jbGluZSAxMDkzICJsaWJ4bHVfY2ZnX3kuYyIKKworLyogTGluZSAxMzkxIG9m
IHlhY2MuYyAgKi8KKyNsaW5lIDExNzEgImxpYnhsdV9jZmdfeS5jIgogCWJyZWFrOwogICAgICAg
Y2FzZSAyMDogLyogInZhbHVlcyIgKi8KKworLyogTGluZSAxMzkxIG9mIHlhY2MuYyAgKi8KICNs
aW5lIDQzICJsaWJ4bHVfY2ZnX3kueSIKIAl7IHhsdV9fY2ZnX3NldF9mcmVlKCh5eXZhbHVlcC0+
c2V0dGluZykpOyB9OwotI2xpbmUgMTA5OCAibGlieGx1X2NmZ195LmMiCisKKy8qIExpbmUgMTM5
MSBvZiB5YWNjLmMgICovCisjbGluZSAxMTgwICJsaWJ4bHVfY2ZnX3kuYyIKIAlicmVhazsKIAog
ICAgICAgZGVmYXVsdDoKQEAgLTExMDQsNyArMTE4Niw2IEBAIHl5ZGVzdHJ1Y3QgKHl5bXNnLCB5
eXR5cGUsIHl5dmFsdWVwLCB5eWwKIAogCiAvKiBQcmV2ZW50IHdhcm5pbmdzIGZyb20gLVdtaXNz
aW5nLXByb3RvdHlwZXMuICAqLwotCiAjaWZkZWYgWVlQQVJTRV9QQVJBTQogI2lmIGRlZmluZWQg
X19TVERDX18gfHwgZGVmaW5lZCBfX2NwbHVzcGx1cwogaW50IHl5cGFyc2UgKHZvaWQgKllZUEFS
U0VfUEFSQU0pOwpAQCAtMTEyMCwxMCArMTIwMSw2IEBAIGludCB5eXBhcnNlICgpOwogI2VuZGlm
IC8qICEgWVlQQVJTRV9QQVJBTSAqLwogCiAKLQotCi0KLQogLyotLS0tLS0tLS0tLgogfCB5eXBh
cnNlLiAgfAogYC0tLS0tLS0tLS0qLwpAQCAtMTE1MCwyNCArMTIyNyw1OSBAQCB5eXBhcnNlIChj
dHgpCiAjZW5kaWYKICNlbmRpZgogewotICAvKiBUaGUgbG9vay1haGVhZCBzeW1ib2wuICAqLwor
LyogVGhlIGxvb2thaGVhZCBzeW1ib2wuICAqLwogaW50IHl5Y2hhcjsKIAotLyogVGhlIHNlbWFu
dGljIHZhbHVlIG9mIHRoZSBsb29rLWFoZWFkIHN5bWJvbC4gICovCisvKiBUaGUgc2VtYW50aWMg
dmFsdWUgb2YgdGhlIGxvb2thaGVhZCBzeW1ib2wuICAqLwogWVlTVFlQRSB5eWx2YWw7CiAKLS8q
IE51bWJlciBvZiBzeW50YXggZXJyb3JzIHNvIGZhci4gICovCi1pbnQgeXluZXJyczsKLS8qIExv
Y2F0aW9uIGRhdGEgZm9yIHRoZSBsb29rLWFoZWFkIHN5bWJvbC4gICovCisvKiBMb2NhdGlvbiBk
YXRhIGZvciB0aGUgbG9va2FoZWFkIHN5bWJvbC4gICovCiBZWUxUWVBFIHl5bGxvYzsKIAotICBp
bnQgeXlzdGF0ZTsKKyAgICAvKiBOdW1iZXIgb2Ygc3ludGF4IGVycm9ycyBzbyBmYXIuICAqLwor
ICAgIGludCB5eW5lcnJzOworCisgICAgaW50IHl5c3RhdGU7CisgICAgLyogTnVtYmVyIG9mIHRv
a2VucyB0byBzaGlmdCBiZWZvcmUgZXJyb3IgbWVzc2FnZXMgZW5hYmxlZC4gICovCisgICAgaW50
IHl5ZXJyc3RhdHVzOworCisgICAgLyogVGhlIHN0YWNrcyBhbmQgdGhlaXIgdG9vbHM6CisgICAg
ICAgYHl5c3MnOiByZWxhdGVkIHRvIHN0YXRlcy4KKyAgICAgICBgeXl2cyc6IHJlbGF0ZWQgdG8g
c2VtYW50aWMgdmFsdWVzLgorICAgICAgIGB5eWxzJzogcmVsYXRlZCB0byBsb2NhdGlvbnMuCisK
KyAgICAgICBSZWZlciB0byB0aGUgc3RhY2tzIHRocnUgc2VwYXJhdGUgcG9pbnRlcnMsIHRvIGFs
bG93IHl5b3ZlcmZsb3cKKyAgICAgICB0byByZWFsbG9jYXRlIHRoZW0gZWxzZXdoZXJlLiAgKi8K
KworICAgIC8qIFRoZSBzdGF0ZSBzdGFjay4gICovCisgICAgeXl0eXBlX2ludDE2IHl5c3NhW1lZ
SU5JVERFUFRIXTsKKyAgICB5eXR5cGVfaW50MTYgKnl5c3M7CisgICAgeXl0eXBlX2ludDE2ICp5
eXNzcDsKKworICAgIC8qIFRoZSBzZW1hbnRpYyB2YWx1ZSBzdGFjay4gICovCisgICAgWVlTVFlQ
RSB5eXZzYVtZWUlOSVRERVBUSF07CisgICAgWVlTVFlQRSAqeXl2czsKKyAgICBZWVNUWVBFICp5
eXZzcDsKKworICAgIC8qIFRoZSBsb2NhdGlvbiBzdGFjay4gICovCisgICAgWVlMVFlQRSB5eWxz
YVtZWUlOSVRERVBUSF07CisgICAgWVlMVFlQRSAqeXlsczsKKyAgICBZWUxUWVBFICp5eWxzcDsK
KworICAgIC8qIFRoZSBsb2NhdGlvbnMgd2hlcmUgdGhlIGVycm9yIHN0YXJ0ZWQgYW5kIGVuZGVk
LiAgKi8KKyAgICBZWUxUWVBFIHl5ZXJyb3JfcmFuZ2VbM107CisKKyAgICBZWVNJWkVfVCB5eXN0
YWNrc2l6ZTsKKwogICBpbnQgeXluOwogICBpbnQgeXlyZXN1bHQ7Ci0gIC8qIE51bWJlciBvZiB0
b2tlbnMgdG8gc2hpZnQgYmVmb3JlIGVycm9yIG1lc3NhZ2VzIGVuYWJsZWQuICAqLwotICBpbnQg
eXllcnJzdGF0dXM7Ci0gIC8qIExvb2stYWhlYWQgdG9rZW4gYXMgYW4gaW50ZXJuYWwgKHRyYW5z
bGF0ZWQpIHRva2VuIG51bWJlci4gICovCi0gIGludCB5eXRva2VuID0gMDsKKyAgLyogTG9va2Fo
ZWFkIHRva2VuIGFzIGFuIGludGVybmFsICh0cmFuc2xhdGVkKSB0b2tlbiBudW1iZXIuICAqLwor
ICBpbnQgeXl0b2tlbjsKKyAgLyogVGhlIHZhcmlhYmxlcyB1c2VkIHRvIHJldHVybiBzZW1hbnRp
YyB2YWx1ZSBhbmQgbG9jYXRpb24gZnJvbSB0aGUKKyAgICAgYWN0aW9uIHJvdXRpbmVzLiAgKi8K
KyAgWVlTVFlQRSB5eXZhbDsKKyAgWVlMVFlQRSB5eWxvYzsKKwogI2lmIFlZRVJST1JfVkVSQk9T
RQogICAvKiBCdWZmZXIgZm9yIGVycm9yIG1lc3NhZ2VzLCBhbmQgaXRzIGFsbG9jYXRlZCBzaXpl
LiAgKi8KICAgY2hhciB5eW1zZ2J1ZlsxMjhdOwpAQCAtMTE3NSw2MyArMTI4NywzNyBAQCBZWUxU
WVBFIHl5bGxvYzsKICAgWVlTSVpFX1QgeXltc2dfYWxsb2MgPSBzaXplb2YgeXltc2didWY7CiAj
ZW5kaWYKIAotICAvKiBUaHJlZSBzdGFja3MgYW5kIHRoZWlyIHRvb2xzOgotICAgICBgeXlzcyc6
IHJlbGF0ZWQgdG8gc3RhdGVzLAotICAgICBgeXl2cyc6IHJlbGF0ZWQgdG8gc2VtYW50aWMgdmFs
dWVzLAotICAgICBgeXlscyc6IHJlbGF0ZWQgdG8gbG9jYXRpb25zLgotCi0gICAgIFJlZmVyIHRv
IHRoZSBzdGFja3MgdGhydSBzZXBhcmF0ZSBwb2ludGVycywgdG8gYWxsb3cgeXlvdmVyZmxvdwot
ICAgICB0byByZWFsbG9jYXRlIHRoZW0gZWxzZXdoZXJlLiAgKi8KLQotICAvKiBUaGUgc3RhdGUg
c3RhY2suICAqLwotICB5eXR5cGVfaW50MTYgeXlzc2FbWVlJTklUREVQVEhdOwotICB5eXR5cGVf
aW50MTYgKnl5c3MgPSB5eXNzYTsKLSAgeXl0eXBlX2ludDE2ICp5eXNzcDsKLQotICAvKiBUaGUg
c2VtYW50aWMgdmFsdWUgc3RhY2suICAqLwotICBZWVNUWVBFIHl5dnNhW1lZSU5JVERFUFRIXTsK
LSAgWVlTVFlQRSAqeXl2cyA9IHl5dnNhOwotICBZWVNUWVBFICp5eXZzcDsKLQotICAvKiBUaGUg
bG9jYXRpb24gc3RhY2suICAqLwotICBZWUxUWVBFIHl5bHNhW1lZSU5JVERFUFRIXTsKLSAgWVlM
VFlQRSAqeXlscyA9IHl5bHNhOwotICBZWUxUWVBFICp5eWxzcDsKLSAgLyogVGhlIGxvY2F0aW9u
cyB3aGVyZSB0aGUgZXJyb3Igc3RhcnRlZCBhbmQgZW5kZWQuICAqLwotICBZWUxUWVBFIHl5ZXJy
b3JfcmFuZ2VbMl07Ci0KICNkZWZpbmUgWVlQT1BTVEFDSyhOKSAgICh5eXZzcCAtPSAoTiksIHl5
c3NwIC09IChOKSwgeXlsc3AgLT0gKE4pKQogCi0gIFlZU0laRV9UIHl5c3RhY2tzaXplID0gWVlJ
TklUREVQVEg7Ci0KLSAgLyogVGhlIHZhcmlhYmxlcyB1c2VkIHRvIHJldHVybiBzZW1hbnRpYyB2
YWx1ZSBhbmQgbG9jYXRpb24gZnJvbSB0aGUKLSAgICAgYWN0aW9uIHJvdXRpbmVzLiAgKi8KLSAg
WVlTVFlQRSB5eXZhbDsKLSAgWVlMVFlQRSB5eWxvYzsKLQogICAvKiBUaGUgbnVtYmVyIG9mIHN5
bWJvbHMgb24gdGhlIFJIUyBvZiB0aGUgcmVkdWNlZCBydWxlLgogICAgICBLZWVwIHRvIHplcm8g
d2hlbiBubyBzeW1ib2wgc2hvdWxkIGJlIHBvcHBlZC4gICovCiAgIGludCB5eWxlbiA9IDA7CiAK
KyAgeXl0b2tlbiA9IDA7CisgIHl5c3MgPSB5eXNzYTsKKyAgeXl2cyA9IHl5dnNhOworICB5eWxz
ID0geXlsc2E7CisgIHl5c3RhY2tzaXplID0gWVlJTklUREVQVEg7CisKICAgWVlEUFJJTlRGICgo
c3RkZXJyLCAiU3RhcnRpbmcgcGFyc2VcbiIpKTsKIAogICB5eXN0YXRlID0gMDsKICAgeXllcnJz
dGF0dXMgPSAwOwogICB5eW5lcnJzID0gMDsKLSAgeXljaGFyID0gWVlFTVBUWTsJCS8qIENhdXNl
IGEgdG9rZW4gdG8gYmUgcmVhZC4gICovCisgIHl5Y2hhciA9IFlZRU1QVFk7IC8qIENhdXNlIGEg
dG9rZW4gdG8gYmUgcmVhZC4gICovCiAKICAgLyogSW5pdGlhbGl6ZSBzdGFjayBwb2ludGVycy4K
ICAgICAgV2FzdGUgb25lIGVsZW1lbnQgb2YgdmFsdWUgYW5kIGxvY2F0aW9uIHN0YWNrCiAgICAg
IHNvIHRoYXQgdGhleSBzdGF5IG9uIHRoZSBzYW1lIGxldmVsIGFzIHRoZSBzdGF0ZSBzdGFjay4K
ICAgICAgVGhlIHdhc3RlZCBlbGVtZW50cyBhcmUgbmV2ZXIgaW5pdGlhbGl6ZWQuICAqLwotCiAg
IHl5c3NwID0geXlzczsKICAgeXl2c3AgPSB5eXZzOwogICB5eWxzcCA9IHl5bHM7Ci0jaWYgWVlM
VFlQRV9JU19UUklWSUFMCisKKyNpZiBkZWZpbmVkIFlZTFRZUEVfSVNfVFJJVklBTCAmJiBZWUxU
WVBFX0lTX1RSSVZJQUwKICAgLyogSW5pdGlhbGl6ZSB0aGUgZGVmYXVsdCBsb2NhdGlvbiBiZWZv
cmUgcGFyc2luZyBzdGFydHMuICAqLwogICB5eWxsb2MuZmlyc3RfbGluZSAgID0geXlsbG9jLmxh
c3RfbGluZSAgID0gMTsKLSAgeXlsbG9jLmZpcnN0X2NvbHVtbiA9IHl5bGxvYy5sYXN0X2NvbHVt
biA9IDA7CisgIHl5bGxvYy5maXJzdF9jb2x1bW4gPSB5eWxsb2MubGFzdF9jb2x1bW4gPSAxOwog
I2VuZGlmCiAKICAgZ290byB5eXNldHN0YXRlOwpAQCAtMTI3MCw2ICsxMzU2LDcgQEAgWVlMVFlQ
RSB5eWxsb2M7CiAJCSAgICAmeXl2czEsIHl5c2l6ZSAqIHNpemVvZiAoKnl5dnNwKSwKIAkJICAg
ICZ5eWxzMSwgeXlzaXplICogc2l6ZW9mICgqeXlsc3ApLAogCQkgICAgJnl5c3RhY2tzaXplKTsK
KwogCXl5bHMgPSB5eWxzMTsKIAl5eXNzID0geXlzczE7CiAJeXl2cyA9IHl5dnMxOwpAQCAtMTI5
MSw5ICsxMzc4LDkgQEAgWVlMVFlQRSB5eWxsb2M7CiAJICAodW5pb24geXlhbGxvYyAqKSBZWVNU
QUNLX0FMTE9DIChZWVNUQUNLX0JZVEVTICh5eXN0YWNrc2l6ZSkpOwogCWlmICghIHl5cHRyKQog
CSAgZ290byB5eWV4aGF1c3RlZGxhYjsKLQlZWVNUQUNLX1JFTE9DQVRFICh5eXNzKTsKLQlZWVNU
QUNLX1JFTE9DQVRFICh5eXZzKTsKLQlZWVNUQUNLX1JFTE9DQVRFICh5eWxzKTsKKwlZWVNUQUNL
X1JFTE9DQVRFICh5eXNzX2FsbG9jLCB5eXNzKTsKKwlZWVNUQUNLX1JFTE9DQVRFICh5eXZzX2Fs
bG9jLCB5eXZzKTsKKwlZWVNUQUNLX1JFTE9DQVRFICh5eWxzX2FsbG9jLCB5eWxzKTsKICMgIHVu
ZGVmIFlZU1RBQ0tfUkVMT0NBVEUKIAlpZiAoeXlzczEgIT0geXlzc2EpCiAJICBZWVNUQUNLX0ZS
RUUgKHl5c3MxKTsKQEAgLTEzMTQsNiArMTQwMSw5IEBAIFlZTFRZUEUgeXlsbG9jOwogCiAgIFlZ
RFBSSU5URiAoKHN0ZGVyciwgIkVudGVyaW5nIHN0YXRlICVkXG4iLCB5eXN0YXRlKSk7CiAKKyAg
aWYgKHl5c3RhdGUgPT0gWVlGSU5BTCkKKyAgICBZWUFDQ0VQVDsKKwogICBnb3RvIHl5YmFja3Vw
OwogCiAvKi0tLS0tLS0tLS0tLgpAQCAtMTMyMiwxNiArMTQxMiwxNiBAQCBZWUxUWVBFIHl5bGxv
YzsKIHl5YmFja3VwOgogCiAgIC8qIERvIGFwcHJvcHJpYXRlIHByb2Nlc3NpbmcgZ2l2ZW4gdGhl
IGN1cnJlbnQgc3RhdGUuICBSZWFkIGEKLSAgICAgbG9vay1haGVhZCB0b2tlbiBpZiB3ZSBuZWVk
IG9uZSBhbmQgZG9uJ3QgYWxyZWFkeSBoYXZlIG9uZS4gICovCisgICAgIGxvb2thaGVhZCB0b2tl
biBpZiB3ZSBuZWVkIG9uZSBhbmQgZG9uJ3QgYWxyZWFkeSBoYXZlIG9uZS4gICovCiAKLSAgLyog
Rmlyc3QgdHJ5IHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGhvdXQgcmVmZXJlbmNlIHRvIGxvb2st
YWhlYWQgdG9rZW4uICAqLworICAvKiBGaXJzdCB0cnkgdG8gZGVjaWRlIHdoYXQgdG8gZG8gd2l0
aG91dCByZWZlcmVuY2UgdG8gbG9va2FoZWFkIHRva2VuLiAgKi8KICAgeXluID0geXlwYWN0W3l5
c3RhdGVdOwotICBpZiAoeXluID09IFlZUEFDVF9OSU5GKQorICBpZiAoeXlwYWN0X3ZhbHVlX2lz
X2RlZmF1bHQgKHl5bikpCiAgICAgZ290byB5eWRlZmF1bHQ7CiAKLSAgLyogTm90IGtub3duID0+
IGdldCBhIGxvb2stYWhlYWQgdG9rZW4gaWYgZG9uJ3QgYWxyZWFkeSBoYXZlIG9uZS4gICovCisg
IC8qIE5vdCBrbm93biA9PiBnZXQgYSBsb29rYWhlYWQgdG9rZW4gaWYgZG9uJ3QgYWxyZWFkeSBo
YXZlIG9uZS4gICovCiAKLSAgLyogWVlDSEFSIGlzIGVpdGhlciBZWUVNUFRZIG9yIFlZRU9GIG9y
IGEgdmFsaWQgbG9vay1haGVhZCBzeW1ib2wuICAqLworICAvKiBZWUNIQVIgaXMgZWl0aGVyIFlZ
RU1QVFkgb3IgWVlFT0Ygb3IgYSB2YWxpZCBsb29rYWhlYWQgc3ltYm9sLiAgKi8KICAgaWYgKHl5
Y2hhciA9PSBZWUVNUFRZKQogICAgIHsKICAgICAgIFlZRFBSSU5URiAoKHN0ZGVyciwgIlJlYWRp
bmcgYSB0b2tlbjogIikpOwpAQCAtMTM1NywyNiArMTQ0NywyMiBAQCB5eWJhY2t1cDoKICAgeXlu
ID0geXl0YWJsZVt5eW5dOwogICBpZiAoeXluIDw9IDApCiAgICAgewotICAgICAgaWYgKHl5biA9
PSAwIHx8IHl5biA9PSBZWVRBQkxFX05JTkYpCi0JZ290byB5eWVycmxhYjsKKyAgICAgIGlmICh5
eXRhYmxlX3ZhbHVlX2lzX2Vycm9yICh5eW4pKQorICAgICAgICBnb3RvIHl5ZXJybGFiOwogICAg
ICAgeXluID0gLXl5bjsKICAgICAgIGdvdG8geXlyZWR1Y2U7CiAgICAgfQogCi0gIGlmICh5eW4g
PT0gWVlGSU5BTCkKLSAgICBZWUFDQ0VQVDsKLQogICAvKiBDb3VudCB0b2tlbnMgc2hpZnRlZCBz
aW5jZSBlcnJvcjsgYWZ0ZXIgdGhyZWUsIHR1cm4gb2ZmIGVycm9yCiAgICAgIHN0YXR1cy4gICov
CiAgIGlmICh5eWVycnN0YXR1cykKICAgICB5eWVycnN0YXR1cy0tOwogCi0gIC8qIFNoaWZ0IHRo
ZSBsb29rLWFoZWFkIHRva2VuLiAgKi8KKyAgLyogU2hpZnQgdGhlIGxvb2thaGVhZCB0b2tlbi4g
ICovCiAgIFlZX1NZTUJPTF9QUklOVCAoIlNoaWZ0aW5nIiwgeXl0b2tlbiwgJnl5bHZhbCwgJnl5
bGxvYyk7CiAKLSAgLyogRGlzY2FyZCB0aGUgc2hpZnRlZCB0b2tlbiB1bmxlc3MgaXQgaXMgZW9m
LiAgKi8KLSAgaWYgKHl5Y2hhciAhPSBZWUVPRikKLSAgICB5eWNoYXIgPSBZWUVNUFRZOworICAv
KiBEaXNjYXJkIHRoZSBzaGlmdGVkIHRva2VuLiAgKi8KKyAgeXljaGFyID0gWVlFTVBUWTsKIAog
ICB5eXN0YXRlID0geXluOwogICAqKyt5eXZzcCA9IHl5bHZhbDsKQEAgLTE0MTcsNjAgKzE1MDMs
OTIgQEAgeXlyZWR1Y2U6CiAgIHN3aXRjaCAoeXluKQogICAgIHsKICAgICAgICAgY2FzZSA0Ogor
CisvKiBMaW5lIDE4MDYgb2YgeWFjYy5jICAqLwogI2xpbmUgNTAgImxpYnhsdV9jZmdfeS55Igot
ICAgIHsgeGx1X19jZmdfc2V0X3N0b3JlKGN0eCwoeXl2c3BbKDEpIC0gKDMpXS5zdHJpbmcpLCh5
eXZzcFsoMykgLSAoMyldLnNldHRpbmcpLCh5eWxzcFsoMykgLSAoMyldKS5maXJzdF9saW5lKTsg
O30KKyAgICB7IHhsdV9fY2ZnX3NldF9zdG9yZShjdHgsKHl5dnNwWygxKSAtICgzKV0uc3RyaW5n
KSwoeXl2c3BbKDMpIC0gKDMpXS5zZXR0aW5nKSwoeXlsc3BbKDMpIC0gKDMpXSkuZmlyc3RfbGlu
ZSk7IH0KICAgICBicmVhazsKIAogICBjYXNlIDEwOgorCisvKiBMaW5lIDE4MDYgb2YgeWFjYy5j
ICAqLwogI2xpbmUgNTggImxpYnhsdV9jZmdfeS55IgotICAgIHsgKHl5dmFsLnNldHRpbmcpPSB4
bHVfX2NmZ19zZXRfbWsoY3R4LDEsKHl5dnNwWygxKSAtICgxKV0uc3RyaW5nKSk7IDt9CisgICAg
eyAoeXl2YWwuc2V0dGluZyk9IHhsdV9fY2ZnX3NldF9tayhjdHgsMSwoeXl2c3BbKDEpIC0gKDEp
XS5zdHJpbmcpKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2UgMTE6CisKKy8qIExpbmUgMTgwNiBv
ZiB5YWNjLmMgICovCiAjbGluZSA1OSAibGlieGx1X2NmZ195LnkiCi0gICAgeyAoeXl2YWwuc2V0
dGluZyk9ICh5eXZzcFsoMykgLSAoNCldLnNldHRpbmcpOyA7fQorICAgIHsgKHl5dmFsLnNldHRp
bmcpPSAoeXl2c3BbKDMpIC0gKDQpXS5zZXR0aW5nKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2Ug
MTI6CisKKy8qIExpbmUgMTgwNiBvZiB5YWNjLmMgICovCiAjbGluZSA2MSAibGlieGx1X2NmZ195
LnkiCi0gICAgeyAoeXl2YWwuc3RyaW5nKT0gKHl5dnNwWygxKSAtICgxKV0uc3RyaW5nKTsgO30K
KyAgICB7ICh5eXZhbC5zdHJpbmcpPSAoeXl2c3BbKDEpIC0gKDEpXS5zdHJpbmcpOyB9CiAgICAg
YnJlYWs7CiAKICAgY2FzZSAxMzoKKworLyogTGluZSAxODA2IG9mIHlhY2MuYyAgKi8KICNsaW5l
IDYyICJsaWJ4bHVfY2ZnX3kueSIKLSAgICB7ICh5eXZhbC5zdHJpbmcpPSAoeXl2c3BbKDEpIC0g
KDEpXS5zdHJpbmcpOyA7fQorICAgIHsgKHl5dmFsLnN0cmluZyk9ICh5eXZzcFsoMSkgLSAoMSld
LnN0cmluZyk7IH0KICAgICBicmVhazsKIAogICBjYXNlIDE0OgorCisvKiBMaW5lIDE4MDYgb2Yg
eWFjYy5jICAqLwogI2xpbmUgNjQgImxpYnhsdV9jZmdfeS55IgotICAgIHsgKHl5dmFsLnNldHRp
bmcpPSB4bHVfX2NmZ19zZXRfbWsoY3R4LDAsMCk7IDt9CisgICAgeyAoeXl2YWwuc2V0dGluZyk9
IHhsdV9fY2ZnX3NldF9tayhjdHgsMCwwKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2UgMTU6CisK
Ky8qIExpbmUgMTgwNiBvZiB5YWNjLmMgICovCiAjbGluZSA2NSAibGlieGx1X2NmZ195LnkiCi0g
ICAgeyAoeXl2YWwuc2V0dGluZyk9ICh5eXZzcFsoMSkgLSAoMSldLnNldHRpbmcpOyA7fQorICAg
IHsgKHl5dmFsLnNldHRpbmcpPSAoeXl2c3BbKDEpIC0gKDEpXS5zZXR0aW5nKTsgfQogICAgIGJy
ZWFrOwogCiAgIGNhc2UgMTY6CisKKy8qIExpbmUgMTgwNiBvZiB5YWNjLmMgICovCiAjbGluZSA2
NiAibGlieGx1X2NmZ195LnkiCi0gICAgeyAoeXl2YWwuc2V0dGluZyk9ICh5eXZzcFsoMSkgLSAo
MyldLnNldHRpbmcpOyA7fQorICAgIHsgKHl5dmFsLnNldHRpbmcpPSAoeXl2c3BbKDEpIC0gKDMp
XS5zZXR0aW5nKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2UgMTc6CisKKy8qIExpbmUgMTgwNiBv
ZiB5YWNjLmMgICovCiAjbGluZSA2OCAibGlieGx1X2NmZ195LnkiCi0gICAgeyAoeXl2YWwuc2V0
dGluZyk9IHhsdV9fY2ZnX3NldF9tayhjdHgsMiwoeXl2c3BbKDEpIC0gKDIpXS5zdHJpbmcpKTsg
O30KKyAgICB7ICh5eXZhbC5zZXR0aW5nKT0geGx1X19jZmdfc2V0X21rKGN0eCwyLCh5eXZzcFso
MSkgLSAoMildLnN0cmluZykpOyB9CiAgICAgYnJlYWs7CiAKICAgY2FzZSAxODoKKworLyogTGlu
ZSAxODA2IG9mIHlhY2MuYyAgKi8KICNsaW5lIDY5ICJsaWJ4bHVfY2ZnX3kueSIKLSAgICB7IHhs
dV9fY2ZnX3NldF9hZGQoY3R4LCh5eXZzcFsoMSkgLSAoNSldLnNldHRpbmcpLCh5eXZzcFsoNCkg
LSAoNSldLnN0cmluZykpOyAoeXl2YWwuc2V0dGluZyk9ICh5eXZzcFsoMSkgLSAoNSldLnNldHRp
bmcpOyA7fQorICAgIHsgeGx1X19jZmdfc2V0X2FkZChjdHgsKHl5dnNwWygxKSAtICg1KV0uc2V0
dGluZyksKHl5dnNwWyg0KSAtICg1KV0uc3RyaW5nKSk7ICh5eXZhbC5zZXR0aW5nKT0gKHl5dnNw
WygxKSAtICg1KV0uc2V0dGluZyk7IH0KICAgICBicmVhazsKIAogCi0vKiBMaW5lIDEyNjcgb2Yg
eWFjYy5jLiAgKi8KLSNsaW5lIDE0NzIgImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDE4MDYg
b2YgeWFjYy5jICAqLworI2xpbmUgMTU3OSAibGlieGx1X2NmZ195LmMiCiAgICAgICBkZWZhdWx0
OiBicmVhazsKICAgICB9CisgIC8qIFVzZXIgc2VtYW50aWMgYWN0aW9ucyBzb21ldGltZXMgYWx0
ZXIgeXljaGFyLCBhbmQgdGhhdCByZXF1aXJlcworICAgICB0aGF0IHl5dG9rZW4gYmUgdXBkYXRl
ZCB3aXRoIHRoZSBuZXcgdHJhbnNsYXRpb24uICBXZSB0YWtlIHRoZQorICAgICBhcHByb2FjaCBv
ZiB0cmFuc2xhdGluZyBpbW1lZGlhdGVseSBiZWZvcmUgZXZlcnkgdXNlIG9mIHl5dG9rZW4uCisg
ICAgIE9uZSBhbHRlcm5hdGl2ZSBpcyB0cmFuc2xhdGluZyBoZXJlIGFmdGVyIGV2ZXJ5IHNlbWFu
dGljIGFjdGlvbiwKKyAgICAgYnV0IHRoYXQgdHJhbnNsYXRpb24gd291bGQgYmUgbWlzc2VkIGlm
IHRoZSBzZW1hbnRpYyBhY3Rpb24gaW52b2tlcworICAgICBZWUFCT1JULCBZWUFDQ0VQVCwgb3Ig
WVlFUlJPUiBpbW1lZGlhdGVseSBhZnRlciBhbHRlcmluZyB5eWNoYXIgb3IKKyAgICAgaWYgaXQg
aW52b2tlcyBZWUJBQ0tVUC4gIEluIHRoZSBjYXNlIG9mIFlZQUJPUlQgb3IgWVlBQ0NFUFQsIGFu
CisgICAgIGluY29ycmVjdCBkZXN0cnVjdG9yIG1pZ2h0IHRoZW4gYmUgaW52b2tlZCBpbW1lZGlh
dGVseS4gIEluIHRoZQorICAgICBjYXNlIG9mIFlZRVJST1Igb3IgWVlCQUNLVVAsIHN1YnNlcXVl
bnQgcGFyc2VyIGFjdGlvbnMgbWlnaHQgbGVhZAorICAgICB0byBhbiBpbmNvcnJlY3QgZGVzdHJ1
Y3RvciBjYWxsIG9yIHZlcmJvc2Ugc3ludGF4IGVycm9yIG1lc3NhZ2UKKyAgICAgYmVmb3JlIHRo
ZSBsb29rYWhlYWQgaXMgdHJhbnNsYXRlZC4gICovCiAgIFlZX1NZTUJPTF9QUklOVCAoIi0+ICQk
ID0iLCB5eXIxW3l5bl0sICZ5eXZhbCwgJnl5bG9jKTsKIAogICBZWVBPUFNUQUNLICh5eWxlbik7
CkBAIC0xNDk5LDYgKzE2MTcsMTAgQEAgeXlyZWR1Y2U6CiB8IHl5ZXJybGFiIC0tIGhlcmUgb24g
ZGV0ZWN0aW5nIGVycm9yIHwKIGAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0q
LwogeXllcnJsYWI6CisgIC8qIE1ha2Ugc3VyZSB3ZSBoYXZlIGxhdGVzdCBsb29rYWhlYWQgdHJh
bnNsYXRpb24uICBTZWUgY29tbWVudHMgYXQKKyAgICAgdXNlciBzZW1hbnRpYyBhY3Rpb25zIGZv
ciB3aHkgdGhpcyBpcyBuZWNlc3NhcnkuICAqLworICB5eXRva2VuID0geXljaGFyID09IFlZRU1Q
VFkgPyBZWUVNUFRZIDogWVlUUkFOU0xBVEUgKHl5Y2hhcik7CisKICAgLyogSWYgbm90IGFscmVh
ZHkgcmVjb3ZlcmluZyBmcm9tIGFuIGVycm9yLCByZXBvcnQgdGhpcyBlcnJvci4gICovCiAgIGlm
ICgheXllcnJzdGF0dXMpCiAgICAgewpAQCAtMTUwNiw0NSArMTYyOCw0NCBAQCB5eWVycmxhYjoK
ICNpZiAhIFlZRVJST1JfVkVSQk9TRQogICAgICAgeXllcnJvciAoJnl5bGxvYywgY3R4LCBZWV8o
InN5bnRheCBlcnJvciIpKTsKICNlbHNlCisjIGRlZmluZSBZWVNZTlRBWF9FUlJPUiB5eXN5bnRh
eF9lcnJvciAoJnl5bXNnX2FsbG9jLCAmeXltc2csIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB5eXNzcCwgeXl0b2tlbikKICAgICAgIHsKLQlZWVNJWkVfVCB5eXNp
emUgPSB5eXN5bnRheF9lcnJvciAoMCwgeXlzdGF0ZSwgeXljaGFyKTsKLQlpZiAoeXltc2dfYWxs
b2MgPCB5eXNpemUgJiYgeXltc2dfYWxsb2MgPCBZWVNUQUNLX0FMTE9DX01BWElNVU0pCi0JICB7
Ci0JICAgIFlZU0laRV9UIHl5YWxsb2MgPSAyICogeXlzaXplOwotCSAgICBpZiAoISAoeXlzaXpl
IDw9IHl5YWxsb2MgJiYgeXlhbGxvYyA8PSBZWVNUQUNLX0FMTE9DX01BWElNVU0pKQotCSAgICAg
IHl5YWxsb2MgPSBZWVNUQUNLX0FMTE9DX01BWElNVU07Ci0JICAgIGlmICh5eW1zZyAhPSB5eW1z
Z2J1ZikKLQkgICAgICBZWVNUQUNLX0ZSRUUgKHl5bXNnKTsKLQkgICAgeXltc2cgPSAoY2hhciAq
KSBZWVNUQUNLX0FMTE9DICh5eWFsbG9jKTsKLQkgICAgaWYgKHl5bXNnKQotCSAgICAgIHl5bXNn
X2FsbG9jID0geXlhbGxvYzsKLQkgICAgZWxzZQotCSAgICAgIHsKLQkJeXltc2cgPSB5eW1zZ2J1
ZjsKLQkJeXltc2dfYWxsb2MgPSBzaXplb2YgeXltc2didWY7Ci0JICAgICAgfQotCSAgfQotCi0J
aWYgKDAgPCB5eXNpemUgJiYgeXlzaXplIDw9IHl5bXNnX2FsbG9jKQotCSAgewotCSAgICAodm9p
ZCkgeXlzeW50YXhfZXJyb3IgKHl5bXNnLCB5eXN0YXRlLCB5eWNoYXIpOwotCSAgICB5eWVycm9y
ICgmeXlsbG9jLCBjdHgsIHl5bXNnKTsKLQkgIH0KLQllbHNlCi0JICB7Ci0JICAgIHl5ZXJyb3Ig
KCZ5eWxsb2MsIGN0eCwgWVlfKCJzeW50YXggZXJyb3IiKSk7Ci0JICAgIGlmICh5eXNpemUgIT0g
MCkKLQkgICAgICBnb3RvIHl5ZXhoYXVzdGVkbGFiOwotCSAgfQorICAgICAgICBjaGFyIGNvbnN0
ICp5eW1zZ3AgPSBZWV8oInN5bnRheCBlcnJvciIpOworICAgICAgICBpbnQgeXlzeW50YXhfZXJy
b3Jfc3RhdHVzOworICAgICAgICB5eXN5bnRheF9lcnJvcl9zdGF0dXMgPSBZWVNZTlRBWF9FUlJP
UjsKKyAgICAgICAgaWYgKHl5c3ludGF4X2Vycm9yX3N0YXR1cyA9PSAwKQorICAgICAgICAgIHl5
bXNncCA9IHl5bXNnOworICAgICAgICBlbHNlIGlmICh5eXN5bnRheF9lcnJvcl9zdGF0dXMgPT0g
MSkKKyAgICAgICAgICB7CisgICAgICAgICAgICBpZiAoeXltc2cgIT0geXltc2didWYpCisgICAg
ICAgICAgICAgIFlZU1RBQ0tfRlJFRSAoeXltc2cpOworICAgICAgICAgICAgeXltc2cgPSAoY2hh
ciAqKSBZWVNUQUNLX0FMTE9DICh5eW1zZ19hbGxvYyk7CisgICAgICAgICAgICBpZiAoIXl5bXNn
KQorICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgeXltc2cgPSB5eW1zZ2J1ZjsKKyAg
ICAgICAgICAgICAgICB5eW1zZ19hbGxvYyA9IHNpemVvZiB5eW1zZ2J1ZjsKKyAgICAgICAgICAg
ICAgICB5eXN5bnRheF9lcnJvcl9zdGF0dXMgPSAyOworICAgICAgICAgICAgICB9CisgICAgICAg
ICAgICBlbHNlCisgICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICB5eXN5bnRheF9lcnJv
cl9zdGF0dXMgPSBZWVNZTlRBWF9FUlJPUjsKKyAgICAgICAgICAgICAgICB5eW1zZ3AgPSB5eW1z
ZzsKKyAgICAgICAgICAgICAgfQorICAgICAgICAgIH0KKyAgICAgICAgeXllcnJvciAoJnl5bGxv
YywgY3R4LCB5eW1zZ3ApOworICAgICAgICBpZiAoeXlzeW50YXhfZXJyb3Jfc3RhdHVzID09IDIp
CisgICAgICAgICAgZ290byB5eWV4aGF1c3RlZGxhYjsKICAgICAgIH0KKyMgdW5kZWYgWVlTWU5U
QVhfRVJST1IKICNlbmRpZgogICAgIH0KIAotICB5eWVycm9yX3JhbmdlWzBdID0geXlsbG9jOwor
ICB5eWVycm9yX3JhbmdlWzFdID0geXlsbG9jOwogCiAgIGlmICh5eWVycnN0YXR1cyA9PSAzKQog
ICAgIHsKLSAgICAgIC8qIElmIGp1c3QgdHJpZWQgYW5kIGZhaWxlZCB0byByZXVzZSBsb29rLWFo
ZWFkIHRva2VuIGFmdGVyIGFuCisgICAgICAvKiBJZiBqdXN0IHRyaWVkIGFuZCBmYWlsZWQgdG8g
cmV1c2UgbG9va2FoZWFkIHRva2VuIGFmdGVyIGFuCiAJIGVycm9yLCBkaXNjYXJkIGl0LiAgKi8K
IAogICAgICAgaWYgKHl5Y2hhciA8PSBZWUVPRikKQEAgLTE1NjEsNyArMTY4Miw3IEBAIHl5ZXJy
bGFiOgogCX0KICAgICB9CiAKLSAgLyogRWxzZSB3aWxsIHRyeSB0byByZXVzZSBsb29rLWFoZWFk
IHRva2VuIGFmdGVyIHNoaWZ0aW5nIHRoZSBlcnJvcgorICAvKiBFbHNlIHdpbGwgdHJ5IHRvIHJl
dXNlIGxvb2thaGVhZCB0b2tlbiBhZnRlciBzaGlmdGluZyB0aGUgZXJyb3IKICAgICAgdG9rZW4u
ICAqLwogICBnb3RvIHl5ZXJybGFiMTsKIApAQCAtMTU3Nyw3ICsxNjk4LDcgQEAgeXllcnJvcmxh
YjoKICAgaWYgKC8qQ09OU1RDT05EKi8gMCkKICAgICAgZ290byB5eWVycm9ybGFiOwogCi0gIHl5
ZXJyb3JfcmFuZ2VbMF0gPSB5eWxzcFsxLXl5bGVuXTsKKyAgeXllcnJvcl9yYW5nZVsxXSA9IHl5
bHNwWzEteXlsZW5dOwogICAvKiBEbyBub3QgcmVjbGFpbSB0aGUgc3ltYm9scyBvZiB0aGUgcnVs
ZSB3aGljaCBhY3Rpb24gdHJpZ2dlcmVkCiAgICAgIHRoaXMgWVlFUlJPUi4gICovCiAgIFlZUE9Q
U1RBQ0sgKHl5bGVuKTsKQEAgLTE1OTYsNyArMTcxNyw3IEBAIHl5ZXJybGFiMToKICAgZm9yICg7
OykKICAgICB7CiAgICAgICB5eW4gPSB5eXBhY3RbeXlzdGF0ZV07Ci0gICAgICBpZiAoeXluICE9
IFlZUEFDVF9OSU5GKQorICAgICAgaWYgKCF5eXBhY3RfdmFsdWVfaXNfZGVmYXVsdCAoeXluKSkK
IAl7CiAJICB5eW4gKz0gWVlURVJST1I7CiAJICBpZiAoMCA8PSB5eW4gJiYgeXluIDw9IFlZTEFT
VCAmJiB5eWNoZWNrW3l5bl0gPT0gWVlURVJST1IpCkBAIC0xNjExLDcgKzE3MzIsNyBAQCB5eWVy
cmxhYjE6CiAgICAgICBpZiAoeXlzc3AgPT0geXlzcykKIAlZWUFCT1JUOwogCi0gICAgICB5eWVy
cm9yX3JhbmdlWzBdID0gKnl5bHNwOworICAgICAgeXllcnJvcl9yYW5nZVsxXSA9ICp5eWxzcDsK
ICAgICAgIHl5ZGVzdHJ1Y3QgKCJFcnJvcjogcG9wcGluZyIsCiAJCSAgeXlzdG9zW3l5c3RhdGVd
LCB5eXZzcCwgeXlsc3AsIGN0eCk7CiAgICAgICBZWVBPUFNUQUNLICgxKTsKQEAgLTE2MTksMTUg
KzE3NDAsMTIgQEAgeXllcnJsYWIxOgogICAgICAgWVlfU1RBQ0tfUFJJTlQgKHl5c3MsIHl5c3Nw
KTsKICAgICB9CiAKLSAgaWYgKHl5biA9PSBZWUZJTkFMKQotICAgIFlZQUNDRVBUOwotCiAgICor
K3l5dnNwID0geXlsdmFsOwogCi0gIHl5ZXJyb3JfcmFuZ2VbMV0gPSB5eWxsb2M7CisgIHl5ZXJy
b3JfcmFuZ2VbMl0gPSB5eWxsb2M7CiAgIC8qIFVzaW5nIFlZTExPQyBpcyB0ZW1wdGluZywgYnV0
IHdvdWxkIGNoYW5nZSB0aGUgbG9jYXRpb24gb2YKLSAgICAgdGhlIGxvb2stYWhlYWQuICBZWUxP
QyBpcyBhdmFpbGFibGUgdGhvdWdoLiAgKi8KLSAgWVlMTE9DX0RFRkFVTFQgKHl5bG9jLCAoeXll
cnJvcl9yYW5nZSAtIDEpLCAyKTsKKyAgICAgdGhlIGxvb2thaGVhZC4gIFlZTE9DIGlzIGF2YWls
YWJsZSB0aG91Z2guICAqLworICBZWUxMT0NfREVGQVVMVCAoeXlsb2MsIHl5ZXJyb3JfcmFuZ2Us
IDIpOwogICAqKyt5eWxzcCA9IHl5bG9jOwogCiAgIC8qIFNoaWZ0IHRoZSBlcnJvciB0b2tlbi4g
ICovCkBAIC0xNjUxLDcgKzE3NjksNyBAQCB5eWFib3J0bGFiOgogICB5eXJlc3VsdCA9IDE7CiAg
IGdvdG8geXlyZXR1cm47CiAKLSNpZm5kZWYgeXlvdmVyZmxvdworI2lmICFkZWZpbmVkKHl5b3Zl
cmZsb3cpIHx8IFlZRVJST1JfVkVSQk9TRQogLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLgogfCB5eWV4aGF1c3RlZGxhYiAtLSBtZW1vcnkgZXhoYXVz
dGlvbiBjb21lcyBoZXJlLiAgfAogYC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0qLwpAQCAtMTY2Miw5ICsxNzgwLDE0IEBAIHl5ZXhoYXVzdGVkbGFiOgog
I2VuZGlmCiAKIHl5cmV0dXJuOgotICBpZiAoeXljaGFyICE9IFlZRU9GICYmIHl5Y2hhciAhPSBZ
WUVNUFRZKQotICAgICB5eWRlc3RydWN0ICgiQ2xlYW51cDogZGlzY2FyZGluZyBsb29rYWhlYWQi
LAotCQkgeXl0b2tlbiwgJnl5bHZhbCwgJnl5bGxvYywgY3R4KTsKKyAgaWYgKHl5Y2hhciAhPSBZ
WUVNUFRZKQorICAgIHsKKyAgICAgIC8qIE1ha2Ugc3VyZSB3ZSBoYXZlIGxhdGVzdCBsb29rYWhl
YWQgdHJhbnNsYXRpb24uICBTZWUgY29tbWVudHMgYXQKKyAgICAgICAgIHVzZXIgc2VtYW50aWMg
YWN0aW9ucyBmb3Igd2h5IHRoaXMgaXMgbmVjZXNzYXJ5LiAgKi8KKyAgICAgIHl5dG9rZW4gPSBZ
WVRSQU5TTEFURSAoeXljaGFyKTsKKyAgICAgIHl5ZGVzdHJ1Y3QgKCJDbGVhbnVwOiBkaXNjYXJk
aW5nIGxvb2thaGVhZCIsCisgICAgICAgICAgICAgICAgICB5eXRva2VuLCAmeXlsdmFsLCAmeXls
bG9jLCBjdHgpOworICAgIH0KICAgLyogRG8gbm90IHJlY2xhaW0gdGhlIHN5bWJvbHMgb2YgdGhl
IHJ1bGUgd2hpY2ggYWN0aW9uIHRyaWdnZXJlZAogICAgICB0aGlzIFlZQUJPUlQgb3IgWVlBQ0NF
UFQuICAqLwogICBZWVBPUFNUQUNLICh5eWxlbik7CkBAIC0xNjg5LDExICsxODEyLDMgQEAgeXly
ZXR1cm46CiAKIAogCi0KLS8qCi0gKiBMb2NhbCB2YXJpYWJsZXM6Ci0gKiBtb2RlOiBDCi0gKiBj
LWJhc2ljLW9mZnNldDogNAotICogaW5kZW50LXRhYnMtbW9kZTogbmlsCi0gKiBFbmQ6Ci0gKi8K
ZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2xpYnhsL2xpYnhsdV9j
ZmdfeS5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9jZmdfeS5oCUZyaSBGZWIgMTcgMTI6MjQ6
MzggMjAxMiArMDAwMAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfY2ZnX3kuaAlNb24gRmViIDIw
IDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTEsMjQgKzEsMjEgQEAKLS8qIEEgQmlzb24gcGFyc2Vy
LCBtYWRlIGJ5IEdOVSBCaXNvbiAyLjMuICAqLworLyogQSBCaXNvbiBwYXJzZXIsIG1hZGUgYnkg
R05VIEJpc29uIDIuNS4gICovCiAKLS8qIFNrZWxldG9uIGludGVyZmFjZSBmb3IgQmlzb24ncyBZ
YWNjLWxpa2UgcGFyc2VycyBpbiBDCi0KLSAgIENvcHlyaWdodCAoQykgMTk4NCwgMTk4OSwgMTk5
MCwgMjAwMCwgMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNgotICAgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uLCBJbmMuCi0KLSAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisvKiBCaXNvbiBpbnRlcmZh
Y2UgZm9yIFlhY2MtbGlrZSBwYXJzZXJzIGluIEMKKyAgIAorICAgICAgQ29weXJpZ2h0IChDKSAx
OTg0LCAxOTg5LTE5OTAsIDIwMDAtMjAxMSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4K
KyAgIAorICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU6IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkKICAgIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdl
bmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5Ci0gICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyLCBvciAoYXQgeW91ciBvcHRpb24pCi0gICBh
bnkgbGF0ZXIgdmVyc2lvbi4KLQorICAgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgZWl0
aGVyIHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwgb3IKKyAgIChhdCB5b3VyIG9wdGlvbikgYW55
IGxhdGVyIHZlcnNpb24uCisgICAKICAgIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0
aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAogICAgYnV0IFdJVEhPVVQgQU5ZIFdBUlJB
TlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKICAgIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKICAgIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCi0KKyAgIAogICAgWW91
IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UKLSAgIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBG
cmVlIFNvZnR3YXJlCi0gICBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQsIEZp
ZnRoIEZsb29yLAotICAgQm9zdG9uLCBNQSAwMjExMC0xMzAxLCBVU0EuICAqLworICAgYWxvbmcg
d2l0aCB0aGlzIHByb2dyYW0uICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5nbnUub3JnL2xpY2Vu
c2VzLz4uICAqLwogCiAvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCB5b3UgbWF5IGNyZWF0ZSBh
IGxhcmdlciB3b3JrIHRoYXQgY29udGFpbnMKICAgIHBhcnQgb3IgYWxsIG9mIHRoZSBCaXNvbiBw
YXJzZXIgc2tlbGV0b24gYW5kIGRpc3RyaWJ1dGUgdGhhdCB3b3JrCkBAIC0yOSwxMCArMjYsMTEg
QEAKICAgIHNwZWNpYWwgZXhjZXB0aW9uLCB3aGljaCB3aWxsIGNhdXNlIHRoZSBza2VsZXRvbiBh
bmQgdGhlIHJlc3VsdGluZwogICAgQmlzb24gb3V0cHV0IGZpbGVzIHRvIGJlIGxpY2Vuc2VkIHVu
ZGVyIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMKICAgIExpY2Vuc2Ugd2l0aG91dCB0aGlzIHNwZWNp
YWwgZXhjZXB0aW9uLgotCisgICAKICAgIFRoaXMgc3BlY2lhbCBleGNlcHRpb24gd2FzIGFkZGVk
IGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24gaW4KICAgIHZlcnNpb24gMi4yIG9mIEJp
c29uLiAgKi8KIAorCiAvKiBUb2tlbnMuICAqLwogI2lmbmRlZiBZWVRPS0VOVFlQRQogIyBkZWZp
bmUgWVlUT0tFTlRZUEUKQEAgLTQ1LDI4ICs0MywyNyBAQAogICAgICBORVdMSU5FID0gMjYxCiAg
ICB9OwogI2VuZGlmCi0vKiBUb2tlbnMuICAqLwotI2RlZmluZSBJREVOVCAyNTgKLSNkZWZpbmUg
U1RSSU5HIDI1OQotI2RlZmluZSBOVU1CRVIgMjYwCi0jZGVmaW5lIE5FV0xJTkUgMjYxCi0KIAog
CiAKICNpZiAhIGRlZmluZWQgWVlTVFlQRSAmJiAhIGRlZmluZWQgWVlTVFlQRV9JU19ERUNMQVJF
RAogdHlwZWRlZiB1bmlvbiBZWVNUWVBFCit7CisKKy8qIExpbmUgMjA2OCBvZiB5YWNjLmMgICov
CiAjbGluZSAyNSAibGlieGx1X2NmZ195LnkiCi17CisKICAgY2hhciAqc3RyaW5nOwogICBYTFVf
Q29uZmlnU2V0dGluZyAqc2V0dGluZzsKLX0KLS8qIExpbmUgMTQ4OSBvZiB5YWNjLmMuICAqLwot
I2xpbmUgNjYgImxpYnhsdV9jZmdfeS5oIgotCVlZU1RZUEU7CisKKworCisvKiBMaW5lIDIwNjgg
b2YgeWFjYy5jICAqLworI2xpbmUgNjMgImxpYnhsdV9jZmdfeS5oIgorfSBZWVNUWVBFOworIyBk
ZWZpbmUgWVlTVFlQRV9JU19UUklWSUFMIDEKICMgZGVmaW5lIHl5c3R5cGUgWVlTVFlQRSAvKiBv
YnNvbGVzY2VudDsgd2lsbCBiZSB3aXRoZHJhd24gKi8KICMgZGVmaW5lIFlZU1RZUEVfSVNfREVD
TEFSRUQgMQotIyBkZWZpbmUgWVlTVFlQRV9JU19UUklWSUFMIDEKICNlbmRpZgogCiAKQEAgLTg2
LDEwICs4MywzIEBAIHR5cGVkZWYgc3RydWN0IFlZTFRZUEUKIAogCiAKLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiBtb2RlOiBDCi0gKiBjLWJhc2ljLW9mZnNldDogNAotICogaW5kZW50LXRh
YnMtbW9kZTogbmlsCi0gKiBFbmQ6Ci0gKi8KZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjll
ZDhhOTE0IHRvb2xzL2xpYnhsL2xpYnhsdV9kaXNrX2wuYwotLS0gYS90b29scy9saWJ4bC9saWJ4
bHVfZGlza19sLmMJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xp
YnhsL2xpYnhsdV9kaXNrX2wuYwlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTU0
LDYgKzU0LDcgQEAgdHlwZWRlZiBpbnQgZmxleF9pbnQzMl90OwogdHlwZWRlZiB1bnNpZ25lZCBj
aGFyIGZsZXhfdWludDhfdDsgCiB0eXBlZGVmIHVuc2lnbmVkIHNob3J0IGludCBmbGV4X3VpbnQx
Nl90OwogdHlwZWRlZiB1bnNpZ25lZCBpbnQgZmxleF91aW50MzJfdDsKKyNlbmRpZiAvKiAhIEM5
OSAqLwogCiAvKiBMaW1pdHMgb2YgaW50ZWdyYWwgdHlwZXMuICovCiAjaWZuZGVmIElOVDhfTUlO
CkBAIC04NCw4ICs4NSw2IEBAIHR5cGVkZWYgdW5zaWduZWQgaW50IGZsZXhfdWludDMyX3Q7CiAj
ZGVmaW5lIFVJTlQzMl9NQVggICAgICAgICAgICAgKDQyOTQ5NjcyOTVVKQogI2VuZGlmCiAKLSNl
bmRpZiAvKiAhIEM5OSAqLwotCiAjZW5kaWYgLyogISBGTEVYSU5UX0ggKi8KIAogI2lmZGVmIF9f
Y3BsdXNwbHVzCkBAIC0xNTksMTUgKzE1OCw3IEBAIHR5cGVkZWYgdm9pZCogeXlzY2FuX3Q7CiAK
IC8qIFNpemUgb2YgZGVmYXVsdCBpbnB1dCBidWZmZXIuICovCiAjaWZuZGVmIFlZX0JVRl9TSVpF
Ci0jaWZkZWYgX19pYTY0X18KLS8qIE9uIElBLTY0LCB0aGUgYnVmZmVyIHNpemUgaXMgMTZrLCBu
b3QgOGsuCi0gKiBNb3Jlb3ZlciwgWVlfQlVGX1NJWkUgaXMgMipZWV9SRUFEX0JVRl9TSVpFIGlu
IHRoZSBnZW5lcmFsIGNhc2UuCi0gKiBEaXR0byBmb3IgdGhlIF9faWE2NF9fIGNhc2UgYWNjb3Jk
aW5nbHkuCi0gKi8KLSNkZWZpbmUgWVlfQlVGX1NJWkUgMzI3NjgKLSNlbHNlCiAjZGVmaW5lIFlZ
X0JVRl9TSVpFIDE2Mzg0Ci0jZW5kaWYgLyogX19pYTY0X18gKi8KICNlbmRpZgogCiAvKiBUaGUg
c3RhdGUgYnVmIG11c3QgYmUgbGFyZ2UgZW5vdWdoIHRvIGhvbGQgb25lIHN0YXRlIHBlciBjaGFy
YWN0ZXIgaW4gdGhlIG1haW4gYnVmZmVyLgpAQCAtODYwLDcgKzg1MSw3IEBAIHN0YXRpYyB2b2lk
IHNldGJhY2tlbmR0eXBlKERpc2tQYXJzZUNvbnQKICNkZWZpbmUgREVQUkVDQVRFKHVzZXdoYXRp
bnN0ZWFkKSAvKiBub3QgY3VycmVudGx5IHJlcG9ydGVkICovCiAKIAotI2xpbmUgODY0ICJsaWJ4
bHVfZGlza19sLmMiCisjbGluZSA4NTUgImxpYnhsdV9kaXNrX2wuYyIKIAogI2RlZmluZSBJTklU
SUFMIDAKICNkZWZpbmUgTEVYRVJSIDEKQEAgLTk4OSwxMiArOTgwLDcgQEAgc3RhdGljIGludCBp
bnB1dCAoeXlzY2FuX3QgeXlzY2FubmVyICk7CiAKIC8qIEFtb3VudCBvZiBzdHVmZiB0byBzbHVy
cCB1cCB3aXRoIGVhY2ggcmVhZC4gKi8KICNpZm5kZWYgWVlfUkVBRF9CVUZfU0laRQotI2lmZGVm
IF9faWE2NF9fCi0vKiBPbiBJQS02NCwgdGhlIGJ1ZmZlciBzaXplIGlzIDE2aywgbm90IDhrICov
Ci0jZGVmaW5lIFlZX1JFQURfQlVGX1NJWkUgMTYzODQKLSNlbHNlCiAjZGVmaW5lIFlZX1JFQURf
QlVGX1NJWkUgODE5MgotI2VuZGlmIC8qIF9faWE2NF9fICovCiAjZW5kaWYKIAogLyogQ29weSB3
aGF0ZXZlciB0aGUgbGFzdCBydWxlIG1hdGNoZWQgdG8gdGhlIHN0YW5kYXJkIG91dHB1dC4gKi8K
QEAgLTEwMDIsNyArOTg4LDcgQEAgc3RhdGljIGludCBpbnB1dCAoeXlzY2FuX3QgeXlzY2FubmVy
ICk7CiAvKiBUaGlzIHVzZWQgdG8gYmUgYW4gZnB1dHMoKSwgYnV0IHNpbmNlIHRoZSBzdHJpbmcg
bWlnaHQgY29udGFpbiBOVUwncywKICAqIHdlIG5vdyB1c2UgZndyaXRlKCkuCiAgKi8KLSNkZWZp
bmUgRUNITyBkbyB7IGlmIChmd3JpdGUoIHl5dGV4dCwgeXlsZW5nLCAxLCB5eW91dCApKSB7fSB9
IHdoaWxlICgwKQorI2RlZmluZSBFQ0hPIGZ3cml0ZSggeXl0ZXh0LCB5eWxlbmcsIDEsIHl5b3V0
ICkKICNlbmRpZgogCiAvKiBHZXRzIGlucHV0IGFuZCBzdHVmZnMgaXQgaW50byAiYnVmIi4gIG51
bWJlciBvZiBjaGFyYWN0ZXJzIHJlYWQsIG9yIFlZX05VTEwsCkBAIC0xMDEzLDcgKzk5OSw3IEBA
IHN0YXRpYyBpbnQgaW5wdXQgKHl5c2Nhbl90IHl5c2Nhbm5lciApOwogCWlmICggWVlfQ1VSUkVO
VF9CVUZGRVJfTFZBTFVFLT55eV9pc19pbnRlcmFjdGl2ZSApIFwKIAkJeyBcCiAJCWludCBjID0g
JyonOyBcCi0JCXNpemVfdCBuOyBcCisJCWludCBuOyBcCiAJCWZvciAoIG4gPSAwOyBuIDwgbWF4
X3NpemUgJiYgXAogCQkJICAgICAoYyA9IGdldGMoIHl5aW4gKSkgIT0gRU9GICYmIGMgIT0gJ1xu
JzsgKytuICkgXAogCQkJYnVmW25dID0gKGNoYXIpIGM7IFwKQEAgLTExMDEsNyArMTA4Nyw3IEBA
IFlZX0RFQ0wKIAogIC8qLS0tLS0gdGhlIHNjYW5uZXIgcnVsZXMgd2hpY2ggZG8gdGhlIHBhcnNp
bmcgLS0tLS0qLwogCi0jbGluZSAxMTA1ICJsaWJ4bHVfZGlza19sLmMiCisjbGluZSAxMDkxICJs
aWJ4bHVfZGlza19sLmMiCiAKIAlpZiAoICF5eWctPnl5X2luaXQgKQogCQl7CkBAIC0xNDI0LDcg
KzE0MTAsNyBAQCBZWV9SVUxFX1NFVFVQCiAjbGluZSAyMjcgImxpYnhsdV9kaXNrX2wubCIKIFlZ
X0ZBVEFMX0VSUk9SKCAiZmxleCBzY2FubmVyIGphbW1lZCIgKTsKIAlZWV9CUkVBSwotI2xpbmUg
MTQyOCAibGlieGx1X2Rpc2tfbC5jIgorI2xpbmUgMTQxNCAibGlieGx1X2Rpc2tfbC5jIgogCQkJ
Y2FzZSBZWV9TVEFURV9FT0YoSU5JVElBTCk6CiAJCQljYXNlIFlZX1NUQVRFX0VPRihMRVhFUlIp
OgogCQkJCXl5dGVybWluYXRlKCk7CkBAIC0yMTI1LDggKzIxMTEsOCBAQCBZWV9CVUZGRVJfU1RB
VEUgeGx1X19kaXNrX3l5X3NjYW5fc3RyaW5nCiAKIC8qKiBTZXR1cCB0aGUgaW5wdXQgYnVmZmVy
IHN0YXRlIHRvIHNjYW4gdGhlIGdpdmVuIGJ5dGVzLiBUaGUgbmV4dCBjYWxsIHRvIHhsdV9fZGlz
a195eWxleCgpIHdpbGwKICAqIHNjYW4gZnJvbSBhIEBlIGNvcHkgb2YgQGEgYnl0ZXMuCi0gKiBA
cGFyYW0geXlieXRlcyB0aGUgYnl0ZSBidWZmZXIgdG8gc2NhbgotICogQHBhcmFtIF95eWJ5dGVz
X2xlbiB0aGUgbnVtYmVyIG9mIGJ5dGVzIGluIHRoZSBidWZmZXIgcG9pbnRlZCB0byBieSBAYSBi
eXRlcy4KKyAqIEBwYXJhbSBieXRlcyB0aGUgYnl0ZSBidWZmZXIgdG8gc2NhbgorICogQHBhcmFt
IGxlbiB0aGUgbnVtYmVyIG9mIGJ5dGVzIGluIHRoZSBidWZmZXIgcG9pbnRlZCB0byBieSBAYSBi
eXRlcy4KICAqIEBwYXJhbSB5eXNjYW5uZXIgVGhlIHNjYW5uZXIgb2JqZWN0LgogICogQHJldHVy
biB0aGUgbmV3bHkgYWxsb2NhdGVkIGJ1ZmZlciBzdGF0ZSBvYmplY3QuCiAgKi8KQEAgLTI1MTcs
MTEgKzI1MDMsMyBAQCB2b2lkIHhsdV9fZGlza195eWZyZWUgKHZvaWQgKiBwdHIgLCB5eXNjCiAj
ZGVmaW5lIFlZVEFCTEVTX05BTUUgInl5dGFibGVzIgogCiAjbGluZSAyMjcgImxpYnhsdV9kaXNr
X2wubCIKLQotLyoKLSAqIExvY2FsIHZhcmlhYmxlczoKLSAqIG1vZGU6IEMKLSAqIGMtYmFzaWMt
b2Zmc2V0OiA0Ci0gKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwKLSAqIEVuZDoKLSAqLwpkaWZmIC1y
IDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbGlieGwvbGlieGx1X2Rpc2tfbC5o
Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9kaXNrX2wuaAlGcmkgRmViIDE3IDEyOjI0OjM4IDIw
MTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGx1X2Rpc2tfbC5oCU1vbiBGZWIgMjAgMTg6
MjA6MjkgMjAxMiArMDEwMApAQCAtNTgsNiArNTgsNyBAQCB0eXBlZGVmIGludCBmbGV4X2ludDMy
X3Q7CiB0eXBlZGVmIHVuc2lnbmVkIGNoYXIgZmxleF91aW50OF90OyAKIHR5cGVkZWYgdW5zaWdu
ZWQgc2hvcnQgaW50IGZsZXhfdWludDE2X3Q7CiB0eXBlZGVmIHVuc2lnbmVkIGludCBmbGV4X3Vp
bnQzMl90OworI2VuZGlmIC8qICEgQzk5ICovCiAKIC8qIExpbWl0cyBvZiBpbnRlZ3JhbCB0eXBl
cy4gKi8KICNpZm5kZWYgSU5UOF9NSU4KQEAgLTg4LDggKzg5LDYgQEAgdHlwZWRlZiB1bnNpZ25l
ZCBpbnQgZmxleF91aW50MzJfdDsKICNkZWZpbmUgVUlOVDMyX01BWCAgICAgICAgICAgICAoNDI5
NDk2NzI5NVUpCiAjZW5kaWYKIAotI2VuZGlmIC8qICEgQzk5ICovCi0KICNlbmRpZiAvKiAhIEZM
RVhJTlRfSCAqLwogCiAjaWZkZWYgX19jcGx1c3BsdXMKQEAgLTEzMiwxNSArMTMxLDcgQEAgdHlw
ZWRlZiB2b2lkKiB5eXNjYW5fdDsKIAogLyogU2l6ZSBvZiBkZWZhdWx0IGlucHV0IGJ1ZmZlci4g
Ki8KICNpZm5kZWYgWVlfQlVGX1NJWkUKLSNpZmRlZiBfX2lhNjRfXwotLyogT24gSUEtNjQsIHRo
ZSBidWZmZXIgc2l6ZSBpcyAxNmssIG5vdCA4ay4KLSAqIE1vcmVvdmVyLCBZWV9CVUZfU0laRSBp
cyAyKllZX1JFQURfQlVGX1NJWkUgaW4gdGhlIGdlbmVyYWwgY2FzZS4KLSAqIERpdHRvIGZvciB0
aGUgX19pYTY0X18gY2FzZSBhY2NvcmRpbmdseS4KLSAqLwotI2RlZmluZSBZWV9CVUZfU0laRSAz
Mjc2OAotI2Vsc2UKICNkZWZpbmUgWVlfQlVGX1NJWkUgMTYzODQKLSNlbmRpZiAvKiBfX2lhNjRf
XyAqLwogI2VuZGlmCiAKICNpZm5kZWYgWVlfVFlQRURFRl9ZWV9CVUZGRVJfU1RBVEUKQEAgLTMw
MiwxMiArMjkzLDcgQEAgc3RhdGljIGludCB5eV9mbGV4X3N0cmxlbiAoeXljb25zdCBjaGFyIAog
CiAvKiBBbW91bnQgb2Ygc3R1ZmYgdG8gc2x1cnAgdXAgd2l0aCBlYWNoIHJlYWQuICovCiAjaWZu
ZGVmIFlZX1JFQURfQlVGX1NJWkUKLSNpZmRlZiBfX2lhNjRfXwotLyogT24gSUEtNjQsIHRoZSBi
dWZmZXIgc2l6ZSBpcyAxNmssIG5vdCA4ayAqLwotI2RlZmluZSBZWV9SRUFEX0JVRl9TSVpFIDE2
Mzg0Ci0jZWxzZQogI2RlZmluZSBZWV9SRUFEX0JVRl9TSVpFIDgxOTIKLSNlbmRpZiAvKiBfX2lh
NjRfXyAqLwogI2VuZGlmCiAKIC8qIE51bWJlciBvZiBlbnRyaWVzIGJ5IHdoaWNoIHN0YXJ0LWNv
bmRpdGlvbiBzdGFjayBncm93cy4gKi8KQEAgLTM0MiwxNCArMzI4LDYgQEAgZXh0ZXJuIGludCB4
bHVfX2Rpc2tfeXlsZXggKHl5c2Nhbl90IHl5cwogCiAjbGluZSAyMjcgImxpYnhsdV9kaXNrX2wu
bCIKIAotI2xpbmUgMzQ2ICJsaWJ4bHVfZGlza19sLmgiCisjbGluZSAzMzIgImxpYnhsdV9kaXNr
X2wuaCIKICN1bmRlZiB4bHVfX2Rpc2tfeXlJTl9IRUFERVIKICNlbmRpZiAvKiB4bHVfX2Rpc2tf
eXlIRUFERVJfSCAqLwotCi0vKgotICogTG9jYWwgdmFyaWFibGVzOgotICogbW9kZTogQwotICog
Yy1iYXNpYy1vZmZzZXQ6IDQKLSAqIGluZGVudC10YWJzLW1vZGU6IG5pbAotICogRW5kOgotICov
CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9tNC9kZWZhdWx0X2xp
Yi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9kZWZhdWx0X2xpYi5tNAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSw4IEBACitBQ19ERUZVTihbQVhfREVGQVVMVF9MSUJdLAorW0FTX0lGKFt0ZXN0IC1k
ICIkcHJlZml4L2xpYjY0Il0sIFsKKyAgICBMSUJfUEFUSD0ibGliNjQiCitdLFsKKyAgICBMSUJf
UEFUSD0ibGliIgorXSkKK0FDX1NVQlNUKExJQl9QQVRIKV0pCisKZGlmZiAtciA4NzIxOGJkMzY3
YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kaXNhYmxl
X2ZlYXR1cmUubTQJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMg
QEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxF
KFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0kMV0sIFskMl0pKQorCitBU19J
RihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBb
dGVzdCAieCRlbmFibGVfJDEiID0gInh5ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rl
c3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSkKKyQxPSRheF9jdl8kMQor
QUNfU1VCU1QoJDEpXSkKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xz
L200L2VuYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL3Rvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00CU1vbiBGZWIgMjAgMTg6
MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEzIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJM
RV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkco
Wy0tZW5hYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHll
cyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJd
LCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhf
Y3ZfJDE9Im4iCitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIDg3MjE4
YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvb2NhbWwubTQKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvb2NhbWwubTQJTW9u
IEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMjQxIEBACitkbmwgYXV0b2Nv
bmYgbWFjcm9zIGZvciBPQ2FtbAorZG5sIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcv
CitkbmwKK2RubCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFJpY2hhcmQgVy5NLiBKb25lcworZG5s
IENvcHlyaWdodCDCqSAyMDA5ICAgICAgU3RlZmFubyBaYWNjaGlyb2xpCitkbmwgQ29weXJpZ2h0
IMKpIDIwMDAtMjAwNSBPbGl2aWVyIEFuZHJpZXUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1
IEplYW4tQ2hyaXN0b3BoZSBGaWxsacOidHJlCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBH
ZW9yZ2VzIE1hcmlhbm8KK2RubAorZG5sIEZvciBkb2N1bWVudGF0aW9uLCBwbGVhc2UgcmVhZCB0
aGUgb2NhbWwubTQgbWFuIHBhZ2UuCisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MXSwKK1tkbmwK
KyAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQ10sW29jYW1s
Y10sW25vXSkKKworICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCisgICAgIE9DQU1M
VkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwx
fHAnYAorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT05d
KQorICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FN
TExJQiIgPSAiIjsgdGhlbgorICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2
L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQor
ICAgICAgICBBQ19NU0dfUkVTVUxUKFtPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2Vydmlu
ZyBpdC5dKQorICAgICBmaQorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCBsaWJyYXJ5IHBhdGgg
aXMgJE9DQU1MTElCXSkKKworICAgICBBQ19TVUJTVChbT0NBTUxWRVJTSU9OXSkKKyAgICAgQUNf
U1VCU1QoW09DQU1MTElCXSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBB
Q19DSEVDS19UT09MKFtPQ0FNTE9QVF0sW29jYW1sb3B0XSxbbm9dKQorICAgICBPQ0FNTEJFU1Q9
Ynl0ZQorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCUFDX01TR19XQVJO
KFtDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS5dKQorICAg
ICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVS
U0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBv
Y2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC5dKQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkg
ICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MQkVT
VF0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAorICAgICBBQ19DSEVDS19UT09M
KFtPQ0FNTENET1RPUFRdLFtvY2FtbGMub3B0XSxbbm9dKQorICAgICBpZiB0ZXN0ICIkT0NBTUxD
RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNl
ZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVS
U0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJz
aW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC5dKQorCWVsc2UK
KwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBmaQorCisgICAgICMgY2hlY2tp
bmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0
aGVuCisJQUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRET1RPUFRdLFtvY2FtbG9wdC5vcHRdLFtub10p
CisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lP
Tj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8
XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0
aGVuCisJICAgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBv
Y2FtbG9wdC5vcHQgZGlzY2FyZGVkLl0pCisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FN
TE9QVERPVE9QVAorCSAgIGZpCisgICAgICAgIGZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1Qo
W09DQU1MT1BUXSkKKyAgZmkKKworICBBQ19TVUJTVChbT0NBTUxDXSkKKworICAjIGNoZWNraW5n
IGZvciBvY2FtbCB0b3BsZXZlbAorICBBQ19DSEVDS19UT09MKFtPQ0FNTF0sW29jYW1sXSxbbm9d
KQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIEFDX0NIRUNLX1RPT0woW09DQU1MREVQ
XSxbb2NhbWxkZXBdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBBQ19D
SEVDS19UT09MKFtPQ0FNTE1LVE9QXSxbb2NhbWxta3RvcF0sW25vXSkKKworICAjIGNoZWNraW5n
IGZvciBvY2FtbG1rbGliCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtMSUJdLFtvY2FtbG1rbGli
XSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgIEFDX0NIRUNLX1RPT0woW09D
QU1MRE9DXSxbb2NhbWxkb2NdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAor
ICBBQ19DSEVDS19UT09MKFtPQ0FNTEJVSUxEXSxbb2NhbWxidWlsZF0sW25vXSkKK10pCisKKwor
QUNfREVGVU4oW0FDX1BST0dfT0NBTUxMRVhdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2Ft
bGxleAorICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWF0sW29jYW1sbGV4XSxbbm9dKQorICBpZiB0
ZXN0ICIkT0NBTUxMRVgiICE9ICJubyI7IHRoZW4KKyAgICBBQ19DSEVDS19UT09MKFtPQ0FNTExF
WERPVE9QVF0sW29jYW1sbGV4Lm9wdF0sW25vXSkKKyAgICBpZiB0ZXN0ICIkT0NBTUxMRVhET1RP
UFQiICE9ICJubyI7IHRoZW4KKwlPQ0FNTExFWD0kT0NBTUxMRVhET1RPUFQKKyAgICBmaQorICBm
aQorICBBQ19TVUJTVChbT0NBTUxMRVhdKQorXSkKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxZ
QUNDXSwKK1tkbmwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxZQUNDXSxbb2NhbWx5YWNjXSxbbm9d
KQorICBBQ19TVUJTVChbT0NBTUxZQUNDXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfQ0FN
TFA0XSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVj
a2luZyBmb3IgY2FtbHA0CisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNF0sW2NhbWxwNF0sW25vXSkK
KyAgaWYgdGVzdCAiJENBTUxQNCIgIT0gIm5vIjsgdGhlbgorICAgICBUTVBWRVJTSU9OPWAkQ0FN
TFA0IC12IDI+JjF8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24gKlwoLipcKSR8XDF8cCdgCisgICAg
IGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJQUNfTVNH
X1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sY10pCisgICAgICAgIENBTUxQND1u
bworICAgICBmaQorICBmaQorICBBQ19TVUJTVChbQ0FNTFA0XSkKKworICAjIGNoZWNraW5nIGZv
ciBjb21wYW5pb24gdG9vbHMKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Qk9PVF0sW2NhbWxwNGJv
b3RdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9dLFtjYW1scDRvXSxbbm9dKQorICBB
Q19DSEVDS19UT09MKFtDQU1MUDRPRl0sW2NhbWxwNG9mXSxbbm9dKQorICBBQ19DSEVDS19UT09M
KFtDQU1MUDRPT0ZdLFtjYW1scDRvb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9S
Rl0sW2NhbWxwNG9yZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UFJPRl0sW2NhbWxw
NHByb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJdLFtjYW1scDRyXSxbbm9dKQor
ICBBQ19DSEVDS19UT09MKFtDQU1MUDRSRl0sW2NhbWxwNHJmXSxbbm9dKQorICBBQ19TVUJTVChb
Q0FNTFA0Qk9PVF0pCisgIEFDX1NVQlNUKFtDQU1MUDRPXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9G
XSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9PRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPUkZdKQorICBB
Q19TVUJTVChbQ0FNTFA0UFJPRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRSXSkKKyAgQUNfU1VCU1Qo
W0NBTUxQNFJGXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfRklORExJQl0sCitbZG5sCisg
IEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
ZmluZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEZJTkRdLFtvY2FtbGZpbmRdLFtub10pCisgIEFD
X1NVQlNUKFtPQ0FNTEZJTkRdKQorXSkKKworCitkbmwgVGhhbmtzIHRvIEppbSBNZXllcmluZyBm
b3Igd29ya2luZyB0aGlzIG5leHQgYml0IG91dCBmb3IgdXMuCitkbmwgWFhYIFdlIHNob3VsZCBk
ZWZpbmUgQVNfVFJfU0ggaWYgaXQncyBub3QgZGVmaW5lZCBhbHJlYWR5CitkbmwgKGVnLiBmb3Ig
b2xkIGF1dG9jb25mKS4KK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9QS0ddLAorW2RubAorICBB
Q19SRVFVSVJFKFtBQ19QUk9HX0ZJTkRMSUJdKWRubAorCisgIEFDX01TR19DSEVDS0lORyhbZm9y
IE9DYW1sIGZpbmRsaWIgcGFja2FnZSAkMV0pCisKKyAgdW5zZXQgZm91bmQKKyAgdW5zZXQgcGtn
CisgIGZvdW5kPW5vCisgIGZvciBwa2cgaW4gJDEgJDIgOyBkbworICAgIGlmICRPQ0FNTEZJTkQg
cXVlcnkgJHBrZyA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisgICAgICBBQ19NU0dfUkVT
VUxUKFtmb3VuZF0pCisgICAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9JHBrZworICAgICAg
Zm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRvbmUKKyAgaWYgdGVzdCAiJGZvdW5k
IiA9ICJubyIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICBBU19U
Ul9TSChbT0NBTUxfUEtHXyQxXSk9bm8KKyAgZmkKKworICBBQ19TVUJTVChBU19UUl9TSChbT0NB
TUxfUEtHXyQxXSkpCitdKQorCisKK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9NT0RVTEVdLAor
W2RubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBtb2R1bGUgJDJdKQorCisgIGNhdCA+
IGNvbmZ0ZXN0Lm1sIDw8RU9GCitvcGVuICQzCitFT0YKKyAgdW5zZXQgZm91bmQKKyAgZm9yICQx
IGluICQkMSAkNCA7IGRvCisgICAgaWYgJE9DQU1MQyAtYyAtSSAiJCQxIiBjb25mdGVzdC5tbCA+
JjUgMj4mNSA7IHRoZW4KKyAgICAgIGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBk
b25lCisKKyAgaWYgdGVzdCAiJGZvdW5kIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFskJDFd
KQorICBlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICAkMT1ubworICBm
aQorICBBQ19TVUJTVChbJDFdKQorXSkKKworCitkbmwgWFhYIENyb3NzLWNvbXBpbGluZworQUNf
REVGVU4oW0FDX0NIRUNLX09DQU1MX1dPUkRfU0laRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FD
X1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBjb21waWxlciB3
b3JkIHNpemVdKQorICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9lbmRsaW5lIChz
dHJpbmdfb2ZfaW50IFN5cy53b3JkX3NpemUpCisgIEVPRgorICBPQ0FNTF9XT1JEX1NJWkU9YCRP
Q0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX1dPUkRfU0laRV0pCisg
IEFDX1NVQlNUKFtPQ0FNTF9XT1JEX1NJWkVdKQorXSkKKworQUNfREVGVU4oW0FDX0NIRUNLX09D
QU1MX09TX1RZUEVdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKyAg
QUNfTVNHX0NIRUNLSU5HKFtPQ2FtbCBTeXMub3NfdHlwZV0pCisKKyAgY2F0ID4gY29uZnRlc3Qu
bWwgPDxFT0YKKyAgcHJpbnRfc3RyaW5nKFN5cy5vc190eXBlKTs7CitFT0YKKworICBPQ0FNTF9P
U19UWVBFPWAkT0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9PU19U
WVBFXSkKKyAgQUNfU1VCU1QoW09DQU1MX09TX1RZUEVdKQorXSkKZGlmZiAtciA4NzIxOGJkMzY3
YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL200L3BhdGhfb3JfZmFpbC5tNAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9wYXRoX29yX2Zh
aWwubTQJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNiBAQAorQUNf
REVGVU4oW0FYX1BBVEhfUFJPR19PUl9GQUlMXSwKK1tBQ19QQVRIX1BST0coWyQxXSwgWyQyXSwg
W25vXSkKK2lmIHRlc3QgeCIkeyQxfSIgPT0geCJubyIgCit0aGVuCisgICAgQUNfTVNHX0VSUk9S
KFtVbmFibGUgdG8gZmluZCAkMiwgcGxlYXNlIGluc3RhbGwgJDJdKQorZmldKQpkaWZmIC1yIDg3
MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvcHl0aG9uX2RldmVsLm00Ci0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5
dGhvbl9kZXZlbC5tNAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwx
OCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9ERVZFTF0sCitbQUNfTVNHX0NIRUNLSU5H
KFtmb3IgcHl0aG9uIGRldmVsXSkKKworYCRQWVRIT04gLWMgJworaW1wb3J0IG9zLnBhdGgsIHN5
cworZm9yIHAgaW4gc3lzLnBhdGg6CisgICAgaWYgb3MucGF0aC5leGlzdHMocCArICIvY29uZmln
L01ha2VmaWxlIik6CisgICAgICAgIHN5cy5leGl0KDApCitzeXMuZXhpdCgxKQorJyA+IC9kZXYv
bnVsbCAyPiYxYAorCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VM
VChbbm9dKQorICAgIEFDX01TR19FUlJPUihbUHl0aG9uIGRldmVsIHBhY2thZ2Ugbm90IGZvdW5k
XSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIDg3MjE4YmQz
NjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvcHl0aG9uX3ZlcnNpb24ubTQKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcHl0aG9u
X3ZlcnNpb24ubTQJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTIg
QEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fVkVSU0lPTl0sCitbQUNfTVNHX0NIRUNLSU5H
KFtmb3IgcHl0aG9uIHZlcnNpb24gPj0gJDEuJDIgXSkKK2AkUFlUSE9OIC1jICdpbXBvcnQgc3lz
OyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoJDEsICQyKSIpKSdgCitpZiB0ZXN0ICIk
PyIgIT0gIjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLVYgMj4mMWAKKyAg
ICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKAorICAgICAgICBbJHB5dGhv
bl92ZXJzaW9uIGlzIHRvbyBvbGQsIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBpcyAkMS4kMl0p
CitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciA4NzIxOGJkMzY3
YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL200L3B5dGhvbl94bWwubTQKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcHl0aG9uX3htbC5t
NAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNfREVG
VU4oW0FYX0NIRUNLX1BZVEhPTl9YTUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhvbiB4
bWwuZG9tLm1pbmlkb21dKQorYCRQWVRIT04gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nYAor
aWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBB
Q19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kIHhtbC5kb20ubWluaWRvbSBtb2R1bGVdKQorZWxz
ZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvc2V0X2NmbGFn
c19sZGZsYWdzLm00CU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDIw
IEBACitBQ19ERUZVTihbQVhfU0VUX0ZMQUdTXSwKK1tmb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5D
TFVERVMKK2RvCisgICAgUFJFUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRm
bGFnIGluICRQUkVQRU5EX0xJQgorZG8KKyAgICBQUkVQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFn
IgorZG9uZQorZm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMKK2RvCisgICAgQVBQRU5EX0NG
TEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4gJEFQUEVORF9MSUIKK2RvCisg
ICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorQ0ZMQUdTPSIkUFJFUEVORF9D
RkxBR1MgJENGTEFHUyAkQVBQRU5EX0NGTEFHUyIKK0xERkxBR1M9IiRQUkVQRU5EX0xERkxBR1Mg
JExERkxBR1MgJEFQUEVORF9MREZMQUdTIl0pCisKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2Nk
ZjllZDhhOTE0IHRvb2xzL200L3VkZXYubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdWRldi5tNAlNb24gRmViIDIwIDE4OjIwOjI5
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwzMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1VERVZdLAor
W2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0aGVuCisgICAgQUNfUEFUSF9Q
Uk9HKFtVREVWQURNXSwgW3VkZXZhZG1dLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1VERVZBRE19
IiA9PSB4Im5vIiAKKyAgICB0aGVuCisgICAgICAgIEFDX1BBVEhfUFJPRyhbVURFVklORk9dLCBb
dWRldmluZm9dLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30iID09IHgibm8i
CisgICAgICAgIHRoZW4KKyAgICAgICAgICAgIEFDX01TR19FUlJPUigKKyAgICAgICAgICAgICAg
ICBbVW5hYmxlIHRvIGZpbmQgdWRldmFkbSBvciB1ZGV2aW5mbywgcGxlYXNlIGluc3RhbGwgdWRl
dl0pCisgICAgICAgIGZpCisgICAgICAgIHVkZXZ2ZXI9YCR7VURFVklORk99IC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZWxzZQorICAgICAgICB1ZGV2dmVyPWAke1VERVZBRE19IGluZm8g
LVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBmaQorICAgIGlmIHRlc3QgJHt1ZGV2dmVyfSAt
bHQgNTkKKyAgICB0aGVuCisgICAgICAgIEFDX1BBVEhfUFJPRyhbSE9UUExVR10sIFtob3RwbHVn
XSwgW25vXSkKKyAgICAgICAgaWYgdGVzdCB4IiR7SE9UUExVR30iID09IHgibm8iCisgICAgICAg
IHRoZW4KKyAgICAgICAgICAgIEFDX01TR19FUlJPUihbdWRldiBpcyB0b28gb2xkLCB1cGdyYWRl
IHRvIHZlcnNpb24gNTkgb3IgbGF0ZXJdKQorICAgICAgICBmaQorICAgIGZpCitlbHNlCisgICAg
QUNfUEFUSF9QUk9HKFtWTkNPTkZJR10sIFt2bmNvbmZpZ10sIFtub10pCisgICAgaWYgdGVzdCB4
IiR7Vk5DT05GSUd9IiA9PSB4Im5vIgorICAgIHRoZW4KKyAgICAgICAgQUNfTVNHX0VSUk9SKFtO
b3QgYSBMaW51eCBzeXN0ZW0gYW5kIHVuYWJsZSB0byBmaW5kIHZuZF0pCisgICAgZmkKK2ZpCitd
KQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvdXVpZC5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC91dWlkLm00CU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwIEBA
CitBQ19ERUZVTihbQVhfQ0hFQ0tfVVVJRF0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxp
bnV4LWdudSIKK3RoZW4KKyAgICBBQ19DSEVDS19IRUFERVIoW3V1aWQvdXVpZC5oXSwsCisJICAg
IFtBQ19NU0dfRVJST1IoW2Nhbm5vdCBmaW5kIHV1aWQgaGVhZGVyc10pXSkKK2Vsc2UKKyAgICBB
Q19DSEVDS19IRUFERVIoW3V1aWQuaF0sLAorCSAgICBbQUNfTVNHX0VSUk9SKFtjYW5ub3QgZmlu
ZCB1dWlkIGhlYWRlcnNdKV0pCitmaQorXSkKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjll
ZDhhOTE0IHZlcnNpb24uc2gKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKKysrIGIvdmVyc2lvbi5zaAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSw1IEBACisjIS9iaW4vc2gKKworTUFKT1I9YGdyZXAgImV4cG9ydCBYRU5fVkVSU0lP
TiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK01JTk9SPWBncmVwICJleHBvcnQg
WEVOX1NVQlZFUlNJT04iICQxIHwgc2VkICdzLy4qPS8vZycgfCB0ciAtcyAiICJgCitwcmludGYg
IiVkLiVkIiAkTUFKT1IgJE1JTk9SCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq4F-0003e0-EN; Tue, 21 Feb 2012 13:47:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1Rzf8D-0003gM-DE
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 02:07:05 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329790018!14152833!1
X-Originating-IP: [137.65.248.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12894 invoked from network); 21 Feb 2012 02:06:58 -0000
Received: from novprvlin0050.provo.novell.com (HELO
	novprvlin0050.provo.novell.com) (137.65.248.33)
	by server-2.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 02:06:58 -0000
Received: from INET-PRV1-MTA by novprvlin0050.provo.novell.com
	with Novell_GroupWise; Mon, 20 Feb 2012 19:06:57 -0700
Message-Id: <4F436CB20200003000000DE0@novprvlin0050.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 20 Feb 2012 19:06:42 -0700
From: "Bamvor Jian Zhang" <bjzhang@suse.com>
To: <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBB95BB22.0__="
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Subject: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBB95BB22.0__=
Content-Type: multipart/alternative; boundary="=__PartBB95BB22.1__="

--=__PartBB95BB22.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable




a, libxl_event.h is included in libxl.h. So, the former one also need to =
be installed. =20
b, define __XEN_TOOLS__ in libxl.h:=20
the head file "xen/sysctl.h" need check this macro. =20
It is the same way used by the xen libxc public headers(tools/libxc/xenctrl=
.h and tools/libxc/xenctrlosdep.h). =20


Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>=20


diff -r 87218bd367be tools/libxl/Makefile=20
--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/MakefileMon Feb 20 15:36:09 2012 +0800=20
@@ -163,7 +163,7 @@=20
 ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.=
so.$(XLUMAJOR)=20
 ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so=20
 $(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR)=20
-$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)=20
+$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h libxl_event.h $(DESTDIR)$(INCLUDED=
IR)=20
 $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh=20
 =20
 .PHONY: clean=20


diff -r 87218bd367be tools/libxl/libxl.h=20
--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/libxl.hMon Feb 20 15:36:09 2012 +0800=20
@@ -127,6 +127,11 @@=20
 #ifndef LIBXL_H=20
 #define LIBXL_H=20
 =20
+/* Tell the Xen public headers we are a user-space tools build. */=20
+#ifndef __XEN_TOOLS__=20
+#define __XEN_TOOLS__ 1=20
+#endif =20
+=20
 #include <stdbool.h>=20
 #include <stdint.h>=20
 #include <stdarg.h> 

--=__PartBB95BB22.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html>=0A  <head>=0A=0A  </head>=0A  <body content=3D"text/html; charset=3D=
UTF-8" style=3D"font-variant: normal; line-height: normal; margin-right: =
4px; margin-left: 4px; margin-bottom: 1px; margin-top: 4px" http-equiv=3D"C=
ontent-Type">=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<br>=0A          </p>=0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">a&#44; =
libxl_event.h is included in libxl.h. So&#44; the former one also need to =
be installed. </font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">b&#4=
4; define __XEN_TOOLS__ in libxl.h:</font>    </p>=0A    <p style=3D"margin=
-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">the head file &quot;xen/sysctl.h&quot; need check this macro. =
</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A     =
 <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">It is the same way used by =
the xen libxc public headers&#40;tools/libxc/xenctrl.h and tools/libxc/xenc=
trlosdep.h&#41;. </font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <br>=0A          </p>=0A    <p style=3D"margin-bott=
om: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">Signed-off-by: Bamvor Jian Zhang &lt;bjzhang@suse.com&gt;</font>=
    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<br>=0A          </p>=0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/Makefile</font>    </p>=0A    <p style=3D"margin-b=
ottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 &#43;0000</fo=
nt>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/MakefileMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -163&#44;7 &#43;163&#44;7 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;ln -sf libxlutil.so.&#36;&#4=
0;XLUMAJOR&#41;.&#36;&#40;XLUMINOR&#41; &#36;&#40;DESTDIR&#41;&#36;&#40;LIB=
DIR&#41;/libxlutil.so.&#36;&#40;XLUMAJOR&#41;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#160;ln -sf libxlutil.so.&#36;&#40;XLUMAJOR&#41=
; &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;/libxlutil.so</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#36;&#40;INSTALL_DATA&#41; =
libxlutil.a &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;</font>    </p>=0A  =
  <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR =
PL ShanHeiSun Uni" size=3D"4">-&#36;&#40;INSTALL_DATA&#41; libxl.h =
libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h libxl_utils.h=
 libxl_uuid.h &#36;&#40;DESTDIR&#41;&#36;&#40;INCLUDEDIR&#41;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#36;&#40;INSTALL_DATA&#41; =
libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h =
libxl_utils.h libxl_uuid.h libxl_event.h &#36;&#40;DESTDIR&#41;&#36;&#40;IN=
CLUDEDIR&#41;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top=
: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#36;&#4=
0;INSTALL_DATA&#41; bash-completion &#36;&#40;DESTDIR&#41;&#36;&#40;BASH_CO=
MPLETION_DIR&#41;/xl.sh</font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#16=
0;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A   =
   <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;.PHONY: clean</font=
>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<br>=0A          </p>=0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/libxl.h</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 &#43;0000</fon=
t>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/libxl.hMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -127&#44;6 &#43;127&#44;11 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;ifndef LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;define LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;/&#42; Tell the Xen public headers we are =
a user-space tools build. &#42;/</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">&#43;&#35;ifndef __XEN_TOOLS__</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;&#35;define __XEN_TOOLS__ 1</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#35;endif </font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#160;&#35;include &lt;stdbool.h&gt;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;include &lt;stdint.h&gt=
;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A    =
  <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;include =
&lt;stdarg.h&gt;</font>=0A    </p>=0A  </body>=0A</html>=0A

--=__PartBB95BB22.1__=--

--=__PartBB95BB22.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

--=__PartBB95BB22.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq4E-0003da-Or; Tue, 21 Feb 2012 13:47:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzWvG-0002yU-2t
	for xen-devel@lists.xen.org; Mon, 20 Feb 2012 17:21:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329758416!55008265!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27502 invoked from network); 20 Feb 2012 17:20:16 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2012 17:20:16 -0000
Received: by wibhi20 with SMTP id hi20so2797393wib.32
	for <xen-devel@lists.xen.org>; Mon, 20 Feb 2012 09:21:08 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.107.67 as permitted sender) client-ip=10.180.107.67; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.107.67 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.107.67])
	by 10.180.107.67 with SMTP id ha3mr18850394wib.8.1329758468300
	(num_hops = 1); Mon, 20 Feb 2012 09:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=8ZVYTL1+wmeB4p1PV7BJB+zFyGjS01MYEsGbyKCD1IM=;
	b=vQhNlaz3My2yrEEfGH3Phdh3lI0cvq+8esL7rzvwP0PFMZq24yWMJlgp4/t2YDwwEd
	jfXjlBdGvBfeTlT9d78jr5ii0G8CxaNdWTUsCspYasgyi4OwCSq6E8eHt5IsH2Q5HiyO
	gIGG5uIVq8JUjt4fuvCqfy+2OKMAwDZkmXJyo=
Received: by 10.180.107.67 with SMTP id ha3mr15655793wib.8.1329758468032;
	Mon, 20 Feb 2012 09:21:08 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id hs6sm8176629wib.2.2012.02.20.09.21.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Feb 2012 09:21:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ccdf9ed8a9141d2f5293580040605e95c6908b43
Message-Id: <ccdf9ed8a9141d2f5293.1329758445@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 20 Feb 2012 18:20:45 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] build: add autoconf to replace custom checks in
	tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5NzU4NDI5IC0zNjAwCiMgTm9kZSBJRCBjY2RmOWVkOGE5
MTQxZDJmNTI5MzU4MDA0MDYwNWU5NWM2OTA4YjQzCiMgUGFyZW50ICA4NzIxOGJkMzY3YmVmY2E3
ZDM0ODhiYTFjZjRmZWIyYjEwZDVmMTRlCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdoZXJl
LCBhbmQgaXMgYXV0b21hdGljYWxseSBjcmVhdGVkIGJ5CmF1dG9oZWFkZXIsIGFsdG91Z2ggdGhp
cyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvIGluY2x1ZGUgdGhpcwpmaWxlLgoKSnVzdCBh
IGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJ
IGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjQ6CgogKiBVcGRhdGVkIHRvIHRp
cC4KCiAqIEluY2x1ZGUgY29uZmlnLmggZnJvbSBjb21waWxlciBjb21tYW5kIGxpbmUgd2hlbiBi
dWlsZGluZyBsaWJ4bCBhbmQKICAgeGwgdG8gYXNzdXJlIHlhamxfdmVyc2lvbi5oIHByZXNlbmNl
IGFuZCBjb3JyZWN0bHkgZGV0ZWN0IHlhamwKICAgdmVyc2lvbi4KCiAqIEFkZGVkIGdsaWItMi4w
IGNoZWNrLgoKQ2hhbmdlcyBzaW5jZSB2MzoKCiAqIENvcGllZCBjb25maWcuZ3Vlc3MgYW5kIGNv
bmZpZy5zdWIgZnJvbSBhdXRvbWFrZSAxLjExLgoKICogQWRkZWQgYSB0ZXN0IHRvIGNoZWNrIGZv
ciB1dWlkLmggb24gQlNEIGFuZCB1dWlkL3V1aWQuaCBvbiBMaW51eC4KCkNoYW5nZXMgc2luY2Ug
djI6CgogKiBDaGFuZ2VkIG9yZGVyIG9mIGNvbmZpZy9Ub29scy5tayBpbmNsdWRlLgoKICogQWRk
ZWQgIi1lIiB0byBhdXRvZ2VuLnNoIHNoZWJhbmcuCgogKiBBZGRlZCBuZWNlc3NhcnkgZmlsZXMg
KGNvbmZpZy4qKSBhbmQgb3V0cHV0IGZyb20gQXV0b2hlYWRlciBhbmQKICAgQXV0b2NvbmYuCgog
KiBSZW1vdmVkIEF1dG9jb25mIGZyb20gYnVpbGQgZGVwZW5kZW5jaWVzIGFuZCB1cGRhdGVkIFJF
QURNRS4KCkNoYW5nZXMgc2luY2UgdjE6CgogKiBNb3ZlZCBhdXRvY29uZiBzdHVmZiBpbnNpZGUg
dG9vbHMgZm9sZGVyLgoKICogQWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBjbGVhbmluZy4KCiAqIFJl
bW92ZWQgQXV0b21ha2UgZGVwZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRvZ2VuLnNoIHRvIGF1dG9t
YXRpY2FsbHkgY3JlYXRlIGNvbmZpZ3VyZSBzY3JpcHQgd2hlbgogICBidWlsZGluZyBmcm9tIHNv
dXJjZSByZXBvc2l0b3J5LgoKICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRpb25zIHBhc3NlZCBmcm9t
IGNvbW1hbmQgbGluZS4KCiAqIEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0byAuaGdpZ25vcmUuCgog
KiBBZGRlZCBBdXRvY29uZiB0byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNpZXMuCgogKiBDaGFuZ2Vk
IGh5cGVuIHRvIHVuZGVyc2NvcmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJpYWJsZSBuYW1lcy4KCiAq
IEFkZGVkIHNjcmlwdCB0byBnZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtlZmlsZS4KCiAqIFNldCBP
Y2FtbCB0b29scyB0byBvcHRpb25hbC4KCiAqIEFkZGVkIHByb2NlZGVuY2Ugb2YgbTQvb2NhbWwu
bTQuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMu
ZWR1PgoKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IC5oZ2lnbm9yZQotLS0g
YS8uaGdpZ25vcmUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiLy5oZ2lnbm9y
ZQlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTMwMyw2ICszMDMsMTIgQEAKIF50
b29scy9vY2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbCQKIF50b29scy9vY2FtbC9saWJzL3hsL3hl
bmxpZ2h0XC5tbGkkCiBedG9vbHMvb2NhbWwveGVuc3RvcmVkL294ZW5zdG9yZWQkCitedG9vbHMv
YXV0b200dGVcLmNhY2hlJAorXnRvb2xzL2NvbmZpZ1wuaCQKK150b29scy9jb25maWdcLmxvZyQK
K150b29scy9jb25maWdcLnN0YXR1cyQKK150b29scy9jb25maWdcLmNhY2hlJAorXmNvbmZpZy9U
b29sc1wubWskCiBeeGVuL1wuYmFubmVyLiokCiBeeGVuL0JMT0ckCiBeeGVuL1N5c3RlbS5tYXAk
CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCBDb25maWcubWsKLS0tIGEvQ29u
ZmlnLm1rCUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgYi9Db25maWcubWsJTW9u
IEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC03MCw5ICs3MCw2IEBAIEVYVFJBX0lOQ0xV
REVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVYVFJBX1BSRUZJ
WCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJPz0gZmxleAot
CiBQWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0tcHJlZml4PSIk
KFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250YWlucyAqbm8g
c3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCkBAIC0xNzUsMzIgKzE3Miw5IEBAIENGTEFH
UyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9MREZMQUdTICs9ICQo
Zm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZMQUdTICs9ICQoZm9y
ZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tfTElCID0gJChFWFRS
QV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lOQ0xVREVTID0gJChF
WFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9JTkNMVURFUykKLQog
RU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5v
LXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyArPSAtZm5vLWV4Y2Vw
dGlvbnMKIAotQ09ORklHX0xJQklDT05WICAgOj0gJChzaGVsbCBleHBvcnQgT1M9ImB1bmFtZSAt
c2AiOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGV4cG9ydCBDSEVDS19MSUI9IiQoQ0hFQ0tf
TElCKSI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgLiAkKFhFTl9ST09UKS90b29scy9jaGVj
ay9mdW5jcy5zaDsgXAotICAgICAgICAgICAgICAgICAgICAgICBoYXNfbGliIGxpYmljb252LnNv
ICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi1DT05GSUdfWUFKTF9WRVJTSU9OIDo9ICQoc2hl
bGwgZXhwb3J0IE9TPSJgdW5hbWUgLXNgIjsgXAotICAgICAgICAgICAgICAgICAgICAgICBleHBv
cnQgQ0hFQ0tfSU5DTFVERVM9IiQoQ0hFQ0tfSU5DTFVERVMpIjsgXAotICAgICAgICAgICAgICAg
ICAgICAgICAuICQoWEVOX1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNoOyBcCi0gICAgICAgICAg
ICAgICAgICAgICAgIGhhc19oZWFkZXIgeWFqbC95YWpsX3ZlcnNpb24uaCAmJiBlY2hvICd5JyB8
fCBlY2hvICduJykKLQotIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwg
Rmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1GTEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxFKQot
Ci0jIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHByb3Rv
Y29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVuIGl0
IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0jIG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQgdGhl
IGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWlsIG9y
IGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4KLUdJ
VF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVTX1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhlIGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2VyZSBk
b3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9uCiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmlnaW5h
bCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVkIGFzIGEgY29tbWVudApAQCAtMjM5LDE3ICsyMTMs
NCBAQCBRRU1VX1RBRyA/PSA0MTRiODc4ZThlYTE3YzY1Y2QwZDdmOWRmYzM4CiAjIFNob3J0IGFu
c3dlciAtLSBkbyBub3QgZW5hYmxlIHRoaXMgdW5sZXNzIHlvdSBrbm93IHdoYXQgeW91IGFyZQog
IyBkb2luZyBhbmQgYXJlIHByZXBhcmVkIGZvciBzb21lIHBhaW4uCiAKLSMgT3B0aW9uYWwgY29t
cG9uZW50cwotWEVOU1RBVF9YRU5UT1AgICAgID89IHkKLVZUUE1fVE9PTFMgICAgICAgICA/PSBu
Ci1MSUJYRU5BUElfQklORElOR1MgPz0gbgotUFlUSE9OX1RPT0xTICAgICAgID89IHkKLU9DQU1M
X1RPT0xTICAgICAgICA/PSB5Ci1DT05GSUdfTUlOSVRFUk0gICAgPz0gbgotQ09ORklHX0xPTU9V
TlQgICAgID89IG4KLUNPTkZJR19TWVNURU1fTElCQUlPID89IHkKIENPTkZJR19URVNUUyAgICAg
ICA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9PTFMpLHkpCi1PQ0FNTF9UT09MUyA6PSAkKHNoZWxs
IG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyAieSIgfHwgZWNobyAibiIpCi1l
bmRpZgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgTWFrZWZpbGUKLS0tIGEv
TWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiL01ha2VmaWxlCU1v
biBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDogREVT
VERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRpc3Q6IGRpc3QteGVuIGRpc3Qta2VybmVscyBkaXN0
LXRvb2xzIGRpc3Qtc3R1YmRvbSBkaXN0LWRvY3MgZGlzdC1taXNjCiAKIGRpc3QtbWlzYzoKLQkk
KElOU1RBTExfRElSKSAkKERJU1RESVIpL2NoZWNrCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09QWUlO
RyAkKERJU1RESVIpCiAJJChJTlNUQUxMX0RBVEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkkKElO
U1RBTExfUFJPRykgLi9pbnN0YWxsLnNoICQoRElTVERJUikKLQkkKElOU1RBTExfUFJPRykgdG9v
bHMvY2hlY2svY2hrIHRvb2xzL2NoZWNrL2NoZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2ggJChE
SVNURElSKS9jaGVjawogZGlzdC0lOiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdC0l
OiBpbnN0YWxsLSUKIAlAOiAjIGRvIG5vdGhpbmcKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2Nk
ZjllZDhhOTE0IFJFQURNRQotLS0gYS9SRUFETUUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICsw
MDAwCisrKyBiL1JFQURNRQlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTg5LDkg
Kzg5LDEzIEBAIDIuIGNkIHRvIHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKIDMuIEZv
ciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWlsZCB0
cmVlcywKICAgIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwczoKIAorICAgICMgLi9jb25maWd1
cmUKICAgICAjIG1ha2Ugd29ybGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ugd2Fu
dCwgeW91IGNhbiBydW4gLi9jb25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgorICAg
b3B0aW9ucyBhdmFpbGFibGUgb3B0aW9ucyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5nIFhl
bi4KKwogICAgVGhpcyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBtYWNo
aW5lLiBJdCB3aWxsIGJ1aWxkCiAgICB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRvb2xz
IGFuZCB0aGUgZG9jdW1lbnRhdGlvbi4KIApkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVk
OGE5MTQgYXV0b2dlbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9hdXRvZ2VuLnNoCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAt
MCwwICsxLDggQEAKKyMhL2Jpbi9zaCAtZQorcm0gLXJmIGNvbmZpZ3VyZQorY2QgdG9vbHMKK2F1
dG9jb25mCitjZCAuLgorZWNobyAiIyEvYmluL3NoIC1lIiA+PiBjb25maWd1cmUKK2VjaG8gImNk
IHRvb2xzICYmIC4vY29uZmlndXJlIFwkQCIgPj4gY29uZmlndXJlCitjaG1vZCAreCBjb25maWd1
cmUKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IGNvbmZpZy9Ub29scy5tay5p
bgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25m
aWcvVG9vbHMubWsuaW4JTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEs
NTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklYICAgICAgICAgICAgICA6
PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BBVEhACisKKyMgQSBkZWJ1
ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0gQGRlYnVnQAorCisjIFRv
b2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAorRkxFWCAgICAgICAgICAg
ICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZVEhPTkAKK1BZVEhPTl9Q
QVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAgICAgICAgIDo9IEBQRVJM
QAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAgICAgICAgICAgICAgIDo9
IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwyX0NPTkZJRyAgICAgICAg
IDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAorWEdFVFRURVhUICAgICAg
ICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBsaWJzL2luY2x1ZGVzCitQ
UkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAorUFJFUEVORF9MSUIgICAg
ICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAgIDo9IEBBUFBFTkRfSU5D
TFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElCQAorCisjIEVuYWJsZSBY
U00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitYU01fRU5BQkxFICAgICAg
ICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21ACisKKyMgRG93bmxvYWQg
R0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJvdG9jb2w/CisjIEdJVCdz
IHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxs
IChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0
IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwgb3IgaGFuZywgcGxlYXNl
IHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50LgorR0lUX0hUVFAgICAgICAg
ICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRzCitYRU5TVEFUX1hFTlRP
UCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAgOj0gQHZ0cG1ACitMSUJY
RU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAgICAgICA6PSBAcHl0aG9u
dG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xzQAorQ09ORklHX01JTklU
RVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAgIDo9IEBsb21vdW50QAor
CisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0gQHN5c3RlbV9haW9ACitD
T05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19HQ1JZUFQgICAgICAgOj0g
QGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4dDJmc0AKZGlmZiAtciA4
NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IGNvbmZpZ3VyZQotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJTW9uIEZlYiAyMCAxODoy
MDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3NoIC1lCitjZCB0b29scyAm
JiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9v
bHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEy
ICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEw
MApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlvCiBlbmRpZgogCiBTVUJE
SVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9IGluY2x1ZGUKIFNVQkRJ
UlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03OSw2ICs3OCw4IEBAIGNsZWFu
OiBzdWJkaXJzLWNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMtZGlzdGNsZWFuCiAJcm0gLXJmIHFl
bXUteGVuLXRyYWRpdGlvbmFsLWRpciBxZW11LXhlbi10cmFkaXRpb25hbC1kaXItcmVtb3RlCiAJ
cm0gLXJmIHFlbXUteGVuLWRpciBxZW11LXhlbi1kaXItcmVtb3RlCisJcm0gLXJmIC4uL2NvbmZp
Zy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAorCQljb25maWcu
Y2FjaGUgYXV0b200dGUuY2FjaGUKIAogaWZuZXEgKCQoWEVOX0NPTVBJTEVfQVJDSCksJChYRU5f
VEFSR0VUX0FSQ0gpKQogSU9FTVVfQ09ORklHVVJFX0NST1NTID89IC0tY3B1PSQoWEVOX1RBUkdF
VF9BUkNIKSBcCmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9SdWxl
cy5tawotLS0gYS90b29scy9SdWxlcy5tawlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAK
KysrIGIvdG9vbHMvUnVsZXMubWsJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC00
LDYgKzQsNyBAQAogYWxsOgogCiBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5taworaW5jbHVk
ZSAkKFhFTl9ST09UKS9jb25maWcvVG9vbHMubWsKIAogZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5T
VEFMTCkKIElOU1RBTEwgPSAkKFhFTl9ST09UKS90b29scy9jcm9zcy1pbnN0YWxsCkBAIC04MCw4
ICs4MSw2IEBAIGNoZWNrLSQoQ09ORklHX1g4NikgPSAkKGNhbGwgY2MtdmVyLWNoZWMKICAgICAg
ICAgICAgICAgICAgICAgICAgICJYZW4gcmVxdWlyZXMgYXQgbGVhc3QgZ2NjLTMuNCIpCiAkKGV2
YWwgJChjaGVjay15KSkKIAotX1BZVEhPTl9QQVRIIDo9ICQoc2hlbGwgd2hpY2ggJChQWVRIT04p
KQotUFlUSE9OX1BBVEggPz0gJChfUFlUSE9OX1BBVEgpCiBJTlNUQUxMX1BZVEhPTl9QUk9HID0g
XAogCSQoWEVOX1JPT1QpL3Rvb2xzL3B5dGhvbi9pbnN0YWxsLXdyYXAgIiQoUFlUSE9OX1BBVEgp
IiAkKElOU1RBTExfUFJPRykKIApAQCAtMTA5LDMgKzEwOCw3IEBAIHN1YmRpci1hbGwtJSBzdWJk
aXItY2xlYW4tJSBzdWJkaXItaW5zdGEKIAogc3ViZGlyLWRpc3RjbGVhbi0lOiAucGhvbnkKIAkk
KE1BS0UpIC1DICQqIGNsZWFuCisKKyQoWEVOX1JPT1QpL2NvbmZpZy9Ub29scy5tazoKKwlAZWNo
byAiWW91IGhhdmUgdG8gcnVuIC4vY29uZmlndXJlIGJlZm9yZSBidWlsZGluZyBvciBpbnN0YWxs
aW5nIHRoZSB0b29scyIKKwlAZXhpdCAxCmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4
YTkxNCB0b29scy9ibGt0YXAvZHJpdmVycy9NYWtlZmlsZQotLS0gYS90b29scy9ibGt0YXAvZHJp
dmVycy9NYWtlZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMv
YmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBA
IC0xMyw3ICsxMyw3IEBAIENGTEFHUyAgICs9ICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKQogQ0ZMQUdT
ICAgKz0gLUkgJChNRU1TSFJfRElSKQogQ0ZMQUdTICAgKz0gLURfR05VX1NPVVJDRQogCi1pZmVx
ICgkKHNoZWxsIC4gLi9jaGVja19nY3J5cHQgJChDQykpLHllcykKK2lmZXEgKCRDT05GSUdfR0NS
WVBULHkpCiBDRkxBR1MgKz0gLURVU0VfR0NSWVBUCiBDUllQVF9MSUIgOj0gLWxnY3J5cHQKIGVs
c2UKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2Jsa3RhcC9kcml2
ZXJzL2NoZWNrX2djcnlwdAotLS0gYS90b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQJ
RnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jpbi9zaAotCi1jYXQgPiAu
Z2NyeXB0LmMgPDwgRU9GCi0jaW5jbHVkZSA8Z2NyeXB0Lmg+Ci1pbnQgbWFpbih2b2lkKSB7IHJl
dHVybiAwOyB9Ci1FT0YKLQotaWYgJDEgLW8gLmdjcnlwdCAuZ2NyeXB0LmMgLWxnY3J5cHQgMj4v
ZGV2L251bGwgOyB0aGVuCi0gIGVjaG8gInllcyIKLWVsc2UKLSAgZWNobyAibm8iCi1maQotCi1y
bSAtZiAuZ2NyeXB0KgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMv
Y2hlY2svTWFrZWZpbGUKLS0tIGEvdG9vbHMvY2hlY2svTWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoy
NDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDI2ICswLDAgQEAKLVhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uCi1pbmNsdWRl
ICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCi0KLSMgRXhwb3J0IHRoZSBuZWNlc3NhcnkgZW52
aXJvbm1lbnQgdmFyaWFibGVzIGZvciB0aGUgdGVzdHMKLWV4cG9ydCBQWVRIT04KLWV4cG9ydCBM
SUJYRU5BUElfQklORElOR1MKLWV4cG9ydCBDSEVDS19JTkNMVURFUwotZXhwb3J0IENIRUNLX0xJ
QgotZXhwb3J0IENPTkZJR19TWVNURU1fTElCQUlPCi0KLS5QSE9OWTogYWxsIGluc3RhbGwKLWFs
bCBpbnN0YWxsOiBjaGVjay1idWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3Ig
YnVpbGRpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWJ1aWxkCi1jaGVjay1idWlsZDoKLQkuL2NoayBi
dWlsZAotCi0jIENoZWNrIHRoaXMgbWFjaGluZSBpcyBPSyBmb3IgaW5zdGFsbGluZyBvbi4KLS5Q
SE9OWTogY2hlY2staW5zdGFsbAotY2hlY2staW5zdGFsbDoKLQkuL2NoayBpbnN0YWxsCi0KLS5Q
SE9OWTogY2xlYW4KLWNsZWFuOgotCS4vY2hrIGNsZWFuCmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9SRUFETUUKLS0tIGEvdG9vbHMvY2hlY2svUkVBRE1F
CUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMCArMCwwIEBACi1DaGVja3MgZm9yIHRoZSBzdWl0
YWJpbGl0eSBvZiBhIG1hY2hpbmUgZm9yIFhlbiBidWlsZCBvciBpbnN0YWxsLgotVG8gY2hlY2sg
Zm9yIGJ1aWxkIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGJ1aWxkCi0KLVRvIGNo
ZWNrIGZvciBpbnN0YWxsIHN1aXRhYmlsaXR5IHVzZQotCi0gICAgICAgIC4vY2hrIGluc3RhbGwK
LQotVGhlIGNoayBzY3JpcHQgd2lsbCBydW4gY2hlY2tzIGluIHRoaXMgZGlyZWN0b3J5IGFuZCBw
cmludAotdGhlIG9uZXMgdGhhdCBmYWlsZWQuIEl0IHByaW50cyBub3RoaW5nIGlmIGNoZWNrcyBz
dWNjZWVkLgotVGhlIGNoayBzY3JpcHQgZXhpdHMgd2l0aCAwIG9uIHN1Y2Nlc3MgYW5kIDEgb24g
ZmFpbHVyZS4KLQotVGhlIGNoayBzY3JpcHQgcnVucyBleGVjdXRhYmxlIGZpbGVzIGluIHRoaXMg
ZGlyZWN0b3J5IHdob3NlCi1uYW1lcyBiZWdpbiB3aXRoICdjaGVja18nLiBGaWxlcyBjb250YWlu
aW5nIENIRUNLLUJVSUxECi1hcmUgcnVuIGZvciB0aGUgYnVpbGQgY2hlY2ssIGFuZCBmaWxlcyBj
b250YWluaW5nIENIRUNLLUlOU1RBTEwKLWFyZSBydW4gZm9yIHRoZSBpbnN0YWxsIGNoZWNrLgot
Ci1EZXRhaWxlZCBvdXRwdXQgZnJvbSB0aGUgY2hlY2sgc2NyaXB0cyBpcyBpbiAuY2hrYnVpbGQg
Zm9yIGJ1aWxkCi1hbmQgLmNoa2luc3RhbGwgZm9yIGluc3RhbGwuClwgTm8gbmV3bGluZSBhdCBl
bmQgb2YgZmlsZQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY2hl
Y2svY2hlY2tfYnJjdGwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfYnJjdGwJRnJpIEZlYiAxNyAx
MjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4g
Li9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8RnJlZUJTRCkKLQloYXNf
b3JfZmFpbCBicmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwgYnJjdGwgOzsKLSopCi0J
ZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjll
ZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hl
Y2tfY3J5cHRvX2xpYglGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAotIyEvYmlu
L3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2Ug
JE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4aXQgMCA7OwotZXNhYwotCi1oYXNf
bGliIGxpYmNyeXB0by5zbyB8fCBmYWlsICJtaXNzaW5nIGxpYmNyeXB0by5zbyIKZGlmZiAtciA4
NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX2N1cmwKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfY3VybAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAsMCBA
QAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNo
Ci0KLWlmIFsgIiRMSUJYRU5BUElfQklORElOR1MiICE9ICJ5IiBdOyB0aGVuCi0JZWNobyAtbiAi
dW51c2VkLCAiCi0JZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCBjdXJsLWNvbmZpZwotY3VybF9s
aWJzPWBjdXJsLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgImN1cmwtY29uZmlnIC0tbGlicyBmYWls
ZWQiCi10ZXN0X2xpbmsgJGN1cmxfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxpYnJhcmllcyBm
b3IgY3VybCBhcmUgbWlzc2luZyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0
IHRvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfaXByb3V0
ZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTUgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLVBBVEg9L3NiaW46JFBBVEgKLQotY2FzZSAkT1Mg
aW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgaWZjb25maWcgOzsKLUxp
bnV4KQotCWhhc19vcl9mYWlsIGlwIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2Fj
CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja19s
aWJhaW9fZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCUZyaSBGZWIg
MTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQot
LiAuL2Z1bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7
IHRoZW4KLSAgICBleGl0IDAKLWZpCi1pZiAhIGhhc19oZWFkZXIgbGliYWlvLmggOyB0aGVuCi0g
ICAgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8gaGVhZGVycywgaW5zdGFsbCBsaWJhaW8gZGV2ZWwg
cGFja2FnZSBvciBzZXQgQ09ORklHX1NZU1RFTV9MSUJBSU89biIKLWZpCmRpZmYgLXIgODcyMThi
ZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja19saWJhaW9fbGliCi0tLSBh
L3Rvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDkg
KzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1
bmNzLnNoCi0KLWlmIFsgWCR7Q09ORklHX1NZU1RFTV9MSUJBSU99ICE9IFgieSIgXSA7IHRoZW4K
LSAgICBleGl0IDAKLWZpCi1oYXNfbGliIGxpYmFpby5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIGxp
YmFpbyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2No
ZWNrX29wZW5zc2xfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAlG
cmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJ
TEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgb3BlbnNzbC9tZDUuaCB8fCBmYWlsICJt
aXNzaW5nIG9wZW5zc2wgaGVhZGVycyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhh
OTE0IHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbgotLS0gYS90b29scy9jaGVjay9jaGVja19weXRo
b24JRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlU
SE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQotCi0ke1BZVEhPTn0gLWMgJwotaW1wb3J0
IHN5cwotc3lzLmV4aXQoc3lzLnZlcnNpb25faW5mb1swXSA8IDIgb3Igc3lzLnZlcnNpb25faW5m
b1sxXSA8IDMpCi0nIHx8IGZhaWwgIm5lZWQgcHl0aG9uIHZlcnNpb24gPj0gMi4zIgpkaWZmIC1y
IDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX2Rl
dmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAlGcmkgRmViIDE3IDEyOjI0
OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5j
cy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049cHl0aG9uCi1maQot
aGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgb3MucGF0aCwg
c3lzCi1mb3IgcCBpbiBzeXMucGF0aDoKLQlpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcv
TWFrZWZpbGUiKToKLQkJc3lzLmV4aXQoMCkKLXN5cy5leGl0KDEpCi0nIHx8IGZhaWwgImNhbid0
IGZpbmQgcHl0aG9uIGRldmVsIGZpbGVzIgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVk
OGE5MTQgdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAotLS0gYS90b29scy9jaGVjay9jaGVj
a19weXRob25feG1sCUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhP
Tn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0k
e1BZVEhPTn0gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nIDI+L2Rldi9udWxsIHx8IFwKLWZh
aWwgImNhbid0IGltcG9ydCB4bWwuZG9tLm1pbmlkb20iCmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja191ZGV2Ci0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3VkZXYJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIyICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxO
ZXRCU0R8RnJlZUJTRCkKLQloYXNfb3JfZmFpbCB2bmNvbmZpZwotCTs7Ci1MaW51eCkKLQloYXMg
L3NiaW4vdWRldmFkbSAmJiBcCi0JCXVkZXZ2ZXI9YC9zYmluL3VkZXZhZG0gaW5mbyAtViB8IGF3
ayAne3ByaW50ICRORn0nYAotCVsgLXogIiR1ZGV2dmVyIiBdICYmIGhhc19vcl9mYWlsIHVkZXZp
bmZvICYmIFwKLQkJdWRldnZlcj1gdWRldmluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlb
ICIkdWRldnZlciIgLWdlIDU5IF0gMj4vZGV2L251bGwgfHwgXAotCQloYXMgaG90cGx1ZyB8fCBc
Ci0JCWZhaWwgInVkZXYgaXMgdG9vIG9sZCwgdXBncmFkZSB0byB2ZXJzaW9uIDU5IG9yIGxhdGVy
IgotCTs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiCi0JOzsKLWVzYWMKZGlmZiAtciA4NzIxOGJk
MzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNyAr
MCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19o
ZWFkZXIgdXVpZC5oIHx8IFwKLWhhc19oZWFkZXIgdXVpZC91dWlkLmggfHwgZmFpbCAibWlzc2lu
ZyB1dWlkIGhlYWRlcnMgKHBhY2thZ2UgdXVpZC1kZXYpIgpkaWZmIC1yIDg3MjE4YmQzNjdiZSAt
ciBjY2RmOWVkOGE5MTQgdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3gxMV9kZXZlbAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgWDEx
L2tleXN5bWRlZi5oIHx8IFwKLWhhc19oZWFkZXIgL3Vzci9YMTFSNi9pbmNsdWRlL1gxMS9rZXlz
eW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVyIC91c3IvWDExUjcvaW5jbHVkZS9YMTEva2V5c3ltZGVm
LmggfHwgXAotd2FybmluZyAiY2FuJ3QgZmluZCBYMTEgaGVhZGVycyIKZGlmZiAtciA4NzIxOGJk
MzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0Ci0tLSBhL3Rv
b2xzL2NoZWNrL2NoZWNrX3hnZXR0ZXh0CUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw2ICswLDAg
QEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX29yX2Zh
aWwgeGdldHRleHQKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2No
ZWNrL2NoZWNrX3htbDIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeG1sMglGcmkgRmViIDE3IDEy
OjI0OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlO
U1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIFsgISAiJExJQlhFTkFQSV9CSU5ESU5HUyIgPSAi
eSIgXQotdGhlbgotICAgIGVjaG8gLW4gInVudXNlZCwgIgotICAgIGV4aXQgMAotZmkKLQotaGFz
X29yX2ZhaWwgeG1sMi1jb25maWcKLXhtbDJfbGlicz1geG1sMi1jb25maWcgLS1saWJzYCB8fCBm
YWlsICJ4bWwyLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICR4bWwyX2xpYnMgfHwg
ZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIHhtbDIgYXJlIG1pc3NpbmciCmRpZmYgLXIg
ODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9jaGVjay9jaGVja195YWpsX2RldmVs
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwJRnJpIEZlYiAxNyAxMjoyNDozOCAy
MDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBA
IC0xLDggKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAot
Ci1oYXNfaGVhZGVyIHlhamwveWFqbF9wYXJzZS5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95
YWpsX3BhcnNlLmgiCi1oYXNfaGVhZGVyIHlhamwveWFqbF9nZW4uaCB8fCBmYWlsICJjYW4ndCBm
aW5kIHlhamwveWFqbF9nZW4uaCIKLWhhc19saWIgbGlieWFqbC5zbyB8fCBmYWlsICJjYW4ndCBm
aW5kIGxpYnlhamwuc28iCmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29s
cy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJfZGV2
ZWwJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBmYWlsICJjYW4n
dCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0
IHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3psaWJf
bGliCUZyaSBGZWIgMTcgMTI6MjQ6MzggMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZy
ZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJ6
LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2Nk
ZjllZDhhOTE0IHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJRnJpIEZlYiAx
NyAxMjoyNDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3VzYWdlICgpCi17
Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFsbHxjbGVhbl0i
Ci0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4gYnVpbGQgb3Ig
aW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90LiIKLSAgICBl
Y2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5lcmF0ZWQgZmls
ZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2JpbgotT1M9YHVu
YW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIgXTsgdGhlbgot
CWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBjaGVjaz0iQ0hF
Q0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hlY2s9IkNIRUNL
LUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQgMAotICAgICAg
ICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVzYWMKLQotZmFp
bGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBjaGVja18qIDsg
ZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29udGludWUKLSAg
ICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVzYWMKLSAgICBp
ZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAgIGlmICEg
Z3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0gICAgZmkKLSAg
ICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRoZW4KLSAgICAg
ICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQotZG9uZQotCi1l
eGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMv
Y2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJRnJpIEZlYiAxNyAxMjoy
NDozOCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGljaCwgZXhjZXB0
IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAteiAiJENST1NT
X0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVybiAkPwotCWZp
Ci0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50
IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBpbiAkUEFUSDsg
ZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0JCQllY2hvICIk
Q1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUKLQlyZXR1cm4g
MQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVsbCB8fCBmYWls
ICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5c19yb290IHx8
IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBbIC1yICIkQ1JP
U1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAwCi0JCWZpCi0J
CWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAiJENST1NTX1NZ
U19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQotCQlkb25lCi0J
CTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVja19zeXNfcm9v
dCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxs
ZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAjIGZvciBsZGNv
bmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhpcyByZWxhdGl2
ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0Ci0JIyBsZGNv
bmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3JrLgotCWlmIFsg
IiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNvLmNhY2hlIiBd
OyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JPU1NfU1lTX1JP
T1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91Z2g7IGxkY29u
ZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJMaW51eCIg
XTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JPU1NfU1lTX1JP
T1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIke09TfSIgPSAi
TmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZxICIkMSIKLQkJ
cmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkgewotCSMgc3Vi
c2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1wZmlsZQotCXRy
YXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1gbWt0ZW1wYCB8
fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+JjEKLQlyZXR1
cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5IGFib3ZlCi1j
aGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiByZXR1cm4gMAot
CWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVhc2Ugc2V0IENS
T1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlmaQotCWlmIFsg
ISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1yb290IGZvdW5k
IGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJuaW5nKCkgewot
CWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAkKn0iCi19Ci0K
LWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6
ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRv
b2xzL2NvbmZpZy5ndWVzcwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi90b29scy9jb25maWcuZ3Vlc3MJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTUyMiBAQAorIyEgL2Jpbi9zaAorIyBBdHRlbXB0IHRvIGd1ZXNzIGEg
Y2Fub25pY2FsIHN5c3RlbSBuYW1lLgorIyAgIENvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5
NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwKKyMgICAyMDAwLCAyMDAxLCAyMDAyLCAy
MDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEwLAorIyAgIDIwMTEg
RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3RpbWVzdGFtcD0nMjAxMS0xMS0xMScK
KworIyBUaGlzIGZpbGUgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeSBpdAorIyB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRp
b24pIGFueSBsYXRlciB2ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJVEhPVVQgQU5ZIFdB
UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRB
QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUK
KyMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hv
dWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZQorIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBT
b2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQgLSBGaWZ0aCBG
bG9vciwgQm9zdG9uLCBNQQorIyAwMjExMC0xMzAxLCBVU0EuCisjCisjIEFzIGEgc3BlY2lhbCBl
eGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBpZiB5b3UKKyMgZGlz
dHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBjb250YWlucyBhCisj
IGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNs
dWRlIGl0IHVuZGVyCisjIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0aGF0IHlvdSB1c2Ug
Zm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KKworCisjIE9yaWdpbmFsbHkgd3JpdHRlbiBi
eSBQZXIgQm90aG5lci4gIFBsZWFzZSBzZW5kIHBhdGNoZXMgKGNvbnRleHQKKyMgZGlmZiBmb3Jt
YXQpIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPiBhbmQgaW5jbHVkZSBhIENoYW5nZUxvZwor
IyBlbnRyeS4KKyMKKyMgVGhpcyBzY3JpcHQgYXR0ZW1wdHMgdG8gZ3Vlc3MgYSBjYW5vbmljYWwg
c3lzdGVtIG5hbWUgc2ltaWxhciB0bworIyBjb25maWcuc3ViLiAgSWYgaXQgc3VjY2VlZHMsIGl0
IHByaW50cyB0aGUgc3lzdGVtIG5hbWUgb24gc3Rkb3V0LCBhbmQKKyMgZXhpdHMgd2l0aCAwLiAg
T3RoZXJ3aXNlLCBpdCBleGl0cyB3aXRoIDEuCisjCisjIFlvdSBjYW4gZ2V0IHRoZSBsYXRlc3Qg
dmVyc2lvbiBvZiB0aGlzIHNjcmlwdCBmcm9tOgorIyBodHRwOi8vZ2l0LnNhdmFubmFoLmdudS5v
cmcvZ2l0d2ViLz9wPWNvbmZpZy5naXQ7YT1ibG9iX3BsYWluO2Y9Y29uZmlnLmd1ZXNzO2hiPUhF
QUQKKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdlPSJcCitVc2Fn
ZTogJDAgW09QVElPTl0KKworT3V0cHV0IHRoZSBjb25maWd1cmF0aW9uIG5hbWUgb2YgdGhlIHN5
c3RlbSBcYCRtZScgaXMgcnVuIG9uLgorCitPcGVyYXRpb24gbW9kZXM6CisgIC1oLCAtLWhlbHAg
ICAgICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtdCwgLS10aW1lLXN0YW1wICAg
cHJpbnQgZGF0ZSBvZiBsYXN0IG1vZGlmaWNhdGlvbiwgdGhlbiBleGl0CisgIC12LCAtLXZlcnNp
b24gICAgICBwcmludCB2ZXJzaW9uIG51bWJlciwgdGhlbiBleGl0CisKK1JlcG9ydCBidWdzIGFu
ZCBwYXRjaGVzIHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4iCisKK3ZlcnNpb249IlwKK0dO
VSBjb25maWcuZ3Vlc3MgKCR0aW1lc3RhbXApCisKK09yaWdpbmFsbHkgd3JpdHRlbiBieSBQZXIg
Qm90aG5lci4KK0NvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5
NywgMTk5OCwgMTk5OSwgMjAwMCwKKzIwMDEsIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYs
IDIwMDcsIDIwMDgsIDIwMDksIDIwMTAsIDIwMTEgRnJlZQorU29mdHdhcmUgRm91bmRhdGlvbiwg
SW5jLgorCitUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUgc291cmNlIGZvciBjb3B5aW5n
IGNvbmRpdGlvbnMuICBUaGVyZSBpcyBOTword2FycmFudHk7IG5vdCBldmVuIGZvciBNRVJDSEFO
VEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIgorCitoZWxwPSIK
K1RyeSBcYCRtZSAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uLiIKKworIyBQYXJzZSBjb21t
YW5kIGxpbmUKK3doaWxlIHRlc3QgJCMgLWd0IDAgOyBkbworICBjYXNlICQxIGluCisgICAgLS10
aW1lLXN0YW1wIHwgLS10aW1lKiB8IC10ICkKKyAgICAgICBlY2hvICIkdGltZXN0YW1wIiA7IGV4
aXQgOzsKKyAgICAtLXZlcnNpb24gfCAtdiApCisgICAgICAgZWNobyAiJHZlcnNpb24iIDsgZXhp
dCA7OworICAgIC0taGVscCB8IC0taCogfCAtaCApCisgICAgICAgZWNobyAiJHVzYWdlIjsgZXhp
dCA7OworICAgIC0tICkgICAgICMgU3RvcCBvcHRpb24gcHJvY2Vzc2luZworICAgICAgIHNoaWZ0
OyBicmVhayA7OworICAgIC0gKQkjIFVzZSBzdGRpbiBhcyBpbnB1dC4KKyAgICAgICBicmVhayA7
OworICAgIC0qICkKKyAgICAgICBlY2hvICIkbWU6IGludmFsaWQgb3B0aW9uICQxJGhlbHAiID4m
MgorICAgICAgIGV4aXQgMSA7OworICAgICogKQorICAgICAgIGJyZWFrIDs7CisgIGVzYWMKK2Rv
bmUKKworaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgIGVjaG8gIiRtZTogdG9vIG1hbnkgYXJndW1l
bnRzJGhlbHAiID4mMgorICBleGl0IDEKK2ZpCisKK3RyYXAgJ2V4aXQgMScgMSAyIDE1CisKKyMg
Q0NfRk9SX0JVSUxEIC0tIGNvbXBpbGVyIHVzZWQgYnkgdGhpcyBzY3JpcHQuIE5vdGUgdGhhdCB0
aGUgdXNlIG9mIGEKKyMgY29tcGlsZXIgdG8gYWlkIGluIHN5c3RlbSBkZXRlY3Rpb24gaXMgZGlz
Y291cmFnZWQgYXMgaXQgcmVxdWlyZXMKKyMgdGVtcG9yYXJ5IGZpbGVzIHRvIGJlIGNyZWF0ZWQg
YW5kLCBhcyB5b3UgY2FuIHNlZSBiZWxvdywgaXQgaXMgYQorIyBoZWFkYWNoZSB0byBkZWFsIHdp
dGggaW4gYSBwb3J0YWJsZSBmYXNoaW9uLgorCisjIEhpc3RvcmljYWxseSwgYENDX0ZPUl9CVUlM
RCcgdXNlZCB0byBiZSBuYW1lZCBgSE9TVF9DQycuIFdlIHN0aWxsCisjIHVzZSBgSE9TVF9DQycg
aWYgZGVmaW5lZCwgYnV0IGl0IGlzIGRlcHJlY2F0ZWQuCisKKyMgUG9ydGFibGUgdG1wIGRpcmVj
dG9yeSBjcmVhdGlvbiBpbnNwaXJlZCBieSB0aGUgQXV0b2NvbmYgdGVhbS4KKworc2V0X2NjX2Zv
cl9idWlsZD0nCit0cmFwICJleGl0Y29kZT1cJD87IChybSAtZiBcJHRtcGZpbGVzIDI+L2Rldi9u
dWxsOyBybWRpciBcJHRtcCAyPi9kZXYvbnVsbCkgJiYgZXhpdCBcJGV4aXRjb2RlIiAwIDsKK3Ry
YXAgInJtIC1mIFwkdG1wZmlsZXMgMj4vZGV2L251bGw7IHJtZGlyIFwkdG1wIDI+L2Rldi9udWxs
OyBleGl0IDEiIDEgMiAxMyAxNSA7Cis6ICR7VE1QRElSPS90bXB9IDsKKyB7IHRtcD1gKHVtYXNr
IDA3NyAmJiBta3RlbXAgLWQgIiRUTVBESVIvY2dYWFhYWFgiKSAyPi9kZXYvbnVsbGAgJiYgdGVz
dCAtbiAiJHRtcCIgJiYgdGVzdCAtZCAiJHRtcCIgOyB9IHx8CisgeyB0ZXN0IC1uICIkUkFORE9N
IiAmJiB0bXA9JFRNUERJUi9jZyQkLSRSQU5ET00gJiYgKHVtYXNrIDA3NyAmJiBta2RpciAkdG1w
KSA7IH0gfHwKKyB7IHRtcD0kVE1QRElSL2NnLSQkICYmICh1bWFzayAwNzcgJiYgbWtkaXIgJHRt
cCkgJiYgZWNobyAiV2FybmluZzogY3JlYXRpbmcgaW5zZWN1cmUgdGVtcCBkaXJlY3RvcnkiID4m
MiA7IH0gfHwKKyB7IGVjaG8gIiRtZTogY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFyeSBkaXJlY3Rv
cnkgaW4gJFRNUERJUiIgPiYyIDsgZXhpdCAxIDsgfSA7CitkdW1teT0kdG1wL2R1bW15IDsKK3Rt
cGZpbGVzPSIkZHVtbXkuYyAkZHVtbXkubyAkZHVtbXkucmVsICRkdW1teSIgOworY2FzZSAkQ0Nf
Rk9SX0JVSUxELCRIT1NUX0NDLCRDQyBpbgorICwsKSAgICBlY2hvICJpbnQgeDsiID4gJGR1bW15
LmMgOworCWZvciBjIGluIGNjIGdjYyBjODkgYzk5IDsgZG8KKwkgIGlmICgkYyAtYyAtbyAkZHVt
bXkubyAkZHVtbXkuYykgPi9kZXYvbnVsbCAyPiYxIDsgdGhlbgorCSAgICAgQ0NfRk9SX0JVSUxE
PSIkYyI7IGJyZWFrIDsKKwkgIGZpIDsKKwlkb25lIDsKKwlpZiB0ZXN0IHgiJENDX0ZPUl9CVUlM
RCIgPSB4IDsgdGhlbgorCSAgQ0NfRk9SX0JVSUxEPW5vX2NvbXBpbGVyX2ZvdW5kIDsKKwlmaQor
CTs7CisgLCwqKSAgIENDX0ZPUl9CVUlMRD0kQ0MgOzsKKyAsKiwqKSAgQ0NfRk9SX0JVSUxEPSRI
T1NUX0NDIDs7Citlc2FjIDsgc2V0X2NjX2Zvcl9idWlsZD0gOycKKworIyBUaGlzIGlzIG5lZWRl
ZCB0byBmaW5kIHVuYW1lIG9uIGEgUHlyYW1pZCBPU3ggd2hlbiBydW4gaW4gdGhlIEJTRCB1bml2
ZXJzZS4KKyMgKGdoYXppQG5vYy5ydXRnZXJzLmVkdSAxOTk0LTA4LTI0KQoraWYgKHRlc3QgLWYg
Ly5hdHRiaW4vdW5hbWUpID4vZGV2L251bGwgMj4mMSA7IHRoZW4KKwlQQVRIPSRQQVRIOi8uYXR0
YmluIDsgZXhwb3J0IFBBVEgKK2ZpCisKK1VOQU1FX01BQ0hJTkU9YCh1bmFtZSAtbSkgMj4vZGV2
L251bGxgIHx8IFVOQU1FX01BQ0hJTkU9dW5rbm93bgorVU5BTUVfUkVMRUFTRT1gKHVuYW1lIC1y
KSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfUkVMRUFTRT11bmtub3duCitVTkFNRV9TWVNURU09YCh1
bmFtZSAtcykgMj4vZGV2L251bGxgICB8fCBVTkFNRV9TWVNURU09dW5rbm93bgorVU5BTUVfVkVS
U0lPTj1gKHVuYW1lIC12KSAyPi9kZXYvbnVsbGAgfHwgVU5BTUVfVkVSU0lPTj11bmtub3duCisK
KyMgTm90ZTogb3JkZXIgaXMgc2lnbmlmaWNhbnQgLSB0aGUgY2FzZSBicmFuY2hlcyBhcmUgbm90
IGV4Y2x1c2l2ZS4KKworY2FzZSAiJHtVTkFNRV9NQUNISU5FfToke1VOQU1FX1NZU1RFTX06JHtV
TkFNRV9SRUxFQVNFfToke1VOQU1FX1ZFUlNJT059IiBpbgorICAgICo6TmV0QlNEOio6KikKKwkj
IE5ldEJTRCAobmJzZCkgdGFyZ2V0cyBzaG91bGQgKHdoZXJlIGFwcGxpY2FibGUpIG1hdGNoIG9u
ZSBvcgorCSMgbW9yZSBvZiB0aGUgdHVwcGxlczogKi0qLW5ldGJzZGVsZiosICotKi1uZXRic2Rh
b3V0KiwKKwkjICotKi1uZXRic2RlY29mZiogYW5kICotKi1uZXRic2QqLiAgRm9yIHRhcmdldHMg
dGhhdCByZWNlbnRseQorCSMgc3dpdGNoZWQgdG8gRUxGLCAqLSotbmV0YnNkKiB3b3VsZCBzZWxl
Y3QgdGhlIG9sZAorCSMgb2JqZWN0IGZpbGUgZm9ybWF0LiAgVGhpcyBwcm92aWRlcyBib3RoIGZv
cndhcmQKKwkjIGNvbXBhdGliaWxpdHkgYW5kIGEgY29uc2lzdGVudCBtZWNoYW5pc20gZm9yIHNl
bGVjdGluZyB0aGUKKwkjIG9iamVjdCBmaWxlIGZvcm1hdC4KKwkjCisJIyBOb3RlOiBOZXRCU0Qg
ZG9lc24ndCBwYXJ0aWN1bGFybHkgY2FyZSBhYm91dCB0aGUgdmVuZG9yCisJIyBwb3J0aW9uIG9m
IHRoZSBuYW1lLiAgV2UgYWx3YXlzIHNldCBpdCB0byAidW5rbm93biIuCisJc3lzY3RsPSJzeXNj
dGwgLW4gaHcubWFjaGluZV9hcmNoIgorCVVOQU1FX01BQ0hJTkVfQVJDSD1gKC9zYmluLyRzeXNj
dGwgMj4vZGV2L251bGwgfHwgXAorCSAgICAvdXNyL3NiaW4vJHN5c2N0bCAyPi9kZXYvbnVsbCB8
fCBlY2hvIHVua25vd24pYAorCWNhc2UgIiR7VU5BTUVfTUFDSElORV9BUkNIfSIgaW4KKwkgICAg
YXJtZWIpIG1hY2hpbmU9YXJtZWItdW5rbm93biA7OworCSAgICBhcm0qKSBtYWNoaW5lPWFybS11
bmtub3duIDs7CisJICAgIHNoM2VsKSBtYWNoaW5lPXNobC11bmtub3duIDs7CisJICAgIHNoM2Vi
KSBtYWNoaW5lPXNoLXVua25vd24gOzsKKwkgICAgc2g1ZWwpIG1hY2hpbmU9c2g1bGUtdW5rbm93
biA7OworCSAgICAqKSBtYWNoaW5lPSR7VU5BTUVfTUFDSElORV9BUkNIfS11bmtub3duIDs7CisJ
ZXNhYworCSMgVGhlIE9wZXJhdGluZyBTeXN0ZW0gaW5jbHVkaW5nIG9iamVjdCBmb3JtYXQsIGlm
IGl0IGhhcyBzd2l0Y2hlZAorCSMgdG8gRUxGIHJlY2VudGx5LCBvciB3aWxsIGluIHRoZSBmdXR1
cmUuCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FX0FSQ0h9IiBpbgorCSAgICBhcm0qfGkzODZ8bTY4
a3xuczMya3xzaDMqfHNwYXJjfHZheCkKKwkJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorCQlpZiBl
Y2hvIF9fRUxGX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwgXAorCQkJfCBncmVw
IC1xIF9fRUxGX18KKwkJdGhlbgorCQkgICAgIyBPbmNlIGFsbCB1dGlsaXRpZXMgY2FuIGJlIEVD
T0ZGIChuZXRic2RlY29mZikgb3IgYS5vdXQgKG5ldGJzZGFvdXQpLgorCQkgICAgIyBSZXR1cm4g
bmV0YnNkIGZvciBlaXRoZXIuICBGSVg/CisJCSAgICBvcz1uZXRic2QKKwkJZWxzZQorCQkgICAg
b3M9bmV0YnNkZWxmCisJCWZpCisJCTs7CisJICAgICopCisJCW9zPW5ldGJzZAorCQk7OworCWVz
YWMKKwkjIFRoZSBPUyByZWxlYXNlCisJIyBEZWJpYW4gR05VL05ldEJTRCBtYWNoaW5lcyBoYXZl
IGEgZGlmZmVyZW50IHVzZXJsYW5kLCBhbmQKKwkjIHRodXMsIG5lZWQgYSBkaXN0aW5jdCB0cmlw
bGV0LiBIb3dldmVyLCB0aGV5IGRvIG5vdCBuZWVkCisJIyBrZXJuZWwgdmVyc2lvbiBpbmZvcm1h
dGlvbiwgc28gaXQgY2FuIGJlIHJlcGxhY2VkIHdpdGggYQorCSMgc3VpdGFibGUgdGFnLCBpbiB0
aGUgc3R5bGUgb2YgbGludXgtZ251LgorCWNhc2UgIiR7VU5BTUVfVkVSU0lPTn0iIGluCisJICAg
IERlYmlhbiopCisJCXJlbGVhc2U9Jy1nbnUnCisJCTs7CisJICAgICopCisJCXJlbGVhc2U9YGVj
aG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy1fXS4qL1wuLydgCisJCTs7CisJZXNhYwor
CSMgU2luY2UgQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVSQVRJTkdfU1lTVEVNOgor
CSMgY29udGFpbnMgcmVkdW5kYW50IGluZm9ybWF0aW9uLCB0aGUgc2hvcnRlciBmb3JtOgorCSMg
Q1BVX1RZUEUtTUFOVUZBQ1RVUkVSLU9QRVJBVElOR19TWVNURU0gaXMgdXNlZC4KKwllY2hvICIk
e21hY2hpbmV9LSR7b3N9JHtyZWxlYXNlfSIKKwlleGl0IDs7CisgICAgKjpPcGVuQlNEOio6KikK
KwlVTkFNRV9NQUNISU5FX0FSQ0g9YGFyY2ggfCBzZWQgJ3MvT3BlbkJTRC4vLydgCisJZWNobyAk
e1VOQU1FX01BQ0hJTkVfQVJDSH0tdW5rbm93bi1vcGVuYnNkJHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICAqOmVra29CU0Q6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3du
LWVra29ic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6U29saWRCU0Q6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXNvbGlkYnNkJHtVTkFNRV9SRUxFQVNFfQor
CWV4aXQgOzsKKyAgICBtYWNwcGM6TWlyQlNEOio6KikKKwllY2hvIHBvd2VycGMtdW5rbm93bi1t
aXJic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6TWlyQlNEOio6KikKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1taXJic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGFscGhhOk9TRjE6KjoqKQorCWNhc2UgJFVOQU1FX1JFTEVBU0UgaW4KKwkqNC4wKQor
CQlVTkFNRV9SRUxFQVNFPWAvdXNyL3NiaW4vc2l6ZXIgLXYgfCBhd2sgJ3twcmludCAkM30nYAor
CQk7OworCSo1LiopCisJCVVOQU1FX1JFTEVBU0U9YC91c3Ivc2Jpbi9zaXplciAtdiB8IGF3ayAn
e3ByaW50ICQ0fSdgCisJCTs7CisJZXNhYworCSMgQWNjb3JkaW5nIHRvIENvbXBhcSwgL3Vzci9z
YmluL3BzcmluZm8gaGFzIGJlZW4gYXZhaWxhYmxlIG9uCisJIyBPU0YvMSBhbmQgVHJ1NjQgc3lz
dGVtcyBwcm9kdWNlZCBzaW5jZSAxOTk1LiAgSSBob3BlIHRoYXQKKwkjIGNvdmVycyBtb3N0IHN5
c3RlbXMgcnVubmluZyB0b2RheS4gIFRoaXMgY29kZSBwaXBlcyB0aGUgQ1BVCisJIyB0eXBlcyB0
aHJvdWdoIGhlYWQgLW4gMSwgc28gd2Ugb25seSBkZXRlY3QgdGhlIHR5cGUgb2YgQ1BVIDAuCisJ
QUxQSEFfQ1BVX1RZUEU9YC91c3Ivc2Jpbi9wc3JpbmZvIC12IHwgc2VkIC1uIC1lICdzL14gIFRo
ZSBhbHBoYSBcKC4qXCkgcHJvY2Vzc29yLiokL1wxL3AnIHwgaGVhZCAtbiAxYAorCWNhc2UgIiRB
TFBIQV9DUFVfVFlQRSIgaW4KKwkgICAgIkVWNCAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0i
YWxwaGEiIDs7CisJICAgICJFVjQuNSAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGEi
IDs7CisJICAgICJMQ0E0ICgyMTA2Ni8yMTA2OCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIg
OzsKKwkgICAgIkVWNSAoMjExNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjUiIDs7CisJ
ICAgICJFVjUuNiAoMjExNjRBKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY1NiIgOzsKKwkg
ICAgIkVWNS42ICgyMTE2NFBDKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhcGNhNTYiIDs7CisJ
ICAgICJFVjUuNyAoMjExNjRQQykiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYXBjYTU3IiA7Owor
CSAgICAiRVY2ICgyMTI2NCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NiIgOzsKKwkgICAg
IkVWNi43ICgyMTI2NEEpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY3IiA7OworCSAgICAi
RVY2LjhDQiAoMjEyNjRDKSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OCIgOzsKKwkgICAg
IkVWNi44QUwgKDIxMjY0QikiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjgiIDs7CisJICAg
ICJFVjYuOENYICgyMTI2NEQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY4IiA7OworCSAg
ICAiRVY2LjlBICgyMTI2NC9FVjY5QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjkiIDs7
CisJICAgICJFVjcgKDIxMzY0KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY3IiA7OworCSAg
ICAiRVY3LjkgKDIxMzY0QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NzkiIDs7CisJZXNh
YworCSMgQSBQbi5uIHZlcnNpb24gaXMgYSBwYXRjaGVkIHZlcnNpb24uCisJIyBBIFZuLm4gdmVy
c2lvbiBpcyBhIHJlbGVhc2VkIHZlcnNpb24uCisJIyBBIFRuLm4gdmVyc2lvbiBpcyBhIHJlbGVh
c2VkIGZpZWxkIHRlc3QgdmVyc2lvbi4KKwkjIEEgWG4ubiB2ZXJzaW9uIGlzIGFuIHVucmVsZWFz
ZWQgZXhwZXJpbWVudGFsIGJhc2VsZXZlbC4KKwkjIDEuMiB1c2VzICIxLjIiIGZvciB1bmFtZSAt
ci4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tZGVjLW9zZmBlY2hvICR7VU5BTUVfUkVMRUFTRX0g
fCBzZWQgLWUgJ3MvXltQVlRYXS8vJyB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicg
J2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6J2AKKwkjIFJlc2V0IEVYSVQgdHJhcCBiZWZvcmUg
ZXhpdGluZyB0byBhdm9pZCBzcHVyaW91cyBub24temVybyBleGl0IGNvZGUuCisJZXhpdGNvZGU9
JD8KKwl0cmFwICcnIDAKKwlleGl0ICRleGl0Y29kZSA7OworICAgIEFscGhhXCAqOldpbmRvd3Nf
TlQqOiopCisJIyBIb3cgZG8gd2Uga25vdyBpdCdzIEludGVyaXggcmF0aGVyIHRoYW4gdGhlIGdl
bmVyaWMgUE9TSVggc3Vic3lzdGVtPworCSMgU2hvdWxkIHdlIGNoYW5nZSBVTkFNRV9NQUNISU5F
IGJhc2VkIG9uIHRoZSBvdXRwdXQgb2YgdW5hbWUgaW5zdGVhZAorCSMgb2YgdGhlIHNwZWNpZmlj
IEFscGhhIG1vZGVsPworCWVjaG8gYWxwaGEtcGMtaW50ZXJpeAorCWV4aXQgOzsKKyAgICAyMTA2
NDpXaW5kb3dzX05UOjUwOjMpCisJZWNobyBhbHBoYS1kZWMtd2lubnQzLjUKKwlleGl0IDs7Cisg
ICAgQW1pZ2EqOlVOSVhfU3lzdGVtX1Y6NC4wOiopCisJZWNobyBtNjhrLXVua25vd24tc3lzdjQK
KwlleGl0IDs7CisgICAgKjpbQWFdbWlnYVtPb11bU3NdOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1hbWlnYW9zCisJZXhpdCA7OworICAgICo6W01tXW9ycGhbT29dW1NzXToq
OiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbW9ycGhvcworCWV4aXQgOzsKKyAg
ICAqOk9TLzM5MDoqOiopCisJZWNobyBpMzcwLWlibS1vcGVuZWRpdGlvbgorCWV4aXQgOzsKKyAg
ICAqOnovVk06KjoqKQorCWVjaG8gczM5MC1pYm0tenZtb2UKKwlleGl0IDs7CisgICAgKjpPUzQw
MDoqOiopCisJZWNobyBwb3dlcnBjLWlibS1vczQwMAorCWV4aXQgOzsKKyAgICBhcm06UklTQyo6
MS5bMDEyXSo6Knxhcm06cmlzY2l4OjEuWzAxMl0qOiopCisJZWNobyBhcm0tYWNvcm4tcmlzY2l4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBhcm06cmlzY29zOio6Knxhcm06UklTQ09T
Oio6KikKKwllY2hvIGFybS11bmtub3duLXJpc2NvcworCWV4aXQgOzsKKyAgICBTUjI/MDE6SEkt
VVgvTVBQOio6KiB8IFNSODAwMDpISS1VWC9NUFA6KjoqKQorCWVjaG8gaHBwYTEuMS1oaXRhY2hp
LWhpdXhtcHAKKwlleGl0IDs7CisgICAgUHlyYW1pZCo6T1N4KjoqOiogfCBNSVMqOk9TeCo6Kjoq
IHwgTUlTKjpTTVBfREMtT1N4KjoqOiopCisJIyBha2VlQHdwZGlzMDMud3BhZmIuYWYubWlsIChF
YXJsZSBGLiBBa2UpIGNvbnRyaWJ1dGVkIE1JUyBhbmQgTklMRS4KKwlpZiB0ZXN0ICJgKC9iaW4v
dW5pdmVyc2UpIDI+L2Rldi9udWxsYCIgPSBhdHQgOyB0aGVuCisJCWVjaG8gcHlyYW1pZC1weXJh
bWlkLXN5c3YzCisJZWxzZQorCQllY2hvIHB5cmFtaWQtcHlyYW1pZC1ic2QKKwlmaQorCWV4aXQg
OzsKKyAgICBOSUxFKjoqOio6ZGNvc3gpCisJZWNobyBweXJhbWlkLXB5cmFtaWQtc3ZyNAorCWV4
aXQgOzsKKyAgICBEUlM/NjAwMDp1bml4OjQuMDo2KikKKwllY2hvIHNwYXJjLWljbC1ueDYKKwll
eGl0IDs7CisgICAgRFJTPzYwMDA6VU5JWF9TVjo0LjIqOjcqIHwgRFJTPzYwMDA6aXNpczo0LjIq
OjcqKQorCWNhc2UgYC91c3IvYmluL3VuYW1lIC1wYCBpbgorCSAgICBzcGFyYykgZWNobyBzcGFy
Yy1pY2wtbng3OyBleGl0IDs7CisJZXNhYyA7OworICAgIHMzOTB4OlN1bk9TOio6KikKKwllY2hv
ICR7VU5BTUVfTUFDSElORX0taWJtLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQg
LWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjRIOlN1bk9TOjUuKjoqKQorCWVjaG8g
c3BhcmMtaGFsLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSov
LydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjUuKjoqIHwgdGFkcG9sZSo6U3VuT1M6NS4q
OiopCisJZWNobyBzcGFyYy1zdW4tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgaTg2cGM6QXVyb3JhVVg6NS4qOiogfCBpODZ4
ZW46QXVyb3JhVVg6NS4qOiopCisJZWNobyBpMzg2LXBjLWF1cm9yYXV4JHtVTkFNRV9SRUxFQVNF
fQorCWV4aXQgOzsKKyAgICBpODZwYzpTdW5PUzo1Lio6KiB8IGk4NnhlbjpTdW5PUzo1Lio6KikK
KwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJU1VOX0FSQ0g9ImkzODYiCisJIyBJZiB0aGVyZSBp
cyBhIGNvbXBpbGVyLCBzZWUgaWYgaXQgaXMgY29uZmlndXJlZCBmb3IgNjQtYml0IG9iamVjdHMu
CisJIyBOb3RlIHRoYXQgdGhlIFN1biBjYyBkb2VzIG5vdCB0dXJuIF9fTFA2NF9fIGludG8gMSBs
aWtlIGdjYyBkb2VzLgorCSMgVGhpcyB0ZXN0IHdvcmtzIGZvciBib3RoIGNvbXBpbGVycy4KKwlp
ZiBbICIkQ0NfRk9SX0JVSUxEIiAhPSAnbm9fY29tcGlsZXJfZm91bmQnIF07IHRoZW4KKwkgICAg
aWYgKGVjaG8gJyNpZmRlZiBfX2FtZDY0JzsgZWNobyBJU182NEJJVF9BUkNIOyBlY2hvICcjZW5k
aWYnKSB8IFwKKwkJKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8IFwK
KwkJZ3JlcCBJU182NEJJVF9BUkNIID4vZGV2L251bGwKKwkgICAgdGhlbgorCQlTVU5fQVJDSD0i
eDg2XzY0IgorCSAgICBmaQorCWZpCisJZWNobyAke1NVTl9BUkNIfS1wYy1zb2xhcmlzMmBlY2hv
ICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsKKyAgICBzdW40
KjpTdW5PUzo2KjoqKQorCSMgQWNjb3JkaW5nIHRvIGNvbmZpZy5zdWIsIHRoaXMgaXMgdGhlIHBy
b3BlciB3YXkgdG8gY2Fub25pY2FsaXplCisJIyBTdW5PUzYuICBIYXJkIHRvIGd1ZXNzIGV4YWN0
bHkgd2hhdCBTdW5PUzYgd2lsbCBiZSBsaWtlLCBidXQKKwkjIGl0J3MgbGlrZWx5IHRvIGJlIG1v
cmUgbGlrZSBTb2xhcmlzIHRoYW4gU3VuT1M0LgorCWVjaG8gc3BhcmMtc3VuLXNvbGFyaXMzYGVj
aG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1
bjQqOlN1bk9TOio6KikKKwljYXNlICJgL3Vzci9iaW4vYXJjaCAta2AiIGluCisJICAgIFNlcmll
cyp8UzQqKQorCQlVTkFNRV9SRUxFQVNFPWB1bmFtZSAtdmAKKwkJOzsKKwllc2FjCisJIyBKYXBh
bmVzZSBMYW5ndWFnZSB2ZXJzaW9ucyBoYXZlIGEgdmVyc2lvbiBudW1iZXIgbGlrZSBgNC4xLjMt
SkwnLgorCWVjaG8gc3BhcmMtc3VuLXN1bm9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUg
J3MvLS9fLydgCisJZXhpdCA7OworICAgIHN1bjMqOlN1bk9TOio6KikKKwllY2hvIG02OGstc3Vu
LXN1bm9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBzdW4qOio6NC4yQlNEOiopCisJ
VU5BTUVfUkVMRUFTRT1gKHNlZCAxcSAvZXRjL21vdGQgfCBhd2sgJ3twcmludCBzdWJzdHIoJDUs
MSwzKX0nKSAyPi9kZXYvbnVsbGAKKwl0ZXN0ICJ4JHtVTkFNRV9SRUxFQVNFfSIgPSAieCIgJiYg
VU5BTUVfUkVMRUFTRT0zCisJY2FzZSAiYC9iaW4vYXJjaGAiIGluCisJICAgIHN1bjMpCisJCWVj
aG8gbTY4ay1zdW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJCTs7CisJICAgIHN1bjQpCisJCWVj
aG8gc3BhcmMtc3VuLXN1bm9zJHtVTkFNRV9SRUxFQVNFfQorCQk7OworCWVzYWMKKwlleGl0IDs7
CisgICAgYXVzaHA6U3VuT1M6KjoqKQorCWVjaG8gc3BhcmMtYXVzcGV4LXN1bm9zJHtVTkFNRV9S
RUxFQVNFfQorCWV4aXQgOzsKKyAgICAjIFRoZSBzaXR1YXRpb24gZm9yIE1pTlQgaXMgYSBsaXR0
bGUgY29uZnVzaW5nLiAgVGhlIG1hY2hpbmUgbmFtZQorICAgICMgY2FuIGJlIHZpcnR1YWxseSBl
dmVyeXRoaW5nIChldmVyeXRoaW5nIHdoaWNoIGlzIG5vdAorICAgICMgImF0YXJpc3QiIG9yICJh
dGFyaXN0ZSIgYXQgbGVhc3Qgc2hvdWxkIGhhdmUgYSBwcm9jZXNzb3IKKyAgICAjID4gbTY4MDAw
KS4gIFRoZSBzeXN0ZW0gbmFtZSByYW5nZXMgZnJvbSAiTWlOVCIgb3ZlciAiRnJlZU1pTlQiCisg
ICAgIyB0byB0aGUgbG93ZXJjYXNlIHZlcnNpb24gIm1pbnQiIChvciAiZnJlZW1pbnQiKS4gIEZp
bmFsbHkKKyAgICAjIHRoZSBzeXN0ZW0gbmFtZSAiVE9TIiBkZW5vdGVzIGEgc3lzdGVtIHdoaWNo
IGlzIGFjdHVhbGx5IG5vdAorICAgICMgTWlOVC4gIEJ1dCBNaU5UIGlzIGRvd253YXJkIGNvbXBh
dGlibGUgdG8gVE9TLCBzbyB0aGlzIHNob3VsZAorICAgICMgYmUgbm8gcHJvYmxlbS4KKyAgICBh
dGFyaXN0W2VdOipNaU5UOio6KiB8IGF0YXJpc3RbZV06Km1pbnQ6KjoqIHwgYXRhcmlzdFtlXToq
VE9TOio6KikKKwllY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgYXRhcmkqOipNaU5UOio6KiB8IGF0YXJpKjoqbWludDoqOiogfCBhdGFyaXN0W2VdOipU
T1M6KjoqKQorCWVjaG8gbTY4ay1hdGFyaS1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsK
KyAgICAqZmFsY29uKjoqTWlOVDoqOiogfCAqZmFsY29uKjoqbWludDoqOiogfCAqZmFsY29uKjoq
VE9TOio6KikKKwllY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgbWlsYW4qOipNaU5UOio6KiB8IG1pbGFuKjoqbWludDoqOiogfCAqbWlsYW4qOipUT1M6
KjoqKQorCWVjaG8gbTY4ay1taWxhbi1taW50JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAg
ICBoYWRlcyo6Kk1pTlQ6KjoqIHwgaGFkZXMqOiptaW50Oio6KiB8ICpoYWRlcyo6KlRPUzoqOiop
CisJZWNobyBtNjhrLWhhZGVzLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6
Kk1pTlQ6KjoqIHwgKjoqbWludDoqOiogfCAqOipUT1M6KjoqKQorCWVjaG8gbTY4ay11bmtub3du
LW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG02OGs6bWFjaHRlbjoqOiopCisJ
ZWNobyBtNjhrLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHBv
d2VycGM6bWFjaHRlbjoqOiopCisJZWNobyBwb3dlcnBjLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIFJJU0MqOk1hY2g6KjoqKQorCWVjaG8gbWlwcy1kZWMtbWFj
aF9ic2Q0LjMKKwlleGl0IDs7CisgICAgUklTQyo6VUxUUklYOio6KikKKwllY2hvIG1pcHMtZGVj
LXVsdHJpeCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgVkFYKjpVTFRSSVgqOio6KikK
KwllY2hvIHZheC1kZWMtdWx0cml4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAyMDIw
OkNMSVg6KjoqIHwgMjQzMDpDTElYOio6KikKKwllY2hvIGNsaXBwZXItaW50ZXJncmFwaC1jbGl4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBtaXBzOio6KjpVTUlQUyB8IG1pcHM6Kjoq
OlJJU0NvcykKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+
JGR1bW15LmMKKyNpZmRlZiBfX2NwbHVzcGx1cworI2luY2x1ZGUgPHN0ZGlvLmg+ICAvKiBmb3Ig
cHJpbnRmKCkgcHJvdG90eXBlICovCisJaW50IG1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10p
IHsKKyNlbHNlCisJaW50IG1haW4gKGFyZ2MsIGFyZ3YpIGludCBhcmdjOyBjaGFyICphcmd2W107
IHsKKyNlbmRpZgorCSNpZiBkZWZpbmVkIChob3N0X21pcHMpICYmIGRlZmluZWQgKE1JUFNFQikK
KwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9TWVNWKQorCSAgcHJpbnRmICgibWlwcy1taXBzLXJpc2Nv
cyVzc3lzdlxuIiwgYXJndlsxXSk7IGV4aXQgKDApOworCSNlbmRpZgorCSNpZiBkZWZpbmVkIChT
WVNUWVBFX1NWUjQpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzdnI0XG4iLCBhcmd2
WzFdKTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfQlNENDMpIHx8
IGRlZmluZWQoU1lTVFlQRV9CU0QpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNic2Rc
biIsIGFyZ3ZbMV0pOyBleGl0ICgwKTsKKwkjZW5kaWYKKwkjZW5kaWYKKwkgIGV4aXQgKC0xKTsK
Kwl9CitFT0YKKwkkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAmJgorCSAgZHVtbXlh
cmc9YGVjaG8gIiR7VU5BTUVfUkVMRUFTRX0iIHwgc2VkIC1uICdzL1woWzAtOV0qXCkuKi9cMS9w
J2AgJiYKKwkgIFNZU1RFTV9OQU1FPWAkZHVtbXkgJGR1bW15YXJnYCAmJgorCSAgICB7IGVjaG8g
IiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKwllY2hvIG1pcHMtbWlwcy1yaXNjb3Mke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIE1vdG9yb2xhOlBvd2VyTUFYX09TOio6KikKKwllY2hvIHBv
d2VycGMtbW90b3JvbGEtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTW90b3JvbGE6Kjo0LjM6UEw4
LSopCisJZWNobyBwb3dlcnBjLWhhcnJpcy1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBOaWdodF9I
YXdrOio6KjpQb3dlck1BWF9PUyB8IFN5bmVyZ3k6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93
ZXJwYy1oYXJyaXMtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTmlnaHRfSGF3azpQb3dlcl9VTklY
Oio6KikKKwllY2hvIHBvd2VycGMtaGFycmlzLXBvd2VydW5peAorCWV4aXQgOzsKKyAgICBtODhr
OkNYL1VYOjcqOiopCisJZWNobyBtODhrLWhhcnJpcy1jeHV4NworCWV4aXQgOzsKKyAgICBtODhr
Oio6NCo6UjQqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2NAorCWV4aXQgOzsKKyAgICBtODhr
Oio6Myo6UjMqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2MworCWV4aXQgOzsKKyAgICBBVmlp
T046ZGd1eDoqOiopCisJIyBERy9VWCByZXR1cm5zIEFWaWlPTiBmb3IgYWxsIGFyY2hpdGVjdHVy
ZXMKKwlVTkFNRV9QUk9DRVNTT1I9YC91c3IvYmluL3VuYW1lIC1wYAorCWlmIFsgJFVOQU1FX1BS
T0NFU1NPUiA9IG1jODgxMDAgXSB8fCBbICRVTkFNRV9QUk9DRVNTT1IgPSBtYzg4MTEwIF0KKwl0
aGVuCisJICAgIGlmIFsgJHtUQVJHRVRfQklOQVJZX0lOVEVSRkFDRX14ID0gbTg4a2RndXhlbGZ4
IF0gfHwgXAorCSAgICAgICBbICR7VEFSR0VUX0JJTkFSWV9JTlRFUkZBQ0V9eCA9IHggXQorCSAg
ICB0aGVuCisJCWVjaG8gbTg4ay1kZy1kZ3V4JHtVTkFNRV9SRUxFQVNFfQorCSAgICBlbHNlCisJ
CWVjaG8gbTg4ay1kZy1kZ3V4YmNzJHtVTkFNRV9SRUxFQVNFfQorCSAgICBmaQorCWVsc2UKKwkg
ICAgZWNobyBpNTg2LWRnLWRndXgke1VOQU1FX1JFTEVBU0V9CisJZmkKKwlleGl0IDs7CisgICAg
TTg4KjpEb2xwaGluT1M6KjoqKQkjIERvbHBoaW5PUyAoU1ZSMykKKwllY2hvIG04OGstZG9scGhp
bi1zeXN2MworCWV4aXQgOzsKKyAgICBNODgqOio6UjMqOiopCisJIyBEZWx0YSA4OGsgc3lzdGVt
IHJ1bm5pbmcgU1ZSMworCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2MworCWV4aXQgOzsKKyAgICBY
RDg4KjoqOio6KikgIyBUZWt0cm9uaXggWEQ4OCBzeXN0ZW0gcnVubmluZyBVVGVrViAoU1ZSMykK
KwllY2hvIG04OGstdGVrdHJvbml4LXN5c3YzCisJZXhpdCA7OworICAgIFRlazQzWzAtOV1bMC05
XTpVVGVrOio6KikgIyBUZWt0cm9uaXggNDMwMCBzeXN0ZW0gcnVubmluZyBVVGVrIChCU0QpCisJ
ZWNobyBtNjhrLXRla3Ryb25peC1ic2QKKwlleGl0IDs7CisgICAgKjpJUklYKjoqOiopCisJZWNo
byBtaXBzLXNnaS1pcml4YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvLS9fL2cnYAor
CWV4aXQgOzsKKyAgICA/Pz8/Pz8/PzpBSVg/OlsxMl0uMToyKSAgICMgQUlYIDIuMi4xIG9yIEFJ
WCAyLjEuMSBpcyBSVC9QQyBBSVguCisJZWNobyByb21wLWlibS1haXggICAgICMgdW5hbWUgLW0g
Z2l2ZXMgYW4gOCBoZXgtY29kZSBDUFUgaWQKKwlleGl0IDs7ICAgICAgICAgICAgICAgIyBOb3Rl
IHRoYXQ6IGVjaG8gIidgdW5hbWUgLXNgJyIgZ2l2ZXMgJ0FJWCAnCisgICAgaSo4NjpBSVg6Kjoq
KQorCWVjaG8gaTM4Ni1pYm0tYWl4CisJZXhpdCA7OworICAgIGlhNjQ6QUlYOio6KikKKwlpZiBb
IC14IC91c3IvYmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1gL3Vzci9iaW4vb3NsZXZl
bGAKKwllbHNlCisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VOQU1FX1JFTEVBU0V9CisJ
ZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0taWJtLWFpeCR7SUJNX1JFVn0KKwlleGl0IDs7Cisg
ICAgKjpBSVg6MjozKQorCWlmIGdyZXAgYm9zMzI1IC91c3IvaW5jbHVkZS9zdGRpby5oID4vZGV2
L251bGwgMj4mMTsgdGhlbgorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCXNlZCAncy9eCQkv
LycgPDwgRU9GID4kZHVtbXkuYworCQkjaW5jbHVkZSA8c3lzL3N5c3RlbWNmZy5oPgorCisJCW1h
aW4oKQorCQkJeworCQkJaWYgKCFfX3Bvd2VyX3BjKCkpCisJCQkJZXhpdCgxKTsKKwkJCXB1dHMo
InBvd2VycGMtaWJtLWFpeDMuMi41Iik7CisJCQlleGl0KDApOworCQkJfQorRU9GCisJCWlmICRD
Q19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmIFNZU1RFTV9OQU1FPWAkZHVtbXlgCisJ
CXRoZW4KKwkJCWVjaG8gIiRTWVNURU1fTkFNRSIKKwkJZWxzZQorCQkJZWNobyByczYwMDAtaWJt
LWFpeDMuMi41CisJCWZpCisJZWxpZiBncmVwIGJvczMyNCAvdXNyL2luY2x1ZGUvc3RkaW8uaCA+
L2Rldi9udWxsIDI+JjE7IHRoZW4KKwkJZWNobyByczYwMDAtaWJtLWFpeDMuMi40CisJZWxzZQor
CQllY2hvIHJzNjAwMC1pYm0tYWl4My4yCisJZmkKKwlleGl0IDs7CisgICAgKjpBSVg6KjpbNDU2
N10pCisJSUJNX0NQVV9JRD1gL3Vzci9zYmluL2xzZGV2IC1DIC1jIHByb2Nlc3NvciAtUyBhdmFp
bGFibGUgfCBzZWQgMXEgfCBhd2sgJ3sgcHJpbnQgJDEgfSdgCisJaWYgL3Vzci9zYmluL2xzYXR0
ciAtRWwgJHtJQk1fQ1BVX0lEfSB8IGdyZXAgJyBQT1dFUicgPi9kZXYvbnVsbCAyPiYxOyB0aGVu
CisJCUlCTV9BUkNIPXJzNjAwMAorCWVsc2UKKwkJSUJNX0FSQ0g9cG93ZXJwYworCWZpCisJaWYg
WyAteCAvdXNyL2Jpbi9vc2xldmVsIF0gOyB0aGVuCisJCUlCTV9SRVY9YC91c3IvYmluL29zbGV2
ZWxgCisJZWxzZQorCQlJQk1fUkVWPSR7VU5BTUVfVkVSU0lPTn0uJHtVTkFNRV9SRUxFQVNFfQor
CWZpCisJZWNobyAke0lCTV9BUkNIfS1pYm0tYWl4JHtJQk1fUkVWfQorCWV4aXQgOzsKKyAgICAq
OkFJWDoqOiopCisJZWNobyByczYwMDAtaWJtLWFpeAorCWV4aXQgOzsKKyAgICBpYm1ydDo0LjRC
U0Q6Knxyb21wLWlibTpCU0Q6KikKKwllY2hvIHJvbXAtaWJtLWJzZDQuNAorCWV4aXQgOzsKKyAg
ICBpYm1ydDoqQlNEOip8cm9tcC1pYm06QlNEOiopICAgICAgICAgICAgIyBjb3ZlcnMgUlQvUEMg
QlNEIGFuZAorCWVjaG8gcm9tcC1pYm0tYnNkJHtVTkFNRV9SRUxFQVNFfSAgICMgNC4zIHdpdGgg
dW5hbWUgYWRkZWQgdG8KKwlleGl0IDs7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHJl
cG9ydDogcm9tcC1pYm0gQlNEIDQuMworICAgICo6Qk9TWDoqOiopCisJZWNobyByczYwMDAtYnVs
bC1ib3N4CisJZXhpdCA7OworICAgIERQWC8yPzAwOkIuTy5TLjoqOiopCisJZWNobyBtNjhrLWJ1
bGwtc3lzdjMKKwlleGl0IDs7CisgICAgOTAwMC9bMzRdPz86NC4zYnNkOjEuKjoqKQorCWVjaG8g
bTY4ay1ocC1ic2QKKwlleGl0IDs7CisgICAgaHAzMDA6NC40QlNEOio6KiB8IDkwMDAvWzM0XT8/
OjQuM2JzZDoyLio6KikKKwllY2hvIG02OGstaHAtYnNkNC40CisJZXhpdCA7OworICAgIDkwMDAv
WzM0Njc4XT8/OkhQLVVYOio6KikKKwlIUFVYX1JFVj1gZWNobyAke1VOQU1FX1JFTEVBU0V9fHNl
ZCAtZSAncy9bXi5dKi5bMEJdKi8vJ2AKKwljYXNlICIke1VOQU1FX01BQ0hJTkV9IiBpbgorCSAg
ICA5MDAwLzMxPyApICAgICAgICAgICAgSFBfQVJDSD1tNjgwMDAgOzsKKwkgICAgOTAwMC9bMzRd
Pz8gKSAgICAgICAgIEhQX0FSQ0g9bTY4ayA7OworCSAgICA5MDAwL1s2NzhdWzAtOV1bMC05XSkK
KwkJaWYgWyAteCAvdXNyL2Jpbi9nZXRjb25mIF07IHRoZW4KKwkJICAgIHNjX2NwdV92ZXJzaW9u
PWAvdXNyL2Jpbi9nZXRjb25mIFNDX0NQVV9WRVJTSU9OIDI+L2Rldi9udWxsYAorCQkgICAgc2Nf
a2VybmVsX2JpdHM9YC91c3IvYmluL2dldGNvbmYgU0NfS0VSTkVMX0JJVFMgMj4vZGV2L251bGxg
CisJCSAgICBjYXNlICIke3NjX2NwdV92ZXJzaW9ufSIgaW4KKwkJICAgICAgNTIzKSBIUF9BUkNI
PSJocHBhMS4wIiA7OyAjIENQVV9QQV9SSVNDMV8wCisJCSAgICAgIDUyOCkgSFBfQVJDSD0iaHBw
YTEuMSIgOzsgIyBDUFVfUEFfUklTQzFfMQorCQkgICAgICA1MzIpICAgICAgICAgICAgICAgICAg
ICAgICMgQ1BVX1BBX1JJU0MyXzAKKwkJCWNhc2UgIiR7c2Nfa2VybmVsX2JpdHN9IiBpbgorCQkJ
ICAzMikgSFBfQVJDSD0iaHBwYTIuMG4iIDs7CisJCQkgIDY0KSBIUF9BUkNIPSJocHBhMi4wdyIg
OzsKKwkJCSAgJycpIEhQX0FSQ0g9ImhwcGEyLjAiIDs7ICAgIyBIUC1VWCAxMC4yMAorCQkJZXNh
YyA7OworCQkgICAgZXNhYworCQlmaQorCQlpZiBbICIke0hQX0FSQ0h9IiA9ICIiIF07IHRoZW4K
KwkJICAgIGV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwkJICAgIHNlZCAncy9eCQkvLycgPDwgRU9G
ID4kZHVtbXkuYworCisJCSNkZWZpbmUgX0hQVVhfU09VUkNFCisJCSNpbmNsdWRlIDxzdGRsaWIu
aD4KKwkJI2luY2x1ZGUgPHVuaXN0ZC5oPgorCisJCWludCBtYWluICgpCisJCXsKKwkJI2lmIGRl
ZmluZWQoX1NDX0tFUk5FTF9CSVRTKQorCQkgICAgbG9uZyBiaXRzID0gc3lzY29uZihfU0NfS0VS
TkVMX0JJVFMpOworCQkjZW5kaWYKKwkJICAgIGxvbmcgY3B1ICA9IHN5c2NvbmYgKF9TQ19DUFVf
VkVSU0lPTik7CisKKwkJICAgIHN3aXRjaCAoY3B1KQorCQkJeworCQkJY2FzZSBDUFVfUEFfUklT
QzFfMDogcHV0cyAoImhwcGExLjAiKTsgYnJlYWs7CisJCQljYXNlIENQVV9QQV9SSVNDMV8xOiBw
dXRzICgiaHBwYTEuMSIpOyBicmVhazsKKwkJCWNhc2UgQ1BVX1BBX1JJU0MyXzA6CisJCSNpZiBk
ZWZpbmVkKF9TQ19LRVJORUxfQklUUykKKwkJCSAgICBzd2l0Y2ggKGJpdHMpCisJCQkJeworCQkJ
CWNhc2UgNjQ6IHB1dHMgKCJocHBhMi4wdyIpOyBicmVhazsKKwkJCQljYXNlIDMyOiBwdXRzICgi
aHBwYTIuMG4iKTsgYnJlYWs7CisJCQkJZGVmYXVsdDogcHV0cyAoImhwcGEyLjAiKTsgYnJlYWs7
CisJCQkJfSBicmVhazsKKwkJI2Vsc2UgIC8qICFkZWZpbmVkKF9TQ19LRVJORUxfQklUUykgKi8K
KwkJCSAgICBwdXRzICgiaHBwYTIuMCIpOyBicmVhazsKKwkJI2VuZGlmCisJCQlkZWZhdWx0OiBw
dXRzICgiaHBwYTEuMCIpOyBicmVhazsKKwkJCX0KKwkJICAgIGV4aXQgKDApOworCQl9CitFT0YK
KwkJICAgIChDQ09QVFM9ICRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jIDI+L2Rldi9u
dWxsKSAmJiBIUF9BUkNIPWAkZHVtbXlgCisJCSAgICB0ZXN0IC16ICIkSFBfQVJDSCIgJiYgSFBf
QVJDSD1ocHBhCisJCWZpIDs7CisJZXNhYworCWlmIFsgJHtIUF9BUkNIfSA9ICJocHBhMi4wdyIg
XQorCXRoZW4KKwkgICAgZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorCisJICAgICMgaHBwYTIuMHct
aHAtaHB1eCogaGFzIGEgNjQtYml0IGtlcm5lbCBhbmQgYSBjb21waWxlciBnZW5lcmF0aW5nCisJ
ICAgICMgMzItYml0IGNvZGUuICBocHBhNjQtaHAtaHB1eCogaGFzIHRoZSBzYW1lIGtlcm5lbCBh
bmQgYSBjb21waWxlcgorCSAgICAjIGdlbmVyYXRpbmcgNjQtYml0IGNvZGUuICBHTlUgYW5kIEhQ
IHVzZSBkaWZmZXJlbnQgbm9tZW5jbGF0dXJlOgorCSAgICAjCisJICAgICMgJCBDQ19GT1JfQlVJ
TEQ9Y2MgLi9jb25maWcuZ3Vlc3MKKwkgICAgIyA9PiBocHBhMi4wdy1ocC1ocHV4MTEuMjMKKwkg
ICAgIyAkIENDX0ZPUl9CVUlMRD0iY2MgK0RBMi4wdyIgLi9jb25maWcuZ3Vlc3MKKwkgICAgIyA9
PiBocHBhNjQtaHAtaHB1eDExLjIzCisKKwkgICAgaWYgZWNobyBfX0xQNjRfXyB8IChDQ09QVFM9
ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCkgfAorCQlncmVwIC1xIF9fTFA2NF9fCisJ
ICAgIHRoZW4KKwkJSFBfQVJDSD0iaHBwYTIuMHciCisJICAgIGVsc2UKKwkJSFBfQVJDSD0iaHBw
YTY0IgorCSAgICBmaQorCWZpCisJZWNobyAke0hQX0FSQ0h9LWhwLWhwdXgke0hQVVhfUkVWfQor
CWV4aXQgOzsKKyAgICBpYTY0OkhQLVVYOio6KikKKwlIUFVYX1JFVj1gZWNobyAke1VOQU1FX1JF
TEVBU0V9fHNlZCAtZSAncy9bXi5dKi5bMEJdKi8vJ2AKKwllY2hvIGlhNjQtaHAtaHB1eCR7SFBV
WF9SRVZ9CisJZXhpdCA7OworICAgIDMwNTAqOkhJLVVYOio6KikKKwlldmFsICRzZXRfY2NfZm9y
X2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+JGR1bW15LmMKKwkjaW5jbHVkZSA8dW5pc3Rk
Lmg+CisJaW50CisJbWFpbiAoKQorCXsKKwkgIGxvbmcgY3B1ID0gc3lzY29uZiAoX1NDX0NQVV9W
RVJTSU9OKTsKKwkgIC8qIFRoZSBvcmRlciBtYXR0ZXJzLCBiZWNhdXNlIENQVV9JU19IUF9NQzY4
SyBlcnJvbmVvdXNseSByZXR1cm5zCisJICAgICB0cnVlIGZvciBDUFVfUEFfUklTQzFfMC4gIENQ
VV9JU19QQV9SSVNDIHJldHVybnMgY29ycmVjdAorCSAgICAgcmVzdWx0cywgaG93ZXZlci4gICov
CisJICBpZiAoQ1BVX0lTX1BBX1JJU0MgKGNwdSkpCisJICAgIHsKKwkgICAgICBzd2l0Y2ggKGNw
dSkKKwkJeworCQkgIGNhc2UgQ1BVX1BBX1JJU0MxXzA6IHB1dHMgKCJocHBhMS4wLWhpdGFjaGkt
aGl1eHdlMiIpOyBicmVhazsKKwkJICBjYXNlIENQVV9QQV9SSVNDMV8xOiBwdXRzICgiaHBwYTEu
MS1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJCSAgY2FzZSBDUFVfUEFfUklTQzJfMDogcHV0
cyAoImhwcGEyLjAtaGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQkgIGRlZmF1bHQ6IHB1dHMg
KCJocHBhLWhpdGFjaGktaGl1eHdlMiIpOyBicmVhazsKKwkJfQorCSAgICB9CisJICBlbHNlIGlm
IChDUFVfSVNfSFBfTUM2OEsgKGNwdSkpCisJICAgIHB1dHMgKCJtNjhrLWhpdGFjaGktaGl1eHdl
MiIpOworCSAgZWxzZSBwdXRzICgidW5rbm93bi1oaXRhY2hpLWhpdXh3ZTIiKTsKKwkgIGV4aXQg
KDApOworCX0KK0VPRgorCSRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmIFNZU1RF
TV9OQU1FPWAkZHVtbXlgICYmCisJCXsgZWNobyAiJFNZU1RFTV9OQU1FIjsgZXhpdDsgfQorCWVj
aG8gdW5rbm93bi1oaXRhY2hpLWhpdXh3ZTIKKwlleGl0IDs7CisgICAgOTAwMC83Pz86NC4zYnNk
Oio6KiB8IDkwMDAvOD9bNzldOjQuM2JzZDoqOiogKQorCWVjaG8gaHBwYTEuMS1ocC1ic2QKKwll
eGl0IDs7CisgICAgOTAwMC84Pz86NC4zYnNkOio6KikKKwllY2hvIGhwcGExLjAtaHAtYnNkCisJ
ZXhpdCA7OworICAgICo5Pz8qOk1QRS9pWDoqOiogfCAqMzAwMCo6TVBFL2lYOio6KikKKwllY2hv
IGhwcGExLjAtaHAtbXBlaXgKKwlleGl0IDs7CisgICAgaHA3Pz86T1NGMToqOiogfCBocDg/Wzc5
XTpPU0YxOio6KiApCisJZWNobyBocHBhMS4xLWhwLW9zZgorCWV4aXQgOzsKKyAgICBocDg/PzpP
U0YxOio6KikKKwllY2hvIGhwcGExLjAtaHAtb3NmCisJZXhpdCA7OworICAgIGkqODY6T1NGMToq
OiopCisJaWYgWyAteCAvdXNyL3NiaW4vc3lzdmVyc2lvbiBdIDsgdGhlbgorCSAgICBlY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1vc2YxbWsKKwllbHNlCisJICAgIGVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLW9zZjEKKwlmaQorCWV4aXQgOzsKKyAgICBwYXJpc2MqOkxpdGVzKjoq
OiopCisJZWNobyBocHBhMS4xLWhwLWxpdGVzCisJZXhpdCA7OworICAgIEMxKjpDb252ZXhPUzoq
OiogfCBjb252ZXg6Q29udmV4T1M6QzEqOiopCisJZWNobyBjMS1jb252ZXgtYnNkCisJZXhpdCA7
OworICAgIEMyKjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzIqOiopCisJaWYgZ2V0
c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhlbiBlY2hvIGMzMi1jb252ZXgtYnNkCisJZWxzZSBl
Y2hvIGMyLWNvbnZleC1ic2QKKwlmaQorCWV4aXQgOzsKKyAgICBDMzQqOkNvbnZleE9TOio6KiB8
IGNvbnZleDpDb252ZXhPUzpDMzQqOiopCisJZWNobyBjMzQtY29udmV4LWJzZAorCWV4aXQgOzsK
KyAgICBDMzgqOkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMzgqOiopCisJZWNobyBj
MzgtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBDNCo6Q29udmV4T1M6KjoqIHwgY29udmV4OkNv
bnZleE9TOkM0KjoqKQorCWVjaG8gYzQtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBDUkFZKlkt
TVA6KjoqOiopCisJZWNobyB5bXAtY3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1l
ICdzL1wuW14uXSokLy5YLycKKwlleGl0IDs7CisgICAgQ1JBWSpbQS1aXTkwOio6KjoqKQorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS1jcmF5LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gXAorCXwgc2Vk
IC1lICdzL0NSQVkuKlwoW0EtWl05MFwpL1wxLycgXAorCSAgICAgIC1lIHkvQUJDREVGR0hJSktM
TU5PUFFSU1RVVldYWVovYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXovIFwKKwkgICAgICAtZSAn
cy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIENSQVkqVFM6KjoqOiopCisJZWNobyB0OTAt
Y3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IHwgc2VkIC1lICdzL1wuW14uXSokLy5YLycKKwll
eGl0IDs7CisgICAgQ1JBWSpUM0U6KjoqOiopCisJZWNobyBhbHBoYWV2NS1jcmF5LXVuaWNvc21r
JHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAg
IENSQVkqU1YxOio6KjoqKQorCWVjaG8gc3YxLWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8
IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgICo6VU5JQ09TL21wOio6KikK
KwllY2hvIGNyYXludi1jcmF5LXVuaWNvc21wJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9c
LlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIEYzMFswMV06VU5JWF9TeXN0ZW1fVjoqOiogfCBG
NzAwOlVOSVhfU3lzdGVtX1Y6KjoqKQorCUZVSklUU1VfUFJPQz1gdW5hbWUgLW0gfCB0ciAnQUJD
REVGR0hJSktMTU5PUFFSU1RVVldYWVonICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eidgCisJ
RlVKSVRTVV9TWVM9YHVuYW1lIC1wIHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAn
YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonIHwgc2VkIC1lICdzL1wvLy8nYAorCUZVSklUU1Vf
UkVMPWBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvIC9fLydgCisJZWNobyAiJHtG
VUpJVFNVX1BST0N9LWZ1aml0c3UtJHtGVUpJVFNVX1NZU30ke0ZVSklUU1VfUkVMfSIKKwlleGl0
IDs7CisgICAgNTAwMDpVTklYX1N5c3RlbV9WOjQuKjoqKQorCUZVSklUU1VfU1lTPWB1bmFtZSAt
cCB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0
dXZ3eHl6JyB8IHNlZCAtZSAncy9cLy8vJ2AKKwlGVUpJVFNVX1JFTD1gZWNobyAke1VOQU1FX1JF
TEVBU0V9IHwgdHIgJ0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5v
cHFyc3R1dnd4eXonIHwgc2VkIC1lICdzLyAvXy8nYAorCWVjaG8gInNwYXJjLWZ1aml0c3UtJHtG
VUpJVFNVX1NZU30ke0ZVSklUU1VfUkVMfSIKKwlleGl0IDs7CisgICAgaSo4NjpCU0QvMzg2Oio6
KiB8IGkqODY6QlNEL09TOio6KiB8ICo6QXNjZW5kXCBFbWJlZGRlZC9PUzoqOiopCisJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXBjLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHNw
YXJjKjpCU0QvT1M6KjoqKQorCWVjaG8gc3BhcmMtdW5rbm93bi1ic2RpJHtVTkFNRV9SRUxFQVNF
fQorCWV4aXQgOzsKKyAgICAqOkJTRC9PUzoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpGcmVlQlNEOio6KikK
KwlVTkFNRV9QUk9DRVNTT1I9YC91c3IvYmluL3VuYW1lIC1wYAorCWNhc2UgJHtVTkFNRV9QUk9D
RVNTT1J9IGluCisJICAgIGFtZDY0KQorCQllY2hvIHg4Nl82NC11bmtub3duLWZyZWVic2RgZWNo
byAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgIDs7CisJICAgICopCisJCWVj
aG8gJHtVTkFNRV9QUk9DRVNTT1J9LXVua25vd24tZnJlZWJzZGBlY2hvICR7VU5BTUVfUkVMRUFT
RX18c2VkIC1lICdzL1stKF0uKi8vJ2AgOzsKKwllc2FjCisJZXhpdCA7OworICAgIGkqOkNZR1dJ
Tio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtY3lnd2luCisJZXhpdCA7OworICAgICo6
TUlOR1cqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW1pbmd3MzIKKwlleGl0IDs7Cisg
ICAgaSo6TVNZUyo6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbXN5cworCWV4aXQgOzsK
KyAgICBpKjp3aW5kb3dzMzIqOiopCisJIyB1bmFtZSAtbSBpbmNsdWRlcyAiLXBjIiBvbiB0aGlz
IHN5c3RlbS4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tbWluZ3czMgorCWV4aXQgOzsKKyAgICBp
KjpQVyo6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtcHczMgorCWV4aXQgOzsKKyAgICAq
OkludGVyaXgqOiopCisJY2FzZSAke1VOQU1FX01BQ0hJTkV9IGluCisJICAgIHg4NikKKwkJZWNo
byBpNTg2LXBjLWludGVyaXgke1VOQU1FX1JFTEVBU0V9CisJCWV4aXQgOzsKKwkgICAgYXV0aGVu
dGljYW1kIHwgZ2VudWluZWludGVsIHwgRU02NFQpCisJCWVjaG8geDg2XzY0LXVua25vd24taW50
ZXJpeCR7VU5BTUVfUkVMRUFTRX0KKwkJZXhpdCA7OworCSAgICBJQTY0KQorCQllY2hvIGlhNjQt
dW5rbm93bi1pbnRlcml4JHtVTkFNRV9SRUxFQVNFfQorCQlleGl0IDs7CisJZXNhYyA7OworICAg
IFszNDVdODY6V2luZG93c185NToqIHwgWzM0NV04NjpXaW5kb3dzXzk4OiogfCBbMzQ1XTg2Oldp
bmRvd3NfTlQ6KikKKwllY2hvIGkke1VOQU1FX01BQ0hJTkV9LXBjLW1rcworCWV4aXQgOzsKKyAg
ICA4NjY0OldpbmRvd3NfTlQ6KikKKwllY2hvIHg4Nl82NC1wYy1ta3MKKwlleGl0IDs7CisgICAg
aSo6V2luZG93c19OVCo6KiB8IFBlbnRpdW0qOldpbmRvd3NfTlQqOiopCisJIyBIb3cgZG8gd2Ug
a25vdyBpdCdzIEludGVyaXggcmF0aGVyIHRoYW4gdGhlIGdlbmVyaWMgUE9TSVggc3Vic3lzdGVt
PworCSMgSXQgYWxzbyBjb25mbGljdHMgd2l0aCBwcmUtMi4wIHZlcnNpb25zIG9mIEFUJlQgVVdJ
Ti4gU2hvdWxkIHdlCisJIyBVTkFNRV9NQUNISU5FIGJhc2VkIG9uIHRoZSBvdXRwdXQgb2YgdW5h
bWUgaW5zdGVhZCBvZiBpMzg2PworCWVjaG8gaTU4Ni1wYy1pbnRlcml4CisJZXhpdCA7OworICAg
IGkqOlVXSU4qOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXV3aW4KKwlleGl0IDs7Cisg
ICAgYW1kNjQ6Q1lHV0lOKjoqOiogfCB4ODZfNjQ6Q1lHV0lOKjoqOiopCisJZWNobyB4ODZfNjQt
dW5rbm93bi1jeWd3aW4KKwlleGl0IDs7CisgICAgcCo6Q1lHV0lOKjoqKQorCWVjaG8gcG93ZXJw
Y2xlLXVua25vd24tY3lnd2luCisJZXhpdCA7OworICAgIHByZXAqOlN1bk9TOjUuKjoqKQorCWVj
aG8gcG93ZXJwY2xlLXVua25vd24tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bXi5dKi8vJ2AKKwlleGl0IDs7CisgICAgKjpHTlU6KjoqKQorCSMgdGhlIEdOVSBzeXN0
ZW0KKwllY2hvIGBlY2hvICR7VU5BTUVfTUFDSElORX18c2VkIC1lICdzLFstL10uKiQsLCdgLXVu
a25vd24tZ251YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MsLy4qJCwsJ2AKKwlleGl0
IDs7CisgICAgKjpHTlUvKjoqOiopCisJIyBvdGhlciBzeXN0ZW1zIHdpdGggR05VIGxpYmMgYW5k
IHVzZXJsYW5kCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tYGVjaG8gJHtVTkFNRV9T
WVNURU19IHwgc2VkICdzLF5bXi9dKi8sLCcgfCB0ciAnW0EtWl0nICdbYS16XSdgYGVjaG8gJHtV
TkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy0oXS4qLy8nYC1nbnUKKwlleGl0IDs7CisgICAgaSo4
NjpNaW5peDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW1pbml4CisJZXhpdCA7Owor
ICAgIGFscGhhOkxpbnV4Oio6KikKKwljYXNlIGBzZWQgLW4gJy9eY3B1IG1vZGVsL3MvXi4qOiBc
KC4qXCkvXDEvcCcgPCAvcHJvYy9jcHVpbmZvYCBpbgorCSAgRVY1KSAgIFVOQU1FX01BQ0hJTkU9
YWxwaGFldjUgOzsKKwkgIEVWNTYpICBVTkFNRV9NQUNISU5FPWFscGhhZXY1NiA7OworCSAgUENB
NTYpIFVOQU1FX01BQ0hJTkU9YWxwaGFwY2E1NiA7OworCSAgUENBNTcpIFVOQU1FX01BQ0hJTkU9
YWxwaGFwY2E1NiA7OworCSAgRVY2KSAgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjYgOzsKKwkgIEVW
NjcpICBVTkFNRV9NQUNISU5FPWFscGhhZXY2NyA7OworCSAgRVY2OCopIFVOQU1FX01BQ0hJTkU9
YWxwaGFldjY4IDs7CisJZXNhYworCW9iamR1bXAgLS1wcml2YXRlLWhlYWRlcnMgL2Jpbi9zaCB8
IGdyZXAgLXEgbGQuc28uMQorCWlmIHRlc3QgIiQ/IiA9IDAgOyB0aGVuIExJQkM9ImxpYmMxIiA7
IGVsc2UgTElCQz0iIiA7IGZpCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgt
Z251JHtMSUJDfQorCWV4aXQgOzsKKyAgICBhcm0qOkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2Nf
Zm9yX2J1aWxkCisJaWYgZWNobyBfX0FSTV9FQUJJX18gfCAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4v
ZGV2L251bGwgXAorCSAgICB8IGdyZXAgLXEgX19BUk1fRUFCSV9fCisJdGhlbgorCSAgICBlY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwllbHNlCisJICAgIGlmIGVjaG8g
X19BUk1fUENTX1ZGUCB8ICRDQ19GT1JfQlVJTEQgLUUgLSAyPi9kZXYvbnVsbCBcCisJCXwgZ3Jl
cCAtcSBfX0FSTV9QQ1NfVkZQCisJICAgIHRoZW4KKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tbGludXgtZ251ZWFiaQorCSAgICBlbHNlCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11
bmtub3duLWxpbnV4LWdudWVhYmloZgorCSAgICBmaQorCWZpCisJZXhpdCA7OworICAgIGF2cjMy
KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJ
ZXhpdCA7OworICAgIGNyaXM6TGludXg6KjoqKQorCWVjaG8gY3Jpcy1heGlzLWxpbnV4LWdudQor
CWV4aXQgOzsKKyAgICBjcmlzdjMyOkxpbnV4Oio6KikKKwllY2hvIGNyaXN2MzItYXhpcy1saW51
eC1nbnUKKwlleGl0IDs7CisgICAgZnJ2OkxpbnV4Oio6KikKKwllY2hvIGZydi11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBoZXhhZ29uOkxpbnV4Oio6KikKKwllY2hvIGhleGFnb24t
dW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgaSo4NjpMaW51eDoqOiopCisJTElCQz1n
bnUKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+JGR1bW15
LmMKKwkjaWZkZWYgX19kaWV0bGliY19fCisJTElCQz1kaWV0bGliYworCSNlbmRpZgorRU9GCisJ
ZXZhbCBgJENDX0ZPUl9CVUlMRCAtRSAkZHVtbXkuYyAyPi9kZXYvbnVsbCB8IGdyZXAgJ15MSUJD
J2AKKwllY2hvICIke1VOQU1FX01BQ0hJTkV9LXBjLWxpbnV4LSR7TElCQ30iCisJZXhpdCA7Owor
ICAgIGlhNjQ6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4
LWdudQorCWV4aXQgOzsKKyAgICBtMzJyKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJ
TkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIG02OCo6TGludXg6KjoqKQorCWVj
aG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBtaXBz
OkxpbnV4Oio6KiB8IG1pcHM2NDpMaW51eDoqOiopCisJZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAor
CXNlZCAncy9eCS8vJyA8PCBFT0YgPiRkdW1teS5jCisJI3VuZGVmIENQVQorCSN1bmRlZiAke1VO
QU1FX01BQ0hJTkV9CisJI3VuZGVmICR7VU5BTUVfTUFDSElORX1lbAorCSNpZiBkZWZpbmVkKF9f
TUlQU0VMX18pIHx8IGRlZmluZWQoX19NSVBTRUwpIHx8IGRlZmluZWQoX01JUFNFTCkgfHwgZGVm
aW5lZChNSVBTRUwpCisJQ1BVPSR7VU5BTUVfTUFDSElORX1lbAorCSNlbHNlCisJI2lmIGRlZmlu
ZWQoX19NSVBTRUJfXykgfHwgZGVmaW5lZChfX01JUFNFQikgfHwgZGVmaW5lZChfTUlQU0VCKSB8
fCBkZWZpbmVkKE1JUFNFQikKKwlDUFU9JHtVTkFNRV9NQUNISU5FfQorCSNlbHNlCisJQ1BVPQor
CSNlbmRpZgorCSNlbmRpZgorRU9GCisJZXZhbCBgJENDX0ZPUl9CVUlMRCAtRSAkZHVtbXkuYyAy
Pi9kZXYvbnVsbCB8IGdyZXAgJ15DUFUnYAorCXRlc3QgeCIke0NQVX0iICE9IHggJiYgeyBlY2hv
ICIke0NQVX0tdW5rbm93bi1saW51eC1nbnUiOyBleGl0OyB9CisJOzsKKyAgICBvcjMyOkxpbnV4
Oio6KikKKwllY2hvIG9yMzItdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgcGFkcmU6
TGludXg6KjoqKQorCWVjaG8gc3BhcmMtdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAg
cGFyaXNjNjQ6TGludXg6KjoqIHwgaHBwYTY0OkxpbnV4Oio6KikKKwllY2hvIGhwcGE2NC11bmtu
b3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYXJpc2M6TGludXg6KjoqIHwgaHBwYTpMaW51
eDoqOiopCisJIyBMb29rIGZvciBDUFUgbGV2ZWwKKwljYXNlIGBncmVwICdeY3B1W15hLXpdKjon
IC9wcm9jL2NwdWluZm8gMj4vZGV2L251bGwgfCBjdXQgLWQnICcgLWYyYCBpbgorCSAgUEE3Kikg
ZWNobyBocHBhMS4xLXVua25vd24tbGludXgtZ251IDs7CisJICBQQTgqKSBlY2hvIGhwcGEyLjAt
dW5rbm93bi1saW51eC1nbnUgOzsKKwkgICopICAgIGVjaG8gaHBwYS11bmtub3duLWxpbnV4LWdu
dSA7OworCWVzYWMKKwlleGl0IDs7CisgICAgcHBjNjQ6TGludXg6KjoqKQorCWVjaG8gcG93ZXJw
YzY0LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHBwYzpMaW51eDoqOiopCisJZWNo
byBwb3dlcnBjLXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHMzOTA6TGludXg6Kjoq
IHwgczM5MHg6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1pYm0tbGludXgKKwll
eGl0IDs7CisgICAgc2g2NCo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtu
b3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBzaCo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFN
RV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBzcGFyYzpMaW51eDoq
OiogfCBzcGFyYzY0OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1s
aW51eC1nbnUKKwlleGl0IDs7CisgICAgdGlsZSo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB2YXg6TGludXg6KjoqKQor
CWVjaG8gJHtVTkFNRV9NQUNISU5FfS1kZWMtbGludXgtZ251CisJZXhpdCA7OworICAgIHg4Nl82
NDpMaW51eDoqOiopCisJZWNobyB4ODZfNjQtdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7Cisg
ICAgeHRlbnNhKjpMaW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGlu
dXgtZ251CisJZXhpdCA7OworICAgIGkqODY6RFlOSVgvcHR4OjQqOiopCisJIyBwdHggNC4wIGRv
ZXMgdW5hbWUgLXMgY29ycmVjdGx5LCB3aXRoIERZTklYL3B0eCBpbiB0aGVyZS4KKwkjIGVhcmxp
ZXIgdmVyc2lvbnMgYXJlIG1lc3NlZCB1cCBhbmQgcHV0IHRoZSBub2RlbmFtZSBpbiBib3RoCisJ
IyBzeXNuYW1lIGFuZCBub2RlbmFtZS4KKwllY2hvIGkzODYtc2VxdWVudC1zeXN2NAorCWV4aXQg
OzsKKyAgICBpKjg2OlVOSVhfU1Y6NC4yTVA6Mi4qKQorCSMgVW5peHdhcmUgaXMgYW4gb2Zmc2hv
b3Qgb2YgU1ZSNCwgYnV0IGl0IGhhcyBpdHMgb3duIHZlcnNpb24KKwkjIG51bWJlciBzZXJpZXMg
c3RhcnRpbmcgd2l0aCAyLi4uCisJIyBJIGFtIG5vdCBwb3NpdGl2ZSB0aGF0IG90aGVyIFNWUjQg
c3lzdGVtcyB3b24ndCBtYXRjaCB0aGlzLAorCSMgSSBqdXN0IGhhdmUgdG8gaG9wZS4gIC0tIHJt
cy4KKwkjIFVzZSBzeXN2NC4ydXcuLi4gc28gdGhhdCBzeXN2NCogbWF0Y2hlcyBpdC4KKwllY2hv
ICR7VU5BTUVfTUFDSElORX0tcGMtc3lzdjQuMnV3JHtVTkFNRV9WRVJTSU9OfQorCWV4aXQgOzsK
KyAgICBpKjg2Ok9TLzI6KjoqKQorCSMgSWYgd2Ugd2VyZSBhYmxlIHRvIGZpbmQgYHVuYW1lJywg
dGhlbiBFTVggVW5peCBjb21wYXRpYmlsaXR5CisJIyBpcyBwcm9iYWJseSBpbnN0YWxsZWQuCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW9zMi1lbXgKKwlleGl0IDs7CisgICAgaSo4NjpYVFMt
MzAwOio6U1RPUCkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zdG9wCisJZXhpdCA7
OworICAgIGkqODY6YXRoZW9zOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1h
dGhlb3MKKwlleGl0IDs7CisgICAgaSo4NjpzeWxsYWJsZToqOiopCisJZWNobyAke1VOQU1FX01B
Q0hJTkV9LXBjLXN5bGxhYmxlCisJZXhpdCA7OworICAgIGkqODY6THlueE9TOjIuKjoqIHwgaSo4
NjpMeW54T1M6My5bMDFdKjoqIHwgaSo4NjpMeW54T1M6NC5bMDJdKjoqKQorCWVjaG8gaTM4Ni11
bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgaSo4NjoqRE9TOio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbXNkb3NkamdwcAorCWV4aXQgOzsKKyAgICBp
Kjg2Oio6NC4qOiogfCBpKjg2OlNZU1RFTV9WOjQuKjoqKQorCVVOQU1FX1JFTD1gZWNobyAke1VO
QU1FX1JFTEVBU0V9IHwgc2VkICdzL1wvTVAkLy8nYAorCWlmIGdyZXAgTm92ZWxsIC91c3IvaW5j
bHVkZS9saW5rLmggPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbgorCQllY2hvICR7VU5BTUVf
TUFDSElORX0tdW5pdmVsLXN5c3Yke1VOQU1FX1JFTH0KKwllbHNlCisJCWVjaG8gJHtVTkFNRV9N
QUNISU5FfS1wYy1zeXN2JHtVTkFNRV9SRUx9CisJZmkKKwlleGl0IDs7CisgICAgaSo4NjoqOjU6
WzY3OF0qKQorCSMgVW5peFdhcmUgNy54LCBPcGVuVU5JWCBhbmQgT3BlblNlcnZlciA2LgorCWNh
c2UgYC9iaW4vdW5hbWUgLVggfCBncmVwICJeTWFjaGluZSJgIGluCisJICAgICo0ODYqKQkgICAg
IFVOQU1FX01BQ0hJTkU9aTQ4NiA7OworCSAgICAqUGVudGl1bSkJICAgICBVTkFNRV9NQUNISU5F
PWk1ODYgOzsKKwkgICAgKlBlbnQqfCpDZWxlcm9uKSBVTkFNRV9NQUNISU5FPWk2ODYgOzsKKwll
c2FjCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFTRX0k
e1VOQU1FX1NZU1RFTX0ke1VOQU1FX1ZFUlNJT059CisJZXhpdCA7OworICAgIGkqODY6KjozLjI6
KikKKwlpZiB0ZXN0IC1mIC91c3Ivb3B0aW9ucy9jYi5uYW1lOyB0aGVuCisJCVVOQU1FX1JFTD1g
c2VkIC1uICdzLy4qVmVyc2lvbiAvL3AnIDwvdXNyL29wdGlvbnMvY2IubmFtZWAKKwkJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXBjLWlzYyRVTkFNRV9SRUwKKwllbGlmIC9iaW4vdW5hbWUgLVggMj4v
ZGV2L251bGwgPi9kZXYvbnVsbCA7IHRoZW4KKwkJVU5BTUVfUkVMPWAoL2Jpbi91bmFtZSAtWHxn
cmVwIFJlbGVhc2V8c2VkIC1lICdzLy4qPSAvLycpYAorCQkoL2Jpbi91bmFtZSAtWHxncmVwIGk4
MDQ4NiA+L2Rldi9udWxsKSAmJiBVTkFNRV9NQUNISU5FPWk0ODYKKwkJKC9iaW4vdW5hbWUgLVh8
Z3JlcCAnXk1hY2hpbmUuKlBlbnRpdW0nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJ
TkU9aTU4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVwICdeTWFjaGluZS4qUGVudCAqSUknID4vZGV2
L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJTkU9aTY4NgorCQkoL2Jpbi91bmFtZSAtWHxncmVw
ICdeTWFjaGluZS4qUGVudGl1bSBQcm8nID4vZGV2L251bGwpIFwKKwkJCSYmIFVOQU1FX01BQ0hJ
TkU9aTY4NgorCQllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc2NvJFVOQU1FX1JFTAorCWVsc2UK
KwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXN5c3YzMgorCWZpCisJZXhpdCA7OworICAgIHBj
Oio6KjoqKQorCSMgTGVmdCBoZXJlIGZvciBjb21wYXRpYmlsaXR5OgorCSMgdW5hbWUgLW0gcHJp
bnRzIGZvciBESkdQUCBhbHdheXMgJ3BjJywgYnV0IGl0IHByaW50cyBub3RoaW5nIGFib3V0CisJ
IyB0aGUgcHJvY2Vzc29yLCBzbyB3ZSBwbGF5IHNhZmUgYnkgYXNzdW1pbmcgaTU4Ni4KKwkjIE5v
dGU6IHdoYXRldmVyIHRoaXMgaXMsIGl0IE1VU1QgYmUgdGhlIHNhbWUgYXMgd2hhdCBjb25maWcu
c3ViCisJIyBwcmludHMgZm9yIHRoZSAiZGpncHAiIGhvc3QsIG9yIGVsc2UgR0RCIGNvbmZpZ3Vy
eSB3aWxsIGRlY2lkZSB0aGF0CisJIyB0aGlzIGlzIGEgY3Jvc3MtYnVpbGQuCisJZWNobyBpNTg2
LXBjLW1zZG9zZGpncHAKKwlleGl0IDs7CisgICAgSW50ZWw6TWFjaDozKjoqKQorCWVjaG8gaTM4
Ni1wYy1tYWNoMworCWV4aXQgOzsKKyAgICBwYXJhZ29uOio6KjoqKQorCWVjaG8gaTg2MC1pbnRl
bC1vc2YxCisJZXhpdCA7OworICAgIGk4NjA6Kjo0Lio6KikgIyBpODYwLVNWUjQKKwlpZiBncmVw
IFN0YXJkZW50IC91c3IvaW5jbHVkZS9zeXMvdWFkbWluLmggPi9kZXYvbnVsbCAyPiYxIDsgdGhl
bgorCSAgZWNobyBpODYwLXN0YXJkZW50LXN5c3Yke1VOQU1FX1JFTEVBU0V9ICMgU3RhcmRlbnQg
VmlzdHJhIGk4NjAtU1ZSNAorCWVsc2UgIyBBZGQgb3RoZXIgaTg2MC1TVlI0IHZlbmRvcnMgYmVs
b3cgYXMgdGhleSBhcmUgZGlzY292ZXJlZC4KKwkgIGVjaG8gaTg2MC11bmtub3duLXN5c3Yke1VO
QU1FX1JFTEVBU0V9ICAjIFVua25vd24gaTg2MC1TVlI0CisJZmkKKwlleGl0IDs7CisgICAgbWlu
aSo6Q1RJWDpTWVMqNToqKQorCSMgIm1pbmlmcmFtZSIKKwllY2hvIG02ODAxMC1jb252ZXJnZW50
LXN5c3YKKwlleGl0IDs7CisgICAgbWM2OGs6VU5JWDpTWVNURU01OjMuNTFtKQorCWVjaG8gbTY4
ay1jb252ZXJnZW50LXN5c3YKKwlleGl0IDs7CisgICAgTTY4MD8wOkQtTklYOjUuMzoqKQorCWVj
aG8gbTY4ay1kaWFiLWRuaXgKKwlleGl0IDs7CisgICAgTTY4KjoqOlIzVls1Njc4XSo6KikKKwl0
ZXN0IC1yIC9zeXNWNjggJiYgeyBlY2hvICdtNjhrLW1vdG9yb2xhLXN5c3YnOyBleGl0OyB9IDs7
CisgICAgM1szNDVdPz86Kjo0LjA6My4wIHwgM1szNF0/P0E6Kjo0LjA6My4wIHwgM1szNF0/Pywq
Oio6NC4wOjMuMCB8IDNbMzRdPz8vKjoqOjQuMDozLjAgfCA0NDAwOio6NC4wOjMuMCB8IDQ4NTA6
Kjo0LjA6My4wIHwgU0tBNDA6Kjo0LjA6My4wIHwgU0RTMjoqOjQuMDozLjAgfCBTSEcyOio6NC4w
OjMuMCB8IFM3NTAxKjoqOjQuMDozLjApCisJT1NfUkVMPScnCisJdGVzdCAtciAvZXRjLy5yZWxp
ZCBcCisJJiYgT1NfUkVMPS5gc2VkIC1uICdzL1teIF0qIFteIF0qIFwoWzAtOV1bMC05XVwpLiov
XDEvcCcgPCAvZXRjLy5yZWxpZGAKKwkvYmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4
NiA+L2Rldi9udWxsIFwKKwkgICYmIHsgZWNobyBpNDg2LW5jci1zeXN2NC4zJHtPU19SRUx9OyBl
eGl0OyB9CisJL2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVsbCB8IC9iaW4vZ3JlcCBlbnRpdW0gPi9k
ZXYvbnVsbCBcCisJICAmJiB7IGVjaG8gaTU4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsg
fSA7OworICAgIDNbMzRdPz86Kjo0LjA6KiB8IDNbMzRdPz8sKjoqOjQuMDoqKQorCS9iaW4vdW5h
bWUgLXAgMj4vZGV2L251bGwgfCBncmVwIDg2ID4vZGV2L251bGwgXAorCSAgJiYgeyBlY2hvIGk0
ODYtbmNyLXN5c3Y0OyBleGl0OyB9IDs7CisgICAgTkNSKjoqOjQuMjoqIHwgTVBSQVMqOio6NC4y
OiopCisJT1NfUkVMPScuMycKKwl0ZXN0IC1yIC9ldGMvLnJlbGlkIFwKKwkgICAgJiYgT1NfUkVM
PS5gc2VkIC1uICdzL1teIF0qIFteIF0qIFwoWzAtOV1bMC05XVwpLiovXDEvcCcgPCAvZXRjLy5y
ZWxpZGAKKwkvYmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4NiA+L2Rldi9udWxsIFwK
KwkgICAgJiYgeyBlY2hvIGk0ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmlu
L3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIGVudGl1bSA+L2Rldi9udWxsIFwKKwkg
ICAgJiYgeyBlY2hvIGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmluL3Vu
YW1lIC1wIDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIHB0ZXJvbiA+L2Rldi9udWxsIFwKKwkgICAg
JiYgeyBlY2hvIGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0gOzsKKyAgICBtNjgq
Okx5bnhPUzoyLio6KiB8IG02OCo6THlueE9TOjMuMCo6KikKKwllY2hvIG02OGstdW5rbm93bi1s
eW54b3Mke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG1jNjgwMzA6VU5JWF9TeXN0ZW1f
Vjo0Lio6KikKKwllY2hvIG02OGstYXRhcmktc3lzdjQKKwlleGl0IDs7CisgICAgVFNVTkFNSTpM
eW54T1M6Mi4qOiopCisJZWNobyBzcGFyYy11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0K
KwlleGl0IDs7CisgICAgcnM2MDAwOkx5bnhPUzoyLio6KikKKwllY2hvIHJzNjAwMC11bmtub3du
LWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgUG93ZXJQQzpMeW54T1M6Mi4q
OiogfCBQb3dlclBDOkx5bnhPUzozLlswMV0qOiogfCBQb3dlclBDOkx5bnhPUzo0LlswMl0qOiop
CisJZWNobyBwb3dlcnBjLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsK
KyAgICBTTVtCRV1TOlVOSVhfU1Y6KjoqKQorCWVjaG8gbWlwcy1kZGUtc3lzdiR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgUk0qOlJlbGlhbnRVTklYLSo6KjoqKQorCWVjaG8gbWlwcy1z
bmktc3lzdjQKKwlleGl0IDs7CisgICAgUk0qOlNJTklYLSo6KjoqKQorCWVjaG8gbWlwcy1zbmkt
c3lzdjQKKwlleGl0IDs7CisgICAgKjpTSU5JWC0qOio6KikKKwlpZiB1bmFtZSAtcCAyPi9kZXYv
bnVsbCA+L2Rldi9udWxsIDsgdGhlbgorCQlVTkFNRV9NQUNISU5FPWAodW5hbWUgLXApIDI+L2Rl
di9udWxsYAorCQllY2hvICR7VU5BTUVfTUFDSElORX0tc25pLXN5c3Y0CisJZWxzZQorCQllY2hv
IG5zMzJrLXNuaS1zeXN2CisJZmkKKwlleGl0IDs7CisgICAgUEVOVElVTToqOjQuMCo6KikJIyBV
bmlzeXMgYENsZWFyUGF0aCBITVAgSVggNDAwMCcgU1ZSNC9NUCBlZmZvcnQKKwkJCSMgc2F5cyA8
UmljaGFyZC5NLkJhcnRlbEBjY01haWwuQ2Vuc3VzLkdPVj4KKwllY2hvIGk1ODYtdW5pc3lzLXN5
c3Y0CisJZXhpdCA7OworICAgICo6VU5JWF9TeXN0ZW1fVjo0KjpGVFgqKQorCSMgRnJvbSBHZXJh
bGQgSGV3ZXMgPGhld2VzQG9wZW5tYXJrZXQuY29tPi4KKwkjIEhvdyBhYm91dCBkaWZmZXJlbnRp
YXRpbmcgYmV0d2VlbiBzdHJhdHVzIGFyY2hpdGVjdHVyZXM/IC1kam0KKwllY2hvIGhwcGExLjEt
c3RyYXR1cy1zeXN2NAorCWV4aXQgOzsKKyAgICAqOio6KjpGVFgqKQorCSMgRnJvbSBzZWFuZkBz
d2RjLnN0cmF0dXMuY29tLgorCWVjaG8gaTg2MC1zdHJhdHVzLXN5c3Y0CisJZXhpdCA7OworICAg
IGkqODY6Vk9TOio6KikKKwkjIEZyb20gUGF1bC5HcmVlbkBzdHJhdHVzLmNvbS4KKwllY2hvICR7
VU5BTUVfTUFDSElORX0tc3RyYXR1cy12b3MKKwlleGl0IDs7CisgICAgKjpWT1M6KjoqKQorCSMg
RnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVjaG8gaHBwYTEuMS1zdHJhdHVzLXZvcwor
CWV4aXQgOzsKKyAgICBtYzY4KjpBL1VYOio6KikKKwllY2hvIG02OGstYXBwbGUtYXV4JHtVTkFN
RV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBuZXdzKjpORVdTLU9TOjYqOiopCisJZWNobyBtaXBz
LXNvbnktbmV3c29zNgorCWV4aXQgOzsKKyAgICBSWzM0XTAwMDoqU3lzdGVtX1YqOio6KiB8IFI0
MDAwOlVOSVhfU1lTVjoqOiogfCBSKjAwMDpVTklYX1NWOio6KikKKwlpZiBbIC1kIC91c3IvbmVj
IF07IHRoZW4KKwkJZWNobyBtaXBzLW5lYy1zeXN2JHtVTkFNRV9SRUxFQVNFfQorCWVsc2UKKwkJ
ZWNobyBtaXBzLXVua25vd24tc3lzdiR7VU5BTUVfUkVMRUFTRX0KKwlmaQorCWV4aXQgOzsKKyAg
ICBCZUJveDpCZU9TOio6KikJIyBCZU9TIHJ1bm5pbmcgb24gaGFyZHdhcmUgbWFkZSBieSBCZSwg
UFBDIG9ubHkuCisJZWNobyBwb3dlcnBjLWJlLWJlb3MKKwlleGl0IDs7CisgICAgQmVNYWM6QmVP
UzoqOiopCSMgQmVPUyBydW5uaW5nIG9uIE1hYyBvciBNYWMgY2xvbmUsIFBQQyBvbmx5LgorCWVj
aG8gcG93ZXJwYy1hcHBsZS1iZW9zCisJZXhpdCA7OworICAgIEJlUEM6QmVPUzoqOiopCSMgQmVP
UyBydW5uaW5nIG9uIEludGVsIFBDIGNvbXBhdGlibGUuCisJZWNobyBpNTg2LXBjLWJlb3MKKwll
eGl0IDs7CisgICAgQmVQQzpIYWlrdToqOiopCSMgSGFpa3UgcnVubmluZyBvbiBJbnRlbCBQQyBj
b21wYXRpYmxlLgorCWVjaG8gaTU4Ni1wYy1oYWlrdQorCWV4aXQgOzsKKyAgICBTWC00OlNVUEVS
LVVYOio6KikKKwllY2hvIHN4NC1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgU1gtNTpTVVBFUi1VWDoqOiopCisJZWNobyBzeDUtbmVjLXN1cGVydXgke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIFNYLTY6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g2LW5lYy1z
dXBlcnV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC03OlNVUEVSLVVYOio6KikK
KwllY2hvIHN4Ny1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gt
ODpTVVBFUi1VWDoqOiopCisJZWNobyBzeDgtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJ
ZXhpdCA7OworICAgIFNYLThSOlNVUEVSLVVYOio6KikKKwllY2hvIHN4OHItbmVjLXN1cGVydXgk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIFBvd2VyKjpSaGFwc29keToqOiopCisJZWNo
byBwb3dlcnBjLWFwcGxlLXJoYXBzb2R5JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAq
OlJoYXBzb2R5Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tYXBwbGUtcmhhcHNvZHkke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6RGFyd2luOio6KikKKwlVTkFNRV9QUk9DRVNT
T1I9YHVuYW1lIC1wYCB8fCBVTkFNRV9QUk9DRVNTT1I9dW5rbm93bgorCWNhc2UgJFVOQU1FX1BS
T0NFU1NPUiBpbgorCSAgICBpMzg2KQorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCWlmIFsg
IiRDQ19GT1JfQlVJTEQiICE9ICdub19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCQkgIGlmIChl
Y2hvICcjaWZkZWYgX19MUDY0X18nOyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicp
IHwgXAorCQkgICAgICAoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwg
XAorCQkgICAgICBncmVwIElTXzY0QklUX0FSQ0ggPi9kZXYvbnVsbAorCQkgIHRoZW4KKwkJICAg
ICAgVU5BTUVfUFJPQ0VTU09SPSJ4ODZfNjQiCisJCSAgZmkKKwkJZmkgOzsKKwkgICAgdW5rbm93
bikgVU5BTUVfUFJPQ0VTU09SPXBvd2VycGMgOzsKKwllc2FjCisJZWNobyAke1VOQU1FX1BST0NF
U1NPUn0tYXBwbGUtZGFyd2luJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOnByb2Nu
dG8qOio6KiB8ICo6UU5YOlswMTIzNDU2Nzg5XSo6KikKKwlVTkFNRV9QUk9DRVNTT1I9YHVuYW1l
IC1wYAorCWlmIHRlc3QgIiRVTkFNRV9QUk9DRVNTT1IiID0gIng4NiI7IHRoZW4KKwkJVU5BTUVf
UFJPQ0VTU09SPWkzODYKKwkJVU5BTUVfTUFDSElORT1wYworCWZpCisJZWNobyAke1VOQU1FX1BS
T0NFU1NPUn0tJHtVTkFNRV9NQUNISU5FfS1udG8tcW54JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQg
OzsKKyAgICAqOlFOWDoqOjQqKQorCWVjaG8gaTM4Ni1wYy1xbngKKwlleGl0IDs7CisgICAgTkVP
LT86Tk9OU1RPUF9LRVJORUw6KjoqKQorCWVjaG8gbmVvLXRhbmRlbS1uc2ske1VOQU1FX1JFTEVB
U0V9CisJZXhpdCA7OworICAgIE5TRS0/Ok5PTlNUT1BfS0VSTkVMOio6KikKKwllY2hvIG5zZS10
YW5kZW0tbnNrJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBOU1ItPzpOT05TVE9QX0tF
Uk5FTDoqOiopCisJZWNobyBuc3ItdGFuZGVtLW5zayR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgKjpOb25TdG9wLVVYOio6KikKKwllY2hvIG1pcHMtY29tcGFxLW5vbnN0b3B1eAorCWV4
aXQgOzsKKyAgICBCUzIwMDA6UE9TSVgqOio6KikKKwllY2hvIGJzMjAwMC1zaWVtZW5zLXN5c3YK
KwlleGl0IDs7CisgICAgRFMvKjpVTklYX1N5c3RlbV9WOio6KikKKwllY2hvICR7VU5BTUVfTUFD
SElORX0tJHtVTkFNRV9TWVNURU19LSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgKjpQ
bGFuOToqOiopCisJIyAidW5hbWUgLW0iIGlzIG5vdCBjb25zaXN0ZW50LCBzbyB1c2UgJGNwdXR5
cGUgaW5zdGVhZC4gMzg2CisJIyBpcyBjb252ZXJ0ZWQgdG8gaTM4NiBmb3IgY29uc2lzdGVuY3kg
d2l0aCBvdGhlciB4ODYKKwkjIG9wZXJhdGluZyBzeXN0ZW1zLgorCWlmIHRlc3QgIiRjcHV0eXBl
IiA9ICIzODYiOyB0aGVuCisJICAgIFVOQU1FX01BQ0hJTkU9aTM4NgorCWVsc2UKKwkgICAgVU5B
TUVfTUFDSElORT0iJGNwdXR5cGUiCisJZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93
bi1wbGFuOQorCWV4aXQgOzsKKyAgICAqOlRPUFMtMTA6KjoqKQorCWVjaG8gcGRwMTAtdW5rbm93
bi10b3BzMTAKKwlleGl0IDs7CisgICAgKjpURU5FWDoqOiopCisJZWNobyBwZHAxMC11bmtub3du
LXRlbmV4CisJZXhpdCA7OworICAgIEtTMTA6VE9QUy0yMDoqOiogfCBLTDEwOlRPUFMtMjA6Kjoq
IHwgVFlQRTQ6VE9QUy0yMDoqOiopCisJZWNobyBwZHAxMC1kZWMtdG9wczIwCisJZXhpdCA7Owor
ICAgIFhLTC0xOlRPUFMtMjA6KjoqIHwgVFlQRTU6VE9QUy0yMDoqOiopCisJZWNobyBwZHAxMC14
a2wtdG9wczIwCisJZXhpdCA7OworICAgICo6VE9QUy0yMDoqOiopCisJZWNobyBwZHAxMC11bmtu
b3duLXRvcHMyMAorCWV4aXQgOzsKKyAgICAqOklUUzoqOiopCisJZWNobyBwZHAxMC11bmtub3du
LWl0cworCWV4aXQgOzsKKyAgICBTRUk6KjoqOlNFSVVYKQorCWVjaG8gbWlwcy1zZWktc2VpdXgk
e1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6RHJhZ29uRmx5Oio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1kcmFnb25mbHlgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNl
ZCAtZSAncy9bLShdLiovLydgCisJZXhpdCA7OworICAgICo6KlZNUzoqOiopCisJVU5BTUVfTUFD
SElORT1gKHVuYW1lIC1wKSAyPi9kZXYvbnVsbGAKKwljYXNlICIke1VOQU1FX01BQ0hJTkV9IiBp
bgorCSAgICBBKikgZWNobyBhbHBoYS1kZWMtdm1zIDsgZXhpdCA7OworCSAgICBJKikgZWNobyBp
YTY0LWRlYy12bXMgOyBleGl0IDs7CisJICAgIFYqKSBlY2hvIHZheC1kZWMtdm1zIDsgZXhpdCA7
OworCWVzYWMgOzsKKyAgICAqOlhFTklYOio6U3lzVikKKwllY2hvIGkzODYtcGMteGVuaXgKKwll
eGl0IDs7CisgICAgaSo4Njpza3lvczoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXNr
eW9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfWAgfCBzZWQgLWUgJ3MvIC4qJC8vJworCWV4aXQgOzsK
KyAgICBpKjg2OnJkb3M6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1yZG9zCisJZXhp
dCA7OworICAgIGkqODY6QVJPUzoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLWFyb3MK
KwlleGl0IDs7Citlc2FjCisKKyNlY2hvICcoTm8gdW5hbWUgY29tbWFuZCBvciB1bmFtZSBvdXRw
dXQgbm90IHJlY29nbml6ZWQuKScgMT4mMgorI2VjaG8gIiR7VU5BTUVfTUFDSElORX06JHtVTkFN
RV9TWVNURU19OiR7VU5BTUVfUkVMRUFTRX06JHtVTkFNRV9WRVJTSU9OfSIgMT4mMgorCitldmFs
ICRzZXRfY2NfZm9yX2J1aWxkCitjYXQgPiRkdW1teS5jIDw8RU9GCisjaWZkZWYgX1NFUVVFTlRf
CisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorIyBpbmNsdWRlIDxzeXMvdXRzbmFtZS5oPgorI2Vu
ZGlmCittYWluICgpCit7CisjaWYgZGVmaW5lZCAoc29ueSkKKyNpZiBkZWZpbmVkIChNSVBTRUIp
CisgIC8qIEJGRCB3YW50cyAiYnNkIiBpbnN0ZWFkIG9mICJuZXdzb3MiLiAgUGVyaGFwcyBCRkQg
c2hvdWxkIGJlIGNoYW5nZWQsCisgICAgIEkgZG9uJ3Qga25vdy4uLi4gICovCisgIHByaW50ZiAo
Im1pcHMtc29ueS1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbHNlCisjaW5jbHVkZSA8c3lzL3BhcmFt
Lmg+CisgIHByaW50ZiAoIm02OGstc29ueS1uZXdzb3Mlc1xuIiwKKyNpZmRlZiBORVdTT1M0CisJ
IjQiCisjZWxzZQorCSIiCisjZW5kaWYKKwkpOyBleGl0ICgwKTsKKyNlbmRpZgorI2VuZGlmCisK
KyNpZiBkZWZpbmVkIChfX2FybSkgJiYgZGVmaW5lZCAoX19hY29ybikgJiYgZGVmaW5lZCAoX191
bml4KQorICBwcmludGYgKCJhcm0tYWNvcm4tcmlzY2l4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYK
KworI2lmIGRlZmluZWQgKGhwMzAwKSAmJiAhZGVmaW5lZCAoaHB1eCkKKyAgcHJpbnRmICgibTY4
ay1ocC1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAoTmVYVCkKKyNp
ZiAhZGVmaW5lZCAoX19BUkNISVRFQ1RVUkVfXykKKyNkZWZpbmUgX19BUkNISVRFQ1RVUkVfXyAi
bTY4ayIKKyNlbmRpZgorICBpbnQgdmVyc2lvbjsKKyAgdmVyc2lvbj1gKGhvc3RpbmZvIHwgc2Vk
IC1uICdzLy4qTmVYVCBNYWNoIFwoWzAtOV0qXCkuKi9cMS9wJykgMj4vZGV2L251bGxgOworICBp
ZiAodmVyc2lvbiA8IDQpCisgICAgcHJpbnRmICgiJXMtbmV4dC1uZXh0c3RlcCVkXG4iLCBfX0FS
Q0hJVEVDVFVSRV9fLCB2ZXJzaW9uKTsKKyAgZWxzZQorICAgIHByaW50ZiAoIiVzLW5leHQtb3Bl
bnN0ZXAlZFxuIiwgX19BUkNISVRFQ1RVUkVfXywgdmVyc2lvbik7CisgIGV4aXQgKDApOworI2Vu
ZGlmCisKKyNpZiBkZWZpbmVkIChNVUxUSU1BWCkgfHwgZGVmaW5lZCAobjE2KQorI2lmIGRlZmlu
ZWQgKFVNQVhWKQorICBwcmludGYgKCJuczMyay1lbmNvcmUtc3lzdlxuIik7IGV4aXQgKDApOwor
I2Vsc2UKKyNpZiBkZWZpbmVkIChDTVUpCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1tYWNoXG4i
KTsgZXhpdCAoMCk7CisjZWxzZQorICBwcmludGYgKCJuczMyay1lbmNvcmUtYnNkXG4iKTsgZXhp
dCAoMCk7CisjZW5kaWYKKyNlbmRpZgorI2VuZGlmCisKKyNpZiBkZWZpbmVkIChfXzM4NkJTRF9f
KQorICBwcmludGYgKCJpMzg2LXBjLWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBk
ZWZpbmVkIChzZXF1ZW50KQorI2lmIGRlZmluZWQgKGkzODYpCisgIHByaW50ZiAoImkzODYtc2Vx
dWVudC1keW5peFxuIik7IGV4aXQgKDApOworI2VuZGlmCisjaWYgZGVmaW5lZCAobnMzMjAwMCkK
KyAgcHJpbnRmICgibnMzMmstc2VxdWVudC1keW5peFxuIik7IGV4aXQgKDApOworI2VuZGlmCisj
ZW5kaWYKKworI2lmIGRlZmluZWQgKF9TRVFVRU5UXykKKyAgICBzdHJ1Y3QgdXRzbmFtZSB1bjsK
KworICAgIHVuYW1lKCZ1bik7CisKKyAgICBpZiAoc3RybmNtcCh1bi52ZXJzaW9uLCAiVjIiLCAy
KSA9PSAwKSB7CisJcHJpbnRmICgiaTM4Ni1zZXF1ZW50LXB0eDJcbiIpOyBleGl0ICgwKTsKKyAg
ICB9CisgICAgaWYgKHN0cm5jbXAodW4udmVyc2lvbiwgIlYxIiwgMikgPT0gMCkgeyAvKiBYWFgg
aXMgVjEgY29ycmVjdD8gKi8KKwlwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4MVxuIik7IGV4aXQg
KDApOworICAgIH0KKyAgICBwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4XG4iKTsgZXhpdCAoMCk7
CisKKyNlbmRpZgorCisjaWYgZGVmaW5lZCAodmF4KQorIyBpZiAhZGVmaW5lZCAodWx0cml4KQor
IyAgaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjICBpZiBkZWZpbmVkIChCU0QpCisjICAgaWYgQlNE
ID09IDQzCisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZDQuM1xuIik7IGV4aXQgKDApOworIyAg
IGVsc2UKKyMgICAgaWYgQlNEID09IDE5OTAwNgorICAgICAgcHJpbnRmICgidmF4LWRlYy1ic2Q0
LjNyZW5vXG4iKTsgZXhpdCAoMCk7CisjICAgIGVsc2UKKyAgICAgIHByaW50ZiAoInZheC1kZWMt
YnNkXG4iKTsgZXhpdCAoMCk7CisjICAgIGVuZGlmCisjICAgZW5kaWYKKyMgIGVsc2UKKyAgICBw
cmludGYgKCJ2YXgtZGVjLWJzZFxuIik7IGV4aXQgKDApOworIyAgZW5kaWYKKyMgZWxzZQorICAg
IHByaW50ZiAoInZheC1kZWMtdWx0cml4XG4iKTsgZXhpdCAoMCk7CisjIGVuZGlmCisjZW5kaWYK
KworI2lmIGRlZmluZWQgKGFsbGlhbnQpICYmIGRlZmluZWQgKGk4NjApCisgIHByaW50ZiAoImk4
NjAtYWxsaWFudC1ic2RcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisgIGV4aXQgKDEpOworfQor
RU9GCisKKyRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jIDI+L2Rldi9udWxsICYmIFNZ
U1RFTV9OQU1FPWAkZHVtbXlgICYmCisJeyBlY2hvICIkU1lTVEVNX05BTUUiOyBleGl0OyB9CisK
KyMgQXBvbGxvcyBwdXQgdGhlIHN5c3RlbSB0eXBlIGluIHRoZSBlbnZpcm9ubWVudC4KKwordGVz
dCAtZCAvdXNyL2Fwb2xsbyAmJiB7IGVjaG8gJHtJU1B9LWFwb2xsby0ke1NZU1RZUEV9OyBleGl0
OyB9CisKKyMgQ29udmV4IHZlcnNpb25zIHRoYXQgcHJlZGF0ZSB1bmFtZSBjYW4gdXNlIGdldHN5
c2luZm8oMSkKKworaWYgWyAteCAvdXNyL2NvbnZleC9nZXRzeXNpbmZvIF0KK3RoZW4KKyAgICBj
YXNlIGBnZXRzeXNpbmZvIC1mIGNwdV90eXBlYCBpbgorICAgIGMxKikKKwllY2hvIGMxLWNvbnZl
eC1ic2QKKwlleGl0IDs7CisgICAgYzIqKQorCWlmIGdldHN5c2luZm8gLWYgc2NhbGFyX2FjYwor
CXRoZW4gZWNobyBjMzItY29udmV4LWJzZAorCWVsc2UgZWNobyBjMi1jb252ZXgtYnNkCisJZmkK
KwlleGl0IDs7CisgICAgYzM0KikKKwllY2hvIGMzNC1jb252ZXgtYnNkCisJZXhpdCA7OworICAg
IGMzOCopCisJZWNobyBjMzgtY29udmV4LWJzZAorCWV4aXQgOzsKKyAgICBjNCopCisJZWNobyBj
NC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGVzYWMKK2ZpCisKK2NhdCA+JjIgPDxFT0YKKyQw
OiB1bmFibGUgdG8gZ3Vlc3Mgc3lzdGVtIHR5cGUKKworVGhpcyBzY3JpcHQsIGxhc3QgbW9kaWZp
ZWQgJHRpbWVzdGFtcCwgaGFzIGZhaWxlZCB0byByZWNvZ25pemUKK3RoZSBvcGVyYXRpbmcgc3lz
dGVtIHlvdSBhcmUgdXNpbmcuIEl0IGlzIGFkdmlzZWQgdGhhdCB5b3UKK2Rvd25sb2FkIHRoZSBt
b3N0IHVwIHRvIGRhdGUgdmVyc2lvbiBvZiB0aGUgY29uZmlnIHNjcmlwdHMgZnJvbQorCisgIGh0
dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxh
aW47Zj1jb25maWcuZ3Vlc3M7aGI9SEVBRAorYW5kCisgIGh0dHA6Ly9naXQuc2F2YW5uYWguZ251
Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47Zj1jb25maWcuc3ViO2hiPUhF
QUQKKworSWYgdGhlIHZlcnNpb24geW91IHJ1biAoJDApIGlzIGFscmVhZHkgdXAgdG8gZGF0ZSwg
cGxlYXNlCitzZW5kIHRoZSBmb2xsb3dpbmcgZGF0YSBhbmQgYW55IGluZm9ybWF0aW9uIHlvdSB0
aGluayBtaWdodCBiZQorcGVydGluZW50IHRvIDxjb25maWctcGF0Y2hlc0BnbnUub3JnPiBpbiBv
cmRlciB0byBwcm92aWRlIHRoZSBuZWVkZWQKK2luZm9ybWF0aW9uIHRvIGhhbmRsZSB5b3VyIHN5
c3RlbS4KKworY29uZmlnLmd1ZXNzIHRpbWVzdGFtcCA9ICR0aW1lc3RhbXAKKwordW5hbWUgLW0g
PSBgKHVuYW1lIC1tKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtciA9IGAo
dW5hbWUgLXIpIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1zID0gYCh1bmFt
ZSAtcykgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXYgPSBgKHVuYW1lIC12
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCisKKy91c3IvYmluL3VuYW1lIC1wID0gYCgv
dXNyL2Jpbi91bmFtZSAtcCkgMj4vZGV2L251bGxgCisvYmluL3VuYW1lIC1YICAgICA9IGAoL2Jp
bi91bmFtZSAtWCkgMj4vZGV2L251bGxgCisKK2hvc3RpbmZvICAgICAgICAgICAgICAgPSBgKGhv
c3RpbmZvKSAyPi9kZXYvbnVsbGAKKy9iaW4vdW5pdmVyc2UgICAgICAgICAgPSBgKC9iaW4vdW5p
dmVyc2UpIDI+L2Rldi9udWxsYAorL3Vzci9iaW4vYXJjaCAtayAgICAgICA9IGAoL3Vzci9iaW4v
YXJjaCAtaykgMj4vZGV2L251bGxgCisvYmluL2FyY2ggICAgICAgICAgICAgID0gYCgvYmluL2Fy
Y2gpIDI+L2Rldi9udWxsYAorL3Vzci9iaW4vb3NsZXZlbCAgICAgICA9IGAoL3Vzci9iaW4vb3Ns
ZXZlbCkgMj4vZGV2L251bGxgCisvdXNyL2NvbnZleC9nZXRzeXNpbmZvID0gYCgvdXNyL2NvbnZl
eC9nZXRzeXNpbmZvKSAyPi9kZXYvbnVsbGAKKworVU5BTUVfTUFDSElORSA9ICR7VU5BTUVfTUFD
SElORX0KK1VOQU1FX1JFTEVBU0UgPSAke1VOQU1FX1JFTEVBU0V9CitVTkFNRV9TWVNURU0gID0g
JHtVTkFNRV9TWVNURU19CitVTkFNRV9WRVJTSU9OID0gJHtVTkFNRV9WRVJTSU9OfQorRU9GCisK
K2V4aXQgMQorCisjIExvY2FsIHZhcmlhYmxlczoKKyMgZXZhbDogKGFkZC1ob29rICd3cml0ZS1m
aWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1lLXN0YW1wLXN0YXJ0OiAidGltZXN0YW1wPSci
CisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0tJTAyZCIKKyMgdGltZS1zdGFtcC1lbmQ6
ICInIgorIyBFbmQ6CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9j
b25maWcuaC5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi90b29scy9jb25maWcuaC5pbglNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSw0NDYgQEAKKy8qIGNvbmZpZy5oLmluLiAgR2VuZXJhdGVkIGZyb20gY29uZmlndXJl
LmFjIGJ5IGF1dG9oZWFkZXIuICAqLworCisvKiBEZWZpbmUgdG8gb25lIG9mIGBfZ2V0YjY3Jywg
YEdFVEI2NycsIGBnZXRiNjcnIGZvciBDcmF5LTIgYW5kIENyYXktWU1QCisgICBzeXN0ZW1zLiBU
aGlzIGZ1bmN0aW9uIGlzIHJlcXVpcmVkIGZvciBgYWxsb2NhLmMnIHN1cHBvcnQgb24gdGhvc2Ug
c3lzdGVtcy4KKyAgICovCisjdW5kZWYgQ1JBWV9TVEFDS1NFR19FTkQKKworLyogRGVmaW5lIHRv
IDEgaWYgdXNpbmcgYGFsbG9jYS5jJy4gKi8KKyN1bmRlZiBDX0FMTE9DQQorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGFsYXJtJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0FM
QVJNCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIGBhbGxvY2EnLCBhcyBhIGZ1bmN0aW9u
IG9yIG1hY3JvLiAqLworI3VuZGVmIEhBVkVfQUxMT0NBCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIDxhbGxvY2EuaD4gYW5kIGl0IHNob3VsZCBiZSB1c2VkIChub3Qgb24gVWx0cml4KS4K
KyAgICovCisjdW5kZWYgSEFWRV9BTExPQ0FfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPGFycGEvaW5ldC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0FSUEFfSU5F
VF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgYXRleGl0JyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX0FURVhJVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YGJ6ZXJvJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0JaRVJPCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgY2xvY2tfZ2V0dGltZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFW
RV9DTE9DS19HRVRUSU1FCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZHVwMicg
ZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9EVVAyCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSA8ZmNudGwuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9GQ05UTF9ICisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZmRhdGFzeW5jJyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX0ZEQVRBU1lOQworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YGZvcmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfRk9SSworCisvKiBEZWZpbmUgdG8gMSBp
ZiBmc2Vla28gKGFuZCBwcmVzdW1hYmx5IGZ0ZWxsbykgZXhpc3RzIGFuZCBpcyBkZWNsYXJlZC4g
Ki8KKyN1bmRlZiBIQVZFX0ZTRUVLTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YGZ0cnVuY2F0ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9GVFJVTkNBVEUKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRjd2QnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfR0VUQ1dECisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZ2V0aG9zdGJ5bmFt
ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRIT1NUQllOQU1FCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSBgZ2V0aG9zdG5hbWUnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfR0VUSE9TVE5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRwYWdl
c2l6ZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9HRVRQQUdFU0laRQorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldHRpbWVvZmRheScgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9HRVRUSU1FT0ZEQVkKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBpbmV0
X250b2EnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfSU5FVF9OVE9BCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8aW50dHlwZXMuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYg
SEFWRV9JTlRUWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgaXNhc2Np
aScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9JU0FTQ0lJCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgY3J5cHRvJyBsaWJyYXJ5ICgtbGNyeXB0bykuICovCisjdW5kZWYgSEFW
RV9MSUJDUllQVE8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxsaWJpbnRsLmg+
IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTElCSU5UTF9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgcnQnIGxpYnJhcnkgKC1scnQpLiAqLworI3VuZGVmIEhBVkVfTElC
UlQKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB1dWlkJyBsaWJyYXJ5ICgtbHV1
aWQpLiAqLworI3VuZGVmIEhBVkVfTElCVVVJRAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHlhamwnIGxpYnJhcnkgKC1seWFqbCkuICovCisjdW5kZWYgSEFWRV9MSUJZQUpMCisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgeicgbGlicmFyeSAoLWx6KS4gKi8KKyN1
bmRlZiBIQVZFX0xJQloKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxsaW1pdHMu
aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9MSU1JVFNfSAorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgaGF2ZSB0aGUgYGxvY2FsdGltZV9yJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X0xPQ0FMVElNRV9SCisKKy8qIERlZmluZSB0byAxIGlmIHlvdXIgc3lzdGVtIGhhcyBhIEdOVSBs
aWJjIGNvbXBhdGlibGUgYG1hbGxvYycgZnVuY3Rpb24sIGFuZAorICAgdG8gMCBvdGhlcndpc2Uu
ICovCisjdW5kZWYgSEFWRV9NQUxMT0MKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IDxtYWxsb2MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9NQUxMT0NfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbWNocicgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9NRU1DSFIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBtZW1tb3ZlJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01FTU1PVkUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxtZW1vcnkuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9NRU1PUllf
SAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbXNldCcgZnVuY3Rpb24uICov
CisjdW5kZWYgSEFWRV9NRU1TRVQKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBt
a2RpcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NS0RJUgorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgYG1rZmlmbycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NS0ZJRk8K
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgYSB3b3JraW5nIGBtbWFwJyBzeXN0ZW0gY2Fs
bC4gKi8KKyN1bmRlZiBIQVZFX01NQVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IGBtdW5tYXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTVVOTUFQCisKKy8qIERlZmluZSB0
byAxIGlmIHlvdSBoYXZlIHRoZSA8bmV0ZGIuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFW
RV9ORVREQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bmV0aW5ldC9pbi5o
PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX05FVElORVRfSU5fSAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHBhdGhjb25mJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X1BBVEhDT05GCisKKy8qIERlZmluZSB0byAxIGlmIHRoZSBzeXN0ZW0gaGFzIHRoZSB0eXBlIGBw
dHJkaWZmX3QnLiAqLworI3VuZGVmIEhBVkVfUFRSRElGRl9UCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdXIgc3lzdGVtIGhhcyBhIEdOVSBsaWJjIGNvbXBhdGlibGUgYHJlYWxsb2MnIGZ1bmN0aW9u
LAorICAgYW5kIHRvIDAgb3RoZXJ3aXNlLiAqLworI3VuZGVmIEhBVkVfUkVBTExPQworCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHJlYWxwYXRoJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1JFQUxQQVRICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgcmVnY29t
cCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9SRUdDT01QCisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgcm1kaXInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUk1ESVIKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzZWxlY3QnIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfU0VMRUNUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc2V0ZW52
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NFVEVOVgorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgYHNvY2tldCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TT0NLRVQKKwor
LyogRGVmaW5lIHRvIDEgaWYgc3RkYm9vbC5oIGNvbmZvcm1zIHRvIEM5OS4gKi8KKyN1bmRlZiBI
QVZFX1NUREJPT0xfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGRlZi5o
PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURERFRl9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8c3RkaW50Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1RESU5UX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdGRsaWIuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERMSUJfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgYHN0cmNhc2VjbXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ0FT
RUNNUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmNocicgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9TVFJDSFIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhl
IGBzdHJjc3BuJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUkNTUE4KKworLyogRGVmaW5l
IHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJkdXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVf
U1RSRFVQCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyZXJyb3InIGZ1bmN0
aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSRVJST1IKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzdHJpbmdzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1RSSU5HU19I
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5nLmg+IGhlYWRlciBmaWxl
LiAqLworI3VuZGVmIEhBVkVfU1RSSU5HX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIGBzdHJuZHVwJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUk5EVVAKKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJwYnJrJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBI
QVZFX1NUUlBCUksKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJyY2hyJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlJDSFIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBzdHJzcG4nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSU1BOCisKKy8q
IERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3Ryc3RyJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1NUUlNUUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnRvbCcg
ZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJUT0wKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBzdHJ0b3VsJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlRPVUwKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJ0b3VsbCcgZnVuY3Rpb24uICovCisj
dW5kZWYgSEFWRV9TVFJUT1VMTAorCisvKiBEZWZpbmUgdG8gMSBpZiBgc3RfYmxrc2l6ZScgaXMg
YSBtZW1iZXIgb2YgYHN0cnVjdCBzdGF0Jy4gKi8KKyN1bmRlZiBIQVZFX1NUUlVDVF9TVEFUX1NU
X0JMS1NJWkUKKworLyogRGVmaW5lIHRvIDEgaWYgYHN0X2Jsb2NrcycgaXMgYSBtZW1iZXIgb2Yg
YHN0cnVjdCBzdGF0Jy4gKi8KKyN1bmRlZiBIQVZFX1NUUlVDVF9TVEFUX1NUX0JMT0NLUworCisv
KiBEZWZpbmUgdG8gMSBpZiBgc3RfcmRldicgaXMgYSBtZW1iZXIgb2YgYHN0cnVjdCBzdGF0Jy4g
Ki8KKyN1bmRlZiBIQVZFX1NUUlVDVF9TVEFUX1NUX1JERVYKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91ciBgc3RydWN0IHN0YXQnIGhhcyBgc3RfYmxvY2tzJy4gRGVwcmVjYXRlZCwgdXNlCisgICBg
SEFWRV9TVFJVQ1RfU1RBVF9TVF9CTE9DS1MnIGluc3RlYWQuICovCisjdW5kZWYgSEFWRV9TVF9C
TE9DS1MKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXNsb2cuaD4gaGVhZGVy
IGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNMT0dfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug
aGF2ZSB0aGUgPHN5cy9maWxlLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX0ZJ
TEVfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9pb2N0bC5oPiBoZWFk
ZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19JT0NUTF9ICisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSA8c3lzL21vdW50Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
U1lTX01PVU5UX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvcGFyYW0u
aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfUEFSQU1fSAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zb2NrZXQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5k
ZWYgSEFWRV9TWVNfU09DS0VUX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxz
eXMvc3RhdHZmcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19TVEFUVkZTX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvc3RhdC5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19TVEFUX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgdGhlIDxzeXMvdGltZS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19USU1F
X0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzeXMvdHlwZXMuaD4gaGVhZGVy
IGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfVFlQRVNfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5
b3UgaGF2ZSB0aGUgPHRlcm1pb3MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9URVJN
SU9TX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB0enNldCcgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9UWlNFVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHVuYW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1VOQU1FCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8dW5pc3RkLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVf
VU5JU1REX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB2Zm9yaycgZnVuY3Rp
b24uICovCisjdW5kZWYgSEFWRV9WRk9SSworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHZmb3JrLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfVkZPUktfSAorCisvKiBE
ZWZpbmUgdG8gMSBpZiBgZm9yaycgd29ya3MuICovCisjdW5kZWYgSEFWRV9XT1JLSU5HX0ZPUksK
KworLyogRGVmaW5lIHRvIDEgaWYgYHZmb3JrJyB3b3Jrcy4gKi8KKyN1bmRlZiBIQVZFX1dPUktJ
TkdfVkZPUksKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx5YWpsL3lhamxfdmVy
c2lvbi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1lBSkxfWUFKTF9WRVJTSU9OX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgdGhlIHN5c3RlbSBoYXMgdGhlIHR5cGUgYF9Cb29sJy4gKi8K
KyN1bmRlZiBIQVZFX19CT09MCisKKy8qIERlZmluZSB0byAxIGlmIGBsc3RhdCcgZGVyZWZlcmVu
Y2VzIGEgc3ltbGluayBzcGVjaWZpZWQgd2l0aCBhIHRyYWlsaW5nCisgICBzbGFzaC4gKi8KKyN1
bmRlZiBMU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSworCisvKiBEZWZpbmUgdG8gMSBpZiBg
bWFqb3InLCBgbWlub3InLCBhbmQgYG1ha2VkZXYnIGFyZSBkZWNsYXJlZCBpbiA8bWtkZXYuaD4u
CisgICAqLworI3VuZGVmIE1BSk9SX0lOX01LREVWCisKKy8qIERlZmluZSB0byAxIGlmIGBtYWpv
cicsIGBtaW5vcicsIGFuZCBgbWFrZWRldicgYXJlIGRlY2xhcmVkIGluCisgICA8c3lzbWFjcm9z
Lmg+LiAqLworI3VuZGVmIE1BSk9SX0lOX1NZU01BQ1JPUworCisvKiBEZWZpbmUgdG8gdGhlIGFk
ZHJlc3Mgd2hlcmUgYnVnIHJlcG9ydHMgZm9yIHRoaXMgcGFja2FnZSBzaG91bGQgYmUgc2VudC4g
Ki8KKyN1bmRlZiBQQUNLQUdFX0JVR1JFUE9SVAorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFt
ZSBvZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9OQU1FCisKKy8qIERlZmluZSB0
byB0aGUgZnVsbCBuYW1lIGFuZCB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQ
QUNLQUdFX1NUUklORworCisvKiBEZWZpbmUgdG8gdGhlIG9uZSBzeW1ib2wgc2hvcnQgbmFtZSBv
ZiB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9UQVJOQU1FCisKKy8qIERlZmluZSB0
byB0aGUgaG9tZSBwYWdlIGZvciB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9VUkwK
KworLyogRGVmaW5lIHRvIHRoZSB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQ
QUNLQUdFX1ZFUlNJT04KKworLyogSWYgdXNpbmcgdGhlIEMgaW1wbGVtZW50YXRpb24gb2YgYWxs
b2NhLCBkZWZpbmUgaWYgeW91IGtub3cgdGhlCisgICBkaXJlY3Rpb24gb2Ygc3RhY2sgZ3Jvd3Ro
IGZvciB5b3VyIHN5c3RlbTsgb3RoZXJ3aXNlIGl0IHdpbGwgYmUKKyAgIGF1dG9tYXRpY2FsbHkg
ZGVkdWNlZCBhdCBydW50aW1lLgorCVNUQUNLX0RJUkVDVElPTiA+IDAgPT4gZ3Jvd3MgdG93YXJk
IGhpZ2hlciBhZGRyZXNzZXMKKwlTVEFDS19ESVJFQ1RJT04gPCAwID0+IGdyb3dzIHRvd2FyZCBs
b3dlciBhZGRyZXNzZXMKKwlTVEFDS19ESVJFQ1RJT04gPSAwID0+IGRpcmVjdGlvbiBvZiBncm93
dGggdW5rbm93biAqLworI3VuZGVmIFNUQUNLX0RJUkVDVElPTgorCisvKiBEZWZpbmUgdG8gMSBp
ZiB5b3UgaGF2ZSB0aGUgQU5TSSBDIGhlYWRlciBmaWxlcy4gKi8KKyN1bmRlZiBTVERDX0hFQURF
UlMKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGNhbiBzYWZlbHkgaW5jbHVkZSBib3RoIDxzeXMv
dGltZS5oPiBhbmQgPHRpbWUuaD4uICovCisjdW5kZWYgVElNRV9XSVRIX1NZU19USU1FCisKKy8q
IERlZmluZSB0byAxIHRvIG1ha2UgZnNlZWtvIHZpc2libGUgb24gc29tZSBob3N0cyAoZS5nLiBn
bGliYyAyLjIpLiAqLworI3VuZGVmIF9MQVJHRUZJTEVfU09VUkNFCisKKy8qIERlZmluZSB0byAx
IGlmIG9uIE1JTklYLiAqLworI3VuZGVmIF9NSU5JWAorCisvKiBEZWZpbmUgdG8gMiBpZiB0aGUg
c3lzdGVtIGRvZXMgbm90IHByb3ZpZGUgUE9TSVguMSBmZWF0dXJlcyBleGNlcHQgd2l0aAorICAg
dGhpcyBkZWZpbmVkLiAqLworI3VuZGVmIF9QT1NJWF8xX1NPVVJDRQorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgbmVlZCB0byBpbiBvcmRlciBmb3IgYHN0YXQnIGFuZCBvdGhlciB0aGluZ3MgdG8g
d29yay4gKi8KKyN1bmRlZiBfUE9TSVhfU09VUkNFCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAy
LjUuMSBzbyB0aGUgdWludDMyX3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisgICA8cHRo
cmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVkZWYgd2Vy
ZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50YXggZXJy
b3IuICovCisjdW5kZWYgX1VJTlQzMl9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAyLjUuMSBz
byB0aGUgdWludDY0X3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisgICA8cHRocmVhZC5o
Piwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVkZWYgd2VyZSBhbGxv
d2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50YXggZXJyb3IuICov
CisjdW5kZWYgX1VJTlQ2NF9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAyLjUuMSBzbyB0aGUg
dWludDhfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhyZWFkLmg+LCBvciA8
c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJlIGFsbG93ZWQsIHRo
ZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJvci4gKi8KKyN1bmRl
ZiBfVUlOVDhfVAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2Vzbid0
IGRlZmluZS4gKi8KKyN1bmRlZiBnaWRfdAorCisvKiBEZWZpbmUgdG8gYF9faW5saW5lX18nIG9y
IGBfX2lubGluZScgaWYgdGhhdCdzIHdoYXQgdGhlIEMgY29tcGlsZXIKKyAgIGNhbGxzIGl0LCBv
ciB0byBub3RoaW5nIGlmICdpbmxpbmUnIGlzIG5vdCBzdXBwb3J0ZWQgdW5kZXIgYW55IG5hbWUu
ICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cworI3VuZGVmIGlubGluZQorI2VuZGlmCisKKy8qIERl
ZmluZSB0byB0aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3Rs
eSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNs
dWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIGludDE2X3QKKworLyogRGVmaW5lIHRv
IHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBleGFjdGx5IDMyIGJp
dHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRv
IG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MzJfdAorCisvKiBEZWZpbmUgdG8gdGhlIHR5
cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkgNjQgYml0cyBpZgor
ICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVkZXMgZG8gbm90IGRl
ZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQ2NF90CisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBh
IHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMgaWYgc3VjaAorICAg
YSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5vdCBkZWZpbmUgaXQu
ICovCisjdW5kZWYgaW50OF90CisKKy8qIERlZmluZSB0byBycGxfbWFsbG9jIGlmIHRoZSByZXBs
YWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiBtYWxsb2MKKworLyog
RGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVmaW5lLiAqLworI3Vu
ZGVmIG1vZGVfdAorCisvKiBEZWZpbmUgdG8gYGxvbmcgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRv
ZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBvZmZfdAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYg
PHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgcGlkX3QKKworLyogRGVm
aW5lIHRvIHJwbF9yZWFsbG9jIGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUg
dXNlZC4gKi8KKyN1bmRlZiByZWFsbG9jCisKKy8qIERlZmluZSB0byB0aGUgZXF1aXZhbGVudCBv
ZiB0aGUgQzk5ICdyZXN0cmljdCcga2V5d29yZCwgb3IgdG8KKyAgIG5vdGhpbmcgaWYgdGhpcyBp
cyBub3Qgc3VwcG9ydGVkLiAgRG8gbm90IGRlZmluZSBpZiByZXN0cmljdCBpcworICAgc3VwcG9y
dGVkIGRpcmVjdGx5LiAgKi8KKyN1bmRlZiByZXN0cmljdAorLyogV29yayBhcm91bmQgYSBidWcg
aW4gU3VuIEMrKzogaXQgZG9lcyBub3Qgc3VwcG9ydCBfUmVzdHJpY3Qgb3IKKyAgIF9fcmVzdHJp
Y3RfXywgZXZlbiB0aG91Z2ggdGhlIGNvcnJlc3BvbmRpbmcgU3VuIEMgY29tcGlsZXIgZW5kcyB1
cCB3aXRoCisgICAiI2RlZmluZSByZXN0cmljdCBfUmVzdHJpY3QiIG9yICIjZGVmaW5lIHJlc3Ry
aWN0IF9fcmVzdHJpY3RfXyIgaW4gdGhlCisgICBwcmV2aW91cyBsaW5lLiAgUGVyaGFwcyBzb21l
IGZ1dHVyZSB2ZXJzaW9uIG9mIFN1biBDKysgd2lsbCB3b3JrIHdpdGgKKyAgIHJlc3RyaWN0OyBp
ZiBzbywgaG9wZWZ1bGx5IGl0IGRlZmluZXMgX19SRVNUUklDVCBsaWtlIFN1biBDIGRvZXMuICAq
LworI2lmIGRlZmluZWQgX19TVU5QUk9fQ0MgJiYgIWRlZmluZWQgX19SRVNUUklDVAorIyBkZWZp
bmUgX1Jlc3RyaWN0CisjIGRlZmluZSBfX3Jlc3RyaWN0X18KKyNlbmRpZgorCisvKiBEZWZpbmUg
dG8gYHVuc2lnbmVkIGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisj
dW5kZWYgc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXMg
bm90IGRlZmluZS4gKi8KKyN1bmRlZiBzc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8
c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5lLiAqLworI3VuZGVmIHVpZF90CisKKy8qIERlZmlu
ZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3Rs
eSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNs
dWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQxNl90CisKKy8qIERlZmluZSB0
byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSAz
MiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNsdWRl
cyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQzMl90CisKKy8qIERlZmluZSB0byB0
aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA2NCBi
aXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFyZCBpbmNsdWRlcyBk
byBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQ2NF90CisKKy8qIERlZmluZSB0byB0aGUg
dHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMg
aWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5v
dCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDhfdAorCisvKiBEZWZpbmUgYXMgYGZvcmsnIGlm
IGB2Zm9yaycgZG9lcyBub3Qgd29yay4gKi8KKyN1bmRlZiB2Zm9yawpkaWZmIC1yIDg3MjE4YmQz
NjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY29uZmlnLnN1YgotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuc3ViCU1vbiBGZWIg
MjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDE3NzEgQEAKKyMhIC9iaW4vc2gKKyMg
Q29uZmlndXJhdGlvbiB2YWxpZGF0aW9uIHN1YnJvdXRpbmUgc2NyaXB0LgorIyAgIENvcHlyaWdo
dCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5OCwgMTk5OSwKKyMg
ICAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAyMDA3LCAyMDA4LCAy
MDA5LCAyMDEwLAorIyAgIDIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3Rp
bWVzdGFtcD0nMjAxMS0xMS0xMScKKworIyBUaGlzIGZpbGUgaXMgKGluIHByaW5jaXBsZSkgY29t
bW9uIHRvIEFMTCBHTlUgc29mdHdhcmUuCisjIFRoZSBwcmVzZW5jZSBvZiBhIG1hY2hpbmUgaW4g
dGhpcyBmaWxlIHN1Z2dlc3RzIHRoYXQgU09NRSBHTlUgc29mdHdhcmUKKyMgY2FuIGhhbmRsZSB0
aGF0IG1hY2hpbmUuICBJdCBkb2VzIG5vdCBpbXBseSBBTEwgR05VIHNvZnR3YXJlIGNhbi4KKyMK
KyMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu
ZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
bjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIgb3B0aW9u
KSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisjIGJ1dCBXSVRIT1VUIEFOWSBXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyMgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91IHNob3Vs
ZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK
KyMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3RyZWV0IC0gRmlmdGggRmxv
b3IsIEJvc3RvbiwgTUEKKyMgMDIxMTAtMTMwMSwgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhj
ZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3Ry
aWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBj
b25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVk
ZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZv
ciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKworIyBQbGVhc2Ugc2VuZCBwYXRjaGVzIHRv
IDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4gIFN1Ym1pdCBhIGNvbnRleHQKKyMgZGlmZiBhbmQg
YSBwcm9wZXJseSBmb3JtYXR0ZWQgR05VIENoYW5nZUxvZyBlbnRyeS4KKyMKKyMgQ29uZmlndXJh
dGlvbiBzdWJyb3V0aW5lIHRvIHZhbGlkYXRlIGFuZCBjYW5vbmljYWxpemUgYSBjb25maWd1cmF0
aW9uIHR5cGUuCisjIFN1cHBseSB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24gdHlwZSBhcyBh
biBhcmd1bWVudC4KKyMgSWYgaXQgaXMgaW52YWxpZCwgd2UgcHJpbnQgYW4gZXJyb3IgbWVzc2Fn
ZSBvbiBzdGRlcnIgYW5kIGV4aXQgd2l0aCBjb2RlIDEuCisjIE90aGVyd2lzZSwgd2UgcHJpbnQg
dGhlIGNhbm9uaWNhbCBjb25maWcgdHlwZSBvbiBzdGRvdXQgYW5kIHN1Y2NlZWQuCisKKyMgWW91
IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgc2NyaXB0IGZyb206CisjIGh0dHA6
Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47
Zj1jb25maWcuc3ViO2hiPUhFQUQKKworIyBUaGlzIGZpbGUgaXMgc3VwcG9zZWQgdG8gYmUgdGhl
IHNhbWUgZm9yIGFsbCBHTlUgcGFja2FnZXMKKyMgYW5kIHJlY29nbml6ZSBhbGwgdGhlIENQVSB0
eXBlcywgc3lzdGVtIHR5cGVzIGFuZCBhbGlhc2VzCisjIHRoYXQgYXJlIG1lYW5pbmdmdWwgd2l0
aCAqYW55KiBHTlUgc29mdHdhcmUuCisjIEVhY2ggcGFja2FnZSBpcyByZXNwb25zaWJsZSBmb3Ig
cmVwb3J0aW5nIHdoaWNoIHZhbGlkIGNvbmZpZ3VyYXRpb25zCisjIGl0IGRvZXMgbm90IHN1cHBv
cnQuICBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaAorIyBhIGZhaWx1cmUg
dG8gc3VwcG9ydCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZnJvbSBhIG1lYW5pbmdsZXNzCisjIGNv
bmZpZ3VyYXRpb24uCisKKyMgVGhlIGdvYWwgb2YgdGhpcyBmaWxlIGlzIHRvIG1hcCBhbGwgdGhl
IHZhcmlvdXMgdmFyaWF0aW9ucyBvZiBhIGdpdmVuCisjIG1hY2hpbmUgc3BlY2lmaWNhdGlvbiBp
bnRvIGEgc2luZ2xlIHNwZWNpZmljYXRpb24gaW4gdGhlIGZvcm06CisjCUNQVV9UWVBFLU1BTlVG
QUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNCisjIG9yIGluIHNvbWUgY2FzZXMsIHRoZSBuZXdlciBm
b3VyLXBhcnQgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVSQVRJTkdf
U1lTVEVNCisjIEl0IGlzIHdyb25nIHRvIGVjaG8gYW55IG90aGVyIHR5cGUgb2Ygc3BlY2lmaWNh
dGlvbi4KKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdlPSJcCitV
c2FnZTogJDAgW09QVElPTl0gQ1BVLU1GUi1PUFNZUworICAgICAgICQwIFtPUFRJT05dIEFMSUFT
CisKK0Nhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gbmFtZS4KKworT3BlcmF0aW9uIG1vZGVz
OgorICAtaCwgLS1oZWxwICAgICAgICAgcHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQKKyAgLXQs
IC0tdGltZS1zdGFtcCAgIHByaW50IGRhdGUgb2YgbGFzdCBtb2RpZmljYXRpb24sIHRoZW4gZXhp
dAorICAtdiwgLS12ZXJzaW9uICAgICAgcHJpbnQgdmVyc2lvbiBudW1iZXIsIHRoZW4gZXhpdAor
CitSZXBvcnQgYnVncyBhbmQgcGF0Y2hlcyB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9yZz4uIgor
Cit2ZXJzaW9uPSJcCitHTlUgY29uZmlnLnN1YiAoJHRpbWVzdGFtcCkKKworQ29weXJpZ2h0IChD
KSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LCAyMDAwLAor
MjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCwgMjAwOSwgMjAx
MCwgMjAxMSBGcmVlCitTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK1RoaXMgaXMgZnJlZSBz
b2Z0d2FyZTsgc2VlIHRoZSBzb3VyY2UgZm9yIGNvcHlpbmcgY29uZGl0aW9ucy4gIFRoZXJlIGlz
IE5PCit3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZP
UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iCisKK2hlbHA9IgorVHJ5IFxgJG1lIC0taGVscCcgZm9y
IG1vcmUgaW5mb3JtYXRpb24uIgorCisjIFBhcnNlIGNvbW1hbmQgbGluZQord2hpbGUgdGVzdCAk
IyAtZ3QgMCA7IGRvCisgIGNhc2UgJDEgaW4KKyAgICAtLXRpbWUtc3RhbXAgfCAtLXRpbWUqIHwg
LXQgKQorICAgICAgIGVjaG8gIiR0aW1lc3RhbXAiIDsgZXhpdCA7OworICAgIC0tdmVyc2lvbiB8
IC12ICkKKyAgICAgICBlY2hvICIkdmVyc2lvbiIgOyBleGl0IDs7CisgICAgLS1oZWxwIHwgLS1o
KiB8IC1oICkKKyAgICAgICBlY2hvICIkdXNhZ2UiOyBleGl0IDs7CisgICAgLS0gKSAgICAgIyBT
dG9wIG9wdGlvbiBwcm9jZXNzaW5nCisgICAgICAgc2hpZnQ7IGJyZWFrIDs7CisgICAgLSApCSMg
VXNlIHN0ZGluIGFzIGlucHV0LgorICAgICAgIGJyZWFrIDs7CisgICAgLSogKQorICAgICAgIGVj
aG8gIiRtZTogaW52YWxpZCBvcHRpb24gJDEkaGVscCIKKyAgICAgICBleGl0IDEgOzsKKworICAg
ICpsb2NhbCopCisgICAgICAgIyBGaXJzdCBwYXNzIHRocm91Z2ggYW55IGxvY2FsIG1hY2hpbmUg
dHlwZXMuCisgICAgICAgZWNobyAkMQorICAgICAgIGV4aXQgOzsKKworICAgICogKQorICAgICAg
IGJyZWFrIDs7CisgIGVzYWMKK2RvbmUKKworY2FzZSAkIyBpbgorIDApIGVjaG8gIiRtZTogbWlz
c2luZyBhcmd1bWVudCRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworIDEpIDs7CisgKikgZWNobyAi
JG1lOiB0b28gbWFueSBhcmd1bWVudHMkaGVscCIgPiYyCisgICAgZXhpdCAxOzsKK2VzYWMKKwor
IyBTZXBhcmF0ZSB3aGF0IHRoZSB1c2VyIGdhdmUgaW50byBDUFUtQ09NUEFOWSBhbmQgT1Mgb3Ig
S0VSTkVMLU9TIChpZiBhbnkpLgorIyBIZXJlIHdlIG11c3QgcmVjb2duaXplIGFsbCB0aGUgdmFs
aWQgS0VSTkVMLU9TIGNvbWJpbmF0aW9ucy4KK21heWJlX29zPWBlY2hvICQxIHwgc2VkICdzL15c
KC4qXCktXChbXi1dKi1bXi1dKlwpJC9cMi8nYAorY2FzZSAkbWF5YmVfb3MgaW4KKyAgbnRvLXFu
eCogfCBsaW51eC1nbnUqIHwgbGludXgtYW5kcm9pZCogfCBsaW51eC1kaWV0bGliYyB8IGxpbnV4
LW5ld2xpYiogfCBcCisgIGxpbnV4LXVjbGliYyogfCB1Y2xpbnV4LXVjbGliYyogfCB1Y2xpbnV4
LWdudSogfCBrZnJlZWJzZCotZ251KiB8IFwKKyAga25ldGJzZCotZ251KiB8IG5ldGJzZCotZ251
KiB8IFwKKyAga29wZW5zb2xhcmlzKi1nbnUqIHwgXAorICBzdG9ybS1jaGFvcyogfCBvczItZW14
KiB8IHJ0bWstbm92YSopCisgICAgb3M9LSRtYXliZV9vcworICAgIGJhc2ljX21hY2hpbmU9YGVj
aG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0qXCkkL1wxLydgCisgICAgOzsKKyAg
KikKKyAgICBiYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzLy1bXi1dKiQvLydgCisgICAg
aWYgWyAkYmFzaWNfbWFjaGluZSAhPSAkMSBdCisgICAgdGhlbiBvcz1gZWNobyAkMSB8IHNlZCAn
cy8uKi0vLS8nYAorICAgIGVsc2Ugb3M9OyBmaQorICAgIDs7Citlc2FjCisKKyMjIyBMZXQncyBy
ZWNvZ25pemUgY29tbW9uIG1hY2hpbmVzIGFzIG5vdCBiZWluZyBvcGVyYXRpbmcgc3lzdGVtcyBz
bworIyMjIHRoYXQgdGhpbmdzIGxpa2UgY29uZmlnLnN1YiBkZWNzdGF0aW9uLTMxMDAgd29yay4g
IFdlIGFsc28KKyMjIyByZWNvZ25pemUgc29tZSBtYW51ZmFjdHVyZXJzIGFzIG5vdCBiZWluZyBv
cGVyYXRpbmcgc3lzdGVtcywgc28gd2UKKyMjIyBjYW4gcHJvdmlkZSBkZWZhdWx0IG9wZXJhdGlu
ZyBzeXN0ZW1zIGJlbG93LgorY2FzZSAkb3MgaW4KKwktc3VuKm9zKikKKwkJIyBQcmV2ZW50IGZv
bGxvd2luZyBjbGF1c2UgZnJvbSBoYW5kbGluZyB0aGlzIGludmFsaWQgaW5wdXQuCisJCTs7CisJ
LWRlYyogfCAtbWlwcyogfCAtc2VxdWVudCogfCAtZW5jb3JlKiB8IC1wYzUzMiogfCAtc2dpKiB8
IC1zb255KiB8IFwKKwktYXR0KiB8IC03MzAwKiB8IC0zMzAwKiB8IC1kZWx0YSogfCAtbW90b3Jv
bGEqIHwgLXN1blsyMzRdKiB8IFwKKwktdW5pY29tKiB8IC1pYm0qIHwgLW5leHQgfCAtaHAgfCAt
aXNpKiB8IC1hcG9sbG8gfCAtYWx0b3MqIHwgXAorCS1jb252ZXJnZW50KiB8IC1uY3IqIHwgLW5l
d3MgfCAtMzIqIHwgLTM2MDAqIHwgLTMxMDAqIHwgLWhpdGFjaGkqIHxcCisJLWNbMTIzXSogfCAt
Y29udmV4KiB8IC1zdW4gfCAtY3JkcyB8IC1vbXJvbiogfCAtZGcgfCAtdWx0cmEgfCAtdHRpKiB8
IFwKKwktaGFycmlzIHwgLWRvbHBoaW4gfCAtaGlnaGxldmVsIHwgLWdvdWxkIHwgLWNibSB8IC1u
cyB8IC1tYXNzY29tcCB8IFwKKwktYXBwbGUgfCAtYXhpcyB8IC1rbnV0aCB8IC1jcmF5IHwgLW1p
Y3JvYmxhemUpCisJCW9zPQorCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWJsdWVnZW5lKikK
KwkJb3M9LWNuaworCQk7OworCS1zaW0gfCAtY2lzY28gfCAtb2tpIHwgLXdlYyB8IC13aW5ib25k
KQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7OworCS1zY291dCkKKwkJOzsKKwktd3Jz
KQorCQlvcz0tdnh3b3JrcworCQliYXNpY19tYWNoaW5lPSQxCisJCTs7CisJLWNob3J1c29zKikK
KwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktY2hvcnVzcmRiKQor
CQlvcz0tY2hvcnVzcmRiCisJCWJhc2ljX21hY2hpbmU9JDEKKwkJOzsKKwktaGl1eCopCisJCW9z
PS1oaXV4d2UyCisJCTs7CisJLXNjbzYpCisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281KQorCQlvcz0t
c2NvMy4ydjUKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1w
Yy8nYAorCQk7OworCS1zY280KQorCQlvcz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQtOV0qKQor
CQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJhc2ljX21h
Y2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktc2NvMy4y
dls0LTldKikKKwkJIyBEb24ndCBmb3JnZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBvciBuZXdl
ci4KKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAor
CQk7OworCS1zY281djYqKQorCQkjIERvbid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlzIDMuMnY0
IG9yIG5ld2VyLgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2
LXBjLydgCisJCTs7CisJLXNjbyopCisJCW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNoaW5lPWBl
Y2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXVkayopCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktaXNj
KQorCQlvcz0taXNjMi4yCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYt
LiovODYtcGMvJ2AKKwkJOzsKKwktY2xpeCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBlci1pbnRl
cmdyYXBoCisJCTs7CisJLWlzYyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktbHlueCopCisJCW9zPS1seW54b3MKKwkJOzsKKwkt
cHR4KikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1zZXF1
ZW50LydgCisJCTs7CisJLXdpbmRvd3NudCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAncy93
aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsKKwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7CisJLW1p
bnQgfCAtbWludFswLTldKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9zPS1taW50
CisJCTs7Citlc2FjCisKKyMgRGVjb2RlIGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNPTVBBTlkg
Y29tYmluYXRpb25zLgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXplIHRoZSBi
YXNpYyBDUFUgdHlwZXMgd2l0aG91dCBjb21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBvbWl0dGVk
IGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUgc3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkxNzUwYSB8
IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFscGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFldjU2IHwg
YWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2NGV2WzQt
OF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhhNjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjddIFwKKwl8
IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFybSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBhcm12WzIz
NDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2ciB8IGF2cjMyIFwKKyAgICAgICAgfCBiZTMyIHwgYmU2
NCBcCisJfCBiZmluIFwKKwl8IGM0eCB8IGNsaXBwZXIgXAorCXwgZDEwdiB8IGQzMHYgfCBkbHgg
fCBkc3AxNnh4IFwKKwl8IGVwaXBoYW55IFwKKwl8IGZpZG8gfCBmcjMwIHwgZnJ2IFwKKwl8IGg4
MzAwIHwgaDg1MDAgfCBocHBhIHwgaHBwYTEuWzAxXSB8IGhwcGEyLjAgfCBocHBhMi4wW253XSB8
IGhwcGE2NCBcCisJfCBoZXhhZ29uIFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlhNjQgXAor
CXwgaXAyayB8IGlxMjAwMCBcCisJfCBsZTMyIHwgbGU2NCBcCisJfCBsbTMyIFwKKwl8IG0zMmMg
fCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsgXAorCXwgbWF4cSB8IG1iIHwg
bWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwgbWlwcyB8IG1pcHNiZSB8IG1p
cHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAorCXwgbWlwczY0IHwgbWlwczY0
ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwgXAorCXwgbWlwczY0b3Jpb24g
fCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlwczY0cjU5MDBlbCBcCisJfCBt
aXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAwIHwgbWlwczY0dnI0MTAwZWwg
XAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAorCXwgbWlwczY0dnI1MDAwIHwg
bWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlwczY0dnI1OTAwZWwgXAorCXwg
bWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMycjIgfCBtaXBzaXNhMzJyMmVs
IFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1pcHNpc2E2NHIyIHwgbWlwc2lz
YTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRzYjFlbCBcCisJfCBtaXBzaXNh
NjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4MzkgfCBtaXBzdHgzOWVsIFwK
Kwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8IG10IFwKKwl8IG1zcDQzMCBc
CisJfCBuZHMzMiB8IG5kczMybGUgfCBuZHMzMmJlIFwKKwl8IG5pb3MgfCBuaW9zMiBcCisJfCBu
czE2ayB8IG5zMzJrIFwKKwl8IG9wZW44IFwKKwl8IG9yMzIgXAorCXwgcGRwMTAgfCBwZHAxMSB8
IHBqIHwgcGpsIFwKKwl8IHBvd2VycGMgfCBwb3dlcnBjNjQgfCBwb3dlcnBjNjRsZSB8IHBvd2Vy
cGNsZSBcCisJfCBweXJhbWlkIFwKKwl8IHJsNzggfCByeCBcCisJfCBzY29yZSBcCisJfCBzaCB8
IHNoWzEyMzRdIHwgc2hbMjRdYSB8IHNoWzI0XWFlYiB8IHNoWzIzXWUgfCBzaFszNF1lYiB8IHNo
ZWIgfCBzaGJlIHwgc2hsZSB8IHNoWzEyMzRdbGUgfCBzaDNlbGUgXAorCXwgc2g2NCB8IHNoNjRs
ZSBcCisJfCBzcGFyYyB8IHNwYXJjNjQgfCBzcGFyYzY0YiB8IHNwYXJjNjR2IHwgc3BhcmM4Nngg
fCBzcGFyY2xldCB8IHNwYXJjbGl0ZSBcCisJfCBzcGFyY3Y4IHwgc3BhcmN2OSB8IHNwYXJjdjli
IHwgc3BhcmN2OXYgXAorCXwgc3B1IFwKKwl8IHRhaG9lIHwgdGljNHggfCB0aWM1NHggfCB0aWM1
NXggfCB0aWM2eCB8IHRpYzgwIHwgdHJvbiBcCisJfCB1Ymljb20zMiBcCisJfCB2ODUwIHwgdjg1
MGUgfCB2ODUwZTEgfCB2ODUwZTIgfCB2ODUwZXMgfCB2ODUwZTJ2MyBcCisJfCB3ZTMyayBcCisJ
fCB4ODYgfCB4YzE2eCB8IHhzdG9ybXkxNiB8IHh0ZW5zYSBcCisJfCB6OGsgfCB6ODApCisJCWJh
c2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93bgorCQk7OworCWM1NHgpCisJCWJhc2lj
X21hY2hpbmU9dGljNTR4LXVua25vd24KKwkJOzsKKwljNTV4KQorCQliYXNpY19tYWNoaW5lPXRp
YzU1eC11bmtub3duCisJCTs7CisJYzZ4KQorCQliYXNpY19tYWNoaW5lPXRpYzZ4LXVua25vd24K
KwkJOzsKKwltNjgxMSB8IG02OGhjMTEgfCBtNjgxMiB8IG02OGhjMTIgfCBwaWNvY2hpcCkKKwkJ
IyBNb3Rvcm9sYSA2OEhDMTEvMTIuCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5r
bm93bgorCQlvcz0tbm9uZQorCQk7OworCW04ODExMCB8IG02ODBbMTIzNDZdMCB8IG02ODM/MiB8
IG02ODM2MCB8IG01MjAwIHwgdjcwIHwgdzY1IHwgejhrKQorCQk7OworCW1zMSkKKwkJYmFzaWNf
bWFjaGluZT1tdC11bmtub3duCisJCTs7CisKKwlzdHJvbmdhcm0gfCB0aHVtYiB8IHhzY2FsZSkK
KwkJYmFzaWNfbWFjaGluZT1hcm0tdW5rbm93bgorCQk7OworCisJeHNjYWxlZWIpCisJCWJhc2lj
X21hY2hpbmU9YXJtZWItdW5rbm93bgorCQk7OworCisJeHNjYWxlZWwpCisJCWJhc2ljX21hY2hp
bmU9YXJtZWwtdW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhhbiBgdW5r
bm93bicKKwkjIGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJlLCBhbmQK
KwkjICgyKSB0aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5pbmcgdXNl
cnMuCisJaSo4NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtcGMK
KwkgIDs7CisJIyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29yZC4KKwkq
LSotKikKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5lIFxgJGJh
c2ljX21hY2hpbmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworCSMgUmVj
b2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgwLSogXAor
CXwgYTI5ay0qIFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1Ni0qIHwg
YWxwaGFldjZbNzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8IGFscGhh
NjRldjU2LSogfCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8IGFscGhh
NjRwY2E1WzY3XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxlLSogfCBh
cm1lYi0qIHwgYXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmUzMi0qIHwgYmU2
NC0qIFwKKwl8IGJmaW4tKiB8IGJzMjAwMC0qIFwKKwl8IGNbMTIzXSogfCBjMzAtKiB8IFtjanRd
OTAtKiB8IGM0eC0qIFwKKwl8IGNsaXBwZXItKiB8IGNyYXludi0qIHwgY3lkcmEtKiBcCisJfCBk
MTB2LSogfCBkMzB2LSogfCBkbHgtKiBcCisJfCBlbHhzaS0qIFwKKwl8IGYzMFswMV0tKiB8IGY3
MDAtKiB8IGZpZG8tKiB8IGZyMzAtKiB8IGZydi0qIHwgZng4MC0qIFwKKwl8IGg4MzAwLSogfCBo
ODUwMC0qIFwKKwl8IGhwcGEtKiB8IGhwcGExLlswMV0tKiB8IGhwcGEyLjAtKiB8IGhwcGEyLjBb
bnddLSogfCBocHBhNjQtKiBcCisJfCBoZXhhZ29uLSogXAorCXwgaSo4Ni0qIHwgaTg2MC0qIHwg
aTk2MC0qIHwgaWE2NC0qIFwKKwl8IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxlMzItKiB8IGxl
NjQtKiBcCisJfCBsbTMyLSogXAorCXwgbTMyYy0qIHwgbTMyci0qIHwgbTMycmxlLSogXAorCXwg
bTY4MDAwLSogfCBtNjgwWzAxMjM0Nl0wLSogfCBtNjgzNjAtKiB8IG02ODM/Mi0qIHwgbTY4ay0q
IFwKKwl8IG04ODExMC0qIHwgbTg4ay0qIHwgbWF4cS0qIHwgbWNvcmUtKiB8IG1ldGFnLSogfCBt
aWNyb2JsYXplLSogXAorCXwgbWlwcy0qIHwgbWlwc2JlLSogfCBtaXBzZWItKiB8IG1pcHNlbC0q
IHwgbWlwc2xlLSogXAorCXwgbWlwczE2LSogXAorCXwgbWlwczY0LSogfCBtaXBzNjRlbC0qIFwK
Kwl8IG1pcHM2NG9jdGVvbi0qIHwgbWlwczY0b2N0ZW9uZWwtKiBcCisJfCBtaXBzNjRvcmlvbi0q
IHwgbWlwczY0b3Jpb25lbC0qIFwKKwl8IG1pcHM2NHI1OTAwLSogfCBtaXBzNjRyNTkwMGVsLSog
XAorCXwgbWlwczY0dnItKiB8IG1pcHM2NHZyZWwtKiBcCisJfCBtaXBzNjR2cjQxMDAtKiB8IG1p
cHM2NHZyNDEwMGVsLSogXAorCXwgbWlwczY0dnI0MzAwLSogfCBtaXBzNjR2cjQzMDBlbC0qIFwK
Kwl8IG1pcHM2NHZyNTAwMC0qIHwgbWlwczY0dnI1MDAwZWwtKiBcCisJfCBtaXBzNjR2cjU5MDAt
KiB8IG1pcHM2NHZyNTkwMGVsLSogXAorCXwgbWlwc2lzYTMyLSogfCBtaXBzaXNhMzJlbC0qIFwK
Kwl8IG1pcHNpc2EzMnIyLSogfCBtaXBzaXNhMzJyMmVsLSogXAorCXwgbWlwc2lzYTY0LSogfCBt
aXBzaXNhNjRlbC0qIFwKKwl8IG1pcHNpc2E2NHIyLSogfCBtaXBzaXNhNjRyMmVsLSogXAorCXwg
bWlwc2lzYTY0c2IxLSogfCBtaXBzaXNhNjRzYjFlbC0qIFwKKwl8IG1pcHNpc2E2NHNyNzFrLSog
fCBtaXBzaXNhNjRzcjcxa2VsLSogXAorCXwgbWlwc3R4MzktKiB8IG1pcHN0eDM5ZWwtKiBcCisJ
fCBtbWl4LSogXAorCXwgbXQtKiBcCisJfCBtc3A0MzAtKiBcCisJfCBuZHMzMi0qIHwgbmRzMzJs
ZS0qIHwgbmRzMzJiZS0qIFwKKwl8IG5pb3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0qIHwgbnAx
LSogfCBuczE2ay0qIHwgbnMzMmstKiBcCisJfCBvcGVuOC0qIFwKKwl8IG9yaW9uLSogXAorCXwg
cGRwMTAtKiB8IHBkcDExLSogfCBwai0qIHwgcGpsLSogfCBwbi0qIHwgcG93ZXItKiBcCisJfCBw
b3dlcnBjLSogfCBwb3dlcnBjNjQtKiB8IHBvd2VycGM2NGxlLSogfCBwb3dlcnBjbGUtKiBcCisJ
fCBweXJhbWlkLSogXAorCXwgcmw3OC0qIHwgcm9tcC0qIHwgcnM2MDAwLSogfCByeC0qIFwKKwl8
IHNoLSogfCBzaFsxMjM0XS0qIHwgc2hbMjRdYS0qIHwgc2hbMjRdYWViLSogfCBzaFsyM11lLSog
fCBzaFszNF1lYi0qIHwgc2hlYi0qIHwgc2hiZS0qIFwKKwl8IHNobGUtKiB8IHNoWzEyMzRdbGUt
KiB8IHNoM2VsZS0qIHwgc2g2NC0qIHwgc2g2NGxlLSogXAorCXwgc3BhcmMtKiB8IHNwYXJjNjQt
KiB8IHNwYXJjNjRiLSogfCBzcGFyYzY0di0qIHwgc3BhcmM4NngtKiB8IHNwYXJjbGV0LSogXAor
CXwgc3BhcmNsaXRlLSogXAorCXwgc3BhcmN2OC0qIHwgc3BhcmN2OS0qIHwgc3BhcmN2OWItKiB8
IHNwYXJjdjl2LSogfCBzdjEtKiB8IHN4Py0qIFwKKwl8IHRhaG9lLSogXAorCXwgdGljMzAtKiB8
IHRpYzR4LSogfCB0aWM1NHgtKiB8IHRpYzU1eC0qIHwgdGljNngtKiB8IHRpYzgwLSogXAorCXwg
dGlsZSotKiBcCisJfCB0cm9uLSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSogfCB2ODUw
ZS0qIHwgdjg1MGUxLSogfCB2ODUwZXMtKiB8IHY4NTBlMi0qIHwgdjg1MGUydjMtKiBcCisJfCB2
YXgtKiBcCisJfCB3ZTMyay0qIFwKKwl8IHg4Ni0qIHwgeDg2XzY0LSogfCB4YzE2eC0qIHwgeHBz
MTAwLSogXAorCXwgeHN0b3JteTE2LSogfCB4dGVuc2EqLSogXAorCXwgeW1wLSogXAorCXwgejhr
LSogfCB6ODAtKikKKwkJOzsKKwkjIFJlY29nbml6ZSB0aGUgYmFzaWMgQ1BVIHR5cGVzIHdpdGhv
dXQgY29tcGFueSBuYW1lLCB3aXRoIGdsb2IgbWF0Y2guCisJeHRlbnNhKikKKwkJYmFzaWNfbWFj
aGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJIyBSZWNvZ25pemUgdGhlIHZhcmlv
dXMgbWFjaGluZSBuYW1lcyBhbmQgYWxpYXNlcyB3aGljaCBzdGFuZAorCSMgZm9yIGEgQ1BVIHR5
cGUgYW5kIGEgY29tcGFueSBhbmQgc29tZXRpbWVzIGV2ZW4gYW4gT1MuCisJMzg2YnNkKQorCQli
YXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tYnNkCisJCTs7CisJM2IxIHwgNzMwMCB8
IDczMDAtYXR0IHwgYXR0LTczMDAgfCBwYzczMDAgfCBzYWZhcmkgfCB1bml4cGMpCisJCWJhc2lj
X21hY2hpbmU9bTY4MDAwLWF0dAorCQk7OworCTNiKikKKwkJYmFzaWNfbWFjaGluZT13ZTMyay1h
dHQKKwkJOzsKKwlhMjlraGlmKQorCQliYXNpY19tYWNoaW5lPWEyOWstYW1kCisJCW9zPS11ZGkK
KwkJOzsKKwlhYmFjdXMpCisJCWJhc2ljX21hY2hpbmU9YWJhY3VzLXVua25vd24KKwkJOzsKKwlh
ZG9iZTY4aykKKwkJYmFzaWNfbWFjaGluZT1tNjgwMTAtYWRvYmUKKwkJb3M9LXNjb3V0CisJCTs7
CisJYWxsaWFudCB8IGZ4ODApCisJCWJhc2ljX21hY2hpbmU9Zng4MC1hbGxpYW50CisJCTs7CisJ
YWx0b3MgfCBhbHRvczMwNjgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hbHRvcworCQk7OworCWFt
MjlrKQorCQliYXNpY19tYWNoaW5lPWEyOWstbm9uZQorCQlvcz0tYnNkCisJCTs7CisJYW1kNjQp
CisJCWJhc2ljX21hY2hpbmU9eDg2XzY0LXBjCisJCTs7CisJYW1kNjQtKikKKwkJYmFzaWNfbWFj
aGluZT14ODZfNjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJ
OzsKKwlhbWRhaGwpCisJCWJhc2ljX21hY2hpbmU9NTgwLWFtZGFobAorCQlvcz0tc3lzdgorCQk7
OworCWFtaWdhIHwgYW1pZ2EtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXVua25vd24KKwkJOzsK
KwlhbWlnYW9zIHwgYW1pZ2Fkb3MpCisJCWJhc2ljX21hY2hpbmU9bTY4ay11bmtub3duCisJCW9z
PS1hbWlnYW9zCisJCTs7CisJYW1pZ2F1bml4IHwgYW1peCkKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LXVua25vd24KKwkJb3M9LXN5c3Y0CisJCTs7CisJYXBvbGxvNjgpCisJCWJhc2ljX21hY2hpbmU9
bTY4ay1hcG9sbG8KKwkJb3M9LXN5c3YKKwkJOzsKKwlhcG9sbG82OGJzZCkKKwkJYmFzaWNfbWFj
aGluZT1tNjhrLWFwb2xsbworCQlvcz0tYnNkCisJCTs7CisJYXJvcykKKwkJYmFzaWNfbWFjaGlu
ZT1pMzg2LXBjCisJCW9zPS1hcm9zCisJCTs7CisJYXV4KQorCQliYXNpY19tYWNoaW5lPW02OGst
YXBwbGUKKwkJb3M9LWF1eAorCQk7OworCWJhbGFuY2UpCisJCWJhc2ljX21hY2hpbmU9bnMzMmst
c2VxdWVudAorCQlvcz0tZHluaXgKKwkJOzsKKwlibGFja2ZpbikKKwkJYmFzaWNfbWFjaGluZT1i
ZmluLXVua25vd24KKwkJb3M9LWxpbnV4CisJCTs7CisJYmxhY2tmaW4tKikKKwkJYmFzaWNfbWFj
aGluZT1iZmluLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9z
PS1saW51eAorCQk7OworCWJsdWVnZW5lKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWlibQor
CQlvcz0tY25rCisJCTs7CisJYzU0eC0qKQorCQliYXNpY19tYWNoaW5lPXRpYzU0eC1gZWNobyAk
YmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM1NXgtKikKKwkJYmFz
aWNfbWFjaGluZT10aWM1NXgtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8v
J2AKKwkJOzsKKwljNngtKikKKwkJYmFzaWNfbWFjaGluZT10aWM2eC1gZWNobyAkYmFzaWNfbWFj
aGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCWM5MCkKKwkJYmFzaWNfbWFjaGluZT1j
OTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY2VnY2MpCisJCWJhc2ljX21hY2hpbmU9YXJt
LXVua25vd24KKwkJb3M9LWNlZ2NjCisJCTs7CisJY29udmV4LWMxKQorCQliYXNpY19tYWNoaW5l
PWMxLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMyKQorCQliYXNpY19tYWNoaW5l
PWMyLWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMzMikKKwkJYmFzaWNfbWFjaGlu
ZT1jMzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzM0KQorCQliYXNpY19tYWNo
aW5lPWMzNC1jb252ZXgKKwkJb3M9LWJzZAorCQk7OworCWNvbnZleC1jMzgpCisJCWJhc2ljX21h
Y2hpbmU9YzM4LWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY3JheSB8IGo5MCkKKwkJYmFzaWNf
bWFjaGluZT1qOTAtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJY3JheW52KQorCQliYXNpY19t
YWNoaW5lPWNyYXludi1jcmF5CisJCW9zPS11bmljb3NtcAorCQk7OworCWNyMTYgfCBjcjE2LSop
CisJCWJhc2ljX21hY2hpbmU9Y3IxNi11bmtub3duCisJCW9zPS1lbGYKKwkJOzsKKwljcmRzIHwg
dW5vcykKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWNyZHMKKwkJOzsKKwljcmlzdjMyIHwgY3Jpc3Yz
Mi0qIHwgZXRyYXhmcyopCisJCWJhc2ljX21hY2hpbmU9Y3Jpc3YzMi1heGlzCisJCTs7CisJY3Jp
cyB8IGNyaXMtKiB8IGV0cmF4KikKKwkJYmFzaWNfbWFjaGluZT1jcmlzLWF4aXMKKwkJOzsKKwlj
cngpCisJCWJhc2ljX21hY2hpbmU9Y3J4LXVua25vd24KKwkJb3M9LWVsZgorCQk7OworCWRhMzAg
fCBkYTMwLSopCisJCWJhc2ljX21hY2hpbmU9bTY4ay1kYTMwCisJCTs7CisJZGVjc3RhdGlvbiB8
IGRlY3N0YXRpb24tMzEwMCB8IHBtYXggfCBwbWF4LSogfCBwbWluIHwgZGVjMzEwMCB8IGRlY3N0
YXRuKQorCQliYXNpY19tYWNoaW5lPW1pcHMtZGVjCisJCTs7CisJZGVjc3lzdGVtMTAqIHwgZGVj
MTAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlvcz0tdG9wczEwCisJCTs7CisJZGVj
c3lzdGVtMjAqIHwgZGVjMjAqKQorCQliYXNpY19tYWNoaW5lPXBkcDEwLWRlYworCQlvcz0tdG9w
czIwCisJCTs7CisJZGVsdGEgfCAzMzAwIHwgbW90b3JvbGEtMzMwMCB8IG1vdG9yb2xhLWRlbHRh
IFwKKwkgICAgICB8IDMzMDAtbW90b3JvbGEgfCBkZWx0YS1tb3Rvcm9sYSkKKwkJYmFzaWNfbWFj
aGluZT1tNjhrLW1vdG9yb2xhCisJCTs7CisJZGVsdGE4OCkKKwkJYmFzaWNfbWFjaGluZT1tODhr
LW1vdG9yb2xhCisJCW9zPS1zeXN2MworCQk7OworCWRpY29zKQorCQliYXNpY19tYWNoaW5lPWk2
ODYtcGMKKwkJb3M9LWRpY29zCisJCTs7CisJZGpncHApCisJCWJhc2ljX21hY2hpbmU9aTU4Ni1w
YworCQlvcz0tbXNkb3NkamdwcAorCQk7OworCWRweDIwIHwgZHB4MjAtKikKKwkJYmFzaWNfbWFj
aGluZT1yczYwMDAtYnVsbAorCQlvcz0tYm9zeAorCQk7OworCWRweDIqIHwgZHB4MiotYnVsbCkK
KwkJYmFzaWNfbWFjaGluZT1tNjhrLWJ1bGwKKwkJb3M9LXN5c3YzCisJCTs7CisJZWJtb24yOWsp
CisJCWJhc2ljX21hY2hpbmU9YTI5ay1hbWQKKwkJb3M9LWVibW9uCisJCTs7CisJZWx4c2kpCisJ
CWJhc2ljX21hY2hpbmU9ZWx4c2ktZWx4c2kKKwkJb3M9LWJzZAorCQk7OworCWVuY29yZSB8IHVt
YXggfCBtbWF4KQorCQliYXNpY19tYWNoaW5lPW5zMzJrLWVuY29yZQorCQk7OworCWVzMTgwMCB8
IE9TRTY4ayB8IG9zZTY4ayB8IG9zZSB8IE9TRSkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWVyaWNz
c29uCisJCW9zPS1vc2UKKwkJOzsKKwlmeDI4MDApCisJCWJhc2ljX21hY2hpbmU9aTg2MC1hbGxp
YW50CisJCTs7CisJZ2VuaXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstbnMKKwkJOzsKKwlnbWlj
cm8pCisJCWJhc2ljX21hY2hpbmU9dHJvbi1nbWljcm8KKwkJb3M9LXN5c3YKKwkJOzsKKwlnbzMy
KQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWdvMzIKKwkJOzsKKwloMzA1MHIqIHwg
aGl1eCopCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRhY2hpCisJCW9zPS1oaXV4d2UyCisJ
CTs7CisJaDgzMDBobXMpCisJCWJhc2ljX21hY2hpbmU9aDgzMDAtaGl0YWNoaQorCQlvcz0taG1z
CisJCTs7CisJaDgzMDB4cmF5KQorCQliYXNpY19tYWNoaW5lPWg4MzAwLWhpdGFjaGkKKwkJb3M9
LXhyYXkKKwkJOzsKKwloODUwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODUwMC1oaXRhY2hpCisJ
CW9zPS1obXMKKwkJOzsKKwloYXJyaXMpCisJCWJhc2ljX21hY2hpbmU9bTg4ay1oYXJyaXMKKwkJ
b3M9LXN5c3YzCisJCTs7CisJaHAzMDAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhwCisJCTs7
CisJaHAzMDBic2QpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlvcz0tYnNkCisJCTs7CisJ
aHAzMDBocHV4KQorCQliYXNpY19tYWNoaW5lPW02OGstaHAKKwkJb3M9LWhwdXgKKwkJOzsKKwlo
cDNrOVswLTldWzAtOV0gfCBocDlbMC05XVswLTldKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjAt
aHAKKwkJOzsKKwlocDlrMlswLTldWzAtOV0gfCBocDlrMzFbMC05XSkKKwkJYmFzaWNfbWFjaGlu
ZT1tNjgwMDAtaHAKKwkJOzsKKwlocDlrM1syLTldWzAtOV0pCisJCWJhc2ljX21hY2hpbmU9bTY4
ay1ocAorCQk7OworCWhwOWs2WzAtOV1bMC05XSB8IGhwNlswLTldWzAtOV0pCisJCWJhc2ljX21h
Y2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwOWs3WzAtNzldWzAtOV0gfCBocDdbMC03OV1bMC05
XSkKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJaHA5azc4WzAtOV0gfCBocDc4
WzAtOV0pCisJCSMgRklYTUU6IHJlYWxseSBocHBhMi4wLWhwCisJCWJhc2ljX21hY2hpbmU9aHBw
YTEuMS1ocAorCQk7OworCWhwOWs4WzY3XTEgfCBocDhbNjddMSB8IGhwOWs4MFsyNF0gfCBocDgw
WzI0XSB8IGhwOWs4Wzc4XTkgfCBocDhbNzhdOSB8IGhwOWs4OTMgfCBocDg5MykKKwkJIyBGSVhN
RTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCTs7CisJ
aHA5azhbMC05XVsxMzY3OV0gfCBocDhbMC05XVsxMzY3OV0pCisJCWJhc2ljX21hY2hpbmU9aHBw
YTEuMS1ocAorCQk7OworCWhwOWs4WzAtOV1bMC05XSB8IGhwOFswLTldWzAtOV0pCisJCWJhc2lj
X21hY2hpbmU9aHBwYTEuMC1ocAorCQk7OworCWhwcGEtbmV4dCkKKwkJb3M9LW5leHRzdGVwMwor
CQk7OworCWhwcGFvc2YpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0tb3NmCisJ
CTs7CisJaHBwcm8pCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1ocAorCQlvcz0tcHJvZWxmCisJ
CTs7CisJaTM3MC1pYm0qIHwgaWJtKikKKwkJYmFzaWNfbWFjaGluZT1pMzcwLWlibQorCQk7Owor
IyBJJ20gbm90IHN1cmUgd2hhdCAiU3lzdjMyIiBtZWFucy4gIFNob3VsZCB0aGlzIGJlIHN5c3Yz
LjI/CisJaSo4NnYzMikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni4q
Lzg2LXBjLydgCisJCW9zPS1zeXN2MzIKKwkJOzsKKwlpKjg2djQqKQorCQliYXNpY19tYWNoaW5l
PWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXN5c3Y0CisJCTs7CisJ
aSo4NnYpCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8n
YAorCQlvcz0tc3lzdgorCQk7OworCWkqODZzb2wyKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICQx
IHwgc2VkIC1lICdzLzg2LiovODYtcGMvJ2AKKwkJb3M9LXNvbGFyaXMyCisJCTs7CisJaTM4Nm1h
Y2gpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1tYWNoCisJCW9zPS1tYWNoCisJCTs7CisJaTM4Ni12
c3RhIHwgdnN0YSkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJb3M9LXZzdGEKKwkJ
OzsKKwlpcmlzIHwgaXJpczRkKQorCQliYXNpY19tYWNoaW5lPW1pcHMtc2dpCisJCWNhc2UgJG9z
IGluCisJCSAgICAtaXJpeCopCisJCQk7OworCQkgICAgKikKKwkJCW9zPS1pcml4NAorCQkJOzsK
KwkJZXNhYworCQk7OworCWlzaTY4IHwgaXNpKQorCQliYXNpY19tYWNoaW5lPW02OGstaXNpCisJ
CW9zPS1zeXN2CisJCTs7CisJbTY4a25vbW11KQorCQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93
bgorCQlvcz0tbGludXgKKwkJOzsKKwltNjhrbm9tbXUtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhr
LWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCW9zPS1saW51eAor
CQk7OworCW04OGstb21yb24qKQorCQliYXNpY19tYWNoaW5lPW04OGstb21yb24KKwkJOzsKKwlt
YWdudW0gfCBtMzIzMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLW1pcHMKKwkJb3M9LXN5c3YKKwkJ
OzsKKwltZXJsaW4pCisJCWJhc2ljX21hY2hpbmU9bnMzMmstdXRlaworCQlvcz0tc3lzdgorCQk7
OworCW1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9bWljcm9ibGF6ZS14aWxpbngKKwkJOzsK
KwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LW1pbmd3MzIKKwkJOzsK
KwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJtLXVua25vd24KKwkJb3M9LW1pbmd3MzJj
ZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtY29udmVyZ2VudAor
CQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlOVCB8ICpNaU5UWzAtOV0qKQorCQliYXNp
Y19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQKKwkJOzsKKwltaXBzMyotKikKKwkJYmFz
aWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAtZSAncy9taXBzMy9taXBzNjQv
J2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2ljX21hY2hpbmUg
fCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25vd24KKwkJOzsKKwltb25pdG9yKQorCQli
YXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJbW9ycGhvcykKKwkJ
YmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJb3M9LW1vcnBob3MKKwkJOzsKKwltc2Rv
cykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc2RvcworCQk7OworCW1zMS0qKQor
CQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkIC1lICdzL21zMS0vbXQt
LydgCisJCTs7CisJbXN5cykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc3lzCisJ
CTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCW9zPS1tdnMKKwkJOzsKKwlu
YWNsKQorCQliYXNpY19tYWNoaW5lPWxlMzItdW5rbm93bgorCQlvcz0tbmFjbAorCQk7OworCW5j
cjMwMDApCisJCWJhc2ljX21hY2hpbmU9aTQ4Ni1uY3IKKwkJb3M9LXN5c3Y0CisJCTs7CisJbmV0
YnNkMzg2KQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tbmV0YnNkCisJCTs7
CisJbmV0d2luZGVyKQorCQliYXNpY19tYWNoaW5lPWFybXY0bC1yZWJlbAorCQlvcz0tbGludXgK
KwkJOzsKKwluZXdzIHwgbmV3czcwMCB8IG5ld3M4MDAgfCBuZXdzOTAwKQorCQliYXNpY19tYWNo
aW5lPW02OGstc29ueQorCQlvcz0tbmV3c29zCisJCTs7CisJbmV3czEwMDApCisJCWJhc2ljX21h
Y2hpbmU9bTY4MDMwLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5ld3MtMzYwMCB8IHJpc2Mt
bmV3cykKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5l
Y3Y3MCkKKwkJYmFzaWNfbWFjaGluZT12NzAtbmVjCisJCW9zPS1zeXN2CisJCTs7CisJbmV4dCB8
IG0qLW5leHQgKQorCQliYXNpY19tYWNoaW5lPW02OGstbmV4dAorCQljYXNlICRvcyBpbgorCQkg
ICAgLW5leHRzdGVwKiApCisJCQk7OworCQkgICAgLW5zMiopCisJCSAgICAgIG9zPS1uZXh0c3Rl
cDIKKwkJCTs7CisJCSAgICAqKQorCQkgICAgICBvcz0tbmV4dHN0ZXAzCisJCQk7OworCQllc2Fj
CisJCTs7CisJbmgzMDAwKQorCQliYXNpY19tYWNoaW5lPW02OGstaGFycmlzCisJCW9zPS1jeHV4
CisJCTs7CisJbmhbNDVdMDAwKQorCQliYXNpY19tYWNoaW5lPW04OGstaGFycmlzCisJCW9zPS1j
eHV4CisJCTs7CisJbmluZHk5NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAorCQlvcz0t
bmluZHkKKwkJOzsKKwltb245NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC1pbnRlbAorCQlvcz0t
bW9uOTYwCisJCTs7CisJbm9uc3RvcHV4KQorCQliYXNpY19tYWNoaW5lPW1pcHMtY29tcGFxCisJ
CW9zPS1ub25zdG9wdXgKKwkJOzsKKwlucDEpCisJCWJhc2ljX21hY2hpbmU9bnAxLWdvdWxkCisJ
CTs7CisJbmVvLXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uZW8tdGFuZGVtCisJCTs7CisJbnNl
LXRhbmRlbSkKKwkJYmFzaWNfbWFjaGluZT1uc2UtdGFuZGVtCisJCTs7CisJbnNyLXRhbmRlbSkK
KwkJYmFzaWNfbWFjaGluZT1uc3ItdGFuZGVtCisJCTs7CisJb3A1MG4tKiB8IG9wNjBjLSopCisJ
CWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJb3M9LXByb2VsZgorCQk7OworCW9wZW5yaXNj
IHwgb3BlbnJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1vcjMyLXVua25vd24KKwkJOzsKKwlvczQw
MCkKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWlibQorCQlvcz0tb3M0MDAKKwkJOzsKKwlPU0U2
ODAwMCB8IG9zZTY4MDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1lcmljc3NvbgorCQlvcz0t
b3NlCisJCTs7CisJb3M2OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ub25lCisJCW9zPS1vczY4
aworCQk7OworCXBhLWhpdGFjaGkpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1oaXRhY2hpCisJ
CW9zPS1oaXV4d2UyCisJCTs7CisJcGFyYWdvbikKKwkJYmFzaWNfbWFjaGluZT1pODYwLWludGVs
CisJCW9zPS1vc2YKKwkJOzsKKwlwYXJpc2MpCisJCWJhc2ljX21hY2hpbmU9aHBwYS11bmtub3du
CisJCW9zPS1saW51eAorCQk7OworCXBhcmlzYy0qKQorCQliYXNpY19tYWNoaW5lPWhwcGEtYGVj
aG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4CisJCTs7
CisJcGJkKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXR0aQorCQk7OworCXBiYikKKwkJYmFzaWNf
bWFjaGluZT1tNjhrLXR0aQorCQk7OworCXBjNTMyIHwgcGM1MzItKikKKwkJYmFzaWNfbWFjaGlu
ZT1uczMyay1wYzUzMgorCQk7OworCXBjOTgpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1wYworCQk7
OworCXBjOTgtKikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LWBlY2hvICRiYXNpY19tYWNoaW5lIHwg
c2VkICdzL15bXi1dKi0vLydgCisJCTs7CisJcGVudGl1bSB8IHA1IHwgazUgfCBrNiB8IG5leGdl
biB8IHZpYWMzKQorCQliYXNpY19tYWNoaW5lPWk1ODYtcGMKKwkJOzsKKwlwZW50aXVtcHJvIHwg
cDYgfCA2eDg2IHwgYXRobG9uIHwgYXRobG9uXyopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1wYwor
CQk7OworCXBlbnRpdW1paSB8IHBlbnRpdW0yIHwgcGVudGl1bWlpaSB8IHBlbnRpdW0zKQorCQli
YXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlwZW50aXVtNCkKKwkJYmFzaWNfbWFjaGluZT1p
Nzg2LXBjCisJCTs7CisJcGVudGl1bS0qIHwgcDUtKiB8IGs1LSogfCBrNi0qIHwgbmV4Z2VuLSog
fCB2aWFjMy0qKQorCQliYXNpY19tYWNoaW5lPWk1ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBz
ZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwZW50aXVtcHJvLSogfCBwNi0qIHwgNng4Ni0qIHwg
YXRobG9uLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNl
ZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW1paS0qIHwgcGVudGl1bTItKiB8IHBlbnRp
dW1paWktKiB8IHBlbnRpdW0zLSopCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1gZWNobyAkYmFzaWNf
bWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBlbnRpdW00LSopCisJCWJhc2lj
X21hY2hpbmU9aTc4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAor
CQk7OworCXBuKQorCQliYXNpY19tYWNoaW5lPXBuLWdvdWxkCisJCTs7CisJcG93ZXIpCWJhc2lj
X21hY2hpbmU9cG93ZXItaWJtCisJCTs7CisJcHBjIHwgcHBjYmUpCWJhc2ljX21hY2hpbmU9cG93
ZXJwYy11bmtub3duCisJCTs7CisJcHBjLSogfCBwcGNiZS0qKQorCQliYXNpY19tYWNoaW5lPXBv
d2VycGMtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlw
cGNsZSB8IHBvd2VycGNsaXR0bGUgfCBwcGMtbGUgfCBwb3dlcnBjLWxpdHRsZSkKKwkJYmFzaWNf
bWFjaGluZT1wb3dlcnBjbGUtdW5rbm93bgorCQk7OworCXBwY2xlLSogfCBwb3dlcnBjbGl0dGxl
LSopCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2Vk
ICdzL15bXi1dKi0vLydgCisJCTs7CisJcHBjNjQpCWJhc2ljX21hY2hpbmU9cG93ZXJwYzY0LXVu
a25vd24KKwkJOzsKKwlwcGM2NC0qKSBiYXNpY19tYWNoaW5lPXBvd2VycGM2NC1gZWNobyAkYmFz
aWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0bGUgfCBwb3dlcnBj
NjRsaXR0bGUgfCBwcGM2NC1sZSB8IHBvd2VycGM2NC1saXR0bGUpCisJCWJhc2ljX21hY2hpbmU9
cG93ZXJwYzY0bGUtdW5rbm93bgorCQk7OworCXBwYzY0bGUtKiB8IHBvd2VycGM2NGxpdHRsZS0q
KQorCQliYXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2Vk
ICdzL15bXi1dKi0vLydgCisJCTs7CisJcHMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtaWJtCisJ
CTs7CisJcHczMikKKwkJYmFzaWNfbWFjaGluZT1pNTg2LXVua25vd24KKwkJb3M9LXB3MzIKKwkJ
OzsKKwlyZG9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LXJkb3MKKwkJOzsKKwly
b202OGspCisJCWJhc2ljX21hY2hpbmU9bTY4ay1yb202OGsKKwkJb3M9LWNvZmYKKwkJOzsKKwly
bVs0Nl0wMCkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNpZW1lbnMKKwkJOzsKKwlydHBjIHwgcnRw
Yy0qKQorCQliYXNpY19tYWNoaW5lPXJvbXAtaWJtCisJCTs7CisJczM5MCB8IHMzOTAtKikKKwkJ
YmFzaWNfbWFjaGluZT1zMzkwLWlibQorCQk7OworCXMzOTB4IHwgczM5MHgtKikKKwkJYmFzaWNf
bWFjaGluZT1zMzkweC1pYm0KKwkJOzsKKwlzYTI5MjAwKQorCQliYXNpY19tYWNoaW5lPWEyOWst
YW1kCisJCW9zPS11ZGkKKwkJOzsKKwlzYjEpCisJCWJhc2ljX21hY2hpbmU9bWlwc2lzYTY0c2Ix
LXVua25vd24KKwkJOzsKKwlzYjFlbCkKKwkJYmFzaWNfbWFjaGluZT1taXBzaXNhNjRzYjFlbC11
bmtub3duCisJCTs7CisJc2RlKQorCQliYXNpY19tYWNoaW5lPW1pcHNpc2EzMi1zZGUKKwkJb3M9
LWVsZgorCQk7OworCXNlaSkKKwkJYmFzaWNfbWFjaGluZT1taXBzLXNlaQorCQlvcz0tc2VpdXgK
KwkJOzsKKwlzZXF1ZW50KQorCQliYXNpY19tYWNoaW5lPWkzODYtc2VxdWVudAorCQk7OworCXNo
KQorCQliYXNpY19tYWNoaW5lPXNoLWhpdGFjaGkKKwkJb3M9LWhtcworCQk7OworCXNoNWVsKQor
CQliYXNpY19tYWNoaW5lPXNoNWxlLXVua25vd24KKwkJOzsKKwlzaDY0KQorCQliYXNpY19tYWNo
aW5lPXNoNjQtdW5rbm93bgorCQk7OworCXNwYXJjbGl0ZS13cnMgfCBzaW1zby13cnMpCisJCWJh
c2ljX21hY2hpbmU9c3BhcmNsaXRlLXdycworCQlvcz0tdnh3b3JrcworCQk7OworCXNwczcpCisJ
CWJhc2ljX21hY2hpbmU9bTY4ay1idWxsCisJCW9zPS1zeXN2MgorCQk7OworCXNwdXIpCisJCWJh
c2ljX21hY2hpbmU9c3B1ci11bmtub3duCisJCTs7CisJc3QyMDAwKQorCQliYXNpY19tYWNoaW5l
PW02OGstdGFuZGVtCisJCTs7CisJc3RyYXR1cykKKwkJYmFzaWNfbWFjaGluZT1pODYwLXN0cmF0
dXMKKwkJb3M9LXN5c3Y0CisJCTs7CisJc3Ryb25nYXJtLSogfCB0aHVtYi0qKQorCQliYXNpY19t
YWNoaW5lPWFybS1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7
OworCXN1bjIpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJvczMpCisJ
CWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuMm9zNCkK
KwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW4zb3Mz
KQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlzdW4zb3M0
KQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW40b3Mz
KQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuNG9z
NCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7OworCXN1bjRz
b2wyKQorCQliYXNpY19tYWNoaW5lPXNwYXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlz
dW4zIHwgc3VuMy0qKQorCQliYXNpY19tYWNoaW5lPW02OGstc3VuCisJCTs7CisJc3VuNCkKKwkJ
YmFzaWNfbWFjaGluZT1zcGFyYy1zdW4KKwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwgcm9hZHJ1
bm5lcikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFzaWNfbWFj
aGluZT1zdjEtY3JheQorCQlvcz0tdW5pY29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJhc2ljX21h
Y2hpbmU9aTM4Ni1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCXQzZSkKKwkJYmFzaWNfbWFj
aGluZT1hbHBoYWV2NS1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJhc2ljX21h
Y2hpbmU9dDkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworCXRpbGUqKQorCQliYXNpY19tYWNo
aW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9LWxpbnV4LWdudQorCQk7OworCXR4Mzkp
CisJCWJhc2ljX21hY2hpbmU9bWlwc3R4MzktdW5rbm93bgorCQk7OworCXR4MzllbCkKKwkJYmFz
aWNfbWFjaGluZT1taXBzdHgzOWVsLXVua25vd24KKwkJOzsKKwl0b2FkMSkKKwkJYmFzaWNfbWFj
aGluZT1wZHAxMC14a2wKKwkJb3M9LXRvcHMyMAorCQk7OworCXRvd2VyIHwgdG93ZXItMzIpCisJ
CWJhc2ljX21hY2hpbmU9bTY4ay1uY3IKKwkJOzsKKwl0cGYpCisJCWJhc2ljX21hY2hpbmU9czM5
MHgtaWJtCisJCW9zPS10cGYKKwkJOzsKKwl1ZGkyOWspCisJCWJhc2ljX21hY2hpbmU9YTI5ay1h
bWQKKwkJb3M9LXVkaQorCQk7OworCXVsdHJhMykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLW55dQor
CQlvcz0tc3ltMQorCQk7OworCXY4MTAgfCBuZWN2ODEwKQorCQliYXNpY19tYWNoaW5lPXY4MTAt
bmVjCisJCW9zPS1ub25lCisJCTs7CisJdmF4dikKKwkJYmFzaWNfbWFjaGluZT12YXgtZGVjCisJ
CW9zPS1zeXN2CisJCTs7CisJdm1zKQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJb3M9LXZt
cworCQk7OworCXZwcCp8dnh8dngtKikKKwkJYmFzaWNfbWFjaGluZT1mMzAxLWZ1aml0c3UKKwkJ
OzsKKwl2eHdvcmtzOTYwKQorCQliYXNpY19tYWNoaW5lPWk5NjAtd3JzCisJCW9zPS12eHdvcmtz
CisJCTs7CisJdnh3b3JrczY4KQorCQliYXNpY19tYWNoaW5lPW02OGstd3JzCisJCW9zPS12eHdv
cmtzCisJCTs7CisJdnh3b3JrczI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLXdycworCQlvcz0t
dnh3b3JrcworCQk7OworCXc2NSopCisJCWJhc2ljX21hY2hpbmU9dzY1LXdkYworCQlvcz0tbm9u
ZQorCQk7OworCXc4OWstKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLXdpbmJvbmQKKwkJb3M9
LXByb2VsZgorCQk7OworCXhib3gpCisJCWJhc2ljX21hY2hpbmU9aTY4Ni1wYworCQlvcz0tbWlu
Z3czMgorCQk7OworCXhwcyB8IHhwczEwMCkKKwkJYmFzaWNfbWFjaGluZT14cHMxMDAtaG9uZXl3
ZWxsCisJCTs7CisJeHNjYWxlLSogfCB4c2NhbGVlW2JsXS0qKQorCQliYXNpY19tYWNoaW5lPWBl
Y2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL154c2NhbGUvYXJtLydgCisJCTs7CisJeW1wKQor
CQliYXNpY19tYWNoaW5lPXltcC1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwl6OGstKi1jb2Zm
KQorCQliYXNpY19tYWNoaW5lPXo4ay11bmtub3duCisJCW9zPS1zaW0KKwkJOzsKKwl6ODAtKi1j
b2ZmKQorCQliYXNpY19tYWNoaW5lPXo4MC11bmtub3duCisJCW9zPS1zaW0KKwkJOzsKKwlub25l
KQorCQliYXNpY19tYWNoaW5lPW5vbmUtbm9uZQorCQlvcz0tbm9uZQorCQk7OworCisjIEhlcmUg
d2UgaGFuZGxlIHRoZSBkZWZhdWx0IG1hbnVmYWN0dXJlciBvZiBjZXJ0YWluIENQVSB0eXBlcy4g
IEl0IGlzIGluCisjIHNvbWUgY2FzZXMgdGhlIG9ubHkgbWFudWZhY3R1cmVyLCBpbiBvdGhlcnMs
IGl0IGlzIHRoZSBtb3N0IHBvcHVsYXIuCisJdzg5aykKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4x
LXdpbmJvbmQKKwkJOzsKKwlvcDUwbikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLW9raQorCQk7
OworCW9wNjBjKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtb2tpCisJCTs7CisJcm9tcCkKKwkJ
YmFzaWNfbWFjaGluZT1yb21wLWlibQorCQk7OworCW1taXgpCisJCWJhc2ljX21hY2hpbmU9bW1p
eC1rbnV0aAorCQk7OworCXJzNjAwMCkKKwkJYmFzaWNfbWFjaGluZT1yczYwMDAtaWJtCisJCTs7
CisJdmF4KQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJOzsKKwlwZHAxMCkKKwkJIyB0aGVy
ZSBhcmUgbWFueSBjbG9uZXMsIHNvIERFQyBpcyBub3QgYSBzYWZlIGJldAorCQliYXNpY19tYWNo
aW5lPXBkcDEwLXVua25vd24KKwkJOzsKKwlwZHAxMSkKKwkJYmFzaWNfbWFjaGluZT1wZHAxMS1k
ZWMKKwkJOzsKKwl3ZTMyaykKKwkJYmFzaWNfbWFjaGluZT13ZTMyay1hdHQKKwkJOzsKKwlzaFsx
MjM0XSB8IHNoWzI0XWEgfCBzaFsyNF1hZWIgfCBzaFszNF1lYiB8IHNoWzEyMzRdbGUgfCBzaFsy
M11lbGUpCisJCWJhc2ljX21hY2hpbmU9c2gtdW5rbm93bgorCQk7OworCXNwYXJjIHwgc3BhcmN2
OCB8IHNwYXJjdjkgfCBzcGFyY3Y5YiB8IHNwYXJjdjl2KQorCQliYXNpY19tYWNoaW5lPXNwYXJj
LXN1bgorCQk7OworCWN5ZHJhKQorCQliYXNpY19tYWNoaW5lPWN5ZHJhLWN5ZHJvbWUKKwkJOzsK
KwlvcmlvbikKKwkJYmFzaWNfbWFjaGluZT1vcmlvbi1oaWdobGV2ZWwKKwkJOzsKKwlvcmlvbjEw
NSkKKwkJYmFzaWNfbWFjaGluZT1jbGlwcGVyLWhpZ2hsZXZlbAorCQk7OworCW1hYyB8IG1wdyB8
IG1hYy1tcHcpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQk7OworCXBtYWMgfCBwbWFj
LW1wdykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLWFwcGxlCisJCTs7CisJKi11bmtub3duKQor
CQkjIE1ha2Ugc3VyZSB0byBtYXRjaCBhbiBhbHJlYWR5LWNhbm9uaWNhbGl6ZWQgbWFjaGluZSBu
YW1lLgorCQk7OworCSopCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFcJzogbWFj
aGluZSBcYCRiYXNpY19tYWNoaW5lXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJ
OzsKK2VzYWMKKworIyBIZXJlIHdlIGNhbm9uaWNhbGl6ZSBjZXJ0YWluIGFsaWFzZXMgZm9yIG1h
bnVmYWN0dXJlcnMuCitjYXNlICRiYXNpY19tYWNoaW5lIGluCisJKi1kaWdpdGFsKikKKwkJYmFz
aWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9kaWdpdGFsLiovZGVjLydg
CisJCTs7CisJKi1jb21tb2RvcmUqKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNo
aW5lIHwgc2VkICdzL2NvbW1vZG9yZS4qL2NibS8nYAorCQk7OworCSopCisJCTs7Citlc2FjCisK
KyMgRGVjb2RlIG1hbnVmYWN0dXJlci1zcGVjaWZpYyBhbGlhc2VzIGZvciBjZXJ0YWluIG9wZXJh
dGluZyBzeXN0ZW1zLgorCitpZiBbIHgiJG9zIiAhPSB4IiIgXQordGhlbgorY2FzZSAkb3MgaW4K
KwkjIEZpcnN0IG1hdGNoIHNvbWUgc3lzdGVtIHR5cGUgYWxpYXNlcworCSMgdGhhdCBtaWdodCBn
ZXQgY29uZnVzZWQgd2l0aCB2YWxpZCBzeXN0ZW0gdHlwZXMuCisJIyAtc29sYXJpcyogaXMgYSBi
YXNpYyBzeXN0ZW0gdHlwZSwgd2l0aCB0aGlzIG9uZSBleGNlcHRpb24uCisJLWF1cm9yYXV4KQor
CQlvcz0tYXVyb3JhdXgKKwkJOzsKKwktc29sYXJpczEgfCAtc29sYXJpczEuKikKKwkJb3M9YGVj
aG8gJG9zIHwgc2VkIC1lICdzfHNvbGFyaXMxfHN1bm9zNHwnYAorCQk7OworCS1zb2xhcmlzKQor
CQlvcz0tc29sYXJpczIKKwkJOzsKKwktc3ZyNCopCisJCW9zPS1zeXN2NAorCQk7OworCS11bml4
d2FyZSopCisJCW9zPS1zeXN2NC4ydXcKKwkJOzsKKwktZ251L2xpbnV4KikKKwkJb3M9YGVjaG8g
JG9zIHwgc2VkIC1lICdzfGdudS9saW51eHxsaW51eC1nbnV8J2AKKwkJOzsKKwkjIEZpcnN0IGFj
Y2VwdCB0aGUgYmFzaWMgc3lzdGVtIHR5cGVzLgorCSMgVGhlIHBvcnRhYmxlIHN5c3RlbXMgY29t
ZXMgZmlyc3QuCisJIyBFYWNoIGFsdGVybmF0aXZlIE1VU1QgRU5EIElOIEEgKiwgdG8gbWF0Y2gg
YSB2ZXJzaW9uIG51bWJlci4KKwkjIC1zeXN2KiBpcyBub3QgaGVyZSBiZWNhdXNlIGl0IGNvbWVz
IGxhdGVyLCBhZnRlciBzeXN2cjQuCisJLWdudSogfCAtYnNkKiB8IC1tYWNoKiB8IC1taW5peCog
fCAtZ2VuaXgqIHwgLXVsdHJpeCogfCAtaXJpeCogXAorCSAgICAgIHwgLSp2bXMqIHwgLXNjbyog
fCAtZXNpeCogfCAtaXNjKiB8IC1haXgqIHwgLWNuayogfCAtc3Vub3MgfCAtc3Vub3NbMzRdKlwK
KwkgICAgICB8IC1ocHV4KiB8IC11bm9zKiB8IC1vc2YqIHwgLWx1bmEqIHwgLWRndXgqIHwgLWF1
cm9yYXV4KiB8IC1zb2xhcmlzKiBcCisJICAgICAgfCAtc3ltKiB8IC1rb3BlbnNvbGFyaXMqIFwK
KwkgICAgICB8IC1hbWlnYW9zKiB8IC1hbWlnYWRvcyogfCAtbXNkb3MqIHwgLW5ld3NvcyogfCAt
dW5pY29zKiB8IC1hb2YqIFwKKwkgICAgICB8IC1hb3MqIHwgLWFyb3MqIFwKKwkgICAgICB8IC1u
aW5keSogfCAtdnhzaW0qIHwgLXZ4d29ya3MqIHwgLWVibW9uKiB8IC1obXMqIHwgLW12cyogXAor
CSAgICAgIHwgLWNsaXgqIHwgLXJpc2NvcyogfCAtdW5pcGx1cyogfCAtaXJpcyogfCAtcnR1KiB8
IC14ZW5peCogXAorCSAgICAgIHwgLWhpdXgqIHwgLTM4NmJzZCogfCAta25ldGJzZCogfCAtbWly
YnNkKiB8IC1uZXRic2QqIFwKKwkgICAgICB8IC1vcGVuYnNkKiB8IC1zb2xpZGJzZCogXAorCSAg
ICAgIHwgLWVra29ic2QqIHwgLWtmcmVlYnNkKiB8IC1mcmVlYnNkKiB8IC1yaXNjaXgqIHwgLWx5
bnhvcyogXAorCSAgICAgIHwgLWJvc3gqIHwgLW5leHRzdGVwKiB8IC1jeHV4KiB8IC1hb3V0KiB8
IC1lbGYqIHwgLW9hYmkqIFwKKwkgICAgICB8IC1wdHgqIHwgLWNvZmYqIHwgLWVjb2ZmKiB8IC13
aW5udCogfCAtZG9tYWluKiB8IC12c3RhKiBcCisJICAgICAgfCAtdWRpKiB8IC1lYWJpKiB8IC1s
aXRlcyogfCAtaWVlZSogfCAtZ28zMiogfCAtYXV4KiBcCisJICAgICAgfCAtY2hvcnVzb3MqIHwg
LWNob3J1c3JkYiogfCAtY2VnY2MqIFwKKwkgICAgICB8IC1jeWd3aW4qIHwgLW1zeXMqIHwgLXBl
KiB8IC1wc29zKiB8IC1tb3NzKiB8IC1wcm9lbGYqIHwgLXJ0ZW1zKiBcCisJICAgICAgfCAtbWlu
Z3czMiogfCAtbGludXgtZ251KiB8IC1saW51eC1hbmRyb2lkKiBcCisJICAgICAgfCAtbGludXgt
bmV3bGliKiB8IC1saW51eC11Y2xpYmMqIFwKKwkgICAgICB8IC11eHB2KiB8IC1iZW9zKiB8IC1t
cGVpeCogfCAtdWRrKiBcCisJICAgICAgfCAtaW50ZXJpeCogfCAtdXdpbiogfCAtbWtzKiB8IC1y
aGFwc29keSogfCAtZGFyd2luKiB8IC1vcGVuZWQqIFwKKwkgICAgICB8IC1vcGVuc3RlcCogfCAt
b3NraXQqIHwgLWNvbml4KiB8IC1wdzMyKiB8IC1ub25zdG9wdXgqIFwKKwkgICAgICB8IC1zdG9y
bS1jaGFvcyogfCAtdG9wczEwKiB8IC10ZW5leCogfCAtdG9wczIwKiB8IC1pdHMqIFwKKwkgICAg
ICB8IC1vczIqIHwgLXZvcyogfCAtcGFsbW9zKiB8IC11Y2xpbnV4KiB8IC1udWNsZXVzKiBcCisJ
ICAgICAgfCAtbW9ycGhvcyogfCAtc3VwZXJ1eCogfCAtcnRtayogfCAtcnRtay1ub3ZhKiB8IC13
aW5kaXNzKiBcCisJICAgICAgfCAtcG93ZXJtYXgqIHwgLWRuaXgqIHwgLW54NiB8IC1ueDcgfCAt
c2VpKiB8IC1kcmFnb25mbHkqIFwKKwkgICAgICB8IC1za3lvcyogfCAtaGFpa3UqIHwgLXJkb3Mq
IHwgLXRvcHBlcnMqIHwgLWRyb3BzKiB8IC1lcyopCisJIyBSZW1lbWJlciwgZWFjaCBhbHRlcm5h
dGl2ZSBNVVNUIEVORCBJTiAqLCB0byBtYXRjaCBhIHZlcnNpb24gbnVtYmVyLgorCQk7OworCS1x
bngqKQorCQljYXNlICRiYXNpY19tYWNoaW5lIGluCisJCSAgICB4ODYtKiB8IGkqODYtKikKKwkJ
CTs7CisJCSAgICAqKQorCQkJb3M9LW50byRvcworCQkJOzsKKwkJZXNhYworCQk7OworCS1udG8t
cW54KikKKwkJOzsKKwktbnRvKikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfG50b3xudG8t
cW54fCdgCisJCTs7CisJLXNpbSB8IC1lczE4MDAqIHwgLWhtcyogfCAteHJheSB8IC1vczY4ayog
fCAtbm9uZSogfCAtdjg4ciogXAorCSAgICAgIHwgLXdpbmRvd3MqIHwgLW9zeCB8IC1hYnVnIHwg
LW5ldHdhcmUqIHwgLW9zOSogfCAtYmVvcyogfCAtaGFpa3UqIFwKKwkgICAgICB8IC1tYWNvcyog
fCAtbXB3KiB8IC1tYWdpYyogfCAtbW1peHdhcmUqIHwgLW1vbjk2MCogfCAtbG5ld3MqKQorCQk7
OworCS1tYWMqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bWFjfG1hY29zfCdgCisJCTs7
CisJLWxpbnV4LWRpZXRsaWJjKQorCQlvcz0tbGludXgtZGlldGxpYmMKKwkJOzsKKwktbGludXgq
KQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bGludXh8bGludXgtZ251fCdgCisJCTs7CisJ
LXN1bm9zNSopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzdW5vczV8c29sYXJpczJ8J2AK
KwkJOzsKKwktc3Vub3M2KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHN1bm9zNnxzb2xh
cmlzM3wnYAorCQk7OworCS1vcGVuZWQqKQorCQlvcz0tb3BlbmVkaXRpb24KKwkJOzsKKwktb3M0
MDAqKQorCQlvcz0tb3M0MDAKKwkJOzsKKwktd2luY2UqKQorCQlvcz0td2luY2UKKwkJOzsKKwkt
b3Nmcm9zZSopCisJCW9zPS1vc2Zyb3NlCisJCTs7CisJLW9zZiopCisJCW9zPS1vc2YKKwkJOzsK
KwktdXRlayopCisJCW9zPS1ic2QKKwkJOzsKKwktZHluaXgqKQorCQlvcz0tYnNkCisJCTs7CisJ
LWFjaXMqKQorCQlvcz0tYW9zCisJCTs7CisJLWF0aGVvcyopCisJCW9zPS1hdGhlb3MKKwkJOzsK
Kwktc3lsbGFibGUqKQorCQlvcz0tc3lsbGFibGUKKwkJOzsKKwktMzg2YnNkKQorCQlvcz0tYnNk
CisJCTs7CisJLWN0aXgqIHwgLXV0cyopCisJCW9zPS1zeXN2CisJCTs7CisJLW5vdmEqKQorCQlv
cz0tcnRtay1ub3ZhCisJCTs7CisJLW5zMiApCisJCW9zPS1uZXh0c3RlcDIKKwkJOzsKKwktbnNr
KikKKwkJb3M9LW5zaworCQk7OworCSMgUHJlc2VydmUgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHNp
bml4NS4KKwktc2luaXg1LiopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xzaW5peHxzeXN2
fCdgCisJCTs7CisJLXNpbml4KikKKwkJb3M9LXN5c3Y0CisJCTs7CisJLXRwZiopCisJCW9zPS10
cGYKKwkJOzsKKwktdHJpdG9uKikKKwkJb3M9LXN5c3YzCisJCTs7CisJLW9zcyopCisJCW9zPS1z
eXN2MworCQk7OworCS1zdnI0KQorCQlvcz0tc3lzdjQKKwkJOzsKKwktc3ZyMykKKwkJb3M9LXN5
c3YzCisJCTs7CisJLXN5c3ZyNCkKKwkJb3M9LXN5c3Y0CisJCTs7CisJIyBUaGlzIG11c3QgY29t
ZSBhZnRlciAtc3lzdnI0LgorCS1zeXN2KikKKwkJOzsKKwktb3NlKikKKwkJb3M9LW9zZQorCQk7
OworCS1lczE4MDAqKQorCQlvcz0tb3NlCisJCTs7CisJLXhlbml4KQorCQlvcz0teGVuaXgKKwkJ
OzsKKwktKm1pbnQgfCAtbWludFswLTldKiB8IC0qTWlOVCB8IC1NaU5UWzAtOV0qKQorCQlvcz0t
bWludAorCQk7OworCS1hcm9zKikKKwkJb3M9LWFyb3MKKwkJOzsKKwkta2FvcyopCisJCW9zPS1r
YW9zCisJCTs7CisJLXp2bW9lKQorCQlvcz0tenZtb2UKKwkJOzsKKwktZGljb3MqKQorCQlvcz0t
ZGljb3MKKwkJOzsKKwktbmFjbCopCisJCTs7CisJLW5vbmUpCisJCTs7CisJKikKKwkJIyBHZXQg
cmlkIG9mIHRoZSBgLScgYXQgdGhlIGJlZ2lubmluZyBvZiAkb3MuCisJCW9zPWBlY2hvICRvcyB8
IHNlZCAncy9bXi1dKi0vLydgCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFcJzog
c3lzdGVtIFxgJG9zXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJOzsKK2VzYWMK
K2Vsc2UKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVtcyB0
aGF0IGNvbWUgd2l0aCB2YXJpb3VzIG1hY2hpbmVzLgorIyBUaGUgdmFsdWUgc2hvdWxkIGJlIHdo
YXQgdGhlIHZlbmRvciBjdXJyZW50bHkgc2hpcHMgb3V0IHRoZSBkb29yIHdpdGggdGhlaXIKKyMg
bWFjaGluZSBvciBwdXQgYW5vdGhlciB3YXksIHRoZSBtb3N0IHBvcHVsYXIgb3MgcHJvdmlkZWQg
d2l0aCB0aGUgbWFjaGluZS4KKworIyBOb3RlIHRoYXQgaWYgeW91J3JlIGdvaW5nIHRvIHRyeSB0
byBtYXRjaCAiLU1BTlVGQUNUVVJFUiIgaGVyZSAoc2F5LAorIyAiLXN1biIpLCB0aGVuIHlvdSBo
YXZlIHRvIHRlbGwgdGhlIGNhc2Ugc3RhdGVtZW50IHVwIHRvd2FyZHMgdGhlIHRvcAorIyB0aGF0
IE1BTlVGQUNUVVJFUiBpc24ndCBhbiBvcGVyYXRpbmcgc3lzdGVtLiAgT3RoZXJ3aXNlLCBjb2Rl
IGFib3ZlCisjIHdpbGwgc2lnbmFsIGFuIGVycm9yIHNheWluZyB0aGF0IE1BTlVGQUNUVVJFUiBp
c24ndCBhbiBvcGVyYXRpbmcKKyMgc3lzdGVtLCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IHRvIHRoaXMg
cG9pbnQuCisKK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwlzY29yZS0qKQorCQlvcz0tZWxmCisJ
CTs7CisJc3B1LSopCisJCW9zPS1lbGYKKwkJOzsKKwkqLWFjb3JuKQorCQlvcz0tcmlzY2l4MS4y
CisJCTs7CisJYXJtKi1yZWJlbCkKKwkJb3M9LWxpbnV4CisJCTs7CisJYXJtKi1zZW1pKQorCQlv
cz0tYW91dAorCQk7OworCWM0eC0qIHwgdGljNHgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM1
NHgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM1NXgtKikKKwkJb3M9LWNvZmYKKwkJOzsKKwl0
aWM2eC0qKQorCQlvcz0tY29mZgorCQk7OworCSMgVGhpcyBtdXN0IGNvbWUgYmVmb3JlIHRoZSAq
LWRlYyBlbnRyeS4KKwlwZHAxMC0qKQorCQlvcz0tdG9wczIwCisJCTs7CisJcGRwMTEtKikKKwkJ
b3M9LW5vbmUKKwkJOzsKKwkqLWRlYyB8IHZheC0qKQorCQlvcz0tdWx0cml4NC4yCisJCTs7CisJ
bTY4Ki1hcG9sbG8pCisJCW9zPS1kb21haW4KKwkJOzsKKwlpMzg2LXN1bikKKwkJb3M9LXN1bm9z
NC4wLjIKKwkJOzsKKwltNjgwMDAtc3VuKQorCQlvcz0tc3Vub3MzCisJCSMgVGhpcyBhbHNvIGV4
aXN0cyBpbiB0aGUgY29uZmlndXJlIHByb2dyYW0sIGJ1dCB3YXMgbm90IHRoZQorCQkjIGRlZmF1
bHQuCisJCSMgb3M9LXN1bm9zNAorCQk7OworCW02OCotY2lzY28pCisJCW9zPS1hb3V0CisJCTs7
CisJbWVwLSopCisJCW9zPS1lbGYKKwkJOzsKKwltaXBzKi1jaXNjbykKKwkJb3M9LWVsZgorCQk7
OworCW1pcHMqLSopCisJCW9zPS1lbGYKKwkJOzsKKwlvcjMyLSopCisJCW9zPS1jb2ZmCisJCTs7
CisJKi10dGkpCSMgbXVzdCBiZSBiZWZvcmUgc3BhcmMgZW50cnkgb3Igd2UgZ2V0IHRoZSB3cm9u
ZyBvcy4KKwkJb3M9LXN5c3YzCisJCTs7CisJc3BhcmMtKiB8ICotc3VuKQorCQlvcz0tc3Vub3M0
LjEuMQorCQk7OworCSotYmUpCisJCW9zPS1iZW9zCisJCTs7CisJKi1oYWlrdSkKKwkJb3M9LWhh
aWt1CisJCTs7CisJKi1pYm0pCisJCW9zPS1haXgKKwkJOzsKKwkqLWtudXRoKQorCQlvcz0tbW1p
eHdhcmUKKwkJOzsKKwkqLXdlYykKKwkJb3M9LXByb2VsZgorCQk7OworCSotd2luYm9uZCkKKwkJ
b3M9LXByb2VsZgorCQk7OworCSotb2tpKQorCQlvcz0tcHJvZWxmCisJCTs7CisJKi1ocCkKKwkJ
b3M9LWhwdXgKKwkJOzsKKwkqLWhpdGFjaGkpCisJCW9zPS1oaXV4CisJCTs7CisJaTg2MC0qIHwg
Ki1hdHQgfCAqLW5jciB8ICotYWx0b3MgfCAqLW1vdG9yb2xhIHwgKi1jb252ZXJnZW50KQorCQlv
cz0tc3lzdgorCQk7OworCSotY2JtKQorCQlvcz0tYW1pZ2FvcworCQk7OworCSotZGcpCisJCW9z
PS1kZ3V4CisJCTs7CisJKi1kb2xwaGluKQorCQlvcz0tc3lzdjMKKwkJOzsKKwltNjhrLWNjdXIp
CisJCW9zPS1ydHUKKwkJOzsKKwltODhrLW9tcm9uKikKKwkJb3M9LWx1bmEKKwkJOzsKKwkqLW5l
eHQgKQorCQlvcz0tbmV4dHN0ZXAKKwkJOzsKKwkqLXNlcXVlbnQpCisJCW9zPS1wdHgKKwkJOzsK
KwkqLWNyZHMpCisJCW9zPS11bm9zCisJCTs7CisJKi1ucykKKwkJb3M9LWdlbml4CisJCTs7CisJ
aTM3MC0qKQorCQlvcz0tbXZzCisJCTs7CisJKi1uZXh0KQorCQlvcz0tbmV4dHN0ZXAzCisJCTs7
CisJKi1nb3VsZCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWhpZ2hsZXZlbCkKKwkJb3M9LWJzZAor
CQk7OworCSotZW5jb3JlKQorCQlvcz0tYnNkCisJCTs7CisJKi1zZ2kpCisJCW9zPS1pcml4CisJ
CTs7CisJKi1zaWVtZW5zKQorCQlvcz0tc3lzdjQKKwkJOzsKKwkqLW1hc3Njb21wKQorCQlvcz0t
cnR1CisJCTs7CisJZjMwWzAxXS1mdWppdHN1IHwgZjcwMC1mdWppdHN1KQorCQlvcz0tdXhwdgor
CQk7OworCSotcm9tNjhrKQorCQlvcz0tY29mZgorCQk7OworCSotKmJ1ZykKKwkJb3M9LWNvZmYK
KwkJOzsKKwkqLWFwcGxlKQorCQlvcz0tbWFjb3MKKwkJOzsKKwkqLWF0YXJpKikKKwkJb3M9LW1p
bnQKKwkJOzsKKwkqKQorCQlvcz0tbm9uZQorCQk7OworZXNhYworZmkKKworIyBIZXJlIHdlIGhh
bmRsZSB0aGUgY2FzZSB3aGVyZSB3ZSBrbm93IHRoZSBvcywgYW5kIHRoZSBDUFUgdHlwZSwgYnV0
IG5vdCB0aGUKKyMgbWFudWZhY3R1cmVyLiAgV2UgcGljayB0aGUgbG9naWNhbCBtYW51ZmFjdHVy
ZXIuCit2ZW5kb3I9dW5rbm93bgorY2FzZSAkYmFzaWNfbWFjaGluZSBpbgorCSotdW5rbm93bikK
KwkJY2FzZSAkb3MgaW4KKwkJCS1yaXNjaXgqKQorCQkJCXZlbmRvcj1hY29ybgorCQkJCTs7CisJ
CQktc3Vub3MqKQorCQkJCXZlbmRvcj1zdW4KKwkJCQk7OworCQkJLWNuayp8LWFpeCopCisJCQkJ
dmVuZG9yPWlibQorCQkJCTs7CisJCQktYmVvcyopCisJCQkJdmVuZG9yPWJlCisJCQkJOzsKKwkJ
CS1ocHV4KikKKwkJCQl2ZW5kb3I9aHAKKwkJCQk7OworCQkJLW1wZWl4KikKKwkJCQl2ZW5kb3I9
aHAKKwkJCQk7OworCQkJLWhpdXgqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsKKwkJCS11
bm9zKikKKwkJCQl2ZW5kb3I9Y3JkcworCQkJCTs7CisJCQktZGd1eCopCisJCQkJdmVuZG9yPWRn
CisJCQkJOzsKKwkJCS1sdW5hKikKKwkJCQl2ZW5kb3I9b21yb24KKwkJCQk7OworCQkJLWdlbml4
KikKKwkJCQl2ZW5kb3I9bnMKKwkJCQk7OworCQkJLW12cyogfCAtb3BlbmVkKikKKwkJCQl2ZW5k
b3I9aWJtCisJCQkJOzsKKwkJCS1vczQwMCopCisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQkt
cHR4KikKKwkJCQl2ZW5kb3I9c2VxdWVudAorCQkJCTs7CisJCQktdHBmKikKKwkJCQl2ZW5kb3I9
aWJtCisJCQkJOzsKKwkJCS12eHNpbSogfCAtdnh3b3JrcyogfCAtd2luZGlzcyopCisJCQkJdmVu
ZG9yPXdycworCQkJCTs7CisJCQktYXV4KikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7OworCQkJ
LWhtcyopCisJCQkJdmVuZG9yPWhpdGFjaGkKKwkJCQk7OworCQkJLW1wdyogfCAtbWFjb3MqKQor
CQkJCXZlbmRvcj1hcHBsZQorCQkJCTs7CisJCQktKm1pbnQgfCAtbWludFswLTldKiB8IC0qTWlO
VCB8IC1NaU5UWzAtOV0qKQorCQkJCXZlbmRvcj1hdGFyaQorCQkJCTs7CisJCQktdm9zKikKKwkJ
CQl2ZW5kb3I9c3RyYXR1cworCQkJCTs7CisJCWVzYWMKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAk
YmFzaWNfbWFjaGluZSB8IHNlZCAicy91bmtub3duLyR2ZW5kb3IvImAKKwkJOzsKK2VzYWMKKwor
ZWNobyAkYmFzaWNfbWFjaGluZSRvcworZXhpdAorCisjIExvY2FsIHZhcmlhYmxlczoKKyMgZXZh
bDogKGFkZC1ob29rICd3cml0ZS1maWxlLWhvb2tzICd0aW1lLXN0YW1wKQorIyB0aW1lLXN0YW1w
LXN0YXJ0OiAidGltZXN0YW1wPSciCisjIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0tJTAy
ZCIKKyMgdGltZS1zdGFtcC1lbmQ6ICInIgorIyBFbmQ6CmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9jb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvY29uZmlndXJlCU1vbiBGZWIgMjAgMTg6MjA6
MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwNDI5IEBACisjISAvYmluL3NoCisjIEd1ZXNzIHZh
bHVlcyBmb3Igc3lzdGVtLWRlcGVuZGVudCB2YXJpYWJsZXMgYW5kIGNyZWF0ZSBNYWtlZmlsZXMu
CisjIEdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OCBmb3IgWGVuIEh5cGVydmlzb3IgNC4y
LgorIworIyBSZXBvcnQgYnVncyB0byA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20+Lgor
IworIworIyBDb3B5cmlnaHQgKEMpIDE5OTIsIDE5OTMsIDE5OTQsIDE5OTUsIDE5OTYsIDE5OTgs
IDE5OTksIDIwMDAsIDIwMDEsCisjIDIwMDIsIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDYsIDIwMDcs
IDIwMDgsIDIwMDksIDIwMTAgRnJlZSBTb2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuCisjCisj
CisjIFRoaXMgY29uZmlndXJlIHNjcmlwdCBpcyBmcmVlIHNvZnR3YXJlOyB0aGUgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uCisjIGdpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNvcHksIGRp
c3RyaWJ1dGUgYW5kIG1vZGlmeSBpdC4KKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBN
NHNoIEluaXRpYWxpemF0aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKworIyBC
ZSBtb3JlIEJvdXJuZSBjb21wYXRpYmxlCitEVUFMQ0FTRT0xOyBleHBvcnQgRFVBTENBU0UgIyBm
b3IgTUtTIHNoCitpZiB0ZXN0IC1uICIke1pTSF9WRVJTSU9OK3NldH0iICYmIChlbXVsYXRlIHNo
KSA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAj
IFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uICR7MSsiJEAifSwg
d2hpY2gKKyAgIyBpcyBjb250cmFyeSB0byBvdXIgdXNhZ2UuICBEaXNhYmxlIHRoaXMgZmVhdHVy
ZS4KKyAgYWxpYXMgLWcgJyR7MSsiJEAifSc9JyIkQCInCisgIHNldG9wdCBOT19HTE9CX1NVQlNU
CitlbHNlCisgIGNhc2UgYChzZXQgLW8pIDI+L2Rldi9udWxsYCBpbiAjKAorICAqcG9zaXgqKSA6
CisgICAgc2V0IC1vIHBvc2l4IDs7ICMoCisgICopIDoKKyAgICAgOzsKK2VzYWMKK2ZpCisKKwor
YXNfbmw9JworJworZXhwb3J0IGFzX25sCisjIFByaW50aW5nIGEgbG9uZyBzdHJpbmcgY3Jhc2hl
cyBTb2xhcmlzIDcgL3Vzci9iaW4vcHJpbnRmLgorYXNfZWNobz0nXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXCcKK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRh
c19lY2hvJGFzX2VjaG8kYXNfZWNobworYXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8k
YXNfZWNobyRhc19lY2hvJGFzX2VjaG8KKyMgUHJlZmVyIGEga3NoIHNoZWxsIGJ1aWx0aW4gb3Zl
ciBhbiBleHRlcm5hbCBwcmludGYgcHJvZ3JhbSBvbiBTb2xhcmlzLAorIyBidXQgd2l0aG91dCB3
YXN0aW5nIGZvcmtzIGZvciBiYXNoIG9yIHpzaC4KK2lmIHRlc3QgLXogIiRCQVNIX1ZFUlNJT04k
WlNIX1ZFUlNJT04iIFwKKyAgICAmJiAodGVzdCAiWGBwcmludCAtciAtLSAkYXNfZWNob2AiID0g
IlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2VjaG89J3ByaW50IC1yIC0tJwor
ICBhc19lY2hvX249J3ByaW50IC1ybiAtLScKK2VsaWYgKHRlc3QgIlhgcHJpbnRmICVzICRhc19l
Y2hvYCIgPSAiWCRhc19lY2hvIikgMj4vZGV2L251bGw7IHRoZW4KKyAgYXNfZWNobz0ncHJpbnRm
ICVzXG4nCisgIGFzX2VjaG9fbj0ncHJpbnRmICVzJworZWxzZQorICBpZiB0ZXN0ICJYYCgvdXNy
L3VjYi9lY2hvIC1uIC1uICRhc19lY2hvKSAyPi9kZXYvbnVsbGAiID0gIlgtbiAkYXNfZWNobyI7
IHRoZW4KKyAgICBhc19lY2hvX2JvZHk9J2V2YWwgL3Vzci91Y2IvZWNobyAtbiAiJDEkYXNfbmwi
JworICAgIGFzX2VjaG9fbj0nL3Vzci91Y2IvZWNobyAtbicKKyAgZWxzZQorICAgIGFzX2VjaG9f
Ym9keT0nZXZhbCBleHByICJYJDEiIDogIlhcXCguKlxcKSInCisgICAgYXNfZWNob19uX2JvZHk9
J2V2YWwKKyAgICAgIGFyZz0kMTsKKyAgICAgIGNhc2UgJGFyZyBpbiAjKAorICAgICAgKiIkYXNf
bmwiKikKKwlleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpJGFzX25sIjsKKwlhcmc9YGV4cHIgIlgk
YXJnIiA6ICIuKiRhc19ubFxcKC4qXFwpImA7OworICAgICAgZXNhYzsKKyAgICAgIGV4cHIgIlgk
YXJnIiA6ICJYXFwoLipcXCkiIHwgdHIgLWQgIiRhc19ubCIKKyAgICAnCisgICAgZXhwb3J0IGFz
X2VjaG9fbl9ib2R5CisgICAgYXNfZWNob19uPSdzaCAtYyAkYXNfZWNob19uX2JvZHkgYXNfZWNo
bycKKyAgZmkKKyAgZXhwb3J0IGFzX2VjaG9fYm9keQorICBhc19lY2hvPSdzaCAtYyAkYXNfZWNo
b19ib2R5IGFzX2VjaG8nCitmaQorCisjIFRoZSB1c2VyIGlzIGFsd2F5cyByaWdodC4KK2lmIHRl
c3QgIiR7UEFUSF9TRVBBUkFUT1Irc2V0fSIgIT0gc2V0OyB0aGVuCisgIFBBVEhfU0VQQVJBVE9S
PToKKyAgKFBBVEg9Jy9iaW47L2Jpbic7IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rldi9udWxs
IDI+JjEgJiYgeworICAgIChQQVRIPScvYmluOi9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikg
Pi9kZXYvbnVsbCAyPiYxIHx8CisgICAgICBQQVRIX1NFUEFSQVRPUj0nOycKKyAgfQorZmkKKwor
CisjIElGUworIyBXZSBuZWVkIHNwYWNlLCB0YWIgYW5kIG5ldyBsaW5lLCBpbiBwcmVjaXNlbHkg
dGhhdCBvcmRlci4gIFF1b3RpbmcgaXMKKyMgdGhlcmUgdG8gcHJldmVudCBlZGl0b3JzIGZyb20g
Y29tcGxhaW5pbmcgYWJvdXQgc3BhY2UtdGFiLgorIyAoSWYgX0FTX1BBVEhfV0FMSyB3ZXJlIGNh
bGxlZCB3aXRoIElGUyB1bnNldCwgaXQgd291bGQgZGlzYWJsZSB3b3JkCisjIHNwbGl0dGluZyBi
eSBzZXR0aW5nIElGUyB0byBlbXB0eSB2YWx1ZS4pCitJRlM9IiAiIgkkYXNfbmwiCisKKyMgRmlu
ZCB3aG8gd2UgYXJlLiAgTG9vayBpbiB0aGUgcGF0aCBpZiB3ZSBjb250YWluIG5vIGRpcmVjdG9y
eSBzZXBhcmF0b3IuCithc19teXNlbGY9CitjYXNlICQwIGluICMoKAorICAqW1xcL10qICkgYXNf
bXlzZWxmPSQwIDs7CisgICopIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICB0ZXN0IC1yICIkYXNfZGlyLyQwIiAmJiBhc19teXNl
bGY9JGFzX2Rpci8kMCAmJiBicmVhaworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgICAg
OzsKK2VzYWMKKyMgV2UgZGlkIG5vdCBmaW5kIG91cnNlbHZlcywgbW9zdCBwcm9iYWJseSB3ZSB3
ZXJlIHJ1biBhcyBgc2ggQ09NTUFORCcKKyMgaW4gd2hpY2ggY2FzZSB3ZSBhcmUgbm90IHRvIGJl
IGZvdW5kIGluIHRoZSBwYXRoLgoraWYgdGVzdCAieCRhc19teXNlbGYiID0geDsgdGhlbgorICBh
c19teXNlbGY9JDAKK2ZpCitpZiB0ZXN0ICEgLWYgIiRhc19teXNlbGYiOyB0aGVuCisgICRhc19l
Y2hvICIkYXNfbXlzZWxmOiBlcnJvcjogY2Fubm90IGZpbmQgbXlzZWxmOyByZXJ1biB3aXRoIGFu
IGFic29sdXRlIGZpbGUgbmFtZSIgPiYyCisgIGV4aXQgMQorZmkKKworIyBVbnNldCB2YXJpYWJs
ZXMgdGhhdCB3ZSBkbyBub3QgbmVlZCBhbmQgd2hpY2ggY2F1c2UgYnVncyAoZS5nLiBpbgorIyBw
cmUtMy4wIFVXSU4ga3NoKS4gIEJ1dCBkbyBub3QgY2F1c2UgYnVncyBpbiBiYXNoIDIuMDE7IHRo
ZSAifHwgZXhpdCAxIgorIyBzdXBwcmVzc2VzIGFueSAiU2VnbWVudGF0aW9uIGZhdWx0IiBtZXNz
YWdlIHRoZXJlLiAgJygoJyBjb3VsZAorIyB0cmlnZ2VyIGEgYnVnIGluIHBka3NoIDUuMi4xNC4K
K2ZvciBhc192YXIgaW4gQkFTSF9FTlYgRU5WIE1BSUwgTUFJTFBBVEgKK2RvIGV2YWwgdGVzdCB4
XCR7JGFzX3ZhcitzZXR9ID0geHNldCBcCisgICYmICggKHVuc2V0ICRhc192YXIpIHx8IGV4aXQg
MSkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0ICRhc192YXIgfHwgOgorZG9uZQorUFMxPSckICcK
K1BTMj0nPiAnCitQUzQ9JysgJworCisjIE5MUyBudWlzYW5jZXMuCitMQ19BTEw9QworZXhwb3J0
IExDX0FMTAorTEFOR1VBR0U9QworZXhwb3J0IExBTkdVQUdFCisKKyMgQ0RQQVRILgorKHVuc2V0
IENEUEFUSCkgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IENEUEFUSAorCitpZiB0ZXN0ICJ4JENP
TkZJR19TSEVMTCIgPSB4OyB0aGVuCisgIGFzX2JvdXJuZV9jb21wYXRpYmxlPSJpZiB0ZXN0IC1u
IFwiXCR7WlNIX1ZFUlNJT04rc2V0fVwiICYmIChlbXVsYXRlIHNoKSA+L2Rldi9udWxsIDI+JjE7
IHRoZW4gOgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAjIFByZS00LjIgdmVyc2lvbnMg
b2YgWnNoIGRvIHdvcmQgc3BsaXR0aW5nIG9uIFwkezErXCJcJEBcIn0sIHdoaWNoCisgICMgaXMg
Y29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1n
ICdcJHsxK1wiXCRAXCJ9Jz0nXCJcJEBcIicKKyAgc2V0b3B0IE5PX0dMT0JfU1VCU1QKK2Vsc2UK
KyAgY2FzZSBcYChzZXQgLW8pIDI+L2Rldi9udWxsXGAgaW4gIygKKyAgKnBvc2l4KikgOgorICAg
IHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2FjCitmaQorIgorICBhc19y
ZXF1aXJlZD0iYXNfZm5fcmV0dXJuICgpIHsgKGV4aXQgXCQxKTsgfQorYXNfZm5fc3VjY2VzcyAo
KSB7IGFzX2ZuX3JldHVybiAwOyB9Cithc19mbl9mYWlsdXJlICgpIHsgYXNfZm5fcmV0dXJuIDE7
IH0KK2FzX2ZuX3JldF9zdWNjZXNzICgpIHsgcmV0dXJuIDA7IH0KK2FzX2ZuX3JldF9mYWlsdXJl
ICgpIHsgcmV0dXJuIDE7IH0KKworZXhpdGNvZGU9MAorYXNfZm5fc3VjY2VzcyB8fCB7IGV4aXRj
b2RlPTE7IGVjaG8gYXNfZm5fc3VjY2VzcyBmYWlsZWQuOyB9Cithc19mbl9mYWlsdXJlICYmIHsg
ZXhpdGNvZGU9MTsgZWNobyBhc19mbl9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2FzX2ZuX3JldF9z
dWNjZXNzIHx8IHsgZXhpdGNvZGU9MTsgZWNobyBhc19mbl9yZXRfc3VjY2VzcyBmYWlsZWQuOyB9
Cithc19mbl9yZXRfZmFpbHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fcmV0X2ZhaWx1
cmUgc3VjY2VlZGVkLjsgfQoraWYgKCBzZXQgeDsgYXNfZm5fcmV0X3N1Y2Nlc3MgeSAmJiB0ZXN0
IHggPSBcIlwkMVwiICk7IHRoZW4gOgorCitlbHNlCisgIGV4aXRjb2RlPTE7IGVjaG8gcG9zaXRp
b25hbCBwYXJhbWV0ZXJzIHdlcmUgbm90IHNhdmVkLgorZmkKK3Rlc3QgeFwkZXhpdGNvZGUgPSB4
MCB8fCBleGl0IDEiCisgIGFzX3N1Z2dlc3RlZD0iICBhc19saW5lbm9fMT0iO2FzX3N1Z2dlc3Rl
ZD0kYXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCIgYXNfbGlu
ZW5vXzFhPVwkTElORU5PCisgIGFzX2xpbmVub18yPSI7YXNfc3VnZ2VzdGVkPSRhc19zdWdnZXN0
ZWQkTElORU5PO2FzX3N1Z2dlc3RlZD0kYXNfc3VnZ2VzdGVkIiBhc19saW5lbm9fMmE9XCRMSU5F
Tk8KKyAgZXZhbCAndGVzdCBcInhcJGFzX2xpbmVub18xJ1wkYXNfcnVuJ1wiICE9IFwieFwkYXNf
bGluZW5vXzInXCRhc19ydW4nXCIgJiYKKyAgdGVzdCBcInhcYGV4cHIgXCRhc19saW5lbm9fMSdc
JGFzX3J1bicgKyAxXGBcIiA9IFwieFwkYXNfbGluZW5vXzInXCRhc19ydW4nXCInIHx8IGV4aXQg
MQordGVzdCBcJCgoIDEgKyAxICkpID0gMiB8fCBleGl0IDEiCisgIGlmIChldmFsICIkYXNfcmVx
dWlyZWQiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGFzX2hhdmVfcmVxdWlyZWQ9eWVzCitlbHNl
CisgIGFzX2hhdmVfcmVxdWlyZWQ9bm8KK2ZpCisgIGlmIHRlc3QgeCRhc19oYXZlX3JlcXVpcmVk
ID0geHllcyAmJiAoZXZhbCAiJGFzX3N1Z2dlc3RlZCIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKwor
ZWxzZQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCithc19mb3VuZD1m
YWxzZQorZm9yIGFzX2RpciBpbiAvYmluJFBBVEhfU0VQQVJBVE9SL3Vzci9iaW4kUEFUSF9TRVBB
UkFUT1IkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAm
JiBhc19kaXI9LgorICBhc19mb3VuZD06CisgIGNhc2UgJGFzX2RpciBpbiAjKAorCSAvKikKKwkg
ICBmb3IgYXNfYmFzZSBpbiBzaCBiYXNoIGtzaCBzaDU7IGRvCisJICAgICAjIFRyeSBvbmx5IHNo
ZWxscyB0aGF0IGV4aXN0LCB0byBzYXZlIHNldmVyYWwgZm9ya3MuCisJICAgICBhc19zaGVsbD0k
YXNfZGlyLyRhc19iYXNlCisJICAgICBpZiB7IHRlc3QgLWYgIiRhc19zaGVsbCIgfHwgdGVzdCAt
ZiAiJGFzX3NoZWxsLmV4ZSI7IH0gJiYKKwkJICAgIHsgJGFzX2VjaG8gIiRhc19ib3VybmVfY29t
cGF0aWJsZSIiJGFzX3JlcXVpcmVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9IDI+L2Rldi9u
dWxsOyB0aGVuIDoKKyAgQ09ORklHX1NIRUxMPSRhc19zaGVsbCBhc19oYXZlX3JlcXVpcmVkPXll
cworCQkgICBpZiB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUiIiRhc19zdWdnZXN0
ZWQiIHwgYXNfcnVuPWEgIiRhc19zaGVsbCI7IH0gMj4vZGV2L251bGw7IHRoZW4gOgorICBicmVh
ayAyCitmaQorZmkKKwkgICBkb25lOzsKKyAgICAgICBlc2FjCisgIGFzX2ZvdW5kPWZhbHNlCitk
b25lCiskYXNfZm91bmQgfHwgeyBpZiB7IHRlc3QgLWYgIiRTSEVMTCIgfHwgdGVzdCAtZiAiJFNI
RUxMLmV4ZSI7IH0gJiYKKwkgICAgICB7ICRhc19lY2hvICIkYXNfYm91cm5lX2NvbXBhdGlibGUi
IiRhc19yZXF1aXJlZCIgfCBhc19ydW49YSAiJFNIRUxMIjsgfSAyPi9kZXYvbnVsbDsgdGhlbiA6
CisgIENPTkZJR19TSEVMTD0kU0hFTEwgYXNfaGF2ZV9yZXF1aXJlZD15ZXMKK2ZpOyB9CitJRlM9
JGFzX3NhdmVfSUZTCisKKworICAgICAgaWYgdGVzdCAieCRDT05GSUdfU0hFTEwiICE9IHg7IHRo
ZW4gOgorICAjIFdlIGNhbm5vdCB5ZXQgYXNzdW1lIGEgZGVjZW50IHNoZWxsLCBzbyB3ZSBoYXZl
IHRvIHByb3ZpZGUgYQorCSMgbmV1dHJhbGl6YXRpb24gdmFsdWUgZm9yIHNoZWxscyB3aXRob3V0
IHVuc2V0OyBhbmQgdGhpcyBhbHNvCisJIyB3b3JrcyBhcm91bmQgc2hlbGxzIHRoYXQgY2Fubm90
IHVuc2V0IG5vbmV4aXN0ZW50IHZhcmlhYmxlcy4KKwkjIFByZXNlcnZlIC12IGFuZCAteCB0byB0
aGUgcmVwbGFjZW1lbnQgc2hlbGwuCisJQkFTSF9FTlY9L2Rldi9udWxsCisJRU5WPS9kZXYvbnVs
bAorCSh1bnNldCBCQVNIX0VOVikgPi9kZXYvbnVsbCAyPiYxICYmIHVuc2V0IEJBU0hfRU5WIEVO
VgorCWV4cG9ydCBDT05GSUdfU0hFTEwKKwljYXNlICQtIGluICMgKCgoKAorCSAgKnYqeCogfCAq
eCp2KiApIGFzX29wdHM9LXZ4IDs7CisJICAqdiogKSBhc19vcHRzPS12IDs7CisJICAqeCogKSBh
c19vcHRzPS14IDs7CisJICAqICkgYXNfb3B0cz0gOzsKKwllc2FjCisJZXhlYyAiJENPTkZJR19T
SEVMTCIgJGFzX29wdHMgIiRhc19teXNlbGYiICR7MSsiJEAifQorZmkKKworICAgIGlmIHRlc3Qg
eCRhc19oYXZlX3JlcXVpcmVkID0geG5vOyB0aGVuIDoKKyAgJGFzX2VjaG8gIiQwOiBUaGlzIHNj
cmlwdCByZXF1aXJlcyBhIHNoZWxsIG1vcmUgbW9kZXJuIHRoYW4gYWxsIgorICAkYXNfZWNobyAi
JDA6IHRoZSBzaGVsbHMgdGhhdCBJIGZvdW5kIG9uIHlvdXIgc3lzdGVtLiIKKyAgaWYgdGVzdCB4
JHtaU0hfVkVSU0lPTitzZXR9ID0geHNldCA7IHRoZW4KKyAgICAkYXNfZWNobyAiJDA6IEluIHBh
cnRpY3VsYXIsIHpzaCAkWlNIX1ZFUlNJT04gaGFzIGJ1Z3MgYW5kIHNob3VsZCIKKyAgICAkYXNf
ZWNobyAiJDA6IGJlIHVwZ3JhZGVkIHRvIHpzaCA0LjMuNCBvciBsYXRlci4iCisgIGVsc2UKKyAg
ICAkYXNfZWNobyAiJDA6IFBsZWFzZSB0ZWxsIGJ1Zy1hdXRvY29uZkBnbnUub3JnIGFuZAorJDA6
IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIGFib3V0IHlvdXIgc3lzdGVtLAorJDA6IGlu
Y2x1ZGluZyBhbnkgZXJyb3IgcG9zc2libHkgb3V0cHV0IGJlZm9yZSB0aGlzCiskMDogbWVzc2Fn
ZS4gVGhlbiBpbnN0YWxsIGEgbW9kZXJuIHNoZWxsLCBvciBtYW51YWxseSBydW4KKyQwOiB0aGUg
c2NyaXB0IHVuZGVyIHN1Y2ggYSBzaGVsbCBpZiB5b3UgZG8gaGF2ZSBvbmUuIgorICBmaQorICBl
eGl0IDEKK2ZpCitmaQorZmkKK1NIRUxMPSR7Q09ORklHX1NIRUxMLS9iaW4vc2h9CitleHBvcnQg
U0hFTEwKKyMgVW5zZXQgbW9yZSB2YXJpYWJsZXMga25vd24gdG8gaW50ZXJmZXJlIHdpdGggYmVo
YXZpb3Igb2YgY29tbW9uIHRvb2xzLgorQ0xJQ09MT1JfRk9SQ0U9IEdSRVBfT1BUSU9OUz0KK3Vu
c2V0IENMSUNPTE9SX0ZPUkNFIEdSRVBfT1BUSU9OUworCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0gIyMKKyMjIE00c2ggU2hlbGwgRnVuY3Rpb25zLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICMjCisjIGFzX2ZuX3Vuc2V0IFZBUgorIyAtLS0tLS0tLS0tLS0tLS0KKyMgUG9ydGFibHkg
dW5zZXQgVkFSLgorYXNfZm5fdW5zZXQgKCkKK3sKKyAgeyBldmFsICQxPTsgdW5zZXQgJDE7fQor
fQorYXNfdW5zZXQ9YXNfZm5fdW5zZXQKKworIyBhc19mbl9zZXRfc3RhdHVzIFNUQVRVUworIyAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBTZXQgJD8gdG8gU1RBVFVTLCB3aXRob3V0IGZvcmtp
bmcuCithc19mbl9zZXRfc3RhdHVzICgpCit7CisgIHJldHVybiAkMQorfSAjIGFzX2ZuX3NldF9z
dGF0dXMKKworIyBhc19mbl9leGl0IFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLQorIyBFeGl0
IHRoZSBzaGVsbCB3aXRoIFNUQVRVUywgZXZlbiBpbiBhICJ0cmFwIDAiIG9yICJzZXQgLWUiIGNv
bnRleHQuCithc19mbl9leGl0ICgpCit7CisgIHNldCArZQorICBhc19mbl9zZXRfc3RhdHVzICQx
CisgIGV4aXQgJDEKK30gIyBhc19mbl9leGl0CisKKyMgYXNfZm5fbWtkaXJfcAorIyAtLS0tLS0t
LS0tLS0tCisjIENyZWF0ZSAiJGFzX2RpciIgYXMgYSBkaXJlY3RvcnksIGluY2x1ZGluZyBwYXJl
bnRzIGlmIG5lY2Vzc2FyeS4KK2FzX2ZuX21rZGlyX3AgKCkKK3sKKworICBjYXNlICRhc19kaXIg
aW4gIygKKyAgLSopIGFzX2Rpcj0uLyRhc19kaXI7OworICBlc2FjCisgIHRlc3QgLWQgIiRhc19k
aXIiIHx8IGV2YWwgJGFzX21rZGlyX3AgfHwgeworICAgIGFzX2RpcnM9CisgICAgd2hpbGUgOjsg
ZG8KKyAgICAgIGNhc2UgJGFzX2RpciBpbiAjKAorICAgICAgKlwnKikgYXNfcWRpcj1gJGFzX2Vj
aG8gIiRhc19kaXIiIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgIycoCisgICAgICAqKSBh
c19xZGlyPSRhc19kaXI7OworICAgICAgZXNhYworICAgICAgYXNfZGlycz0iJyRhc19xZGlyJyAk
YXNfZGlycyIKKyAgICAgIGFzX2Rpcj1gJGFzX2Rpcm5hbWUgLS0gIiRhc19kaXIiIHx8CiskYXNf
ZXhwciBYIiRhc19kaXIiIDogJ1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgi
JGFzX2RpciIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpJCcg
XHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2Vj
aG8gWCIkYXNfZGlyIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyok
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkg
ICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wxLwor
CSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9
CisJICBzLy4qLy4vOyBxJ2AKKyAgICAgIHRlc3QgLWQgIiRhc19kaXIiICYmIGJyZWFrCisgICAg
ZG9uZQorICAgIHRlc3QgLXogIiRhc19kaXJzIiB8fCBldmFsICJta2RpciAkYXNfZGlycyIKKyAg
fSB8fCB0ZXN0IC1kICIkYXNfZGlyIiB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBk
aXJlY3RvcnkgJGFzX2RpciIKKworCit9ICMgYXNfZm5fbWtkaXJfcAorIyBhc19mbl9hcHBlbmQg
VkFSIFZBTFVFCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgQXBwZW5kIHRoZSB0ZXh0IGlu
IFZBTFVFIHRvIHRoZSBlbmQgb2YgdGhlIGRlZmluaXRpb24gY29udGFpbmVkIGluIFZBUi4gVGFr
ZQorIyBhZHZhbnRhZ2Ugb2YgYW55IHNoZWxsIG9wdGltaXphdGlvbnMgdGhhdCBhbGxvdyBhbW9y
dGl6ZWQgbGluZWFyIGdyb3d0aCBvdmVyCisjIHJlcGVhdGVkIGFwcGVuZHMsIGluc3RlYWQgb2Yg
dGhlIHR5cGljYWwgcXVhZHJhdGljIGdyb3d0aCBwcmVzZW50IGluIG5haXZlCisjIGltcGxlbWVu
dGF0aW9ucy4KK2lmIChldmFsICJhc192YXI9MTsgYXNfdmFyKz0yOyB0ZXN0IHhcJGFzX3ZhciA9
IHgxMiIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXBwZW5kICgpCisgIHsK
KyAgICBldmFsICQxKz1cJDIKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXBwZW5kICgpCisgIHsKKyAg
ICBldmFsICQxPVwkJDFcJDIKKyAgfQorZmkgIyBhc19mbl9hcHBlbmQKKworIyBhc19mbl9hcml0
aCBBUkcuLi4KKyMgLS0tLS0tLS0tLS0tLS0tLS0tCisjIFBlcmZvcm0gYXJpdGhtZXRpYyBldmFs
dWF0aW9uIG9uIHRoZSBBUkdzLCBhbmQgc3RvcmUgdGhlIHJlc3VsdCBpbiB0aGUKKyMgZ2xvYmFs
ICRhc192YWwuIFRha2UgYWR2YW50YWdlIG9mIHNoZWxscyB0aGF0IGNhbiBhdm9pZCBmb3Jrcy4g
VGhlIGFyZ3VtZW50cworIyBtdXN0IGJlIHBvcnRhYmxlIGFjcm9zcyAkKCgpKSBhbmQgZXhwci4K
K2lmIChldmFsICJ0ZXN0IFwkKCggMSArIDEgKSkgPSAyIikgMj4vZGV2L251bGw7IHRoZW4gOgor
ICBldmFsICdhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPSQoKCAkKiApKQorICB9Jwor
ZWxzZQorICBhc19mbl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPWBleHByICIkQCIgfHwgdGVz
dCAkPyAtZXEgMWAKKyAgfQorZmkgIyBhc19mbl9hcml0aAorCisKKyMgYXNfZm5fZXJyb3IgU1RB
VFVTIEVSUk9SIFtMSU5FTk8gTE9HX0ZEXQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCisjIE91dHB1dCAiYGJhc2VuYW1lICQwYDogZXJyb3I6IEVSUk9SIiB0byBz
dGRlcnIuIElmIExJTkVOTyBhbmQgTE9HX0ZEIGFyZQorIyBwcm92aWRlZCwgYWxzbyBvdXRwdXQg
dGhlIGVycm9yIHRvIExPR19GRCwgcmVmZXJlbmNpbmcgTElORU5PLiBUaGVuIGV4aXQgdGhlCisj
IHNjcmlwdCB3aXRoIFNUQVRVUywgdXNpbmcgMSBpZiB0aGF0IHdhcyAwLgorYXNfZm5fZXJyb3Ig
KCkKK3sKKyAgYXNfc3RhdHVzPSQxOyB0ZXN0ICRhc19zdGF0dXMgLWVxIDAgJiYgYXNfc3RhdHVz
PTEKKyAgaWYgdGVzdCAiJDQiOyB0aGVuCisgICAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMyJ9
IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICAgICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiAkMiIgPiYkNAorICBm
aQorICAkYXNfZWNobyAiJGFzX21lOiBlcnJvcjogJDIiID4mMgorICBhc19mbl9leGl0ICRhc19z
dGF0dXMKK30gIyBhc19mbl9lcnJvcgorCitpZiBleHByIGEgOiAnXChhXCknID4vZGV2L251bGwg
Mj4mMSAmJgorICAgdGVzdCAiWGBleHByIDAwMDAxIDogJy4qXCguLi5cKSdgIiA9IFgwMDE7IHRo
ZW4KKyAgYXNfZXhwcj1leHByCitlbHNlCisgIGFzX2V4cHI9ZmFsc2UKK2ZpCisKK2lmIChiYXNl
bmFtZSAtLSAvKSA+L2Rldi9udWxsIDI+JjEgJiYgdGVzdCAiWGBiYXNlbmFtZSAtLSAvIDI+JjFg
IiA9ICJYLyI7IHRoZW4KKyAgYXNfYmFzZW5hbWU9YmFzZW5hbWUKK2Vsc2UKKyAgYXNfYmFzZW5h
bWU9ZmFsc2UKK2ZpCisKK2lmIChhc19kaXI9YGRpcm5hbWUgLS0gL2AgJiYgdGVzdCAiWCRhc19k
aXIiID0gWC8pID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBhc19kaXJuYW1lPWRpcm5hbWUKK2Vs
c2UKKyAgYXNfZGlybmFtZT1mYWxzZQorZmkKKworYXNfbWU9YCRhc19iYXNlbmFtZSAtLSAiJDAi
IHx8CiskYXNfZXhwciBYLyIkMCIgOiAnLiovXChbXi9dW14vXSpcKS8qJCcgXHwgXAorCSBYIiQw
IiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiQwIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2L251bGwg
fHwKKyRhc19lY2hvIFgvIiQwIiB8CisgICAgc2VkICcvXi4qXC9cKFteL11bXi9dKlwpXC8qJC97
CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cL1wpJC97CisJICAgIHMv
L1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cKS4qL3sKKwkgICAgcy8vXDEvCisJICAg
IHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorCisjIEF2b2lkIGRlcGVuZGluZyB1cG9uIENoYXJh
Y3RlciBSYW5nZXMuCithc19jcl9sZXR0ZXJzPSdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eicK
K2FzX2NyX0xFVFRFUlM9J0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJworYXNfY3JfTGV0dGVy
cz0kYXNfY3JfbGV0dGVycyRhc19jcl9MRVRURVJTCithc19jcl9kaWdpdHM9JzAxMjM0NTY3ODkn
Cithc19jcl9hbG51bT0kYXNfY3JfTGV0dGVycyRhc19jcl9kaWdpdHMKKworCisgIGFzX2xpbmVu
b18xPSRMSU5FTk8gYXNfbGluZW5vXzFhPSRMSU5FTk8KKyAgYXNfbGluZW5vXzI9JExJTkVOTyBh
c19saW5lbm9fMmE9JExJTkVOTworICBldmFsICd0ZXN0ICJ4JGFzX2xpbmVub18xJyRhc19ydW4n
IiAhPSAieCRhc19saW5lbm9fMickYXNfcnVuJyIgJiYKKyAgdGVzdCAieGBleHByICRhc19saW5l
bm9fMSckYXNfcnVuJyArIDFgIiA9ICJ4JGFzX2xpbmVub18yJyRhc19ydW4nIicgfHwgeworICAj
IEJsYW1lIExlZSBFLiBNY01haG9uICgxOTMxLTE5ODkpIGZvciBzZWQncyBzeW50YXguICA6LSkK
KyAgc2VkIC1uICcKKyAgICBwCisgICAgL1skXUxJTkVOTy89CisgICcgPCRhc19teXNlbGYgfAor
ICAgIHNlZCAnCisgICAgICBzL1skXUxJTkVOTy4qLyYtLworICAgICAgdCBsaW5lbm8KKyAgICAg
IGIKKyAgICAgIDpsaW5lbm8KKyAgICAgIE4KKyAgICAgIDpsb29wCisgICAgICBzL1skXUxJTkVO
T1woW14nJGFzX2NyX2FsbnVtJ19dLipcblwpXCguKlwpL1wyXDFcMi8KKyAgICAgIHQgbG9vcAor
ICAgICAgcy8tXG4uKi8vCisgICAgJyA+JGFzX21lLmxpbmVubyAmJgorICBjaG1vZCAreCAiJGFz
X21lLmxpbmVubyIgfHwKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjYW5ub3QgY3Jl
YXRlICRhc19tZS5saW5lbm87IHJlcnVuIHdpdGggYSBQT1NJWCBzaGVsbCIgPiYyOyBhc19mbl9l
eGl0IDE7IH0KKworICAjIERvbid0IHRyeSB0byBleGVjIGFzIGl0IGNoYW5nZXMgJFswXSwgY2F1
c2luZyBhbGwgc29ydCBvZiBwcm9ibGVtcworICAjICh0aGUgZGlybmFtZSBvZiAkWzBdIGlzIG5v
dCB0aGUgcGxhY2Ugd2hlcmUgd2UgbWlnaHQgZmluZCB0aGUKKyAgIyBvcmlnaW5hbCBhbmQgc28g
b24uICBBdXRvY29uZiBpcyBlc3BlY2lhbGx5IHNlbnNpdGl2ZSB0byB0aGlzKS4KKyAgLiAiLi8k
YXNfbWUubGluZW5vIgorICAjIEV4aXQgc3RhdHVzIGlzIHRoYXQgb2YgdGhlIGxhc3QgY29tbWFu
ZC4KKyAgZXhpdAorfQorCitFQ0hPX0M9IEVDSE9fTj0gRUNIT19UPQorY2FzZSBgZWNobyAtbiB4
YCBpbiAjKCgoKCgKKy1uKikKKyAgY2FzZSBgZWNobyAneHlcYydgIGluCisgICpjKikgRUNIT19U
PScJJzs7CSMgRUNIT19UIGlzIHNpbmdsZSB0YWIgY2hhcmFjdGVyLgorICB4eSkgIEVDSE9fQz0n
XGMnOzsKKyAgKikgICBlY2hvIGBlY2hvIGtzaDg4IGJ1ZyBvbiBBSVggNi4xYCA+IC9kZXYvbnVs
bAorICAgICAgIEVDSE9fVD0nCSc7OworICBlc2FjOzsKKyopCisgIEVDSE9fTj0nLW4nOzsKK2Vz
YWMKKworcm0gLWYgY29uZiQkIGNvbmYkJC5leGUgY29uZiQkLmZpbGUKK2lmIHRlc3QgLWQgY29u
ZiQkLmRpcjsgdGhlbgorICBybSAtZiBjb25mJCQuZGlyL2NvbmYkJC5maWxlCitlbHNlCisgIHJt
IC1mIGNvbmYkJC5kaXIKKyAgbWtkaXIgY29uZiQkLmRpciAyPi9kZXYvbnVsbAorZmkKK2lmIChl
Y2hvID5jb25mJCQuZmlsZSkgMj4vZGV2L251bGw7IHRoZW4KKyAgaWYgbG4gLXMgY29uZiQkLmZp
bGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz0nbG4gLXMnCisgICAgIyAu
Li4gYnV0IHRoZXJlIGFyZSB0d28gZ290Y2hhczoKKyAgICAjIDEpIE9uIE1TWVMsIGJvdGggYGxu
IC1zIGZpbGUgZGlyJyBhbmQgYGxuIGZpbGUgZGlyJyBmYWlsLgorICAgICMgMikgREpHUFAgPCAy
LjA0IGhhcyBubyBzeW1saW5rczsgYGxuIC1zJyBjcmVhdGVzIGEgd3JhcHBlciBleGVjdXRhYmxl
LgorICAgICMgSW4gYm90aCBjYXNlcywgd2UgaGF2ZSB0byBkZWZhdWx0IHRvIGBjcCAtcCcuCisg
ICAgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQkLmRpciAyPi9kZXYvbnVsbCAmJiB0ZXN0ICEgLWYg
Y29uZiQkLmV4ZSB8fAorICAgICAgYXNfbG5fcz0nY3AgLXAnCisgIGVsaWYgbG4gY29uZiQkLmZp
bGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVuCisgICAgYXNfbG5fcz1sbgorICBlbHNlCisgICAg
YXNfbG5fcz0nY3AgLXAnCisgIGZpCitlbHNlCisgIGFzX2xuX3M9J2NwIC1wJworZmkKK3JtIC1m
IGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5kaXIvY29uZiQkLmZpbGUgY29uZiQkLmZpbGUKK3Jt
ZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwKKworaWYgbWtkaXIgLXAgLiAyPi9kZXYvbnVsbDsg
dGhlbgorICBhc19ta2Rpcl9wPSdta2RpciAtcCAiJGFzX2RpciInCitlbHNlCisgIHRlc3QgLWQg
Li8tcCAmJiBybWRpciAuLy1wCisgIGFzX21rZGlyX3A9ZmFsc2UKK2ZpCisKK2lmIHRlc3QgLXgg
LyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfdGVzdF94PSd0ZXN0IC14JworZWxzZQorICBp
ZiBscyAtZEwgLyA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICBhc19sc19MX29wdGlvbj1MCisg
IGVsc2UKKyAgICBhc19sc19MX29wdGlvbj0KKyAgZmkKKyAgYXNfdGVzdF94PScKKyAgICBldmFs
IHNoIC1jICdcJycKKyAgICAgIGlmIHRlc3QgLWQgIiQxIjsgdGhlbgorCXRlc3QgLWQgIiQxLy4i
OworICAgICAgZWxzZQorCWNhc2UgJDEgaW4gIygKKwktKilzZXQgIi4vJDEiOzsKKwllc2FjOwor
CWNhc2UgYGxzIC1sZCckYXNfbHNfTF9vcHRpb24nICIkMSIgMj4vZGV2L251bGxgIGluICMoKAor
CT8/P1tzeF0qKTo7OyopZmFsc2U7O2VzYWM7ZmkKKyAgICAnXCcnIHNoCisgICcKK2ZpCithc19l
eGVjdXRhYmxlX3A9JGFzX3Rlc3RfeAorCisjIFNlZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmlu
ZyBvbnRvIGEgdmFsaWQgQ1BQIG5hbWUuCithc190cl9jcHA9ImV2YWwgc2VkICd5JSokYXNfY3Jf
bGV0dGVycyVQJGFzX2NyX0xFVFRFUlMlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisjIFNl
ZCBleHByZXNzaW9uIHRvIG1hcCBhIHN0cmluZyBvbnRvIGEgdmFsaWQgdmFyaWFibGUgbmFtZS4K
K2FzX3RyX3NoPSJldmFsIHNlZCAneSUqKyVwcCU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisK
KwordGVzdCAtbiAiJERKRElSIiB8fCBleGVjIDc8JjAgPC9kZXYvbnVsbAorZXhlYyA2PiYxCisK
KyMgTmFtZSBvZiB0aGUgaG9zdC4KKyMgaG9zdG5hbWUgb24gc29tZSBzeXN0ZW1zIChTVlIzLjIs
IG9sZCBHTlUvTGludXgpIHJldHVybnMgYSBib2d1cyBleGl0IHN0YXR1cywKKyMgc28gdW5hbWUg
Z2V0cyBydW4gdG9vLgorYWNfaG9zdG5hbWU9YChob3N0bmFtZSB8fCB1bmFtZSAtbikgMj4vZGV2
L251bGwgfCBzZWQgMXFgCisKKyMKKyMgSW5pdGlhbGl6YXRpb25zLgorIworYWNfZGVmYXVsdF9w
cmVmaXg9L3Vzci9sb2NhbAorYWNfY2xlYW5fZmlsZXM9CithY19jb25maWdfbGlib2JqX2Rpcj0u
CitMSUJPQkpTPQorY3Jvc3NfY29tcGlsaW5nPW5vCitzdWJkaXJzPQorTUZMQUdTPQorTUFLRUZM
QUdTPQorCisjIElkZW50aXR5IG9mIHRoaXMgcGFja2FnZS4KK1BBQ0tBR0VfTkFNRT0nWGVuIEh5
cGVydmlzb3InCitQQUNLQUdFX1RBUk5BTUU9J3hlbi1oeXBlcnZpc29yJworUEFDS0FHRV9WRVJT
SU9OPSc0LjInCitQQUNLQUdFX1NUUklORz0nWGVuIEh5cGVydmlzb3IgNC4yJworUEFDS0FHRV9C
VUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tJworUEFDS0FHRV9VUkw9JycK
KworYWNfdW5pcXVlX2ZpbGU9ImxpYnhsL2xpYnhsLmMiCithY19kZWZhdWx0X3ByZWZpeD0vdXNy
CisjIEZhY3RvcmluZyBkZWZhdWx0IGhlYWRlcnMgZm9yIG1vc3QgdGVzdHMuCithY19pbmNsdWRl
c19kZWZhdWx0PSJcCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpZmRlZiBIQVZFX1NZU19UWVBFU19I
CisjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TWVNfU1RBVF9I
CisjIGluY2x1ZGUgPHN5cy9zdGF0Lmg+CisjZW5kaWYKKyNpZmRlZiBTVERDX0hFQURFUlMKKyMg
aW5jbHVkZSA8c3RkbGliLmg+CisjIGluY2x1ZGUgPHN0ZGRlZi5oPgorI2Vsc2UKKyMgaWZkZWYg
SEFWRV9TVERMSUJfSAorIyAgaW5jbHVkZSA8c3RkbGliLmg+CisjIGVuZGlmCisjZW5kaWYKKyNp
ZmRlZiBIQVZFX1NUUklOR19ICisjIGlmICFkZWZpbmVkIFNURENfSEVBREVSUyAmJiBkZWZpbmVk
IEhBVkVfTUVNT1JZX0gKKyMgIGluY2x1ZGUgPG1lbW9yeS5oPgorIyBlbmRpZgorIyBpbmNsdWRl
IDxzdHJpbmcuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RSSU5HU19ICisjIGluY2x1ZGUgPHN0
cmluZ3MuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfSU5UVFlQRVNfSAorIyBpbmNsdWRlIDxpbnR0
eXBlcy5oPgorI2VuZGlmCisjaWZkZWYgSEFWRV9TVERJTlRfSAorIyBpbmNsdWRlIDxzdGRpbnQu
aD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfVU5JU1REX0gKKyMgaW5jbHVkZSA8dW5pc3RkLmg+Cisj
ZW5kaWYiCisKK2FjX2hlYWRlcl9saXN0PQorYWNfZnVuY19saXN0PQorYWNfc3Vic3RfdmFycz0n
TFRMSUJPQkpTCitQT1dfTElCCitMSUJPQkpTCitBTExPQ0EKK2xpYmljb252CitsaWJnY3J5cHQK
K2xpYmV4dDJmcworc3lzdGVtX2FpbworTElCX1BBVEgKK2dsaWJfTElCUworZ2xpYl9DRkxBR1MK
K1BLR19DT05GSUdfTElCRElSCitQS0dfQ09ORklHX1BBVEgKK1BLR19DT05GSUcKK1ZOQ09ORklH
CitIT1RQTFVHCitVREVWSU5GTworVURFVkFETQorUFlUSE9OUEFUSAorT0NBTUxCVUlMRAorT0NB
TUxET0MKK09DQU1MTUtMSUIKK09DQU1MTUtUT1AKK09DQU1MREVQCitPQ0FNTAorT0NBTUxPUFRE
T1RPUFQKK09DQU1MQ0RPVE9QVAorT0NBTUxCRVNUCitPQ0FNTE9QVAorT0NBTUxMSUIKK09DQU1M
VkVSU0lPTgorT0NBTUxDCitJTlNUQUxMX0RBVEEKK0lOU1RBTExfU0NSSVBUCitJTlNUQUxMX1BS
T0dSQU0KK1NFVF9NQUtFCitMTl9TCitTRUQKK1hHRVRURVhUCitCQVNICitYTUwKK0NVUkwKK0ZM
RVgKK0JJU09OCitJUAorQlJDVEwKK1BFUkwKK1BZVEhPTgorQVBQRU5EX0xJQgorQVBQRU5EX0lO
Q0xVREVTCitQUkVQRU5EX0xJQgorUFJFUEVORF9JTkNMVURFUworZGVidWcKK2xvbW91bnQKK21p
bml0ZXJtCitvY2FtbHRvb2xzCitweXRob250b29scworeGFwaQordnRwbQorbW9uaXRvcnMKK2dp
dGh0dHAKK3hzbQoraG9zdF9vcworaG9zdF92ZW5kb3IKK2hvc3RfY3B1Citob3N0CitidWlsZF9v
cworYnVpbGRfdmVuZG9yCitidWlsZF9jcHUKK2J1aWxkCitFR1JFUAorR1JFUAorQ1BQCitPQkpF
WFQKK0VYRUVYVAorYWNfY3RfQ0MKK0NQUEZMQUdTCitMREZMQUdTCitDRkxBR1MKK0NDCit0YXJn
ZXRfYWxpYXMKK2hvc3RfYWxpYXMKK2J1aWxkX2FsaWFzCitMSUJTCitFQ0hPX1QKK0VDSE9fTgor
RUNIT19DCitERUZTCittYW5kaXIKK2xvY2FsZWRpcgorbGliZGlyCitwc2RpcgorcGRmZGlyCitk
dmlkaXIKK2h0bWxkaXIKK2luZm9kaXIKK2RvY2Rpcgorb2xkaW5jbHVkZWRpcgoraW5jbHVkZWRp
cgorbG9jYWxzdGF0ZWRpcgorc2hhcmVkc3RhdGVkaXIKK3N5c2NvbmZkaXIKK2RhdGFkaXIKK2Rh
dGFyb290ZGlyCitsaWJleGVjZGlyCitzYmluZGlyCitiaW5kaXIKK3Byb2dyYW1fdHJhbnNmb3Jt
X25hbWUKK3ByZWZpeAorZXhlY19wcmVmaXgKK1BBQ0tBR0VfVVJMCitQQUNLQUdFX0JVR1JFUE9S
VAorUEFDS0FHRV9TVFJJTkcKK1BBQ0tBR0VfVkVSU0lPTgorUEFDS0FHRV9UQVJOQU1FCitQQUNL
QUdFX05BTUUKK1BBVEhfU0VQQVJBVE9SCitTSEVMTCcKK2FjX3N1YnN0X2ZpbGVzPScnCithY191
c2VyX29wdHM9JworZW5hYmxlX29wdGlvbl9jaGVja2luZworZW5hYmxlX3hzbQorZW5hYmxlX2dp
dGh0dHAKK2VuYWJsZV9tb25pdG9ycworZW5hYmxlX3Z0cG0KK2VuYWJsZV94YXBpCitlbmFibGVf
cHl0aG9udG9vbHMKK2VuYWJsZV9vY2FtbHRvb2xzCitlbmFibGVfbWluaXRlcm0KK2VuYWJsZV9s
b21vdW50CitlbmFibGVfZGVidWcKKycKKyAgICAgIGFjX3ByZWNpb3VzX3ZhcnM9J2J1aWxkX2Fs
aWFzCitob3N0X2FsaWFzCit0YXJnZXRfYWxpYXMKK0NDCitDRkxBR1MKK0xERkxBR1MKK0xJQlMK
K0NQUEZMQUdTCitDUFAKK1BSRVBFTkRfSU5DTFVERVMKK1BSRVBFTkRfTElCCitBUFBFTkRfSU5D
TFVERVMKK0FQUEVORF9MSUIKK1BZVEhPTgorUEVSTAorQlJDVEwKK0lQCitCSVNPTgorRkxFWAor
Q1VSTAorWE1MCitCQVNICitYR0VUVEVYVAorUEtHX0NPTkZJRworUEtHX0NPTkZJR19QQVRICitQ
S0dfQ09ORklHX0xJQkRJUgorZ2xpYl9DRkxBR1MKK2dsaWJfTElCUycKKworCisjIEluaXRpYWxp
emUgc29tZSB2YXJpYWJsZXMgc2V0IGJ5IG9wdGlvbnMuCithY19pbml0X2hlbHA9CithY19pbml0
X3ZlcnNpb249ZmFsc2UKK2FjX3VucmVjb2duaXplZF9vcHRzPQorYWNfdW5yZWNvZ25pemVkX3Nl
cD0KKyMgVGhlIHZhcmlhYmxlcyBoYXZlIHRoZSBzYW1lIG5hbWVzIGFzIHRoZSBvcHRpb25zLCB3
aXRoCisjIGRhc2hlcyBjaGFuZ2VkIHRvIHVuZGVybGluZXMuCitjYWNoZV9maWxlPS9kZXYvbnVs
bAorZXhlY19wcmVmaXg9Tk9ORQorbm9fY3JlYXRlPQorbm9fcmVjdXJzaW9uPQorcHJlZml4PU5P
TkUKK3Byb2dyYW1fcHJlZml4PU5PTkUKK3Byb2dyYW1fc3VmZml4PU5PTkUKK3Byb2dyYW1fdHJh
bnNmb3JtX25hbWU9cyx4LHgsCitzaWxlbnQ9CitzaXRlPQorc3JjZGlyPQordmVyYm9zZT0KK3hf
aW5jbHVkZXM9Tk9ORQoreF9saWJyYXJpZXM9Tk9ORQorCisjIEluc3RhbGxhdGlvbiBkaXJlY3Rv
cnkgb3B0aW9ucy4KKyMgVGhlc2UgYXJlIGxlZnQgdW5leHBhbmRlZCBzbyB1c2VycyBjYW4gIm1h
a2UgaW5zdGFsbCBleGVjX3ByZWZpeD0vZm9vIgorIyBhbmQgYWxsIHRoZSB2YXJpYWJsZXMgdGhh
dCBhcmUgc3VwcG9zZWQgdG8gYmUgYmFzZWQgb24gZXhlY19wcmVmaXgKKyMgYnkgZGVmYXVsdCB3
aWxsIGFjdHVhbGx5IGNoYW5nZS4KKyMgVXNlIGJyYWNlcyBpbnN0ZWFkIG9mIHBhcmVucyBiZWNh
dXNlIHNoLCBwZXJsLCBldGMuIGFsc28gYWNjZXB0IHRoZW0uCisjIChUaGUgbGlzdCBmb2xsb3dz
IHRoZSBzYW1lIG9yZGVyIGFzIHRoZSBHTlUgQ29kaW5nIFN0YW5kYXJkcy4pCitiaW5kaXI9JyR7
ZXhlY19wcmVmaXh9L2JpbicKK3NiaW5kaXI9JyR7ZXhlY19wcmVmaXh9L3NiaW4nCitsaWJleGVj
ZGlyPScke2V4ZWNfcHJlZml4fS9saWJleGVjJworZGF0YXJvb3RkaXI9JyR7cHJlZml4fS9zaGFy
ZScKK2RhdGFkaXI9JyR7ZGF0YXJvb3RkaXJ9Jworc3lzY29uZmRpcj0nJHtwcmVmaXh9L2V0YycK
K3NoYXJlZHN0YXRlZGlyPScke3ByZWZpeH0vY29tJworbG9jYWxzdGF0ZWRpcj0nJHtwcmVmaXh9
L3ZhcicKK2luY2x1ZGVkaXI9JyR7cHJlZml4fS9pbmNsdWRlJworb2xkaW5jbHVkZWRpcj0nL3Vz
ci9pbmNsdWRlJworZG9jZGlyPScke2RhdGFyb290ZGlyfS9kb2MvJHtQQUNLQUdFX1RBUk5BTUV9
JworaW5mb2Rpcj0nJHtkYXRhcm9vdGRpcn0vaW5mbycKK2h0bWxkaXI9JyR7ZG9jZGlyfScKK2R2
aWRpcj0nJHtkb2NkaXJ9JworcGRmZGlyPScke2RvY2Rpcn0nCitwc2Rpcj0nJHtkb2NkaXJ9Jwor
bGliZGlyPScke2V4ZWNfcHJlZml4fS9saWInCitsb2NhbGVkaXI9JyR7ZGF0YXJvb3RkaXJ9L2xv
Y2FsZScKK21hbmRpcj0nJHtkYXRhcm9vdGRpcn0vbWFuJworCithY19wcmV2PQorYWNfZGFzaGRh
c2g9Citmb3IgYWNfb3B0aW9uCitkbworICAjIElmIHRoZSBwcmV2aW91cyBvcHRpb24gbmVlZHMg
YW4gYXJndW1lbnQsIGFzc2lnbiBpdC4KKyAgaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisg
ICAgZXZhbCAkYWNfcHJldj1cJGFjX29wdGlvbgorICAgIGFjX3ByZXY9CisgICAgY29udGludWUK
KyAgZmkKKworICBjYXNlICRhY19vcHRpb24gaW4KKyAgKj0/KikgYWNfb3B0YXJnPWBleHByICJY
JGFjX29wdGlvbiIgOiAnW149XSo9XCguKlwpJ2AgOzsKKyAgKj0pICAgYWNfb3B0YXJnPSA7Owor
ICAqKSAgICBhY19vcHRhcmc9eWVzIDs7CisgIGVzYWMKKworICAjIEFjY2VwdCB0aGUgaW1wb3J0
YW50IEN5Z251cyBjb25maWd1cmUgb3B0aW9ucywgc28gd2UgY2FuIGRpYWdub3NlIHR5cG9zLgor
CisgIGNhc2UgJGFjX2Rhc2hkYXNoJGFjX29wdGlvbiBpbgorICAtLSkKKyAgICBhY19kYXNoZGFz
aD15ZXMgOzsKKworICAtYmluZGlyIHwgLS1iaW5kaXIgfCAtLWJpbmRpIHwgLS1iaW5kIHwgLS1i
aW4gfCAtLWJpKQorICAgIGFjX3ByZXY9YmluZGlyIDs7CisgIC1iaW5kaXI9KiB8IC0tYmluZGly
PSogfCAtLWJpbmRpPSogfCAtLWJpbmQ9KiB8IC0tYmluPSogfCAtLWJpPSopCisgICAgYmluZGly
PSRhY19vcHRhcmcgOzsKKworICAtYnVpbGQgfCAtLWJ1aWxkIHwgLS1idWlsIHwgLS1idWkgfCAt
LWJ1KQorICAgIGFjX3ByZXY9YnVpbGRfYWxpYXMgOzsKKyAgLWJ1aWxkPSogfCAtLWJ1aWxkPSog
fCAtLWJ1aWw9KiB8IC0tYnVpPSogfCAtLWJ1PSopCisgICAgYnVpbGRfYWxpYXM9JGFjX29wdGFy
ZyA7OworCisgIC1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWxlIHwgLS1jYWNoZS1maWwgfCAtLWNh
Y2hlLWZpIFwKKyAgfCAtLWNhY2hlLWYgfCAtLWNhY2hlLSB8IC0tY2FjaGUgfCAtLWNhY2ggfCAt
LWNhYyB8IC0tY2EgfCAtLWMpCisgICAgYWNfcHJldj1jYWNoZV9maWxlIDs7CisgIC1jYWNoZS1m
aWxlPSogfCAtLWNhY2hlLWZpbGU9KiB8IC0tY2FjaGUtZmlsPSogfCAtLWNhY2hlLWZpPSogXAor
ICB8IC0tY2FjaGUtZj0qIHwgLS1jYWNoZS09KiB8IC0tY2FjaGU9KiB8IC0tY2FjaD0qIHwgLS1j
YWM9KiB8IC0tY2E9KiB8IC0tYz0qKQorICAgIGNhY2hlX2ZpbGU9JGFjX29wdGFyZyA7OworCisg
IC0tY29uZmlnLWNhY2hlIHwgLUMpCisgICAgY2FjaGVfZmlsZT1jb25maWcuY2FjaGUgOzsKKwor
ICAtZGF0YWRpciB8IC0tZGF0YWRpciB8IC0tZGF0YWRpIHwgLS1kYXRhZCkKKyAgICBhY19wcmV2
PWRhdGFkaXIgOzsKKyAgLWRhdGFkaXI9KiB8IC0tZGF0YWRpcj0qIHwgLS1kYXRhZGk9KiB8IC0t
ZGF0YWQ9KikKKyAgICBkYXRhZGlyPSRhY19vcHRhcmcgOzsKKworICAtZGF0YXJvb3RkaXIgfCAt
LWRhdGFyb290ZGlyIHwgLS1kYXRhcm9vdGRpIHwgLS1kYXRhcm9vdGQgfCAtLWRhdGFyb290IFwK
KyAgfCAtLWRhdGFyb28gfCAtLWRhdGFybyB8IC0tZGF0YXIpCisgICAgYWNfcHJldj1kYXRhcm9v
dGRpciA7OworICAtZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3RkaXI9KiB8IC0tZGF0YXJvb3Rk
aT0qIHwgLS1kYXRhcm9vdGQ9KiBcCisgIHwgLS1kYXRhcm9vdD0qIHwgLS1kYXRhcm9vPSogfCAt
LWRhdGFybz0qIHwgLS1kYXRhcj0qKQorICAgIGRhdGFyb290ZGlyPSRhY19vcHRhcmcgOzsKKwor
ICAtZGlzYWJsZS0qIHwgLS1kaXNhYmxlLSopCisgICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19v
cHRpb24iIDogJ3gtKmRpc2FibGUtXCguKlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFy
ZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0
IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vy
cm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUgbmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9w
dF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0
IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAg
KiIKKyJlbmFibGVfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXpl
ZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZGlzYWJs
ZS0kYWNfdXNlcm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVz
YWMKKyAgICBldmFsIGVuYWJsZV8kYWNfdXNlcm9wdD1ubyA7OworCisgIC1kb2NkaXIgfCAtLWRv
Y2RpciB8IC0tZG9jZGkgfCAtLWRvYyB8IC0tZG8pCisgICAgYWNfcHJldj1kb2NkaXIgOzsKKyAg
LWRvY2Rpcj0qIHwgLS1kb2NkaXI9KiB8IC0tZG9jZGk9KiB8IC0tZG9jPSogfCAtLWRvPSopCisg
ICAgZG9jZGlyPSRhY19vcHRhcmcgOzsKKworICAtZHZpZGlyIHwgLS1kdmlkaXIgfCAtLWR2aWRp
IHwgLS1kdmlkIHwgLS1kdmkgfCAtLWR2KQorICAgIGFjX3ByZXY9ZHZpZGlyIDs7CisgIC1kdmlk
aXI9KiB8IC0tZHZpZGlyPSogfCAtLWR2aWRpPSogfCAtLWR2aWQ9KiB8IC0tZHZpPSogfCAtLWR2
PSopCisgICAgZHZpZGlyPSRhY19vcHRhcmcgOzsKKworICAtZW5hYmxlLSogfCAtLWVuYWJsZS0q
KQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSplbmFibGUtXChbXj1d
KlwpJ2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFi
bGUgbmFtZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51
bV0iID4vZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGZlYXR1cmUg
bmFtZTogJGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAg
YWNfdXNlcm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAor
ICAgIGNhc2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJlbmFibGVfJGFjX3VzZXJvcHQi
CisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIkYWNfdW5yZWNvZ25pemVk
X29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0tZW5hYmxlLSRhY191c2Vyb3B0X29yaWciCisJIGFj
X3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAgZXNhYworICAgIGV2YWwgZW5hYmxlXyRhY191
c2Vyb3B0PVwkYWNfb3B0YXJnIDs7CisKKyAgLWV4ZWMtcHJlZml4IHwgLS1leGVjX3ByZWZpeCB8
IC0tZXhlYy1wcmVmaXggfCAtLWV4ZWMtcHJlZmkgXAorICB8IC0tZXhlYy1wcmVmIHwgLS1leGVj
LXByZSB8IC0tZXhlYy1wciB8IC0tZXhlYy1wIHwgLS1leGVjLSBcCisgIHwgLS1leGVjIHwgLS1l
eGUgfCAtLWV4KQorICAgIGFjX3ByZXY9ZXhlY19wcmVmaXggOzsKKyAgLWV4ZWMtcHJlZml4PSog
fCAtLWV4ZWNfcHJlZml4PSogfCAtLWV4ZWMtcHJlZml4PSogfCAtLWV4ZWMtcHJlZmk9KiBcCisg
IHwgLS1leGVjLXByZWY9KiB8IC0tZXhlYy1wcmU9KiB8IC0tZXhlYy1wcj0qIHwgLS1leGVjLXA9
KiB8IC0tZXhlYy09KiBcCisgIHwgLS1leGVjPSogfCAtLWV4ZT0qIHwgLS1leD0qKQorICAgIGV4
ZWNfcHJlZml4PSRhY19vcHRhcmcgOzsKKworICAtZ2FzIHwgLS1nYXMgfCAtLWdhIHwgLS1nKQor
ICAgICMgT2Jzb2xldGU7IHVzZSAtLXdpdGgtZ2FzLgorICAgIHdpdGhfZ2FzPXllcyA7OworCisg
IC1oZWxwIHwgLS1oZWxwIHwgLS1oZWwgfCAtLWhlIHwgLWgpCisgICAgYWNfaW5pdF9oZWxwPWxv
bmcgOzsKKyAgLWhlbHA9ciogfCAtLWhlbHA9ciogfCAtLWhlbD1yKiB8IC0taGU9ciogfCAtaHIq
KQorICAgIGFjX2luaXRfaGVscD1yZWN1cnNpdmUgOzsKKyAgLWhlbHA9cyogfCAtLWhlbHA9cyog
fCAtLWhlbD1zKiB8IC0taGU9cyogfCAtaHMqKQorICAgIGFjX2luaXRfaGVscD1zaG9ydCA7Owor
CisgIC1ob3N0IHwgLS1ob3N0IHwgLS1ob3MgfCAtLWhvKQorICAgIGFjX3ByZXY9aG9zdF9hbGlh
cyA7OworICAtaG9zdD0qIHwgLS1ob3N0PSogfCAtLWhvcz0qIHwgLS1obz0qKQorICAgIGhvc3Rf
YWxpYXM9JGFjX29wdGFyZyA7OworCisgIC1odG1sZGlyIHwgLS1odG1sZGlyIHwgLS1odG1sZGkg
fCAtLWh0bWxkIHwgLS1odG1sIHwgLS1odG0gfCAtLWh0KQorICAgIGFjX3ByZXY9aHRtbGRpciA7
OworICAtaHRtbGRpcj0qIHwgLS1odG1sZGlyPSogfCAtLWh0bWxkaT0qIHwgLS1odG1sZD0qIHwg
LS1odG1sPSogfCAtLWh0bT0qIFwKKyAgfCAtLWh0PSopCisgICAgaHRtbGRpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaXIgfCAtLWluY2x1ZGVkaSB8IC0taW5j
bHVkZWQgfCAtLWluY2x1ZGUgXAorICB8IC0taW5jbHVkIHwgLS1pbmNsdSB8IC0taW5jbCB8IC0t
aW5jKQorICAgIGFjX3ByZXY9aW5jbHVkZWRpciA7OworICAtaW5jbHVkZWRpcj0qIHwgLS1pbmNs
dWRlZGlyPSogfCAtLWluY2x1ZGVkaT0qIHwgLS1pbmNsdWRlZD0qIHwgLS1pbmNsdWRlPSogXAor
ICB8IC0taW5jbHVkPSogfCAtLWluY2x1PSogfCAtLWluY2w9KiB8IC0taW5jPSopCisgICAgaW5j
bHVkZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWluZm9kaXIgfCAtLWluZm9kaXIgfCAtLWluZm9k
aSB8IC0taW5mb2QgfCAtLWluZm8gfCAtLWluZikKKyAgICBhY19wcmV2PWluZm9kaXIgOzsKKyAg
LWluZm9kaXI9KiB8IC0taW5mb2Rpcj0qIHwgLS1pbmZvZGk9KiB8IC0taW5mb2Q9KiB8IC0taW5m
bz0qIHwgLS1pbmY9KikKKyAgICBpbmZvZGlyPSRhY19vcHRhcmcgOzsKKworICAtbGliZGlyIHwg
LS1saWJkaXIgfCAtLWxpYmRpIHwgLS1saWJkKQorICAgIGFjX3ByZXY9bGliZGlyIDs7CisgIC1s
aWJkaXI9KiB8IC0tbGliZGlyPSogfCAtLWxpYmRpPSogfCAtLWxpYmQ9KikKKyAgICBsaWJkaXI9
JGFjX29wdGFyZyA7OworCisgIC1saWJleGVjZGlyIHwgLS1saWJleGVjZGlyIHwgLS1saWJleGVj
ZGkgfCAtLWxpYmV4ZWNkIHwgLS1saWJleGVjIFwKKyAgfCAtLWxpYmV4ZSB8IC0tbGliZXggfCAt
LWxpYmUpCisgICAgYWNfcHJldj1saWJleGVjZGlyIDs7CisgIC1saWJleGVjZGlyPSogfCAtLWxp
YmV4ZWNkaXI9KiB8IC0tbGliZXhlY2RpPSogfCAtLWxpYmV4ZWNkPSogfCAtLWxpYmV4ZWM9KiBc
CisgIHwgLS1saWJleGU9KiB8IC0tbGliZXg9KiB8IC0tbGliZT0qKQorICAgIGxpYmV4ZWNkaXI9
JGFjX29wdGFyZyA7OworCisgIC1sb2NhbGVkaXIgfCAtLWxvY2FsZWRpciB8IC0tbG9jYWxlZGkg
fCAtLWxvY2FsZWQgfCAtLWxvY2FsZSkKKyAgICBhY19wcmV2PWxvY2FsZWRpciA7OworICAtbG9j
YWxlZGlyPSogfCAtLWxvY2FsZWRpcj0qIHwgLS1sb2NhbGVkaT0qIHwgLS1sb2NhbGVkPSogfCAt
LWxvY2FsZT0qKQorICAgIGxvY2FsZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWxvY2Fsc3RhdGVk
aXIgfCAtLWxvY2Fsc3RhdGVkaXIgfCAtLWxvY2Fsc3RhdGVkaSB8IC0tbG9jYWxzdGF0ZWQgXAor
ICB8IC0tbG9jYWxzdGF0ZSB8IC0tbG9jYWxzdGF0IHwgLS1sb2NhbHN0YSB8IC0tbG9jYWxzdCB8
IC0tbG9jYWxzKQorICAgIGFjX3ByZXY9bG9jYWxzdGF0ZWRpciA7OworICAtbG9jYWxzdGF0ZWRp
cj0qIHwgLS1sb2NhbHN0YXRlZGlyPSogfCAtLWxvY2Fsc3RhdGVkaT0qIHwgLS1sb2NhbHN0YXRl
ZD0qIFwKKyAgfCAtLWxvY2Fsc3RhdGU9KiB8IC0tbG9jYWxzdGF0PSogfCAtLWxvY2Fsc3RhPSog
fCAtLWxvY2Fsc3Q9KiB8IC0tbG9jYWxzPSopCisgICAgbG9jYWxzdGF0ZWRpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLW1hbmRpciB8IC0tbWFuZGlyIHwgLS1tYW5kaSB8IC0tbWFuZCB8IC0tbWFuIHwg
LS1tYSB8IC0tbSkKKyAgICBhY19wcmV2PW1hbmRpciA7OworICAtbWFuZGlyPSogfCAtLW1hbmRp
cj0qIHwgLS1tYW5kaT0qIHwgLS1tYW5kPSogfCAtLW1hbj0qIHwgLS1tYT0qIHwgLS1tPSopCisg
ICAgbWFuZGlyPSRhY19vcHRhcmcgOzsKKworICAtbmZwIHwgLS1uZnAgfCAtLW5mKQorICAgICMg
T2Jzb2xldGU7IHVzZSAtLXdpdGhvdXQtZnAuCisgICAgd2l0aF9mcD1ubyA7OworCisgIC1uby1j
cmVhdGUgfCAtLW5vLWNyZWF0ZSB8IC0tbm8tY3JlYXQgfCAtLW5vLWNyZWEgfCAtLW5vLWNyZSBc
CisgIHwgLS1uby1jciB8IC0tbm8tYyB8IC1uKQorICAgIG5vX2NyZWF0ZT15ZXMgOzsKKworICAt
bm8tcmVjdXJzaW9uIHwgLS1uby1yZWN1cnNpb24gfCAtLW5vLXJlY3Vyc2lvIHwgLS1uby1yZWN1
cnNpIFwKKyAgfCAtLW5vLXJlY3VycyB8IC0tbm8tcmVjdXIgfCAtLW5vLXJlY3UgfCAtLW5vLXJl
YyB8IC0tbm8tcmUgfCAtLW5vLXIpCisgICAgbm9fcmVjdXJzaW9uPXllcyA7OworCisgIC1vbGRp
bmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRlZGlyIHwgLS1vbGRpbmNsdWRlZGkgfCAtLW9sZGluY2x1
ZGVkIFwKKyAgfCAtLW9sZGluY2x1ZGUgfCAtLW9sZGluY2x1ZCB8IC0tb2xkaW5jbHUgfCAtLW9s
ZGluY2wgfCAtLW9sZGluYyBcCisgIHwgLS1vbGRpbiB8IC0tb2xkaSB8IC0tb2xkIHwgLS1vbCB8
IC0tbykKKyAgICBhY19wcmV2PW9sZGluY2x1ZGVkaXIgOzsKKyAgLW9sZGluY2x1ZGVkaXI9KiB8
IC0tb2xkaW5jbHVkZWRpcj0qIHwgLS1vbGRpbmNsdWRlZGk9KiB8IC0tb2xkaW5jbHVkZWQ9KiBc
CisgIHwgLS1vbGRpbmNsdWRlPSogfCAtLW9sZGluY2x1ZD0qIHwgLS1vbGRpbmNsdT0qIHwgLS1v
bGRpbmNsPSogfCAtLW9sZGluYz0qIFwKKyAgfCAtLW9sZGluPSogfCAtLW9sZGk9KiB8IC0tb2xk
PSogfCAtLW9sPSogfCAtLW89KikKKyAgICBvbGRpbmNsdWRlZGlyPSRhY19vcHRhcmcgOzsKKwor
ICAtcHJlZml4IHwgLS1wcmVmaXggfCAtLXByZWZpIHwgLS1wcmVmIHwgLS1wcmUgfCAtLXByIHwg
LS1wKQorICAgIGFjX3ByZXY9cHJlZml4IDs7CisgIC1wcmVmaXg9KiB8IC0tcHJlZml4PSogfCAt
LXByZWZpPSogfCAtLXByZWY9KiB8IC0tcHJlPSogfCAtLXByPSogfCAtLXA9KikKKyAgICBwcmVm
aXg9JGFjX29wdGFyZyA7OworCisgIC1wcm9ncmFtLXByZWZpeCB8IC0tcHJvZ3JhbS1wcmVmaXgg
fCAtLXByb2dyYW0tcHJlZmkgfCAtLXByb2dyYW0tcHJlZiBcCisgIHwgLS1wcm9ncmFtLXByZSB8
IC0tcHJvZ3JhbS1wciB8IC0tcHJvZ3JhbS1wKQorICAgIGFjX3ByZXY9cHJvZ3JhbV9wcmVmaXgg
OzsKKyAgLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0tcHJlZml4PSogfCAtLXByb2dyYW0t
cHJlZmk9KiBcCisgIHwgLS1wcm9ncmFtLXByZWY9KiB8IC0tcHJvZ3JhbS1wcmU9KiB8IC0tcHJv
Z3JhbS1wcj0qIHwgLS1wcm9ncmFtLXA9KikKKyAgICBwcm9ncmFtX3ByZWZpeD0kYWNfb3B0YXJn
IDs7CisKKyAgLXByb2dyYW0tc3VmZml4IHwgLS1wcm9ncmFtLXN1ZmZpeCB8IC0tcHJvZ3JhbS1z
dWZmaSB8IC0tcHJvZ3JhbS1zdWZmIFwKKyAgfCAtLXByb2dyYW0tc3VmIHwgLS1wcm9ncmFtLXN1
IHwgLS1wcm9ncmFtLXMpCisgICAgYWNfcHJldj1wcm9ncmFtX3N1ZmZpeCA7OworICAtcHJvZ3Jh
bS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaXg9KiB8IC0tcHJvZ3JhbS1zdWZmaT0qIFwKKyAg
fCAtLXByb2dyYW0tc3VmZj0qIHwgLS1wcm9ncmFtLXN1Zj0qIHwgLS1wcm9ncmFtLXN1PSogfCAt
LXByb2dyYW0tcz0qKQorICAgIHByb2dyYW1fc3VmZml4PSRhY19vcHRhcmcgOzsKKworICAtcHJv
Z3JhbS10cmFuc2Zvcm0tbmFtZSB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZSBcCisgIHwgLS1w
cm9ncmFtLXRyYW5zZm9ybS1uYW0gfCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hIFwKKyAgfCAtLXBy
b2dyYW0tdHJhbnNmb3JtLW4gfCAtLXByb2dyYW0tdHJhbnNmb3JtLSBcCisgIHwgLS1wcm9ncmFt
LXRyYW5zZm9ybSB8IC0tcHJvZ3JhbS10cmFuc2ZvciBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm8g
fCAtLXByb2dyYW0tdHJhbnNmIFwKKyAgfCAtLXByb2dyYW0tdHJhbnMgfCAtLXByb2dyYW0tdHJh
biBcCisgIHwgLS1wcm9nci10cmEgfCAtLXByb2dyYW0tdHIgfCAtLXByb2dyYW0tdCkKKyAgICBh
Y19wcmV2PXByb2dyYW1fdHJhbnNmb3JtX25hbWUgOzsKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5h
bWU9KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFtZT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNm
b3JtLW5hbT0qIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYT0qIFwKKyAgfCAtLXByb2dyYW0tdHJh
bnNmb3JtLW49KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tPSogXAorICB8IC0tcHJvZ3JhbS10cmFu
c2Zvcm09KiB8IC0tcHJvZ3JhbS10cmFuc2Zvcj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmbz0q
IHwgLS1wcm9ncmFtLXRyYW5zZj0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnM9KiB8IC0tcHJvZ3Jh
bS10cmFuPSogXAorICB8IC0tcHJvZ3ItdHJhPSogfCAtLXByb2dyYW0tdHI9KiB8IC0tcHJvZ3Jh
bS10PSopCisgICAgcHJvZ3JhbV90cmFuc2Zvcm1fbmFtZT0kYWNfb3B0YXJnIDs7CisKKyAgLXBk
ZmRpciB8IC0tcGRmZGlyIHwgLS1wZGZkaSB8IC0tcGRmZCB8IC0tcGRmIHwgLS1wZCkKKyAgICBh
Y19wcmV2PXBkZmRpciA7OworICAtcGRmZGlyPSogfCAtLXBkZmRpcj0qIHwgLS1wZGZkaT0qIHwg
LS1wZGZkPSogfCAtLXBkZj0qIHwgLS1wZD0qKQorICAgIHBkZmRpcj0kYWNfb3B0YXJnIDs7CisK
KyAgLXBzZGlyIHwgLS1wc2RpciB8IC0tcHNkaSB8IC0tcHNkIHwgLS1wcykKKyAgICBhY19wcmV2
PXBzZGlyIDs7CisgIC1wc2Rpcj0qIHwgLS1wc2Rpcj0qIHwgLS1wc2RpPSogfCAtLXBzZD0qIHwg
LS1wcz0qKQorICAgIHBzZGlyPSRhY19vcHRhcmcgOzsKKworICAtcSB8IC1xdWlldCB8IC0tcXVp
ZXQgfCAtLXF1aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVu
dCB8IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCkKKyAgICBzaWxlbnQ9eWVzIDs7CisKKyAgLXNi
aW5kaXIgfCAtLXNiaW5kaXIgfCAtLXNiaW5kaSB8IC0tc2JpbmQgfCAtLXNiaW4gfCAtLXNiaSB8
IC0tc2IpCisgICAgYWNfcHJldj1zYmluZGlyIDs7CisgIC1zYmluZGlyPSogfCAtLXNiaW5kaXI9
KiB8IC0tc2JpbmRpPSogfCAtLXNiaW5kPSogfCAtLXNiaW49KiBcCisgIHwgLS1zYmk9KiB8IC0t
c2I9KikKKyAgICBzYmluZGlyPSRhY19vcHRhcmcgOzsKKworICAtc2hhcmVkc3RhdGVkaXIgfCAt
LXNoYXJlZHN0YXRlZGlyIHwgLS1zaGFyZWRzdGF0ZWRpIFwKKyAgfCAtLXNoYXJlZHN0YXRlZCB8
IC0tc2hhcmVkc3RhdGUgfCAtLXNoYXJlZHN0YXQgfCAtLXNoYXJlZHN0YSBcCisgIHwgLS1zaGFy
ZWRzdCB8IC0tc2hhcmVkcyB8IC0tc2hhcmVkIHwgLS1zaGFyZSB8IC0tc2hhciBcCisgIHwgLS1z
aGEgfCAtLXNoKQorICAgIGFjX3ByZXY9c2hhcmVkc3RhdGVkaXIgOzsKKyAgLXNoYXJlZHN0YXRl
ZGlyPSogfCAtLXNoYXJlZHN0YXRlZGlyPSogfCAtLXNoYXJlZHN0YXRlZGk9KiBcCisgIHwgLS1z
aGFyZWRzdGF0ZWQ9KiB8IC0tc2hhcmVkc3RhdGU9KiB8IC0tc2hhcmVkc3RhdD0qIHwgLS1zaGFy
ZWRzdGE9KiBcCisgIHwgLS1zaGFyZWRzdD0qIHwgLS1zaGFyZWRzPSogfCAtLXNoYXJlZD0qIHwg
LS1zaGFyZT0qIHwgLS1zaGFyPSogXAorICB8IC0tc2hhPSogfCAtLXNoPSopCisgICAgc2hhcmVk
c3RhdGVkaXI9JGFjX29wdGFyZyA7OworCisgIC1zaXRlIHwgLS1zaXRlIHwgLS1zaXQpCisgICAg
YWNfcHJldj1zaXRlIDs7CisgIC1zaXRlPSogfCAtLXNpdGU9KiB8IC0tc2l0PSopCisgICAgc2l0
ZT0kYWNfb3B0YXJnIDs7CisKKyAgLXNyY2RpciB8IC0tc3JjZGlyIHwgLS1zcmNkaSB8IC0tc3Jj
ZCB8IC0tc3JjIHwgLS1zcikKKyAgICBhY19wcmV2PXNyY2RpciA7OworICAtc3JjZGlyPSogfCAt
LXNyY2Rpcj0qIHwgLS1zcmNkaT0qIHwgLS1zcmNkPSogfCAtLXNyYz0qIHwgLS1zcj0qKQorICAg
IHNyY2Rpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXN5c2NvbmZkaXIgfCAtLXN5c2NvbmZkaXIgfCAt
LXN5c2NvbmZkaSB8IC0tc3lzY29uZmQgfCAtLXN5c2NvbmYgXAorICB8IC0tc3lzY29uIHwgLS1z
eXNjbyB8IC0tc3lzYyB8IC0tc3lzIHwgLS1zeSkKKyAgICBhY19wcmV2PXN5c2NvbmZkaXIgOzsK
KyAgLXN5c2NvbmZkaXI9KiB8IC0tc3lzY29uZmRpcj0qIHwgLS1zeXNjb25mZGk9KiB8IC0tc3lz
Y29uZmQ9KiB8IC0tc3lzY29uZj0qIFwKKyAgfCAtLXN5c2Nvbj0qIHwgLS1zeXNjbz0qIHwgLS1z
eXNjPSogfCAtLXN5cz0qIHwgLS1zeT0qKQorICAgIHN5c2NvbmZkaXI9JGFjX29wdGFyZyA7Owor
CisgIC10YXJnZXQgfCAtLXRhcmdldCB8IC0tdGFyZ2UgfCAtLXRhcmcgfCAtLXRhciB8IC0tdGEg
fCAtLXQpCisgICAgYWNfcHJldj10YXJnZXRfYWxpYXMgOzsKKyAgLXRhcmdldD0qIHwgLS10YXJn
ZXQ9KiB8IC0tdGFyZ2U9KiB8IC0tdGFyZz0qIHwgLS10YXI9KiB8IC0tdGE9KiB8IC0tdD0qKQor
ICAgIHRhcmdldF9hbGlhcz0kYWNfb3B0YXJnIDs7CisKKyAgLXYgfCAtdmVyYm9zZSB8IC0tdmVy
Ym9zZSB8IC0tdmVyYm9zIHwgLS12ZXJibyB8IC0tdmVyYikKKyAgICB2ZXJib3NlPXllcyA7Owor
CisgIC12ZXJzaW9uIHwgLS12ZXJzaW9uIHwgLS12ZXJzaW8gfCAtLXZlcnNpIHwgLS12ZXJzIHwg
LVYpCisgICAgYWNfaW5pdF92ZXJzaW9uPTogOzsKKworICAtd2l0aC0qIHwgLS13aXRoLSopCisg
ICAgYWNfdXNlcm9wdD1gZXhwciAieCRhY19vcHRpb24iIDogJ3gtKndpdGgtXChbXj1dKlwpJ2AK
KyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFyaWFibGUgbmFt
ZXMuCisgICAgZXhwciAieCRhY191c2Vyb3B0IiA6ICIuKlteLSsuXyRhc19jcl9hbG51bV0iID4v
ZGV2L251bGwgJiYKKyAgICAgIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHBhY2thZ2UgbmFtZTog
JGFjX3VzZXJvcHQiCisgICAgYWNfdXNlcm9wdF9vcmlnPSRhY191c2Vyb3B0CisgICAgYWNfdXNl
cm9wdD1gJGFzX2VjaG8gIiRhY191c2Vyb3B0IiB8IHNlZCAncy9bLSsuXS9fL2cnYAorICAgIGNh
c2UgJGFjX3VzZXJfb3B0cyBpbgorICAgICAgKiIKKyJ3aXRoXyRhY191c2Vyb3B0IgorIiopIDs7
CisgICAgICAqKSBhY191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFj
X3VucmVjb2duaXplZF9zZXAtLXdpdGgtJGFjX3VzZXJvcHRfb3JpZyIKKwkgYWNfdW5yZWNvZ25p
emVkX3NlcD0nLCAnOzsKKyAgICBlc2FjCisgICAgZXZhbCB3aXRoXyRhY191c2Vyb3B0PVwkYWNf
b3B0YXJnIDs7CisKKyAgLXdpdGhvdXQtKiB8IC0td2l0aG91dC0qKQorICAgIGFjX3VzZXJvcHQ9
YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSp3aXRob3V0LVwoLipcKSdgCisgICAgIyBSZWplY3Qg
bmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIg
IngkYWNfdXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisg
ICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0Igor
ICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hv
ICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29w
dHMgaW4KKyAgICAgICoiCisid2l0aF8kYWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNf
dW5yZWNvZ25pemVkX29wdHM9IiRhY191bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRf
c2VwLS13aXRob3V0LSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9Jywg
Jzs7CisgICAgZXNhYworICAgIGV2YWwgd2l0aF8kYWNfdXNlcm9wdD1ubyA7OworCisgIC0teCkK
KyAgICAjIE9ic29sZXRlOyB1c2UgLS13aXRoLXguCisgICAgd2l0aF94PXllcyA7OworCisgIC14
LWluY2x1ZGVzIHwgLS14LWluY2x1ZGVzIHwgLS14LWluY2x1ZGUgfCAtLXgtaW5jbHVkIHwgLS14
LWluY2x1IFwKKyAgfCAtLXgtaW5jbCB8IC0teC1pbmMgfCAtLXgtaW4gfCAtLXgtaSkKKyAgICBh
Y19wcmV2PXhfaW5jbHVkZXMgOzsKKyAgLXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlcz0qIHwg
LS14LWluY2x1ZGU9KiB8IC0teC1pbmNsdWQ9KiB8IC0teC1pbmNsdT0qIFwKKyAgfCAtLXgtaW5j
bD0qIHwgLS14LWluYz0qIHwgLS14LWluPSogfCAtLXgtaT0qKQorICAgIHhfaW5jbHVkZXM9JGFj
X29wdGFyZyA7OworCisgIC14LWxpYnJhcmllcyB8IC0teC1saWJyYXJpZXMgfCAtLXgtbGlicmFy
aWUgfCAtLXgtbGlicmFyaSBcCisgIHwgLS14LWxpYnJhciB8IC0teC1saWJyYSB8IC0teC1saWJy
IHwgLS14LWxpYiB8IC0teC1saSB8IC0teC1sKQorICAgIGFjX3ByZXY9eF9saWJyYXJpZXMgOzsK
KyAgLXgtbGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWVzPSogfCAtLXgtbGlicmFyaWU9KiB8IC0t
eC1saWJyYXJpPSogXAorICB8IC0teC1saWJyYXI9KiB8IC0teC1saWJyYT0qIHwgLS14LWxpYnI9
KiB8IC0teC1saWI9KiB8IC0teC1saT0qIHwgLS14LWw9KikKKyAgICB4X2xpYnJhcmllcz0kYWNf
b3B0YXJnIDs7CisKKyAgLSopIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6ZWQgb3B0aW9uOiBc
YCRhY19vcHRpb24nCitUcnkgXGAkMCAtLWhlbHAnIGZvciBtb3JlIGluZm9ybWF0aW9uIgorICAg
IDs7CisKKyAgKj0qKQorICAgIGFjX2VudnZhcj1gZXhwciAieCRhY19vcHRpb24iIDogJ3hcKFte
PV0qXCk9J2AKKyAgICAjIFJlamVjdCBuYW1lcyB0aGF0IGFyZSBub3QgdmFsaWQgc2hlbGwgdmFy
aWFibGUgbmFtZXMuCisgICAgY2FzZSAkYWNfZW52dmFyIGluICMoCisgICAgICAnJyB8IFswLTld
KiB8ICpbIV8kYXNfY3JfYWxudW1dKiApCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2
YXJpYWJsZSBuYW1lOiBcYCRhY19lbnZ2YXInIiA7OworICAgIGVzYWMKKyAgICBldmFsICRhY19l
bnZ2YXI9XCRhY19vcHRhcmcKKyAgICBleHBvcnQgJGFjX2VudnZhciA7OworCisgICopCisgICAg
IyBGSVhNRTogc2hvdWxkIGJlIHJlbW92ZWQgaW4gYXV0b2NvbmYgMy4wLgorICAgICRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHlvdSBzaG91bGQgdXNlIC0tYnVpbGQsIC0taG9zdCwgLS10YXJn
ZXQiID4mMgorICAgIGV4cHIgIngkYWNfb3B0aW9uIiA6ICIuKlteLS5fJGFzX2NyX2FsbnVtXSIg
Pi9kZXYvbnVsbCAmJgorICAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaW52YWxpZCBo
b3N0IHR5cGU6ICRhY19vcHRpb24iID4mMgorICAgIDogIiR7YnVpbGRfYWxpYXM9JGFjX29wdGlv
bn0gJHtob3N0X2FsaWFzPSRhY19vcHRpb259ICR7dGFyZ2V0X2FsaWFzPSRhY19vcHRpb259Igor
ICAgIDs7CisKKyAgZXNhYworZG9uZQorCitpZiB0ZXN0IC1uICIkYWNfcHJldiI7IHRoZW4KKyAg
YWNfb3B0aW9uPS0tYGVjaG8gJGFjX3ByZXYgfCBzZWQgJ3MvXy8tL2cnYAorICBhc19mbl9lcnJv
ciAkPyAibWlzc2luZyBhcmd1bWVudCB0byAkYWNfb3B0aW9uIgorZmkKKworaWYgdGVzdCAtbiAi
JGFjX3VucmVjb2duaXplZF9vcHRzIjsgdGhlbgorICBjYXNlICRlbmFibGVfb3B0aW9uX2NoZWNr
aW5nIGluCisgICAgbm8pIDs7CisgICAgZmF0YWwpIGFzX2ZuX2Vycm9yICQ/ICJ1bnJlY29nbml6
ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXplZF9vcHRzIiA7OworICAgICopICAgICAkYXNfZWNo
byAiJGFzX21lOiBXQVJOSU5HOiB1bnJlY29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXpl
ZF9vcHRzIiA+JjIgOzsKKyAgZXNhYworZmkKKworIyBDaGVjayBhbGwgZGlyZWN0b3J5IGFyZ3Vt
ZW50cyBmb3IgY29uc2lzdGVuY3kuCitmb3IgYWNfdmFyIGluCWV4ZWNfcHJlZml4IHByZWZpeCBi
aW5kaXIgc2JpbmRpciBsaWJleGVjZGlyIGRhdGFyb290ZGlyIFwKKwkJZGF0YWRpciBzeXNjb25m
ZGlyIHNoYXJlZHN0YXRlZGlyIGxvY2Fsc3RhdGVkaXIgaW5jbHVkZWRpciBcCisJCW9sZGluY2x1
ZGVkaXIgZG9jZGlyIGluZm9kaXIgaHRtbGRpciBkdmlkaXIgcGRmZGlyIHBzZGlyIFwKKwkJbGli
ZGlyIGxvY2FsZWRpciBtYW5kaXIKK2RvCisgIGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAjIFJl
bW92ZSB0cmFpbGluZyBzbGFzaGVzLgorICBjYXNlICRhY192YWwgaW4KKyAgICAqLyApCisgICAg
ICBhY192YWw9YGV4cHIgIlgkYWNfdmFsIiA6ICdYXCguKlteL11cKScgXHwgIlgkYWNfdmFsIiA6
ICdYXCguKlwpJ2AKKyAgICAgIGV2YWwgJGFjX3Zhcj1cJGFjX3ZhbDs7CisgIGVzYWMKKyAgIyBC
ZSBzdXJlIHRvIGhhdmUgYWJzb2x1dGUgZGlyZWN0b3J5IG5hbWVzLgorICBjYXNlICRhY192YWwg
aW4KKyAgICBbXFwvJF0qIHwgPzpbXFwvXSogKSAgY29udGludWU7OworICAgIE5PTkUgfCAnJyAp
IGNhc2UgJGFjX3ZhciBpbiAqcHJlZml4ICkgY29udGludWU7OyBlc2FjOzsKKyAgZXNhYworICBh
c19mbl9lcnJvciAkPyAiZXhwZWN0ZWQgYW4gYWJzb2x1dGUgZGlyZWN0b3J5IG5hbWUgZm9yIC0t
JGFjX3ZhcjogJGFjX3ZhbCIKK2RvbmUKKworIyBUaGVyZSBtaWdodCBiZSBwZW9wbGUgd2hvIGRl
cGVuZCBvbiB0aGUgb2xkIGJyb2tlbiBiZWhhdmlvcjogYCRob3N0JworIyB1c2VkIHRvIGhvbGQg
dGhlIGFyZ3VtZW50IG9mIC0taG9zdCBldGMuCisjIEZJWE1FOiBUbyByZW1vdmUgc29tZSBkYXku
CitidWlsZD0kYnVpbGRfYWxpYXMKK2hvc3Q9JGhvc3RfYWxpYXMKK3RhcmdldD0kdGFyZ2V0X2Fs
aWFzCisKKyMgRklYTUU6IFRvIHJlbW92ZSBzb21lIGRheS4KK2lmIHRlc3QgIngkaG9zdF9hbGlh
cyIgIT0geDsgdGhlbgorICBpZiB0ZXN0ICJ4JGJ1aWxkX2FsaWFzIiA9IHg7IHRoZW4KKyAgICBj
cm9zc19jb21waWxpbmc9bWF5YmUKKyAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBpZiB5
b3Ugd2FudGVkIHRvIHNldCB0aGUgLS1idWlsZCB0eXBlLCBkb24ndCB1c2UgLS1ob3N0LgorICAg
IElmIGEgY3Jvc3MgY29tcGlsZXIgaXMgZGV0ZWN0ZWQgdGhlbiBjcm9zcyBjb21waWxlIG1vZGUg
d2lsbCBiZSB1c2VkIiA+JjIKKyAgZWxpZiB0ZXN0ICJ4JGJ1aWxkX2FsaWFzIiAhPSAieCRob3N0
X2FsaWFzIjsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGluZz15ZXMKKyAgZmkKK2ZpCisKK2FjX3Rv
b2xfcHJlZml4PQordGVzdCAtbiAiJGhvc3RfYWxpYXMiICYmIGFjX3Rvb2xfcHJlZml4PSRob3N0
X2FsaWFzLQorCit0ZXN0ICIkc2lsZW50IiA9IHllcyAmJiBleGVjIDY+L2Rldi9udWxsCisKKwor
YWNfcHdkPWBwd2RgICYmIHRlc3QgLW4gIiRhY19wd2QiICYmCithY19sc19kaT1gbHMgLWRpIC5g
ICYmCithY19wd2RfbHNfZGk9YGNkICIkYWNfcHdkIiAmJiBscyAtZGkgLmAgfHwKKyAgYXNfZm5f
ZXJyb3IgJD8gIndvcmtpbmcgZGlyZWN0b3J5IGNhbm5vdCBiZSBkZXRlcm1pbmVkIgordGVzdCAi
WCRhY19sc19kaSIgPSAiWCRhY19wd2RfbHNfZGkiIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJwd2Qg
ZG9lcyBub3QgcmVwb3J0IG5hbWUgb2Ygd29ya2luZyBkaXJlY3RvcnkiCisKKworIyBGaW5kIHRo
ZSBzb3VyY2UgZmlsZXMsIGlmIGxvY2F0aW9uIHdhcyBub3Qgc3BlY2lmaWVkLgoraWYgdGVzdCAt
eiAiJHNyY2RpciI7IHRoZW4KKyAgYWNfc3JjZGlyX2RlZmF1bHRlZD15ZXMKKyAgIyBUcnkgdGhl
IGRpcmVjdG9yeSBjb250YWluaW5nIHRoaXMgc2NyaXB0LCB0aGVuIHRoZSBwYXJlbnQgZGlyZWN0
b3J5LgorICBhY19jb25mZGlyPWAkYXNfZGlybmFtZSAtLSAiJGFzX215c2VsZiIgfHwKKyRhc19l
eHByIFgiJGFzX215c2VsZiIgOiAnWFwoLipbXi9dXCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkg
WCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wpW14vXScgXHwgXAorCSBYIiRhc19teXNlbGYiIDogJ1hc
KC8vXCkkJyBcfCBcCisJIFgiJGFzX215c2VsZiIgOiAnWFwoL1wpJyBcfCAuIDI+L2Rldi9udWxs
IHx8CiskYXNfZWNobyBYIiRhc19teXNlbGYiIHwKKyAgICBzZWQgJy9eWFwoLipbXi9dXClcL1wv
KlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wv
XClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wvXCkkL3sK
KwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cKS4qL3sKKwkgICAgcy8vXDEv
CisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICBzcmNkaXI9JGFjX2NvbmZkaXIKKyAg
aWYgdGVzdCAhIC1yICIkc3JjZGlyLyRhY191bmlxdWVfZmlsZSI7IHRoZW4KKyAgICBzcmNkaXI9
Li4KKyAgZmkKK2Vsc2UKKyAgYWNfc3JjZGlyX2RlZmF1bHRlZD1ubworZmkKK2lmIHRlc3QgISAt
ciAiJHNyY2Rpci8kYWNfdW5pcXVlX2ZpbGUiOyB0aGVuCisgIHRlc3QgIiRhY19zcmNkaXJfZGVm
YXVsdGVkIiA9IHllcyAmJiBzcmNkaXI9IiRhY19jb25mZGlyIG9yIC4uIgorICBhc19mbl9lcnJv
ciAkPyAiY2Fubm90IGZpbmQgc291cmNlcyAoJGFjX3VuaXF1ZV9maWxlKSBpbiAkc3JjZGlyIgor
ZmkKK2FjX21zZz0ic291cmNlcyBhcmUgaW4gJHNyY2RpciwgYnV0IFxgY2QgJHNyY2RpcicgZG9l
cyBub3Qgd29yayIKK2FjX2Fic19jb25mZGlyPWAoCisJY2QgIiRzcmNkaXIiICYmIHRlc3QgLXIg
Ii4vJGFjX3VuaXF1ZV9maWxlIiB8fCBhc19mbl9lcnJvciAkPyAiJGFjX21zZyIKKwlwd2QpYAor
IyBXaGVuIGJ1aWxkaW5nIGluIHBsYWNlLCBzZXQgc3JjZGlyPS4KK2lmIHRlc3QgIiRhY19hYnNf
Y29uZmRpciIgPSAiJGFjX3B3ZCI7IHRoZW4KKyAgc3JjZGlyPS4KK2ZpCisjIFJlbW92ZSB1bm5l
Y2Vzc2FyeSB0cmFpbGluZyBzbGFzaGVzIGZyb20gc3JjZGlyLgorIyBEb3VibGUgc2xhc2hlcyBp
biBmaWxlIG5hbWVzIGluIG9iamVjdCBmaWxlIGRlYnVnZ2luZyBpbmZvCisjIG1lc3MgdXAgTS14
IGdkYiBpbiBFbWFjcy4KK2Nhc2UgJHNyY2RpciBpbgorKi8pIHNyY2Rpcj1gZXhwciAiWCRzcmNk
aXIiIDogJ1hcKC4qW14vXVwpJyBcfCAiWCRzcmNkaXIiIDogJ1hcKC4qXCknYDs7Citlc2FjCitm
b3IgYWNfdmFyIGluICRhY19wcmVjaW91c192YXJzOyBkbworICBldmFsIGFjX2Vudl8ke2FjX3Zh
cn1fc2V0PVwkeyR7YWNfdmFyfStzZXR9CisgIGV2YWwgYWNfZW52XyR7YWNfdmFyfV92YWx1ZT1c
JCR7YWNfdmFyfQorICBldmFsIGFjX2N2X2Vudl8ke2FjX3Zhcn1fc2V0PVwkeyR7YWNfdmFyfStz
ZXR9CisgIGV2YWwgYWNfY3ZfZW52XyR7YWNfdmFyfV92YWx1ZT1cJCR7YWNfdmFyfQorZG9uZQor
CisjCisjIFJlcG9ydCB0aGUgLS1oZWxwIG1lc3NhZ2UuCisjCitpZiB0ZXN0ICIkYWNfaW5pdF9o
ZWxwIiA9ICJsb25nIjsgdGhlbgorICAjIE9taXQgc29tZSBpbnRlcm5hbCBvciBvYnNvbGV0ZSBv
cHRpb25zIHRvIG1ha2UgdGhlIGxpc3QgbGVzcyBpbXBvc2luZy4KKyAgIyBUaGlzIG1lc3NhZ2Ug
aXMgdG9vIGxvbmcgdG8gYmUgYSBzdHJpbmcgaW4gdGhlIEEvVVggMy4xIHNoLgorICBjYXQgPDxf
QUNFT0YKK1xgY29uZmlndXJlJyBjb25maWd1cmVzIFhlbiBIeXBlcnZpc29yIDQuMiB0byBhZGFw
dCB0byBtYW55IGtpbmRzIG9mIHN5c3RlbXMuCisKK1VzYWdlOiAkMCBbT1BUSU9OXS4uLiBbVkFS
PVZBTFVFXS4uLgorCitUbyBhc3NpZ24gZW52aXJvbm1lbnQgdmFyaWFibGVzIChlLmcuLCBDQywg
Q0ZMQUdTLi4uKSwgc3BlY2lmeSB0aGVtIGFzCitWQVI9VkFMVUUuICBTZWUgYmVsb3cgZm9yIGRl
c2NyaXB0aW9ucyBvZiBzb21lIG9mIHRoZSB1c2VmdWwgdmFyaWFibGVzLgorCitEZWZhdWx0cyBm
b3IgdGhlIG9wdGlvbnMgYXJlIHNwZWNpZmllZCBpbiBicmFja2V0cy4KKworQ29uZmlndXJhdGlv
bjoKKyAgLWgsIC0taGVscCAgICAgICAgICAgICAgZGlzcGxheSB0aGlzIGhlbHAgYW5kIGV4aXQK
KyAgICAgIC0taGVscD1zaG9ydCAgICAgICAgZGlzcGxheSBvcHRpb25zIHNwZWNpZmljIHRvIHRo
aXMgcGFja2FnZQorICAgICAgLS1oZWxwPXJlY3Vyc2l2ZSAgICBkaXNwbGF5IHRoZSBzaG9ydCBo
ZWxwIG9mIGFsbCB0aGUgaW5jbHVkZWQgcGFja2FnZXMKKyAgLVYsIC0tdmVyc2lvbiAgICAgICAg
ICAgZGlzcGxheSB2ZXJzaW9uIGluZm9ybWF0aW9uIGFuZCBleGl0CisgIC1xLCAtLXF1aWV0LCAt
LXNpbGVudCAgIGRvIG5vdCBwcmludCBcYGNoZWNraW5nIC4uLicgbWVzc2FnZXMKKyAgICAgIC0t
Y2FjaGUtZmlsZT1GSUxFICAgY2FjaGUgdGVzdCByZXN1bHRzIGluIEZJTEUgW2Rpc2FibGVkXQor
ICAtQywgLS1jb25maWctY2FjaGUgICAgICBhbGlhcyBmb3IgXGAtLWNhY2hlLWZpbGU9Y29uZmln
LmNhY2hlJworICAtbiwgLS1uby1jcmVhdGUgICAgICAgICBkbyBub3QgY3JlYXRlIG91dHB1dCBm
aWxlcworICAgICAgLS1zcmNkaXI9RElSICAgICAgICBmaW5kIHRoZSBzb3VyY2VzIGluIERJUiBb
Y29uZmlndXJlIGRpciBvciBcYC4uJ10KKworSW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVzOgorICAt
LXByZWZpeD1QUkVGSVggICAgICAgICBpbnN0YWxsIGFyY2hpdGVjdHVyZS1pbmRlcGVuZGVudCBm
aWxlcyBpbiBQUkVGSVgKKyAgICAgICAgICAgICAgICAgICAgICAgICAgWyRhY19kZWZhdWx0X3By
ZWZpeF0KKyAgLS1leGVjLXByZWZpeD1FUFJFRklYICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtZGVw
ZW5kZW50IGZpbGVzIGluIEVQUkVGSVgKKyAgICAgICAgICAgICAgICAgICAgICAgICAgW1BSRUZJ
WF0KKworQnkgZGVmYXVsdCwgXGBtYWtlIGluc3RhbGwnIHdpbGwgaW5zdGFsbCBhbGwgdGhlIGZp
bGVzIGluCitcYCRhY19kZWZhdWx0X3ByZWZpeC9iaW4nLCBcYCRhY19kZWZhdWx0X3ByZWZpeC9s
aWInIGV0Yy4gIFlvdSBjYW4gc3BlY2lmeQorYW4gaW5zdGFsbGF0aW9uIHByZWZpeCBvdGhlciB0
aGFuIFxgJGFjX2RlZmF1bHRfcHJlZml4JyB1c2luZyBcYC0tcHJlZml4JywKK2ZvciBpbnN0YW5j
ZSBcYC0tcHJlZml4PVwkSE9NRScuCisKK0ZvciBiZXR0ZXIgY29udHJvbCwgdXNlIHRoZSBvcHRp
b25zIGJlbG93LgorCitGaW5lIHR1bmluZyBvZiB0aGUgaW5zdGFsbGF0aW9uIGRpcmVjdG9yaWVz
OgorICAtLWJpbmRpcj1ESVIgICAgICAgICAgICB1c2VyIGV4ZWN1dGFibGVzIFtFUFJFRklYL2Jp
bl0KKyAgLS1zYmluZGlyPURJUiAgICAgICAgICAgc3lzdGVtIGFkbWluIGV4ZWN1dGFibGVzIFtF
UFJFRklYL3NiaW5dCisgIC0tbGliZXhlY2Rpcj1ESVIgICAgICAgIHByb2dyYW0gZXhlY3V0YWJs
ZXMgW0VQUkVGSVgvbGliZXhlY10KKyAgLS1zeXNjb25mZGlyPURJUiAgICAgICAgcmVhZC1vbmx5
IHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BSRUZJWC9ldGNdCisgIC0tc2hhcmVkc3RhdGVkaXI9RElS
ICAgIG1vZGlmaWFibGUgYXJjaGl0ZWN0dXJlLWluZGVwZW5kZW50IGRhdGEgW1BSRUZJWC9jb21d
CisgIC0tbG9jYWxzdGF0ZWRpcj1ESVIgICAgIG1vZGlmaWFibGUgc2luZ2xlLW1hY2hpbmUgZGF0
YSBbUFJFRklYL3Zhcl0KKyAgLS1saWJkaXI9RElSICAgICAgICAgICAgb2JqZWN0IGNvZGUgbGli
cmFyaWVzIFtFUFJFRklYL2xpYl0KKyAgLS1pbmNsdWRlZGlyPURJUiAgICAgICAgQyBoZWFkZXIg
ZmlsZXMgW1BSRUZJWC9pbmNsdWRlXQorICAtLW9sZGluY2x1ZGVkaXI9RElSICAgICBDIGhlYWRl
ciBmaWxlcyBmb3Igbm9uLWdjYyBbL3Vzci9pbmNsdWRlXQorICAtLWRhdGFyb290ZGlyPURJUiAg
ICAgICByZWFkLW9ubHkgYXJjaC4taW5kZXBlbmRlbnQgZGF0YSByb290IFtQUkVGSVgvc2hhcmVd
CisgIC0tZGF0YWRpcj1ESVIgICAgICAgICAgIHJlYWQtb25seSBhcmNoaXRlY3R1cmUtaW5kZXBl
bmRlbnQgZGF0YSBbREFUQVJPT1RESVJdCisgIC0taW5mb2Rpcj1ESVIgICAgICAgICAgIGluZm8g
ZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RESVIvaW5mb10KKyAgLS1sb2NhbGVkaXI9RElSICAgICAg
ICAgbG9jYWxlLWRlcGVuZGVudCBkYXRhIFtEQVRBUk9PVERJUi9sb2NhbGVdCisgIC0tbWFuZGly
PURJUiAgICAgICAgICAgIG1hbiBkb2N1bWVudGF0aW9uIFtEQVRBUk9PVERJUi9tYW5dCisgIC0t
ZG9jZGlyPURJUiAgICAgICAgICAgIGRvY3VtZW50YXRpb24gcm9vdCBbREFUQVJPT1RESVIvZG9j
L3hlbi1oeXBlcnZpc29yXQorICAtLWh0bWxkaXI9RElSICAgICAgICAgICBodG1sIGRvY3VtZW50
YXRpb24gW0RPQ0RJUl0KKyAgLS1kdmlkaXI9RElSICAgICAgICAgICAgZHZpIGRvY3VtZW50YXRp
b24gW0RPQ0RJUl0KKyAgLS1wZGZkaXI9RElSICAgICAgICAgICAgcGRmIGRvY3VtZW50YXRpb24g
W0RPQ0RJUl0KKyAgLS1wc2Rpcj1ESVIgICAgICAgICAgICAgcHMgZG9jdW1lbnRhdGlvbiBbRE9D
RElSXQorX0FDRU9GCisKKyAgY2F0IDw8XF9BQ0VPRgorCitTeXN0ZW0gdHlwZXM6CisgIC0tYnVp
bGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBmb3IgYnVpbGRpbmcgb24gQlVJTEQgW2d1ZXNzZWRdCisg
IC0taG9zdD1IT1NUICAgICAgIGNyb3NzLWNvbXBpbGUgdG8gYnVpbGQgcHJvZ3JhbXMgdG8gcnVu
IG9uIEhPU1QgW0JVSUxEXQorX0FDRU9GCitmaQorCitpZiB0ZXN0IC1uICIkYWNfaW5pdF9oZWxw
IjsgdGhlbgorICBjYXNlICRhY19pbml0X2hlbHAgaW4KKyAgICAgc2hvcnQgfCByZWN1cnNpdmUg
KSBlY2hvICJDb25maWd1cmF0aW9uIG9mIFhlbiBIeXBlcnZpc29yIDQuMjoiOzsKKyAgIGVzYWMK
KyAgY2F0IDw8XF9BQ0VPRgorCitPcHRpb25hbCBGZWF0dXJlczoKKyAgLS1kaXNhYmxlLW9wdGlv
bi1jaGVja2luZyAgaWdub3JlIHVucmVjb2duaXplZCAtLWVuYWJsZS8tLXdpdGggb3B0aW9ucwor
ICAtLWRpc2FibGUtRkVBVFVSRSAgICAgICBkbyBub3QgaW5jbHVkZSBGRUFUVVJFIChzYW1lIGFz
IC0tZW5hYmxlLUZFQVRVUkU9bm8pCisgIC0tZW5hYmxlLUZFQVRVUkVbPUFSR10gIGluY2x1ZGUg
RkVBVFVSRSBbQVJHPXllc10KKyAgLS1lbmFibGUteHNtICAgICAgICAgICAgRW5hYmxlIFhTTSBz
ZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKQorICAtLWVuYWJsZS1naXRodHRwICAg
ICAgICBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQCisgIC0tZGlzYWJsZS1tb25p
dG9ycyAgICAgIERpc2FibGUgeGVuc3RhdCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHMKKyAg
LS1lbmFibGUtdnRwbSAgICAgICAgICAgRW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9ybSBN
b2R1bGUKKyAgLS1lbmFibGUteGFwaSAgICAgICAgICAgRW5hYmxlIFhlbiBBUEkgQmluZGluZ3MK
KyAgLS1kaXNhYmxlLXB5dGhvbnRvb2xzICAgRGlzYWJsZSBQeXRob24gdG9vbHMKKyAgLS1kaXNh
YmxlLW9jYW1sdG9vbHMgICAgRGlzYWJsZSBPY2FtbCB0b29scworICAtLWVuYWJsZS1taW5pdGVy
bSAgICAgICBFbmFibGUgbWluaXRlcm0KKyAgLS1lbmFibGUtbG9tb3VudCAgICAgICAgRW5hYmxl
IGxvbW91bnQKKyAgLS1kaXNhYmxlLWRlYnVnICAgICAgICAgRGlzYWJsZSBkZWJ1ZyBidWlsZCBv
ZiBYZW4gYW5kIHRvb2xzCisKK1NvbWUgaW5mbHVlbnRpYWwgZW52aXJvbm1lbnQgdmFyaWFibGVz
OgorICBDQyAgICAgICAgICBDIGNvbXBpbGVyIGNvbW1hbmQKKyAgQ0ZMQUdTICAgICAgQyBjb21w
aWxlciBmbGFncworICBMREZMQUdTICAgICBsaW5rZXIgZmxhZ3MsIGUuZy4gLUw8bGliIGRpcj4g
aWYgeW91IGhhdmUgbGlicmFyaWVzIGluIGEKKyAgICAgICAgICAgICAgbm9uc3RhbmRhcmQgZGly
ZWN0b3J5IDxsaWIgZGlyPgorICBMSUJTICAgICAgICBsaWJyYXJpZXMgdG8gcGFzcyB0byB0aGUg
bGlua2VyLCBlLmcuIC1sPGxpYnJhcnk+CisgIENQUEZMQUdTICAgIChPYmplY3RpdmUpIEMvQysr
IHByZXByb2Nlc3NvciBmbGFncywgZS5nLiAtSTxpbmNsdWRlIGRpcj4gaWYKKyAgICAgICAgICAg
ICAgeW91IGhhdmUgaGVhZGVycyBpbiBhIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8aW5jbHVkZSBk
aXI+CisgIENQUCAgICAgICAgIEMgcHJlcHJvY2Vzc29yCisgIFBSRVBFTkRfSU5DTFVERVMKKyAg
ICAgICAgICAgICAgTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1Mg
KHdpdGhvdXQgLUkpCisgIFBSRVBFTkRfTElCIExpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIHBy
ZXBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCkKKyAgQVBQRU5EX0lOQ0xVREVTCisgICAgICAg
ICAgICAgIExpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhv
dXQgLUkpCisgIEFQUEVORF9MSUIgIExpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFwcGVuZCB0
byBMREZMQUdTICh3aXRob3V0IC1MKQorICBQWVRIT04gICAgICBQYXRoIHRvIHRoZSBQeXRob24g
cGFyc2VyCisgIFBFUkwgICAgICAgIFBhdGggdG8gUGVybCBwYXJzZXIKKyAgQlJDVEwgICAgICAg
UGF0aCB0byBicmN0bCB0b29sCisgIElQICAgICAgICAgIFBhdGggdG8gaXAgdG9vbAorICBCSVNP
TiAgICAgICBQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3IKKyAgRkxFWCAgICAgICAgUGF0
aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9yCisgIENVUkwgICAgICAgIFBhdGgg
dG8gY3VybC1jb25maWcgdG9vbAorICBYTUwgICAgICAgICBQYXRoIHRvIHhtbDItY29uZmlnIHRv
b2wKKyAgQkFTSCAgICAgICAgUGF0aCB0byBiYXNoIHNoZWxsCisgIFhHRVRURVhUICAgIFBhdGgg
dG8geGdldHR0ZXh0IHRvb2wKKyAgUEtHX0NPTkZJRyAgcGF0aCB0byBwa2ctY29uZmlnIHV0aWxp
dHkKKyAgUEtHX0NPTkZJR19QQVRICisgICAgICAgICAgICAgIGRpcmVjdG9yaWVzIHRvIGFkZCB0
byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGgKKyAgUEtHX0NPTkZJR19MSUJESVIKKyAgICAgICAg
ICAgICAgcGF0aCBvdmVycmlkaW5nIHBrZy1jb25maWcncyBidWlsdC1pbiBzZWFyY2ggcGF0aAor
ICBnbGliX0NGTEFHUyBDIGNvbXBpbGVyIGZsYWdzIGZvciBnbGliLCBvdmVycmlkaW5nIHBrZy1j
b25maWcKKyAgZ2xpYl9MSUJTICAgbGlua2VyIGZsYWdzIGZvciBnbGliLCBvdmVycmlkaW5nIHBr
Zy1jb25maWcKKworVXNlIHRoZXNlIHZhcmlhYmxlcyB0byBvdmVycmlkZSB0aGUgY2hvaWNlcyBt
YWRlIGJ5IGBjb25maWd1cmUnIG9yIHRvIGhlbHAKK2l0IHRvIGZpbmQgbGlicmFyaWVzIGFuZCBw
cm9ncmFtcyB3aXRoIG5vbnN0YW5kYXJkIG5hbWVzL2xvY2F0aW9ucy4KKworUmVwb3J0IGJ1Z3Mg
dG8gPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPi4KK19BQ0VPRgorYWNfc3RhdHVzPSQ/
CitmaQorCitpZiB0ZXN0ICIkYWNfaW5pdF9oZWxwIiA9ICJyZWN1cnNpdmUiOyB0aGVuCisgICMg
SWYgdGhlcmUgYXJlIHN1YmRpcnMsIHJlcG9ydCB0aGVpciBzcGVjaWZpYyAtLWhlbHAuCisgIGZv
ciBhY19kaXIgaW4gOiAkYWNfc3ViZGlyc19hbGw7IGRvIHRlc3QgIngkYWNfZGlyIiA9IHg6ICYm
IGNvbnRpbnVlCisgICAgdGVzdCAtZCAiJGFjX2RpciIgfHwKKyAgICAgIHsgY2QgIiRzcmNkaXIi
ICYmIGFjX3B3ZD1gcHdkYCAmJiBzcmNkaXI9LiAmJiB0ZXN0IC1kICIkYWNfZGlyIjsgfSB8fAor
ICAgICAgY29udGludWUKKyAgICBhY19idWlsZGRpcj0uCisKK2Nhc2UgIiRhY19kaXIiIGluCisu
KSBhY19kaXJfc3VmZml4PSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZp
eD0gOzsKKyopCisgIGFjX2Rpcl9zdWZmaXg9L2AkYXNfZWNobyAiJGFjX2RpciIgfCBzZWQgJ3N8
XlwuW1xcL118fCdgCisgICMgQSAiLi4iIGZvciBlYWNoIGRpcmVjdG9yeSBpbiAkYWNfZGlyX3N1
ZmZpeC4KKyAgYWNfdG9wX2J1aWxkZGlyX3N1Yj1gJGFzX2VjaG8gIiRhY19kaXJfc3VmZml4IiB8
IHNlZCAnc3wvW15cXC9dKnwvLi58ZztzfC98fCdgCisgIGNhc2UgJGFjX3RvcF9idWlsZGRpcl9z
dWIgaW4KKyAgIiIpIGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4PSA7
OworICAqKSAgYWNfdG9wX2J1aWxkX3ByZWZpeD0kYWNfdG9wX2J1aWxkZGlyX3N1Yi8gOzsKKyAg
ZXNhYyA7OworZXNhYworYWNfYWJzX3RvcF9idWlsZGRpcj0kYWNfcHdkCithY19hYnNfYnVpbGRk
aXI9JGFjX3B3ZCRhY19kaXJfc3VmZml4CisjIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Ogor
YWNfdG9wX2J1aWxkZGlyPSRhY190b3BfYnVpbGRfcHJlZml4CisKK2Nhc2UgJHNyY2RpciBpbgor
ICAuKSAgIyBXZSBhcmUgYnVpbGRpbmcgaW4gcGxhY2UuCisgICAgYWNfc3JjZGlyPS4KKyAgICBh
Y190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRkaXJfc3ViCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9
JGFjX3B3ZCA7OworICBbXFwvXSogfCA/OltcXC9dKiApICAjIEFic29sdXRlIG5hbWUuCisgICAg
YWNfc3JjZGlyPSRzcmNkaXIkYWNfZGlyX3N1ZmZpeDsKKyAgICBhY190b3Bfc3JjZGlyPSRzcmNk
aXIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0kc3JjZGlyIDs7CisgICopICMgUmVsYXRpdmUgbmFt
ZS4KKyAgICBhY19zcmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyJGFjX2Rpcl9zdWZm
aXgKKyAgICBhY190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpcgorICAgIGFj
X2Fic190b3Bfc3JjZGlyPSRhY19wd2QvJHNyY2RpciA7OworZXNhYworYWNfYWJzX3NyY2Rpcj0k
YWNfYWJzX3RvcF9zcmNkaXIkYWNfZGlyX3N1ZmZpeAorCisgICAgY2QgIiRhY19kaXIiIHx8IHsg
YWNfc3RhdHVzPSQ/OyBjb250aW51ZTsgfQorICAgICMgQ2hlY2sgZm9yIGd1ZXN0ZWQgY29uZmln
dXJlLgorICAgIGlmIHRlc3QgLWYgIiRhY19zcmNkaXIvY29uZmlndXJlLmdudSI7IHRoZW4KKyAg
ICAgIGVjaG8gJiYKKyAgICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUuZ251IiAtLWhl
bHA9cmVjdXJzaXZlCisgICAgZWxpZiB0ZXN0IC1mICIkYWNfc3JjZGlyL2NvbmZpZ3VyZSI7IHRo
ZW4KKyAgICAgIGVjaG8gJiYKKyAgICAgICRTSEVMTCAiJGFjX3NyY2Rpci9jb25maWd1cmUiIC0t
aGVscD1yZWN1cnNpdmUKKyAgICBlbHNlCisgICAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiBubyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGlzIGluICRhY19kaXIiID4mMgorICAgIGZp
IHx8IGFjX3N0YXR1cz0kPworICAgIGNkICIkYWNfcHdkIiB8fCB7IGFjX3N0YXR1cz0kPzsgYnJl
YWs7IH0KKyAgZG9uZQorZmkKKwordGVzdCAtbiAiJGFjX2luaXRfaGVscCIgJiYgZXhpdCAkYWNf
c3RhdHVzCitpZiAkYWNfaW5pdF92ZXJzaW9uOyB0aGVuCisgIGNhdCA8PFxfQUNFT0YKK1hlbiBI
eXBlcnZpc29yIGNvbmZpZ3VyZSA0LjIKK2dlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42OAor
CitDb3B5cmlnaHQgKEMpIDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCitUaGlz
IGNvbmZpZ3VyZSBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbgorZ2l2ZXMgdW5saW1pdGVkIHBlcm1pc3Npb24gdG8gY29weSwgZGlzdHJpYnV0ZSBh
bmQgbW9kaWZ5IGl0LgorX0FDRU9GCisgIGV4aXQKK2ZpCisKKyMjIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSAjIworIyMgQXV0b2NvbmYgaW5pdGlhbGl6YXRpb24uICMjCisjIyAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gIyMKKworIyBhY19mbl9jX3RyeV9jb21waWxlIExJTkVOTworIyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gY29tcGlsZSBjb25mdGVzdC4kYWNfZXh0
LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19mbl9jX3RyeV9jb21waWxl
ICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf
bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgcm0gLWYgY29uZnRlc3QuJGFjX29iamV4
dAorICBpZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAg
KlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9l
Y2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9
ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPmNvbmZ0ZXN0LmVycgorICBhY19zdGF0dXM9
JD8KKyAgaWYgdGVzdCAtcyBjb25mdGVzdC5lcnI7IHRoZW4KKyAgICBncmVwIC12ICdeICorJyBj
b25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1CisgICAg
bXYgLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICBmaQorICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfSAmJiB7CisJIHRlc3QgLXogIiRhY19jX3dlcnJvcl9mbGFnIiB8fAorCSB0
ZXN0ICEgLXMgY29uZnRlc3QuZXJyCisgICAgICAgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LiRhY19v
YmpleHQ7IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFzX21lOiBm
YWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+
JjUKKworCWFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGlu
ZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0
dmFsCisKK30gIyBhY19mbl9jX3RyeV9jb21waWxlCisKKyMgYWNfZm5fY190cnlfY3BwIExJTkVO
TworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyeSB0byBwcmVwcm9jZXNzIGNvbmZ0ZXN0
LiRhY19leHQsIGFuZCByZXR1cm4gd2hldGhlciB0aGlzIHN1Y2NlZWRlZC4KK2FjX2ZuX2NfdHJ5
X2NwcCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNr
PWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIHsgeyBhY190cnk9IiRhY19j
cHAgY29uZnRlc3QuJGFjX2V4dCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCog
fCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7
OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZh
bCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVz
PSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycg
Y29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAg
IG12IC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFj
X3N0YXR1cyA9IDA7IH0gPiBjb25mdGVzdC5pICYmIHsKKwkgdGVzdCAteiAiJGFjX2NfcHJlcHJv
Y193YXJuX2ZsYWckYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0LmVy
cgorICAgICAgIH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAiJGFz
X21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFj
X2V4dCA+JjUKKworICAgIGFjX3JldHZhbD0xCitmaQorICBldmFsICRhc19saW5lbm9fc3RhY2s7
ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0YXR1
cyAkYWNfcmV0dmFsCisKK30gIyBhY19mbl9jX3RyeV9jcHAKKworIyBhY19mbl9jX2NoZWNrX2hl
YWRlcl9tb25ncmVsIExJTkVOTyBIRUFERVIgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhl
ciBIRUFERVIgZXhpc3RzLCBnaXZpbmcgYSB3YXJuaW5nIGlmIGl0IGNhbm5vdCBiZSBjb21waWxl
ZCB1c2luZworIyB0aGUgaW5jbHVkZSBmaWxlcyBpbiBJTkNMVURFUyBhbmQgc2V0dGluZyB0aGUg
Y2FjaGUgdmFyaWFibGUgVkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19oZWFkZXJf
bW9uZ3JlbCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0
YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIGlmIGV2YWwgXCR7JDMrOn0g
ZmFsc2U7IHRoZW4gOgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+
JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8g
IiRhY19yZXMiID4mNjsgfQorZWxzZQorICAjIElzIHRoZSBoZWFkZXIgY29tcGlsYWJsZT8KK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIgdXNhYmls
aXR5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nICQyIHVzYWJpbGl0eS4uLiAiID4mNjsgfQor
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworJDQKKyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19oZWFkZXJfY29tcGlsZXI9eWVzCitlbHNlCisg
IGFjX2hlYWRlcl9jb21waWxlcj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19oZWFkZXJfY29tcGlsZXIiID4mNQorJGFzX2Vj
aG8gIiRhY19oZWFkZXJfY29tcGlsZXIiID4mNjsgfQorCisjIElzIHRoZSBoZWFkZXIgcHJlc2Vu
dD8KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgJDIg
cHJlc2VuY2UiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgJDIgcHJlc2VuY2UuLi4gIiA+JjY7
IH0KK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3Bw
ICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2hlYWRlcl9wcmVwcm9jPXllcworZWxzZQorICBhY19o
ZWFkZXJfcHJlcHJvYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0
ZXN0LiRhY19leHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfaGVhZGVyX3ByZXByb2MiID4mNQorJGFzX2VjaG8gIiRhY19oZWFkZXJfcHJlcHJv
YyIgPiY2OyB9CisKKyMgU28/ICBXaGF0IGFib3V0IHRoaXMgaGVhZGVyPworY2FzZSAkYWNfaGVh
ZGVyX2NvbXBpbGVyOiRhY19oZWFkZXJfcHJlcHJvYzokYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBp
biAjKCgKKyAgeWVzOm5vOiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiAkMjogYWNjZXB0ZWQgYnkgdGhlIGNvbXBpbGVyLCByZWplY3RlZCBi
eSB0aGUgcHJlcHJvY2Vzc29yISIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjog
YWNjZXB0ZWQgYnkgdGhlIGNvbXBpbGVyLCByZWplY3RlZCBieSB0aGUgcHJlcHJvY2Vzc29yISIg
PiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5J
Tkc6ICQyOiBwcm9jZWVkaW5nIHdpdGggdGhlIGNvbXBpbGVyJ3MgcmVzdWx0IiA+JjUKKyRhc19l
Y2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiBwcm9jZWVkaW5nIHdpdGggdGhlIGNvbXBpbGVyJ3Mg
cmVzdWx0IiA+JjI7fQorICAgIDs7CisgIG5vOnllczoqICkKKyAgICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3Qg
YmUgY29tcGlsZWQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHByZXNlbnQg
YnV0IGNhbm5vdCBiZSBjb21waWxlZCIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiAgICAgY2hlY2sgZm9yIG1pc3NpbmcgcHJl
cmVxdWlzaXRlIGhlYWRlcnM/IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiAg
ICAgY2hlY2sgZm9yIG1pc3NpbmcgcHJlcmVxdWlzaXRlIGhlYWRlcnM/IiA+JjI7fQorICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6IHNlZSB0
aGUgQXV0b2NvbmYgZG9jdW1lbnRhdGlvbiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H
OiAkMjogc2VlIHRoZSBBdXRvY29uZiBkb2N1bWVudGF0aW9uIiA+JjI7fQorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJDI6ICAgICBzZWN0aW9u
IFwiUHJlc2VudCBCdXQgQ2Fubm90IEJlIENvbXBpbGVkXCIiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogJDI6ICAgICBzZWN0aW9uIFwiUHJlc2VudCBCdXQgQ2Fubm90IEJlIENvbXBp
bGVkXCIiID4mMjt9CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1
CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21w
aWxlcidzIHJlc3VsdCIgPiYyO30KKyggJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBSZXBvcnQgdGhpcyB0byB4ZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbSAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gIyMiCisgICAgICkgfCBzZWQgInMvXi8kYXNfbWU6IFdBUk5JTkc6ICAg
ICAvIiA+JjIKKyAgICA7OworZXNhYworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JDIuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIkMz1cJGFjX2hlYWRlcl9jb21waWxl
ciIKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVz
IiA+JjY7IH0KK2ZpCisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6
Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbAor
CisjIGFjX2ZuX2NfdHJ5X3J1biBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBU
cnkgdG8gbGluayBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNj
ZWVkZWQuIEFzc3VtZXMKKyMgdGhhdCBleGVjdXRhYmxlcyAqY2FuKiBiZSBydW4uCithY19mbl9j
X3RyeV9ydW4gKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19z
dGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiB7IHsgYWNfdHJ5PSIk
YWNfbGluayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190
cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZh
bCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2Vj
aG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsi
KSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfSAm
JiB7IGFjX3RyeT0nLi9jb25mdGVzdCRhY19leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnki
IGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBh
Y190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9l
Y2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgfTsgdGhlbiA6CisgIGFjX3JldHZhbD0wCitl
bHNlCisgICRhc19lY2hvICIkYXNfbWU6IHByb2dyYW0gZXhpdGVkIHdpdGggc3RhdHVzICRhY19z
dGF0dXMiID4mNQorICAgICAgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoi
ID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCisgICAgICAgYWNfcmV0
dmFsPSRhY19zdGF0dXMKK2ZpCisgIHJtIC1yZiBjb25mdGVzdC5kU1lNIGNvbmZ0ZXN0X2lwYThf
Y29uZnRlc3Qub28KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazor
On0gdW5zZXQgYXNfbGluZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMg
YWNfZm5fY190cnlfcnVuCisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSBMSU5FTk8g
SEVBREVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4aXN0cyBhbmQg
Y2FuIGJlIGNvbXBpbGVkIHVzaW5nIHRoZSBpbmNsdWRlIGZpbGVzIGluCisjIElOQ0xVREVTLCBz
ZXR0aW5nIHRoZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkuCithY19mbl9jX2NoZWNr
X2hlYWRlcl9jb21waWxlICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19s
aW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworJDQKKyNpbmNsdWRlIDwkMj4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAi
JExJTkVOTyI7IHRoZW4gOgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu
JGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRh
Y19yZXMiID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNr
Ois6fSB1bnNldCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUK
KworIyBhY19mbl9jX3RyeV9saW5rIExJTkVOTworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQor
IyBUcnkgdG8gbGluayBjb25mdGVzdC4kYWNfZXh0LCBhbmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBz
dWNjZWVkZWQuCithY19mbl9jX3RyeV9saW5rICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVu
by0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sK
KyAgcm0gLWYgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdCRhY19leGVleHQKKyAgaWYgeyB7
IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwg
KlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsK
K2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
JGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwg
IiRhY19saW5rIikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMg
Y29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJyID5jb25m
dGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0ZXN0LmVy
MSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYg
eworCSB0ZXN0IC16ICIkYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNvbmZ0ZXN0
LmVycgorICAgICAgIH0gJiYgdGVzdCAtcyBjb25mdGVzdCRhY19leGVleHQgJiYgeworCSB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllcyB8fAorCSAkYXNfdGVzdF94IGNvbmZ0ZXN0JGFjX2V4
ZWV4dAorICAgICAgIH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNfZWNobyAi
JGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3Qu
JGFjX2V4dCA+JjUKKworCWFjX3JldHZhbD0xCitmaQorICAjIERlbGV0ZSB0aGUgSVBBL0lQTyAo
SW50ZXIgUHJvY2VkdXJhbCBBbmFseXNpcy9PcHRpbWl6YXRpb24pIGluZm9ybWF0aW9uCisgICMg
Y3JlYXRlZCBieSB0aGUgUEdJIGNvbXBpbGVyIChjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vKSwg
YXMgaXQgd291bGQKKyAgIyBpbnRlcmZlcmUgd2l0aCB0aGUgbmV4dCBsaW5rIGNvbW1hbmQ7IGFs
c28gZGVsZXRlIGEgZGlyZWN0b3J5IHRoYXQgaXMKKyAgIyBsZWZ0IGJlaGluZCBieSBBcHBsZSdz
IGNvbXBpbGVyLiAgV2UgZG8gdGhpcyBiZWZvcmUgZXhlY3V0aW5nIHRoZSBhY3Rpb25zLgorICBy
bSAtcmYgY29uZnRlc3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9vCisgIGV2YWwgJGFz
X2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworICBh
c19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5X2xpbmsKKworIyBh
Y19mbl9jX2NoZWNrX3R5cGUgTElORU5PIFRZUEUgVkFSIElOQ0xVREVTCisjIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVGVzdHMgd2hldGhlciBUWVBFIGV4
aXN0cyBhZnRlciBoYXZpbmcgaW5jbHVkZWQgSU5DTFVERVMsIHNldHRpbmcgY2FjaGUKKyMgdmFy
aWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja190eXBlICgpCit7CisgIGFzX2xp
bmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRh
c19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIg
PiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgZXZhbCAiJDM9bm8iCisgIGNhdCBjb25mZGVmcy5oIC0gPDxf
QUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0CitpbnQK
K21haW4gKCkKK3sKK2lmIChzaXplb2YgKCQyKSkKKwkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNv
bmZkZWZzLmguICAqLworJDQKK2ludAorbWFpbiAoKQoreworaWYgKHNpemVvZiAoKCQyKSkpCisJ
ICAgIHJldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgZXZhbCAiJDM9eWVzIgorZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj
X2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29u
ZnRlc3QuJGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4mNQorJGFzX2Vj
aG8gIiRhY19yZXMiID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5v
X3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfdHlwZQorCisj
IGFjX2ZuX2NfY2hlY2tfZnVuYyBMSU5FTk8gRlVOQyBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorIyBUZXN0cyB3aGV0aGVyIEZVTkMgZXhpc3RzLCBzZXR0aW5nIHRo
ZSBjYWNoZSB2YXJpYWJsZSBWQVIgYWNjb3JkaW5nbHkKK2FjX2ZuX2NfY2hlY2tfZnVuYyAoKQor
eworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVu
b19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKy8qIERlZmluZSAkMiB0
byBhbiBpbm5vY3VvdXMgdmFyaWFudCwgaW4gY2FzZSA8bGltaXRzLmg+IGRlY2xhcmVzICQyLgor
ICAgRm9yIGV4YW1wbGUsIEhQLVVYIDExaSA8bGltaXRzLmg+IGRlY2xhcmVzIGdldHRpbWVvZmRh
eS4gICovCisjZGVmaW5lICQyIGlubm9jdW91c18kMgorCisvKiBTeXN0ZW0gaGVhZGVyIHRvIGRl
ZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCisgICAgd2hp
Y2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciAkMiAoKTsgYmVsb3cuCisgICAgUHJlZmVyIDxsaW1p
dHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAgIDxs
aW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4gICovCisKKyNp
ZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFz
c2VydC5oPgorI2VuZGlmCisKKyN1bmRlZiAkMgorCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBf
X2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyICQyICgpOworLyogVGhlIEdOVSBD
IGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cwor
ICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVh
bGx5IG5hbWVkCisgICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwg
bmFtZSBpcyBhbiBhbGlhcy4gICovCisjaWYgZGVmaW5lZCBfX3N0dWJfJDIgfHwgZGVmaW5lZCBf
X3N0dWJfX18kMgorY2hva2UgbWUKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAk
MiAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAi
JExJTkVOTyI7IHRoZW4gOgorICBldmFsICIkMz15ZXMiCitlbHNlCisgIGV2YWwgIiQzPW5vIgor
ZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZhbCBhY19yZXM9XCQkMwor
CSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVu
b19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNf
Zm5fY19jaGVja19mdW5jCisKKyMgYWNfZm5fY19maW5kX2ludFhfdCBMSU5FTk8gQklUUyBWQVIK
KyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgRmluZHMgYSBzaWduZWQg
aW50ZWdlciB0eXBlIHdpdGggd2lkdGggQklUUywgc2V0dGluZyBjYWNoZSB2YXJpYWJsZSBWQVIK
KyMgYWNjb3JkaW5nbHkuCithY19mbl9jX2ZpbmRfaW50WF90ICgpCit7CisgIGFzX2xpbmVubz0k
e2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5l
bm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgaW50JDJfdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW50JDJfdC4u
LiAiID4mNjsgfQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICAgICAjIE9yZGVyIGlzIGlt
cG9ydGFudCAtIG5ldmVyIGNoZWNrIGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIK
KyAgICAgIyB0aGFuIGhhbGYgb2YgdGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KKyAgICAgZm9y
IGFjX3R5cGUgaW4gaW50JDJfdCAnaW50JyAnbG9uZyBpbnQnIFwKKwkgJ2xvbmcgbG9uZyBpbnQn
ICdzaG9ydCBpbnQnICdzaWduZWQgY2hhcic7IGRvCisgICAgICAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQKKwkgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWlu
ICgpCit7CitzdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgwIDwgKCRhY190eXBlKSAo
KCgoKCRhY190eXBlKSAxIDw8IE4pIDw8IE4pIC0gMSkgKiAyICsgMSkpXTsKK3Rlc3RfYXJyYXkg
WzBdID0gMAorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2Nv
bXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1
bHQKKwkgICAgICAgIGVudW0geyBOID0gJDIgLyAyIC0gMSB9OworaW50CittYWluICgpCit7Citz
dGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAyICogISgoJGFjX3R5cGUpICgoKCgoJGFjX3R5cGUp
IDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAxKQorCQkgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5
cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAyKSldOwordGVzdF9hcnJheSBbMF0gPSAwCisK
KyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ
TkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGNhc2UgJGFjX3R5cGUgaW4gIygKKyAgaW50JDJfdCkg
OgorICAgIGV2YWwgIiQzPXllcyIgOzsgIygKKyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlw
ZSIgOzsKK2VzYWMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgICBpZiBldmFsIHRlc3QgXCJ4XCQi
JDMiXCIgPSB4Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJlYWsKK2ZpCisgICAgIGRvbmUKK2Zp
CitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7
IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQg
YXNfbGluZW5vCisKK30gIyBhY19mbl9jX2ZpbmRfaW50WF90CisKKyMgYWNfZm5fY19jaGVja19t
ZW1iZXIgTElORU5PIEFHR1IgTUVNQkVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRyaWVzIHRvIGZpbmQgaWYg
dGhlIGZpZWxkIE1FTUJFUiBleGlzdHMgaW4gdHlwZSBBR0dSLCBhZnRlciBpbmNsdWRpbmcKKyMg
SU5DTFVERVMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5f
Y19jaGVja19tZW1iZXIgKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xp
bmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkMi4kMyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuJDMuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDQr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCiskNQoraW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsKK2lmIChh
Y19hZ2dyLiQzKQorcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFj
X2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgZXZhbCAiJDQ9eWVzIgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCiskNQoraW50CittYWluICgpCit7CitzdGF0aWMgJDIgYWNfYWdncjsK
K2lmIChzaXplb2YgYWNfYWdnci4kMykKK3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQor
X0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwg
IiQ0PXllcyIKK2Vsc2UKKyAgZXZhbCAiJDQ9bm8iCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorZXZh
bCBhY19yZXM9XCQkNAorCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Cisg
IGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xp
bmVubworCit9ICMgYWNfZm5fY19jaGVja19tZW1iZXIKKworIyBhY19mbl9jX2ZpbmRfdWludFhf
dCBMSU5FTk8gQklUUyBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CisjIEZpbmRzIGFuIHVuc2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRoIEJJVFMsIHNldHRp
bmcgY2FjaGUgdmFyaWFibGUgVkFSCisjIGFjY29yZGluZ2x5LgorYWNfZm5fY19maW5kX3VpbnRY
X3QgKCkKK3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1h
c19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB1aW50JDJfdCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgdWludCQyX3QuLi4gIiA+JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBldmFsICIk
Mz1ubyIKKyAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBuZXZlciBjaGVjayBhIHR5cGUgdGhh
dCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCisgICAgICMgdGhhbiBoYWxmIG9mIHRoZSBleHBlY3Rl
ZCB0YXJnZXQgd2lkdGguCisgICAgIGZvciBhY190eXBlIGluIHVpbnQkMl90ICd1bnNpZ25lZCBp
bnQnICd1bnNpZ25lZCBsb25nIGludCcgXAorCSAndW5zaWduZWQgbG9uZyBsb25nIGludCcgJ3Vu
c2lnbmVkIHNob3J0IGludCcgJ3Vuc2lnbmVkIGNoYXInOyBkbworICAgICAgIGNhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK21haW4gKCkKK3sKK3N0YXRpYyBpbnQgdGVzdF9h
cnJheSBbMSAtIDIgKiAhKCgoJGFjX3R5cGUpIC0xID4+ICgkMiAvIDIgLSAxKSkgPj4gKCQyIC8g
MiAtIDEpID09IDMpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgY2Fz
ZSAkYWNfdHlwZSBpbiAjKAorICB1aW50JDJfdCkgOgorICAgIGV2YWwgIiQzPXllcyIgOzsgIygK
KyAgKikgOgorICAgIGV2YWwgIiQzPVwkYWNfdHlwZSIgOzsKK2VzYWMKK2ZpCitybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAg
ICBpZiBldmFsIHRlc3QgXCJ4XCQiJDMiXCIgPSB4Im5vIjsgdGhlbiA6CisKK2Vsc2UKKyAgYnJl
YWsKK2ZpCisgICAgIGRvbmUKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRh
c19lY2hvICIkYWNfcmVzIiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xp
bmVub19zdGFjazorOn0gdW5zZXQgYXNfbGluZW5vCisKK30gIyBhY19mbl9jX2ZpbmRfdWludFhf
dAorY2F0ID5jb25maWcubG9nIDw8X0FDRU9GCitUaGlzIGZpbGUgY29udGFpbnMgYW55IG1lc3Nh
Z2VzIHByb2R1Y2VkIGJ5IGNvbXBpbGVycyB3aGlsZQorcnVubmluZyBjb25maWd1cmUsIHRvIGFp
ZCBkZWJ1Z2dpbmcgaWYgY29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KKworSXQgd2FzIGNyZWF0
ZWQgYnkgWGVuIEh5cGVydmlzb3IgJGFzX21lIDQuMiwgd2hpY2ggd2FzCitnZW5lcmF0ZWQgYnkg
R05VIEF1dG9jb25mIDIuNjguICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICAkICQw
ICRACisKK19BQ0VPRgorZXhlYyA1Pj5jb25maWcubG9nCit7CitjYXQgPDxfQVNVTkFNRQorIyMg
LS0tLS0tLS0tICMjCisjIyBQbGF0Zm9ybS4gIyMKKyMjIC0tLS0tLS0tLSAjIworCitob3N0bmFt
ZSA9IGAoaG9zdG5hbWUgfHwgdW5hbWUgLW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAordW5hbWUg
LW0gPSBgKHVuYW1lIC1tKSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtciA9
IGAodW5hbWUgLXIpIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1zID0gYCh1
bmFtZSAtcykgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXYgPSBgKHVuYW1l
IC12KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCisKKy91c3IvYmluL3VuYW1lIC1wID0g
YCgvdXNyL2Jpbi91bmFtZSAtcCkgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAorL2Jpbi91
bmFtZSAtWCAgICAgPSBgKC9iaW4vdW5hbWUgLVgpIDI+L2Rldi9udWxsICAgICB8fCBlY2hvIHVu
a25vd25gCisKKy9iaW4vYXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkgMj4vZGV2L251
bGwgICAgICAgICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL2FyY2ggLWsgICAgICAg
PSBgKC91c3IvYmluL2FyY2ggLWspIDI+L2Rldi9udWxsICAgICAgIHx8IGVjaG8gdW5rbm93bmAK
Ky91c3IvY29udmV4L2dldHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dldHN5c2luZm8pIDI+L2Rl
di9udWxsIHx8IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL2hvc3RpbmZvICAgICAgPSBgKC91c3Iv
YmluL2hvc3RpbmZvKSAyPi9kZXYvbnVsbCAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vbWFj
aGluZSAgICAgICAgICAgPSBgKC9iaW4vbWFjaGluZSkgMj4vZGV2L251bGwgICAgICAgICAgIHx8
IGVjaG8gdW5rbm93bmAKKy91c3IvYmluL29zbGV2ZWwgICAgICAgPSBgKC91c3IvYmluL29zbGV2
ZWwpIDI+L2Rldi9udWxsICAgICAgIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vdW5pdmVyc2UgICAg
ICAgICAgPSBgKC9iaW4vdW5pdmVyc2UpIDI+L2Rldi9udWxsICAgICAgICAgIHx8IGVjaG8gdW5r
bm93bmAKKworX0FTVU5BTUUKKworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgICRhc19lY2hvICJQQVRIOiAkYXNfZGlyIgorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK30gPiY1CisKK2NhdCA+JjUgPDxfQUNFT0YKKworCisj
IyAtLS0tLS0tLS0tLSAjIworIyMgQ29yZSB0ZXN0cy4gIyMKKyMjIC0tLS0tLS0tLS0tICMjCisK
K19BQ0VPRgorCisKKyMgS2VlcCBhIHRyYWNlIG9mIHRoZSBjb21tYW5kIGxpbmUuCisjIFN0cmlw
IG91dCAtLW5vLWNyZWF0ZSBhbmQgLS1uby1yZWN1cnNpb24gc28gdGhleSBkbyBub3QgcGlsZSB1
cC4KKyMgU3RyaXAgb3V0IC0tc2lsZW50IGJlY2F1c2Ugd2UgZG9uJ3Qgd2FudCB0byByZWNvcmQg
aXQgZm9yIGZ1dHVyZSBydW5zLgorIyBBbHNvIHF1b3RlIGFueSBhcmdzIGNvbnRhaW5pbmcgc2hl
bGwgbWV0YS1jaGFyYWN0ZXJzLgorIyBNYWtlIHR3byBwYXNzZXMgdG8gYWxsb3cgZm9yIHByb3Bl
ciBkdXBsaWNhdGUtYXJndW1lbnQgc3VwcHJlc3Npb24uCithY19jb25maWd1cmVfYXJncz0KK2Fj
X2NvbmZpZ3VyZV9hcmdzMD0KK2FjX2NvbmZpZ3VyZV9hcmdzMT0KK2FjX211c3Rfa2VlcF9uZXh0
PWZhbHNlCitmb3IgYWNfcGFzcyBpbiAxIDIKK2RvCisgIGZvciBhY19hcmcKKyAgZG8KKyAgICBj
YXNlICRhY19hcmcgaW4KKyAgICAtbm8tY3JlYXRlIHwgLS1uby1jKiB8IC1uIHwgLW5vLXJlY3Vy
c2lvbiB8IC0tbm8tciopIGNvbnRpbnVlIDs7CisgICAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwg
LS1xdWllIHwgLS1xdWkgfCAtLXF1IHwgLS1xIFwKKyAgICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8
IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCkKKyAgICAgIGNvbnRpbnVlIDs7CisgICAgKlwnKikK
KyAgICAgIGFjX2FyZz1gJGFzX2VjaG8gIiRhY19hcmciIHwgc2VkICJzLycvJ1xcXFxcXFxcJycv
ZyJgIDs7CisgICAgZXNhYworICAgIGNhc2UgJGFjX3Bhc3MgaW4KKyAgICAxKSBhc19mbl9hcHBl
bmQgYWNfY29uZmlndXJlX2FyZ3MwICIgJyRhY19hcmcnIiA7OworICAgIDIpCisgICAgICBhc19m
bl9hcHBlbmQgYWNfY29uZmlndXJlX2FyZ3MxICIgJyRhY19hcmcnIgorICAgICAgaWYgdGVzdCAk
YWNfbXVzdF9rZWVwX25leHQgPSB0cnVlOyB0aGVuCisJYWNfbXVzdF9rZWVwX25leHQ9ZmFsc2Ug
IyBHb3QgdmFsdWUsIGJhY2sgdG8gbm9ybWFsLgorICAgICAgZWxzZQorCWNhc2UgJGFjX2FyZyBp
bgorCSAgKj0qIHwgLS1jb25maWctY2FjaGUgfCAtQyB8IC1kaXNhYmxlLSogfCAtLWRpc2FibGUt
KiBcCisJICB8IC1lbmFibGUtKiB8IC0tZW5hYmxlLSogfCAtZ2FzIHwgLS1nKiB8IC1uZnAgfCAt
LW5mKiBcCisJICB8IC1xIHwgLXF1aWV0IHwgLS1xKiB8IC1zaWxlbnQgfCAtLXNpbCogfCAtdiB8
IC12ZXJiKiBcCisJICB8IC13aXRoLSogfCAtLXdpdGgtKiB8IC13aXRob3V0LSogfCAtLXdpdGhv
dXQtKiB8IC0teCkKKwkgICAgY2FzZSAiJGFjX2NvbmZpZ3VyZV9hcmdzMCAiIGluCisJICAgICAg
IiRhY19jb25maWd1cmVfYXJnczEiKiIgJyRhY19hcmcnICIqICkgY29udGludWUgOzsKKwkgICAg
ZXNhYworCSAgICA7OworCSAgLSogKSBhY19tdXN0X2tlZXBfbmV4dD10cnVlIDs7CisJZXNhYwor
ICAgICAgZmkKKyAgICAgIGFzX2ZuX2FwcGVuZCBhY19jb25maWd1cmVfYXJncyAiICckYWNfYXJn
JyIKKyAgICAgIDs7CisgICAgZXNhYworICBkb25lCitkb25lCit7IGFjX2NvbmZpZ3VyZV9hcmdz
MD07IHVuc2V0IGFjX2NvbmZpZ3VyZV9hcmdzMDt9Cit7IGFjX2NvbmZpZ3VyZV9hcmdzMT07IHVu
c2V0IGFjX2NvbmZpZ3VyZV9hcmdzMTt9CisKKyMgV2hlbiBpbnRlcnJ1cHRlZCBvciBleGl0J2Qs
IGNsZWFudXAgdGVtcG9yYXJ5IGZpbGVzLCBhbmQgY29tcGxldGUKKyMgY29uZmlnLmxvZy4gIFdl
IHJlbW92ZSBjb21tZW50cyBiZWNhdXNlIGFueXdheSB0aGUgcXVvdGVzIGluIHRoZXJlCisjIHdv
dWxkIGNhdXNlIHByb2JsZW1zIG9yIGxvb2sgdWdseS4KKyMgV0FSTklORzogVXNlICdcJycgdG8g
cmVwcmVzZW50IGFuIGFwb3N0cm9waGUgd2l0aGluIHRoZSB0cmFwLgorIyBXQVJOSU5HOiBEbyBu
b3Qgc3RhcnQgdGhlIHRyYXAgY29kZSB3aXRoIGEgbmV3bGluZSwgZHVlIHRvIGEgRnJlZUJTRCA0
LjAgYnVnLgordHJhcCAnZXhpdF9zdGF0dXM9JD8KKyAgIyBTYXZlIGludG8gY29uZmlnLmxvZyBz
b21lIGluZm9ybWF0aW9uIHRoYXQgbWlnaHQgaGVscCBpbiBkZWJ1Z2dpbmcuCisgIHsKKyAgICBl
Y2hvCisKKyAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLSAjIworIyMgQ2FjaGUgdmFy
aWFibGVzLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisgICAgIyBUaGUg
Zm9sbG93aW5nIHdheSBvZiB3cml0aW5nIHRoZSBjYWNoZSBtaXNoYW5kbGVzIG5ld2xpbmVzIGlu
IHZhbHVlcywKKygKKyAgZm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAtbiAnXCcncy9e
XChbYS16QS1aX11bYS16QS1aMC05X10qXCk9LiovXDEvcCdcJydgOyBkbworICAgIGV2YWwgYWNf
dmFsPVwkJGFjX3ZhcgorICAgIGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSopCisg
ICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFyIGNv
bnRhaW5zIGEgbmV3bGluZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNoZSB2
YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVzYWMK
KyAgICAgIGNhc2UgJGFjX3ZhciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAjKAor
ICAgICAgQkFTSF9BUkdWIHwgQkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAgICAg
ICopIHsgZXZhbCAkYWNfdmFyPTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7Cisg
ICAgZXNhYworICBkb25lCisgIChzZXQpIDI+JjEgfAorICAgIGNhc2UgJGFzX25sYChhY19zcGFj
ZT0nXCcnICdcJyc7IHNldCkgMj4mMWAgaW4gIygKKyAgICAqJHthc19ubH1hY19zcGFjZT1cICop
CisgICAgICBzZWQgLW4gXAorCSJzLydcJycvJ1wnJ1xcXFwnXCcnJ1wnJy9nOworCSAgcy9eXFwo
W18kYXNfY3JfYWxudW1dKl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwpL1xcMT0nXCcn
XFwyJ1wnJy9wIgorICAgICAgOzsgIygKKyAgICAqKQorICAgICAgc2VkIC1uICIvXltfJGFzX2Ny
X2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKj0vcCIKKyAgICAgIDs7CisgICAgZXNhYyB8Cisg
ICAgc29ydAorKQorICAgIGVjaG8KKworICAgICRhc19lY2hvICIjIyAtLS0tLS0tLS0tLS0tLS0t
LSAjIworIyMgT3V0cHV0IHZhcmlhYmxlcy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tICMjIgor
ICAgIGVjaG8KKyAgICBmb3IgYWNfdmFyIGluICRhY19zdWJzdF92YXJzCisgICAgZG8KKyAgICAg
IGV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorICAgICAgY2FzZSAkYWNfdmFsIGluCisgICAgICAqXCdc
JycqKSBhY192YWw9YCRhc19lY2hvICIkYWNfdmFsIiB8IHNlZCAicy8nXCcnLydcJydcXFxcXFxc
XCdcJycnXCcnL2ciYDs7CisgICAgICBlc2FjCisgICAgICAkYXNfZWNobyAiJGFjX3Zhcj0nXCcn
JGFjX3ZhbCdcJyciCisgICAgZG9uZSB8IHNvcnQKKyAgICBlY2hvCisKKyAgICBpZiB0ZXN0IC1u
ICIkYWNfc3Vic3RfZmlsZXMiOyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0t
LS0tLS0tLSAjIworIyMgRmlsZSBzdWJzdGl0dXRpb25zLiAjIworIyMgLS0tLS0tLS0tLS0tLS0t
LS0tLSAjIyIKKyAgICAgIGVjaG8KKyAgICAgIGZvciBhY192YXIgaW4gJGFjX3N1YnN0X2ZpbGVz
CisgICAgICBkbworCWV2YWwgYWNfdmFsPVwkJGFjX3ZhcgorCWNhc2UgJGFjX3ZhbCBpbgorCSpc
J1wnJyopIGFjX3ZhbD1gJGFzX2VjaG8gIiRhY192YWwiIHwgc2VkICJzLydcJycvJ1wnJ1xcXFxc
XFxcJ1wnJydcJycvZyJgOzsKKwllc2FjCisJJGFzX2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwn
XCcnIgorICAgICAgZG9uZSB8IHNvcnQKKyAgICAgIGVjaG8KKyAgICBmaQorCisgICAgaWYgdGVz
dCAtcyBjb25mZGVmcy5oOyB0aGVuCisgICAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0gIyMK
KyMjIGNvbmZkZWZzLmguICMjCisjIyAtLS0tLS0tLS0tLSAjIyIKKyAgICAgIGVjaG8KKyAgICAg
IGNhdCBjb25mZGVmcy5oCisgICAgICBlY2hvCisgICAgZmkKKyAgICB0ZXN0ICIkYWNfc2lnbmFs
IiAhPSAwICYmCisgICAgICAkYXNfZWNobyAiJGFzX21lOiBjYXVnaHQgc2lnbmFsICRhY19zaWdu
YWwiCisgICAgJGFzX2VjaG8gIiRhc19tZTogZXhpdCAkZXhpdF9zdGF0dXMiCisgIH0gPiY1Cisg
IHJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiAmJgorICAgIHJtIC1mIC1yIGNvbmZ0
ZXN0KiBjb25mZGVmcyogY29uZiQkKiAkYWNfY2xlYW5fZmlsZXMgJiYKKyAgICBleGl0ICRleGl0
X3N0YXR1cworJyAwCitmb3IgYWNfc2lnbmFsIGluIDEgMiAxMyAxNTsgZG8KKyAgdHJhcCAnYWNf
c2lnbmFsPSckYWNfc2lnbmFsJzsgYXNfZm5fZXhpdCAxJyAkYWNfc2lnbmFsCitkb25lCithY19z
aWduYWw9MAorCisjIGNvbmZkZWZzLmggYXZvaWRzIE9TIGNvbW1hbmQgbGluZSBsZW5ndGggbGlt
aXRzIHRoYXQgREVGUyBjYW4gZXhjZWVkLgorcm0gLWYgLXIgY29uZnRlc3QqIGNvbmZkZWZzLmgK
KworJGFzX2VjaG8gIi8qIGNvbmZkZWZzLmggKi8iID4gY29uZmRlZnMuaAorCisjIFByZWRlZmlu
ZWQgcHJlcHJvY2Vzc29yIHZhcmlhYmxlcy4KKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBQQUNLQUdFX05BTUUgIiRQQUNLQUdFX05BTUUiCitfQUNFT0YKKworY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgIiRQQUNLQUdFX1RBUk5B
TUUiCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdF
X1ZFUlNJT04gIiRQQUNLQUdFX1ZFUlNJT04iCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSBQQUNLQUdFX1NUUklORyAiJFBBQ0tBR0VfU1RSSU5HIgorX0FDRU9G
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9CVUdSRVBPUlQg
IiRQQUNLQUdFX0JVR1JFUE9SVCIKK19BQ0VPRgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjZGVmaW5lIFBBQ0tBR0VfVVJMICIkUEFDS0FHRV9VUkwiCitfQUNFT0YKKworCisjIExldCB0
aGUgc2l0ZSBmaWxlIHNlbGVjdCBhbiBhbHRlcm5hdGUgY2FjaGUgZmlsZSBpZiBpdCB3YW50cyB0
by4KKyMgUHJlZmVyIGFuIGV4cGxpY2l0bHkgc2VsZWN0ZWQgZmlsZSB0byBhdXRvbWF0aWNhbGx5
IHNlbGVjdGVkIG9uZXMuCithY19zaXRlX2ZpbGUxPU5PTkUKK2FjX3NpdGVfZmlsZTI9Tk9ORQor
aWYgdGVzdCAtbiAiJENPTkZJR19TSVRFIjsgdGhlbgorICAjIFdlIGRvIG5vdCB3YW50IGEgUEFU
SCBzZWFyY2ggZm9yIGNvbmZpZy5zaXRlLgorICBjYXNlICRDT05GSUdfU0lURSBpbiAjKCgKKyAg
ICAtKikgIGFjX3NpdGVfZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICAgICovKikgYWNfc2l0ZV9m
aWxlMT0kQ09ORklHX1NJVEU7OworICAgICopICAgYWNfc2l0ZV9maWxlMT0uLyRDT05GSUdfU0lU
RTs7CisgIGVzYWMKK2VsaWYgdGVzdCAieCRwcmVmaXgiICE9IHhOT05FOyB0aGVuCisgIGFjX3Np
dGVfZmlsZTE9JHByZWZpeC9zaGFyZS9jb25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUyPSRwcmVm
aXgvZXRjL2NvbmZpZy5zaXRlCitlbHNlCisgIGFjX3NpdGVfZmlsZTE9JGFjX2RlZmF1bHRfcHJl
Zml4L3NoYXJlL2NvbmZpZy5zaXRlCisgIGFjX3NpdGVfZmlsZTI9JGFjX2RlZmF1bHRfcHJlZml4
L2V0Yy9jb25maWcuc2l0ZQorZmkKK2ZvciBhY19zaXRlX2ZpbGUgaW4gIiRhY19zaXRlX2ZpbGUx
IiAiJGFjX3NpdGVfZmlsZTIiCitkbworICB0ZXN0ICJ4JGFjX3NpdGVfZmlsZSIgPSB4Tk9ORSAm
JiBjb250aW51ZQorICBpZiB0ZXN0IC9kZXYvbnVsbCAhPSAiJGFjX3NpdGVfZmlsZSIgJiYgdGVz
dCAtciAiJGFjX3NpdGVfZmlsZSI7IHRoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGxvYWRpbmcgc2l0ZSBzY3JpcHQgJGFjX3NpdGVfZmlsZSIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUiID4mNjt9
CisgICAgc2VkICdzL14vfCAvJyAiJGFjX3NpdGVfZmlsZSIgPiY1CisgICAgLiAiJGFjX3NpdGVf
ZmlsZSIgXAorICAgICAgfHwgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiZmFpbGVkIHRvIGxvYWQgc2l0
ZSBzY3JpcHQgJGFjX3NpdGVfZmlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWls
cyIgIiRMSU5FTk8iIDU7IH0KKyAgZmkKK2RvbmUKKworaWYgdGVzdCAtciAiJGNhY2hlX2ZpbGUi
OyB0aGVuCisgICMgU29tZSB2ZXJzaW9ucyBvZiBiYXNoIHdpbGwgZmFpbCB0byBzb3VyY2UgL2Rl
di9udWxsIChzcGVjaWFsIGZpbGVzCisgICMgYWN0dWFsbHkpLCBzbyB3ZSBhdm9pZCBkb2luZyB0
aGF0LiAgREpHUFAgZW11bGF0ZXMgaXQgYXMgYSByZWd1bGFyIGZpbGUuCisgIGlmIHRlc3QgL2Rl
di9udWxsICE9ICIkY2FjaGVfZmlsZSIgJiYgdGVzdCAtZiAiJGNhY2hlX2ZpbGUiOyB0aGVuCisg
ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBsb2FkaW5nIGNhY2hl
ICRjYWNoZV9maWxlIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGxvYWRpbmcgY2FjaGUgJGNhY2hl
X2ZpbGUiID4mNjt9CisgICAgY2FzZSAkY2FjaGVfZmlsZSBpbgorICAgICAgW1xcL10qIHwgPzpb
XFwvXSogKSAuICIkY2FjaGVfZmlsZSI7OworICAgICAgKikgICAgICAgICAgICAgICAgICAgICAg
LiAiLi8kY2FjaGVfZmlsZSI7OworICAgIGVzYWMKKyAgZmkKK2Vsc2UKKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBjcmVhdGluZyBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30K
KyAgPiRjYWNoZV9maWxlCitmaQorCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMv
dGltZS5oIgorYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgdW5pc3RkLmgiCithc19mbl9h
cHBlbmQgYWNfZnVuY19saXN0ICIgYWxhcm0iCithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3Qg
IiBzdGRsaWIuaCIKK2FzX2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHN5cy9wYXJhbS5oIgor
IyBDaGVjayB0aGF0IHRoZSBwcmVjaW91cyB2YXJpYWJsZXMgc2F2ZWQgaW4gdGhlIGNhY2hlIGhh
dmUga2VwdCB0aGUgc2FtZQorIyB2YWx1ZS4KK2FjX2NhY2hlX2NvcnJ1cHRlZD1mYWxzZQorZm9y
IGFjX3ZhciBpbiAkYWNfcHJlY2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19vbGRfc2V0PVwkYWNf
Y3ZfZW52XyR7YWNfdmFyfV9zZXQKKyAgZXZhbCBhY19uZXdfc2V0PVwkYWNfZW52XyR7YWNfdmFy
fV9zZXQKKyAgZXZhbCBhY19vbGRfdmFsPVwkYWNfY3ZfZW52XyR7YWNfdmFyfV92YWx1ZQorICBl
dmFsIGFjX25ld192YWw9XCRhY19lbnZfJHthY192YXJ9X3ZhbHVlCisgIGNhc2UgJGFjX29sZF9z
ZXQsJGFjX25ld19zZXQgaW4KKyAgICBzZXQsKQorICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFyJyB3YXMgc2V0IHRvIFxgJGFjX29s
ZF92YWwnIGluIHRoZSBwcmV2aW91cyBydW4iID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6
IFxgJGFjX3Zhcicgd2FzIHNldCB0byBcYCRhY19vbGRfdmFsJyBpbiB0aGUgcHJldmlvdXMgcnVu
IiA+JjI7fQorICAgICAgYWNfY2FjaGVfY29ycnVwdGVkPTogOzsKKyAgICAsc2V0KQorICAgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFy
JyB3YXMgbm90IHNldCBpbiB0aGUgcHJldmlvdXMgcnVuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6
IGVycm9yOiBcYCRhY192YXInIHdhcyBub3Qgc2V0IGluIHRoZSBwcmV2aW91cyBydW4iID4mMjt9
CisgICAgICBhY19jYWNoZV9jb3JydXB0ZWQ9OiA7OworICAgICwpOzsKKyAgICAqKQorICAgICAg
aWYgdGVzdCAieCRhY19vbGRfdmFsIiAhPSAieCRhY19uZXdfdmFsIjsgdGhlbgorCSMgZGlmZmVy
ZW5jZXMgaW4gd2hpdGVzcGFjZSBkbyBub3QgbGVhZCB0byBmYWlsdXJlLgorCWFjX29sZF92YWxf
dz1gZWNobyB4ICRhY19vbGRfdmFsYAorCWFjX25ld192YWxfdz1gZWNobyB4ICRhY19uZXdfdmFs
YAorCWlmIHRlc3QgIiRhY19vbGRfdmFsX3ciICE9ICIkYWNfbmV3X3ZhbF93IjsgdGhlbgorCSAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogXGAkYWNfdmFy
JyBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogXGAkYWNfdmFyJyBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgcnVu
OiIgPiYyO30KKwkgIGFjX2NhY2hlX2NvcnJ1cHRlZD06CisJZWxzZQorCSAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiB3YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNl
IGNoYW5nZXMgaW4gXGAkYWNfdmFyJyBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiB3YXJuaW5nOiBpZ25vcmluZyB3aGl0ZXNwYWNlIGNoYW5nZXMgaW4gXGAk
YWNfdmFyJyBzaW5jZSB0aGUgcHJldmlvdXMgcnVuOiIgPiYyO30KKwkgIGV2YWwgJGFjX3Zhcj1c
JGFjX29sZF92YWwKKwlmaQorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogICBmb3JtZXIgdmFsdWU6ICBcYCRhY19vbGRfdmFsJyIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiAgIGZvcm1lciB2YWx1ZTogIFxgJGFjX29sZF92YWwnIiA+JjI7fQorCXsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogICBjdXJyZW50IHZhbHVlOiBcYCRhY19uZXdfdmFs
JyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAgIGN1cnJlbnQgdmFsdWU6IFxgJGFjX25ld192YWwn
IiA+JjI7fQorICAgICAgZmk7OworICBlc2FjCisgICMgUGFzcyBwcmVjaW91cyB2YXJpYWJsZXMg
dG8gY29uZmlnLnN0YXR1cy4KKyAgaWYgdGVzdCAiJGFjX25ld19zZXQiID0gc2V0OyB0aGVuCisg
ICAgY2FzZSAkYWNfbmV3X3ZhbCBpbgorICAgICpcJyopIGFjX2FyZz0kYWNfdmFyPWAkYXNfZWNo
byAiJGFjX25ld192YWwiIHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgIDs7CisgICAgKikgYWNf
YXJnPSRhY192YXI9JGFjX25ld192YWwgOzsKKyAgICBlc2FjCisgICAgY2FzZSAiICRhY19jb25m
aWd1cmVfYXJncyAiIGluCisgICAgICAqIiAnJGFjX2FyZycgIiopIDs7ICMgQXZvaWQgZHVwcy4g
IFVzZSBvZiBxdW90ZXMgZW5zdXJlcyBhY2N1cmFjeS4KKyAgICAgICopIGFzX2ZuX2FwcGVuZCBh
Y19jb25maWd1cmVfYXJncyAiICckYWNfYXJnJyIgOzsKKyAgICBlc2FjCisgIGZpCitkb25lCitp
ZiAkYWNfY2FjaGVfY29ycnVwdGVkOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogY2hhbmdlcyBpbiB0aGUgZW52aXJvbm1lbnQgY2Fu
IGNvbXByb21pc2UgdGhlIGJ1aWxkIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBjaGFu
Z2VzIGluIHRoZSBlbnZpcm9ubWVudCBjYW4gY29tcHJvbWlzZSB0aGUgYnVpbGQiID4mMjt9Cisg
IGFzX2ZuX2Vycm9yICQ/ICJydW4gXGBtYWtlIGRpc3RjbGVhbicgYW5kL29yIFxgcm0gJGNhY2hl
X2ZpbGUnIGFuZCBzdGFydCBvdmVyIiAiJExJTkVOTyIgNQorZmkKKyMjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tICMjCisjIyBNYWluIGJvZHkgb2Ygc2NyaXB0LiAjIworIyMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0gIyMKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxl
PSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5r
PSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNv
bmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBp
bGVyX2dudQorCisKKworYWNfY29uZmlnX2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIC4uL2NvbmZp
Zy9Ub29scy5tayIKKworYWNfY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVhZGVycyBjb25m
aWcuaCIKKworCithY19hdXhfZGlyPQorZm9yIGFjX2RpciBpbiAuICIkc3JjZGlyIi8uOyBkbwor
ICBpZiB0ZXN0IC1mICIkYWNfZGlyL2luc3RhbGwtc2giOyB0aGVuCisgICAgYWNfYXV4X2Rpcj0k
YWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvaW5zdGFsbC1zaCAtYyIKKyAg
ICBicmVhaworICBlbGlmIHRlc3QgLWYgIiRhY19kaXIvaW5zdGFsbC5zaCI7IHRoZW4KKyAgICBh
Y19hdXhfZGlyPSRhY19kaXIKKyAgICBhY19pbnN0YWxsX3NoPSIkYWNfYXV4X2Rpci9pbnN0YWxs
LnNoIC1jIgorICAgIGJyZWFrCisgIGVsaWYgdGVzdCAtZiAiJGFjX2Rpci9zaHRvb2wiOyB0aGVu
CisgICAgYWNfYXV4X2Rpcj0kYWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIv
c2h0b29sIGluc3RhbGwgLWMiCisgICAgYnJlYWsKKyAgZmkKK2RvbmUKK2lmIHRlc3QgLXogIiRh
Y19hdXhfZGlyIjsgdGhlbgorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgaW5zdGFsbC1z
aCwgaW5zdGFsbC5zaCwgb3Igc2h0b29sIGluIC4gXCIkc3JjZGlyXCIvLiIgIiRMSU5FTk8iIDUK
K2ZpCisKKyMgVGhlc2UgdGhyZWUgdmFyaWFibGVzIGFyZSB1bmRvY3VtZW50ZWQgYW5kIHVuc3Vw
cG9ydGVkLAorIyBhbmQgYXJlIGludGVuZGVkIHRvIGJlIHdpdGhkcmF3biBpbiBhIGZ1dHVyZSBB
dXRvY29uZiByZWxlYXNlLgorIyBUaGV5IGNhbiBjYXVzZSBzZXJpb3VzIHByb2JsZW1zIGlmIGEg
YnVpbGRlcidzIHNvdXJjZSB0cmVlIGlzIGluIGEgZGlyZWN0b3J5CisjIHdob3NlIGZ1bGwgbmFt
ZSBjb250YWlucyB1bnVzdWFsIGNoYXJhY3RlcnMuCithY19jb25maWdfZ3Vlc3M9IiRTSEVMTCAk
YWNfYXV4X2Rpci9jb25maWcuZ3Vlc3MiICAjIFBsZWFzZSBkb24ndCB1c2UgdGhpcyB2YXIuCith
Y19jb25maWdfc3ViPSIkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgICMgUGxlYXNlIGRv
bid0IHVzZSB0aGlzIHZhci4KK2FjX2NvbmZpZ3VyZT0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZp
Z3VyZSIgICMgUGxlYXNlIGRvbid0IHVzZSB0aGlzIHZhci4KKworCisKKyMgQ2hlY2sgaWYgQ0ZM
QUdTLCBMREZMQUdTLCBMSUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdh
cm5pbmcKKworaWYgdGVzdCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQ
IjsgdGhlbiA6CisKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IFdBUk5JTkc6IFNldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQRkxBR1Mgb3Ig
Q1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMsIFBSRVBFTkRf
TElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3Np
YmxlLiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBTZXR0aW5nIENDLCBDRkxBR1Ms
IExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVz
ZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBB
UFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS4iID4mMjt9CisKK2ZpCisKK2FjX2V4dD1j
CithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQ
UEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFj
X2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJT
ID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK2lmIHRlc3QgLW4g
IiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190
b29sX3ByZWZpeH1nY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2
X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X0ND
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNf
Y3RfQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19j
dF9DQz0iZ2NjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X0NDPSRhY19j
dl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQor
JGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsg
fQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBl
bHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hv
ICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhv
c3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIENDPSRh
Y19jdF9DQworICBmaQorZWxzZQorICBDQz0iJGFjX2N2X3Byb2dfQ0MiCitmaQorCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4Ijsg
dGhlbgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1j
YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHth
Y190b29sX3ByZWZpeH1jYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0ZXN0IC1u
ICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNo
byAibm8iID4mNjsgfQorZmkKKworCisgIGZpCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCisgIGFjX3Byb2dfcmVqZWN0ZWQ9
bm8KK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGlm
IHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhl
bgorICAgICAgIGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29udGludWUKKyAgICAgZmkK
KyAgICBhY19jdl9wcm9nX0NDPSJjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworaWYgdGVzdCAk
YWNfcHJvZ19yZWplY3RlZCA9IHllczsgdGhlbgorICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhl
IHBhdGgsIHNvIG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCisgIHNldCBkdW1teSAkYWNfY3Zf
cHJvZ19DQworICBzaGlmdAorICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KKyAgICAjIFdlIGNob3Nl
IGEgZGlmZmVyZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KKyAgICAjIEhvd2V2ZXIs
IGl0IGhhcyB0aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCisg
ICAgIyBmaXJzdCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVs
bCBmaWxlIG5hbWUuCisgICAgc2hpZnQKKyAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193
b3JkJHsxKycgJ30kQCIKKyAgZmkKK2ZpCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitpZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Cisk
YXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgor
ICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgIGZvciBhY19wcm9nIGluIGNs
LmV4ZQorICBkbworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJl
Zml4JGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0
IGR1bW15ICRhY190b29sX3ByZWZpeCRhY19wcm9nOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zf
cHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3By
ZWZpeCRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9w
cm9nX0NDCitpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgdGVzdCAtbiAiJEND
IiAmJiBicmVhaworICBkb25lCitmaQoraWYgdGVzdCAteiAiJENDIjsgdGhlbgorICBhY19jdF9D
Qz0kQ0MKKyAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCitkbworICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiRhY19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAkYWNfcHJvZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNf
Y3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9
IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X2FjX2N0X0NDPSIkYWNfcHJvZyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh
ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19j
dF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0
X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKworICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCitkb25l
CisKKyAgaWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKKyAgZWxzZQor
ICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBDQz0kYWNfY3Rf
Q0MKKyAgZmkKK2ZpCisKK2ZpCisKKwordGVzdCAteiAiJENDIiAmJiB7IHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRh
c19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9y
ICQ/ICJubyBhY2NlcHRhYmxlIEMgY29tcGlsZXIgZm91bmQgaW4gXCRQQVRICitTZWUgXGBjb25m
aWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorCisjIFByb3ZpZGUgc29t
ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCiskYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciB2ZXJzaW9uIiA+JjUKK3Nl
dCBYICRhY19jb21waWxlCithY19jb21waWxlcj0kMgorZm9yIGFjX29wdGlvbiBpbiAtLXZlcnNp
b24gLXYgLVYgLXF2ZXJzaW9uOyBkbworICB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZXIgJGFjX29w
dGlvbiA+JjUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNf
dHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2
YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9l
Y2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jb21w
aWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBp
ZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgorICAgIHNlZCAnMTBhXAorLi4uIHJlc3Qgb2Yg
c3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgorICAgICAgICAgMTBxJyBjb25mdGVzdC5lcnIgPmNv
bmZ0ZXN0LmVyMQorICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1CisgIGZpCisgIHJtIC1mIGNvbmZ0
ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KK2Rv
bmUKKworY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOwor
fQorX0FDRU9GCithY19jbGVhbl9maWxlc19zYXZlPSRhY19jbGVhbl9maWxlcworYWNfY2xlYW5f
ZmlsZXM9IiRhY19jbGVhbl9maWxlcyBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGIub3V0IgorIyBU
cnkgdG8gY3JlYXRlIGFuIGV4ZWN1dGFibGUgd2l0aG91dCAtbyBmaXJzdCwgZGlzcmVnYXJkIGEu
b3V0LgorIyBJdCB3aWxsIGhlbHAgdXMgZGlhZ25vc2UgYnJva2VuIGNvbXBpbGVycywgYW5kIGZp
bmRpbmcgb3V0IGFuIGludHVpdGlvbgorIyBvZiBleGVleHQuCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29y
a3MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jr
cy4uLiAiID4mNjsgfQorYWNfbGlua19kZWZhdWx0PWAkYXNfZWNobyAiJGFjX2xpbmsiIHwgc2Vk
ICdzLyAtbyAqY29uZnRlc3RbXiBdKi8vJ2AKKworIyBUaGUgcG9zc2libGUgb3V0cHV0IGZpbGVz
OgorYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBjb25mdGVzdCBhLmV4ZSBhX291dC5leGUg
Yi5vdXQgY29uZnRlc3QuKiIKKworYWNfcm1maWxlcz0KK2ZvciBhY19maWxlIGluICRhY19maWxl
cworZG8KKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRk
cyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8
ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKKyAgICAqICkgYWNfcm1maWxlcz0iJGFjX3JtZmls
ZXMgJGFjX2ZpbGUiOzsKKyAgZXNhYworZG9uZQorcm0gLWYgJGFjX3JtZmlsZXMKKworaWYgeyB7
IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8
ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRh
Y190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQor
ICAoZXZhbCAiJGFjX2xpbmtfZGVmYXVsdCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQor
ICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBBdXRvY29uZi0yLjEzIGNvdWxk
IHNldCB0aGUgYWNfY3ZfZXhlZXh0IHZhcmlhYmxlIHRvIGBubycuCisjIFNvIGlnbm9yZSBhIHZh
bHVlIG9mIGBubycsIG90aGVyd2lzZSB0aGlzIHdvdWxkIGxlYWQgdG8gYEVYRUVYVCA9IG5vJwor
IyBpbiBhIE1ha2VmaWxlLiAgV2Ugc2hvdWxkIG5vdCBvdmVycmlkZSBhY19jdl9leGVleHQgaWYg
aXQgd2FzIGNhY2hlZCwKKyMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlz
IHRlc3QgZm9yIGNvbXBpbGVycyB1bmtub3duIHRvCisjIEF1dG9jb25mLgorZm9yIGFjX2ZpbGUg
aW4gJGFjX2ZpbGVzICcnCitkbworICB0ZXN0IC1mICIkYWNfZmlsZSIgfHwgY29udGludWUKKyAg
Y2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8
ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8
ICoubyB8ICoub2JqICkKKwk7OworICAgIFthYl0ub3V0ICkKKwkjIFdlIGZvdW5kIHRoZSBkZWZh
dWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMgbW9zdAorCSMgY2VydGFpbmx5IHJpZ2h0
LgorCWJyZWFrOzsKKyAgICAqLiogKQorCWlmIHRlc3QgIiR7YWNfY3ZfZXhlZXh0K3NldH0iID0g
c2V0ICYmIHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5vOworCXRoZW4gOjsgZWxzZQorCSAgIGFj
X2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAorCWZpCisJIyBX
ZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUgYmVjYXVzZSB0aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMg
bm90CisJIyBzYWZlOiBjcm9zcyBjb21waWxlcnMgbWF5IG5vdCBhZGQgdGhlIHN1ZmZpeCBpZiBn
aXZlbiBhbiBgLW8nCisJIyBhcmd1bWVudCwgc28gd2UgbWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0
aGF0IHBvaW50IGFscmVhZHkuCisJIyBFdmVuIGlmIHRoaXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6
IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCisJIyBhY3R1YWxseSB3b3JraW5nLgorCWJyZWFrOzsK
KyAgICAqICkKKwlicmVhazs7CisgIGVzYWMKK2RvbmUKK3Rlc3QgIiRhY19jdl9leGVleHQiID0g
bm8gJiYgYWNfY3ZfZXhlZXh0PQorCitlbHNlCisgIGFjX2ZpbGU9JycKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfZmlsZSI7IHRoZW4gOgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKyRhc19lY2hvICIk
YXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4k
YWNfZXh0ID4mNQorCit7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yIDc3ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVh
dGUgZXhlY3V0YWJsZXMKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElO
RU5PIiA1OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxlciBk
ZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEMg
Y29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lLi4uICIgPiY2OyB9Cit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2ZpbGUiID4mNQorJGFz
X2VjaG8gIiRhY19maWxlIiA+JjY7IH0KK2FjX2V4ZWV4dD0kYWNfY3ZfZXhlZXh0CisKK3JtIC1m
IC1yIGEub3V0IGEub3V0LmRTWU0gYS5leGUgY29uZnRlc3QkYWNfY3ZfZXhlZXh0IGIub3V0Cith
Y19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2YgZXhlY3V0YWJsZXMuLi4gIiA+
JjY7IH0KK2lmIHsgeyBhY190cnk9IiRhY19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAq
XCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2Vj
aG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0g
PiY1CisgIChldmFsICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0
ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBJZiBib3RoIGBjb25mdGVzdC5leGUn
IGFuZCBgY29uZnRlc3QnIGFyZSBgcHJlc2VudCcgKHdlbGwsIG9ic2VydmFibGUpCisjIGNhdGNo
IGBjb25mdGVzdC5leGUnLiAgRm9yIGluc3RhbmNlIHdpdGggQ3lnd2luLCBgbHMgY29uZnRlc3Qn
IHdpbGwKKyMgd29yayBwcm9wZXJseSAoaS5lLiwgcmVmZXIgdG8gYGNvbmZ0ZXN0LmV4ZScpLCB3
aGlsZSBpdCB3b24ndCB3aXRoCisjIGBybScuCitmb3IgYWNfZmlsZSBpbiBjb25mdGVzdC5leGUg
Y29uZnRlc3QgY29uZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVl
CisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAq
LmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRT
WU0gfCAqLm8gfCAqLm9iaiApIDs7CisgICAgKi4qICkgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNf
ZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCisJICBicmVhazs7CisgICAgKiApIGJyZWFrOzsKKyAg
ZXNhYworZG9uZQorZWxzZQorICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9y
OiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBz
dWZmaXggb2YgZXhlY3V0YWJsZXM6IGNhbm5vdCBjb21waWxlIGFuZCBsaW5rCitTZWUgXGBjb25m
aWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorZmkKK3JtIC1mIGNvbmZ0
ZXN0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dAoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9leGVleHQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9l
eGVleHQiID4mNjsgfQorCitybSAtZiBjb25mdGVzdC4kYWNfZXh0CitFWEVFWFQ9JGFjX2N2X2V4
ZWV4dAorYWNfZXhlZXh0PSRFWEVFWFQKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRpby5oPgor
aW50CittYWluICgpCit7CitGSUxFICpmID0gZm9wZW4gKCJjb25mdGVzdC5vdXQiLCAidyIpOwor
IHJldHVybiBmZXJyb3IgKGYpIHx8IGZjbG9zZSAoZikgIT0gMDsKKworICA7CisgIHJldHVybiAw
OworfQorX0FDRU9GCithY19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGNvbmZ0ZXN0Lm91
dCIKKyMgQ2hlY2sgdGhhdCB0aGUgY29tcGlsZXIgcHJvZHVjZXMgZXhlY3V0YWJsZXMgd2UgY2Fu
IHJ1bi4gIElmIG5vdCwgZWl0aGVyCisjIHRoZSBjb21waWxlciBpcyBicm9rZW4sIG9yIHdlIGNy
b3NzIGNvbXBpbGUuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZyIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmcuLi4gIiA+JjY7IH0KK2lmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciICE9IHllczsgdGhlbgorICB7IHsgYWNfdHJ5PSIkYWNfbGlu
ayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNo
bz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190
cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIK
KyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1
CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorICBpZiB7
IGFjX3RyeT0nLi9jb25mdGVzdCRhY19jdl9leGVleHQnCisgIHsgeyBjYXNlICIoKCRhY190cnki
IGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBh
Y190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9l
Y2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY190cnkiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgfTsgdGhlbgorICAgIGNyb3NzX2NvbXBpbGlu
Zz1ubworICBlbHNlCisgICAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSBtYXliZTsgdGhl
bgorCWNyb3NzX2NvbXBpbGluZz15ZXMKKyAgICBlbHNlCisJeyB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAi
Y2Fubm90IHJ1biBDIGNvbXBpbGVkIHByb2dyYW1zLgorSWYgeW91IG1lYW50IHRvIGNyb3NzIGNv
bXBpbGUsIHVzZSBcYC0taG9zdCcuCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxz
IiAiJExJTkVOTyIgNTsgfQorICAgIGZpCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRjcm9zc19jb21waWxpbmciID4mNQorJGFzX2Vj
aG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQorCitybSAtZiBjb25mdGVzdC4kYWNfZXh0IGNv
bmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5vdXQKK2FjX2NsZWFuX2ZpbGVzPSRhY19jbGVh
bl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo
ZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X29i
amV4dCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgorcm0gLWYgY29uZnRlc3QubyBjb25mdGVzdC5vYmoKK2lmIHsgeyBhY190cnk9IiRh
Y19jb21waWxlIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFj
X3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitl
dmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlf
ZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29t
cGlsZSIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAw
OyB9OyB0aGVuIDoKKyAgZm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29u
ZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOworICBjYXNlICRh
Y19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIg
fCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKKyAg
ICAqKSBhY19jdl9vYmpleHQ9YGV4cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKKyAgICAg
ICBicmVhazs7CisgIGVzYWMKK2RvbmUKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVk
IHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisK
K3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmls
ZXM6IGNhbm5vdCBjb21waWxlCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAi
JExJTkVOTyIgNTsgfQorZmkKK3JtIC1mIGNvbmZ0ZXN0LiRhY19jdl9vYmpleHQgY29uZnRlc3Qu
JGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3Zfb2JqZXh0IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfb2JqZXh0IiA+JjY7IH0K
K09CSkVYVD0kYWNfY3Zfb2JqZXh0CithY19vYmpleHQ9JE9CSkVYVAoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0
aGUgR05VIEMgY29tcGlsZXIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBh
cmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfY29t
cGlsZXJfZ251Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKyNpZm5kZWYgX19HTlVDX18K
KyAgICAgICBjaG9rZSBtZQorI2VuZGlmCisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jb21waWxlcl9n
bnU9eWVzCitlbHNlCisgIGFjX2NvbXBpbGVyX2dudT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorYWNfY3ZfY19jb21w
aWxlcl9nbnU9JGFjX2NvbXBpbGVyX2dudQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX2NvbXBpbGVyX2dudSIgPiY1CiskYXNf
ZWNobyAiJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2NvbXBpbGVy
X2dudSA9IHllczsgdGhlbgorICBHQ0M9eWVzCitlbHNlCisgIEdDQz0KK2ZpCithY190ZXN0X0NG
TEFHUz0ke0NGTEFHUytzZXR9CithY19zYXZlX0NGTEFHUz0kQ0ZMQUdTCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMg
LWciID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZy4uLiAi
ID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2NjX2crOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19zYXZlX2Nfd2Vycm9yX2ZsYWc9JGFjX2Nf
d2Vycm9yX2ZsYWcKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCisgICBhY19jdl9wcm9nX2NjX2c9
bm8KKyAgIENGTEFHUz0iLWciCisgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19nPXllcworZWxzZQorICBDRkxBR1M9IiIKKyAg
ICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNl
CisgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZworCSBDRkxBR1M9Ii1n
IgorCSBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9
CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNf
Y3ZfcHJvZ19jY19nPXllcworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRh
Y19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorICAgYWNfY193ZXJy
b3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2ciID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2ciID4mNjsgfQoraWYgdGVzdCAiJGFjX3Rlc3RfQ0ZMQUdTIiA9
IHNldDsgdGhlbgorICBDRkxBR1M9JGFjX3NhdmVfQ0ZMQUdTCitlbGlmIHRlc3QgJGFjX2N2X3By
b2dfY2NfZyA9IHllczsgdGhlbgorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENG
TEFHUz0iLWcgLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPSItZyIKKyAgZmkKK2Vsc2UKKyAgaWYg
dGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1PMiIKKyAgZWxzZQorICAgIENG
TEFHUz0KKyAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9
CitpZiAke2FjX2N2X3Byb2dfY2NfYzg5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3NhdmVfQ0M9
JENDCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4K
KyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyogTW9zdCBv
ZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3JjL2NvbmYu
c2guICAqLworc3RydWN0IGJ1ZiB7IGludCB4OyB9OworRklMRSAqICgqcmNzb3BlbikgKHN0cnVj
dCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBpKQorICAg
ICBjaGFyICoqcDsKKyAgICAgaW50IGk7Cit7CisgIHJldHVybiBwW2ldOworfQorc3RhdGljIGNo
YXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQoreworICBj
aGFyICpzOworICB2YV9saXN0IHY7CisgIHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAocCwgdmFf
YXJnICh2LGludCkpOworICB2YV9lbmQgKHYpOworICByZXR1cm4gczsKK30KKworLyogT1NGIDQu
MCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQuICBJdCBo
YXMKKyAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhIJyBoZXgg
Y2hhcmFjdGVyIGNvbnN0YW50cy4KKyAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJyb3IgdW5m
b3J0dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gnLiAgVGhl
IGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRvIGdldAor
ICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMgY29tZXMg
b3V0IHRydWUsIGZvciBhbgorICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVjZXNzYXJ5
IHRvIHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1ZSBvbmx5
IHdpdGggLXN0ZC4gICovCitpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAxIDogLTFd
OworCisvKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwgYnV0IGl0
IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBjaGFyYWN0
ZXIgY29uc3RhbnRzLiAgKi8KKyNkZWZpbmUgRk9PKHgpICd4JworaW50IHhsYzZfY2NfYXJyYXlb
Rk9PKGEpID09ICd4JyA/IDEgOiAtMV07CisKK2ludCB0ZXN0IChpbnQgaSwgZG91YmxlIHgpOwor
c3RydWN0IHMxIHtpbnQgKCpmKSAoaW50IGEpO307CitzdHJ1Y3QgczIge2ludCAoKmYpIChkb3Vi
bGUgYSk7fTsKK2ludCBwYWlybmFtZXMgKGludCwgY2hhciAqKiwgRklMRSAqKCopKHN0cnVjdCBi
dWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KSwgaW50LCBpbnQpOworaW50IGFyZ2M7CitjaGFyICoq
YXJndjsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGYgKGUsIGFyZ3YsIDApICE9IGFyZ3ZbMF0g
IHx8ICBmIChlLCBhcmd2LCAxKSAhPSBhcmd2WzFdOworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitmb3IgYWNfYXJnIGluICcnIC1xbGFuZ2x2bD1leHRjODkgLXFsYW5nbHZsPWFuc2kgLXN0
ZCBcCisJLUFlICItQWEgLURfSFBVWF9TT1VSQ0UiICItWGMgLURfX0VYVEVOU0lPTlNfXyIKK2Rv
CisgIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgorICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIk
TElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2dfY2NfYzg5PSRhY19hcmcKK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0CisgIHRlc3QgIngkYWNfY3ZfcHJv
Z19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCitkb25lCitybSAtZiBjb25mdGVzdC4kYWNfZXh0
CitDQz0kYWNfc2F2ZV9DQworCitmaQorIyBBQ19DQUNIRV9WQUwKK2Nhc2UgIngkYWNfY3ZfcHJv
Z19jY19jODkiIGluCisgIHgpCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vbmUgbmVlZGVkIiA+JjUKKyRhc19lY2hvICJub25lIG5lZWRlZCIg
PiY2OyB9IDs7CisgIHhubykKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogdW5zdXBwb3J0ZWQiID4mNQorJGFzX2VjaG8gInVuc3VwcG9ydGVkIiA+
JjY7IH0gOzsKKyAgKikKKyAgICBDQz0iJENDICRhY19jdl9wcm9nX2NjX2M4OSIKKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2df
Y2NfYzg5IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcHJvZ19jY19jODkiID4mNjsgfSA7OworZXNh
YworaWYgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0geG5vOyB0aGVuIDoKKworZmkKKwor
YWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENG
TEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29u
ZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19l
eHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisK
K2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRD
RkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgaG93IHRvIHJ1
biB0aGUgQyBwcmVwcm9jZXNzb3IiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgaG93IHRvIHJ1
biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4gIiA+JjY7IH0KKyMgT24gU3Vucywgc29tZXRpbWVzICRD
UFAgbmFtZXMgYSBkaXJlY3RvcnkuCitpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIkQ1BQ
IjsgdGhlbgorICBDUFA9CitmaQoraWYgdGVzdCAteiAiJENQUCI7IHRoZW4KKyAgaWYgJHthY19j
dl9wcm9nX0NQUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgICAgICAjIERvdWJsZSBxdW90ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhw
YW5kZWQKKyAgICBmb3IgQ1BQIGluICIkQ0MgLUUiICIkQ0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIg
Ii9saWIvY3BwIgorICAgIGRvCisgICAgICBhY19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19w
cmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhh
dCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2gg
Y3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5o
PiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2
ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVu
cyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0
aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNl
CisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlmCisJCSAgICAgU3ludGF4IGVycm9yCitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgICMgQnJv
a2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitmaQorcm0gLWYgY29uZnRlc3Qu
ZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMgT0ssIHdvcmtzIG9uIHNhbmUg
Y2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBoZWFkZXJzCisgICMgY2FuIGJl
IGRldGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhY19ub25leGlzdGVu
dC5oPgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKyAgIyBC
cm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitlbHNlCisgICMgUGFz
c2VzIGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFrCitmaQorcm0gLWYgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCitkb25lCisjIEJlY2F1c2Ugb2Yg
YGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcgY29kZSB3YXMgc2tpcHBlZC4K
K3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19leHQKK2lmICRhY19w
cmVwcm9jX29rOyB0aGVuIDoKKyAgYnJlYWsKK2ZpCisKKyAgICBkb25lCisgICAgYWNfY3ZfcHJv
Z19DUFA9JENQUAorCitmaQorICBDUFA9JGFjX2N2X3Byb2dfQ1BQCitlbHNlCisgIGFjX2N2X3By
b2dfQ1BQPSRDUFAKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJENQUCIgPiY1CiskYXNfZWNobyAiJENQUCIgPiY2OyB9CithY19wcmVwcm9jX29r
PWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMKK2RvCisgICMgVXNl
IGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmlndXJpbmcgZ2xpYmMK
KyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMgUHJlZmVyIDxsaW1p
dHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBzaW5jZQorICAjIDxs
aW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVycy4KKyAgIyBPbiB0
aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21waWxlcidzIHBhcnNl
ciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIgaXMgaGVyZSB0byBj
YXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZmRlZiBfX1NURENfXworIyBpbmNsdWRl
IDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgorI2VuZGlmCisJCSAgICAg
U3ludGF4IGVycm9yCitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4g
OgorCitlbHNlCisgICMgQnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCitm
aQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCisgICMg
T0ssIHdvcmtzIG9uIHNhbmUgY2FzZXMuICBOb3cgY2hlY2sgd2hldGhlciBub25leGlzdGVudCBo
ZWFkZXJzCisgICMgY2FuIGJlIGRldGVjdGVkIGFuZCBob3cuCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxhY19ub25leGlzdGVudC5oPgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgIyBCcm9rZW46IHN1Y2Nlc3Mgb24gaW52YWxpZCBpbnB1dC4KK2NvbnRp
bnVlCitlbHNlCisgICMgUGFzc2VzIGJvdGggdGVzdHMuCithY19wcmVwcm9jX29rPToKK2JyZWFr
CitmaQorcm0gLWYgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LmkgY29uZnRlc3QuJGFjX2V4dAorCitk
b25lCisjIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xlYW5pbmcg
Y29kZSB3YXMgc2tpcHBlZC4KK3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19leHQKK2lmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKKworZWxzZQorICB7IHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2Zu
X2Vycm9yICQ/ICJDIHByZXByb2Nlc3NvciBcIiRDUFBcIiBmYWlscyBzYW5pdHkgY2hlY2sKK1Nl
ZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9CitmaQorCith
Y19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZM
QUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25m
dGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4
dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKKwor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ3Jl
cCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQgLWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMgYW5kIC1lLi4uICIgPiY2OyB9Citp
ZiAke2FjX2N2X3BhdGhfR1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgorICBhY19wYXRoX0dS
RVBfZm91bmQ9ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0
IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9i
aW4KK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfcHJvZyBpbiBncmVwIGdncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9HUkVQ
PSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0
aF9HUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBjb250aW51ZQorIyBD
aGVjayBmb3IgR05VIGFjX3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgor
ICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAorY2FzZSBgIiRhY19wYXRoX0dSRVAiIC0t
dmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JF
UCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNfZWNob19u
IDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNhdCAiY29u
ZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNvbmZ0ZXN0
LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgor
ICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX0dSRVAi
IC1lICdHUkVQJCcgLWUgJy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0
ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJj
b25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFj
X2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0
ICR7YWNfcGF0aF9HUkVQX21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNh
dmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBhY19jdl9wYXRo
X0dSRVA9IiRhY19wYXRoX0dSRVAiCisgICAgICBhY19wYXRoX0dSRVBfbWF4PSRhY19jb3VudAor
ICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVu
b3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25lCisgIHJtIC1m
IGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNh
YworCisgICAgICAkYWNfcGF0aF9HUkVQX2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9H
UkVQIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGdyZXAgY291bGQg
YmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIg
NQorICBmaQorZWxzZQorICBhY19jdl9wYXRoX0dSRVA9JEdSRVAKK2ZpCisKK2ZpCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JF
UCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2
X3BhdGhfR1JFUCIKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZWdyZXAu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9FR1JFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIGVjaG8gYSB8ICRHUkVQIC1FICco
YXxiKScgPi9kZXYvbnVsbCAyPiYxCisgICB0aGVuIGFjX2N2X3BhdGhfRUdSRVA9IiRHUkVQIC1F
IgorICAgZWxzZQorICAgICBpZiB0ZXN0IC16ICIkRUdSRVAiOyB0aGVuCisgIGFjX3BhdGhfRUdS
RVBfZm91bmQ9ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRoIGFuZCB0ZXN0
IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI
X1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9i
aW4KK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfcHJvZyBpbiBlZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfRUdSRVA9IiRh
c19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiCisgICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0VH
UkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9FR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hl
Y2sgZm9yIEdOVSBhY19wYXRoX0VHUkVQIGFuZCBzZWxlY3QgaXQgaWYgaXQgaXMgZm91bmQuCisg
ICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9FR1JFUAorY2FzZSBgIiRhY19wYXRoX0VHUkVQIiAt
LXZlcnNpb24gMj4mMWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9F
R1JFUCIgYWNfcGF0aF9FR1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2Vj
aG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQg
ImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25m
dGVzdC50bXAiICJjb25mdGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5u
bCIKKyAgICAkYXNfZWNobyAnRUdSRVAnID4+ICJjb25mdGVzdC5ubCIKKyAgICAiJGFjX3BhdGhf
RUdSRVAiICdFR1JFUCQnIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251
bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYv
bnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19j
b3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9FR1JFUF9t
YXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBrZWVwIGxv
b2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhf
RUdSRVAiCisgICAgICBhY19wYXRoX0VHUkVQX21heD0kYWNfY291bnQKKyAgICBmaQorICAgICMg
MTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0ZXN0
ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5pbiBj
b25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAgJGFj
X3BhdGhfRUdSRVBfZm91bmQgJiYgYnJlYWsgMworICAgIGRvbmUKKyAgZG9uZQorICBkb25lCitJ
RlM9JGFzX3NhdmVfSUZTCisgIGlmIHRlc3QgLXogIiRhY19jdl9wYXRoX0VHUkVQIjsgdGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIGVncmVwIGNvdWxkIGJlIGZvdW5kIGlu
ICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKK2Vs
c2UKKyAgYWNfY3ZfcGF0aF9FR1JFUD0kRUdSRVAKK2ZpCisKKyAgIGZpCitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0VHUkVQ
IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfcGF0aF9FR1JFUCIgPiY2OyB9CisgRUdSRVA9IiRhY19j
dl9wYXRoX0VHUkVQIgorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVh
ZGVyX3N0ZGMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl
bmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RkYXJn
Lmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8ZmxvYXQuaD4KKworaW50CittYWlu
ICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29t
cGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9oZWFkZXJfc3RkYz15ZXMKK2Vsc2UKKyAg
YWNfY3ZfaGVhZGVyX3N0ZGM9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N0
ZGMgPSB5ZXM7IHRoZW4KKyAgIyBTdW5PUyA0Lnggc3RyaW5nLmggZG9lcyBub3QgZGVjbGFyZSBt
ZW0qLCBjb250cmFyeSB0byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RyaW5nLmg+
CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUgfAor
ICAkRUdSRVAgIm1lbWNociIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKworZWxzZQorICBhY19j
dl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQorCitpZiB0ZXN0ICRh
Y19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIElTQyAyLjAuMiBzdGRsaWIuaCBkb2Vz
IG5vdCBkZWNsYXJlIGZyZWUsIGNvbnRyYXJ5IHRvIEFOU0kuCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNs
dWRlIDxzdGRsaWIuaD4KKworX0FDRU9GCitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNf
ZXh0IikgMj4mNSB8CisgICRFR1JFUCAiZnJlZSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKwor
ZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQor
CitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4vY2MgaW4g
SXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcgLWFuc2ku
CisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgorZWxzZQor
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u
ZmRlZnMuaC4gICovCisjaW5jbHVkZSA8Y3R5cGUuaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNp
ZiAoKCcgJyAmIDB4MEZGKSA9PSAweDAyMCkKKyMgZGVmaW5lIElTTE9XRVIoYykgKCdhJyA8PSAo
YykgJiYgKGMpIDw9ICd6JykKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykgPyAnQScg
KyAoKGMpIC0gJ2EnKSA6IChjKSkKKyNlbHNlCisjIGRlZmluZSBJU0xPV0VSKGMpIFwKKwkJICAg
KCgnYScgPD0gKGMpICYmIChjKSA8PSAnaScpIFwKKwkJICAgICB8fCAoJ2onIDw9IChjKSAmJiAo
YykgPD0gJ3InKSBcCisJCSAgICAgfHwgKCdzJyA8PSAoYykgJiYgKGMpIDw9ICd6JykpCisjIGRl
ZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gKChjKSB8IDB4NDApIDogKGMpKQorI2VuZGlm
CisKKyNkZWZpbmUgWE9SKGUsIGYpICgoKGUpICYmICEoZikpIHx8ICghKGUpICYmIChmKSkpCitp
bnQKK21haW4gKCkKK3sKKyAgaW50IGk7CisgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykKKyAg
ICBpZiAoWE9SIChpc2xvd2VyIChpKSwgSVNMT1dFUiAoaSkpCisJfHwgdG91cHBlciAoaSkgIT0g
VE9VUFBFUiAoaSkpCisgICAgICByZXR1cm4gMjsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGFjX2N2X2hlYWRl
cl9zdGRjPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0
IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0
ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjUK
KyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfaGVh
ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgU1REQ19IRUFERVJTIDEi
ID4+Y29uZmRlZnMuaAorCitmaQorCisjIE9uIElSSVggNS4zLCBzeXMvdHlwZXMgYW5kIGludHR5
cGVzLmggYXJlIGNvbmZsaWN0aW5nLgorZm9yIGFjX2hlYWRlciBpbiBzeXMvdHlwZXMuaCBzeXMv
c3RhdC5oIHN0ZGxpYi5oIHN0cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBcCisJCSAgaW50dHlw
ZXMuaCBzdGRpbnQuaCB1bmlzdGQuaAorZG8gOgorICBhc19hY19IZWFkZXI9YCRhc19lY2hvICJh
Y19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2hlYWRl
cl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNfaW5j
bHVkZXNfZGVmYXVsdAorIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIgPSB4
InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNf
ZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQorCitk
b25lCisKKworCisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJtaW5p
eC9jb25maWcuaCIgImFjX2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giID0geHllczsg
dGhlbiA6CisgIE1JTklYPXllcworZWxzZQorICBNSU5JWD0KK2ZpCisKKworICBpZiB0ZXN0ICIk
TUlOSVgiID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF9TT1VSQ0UgMSIg
Pj5jb25mZGVmcy5oCisKKworJGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYXzFfU09VUkNFIDIiID4+
Y29uZmRlZnMuaAorCisKKyRhc19lY2hvICIjZGVmaW5lIF9NSU5JWCAxIiA+PmNvbmZkZWZzLmgK
KworICBmaQorCisKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fIiA+JjUK
KyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkZWZpbmUgX19FWFRF
TlNJT05TX18uLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNp
b25zX18rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKKyMJICBkZWZpbmUgX19FWFRFTlNJT05TX18gMQorCSAgJGFjX2lu
Y2x1ZGVzX2RlZmF1bHQKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9Citf
QUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zf
c2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX189eWVzCitlbHNlCisgIGFjX2N2X3NhZmVfdG9f
ZGVmaW5lX19fZXh0ZW5zaW9uc19fPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u
ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4
dGVuc2lvbnNfXyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5z
aW9uc19fIiA+JjY7IH0KKyAgdGVzdCAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25z
X18gPSB5ZXMgJiYKKyAgICAkYXNfZWNobyAiI2RlZmluZSBfX0VYVEVOU0lPTlNfXyAxIiA+PmNv
bmZkZWZzLmgKKworICAkYXNfZWNobyAiI2RlZmluZSBfQUxMX1NPVVJDRSAxIiA+PmNvbmZkZWZz
LmgKKworICAkYXNfZWNobyAiI2RlZmluZSBfR05VX1NPVVJDRSAxIiA+PmNvbmZkZWZzLmgKKwor
ICAkYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfUFRIUkVBRF9TRU1BTlRJQ1MgMSIgPj5jb25mZGVm
cy5oCisKKyAgJGFzX2VjaG8gIiNkZWZpbmUgX1RBTkRFTV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5o
CisKKworIyBNYWtlIHN1cmUgd2UgY2FuIHJ1biBjb25maWcuc3ViLgorJFNIRUxMICIkYWNfYXV4
X2Rpci9jb25maWcuc3ViIiBzdW40ID4vZGV2L251bGwgMj4mMSB8fAorICBhc19mbl9lcnJvciAk
PyAiY2Fubm90IHJ1biAkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgIiRMSU5FTk8iIDUK
KworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBidWls
ZCBzeXN0ZW0gdHlwZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlw
ZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9idWlsZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2J1aWxkX2FsaWFzPSRidWlsZF9hbGlh
cwordGVzdCAieCRhY19idWlsZF9hbGlhcyIgPSB4ICYmCisgIGFjX2J1aWxkX2FsaWFzPWAkU0hF
TEwgIiRhY19hdXhfZGlyL2NvbmZpZy5ndWVzcyJgCit0ZXN0ICJ4JGFjX2J1aWxkX2FsaWFzIiA9
IHggJiYKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBndWVzcyBidWlsZCB0eXBlOyB5b3UgbXVz
dCBzcGVjaWZ5IG9uZSIgIiRMSU5FTk8iIDUKK2FjX2N2X2J1aWxkPWAkU0hFTEwgIiRhY19hdXhf
ZGlyL2NvbmZpZy5zdWIiICRhY19idWlsZF9hbGlhc2AgfHwKKyAgYXNfZm5fZXJyb3IgJD8gIiRT
SEVMTCAkYWNfYXV4X2Rpci9jb25maWcuc3ViICRhY19idWlsZF9hbGlhcyBmYWlsZWQiICIkTElO
RU5PIiA1CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2J1aWxkIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfYnVpbGQiID4mNjsgfQor
Y2FzZSAkYWNfY3ZfYnVpbGQgaW4KKyotKi0qKSA7OworKikgYXNfZm5fZXJyb3IgJD8gImludmFs
aWQgdmFsdWUgb2YgY2Fub25pY2FsIGJ1aWxkIiAiJExJTkVOTyIgNTs7Citlc2FjCitidWlsZD0k
YWNfY3ZfYnVpbGQKK2FjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKK3NldCB4ICRhY19jdl9idWls
ZAorc2hpZnQKK2J1aWxkX2NwdT0kMQorYnVpbGRfdmVuZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMg
UmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQq
LAorIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgorYnVpbGRfb3M9JCoKK0lGUz0kYWNfc2F2ZV9J
RlMKK2Nhc2UgJGJ1aWxkX29zIGluICpcICopIGJ1aWxkX29zPWBlY2hvICIkYnVpbGRfb3MiIHwg
c2VkICdzLyAvLS9nJ2A7OyBlc2FjCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaG9zdCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgIngkaG9zdF9hbGlhcyIgPSB4OyB0aGVuCisgIGFjX2N2X2hvc3Q9JGFjX2N2X2J1aWxkCitl
bHNlCisgIGFjX2N2X2hvc3Q9YCRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmlnLnN1YiIgJGhvc3Rf
YWxpYXNgIHx8CisgICAgYXNfZm5fZXJyb3IgJD8gIiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWcu
c3ViICRob3N0X2FsaWFzIGZhaWxlZCIgIiRMSU5FTk8iIDUKK2ZpCisKK2ZpCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hvc3QiID4mNQor
JGFzX2VjaG8gIiRhY19jdl9ob3N0IiA+JjY7IH0KK2Nhc2UgJGFjX2N2X2hvc3QgaW4KKyotKi0q
KSA7OworKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFsdWUgb2YgY2Fub25pY2FsIGhvc3Qi
ICIkTElORU5PIiA1OzsKK2VzYWMKK2hvc3Q9JGFjX2N2X2hvc3QKK2FjX3NhdmVfSUZTPSRJRlM7
IElGUz0nLScKK3NldCB4ICRhY19jdl9ob3N0CitzaGlmdAoraG9zdF9jcHU9JDEKK2hvc3RfdmVu
ZG9yPSQyCitzaGlmdDsgc2hpZnQKKyMgUmVtZW1iZXIsIHRoZSBmaXJzdCBjaGFyYWN0ZXIgb2Yg
SUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAorIyBleGNlcHQgd2l0aCBvbGQgc2hlbGxzOgoraG9z
dF9vcz0kKgorSUZTPSRhY19zYXZlX0lGUworY2FzZSAkaG9zdF9vcyBpbiAqXCAqKSBob3N0X29z
PWBlY2hvICIkaG9zdF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKKworCisKKyMgTTQgTWFj
cm8gaW5jbHVkZXMKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKwor
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKyMgRW5h
YmxlL2Rpc2FibGUgb3B0aW9ucworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhzbSB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV94c20rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2
YWw9JGVuYWJsZV94c207CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieHllcyI7
IHRoZW4gOgorCisgICAgYXhfY3ZfeHNtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hzbSIg
PSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl94c209Im4iCisKK2VsaWYgdGVzdCAteiAkYXhf
Y3ZfeHNtOyB0aGVuIDoKKworICAgIGF4X2N2X3hzbT0ibiIKKworZmkKK3hzbT0kYXhfY3ZfeHNt
CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3Qg
IiR7ZW5hYmxlX2dpdGh0dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJs
ZV9naXRodHRwOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsg
dGhlbiA6CisKKyAgICBheF9jdl9naXRodHRwPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2dp
dGh0dHAiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKKworZWxpZiB0
ZXN0IC16ICRheF9jdl9naXRodHRwOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9Im4iCisK
K2ZpCitnaXRodHRwPSRheF9jdl9naXRodHRwCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1t
b25pdG9ycyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNl
dDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX21vbml0b3JzOworZmkKKworCitpZiB0ZXN0
ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9y
cz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgor
CisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7
IHRoZW4gOgorCisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCisKK2ZpCittb25pdG9ycz0kYXhfY3Zf
bW9uaXRvcnMKKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgoraWYg
dGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX3Z0cG07CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVu
IDoKKworICAgIGF4X2N2X3Z0cG09InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl92dHBtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2
X3Z0cG07IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ibiIKKworZmkKK3Z0cG09JGF4X2N2X3Z0
cG0KKworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhhcGkgd2FzIGdpdmVuLgoraWYgdGVzdCAi
JHtlbmFibGVfeGFwaStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hh
cGk7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hhcGkiID0gInh5ZXMiOyB0aGVuIDoKKwor
ICAgIGF4X2N2X3hhcGk9InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieG5vIjsg
dGhlbiA6CisKKyAgICBheF9jdl94YXBpPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hhcGk7
IHRoZW4gOgorCisgICAgYXhfY3ZfeGFwaT0ibiIKKworZmkKK3hhcGk9JGF4X2N2X3hhcGkKKwor
IyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3Qg
IiR7ZW5hYmxlX3B5dGhvbnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRl
bmFibGVfcHl0aG9udG9vbHM7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xz
IiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJuIgorCitlbGlmIHRl
c3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9w
eXRob250b29scz0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250b29sczsgdGhlbiA6
CisKKyAgICBheF9jdl9weXRob250b29scz0ieSIKKworZmkKK3B5dGhvbnRvb2xzPSRheF9jdl9w
eXRob250b29scworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg
ZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVf
b2NhbWx0b29scyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgor
CitlbGlmIHRlc3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAg
IGF4X2N2X29jYW1sdG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsg
dGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgorCitmaQorb2NhbWx0b29scz0kYXhf
Y3Zfb2NhbWx0b29scworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdp
dmVuLgoraWYgdGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBl
bmFibGV2YWw9JGVuYWJsZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWlu
aXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5IgorCitlbGlm
IHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X21p
bml0ZXJtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAg
IGF4X2N2X21pbml0ZXJtPSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKyMg
Q2hlY2sgd2hldGhlciAtLWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5h
YmxlX2xvbW91bnQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21v
dW50OworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6
CisKKyAgICBheF9jdl9sb21vdW50PSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQi
ID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIKKworZWxpZiB0ZXN0IC16
ICRheF9jdl9sb21vdW50OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9Im4iCisKK2ZpCits
b21vdW50PSRheF9jdl9sb21vdW50CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3
YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9kZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6Cisg
IGVuYWJsZXZhbD0kZW5hYmxlX2RlYnVnOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1
ZyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4
JGVuYWJsZV9kZWJ1ZyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisK
K2VsaWYgdGVzdCAteiAkYXhfY3ZfZGVidWc7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9Inki
CisKK2ZpCitkZWJ1Zz0kYXhfY3ZfZGVidWcKKworCisKKworCisKKworZm9yIGNmbGFnIGluICRQ
UkVQRU5EX0lOQ0xVREVTCitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9u
ZQorZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0i
IC1MJGxkZmxhZyIKK2RvbmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAg
IEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRf
TElCCitkbworICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0i
JFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVO
RF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFHUyIKKworCisKKworCisKKworCisKKwor
CisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0
cHV0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRy
dW5jYXRlIG91dHB1dC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1NFRCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAgICAgICBh
Y19zY3JpcHQ9cy9hYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJi
YmJiYmJiYmJiYmJiYmJiYmJiYmJiYmIvCisgICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7
IGRvCisgICAgICAgYWNfc2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKKyAgICAg
ZG9uZQorICAgICBlY2hvICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0
ZXN0LnNlZAorICAgICB7IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9CisgICAgIGlmIHRl
c3QgLXogIiRTRUQiOyB0aGVuCisgIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0
aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNU
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfU0VE
PSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0
aF9TRUQiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKKyMgQ2hl
Y2sgZm9yIEdOVSBhY19wYXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAj
IENoZWNrIGZvciBHTlUgJGFjX3BhdGhfU0VECitjYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNp
b24gMj4mMWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19w
YXRoX1NFRF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2
Nzg5ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0Lmlu
IiAiY29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJj
b25mdGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNf
ZWNobyAnJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Qu
c2VkIDwgImNvbmZ0ZXN0Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsK
KyAgICBkaWZmICJjb25mdGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8
IGJyZWFrCisgICAgYXNfZm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFs
CisgICAgaWYgdGVzdCAkYWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCisg
ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl
dHRlciBvbmUKKyAgICAgIGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCisgICAgICBhY19w
YXRoX1NFRF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBp
bnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYm
IGJyZWFrCisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0
Lm5sIGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBi
cmVhayAzCisgICAgZG9uZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYg
dGVzdCAteiAiJGFjX2N2X3BhdGhfU0VEIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBh
Y2NlcHRhYmxlIHNlZCBjb3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1CisgIGZp
CitlbHNlCisgIGFjX2N2X3BhdGhfU0VEPSRTRUQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKKyRh
c19lY2hvICIkYWNfY3ZfcGF0aF9TRUQiID4mNjsgfQorIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgor
ICBybSAtZiBjb25mdGVzdC5zZWQKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1Mn
CithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+
JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdT
ICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRh
Y19jdl9jX2NvbXBpbGVyX2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgor
ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28g
aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xf
cHJlZml4fWdjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIk
Q0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg
dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm
b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k
YXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgor
ICBhY19jdF9DQz0kQ0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0
aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3Zl
cnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3Qg
LW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNf
Y3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21w
aWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcg
Y3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9v
bF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNlCisgIEND
PSIkYWNfY3ZfcHJvZ19DQyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgICAgICAg
ICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2Fz
X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgK
K2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K
KyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K
KyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz
dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3By
b2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNo
byAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAg
ZmkKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y
ZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15IGNjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKKyAgYWNfcHJvZ19yZWplY3RlZD1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3Rl
ZD15ZXMKKyAgICAgICBjb250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0
aGVuCisgICMgV2UgZm91bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5l
dmVyIHVzZSBpdC4KKyAgc2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRl
c3QgJCMgIT0gMDsgdGhlbgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJv
bSB0aGUgYm9ndXMgb25lLgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1l
LCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0
byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAor
ICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQorZmkK
K2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Cisk
YXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQor
CisKK2ZpCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgZm9yIGFjX3Byb2cgaW4gY2wuZXhlCisgIGRvCisgICAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFj
X3Byb2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcHJvZ19DQz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFz
X3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIg
PiY2OyB9CitmaQorCisKKyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitp
ZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBj
bC5leGUKK2RvCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBh
Y193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9D
QyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0ND
CitpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19j
dF9DQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRl
c3QgLW4gIiRhY19jdF9DQyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0ND
IiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5n
OiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGgg
aG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3Nz
IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2Fy
bmVkPXllcyA7OworZXNhYworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0
ZXN0IC16ICIkQ0MiICYmIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGlu
IFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21w
aWxlciBmb3VuZCBpbiBcJFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMi
ICIkTElORU5PIiA1OyB9CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBj
b21waWxlci4KKyRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBDIGNvbXBpbGVyIHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBp
bGVyPSQyCitmb3IgYWNfb3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisg
IHsgeyBhY190cnk9IiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3Ry
eSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICop
IGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5
X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5j
b25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0
aGVuCisgICAgc2VkICcxMGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4u
CisgICAgICAgICAxMHEnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0
ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+
JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBH
TlUgQyBjb21waWxlciIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1
c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19jb21waWxl
cl9nbnUrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworI2lmbmRlZiBfX0dOVUNfXworICAg
ICAgIGNob2tlIG1lCisjZW5kaWYKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2NvbXBpbGVyX2dudT15
ZXMKK2Vsc2UKKyAgYWNfY29tcGlsZXJfZ251PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9jX2NvbXBpbGVy
X2dudT0kYWNfY29tcGlsZXJfZ251CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hv
ICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251
ID0geWVzOyB0aGVuCisgIEdDQz15ZXMKK2Vsc2UKKyAgR0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdT
PSR7Q0ZMQUdTK3NldH0KK2FjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3Byb2dfY2NfZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJy
b3JfZmxhZworICAgYWNfY193ZXJyb3JfZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubwor
ICAgQ0ZMQUdTPSItZyIKKyAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOwor
ICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAg
Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZk
ZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAg
YWNfY193ZXJyb3JfZmxhZz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJ
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19B
Q0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9w
cm9nX2NjX2c9eWVzCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29i
amV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9m
bGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X3Byb2dfY2NfZyIgPiY2OyB9CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0
OyB0aGVuCisgIENGTEFHUz0kYWNfc2F2ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19j
Y19nID0geWVzOyB0aGVuCisgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdT
PSItZyAtTzIiCisgIGVsc2UKKyAgICBDRkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0
ICIkR0NDIiA9IHllczsgdGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdT
PQorICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19jY19jODkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MK
K2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2lu
Y2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRo
ZSBmb2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4g
ICovCitzdHJ1Y3QgYnVmIHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1
ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNo
YXIgKipwOworICAgICBpbnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAq
ZiAoY2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIg
KnM7CisgIHZhX2xpc3QgdjsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcg
KHYsaW50KSk7CisgIHZhX2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENv
bXBhcSBjYyBpcyBzb21lIHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcwor
ICAgZnVuY3Rpb24gcHJvdG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFy
YWN0ZXIgY29uc3RhbnRzLgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1
bmF0ZWx5LCBpbnN0ZWFkIGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9s
bG93aW5nIGluZHVjZXMgYW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBw
cm9wZXIgQU5TSSBtb2RlLiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQg
dHJ1ZSwgZm9yIGFuCisgICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8g
d3JpdGUgJ1x4MDAnPT0wIHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0
aCAtc3RkLiAgKi8KK2ludCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisK
Ky8qIElCTSBDIDYgZm9yIEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVw
bGFjZXMgbWFjcm8gcGFyYW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBj
b25zdGFudHMuICAqLworI2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08o
YSkgPT0gJ3gnID8gMSA6IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1
Y3QgczEge2ludCAoKmYpIChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBh
KTt9OworaW50IHBhaXJuYW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAq
LCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2
OworaW50CittYWluICgpCit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwg
IGYgKGUsIGFyZ3YsIDEpICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2ZvciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwK
KwktQWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAg
Q0M9IiRhY19zYXZlX0NDICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2Nj
X2M4OSIgIT0gInhubyIgJiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0ND
PSRhY19zYXZlX0NDCisKK2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2Nj
X2M4OSIgaW4KKyAgeCkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7
IH0gOzsKKyAgeG5vKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsg
fSA7OworICAqKQorICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19j
ODkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitp
ZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19l
eHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdT
ICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVz
dCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAk
TElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAt
cyB3b3JrcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4u
ICIgPiY2OyB9CitMTl9TPSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMi
ID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2Vj
aG8gIm5vLCB1c2luZyAkTE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQo
TUFLRSkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0
cyBcJChNQUtFKS4uLiAiID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNf
ZWNobyAiJDIiIHwgc2VkICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwg
XCR7YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9B
Q0VPRgorU0hFTEwgPSAvYmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUl
JScKK19BQ0VPRgorIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmlu
ZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNv
bmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUlKikKKyAgICBl
dmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQorICAgIGV2YWwg
YWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1mIGNvbmZ0ZXN0
Lm1ha2UKK2ZpCitpZiBldmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQg
PSB5ZXM7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0i
CitmaQorCisjIEZpbmQgYSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJv
Z3JhbSAoZmFzdGVyKSwKKyMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBC
dXQgYXZvaWQgdGhlIGJyb2tlbiBvcgorIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6CisjIFN5c1Yg
L2V0Yy9pbnN0YWxsLCAvdXNyL3NiaW4vaW5zdGFsbAorIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxs
CisjIElSSVggL3NiaW4vaW5zdGFsbAorIyBBSVggL2Jpbi9pbnN0YWxsCisjIEFtaWdhT1MgL0Mv
aW5zdGFsbCwgd2hpY2ggaW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKKyMgQUlY
IDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBm
bGFnCisjIEFGUyAvdXNyL2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4
aXN0ZW50IGFyZ3MKKyMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2Ug
dGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiIKKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3
aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYworIyAuL2luc3RhbGwsIHdo
aWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2gu
CisjIFJlamVjdCBpbnN0YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUg
ZmlsZXMuCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQoraWYgdGVzdCAteiAiJElO
U1RBTEwiOyB0aGVuCitpZiAke2FjX2N2X3BhdGhfaW5zdGFsbCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAjIEFjY291bnQgZm9y
IHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KK2Nhc2Ug
JGFzX2Rpci8gaW4gIygoCisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0Yy8qIHwgL3Vz
ci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCisg
ID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11JTlNUQUxMW1xc
L10qIHwgXAorICAvdXNyL3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5kIFNDTyBPRFQg
My4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9uJ3QgdXNlIGlu
c3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9vdAorICAgICMg
YnkgZGVmYXVsdC4KKyAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0IGluc3RhbGw7
IGRvCisgICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKwlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiICYmICRh
c190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVuCisJICBpZiB0
ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFzX2Rpci8kYWNf
cHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgQUlYIGluc3Rh
bGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KKwkgICAgOgor
CSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3cGx1cyAiJGFz
X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMg
cHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3Qg
dXNlLgorCSAgICA6CisJICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3Qu
dHdvIGNvbmZ0ZXN0LmRpcgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQorCSAgICBlY2hv
IHR3byA+IGNvbmZ0ZXN0LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkgICAgaWYgIiRh
c19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28g
ImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0
ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0
ZXN0Lm9uZSAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0LnR3bworCSAg
ICB0aGVuCisJICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4
ZWNfZXh0IC1jIgorCSAgICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkKKyAgICAgIGRv
bmUKKyAgICBkb25lCisgICAgOzsKK2VzYWMKKworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
K3JtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCitmaQorICBp
ZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgorICAgIElOU1RB
TEw9JGFjX2N2X3BhdGhfaW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1
c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMgdmFsdWUgZm9y
IElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKKyAg
ICAjIGJyZWFrIG90aGVyIHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0IGRpcmVjdG9y
eSBpcworICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUgbmFtZS4K
KyAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIk
SU5TVEFMTCIgPiY2OyB9CisKKyMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFu
ZGxlcyBicmFjZXMgaW4gJHt2YXItdmFsfS4KKyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBi
cmFjZSBlbmRzIHRoZSB2YXJpYWJsZSBzdWJzdGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9Q
Uk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNU
QUxMX1NDUklQVCIgJiYgSU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJ
TlNUQUxMX0RBVEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Bh
dGhfUEVSTCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGNhc2UgJFBFUkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhf
UEVSTD0iJFBFUkwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRo
LgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm
b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh
c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh
YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07
IHRoZW4KKyAgICBhY19jdl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYg
YWNfY3ZfcGF0aF9QRVJMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitQRVJMPSRhY19jdl9wYXRoX1BF
UkwKK2lmIHRlc3QgLW4gIiRQRVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke1BF
Ukx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBw
ZXJsLCBwbGVhc2UgaW5zdGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiYnJjdGwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IGJyY3RsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9CUkNU
TCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGNhc2UgJEJSQ1RMIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JSQ1RM
PSIkQlJDVEwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor
ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig
YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k
aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl
X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo
ZW4KKyAgICBhY19jdl9wYXRoX0JSQ1RMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JSQ1RMIiAmJiBh
Y19jdl9wYXRoX0JSQ1RMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCUkNUTD0kYWNfY3ZfcGF0aF9C
UkNUTAoraWYgdGVzdCAtbiAiJEJSQ1RMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEJSQ1RMIiA+JjUKKyRhc19lY2hvICIkQlJDVEwi
ID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4
IiR7QlJDVEx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8g
ZmluZCBicmN0bCwgcGxlYXNlIGluc3RhbGwgYnJjdGwiICIkTElORU5PIiA1CitmaQorIyBFeHRy
YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJpcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgaXA7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hv
X24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0lQ
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkSVAgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSVA9IiRJUCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICop
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFj
X2N2X3BhdGhfSVA9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfSVAiICYmIGFjX2N2X3BhdGhfSVA9Im5v
IgorICA7OworZXNhYworZmkKK0lQPSRhY19jdl9wYXRoX0lQCitpZiB0ZXN0IC1uICIkSVAiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
SVAiID4mNQorJGFzX2VjaG8gIiRJUCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m
NjsgfQorZmkKKworCitpZiB0ZXN0IHgiJHtJUH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5f
ZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGlwLCBwbGVhc2UgaW5zdGFsbCBpcCIgIiRMSU5FTk8i
IDUKK2ZpCisjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj
X3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9
CitpZiAke2FjX2N2X3BhdGhfQklTT04rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9d
KikKKyAgYWNfY3ZfcGF0aF9CSVNPTj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CSVNPTj0iJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh
ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIk
YWNfY3ZfcGF0aF9CSVNPTiIgJiYgYWNfY3ZfcGF0aF9CSVNPTj0ibm8iCisgIDs7Citlc2FjCitm
aQorQklTT049JGFjX2N2X3BhdGhfQklTT04KK2lmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIg
PiY1CiskYXNfZWNobyAiJEJJU09OIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JJU09OfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19m
bl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYmlzb24sIHBsZWFzZSBpbnN0YWxsIGJpc29uIiAi
JExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0
IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgZmxleDsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3BhdGhfRkxFWCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEZMRVggaW4KKyAgW1xcL10qIHwgPzpb
XFwvXSopCisgIGFjX2N2X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl
IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAi
JGFjX2N2X3BhdGhfRkxFWCIgJiYgYWNfY3ZfcGF0aF9GTEVYPSJubyIKKyAgOzsKK2VzYWMKK2Zp
CitGTEVYPSRhY19jdl9wYXRoX0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQor
JGFzX2VjaG8gIiRGTEVYIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9Citm
aQorCisKK2lmIHRlc3QgeCIke0ZMRVh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9y
ICQ/ICJVbmFibGUgdG8gZmluZCBmbGV4LCBwbGVhc2UgaW5zdGFsbCBmbGV4IiAiJExJTkVOTyIg
NQorZmkKK2lmIHRlc3QgIngkeGFwaSIgPSAieHkiOyB0aGVuIDoKKworICAgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcGF0aF9DVVJMKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgY2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNf
Y3ZfcGF0aF9DVVJMPSIkQ1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0
aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3Vu
ZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitk
b25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9D
VVJMIiAmJiBhY19jdl9wYXRoX0NVUkw9Im5vIgorICA7OworZXNhYworZmkKK0NVUkw9JGFjX2N2
X3BhdGhfQ1VSTAoraWYgdGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENV
UkwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVz
dCB4IiR7Q1VSTH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8i
IDUKK2ZpCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25m
aWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf
d29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1hNTCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhNTCBpbgorICBbXFwv
XSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0k
SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9
JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj
X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz
dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hNTD0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMK
K2ZpCitYTUw9JGFjX2N2X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1Cisk
YXNfZWNobyAiJFhNTCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworCitpZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/
ICJVbmFibGUgdG8gZmluZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWci
ICIkTElORU5PIiA1CitmaQorCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRo
ZW4gOgorCisgICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgaWYgdGVzdCAtbiAiJGFjX3Rv
b2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9v
bF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K
K3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3Byb2dfT0NBTUxDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19P
Q0FNTEM9IiRPQ0FNTEMiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQor
YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU
SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9
LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk
bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190
ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf
cHJvZ19PQ0FNTEM9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK09DQU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FN
TEMiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkT0NBTUxDIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19P
Q0FNTEMiOyB0aGVuCisgIGFjX2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSBvY2FtbGM7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Citl
bHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxDPSIkYWNfY3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSJvY2FtbGMiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKK2ZpCitmaQorYWNfY3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19j
dF9PQ0FNTEMiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9PQ0FNTEMiID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCisgIGVs
c2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBj
cm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxD
PSRhY19jdF9PQ0FNTEMKKyAgZmkKK2Vsc2UKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMi
CitmaQorCisKKyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZF
UlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxw
J2AKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IE9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVy
c2lvbiBpcyAkT0NBTUxWRVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQs
IHVzZSBpdAorICAgICBpZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NB
TUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxj
dXQgLWQgJyAnIC1mIDRgCisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVz
ZXJ2aW5nIGl0LiIgPiY1CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNl
cnZpbmcgaXQuIiA+JjY7IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIi
ID4mNQorJGFzX2VjaG8gIk9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQor
CisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRh
Y190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg
YXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNf
d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0K
K2lmICR7YWNfY3ZfcHJvZ19PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAg
YWNfY3ZfcHJvZ19PQ0FNTE9QVD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0
aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2Zv
ciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFz
X2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFi
bGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsg
dGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQi
CisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBk
b25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NB
TUxPUFQKK2lmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAi
JE9DQU1MT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
K2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NB
TUxPUFQ9JE9DQU1MT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQi
LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1s
b3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj
X3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0i
JGFjX2N0X09DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxPUFQ9Im9jYW1sb3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4m
NQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitm
aQorZmkKK2FjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0
IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRh
Y19jdF9PQ0FNTE9QVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0i
bm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisg
ICAgT0NBTUxPUFQ9JGFjX2N0X09DQU1MT1BUCisgIGZpCitlbHNlCisgIE9DQU1MT1BUPSIkYWNf
Y3ZfcHJvZ19PQ0FNTE9QVCIKK2ZpCisKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVz
dCAiJE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21w
aWxhdGlvbiBvbmx5LiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmlu
ZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UK
KwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCgu
KlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7
IHRoZW4KKwkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4m
NQorJGFzX2VjaG8gInZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2Nh
cmRlZC4iID4mNjsgfQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9w
dAorCWZpCisgICAgIGZpCisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAg
ICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZp
cnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2Ft
bGMub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0
IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9D
QU1MQ0RPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9n
X09DQU1MQ0RPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0IgorICAgICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf
ZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19z
YXZlX0lGUworCitmaQorZmkKK09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQK
K2lmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hv
ICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9Citm
aQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCisg
IGFjX2N0X09DQU1MQ0RPVE9QVD0kT0NBTUxDRE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAib2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgb2NhbWxjLm9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2df
YWNfY3RfT0NBTUxDRE9UT1BUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENE
T1RPUFQ9Im9jYW1sYy5vcHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3Rf
T0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAi
JGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8g
IiRhY19jdF9PQ0FNTENET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgorICAg
IE9DQU1MQ0RPVE9QVD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFj
X3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0
IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9v
bHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9
eWVzIDs7Citlc2FjCisgICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKKyAgZmkK
K2Vsc2UKKyAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCitmaQorCisg
ICAgIGlmIHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAk
T0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcg
YAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9u
cyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2Vj
aG8gInZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIg
PiY2OyB9CisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisK
KyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9Q
VCIgIT0gIm5vIiA7IHRoZW4KKwlpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5v
cHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJv
Z19PQ0FNTE9QVERPVE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19PQ0FNTE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBv
dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB
UkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVz
dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9w
cmVmaXh9b2NhbWxvcHQub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFr
IDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1M
T1BURE9UT1BUPSRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxP
UFRET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkT0NBTUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVERPVE9Q
VCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYg
dGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1M
T1BURE9UT1BUPSRPQ0FNTE9QVERPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
Im9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgb2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTE9QVERPVE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4K
KyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BU
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFRET1RPUFQ9Im9jYW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2Zp
CithY19jdF9PQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAor
aWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BU
IiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor
JGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERP
VE9QVCIgPSB4OyB0aGVuCisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2Fz
ZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdB
Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg
PiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRh
Y19jdF9PQ0FNTE9QVERPVE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2
X3Byb2dfT0NBTUxPUFRET1RPUFQiCitmaQorCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAh
PSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1u
IC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJT
SU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1s
Yzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb24gZGlmZmVy
cyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgIGVsc2UK
KwkgICAgICBPQ0FNTE9QVD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAg
ICBmaQorCisKKyAgZmkKKworCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAg
aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0
IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dv
cmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi
ID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2Vj
aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgor
ICBhY19jdl9wcm9nX09DQU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcHJvZ19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKKyAgICAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k
YXNfc2F2ZV9JRlMKKworZmkKK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAt
biAiJE9DQU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJE9DQU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9w
cm9nX09DQU1MIjsgdGhlbgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFy
Z3MuCitzZXQgZHVtbXkgb2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0
X09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0
X09DQU1MPSIkYWNfY3RfT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0Lgor
ZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBp
biAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBh
c19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNp
b25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYm
ICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAg
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0ib2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorYWNfY3RfT0NBTUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRh
Y19jdF9PQ0FNTCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngk
YWNfY3RfT0NBTUwiID0geDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2Ug
JGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v
dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJO
SU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4m
Mjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwK
KyAgZmkKK2Vsc2UKKyAgT0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgorZmkKKworCisgICMgY2hl
Y2tpbmcgZm9yIG9jYW1sZGVwCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVw
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FN
TERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0i
JE9DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
T0NBTUxERVA9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKK2ZpCitmaQorT0NBTUxERVA9JGFjX2N2X3Byb2dfT0NBTUxERVAKK2lmIHRlc3QgLW4gIiRP
Q0FNTERFUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRPQ0FNTERFUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNf
Y3ZfcHJvZ19PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7
IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9
Im9jYW1sZGVwIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MREVQ
PSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAi
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3RfT0NBTUxERVAiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9
CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0
X09DQU1MREVQIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNl
ICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09D
QU1MREVQCisgIGZpCitlbHNlCisgIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKK2Zp
CisKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRlc3QgLW4gIiRhY190b29s
X3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xf
cHJlZml4fW9jYW1sbWt0b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv
cmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Citp
ZiAke2FjX2N2X3Byb2dfT0NBTUxNS1RPUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgor
ICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29sX3ByZWZpeH1v
Y2FtbG1rdG9wIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv
dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK
K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MTUtUT1A9JGFj
X2N2X3Byb2dfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RP
UCIgPiY1CiskYXNfZWNobyAiJE9DQU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8g
Im5vIiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtU
T1AiOyB0aGVuCisgIGFjX2N0X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICJvY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0
aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0X09DQU1MTUtUT1AiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1L
VE9QPSJvY2FtbG1rdG9wIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09D
QU1MTUtUT1A9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJGFjX2N0
X09DQU1MTUtUT1AiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09D
QU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJu
byIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4K
K3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6
IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQg
d2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAg
ICBPQ0FNTE1LVE9QPSRhY19jdF9PQ0FNTE1LVE9QCisgIGZpCitlbHNlCisgIE9DQU1MTUtUT1A9
IiRhY19jdl9wcm9nX09DQU1MTUtUT1AiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxt
a2xpYgorICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4
fW9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MTUtMSUIrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0
ZXN0IC1uICIkT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NB
TUxNS0xJQiIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09D
QU1MTUtMSUI9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKKworZmkKK2ZpCitPQ0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKK2lmIHRlc3Qg
LW4gIiRPQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LTElC
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LTElC
PSRPQ0FNTE1LTElCCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta2xpYiIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxt
a2xpYjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh
Y193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQis6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1M
TUtMSUI9IiRhY19jdF9PQ0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf
c2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09D
QU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtM
SUIiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS0xJQiIg
PSB4OyB0aGVuCisgICAgT0NBTUxNS0xJQj0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19j
b21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4
ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNp
bmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNf
dG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxNS0xJQj0kYWNfY3RfT0NBTUxNS0xJ
QgorICBmaQorZWxzZQorICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIgorZmkK
KworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sZG9jIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJv
Z19PQ0FNTERPQz0iJE9DQU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfT0NBTUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9
JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lm
IHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9D
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxET0M9JE9D
QU1MRE9DCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZG9jOyBhY193
b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g
IiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19j
dF9PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09D
QU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNf
Y3RfT0NBTUxET0M9Im9jYW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2Fj
X2N0X09DQU1MRE9DPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNf
Y3RfT0NBTUxET0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FN
TERPQyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0
ZXN0ICJ4JGFjX2N0X09DQU1MRE9DIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERPQz0ibm8iCisgIGVs
c2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBj
cm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z
dCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxE
T0M9JGFjX2N0X09DQU1MRE9DCisgIGZpCitlbHNlCisgIE9DQU1MRE9DPSIkYWNfY3ZfcHJvZ19P
Q0FNTERPQyIKK2ZpCisKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3Qg
LW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h
bWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNf
d29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfT0NBTUxCVUlMRCs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJV
SUxEIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190
b29sX3ByZWZpeH1vY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09D
QU1MQlVJTEQ9JGFjX2N2X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQi
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9w
cm9nX09DQU1MQlVJTEQiOyB0aGVuCisgIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEg
cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEKzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQlVJTEQiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09D
QU1MQlVJTEQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8K
KyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAg
IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBp
ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK2FjX2N0X09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVz
dCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNo
byAiJGFjX2N0X09DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBP
Q0FNTEJVSUxEPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9v
bF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp
cGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu
b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMg
OzsKK2VzYWMKKyAgICBPQ0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisg
IE9DQU1MQlVJTEQ9IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiCitmaQorCisKKyAgICBpZiB0ZXN0
ICJ4JE9DQU1MQyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICAgICAgaWYgdGVzdCAieCRlbmFibGVf
b2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgICAgICAgICBhc19mbl9lcnJvciAk
PyAiT2NhbWwgdG9vbHMgZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVO
TyIgNQorZmkKKyAgICAgICAgb2NhbWx0b29scz0ibiIKKworZmkKKworZmkKKyMgRXh0cmFjdCB0
aGUgZmlyc3Qgd29yZCBvZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCitzZXQgZHVtbXkgYmFzaDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f
biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfQkFT
SCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGNhc2UgJEJBU0ggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkFTSD0i
JEJBU0giICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7
OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNf
ZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
KyAgICBhY19jdl9wYXRoX0JBU0g9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJ
RlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkFTSCIgJiYgYWNfY3Zf
cGF0aF9CQVNIPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCQVNIPSRhY19jdl9wYXRoX0JBU0gKK2lm
IHRlc3QgLW4gIiRCQVNIIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJEJBU0giID4mNQorJGFzX2VjaG8gIiRCQVNIIiA+JjY7IH0KK2Vs
c2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JBU0h9IiA9
PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBw
bGVhc2UgaW5zdGFsbCBiYXNoIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkcHl0aG9udG9v
bHMiID0gInh5IjsgdGhlbiA6CisKKyAgICBpZiBlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4v
IjsgdGhlbiA6CisKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1g
YmFzZW5hbWUgJFBZVEhPTlBBVEhgCisKK2VsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgor
ICBQWVRIT049InB5dGhvbiIKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZp
ZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3Jh
bSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcGF0aF9QWVRIT05QQVRIKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/Oltc
XC9dKikKKyAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVz
ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUFlU
SE9OUEFUSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9J
RlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZ
VEhPTlBBVEg9Im5vIgorICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlU
SE9OUEFUSAoraWYgdGVzdCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNf
ZWNobyAiJFBZVEhPTlBBVEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0K
K2ZpCisKKworaWYgdGVzdCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNf
Zm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRI
T04iICIkTElORU5PIiA1CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2Ak
UFlUSE9OIC1jICdpbXBvcnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwg
MykiKSknYAoraWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAk
UFlUSE9OIC1WIDI+JjFgCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgICAgYXNfZm5fZXJy
b3IgJD8gIiRweXRob25fdmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNp
b24gaXMgMi4zIiAiJExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9
CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHB5dGhvbiB4bWwuZG9tLm1pbmlkb20iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiB4bWwuZG9tLm1pbmlkb20uLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBv
cnQgeG1sLmRvbS5taW5pZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1s
LmRvbS5taW5pZG9tIG1vZHVsZSIgIiRMSU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5
ZXMiID4mNjsgfQorZmkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBweXRob24gZGV2ZWwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiBkZXZlbC4uLiAiID4mNjsgfQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3Mu
cGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsg
Ii9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisn
ID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiUHl0aG9uIGRldmVsIHBhY2th
Z2Ugbm90IGZvdW5kIiAiJExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2
OyB9CitmaQorCitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNv
IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7
IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29y
ZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1hHRVRURVhUKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkWEdFVFRFWFQgaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIg
IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICop
CisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4g
JFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf
ZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u
czsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk
YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFj
X2N2X3BhdGhfWEdFVFRFWFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9
JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2
X3BhdGhfWEdFVFRFWFQ9Im5vIgorICA7OworZXNhYworZmkKK1hHRVRURVhUPSRhY19jdl9wYXRo
X1hHRVRURVhUCitpZiB0ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQorJGFzX2Vj
aG8gIiRYR0VUVEVYVCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworCitpZiB0ZXN0IHgiJHtYR0VUVEVYVH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJy
b3IgJD8gIlVuYWJsZSB0byBmaW5kIHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIg
IiRMSU5FTk8iIDUKK2ZpCitpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhl
bgorICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmFkbSIsIHNvIGl0IGNhbiBi
ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgdWRldmFkbTsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3BhdGhfVURFVkFETSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hv
X24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFVERVZBRE0gaW4KKyAgW1xcL10qIHwg
PzpbXFwvXSopCisgIGFjX2N2X3BhdGhfVURFVkFETT0iJFVERVZBRE0iICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lG
Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsg
dGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZB
RE09IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfVURFVkFETSIgJiYgYWNfY3ZfcGF0aF9VREVWQURNPSJu
byIKKyAgOzsKK2VzYWMKK2ZpCitVREVWQURNPSRhY19jdl9wYXRoX1VERVZBRE0KK2lmIHRlc3Qg
LW4gIiRVREVWQURNIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJFVERVZBRE0iID4mNQorJGFzX2VjaG8gIiRVREVWQURNIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtV
REVWQURNfSIgPT0geCJubyIKKyAgICB0aGVuCisgICAgICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAidWRldmluZm8iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15IHVkZXZpbmZvOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9VREVW
SU5GTys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhc2UgJFVERVZJTkZPIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRo
X1VERVZJTkZPPSIkVURFVklORk8iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdp
dGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRh
Y19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZJTkZPPSIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9w
YXRoX1VERVZJTkZPIiAmJiBhY19jdl9wYXRoX1VERVZJTkZPPSJubyIKKyAgOzsKK2VzYWMKK2Zp
CitVREVWSU5GTz0kYWNfY3ZfcGF0aF9VREVWSU5GTworaWYgdGVzdCAtbiAiJFVERVZJTkZPIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFVERVZJTkZPIiA+JjUKKyRhc19lY2hvICIkVURFVklORk8iID4mNjsgfQorZWxzZQorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFz
X2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30i
ID09IHgibm8iCisgICAgICAgIHRoZW4KKyAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFi
bGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2IiAiJExJ
TkVOTyIgNQorICAgICAgICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3
ayAne3ByaW50ICRORn0nYAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBp
bmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZl
cn0gLWx0IDU5CisgICAgdGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg
ImhvdHBsdWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15IGhvdHBsdWc7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0hPVFBMVUcrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRI
T1RQTFVHIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0hPVFBMVUc9IiRI
T1RQTFVHIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAg
OzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcGF0aF9IT1RQTFVHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0hPVFBMVUciICYm
IGFjX2N2X3BhdGhfSE9UUExVRz0ibm8iCisgIDs7Citlc2FjCitmaQorSE9UUExVRz0kYWNfY3Zf
cGF0aF9IT1RQTFVHCitpZiB0ZXN0IC1uICIkSE9UUExVRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRIT1RQTFVHIiA+JjUKKyRhc19l
Y2hvICIkSE9UUExVRyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkK
KworCisgICAgICAgIGlmIHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVu
CisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAidWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRv
IHZlcnNpb24gNTkgb3IgbGF0ZXIiICIkTElORU5PIiA1CisgICAgICAgIGZpCisgICAgZmkKK2Vs
c2UKKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInZuY29uZmlnIiwgc28gaXQgY2Fu
IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB2bmNvbmZpZzsgYWNfd29y
ZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X3BhdGhfVk5DT05GSUcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRWTkNPTkZJRyBpbgorICBbXFwv
XSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJFZOQ09ORklHIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9WTkNPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9WTkNPTkZJRyIgJiYgYWNfY3ZfcGF0aF9W
TkNPTkZJRz0ibm8iCisgIDs7Citlc2FjCitmaQorVk5DT05GSUc9JGFjX2N2X3BhdGhfVk5DT05G
SUcKK2lmIHRlc3QgLW4gIiRWTkNPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRWTkNPTkZJRyIgPiY1CiskYXNfZWNobyAiJFZO
Q09ORklHIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAg
ICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBhc19m
bl9lcnJvciAkPyAiTm90IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmQiICIk
TElORU5PIiA1CisgICAgZmkKK2ZpCisKK2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1n
bnUiCit0aGVuCisgICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInV1
aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoK
KworZWxzZQorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJ
TkVOTyIgNQorZmkKKworCitlbHNlCisgICAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi
JExJTkVOTyIgInV1aWQuaCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4eWVzOyB0aGVuIDoKKwor
ZWxzZQorICBhc19mbl9lcnJvciAkPyAiY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzIiAiJExJTkVO
TyIgNQorZmkKKworCitmaQorCisKKworCisKKworCitpZiB0ZXN0ICJ4JGFjX2N2X2Vudl9QS0df
Q09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCisJaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4
IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9
cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcGF0aF9QS0dfQ09ORklHKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9d
KikKKyAgYWNfY3ZfcGF0aF9QS0dfQ09ORklHPSIkUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUEtHX0NP
TkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK
KworICA7OworZXNhYworZmkKK1BLR19DT05GSUc9JGFjX2N2X3BhdGhfUEtHX0NPTkZJRworaWYg
dGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJFBLR19D
T05GSUciID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworZmkK
K2lmIHRlc3QgLXogIiRhY19jdl9wYXRoX1BLR19DT05GSUciOyB0aGVuCisgIGFjX3B0X1BLR19D
T05GSUc9JFBLR19DT05GSUcKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwa2ctY29u
ZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBw
a2ctY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm
b3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklH
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkYWNfcHRfUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYWNfcHRfUEtHX0NPTkZJRyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfYWNfcHRf
UEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworICA7OworZXNhYworZmkKK2FjX3B0X1BLR19DT05GSUc9JGFjX2N2X3BhdGhfYWNf
cHRfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAiJGFjX3B0X1BLR19DT05GSUciOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcHRfUEtH
X0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJGFjX3B0X1BLR19DT05GSUciID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19wdF9QS0dfQ09O
RklHIiA9IHg7IHRoZW4KKyAgICBQS0dfQ09ORklHPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9z
c19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl
Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQor
YWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgUEtHX0NPTkZJRz0kYWNfcHRfUEtHX0NP
TkZJRworICBmaQorZWxzZQorICBQS0dfQ09ORklHPSIkYWNfY3ZfcGF0aF9QS0dfQ09ORklHIgor
ZmkKKworZmkKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorCV9wa2dfbWluX3ZlcnNp
b249MC45LjAKKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIHBrZy1jb25maWcgaXMgYXQgbGVhc3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbiIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9w
a2dfbWluX3ZlcnNpb24uLi4gIiA+JjY7IH0KKwlpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtn
Y29uZmlnLXZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb247IHRoZW4KKwkJeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVz
IiA+JjY7IH0KKwllbHNlCisJCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCQlQS0dfQ09ORklHPSIi
CisJZmkKK2ZpCisKK3BrZ19mYWlsZWQ9bm8KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdsaWIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIGdsaWIuLi4gIiA+JjY7IH0KKworaWYgdGVzdCAtbiAiJGdsaWJfQ0ZMQUdTIjsgdGhlbgor
ICAgIHBrZ19jdl9nbGliX0NGTEFHUz0iJGdsaWJfQ0ZMQUdTIgorIGVsaWYgdGVzdCAtbiAiJFBL
R19DT05GSUciOyB0aGVuCisgICAgaWYgdGVzdCAtbiAiJFBLR19DT05GSUciICYmIFwKKyAgICB7
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCRQS0dfQ09ORklHIC0t
ZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0yLjBcIiI7IH0gPiY1CisgICgkUEtHX0NPTkZJ
RyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiKSAyPiY1CisgIGFjX3N0YXR1cz0k
PworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3Rh
dHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbgorICBwa2dfY3ZfZ2xpYl9D
RkxBR1M9YCRQS0dfQ09ORklHIC0tY2ZsYWdzICJnbGliLTIuMCIgMj4vZGV2L251bGxgCitlbHNl
CisgIHBrZ19mYWlsZWQ9eWVzCitmaQorIGVsc2UKKyAgICBwa2dfZmFpbGVkPXVudHJpZWQKK2Zp
CitpZiB0ZXN0IC1uICIkZ2xpYl9MSUJTIjsgdGhlbgorICAgIHBrZ19jdl9nbGliX0xJQlM9IiRn
bGliX0xJQlMiCisgZWxpZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KKyAgICBpZiB0ZXN0
IC1uICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBcJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1lcnJvcnMgXCJnbGli
LTIuMFwiIjsgfSA+JjUKKyAgKCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzICJn
bGliLTIuMCIpIDI+JjUKKyAgYWNfc3RhdHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMg
PSAwOyB9OyB0aGVuCisgIHBrZ19jdl9nbGliX0xJQlM9YCRQS0dfQ09ORklHIC0tbGlicyAiZ2xp
Yi0yLjAiIDI+L2Rldi9udWxsYAorZWxzZQorICBwa2dfZmFpbGVkPXllcworZmkKKyBlbHNlCisg
ICAgcGtnX2ZhaWxlZD11bnRyaWVkCitmaQorCisKKworaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHll
czsgdGhlbgorICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorCitpZiAkUEtHX0NPTkZJRyAtLWF0
bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gMC4yMDsgdGhlbgorICAgICAgICBfcGtnX3Nob3J0X2Vy
cm9yc19zdXBwb3J0ZWQ9eWVzCitlbHNlCisgICAgICAgIF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBv
cnRlZD1ubworZmkKKyAgICAgICAgaWYgdGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVk
ID0geWVzOyB0aGVuCisJICAgICAgICBnbGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hv
cnQtZXJyb3JzIC0tcHJpbnQtZXJyb3JzICJnbGliLTIuMCIgMj4mMWAKKyAgICAgICAgZWxzZQor
CSAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xp
Yi0yLjAiIDI+JjFgCisgICAgICAgIGZpCisJIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2Ug
aW4gY29uZmlnLmxvZyB3aGVyZSBpdCBiZWxvbmdzCisJZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIg
PiY1CisKKwlhc19mbl9lcnJvciAkPyAiUGFja2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3
ZXJlIG5vdCBtZXQ6CisKKyRnbGliX1BLR19FUlJPUlMKKworQ29uc2lkZXIgYWRqdXN0aW5nIHRo
ZSBQS0dfQ09ORklHX1BBVEggZW52aXJvbm1lbnQgdmFyaWFibGUgaWYgeW91CitpbnN0YWxsZWQg
c29mdHdhcmUgaW4gYSBub24tc3RhbmRhcmQgcHJlZml4LgorCitBbHRlcm5hdGl2ZWx5LCB5b3Ug
bWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xpYl9M
SUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtnLWNv
bmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLiIgIiRMSU5FTk8iIDUKK2VsaWYgdGVzdCAk
cGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KKyAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQor
CXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIlRoZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUg
Zm91bmQgb3IgaXMgdG9vIG9sZC4gIE1ha2Ugc3VyZSBpdAoraXMgaW4geW91ciBQQVRIIG9yIHNl
dCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9ubWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAorcGF0aCB0
byBwa2ctY29uZmlnLgorCitBbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1l
bnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdTCithbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVk
IHRvIGNhbGwgcGtnLWNvbmZpZy4KK1NlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9y
ZSBkZXRhaWxzLgorCitUbyBnZXQgcGtnLWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5m
cmVlZGVza3RvcC5vcmcvPi4KK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIk
TElORU5PIiA1OyB9CitlbHNlCisJZ2xpYl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUworCWds
aWJfTElCUz0kcGtnX2N2X2dsaWJfTElCUworICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsg
fQorCitmaQorCisjIENoZWNrIGxpYnJhcnkgcGF0aAoraWYgdGVzdCAtZCAiJHByZWZpeC9saWI2
NCI7IHRoZW4gOgorCisgICAgTElCX1BBVEg9ImxpYjY0IgorCitlbHNlCisKKyAgICBMSUJfUEFU
SD0ibGliIgorCitmaQorCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFp
byIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8uLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfbGliX2Fpb19pb19zZXR1cCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9
JExJQlMKK0xJQlM9Ii1sYWlvICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
CisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBpb19zZXR1cCAo
KTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGlvX3NldHVwICgpOworICA7CisgIHJldHVybiAw
OworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFj
X2N2X2xpYl9haW9faW9fc2V0dXA9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9
bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAg
ICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGli
X3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xp
Yl9haW9faW9fc2V0dXAiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfYWlvX2lvX3NldHVw
IiA9IHh5ZXM7IHRoZW4gOgorICBzeXN0ZW1fYWlvPSJ5IgorZWxzZQorICBzeXN0ZW1fYWlvPSJu
IgorZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr
aW5nIGZvciBNRDUgaW4gLWxjcnlwdG8iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIE1E
NSBpbiAtbGNyeXB0by4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfY3J5cHRvX01ENSs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sY3J5cHRvICAkTElCUyIKK2NhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg
Ki8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g
ZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5
cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3
b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNl
bmRpZgorY2hhciBNRDUgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBNRDUgKCk7CisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9jcnlw
dG9fTUQ1PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No
ZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfY3J5cHRvX01E
NSIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBI
QVZFX0xJQkNSWVBUTyAxCitfQUNFT0YKKworICBMSUJTPSItbGNyeXB0byAkTElCUyIKKworZWxz
ZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAiJExJTkVOTyIg
NQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGli
X2V4dDJmc19leHQyZnNfb3BlbjIrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSIt
bGV4dDJmcyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf
ZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJu
YWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQg
bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVu
IGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9f
Y3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZXh0MmZzX29wZW4yICgpOworaW50
CittYWluICgpCit7CityZXR1cm4gZXh0MmZzX29wZW4yICgpOworICA7CisgIHJldHVybiAwOwor
fQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2
X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPXllcworZWxzZQorICBhY19jdl9saWJfZXh0MmZzX2V4
dDJmc19vcGVuMj1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY1Cisk
YXNfZWNobyAiJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA+JjY7IH0KK2lmIHRlc3Qg
IngkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID0geHllczsgdGhlbiA6CisgIGxpYmV4
dDJmcz0ieSIKK2Vsc2UKKyAgbGliZXh0MmZzPSJuIgorZmkKKworCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBnY3J5X21kX2hhc2hfYnVmZmVy
IGluIC1sZ2NyeXB0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBnY3J5X21kX2hhc2hf
YnVmZmVyIGluIC1sZ2NyeXB0Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9nY3J5cHRfZ2Ny
eV9tZF9oYXNoX2J1ZmZlcis6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQp
ICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sZ2Ny
eXB0ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBw
cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdo
dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz
IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1
c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBnY3J5X21kX2hhc2hfYnVmZmVyICgpOwor
aW50CittYWluICgpCit7CityZXR1cm4gZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9eWVzCitlbHNlCisgIGFj
X2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj1ubworZmkKK3JtIC1mIGNvcmUgY29u
ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj
b25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2Ny
eXB0X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0
X2djcnlfbWRfaGFzaF9idWZmZXIiID0geHllczsgdGhlbiA6CisgIGxpYmdjcnlwdD0ieSIKK2Vs
c2UKKyAgbGliZ2NyeXB0PSJuIgorZmkKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFkX2NyZWF0ZSBpbiAtbHB0aHJlYWQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB0aHJlYWRfY3JlYXRlIGluIC1scHRocmVhZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNr
X2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1scHRocmVhZCAgJExJQlMiCitjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy
cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl
IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291
bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k
aWYKK2NoYXIgcHRocmVhZF9jcmVhdGUgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBwdGhy
ZWFkX2NyZWF0ZSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfcHRocmVhZF9wdGhyZWFkX2Ny
ZWF0ZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGU9bm8KK2Zp
CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25m
dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVf
TElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0
OiAkYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9saWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xp
Yl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlIiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisgIGFzX2Zu
X2Vycm9yICQ/ICJDb3VsZCBub3QgZmluZCBsaWJwdGhyZWFkIiAiJExJTkVOTyIgNQorZmkKKwor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgY2xv
Y2tfZ2V0dGltZSBpbiAtbHJ0IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBjbG9ja19n
ZXR0aW1lIGluIC1scnQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRp
bWUrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQor
ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHJ0ICAkTElCUyIKK2NhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg
YW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu
IHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw
ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIK
KyNlbmRpZgorY2hhciBjbG9ja19nZXR0aW1lICgpOworaW50CittYWluICgpCit7CityZXR1cm4g
Y2xvY2tfZ2V0dGltZSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGlt
ZT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRpbWU9bm8KK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX3J0X2Nsb2NrX2dldHRpbWUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfcnRfY2xvY2tf
Z2V0dGltZSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA9
IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
TElCUlQgMQorX0FDRU9GCisKKyAgTElCUz0iLWxydCAkTElCUyIKKworZmkKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdXVpZF9jbGVhciBp
biAtbHV1aWQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIgaW4gLWx1
dWlkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19s
aWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHV1aWQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisv
KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K
KyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh
IEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0
aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitj
aGFyIHV1aWRfY2xlYXIgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiB1dWlkX2NsZWFyICgp
OworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXI9eWVzCitlbHNlCisgIGFj
X2N2X2xpYl91dWlkX3V1aWRfY2xlYXI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj
b25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj
X2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVh
ciIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNjsgfQoraWYg
dGVzdCAieCRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQg
Pj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCVVVJRCAxCitfQUNFT0YKKwor
ICBMSUJTPSItbHV1aWQgJExJQlMiCisKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5v
dCBmaW5kIGxpYnV1aWQiICIkTElORU5PIiA1CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB5YWpsX2FsbG9jIGluIC1seWFqbCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYys6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9
JExJQlMKK0xJQlM9Ii1seWFqbCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFu
eSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIg
YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWls
dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq
LworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgeWFqbF9hbGxv
YyAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIHlhamxfYWxsb2MgKCk7CisgIDsKKyAgcmV0
dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYz15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3lhamxf
eWFqbF9hbGxvYz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRh
Y19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjUKKyRhc19l
Y2hvICIkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2
X2xpYl95YWpsX3lhamxfYWxsb2MiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJZQUpMIDEKK19BQ0VPRgorCisgIExJQlM9Ii1seWFq
bCAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgeWFqbCIg
IiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1seiIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl96
X2RlZmxhdGVDb3B5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+
JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx6ICAkTElC
UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg
dG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0
aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50
IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4
dGVybiAiQyIKKyNlbmRpZgorY2hhciBkZWZsYXRlQ29weSAoKTsKK2ludAorbWFpbiAoKQorewor
cmV0dXJuIGRlZmxhdGVDb3B5ICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl96X2RlZmxhdGVD
b3B5PXllcworZWxzZQorICBhY19jdl9saWJfel9kZWZsYXRlQ29weT1ubworZmkKK3JtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9s
aWJfel9kZWZsYXRlQ29weSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5
IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID0geHllczsgdGhl
biA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9MSUJaIDEKK19B
Q0VPRgorCisgIExJQlM9Ii1seiAkTElCUyIKKworZWxzZQorICBhc19mbl9lcnJvciAkPyAiQ291
bGQgbm90IGZpbmQgemxpYiIgIiRMSU5FTk8iIDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29u
diIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgbGliaWNvbnZfb3BlbiBpbiAtbGljb252
Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxpY29udiAgJExJQlMiCitjYXQgY29uZmRlZnMu
aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisK
Ky8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9y
LgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m
IGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQg
c3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYK
K2NoYXIgbGliaWNvbnZfb3BlbiAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGxpYmljb252
X29wZW4gKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xp
bmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49eWVz
CitlbHNlCisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPW5vCitmaQorcm0gLWYgY29y
ZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhl
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xp
Yl9pY29udl9saWJpY29udl9vcGVuIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2ljb252X2xp
Ymljb252X29wZW4iID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZf
b3BlbiIgPSB4eWVzOyB0aGVuIDoKKyAgbGliaWNvbnY9InkiCitlbHNlCisgIGxpYmljb252PSJu
IgorZmkKKworCisKKyMgQXV0b3NjYW4gc3R1ZmYgKGV4Y2VwdCBmb3IgeWFqbC95YWpsX3ZlcnNp
b24uaCBjaGVjaykKKyMgQ2hlY2tzIGZvciBoZWFkZXIgZmlsZXMuCithY19mbl9jX2NoZWNrX3R5
cGUgIiRMSU5FTk8iICJzaXplX3QiICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19k
ZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3NpemVfdCIgPSB4eWVzOyB0aGVuIDoKKwor
ZWxzZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHNpemVfdCB1bnNpZ25l
ZCBpbnQKK19BQ0VPRgorCitmaQorCisjIFRoZSBVbHRyaXggNC4yIG1pcHMgYnVpbHRpbiBhbGxv
Y2EgZGVjbGFyZWQgYnkgYWxsb2NhLmggb25seSB3b3JrcworIyBmb3IgY29uc3RhbnQgYXJndW1l
bnRzLiAgVXNlbGVzcyEKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIHdvcmtpbmcgYWxsb2NhLmgiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHdvcmtpbmcgYWxsb2NhLmguLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zfd29ya2luZ19hbGxv
Y2FfaCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxhbGxvY2EuaD4KK2ludAorbWFpbiAoKQoreworY2hh
ciAqcCA9IChjaGFyICopIGFsbG9jYSAoMiAqIHNpemVvZiAoaW50KSk7CisJCQkgIGlmIChwKSBy
ZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGlu
ayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl93b3JraW5nX2FsbG9jYV9oPXllcworZWxzZQor
ICBhY19jdl93b3JraW5nX2FsbG9jYV9oPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X3dvcmtpbmdfYWxsb2NhX2giID4mNQorJGFzX2VjaG8gIiRhY19jdl93b3JraW5n
X2FsbG9jYV9oIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X3dvcmtpbmdfYWxsb2NhX2ggPSB5ZXM7
IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9BTExPQ0FfSCAxIiA+PmNvbmZkZWZzLmgK
KworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgYWxsb2NhIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBhbGxvY2EuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19H
TlVDX18KKyMgZGVmaW5lIGFsbG9jYSBfX2J1aWx0aW5fYWxsb2NhCisjZWxzZQorIyBpZmRlZiBf
TVNDX1ZFUgorIyAgaW5jbHVkZSA8bWFsbG9jLmg+CisjICBkZWZpbmUgYWxsb2NhIF9hbGxvY2EK
KyMgZWxzZQorIyAgaWZkZWYgSEFWRV9BTExPQ0FfSAorIyAgIGluY2x1ZGUgPGFsbG9jYS5oPgor
IyAgZWxzZQorIyAgIGlmZGVmIF9BSVgKKyAjcHJhZ21hIGFsbG9jYQorIyAgIGVsc2UKKyMgICAg
aWZuZGVmIGFsbG9jYSAvKiBwcmVkZWZpbmVkIGJ5IEhQIGNjICtPbGliY2FsbHMgKi8KK3ZvaWQg
KmFsbG9jYSAoc2l6ZV90KTsKKyMgICAgZW5kaWYKKyMgICBlbmRpZgorIyAgZW5kaWYKKyMgZW5k
aWYKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK2NoYXIgKnAgPSAoY2hhciAqKSBhbGxvY2Eg
KDEpOworCQkJCSAgICBpZiAocCkgcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19h
bGxvY2Ffd29ya3M9eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPW5vCitmaQor
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjUK
KyRhc19lY2hvICIkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MiID4mNjsgfQorCitpZiB0ZXN0ICRh
Y19jdl9mdW5jX2FsbG9jYV93b3JrcyA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBI
QVZFX0FMTE9DQSAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQorICAjIFRoZSBTVlIzIGxpYlBXIGFu
ZCBTVlI0IGxpYnVjYiBib3RoIGNvbnRhaW4gaW5jb21wYXRpYmxlIGZ1bmN0aW9ucworIyB0aGF0
IGNhdXNlIHRyb3VibGUuICBTb21lIHZlcnNpb25zIGRvIG5vdCBldmVuIGNvbnRhaW4gYWxsb2Nh
IG9yCisjIGNvbnRhaW4gYSBidWdneSB2ZXJzaW9uLiAgSWYgeW91IHN0aWxsIHdhbnQgdG8gdXNl
IHRoZWlyIGFsbG9jYSwKKyMgdXNlIGFyIHRvIGV4dHJhY3QgYWxsb2NhLm8gZnJvbSB0aGVtIGlu
c3RlYWQgb2YgY29tcGlsaW5nIGFsbG9jYS5jLgorCitBTExPQ0E9XCR7TElCT0JKRElSfWFsbG9j
YS4kYWNfb2JqZXh0CisKKyRhc19lY2hvICIjZGVmaW5lIENfQUxMT0NBIDEiID4+Y29uZmRlZnMu
aAorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
d2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcy4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9vc19jcmF5Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmIGRlZmluZWQgQ1JBWSAmJiAhIGRlZmlu
ZWQgQ1JBWTIKK3dlYmVjcmF5CisjZWxzZQord2Vub3RiZWNyYXkKKyNlbmRpZgorCitfQUNFT0YK
K2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVHUkVQICJ3
ZWJlY3JheSIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgYWNfY3Zfb3NfY3JheT15ZXMKK2Vs
c2UKKyAgYWNfY3Zfb3NfY3JheT1ubworZmkKK3JtIC1mIGNvbmZ0ZXN0KgorCitmaQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9vc19jcmF5
IiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfb3NfY3JheSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9v
c19jcmF5ID0geWVzOyB0aGVuCisgIGZvciBhY19mdW5jIGluIF9nZXRiNjcgR0VUQjY3IGdldGI2
NzsgZG8KKyAgICBhc19hY192YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRh
c190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2Fj
X3ZhciIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoK
KworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBDUkFZX1NUQUNLU0VHX0VORCAk
YWNfZnVuYworX0FDRU9GCisKKyAgICBicmVhaworZmkKKworICBkb25lCitmaQorCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHN0YWNrIGRpcmVjdGlv
biBmb3IgQyBhbGxvY2EiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9u
IGZvciBDIGFsbG9jYS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX3N0YWNrX2RpcmVjdGlvbis6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlm
IHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfY19zdGFja19k
aXJlY3Rpb249MAorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50
CitmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKQoreworICBzdGF0aWMgY2hhciAqYWRkciA9IDA7Cisg
IGF1dG8gY2hhciBkdW1teTsKKyAgaWYgKGFkZHIgPT0gMCkKKyAgICB7CisgICAgICBhZGRyID0g
JmR1bW15OworICAgICAgcmV0dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpOworICAgIH0KKyAg
ZWxzZQorICAgIHJldHVybiAoJmR1bW15ID4gYWRkcikgPyAxIDogLTE7Cit9CisKK2ludAorbWFp
biAoKQoreworICByZXR1cm4gZmluZF9zdGFja19kaXJlY3Rpb24gKCkgPCAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19zdGFja19k
aXJlY3Rpb249MQorZWxzZQorICBhY19jdl9jX3N0YWNrX2RpcmVjdGlvbj0tMQorZmkKK3JtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
Y19zdGFja19kaXJlY3Rpb24iID4mNjsgfQorY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2Rl
ZmluZSBTVEFDS19ESVJFQ1RJT04gJGFjX2N2X2Nfc3RhY2tfZGlyZWN0aW9uCitfQUNFT0YKKwor
CitmaQorCitmb3IgYWNfaGVhZGVyIGluICBcCisgICAgICAgICAgICAgICAgYXJwYS9pbmV0Lmgg
ZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCisgICAgICAg
ICAgICAgICAgbmV0ZGIuaCBuZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50Lmggc3RkbGliLmgg
c3RyaW5nLmggXAorICAgICAgICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0
bC5oIHN5cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKKyAgICAgICAgICAgICAgICBzeXMvc29ja2V0
Lmggc3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCisgICAgICAg
ICAgICAgICAgdW5pc3RkLmggeWFqbC95YWpsX3ZlcnNpb24uaCBcCisKK2RvIDoKKyAgYXNfYWNf
SGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAor
YWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNf
YWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFz
X2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNF
T0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQor
X0FDRU9GCisKK2ZpCisKK2RvbmUKKworCisjIENoZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVy
ZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0
byBDOTkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZv
cm1zIHRvIEM5OS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9oZWFkZXJfc3RkYm9vbF9oKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCisjaW5jbHVkZSA8c3RkYm9vbC5oPgorI2lmbmRlZiBib29sCisgImVycm9yOiBib29s
IGlzIG5vdCBkZWZpbmVkIgorI2VuZGlmCisjaWZuZGVmIGZhbHNlCisgImVycm9yOiBmYWxzZSBp
cyBub3QgZGVmaW5lZCIKKyNlbmRpZgorI2lmIGZhbHNlCisgImVycm9yOiBmYWxzZSBpcyBub3Qg
MCIKKyNlbmRpZgorI2lmbmRlZiB0cnVlCisgImVycm9yOiB0cnVlIGlzIG5vdCBkZWZpbmVkIgor
I2VuZGlmCisjaWYgdHJ1ZSAhPSAxCisgImVycm9yOiB0cnVlIGlzIG5vdCAxIgorI2VuZGlmCisj
aWZuZGVmIF9fYm9vbF90cnVlX2ZhbHNlX2FyZV9kZWZpbmVkCisgImVycm9yOiBfX2Jvb2xfdHJ1
ZV9mYWxzZV9hcmVfZGVmaW5lZCBpcyBub3QgZGVmaW5lZCIKKyNlbmRpZgorCisJc3RydWN0IHMg
eyBfQm9vbCBzOiAxOyBfQm9vbCB0OyB9IHM7CisKKwljaGFyIGFbdHJ1ZSA9PSAxID8gMSA6IC0x
XTsKKwljaGFyIGJbZmFsc2UgPT0gMCA/IDEgOiAtMV07CisJY2hhciBjW19fYm9vbF90cnVlX2Zh
bHNlX2FyZV9kZWZpbmVkID09IDEgPyAxIDogLTFdOworCWNoYXIgZFsoYm9vbCkgMC41ID09IHRy
dWUgPyAxIDogLTFdOworCS8qIFNlZSBib2R5IG9mIG1haW4gcHJvZ3JhbSBmb3IgJ2UnLiAgKi8K
KwljaGFyIGZbKF9Cb29sKSAwLjAgPT0gZmFsc2UgPyAxIDogLTFdOworCWNoYXIgZ1t0cnVlXTsK
KwljaGFyIGhbc2l6ZW9mIChfQm9vbCldOworCWNoYXIgaVtzaXplb2Ygcy50XTsKKwllbnVtIHsg
aiA9IGZhbHNlLCBrID0gdHJ1ZSwgbCA9IGZhbHNlICogdHJ1ZSwgbSA9IHRydWUgKiAyNTYgfTsK
KwkvKiBUaGUgZm9sbG93aW5nIGZhaWxzIGZvcgorCSAgIEhQIGFDKysvQU5TSSBDIEIzOTEwQiBB
LjA1LjU1IFtEZWMgMDQgMjAwM10uICovCisJX0Jvb2wgblttXTsKKwljaGFyIG9bc2l6ZW9mIG4g
PT0gbSAqIHNpemVvZiBuWzBdID8gMSA6IC0xXTsKKwljaGFyIHBbLTEgLSAoX0Jvb2wpIDAgPCAw
ICYmIC0xIC0gKGJvb2wpIDAgPCAwID8gMSA6IC0xXTsKKwkvKiBDYXRjaCBhIGJ1ZyBpbiBhbiBI
UC1VWCBDIGNvbXBpbGVyLiAgU2VlCisJICAgaHR0cDovL2djYy5nbnUub3JnL21sL2djYy1wYXRj
aGVzLzIwMDMtMTIvbXNnMDIzMDMuaHRtbAorCSAgIGh0dHA6Ly9saXN0cy5nbnUub3JnL2FyY2hp
dmUvaHRtbC9idWctY29yZXV0aWxzLzIwMDUtMTEvbXNnMDAxNjEuaHRtbAorCSAqLworCV9Cb29s
IHEgPSB0cnVlOworCV9Cb29sICpwcSA9ICZxOworCitpbnQKK21haW4gKCkKK3sKKworCWJvb2wg
ZSA9ICZzOworCSpwcSB8PSBxOworCSpwcSB8PSAhIHE7CisJLyogUmVmZXIgdG8gZXZlcnkgZGVj
bGFyZWQgdmFsdWUsIHRvIGF2b2lkIGNvbXBpbGVyIG9wdGltaXphdGlvbnMuICAqLworCXJldHVy
biAoIWEgKyAhYiArICFjICsgIWQgKyAhZSArICFmICsgIWcgKyAhaCArICFpICsgISFqICsgIWsg
KyAhIWwKKwkJKyAhbSArICFuICsgIW8gKyAhcCArICFxICsgIXBxKTsKKworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2hlYWRlcl9zdGRib29sX2g9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zdGRi
b29sX2g9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zdGRib29sX2giID4mNQorJGFzX2VjaG8gIiRh
Y19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjY7IH0KK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVO
TyIgIl9Cb29sIiAiYWNfY3ZfdHlwZV9fQm9vbCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYg
dGVzdCAieCRhY19jdl90eXBlX19Cb29sIiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfX0JPT0wgMQorX0FDRU9GCisKKworZmkKKworaWYg
dGVzdCAkYWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2Rl
ZmluZSBIQVZFX1NUREJPT0xfSCAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5
cGVzLmgiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5o
Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X3R5cGVfdWlkX3QrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8
c3lzL3R5cGVzLmg+CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4
dCIpIDI+JjUgfAorICAkRUdSRVAgInVpZF90IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgorICBh
Y19jdl90eXBlX3VpZF90PXllcworZWxzZQorICBhY19jdl90eXBlX3VpZF90PW5vCitmaQorcm0g
LWYgY29uZnRlc3QqCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJGFjX2N2X3R5cGVfdWlkX3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl90eXBl
X3VpZF90IiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgorCisk
YXNfZWNobyAiI2RlZmluZSB1aWRfdCBpbnQiID4+Y29uZmRlZnMuaAorCisKKyRhc19lY2hvICIj
ZGVmaW5lIGdpZF90IGludCIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgaW5saW5lLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2NfaW5saW5l
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
YWNfY3ZfY19pbmxpbmU9bm8KK2ZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxpbmVfXyBfX2lubGlu
ZTsgZG8KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog
ZW5kIGNvbmZkZWZzLmguICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cwordHlwZWRlZiBpbnQgZm9v
X3Q7CitzdGF0aWMgJGFjX2t3IGZvb190IHN0YXRpY19mb28gKCkge3JldHVybiAwOyB9CiskYWNf
a3cgZm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQorI2VuZGlmCisKK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9jX2lubGluZT0kYWNfa3cK
K2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0
LiRhY19leHQKKyAgdGVzdCAiJGFjX2N2X2NfaW5saW5lIiAhPSBubyAmJiBicmVhaworZG9uZQor
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdl9jX2lubGluZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2NfaW5saW5lIiA+JjY7IH0KKwor
Y2FzZSAkYWNfY3ZfY19pbmxpbmUgaW4KKyAgaW5saW5lIHwgeWVzKSA7OworICAqKQorICAgIGNh
c2UgJGFjX2N2X2NfaW5saW5lIGluCisgICAgICBubykgYWNfdmFsPTs7CisgICAgICAqKSBhY192
YWw9JGFjX2N2X2NfaW5saW5lOzsKKyAgICBlc2FjCisgICAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B
Q0VPRgorI2lmbmRlZiBfX2NwbHVzcGx1cworI2RlZmluZSBpbmxpbmUgJGFjX3ZhbAorI2VuZGlm
CitfQUNFT0YKKyAgICA7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAi
MTYiICJhY19jdl9jX2ludDE2X3QiCitjYXNlICRhY19jdl9jX2ludDE2X3QgaW4gIygKKyAgbm98
eWVzKSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGlu
dDE2X3QgJGFjX2N2X2NfaW50MTZfdAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRf
aW50WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX2ludDMyX3QiCitjYXNlICRhY19jdl9jX2lu
dDMyX3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8
X0FDRU9GCisjZGVmaW5lIGludDMyX3QgJGFjX2N2X2NfaW50MzJfdAorX0FDRU9GCis7OworZXNh
YworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiNjQiICJhY19jdl9jX2ludDY0X3Qi
CitjYXNlICRhY19jdl9jX2ludDY0X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDY0X3QgJGFjX2N2X2NfaW50NjRf
dAorX0FDRU9GCis7OworZXNhYworCithY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAiOCIg
ImFjX2N2X2NfaW50OF90IgorY2FzZSAkYWNfY3ZfY19pbnQ4X3QgaW4gIygKKyAgbm98eWVzKSA7
OyAjKAorICAqKQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGludDhfdCAk
YWNfY3ZfY19pbnQ4X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19jaGVja190eXBlICIk
TElORU5PIiAibW9kZV90IiAiYWNfY3ZfdHlwZV9tb2RlX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9tb2RlX3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UK
KworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBtb2RlX3QgaW50CitfQUNFT0YK
KworZmkKKworYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAib2ZmX3QiICJhY19jdl90eXBl
X29mZl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfb2Zm
X3QiID0geHllczsgdGhlbiA6CisKK2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBvZmZfdCBsb25nIGludAorX0FDRU9GCisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfdHlw
ZSAiJExJTkVOTyIgInBpZF90IiAiYWNfY3ZfdHlwZV9waWRfdCIgIiRhY19pbmNsdWRlc19kZWZh
dWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3BpZF90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNl
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgcGlkX3QgaW50CitfQUNFT0YK
KworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm
b3IgQy9DKysgcmVzdHJpY3Qga2V5d29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX3Jlc3Ry
aWN0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgYWNfY3ZfY19yZXN0cmljdD1ubworICAgIyBUaGUgb3JkZXIgaGVyZSBjYXRlcnMgdG8gdGhl
IGZhY3QgdGhhdCBDKysgZG9lcyBub3QgcmVxdWlyZSByZXN0cmljdC4KKyAgIGZvciBhY19rdyBp
biBfX3Jlc3RyaWN0IF9fcmVzdHJpY3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7IGRvCisgICAgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KK3R5cGVkZWYgaW50ICogaW50X3B0cjsKKwlpbnQgZm9vIChpbnRfcHRyICRhY19r
dyBpcCkgeworCXJldHVybiBpcFswXTsKKyAgICAgICB9CitpbnQKK21haW4gKCkKK3sKK2ludCBz
WzFdOworCWludCAqICRhY19rdyB0ID0gczsKKwl0WzBdID0gMDsKKwlyZXR1cm4gZm9vKHQpCisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19yZXN0cmljdD0kYWNfa3cKK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgICAgdGVz
dCAiJGFjX2N2X2NfcmVzdHJpY3QiICE9IG5vICYmIGJyZWFrCisgICBkb25lCisKK2ZpCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfcmVz
dHJpY3QiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX3Jlc3RyaWN0IiA+JjY7IH0KKworIGNhc2Ug
JGFjX2N2X2NfcmVzdHJpY3QgaW4KKyAgIHJlc3RyaWN0KSA7OworICAgbm8pICRhc19lY2hvICIj
ZGVmaW5lIHJlc3RyaWN0IC8qKi8iID4+Y29uZmRlZnMuaAorIDs7CisgICAqKSAgY2F0ID4+Y29u
ZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSByZXN0cmljdCAkYWNfY3ZfY19yZXN0cmljdAorX0FD
RU9GCisgOzsKKyBlc2FjCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInNpemVfdCIg
ImFjX2N2X3R5cGVfc2l6ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFj
X2N2X3R5cGVfc2l6ZV90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKKyNkZWZpbmUgc2l6ZV90IHVuc2lnbmVkIGludAorX0FDRU9GCisKK2ZpCisK
K2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInNzaXplX3QiICJhY19jdl90eXBlX3NzaXpl
X3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9zc2l6ZV90
IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgc3NpemVfdCBpbnQKK19BQ0VPRgorCitmaQorCithY19mbl9jX2NoZWNrX21lbWJlciAi
JExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfYmxrc2l6ZSIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rf
c3RhdF9zdF9ibGtzaXplIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2
X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplIiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxLU0laRSAx
CitfQUNFT0YKKworCitmaQorCithY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVj
dCBzdGF0IiAic3RfYmxvY2tzIiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsb2NrcyIg
IiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9tZW1iZXJfc3RydWN0X3N0
YXRfc3RfYmxvY2tzIiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9G
CisjZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTIDEKK19BQ0VPRgorCisKKyRhc19l
Y2hvICIjZGVmaW5lIEhBVkVfU1RfQkxPQ0tTIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgIGNh
c2UgIiAkTElCT0JKUyAiIGluCisgICoiIGZpbGVibG9ja3MuJGFjX29iamV4dCAiKiApIDs7Cisg
ICopIExJQk9CSlM9IiRMSUJPQkpTIGZpbGVibG9ja3MuJGFjX29iamV4dCIKKyA7OworZXNhYwor
CitmaQorCisKK2FjX2ZuX2NfY2hlY2tfbWVtYmVyICIkTElORU5PIiAic3RydWN0IHN0YXQiICJz
dF9yZGV2IiAiYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiICIkYWNfaW5jbHVkZXNf
ZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X3JkZXYiID0g
eHllczsgdGhlbiA6CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9T
VFJVQ1RfU1RBVF9TVF9SREVWIDEKK19BQ0VPRgorCisKK2ZpCisKK2FjX2ZuX2NfZmluZF91aW50
WF90ICIkTElORU5PIiAiMTYiICJhY19jdl9jX3VpbnQxNl90IgorY2FzZSAkYWNfY3ZfY191aW50
MTZfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisgICopCisKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSB1aW50MTZfdCAkYWNfY3ZfY191aW50MTZfdAorX0FDRU9GCis7Owor
ICBlc2FjCisKK2FjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5PIiAiMzIiICJhY19jdl9jX3Vp
bnQzMl90IgorY2FzZSAkYWNfY3ZfY191aW50MzJfdCBpbiAjKAorICBub3x5ZXMpIDs7ICMoCisg
ICopCisKKyRhc19lY2hvICIjZGVmaW5lIF9VSU5UMzJfVCAxIiA+PmNvbmZkZWZzLmgKKworCitj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHVpbnQzMl90ICRhY19jdl9jX3VpbnQz
Ml90CitfQUNFT0YKKzs7CisgIGVzYWMKKworYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8i
ICI2NCIgImFjX2N2X2NfdWludDY0X3QiCitjYXNlICRhY19jdl9jX3VpbnQ2NF90IGluICMoCisg
IG5vfHllcykgOzsgIygKKyAgKikKKworJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ2NF9UIDEiID4+
Y29uZmRlZnMuaAorCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgdWludDY0
X3QgJGFjX2N2X2NfdWludDY0X3QKK19BQ0VPRgorOzsKKyAgZXNhYworCithY19mbl9jX2ZpbmRf
dWludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX3VpbnQ4X3QiCitjYXNlICRhY19jdl9jX3Vp
bnQ4X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBf
VUlOVDhfVCAxIiA+PmNvbmZkZWZzLmgKKworCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIHVpbnQ4X3QgJGFjX2N2X2NfdWludDhfdAorX0FDRU9GCis7OworICBlc2FjCisKK2Fj
X2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgInB0cmRpZmZfdCIgImFjX2N2X3R5cGVfcHRyZGlm
Zl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfcHRyZGlm
Zl90IiA9IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5l
IEhBVkVfUFRSRElGRl9UIDEKK19BQ0VPRgorCisKK2ZpCisKKworIyBDaGVja3MgZm9yIGxpYnJh
cnkgZnVuY3Rpb25zLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgZXJyb3JfYXRfbGluZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
ZXJyb3JfYXRfbGluZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfZXJyb3JfYXRfbGluZSs6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KKyNpbmNsdWRlIDxlcnJvci5oPgoraW50CittYWluICgpCit7CitlcnJvcl9hdF9s
aW5lICgwLCAwLCAiIiwgMCwgImFuIGVycm9yIG9jY3VycmVkIik7CisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNf
Y3ZfbGliX2Vycm9yX2F0X2xpbmU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5l
PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9lcnJvcl9hdF9s
aW5lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUiID4mNjsgfQoraWYg
dGVzdCAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUgPSBubzsgdGhlbgorICBjYXNlICIgJExJQk9C
SlMgIiBpbgorICAqIiBlcnJvci4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJ
Qk9CSlMgZXJyb3IuJGFjX29iamV4dCIKKyA7OworZXNhYworCitmaQorCitmb3IgYWNfaGVhZGVy
IGluIHZmb3JrLmgKK2RvIDoKKyAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVO
TyIgInZmb3JrLmgiICJhY19jdl9oZWFkZXJfdmZvcmtfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0
IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdmZvcmtfaCIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1ZGT1JLX0ggMQorX0FDRU9GCisK
K2ZpCisKK2RvbmUKKworZm9yIGFjX2Z1bmMgaW4gZm9yayB2Zm9yaworZG8gOgorICBhc19hY192
YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKK2FjX2ZuX2Nf
Y2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKK2lmIGV2YWwgdGVz
dCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1bmMiIHwgJGFzX3RyX2Nw
cGAgMQorX0FDRU9GCisKK2ZpCitkb25lCisKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrIiA9
IHh5ZXM7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3Igd29ya2luZyBmb3JrIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3
b3JraW5nIGZvcmsuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19mb3JrX3dvcmtzKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX2Zvcmtfd29y
a3M9Y3Jvc3MKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2ludAor
bWFpbiAoKQoreworCisJICAvKiBCeSBSdWVkaWdlciBLdWhsbWFubi4gKi8KKwkgIHJldHVybiBm
b3JrICgpIDwgMDsKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPXllcworZWxz
ZQorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBjb3Jl
LmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNvbmZ0
ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9m
dW5jX2Zvcmtfd29ya3MiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID4m
NjsgfQorCitlbHNlCisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz0kYWNfY3ZfZnVuY19mb3JrCitm
aQoraWYgdGVzdCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geGNyb3NzOyB0aGVuCisgIGNh
c2UgJGhvc3QgaW4KKyAgICAqLSotYW1pZ2FvcyogfCAqLSotbXNkb3NkamdwcCopCisgICAgICAj
IE92ZXJyaWRlLCBhcyB0aGVzZSBzeXN0ZW1zIGhhdmUgb25seSBhIGR1bW15IGZvcmsoKSBzdHVi
CisgICAgICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9bm8KKyAgICAgIDs7CisgICAgKikKKyAgICAg
IGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKKyAgICAgIDs7CisgIGVzYWMKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1
bmNfZm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX2Zvcmtfd29ya3Mg
Z3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7fQorZmkKK2FjX2N2X2Z1
bmNfdmZvcmtfd29ya3M9JGFjX2N2X2Z1bmNfdmZvcmsKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY192
Zm9yayIgPSB4eWVzOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgdmZvcmsiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yIHdvcmtpbmcgdmZvcmsuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY192Zm9ya193
b3Jrcys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y192Zm9ya193b3Jrcz1jcm9zcworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisvKiBUaGFua3MgdG8gUGF1
bCBFZ2dlcnQgZm9yIHRoaXMgdGVzdC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAorI2luY2x1
ZGUgPHN5cy93YWl0Lmg+CisjaWZkZWYgSEFWRV9WRk9SS19ICisjIGluY2x1ZGUgPHZmb3JrLmg+
CisjZW5kaWYKKy8qIE9uIHNvbWUgc3BhcmMgc3lzdGVtcywgY2hhbmdlcyBieSB0aGUgY2hpbGQg
dG8gbG9jYWwgYW5kIGluY29taW5nCisgICBhcmd1bWVudCByZWdpc3RlcnMgYXJlIHByb3BhZ2F0
ZWQgYmFjayB0byB0aGUgcGFyZW50LiAgVGhlIGNvbXBpbGVyCisgICBpcyB0b2xkIGFib3V0IHRo
aXMgd2l0aCAjaW5jbHVkZSA8dmZvcmsuaD4sIGJ1dCBzb21lIGNvbXBpbGVycworICAgKGUuZy4g
Z2NjIC1PKSBkb24ndCBncm9rIDx2Zm9yay5oPi4gIFRlc3QgZm9yIHRoaXMgYnkgdXNpbmcgYQor
ICAgc3RhdGljIHZhcmlhYmxlIHdob3NlIGFkZHJlc3MgaXMgcHV0IGludG8gYSByZWdpc3RlciB0
aGF0IGlzCisgICBjbG9iYmVyZWQgYnkgdGhlIHZmb3JrLiAgKi8KK3N0YXRpYyB2b2lkCisjaWZk
ZWYgX19jcGx1c3BsdXMKK3NwYXJjX2FkZHJlc3NfdGVzdCAoaW50IGFyZykKKyMgZWxzZQorc3Bh
cmNfYWRkcmVzc190ZXN0IChhcmcpIGludCBhcmc7CisjZW5kaWYKK3sKKyAgc3RhdGljIHBpZF90
IGNoaWxkOworICBpZiAoIWNoaWxkKSB7CisgICAgY2hpbGQgPSB2Zm9yayAoKTsKKyAgICBpZiAo
Y2hpbGQgPCAwKSB7CisgICAgICBwZXJyb3IgKCJ2Zm9yayIpOworICAgICAgX2V4aXQoMik7Cisg
ICAgfQorICAgIGlmICghY2hpbGQpIHsKKyAgICAgIGFyZyA9IGdldHBpZCgpOworICAgICAgd3Jp
dGUoLTEsICIiLCAwKTsKKyAgICAgIF9leGl0IChhcmcpOworICAgIH0KKyAgfQorfQorCitpbnQK
K21haW4gKCkKK3sKKyAgcGlkX3QgcGFyZW50ID0gZ2V0cGlkICgpOworICBwaWRfdCBjaGlsZDsK
KworICBzcGFyY19hZGRyZXNzX3Rlc3QgKDApOworCisgIGNoaWxkID0gdmZvcmsgKCk7CisKKyAg
aWYgKGNoaWxkID09IDApIHsKKyAgICAvKiBIZXJlIGlzIGFub3RoZXIgdGVzdCBmb3Igc3BhcmMg
dmZvcmsgcmVnaXN0ZXIgcHJvYmxlbXMuICBUaGlzCisgICAgICAgdGVzdCB1c2VzIGxvdHMgb2Yg
bG9jYWwgdmFyaWFibGVzLCBhdCBsZWFzdCBhcyBtYW55IGxvY2FsCisgICAgICAgdmFyaWFibGVz
IGFzIG1haW4gaGFzIGFsbG9jYXRlZCBzbyBmYXIgaW5jbHVkaW5nIGNvbXBpbGVyCisgICAgICAg
dGVtcG9yYXJpZXMuICA0IGxvY2FscyBhcmUgZW5vdWdoIGZvciBnY2MgMS40MC4zIG9uIGEgU29s
YXJpcworICAgICAgIDQuMS4zIHNwYXJjLCBidXQgd2UgdXNlIDggdG8gYmUgc2FmZS4gIEEgYnVn
Z3kgY29tcGlsZXIgc2hvdWxkCisgICAgICAgcmV1c2UgdGhlIHJlZ2lzdGVyIG9mIHBhcmVudCBm
b3Igb25lIG9mIHRoZSBsb2NhbCB2YXJpYWJsZXMsCisgICAgICAgc2luY2UgaXQgd2lsbCB0aGlu
ayB0aGF0IHBhcmVudCBjYW4ndCBwb3NzaWJseSBiZSB1c2VkIGFueSBtb3JlCisgICAgICAgaW4g
dGhpcyByb3V0aW5lLiAgQXNzaWduaW5nIHRvIHRoZSBsb2NhbCB2YXJpYWJsZSB3aWxsIHRodXMK
KyAgICAgICBtdW5nZSBwYXJlbnQgaW4gdGhlIHBhcmVudCBwcm9jZXNzLiAgKi8KKyAgICBwaWRf
dAorICAgICAgcCA9IGdldHBpZCgpLCBwMSA9IGdldHBpZCgpLCBwMiA9IGdldHBpZCgpLCBwMyA9
IGdldHBpZCgpLAorICAgICAgcDQgPSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwgcDYgPSBnZXRw
aWQoKSwgcDcgPSBnZXRwaWQoKTsKKyAgICAvKiBDb252aW5jZSB0aGUgY29tcGlsZXIgdGhhdCBw
Li5wNyBhcmUgbGl2ZTsgb3RoZXJ3aXNlLCBpdCBtaWdodAorICAgICAgIHVzZSB0aGUgc2FtZSBo
YXJkd2FyZSByZWdpc3RlciBmb3IgYWxsIDggbG9jYWwgdmFyaWFibGVzLiAgKi8KKyAgICBpZiAo
cCAhPSBwMSB8fCBwICE9IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNAorCXx8IHAgIT0gcDUgfHwg
cCAhPSBwNiB8fCBwICE9IHA3KQorICAgICAgX2V4aXQoMSk7CisKKyAgICAvKiBPbiBzb21lIHN5
c3RlbXMgKGUuZy4gSVJJWCAzLjMpLCB2Zm9yayBkb2Vzbid0IHNlcGFyYXRlIHBhcmVudAorICAg
ICAgIGZyb20gY2hpbGQgZmlsZSBkZXNjcmlwdG9ycy4gIElmIHRoZSBjaGlsZCBjbG9zZXMgYSBk
ZXNjcmlwdG9yCisgICAgICAgYmVmb3JlIGl0IGV4ZWNzIG9yIGV4aXRzLCB0aGlzIG11bmdlcyB0
aGUgcGFyZW50J3MgZGVzY3JpcHRvcgorICAgICAgIGFzIHdlbGwuICBUZXN0IGZvciB0aGlzIGJ5
IGNsb3Npbmcgc3Rkb3V0IGluIHRoZSBjaGlsZC4gICovCisgICAgX2V4aXQoY2xvc2UoZmlsZW5v
KHN0ZG91dCkpICE9IDApOworICB9IGVsc2UgeworICAgIGludCBzdGF0dXM7CisgICAgc3RydWN0
IHN0YXQgc3Q7CisKKyAgICB3aGlsZSAod2FpdCgmc3RhdHVzKSAhPSBjaGlsZCkKKyAgICAgIDsK
KyAgICByZXR1cm4gKAorCSAvKiBXYXMgdGhlcmUgc29tZSBwcm9ibGVtIHdpdGggdmZvcmtpbmc/
ICAqLworCSBjaGlsZCA8IDAKKworCSAvKiBEaWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91
bGRuJ3QgaGFwcGVuLikgICovCisJIHx8IHN0YXR1cworCisJIC8qIERpZCB0aGUgdmZvcmsvY29t
cGlsZXIgYnVnIG9jY3VyPyAgKi8KKwkgfHwgcGFyZW50ICE9IGdldHBpZCgpCisKKwkgLyogRGlk
IHRoZSBmaWxlIGRlc2NyaXB0b3IgYnVnIG9jY3VyPyAgKi8KKwkgfHwgZnN0YXQoZmlsZW5vKHN0
ZG91dCksICZzdCkgIT0gMAorCSApOworICB9Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1
biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPXllcworZWxzZQor
ICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29yZS5j
b25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25mdGVz
dC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVu
Y192Zm9ya193b3JrcyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID4m
NjsgfQorCitmaTsKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsg
dGhlbgorICBhY19jdl9mdW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19j
dl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfdmZvcmtf
d29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjI7fQorZmkKKwor
aWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KKworJGFzX2Vj
aG8gIiNkZWZpbmUgSEFWRV9XT1JLSU5HX1ZGT1JLIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisK
KyRhc19lY2hvICIjZGVmaW5lIHZmb3JrIGZvcmsiID4+Y29uZmRlZnMuaAorCitmaQoraWYgdGVz
dCAieCRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID0geHllczsgdGhlbgorCiskYXNfZWNobyAiI2Rl
ZmluZSBIQVZFX1dPUktJTkdfRk9SSyAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgX0xBUkdFRklMRV9T
T1VSQ0UgdmFsdWUgbmVlZGVkIGZvciBsYXJnZSBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVj
a2luZyBmb3IgX0xBUkdFRklMRV9TT1VSQ0UgdmFsdWUgbmVlZGVkIGZvciBsYXJnZSBmaWxlcy4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIHdoaWxlIDo7IGRvCisg
IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m
ZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4gLyogZm9yIG9mZl90ICovCisgICAg
ICNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgpCit7CitpbnQgKCpmcCkgKEZJTEUgKiwg
b2ZmX3QsIGludCkgPSBmc2Vla287CisgICAgIHJldHVybiBmc2Vla28gKHN0ZGluLCAwLCAwKSAm
JiBmcCAoc3RkaW4sIDAsIDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3N5c19sYXJnZWZpbGVfc291
cmNlPW5vOyBicmVhaworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKyNkZWZpbmUgX0xBUkdFRklMRV9TT1VSQ0UgMQorI2luY2x1ZGUgPHN5cy90eXBlcy5o
PiAvKiBmb3Igb2ZmX3QgKi8KKyAgICAgI2luY2x1ZGUgPHN0ZGlvLmg+CitpbnQKK21haW4gKCkK
K3sKK2ludCAoKmZwKSAoRklMRSAqLCBvZmZfdCwgaW50KSA9IGZzZWVrbzsKKyAgICAgcmV0dXJu
IGZzZWVrbyAoc3RkaW4sIDAsIDApICYmIGZwIChzdGRpbiwgMCwgMCk7CisgIDsKKyAgcmV0dXJu
IDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9MTsgYnJlYWsKK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29u
ZnRlc3QuJGFjX2V4dAorICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT11bmtub3duCisgIGJy
ZWFrCitkb25lCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjY7IH0KK2Nhc2UgJGFjX2N2X3N5c19sYXJnZWZpbGVf
c291cmNlIGluICMoCisgIG5vIHwgdW5rbm93bikgOzsKKyAgKikKK2NhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgX0xBUkdFRklMRV9TT1VSQ0UgJGFjX2N2X3N5c19sYXJnZWZpbGVf
c291cmNlCitfQUNFT0YKKzs7Citlc2FjCitybSAtcmYgY29uZnRlc3QqCisKKyMgV2UgdXNlZCB0
byB0cnkgZGVmaW5pbmcgX1hPUEVOX1NPVVJDRT01MDAgdG9vLCB0byB3b3JrIGFyb3VuZCBhIGJ1
ZworIyBpbiBnbGliYyAyLjEuMywgYnV0IHRoYXQgYnJlYWtzIHRvbyBtYW55IG90aGVyIHRoaW5n
cy4KKyMgSWYgeW91IHdhbnQgZnNlZWtvIGFuZCBmdGVsbG8gd2l0aCBnbGliYywgdXBncmFkZSB0
byBhIGZpeGVkIGdsaWJjLgoraWYgdGVzdCAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UgIT0g
dW5rbm93bjsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX0ZTRUVLTyAxIiA+PmNvbmZk
ZWZzLmgKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVzIHRyYWlsaW5nIHNsYXNoIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRsZXMg
dHJhaWxpbmcgc2xhc2guLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVy
ZW5jZXNfc2xhc2hlZF9zeW1saW5rKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgcm0gLWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0LmZpbGUKK2Vj
aG8gPmNvbmZ0ZXN0LmZpbGUKK2lmIHRlc3QgIiRhc19sbl9zIiA9ICJsbiAtcyIgJiYgbG4gLXMg
Y29uZnRlc3QuZmlsZSBjb25mdGVzdC5zeW07IHRoZW4KKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBp
bGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFz
aGVkX3N5bWxpbms9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl
c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQK
K2ludAorbWFpbiAoKQoreworc3RydWN0IHN0YXQgc2J1ZjsKKyAgICAgLyogTGludXggd2lsbCBk
ZXJlZmVyZW5jZSB0aGUgc3ltbGluayBhbmQgZmFpbCwgYXMgcmVxdWlyZWQgYnkgUE9TSVguCisJ
VGhhdCBpcyBiZXR0ZXIgaW4gdGhlIHNlbnNlIHRoYXQgaXQgbWVhbnMgd2Ugd2lsbCBub3QKKwlo
YXZlIHRvIGNvbXBpbGUgYW5kIHVzZSB0aGUgbHN0YXQgd3JhcHBlci4gICovCisgICAgIHJldHVy
biBsc3RhdCAoImNvbmZ0ZXN0LnN5bS8iLCAmc2J1ZikgPT0gMDsKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2
X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz15ZXMKK2Vsc2UKKyAgYWNf
Y3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCitmaQorcm0gLWYg
Y29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19l
eGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAorZmkKKworZWxzZQorICAjIElmIHRoZSBgbG4gLXMnIGNvbW1hbmQgZmFpbGVkLCB0aGVu
IHdlIHByb2JhYmx5IGRvbid0IGV2ZW4KKyAgIyBoYXZlIGFuIGxzdGF0IGZ1bmN0aW9uLgorICBh
Y19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KK2ZpCitybSAt
ZiBjb25mdGVzdC5zeW0gY29uZnRlc3QuZmlsZQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNl
c19zbGFzaGVkX3N5bWxpbmsiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX2xzdGF0X2RlcmVm
ZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID4mNjsgfQorCit0ZXN0ICRhY19jdl9mdW5jX2xzdGF0
X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsgPSB5ZXMgJiYKKworY2F0ID4+Y29uZmRlZnMu
aCA8PF9BQ0VPRgorI2RlZmluZSBMU1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSyAxCitfQUNF
T0YKKworCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRf
c3ltbGluayIgPSB4bm87IHRoZW4KKyAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbHN0YXQu
JGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIGxzdGF0LiRhY19vYmpl
eHQiCisgOzsKK2VzYWMKKworZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRldiIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHN5cy90eXBlcy5oIGRlZmluZXMgbWFrZWRl
di4uLiAiID4mNjsgfQoraWYgJHthY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldis6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KK2ludAorbWFpbiAoKQoreworcmV0dXJuIG1h
a2VkZXYoMCwgMCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5
X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2Vk
ZXY9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2PW5vCitmaQor
cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRl
c3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21h
a2VkZXYiID4mNQorJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiIg
PiY2OyB9CisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2ID0gbm87
IHRoZW4KK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvbWtkZXYu
aCIgImFjX2N2X2hlYWRlcl9zeXNfbWtkZXZfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYg
dGVzdCAieCRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2giID0geHllczsgdGhlbiA6CisKKyRhc19l
Y2hvICIjZGVmaW5lIE1BSk9SX0lOX01LREVWIDEiID4+Y29uZmRlZnMuaAorCitmaQorCisKKwor
ICBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2ggPSBubzsgdGhlbgorICAgIGFjX2Zu
X2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvc3lzbWFjcm9zLmgiICJhY19j
dl9oZWFkZXJfc3lzX3N5c21hY3Jvc19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0
ICJ4JGFjX2N2X2hlYWRlcl9zeXNfc3lzbWFjcm9zX2giID0geHllczsgdGhlbiA6CisKKyRhc19l
Y2hvICIjZGVmaW5lIE1BSk9SX0lOX1NZU01BQ1JPUyAxIiA+PmNvbmZkZWZzLmgKKworZmkKKwor
CisgIGZpCitmaQorCitmb3IgYWNfaGVhZGVyIGluIHN0ZGxpYi5oCitkbyA6CisgIGFjX2ZuX2Nf
Y2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9z
dGRsaWJfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJf
c3RkbGliX2giID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgSEFWRV9TVERMSUJfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21w
YXRpYmxlIG1hbGxvYyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgR05VIGxpYmMgY29t
cGF0aWJsZSBtYWxsb2MuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u
dWxsKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5j
X21hbGxvY18wX25vbm51bGw9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmIGRlZmluZWQgU1RE
Q19IRUFERVJTIHx8IGRlZmluZWQgSEFWRV9TVERMSUJfSAorIyBpbmNsdWRlIDxzdGRsaWIuaD4K
KyNlbHNlCitjaGFyICptYWxsb2MgKCk7CisjZW5kaWYKKworaW50CittYWluICgpCit7CityZXR1
cm4gISBtYWxsb2MgKDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9j
X3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxs
PXllcworZWxzZQorICBhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGw9bm8KK2ZpCitybSAtZiBj
b3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNf
ZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX21hbGxvY18wX25vbm51bGwiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19tYWxs
b2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxM
T0MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NQUxM
T0MgMCIgPj5jb25mZGVmcy5oCisKKyAgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIG1hbGxv
Yy4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgbWFsbG9jLiRhY19v
YmpleHQiCisgOzsKK2VzYWMKKworCiskYXNfZWNobyAiI2RlZmluZSBtYWxsb2MgcnBsX21hbGxv
YyIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90
aCBiZSBpbmNsdWRlZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHRpbWUuaCBh
bmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNsdWRlZC4uLiAiID4mNjsgfQoraWYgJHthY19j
dl9oZWFkZXJfdGltZSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK
Ky8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRl
IDxzeXMvdGltZS5oPgorI2luY2x1ZGUgPHRpbWUuaD4KKworaW50CittYWluICgpCit7CitpZiAo
KHN0cnVjdCB0bSAqKSAwKQorcmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfaGVhZGVy
X3RpbWU9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRlcl90aW1lPW5vCitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFk
ZXJfdGltZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl90aW1lIiA+JjY7IH0KK2lmIHRl
c3QgJGFjX2N2X2hlYWRlcl90aW1lID0geWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIFRJ
TUVfV0lUSF9TWVNfVElNRSAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisKKworICBmb3IgYWNf
aGVhZGVyIGluICRhY19oZWFkZXJfbGlzdAorZG8gOgorICBhc19hY19IZWFkZXI9YCRhc19lY2hv
ICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2hl
YWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFkZXIiICIkYWNf
aW5jbHVkZXNfZGVmYXVsdAorIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19IZWFkZXIiXCIg
PSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAk
YXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VPRgorCitmaQor
Citkb25lCisKKworCisKKworCisKKworICBmb3IgYWNfZnVuYyBpbiAkYWNfZnVuY19saXN0Citk
byA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3Ry
X3NoYAorYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFy
IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBj
YXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfZnVu
YyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKK2RvbmUKKworCisKKworCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1r
dGltZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBta3RpbWUuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfZnVuY193b3JraW5nX21rdGltZSs6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21w
aWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubworZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisvKiBUZXN0IHByb2dyYW0gZnJvbSBQYXVsIEVnZ2VydCBhbmQgVG9u
eSBMZW5laXMuICAqLworI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQorIyBpbmNsdWRlIDxzeXMv
dGltZS5oPgorIyBpbmNsdWRlIDx0aW1lLmg+CisjZWxzZQorIyBpZmRlZiBIQVZFX1NZU19USU1F
X0gKKyMgIGluY2x1ZGUgPHN5cy90aW1lLmg+CisjIGVsc2UKKyMgIGluY2x1ZGUgPHRpbWUuaD4K
KyMgZW5kaWYKKyNlbmRpZgorCisjaW5jbHVkZSA8bGltaXRzLmg+CisjaW5jbHVkZSA8c3RkbGli
Lmg+CisKKyNpZmRlZiBIQVZFX1VOSVNURF9ICisjIGluY2x1ZGUgPHVuaXN0ZC5oPgorI2VuZGlm
CisKKyNpZm5kZWYgSEFWRV9BTEFSTQorIyBkZWZpbmUgYWxhcm0oWCkgLyogZW1wdHkgKi8KKyNl
bmRpZgorCisvKiBXb3JrIGFyb3VuZCByZWRlZmluaXRpb24gdG8gcnBsX3B1dGVudiBieSBvdGhl
ciBjb25maWcgdGVzdHMuICAqLworI3VuZGVmIHB1dGVudgorCitzdGF0aWMgdGltZV90IHRpbWVf
dF9tYXg7CitzdGF0aWMgdGltZV90IHRpbWVfdF9taW47CisKKy8qIFZhbHVlcyB3ZSdsbCB1c2Ug
dG8gc2V0IHRoZSBUWiBlbnZpcm9ubWVudCB2YXJpYWJsZS4gICovCitzdGF0aWMgY29uc3QgY2hh
ciAqdHpfc3RyaW5nc1tdID0geworICAoY29uc3QgY2hhciAqKSAwLCAiVFo9R01UMCIsICJUWj1K
U1QtOSIsCisgICJUWj1FU1QrM0VEVCsyLE0xMC4xLjAvMDA6MDA6MDAsTTIuMy4wLzAwOjAwOjAw
IgorfTsKKyNkZWZpbmUgTl9TVFJJTkdTIChzaXplb2YgKHR6X3N0cmluZ3MpIC8gc2l6ZW9mICh0
el9zdHJpbmdzWzBdKSkKKworLyogUmV0dXJuIDAgaWYgbWt0aW1lIGZhaWxzIHRvIGNvbnZlcnQg
YSBkYXRlIGluIHRoZSBzcHJpbmctZm9yd2FyZCBnYXAuCisgICBCYXNlZCBvbiBhIHByb2JsZW0g
cmVwb3J0IGZyb20gQW5kcmVhcyBKYWVnZXIuICAqLworc3RhdGljIGludAorc3ByaW5nX2Zvcndh
cmRfZ2FwICgpCit7CisgIC8qIGdsaWJjICh1cCB0byBhYm91dCAxOTk4LTEwLTA3KSBmYWlsZWQg
dGhpcyB0ZXN0LiAqLworICBzdHJ1Y3QgdG0gdG07CisKKyAgLyogVXNlIHRoZSBwb3J0YWJsZSBQ
T1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCisgICAgIGlu
c3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBkZXRlY3QgdGhlIGJ1
ZyBldmVuCisgICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBleHRl
bnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCisgICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGluc3Rh
bGxlZC4gICovCisgIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUuMCIp
OworCisgIHRtLnRtX3llYXIgPSA5ODsKKyAgdG0udG1fbW9uID0gMzsKKyAgdG0udG1fbWRheSA9
IDU7CisgIHRtLnRtX2hvdXIgPSAyOworICB0bS50bV9taW4gPSAwOworICB0bS50bV9zZWMgPSAw
OworICB0bS50bV9pc2RzdCA9IC0xOworICByZXR1cm4gbWt0aW1lICgmdG0pICE9ICh0aW1lX3Qp
IC0xOworfQorCitzdGF0aWMgaW50Citta3RpbWVfdGVzdDEgKHRpbWVfdCBub3cpCit7CisgIHN0
cnVjdCB0bSAqbHQ7CisgIHJldHVybiAhIChsdCA9IGxvY2FsdGltZSAoJm5vdykpIHx8IG1rdGlt
ZSAobHQpID09IG5vdzsKK30KKworc3RhdGljIGludAorbWt0aW1lX3Rlc3QgKHRpbWVfdCBub3cp
Cit7CisgIHJldHVybiAobWt0aW1lX3Rlc3QxIChub3cpCisJICAmJiBta3RpbWVfdGVzdDEgKCh0
aW1lX3QpICh0aW1lX3RfbWF4IC0gbm93KSkKKwkgICYmIG1rdGltZV90ZXN0MSAoKHRpbWVfdCkg
KHRpbWVfdF9taW4gKyBub3cpKSk7Cit9CisKK3N0YXRpYyBpbnQKK2lyaXhfNl80X2J1ZyAoKQor
eworICAvKiBCYXNlZCBvbiBjb2RlIGZyb20gQXJpZWwgRmFpZ29uLiAgKi8KKyAgc3RydWN0IHRt
IHRtOworICB0bS50bV95ZWFyID0gOTY7CisgIHRtLnRtX21vbiA9IDM7CisgIHRtLnRtX21kYXkg
PSAwOworICB0bS50bV9ob3VyID0gMDsKKyAgdG0udG1fbWluID0gMDsKKyAgdG0udG1fc2VjID0g
MDsKKyAgdG0udG1faXNkc3QgPSAtMTsKKyAgbWt0aW1lICgmdG0pOworICByZXR1cm4gdG0udG1f
bW9uID09IDIgJiYgdG0udG1fbWRheSA9PSAzMTsKK30KKworc3RhdGljIGludAorYmlndGltZV90
ZXN0IChpbnQgaikKK3sKKyAgc3RydWN0IHRtIHRtOworICB0aW1lX3Qgbm93OworICB0bS50bV95
ZWFyID0gdG0udG1fbW9uID0gdG0udG1fbWRheSA9IHRtLnRtX2hvdXIgPSB0bS50bV9taW4gPSB0
bS50bV9zZWMgPSBqOworICBub3cgPSBta3RpbWUgKCZ0bSk7CisgIGlmIChub3cgIT0gKHRpbWVf
dCkgLTEpCisgICAgeworICAgICAgc3RydWN0IHRtICpsdCA9IGxvY2FsdGltZSAoJm5vdyk7Cisg
ICAgICBpZiAoISAobHQKKwkgICAgICYmIGx0LT50bV95ZWFyID09IHRtLnRtX3llYXIKKwkgICAg
ICYmIGx0LT50bV9tb24gPT0gdG0udG1fbW9uCisJICAgICAmJiBsdC0+dG1fbWRheSA9PSB0bS50
bV9tZGF5CisJICAgICAmJiBsdC0+dG1faG91ciA9PSB0bS50bV9ob3VyCisJICAgICAmJiBsdC0+
dG1fbWluID09IHRtLnRtX21pbgorCSAgICAgJiYgbHQtPnRtX3NlYyA9PSB0bS50bV9zZWMKKwkg
ICAgICYmIGx0LT50bV95ZGF5ID09IHRtLnRtX3lkYXkKKwkgICAgICYmIGx0LT50bV93ZGF5ID09
IHRtLnRtX3dkYXkKKwkgICAgICYmICgobHQtPnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IGx0LT50
bV9pc2RzdCkKKwkJICA9PSAodG0udG1faXNkc3QgPCAwID8gLTEgOiAwIDwgdG0udG1faXNkc3Qp
KSkpCisJcmV0dXJuIDA7CisgICAgfQorICByZXR1cm4gMTsKK30KKworc3RhdGljIGludAoreWVh
cl8yMDUwX3Rlc3QgKCkKK3sKKyAgLyogVGhlIGNvcnJlY3QgYW5zd2VyIGZvciAyMDUwLTAyLTAx
IDAwOjAwOjAwIGluIFBhY2lmaWMgdGltZSwKKyAgICAgaWdub3JpbmcgbGVhcCBzZWNvbmRzLiAg
Ki8KKyAgdW5zaWduZWQgbG9uZyBpbnQgYW5zd2VyID0gMjUyNzMxNTIwMFVMOworCisgIHN0cnVj
dCB0bSB0bTsKKyAgdGltZV90IHQ7CisgIHRtLnRtX3llYXIgPSAyMDUwIC0gMTkwMDsKKyAgdG0u
dG1fbW9uID0gMiAtIDE7CisgIHRtLnRtX21kYXkgPSAxOworICB0bS50bV9ob3VyID0gdG0udG1f
bWluID0gdG0udG1fc2VjID0gMDsKKyAgdG0udG1faXNkc3QgPSAtMTsKKworICAvKiBVc2UgdGhl
IHBvcnRhYmxlIFBPU0lYLjEgc3BlY2lmaWNhdGlvbiAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUu
MCIKKyAgICAgaW5zdGVhZCBvZiAiVFo9QW1lcmljYS9WYW5jb3V2ZXIiIGluIG9yZGVyIHRvIGRl
dGVjdCB0aGUgYnVnIGV2ZW4KKyAgICAgb24gc3lzdGVtcyB0aGF0IGRvbid0IHN1cHBvcnQgdGhl
IE9sc29uIGV4dGVuc2lvbiwgb3IgZG9uJ3QgaGF2ZSB0aGUKKyAgICAgZnVsbCB6b25laW5mbyB0
YWJsZXMgaW5zdGFsbGVkLiAgKi8KKyAgcHV0ZW52ICgoY2hhciopICJUWj1QU1Q4UERULE00LjEu
MCxNMTAuNS4wIik7CisKKyAgdCA9IG1rdGltZSAoJnRtKTsKKworICAvKiBDaGVjayB0aGF0IHRo
ZSByZXN1bHQgaXMgZWl0aGVyIGEgZmFpbHVyZSwgb3IgY2xvc2UgZW5vdWdoCisgICAgIHRvIHRo
ZSBjb3JyZWN0IGFuc3dlciB0aGF0IHdlIGNhbiBhc3N1bWUgdGhlIGRpc2NyZXBhbmN5IGlzCisg
ICAgIGR1ZSB0byBsZWFwIHNlY29uZHMuICAqLworICByZXR1cm4gKHQgPT0gKHRpbWVfdCkgLTEK
KwkgIHx8ICgwIDwgdCAmJiBhbnN3ZXIgLSAxMjAgPD0gdCAmJiB0IDw9IGFuc3dlciArIDEyMCkp
OworfQorCitpbnQKK21haW4gKCkKK3sKKyAgdGltZV90IHQsIGRlbHRhOworICBpbnQgaSwgajsK
KworICAvKiBUaGlzIHRlc3QgbWFrZXMgc29tZSBidWdneSBta3RpbWUgaW1wbGVtZW50YXRpb25z
IGxvb3AuCisgICAgIEdpdmUgdXAgYWZ0ZXIgNjAgc2Vjb25kczsgYSBta3RpbWUgc2xvd2VyIHRo
YW4gdGhhdAorICAgICBpc24ndCB3b3J0aCB1c2luZyBhbnl3YXkuICAqLworICBhbGFybSAoNjAp
OworCisgIGZvciAoOzspCisgICAgeworICAgICAgdCA9ICh0aW1lX3RfbWF4IDw8IDEpICsgMTsK
KyAgICAgIGlmICh0IDw9IHRpbWVfdF9tYXgpCisJYnJlYWs7CisgICAgICB0aW1lX3RfbWF4ID0g
dDsKKyAgICB9CisgIHRpbWVfdF9taW4gPSAtICgodGltZV90KSB+ICh0aW1lX3QpIDAgPT0gKHRp
bWVfdCkgLTEpIC0gdGltZV90X21heDsKKworICBkZWx0YSA9IHRpbWVfdF9tYXggLyA5OTc7IC8q
IGEgc3VpdGFibGUgcHJpbWUgbnVtYmVyICovCisgIGZvciAoaSA9IDA7IGkgPCBOX1NUUklOR1M7
IGkrKykKKyAgICB7CisgICAgICBpZiAodHpfc3RyaW5nc1tpXSkKKwlwdXRlbnYgKChjaGFyKikg
dHpfc3RyaW5nc1tpXSk7CisKKyAgICAgIGZvciAodCA9IDA7IHQgPD0gdGltZV90X21heCAtIGRl
bHRhOyB0ICs9IGRlbHRhKQorCWlmICghIG1rdGltZV90ZXN0ICh0KSkKKwkgIHJldHVybiAxOwor
ICAgICAgaWYgKCEgKG1rdGltZV90ZXN0ICgodGltZV90KSAxKQorCSAgICAgJiYgbWt0aW1lX3Rl
c3QgKCh0aW1lX3QpICg2MCAqIDYwKSkKKwkgICAgICYmIG1rdGltZV90ZXN0ICgodGltZV90KSAo
NjAgKiA2MCAqIDI0KSkpKQorCXJldHVybiAxOworCisgICAgICBmb3IgKGogPSAxOyA7IGogPDw9
IDEpCisJaWYgKCEgYmlndGltZV90ZXN0IChqKSkKKwkgIHJldHVybiAxOworCWVsc2UgaWYgKElO
VF9NQVggLyAyIDwgaikKKwkgIGJyZWFrOworICAgICAgaWYgKCEgYmlndGltZV90ZXN0IChJTlRf
TUFYKSkKKwlyZXR1cm4gMTsKKyAgICB9CisgIHJldHVybiAhIChpcml4XzZfNF9idWcgKCkgJiYg
c3ByaW5nX2ZvcndhcmRfZ2FwICgpICYmIHllYXJfMjA1MF90ZXN0ICgpKTsKK30KK19BQ0VPRgor
aWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfd29ya2lu
Z19ta3RpbWU9eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWU9bm8KK2ZpCity
bSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0
JGFjX2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVz
dC4kYWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjUKKyRhc19lY2hvICIk
YWNfY3ZfZnVuY193b3JraW5nX21rdGltZSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX3dv
cmtpbmdfbWt0aW1lID0gbm87IHRoZW4KKyAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIgbWt0
aW1lLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBta3RpbWUuJGFj
X29iamV4dCIKKyA7OworZXNhYworCitmaQorCisKKworCisKKworZm9yIGFjX2Z1bmMgaW4gZ2V0
cGFnZXNpemUKK2RvIDoKKyAgYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiZ2V0cGFnZXNp
emUiICJhY19jdl9mdW5jX2dldHBhZ2VzaXplIgoraWYgdGVzdCAieCRhY19jdl9mdW5jX2dldHBh
Z2VzaXplIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVm
aW5lIEhBVkVfR0VUUEFHRVNJWkUgMQorX0FDRU9GCisKK2ZpCitkb25lCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBtbWFwLi4uICIgPiY2OyB9Citp
ZiAke2FjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNf
ZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5n
IiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQ9bm8KK2Vsc2UK
KyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNv
bmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKy8qIG1hbGxvYyBtaWdodCBoYXZl
IGJlZW4gcmVuYW1lZCBhcyBycGxfbWFsbG9jLiAqLworI3VuZGVmIG1hbGxvYworCisvKiBUaGFu
a3MgdG8gTWlrZSBIYWVydGVsIGFuZCBKaW0gQXZlcmEgZm9yIHRoaXMgdGVzdC4KKyAgIEhlcmUg
aXMgYSBtYXRyaXggb2YgbW1hcCBwb3NzaWJpbGl0aWVzOgorCW1tYXAgcHJpdmF0ZSBub3QgZml4
ZWQKKwltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJlbnRseSB1bm1hcHBlZAor
CW1tYXAgcHJpdmF0ZSBmaXhlZCBhdCBzb21ld2hlcmUgYWxyZWFkeSBtYXBwZWQKKwltbWFwIHNo
YXJlZCBub3QgZml4ZWQKKwltbWFwIHNoYXJlZCBmaXhlZCBhdCBzb21ld2hlcmUgY3VycmVudGx5
IHVubWFwcGVkCisJbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVk
CisgICBGb3IgcHJpdmF0ZSBtYXBwaW5ncywgd2Ugc2hvdWxkIHZlcmlmeSB0aGF0IGNoYW5nZXMg
Y2Fubm90IGJlIHJlYWQoKQorICAgYmFjayBmcm9tIHRoZSBmaWxlLCBub3IgbW1hcCdzIGJhY2sg
ZnJvbSB0aGUgZmlsZSBhdCBhIGRpZmZlcmVudAorICAgYWRkcmVzcy4gIChUaGVyZSBoYXZlIGJl
ZW4gc3lzdGVtcyB3aGVyZSBwcml2YXRlIHdhcyBub3QgY29ycmVjdGx5CisgICBpbXBsZW1lbnRl
ZCBsaWtlIHRoZSBpbmZhbW91cyBpMzg2IHN2cjQuMCwgYW5kIHN5c3RlbXMgd2hlcmUgdGhlCisg
ICBWTSBwYWdlIGNhY2hlIHdhcyBub3QgY29oZXJlbnQgd2l0aCB0aGUgZmlsZSBzeXN0ZW0gYnVm
ZmVyIGNhY2hlCisgICBsaWtlIGVhcmx5IHZlcnNpb25zIG9mIEZyZWVCU0QgYW5kIHBvc3NpYmx5
IGNvbnRlbXBvcmFyeSBOZXRCU0QuKQorICAgRm9yIHNoYXJlZCBtYXBwaW5ncywgd2Ugc2hvdWxk
IGNvbnZlcnNlbHkgdmVyaWZ5IHRoYXQgY2hhbmdlcyBnZXQKKyAgIHByb3BhZ2F0ZWQgYmFjayB0
byBhbGwgdGhlIHBsYWNlcyB0aGV5J3JlIHN1cHBvc2VkIHRvIGJlLgorCisgICBHcmVwIHdhbnRz
IHByaXZhdGUgZml4ZWQgYWxyZWFkeSBtYXBwZWQuCisgICBUaGUgbWFpbiB0aGluZ3MgZ3JlcCBu
ZWVkcyB0byBrbm93IGFib3V0IG1tYXAgYXJlOgorICAgKiBkb2VzIGl0IGV4aXN0IGFuZCBpcyBp
dCBzYWZlIHRvIHdyaXRlIGludG8gdGhlIG1tYXAnZCBhcmVhCisgICAqIGhvdyB0byB1c2UgaXQg
KEJTRCB2YXJpYW50cykgICovCisKKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPHN5cy9t
bWFuLmg+CisKKyNpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgIWRlZmluZWQgSEFWRV9TVERM
SUJfSAorY2hhciAqbWFsbG9jICgpOworI2VuZGlmCisKKy8qIFRoaXMgbWVzcyB3YXMgY29waWVk
IGZyb20gdGhlIEdOVSBnZXRwYWdlc2l6ZS5oLiAgKi8KKyNpZm5kZWYgSEFWRV9HRVRQQUdFU0la
RQorIyBpZmRlZiBfU0NfUEFHRVNJWkUKKyMgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIHN5c2NvbmYo
X1NDX1BBR0VTSVpFKQorIyBlbHNlIC8qIG5vIF9TQ19QQUdFU0laRSAqLworIyAgaWZkZWYgSEFW
RV9TWVNfUEFSQU1fSAorIyAgIGluY2x1ZGUgPHN5cy9wYXJhbS5oPgorIyAgIGlmZGVmIEVYRUNf
UEFHRVNJWkUKKyMgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgRVhFQ19QQUdFU0laRQorIyAgIGVs
c2UgLyogbm8gRVhFQ19QQUdFU0laRSAqLworIyAgICBpZmRlZiBOQlBHCisjICAgICBkZWZpbmUg
Z2V0cGFnZXNpemUoKSBOQlBHICogQ0xTSVpFCisjICAgICBpZm5kZWYgQ0xTSVpFCisjICAgICAg
ZGVmaW5lIENMU0laRSAxCisjICAgICBlbmRpZiAvKiBubyBDTFNJWkUgKi8KKyMgICAgZWxzZSAv
KiBubyBOQlBHICovCisjICAgICBpZmRlZiBOQlBDCisjICAgICAgZGVmaW5lIGdldHBhZ2VzaXpl
KCkgTkJQQworIyAgICAgZWxzZSAvKiBubyBOQlBDICovCisjICAgICAgaWZkZWYgUEFHRVNJWkUK
KyMgICAgICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgUEFHRVNJWkUKKyMgICAgICBlbmRpZiAvKiBQ
QUdFU0laRSAqLworIyAgICAgZW5kaWYgLyogbm8gTkJQQyAqLworIyAgICBlbmRpZiAvKiBubyBO
QlBHICovCisjICAgZW5kaWYgLyogbm8gRVhFQ19QQUdFU0laRSAqLworIyAgZWxzZSAvKiBubyBI
QVZFX1NZU19QQVJBTV9IICovCisjICAgZGVmaW5lIGdldHBhZ2VzaXplKCkgODE5MgkvKiBwdW50
IHRvdGFsbHkgKi8KKyMgIGVuZGlmIC8qIG5vIEhBVkVfU1lTX1BBUkFNX0ggKi8KKyMgZW5kaWYg
Lyogbm8gX1NDX1BBR0VTSVpFICovCisKKyNlbmRpZiAvKiBubyBIQVZFX0dFVFBBR0VTSVpFICov
CisKK2ludAorbWFpbiAoKQoreworICBjaGFyICpkYXRhLCAqZGF0YTIsICpkYXRhMzsKKyAgY29u
c3QgY2hhciAqY2RhdGEyOworICBpbnQgaSwgcGFnZXNpemU7CisgIGludCBmZCwgZmQyOworCisg
IHBhZ2VzaXplID0gZ2V0cGFnZXNpemUgKCk7CisKKyAgLyogRmlyc3QsIG1ha2UgYSBmaWxlIHdp
dGggc29tZSBrbm93biBnYXJiYWdlIGluIGl0LiAqLworICBkYXRhID0gKGNoYXIgKikgbWFsbG9j
IChwYWdlc2l6ZSk7CisgIGlmICghZGF0YSkKKyAgICByZXR1cm4gMTsKKyAgZm9yIChpID0gMDsg
aSA8IHBhZ2VzaXplOyArK2kpCisgICAgKihkYXRhICsgaSkgPSByYW5kICgpOworICB1bWFzayAo
MCk7CisgIGZkID0gY3JlYXQgKCJjb25mdGVzdC5tbWFwIiwgMDYwMCk7CisgIGlmIChmZCA8IDAp
CisgICAgcmV0dXJuIDI7CisgIGlmICh3cml0ZSAoZmQsIGRhdGEsIHBhZ2VzaXplKSAhPSBwYWdl
c2l6ZSkKKyAgICByZXR1cm4gMzsKKyAgY2xvc2UgKGZkKTsKKworICAvKiBOZXh0LCBjaGVjayB0
aGF0IHRoZSB0YWlsIG9mIGEgcGFnZSBpcyB6ZXJvLWZpbGxlZC4gIEZpbGUgbXVzdCBoYXZlCisg
ICAgIG5vbi16ZXJvIGxlbmd0aCwgb3RoZXJ3aXNlIHdlIHJpc2sgU0lHQlVTIGZvciBlbnRpcmUg
cGFnZS4gICovCisgIGZkMiA9IG9wZW4gKCJjb25mdGVzdC50eHQiLCBPX1JEV1IgfCBPX0NSRUFU
IHwgT19UUlVOQywgMDYwMCk7CisgIGlmIChmZDIgPCAwKQorICAgIHJldHVybiA0OworICBjZGF0
YTIgPSAiIjsKKyAgaWYgKHdyaXRlIChmZDIsIGNkYXRhMiwgMSkgIT0gMSkKKyAgICByZXR1cm4g
NTsKKyAgZGF0YTIgPSAoY2hhciAqKSBtbWFwICgwLCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJP
VF9XUklURSwgTUFQX1NIQVJFRCwgZmQyLCAwTCk7CisgIGlmIChkYXRhMiA9PSBNQVBfRkFJTEVE
KQorICAgIHJldHVybiA2OworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAgICBp
ZiAoKihkYXRhMiArIGkpKQorICAgICAgcmV0dXJuIDc7CisgIGNsb3NlIChmZDIpOworICBpZiAo
bXVubWFwIChkYXRhMiwgcGFnZXNpemUpKQorICAgIHJldHVybiA4OworCisgIC8qIE5leHQsIHRy
eSB0byBtbWFwIHRoZSBmaWxlIGF0IGEgZml4ZWQgYWRkcmVzcyB3aGljaCBhbHJlYWR5IGhhcwor
ICAgICBzb21ldGhpbmcgZWxzZSBhbGxvY2F0ZWQgYXQgaXQuICBJZiB3ZSBjYW4sIGFsc28gbWFr
ZSBzdXJlIHRoYXQKKyAgICAgd2Ugc2VlIHRoZSBzYW1lIGdhcmJhZ2UuICAqLworICBmZCA9IG9w
ZW4gKCJjb25mdGVzdC5tbWFwIiwgT19SRFdSKTsKKyAgaWYgKGZkIDwgMCkKKyAgICByZXR1cm4g
OTsKKyAgaWYgKGRhdGEyICE9IG1tYXAgKGRhdGEyLCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJP
VF9XUklURSwKKwkJICAgICBNQVBfUFJJVkFURSB8IE1BUF9GSVhFRCwgZmQsIDBMKSkKKyAgICBy
ZXR1cm4gMTA7CisgIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgIGlmICgqKGRh
dGEgKyBpKSAhPSAqKGRhdGEyICsgaSkpCisgICAgICByZXR1cm4gMTE7CisKKyAgLyogRmluYWxs
eSwgbWFrZSBzdXJlIHRoYXQgY2hhbmdlcyB0byB0aGUgbWFwcGVkIGFyZWEgZG8gbm90CisgICAg
IHBlcmNvbGF0ZSBiYWNrIHRvIHRoZSBmaWxlIGFzIHNlZW4gYnkgcmVhZCgpLiAgKFRoaXMgaXMg
YSBidWcgb24KKyAgICAgc29tZSB2YXJpYW50cyBvZiBpMzg2IHN2cjQuMC4pICAqLworICBmb3Ig
KGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAgICAqKGRhdGEyICsgaSkgPSAqKGRhdGEyICsg
aSkgKyAxOworICBkYXRhMyA9IChjaGFyICopIG1hbGxvYyAocGFnZXNpemUpOworICBpZiAoIWRh
dGEzKQorICAgIHJldHVybiAxMjsKKyAgaWYgKHJlYWQgKGZkLCBkYXRhMywgcGFnZXNpemUpICE9
IHBhZ2VzaXplKQorICAgIHJldHVybiAxMzsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyAr
K2kpCisgICAgaWYgKCooZGF0YSArIGkpICE9ICooZGF0YTMgKyBpKSkKKyAgICAgIHJldHVybiAx
NDsKKyAgY2xvc2UgKGZkKTsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5
X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPXll
cworZWxzZQorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCitmaQorcm0gLWYgY29y
ZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVl
eHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4
dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiAkYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY19tbWFw
X2ZpeGVkX21hcHBlZCA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX01NQVAg
MSIgPj5jb25mZGVmcy5oCisKK2ZpCitybSAtZiBjb25mdGVzdC5tbWFwIGNvbmZ0ZXN0LnR4dAor
Citmb3IgYWNfaGVhZGVyIGluIHN0ZGxpYi5oCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVy
X21vbmdyZWwgIiRMSU5FTk8iICJzdGRsaWIuaCIgImFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgIiRh
Y19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfc3RkbGliX2giID0g
eHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9T
VERMSUJfSCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIHJlYWxs
b2MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgcmVh
bGxvYy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX3JlYWxsb2Nf
MF9ub25udWxsPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0
LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBkZWZpbmVkIFNURENfSEVBREVS
UyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKKyMgaW5jbHVkZSA8c3RkbGliLmg+CisjZWxzZQor
Y2hhciAqcmVhbGxvYyAoKTsKKyNlbmRpZgorCitpbnQKK21haW4gKCkKK3sKK3JldHVybiAhIHJl
YWxsb2MgKDAsIDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD15
ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD1ubworZmkKK3JtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l
eHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGwiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfcmVh
bGxvY18wX25vbm51bGwgPSB5ZXM7IHRoZW4gOgorCiskYXNfZWNobyAiI2RlZmluZSBIQVZFX1JF
QUxMT0MgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9S
RUFMTE9DIDAiID4+Y29uZmRlZnMuaAorCisgICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBy
ZWFsbG9jLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyByZWFsbG9j
LiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworCiskYXNfZWNobyAiI2RlZmluZSByZWFsbG9jIHJw
bF9yZWFsbG9jIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBzdHJubGVuIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4uLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19u
ICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHll
czsgdGhlbiA6CisgICMgR3Vlc3Mgbm8gb24gQUlYIHN5c3RlbXMsIHllcyBvdGhlcndpc2UuCisJ
CWNhc2UgIiRob3N0X29zIiBpbgorCQkgIGFpeCopIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5n
PW5vOzsKKwkJICAqKSAgICBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXM7OworCQllc2Fj
CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQKK21haW4gKCkK
K3sKKworI2RlZmluZSBTICJmb29iYXIiCisjZGVmaW5lIFNfTEVOIChzaXplb2YgUyAtIDEpCisK
KyAgLyogQXQgbGVhc3Qgb25lIGltcGxlbWVudGF0aW9uIGlzIGJ1Z2d5OiB0aGF0IG9mIEFJWCA0
LjMgd291bGQKKyAgICAgZ2l2ZSBzdHJubGVuIChTLCAxKSA9PSAzLiAgKi8KKworICBpbnQgaTsK
KyAgZm9yIChpID0gMDsgaSA8IFNfTEVOICsgMTsgKytpKQorICAgIHsKKyAgICAgIGludCBleHBl
Y3RlZCA9IGkgPD0gU19MRU4gPyBpIDogU19MRU47CisgICAgICBpZiAoc3RybmxlbiAoUywgaSkg
IT0gZXhwZWN0ZWQpCisJcmV0dXJuIDE7CisgICAgfQorICByZXR1cm4gMDsKKworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoK
KyAgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfc3Ry
bmxlbl93b3JraW5nPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdt
b24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0
IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJubGVuX3dv
cmtpbmciID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyIgPiY2OyB9
Cit0ZXN0ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyA9IG5vICYmIGNhc2UgIiAkTElCT0JK
UyAiIGluCisgICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRM
SUJPQkpTIHN0cm5sZW4uJGFjX29iamV4dCIKKyA7OworZXNhYworCisKK3sgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RydG9kIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9mdW5jX3N0cnRvZCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0
aGVuIDoKKyAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8
PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCiskYWNf
aW5jbHVkZXNfZGVmYXVsdAorI2lmbmRlZiBzdHJ0b2QKK2RvdWJsZSBzdHJ0b2QgKCk7CisjZW5k
aWYKK2ludAorbWFpbigpCit7CisgIHsKKyAgICAvKiBTb21lIHZlcnNpb25zIG9mIExpbnV4IHN0
cnRvZCBtaXMtcGFyc2Ugc3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KKyAgICBjaGFyICpz
dHJpbmcgPSAiICs2OSI7CisgICAgY2hhciAqdGVybTsKKyAgICBkb3VibGUgdmFsdWU7CisgICAg
dmFsdWUgPSBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOworICAgIGlmICh2YWx1ZSAhPSA2OSB8fCB0
ZXJtICE9IChzdHJpbmcgKyA0KSkKKyAgICAgIHJldHVybiAxOworICB9CisKKyAgeworICAgIC8q
IFVuZGVyIFNvbGFyaXMgMi40LCBzdHJ0b2QgcmV0dXJucyB0aGUgd3JvbmcgdmFsdWUgZm9yIHRo
ZQorICAgICAgIHRlcm1pbmF0aW5nIGNoYXJhY3RlciB1bmRlciBzb21lIGNvbmRpdGlvbnMuICAq
LworICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOworICAgIGNoYXIgKnRlcm07CisgICAgc3RydG9k
IChzdHJpbmcsICZ0ZXJtKTsKKyAgICBpZiAodGVybSAhPSBzdHJpbmcgJiYgKih0ZXJtIC0gMSkg
PT0gMCkKKyAgICAgIHJldHVybiAxOworICB9CisgIHJldHVybiAwOworfQorCitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3N0cnRvZD15
ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KK2ZpCitybSAtZiBjb3JlICouY29yZSBj
b3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCisgIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitmaQorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9mdW5jX3N0cnRvZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfc3RydG9kIiA+JjY7IH0K
K2lmIHRlc3QgJGFjX2N2X2Z1bmNfc3RydG9kID0gbm87IHRoZW4KKyAgY2FzZSAiICRMSUJPQkpT
ICIgaW4KKyAgKiIgc3RydG9kLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElC
T0JKUyBzdHJ0b2QuJGFjX29iamV4dCIKKyA7OworZXNhYworCithY19mbl9jX2NoZWNrX2Z1bmMg
IiRMSU5FTk8iICJwb3ciICJhY19jdl9mdW5jX3BvdyIKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19w
b3ciID0geHllczsgdGhlbiA6CisKK2ZpCisKK2lmIHRlc3QgJGFjX2N2X2Z1bmNfcG93ID0gbm87
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgcG93IGluIC1sbSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgcG93IGluIC1s
bS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfbV9wb3crOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJT
PSRMSUJTCitMSUJTPSItbG0gICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u
ZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkg
R0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJl
Y2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRp
biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8K
KyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIHBvdyAoKTsKK2lu
dAorbWFpbiAoKQoreworcmV0dXJuIHBvdyAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VP
RgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfbV9w
b3c9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9tX3Bvdz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRl
c3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25m
dGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbV9wb3ci
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfbV9wb3ciID4mNjsgfQoraWYgdGVzdCAieCRhY19j
dl9saWJfbV9wb3ciID0geHllczsgdGhlbiA6CisgIFBPV19MSUI9LWxtCitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogY2Fubm90IGZpbmQg
bGlicmFyeSBjb250YWluaW5nIGRlZmluaXRpb24gb2YgcG93IiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IFdBUk5JTkc6IGNhbm5vdCBmaW5kIGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9m
IHBvdyIgPiYyO30KK2ZpCisKK2ZpCisKK2ZpCisKK2ZvciBhY19mdW5jIGluICBcCisgICAgICAg
ICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dldHRpbWUgZHVwMiBmZGF0YXN5bmMg
ZnRydW5jYXRlIFwKKyAgICAgICAgICAgICAgICBnZXRjd2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0
bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAorICAgICAgICAgICAgICAgIGluZXRfbnRv
YSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3ZlIG1lbXNldCBta2RpciBcCisgICAg
ICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiByZWFscGF0aCByZWdjb21wIHJtZGly
IHNlbGVjdCBzZXRlbnYgXAorICAgICAgICAgICAgICAgIHNvY2tldCBzdHJjYXNlY21wIHN0cmNo
ciBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwKKyAgICAgICAgICAgICAgICBzdHJw
YnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNldCBc
CisgICAgICAgICAgICAgICAgdW5hbWUgXAorCitkbyA6CisgIGFzX2FjX3Zhcj1gJGFzX2VjaG8g
ImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19mdW5jICIk
TElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNfdmFyIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19h
Y192YXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YK
KworZmkKK2RvbmUKKworCitjYXQgPmNvbmZjYWNoZSA8PFxfQUNFT0YKKyMgVGhpcyBmaWxlIGlz
IGEgc2hlbGwgc2NyaXB0IHRoYXQgY2FjaGVzIHRoZSByZXN1bHRzIG9mIGNvbmZpZ3VyZQorIyB0
ZXN0cyBydW4gb24gdGhpcyBzeXN0ZW0gc28gdGhleSBjYW4gYmUgc2hhcmVkIGJldHdlZW4gY29u
ZmlndXJlCisjIHNjcmlwdHMgYW5kIGNvbmZpZ3VyZSBydW5zLCBzZWUgY29uZmlndXJlJ3Mgb3B0
aW9uIC0tY29uZmlnLWNhY2hlLgorIyBJdCBpcyBub3QgdXNlZnVsIG9uIG90aGVyIHN5c3RlbXMu
ICBJZiBpdCBjb250YWlucyByZXN1bHRzIHlvdSBkb24ndAorIyB3YW50IHRvIGtlZXAsIHlvdSBt
YXkgcmVtb3ZlIG9yIGVkaXQgaXQuCisjCisjIGNvbmZpZy5zdGF0dXMgb25seSBwYXlzIGF0dGVu
dGlvbiB0byB0aGUgY2FjaGUgZmlsZSBpZiB5b3UgZ2l2ZSBpdAorIyB0aGUgLS1yZWNoZWNrIG9w
dGlvbiB0byByZXJ1biBjb25maWd1cmUuCisjCisjIGBhY19jdl9lbnZfZm9vJyB2YXJpYWJsZXMg
KHNldCBvciB1bnNldCkgd2lsbCBiZSBvdmVycmlkZGVuIHdoZW4KKyMgbG9hZGluZyB0aGlzIGZp
bGUsIG90aGVyICp1bnNldCogYGFjX2N2X2Zvbycgd2lsbCBiZSBhc3NpZ25lZCB0aGUKKyMgZm9s
bG93aW5nIHZhbHVlcy4KKworX0FDRU9GCisKKyMgVGhlIGZvbGxvd2luZyB3YXkgb2Ygd3JpdGlu
ZyB0aGUgY2FjaGUgbWlzaGFuZGxlcyBuZXdsaW5lcyBpbiB2YWx1ZXMsCisjIGJ1dCB3ZSBrbm93
IG9mIG5vIHdvcmthcm91bmQgdGhhdCBpcyBzaW1wbGUsIHBvcnRhYmxlLCBhbmQgZWZmaWNpZW50
LgorIyBTbywgd2Uga2lsbCB2YXJpYWJsZXMgY29udGFpbmluZyBuZXdsaW5lcy4KKyMgVWx0cml4
IHNoIHNldCB3cml0ZXMgdG8gc3RkZXJyIGFuZCBjYW4ndCBiZSByZWRpcmVjdGVkIGRpcmVjdGx5
LAorIyBhbmQgc2V0cyB0aGUgaGlnaCBiaXQgaW4gdGhlIGNhY2hlIGZpbGUgdW5sZXNzIHdlIGFz
c2lnbiB0byB0aGUgdmFycy4KKygKKyAgZm9yIGFjX3ZhciBpbiBgKHNldCkgMj4mMSB8IHNlZCAt
biAncy9eXChbYS16QS1aX11bYS16QS1aMC05X10qXCk9LiovXDEvcCdgOyBkbworICAgIGV2YWwg
YWNfdmFsPVwkJGFjX3ZhcgorICAgIGNhc2UgJGFjX3ZhbCBpbiAjKAorICAgICoke2FzX25sfSop
CisgICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgICpfY3ZfKikgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYWNoZSB2YXJpYWJsZSAkYWNfdmFy
IGNvbnRhaW5zIGEgbmV3bGluZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBjYWNo
ZSB2YXJpYWJsZSAkYWNfdmFyIGNvbnRhaW5zIGEgbmV3bGluZSIgPiYyO30gOzsKKyAgICAgIGVz
YWMKKyAgICAgIGNhc2UgJGFjX3ZhciBpbiAjKAorICAgICAgXyB8IElGUyB8IGFzX25sKSA7OyAj
KAorICAgICAgQkFTSF9BUkdWIHwgQkFTSF9TT1VSQ0UpIGV2YWwgJGFjX3Zhcj0gOzsgIygKKyAg
ICAgICopIHsgZXZhbCAkYWNfdmFyPTsgdW5zZXQgJGFjX3Zhcjt9IDs7CisgICAgICBlc2FjIDs7
CisgICAgZXNhYworICBkb25lCisKKyAgKHNldCkgMj4mMSB8CisgICAgY2FzZSAkYXNfbmxgKGFj
X3NwYWNlPScgJzsgc2V0KSAyPiYxYCBpbiAjKAorICAgICoke2FzX25sfWFjX3NwYWNlPVwgKikK
KyAgICAgICMgYHNldCcgZG9lcyBub3QgcXVvdGUgY29ycmVjdGx5LCBzbyBhZGQgcXVvdGVzOiBk
b3VibGUtcXVvdGUKKyAgICAgICMgc3Vic3RpdHV0aW9uIHR1cm5zIFxcXFwgaW50byBcXCwgYW5k
IHNlZCB0dXJucyBcXCBpbnRvIFwuCisgICAgICBzZWQgLW4gXAorCSJzLycvJ1xcXFwnJy9nOwor
CSAgcy9eXFwoW18kYXNfY3JfYWxudW1dKl9jdl9bXyRhc19jcl9hbG51bV0qXFwpPVxcKC4qXFwp
L1xcMT0nXFwyJy9wIgorICAgICAgOzsgIygKKyAgICAqKQorICAgICAgIyBgc2V0JyBxdW90ZXMg
Y29ycmVjdGx5IGFzIHJlcXVpcmVkIGJ5IFBPU0lYLCBzbyBkbyBub3QgYWRkIHF1b3Rlcy4KKyAg
ICAgIHNlZCAtbiAiL15bXyRhc19jcl9hbG51bV0qX2N2X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisg
ICAgICA7OworICAgIGVzYWMgfAorICAgIHNvcnQKKykgfAorICBzZWQgJworICAgICAvXmFjX2N2
X2Vudl8vYiBlbmQKKyAgICAgdCBjbGVhcgorICAgICA6Y2xlYXIKKyAgICAgcy9eXChbXj1dKlwp
PVwoLipbe31dLipcKSQvdGVzdCAiJHtcMStzZXR9IiA9IHNldCB8fCAmLworICAgICB0IGVuZAor
ICAgICBzL15cKFtePV0qXCk9XCguKlwpJC9cMT0ke1wxPVwyfS8KKyAgICAgOmVuZCcgPj5jb25m
Y2FjaGUKK2lmIGRpZmYgIiRjYWNoZV9maWxlIiBjb25mY2FjaGUgPi9kZXYvbnVsbCAyPiYxOyB0
aGVuIDo7IGVsc2UKKyAgaWYgdGVzdCAtdyAiJGNhY2hlX2ZpbGUiOyB0aGVuCisgICAgaWYgdGVz
dCAieCRjYWNoZV9maWxlIiAhPSAieC9kZXYvbnVsbCI7IHRoZW4KKyAgICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogdXBkYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUi
ID4mNQorJGFzX2VjaG8gIiRhc19tZTogdXBkYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9
CisgICAgICBpZiB0ZXN0ICEgLWYgIiRjYWNoZV9maWxlIiB8fCB0ZXN0IC1oICIkY2FjaGVfZmls
ZSI7IHRoZW4KKwljYXQgY29uZmNhY2hlID4iJGNhY2hlX2ZpbGUiCisgICAgICBlbHNlCisgICAg
ICAgIGNhc2UgJGNhY2hlX2ZpbGUgaW4gIygKKyAgICAgICAgKi8qIHwgPzoqKQorCSAgbXYgLWYg
Y29uZmNhY2hlICIkY2FjaGVfZmlsZSIkJCAmJgorCSAgbXYgLWYgIiRjYWNoZV9maWxlIiQkICIk
Y2FjaGVfZmlsZSIgOzsgIygKKyAgICAgICAgKikKKwkgIG12IC1mIGNvbmZjYWNoZSAiJGNhY2hl
X2ZpbGUiIDs7CisJZXNhYworICAgICAgZmkKKyAgICBmaQorICBlbHNlCisgICAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBub3QgdXBkYXRpbmcgdW53cml0YWJsZSBj
YWNoZSAkY2FjaGVfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBub3QgdXBkYXRpbmcgdW53
cml0YWJsZSBjYWNoZSAkY2FjaGVfZmlsZSIgPiY2O30KKyAgZmkKK2ZpCitybSAtZiBjb25mY2Fj
aGUKKwordGVzdCAieCRwcmVmaXgiID0geE5PTkUgJiYgcHJlZml4PSRhY19kZWZhdWx0X3ByZWZp
eAorIyBMZXQgbWFrZSBleHBhbmQgZXhlY19wcmVmaXguCit0ZXN0ICJ4JGV4ZWNfcHJlZml4IiA9
IHhOT05FICYmIGV4ZWNfcHJlZml4PScke3ByZWZpeH0nCisKK0RFRlM9LURIQVZFX0NPTkZJR19I
CisKK2FjX2xpYm9ianM9CithY19sdGxpYm9ianM9CitVPQorZm9yIGFjX2kgaW4gOiAkTElCT0JK
UzsgZG8gdGVzdCAieCRhY19pIiA9IHg6ICYmIGNvbnRpbnVlCisgICMgMS4gUmVtb3ZlIHRoZSBl
eHRlbnNpb24sIGFuZCAkVSBpZiBhbHJlYWR5IGluc3RhbGxlZC4KKyAgYWNfc2NyaXB0PSdzL1wk
VVwuLy4vO3MvXC5vJC8vO3MvXC5vYmokLy8nCisgIGFjX2k9YCRhc19lY2hvICIkYWNfaSIgfCBz
ZWQgIiRhY19zY3JpcHQiYAorICAjIDIuIFByZXBlbmQgTElCT0JKRElSLiAgV2hlbiB1c2VkIHdp
dGggYXV0b21ha2U+PTEuMTAgTElCT0JKRElSCisgICMgICAgd2lsbCBiZSBzZXQgdG8gdGhlIGRp
cmVjdG9yeSB3aGVyZSBMSUJPQkpTIG9iamVjdHMgYXJlIGJ1aWx0LgorICBhc19mbl9hcHBlbmQg
YWNfbGlib2JqcyAiIFwke0xJQk9CSkRJUn0kYWNfaVwkVS4kYWNfb2JqZXh0IgorICBhc19mbl9h
cHBlbmQgYWNfbHRsaWJvYmpzICIgXCR7TElCT0JKRElSfSRhY19pIickVS5sbycKK2RvbmUKK0xJ
Qk9CSlM9JGFjX2xpYm9ianMKKworTFRMSUJPQkpTPSRhY19sdGxpYm9ianMKKworCisKKzogIiR7
Q09ORklHX1NUQVRVUz0uL2NvbmZpZy5zdGF0dXN9IgorYWNfd3JpdGVfZmFpbD0wCithY19jbGVh
bl9maWxlc19zYXZlPSRhY19jbGVhbl9maWxlcworYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9m
aWxlcyAkQ09ORklHX1NUQVRVUyIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY3JlYXRpbmcgJENPTkZJR19TVEFUVVMiID4mNQorJGFzX2VjaG8gIiRhc19tZTogY3Jl
YXRpbmcgJENPTkZJR19TVEFUVVMiID4mNjt9Cithc193cml0ZV9mYWlsPTAKK2NhdCA+JENPTkZJ
R19TVEFUVVMgPDxfQVNFT0YgfHwgYXNfd3JpdGVfZmFpbD0xCisjISAkU0hFTEwKKyMgR2VuZXJh
dGVkIGJ5ICRhc19tZS4KKyMgUnVuIHRoaXMgZmlsZSB0byByZWNyZWF0ZSB0aGUgY3VycmVudCBj
b25maWd1cmF0aW9uLgorIyBDb21waWxlciBvdXRwdXQgcHJvZHVjZWQgYnkgY29uZmlndXJlLCB1
c2VmdWwgZm9yIGRlYnVnZ2luZworIyBjb25maWd1cmUsIGlzIGluIGNvbmZpZy5sb2cgaWYgaXQg
ZXhpc3RzLgorCitkZWJ1Zz1mYWxzZQorYWNfY3NfcmVjaGVjaz1mYWxzZQorYWNfY3Nfc2lsZW50
PWZhbHNlCisKK1NIRUxMPVwke0NPTkZJR19TSEVMTC0kU0hFTEx9CitleHBvcnQgU0hFTEwKK19B
U0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FTRU9GIHx8IGFzX3dyaXRlX2ZhaWw9MQor
IyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE00c2ggSW5pdGlhbGl6YXRpb24uICMjCisj
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIworCisjIEJlIG1vcmUgQm91cm5lIGNvbXBhdGlibGUK
K0RVQUxDQVNFPTE7IGV4cG9ydCBEVUFMQ0FTRSAjIGZvciBNS1Mgc2gKK2lmIHRlc3QgLW4gIiR7
WlNIX1ZFUlNJT04rc2V0fSIgJiYgKGVtdWxhdGUgc2gpID4vZGV2L251bGwgMj4mMTsgdGhlbiA6
CisgIGVtdWxhdGUgc2gKKyAgTlVMTENNRD06CisgICMgUHJlLTQuMiB2ZXJzaW9ucyBvZiBac2gg
ZG8gd29yZCBzcGxpdHRpbmcgb24gJHsxKyIkQCJ9LCB3aGljaAorICAjIGlzIGNvbnRyYXJ5IHRv
IG91ciB1c2FnZS4gIERpc2FibGUgdGhpcyBmZWF0dXJlLgorICBhbGlhcyAtZyAnJHsxKyIkQCJ9
Jz0nIiRAIicKKyAgc2V0b3B0IE5PX0dMT0JfU1VCU1QKK2Vsc2UKKyAgY2FzZSBgKHNldCAtbykg
Mj4vZGV2L251bGxgIGluICMoCisgICpwb3NpeCopIDoKKyAgICBzZXQgLW8gcG9zaXggOzsgIygK
KyAgKikgOgorICAgICA7OworZXNhYworZmkKKworCithc19ubD0nCisnCitleHBvcnQgYXNfbmwK
KyMgUHJpbnRpbmcgYSBsb25nIHN0cmluZyBjcmFzaGVzIFNvbGFyaXMgNyAvdXNyL2Jpbi9wcmlu
dGYuCithc19lY2hvPSdcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcJworYXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCith
c19lY2hvPSRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobwor
IyBQcmVmZXIgYSBrc2ggc2hlbGwgYnVpbHRpbiBvdmVyIGFuIGV4dGVybmFsIHByaW50ZiBwcm9n
cmFtIG9uIFNvbGFyaXMsCisjIGJ1dCB3aXRob3V0IHdhc3RpbmcgZm9ya3MgZm9yIGJhc2ggb3Ig
enNoLgoraWYgdGVzdCAteiAiJEJBU0hfVkVSU0lPTiRaU0hfVkVSU0lPTiIgXAorICAgICYmICh0
ZXN0ICJYYHByaW50IC1yIC0tICRhc19lY2hvYCIgPSAiWCRhc19lY2hvIikgMj4vZGV2L251bGw7
IHRoZW4KKyAgYXNfZWNobz0ncHJpbnQgLXIgLS0nCisgIGFzX2VjaG9fbj0ncHJpbnQgLXJuIC0t
JworZWxpZiAodGVzdCAiWGBwcmludGYgJXMgJGFzX2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9k
ZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmludGYgJXNcbicKKyAgYXNfZWNob19uPSdwcmlu
dGYgJXMnCitlbHNlCisgIGlmIHRlc3QgIlhgKC91c3IvdWNiL2VjaG8gLW4gLW4gJGFzX2VjaG8p
IDI+L2Rldi9udWxsYCIgPSAiWC1uICRhc19lY2hvIjsgdGhlbgorICAgIGFzX2VjaG9fYm9keT0n
ZXZhbCAvdXNyL3VjYi9lY2hvIC1uICIkMSRhc19ubCInCisgICAgYXNfZWNob19uPScvdXNyL3Vj
Yi9lY2hvIC1uJworICBlbHNlCisgICAgYXNfZWNob19ib2R5PSdldmFsIGV4cHIgIlgkMSIgOiAi
WFxcKC4qXFwpIicKKyAgICBhc19lY2hvX25fYm9keT0nZXZhbAorICAgICAgYXJnPSQxOworICAg
ICAgY2FzZSAkYXJnIGluICMoCisgICAgICAqIiRhc19ubCIqKQorCWV4cHIgIlgkYXJnIiA6ICJY
XFwoLipcXCkkYXNfbmwiOworCWFyZz1gZXhwciAiWCRhcmciIDogIi4qJGFzX25sXFwoLipcXCki
YDs7CisgICAgICBlc2FjOworICAgICAgZXhwciAiWCRhcmciIDogIlhcXCguKlxcKSIgfCB0ciAt
ZCAiJGFzX25sIgorICAgICcKKyAgICBleHBvcnQgYXNfZWNob19uX2JvZHkKKyAgICBhc19lY2hv
X249J3NoIC1jICRhc19lY2hvX25fYm9keSBhc19lY2hvJworICBmaQorICBleHBvcnQgYXNfZWNo
b19ib2R5CisgIGFzX2VjaG89J3NoIC1jICRhc19lY2hvX2JvZHkgYXNfZWNobycKK2ZpCisKKyMg
VGhlIHVzZXIgaXMgYWx3YXlzIHJpZ2h0LgoraWYgdGVzdCAiJHtQQVRIX1NFUEFSQVRPUitzZXR9
IiAhPSBzZXQ7IHRoZW4KKyAgUEFUSF9TRVBBUkFUT1I9OgorICAoUEFUSD0nL2JpbjsvYmluJzsg
RlBBVEg9JFBBVEg7IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSAmJiB7CisgICAgKFBBVEg9Jy9i
aW46L2Jpbic7IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rldi9udWxsIDI+JjEgfHwKKyAgICAg
IFBBVEhfU0VQQVJBVE9SPSc7JworICB9CitmaQorCisKKyMgSUZTCisjIFdlIG5lZWQgc3BhY2Us
IHRhYiBhbmQgbmV3IGxpbmUsIGluIHByZWNpc2VseSB0aGF0IG9yZGVyLiAgUXVvdGluZyBpcwor
IyB0aGVyZSB0byBwcmV2ZW50IGVkaXRvcnMgZnJvbSBjb21wbGFpbmluZyBhYm91dCBzcGFjZS10
YWIuCisjIChJZiBfQVNfUEFUSF9XQUxLIHdlcmUgY2FsbGVkIHdpdGggSUZTIHVuc2V0LCBpdCB3
b3VsZCBkaXNhYmxlIHdvcmQKKyMgc3BsaXR0aW5nIGJ5IHNldHRpbmcgSUZTIHRvIGVtcHR5IHZh
bHVlLikKK0lGUz0iICIiCSRhc19ubCIKKworIyBGaW5kIHdobyB3ZSBhcmUuICBMb29rIGluIHRo
ZSBwYXRoIGlmIHdlIGNvbnRhaW4gbm8gZGlyZWN0b3J5IHNlcGFyYXRvci4KK2FzX215c2VsZj0K
K2Nhc2UgJDAgaW4gIygoCisgICpbXFwvXSogKSBhc19teXNlbGY9JDAgOzsKKyAgKikgYXNfc2F2
ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8K
KyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAg
IHRlc3QgLXIgIiRhc19kaXIvJDAiICYmIGFzX215c2VsZj0kYXNfZGlyLyQwICYmIGJyZWFrCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICAgICA7OworZXNhYworIyBXZSBkaWQgbm90IGZp
bmQgb3Vyc2VsdmVzLCBtb3N0IHByb2JhYmx5IHdlIHdlcmUgcnVuIGFzIGBzaCBDT01NQU5EJwor
IyBpbiB3aGljaCBjYXNlIHdlIGFyZSBub3QgdG8gYmUgZm91bmQgaW4gdGhlIHBhdGguCitpZiB0
ZXN0ICJ4JGFzX215c2VsZiIgPSB4OyB0aGVuCisgIGFzX215c2VsZj0kMAorZmkKK2lmIHRlc3Qg
ISAtZiAiJGFzX215c2VsZiI7IHRoZW4KKyAgJGFzX2VjaG8gIiRhc19teXNlbGY6IGVycm9yOiBj
YW5ub3QgZmluZCBteXNlbGY7IHJlcnVuIHdpdGggYW4gYWJzb2x1dGUgZmlsZSBuYW1lIiA+JjIK
KyAgZXhpdCAxCitmaQorCisjIFVuc2V0IHZhcmlhYmxlcyB0aGF0IHdlIGRvIG5vdCBuZWVkIGFu
ZCB3aGljaCBjYXVzZSBidWdzIChlLmcuIGluCisjIHByZS0zLjAgVVdJTiBrc2gpLiAgQnV0IGRv
IG5vdCBjYXVzZSBidWdzIGluIGJhc2ggMi4wMTsgdGhlICJ8fCBleGl0IDEiCisjIHN1cHByZXNz
ZXMgYW55ICJTZWdtZW50YXRpb24gZmF1bHQiIG1lc3NhZ2UgdGhlcmUuICAnKCgnIGNvdWxkCisj
IHRyaWdnZXIgYSBidWcgaW4gcGRrc2ggNS4yLjE0LgorZm9yIGFzX3ZhciBpbiBCQVNIX0VOViBF
TlYgTUFJTCBNQUlMUEFUSAorZG8gZXZhbCB0ZXN0IHhcJHskYXNfdmFyK3NldH0gPSB4c2V0IFwK
KyAgJiYgKCAodW5zZXQgJGFzX3ZhcikgfHwgZXhpdCAxKSA+L2Rldi9udWxsIDI+JjEgJiYgdW5z
ZXQgJGFzX3ZhciB8fCA6Citkb25lCitQUzE9JyQgJworUFMyPSc+ICcKK1BTND0nKyAnCisKKyMg
TkxTIG51aXNhbmNlcy4KK0xDX0FMTD1DCitleHBvcnQgTENfQUxMCitMQU5HVUFHRT1DCitleHBv
cnQgTEFOR1VBR0UKKworIyBDRFBBVEguCisodW5zZXQgQ0RQQVRIKSA+L2Rldi9udWxsIDI+JjEg
JiYgdW5zZXQgQ0RQQVRICisKKworIyBhc19mbl9lcnJvciBTVEFUVVMgRVJST1IgW0xJTkVOTyBM
T0dfRkRdCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgT3V0
cHV0ICJgYmFzZW5hbWUgJDBgOiBlcnJvcjogRVJST1IiIHRvIHN0ZGVyci4gSWYgTElORU5PIGFu
ZCBMT0dfRkQgYXJlCisjIHByb3ZpZGVkLCBhbHNvIG91dHB1dCB0aGUgZXJyb3IgdG8gTE9HX0ZE
LCByZWZlcmVuY2luZyBMSU5FTk8uIFRoZW4gZXhpdCB0aGUKKyMgc2NyaXB0IHdpdGggU1RBVFVT
LCB1c2luZyAxIGlmIHRoYXQgd2FzIDAuCithc19mbl9lcnJvciAoKQoreworICBhc19zdGF0dXM9
JDE7IHRlc3QgJGFzX3N0YXR1cyAtZXEgMCAmJiBhc19zdGF0dXM9MQorICBpZiB0ZXN0ICIkNCI7
IHRoZW4KKyAgICBhc19saW5lbm89JHthc19saW5lbm8tIiQzIn0gYXNfbGluZW5vX3N0YWNrPWFz
X2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZXJyb3I6ICQyIiA+JiQ0CisgIGZpCisgICRhc19lY2hvICIkYXNf
bWU6IGVycm9yOiAkMiIgPiYyCisgIGFzX2ZuX2V4aXQgJGFzX3N0YXR1cworfSAjIGFzX2ZuX2Vy
cm9yCisKKworIyBhc19mbl9zZXRfc3RhdHVzIFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQorIyBTZXQgJD8gdG8gU1RBVFVTLCB3aXRob3V0IGZvcmtpbmcuCithc19mbl9zZXRfc3Rh
dHVzICgpCit7CisgIHJldHVybiAkMQorfSAjIGFzX2ZuX3NldF9zdGF0dXMKKworIyBhc19mbl9l
eGl0IFNUQVRVUworIyAtLS0tLS0tLS0tLS0tLS0tLQorIyBFeGl0IHRoZSBzaGVsbCB3aXRoIFNU
QVRVUywgZXZlbiBpbiBhICJ0cmFwIDAiIG9yICJzZXQgLWUiIGNvbnRleHQuCithc19mbl9leGl0
ICgpCit7CisgIHNldCArZQorICBhc19mbl9zZXRfc3RhdHVzICQxCisgIGV4aXQgJDEKK30gIyBh
c19mbl9leGl0CisKKyMgYXNfZm5fdW5zZXQgVkFSCisjIC0tLS0tLS0tLS0tLS0tLQorIyBQb3J0
YWJseSB1bnNldCBWQVIuCithc19mbl91bnNldCAoKQoreworICB7IGV2YWwgJDE9OyB1bnNldCAk
MTt9Cit9Cithc191bnNldD1hc19mbl91bnNldAorIyBhc19mbl9hcHBlbmQgVkFSIFZBTFVFCisj
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgQXBwZW5kIHRoZSB0ZXh0IGluIFZBTFVFIHRvIHRo
ZSBlbmQgb2YgdGhlIGRlZmluaXRpb24gY29udGFpbmVkIGluIFZBUi4gVGFrZQorIyBhZHZhbnRh
Z2Ugb2YgYW55IHNoZWxsIG9wdGltaXphdGlvbnMgdGhhdCBhbGxvdyBhbW9ydGl6ZWQgbGluZWFy
IGdyb3d0aCBvdmVyCisjIHJlcGVhdGVkIGFwcGVuZHMsIGluc3RlYWQgb2YgdGhlIHR5cGljYWwg
cXVhZHJhdGljIGdyb3d0aCBwcmVzZW50IGluIG5haXZlCisjIGltcGxlbWVudGF0aW9ucy4KK2lm
IChldmFsICJhc192YXI9MTsgYXNfdmFyKz0yOyB0ZXN0IHhcJGFzX3ZhciA9IHgxMiIpIDI+L2Rl
di9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXBwZW5kICgpCisgIHsKKyAgICBldmFsICQx
Kz1cJDIKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXBwZW5kICgpCisgIHsKKyAgICBldmFsICQxPVwk
JDFcJDIKKyAgfQorZmkgIyBhc19mbl9hcHBlbmQKKworIyBhc19mbl9hcml0aCBBUkcuLi4KKyMg
LS0tLS0tLS0tLS0tLS0tLS0tCisjIFBlcmZvcm0gYXJpdGhtZXRpYyBldmFsdWF0aW9uIG9uIHRo
ZSBBUkdzLCBhbmQgc3RvcmUgdGhlIHJlc3VsdCBpbiB0aGUKKyMgZ2xvYmFsICRhc192YWwuIFRh
a2UgYWR2YW50YWdlIG9mIHNoZWxscyB0aGF0IGNhbiBhdm9pZCBmb3Jrcy4gVGhlIGFyZ3VtZW50
cworIyBtdXN0IGJlIHBvcnRhYmxlIGFjcm9zcyAkKCgpKSBhbmQgZXhwci4KK2lmIChldmFsICJ0
ZXN0IFwkKCggMSArIDEgKSkgPSAyIikgMj4vZGV2L251bGw7IHRoZW4gOgorICBldmFsICdhc19m
bl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPSQoKCAkKiApKQorICB9JworZWxzZQorICBhc19m
bl9hcml0aCAoKQorICB7CisgICAgYXNfdmFsPWBleHByICIkQCIgfHwgdGVzdCAkPyAtZXEgMWAK
KyAgfQorZmkgIyBhc19mbl9hcml0aAorCisKK2lmIGV4cHIgYSA6ICdcKGFcKScgPi9kZXYvbnVs
bCAyPiYxICYmCisgICB0ZXN0ICJYYGV4cHIgMDAwMDEgOiAnLipcKC4uLlwpJ2AiID0gWDAwMTsg
dGhlbgorICBhc19leHByPWV4cHIKK2Vsc2UKKyAgYXNfZXhwcj1mYWxzZQorZmkKKworaWYgKGJh
c2VuYW1lIC0tIC8pID4vZGV2L251bGwgMj4mMSAmJiB0ZXN0ICJYYGJhc2VuYW1lIC0tIC8gMj4m
MWAiID0gIlgvIjsgdGhlbgorICBhc19iYXNlbmFtZT1iYXNlbmFtZQorZWxzZQorICBhc19iYXNl
bmFtZT1mYWxzZQorZmkKKworaWYgKGFzX2Rpcj1gZGlybmFtZSAtLSAvYCAmJiB0ZXN0ICJYJGFz
X2RpciIgPSBYLykgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgIGFzX2Rpcm5hbWU9ZGlybmFtZQor
ZWxzZQorICBhc19kaXJuYW1lPWZhbHNlCitmaQorCithc19tZT1gJGFzX2Jhc2VuYW1lIC0tICIk
MCIgfHwKKyRhc19leHByIFgvIiQwIiA6ICcuKi9cKFteL11bXi9dKlwpLyokJyBcfCBcCisJIFgi
JDAiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJDAiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVs
bCB8fAorJGFzX2VjaG8gWC8iJDAiIHwKKyAgICBzZWQgJy9eLipcL1woW14vXVteL10qXClcLyok
L3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwvXChcL1wvXCkkL3sKKwkgICAg
cy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwvXChcL1wpLioveworCSAgICBzLy9cMS8KKwkg
ICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisKKyMgQXZvaWQgZGVwZW5kaW5nIHVwb24gQ2hh
cmFjdGVyIFJhbmdlcy4KK2FzX2NyX2xldHRlcnM9J2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6
JworYXNfY3JfTEVUVEVSUz0nQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVonCithc19jcl9MZXR0
ZXJzPSRhc19jcl9sZXR0ZXJzJGFzX2NyX0xFVFRFUlMKK2FzX2NyX2RpZ2l0cz0nMDEyMzQ1Njc4
OScKK2FzX2NyX2FsbnVtPSRhc19jcl9MZXR0ZXJzJGFzX2NyX2RpZ2l0cworCitFQ0hPX0M9IEVD
SE9fTj0gRUNIT19UPQorY2FzZSBgZWNobyAtbiB4YCBpbiAjKCgoKCgKKy1uKikKKyAgY2FzZSBg
ZWNobyAneHlcYydgIGluCisgICpjKikgRUNIT19UPScJJzs7CSMgRUNIT19UIGlzIHNpbmdsZSB0
YWIgY2hhcmFjdGVyLgorICB4eSkgIEVDSE9fQz0nXGMnOzsKKyAgKikgICBlY2hvIGBlY2hvIGtz
aDg4IGJ1ZyBvbiBBSVggNi4xYCA+IC9kZXYvbnVsbAorICAgICAgIEVDSE9fVD0nCSc7OworICBl
c2FjOzsKKyopCisgIEVDSE9fTj0nLW4nOzsKK2VzYWMKKworcm0gLWYgY29uZiQkIGNvbmYkJC5l
eGUgY29uZiQkLmZpbGUKK2lmIHRlc3QgLWQgY29uZiQkLmRpcjsgdGhlbgorICBybSAtZiBjb25m
JCQuZGlyL2NvbmYkJC5maWxlCitlbHNlCisgIHJtIC1mIGNvbmYkJC5kaXIKKyAgbWtkaXIgY29u
ZiQkLmRpciAyPi9kZXYvbnVsbAorZmkKK2lmIChlY2hvID5jb25mJCQuZmlsZSkgMj4vZGV2L251
bGw7IHRoZW4KKyAgaWYgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVu
CisgICAgYXNfbG5fcz0nbG4gLXMnCisgICAgIyAuLi4gYnV0IHRoZXJlIGFyZSB0d28gZ290Y2hh
czoKKyAgICAjIDEpIE9uIE1TWVMsIGJvdGggYGxuIC1zIGZpbGUgZGlyJyBhbmQgYGxuIGZpbGUg
ZGlyJyBmYWlsLgorICAgICMgMikgREpHUFAgPCAyLjA0IGhhcyBubyBzeW1saW5rczsgYGxuIC1z
JyBjcmVhdGVzIGEgd3JhcHBlciBleGVjdXRhYmxlLgorICAgICMgSW4gYm90aCBjYXNlcywgd2Ug
aGF2ZSB0byBkZWZhdWx0IHRvIGBjcCAtcCcuCisgICAgbG4gLXMgY29uZiQkLmZpbGUgY29uZiQk
LmRpciAyPi9kZXYvbnVsbCAmJiB0ZXN0ICEgLWYgY29uZiQkLmV4ZSB8fAorICAgICAgYXNfbG5f
cz0nY3AgLXAnCisgIGVsaWYgbG4gY29uZiQkLmZpbGUgY29uZiQkIDI+L2Rldi9udWxsOyB0aGVu
CisgICAgYXNfbG5fcz1sbgorICBlbHNlCisgICAgYXNfbG5fcz0nY3AgLXAnCisgIGZpCitlbHNl
CisgIGFzX2xuX3M9J2NwIC1wJworZmkKK3JtIC1mIGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5k
aXIvY29uZiQkLmZpbGUgY29uZiQkLmZpbGUKK3JtZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwK
KworCisjIGFzX2ZuX21rZGlyX3AKKyMgLS0tLS0tLS0tLS0tLQorIyBDcmVhdGUgIiRhc19kaXIi
IGFzIGEgZGlyZWN0b3J5LCBpbmNsdWRpbmcgcGFyZW50cyBpZiBuZWNlc3NhcnkuCithc19mbl9t
a2Rpcl9wICgpCit7CisKKyAgY2FzZSAkYXNfZGlyIGluICMoCisgIC0qKSBhc19kaXI9Li8kYXNf
ZGlyOzsKKyAgZXNhYworICB0ZXN0IC1kICIkYXNfZGlyIiB8fCBldmFsICRhc19ta2Rpcl9wIHx8
IHsKKyAgICBhc19kaXJzPQorICAgIHdoaWxlIDo7IGRvCisgICAgICBjYXNlICRhc19kaXIgaW4g
IygKKyAgICAgICpcJyopIGFzX3FkaXI9YCRhc19lY2hvICIkYXNfZGlyIiB8IHNlZCAicy8nLydc
XFxcXFxcXCcnL2ciYDs7ICMnKAorICAgICAgKikgYXNfcWRpcj0kYXNfZGlyOzsKKyAgICAgIGVz
YWMKKyAgICAgIGFzX2RpcnM9IickYXNfcWRpcicgJGFzX2RpcnMiCisgICAgICBhc19kaXI9YCRh
c19kaXJuYW1lIC0tICIkYXNfZGlyIiB8fAorJGFzX2V4cHIgWCIkYXNfZGlyIiA6ICdYXCguKlte
L11cKS8vKlteL11bXi9dKi8qJCcgXHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXClbXi9dJyBc
fCBcCisJIFgiJGFzX2RpciIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgv
XCknIFx8IC4gMj4vZGV2L251bGwgfHwKKyRhc19lY2hvIFgiJGFzX2RpciIgfAorICAgIHNlZCAn
L15YXCguKlteL11cKVwvXC8qW14vXVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJ
ICB9CisJICAvXlhcKFwvXC9cKVteL10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJ
ICAvXlhcKFwvXC9cKSQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wp
LioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgICAgICB0
ZXN0IC1kICIkYXNfZGlyIiAmJiBicmVhaworICAgIGRvbmUKKyAgICB0ZXN0IC16ICIkYXNfZGly
cyIgfHwgZXZhbCAibWtkaXIgJGFzX2RpcnMiCisgIH0gfHwgdGVzdCAtZCAiJGFzX2RpciIgfHwg
YXNfZm5fZXJyb3IgJD8gImNhbm5vdCBjcmVhdGUgZGlyZWN0b3J5ICRhc19kaXIiCisKKworfSAj
IGFzX2ZuX21rZGlyX3AKK2lmIG1rZGlyIC1wIC4gMj4vZGV2L251bGw7IHRoZW4KKyAgYXNfbWtk
aXJfcD0nbWtkaXIgLXAgIiRhc19kaXIiJworZWxzZQorICB0ZXN0IC1kIC4vLXAgJiYgcm1kaXIg
Li8tcAorICBhc19ta2Rpcl9wPWZhbHNlCitmaQorCitpZiB0ZXN0IC14IC8gPi9kZXYvbnVsbCAy
PiYxOyB0aGVuCisgIGFzX3Rlc3RfeD0ndGVzdCAteCcKK2Vsc2UKKyAgaWYgbHMgLWRMIC8gPi9k
ZXYvbnVsbCAyPiYxOyB0aGVuCisgICAgYXNfbHNfTF9vcHRpb249TAorICBlbHNlCisgICAgYXNf
bHNfTF9vcHRpb249CisgIGZpCisgIGFzX3Rlc3RfeD0nCisgICAgZXZhbCBzaCAtYyAnXCcnCisg
ICAgICBpZiB0ZXN0IC1kICIkMSI7IHRoZW4KKwl0ZXN0IC1kICIkMS8uIjsKKyAgICAgIGVsc2UK
KwljYXNlICQxIGluICMoCisJLSopc2V0ICIuLyQxIjs7CisJZXNhYzsKKwljYXNlIGBscyAtbGQn
JGFzX2xzX0xfb3B0aW9uJyAiJDEiIDI+L2Rldi9udWxsYCBpbiAjKCgKKwk/Pz9bc3hdKik6Ozsq
KWZhbHNlOztlc2FjO2ZpCisgICAgJ1wnJyBzaAorICAnCitmaQorYXNfZXhlY3V0YWJsZV9wPSRh
c190ZXN0X3gKKworIyBTZWQgZXhwcmVzc2lvbiB0byBtYXAgYSBzdHJpbmcgb250byBhIHZhbGlk
IENQUCBuYW1lLgorYXNfdHJfY3BwPSJldmFsIHNlZCAneSUqJGFzX2NyX2xldHRlcnMlUCRhc19j
cl9MRVRURVJTJTtzJVteXyRhc19jcl9hbG51bV0lXyVnJyIKKworIyBTZWQgZXhwcmVzc2lvbiB0
byBtYXAgYSBzdHJpbmcgb250byBhIHZhbGlkIHZhcmlhYmxlIG5hbWUuCithc190cl9zaD0iZXZh
bCBzZWQgJ3klKislcHAlO3MlW15fJGFzX2NyX2FsbnVtXSVfJWcnIgorCisKK2V4ZWMgNj4mMQor
IyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE1haW4gYm9keSBv
ZiAkQ09ORklHX1NUQVRVUyBzY3JpcHQuICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSAjIworX0FTRU9GCit0ZXN0ICRhc193cml0ZV9mYWlsID0gMCAmJiBjaG1vZCAr
eCAkQ09ORklHX1NUQVRVUyB8fCBhY193cml0ZV9mYWlsPTEKKworY2F0ID4+JENPTkZJR19TVEFU
VVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBTYXZlIHRoZSBsb2cgbWVzc2FnZSwg
dG8ga2VlcCAkMCBhbmQgc28gb24gbWVhbmluZ2Z1bCwgYW5kIHRvCisjIHJlcG9ydCBhY3R1YWwg
aW5wdXQgdmFsdWVzIG9mIENPTkZJR19GSUxFUyBldGMuIGluc3RlYWQgb2YgdGhlaXIKKyMgdmFs
dWVzIGFmdGVyIG9wdGlvbnMgaGFuZGxpbmcuCithY19sb2c9IgorVGhpcyBmaWxlIHdhcyBleHRl
bmRlZCBieSBYZW4gSHlwZXJ2aXNvciAkYXNfbWUgNC4yLCB3aGljaCB3YXMKK2dlbmVyYXRlZCBi
eSBHTlUgQXV0b2NvbmYgMi42OC4gIEludm9jYXRpb24gY29tbWFuZCBsaW5lIHdhcworCisgIENP
TkZJR19GSUxFUyAgICA9ICRDT05GSUdfRklMRVMKKyAgQ09ORklHX0hFQURFUlMgID0gJENPTkZJ
R19IRUFERVJTCisgIENPTkZJR19MSU5LUyAgICA9ICRDT05GSUdfTElOS1MKKyAgQ09ORklHX0NP
TU1BTkRTID0gJENPTkZJR19DT01NQU5EUworICAkICQwICRACisKK29uIGAoaG9zdG5hbWUgfHwg
dW5hbWUgLW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAorIgorCitfQUNFT0YKKworY2FzZSAkYWNf
Y29uZmlnX2ZpbGVzIGluICoiCisiKikgc2V0IHggJGFjX2NvbmZpZ19maWxlczsgc2hpZnQ7IGFj
X2NvbmZpZ19maWxlcz0kKjs7Citlc2FjCisKK2Nhc2UgJGFjX2NvbmZpZ19oZWFkZXJzIGluICoi
CisiKikgc2V0IHggJGFjX2NvbmZpZ19oZWFkZXJzOyBzaGlmdDsgYWNfY29uZmlnX2hlYWRlcnM9
JCo7OworZXNhYworCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRl
X2ZhaWw9MQorIyBGaWxlcyB0aGF0IGNvbmZpZy5zdGF0dXMgd2FzIG1hZGUgZm9yLgorY29uZmln
X2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIgorY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVh
ZGVycyIKKworX0FDRU9GCisKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193
cml0ZV9mYWlsPTEKK2FjX2NzX3VzYWdlPSJcCitcYCRhc19tZScgaW5zdGFudGlhdGVzIGZpbGVz
IGFuZCBvdGhlciBjb25maWd1cmF0aW9uIGFjdGlvbnMKK2Zyb20gdGVtcGxhdGVzIGFjY29yZGlu
ZyB0byB0aGUgY3VycmVudCBjb25maWd1cmF0aW9uLiAgVW5sZXNzIHRoZSBmaWxlcworYW5kIGFj
dGlvbnMgYXJlIHNwZWNpZmllZCBhcyBUQUdzLCBhbGwgYXJlIGluc3RhbnRpYXRlZCBieSBkZWZh
dWx0LgorCitVc2FnZTogJDAgW09QVElPTl0uLi4gW1RBR10uLi4KKworICAtaCwgLS1oZWxwICAg
ICAgIHByaW50IHRoaXMgaGVscCwgdGhlbiBleGl0CisgIC1WLCAtLXZlcnNpb24gICAgcHJpbnQg
dmVyc2lvbiBudW1iZXIgYW5kIGNvbmZpZ3VyYXRpb24gc2V0dGluZ3MsIHRoZW4gZXhpdAorICAg
ICAgLS1jb25maWcgICAgIHByaW50IGNvbmZpZ3VyYXRpb24sIHRoZW4gZXhpdAorICAtcSwgLS1x
dWlldCwgLS1zaWxlbnQKKyAgICAgICAgICAgICAgICAgICBkbyBub3QgcHJpbnQgcHJvZ3Jlc3Mg
bWVzc2FnZXMKKyAgLWQsIC0tZGVidWcgICAgICBkb24ndCByZW1vdmUgdGVtcG9yYXJ5IGZpbGVz
CisgICAgICAtLXJlY2hlY2sgICAgdXBkYXRlICRhc19tZSBieSByZWNvbmZpZ3VyaW5nIGluIHRo
ZSBzYW1lIGNvbmRpdGlvbnMKKyAgICAgIC0tZmlsZT1GSUxFWzpURU1QTEFURV0KKyAgICAgICAg
ICAgICAgICAgICBpbnN0YW50aWF0ZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlIEZJTEUKKyAgICAg
IC0taGVhZGVyPUZJTEVbOlRFTVBMQVRFXQorICAgICAgICAgICAgICAgICAgIGluc3RhbnRpYXRl
IHRoZSBjb25maWd1cmF0aW9uIGhlYWRlciBGSUxFCisKK0NvbmZpZ3VyYXRpb24gZmlsZXM6Cisk
Y29uZmlnX2ZpbGVzCisKK0NvbmZpZ3VyYXRpb24gaGVhZGVyczoKKyRjb25maWdfaGVhZGVycwor
CitSZXBvcnQgYnVncyB0byA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20+LiIKKworX0FD
RU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2Fj
X2NzX2NvbmZpZz0iYCRhc19lY2hvICIkYWNfY29uZmlndXJlX2FyZ3MiIHwgc2VkICdzL14gLy87
IHMvW1xcIiJcYFwkXS9cXFxcJi9nJ2AiCithY19jc192ZXJzaW9uPSJcXAorWGVuIEh5cGVydmlz
b3IgY29uZmlnLnN0YXR1cyA0LjIKK2NvbmZpZ3VyZWQgYnkgJDAsIGdlbmVyYXRlZCBieSBHTlUg
QXV0b2NvbmYgMi42OCwKKyAgd2l0aCBvcHRpb25zIFxcIlwkYWNfY3NfY29uZmlnXFwiCisKK0Nv
cHlyaWdodCAoQykgMjAxMCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KK1RoaXMgY29u
ZmlnLnN0YXR1cyBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbgorZ2l2ZXMgdW5saW1pdGVkIHBlcm1pc3Npb24gdG8gY29weSwgZGlzdHJpYnV0ZSBh
bmQgbW9kaWZ5IGl0LiIKKworYWNfcHdkPSckYWNfcHdkJworc3JjZGlyPSckc3JjZGlyJworSU5T
VEFMTD0nJElOU1RBTEwnCit0ZXN0IC1uICJcJEFXSyIgfHwgQVdLPWF3aworX0FDRU9GCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyMgVGhlIGRl
ZmF1bHQgbGlzdHMgYXBwbHkgaWYgdGhlIHVzZXIgZG9lcyBub3Qgc3BlY2lmeSBhbnkgZmlsZS4K
K2FjX25lZWRfZGVmYXVsdHM9Ogord2hpbGUgdGVzdCAkIyAhPSAwCitkbworICBjYXNlICQxIGlu
CisgIC0tKj0/KikKKyAgICBhY19vcHRpb249YGV4cHIgIlgkMSIgOiAnWFwoW149XSpcKT0nYAor
ICAgIGFjX29wdGFyZz1gZXhwciAiWCQxIiA6ICdYW149XSo9XCguKlwpJ2AKKyAgICBhY19zaGlm
dD06CisgICAgOzsKKyAgLS0qPSkKKyAgICBhY19vcHRpb249YGV4cHIgIlgkMSIgOiAnWFwoW149
XSpcKT0nYAorICAgIGFjX29wdGFyZz0KKyAgICBhY19zaGlmdD06CisgICAgOzsKKyAgKikKKyAg
ICBhY19vcHRpb249JDEKKyAgICBhY19vcHRhcmc9JDIKKyAgICBhY19zaGlmdD1zaGlmdAorICAg
IDs7CisgIGVzYWMKKworICBjYXNlICRhY19vcHRpb24gaW4KKyAgIyBIYW5kbGluZyBvZiB0aGUg
b3B0aW9ucy4KKyAgLXJlY2hlY2sgfCAtLXJlY2hlY2sgfCAtLXJlY2hlYyB8IC0tcmVjaGUgfCAt
LXJlY2ggfCAtLXJlYyB8IC0tcmUgfCAtLXIpCisgICAgYWNfY3NfcmVjaGVjaz06IDs7CisgIC0t
dmVyc2lvbiB8IC0tdmVyc2lvIHwgLS12ZXJzaSB8IC0tdmVycyB8IC0tdmVyIHwgLS12ZSB8IC0t
diB8IC1WICkKKyAgICAkYXNfZWNobyAiJGFjX2NzX3ZlcnNpb24iOyBleGl0IDs7CisgIC0tY29u
ZmlnIHwgLS1jb25maSB8IC0tY29uZiB8IC0tY29uIHwgLS1jbyB8IC0tYyApCisgICAgJGFzX2Vj
aG8gIiRhY19jc19jb25maWciOyBleGl0IDs7CisgIC0tZGVidWcgfCAtLWRlYnUgfCAtLWRlYiB8
IC0tZGUgfCAtLWQgfCAtZCApCisgICAgZGVidWc9OiA7OworICAtLWZpbGUgfCAtLWZpbCB8IC0t
ZmkgfCAtLWYgKQorICAgICRhY19zaGlmdAorICAgIGNhc2UgJGFjX29wdGFyZyBpbgorICAgICpc
JyopIGFjX29wdGFyZz1gJGFzX2VjaG8gIiRhY19vcHRhcmciIHwgc2VkICJzLycvJ1xcXFxcXFxc
JycvZyJgIDs7CisgICAgJycpIGFzX2ZuX2Vycm9yICQ/ICJtaXNzaW5nIGZpbGUgYXJndW1lbnQi
IDs7CisgICAgZXNhYworICAgIGFzX2ZuX2FwcGVuZCBDT05GSUdfRklMRVMgIiAnJGFjX29wdGFy
ZyciCisgICAgYWNfbmVlZF9kZWZhdWx0cz1mYWxzZTs7CisgIC0taGVhZGVyIHwgLS1oZWFkZSB8
IC0taGVhZCB8IC0taGVhICkKKyAgICAkYWNfc2hpZnQKKyAgICBjYXNlICRhY19vcHRhcmcgaW4K
KyAgICAqXCcqKSBhY19vcHRhcmc9YCRhc19lY2hvICIkYWNfb3B0YXJnIiB8IHNlZCAicy8nLydc
XFxcXFxcXCcnL2ciYCA7OworICAgIGVzYWMKKyAgICBhc19mbl9hcHBlbmQgQ09ORklHX0hFQURF
UlMgIiAnJGFjX29wdGFyZyciCisgICAgYWNfbmVlZF9kZWZhdWx0cz1mYWxzZTs7CisgIC0taGUg
fCAtLWgpCisgICAgIyBDb25mbGljdCBiZXR3ZWVuIC0taGVscCBhbmQgLS1oZWFkZXIKKyAgICBh
c19mbl9lcnJvciAkPyAiYW1iaWd1b3VzIG9wdGlvbjogXGAkMScKK1RyeSBcYCQwIC0taGVscCcg
Zm9yIG1vcmUgaW5mb3JtYXRpb24uIjs7CisgIC0taGVscCB8IC0taGVsIHwgLWggKQorICAgICRh
c19lY2hvICIkYWNfY3NfdXNhZ2UiOyBleGl0IDs7CisgIC1xIHwgLXF1aWV0IHwgLS1xdWlldCB8
IC0tcXVpZSB8IC0tcXVpIHwgLS1xdSB8IC0tcSBcCisgIHwgLXNpbGVudCB8IC0tc2lsZW50IHwg
LS1zaWxlbiB8IC0tc2lsZSB8IC0tc2lsIHwgLS1zaSB8IC0tcykKKyAgICBhY19jc19zaWxlbnQ9
OiA7OworCisgICMgVGhpcyBpcyBhbiBlcnJvci4KKyAgLSopIGFzX2ZuX2Vycm9yICQ/ICJ1bnJl
Y29nbml6ZWQgb3B0aW9uOiBcYCQxJworVHJ5IFxgJDAgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1h
dGlvbi4iIDs7CisKKyAgKikgYXNfZm5fYXBwZW5kIGFjX2NvbmZpZ190YXJnZXRzICIgJDEiCisg
ICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2UgOzsKKworICBlc2FjCisgIHNoaWZ0Citkb25lCisK
K2FjX2NvbmZpZ3VyZV9leHRyYV9hcmdzPQorCitpZiAkYWNfY3Nfc2lsZW50OyB0aGVuCisgIGV4
ZWMgNj4vZGV2L251bGwKKyAgYWNfY29uZmlndXJlX2V4dHJhX2FyZ3M9IiRhY19jb25maWd1cmVf
ZXh0cmFfYXJncyAtLXNpbGVudCIKK2ZpCisKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMg
PDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitpZiBcJGFjX2NzX3JlY2hlY2s7IHRoZW4KKyAg
c2V0IFggJyRTSEVMTCcgJyQwJyAkYWNfY29uZmlndXJlX2FyZ3MgXCRhY19jb25maWd1cmVfZXh0
cmFfYXJncyAtLW5vLWNyZWF0ZSAtLW5vLXJlY3Vyc2lvbgorICBzaGlmdAorICBcJGFzX2VjaG8g
InJ1bm5pbmcgQ09ORklHX1NIRUxMPSRTSEVMTCBcJCoiID4mNgorICBDT05GSUdfU0hFTEw9JyRT
SEVMTCcKKyAgZXhwb3J0IENPTkZJR19TSEVMTAorICBleGVjICJcJEAiCitmaQorCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2V4ZWMg
NT4+Y29uZmlnLmxvZworeworICBlY2hvCisgIHNlZCAnaDtzLy4vLS9nO3MvXi4uLi8jIyAvO3Mv
Li4uJC8gIyMvO3A7eDtwO3gnIDw8X0FTQk9YCisjIyBSdW5uaW5nICRhc19tZS4gIyMKK19BU0JP
WAorICAkYXNfZWNobyAiJGFjX2xvZyIKK30gPiY1CisKK19BQ0VPRgorY2F0ID4+JENPTkZJR19T
VEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitfQUNFT0YKKworY2F0ID4+JENPTkZJ
R19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorCisjIEhhbmRsaW5nIG9mIGFy
Z3VtZW50cy4KK2ZvciBhY19jb25maWdfdGFyZ2V0IGluICRhY19jb25maWdfdGFyZ2V0cworZG8K
KyAgY2FzZSAkYWNfY29uZmlnX3RhcmdldCBpbgorICAgICIuLi9jb25maWcvVG9vbHMubWsiKSBD
T05GSUdfRklMRVM9IiRDT05GSUdfRklMRVMgLi4vY29uZmlnL1Rvb2xzLm1rIiA7OworICAgICJj
b25maWcuaCIpIENPTkZJR19IRUFERVJTPSIkQ09ORklHX0hFQURFUlMgY29uZmlnLmgiIDs7CisK
KyAgKikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgYXJndW1lbnQ6IFxgJGFjX2NvbmZpZ190YXJn
ZXQnIiAiJExJTkVOTyIgNTs7CisgIGVzYWMKK2RvbmUKKworCisjIElmIHRoZSB1c2VyIGRpZCBu
b3QgdXNlIHRoZSBhcmd1bWVudHMgdG8gc3BlY2lmeSB0aGUgaXRlbXMgdG8gaW5zdGFudGlhdGUs
CisjIHRoZW4gdGhlIGVudnZhciBpbnRlcmZhY2UgaXMgdXNlZC4gIFNldCBvbmx5IHRob3NlIHRo
YXQgYXJlIG5vdC4KKyMgV2UgdXNlIHRoZSBsb25nIGZvcm0gZm9yIHRoZSBkZWZhdWx0IGFzc2ln
bm1lbnQgYmVjYXVzZSBvZiBhbiBleHRyZW1lbHkKKyMgYml6YXJyZSBidWcgb24gU3VuT1MgNC4x
LjMuCitpZiAkYWNfbmVlZF9kZWZhdWx0czsgdGhlbgorICB0ZXN0ICIke0NPTkZJR19GSUxFUytz
ZXR9IiA9IHNldCB8fCBDT05GSUdfRklMRVM9JGNvbmZpZ19maWxlcworICB0ZXN0ICIke0NPTkZJ
R19IRUFERVJTK3NldH0iID0gc2V0IHx8IENPTkZJR19IRUFERVJTPSRjb25maWdfaGVhZGVycwor
ZmkKKworIyBIYXZlIGEgdGVtcG9yYXJ5IGRpcmVjdG9yeSBmb3IgY29udmVuaWVuY2UuICBNYWtl
IGl0IGluIHRoZSBidWlsZCB0cmVlCisjIHNpbXBseSBiZWNhdXNlIHRoZXJlIGlzIG5vIHJlYXNv
biBhZ2FpbnN0IGhhdmluZyBpdCBoZXJlLCBhbmQgaW4gYWRkaXRpb24sCisjIGNyZWF0aW5nIGFu
ZCBtb3ZpbmcgZmlsZXMgZnJvbSAvdG1wIGNhbiBzb21ldGltZXMgY2F1c2UgcHJvYmxlbXMuCisj
IEhvb2sgZm9yIGl0cyByZW1vdmFsIHVubGVzcyBkZWJ1Z2dpbmcuCisjIE5vdGUgdGhhdCB0aGVy
ZSBpcyBhIHNtYWxsIHdpbmRvdyBpbiB3aGljaCB0aGUgZGlyZWN0b3J5IHdpbGwgbm90IGJlIGNs
ZWFuZWQ6CisjIGFmdGVyIGl0cyBjcmVhdGlvbiBidXQgYmVmb3JlIGl0cyBuYW1lIGhhcyBiZWVu
IGFzc2lnbmVkIHRvIGAkdG1wJy4KKyRkZWJ1ZyB8fAoreworICB0bXA9IGFjX3RtcD0KKyAgdHJh
cCAnZXhpdF9zdGF0dXM9JD8KKyAgOiAiJHthY190bXA6PSR0bXB9IgorICB7IHRlc3QgISAtZCAi
JGFjX3RtcCIgfHwgcm0gLWZyICIkYWNfdG1wIjsgfSAmJiBleGl0ICRleGl0X3N0YXR1cworJyAw
CisgIHRyYXAgJ2FzX2ZuX2V4aXQgMScgMSAyIDEzIDE1Cit9CisjIENyZWF0ZSBhIChzZWN1cmUp
IHRtcCBkaXJlY3RvcnkgZm9yIHRtcCBmaWxlcy4KKworeworICB0bXA9YCh1bWFzayAwNzcgJiYg
bWt0ZW1wIC1kICIuL2NvbmZYWFhYWFgiKSAyPi9kZXYvbnVsbGAgJiYKKyAgdGVzdCAtZCAiJHRt
cCIKK30gIHx8Cit7CisgIHRtcD0uL2NvbmYkJC0kUkFORE9NCisgICh1bWFzayAwNzcgJiYgbWtk
aXIgIiR0bXAiKQorfSB8fCBhc19mbl9lcnJvciAkPyAiY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFy
eSBkaXJlY3RvcnkgaW4gLiIgIiRMSU5FTk8iIDUKK2FjX3RtcD0kdG1wCisKKyMgU2V0IHVwIHRo
ZSBzY3JpcHRzIGZvciBDT05GSUdfRklMRVMgc2VjdGlvbi4KKyMgTm8gbmVlZCB0byBnZW5lcmF0
ZSB0aGVtIGlmIHRoZXJlIGFyZSBubyBDT05GSUdfRklMRVMuCisjIFRoaXMgaGFwcGVucyBmb3Ig
aW5zdGFuY2Ugd2l0aCBgLi9jb25maWcuc3RhdHVzIGNvbmZpZy5oJy4KK2lmIHRlc3QgLW4gIiRD
T05GSUdfRklMRVMiOyB0aGVuCisKKworYWNfY3I9YGVjaG8gWCB8IHRyIFggJ1wwMTUnYAorIyBP
biBjeWd3aW4sIGJhc2ggY2FuIGVhdCBcciBpbnNpZGUgYGAgaWYgdGhlIHVzZXIgcmVxdWVzdGVk
IGlnbmNyLgorIyBCdXQgd2Uga25vdyBvZiBubyBvdGhlciBzaGVsbCB3aGVyZSBhY19jciB3b3Vs
ZCBiZSBlbXB0eSBhdCB0aGlzCisjIHBvaW50LCBzbyB3ZSBjYW4gdXNlIGEgYmFzaGlzbSBhcyBh
IGZhbGxiYWNrLgoraWYgdGVzdCAieCRhY19jciIgPSB4OyB0aGVuCisgIGV2YWwgYWNfY3I9XCRc
J1xcclwnCitmaQorYWNfY3NfYXdrX2NyPWAkQVdLICdCRUdJTiB7IHByaW50ICJhXHJiIiB9JyA8
L2Rldi9udWxsIDI+L2Rldi9udWxsYAoraWYgdGVzdCAiJGFjX2NzX2F3a19jciIgPSAiYSR7YWNf
Y3J9YiI7IHRoZW4KKyAgYWNfY3NfYXdrX2NyPSdcXHInCitlbHNlCisgIGFjX2NzX2F3a19jcj0k
YWNfY3IKK2ZpCisKK2VjaG8gJ0JFR0lOIHsnID4iJGFjX3RtcC9zdWJzMS5hd2siICYmCitfQUNF
T0YKKworCit7CisgIGVjaG8gImNhdCA+Y29uZiQkc3Vicy5hd2sgPDxfQUNFT0YiICYmCisgIGVj
aG8gIiRhY19zdWJzdF92YXJzIiB8IHNlZCAncy8uKi8mISQmJGFjX2RlbGltLycgJiYKKyAgZWNo
byAiX0FDRU9GIgorfSA+Y29uZiQkc3Vicy5zaCB8fAorICBhc19mbl9lcnJvciAkPyAiY291bGQg
bm90IG1ha2UgJENPTkZJR19TVEFUVVMiICIkTElORU5PIiA1CithY19kZWxpbV9udW09YGVjaG8g
IiRhY19zdWJzdF92YXJzIiB8IGdyZXAgLWMgJ14nYAorYWNfZGVsaW09JyUhXyEjICcKK2ZvciBh
Y19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSBmYWxzZSA6OyBkbworICAuIC4v
Y29uZiQkc3Vicy5zaCB8fAorICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFrZSAkQ09O
RklHX1NUQVRVUyIgIiRMSU5FTk8iIDUKKworICBhY19kZWxpbV9uPWBzZWQgLW4gInMvLiokYWNf
ZGVsaW1cJC9YL3AiIGNvbmYkJHN1YnMuYXdrIHwgZ3JlcCAtYyBYYAorICBpZiB0ZXN0ICRhY19k
ZWxpbV9uID0gJGFjX2RlbGltX251bTsgdGhlbgorICAgIGJyZWFrCisgIGVsaWYgJGFjX2xhc3Rf
dHJ5OyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBtYWtlICRDT05GSUdfU1RB
VFVTIiAiJExJTkVOTyIgNQorICBlbHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEkYWNfZGVs
aW0gXyRhY19kZWxpbSEhICIKKyAgZmkKK2RvbmUKK3JtIC1mIGNvbmYkJHN1YnMuc2gKKworY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitjYXQgPj4iXCRh
Y190bXAvc3ViczEuYXdrIiA8PFxcX0FDQVdLICYmCitfQUNFT0YKK3NlZCAtbiAnCitoCitzL14v
U1siLzsgcy8hLiovIl09LworcAorZworcy9eW14hXSohLy8KKzpyZXBsCit0IHJlcGwKK3MvJyIk
YWNfZGVsaW0iJyQvLwordCBkZWxpbQorOm5sCitoCitzL1woLlx7MTQ4XH1cKS4uKi9cMS8KK3Qg
bW9yZTEKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kL1xcbiJcXC8KK3AKK24KK2IgcmVwbAor
Om1vcmUxCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0OFx9
Ly8KK3QgbmwKKzpkZWxpbQoraAorcy9cKC5cezE0OFx9XCkuLiovXDEvCit0IG1vcmUyCitzL1si
XFxdL1xcJi9nOyBzL14vIi87IHMvJC8iLworcAorYgorOm1vcmUyCitzL1siXFxdL1xcJi9nOyBz
L14vIi87IHMvJC8iXFwvCitwCitnCitzLy5cezE0OFx9Ly8KK3QgZGVsaW0KKycgPGNvbmYkJHN1
YnMuYXdrIHwgc2VkICcKKy9eW14iIl0veworICBOCisgIHMvXG4vLworfQorJyA+PiRDT05GSUdf
U1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorcm0gLWYgY29uZiQkc3Vicy5hd2sKK2NhdCA+PiRD
T05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorX0FDQVdLCitjYXQgPj4i
XCRhY190bXAvc3ViczEuYXdrIiA8PF9BQ0FXSyAmJgorICBmb3IgKGtleSBpbiBTKSBTX2lzX3Nl
dFtrZXldID0gMQorICBGUyA9ICIHIgorCit9Cit7CisgIGxpbmUgPSAkIDAKKyAgbmZpZWxkcyA9
IHNwbGl0KGxpbmUsIGZpZWxkLCAiQCIpCisgIHN1YnN0ZWQgPSAwCisgIGxlbiA9IGxlbmd0aChm
aWVsZFsxXSkKKyAgZm9yIChpID0gMjsgaSA8IG5maWVsZHM7IGkrKykgeworICAgIGtleSA9IGZp
ZWxkW2ldCisgICAga2V5bGVuID0gbGVuZ3RoKGtleSkKKyAgICBpZiAoU19pc19zZXRba2V5XSkg
eworICAgICAgdmFsdWUgPSBTW2tleV0KKyAgICAgIGxpbmUgPSBzdWJzdHIobGluZSwgMSwgbGVu
KSAiIiB2YWx1ZSAiIiBzdWJzdHIobGluZSwgbGVuICsga2V5bGVuICsgMykKKyAgICAgIGxlbiAr
PSBsZW5ndGgodmFsdWUpICsgbGVuZ3RoKGZpZWxkWysraV0pCisgICAgICBzdWJzdGVkID0gMQor
ICAgIH0gZWxzZQorICAgICAgbGVuICs9IDEgKyBrZXlsZW4KKyAgfQorCisgIHByaW50IGxpbmUK
K30KKworX0FDQVdLCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBh
Y193cml0ZV9mYWlsPTEKK2lmIHNlZCAicy8kYWNfY3IvLyIgPCAvZGV2L251bGwgPiAvZGV2L251
bGwgMj4mMTsgdGhlbgorICBzZWQgInMvJGFjX2NyXCQvLzsgcy8kYWNfY3IvJGFjX2NzX2F3a19j
ci9nIgorZWxzZQorICBjYXQKK2ZpIDwgIiRhY190bXAvc3ViczEuYXdrIiA+ICIkYWNfdG1wL3N1
YnMuYXdrIiBcCisgIHx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGZp
bGVzIG1hY2hpbmVyeSIgIiRMSU5FTk8iIDUKK19BQ0VPRgorCisjIFZQQVRIIG1heSBjYXVzZSB0
cm91YmxlIHdpdGggc29tZSBtYWtlcywgc28gd2UgcmVtb3ZlIHNvbGUgJChzcmNkaXIpLAorIyAk
e3NyY2Rpcn0gYW5kIEBzcmNkaXJAIGVudHJpZXMgZnJvbSBWUEFUSCBpZiBzcmNkaXIgaXMgIi4i
LCBzdHJpcCBsZWFkaW5nIGFuZAorIyB0cmFpbGluZyBjb2xvbnMgYW5kIHRoZW4gcmVtb3ZlIHRo
ZSB3aG9sZSBsaW5lIGlmIFZQQVRIIGJlY29tZXMgZW1wdHkKKyMgKGFjdHVhbGx5IHdlIGxlYXZl
IGFuIGVtcHR5IGxpbmUgdG8gcHJlc2VydmUgbGluZSBudW1iZXJzKS4KK2lmIHRlc3QgIngkc3Jj
ZGlyIiA9IHguOyB0aGVuCisgIGFjX3Zwc3ViPScvXlsJIF0qVlBBVEhbCSBdKj1bCSBdKi97Cito
CitzLy8vCitzL14vOi8KK3MvWwkgXSokLzovCitzLzpcJChzcmNkaXIpOi86L2cKK3MvOlwke3Ny
Y2Rpcn06LzovZworcy86QHNyY2RpckA6LzovZworcy9eOiovLworcy86KiQvLworeAorcy9cKD1b
CSBdKlwpLiovXDEvCitHCitzL1xuLy8KK3MvXltePV0qPVsJIF0qJC8vCit9JworZmkKKworY2F0
ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorZmkgIyB0ZXN0
IC1uICIkQ09ORklHX0ZJTEVTIgorCisjIFNldCB1cCB0aGUgc2NyaXB0cyBmb3IgQ09ORklHX0hF
QURFUlMgc2VjdGlvbi4KKyMgTm8gbmVlZCB0byBnZW5lcmF0ZSB0aGVtIGlmIHRoZXJlIGFyZSBu
byBDT05GSUdfSEVBREVSUy4KKyMgVGhpcyBoYXBwZW5zIGZvciBpbnN0YW5jZSB3aXRoIGAuL2Nv
bmZpZy5zdGF0dXMgTWFrZWZpbGUnLgoraWYgdGVzdCAtbiAiJENPTkZJR19IRUFERVJTIjsgdGhl
bgorY2F0ID4iJGFjX3RtcC9kZWZpbmVzLmF3ayIgPDxcX0FDQVdLIHx8CitCRUdJTiB7CitfQUNF
T0YKKworIyBUcmFuc2Zvcm0gY29uZmRlZnMuaCBpbnRvIGFuIGF3ayBzY3JpcHQgYGRlZmluZXMu
YXdrJywgZW1iZWRkZWQgYXMKKyMgaGVyZS1kb2N1bWVudCBpbiBjb25maWcuc3RhdHVzLCB0aGF0
IHN1YnN0aXR1dGVzIHRoZSBwcm9wZXIgdmFsdWVzIGludG8KKyMgY29uZmlnLmguaW4gdG8gcHJv
ZHVjZSBjb25maWcuaC4KKworIyBDcmVhdGUgYSBkZWxpbWl0ZXIgc3RyaW5nIHRoYXQgZG9lcyBu
b3QgZXhpc3QgaW4gY29uZmRlZnMuaCwgdG8gZWFzZQorIyBoYW5kbGluZyBvZiBsb25nIGxpbmVz
LgorYWNfZGVsaW09JyUhXyEjICcKK2ZvciBhY19sYXN0X3RyeSBpbiBmYWxzZSBmYWxzZSA6OyBk
bworICBhY190dD1gc2VkIC1uICIvJGFjX2RlbGltL3AiIGNvbmZkZWZzLmhgCisgIGlmIHRlc3Qg
LXogIiRhY190dCI7IHRoZW4KKyAgICBicmVhaworICBlbGlmICRhY19sYXN0X3RyeTsgdGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFrZSAkQ09ORklHX0hFQURFUlMiICIkTElO
RU5PIiA1CisgIGVsc2UKKyAgICBhY19kZWxpbT0iJGFjX2RlbGltISRhY19kZWxpbSBfJGFjX2Rl
bGltISEgIgorICBmaQorZG9uZQorCisjIEZvciB0aGUgYXdrIHNjcmlwdCwgRCBpcyBhbiBhcnJh
eSBvZiBtYWNybyB2YWx1ZXMga2V5ZWQgYnkgbmFtZSwKKyMgbGlrZXdpc2UgUCBjb250YWlucyBt
YWNybyBwYXJhbWV0ZXJzIGlmIGFueS4gIFByZXNlcnZlIGJhY2tzbGFzaAorIyBuZXdsaW5lIHNl
cXVlbmNlcy4KKworYWNfd29yZF9yZT1bXyRhc19jcl9MZXR0ZXJzXVtfJGFzX2NyX2FsbnVtXSoK
K3NlZCAtbiAnCitzLy5cezE0OFx9LyYnIiRhY19kZWxpbSInL2cKK3QgcnNldAorOnJzZXQKK3Mv
XlsJIF0qI1sJIF0qZGVmaW5lWwkgXVsJIF0qLyAvCit0IGRlZgorZAorOmRlZgorcy9cXCQvLwor
dCBic25sCitzL1siXFxdL1xcJi9nCitzL14gXCgnIiRhY193b3JkX3JlIidcKVwoKFteKCldKilc
KVsJIF0qXCguKlwpL1BbIlwxIl09IlwyIlwKK0RbIlwxIl09IiBcMyIvcAorcy9eIFwoJyIkYWNf
d29yZF9yZSInXClbCSBdKlwoLipcKS9EWyJcMSJdPSIgXDIiL3AKK2QKKzpic25sCitzL1siXFxd
L1xcJi9nCitzL14gXCgnIiRhY193b3JkX3JlIidcKVwoKFteKCldKilcKVsJIF0qXCguKlwpL1Bb
IlwxIl09IlwyIlwKK0RbIlwxIl09IiBcM1xcXFxcXG4iXFwvcAordCBjb250CitzL14gXCgnIiRh
Y193b3JkX3JlIidcKVsJIF0qXCguKlwpL0RbIlwxIl09IiBcMlxcXFxcXG4iXFwvcAordCBjb250
CitkCis6Y29udAorbgorcy8uXHsxNDhcfS8mJyIkYWNfZGVsaW0iJy9nCit0IGNsZWFyCis6Y2xl
YXIKK3MvXFwkLy8KK3QgYnNubGMKK3MvWyJcXF0vXFwmL2c7IHMvXi8iLzsgcy8kLyIvcAorZAor
OmJzbmxjCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC9cXFxcXFxuIlxcL3AKK2IgY29udAor
JyA8Y29uZmRlZnMuaCB8IHNlZCAnCitzLyciJGFjX2RlbGltIicvIlxcXAorIi9nJyA+PiRDT05G
SUdfU1RBVFVTIHx8IGFjX3dyaXRlX2ZhaWw9MQorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9B
Q0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyAgZm9yIChrZXkgaW4gRCkgRF9pc19zZXRba2V5XSA9
IDEKKyAgRlMgPSAiByIKK30KKy9eW1x0IF0qI1tcdCBdKihkZWZpbmV8dW5kZWYpW1x0IF0rJGFj
X3dvcmRfcmUoW1x0IChdfFwkKS8geworICBsaW5lID0gXCQgMAorICBzcGxpdChsaW5lLCBhcmcs
ICIgIikKKyAgaWYgKGFyZ1sxXSA9PSAiIyIpIHsKKyAgICBkZWZ1bmRlZiA9IGFyZ1syXQorICAg
IG1hYzEgPSBhcmdbM10KKyAgfSBlbHNlIHsKKyAgICBkZWZ1bmRlZiA9IHN1YnN0cihhcmdbMV0s
IDIpCisgICAgbWFjMSA9IGFyZ1syXQorICB9CisgIHNwbGl0KG1hYzEsIG1hYzIsICIoIikgIykK
KyAgbWFjcm8gPSBtYWMyWzFdCisgIHByZWZpeCA9IHN1YnN0cihsaW5lLCAxLCBpbmRleChsaW5l
LCBkZWZ1bmRlZikgLSAxKQorICBpZiAoRF9pc19zZXRbbWFjcm9dKSB7CisgICAgIyBQcmVzZXJ2
ZSB0aGUgd2hpdGUgc3BhY2Ugc3Vycm91bmRpbmcgdGhlICIjIi4KKyAgICBwcmludCBwcmVmaXgg
ImRlZmluZSIsIG1hY3JvIFBbbWFjcm9dIERbbWFjcm9dCisgICAgbmV4dAorICB9IGVsc2Ugewor
ICAgICMgUmVwbGFjZSAjdW5kZWYgd2l0aCBjb21tZW50cy4gIFRoaXMgaXMgbmVjZXNzYXJ5LCBm
b3IgZXhhbXBsZSwKKyAgICAjIGluIHRoZSBjYXNlIG9mIF9QT1NJWF9TT1VSQ0UsIHdoaWNoIGlz
IHByZWRlZmluZWQgYW5kIHJlcXVpcmVkCisgICAgIyBvbiBzb21lIHN5c3RlbXMgd2hlcmUgY29u
ZmlndXJlIHdpbGwgbm90IGRlY2lkZSB0byBkZWZpbmUgaXQuCisgICAgaWYgKGRlZnVuZGVmID09
ICJ1bmRlZiIpIHsKKyAgICAgIHByaW50ICIvKiIsIHByZWZpeCBkZWZ1bmRlZiwgbWFjcm8sICIq
LyIKKyAgICAgIG5leHQKKyAgICB9CisgIH0KK30KK3sgcHJpbnQgfQorX0FDQVdLCitfQUNFT0YK
K2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyAgYXNf
Zm5fZXJyb3IgJD8gImNvdWxkIG5vdCBzZXR1cCBjb25maWcgaGVhZGVycyBtYWNoaW5lcnkiICIk
TElORU5PIiA1CitmaSAjIHRlc3QgLW4gIiRDT05GSUdfSEVBREVSUyIKKworCitldmFsIHNldCBY
ICIgIDpGICRDT05GSUdfRklMRVMgIDpIICRDT05GSUdfSEVBREVSUyAgICAiCitzaGlmdAorZm9y
IGFjX3RhZworZG8KKyAgY2FzZSAkYWNfdGFnIGluCisgIDpbRkhMQ10pIGFjX21vZGU9JGFjX3Rh
ZzsgY29udGludWU7OworICBlc2FjCisgIGNhc2UgJGFjX21vZGUkYWNfdGFnIGluCisgIDpbRkhM
XSo6Kik7OworICA6TCogfCA6Qyo6KikgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdGFnIFxgJGFj
X3RhZyciICIkTElORU5PIiA1OzsKKyAgOltGSF0tKSBhY190YWc9LTotOzsKKyAgOltGSF0qKSBh
Y190YWc9JGFjX3RhZzokYWNfdGFnLmluOzsKKyAgZXNhYworICBhY19zYXZlX0lGUz0kSUZTCisg
IElGUz06CisgIHNldCB4ICRhY190YWcKKyAgSUZTPSRhY19zYXZlX0lGUworICBzaGlmdAorICBh
Y19maWxlPSQxCisgIHNoaWZ0CisKKyAgY2FzZSAkYWNfbW9kZSBpbgorICA6TCkgYWNfc291cmNl
PSQxOzsKKyAgOltGSF0pCisgICAgYWNfZmlsZV9pbnB1dHM9CisgICAgZm9yIGFjX2YKKyAgICBk
bworICAgICAgY2FzZSAkYWNfZiBpbgorICAgICAgLSkgYWNfZj0iJGFjX3RtcC9zdGRpbiI7Owor
ICAgICAgKikgIyBMb29rIGZvciB0aGUgZmlsZSBmaXJzdCBpbiB0aGUgYnVpbGQgdHJlZSwgdGhl
biBpbiB0aGUgc291cmNlIHRyZWUKKwkgIyAoaWYgdGhlIHBhdGggaXMgbm90IGFic29sdXRlKS4g
IFRoZSBhYnNvbHV0ZSBwYXRoIGNhbm5vdCBiZSBET1Mtc3R5bGUsCisJICMgYmVjYXVzZSAkYWNf
ZiBjYW5ub3QgY29udGFpbiBgOicuCisJIHRlc3QgLWYgIiRhY19mIiB8fAorCSAgIGNhc2UgJGFj
X2YgaW4KKwkgICBbXFwvJF0qKSBmYWxzZTs7CisJICAgKikgdGVzdCAtZiAiJHNyY2Rpci8kYWNf
ZiIgJiYgYWNfZj0iJHNyY2Rpci8kYWNfZiI7OworCSAgIGVzYWMgfHwKKwkgICBhc19mbl9lcnJv
ciAxICJjYW5ub3QgZmluZCBpbnB1dCBmaWxlOiBcYCRhY19mJyIgIiRMSU5FTk8iIDU7OworICAg
ICAgZXNhYworICAgICAgY2FzZSAkYWNfZiBpbiAqXCcqKSBhY19mPWAkYXNfZWNobyAiJGFjX2Yi
IHwgc2VkICJzLycvJ1xcXFxcXFxcJycvZyJgOzsgZXNhYworICAgICAgYXNfZm5fYXBwZW5kIGFj
X2ZpbGVfaW5wdXRzICIgJyRhY19mJyIKKyAgICBkb25lCisKKyAgICAjIExldCdzIHN0aWxsIHBy
ZXRlbmQgaXQgaXMgYGNvbmZpZ3VyZScgd2hpY2ggaW5zdGFudGlhdGVzIChpLmUuLCBkb24ndAor
ICAgICMgdXNlICRhc19tZSksIHBlb3BsZSB3b3VsZCBiZSBzdXJwcmlzZWQgdG8gcmVhZDoKKyAg
ICAjICAgIC8qIGNvbmZpZy5oLiAgR2VuZXJhdGVkIGJ5IGNvbmZpZy5zdGF0dXMuICAqLworICAg
IGNvbmZpZ3VyZV9pbnB1dD0nR2VuZXJhdGVkIGZyb20gJ2AKKwkgICRhc19lY2hvICIkKiIgfCBz
ZWQgJ3N8XlteOl0qL3x8O3N8OlteOl0qL3wsIHxnJworCWAnIGJ5IGNvbmZpZ3VyZS4nCisgICAg
aWYgdGVzdCB4IiRhY19maWxlIiAhPSB4LTsgdGhlbgorICAgICAgY29uZmlndXJlX2lucHV0PSIk
YWNfZmlsZS4gICRjb25maWd1cmVfaW5wdXQiCisgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNyZWF0aW5nICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYXNf
bWU6IGNyZWF0aW5nICRhY19maWxlIiA+JjY7fQorICAgIGZpCisgICAgIyBOZXV0cmFsaXplIHNw
ZWNpYWwgY2hhcmFjdGVycyBpbnRlcnByZXRlZCBieSBzZWQgaW4gcmVwbGFjZW1lbnQgc3RyaW5n
cy4KKyAgICBjYXNlICRjb25maWd1cmVfaW5wdXQgaW4gIygKKyAgICAqXCYqIHwgKlx8KiB8ICpc
XCogKQorICAgICAgIGFjX3NlZF9jb25mX2lucHV0PWAkYXNfZWNobyAiJGNvbmZpZ3VyZV9pbnB1
dCIgfAorICAgICAgIHNlZCAncy9bXFxcXCZ8XS9cXFxcJi9nJ2A7OyAjKAorICAgICopIGFjX3Nl
ZF9jb25mX2lucHV0PSRjb25maWd1cmVfaW5wdXQ7OworICAgIGVzYWMKKworICAgIGNhc2UgJGFj
X3RhZyBpbgorICAgICo6LToqIHwgKjotKSBjYXQgPiIkYWNfdG1wL3N0ZGluIiBcCisgICAgICB8
fCBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUg
OzsKKyAgICBlc2FjCisgICAgOzsKKyAgZXNhYworCisgIGFjX2Rpcj1gJGFzX2Rpcm5hbWUgLS0g
IiRhY19maWxlIiB8fAorJGFzX2V4cHIgWCIkYWNfZmlsZSIgOiAnWFwoLipbXi9dXCkvLypbXi9d
W14vXSovKiQnIFx8IFwKKwkgWCIkYWNfZmlsZSIgOiAnWFwoLy9cKVteL10nIFx8IFwKKwkgWCIk
YWNfZmlsZSIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkYWNfZmlsZSIgOiAnWFwoL1wpJyBcfCAu
IDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhY19maWxlIiB8CisgICAgc2VkICcvXlhcKC4q
W14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkg
IC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwo
XC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXCkuKi97CisJ
ICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKyAgYXNfZGlyPSIkYWNf
ZGlyIjsgYXNfZm5fbWtkaXJfcAorICBhY19idWlsZGRpcj0uCisKK2Nhc2UgIiRhY19kaXIiIGlu
CisuKSBhY19kaXJfc3VmZml4PSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3By
ZWZpeD0gOzsKKyopCisgIGFjX2Rpcl9zdWZmaXg9L2AkYXNfZWNobyAiJGFjX2RpciIgfCBzZWQg
J3N8XlwuW1xcL118fCdgCisgICMgQSAiLi4iIGZvciBlYWNoIGRpcmVjdG9yeSBpbiAkYWNfZGly
X3N1ZmZpeC4KKyAgYWNfdG9wX2J1aWxkZGlyX3N1Yj1gJGFzX2VjaG8gIiRhY19kaXJfc3VmZml4
IiB8IHNlZCAnc3wvW15cXC9dKnwvLi58ZztzfC98fCdgCisgIGNhc2UgJGFjX3RvcF9idWlsZGRp
cl9zdWIgaW4KKyAgIiIpIGFjX3RvcF9idWlsZGRpcl9zdWI9LiBhY190b3BfYnVpbGRfcHJlZml4
PSA7OworICAqKSAgYWNfdG9wX2J1aWxkX3ByZWZpeD0kYWNfdG9wX2J1aWxkZGlyX3N1Yi8gOzsK
KyAgZXNhYyA7OworZXNhYworYWNfYWJzX3RvcF9idWlsZGRpcj0kYWNfcHdkCithY19hYnNfYnVp
bGRkaXI9JGFjX3B3ZCRhY19kaXJfc3VmZml4CisjIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5
OgorYWNfdG9wX2J1aWxkZGlyPSRhY190b3BfYnVpbGRfcHJlZml4CisKK2Nhc2UgJHNyY2RpciBp
bgorICAuKSAgIyBXZSBhcmUgYnVpbGRpbmcgaW4gcGxhY2UuCisgICAgYWNfc3JjZGlyPS4KKyAg
ICBhY190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRkaXJfc3ViCisgICAgYWNfYWJzX3RvcF9zcmNk
aXI9JGFjX3B3ZCA7OworICBbXFwvXSogfCA/OltcXC9dKiApICAjIEFic29sdXRlIG5hbWUuCisg
ICAgYWNfc3JjZGlyPSRzcmNkaXIkYWNfZGlyX3N1ZmZpeDsKKyAgICBhY190b3Bfc3JjZGlyPSRz
cmNkaXIKKyAgICBhY19hYnNfdG9wX3NyY2Rpcj0kc3JjZGlyIDs7CisgICopICMgUmVsYXRpdmUg
bmFtZS4KKyAgICBhY19zcmNkaXI9JGFjX3RvcF9idWlsZF9wcmVmaXgkc3JjZGlyJGFjX2Rpcl9z
dWZmaXgKKyAgICBhY190b3Bfc3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpcgorICAg
IGFjX2Fic190b3Bfc3JjZGlyPSRhY19wd2QvJHNyY2RpciA7OworZXNhYworYWNfYWJzX3NyY2Rp
cj0kYWNfYWJzX3RvcF9zcmNkaXIkYWNfZGlyX3N1ZmZpeAorCisKKyAgY2FzZSAkYWNfbW9kZSBp
bgorICA6RikKKyAgIworICAjIENPTkZJR19GSUxFCisgICMKKworICBjYXNlICRJTlNUQUxMIGlu
CisgIFtcXC8kXSogfCA/OltcXC9dKiApIGFjX0lOU1RBTEw9JElOU1RBTEwgOzsKKyAgKikgYWNf
SU5TVEFMTD0kYWNfdG9wX2J1aWxkX3ByZWZpeCRJTlNUQUxMIDs7CisgIGVzYWMKK19BQ0VPRgor
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIElm
IHRoZSB0ZW1wbGF0ZSBkb2VzIG5vdCBrbm93IGFib3V0IGRhdGFyb290ZGlyLCBleHBhbmQgaXQu
CisjIEZJWE1FOiBUaGlzIGhhY2sgc2hvdWxkIGJlIHJlbW92ZWQgYSBmZXcgeWVhcnMgYWZ0ZXIg
Mi42MC4KK2FjX2RhdGFyb290ZGlyX2hhY2s9OyBhY19kYXRhcm9vdGRpcl9zZWVuPQorYWNfc2Vk
X2RhdGFyb290PScKKy9kYXRhcm9vdGRpci8geworICBwCisgIHEKK30KKy9AZGF0YWRpckAvcAor
L0Bkb2NkaXJAL3AKKy9AaW5mb2RpckAvcAorL0Bsb2NhbGVkaXJAL3AKKy9AbWFuZGlyQC9wJwor
Y2FzZSBgZXZhbCAic2VkIC1uIFwiXCRhY19zZWRfZGF0YXJvb3RcIiAkYWNfZmlsZV9pbnB1dHMi
YCBpbgorKmRhdGFyb290ZGlyKikgYWNfZGF0YXJvb3RkaXJfc2Vlbj15ZXM7OworKkBkYXRhZGly
QCp8KkBkb2NkaXJAKnwqQGluZm9kaXJAKnwqQGxvY2FsZWRpckAqfCpAbWFuZGlyQCopCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogJGFjX2ZpbGVf
aW5wdXRzIHNlZW1zIHRvIGlnbm9yZSB0aGUgLS1kYXRhcm9vdGRpciBzZXR0aW5nIiA+JjUKKyRh
c19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICRhY19maWxlX2lucHV0cyBzZWVtcyB0byBpZ25vcmUg
dGhlIC0tZGF0YXJvb3RkaXIgc2V0dGluZyIgPiYyO30KK19BQ0VPRgorY2F0ID4+JENPTkZJR19T
VEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGFjX2RhdGFyb290ZGlyX2hhY2s9
JworICBzJkBkYXRhZGlyQCYkZGF0YWRpciZnCisgIHMmQGRvY2RpckAmJGRvY2RpciZnCisgIHMm
QGluZm9kaXJAJiRpbmZvZGlyJmcKKyAgcyZAbG9jYWxlZGlyQCYkbG9jYWxlZGlyJmcKKyAgcyZA
bWFuZGlyQCYkbWFuZGlyJmcKKyAgcyZcXFwke2RhdGFyb290ZGlyfSYkZGF0YXJvb3RkaXImZycg
OzsKK2VzYWMKK19BQ0VPRgorCisjIE5ldXRyYWxpemUgVlBBVEggd2hlbiBgJHNyY2RpcicgPSBg
LicuCisjIFNoZWxsIGNvZGUgaW4gY29uZmlndXJlLmFjIG1pZ2h0IHNldCBleHRyYXN1Yi4KKyMg
RklYTUU6IGRvIHdlIHJlYWxseSB3YW50IHRvIG1haW50YWluIHRoaXMgZmVhdHVyZT8KK2NhdCA+
PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorYWNfc2VkX2V4dHJh
PSIkYWNfdnBzdWIKKyRleHRyYXN1YgorX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxf
QUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCis6dAorL0BbYS16QS1aX11bYS16QS1aXzAtOV0qQC8h
Ygorc3xAY29uZmlndXJlX2lucHV0QHwkYWNfc2VkX2NvbmZfaW5wdXR8O3QgdAorcyZAdG9wX2J1
aWxkZGlyQCYkYWNfdG9wX2J1aWxkZGlyX3N1YiY7dCB0CitzJkB0b3BfYnVpbGRfcHJlZml4QCYk
YWNfdG9wX2J1aWxkX3ByZWZpeCY7dCB0CitzJkBzcmNkaXJAJiRhY19zcmNkaXImO3QgdAorcyZA
YWJzX3NyY2RpckAmJGFjX2Fic19zcmNkaXImO3QgdAorcyZAdG9wX3NyY2RpckAmJGFjX3RvcF9z
cmNkaXImO3QgdAorcyZAYWJzX3RvcF9zcmNkaXJAJiRhY19hYnNfdG9wX3NyY2RpciY7dCB0Citz
JkBidWlsZGRpckAmJGFjX2J1aWxkZGlyJjt0IHQKK3MmQGFic19idWlsZGRpckAmJGFjX2Fic19i
dWlsZGRpciY7dCB0CitzJkBhYnNfdG9wX2J1aWxkZGlyQCYkYWNfYWJzX3RvcF9idWlsZGRpciY7
dCB0CitzJkBJTlNUQUxMQCYkYWNfSU5TVEFMTCY7dCB0CiskYWNfZGF0YXJvb3RkaXJfaGFjawor
IgorZXZhbCBzZWQgXCJcJGFjX3NlZF9leHRyYVwiICIkYWNfZmlsZV9pbnB1dHMiIHwgJEFXSyAt
ZiAiJGFjX3RtcC9zdWJzLmF3ayIgXAorICA+JGFjX3RtcC9vdXQgfHwgYXNfZm5fZXJyb3IgJD8g
ImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisKK3Rlc3QgLXogIiRhY19k
YXRhcm9vdGRpcl9oYWNrJGFjX2RhdGFyb290ZGlyX3NlZW4iICYmCisgIHsgYWNfb3V0PWBzZWQg
LW4gJy9cJHtkYXRhcm9vdGRpcn0vcCcgIiRhY190bXAvb3V0ImA7IHRlc3QgLW4gIiRhY19vdXQi
OyB9ICYmCisgIHsgYWNfb3V0PWBzZWQgLW4gJy9eWwkgXSpkYXRhcm9vdGRpclsJIF0qOio9L3An
IFwKKyAgICAgICIkYWNfdG1wL291dCJgOyB0ZXN0IC16ICIkYWNfb3V0IjsgfSAmJgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICRhY19maWxlIGNv
bnRhaW5zIGEgcmVmZXJlbmNlIHRvIHRoZSB2YXJpYWJsZSBcYGRhdGFyb290ZGlyJword2hpY2gg
c2VlbXMgdG8gYmUgdW5kZWZpbmVkLiAgUGxlYXNlIG1ha2Ugc3VyZSBpdCBpcyBkZWZpbmVkIiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICRhY19maWxlIGNvbnRhaW5zIGEgcmVmZXJl
bmNlIHRvIHRoZSB2YXJpYWJsZSBcYGRhdGFyb290ZGlyJword2hpY2ggc2VlbXMgdG8gYmUgdW5k
ZWZpbmVkLiAgUGxlYXNlIG1ha2Ugc3VyZSBpdCBpcyBkZWZpbmVkIiA+JjI7fQorCisgIHJtIC1m
ICIkYWNfdG1wL3N0ZGluIgorICBjYXNlICRhY19maWxlIGluCisgIC0pIGNhdCAiJGFjX3RtcC9v
dXQiICYmIHJtIC1mICIkYWNfdG1wL291dCI7OworICAqKSBybSAtZiAiJGFjX2ZpbGUiICYmIG12
ICIkYWNfdG1wL291dCIgIiRhY19maWxlIjs7CisgIGVzYWMgXAorICB8fCBhc19mbl9lcnJvciAk
PyAiY291bGQgbm90IGNyZWF0ZSAkYWNfZmlsZSIgIiRMSU5FTk8iIDUKKyA7OworICA6SCkKKyAg
IworICAjIENPTkZJR19IRUFERVIKKyAgIworICBpZiB0ZXN0IHgiJGFjX2ZpbGUiICE9IHgtOyB0
aGVuCisgICAgeworICAgICAgJGFzX2VjaG8gIi8qICRjb25maWd1cmVfaW5wdXQgICovIiBcCisg
ICAgICAmJiBldmFsICckQVdLIC1mICIkYWNfdG1wL2RlZmluZXMuYXdrIicgIiRhY19maWxlX2lu
cHV0cyIKKyAgICB9ID4iJGFjX3RtcC9jb25maWcuaCIgXAorICAgICAgfHwgYXNfZm5fZXJyb3Ig
JD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgICAgaWYgZGlmZiAi
JGFjX2ZpbGUiICIkYWNfdG1wL2NvbmZpZy5oIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgICAg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX2ZpbGUgaXMgdW5j
aGFuZ2VkIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6ICRhY19maWxlIGlzIHVuY2hhbmdlZCIgPiY2
O30KKyAgICBlbHNlCisgICAgICBybSAtZiAiJGFjX2ZpbGUiCisgICAgICBtdiAiJGFjX3RtcC9j
b25maWcuaCIgIiRhY19maWxlIiBcCisJfHwgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBjcmVh
dGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgICAgZmkKKyAgZWxzZQorICAgICRhc19lY2hvICIv
KiAkY29uZmlndXJlX2lucHV0ICAqLyIgXAorICAgICAgJiYgZXZhbCAnJEFXSyAtZiAiJGFjX3Rt
cC9kZWZpbmVzLmF3ayInICIkYWNfZmlsZV9pbnB1dHMiIFwKKyAgICAgIHx8IGFzX2ZuX2Vycm9y
ICQ/ICJjb3VsZCBub3QgY3JlYXRlIC0iICIkTElORU5PIiA1CisgIGZpCisgOzsKKworCisgIGVz
YWMKKworZG9uZSAjIGZvciBhY190YWcKKworCithc19mbl9leGl0IDAKK19BQ0VPRgorYWNfY2xl
YW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKKwordGVzdCAkYWNfd3JpdGVfZmFpbCA9IDAg
fHwKKyAgYXNfZm5fZXJyb3IgJD8gIndyaXRlIGZhaWx1cmUgY3JlYXRpbmcgJENPTkZJR19TVEFU
VVMiICIkTElORU5PIiA1CisKKworIyBjb25maWd1cmUgaXMgd3JpdGluZyB0byBjb25maWcubG9n
LCBhbmQgdGhlbiBjYWxscyBjb25maWcuc3RhdHVzLgorIyBjb25maWcuc3RhdHVzIGRvZXMgaXRz
IG93biByZWRpcmVjdGlvbiwgYXBwZW5kaW5nIHRvIGNvbmZpZy5sb2cuCisjIFVuZm9ydHVuYXRl
bHksIG9uIERPUyB0aGlzIGZhaWxzLCBhcyBjb25maWcubG9nIGlzIHN0aWxsIGtlcHQgb3Blbgor
IyBieSBjb25maWd1cmUsIHNvIGNvbmZpZy5zdGF0dXMgd29uJ3QgYmUgYWJsZSB0byB3cml0ZSB0
byBpdDsgaXRzCisjIG91dHB1dCBpcyBzaW1wbHkgZGlzY2FyZGVkLiAgU28gd2UgZXhlYyB0aGUg
RkQgdG8gL2Rldi9udWxsLAorIyBlZmZlY3RpdmVseSBjbG9zaW5nIGNvbmZpZy5sb2csIHNvIGl0
IGNhbiBiZSBwcm9wZXJseSAocmUpb3BlbmVkIGFuZAorIyBhcHBlbmRlZCB0byBieSBjb25maWcu
c3RhdHVzLiAgV2hlbiBjb21pbmcgYmFjayB0byBjb25maWd1cmUsIHdlCisjIG5lZWQgdG8gbWFr
ZSB0aGUgRkQgYXZhaWxhYmxlIGFnYWluLgoraWYgdGVzdCAiJG5vX2NyZWF0ZSIgIT0geWVzOyB0
aGVuCisgIGFjX2NzX3N1Y2Nlc3M9OgorICBhY19jb25maWdfc3RhdHVzX2FyZ3M9CisgIHRlc3Qg
IiRzaWxlbnQiID0geWVzICYmCisgICAgYWNfY29uZmlnX3N0YXR1c19hcmdzPSIkYWNfY29uZmln
X3N0YXR1c19hcmdzIC0tcXVpZXQiCisgIGV4ZWMgNT4vZGV2L251bGwKKyAgJFNIRUxMICRDT05G
SUdfU1RBVFVTICRhY19jb25maWdfc3RhdHVzX2FyZ3MgfHwgYWNfY3Nfc3VjY2Vzcz1mYWxzZQor
ICBleGVjIDU+PmNvbmZpZy5sb2cKKyAgIyBVc2UgfHwsIG5vdCAmJiwgdG8gYXZvaWQgZXhpdGlu
ZyBmcm9tIHRoZSBpZiB3aXRoICQ/ID0gMSwgd2hpY2gKKyAgIyB3b3VsZCBtYWtlIGNvbmZpZ3Vy
ZSBmYWlsIGlmIHRoaXMgaXMgdGhlIGxhc3QgaW5zdHJ1Y3Rpb24uCisgICRhY19jc19zdWNjZXNz
IHx8IGFzX2ZuX2V4aXQgMQorZmkKK2lmIHRlc3QgLW4gIiRhY191bnJlY29nbml6ZWRfb3B0cyIg
JiYgdGVzdCAiJGVuYWJsZV9vcHRpb25fY2hlY2tpbmciICE9IG5vOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdW5yZWNvZ25pemVkIG9w
dGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJO
SU5HOiB1bnJlY29nbml6ZWQgb3B0aW9uczogJGFjX3VucmVjb2duaXplZF9vcHRzIiA+JjI7fQor
ZmkKKwpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvY29uZmlndXJl
LmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rv
b2xzL2NvbmZpZ3VyZS5hYwlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTAsMCAr
MSwxOTIgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBhdXRvY29uZiB0byBw
cm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsyLjY3XSkKK0FDX0lOSVQo
W1hlbiBIeXBlcnZpc29yXSwgbTRfZXN5c2NtZChbLi4vdmVyc2lvbi5zaCAuLi94ZW4vTWFrZWZp
bGVdKSwKKyAgICBbeGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb21dKQorQUNfQ09ORklHX1NS
Q0RJUihbbGlieGwvbGlieGwuY10pCitBQ19DT05GSUdfRklMRVMoWy4uL2NvbmZpZy9Ub29scy5t
a10pCitBQ19DT05GSUdfSEVBREVSUyhbY29uZmlnLmhdKQorQUNfUFJFRklYX0RFRkFVTFQoWy91
c3JdKQorQUNfQ09ORklHX0FVWF9ESVIoWy5dKQorCisjIENoZWNrIGlmIENGTEFHUywgTERGTEFH
UywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCisKK0FT
X0lGKFt0ZXN0IC1uICIkQ0MkQ0ZMQUdTJExERkxBR1MkTElCUyRDUFBGTEFHUyRDUFAiXSwgWwor
ICAgIEFDX01TR19XQVJOKAorW1NldHRpbmcgQ0MsIENGTEFHUywgTERGTEFHUywgTElCUywgQ1BQ
RkxBR1Mgb3IgQ1BQIGlzIG5vdCBcCityZWNvbW1lbmRlZCwgdXNlIFBSRVBFTkRfSU5DTFVERVMs
IFBSRVBFTkRfTElCLCBcCitBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3
aGVuIHBvc3NpYmxlLl0pCitdKQorCitBQ19VU0VfU1lTVEVNX0VYVEVOU0lPTlMKK0FDX0NBTk9O
SUNBTF9IT1NUCisKKyMgTTQgTWFjcm8gaW5jbHVkZXMKK200X2luY2x1ZGUoW200L2VuYWJsZV9m
ZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200L2Rpc2FibGVfZmVhdHVyZS5tNF0pCittNF9pbmNs
dWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX3htbC5tNF0p
CittNF9pbmNsdWRlKFttNC9weXRob25fdmVyc2lvbi5tNF0pCittNF9pbmNsdWRlKFttNC9weXRo
b25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShbbTQvdWRldi5tNF0pCittNF9pbmNsdWRlKFttNC9v
Y2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9kZWZhdWx0X2xpYi5tNF0pCittNF9pbmNsdWRlKFtt
NC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQorbTRfaW5jbHVkZShbbTQvdXVpZC5tNF0pCisKKyMg
RW5hYmxlL2Rpc2FibGUgb3B0aW9ucworQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt4c21dLAor
ICAgIFtFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spXSkKK0FY
X0FSR19FTkFCTEVfQU5EX0VYUE9SVChbZ2l0aHR0cF0sIFtEb3dubG9hZCBHSVQgcmVwb3NpdG9y
aWVzIHZpYSBIVFRQXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW21vbml0b3JzXSwKKyAg
ICBbRGlzYWJsZSB4ZW5zdGF0IGFuZCB4ZW50b3AgbW9uaXRvcmluZyB0b29sc10pCitBWF9BUkdf
RU5BQkxFX0FORF9FWFBPUlQoW3Z0cG1dLCBbRW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9y
bSBNb2R1bGVdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt4YXBpXSwgW0VuYWJsZSBYZW4g
QVBJIEJpbmRpbmdzXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW3B5dGhvbnRvb2xzXSwg
W0Rpc2FibGUgUHl0aG9uIHRvb2xzXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW29jYW1s
dG9vbHNdLCBbRGlzYWJsZSBPY2FtbCB0b29sc10pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQo
W21pbml0ZXJtXSwgW0VuYWJsZSBtaW5pdGVybV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQo
W2xvbW91bnRdLCBbRW5hYmxlIGxvbW91bnRdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChb
ZGVidWddLCBbRGlzYWJsZSBkZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzXSkKKworQUNfQVJH
X1ZBUihbUFJFUEVORF9JTkNMVURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRv
IHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtQUkVQRU5EX0xJ
Ql0sCisgICAgW0xpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAo
d2l0aG91dCAtTCldKQorQUNfQVJHX1ZBUihbQVBQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBv
ZiBpbmNsdWRlIGZvbGRlcnMgdG8gYXBwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQorQUNf
QVJHX1ZBUihbQVBQRU5EX0xJQl0sCisgICAgW0xpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFw
cGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKV0pCisKK0FYX1NFVF9GTEFHUworCitBQ19BUkdf
VkFSKFtQWVRIT05dLCBbUGF0aCB0byB0aGUgUHl0aG9uIHBhcnNlcl0pCitBQ19BUkdfVkFSKFtQ
RVJMXSwgW1BhdGggdG8gUGVybCBwYXJzZXJdKQorQUNfQVJHX1ZBUihbQlJDVExdLCBbUGF0aCB0
byBicmN0bCB0b29sXSkKK0FDX0FSR19WQVIoW0lQXSwgW1BhdGggdG8gaXAgdG9vbF0pCitBQ19B
UkdfVkFSKFtCSVNPTl0sIFtQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQorQUNfQVJH
X1ZBUihbRkxFWF0sIFtQYXRoIHRvIEZsZXggbGV4aWNhbCBhbmFseXNlciBnZW5lcmF0b3JdKQor
QUNfQVJHX1ZBUihbQ1VSTF0sIFtQYXRoIHRvIGN1cmwtY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZB
UihbWE1MXSwgW1BhdGggdG8geG1sMi1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtCQVNIXSwg
W1BhdGggdG8gYmFzaCBzaGVsbF0pCitBQ19BUkdfVkFSKFtYR0VUVEVYVF0sIFtQYXRoIHRvIHhn
ZXR0dGV4dCB0b29sXSkKKworIyBDaGVja3MgZm9yIHByb2dyYW1zLgorQUNfUFJPR19TRUQKK0FD
X1BST0dfQ0MKK0FDX1BST0dfTE5fUworQUNfUFJPR19NQUtFX1NFVAorQUNfUFJPR19JTlNUQUxM
CitBWF9QQVRIX1BST0dfT1JfRkFJTChbUEVSTF0sIFtwZXJsXSkKK0FYX1BBVEhfUFJPR19PUl9G
QUlMKFtCUkNUTF0sIFticmN0bF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbSVBdLCBbaXBdKQor
QVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JJU09OXSwgW2Jpc29uXSkKK0FYX1BBVEhfUFJPR19PUl9G
QUlMKFtGTEVYXSwgW2ZsZXhdKQorQVNfSUYoW3Rlc3QgIngkeGFwaSIgPSAieHkiXSwgWworICAg
IEFYX1BBVEhfUFJPR19PUl9GQUlMKFtDVVJMXSwgW2N1cmwtY29uZmlnXSkKKyAgICBBWF9QQVRI
X1BST0dfT1JfRkFJTChbWE1MXSwgW3htbDItY29uZmlnXSkKK10pCitBU19JRihbdGVzdCAieCRv
Y2FtbHRvb2xzIiA9ICJ4eSJdLCBbCisgICAgQUNfUFJPR19PQ0FNTAorICAgIEFTX0lGKFt0ZXN0
ICJ4JE9DQU1MQyIgPSAieG5vIl0sIFsKKyAgICAgICAgQVNfSUYoW3Rlc3QgIngkZW5hYmxlX29j
YW1sdG9vbHMiID0gInh5ZXMiXSwgWworICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFtPY2FtbCB0
b29scyBlbmFibGVkLCBidXQgdW5hYmxlIHRvIGZpbmQgT2NhbWxdKV0pCisgICAgICAgIG9jYW1s
dG9vbHM9Im4iCisgICAgXSkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQkFTSF0sIFtiYXNo
XSkKK0FTX0lGKFt0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSJdLCBbCisgICAgQVNfSUYoW2Vj
aG8gIiRQWVRIT04iIHwgZ3JlcCAtcSAiXi8iXSwgWworICAgICAgICBQWVRIT05QQVRIPSRQWVRI
T04KKyAgICAgICAgUFlUSE9OPWBiYXNlbmFtZSAkUFlUSE9OUEFUSGAKKyAgICBdLFt0ZXN0IC16
ICIkUFlUSE9OIl0sIFtQWVRIT049InB5dGhvbiJdLAorICAgIFtBQ19NU0dfRVJST1IoW1BZVEhP
TiBzcGVjaWZpZWQsIGJ1dCBpcyBub3QgYW4gYWJzb2x1dGUgcGF0aF0pXSkKKyAgICBBWF9QQVRI
X1BST0dfT1JfRkFJTChbUFlUSE9OUEFUSF0sIFskUFlUSE9OXSkKKyAgICBBWF9DSEVDS19QWVRI
T05fVkVSU0lPTihbMl0sIFszXSkKKyAgICBBWF9DSEVDS19QWVRIT05fWE1MKCkKKyAgICBBWF9D
SEVDS19QWVRIT05fREVWRUwoKQorXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtYR0VUVEVYVF0s
IFt4Z2V0dGV4dF0pCitBWF9DSEVDS19VREVWKFs1OV0pCitBWF9DSEVDS19VVUlECitQS0dfQ0hF
Q0tfTU9EVUxFUyhnbGliLCBnbGliLTIuMCkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RF
RkFVTFRfTElCCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10s
IFtpb19zZXR1cF0sIFtzeXN0ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJT
VChzeXN0ZW1fYWlvKQorQUNfQ0hFQ0tfTElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0df
RVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZz
XSwgW2V4dDJmc19vcGVuMl0sIFtsaWJleHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNf
U1VCU1QobGliZXh0MmZzKQorQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1
ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2Ny
eXB0KQorQUNfQ0hFQ0tfTElCKFtwdGhyZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAg
IFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19M
SUIoW3J0XSwgW2Nsb2NrX2dldHRpbWVdKQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xl
YXJdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQor
QUNfQ0hFQ0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9S
KFtDb3VsZCBub3QgZmluZCB5YWpsXSldKQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5
XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19M
SUIoW2ljb252XSwgW2xpYmljb252X29wZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJu
Il0pCitBQ19TVUJTVChsaWJpY29udikKKworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5
YWpsL3lhamxfdmVyc2lvbi5oIGNoZWNrKQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FD
X0ZVTkNfQUxMT0NBCitBQ19DSEVDS19IRUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEv
aW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAor
ICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0
ZGxpYi5oIHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBz
eXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lz
L3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAor
ICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAg
ICAgICAgIF0pCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBp
bGVyIGNoYXJhY3RlcmlzdGljcy4KK0FDX0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitB
Q19DX0lOTElORQorQUNfVFlQRV9JTlQxNl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5U
NjRfVAorQUNfVFlQRV9JTlQ4X1QKK0FDX1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19U
WVBFX1BJRF9UCitBQ19DX1JFU1RSSUNUCitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9U
CitBQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9T
VF9CTE9DS1MKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQ
RV9VSU5UMTZfVAorQUNfVFlQRV9VSU5UMzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9V
SU5UOF9UCitBQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJh
cnkgZnVuY3Rpb25zLgorQUNfRlVOQ19FUlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZV
TkNfRlNFRUtPCitBQ19GVU5DX0xTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFE
RVJfTUFKT1IKK0FDX0ZVTkNfTUFMTE9DCitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitB
Q19GVU5DX1JFQUxMT0MKK0FDX0ZVTkNfU1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNL
X0ZVTkNTKFsgXAorICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0
aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdl
dGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAg
ICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBt
ZW1zZXQgbWtkaXIgXAorICAgICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVh
bHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2Nr
ZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisg
ICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRv
dWwgc3RydG91bGwgdHpzZXQgXAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAg
ICAgICBdKQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5
MTQgdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUKLS0tIGEvdG9vbHMvZGVidWdnZXIv
Z2Ric3gveGcvTWFrZWZpbGUJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiL3Rv
b2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiAr
MDEwMApAQCAtMjEsNyArMjEsNiBAQCB4Z19hbGwuYTogJChYR19PQkpTKSBNYWtlZmlsZSAkKFhH
X0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMgLW8gJEAgJF4KIAogeGVuLWhlYWRlcnM6Ci0JJChNQUtF
KSAtQyAuLi8uLi8uLi9jaGVjayAKIAkkKE1BS0UpIC1DIC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4
Z19tYWluLm86IHhnX21haW4uYyBNYWtlZmlsZSAkKFhHX0hEUlMpCmRpZmYgLXIgODcyMThiZDM2
N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9pbnN0YWxsLnNoCi0tLSAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2luc3RhbGwuc2gJTW9uIEZlYiAy
MCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMSBAQAorLi4vaW5zdGFsbC5zaApcIE5v
IG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhh
OTE0IHRvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9NYWtl
ZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGliZnNpbWFn
ZS9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTMsNyArMywxMSBA
QCBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCiAKIFNVQkRJUlMteSA9IGNvbW1v
biB1ZnMgcmVpc2VyZnMgaXNvOTY2MCBmYXQgemZzCiBTVUJESVJTLSQoQ09ORklHX1g4NikgKz0g
eGZzCi1TVUJESVJTLXkgKz0gJChzaGVsbCBlbnYgQ0M9IiQoQ0MpIiAuL2NoZWNrLWxpYmV4dDJm
cykKK2lmZXEgKCQoQ09ORklHX0VYVDJGUyksIHkpCisgICAgU1VCRElSUy15ICs9IGV4dDJmcy1s
aWIKK2Vsc2UKKyAgICBTVUJESVJTLXkgKz0gZXh0MmZzCitlbmRpZgogCiAuUEhPTlk6IGFsbCBj
bGVhbiBpbnN0YWxsCiBhbGwgY2xlYW4gaW5zdGFsbDogJTogc3ViZGlycy0lCmRpZmYgLXIgODcy
MThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9saWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJm
cwotLS0gYS90b29scy9saWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJmcwlGcmkgRmViIDE3IDEyOjI0
OjM4IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMjEgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+ZXh0Mi10ZXN0LmMgPDxFT0YK
LSNpbmNsdWRlIDxleHQyZnMvZXh0MmZzLmg+Ci0KLWludCBtYWluKCkKLXsKLQlleHQyZnNfb3Bl
bjI7Ci19Ci1FT0YKLQotJHtDQy1nY2N9IC1vIGV4dDItdGVzdCBleHQyLXRlc3QuYyAtbGV4dDJm
cyA+L2Rldi9udWxsIDI+JjEKLWlmIFsgJD8gPSAwIF07IHRoZW4KLQllY2hvIGV4dDJmcy1saWIK
LWVsc2UKLQllY2hvIGV4dDJmcwotZmkKLQotcm0gLWYgZXh0Mi10ZXN0IGV4dDItdGVzdC5jCi0K
LWV4aXQgMApkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbGlieGVu
L01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4
IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGVuL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MjA6
MjkgMjAxMiArMDEwMApAQCAtMjIsMTIgKzIyLDEyIEBAIE1BSk9SID0gMS4wCiBNSU5PUiA9IDAK
IAogQ0ZMQUdTICs9IC1JaW5jbHVkZSAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAk
KHNoZWxsIHhtbDItY29uZmlnIC0tY2ZsYWdzKSBcCi0gICAgICAgICAgJChzaGVsbCBjdXJsLWNv
bmZpZyAtLWNmbGFncykgXAorICAgICAgICAgICQoc2hlbGwgJChYTUwyX0NPTkZJRykgLS1jZmxh
Z3MpIFwKKyAgICAgICAgICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tY2ZsYWdzKSBcCiAgICAg
ICAgICAgLWZQSUMKIAotTERGTEFHUyArPSAkKHNoZWxsIHhtbDItY29uZmlnIC0tbGlicykgXAot
ICAgICAgICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tbGlicykKK0xERkxBR1MgKz0gJChzaGVs
bCAkKFhNTDJfQ09ORklHKSAtLWxpYnMpIFwKKyAgICAgICAgICAgJChzaGVsbCAkKENVUkxfQ09O
RklHKSAtLWxpYnMpCiAKIExJQlhFTkFQSV9IRFJTID0gJCh3aWxkY2FyZCBpbmNsdWRlL3hlbi9h
cGkvKi5oKSBpbmNsdWRlL3hlbi9hcGkveGVuX2FsbC5oCiBMSUJYRU5BUElfT0JKUyA9ICQocGF0
c3Vic3QgJS5jLCAlLm8sICQod2lsZGNhcmQgc3JjLyouYykpCmRpZmYgLXIgODcyMThiZDM2N2Jl
IC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9saWJ4bC9NYWtlZmlsZQotLS0gYS90b29scy9saWJ4bC9N
YWtlZmlsZQlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwv
TWFrZWZpbGUJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0xOSwxMCArMTksNiBA
QCBpZmVxICgkKENPTkZJR19MaW51eCkseSkKIExJQlVVSURfTElCUyArPSAtbHV1aWQKIGVuZGlm
CiAKLWlmZXEgKCQoQ09ORklHX1lBSkxfVkVSU0lPTikseSkKLUNGTEFHUyArPSAtREhBVkVfWUFK
TF9WRVJTSU9OCi1lbmRpZgotCiBMSUJYTF9MSUJTID0KIExJQlhMX0xJQlMgPSAkKExETElCU19s
aWJ4ZW5jdHJsKSAkKExETElCU19saWJ4ZW5ndWVzdCkgJChMRExJQlNfbGlieGVuc3RvcmUpICQo
TERMSUJTX2xpYmJsa3RhcGN0bCkgJChVVElMX0xJQlMpICQoTElCVVVJRF9MSUJTKQogCkBAIC01
Niw3ICs1Miw3IEBAIExJQlhMX09CSlMgPSBmbGV4YXJyYXkubyBsaWJ4bC5vIGxpYnhsX2MKIAkJ
CWxpYnhsX3FtcC5vIGxpYnhsX2V2ZW50Lm8gJChMSUJYTF9PQkpTLXkpCiBMSUJYTF9PQkpTICs9
IF9saWJ4bF90eXBlcy5vIGxpYnhsX2ZsYXNrLm8gX2xpYnhsX3R5cGVzX2ludGVybmFsLm8KIAot
JChMSUJYTF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICQoQ0ZMQUdTX2xp
Ynhlbmd1ZXN0KSAkKENGTEFHU19saWJ4ZW5zdG9yZSkgJChDRkxBR1NfbGliYmxrdGFwY3RsKQor
JChMSUJYTF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICQoQ0ZMQUdTX2xp
Ynhlbmd1ZXN0KSAkKENGTEFHU19saWJ4ZW5zdG9yZSkgJChDRkxBR1NfbGliYmxrdGFwY3RsKSAt
aW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9jb25maWcuaAogCiBBVVRPSU5DUz0gbGlieGx1X2Nm
Z195LmggbGlieGx1X2NmZ19sLmggX2xpYnhsX2xpc3QuaAogQVVUT1NSQ1M9IGxpYnhsdV9jZmdf
eS5jIGxpYnhsdV9jZmdfbC5jCkBAIC02OSw2ICs2NSw3IEBAIENMSUVOVFMgPSB4bCB0ZXN0aWRs
CiBYTF9PQkpTID0geGwubyB4bF9jbWRpbXBsLm8geGxfY21kdGFibGUubyB4bF9zeHAubwogJChY
TF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmN0cmwpICMgRm9yIHhlbnRvb2xsb2cu
aAogJChYTF9PQkpTKTogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xpYnhlbmxpZ2h0KQorJChYTF9PQkpT
KTogQ0ZMQUdTICs9IC1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL2NvbmZpZy5oICMgbGlieGxf
anNvbi5oIG5lZWRzIGl0LgogCiB0ZXN0aWRsLm86IENGTEFHUyArPSAkKENGTEFHU19saWJ4ZW5j
dHJsKSAkKENGTEFHU19saWJ4ZW5saWdodCkKIHRlc3RpZGwuYzogbGlieGxfdHlwZXMuaWRsIGdl
bnRlc3QucHkgbGlieGwuaCAkKEFVVE9JTkNTKQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2Rm
OWVkOGE5MTQgdG9vbHMvbGlieGwvbGlieGxfanNvbi5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhs
X2pzb24uaAlGcmkgRmViIDE3IDEyOjI0OjM4IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwv
bGlieGxfanNvbi5oCU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMTgsNyArMTgs
NyBAQAogI2luY2x1ZGUgPHlhamwveWFqbF9nZW4uaD4KICNpbmNsdWRlIDx5YWpsL3lhamxfcGFy
c2UuaD4KIAotI2lmZGVmIEhBVkVfWUFKTF9WRVJTSU9OCisjaWZkZWYgSEFWRV9ZQUpMX1lBSkxf
VkVSU0lPTl9ICiAjICBpbmNsdWRlIDx5YWpsL3lhamxfdmVyc2lvbi5oPgogI2VuZGlmCiAKZGlm
ZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2xpYnhsL2xpYnhsdV9jZmdf
eS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9jZmdfeS5jCUZyaSBGZWIgMTcgMTI6MjQ6Mzgg
MjAxMiArMDAwMAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfY2ZnX3kuYwlNb24gRmViIDIwIDE4
OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTEsMjQgKzEsMjEgQEAKLS8qIEEgQmlzb24gcGFyc2VyLCBt
YWRlIGJ5IEdOVSBCaXNvbiAyLjMuICAqLworLyogQSBCaXNvbiBwYXJzZXIsIG1hZGUgYnkgR05V
IEJpc29uIDIuNS4gICovCiAKLS8qIFNrZWxldG9uIGltcGxlbWVudGF0aW9uIGZvciBCaXNvbidz
IFlhY2MtbGlrZSBwYXJzZXJzIGluIEMKLQotICAgQ29weXJpZ2h0IChDKSAxOTg0LCAxOTg5LCAx
OTkwLCAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2Ci0gICBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KLQotICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh
cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKy8qIEJpc29uIGltcGxl
bWVudGF0aW9uIGZvciBZYWNjLWxpa2UgcGFyc2VycyBpbiBDCisgICAKKyAgICAgIENvcHlyaWdo
dCAoQykgMTk4NCwgMTk4OS0xOTkwLCAyMDAwLTIwMTEgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
LCBJbmMuCisgICAKKyAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOiB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CiAgICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQotICAgdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiwgb3IgKGF0IHlvdXIgb3B0aW9u
KQotICAgYW55IGxhdGVyIHZlcnNpb24uCi0KKyAgIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp
b24sIGVpdGhlciB2ZXJzaW9uIDMgb2YgdGhlIExpY2Vuc2UsIG9yCisgICAoYXQgeW91ciBvcHRp
b24pIGFueSBsYXRlciB2ZXJzaW9uLgorICAgCiAgICBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0
ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKICAgIGJ1dCBXSVRIT1VUIEFO
WSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiAgICBNRVJD
SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhl
CiAgICBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgotCisgICAK
ICAgIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlCi0gICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0
byB0aGUgRnJlZSBTb2Z0d2FyZQotICAgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3Ry
ZWV0LCBGaWZ0aCBGbG9vciwKLSAgIEJvc3RvbiwgTUEgMDIxMTAtMTMwMSwgVVNBLiAgKi8KKyAg
IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9y
Zy9saWNlbnNlcy8+LiAgKi8KIAogLyogQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiwgeW91IG1heSBj
cmVhdGUgYSBsYXJnZXIgd29yayB0aGF0IGNvbnRhaW5zCiAgICBwYXJ0IG9yIGFsbCBvZiB0aGUg
Qmlzb24gcGFyc2VyIHNrZWxldG9uIGFuZCBkaXN0cmlidXRlIHRoYXQgd29yawpAQCAtMjksNyAr
MjYsNyBAQAogICAgc3BlY2lhbCBleGNlcHRpb24sIHdoaWNoIHdpbGwgY2F1c2UgdGhlIHNrZWxl
dG9uIGFuZCB0aGUgcmVzdWx0aW5nCiAgICBCaXNvbiBvdXRwdXQgZmlsZXMgdG8gYmUgbGljZW5z
ZWQgdW5kZXIgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYwogICAgTGljZW5zZSB3aXRob3V0IHRoaXMg
c3BlY2lhbCBleGNlcHRpb24uCi0KKyAgIAogICAgVGhpcyBzcGVjaWFsIGV4Y2VwdGlvbiB3YXMg
YWRkZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiBpbgogICAgdmVyc2lvbiAyLjIg
b2YgQmlzb24uICAqLwogCkBAIC00Nyw3ICs0NCw3IEBACiAjZGVmaW5lIFlZQklTT04gMQogCiAv
KiBCaXNvbiB2ZXJzaW9uLiAgKi8KLSNkZWZpbmUgWVlCSVNPTl9WRVJTSU9OICIyLjMiCisjZGVm
aW5lIFlZQklTT05fVkVSU0lPTiAiMi41IgogCiAvKiBTa2VsZXRvbiBuYW1lLiAgKi8KICNkZWZp
bmUgWVlTS0VMRVRPTl9OQU1FICJ5YWNjLmMiCkBAIC01NSw0MSArNTIsMjggQEAKIC8qIFB1cmUg
cGFyc2Vycy4gICovCiAjZGVmaW5lIFlZUFVSRSAxCiAKKy8qIFB1c2ggcGFyc2Vycy4gICovCisj
ZGVmaW5lIFlZUFVTSCAwCisKKy8qIFB1bGwgcGFyc2Vycy4gICovCisjZGVmaW5lIFlZUFVMTCAx
CisKIC8qIFVzaW5nIGxvY2F0aW9ucy4gICovCiAjZGVmaW5lIFlZTFNQX05FRURFRCAxCiAKIC8q
IFN1YnN0aXR1dGUgdGhlIHZhcmlhYmxlIGFuZCBmdW5jdGlvbiBuYW1lcy4gICovCi0jZGVmaW5l
IHl5cGFyc2UgeGx1X19jZmdfeXlwYXJzZQotI2RlZmluZSB5eWxleCAgIHhsdV9fY2ZnX3l5bGV4
Ci0jZGVmaW5lIHl5ZXJyb3IgeGx1X19jZmdfeXllcnJvcgotI2RlZmluZSB5eWx2YWwgIHhsdV9f
Y2ZnX3l5bHZhbAotI2RlZmluZSB5eWNoYXIgIHhsdV9fY2ZnX3l5Y2hhcgotI2RlZmluZSB5eWRl
YnVnIHhsdV9fY2ZnX3l5ZGVidWcKLSNkZWZpbmUgeXluZXJycyB4bHVfX2NmZ195eW5lcnJzCi0j
ZGVmaW5lIHl5bGxvYyB4bHVfX2NmZ195eWxsb2MKLQotLyogVG9rZW5zLiAgKi8KLSNpZm5kZWYg
WVlUT0tFTlRZUEUKLSMgZGVmaW5lIFlZVE9LRU5UWVBFCi0gICAvKiBQdXQgdGhlIHRva2VucyBp
bnRvIHRoZSBzeW1ib2wgdGFibGUsIHNvIHRoYXQgR0RCIGFuZCBvdGhlciBkZWJ1Z2dlcnMKLSAg
ICAgIGtub3cgYWJvdXQgdGhlbS4gICovCi0gICBlbnVtIHl5dG9rZW50eXBlIHsKLSAgICAgSURF
TlQgPSAyNTgsCi0gICAgIFNUUklORyA9IDI1OSwKLSAgICAgTlVNQkVSID0gMjYwLAotICAgICBO
RVdMSU5FID0gMjYxCi0gICB9OwotI2VuZGlmCi0vKiBUb2tlbnMuICAqLwotI2RlZmluZSBJREVO
VCAyNTgKLSNkZWZpbmUgU1RSSU5HIDI1OQotI2RlZmluZSBOVU1CRVIgMjYwCi0jZGVmaW5lIE5F
V0xJTkUgMjYxCi0KLQotCisjZGVmaW5lIHl5cGFyc2UgICAgICAgICB4bHVfX2NmZ195eXBhcnNl
CisjZGVmaW5lIHl5bGV4ICAgICAgICAgICB4bHVfX2NmZ195eWxleAorI2RlZmluZSB5eWVycm9y
ICAgICAgICAgeGx1X19jZmdfeXllcnJvcgorI2RlZmluZSB5eWx2YWwgICAgICAgICAgeGx1X19j
ZmdfeXlsdmFsCisjZGVmaW5lIHl5Y2hhciAgICAgICAgICB4bHVfX2NmZ195eWNoYXIKKyNkZWZp
bmUgeXlkZWJ1ZyAgICAgICAgIHhsdV9fY2ZnX3l5ZGVidWcKKyNkZWZpbmUgeXluZXJycyAgICAg
ICAgIHhsdV9fY2ZnX3l5bmVycnMKKyNkZWZpbmUgeXlsbG9jICAgICAgICAgIHhsdV9fY2ZnX3l5
bGxvYwogCiAvKiBDb3B5IHRoZSBmaXJzdCBwYXJ0IG9mIHVzZXIgZGVjbGFyYXRpb25zLiAgKi8K
KworLyogTGluZSAyNjggb2YgeWFjYy5jICAqLwogI2xpbmUgMTkgImxpYnhsdV9jZmdfeS55Igog
CiAjZGVmaW5lIFlZTEVYX1BBUkFNIGN0eC0+c2Nhbm5lcgpAQCAtOTcsNiArODEsOSBAQAogI2lu
Y2x1ZGUgImxpYnhsdV9jZmdfbC5oIgogCiAKKy8qIExpbmUgMjY4IG9mIHlhY2MuYyAgKi8KKyNs
aW5lIDg2ICJsaWJ4bHVfY2ZnX3kuYyIKKwogLyogRW5hYmxpbmcgdHJhY2VzLiAgKi8KICNpZm5k
ZWYgWVlERUJVRwogIyBkZWZpbmUgWVlERUJVRyAwCkBAIC0xMTUsMTkgKzEwMiw0MCBAQAogIyBk
ZWZpbmUgWVlUT0tFTl9UQUJMRSAwCiAjZW5kaWYKIAorCisvKiBUb2tlbnMuICAqLworI2lmbmRl
ZiBZWVRPS0VOVFlQRQorIyBkZWZpbmUgWVlUT0tFTlRZUEUKKyAgIC8qIFB1dCB0aGUgdG9rZW5z
IGludG8gdGhlIHN5bWJvbCB0YWJsZSwgc28gdGhhdCBHREIgYW5kIG90aGVyIGRlYnVnZ2Vycwor
ICAgICAga25vdyBhYm91dCB0aGVtLiAgKi8KKyAgIGVudW0geXl0b2tlbnR5cGUgeworICAgICBJ
REVOVCA9IDI1OCwKKyAgICAgU1RSSU5HID0gMjU5LAorICAgICBOVU1CRVIgPSAyNjAsCisgICAg
IE5FV0xJTkUgPSAyNjEKKyAgIH07CisjZW5kaWYKKworCisKICNpZiAhIGRlZmluZWQgWVlTVFlQ
RSAmJiAhIGRlZmluZWQgWVlTVFlQRV9JU19ERUNMQVJFRAogdHlwZWRlZiB1bmlvbiBZWVNUWVBF
Cit7CisKKy8qIExpbmUgMjkzIG9mIHlhY2MuYyAgKi8KICNsaW5lIDI1ICJsaWJ4bHVfY2ZnX3ku
eSIKLXsKKwogICBjaGFyICpzdHJpbmc7CiAgIFhMVV9Db25maWdTZXR0aW5nICpzZXR0aW5nOwot
fQotLyogTGluZSAxODcgb2YgeWFjYy5jLiAgKi8KLSNsaW5lIDEyNyAibGlieGx1X2NmZ195LmMi
Ci0JWVlTVFlQRTsKKworCisKKy8qIExpbmUgMjkzIG9mIHlhY2MuYyAgKi8KKyNsaW5lIDEzNSAi
bGlieGx1X2NmZ195LmMiCit9IFlZU1RZUEU7CisjIGRlZmluZSBZWVNUWVBFX0lTX1RSSVZJQUwg
MQogIyBkZWZpbmUgeXlzdHlwZSBZWVNUWVBFIC8qIG9ic29sZXNjZW50OyB3aWxsIGJlIHdpdGhk
cmF3biAqLwogIyBkZWZpbmUgWVlTVFlQRV9JU19ERUNMQVJFRCAxCi0jIGRlZmluZSBZWVNUWVBF
X0lTX1RSSVZJQUwgMQogI2VuZGlmCiAKICNpZiAhIGRlZmluZWQgWVlMVFlQRSAmJiAhIGRlZmlu
ZWQgWVlMVFlQRV9JU19ERUNMQVJFRApAQCAtMTQ3LDggKzE1NSw4IEBAIHR5cGVkZWYgc3RydWN0
IFlZTFRZUEUKIC8qIENvcHkgdGhlIHNlY29uZCBwYXJ0IG9mIHVzZXIgZGVjbGFyYXRpb25zLiAg
Ki8KIAogCi0vKiBMaW5lIDIxNiBvZiB5YWNjLmMuICAqLwotI2xpbmUgMTUyICJsaWJ4bHVfY2Zn
X3kuYyIKKy8qIExpbmUgMzQzIG9mIHlhY2MuYyAgKi8KKyNsaW5lIDE2MCAibGlieGx1X2NmZ195
LmMiCiAKICNpZmRlZiBzaG9ydAogIyB1bmRlZiBzaG9ydApAQCAtMTk4LDcgKzIwNiw3IEBAIHR5
cGVkZWYgc2hvcnQgaW50IHl5dHlwZV9pbnQxNjsKICNkZWZpbmUgWVlTSVpFX01BWElNVU0gKChZ
WVNJWkVfVCkgLTEpCiAKICNpZm5kZWYgWVlfCi0jIGlmIFlZRU5BQkxFX05MUworIyBpZiBkZWZp
bmVkIFlZRU5BQkxFX05MUyAmJiBZWUVOQUJMRV9OTFMKICMgIGlmIEVOQUJMRV9OTFMKICMgICBp
bmNsdWRlIDxsaWJpbnRsLmg+IC8qIElORlJJTkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KICMg
ICBkZWZpbmUgWVlfKG1zZ2lkKSBkZ2V0dGV4dCAoImJpc29uLXJ1bnRpbWUiLCBtc2dpZCkKQEAg
LTIyMywxNCArMjMxLDE0IEBAIHR5cGVkZWYgc2hvcnQgaW50IHl5dHlwZV9pbnQxNjsKICNpZiAo
ZGVmaW5lZCBfX1NURENfXyB8fCBkZWZpbmVkIF9fQzk5X19GVU5DX18gXAogICAgICB8fCBkZWZp
bmVkIF9fY3BsdXNwbHVzIHx8IGRlZmluZWQgX01TQ19WRVIpCiBzdGF0aWMgaW50Ci1ZWUlEIChp
bnQgaSkKK1lZSUQgKGludCB5eWkpCiAjZWxzZQogc3RhdGljIGludAotWVlJRCAoaSkKLSAgICBp
bnQgaTsKK1lZSUQgKHl5aSkKKyAgICBpbnQgeXlpOwogI2VuZGlmCiB7Ci0gIHJldHVybiBpOwor
ICByZXR1cm4geXlpOwogfQogI2VuZGlmCiAKQEAgLTI1MSwxMSArMjU5LDExIEBAIFlZSUQgKGkp
CiAjICAgIGRlZmluZSBhbGxvY2EgX2FsbG9jYQogIyAgIGVsc2UKICMgICAgZGVmaW5lIFlZU1RB
Q0tfQUxMT0MgYWxsb2NhCi0jICAgIGlmICEgZGVmaW5lZCBfQUxMT0NBX0ggJiYgISBkZWZpbmVk
IF9TVERMSUJfSCAmJiAoZGVmaW5lZCBfX1NURENfXyB8fCBkZWZpbmVkIF9fQzk5X19GVU5DX18g
XAorIyAgICBpZiAhIGRlZmluZWQgX0FMTE9DQV9IICYmICEgZGVmaW5lZCBFWElUX1NVQ0NFU1Mg
JiYgKGRlZmluZWQgX19TVERDX18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKICAgICAgfHwg
ZGVmaW5lZCBfX2NwbHVzcGx1cyB8fCBkZWZpbmVkIF9NU0NfVkVSKQogIyAgICAgaW5jbHVkZSA8
c3RkbGliLmg+IC8qIElORlJJTkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KLSMgICAgIGlmbmRl
ZiBfU1RETElCX0gKLSMgICAgICBkZWZpbmUgX1NURExJQl9IIDEKKyMgICAgIGlmbmRlZiBFWElU
X1NVQ0NFU1MKKyMgICAgICBkZWZpbmUgRVhJVF9TVUNDRVNTIDAKICMgICAgIGVuZGlmCiAjICAg
IGVuZGlmCiAjICAgZW5kaWYKQEAgLTI3OCwyNCArMjg2LDI0IEBAIFlZSUQgKGkpCiAjICBpZm5k
ZWYgWVlTVEFDS19BTExPQ19NQVhJTVVNCiAjICAgZGVmaW5lIFlZU1RBQ0tfQUxMT0NfTUFYSU1V
TSBZWVNJWkVfTUFYSU1VTQogIyAgZW5kaWYKLSMgIGlmIChkZWZpbmVkIF9fY3BsdXNwbHVzICYm
ICEgZGVmaW5lZCBfU1RETElCX0ggXAorIyAgaWYgKGRlZmluZWQgX19jcGx1c3BsdXMgJiYgISBk
ZWZpbmVkIEVYSVRfU1VDQ0VTUyBcCiAgICAgICAgJiYgISAoKGRlZmluZWQgWVlNQUxMT0MgfHwg
ZGVmaW5lZCBtYWxsb2MpIFwKIAkgICAgICYmIChkZWZpbmVkIFlZRlJFRSB8fCBkZWZpbmVkIGZy
ZWUpKSkKICMgICBpbmNsdWRlIDxzdGRsaWIuaD4gLyogSU5GUklOR0VTIE9OIFVTRVIgTkFNRSBT
UEFDRSAqLwotIyAgIGlmbmRlZiBfU1RETElCX0gKLSMgICAgZGVmaW5lIF9TVERMSUJfSCAxCisj
ICAgaWZuZGVmIEVYSVRfU1VDQ0VTUworIyAgICBkZWZpbmUgRVhJVF9TVUNDRVNTIDAKICMgICBl
bmRpZgogIyAgZW5kaWYKICMgIGlmbmRlZiBZWU1BTExPQwogIyAgIGRlZmluZSBZWU1BTExPQyBt
YWxsb2MKLSMgICBpZiAhIGRlZmluZWQgbWFsbG9jICYmICEgZGVmaW5lZCBfU1RETElCX0ggJiYg
KGRlZmluZWQgX19TVERDX18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKKyMgICBpZiAhIGRl
ZmluZWQgbWFsbG9jICYmICEgZGVmaW5lZCBFWElUX1NVQ0NFU1MgJiYgKGRlZmluZWQgX19TVERD
X18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKICAgICAgfHwgZGVmaW5lZCBfX2NwbHVzcGx1
cyB8fCBkZWZpbmVkIF9NU0NfVkVSKQogdm9pZCAqbWFsbG9jIChZWVNJWkVfVCk7IC8qIElORlJJ
TkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KICMgICBlbmRpZgogIyAgZW5kaWYKICMgIGlmbmRl
ZiBZWUZSRUUKICMgICBkZWZpbmUgWVlGUkVFIGZyZWUKLSMgICBpZiAhIGRlZmluZWQgZnJlZSAm
JiAhIGRlZmluZWQgX1NURExJQl9IICYmIChkZWZpbmVkIF9fU1REQ19fIHx8IGRlZmluZWQgX19D
OTlfX0ZVTkNfXyBcCisjICAgaWYgISBkZWZpbmVkIGZyZWUgJiYgISBkZWZpbmVkIEVYSVRfU1VD
Q0VTUyAmJiAoZGVmaW5lZCBfX1NURENfXyB8fCBkZWZpbmVkIF9fQzk5X19GVU5DX18gXAogICAg
ICB8fCBkZWZpbmVkIF9fY3BsdXNwbHVzIHx8IGRlZmluZWQgX01TQ19WRVIpCiB2b2lkIGZyZWUg
KHZvaWQgKik7IC8qIElORlJJTkdFUyBPTiBVU0VSIE5BTUUgU1BBQ0UgKi8KICMgICBlbmRpZgpA
QCAtMzEyLDkgKzMyMCw5IEBAIHZvaWQgZnJlZSAodm9pZCAqKTsgLyogSU5GUklOR0VTIE9OIFVT
RVIKIC8qIEEgdHlwZSB0aGF0IGlzIHByb3Blcmx5IGFsaWduZWQgZm9yIGFueSBzdGFjayBtZW1i
ZXIuICAqLwogdW5pb24geXlhbGxvYwogewotICB5eXR5cGVfaW50MTYgeXlzczsKLSAgWVlTVFlQ
RSB5eXZzOwotICAgIFlZTFRZUEUgeXlsczsKKyAgeXl0eXBlX2ludDE2IHl5c3NfYWxsb2M7Cisg
IFlZU1RZUEUgeXl2c19hbGxvYzsKKyAgWVlMVFlQRSB5eWxzX2FsbG9jOwogfTsKIAogLyogVGhl
IHNpemUgb2YgdGhlIG1heGltdW0gZ2FwIGJldHdlZW4gb25lIGFsaWduZWQgc3RhY2sgYW5kIHRo
ZSBuZXh0LiAgKi8KQEAgLTMyNiw2ICszMzQsMjcgQEAgdW5pb24geXlhbGxvYwogICAgICAoKE4p
ICogKHNpemVvZiAoeXl0eXBlX2ludDE2KSArIHNpemVvZiAoWVlTVFlQRSkgKyBzaXplb2YgKFlZ
TFRZUEUpKSBcCiAgICAgICArIDIgKiBZWVNUQUNLX0dBUF9NQVhJTVVNKQogCisjIGRlZmluZSBZ
WUNPUFlfTkVFREVEIDEKKworLyogUmVsb2NhdGUgU1RBQ0sgZnJvbSBpdHMgb2xkIGxvY2F0aW9u
IHRvIHRoZSBuZXcgb25lLiAgVGhlCisgICBsb2NhbCB2YXJpYWJsZXMgWVlTSVpFIGFuZCBZWVNU
QUNLU0laRSBnaXZlIHRoZSBvbGQgYW5kIG5ldyBudW1iZXIgb2YKKyAgIGVsZW1lbnRzIGluIHRo
ZSBzdGFjaywgYW5kIFlZUFRSIGdpdmVzIHRoZSBuZXcgbG9jYXRpb24gb2YgdGhlCisgICBzdGFj
ay4gIEFkdmFuY2UgWVlQVFIgdG8gYSBwcm9wZXJseSBhbGlnbmVkIGxvY2F0aW9uIGZvciB0aGUg
bmV4dAorICAgc3RhY2suICAqLworIyBkZWZpbmUgWVlTVEFDS19SRUxPQ0FURShTdGFja19hbGxv
YywgU3RhY2spCQkJCVwKKyAgICBkbwkJCQkJCQkJCVwKKyAgICAgIHsJCQkJCQkJCQlcCisJWVlT
SVpFX1QgeXluZXdieXRlczsJCQkJCQlcCisJWVlDT1BZICgmeXlwdHItPlN0YWNrX2FsbG9jLCBT
dGFjaywgeXlzaXplKTsJCQlcCisJU3RhY2sgPSAmeXlwdHItPlN0YWNrX2FsbG9jOwkJCQkJXAor
CXl5bmV3Ynl0ZXMgPSB5eXN0YWNrc2l6ZSAqIHNpemVvZiAoKlN0YWNrKSArIFlZU1RBQ0tfR0FQ
X01BWElNVU07IFwKKwl5eXB0ciArPSB5eW5ld2J5dGVzIC8gc2l6ZW9mICgqeXlwdHIpOwkJCQlc
CisgICAgICB9CQkJCQkJCQkJXAorICAgIHdoaWxlIChZWUlEICgwKSkKKworI2VuZGlmCisKKyNp
ZiBkZWZpbmVkIFlZQ09QWV9ORUVERUQgJiYgWVlDT1BZX05FRURFRAogLyogQ29weSBDT1VOVCBv
YmplY3RzIGZyb20gRlJPTSB0byBUTy4gIFRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGRvCiAg
ICBub3Qgb3ZlcmxhcC4gICovCiAjIGlmbmRlZiBZWUNPUFkKQEAgLTM0MywyNCArMzcyLDcgQEAg
dW5pb24geXlhbGxvYwogICAgICAgd2hpbGUgKFlZSUQgKDApKQogIyAgZW5kaWYKICMgZW5kaWYK
LQotLyogUmVsb2NhdGUgU1RBQ0sgZnJvbSBpdHMgb2xkIGxvY2F0aW9uIHRvIHRoZSBuZXcgb25l
LiAgVGhlCi0gICBsb2NhbCB2YXJpYWJsZXMgWVlTSVpFIGFuZCBZWVNUQUNLU0laRSBnaXZlIHRo
ZSBvbGQgYW5kIG5ldyBudW1iZXIgb2YKLSAgIGVsZW1lbnRzIGluIHRoZSBzdGFjaywgYW5kIFlZ
UFRSIGdpdmVzIHRoZSBuZXcgbG9jYXRpb24gb2YgdGhlCi0gICBzdGFjay4gIEFkdmFuY2UgWVlQ
VFIgdG8gYSBwcm9wZXJseSBhbGlnbmVkIGxvY2F0aW9uIGZvciB0aGUgbmV4dAotICAgc3RhY2su
ICAqLwotIyBkZWZpbmUgWVlTVEFDS19SRUxPQ0FURShTdGFjaykJCQkJCVwKLSAgICBkbwkJCQkJ
CQkJCVwKLSAgICAgIHsJCQkJCQkJCQlcCi0JWVlTSVpFX1QgeXluZXdieXRlczsJCQkJCQlcCi0J
WVlDT1BZICgmeXlwdHItPlN0YWNrLCBTdGFjaywgeXlzaXplKTsJCQkJXAotCVN0YWNrID0gJnl5
cHRyLT5TdGFjazsJCQkJCQlcCi0JeXluZXdieXRlcyA9IHl5c3RhY2tzaXplICogc2l6ZW9mICgq
U3RhY2spICsgWVlTVEFDS19HQVBfTUFYSU1VTTsgXAotCXl5cHRyICs9IHl5bmV3Ynl0ZXMgLyBz
aXplb2YgKCp5eXB0cik7CQkJCVwKLSAgICAgIH0JCQkJCQkJCQlcCi0gICAgd2hpbGUgKFlZSUQg
KDApKQotCi0jZW5kaWYKKyNlbmRpZiAvKiAhWVlDT1BZX05FRURFRCAqLwogCiAvKiBZWUZJTkFM
IC0tIFN0YXRlIG51bWJlciBvZiB0aGUgdGVybWluYXRpb24gc3RhdGUuICAqLwogI2RlZmluZSBZ
WUZJTkFMICAyCkBAIC00NTEsNyArNDYzLDcgQEAgc3RhdGljIGNvbnN0IHl5dHlwZV91aW50OCB5
eXJsaW5lW10gPQogc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IHl5dG5hbWVbXSA9CiB7CiAgICIk
ZW5kIiwgImVycm9yIiwgIiR1bmRlZmluZWQiLCAiSURFTlQiLCAiU1RSSU5HIiwgIk5VTUJFUiIs
ICJORVdMSU5FIiwKLSAgIic9JyIsICInOyciLCAiJ1snIiwgIiddJyIsICInLCciLCAiJGFjY2Vw
dCIsICJmaWxlIiwgInNldHRpbmciLCAiQDEiLAorICAiJz0nIiwgIic7JyIsICInWyciLCAiJ10n
IiwgIicsJyIsICIkYWNjZXB0IiwgImZpbGUiLCAic2V0dGluZyIsICIkQDEiLAogICAiZW5kc3Rt
dCIsICJ2YWx1ZSIsICJhdG9tIiwgInZhbHVlbGlzdCIsICJ2YWx1ZXMiLCAibmxvayIsIDAKIH07
CiAjZW5kaWYKQEAgLTQ4Miw4ICs0OTQsOCBAQCBzdGF0aWMgY29uc3QgeXl0eXBlX3VpbnQ4IHl5
cjJbXSA9CiAgICAgICAgMgogfTsKIAotLyogWVlERUZBQ1RbU1RBVEUtTkFNRV0gLS0gRGVmYXVs
dCBydWxlIHRvIHJlZHVjZSB3aXRoIGluIHN0YXRlCi0gICBTVEFURS1OVU0gd2hlbiBZWVRBQkxF
IGRvZXNuJ3Qgc3BlY2lmeSBzb21ldGhpbmcgZWxzZSB0byBkby4gIFplcm8KKy8qIFlZREVGQUNU
W1NUQVRFLU5BTUVdIC0tIERlZmF1bHQgcmVkdWN0aW9uIG51bWJlciBpbiBzdGF0ZSBTVEFURS1O
VU0uCisgICBQZXJmb3JtZWQgd2hlbiBZWVRBQkxFIGRvZXNuJ3Qgc3BlY2lmeSBzb21ldGhpbmcg
ZWxzZSB0byBkby4gIFplcm8KICAgIG1lYW5zIHRoZSBkZWZhdWx0IGlzIGFuIGVycm9yLiAgKi8K
IHN0YXRpYyBjb25zdCB5eXR5cGVfdWludDggeXlkZWZhY3RbXSA9CiB7CkBAIC01MTYsOCArNTI4
LDcgQEAgc3RhdGljIGNvbnN0IHl5dHlwZV9pbnQ4IHl5cGdvdG9bXSA9CiAKIC8qIFlZVEFCTEVb
WVlQQUNUW1NUQVRFLU5VTV1dLiAgV2hhdCB0byBkbyBpbiBzdGF0ZSBTVEFURS1OVU0uICBJZgog
ICAgcG9zaXRpdmUsIHNoaWZ0IHRoYXQgdG9rZW4uICBJZiBuZWdhdGl2ZSwgcmVkdWNlIHRoZSBy
dWxlIHdoaWNoCi0gICBudW1iZXIgaXMgdGhlIG9wcG9zaXRlLiAgSWYgemVybywgZG8gd2hhdCBZ
WURFRkFDVCBzYXlzLgotICAgSWYgWVlUQUJMRV9OSU5GLCBzeW50YXggZXJyb3IuICAqLworICAg
bnVtYmVyIGlzIHRoZSBvcHBvc2l0ZS4gIElmIFlZVEFCTEVfTklORiwgc3ludGF4IGVycm9yLiAg
Ki8KICNkZWZpbmUgWVlUQUJMRV9OSU5GIC0xCiBzdGF0aWMgY29uc3QgeXl0eXBlX3VpbnQ4IHl5
dGFibGVbXSA9CiB7CkBAIC01MjYsNiArNTM3LDEyIEBAIHN0YXRpYyBjb25zdCB5eXR5cGVfdWlu
dDggeXl0YWJsZVtdID0KICAgICAgIDI1LCAgICAyNCwgICAgMTgsICAgIDIyCiB9OwogCisjZGVm
aW5lIHl5cGFjdF92YWx1ZV9pc19kZWZhdWx0KHl5c3RhdGUpIFwKKyAgKCh5eXN0YXRlKSA9PSAo
LTE3KSkKKworI2RlZmluZSB5eXRhYmxlX3ZhbHVlX2lzX2Vycm9yKHl5dGFibGVfdmFsdWUpIFwK
KyAgWVlJRCAoMCkKKwogc3RhdGljIGNvbnN0IHl5dHlwZV91aW50OCB5eWNoZWNrW10gPQogewog
ICAgICAgMTYsICAgICAwLCAgICAgMSwgICAgIDYsICAgICAzLCAgICAxOSwgICAgIDYsICAgICA2
LCAgICAgOCwgICAgIDgsCkBAIC01NTQsOSArNTcxLDE4IEBAIHN0YXRpYyBjb25zdCB5eXR5cGVf
dWludDggeXlzdG9zW10gPQogCiAvKiBMaWtlIFlZRVJST1IgZXhjZXB0IGRvIGNhbGwgeXllcnJv
ci4gIFRoaXMgcmVtYWlucyBoZXJlIHRlbXBvcmFyaWx5CiAgICB0byBlYXNlIHRoZSB0cmFuc2l0
aW9uIHRvIHRoZSBuZXcgbWVhbmluZyBvZiBZWUVSUk9SLCBmb3IgR0NDLgotICAgT25jZSBHQ0Mg
dmVyc2lvbiAyIGhhcyBzdXBwbGFudGVkIHZlcnNpb24gMSwgdGhpcyBjYW4gZ28uICAqLworICAg
T25jZSBHQ0MgdmVyc2lvbiAyIGhhcyBzdXBwbGFudGVkIHZlcnNpb24gMSwgdGhpcyBjYW4gZ28u
ICBIb3dldmVyLAorICAgWVlGQUlMIGFwcGVhcnMgdG8gYmUgaW4gdXNlLiAgTmV2ZXJ0aGVsZXNz
LCBpdCBpcyBmb3JtYWxseSBkZXByZWNhdGVkCisgICBpbiBCaXNvbiAyLjQuMidzIE5FV1MgZW50
cnksIHdoZXJlIGEgcGxhbiB0byBwaGFzZSBpdCBvdXQgaXMKKyAgIGRpc2N1c3NlZC4gICovCiAK
ICNkZWZpbmUgWVlGQUlMCQlnb3RvIHl5ZXJybGFiCisjaWYgZGVmaW5lZCBZWUZBSUwKKyAgLyog
VGhpcyBpcyBoZXJlIHRvIHN1cHByZXNzIHdhcm5pbmdzIGZyb20gdGhlIEdDQyBjcHAncworICAg
ICAtV3VudXNlZC1tYWNyb3MuICBOb3JtYWxseSB3ZSBkb24ndCB3b3JyeSBhYm91dCB0aGF0IHdh
cm5pbmcsIGJ1dAorICAgICBzb21lIHVzZXJzIGRvLCBhbmQgd2Ugd2FudCB0byBtYWtlIGl0IGVh
c3kgZm9yIHVzZXJzIHRvIHJlbW92ZQorICAgICBZWUZBSUwgdXNlcywgd2hpY2ggd2lsbCBwcm9k
dWNlIHdhcm5pbmdzIGZyb20gQmlzb24gMi41LiAgKi8KKyNlbmRpZgogCiAjZGVmaW5lIFlZUkVD
T1ZFUklORygpICAoISF5eWVycnN0YXR1cykKIApAQCAtNTY2LDcgKzU5Miw2IEBAIGRvCQkJCQkJ
CQlcCiAgICAgewkJCQkJCQkJXAogICAgICAgeXljaGFyID0gKFRva2VuKTsJCQkJCQlcCiAgICAg
ICB5eWx2YWwgPSAoVmFsdWUpOwkJCQkJCVwKLSAgICAgIHl5dG9rZW4gPSBZWVRSQU5TTEFURSAo
eXljaGFyKTsJCQkJXAogICAgICAgWVlQT1BTVEFDSyAoMSk7CQkJCQkJXAogICAgICAgZ290byB5
eWJhY2t1cDsJCQkJCQlcCiAgICAgfQkJCQkJCQkJXApAQCAtNjEzLDcgKzYzOCw3IEBAIHdoaWxl
IChZWUlEICgwKSkKICAgIHdlIHdvbid0IGJyZWFrIHVzZXIgY29kZTogd2hlbiB0aGVzZSBhcmUg
dGhlIGxvY2F0aW9ucyB3ZSBrbm93LiAgKi8KIAogI2lmbmRlZiBZWV9MT0NBVElPTl9QUklOVAot
IyBpZiBZWUxUWVBFX0lTX1RSSVZJQUwKKyMgaWYgZGVmaW5lZCBZWUxUWVBFX0lTX1RSSVZJQUwg
JiYgWVlMVFlQRV9JU19UUklWSUFMCiAjICBkZWZpbmUgWVlfTE9DQVRJT05fUFJJTlQoRmlsZSwg
TG9jKQkJCVwKICAgICAgZnByaW50ZiAoRmlsZSwgIiVkLiVkLSVkLiVkIiwJCQlcCiAJICAgICAg
KExvYykuZmlyc3RfbGluZSwgKExvYykuZmlyc3RfY29sdW1uLAlcCkBAIC03MzIsMTcgKzc1Nywy
MCBAQCB5eV9zeW1ib2xfcHJpbnQgKHl5b3V0cHV0LCB5eXR5cGUsIHl5dmFsCiAjaWYgKGRlZmlu
ZWQgX19TVERDX18gfHwgZGVmaW5lZCBfX0M5OV9fRlVOQ19fIFwKICAgICAgfHwgZGVmaW5lZCBf
X2NwbHVzcGx1cyB8fCBkZWZpbmVkIF9NU0NfVkVSKQogc3RhdGljIHZvaWQKLXl5X3N0YWNrX3By
aW50ICh5eXR5cGVfaW50MTYgKmJvdHRvbSwgeXl0eXBlX2ludDE2ICp0b3ApCit5eV9zdGFja19w
cmludCAoeXl0eXBlX2ludDE2ICp5eWJvdHRvbSwgeXl0eXBlX2ludDE2ICp5eXRvcCkKICNlbHNl
CiBzdGF0aWMgdm9pZAoteXlfc3RhY2tfcHJpbnQgKGJvdHRvbSwgdG9wKQotICAgIHl5dHlwZV9p
bnQxNiAqYm90dG9tOwotICAgIHl5dHlwZV9pbnQxNiAqdG9wOworeXlfc3RhY2tfcHJpbnQgKHl5
Ym90dG9tLCB5eXRvcCkKKyAgICB5eXR5cGVfaW50MTYgKnl5Ym90dG9tOworICAgIHl5dHlwZV9p
bnQxNiAqeXl0b3A7CiAjZW5kaWYKIHsKICAgWVlGUFJJTlRGIChzdGRlcnIsICJTdGFjayBub3ci
KTsKLSAgZm9yICg7IGJvdHRvbSA8PSB0b3A7ICsrYm90dG9tKQotICAgIFlZRlBSSU5URiAoc3Rk
ZXJyLCAiICVkIiwgKmJvdHRvbSk7CisgIGZvciAoOyB5eWJvdHRvbSA8PSB5eXRvcDsgeXlib3R0
b20rKykKKyAgICB7CisgICAgICBpbnQgeXlib3QgPSAqeXlib3R0b207CisgICAgICBZWUZQUklO
VEYgKHN0ZGVyciwgIiAlZCIsIHl5Ym90KTsKKyAgICB9CiAgIFlZRlBSSU5URiAoc3RkZXJyLCAi
XG4iKTsKIH0KIApAQCAtNzc4LDExICs4MDYsMTEgQEAgeXlfcmVkdWNlX3ByaW50ICh5eXZzcCwg
eXlsc3AsIHl5cnVsZSwgYwogICAvKiBUaGUgc3ltYm9scyBiZWluZyByZWR1Y2VkLiAgKi8KICAg
Zm9yICh5eWkgPSAwOyB5eWkgPCB5eW5yaHM7IHl5aSsrKQogICAgIHsKLSAgICAgIGZwcmludGYg
KHN0ZGVyciwgIiAgICQlZCA9ICIsIHl5aSArIDEpOworICAgICAgWVlGUFJJTlRGIChzdGRlcnIs
ICIgICAkJWQgPSAiLCB5eWkgKyAxKTsKICAgICAgIHl5X3N5bWJvbF9wcmludCAoc3RkZXJyLCB5
eXJoc1t5eXByaHNbeXlydWxlXSArIHl5aV0sCiAJCSAgICAgICAmKHl5dnNwWyh5eWkgKyAxKSAt
ICh5eW5yaHMpXSkKIAkJICAgICAgICwgJih5eWxzcFsoeXlpICsgMSkgLSAoeXlucmhzKV0pCQkg
ICAgICAgLCBjdHgpOwotICAgICAgZnByaW50ZiAoc3RkZXJyLCAiXG4iKTsKKyAgICAgIFlZRlBS
SU5URiAoc3RkZXJyLCAiXG4iKTsKICAgICB9CiB9CiAKQEAgLTgyMCw3ICs4NDgsNiBAQCBpbnQg
eXlkZWJ1ZzsKICNlbmRpZgogCiAKLQogI2lmIFlZRVJST1JfVkVSQk9TRQogCiAjIGlmbmRlZiB5
eXN0cmxlbgpAQCAtOTIyLDExNiArOTQ5LDE0MyBAQCB5eXRuYW1lcnIgKGNoYXIgKnl5cmVzLCBj
b25zdCBjaGFyICp5eXN0CiB9CiAjIGVuZGlmCiAKLS8qIENvcHkgaW50byBZWVJFU1VMVCBhbiBl
cnJvciBtZXNzYWdlIGFib3V0IHRoZSB1bmV4cGVjdGVkIHRva2VuCi0gICBZWUNIQVIgd2hpbGUg
aW4gc3RhdGUgWVlTVEFURS4gIFJldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIGNvcGllZCwKLSAg
IGluY2x1ZGluZyB0aGUgdGVybWluYXRpbmcgbnVsbCBieXRlLiAgSWYgWVlSRVNVTFQgaXMgbnVs
bCwgZG8gbm90Ci0gICBjb3B5IGFueXRoaW5nOyBqdXN0IHJldHVybiB0aGUgbnVtYmVyIG9mIGJ5
dGVzIHRoYXQgd291bGQgYmUKLSAgIGNvcGllZC4gIEFzIGEgc3BlY2lhbCBjYXNlLCByZXR1cm4g
MCBpZiBhbiBvcmRpbmFyeSAic3ludGF4IGVycm9yIgotICAgbWVzc2FnZSB3aWxsIGRvLiAgUmV0
dXJuIFlZU0laRV9NQVhJTVVNIGlmIG92ZXJmbG93IG9jY3VycyBkdXJpbmcKLSAgIHNpemUgY2Fs
Y3VsYXRpb24uICAqLwotc3RhdGljIFlZU0laRV9UCi15eXN5bnRheF9lcnJvciAoY2hhciAqeXly
ZXN1bHQsIGludCB5eXN0YXRlLCBpbnQgeXljaGFyKQorLyogQ29weSBpbnRvICpZWU1TRywgd2hp
Y2ggaXMgb2Ygc2l6ZSAqWVlNU0dfQUxMT0MsIGFuIGVycm9yIG1lc3NhZ2UKKyAgIGFib3V0IHRo
ZSB1bmV4cGVjdGVkIHRva2VuIFlZVE9LRU4gZm9yIHRoZSBzdGF0ZSBzdGFjayB3aG9zZSB0b3Ag
aXMKKyAgIFlZU1NQLgorCisgICBSZXR1cm4gMCBpZiAqWVlNU0cgd2FzIHN1Y2Nlc3NmdWxseSB3
cml0dGVuLiAgUmV0dXJuIDEgaWYgKllZTVNHIGlzCisgICBub3QgbGFyZ2UgZW5vdWdoIHRvIGhv
bGQgdGhlIG1lc3NhZ2UuICBJbiB0aGF0IGNhc2UsIGFsc28gc2V0CisgICAqWVlNU0dfQUxMT0Mg
dG8gdGhlIHJlcXVpcmVkIG51bWJlciBvZiBieXRlcy4gIFJldHVybiAyIGlmIHRoZQorICAgcmVx
dWlyZWQgbnVtYmVyIG9mIGJ5dGVzIGlzIHRvbyBsYXJnZSB0byBzdG9yZS4gICovCitzdGF0aWMg
aW50Cit5eXN5bnRheF9lcnJvciAoWVlTSVpFX1QgKnl5bXNnX2FsbG9jLCBjaGFyICoqeXltc2cs
CisgICAgICAgICAgICAgICAgeXl0eXBlX2ludDE2ICp5eXNzcCwgaW50IHl5dG9rZW4pCiB7Ci0g
IGludCB5eW4gPSB5eXBhY3RbeXlzdGF0ZV07CisgIFlZU0laRV9UIHl5c2l6ZTAgPSB5eXRuYW1l
cnIgKDAsIHl5dG5hbWVbeXl0b2tlbl0pOworICBZWVNJWkVfVCB5eXNpemUgPSB5eXNpemUwOwor
ICBZWVNJWkVfVCB5eXNpemUxOworICBlbnVtIHsgWVlFUlJPUl9WRVJCT1NFX0FSR1NfTUFYSU1V
TSA9IDUgfTsKKyAgLyogSW50ZXJuYXRpb25hbGl6ZWQgZm9ybWF0IHN0cmluZy4gKi8KKyAgY29u
c3QgY2hhciAqeXlmb3JtYXQgPSAwOworICAvKiBBcmd1bWVudHMgb2YgeXlmb3JtYXQuICovCisg
IGNoYXIgY29uc3QgKnl5YXJnW1lZRVJST1JfVkVSQk9TRV9BUkdTX01BWElNVU1dOworICAvKiBO
dW1iZXIgb2YgcmVwb3J0ZWQgdG9rZW5zIChvbmUgZm9yIHRoZSAidW5leHBlY3RlZCIsIG9uZSBw
ZXIKKyAgICAgImV4cGVjdGVkIikuICovCisgIGludCB5eWNvdW50ID0gMDsKIAotICBpZiAoISAo
WVlQQUNUX05JTkYgPCB5eW4gJiYgeXluIDw9IFlZTEFTVCkpCi0gICAgcmV0dXJuIDA7Ci0gIGVs
c2UKKyAgLyogVGhlcmUgYXJlIG1hbnkgcG9zc2liaWxpdGllcyBoZXJlIHRvIGNvbnNpZGVyOgor
ICAgICAtIEFzc3VtZSBZWUZBSUwgaXMgbm90IHVzZWQuICBJdCdzIHRvbyBmbGF3ZWQgdG8gY29u
c2lkZXIuICBTZWUKKyAgICAgICA8aHR0cDovL2xpc3RzLmdudS5vcmcvYXJjaGl2ZS9odG1sL2Jp
c29uLXBhdGNoZXMvMjAwOS0xMi9tc2cwMDAyNC5odG1sPgorICAgICAgIGZvciBkZXRhaWxzLiAg
WVlFUlJPUiBpcyBmaW5lIGFzIGl0IGRvZXMgbm90IGludm9rZSB0aGlzCisgICAgICAgZnVuY3Rp
b24uCisgICAgIC0gSWYgdGhpcyBzdGF0ZSBpcyBhIGNvbnNpc3RlbnQgc3RhdGUgd2l0aCBhIGRl
ZmF1bHQgYWN0aW9uLCB0aGVuCisgICAgICAgdGhlIG9ubHkgd2F5IHRoaXMgZnVuY3Rpb24gd2Fz
IGludm9rZWQgaXMgaWYgdGhlIGRlZmF1bHQgYWN0aW9uCisgICAgICAgaXMgYW4gZXJyb3IgYWN0
aW9uLiAgSW4gdGhhdCBjYXNlLCBkb24ndCBjaGVjayBmb3IgZXhwZWN0ZWQKKyAgICAgICB0b2tl
bnMgYmVjYXVzZSB0aGVyZSBhcmUgbm9uZS4KKyAgICAgLSBUaGUgb25seSB3YXkgdGhlcmUgY2Fu
IGJlIG5vIGxvb2thaGVhZCBwcmVzZW50IChpbiB5eWNoYXIpIGlzIGlmCisgICAgICAgdGhpcyBz
dGF0ZSBpcyBhIGNvbnNpc3RlbnQgc3RhdGUgd2l0aCBhIGRlZmF1bHQgYWN0aW9uLiAgVGh1cywK
KyAgICAgICBkZXRlY3RpbmcgdGhlIGFic2VuY2Ugb2YgYSBsb29rYWhlYWQgaXMgc3VmZmljaWVu
dCB0byBkZXRlcm1pbmUKKyAgICAgICB0aGF0IHRoZXJlIGlzIG5vIHVuZXhwZWN0ZWQgb3IgZXhw
ZWN0ZWQgdG9rZW4gdG8gcmVwb3J0LiAgSW4gdGhhdAorICAgICAgIGNhc2UsIGp1c3QgcmVwb3J0
IGEgc2ltcGxlICJzeW50YXggZXJyb3IiLgorICAgICAtIERvbid0IGFzc3VtZSB0aGVyZSBpc24n
dCBhIGxvb2thaGVhZCBqdXN0IGJlY2F1c2UgdGhpcyBzdGF0ZSBpcyBhCisgICAgICAgY29uc2lz
dGVudCBzdGF0ZSB3aXRoIGEgZGVmYXVsdCBhY3Rpb24uICBUaGVyZSBtaWdodCBoYXZlIGJlZW4g
YQorICAgICAgIHByZXZpb3VzIGluY29uc2lzdGVudCBzdGF0ZSwgY29uc2lzdGVudCBzdGF0ZSB3
aXRoIGEgbm9uLWRlZmF1bHQKKyAgICAgICBhY3Rpb24sIG9yIHVzZXIgc2VtYW50aWMgYWN0aW9u
IHRoYXQgbWFuaXB1bGF0ZWQgeXljaGFyLgorICAgICAtIE9mIGNvdXJzZSwgdGhlIGV4cGVjdGVk
IHRva2VuIGxpc3QgZGVwZW5kcyBvbiBzdGF0ZXMgdG8gaGF2ZQorICAgICAgIGNvcnJlY3QgbG9v
a2FoZWFkIGluZm9ybWF0aW9uLCBhbmQgaXQgZGVwZW5kcyBvbiB0aGUgcGFyc2VyIG5vdAorICAg
ICAgIHRvIHBlcmZvcm0gZXh0cmEgcmVkdWN0aW9ucyBhZnRlciBmZXRjaGluZyBhIGxvb2thaGVh
ZCBmcm9tIHRoZQorICAgICAgIHNjYW5uZXIgYW5kIGJlZm9yZSBkZXRlY3RpbmcgYSBzeW50YXgg
ZXJyb3IuICBUaHVzLCBzdGF0ZSBtZXJnaW5nCisgICAgICAgKGZyb20gTEFMUiBvciBJRUxSKSBh
bmQgZGVmYXVsdCByZWR1Y3Rpb25zIGNvcnJ1cHQgdGhlIGV4cGVjdGVkCisgICAgICAgdG9rZW4g
bGlzdC4gIEhvd2V2ZXIsIHRoZSBsaXN0IGlzIGNvcnJlY3QgZm9yIGNhbm9uaWNhbCBMUiB3aXRo
CisgICAgICAgb25lIGV4Y2VwdGlvbjogaXQgd2lsbCBzdGlsbCBjb250YWluIGFueSB0b2tlbiB0
aGF0IHdpbGwgbm90IGJlCisgICAgICAgYWNjZXB0ZWQgZHVlIHRvIGFuIGVycm9yIGFjdGlvbiBp
biBhIGxhdGVyIHN0YXRlLgorICAqLworICBpZiAoeXl0b2tlbiAhPSBZWUVNUFRZKQogICAgIHsK
LSAgICAgIGludCB5eXR5cGUgPSBZWVRSQU5TTEFURSAoeXljaGFyKTsKLSAgICAgIFlZU0laRV9U
IHl5c2l6ZTAgPSB5eXRuYW1lcnIgKDAsIHl5dG5hbWVbeXl0eXBlXSk7Ci0gICAgICBZWVNJWkVf
VCB5eXNpemUgPSB5eXNpemUwOwotICAgICAgWVlTSVpFX1QgeXlzaXplMTsKLSAgICAgIGludCB5
eXNpemVfb3ZlcmZsb3cgPSAwOwotICAgICAgZW51bSB7IFlZRVJST1JfVkVSQk9TRV9BUkdTX01B
WElNVU0gPSA1IH07Ci0gICAgICBjaGFyIGNvbnN0ICp5eWFyZ1tZWUVSUk9SX1ZFUkJPU0VfQVJH
U19NQVhJTVVNXTsKLSAgICAgIGludCB5eXg7CisgICAgICBpbnQgeXluID0geXlwYWN0Wyp5eXNz
cF07CisgICAgICB5eWFyZ1t5eWNvdW50KytdID0geXl0bmFtZVt5eXRva2VuXTsKKyAgICAgIGlm
ICgheXlwYWN0X3ZhbHVlX2lzX2RlZmF1bHQgKHl5bikpCisgICAgICAgIHsKKyAgICAgICAgICAv
KiBTdGFydCBZWVggYXQgLVlZTiBpZiBuZWdhdGl2ZSB0byBhdm9pZCBuZWdhdGl2ZSBpbmRleGVz
IGluCisgICAgICAgICAgICAgWVlDSEVDSy4gIEluIG90aGVyIHdvcmRzLCBza2lwIHRoZSBmaXJz
dCAtWVlOIGFjdGlvbnMgZm9yCisgICAgICAgICAgICAgdGhpcyBzdGF0ZSBiZWNhdXNlIHRoZXkg
YXJlIGRlZmF1bHQgYWN0aW9ucy4gICovCisgICAgICAgICAgaW50IHl5eGJlZ2luID0geXluIDwg
MCA/IC15eW4gOiAwOworICAgICAgICAgIC8qIFN0YXkgd2l0aGluIGJvdW5kcyBvZiBib3RoIHl5
Y2hlY2sgYW5kIHl5dG5hbWUuICAqLworICAgICAgICAgIGludCB5eWNoZWNrbGltID0gWVlMQVNU
IC0geXluICsgMTsKKyAgICAgICAgICBpbnQgeXl4ZW5kID0geXljaGVja2xpbSA8IFlZTlRPS0VO
UyA/IHl5Y2hlY2tsaW0gOiBZWU5UT0tFTlM7CisgICAgICAgICAgaW50IHl5eDsKIAotIyBpZiAw
Ci0gICAgICAvKiBUaGlzIGlzIHNvIHhnZXR0ZXh0IHNlZXMgdGhlIHRyYW5zbGF0YWJsZSBmb3Jt
YXRzIHRoYXQgYXJlCi0JIGNvbnN0cnVjdGVkIG9uIHRoZSBmbHkuICAqLwotICAgICAgWVlfKCJz
eW50YXggZXJyb3IsIHVuZXhwZWN0ZWQgJXMiKTsKLSAgICAgIFlZXygic3ludGF4IGVycm9yLCB1
bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMiKTsKLSAgICAgIFlZXygic3ludGF4IGVycm9yLCB1
bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMiKTsKLSAgICAgIFlZXygic3ludGF4IGVy
cm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMgb3IgJXMiKTsKLSAgICAgIFlZ
Xygic3ludGF4IGVycm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMgb3IgJXMg
b3IgJXMiKTsKLSMgZW5kaWYKLSAgICAgIGNoYXIgKnl5Zm10OwotICAgICAgY2hhciBjb25zdCAq
eXlmOwotICAgICAgc3RhdGljIGNoYXIgY29uc3QgeXl1bmV4cGVjdGVkW10gPSAic3ludGF4IGVy
cm9yLCB1bmV4cGVjdGVkICVzIjsKLSAgICAgIHN0YXRpYyBjaGFyIGNvbnN0IHl5ZXhwZWN0aW5n
W10gPSAiLCBleHBlY3RpbmcgJXMiOwotICAgICAgc3RhdGljIGNoYXIgY29uc3QgeXlvcltdID0g
IiBvciAlcyI7Ci0gICAgICBjaGFyIHl5Zm9ybWF0W3NpemVvZiB5eXVuZXhwZWN0ZWQKLQkJICAg
ICsgc2l6ZW9mIHl5ZXhwZWN0aW5nIC0gMQotCQkgICAgKyAoKFlZRVJST1JfVkVSQk9TRV9BUkdT
X01BWElNVU0gLSAyKQotCQkgICAgICAgKiAoc2l6ZW9mIHl5b3IgLSAxKSldOwotICAgICAgY2hh
ciBjb25zdCAqeXlwcmVmaXggPSB5eWV4cGVjdGluZzsKKyAgICAgICAgICBmb3IgKHl5eCA9IHl5
eGJlZ2luOyB5eXggPCB5eXhlbmQ7ICsreXl4KQorICAgICAgICAgICAgaWYgKHl5Y2hlY2tbeXl4
ICsgeXluXSA9PSB5eXggJiYgeXl4ICE9IFlZVEVSUk9SCisgICAgICAgICAgICAgICAgJiYgIXl5
dGFibGVfdmFsdWVfaXNfZXJyb3IgKHl5dGFibGVbeXl4ICsgeXluXSkpCisgICAgICAgICAgICAg
IHsKKyAgICAgICAgICAgICAgICBpZiAoeXljb3VudCA9PSBZWUVSUk9SX1ZFUkJPU0VfQVJHU19N
QVhJTVVNKQorICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICB5eWNvdW50
ID0gMTsKKyAgICAgICAgICAgICAgICAgICAgeXlzaXplID0geXlzaXplMDsKKyAgICAgICAgICAg
ICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgeXlh
cmdbeXljb3VudCsrXSA9IHl5dG5hbWVbeXl4XTsKKyAgICAgICAgICAgICAgICB5eXNpemUxID0g
eXlzaXplICsgeXl0bmFtZXJyICgwLCB5eXRuYW1lW3l5eF0pOworICAgICAgICAgICAgICAgIGlm
ICghICh5eXNpemUgPD0geXlzaXplMQorICAgICAgICAgICAgICAgICAgICAgICAmJiB5eXNpemUx
IDw9IFlZU1RBQ0tfQUxMT0NfTUFYSU1VTSkpCisgICAgICAgICAgICAgICAgICByZXR1cm4gMjsK
KyAgICAgICAgICAgICAgICB5eXNpemUgPSB5eXNpemUxOworICAgICAgICAgICAgICB9CisgICAg
ICAgIH0KKyAgICB9CiAKLSAgICAgIC8qIFN0YXJ0IFlZWCBhdCAtWVlOIGlmIG5lZ2F0aXZlIHRv
IGF2b2lkIG5lZ2F0aXZlIGluZGV4ZXMgaW4KLQkgWVlDSEVDSy4gICovCi0gICAgICBpbnQgeXl4
YmVnaW4gPSB5eW4gPCAwID8gLXl5biA6IDA7CisgIHN3aXRjaCAoeXljb3VudCkKKyAgICB7Cisj
IGRlZmluZSBZWUNBU0VfKE4sIFMpICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgIGNhc2Ug
TjogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICB5eWZvcm1hdCA9IFM7
ICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICBicmVhaworICAgICAgWVlDQVNFXygwLCBZ
WV8oInN5bnRheCBlcnJvciIpKTsKKyAgICAgIFlZQ0FTRV8oMSwgWVlfKCJzeW50YXggZXJyb3Is
IHVuZXhwZWN0ZWQgJXMiKSk7CisgICAgICBZWUNBU0VfKDIsIFlZXygic3ludGF4IGVycm9yLCB1
bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMiKSk7CisgICAgICBZWUNBU0VfKDMsIFlZXygic3lu
dGF4IGVycm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMiKSk7CisgICAgICBZ
WUNBU0VfKDQsIFlZXygic3ludGF4IGVycm9yLCB1bmV4cGVjdGVkICVzLCBleHBlY3RpbmcgJXMg
b3IgJXMgb3IgJXMiKSk7CisgICAgICBZWUNBU0VfKDUsIFlZXygic3ludGF4IGVycm9yLCB1bmV4
cGVjdGVkICVzLCBleHBlY3RpbmcgJXMgb3IgJXMgb3IgJXMgb3IgJXMiKSk7CisjIHVuZGVmIFlZ
Q0FTRV8KKyAgICB9CiAKLSAgICAgIC8qIFN0YXkgd2l0aGluIGJvdW5kcyBvZiBib3RoIHl5Y2hl
Y2sgYW5kIHl5dG5hbWUuICAqLwotICAgICAgaW50IHl5Y2hlY2tsaW0gPSBZWUxBU1QgLSB5eW4g
KyAxOwotICAgICAgaW50IHl5eGVuZCA9IHl5Y2hlY2tsaW0gPCBZWU5UT0tFTlMgPyB5eWNoZWNr
bGltIDogWVlOVE9LRU5TOwotICAgICAgaW50IHl5Y291bnQgPSAxOworICB5eXNpemUxID0geXlz
aXplICsgeXlzdHJsZW4gKHl5Zm9ybWF0KTsKKyAgaWYgKCEgKHl5c2l6ZSA8PSB5eXNpemUxICYm
IHl5c2l6ZTEgPD0gWVlTVEFDS19BTExPQ19NQVhJTVVNKSkKKyAgICByZXR1cm4gMjsKKyAgeXlz
aXplID0geXlzaXplMTsKIAotICAgICAgeXlhcmdbMF0gPSB5eXRuYW1lW3l5dHlwZV07Ci0gICAg
ICB5eWZtdCA9IHl5c3RwY3B5ICh5eWZvcm1hdCwgeXl1bmV4cGVjdGVkKTsKKyAgaWYgKCp5eW1z
Z19hbGxvYyA8IHl5c2l6ZSkKKyAgICB7CisgICAgICAqeXltc2dfYWxsb2MgPSAyICogeXlzaXpl
OworICAgICAgaWYgKCEgKHl5c2l6ZSA8PSAqeXltc2dfYWxsb2MKKyAgICAgICAgICAgICAmJiAq
eXltc2dfYWxsb2MgPD0gWVlTVEFDS19BTExPQ19NQVhJTVVNKSkKKyAgICAgICAgKnl5bXNnX2Fs
bG9jID0gWVlTVEFDS19BTExPQ19NQVhJTVVNOworICAgICAgcmV0dXJuIDE7CisgICAgfQogCi0g
ICAgICBmb3IgKHl5eCA9IHl5eGJlZ2luOyB5eXggPCB5eXhlbmQ7ICsreXl4KQotCWlmICh5eWNo
ZWNrW3l5eCArIHl5bl0gPT0geXl4ICYmIHl5eCAhPSBZWVRFUlJPUikKLQkgIHsKLQkgICAgaWYg
KHl5Y291bnQgPT0gWVlFUlJPUl9WRVJCT1NFX0FSR1NfTUFYSU1VTSkKLQkgICAgICB7Ci0JCXl5
Y291bnQgPSAxOwotCQl5eXNpemUgPSB5eXNpemUwOwotCQl5eWZvcm1hdFtzaXplb2YgeXl1bmV4
cGVjdGVkIC0gMV0gPSAnXDAnOwotCQlicmVhazsKLQkgICAgICB9Ci0JICAgIHl5YXJnW3l5Y291
bnQrK10gPSB5eXRuYW1lW3l5eF07Ci0JICAgIHl5c2l6ZTEgPSB5eXNpemUgKyB5eXRuYW1lcnIg
KDAsIHl5dG5hbWVbeXl4XSk7Ci0JICAgIHl5c2l6ZV9vdmVyZmxvdyB8PSAoeXlzaXplMSA8IHl5
c2l6ZSk7Ci0JICAgIHl5c2l6ZSA9IHl5c2l6ZTE7Ci0JICAgIHl5Zm10ID0geXlzdHBjcHkgKHl5
Zm10LCB5eXByZWZpeCk7Ci0JICAgIHl5cHJlZml4ID0geXlvcjsKLQkgIH0KLQotICAgICAgeXlm
ID0gWVlfKHl5Zm9ybWF0KTsKLSAgICAgIHl5c2l6ZTEgPSB5eXNpemUgKyB5eXN0cmxlbiAoeXlm
KTsKLSAgICAgIHl5c2l6ZV9vdmVyZmxvdyB8PSAoeXlzaXplMSA8IHl5c2l6ZSk7Ci0gICAgICB5
eXNpemUgPSB5eXNpemUxOwotCi0gICAgICBpZiAoeXlzaXplX292ZXJmbG93KQotCXJldHVybiBZ
WVNJWkVfTUFYSU1VTTsKLQotICAgICAgaWYgKHl5cmVzdWx0KQotCXsKLQkgIC8qIEF2b2lkIHNw
cmludGYsIGFzIHRoYXQgaW5mcmluZ2VzIG9uIHRoZSB1c2VyJ3MgbmFtZSBzcGFjZS4KLQkgICAg
IERvbid0IGhhdmUgdW5kZWZpbmVkIGJlaGF2aW9yIGV2ZW4gaWYgdGhlIHRyYW5zbGF0aW9uCi0J
ICAgICBwcm9kdWNlZCBhIHN0cmluZyB3aXRoIHRoZSB3cm9uZyBudW1iZXIgb2YgIiVzInMuICAq
LwotCSAgY2hhciAqeXlwID0geXlyZXN1bHQ7Ci0JICBpbnQgeXlpID0gMDsKLQkgIHdoaWxlICgo
Knl5cCA9ICp5eWYpICE9ICdcMCcpCi0JICAgIHsKLQkgICAgICBpZiAoKnl5cCA9PSAnJScgJiYg
eXlmWzFdID09ICdzJyAmJiB5eWkgPCB5eWNvdW50KQotCQl7Ci0JCSAgeXlwICs9IHl5dG5hbWVy
ciAoeXlwLCB5eWFyZ1t5eWkrK10pOwotCQkgIHl5ZiArPSAyOwotCQl9Ci0JICAgICAgZWxzZQot
CQl7Ci0JCSAgeXlwKys7Ci0JCSAgeXlmKys7Ci0JCX0KLQkgICAgfQotCX0KLSAgICAgIHJldHVy
biB5eXNpemU7Ci0gICAgfQorICAvKiBBdm9pZCBzcHJpbnRmLCBhcyB0aGF0IGluZnJpbmdlcyBv
biB0aGUgdXNlcidzIG5hbWUgc3BhY2UuCisgICAgIERvbid0IGhhdmUgdW5kZWZpbmVkIGJlaGF2
aW9yIGV2ZW4gaWYgdGhlIHRyYW5zbGF0aW9uCisgICAgIHByb2R1Y2VkIGEgc3RyaW5nIHdpdGgg
dGhlIHdyb25nIG51bWJlciBvZiAiJXMicy4gICovCisgIHsKKyAgICBjaGFyICp5eXAgPSAqeXlt
c2c7CisgICAgaW50IHl5aSA9IDA7CisgICAgd2hpbGUgKCgqeXlwID0gKnl5Zm9ybWF0KSAhPSAn
XDAnKQorICAgICAgaWYgKCp5eXAgPT0gJyUnICYmIHl5Zm9ybWF0WzFdID09ICdzJyAmJiB5eWkg
PCB5eWNvdW50KQorICAgICAgICB7CisgICAgICAgICAgeXlwICs9IHl5dG5hbWVyciAoeXlwLCB5
eWFyZ1t5eWkrK10pOworICAgICAgICAgIHl5Zm9ybWF0ICs9IDI7CisgICAgICAgIH0KKyAgICAg
IGVsc2UKKyAgICAgICAgeworICAgICAgICAgIHl5cCsrOworICAgICAgICAgIHl5Zm9ybWF0Kys7
CisgICAgICAgIH0KKyAgfQorICByZXR1cm4gMDsKIH0KICNlbmRpZiAvKiBZWUVSUk9SX1ZFUkJP
U0UgKi8KIAotCiAvKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLgogfCBSZWxlYXNlIHRoZSBtZW1vcnkgYXNzb2NpYXRlZCB0byB0aGlzIHN5bWJvbC4gIHwK
IGAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSovCkBAIC0x
MDYyLDM5ICsxMTE2LDY3IEBAIHl5ZGVzdHJ1Y3QgKHl5bXNnLCB5eXR5cGUsIHl5dmFsdWVwLCB5
eWwKICAgc3dpdGNoICh5eXR5cGUpCiAgICAgewogICAgICAgY2FzZSAzOiAvKiAiSURFTlQiICov
CisKKy8qIExpbmUgMTM5MSBvZiB5YWNjLmMgICovCiAjbGluZSA0MCAibGlieGx1X2NmZ195Lnki
CiAJeyBmcmVlKCh5eXZhbHVlcC0+c3RyaW5nKSk7IH07Ci0jbGluZSAxMDY4ICJsaWJ4bHVfY2Zn
X3kuYyIKKworLyogTGluZSAxMzkxIG9mIHlhY2MuYyAgKi8KKyNsaW5lIDExMjYgImxpYnhsdV9j
ZmdfeS5jIgogCWJyZWFrOwogICAgICAgY2FzZSA0OiAvKiAiU1RSSU5HIiAqLworCisvKiBMaW5l
IDEzOTEgb2YgeWFjYy5jICAqLwogI2xpbmUgNDAgImxpYnhsdV9jZmdfeS55IgogCXsgZnJlZSgo
eXl2YWx1ZXAtPnN0cmluZykpOyB9OwotI2xpbmUgMTA3MyAibGlieGx1X2NmZ195LmMiCisKKy8q
IExpbmUgMTM5MSBvZiB5YWNjLmMgICovCisjbGluZSAxMTM1ICJsaWJ4bHVfY2ZnX3kuYyIKIAli
cmVhazsKICAgICAgIGNhc2UgNTogLyogIk5VTUJFUiIgKi8KKworLyogTGluZSAxMzkxIG9mIHlh
Y2MuYyAgKi8KICNsaW5lIDQwICJsaWJ4bHVfY2ZnX3kueSIKIAl7IGZyZWUoKHl5dmFsdWVwLT5z
dHJpbmcpKTsgfTsKLSNsaW5lIDEwNzggImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDEzOTEg
b2YgeWFjYy5jICAqLworI2xpbmUgMTE0NCAibGlieGx1X2NmZ195LmMiCiAJYnJlYWs7CiAgICAg
ICBjYXNlIDE3OiAvKiAidmFsdWUiICovCisKKy8qIExpbmUgMTM5MSBvZiB5YWNjLmMgICovCiAj
bGluZSA0MyAibGlieGx1X2NmZ195LnkiCiAJeyB4bHVfX2NmZ19zZXRfZnJlZSgoeXl2YWx1ZXAt
PnNldHRpbmcpKTsgfTsKLSNsaW5lIDEwODMgImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDEz
OTEgb2YgeWFjYy5jICAqLworI2xpbmUgMTE1MyAibGlieGx1X2NmZ195LmMiCiAJYnJlYWs7CiAg
ICAgICBjYXNlIDE4OiAvKiAiYXRvbSIgKi8KKworLyogTGluZSAxMzkxIG9mIHlhY2MuYyAgKi8K
ICNsaW5lIDQwICJsaWJ4bHVfY2ZnX3kueSIKIAl7IGZyZWUoKHl5dmFsdWVwLT5zdHJpbmcpKTsg
fTsKLSNsaW5lIDEwODggImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDEzOTEgb2YgeWFjYy5j
ICAqLworI2xpbmUgMTE2MiAibGlieGx1X2NmZ195LmMiCiAJYnJlYWs7CiAgICAgICBjYXNlIDE5
OiAvKiAidmFsdWVsaXN0IiAqLworCisvKiBMaW5lIDEzOTEgb2YgeWFjYy5jICAqLwogI2xpbmUg
NDMgImxpYnhsdV9jZmdfeS55IgogCXsgeGx1X19jZmdfc2V0X2ZyZWUoKHl5dmFsdWVwLT5zZXR0
aW5nKSk7IH07Ci0jbGluZSAxMDkzICJsaWJ4bHVfY2ZnX3kuYyIKKworLyogTGluZSAxMzkxIG9m
IHlhY2MuYyAgKi8KKyNsaW5lIDExNzEgImxpYnhsdV9jZmdfeS5jIgogCWJyZWFrOwogICAgICAg
Y2FzZSAyMDogLyogInZhbHVlcyIgKi8KKworLyogTGluZSAxMzkxIG9mIHlhY2MuYyAgKi8KICNs
aW5lIDQzICJsaWJ4bHVfY2ZnX3kueSIKIAl7IHhsdV9fY2ZnX3NldF9mcmVlKCh5eXZhbHVlcC0+
c2V0dGluZykpOyB9OwotI2xpbmUgMTA5OCAibGlieGx1X2NmZ195LmMiCisKKy8qIExpbmUgMTM5
MSBvZiB5YWNjLmMgICovCisjbGluZSAxMTgwICJsaWJ4bHVfY2ZnX3kuYyIKIAlicmVhazsKIAog
ICAgICAgZGVmYXVsdDoKQEAgLTExMDQsNyArMTE4Niw2IEBAIHl5ZGVzdHJ1Y3QgKHl5bXNnLCB5
eXR5cGUsIHl5dmFsdWVwLCB5eWwKIAogCiAvKiBQcmV2ZW50IHdhcm5pbmdzIGZyb20gLVdtaXNz
aW5nLXByb3RvdHlwZXMuICAqLwotCiAjaWZkZWYgWVlQQVJTRV9QQVJBTQogI2lmIGRlZmluZWQg
X19TVERDX18gfHwgZGVmaW5lZCBfX2NwbHVzcGx1cwogaW50IHl5cGFyc2UgKHZvaWQgKllZUEFS
U0VfUEFSQU0pOwpAQCAtMTEyMCwxMCArMTIwMSw2IEBAIGludCB5eXBhcnNlICgpOwogI2VuZGlm
IC8qICEgWVlQQVJTRV9QQVJBTSAqLwogCiAKLQotCi0KLQogLyotLS0tLS0tLS0tLgogfCB5eXBh
cnNlLiAgfAogYC0tLS0tLS0tLS0qLwpAQCAtMTE1MCwyNCArMTIyNyw1OSBAQCB5eXBhcnNlIChj
dHgpCiAjZW5kaWYKICNlbmRpZgogewotICAvKiBUaGUgbG9vay1haGVhZCBzeW1ib2wuICAqLwor
LyogVGhlIGxvb2thaGVhZCBzeW1ib2wuICAqLwogaW50IHl5Y2hhcjsKIAotLyogVGhlIHNlbWFu
dGljIHZhbHVlIG9mIHRoZSBsb29rLWFoZWFkIHN5bWJvbC4gICovCisvKiBUaGUgc2VtYW50aWMg
dmFsdWUgb2YgdGhlIGxvb2thaGVhZCBzeW1ib2wuICAqLwogWVlTVFlQRSB5eWx2YWw7CiAKLS8q
IE51bWJlciBvZiBzeW50YXggZXJyb3JzIHNvIGZhci4gICovCi1pbnQgeXluZXJyczsKLS8qIExv
Y2F0aW9uIGRhdGEgZm9yIHRoZSBsb29rLWFoZWFkIHN5bWJvbC4gICovCisvKiBMb2NhdGlvbiBk
YXRhIGZvciB0aGUgbG9va2FoZWFkIHN5bWJvbC4gICovCiBZWUxUWVBFIHl5bGxvYzsKIAotICBp
bnQgeXlzdGF0ZTsKKyAgICAvKiBOdW1iZXIgb2Ygc3ludGF4IGVycm9ycyBzbyBmYXIuICAqLwor
ICAgIGludCB5eW5lcnJzOworCisgICAgaW50IHl5c3RhdGU7CisgICAgLyogTnVtYmVyIG9mIHRv
a2VucyB0byBzaGlmdCBiZWZvcmUgZXJyb3IgbWVzc2FnZXMgZW5hYmxlZC4gICovCisgICAgaW50
IHl5ZXJyc3RhdHVzOworCisgICAgLyogVGhlIHN0YWNrcyBhbmQgdGhlaXIgdG9vbHM6CisgICAg
ICAgYHl5c3MnOiByZWxhdGVkIHRvIHN0YXRlcy4KKyAgICAgICBgeXl2cyc6IHJlbGF0ZWQgdG8g
c2VtYW50aWMgdmFsdWVzLgorICAgICAgIGB5eWxzJzogcmVsYXRlZCB0byBsb2NhdGlvbnMuCisK
KyAgICAgICBSZWZlciB0byB0aGUgc3RhY2tzIHRocnUgc2VwYXJhdGUgcG9pbnRlcnMsIHRvIGFs
bG93IHl5b3ZlcmZsb3cKKyAgICAgICB0byByZWFsbG9jYXRlIHRoZW0gZWxzZXdoZXJlLiAgKi8K
KworICAgIC8qIFRoZSBzdGF0ZSBzdGFjay4gICovCisgICAgeXl0eXBlX2ludDE2IHl5c3NhW1lZ
SU5JVERFUFRIXTsKKyAgICB5eXR5cGVfaW50MTYgKnl5c3M7CisgICAgeXl0eXBlX2ludDE2ICp5
eXNzcDsKKworICAgIC8qIFRoZSBzZW1hbnRpYyB2YWx1ZSBzdGFjay4gICovCisgICAgWVlTVFlQ
RSB5eXZzYVtZWUlOSVRERVBUSF07CisgICAgWVlTVFlQRSAqeXl2czsKKyAgICBZWVNUWVBFICp5
eXZzcDsKKworICAgIC8qIFRoZSBsb2NhdGlvbiBzdGFjay4gICovCisgICAgWVlMVFlQRSB5eWxz
YVtZWUlOSVRERVBUSF07CisgICAgWVlMVFlQRSAqeXlsczsKKyAgICBZWUxUWVBFICp5eWxzcDsK
KworICAgIC8qIFRoZSBsb2NhdGlvbnMgd2hlcmUgdGhlIGVycm9yIHN0YXJ0ZWQgYW5kIGVuZGVk
LiAgKi8KKyAgICBZWUxUWVBFIHl5ZXJyb3JfcmFuZ2VbM107CisKKyAgICBZWVNJWkVfVCB5eXN0
YWNrc2l6ZTsKKwogICBpbnQgeXluOwogICBpbnQgeXlyZXN1bHQ7Ci0gIC8qIE51bWJlciBvZiB0
b2tlbnMgdG8gc2hpZnQgYmVmb3JlIGVycm9yIG1lc3NhZ2VzIGVuYWJsZWQuICAqLwotICBpbnQg
eXllcnJzdGF0dXM7Ci0gIC8qIExvb2stYWhlYWQgdG9rZW4gYXMgYW4gaW50ZXJuYWwgKHRyYW5z
bGF0ZWQpIHRva2VuIG51bWJlci4gICovCi0gIGludCB5eXRva2VuID0gMDsKKyAgLyogTG9va2Fo
ZWFkIHRva2VuIGFzIGFuIGludGVybmFsICh0cmFuc2xhdGVkKSB0b2tlbiBudW1iZXIuICAqLwor
ICBpbnQgeXl0b2tlbjsKKyAgLyogVGhlIHZhcmlhYmxlcyB1c2VkIHRvIHJldHVybiBzZW1hbnRp
YyB2YWx1ZSBhbmQgbG9jYXRpb24gZnJvbSB0aGUKKyAgICAgYWN0aW9uIHJvdXRpbmVzLiAgKi8K
KyAgWVlTVFlQRSB5eXZhbDsKKyAgWVlMVFlQRSB5eWxvYzsKKwogI2lmIFlZRVJST1JfVkVSQk9T
RQogICAvKiBCdWZmZXIgZm9yIGVycm9yIG1lc3NhZ2VzLCBhbmQgaXRzIGFsbG9jYXRlZCBzaXpl
LiAgKi8KICAgY2hhciB5eW1zZ2J1ZlsxMjhdOwpAQCAtMTE3NSw2MyArMTI4NywzNyBAQCBZWUxU
WVBFIHl5bGxvYzsKICAgWVlTSVpFX1QgeXltc2dfYWxsb2MgPSBzaXplb2YgeXltc2didWY7CiAj
ZW5kaWYKIAotICAvKiBUaHJlZSBzdGFja3MgYW5kIHRoZWlyIHRvb2xzOgotICAgICBgeXlzcyc6
IHJlbGF0ZWQgdG8gc3RhdGVzLAotICAgICBgeXl2cyc6IHJlbGF0ZWQgdG8gc2VtYW50aWMgdmFs
dWVzLAotICAgICBgeXlscyc6IHJlbGF0ZWQgdG8gbG9jYXRpb25zLgotCi0gICAgIFJlZmVyIHRv
IHRoZSBzdGFja3MgdGhydSBzZXBhcmF0ZSBwb2ludGVycywgdG8gYWxsb3cgeXlvdmVyZmxvdwot
ICAgICB0byByZWFsbG9jYXRlIHRoZW0gZWxzZXdoZXJlLiAgKi8KLQotICAvKiBUaGUgc3RhdGUg
c3RhY2suICAqLwotICB5eXR5cGVfaW50MTYgeXlzc2FbWVlJTklUREVQVEhdOwotICB5eXR5cGVf
aW50MTYgKnl5c3MgPSB5eXNzYTsKLSAgeXl0eXBlX2ludDE2ICp5eXNzcDsKLQotICAvKiBUaGUg
c2VtYW50aWMgdmFsdWUgc3RhY2suICAqLwotICBZWVNUWVBFIHl5dnNhW1lZSU5JVERFUFRIXTsK
LSAgWVlTVFlQRSAqeXl2cyA9IHl5dnNhOwotICBZWVNUWVBFICp5eXZzcDsKLQotICAvKiBUaGUg
bG9jYXRpb24gc3RhY2suICAqLwotICBZWUxUWVBFIHl5bHNhW1lZSU5JVERFUFRIXTsKLSAgWVlM
VFlQRSAqeXlscyA9IHl5bHNhOwotICBZWUxUWVBFICp5eWxzcDsKLSAgLyogVGhlIGxvY2F0aW9u
cyB3aGVyZSB0aGUgZXJyb3Igc3RhcnRlZCBhbmQgZW5kZWQuICAqLwotICBZWUxUWVBFIHl5ZXJy
b3JfcmFuZ2VbMl07Ci0KICNkZWZpbmUgWVlQT1BTVEFDSyhOKSAgICh5eXZzcCAtPSAoTiksIHl5
c3NwIC09IChOKSwgeXlsc3AgLT0gKE4pKQogCi0gIFlZU0laRV9UIHl5c3RhY2tzaXplID0gWVlJ
TklUREVQVEg7Ci0KLSAgLyogVGhlIHZhcmlhYmxlcyB1c2VkIHRvIHJldHVybiBzZW1hbnRpYyB2
YWx1ZSBhbmQgbG9jYXRpb24gZnJvbSB0aGUKLSAgICAgYWN0aW9uIHJvdXRpbmVzLiAgKi8KLSAg
WVlTVFlQRSB5eXZhbDsKLSAgWVlMVFlQRSB5eWxvYzsKLQogICAvKiBUaGUgbnVtYmVyIG9mIHN5
bWJvbHMgb24gdGhlIFJIUyBvZiB0aGUgcmVkdWNlZCBydWxlLgogICAgICBLZWVwIHRvIHplcm8g
d2hlbiBubyBzeW1ib2wgc2hvdWxkIGJlIHBvcHBlZC4gICovCiAgIGludCB5eWxlbiA9IDA7CiAK
KyAgeXl0b2tlbiA9IDA7CisgIHl5c3MgPSB5eXNzYTsKKyAgeXl2cyA9IHl5dnNhOworICB5eWxz
ID0geXlsc2E7CisgIHl5c3RhY2tzaXplID0gWVlJTklUREVQVEg7CisKICAgWVlEUFJJTlRGICgo
c3RkZXJyLCAiU3RhcnRpbmcgcGFyc2VcbiIpKTsKIAogICB5eXN0YXRlID0gMDsKICAgeXllcnJz
dGF0dXMgPSAwOwogICB5eW5lcnJzID0gMDsKLSAgeXljaGFyID0gWVlFTVBUWTsJCS8qIENhdXNl
IGEgdG9rZW4gdG8gYmUgcmVhZC4gICovCisgIHl5Y2hhciA9IFlZRU1QVFk7IC8qIENhdXNlIGEg
dG9rZW4gdG8gYmUgcmVhZC4gICovCiAKICAgLyogSW5pdGlhbGl6ZSBzdGFjayBwb2ludGVycy4K
ICAgICAgV2FzdGUgb25lIGVsZW1lbnQgb2YgdmFsdWUgYW5kIGxvY2F0aW9uIHN0YWNrCiAgICAg
IHNvIHRoYXQgdGhleSBzdGF5IG9uIHRoZSBzYW1lIGxldmVsIGFzIHRoZSBzdGF0ZSBzdGFjay4K
ICAgICAgVGhlIHdhc3RlZCBlbGVtZW50cyBhcmUgbmV2ZXIgaW5pdGlhbGl6ZWQuICAqLwotCiAg
IHl5c3NwID0geXlzczsKICAgeXl2c3AgPSB5eXZzOwogICB5eWxzcCA9IHl5bHM7Ci0jaWYgWVlM
VFlQRV9JU19UUklWSUFMCisKKyNpZiBkZWZpbmVkIFlZTFRZUEVfSVNfVFJJVklBTCAmJiBZWUxU
WVBFX0lTX1RSSVZJQUwKICAgLyogSW5pdGlhbGl6ZSB0aGUgZGVmYXVsdCBsb2NhdGlvbiBiZWZv
cmUgcGFyc2luZyBzdGFydHMuICAqLwogICB5eWxsb2MuZmlyc3RfbGluZSAgID0geXlsbG9jLmxh
c3RfbGluZSAgID0gMTsKLSAgeXlsbG9jLmZpcnN0X2NvbHVtbiA9IHl5bGxvYy5sYXN0X2NvbHVt
biA9IDA7CisgIHl5bGxvYy5maXJzdF9jb2x1bW4gPSB5eWxsb2MubGFzdF9jb2x1bW4gPSAxOwog
I2VuZGlmCiAKICAgZ290byB5eXNldHN0YXRlOwpAQCAtMTI3MCw2ICsxMzU2LDcgQEAgWVlMVFlQ
RSB5eWxsb2M7CiAJCSAgICAmeXl2czEsIHl5c2l6ZSAqIHNpemVvZiAoKnl5dnNwKSwKIAkJICAg
ICZ5eWxzMSwgeXlzaXplICogc2l6ZW9mICgqeXlsc3ApLAogCQkgICAgJnl5c3RhY2tzaXplKTsK
KwogCXl5bHMgPSB5eWxzMTsKIAl5eXNzID0geXlzczE7CiAJeXl2cyA9IHl5dnMxOwpAQCAtMTI5
MSw5ICsxMzc4LDkgQEAgWVlMVFlQRSB5eWxsb2M7CiAJICAodW5pb24geXlhbGxvYyAqKSBZWVNU
QUNLX0FMTE9DIChZWVNUQUNLX0JZVEVTICh5eXN0YWNrc2l6ZSkpOwogCWlmICghIHl5cHRyKQog
CSAgZ290byB5eWV4aGF1c3RlZGxhYjsKLQlZWVNUQUNLX1JFTE9DQVRFICh5eXNzKTsKLQlZWVNU
QUNLX1JFTE9DQVRFICh5eXZzKTsKLQlZWVNUQUNLX1JFTE9DQVRFICh5eWxzKTsKKwlZWVNUQUNL
X1JFTE9DQVRFICh5eXNzX2FsbG9jLCB5eXNzKTsKKwlZWVNUQUNLX1JFTE9DQVRFICh5eXZzX2Fs
bG9jLCB5eXZzKTsKKwlZWVNUQUNLX1JFTE9DQVRFICh5eWxzX2FsbG9jLCB5eWxzKTsKICMgIHVu
ZGVmIFlZU1RBQ0tfUkVMT0NBVEUKIAlpZiAoeXlzczEgIT0geXlzc2EpCiAJICBZWVNUQUNLX0ZS
RUUgKHl5c3MxKTsKQEAgLTEzMTQsNiArMTQwMSw5IEBAIFlZTFRZUEUgeXlsbG9jOwogCiAgIFlZ
RFBSSU5URiAoKHN0ZGVyciwgIkVudGVyaW5nIHN0YXRlICVkXG4iLCB5eXN0YXRlKSk7CiAKKyAg
aWYgKHl5c3RhdGUgPT0gWVlGSU5BTCkKKyAgICBZWUFDQ0VQVDsKKwogICBnb3RvIHl5YmFja3Vw
OwogCiAvKi0tLS0tLS0tLS0tLgpAQCAtMTMyMiwxNiArMTQxMiwxNiBAQCBZWUxUWVBFIHl5bGxv
YzsKIHl5YmFja3VwOgogCiAgIC8qIERvIGFwcHJvcHJpYXRlIHByb2Nlc3NpbmcgZ2l2ZW4gdGhl
IGN1cnJlbnQgc3RhdGUuICBSZWFkIGEKLSAgICAgbG9vay1haGVhZCB0b2tlbiBpZiB3ZSBuZWVk
IG9uZSBhbmQgZG9uJ3QgYWxyZWFkeSBoYXZlIG9uZS4gICovCisgICAgIGxvb2thaGVhZCB0b2tl
biBpZiB3ZSBuZWVkIG9uZSBhbmQgZG9uJ3QgYWxyZWFkeSBoYXZlIG9uZS4gICovCiAKLSAgLyog
Rmlyc3QgdHJ5IHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGhvdXQgcmVmZXJlbmNlIHRvIGxvb2st
YWhlYWQgdG9rZW4uICAqLworICAvKiBGaXJzdCB0cnkgdG8gZGVjaWRlIHdoYXQgdG8gZG8gd2l0
aG91dCByZWZlcmVuY2UgdG8gbG9va2FoZWFkIHRva2VuLiAgKi8KICAgeXluID0geXlwYWN0W3l5
c3RhdGVdOwotICBpZiAoeXluID09IFlZUEFDVF9OSU5GKQorICBpZiAoeXlwYWN0X3ZhbHVlX2lz
X2RlZmF1bHQgKHl5bikpCiAgICAgZ290byB5eWRlZmF1bHQ7CiAKLSAgLyogTm90IGtub3duID0+
IGdldCBhIGxvb2stYWhlYWQgdG9rZW4gaWYgZG9uJ3QgYWxyZWFkeSBoYXZlIG9uZS4gICovCisg
IC8qIE5vdCBrbm93biA9PiBnZXQgYSBsb29rYWhlYWQgdG9rZW4gaWYgZG9uJ3QgYWxyZWFkeSBo
YXZlIG9uZS4gICovCiAKLSAgLyogWVlDSEFSIGlzIGVpdGhlciBZWUVNUFRZIG9yIFlZRU9GIG9y
IGEgdmFsaWQgbG9vay1haGVhZCBzeW1ib2wuICAqLworICAvKiBZWUNIQVIgaXMgZWl0aGVyIFlZ
RU1QVFkgb3IgWVlFT0Ygb3IgYSB2YWxpZCBsb29rYWhlYWQgc3ltYm9sLiAgKi8KICAgaWYgKHl5
Y2hhciA9PSBZWUVNUFRZKQogICAgIHsKICAgICAgIFlZRFBSSU5URiAoKHN0ZGVyciwgIlJlYWRp
bmcgYSB0b2tlbjogIikpOwpAQCAtMTM1NywyNiArMTQ0NywyMiBAQCB5eWJhY2t1cDoKICAgeXlu
ID0geXl0YWJsZVt5eW5dOwogICBpZiAoeXluIDw9IDApCiAgICAgewotICAgICAgaWYgKHl5biA9
PSAwIHx8IHl5biA9PSBZWVRBQkxFX05JTkYpCi0JZ290byB5eWVycmxhYjsKKyAgICAgIGlmICh5
eXRhYmxlX3ZhbHVlX2lzX2Vycm9yICh5eW4pKQorICAgICAgICBnb3RvIHl5ZXJybGFiOwogICAg
ICAgeXluID0gLXl5bjsKICAgICAgIGdvdG8geXlyZWR1Y2U7CiAgICAgfQogCi0gIGlmICh5eW4g
PT0gWVlGSU5BTCkKLSAgICBZWUFDQ0VQVDsKLQogICAvKiBDb3VudCB0b2tlbnMgc2hpZnRlZCBz
aW5jZSBlcnJvcjsgYWZ0ZXIgdGhyZWUsIHR1cm4gb2ZmIGVycm9yCiAgICAgIHN0YXR1cy4gICov
CiAgIGlmICh5eWVycnN0YXR1cykKICAgICB5eWVycnN0YXR1cy0tOwogCi0gIC8qIFNoaWZ0IHRo
ZSBsb29rLWFoZWFkIHRva2VuLiAgKi8KKyAgLyogU2hpZnQgdGhlIGxvb2thaGVhZCB0b2tlbi4g
ICovCiAgIFlZX1NZTUJPTF9QUklOVCAoIlNoaWZ0aW5nIiwgeXl0b2tlbiwgJnl5bHZhbCwgJnl5
bGxvYyk7CiAKLSAgLyogRGlzY2FyZCB0aGUgc2hpZnRlZCB0b2tlbiB1bmxlc3MgaXQgaXMgZW9m
LiAgKi8KLSAgaWYgKHl5Y2hhciAhPSBZWUVPRikKLSAgICB5eWNoYXIgPSBZWUVNUFRZOworICAv
KiBEaXNjYXJkIHRoZSBzaGlmdGVkIHRva2VuLiAgKi8KKyAgeXljaGFyID0gWVlFTVBUWTsKIAog
ICB5eXN0YXRlID0geXluOwogICAqKyt5eXZzcCA9IHl5bHZhbDsKQEAgLTE0MTcsNjAgKzE1MDMs
OTIgQEAgeXlyZWR1Y2U6CiAgIHN3aXRjaCAoeXluKQogICAgIHsKICAgICAgICAgY2FzZSA0Ogor
CisvKiBMaW5lIDE4MDYgb2YgeWFjYy5jICAqLwogI2xpbmUgNTAgImxpYnhsdV9jZmdfeS55Igot
ICAgIHsgeGx1X19jZmdfc2V0X3N0b3JlKGN0eCwoeXl2c3BbKDEpIC0gKDMpXS5zdHJpbmcpLCh5
eXZzcFsoMykgLSAoMyldLnNldHRpbmcpLCh5eWxzcFsoMykgLSAoMyldKS5maXJzdF9saW5lKTsg
O30KKyAgICB7IHhsdV9fY2ZnX3NldF9zdG9yZShjdHgsKHl5dnNwWygxKSAtICgzKV0uc3RyaW5n
KSwoeXl2c3BbKDMpIC0gKDMpXS5zZXR0aW5nKSwoeXlsc3BbKDMpIC0gKDMpXSkuZmlyc3RfbGlu
ZSk7IH0KICAgICBicmVhazsKIAogICBjYXNlIDEwOgorCisvKiBMaW5lIDE4MDYgb2YgeWFjYy5j
ICAqLwogI2xpbmUgNTggImxpYnhsdV9jZmdfeS55IgotICAgIHsgKHl5dmFsLnNldHRpbmcpPSB4
bHVfX2NmZ19zZXRfbWsoY3R4LDEsKHl5dnNwWygxKSAtICgxKV0uc3RyaW5nKSk7IDt9CisgICAg
eyAoeXl2YWwuc2V0dGluZyk9IHhsdV9fY2ZnX3NldF9tayhjdHgsMSwoeXl2c3BbKDEpIC0gKDEp
XS5zdHJpbmcpKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2UgMTE6CisKKy8qIExpbmUgMTgwNiBv
ZiB5YWNjLmMgICovCiAjbGluZSA1OSAibGlieGx1X2NmZ195LnkiCi0gICAgeyAoeXl2YWwuc2V0
dGluZyk9ICh5eXZzcFsoMykgLSAoNCldLnNldHRpbmcpOyA7fQorICAgIHsgKHl5dmFsLnNldHRp
bmcpPSAoeXl2c3BbKDMpIC0gKDQpXS5zZXR0aW5nKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2Ug
MTI6CisKKy8qIExpbmUgMTgwNiBvZiB5YWNjLmMgICovCiAjbGluZSA2MSAibGlieGx1X2NmZ195
LnkiCi0gICAgeyAoeXl2YWwuc3RyaW5nKT0gKHl5dnNwWygxKSAtICgxKV0uc3RyaW5nKTsgO30K
KyAgICB7ICh5eXZhbC5zdHJpbmcpPSAoeXl2c3BbKDEpIC0gKDEpXS5zdHJpbmcpOyB9CiAgICAg
YnJlYWs7CiAKICAgY2FzZSAxMzoKKworLyogTGluZSAxODA2IG9mIHlhY2MuYyAgKi8KICNsaW5l
IDYyICJsaWJ4bHVfY2ZnX3kueSIKLSAgICB7ICh5eXZhbC5zdHJpbmcpPSAoeXl2c3BbKDEpIC0g
KDEpXS5zdHJpbmcpOyA7fQorICAgIHsgKHl5dmFsLnN0cmluZyk9ICh5eXZzcFsoMSkgLSAoMSld
LnN0cmluZyk7IH0KICAgICBicmVhazsKIAogICBjYXNlIDE0OgorCisvKiBMaW5lIDE4MDYgb2Yg
eWFjYy5jICAqLwogI2xpbmUgNjQgImxpYnhsdV9jZmdfeS55IgotICAgIHsgKHl5dmFsLnNldHRp
bmcpPSB4bHVfX2NmZ19zZXRfbWsoY3R4LDAsMCk7IDt9CisgICAgeyAoeXl2YWwuc2V0dGluZyk9
IHhsdV9fY2ZnX3NldF9tayhjdHgsMCwwKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2UgMTU6CisK
Ky8qIExpbmUgMTgwNiBvZiB5YWNjLmMgICovCiAjbGluZSA2NSAibGlieGx1X2NmZ195LnkiCi0g
ICAgeyAoeXl2YWwuc2V0dGluZyk9ICh5eXZzcFsoMSkgLSAoMSldLnNldHRpbmcpOyA7fQorICAg
IHsgKHl5dmFsLnNldHRpbmcpPSAoeXl2c3BbKDEpIC0gKDEpXS5zZXR0aW5nKTsgfQogICAgIGJy
ZWFrOwogCiAgIGNhc2UgMTY6CisKKy8qIExpbmUgMTgwNiBvZiB5YWNjLmMgICovCiAjbGluZSA2
NiAibGlieGx1X2NmZ195LnkiCi0gICAgeyAoeXl2YWwuc2V0dGluZyk9ICh5eXZzcFsoMSkgLSAo
MyldLnNldHRpbmcpOyA7fQorICAgIHsgKHl5dmFsLnNldHRpbmcpPSAoeXl2c3BbKDEpIC0gKDMp
XS5zZXR0aW5nKTsgfQogICAgIGJyZWFrOwogCiAgIGNhc2UgMTc6CisKKy8qIExpbmUgMTgwNiBv
ZiB5YWNjLmMgICovCiAjbGluZSA2OCAibGlieGx1X2NmZ195LnkiCi0gICAgeyAoeXl2YWwuc2V0
dGluZyk9IHhsdV9fY2ZnX3NldF9tayhjdHgsMiwoeXl2c3BbKDEpIC0gKDIpXS5zdHJpbmcpKTsg
O30KKyAgICB7ICh5eXZhbC5zZXR0aW5nKT0geGx1X19jZmdfc2V0X21rKGN0eCwyLCh5eXZzcFso
MSkgLSAoMildLnN0cmluZykpOyB9CiAgICAgYnJlYWs7CiAKICAgY2FzZSAxODoKKworLyogTGlu
ZSAxODA2IG9mIHlhY2MuYyAgKi8KICNsaW5lIDY5ICJsaWJ4bHVfY2ZnX3kueSIKLSAgICB7IHhs
dV9fY2ZnX3NldF9hZGQoY3R4LCh5eXZzcFsoMSkgLSAoNSldLnNldHRpbmcpLCh5eXZzcFsoNCkg
LSAoNSldLnN0cmluZykpOyAoeXl2YWwuc2V0dGluZyk9ICh5eXZzcFsoMSkgLSAoNSldLnNldHRp
bmcpOyA7fQorICAgIHsgeGx1X19jZmdfc2V0X2FkZChjdHgsKHl5dnNwWygxKSAtICg1KV0uc2V0
dGluZyksKHl5dnNwWyg0KSAtICg1KV0uc3RyaW5nKSk7ICh5eXZhbC5zZXR0aW5nKT0gKHl5dnNw
WygxKSAtICg1KV0uc2V0dGluZyk7IH0KICAgICBicmVhazsKIAogCi0vKiBMaW5lIDEyNjcgb2Yg
eWFjYy5jLiAgKi8KLSNsaW5lIDE0NzIgImxpYnhsdV9jZmdfeS5jIgorCisvKiBMaW5lIDE4MDYg
b2YgeWFjYy5jICAqLworI2xpbmUgMTU3OSAibGlieGx1X2NmZ195LmMiCiAgICAgICBkZWZhdWx0
OiBicmVhazsKICAgICB9CisgIC8qIFVzZXIgc2VtYW50aWMgYWN0aW9ucyBzb21ldGltZXMgYWx0
ZXIgeXljaGFyLCBhbmQgdGhhdCByZXF1aXJlcworICAgICB0aGF0IHl5dG9rZW4gYmUgdXBkYXRl
ZCB3aXRoIHRoZSBuZXcgdHJhbnNsYXRpb24uICBXZSB0YWtlIHRoZQorICAgICBhcHByb2FjaCBv
ZiB0cmFuc2xhdGluZyBpbW1lZGlhdGVseSBiZWZvcmUgZXZlcnkgdXNlIG9mIHl5dG9rZW4uCisg
ICAgIE9uZSBhbHRlcm5hdGl2ZSBpcyB0cmFuc2xhdGluZyBoZXJlIGFmdGVyIGV2ZXJ5IHNlbWFu
dGljIGFjdGlvbiwKKyAgICAgYnV0IHRoYXQgdHJhbnNsYXRpb24gd291bGQgYmUgbWlzc2VkIGlm
IHRoZSBzZW1hbnRpYyBhY3Rpb24gaW52b2tlcworICAgICBZWUFCT1JULCBZWUFDQ0VQVCwgb3Ig
WVlFUlJPUiBpbW1lZGlhdGVseSBhZnRlciBhbHRlcmluZyB5eWNoYXIgb3IKKyAgICAgaWYgaXQg
aW52b2tlcyBZWUJBQ0tVUC4gIEluIHRoZSBjYXNlIG9mIFlZQUJPUlQgb3IgWVlBQ0NFUFQsIGFu
CisgICAgIGluY29ycmVjdCBkZXN0cnVjdG9yIG1pZ2h0IHRoZW4gYmUgaW52b2tlZCBpbW1lZGlh
dGVseS4gIEluIHRoZQorICAgICBjYXNlIG9mIFlZRVJST1Igb3IgWVlCQUNLVVAsIHN1YnNlcXVl
bnQgcGFyc2VyIGFjdGlvbnMgbWlnaHQgbGVhZAorICAgICB0byBhbiBpbmNvcnJlY3QgZGVzdHJ1
Y3RvciBjYWxsIG9yIHZlcmJvc2Ugc3ludGF4IGVycm9yIG1lc3NhZ2UKKyAgICAgYmVmb3JlIHRo
ZSBsb29rYWhlYWQgaXMgdHJhbnNsYXRlZC4gICovCiAgIFlZX1NZTUJPTF9QUklOVCAoIi0+ICQk
ID0iLCB5eXIxW3l5bl0sICZ5eXZhbCwgJnl5bG9jKTsKIAogICBZWVBPUFNUQUNLICh5eWxlbik7
CkBAIC0xNDk5LDYgKzE2MTcsMTAgQEAgeXlyZWR1Y2U6CiB8IHl5ZXJybGFiIC0tIGhlcmUgb24g
ZGV0ZWN0aW5nIGVycm9yIHwKIGAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0q
LwogeXllcnJsYWI6CisgIC8qIE1ha2Ugc3VyZSB3ZSBoYXZlIGxhdGVzdCBsb29rYWhlYWQgdHJh
bnNsYXRpb24uICBTZWUgY29tbWVudHMgYXQKKyAgICAgdXNlciBzZW1hbnRpYyBhY3Rpb25zIGZv
ciB3aHkgdGhpcyBpcyBuZWNlc3NhcnkuICAqLworICB5eXRva2VuID0geXljaGFyID09IFlZRU1Q
VFkgPyBZWUVNUFRZIDogWVlUUkFOU0xBVEUgKHl5Y2hhcik7CisKICAgLyogSWYgbm90IGFscmVh
ZHkgcmVjb3ZlcmluZyBmcm9tIGFuIGVycm9yLCByZXBvcnQgdGhpcyBlcnJvci4gICovCiAgIGlm
ICgheXllcnJzdGF0dXMpCiAgICAgewpAQCAtMTUwNiw0NSArMTYyOCw0NCBAQCB5eWVycmxhYjoK
ICNpZiAhIFlZRVJST1JfVkVSQk9TRQogICAgICAgeXllcnJvciAoJnl5bGxvYywgY3R4LCBZWV8o
InN5bnRheCBlcnJvciIpKTsKICNlbHNlCisjIGRlZmluZSBZWVNZTlRBWF9FUlJPUiB5eXN5bnRh
eF9lcnJvciAoJnl5bXNnX2FsbG9jLCAmeXltc2csIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB5eXNzcCwgeXl0b2tlbikKICAgICAgIHsKLQlZWVNJWkVfVCB5eXNp
emUgPSB5eXN5bnRheF9lcnJvciAoMCwgeXlzdGF0ZSwgeXljaGFyKTsKLQlpZiAoeXltc2dfYWxs
b2MgPCB5eXNpemUgJiYgeXltc2dfYWxsb2MgPCBZWVNUQUNLX0FMTE9DX01BWElNVU0pCi0JICB7
Ci0JICAgIFlZU0laRV9UIHl5YWxsb2MgPSAyICogeXlzaXplOwotCSAgICBpZiAoISAoeXlzaXpl
IDw9IHl5YWxsb2MgJiYgeXlhbGxvYyA8PSBZWVNUQUNLX0FMTE9DX01BWElNVU0pKQotCSAgICAg
IHl5YWxsb2MgPSBZWVNUQUNLX0FMTE9DX01BWElNVU07Ci0JICAgIGlmICh5eW1zZyAhPSB5eW1z
Z2J1ZikKLQkgICAgICBZWVNUQUNLX0ZSRUUgKHl5bXNnKTsKLQkgICAgeXltc2cgPSAoY2hhciAq
KSBZWVNUQUNLX0FMTE9DICh5eWFsbG9jKTsKLQkgICAgaWYgKHl5bXNnKQotCSAgICAgIHl5bXNn
X2FsbG9jID0geXlhbGxvYzsKLQkgICAgZWxzZQotCSAgICAgIHsKLQkJeXltc2cgPSB5eW1zZ2J1
ZjsKLQkJeXltc2dfYWxsb2MgPSBzaXplb2YgeXltc2didWY7Ci0JICAgICAgfQotCSAgfQotCi0J
aWYgKDAgPCB5eXNpemUgJiYgeXlzaXplIDw9IHl5bXNnX2FsbG9jKQotCSAgewotCSAgICAodm9p
ZCkgeXlzeW50YXhfZXJyb3IgKHl5bXNnLCB5eXN0YXRlLCB5eWNoYXIpOwotCSAgICB5eWVycm9y
ICgmeXlsbG9jLCBjdHgsIHl5bXNnKTsKLQkgIH0KLQllbHNlCi0JICB7Ci0JICAgIHl5ZXJyb3Ig
KCZ5eWxsb2MsIGN0eCwgWVlfKCJzeW50YXggZXJyb3IiKSk7Ci0JICAgIGlmICh5eXNpemUgIT0g
MCkKLQkgICAgICBnb3RvIHl5ZXhoYXVzdGVkbGFiOwotCSAgfQorICAgICAgICBjaGFyIGNvbnN0
ICp5eW1zZ3AgPSBZWV8oInN5bnRheCBlcnJvciIpOworICAgICAgICBpbnQgeXlzeW50YXhfZXJy
b3Jfc3RhdHVzOworICAgICAgICB5eXN5bnRheF9lcnJvcl9zdGF0dXMgPSBZWVNZTlRBWF9FUlJP
UjsKKyAgICAgICAgaWYgKHl5c3ludGF4X2Vycm9yX3N0YXR1cyA9PSAwKQorICAgICAgICAgIHl5
bXNncCA9IHl5bXNnOworICAgICAgICBlbHNlIGlmICh5eXN5bnRheF9lcnJvcl9zdGF0dXMgPT0g
MSkKKyAgICAgICAgICB7CisgICAgICAgICAgICBpZiAoeXltc2cgIT0geXltc2didWYpCisgICAg
ICAgICAgICAgIFlZU1RBQ0tfRlJFRSAoeXltc2cpOworICAgICAgICAgICAgeXltc2cgPSAoY2hh
ciAqKSBZWVNUQUNLX0FMTE9DICh5eW1zZ19hbGxvYyk7CisgICAgICAgICAgICBpZiAoIXl5bXNn
KQorICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgeXltc2cgPSB5eW1zZ2J1ZjsKKyAg
ICAgICAgICAgICAgICB5eW1zZ19hbGxvYyA9IHNpemVvZiB5eW1zZ2J1ZjsKKyAgICAgICAgICAg
ICAgICB5eXN5bnRheF9lcnJvcl9zdGF0dXMgPSAyOworICAgICAgICAgICAgICB9CisgICAgICAg
ICAgICBlbHNlCisgICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICB5eXN5bnRheF9lcnJv
cl9zdGF0dXMgPSBZWVNZTlRBWF9FUlJPUjsKKyAgICAgICAgICAgICAgICB5eW1zZ3AgPSB5eW1z
ZzsKKyAgICAgICAgICAgICAgfQorICAgICAgICAgIH0KKyAgICAgICAgeXllcnJvciAoJnl5bGxv
YywgY3R4LCB5eW1zZ3ApOworICAgICAgICBpZiAoeXlzeW50YXhfZXJyb3Jfc3RhdHVzID09IDIp
CisgICAgICAgICAgZ290byB5eWV4aGF1c3RlZGxhYjsKICAgICAgIH0KKyMgdW5kZWYgWVlTWU5U
QVhfRVJST1IKICNlbmRpZgogICAgIH0KIAotICB5eWVycm9yX3JhbmdlWzBdID0geXlsbG9jOwor
ICB5eWVycm9yX3JhbmdlWzFdID0geXlsbG9jOwogCiAgIGlmICh5eWVycnN0YXR1cyA9PSAzKQog
ICAgIHsKLSAgICAgIC8qIElmIGp1c3QgdHJpZWQgYW5kIGZhaWxlZCB0byByZXVzZSBsb29rLWFo
ZWFkIHRva2VuIGFmdGVyIGFuCisgICAgICAvKiBJZiBqdXN0IHRyaWVkIGFuZCBmYWlsZWQgdG8g
cmV1c2UgbG9va2FoZWFkIHRva2VuIGFmdGVyIGFuCiAJIGVycm9yLCBkaXNjYXJkIGl0LiAgKi8K
IAogICAgICAgaWYgKHl5Y2hhciA8PSBZWUVPRikKQEAgLTE1NjEsNyArMTY4Miw3IEBAIHl5ZXJy
bGFiOgogCX0KICAgICB9CiAKLSAgLyogRWxzZSB3aWxsIHRyeSB0byByZXVzZSBsb29rLWFoZWFk
IHRva2VuIGFmdGVyIHNoaWZ0aW5nIHRoZSBlcnJvcgorICAvKiBFbHNlIHdpbGwgdHJ5IHRvIHJl
dXNlIGxvb2thaGVhZCB0b2tlbiBhZnRlciBzaGlmdGluZyB0aGUgZXJyb3IKICAgICAgdG9rZW4u
ICAqLwogICBnb3RvIHl5ZXJybGFiMTsKIApAQCAtMTU3Nyw3ICsxNjk4LDcgQEAgeXllcnJvcmxh
YjoKICAgaWYgKC8qQ09OU1RDT05EKi8gMCkKICAgICAgZ290byB5eWVycm9ybGFiOwogCi0gIHl5
ZXJyb3JfcmFuZ2VbMF0gPSB5eWxzcFsxLXl5bGVuXTsKKyAgeXllcnJvcl9yYW5nZVsxXSA9IHl5
bHNwWzEteXlsZW5dOwogICAvKiBEbyBub3QgcmVjbGFpbSB0aGUgc3ltYm9scyBvZiB0aGUgcnVs
ZSB3aGljaCBhY3Rpb24gdHJpZ2dlcmVkCiAgICAgIHRoaXMgWVlFUlJPUi4gICovCiAgIFlZUE9Q
U1RBQ0sgKHl5bGVuKTsKQEAgLTE1OTYsNyArMTcxNyw3IEBAIHl5ZXJybGFiMToKICAgZm9yICg7
OykKICAgICB7CiAgICAgICB5eW4gPSB5eXBhY3RbeXlzdGF0ZV07Ci0gICAgICBpZiAoeXluICE9
IFlZUEFDVF9OSU5GKQorICAgICAgaWYgKCF5eXBhY3RfdmFsdWVfaXNfZGVmYXVsdCAoeXluKSkK
IAl7CiAJICB5eW4gKz0gWVlURVJST1I7CiAJICBpZiAoMCA8PSB5eW4gJiYgeXluIDw9IFlZTEFT
VCAmJiB5eWNoZWNrW3l5bl0gPT0gWVlURVJST1IpCkBAIC0xNjExLDcgKzE3MzIsNyBAQCB5eWVy
cmxhYjE6CiAgICAgICBpZiAoeXlzc3AgPT0geXlzcykKIAlZWUFCT1JUOwogCi0gICAgICB5eWVy
cm9yX3JhbmdlWzBdID0gKnl5bHNwOworICAgICAgeXllcnJvcl9yYW5nZVsxXSA9ICp5eWxzcDsK
ICAgICAgIHl5ZGVzdHJ1Y3QgKCJFcnJvcjogcG9wcGluZyIsCiAJCSAgeXlzdG9zW3l5c3RhdGVd
LCB5eXZzcCwgeXlsc3AsIGN0eCk7CiAgICAgICBZWVBPUFNUQUNLICgxKTsKQEAgLTE2MTksMTUg
KzE3NDAsMTIgQEAgeXllcnJsYWIxOgogICAgICAgWVlfU1RBQ0tfUFJJTlQgKHl5c3MsIHl5c3Nw
KTsKICAgICB9CiAKLSAgaWYgKHl5biA9PSBZWUZJTkFMKQotICAgIFlZQUNDRVBUOwotCiAgICor
K3l5dnNwID0geXlsdmFsOwogCi0gIHl5ZXJyb3JfcmFuZ2VbMV0gPSB5eWxsb2M7CisgIHl5ZXJy
b3JfcmFuZ2VbMl0gPSB5eWxsb2M7CiAgIC8qIFVzaW5nIFlZTExPQyBpcyB0ZW1wdGluZywgYnV0
IHdvdWxkIGNoYW5nZSB0aGUgbG9jYXRpb24gb2YKLSAgICAgdGhlIGxvb2stYWhlYWQuICBZWUxP
QyBpcyBhdmFpbGFibGUgdGhvdWdoLiAgKi8KLSAgWVlMTE9DX0RFRkFVTFQgKHl5bG9jLCAoeXll
cnJvcl9yYW5nZSAtIDEpLCAyKTsKKyAgICAgdGhlIGxvb2thaGVhZC4gIFlZTE9DIGlzIGF2YWls
YWJsZSB0aG91Z2guICAqLworICBZWUxMT0NfREVGQVVMVCAoeXlsb2MsIHl5ZXJyb3JfcmFuZ2Us
IDIpOwogICAqKyt5eWxzcCA9IHl5bG9jOwogCiAgIC8qIFNoaWZ0IHRoZSBlcnJvciB0b2tlbi4g
ICovCkBAIC0xNjUxLDcgKzE3NjksNyBAQCB5eWFib3J0bGFiOgogICB5eXJlc3VsdCA9IDE7CiAg
IGdvdG8geXlyZXR1cm47CiAKLSNpZm5kZWYgeXlvdmVyZmxvdworI2lmICFkZWZpbmVkKHl5b3Zl
cmZsb3cpIHx8IFlZRVJST1JfVkVSQk9TRQogLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLgogfCB5eWV4aGF1c3RlZGxhYiAtLSBtZW1vcnkgZXhoYXVz
dGlvbiBjb21lcyBoZXJlLiAgfAogYC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0qLwpAQCAtMTY2Miw5ICsxNzgwLDE0IEBAIHl5ZXhoYXVzdGVkbGFiOgog
I2VuZGlmCiAKIHl5cmV0dXJuOgotICBpZiAoeXljaGFyICE9IFlZRU9GICYmIHl5Y2hhciAhPSBZ
WUVNUFRZKQotICAgICB5eWRlc3RydWN0ICgiQ2xlYW51cDogZGlzY2FyZGluZyBsb29rYWhlYWQi
LAotCQkgeXl0b2tlbiwgJnl5bHZhbCwgJnl5bGxvYywgY3R4KTsKKyAgaWYgKHl5Y2hhciAhPSBZ
WUVNUFRZKQorICAgIHsKKyAgICAgIC8qIE1ha2Ugc3VyZSB3ZSBoYXZlIGxhdGVzdCBsb29rYWhl
YWQgdHJhbnNsYXRpb24uICBTZWUgY29tbWVudHMgYXQKKyAgICAgICAgIHVzZXIgc2VtYW50aWMg
YWN0aW9ucyBmb3Igd2h5IHRoaXMgaXMgbmVjZXNzYXJ5LiAgKi8KKyAgICAgIHl5dG9rZW4gPSBZ
WVRSQU5TTEFURSAoeXljaGFyKTsKKyAgICAgIHl5ZGVzdHJ1Y3QgKCJDbGVhbnVwOiBkaXNjYXJk
aW5nIGxvb2thaGVhZCIsCisgICAgICAgICAgICAgICAgICB5eXRva2VuLCAmeXlsdmFsLCAmeXls
bG9jLCBjdHgpOworICAgIH0KICAgLyogRG8gbm90IHJlY2xhaW0gdGhlIHN5bWJvbHMgb2YgdGhl
IHJ1bGUgd2hpY2ggYWN0aW9uIHRyaWdnZXJlZAogICAgICB0aGlzIFlZQUJPUlQgb3IgWVlBQ0NF
UFQuICAqLwogICBZWVBPUFNUQUNLICh5eWxlbik7CkBAIC0xNjg5LDExICsxODEyLDMgQEAgeXly
ZXR1cm46CiAKIAogCi0KLS8qCi0gKiBMb2NhbCB2YXJpYWJsZXM6Ci0gKiBtb2RlOiBDCi0gKiBj
LWJhc2ljLW9mZnNldDogNAotICogaW5kZW50LXRhYnMtbW9kZTogbmlsCi0gKiBFbmQ6Ci0gKi8K
ZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL2xpYnhsL2xpYnhsdV9j
ZmdfeS5oCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9jZmdfeS5oCUZyaSBGZWIgMTcgMTI6MjQ6
MzggMjAxMiArMDAwMAorKysgYi90b29scy9saWJ4bC9saWJ4bHVfY2ZnX3kuaAlNb24gRmViIDIw
IDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTEsMjQgKzEsMjEgQEAKLS8qIEEgQmlzb24gcGFyc2Vy
LCBtYWRlIGJ5IEdOVSBCaXNvbiAyLjMuICAqLworLyogQSBCaXNvbiBwYXJzZXIsIG1hZGUgYnkg
R05VIEJpc29uIDIuNS4gICovCiAKLS8qIFNrZWxldG9uIGludGVyZmFjZSBmb3IgQmlzb24ncyBZ
YWNjLWxpa2UgcGFyc2VycyBpbiBDCi0KLSAgIENvcHlyaWdodCAoQykgMTk4NCwgMTk4OSwgMTk5
MCwgMjAwMCwgMjAwMSwgMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNgotICAgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uLCBJbmMuCi0KLSAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisvKiBCaXNvbiBpbnRlcmZh
Y2UgZm9yIFlhY2MtbGlrZSBwYXJzZXJzIGluIEMKKyAgIAorICAgICAgQ29weXJpZ2h0IChDKSAx
OTg0LCAxOTg5LTE5OTAsIDIwMDAtMjAxMSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4K
KyAgIAorICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU6IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkKICAgIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdl
bmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5Ci0gICB0aGUgRnJlZSBTb2Z0d2Fy
ZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyLCBvciAoYXQgeW91ciBvcHRpb24pCi0gICBh
bnkgbGF0ZXIgdmVyc2lvbi4KLQorICAgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgZWl0
aGVyIHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwgb3IKKyAgIChhdCB5b3VyIG9wdGlvbikgYW55
IGxhdGVyIHZlcnNpb24uCisgICAKICAgIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0
aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAogICAgYnV0IFdJVEhPVVQgQU5ZIFdBUlJB
TlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKICAgIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKICAgIEdO
VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCi0KKyAgIAogICAgWW91
IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExp
Y2Vuc2UKLSAgIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBG
cmVlIFNvZnR3YXJlCi0gICBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdHJlZXQsIEZp
ZnRoIEZsb29yLAotICAgQm9zdG9uLCBNQSAwMjExMC0xMzAxLCBVU0EuICAqLworICAgYWxvbmcg
d2l0aCB0aGlzIHByb2dyYW0uICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5nbnUub3JnL2xpY2Vu
c2VzLz4uICAqLwogCiAvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCB5b3UgbWF5IGNyZWF0ZSBh
IGxhcmdlciB3b3JrIHRoYXQgY29udGFpbnMKICAgIHBhcnQgb3IgYWxsIG9mIHRoZSBCaXNvbiBw
YXJzZXIgc2tlbGV0b24gYW5kIGRpc3RyaWJ1dGUgdGhhdCB3b3JrCkBAIC0yOSwxMCArMjYsMTEg
QEAKICAgIHNwZWNpYWwgZXhjZXB0aW9uLCB3aGljaCB3aWxsIGNhdXNlIHRoZSBza2VsZXRvbiBh
bmQgdGhlIHJlc3VsdGluZwogICAgQmlzb24gb3V0cHV0IGZpbGVzIHRvIGJlIGxpY2Vuc2VkIHVu
ZGVyIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMKICAgIExpY2Vuc2Ugd2l0aG91dCB0aGlzIHNwZWNp
YWwgZXhjZXB0aW9uLgotCisgICAKICAgIFRoaXMgc3BlY2lhbCBleGNlcHRpb24gd2FzIGFkZGVk
IGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24gaW4KICAgIHZlcnNpb24gMi4yIG9mIEJp
c29uLiAgKi8KIAorCiAvKiBUb2tlbnMuICAqLwogI2lmbmRlZiBZWVRPS0VOVFlQRQogIyBkZWZp
bmUgWVlUT0tFTlRZUEUKQEAgLTQ1LDI4ICs0MywyNyBAQAogICAgICBORVdMSU5FID0gMjYxCiAg
ICB9OwogI2VuZGlmCi0vKiBUb2tlbnMuICAqLwotI2RlZmluZSBJREVOVCAyNTgKLSNkZWZpbmUg
U1RSSU5HIDI1OQotI2RlZmluZSBOVU1CRVIgMjYwCi0jZGVmaW5lIE5FV0xJTkUgMjYxCi0KIAog
CiAKICNpZiAhIGRlZmluZWQgWVlTVFlQRSAmJiAhIGRlZmluZWQgWVlTVFlQRV9JU19ERUNMQVJF
RAogdHlwZWRlZiB1bmlvbiBZWVNUWVBFCit7CisKKy8qIExpbmUgMjA2OCBvZiB5YWNjLmMgICov
CiAjbGluZSAyNSAibGlieGx1X2NmZ195LnkiCi17CisKICAgY2hhciAqc3RyaW5nOwogICBYTFVf
Q29uZmlnU2V0dGluZyAqc2V0dGluZzsKLX0KLS8qIExpbmUgMTQ4OSBvZiB5YWNjLmMuICAqLwot
I2xpbmUgNjYgImxpYnhsdV9jZmdfeS5oIgotCVlZU1RZUEU7CisKKworCisvKiBMaW5lIDIwNjgg
b2YgeWFjYy5jICAqLworI2xpbmUgNjMgImxpYnhsdV9jZmdfeS5oIgorfSBZWVNUWVBFOworIyBk
ZWZpbmUgWVlTVFlQRV9JU19UUklWSUFMIDEKICMgZGVmaW5lIHl5c3R5cGUgWVlTVFlQRSAvKiBv
YnNvbGVzY2VudDsgd2lsbCBiZSB3aXRoZHJhd24gKi8KICMgZGVmaW5lIFlZU1RZUEVfSVNfREVD
TEFSRUQgMQotIyBkZWZpbmUgWVlTVFlQRV9JU19UUklWSUFMIDEKICNlbmRpZgogCiAKQEAgLTg2
LDEwICs4MywzIEBAIHR5cGVkZWYgc3RydWN0IFlZTFRZUEUKIAogCiAKLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiBtb2RlOiBDCi0gKiBjLWJhc2ljLW9mZnNldDogNAotICogaW5kZW50LXRh
YnMtbW9kZTogbmlsCi0gKiBFbmQ6Ci0gKi8KZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjll
ZDhhOTE0IHRvb2xzL2xpYnhsL2xpYnhsdV9kaXNrX2wuYwotLS0gYS90b29scy9saWJ4bC9saWJ4
bHVfZGlza19sLmMJRnJpIEZlYiAxNyAxMjoyNDozOCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xp
YnhsL2xpYnhsdV9kaXNrX2wuYwlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTU0
LDYgKzU0LDcgQEAgdHlwZWRlZiBpbnQgZmxleF9pbnQzMl90OwogdHlwZWRlZiB1bnNpZ25lZCBj
aGFyIGZsZXhfdWludDhfdDsgCiB0eXBlZGVmIHVuc2lnbmVkIHNob3J0IGludCBmbGV4X3VpbnQx
Nl90OwogdHlwZWRlZiB1bnNpZ25lZCBpbnQgZmxleF91aW50MzJfdDsKKyNlbmRpZiAvKiAhIEM5
OSAqLwogCiAvKiBMaW1pdHMgb2YgaW50ZWdyYWwgdHlwZXMuICovCiAjaWZuZGVmIElOVDhfTUlO
CkBAIC04NCw4ICs4NSw2IEBAIHR5cGVkZWYgdW5zaWduZWQgaW50IGZsZXhfdWludDMyX3Q7CiAj
ZGVmaW5lIFVJTlQzMl9NQVggICAgICAgICAgICAgKDQyOTQ5NjcyOTVVKQogI2VuZGlmCiAKLSNl
bmRpZiAvKiAhIEM5OSAqLwotCiAjZW5kaWYgLyogISBGTEVYSU5UX0ggKi8KIAogI2lmZGVmIF9f
Y3BsdXNwbHVzCkBAIC0xNTksMTUgKzE1OCw3IEBAIHR5cGVkZWYgdm9pZCogeXlzY2FuX3Q7CiAK
IC8qIFNpemUgb2YgZGVmYXVsdCBpbnB1dCBidWZmZXIuICovCiAjaWZuZGVmIFlZX0JVRl9TSVpF
Ci0jaWZkZWYgX19pYTY0X18KLS8qIE9uIElBLTY0LCB0aGUgYnVmZmVyIHNpemUgaXMgMTZrLCBu
b3QgOGsuCi0gKiBNb3Jlb3ZlciwgWVlfQlVGX1NJWkUgaXMgMipZWV9SRUFEX0JVRl9TSVpFIGlu
IHRoZSBnZW5lcmFsIGNhc2UuCi0gKiBEaXR0byBmb3IgdGhlIF9faWE2NF9fIGNhc2UgYWNjb3Jk
aW5nbHkuCi0gKi8KLSNkZWZpbmUgWVlfQlVGX1NJWkUgMzI3NjgKLSNlbHNlCiAjZGVmaW5lIFlZ
X0JVRl9TSVpFIDE2Mzg0Ci0jZW5kaWYgLyogX19pYTY0X18gKi8KICNlbmRpZgogCiAvKiBUaGUg
c3RhdGUgYnVmIG11c3QgYmUgbGFyZ2UgZW5vdWdoIHRvIGhvbGQgb25lIHN0YXRlIHBlciBjaGFy
YWN0ZXIgaW4gdGhlIG1haW4gYnVmZmVyLgpAQCAtODYwLDcgKzg1MSw3IEBAIHN0YXRpYyB2b2lk
IHNldGJhY2tlbmR0eXBlKERpc2tQYXJzZUNvbnQKICNkZWZpbmUgREVQUkVDQVRFKHVzZXdoYXRp
bnN0ZWFkKSAvKiBub3QgY3VycmVudGx5IHJlcG9ydGVkICovCiAKIAotI2xpbmUgODY0ICJsaWJ4
bHVfZGlza19sLmMiCisjbGluZSA4NTUgImxpYnhsdV9kaXNrX2wuYyIKIAogI2RlZmluZSBJTklU
SUFMIDAKICNkZWZpbmUgTEVYRVJSIDEKQEAgLTk4OSwxMiArOTgwLDcgQEAgc3RhdGljIGludCBp
bnB1dCAoeXlzY2FuX3QgeXlzY2FubmVyICk7CiAKIC8qIEFtb3VudCBvZiBzdHVmZiB0byBzbHVy
cCB1cCB3aXRoIGVhY2ggcmVhZC4gKi8KICNpZm5kZWYgWVlfUkVBRF9CVUZfU0laRQotI2lmZGVm
IF9faWE2NF9fCi0vKiBPbiBJQS02NCwgdGhlIGJ1ZmZlciBzaXplIGlzIDE2aywgbm90IDhrICov
Ci0jZGVmaW5lIFlZX1JFQURfQlVGX1NJWkUgMTYzODQKLSNlbHNlCiAjZGVmaW5lIFlZX1JFQURf
QlVGX1NJWkUgODE5MgotI2VuZGlmIC8qIF9faWE2NF9fICovCiAjZW5kaWYKIAogLyogQ29weSB3
aGF0ZXZlciB0aGUgbGFzdCBydWxlIG1hdGNoZWQgdG8gdGhlIHN0YW5kYXJkIG91dHB1dC4gKi8K
QEAgLTEwMDIsNyArOTg4LDcgQEAgc3RhdGljIGludCBpbnB1dCAoeXlzY2FuX3QgeXlzY2FubmVy
ICk7CiAvKiBUaGlzIHVzZWQgdG8gYmUgYW4gZnB1dHMoKSwgYnV0IHNpbmNlIHRoZSBzdHJpbmcg
bWlnaHQgY29udGFpbiBOVUwncywKICAqIHdlIG5vdyB1c2UgZndyaXRlKCkuCiAgKi8KLSNkZWZp
bmUgRUNITyBkbyB7IGlmIChmd3JpdGUoIHl5dGV4dCwgeXlsZW5nLCAxLCB5eW91dCApKSB7fSB9
IHdoaWxlICgwKQorI2RlZmluZSBFQ0hPIGZ3cml0ZSggeXl0ZXh0LCB5eWxlbmcsIDEsIHl5b3V0
ICkKICNlbmRpZgogCiAvKiBHZXRzIGlucHV0IGFuZCBzdHVmZnMgaXQgaW50byAiYnVmIi4gIG51
bWJlciBvZiBjaGFyYWN0ZXJzIHJlYWQsIG9yIFlZX05VTEwsCkBAIC0xMDEzLDcgKzk5OSw3IEBA
IHN0YXRpYyBpbnQgaW5wdXQgKHl5c2Nhbl90IHl5c2Nhbm5lciApOwogCWlmICggWVlfQ1VSUkVO
VF9CVUZGRVJfTFZBTFVFLT55eV9pc19pbnRlcmFjdGl2ZSApIFwKIAkJeyBcCiAJCWludCBjID0g
JyonOyBcCi0JCXNpemVfdCBuOyBcCisJCWludCBuOyBcCiAJCWZvciAoIG4gPSAwOyBuIDwgbWF4
X3NpemUgJiYgXAogCQkJICAgICAoYyA9IGdldGMoIHl5aW4gKSkgIT0gRU9GICYmIGMgIT0gJ1xu
JzsgKytuICkgXAogCQkJYnVmW25dID0gKGNoYXIpIGM7IFwKQEAgLTExMDEsNyArMTA4Nyw3IEBA
IFlZX0RFQ0wKIAogIC8qLS0tLS0gdGhlIHNjYW5uZXIgcnVsZXMgd2hpY2ggZG8gdGhlIHBhcnNp
bmcgLS0tLS0qLwogCi0jbGluZSAxMTA1ICJsaWJ4bHVfZGlza19sLmMiCisjbGluZSAxMDkxICJs
aWJ4bHVfZGlza19sLmMiCiAKIAlpZiAoICF5eWctPnl5X2luaXQgKQogCQl7CkBAIC0xNDI0LDcg
KzE0MTAsNyBAQCBZWV9SVUxFX1NFVFVQCiAjbGluZSAyMjcgImxpYnhsdV9kaXNrX2wubCIKIFlZ
X0ZBVEFMX0VSUk9SKCAiZmxleCBzY2FubmVyIGphbW1lZCIgKTsKIAlZWV9CUkVBSwotI2xpbmUg
MTQyOCAibGlieGx1X2Rpc2tfbC5jIgorI2xpbmUgMTQxNCAibGlieGx1X2Rpc2tfbC5jIgogCQkJ
Y2FzZSBZWV9TVEFURV9FT0YoSU5JVElBTCk6CiAJCQljYXNlIFlZX1NUQVRFX0VPRihMRVhFUlIp
OgogCQkJCXl5dGVybWluYXRlKCk7CkBAIC0yMTI1LDggKzIxMTEsOCBAQCBZWV9CVUZGRVJfU1RB
VEUgeGx1X19kaXNrX3l5X3NjYW5fc3RyaW5nCiAKIC8qKiBTZXR1cCB0aGUgaW5wdXQgYnVmZmVy
IHN0YXRlIHRvIHNjYW4gdGhlIGdpdmVuIGJ5dGVzLiBUaGUgbmV4dCBjYWxsIHRvIHhsdV9fZGlz
a195eWxleCgpIHdpbGwKICAqIHNjYW4gZnJvbSBhIEBlIGNvcHkgb2YgQGEgYnl0ZXMuCi0gKiBA
cGFyYW0geXlieXRlcyB0aGUgYnl0ZSBidWZmZXIgdG8gc2NhbgotICogQHBhcmFtIF95eWJ5dGVz
X2xlbiB0aGUgbnVtYmVyIG9mIGJ5dGVzIGluIHRoZSBidWZmZXIgcG9pbnRlZCB0byBieSBAYSBi
eXRlcy4KKyAqIEBwYXJhbSBieXRlcyB0aGUgYnl0ZSBidWZmZXIgdG8gc2NhbgorICogQHBhcmFt
IGxlbiB0aGUgbnVtYmVyIG9mIGJ5dGVzIGluIHRoZSBidWZmZXIgcG9pbnRlZCB0byBieSBAYSBi
eXRlcy4KICAqIEBwYXJhbSB5eXNjYW5uZXIgVGhlIHNjYW5uZXIgb2JqZWN0LgogICogQHJldHVy
biB0aGUgbmV3bHkgYWxsb2NhdGVkIGJ1ZmZlciBzdGF0ZSBvYmplY3QuCiAgKi8KQEAgLTI1MTcs
MTEgKzI1MDMsMyBAQCB2b2lkIHhsdV9fZGlza195eWZyZWUgKHZvaWQgKiBwdHIgLCB5eXNjCiAj
ZGVmaW5lIFlZVEFCTEVTX05BTUUgInl5dGFibGVzIgogCiAjbGluZSAyMjcgImxpYnhsdV9kaXNr
X2wubCIKLQotLyoKLSAqIExvY2FsIHZhcmlhYmxlczoKLSAqIG1vZGU6IEMKLSAqIGMtYmFzaWMt
b2Zmc2V0OiA0Ci0gKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwKLSAqIEVuZDoKLSAqLwpkaWZmIC1y
IDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbGlieGwvbGlieGx1X2Rpc2tfbC5o
Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsdV9kaXNrX2wuaAlGcmkgRmViIDE3IDEyOjI0OjM4IDIw
MTIgKzAwMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGx1X2Rpc2tfbC5oCU1vbiBGZWIgMjAgMTg6
MjA6MjkgMjAxMiArMDEwMApAQCAtNTgsNiArNTgsNyBAQCB0eXBlZGVmIGludCBmbGV4X2ludDMy
X3Q7CiB0eXBlZGVmIHVuc2lnbmVkIGNoYXIgZmxleF91aW50OF90OyAKIHR5cGVkZWYgdW5zaWdu
ZWQgc2hvcnQgaW50IGZsZXhfdWludDE2X3Q7CiB0eXBlZGVmIHVuc2lnbmVkIGludCBmbGV4X3Vp
bnQzMl90OworI2VuZGlmIC8qICEgQzk5ICovCiAKIC8qIExpbWl0cyBvZiBpbnRlZ3JhbCB0eXBl
cy4gKi8KICNpZm5kZWYgSU5UOF9NSU4KQEAgLTg4LDggKzg5LDYgQEAgdHlwZWRlZiB1bnNpZ25l
ZCBpbnQgZmxleF91aW50MzJfdDsKICNkZWZpbmUgVUlOVDMyX01BWCAgICAgICAgICAgICAoNDI5
NDk2NzI5NVUpCiAjZW5kaWYKIAotI2VuZGlmIC8qICEgQzk5ICovCi0KICNlbmRpZiAvKiAhIEZM
RVhJTlRfSCAqLwogCiAjaWZkZWYgX19jcGx1c3BsdXMKQEAgLTEzMiwxNSArMTMxLDcgQEAgdHlw
ZWRlZiB2b2lkKiB5eXNjYW5fdDsKIAogLyogU2l6ZSBvZiBkZWZhdWx0IGlucHV0IGJ1ZmZlci4g
Ki8KICNpZm5kZWYgWVlfQlVGX1NJWkUKLSNpZmRlZiBfX2lhNjRfXwotLyogT24gSUEtNjQsIHRo
ZSBidWZmZXIgc2l6ZSBpcyAxNmssIG5vdCA4ay4KLSAqIE1vcmVvdmVyLCBZWV9CVUZfU0laRSBp
cyAyKllZX1JFQURfQlVGX1NJWkUgaW4gdGhlIGdlbmVyYWwgY2FzZS4KLSAqIERpdHRvIGZvciB0
aGUgX19pYTY0X18gY2FzZSBhY2NvcmRpbmdseS4KLSAqLwotI2RlZmluZSBZWV9CVUZfU0laRSAz
Mjc2OAotI2Vsc2UKICNkZWZpbmUgWVlfQlVGX1NJWkUgMTYzODQKLSNlbmRpZiAvKiBfX2lhNjRf
XyAqLwogI2VuZGlmCiAKICNpZm5kZWYgWVlfVFlQRURFRl9ZWV9CVUZGRVJfU1RBVEUKQEAgLTMw
MiwxMiArMjkzLDcgQEAgc3RhdGljIGludCB5eV9mbGV4X3N0cmxlbiAoeXljb25zdCBjaGFyIAog
CiAvKiBBbW91bnQgb2Ygc3R1ZmYgdG8gc2x1cnAgdXAgd2l0aCBlYWNoIHJlYWQuICovCiAjaWZu
ZGVmIFlZX1JFQURfQlVGX1NJWkUKLSNpZmRlZiBfX2lhNjRfXwotLyogT24gSUEtNjQsIHRoZSBi
dWZmZXIgc2l6ZSBpcyAxNmssIG5vdCA4ayAqLwotI2RlZmluZSBZWV9SRUFEX0JVRl9TSVpFIDE2
Mzg0Ci0jZWxzZQogI2RlZmluZSBZWV9SRUFEX0JVRl9TSVpFIDgxOTIKLSNlbmRpZiAvKiBfX2lh
NjRfXyAqLwogI2VuZGlmCiAKIC8qIE51bWJlciBvZiBlbnRyaWVzIGJ5IHdoaWNoIHN0YXJ0LWNv
bmRpdGlvbiBzdGFjayBncm93cy4gKi8KQEAgLTM0MiwxNCArMzI4LDYgQEAgZXh0ZXJuIGludCB4
bHVfX2Rpc2tfeXlsZXggKHl5c2Nhbl90IHl5cwogCiAjbGluZSAyMjcgImxpYnhsdV9kaXNrX2wu
bCIKIAotI2xpbmUgMzQ2ICJsaWJ4bHVfZGlza19sLmgiCisjbGluZSAzMzIgImxpYnhsdV9kaXNr
X2wuaCIKICN1bmRlZiB4bHVfX2Rpc2tfeXlJTl9IRUFERVIKICNlbmRpZiAvKiB4bHVfX2Rpc2tf
eXlIRUFERVJfSCAqLwotCi0vKgotICogTG9jYWwgdmFyaWFibGVzOgotICogbW9kZTogQwotICog
Yy1iYXNpYy1vZmZzZXQ6IDQKLSAqIGluZGVudC10YWJzLW1vZGU6IG5pbAotICogRW5kOgotICov
CmRpZmYgLXIgODcyMThiZDM2N2JlIC1yIGNjZGY5ZWQ4YTkxNCB0b29scy9tNC9kZWZhdWx0X2xp
Yi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9kZWZhdWx0X2xpYi5tNAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSw4IEBACitBQ19ERUZVTihbQVhfREVGQVVMVF9MSUJdLAorW0FTX0lGKFt0ZXN0IC1k
ICIkcHJlZml4L2xpYjY0Il0sIFsKKyAgICBMSUJfUEFUSD0ibGliNjQiCitdLFsKKyAgICBMSUJf
UEFUSD0ibGliIgorXSkKK0FDX1NVQlNUKExJQl9QQVRIKV0pCisKZGlmZiAtciA4NzIxOGJkMzY3
YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kaXNhYmxl
X2ZlYXR1cmUubTQJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMg
QEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxF
KFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0kMV0sIFskMl0pKQorCitBU19J
RihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBb
dGVzdCAieCRlbmFibGVfJDEiID0gInh5ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rl
c3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSkKKyQxPSRheF9jdl8kMQor
QUNfU1VCU1QoJDEpXSkKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xz
L200L2VuYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL3Rvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00CU1vbiBGZWIgMjAgMTg6
MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEzIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJM
RV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkco
Wy0tZW5hYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHll
cyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJd
LCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhf
Y3ZfJDE9Im4iCitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIDg3MjE4
YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvb2NhbWwubTQKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvb2NhbWwubTQJTW9u
IEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMjQxIEBACitkbmwgYXV0b2Nv
bmYgbWFjcm9zIGZvciBPQ2FtbAorZG5sIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcv
CitkbmwKK2RubCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFJpY2hhcmQgVy5NLiBKb25lcworZG5s
IENvcHlyaWdodCDCqSAyMDA5ICAgICAgU3RlZmFubyBaYWNjaGlyb2xpCitkbmwgQ29weXJpZ2h0
IMKpIDIwMDAtMjAwNSBPbGl2aWVyIEFuZHJpZXUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1
IEplYW4tQ2hyaXN0b3BoZSBGaWxsacOidHJlCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBH
ZW9yZ2VzIE1hcmlhbm8KK2RubAorZG5sIEZvciBkb2N1bWVudGF0aW9uLCBwbGVhc2UgcmVhZCB0
aGUgb2NhbWwubTQgbWFuIHBhZ2UuCisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MXSwKK1tkbmwK
KyAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQ10sW29jYW1s
Y10sW25vXSkKKworICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAibm8iOyB0aGVuCisgICAgIE9DQU1M
VkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwx
fHAnYAorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT05d
KQorICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0CisgICAgIGlmIHRlc3QgIiRPQ0FN
TExJQiIgPSAiIjsgdGhlbgorICAgICAgICBPQ0FNTExJQj1gJE9DQU1MQyAtd2hlcmUgMj4vZGV2
L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAnICcgLWYgNGAKKyAgICAgZWxzZQor
ICAgICAgICBBQ19NU0dfUkVTVUxUKFtPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2Vydmlu
ZyBpdC5dKQorICAgICBmaQorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCBsaWJyYXJ5IHBhdGgg
aXMgJE9DQU1MTElCXSkKKworICAgICBBQ19TVUJTVChbT0NBTUxWRVJTSU9OXSkKKyAgICAgQUNf
U1VCU1QoW09DQU1MTElCXSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBB
Q19DSEVDS19UT09MKFtPQ0FNTE9QVF0sW29jYW1sb3B0XSxbbm9dKQorICAgICBPQ0FNTEJFU1Q9
Ynl0ZQorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgorCUFDX01TR19XQVJO
KFtDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS5dKQorICAg
ICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVS
U0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBv
Y2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC5dKQorCSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkg
ICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MQkVT
VF0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAorICAgICBBQ19DSEVDS19UT09M
KFtPQ0FNTENET1RPUFRdLFtvY2FtbGMub3B0XSxbbm9dKQorICAgICBpZiB0ZXN0ICIkT0NBTUxD
RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNl
ZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVS
U0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJz
aW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC5dKQorCWVsc2UK
KwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBmaQorCisgICAgICMgY2hlY2tp
bmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiICE9ICJubyIgOyB0
aGVuCisJQUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRET1RPUFRdLFtvY2FtbG9wdC5vcHRdLFtub10p
CisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lP
Tj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8
XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0
aGVuCisJICAgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbiBkaWZmZXJzIGZyb20gb2NhbWxjOyBv
Y2FtbG9wdC5vcHQgZGlzY2FyZGVkLl0pCisJICAgZWxzZQorCSAgICAgIE9DQU1MT1BUPSRPQ0FN
TE9QVERPVE9QVAorCSAgIGZpCisgICAgICAgIGZpCisgICAgIGZpCisKKyAgICAgQUNfU1VCU1Qo
W09DQU1MT1BUXSkKKyAgZmkKKworICBBQ19TVUJTVChbT0NBTUxDXSkKKworICAjIGNoZWNraW5n
IGZvciBvY2FtbCB0b3BsZXZlbAorICBBQ19DSEVDS19UT09MKFtPQ0FNTF0sW29jYW1sXSxbbm9d
KQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIEFDX0NIRUNLX1RPT0woW09DQU1MREVQ
XSxbb2NhbWxkZXBdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta3RvcAorICBBQ19D
SEVDS19UT09MKFtPQ0FNTE1LVE9QXSxbb2NhbWxta3RvcF0sW25vXSkKKworICAjIGNoZWNraW5n
IGZvciBvY2FtbG1rbGliCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtMSUJdLFtvY2FtbG1rbGli
XSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgIEFDX0NIRUNLX1RPT0woW09D
QU1MRE9DXSxbb2NhbWxkb2NdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxidWlsZAor
ICBBQ19DSEVDS19UT09MKFtPQ0FNTEJVSUxEXSxbb2NhbWxidWlsZF0sW25vXSkKK10pCisKKwor
QUNfREVGVU4oW0FDX1BST0dfT0NBTUxMRVhdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2Ft
bGxleAorICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWF0sW29jYW1sbGV4XSxbbm9dKQorICBpZiB0
ZXN0ICIkT0NBTUxMRVgiICE9ICJubyI7IHRoZW4KKyAgICBBQ19DSEVDS19UT09MKFtPQ0FNTExF
WERPVE9QVF0sW29jYW1sbGV4Lm9wdF0sW25vXSkKKyAgICBpZiB0ZXN0ICIkT0NBTUxMRVhET1RP
UFQiICE9ICJubyI7IHRoZW4KKwlPQ0FNTExFWD0kT0NBTUxMRVhET1RPUFQKKyAgICBmaQorICBm
aQorICBBQ19TVUJTVChbT0NBTUxMRVhdKQorXSkKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxZ
QUNDXSwKK1tkbmwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxZQUNDXSxbb2NhbWx5YWNjXSxbbm9d
KQorICBBQ19TVUJTVChbT0NBTUxZQUNDXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfQ0FN
TFA0XSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAgIyBjaGVj
a2luZyBmb3IgY2FtbHA0CisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNF0sW2NhbWxwNF0sW25vXSkK
KyAgaWYgdGVzdCAiJENBTUxQNCIgIT0gIm5vIjsgdGhlbgorICAgICBUTVBWRVJTSU9OPWAkQ0FN
TFA0IC12IDI+JjF8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24gKlwoLipcKSR8XDF8cCdgCisgICAg
IGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJQUNfTVNH
X1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sY10pCisgICAgICAgIENBTUxQND1u
bworICAgICBmaQorICBmaQorICBBQ19TVUJTVChbQ0FNTFA0XSkKKworICAjIGNoZWNraW5nIGZv
ciBjb21wYW5pb24gdG9vbHMKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0Qk9PVF0sW2NhbWxwNGJv
b3RdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9dLFtjYW1scDRvXSxbbm9dKQorICBB
Q19DSEVDS19UT09MKFtDQU1MUDRPRl0sW2NhbWxwNG9mXSxbbm9dKQorICBBQ19DSEVDS19UT09M
KFtDQU1MUDRPT0ZdLFtjYW1scDRvb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9S
Rl0sW2NhbWxwNG9yZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UFJPRl0sW2NhbWxw
NHByb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJdLFtjYW1scDRyXSxbbm9dKQor
ICBBQ19DSEVDS19UT09MKFtDQU1MUDRSRl0sW2NhbWxwNHJmXSxbbm9dKQorICBBQ19TVUJTVChb
Q0FNTFA0Qk9PVF0pCisgIEFDX1NVQlNUKFtDQU1MUDRPXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9G
XSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9PRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPUkZdKQorICBB
Q19TVUJTVChbQ0FNTFA0UFJPRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRSXSkKKyAgQUNfU1VCU1Qo
W0NBTUxQNFJGXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfRklORExJQl0sCitbZG5sCisg
IEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
ZmluZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEZJTkRdLFtvY2FtbGZpbmRdLFtub10pCisgIEFD
X1NVQlNUKFtPQ0FNTEZJTkRdKQorXSkKKworCitkbmwgVGhhbmtzIHRvIEppbSBNZXllcmluZyBm
b3Igd29ya2luZyB0aGlzIG5leHQgYml0IG91dCBmb3IgdXMuCitkbmwgWFhYIFdlIHNob3VsZCBk
ZWZpbmUgQVNfVFJfU0ggaWYgaXQncyBub3QgZGVmaW5lZCBhbHJlYWR5CitkbmwgKGVnLiBmb3Ig
b2xkIGF1dG9jb25mKS4KK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9QS0ddLAorW2RubAorICBB
Q19SRVFVSVJFKFtBQ19QUk9HX0ZJTkRMSUJdKWRubAorCisgIEFDX01TR19DSEVDS0lORyhbZm9y
IE9DYW1sIGZpbmRsaWIgcGFja2FnZSAkMV0pCisKKyAgdW5zZXQgZm91bmQKKyAgdW5zZXQgcGtn
CisgIGZvdW5kPW5vCisgIGZvciBwa2cgaW4gJDEgJDIgOyBkbworICAgIGlmICRPQ0FNTEZJTkQg
cXVlcnkgJHBrZyA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0aGVuCisgICAgICBBQ19NU0dfUkVT
VUxUKFtmb3VuZF0pCisgICAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9JHBrZworICAgICAg
Zm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRvbmUKKyAgaWYgdGVzdCAiJGZvdW5k
IiA9ICJubyIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICBBU19U
Ul9TSChbT0NBTUxfUEtHXyQxXSk9bm8KKyAgZmkKKworICBBQ19TVUJTVChBU19UUl9TSChbT0NB
TUxfUEtHXyQxXSkpCitdKQorCisKK0FDX0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9NT0RVTEVdLAor
W2RubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBtb2R1bGUgJDJdKQorCisgIGNhdCA+
IGNvbmZ0ZXN0Lm1sIDw8RU9GCitvcGVuICQzCitFT0YKKyAgdW5zZXQgZm91bmQKKyAgZm9yICQx
IGluICQkMSAkNCA7IGRvCisgICAgaWYgJE9DQU1MQyAtYyAtSSAiJCQxIiBjb25mdGVzdC5tbCA+
JjUgMj4mNSA7IHRoZW4KKyAgICAgIGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBk
b25lCisKKyAgaWYgdGVzdCAiJGZvdW5kIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFskJDFd
KQorICBlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZvdW5kXSkKKyAgICAkMT1ubworICBm
aQorICBBQ19TVUJTVChbJDFdKQorXSkKKworCitkbmwgWFhYIENyb3NzLWNvbXBpbGluZworQUNf
REVGVU4oW0FDX0NIRUNLX09DQU1MX1dPUkRfU0laRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FD
X1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBjb21waWxlciB3
b3JkIHNpemVdKQorICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9lbmRsaW5lIChz
dHJpbmdfb2ZfaW50IFN5cy53b3JkX3NpemUpCisgIEVPRgorICBPQ0FNTF9XT1JEX1NJWkU9YCRP
Q0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX1dPUkRfU0laRV0pCisg
IEFDX1NVQlNUKFtPQ0FNTF9XT1JEX1NJWkVdKQorXSkKKworQUNfREVGVU4oW0FDX0NIRUNLX09D
QU1MX09TX1RZUEVdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKyAg
QUNfTVNHX0NIRUNLSU5HKFtPQ2FtbCBTeXMub3NfdHlwZV0pCisKKyAgY2F0ID4gY29uZnRlc3Qu
bWwgPDxFT0YKKyAgcHJpbnRfc3RyaW5nKFN5cy5vc190eXBlKTs7CitFT0YKKworICBPQ0FNTF9P
U19UWVBFPWAkT0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9PU19U
WVBFXSkKKyAgQUNfU1VCU1QoW09DQU1MX09TX1RZUEVdKQorXSkKZGlmZiAtciA4NzIxOGJkMzY3
YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL200L3BhdGhfb3JfZmFpbC5tNAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9wYXRoX29yX2Zh
aWwubTQJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsNiBAQAorQUNf
REVGVU4oW0FYX1BBVEhfUFJPR19PUl9GQUlMXSwKK1tBQ19QQVRIX1BST0coWyQxXSwgWyQyXSwg
W25vXSkKK2lmIHRlc3QgeCIkeyQxfSIgPT0geCJubyIgCit0aGVuCisgICAgQUNfTVNHX0VSUk9S
KFtVbmFibGUgdG8gZmluZCAkMiwgcGxlYXNlIGluc3RhbGwgJDJdKQorZmldKQpkaWZmIC1yIDg3
MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvcHl0aG9uX2RldmVsLm00Ci0tLSAv
ZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L3B5
dGhvbl9kZXZlbC5tNAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwx
OCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9ERVZFTF0sCitbQUNfTVNHX0NIRUNLSU5H
KFtmb3IgcHl0aG9uIGRldmVsXSkKKworYCRQWVRIT04gLWMgJworaW1wb3J0IG9zLnBhdGgsIHN5
cworZm9yIHAgaW4gc3lzLnBhdGg6CisgICAgaWYgb3MucGF0aC5leGlzdHMocCArICIvY29uZmln
L01ha2VmaWxlIik6CisgICAgICAgIHN5cy5leGl0KDApCitzeXMuZXhpdCgxKQorJyA+IC9kZXYv
bnVsbCAyPiYxYAorCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VM
VChbbm9dKQorICAgIEFDX01TR19FUlJPUihbUHl0aG9uIGRldmVsIHBhY2thZ2Ugbm90IGZvdW5k
XSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIDg3MjE4YmQz
NjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvcHl0aG9uX3ZlcnNpb24ubTQKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcHl0aG9u
X3ZlcnNpb24ubTQJTW9uIEZlYiAyMCAxODoyMDoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTIg
QEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fVkVSU0lPTl0sCitbQUNfTVNHX0NIRUNLSU5H
KFtmb3IgcHl0aG9uIHZlcnNpb24gPj0gJDEuJDIgXSkKK2AkUFlUSE9OIC1jICdpbXBvcnQgc3lz
OyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoJDEsICQyKSIpKSdgCitpZiB0ZXN0ICIk
PyIgIT0gIjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLVYgMj4mMWAKKyAg
ICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKAorICAgICAgICBbJHB5dGhv
bl92ZXJzaW9uIGlzIHRvbyBvbGQsIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBpcyAkMS4kMl0p
CitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciA4NzIxOGJkMzY3
YmUgLXIgY2NkZjllZDhhOTE0IHRvb2xzL200L3B5dGhvbl94bWwubTQKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcHl0aG9uX3htbC5t
NAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMCBAQAorQUNfREVG
VU4oW0FYX0NIRUNLX1BZVEhPTl9YTUxdLAorW0FDX01TR19DSEVDS0lORyhbZm9yIHB5dGhvbiB4
bWwuZG9tLm1pbmlkb21dKQorYCRQWVRIT04gLWMgJ2ltcG9ydCB4bWwuZG9tLm1pbmlkb20nYAor
aWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBB
Q19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kIHhtbC5kb20ubWluaWRvbSBtb2R1bGVdKQorZWxz
ZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYgLXIgODcyMThiZDM2N2JlIC1y
IGNjZGY5ZWQ4YTkxNCB0b29scy9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvc2V0X2NmbGFn
c19sZGZsYWdzLm00CU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDIw
IEBACitBQ19ERUZVTihbQVhfU0VUX0ZMQUdTXSwKK1tmb3IgY2ZsYWcgaW4gJFBSRVBFTkRfSU5D
TFVERVMKK2RvCisgICAgUFJFUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRm
bGFnIGluICRQUkVQRU5EX0xJQgorZG8KKyAgICBQUkVQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFn
IgorZG9uZQorZm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVERVMKK2RvCisgICAgQVBQRU5EX0NG
TEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4gJEFQUEVORF9MSUIKK2RvCisg
ICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorQ0ZMQUdTPSIkUFJFUEVORF9D
RkxBR1MgJENGTEFHUyAkQVBQRU5EX0NGTEFHUyIKK0xERkxBR1M9IiRQUkVQRU5EX0xERkxBR1Mg
JExERkxBR1MgJEFQUEVORF9MREZMQUdTIl0pCisKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2Nk
ZjllZDhhOTE0IHRvb2xzL200L3VkZXYubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdWRldi5tNAlNb24gRmViIDIwIDE4OjIwOjI5
IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwzMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1VERVZdLAor
W2lmIHRlc3QgIngkaG9zdF9vcyIgPT0gInhsaW51eC1nbnUiCit0aGVuCisgICAgQUNfUEFUSF9Q
Uk9HKFtVREVWQURNXSwgW3VkZXZhZG1dLCBbbm9dKQorICAgIGlmIHRlc3QgeCIke1VERVZBRE19
IiA9PSB4Im5vIiAKKyAgICB0aGVuCisgICAgICAgIEFDX1BBVEhfUFJPRyhbVURFVklORk9dLCBb
dWRldmluZm9dLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30iID09IHgibm8i
CisgICAgICAgIHRoZW4KKyAgICAgICAgICAgIEFDX01TR19FUlJPUigKKyAgICAgICAgICAgICAg
ICBbVW5hYmxlIHRvIGZpbmQgdWRldmFkbSBvciB1ZGV2aW5mbywgcGxlYXNlIGluc3RhbGwgdWRl
dl0pCisgICAgICAgIGZpCisgICAgICAgIHVkZXZ2ZXI9YCR7VURFVklORk99IC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZWxzZQorICAgICAgICB1ZGV2dmVyPWAke1VERVZBRE19IGluZm8g
LVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBmaQorICAgIGlmIHRlc3QgJHt1ZGV2dmVyfSAt
bHQgNTkKKyAgICB0aGVuCisgICAgICAgIEFDX1BBVEhfUFJPRyhbSE9UUExVR10sIFtob3RwbHVn
XSwgW25vXSkKKyAgICAgICAgaWYgdGVzdCB4IiR7SE9UUExVR30iID09IHgibm8iCisgICAgICAg
IHRoZW4KKyAgICAgICAgICAgIEFDX01TR19FUlJPUihbdWRldiBpcyB0b28gb2xkLCB1cGdyYWRl
IHRvIHZlcnNpb24gNTkgb3IgbGF0ZXJdKQorICAgICAgICBmaQorICAgIGZpCitlbHNlCisgICAg
QUNfUEFUSF9QUk9HKFtWTkNPTkZJR10sIFt2bmNvbmZpZ10sIFtub10pCisgICAgaWYgdGVzdCB4
IiR7Vk5DT05GSUd9IiA9PSB4Im5vIgorICAgIHRoZW4KKyAgICAgICAgQUNfTVNHX0VSUk9SKFtO
b3QgYSBMaW51eCBzeXN0ZW0gYW5kIHVuYWJsZSB0byBmaW5kIHZuZF0pCisgICAgZmkKK2ZpCitd
KQpkaWZmIC1yIDg3MjE4YmQzNjdiZSAtciBjY2RmOWVkOGE5MTQgdG9vbHMvbTQvdXVpZC5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC91dWlkLm00CU1vbiBGZWIgMjAgMTg6MjA6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwIEBA
CitBQ19ERUZVTihbQVhfQ0hFQ0tfVVVJRF0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxp
bnV4LWdudSIKK3RoZW4KKyAgICBBQ19DSEVDS19IRUFERVIoW3V1aWQvdXVpZC5oXSwsCisJICAg
IFtBQ19NU0dfRVJST1IoW2Nhbm5vdCBmaW5kIHV1aWQgaGVhZGVyc10pXSkKK2Vsc2UKKyAgICBB
Q19DSEVDS19IRUFERVIoW3V1aWQuaF0sLAorCSAgICBbQUNfTVNHX0VSUk9SKFtjYW5ub3QgZmlu
ZCB1dWlkIGhlYWRlcnNdKV0pCitmaQorXSkKZGlmZiAtciA4NzIxOGJkMzY3YmUgLXIgY2NkZjll
ZDhhOTE0IHZlcnNpb24uc2gKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKKysrIGIvdmVyc2lvbi5zaAlNb24gRmViIDIwIDE4OjIwOjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSw1IEBACisjIS9iaW4vc2gKKworTUFKT1I9YGdyZXAgImV4cG9ydCBYRU5fVkVSU0lP
TiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK01JTk9SPWBncmVwICJleHBvcnQg
WEVOX1NVQlZFUlNJT04iICQxIHwgc2VkICdzLy4qPS8vZycgfCB0ciAtcyAiICJgCitwcmludGYg
IiVkLiVkIiAkTUFKT1IgJE1JTk9SCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1Rzq4F-0003e0-EN; Tue, 21 Feb 2012 13:47:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bjzhang@suse.com>) id 1Rzf8D-0003gM-DE
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 02:07:05 +0000
X-Env-Sender: bjzhang@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329790018!14152833!1
X-Originating-IP: [137.65.248.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12894 invoked from network); 21 Feb 2012 02:06:58 -0000
Received: from novprvlin0050.provo.novell.com (HELO
	novprvlin0050.provo.novell.com) (137.65.248.33)
	by server-2.tower-174.messagelabs.com with SMTP;
	21 Feb 2012 02:06:58 -0000
Received: from INET-PRV1-MTA by novprvlin0050.provo.novell.com
	with Novell_GroupWise; Mon, 20 Feb 2012 19:06:57 -0700
Message-Id: <4F436CB20200003000000DE0@novprvlin0050.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 20 Feb 2012 19:06:42 -0700
From: "Bamvor Jian Zhang" <bjzhang@suse.com>
To: <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBB95BB22.0__="
X-Mailman-Approved-At: Tue, 21 Feb 2012 13:47:40 +0000
Subject: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBB95BB22.0__=
Content-Type: multipart/alternative; boundary="=__PartBB95BB22.1__="

--=__PartBB95BB22.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable




a, libxl_event.h is included in libxl.h. So, the former one also need to =
be installed. =20
b, define __XEN_TOOLS__ in libxl.h:=20
the head file "xen/sysctl.h" need check this macro. =20
It is the same way used by the xen libxc public headers(tools/libxc/xenctrl=
.h and tools/libxc/xenctrlosdep.h). =20


Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>=20


diff -r 87218bd367be tools/libxl/Makefile=20
--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/MakefileMon Feb 20 15:36:09 2012 +0800=20
@@ -163,7 +163,7 @@=20
 ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.=
so.$(XLUMAJOR)=20
 ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so=20
 $(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR)=20
-$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h $(DESTDIR)$(INCLUDEDIR)=20
+$(INSTALL_DATA) libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h =
_libxl_list.h libxl_utils.h libxl_uuid.h libxl_event.h $(DESTDIR)$(INCLUDED=
IR)=20
 $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh=20
 =20
 .PHONY: clean=20


diff -r 87218bd367be tools/libxl/libxl.h=20
--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 +0000=20
+++ b/tools/libxl/libxl.hMon Feb 20 15:36:09 2012 +0800=20
@@ -127,6 +127,11 @@=20
 #ifndef LIBXL_H=20
 #define LIBXL_H=20
 =20
+/* Tell the Xen public headers we are a user-space tools build. */=20
+#ifndef __XEN_TOOLS__=20
+#define __XEN_TOOLS__ 1=20
+#endif =20
+=20
 #include <stdbool.h>=20
 #include <stdint.h>=20
 #include <stdarg.h> 

--=__PartBB95BB22.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html>=0A  <head>=0A=0A  </head>=0A  <body content=3D"text/html; charset=3D=
UTF-8" style=3D"font-variant: normal; line-height: normal; margin-right: =
4px; margin-left: 4px; margin-bottom: 1px; margin-top: 4px" http-equiv=3D"C=
ontent-Type">=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<br>=0A          </p>=0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">a&#44; =
libxl_event.h is included in libxl.h. So&#44; the former one also need to =
be installed. </font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">b&#4=
4; define __XEN_TOOLS__ in libxl.h:</font>    </p>=0A    <p style=3D"margin=
-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">the head file &quot;xen/sysctl.h&quot; need check this macro. =
</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A     =
 <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">It is the same way used by =
the xen libxc public headers&#40;tools/libxc/xenctrl.h and tools/libxc/xenc=
trlosdep.h&#41;. </font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <br>=0A          </p>=0A    <p style=3D"margin-bott=
om: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">Signed-off-by: Bamvor Jian Zhang &lt;bjzhang@suse.com&gt;</font>=
    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<br>=0A          </p>=0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/Makefile</font>    </p>=0A    <p style=3D"margin-b=
ottom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/MakefileFri Feb 17 12:24:38 2012 &#43;0000</fo=
nt>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/MakefileMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -163&#44;7 &#43;163&#44;7 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;ln -sf libxlutil.so.&#36;&#4=
0;XLUMAJOR&#41;.&#36;&#40;XLUMINOR&#41; &#36;&#40;DESTDIR&#41;&#36;&#40;LIB=
DIR&#41;/libxlutil.so.&#36;&#40;XLUMAJOR&#41;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#160;ln -sf libxlutil.so.&#36;&#40;XLUMAJOR&#41=
; &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;/libxlutil.so</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#36;&#40;INSTALL_DATA&#41; =
libxlutil.a &#36;&#40;DESTDIR&#41;&#36;&#40;LIBDIR&#41;</font>    </p>=0A  =
  <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR =
PL ShanHeiSun Uni" size=3D"4">-&#36;&#40;INSTALL_DATA&#41; libxl.h =
libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h libxl_utils.h=
 libxl_uuid.h &#36;&#40;DESTDIR&#41;&#36;&#40;INCLUDEDIR&#41;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#36;&#40;INSTALL_DATA&#41; =
libxl.h libxl_json.h _libxl_types.h _libxl_types_json.h _libxl_list.h =
libxl_utils.h libxl_uuid.h libxl_event.h &#36;&#40;DESTDIR&#41;&#36;&#40;IN=
CLUDEDIR&#41;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top=
: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#36;&#4=
0;INSTALL_DATA&#41; bash-completion &#36;&#40;DESTDIR&#41;&#36;&#40;BASH_CO=
MPLETION_DIR&#41;/xl.sh</font>    </p>=0A    <p style=3D"margin-bottom: 0; =
margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#16=
0;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A   =
   <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;.PHONY: clean</font=
>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<br>=0A          </p>=0A    <p style=3D"margin-bottom: 0; margin-top: =
0">=0A      <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">diff -r =
87218bd367be tools/libxl/libxl.h</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">--- a/tools/libxl/libxl.hFri Feb 17 12:24:38 2012 &#43;0000</fon=
t>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      =
<font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#43;&#43; b/tools/libx=
l/libxl.hMon Feb 20 15:36:09 2012 &#43;0800</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">@@ -127&#44;6 &#43;127&#44;11 @@</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;ifndef LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;define LIBXL_H</font>  =
  </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;/&#42; Tell the Xen public headers we are =
a user-space tools build. &#42;/</font>    </p>=0A    <p style=3D"margin-bo=
ttom: 0; margin-top: 0">=0A      <font face=3D"AR PL ShanHeiSun Uni" =
size=3D"4">&#43;&#35;ifndef __XEN_TOOLS__</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#43;&#35;define __XEN_TOOLS__ 1</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;&#35;endif </font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#43;</font>    </p>=0A    <p =
style=3D"margin-bottom: 0; margin-top: 0">=0A      <font face=3D"AR PL =
ShanHeiSun Uni" size=3D"4">&#160;&#35;include &lt;stdbool.h&gt;</font>    =
</p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A      <font =
face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;include &lt;stdint.h&gt=
;</font>    </p>=0A    <p style=3D"margin-bottom: 0; margin-top: 0">=0A    =
  <font face=3D"AR PL ShanHeiSun Uni" size=3D"4">&#160;&#35;include =
&lt;stdarg.h&gt;</font>=0A    </p>=0A  </body>=0A</html>=0A

--=__PartBB95BB22.1__=--

--=__PartBB95BB22.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

--=__PartBB95BB22.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 21 13:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1Rzq5T-00046j-M6; Tue, 21 Feb 2012 13:48:59 +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 1Rzq5S-00045g-Ck
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 13:48:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329832076!57596838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16444 invoked from network); 21 Feb 2012 13:47:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:48:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:48:54 +0000
Message-ID: <1329832132.3990.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 13:48:52 +0000
In-Reply-To: <CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
	<CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTIxIGF0IDEyOjU5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
OgoKYXJtOiBtb3ZlIGNoZWNrIGZvciBDT05GSUdfRFRCX0ZJTEUgdG8geGVuL2FyY2gvYXJtL01h
a2VmaWxlCgpDT05GSUdfRFRCX0ZJTEUgb25seSBuZWVkcyB0byBiZSBzZXQgd2hlbiBidWlsZGlu
ZyBYZW4gaXRzZWxmLgoKU2lnbmVkLW9mZi1ieTogRGF2aWQgVnJhYmVsIDxkYXZpZC52cmFiZWxA
Y2l0cml4LmNvbT5JJ20gZG9pbmcgYSBmcmVzaApjaGVja291dCBhbmQgSSB3aWxsIHRyeSB0byBy
ZXByb2R1Y2UgdGhlIGVycm9yLAo+IGZvbGxvd2luZyB0aGUgc2FtZSBzdGVwcy4KCkBAIC00MCwx
MSArNDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdDogZGlzdC14
ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRpc3QtZG9jcyBkaXN0LW1p
c2MKIAogZGlzdC1taXNjOgotICAgICAgICQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hlY2sK
ClByZXZpb3VzbHkgdGhpcyB3b3VsZCBoYXZlIGltcGxpY2l0bHkgYWxzbyBjcmVhdGVkICQoRElT
VERJUikgSSB0aGluawp5b3Ugd2FudDoKLSAgICAgICAkKElOU1RBTExfRElSKSAkKERJU1RESVIp
L2NoZWNrCisgICAgICAgJChJTlNUQUxMX0RJUikgJChESVNURElSKS8KCklhbi4KCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1Rzq5T-00046j-M6; Tue, 21 Feb 2012 13:48:59 +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 1Rzq5S-00045g-Ck
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 13:48:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1329832076!57596838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16444 invoked from network); 21 Feb 2012 13:47:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10844952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:48:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:48:54 +0000
Message-ID: <1329832132.3990.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 13:48:52 +0000
In-Reply-To: <CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
	<CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTIxIGF0IDEyOjU5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
OgoKYXJtOiBtb3ZlIGNoZWNrIGZvciBDT05GSUdfRFRCX0ZJTEUgdG8geGVuL2FyY2gvYXJtL01h
a2VmaWxlCgpDT05GSUdfRFRCX0ZJTEUgb25seSBuZWVkcyB0byBiZSBzZXQgd2hlbiBidWlsZGlu
ZyBYZW4gaXRzZWxmLgoKU2lnbmVkLW9mZi1ieTogRGF2aWQgVnJhYmVsIDxkYXZpZC52cmFiZWxA
Y2l0cml4LmNvbT5JJ20gZG9pbmcgYSBmcmVzaApjaGVja291dCBhbmQgSSB3aWxsIHRyeSB0byBy
ZXByb2R1Y2UgdGhlIGVycm9yLAo+IGZvbGxvd2luZyB0aGUgc2FtZSBzdGVwcy4KCkBAIC00MCwx
MSArNDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdDogZGlzdC14
ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRpc3QtZG9jcyBkaXN0LW1p
c2MKIAogZGlzdC1taXNjOgotICAgICAgICQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hlY2sK
ClByZXZpb3VzbHkgdGhpcyB3b3VsZCBoYXZlIGltcGxpY2l0bHkgYWxzbyBjcmVhdGVkICQoRElT
VERJUikgSSB0aGluawp5b3Ugd2FudDoKLSAgICAgICAkKElOU1RBTExfRElSKSAkKERJU1RESVIp
L2NoZWNrCisgICAgICAgJChJTlNUQUxMX0RJUikgJChESVNURElSKS8KCklhbi4KCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq68-0004I2-4U; Tue, 21 Feb 2012 13:49:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rzq66-0004Fj-PT
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:49:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329832171!14247982!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 578 invoked from network); 21 Feb 2012 13:49:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291784"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:49:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:49:30 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-EK;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4f3e3d7016735b6c7a28581097b332b8e30df6ee
Message-ID: <4f3e3d7016735b6c7a28.1329831256@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:16 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule
 parameter command-line 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

Add features to the sched-credit interface to allow querying and
displaying scheduler parameters.  New interface works as follows:

 <nothing>             : List all domain params and sched params from all pools
 -d [domid]            : List domain params for domain
 -d [domid] [params]   : Set domain params for domain
 -p [pool]             : list all domains and sched params for pool
 -s                    : List sched params for poolid 0
 -s [params]           : Set sched params for poolid 0
 -p [pool] -s          : List sched params for pool
 -p [pool] -s [params] : Set sched params for pool
 -p [pool] -d...       : Illegal

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6dc39f1a7167 -r 4f3e3d701673 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:15 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:18 2012 +0000
@@ -3936,6 +3936,30 @@ static int sched_credit_domain_set(
     return rc;
 }
 
+static int sched_credit_param_set(
+    int poolid, libxl_sched_credit_param *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_param_set(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_param_set failed.\n");
+
+    return rc;
+}
+
+static int sched_credit_param_get(
+    int poolid, libxl_sched_credit_param *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_param_get(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_domain_get failed.\n");
+
+    return rc;
+}
+
 static int sched_credit_domain_output(
     int domid)
 {
@@ -3960,6 +3984,25 @@ static int sched_credit_domain_output(
     return 0;
 }
 
+static int sched_credit_pool_output(
+    uint32_t poolid)
+{
+    libxl_sched_credit_param scparam;
+    char *poolname;
+    int rc;
+
+    rc = sched_credit_param_get(poolid, &scparam);
+    if (rc)
+        return rc;
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    printf("Cpupool %s: tslice=%dms ratelimit=%dus\n",
+           poolname,
+           scparam.tslice_ms,
+           scparam.ratelimit_us);
+    free(poolname);
+    return 0;
+}
+
 static int sched_credit2_domain_get(
     int domid, libxl_sched_credit2_domain *scinfo)
 {
@@ -4123,25 +4166,41 @@ static int sched_domain_output(
     return 0;
 }
 
+/* 
+ * <nothing>             : List all domain params and sched params from all pools
+ * -d [domid]            : List domain params for domain
+ * -d [domid] [params]   : Set domain params for domain
+ * -p [pool]             : list all domains and sched params for pool
+ * -s                    : List sched params for poolid 0
+ * -s [params]           : Set sched params for poolid 0
+ * -p [pool] -s          : List sched params for pool
+ * -p [pool] -s [params] : Set sched params for pool
+ * -p [pool] -d...       : Illegal
+ */
 int main_sched_credit(int argc, char **argv)
 {
     libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
+    int opt_s = 0;
+    int tslice = 0, opt_t = 0, ratelimit = 0, opt_r = 0;
     int opt, rc;
     int option_index = 0;
     static struct option long_options[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
+        {"schedparam", 0, 0, 's'},
+        {"tslice_ms", 1, 0, 't'},
+        {"ratelimit_us", 1, 0, 'r'},
         {"cpupool", 1, 0, 'p'},
         {"help", 0, 0, 'h'},
         {0, 0, 0, 0}
     };
 
     while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:p:h", long_options,
+        opt = getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_options,
                           &option_index);
         if (opt == -1)
             break;
@@ -4159,6 +4218,17 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 't':
+            tslice = strtol(optarg, NULL, 10);
+            opt_t = 1;
+            break;
+        case 'r':
+            ratelimit = strtol(optarg, NULL, 10);
+            opt_r = 1;
+            break;
+        case 's':
+            opt_s = 1;
+            break;
         case 'p':
             cpupool = optarg;
             break;
@@ -4168,20 +4238,54 @@ int main_sched_credit(int argc, char **a
         }
     }
 
-    if (cpupool && (dom || opt_w || opt_c)) {
-        fprintf(stderr, "Specifying a cpupool is not allowed with other "
-                "options.\n");
+    if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
+        fprintf(stderr, "Specifying a cpupool or schedparam is not "
+                "allowed with domain options.\n");
         return 1;
     }
     if (!dom && (opt_w || opt_c)) {
         fprintf(stderr, "Must specify a domain.\n");
         return 1;
     }
-
-    if (!dom) { /* list all domain's credit scheduler info */
+    if (!opt_s && (opt_t || opt_r)) {
+        fprintf(stderr, "Must specify schedparam to set schedule "
+                "parameter values.\n");
+        return 1;
+    }
+
+    if (opt_s) {
+        libxl_sched_credit_param  scparam;
+        uint32_t poolid = 0;
+
+        if (cpupool) {
+            if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
+                !libxl_cpupoolid_to_name(ctx, poolid)) {
+                fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+                return -ERROR_FAIL;
+            }
+        }
+
+        if (!opt_t && !opt_r) { /* Output scheduling parameters */
+            return -sched_credit_pool_output(poolid);
+        } else { /* Set scheduling parameters*/
+            rc = sched_credit_param_get(poolid, &scparam);
+            if (rc)
+                return -rc;
+
+            if (opt_t)
+                scparam.tslice_ms = tslice;
+
+            if (opt_r)
+                scparam.ratelimit_us = ratelimit;
+
+            rc = sched_credit_param_set(poolid, &scparam);
+            if (rc)
+                return -rc;
+        }
+    } else if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
                                     sched_credit_domain_output,
-                                    sched_default_pool_output,
+                                    sched_credit_pool_output,
                                     cpupool);
     } else {
         find_domain(dom);
diff -r 6dc39f1a7167 -r 4f3e3d701673 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Tue Feb 21 12:17:15 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Tue Feb 21 12:17:18 2012 +0000
@@ -204,11 +204,14 @@ struct cmd_spec cmd_table[] = {
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",
-      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-p CPUPOOL]",
-      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
-      "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
-      "-c CAP, --cap=CAP              Cap (int)\n"
-      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
+      "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
+      "-w WEIGHT, --weight=WEIGHT        Weight (int)\n"
+      "-c CAP, --cap=CAP                 Cap (int)\n"
+      "-s         --schedparam           Query / modify scheduler parameters\n"
+      "-t TSLICE, --tslice_ms=TSLICE     Set the timeslice, in milliseconds\n"
+      "-r RLIMIT, --ratelimit_us=RLIMIT  Set the scheduling rate limit, in microseconds\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
       &main_sched_credit2, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzq68-0004I2-4U; Tue, 21 Feb 2012 13:49:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rzq66-0004Fj-PT
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:49:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329832171!14247982!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 578 invoked from network); 21 Feb 2012 13:49:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 13:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="22291784"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 08:49:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 08:49:30 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1RzpvH-000899-EK;
	Tue, 21 Feb 2012 13:38:27 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4f3e3d7016735b6c7a28581097b332b8e30df6ee
Message-ID: <4f3e3d7016735b6c7a28.1329831256@kodo2>
In-Reply-To: <patchbomb.1329831246@kodo2>
References: <patchbomb.1329831246@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 21 Feb 2012 13:34:16 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule
 parameter command-line 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

Add features to the sched-credit interface to allow querying and
displaying scheduler parameters.  New interface works as follows:

 <nothing>             : List all domain params and sched params from all pools
 -d [domid]            : List domain params for domain
 -d [domid] [params]   : Set domain params for domain
 -p [pool]             : list all domains and sched params for pool
 -s                    : List sched params for poolid 0
 -s [params]           : Set sched params for poolid 0
 -p [pool] -s          : List sched params for pool
 -p [pool] -s [params] : Set sched params for pool
 -p [pool] -d...       : Illegal

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6dc39f1a7167 -r 4f3e3d701673 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:15 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 21 12:17:18 2012 +0000
@@ -3936,6 +3936,30 @@ static int sched_credit_domain_set(
     return rc;
 }
 
+static int sched_credit_param_set(
+    int poolid, libxl_sched_credit_param *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_param_set(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_param_set failed.\n");
+
+    return rc;
+}
+
+static int sched_credit_param_get(
+    int poolid, libxl_sched_credit_param *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_param_get(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_domain_get failed.\n");
+
+    return rc;
+}
+
 static int sched_credit_domain_output(
     int domid)
 {
@@ -3960,6 +3984,25 @@ static int sched_credit_domain_output(
     return 0;
 }
 
+static int sched_credit_pool_output(
+    uint32_t poolid)
+{
+    libxl_sched_credit_param scparam;
+    char *poolname;
+    int rc;
+
+    rc = sched_credit_param_get(poolid, &scparam);
+    if (rc)
+        return rc;
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    printf("Cpupool %s: tslice=%dms ratelimit=%dus\n",
+           poolname,
+           scparam.tslice_ms,
+           scparam.ratelimit_us);
+    free(poolname);
+    return 0;
+}
+
 static int sched_credit2_domain_get(
     int domid, libxl_sched_credit2_domain *scinfo)
 {
@@ -4123,25 +4166,41 @@ static int sched_domain_output(
     return 0;
 }
 
+/* 
+ * <nothing>             : List all domain params and sched params from all pools
+ * -d [domid]            : List domain params for domain
+ * -d [domid] [params]   : Set domain params for domain
+ * -p [pool]             : list all domains and sched params for pool
+ * -s                    : List sched params for poolid 0
+ * -s [params]           : Set sched params for poolid 0
+ * -p [pool] -s          : List sched params for pool
+ * -p [pool] -s [params] : Set sched params for pool
+ * -p [pool] -d...       : Illegal
+ */
 int main_sched_credit(int argc, char **argv)
 {
     libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
+    int opt_s = 0;
+    int tslice = 0, opt_t = 0, ratelimit = 0, opt_r = 0;
     int opt, rc;
     int option_index = 0;
     static struct option long_options[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
+        {"schedparam", 0, 0, 's'},
+        {"tslice_ms", 1, 0, 't'},
+        {"ratelimit_us", 1, 0, 'r'},
         {"cpupool", 1, 0, 'p'},
         {"help", 0, 0, 'h'},
         {0, 0, 0, 0}
     };
 
     while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:p:h", long_options,
+        opt = getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_options,
                           &option_index);
         if (opt == -1)
             break;
@@ -4159,6 +4218,17 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 't':
+            tslice = strtol(optarg, NULL, 10);
+            opt_t = 1;
+            break;
+        case 'r':
+            ratelimit = strtol(optarg, NULL, 10);
+            opt_r = 1;
+            break;
+        case 's':
+            opt_s = 1;
+            break;
         case 'p':
             cpupool = optarg;
             break;
@@ -4168,20 +4238,54 @@ int main_sched_credit(int argc, char **a
         }
     }
 
-    if (cpupool && (dom || opt_w || opt_c)) {
-        fprintf(stderr, "Specifying a cpupool is not allowed with other "
-                "options.\n");
+    if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
+        fprintf(stderr, "Specifying a cpupool or schedparam is not "
+                "allowed with domain options.\n");
         return 1;
     }
     if (!dom && (opt_w || opt_c)) {
         fprintf(stderr, "Must specify a domain.\n");
         return 1;
     }
-
-    if (!dom) { /* list all domain's credit scheduler info */
+    if (!opt_s && (opt_t || opt_r)) {
+        fprintf(stderr, "Must specify schedparam to set schedule "
+                "parameter values.\n");
+        return 1;
+    }
+
+    if (opt_s) {
+        libxl_sched_credit_param  scparam;
+        uint32_t poolid = 0;
+
+        if (cpupool) {
+            if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
+                !libxl_cpupoolid_to_name(ctx, poolid)) {
+                fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+                return -ERROR_FAIL;
+            }
+        }
+
+        if (!opt_t && !opt_r) { /* Output scheduling parameters */
+            return -sched_credit_pool_output(poolid);
+        } else { /* Set scheduling parameters*/
+            rc = sched_credit_param_get(poolid, &scparam);
+            if (rc)
+                return -rc;
+
+            if (opt_t)
+                scparam.tslice_ms = tslice;
+
+            if (opt_r)
+                scparam.ratelimit_us = ratelimit;
+
+            rc = sched_credit_param_set(poolid, &scparam);
+            if (rc)
+                return -rc;
+        }
+    } else if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
                                     sched_credit_domain_output,
-                                    sched_default_pool_output,
+                                    sched_credit_pool_output,
                                     cpupool);
     } else {
         find_domain(dom);
diff -r 6dc39f1a7167 -r 4f3e3d701673 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Tue Feb 21 12:17:15 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Tue Feb 21 12:17:18 2012 +0000
@@ -204,11 +204,14 @@ struct cmd_spec cmd_table[] = {
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",
-      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-p CPUPOOL]",
-      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
-      "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
-      "-c CAP, --cap=CAP              Cap (int)\n"
-      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
+      "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
+      "-w WEIGHT, --weight=WEIGHT        Weight (int)\n"
+      "-c CAP, --cap=CAP                 Cap (int)\n"
+      "-s         --schedparam           Query / modify scheduler parameters\n"
+      "-t TSLICE, --tslice_ms=TSLICE     Set the timeslice, in milliseconds\n"
+      "-r RLIMIT, --ratelimit_us=RLIMIT  Set the scheduling rate limit, in microseconds\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
       &main_sched_credit2, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1RzqD1-0005YB-4I; Tue, 21 Feb 2012 13:56:47 +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 1RzqD0-0005Xx-Db
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:56:46 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329832553!61444838!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9846 invoked from network); 21 Feb 2012 13:55:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Feb 2012 13:55:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RzqCx-0006XO-1L
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 05:56:43 -0800
Date: Tue, 21 Feb 2012 05:56:43 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329832603031-5502259.post@n5.nabble.com>
In-Reply-To: <CAHyyzzRRDgcMJnXhSf3iqPBKMFJScOCdmRn_pUYQqBeejMv+Lw@mail.gmail.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
	<1329485681.3131.77.camel@zakaz.uk.xensource.com>
	<1329485817436-5492514.post@n5.nabble.com>
	<CAHyyzzRRDgcMJnXhSf3iqPBKMFJScOCdmRn_pUYQqBeejMv+Lw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wheezy (Debian 7) after the 2 patches and change about /usr/lib is
working.

@jacek burghardt: 
where you are installing Xen?
yajl2 is installed?
The patches are applied correctly, the second need change for lines not
matching.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5502259.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1RzqD1-0005YB-4I; Tue, 21 Feb 2012 13:56:47 +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 1RzqD0-0005Xx-Db
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 13:56:46 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329832553!61444838!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9846 invoked from network); 21 Feb 2012 13:55:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Feb 2012 13:55:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RzqCx-0006XO-1L
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 05:56:43 -0800
Date: Tue, 21 Feb 2012 05:56:43 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329832603031-5502259.post@n5.nabble.com>
In-Reply-To: <CAHyyzzRRDgcMJnXhSf3iqPBKMFJScOCdmRn_pUYQqBeejMv+Lw@mail.gmail.com>
References: <CAHyyzzRN6FxtxHPfsZEt+xFa7hdgPKxcH12kBcMaEHehMA1_ZA@mail.gmail.com>
	<1329466930.8012.8.camel@dagon.hellion.org.uk>
	<1329467829314-5491845.post@n5.nabble.com>
	<1329476778668-5492170.post@n5.nabble.com>
	<1329480107.3131.47.camel@zakaz.uk.xensource.com>
	<1329481575617-5492321.post@n5.nabble.com>
	<1329484462005-5492438.post@n5.nabble.com>
	<1329485681.3131.77.camel@zakaz.uk.xensource.com>
	<1329485817436-5492514.post@n5.nabble.com>
	<CAHyyzzRRDgcMJnXhSf3iqPBKMFJScOCdmRn_pUYQqBeejMv+Lw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xl_cmdimpl.c errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wheezy (Debian 7) after the 2 patches and change about /usr/lib is
working.

@jacek burghardt: 
where you are installing Xen?
yajl2 is installed?
The patches are applied correctly, the second need change for lines not
matching.

--
View this message in context: http://xen.1045712.n5.nabble.com/xl-cmdimpl-c-errors-tp5491537p5502259.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzqEX-0005iv-Mv; Tue, 21 Feb 2012 13:58:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqEV-0005iI-SJ
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 13:58:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329832692!14281207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22925 invoked from network); 21 Feb 2012 13:58: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;
	21 Feb 2012 13:58:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:58:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:58:12 +0000
Message-ID: <1329832691.3990.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 13:58:11 +0000
In-Reply-To: <1329832132.3990.85.camel@zakaz.uk.xensource.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
	<CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
	<1329832132.3990.85.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTIxIGF0IDEzOjQ4ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gVHVlLCAyMDEyLTAyLTIxIGF0IDEyOjU5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IAo+IGFybTogbW92ZSBjaGVjayBmb3IgQ09ORklHX0RUQl9GSUxFIHRvIHhlbi9hcmNoL2Fy
bS9NYWtlZmlsZQo+IAo+IENPTkZJR19EVEJfRklMRSBvbmx5IG5lZWRzIHRvIGJlIHNldCB3aGVu
IGJ1aWxkaW5nIFhlbiBpdHNlbGYuCj4gCj4gU2lnbmVkLW9mZi1ieTogRGF2aWQgVnJhYmVsIDxk
YXZpZC52cmFiZWxAY2l0cml4LmNvbT4KCk9vcHMsIHBhc3RlZCBzb21ldGhpbmcgaGVyZSB1bmlu
dGVudGlvbmFsbHkhCgo+IEknbSBkb2luZyBhIGZyZXNoCj4gY2hlY2tvdXQgYW5kIEkgd2lsbCB0
cnkgdG8gcmVwcm9kdWNlIHRoZSBlcnJvciwKPiA+IGZvbGxvd2luZyB0aGUgc2FtZSBzdGVwcy4K
PiAKPiBAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwK
PiAgZGlzdDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRp
c3QtZG9jcyBkaXN0LW1pc2MKPiAgCj4gIGRpc3QtbWlzYzoKPiAtICAgICAgICQoSU5TVEFMTF9E
SVIpICQoRElTVERJUikvY2hlY2sKPiAKPiBQcmV2aW91c2x5IHRoaXMgd291bGQgaGF2ZSBpbXBs
aWNpdGx5IGFsc28gY3JlYXRlZCAkKERJU1RESVIpIEkgdGhpbmsKPiB5b3Ugd2FudDoKPiAtICAg
ICAgICQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hlY2sKPiArICAgICAgICQoSU5TVEFMTF9E
SVIpICQoRElTVERJUikvCj4gCj4gSWFuLgo+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 13:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 13: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 1RzqEX-0005iv-Mv; Tue, 21 Feb 2012 13:58:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqEV-0005iI-SJ
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 13:58:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329832692!14281207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22925 invoked from network); 21 Feb 2012 13:58: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;
	21 Feb 2012 13:58:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:58:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:58:12 +0000
Message-ID: <1329832691.3990.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 21 Feb 2012 13:58:11 +0000
In-Reply-To: <1329832132.3990.85.camel@zakaz.uk.xensource.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
	<CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
	<1329832132.3990.85.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTIxIGF0IDEzOjQ4ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gVHVlLCAyMDEyLTAyLTIxIGF0IDEyOjU5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IAo+IGFybTogbW92ZSBjaGVjayBmb3IgQ09ORklHX0RUQl9GSUxFIHRvIHhlbi9hcmNoL2Fy
bS9NYWtlZmlsZQo+IAo+IENPTkZJR19EVEJfRklMRSBvbmx5IG5lZWRzIHRvIGJlIHNldCB3aGVu
IGJ1aWxkaW5nIFhlbiBpdHNlbGYuCj4gCj4gU2lnbmVkLW9mZi1ieTogRGF2aWQgVnJhYmVsIDxk
YXZpZC52cmFiZWxAY2l0cml4LmNvbT4KCk9vcHMsIHBhc3RlZCBzb21ldGhpbmcgaGVyZSB1bmlu
dGVudGlvbmFsbHkhCgo+IEknbSBkb2luZyBhIGZyZXNoCj4gY2hlY2tvdXQgYW5kIEkgd2lsbCB0
cnkgdG8gcmVwcm9kdWNlIHRoZSBlcnJvciwKPiA+IGZvbGxvd2luZyB0aGUgc2FtZSBzdGVwcy4K
PiAKPiBAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwK
PiAgZGlzdDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1zdHViZG9tIGRp
c3QtZG9jcyBkaXN0LW1pc2MKPiAgCj4gIGRpc3QtbWlzYzoKPiAtICAgICAgICQoSU5TVEFMTF9E
SVIpICQoRElTVERJUikvY2hlY2sKPiAKPiBQcmV2aW91c2x5IHRoaXMgd291bGQgaGF2ZSBpbXBs
aWNpdGx5IGFsc28gY3JlYXRlZCAkKERJU1RESVIpIEkgdGhpbmsKPiB5b3Ugd2FudDoKPiAtICAg
ICAgICQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvY2hlY2sKPiArICAgICAgICQoSU5TVEFMTF9E
SVIpICQoRElTVERJUikvCj4gCj4gSWFuLgo+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:03:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqJM-0006Fg-M2; Tue, 21 Feb 2012 14:03:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzqJL-0006FH-0I
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 14:03:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329832992!14264877!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30018 invoked from network); 21 Feb 2012 14:03:12 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:03:12 -0000
Received: by werh12 with SMTP id h12so5068881wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 06:03:12 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr32689530wib.3.1329832992185
	(num_hops = 1); Tue, 21 Feb 2012 06:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=DrlzFLorw/vwHf7i4dN+nw267IsSmQ5fK132Nl4O4+U=;
	b=TwDsXJ7Tv/eOVNVaSVswsftSYK7ZZt89JsRFsCWIODSmo8HWi+isJA/9jZwTMbWR0G
	gh+2/LxSR/rBHtE6iWm2VpD4nz7qq6roEPS9jJdlwQBF20DLbyQTAJfoLGdgPrvvrPVb
	m7LBZJgDU1cgT1Rry06vx3Wa/aWD7RMm2Be/s=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr27265867wib.3.1329832991957; Tue,
	21 Feb 2012 06:03:11 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 06:03:11 -0800 (PST)
In-Reply-To: <1329832691.3990.89.camel@zakaz.uk.xensource.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
	<CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
	<1329832132.3990.85.camel@zakaz.uk.xensource.com>
	<1329832691.3990.89.camel@zakaz.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:03:11 +0100
X-Google-Sender-Auth: 6M-FREdtotV3qJ9SVKDPtqHMQAQ
Message-ID: <CAPLaKK7_14YxddovDDtOhAZu+zH=VpG8Pz5_qTsn3B0K4a7JxA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMi0yMSBhdCAxMzo0OCArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+PiBPbiBU
dWUsIDIwMTItMDItMjEgYXQgMTI6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
Cj4+IGFybTogbW92ZSBjaGVjayBmb3IgQ09ORklHX0RUQl9GSUxFIHRvIHhlbi9hcmNoL2FybS9N
YWtlZmlsZQo+Pgo+PiBDT05GSUdfRFRCX0ZJTEUgb25seSBuZWVkcyB0byBiZSBzZXQgd2hlbiBi
dWlsZGluZyBYZW4gaXRzZWxmLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBWcmFiZWwgPGRh
dmlkLnZyYWJlbEBjaXRyaXguY29tPgo+Cj4gT29wcywgcGFzdGVkIHNvbWV0aGluZyBoZXJlIHVu
aW50ZW50aW9uYWxseSEKPgo+PiBJJ20gZG9pbmcgYSBmcmVzaAo+PiBjaGVja291dCBhbmQgSSB3
aWxsIHRyeSB0byByZXByb2R1Y2UgdGhlIGVycm9yLAo+PiA+IGZvbGxvd2luZyB0aGUgc2FtZSBz
dGVwcy4KPj4KPj4gQEAgLTQwLDExICs0MCw5IEBAIGRpc3Q6IERFU1RESVI9JChESVNURElSKS9p
bnN0YWxsCj4+IMKgZGlzdDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1z
dHViZG9tIGRpc3QtZG9jcyBkaXN0LW1pc2MKPj4KPj4gwqBkaXN0LW1pc2M6Cj4+IC0gwqAgwqAg
wqAgJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawo+Pgo+PiBQcmV2aW91c2x5IHRoaXMg
d291bGQgaGF2ZSBpbXBsaWNpdGx5IGFsc28gY3JlYXRlZCAkKERJU1RESVIpIEkgdGhpbmsKPj4g
eW91IHdhbnQ6Cj4+IC0gwqAgwqAgwqAgJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawo+
PiArIMKgIMKgIMKgICQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvCgpZZXMsIGl0J3MgcHJvYmFi
bHkgdGhpcyB0aGF0J3MgY2F1c2luZyB0aGUgZXJyb3IsIHdoYXQgSSBkb24ndAp1bmRlcnN0YW5k
IGlzIHdoeSBpdCBoYXMgbmV2ZXIgaGFwcGVuZWQgdG8gbWUsIEkndmUgZG9uZSBhIGZyZXNoIHRl
c3QKb2YgdGhpcyBwYXRjaCBtb3JlIHRoYW4gb25jZS4gUHJvYmFibHkgZGlzdC1taXNjIHRhcmdl
dCB3YXMgZXhlY3V0ZWQKYWZ0ZXIgc29tZSBvdGhlciB0YXJnZXQgYWxyZWFkeSBjcmVhdGVkIHRo
ZSBkaXN0IGZvbGRlci4KClRoYW5rcywgSSB3aWxsIHBvc3QgYW4gdXBkYXRlZCB2ZXJzaW9uIChh
Z2FpbikuCgo+Pgo+PiBJYW4uCj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKPj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4KPgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:03:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqJM-0006Fg-M2; Tue, 21 Feb 2012 14:03:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzqJL-0006FH-0I
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 14:03:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329832992!14264877!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30018 invoked from network); 21 Feb 2012 14:03:12 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:03:12 -0000
Received: by werh12 with SMTP id h12so5068881wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 06:03:12 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr32689530wib.3.1329832992185
	(num_hops = 1); Tue, 21 Feb 2012 06:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=DrlzFLorw/vwHf7i4dN+nw267IsSmQ5fK132Nl4O4+U=;
	b=TwDsXJ7Tv/eOVNVaSVswsftSYK7ZZt89JsRFsCWIODSmo8HWi+isJA/9jZwTMbWR0G
	gh+2/LxSR/rBHtE6iWm2VpD4nz7qq6roEPS9jJdlwQBF20DLbyQTAJfoLGdgPrvvrPVb
	m7LBZJgDU1cgT1Rry06vx3Wa/aWD7RMm2Be/s=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr27265867wib.3.1329832991957; Tue,
	21 Feb 2012 06:03:11 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 06:03:11 -0800 (PST)
In-Reply-To: <1329832691.3990.89.camel@zakaz.uk.xensource.com>
References: <3bd6a7f9d07d888f4096.1329788138@build.localdomain>
	<20291.37671.962922.464807@mariner.uk.xensource.com>
	<CAPLaKK62FGRd9+62u+XY6F7XStL7dr-E8xZDQgMT=8brU05+iw@mail.gmail.com>
	<1329832132.3990.85.camel@zakaz.uk.xensource.com>
	<1329832691.3990.89.camel@zakaz.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:03:11 +0100
X-Google-Sender-Auth: 6M-FREdtotV3qJ9SVKDPtqHMQAQ
Message-ID: <CAPLaKK7_14YxddovDDtOhAZu+zH=VpG8Pz5_qTsn3B0K4a7JxA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMi0yMSBhdCAxMzo0OCArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+PiBPbiBU
dWUsIDIwMTItMDItMjEgYXQgMTI6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
Cj4+IGFybTogbW92ZSBjaGVjayBmb3IgQ09ORklHX0RUQl9GSUxFIHRvIHhlbi9hcmNoL2FybS9N
YWtlZmlsZQo+Pgo+PiBDT05GSUdfRFRCX0ZJTEUgb25seSBuZWVkcyB0byBiZSBzZXQgd2hlbiBi
dWlsZGluZyBYZW4gaXRzZWxmLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBWcmFiZWwgPGRh
dmlkLnZyYWJlbEBjaXRyaXguY29tPgo+Cj4gT29wcywgcGFzdGVkIHNvbWV0aGluZyBoZXJlIHVu
aW50ZW50aW9uYWxseSEKPgo+PiBJJ20gZG9pbmcgYSBmcmVzaAo+PiBjaGVja291dCBhbmQgSSB3
aWxsIHRyeSB0byByZXByb2R1Y2UgdGhlIGVycm9yLAo+PiA+IGZvbGxvd2luZyB0aGUgc2FtZSBz
dGVwcy4KPj4KPj4gQEAgLTQwLDExICs0MCw5IEBAIGRpc3Q6IERFU1RESVI9JChESVNURElSKS9p
bnN0YWxsCj4+IMKgZGlzdDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlzdC1z
dHViZG9tIGRpc3QtZG9jcyBkaXN0LW1pc2MKPj4KPj4gwqBkaXN0LW1pc2M6Cj4+IC0gwqAgwqAg
wqAgJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawo+Pgo+PiBQcmV2aW91c2x5IHRoaXMg
d291bGQgaGF2ZSBpbXBsaWNpdGx5IGFsc28gY3JlYXRlZCAkKERJU1RESVIpIEkgdGhpbmsKPj4g
eW91IHdhbnQ6Cj4+IC0gwqAgwqAgwqAgJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjawo+
PiArIMKgIMKgIMKgICQoSU5TVEFMTF9ESVIpICQoRElTVERJUikvCgpZZXMsIGl0J3MgcHJvYmFi
bHkgdGhpcyB0aGF0J3MgY2F1c2luZyB0aGUgZXJyb3IsIHdoYXQgSSBkb24ndAp1bmRlcnN0YW5k
IGlzIHdoeSBpdCBoYXMgbmV2ZXIgaGFwcGVuZWQgdG8gbWUsIEkndmUgZG9uZSBhIGZyZXNoIHRl
c3QKb2YgdGhpcyBwYXRjaCBtb3JlIHRoYW4gb25jZS4gUHJvYmFibHkgZGlzdC1taXNjIHRhcmdl
dCB3YXMgZXhlY3V0ZWQKYWZ0ZXIgc29tZSBvdGhlciB0YXJnZXQgYWxyZWFkeSBjcmVhdGVkIHRo
ZSBkaXN0IGZvbGRlci4KClRoYW5rcywgSSB3aWxsIHBvc3QgYW4gdXBkYXRlZCB2ZXJzaW9uIChh
Z2FpbikuCgo+Pgo+PiBJYW4uCj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKPj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4KPgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqM0-0006Xa-Hi; Tue, 21 Feb 2012 14:06: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 1RzqLz-0006XQ-Uh
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:06:04 +0000
Received: from [85.158.139.83:22888] by server-1.bemta-5.messagelabs.com id
	39/D0-28458-BC4A34F4; Tue, 21 Feb 2012 14:06:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329833161!8653392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13210 invoked from network); 21 Feb 2012 14:06:02 -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;
	21 Feb 2012 14:06:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:06:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:06:01 +0000
Message-ID: <1329833159.3990.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 14:05:59 +0000
In-Reply-To: <alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<1329755758.3990.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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, 2012-02-21 at 10:53 +0000, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Ian Campbell wrote:
> > On Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> > > This is necessary to handle nested traps to the hypervisor more than one deep.
> > 
> > A sort of corollary to this patch is the following.
> > 
> > The situation with the LR register when in hyp mode is a bit odd, since
> > this is normally a banked register but for hyp mode it actually accesses
> > LR_usr instead.
> > 
> > However, although I think the following is correct I'm not sure if it is
> > useful to combine LR_usr and LR like this -- in particular I fear it
> > might be more confusing than helpful. Making the return-to-user case a
> > proper superset of return-to-hypervisor (as is the case on the save
> > path) is nice though.
> > 
> > What do people think?
> 
> I am OK with this.

Is that an Acked-by?

> 
> > 8<---------------------------------------------------------------
> > 
> > >From 3132c2976ae4c83d6d9b94ad80ee04c4880f13da Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Mon, 20 Feb 2012 15:07:09 +0000
> > Subject: [PATCH] arm: lr register in hyp mode is really LR_usr.
> > 
> > Save and restore it in the same way for both hypervisor and user stack frames
> > rather than saving both individually in the user stack frame.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/entry.S          |   14 ++------------
> >  xen/include/public/arch-arm.h |   15 ++++++++++++---
> >  2 files changed, 14 insertions(+), 15 deletions(-)
> > 
> > diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> > index 36f1119..0e85c3c 100644
> > --- a/xen/arch/arm/entry.S
> > +++ b/xen/arch/arm/entry.S
> > @@ -29,8 +29,6 @@
> >  	blne save_guest_regs
> >  
> >  save_guest_regs:
> > -	ldr r11, [sp, #UREGS_lr]
> > -	str r11, [sp, #UREGS_LR_usr]
> >  	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
> >  	str r11, [sp, #UREGS_sp]
> 
> It would be nice to have a comment here saying "no need to save LR again
> because LR_usr and LR are the same physical register"

I'll add something next to both the save and restore of SP_usr saying
why LR_usr isn't also saved/restored there.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqM0-0006Xa-Hi; Tue, 21 Feb 2012 14:06: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 1RzqLz-0006XQ-Uh
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:06:04 +0000
Received: from [85.158.139.83:22888] by server-1.bemta-5.messagelabs.com id
	39/D0-28458-BC4A34F4; Tue, 21 Feb 2012 14:06:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329833161!8653392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13210 invoked from network); 21 Feb 2012 14:06:02 -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;
	21 Feb 2012 14:06:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:06:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:06:01 +0000
Message-ID: <1329833159.3990.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 14:05:59 +0000
In-Reply-To: <alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<1329755758.3990.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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, 2012-02-21 at 10:53 +0000, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Ian Campbell wrote:
> > On Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> > > This is necessary to handle nested traps to the hypervisor more than one deep.
> > 
> > A sort of corollary to this patch is the following.
> > 
> > The situation with the LR register when in hyp mode is a bit odd, since
> > this is normally a banked register but for hyp mode it actually accesses
> > LR_usr instead.
> > 
> > However, although I think the following is correct I'm not sure if it is
> > useful to combine LR_usr and LR like this -- in particular I fear it
> > might be more confusing than helpful. Making the return-to-user case a
> > proper superset of return-to-hypervisor (as is the case on the save
> > path) is nice though.
> > 
> > What do people think?
> 
> I am OK with this.

Is that an Acked-by?

> 
> > 8<---------------------------------------------------------------
> > 
> > >From 3132c2976ae4c83d6d9b94ad80ee04c4880f13da Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Mon, 20 Feb 2012 15:07:09 +0000
> > Subject: [PATCH] arm: lr register in hyp mode is really LR_usr.
> > 
> > Save and restore it in the same way for both hypervisor and user stack frames
> > rather than saving both individually in the user stack frame.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/entry.S          |   14 ++------------
> >  xen/include/public/arch-arm.h |   15 ++++++++++++---
> >  2 files changed, 14 insertions(+), 15 deletions(-)
> > 
> > diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> > index 36f1119..0e85c3c 100644
> > --- a/xen/arch/arm/entry.S
> > +++ b/xen/arch/arm/entry.S
> > @@ -29,8 +29,6 @@
> >  	blne save_guest_regs
> >  
> >  save_guest_regs:
> > -	ldr r11, [sp, #UREGS_lr]
> > -	str r11, [sp, #UREGS_LR_usr]
> >  	ldr r11, =0xffffffff  /* Clobber SP which is only valid for hypervisor frames. */
> >  	str r11, [sp, #UREGS_sp]
> 
> It would be nice to have a comment here saying "no need to save LR again
> because LR_usr and LR are the same physical register"

I'll add something next to both the save and restore of SP_usr saying
why LR_usr isn't also saved/restored there.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:06:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqM9-0006ZU-VK; Tue, 21 Feb 2012 14:06:13 +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 1RzqM8-0006Y5-Ti
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:06:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329833113!55141722!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28731 invoked from network); 21 Feb 2012 14:05:14 -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; 21 Feb 2012 14:05: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 q1LE61iq010949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:06:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1LE60bL011143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:06:01 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1LE60f6027491; Tue, 21 Feb 2012 08:06:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:06:00 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4E08540469; Tue, 21 Feb 2012 09:02:46 -0500 (EST)
Date: Tue, 21 Feb 2012 09:02:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221140246.GB11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020206.4F43A4CC.01A0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v3] blkif.h: Document protocol and
 existing 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 Mon, Feb 20, 2012 at 11:07:21AM -0700, Justin T. Gibbs wrote:
> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.
> 
> Changes in v3:
> 
> patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
>          ring extensions.):

It is called 'Red Hat', not RedHat.

>   o Mark the RedHat/Amazon EC2 ring extension nodes as deprecated.  While
>     there is nothing fundamentally wrong with the method used there, it
>     was not publicly documented (not even in patch form), and differs from
>     the "page-order" large ring XenBus node convention used for other
>     drivers.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>          extension.)
>    o Fix typo "max-ring_pages" -> "max-ring-pages".
> 
> Changes in v2:
> 
> patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
>   o Mark backend device identification section as private to the
>     backend driver.
>   o Refer to docs/misc/vbd-interface.txt for the format of the
>     virtual-device front-end node.
>   o Correct field size for the virtual-device front-end node.
> 
> patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
>          ring extensions.):
>   o Correct node names for the RedHat/Amazon multi-ring extension.  The
>     previous patch mistakenly documented the now defunct FreeBSD extension.
>   o Clarify the note on multi-page ring interoperability to indicate that
>     identical ring parameters should be published to the XenStore for
>     all supported schemes.
> 
> v1 patch 4 (Deleted):
>   o Remove patch that added the XEN_*_MAJOR definitions.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>          extension.)
>   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
>     to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> 
> --
> Justin
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:06:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqM9-0006ZU-VK; Tue, 21 Feb 2012 14:06:13 +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 1RzqM8-0006Y5-Ti
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:06:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329833113!55141722!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28731 invoked from network); 21 Feb 2012 14:05:14 -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; 21 Feb 2012 14:05: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 q1LE61iq010949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:06:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1LE60bL011143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:06:01 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1LE60f6027491; Tue, 21 Feb 2012 08:06:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:06:00 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4E08540469; Tue, 21 Feb 2012 09:02:46 -0500 (EST)
Date: Tue, 21 Feb 2012 09:02:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221140246.GB11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329761241@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020206.4F43A4CC.01A0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v3] blkif.h: Document protocol and
 existing 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 Mon, Feb 20, 2012 at 11:07:21AM -0700, Justin T. Gibbs wrote:
> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.
> 
> Changes in v3:
> 
> patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
>          ring extensions.):

It is called 'Red Hat', not RedHat.

>   o Mark the RedHat/Amazon EC2 ring extension nodes as deprecated.  While
>     there is nothing fundamentally wrong with the method used there, it
>     was not publicly documented (not even in patch form), and differs from
>     the "page-order" large ring XenBus node convention used for other
>     drivers.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>          extension.)
>    o Fix typo "max-ring_pages" -> "max-ring-pages".
> 
> Changes in v2:
> 
> patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
>   o Mark backend device identification section as private to the
>     backend driver.
>   o Refer to docs/misc/vbd-interface.txt for the format of the
>     virtual-device front-end node.
>   o Correct field size for the virtual-device front-end node.
> 
> patch 3 (blkif.h: Document the RedHat and Citrix blkif multi-page
>          ring extensions.):
>   o Correct node names for the RedHat/Amazon multi-ring extension.  The
>     previous patch mistakenly documented the now defunct FreeBSD extension.
>   o Clarify the note on multi-page ring interoperability to indicate that
>     identical ring parameters should be published to the XenStore for
>     all supported schemes.
> 
> v1 patch 4 (Deleted):
>   o Remove patch that added the XEN_*_MAJOR definitions.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>          extension.)
>   o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
>     to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> 
> --
> Justin
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:08:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqNp-0006lc-J3; Tue, 21 Feb 2012 14:07:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzqNn-0006kI-A3
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 14:07:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329833266!12454364!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24286 invoked from network); 21 Feb 2012 14:07:46 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:07:46 -0000
Received: by werh12 with SMTP id h12so5072608wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 06:07:46 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.109.225 as permitted sender) client-ip=10.180.109.225; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.109.225 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.109.225])
	by 10.180.109.225 with SMTP id hv1mr27070547wib.6.1329833266234
	(num_hops = 1); Tue, 21 Feb 2012 06:07:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=wh0jcBaEIZ/Y8GnmUHxrdOw5alx3kQylyQ2eJ9LLOR4=;
	b=HFJDjccFnMB2lIIBSBtKGewwNo4JohsTcc4stbeGAACthDy2DzbNWyaWjbLqlcJp+n
	EEQgoXpF4dDiPeHnXS306OXyF3WCy/DnPtOZvAOtyPHLR5Fm1k/O3xTgnxVYyj/x2S7v
	KptvQqLgpct7Wpg62SGKJv/gMvuz3jbfOJSi8=
Received: by 10.180.109.225 with SMTP id hv1mr22630538wib.6.1329833266146;
	Tue, 21 Feb 2012 06:07:46 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gf3sm21248143wib.6.2012.02.21.06.07.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 06:07:45 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============6369934646102767628=="
MIME-Version: 1.0
X-Mercurial-Node: c2f0820e48ae9cf0735c5ef81e6a6796f3d42e5a
Message-Id: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 04:19:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH v8] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6369934646102767628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v7:

 * Fixed bug that prevented the creation of "dist" directory (Ian
   Campbell).

Changes since v6:

 * Readded autogen.sh.

Changes since v5:

 * Remove dummy configure generation from autogen.sh since it's
   already on the source tree.

 * Removed autogen.sh since it was only a wrapper for calling
   autoconf.

 * Remove comment regarding yajl_version.h from configure.ac.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    3 +-
 README                            |    4 +
 autogen.sh                        |    3 +
 config/Tools.mk.in                |   50 +++++++
 configure                         |    2 +
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  192 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 55 files changed, 840 insertions(+), 511 deletions(-)



--===============6369934646102767628==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzk0MzA5IC0zNjAwCiMgTm9kZSBJRCBjMmYwODIwZTQ4
YWU5Y2YwNzM1YzVlZjgxZTZhNjc5NmYzZDQyZTVhCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY3OgoKICogRml4ZWQgYnVn
IHRoYXQgcHJldmVudGVkIHRoZSBjcmVhdGlvbiBvZiAiZGlzdCIgZGlyZWN0b3J5IChJYW4KICAg
Q2FtcGJlbGwpLgoKQ2hhbmdlcyBzaW5jZSB2NjoKCiAqIFJlYWRkZWQgYXV0b2dlbi5zaC4KCkNo
YW5nZXMgc2luY2UgdjU6CgogKiBSZW1vdmUgZHVtbXkgY29uZmlndXJlIGdlbmVyYXRpb24gZnJv
bSBhdXRvZ2VuLnNoIHNpbmNlIGl0J3MKICAgYWxyZWFkeSBvbiB0aGUgc291cmNlIHRyZWUuCgog
KiBSZW1vdmVkIGF1dG9nZW4uc2ggc2luY2UgaXQgd2FzIG9ubHkgYSB3cmFwcGVyIGZvciBjYWxs
aW5nCiAgIGF1dG9jb25mLgoKICogUmVtb3ZlIGNvbW1lbnQgcmVnYXJkaW5nIHlhamxfdmVyc2lv
bi5oIGZyb20gY29uZmlndXJlLmFjLgoKQ2hhbmdlcyBzaW5jZSB2NDoKCiAqIFVwZGF0ZWQgdG8g
dGlwLgoKICogSW5jbHVkZSBjb25maWcuaCBmcm9tIGNvbXBpbGVyIGNvbW1hbmQgbGluZSB3aGVu
IGJ1aWxkaW5nIGxpYnhsIGFuZAogICB4bCB0byBhc3N1cmUgeWFqbF92ZXJzaW9uLmggcHJlc2Vu
Y2UgYW5kIGNvcnJlY3RseSBkZXRlY3QgeWFqbAogICB2ZXJzaW9uLgoKICogQWRkZWQgZ2xpYi0y
LjAgY2hlY2sgd2l0aCBhcHByb3BpYXRlIG00IG1hY3Jvcy4KCiAqIFB1cmdlZCBjb25maWcuaC5p
biBmcm9tIHVubmVjZXNzYXJ5IGRlZmluZXMgdGhhdCBjb3VsZCBtZXNzIHdpdGgKICAgdGhlIGJ1
aWxkIHN5c3RlbS4KCiAqIFJlbW92ZWQgdG9vbHMvY29uZmlnLnN1YiwgdG9vbHMvY29uZmlnLmd1
ZXNzLCB0b29scy9jb25maWd1cmUgYW5kCiAgIGNvbmZpZ3VyZSB0byBtYWtlIHRoZSBwYXRjaCBm
aXQgbWFpbGluZyBsaXN0IGxpbWl0LgoKQ2hhbmdlcyBzaW5jZSB2MzoKCiAqIENvcGllZCBjb25m
aWcuZ3Vlc3MgYW5kIGNvbmZpZy5zdWIgZnJvbSBhdXRvbWFrZSAxLjExLgoKICogQWRkZWQgYSB0
ZXN0IHRvIGNoZWNrIGZvciB1dWlkLmggb24gQlNEIGFuZCB1dWlkL3V1aWQuaCBvbiBMaW51eC4K
CkNoYW5nZXMgc2luY2UgdjI6CgogKiBDaGFuZ2VkIG9yZGVyIG9mIGNvbmZpZy9Ub29scy5tayBp
bmNsdWRlLgoKICogQWRkZWQgIi1lIiB0byBhdXRvZ2VuLnNoIHNoZWJhbmcuCgogKiBBZGRlZCBu
ZWNlc3NhcnkgZmlsZXMgKGNvbmZpZy4qKSBhbmQgb3V0cHV0IGZyb20gQXV0b2hlYWRlciBhbmQK
ICAgQXV0b2NvbmYuCgogKiBSZW1vdmVkIEF1dG9jb25mIGZyb20gYnVpbGQgZGVwZW5kZW5jaWVz
IGFuZCB1cGRhdGVkIFJFQURNRS4KCkNoYW5nZXMgc2luY2UgdjE6CgogKiBNb3ZlZCBhdXRvY29u
ZiBzdHVmZiBpbnNpZGUgdG9vbHMgZm9sZGVyLgoKICogQWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBj
bGVhbmluZy4KCiAqIFJlbW92ZWQgQXV0b21ha2UgZGVwZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRv
Z2VuLnNoIHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGNvbmZpZ3VyZSBzY3JpcHQgd2hlbgogICBi
dWlsZGluZyBmcm9tIHNvdXJjZSByZXBvc2l0b3J5LgoKICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRp
b25zIHBhc3NlZCBmcm9tIGNvbW1hbmQgbGluZS4KCiAqIEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0
byAuaGdpZ25vcmUuCgogKiBBZGRlZCBBdXRvY29uZiB0byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNp
ZXMuCgogKiBDaGFuZ2VkIGh5cGVuIHRvIHVuZGVyc2NvcmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJp
YWJsZSBuYW1lcy4KCiAqIEFkZGVkIHNjcmlwdCB0byBnZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtl
ZmlsZS4KCiAqIFNldCBPY2FtbCB0b29scyB0byBvcHRpb25hbC4KCiAqIEFkZGVkIHByb2NlZGVu
Y2Ugb2YgbTQvb2NhbWwubTQuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2Vy
LnBhdUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFl
IC5oZ2lnbm9yZQotLS0gYS8uaGdpZ25vcmUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyBiLy5oZ2lnbm9yZQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTMwMyw2
ICszMDMsMTIgQEAKIF50b29scy9vY2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbCQKIF50b29scy9v
Y2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbGkkCiBedG9vbHMvb2NhbWwveGVuc3RvcmVkL294ZW5z
dG9yZWQkCitedG9vbHMvYXV0b200dGVcLmNhY2hlJAorXnRvb2xzL2NvbmZpZ1wuaCQKK150b29s
cy9jb25maWdcLmxvZyQKK150b29scy9jb25maWdcLnN0YXR1cyQKK150b29scy9jb25maWdcLmNh
Y2hlJAorXmNvbmZpZy9Ub29sc1wubWskCiBeeGVuL1wuYmFubmVyLiokCiBeeGVuL0JMT0ckCiBe
eGVuL1N5c3RlbS5tYXAkCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSBDb25m
aWcubWsKLS0tIGEvQ29uZmlnLm1rCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysg
Yi9Db25maWcubWsJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC03MCw5ICs3MCw2
IEBAIEVYVFJBX0lOQ0xVREVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiAr
PSAkKEVYVFJBX1BSRUZJWCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24K
LUZMRVgJPz0gZmxleAotCiBQWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJH
ID89IC0tcHJlZml4PSIkKFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJ
WCBjb250YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCkBAIC0xNzUsMzIg
KzE3Miw5IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVO
RF9MREZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRf
Q0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hF
Q0tfTElCID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNL
X0lOQ0xVREVTID0gJChFWFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVO
RF9JTkNMVURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFH
UyArPSAtZm5vLWV4Y2VwdGlvbnMKIAotQ09ORklHX0xJQklDT05WICAgOj0gJChzaGVsbCBleHBv
cnQgT1M9ImB1bmFtZSAtc2AiOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGV4cG9ydCBDSEVD
S19MSUI9IiQoQ0hFQ0tfTElCKSI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgLiAkKFhFTl9S
T09UKS90b29scy9jaGVjay9mdW5jcy5zaDsgXAotICAgICAgICAgICAgICAgICAgICAgICBoYXNf
bGliIGxpYmljb252LnNvICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi1DT05GSUdfWUFKTF9W
RVJTSU9OIDo9ICQoc2hlbGwgZXhwb3J0IE9TPSJgdW5hbWUgLXNgIjsgXAotICAgICAgICAgICAg
ICAgICAgICAgICBleHBvcnQgQ0hFQ0tfSU5DTFVERVM9IiQoQ0hFQ0tfSU5DTFVERVMpIjsgXAot
ICAgICAgICAgICAgICAgICAgICAgICAuICQoWEVOX1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNo
OyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGhhc19oZWFkZXIgeWFqbC95YWpsX3ZlcnNpb24u
aCAmJiBlY2hvICd5JyB8fCBlY2hvICduJykKLQotIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVs
ZSAoYnkgZGVmYXVsdCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1GTEFTS19FTkFCTEUgPz0g
JChYU01fRU5BQkxFKQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3Ig
R0lUJ3Mgb3duIHByb3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUg
cm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0jIG1heSBibG9jayBpdCku
IFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25s
b2FkcwotIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBl
bnZpcm9ubWVudC4KLUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVTX1VSTD1odHRwOi8veGVu
Yml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhlIGZpbGVzIGF0IHRoYXQg
bG9jYXRpb24gd2VyZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9uCiAjIHRoZSBpbnRlcm5l
dC4gIFRoZSBvcmlnaW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVkIGFzIGEgY29tbWVudApA
QCAtMjM5LDE3ICsyMTMsNCBAQCBRRU1VX1RBRyA/PSAxMjhkZTI1NDljNWYyNGU0YTQzN2I4NmJk
MmU0CiAjIFNob3J0IGFuc3dlciAtLSBkbyBub3QgZW5hYmxlIHRoaXMgdW5sZXNzIHlvdSBrbm93
IHdoYXQgeW91IGFyZQogIyBkb2luZyBhbmQgYXJlIHByZXBhcmVkIGZvciBzb21lIHBhaW4uCiAK
LSMgT3B0aW9uYWwgY29tcG9uZW50cwotWEVOU1RBVF9YRU5UT1AgICAgID89IHkKLVZUUE1fVE9P
TFMgICAgICAgICA/PSBuCi1MSUJYRU5BUElfQklORElOR1MgPz0gbgotUFlUSE9OX1RPT0xTICAg
ICAgID89IHkKLU9DQU1MX1RPT0xTICAgICAgICA/PSB5Ci1DT05GSUdfTUlOSVRFUk0gICAgPz0g
bgotQ09ORklHX0xPTU9VTlQgICAgID89IG4KLUNPTkZJR19TWVNURU1fTElCQUlPID89IHkKIENP
TkZJR19URVNUUyAgICAgICA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9PTFMpLHkpCi1PQ0FNTF9U
T09MUyA6PSAkKHNoZWxsIG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyAieSIg
fHwgZWNobyAibiIpCi1lbmRpZgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUg
TWFrZWZpbGUKLS0tIGEvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyBiL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtNDAsMTEgKzQw
LDEwIEBAIGRpc3Q6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0OiBkaXN0LXhlbiBk
aXN0LWtlcm5lbHMgZGlzdC10b29scyBkaXN0LXN0dWJkb20gZGlzdC1kb2NzIGRpc3QtbWlzYwog
CiBkaXN0LW1pc2M6Ci0JJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjaworCSQoSU5TVEFM
TF9ESVIpICQoRElTVERJUikvCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09QWUlORyAkKERJU1RESVIp
CiAJJChJTlNUQUxMX0RBVEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkkKElOU1RBTExfUFJPRykg
Li9pbnN0YWxsLnNoICQoRElTVERJUikKLQkkKElOU1RBTExfUFJPRykgdG9vbHMvY2hlY2svY2hr
IHRvb2xzL2NoZWNrL2NoZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2ggJChESVNURElSKS9jaGVj
awogZGlzdC0lOiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdC0lOiBpbnN0YWxsLSUK
IAlAOiAjIGRvIG5vdGhpbmcKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIFJF
QURNRQotLS0gYS9SRUFETUUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL1JF
QURNRQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTg5LDkgKzg5LDEzIEBAIDIu
IGNkIHRvIHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKIDMuIEZvciB0aGUgdmVyeSBm
aXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWlsZCB0cmVlcywKICAgIHBl
cmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwczoKIAorICAgICMgLi9jb25maWd1cmUKICAgICAjIG1h
a2Ugd29ybGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ugd2FudCwgeW91IGNhbiBy
dW4gLi9jb25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgorICAgb3B0aW9ucyBhdmFp
bGFibGUgb3B0aW9ucyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5nIFhlbi4KKwogICAgVGhp
cyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBtYWNoaW5lLiBJdCB3aWxs
IGJ1aWxkCiAgICB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRvb2xzIGFuZCB0aGUgZG9j
dW1lbnRhdGlvbi4KIApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgYXV0b2dl
bi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9h
dXRvZ2VuLnNoCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDMgQEAK
KyMhL2Jpbi9zaCAtZQorY2QgdG9vbHMKK2F1dG9jb25mCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGMyZjA4MjBlNDhhZSBjb25maWcvVG9vbHMubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvY29uZmlnL1Rvb2xzLm1rLmluCVR1ZSBGZWIgMjEg
MDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDUwIEBACisjIFByZWZpeCBhbmQgaW5zdGFs
bCBmb2xkZXIKK1BSRUZJWCAgICAgICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJfeDg2
XzY0ICAgOj0gQExJQl9QQVRIQAorCisjIEEgZGVidWcgYnVpbGQgb2YgdG9vbHM/CitkZWJ1ZyAg
ICAgICAgICAgICAgIDo9IEBkZWJ1Z0AKKworIyBUb29scyBwYXRoCitCSVNPTiAgICAgICAgICAg
ICAgIDo9IEBCSVNPTkAKK0ZMRVggICAgICAgICAgICAgICAgOj0gQEZMRVhACitQWVRIT04gICAg
ICAgICAgICAgIDo9IEBQWVRIT05ACitQWVRIT05fUEFUSCAgICAgICAgIDo9IEBQWVRIT05QQVRI
QAorUEVSTCAgICAgICAgICAgICAgICA6PSBAUEVSTEAKK0JSQ1RMICAgICAgICAgICAgICAgOj0g
QEJSQ1RMQAorSVAgICAgICAgICAgICAgICAgICA6PSBASVBACitDVVJMX0NPTkZJRyAgICAgICAg
IDo9IEBDVVJMQAorWE1MMl9DT05GSUcgICAgICAgICA6PSBAWE1MQAorQkFTSCAgICAgICAgICAg
ICAgICA6PSBAQkFTSEAKK1hHRVRUVEVYVCAgICAgICAgICAgOj0gQFhHRVRURVhUQAorCisjIEV4
dHJhIGZvbGRlciBmb3IgbGlicy9pbmNsdWRlcworUFJFUEVORF9JTkNMVURFUyAgICA6PSBAUFJF
UEVORF9JTkNMVURFU0AKK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElCQAorQVBQ
RU5EX0lOQ0xVREVTICAgICA6PSBAQVBQRU5EX0lOQ0xVREVTQAorQVBQRU5EX0xJQiAgICAgICAg
ICA6PSBAQVBQRU5EX0xJQkAKKworIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVm
YXVsdCwgRmxhc2spLgorWFNNX0VOQUJMRSAgICAgICAgICA6PSBAeHNtQAorRkxBU0tfRU5BQkxF
ICAgICAgICA6PSBAeHNtQAorCisjIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAg
b3IgR0lUJ3Mgb3duIHByb3RvY29sPworIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1v
cmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCisjIG1heSBibG9jayBp
dCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRv
d25sb2FkcworIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91
ciBlbnZpcm9ubWVudC4KK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBACisKKyMgT3B0
aW9uYWwgY29tcG9uZW50cworWEVOU1RBVF9YRU5UT1AgICAgICA6PSBAbW9uaXRvcnNACitWVFBN
X1RPT0xTICAgICAgICAgIDo9IEB2dHBtQAorTElCWEVOQVBJX0JJTkRJTkdTICA6PSBAeGFwaUAK
K1BZVEhPTl9UT09MUyAgICAgICAgOj0gQHB5dGhvbnRvb2xzQAorT0NBTUxfVE9PTFMgICAgICAg
ICA6PSBAb2NhbWx0b29sc0AKK0NPTkZJR19NSU5JVEVSTSAgICAgOj0gQG1pbml0ZXJtQAorQ09O
RklHX0xPTU9VTlQgICAgICA6PSBAbG9tb3VudEAKKworI1N5c3RlbSBvcHRpb25zCitDT05GSUdf
U1lTVEVNX0xJQkFJTzo9IEBzeXN0ZW1fYWlvQAorQ09ORklHX0xJQklDT05WICAgICA6PSBAbGli
aWNvbnZACitDT05GSUdfR0NSWVBUICAgICAgIDo9IEBsaWJnY3J5cHRACitDT05GSUdfRVhUMkZT
ICAgICAgIDo9IEBsaWJleHQyZnNACmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhh
ZSBjb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
KysrIGIvY29uZmlndXJlCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsx
LDIgQEAKKyMhL2Jpbi9zaCAtZQorY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgJEAKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL01h
a2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9NYWtlZmls
ZQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTYsNyArNiw2IEBAIFNVQkRJUlMt
bGliYWlvIDo9IGxpYmFpbwogZW5kaWYKIAogU1VCRElSUy15IDo9Ci1TVUJESVJTLXkgKz0gY2hl
Y2sKIFNVQkRJUlMteSArPSBpbmNsdWRlCiBTVUJESVJTLXkgKz0gbGlieGMKIFNVQkRJUlMteSAr
PSBmbGFzawpAQCAtNzksNiArNzgsOCBAQCBjbGVhbjogc3ViZGlycy1jbGVhbgogZGlzdGNsZWFu
OiBzdWJkaXJzLWRpc3RjbGVhbgogCXJtIC1yZiBxZW11LXhlbi10cmFkaXRpb25hbC1kaXIgcWVt
dS14ZW4tdHJhZGl0aW9uYWwtZGlyLXJlbW90ZQogCXJtIC1yZiBxZW11LXhlbi1kaXIgcWVtdS14
ZW4tZGlyLXJlbW90ZQorCXJtIC1yZiAuLi9jb25maWcvVG9vbHMubWsgY29uZmlnLmggY29uZmln
LmxvZyBjb25maWcuc3RhdHVzIFwKKwkJY29uZmlnLmNhY2hlIGF1dG9tNHRlLmNhY2hlCiAKIGlm
bmVxICgkKFhFTl9DT01QSUxFX0FSQ0gpLCQoWEVOX1RBUkdFVF9BUkNIKSkKIElPRU1VX0NPTkZJ
R1VSRV9DUk9TUyA/PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXApkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvUnVsZXMubWsKLS0tIGEvdG9vbHMvUnVsZXMubWsJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL1J1bGVzLm1rCVR1ZSBG
ZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtNCw2ICs0LDcgQEAKIGFsbDoKIAogaW5jbHVk
ZSAkKFhFTl9ST09UKS9Db25maWcubWsKK2luY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xz
Lm1rCiAKIGV4cG9ydCBfSU5TVEFMTCA6PSAkKElOU1RBTEwpCiBJTlNUQUxMID0gJChYRU5fUk9P
VCkvdG9vbHMvY3Jvc3MtaW5zdGFsbApAQCAtODAsOCArODEsNiBAQCBjaGVjay0kKENPTkZJR19Y
ODYpID0gJChjYWxsIGNjLXZlci1jaGVjCiAgICAgICAgICAgICAgICAgICAgICAgICAiWGVuIHJl
cXVpcmVzIGF0IGxlYXN0IGdjYy0zLjQiKQogJChldmFsICQoY2hlY2steSkpCiAKLV9QWVRIT05f
UEFUSCA6PSAkKHNoZWxsIHdoaWNoICQoUFlUSE9OKSkKLVBZVEhPTl9QQVRIID89ICQoX1BZVEhP
Tl9QQVRIKQogSU5TVEFMTF9QWVRIT05fUFJPRyA9IFwKIAkkKFhFTl9ST09UKS90b29scy9weXRo
b24vaW5zdGFsbC13cmFwICIkKFBZVEhPTl9QQVRIKSIgJChJTlNUQUxMX1BST0cpCiAKQEAgLTEw
OSwzICsxMDgsNyBAQCBzdWJkaXItYWxsLSUgc3ViZGlyLWNsZWFuLSUgc3ViZGlyLWluc3RhCiAK
IHN1YmRpci1kaXN0Y2xlYW4tJTogLnBob255CiAJJChNQUtFKSAtQyAkKiBjbGVhbgorCiskKFhF
Tl9ST09UKS9jb25maWcvVG9vbHMubWs6CisJQGVjaG8gIllvdSBoYXZlIHRvIHJ1biAuL2NvbmZp
Z3VyZSBiZWZvcmUgYnVpbGRpbmcgb3IgaW5zdGFsbGluZyB0aGUgdG9vbHMiCisJQGV4aXQgMQpk
aWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvYmxrdGFwL2RyaXZlcnMv
TWFrZWZpbGUKLS0tIGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVR1
ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMTMsNyArMTMsNyBAQCBDRkxBR1MgICAr
PSAkKENGTEFHU19saWJ4ZW5zdG9yZSkKIENGTEFHUyAgICs9IC1JICQoTUVNU0hSX0RJUikKIENG
TEFHUyAgICs9IC1EX0dOVV9TT1VSQ0UKIAotaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0
ICQoQ0MpKSx5ZXMpCitpZmVxICgkQ09ORklHX0dDUllQVCx5KQogQ0ZMQUdTICs9IC1EVVNFX0dD
UllQVAogQ1JZUFRfTElCIDo9IC1sZ2NyeXB0CiBlbHNlCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGMyZjA4MjBlNDhhZSB0b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQKLS0tIGEvdG9v
bHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiAr
MDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwx
NCArMCwwIEBACi0jIS9iaW4vc2gKLQotY2F0ID4gLmdjcnlwdC5jIDw8IEVPRgotI2luY2x1ZGUg
PGdjcnlwdC5oPgotaW50IG1haW4odm9pZCkgeyByZXR1cm4gMDsgfQotRU9GCi0KLWlmICQxIC1v
IC5nY3J5cHQgLmdjcnlwdC5jIC1sZ2NyeXB0IDI+L2Rldi9udWxsIDsgdGhlbgotICBlY2hvICJ5
ZXMiCi1lbHNlCi0gIGVjaG8gIm5vIgotZmkKLQotcm0gLWYgLmdjcnlwdCoKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL01ha2VmaWxlCi0tLSBhL3Rvb2xz
L2NoZWNrL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyNiArMCwwIEBACi1YRU5f
Uk9PVCA9ICQoQ1VSRElSKS8uLi8uLgotaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5t
awotCi0jIEV4cG9ydCB0aGUgbmVjZXNzYXJ5IGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgdGhl
IHRlc3RzCi1leHBvcnQgUFlUSE9OCi1leHBvcnQgTElCWEVOQVBJX0JJTkRJTkdTCi1leHBvcnQg
Q0hFQ0tfSU5DTFVERVMKLWV4cG9ydCBDSEVDS19MSUIKLWV4cG9ydCBDT05GSUdfU1lTVEVNX0xJ
QkFJTwotCi0uUEhPTlk6IGFsbCBpbnN0YWxsCi1hbGwgaW5zdGFsbDogY2hlY2stYnVpbGQKLQot
IyBDaGVjayB0aGlzIG1hY2hpbmUgaXMgT0sgZm9yIGJ1aWxkaW5nIG9uLgotLlBIT05ZOiBjaGVj
ay1idWlsZAotY2hlY2stYnVpbGQ6Ci0JLi9jaGsgYnVpbGQKLQotIyBDaGVjayB0aGlzIG1hY2hp
bmUgaXMgT0sgZm9yIGluc3RhbGxpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWluc3RhbGwKLWNoZWNr
LWluc3RhbGw6Ci0JLi9jaGsgaW5zdGFsbAotCi0uUEhPTlk6IGNsZWFuCi1jbGVhbjoKLQkuL2No
ayBjbGVhbgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvY2hlY2sv
UkVBRE1FCi0tLSBhL3Rvb2xzL2NoZWNrL1JFQURNRQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MjAgKzAsMCBAQAotQ2hlY2tzIGZvciB0aGUgc3VpdGFiaWxpdHkgb2YgYSBtYWNoaW5lIGZvciBY
ZW4gYnVpbGQgb3IgaW5zdGFsbC4KLVRvIGNoZWNrIGZvciBidWlsZCBzdWl0YWJpbGl0eSB1c2UK
LQotICAgICAgICAuL2NoayBidWlsZAotCi1UbyBjaGVjayBmb3IgaW5zdGFsbCBzdWl0YWJpbGl0
eSB1c2UKLQotICAgICAgICAuL2NoayBpbnN0YWxsCi0KLVRoZSBjaGsgc2NyaXB0IHdpbGwgcnVu
IGNoZWNrcyBpbiB0aGlzIGRpcmVjdG9yeSBhbmQgcHJpbnQKLXRoZSBvbmVzIHRoYXQgZmFpbGVk
LiBJdCBwcmludHMgbm90aGluZyBpZiBjaGVja3Mgc3VjY2VlZC4KLVRoZSBjaGsgc2NyaXB0IGV4
aXRzIHdpdGggMCBvbiBzdWNjZXNzIGFuZCAxIG9uIGZhaWx1cmUuCi0KLVRoZSBjaGsgc2NyaXB0
IHJ1bnMgZXhlY3V0YWJsZSBmaWxlcyBpbiB0aGlzIGRpcmVjdG9yeSB3aG9zZQotbmFtZXMgYmVn
aW4gd2l0aCAnY2hlY2tfJy4gRmlsZXMgY29udGFpbmluZyBDSEVDSy1CVUlMRAotYXJlIHJ1biBm
b3IgdGhlIGJ1aWxkIGNoZWNrLCBhbmQgZmlsZXMgY29udGFpbmluZyBDSEVDSy1JTlNUQUxMCi1h
cmUgcnVuIGZvciB0aGUgaW5zdGFsbCBjaGVjay4KLQotRGV0YWlsZWQgb3V0cHV0IGZyb20gdGhl
IGNoZWNrIHNjcmlwdHMgaXMgaW4gLmNoa2J1aWxkIGZvciBidWlsZAotYW5kIC5jaGtpbnN0YWxs
IGZvciBpbnN0YWxsLgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL2NoZWNrX2JyY3RsCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX2JyY3RsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4K
LU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgYnJjb25maWcgOzsKLUxpbnV4
KQotCWhhc19vcl9mYWlsIGJyY3RsIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2Fj
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19j
cnlwdG9fbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1J
TlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRCU0R8T3Bl
bkJTRCkKLQlleGl0IDAgOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJjcnlwdG8uc28gfHwgZmFpbCAi
bWlzc2luZyBsaWJjcnlwdG8uc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhh
ZSB0b29scy9jaGVjay9jaGVja19jdXJsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2N1cmwJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlM
RCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICIkTElCWEVOQVBJX0JJTkRJ
TkdTIiAhPSAieSIgXTsgdGhlbgotCWVjaG8gLW4gInVudXNlZCwgIgotCWV4aXQgMAotZmkKLQot
aGFzX29yX2ZhaWwgY3VybC1jb25maWcKLWN1cmxfbGlicz1gY3VybC1jb25maWcgLS1saWJzYCB8
fCBmYWlsICJjdXJsLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICRjdXJsX2xpYnMg
fHwgZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIGN1cmwgYXJlIG1pc3NpbmciCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19pcHJvdXRl
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDE1ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAot
Ci1QQVRIPS9zYmluOiRQQVRICi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNE
KQotCWhhc19vcl9mYWlsIGlmY29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBpcCA7Owot
KikKLQlmYWlsICJ1bmtub3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBj
MmYwODIwZTQ4YWUgdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX2xpYmFpb19kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBA
QAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NP
TkZJR19TWVNURU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaWYg
ISBoYXNfaGVhZGVyIGxpYmFpby5oIDsgdGhlbgotICAgIGZhaWwgImNhbid0IGZpbmQgbGliYWlv
IGhlYWRlcnMsIGluc3RhbGwgbGliYWlvIGRldmVsIHBhY2thZ2Ugb3Igc2V0IENPTkZJR19TWVNU
RU1fTElCQUlPPW4iCi1maQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9v
bHMvY2hlY2svY2hlY2tfbGliYWlvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9f
bGliCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19T
WVNURU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaGFzX2xpYiBs
aWJhaW8uc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8iCmRpZmYgLXIgY2E4MGVjYTljZmEz
IC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCi0tLSBhL3Rv
b2xzL2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYg
KzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNf
aGVhZGVyIG9wZW5zc2wvbWQ1LmggfHwgZmFpbCAibWlzc2luZyBvcGVuc3NsIGhlYWRlcnMiCmRp
ZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19weXRo
b24KLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAx
MiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0u
IC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhv
bgotZmkKLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBzeXMKLXN5cy5leGl0KHN5cy52ZXJzaW9u
X2luZm9bMF0gPCAyIG9yIHN5cy52ZXJzaW9uX2luZm9bMV0gPCAzKQotJyB8fCBmYWlsICJuZWVk
IHB5dGhvbiB2ZXJzaW9uID49IDIuMyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0
OGFlIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVj
a19weXRob25fZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE3ICswLDAgQEAKLSMhL2Jp
bi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhP
Tn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0k
e1BZVEhPTn0gLWMgJwotaW1wb3J0IG9zLnBhdGgsIHN5cwotZm9yIHAgaW4gc3lzLnBhdGg6Ci0J
aWYgb3MucGF0aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6Ci0JCXN5cy5leGl0KDAp
Ci1zeXMuZXhpdCgxKQotJyB8fCBmYWlsICJjYW4ndCBmaW5kIHB5dGhvbiBkZXZlbCBmaWxlcyIK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL2NoZWNrX3B5
dGhvbl94bWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAlNb24gRmViIDIwIDE4
OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsMTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAu
L2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24K
LWZpCi1oYXNfb3JfZmFpbCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICdpbXBvcnQgeG1sLmRv
bS5taW5pZG9tJyAyPi9kZXYvbnVsbCB8fCBcCi1mYWlsICJjYW4ndCBpbXBvcnQgeG1sLmRvbS5t
aW5pZG9tIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvY2hlY2sv
Y2hlY2tfdWRldgotLS0gYS90b29scy9jaGVjay9jaGVja191ZGV2CU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwyMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVu
Y3Muc2gKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2Zh
aWwgdm5jb25maWcKLQk7OwotTGludXgpCi0JaGFzIC9zYmluL3VkZXZhZG0gJiYgXAotCQl1ZGV2
dmVyPWAvc2Jpbi91ZGV2YWRtIGluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbIC16ICIk
dWRldnZlciIgXSAmJiBoYXNfb3JfZmFpbCB1ZGV2aW5mbyAmJiBcCi0JCXVkZXZ2ZXI9YHVkZXZp
bmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0JWyAiJHVkZXZ2ZXIiIC1nZSA1OSBdIDI+L2Rl
di9udWxsIHx8IFwKLQkJaGFzIGhvdHBsdWcgfHwgXAotCQlmYWlsICJ1ZGV2IGlzIHRvbyBvbGQs
IHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlciIKLQk7OwotKikKLQlmYWlsICJ1bmtub3du
IE9TIgotCTs7Ci1lc2FjCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29s
cy9jaGVjay9jaGVja191dWlkX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2
ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHV1aWQuaCB8fCBcCi1oYXNfaGVh
ZGVyIHV1aWQvdXVpZC5oIHx8IGZhaWwgIm1pc3NpbmcgdXVpZCBoZWFkZXJzIChwYWNrYWdlIHV1
aWQtZGV2KSIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNr
L2NoZWNrX3gxMV9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIFgxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVh
ZGVyIC91c3IvWDExUjYvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAotaGFzX2hlYWRlciAv
dXNyL1gxMVI3L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLXdhcm5pbmcgImNhbid0IGZp
bmQgWDExIGhlYWRlcnMiCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29s
cy9jaGVjay9jaGVja194Z2V0dGV4dAotLS0gYS90b29scy9jaGVjay9jaGVja194Z2V0dGV4dAlN
b24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJ
TEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19vcl9mYWlsIHhnZXR0ZXh0CmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja194bWwyCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX3htbDIJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1p
ZiBbICEgIiRMSUJYRU5BUElfQklORElOR1MiID0gInkiIF0KLXRoZW4KLSAgICBlY2hvIC1uICJ1
bnVzZWQsICIKLSAgICBleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIHhtbDItY29uZmlnCi14bWwy
X2xpYnM9YHhtbDItY29uZmlnIC0tbGlic2AgfHwgZmFpbCAieG1sMi1jb25maWcgLS1saWJzIGZh
aWxlZCIKLXRlc3RfbGluayAkeG1sMl9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVz
IGZvciB4bWwyIGFyZSBtaXNzaW5nIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4
YWUgdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja195
YWpsX2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw4ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB5YWpsL3lhamxfcGFy
c2UuaCB8fCBmYWlsICJjYW4ndCBmaW5kIHlhamwveWFqbF9wYXJzZS5oIgotaGFzX2hlYWRlciB5
YWpsL3lhamxfZ2VuLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfZ2VuLmgiCi1oYXNf
bGliIGxpYnlhamwuc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJ5YWpsLnNvIgpkaWZmIC1yIGNh
ODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvY2hlY2svY2hlY2tfemxpYl9kZXZlbAot
LS0gYS90b29scy9jaGVjay9jaGVja196bGliX2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAx
MiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQot
aGFzX2hlYWRlciB6bGliLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB6bGliIGhlYWRlcnMiCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja196bGliX2xp
YgotLS0gYS90b29scy9jaGVjay9jaGVja196bGliX2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsMTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4
aXQgMAotCTs7Ci1lc2FjCi0KLWhhc19saWIgbGliei5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIHps
aWIiCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGsK
LS0tIGEvdG9vbHMvY2hlY2svY2hrCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw2MyArMCwwIEBA
Ci0jIS9iaW4vc2gKLQotZnVuY191c2FnZSAoKQotewotICAgIGVjaG8gIlVzYWdlOiIKLSAgICBl
Y2hvICIJJDAgW2J1aWxkfGluc3RhbGx8Y2xlYW5dIgotICAgIGVjaG8KLSAgICBlY2hvICJDaGVj
ayBzdWl0YWJpbGl0eSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuIgotICAgIGVjaG8gIkV4aXQg
d2l0aCAwIGlmIE9LLCAxIGlmIG5vdC4iCi0gICAgZWNobwotICAgIGVjaG8gIkNhbGxpbmcgd2l0
aCAnY2xlYW4nIHJlbW92ZXMgZ2VuZXJhdGVkIGZpbGVzLiIKLSAgICBleGl0IDEKLX0KLQotUEFU
SD0kUEFUSDovc2JpbjovdXNyL3NiaW4KLU9TPWB1bmFtZSAtc2AKLWV4cG9ydCBQQVRIIE9TCi0K
LWlmIFsgIiRPUyIgPSAiU3VuT1MiIF07IHRoZW4KLQlleGl0IDAKLWZpCi0KLWNhc2UgJDEgaW4K
LSAgICBidWlsZCkKLSAgICAgICAgY2hlY2s9IkNIRUNLLUJVSUxEIgotICAgICAgICA7OwotICAg
IGluc3RhbGwpCi0gICAgICAgIGNoZWNrPSJDSEVDSy1JTlNUQUxMIgotICAgICAgICA7OwotICAg
IGNsZWFuKQotICAgICAgICBleGl0IDAKLSAgICAgICAgOzsKLSAgICAqKQotICAgICAgICBmdW5j
X3VzYWdlCi0gICAgICAgIDs7Ci1lc2FjCi0KLWZhaWxlZD0wCi0KLWVjaG8gIlhlbiAke2NoZWNr
fSAiIGBkYXRlYAotZm9yIGYgaW4gY2hlY2tfKiA7IGRvCi0gICAgY2FzZSAkZiBpbgotICAgICAg
ICAqfikKLSAgICAgICAgICAgIGNvbnRpbnVlCi0gICAgICAgICAgICA7OwotICAgICAgICAqKQot
ICAgICAgICAgICAgOzsKLSAgICBlc2FjCi0gICAgaWYgISBbIC14ICRmIF0gOyB0aGVuCi0gICAg
ICAgIGNvbnRpbnVlCi0gICAgZmkKLSAgICBpZiAhIGdyZXAgLUZxICIkY2hlY2siICRmIDsgdGhl
bgotICAgICAgICBjb250aW51ZQotICAgIGZpCi0gICAgZWNobyAtbiAiQ2hlY2tpbmcgJGY6ICIK
LSAgICBpZiAuLyRmIDI+JjEgOyB0aGVuCi0gICAgICAgIGVjaG8gT0sKLSAgICBlbHNlCi0gICAg
ICAgIGZhaWxlZD0xCi0gICAgZmkKLWRvbmUKLQotZXhpdCAke2ZhaWxlZH0KZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL2Z1bmNzLnNoCi0tLSBhL3Rvb2xz
L2NoZWNrL2Z1bmNzLnNoCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMDYgKzAsMCBAQAotIyBo
YXMgaXMgdGhlIHNhbWUgYXMgd2hpY2gsIGV4Y2VwdCBpdCBoYW5kbGVzIGNyb3NzIGVudmlyb25t
ZW50cwotaGFzKCkgewotCWlmIFsgLXogIiRDUk9TU19DT01QSUxFIiBdOyB0aGVuCi0JCWNvbW1h
bmQgd2hpY2ggIiRAIgotCQlyZXR1cm4gJD8KLQlmaQotCi0JY2hlY2tfc3lzX3Jvb3QgfHwgcmV0
dXJuIDEKLQotCSMgc3Vic2hlbGwgdG8gcHJldmVudCBwb2xsdXRpb24gb2YgY2FsbGVyJ3MgSUZT
Ci0JKAotCUlGUz06Ci0JZm9yIHAgaW4gJFBBVEg7IGRvCi0JCWlmIFsgLXggIiRDUk9TU19TWVNf
Uk9PVC8kcC8kMSIgXTsgdGhlbgotCQkJZWNobyAiJENST1NTX1NZU19ST09ULyRwLyQxIgotCQkJ
cmV0dXJuIDAKLQkJZmkKLQlkb25lCi0JcmV0dXJuIDEKLQkpCi19Ci0KLWhhc19vcl9mYWlsKCkg
ewotCWhhcyAiJDEiID4vZGV2L251bGwgfHwgZmFpbCAiY2FuJ3QgZmluZCAkMSIKLX0KLQotaGFz
X2hlYWRlcigpIHsKLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JY2FzZSAkMSBpbgot
CQkvKikgOzsKLQkJKikKLQkJaWYgWyAtciAiJENST1NTX1NZU19ST09UL3Vzci9pbmNsdWRlLyQx
IiBdOyB0aGVuCi0JCQlyZXR1cm4gMAotCQlmaQotCQlmb3IgcGF0aCBpbiAke0NIRUNLX0lOQ0xV
REVTfTsgZG8KLQkJCWlmIFsgLXIgIiRDUk9TU19TWVNfUk9PVCR7cGF0aH0vJDEiIF07IHRoZW4K
LQkJCQlyZXR1cm4gMAotCQkJZmkKLQkJZG9uZQotCQk7OwotCWVzYWMKLQotCXJldHVybiAxCi19
Ci0KLWhhc19saWIoKSB7Ci0JY2hlY2tfc3lzX3Jvb3QgfHwgcmV0dXJuIDEKLQotCSMgc3Vic2hl
bGwgdG8gcHJldmVudCBwb2xsdXRpb24gb2YgY2FsbGVyJ3MgZW52aXJvbm1lbnQKLQkoCi0JUEFU
SD0vc2JpbjokUEFUSCAgICAgICAgIyBmb3IgbGRjb25maWcKLQlMSUJSQVJJRVM9IiRDSEVDS19M
SUIgL3Vzci9saWIiCi0KLQkjIFRoaXMgcmVsYXRpdmVseSBjb21tb24gaW4gYSBzeXMtcm9vdDsg
bGlicyBhcmUgaW5zdGFsbGVkIGJ1dAotCSMgbGRjb25maWcgaGFzbid0IHJ1biB0aGVyZSwgc28g
bGRjb25maWcgLXAgd29uJ3Qgd29yay4KLQlpZiBbICIkT1MiID0gTGludXggLWEgISAtZiAiJENS
T1NTX1NZU19ST09UL2V0Yy9sZC5zby5jYWNoZSIgXTsgdGhlbgotCSAgICBlY2hvICJQbGVhc2Ug
cnVuIGxkY29uZmlnIC1yIFwiJENST1NTX1NZU19ST09UXCIgdG8gZ2VuZXJhdGUgbGQuc28uY2Fj
aGUiCi0JICAgICMgZmFsbCB0aHJvdWdoOyBsZGNvbmZpZyB0ZXN0IGJlbG93IHNob3VsZCBmYWls
Ci0JZmkKLQlpZiBbICIke09TfSIgPSAiTGludXgiIF07IHRoZW4KLQkJbGRjb25maWcgLXAgJHtD
Uk9TU19TWVNfUk9PVCstciAiJENST1NTX1NZU19ST09UIn0gfCBncmVwIC1GcSAiJDEiCi0JCXJl
dHVybiAkPwotCWZpCi0JaWYgWyAiJHtPU30iID0gIk5ldEJTRCIgXTsgdGhlbgotCQlscyAtMSAk
e0xJQlJBUklFU30gfCBncmVwIC1GcSAiJDEiCi0JCXJldHVybiAkPwotCWZpCi0JcmV0dXJuIDEK
LQkpCi19Ci0KLXRlc3RfbGluaygpIHsKLQkjIHN1YnNoZWxsIHRvIHRyYXAgcmVtb3ZhbCBvZiB0
bXBmaWxlCi0JKAotCXVuc2V0IHRtcGZpbGUKLQl0cmFwICdybSAtZiAiJHRtcGZpbGUiOyBleGl0
JyAwIDEgMiAxNQotCXRtcGZpbGU9YG1rdGVtcGAgfHwgcmV0dXJuIDEKLQlsZCAiJEAiIC1vICIk
dG1wZmlsZSIgPi9kZXYvbnVsbCAyPiYxCi0JcmV0dXJuICQ/Ci0JKQotfQotCi0jIHRoaXMgZnVu
Y3Rpb24gaXMgdXNlZCBjb21tb25seSBhYm92ZQotY2hlY2tfc3lzX3Jvb3QoKSB7Ci0JWyAteiAi
JENST1NTX0NPTVBJTEUiIF0gJiYgcmV0dXJuIDAKLQlpZiBbIC16ICIkQ1JPU1NfU1lTX1JPT1Qi
IF07IHRoZW4KLQkJZWNobyAicGxlYXNlIHNldCBDUk9TU19TWVNfUk9PVCBpbiB0aGUgZW52aXJv
bm1lbnQiCi0JCXJldHVybiAxCi0JZmkKLQlpZiBbICEgLWQgIiRDUk9TU19TWVNfUk9PVCIgXTsg
dGhlbgotCQllY2hvICJubyBzeXMtcm9vdCBmb3VuZCBhdCAkQ1JPU1NfU1lTX1JPT1QiCi0JCXJl
dHVybiAxCi0JZmkKLX0KLQotd2FybmluZygpIHsKLQllY2hvCi0JZWNobyAiICoqKiBgYmFzZW5h
bWUgIiQwImAgRkFJTEVEJHsqKzogJCp9IgotfQotCi1mYWlsKCkgewotCWVjaG8KLQllY2hvICIg
KioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAkKn0iCi0JZXhpdCAxCi19CmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jb25maWcuaC5pbgotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuaC5p
bglUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxNiBAQAorLyoKKyAq
IENvcHlyaWdodCAoQykgMjAxMgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNo
ZWQKKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IHZlcnNpb24gMi4xIG9ubHku
IHdpdGggdGhlIHNwZWNpYWwKKyAqIGV4Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBm
aWxlIExJQ0VOU0UuCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBo
b3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7
IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZ
IG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIExl
c3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKi8KKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx5YWpsL3lhamxfdmVyc2lvbi5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1lBSkxfWUFKTF9WRVJTSU9OX0gKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NvbmZpZ3VyZS5hYwotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWd1cmUuYWMJVHVl
IEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTkyIEBACisjICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCisj
IFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0b2NvbmYgdG8gcHJvZHVjZSBhIGNvbmZpZ3VyZSBz
Y3JpcHQuCisKK0FDX1BSRVJFUShbMi42N10pCitBQ19JTklUKFtYZW4gSHlwZXJ2aXNvcl0sIG00
X2VzeXNjbWQoWy4uL3ZlcnNpb24uc2ggLi4veGVuL01ha2VmaWxlXSksCisgICAgW3hlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKK0FDX0NPTkZJR19TUkNESVIoW2xpYnhsL2xpYnhsLmNd
KQorQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMubWtdKQorQUNfQ09ORklHX0hFQURF
UlMoW2NvbmZpZy5oXSkKK0FDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkKK0FDX0NPTkZJR19BVVhf
RElSKFsuXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9y
IENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitBU19JRihbdGVzdCAtbiAiJENDJENG
TEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsKKyAgICBBQ19NU0dfV0FSTigKK1tT
ZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBub3Qg
XAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJQiwgXAorQVBQ
RU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS5dKQorXSkK
KworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCitBQ19DQU5PTklDQUxfSE9TVAorCisjIE00IE1h
Y3JvIGluY2x1ZGVzCittNF9pbmNsdWRlKFttNC9lbmFibGVfZmVhdHVyZS5tNF0pCittNF9pbmNs
dWRlKFttNC9kaXNhYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5jbHVkZShbbTQvcGF0aF9vcl9mYWls
Lm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0
aG9uX3ZlcnNpb24ubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX2RldmVsLm00XSkKK200X2lu
Y2x1ZGUoW200L3VkZXYubTRdKQorbTRfaW5jbHVkZShbbTQvb2NhbWwubTRdKQorbTRfaW5jbHVk
ZShbbTQvZGVmYXVsdF9saWIubTRdKQorbTRfaW5jbHVkZShbbTQvc2V0X2NmbGFnc19sZGZsYWdz
Lm00XSkKK200X2luY2x1ZGUoW200L3V1aWQubTRdKQorbTRfaW5jbHVkZShbbTQvcGtnLm00XSkK
KworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hz
bV0sCisgICAgW0VuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzayld
KQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtnaXRodHRwXSwgW0Rvd25sb2FkIEdJVCByZXBv
c2l0b3JpZXMgdmlhIEhUVFBdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbbW9uaXRvcnNd
LAorICAgIFtEaXNhYmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzXSkKK0FY
X0FSR19FTkFCTEVfQU5EX0VYUE9SVChbdnRwbV0sIFtFbmFibGUgVmlydHVhbCBUcnVzdGVkIFBs
YXRmb3JtIE1vZHVsZV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hhcGldLCBbRW5hYmxl
IFhlbiBBUEkgQmluZGluZ3NdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbcHl0aG9udG9v
bHNdLCBbRGlzYWJsZSBQeXRob24gdG9vbHNdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChb
b2NhbWx0b29sc10sIFtEaXNhYmxlIE9jYW1sIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VY
UE9SVChbbWluaXRlcm1dLCBbRW5hYmxlIG1pbml0ZXJtXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VY
UE9SVChbbG9tb3VudF0sIFtFbmFibGUgbG9tb3VudF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQ
T1JUKFtkZWJ1Z10sIFtEaXNhYmxlIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQgdG9vbHNdKQorCitB
Q19BUkdfVkFSKFtQUkVQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRl
cnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW1BSRVBF
TkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZM
QUdTICh3aXRob3V0IC1MKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfSU5DTFVERVNdLAorICAgIFtM
aXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0p
CitBQ19BUkdfVkFSKFtBUFBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMg
dG8gYXBwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKKworQVhfU0VUX0ZMQUdTCisKK0FD
X0FSR19WQVIoW1BZVEhPTl0sIFtQYXRoIHRvIHRoZSBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19W
QVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBhcnNlcl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQ
YXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJHX1ZBUihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkK
K0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGggdG8gQmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitB
Q19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8gRmxleCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRv
cl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1BhdGggdG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19B
UkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JB
U0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkKK0FDX0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGgg
dG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENoZWNrcyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NF
RAorQUNfUFJPR19DQworQUNfUFJPR19MTl9TCitBQ19QUk9HX01BS0VfU0VUCitBQ19QUk9HX0lO
U1RBTEwKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtQRVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtp
cF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQklTT05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitBU19JRihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBb
CisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0NVUkxdLCBbY3VybC1jb25maWddKQorICAgIEFY
X1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBbeG1sMi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0
ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsKKyAgICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYo
W3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWworICAgICAgICBBU19JRihbdGVzdCAieCRlbmFi
bGVfb2NhbWx0b29scyIgPSAieHllcyJdLCBbCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoW09j
YW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmluZCBPY2FtbF0pXSkKKyAgICAgICAg
b2NhbWx0b29scz0ibiIKKyAgICBdKQorXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCQVNIXSwg
W2Jhc2hdKQorQVNfSUYoW3Rlc3QgIngkcHl0aG9udG9vbHMiID0gInh5Il0sIFsKKyAgICBBU19J
RihbZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyJdLCBbCisgICAgICAgIFBZVEhPTlBBVEg9
JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorICAgIF0sW3Rl
c3QgLXogIiRQWVRIT04iXSwgW1BZVEhPTj0icHl0aG9uIl0sCisgICAgW0FDX01TR19FUlJPUihb
UFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoXSldKQorICAgIEFY
X1BBVEhfUFJPR19PUl9GQUlMKFtQWVRIT05QQVRIXSwgWyRQWVRIT05dKQorICAgIEFYX0NIRUNL
X1BZVEhPTl9WRVJTSU9OKFsyXSwgWzNdKQorICAgIEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAg
IEFYX0NIRUNLX1BZVEhPTl9ERVZFTCgpCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRU
RVhUXSwgW3hnZXR0ZXh0XSkKK0FYX0NIRUNLX1VERVYoWzU5XSkKK0FYX0NIRUNLX1VVSUQKK1BL
R19DSEVDS19NT0RVTEVTKGdsaWIsIGdsaWItMi4wKQorCisjIENoZWNrIGxpYnJhcnkgcGF0aAor
QVhfREVGQVVMVF9MSUIKKworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK0FDX0NIRUNLX0xJQihb
YWlvXSwgW2lvX3NldHVwXSwgW3N5c3RlbV9haW89InkiXSwgW3N5c3RlbV9haW89Im4iXSkKK0FD
X1NVQlNUKHN5c3RlbV9haW8pCitBQ19DSEVDS19MSUIoW2NyeXB0b10sIFtNRDVdLCBbXSwgW0FD
X01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGliY3J5cHRvXSldKQorQUNfQ0hFQ0tfTElCKFtl
eHQyZnNdLCBbZXh0MmZzX29wZW4yXSwgW2xpYmV4dDJmcz0ieSJdLCBbbGliZXh0MmZzPSJuIl0p
CitBQ19TVUJTVChsaWJleHQyZnMpCitBQ19DSEVDS19MSUIoW2djcnlwdF0sIFtnY3J5X21kX2hh
c2hfYnVmZmVyXSwgW2xpYmdjcnlwdD0ieSJdLCBbbGliZ2NyeXB0PSJuIl0pCitBQ19TVUJTVChs
aWJnY3J5cHQpCitBQ19DSEVDS19MSUIoW3B0aHJlYWRdLCBbcHRocmVhZF9jcmVhdGVdLCBbXSAs
CisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGlicHRocmVhZF0pXSkKK0FDX0NI
RUNLX0xJQihbcnRdLCBbY2xvY2tfZ2V0dGltZV0pCitBQ19DSEVDS19MSUIoW3V1aWRdLCBbdXVp
ZF9jbGVhcl0sIFtdLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnV1aWRd
KV0pCitBQ19DSEVDS19MSUIoW3lhamxdLCBbeWFqbF9hbGxvY10sIFtdLAorICAgIFtBQ19NU0df
RVJST1IoW0NvdWxkIG5vdCBmaW5kIHlhamxdKV0pCitBQ19DSEVDS19MSUIoW3pdLCBbZGVmbGF0
ZUNvcHldLCBbXSwgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgemxpYl0pXSkKK0FDX0NI
RUNLX0xJQihbaWNvbnZdLCBbbGliaWNvbnZfb3Blbl0sIFtsaWJpY29udj0ieSJdLCBbbGliaWNv
bnY9Im4iXSkKK0FDX1NVQlNUKGxpYmljb252KQorCisjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVz
LgorQUNfRlVOQ19BTExPQ0EKK0FDX0NIRUNLX0hFQURFUlMoWyBcCisgICAgICAgICAgICAgICAg
YXJwYS9pbmV0LmggZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2Mu
aCBcCisgICAgICAgICAgICAgICAgbmV0ZGIuaCBuZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50
Lmggc3RkbGliLmggc3RyaW5nLmggXAorICAgICAgICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmls
ZS5oIHN5cy9pb2N0bC5oIHN5cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKKyAgICAgICAgICAgICAg
ICBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3Mu
aCBcCisgICAgICAgICAgICAgICAgdW5pc3RkLmggeWFqbC95YWpsX3ZlcnNpb24uaCBcCisgICAg
ICAgICAgICAgICAgXSkKKworIyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQg
Y29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgorQUNfSEVBREVSX1NUREJPT0wKK0FDX1RZUEVfVUlE
X1QKK0FDX0NfSU5MSU5FCitBQ19UWVBFX0lOVDE2X1QKK0FDX1RZUEVfSU5UMzJfVAorQUNfVFlQ
RV9JTlQ2NF9UCitBQ19UWVBFX0lOVDhfVAorQUNfVFlQRV9NT0RFX1QKK0FDX1RZUEVfT0ZGX1QK
K0FDX1RZUEVfUElEX1QKK0FDX0NfUkVTVFJJQ1QKK0FDX1RZUEVfU0laRV9UCitBQ19UWVBFX1NT
SVpFX1QKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X2Jsa3NpemVdKQorQUNfU1RS
VUNUX1NUX0JMT0NLUworQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCitB
Q19UWVBFX1VJTlQxNl9UCitBQ19UWVBFX1VJTlQzMl9UCitBQ19UWVBFX1VJTlQ2NF9UCitBQ19U
WVBFX1VJTlQ4X1QKK0FDX0NIRUNLX1RZUEVTKFtwdHJkaWZmX3RdKQorCisjIENoZWNrcyBmb3Ig
bGlicmFyeSBmdW5jdGlvbnMuCitBQ19GVU5DX0VSUk9SX0FUX0xJTkUKK0FDX0ZVTkNfRk9SSwor
QUNfRlVOQ19GU0VFS08KK0FDX0ZVTkNfTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksKK0FD
X0hFQURFUl9NQUpPUgorQUNfRlVOQ19NQUxMT0MKK0FDX0ZVTkNfTUtUSU1FCitBQ19GVU5DX01N
QVAKK0FDX0ZVTkNfUkVBTExPQworQUNfRlVOQ19TVFJOTEVOCitBQ19GVU5DX1NUUlRPRAorQUNf
Q0hFQ0tfRlVOQ1MoWyBcCisgICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2Nr
X2dldHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKKyAgICAgICAgICAgICAgICBnZXRj
d2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAor
ICAgICAgICAgICAgICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1t
b3ZlIG1lbXNldCBta2RpciBcCisgICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29u
ZiByZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAorICAgICAgICAgICAgICAg
IHNvY2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVw
IFwKKyAgICAgICAgICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wg
c3RydG91bCBzdHJ0b3VsbCB0enNldCBcCisgICAgICAgICAgICAgICAgdW5hbWUgXAorICAgICAg
ICAgICAgICAgIF0pCisKK0FDX09VVFBVVCgpCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4
MjBlNDhhZSB0b29scy9kZWJ1Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQotLS0gYS90b29scy9kZWJ1
Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJVHVlIEZlYiAyMSAwNDoxODoyOSAy
MDEyICswMTAwCkBAIC0yMSw3ICsyMSw2IEBAIHhnX2FsbC5hOiAkKFhHX09CSlMpIE1ha2VmaWxl
ICQoWEdfSERSUykKICMJJChDQykgLW0zMiAtYyAtbyAkQCAkXgogCiB4ZW4taGVhZGVyczoKLQkk
KE1BS0UpIC1DIC4uLy4uLy4uL2NoZWNrIAogCSQoTUFLRSkgLUMgLi4vLi4vLi4vaW5jbHVkZQog
CiAjIHhnX21haW4ubzogeGdfbWFpbi5jIE1ha2VmaWxlICQoWEdfSERSUykKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2luc3RhbGwuc2gKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvaW5zdGFsbC5zaAlUdWUg
RmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxIEBACisuLi9pbnN0YWxsLnNo
ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYw
ODIwZTQ4YWUgdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQotLS0gYS90b29scy9saWJmc2ltYWdl
L01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9saWJm
c2ltYWdlL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMyw3ICsz
LDExIEBAIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsKIAogU1VCRElSUy15ID0g
Y29tbW9uIHVmcyByZWlzZXJmcyBpc285NjYwIGZhdCB6ZnMKIFNVQkRJUlMtJChDT05GSUdfWDg2
KSArPSB4ZnMKLVNVQkRJUlMteSArPSAkKHNoZWxsIGVudiBDQz0iJChDQykiIC4vY2hlY2stbGli
ZXh0MmZzKQoraWZlcSAoJChDT05GSUdfRVhUMkZTKSwgeSkKKyAgICBTVUJESVJTLXkgKz0gZXh0
MmZzLWxpYgorZWxzZQorICAgIFNVQkRJUlMteSArPSBleHQyZnMKK2VuZGlmCiAKIC5QSE9OWTog
YWxsIGNsZWFuIGluc3RhbGwKIGFsbCBjbGVhbiBpbnN0YWxsOiAlOiBzdWJkaXJzLSUKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGli
ZXh0MmZzCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCU1vbiBGZWIgMjAg
MTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMApAQCAtMSwyMSArMCwwIEBACi0jIS9iaW4vc2gKLQotY2F0ID5leHQyLXRlc3QuYyA8
PEVPRgotI2luY2x1ZGUgPGV4dDJmcy9leHQyZnMuaD4KLQotaW50IG1haW4oKQotewotCWV4dDJm
c19vcGVuMjsKLX0KLUVPRgotCi0ke0NDLWdjY30gLW8gZXh0Mi10ZXN0IGV4dDItdGVzdC5jIC1s
ZXh0MmZzID4vZGV2L251bGwgMj4mMQotaWYgWyAkPyA9IDAgXTsgdGhlbgotCWVjaG8gZXh0MmZz
LWxpYgotZWxzZQotCWVjaG8gZXh0MmZzCi1maQotCi1ybSAtZiBleHQyLXRlc3QgZXh0Mi10ZXN0
LmMKLQotZXhpdCAwCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9s
aWJ4ZW4vTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGVuL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6
MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9saWJ4ZW4vTWFrZWZpbGUJVHVlIEZlYiAyMSAw
NDoxODoyOSAyMDEyICswMTAwCkBAIC0yMiwxMiArMjIsMTIgQEAgTUFKT1IgPSAxLjAKIE1JTk9S
ID0gMAogCiBDRkxBR1MgKz0gLUlpbmNsdWRlICAgICAgICAgICAgICAgICAgICAgXAotICAgICAg
ICAgICQoc2hlbGwgeG1sMi1jb25maWcgLS1jZmxhZ3MpIFwKLSAgICAgICAgICAkKHNoZWxsIGN1
cmwtY29uZmlnIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAkKFhNTDJfQ09ORklHKSAt
LWNmbGFncykgXAorICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1jZmxhZ3MpIFwK
ICAgICAgICAgICAtZlBJQwogCi1MREZMQUdTICs9ICQoc2hlbGwgeG1sMi1jb25maWcgLS1saWJz
KSBcCi0gICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1saWJzKQorTERGTEFHUyArPSAk
KHNoZWxsICQoWE1MMl9DT05GSUcpIC0tbGlicykgXAorICAgICAgICAgICAkKHNoZWxsICQoQ1VS
TF9DT05GSUcpIC0tbGlicykKIAogTElCWEVOQVBJX0hEUlMgPSAkKHdpbGRjYXJkIGluY2x1ZGUv
eGVuL2FwaS8qLmgpIGluY2x1ZGUveGVuL2FwaS94ZW5fYWxsLmgKIExJQlhFTkFQSV9PQkpTID0g
JChwYXRzdWJzdCAlLmMsICUubywgJCh3aWxkY2FyZCBzcmMvKi5jKSkKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2xpYnhsL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xp
YnhsL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9s
aWJ4bC9NYWtlZmlsZQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTE5LDEwICsx
OSw2IEBAIGlmZXEgKCQoQ09ORklHX0xpbnV4KSx5KQogTElCVVVJRF9MSUJTICs9IC1sdXVpZAog
ZW5kaWYKIAotaWZlcSAoJChDT05GSUdfWUFKTF9WRVJTSU9OKSx5KQotQ0ZMQUdTICs9IC1ESEFW
RV9ZQUpMX1ZFUlNJT04KLWVuZGlmCi0KIExJQlhMX0xJQlMgPQogTElCWExfTElCUyA9ICQoTERM
SUJTX2xpYnhlbmN0cmwpICQoTERMSUJTX2xpYnhlbmd1ZXN0KSAkKExETElCU19saWJ4ZW5zdG9y
ZSkgJChMRExJQlNfbGliYmxrdGFwY3RsKSAkKFVUSUxfTElCUykgJChMSUJVVUlEX0xJQlMpCiAK
QEAgLTU2LDcgKzUyLDcgQEAgTElCWExfT0JKUyA9IGZsZXhhcnJheS5vIGxpYnhsLm8gbGlieGxf
YwogCQkJbGlieGxfcW1wLm8gbGlieGxfZXZlbnQubyAkKExJQlhMX09CSlMteSkKIExJQlhMX09C
SlMgKz0gX2xpYnhsX3R5cGVzLm8gbGlieGxfZmxhc2subyBfbGlieGxfdHlwZXNfaW50ZXJuYWwu
bwogCi0kKExJQlhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxB
R1NfbGlieGVuZ3Vlc3QpICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKSAkKENGTEFHU19saWJibGt0YXBj
dGwpCiskKExJQlhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxB
R1NfbGlieGVuZ3Vlc3QpICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKSAkKENGTEFHU19saWJibGt0YXBj
dGwpIC1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL2NvbmZpZy5oCiAKIEFVVE9JTkNTPSBsaWJ4
bHVfY2ZnX3kuaCBsaWJ4bHVfY2ZnX2wuaCBfbGlieGxfbGlzdC5oCiBBVVRPU1JDUz0gbGlieGx1
X2NmZ195LmMgbGlieGx1X2NmZ19sLmMKQEAgLTY5LDYgKzY1LDcgQEAgQ0xJRU5UUyA9IHhsIHRl
c3RpZGwKIFhMX09CSlMgPSB4bC5vIHhsX2NtZGltcGwubyB4bF9jbWR0YWJsZS5vIHhsX3N4cC5v
CiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3IgeGVudG9v
bGxvZy5oCiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVubGlnaHQpCiskKFhM
X09CSlMpOiBDRkxBR1MgKz0gLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvY29uZmlnLmggIyBs
aWJ4bF9qc29uLmggbmVlZHMgaXQuCiAKIHRlc3RpZGwubzogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xp
YnhlbmN0cmwpICQoQ0ZMQUdTX2xpYnhlbmxpZ2h0KQogdGVzdGlkbC5jOiBsaWJ4bF90eXBlcy5p
ZGwgZ2VudGVzdC5weSBsaWJ4bC5oICQoQVVUT0lOQ1MpCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGMyZjA4MjBlNDhhZSB0b29scy9saWJ4bC9saWJ4bF9qc29uLmgKLS0tIGEvdG9vbHMvbGlieGwv
bGlieGxfanNvbi5oCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9s
aWJ4bC9saWJ4bF9qc29uLmgJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0xOCw3
ICsxOCw3IEBACiAjaW5jbHVkZSA8eWFqbC95YWpsX2dlbi5oPgogI2luY2x1ZGUgPHlhamwveWFq
bF9wYXJzZS5oPgogCi0jaWZkZWYgSEFWRV9ZQUpMX1ZFUlNJT04KKyNpZmRlZiBIQVZFX1lBSkxf
WUFKTF9WRVJTSU9OX0gKICMgIGluY2x1ZGUgPHlhamwveWFqbF92ZXJzaW9uLmg+CiAjZW5kaWYK
IApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvbTQvZGVmYXVsdF9s
aWIubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvZGVmYXVsdF9saWIubTQJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsOCBAQAorQUNfREVGVU4oW0FYX0RFRkFVTFRfTElCXSwKK1tBU19JRihbdGVzdCAt
ZCAiJHByZWZpeC9saWI2NCJdLCBbCisgICAgTElCX1BBVEg9ImxpYjY0IgorXSxbCisgICAgTElC
X1BBVEg9ImxpYiIKK10pCitBQ19TVUJTVChMSUJfUEFUSCldKQorCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZGlzYWJs
ZV9mZWF0dXJlLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEz
IEBACitBQ19ERUZVTihbQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVF0sCitbQUNfQVJHX0VOQUJM
RShbJDFdLAorICAgIEFTX0hFTFBfU1RSSU5HKFstLWRpc2FibGUtJDFdLCBbJDJdKSkKKworQVNf
SUYoW3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4bm8iXSwgWworICAgIGF4X2N2XyQxPSJuIgorXSwg
W3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4eWVzIl0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0
ZXN0IC16ICRheF9jdl8kMV0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10pCiskMT0kYXhfY3ZfJDEK
K0FDX1NVQlNUKCQxKV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29s
cy9tNC9lbmFibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9lbmFibGVfZmVhdHVyZS5tNAlUdWUgRmViIDIxIDA0
OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMyBAQAorQUNfREVGVU4oW0FYX0FSR19FTkFC
TEVfQU5EX0VYUE9SVF0sCitbQUNfQVJHX0VOQUJMRShbJDFdLAorICAgIEFTX0hFTFBfU1RSSU5H
KFstLWVuYWJsZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInh5
ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4bm8i
XSwgWworICAgIGF4X2N2XyQxPSJuIgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4
X2N2XyQxPSJuIgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL200L29jYW1sLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L29jYW1sLm00CVR1
ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDI0MSBAQAorZG5sIGF1dG9j
b25mIG1hY3JvcyBmb3IgT0NhbWwKK2RubCBmcm9tIGh0dHA6Ly9mb3JnZS5vY2FtbGNvcmUub3Jn
LworZG5sCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAgICBSaWNoYXJkIFcuTS4gSm9uZXMKK2Ru
bCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFN0ZWZhbm8gWmFjY2hpcm9saQorZG5sIENvcHlyaWdo
dCDCqSAyMDAwLTIwMDUgT2xpdmllciBBbmRyaWV1CitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAw
NSBKZWFuLUNocmlzdG9waGUgRmlsbGnDonRyZQorZG5sIENvcHlyaWdodCDCqSAyMDAwLTIwMDUg
R2VvcmdlcyBNYXJpYW5vCitkbmwKK2RubCBGb3IgZG9jdW1lbnRhdGlvbiwgcGxlYXNlIHJlYWQg
dGhlIG9jYW1sLm00IG1hbiBwYWdlLgorCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTF0sCitbZG5s
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sYworICBBQ19DSEVDS19UT09MKFtPQ0FNTENdLFtvY2Ft
bGNdLFtub10pCisKKyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FN
TFZFUlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxc
MXxwJ2AKKyAgICAgQUNfTVNHX1JFU1VMVChbT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9O
XSkKKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAorICAgICBpZiB0ZXN0ICIkT0NB
TUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rl
di9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRgCisgICAgIGVsc2UK
KyAgICAgICAgQUNfTVNHX1JFU1VMVChbT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZp
bmcgaXQuXSkKKyAgICAgZmkKKyAgICAgQUNfTVNHX1JFU1VMVChbT0NhbWwgbGlicmFyeSBwYXRo
IGlzICRPQ0FNTExJQl0pCisKKyAgICAgQUNfU1VCU1QoW09DQU1MVkVSU0lPTl0pCisgICAgIEFD
X1NVQlNUKFtPQ0FNTExJQl0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQKKyAgICAg
QUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRdLFtvY2FtbG9wdF0sW25vXSkKKyAgICAgT0NBTUxCRVNU
PWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KKwlBQ19NU0dfV0FS
TihbQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuXSkKKyAg
ICAgZWxzZQorCVRNUFZFUlNJT049YCRPQ0FNTE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNp
b24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZF
UlNJT04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuXSkKKwkgICAgT0NBTUxPUFQ9bm8KKwllbHNlCisJ
ICAgIE9DQU1MQkVTVD1vcHQKKwlmaQorICAgICBmaQorCisgICAgIEFDX1NVQlNUKFtPQ0FNTEJF
U1RdKQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgQUNfQ0hFQ0tfVE9P
TChbT0NBTUxDRE9UT1BUXSxbb2NhbWxjLm9wdF0sW25vXSkKKyAgICAgaWYgdGVzdCAiJE9DQU1M
Q0RPVE9QVCIgIT0gIm5vIjsgdGhlbgorCVRNUFZFUlNJT049YCRPQ0FNTENET1RPUFQgLXYgfCBz
ZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZF
UlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVy
c2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuXSkKKwllbHNl
CisJICAgIE9DQU1MQz0kT0NBTUxDRE9UT1BUCisJZmkKKyAgICAgZmkKKworICAgICAjIGNoZWNr
aW5nIGZvciBvY2FtbG9wdC5vcHQKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsg
dGhlbgorCUFDX0NIRUNLX1RPT0woW09DQU1MT1BURE9UT1BUXSxbb2NhbWxvcHQub3B0XSxbbm9d
KQorCWlmIHRlc3QgIiRPQ0FNTE9QVERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCSAgIFRNUFZFUlNJ
T049YCRPQ0FNTE9QVERPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkk
fFwxfHAnIGAKKwkgICBpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsg
dGhlbgorCSAgICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxvcHQub3B0IGRpc2NhcmRlZC5dKQorCSAgIGVsc2UKKwkgICAgICBPQ0FNTE9QVD0kT0NB
TUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAgICBmaQorCisgICAgIEFDX1NVQlNU
KFtPQ0FNTE9QVF0pCisgIGZpCisKKyAgQUNfU1VCU1QoW09DQU1MQ10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxdLFtvY2FtbF0sW25v
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGRlcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTERF
UF0sW29jYW1sZGVwXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWt0b3AKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxNS1RPUF0sW29jYW1sbWt0b3BdLFtub10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxta2xpYgorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LTElCXSxbb2NhbWxta2xp
Yl0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGRvYworICBBQ19DSEVDS19UT09MKFtP
Q0FNTERPQ10sW29jYW1sZG9jXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQK
KyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxCVUlMRF0sW29jYW1sYnVpbGRdLFtub10pCitdKQorCisK
K0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MTEVYXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2Nh
bWxsZXgKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxMRVhdLFtvY2FtbGxleF0sW25vXSkKKyAgaWYg
dGVzdCAiJE9DQU1MTEVYIiAhPSAibm8iOyB0aGVuCisgICAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxM
RVhET1RPUFRdLFtvY2FtbGxleC5vcHRdLFtub10pCisgICAgaWYgdGVzdCAiJE9DQU1MTEVYRE9U
T1BUIiAhPSAibm8iOyB0aGVuCisJT0NBTUxMRVg9JE9DQU1MTEVYRE9UT1BUCisgICAgZmkKKyAg
ZmkKKyAgQUNfU1VCU1QoW09DQU1MTEVYXSkKK10pCisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1M
WUFDQ10sCitbZG5sCisgIEFDX0NIRUNLX1RPT0woW09DQU1MWUFDQ10sW29jYW1seWFjY10sW25v
XSkKKyAgQUNfU1VCU1QoW09DQU1MWUFDQ10pCitdKQorCisKK0FDX0RFRlVOKFtBQ19QUk9HX0NB
TUxQNF0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisgICMgY2hl
Y2tpbmcgZm9yIGNhbWxwNAorICBBQ19DSEVDS19UT09MKFtDQU1MUDRdLFtjYW1scDRdLFtub10p
CisgIGlmIHRlc3QgIiRDQU1MUDQiICE9ICJubyI7IHRoZW4KKyAgICAgVE1QVkVSU0lPTj1gJENB
TUxQNCAtdiAyPiYxfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uICpcKC4qXCkkfFwxfHAnYAorICAg
ICBpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCUFDX01T
R19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGNdKQorICAgICAgICBDQU1MUDQ9
bm8KKyAgICAgZmkKKyAgZmkKKyAgQUNfU1VCU1QoW0NBTUxQNF0pCisKKyAgIyBjaGVja2luZyBm
b3IgY29tcGFuaW9uIHRvb2xzCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNEJPT1RdLFtjYW1scDRi
b290XSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPXSxbY2FtbHA0b10sW25vXSkKKyAg
QUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T0ZdLFtjYW1scDRvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9P
TChbQ0FNTFA0T09GXSxbY2FtbHA0b29mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRP
UkZdLFtjYW1scDRvcmZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFBST0ZdLFtjYW1s
cDRwcm9mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRSXSxbY2FtbHA0cl0sW25vXSkK
KyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UkZdLFtjYW1scDRyZl0sW25vXSkKKyAgQUNfU1VCU1Qo
W0NBTUxQNEJPT1RdKQorICBBQ19TVUJTVChbQ0FNTFA0T10pCisgIEFDX1NVQlNUKFtDQU1MUDRP
Rl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPT0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0T1JGXSkKKyAg
QUNfU1VCU1QoW0NBTUxQNFBST0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0Ul0pCisgIEFDX1NVQlNU
KFtDQU1MUDRSRl0pCitdKQorCisKK0FDX0RFRlVOKFtBQ19QUk9HX0ZJTkRMSUJdLAorW2RubAor
ICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKworICAjIGNoZWNraW5nIGZvciBvY2Ft
bGZpbmQKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxGSU5EXSxbb2NhbWxmaW5kXSxbbm9dKQorICBB
Q19TVUJTVChbT0NBTUxGSU5EXSkKK10pCisKKworZG5sIFRoYW5rcyB0byBKaW0gTWV5ZXJpbmcg
Zm9yIHdvcmtpbmcgdGhpcyBuZXh0IGJpdCBvdXQgZm9yIHVzLgorZG5sIFhYWCBXZSBzaG91bGQg
ZGVmaW5lIEFTX1RSX1NIIGlmIGl0J3Mgbm90IGRlZmluZWQgYWxyZWFkeQorZG5sIChlZy4gZm9y
IG9sZCBhdXRvY29uZikuCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfUEtHXSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19GSU5ETElCXSlkbmwKKworICBBQ19NU0dfQ0hFQ0tJTkcoW2Zv
ciBPQ2FtbCBmaW5kbGliIHBhY2thZ2UgJDFdKQorCisgIHVuc2V0IGZvdW5kCisgIHVuc2V0IHBr
ZworICBmb3VuZD1ubworICBmb3IgcGtnIGluICQxICQyIDsgZG8KKyAgICBpZiAkT0NBTUxGSU5E
IHF1ZXJ5ICRwa2cgPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbgorICAgICAgQUNfTVNHX1JF
U1VMVChbZm91bmRdKQorICAgICAgQVNfVFJfU0goW09DQU1MX1BLR18kMV0pPSRwa2cKKyAgICAg
IGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBkb25lCisgIGlmIHRlc3QgIiRmb3Vu
ZCIgPSAibm8iIDsgdGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vdCBmb3VuZF0pCisgICAgQVNf
VFJfU0goW09DQU1MX1BLR18kMV0pPW5vCisgIGZpCisKKyAgQUNfU1VCU1QoQVNfVFJfU0goW09D
QU1MX1BLR18kMV0pKQorXSkKKworCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfTU9EVUxFXSwK
K1tkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgbW9kdWxlICQyXSkKKworICBjYXQg
PiBjb25mdGVzdC5tbCA8PEVPRgorb3BlbiAkMworRU9GCisgIHVuc2V0IGZvdW5kCisgIGZvciAk
MSBpbiAkJDEgJDQgOyBkbworICAgIGlmICRPQ0FNTEMgLWMgLUkgIiQkMSIgY29uZnRlc3QubWwg
PiY1IDI+JjUgOyB0aGVuCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAg
ZG9uZQorCisgIGlmIHRlc3QgIiRmb3VuZCIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbJCQx
XSkKKyAgZWxzZQorICAgIEFDX01TR19SRVNVTFQoW25vdCBmb3VuZF0pCisgICAgJDE9bm8KKyAg
ZmkKKyAgQUNfU1VCU1QoWyQxXSkKK10pCisKKworZG5sIFhYWCBDcm9zcy1jb21waWxpbmcKK0FD
X0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9XT1JEX1NJWkVdLAorW2RubAorICBBQ19SRVFVSVJFKFtB
Q19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgY29tcGlsZXIg
d29yZCBzaXplXSkKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfZW5kbGluZSAo
c3RyaW5nX29mX2ludCBTeXMud29yZF9zaXplKQorICBFT0YKKyAgT0NBTUxfV09SRF9TSVpFPWAk
T0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9XT1JEX1NJWkVdKQor
ICBBQ19TVUJTVChbT0NBTUxfV09SRF9TSVpFXSkKK10pCisKK0FDX0RFRlVOKFtBQ19DSEVDS19P
Q0FNTF9PU19UWVBFXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisg
IEFDX01TR19DSEVDS0lORyhbT0NhbWwgU3lzLm9zX3R5cGVdKQorCisgIGNhdCA+IGNvbmZ0ZXN0
Lm1sIDw8RU9GCisgIHByaW50X3N0cmluZyhTeXMub3NfdHlwZSk7OworRU9GCisKKyAgT0NBTUxf
T1NfVFlQRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFskT0NBTUxfT1Nf
VFlQRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9PU19UWVBFXSkKK10pCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9wYXRoX29yX2ZhaWwubTQKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcGF0aF9vcl9m
YWlsLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDYgQEAKK0FD
X0RFRlVOKFtBWF9QQVRIX1BST0dfT1JfRkFJTF0sCitbQUNfUEFUSF9QUk9HKFskMV0sIFskMl0s
IFtub10pCitpZiB0ZXN0IHgiJHskMX0iID09IHgibm8iIAordGhlbgorICAgIEFDX01TR19FUlJP
UihbVW5hYmxlIHRvIGZpbmQgJDIsIHBsZWFzZSBpbnN0YWxsICQyXSkKK2ZpXSkKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL200L3BrZy5tNAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9wa2cubTQJVHVl
IEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTU3IEBACisjIHBrZy5tNCAt
IE1hY3JvcyB0byBsb2NhdGUgYW5kIHV0aWxpc2UgcGtnLWNvbmZpZy4gICAgICAgICAgICAtKi0g
QXV0b2NvbmYgLSotCisjIHNlcmlhbCAxIChwa2ctY29uZmlnLTAuMjQpCisjIAorIyBDb3B5cmln
aHQgwqkgMjAwNCBTY290dCBKYW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+LgorIwor
IyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeQorIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRp
b24pIGFueSBsYXRlciB2ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJVEhPVVQgQU5ZIFdB
UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRB
QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUK
KyMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hv
dWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZQorIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBT
b2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAs
IEJvc3RvbiwgTUEgMDIxMTEtMTMwNywgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhjZXB0aW9u
IHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3RyaWJ1dGUg
dGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBjb25maWd1
cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVkZSBpdCB1
bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZvciB0aGUg
cmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKyMgUEtHX1BST0dfUEtHX0NPTkZJRyhbTUlOLVZFUlNJ
T05dKQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCitBQ19ERUZVTihbUEtH
X1BST0dfUEtHX0NPTkZJR10sCitbbTRfcGF0dGVybl9mb3JiaWQoW15fP1BLR19bQS1aX10rJF0p
CittNF9wYXR0ZXJuX2FsbG93KFteUEtHX0NPTkZJRyhfUEFUSCk/JF0pCitBQ19BUkdfVkFSKFtQ
S0dfQ09ORklHXSwgW3BhdGggdG8gcGtnLWNvbmZpZyB1dGlsaXR5XSkKK0FDX0FSR19WQVIoW1BL
R19DT05GSUdfUEFUSF0sIFtkaXJlY3RvcmllcyB0byBhZGQgdG8gcGtnLWNvbmZpZydzIHNlYXJj
aCBwYXRoXSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUdfTElCRElSXSwgW3BhdGggb3ZlcnJpZGlu
ZyBwa2ctY29uZmlnJ3MgYnVpbHQtaW4gc2VhcmNoIHBhdGhdKQorCitpZiB0ZXN0ICJ4JGFjX2N2
X2Vudl9QS0dfQ09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCisJQUNfUEFUSF9UT09MKFtQS0df
Q09ORklHXSwgW3BrZy1jb25maWddKQorZmkKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhl
bgorCV9wa2dfbWluX3ZlcnNpb249bTRfZGVmYXVsdChbJDFdLCBbMC45LjBdKQorCUFDX01TR19D
SEVDS0lORyhbcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9u
XSkKKwlpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gJF9wa2dfbWlu
X3ZlcnNpb247IHRoZW4KKwkJQUNfTVNHX1JFU1VMVChbeWVzXSkKKwllbHNlCisJCUFDX01TR19S
RVNVTFQoW25vXSkKKwkJUEtHX0NPTkZJRz0iIgorCWZpCitmaVtdZG5sCitdKSMgUEtHX1BST0df
UEtHX0NPTkZJRworCisjIFBLR19DSEVDS19FWElTVFMoTU9EVUxFUywgW0FDVElPTi1JRi1GT1VO
RF0sIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkKKyMKKyMgQ2hlY2sgdG8gc2VlIHdoZXRoZXIgYSBw
YXJ0aWN1bGFyIHNldCBvZiBtb2R1bGVzIGV4aXN0cy4gIFNpbWlsYXIKKyMgdG8gUEtHX0NIRUNL
X01PRFVMRVMoKSwgYnV0IGRvZXMgbm90IHNldCB2YXJpYWJsZXMgb3IgcHJpbnQgZXJyb3JzLgor
IworIyBQbGVhc2UgcmVtZW1iZXIgdGhhdCBtNCBleHBhbmRzIEFDX1JFUVVJUkUoW1BLR19QUk9H
X1BLR19DT05GSUddKQorIyBvbmx5IGF0IHRoZSBmaXJzdCBvY2N1cmVuY2UgaW4gY29uZmlndXJl
LmFjLCBzbyBpZiB0aGUgZmlyc3QgcGxhY2UKKyMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBl
ZCAoc3VjaCBhcyBpZiBpdCBpcyB3aXRoaW4gYW4gImlmIiwgeW91CisjIGhhdmUgdG8gY2FsbCBQ
S0dfQ0hFQ0tfRVhJU1RTIG1hbnVhbGx5CisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCitBQ19ERUZVTihbUEtHX0NIRUNLX0VY
SVNUU10sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pZG5sCitpZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIEFDX1JVTl9MT0coWyRQS0dfQ09ORklHIC0tZXhpc3Rz
IC0tcHJpbnQtZXJyb3JzICIkMSJdKTsgdGhlbgorICBtNF9kZWZhdWx0KFskMl0sIFs6XSkKK200
X2lmdmFsbihbJDNdLCBbZWxzZQorICAkM10pZG5sCitmaV0pCisKKyMgX1BLR19DT05GSUcoW1ZB
UklBQkxFXSwgW0NPTU1BTkRdLCBbTU9EVUxFU10pCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorbTRfZGVmaW5lKFtfUEtHX0NPTkZJR10sCitbaWYgdGVz
dCAtbiAiJCQxIjsgdGhlbgorICAgIHBrZ19jdl9bXSQxPSIkJDEiCisgZWxpZiB0ZXN0IC1uICIk
UEtHX0NPTkZJRyI7IHRoZW4KKyAgICBQS0dfQ0hFQ0tfRVhJU1RTKFskM10sCisgICAgICAgICAg
ICAgICAgICAgICBbcGtnX2N2X1tdJDE9YCRQS0dfQ09ORklHIC0tW10kMiAiJDMiIDI+L2Rldi9u
dWxsYF0sCisJCSAgICAgW3BrZ19mYWlsZWQ9eWVzXSkKKyBlbHNlCisgICAgcGtnX2ZhaWxlZD11
bnRyaWVkCitmaVtdZG5sCitdKSMgX1BLR19DT05GSUcKKworIyBfUEtHX1NIT1JUX0VSUk9SU19T
VVBQT1JURUQKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtfUEtH
X1NIT1JUX0VSUk9SU19TVVBQT1JURURdLAorW0FDX1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05G
SUddKQoraWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uIDAuMjA7IHRo
ZW4KKyAgICAgICAgX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkPXllcworZWxzZQorICAgICAg
ICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9bm8KK2ZpW11kbmwKK10pIyBfUEtHX1NIT1JU
X0VSUk9SU19TVVBQT1JURUQKKworCisjIFBLR19DSEVDS19NT0RVTEVTKFZBUklBQkxFLVBSRUZJ
WCwgTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sCisjIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkK
KyMKKyMKKyMgTm90ZSB0aGF0IGlmIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhlIGZpcnN0IGNh
bGwgdG8KKyMgUEtHX0NIRUNLX01PRFVMRVMgbWlnaHQgbm90IGhhcHBlbiwgeW91IHNob3VsZCBi
ZSBzdXJlIHRvIGluY2x1ZGUgYW4KKyMgZXhwbGljaXQgY2FsbCB0byBQS0dfUFJPR19QS0dfQ09O
RklHIGluIHlvdXIgY29uZmlndXJlLmFjCisjCisjCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCitBQ19ERUZVTihbUEtHX0NI
RUNLX01PRFVMRVNdLAorW0FDX1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05GSUddKWRubAorQUNf
QVJHX1ZBUihbJDFdW19DRkxBR1NdLCBbQyBjb21waWxlciBmbGFncyBmb3IgJDEsIG92ZXJyaWRp
bmcgcGtnLWNvbmZpZ10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0xJQlNdLCBbbGlua2VyIGZsYWdz
IGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlkbmwKKworcGtnX2ZhaWxlZD1ubworQUNf
TVNHX0NIRUNLSU5HKFtmb3IgJDFdKQorCitfUEtHX0NPTkZJRyhbJDFdW19DRkxBR1NdLCBbY2Zs
YWdzXSwgWyQyXSkKK19QS0dfQ09ORklHKFskMV1bX0xJQlNdLCBbbGlic10sIFskMl0pCisKK200
X2RlZmluZShbX1BLR19URVhUXSwgW0FsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZp
cm9ubWVudCB2YXJpYWJsZXMgJDFbXV9DRkxBR1MKK2FuZCAkMVtdX0xJQlMgdG8gYXZvaWQgdGhl
IG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgorU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZv
ciBtb3JlIGRldGFpbHMuXSkKKworaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHllczsgdGhlbgorICAg
CUFDX01TR19SRVNVTFQoW25vXSkKKyAgICAgICAgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVE
CisgICAgICAgIGlmIHRlc3QgJF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZCA9IHllczsgdGhl
bgorCSAgICAgICAgJDFbXV9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXNob3J0LWVycm9ycyAt
LXByaW50LWVycm9ycyAiJDIiIDI+JjFgCisgICAgICAgIGVsc2UgCisJICAgICAgICAkMVtdX1BL
R19FUlJPUlM9YCRQS0dfQ09ORklHIC0tcHJpbnQtZXJyb3JzICIkMiIgMj4mMWAKKyAgICAgICAg
ZmkKKwkjIFB1dCB0aGUgbmFzdHkgZXJyb3IgbWVzc2FnZSBpbiBjb25maWcubG9nIHdoZXJlIGl0
IGJlbG9uZ3MKKwllY2hvICIkJDFbXV9QS0dfRVJST1JTIiA+JkFTX01FU1NBR0VfTE9HX0ZECisK
KwltNF9kZWZhdWx0KFskNF0sIFtBQ19NU0dfRVJST1IoCitbUGFja2FnZSByZXF1aXJlbWVudHMg
KCQyKSB3ZXJlIG5vdCBtZXQ6CisKKyQkMV9QS0dfRVJST1JTCisKK0NvbnNpZGVyIGFkanVzdGlu
ZyB0aGUgUEtHX0NPTkZJR19QQVRIIGVudmlyb25tZW50IHZhcmlhYmxlIGlmIHlvdQoraW5zdGFs
bGVkIHNvZnR3YXJlIGluIGEgbm9uLXN0YW5kYXJkIHByZWZpeC4KKworX1BLR19URVhUXSlkbmwK
KyAgICAgICAgXSkKK2VsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KKyAgICAg
CUFDX01TR19SRVNVTFQoW25vXSkKKwltNF9kZWZhdWx0KFskNF0sIFtBQ19NU0dfRkFJTFVSRSgK
K1tUaGUgcGtnLWNvbmZpZyBzY3JpcHQgY291bGQgbm90IGJlIGZvdW5kIG9yIGlzIHRvbyBvbGQu
ICBNYWtlIHN1cmUgaXQKK2lzIGluIHlvdXIgUEFUSCBvciBzZXQgdGhlIFBLR19DT05GSUcgZW52
aXJvbm1lbnQgdmFyaWFibGUgdG8gdGhlIGZ1bGwKK3BhdGggdG8gcGtnLWNvbmZpZy4KKworX1BL
R19URVhUCisKK1RvIGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVk
ZXNrdG9wLm9yZy8+Ll0pZG5sCisgICAgICAgIF0pCitlbHNlCisJJDFbXV9DRkxBR1M9JHBrZ19j
dl9bXSQxW11fQ0ZMQUdTCisJJDFbXV9MSUJTPSRwa2dfY3ZfW10kMVtdX0xJQlMKKyAgICAgICAg
QUNfTVNHX1JFU1VMVChbeWVzXSkKKwkkMworZmlbXWRubAorXSkjIFBLR19DSEVDS19NT0RVTEVT
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9weXRob25fZGV2
ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvcHl0aG9uX2RldmVsLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApA
QCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tBQ19N
U0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQg
b3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhw
ICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEp
CisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFja2Fn
ZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9weXRob25fdmVyc2lvbi5t
NAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29s
cy9tNC9weXRob25fdmVyc2lvbi5tNAlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSwxMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tBQ19N
U0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04gLWMg
J2ltcG9ydCBzeXM7IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikpJ2AK
K2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAt
ViAyPiYxYAorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisgICAg
ICAgIFskcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9u
IGlzICQxLiQyXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1y
IGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvbTQvcHl0aG9uX3htbC5tNAotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9w
eXRob25feG1sLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEw
IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5HKFtm
b3IgcHl0aG9uIHhtbC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20u
bWluaWRvbSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VMVChb
bm9dKQorICAgIEFDX01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1v
ZHVsZV0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsMjAgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBjZmxhZyBpbiAk
UFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2Rv
bmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRfTERGTEFHUys9
IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURFUworZG8KKyAg
ICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkQVBQRU5E
X0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitDRkxBR1M9
IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFHUz0iJFBSRVBF
TkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00CVR1ZSBGZWIg
MjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZVTihbQVhfQ0hF
Q0tfVURFVl0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4KKyAg
ICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVzdCB4
IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtV
REVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJTkZP
fSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAorICAg
ICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2Ug
aW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5GT30g
LVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7VURF
VkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVzdCAk
e3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQTFVH
XSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0geCJu
byIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRvbyBv
bGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAgZmkK
K2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkKKyAg
ICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBBQ19N
U0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkKKyAg
ICBmaQorZmkKK10pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9t
NC91dWlkLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3Rvb2xzL200L3V1aWQubTQJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0w
LDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VVUlEXSwKK1tpZiB0ZXN0ICJ4JGhvc3Rf
b3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgIEFDX0NIRUNLX0hFQURFUihbdXVpZC91dWlk
LmhdLCwKKwkgICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzXSldKQor
ZWxzZQorICAgIEFDX0NIRUNLX0hFQURFUihbdXVpZC5oXSwsCisJICAgIFtBQ19NU0dfRVJST1Io
W2Nhbm5vdCBmaW5kIHV1aWQgaGVhZGVyc10pXSkKK2ZpCitdKQpkaWZmIC1yIGNhODBlY2E5Y2Zh
MyAtciBjMmYwODIwZTQ4YWUgdmVyc2lvbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi92ZXJzaW9uLnNoCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAx
MiArMDEwMApAQCAtMCwwICsxLDUgQEAKKyMhL2Jpbi9zaAorCitNQUpPUj1gZ3JlcCAiZXhwb3J0
IFhFTl9WRVJTSU9OIiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdy
ZXAgImV4cG9ydCBYRU5fU1VCVkVSU0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIg
ImAKK3ByaW50ZiAiJWQuJWQiICRNQUpPUiAkTUlOT1IK

--===============6369934646102767628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6369934646102767628==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 14:08:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqNp-0006lc-J3; Tue, 21 Feb 2012 14:07:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RzqNn-0006kI-A3
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 14:07:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329833266!12454364!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_06_12,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24286 invoked from network); 21 Feb 2012 14:07:46 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:07:46 -0000
Received: by werh12 with SMTP id h12so5072608wer.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 06:07:46 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.109.225 as permitted sender) client-ip=10.180.109.225; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.109.225 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.109.225])
	by 10.180.109.225 with SMTP id hv1mr27070547wib.6.1329833266234
	(num_hops = 1); Tue, 21 Feb 2012 06:07:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:subject:x-mercurial-node
	:message-id:user-agent:date:from:to:cc;
	bh=wh0jcBaEIZ/Y8GnmUHxrdOw5alx3kQylyQ2eJ9LLOR4=;
	b=HFJDjccFnMB2lIIBSBtKGewwNo4JohsTcc4stbeGAACthDy2DzbNWyaWjbLqlcJp+n
	EEQgoXpF4dDiPeHnXS306OXyF3WCy/DnPtOZvAOtyPHLR5Fm1k/O3xTgnxVYyj/x2S7v
	KptvQqLgpct7Wpg62SGKJv/gMvuz3jbfOJSi8=
Received: by 10.180.109.225 with SMTP id hv1mr22630538wib.6.1329833266146;
	Tue, 21 Feb 2012 06:07:46 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gf3sm21248143wib.6.2012.02.21.06.07.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 21 Feb 2012 06:07:45 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============6369934646102767628=="
MIME-Version: 1.0
X-Mercurial-Node: c2f0820e48ae9cf0735c5ef81e6a6796f3d42e5a
Message-Id: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 04:19:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH v8] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6369934646102767628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.

conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.

config.h is only used by libxl/xl to detect yajl_version.h.

Changes since v7:

 * Fixed bug that prevented the creation of "dist" directory (Ian
   Campbell).

Changes since v6:

 * Readded autogen.sh.

Changes since v5:

 * Remove dummy configure generation from autogen.sh since it's
   already on the source tree.

 * Removed autogen.sh since it was only a wrapper for calling
   autoconf.

 * Remove comment regarding yajl_version.h from configure.ac.

Changes since v4:

 * Updated to tip.

 * Include config.h from compiler command line when building libxl and
   xl to assure yajl_version.h presence and correctly detect yajl
   version.

 * Added glib-2.0 check with appropiate m4 macros.

 * Purged config.h.in from unnecessary defines that could mess with
   the build system.

 * Removed tools/config.sub, tools/config.guess, tools/configure and
   configure to make the patch fit mailing list limit.

Changes since v3:

 * Copied config.guess and config.sub from automake 1.11.

 * Added a test to check for uuid.h on BSD and uuid/uuid.h on Linux.

Changes since v2:

 * Changed order of config/Tools.mk include.

 * Added "-e" to autogen.sh shebang.

 * Added necessary files (config.*) and output from Autoheader and
   Autoconf.

 * Removed Autoconf from build dependencies and updated README.

Changes since v1:

 * Moved autoconf stuff inside tools folder.

 * Add Makefile rules for cleaning.

 * Removed Automake dependency.

 * Create autogen.sh to automatically create configure script when
   building from source repository.

 * Cached values of options passed from command line.

 * Add necessary ignores to .hgignore.

 * Added Autoconf to the list of dependencies.

 * Changed hypen to underscore in XML2 and CURL variable names.

 * Added script to get version from xen/Makefile.

 * Set Ocaml tools to optional.

 * Added procedence of m4/ocaml.m4.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>


 .hgignore                         |    6 +
 Config.mk                         |   39 ------
 Makefile                          |    3 +-
 README                            |    4 +
 autogen.sh                        |    3 +
 config/Tools.mk.in                |   50 +++++++
 configure                         |    2 +
 tools/Makefile                    |    3 +-
 tools/Rules.mk                    |    7 +-
 tools/blktap/drivers/Makefile     |    2 +-
 tools/blktap/drivers/check_gcrypt |   14 --
 tools/check/Makefile              |   26 ----
 tools/check/README                |   20 ---
 tools/check/check_brctl           |   13 --
 tools/check/check_crypto_lib      |   11 -
 tools/check/check_curl            |   13 --
 tools/check/check_iproute         |   15 --
 tools/check/check_libaio_devel    |   11 -
 tools/check/check_libaio_lib      |    9 -
 tools/check/check_openssl_devel   |    6 -
 tools/check/check_python          |   13 --
 tools/check/check_python_devel    |   17 --
 tools/check/check_python_xml      |   12 -
 tools/check/check_udev            |   22 ---
 tools/check/check_uuid_devel      |    7 -
 tools/check/check_x11_devel       |    9 -
 tools/check/check_xgettext        |    6 -
 tools/check/check_xml2            |   14 --
 tools/check/check_yajl_devel      |    8 -
 tools/check/check_zlib_devel      |    6 -
 tools/check/check_zlib_lib        |   12 -
 tools/check/chk                   |   63 ---------
 tools/check/funcs.sh              |  106 ----------------
 tools/config.h.in                 |   16 ++
 tools/configure.ac                |  192 ++++++++++++++++++++++++++++++
 tools/debugger/gdbsx/xg/Makefile  |    1 -
 tools/install.sh                  |    1 +
 tools/libfsimage/Makefile         |    6 +-
 tools/libfsimage/check-libext2fs  |   21 ---
 tools/libxen/Makefile             |    8 +-
 tools/libxl/Makefile              |    7 +-
 tools/libxl/libxl_json.h          |    2 +-
 tools/m4/default_lib.m4           |    8 +
 tools/m4/disable_feature.m4       |   13 ++
 tools/m4/enable_feature.m4        |   13 ++
 tools/m4/ocaml.m4                 |  241 ++++++++++++++++++++++++++++++++++++++
 tools/m4/path_or_fail.m4          |    6 +
 tools/m4/pkg.m4                   |  157 ++++++++++++++++++++++++
 tools/m4/python_devel.m4          |   18 ++
 tools/m4/python_version.m4        |   12 +
 tools/m4/python_xml.m4            |   10 +
 tools/m4/set_cflags_ldflags.m4    |   20 +++
 tools/m4/udev.m4                  |   32 +++++
 tools/m4/uuid.m4                  |   10 +
 version.sh                        |    5 +
 55 files changed, 840 insertions(+), 511 deletions(-)



--===============6369934646102767628==
Content-Type: text/x-patch; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xen-autoconf.patch

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI5Nzk0MzA5IC0zNjAwCiMgTm9kZSBJRCBjMmYwODIwZTQ4
YWU5Y2YwNzM1YzVlZjgxZTZhNjc5NmYzZDQyZTVhCiMgUGFyZW50ICBjYTgwZWNhOWNmYTM5ZDFi
NjBkMTIxNjk0OGRhYzU3MTFkNTUwYjgzCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwgY29uZmlnL1Rvb2xzLm1rCmFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5jbHVk
ZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25zIHBy
ZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcK
cGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVjdXRp
bmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIG9ubHkgdXNlZCBieSBsaWJ4bC94bCB0
byBkZXRlY3QgeWFqbF92ZXJzaW9uLmguCgpDaGFuZ2VzIHNpbmNlIHY3OgoKICogRml4ZWQgYnVn
IHRoYXQgcHJldmVudGVkIHRoZSBjcmVhdGlvbiBvZiAiZGlzdCIgZGlyZWN0b3J5IChJYW4KICAg
Q2FtcGJlbGwpLgoKQ2hhbmdlcyBzaW5jZSB2NjoKCiAqIFJlYWRkZWQgYXV0b2dlbi5zaC4KCkNo
YW5nZXMgc2luY2UgdjU6CgogKiBSZW1vdmUgZHVtbXkgY29uZmlndXJlIGdlbmVyYXRpb24gZnJv
bSBhdXRvZ2VuLnNoIHNpbmNlIGl0J3MKICAgYWxyZWFkeSBvbiB0aGUgc291cmNlIHRyZWUuCgog
KiBSZW1vdmVkIGF1dG9nZW4uc2ggc2luY2UgaXQgd2FzIG9ubHkgYSB3cmFwcGVyIGZvciBjYWxs
aW5nCiAgIGF1dG9jb25mLgoKICogUmVtb3ZlIGNvbW1lbnQgcmVnYXJkaW5nIHlhamxfdmVyc2lv
bi5oIGZyb20gY29uZmlndXJlLmFjLgoKQ2hhbmdlcyBzaW5jZSB2NDoKCiAqIFVwZGF0ZWQgdG8g
dGlwLgoKICogSW5jbHVkZSBjb25maWcuaCBmcm9tIGNvbXBpbGVyIGNvbW1hbmQgbGluZSB3aGVu
IGJ1aWxkaW5nIGxpYnhsIGFuZAogICB4bCB0byBhc3N1cmUgeWFqbF92ZXJzaW9uLmggcHJlc2Vu
Y2UgYW5kIGNvcnJlY3RseSBkZXRlY3QgeWFqbAogICB2ZXJzaW9uLgoKICogQWRkZWQgZ2xpYi0y
LjAgY2hlY2sgd2l0aCBhcHByb3BpYXRlIG00IG1hY3Jvcy4KCiAqIFB1cmdlZCBjb25maWcuaC5p
biBmcm9tIHVubmVjZXNzYXJ5IGRlZmluZXMgdGhhdCBjb3VsZCBtZXNzIHdpdGgKICAgdGhlIGJ1
aWxkIHN5c3RlbS4KCiAqIFJlbW92ZWQgdG9vbHMvY29uZmlnLnN1YiwgdG9vbHMvY29uZmlnLmd1
ZXNzLCB0b29scy9jb25maWd1cmUgYW5kCiAgIGNvbmZpZ3VyZSB0byBtYWtlIHRoZSBwYXRjaCBm
aXQgbWFpbGluZyBsaXN0IGxpbWl0LgoKQ2hhbmdlcyBzaW5jZSB2MzoKCiAqIENvcGllZCBjb25m
aWcuZ3Vlc3MgYW5kIGNvbmZpZy5zdWIgZnJvbSBhdXRvbWFrZSAxLjExLgoKICogQWRkZWQgYSB0
ZXN0IHRvIGNoZWNrIGZvciB1dWlkLmggb24gQlNEIGFuZCB1dWlkL3V1aWQuaCBvbiBMaW51eC4K
CkNoYW5nZXMgc2luY2UgdjI6CgogKiBDaGFuZ2VkIG9yZGVyIG9mIGNvbmZpZy9Ub29scy5tayBp
bmNsdWRlLgoKICogQWRkZWQgIi1lIiB0byBhdXRvZ2VuLnNoIHNoZWJhbmcuCgogKiBBZGRlZCBu
ZWNlc3NhcnkgZmlsZXMgKGNvbmZpZy4qKSBhbmQgb3V0cHV0IGZyb20gQXV0b2hlYWRlciBhbmQK
ICAgQXV0b2NvbmYuCgogKiBSZW1vdmVkIEF1dG9jb25mIGZyb20gYnVpbGQgZGVwZW5kZW5jaWVz
IGFuZCB1cGRhdGVkIFJFQURNRS4KCkNoYW5nZXMgc2luY2UgdjE6CgogKiBNb3ZlZCBhdXRvY29u
ZiBzdHVmZiBpbnNpZGUgdG9vbHMgZm9sZGVyLgoKICogQWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBj
bGVhbmluZy4KCiAqIFJlbW92ZWQgQXV0b21ha2UgZGVwZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRv
Z2VuLnNoIHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGNvbmZpZ3VyZSBzY3JpcHQgd2hlbgogICBi
dWlsZGluZyBmcm9tIHNvdXJjZSByZXBvc2l0b3J5LgoKICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRp
b25zIHBhc3NlZCBmcm9tIGNvbW1hbmQgbGluZS4KCiAqIEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0
byAuaGdpZ25vcmUuCgogKiBBZGRlZCBBdXRvY29uZiB0byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNp
ZXMuCgogKiBDaGFuZ2VkIGh5cGVuIHRvIHVuZGVyc2NvcmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJp
YWJsZSBuYW1lcy4KCiAqIEFkZGVkIHNjcmlwdCB0byBnZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtl
ZmlsZS4KCiAqIFNldCBPY2FtbCB0b29scyB0byBvcHRpb25hbC4KCiAqIEFkZGVkIHByb2NlZGVu
Y2Ugb2YgbTQvb2NhbWwubTQuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2Vy
LnBhdUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFl
IC5oZ2lnbm9yZQotLS0gYS8uaGdpZ25vcmUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAw
CisrKyBiLy5oZ2lnbm9yZQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTMwMyw2
ICszMDMsMTIgQEAKIF50b29scy9vY2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbCQKIF50b29scy9v
Y2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbGkkCiBedG9vbHMvb2NhbWwveGVuc3RvcmVkL294ZW5z
dG9yZWQkCitedG9vbHMvYXV0b200dGVcLmNhY2hlJAorXnRvb2xzL2NvbmZpZ1wuaCQKK150b29s
cy9jb25maWdcLmxvZyQKK150b29scy9jb25maWdcLnN0YXR1cyQKK150b29scy9jb25maWdcLmNh
Y2hlJAorXmNvbmZpZy9Ub29sc1wubWskCiBeeGVuL1wuYmFubmVyLiokCiBeeGVuL0JMT0ckCiBe
eGVuL1N5c3RlbS5tYXAkCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSBDb25m
aWcubWsKLS0tIGEvQ29uZmlnLm1rCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysg
Yi9Db25maWcubWsJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC03MCw5ICs3MCw2
IEBAIEVYVFJBX0lOQ0xVREVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiAr
PSAkKEVYVFJBX1BSRUZJWCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24K
LUZMRVgJPz0gZmxleAotCiBQWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJH
ID89IC0tcHJlZml4PSIkKFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJ
WCBjb250YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCkBAIC0xNzUsMzIg
KzE3Miw5IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVO
RF9MREZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRf
Q0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hF
Q0tfTElCID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNL
X0lOQ0xVREVTID0gJChFWFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVO
RF9JTkNMVURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNr
LXByb3RlY3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFH
UyArPSAtZm5vLWV4Y2VwdGlvbnMKIAotQ09ORklHX0xJQklDT05WICAgOj0gJChzaGVsbCBleHBv
cnQgT1M9ImB1bmFtZSAtc2AiOyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGV4cG9ydCBDSEVD
S19MSUI9IiQoQ0hFQ0tfTElCKSI7IFwKLSAgICAgICAgICAgICAgICAgICAgICAgLiAkKFhFTl9S
T09UKS90b29scy9jaGVjay9mdW5jcy5zaDsgXAotICAgICAgICAgICAgICAgICAgICAgICBoYXNf
bGliIGxpYmljb252LnNvICYmIGVjaG8gJ3knIHx8IGVjaG8gJ24nKQotCi1DT05GSUdfWUFKTF9W
RVJTSU9OIDo9ICQoc2hlbGwgZXhwb3J0IE9TPSJgdW5hbWUgLXNgIjsgXAotICAgICAgICAgICAg
ICAgICAgICAgICBleHBvcnQgQ0hFQ0tfSU5DTFVERVM9IiQoQ0hFQ0tfSU5DTFVERVMpIjsgXAot
ICAgICAgICAgICAgICAgICAgICAgICAuICQoWEVOX1JPT1QpL3Rvb2xzL2NoZWNrL2Z1bmNzLnNo
OyBcCi0gICAgICAgICAgICAgICAgICAgICAgIGhhc19oZWFkZXIgeWFqbC95YWpsX3ZlcnNpb24u
aCAmJiBlY2hvICd5JyB8fCBlY2hvICduJykKLQotIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVs
ZSAoYnkgZGVmYXVsdCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1GTEFTS19FTkFCTEUgPz0g
JChYU01fRU5BQkxFKQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3Ig
R0lUJ3Mgb3duIHByb3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUg
cm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0jIG1heSBibG9jayBpdCku
IFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25s
b2FkcwotIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBl
bnZpcm9ubWVudC4KLUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVTX1VSTD1odHRwOi8veGVu
Yml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhlIGZpbGVzIGF0IHRoYXQg
bG9jYXRpb24gd2VyZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9uCiAjIHRoZSBpbnRlcm5l
dC4gIFRoZSBvcmlnaW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVkIGFzIGEgY29tbWVudApA
QCAtMjM5LDE3ICsyMTMsNCBAQCBRRU1VX1RBRyA/PSAxMjhkZTI1NDljNWYyNGU0YTQzN2I4NmJk
MmU0CiAjIFNob3J0IGFuc3dlciAtLSBkbyBub3QgZW5hYmxlIHRoaXMgdW5sZXNzIHlvdSBrbm93
IHdoYXQgeW91IGFyZQogIyBkb2luZyBhbmQgYXJlIHByZXBhcmVkIGZvciBzb21lIHBhaW4uCiAK
LSMgT3B0aW9uYWwgY29tcG9uZW50cwotWEVOU1RBVF9YRU5UT1AgICAgID89IHkKLVZUUE1fVE9P
TFMgICAgICAgICA/PSBuCi1MSUJYRU5BUElfQklORElOR1MgPz0gbgotUFlUSE9OX1RPT0xTICAg
ICAgID89IHkKLU9DQU1MX1RPT0xTICAgICAgICA/PSB5Ci1DT05GSUdfTUlOSVRFUk0gICAgPz0g
bgotQ09ORklHX0xPTU9VTlQgICAgID89IG4KLUNPTkZJR19TWVNURU1fTElCQUlPID89IHkKIENP
TkZJR19URVNUUyAgICAgICA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9PTFMpLHkpCi1PQ0FNTF9U
T09MUyA6PSAkKHNoZWxsIG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyAieSIg
fHwgZWNobyAibiIpCi1lbmRpZgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUg
TWFrZWZpbGUKLS0tIGEvTWFrZWZpbGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisr
KyBiL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtNDAsMTEgKzQw
LDEwIEBAIGRpc3Q6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0OiBkaXN0LXhlbiBk
aXN0LWtlcm5lbHMgZGlzdC10b29scyBkaXN0LXN0dWJkb20gZGlzdC1kb2NzIGRpc3QtbWlzYwog
CiBkaXN0LW1pc2M6Ci0JJChJTlNUQUxMX0RJUikgJChESVNURElSKS9jaGVjaworCSQoSU5TVEFM
TF9ESVIpICQoRElTVERJUikvCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09QWUlORyAkKERJU1RESVIp
CiAJJChJTlNUQUxMX0RBVEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkkKElOU1RBTExfUFJPRykg
Li9pbnN0YWxsLnNoICQoRElTVERJUikKLQkkKElOU1RBTExfUFJPRykgdG9vbHMvY2hlY2svY2hr
IHRvb2xzL2NoZWNrL2NoZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2ggJChESVNURElSKS9jaGVj
awogZGlzdC0lOiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdC0lOiBpbnN0YWxsLSUK
IAlAOiAjIGRvIG5vdGhpbmcKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIFJF
QURNRQotLS0gYS9SRUFETUUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL1JF
QURNRQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTg5LDkgKzg5LDEzIEBAIDIu
IGNkIHRvIHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKIDMuIEZvciB0aGUgdmVyeSBm
aXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWlsZCB0cmVlcywKICAgIHBl
cmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwczoKIAorICAgICMgLi9jb25maWd1cmUKICAgICAjIG1h
a2Ugd29ybGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ugd2FudCwgeW91IGNhbiBy
dW4gLi9jb25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgorICAgb3B0aW9ucyBhdmFp
bGFibGUgb3B0aW9ucyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5nIFhlbi4KKwogICAgVGhp
cyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBtYWNoaW5lLiBJdCB3aWxs
IGJ1aWxkCiAgICB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRvb2xzIGFuZCB0aGUgZG9j
dW1lbnRhdGlvbi4KIApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgYXV0b2dl
bi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9h
dXRvZ2VuLnNoCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDMgQEAK
KyMhL2Jpbi9zaCAtZQorY2QgdG9vbHMKK2F1dG9jb25mCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGMyZjA4MjBlNDhhZSBjb25maWcvVG9vbHMubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvY29uZmlnL1Rvb2xzLm1rLmluCVR1ZSBGZWIgMjEg
MDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDUwIEBACisjIFByZWZpeCBhbmQgaW5zdGFs
bCBmb2xkZXIKK1BSRUZJWCAgICAgICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJfeDg2
XzY0ICAgOj0gQExJQl9QQVRIQAorCisjIEEgZGVidWcgYnVpbGQgb2YgdG9vbHM/CitkZWJ1ZyAg
ICAgICAgICAgICAgIDo9IEBkZWJ1Z0AKKworIyBUb29scyBwYXRoCitCSVNPTiAgICAgICAgICAg
ICAgIDo9IEBCSVNPTkAKK0ZMRVggICAgICAgICAgICAgICAgOj0gQEZMRVhACitQWVRIT04gICAg
ICAgICAgICAgIDo9IEBQWVRIT05ACitQWVRIT05fUEFUSCAgICAgICAgIDo9IEBQWVRIT05QQVRI
QAorUEVSTCAgICAgICAgICAgICAgICA6PSBAUEVSTEAKK0JSQ1RMICAgICAgICAgICAgICAgOj0g
QEJSQ1RMQAorSVAgICAgICAgICAgICAgICAgICA6PSBASVBACitDVVJMX0NPTkZJRyAgICAgICAg
IDo9IEBDVVJMQAorWE1MMl9DT05GSUcgICAgICAgICA6PSBAWE1MQAorQkFTSCAgICAgICAgICAg
ICAgICA6PSBAQkFTSEAKK1hHRVRUVEVYVCAgICAgICAgICAgOj0gQFhHRVRURVhUQAorCisjIEV4
dHJhIGZvbGRlciBmb3IgbGlicy9pbmNsdWRlcworUFJFUEVORF9JTkNMVURFUyAgICA6PSBAUFJF
UEVORF9JTkNMVURFU0AKK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElCQAorQVBQ
RU5EX0lOQ0xVREVTICAgICA6PSBAQVBQRU5EX0lOQ0xVREVTQAorQVBQRU5EX0xJQiAgICAgICAg
ICA6PSBAQVBQRU5EX0xJQkAKKworIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVm
YXVsdCwgRmxhc2spLgorWFNNX0VOQUJMRSAgICAgICAgICA6PSBAeHNtQAorRkxBU0tfRU5BQkxF
ICAgICAgICA6PSBAeHNtQAorCisjIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAg
b3IgR0lUJ3Mgb3duIHByb3RvY29sPworIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1v
cmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCisjIG1heSBibG9jayBp
dCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRv
d25sb2FkcworIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91
ciBlbnZpcm9ubWVudC4KK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBACisKKyMgT3B0
aW9uYWwgY29tcG9uZW50cworWEVOU1RBVF9YRU5UT1AgICAgICA6PSBAbW9uaXRvcnNACitWVFBN
X1RPT0xTICAgICAgICAgIDo9IEB2dHBtQAorTElCWEVOQVBJX0JJTkRJTkdTICA6PSBAeGFwaUAK
K1BZVEhPTl9UT09MUyAgICAgICAgOj0gQHB5dGhvbnRvb2xzQAorT0NBTUxfVE9PTFMgICAgICAg
ICA6PSBAb2NhbWx0b29sc0AKK0NPTkZJR19NSU5JVEVSTSAgICAgOj0gQG1pbml0ZXJtQAorQ09O
RklHX0xPTU9VTlQgICAgICA6PSBAbG9tb3VudEAKKworI1N5c3RlbSBvcHRpb25zCitDT05GSUdf
U1lTVEVNX0xJQkFJTzo9IEBzeXN0ZW1fYWlvQAorQ09ORklHX0xJQklDT05WICAgICA6PSBAbGli
aWNvbnZACitDT05GSUdfR0NSWVBUICAgICAgIDo9IEBsaWJnY3J5cHRACitDT05GSUdfRVhUMkZT
ICAgICAgIDo9IEBsaWJleHQyZnNACmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhh
ZSBjb25maWd1cmUKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
KysrIGIvY29uZmlndXJlCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsx
LDIgQEAKKyMhL2Jpbi9zaCAtZQorY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgJEAKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL01h
a2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9NYWtlZmls
ZQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTYsNyArNiw2IEBAIFNVQkRJUlMt
bGliYWlvIDo9IGxpYmFpbwogZW5kaWYKIAogU1VCRElSUy15IDo9Ci1TVUJESVJTLXkgKz0gY2hl
Y2sKIFNVQkRJUlMteSArPSBpbmNsdWRlCiBTVUJESVJTLXkgKz0gbGlieGMKIFNVQkRJUlMteSAr
PSBmbGFzawpAQCAtNzksNiArNzgsOCBAQCBjbGVhbjogc3ViZGlycy1jbGVhbgogZGlzdGNsZWFu
OiBzdWJkaXJzLWRpc3RjbGVhbgogCXJtIC1yZiBxZW11LXhlbi10cmFkaXRpb25hbC1kaXIgcWVt
dS14ZW4tdHJhZGl0aW9uYWwtZGlyLXJlbW90ZQogCXJtIC1yZiBxZW11LXhlbi1kaXIgcWVtdS14
ZW4tZGlyLXJlbW90ZQorCXJtIC1yZiAuLi9jb25maWcvVG9vbHMubWsgY29uZmlnLmggY29uZmln
LmxvZyBjb25maWcuc3RhdHVzIFwKKwkJY29uZmlnLmNhY2hlIGF1dG9tNHRlLmNhY2hlCiAKIGlm
bmVxICgkKFhFTl9DT01QSUxFX0FSQ0gpLCQoWEVOX1RBUkdFVF9BUkNIKSkKIElPRU1VX0NPTkZJ
R1VSRV9DUk9TUyA/PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXApkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvUnVsZXMubWsKLS0tIGEvdG9vbHMvUnVsZXMubWsJ
TW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL1J1bGVzLm1rCVR1ZSBG
ZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtNCw2ICs0LDcgQEAKIGFsbDoKIAogaW5jbHVk
ZSAkKFhFTl9ST09UKS9Db25maWcubWsKK2luY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xz
Lm1rCiAKIGV4cG9ydCBfSU5TVEFMTCA6PSAkKElOU1RBTEwpCiBJTlNUQUxMID0gJChYRU5fUk9P
VCkvdG9vbHMvY3Jvc3MtaW5zdGFsbApAQCAtODAsOCArODEsNiBAQCBjaGVjay0kKENPTkZJR19Y
ODYpID0gJChjYWxsIGNjLXZlci1jaGVjCiAgICAgICAgICAgICAgICAgICAgICAgICAiWGVuIHJl
cXVpcmVzIGF0IGxlYXN0IGdjYy0zLjQiKQogJChldmFsICQoY2hlY2steSkpCiAKLV9QWVRIT05f
UEFUSCA6PSAkKHNoZWxsIHdoaWNoICQoUFlUSE9OKSkKLVBZVEhPTl9QQVRIID89ICQoX1BZVEhP
Tl9QQVRIKQogSU5TVEFMTF9QWVRIT05fUFJPRyA9IFwKIAkkKFhFTl9ST09UKS90b29scy9weXRo
b24vaW5zdGFsbC13cmFwICIkKFBZVEhPTl9QQVRIKSIgJChJTlNUQUxMX1BST0cpCiAKQEAgLTEw
OSwzICsxMDgsNyBAQCBzdWJkaXItYWxsLSUgc3ViZGlyLWNsZWFuLSUgc3ViZGlyLWluc3RhCiAK
IHN1YmRpci1kaXN0Y2xlYW4tJTogLnBob255CiAJJChNQUtFKSAtQyAkKiBjbGVhbgorCiskKFhF
Tl9ST09UKS9jb25maWcvVG9vbHMubWs6CisJQGVjaG8gIllvdSBoYXZlIHRvIHJ1biAuL2NvbmZp
Z3VyZSBiZWZvcmUgYnVpbGRpbmcgb3IgaW5zdGFsbGluZyB0aGUgdG9vbHMiCisJQGV4aXQgMQpk
aWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvYmxrdGFwL2RyaXZlcnMv
TWFrZWZpbGUKLS0tIGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVR1
ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMTMsNyArMTMsNyBAQCBDRkxBR1MgICAr
PSAkKENGTEFHU19saWJ4ZW5zdG9yZSkKIENGTEFHUyAgICs9IC1JICQoTUVNU0hSX0RJUikKIENG
TEFHUyAgICs9IC1EX0dOVV9TT1VSQ0UKIAotaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0
ICQoQ0MpKSx5ZXMpCitpZmVxICgkQ09ORklHX0dDUllQVCx5KQogQ0ZMQUdTICs9IC1EVVNFX0dD
UllQVAogQ1JZUFRfTElCIDo9IC1sZ2NyeXB0CiBlbHNlCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGMyZjA4MjBlNDhhZSB0b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQKLS0tIGEvdG9v
bHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0CU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiAr
MDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwx
NCArMCwwIEBACi0jIS9iaW4vc2gKLQotY2F0ID4gLmdjcnlwdC5jIDw8IEVPRgotI2luY2x1ZGUg
PGdjcnlwdC5oPgotaW50IG1haW4odm9pZCkgeyByZXR1cm4gMDsgfQotRU9GCi0KLWlmICQxIC1v
IC5nY3J5cHQgLmdjcnlwdC5jIC1sZ2NyeXB0IDI+L2Rldi9udWxsIDsgdGhlbgotICBlY2hvICJ5
ZXMiCi1lbHNlCi0gIGVjaG8gIm5vIgotZmkKLQotcm0gLWYgLmdjcnlwdCoKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL01ha2VmaWxlCi0tLSBhL3Rvb2xz
L2NoZWNrL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyNiArMCwwIEBACi1YRU5f
Uk9PVCA9ICQoQ1VSRElSKS8uLi8uLgotaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5t
awotCi0jIEV4cG9ydCB0aGUgbmVjZXNzYXJ5IGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgdGhl
IHRlc3RzCi1leHBvcnQgUFlUSE9OCi1leHBvcnQgTElCWEVOQVBJX0JJTkRJTkdTCi1leHBvcnQg
Q0hFQ0tfSU5DTFVERVMKLWV4cG9ydCBDSEVDS19MSUIKLWV4cG9ydCBDT05GSUdfU1lTVEVNX0xJ
QkFJTwotCi0uUEhPTlk6IGFsbCBpbnN0YWxsCi1hbGwgaW5zdGFsbDogY2hlY2stYnVpbGQKLQot
IyBDaGVjayB0aGlzIG1hY2hpbmUgaXMgT0sgZm9yIGJ1aWxkaW5nIG9uLgotLlBIT05ZOiBjaGVj
ay1idWlsZAotY2hlY2stYnVpbGQ6Ci0JLi9jaGsgYnVpbGQKLQotIyBDaGVjayB0aGlzIG1hY2hp
bmUgaXMgT0sgZm9yIGluc3RhbGxpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWluc3RhbGwKLWNoZWNr
LWluc3RhbGw6Ci0JLi9jaGsgaW5zdGFsbAotCi0uUEhPTlk6IGNsZWFuCi1jbGVhbjoKLQkuL2No
ayBjbGVhbgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvY2hlY2sv
UkVBRE1FCi0tLSBhL3Rvb2xzL2NoZWNrL1JFQURNRQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIg
KzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEs
MjAgKzAsMCBAQAotQ2hlY2tzIGZvciB0aGUgc3VpdGFiaWxpdHkgb2YgYSBtYWNoaW5lIGZvciBY
ZW4gYnVpbGQgb3IgaW5zdGFsbC4KLVRvIGNoZWNrIGZvciBidWlsZCBzdWl0YWJpbGl0eSB1c2UK
LQotICAgICAgICAuL2NoayBidWlsZAotCi1UbyBjaGVjayBmb3IgaW5zdGFsbCBzdWl0YWJpbGl0
eSB1c2UKLQotICAgICAgICAuL2NoayBpbnN0YWxsCi0KLVRoZSBjaGsgc2NyaXB0IHdpbGwgcnVu
IGNoZWNrcyBpbiB0aGlzIGRpcmVjdG9yeSBhbmQgcHJpbnQKLXRoZSBvbmVzIHRoYXQgZmFpbGVk
LiBJdCBwcmludHMgbm90aGluZyBpZiBjaGVja3Mgc3VjY2VlZC4KLVRoZSBjaGsgc2NyaXB0IGV4
aXRzIHdpdGggMCBvbiBzdWNjZXNzIGFuZCAxIG9uIGZhaWx1cmUuCi0KLVRoZSBjaGsgc2NyaXB0
IHJ1bnMgZXhlY3V0YWJsZSBmaWxlcyBpbiB0aGlzIGRpcmVjdG9yeSB3aG9zZQotbmFtZXMgYmVn
aW4gd2l0aCAnY2hlY2tfJy4gRmlsZXMgY29udGFpbmluZyBDSEVDSy1CVUlMRAotYXJlIHJ1biBm
b3IgdGhlIGJ1aWxkIGNoZWNrLCBhbmQgZmlsZXMgY29udGFpbmluZyBDSEVDSy1JTlNUQUxMCi1h
cmUgcnVuIGZvciB0aGUgaW5zdGFsbCBjaGVjay4KLQotRGV0YWlsZWQgb3V0cHV0IGZyb20gdGhl
IGNoZWNrIHNjcmlwdHMgaXMgaW4gLmNoa2J1aWxkIGZvciBidWlsZAotYW5kIC5jaGtpbnN0YWxs
IGZvciBpbnN0YWxsLgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL2NoZWNrX2JyY3RsCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX2JyY3RsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0j
IS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4K
LU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgYnJjb25maWcgOzsKLUxpbnV4
KQotCWhhc19vcl9mYWlsIGJyY3RsIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2Fj
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19j
cnlwdG9fbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIJTW9uIEZlYiAyMCAx
ODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCkBAIC0xLDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1J
TlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRCU0R8T3Bl
bkJTRCkKLQlleGl0IDAgOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJjcnlwdG8uc28gfHwgZmFpbCAi
bWlzc2luZyBsaWJjcnlwdG8uc28iCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhh
ZSB0b29scy9jaGVjay9jaGVja19jdXJsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2N1cmwJTW9u
IEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDow
MDowMCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlM
RCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICIkTElCWEVOQVBJX0JJTkRJ
TkdTIiAhPSAieSIgXTsgdGhlbgotCWVjaG8gLW4gInVudXNlZCwgIgotCWV4aXQgMAotZmkKLQot
aGFzX29yX2ZhaWwgY3VybC1jb25maWcKLWN1cmxfbGlicz1gY3VybC1jb25maWcgLS1saWJzYCB8
fCBmYWlsICJjdXJsLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICRjdXJsX2xpYnMg
fHwgZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIGN1cmwgYXJlIG1pc3NpbmciCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19pcHJvdXRl
Ci0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEy
ICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0x
LDE1ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAot
Ci1QQVRIPS9zYmluOiRQQVRICi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNE
KQotCWhhc19vcl9mYWlsIGlmY29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBpcCA7Owot
KikKLQlmYWlsICJ1bmtub3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBj
MmYwODIwZTQ4YWUgdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX2xpYmFpb19kZXZlbAlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBA
QAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NP
TkZJR19TWVNURU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaWYg
ISBoYXNfaGVhZGVyIGxpYmFpby5oIDsgdGhlbgotICAgIGZhaWwgImNhbid0IGZpbmQgbGliYWlv
IGhlYWRlcnMsIGluc3RhbGwgbGliYWlvIGRldmVsIHBhY2thZ2Ugb3Igc2V0IENPTkZJR19TWVNU
RU1fTElCQUlPPW4iCi1maQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9v
bHMvY2hlY2svY2hlY2tfbGliYWlvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9f
bGliCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19T
WVNURU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaGFzX2xpYiBs
aWJhaW8uc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8iCmRpZmYgLXIgY2E4MGVjYTljZmEz
IC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCi0tLSBhL3Rv
b2xzL2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYg
KzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNf
aGVhZGVyIG9wZW5zc2wvbWQ1LmggfHwgZmFpbCAibWlzc2luZyBvcGVuc3NsIGhlYWRlcnMiCmRp
ZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja19weXRo
b24KLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAx
MiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0u
IC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhv
bgotZmkKLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBzeXMKLXN5cy5leGl0KHN5cy52ZXJzaW9u
X2luZm9bMF0gPCAyIG9yIHN5cy52ZXJzaW9uX2luZm9bMV0gPCAzKQotJyB8fCBmYWlsICJuZWVk
IHB5dGhvbiB2ZXJzaW9uID49IDIuMyIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0
OGFlIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVj
a19weXRob25fZGV2ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE3ICswLDAgQEAKLSMhL2Jp
bi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhP
Tn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0k
e1BZVEhPTn0gLWMgJwotaW1wb3J0IG9zLnBhdGgsIHN5cwotZm9yIHAgaW4gc3lzLnBhdGg6Ci0J
aWYgb3MucGF0aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6Ci0JCXN5cy5leGl0KDAp
Ci1zeXMuZXhpdCgxKQotJyB8fCBmYWlsICJjYW4ndCBmaW5kIHB5dGhvbiBkZXZlbCBmaWxlcyIK
ZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL2NoZWNrX3B5
dGhvbl94bWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAlNb24gRmViIDIwIDE4
OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKQEAgLTEsMTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAu
L2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24K
LWZpCi1oYXNfb3JfZmFpbCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICdpbXBvcnQgeG1sLmRv
bS5taW5pZG9tJyAyPi9kZXYvbnVsbCB8fCBcCi1mYWlsICJjYW4ndCBpbXBvcnQgeG1sLmRvbS5t
aW5pZG9tIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvY2hlY2sv
Y2hlY2tfdWRldgotLS0gYS90b29scy9jaGVjay9jaGVja191ZGV2CU1vbiBGZWIgMjAgMTg6MzQ6
MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwyMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVu
Y3Muc2gKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2Zh
aWwgdm5jb25maWcKLQk7OwotTGludXgpCi0JaGFzIC9zYmluL3VkZXZhZG0gJiYgXAotCQl1ZGV2
dmVyPWAvc2Jpbi91ZGV2YWRtIGluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbIC16ICIk
dWRldnZlciIgXSAmJiBoYXNfb3JfZmFpbCB1ZGV2aW5mbyAmJiBcCi0JCXVkZXZ2ZXI9YHVkZXZp
bmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0JWyAiJHVkZXZ2ZXIiIC1nZSA1OSBdIDI+L2Rl
di9udWxsIHx8IFwKLQkJaGFzIGhvdHBsdWcgfHwgXAotCQlmYWlsICJ1ZGV2IGlzIHRvbyBvbGQs
IHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlciIKLQk7OwotKikKLQlmYWlsICJ1bmtub3du
IE9TIgotCTs7Ci1lc2FjCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29s
cy9jaGVjay9jaGVja191dWlkX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2
ZWwJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNL
LUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHV1aWQuaCB8fCBcCi1oYXNfaGVh
ZGVyIHV1aWQvdXVpZC5oIHx8IGZhaWwgIm1pc3NpbmcgdXVpZCBoZWFkZXJzIChwYWNrYWdlIHV1
aWQtZGV2KSIKZGlmZiAtciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNr
L2NoZWNrX3gxMV9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwJTW9uIEZl
YiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIFgxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVh
ZGVyIC91c3IvWDExUjYvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAotaGFzX2hlYWRlciAv
dXNyL1gxMVI3L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLXdhcm5pbmcgImNhbid0IGZp
bmQgWDExIGhlYWRlcnMiCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29s
cy9jaGVjay9jaGVja194Z2V0dGV4dAotLS0gYS90b29scy9jaGVjay9jaGVja194Z2V0dGV4dAlN
b24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAw
OjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJ
TEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19vcl9mYWlsIHhnZXR0ZXh0CmRpZmYgLXIgY2E4MGVj
YTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja194bWwyCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX3htbDIJTW9uIEZlYiAyMCAxODozNDoxNCAyMDEyICswMDAwCisrKyAvZGV2
L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMh
L2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1p
ZiBbICEgIiRMSUJYRU5BUElfQklORElOR1MiID0gInkiIF0KLXRoZW4KLSAgICBlY2hvIC1uICJ1
bnVzZWQsICIKLSAgICBleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIHhtbDItY29uZmlnCi14bWwy
X2xpYnM9YHhtbDItY29uZmlnIC0tbGlic2AgfHwgZmFpbCAieG1sMi1jb25maWcgLS1saWJzIGZh
aWxlZCIKLXRlc3RfbGluayAkeG1sMl9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVz
IGZvciB4bWwyIGFyZSBtaXNzaW5nIgpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4
YWUgdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja195
YWpsX2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw4ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB5YWpsL3lhamxfcGFy
c2UuaCB8fCBmYWlsICJjYW4ndCBmaW5kIHlhamwveWFqbF9wYXJzZS5oIgotaGFzX2hlYWRlciB5
YWpsL3lhamxfZ2VuLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfZ2VuLmgiCi1oYXNf
bGliIGxpYnlhamwuc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJ5YWpsLnNvIgpkaWZmIC1yIGNh
ODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvY2hlY2svY2hlY2tfemxpYl9kZXZlbAot
LS0gYS90b29scy9jaGVjay9jaGVja196bGliX2RldmVsCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAx
MiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAt
MSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQot
aGFzX2hlYWRlciB6bGliLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB6bGliIGhlYWRlcnMiCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGVja196bGliX2xp
YgotLS0gYS90b29scy9jaGVjay9jaGVja196bGliX2xpYglNb24gRmViIDIwIDE4OjM0OjE0IDIw
MTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAg
LTEsMTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1GcmVlQlNEfE5ldEJTRHxPcGVuQlNEKQotCWV4
aXQgMAotCTs7Ci1lc2FjCi0KLWhhc19saWIgbGliei5zbyB8fCBmYWlsICJjYW4ndCBmaW5kIHps
aWIiCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jaGVjay9jaGsK
LS0tIGEvdG9vbHMvY2hlY2svY2hrCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw2MyArMCwwIEBA
Ci0jIS9iaW4vc2gKLQotZnVuY191c2FnZSAoKQotewotICAgIGVjaG8gIlVzYWdlOiIKLSAgICBl
Y2hvICIJJDAgW2J1aWxkfGluc3RhbGx8Y2xlYW5dIgotICAgIGVjaG8KLSAgICBlY2hvICJDaGVj
ayBzdWl0YWJpbGl0eSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuIgotICAgIGVjaG8gIkV4aXQg
d2l0aCAwIGlmIE9LLCAxIGlmIG5vdC4iCi0gICAgZWNobwotICAgIGVjaG8gIkNhbGxpbmcgd2l0
aCAnY2xlYW4nIHJlbW92ZXMgZ2VuZXJhdGVkIGZpbGVzLiIKLSAgICBleGl0IDEKLX0KLQotUEFU
SD0kUEFUSDovc2JpbjovdXNyL3NiaW4KLU9TPWB1bmFtZSAtc2AKLWV4cG9ydCBQQVRIIE9TCi0K
LWlmIFsgIiRPUyIgPSAiU3VuT1MiIF07IHRoZW4KLQlleGl0IDAKLWZpCi0KLWNhc2UgJDEgaW4K
LSAgICBidWlsZCkKLSAgICAgICAgY2hlY2s9IkNIRUNLLUJVSUxEIgotICAgICAgICA7OwotICAg
IGluc3RhbGwpCi0gICAgICAgIGNoZWNrPSJDSEVDSy1JTlNUQUxMIgotICAgICAgICA7OwotICAg
IGNsZWFuKQotICAgICAgICBleGl0IDAKLSAgICAgICAgOzsKLSAgICAqKQotICAgICAgICBmdW5j
X3VzYWdlCi0gICAgICAgIDs7Ci1lc2FjCi0KLWZhaWxlZD0wCi0KLWVjaG8gIlhlbiAke2NoZWNr
fSAiIGBkYXRlYAotZm9yIGYgaW4gY2hlY2tfKiA7IGRvCi0gICAgY2FzZSAkZiBpbgotICAgICAg
ICAqfikKLSAgICAgICAgICAgIGNvbnRpbnVlCi0gICAgICAgICAgICA7OwotICAgICAgICAqKQot
ICAgICAgICAgICAgOzsKLSAgICBlc2FjCi0gICAgaWYgISBbIC14ICRmIF0gOyB0aGVuCi0gICAg
ICAgIGNvbnRpbnVlCi0gICAgZmkKLSAgICBpZiAhIGdyZXAgLUZxICIkY2hlY2siICRmIDsgdGhl
bgotICAgICAgICBjb250aW51ZQotICAgIGZpCi0gICAgZWNobyAtbiAiQ2hlY2tpbmcgJGY6ICIK
LSAgICBpZiAuLyRmIDI+JjEgOyB0aGVuCi0gICAgICAgIGVjaG8gT0sKLSAgICBlbHNlCi0gICAg
ICAgIGZhaWxlZD0xCi0gICAgZmkKLWRvbmUKLQotZXhpdCAke2ZhaWxlZH0KZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NoZWNrL2Z1bmNzLnNoCi0tLSBhL3Rvb2xz
L2NoZWNrL2Z1bmNzLnNoCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMDYgKzAsMCBAQAotIyBo
YXMgaXMgdGhlIHNhbWUgYXMgd2hpY2gsIGV4Y2VwdCBpdCBoYW5kbGVzIGNyb3NzIGVudmlyb25t
ZW50cwotaGFzKCkgewotCWlmIFsgLXogIiRDUk9TU19DT01QSUxFIiBdOyB0aGVuCi0JCWNvbW1h
bmQgd2hpY2ggIiRAIgotCQlyZXR1cm4gJD8KLQlmaQotCi0JY2hlY2tfc3lzX3Jvb3QgfHwgcmV0
dXJuIDEKLQotCSMgc3Vic2hlbGwgdG8gcHJldmVudCBwb2xsdXRpb24gb2YgY2FsbGVyJ3MgSUZT
Ci0JKAotCUlGUz06Ci0JZm9yIHAgaW4gJFBBVEg7IGRvCi0JCWlmIFsgLXggIiRDUk9TU19TWVNf
Uk9PVC8kcC8kMSIgXTsgdGhlbgotCQkJZWNobyAiJENST1NTX1NZU19ST09ULyRwLyQxIgotCQkJ
cmV0dXJuIDAKLQkJZmkKLQlkb25lCi0JcmV0dXJuIDEKLQkpCi19Ci0KLWhhc19vcl9mYWlsKCkg
ewotCWhhcyAiJDEiID4vZGV2L251bGwgfHwgZmFpbCAiY2FuJ3QgZmluZCAkMSIKLX0KLQotaGFz
X2hlYWRlcigpIHsKLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JY2FzZSAkMSBpbgot
CQkvKikgOzsKLQkJKikKLQkJaWYgWyAtciAiJENST1NTX1NZU19ST09UL3Vzci9pbmNsdWRlLyQx
IiBdOyB0aGVuCi0JCQlyZXR1cm4gMAotCQlmaQotCQlmb3IgcGF0aCBpbiAke0NIRUNLX0lOQ0xV
REVTfTsgZG8KLQkJCWlmIFsgLXIgIiRDUk9TU19TWVNfUk9PVCR7cGF0aH0vJDEiIF07IHRoZW4K
LQkJCQlyZXR1cm4gMAotCQkJZmkKLQkJZG9uZQotCQk7OwotCWVzYWMKLQotCXJldHVybiAxCi19
Ci0KLWhhc19saWIoKSB7Ci0JY2hlY2tfc3lzX3Jvb3QgfHwgcmV0dXJuIDEKLQotCSMgc3Vic2hl
bGwgdG8gcHJldmVudCBwb2xsdXRpb24gb2YgY2FsbGVyJ3MgZW52aXJvbm1lbnQKLQkoCi0JUEFU
SD0vc2JpbjokUEFUSCAgICAgICAgIyBmb3IgbGRjb25maWcKLQlMSUJSQVJJRVM9IiRDSEVDS19M
SUIgL3Vzci9saWIiCi0KLQkjIFRoaXMgcmVsYXRpdmVseSBjb21tb24gaW4gYSBzeXMtcm9vdDsg
bGlicyBhcmUgaW5zdGFsbGVkIGJ1dAotCSMgbGRjb25maWcgaGFzbid0IHJ1biB0aGVyZSwgc28g
bGRjb25maWcgLXAgd29uJ3Qgd29yay4KLQlpZiBbICIkT1MiID0gTGludXggLWEgISAtZiAiJENS
T1NTX1NZU19ST09UL2V0Yy9sZC5zby5jYWNoZSIgXTsgdGhlbgotCSAgICBlY2hvICJQbGVhc2Ug
cnVuIGxkY29uZmlnIC1yIFwiJENST1NTX1NZU19ST09UXCIgdG8gZ2VuZXJhdGUgbGQuc28uY2Fj
aGUiCi0JICAgICMgZmFsbCB0aHJvdWdoOyBsZGNvbmZpZyB0ZXN0IGJlbG93IHNob3VsZCBmYWls
Ci0JZmkKLQlpZiBbICIke09TfSIgPSAiTGludXgiIF07IHRoZW4KLQkJbGRjb25maWcgLXAgJHtD
Uk9TU19TWVNfUk9PVCstciAiJENST1NTX1NZU19ST09UIn0gfCBncmVwIC1GcSAiJDEiCi0JCXJl
dHVybiAkPwotCWZpCi0JaWYgWyAiJHtPU30iID0gIk5ldEJTRCIgXTsgdGhlbgotCQlscyAtMSAk
e0xJQlJBUklFU30gfCBncmVwIC1GcSAiJDEiCi0JCXJldHVybiAkPwotCWZpCi0JcmV0dXJuIDEK
LQkpCi19Ci0KLXRlc3RfbGluaygpIHsKLQkjIHN1YnNoZWxsIHRvIHRyYXAgcmVtb3ZhbCBvZiB0
bXBmaWxlCi0JKAotCXVuc2V0IHRtcGZpbGUKLQl0cmFwICdybSAtZiAiJHRtcGZpbGUiOyBleGl0
JyAwIDEgMiAxNQotCXRtcGZpbGU9YG1rdGVtcGAgfHwgcmV0dXJuIDEKLQlsZCAiJEAiIC1vICIk
dG1wZmlsZSIgPi9kZXYvbnVsbCAyPiYxCi0JcmV0dXJuICQ/Ci0JKQotfQotCi0jIHRoaXMgZnVu
Y3Rpb24gaXMgdXNlZCBjb21tb25seSBhYm92ZQotY2hlY2tfc3lzX3Jvb3QoKSB7Ci0JWyAteiAi
JENST1NTX0NPTVBJTEUiIF0gJiYgcmV0dXJuIDAKLQlpZiBbIC16ICIkQ1JPU1NfU1lTX1JPT1Qi
IF07IHRoZW4KLQkJZWNobyAicGxlYXNlIHNldCBDUk9TU19TWVNfUk9PVCBpbiB0aGUgZW52aXJv
bm1lbnQiCi0JCXJldHVybiAxCi0JZmkKLQlpZiBbICEgLWQgIiRDUk9TU19TWVNfUk9PVCIgXTsg
dGhlbgotCQllY2hvICJubyBzeXMtcm9vdCBmb3VuZCBhdCAkQ1JPU1NfU1lTX1JPT1QiCi0JCXJl
dHVybiAxCi0JZmkKLX0KLQotd2FybmluZygpIHsKLQllY2hvCi0JZWNobyAiICoqKiBgYmFzZW5h
bWUgIiQwImAgRkFJTEVEJHsqKzogJCp9IgotfQotCi1mYWlsKCkgewotCWVjaG8KLQllY2hvICIg
KioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAkKn0iCi0JZXhpdCAxCi19CmRpZmYgLXIg
Y2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9jb25maWcuaC5pbgotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcuaC5p
bglUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxNiBAQAorLyoKKyAq
IENvcHlyaWdodCAoQykgMjAxMgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNo
ZWQKKyAqIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IHZlcnNpb24gMi4xIG9ubHku
IHdpdGggdGhlIHNwZWNpYWwKKyAqIGV4Y2VwdGlvbiBvbiBsaW5raW5nIGRlc2NyaWJlZCBpbiBm
aWxlIExJQ0VOU0UuCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBo
b3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7
IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZ
IG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIExl
c3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKi8KKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx5YWpsL3lhamxfdmVyc2lvbi5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1lBSkxfWUFKTF9WRVJTSU9OX0gKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2NvbmZpZ3VyZS5hYwotLS0gL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWd1cmUuYWMJVHVl
IEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTkyIEBACisjICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCisj
IFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0b2NvbmYgdG8gcHJvZHVjZSBhIGNvbmZpZ3VyZSBz
Y3JpcHQuCisKK0FDX1BSRVJFUShbMi42N10pCitBQ19JTklUKFtYZW4gSHlwZXJ2aXNvcl0sIG00
X2VzeXNjbWQoWy4uL3ZlcnNpb24uc2ggLi4veGVuL01ha2VmaWxlXSksCisgICAgW3hlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKK0FDX0NPTkZJR19TUkNESVIoW2xpYnhsL2xpYnhsLmNd
KQorQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMubWtdKQorQUNfQ09ORklHX0hFQURF
UlMoW2NvbmZpZy5oXSkKK0FDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkKK0FDX0NPTkZJR19BVVhf
RElSKFsuXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9y
IENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitBU19JRihbdGVzdCAtbiAiJENDJENG
TEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsKKyAgICBBQ19NU0dfV0FSTigKK1tT
ZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBub3Qg
XAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJQiwgXAorQVBQ
RU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS5dKQorXSkK
KworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCitBQ19DQU5PTklDQUxfSE9TVAorCisjIE00IE1h
Y3JvIGluY2x1ZGVzCittNF9pbmNsdWRlKFttNC9lbmFibGVfZmVhdHVyZS5tNF0pCittNF9pbmNs
dWRlKFttNC9kaXNhYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5jbHVkZShbbTQvcGF0aF9vcl9mYWls
Lm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0
aG9uX3ZlcnNpb24ubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX2RldmVsLm00XSkKK200X2lu
Y2x1ZGUoW200L3VkZXYubTRdKQorbTRfaW5jbHVkZShbbTQvb2NhbWwubTRdKQorbTRfaW5jbHVk
ZShbbTQvZGVmYXVsdF9saWIubTRdKQorbTRfaW5jbHVkZShbbTQvc2V0X2NmbGFnc19sZGZsYWdz
Lm00XSkKK200X2luY2x1ZGUoW200L3V1aWQubTRdKQorbTRfaW5jbHVkZShbbTQvcGtnLm00XSkK
KworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hz
bV0sCisgICAgW0VuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzayld
KQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtnaXRodHRwXSwgW0Rvd25sb2FkIEdJVCByZXBv
c2l0b3JpZXMgdmlhIEhUVFBdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbbW9uaXRvcnNd
LAorICAgIFtEaXNhYmxlIHhlbnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzXSkKK0FY
X0FSR19FTkFCTEVfQU5EX0VYUE9SVChbdnRwbV0sIFtFbmFibGUgVmlydHVhbCBUcnVzdGVkIFBs
YXRmb3JtIE1vZHVsZV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hhcGldLCBbRW5hYmxl
IFhlbiBBUEkgQmluZGluZ3NdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbcHl0aG9udG9v
bHNdLCBbRGlzYWJsZSBQeXRob24gdG9vbHNdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChb
b2NhbWx0b29sc10sIFtEaXNhYmxlIE9jYW1sIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VY
UE9SVChbbWluaXRlcm1dLCBbRW5hYmxlIG1pbml0ZXJtXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VY
UE9SVChbbG9tb3VudF0sIFtFbmFibGUgbG9tb3VudF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQ
T1JUKFtkZWJ1Z10sIFtEaXNhYmxlIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQgdG9vbHNdKQorCitB
Q19BUkdfVkFSKFtQUkVQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRl
cnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkKK0FDX0FSR19WQVIoW1BSRVBF
TkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZM
QUdTICh3aXRob3V0IC1MKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfSU5DTFVERVNdLAorICAgIFtM
aXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0p
CitBQ19BUkdfVkFSKFtBUFBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMg
dG8gYXBwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQgLUwpXSkKKworQVhfU0VUX0ZMQUdTCisKK0FD
X0FSR19WQVIoW1BZVEhPTl0sIFtQYXRoIHRvIHRoZSBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19W
QVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBhcnNlcl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQ
YXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJHX1ZBUihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkK
K0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGggdG8gQmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitB
Q19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8gRmxleCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRv
cl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1BhdGggdG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19B
UkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JB
U0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkKK0FDX0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGgg
dG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENoZWNrcyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NF
RAorQUNfUFJPR19DQworQUNfUFJPR19MTl9TCitBQ19QUk9HX01BS0VfU0VUCitBQ19QUk9HX0lO
U1RBTEwKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtQRVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtp
cF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQklTT05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9H
X09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitBU19JRihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBb
CisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0NVUkxdLCBbY3VybC1jb25maWddKQorICAgIEFY
X1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBbeG1sMi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0
ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsKKyAgICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYo
W3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWworICAgICAgICBBU19JRihbdGVzdCAieCRlbmFi
bGVfb2NhbWx0b29scyIgPSAieHllcyJdLCBbCisgICAgICAgICAgICBBQ19NU0dfRVJST1IoW09j
YW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmluZCBPY2FtbF0pXSkKKyAgICAgICAg
b2NhbWx0b29scz0ibiIKKyAgICBdKQorXSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCQVNIXSwg
W2Jhc2hdKQorQVNfSUYoW3Rlc3QgIngkcHl0aG9udG9vbHMiID0gInh5Il0sIFsKKyAgICBBU19J
RihbZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJeLyJdLCBbCisgICAgICAgIFBZVEhPTlBBVEg9
JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorICAgIF0sW3Rl
c3QgLXogIiRQWVRIT04iXSwgW1BZVEhPTj0icHl0aG9uIl0sCisgICAgW0FDX01TR19FUlJPUihb
UFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoXSldKQorICAgIEFY
X1BBVEhfUFJPR19PUl9GQUlMKFtQWVRIT05QQVRIXSwgWyRQWVRIT05dKQorICAgIEFYX0NIRUNL
X1BZVEhPTl9WRVJTSU9OKFsyXSwgWzNdKQorICAgIEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAg
IEFYX0NIRUNLX1BZVEhPTl9ERVZFTCgpCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRU
RVhUXSwgW3hnZXR0ZXh0XSkKK0FYX0NIRUNLX1VERVYoWzU5XSkKK0FYX0NIRUNLX1VVSUQKK1BL
R19DSEVDS19NT0RVTEVTKGdsaWIsIGdsaWItMi4wKQorCisjIENoZWNrIGxpYnJhcnkgcGF0aAor
QVhfREVGQVVMVF9MSUIKKworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK0FDX0NIRUNLX0xJQihb
YWlvXSwgW2lvX3NldHVwXSwgW3N5c3RlbV9haW89InkiXSwgW3N5c3RlbV9haW89Im4iXSkKK0FD
X1NVQlNUKHN5c3RlbV9haW8pCitBQ19DSEVDS19MSUIoW2NyeXB0b10sIFtNRDVdLCBbXSwgW0FD
X01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGliY3J5cHRvXSldKQorQUNfQ0hFQ0tfTElCKFtl
eHQyZnNdLCBbZXh0MmZzX29wZW4yXSwgW2xpYmV4dDJmcz0ieSJdLCBbbGliZXh0MmZzPSJuIl0p
CitBQ19TVUJTVChsaWJleHQyZnMpCitBQ19DSEVDS19MSUIoW2djcnlwdF0sIFtnY3J5X21kX2hh
c2hfYnVmZmVyXSwgW2xpYmdjcnlwdD0ieSJdLCBbbGliZ2NyeXB0PSJuIl0pCitBQ19TVUJTVChs
aWJnY3J5cHQpCitBQ19DSEVDS19MSUIoW3B0aHJlYWRdLCBbcHRocmVhZF9jcmVhdGVdLCBbXSAs
CisgICAgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgbGlicHRocmVhZF0pXSkKK0FDX0NI
RUNLX0xJQihbcnRdLCBbY2xvY2tfZ2V0dGltZV0pCitBQ19DSEVDS19MSUIoW3V1aWRdLCBbdXVp
ZF9jbGVhcl0sIFtdLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnV1aWRd
KV0pCitBQ19DSEVDS19MSUIoW3lhamxdLCBbeWFqbF9hbGxvY10sIFtdLAorICAgIFtBQ19NU0df
RVJST1IoW0NvdWxkIG5vdCBmaW5kIHlhamxdKV0pCitBQ19DSEVDS19MSUIoW3pdLCBbZGVmbGF0
ZUNvcHldLCBbXSwgW0FDX01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgemxpYl0pXSkKK0FDX0NI
RUNLX0xJQihbaWNvbnZdLCBbbGliaWNvbnZfb3Blbl0sIFtsaWJpY29udj0ieSJdLCBbbGliaWNv
bnY9Im4iXSkKK0FDX1NVQlNUKGxpYmljb252KQorCisjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVz
LgorQUNfRlVOQ19BTExPQ0EKK0FDX0NIRUNLX0hFQURFUlMoWyBcCisgICAgICAgICAgICAgICAg
YXJwYS9pbmV0LmggZmNudGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2Mu
aCBcCisgICAgICAgICAgICAgICAgbmV0ZGIuaCBuZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50
Lmggc3RkbGliLmggc3RyaW5nLmggXAorICAgICAgICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmls
ZS5oIHN5cy9pb2N0bC5oIHN5cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKKyAgICAgICAgICAgICAg
ICBzeXMvc29ja2V0Lmggc3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3Mu
aCBcCisgICAgICAgICAgICAgICAgdW5pc3RkLmggeWFqbC95YWpsX3ZlcnNpb24uaCBcCisgICAg
ICAgICAgICAgICAgXSkKKworIyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQg
Y29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgorQUNfSEVBREVSX1NUREJPT0wKK0FDX1RZUEVfVUlE
X1QKK0FDX0NfSU5MSU5FCitBQ19UWVBFX0lOVDE2X1QKK0FDX1RZUEVfSU5UMzJfVAorQUNfVFlQ
RV9JTlQ2NF9UCitBQ19UWVBFX0lOVDhfVAorQUNfVFlQRV9NT0RFX1QKK0FDX1RZUEVfT0ZGX1QK
K0FDX1RZUEVfUElEX1QKK0FDX0NfUkVTVFJJQ1QKK0FDX1RZUEVfU0laRV9UCitBQ19UWVBFX1NT
SVpFX1QKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X2Jsa3NpemVdKQorQUNfU1RS
VUNUX1NUX0JMT0NLUworQUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCitB
Q19UWVBFX1VJTlQxNl9UCitBQ19UWVBFX1VJTlQzMl9UCitBQ19UWVBFX1VJTlQ2NF9UCitBQ19U
WVBFX1VJTlQ4X1QKK0FDX0NIRUNLX1RZUEVTKFtwdHJkaWZmX3RdKQorCisjIENoZWNrcyBmb3Ig
bGlicmFyeSBmdW5jdGlvbnMuCitBQ19GVU5DX0VSUk9SX0FUX0xJTkUKK0FDX0ZVTkNfRk9SSwor
QUNfRlVOQ19GU0VFS08KK0FDX0ZVTkNfTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksKK0FD
X0hFQURFUl9NQUpPUgorQUNfRlVOQ19NQUxMT0MKK0FDX0ZVTkNfTUtUSU1FCitBQ19GVU5DX01N
QVAKK0FDX0ZVTkNfUkVBTExPQworQUNfRlVOQ19TVFJOTEVOCitBQ19GVU5DX1NUUlRPRAorQUNf
Q0hFQ0tfRlVOQ1MoWyBcCisgICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2Nr
X2dldHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKKyAgICAgICAgICAgICAgICBnZXRj
d2QgZ2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAor
ICAgICAgICAgICAgICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1t
b3ZlIG1lbXNldCBta2RpciBcCisgICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29u
ZiByZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAorICAgICAgICAgICAgICAg
IHNvY2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVw
IFwKKyAgICAgICAgICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wg
c3RydG91bCBzdHJ0b3VsbCB0enNldCBcCisgICAgICAgICAgICAgICAgdW5hbWUgXAorICAgICAg
ICAgICAgICAgIF0pCisKK0FDX09VVFBVVCgpCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4
MjBlNDhhZSB0b29scy9kZWJ1Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQotLS0gYS90b29scy9kZWJ1
Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQlNb24gRmViIDIwIDE4OjM0OjE0IDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJVHVlIEZlYiAyMSAwNDoxODoyOSAy
MDEyICswMTAwCkBAIC0yMSw3ICsyMSw2IEBAIHhnX2FsbC5hOiAkKFhHX09CSlMpIE1ha2VmaWxl
ICQoWEdfSERSUykKICMJJChDQykgLW0zMiAtYyAtbyAkQCAkXgogCiB4ZW4taGVhZGVyczoKLQkk
KE1BS0UpIC1DIC4uLy4uLy4uL2NoZWNrIAogCSQoTUFLRSkgLUMgLi4vLi4vLi4vaW5jbHVkZQog
CiAjIHhnX21haW4ubzogeGdfbWFpbi5jIE1ha2VmaWxlICQoWEdfSERSUykKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2luc3RhbGwuc2gKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvaW5zdGFsbC5zaAlUdWUg
RmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxIEBACisuLi9pbnN0YWxsLnNo
ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQpkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYw
ODIwZTQ4YWUgdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQotLS0gYS90b29scy9saWJmc2ltYWdl
L01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9saWJm
c2ltYWdlL01ha2VmaWxlCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMyw3ICsz
LDExIEBAIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsKIAogU1VCRElSUy15ID0g
Y29tbW9uIHVmcyByZWlzZXJmcyBpc285NjYwIGZhdCB6ZnMKIFNVQkRJUlMtJChDT05GSUdfWDg2
KSArPSB4ZnMKLVNVQkRJUlMteSArPSAkKHNoZWxsIGVudiBDQz0iJChDQykiIC4vY2hlY2stbGli
ZXh0MmZzKQoraWZlcSAoJChDT05GSUdfRVhUMkZTKSwgeSkKKyAgICBTVUJESVJTLXkgKz0gZXh0
MmZzLWxpYgorZWxzZQorICAgIFNVQkRJUlMteSArPSBleHQyZnMKK2VuZGlmCiAKIC5QSE9OWTog
YWxsIGNsZWFuIGluc3RhbGwKIGFsbCBjbGVhbiBpbnN0YWxsOiAlOiBzdWJkaXJzLSUKZGlmZiAt
ciBjYTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGli
ZXh0MmZzCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCU1vbiBGZWIgMjAg
MTg6MzQ6MTQgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMApAQCAtMSwyMSArMCwwIEBACi0jIS9iaW4vc2gKLQotY2F0ID5leHQyLXRlc3QuYyA8
PEVPRgotI2luY2x1ZGUgPGV4dDJmcy9leHQyZnMuaD4KLQotaW50IG1haW4oKQotewotCWV4dDJm
c19vcGVuMjsKLX0KLUVPRgotCi0ke0NDLWdjY30gLW8gZXh0Mi10ZXN0IGV4dDItdGVzdC5jIC1s
ZXh0MmZzID4vZGV2L251bGwgMj4mMQotaWYgWyAkPyA9IDAgXTsgdGhlbgotCWVjaG8gZXh0MmZz
LWxpYgotZWxzZQotCWVjaG8gZXh0MmZzCi1maQotCi1ybSAtZiBleHQyLXRlc3QgZXh0Mi10ZXN0
LmMKLQotZXhpdCAwCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9s
aWJ4ZW4vTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGlieGVuL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6
MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9saWJ4ZW4vTWFrZWZpbGUJVHVlIEZlYiAyMSAw
NDoxODoyOSAyMDEyICswMTAwCkBAIC0yMiwxMiArMjIsMTIgQEAgTUFKT1IgPSAxLjAKIE1JTk9S
ID0gMAogCiBDRkxBR1MgKz0gLUlpbmNsdWRlICAgICAgICAgICAgICAgICAgICAgXAotICAgICAg
ICAgICQoc2hlbGwgeG1sMi1jb25maWcgLS1jZmxhZ3MpIFwKLSAgICAgICAgICAkKHNoZWxsIGN1
cmwtY29uZmlnIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAkKFhNTDJfQ09ORklHKSAt
LWNmbGFncykgXAorICAgICAgICAgICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1jZmxhZ3MpIFwK
ICAgICAgICAgICAtZlBJQwogCi1MREZMQUdTICs9ICQoc2hlbGwgeG1sMi1jb25maWcgLS1saWJz
KSBcCi0gICAgICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1saWJzKQorTERGTEFHUyArPSAk
KHNoZWxsICQoWE1MMl9DT05GSUcpIC0tbGlicykgXAorICAgICAgICAgICAkKHNoZWxsICQoQ1VS
TF9DT05GSUcpIC0tbGlicykKIAogTElCWEVOQVBJX0hEUlMgPSAkKHdpbGRjYXJkIGluY2x1ZGUv
eGVuL2FwaS8qLmgpIGluY2x1ZGUveGVuL2FwaS94ZW5fYWxsLmgKIExJQlhFTkFQSV9PQkpTID0g
JChwYXRzdWJzdCAlLmMsICUubywgJCh3aWxkY2FyZCBzcmMvKi5jKSkKZGlmZiAtciBjYTgwZWNh
OWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL2xpYnhsL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xp
YnhsL01ha2VmaWxlCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9s
aWJ4bC9NYWtlZmlsZQlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTE5LDEwICsx
OSw2IEBAIGlmZXEgKCQoQ09ORklHX0xpbnV4KSx5KQogTElCVVVJRF9MSUJTICs9IC1sdXVpZAog
ZW5kaWYKIAotaWZlcSAoJChDT05GSUdfWUFKTF9WRVJTSU9OKSx5KQotQ0ZMQUdTICs9IC1ESEFW
RV9ZQUpMX1ZFUlNJT04KLWVuZGlmCi0KIExJQlhMX0xJQlMgPQogTElCWExfTElCUyA9ICQoTERM
SUJTX2xpYnhlbmN0cmwpICQoTERMSUJTX2xpYnhlbmd1ZXN0KSAkKExETElCU19saWJ4ZW5zdG9y
ZSkgJChMRExJQlNfbGliYmxrdGFwY3RsKSAkKFVUSUxfTElCUykgJChMSUJVVUlEX0xJQlMpCiAK
QEAgLTU2LDcgKzUyLDcgQEAgTElCWExfT0JKUyA9IGZsZXhhcnJheS5vIGxpYnhsLm8gbGlieGxf
YwogCQkJbGlieGxfcW1wLm8gbGlieGxfZXZlbnQubyAkKExJQlhMX09CSlMteSkKIExJQlhMX09C
SlMgKz0gX2xpYnhsX3R5cGVzLm8gbGlieGxfZmxhc2subyBfbGlieGxfdHlwZXNfaW50ZXJuYWwu
bwogCi0kKExJQlhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxB
R1NfbGlieGVuZ3Vlc3QpICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKSAkKENGTEFHU19saWJibGt0YXBj
dGwpCiskKExJQlhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgJChDRkxB
R1NfbGlieGVuZ3Vlc3QpICQoQ0ZMQUdTX2xpYnhlbnN0b3JlKSAkKENGTEFHU19saWJibGt0YXBj
dGwpIC1pbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL2NvbmZpZy5oCiAKIEFVVE9JTkNTPSBsaWJ4
bHVfY2ZnX3kuaCBsaWJ4bHVfY2ZnX2wuaCBfbGlieGxfbGlzdC5oCiBBVVRPU1JDUz0gbGlieGx1
X2NmZ195LmMgbGlieGx1X2NmZ19sLmMKQEAgLTY5LDYgKzY1LDcgQEAgQ0xJRU5UUyA9IHhsIHRl
c3RpZGwKIFhMX09CSlMgPSB4bC5vIHhsX2NtZGltcGwubyB4bF9jbWR0YWJsZS5vIHhsX3N4cC5v
CiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVuY3RybCkgIyBGb3IgeGVudG9v
bGxvZy5oCiAkKFhMX09CSlMpOiBDRkxBR1MgKz0gJChDRkxBR1NfbGlieGVubGlnaHQpCiskKFhM
X09CSlMpOiBDRkxBR1MgKz0gLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvY29uZmlnLmggIyBs
aWJ4bF9qc29uLmggbmVlZHMgaXQuCiAKIHRlc3RpZGwubzogQ0ZMQUdTICs9ICQoQ0ZMQUdTX2xp
YnhlbmN0cmwpICQoQ0ZMQUdTX2xpYnhlbmxpZ2h0KQogdGVzdGlkbC5jOiBsaWJ4bF90eXBlcy5p
ZGwgZ2VudGVzdC5weSBsaWJ4bC5oICQoQVVUT0lOQ1MpCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1y
IGMyZjA4MjBlNDhhZSB0b29scy9saWJ4bC9saWJ4bF9qc29uLmgKLS0tIGEvdG9vbHMvbGlieGwv
bGlieGxfanNvbi5oCU1vbiBGZWIgMjAgMTg6MzQ6MTQgMjAxMiArMDAwMAorKysgYi90b29scy9s
aWJ4bC9saWJ4bF9qc29uLmgJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0xOCw3
ICsxOCw3IEBACiAjaW5jbHVkZSA8eWFqbC95YWpsX2dlbi5oPgogI2luY2x1ZGUgPHlhamwveWFq
bF9wYXJzZS5oPgogCi0jaWZkZWYgSEFWRV9ZQUpMX1ZFUlNJT04KKyNpZmRlZiBIQVZFX1lBSkxf
WUFKTF9WRVJTSU9OX0gKICMgIGluY2x1ZGUgPHlhamwveWFqbF92ZXJzaW9uLmg+CiAjZW5kaWYK
IApkaWZmIC1yIGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvbTQvZGVmYXVsdF9s
aWIubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvZGVmYXVsdF9saWIubTQJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsOCBAQAorQUNfREVGVU4oW0FYX0RFRkFVTFRfTElCXSwKK1tBU19JRihbdGVzdCAt
ZCAiJHByZWZpeC9saWI2NCJdLCBbCisgICAgTElCX1BBVEg9ImxpYjY0IgorXSxbCisgICAgTElC
X1BBVEg9ImxpYiIKK10pCitBQ19TVUJTVChMSUJfUEFUSCldKQorCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZGlzYWJs
ZV9mZWF0dXJlLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEz
IEBACitBQ19ERUZVTihbQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVF0sCitbQUNfQVJHX0VOQUJM
RShbJDFdLAorICAgIEFTX0hFTFBfU1RSSU5HKFstLWRpc2FibGUtJDFdLCBbJDJdKSkKKworQVNf
SUYoW3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4bm8iXSwgWworICAgIGF4X2N2XyQxPSJuIgorXSwg
W3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4eWVzIl0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0
ZXN0IC16ICRheF9jdl8kMV0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10pCiskMT0kYXhfY3ZfJDEK
K0FDX1NVQlNUKCQxKV0pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29s
cy9tNC9lbmFibGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAg
MTk3MCArMDAwMAorKysgYi90b29scy9tNC9lbmFibGVfZmVhdHVyZS5tNAlUdWUgRmViIDIxIDA0
OjE4OjI5IDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMyBAQAorQUNfREVGVU4oW0FYX0FSR19FTkFC
TEVfQU5EX0VYUE9SVF0sCitbQUNfQVJHX0VOQUJMRShbJDFdLAorICAgIEFTX0hFTFBfU1RSSU5H
KFstLWVuYWJsZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInh5
ZXMiXSwgWworICAgIGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgIngkZW5hYmxlXyQxIiA9ICJ4bm8i
XSwgWworICAgIGF4X2N2XyQxPSJuIgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4
X2N2XyQxPSJuIgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL200L29jYW1sLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L29jYW1sLm00CVR1
ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDI0MSBAQAorZG5sIGF1dG9j
b25mIG1hY3JvcyBmb3IgT0NhbWwKK2RubCBmcm9tIGh0dHA6Ly9mb3JnZS5vY2FtbGNvcmUub3Jn
LworZG5sCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAgICBSaWNoYXJkIFcuTS4gSm9uZXMKK2Ru
bCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFN0ZWZhbm8gWmFjY2hpcm9saQorZG5sIENvcHlyaWdo
dCDCqSAyMDAwLTIwMDUgT2xpdmllciBBbmRyaWV1CitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAw
NSBKZWFuLUNocmlzdG9waGUgRmlsbGnDonRyZQorZG5sIENvcHlyaWdodCDCqSAyMDAwLTIwMDUg
R2VvcmdlcyBNYXJpYW5vCitkbmwKK2RubCBGb3IgZG9jdW1lbnRhdGlvbiwgcGxlYXNlIHJlYWQg
dGhlIG9jYW1sLm00IG1hbiBwYWdlLgorCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTF0sCitbZG5s
CisgICMgY2hlY2tpbmcgZm9yIG9jYW1sYworICBBQ19DSEVDS19UT09MKFtPQ0FNTENdLFtvY2Ft
bGNdLFtub10pCisKKyAgaWYgdGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FN
TFZFUlNJT049YCRPQ0FNTEMgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxc
MXxwJ2AKKyAgICAgQUNfTVNHX1JFU1VMVChbT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxWRVJTSU9O
XSkKKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAorICAgICBpZiB0ZXN0ICIkT0NB
TUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMgLXdoZXJlIDI+L2Rl
di9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRgCisgICAgIGVsc2UK
KyAgICAgICAgQUNfTVNHX1JFU1VMVChbT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZp
bmcgaXQuXSkKKyAgICAgZmkKKyAgICAgQUNfTVNHX1JFU1VMVChbT0NhbWwgbGlicmFyeSBwYXRo
IGlzICRPQ0FNTExJQl0pCisKKyAgICAgQUNfU1VCU1QoW09DQU1MVkVSU0lPTl0pCisgICAgIEFD
X1NVQlNUKFtPQ0FNTExJQl0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQKKyAgICAg
QUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRdLFtvY2FtbG9wdF0sW25vXSkKKyAgICAgT0NBTUxCRVNU
PWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9ICJubyI7IHRoZW4KKwlBQ19NU0dfV0FS
TihbQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuXSkKKyAg
ICAgZWxzZQorCVRNUFZFUlNJT049YCRPQ0FNTE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNp
b24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZF
UlNJT04iIDsgdGhlbgorCSAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuXSkKKwkgICAgT0NBTUxPUFQ9bm8KKwllbHNlCisJ
ICAgIE9DQU1MQkVTVD1vcHQKKwlmaQorICAgICBmaQorCisgICAgIEFDX1NVQlNUKFtPQ0FNTEJF
U1RdKQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgQUNfQ0hFQ0tfVE9P
TChbT0NBTUxDRE9UT1BUXSxbb2NhbWxjLm9wdF0sW25vXSkKKyAgICAgaWYgdGVzdCAiJE9DQU1M
Q0RPVE9QVCIgIT0gIm5vIjsgdGhlbgorCVRNUFZFUlNJT049YCRPQ0FNTENET1RPUFQgLXYgfCBz
ZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZF
UlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVy
c2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuXSkKKwllbHNl
CisJICAgIE9DQU1MQz0kT0NBTUxDRE9UT1BUCisJZmkKKyAgICAgZmkKKworICAgICAjIGNoZWNr
aW5nIGZvciBvY2FtbG9wdC5vcHQKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsg
dGhlbgorCUFDX0NIRUNLX1RPT0woW09DQU1MT1BURE9UT1BUXSxbb2NhbWxvcHQub3B0XSxbbm9d
KQorCWlmIHRlc3QgIiRPQ0FNTE9QVERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCSAgIFRNUFZFUlNJ
T049YCRPQ0FNTE9QVERPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkk
fFwxfHAnIGAKKwkgICBpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsg
dGhlbgorCSAgICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxvcHQub3B0IGRpc2NhcmRlZC5dKQorCSAgIGVsc2UKKwkgICAgICBPQ0FNTE9QVD0kT0NB
TUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAgICBmaQorCisgICAgIEFDX1NVQlNU
KFtPQ0FNTE9QVF0pCisgIGZpCisKKyAgQUNfU1VCU1QoW09DQU1MQ10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxdLFtvY2FtbF0sW25v
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGRlcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTERF
UF0sW29jYW1sZGVwXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWt0b3AKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxNS1RPUF0sW29jYW1sbWt0b3BdLFtub10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxta2xpYgorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LTElCXSxbb2NhbWxta2xp
Yl0sW25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGRvYworICBBQ19DSEVDS19UT09MKFtP
Q0FNTERPQ10sW29jYW1sZG9jXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQK
KyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxCVUlMRF0sW29jYW1sYnVpbGRdLFtub10pCitdKQorCisK
K0FDX0RFRlVOKFtBQ19QUk9HX09DQU1MTEVYXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2Nh
bWxsZXgKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxMRVhdLFtvY2FtbGxleF0sW25vXSkKKyAgaWYg
dGVzdCAiJE9DQU1MTEVYIiAhPSAibm8iOyB0aGVuCisgICAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxM
RVhET1RPUFRdLFtvY2FtbGxleC5vcHRdLFtub10pCisgICAgaWYgdGVzdCAiJE9DQU1MTEVYRE9U
T1BUIiAhPSAibm8iOyB0aGVuCisJT0NBTUxMRVg9JE9DQU1MTEVYRE9UT1BUCisgICAgZmkKKyAg
ZmkKKyAgQUNfU1VCU1QoW09DQU1MTEVYXSkKK10pCisKK0FDX0RFRlVOKFtBQ19QUk9HX09DQU1M
WUFDQ10sCitbZG5sCisgIEFDX0NIRUNLX1RPT0woW09DQU1MWUFDQ10sW29jYW1seWFjY10sW25v
XSkKKyAgQUNfU1VCU1QoW09DQU1MWUFDQ10pCitdKQorCisKK0FDX0RFRlVOKFtBQ19QUk9HX0NB
TUxQNF0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisgICMgY2hl
Y2tpbmcgZm9yIGNhbWxwNAorICBBQ19DSEVDS19UT09MKFtDQU1MUDRdLFtjYW1scDRdLFtub10p
CisgIGlmIHRlc3QgIiRDQU1MUDQiICE9ICJubyI7IHRoZW4KKyAgICAgVE1QVkVSU0lPTj1gJENB
TUxQNCAtdiAyPiYxfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uICpcKC4qXCkkfFwxfHAnYAorICAg
ICBpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCUFDX01T
R19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGNdKQorICAgICAgICBDQU1MUDQ9
bm8KKyAgICAgZmkKKyAgZmkKKyAgQUNfU1VCU1QoW0NBTUxQNF0pCisKKyAgIyBjaGVja2luZyBm
b3IgY29tcGFuaW9uIHRvb2xzCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNEJPT1RdLFtjYW1scDRi
b290XSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPXSxbY2FtbHA0b10sW25vXSkKKyAg
QUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T0ZdLFtjYW1scDRvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9P
TChbQ0FNTFA0T09GXSxbY2FtbHA0b29mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRP
UkZdLFtjYW1scDRvcmZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFBST0ZdLFtjYW1s
cDRwcm9mXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRSXSxbY2FtbHA0cl0sW25vXSkK
KyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0UkZdLFtjYW1scDRyZl0sW25vXSkKKyAgQUNfU1VCU1Qo
W0NBTUxQNEJPT1RdKQorICBBQ19TVUJTVChbQ0FNTFA0T10pCisgIEFDX1NVQlNUKFtDQU1MUDRP
Rl0pCisgIEFDX1NVQlNUKFtDQU1MUDRPT0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0T1JGXSkKKyAg
QUNfU1VCU1QoW0NBTUxQNFBST0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0Ul0pCisgIEFDX1NVQlNU
KFtDQU1MUDRSRl0pCitdKQorCisKK0FDX0RFRlVOKFtBQ19QUk9HX0ZJTkRMSUJdLAorW2RubAor
ICBBQ19SRVFVSVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKworICAjIGNoZWNraW5nIGZvciBvY2Ft
bGZpbmQKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxGSU5EXSxbb2NhbWxmaW5kXSxbbm9dKQorICBB
Q19TVUJTVChbT0NBTUxGSU5EXSkKK10pCisKKworZG5sIFRoYW5rcyB0byBKaW0gTWV5ZXJpbmcg
Zm9yIHdvcmtpbmcgdGhpcyBuZXh0IGJpdCBvdXQgZm9yIHVzLgorZG5sIFhYWCBXZSBzaG91bGQg
ZGVmaW5lIEFTX1RSX1NIIGlmIGl0J3Mgbm90IGRlZmluZWQgYWxyZWFkeQorZG5sIChlZy4gZm9y
IG9sZCBhdXRvY29uZikuCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfUEtHXSwKK1tkbmwKKyAg
QUNfUkVRVUlSRShbQUNfUFJPR19GSU5ETElCXSlkbmwKKworICBBQ19NU0dfQ0hFQ0tJTkcoW2Zv
ciBPQ2FtbCBmaW5kbGliIHBhY2thZ2UgJDFdKQorCisgIHVuc2V0IGZvdW5kCisgIHVuc2V0IHBr
ZworICBmb3VuZD1ubworICBmb3IgcGtnIGluICQxICQyIDsgZG8KKyAgICBpZiAkT0NBTUxGSU5E
IHF1ZXJ5ICRwa2cgPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbgorICAgICAgQUNfTVNHX1JF
U1VMVChbZm91bmRdKQorICAgICAgQVNfVFJfU0goW09DQU1MX1BLR18kMV0pPSRwa2cKKyAgICAg
IGZvdW5kPXllcworICAgICAgYnJlYWsKKyAgICBmaQorICBkb25lCisgIGlmIHRlc3QgIiRmb3Vu
ZCIgPSAibm8iIDsgdGhlbgorICAgIEFDX01TR19SRVNVTFQoW25vdCBmb3VuZF0pCisgICAgQVNf
VFJfU0goW09DQU1MX1BLR18kMV0pPW5vCisgIGZpCisKKyAgQUNfU1VCU1QoQVNfVFJfU0goW09D
QU1MX1BLR18kMV0pKQorXSkKKworCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfTU9EVUxFXSwK
K1tkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgbW9kdWxlICQyXSkKKworICBjYXQg
PiBjb25mdGVzdC5tbCA8PEVPRgorb3BlbiAkMworRU9GCisgIHVuc2V0IGZvdW5kCisgIGZvciAk
MSBpbiAkJDEgJDQgOyBkbworICAgIGlmICRPQ0FNTEMgLWMgLUkgIiQkMSIgY29uZnRlc3QubWwg
PiY1IDI+JjUgOyB0aGVuCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAg
ZG9uZQorCisgIGlmIHRlc3QgIiRmb3VuZCIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbJCQx
XSkKKyAgZWxzZQorICAgIEFDX01TR19SRVNVTFQoW25vdCBmb3VuZF0pCisgICAgJDE9bm8KKyAg
ZmkKKyAgQUNfU1VCU1QoWyQxXSkKK10pCisKKworZG5sIFhYWCBDcm9zcy1jb21waWxpbmcKK0FD
X0RFRlVOKFtBQ19DSEVDS19PQ0FNTF9XT1JEX1NJWkVdLAorW2RubAorICBBQ19SRVFVSVJFKFtB
Q19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgY29tcGlsZXIg
d29yZCBzaXplXSkKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfZW5kbGluZSAo
c3RyaW5nX29mX2ludCBTeXMud29yZF9zaXplKQorICBFT0YKKyAgT0NBTUxfV09SRF9TSVpFPWAk
T0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01TR19SRVNVTFQoWyRPQ0FNTF9XT1JEX1NJWkVdKQor
ICBBQ19TVUJTVChbT0NBTUxfV09SRF9TSVpFXSkKK10pCisKK0FDX0RFRlVOKFtBQ19DSEVDS19P
Q0FNTF9PU19UWVBFXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisg
IEFDX01TR19DSEVDS0lORyhbT0NhbWwgU3lzLm9zX3R5cGVdKQorCisgIGNhdCA+IGNvbmZ0ZXN0
Lm1sIDw8RU9GCisgIHByaW50X3N0cmluZyhTeXMub3NfdHlwZSk7OworRU9GCisKKyAgT0NBTUxf
T1NfVFlQRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFskT0NBTUxfT1Nf
VFlQRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9PU19UWVBFXSkKK10pCmRpZmYgLXIgY2E4MGVjYTlj
ZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9wYXRoX29yX2ZhaWwubTQKLS0tIC9kZXYvbnVs
bAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvcGF0aF9vcl9m
YWlsLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDYgQEAKK0FD
X0RFRlVOKFtBWF9QQVRIX1BST0dfT1JfRkFJTF0sCitbQUNfUEFUSF9QUk9HKFskMV0sIFskMl0s
IFtub10pCitpZiB0ZXN0IHgiJHskMX0iID09IHgibm8iIAordGhlbgorICAgIEFDX01TR19FUlJP
UihbVW5hYmxlIHRvIGZpbmQgJDIsIHBsZWFzZSBpbnN0YWxsICQyXSkKK2ZpXSkKZGlmZiAtciBj
YTgwZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL200L3BrZy5tNAotLS0gL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9wa2cubTQJVHVl
IEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTU3IEBACisjIHBrZy5tNCAt
IE1hY3JvcyB0byBsb2NhdGUgYW5kIHV0aWxpc2UgcGtnLWNvbmZpZy4gICAgICAgICAgICAtKi0g
QXV0b2NvbmYgLSotCisjIHNlcmlhbCAxIChwa2ctY29uZmlnLTAuMjQpCisjIAorIyBDb3B5cmln
aHQgwqkgMjAwNCBTY290dCBKYW1lcyBSZW1uYW50IDxzY290dEBuZXRzcGxpdC5jb20+LgorIwor
IyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeQorIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorIyAoYXQgeW91ciBvcHRp
b24pIGFueSBsYXRlciB2ZXJzaW9uLgorIworIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQg
aW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CisjIFdJVEhPVVQgQU5ZIFdB
UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyMgTUVSQ0hBTlRB
QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUK
KyMgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorIworIyBZb3Ugc2hv
dWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZQorIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBT
b2Z0d2FyZQorIyBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAs
IEJvc3RvbiwgTUEgMDIxMTEtMTMwNywgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhjZXB0aW9u
IHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3RyaWJ1dGUg
dGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBjb25maWd1
cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVkZSBpdCB1
bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZvciB0aGUg
cmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKyMgUEtHX1BST0dfUEtHX0NPTkZJRyhbTUlOLVZFUlNJ
T05dKQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCitBQ19ERUZVTihbUEtH
X1BST0dfUEtHX0NPTkZJR10sCitbbTRfcGF0dGVybl9mb3JiaWQoW15fP1BLR19bQS1aX10rJF0p
CittNF9wYXR0ZXJuX2FsbG93KFteUEtHX0NPTkZJRyhfUEFUSCk/JF0pCitBQ19BUkdfVkFSKFtQ
S0dfQ09ORklHXSwgW3BhdGggdG8gcGtnLWNvbmZpZyB1dGlsaXR5XSkKK0FDX0FSR19WQVIoW1BL
R19DT05GSUdfUEFUSF0sIFtkaXJlY3RvcmllcyB0byBhZGQgdG8gcGtnLWNvbmZpZydzIHNlYXJj
aCBwYXRoXSkKK0FDX0FSR19WQVIoW1BLR19DT05GSUdfTElCRElSXSwgW3BhdGggb3ZlcnJpZGlu
ZyBwa2ctY29uZmlnJ3MgYnVpbHQtaW4gc2VhcmNoIHBhdGhdKQorCitpZiB0ZXN0ICJ4JGFjX2N2
X2Vudl9QS0dfQ09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCisJQUNfUEFUSF9UT09MKFtQS0df
Q09ORklHXSwgW3BrZy1jb25maWddKQorZmkKK2lmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhl
bgorCV9wa2dfbWluX3ZlcnNpb249bTRfZGVmYXVsdChbJDFdLCBbMC45LjBdKQorCUFDX01TR19D
SEVDS0lORyhbcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9u
XSkKKwlpZiAkUEtHX0NPTkZJRyAtLWF0bGVhc3QtcGtnY29uZmlnLXZlcnNpb24gJF9wa2dfbWlu
X3ZlcnNpb247IHRoZW4KKwkJQUNfTVNHX1JFU1VMVChbeWVzXSkKKwllbHNlCisJCUFDX01TR19S
RVNVTFQoW25vXSkKKwkJUEtHX0NPTkZJRz0iIgorCWZpCitmaVtdZG5sCitdKSMgUEtHX1BST0df
UEtHX0NPTkZJRworCisjIFBLR19DSEVDS19FWElTVFMoTU9EVUxFUywgW0FDVElPTi1JRi1GT1VO
RF0sIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkKKyMKKyMgQ2hlY2sgdG8gc2VlIHdoZXRoZXIgYSBw
YXJ0aWN1bGFyIHNldCBvZiBtb2R1bGVzIGV4aXN0cy4gIFNpbWlsYXIKKyMgdG8gUEtHX0NIRUNL
X01PRFVMRVMoKSwgYnV0IGRvZXMgbm90IHNldCB2YXJpYWJsZXMgb3IgcHJpbnQgZXJyb3JzLgor
IworIyBQbGVhc2UgcmVtZW1iZXIgdGhhdCBtNCBleHBhbmRzIEFDX1JFUVVJUkUoW1BLR19QUk9H
X1BLR19DT05GSUddKQorIyBvbmx5IGF0IHRoZSBmaXJzdCBvY2N1cmVuY2UgaW4gY29uZmlndXJl
LmFjLCBzbyBpZiB0aGUgZmlyc3QgcGxhY2UKKyMgaXQncyBjYWxsZWQgbWlnaHQgYmUgc2tpcHBl
ZCAoc3VjaCBhcyBpZiBpdCBpcyB3aXRoaW4gYW4gImlmIiwgeW91CisjIGhhdmUgdG8gY2FsbCBQ
S0dfQ0hFQ0tfRVhJU1RTIG1hbnVhbGx5CisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCitBQ19ERUZVTihbUEtHX0NIRUNLX0VY
SVNUU10sCitbQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pZG5sCitpZiB0ZXN0IC1u
ICIkUEtHX0NPTkZJRyIgJiYgXAorICAgIEFDX1JVTl9MT0coWyRQS0dfQ09ORklHIC0tZXhpc3Rz
IC0tcHJpbnQtZXJyb3JzICIkMSJdKTsgdGhlbgorICBtNF9kZWZhdWx0KFskMl0sIFs6XSkKK200
X2lmdmFsbihbJDNdLCBbZWxzZQorICAkM10pZG5sCitmaV0pCisKKyMgX1BLR19DT05GSUcoW1ZB
UklBQkxFXSwgW0NPTU1BTkRdLCBbTU9EVUxFU10pCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorbTRfZGVmaW5lKFtfUEtHX0NPTkZJR10sCitbaWYgdGVz
dCAtbiAiJCQxIjsgdGhlbgorICAgIHBrZ19jdl9bXSQxPSIkJDEiCisgZWxpZiB0ZXN0IC1uICIk
UEtHX0NPTkZJRyI7IHRoZW4KKyAgICBQS0dfQ0hFQ0tfRVhJU1RTKFskM10sCisgICAgICAgICAg
ICAgICAgICAgICBbcGtnX2N2X1tdJDE9YCRQS0dfQ09ORklHIC0tW10kMiAiJDMiIDI+L2Rldi9u
dWxsYF0sCisJCSAgICAgW3BrZ19mYWlsZWQ9eWVzXSkKKyBlbHNlCisgICAgcGtnX2ZhaWxlZD11
bnRyaWVkCitmaVtdZG5sCitdKSMgX1BLR19DT05GSUcKKworIyBfUEtHX1NIT1JUX0VSUk9SU19T
VVBQT1JURUQKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KK0FDX0RFRlVOKFtfUEtH
X1NIT1JUX0VSUk9SU19TVVBQT1JURURdLAorW0FDX1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05G
SUddKQoraWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uIDAuMjA7IHRo
ZW4KKyAgICAgICAgX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkPXllcworZWxzZQorICAgICAg
ICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9bm8KK2ZpW11kbmwKK10pIyBfUEtHX1NIT1JU
X0VSUk9SU19TVVBQT1JURUQKKworCisjIFBLR19DSEVDS19NT0RVTEVTKFZBUklBQkxFLVBSRUZJ
WCwgTU9EVUxFUywgW0FDVElPTi1JRi1GT1VORF0sCisjIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkK
KyMKKyMKKyMgTm90ZSB0aGF0IGlmIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgdGhlIGZpcnN0IGNh
bGwgdG8KKyMgUEtHX0NIRUNLX01PRFVMRVMgbWlnaHQgbm90IGhhcHBlbiwgeW91IHNob3VsZCBi
ZSBzdXJlIHRvIGluY2x1ZGUgYW4KKyMgZXhwbGljaXQgY2FsbCB0byBQS0dfUFJPR19QS0dfQ09O
RklHIGluIHlvdXIgY29uZmlndXJlLmFjCisjCisjCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCitBQ19ERUZVTihbUEtHX0NI
RUNLX01PRFVMRVNdLAorW0FDX1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05GSUddKWRubAorQUNf
QVJHX1ZBUihbJDFdW19DRkxBR1NdLCBbQyBjb21waWxlciBmbGFncyBmb3IgJDEsIG92ZXJyaWRp
bmcgcGtnLWNvbmZpZ10pZG5sCitBQ19BUkdfVkFSKFskMV1bX0xJQlNdLCBbbGlua2VyIGZsYWdz
IGZvciAkMSwgb3ZlcnJpZGluZyBwa2ctY29uZmlnXSlkbmwKKworcGtnX2ZhaWxlZD1ubworQUNf
TVNHX0NIRUNLSU5HKFtmb3IgJDFdKQorCitfUEtHX0NPTkZJRyhbJDFdW19DRkxBR1NdLCBbY2Zs
YWdzXSwgWyQyXSkKK19QS0dfQ09ORklHKFskMV1bX0xJQlNdLCBbbGlic10sIFskMl0pCisKK200
X2RlZmluZShbX1BLR19URVhUXSwgW0FsdGVybmF0aXZlbHksIHlvdSBtYXkgc2V0IHRoZSBlbnZp
cm9ubWVudCB2YXJpYWJsZXMgJDFbXV9DRkxBR1MKK2FuZCAkMVtdX0xJQlMgdG8gYXZvaWQgdGhl
IG5lZWQgdG8gY2FsbCBwa2ctY29uZmlnLgorU2VlIHRoZSBwa2ctY29uZmlnIG1hbiBwYWdlIGZv
ciBtb3JlIGRldGFpbHMuXSkKKworaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHllczsgdGhlbgorICAg
CUFDX01TR19SRVNVTFQoW25vXSkKKyAgICAgICAgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVE
CisgICAgICAgIGlmIHRlc3QgJF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZCA9IHllczsgdGhl
bgorCSAgICAgICAgJDFbXV9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXNob3J0LWVycm9ycyAt
LXByaW50LWVycm9ycyAiJDIiIDI+JjFgCisgICAgICAgIGVsc2UgCisJICAgICAgICAkMVtdX1BL
R19FUlJPUlM9YCRQS0dfQ09ORklHIC0tcHJpbnQtZXJyb3JzICIkMiIgMj4mMWAKKyAgICAgICAg
ZmkKKwkjIFB1dCB0aGUgbmFzdHkgZXJyb3IgbWVzc2FnZSBpbiBjb25maWcubG9nIHdoZXJlIGl0
IGJlbG9uZ3MKKwllY2hvICIkJDFbXV9QS0dfRVJST1JTIiA+JkFTX01FU1NBR0VfTE9HX0ZECisK
KwltNF9kZWZhdWx0KFskNF0sIFtBQ19NU0dfRVJST1IoCitbUGFja2FnZSByZXF1aXJlbWVudHMg
KCQyKSB3ZXJlIG5vdCBtZXQ6CisKKyQkMV9QS0dfRVJST1JTCisKK0NvbnNpZGVyIGFkanVzdGlu
ZyB0aGUgUEtHX0NPTkZJR19QQVRIIGVudmlyb25tZW50IHZhcmlhYmxlIGlmIHlvdQoraW5zdGFs
bGVkIHNvZnR3YXJlIGluIGEgbm9uLXN0YW5kYXJkIHByZWZpeC4KKworX1BLR19URVhUXSlkbmwK
KyAgICAgICAgXSkKK2VsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRoZW4KKyAgICAg
CUFDX01TR19SRVNVTFQoW25vXSkKKwltNF9kZWZhdWx0KFskNF0sIFtBQ19NU0dfRkFJTFVSRSgK
K1tUaGUgcGtnLWNvbmZpZyBzY3JpcHQgY291bGQgbm90IGJlIGZvdW5kIG9yIGlzIHRvbyBvbGQu
ICBNYWtlIHN1cmUgaXQKK2lzIGluIHlvdXIgUEFUSCBvciBzZXQgdGhlIFBLR19DT05GSUcgZW52
aXJvbm1lbnQgdmFyaWFibGUgdG8gdGhlIGZ1bGwKK3BhdGggdG8gcGtnLWNvbmZpZy4KKworX1BL
R19URVhUCisKK1RvIGdldCBwa2ctY29uZmlnLCBzZWUgPGh0dHA6Ly9wa2ctY29uZmlnLmZyZWVk
ZXNrdG9wLm9yZy8+Ll0pZG5sCisgICAgICAgIF0pCitlbHNlCisJJDFbXV9DRkxBR1M9JHBrZ19j
dl9bXSQxW11fQ0ZMQUdTCisJJDFbXV9MSUJTPSRwa2dfY3ZfW10kMVtdX0xJQlMKKyAgICAgICAg
QUNfTVNHX1JFU1VMVChbeWVzXSkKKwkkMworZmlbXWRubAorXSkjIFBLR19DSEVDS19NT0RVTEVT
CmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9weXRob25fZGV2
ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvcHl0aG9uX2RldmVsLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApA
QCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tBQ19N
U0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQg
b3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhw
ICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEp
CisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFja2Fn
ZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYg
LXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9tNC9weXRob25fdmVyc2lvbi5t
NAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29s
cy9tNC9weXRob25fdmVyc2lvbi5tNAlUdWUgRmViIDIxIDA0OjE4OjI5IDIwMTIgKzAxMDAKQEAg
LTAsMCArMSwxMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tBQ19N
U0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04gLWMg
J2ltcG9ydCBzeXM7IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikpJ2AK
K2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAt
ViAyPiYxYAorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisgICAg
ICAgIFskcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9u
IGlzICQxLiQyXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1y
IGNhODBlY2E5Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvbTQvcHl0aG9uX3htbC5tNAotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9w
eXRob25feG1sLm00CVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDEw
IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5HKFtm
b3IgcHl0aG9uIHhtbC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20u
bWluaWRvbSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VMVChb
bm9dKQorICAgIEFDX01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1v
ZHVsZV0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciBjYTgw
ZWNhOWNmYTMgLXIgYzJmMDgyMGU0OGFlIHRvb2xzL200L3NldF9jZmxhZ3NfbGRmbGFncy5tNAot
LS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9t
NC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBA
IC0wLDAgKzEsMjAgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBjZmxhZyBpbiAk
UFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2Rv
bmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRfTERGTEFHUys9
IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURFUworZG8KKyAg
ICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkQVBQRU5E
X0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitDRkxBR1M9
IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFHUz0iJFBSRVBF
TkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1yIGNhODBlY2E5
Y2ZhMyAtciBjMmYwODIwZTQ4YWUgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00CVR1ZSBGZWIg
MjEgMDQ6MTg6MjkgMjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZVTihbQVhfQ0hF
Q0tfVURFVl0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIKK3RoZW4KKyAg
ICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVzdCB4
IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtV
REVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJTkZP
fSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAorICAg
ICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2Ug
aW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5GT30g
LVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7VURF
VkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVzdCAk
e3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQTFVH
XSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0geCJu
byIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRvbyBv
bGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAgZmkK
K2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkKKyAg
ICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBBQ19N
U0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkKKyAg
ICBmaQorZmkKK10pCmRpZmYgLXIgY2E4MGVjYTljZmEzIC1yIGMyZjA4MjBlNDhhZSB0b29scy9t
NC91dWlkLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3Rvb2xzL200L3V1aWQubTQJVHVlIEZlYiAyMSAwNDoxODoyOSAyMDEyICswMTAwCkBAIC0w
LDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VVUlEXSwKK1tpZiB0ZXN0ICJ4JGhvc3Rf
b3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgIEFDX0NIRUNLX0hFQURFUihbdXVpZC91dWlk
LmhdLCwKKwkgICAgW0FDX01TR19FUlJPUihbY2Fubm90IGZpbmQgdXVpZCBoZWFkZXJzXSldKQor
ZWxzZQorICAgIEFDX0NIRUNLX0hFQURFUihbdXVpZC5oXSwsCisJICAgIFtBQ19NU0dfRVJST1Io
W2Nhbm5vdCBmaW5kIHV1aWQgaGVhZGVyc10pXSkKK2ZpCitdKQpkaWZmIC1yIGNhODBlY2E5Y2Zh
MyAtciBjMmYwODIwZTQ4YWUgdmVyc2lvbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6
MDA6MDAgMTk3MCArMDAwMAorKysgYi92ZXJzaW9uLnNoCVR1ZSBGZWIgMjEgMDQ6MTg6MjkgMjAx
MiArMDEwMApAQCAtMCwwICsxLDUgQEAKKyMhL2Jpbi9zaAorCitNQUpPUj1gZ3JlcCAiZXhwb3J0
IFhFTl9WRVJTSU9OIiAkMSB8IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdy
ZXAgImV4cG9ydCBYRU5fU1VCVkVSU0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIg
ImAKK3ByaW50ZiAiJWQuJWQiICRNQUpPUiAkTUlOT1IK

--===============6369934646102767628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6369934646102767628==--


From xen-devel-bounces@lists.xen.org Tue Feb 21 14:14:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:14:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqTo-0007Aa-OD; Tue, 21 Feb 2012 14:14: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 1RzqTn-0007AO-6g
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:14:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329833599!53331431!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24533 invoked from network); 21 Feb 2012 14:13:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 14:13:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LEDvKb018830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:13:58 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
	q1LEDuPr027578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:13:57 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
	q1LEDt1I000709; Tue, 21 Feb 2012 08:13:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:13:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AF1BC40469; Tue, 21 Feb 2012 09:10:41 -0500 (EST)
Date: Tue, 21 Feb 2012 09:10:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221141041.GC11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F43A6A7.008D,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 11:07:23AM -0700, Justin T. Gibbs wrote:
>   o Document the XenBus nodes used in this protocol.
>   o Add a state diagram illustrating the roles and responsibilities
>     of both the front and backend during startup.
>   o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
> 
> No functional changes.

Some comments below.

> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 28137a4e39a3 -r e79902456819 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> @@ -22,6 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   *
>   * Copyright (c) 2003-2004, Keir Fraser
> + * Copyright (c) 2012, Spectra Logic Corporation
>   */
>  
>  #ifndef __XEN_PUBLIC_IO_BLKIF_H__
> @@ -48,32 +49,253 @@
>  #define blkif_sector_t uint64_t
>  
>  /*
> + * Feature and Parameter Negotiation
> + * =================================
> + * The two halves of a Xen block driver utilize nodes within the XenStore to
> + * communicate capabilities and to negotiate operating parameters.  This
> + * section enumerates these nodes which reside in the respective front and
> + * backend portions of the XenStore, following the XenBus convention.
> + *
> + * All data in the XenStore is stored as strings.  Nodes specifying numeric
> + * values are encoded in decimal.  Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.
> + *
> + * Any specified default value is in effect if the corresponding XenBus node
> + * is not present in the XenStore.
> + *
> + * XenStore nodes in sections marked "PRIVATE" are solely for use by the
> + * driver side whose XenBus tree contains them.
> + *
> + * See the XenBus state transition diagram below for details on when XenBus
> + * nodes must be published and when they can be queried.
> + *
> + *****************************************************************************
> + *                            Backend XenBus Nodes
> + *****************************************************************************
> + *
> + *------------------ Backend Device Identification (PRIVATE) ------------------
> + *
> + * mode
> + *      Values:         "r" (read only), "w" (writable)
> + *
> + *      The read or write access permissions to the backing store to be
> + *      granted to the frontend.
> + *
> + * params
> + *      Values:         string
> + *
> + *      A free formatted string providing sufficient information for the
> + *      backend driver to open the backing device.  (e.g. the path to the
> + *      file or block device representing the backing store.)
> + *
> + * type
> + *      Values:         "file", "phy", "tap"
> + *
> + *      The type of the backing device/object.
> + *
> + *--------------------------------- Features ---------------------------------
> + *
> + * feature-barrier
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process requests
> + *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
> + *      of this type may still be returned at any time with the
> + *      BLKIF_RSP_EOPNOTSUPP result code.
> + *
> + * feature-flush-cache
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process requests
> + *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
> + *      of this type may still be returned at any time with the
> + *      BLKIF_RSP_EOPNOTSUPP result code.
> + *
> + * feature-discard
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process requests
> + *      containing the BLKIF_OP_DISCARD request opcode.  Requests
> + *      of this type may still be returned at any time with the
> + *      BLKIF_RSP_EOPNOTSUPP result code.
> + *
> + *------------------------- Backend Device Properties -------------------------
> + *
> + * discard-aligment
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Notes:          1, 2
> + *
> + *      The offset, in bytes from the beginning of the virtual block device,
> + *      to the first, addressable, discard extent on the underlying device.

You are also missing the rest of the information about it. Please include the
details that the previous comment had.

> + *
> + * discard-granularity
> + *      Values:         <uint32_t>
> + *      Default Value:  <"sector-size">
> + *      Notes:          1
> + *
> + *      The size, in bytes, of the individually addressable discard extents
> + *      of the underlying device.

Please include more data - the old comment had more contents.

> + *
> + * discard-secure
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
> + *      requests with the BLKIF_DISCARD_SECURE flag set.


That is not very specific to what this does. It just says X will do Y.


> + *
> + * info
> + *      Values:         <uint32_t> (bitmap)
> + *
> + *      A collection of bit flags describing attributes of the backing
> + *      device.  The VDISK_* macros define the meaning of each bit
> + *      location.
> + *
> + * sector-size
> + *      Values:         <uint32_t>
> + *
> + *      The native sector size, in bytes, of the backend device.
> + *
> + * sectors
> + *      Values:         <uint64_t>
> + *
> + *      The size of the backend device, expressed in units of its native
> + *      sector size ("sector-size").
> + *
> + *****************************************************************************
> + *                            Frontend XenBus Nodes
> + *****************************************************************************
> + *
> + *----------------------- Request Transport Parameters -----------------------
> + *
> + * event-channel
> + *      Values:         <uint32_t>
> + *
> + *      The identifier of the Xen event channel used to signal activity
> + *      in the ring buffer.
> + *
> + * ring-ref
> + *      Values:         <uint32_t>
> + *
> + *      The Xen grant reference granting permission for the backend to map
> + *      the sole page in a single page sized ring buffer.
> + *
> + * protocol
> + *      Values:         string (XEN_IO_PROTO_ABI_*)
> + *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
> + *
> + *      The machine ABI rules governing the format of all ring request and
> + *      response structures.
> + *
> + *------------------------- Virtual Device Properties -------------------------
> + *
> + * device-type
> + *      Values:         "disk", "cdrom", "floppy", etc.
> + *
> + * virtual-device
> + *      Values:         <uint32_t>
> + *
> + *      A value indicating the physical device to virtualize within the
> + *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
> + *      disk", etc.)
> + *
> + *      See docs/misc/vbd-interface.txt for details on the format of this
> + *      value.
> + *
> + * Notes
> + * -----
> + * (1) Devices that support discard functionality may internally allocate
> + *     space (discardable extents) in units that are larger than the
> + *     exported logical block size.
> + * (2) The discard-alignment parameter allows a physical device to be
> + *     partitioned into virtual devices that do not necessarily begin or
> + *     end on a discardable extent boundary.
> + */
> +
> +/*
> + * STATE DIAGRAMS
> + *
> + *****************************************************************************
> + *                                   Startup                                 *
> + *****************************************************************************
> + *
> + * Tool stack creates front and back nodes with state XenbusStateInitialising.
> + *
> + * Front                                Back
> + * =================================    =====================================
> + * XenbusStateInitialising              XenbusStateInitialising
> + *  o Query virtual device               o Query backend device identification
> + *    properties.                          data.
> + *  o Setup OS device instance.          o Open and validate backend device.
> + *                                       o Publish backend features.
> + *                                                      |
> + *                                                      |
> + *                                                      V
> + *                                      XenbusStateInitWait
> + *
> + * o Query backend features.
> + * o Allocate and initialize the
> + *   request ring.
> + *              |
> + *              |
> + *              V
> + * XenbusStateInitialised
> + *
> + *                                       o Connect to the request ring and
> + *                                         event channel.
> + *                                       o Publish backend device properties.
> + *                                                      |
> + *                                                      |
> + *                                                      V
> + *                                      XenbusStateConnected
> + *
> + *  o Query backend device properties.
> + *  o Finalize OS virtual device
> + *    instance.
> + *              |
> + *              |
> + *              V
> + * XenbusStateConnected
> + *
> + * Note: Drivers that do not support any optional features can skip certain
> + *       states in the state machine:
> + *
> + *       o A frontend may transition to XenbusStateInitialised without
> + *         waiting for the backend to enter XenbusStateInitWait.
> + *
> + *       o A backend may transition to XenbusStateInitialised, bypassing
> + *         XenbusStateInitWait, without waiting for the frontend to first
> + *         enter the XenbusStateInitialised state.
> + *
> + *       Drivers that support optional features must tolerate these additional
> + *       state transition paths.  In general this means performing the work of
> + *       any skipped state transition, if it has not already been performed,
> + *       in addition to the work associated with entry into the current state.
> + */
> +
> +/*
>   * REQUEST CODES.
>   */
>  #define BLKIF_OP_READ              0
>  #define BLKIF_OP_WRITE             1
>  /*
> - * Recognised only if "feature-barrier" is present in backend xenbus info.
> - * The "feature-barrier" node contains a boolean indicating whether barrier
> - * requests are likely to succeed or fail. Either way, a barrier request
> - * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
> - * the underlying block-device hardware. The boolean simply indicates whether
> - * or not it is worthwhile for the frontend to attempt barrier requests.
> - * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
> - * create the "feature-barrier" node!
> + * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
> + * operation code ("barrier request") must be completed prior to the
> + * execution of the barrier request.  All writes issued after the barrier
> + * request must not execute until after the completion of the barrier request.
> + *
> + * Optional.  See "feature-barrier" XenBus node documentation above.
>   */
>  #define BLKIF_OP_WRITE_BARRIER     2
>  /*
> - * Recognised if "feature-flush-cache" is present in backend xenbus
> - * info.  A flush will ask the underlying storage hardware to flush its
> - * non-volatile caches as appropriate.  The "feature-flush-cache" node
> - * contains a boolean indicating whether flush requests are likely to
> - * succeed or fail. Either way, a flush request may fail at any time
> - * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
> - * block-device hardware. The boolean simply indicates whether or not it
> - * is worthwhile for the frontend to attempt flushes.  If a backend does
> - * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
> - * "feature-flush-cache" node!
> + * Commit any uncommitted contents of the backing device's volatile cache
> + * to stable storage.
> + *
> + * Optional.  See "feature-flush-cache" XenBus node documentation above.
>   */
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
>  /*
> @@ -82,47 +304,24 @@
>   */
>  #define BLKIF_OP_RESERVED_1        4
>  /*
> - * Recognised only if "feature-discard" is present in backend xenbus info.
> - * The "feature-discard" node contains a boolean indicating whether trim
> - * (ATA) or unmap (SCSI) - conviently called discard requests are likely
> - * to succeed or fail. Either way, a discard request
> - * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
> - * the underlying block-device hardware. The boolean simply indicates whether
> - * or not it is worthwhile for the frontend to attempt discard requests.
> - * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
> - * create the "feature-discard" node!
> + * Indicate to the backend device that a region of storage is no longer in
> + * use, and may be discarded at any time without impact to the client.  If
> + * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
> + * discarded region on the device must be rendered unrecoverable before the
> + * command returns.
>   *
> - * Discard operation is a request for the underlying block device to mark
> - * extents to be erased. However, discard does not guarantee that the blocks
> - * will be erased from the device - it is just a hint to the device
> - * controller that these blocks are no longer in use. What the device
> - * controller does with that information is left to the controller.
> - * Discard operations are passed with sector_number as the
> - * sector index to begin discard operations at and nr_sectors as the number of
> - * sectors to be discarded. The specified sectors should be discarded if the
> - * underlying block device supports trim (ATA) or unmap (SCSI) operations,
> - * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
> - * More information about trim/unmap operations at:
> + * This operation is analogous to performing a trim (ATA) or unamp (SCSI),

unmap.

> + * command on a native device.

And you might want to mention what the previous comment did - that this is
a hint to the backend.

> + *
> + * More information about trim/unmap operations can be found at:
>   * http://t13.org/Documents/UploadedDocuments/docs2008/
>   *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
>   * http://www.seagate.com/staticfiles/support/disc/manuals/
>   *     Interface%20manuals/100293068c.pdf
> - * The backend can optionally provide these extra XenBus attributes to
> - * further optimize the discard functionality:
> - * 'discard-aligment' - Devices that support discard functionality may
> - * internally allocate space in units that are bigger than the exported
> - * logical block size. The discard-alignment parameter indicates how many bytes
> - * the beginning of the partition is offset from the internal allocation unit's
> - * natural alignment. Do not confuse this with natural disk alignment offset.
> - * 'discard-granularity'  - Devices that support discard functionality may
> - * internally allocate space using units that are bigger than the logical block
> - * size. The discard-granularity parameter indicates the size of the internal
> - * allocation unit in bytes if reported by the device. Otherwise the
> - * discard-granularity will be set to match the device's physical block size.
> - * It is the minimum size you can discard.
> - * 'discard-secure' - All copies of the discarded sectors (potentially created
> - * by garbage collection) must also be erased.  To use this feature, the flag
> - * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
> + *
> + * Optional.  See "feature-discard", "discard-alignment",
> + * "discard-granularity", and "discard-secure" in the XenBus node
> + * documentation above.
>   */
>  #define BLKIF_OP_DISCARD           5
>  
> @@ -147,6 +346,9 @@ struct blkif_request_segment {
>      uint8_t     first_sect, last_sect;
>  };
>  
> +/*
> + * Starting ring element for any I/O request.
> + */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
>      uint8_t        nr_segments;  /* number of segments                   */
> @@ -158,7 +360,7 @@ struct blkif_request {
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> - * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
> + * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
>  struct blkif_request_discard {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:14:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:14:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqTo-0007Aa-OD; Tue, 21 Feb 2012 14:14: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 1RzqTn-0007AO-6g
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:14:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329833599!53331431!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24533 invoked from network); 21 Feb 2012 14:13:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 14:13:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LEDvKb018830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:13:58 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
	q1LEDuPr027578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:13:57 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
	q1LEDt1I000709; Tue, 21 Feb 2012 08:13:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:13:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AF1BC40469; Tue, 21 Feb 2012 09:10:41 -0500 (EST)
Date: Tue, 21 Feb 2012 09:10:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221141041.GC11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F43A6A7.008D,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 11:07:23AM -0700, Justin T. Gibbs wrote:
>   o Document the XenBus nodes used in this protocol.
>   o Add a state diagram illustrating the roles and responsibilities
>     of both the front and backend during startup.
>   o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
> 
> No functional changes.

Some comments below.

> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 28137a4e39a3 -r e79902456819 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> @@ -22,6 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   *
>   * Copyright (c) 2003-2004, Keir Fraser
> + * Copyright (c) 2012, Spectra Logic Corporation
>   */
>  
>  #ifndef __XEN_PUBLIC_IO_BLKIF_H__
> @@ -48,32 +49,253 @@
>  #define blkif_sector_t uint64_t
>  
>  /*
> + * Feature and Parameter Negotiation
> + * =================================
> + * The two halves of a Xen block driver utilize nodes within the XenStore to
> + * communicate capabilities and to negotiate operating parameters.  This
> + * section enumerates these nodes which reside in the respective front and
> + * backend portions of the XenStore, following the XenBus convention.
> + *
> + * All data in the XenStore is stored as strings.  Nodes specifying numeric
> + * values are encoded in decimal.  Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.
> + *
> + * Any specified default value is in effect if the corresponding XenBus node
> + * is not present in the XenStore.
> + *
> + * XenStore nodes in sections marked "PRIVATE" are solely for use by the
> + * driver side whose XenBus tree contains them.
> + *
> + * See the XenBus state transition diagram below for details on when XenBus
> + * nodes must be published and when they can be queried.
> + *
> + *****************************************************************************
> + *                            Backend XenBus Nodes
> + *****************************************************************************
> + *
> + *------------------ Backend Device Identification (PRIVATE) ------------------
> + *
> + * mode
> + *      Values:         "r" (read only), "w" (writable)
> + *
> + *      The read or write access permissions to the backing store to be
> + *      granted to the frontend.
> + *
> + * params
> + *      Values:         string
> + *
> + *      A free formatted string providing sufficient information for the
> + *      backend driver to open the backing device.  (e.g. the path to the
> + *      file or block device representing the backing store.)
> + *
> + * type
> + *      Values:         "file", "phy", "tap"
> + *
> + *      The type of the backing device/object.
> + *
> + *--------------------------------- Features ---------------------------------
> + *
> + * feature-barrier
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process requests
> + *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
> + *      of this type may still be returned at any time with the
> + *      BLKIF_RSP_EOPNOTSUPP result code.
> + *
> + * feature-flush-cache
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process requests
> + *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
> + *      of this type may still be returned at any time with the
> + *      BLKIF_RSP_EOPNOTSUPP result code.
> + *
> + * feature-discard
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process requests
> + *      containing the BLKIF_OP_DISCARD request opcode.  Requests
> + *      of this type may still be returned at any time with the
> + *      BLKIF_RSP_EOPNOTSUPP result code.
> + *
> + *------------------------- Backend Device Properties -------------------------
> + *
> + * discard-aligment
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Notes:          1, 2
> + *
> + *      The offset, in bytes from the beginning of the virtual block device,
> + *      to the first, addressable, discard extent on the underlying device.

You are also missing the rest of the information about it. Please include the
details that the previous comment had.

> + *
> + * discard-granularity
> + *      Values:         <uint32_t>
> + *      Default Value:  <"sector-size">
> + *      Notes:          1
> + *
> + *      The size, in bytes, of the individually addressable discard extents
> + *      of the underlying device.

Please include more data - the old comment had more contents.

> + *
> + * discard-secure
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *
> + *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
> + *      requests with the BLKIF_DISCARD_SECURE flag set.


That is not very specific to what this does. It just says X will do Y.


> + *
> + * info
> + *      Values:         <uint32_t> (bitmap)
> + *
> + *      A collection of bit flags describing attributes of the backing
> + *      device.  The VDISK_* macros define the meaning of each bit
> + *      location.
> + *
> + * sector-size
> + *      Values:         <uint32_t>
> + *
> + *      The native sector size, in bytes, of the backend device.
> + *
> + * sectors
> + *      Values:         <uint64_t>
> + *
> + *      The size of the backend device, expressed in units of its native
> + *      sector size ("sector-size").
> + *
> + *****************************************************************************
> + *                            Frontend XenBus Nodes
> + *****************************************************************************
> + *
> + *----------------------- Request Transport Parameters -----------------------
> + *
> + * event-channel
> + *      Values:         <uint32_t>
> + *
> + *      The identifier of the Xen event channel used to signal activity
> + *      in the ring buffer.
> + *
> + * ring-ref
> + *      Values:         <uint32_t>
> + *
> + *      The Xen grant reference granting permission for the backend to map
> + *      the sole page in a single page sized ring buffer.
> + *
> + * protocol
> + *      Values:         string (XEN_IO_PROTO_ABI_*)
> + *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
> + *
> + *      The machine ABI rules governing the format of all ring request and
> + *      response structures.
> + *
> + *------------------------- Virtual Device Properties -------------------------
> + *
> + * device-type
> + *      Values:         "disk", "cdrom", "floppy", etc.
> + *
> + * virtual-device
> + *      Values:         <uint32_t>
> + *
> + *      A value indicating the physical device to virtualize within the
> + *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
> + *      disk", etc.)
> + *
> + *      See docs/misc/vbd-interface.txt for details on the format of this
> + *      value.
> + *
> + * Notes
> + * -----
> + * (1) Devices that support discard functionality may internally allocate
> + *     space (discardable extents) in units that are larger than the
> + *     exported logical block size.
> + * (2) The discard-alignment parameter allows a physical device to be
> + *     partitioned into virtual devices that do not necessarily begin or
> + *     end on a discardable extent boundary.
> + */
> +
> +/*
> + * STATE DIAGRAMS
> + *
> + *****************************************************************************
> + *                                   Startup                                 *
> + *****************************************************************************
> + *
> + * Tool stack creates front and back nodes with state XenbusStateInitialising.
> + *
> + * Front                                Back
> + * =================================    =====================================
> + * XenbusStateInitialising              XenbusStateInitialising
> + *  o Query virtual device               o Query backend device identification
> + *    properties.                          data.
> + *  o Setup OS device instance.          o Open and validate backend device.
> + *                                       o Publish backend features.
> + *                                                      |
> + *                                                      |
> + *                                                      V
> + *                                      XenbusStateInitWait
> + *
> + * o Query backend features.
> + * o Allocate and initialize the
> + *   request ring.
> + *              |
> + *              |
> + *              V
> + * XenbusStateInitialised
> + *
> + *                                       o Connect to the request ring and
> + *                                         event channel.
> + *                                       o Publish backend device properties.
> + *                                                      |
> + *                                                      |
> + *                                                      V
> + *                                      XenbusStateConnected
> + *
> + *  o Query backend device properties.
> + *  o Finalize OS virtual device
> + *    instance.
> + *              |
> + *              |
> + *              V
> + * XenbusStateConnected
> + *
> + * Note: Drivers that do not support any optional features can skip certain
> + *       states in the state machine:
> + *
> + *       o A frontend may transition to XenbusStateInitialised without
> + *         waiting for the backend to enter XenbusStateInitWait.
> + *
> + *       o A backend may transition to XenbusStateInitialised, bypassing
> + *         XenbusStateInitWait, without waiting for the frontend to first
> + *         enter the XenbusStateInitialised state.
> + *
> + *       Drivers that support optional features must tolerate these additional
> + *       state transition paths.  In general this means performing the work of
> + *       any skipped state transition, if it has not already been performed,
> + *       in addition to the work associated with entry into the current state.
> + */
> +
> +/*
>   * REQUEST CODES.
>   */
>  #define BLKIF_OP_READ              0
>  #define BLKIF_OP_WRITE             1
>  /*
> - * Recognised only if "feature-barrier" is present in backend xenbus info.
> - * The "feature-barrier" node contains a boolean indicating whether barrier
> - * requests are likely to succeed or fail. Either way, a barrier request
> - * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
> - * the underlying block-device hardware. The boolean simply indicates whether
> - * or not it is worthwhile for the frontend to attempt barrier requests.
> - * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
> - * create the "feature-barrier" node!
> + * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
> + * operation code ("barrier request") must be completed prior to the
> + * execution of the barrier request.  All writes issued after the barrier
> + * request must not execute until after the completion of the barrier request.
> + *
> + * Optional.  See "feature-barrier" XenBus node documentation above.
>   */
>  #define BLKIF_OP_WRITE_BARRIER     2
>  /*
> - * Recognised if "feature-flush-cache" is present in backend xenbus
> - * info.  A flush will ask the underlying storage hardware to flush its
> - * non-volatile caches as appropriate.  The "feature-flush-cache" node
> - * contains a boolean indicating whether flush requests are likely to
> - * succeed or fail. Either way, a flush request may fail at any time
> - * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
> - * block-device hardware. The boolean simply indicates whether or not it
> - * is worthwhile for the frontend to attempt flushes.  If a backend does
> - * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
> - * "feature-flush-cache" node!
> + * Commit any uncommitted contents of the backing device's volatile cache
> + * to stable storage.
> + *
> + * Optional.  See "feature-flush-cache" XenBus node documentation above.
>   */
>  #define BLKIF_OP_FLUSH_DISKCACHE   3
>  /*
> @@ -82,47 +304,24 @@
>   */
>  #define BLKIF_OP_RESERVED_1        4
>  /*
> - * Recognised only if "feature-discard" is present in backend xenbus info.
> - * The "feature-discard" node contains a boolean indicating whether trim
> - * (ATA) or unmap (SCSI) - conviently called discard requests are likely
> - * to succeed or fail. Either way, a discard request
> - * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
> - * the underlying block-device hardware. The boolean simply indicates whether
> - * or not it is worthwhile for the frontend to attempt discard requests.
> - * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
> - * create the "feature-discard" node!
> + * Indicate to the backend device that a region of storage is no longer in
> + * use, and may be discarded at any time without impact to the client.  If
> + * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
> + * discarded region on the device must be rendered unrecoverable before the
> + * command returns.
>   *
> - * Discard operation is a request for the underlying block device to mark
> - * extents to be erased. However, discard does not guarantee that the blocks
> - * will be erased from the device - it is just a hint to the device
> - * controller that these blocks are no longer in use. What the device
> - * controller does with that information is left to the controller.
> - * Discard operations are passed with sector_number as the
> - * sector index to begin discard operations at and nr_sectors as the number of
> - * sectors to be discarded. The specified sectors should be discarded if the
> - * underlying block device supports trim (ATA) or unmap (SCSI) operations,
> - * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
> - * More information about trim/unmap operations at:
> + * This operation is analogous to performing a trim (ATA) or unamp (SCSI),

unmap.

> + * command on a native device.

And you might want to mention what the previous comment did - that this is
a hint to the backend.

> + *
> + * More information about trim/unmap operations can be found at:
>   * http://t13.org/Documents/UploadedDocuments/docs2008/
>   *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
>   * http://www.seagate.com/staticfiles/support/disc/manuals/
>   *     Interface%20manuals/100293068c.pdf
> - * The backend can optionally provide these extra XenBus attributes to
> - * further optimize the discard functionality:
> - * 'discard-aligment' - Devices that support discard functionality may
> - * internally allocate space in units that are bigger than the exported
> - * logical block size. The discard-alignment parameter indicates how many bytes
> - * the beginning of the partition is offset from the internal allocation unit's
> - * natural alignment. Do not confuse this with natural disk alignment offset.
> - * 'discard-granularity'  - Devices that support discard functionality may
> - * internally allocate space using units that are bigger than the logical block
> - * size. The discard-granularity parameter indicates the size of the internal
> - * allocation unit in bytes if reported by the device. Otherwise the
> - * discard-granularity will be set to match the device's physical block size.
> - * It is the minimum size you can discard.
> - * 'discard-secure' - All copies of the discarded sectors (potentially created
> - * by garbage collection) must also be erased.  To use this feature, the flag
> - * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
> + *
> + * Optional.  See "feature-discard", "discard-alignment",
> + * "discard-granularity", and "discard-secure" in the XenBus node
> + * documentation above.
>   */
>  #define BLKIF_OP_DISCARD           5
>  
> @@ -147,6 +346,9 @@ struct blkif_request_segment {
>      uint8_t     first_sect, last_sect;
>  };
>  
> +/*
> + * Starting ring element for any I/O request.
> + */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
>      uint8_t        nr_segments;  /* number of segments                   */
> @@ -158,7 +360,7 @@ struct blkif_request {
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> - * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
> + * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
>  struct blkif_request_discard {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:14:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqU1-0007BX-5V; Tue, 21 Feb 2012 14:14:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzqTz-0007Az-Mu
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:14:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329833652!15160025!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6674 invoked from network); 21 Feb 2012 14:14:13 -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; 21 Feb 2012 14:14:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LEEAsB015645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:14:11 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
	q1LEE6tB022343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:14:10 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
	q1LEE6kS016309; Tue, 21 Feb 2012 08:14:06 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:14:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADCF440469; Tue, 21 Feb 2012 09:10:52 -0500 (EST)
Date: Tue, 21 Feb 2012 09:10:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221141052.GD11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090206.4F43A6B3.01D3,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 4 v3] blkif.h: Miscelaneous style 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, Feb 20, 2012 at 11:07:22AM -0700, Justin T. Gibbs wrote:
>   o Remove trailing whitespace.
>   o Remove a blank line so that a comment block is adjacent to the
>     code it documents.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

OK, looks good.
> 
> diff -r 87218bd367be -r 28137a4e39a3 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Fri Feb 17 12:24:38 2012 +0000
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * blkif.h
> - * 
> + *
>   * Unified block-device I/O interface for Xen guest OSes.
> - * 
> + *
>   * 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
> @@ -35,7 +35,7 @@
>   * notification can be made conditional on req_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Backends must set
>   * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
> - * 
> + *
>   * Back->front notifications: When enqueuing a new response, sending a
>   * notification can be made conditional on rsp_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Frontends must set
> @@ -133,7 +133,7 @@
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> -/* 
> +/*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
>   * sector_number in blkif_request, are always expressed in 512-byte units.
>   * However they must be properly aligned to the real sector size of the
> @@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
>  /*
>   * Generate blkif ring structures and types.
>   */
> -
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
>  #define VDISK_CDROM        0x1
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:14:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqU1-0007BX-5V; Tue, 21 Feb 2012 14:14:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzqTz-0007Az-Mu
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:14:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329833652!15160025!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6674 invoked from network); 21 Feb 2012 14:14:13 -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; 21 Feb 2012 14:14:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LEEAsB015645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:14:11 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
	q1LEE6tB022343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:14:10 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
	q1LEE6kS016309; Tue, 21 Feb 2012 08:14:06 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:14:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADCF440469; Tue, 21 Feb 2012 09:10:52 -0500 (EST)
Date: Tue, 21 Feb 2012 09:10:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221141052.GD11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090206.4F43A6B3.01D3,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 4 v3] blkif.h: Miscelaneous style 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, Feb 20, 2012 at 11:07:22AM -0700, Justin T. Gibbs wrote:
>   o Remove trailing whitespace.
>   o Remove a blank line so that a comment block is adjacent to the
>     code it documents.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

OK, looks good.
> 
> diff -r 87218bd367be -r 28137a4e39a3 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Fri Feb 17 12:24:38 2012 +0000
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * blkif.h
> - * 
> + *
>   * Unified block-device I/O interface for Xen guest OSes.
> - * 
> + *
>   * 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
> @@ -35,7 +35,7 @@
>   * notification can be made conditional on req_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Backends must set
>   * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
> - * 
> + *
>   * Back->front notifications: When enqueuing a new response, sending a
>   * notification can be made conditional on rsp_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Frontends must set
> @@ -133,7 +133,7 @@
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> -/* 
> +/*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
>   * sector_number in blkif_request, are always expressed in 512-byte units.
>   * However they must be properly aligned to the real sector size of the
> @@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
>  /*
>   * Generate blkif ring structures and types.
>   */
> -
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
>  #define VDISK_CDROM        0x1
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqU4-0007CH-Hc; Tue, 21 Feb 2012 14:14:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RzqU2-0007BC-Dt
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 14:14:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329833655!12455735!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17758 invoked from network); 21 Feb 2012 14:14:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 14:14:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 14:14:15 +0000
Message-Id: <4F43B4C40200007800074350@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 14:14:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
In-Reply-To: <20120220183207.GA7170@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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 20.02.12 at 19:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> And only on Intel.. and only if it is a 32-bit dom0. If I do the same test 
> with a 64-bit dom0 I do not see this problem.
> 
> Any thoughts of what it might be or what I should try out? My thought
> was to swap out the hypervisor (use a Xen 4.0) or unstable and see if I get 
> the same result.
> But maybe there is something obvious out there?

Did you check that it's not the kernel image itself on that particular box
that's corrupted?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqU4-0007CH-Hc; Tue, 21 Feb 2012 14:14:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RzqU2-0007BC-Dt
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 14:14:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329833655!12455735!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17758 invoked from network); 21 Feb 2012 14:14:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 14:14:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 21 Feb 2012 14:14:15 +0000
Message-Id: <4F43B4C40200007800074350@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 21 Feb 2012 14:14:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
In-Reply-To: <20120220183207.GA7170@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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 20.02.12 at 19:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> And only on Intel.. and only if it is a 32-bit dom0. If I do the same test 
> with a 64-bit dom0 I do not see this problem.
> 
> Any thoughts of what it might be or what I should try out? My thought
> was to swap out the hypervisor (use a Xen 4.0) or unstable and see if I get 
> the same result.
> But maybe there is something obvious out there?

Did you check that it's not the kernel image itself on that particular box
that's corrupted?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqVg-0007PB-2K; Tue, 21 Feb 2012 14:16:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqVf-0007Ob-Ew
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:16:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329833756!14284723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4614 invoked from network); 21 Feb 2012 14:15: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;
	21 Feb 2012 14:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14: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.213.0;
	Tue, 21 Feb 2012 14:15:39 +0000
Message-ID: <1329833737.3990.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:15:37 +0000
In-Reply-To: <28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 4 v3] blkif.h: Miscelaneous style 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, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> o Remove trailing whitespace.
>   o Remove a blank line so that a comment block is adjacent to the
>     code it documents.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 87218bd367be -r 28137a4e39a3 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Fri Feb 17 12:24:38 2012 +0000
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * blkif.h
> - * 
> + *
>   * Unified block-device I/O interface for Xen guest OSes.
> - * 
> + *
>   * 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
> @@ -35,7 +35,7 @@
>   * notification can be made conditional on req_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Backends must set
>   * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
> - * 
> + *
>   * Back->front notifications: When enqueuing a new response, sending a
>   * notification can be made conditional on rsp_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Frontends must set
> @@ -133,7 +133,7 @@
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> -/* 
> +/*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
>   * sector_number in blkif_request, are always expressed in 512-byte units.
>   * However they must be properly aligned to the real sector size of the
> @@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
>  /*
>   * Generate blkif ring structures and types.
>   */
> -
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
>  #define VDISK_CDROM        0x1
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:16:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqVg-0007PB-2K; Tue, 21 Feb 2012 14:16:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqVf-0007Ob-Ew
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:16:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329833756!14284723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4614 invoked from network); 21 Feb 2012 14:15: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;
	21 Feb 2012 14:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14: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.213.0;
	Tue, 21 Feb 2012 14:15:39 +0000
Message-ID: <1329833737.3990.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:15:37 +0000
In-Reply-To: <28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<28137a4e39a3ed61511f.1329761242@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 4 v3] blkif.h: Miscelaneous style 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, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> o Remove trailing whitespace.
>   o Remove a blank line so that a comment block is adjacent to the
>     code it documents.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 87218bd367be -r 28137a4e39a3 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Fri Feb 17 12:24:38 2012 +0000
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * blkif.h
> - * 
> + *
>   * Unified block-device I/O interface for Xen guest OSes.
> - * 
> + *
>   * 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
> @@ -35,7 +35,7 @@
>   * notification can be made conditional on req_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Backends must set
>   * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
> - * 
> + *
>   * Back->front notifications: When enqueuing a new response, sending a
>   * notification can be made conditional on rsp_event (i.e., the generic
>   * hold-off mechanism provided by the ring macros). Frontends must set
> @@ -133,7 +133,7 @@
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> -/* 
> +/*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
>   * sector_number in blkif_request, are always expressed in 512-byte units.
>   * However they must be properly aligned to the real sector size of the
> @@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
>  /*
>   * Generate blkif ring structures and types.
>   */
> -
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
>  #define VDISK_CDROM        0x1
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1RzqVv-0007SV-MD; Tue, 21 Feb 2012 14:16:19 +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 1RzqVt-0007RR-Hv
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:16:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329833717!50125378!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15405 invoked from network); 21 Feb 2012 14:15:19 -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; 21 Feb 2012 14:15:19 -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 q1LEGAIN021119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:16:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1LEG9Q8028529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:16:10 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
	q1LEG81D002294; Tue, 21 Feb 2012 08:16:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:16:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AB8C240469; Tue, 21 Feb 2012 09:12:54 -0500 (EST)
Date: Tue, 21 Feb 2012 09:12:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221141254.GE11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F43A72B.0159,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 4 v3] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring 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 Mon, Feb 20, 2012 at 11:07:24AM -0700, Justin T. Gibbs wrote:
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r e79902456819 -r 09051133e2fe xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> @@ -67,6 +67,9 @@
>   * XenStore nodes in sections marked "PRIVATE" are solely for use by the
>   * driver side whose XenBus tree contains them.
>   *
> + * XenStore nodes marked "DEPRECATED" in their notes section should only be
> + * used to provide interoperability with legacy implementations.
> + *
>   * See the XenBus state transition diagram below for details on when XenBus
>   * nodes must be published and when they can be queried.
>   *
> @@ -123,12 +126,31 @@
>   *      of this type may still be returned at any time with the
>   *      BLKIF_RSP_EOPNOTSUPP result code.
>   *
> + *----------------------- Request Transport Parameters ------------------------
> + *
> + * max-ring-page-order
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Notes:          1, 3
> + *
> + *      The maximum supported size of the request ring buffer in units of
> + *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
> + *      etc.).
> + *
> + * max-ring-pages
> + *      Values:         <uint32_t>
> + *      Default Value:  1
> + *      Notes:          DEPRECATED, 2, 3
> + *
> + *      The maximum supported size of the request ring buffer in units of
> + *      machine pages.  The value must be a power of 2.
> + *
>   *------------------------- Backend Device Properties -------------------------
>   *
>   * discard-aligment
>   *      Values:         <uint32_t>
>   *      Default Value:  0
> - *      Notes:          1, 2
> + *      Notes:          4, 5
>   *
>   *      The offset, in bytes from the beginning of the virtual block device,
>   *      to the first, addressable, discard extent on the underlying device.
> @@ -136,7 +158,7 @@
>   * discard-granularity
>   *      Values:         <uint32_t>
>   *      Default Value:  <"sector-size">
> - *      Notes:          1
> + *      Notes:          4
>   *
>   *      The size, in bytes, of the individually addressable discard extents
>   *      of the underlying device.
> @@ -180,10 +202,20 @@
>   *
>   * ring-ref
>   *      Values:         <uint32_t>
> + *      Notes:          6
>   *
>   *      The Xen grant reference granting permission for the backend to map
>   *      the sole page in a single page sized ring buffer.
>   *
> + * ring-ref%u
> + *      Values:         <uint32_t>
> + *      Notes:          6
> + *
> + *      For a frontend providing a multi-page ring, a "number of ring pages"
> + *      sized list of nodes, each containing a Xen grant reference granting
> + *      permission for the backend to map the page of the ring located
> + *      at page index "%u".  Page indexes are zero based.
> + *
>   * protocol
>   *      Values:         string (XEN_IO_PROTO_ABI_*)
>   *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
> @@ -191,6 +223,25 @@
>   *      The machine ABI rules governing the format of all ring request and
>   *      response structures.
>   *
> + * ring-page-order
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> + *      Notes:          1, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units
> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> + *      etc.).
> + *
> + * num-ring-pages
> + *      Values:         <uint32_t>
> + *      Default Value:  1
> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> + *      Notes:          DEPRECATED, 2, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units of
> + *      machine pages.  The value must be a power of 2.
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -208,12 +259,26 @@
>   *
>   * Notes
>   * -----
> - * (1) Devices that support discard functionality may internally allocate
> + * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
> + *     PV drivers.
> + * (2) Multi-page ring buffer scheme first used in some RedHat distributions

Red Hat.

> + *     including a distribution deployed on certain nodes of the Amazon
> + *     EC2 cluster.
> + * (3) Support for multi-page ring buffers was implemented independently,
> + *     in slightly different forms, by both Citrix and RedHat/Amazon.

Red Hat.

> + *     For full interoperability, block front and backends should publish
> + *     identical ring parameters, adjusted for unit differences, to the
> + *     XenStore nodes used in both schemes.
> + * (4) Devices that support discard functionality may internally allocate
>   *     space (discardable extents) in units that are larger than the
>   *     exported logical block size.
> - * (2) The discard-alignment parameter allows a physical device to be
> + * (5) The discard-alignment parameter allows a physical device to be
>   *     partitioned into virtual devices that do not necessarily begin or
>   *     end on a discardable extent boundary.
> + * (6) When there is only a single page allocated to the request ring,
> + *     'ring-ref' is used to communicate the grant reference for this
> + *     page to the backend.  When using a multi-page ring, the 'ring-ref'
> + *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
>   */
>  
>  /*
> @@ -231,20 +296,26 @@
>   *  o Query virtual device               o Query backend device identification
>   *    properties.                          data.
>   *  o Setup OS device instance.          o Open and validate backend device.
> - *                                       o Publish backend features.
> + *                                       o Publish backend features and
> + *                                         transport parameters.
>   *                                                      |
>   *                                                      |
>   *                                                      V
>   *                                      XenbusStateInitWait
>   *
> - * o Query backend features.
> + * o Query backend features and
> + *   transport parameters.
>   * o Allocate and initialize the
>   *   request ring.
> + * o Publish transport parameters
> + *   that will be in effect during
> + *   this connection.
>   *              |
>   *              |
>   *              V
>   * XenbusStateInitialised
>   *
> + *                                       o Query frontend transport parameters.
>   *                                       o Connect to the request ring and
>   *                                         event channel.
>   *                                       o Publish backend device properties.
> @@ -261,20 +332,26 @@
>   *              V
>   * XenbusStateConnected
>   *
> - * Note: Drivers that do not support any optional features can skip certain
> - *       states in the state machine:
> + * Note: Drivers that do not support any optional features, or the negotiation
> + *       of transport parameters, can skip certain states in the state machine:
>   *
>   *       o A frontend may transition to XenbusStateInitialised without
> - *         waiting for the backend to enter XenbusStateInitWait.
> + *         waiting for the backend to enter XenbusStateInitWait.  In this
> + *         case, default transport parameters are in effect and any
> + *         transport parameters published by the frontend must contain
> + *         their default values.
>   *
>   *       o A backend may transition to XenbusStateInitialised, bypassing
>   *         XenbusStateInitWait, without waiting for the frontend to first
> - *         enter the XenbusStateInitialised state.
> + *         enter the XenbusStateInitialised state.  In this case, default
> + *         transport parameters are in effect and any transport parameters
> + *         published by the backend must contain their default values.
>   *
> - *       Drivers that support optional features must tolerate these additional
> - *       state transition paths.  In general this means performing the work of
> - *       any skipped state transition, if it has not already been performed,
> - *       in addition to the work associated with entry into the current state.
> + *       Drivers that support optional features and/or transport parameter
> + *       negotiation must tolerate these additional state transition paths.
> + *       In general this means performing the work of any skipped state
> + *       transition, if it has not already been performed, in addition to the
> + *       work associated with entry into the current state.
>   */
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 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 1RzqVv-0007SV-MD; Tue, 21 Feb 2012 14:16:19 +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 1RzqVt-0007RR-Hv
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:16:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329833717!50125378!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15405 invoked from network); 21 Feb 2012 14:15:19 -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; 21 Feb 2012 14:15:19 -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 q1LEGAIN021119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:16:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1LEG9Q8028529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:16:10 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
	q1LEG81D002294; Tue, 21 Feb 2012 08:16:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:16:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AB8C240469; Tue, 21 Feb 2012 09:12:54 -0500 (EST)
Date: Tue, 21 Feb 2012 09:12:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221141254.GE11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F43A72B.0159,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 4 v3] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring 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 Mon, Feb 20, 2012 at 11:07:24AM -0700, Justin T. Gibbs wrote:
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r e79902456819 -r 09051133e2fe xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 10:48:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> @@ -67,6 +67,9 @@
>   * XenStore nodes in sections marked "PRIVATE" are solely for use by the
>   * driver side whose XenBus tree contains them.
>   *
> + * XenStore nodes marked "DEPRECATED" in their notes section should only be
> + * used to provide interoperability with legacy implementations.
> + *
>   * See the XenBus state transition diagram below for details on when XenBus
>   * nodes must be published and when they can be queried.
>   *
> @@ -123,12 +126,31 @@
>   *      of this type may still be returned at any time with the
>   *      BLKIF_RSP_EOPNOTSUPP result code.
>   *
> + *----------------------- Request Transport Parameters ------------------------
> + *
> + * max-ring-page-order
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Notes:          1, 3
> + *
> + *      The maximum supported size of the request ring buffer in units of
> + *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
> + *      etc.).
> + *
> + * max-ring-pages
> + *      Values:         <uint32_t>
> + *      Default Value:  1
> + *      Notes:          DEPRECATED, 2, 3
> + *
> + *      The maximum supported size of the request ring buffer in units of
> + *      machine pages.  The value must be a power of 2.
> + *
>   *------------------------- Backend Device Properties -------------------------
>   *
>   * discard-aligment
>   *      Values:         <uint32_t>
>   *      Default Value:  0
> - *      Notes:          1, 2
> + *      Notes:          4, 5
>   *
>   *      The offset, in bytes from the beginning of the virtual block device,
>   *      to the first, addressable, discard extent on the underlying device.
> @@ -136,7 +158,7 @@
>   * discard-granularity
>   *      Values:         <uint32_t>
>   *      Default Value:  <"sector-size">
> - *      Notes:          1
> + *      Notes:          4
>   *
>   *      The size, in bytes, of the individually addressable discard extents
>   *      of the underlying device.
> @@ -180,10 +202,20 @@
>   *
>   * ring-ref
>   *      Values:         <uint32_t>
> + *      Notes:          6
>   *
>   *      The Xen grant reference granting permission for the backend to map
>   *      the sole page in a single page sized ring buffer.
>   *
> + * ring-ref%u
> + *      Values:         <uint32_t>
> + *      Notes:          6
> + *
> + *      For a frontend providing a multi-page ring, a "number of ring pages"
> + *      sized list of nodes, each containing a Xen grant reference granting
> + *      permission for the backend to map the page of the ring located
> + *      at page index "%u".  Page indexes are zero based.
> + *
>   * protocol
>   *      Values:         string (XEN_IO_PROTO_ABI_*)
>   *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
> @@ -191,6 +223,25 @@
>   *      The machine ABI rules governing the format of all ring request and
>   *      response structures.
>   *
> + * ring-page-order
> + *      Values:         <uint32_t>
> + *      Default Value:  0
> + *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
> + *      Notes:          1, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units
> + *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
> + *      etc.).
> + *
> + * num-ring-pages
> + *      Values:         <uint32_t>
> + *      Default Value:  1
> + *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
> + *      Notes:          DEPRECATED, 2, 3
> + *
> + *      The size of the frontend allocated request ring buffer in units of
> + *      machine pages.  The value must be a power of 2.
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -208,12 +259,26 @@
>   *
>   * Notes
>   * -----
> - * (1) Devices that support discard functionality may internally allocate
> + * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
> + *     PV drivers.
> + * (2) Multi-page ring buffer scheme first used in some RedHat distributions

Red Hat.

> + *     including a distribution deployed on certain nodes of the Amazon
> + *     EC2 cluster.
> + * (3) Support for multi-page ring buffers was implemented independently,
> + *     in slightly different forms, by both Citrix and RedHat/Amazon.

Red Hat.

> + *     For full interoperability, block front and backends should publish
> + *     identical ring parameters, adjusted for unit differences, to the
> + *     XenStore nodes used in both schemes.
> + * (4) Devices that support discard functionality may internally allocate
>   *     space (discardable extents) in units that are larger than the
>   *     exported logical block size.
> - * (2) The discard-alignment parameter allows a physical device to be
> + * (5) The discard-alignment parameter allows a physical device to be
>   *     partitioned into virtual devices that do not necessarily begin or
>   *     end on a discardable extent boundary.
> + * (6) When there is only a single page allocated to the request ring,
> + *     'ring-ref' is used to communicate the grant reference for this
> + *     page to the backend.  When using a multi-page ring, the 'ring-ref'
> + *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
>   */
>  
>  /*
> @@ -231,20 +296,26 @@
>   *  o Query virtual device               o Query backend device identification
>   *    properties.                          data.
>   *  o Setup OS device instance.          o Open and validate backend device.
> - *                                       o Publish backend features.
> + *                                       o Publish backend features and
> + *                                         transport parameters.
>   *                                                      |
>   *                                                      |
>   *                                                      V
>   *                                      XenbusStateInitWait
>   *
> - * o Query backend features.
> + * o Query backend features and
> + *   transport parameters.
>   * o Allocate and initialize the
>   *   request ring.
> + * o Publish transport parameters
> + *   that will be in effect during
> + *   this connection.
>   *              |
>   *              |
>   *              V
>   * XenbusStateInitialised
>   *
> + *                                       o Query frontend transport parameters.
>   *                                       o Connect to the request ring and
>   *                                         event channel.
>   *                                       o Publish backend device properties.
> @@ -261,20 +332,26 @@
>   *              V
>   * XenbusStateConnected
>   *
> - * Note: Drivers that do not support any optional features can skip certain
> - *       states in the state machine:
> + * Note: Drivers that do not support any optional features, or the negotiation
> + *       of transport parameters, can skip certain states in the state machine:
>   *
>   *       o A frontend may transition to XenbusStateInitialised without
> - *         waiting for the backend to enter XenbusStateInitWait.
> + *         waiting for the backend to enter XenbusStateInitWait.  In this
> + *         case, default transport parameters are in effect and any
> + *         transport parameters published by the frontend must contain
> + *         their default values.
>   *
>   *       o A backend may transition to XenbusStateInitialised, bypassing
>   *         XenbusStateInitWait, without waiting for the frontend to first
> - *         enter the XenbusStateInitialised state.
> + *         enter the XenbusStateInitialised state.  In this case, default
> + *         transport parameters are in effect and any transport parameters
> + *         published by the backend must contain their default values.
>   *
> - *       Drivers that support optional features must tolerate these additional
> - *       state transition paths.  In general this means performing the work of
> - *       any skipped state transition, if it has not already been performed,
> - *       in addition to the work associated with entry into the current state.
> + *       Drivers that support optional features and/or transport parameter
> + *       negotiation must tolerate these additional state transition paths.
> + *       In general this means performing the work of any skipped state
> + *       transition, if it has not already been performed, in addition to the
> + *       work associated with entry into the current state.
>   */
>  
>  /*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:25:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzqer-000896-08; Tue, 21 Feb 2012 14:25:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzqep-00088t-2y
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:25:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329834323!14291144!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4159 invoked from network); 21 Feb 2012 14:25: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; 21 Feb 2012 14:25:24 -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 q1LEPKWU027023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:25:21 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
	q1LEPJdT019655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:25:19 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
	q1LEPI6o013363; Tue, 21 Feb 2012 08:25:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:25:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E0BE740469; Tue, 21 Feb 2012 09:22:04 -0500 (EST)
Date: Tue, 21 Feb 2012 09:22:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221142204.GF11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F43A951.0174,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 11:07:25AM -0700, Justin T. Gibbs wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>       BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>       to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>       recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>       this value.
> 
> This extension first appeared in the FreeBSD Operating System.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
> @@ -145,6 +145,32 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the backend.

Don't you mean responses?

> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
> + *
> + *      The maximum value of blkif_request.nr_segments supported by
> + *      the backend.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by a
> + *      request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).

So just to make sure my math is correct. That would be 1MB right?

> + *
>   *------------------------- Backend Device Properties -------------------------
>   *
>   * discard-aligment
> @@ -242,6 +268,33 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the frontend.
> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  MIN(255, backend/max-request-segments)

Um, that looks like its referencing itself? This is the backend section.

> + *
> + *      The maximum value the frontend will set in the
> + *      blkif_request.nr_segments field.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  max-request-segments * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by
> + *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -403,11 +456,28 @@
>  #define BLKIF_OP_DISCARD           5
>  
>  /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
>   * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
>   * NB. This could be 12 if the ring indexes weren't stored in the same page.
>   */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040201
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
> +#else
> +/*
> + * Maximum scatter/gather segments per request (header block only).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> +#endif
>  
>  /*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -422,9 +492,25 @@ struct blkif_request_segment {
>      /* @last_sect: last sector in frame to transfer (inclusive).     */
>      uint8_t     first_sect, last_sect;
>  };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>  
>  /*
>   * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note:  Due to the way Xen request rings operate, the producer and
> + *        consumer indices of the ring must be incremented by the
> + *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + *        (e.g. a response to a 3 ring entry request must also consume
> + *        3 entries in the ring, even though only the first ring entry
> + *        in the response has any data.)
>   */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
> @@ -432,11 +518,22 @@ struct blkif_request {
>      blkif_vdev_t   handle;       /* only for read/write requests         */
>      uint64_t       id;           /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> -    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
>  };
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
>   * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
> @@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
>   */
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
> +    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
> +    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
> +     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
> +    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h	Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/xen-compat.h	Mon Feb 20 11:03:01 2012 -0700
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:25:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:25:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzqer-000896-08; Tue, 21 Feb 2012 14:25:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzqep-00088t-2y
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:25:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1329834323!14291144!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4159 invoked from network); 21 Feb 2012 14:25: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; 21 Feb 2012 14:25:24 -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 q1LEPKWU027023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:25:21 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
	q1LEPJdT019655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:25:19 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
	q1LEPI6o013363; Tue, 21 Feb 2012 08:25:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:25:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E0BE740469; Tue, 21 Feb 2012 09:22:04 -0500 (EST)
Date: Tue, 21 Feb 2012 09:22:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221142204.GF11950@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F43A951.0174,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 20, 2012 at 11:07:25AM -0700, Justin T. Gibbs wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>       BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>       to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>       recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>       this value.
> 
> This extension first appeared in the FreeBSD Operating System.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
> @@ -145,6 +145,32 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the backend.

Don't you mean responses?

> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
> + *
> + *      The maximum value of blkif_request.nr_segments supported by
> + *      the backend.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by a
> + *      request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).

So just to make sure my math is correct. That would be 1MB right?

> + *
>   *------------------------- Backend Device Properties -------------------------
>   *
>   * discard-aligment
> @@ -242,6 +268,33 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the frontend.
> + *
> + *      Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + *      Values:         <uint8_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + *      Maximum Value:  MIN(255, backend/max-request-segments)

Um, that looks like its referencing itself? This is the backend section.

> + *
> + *      The maximum value the frontend will set in the
> + *      blkif_request.nr_segments field.
> + *
> + * max-request-size
> + *      Values:         <uint32_t>
> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + *      Maximum Value:  max-request-segments * PAGE_SIZE
> + *
> + *      The maximum amount of data, in bytes, that can be referenced by
> + *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -403,11 +456,28 @@
>  #define BLKIF_OP_DISCARD           5
>  
>  /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
>   * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
>   * NB. This could be 12 if the ring indexes weren't stored in the same page.
>   */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040201
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
> +#else
> +/*
> + * Maximum scatter/gather segments per request (header block only).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> +#endif
>  
>  /*
>   * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -422,9 +492,25 @@ struct blkif_request_segment {
>      /* @last_sect: last sector in frame to transfer (inclusive).     */
>      uint8_t     first_sect, last_sect;
>  };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>  
>  /*
>   * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note:  Due to the way Xen request rings operate, the producer and
> + *        consumer indices of the ring must be incremented by the
> + *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + *        (e.g. a response to a 3 ring entry request must also consume
> + *        3 entries in the ring, even though only the first ring entry
> + *        in the response has any data.)
>   */
>  struct blkif_request {
>      uint8_t        operation;    /* BLKIF_OP_???                         */
> @@ -432,11 +518,22 @@ struct blkif_request {
>      blkif_vdev_t   handle;       /* only for read/write requests         */
>      uint64_t       id;           /* private guest value, echoed in resp  */
>      blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
> -    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
>  };
>  typedef struct blkif_request blkif_request_t;
>  
>  /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> +    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
>   * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
>   * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
>   */
> @@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
>   */
>  DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>  
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
> +    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
> +    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
> +     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
> +    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
>  #define VDISK_CDROM        0x1
>  #define VDISK_REMOVABLE    0x2
>  #define VDISK_READONLY     0x4
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h	Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/xen-compat.h	Mon Feb 20 11:03:01 2012 -0700
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:27:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqgQ-0008H8-GE; Tue, 21 Feb 2012 14:27:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqgP-0008Gs-IL
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:27:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329834422!12458614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20646 invoked from network); 21 Feb 2012 14:27:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:27:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:27:03 +0000
Message-ID: <1329834420.3990.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:27:00 +0000
In-Reply-To: <e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> o Document the XenBus nodes used in this protocol.
>   o Add a state diagram illustrating the roles and responsibilities
>     of both the front and backend during startup.
>   o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I've made some very minor comments below but I think getting the basic
documentation of this stuff in as a baseline to improve and correct over
time is more important than any of them.

Thanks again for doing this -- it is really valuable!

> diff -r 28137a4e39a3 -r e79902456819 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h     Mon Feb 20 10:48:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h     Mon Feb 20 10:48:09 2012 -0700
> @@ -22,6 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   *
>   * Copyright (c) 2003-2004, Keir Fraser
> + * Copyright (c) 2012, Spectra Logic Corporation
>   */
> 
>  #ifndef __XEN_PUBLIC_IO_BLKIF_H__
> @@ -48,32 +49,253 @@
>  #define blkif_sector_t uint64_t
> 
>  /*
> + * Feature and Parameter Negotiation
> + * =================================
> + * The two halves of a Xen block driver utilize nodes within the XenStore to
> + * communicate capabilities and to negotiate operating parameters.  This
> + * section enumerates these nodes which reside in the respective front and
> + * backend portions of the XenStore, following the XenBus convention.
> + *
> + * All data in the XenStore is stored as strings.  Nodes specifying numeric
> + * values are encoded in decimal.  Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.

		    formatted

> + *
> + * Any specified default value is in effect if the corresponding XenBus node
> + * is not present in the XenStore.
> + *
> + * XenStore nodes in sections marked "PRIVATE" are solely for use by the
> + * driver side whose XenBus tree contains them.
> + *
> + * See the XenBus state transition diagram below for details on when XenBus
> + * nodes must be published and when they can be queried.
> + *
> + *****************************************************************************
> + *                            Backend XenBus Nodes
> + *****************************************************************************
> + *
> + *------------------ Backend Device Identification (PRIVATE) ------------------
> + *
> + * mode
> + *      Values:         "r" (read only), "w" (writable)
> + *
> + *      The read or write access permissions to the backing store to be
> + *      granted to the frontend.
> + *
> + * params
> + *      Values:         string
> + *
> + *      A free formatted string providing sufficient information for the
> + *      backend driver to open the backing device.  (e.g. the path to the
> + *      file or block device representing the backing store.)

The syntax and semantics of params is defined by the particular backend,
rather than being "free formatted" as such. I think it would be worth
saying that explicitly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:27:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqgQ-0008H8-GE; Tue, 21 Feb 2012 14:27:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqgP-0008Gs-IL
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:27:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329834422!12458614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20646 invoked from network); 21 Feb 2012 14:27:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10845983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:27:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:27:03 +0000
Message-ID: <1329834420.3990.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:27:00 +0000
In-Reply-To: <e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> o Document the XenBus nodes used in this protocol.
>   o Add a state diagram illustrating the roles and responsibilities
>     of both the front and backend during startup.
>   o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
> 
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I've made some very minor comments below but I think getting the basic
documentation of this stuff in as a baseline to improve and correct over
time is more important than any of them.

Thanks again for doing this -- it is really valuable!

> diff -r 28137a4e39a3 -r e79902456819 xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h     Mon Feb 20 10:48:09 2012 -0700
> +++ b/xen/include/public/io/blkif.h     Mon Feb 20 10:48:09 2012 -0700
> @@ -22,6 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   *
>   * Copyright (c) 2003-2004, Keir Fraser
> + * Copyright (c) 2012, Spectra Logic Corporation
>   */
> 
>  #ifndef __XEN_PUBLIC_IO_BLKIF_H__
> @@ -48,32 +49,253 @@
>  #define blkif_sector_t uint64_t
> 
>  /*
> + * Feature and Parameter Negotiation
> + * =================================
> + * The two halves of a Xen block driver utilize nodes within the XenStore to
> + * communicate capabilities and to negotiate operating parameters.  This
> + * section enumerates these nodes which reside in the respective front and
> + * backend portions of the XenStore, following the XenBus convention.
> + *
> + * All data in the XenStore is stored as strings.  Nodes specifying numeric
> + * values are encoded in decimal.  Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.

		    formatted

> + *
> + * Any specified default value is in effect if the corresponding XenBus node
> + * is not present in the XenStore.
> + *
> + * XenStore nodes in sections marked "PRIVATE" are solely for use by the
> + * driver side whose XenBus tree contains them.
> + *
> + * See the XenBus state transition diagram below for details on when XenBus
> + * nodes must be published and when they can be queried.
> + *
> + *****************************************************************************
> + *                            Backend XenBus Nodes
> + *****************************************************************************
> + *
> + *------------------ Backend Device Identification (PRIVATE) ------------------
> + *
> + * mode
> + *      Values:         "r" (read only), "w" (writable)
> + *
> + *      The read or write access permissions to the backing store to be
> + *      granted to the frontend.
> + *
> + * params
> + *      Values:         string
> + *
> + *      A free formatted string providing sufficient information for the
> + *      backend driver to open the backing device.  (e.g. the path to the
> + *      file or block device representing the backing store.)

The syntax and semantics of params is defined by the particular backend,
rather than being "free formatted" as such. I think it would be worth
saying that explicitly.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1Rzqk7-00007p-9s; Tue, 21 Feb 2012 14:30:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzqk6-00007W-8Q
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:30:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329834650!14078738!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7427 invoked from network); 21 Feb 2012 14:30:51 -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; 21 Feb 2012 14:30: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 q1LEUepY032618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:30:41 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
	q1LEUdt6027509
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:30:40 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
	q1LEUcZL013183; Tue, 21 Feb 2012 08:30:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:30:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6CD5140469; Tue, 21 Feb 2012 09:27:24 -0500 (EST)
Date: Tue, 21 Feb 2012 09:27:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>, lenb@kernel.org,
	len.brown@intel.com
Message-ID: <20120221142724.GB5652@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F43AA92.0110,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 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 Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> >>>>> +struct pv_pad_ops {
> >>>>> +	int (*acpi_pad_init)(void);
> >>>>> +	void (*acpi_pad_exit)(void);
> >>>>> +};
> >>>>> +
> >>> 
> >>> Looking at this a bit closer I am not sure why you choose the
> >>> paravirt interface for this? There is another one - the x86 that
> >>> could have been choosen. Or introduce a new one that is specific to
> >>> ACPI. 
> >>> 
> >>> I am curious - what was the reason for using the paravirt interface?
> >>> I understand it does get the job done, but it seems a bit overkill
> >>> when something simple could have been used?
> >>> 
> >> 
> >> It uses paravirt interface to avoid some code like 'xen_...' in
> >> native code path (acpi_pad.c). 
> >> I'm not quite sure what does 'x86' here mean? Adding 2 fields
> >> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
> >> seems it's much simpler.  
> > 
> > arch/x86/include/asm/x86_init.h
> > 
> > But before you go that way let me ask you another question - can ACPI
> > PAD 
> > be used on ARM or IA64? If so, wouldn't this fail compilation as this
> > pvops structure is not defined on IA64?
> 
> Ideally ACPI PAD is not bound to some arch, so IMO it could be used at least on IA64 (through currently no real PAD on IA64 platform as far as I know).
> However, in native acpi_pad implementation, it indeed depends on X86 for reason like mwait.
> So for xen acpi_pad, I think it's OK to choose x86, defining an acpi_pad_ops at x86_init.c which would be overwritten when xen init.

OK, or in osl.c. We need Len to chime in here as I can see this expanding in the future.
> 
> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as 'bool', which would disable native acpi_pad module.

Ewww. No.
> 
> Your opinion?
> 
> Thanks,
> Jinsong
> 
> > 
> > The other thing I am not comfortable about is that the pvops structure
> > are used for low-level code. Not for higher up, like ACPI. For that
> > another structure seems more prudent. Perhaps something like the x86
> > one, but specific to ACPI?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1Rzqk7-00007p-9s; Tue, 21 Feb 2012 14:30:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzqk6-00007W-8Q
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:30:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329834650!14078738!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7427 invoked from network); 21 Feb 2012 14:30:51 -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; 21 Feb 2012 14:30: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 q1LEUepY032618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:30:41 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
	q1LEUdt6027509
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:30:40 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
	q1LEUcZL013183; Tue, 21 Feb 2012 08:30:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:30:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6CD5140469; Tue, 21 Feb 2012 09:27:24 -0500 (EST)
Date: Tue, 21 Feb 2012 09:27:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>, lenb@kernel.org,
	len.brown@intel.com
Message-ID: <20120221142724.GB5652@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F43AA92.0110,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 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 Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> >>>>> +struct pv_pad_ops {
> >>>>> +	int (*acpi_pad_init)(void);
> >>>>> +	void (*acpi_pad_exit)(void);
> >>>>> +};
> >>>>> +
> >>> 
> >>> Looking at this a bit closer I am not sure why you choose the
> >>> paravirt interface for this? There is another one - the x86 that
> >>> could have been choosen. Or introduce a new one that is specific to
> >>> ACPI. 
> >>> 
> >>> I am curious - what was the reason for using the paravirt interface?
> >>> I understand it does get the job done, but it seems a bit overkill
> >>> when something simple could have been used?
> >>> 
> >> 
> >> It uses paravirt interface to avoid some code like 'xen_...' in
> >> native code path (acpi_pad.c). 
> >> I'm not quite sure what does 'x86' here mean? Adding 2 fields
> >> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
> >> seems it's much simpler.  
> > 
> > arch/x86/include/asm/x86_init.h
> > 
> > But before you go that way let me ask you another question - can ACPI
> > PAD 
> > be used on ARM or IA64? If so, wouldn't this fail compilation as this
> > pvops structure is not defined on IA64?
> 
> Ideally ACPI PAD is not bound to some arch, so IMO it could be used at least on IA64 (through currently no real PAD on IA64 platform as far as I know).
> However, in native acpi_pad implementation, it indeed depends on X86 for reason like mwait.
> So for xen acpi_pad, I think it's OK to choose x86, defining an acpi_pad_ops at x86_init.c which would be overwritten when xen init.

OK, or in osl.c. We need Len to chime in here as I can see this expanding in the future.
> 
> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as 'bool', which would disable native acpi_pad module.

Ewww. No.
> 
> Your opinion?
> 
> Thanks,
> Jinsong
> 
> > 
> > The other thing I am not comfortable about is that the pvops structure
> > are used for low-level code. Not for higher up, like ACPI. For that
> > another structure seems more prudent. Perhaps something like the x86
> > one, but specific to ACPI?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:32:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqlY-0000GU-Uy; Tue, 21 Feb 2012 14:32:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqlW-0000Fv-Sg
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:32:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329834739!15713157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1778 invoked from network); 21 Feb 2012 14:32:19 -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;
	21 Feb 2012 14:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10846113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:32:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:32:18 +0000
Message-ID: <1329834736.3990.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:32:16 +0000
In-Reply-To: <09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 4 v3] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring 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 Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.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 Feb 21 14:32:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1RzqlY-0000GU-Uy; Tue, 21 Feb 2012 14:32:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqlW-0000Fv-Sg
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:32:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329834739!15713157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1778 invoked from network); 21 Feb 2012 14:32:19 -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;
	21 Feb 2012 14:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10846113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:32:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:32:18 +0000
Message-ID: <1329834736.3990.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:32:16 +0000
In-Reply-To: <09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<09051133e2fee4f2e371.1329761244@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 4 v3] blkif.h: Document the RedHat and
 Citrix blkif multi-page ring 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 Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> No functional changes.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.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 Feb 21 14:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1Rzqnj-0000SB-GE; Tue, 21 Feb 2012 14:34:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzqni-0000RV-LQ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:34:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329834875!17597872!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 765 invoked from network); 21 Feb 2012 14:34:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 14:34:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329834874; l=1411;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=V8eNdojozPSBMb5KtZvURJWZLYg=;
	b=JnkT1bCgyh1vnV4h133Xt1Gu/nLJEkfQ9z2fHZI6d79/5i93L682lqYNKoq//ESgMz8
	z4bl4x4zepBriEDgb2g9XnAiOAQpKrr35+ij3E3juAOljCiyWd1eaE4sYdV+v+i5VIddn
	/aF54nXcnS8SRfteT9QAo2HBeZBPpmCTlvA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (klopstock mo1) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e07352o1LE3GZZ ;
	Tue, 21 Feb 2012 15:34:11 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E683A18638; Tue, 21 Feb 2012 15:34:07 +0100 (CET)
Date: Tue, 21 Feb 2012 15:34:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221143407.GA12163@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<1329823291.25232.94.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329823291.25232.94.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Campbell wrote:

> On Mon, 2012-02-20 at 19:26 +0000, Olaf Hering wrote:
> > Any idea whats going on here?
> 
> It's pretty odd isn't it.
> 
> I tried:
>         $ make -C tools/xenstore/ clean
>         $ make -C tools/xenstore/ -j12
> and couldn't reproduce. I see the ln before the link lines, even with
> bigger and smaller -jN.

I use this script 'time bash ../build.sh -d xen tools &> output.txt':

#!/bin/bash
set -x
unset LANG
unset ${!LC_*}
tgt="xen tools"
if test -n "$1"
then
	tgt=$@
fi
if pushd tools/xenstore
then
	make clean
	popd
fi
time XEN_DOMAIN=localhost DISTDIR=/dev/shm/install-${PWD//\//_} make -j 3 ${tgt} ; echo $?

It seems to trigger with either 'make -d' or 'make -d xen tools', but
seldom with 'make -d tools'.
It does not trigger with -j 1, but with -j 2 or 3.

> "make -d" will tell you make's thought processes, might give a hint?

Thanks for that hint, I will try to make sense of the (huge) output.

> Could it be your filesystem? Something odd to do with timestamps on
> symlinks which upsets your version of make perhaps? (I'm on ext3)

I'm on ext3.  libxenstore.so is not there, thats the issue.

I wonder why libxenstore.so and libxenstore.a is listed at all in
ALL_TARGETS? Perhaps that confuses make? But removing both does not help
either. To me it looks like $(LIBXENSTORE) does not serve as a proper
dependency.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14: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 1Rzqnj-0000SB-GE; Tue, 21 Feb 2012 14:34:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzqni-0000RV-LQ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:34:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329834875!17597872!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 765 invoked from network); 21 Feb 2012 14:34:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 14:34:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329834874; l=1411;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=V8eNdojozPSBMb5KtZvURJWZLYg=;
	b=JnkT1bCgyh1vnV4h133Xt1Gu/nLJEkfQ9z2fHZI6d79/5i93L682lqYNKoq//ESgMz8
	z4bl4x4zepBriEDgb2g9XnAiOAQpKrr35+ij3E3juAOljCiyWd1eaE4sYdV+v+i5VIddn
	/aF54nXcnS8SRfteT9QAo2HBeZBPpmCTlvA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (klopstock mo1) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e07352o1LE3GZZ ;
	Tue, 21 Feb 2012 15:34:11 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E683A18638; Tue, 21 Feb 2012 15:34:07 +0100 (CET)
Date: Tue, 21 Feb 2012 15:34:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221143407.GA12163@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<1329823291.25232.94.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329823291.25232.94.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Campbell wrote:

> On Mon, 2012-02-20 at 19:26 +0000, Olaf Hering wrote:
> > Any idea whats going on here?
> 
> It's pretty odd isn't it.
> 
> I tried:
>         $ make -C tools/xenstore/ clean
>         $ make -C tools/xenstore/ -j12
> and couldn't reproduce. I see the ln before the link lines, even with
> bigger and smaller -jN.

I use this script 'time bash ../build.sh -d xen tools &> output.txt':

#!/bin/bash
set -x
unset LANG
unset ${!LC_*}
tgt="xen tools"
if test -n "$1"
then
	tgt=$@
fi
if pushd tools/xenstore
then
	make clean
	popd
fi
time XEN_DOMAIN=localhost DISTDIR=/dev/shm/install-${PWD//\//_} make -j 3 ${tgt} ; echo $?

It seems to trigger with either 'make -d' or 'make -d xen tools', but
seldom with 'make -d tools'.
It does not trigger with -j 1, but with -j 2 or 3.

> "make -d" will tell you make's thought processes, might give a hint?

Thanks for that hint, I will try to make sense of the (huge) output.

> Could it be your filesystem? Something odd to do with timestamps on
> symlinks which upsets your version of make perhaps? (I'm on ext3)

I'm on ext3.  libxenstore.so is not there, thats the issue.

I wonder why libxenstore.so and libxenstore.a is listed at all in
ALL_TARGETS? Perhaps that confuses make? But removing both does not help
either. To me it looks like $(LIBXENSTORE) does not serve as a proper
dependency.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqrX-0000jI-ET; Tue, 21 Feb 2012 14:38:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqrW-0000j3-DZ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:38:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329835110!14289040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7291 invoked from network); 21 Feb 2012 14:38:31 -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;
	21 Feb 2012 14:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10846292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:38:29 +0000
Message-ID: <1329835108.3990.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:38:28 +0000
In-Reply-To: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>       BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>       to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>       recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>       this value.
> 
> This extension first appeared in the FreeBSD Operating System.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
> @@ -145,6 +145,32 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the backend.

by "issued" do you mean the maximum number that the backend is willing
to consume/have-in-flight at once? I guess that means issued to the
underlying storage? (backend doesn't issue requests to the frontend does
it? That's how I first read it, hence my question)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqrX-0000jI-ET; Tue, 21 Feb 2012 14:38:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzqrW-0000j3-DZ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:38:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329835110!14289040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7291 invoked from network); 21 Feb 2012 14:38:31 -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;
	21 Feb 2012 14:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10846292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:38:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 14:38:29 +0000
Message-ID: <1329835108.3990.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 14:38:28 +0000
In-Reply-To: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>       BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>       to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>       recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>       this value.
> 
> This extension first appeared in the FreeBSD Operating System.
> 
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
> @@ -145,6 +145,32 @@
>   *      The maximum supported size of the request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * max-requests         <uint32_t>
> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + *      The maximum number of concurrent, logical requests that will be
> + *      issued by the backend.

by "issued" do you mean the maximum number that the backend is willing
to consume/have-in-flight at once? I guess that means issued to the
underlying storage? (backend doesn't issue requests to the frontend does
it? That's how I first read it, hence my question)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:39:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzqsb-0000on-T5; Tue, 21 Feb 2012 14:39:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RzqsZ-0000o8-Qq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:39:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329835177!9141021!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26449 invoked from network); 21 Feb 2012 14:39:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:39:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10846324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:39:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 14:39:37 +0000
Date: Tue, 21 Feb 2012 14:45:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329833159.3990.91.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211445000.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<1329755758.3990.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
	<1329833159.3990.91.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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, 21 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-21 at 10:53 +0000, Stefano Stabellini wrote:
> > On Mon, 20 Feb 2012, Ian Campbell wrote:
> > > On Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> > > > This is necessary to handle nested traps to the hypervisor more than one deep.
> > > 
> > > A sort of corollary to this patch is the following.
> > > 
> > > The situation with the LR register when in hyp mode is a bit odd, since
> > > this is normally a banked register but for hyp mode it actually accesses
> > > LR_usr instead.
> > > 
> > > However, although I think the following is correct I'm not sure if it is
> > > useful to combine LR_usr and LR like this -- in particular I fear it
> > > might be more confusing than helpful. Making the return-to-user case a
> > > proper superset of return-to-hypervisor (as is the case on the save
> > > path) is nice though.
> > > 
> > > What do people think?
> > 
> > I am OK with this.
> 
> Is that an Acked-by?

with the comments, yes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:39:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzqsb-0000on-T5; Tue, 21 Feb 2012 14:39:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RzqsZ-0000o8-Qq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:39:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329835177!9141021!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26449 invoked from network); 21 Feb 2012 14:39:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 14:39:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="10846324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:39:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 14:39:37 +0000
Date: Tue, 21 Feb 2012 14:45:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329833159.3990.91.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202211445000.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<1329755758.3990.72.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211051510.23091@kaball-desktop>
	<1329833159.3990.91.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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, 21 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-21 at 10:53 +0000, Stefano Stabellini wrote:
> > On Mon, 20 Feb 2012, Ian Campbell wrote:
> > > On Mon, 2012-02-20 at 15:22 +0000, Ian Campbell wrote:
> > > > This is necessary to handle nested traps to the hypervisor more than one deep.
> > > 
> > > A sort of corollary to this patch is the following.
> > > 
> > > The situation with the LR register when in hyp mode is a bit odd, since
> > > this is normally a banked register but for hyp mode it actually accesses
> > > LR_usr instead.
> > > 
> > > However, although I think the following is correct I'm not sure if it is
> > > useful to combine LR_usr and LR like this -- in particular I fear it
> > > might be more confusing than helpful. Making the return-to-user case a
> > > proper superset of return-to-hypervisor (as is the case on the save
> > > path) is nice though.
> > > 
> > > What do people think?
> > 
> > I am OK with this.
> 
> Is that an Acked-by?

with the comments, yes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:47:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqzM-0001Bm-W0; Tue, 21 Feb 2012 14:46:44 +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 1RzqzL-0001BU-Qk
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:46:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329835542!50131674!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29127 invoked from network); 21 Feb 2012 14:45:43 -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; 21 Feb 2012 14:45: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 q1LEkV6F017018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:46:32 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
	q1LEkUxK017488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:46:31 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
	q1LEkUaM024967; Tue, 21 Feb 2012 08:46:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:46:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4E5D340469; Tue, 21 Feb 2012 09:43:16 -0500 (EST)
Date: Tue, 21 Feb 2012 09:43:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120221144316.GG5652@phenom.dumpdata.com>
References: <1329823842-10085-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329823842-10085-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090203.4F43AE48.013B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] hvc_xen: introduce HVC_XEN_FRONTEND
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 11:30:42AM +0000, Stefano Stabellini wrote:
> Introduce a new config option HVC_XEN_FRONTEND to enable/disable the
> xenbus based pv console frontend.

applied.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/Kconfig   |    8 +++
>  drivers/tty/hvc/hvc_xen.c |  116 ++++++++++++++++++++++++---------------------
>  2 files changed, 70 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
> index 4222035..192e21e 100644
> --- a/drivers/tty/hvc/Kconfig
> +++ b/drivers/tty/hvc/Kconfig
> @@ -76,6 +76,14 @@ config HVC_XEN
>  	help
>  	  Xen virtual console device driver
>  
> +config HVC_XEN_FRONTEND
> +	bool "Xen Hypervisor Multiple Consoles support"
> +	depends on HVC_XEN
> +	select XEN_XENBUS_FRONTEND
> +	default y
> +	help
> +	  Xen driver for secondary virtual consoles
> +
>  config HVC_UDBG
>         bool "udbg based fake hypervisor console"
>         depends on PPC && EXPERIMENTAL
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 26090c7..83d5c88 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -55,7 +55,6 @@ struct xencons_info {
>  
>  static LIST_HEAD(xenconsoles);
>  static DEFINE_SPINLOCK(xencons_lock);
> -static struct xenbus_driver xencons_driver;
>  
>  /* ------------------------------------------------------------------ */
>  
> @@ -298,53 +297,6 @@ static int xen_initial_domain_console_init(void)
>  	return 0;
>  }
>  
> -static int __init xen_hvc_init(void)
> -{
> -	int r;
> -	struct xencons_info *info;
> -	const struct hv_ops *ops;
> -
> -	if (!xen_domain())
> -		return -ENODEV;
> -
> -	if (xen_initial_domain()) {
> -		ops = &dom0_hvc_ops;
> -		r = xen_initial_domain_console_init();
> -		if (r < 0)
> -			return r;
> -		info = vtermno_to_xencons(HVC_COOKIE);
> -	} else {
> -		ops = &domU_hvc_ops;
> -		if (xen_hvm_domain())
> -			r = xen_hvm_console_init();
> -		else
> -			r = xen_pv_console_init();
> -		if (r < 0)
> -			return r;
> -
> -		info = vtermno_to_xencons(HVC_COOKIE);
> -		info->irq = bind_evtchn_to_irq(info->evtchn);
> -	}
> -	if (info->irq < 0)
> -		info->irq = 0; /* NO_IRQ */
> -	else
> -		irq_set_noprobe(info->irq);
> -
> -	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> -	if (IS_ERR(info->hvc)) {
> -		r = PTR_ERR(info->hvc);
> -		spin_lock(&xencons_lock);
> -		list_del(&info->list);
> -		spin_unlock(&xencons_lock);
> -		if (info->irq)
> -			unbind_from_irqhandler(info->irq, NULL);
> -		kfree(info);
> -		return r;
> -	}
> -
> -	return xenbus_register_frontend(&xencons_driver);
> -}
> -
>  void xen_console_resume(void)
>  {
>  	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
> @@ -392,6 +344,9 @@ static int xen_console_remove(struct xencons_info *info)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_HVC_XEN_FRONTEND
> +static struct xenbus_driver xencons_driver;
> +
>  static int xencons_remove(struct xenbus_device *dev)
>  {
>  	return xen_console_remove(dev_get_drvdata(&dev->dev));
> @@ -543,6 +498,65 @@ static const struct xenbus_device_id xencons_ids[] = {
>  };
>  
>  
> +static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +);
> +#endif /* CONFIG_HVC_XEN_FRONTEND */
> +
> +static int __init xen_hvc_init(void)
> +{
> +	int r;
> +	struct xencons_info *info;
> +	const struct hv_ops *ops;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	if (xen_initial_domain()) {
> +		ops = &dom0_hvc_ops;
> +		r = xen_initial_domain_console_init();
> +		if (r < 0)
> +			return r;
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +	} else {
> +		ops = &domU_hvc_ops;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
> +		else
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
> +
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +		info->irq = bind_evtchn_to_irq(info->evtchn);
> +	}
> +	if (info->irq < 0)
> +		info->irq = 0; /* NO_IRQ */
> +	else
> +		irq_set_noprobe(info->irq);
> +
> +	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> +	if (IS_ERR(info->hvc)) {
> +		r = PTR_ERR(info->hvc);
> +		spin_lock(&xencons_lock);
> +		list_del(&info->list);
> +		spin_unlock(&xencons_lock);
> +		if (info->irq)
> +			unbind_from_irqhandler(info->irq, NULL);
> +		kfree(info);
> +		return r;
> +	}
> +
> +	r = 0;
> +#ifdef CONFIG_HVC_XEN_FRONTEND
> +	r = xenbus_register_frontend(&xencons_driver);
> +#endif
> +	return r;
> +}
> +
>  static void __exit xen_hvc_fini(void)
>  {
>  	struct xencons_info *entry, *next;
> @@ -580,12 +594,6 @@ static int xen_cons_init(void)
>  	return 0;
>  }
>  
> -static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
> -	.probe = xencons_probe,
> -	.remove = xencons_remove,
> -	.resume = xencons_resume,
> -	.otherend_changed = xencons_backend_changed,
> -);
>  
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:47:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzqzM-0001Bm-W0; Tue, 21 Feb 2012 14:46:44 +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 1RzqzL-0001BU-Qk
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:46:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329835542!50131674!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29127 invoked from network); 21 Feb 2012 14:45:43 -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; 21 Feb 2012 14:45: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 q1LEkV6F017018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:46:32 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
	q1LEkUxK017488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:46:31 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
	q1LEkUaM024967; Tue, 21 Feb 2012 08:46:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:46:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4E5D340469; Tue, 21 Feb 2012 09:43:16 -0500 (EST)
Date: Tue, 21 Feb 2012 09:43:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120221144316.GG5652@phenom.dumpdata.com>
References: <1329823842-10085-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329823842-10085-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090203.4F43AE48.013B,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] hvc_xen: introduce HVC_XEN_FRONTEND
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 11:30:42AM +0000, Stefano Stabellini wrote:
> Introduce a new config option HVC_XEN_FRONTEND to enable/disable the
> xenbus based pv console frontend.

applied.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/Kconfig   |    8 +++
>  drivers/tty/hvc/hvc_xen.c |  116 ++++++++++++++++++++++++---------------------
>  2 files changed, 70 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
> index 4222035..192e21e 100644
> --- a/drivers/tty/hvc/Kconfig
> +++ b/drivers/tty/hvc/Kconfig
> @@ -76,6 +76,14 @@ config HVC_XEN
>  	help
>  	  Xen virtual console device driver
>  
> +config HVC_XEN_FRONTEND
> +	bool "Xen Hypervisor Multiple Consoles support"
> +	depends on HVC_XEN
> +	select XEN_XENBUS_FRONTEND
> +	default y
> +	help
> +	  Xen driver for secondary virtual consoles
> +
>  config HVC_UDBG
>         bool "udbg based fake hypervisor console"
>         depends on PPC && EXPERIMENTAL
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 26090c7..83d5c88 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -55,7 +55,6 @@ struct xencons_info {
>  
>  static LIST_HEAD(xenconsoles);
>  static DEFINE_SPINLOCK(xencons_lock);
> -static struct xenbus_driver xencons_driver;
>  
>  /* ------------------------------------------------------------------ */
>  
> @@ -298,53 +297,6 @@ static int xen_initial_domain_console_init(void)
>  	return 0;
>  }
>  
> -static int __init xen_hvc_init(void)
> -{
> -	int r;
> -	struct xencons_info *info;
> -	const struct hv_ops *ops;
> -
> -	if (!xen_domain())
> -		return -ENODEV;
> -
> -	if (xen_initial_domain()) {
> -		ops = &dom0_hvc_ops;
> -		r = xen_initial_domain_console_init();
> -		if (r < 0)
> -			return r;
> -		info = vtermno_to_xencons(HVC_COOKIE);
> -	} else {
> -		ops = &domU_hvc_ops;
> -		if (xen_hvm_domain())
> -			r = xen_hvm_console_init();
> -		else
> -			r = xen_pv_console_init();
> -		if (r < 0)
> -			return r;
> -
> -		info = vtermno_to_xencons(HVC_COOKIE);
> -		info->irq = bind_evtchn_to_irq(info->evtchn);
> -	}
> -	if (info->irq < 0)
> -		info->irq = 0; /* NO_IRQ */
> -	else
> -		irq_set_noprobe(info->irq);
> -
> -	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> -	if (IS_ERR(info->hvc)) {
> -		r = PTR_ERR(info->hvc);
> -		spin_lock(&xencons_lock);
> -		list_del(&info->list);
> -		spin_unlock(&xencons_lock);
> -		if (info->irq)
> -			unbind_from_irqhandler(info->irq, NULL);
> -		kfree(info);
> -		return r;
> -	}
> -
> -	return xenbus_register_frontend(&xencons_driver);
> -}
> -
>  void xen_console_resume(void)
>  {
>  	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
> @@ -392,6 +344,9 @@ static int xen_console_remove(struct xencons_info *info)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_HVC_XEN_FRONTEND
> +static struct xenbus_driver xencons_driver;
> +
>  static int xencons_remove(struct xenbus_device *dev)
>  {
>  	return xen_console_remove(dev_get_drvdata(&dev->dev));
> @@ -543,6 +498,65 @@ static const struct xenbus_device_id xencons_ids[] = {
>  };
>  
>  
> +static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +);
> +#endif /* CONFIG_HVC_XEN_FRONTEND */
> +
> +static int __init xen_hvc_init(void)
> +{
> +	int r;
> +	struct xencons_info *info;
> +	const struct hv_ops *ops;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	if (xen_initial_domain()) {
> +		ops = &dom0_hvc_ops;
> +		r = xen_initial_domain_console_init();
> +		if (r < 0)
> +			return r;
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +	} else {
> +		ops = &domU_hvc_ops;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
> +		else
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
> +
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +		info->irq = bind_evtchn_to_irq(info->evtchn);
> +	}
> +	if (info->irq < 0)
> +		info->irq = 0; /* NO_IRQ */
> +	else
> +		irq_set_noprobe(info->irq);
> +
> +	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> +	if (IS_ERR(info->hvc)) {
> +		r = PTR_ERR(info->hvc);
> +		spin_lock(&xencons_lock);
> +		list_del(&info->list);
> +		spin_unlock(&xencons_lock);
> +		if (info->irq)
> +			unbind_from_irqhandler(info->irq, NULL);
> +		kfree(info);
> +		return r;
> +	}
> +
> +	r = 0;
> +#ifdef CONFIG_HVC_XEN_FRONTEND
> +	r = xenbus_register_frontend(&xencons_driver);
> +#endif
> +	return r;
> +}
> +
>  static void __exit xen_hvc_fini(void)
>  {
>  	struct xencons_info *entry, *next;
> @@ -580,12 +594,6 @@ static int xen_cons_init(void)
>  	return 0;
>  }
>  
> -static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
> -	.probe = xencons_probe,
> -	.remove = xencons_remove,
> -	.resume = xencons_resume,
> -	.otherend_changed = xencons_backend_changed,
> -);
>  
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:49:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzr1v-0001Kx-T9; Tue, 21 Feb 2012 14:49:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzr1t-0001KJ-MZ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:49:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329835755!13354735!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17111 invoked from network); 21 Feb 2012 14:49:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 14:49:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329835755; l=227;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vGffGzXt0G17LDHfziOjcyZmm3M=;
	b=jqu0mMBG7hDakMbHiQoN6TEeyL9sUwgS0np1FCailK1r1vDW5UXcgYnCINtThCUqnI3
	07hMalza5Dlq1j8hFIGGn+0HRgpVSPlqtG2XrtHKnF0xTYwMhdH2K97BM6SaZq4o8f/3N
	DfyqpYqfoeuDOqLACvGdkten/afRZe0kD5Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by post.strato.de (mrclete mo14) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id d04ec6o1LDQ1fd ;
	Tue, 21 Feb 2012 15:49:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 26D8C18638; Tue, 21 Feb 2012 15:49:06 +0100 (CET)
Date: Tue, 21 Feb 2012 15:49:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221144905.GA32695@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<1329823291.25232.94.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329823291.25232.94.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Campbell wrote:

> On Mon, 2012-02-20 at 19:26 +0000, Olaf Hering wrote:
> > Any idea whats going on here?
> 
> It's pretty odd isn't it.

I can not reproduce the link failure with make 3.81.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:49:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzr1v-0001Kx-T9; Tue, 21 Feb 2012 14:49:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzr1t-0001KJ-MZ
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:49:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329835755!13354735!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17111 invoked from network); 21 Feb 2012 14:49:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 14:49:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329835755; l=227;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vGffGzXt0G17LDHfziOjcyZmm3M=;
	b=jqu0mMBG7hDakMbHiQoN6TEeyL9sUwgS0np1FCailK1r1vDW5UXcgYnCINtThCUqnI3
	07hMalza5Dlq1j8hFIGGn+0HRgpVSPlqtG2XrtHKnF0xTYwMhdH2K97BM6SaZq4o8f/3N
	DfyqpYqfoeuDOqLACvGdkten/afRZe0kD5Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by post.strato.de (mrclete mo14) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id d04ec6o1LDQ1fd ;
	Tue, 21 Feb 2012 15:49:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 26D8C18638; Tue, 21 Feb 2012 15:49:06 +0100 (CET)
Date: Tue, 21 Feb 2012 15:49:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120221144905.GA32695@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<1329823291.25232.94.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329823291.25232.94.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Campbell wrote:

> On Mon, 2012-02-20 at 19:26 +0000, Olaf Hering wrote:
> > Any idea whats going on here?
> 
> It's pretty odd isn't it.

I can not reproduce the link failure with make 3.81.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:59:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrB9-0001wl-3U; Tue, 21 Feb 2012 14:58:55 +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 1RzrB7-0001wc-Vw
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:58:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329836197!62238997!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 21 Feb 2012 14:56:38 -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 Feb 2012 14:56:38 -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 q1LEwigE001867
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:58:45 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
	q1LEwgvs012326
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:58:43 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1LEwf0H002237; Tue, 21 Feb 2012 08:58:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:58:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E261B40469; Tue, 21 Feb 2012 09:55:26 -0500 (EST)
Date: Tue, 21 Feb 2012 09:55:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Weyergraf <T.Weyergraf@virtfinity.de>
Message-ID: <20120221145526.GH5652@phenom.dumpdata.com>
References: <4F405CD0.2060002@virtfinity.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F405CD0.2060002@virtfinity.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F43B126.0014,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Feb 19, 2012 at 03:22:08AM +0100, Thomas Weyergraf wrote:
> Hi, I am working as a system administrator at an internet platform
> service provider, and I am currently seeking to re-new our Xen
> virtualization infrastructure for which I am mostly responsible for.
> Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0
> with CentOS 5.x pv-guests.
> 
> Based on my experiments, I am currently looking into Xen 4.1.2 on
> RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as
> Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.

Sweet.
> 
> Our DomU's have their disk-devices on iscsi-storage backends (EMC,
> netapp, Linux IET), we attach the disks to Dom0 via open-iscsi
> initiator and pass them as 'phy'-type blockdevices, using
> blkfront/back.

OK.
> 
> As this is the time for a major overhaul anyway, I looked at
> 'pvscsi', which is very attractive to me for a bunch of
> (administrative) reasons. I have created a working pvscsi-setup with
> the following steps:
> 1. Use CentOS 6.2 as base system
> 2. Add Xen hypervisor from Michael Young's repository [1]. This is
> stock 4.1.2 with a patch from 4.1-testing pulled-in and various
> patches fixing compile-time issues, toolchain problems and system
> service management on RHEL-alike systems. (Nice work, btw!)
> 3. Use a vanilla 3.2.0 kernel from kernel.org and a .config based on
> a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,
> Fedora 16 supports Dom0 operation and the only changes to the config
> are non-Xen related or add the Xen pvscsi config. I refrained from
> attaching the config to avoid mailinglist-clutter, but can do so on
> demand.

Awesome.
> 4. I pulled and applied the pvscsi-patch found in this post [2] from
> Konrad Rzeszutek Wilk.
> 
> Putting it all together yielded a "working setup" in which I am able
> to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.
> In DomU context, I could partition the device, create a filesystem
> on it and copy/read/verify some 10gig of data to it. Very basic
> testing until now, essentially. However, the whole issue raised some
> questions:
> 
> - I pvscsi actively maintained? Is someone working on this or even
> prepare it for upstream inclusion in the pv-ops framework of the 3.x
> series?

So nobody has stepped up to do the upstream task and it is on my todo list
but mostly at the end.

> - Has anybody started on adding the vscsi-semantics to the xl toolstack?

Not that I know of.

> - Using 'xm', I was only able to add a device via its SCSI tupel
> (HCTL, e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other
> device-node, such as '/dev/sde' or the
> '/dev/disk/by-path/<iscsi-iqn>' link. For these invocations, an
> "Error: Cannot find device <device>" message is given. I have not
> yet looked at the issue in detail (in
> /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this
> a known issue?

First time I hear of it. But then I didn't even think to use /dev/sde
to pass in a device since SCSI devices aren't neccessarily block ones.
They can be scanners, medical devices, tape drivers, etc - which
might not have a /dev/sdX (thought they will have an /dev/sgX).

> 
> Is there any developer(s) working on getting pvscsi ready for
> kernel.org 3.x upstream inclusion? Should i better retool my efforts
> using pv-ops xen/stable 2.6.32 series?

For 3.x upstream inclusion - not that I know off.
Why would you want to retool your effort in using the 2.6.32 series
as opposed to 3.x? What other items is the 3.x missing compared to 2.6.32?

Now the good news is that I am happy to keep this going (pv-scsi)
and fixing it, and having incremental updates to make it better.

> 
> If applicable, I'd be more than happy to provide assistance to move
> forward pvscsi. Maybe, as a start, provide a short, practical howto
> about what I did above to get pvscsi working and reference it by the
> Xen PVSCSI wiki page [3]?

Sure. Also, did you use the git tree to pull the patches or just
the big patch file ? The git tree has fixes to make it work under 3.2 as well.

> 
> Regards,
> Thomas Weyergraf
> 
> [1] http://xenbits.xen.org/people/mayoung/EL6.xen/
> [2] http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
> [3] http://wiki.xen.org/xenwiki/XenPVSCSI
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:59:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrB9-0001wl-3U; Tue, 21 Feb 2012 14:58:55 +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 1RzrB7-0001wc-Vw
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:58:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329836197!62238997!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 21 Feb 2012 14:56:38 -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 Feb 2012 14:56:38 -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 q1LEwigE001867
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:58:45 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
	q1LEwgvs012326
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:58:43 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1LEwf0H002237; Tue, 21 Feb 2012 08:58:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:58:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E261B40469; Tue, 21 Feb 2012 09:55:26 -0500 (EST)
Date: Tue, 21 Feb 2012 09:55:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Weyergraf <T.Weyergraf@virtfinity.de>
Message-ID: <20120221145526.GH5652@phenom.dumpdata.com>
References: <4F405CD0.2060002@virtfinity.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F405CD0.2060002@virtfinity.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F43B126.0014,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Feb 19, 2012 at 03:22:08AM +0100, Thomas Weyergraf wrote:
> Hi, I am working as a system administrator at an internet platform
> service provider, and I am currently seeking to re-new our Xen
> virtualization infrastructure for which I am mostly responsible for.
> Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0
> with CentOS 5.x pv-guests.
> 
> Based on my experiments, I am currently looking into Xen 4.1.2 on
> RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as
> Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.

Sweet.
> 
> Our DomU's have their disk-devices on iscsi-storage backends (EMC,
> netapp, Linux IET), we attach the disks to Dom0 via open-iscsi
> initiator and pass them as 'phy'-type blockdevices, using
> blkfront/back.

OK.
> 
> As this is the time for a major overhaul anyway, I looked at
> 'pvscsi', which is very attractive to me for a bunch of
> (administrative) reasons. I have created a working pvscsi-setup with
> the following steps:
> 1. Use CentOS 6.2 as base system
> 2. Add Xen hypervisor from Michael Young's repository [1]. This is
> stock 4.1.2 with a patch from 4.1-testing pulled-in and various
> patches fixing compile-time issues, toolchain problems and system
> service management on RHEL-alike systems. (Nice work, btw!)
> 3. Use a vanilla 3.2.0 kernel from kernel.org and a .config based on
> a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,
> Fedora 16 supports Dom0 operation and the only changes to the config
> are non-Xen related or add the Xen pvscsi config. I refrained from
> attaching the config to avoid mailinglist-clutter, but can do so on
> demand.

Awesome.
> 4. I pulled and applied the pvscsi-patch found in this post [2] from
> Konrad Rzeszutek Wilk.
> 
> Putting it all together yielded a "working setup" in which I am able
> to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.
> In DomU context, I could partition the device, create a filesystem
> on it and copy/read/verify some 10gig of data to it. Very basic
> testing until now, essentially. However, the whole issue raised some
> questions:
> 
> - I pvscsi actively maintained? Is someone working on this or even
> prepare it for upstream inclusion in the pv-ops framework of the 3.x
> series?

So nobody has stepped up to do the upstream task and it is on my todo list
but mostly at the end.

> - Has anybody started on adding the vscsi-semantics to the xl toolstack?

Not that I know of.

> - Using 'xm', I was only able to add a device via its SCSI tupel
> (HCTL, e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other
> device-node, such as '/dev/sde' or the
> '/dev/disk/by-path/<iscsi-iqn>' link. For these invocations, an
> "Error: Cannot find device <device>" message is given. I have not
> yet looked at the issue in detail (in
> /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this
> a known issue?

First time I hear of it. But then I didn't even think to use /dev/sde
to pass in a device since SCSI devices aren't neccessarily block ones.
They can be scanners, medical devices, tape drivers, etc - which
might not have a /dev/sdX (thought they will have an /dev/sgX).

> 
> Is there any developer(s) working on getting pvscsi ready for
> kernel.org 3.x upstream inclusion? Should i better retool my efforts
> using pv-ops xen/stable 2.6.32 series?

For 3.x upstream inclusion - not that I know off.
Why would you want to retool your effort in using the 2.6.32 series
as opposed to 3.x? What other items is the 3.x missing compared to 2.6.32?

Now the good news is that I am happy to keep this going (pv-scsi)
and fixing it, and having incremental updates to make it better.

> 
> If applicable, I'd be more than happy to provide assistance to move
> forward pvscsi. Maybe, as a start, provide a short, practical howto
> about what I did above to get pvscsi working and reference it by the
> Xen PVSCSI wiki page [3]?

Sure. Also, did you use the git tree to pull the patches or just
the big patch file ? The git tree has fixes to make it work under 3.2 as well.

> 
> Regards,
> Thomas Weyergraf
> 
> [1] http://xenbits.xen.org/people/mayoung/EL6.xen/
> [2] http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
> [3] http://wiki.xen.org/xenwiki/XenPVSCSI
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrBd-0001zQ-O0; Tue, 21 Feb 2012 14:59:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzrBc-0001yq-8Q
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:59:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329836358!12379241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10669 invoked from network); 21 Feb 2012 14:59:18 -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;
	21 Feb 2012 14:59:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10846957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:59:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 14:59:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzrBV-0001Uo-9n;
	Tue, 21 Feb 2012 14:59:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzrBV-0001DX-9K;
	Tue, 21 Feb 2012 14:59:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11995-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 14:59:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11995: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11995 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11995/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11988

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 14:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 14:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrBd-0001zQ-O0; Tue, 21 Feb 2012 14:59:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzrBc-0001yq-8Q
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 14:59:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329836358!12379241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10669 invoked from network); 21 Feb 2012 14:59:18 -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;
	21 Feb 2012 14:59:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10846957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 14:59:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 14:59:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzrBV-0001Uo-9n;
	Tue, 21 Feb 2012 14:59:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzrBV-0001DX-9K;
	Tue, 21 Feb 2012 14:59:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11995-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 14:59:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11995: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11995 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11995/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11988

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzrEJ-0002EQ-Ao; Tue, 21 Feb 2012 15:02:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzrEI-0002E4-5G
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:02:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329836522!3835942!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30198 invoked from network); 21 Feb 2012 15:02:03 -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; 21 Feb 2012 15:02:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LF207p005787
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:02: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
	q1LF1wsM019693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:01:59 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
	q1LF1w5t009323; Tue, 21 Feb 2012 09:01:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 07:01:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D81D940469; Tue, 21 Feb 2012 09:58:44 -0500 (EST)
Date: Tue, 21 Feb 2012 09:58:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Noonan <snoonan@amazon.com>
Message-ID: <20120221145844.GA7390@phenom.dumpdata.com>
References: <1329509084-26013-1-git-send-email-snoonan@amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329509084-26013-1-git-send-email-snoonan@amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F43B1E9.0044,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: make blkif_io_lock spinlock
	per-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 Fri, Feb 17, 2012 at 12:04:44PM -0800, Steven Noonan wrote:
> This patch moves the global blkif_io_lock to the per-device structure. The
> spinlock seems to exists for two reasons: to disable IRQs when in the interrupt
> handlers for blkfront, and to protect the blkfront VBDs when a detachment is
> requested.
> 
> Having a global blkif_io_lock doesn't make sense given the use case, and it
> drastically hinders performance due to contention. All VBDs with pending IOs
> have to take the lock in order to get work done, which serializes everything
> pretty badly.

applied in #testing.

> 
> Signed-off-by: Steven Noonan <snoonan@amazon.com>
> ---
>  drivers/block/xen-blkfront.c |   32 ++++++++++++++++----------------
>  1 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 7b2ec59..df9b8da 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -81,6 +81,7 @@ static const struct block_device_operations xlvbd_block_fops;
>   */
>  struct blkfront_info
>  {
> +	spinlock_t io_lock;
>  	struct mutex mutex;
>  	struct xenbus_device *xbdev;
>  	struct gendisk *gd;
> @@ -104,8 +105,6 @@ struct blkfront_info
>  	int is_ready;
>  };
>  
> -static DEFINE_SPINLOCK(blkif_io_lock);
> -
>  static unsigned int nr_minors;
>  static unsigned long *minors;
>  static DEFINE_SPINLOCK(minor_lock);
> @@ -413,7 +412,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  	struct request_queue *rq;
>  	struct blkfront_info *info = gd->private_data;
>  
> -	rq = blk_init_queue(do_blkif_request, &blkif_io_lock);
> +	rq = blk_init_queue(do_blkif_request, &info->io_lock);
>  	if (rq == NULL)
>  		return -1;
>  
> @@ -628,14 +627,14 @@ static void xlvbd_release_gendisk(struct blkfront_info *info)
>  	if (info->rq == NULL)
>  		return;
>  
> -	spin_lock_irqsave(&blkif_io_lock, flags);
> +	spin_lock_irqsave(&info->io_lock, flags);
>  
>  	/* No more blkif_request(). */
>  	blk_stop_queue(info->rq);
>  
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
> -	spin_unlock_irqrestore(&blkif_io_lock, flags);
> +	spin_unlock_irqrestore(&info->io_lock, flags);
>  
>  	/* Flush gnttab callback work. Must be done with no locks held. */
>  	flush_work_sync(&info->work);
> @@ -667,16 +666,16 @@ static void blkif_restart_queue(struct work_struct *work)
>  {
>  	struct blkfront_info *info = container_of(work, struct blkfront_info, work);
>  
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  	if (info->connected == BLKIF_STATE_CONNECTED)
>  		kick_pending_request_queues(info);
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  }
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
>  	/* Prevent new requests being issued until we fix things up. */
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
>  		BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
>  	/* No more blkif_request(). */
> @@ -684,7 +683,7 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  		blk_stop_queue(info->rq);
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  
>  	/* Flush gnttab callback work. Must be done with no locks held. */
>  	flush_work_sync(&info->work);
> @@ -718,10 +717,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  	struct blkfront_info *info = (struct blkfront_info *)dev_id;
>  	int error;
>  
> -	spin_lock_irqsave(&blkif_io_lock, flags);
> +	spin_lock_irqsave(&info->io_lock, flags);
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED)) {
> -		spin_unlock_irqrestore(&blkif_io_lock, flags);
> +		spin_unlock_irqrestore(&info->io_lock, flags);
>  		return IRQ_HANDLED;
>  	}
>  
> @@ -803,7 +802,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  
>  	kick_pending_request_queues(info);
>  
> -	spin_unlock_irqrestore(&blkif_io_lock, flags);
> +	spin_unlock_irqrestore(&info->io_lock, flags);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -978,6 +977,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	}
>  
>  	mutex_init(&info->mutex);
> +	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
> @@ -1053,7 +1053,7 @@ static int blkif_recover(struct blkfront_info *info)
>  
>  	xenbus_switch_state(info->xbdev, XenbusStateConnected);
>  
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  
>  	/* Now safe for us to use the shared ring */
>  	info->connected = BLKIF_STATE_CONNECTED;
> @@ -1064,7 +1064,7 @@ static int blkif_recover(struct blkfront_info *info)
>  	/* Kick any other new requests queued since we resumed */
>  	kick_pending_request_queues(info);
>  
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  
>  	return 0;
>  }
> @@ -1254,10 +1254,10 @@ static void blkfront_connect(struct blkfront_info *info)
>  	xenbus_switch_state(info->xbdev, XenbusStateConnected);
>  
>  	/* Kick pending requests. */
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  	info->connected = BLKIF_STATE_CONNECTED;
>  	kick_pending_request_queues(info);
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  
>  	add_disk(info->gd);
>  
> -- 
> 1.7.9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzrEJ-0002EQ-Ao; Tue, 21 Feb 2012 15:02:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzrEI-0002E4-5G
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:02:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329836522!3835942!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30198 invoked from network); 21 Feb 2012 15:02:03 -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; 21 Feb 2012 15:02:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LF207p005787
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:02: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
	q1LF1wsM019693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:01:59 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
	q1LF1w5t009323; Tue, 21 Feb 2012 09:01:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 07:01:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D81D940469; Tue, 21 Feb 2012 09:58:44 -0500 (EST)
Date: Tue, 21 Feb 2012 09:58:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Noonan <snoonan@amazon.com>
Message-ID: <20120221145844.GA7390@phenom.dumpdata.com>
References: <1329509084-26013-1-git-send-email-snoonan@amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329509084-26013-1-git-send-email-snoonan@amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F43B1E9.0044,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: make blkif_io_lock spinlock
	per-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 Fri, Feb 17, 2012 at 12:04:44PM -0800, Steven Noonan wrote:
> This patch moves the global blkif_io_lock to the per-device structure. The
> spinlock seems to exists for two reasons: to disable IRQs when in the interrupt
> handlers for blkfront, and to protect the blkfront VBDs when a detachment is
> requested.
> 
> Having a global blkif_io_lock doesn't make sense given the use case, and it
> drastically hinders performance due to contention. All VBDs with pending IOs
> have to take the lock in order to get work done, which serializes everything
> pretty badly.

applied in #testing.

> 
> Signed-off-by: Steven Noonan <snoonan@amazon.com>
> ---
>  drivers/block/xen-blkfront.c |   32 ++++++++++++++++----------------
>  1 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 7b2ec59..df9b8da 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -81,6 +81,7 @@ static const struct block_device_operations xlvbd_block_fops;
>   */
>  struct blkfront_info
>  {
> +	spinlock_t io_lock;
>  	struct mutex mutex;
>  	struct xenbus_device *xbdev;
>  	struct gendisk *gd;
> @@ -104,8 +105,6 @@ struct blkfront_info
>  	int is_ready;
>  };
>  
> -static DEFINE_SPINLOCK(blkif_io_lock);
> -
>  static unsigned int nr_minors;
>  static unsigned long *minors;
>  static DEFINE_SPINLOCK(minor_lock);
> @@ -413,7 +412,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  	struct request_queue *rq;
>  	struct blkfront_info *info = gd->private_data;
>  
> -	rq = blk_init_queue(do_blkif_request, &blkif_io_lock);
> +	rq = blk_init_queue(do_blkif_request, &info->io_lock);
>  	if (rq == NULL)
>  		return -1;
>  
> @@ -628,14 +627,14 @@ static void xlvbd_release_gendisk(struct blkfront_info *info)
>  	if (info->rq == NULL)
>  		return;
>  
> -	spin_lock_irqsave(&blkif_io_lock, flags);
> +	spin_lock_irqsave(&info->io_lock, flags);
>  
>  	/* No more blkif_request(). */
>  	blk_stop_queue(info->rq);
>  
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
> -	spin_unlock_irqrestore(&blkif_io_lock, flags);
> +	spin_unlock_irqrestore(&info->io_lock, flags);
>  
>  	/* Flush gnttab callback work. Must be done with no locks held. */
>  	flush_work_sync(&info->work);
> @@ -667,16 +666,16 @@ static void blkif_restart_queue(struct work_struct *work)
>  {
>  	struct blkfront_info *info = container_of(work, struct blkfront_info, work);
>  
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  	if (info->connected == BLKIF_STATE_CONNECTED)
>  		kick_pending_request_queues(info);
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  }
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
>  	/* Prevent new requests being issued until we fix things up. */
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
>  		BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
>  	/* No more blkif_request(). */
> @@ -684,7 +683,7 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  		blk_stop_queue(info->rq);
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  
>  	/* Flush gnttab callback work. Must be done with no locks held. */
>  	flush_work_sync(&info->work);
> @@ -718,10 +717,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  	struct blkfront_info *info = (struct blkfront_info *)dev_id;
>  	int error;
>  
> -	spin_lock_irqsave(&blkif_io_lock, flags);
> +	spin_lock_irqsave(&info->io_lock, flags);
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED)) {
> -		spin_unlock_irqrestore(&blkif_io_lock, flags);
> +		spin_unlock_irqrestore(&info->io_lock, flags);
>  		return IRQ_HANDLED;
>  	}
>  
> @@ -803,7 +802,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  
>  	kick_pending_request_queues(info);
>  
> -	spin_unlock_irqrestore(&blkif_io_lock, flags);
> +	spin_unlock_irqrestore(&info->io_lock, flags);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -978,6 +977,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	}
>  
>  	mutex_init(&info->mutex);
> +	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
> @@ -1053,7 +1053,7 @@ static int blkif_recover(struct blkfront_info *info)
>  
>  	xenbus_switch_state(info->xbdev, XenbusStateConnected);
>  
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  
>  	/* Now safe for us to use the shared ring */
>  	info->connected = BLKIF_STATE_CONNECTED;
> @@ -1064,7 +1064,7 @@ static int blkif_recover(struct blkfront_info *info)
>  	/* Kick any other new requests queued since we resumed */
>  	kick_pending_request_queues(info);
>  
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  
>  	return 0;
>  }
> @@ -1254,10 +1254,10 @@ static void blkfront_connect(struct blkfront_info *info)
>  	xenbus_switch_state(info->xbdev, XenbusStateConnected);
>  
>  	/* Kick pending requests. */
> -	spin_lock_irq(&blkif_io_lock);
> +	spin_lock_irq(&info->io_lock);
>  	info->connected = BLKIF_STATE_CONNECTED;
>  	kick_pending_request_queues(info);
> -	spin_unlock_irq(&blkif_io_lock);
> +	spin_unlock_irq(&info->io_lock);
>  
>  	add_disk(info->gd);
>  
> -- 
> 1.7.9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:02:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrES-0002FR-Ng; Tue, 21 Feb 2012 15:02:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzrEQ-0002F5-A5
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:02:19 +0000
Received: from [85.158.139.83:8632] by server-4.bemta-5.messagelabs.com id
	BC/D1-10788-9F1B34F4; Tue, 21 Feb 2012 15:02:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329836535!15991440!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27344 invoked from network); 21 Feb 2012 15:02:16 -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; 21 Feb 2012 15:02: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 q1LF290V002235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:02:10 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
	q1LF2935029708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:02:09 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
	q1LF28he005317; Tue, 21 Feb 2012 09:02:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 07:02:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5DEA840469; Tue, 21 Feb 2012 09:58:54 -0500 (EST)
Date: Tue, 21 Feb 2012 09:58:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120221145854.GB7390@phenom.dumpdata.com>
References: <1329394585-10129-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329394585-10129-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F43B1F4.0014,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after
	getting it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> We should hang onto bdev until we're done with it.

applied in #testing
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..5d45688 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	mutex_lock(&blkfront_mutex);
>  
>  	bdev = bdget_disk(disk, 0);
> -	bdput(bdev);
>  
>  	if (bdev->bd_openers)
>  		goto out;
> @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	}
>  
>  out:
> +	bdput(bdev);
>  	mutex_unlock(&blkfront_mutex);
>  	return 0;
>  }
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:02:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrES-0002FR-Ng; Tue, 21 Feb 2012 15:02:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzrEQ-0002F5-A5
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:02:19 +0000
Received: from [85.158.139.83:8632] by server-4.bemta-5.messagelabs.com id
	BC/D1-10788-9F1B34F4; Tue, 21 Feb 2012 15:02:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329836535!15991440!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27344 invoked from network); 21 Feb 2012 15:02:16 -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; 21 Feb 2012 15:02: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 q1LF290V002235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:02:10 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
	q1LF2935029708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:02:09 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
	q1LF28he005317; Tue, 21 Feb 2012 09:02:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 07:02:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5DEA840469; Tue, 21 Feb 2012 09:58:54 -0500 (EST)
Date: Tue, 21 Feb 2012 09:58:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120221145854.GB7390@phenom.dumpdata.com>
References: <1329394585-10129-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329394585-10129-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F43B1F4.0014,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after
	getting it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> We should hang onto bdev until we're done with it.

applied in #testing
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/block/xen-blkfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..5d45688 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	mutex_lock(&blkfront_mutex);
>  
>  	bdev = bdget_disk(disk, 0);
> -	bdput(bdev);
>  
>  	if (bdev->bd_openers)
>  		goto out;
> @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
>  	}
>  
>  out:
> +	bdput(bdev);
>  	mutex_unlock(&blkfront_mutex);
>  	return 0;
>  }
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrIJ-0002bu-Dr; Tue, 21 Feb 2012 15:06:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1RzrII-0002bh-26
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:06:18 +0000
Received: from [85.158.139.83:2709] by server-11.bemta-5.messagelabs.com id
	C3/BD-14397-9E2B34F4; Tue, 21 Feb 2012 15:06:17 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329836775!15966599!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1429 invoked from network); 21 Feb 2012 15:06:16 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:06:16 -0000
Received: by iaeh11 with SMTP id h11so50689665iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 07:06:14 -0800 (PST)
Received-SPF: pass (google.com: domain of avscomputing@gmail.com designates
	10.50.203.98 as permitted sender) client-ip=10.50.203.98; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of avscomputing@gmail.com
	designates 10.50.203.98 as permitted sender)
	smtp.mail=avscomputing@gmail.com;
	dkim=pass header.i=avscomputing@gmail.com
Received: from mr.google.com ([10.50.203.98])
	by 10.50.203.98 with SMTP id kp2mr20203474igc.5.1329836774847 (num_hops
	= 1); Tue, 21 Feb 2012 07:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=iRhRA4yCZXy3JIpjkj/+Ye/h0E9JC/TI8AUWPuEhYe4=;
	b=mGIzYPQ9u6N31YU4ZUndNhu6EeFz2CbE7EpjM3YooA1Un2qcd/gA5Lyr3fGp60Rzez
	YlOdHHrt5UsQk4SKbxRuO1l1eQX+ObUiW8ljaN+e2nA9cKcQyH+6g/MhevdfvmipRwvV
	9Q3VXCEAX/UocuTs+YLgu5HR8CjdH8JAPex6Y=
MIME-Version: 1.0
Received: by 10.50.203.98 with SMTP id kp2mr16317388igc.5.1329836774795; Tue,
	21 Feb 2012 07:06:14 -0800 (PST)
Received: by 10.231.68.203 with HTTP; Tue, 21 Feb 2012 07:06:14 -0800 (PST)
In-Reply-To: <20120215183122.GO12984@reaktio.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
Date: Tue, 21 Feb 2012 18:06:14 +0300
Message-ID: <CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/15 Pasi K=E4rkk=E4inen <pasik@iki.fi>:

AS>> Unfortunately, I'm not skilled at compiling the kernel myself.
AS>> I tried building the newest 3.2.6 with all Xen options enabled,
AS>> but the resulting system didn't have netback.ko module at all,
AS>> barely booted, and xm was not able to communicate with VMM.

PK> About compiling the dom0 kernel, see this wiki page:
PK> http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_suppo=
rt

Thanks, it looks like I just messed some "y" with "m" and vice versa
("m" is presented as a meaningless bullet in GUI). By the way, that how-to
contains dubious lines for CONFIG_XEN_DEV_EVTCHN and CONFIG_XEN_GNTDEV.

Well, now the system boots more eagerly, although the kernel still
seems to be slightly incompatible with distro's environment and my hardware.
But at least xend is now responding and is able to run DomUs as usual.


I started and stopped all the swarm of VMs several times (without letting t=
hem
to run for some time), and observed no GPF. But instead of this I get
screen garbling: while a DomU is starting or stopping, the whole graphical
desktop is sometimes painted with either black or not-so-random garbage,
and even mouse pointer can become garbled; I have to move / resize windows
to get them repainted. Network connectivity between Dom0 and [subsequently
started] DomUs does not break though.

On one hand, I am not sure whether the video driver is not to be
blamed for glitches,
because graphics already does not work as usual: it is not hardware-acceler=
ated
with my custom kernel (while it is with stock kernel), and the screen is ga=
rbled
on Xorg startup, before login promt is displayed. On the other hand, this i=
s not
in any way normal, as Xen operations must not interfere with Dom0's desktop
(or was it direct VRAM corruption?).

This happens even when "suspicious" domains (NetBSD with CARP) are not
started: on a freshly booted Dom0, just having 4 essential DomUs is enough
to get that screen garbling when shutting down 1 or 2 of them for the
first time.


But when I return to stock kernel, I can run a dozen of such DomUs (includi=
ng
those NetBSD load-balancers), starting and stopping them many times
without a problem. Recently, no GPF occurred when only 1 out of 2 balancers
is started, or none of them started at all; or it just needs much more upti=
me
to accumulate memory corruption for a GPF.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrIJ-0002bu-Dr; Tue, 21 Feb 2012 15:06:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1RzrII-0002bh-26
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:06:18 +0000
Received: from [85.158.139.83:2709] by server-11.bemta-5.messagelabs.com id
	C3/BD-14397-9E2B34F4; Tue, 21 Feb 2012 15:06:17 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329836775!15966599!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1429 invoked from network); 21 Feb 2012 15:06:16 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:06:16 -0000
Received: by iaeh11 with SMTP id h11so50689665iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 07:06:14 -0800 (PST)
Received-SPF: pass (google.com: domain of avscomputing@gmail.com designates
	10.50.203.98 as permitted sender) client-ip=10.50.203.98; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of avscomputing@gmail.com
	designates 10.50.203.98 as permitted sender)
	smtp.mail=avscomputing@gmail.com;
	dkim=pass header.i=avscomputing@gmail.com
Received: from mr.google.com ([10.50.203.98])
	by 10.50.203.98 with SMTP id kp2mr20203474igc.5.1329836774847 (num_hops
	= 1); Tue, 21 Feb 2012 07:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=iRhRA4yCZXy3JIpjkj/+Ye/h0E9JC/TI8AUWPuEhYe4=;
	b=mGIzYPQ9u6N31YU4ZUndNhu6EeFz2CbE7EpjM3YooA1Un2qcd/gA5Lyr3fGp60Rzez
	YlOdHHrt5UsQk4SKbxRuO1l1eQX+ObUiW8ljaN+e2nA9cKcQyH+6g/MhevdfvmipRwvV
	9Q3VXCEAX/UocuTs+YLgu5HR8CjdH8JAPex6Y=
MIME-Version: 1.0
Received: by 10.50.203.98 with SMTP id kp2mr16317388igc.5.1329836774795; Tue,
	21 Feb 2012 07:06:14 -0800 (PST)
Received: by 10.231.68.203 with HTTP; Tue, 21 Feb 2012 07:06:14 -0800 (PST)
In-Reply-To: <20120215183122.GO12984@reaktio.net>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
Date: Tue, 21 Feb 2012 18:06:14 +0300
Message-ID: <CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/15 Pasi K=E4rkk=E4inen <pasik@iki.fi>:

AS>> Unfortunately, I'm not skilled at compiling the kernel myself.
AS>> I tried building the newest 3.2.6 with all Xen options enabled,
AS>> but the resulting system didn't have netback.ko module at all,
AS>> barely booted, and xm was not able to communicate with VMM.

PK> About compiling the dom0 kernel, see this wiki page:
PK> http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_suppo=
rt

Thanks, it looks like I just messed some "y" with "m" and vice versa
("m" is presented as a meaningless bullet in GUI). By the way, that how-to
contains dubious lines for CONFIG_XEN_DEV_EVTCHN and CONFIG_XEN_GNTDEV.

Well, now the system boots more eagerly, although the kernel still
seems to be slightly incompatible with distro's environment and my hardware.
But at least xend is now responding and is able to run DomUs as usual.


I started and stopped all the swarm of VMs several times (without letting t=
hem
to run for some time), and observed no GPF. But instead of this I get
screen garbling: while a DomU is starting or stopping, the whole graphical
desktop is sometimes painted with either black or not-so-random garbage,
and even mouse pointer can become garbled; I have to move / resize windows
to get them repainted. Network connectivity between Dom0 and [subsequently
started] DomUs does not break though.

On one hand, I am not sure whether the video driver is not to be
blamed for glitches,
because graphics already does not work as usual: it is not hardware-acceler=
ated
with my custom kernel (while it is with stock kernel), and the screen is ga=
rbled
on Xorg startup, before login promt is displayed. On the other hand, this i=
s not
in any way normal, as Xen operations must not interfere with Dom0's desktop
(or was it direct VRAM corruption?).

This happens even when "suspicious" domains (NetBSD with CARP) are not
started: on a freshly booted Dom0, just having 4 essential DomUs is enough
to get that screen garbling when shutting down 1 or 2 of them for the
first time.


But when I return to stock kernel, I can run a dozen of such DomUs (includi=
ng
those NetBSD load-balancers), starting and stopping them many times
without a problem. Recently, no GPF occurred when only 1 out of 2 balancers
is started, or none of them started at all; or it just needs much more upti=
me
to accumulate memory corruption for a GPF.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrPx-0002uk-OV; Tue, 21 Feb 2012 15:14:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzrPw-0002uY-1s
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:14:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329837245!14231984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8166 invoked from network); 21 Feb 2012 15:14:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:14:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:14:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:14:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzrPp-0001cG-HT; Tue, 21 Feb 2012 15:14:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzrPp-0008WG-Ge;
	Tue, 21 Feb 2012 15:14:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.46269.502471.996774@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:14:05 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329831808.3990.83.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > xen-unstable's Config.mk ?  That's what I do with
> > qemu-xen-unstable.git.
> 
> That would make master rebasing. I'm happy to do that if there is
> consensus that it is ok.

Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrPx-0002uk-OV; Tue, 21 Feb 2012 15:14:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzrPw-0002uY-1s
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:14:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329837245!14231984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8166 invoked from network); 21 Feb 2012 15:14:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:14:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:14:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:14:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzrPp-0001cG-HT; Tue, 21 Feb 2012 15:14:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzrPp-0008WG-Ge;
	Tue, 21 Feb 2012 15:14:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.46269.502471.996774@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:14:05 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329831808.3990.83.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > xen-unstable's Config.mk ?  That's what I do with
> > qemu-xen-unstable.git.
> 
> That would make master rebasing. I'm happy to do that if there is
> consensus that it is ok.

Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzrSG-000323-Cf; Tue, 21 Feb 2012 15:16:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzrSF-00031m-3X
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:16:35 +0000
Received: from [85.158.139.83:35294] by server-2.bemta-5.messagelabs.com id
	5F/30-20263-255B34F4; Tue, 21 Feb 2012 15:16:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329837393!16003930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24742 invoked from network); 21 Feb 2012 15:16:33 -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;
	21 Feb 2012 15:16:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:16:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:16:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzrSC-0001gw-Vu	for xen-devel@lists.xensource.com;
	Tue, 21 Feb 2012 15:16:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzrSC-000050-VA	for
	xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:16:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.46416.936156.684538@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:16:32 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11995-mainreport@xen.org>
References: <osstest-11995-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11995: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 11995: regressions - FAIL"):
> flight 11995 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11995/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           4 xen-build              fail REGR. vs. 11986

This is an infrastructure problem, not a real failure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzrSG-000323-Cf; Tue, 21 Feb 2012 15:16:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzrSF-00031m-3X
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:16:35 +0000
Received: from [85.158.139.83:35294] by server-2.bemta-5.messagelabs.com id
	5F/30-20263-255B34F4; Tue, 21 Feb 2012 15:16:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329837393!16003930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24742 invoked from network); 21 Feb 2012 15:16:33 -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;
	21 Feb 2012 15:16:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:16:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:16:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzrSC-0001gw-Vu	for xen-devel@lists.xensource.com;
	Tue, 21 Feb 2012 15:16:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzrSC-000050-VA	for
	xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:16:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.46416.936156.684538@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:16:32 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11995-mainreport@xen.org>
References: <osstest-11995-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11995: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 11995: regressions - FAIL"):
> flight 11995 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11995/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           4 xen-build              fail REGR. vs. 11986

This is an infrastructure problem, not a real failure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:17:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrSw-00037y-Qh; Tue, 21 Feb 2012 15:17:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzrSv-00037O-4R
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:17:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329837430!10238969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29730 invoked from network); 21 Feb 2012 15:17:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:17:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:17:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:17:10 +0000
Message-ID: <1329837427.3990.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:17:07 +0000
In-Reply-To: <1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/7] arm: compile 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 Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> 
> +static int
> +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context
> *dinfo, xc_dominfo_t *info,
> +                        shared_info_any_t *live_shinfo, xen_pfn_t
> **live_p2m,
> +                        unsigned long *pfnp, int rw)
> +{
> +    return -ENOSYS;

I only just noticed this: libxc is supposed to set errno and return -1,
not return -Efoo.

There's a few of these in this series. I actually noticed it in
xc_hvm_build_arm.c but this was the first one I came across when
grepping my mail.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:17:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrSw-00037y-Qh; Tue, 21 Feb 2012 15:17:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzrSv-00037O-4R
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:17:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1329837430!10238969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29730 invoked from network); 21 Feb 2012 15:17:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:17:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:17:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:17:10 +0000
Message-ID: <1329837427.3990.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:17:07 +0000
In-Reply-To: <1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/7] arm: compile 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 Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> 
> +static int
> +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context
> *dinfo, xc_dominfo_t *info,
> +                        shared_info_any_t *live_shinfo, xen_pfn_t
> **live_p2m,
> +                        unsigned long *pfnp, int rw)
> +{
> +    return -ENOSYS;

I only just noticed this: libxc is supposed to set errno and return -1,
not return -Efoo.

There's a few of these in this series. I actually noticed it in
xc_hvm_build_arm.c but this was the first one I came across when
grepping my mail.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzrTl-0003EF-9B; Tue, 21 Feb 2012 15:18:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzrTk-0003E6-Ef
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:18:08 +0000
Received: from [85.158.139.83:20331] by server-11.bemta-5.messagelabs.com id
	A9/32-14397-FA5B34F4; Tue, 21 Feb 2012 15:18:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329837487!16013815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8317 invoked from network); 21 Feb 2012 15:18:07 -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;
	21 Feb 2012 15:18:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:18:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:18:07 +0000
Message-ID: <1329837485.3990.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:18:05 +0000
In-Reply-To: <20291.46269.502471.996774@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 15:14 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > > xen-unstable's Config.mk ?  That's what I do with
> > > qemu-xen-unstable.git.
> > 
> > That would make master rebasing. I'm happy to do that if there is
> > consensus that it is ok.
> 
> Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.

SEABIOS_UPSTREAM_TAG is tracking an upstream stable branch. When they
release a new stable release we will want to switch to that, but that
will not be a fast-forward.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzrTl-0003EF-9B; Tue, 21 Feb 2012 15:18:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzrTk-0003E6-Ef
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:18:08 +0000
Received: from [85.158.139.83:20331] by server-11.bemta-5.messagelabs.com id
	A9/32-14397-FA5B34F4; Tue, 21 Feb 2012 15:18:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1329837487!16013815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8317 invoked from network); 21 Feb 2012 15:18:07 -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;
	21 Feb 2012 15:18:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:18:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:18:07 +0000
Message-ID: <1329837485.3990.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:18:05 +0000
In-Reply-To: <20291.46269.502471.996774@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 15:14 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > > xen-unstable's Config.mk ?  That's what I do with
> > > qemu-xen-unstable.git.
> > 
> > That would make master rebasing. I'm happy to do that if there is
> > consensus that it is ok.
> 
> Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.

SEABIOS_UPSTREAM_TAG is tracking an upstream stable branch. When they
release a new stable release we will want to switch to that, but that
will not be a fast-forward.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:21:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrXH-0003dS-Vu; Tue, 21 Feb 2012 15:21:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzrXG-0003cm-Ez
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:21:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329837684!12573322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9217 invoked from network); 21 Feb 2012 15:21:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:21:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:21:24 +0000
Message-ID: <1329837682.3990.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 21 Feb 2012 15:21:22 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, February 21, 2012 3:47 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> > 
> > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > Updates to the layout of the HVM parameter and information page
> > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > written to the bottom half of this page.
> > 
> > We would like to eventually get rid of the HVM info page and would
> > certainly like to avoid adding anything further there. Could this data
> > not be supplied via xenstore? Certainly they could and should be for the
> > ones controlled by the flags entry which you add.
> > 
> > Ian.
> > 
> 
> Ah I did not realize that. The original incarnation of this code came
> from 2+ years ago. I have no objection to using xenstore but I did not
> think xenstore was suitable for passing arbitrary blocks of binary
> data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in
> this assumption.

I think in principal binary data is supported, but its use is
discouraged. docs/misc/xenstore.txt talks about it a bit.

For well defined entries it should be reasonable to have human readable
content in xenstore which simply enable/disables the table and perhaps
contains some configuration values as appropriate.

For adding arbitrary tables I'm less sure what the right answer is.
Common header elements in human readable form, payload as hex encoded
strings or something? Seems a bit icky though.

> I am not sure what other mechanisms could be employed. In other code I
> use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime.
> I use a little DMAish interface I built into qemu to push the SSDT to
> hvmloader while it is building the ACPI tables. Something like this
> could be used but I don't really want to get qemu involved in this
> operation.

Yes, I think we should avoid that too.

> I guess a third option might be to have a facility to load extra
> modules/files into the new domain at start time and specify their
> gpa's in xenstore. They could then be discarded after the initial
> domain setup is complete.

That might work. What do others around here think?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:21:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrXH-0003dS-Vu; Tue, 21 Feb 2012 15:21:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzrXG-0003cm-Ez
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:21:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329837684!12573322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9217 invoked from network); 21 Feb 2012 15:21:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:21:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:21:24 +0000
Message-ID: <1329837682.3990.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Tue, 21 Feb 2012 15:21:22 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, February 21, 2012 3:47 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> > 
> > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > Updates to the layout of the HVM parameter and information page
> > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > written to the bottom half of this page.
> > 
> > We would like to eventually get rid of the HVM info page and would
> > certainly like to avoid adding anything further there. Could this data
> > not be supplied via xenstore? Certainly they could and should be for the
> > ones controlled by the flags entry which you add.
> > 
> > Ian.
> > 
> 
> Ah I did not realize that. The original incarnation of this code came
> from 2+ years ago. I have no objection to using xenstore but I did not
> think xenstore was suitable for passing arbitrary blocks of binary
> data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in
> this assumption.

I think in principal binary data is supported, but its use is
discouraged. docs/misc/xenstore.txt talks about it a bit.

For well defined entries it should be reasonable to have human readable
content in xenstore which simply enable/disables the table and perhaps
contains some configuration values as appropriate.

For adding arbitrary tables I'm less sure what the right answer is.
Common header elements in human readable form, payload as hex encoded
strings or something? Seems a bit icky though.

> I am not sure what other mechanisms could be employed. In other code I
> use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime.
> I use a little DMAish interface I built into qemu to push the SSDT to
> hvmloader while it is building the ACPI tables. Something like this
> could be used but I don't really want to get qemu involved in this
> operation.

Yes, I think we should avoid that too.

> I guess a third option might be to have a facility to load extra
> modules/files into the new domain at start time and specify their
> gpa's in xenstore. They could then be discarded after the initial
> domain setup is complete.

That might work. What do others around here think?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:28:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrdE-0003zW-V0; Tue, 21 Feb 2012 15:27:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RzrdD-0003zF-EV
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:27:55 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329838067!14290101!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6754 invoked from network); 21 Feb 2012 15:27:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 15:27:49 -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 q1LFRgO4006818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:27:43 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
	q1LFRfbK007269
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:27:42 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
	q1LFRfOv029802; Tue, 21 Feb 2012 09:27:41 -0600
MIME-Version: 1.0
Message-ID: <2b417c3e-8bfa-4c6e-9200-94bf34c02e17@default>
Date: Tue, 21 Feb 2012 07:27:32 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
	<1329819046.25232.69.camel@dagon.hellion.org.uk>
In-Reply-To: <1329819046.25232.69.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F43B7F0.0043,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests
> 
> On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
> > On Mon, 20 Feb 2012, Ian Jackson wrote:
> > > Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> > > > libxl: drop 8M slack for PV guests.
> > > >
> > > > As far as I can tell this serves no purpose. I think it relates to the old
> > > > 8M to "account for backend allocations" which we used to add. This leaves a bit
> > > > of unpopulated space in the Pseudo-physical address space which can be used by
> > > > backends when mapping foreign memory. However 8M is not representative of that
> > > > any more and modern kernels do not operate in this way anyway.
> > > >
> > > > I suspect an argument could be made for removing this from the libxl API
> > > > altogether but instead lets just set the overhead to 0.
> > >
> > > I think this is plausible but I'd like to hear from Stefano, who iirc
> > > may have some knowledge about the reason for this 8Mb.
> >
> > It comes from XenD (and XAPI too, if I recall correctly), see this
> > comment in tools/python/xen/xend/image.py:
> 
> That doesn't answer the "why" though.
> 
> I think I should just be more assertive since I believe I do actually
> know why the 8 is there (or certainly nobody appears to know any
> better). I'll update the changelog to read:
> 
>         This serves no purpose. It relates to the old 8M to "account for
>         backend allocations" which we used to add. This leaves a bit of
>         unpopulated space in the Pseudo-physical address space which can
>         be used by backends when mapping foreign memory. However 8M is
>         not representative of that any more and modern kernels do not
>         operate in this way anyway.

Hmmm... this adds a small, but not trivial, performance advantage to xl
over xm/xend, at least for small memory guests.  Might be a nice
second-tier bullet for the 4.2/xl release notes... "better performance"
always encourages people to move from old-to-new quicker even when
it is hard to quantify or measure.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:28:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzrdE-0003zW-V0; Tue, 21 Feb 2012 15:27:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RzrdD-0003zF-EV
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:27:55 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329838067!14290101!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6754 invoked from network); 21 Feb 2012 15:27:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 15:27:49 -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 q1LFRgO4006818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:27:43 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
	q1LFRfbK007269
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:27:42 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
	q1LFRfOv029802; Tue, 21 Feb 2012 09:27:41 -0600
MIME-Version: 1.0
Message-ID: <2b417c3e-8bfa-4c6e-9200-94bf34c02e17@default>
Date: Tue, 21 Feb 2012 07:27:32 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
References: <patchbomb.1329151966@cosworth.uk.xensource.com>
	<192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com>
	<20290.39907.912639.18195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1202211008060.23091@kaball-desktop>
	<1329819046.25232.69.camel@dagon.hellion.org.uk>
In-Reply-To: <1329819046.25232.69.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F43B7F0.0043,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV 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

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests
> 
> On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote:
> > On Mon, 20 Feb 2012, Ian Jackson wrote:
> > > Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"):
> > > > libxl: drop 8M slack for PV guests.
> > > >
> > > > As far as I can tell this serves no purpose. I think it relates to the old
> > > > 8M to "account for backend allocations" which we used to add. This leaves a bit
> > > > of unpopulated space in the Pseudo-physical address space which can be used by
> > > > backends when mapping foreign memory. However 8M is not representative of that
> > > > any more and modern kernels do not operate in this way anyway.
> > > >
> > > > I suspect an argument could be made for removing this from the libxl API
> > > > altogether but instead lets just set the overhead to 0.
> > >
> > > I think this is plausible but I'd like to hear from Stefano, who iirc
> > > may have some knowledge about the reason for this 8Mb.
> >
> > It comes from XenD (and XAPI too, if I recall correctly), see this
> > comment in tools/python/xen/xend/image.py:
> 
> That doesn't answer the "why" though.
> 
> I think I should just be more assertive since I believe I do actually
> know why the 8 is there (or certainly nobody appears to know any
> better). I'll update the changelog to read:
> 
>         This serves no purpose. It relates to the old 8M to "account for
>         backend allocations" which we used to add. This leaves a bit of
>         unpopulated space in the Pseudo-physical address space which can
>         be used by backends when mapping foreign memory. However 8M is
>         not representative of that any more and modern kernels do not
>         operate in this way anyway.

Hmmm... this adds a small, but not trivial, performance advantage to xl
over xm/xend, at least for small memory guests.  Might be a nice
second-tier bullet for the 4.2/xl release notes... "better performance"
always encourages people to move from old-to-new quicker even when
it is hard to quantify or measure.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzrh1-0004Dc-Cs; Tue, 21 Feb 2012 15:31:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzrgz-0004D0-QI
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:31:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329838303!3842884!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17405 invoked from network); 21 Feb 2012 15:31:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:31:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:31:43 +0000
Message-ID: <1329838302.3990.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:31:42 +0000
In-Reply-To: <1329837427.3990.110.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329837427.3990.110.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/7] arm: compile 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 Tue, 2012-02-21 at 15:17 +0000, Ian Campbell wrote:
> On Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> > 
> > +static int
> > +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context
> > *dinfo, xc_dominfo_t *info,
> > +                        shared_info_any_t *live_shinfo, xen_pfn_t
> > **live_p2m,
> > +                        unsigned long *pfnp, int rw)
> > +{
> > +    return -ENOSYS;
> 
> I only just noticed this: libxc is supposed to set errno and return -1,
> not return -Efoo.
> 
> There's a few of these in this series. I actually noticed it in
> xc_hvm_build_arm.c but this was the first one I came across when
> grepping my mail.

If you are resending, could you also add the emacs magic comments to the
tail of any new files.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzrh1-0004Dc-Cs; Tue, 21 Feb 2012 15:31:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzrgz-0004D0-QI
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:31:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329838303!3842884!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17405 invoked from network); 21 Feb 2012 15:31:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:31:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 15:31:43 +0000
Message-ID: <1329838302.3990.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:31:42 +0000
In-Reply-To: <1329837427.3990.110.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202151217060.7456@kaball-desktop>
	<1329308673-30175-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329837427.3990.110.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 2/7] arm: compile 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 Tue, 2012-02-21 at 15:17 +0000, Ian Campbell wrote:
> On Wed, 2012-02-15 at 12:24 +0000, Stefano Stabellini wrote:
> > 
> > +static int
> > +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context
> > *dinfo, xc_dominfo_t *info,
> > +                        shared_info_any_t *live_shinfo, xen_pfn_t
> > **live_p2m,
> > +                        unsigned long *pfnp, int rw)
> > +{
> > +    return -ENOSYS;
> 
> I only just noticed this: libxc is supposed to set errno and return -1,
> not return -Efoo.
> 
> There's a few of these in this series. I actually noticed it in
> xc_hvm_build_arm.c but this was the first one I came across when
> grepping my mail.

If you are resending, could you also add the emacs magic comments to the
tail of any new files.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzrh0-0004DU-K2; Tue, 21 Feb 2012 15:31:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzrgz-0004Cy-4c
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:31:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329838303!3842884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17371 invoked from network); 21 Feb 2012 15:31:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:31:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:31:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzrgs-0001n5-NF; Tue, 21 Feb 2012 15:31:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzrgs-00006H-LJ;
	Tue, 21 Feb 2012 15:31:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.47326.624920.309995@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:31:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329837485.3990.111.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> On Tue, 2012-02-21 at 15:14 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > > On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > > > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > > > xen-unstable's Config.mk ?  That's what I do with
> > > > qemu-xen-unstable.git.
> > > 
> > > That would make master rebasing. I'm happy to do that if there is
> > > consensus that it is ok.
> > 
> > Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.
> 
> SEABIOS_UPSTREAM_TAG is tracking an upstream stable branch. When they
> release a new stable release we will want to switch to that, but that
> will not be a fast-forward.

Hmm.  Well as to the question of what "master" should be:

If it's anything useful at all, it needs to be what you would need to
edit to change the result of the Xen build.  So either it must be
.._TAG or it must be some fast-forwarding branch constructed from the
series of _TAG values.  (Ie, a branch whose commits correspond 1:1
with _TAG values, each commit on the master branch having the previous
master commit as its left parent and the _TAG, which determines the
contents, as the right parent.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:32:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzrh0-0004DU-K2; Tue, 21 Feb 2012 15:31:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzrgz-0004Cy-4c
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:31:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329838303!3842884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17371 invoked from network); 21 Feb 2012 15:31:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10847982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:31:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:31:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzrgs-0001n5-NF; Tue, 21 Feb 2012 15:31:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzrgs-00006H-LJ;
	Tue, 21 Feb 2012 15:31:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.47326.624920.309995@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 15:31:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329837485.3990.111.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> On Tue, 2012-02-21 at 15:14 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > > On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > > > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > > > xen-unstable's Config.mk ?  That's what I do with
> > > > qemu-xen-unstable.git.
> > > 
> > > That would make master rebasing. I'm happy to do that if there is
> > > consensus that it is ok.
> > 
> > Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.
> 
> SEABIOS_UPSTREAM_TAG is tracking an upstream stable branch. When they
> release a new stable release we will want to switch to that, but that
> will not be a fast-forward.

Hmm.  Well as to the question of what "master" should be:

If it's anything useful at all, it needs to be what you would need to
edit to change the result of the Xen build.  So either it must be
.._TAG or it must be some fast-forwarding branch constructed from the
series of _TAG values.  (Ie, a branch whose commits correspond 1:1
with _TAG values, each commit on the master branch having the previous
master commit as its left parent and the _TAG, which determines the
contents, as the right parent.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:42:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzrql-0004jD-M1; Tue, 21 Feb 2012 15:41:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzrqk-0004j4-Nc
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:41:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329838906!9370176!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1535 invoked from network); 21 Feb 2012 15:41:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 15:41:48 -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 q1LFfh9a019401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:41:44 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
	q1LFfhim018375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:41:43 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
	q1LFfgpj004733; Tue, 21 Feb 2012 09:41:42 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 07:41:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 26DAD40469; Tue, 21 Feb 2012 10:38:28 -0500 (EST)
Date: Tue, 21 Feb 2012 10:38:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Rostedt <rostedt@goodmis.org>
Message-ID: <20120221153827.GA7529@phenom.dumpdata.com>
References: <20120214152955.GA17671@phenom.dumpdata.com>
	<1329243722.7469.7.camel@acer.local.home>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329243722.7469.7.camel@acer.local.home>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090208.4F43BB39.0002,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 14, 2012 at 01:22:02PM -0500, Steven Rostedt wrote:
> On Tue, 2012-02-14 at 10:29 -0500, Konrad Rzeszutek Wilk wrote: 
> > Hey,
> > 
> > I was running some benchmarks (netserver/netperf) where the init script just launched
> > the netserver and nothing else and was concerned to see the performance not up to par.
> > This was an HVM guest running with PV drivers.
> > 
> > If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better
> 
> There is a known performance degrade of 1 or 2% with function tracing
> enabled, on some work loads. Anything more that needs to be
> investigated.
> 
> Did you also keep FRAME_POINTERS enabled? FUNCTION_TRACER selects frame
> pointers which can also slow down the system.

Not yet. Doing the compile now.
> 
> > - but it was 
> > my understanding that the tracing code does not impact the machine unless it is enabled.
> > And when I inserted a bunch of print_dump_bytes I do see instructions such as
> > e8 6a 90 60 e1 get replaced with 66 66 66 90 so I see the the instructions getting
> > patched over.
> 
> Right on boot up (and module load) the calls do get changed to nops. Now
> note that there's some calls that do not get changed at boot up, but the
> most recent scripts/recordmcount.c should change them to nops at compile
> time.
> > 
> > To get a better feel for this I tried this on baremetal, and (this is going
> > to sound a bit round-about way, but please bear with me), I was working on making
> > the pte_flags be paravirt (so it is a function instead of being a macro) and noticed
> > that on on an AMD A8-3850, with a CONFIG_PARAVIRT and CONFIG_FUNCTION_TRACER and
> > running kernelbench it would run slower than without CONFIG_FUNCTION_TRACER.
> 
> Have you tried what the difference is between !CONFIG_PARAVIRT and with
> and without CONFIG_FUNCTION_TRACER?

Hadn't tried that, but let do that.

> 
> > 
> > I am not really sure what the problem is, but based on those experiments
> > four things come to my mind:
> >  - Lots of nops and we choke the CPU instruction decoder with 20-30 bytes
> >    of 'nop', so the CPU is stalling waiting for some real instructions.
> 
> But the nop is only placed at the beginning of functions.

Right, and I was thinking that with paravirt enabled that some of the operations
end up having nops as well. So you kind of get:
66 66 66 90 66 66 66 90 or more

Thought let me double check which instructions I was thinking of that
get patched over to NOPs when running with pvops under baremetal.

> 
> > - The compiler has choosen to compile most of the paravirt instructions as
> >    functions making the call to mcount (which gets patched over), but the
> >    end result is that we have an extra 'call' in the chain.
> 
> You mean that we get a lot more functions because the compiler made them
> functions? Maybe we should add "notrace" to all paravirt functions? Then
> they wont have the calls or nops.

<nods> Do you remember the rational of why some have notrace but not all?

> 
> > - Somehow the low-level para-virt (like the assembler ones) calls don't get
> >    patched over and still end up calling mcount? (but I really doubt that is the
> >    case - but you never know).
> 
> We only live patch code in a white list of sections. But with the latest
> scripts/recordmcount.c, as I stated above, the ones that don't get
> patched at boot up, should be patched at compile time. But that still
> keeps the nops there.

So the ideal_nop in the looks to be different from what the trace code
decides to patch during execution. Is that OK? I am not that familiar with the
variants of nops to know if some are just not ok on certain architectures?

> 
> > - Something else?
> > 
> > My thought was to crash the kernel as it is up and running and look at the
> > diassembled core to see what the instructions end up looking to get a further feel
> > for this.  But before I go with this are there some other ideas of what I should look
> > for?
> 
> You can just look at the objdump of vmlinux, as the recordmcount.c would
> have already patched the code that is not whitelisted, and you can also
> see if things are function calls.

OK. Let me start doing that.

Thank for your email with lots of hints/pointers to what to try out!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:42:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzrql-0004jD-M1; Tue, 21 Feb 2012 15:41:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzrqk-0004j4-Nc
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:41:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1329838906!9370176!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1535 invoked from network); 21 Feb 2012 15:41:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 15:41:48 -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 q1LFfh9a019401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 15:41:44 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
	q1LFfhim018375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 15:41:43 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
	q1LFfgpj004733; Tue, 21 Feb 2012 09:41:42 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 07:41:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 26DAD40469; Tue, 21 Feb 2012 10:38:28 -0500 (EST)
Date: Tue, 21 Feb 2012 10:38:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Rostedt <rostedt@goodmis.org>
Message-ID: <20120221153827.GA7529@phenom.dumpdata.com>
References: <20120214152955.GA17671@phenom.dumpdata.com>
	<1329243722.7469.7.camel@acer.local.home>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329243722.7469.7.camel@acer.local.home>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090208.4F43BB39.0002,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 14, 2012 at 01:22:02PM -0500, Steven Rostedt wrote:
> On Tue, 2012-02-14 at 10:29 -0500, Konrad Rzeszutek Wilk wrote: 
> > Hey,
> > 
> > I was running some benchmarks (netserver/netperf) where the init script just launched
> > the netserver and nothing else and was concerned to see the performance not up to par.
> > This was an HVM guest running with PV drivers.
> > 
> > If I compile the kernel without CONFIG_FUNCTION_TRACER it is much better
> 
> There is a known performance degrade of 1 or 2% with function tracing
> enabled, on some work loads. Anything more that needs to be
> investigated.
> 
> Did you also keep FRAME_POINTERS enabled? FUNCTION_TRACER selects frame
> pointers which can also slow down the system.

Not yet. Doing the compile now.
> 
> > - but it was 
> > my understanding that the tracing code does not impact the machine unless it is enabled.
> > And when I inserted a bunch of print_dump_bytes I do see instructions such as
> > e8 6a 90 60 e1 get replaced with 66 66 66 90 so I see the the instructions getting
> > patched over.
> 
> Right on boot up (and module load) the calls do get changed to nops. Now
> note that there's some calls that do not get changed at boot up, but the
> most recent scripts/recordmcount.c should change them to nops at compile
> time.
> > 
> > To get a better feel for this I tried this on baremetal, and (this is going
> > to sound a bit round-about way, but please bear with me), I was working on making
> > the pte_flags be paravirt (so it is a function instead of being a macro) and noticed
> > that on on an AMD A8-3850, with a CONFIG_PARAVIRT and CONFIG_FUNCTION_TRACER and
> > running kernelbench it would run slower than without CONFIG_FUNCTION_TRACER.
> 
> Have you tried what the difference is between !CONFIG_PARAVIRT and with
> and without CONFIG_FUNCTION_TRACER?

Hadn't tried that, but let do that.

> 
> > 
> > I am not really sure what the problem is, but based on those experiments
> > four things come to my mind:
> >  - Lots of nops and we choke the CPU instruction decoder with 20-30 bytes
> >    of 'nop', so the CPU is stalling waiting for some real instructions.
> 
> But the nop is only placed at the beginning of functions.

Right, and I was thinking that with paravirt enabled that some of the operations
end up having nops as well. So you kind of get:
66 66 66 90 66 66 66 90 or more

Thought let me double check which instructions I was thinking of that
get patched over to NOPs when running with pvops under baremetal.

> 
> > - The compiler has choosen to compile most of the paravirt instructions as
> >    functions making the call to mcount (which gets patched over), but the
> >    end result is that we have an extra 'call' in the chain.
> 
> You mean that we get a lot more functions because the compiler made them
> functions? Maybe we should add "notrace" to all paravirt functions? Then
> they wont have the calls or nops.

<nods> Do you remember the rational of why some have notrace but not all?

> 
> > - Somehow the low-level para-virt (like the assembler ones) calls don't get
> >    patched over and still end up calling mcount? (but I really doubt that is the
> >    case - but you never know).
> 
> We only live patch code in a white list of sections. But with the latest
> scripts/recordmcount.c, as I stated above, the ones that don't get
> patched at boot up, should be patched at compile time. But that still
> keeps the nops there.

So the ideal_nop in the looks to be different from what the trace code
decides to patch during execution. Is that OK? I am not that familiar with the
variants of nops to know if some are just not ok on certain architectures?

> 
> > - Something else?
> > 
> > My thought was to crash the kernel as it is up and running and look at the
> > diassembled core to see what the instructions end up looking to get a further feel
> > for this.  But before I go with this are there some other ideas of what I should look
> > for?
> 
> You can just look at the objdump of vmlinux, as the recordmcount.c would
> have already patched the code that is not whitelisted, and you can also
> see if things are function calls.

OK. Let me start doing that.

Thank for your email with lots of hints/pointers to what to try out!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:50:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzryF-00055y-L4; Tue, 21 Feb 2012 15:49: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 1RzryD-00055q-Q6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:49:38 +0000
Received: from [85.158.139.83:35035] by server-9.bemta-5.messagelabs.com id
	5D/5D-30171-11DB34F4; Tue, 21 Feb 2012 15:49:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329839376!15973424!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6941 invoked from network); 21 Feb 2012 15:49:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10848419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:49:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:49:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzryB-0001xW-PI;
	Tue, 21 Feb 2012 15:49:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzryB-0000Zk-Ok;
	Tue, 21 Feb 2012 15:49:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11996-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:49:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11996: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11996 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11996/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2    fail in 11994 REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11994
 build-amd64                   4 xen-build                   fail pass in 11994
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11994 pass in 11990

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  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-qemuu-rhel6hvm-intel  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-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-rhel6hvm-amd  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-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 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    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11994 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11994 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11994 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11994 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11994 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11994 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11994 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11994 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11994 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11994 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:50:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1RzryF-00055y-L4; Tue, 21 Feb 2012 15:49: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 1RzryD-00055q-Q6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:49:38 +0000
Received: from [85.158.139.83:35035] by server-9.bemta-5.messagelabs.com id
	5D/5D-30171-11DB34F4; Tue, 21 Feb 2012 15:49:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329839376!15973424!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6941 invoked from network); 21 Feb 2012 15:49:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 15:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10848419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 15:49:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 15:49:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzryB-0001xW-PI;
	Tue, 21 Feb 2012 15:49:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzryB-0000Zk-Ok;
	Tue, 21 Feb 2012 15:49:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11996-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 15:49:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11996: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11996 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11996/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2    fail in 11994 REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11994
 build-amd64                   4 xen-build                   fail pass in 11994
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11994 pass in 11990

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  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-qemuu-rhel6hvm-intel  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-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-rhel6hvm-amd  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-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 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    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11994 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11994 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11994 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11994 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11994 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11994 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11994 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11994 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11994 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11994 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1Rzs3i-0005Px-DG; Tue, 21 Feb 2012 15:55:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rostedt@goodmis.org>) id 1Rzs3h-0005PX-5s
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:55:17 +0000
X-Env-Sender: rostedt@goodmis.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329839710!12581290!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzg2NjQ0\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzg2NjQ0\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14625 invoked from network); 21 Feb 2012 15:55:10 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-8.tower-21.messagelabs.com with SMTP;
	21 Feb 2012 15:55:10 -0000
X-Authority-Analysis: v=2.0 cv=fNy7LOme c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17
	a=CvlS4R1r7kYA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10
	a=bNEnXefycaPkDHUF5vwA:9 a=PUjeQqilurYA:10
	a=ZycB6UtQUfgMyuk2+PxD7w==:117
X-Cloudmark-Score: 0
X-Originating-IP: 74.67.80.29
Received: from [74.67.80.29] ([74.67.80.29:46526] helo=[192.168.23.10])
	by hrndva-oedge03.mail.rr.com (envelope-from <rostedt@goodmis.org>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 2A/C4-11045-D5EB34F4; Tue, 21 Feb 2012 15:55:10 +0000
Message-ID: <1329839709.25686.63.camel@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 21 Feb 2012 10:55:09 -0500
In-Reply-To: <20120221153827.GA7529@phenom.dumpdata.com>
References: <20120214152955.GA17671@phenom.dumpdata.com>
	<1329243722.7469.7.camel@acer.local.home>
	<20120221153827.GA7529@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 10:38 -0500, Konrad Rzeszutek Wilk wrote:
>  
> > You mean that we get a lot more functions because the compiler made them
> > functions? Maybe we should add "notrace" to all paravirt functions? Then
> > they wont have the calls or nops.
> 
> <nods> Do you remember the rational of why some have notrace but not all?

They probably all should. Unless there's some reason people want to
trace those functions. But if they are not traced on bare-metal, then it
probably isn't worth tracing them on paravirt either.

> 
> > 
> > > - Somehow the low-level para-virt (like the assembler ones) calls don't get
> > >    patched over and still end up calling mcount? (but I really doubt that is the
> > >    case - but you never know).
> > 
> > We only live patch code in a white list of sections. But with the latest
> > scripts/recordmcount.c, as I stated above, the ones that don't get
> > patched at boot up, should be patched at compile time. But that still
> > keeps the nops there.
> 
> So the ideal_nop in the looks to be different from what the trace code
> decides to patch during execution. Is that OK? I am not that familiar with the
> variants of nops to know if some are just not ok on certain architectures?

What gets patched at compile time isn't the ideal for the arch. But it's
the "best" that can be done at that moment. But pretty much all of the
non ideal nops are patched over .init sections that are called only once
(at boot up). Even though they may not be the ideal nop for the running
box, it shouldn't be any noticeable overhead.

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15: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 1Rzs3i-0005Px-DG; Tue, 21 Feb 2012 15:55:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <rostedt@goodmis.org>) id 1Rzs3h-0005PX-5s
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 15:55:17 +0000
X-Env-Sender: rostedt@goodmis.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329839710!12581290!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzg2NjQ0\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gMzg2NjQ0\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14625 invoked from network); 21 Feb 2012 15:55:10 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-8.tower-21.messagelabs.com with SMTP;
	21 Feb 2012 15:55:10 -0000
X-Authority-Analysis: v=2.0 cv=fNy7LOme c=1 sm=0 a=ZycB6UtQUfgMyuk2+PxD7w==:17
	a=CvlS4R1r7kYA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10
	a=bNEnXefycaPkDHUF5vwA:9 a=PUjeQqilurYA:10
	a=ZycB6UtQUfgMyuk2+PxD7w==:117
X-Cloudmark-Score: 0
X-Originating-IP: 74.67.80.29
Received: from [74.67.80.29] ([74.67.80.29:46526] helo=[192.168.23.10])
	by hrndva-oedge03.mail.rr.com (envelope-from <rostedt@goodmis.org>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 2A/C4-11045-D5EB34F4; Tue, 21 Feb 2012 15:55:10 +0000
Message-ID: <1329839709.25686.63.camel@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 21 Feb 2012 10:55:09 -0500
In-Reply-To: <20120221153827.GA7529@phenom.dumpdata.com>
References: <20120214152955.GA17671@phenom.dumpdata.com>
	<1329243722.7469.7.camel@acer.local.home>
	<20120221153827.GA7529@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] ftrace_enabled set to 1 on bootup,
 slow downs with CONFIG_FUNCTION_TRACER in virt environments?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 10:38 -0500, Konrad Rzeszutek Wilk wrote:
>  
> > You mean that we get a lot more functions because the compiler made them
> > functions? Maybe we should add "notrace" to all paravirt functions? Then
> > they wont have the calls or nops.
> 
> <nods> Do you remember the rational of why some have notrace but not all?

They probably all should. Unless there's some reason people want to
trace those functions. But if they are not traced on bare-metal, then it
probably isn't worth tracing them on paravirt either.

> 
> > 
> > > - Somehow the low-level para-virt (like the assembler ones) calls don't get
> > >    patched over and still end up calling mcount? (but I really doubt that is the
> > >    case - but you never know).
> > 
> > We only live patch code in a white list of sections. But with the latest
> > scripts/recordmcount.c, as I stated above, the ones that don't get
> > patched at boot up, should be patched at compile time. But that still
> > keeps the nops there.
> 
> So the ideal_nop in the looks to be different from what the trace code
> decides to patch during execution. Is that OK? I am not that familiar with the
> variants of nops to know if some are just not ok on certain architectures?

What gets patched at compile time isn't the ideal for the arch. But it's
the "best" that can be done at that moment. But pretty much all of the
non ideal nops are patched over .init sections that are called only once
(at boot up). Even though they may not be the ideal nop for the running
box, it shouldn't be any noticeable overhead.

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzs7B-0005cH-21; Tue, 21 Feb 2012 15:58:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzs79-0005bz-QS
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 15:58:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329835203!12037349!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25127 invoked from network); 21 Feb 2012 14:40:04 -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; 21 Feb 2012 14:40:04 -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 q1LEdsqu013817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:39: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
	q1LEdo4J005951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:39:52 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
	q1LEdmHh024238; Tue, 21 Feb 2012 08:39:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:39:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A08C40469; Tue, 21 Feb 2012 09:36:34 -0500 (EST)
Date: Tue, 21 Feb 2012 09:36:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, joe.jin@oracle.com
Message-ID: <20120221143634.GD5652@phenom.dumpdata.com>
References: <4F436E75020000780007409F@nat28.tlf.novell.com>
	<0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
	<4F43743102000078000740C2@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F43743102000078000740C2@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F43ACBD.0054,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>, xen-devel <xen-devel@lists.xen.org>,
	jeremy@goop.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 09:38:41AM +0000, Jan Beulich wrote:
> >>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
> >> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
> >> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> >> There was another fix that sounds similar to this in the backend.
> >> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >> >> 
> >> > 
> >> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> >> > tree has that, but it probably would be a good idea there too.
> >> 
> >> While I had seen the change and considered pulling it in, I wasn't
> >> really convinced this is the right behavior here: After all, if the
> >> host
> >> admin requested a resource to be removed from a guest, it shouldn't
> >> depend on the guest whether and when to honor that request, yet
> >> by deferring the disconnect you basically allow the guest to continue
> >> using the disk indefinitely.
> >> 
> > 
> > I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> > something we want. At the moment, Igor and I are poking through
> > xen-blkfront.c, and currently we'd rather see the feature dropped
> > in favor of a simplified driver. One that has less release paths,
> > and/or release paths with more consistent locking behavior.
> 
> I must have missed this, or it's one more instance of delayed mail
> delivery via xen-devel.
> 
> Konrad - care to revert that original change as having barked up
> the wrong tree?

Meaning the 6f5986bce558e64fe867bff600a2127a3cb0c006?

Lets CC Joe Jin here to get his input. I recall that the --force argument
still works with that patch so the admin can still choose to terminate the
state. Which I thought was the point of the --force - as in if the
guest is still using it, we won't be yanking it out until we are
completly sure.


> 
> Jan
> 
> > [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 15:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 15:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzs7B-0005cH-21; Tue, 21 Feb 2012 15:58:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzs79-0005bz-QS
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 15:58:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1329835203!12037349!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1NTcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25127 invoked from network); 21 Feb 2012 14:40:04 -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; 21 Feb 2012 14:40:04 -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 q1LEdsqu013817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 14:39: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
	q1LEdo4J005951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 14:39:52 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
	q1LEdmHh024238; Tue, 21 Feb 2012 08:39:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 06:39:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A08C40469; Tue, 21 Feb 2012 09:36:34 -0500 (EST)
Date: Tue, 21 Feb 2012 09:36:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, joe.jin@oracle.com
Message-ID: <20120221143634.GD5652@phenom.dumpdata.com>
References: <4F436E75020000780007409F@nat28.tlf.novell.com>
	<0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
	<4F43743102000078000740C2@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F43743102000078000740C2@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F43ACBD.0054,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>, xen-devel <xen-devel@lists.xen.org>,
	jeremy@goop.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're
 busy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 09:38:41AM +0000, Jan Beulich wrote:
> >>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
> >> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
> >> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> >> There was another fix that sounds similar to this in the backend.
> >> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >> >> 
> >> > 
> >> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> >> > tree has that, but it probably would be a good idea there too.
> >> 
> >> While I had seen the change and considered pulling it in, I wasn't
> >> really convinced this is the right behavior here: After all, if the
> >> host
> >> admin requested a resource to be removed from a guest, it shouldn't
> >> depend on the guest whether and when to honor that request, yet
> >> by deferring the disconnect you basically allow the guest to continue
> >> using the disk indefinitely.
> >> 
> > 
> > I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> > something we want. At the moment, Igor and I are poking through
> > xen-blkfront.c, and currently we'd rather see the feature dropped
> > in favor of a simplified driver. One that has less release paths,
> > and/or release paths with more consistent locking behavior.
> 
> I must have missed this, or it's one more instance of delayed mail
> delivery via xen-devel.
> 
> Konrad - care to revert that original change as having barked up
> the wrong tree?

Meaning the 6f5986bce558e64fe867bff600a2127a3cb0c006?

Lets CC Joe Jin here to get his input. I recall that the --force argument
still works with that patch so the admin can still choose to terminate the
state. Which I thought was the point of the --force - as in if the
guest is still using it, we won't be yanking it out until we are
completly sure.


> 
> Jan
> 
> > [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:08:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzsGD-0006IP-30; Tue, 21 Feb 2012 16:08:13 +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 1RzsGA-0006II-OK
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:08:11 +0000
Received: from [85.158.139.83:42484] by server-9.bemta-5.messagelabs.com id
	02/A4-30171-961C34F4; Tue, 21 Feb 2012 16:08:09 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329840487!15976649!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13518 invoked from network); 21 Feb 2012 16:08:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:08:08 -0000
Received: by yenm7 with SMTP id m7so82528084yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 08:08:07 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.60.3.9 as permitted sender) client-ip=10.60.3.9; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.60.3.9 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.60.3.9])
	by 10.60.3.9 with SMTP id 9mr12279601oey.49.1329840487413 (num_hops =
	1); Tue, 21 Feb 2012 08:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=oJFDL/hgPSruLfamcdoCv69CaNuV1mDP40AfXjlUZ44=;
	b=hUbQ9isoznr1YOs01lKrKb8F5RLhBSNhhzK+KBEMHYa45E4n1b7xhrcR1+VoxfzfS3
	8io+m0hY+Y0VzGL5CBcrdmR2HdCU7rXNARS5kxtij4VsZXAxY3goushxak3dEWY4x/K8
	ESSrSW2ONhtyOqBzZ8wdLIeHyge8jVtD1BHU0=
Received: by 10.60.3.9 with SMTP id 9mr10493173oey.49.1329840487197; Tue, 21
	Feb 2012 08:08:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 21 Feb 2012 08:07:37 -0800 (PST)
In-Reply-To: <20120220203046.GD18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
	<20120220203046.GD18751@redhat.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 21 Feb 2012 16:07:37 +0000
X-Google-Sender-Auth: 2d_xt-FLlwnAU7LvtyuLcpTp8OA
Message-ID: <CAJJyHjJvW==7psyExB3aoNky_Ec=1XYUq1cRpWyLBN54wpT1Fg@mail.gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V7 03/11] pci_regs: Add
	PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBGZWIgMjAsIDIwMTIgYXQgMjA6MzAsIE1pY2hhZWwgUy4gVHNpcmtpbiA8bXN0QHJl
ZGhhdC5jb20+IHdyb3RlOgo+IE9uIEZyaSwgRmViIDE3LCAyMDEyIGF0IDA1OjA4OjM3UE0gKzAw
MDAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOgo+PiBTaWduZWQtb2ZmLWJ5OiBBbnRob255IFBFUkFS
RCA8YW50aG9ueS5wZXJhcmRAY2l0cml4LmNvbT4KPj4gLS0tCj4+IMKgaHcvcGNpX3JlZ3MuaCB8
IMKgIMKgMSArCj4+IMKgMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDAgZGVsZXRp
b25zKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS9ody9wY2lfcmVncy5oIGIvaHcvcGNpX3JlZ3MuaAo+
PiBpbmRleCA2YjQyNTE1Li41NmE0MDRiIDEwMDY0NAo+PiAtLS0gYS9ody9wY2lfcmVncy5oCj4+
ICsrKyBiL2h3L3BjaV9yZWdzLmgKPj4gQEAgLTM5Miw2ICszOTIsNyBAQAo+PiDCoCNkZWZpbmUg
wqBQQ0lfRVhQX1RZUEVfVVBTVFJFQU0gwqAgwqAgwqAgMHg1IMKgIMKgIC8qIFVwc3RyZWFtIFBv
cnQgKi8KPj4gwqAjZGVmaW5lIMKgUENJX0VYUF9UWVBFX0RPV05TVFJFQU0gMHg2IC8qIERvd25z
dHJlYW0gUG9ydCAqLwo+PiDCoCNkZWZpbmUgwqBQQ0lfRVhQX1RZUEVfUENJX0JSSURHRSAweDcg
LyogUENJL1BDSS1YIEJyaWRnZSAqLwo+PiArI2RlZmluZSDCoFBDSV9FWFBfVFlQRV9QQ0lFX0JS
SURHRSAweDggwqAgLyogUENJL1BDSS1YIHRvIFBDSUUgQnJpZGdlICovCj4KPiBJIGRvbid0IGtu
b3cgd2h5IGJ1dCBsaW51eCBzb3VyY2UgbGFja3MgdGhpcyB2YWx1ZSwgYW5kIHdlCj4gdHJ5IHRv
IHN0YXkgaW4gc3luYyB3aXRoIHRoYXQuCj4gUGxlYXNlIHB1c2ggdGhlcmUgdGhlbiB3ZSdsbCBh
ZGQgaGVyZS4KPiBNZWFud2hpbGUgwqBwdXQgYSBkZWZpbmUgaW4geW91ciBjb2RlLgoKT2ssIEkn
bGwgZG8gdGhhdC4KVGhhbmtzLAoKLS0gCkFudGhvbnkgUEVSQVJECgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:08:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzsGD-0006IP-30; Tue, 21 Feb 2012 16:08:13 +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 1RzsGA-0006II-OK
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:08:11 +0000
Received: from [85.158.139.83:42484] by server-9.bemta-5.messagelabs.com id
	02/A4-30171-961C34F4; Tue, 21 Feb 2012 16:08:09 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329840487!15976649!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13518 invoked from network); 21 Feb 2012 16:08:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:08:08 -0000
Received: by yenm7 with SMTP id m7so82528084yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 08:08:07 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.60.3.9 as permitted sender) client-ip=10.60.3.9; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.60.3.9 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.60.3.9])
	by 10.60.3.9 with SMTP id 9mr12279601oey.49.1329840487413 (num_hops =
	1); Tue, 21 Feb 2012 08:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=oJFDL/hgPSruLfamcdoCv69CaNuV1mDP40AfXjlUZ44=;
	b=hUbQ9isoznr1YOs01lKrKb8F5RLhBSNhhzK+KBEMHYa45E4n1b7xhrcR1+VoxfzfS3
	8io+m0hY+Y0VzGL5CBcrdmR2HdCU7rXNARS5kxtij4VsZXAxY3goushxak3dEWY4x/K8
	ESSrSW2ONhtyOqBzZ8wdLIeHyge8jVtD1BHU0=
Received: by 10.60.3.9 with SMTP id 9mr10493173oey.49.1329840487197; Tue, 21
	Feb 2012 08:08:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 21 Feb 2012 08:07:37 -0800 (PST)
In-Reply-To: <20120220203046.GD18751@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
	<20120220203046.GD18751@redhat.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 21 Feb 2012 16:07:37 +0000
X-Google-Sender-Auth: 2d_xt-FLlwnAU7LvtyuLcpTp8OA
Message-ID: <CAJJyHjJvW==7psyExB3aoNky_Ec=1XYUq1cRpWyLBN54wpT1Fg@mail.gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V7 03/11] pci_regs: Add
	PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBGZWIgMjAsIDIwMTIgYXQgMjA6MzAsIE1pY2hhZWwgUy4gVHNpcmtpbiA8bXN0QHJl
ZGhhdC5jb20+IHdyb3RlOgo+IE9uIEZyaSwgRmViIDE3LCAyMDEyIGF0IDA1OjA4OjM3UE0gKzAw
MDAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOgo+PiBTaWduZWQtb2ZmLWJ5OiBBbnRob255IFBFUkFS
RCA8YW50aG9ueS5wZXJhcmRAY2l0cml4LmNvbT4KPj4gLS0tCj4+IMKgaHcvcGNpX3JlZ3MuaCB8
IMKgIMKgMSArCj4+IMKgMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDAgZGVsZXRp
b25zKC0pCj4+Cj4+IGRpZmYgLS1naXQgYS9ody9wY2lfcmVncy5oIGIvaHcvcGNpX3JlZ3MuaAo+
PiBpbmRleCA2YjQyNTE1Li41NmE0MDRiIDEwMDY0NAo+PiAtLS0gYS9ody9wY2lfcmVncy5oCj4+
ICsrKyBiL2h3L3BjaV9yZWdzLmgKPj4gQEAgLTM5Miw2ICszOTIsNyBAQAo+PiDCoCNkZWZpbmUg
wqBQQ0lfRVhQX1RZUEVfVVBTVFJFQU0gwqAgwqAgwqAgMHg1IMKgIMKgIC8qIFVwc3RyZWFtIFBv
cnQgKi8KPj4gwqAjZGVmaW5lIMKgUENJX0VYUF9UWVBFX0RPV05TVFJFQU0gMHg2IC8qIERvd25z
dHJlYW0gUG9ydCAqLwo+PiDCoCNkZWZpbmUgwqBQQ0lfRVhQX1RZUEVfUENJX0JSSURHRSAweDcg
LyogUENJL1BDSS1YIEJyaWRnZSAqLwo+PiArI2RlZmluZSDCoFBDSV9FWFBfVFlQRV9QQ0lFX0JS
SURHRSAweDggwqAgLyogUENJL1BDSS1YIHRvIFBDSUUgQnJpZGdlICovCj4KPiBJIGRvbid0IGtu
b3cgd2h5IGJ1dCBsaW51eCBzb3VyY2UgbGFja3MgdGhpcyB2YWx1ZSwgYW5kIHdlCj4gdHJ5IHRv
IHN0YXkgaW4gc3luYyB3aXRoIHRoYXQuCj4gUGxlYXNlIHB1c2ggdGhlcmUgdGhlbiB3ZSdsbCBh
ZGQgaGVyZS4KPiBNZWFud2hpbGUgwqBwdXQgYSBkZWZpbmUgaW4geW91ciBjb2RlLgoKT2ssIEkn
bGwgZG8gdGhhdC4KVGhhbmtzLAoKLS0gCkFudGhvbnkgUEVSQVJECgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:16:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzsO6-0006Yc-6y; Tue, 21 Feb 2012 16:16:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzsO5-0006YP-Ge
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:16:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329840973!6112239!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5451 invoked from network); 21 Feb 2012 16:16:15 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:16:15 -0000
Received: by obcuy19 with SMTP id uy19so20360883obc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 08:16:13 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.182.160.33 as permitted sender) client-ip=10.182.160.33; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.182.160.33 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.182.160.33])
	by 10.182.160.33 with SMTP id xh1mr859746obb.59.1329840973504 (num_hops
	= 1); Tue, 21 Feb 2012 08:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=YAsKGBx2Ms5XkTlWyU07ZwJI3Pk4juOvr2HhCgxAszc=;
	b=F7JKvbxahrX24BERh9smJiav6bUPD2edNm0oFYCxYri6pzr9LXcXuIl0niMLpGSMCb
	BxIYB7cr3nucYwLJQgys0UmJRxr7Fek+zQuyNB7NFUcvbHpP8Vxi5RRCwGOKnUetwY34
	RbCtMePHyipIJMZOoud+wtMQEeB535c3eNeWo=
Received: by 10.182.160.33 with SMTP id xh1mr732082obb.59.1329840973464; Tue,
	21 Feb 2012 08:16:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 21 Feb 2012 08:15:43 -0800 (PST)
In-Reply-To: <4F43731A02000078000740BA@nat28.tlf.novell.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
	<4F43731A02000078000740BA@nat28.tlf.novell.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 21 Feb 2012 16:15:43 +0000
X-Google-Sender-Auth: 7dLfW-GbHnoYE9gZEyAMifeG_KU
Message-ID: <CAJJyHjJEGLU+CUZ+hxOk3VNsSovOaPhu33psnxUgWAFzAj-usg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Shan Haitao <maillists.shan@gmail.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V7 11/11] xen passthrough:
 clean up MSI-X table handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 09:34, Jan Beulich <JBeulich@suse.com> wrote:
> Wouldn't thus much better be merged into the prior patch(es)? After
> all you're not trying to reconstruct the Xen-side history of this code
> anyway.

Yes, that probably better than having an extra patch. There is a
"link" to the history, anyway. I'll merge the patch.

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 Feb 21 16:16:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzsO6-0006Yc-6y; Tue, 21 Feb 2012 16:16:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RzsO5-0006YP-Ge
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:16:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329840973!6112239!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5451 invoked from network); 21 Feb 2012 16:16:15 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:16:15 -0000
Received: by obcuy19 with SMTP id uy19so20360883obc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 08:16:13 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.182.160.33 as permitted sender) client-ip=10.182.160.33; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.182.160.33 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.182.160.33])
	by 10.182.160.33 with SMTP id xh1mr859746obb.59.1329840973504 (num_hops
	= 1); Tue, 21 Feb 2012 08:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=YAsKGBx2Ms5XkTlWyU07ZwJI3Pk4juOvr2HhCgxAszc=;
	b=F7JKvbxahrX24BERh9smJiav6bUPD2edNm0oFYCxYri6pzr9LXcXuIl0niMLpGSMCb
	BxIYB7cr3nucYwLJQgys0UmJRxr7Fek+zQuyNB7NFUcvbHpP8Vxi5RRCwGOKnUetwY34
	RbCtMePHyipIJMZOoud+wtMQEeB535c3eNeWo=
Received: by 10.182.160.33 with SMTP id xh1mr732082obb.59.1329840973464; Tue,
	21 Feb 2012 08:16:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 21 Feb 2012 08:15:43 -0800 (PST)
In-Reply-To: <4F43731A02000078000740BA@nat28.tlf.novell.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-12-git-send-email-anthony.perard@citrix.com>
	<4F43731A02000078000740BA@nat28.tlf.novell.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 21 Feb 2012 16:15:43 +0000
X-Google-Sender-Auth: 7dLfW-GbHnoYE9gZEyAMifeG_KU
Message-ID: <CAJJyHjJEGLU+CUZ+hxOk3VNsSovOaPhu33psnxUgWAFzAj-usg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Shan Haitao <maillists.shan@gmail.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V7 11/11] xen passthrough:
 clean up MSI-X table handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 09:34, Jan Beulich <JBeulich@suse.com> wrote:
> Wouldn't thus much better be merged into the prior patch(es)? After
> all you're not trying to reconstruct the Xen-side history of this code
> anyway.

Yes, that probably better than having an extra patch. There is a
"link" to the history, anyway. I'll merge the patch.

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 Feb 21 16:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzsPk-0006gB-Ma; Tue, 21 Feb 2012 16:18:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzsPj-0006fg-Ns
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:18:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329841077!17616186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17961 invoked from network); 21 Feb 2012 16:17:57 -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;
	21 Feb 2012 16:17:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10849183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 16:17:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 16:17:56 +0000
Message-ID: <1329841075.3990.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 16:17:55 +0000
In-Reply-To: <20291.47326.624920.309995@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 15:31 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > On Tue, 2012-02-21 at 15:14 +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > > > On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > > > > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > > > > xen-unstable's Config.mk ?  That's what I do with
> > > > > qemu-xen-unstable.git.
> > > > 
> > > > That would make master rebasing. I'm happy to do that if there is
> > > > consensus that it is ok.
> > > 
> > > Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.
> > 
> > SEABIOS_UPSTREAM_TAG is tracking an upstream stable branch. When they
> > release a new stable release we will want to switch to that, but that
> > will not be a fast-forward.
> 
> Hmm.  Well as to the question of what "master" should be:
> 
> If it's anything useful at all,

(which I'm not personally convinced of, but I seem to be in the minority
so I shall try and make it mean something)

> it needs to be what you would need to
> edit to change the result of the Xen build.  So either it must be
> .._TAG

I'll choose this option. I'll also edit the repo description to make it
clear that all branches are rebasing.

>  or it must be some fast-forwarding branch constructed from the
> series of _TAG values.  (Ie, a branch whose commits correspond 1:1
> with _TAG values, each commit on the master branch having the previous
> master commit as its left parent and the _TAG, which determines the
> contents, as the right parent.)

I think I'd inevitably end up cocking this scheme up, especially given
the expected frequency of seabios updates (e.g. v. low).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:18:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzsPk-0006gB-Ma; Tue, 21 Feb 2012 16:18:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzsPj-0006fg-Ns
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:18:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329841077!17616186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17961 invoked from network); 21 Feb 2012 16:17:57 -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;
	21 Feb 2012 16:17:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10849183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 16:17:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 16:17:56 +0000
Message-ID: <1329841075.3990.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 16:17:55 +0000
In-Reply-To: <20291.47326.624920.309995@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 15:31 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > On Tue, 2012-02-21 at 15:14 +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > > > On Tue, 2012-02-21 at 12:34 +0000, Ian Jackson wrote:
> > > > > Why not make "master" be equal to the SEABIOS_UPSTREAM_TAG in
> > > > > xen-unstable's Config.mk ?  That's what I do with
> > > > > qemu-xen-unstable.git.
> > > > 
> > > > That would make master rebasing. I'm happy to do that if there is
> > > > consensus that it is ok.
> > > 
> > > Wait, you're rewinding SEABIOS_UPSTREAM_TAG ?  That's quite exciting.
> > 
> > SEABIOS_UPSTREAM_TAG is tracking an upstream stable branch. When they
> > release a new stable release we will want to switch to that, but that
> > will not be a fast-forward.
> 
> Hmm.  Well as to the question of what "master" should be:
> 
> If it's anything useful at all,

(which I'm not personally convinced of, but I seem to be in the minority
so I shall try and make it mean something)

> it needs to be what you would need to
> edit to change the result of the Xen build.  So either it must be
> .._TAG

I'll choose this option. I'll also edit the repo description to make it
clear that all branches are rebasing.

>  or it must be some fast-forwarding branch constructed from the
> series of _TAG values.  (Ie, a branch whose commits correspond 1:1
> with _TAG values, each commit on the master branch having the previous
> master commit as its left parent and the _TAG, which determines the
> contents, as the right parent.)

I think I'd inevitably end up cocking this scheme up, especially given
the expected frequency of seabios updates (e.g. v. low).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16: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 1Rzsnq-0007QQ-PE; Tue, 21 Feb 2012 16:42:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzsnp-0007QL-9U
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:42:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329842570!9331883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7055 invoked from network); 21 Feb 2012 16:42:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:42:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10849871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 16:42:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 16:42:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzsni-0002W7-DG; Tue, 21 Feb 2012 16:42:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzsni-0001ke-5u;
	Tue, 21 Feb 2012 16:42:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.51594.58651.507278@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 16:42:50 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> On Tue, 14 Feb 2012, Ian Campbell wrote:
> > I was wondering if perhaps xl/libxl should handle these events by
> > default (using the same APIs as xldeviced uses) such that in the simple
> > case users can continue to just use xl without worrying about
> > configuring or enabling additional daemons. There would then be an
> > option to disable this if you were running xldeviced (either in dom0 or
> > in a driver dom). Perhaps a more DWIM extension would be to default to
> > running things within xl/libxl only if the backend is in dom0 and assu,e
> > xldeviced is running in backend doms != 0.
> 
> While I understand that technically is not difficult to achieve and
> doesn't add much complexity in terms of lines of code; starting daemons
> is cheap and is taken care by xencommons. I am not sure if it is worth
> introducing yet another way of doing the same thing.

This is a good point.  Also, if anyone does object to this daemon, and
we take the event-driven approach already suggested, it probably won't
be too hard to add later the short-cut to run it in-process.

So I think for now we should just have the daemonic version.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16: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 1Rzsnq-0007QQ-PE; Tue, 21 Feb 2012 16:42:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzsnp-0007QL-9U
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:42:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329842570!9331883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7055 invoked from network); 21 Feb 2012 16:42:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:42:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10849871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 16:42:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 16:42:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzsni-0002W7-DG; Tue, 21 Feb 2012 16:42:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzsni-0001ke-5u;
	Tue, 21 Feb 2012 16:42:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.51594.58651.507278@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 16:42:50 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> On Tue, 14 Feb 2012, Ian Campbell wrote:
> > I was wondering if perhaps xl/libxl should handle these events by
> > default (using the same APIs as xldeviced uses) such that in the simple
> > case users can continue to just use xl without worrying about
> > configuring or enabling additional daemons. There would then be an
> > option to disable this if you were running xldeviced (either in dom0 or
> > in a driver dom). Perhaps a more DWIM extension would be to default to
> > running things within xl/libxl only if the backend is in dom0 and assu,e
> > xldeviced is running in backend doms != 0.
> 
> While I understand that technically is not difficult to achieve and
> doesn't add much complexity in terms of lines of code; starting daemons
> is cheap and is taken care by xencommons. I am not sure if it is worth
> introducing yet another way of doing the same thing.

This is a good point.  Also, if anyone does object to this daemon, and
we take the event-driven approach already suggested, it probably won't
be too hard to add later the short-cut to run it in-process.

So I think for now we should just have the daemonic version.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:45:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16: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 1RzspS-0007Up-98; Tue, 21 Feb 2012 16:44:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzspR-0007Ub-6X
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:44:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329842669!14143335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12954 invoked from network); 21 Feb 2012 16:44:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:44:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10849921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 16:44:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 16:44:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzspI-0002Yd-QK; Tue, 21 Feb 2012 16:44:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzspI-0001l3-PX;
	Tue, 21 Feb 2012 16:44:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.51692.624858.980372@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 16:44:28 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F43616F.9060902@amd.com>
References: <4F33C6C6.30005@amd.com>
	<20290.38015.460233.816604@mariner.uk.xensource.com>
	<4F43616F.9060902@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add 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

Christoph Egger writes ("Re: [Xen-devel] [PATCH] libxl: add missing includes"):
> On 02/20/12 19:44, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] libxl: add missing includes"):
> >>
> >> include<poll.h>  for struct pollfd
> >> include<time.h>  for struct timeval
> >> Fixes gcc complaints about implicit declaration.
> >
> > According to SuS, it should be<sys/time.h>.
> 
> Yes, sorry. Should I resend?

I have fixed it up and committed it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 16:45:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 16: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 1RzspS-0007Up-98; Tue, 21 Feb 2012 16:44:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzspR-0007Ub-6X
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 16:44:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329842669!14143335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12954 invoked from network); 21 Feb 2012 16:44:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 16:44:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10849921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 16:44:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 16:44:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzspI-0002Yd-QK; Tue, 21 Feb 2012 16:44:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzspI-0001l3-PX;
	Tue, 21 Feb 2012 16:44:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.51692.624858.980372@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 16:44:28 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F43616F.9060902@amd.com>
References: <4F33C6C6.30005@amd.com>
	<20290.38015.460233.816604@mariner.uk.xensource.com>
	<4F43616F.9060902@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: add 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

Christoph Egger writes ("Re: [Xen-devel] [PATCH] libxl: add missing includes"):
> On 02/20/12 19:44, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] libxl: add missing includes"):
> >>
> >> include<poll.h>  for struct pollfd
> >> include<time.h>  for struct timeval
> >> Fixes gcc complaints about implicit declaration.
> >
> > According to SuS, it should be<sys/time.h>.
> 
> Yes, sorry. Should I resend?

I have fixed it up and committed it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17: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 1Rzt6N-000830-6T; Tue, 21 Feb 2012 17:02:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzt6L-00082r-E6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:02:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329843717!5112078!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5728 invoked from network); 21 Feb 2012 17:01:58 -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; 21 Feb 2012 17: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 q1LH1kZQ018767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 17:01:47 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
	q1LH1jMn015686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 17:01: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
	q1LH1jNR005568; Tue, 21 Feb 2012 11:01:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 09:01:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 172624047A; Tue, 21 Feb 2012 11:58:31 -0500 (EST)
Date: Tue, 21 Feb 2012 11:58:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120221165830.GA32413@phenom.dumpdata.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090204.4F43CDFB.003E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 06:06:14PM +0300, Anton Samsonov wrote:
> 2012/2/15 Pasi K=E4rkk=E4inen <pasik@iki.fi>:
> =

> AS>> Unfortunately, I'm not skilled at compiling the kernel myself.
> AS>> I tried building the newest 3.2.6 with all Xen options enabled,
> AS>> but the resulting system didn't have netback.ko module at all,
> AS>> barely booted, and xm was not able to communicate with VMM.
> =

> PK> About compiling the dom0 kernel, see this wiki page:
> PK> http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_sup=
port
> =

> Thanks, it looks like I just messed some "y" with "m" and vice versa
> ("m" is presented as a meaningless bullet in GUI). By the way, that how-to
> contains dubious lines for CONFIG_XEN_DEV_EVTCHN and CONFIG_XEN_GNTDEV.
> =

> Well, now the system boots more eagerly, although the kernel still
> seems to be slightly incompatible with distro's environment and my hardwa=
re.
> But at least xend is now responding and is able to run DomUs as usual.
> =

> =

> I started and stopped all the swarm of VMs several times (without letting=
 them
> to run for some time), and observed no GPF. But instead of this I get
> screen garbling: while a DomU is starting or stopping, the whole graphical
> desktop is sometimes painted with either black or not-so-random garbage,
> and even mouse pointer can become garbled; I have to move / resize windows
> to get them repainted. Network connectivity between Dom0 and [subsequently
> started] DomUs does not break though.
> =

> On one hand, I am not sure whether the video driver is not to be
> blamed for glitches,
> because graphics already does not work as usual: it is not hardware-accel=
erated
> with my custom kernel (while it is with stock kernel), and the screen is =
garbled
> on Xorg startup, before login promt is displayed. On the other hand, this=
 is not

So... I am curious, what graphic card do you have and do you get any of
these Red Hat BZs?  RH BZ# 742032, 787403, and 745574?

> in any way normal, as Xen operations must not interfere with Dom0's deskt=
op
> (or was it direct VRAM corruption?).

It is complicated. There is a bug in 3.2 when using radeon or nouveau for a=
 lengthy
time of period that ends up "corrupting" memory. The workaround is to provi=
de 'nopat'
on the argument line.

> =

> This happens even when "suspicious" domains (NetBSD with CARP) are not
> started: on a freshly booted Dom0, just having 4 essential DomUs is enough
> to get that screen garbling when shutting down 1 or 2 of them for the
> first time.

Hmm, that is weird. Never seen that before. Can you include more details on=
 your
machine?

> =

> =

> But when I return to stock kernel, I can run a dozen of such DomUs (inclu=
ding
> those NetBSD load-balancers), starting and stopping them many times
> without a problem. Recently, no GPF occurred when only 1 out of 2 balance=
rs
> is started, or none of them started at all; or it just needs much more up=
time
> to accumulate memory corruption for a GPF.
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17: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 1Rzt6N-000830-6T; Tue, 21 Feb 2012 17:02:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rzt6L-00082r-E6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:02:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1329843717!5112078!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5728 invoked from network); 21 Feb 2012 17:01:58 -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; 21 Feb 2012 17: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 q1LH1kZQ018767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 17:01:47 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
	q1LH1jMn015686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 17:01: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
	q1LH1jNR005568; Tue, 21 Feb 2012 11:01:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 09:01:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 172624047A; Tue, 21 Feb 2012 11:58:31 -0500 (EST)
Date: Tue, 21 Feb 2012 11:58:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120221165830.GA32413@phenom.dumpdata.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090204.4F43CDFB.003E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 21, 2012 at 06:06:14PM +0300, Anton Samsonov wrote:
> 2012/2/15 Pasi K=E4rkk=E4inen <pasik@iki.fi>:
> =

> AS>> Unfortunately, I'm not skilled at compiling the kernel myself.
> AS>> I tried building the newest 3.2.6 with all Xen options enabled,
> AS>> but the resulting system didn't have netback.ko module at all,
> AS>> barely booted, and xm was not able to communicate with VMM.
> =

> PK> About compiling the dom0 kernel, see this wiki page:
> PK> http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_sup=
port
> =

> Thanks, it looks like I just messed some "y" with "m" and vice versa
> ("m" is presented as a meaningless bullet in GUI). By the way, that how-to
> contains dubious lines for CONFIG_XEN_DEV_EVTCHN and CONFIG_XEN_GNTDEV.
> =

> Well, now the system boots more eagerly, although the kernel still
> seems to be slightly incompatible with distro's environment and my hardwa=
re.
> But at least xend is now responding and is able to run DomUs as usual.
> =

> =

> I started and stopped all the swarm of VMs several times (without letting=
 them
> to run for some time), and observed no GPF. But instead of this I get
> screen garbling: while a DomU is starting or stopping, the whole graphical
> desktop is sometimes painted with either black or not-so-random garbage,
> and even mouse pointer can become garbled; I have to move / resize windows
> to get them repainted. Network connectivity between Dom0 and [subsequently
> started] DomUs does not break though.
> =

> On one hand, I am not sure whether the video driver is not to be
> blamed for glitches,
> because graphics already does not work as usual: it is not hardware-accel=
erated
> with my custom kernel (while it is with stock kernel), and the screen is =
garbled
> on Xorg startup, before login promt is displayed. On the other hand, this=
 is not

So... I am curious, what graphic card do you have and do you get any of
these Red Hat BZs?  RH BZ# 742032, 787403, and 745574?

> in any way normal, as Xen operations must not interfere with Dom0's deskt=
op
> (or was it direct VRAM corruption?).

It is complicated. There is a bug in 3.2 when using radeon or nouveau for a=
 lengthy
time of period that ends up "corrupting" memory. The workaround is to provi=
de 'nopat'
on the argument line.

> =

> This happens even when "suspicious" domains (NetBSD with CARP) are not
> started: on a freshly booted Dom0, just having 4 essential DomUs is enough
> to get that screen garbling when shutting down 1 or 2 of them for the
> first time.

Hmm, that is weird. Never seen that before. Can you include more details on=
 your
machine?

> =

> =

> But when I return to stock kernel, I can run a dozen of such DomUs (inclu=
ding
> those NetBSD load-balancers), starting and stopping them many times
> without a problem. Recently, no GPF occurred when only 1 out of 2 balance=
rs
> is started, or none of them started at all; or it just needs much more up=
time
> to accumulate memory corruption for a GPF.
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:02:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzt6W-00083S-J5; Tue, 21 Feb 2012 17:02: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 1Rzt6V-00083H-7W
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:02:15 +0000
Received: from [85.158.139.83:7867] by server-12.bemta-5.messagelabs.com id
	89/66-24595-61EC34F4; Tue, 21 Feb 2012 17:02:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329843733!13310458!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15265 invoked from network); 21 Feb 2012 17:02:13 -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 Feb 2012 17:02:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10850288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:02:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 17:02:13 +0000
Message-ID: <1329843731.17823.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 17:02:11 +0000
In-Reply-To: <20291.51594.58651.507278@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
	<20291.51594.58651.507278@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monn? <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 16:42 +0000, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > On Tue, 14 Feb 2012, Ian Campbell wrote:
> > > I was wondering if perhaps xl/libxl should handle these events by
> > > default (using the same APIs as xldeviced uses) such that in the simple
> > > case users can continue to just use xl without worrying about
> > > configuring or enabling additional daemons. There would then be an
> > > option to disable this if you were running xldeviced (either in dom0 or
> > > in a driver dom). Perhaps a more DWIM extension would be to default to
> > > running things within xl/libxl only if the backend is in dom0 and assu,e
> > > xldeviced is running in backend doms != 0.
> > 
> > While I understand that technically is not difficult to achieve and
> > doesn't add much complexity in terms of lines of code; starting daemons
> > is cheap and is taken care by xencommons. I am not sure if it is worth
> > introducing yet another way of doing the same thing.
> 
> This is a good point.  Also, if anyone does object to this daemon, and
> we take the event-driven approach already suggested, it probably won't
> be too hard to add later the short-cut to run it in-process.
> 
> So I think for now we should just have the daemonic version.

If the smarts are all in libxl and the daemon is the noddy event loop
then that's ok with me too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:02:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzt6W-00083S-J5; Tue, 21 Feb 2012 17:02: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 1Rzt6V-00083H-7W
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:02:15 +0000
Received: from [85.158.139.83:7867] by server-12.bemta-5.messagelabs.com id
	89/66-24595-61EC34F4; Tue, 21 Feb 2012 17:02:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329843733!13310458!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15265 invoked from network); 21 Feb 2012 17:02:13 -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 Feb 2012 17:02:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10850288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:02:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 17:02:13 +0000
Message-ID: <1329843731.17823.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 17:02:11 +0000
In-Reply-To: <20291.51594.58651.507278@mariner.uk.xensource.com>
References: <patchbomb.1328189195@debian.localdomain>
	<bc38aa2e11e21b34dbc2.1328189215@debian.localdomain>
	<20274.42482.96188.319229@mariner.uk.xensource.com>
	<CAPLaKK6+g=kWOv5KAcd7dNHguOYJQ1ByZdpVLtUVXS+5RnrxWw@mail.gmail.com>
	<1329234536.31256.259.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202211035100.23091@kaball-desktop>
	<20291.51594.58651.507278@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monn? <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug
 public API functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 16:42 +0000, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions"):
> > On Tue, 14 Feb 2012, Ian Campbell wrote:
> > > I was wondering if perhaps xl/libxl should handle these events by
> > > default (using the same APIs as xldeviced uses) such that in the simple
> > > case users can continue to just use xl without worrying about
> > > configuring or enabling additional daemons. There would then be an
> > > option to disable this if you were running xldeviced (either in dom0 or
> > > in a driver dom). Perhaps a more DWIM extension would be to default to
> > > running things within xl/libxl only if the backend is in dom0 and assu,e
> > > xldeviced is running in backend doms != 0.
> > 
> > While I understand that technically is not difficult to achieve and
> > doesn't add much complexity in terms of lines of code; starting daemons
> > is cheap and is taken care by xencommons. I am not sure if it is worth
> > introducing yet another way of doing the same thing.
> 
> This is a good point.  Also, if anyone does object to this daemon, and
> we take the event-driven approach already suggested, it probably won't
> be too hard to add later the short-cut to run it in-process.
> 
> So I think for now we should just have the daemonic version.

If the smarts are all in libxl and the daemon is the noddy event loop
then that's ok with me too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:12:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:12:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztFt-0008LX-LQ; Tue, 21 Feb 2012 17:11:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RztFs-0008LS-0i
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 17:11:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329844309!9336814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1947 invoked from network); 21 Feb 2012 17:11:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:11:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10850520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:11:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:11:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztFk-0002x9-QI; Tue, 21 Feb 2012 17:11:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztFk-0001pW-Og;
	Tue, 21 Feb 2012 17:11:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.53332.751695.368872@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:11:48 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
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 v8] build: add autoconf to replace custom
 checks in tools/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

Roger Pau Monne writes ("[PATCH v8] build: add autoconf to replace custom checks in tools/check"):
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script, config/Tools.mk
> and config.h.

Thanks, I have now managed to successfuly test this.  It's looking
good.

I have made a change to the test system to deal with it (as otherwise
of course all the builds will fail), and I will apply your autoconf
patch when I get a push on the test system.

I'll also apply the .gitignore patch below.

Ian.

commit 6e9893f665a3f6fc6eef45fc53cf446f8c0856c4
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Tue Feb 21 16:12:46 2012 +0000

    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/.gitignore b/.gitignore
index d1a503b..8810b35 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,12 @@ stubdom/lwip/
 stubdom/ioemu/
 stubdom/stubdompath.sh
 tools/*/build/lib*/*.py
+tools/autom4te.cache
+tools/config.h
+tools/config.log
+tools/config.status
+tools/config.cache
+config/Tools.mk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:12:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:12:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztFt-0008LX-LQ; Tue, 21 Feb 2012 17:11:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RztFs-0008LS-0i
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 17:11:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329844309!9336814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1947 invoked from network); 21 Feb 2012 17:11:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:11:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10850520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:11:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:11:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztFk-0002x9-QI; Tue, 21 Feb 2012 17:11:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztFk-0001pW-Og;
	Tue, 21 Feb 2012 17:11:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.53332.751695.368872@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:11:48 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
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 v8] build: add autoconf to replace custom
 checks in tools/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

Roger Pau Monne writes ("[PATCH v8] build: add autoconf to replace custom checks in tools/check"):
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script, config/Tools.mk
> and config.h.

Thanks, I have now managed to successfuly test this.  It's looking
good.

I have made a change to the test system to deal with it (as otherwise
of course all the builds will fail), and I will apply your autoconf
patch when I get a push on the test system.

I'll also apply the .gitignore patch below.

Ian.

commit 6e9893f665a3f6fc6eef45fc53cf446f8c0856c4
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Tue Feb 21 16:12:46 2012 +0000

    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/.gitignore b/.gitignore
index d1a503b..8810b35 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,12 @@ stubdom/lwip/
 stubdom/ioemu/
 stubdom/stubdompath.sh
 tools/*/build/lib*/*.py
+tools/autom4te.cache
+tools/config.h
+tools/config.log
+tools/config.status
+tools/config.cache
+config/Tools.mk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:39:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztfp-0000Pt-9K; Tue, 21 Feb 2012 17:38: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 1Rztfn-0000Po-Ua
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:38:44 +0000
Received: from [85.158.139.83:9979] by server-1.bemta-5.messagelabs.com id
	CF/3D-28458-3A6D34F4; Tue, 21 Feb 2012 17:38:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329845922!16024712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23987 invoked from network); 21 Feb 2012 17:38: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;
	21 Feb 2012 17:38:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10850988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:38:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:38:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztfm-0003Dh-9K; Tue, 21 Feb 2012 17:38:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztfm-0001vI-7b;
	Tue, 21 Feb 2012 17:38:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.54946.71627.564190@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:38:42 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 9] tools/xenpaging: cleanups
	and	performance improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 0 of 9] tools/xenpaging: cleanups and performance improvements"):
> Series sent on 2012-01-31, now rebased to 24847:0900b1c905f1
> 
> This series adjusts the error reporting in the various code paths, with
> the intention that fatal errors can be detected by callers and handled
> properly. During my performance analysis with callgrind I found and
> fixed a few bottlenecks in the page-in code paths.

Thanks, applied all nine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:39:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztfp-0000Pt-9K; Tue, 21 Feb 2012 17:38: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 1Rztfn-0000Po-Ua
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:38:44 +0000
Received: from [85.158.139.83:9979] by server-1.bemta-5.messagelabs.com id
	CF/3D-28458-3A6D34F4; Tue, 21 Feb 2012 17:38:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329845922!16024712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23987 invoked from network); 21 Feb 2012 17:38: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;
	21 Feb 2012 17:38:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10850988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:38:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:38:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztfm-0003Dh-9K; Tue, 21 Feb 2012 17:38:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztfm-0001vI-7b;
	Tue, 21 Feb 2012 17:38:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.54946.71627.564190@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:38:42 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1329770882@probook.site>
References: <patchbomb.1329770882@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 9] tools/xenpaging: cleanups
	and	performance improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("[Xen-devel] [PATCH 0 of 9] tools/xenpaging: cleanups and performance improvements"):
> Series sent on 2012-01-31, now rebased to 24847:0900b1c905f1
> 
> This series adjusts the error reporting in the various code paths, with
> the intention that fatal errors can be detected by callers and handled
> properly. During my performance analysis with callgrind I found and
> fixed a few bottlenecks in the page-in code paths.

Thanks, applied all nine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17: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 1Rztn0-0000ci-Fu; Tue, 21 Feb 2012 17:46:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rztmz-0000cd-6a
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:46:09 +0000
Received: from [85.158.139.83:32779] by server-7.bemta-5.messagelabs.com id
	3E/F9-16195-068D34F4; Tue, 21 Feb 2012 17:46:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329846367!12160639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23702 invoked from network); 21 Feb 2012 17:46:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:46:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:46:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztmw-0003IK-PO; Tue, 21 Feb 2012 17:46:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztmw-0001w8-OA;
	Tue, 21 Feb 2012 17:46:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55390.734920.978564@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:46:06 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0f97e5c69eeb0c00d1f7.1329831252@kodo2>
References: <patchbomb.1329831246@kodo2>
	<0f97e5c69eeb0c00d1f7.1329831252@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 10] libxl: cleanup: Remove
	pointless	ERRNOVAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 06 of 10] libxl: cleanup: Remove pointless ERRNOVAL"):
> Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17: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 1Rztn0-0000ci-Fu; Tue, 21 Feb 2012 17:46:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rztmz-0000cd-6a
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:46:09 +0000
Received: from [85.158.139.83:32779] by server-7.bemta-5.messagelabs.com id
	3E/F9-16195-068D34F4; Tue, 21 Feb 2012 17:46:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329846367!12160639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23702 invoked from network); 21 Feb 2012 17:46:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:46:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:46:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztmw-0003IK-PO; Tue, 21 Feb 2012 17:46:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztmw-0001w8-OA;
	Tue, 21 Feb 2012 17:46:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55390.734920.978564@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:46:06 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0f97e5c69eeb0c00d1f7.1329831252@kodo2>
References: <patchbomb.1329831246@kodo2>
	<0f97e5c69eeb0c00d1f7.1329831252@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 06 of 10] libxl: cleanup: Remove
	pointless	ERRNOVAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 06 of 10] libxl: cleanup: Remove pointless ERRNOVAL"):
> Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:49:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztq8-0000md-32; Tue, 21 Feb 2012 17:49:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rztq6-0000mQ-82
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:49:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329846556!15812942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10533 invoked from network); 21 Feb 2012 17:49:16 -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;
	21 Feb 2012 17:49:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:49:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:49:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztpz-0003JU-IL; Tue, 21 Feb 2012 17:49:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztpz-0001wO-HS;
	Tue, 21 Feb 2012 17:49:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55577.387401.827359@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:49:13 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6dc39f1a7167b3a98178.1329831255@kodo2>
References: <patchbomb.1329831246@kodo2>
	<6dc39f1a7167b3a98178.1329831255@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 09 of 10] xl: Refactor sched_domain_output
 to have a callback for pool information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 09 of 10] xl: Refactor sched_domain_output to have a callback for pool information"):
> Allow a scheduler to provide a callback to display pool-wide information,
> providing a default.  This is in preparation for displaying pool-wide
> scheduler parameters on this line.

> +static int sched_default_pool_output(
> +    uint32_t poolid)
> +{

Formatting glitch.  I know sched_domain_output looks like that but
that's because it needs it to avoid wrapping.

>  static int sched_domain_output(
> -    uint32_t sched, int (*output)(int), const char *cpupool)
> +    uint32_t sched, int (*output)(int), int (*pooloutput)(uint32_t), const char *cpupool)

And here you've failed to wrap it :-).  I suggest

  static int sched_domain_output(uint32_t sched, const char *cpupool,
                int (*output)(int), int (*pooloutput)(uint32_t))
  {

but anything plausible is fine by me.

Aside from those niggles,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:49:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztq8-0000md-32; Tue, 21 Feb 2012 17:49:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rztq6-0000mQ-82
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:49:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329846556!15812942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10533 invoked from network); 21 Feb 2012 17:49:16 -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;
	21 Feb 2012 17:49:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:49:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:49:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztpz-0003JU-IL; Tue, 21 Feb 2012 17:49:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztpz-0001wO-HS;
	Tue, 21 Feb 2012 17:49:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55577.387401.827359@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:49:13 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6dc39f1a7167b3a98178.1329831255@kodo2>
References: <patchbomb.1329831246@kodo2>
	<6dc39f1a7167b3a98178.1329831255@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 09 of 10] xl: Refactor sched_domain_output
 to have a callback for pool information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 09 of 10] xl: Refactor sched_domain_output to have a callback for pool information"):
> Allow a scheduler to provide a callback to display pool-wide information,
> providing a default.  This is in preparation for displaying pool-wide
> scheduler parameters on this line.

> +static int sched_default_pool_output(
> +    uint32_t poolid)
> +{

Formatting glitch.  I know sched_domain_output looks like that but
that's because it needs it to avoid wrapping.

>  static int sched_domain_output(
> -    uint32_t sched, int (*output)(int), const char *cpupool)
> +    uint32_t sched, int (*output)(int), int (*pooloutput)(uint32_t), const char *cpupool)

And here you've failed to wrap it :-).  I suggest

  static int sched_domain_output(uint32_t sched, const char *cpupool,
                int (*output)(int), int (*pooloutput)(uint32_t))
  {

but anything plausible is fine by me.

Aside from those niggles,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:50:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztqe-0000p9-H9; Tue, 21 Feb 2012 17:49:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rztqd-0000oy-Cu
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:49:55 +0000
Received: from [85.158.139.83:52333] by server-12.bemta-5.messagelabs.com id
	0B/05-24595-249D34F4; Tue, 21 Feb 2012 17:49:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329846594!16018213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3931 invoked from network); 21 Feb 2012 17:49:54 -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;
	21 Feb 2012 17:49:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:49:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:49:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztqb-0003Jh-N8; Tue, 21 Feb 2012 17:49:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztqb-0001wq-MP;
	Tue, 21 Feb 2012 17:49:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55617.474538.123777@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:49:53 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5e3ca9be617e7c82d305.1329831251@kodo2>
References: <patchbomb.1329831246@kodo2>
	<5e3ca9be617e7c82d305.1329831251@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 10] libxc: Implement SCHEDOP sysctl
	for	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 05 of 10] libxc: Implement SCHEDOP sysctl for credit scheduler"):
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
...
> +xc_sched_credit_param_set(
> +    xc_interface *xch,
> +    uint32_t cpupool_id,
> +    struct xen_sysctl_credit_schedule *schedule)

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:50:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztqe-0000p9-H9; Tue, 21 Feb 2012 17:49:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rztqd-0000oy-Cu
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:49:55 +0000
Received: from [85.158.139.83:52333] by server-12.bemta-5.messagelabs.com id
	0B/05-24595-249D34F4; Tue, 21 Feb 2012 17:49:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1329846594!16018213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3931 invoked from network); 21 Feb 2012 17:49:54 -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;
	21 Feb 2012 17:49:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:49:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:49:53 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rztqb-0003Jh-N8; Tue, 21 Feb 2012 17:49:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rztqb-0001wq-MP;
	Tue, 21 Feb 2012 17:49:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55617.474538.123777@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:49:53 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5e3ca9be617e7c82d305.1329831251@kodo2>
References: <patchbomb.1329831246@kodo2>
	<5e3ca9be617e7c82d305.1329831251@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 10] libxc: Implement SCHEDOP sysctl
	for	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 05 of 10] libxc: Implement SCHEDOP sysctl for credit scheduler"):
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
...
> +xc_sched_credit_param_set(
> +    xc_interface *xch,
> +    uint32_t cpupool_id,
> +    struct xen_sysctl_credit_schedule *schedule)

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:52:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztsS-00011N-0P; Tue, 21 Feb 2012 17:51:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RztsR-00010Q-2n
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:51:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329846699!16263657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4578 invoked from network); 21 Feb 2012 17:51:39 -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;
	21 Feb 2012 17:51:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:51:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:51:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztsJ-0003KO-07; Tue, 21 Feb 2012 17:51:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztsI-0001x6-UP;
	Tue, 21 Feb 2012 17:51:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55722.928406.510062@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:51:38 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d70161aab13edea6f2f4.1329831254@kodo2>
References: <patchbomb.1329831246@kodo2>
	<d70161aab13edea6f2f4.1329831254@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 08 of 10] libxl:
	Implement	libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 08 of 10] libxl: Implement libxl_sched_credit_param_[gs]et"):
> Implement functions to set credit scheduler global parameters.

Again, just some niggles:

> +int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)

Long line here and in _set.

Shouldn't this be "params" rather than "param" since it sets several
parameters ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:52:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztsS-00011N-0P; Tue, 21 Feb 2012 17:51:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RztsR-00010Q-2n
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:51:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1329846699!16263657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4578 invoked from network); 21 Feb 2012 17:51:39 -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;
	21 Feb 2012 17:51:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:51:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:51:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztsJ-0003KO-07; Tue, 21 Feb 2012 17:51:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztsI-0001x6-UP;
	Tue, 21 Feb 2012 17:51:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55722.928406.510062@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:51:38 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d70161aab13edea6f2f4.1329831254@kodo2>
References: <patchbomb.1329831246@kodo2>
	<d70161aab13edea6f2f4.1329831254@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 08 of 10] libxl:
	Implement	libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 08 of 10] libxl: Implement libxl_sched_credit_param_[gs]et"):
> Implement functions to set credit scheduler global parameters.

Again, just some niggles:

> +int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)

Long line here and in _set.

Shouldn't this be "params" rather than "param" since it sets several
parameters ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:52:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzttJ-000183-GD; Tue, 21 Feb 2012 17:52:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzttH-00017N-Qc
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:52:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329846753!15245482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26344 invoked from network); 21 Feb 2012 17:52:33 -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;
	21 Feb 2012 17:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:52:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:52:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzttB-0003Ki-DH; Tue, 21 Feb 2012 17:52:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzttB-0001xF-CV;
	Tue, 21 Feb 2012 17:52:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55777.375328.208241@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:52:33 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <127b33c09db2bcf9b11a.1329831253@kodo2>
References: <patchbomb.1329831246@kodo2>
	<127b33c09db2bcf9b11a.1329831253@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to
	include	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to include _domain"):
> In preparation for introducing a schedule parameter-based structure,
> rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

If you're feeling nice you could rewrap the long lines.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:52:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:52:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzttJ-000183-GD; Tue, 21 Feb 2012 17:52:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzttH-00017N-Qc
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:52:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329846753!15245482!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26344 invoked from network); 21 Feb 2012 17:52:33 -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;
	21 Feb 2012 17:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:52:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:52:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzttB-0003Ki-DH; Tue, 21 Feb 2012 17:52:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzttB-0001xF-CV;
	Tue, 21 Feb 2012 17:52:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.55777.375328.208241@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:52:33 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <127b33c09db2bcf9b11a.1329831253@kodo2>
References: <patchbomb.1329831246@kodo2>
	<127b33c09db2bcf9b11a.1329831253@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to
	include	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("[Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to include _domain"):
> In preparation for introducing a schedule parameter-based structure,
> rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

If you're feeling nice you could rewrap the long lines.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:55:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztvQ-0001Or-Co; Tue, 21 Feb 2012 17:54:52 +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 1RztvN-0001Oc-BV
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:54:49 +0000
Received: from [85.158.139.83:10398] by server-12.bemta-5.messagelabs.com id
	94/1D-24595-86AD34F4; Tue, 21 Feb 2012 17:54:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329846886!15170277!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27499 invoked from network); 21 Feb 2012 17:54:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325480400"; d="scan'208";a="182806649"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:54:45 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 12:54:45 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1RztvI-0003P7-Tt;
	Tue, 21 Feb 2012 17:54:44 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20291.55777.375328.208241@mariner.uk.xensource.com>
References: <patchbomb.1329831246@kodo2>
	<127b33c09db2bcf9b11a.1329831253@kodo2>
	<20291.55777.375328.208241@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:54:45 +0000
Message-ID: <1329846885.2196.112.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to
 include	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 17:52 +0000, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to include _domain"):
> > In preparation for introducing a schedule parameter-based structure,
> > rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> If you're feeling nice you could rewrap the long lines.

Might as well. :-)

 -George

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:55:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:55:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztvQ-0001Or-Co; Tue, 21 Feb 2012 17:54:52 +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 1RztvN-0001Oc-BV
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:54:49 +0000
Received: from [85.158.139.83:10398] by server-12.bemta-5.messagelabs.com id
	94/1D-24595-86AD34F4; Tue, 21 Feb 2012 17:54:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329846886!15170277!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY4MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27499 invoked from network); 21 Feb 2012 17:54:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325480400"; d="scan'208";a="182806649"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:54:45 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 12:54:45 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1RztvI-0003P7-Tt;
	Tue, 21 Feb 2012 17:54:44 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20291.55777.375328.208241@mariner.uk.xensource.com>
References: <patchbomb.1329831246@kodo2>
	<127b33c09db2bcf9b11a.1329831253@kodo2>
	<20291.55777.375328.208241@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:54:45 +0000
Message-ID: <1329846885.2196.112.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to
 include	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 17:52 +0000, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 07 of 10] libxl: Rename libxl_sched_* to include _domain"):
> > In preparation for introducing a schedule parameter-based structure,
> > rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> If you're feeling nice you could rewrap the long lines.

Might as well. :-)

 -George

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztws-0001Zw-Ko; Tue, 21 Feb 2012 17:56:22 +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 1Rztwq-0001Zh-Nm
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:56:20 +0000
Received: from [85.158.139.83:16302] by server-10.bemta-5.messagelabs.com id
	F8/CB-07861-3CAD34F4; Tue, 21 Feb 2012 17:56:19 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329846977!12100247!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29474 invoked from network); 21 Feb 2012 17:56:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325480400"; d="scan'208";a="22303439"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:56:16 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 12:56:16 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1Rztwm-0003QR-0l;
	Tue, 21 Feb 2012 17:56:16 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20291.55722.928406.510062@mariner.uk.xensource.com>
References: <patchbomb.1329831246@kodo2>
	<d70161aab13edea6f2f4.1329831254@kodo2>
	<20291.55722.928406.510062@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:56:16 +0000
Message-ID: <1329846976.2196.114.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10] libxl: Implement
 libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 17:51 +0000, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 08 of 10] libxl: Implement libxl_sched_credit_param_[gs]et"):
> > Implement functions to set credit scheduler global parameters.
> 
> Again, just some niggles:
> 
> > +int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)
> 
> Long line here and in _set.
> 
> Shouldn't this be "params" rather than "param" since it sets several
> parameters ?

Hmm, I suppose so.  I think I accidentally said "param" because I
originally wrote the patch series, the structure actually only contained
one parameter.  Then I thought I might as well do both at the same time,
but didn't have to re-write this patch. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:56:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rztws-0001Zw-Ko; Tue, 21 Feb 2012 17:56:22 +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 1Rztwq-0001Zh-Nm
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:56:20 +0000
Received: from [85.158.139.83:16302] by server-10.bemta-5.messagelabs.com id
	F8/CB-07861-3CAD34F4; Tue, 21 Feb 2012 17:56:19 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1329846977!12100247!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29474 invoked from network); 21 Feb 2012 17:56:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325480400"; d="scan'208";a="22303439"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 12:56:16 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 12:56:16 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1Rztwm-0003QR-0l;
	Tue, 21 Feb 2012 17:56:16 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20291.55722.928406.510062@mariner.uk.xensource.com>
References: <patchbomb.1329831246@kodo2>
	<d70161aab13edea6f2f4.1329831254@kodo2>
	<20291.55722.928406.510062@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:56:16 +0000
Message-ID: <1329846976.2196.114.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10] libxl: Implement
 libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 17:51 +0000, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 08 of 10] libxl: Implement libxl_sched_credit_param_[gs]et"):
> > Implement functions to set credit scheduler global parameters.
> 
> Again, just some niggles:
> 
> > +int libxl_sched_credit_param_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit_param *scinfo)
> 
> Long line here and in _set.
> 
> Shouldn't this be "params" rather than "param" since it sets several
> parameters ?

Hmm, I suppose so.  I think I accidentally said "param" because I
originally wrote the patch series, the structure actually only contained
one parameter.  Then I thought I might as well do both at the same time,
but didn't have to re-write this patch. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:56:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17: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 1RztxE-0001d9-32; Tue, 21 Feb 2012 17:56:44 +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 1RztxD-0001cr-3t
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:56:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329846935!62011298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27999 invoked from network); 21 Feb 2012 17:55:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:55:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 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.213.0; Tue, 21 Feb 2012 17:56:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztxB-0003MS-H6; Tue, 21 Feb 2012 17:56:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztxB-0001xo-GD;
	Tue, 21 Feb 2012 17:56:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56025.490397.260688@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:56:41 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4f3e3d7016735b6c7a28.1329831256@kodo2>
References: <patchbomb.1329831246@kodo2>
	<4f3e3d7016735b6c7a28.1329831256@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit
 schedule parameter command-line 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

George Dunlap writes ("[Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> Add features to the sched-credit interface to allow querying and
> displaying scheduler parameters.  New interface works as follows:
> 
>  <nothing>             : List all domain params and sched params from all pools
>  -d [domid]            : List domain params for domain
>  -d [domid] [params]   : Set domain params for domain
>  -p [pool]             : list all domains and sched params for pool
>  -s                    : List sched params for poolid 0
>  -s [params]           : Set sched params for poolid 0
>  -p [pool] -s          : List sched params for pool
>  -p [pool] -s [params] : Set sched params for pool
>  -p [pool] -d...       : Illegal

This information should be in the xl manpage, rather than in the
commit message and a code comment.

> +static int sched_credit_param_set(
> +    int poolid, libxl_sched_credit_param *scinfo)
> +{

Formatting.  It should be

static int sched_credit_param_set(int poolid, libxl_sched_credit_param *scinfo)

(79 columns) or

static int sched_credit_param_set(int poolid,
                                  libxl_sched_credit_param *scinfo)

(67 columns).

This should be changed throughout I'm afraid.

> +        } else { /* Set scheduling parameters*/
> +            rc = sched_credit_param_get(poolid, &scparam);

What happens if the pool isn't using the credit scheduler ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:56:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17: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 1RztxE-0001d9-32; Tue, 21 Feb 2012 17:56:44 +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 1RztxD-0001cr-3t
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:56:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329846935!62011298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27999 invoked from network); 21 Feb 2012 17:55:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 17:55:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 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.213.0; Tue, 21 Feb 2012 17:56:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztxB-0003MS-H6; Tue, 21 Feb 2012 17:56:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztxB-0001xo-GD;
	Tue, 21 Feb 2012 17:56:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56025.490397.260688@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:56:41 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4f3e3d7016735b6c7a28.1329831256@kodo2>
References: <patchbomb.1329831246@kodo2>
	<4f3e3d7016735b6c7a28.1329831256@kodo2>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit
 schedule parameter command-line 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

George Dunlap writes ("[Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> Add features to the sched-credit interface to allow querying and
> displaying scheduler parameters.  New interface works as follows:
> 
>  <nothing>             : List all domain params and sched params from all pools
>  -d [domid]            : List domain params for domain
>  -d [domid] [params]   : Set domain params for domain
>  -p [pool]             : list all domains and sched params for pool
>  -s                    : List sched params for poolid 0
>  -s [params]           : Set sched params for poolid 0
>  -p [pool] -s          : List sched params for pool
>  -p [pool] -s [params] : Set sched params for pool
>  -p [pool] -d...       : Illegal

This information should be in the xl manpage, rather than in the
commit message and a code comment.

> +static int sched_credit_param_set(
> +    int poolid, libxl_sched_credit_param *scinfo)
> +{

Formatting.  It should be

static int sched_credit_param_set(int poolid, libxl_sched_credit_param *scinfo)

(79 columns) or

static int sched_credit_param_set(int poolid,
                                  libxl_sched_credit_param *scinfo)

(67 columns).

This should be changed throughout I'm afraid.

> +        } else { /* Set scheduling parameters*/
> +            rc = sched_credit_param_get(poolid, &scparam);

What happens if the pool isn't using the credit scheduler ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:58:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztyG-0001r8-W7; Tue, 21 Feb 2012 17:57: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 1RztyF-0001qn-8O
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:57:47 +0000
Received: from [85.158.139.83:21990] by server-1.bemta-5.messagelabs.com id
	61/74-28458-A1BD34F4; Tue, 21 Feb 2012 17:57:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329847065!15990523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2352 invoked from network); 21 Feb 2012 17:57:46 -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;
	21 Feb 2012 17:57:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:57:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:57:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztyD-0003Mm-L0; Tue, 21 Feb 2012 17:57:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztyD-0001xz-K9;
	Tue, 21 Feb 2012 17:57:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56089.609979.980237@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:57:45 +0000
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1329846976.2196.114.camel@elijah>
References: <patchbomb.1329831246@kodo2>
	<d70161aab13edea6f2f4.1329831254@kodo2>
	<20291.55722.928406.510062@mariner.uk.xensource.com>
	<1329846976.2196.114.camel@elijah>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10] libxl: Implement
 libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 08 of 10] libxl: Implement libxl_sched_credit_param_[gs]et"):
> On Tue, 2012-02-21 at 17:51 +0000, Ian Jackson wrote:
> > Shouldn't this be "params" rather than "param" since it sets several
> > parameters ?
> 
> Hmm, I suppose so.  I think I accidentally said "param" because I
> originally wrote the patch series, the structure actually only contained
> one parameter.  Then I thought I might as well do both at the same time,
> but didn't have to re-write this patch. :-)

Well, a "params" struct containing only one param for this particular
scheduler is less weird than a "param" one containing several...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 17:58:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 17:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RztyG-0001r8-W7; Tue, 21 Feb 2012 17:57: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 1RztyF-0001qn-8O
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 17:57:47 +0000
Received: from [85.158.139.83:21990] by server-1.bemta-5.messagelabs.com id
	61/74-28458-A1BD34F4; Tue, 21 Feb 2012 17:57:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329847065!15990523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2352 invoked from network); 21 Feb 2012 17:57:46 -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;
	21 Feb 2012 17:57:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 17:57:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 17:57:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RztyD-0003Mm-L0; Tue, 21 Feb 2012 17:57:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RztyD-0001xz-K9;
	Tue, 21 Feb 2012 17:57:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56089.609979.980237@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 17:57:45 +0000
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1329846976.2196.114.camel@elijah>
References: <patchbomb.1329831246@kodo2>
	<d70161aab13edea6f2f4.1329831254@kodo2>
	<20291.55722.928406.510062@mariner.uk.xensource.com>
	<1329846976.2196.114.camel@elijah>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10] libxl: Implement
 libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 08 of 10] libxl: Implement libxl_sched_credit_param_[gs]et"):
> On Tue, 2012-02-21 at 17:51 +0000, Ian Jackson wrote:
> > Shouldn't this be "params" rather than "param" since it sets several
> > parameters ?
> 
> Hmm, I suppose so.  I think I accidentally said "param" because I
> originally wrote the patch series, the structure actually only contained
> one parameter.  Then I thought I might as well do both at the same time,
> but didn't have to re-write this patch. :-)

Well, a "params" struct containing only one param for this particular
scheduler is less weird than a "param" one containing several...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:03:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzu36-0002MQ-Ah; Tue, 21 Feb 2012 18:02:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzu34-0002M7-Vq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:02:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329847360!7051840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12079 invoked from network); 21 Feb 2012 18:02:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:02:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:02:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzu2x-0003Os-NP; Tue, 21 Feb 2012 18:02:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzu2x-00027J-MT;
	Tue, 21 Feb 2012 18:02:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56383.499378.463797@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:02:39 +0000
To: "Bamvor Jian Zhang" <bjzhang@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bamvor Jian Zhang writes ("[Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> 
> a, libxl_event.h is included in libxl.h. So, the former one also need to be
> installed.

Well spotted.  However, I'm afraid your mail has been very badly
mangled by whatever program you used to send it.  For this patch I
reconstructed the change by hand and have committed it.

> b, define __XEN_TOOLS__ in libxl.h:
> the head file "xen/sysctl.h" need check this macro.

I don't think this is correct.

> It is the same way used by the xen libxc public headers(tools/libxc/xenctrl.h
> and tools/libxc/xenctrlosdep.h).

Users of libxl should not be using libxc directly and therefore should
not be including xenctrl.h.

Note that the API for libxl has changed in xen-unstable.hg compared to
4.1, and further changes are forthcoming.  So there will have to be
changes in libvirt.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:03:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzu36-0002MQ-Ah; Tue, 21 Feb 2012 18:02:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzu34-0002M7-Vq
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:02:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329847360!7051840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12079 invoked from network); 21 Feb 2012 18:02:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851579"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:02:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:02:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzu2x-0003Os-NP; Tue, 21 Feb 2012 18:02:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzu2x-00027J-MT;
	Tue, 21 Feb 2012 18:02:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56383.499378.463797@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:02:39 +0000
To: "Bamvor Jian Zhang" <bjzhang@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bamvor Jian Zhang writes ("[Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> 
> a, libxl_event.h is included in libxl.h. So, the former one also need to be
> installed.

Well spotted.  However, I'm afraid your mail has been very badly
mangled by whatever program you used to send it.  For this patch I
reconstructed the change by hand and have committed it.

> b, define __XEN_TOOLS__ in libxl.h:
> the head file "xen/sysctl.h" need check this macro.

I don't think this is correct.

> It is the same way used by the xen libxc public headers(tools/libxc/xenctrl.h
> and tools/libxc/xenctrlosdep.h).

Users of libxl should not be using libxc directly and therefore should
not be including xenctrl.h.

Note that the API for libxl has changed in xen-unstable.hg compared to
4.1, and further changes are forthcoming.  So there will have to be
changes in libvirt.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:04:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzu4B-0002R0-R6; Tue, 21 Feb 2012 18:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1Rzu4A-0002Qg-NI
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:03:54 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329847426!15259067!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30606 invoked from network); 21 Feb 2012 18:03:48 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 18:03:48 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LI3hfr031836
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 11:03:43 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1329835108.3990.108.camel@zakaz.uk.xensource.com>
Date: Tue, 21 Feb 2012 11:03:54 -0700
Message-Id: <62D2BC95-E6F0-4308-BEFC-415F69B93A68@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
	<1329835108.3990.108.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 21 Feb 2012 11:03:44 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Feb 21, 2012, at 7:38 AM, Ian Campbell wrote:

> On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
>> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>>      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>>      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>>      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>>      this value.
>> 
>> This extension first appeared in the FreeBSD Operating System.
>> 
>> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>> 
>> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
>> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
>> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
>> @@ -145,6 +145,32 @@
>>  *      The maximum supported size of the request ring buffer in units of
>>  *      machine pages.  The value must be a power of 2.
>>  *
>> + * max-requests         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
>> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
>> + *
>> + *      The maximum number of concurrent, logical requests that will be
>> + *      issued by the backend.
> 
> by "issued" do you mean the maximum number that the backend is willing
> to consume/have-in-flight at once? I guess that means issued to the
> underlying storage? (backend doesn't issue requests to the frontend does
> it? That's how I first read it, hence my question)
> 
> Ian.
> 

I should have used the same language as in the other entries.  Does this
make more sense?

 *      The maximum number of concurrent, logical requests supported by
 *      the backend.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:04:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzu4B-0002R0-R6; Tue, 21 Feb 2012 18:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1Rzu4A-0002Qg-NI
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:03:54 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329847426!15259067!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30606 invoked from network); 21 Feb 2012 18:03:48 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 18:03:48 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LI3hfr031836
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 11:03:43 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1329835108.3990.108.camel@zakaz.uk.xensource.com>
Date: Tue, 21 Feb 2012 11:03:54 -0700
Message-Id: <62D2BC95-E6F0-4308-BEFC-415F69B93A68@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
	<1329835108.3990.108.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 21 Feb 2012 11:03:44 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Feb 21, 2012, at 7:38 AM, Ian Campbell wrote:

> On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
>> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>>      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>>      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>>      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>>      this value.
>> 
>> This extension first appeared in the FreeBSD Operating System.
>> 
>> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>> 
>> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
>> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
>> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
>> @@ -145,6 +145,32 @@
>>  *      The maximum supported size of the request ring buffer in units of
>>  *      machine pages.  The value must be a power of 2.
>>  *
>> + * max-requests         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
>> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
>> + *
>> + *      The maximum number of concurrent, logical requests that will be
>> + *      issued by the backend.
> 
> by "issued" do you mean the maximum number that the backend is willing
> to consume/have-in-flight at once? I guess that means issued to the
> underlying storage? (backend doesn't issue requests to the frontend does
> it? That's how I first read it, hence my question)
> 
> Ian.
> 

I should have used the same language as in the other entries.  Does this
make more sense?

 *      The maximum number of concurrent, logical requests supported by
 *      the backend.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzu7u-0002fa-IB; Tue, 21 Feb 2012 18:07:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzu7t-0002fC-8w
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:07:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329847657!9173084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27507 invoked from network); 21 Feb 2012 18:07:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:07:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:07:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:07:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rzu7l-0003SX-2C;
	Tue, 21 Feb 2012 18:07:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rzu7k-0007CW-Vw;
	Tue, 21 Feb 2012 18:07:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11997-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 18:07:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11997: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11997 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11997/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11988

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:07:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzu7u-0002fa-IB; Tue, 21 Feb 2012 18:07:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rzu7t-0002fC-8w
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:07:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329847657!9173084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27507 invoked from network); 21 Feb 2012 18:07:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:07:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:07:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:07:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rzu7l-0003SX-2C;
	Tue, 21 Feb 2012 18:07:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rzu7k-0007CW-Vw;
	Tue, 21 Feb 2012 18:07:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11997-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 18:07:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11997: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11997 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11997/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11986
 build-amd64                   4 xen-build                 fail REGR. vs. 11986

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11988

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            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      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0900b1c905f1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24847:0900b1c905f1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:58:07 2012 +0000
    
    tools/hotplug: remove 4 from default runlevel in xencommons
    
    LSB defines runlevel 4 as "reserved for local use, default is
    normal/full multiuser"
    
    The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
    xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
    Default-Start: line. As a result insserv will print a warning:
    
    insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
    
    Since the local admin is responsible to create all symlinks manually in
    /etc/init.d/rc4.d/ the xencommons script should not automatically enable
    itself in runlevel 4.
    
    So, remove the 4 from Default-Start: line.
    
    Note: This change will not automatically remove old/stale xencommon
    symlinks in /etc/init.d/rc4.d/ during a package upgrade.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24846:7060509e36e5
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:57:33 2012 +0000
    
    tools/examples: mention output_format= in examples/xl.conf
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24845:0da2e4935a7b
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 18:56:57 2012 +0000
    
    docs/man: correct autoballoon in xl.conf
    
    Correct wording and default value of autoballoon= in xl.conf(5)
    to match code and supplied xl.conf.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24844:c78636d15ac5
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 20 18:48:32 2012 +0000
    
    minios: Remove unused variables warnings
    
    s/DEBUG/printk/ in test_xenbus and all associated do_*_test+xenbus_dbg_message
    and always print the IRQ and MFN used by the xenbus on init.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: John McDermott <john.mcdermott@nrl.navy.mil>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24843:3059bc2c14f7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    libxl: Set VNC password through QMP
    
    This patch provide the code to set the VNC password to QEMU upstream through
    VNC. The password is still stored in xenstore but will not be used by QEMU
    upstream.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24842:2c2afbd7cef7
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:29 2012 +0000
    
    Provide dm_vnc() as a in libxl helper.
    
    Just to use this function in more than one file.c.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24841:a2d15eaa2fe2
user:        Anthony PERARD <anthony.perard@citrix.com>
date:        Mon Feb 20 18:45:28 2012 +0000
    
    libxl_qmp: Use GC instead of CTX as parameter for _initialize.
    
    This make things a bit easier.
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24840:ca80eca9cfa3
user:        Shriram Rajagopalan <rshriram@cs.ubc.ca>
date:        Mon Feb 20 18:34:14 2012 +0000
    
    remus: libcheckpoint - initialize unused callback fields to NULL
    
    Add a memset to the save_callbacks struct instance in libcheckpoint's
    initialization code. New additions to the callback struct will not
    need to add an explicit initialization (to NULL), to maintain
    compatibility with older xend/remus based invocation of xc_domain_save.
    
    Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1Rzu9y-0002n5-43; Tue, 21 Feb 2012 18:09:54 +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 1Rzu9w-0002mv-PF
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:09:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329847662!62265256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29307 invoked from network); 21 Feb 2012 18:07:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:09:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:09:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzu9v-0003Te-6y	for xen-devel@lists.xensource.com;
	Tue, 21 Feb 2012 18:09:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzu9v-000289-66	for
	xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:09:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56815.172180.372297@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:09:51 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11997-mainreport@xen.org>
References: <osstest-11997-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11997: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 11997: regressions - FAIL"):
> flight 11997 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11997/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           4 xen-build              fail REGR. vs. 11986
>  build-amd64                   4 xen-build              fail REGR. vs. 11986

I think I have finally managed to fix this so the next one shouldn't
die this way.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1Rzu9y-0002n5-43; Tue, 21 Feb 2012 18:09:54 +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 1Rzu9w-0002mv-PF
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:09:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1329847662!62265256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29307 invoked from network); 21 Feb 2012 18:07:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:07:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:09:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:09:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rzu9v-0003Te-6y	for xen-devel@lists.xensource.com;
	Tue, 21 Feb 2012 18:09:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rzu9v-000289-66	for
	xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:09:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.56815.172180.372297@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:09:51 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11997-mainreport@xen.org>
References: <osstest-11997-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11997: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] 11997: regressions - FAIL"):
> flight 11997 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11997/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           4 xen-build              fail REGR. vs. 11986
>  build-amd64                   4 xen-build              fail REGR. vs. 11986

I think I have finally managed to fix this so the next one shouldn't
die this way.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:12:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzuBy-0002ve-92; Tue, 21 Feb 2012 18:11:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzuBx-0002us-6P
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:11:57 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329847909!14312768!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30497 invoked from network); 21 Feb 2012 18:11:50 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 18:11:50 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LIBWFt031906
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 11:11:32 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120221142204.GF11950@phenom.dumpdata.com>
Date: Tue, 21 Feb 2012 11:11:42 -0700
Message-Id: <3B89BF4E-125B-4CEC-9E53-78933C699B8F@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
	<20120221142204.GF11950@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 21 Feb 2012 11:11:32 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Feb 21, 2012, at 7:22 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 20, 2012 at 11:07:25AM -0700, Justin T. Gibbs wrote:
>> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>>      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>>      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>>      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>>      this value.
>> 
>> This extension first appeared in the FreeBSD Operating System.
>> 
>> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>> 
>> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
>> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
>> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
>> @@ -145,6 +145,32 @@
>>  *      The maximum supported size of the request ring buffer in units of
>>  *      machine pages.  The value must be a power of 2.
>>  *
>> + * max-requests         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
>> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
>> + *
>> + *      The maximum number of concurrent, logical requests that will be
>> + *      issued by the backend.
> 
> Don't you mean responses?

No, but it is poorly worded.  See my reply to Ian C.

>> + * max-request-size
>> + *      Values:         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
>> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
>> + *
>> + *      The maximum amount of data, in bytes, that can be referenced by a
>> + *      request type that accesses frontend memory (currently BLKIF_OP_READ,
>> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> 
> So just to make sure my math is correct. That would be 1MB right?

Assuming a 4K PAGE_SIZE, the maximum I/O possible is 1020KiB or .996MiB.
Allowing more segments would require expanding the 8bit nr_segments field,
severely complicating backwards compatibility.

> 
>> + *
>>  *------------------------- Backend Device Properties -------------------------
>>  *
>>  * discard-aligment
>> @@ -242,6 +268,33 @@
>>  *      The size of the frontend allocated request ring buffer in units of
>>  *      machine pages.  The value must be a power of 2.
>>  *
>> + * max-requests
>> + *      Values:         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
>> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
>> + *
>> + *      The maximum number of concurrent, logical requests that will be
>> + *      issued by the frontend.
>> + *
>> + *      Note: A logical request may span multiple ring entries.
>> + *
>> + * max-request-segments
>> + *      Values:         <uint8_t>
>> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
>> + *      Maximum Value:  MIN(255, backend/max-request-segments)
> 
> Um, that looks like its referencing itself? This is the backend section.

This is at the end of the frontend section, but the diff doesn't have
enough context to make that obvious.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:12:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzuBy-0002ve-92; Tue, 21 Feb 2012 18:11:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzuBx-0002us-6P
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:11:57 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329847909!14312768!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30497 invoked from network); 21 Feb 2012 18:11:50 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2012 18:11:50 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LIBWFt031906
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 11:11:32 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120221142204.GF11950@phenom.dumpdata.com>
Date: Tue, 21 Feb 2012 11:11:42 -0700
Message-Id: <3B89BF4E-125B-4CEC-9E53-78933C699B8F@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
	<20120221142204.GF11950@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 21 Feb 2012 11:11:32 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
	request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Feb 21, 2012, at 7:22 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 20, 2012 at 11:07:25AM -0700, Justin T. Gibbs wrote:
>> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>>      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
>>      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
>>      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
>>      this value.
>> 
>> This extension first appeared in the FreeBSD Operating System.
>> 
>> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>> 
>> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
>> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
>> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
>> @@ -145,6 +145,32 @@
>>  *      The maximum supported size of the request ring buffer in units of
>>  *      machine pages.  The value must be a power of 2.
>>  *
>> + * max-requests         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
>> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
>> + *
>> + *      The maximum number of concurrent, logical requests that will be
>> + *      issued by the backend.
> 
> Don't you mean responses?

No, but it is poorly worded.  See my reply to Ian C.

>> + * max-request-size
>> + *      Values:         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
>> + *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
>> + *
>> + *      The maximum amount of data, in bytes, that can be referenced by a
>> + *      request type that accesses frontend memory (currently BLKIF_OP_READ,
>> + *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> 
> So just to make sure my math is correct. That would be 1MB right?

Assuming a 4K PAGE_SIZE, the maximum I/O possible is 1020KiB or .996MiB.
Allowing more segments would require expanding the 8bit nr_segments field,
severely complicating backwards compatibility.

> 
>> + *
>>  *------------------------- Backend Device Properties -------------------------
>>  *
>>  * discard-aligment
>> @@ -242,6 +268,33 @@
>>  *      The size of the frontend allocated request ring buffer in units of
>>  *      machine pages.  The value must be a power of 2.
>>  *
>> + * max-requests
>> + *      Values:         <uint32_t>
>> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
>> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
>> + *
>> + *      The maximum number of concurrent, logical requests that will be
>> + *      issued by the frontend.
>> + *
>> + *      Note: A logical request may span multiple ring entries.
>> + *
>> + * max-request-segments
>> + *      Values:         <uint8_t>
>> + *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
>> + *      Maximum Value:  MIN(255, backend/max-request-segments)
> 
> Um, that looks like its referencing itself? This is the backend section.

This is at the end of the frontend section, but the diff doesn't have
enough context to make that obvious.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:12:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzuBx-0002vM-Lj; Tue, 21 Feb 2012 18:11:57 +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 1RzuBv-0002v2-R6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:11:56 +0000
Received: from [85.158.139.83:17245] by server-8.bemta-5.messagelabs.com id
	AA/51-09797-B6ED34F4; Tue, 21 Feb 2012 18:11:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329847913!8691716!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17206 invoked from network); 21 Feb 2012 18:11:54 -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 Feb 2012 18:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325480400"; d="scan'208";a="22304099"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:11:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:11:52 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1RzuBs-0003ds-F9;
	Tue, 21 Feb 2012 18:11:52 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20291.56025.490397.260688@mariner.uk.xensource.com>
References: <patchbomb.1329831246@kodo2>
	<4f3e3d7016735b6c7a28.1329831256@kodo2>
	<20291.56025.490397.260688@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:11:53 +0000
Message-ID: <1329847913.2196.123.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit
 schedule parameter command-line 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 Tue, 2012-02-21 at 17:56 +0000, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> > Add features to the sched-credit interface to allow querying and
> > displaying scheduler parameters.  New interface works as follows:
> > 
> >  <nothing>             : List all domain params and sched params from all pools
> >  -d [domid]            : List domain params for domain
> >  -d [domid] [params]   : Set domain params for domain
> >  -p [pool]             : list all domains and sched params for pool
> >  -s                    : List sched params for poolid 0
> >  -s [params]           : Set sched params for poolid 0
> >  -p [pool] -s          : List sched params for pool
> >  -p [pool] -s [params] : Set sched params for pool
> >  -p [pool] -d...       : Illegal
> 
> This information should be in the xl manpage, rather than in the
> commit message and a code comment.

Of course.  And, is there some other documentation that this should be
put into as well?  

> 
> > +static int sched_credit_param_set(
> > +    int poolid, libxl_sched_credit_param *scinfo)
> > +{
> 
> Formatting.  It should be
> 
> static int sched_credit_param_set(int poolid, libxl_sched_credit_param *scinfo)
> 
> (79 columns) or
> 
> static int sched_credit_param_set(int poolid,
>                                   libxl_sched_credit_param *scinfo)
> 
> (67 columns).
> 
> This should be changed throughout I'm afraid.

Ack.

> 
> > +        } else { /* Set scheduling parameters*/
> > +            rc = sched_credit_param_get(poolid, &scparam);
> 
> What happens if the pool isn't using the credit scheduler ?

Ah, good point.  I suppose it should just print the pool name.

What happens to output of domains when you use xl sched-credit and there
is a pool that's not using the credit scheduler?  It looks like it will
stop at that point and quit processing.  It seems like having it print
the domain ID and "[not sched-credit]" or something like that would be
better.

What would be *even* better is to unify these all somehow, so that xl
would automatically detect the appropriate scheduler for the pool and
behave accordingly.  But that's a patch series for another time, I
think.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:12:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzuBx-0002vM-Lj; Tue, 21 Feb 2012 18:11:57 +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 1RzuBv-0002v2-R6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:11:56 +0000
Received: from [85.158.139.83:17245] by server-8.bemta-5.messagelabs.com id
	AA/51-09797-B6ED34F4; Tue, 21 Feb 2012 18:11:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1329847913!8691716!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIzNTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17206 invoked from network); 21 Feb 2012 18:11:54 -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 Feb 2012 18:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325480400"; d="scan'208";a="22304099"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 13:11:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 13:11:52 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1RzuBs-0003ds-F9;
	Tue, 21 Feb 2012 18:11:52 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20291.56025.490397.260688@mariner.uk.xensource.com>
References: <patchbomb.1329831246@kodo2>
	<4f3e3d7016735b6c7a28.1329831256@kodo2>
	<20291.56025.490397.260688@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:11:53 +0000
Message-ID: <1329847913.2196.123.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit
 schedule parameter command-line 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 Tue, 2012-02-21 at 17:56 +0000, Ian Jackson wrote:
> George Dunlap writes ("[Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> > Add features to the sched-credit interface to allow querying and
> > displaying scheduler parameters.  New interface works as follows:
> > 
> >  <nothing>             : List all domain params and sched params from all pools
> >  -d [domid]            : List domain params for domain
> >  -d [domid] [params]   : Set domain params for domain
> >  -p [pool]             : list all domains and sched params for pool
> >  -s                    : List sched params for poolid 0
> >  -s [params]           : Set sched params for poolid 0
> >  -p [pool] -s          : List sched params for pool
> >  -p [pool] -s [params] : Set sched params for pool
> >  -p [pool] -d...       : Illegal
> 
> This information should be in the xl manpage, rather than in the
> commit message and a code comment.

Of course.  And, is there some other documentation that this should be
put into as well?  

> 
> > +static int sched_credit_param_set(
> > +    int poolid, libxl_sched_credit_param *scinfo)
> > +{
> 
> Formatting.  It should be
> 
> static int sched_credit_param_set(int poolid, libxl_sched_credit_param *scinfo)
> 
> (79 columns) or
> 
> static int sched_credit_param_set(int poolid,
>                                   libxl_sched_credit_param *scinfo)
> 
> (67 columns).
> 
> This should be changed throughout I'm afraid.

Ack.

> 
> > +        } else { /* Set scheduling parameters*/
> > +            rc = sched_credit_param_get(poolid, &scparam);
> 
> What happens if the pool isn't using the credit scheduler ?

Ah, good point.  I suppose it should just print the pool name.

What happens to output of domains when you use xl sched-credit and there
is a pool that's not using the credit scheduler?  It looks like it will
stop at that point and quit processing.  It seems like having it print
the domain ID and "[not sched-credit]" or something like that would be
better.

What would be *even* better is to unify these all somehow, so that xl
would automatically detect the appropriate scheduler for the pool and
behave accordingly.  But that's a patch series for another time, I
think.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:14:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:14:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuE8-0003At-Qq; Tue, 21 Feb 2012 18:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzuE7-0003AG-0c
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:14:11 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329848043!14335721!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22978 invoked from network); 21 Feb 2012 18:14:04 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 18:14:04 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LIE0Q9031921
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 11:14:01 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1329834420.3990.100.camel@zakaz.uk.xensource.com>
Date: Tue, 21 Feb 2012 11:14:11 -0700
Message-Id: <6792A135-57D1-4AE0-9690-F6B2B2E071BC@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<1329834420.3990.100.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 21 Feb 2012 11:14:01 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
	documentation of the blkif 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 Feb 21, 2012, at 7:27 AM, Ian Campbell wrote:

> On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
>> o Document the XenBus nodes used in this protocol.
>>  o Add a state diagram illustrating the roles and responsibilities
>>    of both the front and backend during startup.
>>  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
>> 
>> No functional changes.
>> 
>> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I've made some very minor comments below but I think getting the basic
> documentation of this stuff in as a baseline to improve and correct over
> time is more important than any of them.
> 
> Thanks again for doing this -- it is really valuable!

Thanks.

>> + * params
>> + *      Values:         string
>> + *
>> + *      A free formatted string providing sufficient information for the
>> + *      backend driver to open the backing device.  (e.g. the path to the
>> + *      file or block device representing the backing store.)
> 
> The syntax and semantics of params is defined by the particular backend,
> rather than being "free formatted" as such. I think it would be worth
> saying that explicitly.
> 
> Ian.

Perhaps something like this?

 * params                                                               
 *      Values:         string                                               
 *                                                                   
 *      Data used by the backend driver to locate and configure the backing
 *      device.  The format and semantics of this data vary according to the 
 *      backing device in use and are outside the scope of this specification.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:14:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:14:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuE8-0003At-Qq; Tue, 21 Feb 2012 18:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1RzuE7-0003AG-0c
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:14:11 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329848043!14335721!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22978 invoked from network); 21 Feb 2012 18:14:04 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 18:14:04 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LIE0Q9031921
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 11:14:01 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1329834420.3990.100.camel@zakaz.uk.xensource.com>
Date: Tue, 21 Feb 2012 11:14:11 -0700
Message-Id: <6792A135-57D1-4AE0-9690-F6B2B2E071BC@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<1329834420.3990.100.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Tue, 21 Feb 2012 11:14:01 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
	documentation of the blkif 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 Feb 21, 2012, at 7:27 AM, Ian Campbell wrote:

> On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
>> o Document the XenBus nodes used in this protocol.
>>  o Add a state diagram illustrating the roles and responsibilities
>>    of both the front and backend during startup.
>>  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
>> 
>> No functional changes.
>> 
>> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I've made some very minor comments below but I think getting the basic
> documentation of this stuff in as a baseline to improve and correct over
> time is more important than any of them.
> 
> Thanks again for doing this -- it is really valuable!

Thanks.

>> + * params
>> + *      Values:         string
>> + *
>> + *      A free formatted string providing sufficient information for the
>> + *      backend driver to open the backing device.  (e.g. the path to the
>> + *      file or block device representing the backing store.)
> 
> The syntax and semantics of params is defined by the particular backend,
> rather than being "free formatted" as such. I think it would be worth
> saying that explicitly.
> 
> Ian.

Perhaps something like this?

 * params                                                               
 *      Values:         string                                               
 *                                                                   
 *      Data used by the backend driver to locate and configure the backing
 *      device.  The format and semantics of this data vary according to the 
 *      backing device in use and are outside the scope of this specification.

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzuH3-0003Pm-E9; Tue, 21 Feb 2012 18: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 1RzuH1-0003Pf-U3
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:17:12 +0000
Received: from [85.158.139.83:35262] by server-7.bemta-5.messagelabs.com id
	49/5E-16195-7AFD34F4; Tue, 21 Feb 2012 18:17:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329848230!16028584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22198 invoked from network); 21 Feb 2012 18:17:10 -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;
	21 Feb 2012 18:17:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:17:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:17:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzuGz-0003WQ-SJ; Tue, 21 Feb 2012 18:17:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzuGz-0006n5-R7;
	Tue, 21 Feb 2012 18:17:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.57253.826402.506523@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:17:09 +0000
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1329847913.2196.123.camel@elijah>
References: <patchbomb.1329831246@kodo2>
	<4f3e3d7016735b6c7a28.1329831256@kodo2>
	<20291.56025.490397.260688@mariner.uk.xensource.com>
	<1329847913.2196.123.camel@elijah>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit
 schedule parameter command-line 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

George Dunlap writes ("Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> On Tue, 2012-02-21 at 17:56 +0000, Ian Jackson wrote:
> > George Dunlap writes ("[Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> > This information should be in the xl manpage, rather than in the
> > commit message and a code comment.
> 
> Of course.  And, is there some other documentation that this should be
> put into as well?  

I think what you have in the usage message, plus the manpage, is
sufficient.

> What would be *even* better is to unify these all somehow, so that xl
> would automatically detect the appropriate scheduler for the pool and
> behave accordingly.  But that's a patch series for another time, I
> think.

Sure.  I just wasn't sure from the code that you'd considered this
case.  I'd be happy with an error message of some kind, and a zero
exit status.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzuH3-0003Pm-E9; Tue, 21 Feb 2012 18: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 1RzuH1-0003Pf-U3
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:17:12 +0000
Received: from [85.158.139.83:35262] by server-7.bemta-5.messagelabs.com id
	49/5E-16195-7AFD34F4; Tue, 21 Feb 2012 18:17:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329848230!16028584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22198 invoked from network); 21 Feb 2012 18:17:10 -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;
	21 Feb 2012 18:17:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10851864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:17:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:17:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzuGz-0003WQ-SJ; Tue, 21 Feb 2012 18:17:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzuGz-0006n5-R7;
	Tue, 21 Feb 2012 18:17:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.57253.826402.506523@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:17:09 +0000
To: George Dunlap <george.dunlap@citrix.com>
In-Reply-To: <1329847913.2196.123.camel@elijah>
References: <patchbomb.1329831246@kodo2>
	<4f3e3d7016735b6c7a28.1329831256@kodo2>
	<20291.56025.490397.260688@mariner.uk.xensource.com>
	<1329847913.2196.123.camel@elijah>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit
 schedule parameter command-line 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

George Dunlap writes ("Re: [Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> On Tue, 2012-02-21 at 17:56 +0000, Ian Jackson wrote:
> > George Dunlap writes ("[Xen-devel] [PATCH 10 of 10] xl: Implement sched-credit schedule parameter command-line interface"):
> > This information should be in the xl manpage, rather than in the
> > commit message and a code comment.
> 
> Of course.  And, is there some other documentation that this should be
> put into as well?  

I think what you have in the usage message, plus the manpage, is
sufficient.

> What would be *even* better is to unify these all somehow, so that xl
> would automatically detect the appropriate scheduler for the pool and
> behave accordingly.  But that's a patch series for another time, I
> think.

Sure.  I just wasn't sure from the code that you'd considered this
case.  I'd be happy with an error message of some kind, and a zero
exit status.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuNp-0003vG-B5; Tue, 21 Feb 2012 18:24:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzuNo-0003v3-P5
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:24:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329848646!6132521!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2358 invoked from network); 21 Feb 2012 18:24:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:24:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10852044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:24:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:24:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzuNi-0003cq-GN; Tue, 21 Feb 2012 18:24:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzuNi-0004HC-BA;
	Tue, 21 Feb 2012 18:24:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.57670.186303.970388@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:24:06 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120220192655.GA8280@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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

Olaf Hering writes ("[Xen-devel] libxenstore.so Makefile dependency issue"):
> 
> This is the second time I run into this linking issue. A few days ago it
> happend with a make -j 4 or 8 during automated rpm package build. Now it
> happend with a fresh tree. My local system is openSuSE 11.4 with make
> 3.82, the failed automated build was either openSUSE 11.4 or 12.1.
> 
> For some reason the libxenstore.so symlink is created after
> init-xenstore-domain is about to be linked. The ln command is not
> visible in this output, I saw the ln invocation in the rpm build log.
> 
> Hmm, and for some reason the symlink was not created anyway in my local
> build. A second make run worked ok, libxenstore.so was created.  It
> looks like I can reproduce it by running make clean in tools/xenstore.
> 
> Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
> and libxenstore.so is also a target. So its not clear to me how make can
> miss that, or how the dependencies should be listed.

This is indeed mysterious.  I haven't managed to reproduce it either.

I tried the patch below, with make -j1000, and everything worked the
way it should do.

Ian.

diff -r 6a34a42a2b5d tools/xenstore/Makefile
--- a/tools/xenstore/Makefile	Tue Feb 21 18:01:04 2012 +0000
+++ b/tools/xenstore/Makefile	Tue Feb 21 18:23:46 2012 +0000
@@ -82,7 +82,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.
 xs.opic: 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)
+	set -x; while test ! -f go$$$$; do sleep 10; done; $(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)
 
 libxenstore.a: xs.o xs_lib.o
 	$(AR) rcs $@ $^

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuNp-0003vG-B5; Tue, 21 Feb 2012 18:24:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzuNo-0003v3-P5
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:24:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329848646!6132521!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2358 invoked from network); 21 Feb 2012 18:24:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:24:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="10852044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:24:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:24:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzuNi-0003cq-GN; Tue, 21 Feb 2012 18:24:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzuNi-0004HC-BA;
	Tue, 21 Feb 2012 18:24:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.57670.186303.970388@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:24:06 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120220192655.GA8280@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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

Olaf Hering writes ("[Xen-devel] libxenstore.so Makefile dependency issue"):
> 
> This is the second time I run into this linking issue. A few days ago it
> happend with a make -j 4 or 8 during automated rpm package build. Now it
> happend with a fresh tree. My local system is openSuSE 11.4 with make
> 3.82, the failed automated build was either openSUSE 11.4 or 12.1.
> 
> For some reason the libxenstore.so symlink is created after
> init-xenstore-domain is about to be linked. The ln command is not
> visible in this output, I saw the ln invocation in the rpm build log.
> 
> Hmm, and for some reason the symlink was not created anyway in my local
> build. A second make run worked ok, libxenstore.so was created.  It
> looks like I can reproduce it by running make clean in tools/xenstore.
> 
> Looking at the Makefile, init-xenstore-domain depends on LIBXENSTORE,
> and libxenstore.so is also a target. So its not clear to me how make can
> miss that, or how the dependencies should be listed.

This is indeed mysterious.  I haven't managed to reproduce it either.

I tried the patch below, with make -j1000, and everything worked the
way it should do.

Ian.

diff -r 6a34a42a2b5d tools/xenstore/Makefile
--- a/tools/xenstore/Makefile	Tue Feb 21 18:01:04 2012 +0000
+++ b/tools/xenstore/Makefile	Tue Feb 21 18:23:46 2012 +0000
@@ -82,7 +82,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.
 xs.opic: 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)
+	set -x; while test ! -f go$$$$; do sleep 10; done; $(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)
 
 libxenstore.a: xs.o xs_lib.o
 	$(AR) rcs $@ $^

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:27:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuQP-00041p-VQ; Tue, 21 Feb 2012 18:26:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzuQO-00041j-DP
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:26:52 +0000
Received: from [85.158.139.83:27702] by server-2.bemta-5.messagelabs.com id
	5D/6E-20263-BE1E34F4; Tue, 21 Feb 2012 18:26:51 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329848810!15993080!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9259 invoked from network); 21 Feb 2012 18:26:50 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:26:50 -0000
Received: by wgbdr13 with SMTP id dr13so5290395wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 10:26:50 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr36725916wia.3.1329848810350 (num_hops
	= 1); Tue, 21 Feb 2012 10:26:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr30643580wia.3.1329848810185; Tue,
	21 Feb 2012 10:26:50 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Tue, 21 Feb 2012 10:26:50 -0800 (PST)
In-Reply-To: <B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
References: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
	<B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 21 Feb 2012 10:26:50 -0800
Message-ID: <CAMrHX2Wmci7n5h1NsseiRHr3-TZ_JbY_6aKJFvHTaw4wOxGqHg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Gm-Message-State: ALoCoQmgoWd+iBGY9UrmXTHR+vyQWBNt8BUMcy1qzCXYY1quTrWs46avq0UiCj9zu/HhM2ITO/Wl
Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks Xiantao,

I am using a Dual Xeon Tyan server here and VT-d is enabled.  I was
hoping someone might spot something special in the PCI listing for the
device that might explain why I haven't been able to get the second
GPU to start.
One difference between the primary and secondary GPU is that the
second GPU on the card does not have any VGA output capability.
However, we're not needing VGA output as we remote in to the guest.
This limitation hasn't stopped us from getting VMWare to successfully
dedicate the second GPU to it's on virtual machine.

Looking at the xen-unstable source tree I do see some significant
changes to VGA passthrough so I may try this and see if I have any
success.

Matt

On 20 February 2012 22:54, Zhang, Xiantao <xiantao.zhang@intel.com> wrote:
> If the card has two =A0full-fledged =A0PCI-e graphics functions, I think =
you can follow the link(http://wiki.xen.org/wiki/Xen_VGA_Passthrough) to do=
 your passthru work. It depends on Intel's VT-d or AMD's IOMMU technology, =
so please make sure all required components are ready in your system. =A0 I=
 think Xen's mailing list archive also has some detailed discussions about =
how to passthru one graphics device to the guest and what's difference comp=
ared with general PCIe device assignment.
> Xiantao
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Matthew Hook
>> Sent: Tuesday, February 21, 2012 12:59 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
>>
>> Is it possible in Xen that with a dual GPU graphics card which appears a=
s two
>> separately addressable PCI devices to pass each GPU to a separate guest?
>> Although I didn't think this was initially possible, VMWare supports it.
>> It's useful under xen for increasing virtual server density when providi=
ng
>> virtual desktops or similar.
>> Although not many Dual GPU cards are on the market at the moment, it
>> seems likely that Dual or Quad GPU cards will become the norm in the near
>> future.
>>
>> For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
>> I have successfully managed to passthru one of the GPU's on the card with
>> success. =A0However I get a BSOD on the second one.
>>
>> I'm wondering if compiling in the VGA BIOS may help?
>> If so, where is a good resource on how I could do that?
>>
>>
>> Cards show in lspci as follows:
>>
>> 12:00.0 Display controller: ATI Technologies Inc Device 671d
>> 12:00.1 Audio device: ATI Technologies Inc Device aa80
>> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
>> 13:00.1 Audio device: ATI Technologies Inc Device aa80
>>
>>
>> ATI Technologies Inc Device aa80
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0+-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-0=
4.0-[0000:10-13]----00.0-
>> [0000:11-13]--+-04.0-[0000:13]--+-00.0
>> =A0ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies
>> Inc Device aa80
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \-08.0-[0000:12]--+-=
00.0 =A0ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies Inc Device aa80
>>
>>
>> More details on the devices themselves.
>>
>> 12:00.0 Display controller: ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 1b2a
>> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASno=
op-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast =
>TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
>> =A0 =A0 =A0 =A0 Region 0: Memory at 80000000 (64-bit, prefetchable) [dis=
abled]
>> [size=3D256M]
>> =A0 =A0 =A0 =A0 Region 2: Memory at fb6c0000 (64-bit, non-prefetchable) =
[disabled]
>> [size=3D128K]
>> =A0 =A0 =A0 =A0 Region 4: I/O ports at 9000 [disabled] [size=3D256]
>> =A0 =A0 =A0 =A0 Expansion ROM at fb6a0000 [disabled] [size=3D128K]
>> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
>> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFunc =
0, Latency L0s <4us, L1
>> unlimited
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnInd=
- PwrInd- RBE+ FLReset-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- Non-=
Fatal- Fatal-
>> Unsupported-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- PhantFu=
nc- AuxPwr- NoSnoop+
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, Ma=
xReadReq 512 bytes
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- Un=
suppReq+
>> AuxPwr- TransPend-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #8, Speed 2.5GT/s, Width x1=
6, ASPM L0s L1, Latency L0
>> <64ns, L1 <1us
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLActR=
ep- BwNot-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Disa=
bled- Retrain- CommClk-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- AutWi=
dDis- BWInt- AutBWInt-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrErr-=
 Train-
>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask- 6=
4bit+
>> Queue=3D0/0 Enable-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
>> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
>> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
>> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
>>
>>
>> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 0b2a
>> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASno=
op-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast =
>TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
>> =A0 =A0 =A0 =A0 Region 0: Memory at 90000000 (64-bit, prefetchable) [dis=
abled]
>> [size=3D256M]
>> =A0 =A0 =A0 =A0 Region 2: Memory at fb7c0000 (64-bit, non-prefetchable) =
[disabled]
>> [size=3D128K]
>> =A0 =A0 =A0 =A0 Region 4: I/O ports at a000 [disabled] [size=3D256]
>> =A0 =A0 =A0 =A0 Expansion ROM at fb7a0000 [disabled] [size=3D128K]
>> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
>> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFunc =
0, Latency L0s <4us, L1
>> unlimited
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnInd=
- PwrInd- RBE+ FLReset-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- Non-=
Fatal- Fatal-
>> Unsupported-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- PhantFu=
nc- AuxPwr- NoSnoop+
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, Ma=
xReadReq 512 bytes
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- Un=
suppReq+
>> AuxPwr- TransPend-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #4, Speed 2.5GT/s, Width x1=
6, ASPM L0s L1, Latency L0
>> <64ns, L1 <1us
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLActR=
ep- BwNot-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Disa=
bled- Retrain- CommClk-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- AutWi=
dDis- BWInt- AutBWInt-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrErr-=
 Train-
>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask- 6=
4bit+
>> Queue=3D0/0 Enable-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
>> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
>> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
>> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
>>
>> Matt
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:27:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuQP-00041p-VQ; Tue, 21 Feb 2012 18:26:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.hook@otoy.com>) id 1RzuQO-00041j-DP
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:26:52 +0000
Received: from [85.158.139.83:27702] by server-2.bemta-5.messagelabs.com id
	5D/6E-20263-BE1E34F4; Tue, 21 Feb 2012 18:26:51 +0000
X-Env-Sender: matthew.hook@otoy.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329848810!15993080!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9259 invoked from network); 21 Feb 2012 18:26:50 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:26:50 -0000
Received: by wgbdr13 with SMTP id dr13so5290395wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 21 Feb 2012 10:26:50 -0800 (PST)
Received-SPF: pass (google.com: domain of matthew.hook@otoy.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of matthew.hook@otoy.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=matthew.hook@otoy.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr36725916wia.3.1329848810350 (num_hops
	= 1); Tue, 21 Feb 2012 10:26:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr30643580wia.3.1329848810185; Tue,
	21 Feb 2012 10:26:50 -0800 (PST)
Received: by 10.227.142.14 with HTTP; Tue, 21 Feb 2012 10:26:50 -0800 (PST)
In-Reply-To: <B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
References: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
	<B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 21 Feb 2012 10:26:50 -0800
Message-ID: <CAMrHX2Wmci7n5h1NsseiRHr3-TZ_JbY_6aKJFvHTaw4wOxGqHg@mail.gmail.com>
From: Matthew Hook <matthew.hook@otoy.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Gm-Message-State: ALoCoQmgoWd+iBGY9UrmXTHR+vyQWBNt8BUMcy1qzCXYY1quTrWs46avq0UiCj9zu/HhM2ITO/Wl
Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks Xiantao,

I am using a Dual Xeon Tyan server here and VT-d is enabled.  I was
hoping someone might spot something special in the PCI listing for the
device that might explain why I haven't been able to get the second
GPU to start.
One difference between the primary and secondary GPU is that the
second GPU on the card does not have any VGA output capability.
However, we're not needing VGA output as we remote in to the guest.
This limitation hasn't stopped us from getting VMWare to successfully
dedicate the second GPU to it's on virtual machine.

Looking at the xen-unstable source tree I do see some significant
changes to VGA passthrough so I may try this and see if I have any
success.

Matt

On 20 February 2012 22:54, Zhang, Xiantao <xiantao.zhang@intel.com> wrote:
> If the card has two =A0full-fledged =A0PCI-e graphics functions, I think =
you can follow the link(http://wiki.xen.org/wiki/Xen_VGA_Passthrough) to do=
 your passthru work. It depends on Intel's VT-d or AMD's IOMMU technology, =
so please make sure all required components are ready in your system. =A0 I=
 think Xen's mailing list archive also has some detailed discussions about =
how to passthru one graphics device to the guest and what's difference comp=
ared with general PCIe device assignment.
> Xiantao
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Matthew Hook
>> Sent: Tuesday, February 21, 2012 12:59 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
>>
>> Is it possible in Xen that with a dual GPU graphics card which appears a=
s two
>> separately addressable PCI devices to pass each GPU to a separate guest?
>> Although I didn't think this was initially possible, VMWare supports it.
>> It's useful under xen for increasing virtual server density when providi=
ng
>> virtual desktops or similar.
>> Although not many Dual GPU cards are on the market at the moment, it
>> seems likely that Dual or Quad GPU cards will become the norm in the near
>> future.
>>
>> For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
>> I have successfully managed to passthru one of the GPU's on the card with
>> success. =A0However I get a BSOD on the second one.
>>
>> I'm wondering if compiling in the VGA BIOS may help?
>> If so, where is a good resource on how I could do that?
>>
>>
>> Cards show in lspci as follows:
>>
>> 12:00.0 Display controller: ATI Technologies Inc Device 671d
>> 12:00.1 Audio device: ATI Technologies Inc Device aa80
>> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
>> 13:00.1 Audio device: ATI Technologies Inc Device aa80
>>
>>
>> ATI Technologies Inc Device aa80
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0+-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-0=
4.0-[0000:10-13]----00.0-
>> [0000:11-13]--+-04.0-[0000:13]--+-00.0
>> =A0ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies
>> Inc Device aa80
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \-08.0-[0000:12]--+-=
00.0 =A0ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies Inc Device aa80
>>
>>
>> More details on the devices themselves.
>>
>> 12:00.0 Display controller: ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 1b2a
>> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASno=
op-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast =
>TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
>> =A0 =A0 =A0 =A0 Region 0: Memory at 80000000 (64-bit, prefetchable) [dis=
abled]
>> [size=3D256M]
>> =A0 =A0 =A0 =A0 Region 2: Memory at fb6c0000 (64-bit, non-prefetchable) =
[disabled]
>> [size=3D128K]
>> =A0 =A0 =A0 =A0 Region 4: I/O ports at 9000 [disabled] [size=3D256]
>> =A0 =A0 =A0 =A0 Expansion ROM at fb6a0000 [disabled] [size=3D128K]
>> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
>> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFunc =
0, Latency L0s <4us, L1
>> unlimited
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnInd=
- PwrInd- RBE+ FLReset-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- Non-=
Fatal- Fatal-
>> Unsupported-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- PhantFu=
nc- AuxPwr- NoSnoop+
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, Ma=
xReadReq 512 bytes
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- Un=
suppReq+
>> AuxPwr- TransPend-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #8, Speed 2.5GT/s, Width x1=
6, ASPM L0s L1, Latency L0
>> <64ns, L1 <1us
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLActR=
ep- BwNot-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Disa=
bled- Retrain- CommClk-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- AutWi=
dDis- BWInt- AutBWInt-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrErr-=
 Train-
>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask- 6=
4bit+
>> Queue=3D0/0 Enable-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
>> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
>> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
>> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
>>
>>
>> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
>> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 0b2a
>> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASno=
op-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast =
>TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
>> =A0 =A0 =A0 =A0 Region 0: Memory at 90000000 (64-bit, prefetchable) [dis=
abled]
>> [size=3D256M]
>> =A0 =A0 =A0 =A0 Region 2: Memory at fb7c0000 (64-bit, non-prefetchable) =
[disabled]
>> [size=3D128K]
>> =A0 =A0 =A0 =A0 Region 4: I/O ports at a000 [disabled] [size=3D256]
>> =A0 =A0 =A0 =A0 Expansion ROM at fb7a0000 [disabled] [size=3D128K]
>> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
>> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFunc =
0, Latency L0s <4us, L1
>> unlimited
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnInd=
- PwrInd- RBE+ FLReset-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- Non-=
Fatal- Fatal-
>> Unsupported-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- PhantFu=
nc- AuxPwr- NoSnoop+
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, Ma=
xReadReq 512 bytes
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- Un=
suppReq+
>> AuxPwr- TransPend-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #4, Speed 2.5GT/s, Width x1=
6, ASPM L0s L1, Latency L0
>> <64ns, L1 <1us
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLActR=
ep- BwNot-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Disa=
bled- Retrain- CommClk-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- AutWi=
dDis- BWInt- AutBWInt-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrErr-=
 Train-
>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask- 6=
4bit+
>> Queue=3D0/0 Enable-
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
>> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
>> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
>> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
>>
>> Matt
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuUE-0004F6-Ps; Tue, 21 Feb 2012 18:30:50 +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 1RzuUC-0004Ex-L6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:30:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329848911!49641834!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26614 invoked from network); 21 Feb 2012 18:28:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 18:28:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329849047; l=386;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=FrCeIqfBkLzouTL4ThBp6uzysmc=;
	b=cMR9ss24KK3Q6H/1kTQIR2pJyeNwzskc8HjWNA8plv4SbaDVQYIO+S6YJnAiKQD2ssP
	NYym7V6VPPTVrEMtR7iwJHOSVlvONKNLUqdM1iWsCG38axCoV22KSyVgTXp7DabnNfNw0
	LmI+dmKuPnOZX/LlbNWdLyHwBVWkejzmrms=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (klopstock mo53) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2017aco1LGLKvH ;
	Tue, 21 Feb 2012 19:30:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 83B0C18638; Tue, 21 Feb 2012 19:30:42 +0100 (CET)
Date: Tue, 21 Feb 2012 19:30:42 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120221183042.GA24861@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<20291.57670.186303.970388@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20291.57670.186303.970388@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Jackson wrote:

> This is indeed mysterious.  I haven't managed to reproduce it either.
> 
> I tried the patch below, with make -j1000, and everything worked the
> way it should do.

Is this with make 3.82?

I think its time to ask on a make mailing list for advice. The NEWS file
for 3.82 did not contain any (obvious related) incompatible change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:31:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuUE-0004F6-Ps; Tue, 21 Feb 2012 18:30:50 +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 1RzuUC-0004Ex-L6
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:30:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329848911!49641834!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNTgwMjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26614 invoked from network); 21 Feb 2012 18:28:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 18:28:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329849047; l=386;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=FrCeIqfBkLzouTL4ThBp6uzysmc=;
	b=cMR9ss24KK3Q6H/1kTQIR2pJyeNwzskc8HjWNA8plv4SbaDVQYIO+S6YJnAiKQD2ssP
	NYym7V6VPPTVrEMtR7iwJHOSVlvONKNLUqdM1iWsCG38axCoV22KSyVgTXp7DabnNfNw0
	LmI+dmKuPnOZX/LlbNWdLyHwBVWkejzmrms=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (klopstock mo53) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2017aco1LGLKvH ;
	Tue, 21 Feb 2012 19:30:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 83B0C18638; Tue, 21 Feb 2012 19:30:42 +0100 (CET)
Date: Tue, 21 Feb 2012 19:30:42 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120221183042.GA24861@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<20291.57670.186303.970388@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20291.57670.186303.970388@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Jackson wrote:

> This is indeed mysterious.  I haven't managed to reproduce it either.
> 
> I tried the patch below, with make -j1000, and everything worked the
> way it should do.

Is this with make 3.82?

I think its time to ask on a make mailing list for advice. The NEWS file
for 3.82 did not contain any (obvious related) incompatible change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:33:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:33:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuWP-0004Mb-Ds; Tue, 21 Feb 2012 18:33:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzuWO-0004MS-0n
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:33:04 +0000
Received: from [85.158.139.83:30089] by server-10.bemta-5.messagelabs.com id
	4A/25-07861-F53E34F4; Tue, 21 Feb 2012 18:33:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329849182!16037576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11027 invoked from network); 21 Feb 2012 18:33:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:33:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10852154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:33:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:33:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzuWM-0003iF-AJ; Tue, 21 Feb 2012 18:33:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzuWM-0004I8-9R;
	Tue, 21 Feb 2012 18:33:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.58206.279883.482278@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:33:02 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120221183042.GA24861@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<20291.57670.186303.970388@mariner.uk.xensource.com>
	<20120221183042.GA24861@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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

Olaf Hering writes ("Re: [Xen-devel] libxenstore.so Makefile dependency issue"):
> Is this with make 3.82?
> 
> I think its time to ask on a make mailing list for advice. The NEWS file
> for 3.82 did not contain any (obvious related) incompatible change.

3.81.

You could try the patch from my last mail which I think should enable
to you repro the bug every time.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:33:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18:33:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzuWP-0004Mb-Ds; Tue, 21 Feb 2012 18:33:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzuWO-0004MS-0n
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:33:04 +0000
Received: from [85.158.139.83:30089] by server-10.bemta-5.messagelabs.com id
	4A/25-07861-F53E34F4; Tue, 21 Feb 2012 18:33:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329849182!16037576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11027 invoked from network); 21 Feb 2012 18:33:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:33:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10852154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:33:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:33:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzuWM-0003iF-AJ; Tue, 21 Feb 2012 18:33:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzuWM-0004I8-9R;
	Tue, 21 Feb 2012 18:33:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.58206.279883.482278@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 18:33:02 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120221183042.GA24861@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<20291.57670.186303.970388@mariner.uk.xensource.com>
	<20120221183042.GA24861@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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

Olaf Hering writes ("Re: [Xen-devel] libxenstore.so Makefile dependency issue"):
> Is this with make 3.82?
> 
> I think its time to ask on a make mailing list for advice. The NEWS file
> for 3.82 did not contain any (obvious related) incompatible change.

3.81.

You could try the patch from my last mail which I think should enable
to you repro the bug every time.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:38:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1Rzubq-0004af-6t; Tue, 21 Feb 2012 18:38:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzubo-0004aV-AY
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 18:38:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329849478!53374010!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19345 invoked from network); 21 Feb 2012 18:37:58 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:37:58 -0000
Received: by wgbdy1 with SMTP id dy1so4432403wgb.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 10:38:39 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr35306018wib.3.1329849519132
	(num_hops = 1); Tue, 21 Feb 2012 10:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=08B3lWCvAE2dhaUU6cFnVk12PYXfcqFhdVam7JX79yQ=;
	b=vTmFt4ImWaQBsx66m5UwYwk1FH8Yxh1oj94mQ+cJqKxeVMmWkWrRYUf/0zAHFgmEzG
	IfcYBng6yMNyvAjWE74YZucfDkFOBXiEbP2lcwvjfIUwpattlyD5FR4mNWFdSc1F8zbw
	M0nj4yhAu1VdrIiL1slSPdhv5I8nSflXU6cNs=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr29436563wib.3.1329849519069; Tue,
	21 Feb 2012 10:38:39 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 10:38:39 -0800 (PST)
In-Reply-To: <20291.53332.751695.368872@mariner.uk.xensource.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20291.53332.751695.368872@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 19:38:39 +0100
X-Google-Sender-Auth: Uu8Hvb2ZTUxQaY4txRiAQLDrZYA
Message-ID: <CAPLaKK6N=OZkY9Bfj87sMqu6iti+46gx5fVZwuYMhsxy875C7w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
	checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY4XSBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJl
cGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVjayIpOgo+PiBBZGRlZCBhdXRvdG9vbHMg
bWFnaWMgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCj4+IGNo
ZWNrcyBoYXZlIGJlZW4gcG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9u
ZXMgaGF2ZQo+PiBiZWVuIGFkZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcg
YXV0b3NjYW4pLiBUd28gZmlsZXMgYXJlCj4+IGNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVj
dXRpbmcgY29uZmlndXJlIHNjcmlwdCwgY29uZmlnL1Rvb2xzLm1rCj4+IGFuZCBjb25maWcuaC4K
Pgo+IFRoYW5rcywgSSBoYXZlIG5vdyBtYW5hZ2VkIHRvIHN1Y2Nlc3NmdWx5IHRlc3QgdGhpcy4g
wqBJdCdzIGxvb2tpbmcKPiBnb29kLgo+Cj4gSSBoYXZlIG1hZGUgYSBjaGFuZ2UgdG8gdGhlIHRl
c3Qgc3lzdGVtIHRvIGRlYWwgd2l0aCBpdCAoYXMgb3RoZXJ3aXNlCj4gb2YgY291cnNlIGFsbCB0
aGUgYnVpbGRzIHdpbGwgZmFpbCksIGFuZCBJIHdpbGwgYXBwbHkgeW91ciBhdXRvY29uZgo+IHBh
dGNoIHdoZW4gSSBnZXQgYSBwdXNoIG9uIHRoZSB0ZXN0IHN5c3RlbS4KClRoYXRzIGdvb2QsIEkn
bSBoYXBweSB0aGF0IHRoaXMgaXMgZmluYWxseSBsb29raW5nIG9rLgoKPiBJJ2xsIGFsc28gYXBw
bHkgdGhlIC5naXRpZ25vcmUgcGF0Y2ggYmVsb3cuCgpJc24ndCB0aGF0IGFscmVhZHkgb24gbXkg
cGF0Y2g/Cgo+IElhbi4KPgo+IGNvbW1pdCA2ZTk4OTNmNjY1YTNmNmZjNmVlZjQ1ZmM1M2NmNDQ2
ZjhjMDg1NmM0Cj4gQXV0aG9yOiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNv
bT4KPiBEYXRlOiDCoCBUdWUgRmViIDIxIDE2OjEyOjQ2IDIwMTIgKzAwMDAKPgo+IMKgIMKgLmdp
dGlnbm9yZTogYWRkIGF1dG9jb25mLXJlbGF0ZWQgZmlsZXMKPgo+IMKgIMKgU2lnbmVkLW9mZi1i
eTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4KPiBkaWZmIC0tZ2l0
IGEvLmdpdGlnbm9yZSBiLy5naXRpZ25vcmUKPiBpbmRleCBkMWE1MDNiLi44ODEwYjM1IDEwMDY0
NAo+IC0tLSBhLy5naXRpZ25vcmUKPiArKysgYi8uZ2l0aWdub3JlCj4gQEAgLTEwNSw2ICsxMDUs
MTIgQEAgc3R1YmRvbS9sd2lwLwo+IMKgc3R1YmRvbS9pb2VtdS8KPiDCoHN0dWJkb20vc3R1YmRv
bXBhdGguc2gKPiDCoHRvb2xzLyovYnVpbGQvbGliKi8qLnB5Cj4gK3Rvb2xzL2F1dG9tNHRlLmNh
Y2hlCj4gK3Rvb2xzL2NvbmZpZy5oCj4gK3Rvb2xzL2NvbmZpZy5sb2cKPiArdG9vbHMvY29uZmln
LnN0YXR1cwo+ICt0b29scy9jb25maWcuY2FjaGUKPiArY29uZmlnL1Rvb2xzLm1rCj4gwqB0b29s
cy9ibGt0YXAyL2RhZW1vbi9ibGt0YXBjdHJsCj4gwqB0b29scy9ibGt0YXAyL2RyaXZlcnMvaW1n
MnFjb3cKPiDCoHRvb2xzL2Jsa3RhcDIvZHJpdmVycy9sb2NrLXV0aWwKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:38:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1Rzubq-0004af-6t; Tue, 21 Feb 2012 18:38:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rzubo-0004aV-AY
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 18:38:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329849478!53374010!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19345 invoked from network); 21 Feb 2012 18:37:58 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:37:58 -0000
Received: by wgbdy1 with SMTP id dy1so4432403wgb.32
	for <xen-devel@lists.xen.org>; Tue, 21 Feb 2012 10:38:39 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr35306018wib.3.1329849519132
	(num_hops = 1); Tue, 21 Feb 2012 10:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=08B3lWCvAE2dhaUU6cFnVk12PYXfcqFhdVam7JX79yQ=;
	b=vTmFt4ImWaQBsx66m5UwYwk1FH8Yxh1oj94mQ+cJqKxeVMmWkWrRYUf/0zAHFgmEzG
	IfcYBng6yMNyvAjWE74YZucfDkFOBXiEbP2lcwvjfIUwpattlyD5FR4mNWFdSc1F8zbw
	M0nj4yhAu1VdrIiL1slSPdhv5I8nSflXU6cNs=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr29436563wib.3.1329849519069; Tue,
	21 Feb 2012 10:38:39 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Tue, 21 Feb 2012 10:38:39 -0800 (PST)
In-Reply-To: <20291.53332.751695.368872@mariner.uk.xensource.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20291.53332.751695.368872@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 19:38:39 +0100
X-Google-Sender-Auth: Uu8Hvb2ZTUxQaY4txRiAQLDrZYA
Message-ID: <CAPLaKK6N=OZkY9Bfj87sMqu6iti+46gx5fVZwuYMhsxy875C7w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
	checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIxIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIHY4XSBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJl
cGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVjayIpOgo+PiBBZGRlZCBhdXRvdG9vbHMg
bWFnaWMgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCj4+IGNo
ZWNrcyBoYXZlIGJlZW4gcG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9u
ZXMgaGF2ZQo+PiBiZWVuIGFkZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcg
YXV0b3NjYW4pLiBUd28gZmlsZXMgYXJlCj4+IGNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVj
dXRpbmcgY29uZmlndXJlIHNjcmlwdCwgY29uZmlnL1Rvb2xzLm1rCj4+IGFuZCBjb25maWcuaC4K
Pgo+IFRoYW5rcywgSSBoYXZlIG5vdyBtYW5hZ2VkIHRvIHN1Y2Nlc3NmdWx5IHRlc3QgdGhpcy4g
wqBJdCdzIGxvb2tpbmcKPiBnb29kLgo+Cj4gSSBoYXZlIG1hZGUgYSBjaGFuZ2UgdG8gdGhlIHRl
c3Qgc3lzdGVtIHRvIGRlYWwgd2l0aCBpdCAoYXMgb3RoZXJ3aXNlCj4gb2YgY291cnNlIGFsbCB0
aGUgYnVpbGRzIHdpbGwgZmFpbCksIGFuZCBJIHdpbGwgYXBwbHkgeW91ciBhdXRvY29uZgo+IHBh
dGNoIHdoZW4gSSBnZXQgYSBwdXNoIG9uIHRoZSB0ZXN0IHN5c3RlbS4KClRoYXRzIGdvb2QsIEkn
bSBoYXBweSB0aGF0IHRoaXMgaXMgZmluYWxseSBsb29raW5nIG9rLgoKPiBJJ2xsIGFsc28gYXBw
bHkgdGhlIC5naXRpZ25vcmUgcGF0Y2ggYmVsb3cuCgpJc24ndCB0aGF0IGFscmVhZHkgb24gbXkg
cGF0Y2g/Cgo+IElhbi4KPgo+IGNvbW1pdCA2ZTk4OTNmNjY1YTNmNmZjNmVlZjQ1ZmM1M2NmNDQ2
ZjhjMDg1NmM0Cj4gQXV0aG9yOiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNv
bT4KPiBEYXRlOiDCoCBUdWUgRmViIDIxIDE2OjEyOjQ2IDIwMTIgKzAwMDAKPgo+IMKgIMKgLmdp
dGlnbm9yZTogYWRkIGF1dG9jb25mLXJlbGF0ZWQgZmlsZXMKPgo+IMKgIMKgU2lnbmVkLW9mZi1i
eTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4KPiBkaWZmIC0tZ2l0
IGEvLmdpdGlnbm9yZSBiLy5naXRpZ25vcmUKPiBpbmRleCBkMWE1MDNiLi44ODEwYjM1IDEwMDY0
NAo+IC0tLSBhLy5naXRpZ25vcmUKPiArKysgYi8uZ2l0aWdub3JlCj4gQEAgLTEwNSw2ICsxMDUs
MTIgQEAgc3R1YmRvbS9sd2lwLwo+IMKgc3R1YmRvbS9pb2VtdS8KPiDCoHN0dWJkb20vc3R1YmRv
bXBhdGguc2gKPiDCoHRvb2xzLyovYnVpbGQvbGliKi8qLnB5Cj4gK3Rvb2xzL2F1dG9tNHRlLmNh
Y2hlCj4gK3Rvb2xzL2NvbmZpZy5oCj4gK3Rvb2xzL2NvbmZpZy5sb2cKPiArdG9vbHMvY29uZmln
LnN0YXR1cwo+ICt0b29scy9jb25maWcuY2FjaGUKPiArY29uZmlnL1Rvb2xzLm1rCj4gwqB0b29s
cy9ibGt0YXAyL2RhZW1vbi9ibGt0YXBjdHJsCj4gwqB0b29scy9ibGt0YXAyL2RyaXZlcnMvaW1n
MnFjb3cKPiDCoHRvb2xzL2Jsa3RhcDIvZHJpdmVycy9sb2NrLXV0aWwKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzutR-00058b-3y; Tue, 21 Feb 2012 18: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.Jackson@eu.citrix.com>) id 1RzutO-00058W-Mt
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:56:51 +0000
Received: from [85.158.139.83:42897] by server-9.bemta-5.messagelabs.com id
	ED/9A-30171-1F8E34F4; Tue, 21 Feb 2012 18:56:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329850606!13322357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25471 invoked from network); 21 Feb 2012 18:56:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:56:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10852641"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:56:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:56:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzutF-0003sr-TH;
	Tue, 21 Feb 2012 18:56:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzutF-0001fN-MT;
	Tue, 21 Feb 2012 18:56:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11998-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 18:56:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11998: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11998 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11998/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2    fail in 11994 REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11994
 build-amd64                   4 xen-build                   fail pass in 11994
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11994 pass in 11990

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  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-qemuu-rhel6hvm-intel  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-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-rhel6hvm-amd  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-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 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    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11994 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11994 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11994 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11994 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11994 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11994 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11994 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11994 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11994 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11994 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 18:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 18: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 1RzutR-00058b-3y; Tue, 21 Feb 2012 18: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.Jackson@eu.citrix.com>) id 1RzutO-00058W-Mt
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 18:56:51 +0000
Received: from [85.158.139.83:42897] by server-9.bemta-5.messagelabs.com id
	ED/9A-30171-1F8E34F4; Tue, 21 Feb 2012 18:56:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329850606!13322357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25471 invoked from network); 21 Feb 2012 18:56:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2012 18:56:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10852641"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 18:56:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 18:56:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzutF-0003sr-TH;
	Tue, 21 Feb 2012 18:56:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzutF-0001fN-MT;
	Tue, 21 Feb 2012 18:56:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11998-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 18:56:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11998: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 11998 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11998/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2    fail in 11994 REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 build-amd64-pvops             4 kernel-build                fail pass in 11994
 build-amd64                   4 xen-build                   fail pass in 11994
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11994 pass in 11990

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  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-qemuu-rhel6hvm-intel  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-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-rhel6hvm-amd  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-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 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    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail in 11994 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 11994 never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 11994 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11994 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11994 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11994 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11994 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11994 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11994 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11994 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11994 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11994 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11994 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 19:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 19: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 1Rzvb0-0005rT-0N; Tue, 21 Feb 2012 19:41:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzvay-0005rO-34
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 19:41:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329853305!14297836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17538 invoked from network); 21 Feb 2012 19:41:46 -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;
	21 Feb 2012 19:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10853166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 19:41:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 19:41:45 +0000
Message-ID: <1329853305.25232.109.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 19:41:45 +0000
In-Reply-To: <6792A135-57D1-4AE0-9690-F6B2B2E071BC@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<1329834420.3990.100.camel@zakaz.uk.xensource.com>
	<6792A135-57D1-4AE0-9690-F6B2B2E071BC@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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 Tue, 2012-02-21 at 18:14 +0000, Justin T. Gibbs wrote:
> On Feb 21, 2012, at 7:27 AM, Ian Campbell wrote:
> 
> > On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> >> o Document the XenBus nodes used in this protocol.
> >>  o Add a state diagram illustrating the roles and responsibilities
> >>    of both the front and backend during startup.
> >>  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
> >> 
> >> No functional changes.
> >> 
> >> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I've made some very minor comments below but I think getting the basic
> > documentation of this stuff in as a baseline to improve and correct over
> > time is more important than any of them.
> > 
> > Thanks again for doing this -- it is really valuable!
> 
> Thanks.
> 
> >> + * params
> >> + *      Values:         string
> >> + *
> >> + *      A free formatted string providing sufficient information for the
> >> + *      backend driver to open the backing device.  (e.g. the path to the
> >> + *      file or block device representing the backing store.)
> > 
> > The syntax and semantics of params is defined by the particular backend,
> > rather than being "free formatted" as such. I think it would be worth
> > saying that explicitly.
> > 
> > Ian.
> 
> Perhaps something like this?
> 
>  * params                                                               
>  *      Values:         string                                               
>  *                                                                   
>  *      Data used by the backend driver to locate and configure the backing
>  *      device.  The format and semantics of this data vary according to the 
>  *      backing device in use and are outside the scope of this specification.

Sounds good.

> 
> --
> Justin



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 19:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 19: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 1Rzvb0-0005rT-0N; Tue, 21 Feb 2012 19:41:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rzvay-0005rO-34
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 19:41:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329853305!14297836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17538 invoked from network); 21 Feb 2012 19:41:46 -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;
	21 Feb 2012 19:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10853166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 19:41:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 19:41:45 +0000
Message-ID: <1329853305.25232.109.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 19:41:45 +0000
In-Reply-To: <6792A135-57D1-4AE0-9690-F6B2B2E071BC@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<1329834420.3990.100.camel@zakaz.uk.xensource.com>
	<6792A135-57D1-4AE0-9690-F6B2B2E071BC@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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 Tue, 2012-02-21 at 18:14 +0000, Justin T. Gibbs wrote:
> On Feb 21, 2012, at 7:27 AM, Ian Campbell wrote:
> 
> > On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> >> o Document the XenBus nodes used in this protocol.
> >>  o Add a state diagram illustrating the roles and responsibilities
> >>    of both the front and backend during startup.
> >>  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.
> >> 
> >> No functional changes.
> >> 
> >> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I've made some very minor comments below but I think getting the basic
> > documentation of this stuff in as a baseline to improve and correct over
> > time is more important than any of them.
> > 
> > Thanks again for doing this -- it is really valuable!
> 
> Thanks.
> 
> >> + * params
> >> + *      Values:         string
> >> + *
> >> + *      A free formatted string providing sufficient information for the
> >> + *      backend driver to open the backing device.  (e.g. the path to the
> >> + *      file or block device representing the backing store.)
> > 
> > The syntax and semantics of params is defined by the particular backend,
> > rather than being "free formatted" as such. I think it would be worth
> > saying that explicitly.
> > 
> > Ian.
> 
> Perhaps something like this?
> 
>  * params                                                               
>  *      Values:         string                                               
>  *                                                                   
>  *      Data used by the backend driver to locate and configure the backing
>  *      device.  The format and semantics of this data vary according to the 
>  *      backing device in use and are outside the scope of this specification.

Sounds good.

> 
> --
> Justin



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 19:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 19: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 1RzvbI-0005sL-Dh; Tue, 21 Feb 2012 19:42:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzvbG-0005rt-9q
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 19:42:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329853323!14320727!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28871 invoked from network); 21 Feb 2012 19:42:04 -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;
	21 Feb 2012 19:42:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10853170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 19:42:03 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 19:42:03 +0000
Message-ID: <1329853322.25232.110.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 19:42:02 +0000
In-Reply-To: <62D2BC95-E6F0-4308-BEFC-415F69B93A68@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
	<1329835108.3990.108.camel@zakaz.uk.xensource.com>
	<62D2BC95-E6F0-4308-BEFC-415F69B93A68@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 18:03 +0000, Justin T. Gibbs wrote:
> On Feb 21, 2012, at 7:38 AM, Ian Campbell wrote:
> 
> > On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> >> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> >>      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
> >>      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
> >>      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
> >>      this value.
> >> 
> >> This extension first appeared in the FreeBSD Operating System.
> >> 
> >> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> >> 
> >> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> >> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> >> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
> >> @@ -145,6 +145,32 @@
> >>  *      The maximum supported size of the request ring buffer in units of
> >>  *      machine pages.  The value must be a power of 2.
> >>  *
> >> + * max-requests         <uint32_t>
> >> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> >> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> >> + *
> >> + *      The maximum number of concurrent, logical requests that will be
> >> + *      issued by the backend.
> > 
> > by "issued" do you mean the maximum number that the backend is willing
> > to consume/have-in-flight at once? I guess that means issued to the
> > underlying storage? (backend doesn't issue requests to the frontend does
> > it? That's how I first read it, hence my question)
> > 
> > Ian.
> > 
> 
> I should have used the same language as in the other entries.  Does this
> make more sense?
> 
>  *      The maximum number of concurrent, logical requests supported by
>  *      the backend.

Makes sense, thanks.

Ian.

> 
> --
> Justin



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 19:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 19: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 1RzvbI-0005sL-Dh; Tue, 21 Feb 2012 19:42:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RzvbG-0005rt-9q
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 19:42:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329853323!14320727!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28871 invoked from network); 21 Feb 2012 19:42:04 -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;
	21 Feb 2012 19:42:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10853170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 19:42:03 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 21 Feb 2012 19:42:03 +0000
Message-ID: <1329853322.25232.110.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Date: Tue, 21 Feb 2012 19:42:02 +0000
In-Reply-To: <62D2BC95-E6F0-4308-BEFC-415F69B93A68@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
	<1329835108.3990.108.camel@zakaz.uk.xensource.com>
	<62D2BC95-E6F0-4308-BEFC-415F69B93A68@spectralogic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 4 v3] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 18:03 +0000, Justin T. Gibbs wrote:
> On Feb 21, 2012, at 7:38 AM, Ian Campbell wrote:
> 
> > On Mon, 2012-02-20 at 18:07 +0000, Justin T. Gibbs wrote:
> >> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> >>      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
> >>      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
> >>      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
> >>      this value.
> >> 
> >> This extension first appeared in the FreeBSD Operating System.
> >> 
> >> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> >> 
> >> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> >> --- a/xen/include/public/io/blkif.h	Mon Feb 20 11:02:53 2012 -0700
> >> +++ b/xen/include/public/io/blkif.h	Mon Feb 20 11:03:01 2012 -0700
> >> @@ -145,6 +145,32 @@
> >>  *      The maximum supported size of the request ring buffer in units of
> >>  *      machine pages.  The value must be a power of 2.
> >>  *
> >> + * max-requests         <uint32_t>
> >> + *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> >> + *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> >> + *
> >> + *      The maximum number of concurrent, logical requests that will be
> >> + *      issued by the backend.
> > 
> > by "issued" do you mean the maximum number that the backend is willing
> > to consume/have-in-flight at once? I guess that means issued to the
> > underlying storage? (backend doesn't issue requests to the frontend does
> > it? That's how I first read it, hence my question)
> > 
> > Ian.
> > 
> 
> I should have used the same language as in the other entries.  Does this
> make more sense?
> 
>  *      The maximum number of concurrent, logical requests supported by
>  *      the backend.

Makes sense, thanks.

Ian.

> 
> --
> Justin



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 20:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 20: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 1RzwB7-0006uP-Nc; Tue, 21 Feb 2012 20:19:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzwB6-0006u5-G9
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 20:19:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329855545!14915497!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20493 invoked from network); 21 Feb 2012 20:19: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;
	21 Feb 2012 20:19:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10854709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 20:19:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 20:19:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzwAy-0004Vm-UF; Tue, 21 Feb 2012 20:19:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzwAy-0004p7-SQ;
	Tue, 21 Feb 2012 20:19:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.64568.850112.78893@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 20:19:04 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6N=OZkY9Bfj87sMqu6iti+46gx5fVZwuYMhsxy875C7w@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20291.53332.751695.368872@mariner.uk.xensource.com>
	<CAPLaKK6N=OZkY9Bfj87sMqu6iti+46gx5fVZwuYMhsxy875C7w@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH v8] build: add autoconf to replace cu=
stom checks in tools/check"):
> 2012/2/21 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > I'll also apply the .gitignore patch below.
> =

> Isn't that already on my patch?

No, yours has the .hgignore.  If I (and my git) are not mistaken.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 20:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 20: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 1RzwB7-0006uP-Nc; Tue, 21 Feb 2012 20:19:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RzwB6-0006u5-G9
	for xen-devel@lists.xen.org; Tue, 21 Feb 2012 20:19:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329855545!14915497!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzg1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20493 invoked from network); 21 Feb 2012 20:19: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;
	21 Feb 2012 20:19:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="10854709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 20:19:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 20:19:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RzwAy-0004Vm-UF; Tue, 21 Feb 2012 20:19:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RzwAy-0004p7-SQ;
	Tue, 21 Feb 2012 20:19:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20291.64568.850112.78893@mariner.uk.xensource.com>
Date: Tue, 21 Feb 2012 20:19:04 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6N=OZkY9Bfj87sMqu6iti+46gx5fVZwuYMhsxy875C7w@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20291.53332.751695.368872@mariner.uk.xensource.com>
	<CAPLaKK6N=OZkY9Bfj87sMqu6iti+46gx5fVZwuYMhsxy875C7w@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH v8] build: add autoconf to replace cu=
stom checks in tools/check"):
> 2012/2/21 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > I'll also apply the .gitignore patch below.
> =

> Isn't that already on my patch?

No, yours has the .hgignore.  If I (and my git) are not mistaken.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 20:35:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 20:35:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzwQG-0007Es-7B; Tue, 21 Feb 2012 20:34:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joseph.cihula@intel.com>) id 1RzwQE-0007En-MT
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 20:34:50 +0000
X-Env-Sender: joseph.cihula@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329856436!55194106!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM1MDc1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26805 invoked from network); 21 Feb 2012 20:33:57 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	21 Feb 2012 20:33:57 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 21 Feb 2012 12:34:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="68796375"
Received: from orsmsx605.amr.corp.intel.com ([10.22.226.10])
	by AZSMGA002.ch.intel.com with ESMTP; 21 Feb 2012 12:34:47 -0800
Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by
	orsmsx605.amr.corp.intel.com (10.22.226.10) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 12:34:46 -0800
Received: from orsmsx101.amr.corp.intel.com ([169.254.8.3]) by
	ORSMSX105.amr.corp.intel.com ([169.254.4.233]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 12:34:46 -0800
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ross Philipson
	<Ross.Philipson@citrix.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwQMeKjMMBX2CPRpih3BdESm407wAd6VwAAApPlwAAA3afAAAF9pNw
Date: Tue, 21 Feb 2012 20:34:46 +0000
Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC382173FC@ORSMSX101.amr.corp.intel.com>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
	<1329837682.3990.114.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329837682.3990.114.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.22.254.139]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian
> Campbell
> Sent: Tuesday, February 21, 2012 7:21 AM
> 
> On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough
> > > support
> > >
> > > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > > Updates to the layout of the HVM parameter and information page
> > > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > > written to the bottom half of this page.
> > >
> > > We would like to eventually get rid of the HVM info page and would
> > > certainly like to avoid adding anything further there. Could this
> > > data not be supplied via xenstore? Certainly they could and should
> > > be for the ones controlled by the flags entry which you add.
> > >
> > > Ian.
> > >
> >
> > Ah I did not realize that. The original incarnation of this code came
> > from 2+ years ago. I have no objection to using xenstore but I did not
> > think xenstore was suitable for passing arbitrary blocks of binary
> > data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in
> > this assumption.
> 
> I think in principal binary data is supported, but its use is discouraged. docs/misc/xenstore.txt
> talks about it a bit.
> 
> For well defined entries it should be reasonable to have human readable content in xenstore which
> simply enable/disables the table and perhaps contains some configuration values as appropriate.
> 
> For adding arbitrary tables I'm less sure what the right answer is.
> Common header elements in human readable form, payload as hex encoded strings or something? Seems
> a bit icky though.
> 
> > I am not sure what other mechanisms could be employed. In other code I
> > use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime.
> > I use a little DMAish interface I built into qemu to push the SSDT to
> > hvmloader while it is building the ACPI tables. Something like this
> > could be used but I don't really want to get qemu involved in this
> > operation.
> 
> Yes, I think we should avoid that too.
> 
> > I guess a third option might be to have a facility to load extra
> > modules/files into the new domain at start time and specify their
> > gpa's in xenstore. They could then be discarded after the initial
> > domain setup is complete.
> 
> That might work. What do others around here think?
> 
> Ian.

In deciding which approach to use, you should keep in mind that eventually it will be desirable to measure the VM (i.e. into a virtual TPM).  So if the data is going to be processed by code that is TPM-aware, then any approach to getting it the data should allow for measurement.  But if the processing code is not TPM-aware and is measured by the domain builder code, then the data should be provided in a way that the domain builder can easily measure it.

Joe

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 20:35:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 20:35:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzwQG-0007Es-7B; Tue, 21 Feb 2012 20:34:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joseph.cihula@intel.com>) id 1RzwQE-0007En-MT
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 20:34:50 +0000
X-Env-Sender: joseph.cihula@intel.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329856436!55194106!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM1MDc1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26805 invoked from network); 21 Feb 2012 20:33:57 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-27.messagelabs.com with SMTP;
	21 Feb 2012 20:33:57 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 21 Feb 2012 12:34:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="68796375"
Received: from orsmsx605.amr.corp.intel.com ([10.22.226.10])
	by AZSMGA002.ch.intel.com with ESMTP; 21 Feb 2012 12:34:47 -0800
Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by
	orsmsx605.amr.corp.intel.com (10.22.226.10) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 21 Feb 2012 12:34:46 -0800
Received: from orsmsx101.amr.corp.intel.com ([169.254.8.3]) by
	ORSMSX105.amr.corp.intel.com ([169.254.4.233]) with mapi id
	14.01.0355.002; Tue, 21 Feb 2012 12:34:46 -0800
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ross Philipson
	<Ross.Philipson@citrix.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwQMeKjMMBX2CPRpih3BdESm407wAd6VwAAApPlwAAA3afAAAF9pNw
Date: Tue, 21 Feb 2012 20:34:46 +0000
Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC382173FC@ORSMSX101.amr.corp.intel.com>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
	<1329837682.3990.114.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329837682.3990.114.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.22.254.139]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian
> Campbell
> Sent: Tuesday, February 21, 2012 7:21 AM
> 
> On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough
> > > support
> > >
> > > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > > Updates to the layout of the HVM parameter and information page
> > > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > > written to the bottom half of this page.
> > >
> > > We would like to eventually get rid of the HVM info page and would
> > > certainly like to avoid adding anything further there. Could this
> > > data not be supplied via xenstore? Certainly they could and should
> > > be for the ones controlled by the flags entry which you add.
> > >
> > > Ian.
> > >
> >
> > Ah I did not realize that. The original incarnation of this code came
> > from 2+ years ago. I have no objection to using xenstore but I did not
> > think xenstore was suitable for passing arbitrary blocks of binary
> > data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in
> > this assumption.
> 
> I think in principal binary data is supported, but its use is discouraged. docs/misc/xenstore.txt
> talks about it a bit.
> 
> For well defined entries it should be reasonable to have human readable content in xenstore which
> simply enable/disables the table and perhaps contains some configuration values as appropriate.
> 
> For adding arbitrary tables I'm less sure what the right answer is.
> Common header elements in human readable form, payload as hex encoded strings or something? Seems
> a bit icky though.
> 
> > I am not sure what other mechanisms could be employed. In other code I
> > use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime.
> > I use a little DMAish interface I built into qemu to push the SSDT to
> > hvmloader while it is building the ACPI tables. Something like this
> > could be used but I don't really want to get qemu involved in this
> > operation.
> 
> Yes, I think we should avoid that too.
> 
> > I guess a third option might be to have a facility to load extra
> > modules/files into the new domain at start time and specify their
> > gpa's in xenstore. They could then be discarded after the initial
> > domain setup is complete.
> 
> That might work. What do others around here think?
> 
> Ian.

In deciding which approach to use, you should keep in mind that eventually it will be desirable to measure the VM (i.e. into a virtual TPM).  So if the data is going to be processed by code that is TPM-aware, then any approach to getting it the data should allow for measurement.  But if the processing code is not TPM-aware and is measured by the domain builder code, then the data should be provided in a way that the domain builder can easily measure it.

Joe

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 21:00:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 21:00:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzwo5-0007jh-GA; Tue, 21 Feb 2012 20:59:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1Rzwo4-0007jc-6P
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 20:59:28 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329857960!15829825!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10723 invoked from network); 21 Feb 2012 20:59:21 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 20:59:21 -0000
Received: from [192.168.6.189] (207-225-98-3.dia.static.qwest.net
	[207.225.98.3]) (authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LKxIbA032704
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 13:59:19 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120221141041.GC11950@phenom.dumpdata.com>
Date: Tue, 21 Feb 2012 13:59:15 -0700
Message-Id: <D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Tue, 21 Feb 2012 13:59:20 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
	documentation of the blkif 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Feb 21, 2012, at 7:10 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 20, 2012 at 11:07:23AM -0700, Justin T. Gibbs wrote:
>>  o Document the XenBus nodes used in this protocol.
>>  o Add a state diagram illustrating the roles and responsibilities
>>    of both the front and backend during startup.
>>  o Correct missed BLKIF_OP_TRIM =3D> BLKIF_OP_DISCARD conversion in a co=
mment.
>> =

>> No functional changes.
> =

> Some comments below.

=85

>> + *------------------------- Backend Device Properties -----------------=
--------
>> + *
>> + * discard-aligment
>> + *      Values:         <uint32_t>
>> + *      Default Value:  0
>> + *      Notes:          1, 2
>> + *
>> + *      The offset, in bytes from the beginning of the virtual block de=
vice,
>> + *      to the first, addressable, discard extent on the underlying dev=
ice.
> =

> You are also missing the rest of the information about it. Please include=
 the
> details that the previous comment had.

The strategy I have employed in all of this documentation is to
treat blkif.h as a formal spec.  This means that blkif needs to
describe how its terminology maps to industry standards (e.g. discard
means trim/unmap) and how these requests can be communicated between
front and back driver.  It should not, in my opinion, attempt to
document information that is managed in other specs (e.g. T10/T13)
and could easily become stale in blkif.h.  It also should avoid
stating information that someone reasonably proficient in writing
(storage) device drivers is expected to know (e.g. don't say you
support something that you don't).

With that in mind, I believe that all of the required information
about discard is still present in blkif.h, but perhaps presented
differently or moved to different sections.  Can you be more
specific about the information that you feel is missing here and
in the other places you noted below?

>> + *
>> + * discard-secure
>> + *      Values:         0/1 (boolean)
>> + *      Default Value:  0
>> + *
>> + *      A value of "1" indicates that the backend can process BLKIF_OP_=
DISCARD
>> + *      requests with the BLKIF_DISCARD_SECURE flag set.
> =

> =

> That is not very specific to what this does. It just says X will do Y.

Did you mean, "That is not very specific to what BLKIF_DISCARD_SECURE
does."?  BLKIF_DISCARD_SECURE is documented in the comment section
for BLKIF_OP_DISCARD.  The pertinent text is: "If  the BLKIF_DISCARD_SECURE
flag is set on the request, all copies of the discarded region on
the device must be rendered unrecoverable before the command returns."
Is there a compelling reason to document it here instead?

The comment block here mirrors the language of all the other feature
flags.  Do you believe they should be changed in some way too?

>> - * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
>> - * More information about trim/unmap operations at:
>> + * This operation is analogous to performing a trim (ATA) or unamp (SCS=
I),
> =

> unmap.

Good catch.

> =

>> + * command on a native device.
> =

> And you might want to mention what the previous comment did - that this is
> a hint to the backend.

The proposed text already does this:

    "Indicate to the backend device that a region of storage is no
     longer in use, and may be discarded at any time without impact
     to the client."

If the backend was required to discard the region, I would have
used "shall" or "must", not "may".  This is the typical language
convention of standards documents.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 21:00:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 21:00:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1Rzwo5-0007jh-GA; Tue, 21 Feb 2012 20:59:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1Rzwo4-0007jc-6P
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 20:59:28 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329857960!15829825!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10723 invoked from network); 21 Feb 2012 20:59:21 -0000
Received: from ns1.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 20:59:21 -0000
Received: from [192.168.6.189] (207-225-98-3.dia.static.qwest.net
	[207.225.98.3]) (authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1LKxIbA032704
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 21 Feb 2012 13:59:19 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120221141041.GC11950@phenom.dumpdata.com>
Date: Tue, 21 Feb 2012 13:59:15 -0700
Message-Id: <D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Tue, 21 Feb 2012 13:59:20 -0700 (MST)
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
	documentation of the blkif 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Feb 21, 2012, at 7:10 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 20, 2012 at 11:07:23AM -0700, Justin T. Gibbs wrote:
>>  o Document the XenBus nodes used in this protocol.
>>  o Add a state diagram illustrating the roles and responsibilities
>>    of both the front and backend during startup.
>>  o Correct missed BLKIF_OP_TRIM =3D> BLKIF_OP_DISCARD conversion in a co=
mment.
>> =

>> No functional changes.
> =

> Some comments below.

=85

>> + *------------------------- Backend Device Properties -----------------=
--------
>> + *
>> + * discard-aligment
>> + *      Values:         <uint32_t>
>> + *      Default Value:  0
>> + *      Notes:          1, 2
>> + *
>> + *      The offset, in bytes from the beginning of the virtual block de=
vice,
>> + *      to the first, addressable, discard extent on the underlying dev=
ice.
> =

> You are also missing the rest of the information about it. Please include=
 the
> details that the previous comment had.

The strategy I have employed in all of this documentation is to
treat blkif.h as a formal spec.  This means that blkif needs to
describe how its terminology maps to industry standards (e.g. discard
means trim/unmap) and how these requests can be communicated between
front and back driver.  It should not, in my opinion, attempt to
document information that is managed in other specs (e.g. T10/T13)
and could easily become stale in blkif.h.  It also should avoid
stating information that someone reasonably proficient in writing
(storage) device drivers is expected to know (e.g. don't say you
support something that you don't).

With that in mind, I believe that all of the required information
about discard is still present in blkif.h, but perhaps presented
differently or moved to different sections.  Can you be more
specific about the information that you feel is missing here and
in the other places you noted below?

>> + *
>> + * discard-secure
>> + *      Values:         0/1 (boolean)
>> + *      Default Value:  0
>> + *
>> + *      A value of "1" indicates that the backend can process BLKIF_OP_=
DISCARD
>> + *      requests with the BLKIF_DISCARD_SECURE flag set.
> =

> =

> That is not very specific to what this does. It just says X will do Y.

Did you mean, "That is not very specific to what BLKIF_DISCARD_SECURE
does."?  BLKIF_DISCARD_SECURE is documented in the comment section
for BLKIF_OP_DISCARD.  The pertinent text is: "If  the BLKIF_DISCARD_SECURE
flag is set on the request, all copies of the discarded region on
the device must be rendered unrecoverable before the command returns."
Is there a compelling reason to document it here instead?

The comment block here mirrors the language of all the other feature
flags.  Do you believe they should be changed in some way too?

>> - * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
>> - * More information about trim/unmap operations at:
>> + * This operation is analogous to performing a trim (ATA) or unamp (SCS=
I),
> =

> unmap.

Good catch.

> =

>> + * command on a native device.
> =

> And you might want to mention what the previous comment did - that this is
> a hint to the backend.

The proposed text already does this:

    "Indicate to the backend device that a region of storage is no
     longer in use, and may be discarded at any time without impact
     to the client."

If the backend was required to discard the region, I would have
used "shall" or "must", not "may".  This is the typical language
convention of standards documents.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 21:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 21:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzxR8-0008HX-Md; Tue, 21 Feb 2012 21:39:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzxR6-0008HP-JX
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 21:39:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329860380!14352182!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18268 invoked from network); 21 Feb 2012 21:39:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 21:39:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LLdcTR005321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 21:39:39 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
	q1LLdcDn012095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 21:39:38 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
	q1LLdbJh010493; Tue, 21 Feb 2012 15:39:37 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 13:39:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFA174047A; Tue, 21 Feb 2012 16:36:23 -0500 (EST)
Date: Tue, 21 Feb 2012 16:36:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221213623.GB28154@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F440F1C.0050,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBGZWIgMjEsIDIwMTIgYXQgMDE6NTk6MTVQTSAtMDcwMCwgSnVzdGluIFQuIEdpYmJz
IHdyb3RlOgo+IE9uIEZlYiAyMSwgMjAxMiwgYXQgNzoxMCBBTSwgS29ucmFkIFJ6ZXN6dXRlayBX
aWxrIHdyb3RlOgo+IAo+ID4gT24gTW9uLCBGZWIgMjAsIDIwMTIgYXQgMTE6MDc6MjNBTSAtMDcw
MCwgSnVzdGluIFQuIEdpYmJzIHdyb3RlOgo+ID4+ICBvIERvY3VtZW50IHRoZSBYZW5CdXMgbm9k
ZXMgdXNlZCBpbiB0aGlzIHByb3RvY29sLgo+ID4+ICBvIEFkZCBhIHN0YXRlIGRpYWdyYW0gaWxs
dXN0cmF0aW5nIHRoZSByb2xlcyBhbmQgcmVzcG9uc2liaWxpdGllcwo+ID4+ICAgIG9mIGJvdGgg
dGhlIGZyb250IGFuZCBiYWNrZW5kIGR1cmluZyBzdGFydHVwLgo+ID4+ICBvIENvcnJlY3QgbWlz
c2VkIEJMS0lGX09QX1RSSU0gPT4gQkxLSUZfT1BfRElTQ0FSRCBjb252ZXJzaW9uIGluIGEgY29t
bWVudC4KPiA+PiAKPiA+PiBObyBmdW5jdGlvbmFsIGNoYW5nZXMuCj4gPiAKPiA+IFNvbWUgY29t
bWVudHMgYmVsb3cuCj4gCj4g4oCmCj4gCj4gPj4gKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSBCYWNrZW5kIERldmljZSBQcm9wZXJ0aWVzIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+
PiArICoKPiA+PiArICogZGlzY2FyZC1hbGlnbWVudAo+ID4+ICsgKiAgICAgIFZhbHVlczogICAg
ICAgICA8dWludDMyX3Q+Cj4gPj4gKyAqICAgICAgRGVmYXVsdCBWYWx1ZTogIDAKPiA+PiArICog
ICAgICBOb3RlczogICAgICAgICAgMSwgMgo+ID4+ICsgKgo+ID4+ICsgKiAgICAgIFRoZSBvZmZz
ZXQsIGluIGJ5dGVzIGZyb20gdGhlIGJlZ2lubmluZyBvZiB0aGUgdmlydHVhbCBibG9jayBkZXZp
Y2UsCj4gPj4gKyAqICAgICAgdG8gdGhlIGZpcnN0LCBhZGRyZXNzYWJsZSwgZGlzY2FyZCBleHRl
bnQgb24gdGhlIHVuZGVybHlpbmcgZGV2aWNlLgo+ID4gCj4gPiBZb3UgYXJlIGFsc28gbWlzc2lu
ZyB0aGUgcmVzdCBvZiB0aGUgaW5mb3JtYXRpb24gYWJvdXQgaXQuIFBsZWFzZSBpbmNsdWRlIHRo
ZQo+ID4gZGV0YWlscyB0aGF0IHRoZSBwcmV2aW91cyBjb21tZW50IGhhZC4KPiAKPiBUaGUgc3Ry
YXRlZ3kgSSBoYXZlIGVtcGxveWVkIGluIGFsbCBvZiB0aGlzIGRvY3VtZW50YXRpb24gaXMgdG8K
PiB0cmVhdCBibGtpZi5oIGFzIGEgZm9ybWFsIHNwZWMuICBUaGlzIG1lYW5zIHRoYXQgYmxraWYg
bmVlZHMgdG8KCk9LLgo+IGRlc2NyaWJlIGhvdyBpdHMgdGVybWlub2xvZ3kgbWFwcyB0byBpbmR1
c3RyeSBzdGFuZGFyZHMgKGUuZy4gZGlzY2FyZAo+IG1lYW5zIHRyaW0vdW5tYXApIGFuZCBob3cg
dGhlc2UgcmVxdWVzdHMgY2FuIGJlIGNvbW11bmljYXRlZCBiZXR3ZWVuCj4gZnJvbnQgYW5kIGJh
Y2sgZHJpdmVyLiAgSXQgc2hvdWxkIG5vdCwgaW4gbXkgb3BpbmlvbiwgYXR0ZW1wdCB0bwo+IGRv
Y3VtZW50IGluZm9ybWF0aW9uIHRoYXQgaXMgbWFuYWdlZCBpbiBvdGhlciBzcGVjcyAoZS5nLiBU
MTAvVDEzKQo+IGFuZCBjb3VsZCBlYXNpbHkgYmVjb21lIHN0YWxlIGluIGJsa2lmLmguICBJdCBh
bHNvIHNob3VsZCBhdm9pZAo+IHN0YXRpbmcgaW5mb3JtYXRpb24gdGhhdCBzb21lb25lIHJlYXNv
bmFibHkgcHJvZmljaWVudCBpbiB3cml0aW5nCj4gKHN0b3JhZ2UpIGRldmljZSBkcml2ZXJzIGlz
IGV4cGVjdGVkIHRvIGtub3cgKGUuZy4gZG9uJ3Qgc2F5IHlvdQo+IHN1cHBvcnQgc29tZXRoaW5n
IHRoYXQgeW91IGRvbid0KS4KCkFuZCB0aGF0IGlzIHdoYXQgSSBoYXRlIGFib3V0IHNwZWNzLiBU
aGV5IGRvbid0IHByb3ZpZGUgZW5vdWdoIGRldGFpbHMKb24gdGhlIGNvcm5lciBjYXNlcyBvciB3
aGF0IGFuIGltcGxlbnRhdGlvbiBjb3VsZCBsb29rIGxpa2UuCgo+IAo+IFdpdGggdGhhdCBpbiBt
aW5kLCBJIGJlbGlldmUgdGhhdCBhbGwgb2YgdGhlIHJlcXVpcmVkIGluZm9ybWF0aW9uCj4gYWJv
dXQgZGlzY2FyZCBpcyBzdGlsbCBwcmVzZW50IGluIGJsa2lmLmgsIGJ1dCBwZXJoYXBzIHByZXNl
bnRlZAo+IGRpZmZlcmVudGx5IG9yIG1vdmVkIHRvIGRpZmZlcmVudCBzZWN0aW9ucy4gIENhbiB5
b3UgYmUgbW9yZQo+IHNwZWNpZmljIGFib3V0IHRoZSBpbmZvcm1hdGlvbiB0aGF0IHlvdSBmZWVs
IGlzIG1pc3NpbmcgaGVyZSBhbmQKPiBpbiB0aGUgb3RoZXIgcGxhY2VzIHlvdSBub3RlZCBiZWxv
dz8KClRoZSBvcmlnaW5hbCBzdGF0ZW1lbnQgYWJvdXQgaG93IHRoZSBiYWNrZW5kIHdvdWxkIGRl
dGVybWluZSBob3cKdG8gZXhwb3NlIHRoaXMgaW5mb3JtYXRpb24uCgo+IAo+ID4+ICsgKgo+ID4+
ICsgKiBkaXNjYXJkLXNlY3VyZQo+ID4+ICsgKiAgICAgIFZhbHVlczogICAgICAgICAwLzEgKGJv
b2xlYW4pCj4gPj4gKyAqICAgICAgRGVmYXVsdCBWYWx1ZTogIDAKPiA+PiArICoKPiA+PiArICog
ICAgICBBIHZhbHVlIG9mICIxIiBpbmRpY2F0ZXMgdGhhdCB0aGUgYmFja2VuZCBjYW4gcHJvY2Vz
cyBCTEtJRl9PUF9ESVNDQVJECj4gPj4gKyAqICAgICAgcmVxdWVzdHMgd2l0aCB0aGUgQkxLSUZf
RElTQ0FSRF9TRUNVUkUgZmxhZyBzZXQuCj4gPiAKPiA+IAo+ID4gVGhhdCBpcyBub3QgdmVyeSBz
cGVjaWZpYyB0byB3aGF0IHRoaXMgZG9lcy4gSXQganVzdCBzYXlzIFggd2lsbCBkbyBZLgo+IAo+
IERpZCB5b3UgbWVhbiwgIlRoYXQgaXMgbm90IHZlcnkgc3BlY2lmaWMgdG8gd2hhdCBCTEtJRl9E
SVNDQVJEX1NFQ1VSRQo+IGRvZXMuIj8gIEJMS0lGX0RJU0NBUkRfU0VDVVJFIGlzIGRvY3VtZW50
ZWQgaW4gdGhlIGNvbW1lbnQgc2VjdGlvbgo+IGZvciBCTEtJRl9PUF9ESVNDQVJELiAgVGhlIHBl
cnRpbmVudCB0ZXh0IGlzOiAiSWYgIHRoZSBCTEtJRl9ESVNDQVJEX1NFQ1VSRQo+IGZsYWcgaXMg
c2V0IG9uIHRoZSByZXF1ZXN0LCBhbGwgY29waWVzIG9mIHRoZSBkaXNjYXJkZWQgcmVnaW9uIG9u
Cj4gdGhlIGRldmljZSBtdXN0IGJlIHJlbmRlcmVkIHVucmVjb3ZlcmFibGUgYmVmb3JlIHRoZSBj
b21tYW5kIHJldHVybnMuIgo+IElzIHRoZXJlIGEgY29tcGVsbGluZyByZWFzb24gdG8gZG9jdW1l
bnQgaXQgaGVyZSBpbnN0ZWFkPwoKSSBqdXN0IHRoaW5rIHRoYXQgaGF2aW5nIG1vcmUgaW5mb3Jt
YXRpb24gKGV2ZW4gZHVwbGljYXRlKSBpcwpiZXR0ZXIuIEJ1dCB0aGF0IGhhcyB0aGUgZGlzYWR2
YW50YWdlIHRoYXQgaXQgY2FuIGdldCBvdXQgb2Ygc3luYy4KCj4gCj4gVGhlIGNvbW1lbnQgYmxv
Y2sgaGVyZSBtaXJyb3JzIHRoZSBsYW5ndWFnZSBvZiBhbGwgdGhlIG90aGVyIGZlYXR1cmUKPiBm
bGFncy4gIERvIHlvdSBiZWxpZXZlIHRoZXkgc2hvdWxkIGJlIGNoYW5nZWQgaW4gc29tZSB3YXkg
dG9vPwoKV2VsbCwgdGhlIGRlc2lyZSAobWluZSkgaXMgdG8gaW5jbHVkZSBhcyBtdWNoIGRldGFp
bHMgKG9yIGV2ZW4gbW9yZSkgaW4gdGhlCnNwZWMgc28gdGhhdCBpdCBjYW4gYmUgcmVhZCBhcyBh
IG5vdmVsIGlmIGRlc2lyZWQuCgpCdXQgSSB3aWxsIGRlZmVyIHRvIElhbiAtIGlmIGhlIGlzIE9L
IHRoZW4gdGhpcyBzaG91bGRuJ3QgZ2F0ZQp0aGUgYWNjZXB0YW5jZSBvZiB0aGlzIHBhdGNoIHdo
aWNoIGlzIGEgc3RlcCBmb3J3YXJkLgoKLi4gc25pcC4uCj4gPj4gKyAqIGNvbW1hbmQgb24gYSBu
YXRpdmUgZGV2aWNlLgo+ID4gCj4gPiBBbmQgeW91IG1pZ2h0IHdhbnQgdG8gbWVudGlvbiB3aGF0
IHRoZSBwcmV2aW91cyBjb21tZW50IGRpZCAtIHRoYXQgdGhpcyBpcwo+ID4gYSBoaW50IHRvIHRo
ZSBiYWNrZW5kLgo+IAo+IFRoZSBwcm9wb3NlZCB0ZXh0IGFscmVhZHkgZG9lcyB0aGlzOgo+IAo+
ICAgICAiSW5kaWNhdGUgdG8gdGhlIGJhY2tlbmQgZGV2aWNlIHRoYXQgYSByZWdpb24gb2Ygc3Rv
cmFnZSBpcyBubwo+ICAgICAgbG9uZ2VyIGluIHVzZSwgYW5kIG1heSBiZSBkaXNjYXJkZWQgYXQg
YW55IHRpbWUgd2l0aG91dCBpbXBhY3QKPiAgICAgIHRvIHRoZSBjbGllbnQuIgo+IAo+IElmIHRo
ZSBiYWNrZW5kIHdhcyByZXF1aXJlZCB0byBkaXNjYXJkIHRoZSByZWdpb24sIEkgd291bGQgaGF2
ZQo+IHVzZWQgInNoYWxsIiBvciAibXVzdCIsIG5vdCAibWF5Ii4gIFRoaXMgaXMgdGhlIHR5cGlj
YWwgbGFuZ3VhZ2UKPiBjb252ZW50aW9uIG9mIHN0YW5kYXJkcyBkb2N1bWVudHMuCgpGYWlyIGVu
b3VnaC4KCj4gCj4gLS0KPiBKdXN0aW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 21:40:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 21:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1RzxR8-0008HX-Md; Tue, 21 Feb 2012 21:39:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RzxR6-0008HP-JX
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 21:39:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329860380!14352182!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTU2NzA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18268 invoked from network); 21 Feb 2012 21:39:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2012 21:39:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1LLdcTR005321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 21 Feb 2012 21:39:39 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
	q1LLdcDn012095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2012 21:39:38 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
	q1LLdbJh010493; Tue, 21 Feb 2012 15:39:37 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 21 Feb 2012 13:39:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFA174047A; Tue, 21 Feb 2012 16:36:23 -0500 (EST)
Date: Tue, 21 Feb 2012 16:36:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Message-ID: <20120221213623.GB28154@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F440F1C.0050,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBGZWIgMjEsIDIwMTIgYXQgMDE6NTk6MTVQTSAtMDcwMCwgSnVzdGluIFQuIEdpYmJz
IHdyb3RlOgo+IE9uIEZlYiAyMSwgMjAxMiwgYXQgNzoxMCBBTSwgS29ucmFkIFJ6ZXN6dXRlayBX
aWxrIHdyb3RlOgo+IAo+ID4gT24gTW9uLCBGZWIgMjAsIDIwMTIgYXQgMTE6MDc6MjNBTSAtMDcw
MCwgSnVzdGluIFQuIEdpYmJzIHdyb3RlOgo+ID4+ICBvIERvY3VtZW50IHRoZSBYZW5CdXMgbm9k
ZXMgdXNlZCBpbiB0aGlzIHByb3RvY29sLgo+ID4+ICBvIEFkZCBhIHN0YXRlIGRpYWdyYW0gaWxs
dXN0cmF0aW5nIHRoZSByb2xlcyBhbmQgcmVzcG9uc2liaWxpdGllcwo+ID4+ICAgIG9mIGJvdGgg
dGhlIGZyb250IGFuZCBiYWNrZW5kIGR1cmluZyBzdGFydHVwLgo+ID4+ICBvIENvcnJlY3QgbWlz
c2VkIEJMS0lGX09QX1RSSU0gPT4gQkxLSUZfT1BfRElTQ0FSRCBjb252ZXJzaW9uIGluIGEgY29t
bWVudC4KPiA+PiAKPiA+PiBObyBmdW5jdGlvbmFsIGNoYW5nZXMuCj4gPiAKPiA+IFNvbWUgY29t
bWVudHMgYmVsb3cuCj4gCj4g4oCmCj4gCj4gPj4gKyAqLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSBCYWNrZW5kIERldmljZSBQcm9wZXJ0aWVzIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+
PiArICoKPiA+PiArICogZGlzY2FyZC1hbGlnbWVudAo+ID4+ICsgKiAgICAgIFZhbHVlczogICAg
ICAgICA8dWludDMyX3Q+Cj4gPj4gKyAqICAgICAgRGVmYXVsdCBWYWx1ZTogIDAKPiA+PiArICog
ICAgICBOb3RlczogICAgICAgICAgMSwgMgo+ID4+ICsgKgo+ID4+ICsgKiAgICAgIFRoZSBvZmZz
ZXQsIGluIGJ5dGVzIGZyb20gdGhlIGJlZ2lubmluZyBvZiB0aGUgdmlydHVhbCBibG9jayBkZXZp
Y2UsCj4gPj4gKyAqICAgICAgdG8gdGhlIGZpcnN0LCBhZGRyZXNzYWJsZSwgZGlzY2FyZCBleHRl
bnQgb24gdGhlIHVuZGVybHlpbmcgZGV2aWNlLgo+ID4gCj4gPiBZb3UgYXJlIGFsc28gbWlzc2lu
ZyB0aGUgcmVzdCBvZiB0aGUgaW5mb3JtYXRpb24gYWJvdXQgaXQuIFBsZWFzZSBpbmNsdWRlIHRo
ZQo+ID4gZGV0YWlscyB0aGF0IHRoZSBwcmV2aW91cyBjb21tZW50IGhhZC4KPiAKPiBUaGUgc3Ry
YXRlZ3kgSSBoYXZlIGVtcGxveWVkIGluIGFsbCBvZiB0aGlzIGRvY3VtZW50YXRpb24gaXMgdG8K
PiB0cmVhdCBibGtpZi5oIGFzIGEgZm9ybWFsIHNwZWMuICBUaGlzIG1lYW5zIHRoYXQgYmxraWYg
bmVlZHMgdG8KCk9LLgo+IGRlc2NyaWJlIGhvdyBpdHMgdGVybWlub2xvZ3kgbWFwcyB0byBpbmR1
c3RyeSBzdGFuZGFyZHMgKGUuZy4gZGlzY2FyZAo+IG1lYW5zIHRyaW0vdW5tYXApIGFuZCBob3cg
dGhlc2UgcmVxdWVzdHMgY2FuIGJlIGNvbW11bmljYXRlZCBiZXR3ZWVuCj4gZnJvbnQgYW5kIGJh
Y2sgZHJpdmVyLiAgSXQgc2hvdWxkIG5vdCwgaW4gbXkgb3BpbmlvbiwgYXR0ZW1wdCB0bwo+IGRv
Y3VtZW50IGluZm9ybWF0aW9uIHRoYXQgaXMgbWFuYWdlZCBpbiBvdGhlciBzcGVjcyAoZS5nLiBU
MTAvVDEzKQo+IGFuZCBjb3VsZCBlYXNpbHkgYmVjb21lIHN0YWxlIGluIGJsa2lmLmguICBJdCBh
bHNvIHNob3VsZCBhdm9pZAo+IHN0YXRpbmcgaW5mb3JtYXRpb24gdGhhdCBzb21lb25lIHJlYXNv
bmFibHkgcHJvZmljaWVudCBpbiB3cml0aW5nCj4gKHN0b3JhZ2UpIGRldmljZSBkcml2ZXJzIGlz
IGV4cGVjdGVkIHRvIGtub3cgKGUuZy4gZG9uJ3Qgc2F5IHlvdQo+IHN1cHBvcnQgc29tZXRoaW5n
IHRoYXQgeW91IGRvbid0KS4KCkFuZCB0aGF0IGlzIHdoYXQgSSBoYXRlIGFib3V0IHNwZWNzLiBU
aGV5IGRvbid0IHByb3ZpZGUgZW5vdWdoIGRldGFpbHMKb24gdGhlIGNvcm5lciBjYXNlcyBvciB3
aGF0IGFuIGltcGxlbnRhdGlvbiBjb3VsZCBsb29rIGxpa2UuCgo+IAo+IFdpdGggdGhhdCBpbiBt
aW5kLCBJIGJlbGlldmUgdGhhdCBhbGwgb2YgdGhlIHJlcXVpcmVkIGluZm9ybWF0aW9uCj4gYWJv
dXQgZGlzY2FyZCBpcyBzdGlsbCBwcmVzZW50IGluIGJsa2lmLmgsIGJ1dCBwZXJoYXBzIHByZXNl
bnRlZAo+IGRpZmZlcmVudGx5IG9yIG1vdmVkIHRvIGRpZmZlcmVudCBzZWN0aW9ucy4gIENhbiB5
b3UgYmUgbW9yZQo+IHNwZWNpZmljIGFib3V0IHRoZSBpbmZvcm1hdGlvbiB0aGF0IHlvdSBmZWVs
IGlzIG1pc3NpbmcgaGVyZSBhbmQKPiBpbiB0aGUgb3RoZXIgcGxhY2VzIHlvdSBub3RlZCBiZWxv
dz8KClRoZSBvcmlnaW5hbCBzdGF0ZW1lbnQgYWJvdXQgaG93IHRoZSBiYWNrZW5kIHdvdWxkIGRl
dGVybWluZSBob3cKdG8gZXhwb3NlIHRoaXMgaW5mb3JtYXRpb24uCgo+IAo+ID4+ICsgKgo+ID4+
ICsgKiBkaXNjYXJkLXNlY3VyZQo+ID4+ICsgKiAgICAgIFZhbHVlczogICAgICAgICAwLzEgKGJv
b2xlYW4pCj4gPj4gKyAqICAgICAgRGVmYXVsdCBWYWx1ZTogIDAKPiA+PiArICoKPiA+PiArICog
ICAgICBBIHZhbHVlIG9mICIxIiBpbmRpY2F0ZXMgdGhhdCB0aGUgYmFja2VuZCBjYW4gcHJvY2Vz
cyBCTEtJRl9PUF9ESVNDQVJECj4gPj4gKyAqICAgICAgcmVxdWVzdHMgd2l0aCB0aGUgQkxLSUZf
RElTQ0FSRF9TRUNVUkUgZmxhZyBzZXQuCj4gPiAKPiA+IAo+ID4gVGhhdCBpcyBub3QgdmVyeSBz
cGVjaWZpYyB0byB3aGF0IHRoaXMgZG9lcy4gSXQganVzdCBzYXlzIFggd2lsbCBkbyBZLgo+IAo+
IERpZCB5b3UgbWVhbiwgIlRoYXQgaXMgbm90IHZlcnkgc3BlY2lmaWMgdG8gd2hhdCBCTEtJRl9E
SVNDQVJEX1NFQ1VSRQo+IGRvZXMuIj8gIEJMS0lGX0RJU0NBUkRfU0VDVVJFIGlzIGRvY3VtZW50
ZWQgaW4gdGhlIGNvbW1lbnQgc2VjdGlvbgo+IGZvciBCTEtJRl9PUF9ESVNDQVJELiAgVGhlIHBl
cnRpbmVudCB0ZXh0IGlzOiAiSWYgIHRoZSBCTEtJRl9ESVNDQVJEX1NFQ1VSRQo+IGZsYWcgaXMg
c2V0IG9uIHRoZSByZXF1ZXN0LCBhbGwgY29waWVzIG9mIHRoZSBkaXNjYXJkZWQgcmVnaW9uIG9u
Cj4gdGhlIGRldmljZSBtdXN0IGJlIHJlbmRlcmVkIHVucmVjb3ZlcmFibGUgYmVmb3JlIHRoZSBj
b21tYW5kIHJldHVybnMuIgo+IElzIHRoZXJlIGEgY29tcGVsbGluZyByZWFzb24gdG8gZG9jdW1l
bnQgaXQgaGVyZSBpbnN0ZWFkPwoKSSBqdXN0IHRoaW5rIHRoYXQgaGF2aW5nIG1vcmUgaW5mb3Jt
YXRpb24gKGV2ZW4gZHVwbGljYXRlKSBpcwpiZXR0ZXIuIEJ1dCB0aGF0IGhhcyB0aGUgZGlzYWR2
YW50YWdlIHRoYXQgaXQgY2FuIGdldCBvdXQgb2Ygc3luYy4KCj4gCj4gVGhlIGNvbW1lbnQgYmxv
Y2sgaGVyZSBtaXJyb3JzIHRoZSBsYW5ndWFnZSBvZiBhbGwgdGhlIG90aGVyIGZlYXR1cmUKPiBm
bGFncy4gIERvIHlvdSBiZWxpZXZlIHRoZXkgc2hvdWxkIGJlIGNoYW5nZWQgaW4gc29tZSB3YXkg
dG9vPwoKV2VsbCwgdGhlIGRlc2lyZSAobWluZSkgaXMgdG8gaW5jbHVkZSBhcyBtdWNoIGRldGFp
bHMgKG9yIGV2ZW4gbW9yZSkgaW4gdGhlCnNwZWMgc28gdGhhdCBpdCBjYW4gYmUgcmVhZCBhcyBh
IG5vdmVsIGlmIGRlc2lyZWQuCgpCdXQgSSB3aWxsIGRlZmVyIHRvIElhbiAtIGlmIGhlIGlzIE9L
IHRoZW4gdGhpcyBzaG91bGRuJ3QgZ2F0ZQp0aGUgYWNjZXB0YW5jZSBvZiB0aGlzIHBhdGNoIHdo
aWNoIGlzIGEgc3RlcCBmb3J3YXJkLgoKLi4gc25pcC4uCj4gPj4gKyAqIGNvbW1hbmQgb24gYSBu
YXRpdmUgZGV2aWNlLgo+ID4gCj4gPiBBbmQgeW91IG1pZ2h0IHdhbnQgdG8gbWVudGlvbiB3aGF0
IHRoZSBwcmV2aW91cyBjb21tZW50IGRpZCAtIHRoYXQgdGhpcyBpcwo+ID4gYSBoaW50IHRvIHRo
ZSBiYWNrZW5kLgo+IAo+IFRoZSBwcm9wb3NlZCB0ZXh0IGFscmVhZHkgZG9lcyB0aGlzOgo+IAo+
ICAgICAiSW5kaWNhdGUgdG8gdGhlIGJhY2tlbmQgZGV2aWNlIHRoYXQgYSByZWdpb24gb2Ygc3Rv
cmFnZSBpcyBubwo+ICAgICAgbG9uZ2VyIGluIHVzZSwgYW5kIG1heSBiZSBkaXNjYXJkZWQgYXQg
YW55IHRpbWUgd2l0aG91dCBpbXBhY3QKPiAgICAgIHRvIHRoZSBjbGllbnQuIgo+IAo+IElmIHRo
ZSBiYWNrZW5kIHdhcyByZXF1aXJlZCB0byBkaXNjYXJkIHRoZSByZWdpb24sIEkgd291bGQgaGF2
ZQo+IHVzZWQgInNoYWxsIiBvciAibXVzdCIsIG5vdCAibWF5Ii4gIFRoaXMgaXMgdGhlIHR5cGlj
YWwgbGFuZ3VhZ2UKPiBjb252ZW50aW9uIG9mIHN0YW5kYXJkcyBkb2N1bWVudHMuCgpGYWlyIGVu
b3VnaC4KCj4gCj4gLS0KPiBKdXN0aW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 21 22:02:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 22: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 1Rzxmr-0000MV-St; Tue, 21 Feb 2012 22:02:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzxmq-0000MQ-SC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 22:02:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329861730!14922965!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32145 invoked from network); 21 Feb 2012 22:02:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 22:02:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329861729; l=562;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mts6OhV/o43Te6uxWZHyxUlDluw=;
	b=AelzfzLp92d7Y+iKZE9KqT/rCyiX6+05Kl5Q1/IpUVdjuhIqzPSS3vUjGKkDLUqwzzk
	NpDghJZxBr2l/jCruCwr6Ubq7QXJ9JssLrUo3rkp7Xp3ZrKoCJ46BeceSQ3EDB43kOKDd
	Q4wunlJCjA5kq9lDrCSa7o/pvkIOZemlu/k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo30) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n0233eo1LKPv0V ;
	Tue, 21 Feb 2012 23:01:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 31FCD18638; Tue, 21 Feb 2012 23:01:49 +0100 (CET)
Date: Tue, 21 Feb 2012 23:01:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120221220148.GA5984@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<20291.57670.186303.970388@mariner.uk.xensource.com>
	<20120221183042.GA24861@aepfle.de>
	<20291.58206.279883.482278@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20291.58206.279883.482278@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Jackson wrote:

> Olaf Hering writes ("Re: [Xen-devel] libxenstore.so Makefile dependency issue"):
> > Is this with make 3.82?
> > 
> > I think its time to ask on a make mailing list for advice. The NEWS file
> > for 3.82 did not contain any (obvious related) incompatible change.
> 
> 3.81.
> 
> You could try the patch from my last mail which I think should enable
> to you repro the bug every time.

Not really. If I put a simple sleep 1 or 2 in there libxenstore.so is
not created in time, but sleep 3 and more helps.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 22:02:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 22: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 1Rzxmr-0000MV-St; Tue, 21 Feb 2012 22:02:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rzxmq-0000MQ-SC
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 22:02:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329861730!14922965!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTE3OTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32145 invoked from network); 21 Feb 2012 22:02:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 21 Feb 2012 22:02:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329861729; l=562;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=mts6OhV/o43Te6uxWZHyxUlDluw=;
	b=AelzfzLp92d7Y+iKZE9KqT/rCyiX6+05Kl5Q1/IpUVdjuhIqzPSS3vUjGKkDLUqwzzk
	NpDghJZxBr2l/jCruCwr6Ubq7QXJ9JssLrUo3rkp7Xp3ZrKoCJ46BeceSQ3EDB43kOKDd
	Q4wunlJCjA5kq9lDrCSa7o/pvkIOZemlu/k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo30) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n0233eo1LKPv0V ;
	Tue, 21 Feb 2012 23:01:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 31FCD18638; Tue, 21 Feb 2012 23:01:49 +0100 (CET)
Date: Tue, 21 Feb 2012 23:01:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120221220148.GA5984@aepfle.de>
References: <20120220192655.GA8280@aepfle.de>
	<20291.57670.186303.970388@mariner.uk.xensource.com>
	<20120221183042.GA24861@aepfle.de>
	<20291.58206.279883.482278@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20291.58206.279883.482278@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxenstore.so Makefile dependency 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, Feb 21, Ian Jackson wrote:

> Olaf Hering writes ("Re: [Xen-devel] libxenstore.so Makefile dependency issue"):
> > Is this with make 3.82?
> > 
> > I think its time to ask on a make mailing list for advice. The NEWS file
> > for 3.82 did not contain any (obvious related) incompatible change.
> 
> 3.81.
> 
> You could try the patch from my last mail which I think should enable
> to you repro the bug every time.

Not really. If I put a simple sleep 1 or 2 in there libxenstore.so is
not created in time, but sleep 3 and more helps.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 23:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 23: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 1RzzPT-0001gR-MG; Tue, 21 Feb 2012 23:46: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 1RzzPS-0001gJ-5E
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 23:46:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329867833!49662874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1938 invoked from network); 21 Feb 2012 23:43:54 -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 Feb 2012 23:43:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,460,1325462400"; d="scan'208";a="10856094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 23:46:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 23:46:09 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzzPM-0005sD-KA;
	Tue, 21 Feb 2012 23:46:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzzPM-0003xL-9z;
	Tue, 21 Feb 2012 23:46:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12001-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 23:46:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12001: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12001 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12001/

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. 11986

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a88ba599add1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 323 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 21 23:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 21 Feb 2012 23: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 1RzzPT-0001gR-MG; Tue, 21 Feb 2012 23:46: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 1RzzPS-0001gJ-5E
	for xen-devel@lists.xensource.com; Tue, 21 Feb 2012 23:46:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1329867833!49662874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1938 invoked from network); 21 Feb 2012 23:43:54 -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 Feb 2012 23:43:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,460,1325462400"; d="scan'208";a="10856094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2012 23:46:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 21 Feb 2012 23:46:09 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RzzPM-0005sD-KA;
	Tue, 21 Feb 2012 23:46:08 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RzzPM-0003xL-9z;
	Tue, 21 Feb 2012 23:46:08 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12001-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 21 Feb 2012 23:46:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12001: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12001 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12001/

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. 11986

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a88ba599add1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 323 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 Feb 22 03:21:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 03:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S02lM-0001mb-SD; Wed, 22 Feb 2012 03:21:05 +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 1S02lK-0001mW-20
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 03:21:02 +0000
Received: from [85.158.139.83:56016] by server-11.bemta-5.messagelabs.com id
	33/7B-14397-D1F544F4; Wed, 22 Feb 2012 03:21:01 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329880858!16029071!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk5OTI4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28337 invoked from network); 22 Feb 2012 03:20:59 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	22 Feb 2012 03:20:59 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 21 Feb 2012 19:20:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="68915378"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by AZSMGA002.ch.intel.com with ESMTP; 21 Feb 2012 19:20:56 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 22 Feb 2012 11:19:36 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 22 Feb 2012 11:19:36 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Wed, 22 Feb 2012 11:19:34 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM8G9dFE2rD8kEpUevO+lz9U2PUZZINiCA
Date: Wed, 22 Feb 2012 03:19:33 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A7F2E@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
In-Reply-To: <4F435DED0200007800074080@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: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad RzeszutekWilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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

Jan Beulich wrote:
>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Core parking is a power control feature and it can co-work with
>>>> NPTM to control system power budget through online/offline some
>>>> CPUs in the system. These patches implement core parking feature
>>>> for xen. They consist of 2 parts: dom0 patches and xen hypervisor
>>>> patches. 
>>>> 
>>>> At dom0 side, patches include
>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>> logic, providing a native interface for natvie platform and a
>>>> paravirt template for paravirt platform, so that os can implicitly
>>>> hook to proper ops accordingly; [Patch 2/3] redirect paravirt
>>>> template to Xen pv ops; [Patch 3/3] implement Xen pad logic, and
>>>> when getting pad device notification, it hypercalls to Xen
>>>> hypervisor for core parking. Due to the characteristic of xen
>>>> continue_hypercall_on_cpu, dom0 seperately send/get core parking
>>>> request/result; 
>>>> 
>>>> At Xen hypervisor side, patches include
>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>> parking request, and get core parking result;
>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>> sequence has different power/performance result, due to cpu
>>>> socket/core/thread topology. This patch provide power-first and
>>>> performance-first policies, users can choose core parking policy on
>>>> their own demand, considering power and performance tradeoff.
>>> 
>>> Does this really need to be implemented in the hypervisor? All this
>>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>>> have hypercall interfaces already. So I'd rather see this as being
>>> an extension to Dom0's pCPU management patches (which aren't
>>> upstream afaict)... 
>>> 
>>> Jan
>> 
>> It's a design choice. Core parking is not only a wrapper around
>> cpu_down/up, it also involves policy algorithms which depend on
>> physical cpu topology and cpu_online/present_map, etc. Implement
>> core parking at dom0 side need expose all those information to dom0,
>> with potential issues (like coherence), while dom0 still need do
>> same work as hypervisor. 
>> Our idea is to keep dom0 as ACPI parser, then hypercall and do rest
>> things at hypervisor side.
> 
> Actually, after some more thought, I don't even think this ought to
> be implemented in the Dom0 kernel, but in user space altogether.
> Afaict all information necessary is already being exposed.
> 

No, user space lack necessary information. If I didn't misunderstand, it has some dom0-side dependencies not ready now, like
1. sysfs interface, and exposing xen pcpu topology and maps;
2. intecept pad notify and call usermodehelper;
3. a daemon to monitor/policy core parking (daemon enable when linux run as pvops under xen (kernel acpi_pad disable now), daemon disable when linux run under baremetal (kernel acpi_pad enable now))

Seems keep same approach as native kernel which handle acpi_pad in kernel side (for us, in hypervisor side) is a reasonable choice. Per my understanding core parking is a co-work part of NPTM, the whole process is basically a remote controller-microengine-bios-kernel process, not necessarily involve user action.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 03:21:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 03:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S02lM-0001mb-SD; Wed, 22 Feb 2012 03:21:05 +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 1S02lK-0001mW-20
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 03:21:02 +0000
Received: from [85.158.139.83:56016] by server-11.bemta-5.messagelabs.com id
	33/7B-14397-D1F544F4; Wed, 22 Feb 2012 03:21:01 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329880858!16029071!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk5OTI4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28337 invoked from network); 22 Feb 2012 03:20:59 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	22 Feb 2012 03:20:59 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 21 Feb 2012 19:20:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="68915378"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by AZSMGA002.ch.intel.com with ESMTP; 21 Feb 2012 19:20:56 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 22 Feb 2012 11:19:36 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 22 Feb 2012 11:19:36 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Wed, 22 Feb 2012 11:19:34 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM8G9dFE2rD8kEpUevO+lz9U2PUZZINiCA
Date: Wed, 22 Feb 2012 03:19:33 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350A7F2E@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
In-Reply-To: <4F435DED0200007800074080@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: "Li, Shaohua" <shaohua.li@intel.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Konrad RzeszutekWilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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

Jan Beulich wrote:
>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Core parking is a power control feature and it can co-work with
>>>> NPTM to control system power budget through online/offline some
>>>> CPUs in the system. These patches implement core parking feature
>>>> for xen. They consist of 2 parts: dom0 patches and xen hypervisor
>>>> patches. 
>>>> 
>>>> At dom0 side, patches include
>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>> logic, providing a native interface for natvie platform and a
>>>> paravirt template for paravirt platform, so that os can implicitly
>>>> hook to proper ops accordingly; [Patch 2/3] redirect paravirt
>>>> template to Xen pv ops; [Patch 3/3] implement Xen pad logic, and
>>>> when getting pad device notification, it hypercalls to Xen
>>>> hypervisor for core parking. Due to the characteristic of xen
>>>> continue_hypercall_on_cpu, dom0 seperately send/get core parking
>>>> request/result; 
>>>> 
>>>> At Xen hypervisor side, patches include
>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>> parking request, and get core parking result;
>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>> sequence has different power/performance result, due to cpu
>>>> socket/core/thread topology. This patch provide power-first and
>>>> performance-first policies, users can choose core parking policy on
>>>> their own demand, considering power and performance tradeoff.
>>> 
>>> Does this really need to be implemented in the hypervisor? All this
>>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>>> have hypercall interfaces already. So I'd rather see this as being
>>> an extension to Dom0's pCPU management patches (which aren't
>>> upstream afaict)... 
>>> 
>>> Jan
>> 
>> It's a design choice. Core parking is not only a wrapper around
>> cpu_down/up, it also involves policy algorithms which depend on
>> physical cpu topology and cpu_online/present_map, etc. Implement
>> core parking at dom0 side need expose all those information to dom0,
>> with potential issues (like coherence), while dom0 still need do
>> same work as hypervisor. 
>> Our idea is to keep dom0 as ACPI parser, then hypercall and do rest
>> things at hypervisor side.
> 
> Actually, after some more thought, I don't even think this ought to
> be implemented in the Dom0 kernel, but in user space altogether.
> Afaict all information necessary is already being exposed.
> 

No, user space lack necessary information. If I didn't misunderstand, it has some dom0-side dependencies not ready now, like
1. sysfs interface, and exposing xen pcpu topology and maps;
2. intecept pad notify and call usermodehelper;
3. a daemon to monitor/policy core parking (daemon enable when linux run as pvops under xen (kernel acpi_pad disable now), daemon disable when linux run under baremetal (kernel acpi_pad enable now))

Seems keep same approach as native kernel which handle acpi_pad in kernel side (for us, in hypervisor side) is a reasonable choice. Per my understanding core parking is a co-work part of NPTM, the whole process is basically a remote controller-microengine-bios-kernel process, not necessarily involve user action.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 03:53:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 03:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S03Fj-0002Fa-Dd; Wed, 22 Feb 2012 03:52:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S03Fh-0002FV-Dw
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 03:52:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329882738!16326628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9293 invoked from network); 22 Feb 2012 03:52:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 03:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,461,1325462400"; d="scan'208";a="10857095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 03:52:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 03:52:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S03FZ-0007XI-Hq;
	Wed, 22 Feb 2012 03:52:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S03FZ-0006fL-By;
	Wed, 22 Feb 2012 03:52:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12002-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 03:52:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12002: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12002 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12002/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 03:53:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 03:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S03Fj-0002Fa-Dd; Wed, 22 Feb 2012 03:52:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S03Fh-0002FV-Dw
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 03:52:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1329882738!16326628!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9293 invoked from network); 22 Feb 2012 03:52:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 03:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,461,1325462400"; d="scan'208";a="10857095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 03:52:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 03:52:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S03FZ-0007XI-Hq;
	Wed, 22 Feb 2012 03:52:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S03FZ-0006fL-By;
	Wed, 22 Feb 2012 03:52:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12002-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 03:52:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12002: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12002 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12002/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 06:15:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 06:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S05T9-0004Gm-S9; Wed, 22 Feb 2012 06:14:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S05T7-0004Gd-WC
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 06:14:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329891258!14385951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31581 invoked from network); 22 Feb 2012 06:14:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 06:14:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,462,1325462400"; d="scan'208";a="10858261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 06:14:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 06:14:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S05Sz-0008WD-7W;
	Wed, 22 Feb 2012 06:14:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S05Sy-0004u4-Og;
	Wed, 22 Feb 2012 06:14:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12003-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 06:14:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12003: 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 12003 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12003/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a88ba599add1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a88ba599add1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a88ba599add1
+ branch=xen-unstable
+ revision=a88ba599add1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a88ba599add1 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 32 changes to 14 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 06:15:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 06:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S05T9-0004Gm-S9; Wed, 22 Feb 2012 06:14:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S05T7-0004Gd-WC
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 06:14:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329891258!14385951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31581 invoked from network); 22 Feb 2012 06:14:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 06:14:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,462,1325462400"; d="scan'208";a="10858261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 06:14:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 06:14:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S05Sz-0008WD-7W;
	Wed, 22 Feb 2012 06:14:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S05Sy-0004u4-Og;
	Wed, 22 Feb 2012 06:14:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12003-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 06:14:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12003: 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 12003 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12003/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11986

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a88ba599add1
baseline version:
 xen                  ca80eca9cfa3

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD <anthony.perard@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Olaf Hering <olaf@aepfle.de>
  Shriram Rajagopalan <rshriram@cs.ubc.ca>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a88ba599add1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a88ba599add1
+ branch=xen-unstable
+ revision=a88ba599add1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a88ba599add1 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 32 changes to 14 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 07:07:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 07:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S06I1-000683-6t; Wed, 22 Feb 2012 07:07: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 1S06Hz-00067x-Em
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 07:06:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329894364!50216479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18988 invoked from network); 22 Feb 2012 07:06:04 -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;
	22 Feb 2012 07:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,462,1325462400"; d="scan'208";a="10858602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 07:06:58 +0000
Received: from [127.0.0.1] (10.80.16.66) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 07:06:58 +0000
Message-ID: <1329894417.25232.119.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 07:06:57 +0000
In-Reply-To: <osstest-12003-mainreport@xen.org>
References: <osstest-12003-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12003: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 06:14 +0000, xen.org wrote:
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

From
http://www.chiark.greenend.org.uk/~xensrcts/logs/12003/test-amd64-amd64-xl-qemuu-winxpsp3/bush-cricket---var-log-xen-qemu-dm-win.guest.osstest.log:

        /usr/lib/xen/bin/qemu-system-i386: error while loading shared
        libraries: libgthread-2.0.so.0: cannot open shared object file:
        No such file or directory
        
It seems that we need:

$ dpkg -S libgthread-2.0.so.0
libglib2.0-0: /usr/lib/libgthread-2.0.so.0.2400.2
libglib2.0-0: /usr/lib/libgthread-2.0.so.0

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 07:07:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 07:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S06I1-000683-6t; Wed, 22 Feb 2012 07:07: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 1S06Hz-00067x-Em
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 07:06:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329894364!50216479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18988 invoked from network); 22 Feb 2012 07:06:04 -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;
	22 Feb 2012 07:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,462,1325462400"; d="scan'208";a="10858602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 07:06:58 +0000
Received: from [127.0.0.1] (10.80.16.66) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 07:06:58 +0000
Message-ID: <1329894417.25232.119.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 07:06:57 +0000
In-Reply-To: <osstest-12003-mainreport@xen.org>
References: <osstest-12003-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12003: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 06:14 +0000, xen.org wrote:
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass

From
http://www.chiark.greenend.org.uk/~xensrcts/logs/12003/test-amd64-amd64-xl-qemuu-winxpsp3/bush-cricket---var-log-xen-qemu-dm-win.guest.osstest.log:

        /usr/lib/xen/bin/qemu-system-i386: error while loading shared
        libraries: libgthread-2.0.so.0: cannot open shared object file:
        No such file or directory
        
It seems that we need:

$ dpkg -S libgthread-2.0.so.0
libglib2.0-0: /usr/lib/libgthread-2.0.so.0.2400.2
libglib2.0-0: /usr/lib/libgthread-2.0.so.0

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 07:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 07: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 1S06Ls-0006HE-Cz; Wed, 22 Feb 2012 07:11: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 1S06Lq-0006H3-8P
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 07:10:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329894583!62363444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31565 invoked from network); 22 Feb 2012 07:09:43 -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;
	22 Feb 2012 07:09:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,462,1325462400"; d="scan'208";a="10858640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 07:10:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 07:10:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S06Lm-0000Y8-Uq;
	Wed, 22 Feb 2012 07:10:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S06Lm-0003BO-NG;
	Wed, 22 Feb 2012 07:10:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12007-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 07:10:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12007 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12007/

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. 12003
 build-i386                    4 xen-build                 fail REGR. vs. 12003
 build-amd64                   4 xen-build                 fail REGR. vs. 12003
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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

version targeted for testing:
 xen                  8ee81ceda8c9
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

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:   24861:8ee81ceda8c9
tag:         tip
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 07:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 07: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 1S06Ls-0006HE-Cz; Wed, 22 Feb 2012 07:11: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 1S06Lq-0006H3-8P
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 07:10:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1329894583!62363444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDE4MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31565 invoked from network); 22 Feb 2012 07:09:43 -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;
	22 Feb 2012 07:09:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,462,1325462400"; d="scan'208";a="10858640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 07:10:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 07:10:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S06Lm-0000Y8-Uq;
	Wed, 22 Feb 2012 07:10:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S06Lm-0003BO-NG;
	Wed, 22 Feb 2012 07:10:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12007-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 07:10:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12007 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12007/

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. 12003
 build-i386                    4 xen-build                 fail REGR. vs. 12003
 build-amd64                   4 xen-build                 fail REGR. vs. 12003
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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

version targeted for testing:
 xen                  8ee81ceda8c9
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

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:   24861:8ee81ceda8c9
tag:         tip
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 08:48:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 08: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 1S07rm-0007sO-7D; Wed, 22 Feb 2012 08:48:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1S07rj-0007s5-Ka
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 08:48:00 +0000
Received: from [85.158.139.83:27094] by server-10.bemta-5.messagelabs.com id
	7D/42-07861-EBBA44F4; Wed, 22 Feb 2012 08:47:58 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329900477!15459304!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMzQ2Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18110 invoked from network); 22 Feb 2012 08:47:57 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-182.messagelabs.com with SMTP;
	22 Feb 2012 08:47:57 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 22 Feb 2012 00:47:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="128076272"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by fmsmga002.fm.intel.com with ESMTP; 22 Feb 2012 00:47:55 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 22 Feb 2012 16:47:52 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 22 Feb 2012 16:47:51 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 22 Feb 2012 16:47:50 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Matthew Hook <matthew.hook@otoy.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
Thread-Index: AQHM8FX50QDHd0kQ0kulzqAWlZYHAZZG6C3AgAA9ywCAAXSYAA==
Date: Wed, 22 Feb 2012 08:47:50 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564407C23A@SHSMSX101.ccr.corp.intel.com>
References: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
	<B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
	<CAMrHX2Wmci7n5h1NsseiRHr3-TZ_JbY_6aKJFvHTaw4wOxGqHg@mail.gmail.com>
In-Reply-To: <CAMrHX2Wmci7n5h1NsseiRHr3-TZ_JbY_6aKJFvHTaw4wOxGqHg@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
Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Matt
  Can you try to assign the second one to a Linux guest,  and it maybe give=
 more useful information for root-causing it.  I also believe Xen should su=
pport such assignment, but we hadn't try the card like yours.    Seems you =
have many such cards,  have you tried to only assign the first one for each=
 card ?  For example, insert two cards to your system, and assign each one'=
s first function to each dedicated guest.  If only the second function has =
the issue,  it maybe a new potential issue in VGA passthru logic,  I don't =
think someone else tried such cards before.  :)
Xiantao

> -----Original Message-----
> From: Matthew Hook [mailto:matthew.hook@otoy.com]
> Sent: Wednesday, February 22, 2012 2:27 AM
> To: Zhang, Xiantao; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two
> domU's
> =

> Thanks Xiantao,
> =

> I am using a Dual Xeon Tyan server here and VT-d is enabled.  I was hoping
> someone might spot something special in the PCI listing for the device th=
at
> might explain why I haven't been able to get the second GPU to start.
> One difference between the primary and secondary GPU is that the second
> GPU on the card does not have any VGA output capability.
> However, we're not needing VGA output as we remote in to the guest.
> This limitation hasn't stopped us from getting VMWare to successfully
> dedicate the second GPU to it's on virtual machine.
> =

> Looking at the xen-unstable source tree I do see some significant changes=
 to
> VGA passthrough so I may try this and see if I have any success.
> =

> Matt
> =

> On 20 February 2012 22:54, Zhang, Xiantao <xiantao.zhang@intel.com> wrote:
> > If the card has two =A0full-fledged =A0PCI-e graphics functions, I thin=
k you can
> follow the link(http://wiki.xen.org/wiki/Xen_VGA_Passthrough) to do your
> passthru work. It depends on Intel's VT-d or AMD's IOMMU technology, so
> please make sure all required components are ready in your system. =A0 I =
think
> Xen's mailing list archive also has some detailed discussions about how to
> passthru one graphics device to the guest and what's difference compared
> with general PCIe device assignment.
> > Xiantao
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> >> bounces@lists.xen.org] On Behalf Of Matthew Hook
> >> Sent: Tuesday, February 21, 2012 12:59 PM
> >> To: xen-devel@lists.xensource.com
> >> Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two
> >> domU's
> >>
> >> Is it possible in Xen that with a dual GPU graphics card which
> >> appears as two separately addressable PCI devices to pass each GPU to a
> separate guest?
> >> Although I didn't think this was initially possible, VMWare supports i=
t.
> >> It's useful under xen for increasing virtual server density when
> >> providing virtual desktops or similar.
> >> Although not many Dual GPU cards are on the market at the moment, it
> >> seems likely that Dual or Quad GPU cards will become the norm in the
> >> near future.
> >>
> >> For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
> >> I have successfully managed to passthru one of the GPU's on the card
> >> with success. =A0However I get a BSOD on the second one.
> >>
> >> I'm wondering if compiling in the VGA BIOS may help?
> >> If so, where is a good resource on how I could do that?
> >>
> >>
> >> Cards show in lspci as follows:
> >>
> >> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> >> 12:00.1 Audio device: ATI Technologies Inc Device aa80
> >> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
> >> 13:00.1 Audio device: ATI Technologies Inc Device aa80
> >>
> >>
> >> ATI Technologies Inc Device aa80
> >>
> >> +-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-04.0-[0000:10-13]----00.0
> >> -
> >> [0000:11-13]--+-04.0-[0000:13]--+-00.0
> >> =A0ATI Technologies Inc Device 671d
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies
> >> Inc Device aa80
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \-08.0-[0000:12]--=
+-00.0 =A0ATI Technologies
> >> Inc Device 671d
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies
> >> Inc Device aa80
> >>
> >>
> >> More details on the devices themselves.
> >>
> >> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> >> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 1b2a
> >> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGAS=
noop-
> >> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >> >TAbort-
> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
> >> =A0 =A0 =A0 =A0 Region 0: Memory at 80000000 (64-bit, prefetchable)
> >> [disabled] [size=3D256M]
> >> =A0 =A0 =A0 =A0 Region 2: Memory at fb6c0000 (64-bit, non-prefetchable)
> >> [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Region 4: I/O ports at 9000 [disabled] [size=3D256]
> >> =A0 =A0 =A0 =A0 Expansion ROM at fb6a0000 [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
> >> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
> >> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFun=
c 0, Latency
> >> L0s <4us, L1 unlimited
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnI=
nd- PwrInd- RBE+
> >> FLReset-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- No=
n-Fatal- Fatal-
> >> Unsupported-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- Phant=
Func- AuxPwr- NoSnoop+
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, =
MaxReadReq 512 bytes
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- =
UnsuppReq+
> >> AuxPwr- TransPend-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #8, Speed 2.5GT/s, Width =
x16, ASPM L0s
> >> L1, Latency L0 <64ns, L1 <1us
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLAc=
tRep- BwNot-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Di=
sabled-
> >> Retrain- CommClk-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- Aut=
WidDis- BWInt-
> >> AutBWInt-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrEr=
r- Train-
> >> SlotClk+ DLActive- BWMgmt- ABWMgmt-
> >> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask-=
 64bit+
> >> Queue=3D0/0 Enable-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
> >> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
> >> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
> >> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
> >>
> >>
> >> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
> >> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 0b2a
> >> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGAS=
noop-
> >> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >> >TAbort-
> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
> >> =A0 =A0 =A0 =A0 Region 0: Memory at 90000000 (64-bit, prefetchable)
> >> [disabled] [size=3D256M]
> >> =A0 =A0 =A0 =A0 Region 2: Memory at fb7c0000 (64-bit, non-prefetchable)
> >> [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Region 4: I/O ports at a000 [disabled] [size=3D256]
> >> =A0 =A0 =A0 =A0 Expansion ROM at fb7a0000 [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
> >> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
> >> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFun=
c 0, Latency
> >> L0s <4us, L1 unlimited
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnI=
nd- PwrInd- RBE+
> >> FLReset-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- No=
n-Fatal- Fatal-
> >> Unsupported-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- Phant=
Func- AuxPwr- NoSnoop+
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, =
MaxReadReq 512 bytes
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- =
UnsuppReq+
> >> AuxPwr- TransPend-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #4, Speed 2.5GT/s, Width =
x16, ASPM L0s
> >> L1, Latency L0 <64ns, L1 <1us
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLAc=
tRep- BwNot-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Di=
sabled-
> >> Retrain- CommClk-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- Aut=
WidDis- BWInt-
> >> AutBWInt-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrEr=
r- Train-
> >> SlotClk+ DLActive- BWMgmt- ABWMgmt-
> >> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask-=
 64bit+
> >> Queue=3D0/0 Enable-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
> >> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
> >> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
> >> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
> >>
> >> Matt
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 08:48:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 08: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 1S07rm-0007sO-7D; Wed, 22 Feb 2012 08:48:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1S07rj-0007s5-Ka
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 08:48:00 +0000
Received: from [85.158.139.83:27094] by server-10.bemta-5.messagelabs.com id
	7D/42-07861-EBBA44F4; Wed, 22 Feb 2012 08:47:58 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1329900477!15459304!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMzQ2Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18110 invoked from network); 22 Feb 2012 08:47:57 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-182.messagelabs.com with SMTP;
	22 Feb 2012 08:47:57 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 22 Feb 2012 00:47:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="128076272"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by fmsmga002.fm.intel.com with ESMTP; 22 Feb 2012 00:47:55 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 22 Feb 2012 16:47:52 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 22 Feb 2012 16:47:51 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 22 Feb 2012 16:47:50 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Matthew Hook <matthew.hook@otoy.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Graphics passthru for dual-GPU cards to two domU's
Thread-Index: AQHM8FX50QDHd0kQ0kulzqAWlZYHAZZG6C3AgAA9ywCAAXSYAA==
Date: Wed, 22 Feb 2012 08:47:50 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564407C23A@SHSMSX101.ccr.corp.intel.com>
References: <CAMrHX2XvgBXNFkfu-_=WZoumrCD6A8XrAzhZ+Lcv5=UqkAdE-Q@mail.gmail.com>
	<B6C2EB9186482D47BD0C5A9A4834564407A93E@SHSMSX101.ccr.corp.intel.com>
	<CAMrHX2Wmci7n5h1NsseiRHr3-TZ_JbY_6aKJFvHTaw4wOxGqHg@mail.gmail.com>
In-Reply-To: <CAMrHX2Wmci7n5h1NsseiRHr3-TZ_JbY_6aKJFvHTaw4wOxGqHg@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
Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two domU'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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Matt
  Can you try to assign the second one to a Linux guest,  and it maybe give=
 more useful information for root-causing it.  I also believe Xen should su=
pport such assignment, but we hadn't try the card like yours.    Seems you =
have many such cards,  have you tried to only assign the first one for each=
 card ?  For example, insert two cards to your system, and assign each one'=
s first function to each dedicated guest.  If only the second function has =
the issue,  it maybe a new potential issue in VGA passthru logic,  I don't =
think someone else tried such cards before.  :)
Xiantao

> -----Original Message-----
> From: Matthew Hook [mailto:matthew.hook@otoy.com]
> Sent: Wednesday, February 22, 2012 2:27 AM
> To: Zhang, Xiantao; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Graphics passthru for dual-GPU cards to two
> domU's
> =

> Thanks Xiantao,
> =

> I am using a Dual Xeon Tyan server here and VT-d is enabled.  I was hoping
> someone might spot something special in the PCI listing for the device th=
at
> might explain why I haven't been able to get the second GPU to start.
> One difference between the primary and secondary GPU is that the second
> GPU on the card does not have any VGA output capability.
> However, we're not needing VGA output as we remote in to the guest.
> This limitation hasn't stopped us from getting VMWare to successfully
> dedicate the second GPU to it's on virtual machine.
> =

> Looking at the xen-unstable source tree I do see some significant changes=
 to
> VGA passthrough so I may try this and see if I have any success.
> =

> Matt
> =

> On 20 February 2012 22:54, Zhang, Xiantao <xiantao.zhang@intel.com> wrote:
> > If the card has two =A0full-fledged =A0PCI-e graphics functions, I thin=
k you can
> follow the link(http://wiki.xen.org/wiki/Xen_VGA_Passthrough) to do your
> passthru work. It depends on Intel's VT-d or AMD's IOMMU technology, so
> please make sure all required components are ready in your system. =A0 I =
think
> Xen's mailing list archive also has some detailed discussions about how to
> passthru one graphics device to the guest and what's difference compared
> with general PCIe device assignment.
> > Xiantao
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> >> bounces@lists.xen.org] On Behalf Of Matthew Hook
> >> Sent: Tuesday, February 21, 2012 12:59 PM
> >> To: xen-devel@lists.xensource.com
> >> Subject: [Xen-devel] Graphics passthru for dual-GPU cards to two
> >> domU's
> >>
> >> Is it possible in Xen that with a dual GPU graphics card which
> >> appears as two separately addressable PCI devices to pass each GPU to a
> separate guest?
> >> Although I didn't think this was initially possible, VMWare supports i=
t.
> >> It's useful under xen for increasing virtual server density when
> >> providing virtual desktops or similar.
> >> Although not many Dual GPU cards are on the market at the moment, it
> >> seems likely that Dual or Quad GPU cards will become the norm in the
> >> near future.
> >>
> >> For example, I have a number of Dual GPU AMD HD Radeon 6990 card's.
> >> I have successfully managed to passthru one of the GPU's on the card
> >> with success. =A0However I get a BSOD on the second one.
> >>
> >> I'm wondering if compiling in the VGA BIOS may help?
> >> If so, where is a good resource on how I could do that?
> >>
> >>
> >> Cards show in lspci as follows:
> >>
> >> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> >> 12:00.1 Audio device: ATI Technologies Inc Device aa80
> >> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
> >> 13:00.1 Audio device: ATI Technologies Inc Device aa80
> >>
> >>
> >> ATI Technologies Inc Device aa80
> >>
> >> +-07.0-[0000:0a-13]----00.0-[0000:0b-13]--+-04.0-[0000:10-13]----00.0
> >> -
> >> [0000:11-13]--+-04.0-[0000:13]--+-00.0
> >> =A0ATI Technologies Inc Device 671d
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies
> >> Inc Device aa80
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \-08.0-[0000:12]--=
+-00.0 =A0ATI Technologies
> >> Inc Device 671d
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 \-00.1 =A0ATI Technologies
> >> Inc Device aa80
> >>
> >>
> >> More details on the devices themselves.
> >>
> >> 12:00.0 Display controller: ATI Technologies Inc Device 671d
> >> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 1b2a
> >> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGAS=
noop-
> >> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >> >TAbort-
> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
> >> =A0 =A0 =A0 =A0 Region 0: Memory at 80000000 (64-bit, prefetchable)
> >> [disabled] [size=3D256M]
> >> =A0 =A0 =A0 =A0 Region 2: Memory at fb6c0000 (64-bit, non-prefetchable)
> >> [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Region 4: I/O ports at 9000 [disabled] [size=3D256]
> >> =A0 =A0 =A0 =A0 Expansion ROM at fb6a0000 [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
> >> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
> >> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFun=
c 0, Latency
> >> L0s <4us, L1 unlimited
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnI=
nd- PwrInd- RBE+
> >> FLReset-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- No=
n-Fatal- Fatal-
> >> Unsupported-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- Phant=
Func- AuxPwr- NoSnoop+
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, =
MaxReadReq 512 bytes
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- =
UnsuppReq+
> >> AuxPwr- TransPend-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #8, Speed 2.5GT/s, Width =
x16, ASPM L0s
> >> L1, Latency L0 <64ns, L1 <1us
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLAc=
tRep- BwNot-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Di=
sabled-
> >> Retrain- CommClk-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- Aut=
WidDis- BWInt-
> >> AutBWInt-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrEr=
r- Train-
> >> SlotClk+ DLActive- BWMgmt- ABWMgmt-
> >> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask-=
 64bit+
> >> Queue=3D0/0 Enable-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
> >> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
> >> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
> >> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
> >>
> >>
> >> 13:00.0 VGA compatible controller: ATI Technologies Inc Device 671d
> >> =A0 =A0 =A0 =A0 Subsystem: ATI Technologies Inc Device 0b2a
> >> =A0 =A0 =A0 =A0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGAS=
noop-
> >> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> =A0 =A0 =A0 =A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >> >TAbort-
> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> =A0 =A0 =A0 =A0 Interrupt: pin A routed to IRQ 30
> >> =A0 =A0 =A0 =A0 Region 0: Memory at 90000000 (64-bit, prefetchable)
> >> [disabled] [size=3D256M]
> >> =A0 =A0 =A0 =A0 Region 2: Memory at fb7c0000 (64-bit, non-prefetchable)
> >> [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Region 4: I/O ports at a000 [disabled] [size=3D256]
> >> =A0 =A0 =A0 =A0 Expansion ROM at fb7a0000 [disabled] [size=3D128K]
> >> =A0 =A0 =A0 =A0 Capabilities: [50] Power Management version 3
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=
=3D0mA
> >> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status: D0 PME-Enable- DSel=3D0 DScale=
=3D0 PME-
> >> =A0 =A0 =A0 =A0 Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCap: MaxPayload 256 bytes, PhantFun=
c 0, Latency
> >> L0s <4us, L1 unlimited
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtTag+ AttnBtn- AttnI=
nd- PwrInd- RBE+
> >> FLReset-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevCtl: Report errors: Correctable- No=
n-Fatal- Fatal-
> >> Unsupported-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RlxdOrd+ ExtTag- Phant=
Func- AuxPwr- NoSnoop+
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MaxPayload 128 bytes, =
MaxReadReq 512 bytes
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DevSta: CorrErr+ UncorrErr- FatalErr- =
UnsuppReq+
> >> AuxPwr- TransPend-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCap: Port #4, Speed 2.5GT/s, Width =
x16, ASPM L0s
> >> L1, Latency L0 <64ns, L1 <1us
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClockPM- Suprise- LLAc=
tRep- BwNot-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkCtl: ASPM Disabled; RCB 64 bytes Di=
sabled-
> >> Retrain- CommClk-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ExtSynch- ClockPM- Aut=
WidDis- BWInt-
> >> AutBWInt-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LnkSta: Speed 2.5GT/s, Width x16, TrEr=
r- Train-
> >> SlotClk+ DLActive- BWMgmt- ABWMgmt-
> >> =A0 =A0 =A0 =A0 Capabilities: [a0] Message Signalled Interrupts: Mask-=
 64bit+
> >> Queue=3D0/0 Enable-
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address: 0000000000000000 =A0Data: 0000
> >> =A0 =A0 =A0 =A0 Capabilities: [100] Vendor Specific Information <?>
> >> =A0 =A0 =A0 =A0 Capabilities: [150] Advanced Error Reporting <?>
> >> =A0 =A0 =A0 =A0 Kernel driver in use: pciback
> >>
> >> Matt
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:13:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:13:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08FS-00086H-EM; Wed, 22 Feb 2012 09:12:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S08FR-00086C-8Q
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:12:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329901943!9069757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13368 invoked from network); 22 Feb 2012 09:12:23 -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;
	22 Feb 2012 09:12:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10862182"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 09:12:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 09:12:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S08FK-0001an-IW;
	Wed, 22 Feb 2012 09:12:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S08FK-0003lN-I9;
	Wed, 22 Feb 2012 09:12:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12006-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 09:12:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12006: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12006 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12006/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl           18 leak-check/check            fail pass in 12002

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:13:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:13:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08FS-00086H-EM; Wed, 22 Feb 2012 09:12:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S08FR-00086C-8Q
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:12:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329901943!9069757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13368 invoked from network); 22 Feb 2012 09:12:23 -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;
	22 Feb 2012 09:12:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10862182"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 09:12:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 09:12:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S08FK-0001an-IW;
	Wed, 22 Feb 2012 09:12:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S08FK-0003lN-I9;
	Wed, 22 Feb 2012 09:12:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12006-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 09:12:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12006: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12006 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12006/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl           18 leak-check/check            fail pass in 12002

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08NF-0008Qg-CV; Wed, 22 Feb 2012 09:20:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S08ND-0008QY-7T
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:20:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329902424!14366161!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18688 invoked from network); 22 Feb 2012 09:20:24 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 09:20:24 -0000
Received: by wgbdr13 with SMTP id dr13so5734703wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 01:20:24 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr43263481wia.3.1329902424010 (num_hops
	= 1); Wed, 22 Feb 2012 01:20:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=tPx4mcnqFE0ivJ3qO/xTjxn+rD1cobCMcIXLcSGYJsc=;
	b=UmqVCLRpvuK1GT5KvYTrqXfqvUZhvWrMvx40agU7Ek57/GD19yYOohCWRUd+N0+s45
	ORzAPqJhEkTcrM4USIUrL/KBRmahniDrIicqjxxQCHrDCHIfN2ANHPeGORufVlsnaJyV
	PmrI7glmmzqndp0FDpV56XqW1a440+R7oYETs=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr35897065wia.3.1329902423811; Wed,
	22 Feb 2012 01:20:23 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 01:20:23 -0800 (PST)
In-Reply-To: <osstest-12007-mainreport@xen.org>
References: <osstest-12007-mainreport@xen.org>
Date: Wed, 22 Feb 2012 10:20:23 +0100
X-Google-Sender-Auth: kCyk2wVfjPSVVlhJD8WTi2TaT88
Message-ID: <CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "xen.org" <ian.jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IGZsaWdodCAx
MjAwNyB4ZW4tdW5zdGFibGUgcmVhbCBbcmVhbF0KPiBodHRwOi8vd3d3LmNoaWFyay5ncmVlbmVu
ZC5vcmcudWsvfnhlbnNyY3RzL2xvZ3MvMTIwMDcvCj4KPiBSZWdyZXNzaW9ucyA6LSgKPgo+IFRl
c3RzIHdoaWNoIGRpZCBub3Qgc3VjY2VlZCBhbmQgYXJlIGJsb2NraW5nLAo+IGluY2x1ZGluZyB0
ZXN0cyB3aGljaCBjb3VsZCBub3QgYmUgcnVuOgo+IMKgYnVpbGQtaTM4Ni1vbGRrZXJuIMKgIMKg
IMKgIMKgIMKgIMKgNCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdS
LiB2cy4gMTIwMDMKPiDCoGJ1aWxkLWkzODYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA0
IHhlbi1idWlsZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+
IMKgYnVpbGQtYW1kNjQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgNCB4ZW4tYnVpbGQgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiDCoGJ1aWxkLWFtZDY0
LW9sZGtlcm4gwqAgwqAgwqAgwqAgwqAgNCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKCgpicmN0bCBpcyBub3QgaW5zdGFsbGVkLCBvciB0aGUg
dXNlciB0aGF0IGlzIHRyeWluZyB0byBidWlsZCBYZW4KZG9lc24ndCBoYXZlIHBlcm1pc3Npb25z
IHRvIHJ1biBpdC4gSSd2ZSBmb3VuZCB0aGlzIHRlc3QgcXVpdGUKdXNlbGVzcywgYmVjYXVzZSB5
b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgWGVuIGFzIGEgcmVndWxhciB1c2VyLAp0aGF0IGRv
ZXNuJ3QgaGF2ZSBhY2Nlc3MgdG8gYnJjdGwsIGRvIHlvdSB3YW50IG1lIHRvIHNlbmQgYSBwYXRj
aCB0aGF0CnJlbW92ZXMgdGhpcyBjaGVjaz8KCj4gVGVzdHMgd2hpY2ggZGlkIG5vdCBzdWNjZWVk
LCBidXQgYXJlIG5vdCBibG9ja2luZzoKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtcWVtdXUtd2lu
eHBzcDMgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIG4vYQo+
IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS13aW43LWFtZDY0IMKgMSB4ZW4tYnVpbGQtY2hl
Y2soMSkgwqAgwqAgwqAgwqAgYmxvY2tlZCBuL2EKPiDCoHRlc3QtaTM4Ni1pMzg2LXhsLXFlbXV1
LXdpbnhwc3AzIMKgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDC
oG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWludGVsIMKgMSB4ZW4tYnVp
bGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgYmxvY2tlZCBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQt
eGwtcGNpcHQtaW50ZWwgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9j
a2VkIMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWkzODYtcmhlbDZodm0tYW1kIMKgMSB4ZW4tYnVpbGQt
Y2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2
LXJoZWw2aHZtLWludGVsIMKgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxv
Y2tlZCDCoG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWFtZCDCoDEgeGVu
LWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgbi9hCj4gwqB0ZXN0LWFtZDY0
LWkzODYtcHYgwqAgwqAgwqAgwqAgwqAgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDC
oCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni14bCDCoCDCoCDCoCDCoCDCoCDC
oCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0
ZXN0LWFtZDY0LWkzODYteGwgwqAgwqAgwqAgwqAgwqAgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDC
oCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXhsIMKgIMKg
IMKgIMKgIMKgIDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBu
L2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtc2VkZiDCoCDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNr
KDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQtcGFp
ciDCoCDCoCDCoCDCoCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2Vk
IMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWkzODYtcGFpciDCoCDCoCDCoCDCoCDCoDEgeGVuLWJ1aWxk
LWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1k
NjQtcHYgwqAgwqAgwqAgwqAgwqAgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAg
YmxvY2tlZCDCoG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2LXhsLXdpbnhwc3AzLXZjcHVzMSDCoDEg
eGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgbi9hCj4gwqB0ZXN0LWFt
ZDY0LWkzODYteGVuZC13aW54cHNwMyDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKg
IMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQtd2luIMKgIMKgIMKgIMKgIMKg
MSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+IMKgdGVz
dC1hbWQ2NC1pMzg2LXhsLXdpbjctYW1kNjQgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWkzODYteGwtd2luLXZjcHVzMSDC
oDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRl
c3QtYW1kNjQtYW1kNjQteGwtc2VkZi1waW4gwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni1wdiDCoCDCoCDCoCDCoCDC
oCDCoCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4g
wqB0ZXN0LWFtZDY0LWkzODYteGwtY3JlZGl0MiDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtaTM4Ni14bC1tdWx0aXZj
cHUgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4g
wqB0ZXN0LWFtZDY0LWkzODYtd2luLXZjcHVzMSDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtd2lueHBz
cDMgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4g
wqB0ZXN0LWkzODYtaTM4Ni14bC13aW54cHNwMyDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtaTM4Ni13aW4gwqAgwqAg
wqAgwqAgwqAgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4v
YQo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC13aW43LWFtZDY0IMKgMSB4ZW4tYnVpbGQtY2hlY2so
MSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+IMKgdGVzdC1pMzg2LWkzODYtcGFpciDC
oCDCoCDCoCDCoCDCoCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2Vk
IMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXhsLXdpbiDCoCDCoCDCoCAxIHhlbi1idWlsZC1j
aGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni13
aW4gwqAgwqAgwqAgwqAgwqAgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBi
bG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni14bC13aW4gwqAgwqAgwqAgwqAgMSB4ZW4t
YnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+Cj4gdmVyc2lvbiB0
YXJnZXRlZCBmb3IgdGVzdGluZzoKPiDCoHhlbiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDhl
ZTgxY2VkYThjOQo+IGJhc2VsaW5lIHZlcnNpb246Cj4gwqB4ZW4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBhODhiYTU5OWFkZDEKPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFBlb3BsZSB3aG8gdG91Y2hlZCByZXZpc2lv
bnMgdW5kZXIgdGVzdDoKPiDCoEJhbXZvciBKaWFuIFpoYW5nIDxianpoYW5nQHN1c2UuY29tPgo+
IMKgR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgo+IMKgSWFuIEph
Y2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4gwqBKZWFuIEd1eWFkZXIgPGplYW4u
Z3V5YWRlckBldS5jaXRyaXguY29tPgo+IMKgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50
ZWwudXBjLmVkdT4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KPgo+IGpvYnM6Cj4gwqBidWlsZC1hbWQ2NCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGZhaWwKPiDCoGJ1aWxkLWkzODYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbAo+IMKgYnVpbGQt
YW1kNjQtb2xka2VybiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoGZhaWwKPiDCoGJ1aWxkLWkzODYtb2xka2VybiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmYWls
Cj4gwqBidWlsZC1hbWQ2NC1wdm9wcyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhc3MKPiDCoGJ1aWxkLWkzODYtcHZvcHMg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgcGFzcwo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJsb2NrZWQKPiDCoHRl
c3QtYW1kNjQtaTM4Ni14bCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWkzODYtaTM4Ni14bCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni1yaGVsNmh2bS1hbWQgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2
NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWFtZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXhsLXFlbXV1LXdpbjctYW1kNjQg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2
NC1hbWQ2NC14bC13aW43LWFtZDY0IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni14bC13aW43LWFtZDY0IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVz
dC1hbWQ2NC1pMzg2LXhsLWNyZWRpdDIgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1wY2lwdC1p
bnRlbCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJsb2NrZWQK
PiDCoHRlc3QtYW1kNjQtaTM4Ni1yaGVsNmh2bS1pbnRlbCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWkzODYtcWVtdXUt
cmhlbDZodm0taW50ZWwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tl
ZAo+IMKgdGVzdC1hbWQ2NC1pMzg2LXhsLW11bHRpdmNwdSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXBh
aXIgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWkzODYtcGFpciDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0
LWkzODYtaTM4Ni1wYWlyIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1zZWRm
LXBpbiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9j
a2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXB2IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1p
Mzg2LXB2IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQKPiDCoHRlc3QtaTM4Ni1pMzg2LXB2IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tl
ZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1zZWRmIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni13
aW4tdmNwdXMxIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni14bC13aW4tdmNwdXMxIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2
NC1pMzg2LXhsLXdpbnhwc3AzLXZjcHVzMSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXdpbiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0
ZXN0LWFtZDY0LWkzODYtd2luIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1pMzg2LWkzODYtd2luIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtd2luIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1p
Mzg2LWkzODYteGwtd2luIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS13
aW54cHNwMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4g
wqB0ZXN0LWkzODYtaTM4Ni14bC1xZW11dS13aW54cHNwMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWkzODYteGVuZC13aW54
cHNwMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJsb2Nr
ZWQKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtd2lueHBzcDMgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1pMzg2LWkzODYteGwt
d2lueHBzcDMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgYmxvY2tlZAo+Cj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBzZy1yZXBvcnQtZmxpZ2h0IG9uIHdva2luZy5jYW0ueGNp
LXRlc3QuY29tCj4gbG9nczogL2hvbWUveGNfb3NzdGVzdC9sb2dzCj4gaW1hZ2VzOiAvaG9tZS94
Y19vc3N0ZXN0L2ltYWdlcwo+Cj4gTG9ncywgY29uZmlnIGZpbGVzLCBldGMuIGFyZSBhdmFpbGFi
bGUgYXQKPiDCoCDCoGh0dHA6Ly93d3cuY2hpYXJrLmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMv
bG9ncwo+Cj4gVGVzdCBoYXJuZXNzIGNvZGUgY2FuIGJlIGZvdW5kIGF0Cj4gwqAgwqBodHRwOi8v
eGVuYml0cy54ZW5zb3VyY2UuY29tL2dpdHdlYj9wPW9zc3Rlc3QuZ2l0O2E9c3VtbWFyeQo+Cj4K
PiBOb3QgcHVzaGluZy4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IGNoYW5nZXNldDogwqAgMjQ4NjE6OGVlODFjZWRhOGM5
Cj4gdGFnOiDCoCDCoCDCoCDCoCB0aXAKPiB1c2VyOiDCoCDCoCDCoCDCoElhbiBKYWNrc29uIDxp
YW4uamFja3NvbkBldS5jaXRyaXguY29tPgo+IGRhdGU6IMKgIMKgIMKgIMKgV2VkIEZlYiAyMiAw
MTo1NTowNCAyMDEyICswMDAwCj4KPiDCoCDCoC5naXRpZ25vcmU6IGFkZCBhdXRvY29uZi1yZWxh
dGVkIGZpbGVzCj4KPiDCoCDCoFNpZ25lZC1vZmYtYnk6IElhbiBKYWNrc29uIDxpYW4uamFja3Nv
bkBldS5jaXRyaXguY29tPgo+IMKgIMKgQ29tbWl0dGVkLWJ5OiBJYW4gSmFja3NvbiA8SWFuLkph
Y2tzb25AZXUuY2l0cml4LmNvbT4KPgo+Cj4gY2hhbmdlc2V0OiDCoCAyNDg2MDphMTljNmQ5MGZk
NDEKPiB1c2VyOiDCoCDCoCDCoCDCoElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXgu
Y29tPgo+IGRhdGU6IMKgIMKgIMKgIMKgV2VkIEZlYiAyMiAwMTo1NTowMyAyMDEyICswMDAwCj4K
PiDCoCDCoGJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2tzIGluIHRv
b2xzL2NoZWNrCj4KPiDCoCDCoEFkZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBsYWNlIGN1c3Rv
bSBjaGVjayBzY3JpcHRzLiBUaGUgcHJldmlvdXMKPiDCoCDCoGNoZWNrcyBoYXZlIGJlZW4gcG9y
dGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQo+IMKgIMKgYmVl
biBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlvbnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4gVHdv
IGZpbGVzIGFyZQo+IMKgIMKgY3JlYXRlZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25m
aWd1cmUgc2NyaXB0LCBjb25maWcvVG9vbHMubWsKPiDCoCDCoGFuZCBjb25maWcuaC4KPgo+IMKg
IMKgY29uZi9Ub29scy5tayBpcyBpbmNsdWRlZCBieSB0b29scy9SdWxlcy5taywgYW5kIGNvbnRh
aW5zIG1vc3Qgb2YgdGhlCj4gwqAgwqBvcHRpb25zIHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29u
ZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcKPiDCoCDCoHBhcmFtZXRlcnMgb3IgZGVm
aW5pbmcgZW52aXJvbm1lbnQgdmFyaWFibGVzIHdoZW4gZXhlY3V0aW5nIGNvbmZpZ3VyZQo+IMKg
IMKgc2NyaXB0Lgo+Cj4gwqAgwqBjb25maWcuaCBpcyBvbmx5IHVzZWQgYnkgbGlieGwveGwgdG8g
ZGV0ZWN0IHlhamxfdmVyc2lvbi5oLgo+Cj4gwqAgwqBbIHRvb2xzL2NvbmZpZy5zdWIgYW5kIGNv
bmZpZy5ndWVzcyBjb3BpZWQgZnJvbQo+IMKgIMKgIMKgYXV0b3Rvb2xzLWRldiAyMDEwMDEyMi4x
IGZyb20gRGViaWFuIHNxdWVlemUgaTM4NiwKPiDCoCDCoCDCoHdoaWNoIGlzIEdQTHYyLgo+Cj4g
wqAgwqAgwqB0b29scy9jb25maWd1cmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBpbmNsdWRlZCAuL2F1
dG9nZW4uc2gKPiDCoCDCoCDCoHdoaWNoIHJhbiBhdXRvY29uZiAyLjY3LTIgZnJvbSBEZWJpYW4g
c3F1ZWV6ZSBpMzg2LiDCoGF1dG9jb25mCj4gwqAgwqAgwqBpcyBHUEx2MysgYnV0IGhhcyBhIHNw
ZWNpYWwgZXhjZXB0aW9uIGZvciB0aGUgYXV0b2NvbmYgb3V0cHV0Owo+IMKgIMKgIMKgdGhpcyBl
eGNlcHRpb24gYXBwbGllcyB0byB1cyBhbmQgZXhlbXB0cyB1cyBmcm9tIGNvbXBseWluZwo+IMKg
IMKgIMKgd2l0aCBHUEx2MysgZm9yIGNvbmZpZ3VyZSwgd2hpY2ggaXMgZ29vZCBhcyBYZW4gaXMg
R1BMMiBvbmx5Lgo+Cj4gwqAgwqAgwqAtIElhbiBKYWNrc29uIF0KPgo+IMKgIMKgU2lnbmVkLW9m
Zi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiDCoCDCoFRl
c3RlZC1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4gwqAgwqBD
b21taXR0ZWQtYnk6IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPgo+Cj4K
PiBjaGFuZ2VzZXQ6IMKgIDI0ODU5OjZhMzRhNDJhMmI1ZAo+IHVzZXI6IMKgIMKgIMKgIMKgQmFt
dm9yIEppYW4gWmhhbmcgPGJqemhhbmdAc3VzZS5jb20+Cj4gZGF0ZTogwqAgwqAgwqAgwqBUdWUg
RmViIDIxIDE4OjAxOjA0IDIwMTIgKzAwMDAKPgo+IMKgIMKgbGlieGw6IEV4cG9ydCBsaWJ4bF9l
dmVudC5oCj4KPiDCoCDCoFRoaXMgZml4ZXMgYSBjb21waWxlIGVycm9yIGluIGxpYnZpcnQuCj4K
PiDCoCDCoFNpZ25lZC1vZmYtYnk6IEJhbXZvciBKaWFuIFpoYW5nIDxianpoYW5nQHN1c2UuY29t
Pgo+IMKgIMKgQWNrZWQtYnk6IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29t
Pgo+IMKgIMKgQ29tbWl0dGVkLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4
LmNvbT4KPgo+Cj4gY2hhbmdlc2V0OiDCoCAyNDg1ODphODhiYTU5OWFkZDEKPiB1c2VyOiDCoCDC
oCDCoCDCoEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KPiBkYXRl
OiDCoCDCoCDCoCDCoFR1ZSBGZWIgMjEgMTc6NDU6NTkgMjAxMiArMDAwMAo+Cj4gwqAgwqBsaWJ4
bDogY2xlYW51cDogUmVtb3ZlIHBvaW50bGVzcyBFUlJOT1ZBTAo+Cj4gwqAgwqBKdXN0IGNhbGwg
TElCWExfX0xPRyByYXRoZXIgdGhhbiBwYXNzaW5nIGEgbWVhbmluZ2xlc3MgRVJSTk9WQUwuCj4K
PiDCoCDCoFNpZ25lZC1vZmYtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0
cml4LmNvbT4KPiDCoCDCoEFja2VkLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0
cml4LmNvbT4KPiDCoCDCoENvbW1pdHRlZC1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1
LmNpdHJpeC5jb20+Cj4KPgo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT0KPiBjb21taXQgMTI4ZGUyNTQ5YzVmMjRlNGE0MzdiODZiZDJlNDZmMDIzOTc2ZDUwYQo+IEF1
dGhvcjogSmVhbiBHdXlhZGVyIDxqZWFuLmd1eWFkZXJAZXUuY2l0cml4LmNvbT4KPiBEYXRlOiDC
oCBNb24gRmViIDIwIDE2OjIxOjQ3IDIwMTIgKzAwMDAKPgo+IMKgIMKgSW50ZWwgR1BVIHBhc3N0
aHJvdWdoOiBIb3N0IGJyaWRnZSBjb25maWcgc3BhY2UKPgo+IMKgIMKgRXhwb3NlIG1vcmUgaG9z
dCBicmlkZ2UgY29uZmlnIHNwYWNlIHZhbHVlIHRvIG1ha2UgdGhlIGRyaXZlciBoYXBweQo+IMKg
IMKgZm9yIGFsbCB0aGUgZGlmZmVyZW50IHJldmlzaW9ucyBvZiB0aGUgZGV2aWNlLgo+Cj4gwqAg
wqBTaWduZWQtb2ZmLWJ5OiBKZWFuIEd1eWFkZXIgPGplYW4uZ3V5YWRlckBldS5jaXRyaXguY29t
Pgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:21:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08NF-0008Qg-CV; Wed, 22 Feb 2012 09:20:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S08ND-0008QY-7T
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:20:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1329902424!14366161!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18688 invoked from network); 22 Feb 2012 09:20:24 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 09:20:24 -0000
Received: by wgbdr13 with SMTP id dr13so5734703wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 01:20:24 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr43263481wia.3.1329902424010 (num_hops
	= 1); Wed, 22 Feb 2012 01:20:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=tPx4mcnqFE0ivJ3qO/xTjxn+rD1cobCMcIXLcSGYJsc=;
	b=UmqVCLRpvuK1GT5KvYTrqXfqvUZhvWrMvx40agU7Ek57/GD19yYOohCWRUd+N0+s45
	ORzAPqJhEkTcrM4USIUrL/KBRmahniDrIicqjxxQCHrDCHIfN2ANHPeGORufVlsnaJyV
	PmrI7glmmzqndp0FDpV56XqW1a440+R7oYETs=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr35897065wia.3.1329902423811; Wed,
	22 Feb 2012 01:20:23 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 01:20:23 -0800 (PST)
In-Reply-To: <osstest-12007-mainreport@xen.org>
References: <osstest-12007-mainreport@xen.org>
Date: Wed, 22 Feb 2012 10:20:23 +0100
X-Google-Sender-Auth: kCyk2wVfjPSVVlhJD8WTi2TaT88
Message-ID: <CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "xen.org" <ian.jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IGZsaWdodCAx
MjAwNyB4ZW4tdW5zdGFibGUgcmVhbCBbcmVhbF0KPiBodHRwOi8vd3d3LmNoaWFyay5ncmVlbmVu
ZC5vcmcudWsvfnhlbnNyY3RzL2xvZ3MvMTIwMDcvCj4KPiBSZWdyZXNzaW9ucyA6LSgKPgo+IFRl
c3RzIHdoaWNoIGRpZCBub3Qgc3VjY2VlZCBhbmQgYXJlIGJsb2NraW5nLAo+IGluY2x1ZGluZyB0
ZXN0cyB3aGljaCBjb3VsZCBub3QgYmUgcnVuOgo+IMKgYnVpbGQtaTM4Ni1vbGRrZXJuIMKgIMKg
IMKgIMKgIMKgIMKgNCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdS
LiB2cy4gMTIwMDMKPiDCoGJ1aWxkLWkzODYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA0
IHhlbi1idWlsZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+
IMKgYnVpbGQtYW1kNjQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgNCB4ZW4tYnVpbGQgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiDCoGJ1aWxkLWFtZDY0
LW9sZGtlcm4gwqAgwqAgwqAgwqAgwqAgNCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKCgpicmN0bCBpcyBub3QgaW5zdGFsbGVkLCBvciB0aGUg
dXNlciB0aGF0IGlzIHRyeWluZyB0byBidWlsZCBYZW4KZG9lc24ndCBoYXZlIHBlcm1pc3Npb25z
IHRvIHJ1biBpdC4gSSd2ZSBmb3VuZCB0aGlzIHRlc3QgcXVpdGUKdXNlbGVzcywgYmVjYXVzZSB5
b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgWGVuIGFzIGEgcmVndWxhciB1c2VyLAp0aGF0IGRv
ZXNuJ3QgaGF2ZSBhY2Nlc3MgdG8gYnJjdGwsIGRvIHlvdSB3YW50IG1lIHRvIHNlbmQgYSBwYXRj
aCB0aGF0CnJlbW92ZXMgdGhpcyBjaGVjaz8KCj4gVGVzdHMgd2hpY2ggZGlkIG5vdCBzdWNjZWVk
LCBidXQgYXJlIG5vdCBibG9ja2luZzoKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtcWVtdXUtd2lu
eHBzcDMgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIG4vYQo+
IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS13aW43LWFtZDY0IMKgMSB4ZW4tYnVpbGQtY2hl
Y2soMSkgwqAgwqAgwqAgwqAgYmxvY2tlZCBuL2EKPiDCoHRlc3QtaTM4Ni1pMzg2LXhsLXFlbXV1
LXdpbnhwc3AzIMKgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDC
oG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWludGVsIMKgMSB4ZW4tYnVp
bGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgYmxvY2tlZCBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQt
eGwtcGNpcHQtaW50ZWwgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9j
a2VkIMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWkzODYtcmhlbDZodm0tYW1kIMKgMSB4ZW4tYnVpbGQt
Y2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2
LXJoZWw2aHZtLWludGVsIMKgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxv
Y2tlZCDCoG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWFtZCDCoDEgeGVu
LWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgbi9hCj4gwqB0ZXN0LWFtZDY0
LWkzODYtcHYgwqAgwqAgwqAgwqAgwqAgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDC
oCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni14bCDCoCDCoCDCoCDCoCDCoCDC
oCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0
ZXN0LWFtZDY0LWkzODYteGwgwqAgwqAgwqAgwqAgwqAgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDC
oCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXhsIMKgIMKg
IMKgIMKgIMKgIDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBu
L2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtc2VkZiDCoCDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNr
KDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQtcGFp
ciDCoCDCoCDCoCDCoCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2Vk
IMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWkzODYtcGFpciDCoCDCoCDCoCDCoCDCoDEgeGVuLWJ1aWxk
LWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1k
NjQtcHYgwqAgwqAgwqAgwqAgwqAgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAg
YmxvY2tlZCDCoG4vYQo+IMKgdGVzdC1hbWQ2NC1pMzg2LXhsLXdpbnhwc3AzLXZjcHVzMSDCoDEg
eGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgbi9hCj4gwqB0ZXN0LWFt
ZDY0LWkzODYteGVuZC13aW54cHNwMyDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKg
IMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQtd2luIMKgIMKgIMKgIMKgIMKg
MSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+IMKgdGVz
dC1hbWQ2NC1pMzg2LXhsLXdpbjctYW1kNjQgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWkzODYteGwtd2luLXZjcHVzMSDC
oDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRl
c3QtYW1kNjQtYW1kNjQteGwtc2VkZi1waW4gwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni1wdiDCoCDCoCDCoCDCoCDC
oCDCoCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4g
wqB0ZXN0LWFtZDY0LWkzODYteGwtY3JlZGl0MiDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtaTM4Ni14bC1tdWx0aXZj
cHUgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4g
wqB0ZXN0LWFtZDY0LWkzODYtd2luLXZjcHVzMSDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtd2lueHBz
cDMgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4g
wqB0ZXN0LWkzODYtaTM4Ni14bC13aW54cHNwMyDCoCDCoDEgeGVuLWJ1aWxkLWNoZWNrKDEpIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQgwqBuL2EKPiDCoHRlc3QtYW1kNjQtaTM4Ni13aW4gwqAgwqAg
wqAgwqAgwqAgMSB4ZW4tYnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4v
YQo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC13aW43LWFtZDY0IMKgMSB4ZW4tYnVpbGQtY2hlY2so
MSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+IMKgdGVzdC1pMzg2LWkzODYtcGFpciDC
oCDCoCDCoCDCoCDCoCAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2Vk
IMKgbi9hCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXhsLXdpbiDCoCDCoCDCoCAxIHhlbi1idWlsZC1j
aGVjaygxKSDCoCDCoCDCoCDCoCDCoCBibG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni13
aW4gwqAgwqAgwqAgwqAgwqAgwqAxIHhlbi1idWlsZC1jaGVjaygxKSDCoCDCoCDCoCDCoCDCoCBi
bG9ja2VkIMKgbi9hCj4gwqB0ZXN0LWkzODYtaTM4Ni14bC13aW4gwqAgwqAgwqAgwqAgMSB4ZW4t
YnVpbGQtY2hlY2soMSkgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZCDCoG4vYQo+Cj4gdmVyc2lvbiB0
YXJnZXRlZCBmb3IgdGVzdGluZzoKPiDCoHhlbiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDhl
ZTgxY2VkYThjOQo+IGJhc2VsaW5lIHZlcnNpb246Cj4gwqB4ZW4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBhODhiYTU5OWFkZDEKPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFBlb3BsZSB3aG8gdG91Y2hlZCByZXZpc2lv
bnMgdW5kZXIgdGVzdDoKPiDCoEJhbXZvciBKaWFuIFpoYW5nIDxianpoYW5nQHN1c2UuY29tPgo+
IMKgR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgo+IMKgSWFuIEph
Y2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4gwqBKZWFuIEd1eWFkZXIgPGplYW4u
Z3V5YWRlckBldS5jaXRyaXguY29tPgo+IMKgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50
ZWwudXBjLmVkdT4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KPgo+IGpvYnM6Cj4gwqBidWlsZC1hbWQ2NCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGZhaWwKPiDCoGJ1aWxkLWkzODYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbAo+IMKgYnVpbGQt
YW1kNjQtb2xka2VybiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoGZhaWwKPiDCoGJ1aWxkLWkzODYtb2xka2VybiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmYWls
Cj4gwqBidWlsZC1hbWQ2NC1wdm9wcyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhc3MKPiDCoGJ1aWxkLWkzODYtcHZvcHMg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgcGFzcwo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJsb2NrZWQKPiDCoHRl
c3QtYW1kNjQtaTM4Ni14bCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWkzODYtaTM4Ni14bCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni1yaGVsNmh2bS1hbWQgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2
NC1pMzg2LXFlbXV1LXJoZWw2aHZtLWFtZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXhsLXFlbXV1LXdpbjctYW1kNjQg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2
NC1hbWQ2NC14bC13aW43LWFtZDY0IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni14bC13aW43LWFtZDY0IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVz
dC1hbWQ2NC1pMzg2LXhsLWNyZWRpdDIgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1wY2lwdC1p
bnRlbCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJsb2NrZWQK
PiDCoHRlc3QtYW1kNjQtaTM4Ni1yaGVsNmh2bS1pbnRlbCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWkzODYtcWVtdXUt
cmhlbDZodm0taW50ZWwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tl
ZAo+IMKgdGVzdC1hbWQ2NC1pMzg2LXhsLW11bHRpdmNwdSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXBh
aXIgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWkzODYtcGFpciDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0
LWkzODYtaTM4Ni1wYWlyIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1zZWRm
LXBpbiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9j
a2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXB2IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1p
Mzg2LXB2IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIGJsb2NrZWQKPiDCoHRlc3QtaTM4Ni1pMzg2LXB2IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tl
ZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1zZWRmIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni13
aW4tdmNwdXMxIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtaTM4Ni14bC13aW4tdmNwdXMxIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2
NC1pMzg2LXhsLXdpbnhwc3AzLXZjcHVzMSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWFtZDY0LXdpbiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0
ZXN0LWFtZDY0LWkzODYtd2luIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1pMzg2LWkzODYtd2luIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGJsb2NrZWQKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtd2luIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1p
Mzg2LWkzODYteGwtd2luIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgYmxvY2tlZAo+IMKgdGVzdC1hbWQ2NC1hbWQ2NC14bC1xZW11dS13
aW54cHNwMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4g
wqB0ZXN0LWkzODYtaTM4Ni14bC1xZW11dS13aW54cHNwMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCBibG9ja2VkCj4gwqB0ZXN0LWFtZDY0LWkzODYteGVuZC13aW54
cHNwMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJsb2Nr
ZWQKPiDCoHRlc3QtYW1kNjQtYW1kNjQteGwtd2lueHBzcDMgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmxvY2tlZAo+IMKgdGVzdC1pMzg2LWkzODYteGwt
d2lueHBzcDMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgYmxvY2tlZAo+Cj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBzZy1yZXBvcnQtZmxpZ2h0IG9uIHdva2luZy5jYW0ueGNp
LXRlc3QuY29tCj4gbG9nczogL2hvbWUveGNfb3NzdGVzdC9sb2dzCj4gaW1hZ2VzOiAvaG9tZS94
Y19vc3N0ZXN0L2ltYWdlcwo+Cj4gTG9ncywgY29uZmlnIGZpbGVzLCBldGMuIGFyZSBhdmFpbGFi
bGUgYXQKPiDCoCDCoGh0dHA6Ly93d3cuY2hpYXJrLmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMv
bG9ncwo+Cj4gVGVzdCBoYXJuZXNzIGNvZGUgY2FuIGJlIGZvdW5kIGF0Cj4gwqAgwqBodHRwOi8v
eGVuYml0cy54ZW5zb3VyY2UuY29tL2dpdHdlYj9wPW9zc3Rlc3QuZ2l0O2E9c3VtbWFyeQo+Cj4K
PiBOb3QgcHVzaGluZy4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IGNoYW5nZXNldDogwqAgMjQ4NjE6OGVlODFjZWRhOGM5
Cj4gdGFnOiDCoCDCoCDCoCDCoCB0aXAKPiB1c2VyOiDCoCDCoCDCoCDCoElhbiBKYWNrc29uIDxp
YW4uamFja3NvbkBldS5jaXRyaXguY29tPgo+IGRhdGU6IMKgIMKgIMKgIMKgV2VkIEZlYiAyMiAw
MTo1NTowNCAyMDEyICswMDAwCj4KPiDCoCDCoC5naXRpZ25vcmU6IGFkZCBhdXRvY29uZi1yZWxh
dGVkIGZpbGVzCj4KPiDCoCDCoFNpZ25lZC1vZmYtYnk6IElhbiBKYWNrc29uIDxpYW4uamFja3Nv
bkBldS5jaXRyaXguY29tPgo+IMKgIMKgQ29tbWl0dGVkLWJ5OiBJYW4gSmFja3NvbiA8SWFuLkph
Y2tzb25AZXUuY2l0cml4LmNvbT4KPgo+Cj4gY2hhbmdlc2V0OiDCoCAyNDg2MDphMTljNmQ5MGZk
NDEKPiB1c2VyOiDCoCDCoCDCoCDCoElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXgu
Y29tPgo+IGRhdGU6IMKgIMKgIMKgIMKgV2VkIEZlYiAyMiAwMTo1NTowMyAyMDEyICswMDAwCj4K
PiDCoCDCoGJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2tzIGluIHRv
b2xzL2NoZWNrCj4KPiDCoCDCoEFkZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBsYWNlIGN1c3Rv
bSBjaGVjayBzY3JpcHRzLiBUaGUgcHJldmlvdXMKPiDCoCDCoGNoZWNrcyBoYXZlIGJlZW4gcG9y
dGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQo+IMKgIMKgYmVl
biBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlvbnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4gVHdv
IGZpbGVzIGFyZQo+IMKgIMKgY3JlYXRlZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25m
aWd1cmUgc2NyaXB0LCBjb25maWcvVG9vbHMubWsKPiDCoCDCoGFuZCBjb25maWcuaC4KPgo+IMKg
IMKgY29uZi9Ub29scy5tayBpcyBpbmNsdWRlZCBieSB0b29scy9SdWxlcy5taywgYW5kIGNvbnRh
aW5zIG1vc3Qgb2YgdGhlCj4gwqAgwqBvcHRpb25zIHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29u
ZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3NpbmcKPiDCoCDCoHBhcmFtZXRlcnMgb3IgZGVm
aW5pbmcgZW52aXJvbm1lbnQgdmFyaWFibGVzIHdoZW4gZXhlY3V0aW5nIGNvbmZpZ3VyZQo+IMKg
IMKgc2NyaXB0Lgo+Cj4gwqAgwqBjb25maWcuaCBpcyBvbmx5IHVzZWQgYnkgbGlieGwveGwgdG8g
ZGV0ZWN0IHlhamxfdmVyc2lvbi5oLgo+Cj4gwqAgwqBbIHRvb2xzL2NvbmZpZy5zdWIgYW5kIGNv
bmZpZy5ndWVzcyBjb3BpZWQgZnJvbQo+IMKgIMKgIMKgYXV0b3Rvb2xzLWRldiAyMDEwMDEyMi4x
IGZyb20gRGViaWFuIHNxdWVlemUgaTM4NiwKPiDCoCDCoCDCoHdoaWNoIGlzIEdQTHYyLgo+Cj4g
wqAgwqAgwqB0b29scy9jb25maWd1cmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBpbmNsdWRlZCAuL2F1
dG9nZW4uc2gKPiDCoCDCoCDCoHdoaWNoIHJhbiBhdXRvY29uZiAyLjY3LTIgZnJvbSBEZWJpYW4g
c3F1ZWV6ZSBpMzg2LiDCoGF1dG9jb25mCj4gwqAgwqAgwqBpcyBHUEx2MysgYnV0IGhhcyBhIHNw
ZWNpYWwgZXhjZXB0aW9uIGZvciB0aGUgYXV0b2NvbmYgb3V0cHV0Owo+IMKgIMKgIMKgdGhpcyBl
eGNlcHRpb24gYXBwbGllcyB0byB1cyBhbmQgZXhlbXB0cyB1cyBmcm9tIGNvbXBseWluZwo+IMKg
IMKgIMKgd2l0aCBHUEx2MysgZm9yIGNvbmZpZ3VyZSwgd2hpY2ggaXMgZ29vZCBhcyBYZW4gaXMg
R1BMMiBvbmx5Lgo+Cj4gwqAgwqAgwqAtIElhbiBKYWNrc29uIF0KPgo+IMKgIMKgU2lnbmVkLW9m
Zi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiDCoCDCoFRl
c3RlZC1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Cj4gwqAgwqBD
b21taXR0ZWQtYnk6IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPgo+Cj4K
PiBjaGFuZ2VzZXQ6IMKgIDI0ODU5OjZhMzRhNDJhMmI1ZAo+IHVzZXI6IMKgIMKgIMKgIMKgQmFt
dm9yIEppYW4gWmhhbmcgPGJqemhhbmdAc3VzZS5jb20+Cj4gZGF0ZTogwqAgwqAgwqAgwqBUdWUg
RmViIDIxIDE4OjAxOjA0IDIwMTIgKzAwMDAKPgo+IMKgIMKgbGlieGw6IEV4cG9ydCBsaWJ4bF9l
dmVudC5oCj4KPiDCoCDCoFRoaXMgZml4ZXMgYSBjb21waWxlIGVycm9yIGluIGxpYnZpcnQuCj4K
PiDCoCDCoFNpZ25lZC1vZmYtYnk6IEJhbXZvciBKaWFuIFpoYW5nIDxianpoYW5nQHN1c2UuY29t
Pgo+IMKgIMKgQWNrZWQtYnk6IElhbiBKYWNrc29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29t
Pgo+IMKgIMKgQ29tbWl0dGVkLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4
LmNvbT4KPgo+Cj4gY2hhbmdlc2V0OiDCoCAyNDg1ODphODhiYTU5OWFkZDEKPiB1c2VyOiDCoCDC
oCDCoCDCoEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KPiBkYXRl
OiDCoCDCoCDCoCDCoFR1ZSBGZWIgMjEgMTc6NDU6NTkgMjAxMiArMDAwMAo+Cj4gwqAgwqBsaWJ4
bDogY2xlYW51cDogUmVtb3ZlIHBvaW50bGVzcyBFUlJOT1ZBTAo+Cj4gwqAgwqBKdXN0IGNhbGwg
TElCWExfX0xPRyByYXRoZXIgdGhhbiBwYXNzaW5nIGEgbWVhbmluZ2xlc3MgRVJSTk9WQUwuCj4K
PiDCoCDCoFNpZ25lZC1vZmYtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0
cml4LmNvbT4KPiDCoCDCoEFja2VkLWJ5OiBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0
cml4LmNvbT4KPiDCoCDCoENvbW1pdHRlZC1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1
LmNpdHJpeC5jb20+Cj4KPgo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT0KPiBjb21taXQgMTI4ZGUyNTQ5YzVmMjRlNGE0MzdiODZiZDJlNDZmMDIzOTc2ZDUwYQo+IEF1
dGhvcjogSmVhbiBHdXlhZGVyIDxqZWFuLmd1eWFkZXJAZXUuY2l0cml4LmNvbT4KPiBEYXRlOiDC
oCBNb24gRmViIDIwIDE2OjIxOjQ3IDIwMTIgKzAwMDAKPgo+IMKgIMKgSW50ZWwgR1BVIHBhc3N0
aHJvdWdoOiBIb3N0IGJyaWRnZSBjb25maWcgc3BhY2UKPgo+IMKgIMKgRXhwb3NlIG1vcmUgaG9z
dCBicmlkZ2UgY29uZmlnIHNwYWNlIHZhbHVlIHRvIG1ha2UgdGhlIGRyaXZlciBoYXBweQo+IMKg
IMKgZm9yIGFsbCB0aGUgZGlmZmVyZW50IHJldmlzaW9ucyBvZiB0aGUgZGV2aWNlLgo+Cj4gwqAg
wqBTaWduZWQtb2ZmLWJ5OiBKZWFuIEd1eWFkZXIgPGplYW4uZ3V5YWRlckBldS5jaXRyaXguY29t
Pgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:55:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08uh-0000Pf-FW; Wed, 22 Feb 2012 09:55:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S08uf-0000Pa-5E
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329904498!14395549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29742 invoked from network); 22 Feb 2012 09:54:58 -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;
	22 Feb 2012 09:54:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10864153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 09:54:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 09:54:57 +0000
Message-ID: <1329904496.2880.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 22 Feb 2012 09:54:56 +0000
In-Reply-To: <CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTIyIGF0IDA5OjIwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yMiB4ZW4ub3JnIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPjoKPiA+IGZs
aWdodCAxMjAwNyB4ZW4tdW5zdGFibGUgcmVhbCBbcmVhbF0KPiA+IGh0dHA6Ly93d3cuY2hpYXJr
LmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMvbG9ncy8xMjAwNy8KPiA+Cj4gPiBSZWdyZXNzaW9u
cyA6LSgKPiA+Cj4gPiBUZXN0cyB3aGljaCBkaWQgbm90IHN1Y2NlZWQgYW5kIGFyZSBibG9ja2lu
ZywKPiA+IGluY2x1ZGluZyB0ZXN0cyB3aGljaCBjb3VsZCBub3QgYmUgcnVuOgo+ID4gIGJ1aWxk
LWkzODYtb2xka2VybiAgICAgICAgICAgIDQgeGVuLWJ1aWxkICAgICAgICAgICAgICAgICBmYWls
IFJFR1IuIHZzLiAxMjAwMwo+ID4gIGJ1aWxkLWkzODYgICAgICAgICAgICAgICAgICAgIDQgeGVu
LWJ1aWxkICAgICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+ID4gIGJ1aWxkLWFt
ZDY0ICAgICAgICAgICAgICAgICAgIDQgeGVuLWJ1aWxkICAgICAgICAgICAgICAgICBmYWlsIFJF
R1IuIHZzLiAxMjAwMwo+ID4gIGJ1aWxkLWFtZDY0LW9sZGtlcm4gICAgICAgICAgIDQgeGVuLWJ1
aWxkICAgICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+IAo+IAo+IGJyY3RsIGlz
IG5vdCBpbnN0YWxsZWQsIG9yIHRoZSB1c2VyIHRoYXQgaXMgdHJ5aW5nIHRvIGJ1aWxkIFhlbgo+
IGRvZXNuJ3QgaGF2ZSBwZXJtaXNzaW9ucyB0byBydW4gaXQuIEkndmUgZm91bmQgdGhpcyB0ZXN0
IHF1aXRlCj4gdXNlbGVzcywgYmVjYXVzZSB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgWGVu
IGFzIGEgcmVndWxhciB1c2VyLAo+IHRoYXQgZG9lc24ndCBoYXZlIGFjY2VzcyB0byBicmN0bCwg
ZG8geW91IHdhbnQgbWUgdG8gc2VuZCBhIHBhdGNoIHRoYXQKPiByZW1vdmVzIHRoaXMgY2hlY2s/
CgpJIGJ1aWxkIFhlbiBvbiBhIG1hY2hpbmUgd2hpY2ggZG9lc24ndCBhY3R1YWxseSBydW4gWGVu
IGFuZCB0aGVyZWZvcmUKZG9lc24ndCBoYXZlIGJyY3RsIGluc3RhbGxlZCwgSSBkb24ndCB0aGlu
ayB0aGlzIGlzIHVucmVhc29uYWJsZSBzaW5jZQpicmN0bCBpcyBhIHJ1bnRpbWUgbm90IGNvbXBp
bGUtdGltZSBkZXBlbmRlbmN5LgoKSSB0aGluayB3ZSBzaG91bGQgcmVtb3ZlIHRoZSB0ZXN0IGZy
b20gY29uZmlndXJlIC0tIGFsdGhvdWdoIGl0IGRvZXMKbWFrZSBtZSB3b25kZXIgKHBlcmhhcHMg
dG9vIGxhdGUpIGlmIHdlIHNob3VsZG4ndCBoYXZlIGtlcHQgdGhlIGV4aXN0aW5nCmluc3RhbGwg
dGltZSBjaGVja3MuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:55:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08uh-0000Pf-FW; Wed, 22 Feb 2012 09:55:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S08uf-0000Pa-5E
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329904498!14395549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29742 invoked from network); 22 Feb 2012 09:54:58 -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;
	22 Feb 2012 09:54:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10864153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 09:54:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 09:54:57 +0000
Message-ID: <1329904496.2880.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 22 Feb 2012 09:54:56 +0000
In-Reply-To: <CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTIyIGF0IDA5OjIwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yMiB4ZW4ub3JnIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPjoKPiA+IGZs
aWdodCAxMjAwNyB4ZW4tdW5zdGFibGUgcmVhbCBbcmVhbF0KPiA+IGh0dHA6Ly93d3cuY2hpYXJr
LmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMvbG9ncy8xMjAwNy8KPiA+Cj4gPiBSZWdyZXNzaW9u
cyA6LSgKPiA+Cj4gPiBUZXN0cyB3aGljaCBkaWQgbm90IHN1Y2NlZWQgYW5kIGFyZSBibG9ja2lu
ZywKPiA+IGluY2x1ZGluZyB0ZXN0cyB3aGljaCBjb3VsZCBub3QgYmUgcnVuOgo+ID4gIGJ1aWxk
LWkzODYtb2xka2VybiAgICAgICAgICAgIDQgeGVuLWJ1aWxkICAgICAgICAgICAgICAgICBmYWls
IFJFR1IuIHZzLiAxMjAwMwo+ID4gIGJ1aWxkLWkzODYgICAgICAgICAgICAgICAgICAgIDQgeGVu
LWJ1aWxkICAgICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+ID4gIGJ1aWxkLWFt
ZDY0ICAgICAgICAgICAgICAgICAgIDQgeGVuLWJ1aWxkICAgICAgICAgICAgICAgICBmYWlsIFJF
R1IuIHZzLiAxMjAwMwo+ID4gIGJ1aWxkLWFtZDY0LW9sZGtlcm4gICAgICAgICAgIDQgeGVuLWJ1
aWxkICAgICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+IAo+IAo+IGJyY3RsIGlz
IG5vdCBpbnN0YWxsZWQsIG9yIHRoZSB1c2VyIHRoYXQgaXMgdHJ5aW5nIHRvIGJ1aWxkIFhlbgo+
IGRvZXNuJ3QgaGF2ZSBwZXJtaXNzaW9ucyB0byBydW4gaXQuIEkndmUgZm91bmQgdGhpcyB0ZXN0
IHF1aXRlCj4gdXNlbGVzcywgYmVjYXVzZSB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgWGVu
IGFzIGEgcmVndWxhciB1c2VyLAo+IHRoYXQgZG9lc24ndCBoYXZlIGFjY2VzcyB0byBicmN0bCwg
ZG8geW91IHdhbnQgbWUgdG8gc2VuZCBhIHBhdGNoIHRoYXQKPiByZW1vdmVzIHRoaXMgY2hlY2s/
CgpJIGJ1aWxkIFhlbiBvbiBhIG1hY2hpbmUgd2hpY2ggZG9lc24ndCBhY3R1YWxseSBydW4gWGVu
IGFuZCB0aGVyZWZvcmUKZG9lc24ndCBoYXZlIGJyY3RsIGluc3RhbGxlZCwgSSBkb24ndCB0aGlu
ayB0aGlzIGlzIHVucmVhc29uYWJsZSBzaW5jZQpicmN0bCBpcyBhIHJ1bnRpbWUgbm90IGNvbXBp
bGUtdGltZSBkZXBlbmRlbmN5LgoKSSB0aGluayB3ZSBzaG91bGQgcmVtb3ZlIHRoZSB0ZXN0IGZy
b20gY29uZmlndXJlIC0tIGFsdGhvdWdoIGl0IGRvZXMKbWFrZSBtZSB3b25kZXIgKHBlcmhhcHMg
dG9vIGxhdGUpIGlmIHdlIHNob3VsZG4ndCBoYXZlIGtlcHQgdGhlIGV4aXN0aW5nCmluc3RhbGwg
dGltZSBjaGVja3MuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:56:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08vo-0000SV-Ue; Wed, 22 Feb 2012 09:56:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S08vn-0000SN-LM
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 09:56:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329904522!55259981!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31109 invoked from network); 22 Feb 2012 09:55:22 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 09:55:22 -0000
Received: by wibhi20 with SMTP id hi20so4226833wib.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 01:56:14 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr41969475wib.3.1329904574255 (num_hops
	= 1); Wed, 22 Feb 2012 01:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=u62farwqq/g2pvQa8lxH8CU04nzd7fEGxoFJ9lu/J00=;
	b=Px5t3H8EQQYp+lxCr6jMRaELCe9fgkCkPUuadLifZ0dacuRuK+7HBwjS8iWDntsyHV
	w235k6sHBLfaw2Td3FEJYbddkjK4zfAx41RJoP3VHZaXme/tUGGE3i5kQoXOkJE3qkSe
	SQCF4iKxHf00SVVTADKqyHt1xnMvVErx9So8g=
Received: by 10.180.92.71 with SMTP id ck7mr34730570wib.3.1329904574178;
	Wed, 22 Feb 2012 01:56:14 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id y1sm68888854wiw.6.2012.02.22.01.56.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 01:56:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0ab0491f2819fc8440da323d1bb0fa5534450b35
Message-Id: <0ab0491f2819fc8440da.1329801792@build.localdomain>
In-Reply-To: <osstest-12007-mainreport@xen.org>
References: <osstest-12007-mainreport@xen.org>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 06:23:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] autoconf: remove brctl 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329801384 -3600
# Node ID 0ab0491f2819fc8440da323d1bb0fa5534450b35
# Parent  c2f0820e48ae9cf0735c5ef81e6a6796f3d42e5a
autoconf: remove brctl check

Remove brctl check since it's usually only available to users with
high privileges, but Xen should be buildable by regular users.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c2f0820e48ae -r 0ab0491f2819 tools/configure.ac
--- a/tools/configure.ac	Tue Feb 21 04:18:29 2012 +0100
+++ b/tools/configure.ac	Tue Feb 21 06:16:24 2012 +0100
@@ -79,7 +79,6 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
-AX_PATH_PROG_OR_FAIL([BRCTL], [brctl])
 AX_PATH_PROG_OR_FAIL([IP], [ip])
 AX_PATH_PROG_OR_FAIL([BISON], [bison])
 AX_PATH_PROG_OR_FAIL([FLEX], [flex])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:56:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:56:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08vo-0000SV-Ue; Wed, 22 Feb 2012 09:56:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S08vn-0000SN-LM
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 09:56:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329904522!55259981!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31109 invoked from network); 22 Feb 2012 09:55:22 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 09:55:22 -0000
Received: by wibhi20 with SMTP id hi20so4226833wib.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 01:56:14 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr41969475wib.3.1329904574255 (num_hops
	= 1); Wed, 22 Feb 2012 01:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=u62farwqq/g2pvQa8lxH8CU04nzd7fEGxoFJ9lu/J00=;
	b=Px5t3H8EQQYp+lxCr6jMRaELCe9fgkCkPUuadLifZ0dacuRuK+7HBwjS8iWDntsyHV
	w235k6sHBLfaw2Td3FEJYbddkjK4zfAx41RJoP3VHZaXme/tUGGE3i5kQoXOkJE3qkSe
	SQCF4iKxHf00SVVTADKqyHt1xnMvVErx9So8g=
Received: by 10.180.92.71 with SMTP id ck7mr34730570wib.3.1329904574178;
	Wed, 22 Feb 2012 01:56:14 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id y1sm68888854wiw.6.2012.02.22.01.56.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 01:56:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0ab0491f2819fc8440da323d1bb0fa5534450b35
Message-Id: <0ab0491f2819fc8440da.1329801792@build.localdomain>
In-Reply-To: <osstest-12007-mainreport@xen.org>
References: <osstest-12007-mainreport@xen.org>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 06:23:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] autoconf: remove brctl 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329801384 -3600
# Node ID 0ab0491f2819fc8440da323d1bb0fa5534450b35
# Parent  c2f0820e48ae9cf0735c5ef81e6a6796f3d42e5a
autoconf: remove brctl check

Remove brctl check since it's usually only available to users with
high privileges, but Xen should be buildable by regular users.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c2f0820e48ae -r 0ab0491f2819 tools/configure.ac
--- a/tools/configure.ac	Tue Feb 21 04:18:29 2012 +0100
+++ b/tools/configure.ac	Tue Feb 21 06:16:24 2012 +0100
@@ -79,7 +79,6 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
-AX_PATH_PROG_OR_FAIL([BRCTL], [brctl])
 AX_PATH_PROG_OR_FAIL([IP], [ip])
 AX_PATH_PROG_OR_FAIL([BISON], [bison])
 AX_PATH_PROG_OR_FAIL([FLEX], [flex])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:57:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08wz-0000YA-FT; Wed, 22 Feb 2012 09:57:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1S08wy-0000XY-8u
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:57:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329904641!15892052!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18758 invoked from network); 22 Feb 2012 09:57:22 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 09:57:22 -0000
Received: from mail114-am1-R.bigfish.com (10.3.201.238) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 09:57:16 +0000
Received: from mail114-am1 (localhost [127.0.0.1])	by
	mail114-am1-R.bigfish.com (Postfix) with ESMTP id F1EB440170	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 09:57:15 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail114-am1 (localhost.localdomain [127.0.0.1]) by mail114-am1
	(MessageSwitch) id 1329904634143007_1498;
	Wed, 22 Feb 2012 09:57:14 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.228])	by
	mail114-am1.bigfish.com (Postfix) with ESMTP id 15C982005F	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 09:57:14 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 09:57:13 +0000
X-WSS-ID: 0LZSGZF-02-7L6-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 28641C80B9	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 03:57:14 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 22 Feb 2012 03:57:27 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 22 Feb 2012 03:57:16 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	04:57:16 -0500
Message-ID: <4F44BBFA.6070403@amd.com>
Date: Wed, 22 Feb 2012 10:57:14 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

configure fails on NetBSD that there is no brctl.
NetBSD has no brctl, NetBSD has brconfig.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 09:57:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 09:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S08wz-0000YA-FT; Wed, 22 Feb 2012 09:57:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1S08wy-0000XY-8u
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:57:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329904641!15892052!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18758 invoked from network); 22 Feb 2012 09:57:22 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 09:57:22 -0000
Received: from mail114-am1-R.bigfish.com (10.3.201.238) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 09:57:16 +0000
Received: from mail114-am1 (localhost [127.0.0.1])	by
	mail114-am1-R.bigfish.com (Postfix) with ESMTP id F1EB440170	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 09:57:15 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail114-am1 (localhost.localdomain [127.0.0.1]) by mail114-am1
	(MessageSwitch) id 1329904634143007_1498;
	Wed, 22 Feb 2012 09:57:14 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.228])	by
	mail114-am1.bigfish.com (Postfix) with ESMTP id 15C982005F	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 09:57:14 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 09:57:13 +0000
X-WSS-ID: 0LZSGZF-02-7L6-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 28641C80B9	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 03:57:14 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 22 Feb 2012 03:57:27 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 22 Feb 2012 03:57:16 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	04:57:16 -0500
Message-ID: <4F44BBFA.6070403@amd.com>
Date: Wed, 22 Feb 2012 10:57:14 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

configure fails on NetBSD that there is no brctl.
NetBSD has no brctl, NetBSD has brconfig.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:00:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S08zN-0000kF-1M; Wed, 22 Feb 2012 09:59:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S08zL-0000jX-0L
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:59:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329904788!14341528!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27491 invoked from network); 22 Feb 2012 09:59:49 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 09:59:49 -0000
Received: by werb14 with SMTP id b14so16851461wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 01:59:48 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr8558341wei.42.1329904788764
	(num_hops = 1); Wed, 22 Feb 2012 01:59:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ra7qSPmXyA/jCB+TYjhcJb3LNxLOz58dZxPjgj7mDq4=;
	b=nu0M3vSg7mYOTquWeY0l1vqAdr1Ikvs935WKUT0ZkpPZ/cwZF4V6nSQYPOfcOJtjEm
	tnwF068xwDlJ0yImNDOmoFnCQeHXgGEleY5HeuYKKKDRdjTitcG0AKXrsvFr55GRDy4d
	RYv4wT4oKmjvGeVJdCrkE4Kz7LtGTuCsSrQHs=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr7070098wei.42.1329904788597; Wed,
	22 Feb 2012 01:59:48 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 01:59:48 -0800 (PST)
In-Reply-To: <4F44BBFA.6070403@amd.com>
References: <4F44BBFA.6070403@amd.com>
Date: Wed, 22 Feb 2012 10:59:48 +0100
X-Google-Sender-Auth: o3myxqmANZuf4cSjMgVAyN_dgFc
Message-ID: <CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/22 Christoph Egger <Christoph.Egger@amd.com>:
>
> Hi,
>
> configure fails on NetBSD that there is no brctl.
> NetBSD has no brctl, NetBSD has brconfig.

Sorry Christoph, the brctl test is going away (from configure at least).

>
> Christoph
>
> --
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:00:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S08zN-0000kF-1M; Wed, 22 Feb 2012 09:59:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S08zL-0000jX-0L
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 09:59:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1329904788!14341528!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27491 invoked from network); 22 Feb 2012 09:59:49 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 09:59:49 -0000
Received: by werb14 with SMTP id b14so16851461wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 01:59:48 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr8558341wei.42.1329904788764
	(num_hops = 1); Wed, 22 Feb 2012 01:59:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ra7qSPmXyA/jCB+TYjhcJb3LNxLOz58dZxPjgj7mDq4=;
	b=nu0M3vSg7mYOTquWeY0l1vqAdr1Ikvs935WKUT0ZkpPZ/cwZF4V6nSQYPOfcOJtjEm
	tnwF068xwDlJ0yImNDOmoFnCQeHXgGEleY5HeuYKKKDRdjTitcG0AKXrsvFr55GRDy4d
	RYv4wT4oKmjvGeVJdCrkE4Kz7LtGTuCsSrQHs=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr7070098wei.42.1329904788597; Wed,
	22 Feb 2012 01:59:48 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 01:59:48 -0800 (PST)
In-Reply-To: <4F44BBFA.6070403@amd.com>
References: <4F44BBFA.6070403@amd.com>
Date: Wed, 22 Feb 2012 10:59:48 +0100
X-Google-Sender-Auth: o3myxqmANZuf4cSjMgVAyN_dgFc
Message-ID: <CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/22 Christoph Egger <Christoph.Egger@amd.com>:
>
> Hi,
>
> configure fails on NetBSD that there is no brctl.
> NetBSD has no brctl, NetBSD has brconfig.

Sorry Christoph, the brctl test is going away (from configure at least).

>
> Christoph
>
> --
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:04:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S093f-000132-Of; Wed, 22 Feb 2012 10:04:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S093e-00012d-UQ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:04:23 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329905055!1999699!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30580 invoked from network); 22 Feb 2012 10:04:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 10:04:16 -0000
Received: by wgbdr13 with SMTP id dr13so5770759wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 02:04:15 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr42049535wib.3.1329905055156 (num_hops
	= 1); Wed, 22 Feb 2012 02:04:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=n0XzemjtzcDGEKttXDQv+eWlytNsEwBrrD+hkl732CA=;
	b=dS2Sx8VG1sb4aTADSsrGj5pdZTDU7FbrSiPnjFrUKuYVlItk/zigTVy5fBjlSEHYaa
	W5InqGlCTNuAWAb+gAOtBmtvqvbSUKl0YOP1ecDh+hx6DnwzUV8TVZ9+Sb8F34/SWH4h
	PkQFAii/SJxQZjcTdbIwSfz7z2FC5C+WlN29A=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr34796912wib.3.1329905055056; Wed,
	22 Feb 2012 02:04:15 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 02:04:15 -0800 (PST)
In-Reply-To: <1329904496.2880.1.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:04:15 +0100
X-Google-Sender-Auth: Y4A74-jFg_hDLZApbrA9Hj1NoL8
Message-ID: <CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMi0yMiBhdCAwOToyMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+IGZsaWdo
dCAxMjAwNyB4ZW4tdW5zdGFibGUgcmVhbCBbcmVhbF0KPj4gPiBodHRwOi8vd3d3LmNoaWFyay5n
cmVlbmVuZC5vcmcudWsvfnhlbnNyY3RzL2xvZ3MvMTIwMDcvCj4+ID4KPj4gPiBSZWdyZXNzaW9u
cyA6LSgKPj4gPgo+PiA+IFRlc3RzIHdoaWNoIGRpZCBub3Qgc3VjY2VlZCBhbmQgYXJlIGJsb2Nr
aW5nLAo+PiA+IGluY2x1ZGluZyB0ZXN0cyB3aGljaCBjb3VsZCBub3QgYmUgcnVuOgo+PiA+IMKg
YnVpbGQtaTM4Ni1vbGRrZXJuIMKgIMKgIMKgIMKgIMKgIMKgNCB4ZW4tYnVpbGQgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPj4gPiDCoGJ1aWxkLWkzODYgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA0IHhlbi1idWlsZCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+PiA+IMKgYnVpbGQtYW1kNjQgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgNCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBS
RUdSLiB2cy4gMTIwMDMKPj4gPiDCoGJ1aWxkLWFtZDY0LW9sZGtlcm4gwqAgwqAgwqAgwqAgwqAg
NCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMK
Pj4KPj4KPj4gYnJjdGwgaXMgbm90IGluc3RhbGxlZCwgb3IgdGhlIHVzZXIgdGhhdCBpcyB0cnlp
bmcgdG8gYnVpbGQgWGVuCj4+IGRvZXNuJ3QgaGF2ZSBwZXJtaXNzaW9ucyB0byBydW4gaXQuIEkn
dmUgZm91bmQgdGhpcyB0ZXN0IHF1aXRlCj4+IHVzZWxlc3MsIGJlY2F1c2UgeW91IHNob3VsZCBi
ZSBhYmxlIHRvIGJ1aWxkIFhlbiBhcyBhIHJlZ3VsYXIgdXNlciwKPj4gdGhhdCBkb2Vzbid0IGhh
dmUgYWNjZXNzIHRvIGJyY3RsLCBkbyB5b3Ugd2FudCBtZSB0byBzZW5kIGEgcGF0Y2ggdGhhdAo+
PiByZW1vdmVzIHRoaXMgY2hlY2s/Cj4KPiBJIGJ1aWxkIFhlbiBvbiBhIG1hY2hpbmUgd2hpY2gg
ZG9lc24ndCBhY3R1YWxseSBydW4gWGVuIGFuZCB0aGVyZWZvcmUKPiBkb2Vzbid0IGhhdmUgYnJj
dGwgaW5zdGFsbGVkLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdW5yZWFzb25hYmxlIHNpbmNlCj4g
YnJjdGwgaXMgYSBydW50aW1lIG5vdCBjb21waWxlLXRpbWUgZGVwZW5kZW5jeS4KPgo+IEkgdGhp
bmsgd2Ugc2hvdWxkIHJlbW92ZSB0aGUgdGVzdCBmcm9tIGNvbmZpZ3VyZSAtLSBhbHRob3VnaCBp
dCBkb2VzCj4gbWFrZSBtZSB3b25kZXIgKHBlcmhhcHMgdG9vIGxhdGUpIGlmIHdlIHNob3VsZG4n
dCBoYXZlIGtlcHQgdGhlIGV4aXN0aW5nCj4gaW5zdGFsbCB0aW1lIGNoZWNrcy4KCkkndmUgc3Vi
bWl0dGVkIGEgcGF0Y2ggdGhhdCBzaG91bGQgZml4IHRoYXQuIEknbSBhZnJhaWQgdGhhdCByZW1v
dmluZwp0aGUgYnJjdGwvYnJjb25maWcgY2hlY2sgd2lsbCBicmluZyB0cm91YmxlLCBiZWNhdXNl
IHRoaXMgaXMgdXNlZCBpbgpob3RwbHVnIHNjcmlwdHMgYW5kIGVycm9ycyBvbiBob3RwbHVnIHNj
cmlwdHMgYXJlIGhhcmQgdG8gc3BvdCByaWdodApub3cgZm9yIHJlZ3VsYXIgdXNlcnMuCgo+IElh
bi4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:04:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S093f-000132-Of; Wed, 22 Feb 2012 10:04:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S093e-00012d-UQ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:04:23 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1329905055!1999699!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30580 invoked from network); 22 Feb 2012 10:04:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 10:04:16 -0000
Received: by wgbdr13 with SMTP id dr13so5770759wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 02:04:15 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr42049535wib.3.1329905055156 (num_hops
	= 1); Wed, 22 Feb 2012 02:04:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=n0XzemjtzcDGEKttXDQv+eWlytNsEwBrrD+hkl732CA=;
	b=dS2Sx8VG1sb4aTADSsrGj5pdZTDU7FbrSiPnjFrUKuYVlItk/zigTVy5fBjlSEHYaa
	W5InqGlCTNuAWAb+gAOtBmtvqvbSUKl0YOP1ecDh+hx6DnwzUV8TVZ9+Sb8F34/SWH4h
	PkQFAii/SJxQZjcTdbIwSfz7z2FC5C+WlN29A=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr34796912wib.3.1329905055056; Wed,
	22 Feb 2012 02:04:15 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 02:04:15 -0800 (PST)
In-Reply-To: <1329904496.2880.1.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:04:15 +0100
X-Google-Sender-Auth: Y4A74-jFg_hDLZApbrA9Hj1NoL8
Message-ID: <CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMi0yMiBhdCAwOToyMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+IGZsaWdo
dCAxMjAwNyB4ZW4tdW5zdGFibGUgcmVhbCBbcmVhbF0KPj4gPiBodHRwOi8vd3d3LmNoaWFyay5n
cmVlbmVuZC5vcmcudWsvfnhlbnNyY3RzL2xvZ3MvMTIwMDcvCj4+ID4KPj4gPiBSZWdyZXNzaW9u
cyA6LSgKPj4gPgo+PiA+IFRlc3RzIHdoaWNoIGRpZCBub3Qgc3VjY2VlZCBhbmQgYXJlIGJsb2Nr
aW5nLAo+PiA+IGluY2x1ZGluZyB0ZXN0cyB3aGljaCBjb3VsZCBub3QgYmUgcnVuOgo+PiA+IMKg
YnVpbGQtaTM4Ni1vbGRrZXJuIMKgIMKgIMKgIMKgIMKgIMKgNCB4ZW4tYnVpbGQgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPj4gPiDCoGJ1aWxkLWkzODYgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA0IHhlbi1idWlsZCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+PiA+IMKgYnVpbGQtYW1kNjQgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgNCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBS
RUdSLiB2cy4gMTIwMDMKPj4gPiDCoGJ1aWxkLWFtZDY0LW9sZGtlcm4gwqAgwqAgwqAgwqAgwqAg
NCB4ZW4tYnVpbGQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmFpbCBSRUdSLiB2cy4gMTIwMDMK
Pj4KPj4KPj4gYnJjdGwgaXMgbm90IGluc3RhbGxlZCwgb3IgdGhlIHVzZXIgdGhhdCBpcyB0cnlp
bmcgdG8gYnVpbGQgWGVuCj4+IGRvZXNuJ3QgaGF2ZSBwZXJtaXNzaW9ucyB0byBydW4gaXQuIEkn
dmUgZm91bmQgdGhpcyB0ZXN0IHF1aXRlCj4+IHVzZWxlc3MsIGJlY2F1c2UgeW91IHNob3VsZCBi
ZSBhYmxlIHRvIGJ1aWxkIFhlbiBhcyBhIHJlZ3VsYXIgdXNlciwKPj4gdGhhdCBkb2Vzbid0IGhh
dmUgYWNjZXNzIHRvIGJyY3RsLCBkbyB5b3Ugd2FudCBtZSB0byBzZW5kIGEgcGF0Y2ggdGhhdAo+
PiByZW1vdmVzIHRoaXMgY2hlY2s/Cj4KPiBJIGJ1aWxkIFhlbiBvbiBhIG1hY2hpbmUgd2hpY2gg
ZG9lc24ndCBhY3R1YWxseSBydW4gWGVuIGFuZCB0aGVyZWZvcmUKPiBkb2Vzbid0IGhhdmUgYnJj
dGwgaW5zdGFsbGVkLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdW5yZWFzb25hYmxlIHNpbmNlCj4g
YnJjdGwgaXMgYSBydW50aW1lIG5vdCBjb21waWxlLXRpbWUgZGVwZW5kZW5jeS4KPgo+IEkgdGhp
bmsgd2Ugc2hvdWxkIHJlbW92ZSB0aGUgdGVzdCBmcm9tIGNvbmZpZ3VyZSAtLSBhbHRob3VnaCBp
dCBkb2VzCj4gbWFrZSBtZSB3b25kZXIgKHBlcmhhcHMgdG9vIGxhdGUpIGlmIHdlIHNob3VsZG4n
dCBoYXZlIGtlcHQgdGhlIGV4aXN0aW5nCj4gaW5zdGFsbCB0aW1lIGNoZWNrcy4KCkkndmUgc3Vi
bWl0dGVkIGEgcGF0Y2ggdGhhdCBzaG91bGQgZml4IHRoYXQuIEknbSBhZnJhaWQgdGhhdCByZW1v
dmluZwp0aGUgYnJjdGwvYnJjb25maWcgY2hlY2sgd2lsbCBicmluZyB0cm91YmxlLCBiZWNhdXNl
IHRoaXMgaXMgdXNlZCBpbgpob3RwbHVnIHNjcmlwdHMgYW5kIGVycm9ycyBvbiBob3RwbHVnIHNj
cmlwdHMgYXJlIGhhcmQgdG8gc3BvdCByaWdodApub3cgZm9yIHJlZ3VsYXIgdXNlcnMuCgo+IElh
bi4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S09KM-0001Tk-Cx; Wed, 22 Feb 2012 10:21:38 +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 1S09KL-0001Tf-6W
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:21:37 +0000
Received: from [85.158.139.83:28675] by server-5.bemta-5.messagelabs.com id
	51/38-13566-0B1C44F4; Wed, 22 Feb 2012 10:21:36 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329906095!4847136!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11601 invoked from network); 22 Feb 2012 10:21:35 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.140)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 10:21:35 -0000
Received: from mail48-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:21:30 +0000
Received: from mail48-db3 (localhost [127.0.0.1])	by mail48-db3-R.bigfish.com
	(Postfix) with ESMTP id 92F066067D;
	Wed, 22 Feb 2012 10:21:29 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dIc89bh1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3
	(MessageSwitch) id 1329906087577916_18040;
	Wed, 22 Feb 2012 10:21:27 +0000 (UTC)
Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.243])	by
	mail48-db3.bigfish.com (Postfix) with ESMTP id 8908F8004C;
	Wed, 22 Feb 2012 10:21:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:21:27 +0000
X-WSS-ID: 0LZSI3S-02-91N-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 22AF0C80C3;	Wed, 22 Feb 2012 04:21:28 -0600 (CST)
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;
	Wed, 22 Feb 2012 04:21:41 -0600
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, 22 Feb 2012 04:21:29 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	05:21:29 -0500
Message-ID: <4F44C1A7.6070405@amd.com>
Date: Wed, 22 Feb 2012 11:21:27 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
In-Reply-To: <CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMDIvMjIvMTIgMTA6NTksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gMjAxMi8yLzIyIENo
cmlzdG9waCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4+Cj4+IEhpLAo+Pgo+PiBj
b25maWd1cmUgZmFpbHMgb24gTmV0QlNEIHRoYXQgdGhlcmUgaXMgbm8gYnJjdGwuCj4+IE5ldEJT
RCBoYXMgbm8gYnJjdGwsIE5ldEJTRCBoYXMgYnJjb25maWcuCj4KPiBTb3JyeSBDaHJpc3RvcGgs
IHRoZSBicmN0bCB0ZXN0IGlzIGdvaW5nIGF3YXkgKGZyb20gY29uZmlndXJlIGF0IGxlYXN0KS4K
ClRoZXJlIGFyZSBzb21lIG1vcmUgTGludXggc3BlY2lmaWMgdGVzdHM6Ci0gaXAKLSB1dWlkX2Ns
ZWFyIGluIGxpYnV1aWQKCkFsc28gdGhlIGNoZWNrIGZvciB5YWpsX2FsbG9jIGluIGxpYnlhamwg
ZmFpbHMgYWx0aG91Z2ggSSBoYXZlIGxpYnlhamwgCnZlcnNpb24gMSBpbnN0YWxsZWQuIFRoZSBj
aGVjayBtYXkgYmUgY29ycmVjdCBidXQgY29uZmlndXJlIHNob3VsZG4ndCAKZmFpbCBpZiB2ZXJz
aW9uIDEgaXMgc3RpbGwgc3VwcG9ydGVkLgoKQ2hyaXN0b3BoCgotLSAKLS0tdG8gc2F0aXNmeSBF
dXJvcGVhbiBMYXcgZm9yIGJ1c2luZXNzIGxldHRlcnM6CkFkdmFuY2VkIE1pY3JvIERldmljZXMg
R21iSApFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERvcm5hY2ggYi4gTXVlbmNoZW4KR2VzY2hhZWZ0
c2Z1ZWhyZXI6IEFsYmVydG8gQm96em8sIEFuZHJldyBCb3dkClNpdHo6IERvcm5hY2gsIEdlbWVp
bmRlIEFzY2hoZWltLCBMYW5ka3JlaXMgTXVlbmNoZW4KUmVnaXN0ZXJnZXJpY2h0IE11ZW5jaGVu
LCBIUkIgTnIuIDQzNjMyCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S09KM-0001Tk-Cx; Wed, 22 Feb 2012 10:21:38 +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 1S09KL-0001Tf-6W
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:21:37 +0000
Received: from [85.158.139.83:28675] by server-5.bemta-5.messagelabs.com id
	51/38-13566-0B1C44F4; Wed, 22 Feb 2012 10:21:36 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329906095!4847136!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11601 invoked from network); 22 Feb 2012 10:21:35 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.140)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 10:21:35 -0000
Received: from mail48-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:21:30 +0000
Received: from mail48-db3 (localhost [127.0.0.1])	by mail48-db3-R.bigfish.com
	(Postfix) with ESMTP id 92F066067D;
	Wed, 22 Feb 2012 10:21:29 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dIc89bh1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3
	(MessageSwitch) id 1329906087577916_18040;
	Wed, 22 Feb 2012 10:21:27 +0000 (UTC)
Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.243])	by
	mail48-db3.bigfish.com (Postfix) with ESMTP id 8908F8004C;
	Wed, 22 Feb 2012 10:21:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:21:27 +0000
X-WSS-ID: 0LZSI3S-02-91N-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 22AF0C80C3;	Wed, 22 Feb 2012 04:21:28 -0600 (CST)
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;
	Wed, 22 Feb 2012 04:21:41 -0600
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, 22 Feb 2012 04:21:29 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	05:21:29 -0500
Message-ID: <4F44C1A7.6070405@amd.com>
Date: Wed, 22 Feb 2012 11:21:27 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
In-Reply-To: <CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMDIvMjIvMTIgMTA6NTksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gMjAxMi8yLzIyIENo
cmlzdG9waCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4+Cj4+IEhpLAo+Pgo+PiBj
b25maWd1cmUgZmFpbHMgb24gTmV0QlNEIHRoYXQgdGhlcmUgaXMgbm8gYnJjdGwuCj4+IE5ldEJT
RCBoYXMgbm8gYnJjdGwsIE5ldEJTRCBoYXMgYnJjb25maWcuCj4KPiBTb3JyeSBDaHJpc3RvcGgs
IHRoZSBicmN0bCB0ZXN0IGlzIGdvaW5nIGF3YXkgKGZyb20gY29uZmlndXJlIGF0IGxlYXN0KS4K
ClRoZXJlIGFyZSBzb21lIG1vcmUgTGludXggc3BlY2lmaWMgdGVzdHM6Ci0gaXAKLSB1dWlkX2Ns
ZWFyIGluIGxpYnV1aWQKCkFsc28gdGhlIGNoZWNrIGZvciB5YWpsX2FsbG9jIGluIGxpYnlhamwg
ZmFpbHMgYWx0aG91Z2ggSSBoYXZlIGxpYnlhamwgCnZlcnNpb24gMSBpbnN0YWxsZWQuIFRoZSBj
aGVjayBtYXkgYmUgY29ycmVjdCBidXQgY29uZmlndXJlIHNob3VsZG4ndCAKZmFpbCBpZiB2ZXJz
aW9uIDEgaXMgc3RpbGwgc3VwcG9ydGVkLgoKQ2hyaXN0b3BoCgotLSAKLS0tdG8gc2F0aXNmeSBF
dXJvcGVhbiBMYXcgZm9yIGJ1c2luZXNzIGxldHRlcnM6CkFkdmFuY2VkIE1pY3JvIERldmljZXMg
R21iSApFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERvcm5hY2ggYi4gTXVlbmNoZW4KR2VzY2hhZWZ0
c2Z1ZWhyZXI6IEFsYmVydG8gQm96em8sIEFuZHJldyBCb3dkClNpdHo6IERvcm5hY2gsIEdlbWVp
bmRlIEFzY2hoZWltLCBMYW5ka3JlaXMgTXVlbmNoZW4KUmVnaXN0ZXJnZXJpY2h0IE11ZW5jaGVu
LCBIUkIgTnIuIDQzNjMyCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:29:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10:29:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S09Rh-0001dT-Ab; Wed, 22 Feb 2012 10:29:13 +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 1S09Rf-0001dL-MD
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:29:11 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329906489!50250543!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8248 invoked from network); 22 Feb 2012 10:28:11 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 10:28:11 -0000
Received: from mail135-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:28:58 +0000
Received: from mail135-tx2 (localhost [127.0.0.1])	by
	mail135-tx2-R.bigfish.com (Postfix) with ESMTP id 110A034032F	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 10:28:58 +0000 (UTC)
X-SpamScore: 4
X-BigFish: VPS4(z33fclzzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail135-tx2 (localhost.localdomain [127.0.0.1]) by mail135-tx2
	(MessageSwitch) id 1329906535738898_19687;
	Wed, 22 Feb 2012 10:28:55 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.249])	by
	mail135-tx2.bigfish.com (Postfix) with ESMTP id ADC611E0046	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 10:28:55 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:28:55 +0000
X-WSS-ID: 0LZSIGB-01-5MT-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 25CCC1028097	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 04:28:59 -0600 (CST)
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, 22 Feb 2012 04:29:10 -0600
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, 22 Feb 2012 04:28:59 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	05:28:59 -0500
Message-ID: <4F44C369.9020500@amd.com>
Date: Wed, 22 Feb 2012 11:28:57 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] xenstore build failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

xenstore fails to build:

init-xenstore-domain.c:11:32: error: xen/sys/xenbus_dev.h: No such file 
or directory
init-xenstore-domain.c: In function 'build':
init-xenstore-domain.c:37: error: 'IOCTL_XENBUS_BACKEND_SETUP' 
undeclared (first use in this function)

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:29:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10:29:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S09Rh-0001dT-Ab; Wed, 22 Feb 2012 10:29:13 +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 1S09Rf-0001dL-MD
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:29:11 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1329906489!50250543!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8248 invoked from network); 22 Feb 2012 10:28:11 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 10:28:11 -0000
Received: from mail135-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:28:58 +0000
Received: from mail135-tx2 (localhost [127.0.0.1])	by
	mail135-tx2-R.bigfish.com (Postfix) with ESMTP id 110A034032F	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 10:28:58 +0000 (UTC)
X-SpamScore: 4
X-BigFish: VPS4(z33fclzzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail135-tx2 (localhost.localdomain [127.0.0.1]) by mail135-tx2
	(MessageSwitch) id 1329906535738898_19687;
	Wed, 22 Feb 2012 10:28:55 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.249])	by
	mail135-tx2.bigfish.com (Postfix) with ESMTP id ADC611E0046	for
	<xen-devel@lists.xensource.com>; Wed, 22 Feb 2012 10:28:55 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:28:55 +0000
X-WSS-ID: 0LZSIGB-01-5MT-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 25CCC1028097	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 04:28:59 -0600 (CST)
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, 22 Feb 2012 04:29:10 -0600
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, 22 Feb 2012 04:28:59 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	05:28:59 -0500
Message-ID: <4F44C369.9020500@amd.com>
Date: Wed, 22 Feb 2012 11:28:57 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] xenstore build failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

xenstore fails to build:

init-xenstore-domain.c:11:32: error: xen/sys/xenbus_dev.h: No such file 
or directory
init-xenstore-domain.c: In function 'build':
init-xenstore-domain.c:37: error: 'IOCTL_XENBUS_BACKEND_SETUP' 
undeclared (first use in this function)

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:30:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S09T0-0001hH-Pu; Wed, 22 Feb 2012 10:30:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S09Sz-0001gv-Dt
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:30:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329906624!9455635!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2200 invoked from network); 22 Feb 2012 10:30:24 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 10:30:24 -0000
Received: by wgbdr13 with SMTP id dr13so5792218wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 02:30:24 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr43975913wia.3.1329906624736 (num_hops
	= 1); Wed, 22 Feb 2012 02:30:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=H3OX80VUgUYaTiykXh34/S1A158vwBtRafe2TmsSPsk=;
	b=m+ySsl9bPuhKk10evm4TPAcTH/s94XBmEryGm+8ngv570OeAp2H96FS+HkyWH0WWC7
	/Erm7uWf/8nw23Cc1YUtxJGGE3H6IZ8DjG+iGi1TQwwEP2zICB0sQMSzpYVym5+oQq39
	iGQ2PIlkxaEg+OGx9FLWSKRvNZcBqs86KN7j8=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr36471539wia.3.1329906624672; Wed,
	22 Feb 2012 02:30:24 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 02:30:24 -0800 (PST)
In-Reply-To: <4F44C1A7.6070405@amd.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
Date: Wed, 22 Feb 2012 11:30:24 +0100
X-Google-Sender-Auth: frYJnKID6-h5i7h-6D23wGqnc44
Message-ID: <CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+IE9u
IDAyLzIyLzEyIDEwOjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pgo+PiAyMDEyLzIvMjIg
Q2hyaXN0b3BoIEVnZ2VyPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPj4+Cj4+Pgo+Pj4gSGks
Cj4+Pgo+Pj4gY29uZmlndXJlIGZhaWxzIG9uIE5ldEJTRCB0aGF0IHRoZXJlIGlzIG5vIGJyY3Rs
Lgo+Pj4gTmV0QlNEIGhhcyBubyBicmN0bCwgTmV0QlNEIGhhcyBicmNvbmZpZy4KPj4KPj4KPj4g
U29ycnkgQ2hyaXN0b3BoLCB0aGUgYnJjdGwgdGVzdCBpcyBnb2luZyBhd2F5IChmcm9tIGNvbmZp
Z3VyZSBhdCBsZWFzdCkuCj4KPgo+IFRoZXJlIGFyZSBzb21lIG1vcmUgTGludXggc3BlY2lmaWMg
dGVzdHM6Cj4gLSBpcAo+IC0gdXVpZF9jbGVhciBpbiBsaWJ1dWlkCgpUaGFua3MgZm9yIHJlcG9y
dGluZywgSSB3aWxsIHRha2UgY2FyZSBvZiB0aG9zZSBvbmNlIHRoZSBwYXRjaCBoYXMKcGFzc2Vk
IHRoZSB0ZXN0IHN5c3RlbSAoc29ycnkgZm9yIHRoYXQsIGJ1dCBJIGNhbm5vdCB0ZXN0IG9uIHNv
IG1hbnkKc3lzdGVtcykuCgo+IEFsc28gdGhlIGNoZWNrIGZvciB5YWpsX2FsbG9jIGluIGxpYnlh
amwgZmFpbHMgYWx0aG91Z2ggSSBoYXZlIGxpYnlhamwKPiB2ZXJzaW9uIDEgaW5zdGFsbGVkLiBU
aGUgY2hlY2sgbWF5IGJlIGNvcnJlY3QgYnV0IGNvbmZpZ3VyZSBzaG91bGRuJ3QgZmFpbAo+IGlm
IHZlcnNpb24gMSBpcyBzdGlsbCBzdXBwb3J0ZWQuCgpTaW5jZSBJIGd1ZXNzIHlvdSBoYXZlIGl0
IGluIC91c3IvcGtnLywgaGF2ZSB5b3Ugc2V0IFBSRVBFTkRfTElCIG9yCkFQUEVORF9MSUIgZW52
IHZhcmlhYmxlcyBiZWZvcmUgZXhlY3V0aW5nIGNvbmZpZ3VyZT8KCj4KPgo+IENocmlzdG9waAo+
Cj4gLS0KPiAtLS10byBzYXRpc2Z5IEV1cm9wZWFuIExhdyBmb3IgYnVzaW5lc3MgbGV0dGVyczoK
PiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIEdtYkgKPiBFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERv
cm5hY2ggYi4gTXVlbmNoZW4KPiBHZXNjaGFlZnRzZnVlaHJlcjogQWxiZXJ0byBCb3p6bywgQW5k
cmV3IEJvd2QKPiBTaXR6OiBEb3JuYWNoLCBHZW1laW5kZSBBc2NoaGVpbSwgTGFuZGtyZWlzIE11
ZW5jaGVuCj4gUmVnaXN0ZXJnZXJpY2h0IE11ZW5jaGVuLCBIUkIgTnIuIDQzNjMyCj4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:30:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S09T0-0001hH-Pu; Wed, 22 Feb 2012 10:30:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S09Sz-0001gv-Dt
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:30:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1329906624!9455635!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2200 invoked from network); 22 Feb 2012 10:30:24 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 10:30:24 -0000
Received: by wgbdr13 with SMTP id dr13so5792218wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 02:30:24 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr43975913wia.3.1329906624736 (num_hops
	= 1); Wed, 22 Feb 2012 02:30:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=H3OX80VUgUYaTiykXh34/S1A158vwBtRafe2TmsSPsk=;
	b=m+ySsl9bPuhKk10evm4TPAcTH/s94XBmEryGm+8ngv570OeAp2H96FS+HkyWH0WWC7
	/Erm7uWf/8nw23Cc1YUtxJGGE3H6IZ8DjG+iGi1TQwwEP2zICB0sQMSzpYVym5+oQq39
	iGQ2PIlkxaEg+OGx9FLWSKRvNZcBqs86KN7j8=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr36471539wia.3.1329906624672; Wed,
	22 Feb 2012 02:30:24 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 02:30:24 -0800 (PST)
In-Reply-To: <4F44C1A7.6070405@amd.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
Date: Wed, 22 Feb 2012 11:30:24 +0100
X-Google-Sender-Auth: frYJnKID6-h5i7h-6D23wGqnc44
Message-ID: <CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+IE9u
IDAyLzIyLzEyIDEwOjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pgo+PiAyMDEyLzIvMjIg
Q2hyaXN0b3BoIEVnZ2VyPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPj4+Cj4+Pgo+Pj4gSGks
Cj4+Pgo+Pj4gY29uZmlndXJlIGZhaWxzIG9uIE5ldEJTRCB0aGF0IHRoZXJlIGlzIG5vIGJyY3Rs
Lgo+Pj4gTmV0QlNEIGhhcyBubyBicmN0bCwgTmV0QlNEIGhhcyBicmNvbmZpZy4KPj4KPj4KPj4g
U29ycnkgQ2hyaXN0b3BoLCB0aGUgYnJjdGwgdGVzdCBpcyBnb2luZyBhd2F5IChmcm9tIGNvbmZp
Z3VyZSBhdCBsZWFzdCkuCj4KPgo+IFRoZXJlIGFyZSBzb21lIG1vcmUgTGludXggc3BlY2lmaWMg
dGVzdHM6Cj4gLSBpcAo+IC0gdXVpZF9jbGVhciBpbiBsaWJ1dWlkCgpUaGFua3MgZm9yIHJlcG9y
dGluZywgSSB3aWxsIHRha2UgY2FyZSBvZiB0aG9zZSBvbmNlIHRoZSBwYXRjaCBoYXMKcGFzc2Vk
IHRoZSB0ZXN0IHN5c3RlbSAoc29ycnkgZm9yIHRoYXQsIGJ1dCBJIGNhbm5vdCB0ZXN0IG9uIHNv
IG1hbnkKc3lzdGVtcykuCgo+IEFsc28gdGhlIGNoZWNrIGZvciB5YWpsX2FsbG9jIGluIGxpYnlh
amwgZmFpbHMgYWx0aG91Z2ggSSBoYXZlIGxpYnlhamwKPiB2ZXJzaW9uIDEgaW5zdGFsbGVkLiBU
aGUgY2hlY2sgbWF5IGJlIGNvcnJlY3QgYnV0IGNvbmZpZ3VyZSBzaG91bGRuJ3QgZmFpbAo+IGlm
IHZlcnNpb24gMSBpcyBzdGlsbCBzdXBwb3J0ZWQuCgpTaW5jZSBJIGd1ZXNzIHlvdSBoYXZlIGl0
IGluIC91c3IvcGtnLywgaGF2ZSB5b3Ugc2V0IFBSRVBFTkRfTElCIG9yCkFQUEVORF9MSUIgZW52
IHZhcmlhYmxlcyBiZWZvcmUgZXhlY3V0aW5nIGNvbmZpZ3VyZT8KCj4KPgo+IENocmlzdG9waAo+
Cj4gLS0KPiAtLS10byBzYXRpc2Z5IEV1cm9wZWFuIExhdyBmb3IgYnVzaW5lc3MgbGV0dGVyczoK
PiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIEdtYkgKPiBFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERv
cm5hY2ggYi4gTXVlbmNoZW4KPiBHZXNjaGFlZnRzZnVlaHJlcjogQWxiZXJ0byBCb3p6bywgQW5k
cmV3IEJvd2QKPiBTaXR6OiBEb3JuYWNoLCBHZW1laW5kZSBBc2NoaGVpbSwgTGFuZGtyZWlzIE11
ZW5jaGVuCj4gUmVnaXN0ZXJnZXJpY2h0IE11ZW5jaGVuLCBIUkIgTnIuIDQzNjMyCj4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:31:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09Tl-0001m4-Df; Wed, 22 Feb 2012 10:31:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S09Tk-0001lY-DG
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:31:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329906674!10002616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31838 invoked from network); 22 Feb 2012 10:31:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 10:31:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10865710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 10:31:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 10:31:05 +0000
Message-ID: <1329906664.2880.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 22 Feb 2012 10:31:04 +0000
In-Reply-To: <1329904496.2880.1.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTIyIGF0IDA5OjU0ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gV2VkLCAyMDEyLTAyLTIyIGF0IDA5OjIwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+ID4gMjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+ID4g
PiBmbGlnaHQgMTIwMDcgeGVuLXVuc3RhYmxlIHJlYWwgW3JlYWxdCj4gPiA+IGh0dHA6Ly93d3cu
Y2hpYXJrLmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMvbG9ncy8xMjAwNy8KPiA+ID4KPiA+ID4g
UmVncmVzc2lvbnMgOi0oCj4gPiA+Cj4gPiA+IFRlc3RzIHdoaWNoIGRpZCBub3Qgc3VjY2VlZCBh
bmQgYXJlIGJsb2NraW5nLAo+ID4gPiBpbmNsdWRpbmcgdGVzdHMgd2hpY2ggY291bGQgbm90IGJl
IHJ1bjoKPiA+ID4gIGJ1aWxkLWkzODYtb2xka2VybiAgICAgICAgICAgIDQgeGVuLWJ1aWxkICAg
ICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+ID4gPiAgYnVpbGQtaTM4NiAgICAg
ICAgICAgICAgICAgICAgNCB4ZW4tYnVpbGQgICAgICAgICAgICAgICAgIGZhaWwgUkVHUi4gdnMu
IDEyMDAzCj4gPiA+ICBidWlsZC1hbWQ2NCAgICAgICAgICAgICAgICAgICA0IHhlbi1idWlsZCAg
ICAgICAgICAgICAgICAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+ID4gIGJ1aWxkLWFtZDY0LW9s
ZGtlcm4gICAgICAgICAgIDQgeGVuLWJ1aWxkICAgICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZz
LiAxMjAwMwo+ID4gCj4gPiAKPiA+IGJyY3RsIGlzIG5vdCBpbnN0YWxsZWQsIG9yIHRoZSB1c2Vy
IHRoYXQgaXMgdHJ5aW5nIHRvIGJ1aWxkIFhlbgo+ID4gZG9lc24ndCBoYXZlIHBlcm1pc3Npb25z
IHRvIHJ1biBpdC4gSSd2ZSBmb3VuZCB0aGlzIHRlc3QgcXVpdGUKPiA+IHVzZWxlc3MsIGJlY2F1
c2UgeW91IHNob3VsZCBiZSBhYmxlIHRvIGJ1aWxkIFhlbiBhcyBhIHJlZ3VsYXIgdXNlciwKPiA+
IHRoYXQgZG9lc24ndCBoYXZlIGFjY2VzcyB0byBicmN0bCwgZG8geW91IHdhbnQgbWUgdG8gc2Vu
ZCBhIHBhdGNoIHRoYXQKPiA+IHJlbW92ZXMgdGhpcyBjaGVjaz8KPiAKPiBJIGJ1aWxkIFhlbiBv
biBhIG1hY2hpbmUgd2hpY2ggZG9lc24ndCBhY3R1YWxseSBydW4gWGVuIGFuZCB0aGVyZWZvcmUK
PiBkb2Vzbid0IGhhdmUgYnJjdGwgaW5zdGFsbGVkLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdW5y
ZWFzb25hYmxlIHNpbmNlCj4gYnJjdGwgaXMgYSBydW50aW1lIG5vdCBjb21waWxlLXRpbWUgZGVw
ZW5kZW5jeS4KCkkgYWxzbyBoYWQgdG8gc3BlY2lmeSBVREVWQURNIG9uIHRoZSBjb25maWd1cmUg
bGluZSAoSSBzdXNwZWN0IGJlY2F1c2UKaXQgaXMgbm90IGluICRQQVRIIGZvciByZWd1bGFyIHVz
ZXJzKS4gVGhlIGZpcnN0IHRpbWUgSSBkaWQgc28gSSBnYXZlCnRoZSB3cm9uZyBwYXRoOgogICAg
ICAgICQgVURFVkFETT0vdXNyL3NiaW4vdWRldmFkbSAuL2NvbmZpZ3VyZSAKICAgICAgICBbLi4u
XQogICAgICAgIGNoZWNraW5nIGZvciB1ZGV2YWRtLi4uIC91c3Ivc2Jpbi91ZGV2YWRtCiAgICAg
ICAgLi9jb25maWd1cmU6IGxpbmUgNjQ4NDogL3Vzci9zYmluL3VkZXZhZG06IE5vIHN1Y2ggZmls
ZSBvciBkaXJlY3RvcnkKICAgICAgICAuL2NvbmZpZ3VyZTogbGluZSA2NDg2OiB0ZXN0OiAtbHQ6
IHVuYXJ5IG9wZXJhdG9yIGV4cGVjdGVkCgpJZiB3ZSB0aGluayB0aGlzIGNoZWNrIHNob3VsZCBi
ZSBrZXB0IHRoZW4gaXQgbmVlZHMgdG8gbGVhcm4gdG8gY2hlY2sKZm9yIHRoaW5ncyBpbiBwYXRo
cyBvdGhlciB0aGFuICRQQVRIIGFuZCBhbHNvIGhhdmUgdGhlIGVycm9yIGhhbmRsaW5nCmZpeGVk
LgoKV2l0aCB0aGlzIGFuZCByZW1vdmluZyB0aGUgYnJjdGwgY2hlY2sgSSB3YXMgYWJsZSB0byBy
dW4gY29uZmlndXJlCnN1Y2Nlc3NmdWxseS4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:31:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09Tl-0001m4-Df; Wed, 22 Feb 2012 10:31:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S09Tk-0001lY-DG
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:31:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329906674!10002616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31838 invoked from network); 22 Feb 2012 10:31:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 10:31:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10865710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 10:31:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 10:31:05 +0000
Message-ID: <1329906664.2880.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 22 Feb 2012 10:31:04 +0000
In-Reply-To: <1329904496.2880.1.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTIyIGF0IDA5OjU0ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gV2VkLCAyMDEyLTAyLTIyIGF0IDA5OjIwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+ID4gMjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+ID4g
PiBmbGlnaHQgMTIwMDcgeGVuLXVuc3RhYmxlIHJlYWwgW3JlYWxdCj4gPiA+IGh0dHA6Ly93d3cu
Y2hpYXJrLmdyZWVuZW5kLm9yZy51ay9+eGVuc3JjdHMvbG9ncy8xMjAwNy8KPiA+ID4KPiA+ID4g
UmVncmVzc2lvbnMgOi0oCj4gPiA+Cj4gPiA+IFRlc3RzIHdoaWNoIGRpZCBub3Qgc3VjY2VlZCBh
bmQgYXJlIGJsb2NraW5nLAo+ID4gPiBpbmNsdWRpbmcgdGVzdHMgd2hpY2ggY291bGQgbm90IGJl
IHJ1bjoKPiA+ID4gIGJ1aWxkLWkzODYtb2xka2VybiAgICAgICAgICAgIDQgeGVuLWJ1aWxkICAg
ICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+ID4gPiAgYnVpbGQtaTM4NiAgICAg
ICAgICAgICAgICAgICAgNCB4ZW4tYnVpbGQgICAgICAgICAgICAgICAgIGZhaWwgUkVHUi4gdnMu
IDEyMDAzCj4gPiA+ICBidWlsZC1hbWQ2NCAgICAgICAgICAgICAgICAgICA0IHhlbi1idWlsZCAg
ICAgICAgICAgICAgICAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+ID4gIGJ1aWxkLWFtZDY0LW9s
ZGtlcm4gICAgICAgICAgIDQgeGVuLWJ1aWxkICAgICAgICAgICAgICAgICBmYWlsIFJFR1IuIHZz
LiAxMjAwMwo+ID4gCj4gPiAKPiA+IGJyY3RsIGlzIG5vdCBpbnN0YWxsZWQsIG9yIHRoZSB1c2Vy
IHRoYXQgaXMgdHJ5aW5nIHRvIGJ1aWxkIFhlbgo+ID4gZG9lc24ndCBoYXZlIHBlcm1pc3Npb25z
IHRvIHJ1biBpdC4gSSd2ZSBmb3VuZCB0aGlzIHRlc3QgcXVpdGUKPiA+IHVzZWxlc3MsIGJlY2F1
c2UgeW91IHNob3VsZCBiZSBhYmxlIHRvIGJ1aWxkIFhlbiBhcyBhIHJlZ3VsYXIgdXNlciwKPiA+
IHRoYXQgZG9lc24ndCBoYXZlIGFjY2VzcyB0byBicmN0bCwgZG8geW91IHdhbnQgbWUgdG8gc2Vu
ZCBhIHBhdGNoIHRoYXQKPiA+IHJlbW92ZXMgdGhpcyBjaGVjaz8KPiAKPiBJIGJ1aWxkIFhlbiBv
biBhIG1hY2hpbmUgd2hpY2ggZG9lc24ndCBhY3R1YWxseSBydW4gWGVuIGFuZCB0aGVyZWZvcmUK
PiBkb2Vzbid0IGhhdmUgYnJjdGwgaW5zdGFsbGVkLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdW5y
ZWFzb25hYmxlIHNpbmNlCj4gYnJjdGwgaXMgYSBydW50aW1lIG5vdCBjb21waWxlLXRpbWUgZGVw
ZW5kZW5jeS4KCkkgYWxzbyBoYWQgdG8gc3BlY2lmeSBVREVWQURNIG9uIHRoZSBjb25maWd1cmUg
bGluZSAoSSBzdXNwZWN0IGJlY2F1c2UKaXQgaXMgbm90IGluICRQQVRIIGZvciByZWd1bGFyIHVz
ZXJzKS4gVGhlIGZpcnN0IHRpbWUgSSBkaWQgc28gSSBnYXZlCnRoZSB3cm9uZyBwYXRoOgogICAg
ICAgICQgVURFVkFETT0vdXNyL3NiaW4vdWRldmFkbSAuL2NvbmZpZ3VyZSAKICAgICAgICBbLi4u
XQogICAgICAgIGNoZWNraW5nIGZvciB1ZGV2YWRtLi4uIC91c3Ivc2Jpbi91ZGV2YWRtCiAgICAg
ICAgLi9jb25maWd1cmU6IGxpbmUgNjQ4NDogL3Vzci9zYmluL3VkZXZhZG06IE5vIHN1Y2ggZmls
ZSBvciBkaXJlY3RvcnkKICAgICAgICAuL2NvbmZpZ3VyZTogbGluZSA2NDg2OiB0ZXN0OiAtbHQ6
IHVuYXJ5IG9wZXJhdG9yIGV4cGVjdGVkCgpJZiB3ZSB0aGluayB0aGlzIGNoZWNrIHNob3VsZCBi
ZSBrZXB0IHRoZW4gaXQgbmVlZHMgdG8gbGVhcm4gdG8gY2hlY2sKZm9yIHRoaW5ncyBpbiBwYXRo
cyBvdGhlciB0aGFuICRQQVRIIGFuZCBhbHNvIGhhdmUgdGhlIGVycm9yIGhhbmRsaW5nCmZpeGVk
LgoKV2l0aCB0aGlzIGFuZCByZW1vdmluZyB0aGUgYnJjdGwgY2hlY2sgSSB3YXMgYWJsZSB0byBy
dW4gY29uZmlndXJlCnN1Y2Nlc3NmdWxseS4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09Wx-00023B-1M; Wed, 22 Feb 2012 10:34: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 1S09Wu-00022v-Qf
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:34:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329906823!55269044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3473 invoked from network); 22 Feb 2012 10:33:43 -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;
	22 Feb 2012 10:33:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10865832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 10:34:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 10:34:35 +0000
Message-ID: <1329906873.2880.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 22 Feb 2012 10:34:33 +0000
In-Reply-To: <CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTIyIGF0IDEwOjA0ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFdlZCwgMjAxMi0wMi0yMiBhdCAwOToyMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzIvMjIgeGVuLm9yZyA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4g
Pj4gPiBmbGlnaHQgMTIwMDcgeGVuLXVuc3RhYmxlIHJlYWwgW3JlYWxdCj4gPj4gPiBodHRwOi8v
d3d3LmNoaWFyay5ncmVlbmVuZC5vcmcudWsvfnhlbnNyY3RzL2xvZ3MvMTIwMDcvCj4gPj4gPgo+
ID4+ID4gUmVncmVzc2lvbnMgOi0oCj4gPj4gPgo+ID4+ID4gVGVzdHMgd2hpY2ggZGlkIG5vdCBz
dWNjZWVkIGFuZCBhcmUgYmxvY2tpbmcsCj4gPj4gPiBpbmNsdWRpbmcgdGVzdHMgd2hpY2ggY291
bGQgbm90IGJlIHJ1bjoKPiA+PiA+ICBidWlsZC1pMzg2LW9sZGtlcm4gICAgICAgICAgICA0IHhl
bi1idWlsZCAgICAgICAgICAgICAgICAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+PiA+ICBidWls
ZC1pMzg2ICAgICAgICAgICAgICAgICAgICA0IHhlbi1idWlsZCAgICAgICAgICAgICAgICAgZmFp
bCBSRUdSLiB2cy4gMTIwMDMKPiA+PiA+ICBidWlsZC1hbWQ2NCAgICAgICAgICAgICAgICAgICA0
IHhlbi1idWlsZCAgICAgICAgICAgICAgICAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+PiA+ICBi
dWlsZC1hbWQ2NC1vbGRrZXJuICAgICAgICAgICA0IHhlbi1idWlsZCAgICAgICAgICAgICAgICAg
ZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+Pgo+ID4+Cj4gPj4gYnJjdGwgaXMgbm90IGluc3RhbGxl
ZCwgb3IgdGhlIHVzZXIgdGhhdCBpcyB0cnlpbmcgdG8gYnVpbGQgWGVuCj4gPj4gZG9lc24ndCBo
YXZlIHBlcm1pc3Npb25zIHRvIHJ1biBpdC4gSSd2ZSBmb3VuZCB0aGlzIHRlc3QgcXVpdGUKPiA+
PiB1c2VsZXNzLCBiZWNhdXNlIHlvdSBzaG91bGQgYmUgYWJsZSB0byBidWlsZCBYZW4gYXMgYSBy
ZWd1bGFyIHVzZXIsCj4gPj4gdGhhdCBkb2Vzbid0IGhhdmUgYWNjZXNzIHRvIGJyY3RsLCBkbyB5
b3Ugd2FudCBtZSB0byBzZW5kIGEgcGF0Y2ggdGhhdAo+ID4+IHJlbW92ZXMgdGhpcyBjaGVjaz8K
PiA+Cj4gPiBJIGJ1aWxkIFhlbiBvbiBhIG1hY2hpbmUgd2hpY2ggZG9lc24ndCBhY3R1YWxseSBy
dW4gWGVuIGFuZCB0aGVyZWZvcmUKPiA+IGRvZXNuJ3QgaGF2ZSBicmN0bCBpbnN0YWxsZWQsIEkg
ZG9uJ3QgdGhpbmsgdGhpcyBpcyB1bnJlYXNvbmFibGUgc2luY2UKPiA+IGJyY3RsIGlzIGEgcnVu
dGltZSBub3QgY29tcGlsZS10aW1lIGRlcGVuZGVuY3kuCj4gPgo+ID4gSSB0aGluayB3ZSBzaG91
bGQgcmVtb3ZlIHRoZSB0ZXN0IGZyb20gY29uZmlndXJlIC0tIGFsdGhvdWdoIGl0IGRvZXMKPiA+
IG1ha2UgbWUgd29uZGVyIChwZXJoYXBzIHRvbyBsYXRlKSBpZiB3ZSBzaG91bGRuJ3QgaGF2ZSBr
ZXB0IHRoZSBleGlzdGluZwo+ID4gaW5zdGFsbCB0aW1lIGNoZWNrcy4KPiAKPiBJJ3ZlIHN1Ym1p
dHRlZCBhIHBhdGNoIHRoYXQgc2hvdWxkIGZpeCB0aGF0LiBJJ20gYWZyYWlkIHRoYXQgcmVtb3Zp
bmcKPiB0aGUgYnJjdGwvYnJjb25maWcgY2hlY2sgd2lsbCBicmluZyB0cm91YmxlLCBiZWNhdXNl
IHRoaXMgaXMgdXNlZCBpbgo+IGhvdHBsdWcgc2NyaXB0cyBhbmQgZXJyb3JzIG9uIGhvdHBsdWcg
c2NyaXB0cyBhcmUgaGFyZCB0byBzcG90IHJpZ2h0Cj4gbm93IGZvciByZWd1bGFyIHVzZXJzLgoK
VGhpcyBpcyB3aHkgSSBhbSBjb25jZXJuZWQgdGhhdCB3ZSBoYXZlIHJlbW92ZWQgdGhlIGluc3Rh
bGwgdGltZSBhcyB3ZWxsCmFzIHRoZSBkZXZlbG9wbWVudCB0aW1lIGNoZWNrcy4uLgoKUGVyaGFw
cyB3ZSBzaG91bGQgbW92ZSB0aGVzZSBuZXcgY2hlY2tzIHRvIGEgc2Vjb25kIGNvbmZpZ3VyZSBz
Y3JpcHQKd2hpY2ggY2FuIGJlIHJ1biBhdCBpbnN0YWxsIHRpbWUgYW5kIHByb2R1Y2VzIGFzIGl0
cyBvdXRwdXQganVzdCBhIHBhc3MKb3IgZmFpbD8KCklhbi4KCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09Wx-00023B-1M; Wed, 22 Feb 2012 10:34: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 1S09Wu-00022v-Qf
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:34:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329906823!55269044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3473 invoked from network); 22 Feb 2012 10:33:43 -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;
	22 Feb 2012 10:33:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10865832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 10:34:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 10:34:35 +0000
Message-ID: <1329906873.2880.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 22 Feb 2012 10:34:33 +0000
In-Reply-To: <CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTIyIGF0IDEwOjA0ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yMiBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFdlZCwgMjAxMi0wMi0yMiBhdCAwOToyMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzIvMjIgeGVuLm9yZyA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4g
Pj4gPiBmbGlnaHQgMTIwMDcgeGVuLXVuc3RhYmxlIHJlYWwgW3JlYWxdCj4gPj4gPiBodHRwOi8v
d3d3LmNoaWFyay5ncmVlbmVuZC5vcmcudWsvfnhlbnNyY3RzL2xvZ3MvMTIwMDcvCj4gPj4gPgo+
ID4+ID4gUmVncmVzc2lvbnMgOi0oCj4gPj4gPgo+ID4+ID4gVGVzdHMgd2hpY2ggZGlkIG5vdCBz
dWNjZWVkIGFuZCBhcmUgYmxvY2tpbmcsCj4gPj4gPiBpbmNsdWRpbmcgdGVzdHMgd2hpY2ggY291
bGQgbm90IGJlIHJ1bjoKPiA+PiA+ICBidWlsZC1pMzg2LW9sZGtlcm4gICAgICAgICAgICA0IHhl
bi1idWlsZCAgICAgICAgICAgICAgICAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+PiA+ICBidWls
ZC1pMzg2ICAgICAgICAgICAgICAgICAgICA0IHhlbi1idWlsZCAgICAgICAgICAgICAgICAgZmFp
bCBSRUdSLiB2cy4gMTIwMDMKPiA+PiA+ICBidWlsZC1hbWQ2NCAgICAgICAgICAgICAgICAgICA0
IHhlbi1idWlsZCAgICAgICAgICAgICAgICAgZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+PiA+ICBi
dWlsZC1hbWQ2NC1vbGRrZXJuICAgICAgICAgICA0IHhlbi1idWlsZCAgICAgICAgICAgICAgICAg
ZmFpbCBSRUdSLiB2cy4gMTIwMDMKPiA+Pgo+ID4+Cj4gPj4gYnJjdGwgaXMgbm90IGluc3RhbGxl
ZCwgb3IgdGhlIHVzZXIgdGhhdCBpcyB0cnlpbmcgdG8gYnVpbGQgWGVuCj4gPj4gZG9lc24ndCBo
YXZlIHBlcm1pc3Npb25zIHRvIHJ1biBpdC4gSSd2ZSBmb3VuZCB0aGlzIHRlc3QgcXVpdGUKPiA+
PiB1c2VsZXNzLCBiZWNhdXNlIHlvdSBzaG91bGQgYmUgYWJsZSB0byBidWlsZCBYZW4gYXMgYSBy
ZWd1bGFyIHVzZXIsCj4gPj4gdGhhdCBkb2Vzbid0IGhhdmUgYWNjZXNzIHRvIGJyY3RsLCBkbyB5
b3Ugd2FudCBtZSB0byBzZW5kIGEgcGF0Y2ggdGhhdAo+ID4+IHJlbW92ZXMgdGhpcyBjaGVjaz8K
PiA+Cj4gPiBJIGJ1aWxkIFhlbiBvbiBhIG1hY2hpbmUgd2hpY2ggZG9lc24ndCBhY3R1YWxseSBy
dW4gWGVuIGFuZCB0aGVyZWZvcmUKPiA+IGRvZXNuJ3QgaGF2ZSBicmN0bCBpbnN0YWxsZWQsIEkg
ZG9uJ3QgdGhpbmsgdGhpcyBpcyB1bnJlYXNvbmFibGUgc2luY2UKPiA+IGJyY3RsIGlzIGEgcnVu
dGltZSBub3QgY29tcGlsZS10aW1lIGRlcGVuZGVuY3kuCj4gPgo+ID4gSSB0aGluayB3ZSBzaG91
bGQgcmVtb3ZlIHRoZSB0ZXN0IGZyb20gY29uZmlndXJlIC0tIGFsdGhvdWdoIGl0IGRvZXMKPiA+
IG1ha2UgbWUgd29uZGVyIChwZXJoYXBzIHRvbyBsYXRlKSBpZiB3ZSBzaG91bGRuJ3QgaGF2ZSBr
ZXB0IHRoZSBleGlzdGluZwo+ID4gaW5zdGFsbCB0aW1lIGNoZWNrcy4KPiAKPiBJJ3ZlIHN1Ym1p
dHRlZCBhIHBhdGNoIHRoYXQgc2hvdWxkIGZpeCB0aGF0LiBJJ20gYWZyYWlkIHRoYXQgcmVtb3Zp
bmcKPiB0aGUgYnJjdGwvYnJjb25maWcgY2hlY2sgd2lsbCBicmluZyB0cm91YmxlLCBiZWNhdXNl
IHRoaXMgaXMgdXNlZCBpbgo+IGhvdHBsdWcgc2NyaXB0cyBhbmQgZXJyb3JzIG9uIGhvdHBsdWcg
c2NyaXB0cyBhcmUgaGFyZCB0byBzcG90IHJpZ2h0Cj4gbm93IGZvciByZWd1bGFyIHVzZXJzLgoK
VGhpcyBpcyB3aHkgSSBhbSBjb25jZXJuZWQgdGhhdCB3ZSBoYXZlIHJlbW92ZWQgdGhlIGluc3Rh
bGwgdGltZSBhcyB3ZWxsCmFzIHRoZSBkZXZlbG9wbWVudCB0aW1lIGNoZWNrcy4uLgoKUGVyaGFw
cyB3ZSBzaG91bGQgbW92ZSB0aGVzZSBuZXcgY2hlY2tzIHRvIGEgc2Vjb25kIGNvbmZpZ3VyZSBz
Y3JpcHQKd2hpY2ggY2FuIGJlIHJ1biBhdCBpbnN0YWxsIHRpbWUgYW5kIHByb2R1Y2VzIGFzIGl0
cyBvdXRwdXQganVzdCBhIHBhc3MKb3IgZmFpbD8KCklhbi4KCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:37:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09ZP-0002DH-JH; Wed, 22 Feb 2012 10:37:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S09ZO-0002D6-I8
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:37:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329907011!10191991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4396 invoked from network); 22 Feb 2012 10:36:51 -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;
	22 Feb 2012 10:36:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10866207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 10:36:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 10:36:51 +0000
Message-ID: <1329907009.2880.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 22 Feb 2012 10:36:49 +0000
In-Reply-To: <4F44C369.9020500@amd.com>
References: <4F44C369.9020500@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xenstore build failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 10:28 +0000, Christoph Egger wrote:
> Hi,
> 
> xenstore fails to build:
> 
> init-xenstore-domain.c:11:32: error: xen/sys/xenbus_dev.h: No such file 

This is the Linux /dev/xen/xenbus ioctl definitions used by the special
stub-xenstored domain building tool.

Since NetBSD presumably does not implement the necessary ioctls to
startup a non-dom0 xenstored I suggest you patch tools/xenstore/Makefile
and stubdom/Makefile to not build the stubxenstore or loader except on
Linux.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:37:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09ZP-0002DH-JH; Wed, 22 Feb 2012 10:37:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S09ZO-0002D6-I8
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:37:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329907011!10191991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4396 invoked from network); 22 Feb 2012 10:36:51 -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;
	22 Feb 2012 10:36:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10866207"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 10:36:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 10:36:51 +0000
Message-ID: <1329907009.2880.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 22 Feb 2012 10:36:49 +0000
In-Reply-To: <4F44C369.9020500@amd.com>
References: <4F44C369.9020500@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xenstore build failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 10:28 +0000, Christoph Egger wrote:
> Hi,
> 
> xenstore fails to build:
> 
> init-xenstore-domain.c:11:32: error: xen/sys/xenbus_dev.h: No such file 

This is the Linux /dev/xen/xenbus ioctl definitions used by the special
stub-xenstored domain building tool.

Since NetBSD presumably does not implement the necessary ioctls to
startup a non-dom0 xenstored I suggest you patch tools/xenstore/Makefile
and stubdom/Makefile to not build the stubxenstore or loader except on
Linux.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09nj-0002fJ-1h; Wed, 22 Feb 2012 10:51:59 +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 1S09nh-0002fE-Vh
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:51:58 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329907881!57748036!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4944 invoked from network); 22 Feb 2012 10:51:22 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.12)
	by server-13.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 10:51:22 -0000
Received: from mail169-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:51:45 +0000
Received: from mail169-tx2 (localhost [127.0.0.1])	by
	mail169-tx2-R.bigfish.com (Postfix) with ESMTP id C46A0200192;
	Wed, 22 Feb 2012 10:51:45 +0000 (UTC)
X-SpamScore: -18
X-BigFish: VPS-18(zzbb2dIc89bh148cM1102K1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail169-tx2 (localhost.localdomain [127.0.0.1]) by mail169-tx2
	(MessageSwitch) id 132990790436549_20263;
	Wed, 22 Feb 2012 10:51:44 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.246])	by
	mail169-tx2.bigfish.com (Postfix) with ESMTP id ED92D18004A;
	Wed, 22 Feb 2012 10:51:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:51:43 +0000
X-WSS-ID: 0LZSJI9-02-AAY-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 2EEE6C80C1;	Wed, 22 Feb 2012 04:51:44 -0600 (CST)
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, 22 Feb 2012 04:51:57 -0600
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, 22 Feb 2012 04:51:46 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	05:51:43 -0500
Message-ID: <4F44C8BE.4050809@amd.com>
Date: Wed, 22 Feb 2012 11:51:42 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
In-Reply-To: <CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMDIvMjIvMTIgMTE6MzAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gMjAxMi8yLzIyIENo
cmlzdG9waCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4+IE9uIDAyLzIyLzEyIDEw
OjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pj4KPj4+IDIwMTIvMi8yMiBDaHJpc3RvcGgg
RWdnZXI8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+Pj4+Cj4+Pj4KPj4+PiBIaSwKPj4+Pgo+
Pj4+IGNvbmZpZ3VyZSBmYWlscyBvbiBOZXRCU0QgdGhhdCB0aGVyZSBpcyBubyBicmN0bC4KPj4+
PiBOZXRCU0QgaGFzIG5vIGJyY3RsLCBOZXRCU0QgaGFzIGJyY29uZmlnLgo+Pj4KPj4+Cj4+PiBT
b3JyeSBDaHJpc3RvcGgsIHRoZSBicmN0bCB0ZXN0IGlzIGdvaW5nIGF3YXkgKGZyb20gY29uZmln
dXJlIGF0IGxlYXN0KS4KPj4KPj4KPj4gVGhlcmUgYXJlIHNvbWUgbW9yZSBMaW51eCBzcGVjaWZp
YyB0ZXN0czoKPj4gLSBpcAo+PiAtIHV1aWRfY2xlYXIgaW4gbGlidXVpZAo+Cj4gVGhhbmtzIGZv
ciByZXBvcnRpbmcsIEkgd2lsbCB0YWtlIGNhcmUgb2YgdGhvc2Ugb25jZSB0aGUgcGF0Y2ggaGFz
Cj4gcGFzc2VkIHRoZSB0ZXN0IHN5c3RlbSAoc29ycnkgZm9yIHRoYXQsIGJ1dCBJIGNhbm5vdCB0
ZXN0IG9uIHNvIG1hbnkKPiBzeXN0ZW1zKS4KPgo+PiBBbHNvIHRoZSBjaGVjayBmb3IgeWFqbF9h
bGxvYyBpbiBsaWJ5YWpsIGZhaWxzIGFsdGhvdWdoIEkgaGF2ZSBsaWJ5YWpsCj4+IHZlcnNpb24g
MSBpbnN0YWxsZWQuIFRoZSBjaGVjayBtYXkgYmUgY29ycmVjdCBidXQgY29uZmlndXJlIHNob3Vs
ZG4ndCBmYWlsCj4+IGlmIHZlcnNpb24gMSBpcyBzdGlsbCBzdXBwb3J0ZWQuCj4KPiBTaW5jZSBJ
IGd1ZXNzIHlvdSBoYXZlIGl0IGluIC91c3IvcGtnLywgaGF2ZSB5b3Ugc2V0IFBSRVBFTkRfTElC
IG9yCj4gQVBQRU5EX0xJQiBlbnYgdmFyaWFibGVzIGJlZm9yZSBleGVjdXRpbmcgY29uZmlndXJl
PwoKTm8sIEkgaGF2ZSBzZXQgRVhUUkFfTElCIGFuZCBFWFRSQV9JTkNMVURFUy4KSSB0cmllZCBi
b3RoIFBSRVBFTkRfTElCIGFuZCBBUFBFTkRfTElCIGFuZCB0aGF0IHdvcmtzLgoKT2ggYW5kIHRo
ZSBpbnRlZ2VyIHR5cGUgY2hlY2tzIGZhaWwuIFNuaXBwZXQgZnJvbSBjb25maWcubG9nOgoKY29u
ZmlndXJlOjc2MDA6IGNoZWNraW5nIGZvciBpbnQ2NF90CmNvbmZpZ3VyZTo3NjAwOiBnY2MgLWMg
LUkvdXNyL3BrZy9pbmNsdWRlIC1nIC1PMiBjb25mdGVzdC5jID4mNQpjb25mdGVzdC5jOiBJbiBm
dW5jdGlvbiAnbWFpbic6CmNvbmZ0ZXN0LmM6OTA6IGVycm9yOiBleHBlY3RlZCAnKScgYmVmb3Jl
ICc7JyB0b2tlbgpjb25mdGVzdC5jOjkxOiBlcnJvcjogZXhwZWN0ZWQgZXhwcmVzc2lvbiBiZWZv
cmUgJ10nIHRva2VuCmNvbmZpZ3VyZTogNzYwMDogJD8gPSAxCgpUaGUgdW5zaWduZWQgaW50ZWdl
ciB0eXBlIGNoZWNrcyBzdWNjZWVkLgoKQ2hyaXN0b3BoCgotLSAKLS0tdG8gc2F0aXNmeSBFdXJv
cGVhbiBMYXcgZm9yIGJ1c2luZXNzIGxldHRlcnM6CkFkdmFuY2VkIE1pY3JvIERldmljZXMgR21i
SApFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERvcm5hY2ggYi4gTXVlbmNoZW4KR2VzY2hhZWZ0c2Z1
ZWhyZXI6IEFsYmVydG8gQm96em8sIEFuZHJldyBCb3dkClNpdHo6IERvcm5hY2gsIEdlbWVpbmRl
IEFzY2hoZWltLCBMYW5ka3JlaXMgTXVlbmNoZW4KUmVnaXN0ZXJnZXJpY2h0IE11ZW5jaGVuLCBI
UkIgTnIuIDQzNjMyCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 10:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 10: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 1S09nj-0002fJ-1h; Wed, 22 Feb 2012 10:51:59 +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 1S09nh-0002fE-Vh
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 10:51:58 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329907881!57748036!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4944 invoked from network); 22 Feb 2012 10:51:22 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.12)
	by server-13.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 10:51:22 -0000
Received: from mail169-tx2-R.bigfish.com (10.9.14.235) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:51:45 +0000
Received: from mail169-tx2 (localhost [127.0.0.1])	by
	mail169-tx2-R.bigfish.com (Postfix) with ESMTP id C46A0200192;
	Wed, 22 Feb 2012 10:51:45 +0000 (UTC)
X-SpamScore: -18
X-BigFish: VPS-18(zzbb2dIc89bh148cM1102K1432N98dKzz1202hzz8275bhz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail169-tx2 (localhost.localdomain [127.0.0.1]) by mail169-tx2
	(MessageSwitch) id 132990790436549_20263;
	Wed, 22 Feb 2012 10:51:44 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.246])	by
	mail169-tx2.bigfish.com (Postfix) with ESMTP id ED92D18004A;
	Wed, 22 Feb 2012 10:51:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 10:51:43 +0000
X-WSS-ID: 0LZSJI9-02-AAY-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 2EEE6C80C1;	Wed, 22 Feb 2012 04:51:44 -0600 (CST)
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, 22 Feb 2012 04:51:57 -0600
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, 22 Feb 2012 04:51:46 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	05:51:43 -0500
Message-ID: <4F44C8BE.4050809@amd.com>
Date: Wed, 22 Feb 2012 11:51:42 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
In-Reply-To: <CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-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

T24gMDIvMjIvMTIgMTE6MzAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gMjAxMi8yLzIyIENo
cmlzdG9waCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4+IE9uIDAyLzIyLzEyIDEw
OjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pj4KPj4+IDIwMTIvMi8yMiBDaHJpc3RvcGgg
RWdnZXI8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+Pj4+Cj4+Pj4KPj4+PiBIaSwKPj4+Pgo+
Pj4+IGNvbmZpZ3VyZSBmYWlscyBvbiBOZXRCU0QgdGhhdCB0aGVyZSBpcyBubyBicmN0bC4KPj4+
PiBOZXRCU0QgaGFzIG5vIGJyY3RsLCBOZXRCU0QgaGFzIGJyY29uZmlnLgo+Pj4KPj4+Cj4+PiBT
b3JyeSBDaHJpc3RvcGgsIHRoZSBicmN0bCB0ZXN0IGlzIGdvaW5nIGF3YXkgKGZyb20gY29uZmln
dXJlIGF0IGxlYXN0KS4KPj4KPj4KPj4gVGhlcmUgYXJlIHNvbWUgbW9yZSBMaW51eCBzcGVjaWZp
YyB0ZXN0czoKPj4gLSBpcAo+PiAtIHV1aWRfY2xlYXIgaW4gbGlidXVpZAo+Cj4gVGhhbmtzIGZv
ciByZXBvcnRpbmcsIEkgd2lsbCB0YWtlIGNhcmUgb2YgdGhvc2Ugb25jZSB0aGUgcGF0Y2ggaGFz
Cj4gcGFzc2VkIHRoZSB0ZXN0IHN5c3RlbSAoc29ycnkgZm9yIHRoYXQsIGJ1dCBJIGNhbm5vdCB0
ZXN0IG9uIHNvIG1hbnkKPiBzeXN0ZW1zKS4KPgo+PiBBbHNvIHRoZSBjaGVjayBmb3IgeWFqbF9h
bGxvYyBpbiBsaWJ5YWpsIGZhaWxzIGFsdGhvdWdoIEkgaGF2ZSBsaWJ5YWpsCj4+IHZlcnNpb24g
MSBpbnN0YWxsZWQuIFRoZSBjaGVjayBtYXkgYmUgY29ycmVjdCBidXQgY29uZmlndXJlIHNob3Vs
ZG4ndCBmYWlsCj4+IGlmIHZlcnNpb24gMSBpcyBzdGlsbCBzdXBwb3J0ZWQuCj4KPiBTaW5jZSBJ
IGd1ZXNzIHlvdSBoYXZlIGl0IGluIC91c3IvcGtnLywgaGF2ZSB5b3Ugc2V0IFBSRVBFTkRfTElC
IG9yCj4gQVBQRU5EX0xJQiBlbnYgdmFyaWFibGVzIGJlZm9yZSBleGVjdXRpbmcgY29uZmlndXJl
PwoKTm8sIEkgaGF2ZSBzZXQgRVhUUkFfTElCIGFuZCBFWFRSQV9JTkNMVURFUy4KSSB0cmllZCBi
b3RoIFBSRVBFTkRfTElCIGFuZCBBUFBFTkRfTElCIGFuZCB0aGF0IHdvcmtzLgoKT2ggYW5kIHRo
ZSBpbnRlZ2VyIHR5cGUgY2hlY2tzIGZhaWwuIFNuaXBwZXQgZnJvbSBjb25maWcubG9nOgoKY29u
ZmlndXJlOjc2MDA6IGNoZWNraW5nIGZvciBpbnQ2NF90CmNvbmZpZ3VyZTo3NjAwOiBnY2MgLWMg
LUkvdXNyL3BrZy9pbmNsdWRlIC1nIC1PMiBjb25mdGVzdC5jID4mNQpjb25mdGVzdC5jOiBJbiBm
dW5jdGlvbiAnbWFpbic6CmNvbmZ0ZXN0LmM6OTA6IGVycm9yOiBleHBlY3RlZCAnKScgYmVmb3Jl
ICc7JyB0b2tlbgpjb25mdGVzdC5jOjkxOiBlcnJvcjogZXhwZWN0ZWQgZXhwcmVzc2lvbiBiZWZv
cmUgJ10nIHRva2VuCmNvbmZpZ3VyZTogNzYwMDogJD8gPSAxCgpUaGUgdW5zaWduZWQgaW50ZWdl
ciB0eXBlIGNoZWNrcyBzdWNjZWVkLgoKQ2hyaXN0b3BoCgotLSAKLS0tdG8gc2F0aXNmeSBFdXJv
cGVhbiBMYXcgZm9yIGJ1c2luZXNzIGxldHRlcnM6CkFkdmFuY2VkIE1pY3JvIERldmljZXMgR21i
SApFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERvcm5hY2ggYi4gTXVlbmNoZW4KR2VzY2hhZWZ0c2Z1
ZWhyZXI6IEFsYmVydG8gQm96em8sIEFuZHJldyBCb3dkClNpdHo6IERvcm5hY2gsIEdlbWVpbmRl
IEFzY2hoZWltLCBMYW5ka3JlaXMgTXVlbmNoZW4KUmVnaXN0ZXJnZXJpY2h0IE11ZW5jaGVuLCBI
UkIgTnIuIDQzNjMyCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:05:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0A0W-0002rW-CI; Wed, 22 Feb 2012 11:05:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0A0U-0002rO-Is
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:05:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329908703!14408695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2670 invoked from network); 22 Feb 2012 11:05:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:05:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10867741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:05:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:05:02 +0000
Message-ID: <1329908701.2880.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 22 Feb 2012 11:05:01 +0000
In-Reply-To: <4F430201.3040208@oracle.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
	<4F430201.3040208@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>, young
	zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 02:31 +0000, ANNIE LI wrote:
> 
> On 2012-2-21 7:54, Zhang, Yang Z wrote:
> >> -----Original Message-----
> >> From: young zhang [mailto:young.zhang.free@gmail.com]
> >> Sent: Monday, February 20, 2012 11:04 PM
> >> To: Zhang, Yang Z
> >> Cc: ANNIE LI; xen-devel@lists.xensource.com; Kurt Hackel; Dan Magenheimer;
> >> Konrad Rzeszutek Wilk
> >> Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
> >> to tm->tm_year
> >>
> >> The mktime which used in xen is different from standard C. I think the best way is
> >> change it same as normal mktime, or else, other people will make the same
> >> mistake too.
> > yes. The name will mislead the people who not look into the code, including me. :)
> 
> I compared the mktime of xen with mktime of linux. The code is almost 
> the same, I do not understand why xen requires the input year is 
> tm->tm_year, not tm->tm_year+1900. Am I missing somthing?

The Linux kernel's version of mktime and Xen's version both differ from
standard C/POSIX defined function (in fact I expect Xen's is derived
from Linux's). Not least because they take a bunch of values instead of
a struct tm as arguments (i.e. they take unsigned int year, not
tm->tm_year).

If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
want the libc version. The Xen and Linux mktime()s certainly differ
substantially from the eglibc one.

I don't think you can expect that the in-kernel mktime necessarily has
the same interface as POSIX documents, there is certainly no particular
reason why they should or must (a kernel is not a POSIX environment).
The comment preceding Xen's mktime makes no mention of offsetting
anything by 1900 (or anything else) and I believe its implementation is
consistent with its defined interface.

Ian.

> See following diff file which is created between mktime of linux and 
> mktime of xen, (I did some tab/space format changes for comparison)
> 
> diff linux-mktime.c xen-mktime.c
> 2,4c2,4
> < mktime(const unsigned int year0, const unsigned int mon0,
> <       const unsigned int day, const unsigned int hour,
> <       const unsigned int min, const unsigned int sec)
> ---
>  > mktime (unsigned int year, unsigned int mon,
>  >       unsigned int day, unsigned int hour,
>  >       unsigned int min, unsigned int sec)
> 6,8c6
> <       unsigned int mon = mon0, year = year0;
> <
> <       /* 1..12 -> 11,12,1..10 */
> ---
>  >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
> 10c8
> <               mon += 12;      /* Puts Feb last since it has leap day */
> ---
>  >               mon += 12;
> 21d18
> <
> 
> Thanks
> Annie
> >
> > best regards
> > yang
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:05:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0A0W-0002rW-CI; Wed, 22 Feb 2012 11:05:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0A0U-0002rO-Is
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:05:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329908703!14408695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2670 invoked from network); 22 Feb 2012 11:05:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:05:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10867741"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:05:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:05:02 +0000
Message-ID: <1329908701.2880.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 22 Feb 2012 11:05:01 +0000
In-Reply-To: <4F430201.3040208@oracle.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
	<4F430201.3040208@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>, young
	zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 02:31 +0000, ANNIE LI wrote:
> 
> On 2012-2-21 7:54, Zhang, Yang Z wrote:
> >> -----Original Message-----
> >> From: young zhang [mailto:young.zhang.free@gmail.com]
> >> Sent: Monday, February 20, 2012 11:04 PM
> >> To: Zhang, Yang Z
> >> Cc: ANNIE LI; xen-devel@lists.xensource.com; Kurt Hackel; Dan Magenheimer;
> >> Konrad Rzeszutek Wilk
> >> Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error due
> >> to tm->tm_year
> >>
> >> The mktime which used in xen is different from standard C. I think the best way is
> >> change it same as normal mktime, or else, other people will make the same
> >> mistake too.
> > yes. The name will mislead the people who not look into the code, including me. :)
> 
> I compared the mktime of xen with mktime of linux. The code is almost 
> the same, I do not understand why xen requires the input year is 
> tm->tm_year, not tm->tm_year+1900. Am I missing somthing?

The Linux kernel's version of mktime and Xen's version both differ from
standard C/POSIX defined function (in fact I expect Xen's is derived
from Linux's). Not least because they take a bunch of values instead of
a struct tm as arguments (i.e. they take unsigned int year, not
tm->tm_year).

If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
want the libc version. The Xen and Linux mktime()s certainly differ
substantially from the eglibc one.

I don't think you can expect that the in-kernel mktime necessarily has
the same interface as POSIX documents, there is certainly no particular
reason why they should or must (a kernel is not a POSIX environment).
The comment preceding Xen's mktime makes no mention of offsetting
anything by 1900 (or anything else) and I believe its implementation is
consistent with its defined interface.

Ian.

> See following diff file which is created between mktime of linux and 
> mktime of xen, (I did some tab/space format changes for comparison)
> 
> diff linux-mktime.c xen-mktime.c
> 2,4c2,4
> < mktime(const unsigned int year0, const unsigned int mon0,
> <       const unsigned int day, const unsigned int hour,
> <       const unsigned int min, const unsigned int sec)
> ---
>  > mktime (unsigned int year, unsigned int mon,
>  >       unsigned int day, unsigned int hour,
>  >       unsigned int min, unsigned int sec)
> 6,8c6
> <       unsigned int mon = mon0, year = year0;
> <
> <       /* 1..12 -> 11,12,1..10 */
> ---
>  >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
> 10c8
> <               mon += 12;      /* Puts Feb last since it has leap day */
> ---
>  >               mon += 12;
> 21d18
> <
> 
> Thanks
> Annie
> >
> > best regards
> > yang
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0A2B-0002vQ-SD; Wed, 22 Feb 2012 11:06:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1S0A29-0002v6-LP
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:06:53 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329908806!3992266!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6491 invoked from network); 22 Feb 2012 11:06:47 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 11:06:47 -0000
Received: from mail70-ch1-R.bigfish.com (10.43.68.241) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 11:06:40 +0000
Received: from mail70-ch1 (localhost [127.0.0.1])	by mail70-ch1-R.bigfish.com
	(Postfix) with ESMTP id 497BD1A0442	for
	<xen-devel@lists.xensource.com>; Wed,
	22 Feb 2012 11:06:40 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1
	(MessageSwitch) id 1329908798959724_26713;
	Wed, 22 Feb 2012 11:06:38 +0000 (UTC)
Received: from CH1EHSMHS020.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.229])	by mail70-ch1.bigfish.com (Postfix) with ESMTP id
	E76F82004C for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 11:06:38 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 11:06:38 +0000
X-WSS-ID: 0LZSK73-02-BIO-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 2FE9CC80BF	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 05:06:39 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 22 Feb 2012 05:06:52 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 22 Feb 2012 05:06:41 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	06:06:40 -0500
Message-ID: <4F44CC3E.1020702@amd.com>
Date: Wed, 22 Feb 2012 12:06:38 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------020108010607020306070401"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xenstore: build fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------020108010607020306070401
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Build stubxenstore only when building stubdomain.
Fixes build failure on platforms w/o stubdomain support.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------020108010607020306070401
Content-Type: text/plain; name="xen_tools_xenstore.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_xenstore.diff"
Content-Description: xen_tools_xenstore.diff

diff -r 6e2835b65842 tools/xenstore/Makefile
--- a/tools/xenstore/Makefile	Wed Feb 22 10:44:13 2012 +0100
+++ b/tools/xenstore/Makefile	Wed Feb 22 12:05:13 2012 +0100
@@ -27,10 +27,11 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
+ALL_TARGETS += init-xenstore-domain
 endif
 
 .PHONY: all

--------------020108010607020306070401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020108010607020306070401--


From xen-devel-bounces@lists.xen.org Wed Feb 22 11:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0A2B-0002vQ-SD; Wed, 22 Feb 2012 11:06:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1S0A29-0002v6-LP
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:06:53 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329908806!3992266!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6491 invoked from network); 22 Feb 2012 11:06:47 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 11:06:47 -0000
Received: from mail70-ch1-R.bigfish.com (10.43.68.241) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 11:06:40 +0000
Received: from mail70-ch1 (localhost [127.0.0.1])	by mail70-ch1-R.bigfish.com
	(Postfix) with ESMTP id 497BD1A0442	for
	<xen-devel@lists.xensource.com>; Wed,
	22 Feb 2012 11:06:40 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1
	(MessageSwitch) id 1329908798959724_26713;
	Wed, 22 Feb 2012 11:06:38 +0000 (UTC)
Received: from CH1EHSMHS020.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.229])	by mail70-ch1.bigfish.com (Postfix) with ESMTP id
	E76F82004C for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 11:06:38 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 11:06:38 +0000
X-WSS-ID: 0LZSK73-02-BIO-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 2FE9CC80BF	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 05:06:39 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 22 Feb 2012 05:06:52 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 22 Feb 2012 05:06:41 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	06:06:40 -0500
Message-ID: <4F44CC3E.1020702@amd.com>
Date: Wed, 22 Feb 2012 12:06:38 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------020108010607020306070401"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xenstore: build fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------020108010607020306070401
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Build stubxenstore only when building stubdomain.
Fixes build failure on platforms w/o stubdomain support.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------020108010607020306070401
Content-Type: text/plain; name="xen_tools_xenstore.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_tools_xenstore.diff"
Content-Description: xen_tools_xenstore.diff

diff -r 6e2835b65842 tools/xenstore/Makefile
--- a/tools/xenstore/Makefile	Wed Feb 22 10:44:13 2012 +0100
+++ b/tools/xenstore/Makefile	Wed Feb 22 12:05:13 2012 +0100
@@ -27,10 +27,11 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
+ALL_TARGETS += init-xenstore-domain
 endif
 
 .PHONY: all

--------------020108010607020306070401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020108010607020306070401--


From xen-devel-bounces@lists.xen.org Wed Feb 22 11:14:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0A9a-0003Ak-QZ; Wed, 22 Feb 2012 11:14: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 1S0A9a-0003Af-28
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:14:34 +0000
Received: from [85.158.139.83:49717] by server-2.bemta-5.messagelabs.com id
	0D/2B-20263-91EC44F4; Wed, 22 Feb 2012 11:14:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329909272!15268902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9650 invoked from network); 22 Feb 2012 11:14:32 -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;
	22 Feb 2012 11:14:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10868037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:14:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:14:32 +0000
Message-ID: <1329909271.2880.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 22 Feb 2012 11:14:31 +0000
In-Reply-To: <20120221213623.GB28154@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
	<20120221213623.GB28154@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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 Tue, 2012-02-21 at 21:36 +0000, Konrad Rzeszutek Wilk wrote:
[...]
> > With that in mind, I believe that all of the required information
> > about discard is still present in blkif.h, but perhaps presented
> > differently or moved to different sections.  Can you be more
> > specific about the information that you feel is missing here and
> > in the other places you noted below?
> 
> The original statement about how the backend would determine how
> to expose this information.

Please can you quote the actual text of the statements which you think
are missing and/or should be retained so we know precisely what you are
talking about.

> > The comment block here mirrors the language of all the other feature
> > flags.  Do you believe they should be changed in some way too?
> 
> Well, the desire (mine) is to include as much details (or even more) in the
> spec so that it can be read as a novel if desired.
> 
> But I will defer to Ian - if he is OK then this shouldn't gate
> the acceptance of this patch which is a step forward.

Perhaps details which aren't part of the formal spec, e.g.
implementation tips, details of various OSes implementation choices etc
could be kept elsewhere, e.g. on the wiki?

The problem with including these sorts of things in the spec is that you
then have to get all pedantic about which statements are normative and
which are just quirks or details of a particular valid implementation of
the spec etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:14:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0A9a-0003Ak-QZ; Wed, 22 Feb 2012 11:14: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 1S0A9a-0003Af-28
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:14:34 +0000
Received: from [85.158.139.83:49717] by server-2.bemta-5.messagelabs.com id
	0D/2B-20263-91EC44F4; Wed, 22 Feb 2012 11:14:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329909272!15268902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9650 invoked from network); 22 Feb 2012 11:14:32 -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;
	22 Feb 2012 11:14:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10868037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:14:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:14:32 +0000
Message-ID: <1329909271.2880.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 22 Feb 2012 11:14:31 +0000
In-Reply-To: <20120221213623.GB28154@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
	<20120221213623.GB28154@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif 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 Tue, 2012-02-21 at 21:36 +0000, Konrad Rzeszutek Wilk wrote:
[...]
> > With that in mind, I believe that all of the required information
> > about discard is still present in blkif.h, but perhaps presented
> > differently or moved to different sections.  Can you be more
> > specific about the information that you feel is missing here and
> > in the other places you noted below?
> 
> The original statement about how the backend would determine how
> to expose this information.

Please can you quote the actual text of the statements which you think
are missing and/or should be retained so we know precisely what you are
talking about.

> > The comment block here mirrors the language of all the other feature
> > flags.  Do you believe they should be changed in some way too?
> 
> Well, the desire (mine) is to include as much details (or even more) in the
> spec so that it can be read as a novel if desired.
> 
> But I will defer to Ian - if he is OK then this shouldn't gate
> the acceptance of this patch which is a step forward.

Perhaps details which aren't part of the formal spec, e.g.
implementation tips, details of various OSes implementation choices etc
could be kept elsewhere, e.g. on the wiki?

The problem with including these sorts of things in the spec is that you
then have to get all pedantic about which statements are normative and
which are just quirks or details of a particular valid implementation of
the spec etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:16:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0AB9-0003Gu-Ft; Wed, 22 Feb 2012 11: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.Campbell@citrix.com>) id 1S0AB8-0003Gm-D6
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:16:10 +0000
Received: from [85.158.139.83:16813] by server-5.bemta-5.messagelabs.com id
	07/4B-13566-97EC44F4; Wed, 22 Feb 2012 11:16:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329909368!16122168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31747 invoked from network); 22 Feb 2012 11:16: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;
	22 Feb 2012 11:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10868093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:15:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:15:52 +0000
Message-ID: <1329909351.2880.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 22 Feb 2012 11:15:51 +0000
In-Reply-To: <4F44CC3E.1020702@amd.com>
References: <4F44CC3E.1020702@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenstore: build fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 11:06 +0000, Christoph Egger wrote:
> Build stubxenstore only when building stubdomain.
> Fixes build failure on platforms w/o stubdomain support.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Strictly speaking it is possible for a platform to support stub domains
but not the necessary dom0 kernel interface to use this particular stub
domain -- but we can cross that bridge if/when we come to it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:16:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0AB9-0003Gu-Ft; Wed, 22 Feb 2012 11: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.Campbell@citrix.com>) id 1S0AB8-0003Gm-D6
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:16:10 +0000
Received: from [85.158.139.83:16813] by server-5.bemta-5.messagelabs.com id
	07/4B-13566-97EC44F4; Wed, 22 Feb 2012 11:16:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329909368!16122168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31747 invoked from network); 22 Feb 2012 11:16: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;
	22 Feb 2012 11:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10868093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:15:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:15:52 +0000
Message-ID: <1329909351.2880.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Wed, 22 Feb 2012 11:15:51 +0000
In-Reply-To: <4F44CC3E.1020702@amd.com>
References: <4F44CC3E.1020702@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenstore: build fix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 11:06 +0000, Christoph Egger wrote:
> Build stubxenstore only when building stubdomain.
> Fixes build failure on platforms w/o stubdomain support.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Strictly speaking it is possible for a platform to support stub domains
but not the necessary dom0 kernel interface to use this particular stub
domain -- but we can cross that bridge if/when we come to it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0AEV-0003be-3u; Wed, 22 Feb 2012 11:19:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0AEU-0003bL-Ez
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:19:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329909520!55278413!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 860 invoked from network); 22 Feb 2012 11:18:40 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:18:40 -0000
Received: by wibhm2 with SMTP id hm2so15802936wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 03:19:32 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr44486968wia.3.1329909572320 (num_hops
	= 1); Wed, 22 Feb 2012 03:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=M6GD1DvQZbn5GSMRS5yLNTv3FHkwbEB9SarJnHQOM1s=;
	b=Js7blPj4+90dCsdoAqzMKJcUef90+Wwz3Fq1CCnhv8kmOLFA1aJnSzsWxqx6A4KxLE
	QPhvvwqaSMhMpk7LCe2rid3GP/siyUld7UUrkhB5vM6BVPTnnWrmh09m5mOVAm+RpwnJ
	/ecw8c+bjXUEocPPY9cjNY8eQlrUmCyXetVZc=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr36885237wia.3.1329909572183; Wed,
	22 Feb 2012 03:19:32 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 03:19:32 -0800 (PST)
In-Reply-To: <4F44C8BE.4050809@amd.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
	<4F44C8BE.4050809@amd.com>
Date: Wed, 22 Feb 2012 12:19:32 +0100
X-Google-Sender-Auth: FMjM22IvtmzKGfRDXbj6tQIkzeY
Message-ID: <CAPLaKK6y6Ofygn_bwDXQK_mT+xEDb9FmFCsSSJsezgvO66z7cQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+IE9u
IDAyLzIyLzEyIDExOjMwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pgo+PiAyMDEyLzIvMjIg
Q2hyaXN0b3BoIEVnZ2VyPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPj4+Cj4+PiBPbiAwMi8y
Mi8xMiAxMDo1OSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4+Pgo+Pj4+Cj4+Pj4gMjAxMi8y
LzIyIENocmlzdG9waCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4+Pj4+Cj4+Pj4+
Cj4+Pj4+Cj4+Pj4+IEhpLAo+Pj4+Pgo+Pj4+PiBjb25maWd1cmUgZmFpbHMgb24gTmV0QlNEIHRo
YXQgdGhlcmUgaXMgbm8gYnJjdGwuCj4+Pj4+IE5ldEJTRCBoYXMgbm8gYnJjdGwsIE5ldEJTRCBo
YXMgYnJjb25maWcuCj4+Pj4KPj4+Pgo+Pj4+Cj4+Pj4gU29ycnkgQ2hyaXN0b3BoLCB0aGUgYnJj
dGwgdGVzdCBpcyBnb2luZyBhd2F5IChmcm9tIGNvbmZpZ3VyZSBhdCBsZWFzdCkuCj4+Pgo+Pj4K
Pj4+Cj4+PiBUaGVyZSBhcmUgc29tZSBtb3JlIExpbnV4IHNwZWNpZmljIHRlc3RzOgo+Pj4gLSBp
cAo+Pj4gLSB1dWlkX2NsZWFyIGluIGxpYnV1aWQKPj4KPj4KPj4gVGhhbmtzIGZvciByZXBvcnRp
bmcsIEkgd2lsbCB0YWtlIGNhcmUgb2YgdGhvc2Ugb25jZSB0aGUgcGF0Y2ggaGFzCj4+IHBhc3Nl
ZCB0aGUgdGVzdCBzeXN0ZW0gKHNvcnJ5IGZvciB0aGF0LCBidXQgSSBjYW5ub3QgdGVzdCBvbiBz
byBtYW55Cj4+IHN5c3RlbXMpLgo+Pgo+Pj4gQWxzbyB0aGUgY2hlY2sgZm9yIHlhamxfYWxsb2Mg
aW4gbGlieWFqbCBmYWlscyBhbHRob3VnaCBJIGhhdmUgbGlieWFqbAo+Pj4gdmVyc2lvbiAxIGlu
c3RhbGxlZC4gVGhlIGNoZWNrIG1heSBiZSBjb3JyZWN0IGJ1dCBjb25maWd1cmUgc2hvdWxkbid0
Cj4+PiBmYWlsCj4+PiBpZiB2ZXJzaW9uIDEgaXMgc3RpbGwgc3VwcG9ydGVkLgo+Pgo+Pgo+PiBT
aW5jZSBJIGd1ZXNzIHlvdSBoYXZlIGl0IGluIC91c3IvcGtnLywgaGF2ZSB5b3Ugc2V0IFBSRVBF
TkRfTElCIG9yCj4+IEFQUEVORF9MSUIgZW52IHZhcmlhYmxlcyBiZWZvcmUgZXhlY3V0aW5nIGNv
bmZpZ3VyZT8KPgo+Cj4gTm8sIEkgaGF2ZSBzZXQgRVhUUkFfTElCIGFuZCBFWFRSQV9JTkNMVURF
Uy4KPiBJIHRyaWVkIGJvdGggUFJFUEVORF9MSUIgYW5kIEFQUEVORF9MSUIgYW5kIHRoYXQgd29y
a3MuCgpFWFRSQV9MSUIgYW5kIEVYVFJBX0lOQ0xVREVTIGlzIGRlcHJlY2F0ZWQgaW4gZmF2b3Ig
b2YgUFJFUEVORF8gYW5kCkFQUEVORF8sIHdoaWNoIGl0J3MgYmFzaWNhbGx5IHRoZSBzYW1lIGJ1
dCBhbGxvd3MgYSBtb3JlIGZpbmUgZ3JhaW5lZApjb250cm9sLgoKPgo+IE9oIGFuZCB0aGUgaW50
ZWdlciB0eXBlIGNoZWNrcyBmYWlsLiBTbmlwcGV0IGZyb20gY29uZmlnLmxvZzoKPgo+IGNvbmZp
Z3VyZTo3NjAwOiBjaGVja2luZyBmb3IgaW50NjRfdAo+IGNvbmZpZ3VyZTo3NjAwOiBnY2MgLWMg
LUkvdXNyL3BrZy9pbmNsdWRlIC1nIC1PMiBjb25mdGVzdC5jID4mNQo+IGNvbmZ0ZXN0LmM6IElu
IGZ1bmN0aW9uICdtYWluJzoKPiBjb25mdGVzdC5jOjkwOiBlcnJvcjogZXhwZWN0ZWQgJyknIGJl
Zm9yZSAnOycgdG9rZW4KPiBjb25mdGVzdC5jOjkxOiBlcnJvcjogZXhwZWN0ZWQgZXhwcmVzc2lv
biBiZWZvcmUgJ10nIHRva2VuCj4gY29uZmlndXJlOiA3NjAwOiAkPyA9IDEKClRoaXMgd2FzIGFk
ZGVkIGJ5IGRlZmF1bHQgd2hlbiBydW5uaW5nIGF1dG9zY2FuLCBJIGd1ZXNzIHdlIGNhbgpkaXNh
YmxlIHRob3NlIGNoZWNrcy4KCj4KPiBUaGUgdW5zaWduZWQgaW50ZWdlciB0eXBlIGNoZWNrcyBz
dWNjZWVkLgo+Cj4KPiBDaHJpc3RvcGgKPgo+IC0tCj4gLS0tdG8gc2F0aXNmeSBFdXJvcGVhbiBM
YXcgZm9yIGJ1c2luZXNzIGxldHRlcnM6Cj4gQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBHbWJICj4g
RWluc3RlaW5yaW5nIDI0LCA4NTY4OSBEb3JuYWNoIGIuIE11ZW5jaGVuCj4gR2VzY2hhZWZ0c2Z1
ZWhyZXI6IEFsYmVydG8gQm96em8sIEFuZHJldyBCb3dkCj4gU2l0ejogRG9ybmFjaCwgR2VtZWlu
ZGUgQXNjaGhlaW0sIExhbmRrcmVpcyBNdWVuY2hlbgo+IFJlZ2lzdGVyZ2VyaWNodCBNdWVuY2hl
biwgSFJCIE5yLiA0MzYzMgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0AEV-0003be-3u; Wed, 22 Feb 2012 11:19:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0AEU-0003bL-Ez
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:19:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1329909520!55278413!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 860 invoked from network); 22 Feb 2012 11:18:40 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:18:40 -0000
Received: by wibhm2 with SMTP id hm2so15802936wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 03:19:32 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr44486968wia.3.1329909572320 (num_hops
	= 1); Wed, 22 Feb 2012 03:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=M6GD1DvQZbn5GSMRS5yLNTv3FHkwbEB9SarJnHQOM1s=;
	b=Js7blPj4+90dCsdoAqzMKJcUef90+Wwz3Fq1CCnhv8kmOLFA1aJnSzsWxqx6A4KxLE
	QPhvvwqaSMhMpk7LCe2rid3GP/siyUld7UUrkhB5vM6BVPTnnWrmh09m5mOVAm+RpwnJ
	/ecw8c+bjXUEocPPY9cjNY8eQlrUmCyXetVZc=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr36885237wia.3.1329909572183; Wed,
	22 Feb 2012 03:19:32 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 03:19:32 -0800 (PST)
In-Reply-To: <4F44C8BE.4050809@amd.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK7dh6VfPkM5gJGwprCSEfN_CsnCEe6ELD7=MjQsP_yWDA@mail.gmail.com>
	<4F44C8BE.4050809@amd.com>
Date: Wed, 22 Feb 2012 12:19:32 +0100
X-Google-Sender-Auth: FMjM22IvtmzKGfRDXbj6tQIkzeY
Message-ID: <CAPLaKK6y6Ofygn_bwDXQK_mT+xEDb9FmFCsSSJsezgvO66z7cQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+IE9u
IDAyLzIyLzEyIDExOjMwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pgo+PiAyMDEyLzIvMjIg
Q2hyaXN0b3BoIEVnZ2VyPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPj4+Cj4+PiBPbiAwMi8y
Mi8xMiAxMDo1OSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4+Pgo+Pj4+Cj4+Pj4gMjAxMi8y
LzIyIENocmlzdG9waCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4+Pj4+Cj4+Pj4+
Cj4+Pj4+Cj4+Pj4+IEhpLAo+Pj4+Pgo+Pj4+PiBjb25maWd1cmUgZmFpbHMgb24gTmV0QlNEIHRo
YXQgdGhlcmUgaXMgbm8gYnJjdGwuCj4+Pj4+IE5ldEJTRCBoYXMgbm8gYnJjdGwsIE5ldEJTRCBo
YXMgYnJjb25maWcuCj4+Pj4KPj4+Pgo+Pj4+Cj4+Pj4gU29ycnkgQ2hyaXN0b3BoLCB0aGUgYnJj
dGwgdGVzdCBpcyBnb2luZyBhd2F5IChmcm9tIGNvbmZpZ3VyZSBhdCBsZWFzdCkuCj4+Pgo+Pj4K
Pj4+Cj4+PiBUaGVyZSBhcmUgc29tZSBtb3JlIExpbnV4IHNwZWNpZmljIHRlc3RzOgo+Pj4gLSBp
cAo+Pj4gLSB1dWlkX2NsZWFyIGluIGxpYnV1aWQKPj4KPj4KPj4gVGhhbmtzIGZvciByZXBvcnRp
bmcsIEkgd2lsbCB0YWtlIGNhcmUgb2YgdGhvc2Ugb25jZSB0aGUgcGF0Y2ggaGFzCj4+IHBhc3Nl
ZCB0aGUgdGVzdCBzeXN0ZW0gKHNvcnJ5IGZvciB0aGF0LCBidXQgSSBjYW5ub3QgdGVzdCBvbiBz
byBtYW55Cj4+IHN5c3RlbXMpLgo+Pgo+Pj4gQWxzbyB0aGUgY2hlY2sgZm9yIHlhamxfYWxsb2Mg
aW4gbGlieWFqbCBmYWlscyBhbHRob3VnaCBJIGhhdmUgbGlieWFqbAo+Pj4gdmVyc2lvbiAxIGlu
c3RhbGxlZC4gVGhlIGNoZWNrIG1heSBiZSBjb3JyZWN0IGJ1dCBjb25maWd1cmUgc2hvdWxkbid0
Cj4+PiBmYWlsCj4+PiBpZiB2ZXJzaW9uIDEgaXMgc3RpbGwgc3VwcG9ydGVkLgo+Pgo+Pgo+PiBT
aW5jZSBJIGd1ZXNzIHlvdSBoYXZlIGl0IGluIC91c3IvcGtnLywgaGF2ZSB5b3Ugc2V0IFBSRVBF
TkRfTElCIG9yCj4+IEFQUEVORF9MSUIgZW52IHZhcmlhYmxlcyBiZWZvcmUgZXhlY3V0aW5nIGNv
bmZpZ3VyZT8KPgo+Cj4gTm8sIEkgaGF2ZSBzZXQgRVhUUkFfTElCIGFuZCBFWFRSQV9JTkNMVURF
Uy4KPiBJIHRyaWVkIGJvdGggUFJFUEVORF9MSUIgYW5kIEFQUEVORF9MSUIgYW5kIHRoYXQgd29y
a3MuCgpFWFRSQV9MSUIgYW5kIEVYVFJBX0lOQ0xVREVTIGlzIGRlcHJlY2F0ZWQgaW4gZmF2b3Ig
b2YgUFJFUEVORF8gYW5kCkFQUEVORF8sIHdoaWNoIGl0J3MgYmFzaWNhbGx5IHRoZSBzYW1lIGJ1
dCBhbGxvd3MgYSBtb3JlIGZpbmUgZ3JhaW5lZApjb250cm9sLgoKPgo+IE9oIGFuZCB0aGUgaW50
ZWdlciB0eXBlIGNoZWNrcyBmYWlsLiBTbmlwcGV0IGZyb20gY29uZmlnLmxvZzoKPgo+IGNvbmZp
Z3VyZTo3NjAwOiBjaGVja2luZyBmb3IgaW50NjRfdAo+IGNvbmZpZ3VyZTo3NjAwOiBnY2MgLWMg
LUkvdXNyL3BrZy9pbmNsdWRlIC1nIC1PMiBjb25mdGVzdC5jID4mNQo+IGNvbmZ0ZXN0LmM6IElu
IGZ1bmN0aW9uICdtYWluJzoKPiBjb25mdGVzdC5jOjkwOiBlcnJvcjogZXhwZWN0ZWQgJyknIGJl
Zm9yZSAnOycgdG9rZW4KPiBjb25mdGVzdC5jOjkxOiBlcnJvcjogZXhwZWN0ZWQgZXhwcmVzc2lv
biBiZWZvcmUgJ10nIHRva2VuCj4gY29uZmlndXJlOiA3NjAwOiAkPyA9IDEKClRoaXMgd2FzIGFk
ZGVkIGJ5IGRlZmF1bHQgd2hlbiBydW5uaW5nIGF1dG9zY2FuLCBJIGd1ZXNzIHdlIGNhbgpkaXNh
YmxlIHRob3NlIGNoZWNrcy4KCj4KPiBUaGUgdW5zaWduZWQgaW50ZWdlciB0eXBlIGNoZWNrcyBz
dWNjZWVkLgo+Cj4KPiBDaHJpc3RvcGgKPgo+IC0tCj4gLS0tdG8gc2F0aXNmeSBFdXJvcGVhbiBM
YXcgZm9yIGJ1c2luZXNzIGxldHRlcnM6Cj4gQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBHbWJICj4g
RWluc3RlaW5yaW5nIDI0LCA4NTY4OSBEb3JuYWNoIGIuIE11ZW5jaGVuCj4gR2VzY2hhZWZ0c2Z1
ZWhyZXI6IEFsYmVydG8gQm96em8sIEFuZHJldyBCb3dkCj4gU2l0ejogRG9ybmFjaCwgR2VtZWlu
ZGUgQXNjaGhlaW0sIExhbmRrcmVpcyBNdWVuY2hlbgo+IFJlZ2lzdGVyZ2VyaWNodCBNdWVuY2hl
biwgSFJCIE5yLiA0MzYzMgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0AOJ-0003pT-Sm; Wed, 22 Feb 2012 11:29:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0AOI-0003pL-CQ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:29:46 +0000
Received: from [85.158.139.83:61458] by server-12.bemta-5.messagelabs.com id
	AD/A4-24595-9A1D44F4; Wed, 22 Feb 2012 11:29:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329910184!4859618!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16724 invoked from network); 22 Feb 2012 11:29:44 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:29:44 -0000
Received: by wibhm2 with SMTP id hm2so15820886wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 03:29:44 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr44588146wia.3.1329910184795 (num_hops
	= 1); Wed, 22 Feb 2012 03:29:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=X9nr2oQxGwuqldCxDyLW+uhPC8ydZ7l+7S8GW2fiP/I=;
	b=mUmvfsFGDs29GlByK7QEVoRqz+yr1SGmoblwmw1vzhEk6kdl+PTt8VmjInT+lAOR6t
	20S/y698aSXhEq256mUgz7X0bDr/r4y8c7oIaxiwvNSuKdeQa2FTGEG5LsWtvYTouVOE
	PtTu9XMFRd3IJlKTaSmHZjHk4CI+OoScZcZpg=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr36966376wia.3.1329910184671; Wed,
	22 Feb 2012 03:29:44 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 03:29:44 -0800 (PST)
In-Reply-To: <1329906664.2880.4.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<1329906664.2880.4.camel@zakaz.uk.xensource.com>
Date: Wed, 22 Feb 2012 12:29:44 +0100
X-Google-Sender-Auth: jMQbZ9O8oHsm0apjeWZDvsEK0R0
Message-ID: <CAPLaKK5ZzW0ZEE6cjv8OFy+oZv7nrybkWTdaGwgovOUFPhmYNA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMi0yMiBhdCAwOTo1NCArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+PiBPbiBX
ZWQsIDIwMTItMDItMjIgYXQgMDk6MjAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
ID4gMjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+ID4g
ZmxpZ2h0IDEyMDA3IHhlbi11bnN0YWJsZSByZWFsIFtyZWFsXQo+PiA+ID4gaHR0cDovL3d3dy5j
aGlhcmsuZ3JlZW5lbmQub3JnLnVrL354ZW5zcmN0cy9sb2dzLzEyMDA3Lwo+PiA+ID4KPj4gPiA+
IFJlZ3Jlc3Npb25zIDotKAo+PiA+ID4KPj4gPiA+IFRlc3RzIHdoaWNoIGRpZCBub3Qgc3VjY2Vl
ZCBhbmQgYXJlIGJsb2NraW5nLAo+PiA+ID4gaW5jbHVkaW5nIHRlc3RzIHdoaWNoIGNvdWxkIG5v
dCBiZSBydW46Cj4+ID4gPiDCoGJ1aWxkLWkzODYtb2xka2VybiDCoCDCoCDCoCDCoCDCoCDCoDQg
eGVuLWJ1aWxkIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZhaWwgUkVHUi4gdnMuIDEyMDAzCj4+
ID4gPiDCoGJ1aWxkLWkzODYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA0IHhlbi1idWls
ZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+PiA+ID4gwqBi
dWlsZC1hbWQ2NCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA0IHhlbi1idWlsZCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+PiA+ID4gwqBidWlsZC1hbWQ2
NC1vbGRrZXJuIMKgIMKgIMKgIMKgIMKgIDQgeGVuLWJ1aWxkIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGZhaWwgUkVHUi4gdnMuIDEyMDAzCj4+ID4KPj4gPgo+PiA+IGJyY3RsIGlzIG5vdCBpbnN0
YWxsZWQsIG9yIHRoZSB1c2VyIHRoYXQgaXMgdHJ5aW5nIHRvIGJ1aWxkIFhlbgo+PiA+IGRvZXNu
J3QgaGF2ZSBwZXJtaXNzaW9ucyB0byBydW4gaXQuIEkndmUgZm91bmQgdGhpcyB0ZXN0IHF1aXRl
Cj4+ID4gdXNlbGVzcywgYmVjYXVzZSB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgWGVuIGFz
IGEgcmVndWxhciB1c2VyLAo+PiA+IHRoYXQgZG9lc24ndCBoYXZlIGFjY2VzcyB0byBicmN0bCwg
ZG8geW91IHdhbnQgbWUgdG8gc2VuZCBhIHBhdGNoIHRoYXQKPj4gPiByZW1vdmVzIHRoaXMgY2hl
Y2s/Cj4+Cj4+IEkgYnVpbGQgWGVuIG9uIGEgbWFjaGluZSB3aGljaCBkb2Vzbid0IGFjdHVhbGx5
IHJ1biBYZW4gYW5kIHRoZXJlZm9yZQo+PiBkb2Vzbid0IGhhdmUgYnJjdGwgaW5zdGFsbGVkLCBJ
IGRvbid0IHRoaW5rIHRoaXMgaXMgdW5yZWFzb25hYmxlIHNpbmNlCj4+IGJyY3RsIGlzIGEgcnVu
dGltZSBub3QgY29tcGlsZS10aW1lIGRlcGVuZGVuY3kuCj4KPiBJIGFsc28gaGFkIHRvIHNwZWNp
ZnkgVURFVkFETSBvbiB0aGUgY29uZmlndXJlIGxpbmUgKEkgc3VzcGVjdCBiZWNhdXNlCj4gaXQg
aXMgbm90IGluICRQQVRIIGZvciByZWd1bGFyIHVzZXJzKS4gVGhlIGZpcnN0IHRpbWUgSSBkaWQg
c28gSSBnYXZlCj4gdGhlIHdyb25nIHBhdGg6Cj4gwqAgwqAgwqAgwqAkIFVERVZBRE09L3Vzci9z
YmluL3VkZXZhZG0gLi9jb25maWd1cmUKPiDCoCDCoCDCoCDCoFsuLi5dCj4gwqAgwqAgwqAgwqBj
aGVja2luZyBmb3IgdWRldmFkbS4uLiAvdXNyL3NiaW4vdWRldmFkbQo+IMKgIMKgIMKgIMKgLi9j
b25maWd1cmU6IGxpbmUgNjQ4NDogL3Vzci9zYmluL3VkZXZhZG06IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkKPiDCoCDCoCDCoCDCoC4vY29uZmlndXJlOiBsaW5lIDY0ODY6IHRlc3Q6IC1sdDog
dW5hcnkgb3BlcmF0b3IgZXhwZWN0ZWQKPgo+IElmIHdlIHRoaW5rIHRoaXMgY2hlY2sgc2hvdWxk
IGJlIGtlcHQgdGhlbiBpdCBuZWVkcyB0byBsZWFybiB0byBjaGVjawo+IGZvciB0aGluZ3MgaW4g
cGF0aHMgb3RoZXIgdGhhbiAkUEFUSCBhbmQgYWxzbyBoYXZlIHRoZSBlcnJvciBoYW5kbGluZwo+
IGZpeGVkLgoKSXQncyB0aGUgc2FtZSBhcyB0aGUgYnJjdGwgY2hlY2sgSSB0aGluaywgYW5kIEkg
d2lsbCBhbHNvIHNlbmQgYSBwYXRjaAp0byByZW1vdmUgdGhpcyB3aGlsZSBJIHdvcmsgb24gYSB3
YXkgdG8gY3JlYXRlIGEgc2ltcGxlIGluc3RhbGwgdGVzdAphbHNvLgoKPiBXaXRoIHRoaXMgYW5k
IHJlbW92aW5nIHRoZSBicmN0bCBjaGVjayBJIHdhcyBhYmxlIHRvIHJ1biBjb25maWd1cmUKPiBz
dWNjZXNzZnVsbHkuCj4KPiBJYW4uCj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0AOJ-0003pT-Sm; Wed, 22 Feb 2012 11:29:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0AOI-0003pL-CQ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:29:46 +0000
Received: from [85.158.139.83:61458] by server-12.bemta-5.messagelabs.com id
	AD/A4-24595-9A1D44F4; Wed, 22 Feb 2012 11:29:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329910184!4859618!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16724 invoked from network); 22 Feb 2012 11:29:44 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:29:44 -0000
Received: by wibhm2 with SMTP id hm2so15820886wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 03:29:44 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr44588146wia.3.1329910184795 (num_hops
	= 1); Wed, 22 Feb 2012 03:29:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=X9nr2oQxGwuqldCxDyLW+uhPC8ydZ7l+7S8GW2fiP/I=;
	b=mUmvfsFGDs29GlByK7QEVoRqz+yr1SGmoblwmw1vzhEk6kdl+PTt8VmjInT+lAOR6t
	20S/y698aSXhEq256mUgz7X0bDr/r4y8c7oIaxiwvNSuKdeQa2FTGEG5LsWtvYTouVOE
	PtTu9XMFRd3IJlKTaSmHZjHk4CI+OoScZcZpg=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr36966376wia.3.1329910184671; Wed,
	22 Feb 2012 03:29:44 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 03:29:44 -0800 (PST)
In-Reply-To: <1329906664.2880.4.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<1329906664.2880.4.camel@zakaz.uk.xensource.com>
Date: Wed, 22 Feb 2012 12:29:44 +0100
X-Google-Sender-Auth: jMQbZ9O8oHsm0apjeWZDvsEK0R0
Message-ID: <CAPLaKK5ZzW0ZEE6cjv8OFy+oZv7nrybkWTdaGwgovOUFPhmYNA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMi0yMiBhdCAwOTo1NCArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+PiBPbiBX
ZWQsIDIwMTItMDItMjIgYXQgMDk6MjAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4+
ID4gMjAxMi8yLzIyIHhlbi5vcmcgPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+ID4g
ZmxpZ2h0IDEyMDA3IHhlbi11bnN0YWJsZSByZWFsIFtyZWFsXQo+PiA+ID4gaHR0cDovL3d3dy5j
aGlhcmsuZ3JlZW5lbmQub3JnLnVrL354ZW5zcmN0cy9sb2dzLzEyMDA3Lwo+PiA+ID4KPj4gPiA+
IFJlZ3Jlc3Npb25zIDotKAo+PiA+ID4KPj4gPiA+IFRlc3RzIHdoaWNoIGRpZCBub3Qgc3VjY2Vl
ZCBhbmQgYXJlIGJsb2NraW5nLAo+PiA+ID4gaW5jbHVkaW5nIHRlc3RzIHdoaWNoIGNvdWxkIG5v
dCBiZSBydW46Cj4+ID4gPiDCoGJ1aWxkLWkzODYtb2xka2VybiDCoCDCoCDCoCDCoCDCoCDCoDQg
eGVuLWJ1aWxkIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZhaWwgUkVHUi4gdnMuIDEyMDAzCj4+
ID4gPiDCoGJ1aWxkLWkzODYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA0IHhlbi1idWls
ZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+PiA+ID4gwqBi
dWlsZC1hbWQ2NCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA0IHhlbi1idWlsZCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBmYWlsIFJFR1IuIHZzLiAxMjAwMwo+PiA+ID4gwqBidWlsZC1hbWQ2
NC1vbGRrZXJuIMKgIMKgIMKgIMKgIMKgIDQgeGVuLWJ1aWxkIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGZhaWwgUkVHUi4gdnMuIDEyMDAzCj4+ID4KPj4gPgo+PiA+IGJyY3RsIGlzIG5vdCBpbnN0
YWxsZWQsIG9yIHRoZSB1c2VyIHRoYXQgaXMgdHJ5aW5nIHRvIGJ1aWxkIFhlbgo+PiA+IGRvZXNu
J3QgaGF2ZSBwZXJtaXNzaW9ucyB0byBydW4gaXQuIEkndmUgZm91bmQgdGhpcyB0ZXN0IHF1aXRl
Cj4+ID4gdXNlbGVzcywgYmVjYXVzZSB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgWGVuIGFz
IGEgcmVndWxhciB1c2VyLAo+PiA+IHRoYXQgZG9lc24ndCBoYXZlIGFjY2VzcyB0byBicmN0bCwg
ZG8geW91IHdhbnQgbWUgdG8gc2VuZCBhIHBhdGNoIHRoYXQKPj4gPiByZW1vdmVzIHRoaXMgY2hl
Y2s/Cj4+Cj4+IEkgYnVpbGQgWGVuIG9uIGEgbWFjaGluZSB3aGljaCBkb2Vzbid0IGFjdHVhbGx5
IHJ1biBYZW4gYW5kIHRoZXJlZm9yZQo+PiBkb2Vzbid0IGhhdmUgYnJjdGwgaW5zdGFsbGVkLCBJ
IGRvbid0IHRoaW5rIHRoaXMgaXMgdW5yZWFzb25hYmxlIHNpbmNlCj4+IGJyY3RsIGlzIGEgcnVu
dGltZSBub3QgY29tcGlsZS10aW1lIGRlcGVuZGVuY3kuCj4KPiBJIGFsc28gaGFkIHRvIHNwZWNp
ZnkgVURFVkFETSBvbiB0aGUgY29uZmlndXJlIGxpbmUgKEkgc3VzcGVjdCBiZWNhdXNlCj4gaXQg
aXMgbm90IGluICRQQVRIIGZvciByZWd1bGFyIHVzZXJzKS4gVGhlIGZpcnN0IHRpbWUgSSBkaWQg
c28gSSBnYXZlCj4gdGhlIHdyb25nIHBhdGg6Cj4gwqAgwqAgwqAgwqAkIFVERVZBRE09L3Vzci9z
YmluL3VkZXZhZG0gLi9jb25maWd1cmUKPiDCoCDCoCDCoCDCoFsuLi5dCj4gwqAgwqAgwqAgwqBj
aGVja2luZyBmb3IgdWRldmFkbS4uLiAvdXNyL3NiaW4vdWRldmFkbQo+IMKgIMKgIMKgIMKgLi9j
b25maWd1cmU6IGxpbmUgNjQ4NDogL3Vzci9zYmluL3VkZXZhZG06IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkKPiDCoCDCoCDCoCDCoC4vY29uZmlndXJlOiBsaW5lIDY0ODY6IHRlc3Q6IC1sdDog
dW5hcnkgb3BlcmF0b3IgZXhwZWN0ZWQKPgo+IElmIHdlIHRoaW5rIHRoaXMgY2hlY2sgc2hvdWxk
IGJlIGtlcHQgdGhlbiBpdCBuZWVkcyB0byBsZWFybiB0byBjaGVjawo+IGZvciB0aGluZ3MgaW4g
cGF0aHMgb3RoZXIgdGhhbiAkUEFUSCBhbmQgYWxzbyBoYXZlIHRoZSBlcnJvciBoYW5kbGluZwo+
IGZpeGVkLgoKSXQncyB0aGUgc2FtZSBhcyB0aGUgYnJjdGwgY2hlY2sgSSB0aGluaywgYW5kIEkg
d2lsbCBhbHNvIHNlbmQgYSBwYXRjaAp0byByZW1vdmUgdGhpcyB3aGlsZSBJIHdvcmsgb24gYSB3
YXkgdG8gY3JlYXRlIGEgc2ltcGxlIGluc3RhbGwgdGVzdAphbHNvLgoKPiBXaXRoIHRoaXMgYW5k
IHJlbW92aW5nIHRoZSBicmN0bCBjaGVjayBJIHdhcyBhYmxlIHRvIHJ1biBjb25maWd1cmUKPiBz
dWNjZXNzZnVsbHkuCj4KPiBJYW4uCj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:44:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ac9-0004IV-Hw; Wed, 22 Feb 2012 11:44:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0Ac7-0004IQ-Pe
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 11:44:04 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329911035!15303671!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20126 invoked from network); 22 Feb 2012 11:43:56 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:43:56 -0000
Received: by wibhi20 with SMTP id hi20so4312006wib.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 03:43:55 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.78.233 as permitted sender) client-ip=10.180.78.233; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.78.233 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.78.233])
	by 10.180.78.233 with SMTP id e9mr35481010wix.0.1329911035359 (num_hops
	= 1); Wed, 22 Feb 2012 03:43:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=fvyd2xyHvvGtXni/o+MTEqSt7FRfnlK8Ozw5SUhjLhA=;
	b=nPcoqzjA2OvCaYPlG6ymxyv+IR7IU5N3N1NfmgjiWPv84NQ1U9xN/ghWEdevqoZ1rb
	tXX+D3R3312Q1Fgre7P6BGsNE3WW8nESnNk7qryCRS9YS1PykQ8H9eTGswIBGZf63cOh
	uA3M9IKUp0U+IdGwnwvH1claDi2nKMm3GNNjQ=
Received: by 10.180.78.233 with SMTP id e9mr29488593wix.0.1329911035225;
	Wed, 22 Feb 2012 03:43:55 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id h19sm28642796wiw.9.2012.02.22.03.43.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 03:43:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 31a50458bab3ffe84710d0e2e952598a642965c7
Message-Id: <31a50458bab3ffe84710.1329808780@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 08:19:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] autoconf: remove udev checks from 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329808760 -3600
# Node ID 31a50458bab3ffe84710d0e2e952598a642965c7
# Parent  0ab0491f2819fc8440da323d1bb0fa5534450b35
autoconf: remove udev checks from build

There's no need to have udev when building Xen since it's only used at
run time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0ab0491f2819 -r 31a50458bab3 tools/configure.ac
--- a/tools/configure.ac	Tue Feb 21 06:16:24 2012 +0100
+++ b/tools/configure.ac	Tue Feb 21 08:19:20 2012 +0100
@@ -29,7 +29,6 @@ m4_include([m4/path_or_fail.m4])
 m4_include([m4/python_xml.m4])
 m4_include([m4/python_version.m4])
 m4_include([m4/python_devel.m4])
-m4_include([m4/udev.m4])
 m4_include([m4/ocaml.m4])
 m4_include([m4/default_lib.m4])
 m4_include([m4/set_cflags_ldflags.m4])
@@ -107,7 +106,6 @@ AS_IF([test "x$pythontools" = "xy"], [
     AX_CHECK_PYTHON_DEVEL()
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
-AX_CHECK_UDEV([59])
 AX_CHECK_UUID
 PKG_CHECK_MODULES(glib, glib-2.0)
 
diff -r 0ab0491f2819 -r 31a50458bab3 tools/m4/udev.m4
--- a/tools/m4/udev.m4	Tue Feb 21 06:16:24 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,32 +0,0 @@
-AC_DEFUN([AX_CHECK_UDEV],
-[if test "x$host_os" == "xlinux-gnu"
-then
-    AC_PATH_PROG([UDEVADM], [udevadm], [no])
-    if test x"${UDEVADM}" == x"no" 
-    then
-        AC_PATH_PROG([UDEVINFO], [udevinfo], [no])
-        if test x"${UDEVINFO}" == x"no"
-        then
-            AC_MSG_ERROR(
-                [Unable to find udevadm or udevinfo, please install udev])
-        fi
-        udevver=`${UDEVINFO} -V | awk '{print $NF}'`
-    else
-        udevver=`${UDEVADM} info -V | awk '{print $NF}'`
-    fi
-    if test ${udevver} -lt 59
-    then
-        AC_PATH_PROG([HOTPLUG], [hotplug], [no])
-        if test x"${HOTPLUG}" == x"no"
-        then
-            AC_MSG_ERROR([udev is too old, upgrade to version 59 or later])
-        fi
-    fi
-else
-    AC_PATH_PROG([VNCONFIG], [vnconfig], [no])
-    if test x"${VNCONFIG}" == x"no"
-    then
-        AC_MSG_ERROR([Not a Linux system and unable to find vnd])
-    fi
-fi
-])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:44:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:44:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ac9-0004IV-Hw; Wed, 22 Feb 2012 11:44:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0Ac7-0004IQ-Pe
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 11:44:04 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329911035!15303671!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20126 invoked from network); 22 Feb 2012 11:43:56 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 11:43:56 -0000
Received: by wibhi20 with SMTP id hi20so4312006wib.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 03:43:55 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.78.233 as permitted sender) client-ip=10.180.78.233; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.78.233 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.78.233])
	by 10.180.78.233 with SMTP id e9mr35481010wix.0.1329911035359 (num_hops
	= 1); Wed, 22 Feb 2012 03:43:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=fvyd2xyHvvGtXni/o+MTEqSt7FRfnlK8Ozw5SUhjLhA=;
	b=nPcoqzjA2OvCaYPlG6ymxyv+IR7IU5N3N1NfmgjiWPv84NQ1U9xN/ghWEdevqoZ1rb
	tXX+D3R3312Q1Fgre7P6BGsNE3WW8nESnNk7qryCRS9YS1PykQ8H9eTGswIBGZf63cOh
	uA3M9IKUp0U+IdGwnwvH1claDi2nKMm3GNNjQ=
Received: by 10.180.78.233 with SMTP id e9mr29488593wix.0.1329911035225;
	Wed, 22 Feb 2012 03:43:55 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id h19sm28642796wiw.9.2012.02.22.03.43.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 03:43:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 31a50458bab3ffe84710d0e2e952598a642965c7
Message-Id: <31a50458bab3ffe84710.1329808780@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 08:19:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] autoconf: remove udev checks from 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329808760 -3600
# Node ID 31a50458bab3ffe84710d0e2e952598a642965c7
# Parent  0ab0491f2819fc8440da323d1bb0fa5534450b35
autoconf: remove udev checks from build

There's no need to have udev when building Xen since it's only used at
run time.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0ab0491f2819 -r 31a50458bab3 tools/configure.ac
--- a/tools/configure.ac	Tue Feb 21 06:16:24 2012 +0100
+++ b/tools/configure.ac	Tue Feb 21 08:19:20 2012 +0100
@@ -29,7 +29,6 @@ m4_include([m4/path_or_fail.m4])
 m4_include([m4/python_xml.m4])
 m4_include([m4/python_version.m4])
 m4_include([m4/python_devel.m4])
-m4_include([m4/udev.m4])
 m4_include([m4/ocaml.m4])
 m4_include([m4/default_lib.m4])
 m4_include([m4/set_cflags_ldflags.m4])
@@ -107,7 +106,6 @@ AS_IF([test "x$pythontools" = "xy"], [
     AX_CHECK_PYTHON_DEVEL()
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
-AX_CHECK_UDEV([59])
 AX_CHECK_UUID
 PKG_CHECK_MODULES(glib, glib-2.0)
 
diff -r 0ab0491f2819 -r 31a50458bab3 tools/m4/udev.m4
--- a/tools/m4/udev.m4	Tue Feb 21 06:16:24 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,32 +0,0 @@
-AC_DEFUN([AX_CHECK_UDEV],
-[if test "x$host_os" == "xlinux-gnu"
-then
-    AC_PATH_PROG([UDEVADM], [udevadm], [no])
-    if test x"${UDEVADM}" == x"no" 
-    then
-        AC_PATH_PROG([UDEVINFO], [udevinfo], [no])
-        if test x"${UDEVINFO}" == x"no"
-        then
-            AC_MSG_ERROR(
-                [Unable to find udevadm or udevinfo, please install udev])
-        fi
-        udevver=`${UDEVINFO} -V | awk '{print $NF}'`
-    else
-        udevver=`${UDEVADM} info -V | awk '{print $NF}'`
-    fi
-    if test ${udevver} -lt 59
-    then
-        AC_PATH_PROG([HOTPLUG], [hotplug], [no])
-        if test x"${HOTPLUG}" == x"no"
-        then
-            AC_MSG_ERROR([udev is too old, upgrade to version 59 or later])
-        fi
-    fi
-else
-    AC_PATH_PROG([VNCONFIG], [vnconfig], [no])
-    if test x"${VNCONFIG}" == x"no"
-    then
-        AC_MSG_ERROR([Not a Linux system and unable to find vnd])
-    fi
-fi
-])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0Akl-0004eH-IT; Wed, 22 Feb 2012 11:52: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 1S0Akj-0004eC-SW
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:52:58 +0000
Received: from [85.158.139.83:10462] by server-2.bemta-5.messagelabs.com id
	52/66-20263-917D44F4; Wed, 22 Feb 2012 11:52:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329911576!15586386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18180 invoked from network); 22 Feb 2012 11:52:56 -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;
	22 Feb 2012 11:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:52:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:52:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0Akg-00039Z-97; Wed, 22 Feb 2012 11:52:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0Akg-0000yb-7C;
	Wed, 22 Feb 2012 11:52:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55062.209546.961330@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:52:54 +0000
To: Bamvor Jian Zhang <bjzhang@suse.com>
In-Reply-To: <4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.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-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> Ian Jackson wrote: 
> > Users of libxl should not be using libxc directly and therefore should 
> > not be including xenctrl.h. 
...
> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
> it seems that add __XEN_TOOLS_ to libvirt code is not good. 

Can you tell us the error message you get ?  I think the problem is
probably that libvirt is trying to use libxc directly.

Now there is an existing libxc/libxenstore-based libvirt driver for
Xen but that should be in a separate file.  The libxl-based driver
should not use libxc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0Akl-0004eH-IT; Wed, 22 Feb 2012 11:52: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 1S0Akj-0004eC-SW
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:52:58 +0000
Received: from [85.158.139.83:10462] by server-2.bemta-5.messagelabs.com id
	52/66-20263-917D44F4; Wed, 22 Feb 2012 11:52:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329911576!15586386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18180 invoked from network); 22 Feb 2012 11:52:56 -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;
	22 Feb 2012 11:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:52:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:52:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0Akg-00039Z-97; Wed, 22 Feb 2012 11:52:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0Akg-0000yb-7C;
	Wed, 22 Feb 2012 11:52:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55062.209546.961330@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:52:54 +0000
To: Bamvor Jian Zhang <bjzhang@suse.com>
In-Reply-To: <4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.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-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> Ian Jackson wrote: 
> > Users of libxl should not be using libxc directly and therefore should 
> > not be including xenctrl.h. 
...
> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
> it seems that add __XEN_TOOLS_ to libvirt code is not good. 

Can you tell us the error message you get ?  I think the problem is
probably that libvirt is trying to use libxc directly.

Now there is an existing libxc/libxenstore-based libvirt driver for
Xen but that should be in a separate file.  The libxl-based driver
should not use libxc.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:54:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0Ale-0004hH-0x; Wed, 22 Feb 2012 11:53:54 +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 1S0Alc-0004gz-Ci
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:53:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329911597!57761142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16953 invoked from network); 22 Feb 2012 11:53:17 -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 Feb 2012 11:53:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:53:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:53:47 +0000
Message-ID: <1329911626.2880.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 11:53:46 +0000
In-Reply-To: <1329841075.3990.119.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 16:17 +0000, Ian Campbell wrote:
> > it needs to be what you would need to
> > edit to change the result of the Xen build.  So either it must be
> > .._TAG
> 
> I'll choose this option. I'll also edit the repo description to make it
> clear that all branches are rebasing.
> 
> >  or it must be some fast-forwarding branch constructed from the
> > series of _TAG values.  (Ie, a branch whose commits correspond 1:1
> > with _TAG values, each commit on the master branch having the previous
> > master commit as its left parent and the _TAG, which determines the
> > contents, as the right parent.)
> 
> I think I'd inevitably end up cocking this scheme up, especially given
> the expected frequency of seabios updates (e.g. v. low).

... actually I don't need to pick between the two until this actually
happens. When it does happen I'll play with the second option and
determine if I am capable of not making a mess of it etc.

For now I have cherry-picked the upstream fix onto a new branch
"1.6.3-stable-xen" and pushed that branch to our repo. I have also
updated the "xen-unstable" branch (the default branch) with the same.

IanJ -- when you are ready to push the xen-unstable.hg side please
include an update of SEABIOS_UPSTREAM_TAG to
002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
is currently).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:54:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0Ale-0004hH-0x; Wed, 22 Feb 2012 11:53:54 +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 1S0Alc-0004gz-Ci
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:53:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329911597!57761142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16953 invoked from network); 22 Feb 2012 11:53:17 -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 Feb 2012 11:53:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:53:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:53:47 +0000
Message-ID: <1329911626.2880.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 11:53:46 +0000
In-Reply-To: <1329841075.3990.119.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 16:17 +0000, Ian Campbell wrote:
> > it needs to be what you would need to
> > edit to change the result of the Xen build.  So either it must be
> > .._TAG
> 
> I'll choose this option. I'll also edit the repo description to make it
> clear that all branches are rebasing.
> 
> >  or it must be some fast-forwarding branch constructed from the
> > series of _TAG values.  (Ie, a branch whose commits correspond 1:1
> > with _TAG values, each commit on the master branch having the previous
> > master commit as its left parent and the _TAG, which determines the
> > contents, as the right parent.)
> 
> I think I'd inevitably end up cocking this scheme up, especially given
> the expected frequency of seabios updates (e.g. v. low).

... actually I don't need to pick between the two until this actually
happens. When it does happen I'll play with the second option and
determine if I am capable of not making a mess of it etc.

For now I have cherry-picked the upstream fix onto a new branch
"1.6.3-stable-xen" and pushed that branch to our repo. I have also
updated the "xen-unstable" branch (the default branch) with the same.

IanJ -- when you are ready to push the xen-unstable.hg side please
include an update of SEABIOS_UPSTREAM_TAG to
002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
is currently).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:54:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0AmK-0004lZ-FM; Wed, 22 Feb 2012 11:54:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0AmI-0004ki-5I
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 11:54:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329911667!14260166!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9709 invoked from network); 22 Feb 2012 11:54:27 -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;
	22 Feb 2012 11:54:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:54:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:54:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AmB-0003AS-3z; Wed, 22 Feb 2012 11:54:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AmB-0000zA-20;
	Wed, 22 Feb 2012 11:54:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55155.47837.914454@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:54:27 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <0ab0491f2819fc8440da.1329801792@build.localdomain>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
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] autoconf: remove brctl 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

Roger Pau Monne writes ("[PATCH] autoconf: remove brctl check"):
> autoconf: remove brctl check
> 
> Remove brctl check since it's usually only available to users with
> high privileges, but Xen should be buildable by regular users.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:54:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:54:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0AmK-0004lZ-FM; Wed, 22 Feb 2012 11:54:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0AmI-0004ki-5I
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 11:54:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329911667!14260166!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9709 invoked from network); 22 Feb 2012 11:54:27 -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;
	22 Feb 2012 11:54:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:54:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:54:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AmB-0003AS-3z; Wed, 22 Feb 2012 11:54:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AmB-0000zA-20;
	Wed, 22 Feb 2012 11:54:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55155.47837.914454@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:54:27 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <0ab0491f2819fc8440da.1329801792@build.localdomain>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
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] autoconf: remove brctl 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

Roger Pau Monne writes ("[PATCH] autoconf: remove brctl check"):
> autoconf: remove brctl check
> 
> Remove brctl check since it's usually only available to users with
> high privileges, but Xen should be buildable by regular users.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0AoY-0004zv-6l; Wed, 22 Feb 2012 11:56:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0AoW-0004zG-H6
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 11:56:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329911806!15853124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27598 invoked from network); 22 Feb 2012 11:56:46 -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;
	22 Feb 2012 11:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:56:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:56:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AoP-0003BG-Qy; Wed, 22 Feb 2012 11:56:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AoP-0000zm-Oh;
	Wed, 22 Feb 2012 11:56:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55293.739472.670166@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:56:45 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <31a50458bab3ffe84710.1329808780@build.localdomain>
References: <31a50458bab3ffe84710.1329808780@build.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove udev checks from 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

Roger Pau Monne writes ("[PATCH] autoconf: remove udev checks from build"):
> autoconf: remove udev checks from build
> 
> There's no need to have udev when building Xen since it's only used at
> run time.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0AoY-0004zv-6l; Wed, 22 Feb 2012 11:56:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0AoW-0004zG-H6
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 11:56:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329911806!15853124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27598 invoked from network); 22 Feb 2012 11:56:46 -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;
	22 Feb 2012 11:56:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869387"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:56:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:56:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AoP-0003BG-Qy; Wed, 22 Feb 2012 11:56:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AoP-0000zm-Oh;
	Wed, 22 Feb 2012 11:56:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55293.739472.670166@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:56:45 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <31a50458bab3ffe84710.1329808780@build.localdomain>
References: <31a50458bab3ffe84710.1329808780@build.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove udev checks from 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

Roger Pau Monne writes ("[PATCH] autoconf: remove udev checks from build"):
> autoconf: remove udev checks from build
> 
> There's no need to have udev when building Xen since it's only used at
> run time.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 11:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0AqJ-0005Bi-O5; Wed, 22 Feb 2012 11:58:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0AqH-0005BL-SO
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:58:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329911915!12514861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8794 invoked from network); 22 Feb 2012 11:58:36 -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;
	22 Feb 2012 11:58:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:58:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:58:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AqB-0003Bw-BN; Wed, 22 Feb 2012 11:58:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AqB-000107-AW;
	Wed, 22 Feb 2012 11:58:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55403.163069.11201@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:58:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329911626.2880.42.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> IanJ -- when you are ready to push the xen-unstable.hg side please
> include an update of SEABIOS_UPSTREAM_TAG to
> 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> is currently).

I think each side of this change is harmless independently, so you can
go ahead and do that whenever you think it right.  But perhaps we
should wait with this and the $(PYTHON)-passing patch until we get the
tree building 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 Feb 22 11:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 11: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 1S0AqJ-0005Bi-O5; Wed, 22 Feb 2012 11:58:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0AqH-0005BL-SO
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 11:58:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329911915!12514861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8794 invoked from network); 22 Feb 2012 11:58:36 -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;
	22 Feb 2012 11:58:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:58:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 11:58:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AqB-0003Bw-BN; Wed, 22 Feb 2012 11:58:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AqB-000107-AW;
	Wed, 22 Feb 2012 11:58:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55403.163069.11201@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 11:58:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329911626.2880.42.camel@zakaz.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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/seabios: override $(PYTHON)"):
> IanJ -- when you are ready to push the xen-unstable.hg side please
> include an update of SEABIOS_UPSTREAM_TAG to
> 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> is currently).

I think each side of this change is harmless independently, so you can
go ahead and do that whenever you think it right.  But perhaps we
should wait with this and the $(PYTHON)-passing patch until we get the
tree building 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 Feb 22 12:01:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Asp-0005Tg-8S; Wed, 22 Feb 2012 12:01: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 1S0Asn-0005TL-Mt
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:01:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329912051!53949807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16640 invoked from network); 22 Feb 2012 12:00:51 -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;
	22 Feb 2012 12:00:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:00:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 12:00:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AsR-0003D4-V7; Wed, 22 Feb 2012 12:00:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AsR-00010C-T6;
	Wed, 22 Feb 2012 12:00:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55543.888305.406653@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 12:00:55 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329906873.2880.6.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
	<1329906873.2880.6.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0813297164858802602=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0813297164858802602==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL"):
> This is why I am concerned that we have removed the install time as well
> as the development time checks...

This is a legitimate concern but these checks should definitely not be
in the configure script, so I've applied Roger's patches to remove
them.

> Perhaps we should move these new checks to a second configure script
> which can be run at install time and produces as its output just a pass
> or fail?

Roger Pau Monné writes ("Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL"):
> I've submitted a patch that should fix that. I'm afraid that removing
> the brctl/brconfig check will bring trouble, because this is used in
> hotplug scripts and errors on hotplug scripts are hard to spot right
> now for regular users.

This should definitely be fixed.

I think the right answer is to add some checks in xencommons.  Since
the purpose is to help the user diagnose problems, it's fine for them
to be warnings rather than causing xencommons not to work at all.

And given that we only want to check for brctl and udev, and those are
pretty simple, I don't think we need to use autoconf for that.

Ian.


--===============0813297164858802602==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0813297164858802602==--

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:01:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Asp-0005Tg-8S; Wed, 22 Feb 2012 12:01: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 1S0Asn-0005TL-Mt
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:01:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329912051!53949807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16640 invoked from network); 22 Feb 2012 12:00:51 -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;
	22 Feb 2012 12:00:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:00:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 12:00:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AsR-0003D4-V7; Wed, 22 Feb 2012 12:00:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AsR-00010C-T6;
	Wed, 22 Feb 2012 12:00:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55543.888305.406653@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 12:00:55 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329906873.2880.6.camel@zakaz.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
	<1329906873.2880.6.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0813297164858802602=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0813297164858802602==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL"):
> This is why I am concerned that we have removed the install time as well
> as the development time checks...

This is a legitimate concern but these checks should definitely not be
in the configure script, so I've applied Roger's patches to remove
them.

> Perhaps we should move these new checks to a second configure script
> which can be run at install time and produces as its output just a pass
> or fail?

Roger Pau Monné writes ("Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL"):
> I've submitted a patch that should fix that. I'm afraid that removing
> the brctl/brconfig check will bring trouble, because this is used in
> hotplug scripts and errors on hotplug scripts are hard to spot right
> now for regular users.

This should definitely be fixed.

I think the right answer is to add some checks in xencommons.  Since
the purpose is to help the user diagnose problems, it's fine for them
to be warnings rather than causing xencommons not to work at all.

And given that we only want to check for brctl and udev, and those are
pretty simple, I don't think we need to use autoconf for that.

Ian.


--===============0813297164858802602==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0813297164858802602==--

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Axd-0005nE-Pn; Wed, 22 Feb 2012 12:06:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0Axc-0005mW-G1
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:06:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329912324!61169480!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18271 invoked from network); 22 Feb 2012 12:05:24 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 12:05:24 -0000
Received: by wgbdr13 with SMTP id dr13so5873222wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 04:06:10 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr43306140wib.3.1329912370231 (num_hops
	= 1); Wed, 22 Feb 2012 04:06:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=mvssZO4puj0Y53FyDdVSbIKvohxJ9tCFWzqsRsSrvtM=;
	b=EXjzD19hKSBhB6bs2nYuNFK6F/YchMZloAKMsRySS9EtbF/z/NQxEGwjzshXNtmeCJ
	QLxZDd7G16wVdNseAabgdsndP1tKIZNBdB9vs6JUNJuJbm7a4CsM/31QB0gFV5iiw04x
	VMTcbvZ7UhhwH3qvtiOUUXm2cNKGYUpjLUGwk=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr35818194wib.3.1329912370135; Wed,
	22 Feb 2012 04:06:10 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 04:06:10 -0800 (PST)
In-Reply-To: <20292.55543.888305.406653@mariner.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
	<1329906873.2880.6.camel@zakaz.uk.xensource.com>
	<20292.55543.888305.406653@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 13:06:10 +0100
X-Google-Sender-Auth: aWniaaHdB8rQWwYwILgE7tNMtrM
Message-ID: <CAPLaKK4ANaH=Ua2Vx0ZZUB_zz_1+VFfUpGk-2w8r+JASvcmUUw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBJYW4g
Q2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFt4ZW4tdW5zdGFibGUgdGVzdF0gMTIw
MDc6IHJlZ3Jlc3Npb25zIC0gRkFJTCIpOgo+PiBUaGlzIGlzIHdoeSBJIGFtIGNvbmNlcm5lZCB0
aGF0IHdlIGhhdmUgcmVtb3ZlZCB0aGUgaW5zdGFsbCB0aW1lIGFzIHdlbGwKPj4gYXMgdGhlIGRl
dmVsb3BtZW50IHRpbWUgY2hlY2tzLi4uCj4KPiBUaGlzIGlzIGEgbGVnaXRpbWF0ZSBjb25jZXJu
IGJ1dCB0aGVzZSBjaGVja3Mgc2hvdWxkIGRlZmluaXRlbHkgbm90IGJlCj4gaW4gdGhlIGNvbmZp
Z3VyZSBzY3JpcHQsIHNvIEkndmUgYXBwbGllZCBSb2dlcidzIHBhdGNoZXMgdG8gcmVtb3ZlCj4g
dGhlbS4KPgo+PiBQZXJoYXBzIHdlIHNob3VsZCBtb3ZlIHRoZXNlIG5ldyBjaGVja3MgdG8gYSBz
ZWNvbmQgY29uZmlndXJlIHNjcmlwdAo+PiB3aGljaCBjYW4gYmUgcnVuIGF0IGluc3RhbGwgdGlt
ZSBhbmQgcHJvZHVjZXMgYXMgaXRzIG91dHB1dCBqdXN0IGEgcGFzcwo+PiBvciBmYWlsPwo+Cj4g
Um9nZXIgUGF1IE1vbm7DqSB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW3hlbi11bnN0YWJsZSB0
ZXN0XSAxMjAwNzogcmVncmVzc2lvbnMgLSBGQUlMIik6Cj4+IEkndmUgc3VibWl0dGVkIGEgcGF0
Y2ggdGhhdCBzaG91bGQgZml4IHRoYXQuIEknbSBhZnJhaWQgdGhhdCByZW1vdmluZwo+PiB0aGUg
YnJjdGwvYnJjb25maWcgY2hlY2sgd2lsbCBicmluZyB0cm91YmxlLCBiZWNhdXNlIHRoaXMgaXMg
dXNlZCBpbgo+PiBob3RwbHVnIHNjcmlwdHMgYW5kIGVycm9ycyBvbiBob3RwbHVnIHNjcmlwdHMg
YXJlIGhhcmQgdG8gc3BvdCByaWdodAo+PiBub3cgZm9yIHJlZ3VsYXIgdXNlcnMuCj4KPiBUaGlz
IHNob3VsZCBkZWZpbml0ZWx5IGJlIGZpeGVkLgo+Cj4gSSB0aGluayB0aGUgcmlnaHQgYW5zd2Vy
IGlzIHRvIGFkZCBzb21lIGNoZWNrcyBpbiB4ZW5jb21tb25zLiDCoFNpbmNlCj4gdGhlIHB1cnBv
c2UgaXMgdG8gaGVscCB0aGUgdXNlciBkaWFnbm9zZSBwcm9ibGVtcywgaXQncyBmaW5lIGZvciB0
aGVtCj4gdG8gYmUgd2FybmluZ3MgcmF0aGVyIHRoYW4gY2F1c2luZyB4ZW5jb21tb25zIG5vdCB0
byB3b3JrIGF0IGFsbC4KCkkgd2FzIGdvaW5nIHRvIGNyZWF0ZSBhIG5ldyBjb25maWd1cmUgc2Ny
aXB0IHRvIHBlcmZvcm0gdGhvc2UgY2hlY2tzLApidXQgbWF5YmUgaXQncyBvdmVya2lsbC4gSSB3
aWxsIGFkZCBzb21lIHNpbXBsZSB0ZXN0cyB0byB4ZW5jb21tb25zLgoKPiBBbmQgZ2l2ZW4gdGhh
dCB3ZSBvbmx5IHdhbnQgdG8gY2hlY2sgZm9yIGJyY3RsIGFuZCB1ZGV2LCBhbmQgdGhvc2UgYXJl
Cj4gcHJldHR5IHNpbXBsZSwgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHVzZSBhdXRvY29uZiBm
b3IgdGhhdC4KPgo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Axd-0005nE-Pn; Wed, 22 Feb 2012 12:06:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0Axc-0005mW-G1
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:06:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1329912324!61169480!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18271 invoked from network); 22 Feb 2012 12:05:24 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 12:05:24 -0000
Received: by wgbdr13 with SMTP id dr13so5873222wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 04:06:10 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr43306140wib.3.1329912370231 (num_hops
	= 1); Wed, 22 Feb 2012 04:06:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=mvssZO4puj0Y53FyDdVSbIKvohxJ9tCFWzqsRsSrvtM=;
	b=EXjzD19hKSBhB6bs2nYuNFK6F/YchMZloAKMsRySS9EtbF/z/NQxEGwjzshXNtmeCJ
	QLxZDd7G16wVdNseAabgdsndP1tKIZNBdB9vs6JUNJuJbm7a4CsM/31QB0gFV5iiw04x
	VMTcbvZ7UhhwH3qvtiOUUXm2cNKGYUpjLUGwk=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr35818194wib.3.1329912370135; Wed,
	22 Feb 2012 04:06:10 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 04:06:10 -0800 (PST)
In-Reply-To: <20292.55543.888305.406653@mariner.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<CAPLaKK7HrpvKEr4PP_za--kJf5XGb7Sg5VtcrLZCmDjzrR5+ZA@mail.gmail.com>
	<1329904496.2880.1.camel@zakaz.uk.xensource.com>
	<CAPLaKK6YWv7wf3VtK0ZxrTBBSrjnJ=0D06A9JmCupWz3UN1W3Q@mail.gmail.com>
	<1329906873.2880.6.camel@zakaz.uk.xensource.com>
	<20292.55543.888305.406653@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 13:06:10 +0100
X-Google-Sender-Auth: aWniaaHdB8rQWwYwILgE7tNMtrM
Message-ID: <CAPLaKK4ANaH=Ua2Vx0ZZUB_zz_1+VFfUpGk-2w8r+JASvcmUUw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBJYW4g
Q2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFt4ZW4tdW5zdGFibGUgdGVzdF0gMTIw
MDc6IHJlZ3Jlc3Npb25zIC0gRkFJTCIpOgo+PiBUaGlzIGlzIHdoeSBJIGFtIGNvbmNlcm5lZCB0
aGF0IHdlIGhhdmUgcmVtb3ZlZCB0aGUgaW5zdGFsbCB0aW1lIGFzIHdlbGwKPj4gYXMgdGhlIGRl
dmVsb3BtZW50IHRpbWUgY2hlY2tzLi4uCj4KPiBUaGlzIGlzIGEgbGVnaXRpbWF0ZSBjb25jZXJu
IGJ1dCB0aGVzZSBjaGVja3Mgc2hvdWxkIGRlZmluaXRlbHkgbm90IGJlCj4gaW4gdGhlIGNvbmZp
Z3VyZSBzY3JpcHQsIHNvIEkndmUgYXBwbGllZCBSb2dlcidzIHBhdGNoZXMgdG8gcmVtb3ZlCj4g
dGhlbS4KPgo+PiBQZXJoYXBzIHdlIHNob3VsZCBtb3ZlIHRoZXNlIG5ldyBjaGVja3MgdG8gYSBz
ZWNvbmQgY29uZmlndXJlIHNjcmlwdAo+PiB3aGljaCBjYW4gYmUgcnVuIGF0IGluc3RhbGwgdGlt
ZSBhbmQgcHJvZHVjZXMgYXMgaXRzIG91dHB1dCBqdXN0IGEgcGFzcwo+PiBvciBmYWlsPwo+Cj4g
Um9nZXIgUGF1IE1vbm7DqSB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW3hlbi11bnN0YWJsZSB0
ZXN0XSAxMjAwNzogcmVncmVzc2lvbnMgLSBGQUlMIik6Cj4+IEkndmUgc3VibWl0dGVkIGEgcGF0
Y2ggdGhhdCBzaG91bGQgZml4IHRoYXQuIEknbSBhZnJhaWQgdGhhdCByZW1vdmluZwo+PiB0aGUg
YnJjdGwvYnJjb25maWcgY2hlY2sgd2lsbCBicmluZyB0cm91YmxlLCBiZWNhdXNlIHRoaXMgaXMg
dXNlZCBpbgo+PiBob3RwbHVnIHNjcmlwdHMgYW5kIGVycm9ycyBvbiBob3RwbHVnIHNjcmlwdHMg
YXJlIGhhcmQgdG8gc3BvdCByaWdodAo+PiBub3cgZm9yIHJlZ3VsYXIgdXNlcnMuCj4KPiBUaGlz
IHNob3VsZCBkZWZpbml0ZWx5IGJlIGZpeGVkLgo+Cj4gSSB0aGluayB0aGUgcmlnaHQgYW5zd2Vy
IGlzIHRvIGFkZCBzb21lIGNoZWNrcyBpbiB4ZW5jb21tb25zLiDCoFNpbmNlCj4gdGhlIHB1cnBv
c2UgaXMgdG8gaGVscCB0aGUgdXNlciBkaWFnbm9zZSBwcm9ibGVtcywgaXQncyBmaW5lIGZvciB0
aGVtCj4gdG8gYmUgd2FybmluZ3MgcmF0aGVyIHRoYW4gY2F1c2luZyB4ZW5jb21tb25zIG5vdCB0
byB3b3JrIGF0IGFsbC4KCkkgd2FzIGdvaW5nIHRvIGNyZWF0ZSBhIG5ldyBjb25maWd1cmUgc2Ny
aXB0IHRvIHBlcmZvcm0gdGhvc2UgY2hlY2tzLApidXQgbWF5YmUgaXQncyBvdmVya2lsbC4gSSB3
aWxsIGFkZCBzb21lIHNpbXBsZSB0ZXN0cyB0byB4ZW5jb21tb25zLgoKPiBBbmQgZ2l2ZW4gdGhh
dCB3ZSBvbmx5IHdhbnQgdG8gY2hlY2sgZm9yIGJyY3RsIGFuZCB1ZGV2LCBhbmQgdGhvc2UgYXJl
Cj4gcHJldHR5IHNpbXBsZSwgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHVzZSBhdXRvY29uZiBm
b3IgdGhhdC4KPgo+IElhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:06:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Axk-0005nz-6j; Wed, 22 Feb 2012 12:06:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Axh-0005my-W8
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:06:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329912375!15925467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5185 invoked from network); 22 Feb 2012 12:06:15 -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;
	22 Feb 2012 12:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:05:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 12:05:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AxH-0003Et-9T; Wed, 22 Feb 2012 12:05:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AxH-00011C-8W;
	Wed, 22 Feb 2012 12:05:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55843.90369.226447@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 12:05:55 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329894417.25232.119.camel@dagon.hellion.org.uk>
References: <osstest-12003-mainreport@xen.org>
	<1329894417.25232.119.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12003: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12003: tolerable FAIL - PUSHED"):
> On Wed, 2012-02-22 at 06:14 +0000, xen.org wrote:
> >  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
> 
> From
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12003/test-amd64-amd64-xl-qemuu-winxpsp3/bush-cricket---var-log-xen-qemu-dm-win.guest.osstest.log:
> 
>         /usr/lib/xen/bin/qemu-system-i386: error while loading shared
>         libraries: libgthread-2.0.so.0: cannot open shared object file:
>         No such file or directory
>         
> It seems that we need:
> 
> $ dpkg -S libgthread-2.0.so.0
> libglib2.0-0: /usr/lib/libgthread-2.0.so.0.2400.2
> libglib2.0-0: /usr/lib/libgthread-2.0.so.0

Thanks for investigating.  I have submitted a change to install 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 Feb 22 12:06:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Axk-0005nz-6j; Wed, 22 Feb 2012 12:06:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Axh-0005my-W8
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:06:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329912375!15925467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5185 invoked from network); 22 Feb 2012 12:06:15 -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;
	22 Feb 2012 12:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208";a="10869953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:05:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 12:05:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0AxH-0003Et-9T; Wed, 22 Feb 2012 12:05:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0AxH-00011C-8W;
	Wed, 22 Feb 2012 12:05:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.55843.90369.226447@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 12:05:55 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329894417.25232.119.camel@dagon.hellion.org.uk>
References: <osstest-12003-mainreport@xen.org>
	<1329894417.25232.119.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 12003: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12003: tolerable FAIL - PUSHED"):
> On Wed, 2012-02-22 at 06:14 +0000, xen.org wrote:
> >  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
> 
> From
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12003/test-amd64-amd64-xl-qemuu-winxpsp3/bush-cricket---var-log-xen-qemu-dm-win.guest.osstest.log:
> 
>         /usr/lib/xen/bin/qemu-system-i386: error while loading shared
>         libraries: libgthread-2.0.so.0: cannot open shared object file:
>         No such file or directory
>         
> It seems that we need:
> 
> $ dpkg -S libgthread-2.0.so.0
> libglib2.0-0: /usr/lib/libgthread-2.0.so.0.2400.2
> libglib2.0-0: /usr/lib/libgthread-2.0.so.0

Thanks for investigating.  I have submitted a change to install 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 Feb 22 12:07:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ayl-0005xw-Lr; Wed, 22 Feb 2012 12:07:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Ayj-0005x1-W7
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:07:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329912437!15602423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9463 invoked from network); 22 Feb 2012 12:07:18 -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;
	22 Feb 2012 12:07:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10870120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:07:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 12:07:07 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0AyQ-0003FK-T6;
	Wed, 22 Feb 2012 12:07:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0AyQ-0001AM-Pd;
	Wed, 22 Feb 2012 12:07:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12015-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 12:07:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12015: trouble: preparing/queued
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12015 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12015/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-intel    <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 build-i386-oldkern            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-i386                    1 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 build-amd64-pvops             1 hosts-allocate           running [st=running!]
 test-amd64-i386-win             <none executed>              queued
 build-amd64                   2 host-install(2)          running [st=running!]
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 build-amd64-oldkern           1 hosts-allocate           running [st=running!]
 test-i386-i386-pair             <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued

version targeted for testing:
 xen                  8ee81ceda8c9
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  preparing
 build-i386                                                   preparing
 build-amd64-oldkern                                          preparing
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            preparing
 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:   24861:8ee81ceda8c9
tag:         tip
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:07:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ayl-0005xw-Lr; Wed, 22 Feb 2012 12:07:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Ayj-0005x1-W7
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:07:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1329912437!15602423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9463 invoked from network); 22 Feb 2012 12:07:18 -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;
	22 Feb 2012 12:07:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10870120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:07:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 12:07:07 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0AyQ-0003FK-T6;
	Wed, 22 Feb 2012 12:07:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0AyQ-0001AM-Pd;
	Wed, 22 Feb 2012 12:07:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12015-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 12:07:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12015: trouble: preparing/queued
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12015 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12015/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-intel    <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 build-i386-oldkern            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-i386                    1 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 build-amd64-pvops             1 hosts-allocate           running [st=running!]
 test-amd64-i386-win             <none executed>              queued
 build-amd64                   2 host-install(2)          running [st=running!]
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 build-amd64-oldkern           1 hosts-allocate           running [st=running!]
 test-i386-i386-pair             <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued

version targeted for testing:
 xen                  8ee81ceda8c9
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  preparing
 build-i386                                                   preparing
 build-amd64-oldkern                                          preparing
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            preparing
 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:   24861:8ee81ceda8c9
tag:         tip
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:09:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0B09-0006AU-6g; Wed, 22 Feb 2012 12:08:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0B07-0006A9-Rg
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 12:08:52 +0000
Received: from [85.158.139.83:4780] by server-5.bemta-5.messagelabs.com id
	78/43-13566-3DAD44F4; Wed, 22 Feb 2012 12:08:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329912530!16100037!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14193 invoked from network); 22 Feb 2012 12:08:50 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 12:08:50 -0000
Received: by werh12 with SMTP id h12so5901569wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 04:08:50 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.135.193 as permitted sender) client-ip=10.216.135.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.135.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.135.193])
	by 10.216.135.193 with SMTP id u43mr9020962wei.34.1329912530362
	(num_hops = 1); Wed, 22 Feb 2012 04:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4KgWgF3riKdosPmn/8+Ot+wYAIltAhkPp+U/dy5fado=;
	b=pcFFoDEkyI+Z2xOrjkeUw8K2nh4MLcatGApytIUungs7fs5mg0f89LiUPq6zCyP+LO
	oR51ogSJi2IygmrPWLXTf7Dz4zy5XCl/P+OR5H2KXCa71Irpi0Tvnbs4YEGDcarlTz1E
	M/QRy1dwdSnx6YWI595Jq2bj9p6YJDpWyTFFU=
MIME-Version: 1.0
Received: by 10.216.135.193 with SMTP id u43mr7469670wei.34.1329912530261;
	Wed, 22 Feb 2012 04:08:50 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 04:08:50 -0800 (PST)
In-Reply-To: <20292.55155.47837.914454@mariner.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 13:08:50 +0100
X-Google-Sender-Auth: qth7Dn4CxYHZe-U0uuZElq_nK3A
Message-ID: <CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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

This bit was missing, sorry:

autoconf: clean brctl options

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 31a50458bab3 tools/configure.ac
--- a/tools/configure.ac        Tue Feb 21 08:19:20 2012 +0100
+++ b/tools/configure.ac        Tue Feb 21 08:46:04 2012 +0100
@@ -62,7 +62,6 @@ AX_SET_FLAGS

 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
-AC_ARG_VAR([BRCTL], [Path to brctl tool])
 AC_ARG_VAR([IP], [Path to ip tool])
 AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:09:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0B09-0006AU-6g; Wed, 22 Feb 2012 12:08:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0B07-0006A9-Rg
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 12:08:52 +0000
Received: from [85.158.139.83:4780] by server-5.bemta-5.messagelabs.com id
	78/43-13566-3DAD44F4; Wed, 22 Feb 2012 12:08:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329912530!16100037!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14193 invoked from network); 22 Feb 2012 12:08:50 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 12:08:50 -0000
Received: by werh12 with SMTP id h12so5901569wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 04:08:50 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.135.193 as permitted sender) client-ip=10.216.135.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.135.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.135.193])
	by 10.216.135.193 with SMTP id u43mr9020962wei.34.1329912530362
	(num_hops = 1); Wed, 22 Feb 2012 04:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4KgWgF3riKdosPmn/8+Ot+wYAIltAhkPp+U/dy5fado=;
	b=pcFFoDEkyI+Z2xOrjkeUw8K2nh4MLcatGApytIUungs7fs5mg0f89LiUPq6zCyP+LO
	oR51ogSJi2IygmrPWLXTf7Dz4zy5XCl/P+OR5H2KXCa71Irpi0Tvnbs4YEGDcarlTz1E
	M/QRy1dwdSnx6YWI595Jq2bj9p6YJDpWyTFFU=
MIME-Version: 1.0
Received: by 10.216.135.193 with SMTP id u43mr7469670wei.34.1329912530261;
	Wed, 22 Feb 2012 04:08:50 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 04:08:50 -0800 (PST)
In-Reply-To: <20292.55155.47837.914454@mariner.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 13:08:50 +0100
X-Google-Sender-Auth: qth7Dn4CxYHZe-U0uuZElq_nK3A
Message-ID: <CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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

This bit was missing, sorry:

autoconf: clean brctl options

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 31a50458bab3 tools/configure.ac
--- a/tools/configure.ac        Tue Feb 21 08:19:20 2012 +0100
+++ b/tools/configure.ac        Tue Feb 21 08:46:04 2012 +0100
@@ -62,7 +62,6 @@ AX_SET_FLAGS

 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
-AC_ARG_VAR([BRCTL], [Path to brctl tool])
 AC_ARG_VAR([IP], [Path to ip tool])
 AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:10:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12: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 1S0B1i-0006OO-Mz; Wed, 22 Feb 2012 12:10:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0B1h-0006Nj-AX
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:10:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329912622!12739221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21208 invoked from network); 22 Feb 2012 12:10:22 -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;
	22 Feb 2012 12:10:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10870296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:10:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 12:10:21 +0000
Message-ID: <1329912620.2880.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 12:10:20 +0000
In-Reply-To: <20292.55062.209546.961330@mariner.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 11:52 +0000, Ian Jackson wrote:
> Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > Ian Jackson wrote: 
> > > Users of libxl should not be using libxc directly and therefore should 
> > > not be including xenctrl.h. 
> ...
> > but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
> > it seems that add __XEN_TOOLS_ to libvirt code is not good. 
> 
> Can you tell us the error message you get ?  I think the problem is
> probably that libvirt is trying to use libxc directly.

Is the problem here libxc or the Xen public headers?

I thought we'd decided the latter was OK in users of libxl. e.g. xl has
to use the SHUTDOWN_{poweroff,reboot,suspend} constants from
xen/include/public/sched.h (and indeed libxl.h includes this header).

libxl.h also includes Xen's sysctl.h -- seems to be for
XEN_SYSCTL_PHYSCAP_*. Really this case would be better exposing as a
series of bools which are initialised from the hypercall provided flags
mask by libxl (like we do for the various dominfo flags)

Personally I'd be happy to have libxl always define its own constants
and remove this need for libxl users to use the Xen headers.

If we are going to do that it should go onto 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 Wed Feb 22 12:10:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12: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 1S0B1i-0006OO-Mz; Wed, 22 Feb 2012 12:10:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0B1h-0006Nj-AX
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:10:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329912622!12739221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21208 invoked from network); 22 Feb 2012 12:10:22 -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;
	22 Feb 2012 12:10:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10870296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:10:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 12:10:21 +0000
Message-ID: <1329912620.2880.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 12:10:20 +0000
In-Reply-To: <20292.55062.209546.961330@mariner.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 11:52 +0000, Ian Jackson wrote:
> Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > Ian Jackson wrote: 
> > > Users of libxl should not be using libxc directly and therefore should 
> > > not be including xenctrl.h. 
> ...
> > but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
> > it seems that add __XEN_TOOLS_ to libvirt code is not good. 
> 
> Can you tell us the error message you get ?  I think the problem is
> probably that libvirt is trying to use libxc directly.

Is the problem here libxc or the Xen public headers?

I thought we'd decided the latter was OK in users of libxl. e.g. xl has
to use the SHUTDOWN_{poweroff,reboot,suspend} constants from
xen/include/public/sched.h (and indeed libxl.h includes this header).

libxl.h also includes Xen's sysctl.h -- seems to be for
XEN_SYSCTL_PHYSCAP_*. Really this case would be better exposing as a
series of bools which are initialised from the hypercall provided flags
mask by libxl (like we do for the various dominfo flags)

Personally I'd be happy to have libxl always define its own constants
and remove this need for libxl users to use the Xen headers.

If we are going to do that it should go onto 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 Wed Feb 22 12:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12: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 1S0B5S-0006n7-KH; Wed, 22 Feb 2012 12:14:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0B5R-0006mp-BF
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:14:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329912855!14222603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16261 invoked from network); 22 Feb 2012 12:14:15 -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;
	22 Feb 2012 12:14:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10870379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:14:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 12:14:15 +0000
Message-ID: <1329912853.2880.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 12:14:13 +0000
In-Reply-To: <20292.55403.163069.11201@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
	<20292.55403.163069.11201@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 11:58 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > IanJ -- when you are ready to push the xen-unstable.hg side please
> > include an update of SEABIOS_UPSTREAM_TAG to
> > 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> > is currently).
> 
> I think each side of this change is harmless independently, so you can
> go ahead and do that whenever you think it right.  But perhaps we
> should wait with this and the $(PYTHON)-passing patch until we get the
> tree building again.

Ack on waiting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12: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 1S0B5S-0006n7-KH; Wed, 22 Feb 2012 12:14:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0B5R-0006mp-BF
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:14:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329912855!14222603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16261 invoked from network); 22 Feb 2012 12:14:15 -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;
	22 Feb 2012 12:14:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10870379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 12:14:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 12:14:15 +0000
Message-ID: <1329912853.2880.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 12:14:13 +0000
In-Reply-To: <20292.55403.163069.11201@mariner.uk.xensource.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
	<20292.55403.163069.11201@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 11:58 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)"):
> > IanJ -- when you are ready to push the xen-unstable.hg side please
> > include an update of SEABIOS_UPSTREAM_TAG to
> > 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> > is currently).
> 
> I think each side of this change is harmless independently, so you can
> go ahead and do that whenever you think it right.  But perhaps we
> should wait with this and the $(PYTHON)-passing patch until we get the
> tree building again.

Ack on waiting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:17:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12: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 1S0B8Y-00070y-7B; Wed, 22 Feb 2012 12:17:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1S0B8W-00070T-PM
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:17:33 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329913045!14223219!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28308 invoked from network); 22 Feb 2012 12:17:26 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 12:17:26 -0000
Received: by iaeh11 with SMTP id h11so57188709iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 04:17:24 -0800 (PST)
Received-SPF: pass (google.com: domain of avscomputing@gmail.com designates
	10.50.36.230 as permitted sender) client-ip=10.50.36.230; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of avscomputing@gmail.com
	designates 10.50.36.230 as permitted sender)
	smtp.mail=avscomputing@gmail.com;
	dkim=pass header.i=avscomputing@gmail.com
Received: from mr.google.com ([10.50.36.230])
	by 10.50.36.230 with SMTP id t6mr26024795igj.5.1329913044901 (num_hops
	= 1); Wed, 22 Feb 2012 04:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=t79rxmX0Zxd0cy8rPGvFlAi4gzthtJUTP39lN3fo12E=;
	b=c/5V8t/ZkyUQKt5agFmp/d+k5dTvGQzGHJjh2ZGpwShTbNi2qo3MgNtlyrgY+Rxsl5
	b6Lji4fQR4W4Ml79PSOPxZYapN5o1ZrnBFQ157YGaqVE+bn64x2ToZ11ufcDKxGk60fe
	9a/ZrjedrbD8dcR7g0mNbW70a2zZ6T5GMh0kw=
MIME-Version: 1.0
Received: by 10.50.36.230 with SMTP id t6mr21075354igj.5.1329913044822; Wed,
	22 Feb 2012 04:17:24 -0800 (PST)
Received: by 10.231.68.203 with HTTP; Wed, 22 Feb 2012 04:17:24 -0800 (PST)
In-Reply-To: <20120221165830.GA32413@phenom.dumpdata.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
	<20120221165830.GA32413@phenom.dumpdata.com>
Date: Wed, 22 Feb 2012 15:17:24 +0300
Message-ID: <CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/21 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:

AS>> With custom-built kernel, I didn't yet see any GPF, but screen garbling
AS>> happens almost every time when a DomU is starting or stopping:
AS>> the whole graphical is painted with either black or not-so-random garb=
age.

KRW> So... I am curious, what graphic card do you have and do you get any of
KRW> these Red Hat BZs? =A0RH BZ# 742032, 787403, and 745574?
KRW> There is a bug in 3.2 when using radeon or nouveau for a lengthy time
KRW> that ends up "corrupting" memory. The workaround is 'nopat' kernel arg.

My idea is that my custom-built kernel can't be considered a trusted
proving ground,
as it is of very low quality. Video issue is just the most obvious
example. Another
indisputable example is how the Dom0 reboots: instead of simple CPU restart,
the whole system goes into soft-off for several seconds, then wakes back.
When I boot this kernel in bare-metal mode (without Xen VMM), none of those
happens: GUI is accelerated (at least in 2D; I don't use OpenGL desktop),
screen is not garbled at login and logout dialogs, system reboots quickly.

Anyway, I tried your solution with "nopat". It didn't worked: with 4
DomUs running
for a minute and then shut down in reverse order (4th, 3rd, 2nd, 1st),
the screen
went black right between the 3rd VM was completely shut and 2nd VM was
requested to shut. There was no "lengthy time" of Dom0 running, my video ad=
apter
is neither nVidia nor ATi, but an integrated Intel HD Graphics 2000
using i915 driver,
and I see no similarities to the Red Hat bugs mentioned by you.


KRW> Can you include more details on your machine?

My guess is that it is not just my hardware that causes GPF, but either
a bug in netback module, or a compiler issue for specific combination of Xen
(and/or particularly netback) together with openSUSE build technology.

As an example of the latter, look again at the Novell BZ #727081 mentioned
in the original post =97 the comment #30 says: "The compiler apparently mak=
es use
of the 128-byte area called 'red zone' in the ABI, and this is incompatible
with xc_cpuid_x86.c:cpuid() using pushes and pops around the cpuid instruct=
ion".
The consequence is that, on some machines, libxenguest segfaults when you
try to start a DomU. With Core i7-920 there is no problem, but with Core i5=
-2300
I faced that issue, and wonder whether the same incompatibility can take pl=
ace
in netback module. I though the traceback gives some hints on where to debu=
g.

My specs are:
MB: Asus P8H67-M (Intel H67 chipset)
CPU: Intel Core i5 model 2300 (Turbo mode disabled)
RAM: 12GB DDR3-1333 non-ECC (recently checked by MemTest86+ 4.20)
Video: Intel HD Graphics 2000 (integrated into CPU)
Network: dedicated soft-bridge for most DomUs,
 + bridged Realtek RTL8111E for gateway DomU (not with CARP)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:17:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 12: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 1S0B8Y-00070y-7B; Wed, 22 Feb 2012 12:17:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avscomputing@gmail.com>) id 1S0B8W-00070T-PM
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:17:33 +0000
X-Env-Sender: avscomputing@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1329913045!14223219!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28308 invoked from network); 22 Feb 2012 12:17:26 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 12:17:26 -0000
Received: by iaeh11 with SMTP id h11so57188709iae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 04:17:24 -0800 (PST)
Received-SPF: pass (google.com: domain of avscomputing@gmail.com designates
	10.50.36.230 as permitted sender) client-ip=10.50.36.230; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of avscomputing@gmail.com
	designates 10.50.36.230 as permitted sender)
	smtp.mail=avscomputing@gmail.com;
	dkim=pass header.i=avscomputing@gmail.com
Received: from mr.google.com ([10.50.36.230])
	by 10.50.36.230 with SMTP id t6mr26024795igj.5.1329913044901 (num_hops
	= 1); Wed, 22 Feb 2012 04:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=t79rxmX0Zxd0cy8rPGvFlAi4gzthtJUTP39lN3fo12E=;
	b=c/5V8t/ZkyUQKt5agFmp/d+k5dTvGQzGHJjh2ZGpwShTbNi2qo3MgNtlyrgY+Rxsl5
	b6Lji4fQR4W4Ml79PSOPxZYapN5o1ZrnBFQ157YGaqVE+bn64x2ToZ11ufcDKxGk60fe
	9a/ZrjedrbD8dcR7g0mNbW70a2zZ6T5GMh0kw=
MIME-Version: 1.0
Received: by 10.50.36.230 with SMTP id t6mr21075354igj.5.1329913044822; Wed,
	22 Feb 2012 04:17:24 -0800 (PST)
Received: by 10.231.68.203 with HTTP; Wed, 22 Feb 2012 04:17:24 -0800 (PST)
In-Reply-To: <20120221165830.GA32413@phenom.dumpdata.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
	<20120221165830.GA32413@phenom.dumpdata.com>
Date: Wed, 22 Feb 2012 15:17:24 +0300
Message-ID: <CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
From: Anton Samsonov <avscomputing@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/21 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:

AS>> With custom-built kernel, I didn't yet see any GPF, but screen garbling
AS>> happens almost every time when a DomU is starting or stopping:
AS>> the whole graphical is painted with either black or not-so-random garb=
age.

KRW> So... I am curious, what graphic card do you have and do you get any of
KRW> these Red Hat BZs? =A0RH BZ# 742032, 787403, and 745574?
KRW> There is a bug in 3.2 when using radeon or nouveau for a lengthy time
KRW> that ends up "corrupting" memory. The workaround is 'nopat' kernel arg.

My idea is that my custom-built kernel can't be considered a trusted
proving ground,
as it is of very low quality. Video issue is just the most obvious
example. Another
indisputable example is how the Dom0 reboots: instead of simple CPU restart,
the whole system goes into soft-off for several seconds, then wakes back.
When I boot this kernel in bare-metal mode (without Xen VMM), none of those
happens: GUI is accelerated (at least in 2D; I don't use OpenGL desktop),
screen is not garbled at login and logout dialogs, system reboots quickly.

Anyway, I tried your solution with "nopat". It didn't worked: with 4
DomUs running
for a minute and then shut down in reverse order (4th, 3rd, 2nd, 1st),
the screen
went black right between the 3rd VM was completely shut and 2nd VM was
requested to shut. There was no "lengthy time" of Dom0 running, my video ad=
apter
is neither nVidia nor ATi, but an integrated Intel HD Graphics 2000
using i915 driver,
and I see no similarities to the Red Hat bugs mentioned by you.


KRW> Can you include more details on your machine?

My guess is that it is not just my hardware that causes GPF, but either
a bug in netback module, or a compiler issue for specific combination of Xen
(and/or particularly netback) together with openSUSE build technology.

As an example of the latter, look again at the Novell BZ #727081 mentioned
in the original post =97 the comment #30 says: "The compiler apparently mak=
es use
of the 128-byte area called 'red zone' in the ABI, and this is incompatible
with xc_cpuid_x86.c:cpuid() using pushes and pops around the cpuid instruct=
ion".
The consequence is that, on some machines, libxenguest segfaults when you
try to start a DomU. With Core i7-920 there is no problem, but with Core i5=
-2300
I faced that issue, and wonder whether the same incompatibility can take pl=
ace
in netback module. I though the traceback gives some hints on where to debu=
g.

My specs are:
MB: Asus P8H67-M (Intel H67 chipset)
CPU: Intel Core i5 model 2300 (Turbo mode disabled)
RAM: 12GB DDR3-1333 non-ECC (recently checked by MemTest86+ 4.20)
Video: Intel HD Graphics 2000 (integrated into CPU)
Network: dedicated soft-bridge for most DomUs,
 + bridged Realtek RTL8111E for gateway DomU (not with CARP)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:34:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0BOW-0007QT-1P; Wed, 22 Feb 2012 12:34:04 +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 1S0BOT-0007QO-82
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:34:02 +0000
Received: from [85.158.139.83:20171] by server-4.bemta-5.messagelabs.com id
	28/01-10788-8B0E44F4; Wed, 22 Feb 2012 12:34:00 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329914039!15594328!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2497 invoked from network); 22 Feb 2012 12:33:59 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.208)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 12:33:59 -0000
Received: from mail16-am1-R.bigfish.com (10.3.201.231) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 12:33:53 +0000
Received: from mail16-am1 (localhost [127.0.0.1])	by mail16-am1-R.bigfish.com
	(Postfix) with ESMTP id BB2674E015C;
	Wed, 22 Feb 2012 12:33:53 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzzz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1
	(MessageSwitch) id 1329914032333108_18376;
	Wed, 22 Feb 2012 12:33:52 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.254])	by
	mail16-am1.bigfish.com (Postfix) with ESMTP id 43527E004A;
	Wed, 22 Feb 2012 12:33:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 12:33:51 +0000
X-WSS-ID: 0LZSO8G-02-FNW-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 23086C80C1;	Wed, 22 Feb 2012 06:33:52 -0600 (CST)
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;
	Wed, 22 Feb 2012 06:34:06 -0600
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, 22 Feb 2012 06:33:54 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	07:33:53 -0500
Message-ID: <4F44E0B0.8010007@amd.com>
Date: Wed, 22 Feb 2012 13:33:52 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329911626.2880.42.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/22/12 12:53, Ian Campbell wrote:
> On Tue, 2012-02-21 at 16:17 +0000, Ian Campbell wrote:
>>> it needs to be what you would need to
>>> edit to change the result of the Xen build.  So either it must be
>>> .._TAG
>>
>> I'll choose this option. I'll also edit the repo description to make it
>> clear that all branches are rebasing.
>>
>>>   or it must be some fast-forwarding branch constructed from the
>>> series of _TAG values.  (Ie, a branch whose commits correspond 1:1
>>> with _TAG values, each commit on the master branch having the previous
>>> master commit as its left parent and the _TAG, which determines the
>>> contents, as the right parent.)
>>
>> I think I'd inevitably end up cocking this scheme up, especially given
>> the expected frequency of seabios updates (e.g. v. low).
>
> ... actually I don't need to pick between the two until this actually
> happens. When it does happen I'll play with the second option and
> determine if I am capable of not making a mess of it etc.
>
> For now I have cherry-picked the upstream fix onto a new branch
> "1.6.3-stable-xen" and pushed that branch to our repo. I have also
> updated the "xen-unstable" branch (the default branch) with the same.
>
> IanJ -- when you are ready to push the xen-unstable.hg side please
> include an update of SEABIOS_UPSTREAM_TAG to
> 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> is currently).

There is still one fix missing from upstream, namely: 
805ede2bd35243a4298bc64bd81be6db7cf57f58

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 12:34:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0BOW-0007QT-1P; Wed, 22 Feb 2012 12:34:04 +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 1S0BOT-0007QO-82
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 12:34:02 +0000
Received: from [85.158.139.83:20171] by server-4.bemta-5.messagelabs.com id
	28/01-10788-8B0E44F4; Wed, 22 Feb 2012 12:34:00 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329914039!15594328!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2497 invoked from network); 22 Feb 2012 12:33:59 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.208)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	22 Feb 2012 12:33:59 -0000
Received: from mail16-am1-R.bigfish.com (10.3.201.231) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 12:33:53 +0000
Received: from mail16-am1 (localhost [127.0.0.1])	by mail16-am1-R.bigfish.com
	(Postfix) with ESMTP id BB2674E015C;
	Wed, 22 Feb 2012 12:33:53 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzzz2dh668h839h93fh)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1
	(MessageSwitch) id 1329914032333108_18376;
	Wed, 22 Feb 2012 12:33:52 +0000 (UTC)
Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.254])	by
	mail16-am1.bigfish.com (Postfix) with ESMTP id 43527E004A;
	Wed, 22 Feb 2012 12:33:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server id
	14.1.225.23; Wed, 22 Feb 2012 12:33:51 +0000
X-WSS-ID: 0LZSO8G-02-FNW-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 23086C80C1;	Wed, 22 Feb 2012 06:33:52 -0600 (CST)
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;
	Wed, 22 Feb 2012 06:34:06 -0600
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, 22 Feb 2012 06:33:54 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012
	07:33:53 -0500
Message-ID: <4F44E0B0.8010007@amd.com>
Date: Wed, 22 Feb 2012 13:33:52 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329911626.2880.42.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/22/12 12:53, Ian Campbell wrote:
> On Tue, 2012-02-21 at 16:17 +0000, Ian Campbell wrote:
>>> it needs to be what you would need to
>>> edit to change the result of the Xen build.  So either it must be
>>> .._TAG
>>
>> I'll choose this option. I'll also edit the repo description to make it
>> clear that all branches are rebasing.
>>
>>>   or it must be some fast-forwarding branch constructed from the
>>> series of _TAG values.  (Ie, a branch whose commits correspond 1:1
>>> with _TAG values, each commit on the master branch having the previous
>>> master commit as its left parent and the _TAG, which determines the
>>> contents, as the right parent.)
>>
>> I think I'd inevitably end up cocking this scheme up, especially given
>> the expected frequency of seabios updates (e.g. v. low).
>
> ... actually I don't need to pick between the two until this actually
> happens. When it does happen I'll play with the second option and
> determine if I am capable of not making a mess of it etc.
>
> For now I have cherry-picked the upstream fix onto a new branch
> "1.6.3-stable-xen" and pushed that branch to our repo. I have also
> updated the "xen-unstable" branch (the default branch) with the same.
>
> IanJ -- when you are ready to push the xen-unstable.hg side please
> include an update of SEABIOS_UPSTREAM_TAG to
> 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> is currently).

There is still one fix missing from upstream, namely: 
805ede2bd35243a4298bc64bd81be6db7cf57f58

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:08:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Bv0-0008EK-OZ; Wed, 22 Feb 2012 13:07:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Buz-0008EF-1v
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:07:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329916050!9293274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25048 invoked from network); 22 Feb 2012 13:07:31 -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;
	22 Feb 2012 13:07:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10872707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 13:07:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 13:07:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0Bus-0003ym-7g; Wed, 22 Feb 2012 13:07:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0Bus-0002aT-6q;
	Wed, 22 Feb 2012 13:07:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.59538.106293.644879@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 13:07:30 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH] autoconf: remove brctl check"):
> This bit was missing, sorry:
> =

> autoconf: clean brctl options
> =

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Let me cancel another doomed test run...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:08:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:08:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Bv0-0008EK-OZ; Wed, 22 Feb 2012 13:07:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Buz-0008EF-1v
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:07:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329916050!9293274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25048 invoked from network); 22 Feb 2012 13:07:31 -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;
	22 Feb 2012 13:07:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10872707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 13:07:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 13:07:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0Bus-0003ym-7g; Wed, 22 Feb 2012 13:07:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0Bus-0002aT-6q;
	Wed, 22 Feb 2012 13:07:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.59538.106293.644879@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 13:07:30 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH] autoconf: remove brctl check"):
> This bit was missing, sorry:
> =

> autoconf: clean brctl options
> =

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Let me cancel another doomed test run...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:10:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:10:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Bxd-0008Jw-LJ; Wed, 22 Feb 2012 13:10:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Bxb-0008Jl-PQ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 13:10:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329916212!10216250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29974 invoked from network); 22 Feb 2012 13:10:13 -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;
	22 Feb 2012 13:10:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10872778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 13:10:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 13:10:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0BxU-00043p-3k;
	Wed, 22 Feb 2012 13:10:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0BxU-0004Tn-1R;
	Wed, 22 Feb 2012 13:10:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12017-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 13:10:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12017: regressions - trouble:
	fail/preparing/queued
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12017 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12017/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-intel    <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 build-i386-oldkern            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-i386                    1 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 build-amd64-pvops             1 hosts-allocate           running [st=running!]
 test-amd64-i386-win             <none executed>              queued
 build-amd64                   4 xen-build                 fail REGR. vs. 12003
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12003
 test-i386-i386-pair             <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued

version targeted for testing:
 xen                  4aa563f19a18
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   preparing
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            preparing
 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:   24863:4aa563f19a18
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:56:24 2012 +0000
    
    autoconf: remove udev checks from build
    
    There's no need to have udev when building Xen since it's only used at
    run time.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24862:69c6e5d33f10
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:54:16 2012 +0000
    
    autoconf: remove brctl check
    
    Remove brctl check since it's usually only available to users with
    high privileges, but Xen should be buildable by regular users.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24861:8ee81ceda8c9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:10:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:10:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Bxd-0008Jw-LJ; Wed, 22 Feb 2012 13:10:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Bxb-0008Jl-PQ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 13:10:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329916212!10216250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29974 invoked from network); 22 Feb 2012 13:10:13 -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;
	22 Feb 2012 13:10:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10872778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 13:10:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 13:10:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0BxU-00043p-3k;
	Wed, 22 Feb 2012 13:10:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0BxU-0004Tn-1R;
	Wed, 22 Feb 2012 13:10:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12017-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 13:10:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12017: regressions - trouble:
	fail/preparing/queued
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12017 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12017/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-intel    <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 build-i386-oldkern            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-i386                    1 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 build-amd64-pvops             1 hosts-allocate           running [st=running!]
 test-amd64-i386-win             <none executed>              queued
 build-amd64                   4 xen-build                 fail REGR. vs. 12003
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12003
 test-i386-i386-pair             <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued

version targeted for testing:
 xen                  4aa563f19a18
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   preparing
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            preparing
 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:   24863:4aa563f19a18
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:56:24 2012 +0000
    
    autoconf: remove udev checks from build
    
    There's no need to have udev when building Xen since it's only used at
    run time.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24862:69c6e5d33f10
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:54:16 2012 +0000
    
    autoconf: remove brctl check
    
    Remove brctl check since it's usually only available to users with
    high privileges, but Xen should be buildable by regular users.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24861:8ee81ceda8c9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:11:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:11:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0By2-0008M0-7p; Wed, 22 Feb 2012 13:10:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0By0-0008LZ-MM
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:10:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329916235!10225962!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5830 invoked from network); 22 Feb 2012 13:10:36 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:10:36 -0000
Received: by werh12 with SMTP id h12so7963wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:10:35 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr44181263wib.3.1329916235480
	(num_hops = 1); Wed, 22 Feb 2012 05:10:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=nN9lmtslO4Hh9nQNOvQxREVtMIixRXfo2ElAxrFNA24=;
	b=yEgU3IqrB9W6gKiK7HmB8uWyZokvqlYxCBfCvoGbR9knxirMEcyMRUu/SUSE6u8aGY
	0GiNZdAMxGBh4fZ77MNjY0O2iQu0ezFPu74sFL4YM2gZgOz+ZYBIOCY84zig7RjtQjHF
	DPXuFuc/h+B508aviqoYDMgFInIJxmU+nml2w=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr36573292wib.3.1329916235334; Wed,
	22 Feb 2012 05:10:35 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 05:10:35 -0800 (PST)
In-Reply-To: <20292.59538.106293.644879@mariner.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
	<20292.59538.106293.644879@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 14:10:35 +0100
X-Google-Sender-Auth: THPhZDV8fk0zOxLdNvGXlrfajbo
Message-ID: <CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbUEFUQ0hdIGF1dG9jb25mOiByZW1vdmUgYnJjdGwg
Y2hlY2siKToKPj4gVGhpcyBiaXQgd2FzIG1pc3NpbmcsIHNvcnJ5Ogo+Pgo+PiBhdXRvY29uZjog
Y2xlYW4gYnJjdGwgb3B0aW9ucwo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Cj4gQWNrZWQtYnk6IElhbiBKYWNrc29uIDxpYW4u
amFja3NvbkBldS5jaXRyaXguY29tPgo+IENvbW1pdHRlZC1ieTogSWFuIEphY2tzb24gPGlhbi5q
YWNrc29uQGV1LmNpdHJpeC5jb20+Cj4KPiBMZXQgbWUgY2FuY2VsIGFub3RoZXIgZG9vbWVkIHRl
c3QgcnVuLi4uCgpUaGlzIGlzIG1vcmUgb2YgYSBjb3NtZXRpYyBmaXggdGhhbiBhbnl0aGluZywg
aXQgc2hvdWxkIG5vdCBibG9jayB5b3VyIHRlc3RzLgoKPiBJYW4uCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:11:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:11:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0By2-0008M0-7p; Wed, 22 Feb 2012 13:10:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0By0-0008LZ-MM
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:10:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329916235!10225962!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5830 invoked from network); 22 Feb 2012 13:10:36 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:10:36 -0000
Received: by werh12 with SMTP id h12so7963wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:10:35 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr44181263wib.3.1329916235480
	(num_hops = 1); Wed, 22 Feb 2012 05:10:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=nN9lmtslO4Hh9nQNOvQxREVtMIixRXfo2ElAxrFNA24=;
	b=yEgU3IqrB9W6gKiK7HmB8uWyZokvqlYxCBfCvoGbR9knxirMEcyMRUu/SUSE6u8aGY
	0GiNZdAMxGBh4fZ77MNjY0O2iQu0ezFPu74sFL4YM2gZgOz+ZYBIOCY84zig7RjtQjHF
	DPXuFuc/h+B508aviqoYDMgFInIJxmU+nml2w=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr36573292wib.3.1329916235334; Wed,
	22 Feb 2012 05:10:35 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 05:10:35 -0800 (PST)
In-Reply-To: <20292.59538.106293.644879@mariner.uk.xensource.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
	<20292.59538.106293.644879@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 14:10:35 +0100
X-Google-Sender-Auth: THPhZDV8fk0zOxLdNvGXlrfajbo
Message-ID: <CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbUEFUQ0hdIGF1dG9jb25mOiByZW1vdmUgYnJjdGwg
Y2hlY2siKToKPj4gVGhpcyBiaXQgd2FzIG1pc3NpbmcsIHNvcnJ5Ogo+Pgo+PiBhdXRvY29uZjog
Y2xlYW4gYnJjdGwgb3B0aW9ucwo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Cj4gQWNrZWQtYnk6IElhbiBKYWNrc29uIDxpYW4u
amFja3NvbkBldS5jaXRyaXguY29tPgo+IENvbW1pdHRlZC1ieTogSWFuIEphY2tzb24gPGlhbi5q
YWNrc29uQGV1LmNpdHJpeC5jb20+Cj4KPiBMZXQgbWUgY2FuY2VsIGFub3RoZXIgZG9vbWVkIHRl
c3QgcnVuLi4uCgpUaGlzIGlzIG1vcmUgb2YgYSBjb3NtZXRpYyBmaXggdGhhbiBhbnl0aGluZywg
aXQgc2hvdWxkIG5vdCBibG9jayB5b3VyIHRlc3RzLgoKPiBJYW4uCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:11:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0ByN-0008Og-LS; Wed, 22 Feb 2012 13:11:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0ByM-0008OR-Eq
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 13:11:06 +0000
Received: from [85.158.139.83:31671] by server-12.bemta-5.messagelabs.com id
	65/B2-24595-969E44F4; Wed, 22 Feb 2012 13:11:05 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329916263!15291647!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTYwNTI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28525 invoked from network); 22 Feb 2012 13:11:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2012 13:11:04 -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 q1MDAw0K021901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 13:10: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
	q1MDAvAt013898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 13:10:58 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
	q1MDAuTm023923; Wed, 22 Feb 2012 07:10:57 -0600
Received: from [221.218.36.201] (/221.218.36.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 05:10:56 -0800
Message-ID: <4F44E94A.2060209@oracle.com>
Date: Wed, 22 Feb 2012 21:10:34 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F41F41F.9060601@oracle.com>	
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	
	<4F430201.3040208@oracle.com>
	<1329908701.2880.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329908701.2880.26.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090207.4F44E963.0155,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thanks a lot for your reply, Ian.
I guess there is misunderstanding here, see following,
> The Linux kernel's version of mktime and Xen's version both differ from
> standard C/POSIX defined function (in fact I expect Xen's is derived
> from Linux's). Not least because they take a bunch of values instead of
> a struct tm as arguments (i.e. they take unsigned int year, not
> tm->tm_year).
>   
Yes, Xen's is same as Linux's.
> If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
> want the libc version. The Xen and Linux mktime()s certainly differ
> substantially from the eglibc one.
>   
Thanks, my original aim is to address an issue in rtc_set_time of 
\xen\arch\x86\hvm\rtc.c. (at least I thought it was, need your 
confirmation :-) )
> I don't think you can expect that the in-kernel mktime necessarily has
> the same interface as POSIX documents, there is certainly no particular
> reason why they should or must (a kernel is not a POSIX environment).
> The comment preceding Xen's mktime makes no mention of offsetting
> anything by 1900 (or anything else) and I believe its implementation is
> consistent with its defined interface.
>   
Yes, the comments does not mention of offsetting anything by 1900, and 
this is the reason why I created the patch.
In \xen\arch\x86\hvm\rtc.c, rtc_set_time call mktime to calculate the 
seconds since 1970/01/01, the input parameters of mktime are required to 
be in normal date format. Such as: year=1980, mon=12, day=31, hour=23, 
min=59, sec=59. (Just like Linux)

However, current xen code has some problem when dealing with 
tm->tm_year, see following,
    tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
    after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
                   tm->tm_hour, tm->tm_min, tm->tm_sec);
(For example, if current time is 2012/12/31, tm->tm_year is 112 here)

To meet the requirement of Xen's mktime, tm->tm_year should be changed 
to tm->tm_year+1900 when calling mktime in Xen. See following,
    after = mktime(tm->tm_year+1900, tm->tm_mon+1, tm->tm_mday,
                   tm->tm_hour, tm->tm_min, tm->tm_sec);

Thanks,
Annie
> Ian.
>
>   
>> See following diff file which is created between mktime of linux and 
>> mktime of xen, (I did some tab/space format changes for comparison)
>>
>> diff linux-mktime.c xen-mktime.c
>> 2,4c2,4
>> < mktime(const unsigned int year0, const unsigned int mon0,
>> <       const unsigned int day, const unsigned int hour,
>> <       const unsigned int min, const unsigned int sec)
>> ---
>>  > mktime (unsigned int year, unsigned int mon,
>>  >       unsigned int day, unsigned int hour,
>>  >       unsigned int min, unsigned int sec)
>> 6,8c6
>> <       unsigned int mon = mon0, year = year0;
>> <
>> <       /* 1..12 -> 11,12,1..10 */
>> ---
>>  >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
>> 10c8
>> <               mon += 12;      /* Puts Feb last since it has leap day */
>> ---
>>  >               mon += 12;
>> 21d18
>> <
>>
>> Thanks
>> Annie
>>     
>>> best regards
>>> yang
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xensource.com/xen-devel
>>     
>
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:11:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0ByN-0008Og-LS; Wed, 22 Feb 2012 13:11:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0ByM-0008OR-Eq
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 13:11:06 +0000
Received: from [85.158.139.83:31671] by server-12.bemta-5.messagelabs.com id
	65/B2-24595-969E44F4; Wed, 22 Feb 2012 13:11:05 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329916263!15291647!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTYwNTI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28525 invoked from network); 22 Feb 2012 13:11:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2012 13:11:04 -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 q1MDAw0K021901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 13:10: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
	q1MDAvAt013898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 13:10:58 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
	q1MDAuTm023923; Wed, 22 Feb 2012 07:10:57 -0600
Received: from [221.218.36.201] (/221.218.36.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 05:10:56 -0800
Message-ID: <4F44E94A.2060209@oracle.com>
Date: Wed, 22 Feb 2012 21:10:34 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F41F41F.9060601@oracle.com>	
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	
	<4F430201.3040208@oracle.com>
	<1329908701.2880.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329908701.2880.26.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090207.4F44E963.0155,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thanks a lot for your reply, Ian.
I guess there is misunderstanding here, see following,
> The Linux kernel's version of mktime and Xen's version both differ from
> standard C/POSIX defined function (in fact I expect Xen's is derived
> from Linux's). Not least because they take a bunch of values instead of
> a struct tm as arguments (i.e. they take unsigned int year, not
> tm->tm_year).
>   
Yes, Xen's is same as Linux's.
> If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
> want the libc version. The Xen and Linux mktime()s certainly differ
> substantially from the eglibc one.
>   
Thanks, my original aim is to address an issue in rtc_set_time of 
\xen\arch\x86\hvm\rtc.c. (at least I thought it was, need your 
confirmation :-) )
> I don't think you can expect that the in-kernel mktime necessarily has
> the same interface as POSIX documents, there is certainly no particular
> reason why they should or must (a kernel is not a POSIX environment).
> The comment preceding Xen's mktime makes no mention of offsetting
> anything by 1900 (or anything else) and I believe its implementation is
> consistent with its defined interface.
>   
Yes, the comments does not mention of offsetting anything by 1900, and 
this is the reason why I created the patch.
In \xen\arch\x86\hvm\rtc.c, rtc_set_time call mktime to calculate the 
seconds since 1970/01/01, the input parameters of mktime are required to 
be in normal date format. Such as: year=1980, mon=12, day=31, hour=23, 
min=59, sec=59. (Just like Linux)

However, current xen code has some problem when dealing with 
tm->tm_year, see following,
    tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
    after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
                   tm->tm_hour, tm->tm_min, tm->tm_sec);
(For example, if current time is 2012/12/31, tm->tm_year is 112 here)

To meet the requirement of Xen's mktime, tm->tm_year should be changed 
to tm->tm_year+1900 when calling mktime in Xen. See following,
    after = mktime(tm->tm_year+1900, tm->tm_mon+1, tm->tm_mday,
                   tm->tm_hour, tm->tm_min, tm->tm_sec);

Thanks,
Annie
> Ian.
>
>   
>> See following diff file which is created between mktime of linux and 
>> mktime of xen, (I did some tab/space format changes for comparison)
>>
>> diff linux-mktime.c xen-mktime.c
>> 2,4c2,4
>> < mktime(const unsigned int year0, const unsigned int mon0,
>> <       const unsigned int day, const unsigned int hour,
>> <       const unsigned int min, const unsigned int sec)
>> ---
>>  > mktime (unsigned int year, unsigned int mon,
>>  >       unsigned int day, unsigned int hour,
>>  >       unsigned int min, unsigned int sec)
>> 6,8c6
>> <       unsigned int mon = mon0, year = year0;
>> <
>> <       /* 1..12 -> 11,12,1..10 */
>> ---
>>  >       /* 1..12 -> 11,12,1..10: put Feb last since it has a leap day. */
>> 10c8
>> <               mon += 12;      /* Puts Feb last since it has leap day */
>> ---
>>  >               mon += 12;
>> 21d18
>> <
>>
>> Thanks
>> Annie
>>     
>>> best regards
>>> yang
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xensource.com/xen-devel
>>     
>
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:16:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0C2t-0000NQ-Db; Wed, 22 Feb 2012 13:15:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0C2s-0000N5-Ba
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:15:46 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329916538!14433077!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30827 invoked from network); 22 Feb 2012 13:15:39 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:15:39 -0000
Received: by werh12 with SMTP id h12so12042wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:15:37 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr44235547wib.3.1329916537957
	(num_hops = 1); Wed, 22 Feb 2012 05:15:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=LPRAnTpu5ZAVJQFIwDRAJCKpOfOmOsn6vW4TFXJV1W4=;
	b=iZ3ywoZb/MThvzKg/iIuV2CfuhT2WH4P1ayWX3+K9fM9n16QyPuQP3C0W5ZrqqTXHD
	Gm5YWnRTk5uJllcvaq6UJH6fj1o75zXNUKyWv45K4SxxcpLmc8ull/lxx4sF6fL6Ye/H
	yc61lUo0mmqjJEedZt7krRMbmsM/duONIUd0Q=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr36617392wib.3.1329916537868; Wed,
	22 Feb 2012 05:15:37 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 05:15:37 -0800 (PST)
In-Reply-To: <CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
	<20292.59538.106293.644879@mariner.uk.xensource.com>
	<CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
Date: Wed, 22 Feb 2012 14:15:37 +0100
X-Google-Sender-Auth: haRiV2giT9ntTye1VAExSt_oqZw
Message-ID: <CAPLaKK4J2J2bEcd254aJt0Jxs6O7d0YV6PZN8ju9d17tBySD+w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PjoKPiAy
MDEyLzIvMjIgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbUEFUQ0hdIGF1dG9jb25mOiByZW1vdmUgYnJjdGwg
Y2hlY2siKToKPj4+IFRoaXMgYml0IHdhcyBtaXNzaW5nLCBzb3JyeToKPj4+Cj4+PiBhdXRvY29u
ZjogY2xlYW4gYnJjdGwgb3B0aW9ucwo+Pj4KPj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBN
b25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+Cj4+IEFja2VkLWJ5OiBJYW4gSmFja3Nv
biA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPj4gQ29tbWl0dGVkLWJ5OiBJYW4gSmFja3Nv
biA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPj4KPj4gTGV0IG1lIGNhbmNlbCBhbm90aGVy
IGRvb21lZCB0ZXN0IHJ1bi4uLgo+Cj4gVGhpcyBpcyBtb3JlIG9mIGEgY29zbWV0aWMgZml4IHRo
YW4gYW55dGhpbmcsIGl0IHNob3VsZCBub3QgYmxvY2sgeW91ciB0ZXN0cy4KCi4uLmFuZCByZW1l
bWJlciB0byBleGVjdXRlIC4vYXV0b2dlbi5zaCBvbiBldmVyeSBjb25maWd1cmUuYWMgY2hhbmdl
LAp0byB1cGRhdGUgdGhlIHNjcmlwdC4KCj4KPj4gSWFuLgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:16:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0C2t-0000NQ-Db; Wed, 22 Feb 2012 13:15:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0C2s-0000N5-Ba
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:15:46 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329916538!14433077!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30827 invoked from network); 22 Feb 2012 13:15:39 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:15:39 -0000
Received: by werh12 with SMTP id h12so12042wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:15:37 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr44235547wib.3.1329916537957
	(num_hops = 1); Wed, 22 Feb 2012 05:15:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=LPRAnTpu5ZAVJQFIwDRAJCKpOfOmOsn6vW4TFXJV1W4=;
	b=iZ3ywoZb/MThvzKg/iIuV2CfuhT2WH4P1ayWX3+K9fM9n16QyPuQP3C0W5ZrqqTXHD
	Gm5YWnRTk5uJllcvaq6UJH6fj1o75zXNUKyWv45K4SxxcpLmc8ull/lxx4sF6fL6Ye/H
	yc61lUo0mmqjJEedZt7krRMbmsM/duONIUd0Q=
MIME-Version: 1.0
Received: by 10.180.100.33 with SMTP id ev1mr36617392wib.3.1329916537868; Wed,
	22 Feb 2012 05:15:37 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Wed, 22 Feb 2012 05:15:37 -0800 (PST)
In-Reply-To: <CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
	<20292.59538.106293.644879@mariner.uk.xensource.com>
	<CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
Date: Wed, 22 Feb 2012 14:15:37 +0100
X-Google-Sender-Auth: haRiV2giT9ntTye1VAExSt_oqZw
Message-ID: <CAPLaKK4J2J2bEcd254aJt0Jxs6O7d0YV6PZN8ju9d17tBySD+w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PjoKPiAy
MDEyLzIvMjIgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbUEFUQ0hdIGF1dG9jb25mOiByZW1vdmUgYnJjdGwg
Y2hlY2siKToKPj4+IFRoaXMgYml0IHdhcyBtaXNzaW5nLCBzb3JyeToKPj4+Cj4+PiBhdXRvY29u
ZjogY2xlYW4gYnJjdGwgb3B0aW9ucwo+Pj4KPj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBN
b25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+Cj4+IEFja2VkLWJ5OiBJYW4gSmFja3Nv
biA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPj4gQ29tbWl0dGVkLWJ5OiBJYW4gSmFja3Nv
biA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KPj4KPj4gTGV0IG1lIGNhbmNlbCBhbm90aGVy
IGRvb21lZCB0ZXN0IHJ1bi4uLgo+Cj4gVGhpcyBpcyBtb3JlIG9mIGEgY29zbWV0aWMgZml4IHRo
YW4gYW55dGhpbmcsIGl0IHNob3VsZCBub3QgYmxvY2sgeW91ciB0ZXN0cy4KCi4uLmFuZCByZW1l
bWJlciB0byBleGVjdXRlIC4vYXV0b2dlbi5zaCBvbiBldmVyeSBjb25maWd1cmUuYWMgY2hhbmdl
LAp0byB1cGRhdGUgdGhlIHNjcmlwdC4KCj4KPj4gSWFuLgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0CL7-00012L-NA; Wed, 22 Feb 2012 13:34:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0CL6-00011i-4w
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:34:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329917666!10041441!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6003 invoked from network); 22 Feb 2012 13:34:26 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:34:26 -0000
Received: by wgbdy1 with SMTP id dy1so17217wgb.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:34:26 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.90.212 as permitted sender) client-ip=10.180.90.212; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.90.212 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.90.212])
	by 10.180.90.212 with SMTP id by20mr35542070wib.12.1329917666407
	(num_hops = 1); Wed, 22 Feb 2012 05:34:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=tGzBNzRrBEinhz7uIgcjnf5Rdp629dBWQ2Zgqx9ejjY=;
	b=pAMI25hm+kl4WseUCL4bs+alhVklv2StajrFj8Pdv0rVtFbzubIYt6weiFozjp4PxP
	st5f8ste6JiaU+RE1131co7VztPBXtMqrHSlkZu5mPRBG1wj2jkVtylaNEYkCAT+HFvp
	SKpKVdl3thDUU9JXkBqSLGKHyGufQJwn+vd+Q=
Received: by 10.180.90.212 with SMTP id by20mr29395672wib.12.1329917666334;
	Wed, 22 Feb 2012 05:34:26 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm71244457wib.8.2012.02.22.05.34.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 05:34:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 40f8487cacc807bb6f9d642b4fe75deaf1087833
Message-Id: <40f8487cacc807bb6f9d.1329815953@build.localdomain>
In-Reply-To: <patchbomb.1329815952@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 10:19:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Linux/init: check for brctl at xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329811412 -3600
# Node ID 40f8487cacc807bb6f9d642b4fe75deaf1087833
# Parent  c157f98ab8ff6e2e8b35cc6135f636896cb4f623
Linux/init: check for brctl at xencommons

Check for brctl at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c157f98ab8ff -r 40f8487cacc8 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 08:46:04 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
@@ -50,6 +50,9 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# Check if brctl is present
+hash brctl > /dev/null 2>&1 || echo "Warning: brctl not found"
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0CL7-00012L-NA; Wed, 22 Feb 2012 13:34:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0CL6-00011i-4w
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:34:36 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329917666!10041441!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6003 invoked from network); 22 Feb 2012 13:34:26 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:34:26 -0000
Received: by wgbdy1 with SMTP id dy1so17217wgb.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:34:26 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.90.212 as permitted sender) client-ip=10.180.90.212; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.90.212 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.90.212])
	by 10.180.90.212 with SMTP id by20mr35542070wib.12.1329917666407
	(num_hops = 1); Wed, 22 Feb 2012 05:34:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=tGzBNzRrBEinhz7uIgcjnf5Rdp629dBWQ2Zgqx9ejjY=;
	b=pAMI25hm+kl4WseUCL4bs+alhVklv2StajrFj8Pdv0rVtFbzubIYt6weiFozjp4PxP
	st5f8ste6JiaU+RE1131co7VztPBXtMqrHSlkZu5mPRBG1wj2jkVtylaNEYkCAT+HFvp
	SKpKVdl3thDUU9JXkBqSLGKHyGufQJwn+vd+Q=
Received: by 10.180.90.212 with SMTP id by20mr29395672wib.12.1329917666334;
	Wed, 22 Feb 2012 05:34:26 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm71244457wib.8.2012.02.22.05.34.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 05:34:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 40f8487cacc807bb6f9d642b4fe75deaf1087833
Message-Id: <40f8487cacc807bb6f9d.1329815953@build.localdomain>
In-Reply-To: <patchbomb.1329815952@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 10:19:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Linux/init: check for brctl at xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329811412 -3600
# Node ID 40f8487cacc807bb6f9d642b4fe75deaf1087833
# Parent  c157f98ab8ff6e2e8b35cc6135f636896cb4f623
Linux/init: check for brctl at xencommons

Check for brctl at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r c157f98ab8ff -r 40f8487cacc8 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 08:46:04 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
@@ -50,6 +50,9 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# Check if brctl is present
+hash brctl > /dev/null 2>&1 || echo "Warning: brctl not found"
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0CL3-00011t-U6; Wed, 22 Feb 2012 13:34:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0CL2-00011b-I7
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:34:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329917665!10230969!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13819 invoked from network); 22 Feb 2012 13:34:26 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:34:26 -0000
Received: by wgbdy1 with SMTP id dy1so17208wgb.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:34:25 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.96.230 as permitted sender) client-ip=10.180.96.230; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.96.230 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.96.230])
	by 10.180.96.230 with SMTP id dv6mr35382944wib.11.1329917665758
	(num_hops = 1); Wed, 22 Feb 2012 05:34:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=U8NdlV0jh+2kIjTVlKPLcD7LC+4gqIuMOY08h+oa+Ww=;
	b=iQw3n3ZNL7h3GUHKo6yR1nx2BEQ6F+47mQIy6bG4X9L86IrRIarwmmgEH3P806qQKW
	xKdYnPtI3y0a3tkV5hNS5KVTogiFhB/ueVLUZ/0UW2mQJp4de28CrjqrQsodOGtVhcq4
	/nOFFjvegf8Xol4o7fXbvWKyYG99IqtN/EFJk=
Received: by 10.180.96.230 with SMTP id dv6mr29223090wib.11.1329917665608;
	Wed, 22 Feb 2012 05:34:25 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm71244457wib.8.2012.02.22.05.34.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 05:34:25 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329815952@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 10:19:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Linux/init: add udev and brctl checks to
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 udev and brctl checks previously in tools/check to xencommons.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0CL3-00011t-U6; Wed, 22 Feb 2012 13:34:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0CL2-00011b-I7
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:34:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329917665!10230969!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13819 invoked from network); 22 Feb 2012 13:34:26 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:34:26 -0000
Received: by wgbdy1 with SMTP id dy1so17208wgb.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:34:25 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.96.230 as permitted sender) client-ip=10.180.96.230; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.96.230 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.96.230])
	by 10.180.96.230 with SMTP id dv6mr35382944wib.11.1329917665758
	(num_hops = 1); Wed, 22 Feb 2012 05:34:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=U8NdlV0jh+2kIjTVlKPLcD7LC+4gqIuMOY08h+oa+Ww=;
	b=iQw3n3ZNL7h3GUHKo6yR1nx2BEQ6F+47mQIy6bG4X9L86IrRIarwmmgEH3P806qQKW
	xKdYnPtI3y0a3tkV5hNS5KVTogiFhB/ueVLUZ/0UW2mQJp4de28CrjqrQsodOGtVhcq4
	/nOFFjvegf8Xol4o7fXbvWKyYG99IqtN/EFJk=
Received: by 10.180.96.230 with SMTP id dv6mr29223090wib.11.1329917665608;
	Wed, 22 Feb 2012 05:34:25 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm71244457wib.8.2012.02.22.05.34.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 05:34:25 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329815952@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 10:19:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Linux/init: add udev and brctl checks to
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 udev and brctl checks previously in tools/check to xencommons.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0CL4-000121-9g; Wed, 22 Feb 2012 13:34:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0CL3-00011d-9M
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:34:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329917616!61609880!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12346 invoked from network); 22 Feb 2012 13:33:36 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:33:36 -0000
Received: by werh12 with SMTP id h12so28533wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:34:27 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.226 as permitted sender) client-ip=10.180.92.226; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.226 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.226])
	by 10.180.92.226 with SMTP id cp2mr35332285wib.10.1329917667139
	(num_hops = 1); Wed, 22 Feb 2012 05:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=i3SOkv7igRbRkt1GnqGYiIy8Vm/T7n/anvvHR/fls8Q=;
	b=rxK7BZrpDDuBMYcfVmgxSrL7BrAv8Au0A9IDfyOWeipEHxvhk4KhAF7ecm09MuUPzr
	d4PPALCgYkpIzS5wGGqp08cR7eyMTHcDbOWDR2+Wj7AVlyFqYSJKJUUNcw2na1FPX4gW
	D4rRv0UAkOiUlbW3obhMWIf2a3yiGJSu7lKjk=
Received: by 10.180.92.226 with SMTP id cp2mr29222877wib.10.1329917667102;
	Wed, 22 Feb 2012 05:34:27 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm71244457wib.8.2012.02.22.05.34.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 05:34:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: eea0d53efff1fa94266026088cd5498921598df6
Message-Id: <eea0d53efff1fa942660.1329815954@build.localdomain>
In-Reply-To: <patchbomb.1329815952@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 10:19:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Linux/init: check for udev >= 59 at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329814249 -3600
# Node ID eea0d53efff1fa94266026088cd5498921598df6
# Parent  40f8487cacc807bb6f9d642b4fe75deaf1087833
Linux/init: check for udev >= 59 at xencommons

Check for udev at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 40f8487cacc8 -r eea0d53efff1 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:50:49 2012 +0100
@@ -53,6 +53,26 @@ fi
 # Check if brctl is present
 hash brctl > /dev/null 2>&1 || echo "Warning: brctl not found"
 
+# Check for udev >= 59
+if ! hash udevadm > /dev/null 2>&1
+then
+	if ! hash udevinfo > /dev/null 2>&1
+	then
+		echo "Warning: unable to find udevadm or udevinfo"
+	else
+		udevver=`udevinfo -V | awk '{print $NF}'`
+	fi
+else
+	udevver=`udevadm info -V | awk '{print $NF}'`
+fi
+if test -z "${udevver}" || test "${udevver}" -lt 59
+then
+	if ! hash hotplug > /dev/null 2>&1
+	then
+		echo "Warning: udev is too old, upgrade to version 59 or later"
+	fi
+fi
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 13: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 1S0CL4-000121-9g; Wed, 22 Feb 2012 13:34:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0CL3-00011d-9M
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 13:34:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1329917616!61609880!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12346 invoked from network); 22 Feb 2012 13:33:36 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 13:33:36 -0000
Received: by werh12 with SMTP id h12so28533wer.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 05:34:27 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.226 as permitted sender) client-ip=10.180.92.226; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.226 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.226])
	by 10.180.92.226 with SMTP id cp2mr35332285wib.10.1329917667139
	(num_hops = 1); Wed, 22 Feb 2012 05:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=i3SOkv7igRbRkt1GnqGYiIy8Vm/T7n/anvvHR/fls8Q=;
	b=rxK7BZrpDDuBMYcfVmgxSrL7BrAv8Au0A9IDfyOWeipEHxvhk4KhAF7ecm09MuUPzr
	d4PPALCgYkpIzS5wGGqp08cR7eyMTHcDbOWDR2+Wj7AVlyFqYSJKJUUNcw2na1FPX4gW
	D4rRv0UAkOiUlbW3obhMWIf2a3yiGJSu7lKjk=
Received: by 10.180.92.226 with SMTP id cp2mr29222877wib.10.1329917667102;
	Wed, 22 Feb 2012 05:34:27 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id cs4sm71244457wib.8.2012.02.22.05.34.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 05:34:26 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: eea0d53efff1fa94266026088cd5498921598df6
Message-Id: <eea0d53efff1fa942660.1329815954@build.localdomain>
In-Reply-To: <patchbomb.1329815952@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 10:19:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Linux/init: check for udev >= 59 at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329814249 -3600
# Node ID eea0d53efff1fa94266026088cd5498921598df6
# Parent  40f8487cacc807bb6f9d642b4fe75deaf1087833
Linux/init: check for udev >= 59 at xencommons

Check for udev at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 40f8487cacc8 -r eea0d53efff1 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:50:49 2012 +0100
@@ -53,6 +53,26 @@ fi
 # Check if brctl is present
 hash brctl > /dev/null 2>&1 || echo "Warning: brctl not found"
 
+# Check for udev >= 59
+if ! hash udevadm > /dev/null 2>&1
+then
+	if ! hash udevinfo > /dev/null 2>&1
+	then
+		echo "Warning: unable to find udevadm or udevinfo"
+	else
+		udevver=`udevinfo -V | awk '{print $NF}'`
+	fi
+else
+	udevver=`udevadm info -V | awk '{print $NF}'`
+fi
+if test -z "${udevver}" || test "${udevver}" -lt 59
+then
+	if ! hash hotplug > /dev/null 2>&1
+	then
+		echo "Warning: udev is too old, upgrade to version 59 or later"
+	fi
+fi
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0Cik-0002MV-B1; Wed, 22 Feb 2012 13:59:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Cij-0002ML-GS
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 13:59:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329919135!15764401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2051 invoked from network); 22 Feb 2012 13:58:55 -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;
	22 Feb 2012 13:58:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 13:58:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 13:58:55 +0000
Message-ID: <1329919132.8557.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Wed, 22 Feb 2012 13:58:52 +0000
In-Reply-To: <4F44E94A.2060209@oracle.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
	<4F430201.3040208@oracle.com>
	<1329908701.2880.26.camel@zakaz.uk.xensource.com>
	<4F44E94A.2060209@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>, young
	zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 13:10 +0000, annie li wrote:
> Thanks a lot for your reply, Ian.
> I guess there is misunderstanding here, see following,
> > The Linux kernel's version of mktime and Xen's version both differ from
> > standard C/POSIX defined function (in fact I expect Xen's is derived
> > from Linux's). Not least because they take a bunch of values instead of
> > a struct tm as arguments (i.e. they take unsigned int year, not
> > tm->tm_year).
> >   
> Yes, Xen's is same as Linux's.
> > If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
> > want the libc version. The Xen and Linux mktime()s certainly differ
> > substantially from the eglibc one.
> >   
> Thanks, my original aim is to address an issue in rtc_set_time of 
> \xen\arch\x86\hvm\rtc.c. (at least I thought it was, need your 
> confirmation :-) )
> > I don't think you can expect that the in-kernel mktime necessarily has
> > the same interface as POSIX documents, there is certainly no particular
> > reason why they should or must (a kernel is not a POSIX environment).
> > The comment preceding Xen's mktime makes no mention of offsetting
> > anything by 1900 (or anything else) and I believe its implementation is
> > consistent with its defined interface.
> >   
> Yes, the comments does not mention of offsetting anything by 1900, and 
> this is the reason why I created the patch.

Oh -- I see now that the original patch is fixing the caller and it was someone
else who introduced this red-herring about the mktime interface itself, sorry.

> In \xen\arch\x86\hvm\rtc.c, rtc_set_time call mktime to calculate the 
> seconds since 1970/01/01, the input parameters of mktime are required to 
> be in normal date format. Such as: year=1980, mon=12, day=31, hour=23, 
> min=59, sec=59. (Just like Linux)
> 
> However, current xen code has some problem when dealing with 
> tm->tm_year, see following,
>     tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
>     after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
>                    tm->tm_hour, tm->tm_min, tm->tm_sec);
> (For example, if current time is 2012/12/31, tm->tm_year is 112 here)
> 
> To meet the requirement of Xen's mktime, tm->tm_year should be changed 
> to tm->tm_year+1900 when calling mktime in Xen. See following,
>     after = mktime(tm->tm_year+1900, tm->tm_mon+1, tm->tm_mday,
>                    tm->tm_hour, tm->tm_min, tm->tm_sec);

Yes, this looks plausible to me (although I'm no expert on this code).
Something similar happens in rtc_next_second. 

Perhaps it would be better to add a function or macro to do the
conversion, such that it is somewhat self documenting? Or at least make
the 1900 a #define with a suitable name.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 13:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0Cik-0002MV-B1; Wed, 22 Feb 2012 13:59:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Cij-0002ML-GS
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 13:59:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1329919135!15764401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2051 invoked from network); 22 Feb 2012 13:58:55 -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;
	22 Feb 2012 13:58:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 13:58:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 13:58:55 +0000
Message-ID: <1329919132.8557.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Wed, 22 Feb 2012 13:58:52 +0000
In-Reply-To: <4F44E94A.2060209@oracle.com>
References: <4F41F41F.9060601@oracle.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>
	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>
	<4F430201.3040208@oracle.com>
	<1329908701.2880.26.camel@zakaz.uk.xensource.com>
	<4F44E94A.2060209@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>, young
	zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 13:10 +0000, annie li wrote:
> Thanks a lot for your reply, Ian.
> I guess there is misunderstanding here, see following,
> > The Linux kernel's version of mktime and Xen's version both differ from
> > standard C/POSIX defined function (in fact I expect Xen's is derived
> > from Linux's). Not least because they take a bunch of values instead of
> > a struct tm as arguments (i.e. they take unsigned int year, not
> > tm->tm_year).
> >   
> Yes, Xen's is same as Linux's.
> > If you wanted to compare Xen vs. a POSIX compliant mktime you'd probably
> > want the libc version. The Xen and Linux mktime()s certainly differ
> > substantially from the eglibc one.
> >   
> Thanks, my original aim is to address an issue in rtc_set_time of 
> \xen\arch\x86\hvm\rtc.c. (at least I thought it was, need your 
> confirmation :-) )
> > I don't think you can expect that the in-kernel mktime necessarily has
> > the same interface as POSIX documents, there is certainly no particular
> > reason why they should or must (a kernel is not a POSIX environment).
> > The comment preceding Xen's mktime makes no mention of offsetting
> > anything by 1900 (or anything else) and I believe its implementation is
> > consistent with its defined interface.
> >   
> Yes, the comments does not mention of offsetting anything by 1900, and 
> this is the reason why I created the patch.

Oh -- I see now that the original patch is fixing the caller and it was someone
else who introduced this red-herring about the mktime interface itself, sorry.

> In \xen\arch\x86\hvm\rtc.c, rtc_set_time call mktime to calculate the 
> seconds since 1970/01/01, the input parameters of mktime are required to 
> be in normal date format. Such as: year=1980, mon=12, day=31, hour=23, 
> min=59, sec=59. (Just like Linux)
> 
> However, current xen code has some problem when dealing with 
> tm->tm_year, see following,
>     tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
>     after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
>                    tm->tm_hour, tm->tm_min, tm->tm_sec);
> (For example, if current time is 2012/12/31, tm->tm_year is 112 here)
> 
> To meet the requirement of Xen's mktime, tm->tm_year should be changed 
> to tm->tm_year+1900 when calling mktime in Xen. See following,
>     after = mktime(tm->tm_year+1900, tm->tm_mon+1, tm->tm_mday,
>                    tm->tm_hour, tm->tm_min, tm->tm_sec);

Yes, this looks plausible to me (although I'm no expert on this code).
Something similar happens in rtc_next_second. 

Perhaps it would be better to add a function or macro to do the
conversion, such that it is somewhat self documenting? Or at least make
the 1900 a #define with a suitable name.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:07:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Cqp-0002gV-GX; Wed, 22 Feb 2012 14:07:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1S0Cqn-0002gM-IX
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 14:07:22 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329919632!15036505!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTYwNTI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1124 invoked from network); 22 Feb 2012 14:07:14 -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; 22 Feb 2012 14:07:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1ME7A5v016508
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:07:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1ME79ql016293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:07:10 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1ME79Ps011208
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 08:07:09 -0600
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 06:07:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6770476b814532bb36a3b00cba16e5cd8a6b4585
Message-Id: <6770476b814532bb36a3.1329919602@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Wed, 22 Feb 2012 09:06:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F44F690.003E,ss=1,re=-2.300,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] add new bootloader xenpvnetboot for pv guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/misc/Makefile     |    2 +-
 tools/misc/xenpvnetboot |  293 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 294 insertions(+), 1 deletions(-)


# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1329919344 18000
# Node ID 6770476b814532bb36a3b00cba16e5cd8a6b4585
# Parent  ca80eca9cfa39d1b60d1216948dac5711d550b83
add new bootloader xenpvnetboot for pv guest

`xenpvnetboot` supports getting boot images from following locations:

 - http://host/path
 - https://host/path
 - ftp://host/path
 - file:///path
 - tftp://host/path
 - nfs:host:/path
 - /path
 - /path/file.iso
 - /path/filesystem.img
 - /dev/sda1
 - nfs+iso:host:/path/file.iso
 - nfs+iso:host:/path/filesystem.img

To use it, make `xenpvnetboot` as bootloader for PV guest::

    bootloader = '/usr/bin/xenpvnetboot'

To get boot images from various locations, set the right bootloader arguments,
e.g.::

    bootloarder_args = ['--location=http://192.168.0.1/fedora/x86_64']
    bootloarder_args = ['--location=ftp://192.168.0.1/fedora/x86_64']
    bootloarder_args = ['--location=file:///fedora/x86_64']
    bootloarder_args = ['--location=tftp://192.168.0.1/fedora/x86_64']
    bootloarder_args = ['--location=/fedora/x86_64']
    bootloarder_args = ['--location=/fedora/Fedora-16-x86_64-DVD.iso']
    bootloarder_args = ['--location=nfs:192.168.0.1:/fedora/x86_64']
    bootloarder_args = ['--location=nfs+iso:192.168.0.1:/fedora/Fedora-16-x86_64-DVD.iso']

You can use `kernel` and `ramdisk` to specify the relative path of boot
kernel and ramdisk. `xenpvnetboot` will join them with the location to find the
boot kernel and ramdisk, e.g.::

    kernel = 'images/pxeboot/vmlinuz'
    ramdisk = 'images/pxeboot/initrd.img'
    bootloarder_args = ['--location=http://192.168.0.1/fedora/x86_64']

    kernel = 'fedora/x86_64/images/pxeboot/vmlinuz'
    ramdisk = 'fedora/x86_64/images/pxeboot/initrd.img'
    bootloarder_args = ['--location=http://192.168.0.1/']

You can also omit the `--location` option and specify the full URL for `kernel`
and `ramdisk` directly, e.g.:

    kernel = 'http://192.168.0.1/fedora/x86_64/images/pxeboot/vmlinuz'
    ramdisk = 'http://192.168.0.1/fedora/x86_64/images/pxeboot/initrd.img'

If only `--location` is specified and `kernel` and `ramdisk` are not specified,
`xenpvnetboot` will search the following places for boot images from the
location::

    ('images/xen/vmlinuz', 'images/xen/initrd.img'), # Fedora <= 10 and OL = 5
    ('boot/i386/vmlinuz-xen', 'boot/i386/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
    ('boot/x86_64/vmlinuz-xen', 'boot/x86_64/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
    ('current/images/netboot/xen/vmlinuz', 'current/images/netboot/xen/initrd.gz'), # Debian
    ('images/pxeboot/vmlinuz', 'images/pxeboot/initrd.img'), # Fedora >=10 and OL >= 6
    ('isolinux/vmlinuz', 'isolinux/initrd.img'), # Fedora >= 10 and OL >= 6

`xenpvnetboot` requires python module `urlgrabber <http://urlgrabber.baseurl.org/>`.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r ca80eca9cfa3 -r 6770476b8145 tools/misc/Makefile
--- a/tools/misc/Makefile	Mon Feb 20 18:34:14 2012 +0000
+++ b/tools/misc/Makefile	Wed Feb 22 09:02:24 2012 -0500
@@ -17,7 +17,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount
 SUBDIRS-$(CONFIG_MINITERM) += miniterm
 SUBDIRS := $(SUBDIRS-y)
 
-INSTALL_BIN-y := xencons
+INSTALL_BIN-y := xencons xenpvnetboot
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
diff -r ca80eca9cfa3 -r 6770476b8145 tools/misc/xenpvnetboot
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/misc/xenpvnetboot	Wed Feb 22 09:02:24 2012 -0500
@@ -0,0 +1,293 @@
+#!/usr/bin/env python
+#
+# Copyright (C) 2010 Oracle. All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free Software
+# Foundation, version 2.  This program is distributed in the hope that it will be
+# useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
+# Public License for more details.  You should have received a copy of the GNU
+# General Public License along with this program; if not, write to the Free
+# Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 021110-1307,
+# USA.
+
+import sys
+import os
+import stat
+import time
+import string
+import random
+import tempfile
+import commands
+import subprocess
+import urlgrabber
+from optparse import OptionParser
+
+
+XEN_PATHS = [
+    ('images/xen/vmlinuz', 'images/xen/initrd.img'), # Fedora <= 10 and OL = 5
+    ('boot/i386/vmlinuz-xen', 'boot/i386/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
+    ('boot/x86_64/vmlinuz-xen', 'boot/x86_64/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
+    ('current/images/netboot/xen/vmlinuz', 'current/images/netboot/xen/initrd.gz'), # Debian
+    ('images/pxeboot/vmlinuz', 'images/pxeboot/initrd.img'), # Fedora >=10 and OL >= 6
+    ('isolinux/vmlinuz', 'isolinux/initrd.img'), # Fedora >= 10 and OL >= 6
+]
+
+
+def format_sxp(kernel, ramdisk, args):
+    s = 'linux (kernel %s)' % kernel
+    if ramdisk:
+        s += '(ramdisk %s)' % ramdisk
+    if args:
+        s += '(args "%s")' % args
+    return s
+
+
+def format_simple(kernel, ramdisk, args, sep):
+    s = ('kernel %s' % kernel) + sep
+    if ramdisk:
+        s += ('ramdisk %s' % ramdisk) + sep
+    if args:
+        s += ('args %s' % args) + sep
+    s += sep
+    return s
+
+
+def mount(dev, path, option=''):
+    if os.uname()[0] == 'SunOS':
+        mountcmd = '/usr/sbin/mount'
+    else:
+        mountcmd = '/bin/mount'
+    cmd = ' '.join([mountcmd, option, dev, path])
+    (status, output) = commands.getstatusoutput(cmd)
+    if status != 0:
+        raise RuntimeError('Command: (%s) failed: (%s) %s' % (cmd, status, output))
+
+
+def umount(path):
+    if os.uname()[0] == 'SunOS':
+        cmd = ['/usr/sbin/umount', path]
+    else:
+        cmd = ['/bin/umount', path]
+    subprocess.call(cmd)
+
+
+class Fetcher:
+    def __init__(self, location, tmpdir):
+        self.location = location
+        self.tmpdir = tmpdir
+        self.srcdir = location
+
+    def prepare(self):
+        if not os.path.exists(self.tmpdir):
+            os.makedirs(self.tmpdir, 0750)
+
+    def cleanup(self):
+        pass
+
+    def get_file(self, filename):
+        url = os.path.join(self.srcdir, filename)
+        suffix = ''.join(random.sample(string.ascii_letters, 6))
+        local_name = os.path.join(self.tmpdir, 'xenpvboot.%s.%s' % (os.path.basename(filename), suffix))
+        try:
+            return urlgrabber.urlgrab(url, local_name, copy_local=1)
+        except Exception, err:
+            raise RuntimeError('Cannot get file %s: %s' % (url, err))
+
+
+class MountedFetcher(Fetcher):
+    def prepare(self):
+        Fetcher.prepare(self)
+        self.srcdir = tempfile.mkdtemp(prefix='xenpvboot.', dir=self.tmpdir)
+        if self.location.startswith('nfs:'):
+            mount(self.location[4:], self.srcdir, '-o ro')
+        else:
+            if stat.S_ISBLK(os.stat(self.location)[stat.ST_MODE]):
+                option = '-o ro'
+            else:
+                option = '-o ro,loop'
+            if os.uname()[0] == 'SunOS':
+                option += ' -F hsfs'
+            mount(self.location, self.srcdir, option)
+
+    def cleanup(self):
+        umount(self.srcdir)
+        try:
+            os.rmdir(self.srcdir)
+        except:
+            pass
+
+
+class NFSISOFetcher(MountedFetcher):
+    def __init__(self, location, tmpdir):
+        self.nfsdir = None
+        MountedFetcher.__init__(self, location, tmpdir)
+
+    def prepare(self):
+        Fetcher.prepare(self)
+        self.nfsdir = tempfile.mkdtemp(prefix='xenpvboot.', dir=self.tmpdir)
+        self.srcdir = tempfile.mkdtemp(prefix='xenpvboot.', dir=self.tmpdir)
+        nfs = os.path.dirname(self.location[8:])
+        iso = os.path.basename(self.location[8:])
+        mount(nfs, self.nfsdir, '-o ro')
+        option = '-o ro,loop'
+        if os.uname()[0] == 'SunOS':
+            option += ' -F hsfs'
+        mount(os.path.join(self.nfsdir, iso), self.srcdir, option)
+
+    def cleanup(self):
+        MountedFetcher.cleanup(self)
+        time.sleep(1)
+        umount(self.nfsdir)
+        try:
+            os.rmdir(self.nfsdir)
+        except:
+            pass
+
+
+class TFTPFetcher(Fetcher):
+    def get_file(self, filename):
+        if '/' in self.location[7:]:
+            host = self.location[7:].split('/', 1)[0].replace(':', ' ')
+            basedir = self.location[7:].split('/', 1)[1]
+        else:
+            host = self.location[7:].replace(':', ' ')
+            basedir = ''
+        suffix = ''.join(random.sample(string.ascii_letters, 6))
+        local_name = os.path.join(self.tmpdir, 'xenpvboot.%s.%s' % (os.path.basename(filename), suffix))
+        cmd = '/usr/bin/tftp %s -c get %s %s' % (host, os.path.join(basedir, filename), local_name)
+        (status, output) = commands.getstatusoutput(cmd)
+        if status != 0:
+            raise RuntimeError('Command: (%s) failed: (%s) %s' % (cmd, status, output))
+        return local_name
+
+
+def main():
+    usage = '''%prog [option]
+
+Get boot images from the given location and prepare for Xen to use.
+
+Supported locations:
+
+ - http://host/path
+ - https://host/path
+ - ftp://host/path
+ - file:///path
+ - tftp://host/path
+ - nfs:host:/path
+ - /path
+ - /path/file.iso
+ - /path/filesystem.img
+ - /dev/sda1
+ - nfs+iso:host:/path/file.iso
+ - nfs+iso:host:/path/filesystem.img'''
+    version = '%prog version 0.1'
+    parser = OptionParser(usage=usage, version=version)
+    parser.add_option('', '--location',
+                      help='The base url for kernel and ramdisk files.')
+    parser.add_option('', '--kernel',
+                      help='The kernel image file.')
+    parser.add_option('', '--ramdisk',
+                      help='The initial ramdisk file.')
+    parser.add_option('', '--args',
+                      help='Arguments pass to the kernel.')
+    parser.add_option('', '--output',
+                      help='Redirect output to this file instead of stdout.')
+    parser.add_option('', '--output-directory', default='/var/run/libxl',
+                      help='Output directory.')
+    parser.add_option('', '--output-format', default='sxp',
+                      help='Output format: sxp, simple or simple0.')
+    parser.add_option('-q', '--quiet', action='store_true',
+                      help='Be quiet.')
+    (opts, args) = parser.parse_args()
+
+    if not opts.location and not opts.kernel and not opts.ramdisk:
+        if not opts.quiet:
+            print >> sys.stderr, 'You should at least specify a location or kernel/ramdisk.'
+            parser.print_help(sys.stderr)
+        sys.exit(1)
+
+    if not opts.output or opts.output == '-':
+        fd = sys.stdout.fileno()
+    else:
+        fd = os.open(opts.output, os.O_WRONLY)
+
+    if opts.location:
+        location = opts.location
+    else:
+        location = ''
+    if (location == ''
+        or location.startswith('http://') or location.startswith('https://')
+        or location.startswith('ftp://') or location.startswith('file://')
+        or (os.path.exists(location) and os.path.isdir(location))):
+        fetcher = Fetcher(location, opts.output_directory)
+    elif location.startswith('nfs:') or (os.path.exists(location) and not os.path.isdir(location)):
+        fetcher = MountedFetcher(location, opts.output_directory)
+    elif location.startswith('nfs+iso:'):
+        fetcher = NFSISOFetcher(location, opts.output_directory)
+    elif location.startswith('tftp://'):
+        fetcher = TFTPFetcher(location, opts.output_directory)
+    else:
+        if not opts.quiet:
+            print >> sys.stderr, 'Unsupported location: %s' % location
+        sys.exit(1)
+
+    try:
+        fetcher.prepare()
+    except Exception, err:
+        if not opts.quiet:
+            print >> sys.stderr, str(err)
+        fetcher.cleanup()
+        sys.exit(1)
+
+    try:
+        kernel = None
+        if opts.kernel:
+            kernel = fetcher.get_file(opts.kernel)
+        else:
+            for (kernel_path, _) in XEN_PATHS:
+                try:
+                    kernel = fetcher.get_file(kernel_path)
+                except Exception, err:
+                    if not opts.quiet:
+                        print >> sys.stderr, str(err)
+                    continue
+                break
+
+        if not kernel:
+            if not opts.quiet:
+                print >> sys.stderr, 'Cannot get kernel from loacation: %s' % location
+            sys.exit(1)
+
+        ramdisk = None
+        if opts.ramdisk:
+            ramdisk = fetcher.get_file(opts.ramdisk)
+        else:
+            for (_, ramdisk_path) in XEN_PATHS:
+                try:
+                    ramdisk = fetcher.get_file(ramdisk_path)
+                except Exception, err:
+                    if not opts.quiet:
+                        print >> sys.stderr, str(err)
+                    continue
+                break
+    finally:
+        fetcher.cleanup()
+
+    if opts.output_format == 'sxp':
+        output = format_sxp(kernel, ramdisk, opts.args)
+    elif opts.output_format == 'simple':
+        output = format_simple(kernel, ramdisk, opts.args, '\n')
+    elif opts.output_format == 'simple0':
+        output = format_simple(kernel, ramdisk, opts.args, '\0')
+    else:
+        print >> sys.stderr, 'Unknown output format: %s' % opts.output_format
+        sys.exit(1)
+
+    sys.stdout.flush()
+    os.write(fd, output)
+
+
+if __name__ == '__main__':
+    main()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:07:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Cqp-0002gV-GX; Wed, 22 Feb 2012 14:07:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1S0Cqn-0002gM-IX
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 14:07:22 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1329919632!15036505!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTYwNTI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1124 invoked from network); 22 Feb 2012 14:07:14 -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; 22 Feb 2012 14:07:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1ME7A5v016508
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:07:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1ME79ql016293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:07:10 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1ME79Ps011208
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 08:07:09 -0600
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 06:07:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6770476b814532bb36a3b00cba16e5cd8a6b4585
Message-Id: <6770476b814532bb36a3.1329919602@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Wed, 22 Feb 2012 09:06:42 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F44F690.003E,ss=1,re=-2.300,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] add new bootloader xenpvnetboot for pv guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/misc/Makefile     |    2 +-
 tools/misc/xenpvnetboot |  293 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 294 insertions(+), 1 deletions(-)


# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1329919344 18000
# Node ID 6770476b814532bb36a3b00cba16e5cd8a6b4585
# Parent  ca80eca9cfa39d1b60d1216948dac5711d550b83
add new bootloader xenpvnetboot for pv guest

`xenpvnetboot` supports getting boot images from following locations:

 - http://host/path
 - https://host/path
 - ftp://host/path
 - file:///path
 - tftp://host/path
 - nfs:host:/path
 - /path
 - /path/file.iso
 - /path/filesystem.img
 - /dev/sda1
 - nfs+iso:host:/path/file.iso
 - nfs+iso:host:/path/filesystem.img

To use it, make `xenpvnetboot` as bootloader for PV guest::

    bootloader = '/usr/bin/xenpvnetboot'

To get boot images from various locations, set the right bootloader arguments,
e.g.::

    bootloarder_args = ['--location=http://192.168.0.1/fedora/x86_64']
    bootloarder_args = ['--location=ftp://192.168.0.1/fedora/x86_64']
    bootloarder_args = ['--location=file:///fedora/x86_64']
    bootloarder_args = ['--location=tftp://192.168.0.1/fedora/x86_64']
    bootloarder_args = ['--location=/fedora/x86_64']
    bootloarder_args = ['--location=/fedora/Fedora-16-x86_64-DVD.iso']
    bootloarder_args = ['--location=nfs:192.168.0.1:/fedora/x86_64']
    bootloarder_args = ['--location=nfs+iso:192.168.0.1:/fedora/Fedora-16-x86_64-DVD.iso']

You can use `kernel` and `ramdisk` to specify the relative path of boot
kernel and ramdisk. `xenpvnetboot` will join them with the location to find the
boot kernel and ramdisk, e.g.::

    kernel = 'images/pxeboot/vmlinuz'
    ramdisk = 'images/pxeboot/initrd.img'
    bootloarder_args = ['--location=http://192.168.0.1/fedora/x86_64']

    kernel = 'fedora/x86_64/images/pxeboot/vmlinuz'
    ramdisk = 'fedora/x86_64/images/pxeboot/initrd.img'
    bootloarder_args = ['--location=http://192.168.0.1/']

You can also omit the `--location` option and specify the full URL for `kernel`
and `ramdisk` directly, e.g.:

    kernel = 'http://192.168.0.1/fedora/x86_64/images/pxeboot/vmlinuz'
    ramdisk = 'http://192.168.0.1/fedora/x86_64/images/pxeboot/initrd.img'

If only `--location` is specified and `kernel` and `ramdisk` are not specified,
`xenpvnetboot` will search the following places for boot images from the
location::

    ('images/xen/vmlinuz', 'images/xen/initrd.img'), # Fedora <= 10 and OL = 5
    ('boot/i386/vmlinuz-xen', 'boot/i386/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
    ('boot/x86_64/vmlinuz-xen', 'boot/x86_64/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
    ('current/images/netboot/xen/vmlinuz', 'current/images/netboot/xen/initrd.gz'), # Debian
    ('images/pxeboot/vmlinuz', 'images/pxeboot/initrd.img'), # Fedora >=10 and OL >= 6
    ('isolinux/vmlinuz', 'isolinux/initrd.img'), # Fedora >= 10 and OL >= 6

`xenpvnetboot` requires python module `urlgrabber <http://urlgrabber.baseurl.org/>`.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r ca80eca9cfa3 -r 6770476b8145 tools/misc/Makefile
--- a/tools/misc/Makefile	Mon Feb 20 18:34:14 2012 +0000
+++ b/tools/misc/Makefile	Wed Feb 22 09:02:24 2012 -0500
@@ -17,7 +17,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount
 SUBDIRS-$(CONFIG_MINITERM) += miniterm
 SUBDIRS := $(SUBDIRS-y)
 
-INSTALL_BIN-y := xencons
+INSTALL_BIN-y := xencons xenpvnetboot
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
diff -r ca80eca9cfa3 -r 6770476b8145 tools/misc/xenpvnetboot
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/misc/xenpvnetboot	Wed Feb 22 09:02:24 2012 -0500
@@ -0,0 +1,293 @@
+#!/usr/bin/env python
+#
+# Copyright (C) 2010 Oracle. All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free Software
+# Foundation, version 2.  This program is distributed in the hope that it will be
+# useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
+# Public License for more details.  You should have received a copy of the GNU
+# General Public License along with this program; if not, write to the Free
+# Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 021110-1307,
+# USA.
+
+import sys
+import os
+import stat
+import time
+import string
+import random
+import tempfile
+import commands
+import subprocess
+import urlgrabber
+from optparse import OptionParser
+
+
+XEN_PATHS = [
+    ('images/xen/vmlinuz', 'images/xen/initrd.img'), # Fedora <= 10 and OL = 5
+    ('boot/i386/vmlinuz-xen', 'boot/i386/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
+    ('boot/x86_64/vmlinuz-xen', 'boot/x86_64/initrd-xen'), # openSUSE >= 10.2 and SLES >= 10
+    ('current/images/netboot/xen/vmlinuz', 'current/images/netboot/xen/initrd.gz'), # Debian
+    ('images/pxeboot/vmlinuz', 'images/pxeboot/initrd.img'), # Fedora >=10 and OL >= 6
+    ('isolinux/vmlinuz', 'isolinux/initrd.img'), # Fedora >= 10 and OL >= 6
+]
+
+
+def format_sxp(kernel, ramdisk, args):
+    s = 'linux (kernel %s)' % kernel
+    if ramdisk:
+        s += '(ramdisk %s)' % ramdisk
+    if args:
+        s += '(args "%s")' % args
+    return s
+
+
+def format_simple(kernel, ramdisk, args, sep):
+    s = ('kernel %s' % kernel) + sep
+    if ramdisk:
+        s += ('ramdisk %s' % ramdisk) + sep
+    if args:
+        s += ('args %s' % args) + sep
+    s += sep
+    return s
+
+
+def mount(dev, path, option=''):
+    if os.uname()[0] == 'SunOS':
+        mountcmd = '/usr/sbin/mount'
+    else:
+        mountcmd = '/bin/mount'
+    cmd = ' '.join([mountcmd, option, dev, path])
+    (status, output) = commands.getstatusoutput(cmd)
+    if status != 0:
+        raise RuntimeError('Command: (%s) failed: (%s) %s' % (cmd, status, output))
+
+
+def umount(path):
+    if os.uname()[0] == 'SunOS':
+        cmd = ['/usr/sbin/umount', path]
+    else:
+        cmd = ['/bin/umount', path]
+    subprocess.call(cmd)
+
+
+class Fetcher:
+    def __init__(self, location, tmpdir):
+        self.location = location
+        self.tmpdir = tmpdir
+        self.srcdir = location
+
+    def prepare(self):
+        if not os.path.exists(self.tmpdir):
+            os.makedirs(self.tmpdir, 0750)
+
+    def cleanup(self):
+        pass
+
+    def get_file(self, filename):
+        url = os.path.join(self.srcdir, filename)
+        suffix = ''.join(random.sample(string.ascii_letters, 6))
+        local_name = os.path.join(self.tmpdir, 'xenpvboot.%s.%s' % (os.path.basename(filename), suffix))
+        try:
+            return urlgrabber.urlgrab(url, local_name, copy_local=1)
+        except Exception, err:
+            raise RuntimeError('Cannot get file %s: %s' % (url, err))
+
+
+class MountedFetcher(Fetcher):
+    def prepare(self):
+        Fetcher.prepare(self)
+        self.srcdir = tempfile.mkdtemp(prefix='xenpvboot.', dir=self.tmpdir)
+        if self.location.startswith('nfs:'):
+            mount(self.location[4:], self.srcdir, '-o ro')
+        else:
+            if stat.S_ISBLK(os.stat(self.location)[stat.ST_MODE]):
+                option = '-o ro'
+            else:
+                option = '-o ro,loop'
+            if os.uname()[0] == 'SunOS':
+                option += ' -F hsfs'
+            mount(self.location, self.srcdir, option)
+
+    def cleanup(self):
+        umount(self.srcdir)
+        try:
+            os.rmdir(self.srcdir)
+        except:
+            pass
+
+
+class NFSISOFetcher(MountedFetcher):
+    def __init__(self, location, tmpdir):
+        self.nfsdir = None
+        MountedFetcher.__init__(self, location, tmpdir)
+
+    def prepare(self):
+        Fetcher.prepare(self)
+        self.nfsdir = tempfile.mkdtemp(prefix='xenpvboot.', dir=self.tmpdir)
+        self.srcdir = tempfile.mkdtemp(prefix='xenpvboot.', dir=self.tmpdir)
+        nfs = os.path.dirname(self.location[8:])
+        iso = os.path.basename(self.location[8:])
+        mount(nfs, self.nfsdir, '-o ro')
+        option = '-o ro,loop'
+        if os.uname()[0] == 'SunOS':
+            option += ' -F hsfs'
+        mount(os.path.join(self.nfsdir, iso), self.srcdir, option)
+
+    def cleanup(self):
+        MountedFetcher.cleanup(self)
+        time.sleep(1)
+        umount(self.nfsdir)
+        try:
+            os.rmdir(self.nfsdir)
+        except:
+            pass
+
+
+class TFTPFetcher(Fetcher):
+    def get_file(self, filename):
+        if '/' in self.location[7:]:
+            host = self.location[7:].split('/', 1)[0].replace(':', ' ')
+            basedir = self.location[7:].split('/', 1)[1]
+        else:
+            host = self.location[7:].replace(':', ' ')
+            basedir = ''
+        suffix = ''.join(random.sample(string.ascii_letters, 6))
+        local_name = os.path.join(self.tmpdir, 'xenpvboot.%s.%s' % (os.path.basename(filename), suffix))
+        cmd = '/usr/bin/tftp %s -c get %s %s' % (host, os.path.join(basedir, filename), local_name)
+        (status, output) = commands.getstatusoutput(cmd)
+        if status != 0:
+            raise RuntimeError('Command: (%s) failed: (%s) %s' % (cmd, status, output))
+        return local_name
+
+
+def main():
+    usage = '''%prog [option]
+
+Get boot images from the given location and prepare for Xen to use.
+
+Supported locations:
+
+ - http://host/path
+ - https://host/path
+ - ftp://host/path
+ - file:///path
+ - tftp://host/path
+ - nfs:host:/path
+ - /path
+ - /path/file.iso
+ - /path/filesystem.img
+ - /dev/sda1
+ - nfs+iso:host:/path/file.iso
+ - nfs+iso:host:/path/filesystem.img'''
+    version = '%prog version 0.1'
+    parser = OptionParser(usage=usage, version=version)
+    parser.add_option('', '--location',
+                      help='The base url for kernel and ramdisk files.')
+    parser.add_option('', '--kernel',
+                      help='The kernel image file.')
+    parser.add_option('', '--ramdisk',
+                      help='The initial ramdisk file.')
+    parser.add_option('', '--args',
+                      help='Arguments pass to the kernel.')
+    parser.add_option('', '--output',
+                      help='Redirect output to this file instead of stdout.')
+    parser.add_option('', '--output-directory', default='/var/run/libxl',
+                      help='Output directory.')
+    parser.add_option('', '--output-format', default='sxp',
+                      help='Output format: sxp, simple or simple0.')
+    parser.add_option('-q', '--quiet', action='store_true',
+                      help='Be quiet.')
+    (opts, args) = parser.parse_args()
+
+    if not opts.location and not opts.kernel and not opts.ramdisk:
+        if not opts.quiet:
+            print >> sys.stderr, 'You should at least specify a location or kernel/ramdisk.'
+            parser.print_help(sys.stderr)
+        sys.exit(1)
+
+    if not opts.output or opts.output == '-':
+        fd = sys.stdout.fileno()
+    else:
+        fd = os.open(opts.output, os.O_WRONLY)
+
+    if opts.location:
+        location = opts.location
+    else:
+        location = ''
+    if (location == ''
+        or location.startswith('http://') or location.startswith('https://')
+        or location.startswith('ftp://') or location.startswith('file://')
+        or (os.path.exists(location) and os.path.isdir(location))):
+        fetcher = Fetcher(location, opts.output_directory)
+    elif location.startswith('nfs:') or (os.path.exists(location) and not os.path.isdir(location)):
+        fetcher = MountedFetcher(location, opts.output_directory)
+    elif location.startswith('nfs+iso:'):
+        fetcher = NFSISOFetcher(location, opts.output_directory)
+    elif location.startswith('tftp://'):
+        fetcher = TFTPFetcher(location, opts.output_directory)
+    else:
+        if not opts.quiet:
+            print >> sys.stderr, 'Unsupported location: %s' % location
+        sys.exit(1)
+
+    try:
+        fetcher.prepare()
+    except Exception, err:
+        if not opts.quiet:
+            print >> sys.stderr, str(err)
+        fetcher.cleanup()
+        sys.exit(1)
+
+    try:
+        kernel = None
+        if opts.kernel:
+            kernel = fetcher.get_file(opts.kernel)
+        else:
+            for (kernel_path, _) in XEN_PATHS:
+                try:
+                    kernel = fetcher.get_file(kernel_path)
+                except Exception, err:
+                    if not opts.quiet:
+                        print >> sys.stderr, str(err)
+                    continue
+                break
+
+        if not kernel:
+            if not opts.quiet:
+                print >> sys.stderr, 'Cannot get kernel from loacation: %s' % location
+            sys.exit(1)
+
+        ramdisk = None
+        if opts.ramdisk:
+            ramdisk = fetcher.get_file(opts.ramdisk)
+        else:
+            for (_, ramdisk_path) in XEN_PATHS:
+                try:
+                    ramdisk = fetcher.get_file(ramdisk_path)
+                except Exception, err:
+                    if not opts.quiet:
+                        print >> sys.stderr, str(err)
+                    continue
+                break
+    finally:
+        fetcher.cleanup()
+
+    if opts.output_format == 'sxp':
+        output = format_sxp(kernel, ramdisk, opts.args)
+    elif opts.output_format == 'simple':
+        output = format_simple(kernel, ramdisk, opts.args, '\n')
+    elif opts.output_format == 'simple0':
+        output = format_simple(kernel, ramdisk, opts.args, '\0')
+    else:
+        print >> sys.stderr, 'Unknown output format: %s' % opts.output_format
+        sys.exit(1)
+
+    sys.stdout.flush()
+    os.write(fd, output)
+
+
+if __name__ == '__main__':
+    main()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0CzP-00032v-7n; Wed, 22 Feb 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1S0CzO-00032l-BL
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:16:14 +0000
Received: from [85.158.139.83:52980] by server-2.bemta-5.messagelabs.com id
	2D/DD-20263-DA8F44F4; Wed, 22 Feb 2012 14:16:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329920172!16167638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20122 invoked from network); 22 Feb 2012 14:16:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:16:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:15:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:15:46 +0000
Date: Wed, 22 Feb 2012 14:21:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202221410020.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: linux@eikelenboom.it, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] qemu-xen: ignore console disconnect events from
	console/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

qemu-xen: ignore console disconnect events for console/0

The first console has a different location compared to other PV devices
(console, rather than device/console/0) and doesn't obey the xenstore
state protocol. We already special case the first console in con_init
and con_initialise, we should also do it in con_disconnect.

This patch should be applied to 4.1 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/hw/xen_console.c b/hw/xen_console.c
index 0a2374c..f036b8d 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -253,6 +253,8 @@ static void con_disconnect(struct XenDevice *xendev)
 {
     struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 
+    if (!xendev->dev)
+        return;
     if (con->chr)
         qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
     xen_be_unbind_evtchn(&con->xendev);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:16:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0CzP-00032v-7n; Wed, 22 Feb 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1S0CzO-00032l-BL
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:16:14 +0000
Received: from [85.158.139.83:52980] by server-2.bemta-5.messagelabs.com id
	2D/DD-20263-DA8F44F4; Wed, 22 Feb 2012 14:16:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329920172!16167638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20122 invoked from network); 22 Feb 2012 14:16:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:16:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:15:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:15:46 +0000
Date: Wed, 22 Feb 2012 14:21:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202221410020.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: linux@eikelenboom.it, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] qemu-xen: ignore console disconnect events from
	console/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

qemu-xen: ignore console disconnect events for console/0

The first console has a different location compared to other PV devices
(console, rather than device/console/0) and doesn't obey the xenstore
state protocol. We already special case the first console in con_init
and con_initialise, we should also do it in con_disconnect.

This patch should be applied to 4.1 too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/hw/xen_console.c b/hw/xen_console.c
index 0a2374c..f036b8d 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -253,6 +253,8 @@ static void con_disconnect(struct XenDevice *xendev)
 {
     struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 
+    if (!xendev->dev)
+        return;
     if (con->chr)
         qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
     xen_be_unbind_evtchn(&con->xendev);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0D10-0003DW-OH; Wed, 22 Feb 2012 14:17:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0D0y-0003DK-UX
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:17:53 +0000
Received: from [85.158.139.83:65357] by server-4.bemta-5.messagelabs.com id
	02/54-10788-019F44F4; Wed, 22 Feb 2012 14:17:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329920271!4890756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5484 invoked from network); 22 Feb 2012 14:17:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:17:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:17:50 +0000
Date: Wed, 22 Feb 2012 14:23:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1202221423280.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Mon, 20 Feb 2012, Ian Campbell wrote:
> This is necessary to handle nested traps to the hypervisor more than one deep.
> 
> I've not seen an actually failure relating to this but I'm not quite sure how
> we've managed to get away with not doing it (I suppose multiply nested traps
> are uncommon).

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/entry.S |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index 0b9cce5..36f1119 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -102,6 +102,10 @@ ENTRY(return_to_guest)
>  
>  ENTRY(return_to_hypervisor)
>  	ldr lr, [sp, #UREGS_lr]
> +	ldr r11, [sp, #UREGS_pc]
> +	msr ELR_hyp, r11
> +	ldr r11, [sp, #UREGS_cpsr]
> +	msr SPSR_hyp, r11
>  	pop {r0-r12}
>  	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
>  	eret
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0D10-0003DW-OH; Wed, 22 Feb 2012 14:17:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0D0y-0003DK-UX
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:17:53 +0000
Received: from [85.158.139.83:65357] by server-4.bemta-5.messagelabs.com id
	02/54-10788-019F44F4; Wed, 22 Feb 2012 14:17:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1329920271!4890756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5484 invoked from network); 22 Feb 2012 14:17:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:17:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:17:50 +0000
Date: Wed, 22 Feb 2012 14:23:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1202221423280.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Mon, 20 Feb 2012, Ian Campbell wrote:
> This is necessary to handle nested traps to the hypervisor more than one deep.
> 
> I've not seen an actually failure relating to this but I'm not quite sure how
> we've managed to get away with not doing it (I suppose multiply nested traps
> are uncommon).

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/entry.S |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/entry.S b/xen/arch/arm/entry.S
> index 0b9cce5..36f1119 100644
> --- a/xen/arch/arm/entry.S
> +++ b/xen/arch/arm/entry.S
> @@ -102,6 +102,10 @@ ENTRY(return_to_guest)
>  
>  ENTRY(return_to_hypervisor)
>  	ldr lr, [sp, #UREGS_lr]
> +	ldr r11, [sp, #UREGS_pc]
> +	msr ELR_hyp, r11
> +	ldr r11, [sp, #UREGS_cpsr]
> +	msr SPSR_hyp, r11
>  	pop {r0-r12}
>  	add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */
>  	eret
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0D2c-0003O4-9e; Wed, 22 Feb 2012 14:19:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0D2a-0003NQ-VR
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:19:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329920366!12541283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27656 invoked from network); 22 Feb 2012 14:19:26 -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;
	22 Feb 2012 14:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:19:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:19:26 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0D2U-0004mf-DR;
	Wed, 22 Feb 2012 14:19:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0D2U-0004Ig-9A;
	Wed, 22 Feb 2012 14:19:26 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12018-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 14:19:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12018: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12018 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12018/

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. 12003
 build-i386                    4 xen-build                 fail REGR. vs. 12003
 build-amd64                   4 xen-build                 fail REGR. vs. 12003
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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

version targeted for testing:
 xen                  d370b93ba754
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

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:   24864:d370b93ba754
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 13:06:42 2012 +0000
    
    autoconf: clean brctl options
    
    This bit was missing, sorry.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24863:4aa563f19a18
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:56:24 2012 +0000
    
    autoconf: remove udev checks from build
    
    There's no need to have udev when building Xen since it's only used at
    run time.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24862:69c6e5d33f10
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:54:16 2012 +0000
    
    autoconf: remove brctl check
    
    Remove brctl check since it's usually only available to users with
    high privileges, but Xen should be buildable by regular users.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24861:8ee81ceda8c9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:20:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0D2c-0003O4-9e; Wed, 22 Feb 2012 14:19:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0D2a-0003NQ-VR
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:19:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1329920366!12541283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27656 invoked from network); 22 Feb 2012 14:19:26 -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;
	22 Feb 2012 14:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:19:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:19:26 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0D2U-0004mf-DR;
	Wed, 22 Feb 2012 14:19:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0D2U-0004Ig-9A;
	Wed, 22 Feb 2012 14:19:26 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12018-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 14:19:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12018: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12018 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12018/

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. 12003
 build-i386                    4 xen-build                 fail REGR. vs. 12003
 build-amd64                   4 xen-build                 fail REGR. vs. 12003
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  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           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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

version targeted for testing:
 xen                  d370b93ba754
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

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:   24864:d370b93ba754
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 13:06:42 2012 +0000
    
    autoconf: clean brctl options
    
    This bit was missing, sorry.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24863:4aa563f19a18
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:56:24 2012 +0000
    
    autoconf: remove udev checks from build
    
    There's no need to have udev when building Xen since it's only used at
    run time.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24862:69c6e5d33f10
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:54:16 2012 +0000
    
    autoconf: remove brctl check
    
    Remove brctl check since it's usually only available to users with
    high privileges, but Xen should be buildable by regular users.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24861:8ee81ceda8c9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:28:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0DAl-0003qq-O1; Wed, 22 Feb 2012 14:27:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0DAj-0003ql-UI
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 14:27:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329920871!14446539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8590 invoked from network); 22 Feb 2012 14:27:51 -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;
	22 Feb 2012 14:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:27:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:27:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0DAc-0004s3-Om; Wed, 22 Feb 2012 14:27:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0DAc-0002fu-O2;
	Wed, 22 Feb 2012 14:27:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.64358.731316.151273@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 14:27:50 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4J2J2bEcd254aJt0Jxs6O7d0YV6PZN8ju9d17tBySD+w@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
	<20292.59538.106293.644879@mariner.uk.xensource.com>
	<CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
	<CAPLaKK4J2J2bEcd254aJt0Jxs6O7d0YV6PZN8ju9d17tBySD+w@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH] autoconf: remove brctl check"):
> ...and remember to execute ./autogen.sh on every configure.ac change,
> to update the script.

Oops.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1329920838 0
# Node ID 40785b4790470b5180ded4e89e8c8b7919adb87c
# Parent  d370b93ba7543769702a25d7b9c99e5aa9adac6d
autoconf: Rerun autogen.sh

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r d370b93ba754 -r 40785b479047 tools/configure
--- a/tools/configure	Wed Feb 22 13:06:42 2012 +0000
+++ b/tools/configure	Wed Feb 22 14:27:18 2012 +0000
@@ -611,10 +611,6 @@ glib_CFLAGS
 PKG_CONFIG_LIBDIR
 PKG_CONFIG_PATH
 PKG_CONFIG
-VNCONFIG
-HOTPLUG
-UDEVINFO
-UDEVADM
 PYTHONPATH
 OCAMLBUILD
 OCAMLDOC
@@ -642,7 +638,6 @@ CURL
 FLEX
 BISON
 IP
-BRCTL
 PERL
 PYTHON
 APPEND_LIB
@@ -744,7 +739,6 @@ APPEND_INCLUDES
 APPEND_LIB
 PYTHON
 PERL
-BRCTL
 IP
 BISON
 FLEX
@@ -1400,7 +1394,6 @@ Some influential environment variables:
   APPEND_LIB  List of library folders to append to LDFLAGS (without -L)
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
-  BRCTL       Path to brctl tool
   IP          Path to ip tool
   BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
@@ -3858,8 +3851,6 @@ case $host_os in *\ *) host_os=3D`echo "$h
 =

 =

 =

-
-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autocon=
f -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -4168,7 +4159,6 @@ LDFLAGS=3D"$PREPEND_LDFLAGS $LDFLAGS $APPE
 =

 =

 =

-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not =
truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
@@ -4959,51 +4949,6 @@ if test x"${PERL}" =3D=3D x"no"
 then
     as_fn_error $? "Unable to find perl, please install perl" "$LINENO" 5
 fi
-# Extract the first word of "brctl", so it can be a program name with args.
-set dummy brctl; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BRCTL+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $BRCTL in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_BRCTL=3D"$BRCTL" # Let the user override the test with a path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_BRCTL=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_BRCTL" && ac_cv_path_BRCTL=3D"no"
-  ;;
-esac
-fi
-BRCTL=3D$ac_cv_path_BRCTL
-if test -n "$BRCTL"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $BRCTL" >&5
-$as_echo "$BRCTL" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-if test x"${BRCTL}" =3D=3D x"no"
-then
-    as_fn_error $? "Unable to find brctl, please install brctl" "$LINENO" 5
-fi
 # Extract the first word of "ip", so it can be a program name with args.
 set dummy ip; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
@@ -6440,196 +6385,6 @@ then
 fi
 if test "x$host_os" =3D=3D "xlinux-gnu"
 then
-    # Extract the first word of "udevadm", so it can be a program name wit=
h args.
-set dummy udevadm; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_UDEVADM+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $UDEVADM in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_UDEVADM=3D"$UDEVADM" # Let the user override the test with a =
path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_UDEVADM=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_UDEVADM" && ac_cv_path_UDEVADM=3D"no"
-  ;;
-esac
-fi
-UDEVADM=3D$ac_cv_path_UDEVADM
-if test -n "$UDEVADM"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $UDEVADM" >&5
-$as_echo "$UDEVADM" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-    if test x"${UDEVADM}" =3D=3D x"no"
-    then
-        # Extract the first word of "udevinfo", so it can be a program nam=
e with args.
-set dummy udevinfo; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_UDEVINFO+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $UDEVINFO in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_UDEVINFO=3D"$UDEVINFO" # Let the user override the test with =
a path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_UDEVINFO=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_UDEVINFO" && ac_cv_path_UDEVINFO=3D"no"
-  ;;
-esac
-fi
-UDEVINFO=3D$ac_cv_path_UDEVINFO
-if test -n "$UDEVINFO"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $UDEVINFO" >&5
-$as_echo "$UDEVINFO" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-        if test x"${UDEVINFO}" =3D=3D x"no"
-        then
-            as_fn_error $? "Unable to find udevadm or udevinfo, please ins=
tall udev" "$LINENO" 5
-        fi
-        udevver=3D`${UDEVINFO} -V | awk '{print $NF}'`
-    else
-        udevver=3D`${UDEVADM} info -V | awk '{print $NF}'`
-    fi
-    if test ${udevver} -lt 59
-    then
-        # Extract the first word of "hotplug", so it can be a program name=
 with args.
-set dummy hotplug; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_HOTPLUG+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $HOTPLUG in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_HOTPLUG=3D"$HOTPLUG" # Let the user override the test with a =
path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_HOTPLUG=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_HOTPLUG" && ac_cv_path_HOTPLUG=3D"no"
-  ;;
-esac
-fi
-HOTPLUG=3D$ac_cv_path_HOTPLUG
-if test -n "$HOTPLUG"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $HOTPLUG" >&5
-$as_echo "$HOTPLUG" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-        if test x"${HOTPLUG}" =3D=3D x"no"
-        then
-            as_fn_error $? "udev is too old, upgrade to version 59 or late=
r" "$LINENO" 5
-        fi
-    fi
-else
-    # Extract the first word of "vnconfig", so it can be a program name wi=
th args.
-set dummy vnconfig; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_VNCONFIG+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $VNCONFIG in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_VNCONFIG=3D"$VNCONFIG" # Let the user override the test with =
a path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_VNCONFIG=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_VNCONFIG" && ac_cv_path_VNCONFIG=3D"no"
-  ;;
-esac
-fi
-VNCONFIG=3D$ac_cv_path_VNCONFIG
-if test -n "$VNCONFIG"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $VNCONFIG" >&5
-$as_echo "$VNCONFIG" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-    if test x"${VNCONFIG}" =3D=3D x"no"
-    then
-        as_fn_error $? "Not a Linux system and unable to find vnd" "$LINEN=
O" 5
-    fi
-fi
-
-if test "x$host_os" =3D=3D "xlinux-gnu"
-then
     ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uui=
d_uuid_h" "$ac_includes_default"
 if test "x$ac_cv_header_uuid_uuid_h" =3D x""yes; then :
 =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:28:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:28:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0DAl-0003qq-O1; Wed, 22 Feb 2012 14:27:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0DAj-0003ql-UI
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 14:27:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329920871!14446539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8590 invoked from network); 22 Feb 2012 14:27:51 -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;
	22 Feb 2012 14:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10874857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:27:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 14:27:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0DAc-0004s3-Om; Wed, 22 Feb 2012 14:27:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0DAc-0002fu-O2;
	Wed, 22 Feb 2012 14:27:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20292.64358.731316.151273@mariner.uk.xensource.com>
Date: Wed, 22 Feb 2012 14:27:50 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4J2J2bEcd254aJt0Jxs6O7d0YV6PZN8ju9d17tBySD+w@mail.gmail.com>
References: <osstest-12007-mainreport@xen.org>
	<0ab0491f2819fc8440da.1329801792@build.localdomain>
	<20292.55155.47837.914454@mariner.uk.xensource.com>
	<CAPLaKK4gkebUYKKNcvwPbkhHfWZhH4oRFgrOHQ+1P5cPLPfJWA@mail.gmail.com>
	<20292.59538.106293.644879@mariner.uk.xensource.com>
	<CAPLaKK5Qu7+jHqKNB5VdpRM-57H1abNnzfSawLEv_-=pwQA-9w@mail.gmail.com>
	<CAPLaKK4J2J2bEcd254aJt0Jxs6O7d0YV6PZN8ju9d17tBySD+w@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] autoconf: remove brctl 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [PATCH] autoconf: remove brctl check"):
> ...and remember to execute ./autogen.sh on every configure.ac change,
> to update the script.

Oops.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1329920838 0
# Node ID 40785b4790470b5180ded4e89e8c8b7919adb87c
# Parent  d370b93ba7543769702a25d7b9c99e5aa9adac6d
autoconf: Rerun autogen.sh

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r d370b93ba754 -r 40785b479047 tools/configure
--- a/tools/configure	Wed Feb 22 13:06:42 2012 +0000
+++ b/tools/configure	Wed Feb 22 14:27:18 2012 +0000
@@ -611,10 +611,6 @@ glib_CFLAGS
 PKG_CONFIG_LIBDIR
 PKG_CONFIG_PATH
 PKG_CONFIG
-VNCONFIG
-HOTPLUG
-UDEVINFO
-UDEVADM
 PYTHONPATH
 OCAMLBUILD
 OCAMLDOC
@@ -642,7 +638,6 @@ CURL
 FLEX
 BISON
 IP
-BRCTL
 PERL
 PYTHON
 APPEND_LIB
@@ -744,7 +739,6 @@ APPEND_INCLUDES
 APPEND_LIB
 PYTHON
 PERL
-BRCTL
 IP
 BISON
 FLEX
@@ -1400,7 +1394,6 @@ Some influential environment variables:
   APPEND_LIB  List of library folders to append to LDFLAGS (without -L)
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
-  BRCTL       Path to brctl tool
   IP          Path to ip tool
   BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
@@ -3858,8 +3851,6 @@ case $host_os in *\ *) host_os=3D`echo "$h
 =

 =

 =

-
-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autocon=
f -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -4168,7 +4159,6 @@ LDFLAGS=3D"$PREPEND_LDFLAGS $LDFLAGS $APPE
 =

 =

 =

-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not =
truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
@@ -4959,51 +4949,6 @@ if test x"${PERL}" =3D=3D x"no"
 then
     as_fn_error $? "Unable to find perl, please install perl" "$LINENO" 5
 fi
-# Extract the first word of "brctl", so it can be a program name with args.
-set dummy brctl; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_BRCTL+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $BRCTL in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_BRCTL=3D"$BRCTL" # Let the user override the test with a path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_BRCTL=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_BRCTL" && ac_cv_path_BRCTL=3D"no"
-  ;;
-esac
-fi
-BRCTL=3D$ac_cv_path_BRCTL
-if test -n "$BRCTL"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $BRCTL" >&5
-$as_echo "$BRCTL" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-if test x"${BRCTL}" =3D=3D x"no"
-then
-    as_fn_error $? "Unable to find brctl, please install brctl" "$LINENO" 5
-fi
 # Extract the first word of "ip", so it can be a program name with args.
 set dummy ip; ac_word=3D$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
@@ -6440,196 +6385,6 @@ then
 fi
 if test "x$host_os" =3D=3D "xlinux-gnu"
 then
-    # Extract the first word of "udevadm", so it can be a program name wit=
h args.
-set dummy udevadm; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_UDEVADM+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $UDEVADM in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_UDEVADM=3D"$UDEVADM" # Let the user override the test with a =
path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_UDEVADM=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_UDEVADM" && ac_cv_path_UDEVADM=3D"no"
-  ;;
-esac
-fi
-UDEVADM=3D$ac_cv_path_UDEVADM
-if test -n "$UDEVADM"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $UDEVADM" >&5
-$as_echo "$UDEVADM" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-    if test x"${UDEVADM}" =3D=3D x"no"
-    then
-        # Extract the first word of "udevinfo", so it can be a program nam=
e with args.
-set dummy udevinfo; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_UDEVINFO+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $UDEVINFO in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_UDEVINFO=3D"$UDEVINFO" # Let the user override the test with =
a path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_UDEVINFO=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_UDEVINFO" && ac_cv_path_UDEVINFO=3D"no"
-  ;;
-esac
-fi
-UDEVINFO=3D$ac_cv_path_UDEVINFO
-if test -n "$UDEVINFO"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $UDEVINFO" >&5
-$as_echo "$UDEVINFO" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-        if test x"${UDEVINFO}" =3D=3D x"no"
-        then
-            as_fn_error $? "Unable to find udevadm or udevinfo, please ins=
tall udev" "$LINENO" 5
-        fi
-        udevver=3D`${UDEVINFO} -V | awk '{print $NF}'`
-    else
-        udevver=3D`${UDEVADM} info -V | awk '{print $NF}'`
-    fi
-    if test ${udevver} -lt 59
-    then
-        # Extract the first word of "hotplug", so it can be a program name=
 with args.
-set dummy hotplug; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_HOTPLUG+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $HOTPLUG in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_HOTPLUG=3D"$HOTPLUG" # Let the user override the test with a =
path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_HOTPLUG=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_HOTPLUG" && ac_cv_path_HOTPLUG=3D"no"
-  ;;
-esac
-fi
-HOTPLUG=3D$ac_cv_path_HOTPLUG
-if test -n "$HOTPLUG"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $HOTPLUG" >&5
-$as_echo "$HOTPLUG" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-        if test x"${HOTPLUG}" =3D=3D x"no"
-        then
-            as_fn_error $? "udev is too old, upgrade to version 59 or late=
r" "$LINENO" 5
-        fi
-    fi
-else
-    # Extract the first word of "vnconfig", so it can be a program name wi=
th args.
-set dummy vnconfig; ac_word=3D$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_VNCONFIG+set}" =3D set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $VNCONFIG in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_VNCONFIG=3D"$VNCONFIG" # Let the user override the test with =
a path.
-  ;;
-  *)
-  as_save_IFS=3D$IFS; IFS=3D$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=3D$as_save_IFS
-  test -z "$as_dir" && as_dir=3D.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_w=
ord$ac_exec_ext"; }; then
-    ac_cv_path_VNCONFIG=3D"$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_=
ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=3D$as_save_IFS
-
-  test -z "$ac_cv_path_VNCONFIG" && ac_cv_path_VNCONFIG=3D"no"
-  ;;
-esac
-fi
-VNCONFIG=3D$ac_cv_path_VNCONFIG
-if test -n "$VNCONFIG"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $VNCONFIG" >&5
-$as_echo "$VNCONFIG" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-    if test x"${VNCONFIG}" =3D=3D x"no"
-    then
-        as_fn_error $? "Not a Linux system and unable to find vnd" "$LINEN=
O" 5
-    fi
-fi
-
-if test "x$host_os" =3D=3D "xlinux-gnu"
-then
     ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uui=
d_uuid_h" "$ac_includes_default"
 if test "x$ac_cv_header_uuid_uuid_h" =3D x""yes; then :
 =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0DGc-00042d-Me; Wed, 22 Feb 2012 14:34:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0DGa-00042P-WF
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:34:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329921234!7215887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31920 invoked from network); 22 Feb 2012 14:33:54 -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;
	22 Feb 2012 14:33:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:33:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 14:33:54 +0000
Message-ID: <1329921233.8557.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 22 Feb 2012 14:33:53 +0000
In-Reply-To: <20120220145826.GA78217@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
	<20120219093105.GA30637@ocelot.phlegethon.org>
	<1329749035.3990.49.camel@zakaz.uk.xensource.com>
	<20120220145826.GA78217@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 14:58 +0000, Tim Deegan wrote:
> At 14:43 +0000 on 20 Feb (1329749035), Ian Campbell wrote:
> > We do not do any lazy state switching. Outside of context_switch() the current
> > stack is always that of the VCPU which current returns.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Tim Deegan <tim@xen.org>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Thanks, committed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0DGc-00042d-Me; Wed, 22 Feb 2012 14:34:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0DGa-00042P-WF
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:34:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329921234!7215887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31920 invoked from network); 22 Feb 2012 14:33:54 -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;
	22 Feb 2012 14:33:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875063"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:33:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 14:33:54 +0000
Message-ID: <1329921233.8557.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 22 Feb 2012 14:33:53 +0000
In-Reply-To: <20120220145826.GA78217@ocelot.phlegethon.org>
References: <1329324592-12589-1-git-send-email-ian.campbell@citrix.com>
	<20120218135244.GA1531@ocelot.phlegethon.org>
	<1329641061.5898.10.camel@dagon.hellion.org.uk>
	<20120219093105.GA30637@ocelot.phlegethon.org>
	<1329749035.3990.49.camel@zakaz.uk.xensource.com>
	<20120220145826.GA78217@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] arm: use a per-VCPU stack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-20 at 14:58 +0000, Tim Deegan wrote:
> At 14:43 +0000 on 20 Feb (1329749035), Ian Campbell wrote:
> > We do not do any lazy state switching. Outside of context_switch() the current
> > stack is always that of the VCPU which current returns.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Tim Deegan <tim@xen.org>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Thanks, committed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0DGt-00043r-2x; Wed, 22 Feb 2012 14:34:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0DGs-00043I-5T
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:34:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329921251!12770858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32446 invoked from network); 22 Feb 2012 14:34:12 -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;
	22 Feb 2012 14:34:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:34:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 14:34:11 +0000
Message-ID: <1329921250.8557.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 22 Feb 2012 14:34:10 +0000
In-Reply-To: <1329758412.3990.80.camel@zakaz.uk.xensource.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
	<1329498796.3131.135.camel@zakaz.uk.xensource.com>
	<4F3E8CE1.7030803@citrix.com>
	<1329758412.3990.80.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> > 
> > 8<---------
> > arm: move check for CONFIG_DTB_FILE to xen/arch/arm/Makefile
> > 
> > CONFIG_DTB_FILE only needs to be set when building Xen itself.
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> and queued for commit.

Done.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 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 1S0DGt-00043r-2x; Wed, 22 Feb 2012 14:34:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0DGs-00043I-5T
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:34:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1329921251!12770858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32446 invoked from network); 22 Feb 2012 14:34:12 -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;
	22 Feb 2012 14:34:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:34:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 14:34:11 +0000
Message-ID: <1329921250.8557.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 22 Feb 2012 14:34:10 +0000
In-Reply-To: <1329758412.3990.80.camel@zakaz.uk.xensource.com>
References: <1329139131-27554-1-git-send-email-david.vrabel@citrix.com>
	<1329139131-27554-5-git-send-email-david.vrabel@citrix.com>
	<1329498796.3131.135.camel@zakaz.uk.xensource.com>
	<4F3E8CE1.7030803@citrix.com>
	<1329758412.3990.80.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/8] arm: link a device tree blob into the
 xen image
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> > 
> > 8<---------
> > arm: move check for CONFIG_DTB_FILE to xen/arch/arm/Makefile
> > 
> > CONFIG_DTB_FILE only needs to be set when building Xen itself.
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> and queued for commit.

Done.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:35:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0DHY-00048e-Tm; Wed, 22 Feb 2012 14:35: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 1S0DHW-00048F-QR
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:34:58 +0000
Received: from [85.158.139.83:24589] by server-10.bemta-5.messagelabs.com id
	E7/2D-07861-11DF44F4; Wed, 22 Feb 2012 14:34:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329921297!16100626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21123 invoked from network); 22 Feb 2012 14:34:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:34:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:34:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 14:34:57 +0000
Message-ID: <1329921295.8557.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 22 Feb 2012 14:34:55 +0000
In-Reply-To: <alpine.DEB.2.00.1202221423280.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1202221423280.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Wed, 2012-02-22 at 14:23 +0000, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Ian Campbell wrote:
> > This is necessary to handle nested traps to the hypervisor more than one deep.
> > 
> > I've not seen an actually failure relating to this but I'm not quite sure how
> > we've managed to get away with not doing it (I suppose multiply nested traps
> > are uncommon).
> 
> ack

Thanks, I have committed both patches from this thread:
        arm: restore ELR_hyp and SPSR_hyp on return from hypervisor to hypervisor.
        arm: lr register in hyp mode is really LR_usr.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:35:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0DHY-00048e-Tm; Wed, 22 Feb 2012 14:35: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 1S0DHW-00048F-QR
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:34:58 +0000
Received: from [85.158.139.83:24589] by server-10.bemta-5.messagelabs.com id
	E7/2D-07861-11DF44F4; Wed, 22 Feb 2012 14:34:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329921297!16100626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21123 invoked from network); 22 Feb 2012 14:34:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:34:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 14:34:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 14:34:57 +0000
Message-ID: <1329921295.8557.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 22 Feb 2012 14:34:55 +0000
In-Reply-To: <alpine.DEB.2.00.1202221423280.23091@kaball-desktop>
References: <1329751321-32047-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1202221423280.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: restore ELR_hyp and SPSR_hyp on return
 from hypervisor 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 Wed, 2012-02-22 at 14:23 +0000, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Ian Campbell wrote:
> > This is necessary to handle nested traps to the hypervisor more than one deep.
> > 
> > I've not seen an actually failure relating to this but I'm not quite sure how
> > we've managed to get away with not doing it (I suppose multiply nested traps
> > are uncommon).
> 
> ack

Thanks, I have committed both patches from this thread:
        arm: restore ELR_hyp and SPSR_hyp on return from hypervisor to hypervisor.
        arm: lr register in hyp mode is really LR_usr.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:35:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0DID-0004EX-E0; Wed, 22 Feb 2012 14:35:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0DIC-0004Dc-2k
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:35:40 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329921332!9140359!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTYwNTI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17235 invoked from network); 22 Feb 2012 14:35:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2012 14:35:33 -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 q1MEZS6B014308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 14:35:29 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
	q1MEZRYu020691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 14:35:27 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
	q1MEZRqh021517; Wed, 22 Feb 2012 08:35:27 -0600
Received: from [221.218.36.201] (/221.218.36.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 06:35:26 -0800
Message-ID: <4F44FD1B.5090000@oracle.com>
Date: Wed, 22 Feb 2012 22:35:07 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F41F41F.9060601@oracle.com>	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	<4F430201.3040208@oracle.com>	<1329908701.2880.26.camel@zakaz.uk.xensource.com>	<4F44E94A.2060209@oracle.com>
	<1329919132.8557.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329919132.8557.2.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F44FD31.006E,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-2-22 21:58, Ian Campbell wrote:
>
> Yes, this looks plausible to me (although I'm no expert on this code).
> Something similar happens in rtc_next_second. 
>
> Perhaps it would be better to add a function or macro to do the
> conversion, such that it is somewhat self documenting? Or at least make
> the 1900 a #define with a suitable name.
>   
Sure.
How about
#define epoch_year   1900
#define get_year(x)    (x + epoch_year)
?

Thanks,
Annie
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:35:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0DID-0004EX-E0; Wed, 22 Feb 2012 14:35:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0DIC-0004Dc-2k
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:35:40 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329921332!9140359!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTYwNTI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17235 invoked from network); 22 Feb 2012 14:35:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2012 14:35:33 -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 q1MEZS6B014308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 14:35:29 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
	q1MEZRYu020691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 14:35:27 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
	q1MEZRqh021517; Wed, 22 Feb 2012 08:35:27 -0600
Received: from [221.218.36.201] (/221.218.36.201)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 06:35:26 -0800
Message-ID: <4F44FD1B.5090000@oracle.com>
Date: Wed, 22 Feb 2012 22:35:07 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F41F41F.9060601@oracle.com>	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	<4F430201.3040208@oracle.com>	<1329908701.2880.26.camel@zakaz.uk.xensource.com>	<4F44E94A.2060209@oracle.com>
	<1329919132.8557.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329919132.8557.2.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F44FD31.006E,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-2-22 21:58, Ian Campbell wrote:
>
> Yes, this looks plausible to me (although I'm no expert on this code).
> Something similar happens in rtc_next_second. 
>
> Perhaps it would be better to add a function or macro to do the
> conversion, such that it is somewhat self documenting? Or at least make
> the 1900 a #define with a suitable name.
>   
Sure.
How about
#define epoch_year   1900
#define get_year(x)    (x + epoch_year)
?

Thanks,
Annie
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0Dcb-0004wc-PS; Wed, 22 Feb 2012 14:56:45 +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 1S0Dcb-0004wX-1U
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:56:45 +0000
Received: from [85.158.139.83:16155] by server-1.bemta-5.messagelabs.com id
	45/58-28458-C22054F4; Wed, 22 Feb 2012 14:56:44 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329922602!12298294!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24673 invoked from network); 22 Feb 2012 14:56:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:56:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182956542"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 09:56:41 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 09:56:41 -0500
Received: from [10.80.3.61] (helo=dhcp-3-61.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1S0DcX-0004Ic-2X;
	Wed, 22 Feb 2012 14:56:41 +0000
Date: Wed, 22 Feb 2012 14:56:40 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <CAJJyHj+8M_3ZmS0un8y6d=abijXE6Y0u56m4qWubu5BdBKMo4A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202221445530.22850@perard.uk.xensource.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
	<CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
	<4F42A601.7000701@vido.info>
	<CAJJyHj+8M_3ZmS0un8y6d=abijXE6Y0u56m4qWubu5BdBKMo4A@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 20 Feb 2012, Anthony PERARD wrote:

> On Mon, Feb 20, 2012 at 19:58, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > [00:06.0] pt_pci_read_config: address=0x0030 val=0x00000000 len=4
> > [00:06.0] pt_pci_write_config: address=0x0030 val=0xffffffff len=4
> > [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=1
> > [00:06.0] pt_pci_read_config: address=0x0030 val=0xfffe0001 len=4
> > [00:06.0] pt_pci_write_config: address=0x0030 val=0x00000000 len=4
> > [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=0
> ...
> > [00:06.0] pt_pci_read_config: address=0x0004 val=0x00000000 len=2
> > [00:06.0] pt_pci_write_config: address=0x0004 val=0x00000004 len=2
> > qemu-system-x86_64: /usr/src/xen-with-upstream-qemu-patch/upstream-qemu/qemu/memory.c:1378: memory_region_del_subregion: Assertion `subregion->parent == mr' failed.
>
> This last line is why QEMU fail and I thinks it's because I never try
> a PCI device with a ROM pci bar. I'll try to fix this tomorrow.

Could you tell me if this "patch" resolve the issue?

diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index f1fffd1..37aa383 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -555,18 +555,16 @@ static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
     XenPTReg *reg_entry = NULL;
     XenPTRegion *base = NULL;
     PCIDevice *d = (PCIDevice *)&s->dev;
-    PCIIORegion *r;
     uint32_t writable_mask = 0;
     uint32_t throughable_mask = 0;
     pcibus_t r_size = 0;
     uint32_t bar_emu_mask = 0;
     uint32_t bar_ro_mask = 0;

-    r = &d->io_regions[PCI_ROM_SLOT];
-    r_size = r->size;
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
     base = &s->bases[PCI_ROM_SLOT];
     /* align memory type resource size */
-    pt_get_emul_size(base->bar_flag, r_size);
+    r_size = pt_get_emul_size(base->bar_flag, r_size);

     /* set emulate mask and read-only mask */
     bar_emu_mask = reg->emu_mask;
@@ -576,19 +574,6 @@ static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
     writable_mask = ~bar_ro_mask & valid_mask;
     cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);

-    /* update the corresponding virtual region address */
-    /*
-     * When guest code tries to get block size of mmio, it will write all "1"s
-     * into pci bar register. In this case, cfg_entry->data == writable_mask.
-     * Especially for devices with large mmio, the value of writable_mask
-     * is likely to be a guest physical address that has been mapped to ram
-     * rather than mmio. Remapping this value to mmio should be prevented.
-     */
-
-    if (cfg_entry->data != writable_mask) {
-        r->addr = cfg_entry->data;
-    }
-
     /* create value for writing to I/O device register */
     throughable_mask = ~bar_emu_mask & valid_mask;
     *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);

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 Feb 22 14:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14: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 1S0Dcb-0004wc-PS; Wed, 22 Feb 2012 14:56:45 +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 1S0Dcb-0004wX-1U
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:56:45 +0000
Received: from [85.158.139.83:16155] by server-1.bemta-5.messagelabs.com id
	45/58-28458-C22054F4; Wed, 22 Feb 2012 14:56:44 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329922602!12298294!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24673 invoked from network); 22 Feb 2012 14:56:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 14:56:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182956542"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 09:56:41 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 09:56:41 -0500
Received: from [10.80.3.61] (helo=dhcp-3-61.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<anthony.perard@citrix.com>)	id 1S0DcX-0004Ic-2X;
	Wed, 22 Feb 2012 14:56:41 +0000
Date: Wed, 22 Feb 2012 14:56:40 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Tobias Geiger <tobias.geiger@vido.info>
In-Reply-To: <CAJJyHj+8M_3ZmS0un8y6d=abijXE6Y0u56m4qWubu5BdBKMo4A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202221445530.22850@perard.uk.xensource.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<201202201151.12291.tobias.geiger@vido.info>
	<CAJJyHj+DmDzApF6LDaJYDPyJSHwwMM=yo7g7ks+44t+CjASMnA@mail.gmail.com>
	<201202201711.11807.tobias.geiger@vido.info>
	<CAJJyHj+5NJsHRESxn=socWA_bum3O19trhYUZE9+qdAji8hxwg@mail.gmail.com>
	<4F42A601.7000701@vido.info>
	<CAJJyHj+8M_3ZmS0un8y6d=abijXE6Y0u56m4qWubu5BdBKMo4A@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel]  [PATCH V7 00/11] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 20 Feb 2012, Anthony PERARD wrote:

> On Mon, Feb 20, 2012 at 19:58, Tobias Geiger <tobias.geiger@vido.info> wrote:
> > [00:06.0] pt_pci_read_config: address=0x0030 val=0x00000000 len=4
> > [00:06.0] pt_pci_write_config: address=0x0030 val=0xffffffff len=4
> > [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=1
> > [00:06.0] pt_pci_read_config: address=0x0030 val=0xfffe0001 len=4
> > [00:06.0] pt_pci_write_config: address=0x0030 val=0x00000000 len=4
> > [00:06.0] pt_iomem_map: BAR 6, e_phys=0xffffffffffffffff maddr=0xc3140000 len=0x20000 first_map=0
> ...
> > [00:06.0] pt_pci_read_config: address=0x0004 val=0x00000000 len=2
> > [00:06.0] pt_pci_write_config: address=0x0004 val=0x00000004 len=2
> > qemu-system-x86_64: /usr/src/xen-with-upstream-qemu-patch/upstream-qemu/qemu/memory.c:1378: memory_region_del_subregion: Assertion `subregion->parent == mr' failed.
>
> This last line is why QEMU fail and I thinks it's because I never try
> a PCI device with a ROM pci bar. I'll try to fix this tomorrow.

Could you tell me if this "patch" resolve the issue?

diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index f1fffd1..37aa383 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -555,18 +555,16 @@ static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
     XenPTReg *reg_entry = NULL;
     XenPTRegion *base = NULL;
     PCIDevice *d = (PCIDevice *)&s->dev;
-    PCIIORegion *r;
     uint32_t writable_mask = 0;
     uint32_t throughable_mask = 0;
     pcibus_t r_size = 0;
     uint32_t bar_emu_mask = 0;
     uint32_t bar_ro_mask = 0;

-    r = &d->io_regions[PCI_ROM_SLOT];
-    r_size = r->size;
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
     base = &s->bases[PCI_ROM_SLOT];
     /* align memory type resource size */
-    pt_get_emul_size(base->bar_flag, r_size);
+    r_size = pt_get_emul_size(base->bar_flag, r_size);

     /* set emulate mask and read-only mask */
     bar_emu_mask = reg->emu_mask;
@@ -576,19 +574,6 @@ static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
     writable_mask = ~bar_ro_mask & valid_mask;
     cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);

-    /* update the corresponding virtual region address */
-    /*
-     * When guest code tries to get block size of mmio, it will write all "1"s
-     * into pci bar register. In this case, cfg_entry->data == writable_mask.
-     * Especially for devices with large mmio, the value of writable_mask
-     * is likely to be a guest physical address that has been mapped to ram
-     * rather than mmio. Remapping this value to mmio should be prevented.
-     */
-
-    if (cfg_entry->data != writable_mask) {
-        r->addr = cfg_entry->data;
-    }
-
     /* create value for writing to I/O device register */
     throughable_mask = ~bar_emu_mask & valid_mask;
     *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);

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 Feb 22 14:59:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0DfC-00054d-GU; Wed, 22 Feb 2012 14:59:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0DfB-00054N-8I
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:59:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329922752!7220720!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9258 invoked from network); 22 Feb 2012 14:59:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Feb 2012 14:59:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Dex-0002Ph-A7
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 06:59:11 -0800
Date: Wed, 22 Feb 2012 06:59:11 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329922751305-5505329.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] tools/examples: Move readmes and examples to
 subdirectory 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

tools/examples: Move readmes and examples to subdirectory docs

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index 8cea724..be71872 100644
--- a/tools/examples/Makefile
+++ b/tools/examples/Makefile
@@ -7,20 +7,20 @@ XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
 
 # Xen configuration dir and configs to go there.
-XEN_READMES = README
-XEN_READMES += README.incompatibilities
+XEN_DOCS = README
+XEN_DOCS += README.incompatibilities
 XEN_CONFIGS = xend-config.sxp
 XEN_CONFIGS += xm-config.xml
-XEN_CONFIGS += xmexample1 
-XEN_CONFIGS += xmexample2
-XEN_CONFIGS += xmexample3
-XEN_CONFIGS += xmexample.hvm
-XEN_CONFIGS += xmexample.hvm-stubdom
-XEN_CONFIGS += xmexample.pv-grub
-XEN_CONFIGS += xmexample.nbd
-XEN_CONFIGS += xmexample.vti
-XEN_CONFIGS += xlexample.hvm
-XEN_CONFIGS += xlexample.pvlinux
+XEN_DOCS += xmexample1 
+XEN_DOCS += xmexample2
+XEN_DOCS += xmexample3
+XEN_DOCS += xmexample.hvm
+XEN_DOCS += xmexample.hvm-stubdom
+XEN_DOCS += xmexample.pv-grub
+XEN_DOCS += xmexample.nbd
+XEN_DOCS += xmexample.vti
+XEN_DOCS += xlexample.hvm
+XEN_DOCS += xlexample.pvlinux
 XEN_CONFIGS += xend-pci-quirks.sxp
 XEN_CONFIGS += xend-pci-permissive.sxp
 XEN_CONFIGS += xl.conf
@@ -33,15 +33,17 @@ all:
 build:
 
 .PHONY: install
-install: all install-readmes install-configs $(HOTPLUGS)
+install: all install-docs install-configs $(HOTPLUGS)
 
-.PHONY: install-readmes
-install-readmes:
+.PHONY: install-docs
+install-docs:
 	[ -d $(DESTDIR)$(XEN_CONFIG_DIR) ] || \
 		$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
-	set -e; for i in $(XEN_READMES); \
-	    do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/$$i ] || \
-	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR); \
+	[ -d $(DESTDIR)$(XEN_CONFIG_DIR)/docs ] || \
+		$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)/docs
+	set -e; for i in $(XEN_DOCS); \
+	    do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/docs/$$i ] || \
+	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR)/docs/; \
 	done
 
 .PHONY: install-configs

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-examples-Move-readmes-and-examples-to-subdirectory-docs-tp5505329p5505329.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 14:59:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 14:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0DfC-00054d-GU; Wed, 22 Feb 2012 14:59:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0DfB-00054N-8I
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 14:59:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1329922752!7220720!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9258 invoked from network); 22 Feb 2012 14:59:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Feb 2012 14:59:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Dex-0002Ph-A7
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 06:59:11 -0800
Date: Wed, 22 Feb 2012 06:59:11 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329922751305-5505329.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] tools/examples: Move readmes and examples to
 subdirectory 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

tools/examples: Move readmes and examples to subdirectory docs

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index 8cea724..be71872 100644
--- a/tools/examples/Makefile
+++ b/tools/examples/Makefile
@@ -7,20 +7,20 @@ XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
 
 # Xen configuration dir and configs to go there.
-XEN_READMES = README
-XEN_READMES += README.incompatibilities
+XEN_DOCS = README
+XEN_DOCS += README.incompatibilities
 XEN_CONFIGS = xend-config.sxp
 XEN_CONFIGS += xm-config.xml
-XEN_CONFIGS += xmexample1 
-XEN_CONFIGS += xmexample2
-XEN_CONFIGS += xmexample3
-XEN_CONFIGS += xmexample.hvm
-XEN_CONFIGS += xmexample.hvm-stubdom
-XEN_CONFIGS += xmexample.pv-grub
-XEN_CONFIGS += xmexample.nbd
-XEN_CONFIGS += xmexample.vti
-XEN_CONFIGS += xlexample.hvm
-XEN_CONFIGS += xlexample.pvlinux
+XEN_DOCS += xmexample1 
+XEN_DOCS += xmexample2
+XEN_DOCS += xmexample3
+XEN_DOCS += xmexample.hvm
+XEN_DOCS += xmexample.hvm-stubdom
+XEN_DOCS += xmexample.pv-grub
+XEN_DOCS += xmexample.nbd
+XEN_DOCS += xmexample.vti
+XEN_DOCS += xlexample.hvm
+XEN_DOCS += xlexample.pvlinux
 XEN_CONFIGS += xend-pci-quirks.sxp
 XEN_CONFIGS += xend-pci-permissive.sxp
 XEN_CONFIGS += xl.conf
@@ -33,15 +33,17 @@ all:
 build:
 
 .PHONY: install
-install: all install-readmes install-configs $(HOTPLUGS)
+install: all install-docs install-configs $(HOTPLUGS)
 
-.PHONY: install-readmes
-install-readmes:
+.PHONY: install-docs
+install-docs:
 	[ -d $(DESTDIR)$(XEN_CONFIG_DIR) ] || \
 		$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
-	set -e; for i in $(XEN_READMES); \
-	    do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/$$i ] || \
-	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR); \
+	[ -d $(DESTDIR)$(XEN_CONFIG_DIR)/docs ] || \
+		$(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)/docs
+	set -e; for i in $(XEN_DOCS); \
+	    do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/docs/$$i ] || \
+	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR)/docs/; \
 	done
 
 .PHONY: install-configs

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-examples-Move-readmes-and-examples-to-subdirectory-docs-tp5505329p5505329.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 15:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 15:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Dgn-0005DE-Vm; Wed, 22 Feb 2012 15:01:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S0Dgm-0005D8-IA
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 15:01:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329922839!64586007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6251 invoked from network); 22 Feb 2012 15:00:40 -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;
	22 Feb 2012 15:00:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 15:00:51 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 15:00:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 22 Feb 2012 15:00:12 +0000
Message-ID: <1329922812.5468.55.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH] Add gtags target for xen/Makefile. Also update
	.hgignore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1329922671 0
# Node ID bb2986677df84b9709a60aea7e70ffd9f9e23f76
# Parent  d433a9cb0089683b8f75458807c5437341f2cdcc
Add gtags target for xen/Makefile. Also update .hgignore.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -23,6 +23,7 @@
 ^\.config$
 ^\.pc
 (^|/)(tags|TAGS)$
+(^|/)(GTAGS|GPATH|GSYMS|GRTAGS|gtags.*)$
 ^build-.*$
 ^dist/.*$
 ^docs/.*\.aux$
diff --git a/xen/Makefile b/xen/Makefile
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,8 +20,8 @@ default: build
 .PHONY: dist
 dist: install
 
-.PHONY: build install clean distclean cscope TAGS tags MAP
-build install debug clean distclean cscope TAGS tags MAP::
+.PHONY: build install clean distclean cscope TAGS tags MAP gtags
+build install debug clean distclean cscope TAGS tags MAP gtags::
 	$(MAKE) -f Rules.mk _$@
 
 .PHONY: _build
@@ -67,7 +67,7 @@ _clean: delete-unfresh-files
 
 .PHONY: _distclean
 _distclean: clean
-	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
+	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out gtags.files GTAGS GPATH GRTAGS GSYMS
 
 $(TARGET).gz: $(TARGET)
 	gzip -f -9 < $< > $@.new
@@ -159,6 +159,12 @@ _tags:
 	$(call set_exuberant_flags,ctags); \
 	$(all_sources) | xargs ctags $$exuberant_flags -a
 
+.PHONY: _gtags
+_gtags:
+	set -e; rm -f GTAGS GSYMS GPATH GRTAGS
+	$(all_sources) > gtags.files
+	gtags -f gtags.files
+
 .PHONY: _cscope
 _cscope:
 	$(all_sources) > cscope.files



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 15:01:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 15:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Dgn-0005DE-Vm; Wed, 22 Feb 2012 15:01:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S0Dgm-0005D8-IA
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 15:01:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1329922839!64586007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6251 invoked from network); 22 Feb 2012 15:00:40 -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;
	22 Feb 2012 15:00:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="10875794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 15:00:51 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 15:00:51 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 22 Feb 2012 15:00:12 +0000
Message-ID: <1329922812.5468.55.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH] Add gtags target for xen/Makefile. Also update
	.hgignore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1329922671 0
# Node ID bb2986677df84b9709a60aea7e70ffd9f9e23f76
# Parent  d433a9cb0089683b8f75458807c5437341f2cdcc
Add gtags target for xen/Makefile. Also update .hgignore.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -23,6 +23,7 @@
 ^\.config$
 ^\.pc
 (^|/)(tags|TAGS)$
+(^|/)(GTAGS|GPATH|GSYMS|GRTAGS|gtags.*)$
 ^build-.*$
 ^dist/.*$
 ^docs/.*\.aux$
diff --git a/xen/Makefile b/xen/Makefile
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,8 +20,8 @@ default: build
 .PHONY: dist
 dist: install
 
-.PHONY: build install clean distclean cscope TAGS tags MAP
-build install debug clean distclean cscope TAGS tags MAP::
+.PHONY: build install clean distclean cscope TAGS tags MAP gtags
+build install debug clean distclean cscope TAGS tags MAP gtags::
 	$(MAKE) -f Rules.mk _$@
 
 .PHONY: _build
@@ -67,7 +67,7 @@ _clean: delete-unfresh-files
 
 .PHONY: _distclean
 _distclean: clean
-	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
+	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out gtags.files GTAGS GPATH GRTAGS GSYMS
 
 $(TARGET).gz: $(TARGET)
 	gzip -f -9 < $< > $@.new
@@ -159,6 +159,12 @@ _tags:
 	$(call set_exuberant_flags,ctags); \
 	$(all_sources) | xargs ctags $$exuberant_flags -a
 
+.PHONY: _gtags
+_gtags:
+	set -e; rm -f GTAGS GSYMS GPATH GRTAGS
+	$(all_sources) > gtags.files
+	gtags -f gtags.files
+
 .PHONY: _cscope
 _cscope:
 	$(all_sources) > cscope.files



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 15:28:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 15:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0E7D-0005iZ-CZ; Wed, 22 Feb 2012 15:28:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0E7B-0005iU-GL
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 15:28:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329924494!14457560!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5587 invoked from network); 22 Feb 2012 15:28:15 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Feb 2012 15:28:15 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0E73-0007iB-Nj
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 07:28:13 -0800
Date: Wed, 22 Feb 2012 07:28:13 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329924493728-5505409.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xen-unstable: Qemu upstream domUs not start on Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
build:
http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
And also this change for lib patch modified with multiarch support:
vi config/StdGNU.mk
LIBLEAFDIR_x86_64 ?= lib

DomUs PV working, domUs with qemu-upstream not start.

The xl configuration file:
---------------------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
'/dev/sr0,raw,hdb,ro,cdrom']
boot='c'
xen_platform_pci=1
device_model_version='qemu-xen'
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#stdvga=1
#videoram=16
sdl=0
#spice=1
#spicehost='192.168.1.137'
#spiceport=6000
#spicepasswd='test'
#on_crash='preserve'
---------------------------------

xl create /etc/xen/PRECISEHVM.cfg
Parsing config file /etc/xen/PRECISEHVM.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
such file or directory
libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
during startup
libxl: error: libxl_create.c:602:do_domain_create: device model did not
start: -1

The same with change only device_model_version to qemu-xen-traditional work


If you need more test and data ask me and I will do and post.
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5505409.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 15:28:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 15:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0E7D-0005iZ-CZ; Wed, 22 Feb 2012 15:28:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0E7B-0005iU-GL
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 15:28:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1329924494!14457560!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5587 invoked from network); 22 Feb 2012 15:28:15 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	22 Feb 2012 15:28:15 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0E73-0007iB-Nj
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 07:28:13 -0800
Date: Wed, 22 Feb 2012 07:28:13 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329924493728-5505409.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] xen-unstable: Qemu upstream domUs not start on Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
build:
http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
And also this change for lib patch modified with multiarch support:
vi config/StdGNU.mk
LIBLEAFDIR_x86_64 ?= lib

DomUs PV working, domUs with qemu-upstream not start.

The xl configuration file:
---------------------------------
name='PRECISEHVM'
builder="hvm"
memory=1024
vcpus=2
hap=1
pae=1
acpi=1
apic=1
nx=1
vif=['bridge=xenbr0']
#vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
'/dev/sr0,raw,hdb,ro,cdrom']
boot='c'
xen_platform_pci=1
device_model_version='qemu-xen'
vnc=1
vncunused=1
vnclisten="0.0.0.0"
keymap="it"
#stdvga=1
#videoram=16
sdl=0
#spice=1
#spicehost='192.168.1.137'
#spiceport=6000
#spicepasswd='test'
#on_crash='preserve'
---------------------------------

xl create /etc/xen/PRECISEHVM.cfg
Parsing config file /etc/xen/PRECISEHVM.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000019dc88
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
such file or directory
libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
during startup
libxl: error: libxl_create.c:602:do_domain_create: device model did not
start: -1

The same with change only device_model_version to qemu-xen-traditional work


If you need more test and data ask me and I will do and post.
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5505409.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 15:38:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 15:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0EGw-0005sc-Er; Wed, 22 Feb 2012 15:38:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1S0EGv-0005sX-Km
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 15:38:25 +0000
Received: from [85.158.139.83:28454] by server-7.bemta-5.messagelabs.com id
	8E/4F-16195-0FB054F4; Wed, 22 Feb 2012 15:38:24 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329925102!16171752!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16648 invoked from network); 22 Feb 2012 15:38:24 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 15:38:24 -0000
Received: by damc16 with SMTP id c16so638009dam.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 07:38:21 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.68.219.98 as permitted sender) client-ip=10.68.219.98; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.68.219.98 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.68.219.98])
	by 10.68.219.98 with SMTP id pn2mr2701516pbc.161.1329925101980
	(num_hops = 1); Wed, 22 Feb 2012 07:38:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=OBbkobZbkWrErhN9xtrnND1SkSJc0h1T/7RL119p+eI=;
	b=iHa1jHGvA9ydaayEOuspoAxgeo9kP8KvQEKYhSqOqC4NrAUzTQVXYkViknsotcA1JP
	cx1VDjqP3IiCX0XhvD168KRLGgqd+8Q4Av5uNzBB32n4WVOOCGDlbu93GfATkwn3RtA4
	DSg4CK2LBIL7MEAhG9j7kD/ZzjgoZxk5LaZdo=
MIME-Version: 1.0
Received: by 10.68.219.98 with SMTP id pn2mr2248148pbc.161.1329925101918; Wed,
	22 Feb 2012 07:38:21 -0800 (PST)
Received: by 10.142.106.6 with HTTP; Wed, 22 Feb 2012 07:38:21 -0800 (PST)
Date: Wed, 22 Feb 2012 08:38:21 -0700
Message-ID: <CAHyyzzSFmXEgdtacKQKbifsKXsNe88A3eu7gPb-+dY3rtAyHVw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] esxi vmware style cdrom
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7297281775760310965=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7297281775760310965==
Content-Type: multipart/alternative; boundary=047d7b2ed24347183704b98f51f8

--047d7b2ed24347183704b98f51f8
Content-Type: text/plain; charset=ISO-8859-1

I wonder if anyone is planning on creating vmware style dvd  drive direct
virtual drivers.  It seems that esxi let you assign direct control of
assigned drive. With esxi I could assign my blurey drive and backup movies
using makemkv. I had tried to use phy: and makemkv in domu would state that
it could not find cdrom. When I assigned blurey to server 2008 but xen does
not allow full control of blurey I got couple of scsi errors.

--047d7b2ed24347183704b98f51f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wonder if anyone is planning on creating vmware style dvd=A0 drive direct=
 virtual drivers.=A0 It seems that esxi let you assign direct control of as=
signed drive. With esxi I could assign my blurey drive and backup movies us=
ing makemkv. I had tried to use phy: and makemkv in domu would state that i=
t could not find cdrom. When I assigned blurey to server 2008 but xen does =
not allow full control of blurey I got couple of scsi errors.=20

--047d7b2ed24347183704b98f51f8--


--===============7297281775760310965==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7297281775760310965==--


From xen-devel-bounces@lists.xen.org Wed Feb 22 15:38:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 15:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0EGw-0005sc-Er; Wed, 22 Feb 2012 15:38:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1S0EGv-0005sX-Km
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 15:38:25 +0000
Received: from [85.158.139.83:28454] by server-7.bemta-5.messagelabs.com id
	8E/4F-16195-0FB054F4; Wed, 22 Feb 2012 15:38:24 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329925102!16171752!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16648 invoked from network); 22 Feb 2012 15:38:24 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 15:38:24 -0000
Received: by damc16 with SMTP id c16so638009dam.30
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 07:38:21 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.68.219.98 as permitted sender) client-ip=10.68.219.98; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.68.219.98 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.68.219.98])
	by 10.68.219.98 with SMTP id pn2mr2701516pbc.161.1329925101980
	(num_hops = 1); Wed, 22 Feb 2012 07:38:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=OBbkobZbkWrErhN9xtrnND1SkSJc0h1T/7RL119p+eI=;
	b=iHa1jHGvA9ydaayEOuspoAxgeo9kP8KvQEKYhSqOqC4NrAUzTQVXYkViknsotcA1JP
	cx1VDjqP3IiCX0XhvD168KRLGgqd+8Q4Av5uNzBB32n4WVOOCGDlbu93GfATkwn3RtA4
	DSg4CK2LBIL7MEAhG9j7kD/ZzjgoZxk5LaZdo=
MIME-Version: 1.0
Received: by 10.68.219.98 with SMTP id pn2mr2248148pbc.161.1329925101918; Wed,
	22 Feb 2012 07:38:21 -0800 (PST)
Received: by 10.142.106.6 with HTTP; Wed, 22 Feb 2012 07:38:21 -0800 (PST)
Date: Wed, 22 Feb 2012 08:38:21 -0700
Message-ID: <CAHyyzzSFmXEgdtacKQKbifsKXsNe88A3eu7gPb-+dY3rtAyHVw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] esxi vmware style cdrom
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7297281775760310965=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7297281775760310965==
Content-Type: multipart/alternative; boundary=047d7b2ed24347183704b98f51f8

--047d7b2ed24347183704b98f51f8
Content-Type: text/plain; charset=ISO-8859-1

I wonder if anyone is planning on creating vmware style dvd  drive direct
virtual drivers.  It seems that esxi let you assign direct control of
assigned drive. With esxi I could assign my blurey drive and backup movies
using makemkv. I had tried to use phy: and makemkv in domu would state that
it could not find cdrom. When I assigned blurey to server 2008 but xen does
not allow full control of blurey I got couple of scsi errors.

--047d7b2ed24347183704b98f51f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wonder if anyone is planning on creating vmware style dvd=A0 drive direct=
 virtual drivers.=A0 It seems that esxi let you assign direct control of as=
signed drive. With esxi I could assign my blurey drive and backup movies us=
ing makemkv. I had tried to use phy: and makemkv in domu would state that i=
t could not find cdrom. When I assigned blurey to server 2008 but xen does =
not allow full control of blurey I got couple of scsi errors.=20

--047d7b2ed24347183704b98f51f8--


--===============7297281775760310965==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7297281775760310965==--


From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0EsM-0006nx-Gq; Wed, 22 Feb 2012 16:17:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0EsL-0006nO-6a
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:05 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329927415!9327088!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30835 invoked from network); 22 Feb 2012 16:16:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="22344737"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-1W;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 5600db2bcd0ebac0c02e0e5d03e81f5d73819106
Message-ID: <5600db2bcd0ebac0c02e.1329927314@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:14 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 8 of 9] xl: Refactor sched_domain_output to have
 a callback for pool information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a scheduler to provide a callback to display pool-wide information,
providing a default.  This is in preparation for displaying pool-wide
scheduler parameters on this line.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r acbe35e4fb4a -r 5600db2bcd0e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -4059,13 +4059,23 @@ static int sched_sedf_domain_output(
     return 0;
 }
 
-static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+static int sched_default_pool_output(uint32_t poolid)
+{
+    char *poolname;
+
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    printf("Cpupool %s:\n",
+           poolname);
+    free(poolname);
+    return 0;
+}
+
+static int sched_domain_output(uint32_t sched, int (*output)(int),
+                               int (*pooloutput)(uint32_t), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
     uint32_t poolid;
-    char *poolname;
     int nb_domain, n_pools = 0, i, p;
     int rc = 0;
 
@@ -4093,9 +4103,7 @@ static int sched_domain_output(
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
-        poolname = libxl_cpupoolid_to_name(ctx, poolinfo[p].poolid);
-        printf("Cpupool %s:\n", poolname);
-        free(poolname);
+        pooloutput(poolinfo[p].poolid);
 
         output(-1);
         for (i = 0; i < nb_domain; i++) {
@@ -4171,7 +4179,9 @@ int main_sched_credit(int argc, char **a
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
-                                    sched_credit_domain_output, cpupool);
+                                    sched_credit_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4247,7 +4257,9 @@ int main_sched_credit2(int argc, char **
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
-                                    sched_credit2_domain_output, cpupool);
+                                    sched_credit2_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4349,7 +4361,9 @@ int main_sched_sedf(int argc, char **arg
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_SEDF,
-                                    sched_sedf_domain_output, cpupool);
+                                    sched_sedf_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0EsM-0006nx-Gq; Wed, 22 Feb 2012 16:17:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0EsL-0006nO-6a
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:05 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329927415!9327088!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30835 invoked from network); 22 Feb 2012 16:16:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="22344737"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-1W;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 5600db2bcd0ebac0c02e0e5d03e81f5d73819106
Message-ID: <5600db2bcd0ebac0c02e.1329927314@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:14 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 8 of 9] xl: Refactor sched_domain_output to have
 a callback for pool information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a scheduler to provide a callback to display pool-wide information,
providing a default.  This is in preparation for displaying pool-wide
scheduler parameters on this line.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r acbe35e4fb4a -r 5600db2bcd0e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -4059,13 +4059,23 @@ static int sched_sedf_domain_output(
     return 0;
 }
 
-static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+static int sched_default_pool_output(uint32_t poolid)
+{
+    char *poolname;
+
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    printf("Cpupool %s:\n",
+           poolname);
+    free(poolname);
+    return 0;
+}
+
+static int sched_domain_output(uint32_t sched, int (*output)(int),
+                               int (*pooloutput)(uint32_t), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
     uint32_t poolid;
-    char *poolname;
     int nb_domain, n_pools = 0, i, p;
     int rc = 0;
 
@@ -4093,9 +4103,7 @@ static int sched_domain_output(
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
-        poolname = libxl_cpupoolid_to_name(ctx, poolinfo[p].poolid);
-        printf("Cpupool %s:\n", poolname);
-        free(poolname);
+        pooloutput(poolinfo[p].poolid);
 
         output(-1);
         for (i = 0; i < nb_domain; i++) {
@@ -4171,7 +4179,9 @@ int main_sched_credit(int argc, char **a
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
-                                    sched_credit_domain_output, cpupool);
+                                    sched_credit_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4247,7 +4257,9 @@ int main_sched_credit2(int argc, char **
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
-                                    sched_credit2_domain_output, cpupool);
+                                    sched_credit2_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 
@@ -4349,7 +4361,9 @@ int main_sched_sedf(int argc, char **arg
 
     if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_SEDF,
-                                    sched_sedf_domain_output, cpupool);
+                                    sched_sedf_domain_output,
+                                    sched_default_pool_output,
+                                    cpupool);
     } else {
         find_domain(dom);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:17:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0EsM-0006o8-S5; Wed, 22 Feb 2012 16:17:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0EsL-0006nP-8H
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:05 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329927415!9327088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30806 invoked from network); 22 Feb 2012 16:16:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="22344738"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-0d;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: af02b1ea16dabf3d96f21a91d1697eb511dba241
Message-ID: <af02b1ea16dabf3d96f2.1329927312@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 9] libxl: Rename libxl_sched_* to include
	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for introducing a schedule parameter-based structure,
rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.

No functional changes.

v2: Wrap long lines while I'm at it

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -2975,7 +2975,8 @@ int libxl_get_sched_id(libxl_ctx *ctx)
     return sched;
 }
 
-int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     int rc;
@@ -2992,7 +2993,8 @@ int libxl_sched_credit_domain_get(libxl_
     return 0;
 }
 
-int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     xc_domaininfo_t domaininfo;
@@ -3033,7 +3035,7 @@ int libxl_sched_credit_domain_set(libxl_
 }
 
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     int rc;
@@ -3051,7 +3053,7 @@ int libxl_sched_credit2_domain_get(libxl
 }
 
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     xc_domaininfo_t domaininfo;
@@ -3086,7 +3088,7 @@ int libxl_sched_credit2_domain_set(libxl
 }
 
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     uint64_t period;
     uint64_t slice;
@@ -3112,7 +3114,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 }
 
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     xc_domaininfo_t domaininfo;
     int rc;
diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -588,17 +588,17 @@ int libxl_get_sched_id(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
@@ -390,16 +390,16 @@ libxl_cputopology = Struct("cputopology"
     ("node", uint32),
     ])
 
-libxl_sched_credit = Struct("sched_credit", [
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
 
-libxl_sched_credit2 = Struct("sched_credit2", [
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)
 
-libxl_sched_sedf = Struct("sched_sedf", [
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
     ("period", integer),
     ("slice", integer),
     ("latency", integer),
diff -r b5d446a34508 -r af02b1ea16da tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -3913,7 +3913,7 @@ int main_sharing(int argc, char **argv)
 }
 
 static int sched_credit_domain_get(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3925,7 +3925,7 @@ static int sched_credit_domain_get(
 }
 
 static int sched_credit_domain_set(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3940,7 +3940,7 @@ static int sched_credit_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -3961,7 +3961,7 @@ static int sched_credit_domain_output(
 }
 
 static int sched_credit2_domain_get(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3973,7 +3973,7 @@ static int sched_credit2_domain_get(
 }
 
 static int sched_credit2_domain_set(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3988,7 +3988,7 @@ static int sched_credit2_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4008,7 +4008,7 @@ static int sched_credit2_domain_output(
 }
 
 static int sched_sedf_domain_get(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4020,7 +4020,7 @@ static int sched_sedf_domain_get(
 }
 
 static int sched_sedf_domain_set(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4035,7 +4035,7 @@ static int sched_sedf_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4116,7 +4116,7 @@ static int sched_domain_output(
 
 int main_sched_credit(int argc, char **argv)
 {
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
@@ -4198,7 +4198,7 @@ int main_sched_credit(int argc, char **a
 
 int main_sched_credit2(int argc, char **argv)
 {
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, opt_w = 0;
@@ -4272,7 +4272,7 @@ int main_sched_credit2(int argc, char **
 
 int main_sched_sedf(int argc, char **argv)
 {
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int period = 0, opt_p = 0;
diff -r b5d446a34508 -r af02b1ea16da tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Feb 22 16:08:28 2012 +0000
@@ -473,7 +473,7 @@ value stub_xl_sched_credit_domain_get(va
 {
 	CAMLparam1(domid);
 	CAMLlocal1(scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
@@ -483,18 +483,18 @@ value stub_xl_sched_credit_domain_get(va
 		failwith_xl("sched_credit_domain_get", &lg);
 	FREE_CTX();
 
-	scinfo = Val_sched_credit(&gc, &lg, &c_scinfo);
+	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
 	CAMLreturn(scinfo);
 }
 
 value stub_xl_sched_credit_domain_set(value domid, value scinfo)
 {
 	CAMLparam2(domid, scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
-	sched_credit_val(&gc, &lg, &c_scinfo, scinfo);
+	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
 
 	INIT_CTX();
 	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:17:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0EsM-0006o8-S5; Wed, 22 Feb 2012 16:17:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0EsL-0006nP-8H
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:05 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329927415!9327088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30806 invoked from network); 22 Feb 2012 16:16:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="22344738"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-0d;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: af02b1ea16dabf3d96f21a91d1697eb511dba241
Message-ID: <af02b1ea16dabf3d96f2.1329927312@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 9] libxl: Rename libxl_sched_* to include
	_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In preparation for introducing a schedule parameter-based structure,
rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.

No functional changes.

v2: Wrap long lines while I'm at it

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -2975,7 +2975,8 @@ int libxl_get_sched_id(libxl_ctx *ctx)
     return sched;
 }
 
-int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     int rc;
@@ -2992,7 +2993,8 @@ int libxl_sched_credit_domain_get(libxl_
     return 0;
 }
 
-int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid, libxl_sched_credit *scinfo)
+int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_sched_credit_domain *scinfo)
 {
     struct xen_domctl_sched_credit sdom;
     xc_domaininfo_t domaininfo;
@@ -3033,7 +3035,7 @@ int libxl_sched_credit_domain_set(libxl_
 }
 
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     int rc;
@@ -3051,7 +3053,7 @@ int libxl_sched_credit2_domain_get(libxl
 }
 
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo)
+                                   libxl_sched_credit2_domain *scinfo)
 {
     struct xen_domctl_sched_credit2 sdom;
     xc_domaininfo_t domaininfo;
@@ -3086,7 +3088,7 @@ int libxl_sched_credit2_domain_set(libxl
 }
 
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     uint64_t period;
     uint64_t slice;
@@ -3112,7 +3114,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 }
 
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo)
+                                libxl_sched_sedf_domain *scinfo)
 {
     xc_domaininfo_t domaininfo;
     int rc;
diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -588,17 +588,17 @@ int libxl_get_sched_id(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                  libxl_sched_credit *scinfo);
+                                  libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                   libxl_sched_credit2 *scinfo);
+                                   libxl_sched_credit2_domain *scinfo);
 int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
-                                libxl_sched_sedf *scinfo);
+                                libxl_sched_sedf_domain *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
@@ -390,16 +390,16 @@ libxl_cputopology = Struct("cputopology"
     ("node", uint32),
     ])
 
-libxl_sched_credit = Struct("sched_credit", [
+libxl_sched_credit_domain = Struct("sched_credit_domain", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
 
-libxl_sched_credit2 = Struct("sched_credit2", [
+libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)
 
-libxl_sched_sedf = Struct("sched_sedf", [
+libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
     ("period", integer),
     ("slice", integer),
     ("latency", integer),
diff -r b5d446a34508 -r af02b1ea16da tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -3913,7 +3913,7 @@ int main_sharing(int argc, char **argv)
 }
 
 static int sched_credit_domain_get(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3925,7 +3925,7 @@ static int sched_credit_domain_get(
 }
 
 static int sched_credit_domain_set(
-    int domid, libxl_sched_credit *scinfo)
+    int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3940,7 +3940,7 @@ static int sched_credit_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -3961,7 +3961,7 @@ static int sched_credit_domain_output(
 }
 
 static int sched_credit2_domain_get(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3973,7 +3973,7 @@ static int sched_credit2_domain_get(
 }
 
 static int sched_credit2_domain_set(
-    int domid, libxl_sched_credit2 *scinfo)
+    int domid, libxl_sched_credit2_domain *scinfo)
 {
     int rc;
 
@@ -3988,7 +3988,7 @@ static int sched_credit2_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4008,7 +4008,7 @@ static int sched_credit2_domain_output(
 }
 
 static int sched_sedf_domain_get(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4020,7 +4020,7 @@ static int sched_sedf_domain_get(
 }
 
 static int sched_sedf_domain_set(
-    int domid, libxl_sched_sedf *scinfo)
+    int domid, libxl_sched_sedf_domain *scinfo)
 {
     int rc;
 
@@ -4035,7 +4035,7 @@ static int sched_sedf_domain_output(
     int domid)
 {
     char *domname;
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     int rc;
 
     if (domid < 0) {
@@ -4116,7 +4116,7 @@ static int sched_domain_output(
 
 int main_sched_credit(int argc, char **argv)
 {
-    libxl_sched_credit scinfo;
+    libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
@@ -4198,7 +4198,7 @@ int main_sched_credit(int argc, char **a
 
 int main_sched_credit2(int argc, char **argv)
 {
-    libxl_sched_credit2 scinfo;
+    libxl_sched_credit2_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, opt_w = 0;
@@ -4272,7 +4272,7 @@ int main_sched_credit2(int argc, char **
 
 int main_sched_sedf(int argc, char **argv)
 {
-    libxl_sched_sedf scinfo;
+    libxl_sched_sedf_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int period = 0, opt_p = 0;
diff -r b5d446a34508 -r af02b1ea16da tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Feb 22 16:08:28 2012 +0000
@@ -473,7 +473,7 @@ value stub_xl_sched_credit_domain_get(va
 {
 	CAMLparam1(domid);
 	CAMLlocal1(scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
@@ -483,18 +483,18 @@ value stub_xl_sched_credit_domain_get(va
 		failwith_xl("sched_credit_domain_get", &lg);
 	FREE_CTX();
 
-	scinfo = Val_sched_credit(&gc, &lg, &c_scinfo);
+	scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
 	CAMLreturn(scinfo);
 }
 
 value stub_xl_sched_credit_domain_set(value domid, value scinfo)
 {
 	CAMLparam2(domid, scinfo);
-	libxl_sched_credit c_scinfo;
+	libxl_sched_credit_domain c_scinfo;
 	int ret;
 	INIT_STRUCT();
 
-	sched_credit_val(&gc, &lg, &c_scinfo, scinfo);
+	sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
 
 	INIT_CTX();
 	ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0EsN-0006oJ-A6; Wed, 22 Feb 2012 16:17:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0EsM-0006nQ-5o
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:06 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329927415!9327088!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30852 invoked from network); 22 Feb 2012 16:16:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="22344739"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-1w;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0f91ce7b095af8506e946d4c453c575fa2ea01a5
Message-ID: <0f91ce7b095af8506e94.1329927315@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:15 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 9 of 9] xl: Implement sched-credit schedule
 parameter command-line 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

Add features to the sched-credit interface to allow querying and
displaying scheduler parameters.

v2:
 - Change function line breaks
 - Pool output deals gracefully with other schedulers
 - Add new parameters, as well as a description of how they
   interact, to the xl man page

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5600db2bcd0e -r 0f91ce7b095a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Feb 22 16:08:28 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Feb 22 16:08:28 2012 +0000
@@ -714,6 +714,53 @@ no upper cap.
 
 Restrict output to domains in the specified cpupool.
 
+=item B<-s>, B<--schedparam>
+
+Specify to list or set pool-wide scheduler parameters.
+
+=item B<-t TSLICE>, B<--tslice_ms=TSLICE>
+
+Timeslice tells the scheduler how long to allow VMs to run before
+pre-empting.  The default is 30ms.  Valid ranges are 1ms to 1000ms.
+The length of the timeslice (in ms) must be higher than the length of
+the ratelimit (see below).
+
+=item B<-r RLIMIT>, B<--ratelimit_us=RLIMIT>
+
+Ratelimit attempts to limit the number of schedules per second.  It
+sets a minimum amount of time (in microseconds) a VM must run before
+we will allow a higher-prioirty VM to pre-empt it.  The default value
+is 1000 microseconds (1ms).  Valid range is 100 to 500000 (500ms).
+The ratelimit length must be lower than the timeslice length.
+
+=back
+
+B<COMBINATION>
+
+The following is the effect of combining the above options:
+
+=over 4
+
+=item B<E<lt>nothingE<gt>>             : List all domain params and sched params from all pools
+
+=item B<-d [domid]>            : List domain params for domain [domid]
+
+=item B<-d [domid] [params]>   : Set domain params for domain [domid]
+
+=item B<-p [pool]>             : list all domains and sched params for [pool]
+
+=item B<-s>                    : List sched params for poolid 0
+
+=item B<-s [params]>           : Set sched params for poolid 0
+
+=item B<-p [pool] -s>          : List sched params for [pool]
+
+=item B<-p [pool] -s [params]> : Set sched params for [pool]
+
+=item B<-p [pool] -d>...       : Illegal
+
+=item
+
 =back
 
 =item B<sched-credit2> [I<OPTIONS>]
diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -3912,8 +3912,7 @@ int main_sharing(int argc, char **argv)
     return 0;
 }
 
-static int sched_credit_domain_get(
-    int domid, libxl_sched_credit_domain *scinfo)
+static int sched_credit_domain_get(int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3924,8 +3923,7 @@ static int sched_credit_domain_get(
     return rc;
 }
 
-static int sched_credit_domain_set(
-    int domid, libxl_sched_credit_domain *scinfo)
+static int sched_credit_domain_set(int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3936,8 +3934,29 @@ static int sched_credit_domain_set(
     return rc;
 }
 
-static int sched_credit_domain_output(
-    int domid)
+static int sched_credit_params_set(int poolid, libxl_sched_credit_params *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_params_set(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_params_set failed.\n");
+
+    return rc;
+}
+
+static int sched_credit_params_get(int poolid, libxl_sched_credit_params *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_params_get(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_params_get failed.\n");
+
+    return rc;
+}
+
+static int sched_credit_domain_output(int domid)
 {
     char *domname;
     libxl_sched_credit_domain scinfo;
@@ -3960,6 +3979,27 @@ static int sched_credit_domain_output(
     return 0;
 }
 
+static int sched_credit_pool_output(uint32_t poolid)
+{
+    libxl_sched_credit_params scparam;
+    char *poolname;
+    int rc;
+
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    rc = sched_credit_params_get(poolid, &scparam);
+    if (rc) {
+        printf("Cpupool %s: [sched params unavailable]\n",
+               poolname);
+    } else {
+        printf("Cpupool %s: tslice=%dms ratelimit=%dus\n",
+               poolname,
+               scparam.tslice_ms,
+               scparam.ratelimit_us);
+    }
+    free(poolname);
+    return 0;
+}
+
 static int sched_credit2_domain_get(
     int domid, libxl_sched_credit2_domain *scinfo)
 {
@@ -4122,25 +4162,41 @@ static int sched_domain_output(uint32_t 
     return 0;
 }
 
+/* 
+ * <nothing>             : List all domain params and sched params from all pools
+ * -d [domid]            : List domain params for domain
+ * -d [domid] [params]   : Set domain params for domain
+ * -p [pool]             : list all domains and sched params for pool
+ * -s                    : List sched params for poolid 0
+ * -s [params]           : Set sched params for poolid 0
+ * -p [pool] -s          : List sched params for pool
+ * -p [pool] -s [params] : Set sched params for pool
+ * -p [pool] -d...       : Illegal
+ */
 int main_sched_credit(int argc, char **argv)
 {
     libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
+    int opt_s = 0;
+    int tslice = 0, opt_t = 0, ratelimit = 0, opt_r = 0;
     int opt, rc;
     int option_index = 0;
     static struct option long_options[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
+        {"schedparam", 0, 0, 's'},
+        {"tslice_ms", 1, 0, 't'},
+        {"ratelimit_us", 1, 0, 'r'},
         {"cpupool", 1, 0, 'p'},
         {"help", 0, 0, 'h'},
         {0, 0, 0, 0}
     };
 
     while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:p:h", long_options,
+        opt = getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_options,
                           &option_index);
         if (opt == -1)
             break;
@@ -4158,6 +4214,17 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 't':
+            tslice = strtol(optarg, NULL, 10);
+            opt_t = 1;
+            break;
+        case 'r':
+            ratelimit = strtol(optarg, NULL, 10);
+            opt_r = 1;
+            break;
+        case 's':
+            opt_s = 1;
+            break;
         case 'p':
             cpupool = optarg;
             break;
@@ -4167,20 +4234,54 @@ int main_sched_credit(int argc, char **a
         }
     }
 
-    if (cpupool && (dom || opt_w || opt_c)) {
-        fprintf(stderr, "Specifying a cpupool is not allowed with other "
-                "options.\n");
+    if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
+        fprintf(stderr, "Specifying a cpupool or schedparam is not "
+                "allowed with domain options.\n");
         return 1;
     }
     if (!dom && (opt_w || opt_c)) {
         fprintf(stderr, "Must specify a domain.\n");
         return 1;
     }
-
-    if (!dom) { /* list all domain's credit scheduler info */
+    if (!opt_s && (opt_t || opt_r)) {
+        fprintf(stderr, "Must specify schedparam to set schedule "
+                "parameter values.\n");
+        return 1;
+    }
+
+    if (opt_s) {
+        libxl_sched_credit_params  scparam;
+        uint32_t poolid = 0;
+
+        if (cpupool) {
+            if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
+                !libxl_cpupoolid_to_name(ctx, poolid)) {
+                fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+                return -ERROR_FAIL;
+            }
+        }
+
+        if (!opt_t && !opt_r) { /* Output scheduling parameters */
+            return -sched_credit_pool_output(poolid);
+        } else { /* Set scheduling parameters*/
+            rc = sched_credit_params_get(poolid, &scparam);
+            if (rc)
+                return -rc;
+
+            if (opt_t)
+                scparam.tslice_ms = tslice;
+
+            if (opt_r)
+                scparam.ratelimit_us = ratelimit;
+
+            rc = sched_credit_params_set(poolid, &scparam);
+            if (rc)
+                return -rc;
+        }
+    } else if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
                                     sched_credit_domain_output,
-                                    sched_default_pool_output,
+                                    sched_credit_pool_output,
                                     cpupool);
     } else {
         find_domain(dom);
diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Wed Feb 22 16:08:28 2012 +0000
@@ -204,11 +204,14 @@ struct cmd_spec cmd_table[] = {
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",
-      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-p CPUPOOL]",
-      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
-      "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
-      "-c CAP, --cap=CAP              Cap (int)\n"
-      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
+      "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
+      "-w WEIGHT, --weight=WEIGHT        Weight (int)\n"
+      "-c CAP, --cap=CAP                 Cap (int)\n"
+      "-s         --schedparam           Query / modify scheduler parameters\n"
+      "-t TSLICE, --tslice_ms=TSLICE     Set the timeslice, in milliseconds\n"
+      "-r RLIMIT, --ratelimit_us=RLIMIT  Set the scheduling rate limit, in microseconds\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
       &main_sched_credit2, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0EsN-0006oJ-A6; Wed, 22 Feb 2012 16:17:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0EsM-0006nQ-5o
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:06 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329927415!9327088!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30852 invoked from network); 22 Feb 2012 16:16:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:16:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="22344739"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-1w;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0f91ce7b095af8506e946d4c453c575fa2ea01a5
Message-ID: <0f91ce7b095af8506e94.1329927315@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:15 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 9 of 9] xl: Implement sched-credit schedule
 parameter command-line 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

Add features to the sched-credit interface to allow querying and
displaying scheduler parameters.

v2:
 - Change function line breaks
 - Pool output deals gracefully with other schedulers
 - Add new parameters, as well as a description of how they
   interact, to the xl man page

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 5600db2bcd0e -r 0f91ce7b095a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Feb 22 16:08:28 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Feb 22 16:08:28 2012 +0000
@@ -714,6 +714,53 @@ no upper cap.
 
 Restrict output to domains in the specified cpupool.
 
+=item B<-s>, B<--schedparam>
+
+Specify to list or set pool-wide scheduler parameters.
+
+=item B<-t TSLICE>, B<--tslice_ms=TSLICE>
+
+Timeslice tells the scheduler how long to allow VMs to run before
+pre-empting.  The default is 30ms.  Valid ranges are 1ms to 1000ms.
+The length of the timeslice (in ms) must be higher than the length of
+the ratelimit (see below).
+
+=item B<-r RLIMIT>, B<--ratelimit_us=RLIMIT>
+
+Ratelimit attempts to limit the number of schedules per second.  It
+sets a minimum amount of time (in microseconds) a VM must run before
+we will allow a higher-prioirty VM to pre-empt it.  The default value
+is 1000 microseconds (1ms).  Valid range is 100 to 500000 (500ms).
+The ratelimit length must be lower than the timeslice length.
+
+=back
+
+B<COMBINATION>
+
+The following is the effect of combining the above options:
+
+=over 4
+
+=item B<E<lt>nothingE<gt>>             : List all domain params and sched params from all pools
+
+=item B<-d [domid]>            : List domain params for domain [domid]
+
+=item B<-d [domid] [params]>   : Set domain params for domain [domid]
+
+=item B<-p [pool]>             : list all domains and sched params for [pool]
+
+=item B<-s>                    : List sched params for poolid 0
+
+=item B<-s [params]>           : Set sched params for poolid 0
+
+=item B<-p [pool] -s>          : List sched params for [pool]
+
+=item B<-p [pool] -s [params]> : Set sched params for [pool]
+
+=item B<-p [pool] -d>...       : Illegal
+
+=item
+
 =back
 
 =item B<sched-credit2> [I<OPTIONS>]
diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -3912,8 +3912,7 @@ int main_sharing(int argc, char **argv)
     return 0;
 }
 
-static int sched_credit_domain_get(
-    int domid, libxl_sched_credit_domain *scinfo)
+static int sched_credit_domain_get(int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3924,8 +3923,7 @@ static int sched_credit_domain_get(
     return rc;
 }
 
-static int sched_credit_domain_set(
-    int domid, libxl_sched_credit_domain *scinfo)
+static int sched_credit_domain_set(int domid, libxl_sched_credit_domain *scinfo)
 {
     int rc;
 
@@ -3936,8 +3934,29 @@ static int sched_credit_domain_set(
     return rc;
 }
 
-static int sched_credit_domain_output(
-    int domid)
+static int sched_credit_params_set(int poolid, libxl_sched_credit_params *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_params_set(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_params_set failed.\n");
+
+    return rc;
+}
+
+static int sched_credit_params_get(int poolid, libxl_sched_credit_params *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit_params_get(ctx, poolid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit_params_get failed.\n");
+
+    return rc;
+}
+
+static int sched_credit_domain_output(int domid)
 {
     char *domname;
     libxl_sched_credit_domain scinfo;
@@ -3960,6 +3979,27 @@ static int sched_credit_domain_output(
     return 0;
 }
 
+static int sched_credit_pool_output(uint32_t poolid)
+{
+    libxl_sched_credit_params scparam;
+    char *poolname;
+    int rc;
+
+    poolname = libxl_cpupoolid_to_name(ctx, poolid);
+    rc = sched_credit_params_get(poolid, &scparam);
+    if (rc) {
+        printf("Cpupool %s: [sched params unavailable]\n",
+               poolname);
+    } else {
+        printf("Cpupool %s: tslice=%dms ratelimit=%dus\n",
+               poolname,
+               scparam.tslice_ms,
+               scparam.ratelimit_us);
+    }
+    free(poolname);
+    return 0;
+}
+
 static int sched_credit2_domain_get(
     int domid, libxl_sched_credit2_domain *scinfo)
 {
@@ -4122,25 +4162,41 @@ static int sched_domain_output(uint32_t 
     return 0;
 }
 
+/* 
+ * <nothing>             : List all domain params and sched params from all pools
+ * -d [domid]            : List domain params for domain
+ * -d [domid] [params]   : Set domain params for domain
+ * -p [pool]             : list all domains and sched params for pool
+ * -s                    : List sched params for poolid 0
+ * -s [params]           : Set sched params for poolid 0
+ * -p [pool] -s          : List sched params for pool
+ * -p [pool] -s [params] : Set sched params for pool
+ * -p [pool] -d...       : Illegal
+ */
 int main_sched_credit(int argc, char **argv)
 {
     libxl_sched_credit_domain scinfo;
     const char *dom = NULL;
     const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
+    int opt_s = 0;
+    int tslice = 0, opt_t = 0, ratelimit = 0, opt_r = 0;
     int opt, rc;
     int option_index = 0;
     static struct option long_options[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
+        {"schedparam", 0, 0, 's'},
+        {"tslice_ms", 1, 0, 't'},
+        {"ratelimit_us", 1, 0, 'r'},
         {"cpupool", 1, 0, 'p'},
         {"help", 0, 0, 'h'},
         {0, 0, 0, 0}
     };
 
     while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:p:h", long_options,
+        opt = getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_options,
                           &option_index);
         if (opt == -1)
             break;
@@ -4158,6 +4214,17 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 't':
+            tslice = strtol(optarg, NULL, 10);
+            opt_t = 1;
+            break;
+        case 'r':
+            ratelimit = strtol(optarg, NULL, 10);
+            opt_r = 1;
+            break;
+        case 's':
+            opt_s = 1;
+            break;
         case 'p':
             cpupool = optarg;
             break;
@@ -4167,20 +4234,54 @@ int main_sched_credit(int argc, char **a
         }
     }
 
-    if (cpupool && (dom || opt_w || opt_c)) {
-        fprintf(stderr, "Specifying a cpupool is not allowed with other "
-                "options.\n");
+    if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
+        fprintf(stderr, "Specifying a cpupool or schedparam is not "
+                "allowed with domain options.\n");
         return 1;
     }
     if (!dom && (opt_w || opt_c)) {
         fprintf(stderr, "Must specify a domain.\n");
         return 1;
     }
-
-    if (!dom) { /* list all domain's credit scheduler info */
+    if (!opt_s && (opt_t || opt_r)) {
+        fprintf(stderr, "Must specify schedparam to set schedule "
+                "parameter values.\n");
+        return 1;
+    }
+
+    if (opt_s) {
+        libxl_sched_credit_params  scparam;
+        uint32_t poolid = 0;
+
+        if (cpupool) {
+            if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
+                !libxl_cpupoolid_to_name(ctx, poolid)) {
+                fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+                return -ERROR_FAIL;
+            }
+        }
+
+        if (!opt_t && !opt_r) { /* Output scheduling parameters */
+            return -sched_credit_pool_output(poolid);
+        } else { /* Set scheduling parameters*/
+            rc = sched_credit_params_get(poolid, &scparam);
+            if (rc)
+                return -rc;
+
+            if (opt_t)
+                scparam.tslice_ms = tslice;
+
+            if (opt_r)
+                scparam.ratelimit_us = ratelimit;
+
+            rc = sched_credit_params_set(poolid, &scparam);
+            if (rc)
+                return -rc;
+        }
+    } else if (!dom) { /* list all domain's credit scheduler info */
         return -sched_domain_output(XEN_SCHEDULER_CREDIT,
                                     sched_credit_domain_output,
-                                    sched_default_pool_output,
+                                    sched_credit_pool_output,
                                     cpupool);
     } else {
         find_domain(dom);
diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Wed Feb 22 16:08:28 2012 +0000
@@ -204,11 +204,14 @@ struct cmd_spec cmd_table[] = {
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",
-      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-p CPUPOOL]",
-      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
-      "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
-      "-c CAP, --cap=CAP              Cap (int)\n"
-      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-s [-t TSLICE] [-r RATELIMIT]] [-p CPUPOOL]",
+      "-d DOMAIN, --domain=DOMAIN        Domain to modify\n"
+      "-w WEIGHT, --weight=WEIGHT        Weight (int)\n"
+      "-c CAP, --cap=CAP                 Cap (int)\n"
+      "-s         --schedparam           Query / modify scheduler parameters\n"
+      "-t TSLICE, --tslice_ms=TSLICE     Set the timeslice, in milliseconds\n"
+      "-r RLIMIT, --ratelimit_us=RLIMIT  Set the scheduling rate limit, in microseconds\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL     Restrict output to CPUPOOL"
     },
     { "sched-credit2",
       &main_sched_credit2, 0,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esh-0006tp-74; Wed, 22 Feb 2012 16:17:27 +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 1S0Esf-0006si-Bn
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:25 +0000
Received: from [85.158.139.83:8735] by server-7.bemta-5.messagelabs.com id
	63/8C-16195-415154F4; Wed, 22 Feb 2012 16:17:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329927441!16118939!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9902 invoked from network); 22 Feb 2012 16:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-Vx;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0b230c5ac8b7c23d1185834268093bb26d41787a
Message-ID: <0b230c5ac8b7c23d1185.1329927310@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:10 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 9] xen: Implement SCHEDOP sysctl for credit
	scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow tslice_ms and ratelimit_us to be modified.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a4e58388859e -r 0b230c5ac8b7 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
@@ -833,6 +833,36 @@ csched_dom_cntl(
     return 0;
 }
 
+static int
+csched_sys_cntl(const struct scheduler *ops,
+                        struct xen_sysctl_scheduler_op *sc)
+{
+    int rc = -EINVAL;
+    xen_sysctl_credit_schedule_t *params = &sc->u.sched_credit;
+    struct csched_private *prv = CSCHED_PRIV(ops);
+
+    switch ( sc->cmd )
+    {
+    case XEN_SYSCTL_SCHEDOP_putinfo:
+        if (params->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+            || params->tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN 
+            || params->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+            || params->ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN 
+            || MICROSECS(params->ratelimit_us) > MILLISECS(params->tslice_ms) )
+                goto out;
+        prv->tslice_ms = params->tslice_ms;
+        prv->ratelimit_us = params->ratelimit_us;
+        /* FALLTHRU */
+    case XEN_SYSCTL_SCHEDOP_getinfo:
+        params->tslice_ms = prv->tslice_ms;
+        params->ratelimit_us = prv->ratelimit_us;
+        rc = 0;
+        break;
+    }
+    out:
+    return rc;
+}
+
 static void *
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
 {
@@ -1566,6 +1596,28 @@ csched_init(struct scheduler *ops)
     INIT_LIST_HEAD(&prv->active_sdom);
     prv->master = UINT_MAX;
 
+    if ( sched_credit_tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+         || sched_credit_tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN )
+    {
+        printk("WARNING: sched_credit_tslice_ms outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_CSCHED_TSLICE_MIN,
+               XEN_SYSCTL_CSCHED_TSLICE_MAX,
+               CSCHED_DEFAULT_TSLICE_MS);
+        sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
+    }
+
+    if ( sched_ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+         || sched_ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN )
+    {
+        printk("WARNING: sched_ratelimit_us outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+               XEN_SYSCTL_SCHED_RATELIMIT_MAX,
+               SCHED_DEFAULT_RATELIMIT_US);
+        sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
+    }
+
     prv->tslice_ms = sched_credit_tslice_ms;
     prv->ticks_per_tslice = CSCHED_TICKS_PER_TSLICE;
     if ( prv->tslice_ms < prv->ticks_per_tslice )
@@ -1641,6 +1693,7 @@ const struct scheduler sched_credit_def 
     .yield          = csched_vcpu_yield,
 
     .adjust         = csched_dom_cntl,
+    .adjust_global  = csched_sys_cntl,
 
     .pick_cpu       = csched_cpu_pick,
     .do_schedule    = csched_schedule,
diff -r a4e58388859e -r 0b230c5ac8b7 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/include/public/sysctl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -564,6 +564,19 @@ struct xen_sysctl_arinc653_schedule {
 typedef struct xen_sysctl_arinc653_schedule xen_sysctl_arinc653_schedule_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_arinc653_schedule_t);
 
+struct xen_sysctl_credit_schedule {
+    /* Length of timeslice in milliseconds */
+#define XEN_SYSCTL_CSCHED_TSLICE_MAX 1000
+#define XEN_SYSCTL_CSCHED_TSLICE_MIN 1
+    unsigned tslice_ms;
+    /* Rate limit (minimum timeslice) in microseconds */
+#define XEN_SYSCTL_SCHED_RATELIMIT_MAX 500000
+#define XEN_SYSCTL_SCHED_RATELIMIT_MIN 100
+    unsigned ratelimit_us;
+};
+typedef struct xen_sysctl_credit_schedule xen_sysctl_credit_schedule_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_credit_schedule_t);
+
 /* XEN_SYSCTL_scheduler_op */
 /* Set or get info? */
 #define XEN_SYSCTL_SCHEDOP_putinfo 0
@@ -576,6 +589,7 @@ struct xen_sysctl_scheduler_op {
         struct xen_sysctl_sched_arinc653 {
             XEN_GUEST_HANDLE_64(xen_sysctl_arinc653_schedule_t) schedule;
         } sched_arinc653;
+        struct xen_sysctl_credit_schedule sched_credit;
     } u;
 };
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esh-0006tp-74; Wed, 22 Feb 2012 16:17:27 +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 1S0Esf-0006si-Bn
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:25 +0000
Received: from [85.158.139.83:8735] by server-7.bemta-5.messagelabs.com id
	63/8C-16195-415154F4; Wed, 22 Feb 2012 16:17:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329927441!16118939!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9902 invoked from network); 22 Feb 2012 16:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-Vx;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: 0b230c5ac8b7c23d1185834268093bb26d41787a
Message-ID: <0b230c5ac8b7c23d1185.1329927310@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:10 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 9] xen: Implement SCHEDOP sysctl for credit
	scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow tslice_ms and ratelimit_us to be modified.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a4e58388859e -r 0b230c5ac8b7 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
@@ -833,6 +833,36 @@ csched_dom_cntl(
     return 0;
 }
 
+static int
+csched_sys_cntl(const struct scheduler *ops,
+                        struct xen_sysctl_scheduler_op *sc)
+{
+    int rc = -EINVAL;
+    xen_sysctl_credit_schedule_t *params = &sc->u.sched_credit;
+    struct csched_private *prv = CSCHED_PRIV(ops);
+
+    switch ( sc->cmd )
+    {
+    case XEN_SYSCTL_SCHEDOP_putinfo:
+        if (params->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+            || params->tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN 
+            || params->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+            || params->ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN 
+            || MICROSECS(params->ratelimit_us) > MILLISECS(params->tslice_ms) )
+                goto out;
+        prv->tslice_ms = params->tslice_ms;
+        prv->ratelimit_us = params->ratelimit_us;
+        /* FALLTHRU */
+    case XEN_SYSCTL_SCHEDOP_getinfo:
+        params->tslice_ms = prv->tslice_ms;
+        params->ratelimit_us = prv->ratelimit_us;
+        rc = 0;
+        break;
+    }
+    out:
+    return rc;
+}
+
 static void *
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
 {
@@ -1566,6 +1596,28 @@ csched_init(struct scheduler *ops)
     INIT_LIST_HEAD(&prv->active_sdom);
     prv->master = UINT_MAX;
 
+    if ( sched_credit_tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX
+         || sched_credit_tslice_ms < XEN_SYSCTL_CSCHED_TSLICE_MIN )
+    {
+        printk("WARNING: sched_credit_tslice_ms outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_CSCHED_TSLICE_MIN,
+               XEN_SYSCTL_CSCHED_TSLICE_MAX,
+               CSCHED_DEFAULT_TSLICE_MS);
+        sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
+    }
+
+    if ( sched_ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX
+         || sched_ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN )
+    {
+        printk("WARNING: sched_ratelimit_us outside of valid range [%d,%d].\n"
+               " Resetting to default %u\n",
+               XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+               XEN_SYSCTL_SCHED_RATELIMIT_MAX,
+               SCHED_DEFAULT_RATELIMIT_US);
+        sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
+    }
+
     prv->tslice_ms = sched_credit_tslice_ms;
     prv->ticks_per_tslice = CSCHED_TICKS_PER_TSLICE;
     if ( prv->tslice_ms < prv->ticks_per_tslice )
@@ -1641,6 +1693,7 @@ const struct scheduler sched_credit_def 
     .yield          = csched_vcpu_yield,
 
     .adjust         = csched_dom_cntl,
+    .adjust_global  = csched_sys_cntl,
 
     .pick_cpu       = csched_cpu_pick,
     .do_schedule    = csched_schedule,
diff -r a4e58388859e -r 0b230c5ac8b7 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/include/public/sysctl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -564,6 +564,19 @@ struct xen_sysctl_arinc653_schedule {
 typedef struct xen_sysctl_arinc653_schedule xen_sysctl_arinc653_schedule_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_arinc653_schedule_t);
 
+struct xen_sysctl_credit_schedule {
+    /* Length of timeslice in milliseconds */
+#define XEN_SYSCTL_CSCHED_TSLICE_MAX 1000
+#define XEN_SYSCTL_CSCHED_TSLICE_MIN 1
+    unsigned tslice_ms;
+    /* Rate limit (minimum timeslice) in microseconds */
+#define XEN_SYSCTL_SCHED_RATELIMIT_MAX 500000
+#define XEN_SYSCTL_SCHED_RATELIMIT_MIN 100
+    unsigned ratelimit_us;
+};
+typedef struct xen_sysctl_credit_schedule xen_sysctl_credit_schedule_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_credit_schedule_t);
+
 /* XEN_SYSCTL_scheduler_op */
 /* Set or get info? */
 #define XEN_SYSCTL_SCHEDOP_putinfo 0
@@ -576,6 +589,7 @@ struct xen_sysctl_scheduler_op {
         struct xen_sysctl_sched_arinc653 {
             XEN_GUEST_HANDLE_64(xen_sysctl_arinc653_schedule_t) schedule;
         } sched_arinc653;
+        struct xen_sysctl_credit_schedule sched_credit;
     } u;
 };
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esk-0006vI-Dj; Wed, 22 Feb 2012 16:17:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esi-0006sN-Qv
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13758 invoked from network); 22 Feb 2012 16:17:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-VW;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: a4e58388859eb56177b868b69402da19428b0517
Message-ID: <a4e58388859eb56177b8.1329927309@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 9] xen: Print ratelimit in scheduler
	debugkey
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r efd21e08e0fd -r a4e58388859e xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
@@ -1504,6 +1504,7 @@ csched_dump(const struct scheduler *ops)
            "\trunq_sort          = %u\n"
            "\tdefault-weight     = %d\n"
            "\ttslice             = %dms\n"
+           "\tratelimit          = %dus\n"
            "\tcredits per msec   = %d\n"
            "\tticks per tslice   = %d\n"
            "\tmigration delay    = %uus\n",
@@ -1515,6 +1516,7 @@ csched_dump(const struct scheduler *ops)
            prv->runq_sort,
            CSCHED_DEFAULT_WEIGHT,
            prv->tslice_ms,
+           prv->ratelimit_us,
            CSCHED_CREDITS_PER_MSEC,
            prv->ticks_per_tslice,
            vcpu_migration_delay);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esk-0006vI-Dj; Wed, 22 Feb 2012 16:17:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esi-0006sN-Qv
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13758 invoked from network); 22 Feb 2012 16:17:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-VW;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: a4e58388859eb56177b868b69402da19428b0517
Message-ID: <a4e58388859eb56177b8.1329927309@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 9] xen: Print ratelimit in scheduler
	debugkey
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r efd21e08e0fd -r a4e58388859e xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/common/sched_credit.c	Wed Feb 22 16:08:28 2012 +0000
@@ -1504,6 +1504,7 @@ csched_dump(const struct scheduler *ops)
            "\trunq_sort          = %u\n"
            "\tdefault-weight     = %d\n"
            "\ttslice             = %dms\n"
+           "\tratelimit          = %dus\n"
            "\tcredits per msec   = %d\n"
            "\tticks per tslice   = %d\n"
            "\tmigration delay    = %uus\n",
@@ -1515,6 +1516,7 @@ csched_dump(const struct scheduler *ops)
            prv->runq_sort,
            CSCHED_DEFAULT_WEIGHT,
            prv->tslice_ms,
+           prv->ratelimit_us,
            CSCHED_CREDITS_PER_MSEC,
            prv->ticks_per_tslice,
            vcpu_migration_delay);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esi-0006uc-Kr; Wed, 22 Feb 2012 16:17:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esh-0006sA-H0
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13668 invoked from network); 22 Feb 2012 16:17:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974183"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-U1;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:06 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 9] V2 Allow user to configure credit
	scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series introduces hypercalls to allow the timeslice
and ratelimit parameters of the credit scheduler to be read and
tweaked, and plumbed all the way through to the xl command-line.

v2:
 - Fixed some line-length issues
 - Renamed structures and functions "params" rather than "param"
 - Added options to xl man page

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esi-0006uc-Kr; Wed, 22 Feb 2012 16:17:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esh-0006sA-H0
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13668 invoked from network); 22 Feb 2012 16:17:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974183"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-U1;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:06 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 9] V2 Allow user to configure credit
	scheduler parameters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series introduces hypercalls to allow the timeslice
and ratelimit parameters of the credit scheduler to be read and
tweaked, and plumbed all the way through to the xl command-line.

v2:
 - Fixed some line-length issues
 - Renamed structures and functions "params" rather than "param"
 - Added options to xl man page

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esk-0006v6-1l; Wed, 22 Feb 2012 16:17:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esi-0006sG-6W
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13715 invoked from network); 22 Feb 2012 16:17:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-Uf;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6d6667ea47ed4c5a73e519c4bafc870843f617de
Message-ID: <6d6667ea47ed4c5a73e5.1329927307@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:07 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 9] cleanup: Remove dependency files in efi
 directory during a make clean
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a4d93d0e0df2 -r 6d6667ea47ed xen/arch/x86/Makefile
--- a/xen/arch/x86/Makefile	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/arch/x86/Makefile	Wed Feb 22 16:08:28 2012 +0000
@@ -168,5 +168,5 @@ efi/mkreloc: efi/mkreloc.c
 clean::
 	rm -f asm-offsets.s xen.lds boot/*.o boot/*~ boot/core boot/mkelf32
 	rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc
+	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc efi/.*.d
 	rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esk-0006v6-1l; Wed, 22 Feb 2012 16:17:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esi-0006sG-6W
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13715 invoked from network); 22 Feb 2012 16:17:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-Uf;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6d6667ea47ed4c5a73e519c4bafc870843f617de
Message-ID: <6d6667ea47ed4c5a73e5.1329927307@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:07 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 9] cleanup: Remove dependency files in efi
 directory during a make clean
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a4d93d0e0df2 -r 6d6667ea47ed xen/arch/x86/Makefile
--- a/xen/arch/x86/Makefile	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/arch/x86/Makefile	Wed Feb 22 16:08:28 2012 +0000
@@ -168,5 +168,5 @@ efi/mkreloc: efi/mkreloc.c
 clean::
 	rm -f asm-offsets.s xen.lds boot/*.o boot/*~ boot/core boot/mkelf32
 	rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc
+	rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/mkreloc efi/.*.d
 	rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esf-0006tU-RC; Wed, 22 Feb 2012 16:17: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 1S0Ese-0006sQ-9U
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:24 +0000
Received: from [85.158.139.83:8674] by server-6.bemta-5.messagelabs.com id
	73/A1-27305-315154F4; Wed, 22 Feb 2012 16:17:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329927441!16118939!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9824 invoked from network); 22 Feb 2012 16:17:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974186"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-V7;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: efd21e08e0fd086fbaa242005deeb904a235ca05
Message-ID: <efd21e08e0fd086fbaa2.1329927308@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 9] xen: Add a #define for the default
	ratelimit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6d6667ea47ed -r efd21e08e0fd xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/common/schedule.c	Wed Feb 22 16:08:28 2012 +0000
@@ -50,7 +50,7 @@ boolean_param("sched_smt_power_savings",
 /* Default scheduling rate limit: 1ms 
  * The behavior when sched_ratelimit_us is greater than sched_credit_tslice_ms is undefined
  * */
-int sched_ratelimit_us = 1000;
+int sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
 integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
diff -r 6d6667ea47ed -r efd21e08e0fd xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/include/xen/sched-if.h	Wed Feb 22 16:08:28 2012 +0000
@@ -18,6 +18,7 @@ extern cpumask_t cpupool_free_cpus;
 
 /* Scheduler generic parameters
  * */
+#define SCHED_DEFAULT_RATELIMIT_US 1000
 extern int sched_ratelimit_us;
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esf-0006tU-RC; Wed, 22 Feb 2012 16:17: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 1S0Ese-0006sQ-9U
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:24 +0000
Received: from [85.158.139.83:8674] by server-6.bemta-5.messagelabs.com id
	73/A1-27305-315154F4; Wed, 22 Feb 2012 16:17:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329927441!16118939!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9824 invoked from network); 22 Feb 2012 16:17:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974186"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0Es9-00060o-V7;
	Wed, 22 Feb 2012 16:16:53 +0000
MIME-Version: 1.0
X-Mercurial-Node: efd21e08e0fd086fbaa242005deeb904a235ca05
Message-ID: <efd21e08e0fd086fbaa2.1329927308@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 9] xen: Add a #define for the default
	ratelimit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6d6667ea47ed -r efd21e08e0fd xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/common/schedule.c	Wed Feb 22 16:08:28 2012 +0000
@@ -50,7 +50,7 @@ boolean_param("sched_smt_power_savings",
 /* Default scheduling rate limit: 1ms 
  * The behavior when sched_ratelimit_us is greater than sched_credit_tslice_ms is undefined
  * */
-int sched_ratelimit_us = 1000;
+int sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
 integer_param("sched_ratelimit_us", sched_ratelimit_us);
 /* Various timer handlers. */
 static void s_timer_fn(void *unused);
diff -r 6d6667ea47ed -r efd21e08e0fd xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/xen/include/xen/sched-if.h	Wed Feb 22 16:08:28 2012 +0000
@@ -18,6 +18,7 @@ extern cpumask_t cpupool_free_cpus;
 
 /* Scheduler generic parameters
  * */
+#define SCHED_DEFAULT_RATELIMIT_US 1000
 extern int sched_ratelimit_us;
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esl-0006vr-0s; Wed, 22 Feb 2012 16:17:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esj-0006sU-D6
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 22 Feb 2012 16:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974187"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-08;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: b5d446a3450824e737ad8299ed81cfd7b54598e3
Message-ID: <b5d446a3450824e737ad.1329927311@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:11 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 9] libxc: Implement SCHEDOP sysctl for
	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 0b230c5ac8b7 -r b5d446a34508 tools/libxc/xc_csched.c
--- a/tools/libxc/xc_csched.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxc/xc_csched.c	Wed Feb 22 16:08:28 2012 +0000
@@ -61,3 +61,47 @@ xc_sched_credit_domain_get(
 
     return err;
 }
+
+int
+xc_sched_credit_params_set(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
+
+    sysctl.u.scheduler_op.u.sched_credit = *schedule;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
+
+int
+xc_sched_credit_params_get(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
diff -r 0b230c5ac8b7 -r b5d446a34508 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxc/xenctrl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -668,7 +668,12 @@ int xc_sched_credit_domain_set(xc_interf
 int xc_sched_credit_domain_get(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit *sdom);
-
+int xc_sched_credit_params_set(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
+int xc_sched_credit_params_get(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
 int xc_sched_credit2_domain_set(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit2 *sdom);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16: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 1S0Esl-0006vr-0s; Wed, 22 Feb 2012 16:17:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esj-0006sU-D6
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 22 Feb 2012 16:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974187"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-08;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: b5d446a3450824e737ad8299ed81cfd7b54598e3
Message-ID: <b5d446a3450824e737ad.1329927311@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:11 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 9] libxc: Implement SCHEDOP sysctl for
	credit scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 0b230c5ac8b7 -r b5d446a34508 tools/libxc/xc_csched.c
--- a/tools/libxc/xc_csched.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxc/xc_csched.c	Wed Feb 22 16:08:28 2012 +0000
@@ -61,3 +61,47 @@ xc_sched_credit_domain_get(
 
     return err;
 }
+
+int
+xc_sched_credit_params_set(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
+
+    sysctl.u.scheduler_op.u.sched_credit = *schedule;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
+
+int
+xc_sched_credit_params_get(
+    xc_interface *xch,
+    uint32_t cpupool_id,
+    struct xen_sysctl_credit_schedule *schedule)
+{
+    int rc;
+    DECLARE_SYSCTL;
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo;
+
+    rc = do_sysctl(xch, &sysctl);
+
+    *schedule = sysctl.u.scheduler_op.u.sched_credit;
+
+    return rc;
+}
diff -r 0b230c5ac8b7 -r b5d446a34508 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxc/xenctrl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -668,7 +668,12 @@ int xc_sched_credit_domain_set(xc_interf
 int xc_sched_credit_domain_get(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit *sdom);
-
+int xc_sched_credit_params_set(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
+int xc_sched_credit_params_get(xc_interface *xch,
+                              uint32_t cpupool_id,
+                              struct xen_sysctl_credit_schedule *schedule);
 int xc_sched_credit2_domain_set(xc_interface *xch,
                                uint32_t domid,
                                struct xen_domctl_sched_credit2 *sdom);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Esm-0006wV-EZ; Wed, 22 Feb 2012 16:17:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esk-0006tF-G4
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13850 invoked from network); 22 Feb 2012 16:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974188"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-15;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: acbe35e4fb4a9db1b9dd2b932906d87ba36255a1
Message-ID: <acbe35e4fb4a9db1b9dd.1329927313@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 7 of 9] libxl: Implement
	libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement functions to set credit scheduler global parameters.

v2:
 - Use "params" rather than "param"
 - Fix long lines

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r af02b1ea16da -r acbe35e4fb4a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -3034,6 +3034,67 @@ int libxl_sched_credit_domain_set(libxl_
     return 0;
 }
 
+int libxl_sched_credit_params_get(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc;
+
+    rc = xc_sched_credit_params_get(ctx->xch, poolid, &sparam);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
+int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc=0;
+
+    if (scinfo->tslice_ms <  XEN_SYSCTL_CSCHED_TSLICE_MIN
+        || scinfo->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Time slice out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_CSCHED_TSLICE_MIN,
+                            XEN_SYSCTL_CSCHED_TSLICE_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us <  XEN_SYSCTL_SCHED_RATELIMIT_MIN
+        || scinfo->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Ratelimit out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+                            XEN_SYSCTL_SCHED_RATELIMIT_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us > scinfo->tslice_ms*1000) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "Ratelimit cannot be greater than timeslice\n");
+        return ERROR_INVAL;
+    }
+
+    sparam.tslice_ms = scinfo->tslice_ms;
+    sparam.ratelimit_us = scinfo->ratelimit_us;
+
+    rc = xc_sched_credit_params_set(ctx->xch, poolid, &sparam);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo)
 {
diff -r af02b1ea16da -r acbe35e4fb4a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -591,6 +591,10 @@ int libxl_sched_credit_domain_get(libxl_
                                   libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
                                   libxl_sched_credit_domain *scinfo);
+int libxl_sched_credit_params_get(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo);
+int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
diff -r af02b1ea16da -r acbe35e4fb4a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
@@ -395,6 +395,11 @@ libxl_sched_credit_domain = Struct("sche
     ("cap", integer),
     ], dispose_fn=None)
 
+libxl_sched_credit_params = Struct("sched_credit_params", [
+    ("tslice_ms", integer),
+    ("ratelimit_us", integer),
+    ], dispose_fn=None)
+
 libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Esm-0006wV-EZ; Wed, 22 Feb 2012 16:17:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0Esk-0006tF-G4
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:17:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329927439!15405089!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjczNjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13850 invoked from network); 22 Feb 2012 16:17:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:17:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,464,1325480400"; d="scan'208";a="182974188"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 11:16:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 22 Feb 2012 11:16:54 -0500
Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0EsA-00060o-15;
	Wed, 22 Feb 2012 16:16:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: acbe35e4fb4a9db1b9dd2b932906d87ba36255a1
Message-ID: <acbe35e4fb4a9db1b9dd.1329927313@kodo2>
In-Reply-To: <patchbomb.1329927306@kodo2>
References: <patchbomb.1329927306@kodo2>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 16:15:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 7 of 9] libxl: Implement
	libxl_sched_credit_param_[gs]et
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement functions to set credit scheduler global parameters.

v2:
 - Use "params" rather than "param"
 - Fix long lines

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r af02b1ea16da -r acbe35e4fb4a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Feb 22 16:08:28 2012 +0000
@@ -3034,6 +3034,67 @@ int libxl_sched_credit_domain_set(libxl_
     return 0;
 }
 
+int libxl_sched_credit_params_get(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc;
+
+    rc = xc_sched_credit_params_get(ctx->xch, poolid, &sparam);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
+int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo)
+{
+    struct xen_sysctl_credit_schedule sparam;
+    int rc=0;
+
+    if (scinfo->tslice_ms <  XEN_SYSCTL_CSCHED_TSLICE_MIN
+        || scinfo->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Time slice out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_CSCHED_TSLICE_MIN,
+                            XEN_SYSCTL_CSCHED_TSLICE_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us <  XEN_SYSCTL_SCHED_RATELIMIT_MIN
+        || scinfo->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+            "Ratelimit out of range, valid range is from %d to %d",
+                            XEN_SYSCTL_SCHED_RATELIMIT_MIN,
+                            XEN_SYSCTL_SCHED_RATELIMIT_MAX);
+        return ERROR_INVAL;
+    }
+    if (scinfo->ratelimit_us > scinfo->tslice_ms*1000) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "Ratelimit cannot be greater than timeslice\n");
+        return ERROR_INVAL;
+    }
+
+    sparam.tslice_ms = scinfo->tslice_ms;
+    sparam.ratelimit_us = scinfo->ratelimit_us;
+
+    rc = xc_sched_credit_params_set(ctx->xch, poolid, &sparam);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting sched credit param");
+        return ERROR_FAIL;
+    }
+
+    scinfo->tslice_ms = sparam.tslice_ms;
+    scinfo->ratelimit_us = sparam.ratelimit_us;
+
+    return 0;
+}
+
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo)
 {
diff -r af02b1ea16da -r acbe35e4fb4a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Feb 22 16:08:28 2012 +0000
@@ -591,6 +591,10 @@ int libxl_sched_credit_domain_get(libxl_
                                   libxl_sched_credit_domain *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
                                   libxl_sched_credit_domain *scinfo);
+int libxl_sched_credit_params_get(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo);
+int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
+                                  libxl_sched_credit_params *scinfo);
 int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2_domain *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
diff -r af02b1ea16da -r acbe35e4fb4a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 22 16:08:28 2012 +0000
@@ -395,6 +395,11 @@ libxl_sched_credit_domain = Struct("sche
     ("cap", integer),
     ], dispose_fn=None)
 
+libxl_sched_credit_params = Struct("sched_credit_params", [
+    ("tslice_ms", integer),
+    ("ratelimit_us", integer),
+    ], dispose_fn=None)
+
 libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
     ("weight", integer),
     ], dispose_fn=None)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:24:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0EzZ-0008Op-Ki; Wed, 22 Feb 2012 16:24:33 +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 1S0EzX-0008Ob-PF
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:24:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329927842!54004268!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTA4Mjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTA4Mjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1769 invoked from network); 22 Feb 2012 16:24:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Feb 2012 16:24:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329927867; l=1270;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ie9zgXoQ282OwRtYiXrybKeANQI=;
	b=rfdHG2QP8BQD1QkKhoHPH0xjRkN1qoct4ILI0Fz0EOaU2TIFP5/Z1TMVrPKYmuL4+Kn
	ietgzov3f1rVGNLhSWQf4h0bUCOTjIoHASIq4TNjuaKLUxUqszFBgAGIaxGaDOucnJ8s3
	qGCCw21swf7PcPRyrYnjdrDUL0Ymo+6Py8I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69v6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-13.vodafone-net.de [80.226.24.13])
	by smtp.strato.de (klopstock mo4) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h00fa6o1MEiHTx
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 17:24:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 00F0318635
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 17:24:21 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2d1ac43212fa31cedda2b8e4ed90bea1d63d229b
Message-Id: <2d1ac43212fa31cedda2.1329927860@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 22 Feb 2012 17:24:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/xenstore: workaround make 3.82 dependency
	flaw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329927731 -3600
# Node ID 2d1ac43212fa31cedda2b8e4ed90bea1d63d229b
# Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
tools/xenstore: workaround make 3.82 dependency flaw

After changeset 24767:28300f4562de build sometimes fails when make v3.82
as shipped with openSuSE 11.4/12.1 is used.

Add a workaround until the reason for the changed dependency handling in
make v3.82 is known.

The failure is a link error because the required libxenstore.so is not
created before init-xenstore-domain is about to be linked. All required
dependencies are listed, but they are ignored. So far the only way to
hide the error is to list init-xenstore-domain first in ALL_TARGETS.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0900b1c905f1 -r 2d1ac43212fa tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -27,7 +27,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
+ALL_TARGETS = init-xenstore-domain libxenstore.a libxenstore.so clients xs_tdb_dump xenstored
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:24:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:24:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0EzZ-0008Op-Ki; Wed, 22 Feb 2012 16:24:33 +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 1S0EzX-0008Ob-PF
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:24:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329927842!54004268!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTA4Mjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNTA4Mjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1769 invoked from network); 22 Feb 2012 16:24:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Feb 2012 16:24:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1329927867; l=1270;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ie9zgXoQ282OwRtYiXrybKeANQI=;
	b=rfdHG2QP8BQD1QkKhoHPH0xjRkN1qoct4ILI0Fz0EOaU2TIFP5/Z1TMVrPKYmuL4+Kn
	ietgzov3f1rVGNLhSWQf4h0bUCOTjIoHASIq4TNjuaKLUxUqszFBgAGIaxGaDOucnJ8s3
	qGCCw21swf7PcPRyrYnjdrDUL0Ymo+6Py8I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69v6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-13.vodafone-net.de [80.226.24.13])
	by smtp.strato.de (klopstock mo4) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h00fa6o1MEiHTx
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 17:24:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 00F0318635
	for <xen-devel@lists.xensource.com>;
	Wed, 22 Feb 2012 17:24:21 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2d1ac43212fa31cedda2b8e4ed90bea1d63d229b
Message-Id: <2d1ac43212fa31cedda2.1329927860@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 22 Feb 2012 17:24:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/xenstore: workaround make 3.82 dependency
	flaw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1329927731 -3600
# Node ID 2d1ac43212fa31cedda2b8e4ed90bea1d63d229b
# Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
tools/xenstore: workaround make 3.82 dependency flaw

After changeset 24767:28300f4562de build sometimes fails when make v3.82
as shipped with openSuSE 11.4/12.1 is used.

Add a workaround until the reason for the changed dependency handling in
make v3.82 is known.

The failure is a link error because the required libxenstore.so is not
created before init-xenstore-domain is about to be linked. All required
dependencies are listed, but they are ignored. So far the only way to
hide the error is to list init-xenstore-domain first in ALL_TARGETS.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0900b1c905f1 -r 2d1ac43212fa tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -27,7 +27,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
+ALL_TARGETS = init-xenstore-domain libxenstore.a libxenstore.so clients xs_tdb_dump xenstored
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:56:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0FUN-0000Ig-FZ; Wed, 22 Feb 2012 16:56:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0FUL-0000Ib-Hy
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:56:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329929774!14463447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28146 invoked from network); 22 Feb 2012 16:56:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:56:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10878791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 16:55:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 16:55:29 +0000
Date: Wed, 22 Feb 2012 17:01:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1329924493728-5505409.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
References: <1329924493728-5505409.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
 Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 22 Feb 2012, Fantu wrote:
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> And also this change for lib patch modified with multiarch support:
> vi config/StdGNU.mk
> LIBLEAFDIR_x86_64 ?= lib
> 
> DomUs PV working, domUs with qemu-upstream not start.
> 
> The xl configuration file:
> ---------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/sr0,raw,hdb,ro,cdrom']
> boot='c'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #stdvga=1
> #videoram=16
> sdl=0
> #spice=1
> #spicehost='192.168.1.137'
> #spiceport=6000
> #spicepasswd='test'
> #on_crash='preserve'
> ---------------------------------
> 
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
> during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> The same with change only device_model_version to qemu-xen-traditional work
> 
> 
> If you need more test and data ask me and I will do and post.
> Thanks for any reply and sorry for bad english.

Please post your qemu log file (/var/log/xen/qemu-dm-PRECISEHVM.log

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 16:56:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 16:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0FUN-0000Ig-FZ; Wed, 22 Feb 2012 16:56:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0FUL-0000Ib-Hy
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 16:56:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329929774!14463447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28146 invoked from network); 22 Feb 2012 16:56:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 16:56:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10878791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 16:55:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 16:55:29 +0000
Date: Wed, 22 Feb 2012 17:01:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1329924493728-5505409.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
References: <1329924493728-5505409.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
 Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 22 Feb 2012, Fantu wrote:
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> And also this change for lib patch modified with multiarch support:
> vi config/StdGNU.mk
> LIBLEAFDIR_x86_64 ?= lib
> 
> DomUs PV working, domUs with qemu-upstream not start.
> 
> The xl configuration file:
> ---------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/sr0,raw,hdb,ro,cdrom']
> boot='c'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #stdvga=1
> #videoram=16
> sdl=0
> #spice=1
> #spicehost='192.168.1.137'
> #spiceport=6000
> #spicepasswd='test'
> #on_crash='preserve'
> ---------------------------------
> 
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died
> during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> The same with change only device_model_version to qemu-xen-traditional work
> 
> 
> If you need more test and data ask me and I will do and post.
> Thanks for any reply and sorry for bad english.

Please post your qemu log file (/var/log/xen/qemu-dm-PRECISEHVM.log

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 17:03:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 17:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Fb0-0000ao-Am; Wed, 22 Feb 2012 17:03:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S0Faz-0000aa-8P
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 17:03:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329930185!12627582!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM2MDQw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 22 Feb 2012 17:03:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-174.messagelabs.com with SMTP;
	22 Feb 2012 17:03:06 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 22 Feb 2012 09:03:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="69136193"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Feb 2012 09:03:03 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 01:03:02 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 01:03:01 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 01:03:00 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "lenb@kernel.org"
	<lenb@kernel.org>, "Brown, Len" <len.brown@intel.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM8KTtqETlTTaR00eoPTQ1GukvM5ZJIhXg
Date: Wed, 22 Feb 2012 17:02:59 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
	<20120221142724.GB5652@phenom.dumpdata.com>
In-Reply-To: <20120221142724.GB5652@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>>>>> +struct pv_pad_ops {
>>>>>>> +	int (*acpi_pad_init)(void);
>>>>>>> +	void (*acpi_pad_exit)(void);
>>>>>>> +};
>>>>>>> +
>>>>> 
>>>>> Looking at this a bit closer I am not sure why you choose the
>>>>> paravirt interface for this? There is another one - the x86 that
>>>>> could have been choosen. Or introduce a new one that is specific
>>>>> to ACPI. 
>>>>> 
>>>>> I am curious - what was the reason for using the paravirt
>>>>> interface? I understand it does get the job done, but it seems a
>>>>> bit overkill when something simple could have been used?
>>>>> 
>>>> 
>>>> It uses paravirt interface to avoid some code like 'xen_...' in
>>>> native code path (acpi_pad.c).
>>>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
>>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>>>> seems it's much simpler.
>>> 
>>> arch/x86/include/asm/x86_init.h
>>> 
>>> But before you go that way let me ask you another question - can
>>> ACPI PAD be used on ARM or IA64? If so, wouldn't this fail
>>> compilation as this pvops structure is not defined on IA64?
>> 
>> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
>> at least on IA64 (through currently no real PAD on IA64 platform as
>> far as I know). However, in native acpi_pad implementation, it
>> indeed depends on X86 for reason like mwait.  
>> So for xen acpi_pad, I think it's OK to choose x86, defining an
>> acpi_pad_ops at x86_init.c which would be overwritten when xen init. 
> 
> OK, or in osl.c. We need Len to chime in here as I can see this
> expanding in the future. 
>> 
>> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
>> 'bool', which would disable native acpi_pad module. 
> 
> Ewww. No.

I'm OK with x86_init approach, but advantage of 'config ACPI_PROCESSOR_AGGREGATOR as bool' would get rid of X86/IA64/... arch issue for xen (at least from coding view), through it need disable native acpi_pad module (IMO acpi_pad module has not strong reason to must be so).
Have a re-consider of this approach? :-)

Thanks,
Jinsong

>> 
>> Your opinion?
>> 
>> Thanks,
>> Jinsong
>> 
>>> 
>>> The other thing I am not comfortable about is that the pvops
>>> structure are used for low-level code. Not for higher up, like
>>> ACPI. For that another structure seems more prudent. Perhaps
>>> something like the x86 one, but specific to ACPI?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 17:03:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 17:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Fb0-0000ao-Am; Wed, 22 Feb 2012 17:03:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S0Faz-0000aa-8P
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 17:03:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1329930185!12627582!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM2MDQw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 22 Feb 2012 17:03:06 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-174.messagelabs.com with SMTP;
	22 Feb 2012 17:03:06 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 22 Feb 2012 09:03:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="69136193"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by AZSMGA002.ch.intel.com with ESMTP; 22 Feb 2012 09:03:03 -0800
Received: from pgsmsx151.gar.corp.intel.com (172.30.236.41) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 01:03:02 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 01:03:01 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 01:03:00 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "lenb@kernel.org"
	<lenb@kernel.org>, "Brown, Len" <len.brown@intel.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM8KTtqETlTTaR00eoPTQ1GukvM5ZJIhXg
Date: Wed, 22 Feb 2012 17:02:59 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
	<20120221142724.GB5652@phenom.dumpdata.com>
In-Reply-To: <20120221142724.GB5652@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>>>>> +struct pv_pad_ops {
>>>>>>> +	int (*acpi_pad_init)(void);
>>>>>>> +	void (*acpi_pad_exit)(void);
>>>>>>> +};
>>>>>>> +
>>>>> 
>>>>> Looking at this a bit closer I am not sure why you choose the
>>>>> paravirt interface for this? There is another one - the x86 that
>>>>> could have been choosen. Or introduce a new one that is specific
>>>>> to ACPI. 
>>>>> 
>>>>> I am curious - what was the reason for using the paravirt
>>>>> interface? I understand it does get the job done, but it seems a
>>>>> bit overkill when something simple could have been used?
>>>>> 
>>>> 
>>>> It uses paravirt interface to avoid some code like 'xen_...' in
>>>> native code path (acpi_pad.c).
>>>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
>>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>>>> seems it's much simpler.
>>> 
>>> arch/x86/include/asm/x86_init.h
>>> 
>>> But before you go that way let me ask you another question - can
>>> ACPI PAD be used on ARM or IA64? If so, wouldn't this fail
>>> compilation as this pvops structure is not defined on IA64?
>> 
>> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
>> at least on IA64 (through currently no real PAD on IA64 platform as
>> far as I know). However, in native acpi_pad implementation, it
>> indeed depends on X86 for reason like mwait.  
>> So for xen acpi_pad, I think it's OK to choose x86, defining an
>> acpi_pad_ops at x86_init.c which would be overwritten when xen init. 
> 
> OK, or in osl.c. We need Len to chime in here as I can see this
> expanding in the future. 
>> 
>> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
>> 'bool', which would disable native acpi_pad module. 
> 
> Ewww. No.

I'm OK with x86_init approach, but advantage of 'config ACPI_PROCESSOR_AGGREGATOR as bool' would get rid of X86/IA64/... arch issue for xen (at least from coding view), through it need disable native acpi_pad module (IMO acpi_pad module has not strong reason to must be so).
Have a re-consider of this approach? :-)

Thanks,
Jinsong

>> 
>> Your opinion?
>> 
>> Thanks,
>> Jinsong
>> 
>>> 
>>> The other thing I am not comfortable about is that the pvops
>>> structure are used for low-level code. Not for higher up, like
>>> ACPI. For that another structure seems more prudent. Perhaps
>>> something like the x86 one, but specific to ACPI?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 18:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 18: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 1S0Gia-0002Hi-KI; Wed, 22 Feb 2012 18:15: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 1S0GiY-0002Hc-Jq
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 18:15:06 +0000
Received: from [85.158.139.83:26785] by server-1.bemta-5.messagelabs.com id
	E2/D7-28458-9A0354F4; Wed, 22 Feb 2012 18:15:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329934503!16135188!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1OTY1MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5751 invoked from network); 22 Feb 2012 18:15:05 -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; 22 Feb 2012 18:15:05 -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 q1MIF1go024956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 18:15: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
	q1MIF063021421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 18:15:01 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
	q1MIF0sJ030178; Wed, 22 Feb 2012 12:15:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 10:15:00 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C85AA4047A; Wed, 22 Feb 2012 13:11:43 -0500 (EST)
Date: Wed, 22 Feb 2012 13:11:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120222181143.GD3132@phenom.dumpdata.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
	<20120221165830.GA32413@phenom.dumpdata.com>
	<CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F4530A6.0048,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBGZWIgMjIsIDIwMTIgYXQgMDM6MTc6MjRQTSArMDMwMCwgQW50b24gU2Ftc29ub3Yg
d3JvdGU6Cj4gMjAxMi8yLzIxIEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT46Cj4gCj4gQVM+PiBXaXRoIGN1c3RvbS1idWlsdCBrZXJuZWwsIEkgZGlkbid0IHll
dCBzZWUgYW55IEdQRiwgYnV0IHNjcmVlbiBnYXJibGluZwo+IEFTPj4gaGFwcGVucyBhbG1vc3Qg
ZXZlcnkgdGltZSB3aGVuIGEgRG9tVSBpcyBzdGFydGluZyBvciBzdG9wcGluZzoKPiBBUz4+IHRo
ZSB3aG9sZSBncmFwaGljYWwgaXMgcGFpbnRlZCB3aXRoIGVpdGhlciBibGFjayBvciBub3Qtc28t
cmFuZG9tIGdhcmJhZ2UuCj4gCj4gS1JXPiBTby4uLiBJIGFtIGN1cmlvdXMsIHdoYXQgZ3JhcGhp
YyBjYXJkIGRvIHlvdSBoYXZlIGFuZCBkbyB5b3UgZ2V0IGFueSBvZgo+IEtSVz4gdGhlc2UgUmVk
IEhhdCBCWnM/IMKgUkggQlojIDc0MjAzMiwgNzg3NDAzLCBhbmQgNzQ1NTc0Pwo+IEtSVz4gVGhl
cmUgaXMgYSBidWcgaW4gMy4yIHdoZW4gdXNpbmcgcmFkZW9uIG9yIG5vdXZlYXUgZm9yIGEgbGVu
Z3RoeSB0aW1lCj4gS1JXPiB0aGF0IGVuZHMgdXAgImNvcnJ1cHRpbmciIG1lbW9yeS4gVGhlIHdv
cmthcm91bmQgaXMgJ25vcGF0JyBrZXJuZWwgYXJnLgo+IAo+IE15IGlkZWEgaXMgdGhhdCBteSBj
dXN0b20tYnVpbHQga2VybmVsIGNhbid0IGJlIGNvbnNpZGVyZWQgYSB0cnVzdGVkCj4gcHJvdmlu
ZyBncm91bmQsCj4gYXMgaXQgaXMgb2YgdmVyeSBsb3cgcXVhbGl0eS4gVmlkZW8gaXNzdWUgaXMg
anVzdCB0aGUgbW9zdCBvYnZpb3VzCj4gZXhhbXBsZS4gQW5vdGhlcgo+IGluZGlzcHV0YWJsZSBl
eGFtcGxlIGlzIGhvdyB0aGUgRG9tMCByZWJvb3RzOiBpbnN0ZWFkIG9mIHNpbXBsZSBDUFUgcmVz
dGFydCwKPiB0aGUgd2hvbGUgc3lzdGVtIGdvZXMgaW50byBzb2Z0LW9mZiBmb3Igc2V2ZXJhbCBz
ZWNvbmRzLCB0aGVuIHdha2VzIGJhY2suCj4gV2hlbiBJIGJvb3QgdGhpcyBrZXJuZWwgaW4gYmFy
ZS1tZXRhbCBtb2RlICh3aXRob3V0IFhlbiBWTU0pLCBub25lIG9mIHRob3NlCj4gaGFwcGVuczog
R1VJIGlzIGFjY2VsZXJhdGVkIChhdCBsZWFzdCBpbiAyRDsgSSBkb24ndCB1c2UgT3BlbkdMIGRl
c2t0b3ApLAo+IHNjcmVlbiBpcyBub3QgZ2FyYmxlZCBhdCBsb2dpbiBhbmQgbG9nb3V0IGRpYWxv
Z3MsIHN5c3RlbSByZWJvb3RzIHF1aWNrbHkuCj4gCj4gQW55d2F5LCBJIHRyaWVkIHlvdXIgc29s
dXRpb24gd2l0aCAibm9wYXQiLiBJdCBkaWRuJ3Qgd29ya2VkOiB3aXRoIDQKPiBEb21VcyBydW5u
aW5nCj4gZm9yIGEgbWludXRlIGFuZCB0aGVuIHNodXQgZG93biBpbiByZXZlcnNlIG9yZGVyICg0
dGgsIDNyZCwgMm5kLCAxc3QpLAo+IHRoZSBzY3JlZW4KPiB3ZW50IGJsYWNrIHJpZ2h0IGJldHdl
ZW4gdGhlIDNyZCBWTSB3YXMgY29tcGxldGVseSBzaHV0IGFuZCAybmQgVk0gd2FzCj4gcmVxdWVz
dGVkIHRvIHNodXQuIFRoZXJlIHdhcyBubyAibGVuZ3RoeSB0aW1lIiBvZiBEb20wIHJ1bm5pbmcs
IG15IHZpZGVvIGFkYXB0ZXIKPiBpcyBuZWl0aGVyIG5WaWRpYSBub3IgQVRpLCBidXQgYW4gaW50
ZWdyYXRlZCBJbnRlbCBIRCBHcmFwaGljcyAyMDAwCj4gdXNpbmcgaTkxNSBkcml2ZXIsCj4gYW5k
IEkgc2VlIG5vIHNpbWlsYXJpdGllcyB0byB0aGUgUmVkIEhhdCBidWdzIG1lbnRpb25lZCBieSB5
b3UuCj4gCj4gCj4gS1JXPiBDYW4geW91IGluY2x1ZGUgbW9yZSBkZXRhaWxzIG9uIHlvdXIgbWFj
aGluZT8KPiAKPiBNeSBndWVzcyBpcyB0aGF0IGl0IGlzIG5vdCBqdXN0IG15IGhhcmR3YXJlIHRo
YXQgY2F1c2VzIEdQRiwgYnV0IGVpdGhlcgo+IGEgYnVnIGluIG5ldGJhY2sgbW9kdWxlLCBvciBh
IGNvbXBpbGVyIGlzc3VlIGZvciBzcGVjaWZpYyBjb21iaW5hdGlvbiBvZiBYZW4KPiAoYW5kL29y
IHBhcnRpY3VsYXJseSBuZXRiYWNrKSB0b2dldGhlciB3aXRoIG9wZW5TVVNFIGJ1aWxkIHRlY2hu
b2xvZ3kuCj4gCj4gQXMgYW4gZXhhbXBsZSBvZiB0aGUgbGF0dGVyLCBsb29rIGFnYWluIGF0IHRo
ZSBOb3ZlbGwgQlogIzcyNzA4MSBtZW50aW9uZWQKPiBpbiB0aGUgb3JpZ2luYWwgcG9zdCDigJQg
dGhlIGNvbW1lbnQgIzMwIHNheXM6ICJUaGUgY29tcGlsZXIgYXBwYXJlbnRseSBtYWtlcyB1c2UK
PiBvZiB0aGUgMTI4LWJ5dGUgYXJlYSBjYWxsZWQgJ3JlZCB6b25lJyBpbiB0aGUgQUJJLCBhbmQg
dGhpcyBpcyBpbmNvbXBhdGlibGUKPiB3aXRoIHhjX2NwdWlkX3g4Ni5jOmNwdWlkKCkgdXNpbmcg
cHVzaGVzIGFuZCBwb3BzIGFyb3VuZCB0aGUgY3B1aWQgaW5zdHJ1Y3Rpb24iLgo+IFRoZSBjb25z
ZXF1ZW5jZSBpcyB0aGF0LCBvbiBzb21lIG1hY2hpbmVzLCBsaWJ4ZW5ndWVzdCBzZWdmYXVsdHMg
d2hlbiB5b3UKPiB0cnkgdG8gc3RhcnQgYSBEb21VLiBXaXRoIENvcmUgaTctOTIwIHRoZXJlIGlz
IG5vIHByb2JsZW0sIGJ1dCB3aXRoIENvcmUgaTUtMjMwMAo+IEkgZmFjZWQgdGhhdCBpc3N1ZSwg
YW5kIHdvbmRlciB3aGV0aGVyIHRoZSBzYW1lIGluY29tcGF0aWJpbGl0eSBjYW4gdGFrZSBwbGFj
ZQo+IGluIG5ldGJhY2sgbW9kdWxlLiBJIHRob3VnaCB0aGUgdHJhY2ViYWNrIGdpdmVzIHNvbWUg
aGludHMgb24gd2hlcmUgdG8gZGVidWcuCj4gCj4gTXkgc3BlY3MgYXJlOgo+IE1COiBBc3VzIFA4
SDY3LU0gKEludGVsIEg2NyBjaGlwc2V0KQo+IENQVTogSW50ZWwgQ29yZSBpNSBtb2RlbCAyMzAw
IChUdXJibyBtb2RlIGRpc2FibGVkKQo+IFJBTTogMTJHQiBERFIzLTEzMzMgbm9uLUVDQyAocmVj
ZW50bHkgY2hlY2tlZCBieSBNZW1UZXN0ODYrIDQuMjApCgpEbyB5b3UgaGF2ZSBDT05GSUdfRE1B
UiBlbmFibGVkIGluIHlvdXIgY29uZmlnPwoKPiBWaWRlbzogSW50ZWwgSEQgR3JhcGhpY3MgMjAw
MCAoaW50ZWdyYXRlZCBpbnRvIENQVSkKPiBOZXR3b3JrOiBkZWRpY2F0ZWQgc29mdC1icmlkZ2Ug
Zm9yIG1vc3QgRG9tVXMsCj4gICsgYnJpZGdlZCBSZWFsdGVrIFJUTDgxMTFFIGZvciBnYXRld2F5
IERvbVUgKG5vdCB3aXRoIENBUlApCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 18:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 18: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 1S0Gia-0002Hi-KI; Wed, 22 Feb 2012 18:15: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 1S0GiY-0002Hc-Jq
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 18:15:06 +0000
Received: from [85.158.139.83:26785] by server-1.bemta-5.messagelabs.com id
	E2/D7-28458-9A0354F4; Wed, 22 Feb 2012 18:15:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1329934503!16135188!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1OTY1MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5751 invoked from network); 22 Feb 2012 18:15:05 -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; 22 Feb 2012 18:15:05 -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 q1MIF1go024956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 18:15: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
	q1MIF063021421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 18:15:01 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
	q1MIF0sJ030178; Wed, 22 Feb 2012 12:15:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 10:15:00 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C85AA4047A; Wed, 22 Feb 2012 13:11:43 -0500 (EST)
Date: Wed, 22 Feb 2012 13:11:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anton Samsonov <avscomputing@gmail.com>
Message-ID: <20120222181143.GD3132@phenom.dumpdata.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
	<20120221165830.GA32413@phenom.dumpdata.com>
	<CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F4530A6.0048,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCBGZWIgMjIsIDIwMTIgYXQgMDM6MTc6MjRQTSArMDMwMCwgQW50b24gU2Ftc29ub3Yg
d3JvdGU6Cj4gMjAxMi8yLzIxIEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT46Cj4gCj4gQVM+PiBXaXRoIGN1c3RvbS1idWlsdCBrZXJuZWwsIEkgZGlkbid0IHll
dCBzZWUgYW55IEdQRiwgYnV0IHNjcmVlbiBnYXJibGluZwo+IEFTPj4gaGFwcGVucyBhbG1vc3Qg
ZXZlcnkgdGltZSB3aGVuIGEgRG9tVSBpcyBzdGFydGluZyBvciBzdG9wcGluZzoKPiBBUz4+IHRo
ZSB3aG9sZSBncmFwaGljYWwgaXMgcGFpbnRlZCB3aXRoIGVpdGhlciBibGFjayBvciBub3Qtc28t
cmFuZG9tIGdhcmJhZ2UuCj4gCj4gS1JXPiBTby4uLiBJIGFtIGN1cmlvdXMsIHdoYXQgZ3JhcGhp
YyBjYXJkIGRvIHlvdSBoYXZlIGFuZCBkbyB5b3UgZ2V0IGFueSBvZgo+IEtSVz4gdGhlc2UgUmVk
IEhhdCBCWnM/IMKgUkggQlojIDc0MjAzMiwgNzg3NDAzLCBhbmQgNzQ1NTc0Pwo+IEtSVz4gVGhl
cmUgaXMgYSBidWcgaW4gMy4yIHdoZW4gdXNpbmcgcmFkZW9uIG9yIG5vdXZlYXUgZm9yIGEgbGVu
Z3RoeSB0aW1lCj4gS1JXPiB0aGF0IGVuZHMgdXAgImNvcnJ1cHRpbmciIG1lbW9yeS4gVGhlIHdv
cmthcm91bmQgaXMgJ25vcGF0JyBrZXJuZWwgYXJnLgo+IAo+IE15IGlkZWEgaXMgdGhhdCBteSBj
dXN0b20tYnVpbHQga2VybmVsIGNhbid0IGJlIGNvbnNpZGVyZWQgYSB0cnVzdGVkCj4gcHJvdmlu
ZyBncm91bmQsCj4gYXMgaXQgaXMgb2YgdmVyeSBsb3cgcXVhbGl0eS4gVmlkZW8gaXNzdWUgaXMg
anVzdCB0aGUgbW9zdCBvYnZpb3VzCj4gZXhhbXBsZS4gQW5vdGhlcgo+IGluZGlzcHV0YWJsZSBl
eGFtcGxlIGlzIGhvdyB0aGUgRG9tMCByZWJvb3RzOiBpbnN0ZWFkIG9mIHNpbXBsZSBDUFUgcmVz
dGFydCwKPiB0aGUgd2hvbGUgc3lzdGVtIGdvZXMgaW50byBzb2Z0LW9mZiBmb3Igc2V2ZXJhbCBz
ZWNvbmRzLCB0aGVuIHdha2VzIGJhY2suCj4gV2hlbiBJIGJvb3QgdGhpcyBrZXJuZWwgaW4gYmFy
ZS1tZXRhbCBtb2RlICh3aXRob3V0IFhlbiBWTU0pLCBub25lIG9mIHRob3NlCj4gaGFwcGVuczog
R1VJIGlzIGFjY2VsZXJhdGVkIChhdCBsZWFzdCBpbiAyRDsgSSBkb24ndCB1c2UgT3BlbkdMIGRl
c2t0b3ApLAo+IHNjcmVlbiBpcyBub3QgZ2FyYmxlZCBhdCBsb2dpbiBhbmQgbG9nb3V0IGRpYWxv
Z3MsIHN5c3RlbSByZWJvb3RzIHF1aWNrbHkuCj4gCj4gQW55d2F5LCBJIHRyaWVkIHlvdXIgc29s
dXRpb24gd2l0aCAibm9wYXQiLiBJdCBkaWRuJ3Qgd29ya2VkOiB3aXRoIDQKPiBEb21VcyBydW5u
aW5nCj4gZm9yIGEgbWludXRlIGFuZCB0aGVuIHNodXQgZG93biBpbiByZXZlcnNlIG9yZGVyICg0
dGgsIDNyZCwgMm5kLCAxc3QpLAo+IHRoZSBzY3JlZW4KPiB3ZW50IGJsYWNrIHJpZ2h0IGJldHdl
ZW4gdGhlIDNyZCBWTSB3YXMgY29tcGxldGVseSBzaHV0IGFuZCAybmQgVk0gd2FzCj4gcmVxdWVz
dGVkIHRvIHNodXQuIFRoZXJlIHdhcyBubyAibGVuZ3RoeSB0aW1lIiBvZiBEb20wIHJ1bm5pbmcs
IG15IHZpZGVvIGFkYXB0ZXIKPiBpcyBuZWl0aGVyIG5WaWRpYSBub3IgQVRpLCBidXQgYW4gaW50
ZWdyYXRlZCBJbnRlbCBIRCBHcmFwaGljcyAyMDAwCj4gdXNpbmcgaTkxNSBkcml2ZXIsCj4gYW5k
IEkgc2VlIG5vIHNpbWlsYXJpdGllcyB0byB0aGUgUmVkIEhhdCBidWdzIG1lbnRpb25lZCBieSB5
b3UuCj4gCj4gCj4gS1JXPiBDYW4geW91IGluY2x1ZGUgbW9yZSBkZXRhaWxzIG9uIHlvdXIgbWFj
aGluZT8KPiAKPiBNeSBndWVzcyBpcyB0aGF0IGl0IGlzIG5vdCBqdXN0IG15IGhhcmR3YXJlIHRo
YXQgY2F1c2VzIEdQRiwgYnV0IGVpdGhlcgo+IGEgYnVnIGluIG5ldGJhY2sgbW9kdWxlLCBvciBh
IGNvbXBpbGVyIGlzc3VlIGZvciBzcGVjaWZpYyBjb21iaW5hdGlvbiBvZiBYZW4KPiAoYW5kL29y
IHBhcnRpY3VsYXJseSBuZXRiYWNrKSB0b2dldGhlciB3aXRoIG9wZW5TVVNFIGJ1aWxkIHRlY2hu
b2xvZ3kuCj4gCj4gQXMgYW4gZXhhbXBsZSBvZiB0aGUgbGF0dGVyLCBsb29rIGFnYWluIGF0IHRo
ZSBOb3ZlbGwgQlogIzcyNzA4MSBtZW50aW9uZWQKPiBpbiB0aGUgb3JpZ2luYWwgcG9zdCDigJQg
dGhlIGNvbW1lbnQgIzMwIHNheXM6ICJUaGUgY29tcGlsZXIgYXBwYXJlbnRseSBtYWtlcyB1c2UK
PiBvZiB0aGUgMTI4LWJ5dGUgYXJlYSBjYWxsZWQgJ3JlZCB6b25lJyBpbiB0aGUgQUJJLCBhbmQg
dGhpcyBpcyBpbmNvbXBhdGlibGUKPiB3aXRoIHhjX2NwdWlkX3g4Ni5jOmNwdWlkKCkgdXNpbmcg
cHVzaGVzIGFuZCBwb3BzIGFyb3VuZCB0aGUgY3B1aWQgaW5zdHJ1Y3Rpb24iLgo+IFRoZSBjb25z
ZXF1ZW5jZSBpcyB0aGF0LCBvbiBzb21lIG1hY2hpbmVzLCBsaWJ4ZW5ndWVzdCBzZWdmYXVsdHMg
d2hlbiB5b3UKPiB0cnkgdG8gc3RhcnQgYSBEb21VLiBXaXRoIENvcmUgaTctOTIwIHRoZXJlIGlz
IG5vIHByb2JsZW0sIGJ1dCB3aXRoIENvcmUgaTUtMjMwMAo+IEkgZmFjZWQgdGhhdCBpc3N1ZSwg
YW5kIHdvbmRlciB3aGV0aGVyIHRoZSBzYW1lIGluY29tcGF0aWJpbGl0eSBjYW4gdGFrZSBwbGFj
ZQo+IGluIG5ldGJhY2sgbW9kdWxlLiBJIHRob3VnaCB0aGUgdHJhY2ViYWNrIGdpdmVzIHNvbWUg
aGludHMgb24gd2hlcmUgdG8gZGVidWcuCj4gCj4gTXkgc3BlY3MgYXJlOgo+IE1COiBBc3VzIFA4
SDY3LU0gKEludGVsIEg2NyBjaGlwc2V0KQo+IENQVTogSW50ZWwgQ29yZSBpNSBtb2RlbCAyMzAw
IChUdXJibyBtb2RlIGRpc2FibGVkKQo+IFJBTTogMTJHQiBERFIzLTEzMzMgbm9uLUVDQyAocmVj
ZW50bHkgY2hlY2tlZCBieSBNZW1UZXN0ODYrIDQuMjApCgpEbyB5b3UgaGF2ZSBDT05GSUdfRE1B
UiBlbmFibGVkIGluIHlvdXIgY29uZmlnPwoKPiBWaWRlbzogSW50ZWwgSEQgR3JhcGhpY3MgMjAw
MCAoaW50ZWdyYXRlZCBpbnRvIENQVSkKPiBOZXR3b3JrOiBkZWRpY2F0ZWQgc29mdC1icmlkZ2Ug
Zm9yIG1vc3QgRG9tVXMsCj4gICsgYnJpZGdlZCBSZWFsdGVrIFJUTDgxMTFFIGZvciBnYXRld2F5
IERvbVUgKG5vdCB3aXRoIENBUlApCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 22 18:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 18: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 1S0Gtq-0002ju-3d; Wed, 22 Feb 2012 18:26:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0Gto-0002jp-JC
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 18:26:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329935196!14323714!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1OTY1MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 22 Feb 2012 18:26:38 -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; 22 Feb 2012 18:26: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 q1MIQUKp001644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 18:26: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
	q1MIQTMv000600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 18:26:29 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
	q1MIQSKN001928; Wed, 22 Feb 2012 12:26:28 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 10:26:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6D6A34047A; Wed, 22 Feb 2012 13:23:12 -0500 (EST)
Date: Wed, 22 Feb 2012 13:23:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120222182312.GE3132@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
	<20120221142724.GB5652@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F453358.0068,ss=1,re=0.000,fgs=0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 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 Wed, Feb 22, 2012 at 05:02:59PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>>>>>> +struct pv_pad_ops {
> >>>>>>> +	int (*acpi_pad_init)(void);
> >>>>>>> +	void (*acpi_pad_exit)(void);
> >>>>>>> +};
> >>>>>>> +
> >>>>> 
> >>>>> Looking at this a bit closer I am not sure why you choose the
> >>>>> paravirt interface for this? There is another one - the x86 that
> >>>>> could have been choosen. Or introduce a new one that is specific
> >>>>> to ACPI. 
> >>>>> 
> >>>>> I am curious - what was the reason for using the paravirt
> >>>>> interface? I understand it does get the job done, but it seems a
> >>>>> bit overkill when something simple could have been used?
> >>>>> 
> >>>> 
> >>>> It uses paravirt interface to avoid some code like 'xen_...' in
> >>>> native code path (acpi_pad.c).
> >>>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
> >>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
> >>>> seems it's much simpler.
> >>> 
> >>> arch/x86/include/asm/x86_init.h
> >>> 
> >>> But before you go that way let me ask you another question - can
> >>> ACPI PAD be used on ARM or IA64? If so, wouldn't this fail
> >>> compilation as this pvops structure is not defined on IA64?
> >> 
> >> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
> >> at least on IA64 (through currently no real PAD on IA64 platform as
> >> far as I know). However, in native acpi_pad implementation, it
> >> indeed depends on X86 for reason like mwait.  
> >> So for xen acpi_pad, I think it's OK to choose x86, defining an
> >> acpi_pad_ops at x86_init.c which would be overwritten when xen init. 
> > 
> > OK, or in osl.c. We need Len to chime in here as I can see this
> > expanding in the future. 
> >> 
> >> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
> >> 'bool', which would disable native acpi_pad module. 
> > 
> > Ewww. No.
> 
> I'm OK with x86_init approach, but advantage of 'config ACPI_PROCESSOR_AGGREGATOR as bool' would get rid of X86/IA64/... arch issue for xen (at least from coding view), through it need disable native acpi_pad module (IMO acpi_pad module has not strong reason to must be so).
> Have a re-consider of this approach? :-)

But it is a compile option right? We wantone kernel that can do both
baremetal and Xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 18:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 18: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 1S0Gtq-0002ju-3d; Wed, 22 Feb 2012 18:26:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0Gto-0002jp-JC
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 18:26:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329935196!14323714!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU1OTY1MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 22 Feb 2012 18:26:38 -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; 22 Feb 2012 18:26: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 q1MIQUKp001644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 22 Feb 2012 18:26: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
	q1MIQTMv000600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Feb 2012 18:26:29 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
	q1MIQSKN001928; Wed, 22 Feb 2012 12:26:28 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 22 Feb 2012 10:26:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6D6A34047A; Wed, 22 Feb 2012 13:23:12 -0500 (EST)
Date: Wed, 22 Feb 2012 13:23:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120222182312.GE3132@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
	<20120221142724.GB5652@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F453358.0068,ss=1,re=0.000,fgs=0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 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 Wed, Feb 22, 2012 at 05:02:59PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>>>>>> +struct pv_pad_ops {
> >>>>>>> +	int (*acpi_pad_init)(void);
> >>>>>>> +	void (*acpi_pad_exit)(void);
> >>>>>>> +};
> >>>>>>> +
> >>>>> 
> >>>>> Looking at this a bit closer I am not sure why you choose the
> >>>>> paravirt interface for this? There is another one - the x86 that
> >>>>> could have been choosen. Or introduce a new one that is specific
> >>>>> to ACPI. 
> >>>>> 
> >>>>> I am curious - what was the reason for using the paravirt
> >>>>> interface? I understand it does get the job done, but it seems a
> >>>>> bit overkill when something simple could have been used?
> >>>>> 
> >>>> 
> >>>> It uses paravirt interface to avoid some code like 'xen_...' in
> >>>> native code path (acpi_pad.c).
> >>>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
> >>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
> >>>> seems it's much simpler.
> >>> 
> >>> arch/x86/include/asm/x86_init.h
> >>> 
> >>> But before you go that way let me ask you another question - can
> >>> ACPI PAD be used on ARM or IA64? If so, wouldn't this fail
> >>> compilation as this pvops structure is not defined on IA64?
> >> 
> >> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
> >> at least on IA64 (through currently no real PAD on IA64 platform as
> >> far as I know). However, in native acpi_pad implementation, it
> >> indeed depends on X86 for reason like mwait.  
> >> So for xen acpi_pad, I think it's OK to choose x86, defining an
> >> acpi_pad_ops at x86_init.c which would be overwritten when xen init. 
> > 
> > OK, or in osl.c. We need Len to chime in here as I can see this
> > expanding in the future. 
> >> 
> >> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
> >> 'bool', which would disable native acpi_pad module. 
> > 
> > Ewww. No.
> 
> I'm OK with x86_init approach, but advantage of 'config ACPI_PROCESSOR_AGGREGATOR as bool' would get rid of X86/IA64/... arch issue for xen (at least from coding view), through it need disable native acpi_pad module (IMO acpi_pad module has not strong reason to must be so).
> Have a re-consider of this approach? :-)

But it is a compile option right? We wantone kernel that can do both
baremetal and Xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:21:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0HkO-0003Q9-3d; Wed, 22 Feb 2012 19:21:04 +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 1S0HkM-0003Ph-GK
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 19:21:02 +0000
Received: from [85.158.139.83:63764] by server-8.bemta-5.messagelabs.com id
	C4/B1-09797-D10454F4; Wed, 22 Feb 2012 19:21:01 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938460!13496058!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30926 invoked from network); 22 Feb 2012 19:21:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 19:20:34 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 19:20:34 +0000
MIME-Version: 1.0
X-Mercurial-Node: 032fea10f8d121fe7db01b33d93ba62c3272197c
Message-ID: <032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
In-Reply-To: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 19:17:13 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: gbtju85@gmail.com
Subject: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include OVMF
 UEFI support and directly use 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

when specified in the guest configuration file.
This work is somewhat based on Bei Guan effort during the SoC 2011 and
relies on upstream edk2/ovmf Tianocore ROM to be built separately and
manually copied as:
Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd -> tools/firmware/ovmf/ovmf-x64.bin
Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd -> toolf/firmware/ovmf/ovmf-ia32.bin

A way to integrate OVMF build directly into XEN has still be discussed
on the mailing list appropriately.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

diff -r a88ba599add1 -r 032fea10f8d1 Config.mk
--- a/Config.mk	Tue Feb 21 17:45:59 2012 +0000
+++ b/Config.mk	Wed Feb 22 18:54:03 2012 +0000
@@ -224,6 +224,7 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_OVMF ?= y
 CONFIG_ROMBIOS ?= y
 CONFIG_SEABIOS ?= y
 
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Tue Feb 21 17:45:59 2012 +0000
+++ b/tools/firmware/hvmloader/Makefile	Wed Feb 22 18:54:03 2012 +0000
@@ -37,6 +37,7 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
+OVMF_DIR := ../ovmf
 ROMBIOS_DIR := ../rombios
 SEABIOS_DIR := ../seabios-dir
 
@@ -52,6 +53,14 @@ endif
 
 ROMS := 
 
+ifeq ($(CONFIG_OVMF),y)
+OBJS += ovmf.o
+CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
+OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
+OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
+ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
+endif
+
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
@@ -70,7 +79,7 @@ endif
 all: subdirs-all
 	$(MAKE) hvmloader
 
-rombios.o seabios.o hvmloader.o: roms.inc
+ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -93,6 +102,18 @@ ifneq ($(SEABIOS_ROM),)
 	echo "#endif" >> $@.new
 endif
 
+ifneq ($(OVMF32_ROM),)
+	echo "#ifdef ROM_INCLUDE_OVMF32" >> $@.new
+	sh ./mkhex ovmf32 $(OVMF32_ROM) >> $@.new
+	echo "#endif" >> $@.new	
+endif 
+
+ifneq ($(OVMF64_ROM),)
+	echo "#ifdef ROM_INCLUDE_OVMF64" >> $@.new
+	sh ./mkhex ovmf64 $(OVMF64_ROM) >> $@.new
+	echo "#endif" >> $@.new	
+endif 
+
 ifneq ($(STDVGA_ROM),)
 	echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
 	sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
+++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
@@ -35,6 +35,8 @@ struct bios_config {
 
 extern struct bios_config rombios_config;
 extern struct bios_config seabios_config;
+extern struct bios_config ovmf32_config;
+extern struct bios_config ovmf64_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Tue Feb 21 17:45:59 2012 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Wed Feb 22 18:54:03 2012 +0000
@@ -212,6 +212,12 @@ struct bios_info {
 #ifdef ENABLE_SEABIOS
     { "seabios", &seabios_config, },
 #endif
+#ifdef ENABLE_OVMF32
+    { "ovmf-ia32", &ovmf32_config, },
+#endif
+#ifdef ENABLE_OVMF64
+    { "ovmf-x64", &ovmf64_config, },
+#endif
     { NULL, NULL }
 };
 
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/ovmf.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ovmf.c	Wed Feb 22 18:54:03 2012 +0000
@@ -0,0 +1,147 @@
+/*
+ * HVM OVMF UEFI support.
+ *
+ * Bei Guan, gbtju85@gmail.com
+ * Andrei Warkentin, andreiw@motorola.com
+ * Leendert van Doorn, leendert@watson.ibm.com
+ * Copyright (c) 2005, International Business Machines Corporation.
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ * Copyright (c) 2011, Citrix Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include "config.h"
+#include "smbios_types.h"
+#include "acpi/acpi2_0.h"
+#include "apic_regs.h"
+#include "../rombios/config.h"
+#include "util.h"
+#include "pci_regs.h"
+#include "hypercall.h"
+
+#include <xen/hvm/params.h>
+#include <xen/hvm/ioreq.h>
+#include <xen/memory.h>
+
+#define ROM_INCLUDE_OVMF32
+#define ROM_INCLUDE_OVMF64
+#include "roms.inc"
+
+#define OVMF_BEGIN              0xFFF00000ULL
+#define OVMF_SIZE               0x00100000ULL
+#define OVMF_MAXOFFSET          0x000FFFFFULL
+#define OVMF_END                (OVMF_BEGIN + OVMF_SIZE)
+#define LOWCHUNK_BEGIN          0x000F0000
+#define LOWCHUNK_SIZE           0x00010000
+#define LOWCHUNK_MAXOFFSET      0x0000FFFF
+#define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
+
+extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
+extern int dsdt_anycpu_len, dsdt_15cpu_len;
+
+static void ovmf_load(const struct bios_config *config)
+{
+    xen_pfn_t mfn;
+    uint64_t addr = OVMF_BEGIN;
+
+    /* Copy low-reset vector portion. */
+    memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
+           + OVMF_SIZE
+           - LOWCHUNK_SIZE,
+           LOWCHUNK_SIZE);
+
+    /* Ensure we have backing page prior to moving FD. */
+    while ((addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT)) {
+        mfn = (uint32_t) (addr >> PAGE_SHIFT);
+        addr += PAGE_SIZE;
+	mem_hole_populate_ram(mfn, 1);
+    }
+
+    /* Copy FD. */
+    memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+}
+
+static void ovmf_acpi_build_tables(void)
+{
+    struct acpi_config config = {
+        .dsdt_anycpu = dsdt_anycpu,
+        .dsdt_anycpu_len = dsdt_anycpu_len,
+        .dsdt_15cpu = dsdt_15cpu,
+        .dsdt_15cpu_len = dsdt_15cpu_len,
+    };
+
+    acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
+}
+
+static void ovmf_create_smbios_tables(void)
+{
+    hvm_write_smbios_tables(SMBIOS_PHYSICAL_ADDRESS,
+                            SMBIOS_PHYSICAL_ADDRESS + sizeof(struct smbios_entry_point),
+                            SMBIOS_PHYSICAL_END);
+}
+
+struct bios_config ovmf32_config =  {
+    .name = "OVMF-IA32",
+
+    .image = ovmf32,
+    .image_size = sizeof(ovmf32),
+
+    .bios_address = 0,
+    .bios_load = ovmf_load,
+
+    .load_roms = 0,
+
+    .bios_info_setup = NULL,
+    .bios_info_finish = NULL,
+
+    .e820_setup = NULL,
+
+    .acpi_build_tables = ovmf_acpi_build_tables,
+    .create_mp_tables = NULL,
+    .create_smbios_tables = ovmf_create_smbios_tables,
+    .create_pir_tables = NULL,
+};
+
+struct bios_config ovmf64_config =  {
+    .name = "OVMF-X64",
+
+    .image = ovmf64,
+    .image_size = sizeof(ovmf64),
+
+    .bios_address = 0,
+    .bios_load = ovmf_load,
+
+    .load_roms = 0,
+
+    .bios_info_setup = NULL,
+    .bios_info_finish = NULL,
+
+    .e820_setup = NULL,
+
+    .acpi_build_tables = ovmf_acpi_build_tables,
+    .create_mp_tables = NULL,
+    .create_smbios_tables = ovmf_create_smbios_tables,
+    .create_pir_tables = NULL,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:21:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19:21:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0HkO-0003Q9-3d; Wed, 22 Feb 2012 19:21:04 +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 1S0HkM-0003Ph-GK
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 19:21:02 +0000
Received: from [85.158.139.83:63764] by server-8.bemta-5.messagelabs.com id
	C4/B1-09797-D10454F4; Wed, 22 Feb 2012 19:21:01 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938460!13496058!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30926 invoked from network); 22 Feb 2012 19:21:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 19:20:34 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 19:20:34 +0000
MIME-Version: 1.0
X-Mercurial-Node: 032fea10f8d121fe7db01b33d93ba62c3272197c
Message-ID: <032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
In-Reply-To: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 19:17:13 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: gbtju85@gmail.com
Subject: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include OVMF
 UEFI support and directly use 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

when specified in the guest configuration file.
This work is somewhat based on Bei Guan effort during the SoC 2011 and
relies on upstream edk2/ovmf Tianocore ROM to be built separately and
manually copied as:
Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd -> tools/firmware/ovmf/ovmf-x64.bin
Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd -> toolf/firmware/ovmf/ovmf-ia32.bin

A way to integrate OVMF build directly into XEN has still be discussed
on the mailing list appropriately.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

diff -r a88ba599add1 -r 032fea10f8d1 Config.mk
--- a/Config.mk	Tue Feb 21 17:45:59 2012 +0000
+++ b/Config.mk	Wed Feb 22 18:54:03 2012 +0000
@@ -224,6 +224,7 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
+CONFIG_OVMF ?= y
 CONFIG_ROMBIOS ?= y
 CONFIG_SEABIOS ?= y
 
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Tue Feb 21 17:45:59 2012 +0000
+++ b/tools/firmware/hvmloader/Makefile	Wed Feb 22 18:54:03 2012 +0000
@@ -37,6 +37,7 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
+OVMF_DIR := ../ovmf
 ROMBIOS_DIR := ../rombios
 SEABIOS_DIR := ../seabios-dir
 
@@ -52,6 +53,14 @@ endif
 
 ROMS := 
 
+ifeq ($(CONFIG_OVMF),y)
+OBJS += ovmf.o
+CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
+OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
+OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
+ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
+endif
+
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
@@ -70,7 +79,7 @@ endif
 all: subdirs-all
 	$(MAKE) hvmloader
 
-rombios.o seabios.o hvmloader.o: roms.inc
+ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -93,6 +102,18 @@ ifneq ($(SEABIOS_ROM),)
 	echo "#endif" >> $@.new
 endif
 
+ifneq ($(OVMF32_ROM),)
+	echo "#ifdef ROM_INCLUDE_OVMF32" >> $@.new
+	sh ./mkhex ovmf32 $(OVMF32_ROM) >> $@.new
+	echo "#endif" >> $@.new	
+endif 
+
+ifneq ($(OVMF64_ROM),)
+	echo "#ifdef ROM_INCLUDE_OVMF64" >> $@.new
+	sh ./mkhex ovmf64 $(OVMF64_ROM) >> $@.new
+	echo "#endif" >> $@.new	
+endif 
+
 ifneq ($(STDVGA_ROM),)
 	echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
 	sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
+++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
@@ -35,6 +35,8 @@ struct bios_config {
 
 extern struct bios_config rombios_config;
 extern struct bios_config seabios_config;
+extern struct bios_config ovmf32_config;
+extern struct bios_config ovmf64_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Tue Feb 21 17:45:59 2012 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Wed Feb 22 18:54:03 2012 +0000
@@ -212,6 +212,12 @@ struct bios_info {
 #ifdef ENABLE_SEABIOS
     { "seabios", &seabios_config, },
 #endif
+#ifdef ENABLE_OVMF32
+    { "ovmf-ia32", &ovmf32_config, },
+#endif
+#ifdef ENABLE_OVMF64
+    { "ovmf-x64", &ovmf64_config, },
+#endif
     { NULL, NULL }
 };
 
diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/ovmf.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ovmf.c	Wed Feb 22 18:54:03 2012 +0000
@@ -0,0 +1,147 @@
+/*
+ * HVM OVMF UEFI support.
+ *
+ * Bei Guan, gbtju85@gmail.com
+ * Andrei Warkentin, andreiw@motorola.com
+ * Leendert van Doorn, leendert@watson.ibm.com
+ * Copyright (c) 2005, International Business Machines Corporation.
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ * Copyright (c) 2011, Citrix Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include "config.h"
+#include "smbios_types.h"
+#include "acpi/acpi2_0.h"
+#include "apic_regs.h"
+#include "../rombios/config.h"
+#include "util.h"
+#include "pci_regs.h"
+#include "hypercall.h"
+
+#include <xen/hvm/params.h>
+#include <xen/hvm/ioreq.h>
+#include <xen/memory.h>
+
+#define ROM_INCLUDE_OVMF32
+#define ROM_INCLUDE_OVMF64
+#include "roms.inc"
+
+#define OVMF_BEGIN              0xFFF00000ULL
+#define OVMF_SIZE               0x00100000ULL
+#define OVMF_MAXOFFSET          0x000FFFFFULL
+#define OVMF_END                (OVMF_BEGIN + OVMF_SIZE)
+#define LOWCHUNK_BEGIN          0x000F0000
+#define LOWCHUNK_SIZE           0x00010000
+#define LOWCHUNK_MAXOFFSET      0x0000FFFF
+#define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
+
+extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
+extern int dsdt_anycpu_len, dsdt_15cpu_len;
+
+static void ovmf_load(const struct bios_config *config)
+{
+    xen_pfn_t mfn;
+    uint64_t addr = OVMF_BEGIN;
+
+    /* Copy low-reset vector portion. */
+    memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
+           + OVMF_SIZE
+           - LOWCHUNK_SIZE,
+           LOWCHUNK_SIZE);
+
+    /* Ensure we have backing page prior to moving FD. */
+    while ((addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT)) {
+        mfn = (uint32_t) (addr >> PAGE_SHIFT);
+        addr += PAGE_SIZE;
+	mem_hole_populate_ram(mfn, 1);
+    }
+
+    /* Copy FD. */
+    memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+}
+
+static void ovmf_acpi_build_tables(void)
+{
+    struct acpi_config config = {
+        .dsdt_anycpu = dsdt_anycpu,
+        .dsdt_anycpu_len = dsdt_anycpu_len,
+        .dsdt_15cpu = dsdt_15cpu,
+        .dsdt_15cpu_len = dsdt_15cpu_len,
+    };
+
+    acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
+}
+
+static void ovmf_create_smbios_tables(void)
+{
+    hvm_write_smbios_tables(SMBIOS_PHYSICAL_ADDRESS,
+                            SMBIOS_PHYSICAL_ADDRESS + sizeof(struct smbios_entry_point),
+                            SMBIOS_PHYSICAL_END);
+}
+
+struct bios_config ovmf32_config =  {
+    .name = "OVMF-IA32",
+
+    .image = ovmf32,
+    .image_size = sizeof(ovmf32),
+
+    .bios_address = 0,
+    .bios_load = ovmf_load,
+
+    .load_roms = 0,
+
+    .bios_info_setup = NULL,
+    .bios_info_finish = NULL,
+
+    .e820_setup = NULL,
+
+    .acpi_build_tables = ovmf_acpi_build_tables,
+    .create_mp_tables = NULL,
+    .create_smbios_tables = ovmf_create_smbios_tables,
+    .create_pir_tables = NULL,
+};
+
+struct bios_config ovmf64_config =  {
+    .name = "OVMF-X64",
+
+    .image = ovmf64,
+    .image_size = sizeof(ovmf64),
+
+    .bios_address = 0,
+    .bios_load = ovmf_load,
+
+    .load_roms = 0,
+
+    .bios_info_setup = NULL,
+    .bios_info_finish = NULL,
+
+    .e820_setup = NULL,
+
+    .acpi_build_tables = ovmf_acpi_build_tables,
+    .create_mp_tables = NULL,
+    .create_smbios_tables = ovmf_create_smbios_tables,
+    .create_pir_tables = NULL,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:21:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0HkN-0003Pv-B2; Wed, 22 Feb 2012 19:21:03 +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 1S0HkM-0003Pg-1z
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 19:21:02 +0000
Received: from [85.158.139.83:63750] by server-9.bemta-5.messagelabs.com id
	FD/4E-30171-D10454F4; Wed, 22 Feb 2012 19:21:01 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938460!13496058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30916 invoked from network); 22 Feb 2012 19:21:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:21:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 19:20:39 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 19:20:39 +0000
MIME-Version: 1.0
X-Mercurial-Node: 520ba1527b7ad2c73c41ddcd954b7b80e8522b2c
Message-ID: <520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
In-Reply-To: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 19:17:14 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: gbtju85@gmail.com
Subject: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the option
 "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

configuration file.
An example is given by:
bios_override="ovmf-x64"

which forces BIOS to be the OVMF UEFI for 64 bits architectures.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Feb 22 18:56:22 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = NULL;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return info->u.hvm.bios;
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
@@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", string),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:56:22 2012 +0000
@@ -704,6 +704,8 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        xlu_cfg_replace_string (config, "bios_override",
+                                &b_info->u.hvm.bios, 0);
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:21:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0HkN-0003Pv-B2; Wed, 22 Feb 2012 19:21:03 +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 1S0HkM-0003Pg-1z
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 19:21:02 +0000
Received: from [85.158.139.83:63750] by server-9.bemta-5.messagelabs.com id
	FD/4E-30171-D10454F4; Wed, 22 Feb 2012 19:21:01 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938460!13496058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30916 invoked from network); 22 Feb 2012 19:21:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:21:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 19:20:39 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 19:20:39 +0000
MIME-Version: 1.0
X-Mercurial-Node: 520ba1527b7ad2c73c41ddcd954b7b80e8522b2c
Message-ID: <520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
In-Reply-To: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 19:17:14 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: gbtju85@gmail.com
Subject: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the option
 "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

configuration file.
An example is given by:
bios_override="ovmf-x64"

which forces BIOS to be the OVMF UEFI for 64 bits architectures.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Feb 22 18:56:22 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = NULL;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return info->u.hvm.bios;
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
@@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", string),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:54:03 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:56:22 2012 +0000
@@ -704,6 +704,8 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        xlu_cfg_replace_string (config, "bios_override",
+                                &b_info->u.hvm.bios, 0);
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19: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 1S0HkN-0003Q2-OZ; Wed, 22 Feb 2012 19:21:03 +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 1S0HkM-0003Pg-LJ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 19:21:02 +0000
Received: from [85.158.139.83:63763] by server-9.bemta-5.messagelabs.com id
	1F/4E-30171-D10454F4; Wed, 22 Feb 2012 19:21:01 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938460!13496058!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30944 invoked from network); 22 Feb 2012 19:21:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 19:20:29 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 19:20:29 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 19:17:12 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: gbtju85@gmail.com
Subject: [Xen-devel] [PATCH 0 of 2] Add the OVMF UEFI support to 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

The attached patches rewamp an early SoC 2011 work by Bei Guan and
add the support for OVMF UEFI in hvmloader.

In order to use the OVMF the guest configuration file must specify it
via the introduced bios_override option and the Tianocore roms must be
built and copied manually into the specific location (as explained in
the comments about ovmf_infrastructure.patch).

An open point is how to deal with download and building of the rom
themselves.
We should likely mirror the edk2 svn tree (or a part of it) via an
utility as git-svn and download with git as we already do with projects
as seabios.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19: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 1S0HkN-0003Q2-OZ; Wed, 22 Feb 2012 19:21:03 +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 1S0HkM-0003Pg-LJ
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 19:21:02 +0000
Received: from [85.158.139.83:63763] by server-9.bemta-5.messagelabs.com id
	1F/4E-30171-D10454F4; Wed, 22 Feb 2012 19:21:01 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938460!13496058!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30944 invoked from network); 22 Feb 2012 19:21:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 19:20:29 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 19:20:29 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 22 Feb 2012 19:17:12 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: gbtju85@gmail.com
Subject: [Xen-devel] [PATCH 0 of 2] Add the OVMF UEFI support to 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

The attached patches rewamp an early SoC 2011 work by Bei Guan and
add the support for OVMF UEFI in hvmloader.

In order to use the OVMF the guest configuration file must specify it
via the introduced bios_override option and the Tianocore roms must be
built and copied manually into the specific location (as explained in
the comments about ovmf_infrastructure.patch).

An open point is how to deal with download and building of the rom
themselves.
We should likely mirror the edk2 svn tree (or a part of it) via an
utility as git-svn and download with git as we already do with projects
as seabios.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:26:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0HpI-0003z2-Jk; Wed, 22 Feb 2012 19:26:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1S0HpH-0003yg-8E
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 19:26:07 +0000
Received: from [85.158.139.83:18248] by server-12.bemta-5.messagelabs.com id
	A7/FE-24595-C41454F4; Wed, 22 Feb 2012 19:26:04 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938762!13496547!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10583 invoked from network); 22 Feb 2012 19:26:04 -0000
Received: from mail-pw0-f45.google.com (HELO mail-pw0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:26:04 -0000
Received: by pbbro12 with SMTP id ro12so522805pbb.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 11:26:02 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony@codemonkey.ws designates
	10.68.197.196 as permitted sender) client-ip=10.68.197.196; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of anthony@codemonkey.ws
	designates 10.68.197.196 as permitted sender)
	smtp.mail=anthony@codemonkey.ws
Received: from mr.google.com ([10.68.197.196])
	by 10.68.197.196 with SMTP id iw4mr30007133pbc.133.1329938762125
	(num_hops = 1); Wed, 22 Feb 2012 11:26:02 -0800 (PST)
Received: by 10.68.197.196 with SMTP id iw4mr24421154pbc.133.1329938762053;
	Wed, 22 Feb 2012 11:26:02 -0800 (PST)
Received: from [192.168.0.108] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id f5sm19693712pbe.26.2012.02.22.11.25.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 11:26:00 -0800 (PST)
Message-ID: <4F454146.1050007@codemonkey.ws>
Date: Wed, 22 Feb 2012 13:25:58 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@entel.upc.edu>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
In-Reply-To: <1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
X-Gm-Message-State: ALoCoQlG0WtohZowNemHl+gGwRHbLqHFl5AVuzSVpn73hy9aVCYnXHMIuWlCx0bkDK37DfVbCs7D
Cc: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
	function
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/20/2012 06:11 AM, Roger Pau Monne wrote:
> Replace clock_gettime with timer_gettime, since at least under
> uclibc 0.9.33 the clock_getttime function can be used without linking
> against librt (although the manual page states the opposite).
>
> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu>

I don't think this is against qemu.git.  Please do not send patches to 
qemu-devel that are not against qemu.git without clearly indicating this.

Regards,

Anthony Liguori

> ---
>   configure |    3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/configure b/configure
> index 7bcd547..fb99632 100755
> --- a/configure
> +++ b/configure
> @@ -2438,7 +2438,8 @@ fi
>   cat>  $TMPC<<EOF
>   #include<signal.h>
>   #include<time.h>
> -int main(void) { clockid_t id; return clock_gettime(id, NULL); }
> +int main(void) { timer_t tid; struct itimerspec it; \
> +                 return timer_gettime(tid,&it); }
>   EOF
>
>   if compile_prog "" "" ; then


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 19:26:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 19:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0HpI-0003z2-Jk; Wed, 22 Feb 2012 19:26:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1S0HpH-0003yg-8E
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 19:26:07 +0000
Received: from [85.158.139.83:18248] by server-12.bemta-5.messagelabs.com id
	A7/FE-24595-C41454F4; Wed, 22 Feb 2012 19:26:04 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-4.tower-182.messagelabs.com!1329938762!13496547!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10583 invoked from network); 22 Feb 2012 19:26:04 -0000
Received: from mail-pw0-f45.google.com (HELO mail-pw0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 19:26:04 -0000
Received: by pbbro12 with SMTP id ro12so522805pbb.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 11:26:02 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony@codemonkey.ws designates
	10.68.197.196 as permitted sender) client-ip=10.68.197.196; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of anthony@codemonkey.ws
	designates 10.68.197.196 as permitted sender)
	smtp.mail=anthony@codemonkey.ws
Received: from mr.google.com ([10.68.197.196])
	by 10.68.197.196 with SMTP id iw4mr30007133pbc.133.1329938762125
	(num_hops = 1); Wed, 22 Feb 2012 11:26:02 -0800 (PST)
Received: by 10.68.197.196 with SMTP id iw4mr24421154pbc.133.1329938762053;
	Wed, 22 Feb 2012 11:26:02 -0800 (PST)
Received: from [192.168.0.108] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id f5sm19693712pbe.26.2012.02.22.11.25.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 22 Feb 2012 11:26:00 -0800 (PST)
Message-ID: <4F454146.1050007@codemonkey.ws>
Date: Wed, 22 Feb 2012 13:25:58 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@entel.upc.edu>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
In-Reply-To: <1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
X-Gm-Message-State: ALoCoQlG0WtohZowNemHl+gGwRHbLqHFl5AVuzSVpn73hy9aVCYnXHMIuWlCx0bkDK37DfVbCs7D
Cc: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
	function
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/20/2012 06:11 AM, Roger Pau Monne wrote:
> Replace clock_gettime with timer_gettime, since at least under
> uclibc 0.9.33 the clock_getttime function can be used without linking
> against librt (although the manual page states the opposite).
>
> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu>

I don't think this is against qemu.git.  Please do not send patches to 
qemu-devel that are not against qemu.git without clearly indicating this.

Regards,

Anthony Liguori

> ---
>   configure |    3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/configure b/configure
> index 7bcd547..fb99632 100755
> --- a/configure
> +++ b/configure
> @@ -2438,7 +2438,8 @@ fi
>   cat>  $TMPC<<EOF
>   #include<signal.h>
>   #include<time.h>
> -int main(void) { clockid_t id; return clock_gettime(id, NULL); }
> +int main(void) { timer_t tid; struct itimerspec it; \
> +                 return timer_gettime(tid,&it); }
>   EOF
>
>   if compile_prog "" "" ; then


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 20:03:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 20:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0IOx-0004cX-Ke; Wed, 22 Feb 2012 20:02:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0IOv-0004cS-QV
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 20:02:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329940971!9351773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1841 invoked from network); 22 Feb 2012 20:02:51 -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;
	22 Feb 2012 20:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 20:02:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 20:02:50 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0IOo-00008y-7c;
	Wed, 22 Feb 2012 20:02:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0IOo-0004wL-0c;
	Wed, 22 Feb 2012 20:02:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12022-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 20:02:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12022: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12022 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12022/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 12003

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   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-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  40785b479047
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 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:   24865:40785b479047
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Feb 22 14:27:18 2012 +0000
    
    autoconf: Rerun autogen.sh
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24864:d370b93ba754
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 13:06:42 2012 +0000
    
    autoconf: clean brctl options
    
    This bit was missing, sorry.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24863:4aa563f19a18
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:56:24 2012 +0000
    
    autoconf: remove udev checks from build
    
    There's no need to have udev when building Xen since it's only used at
    run time.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24862:69c6e5d33f10
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:54:16 2012 +0000
    
    autoconf: remove brctl check
    
    Remove brctl check since it's usually only available to users with
    high privileges, but Xen should be buildable by regular users.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24861:8ee81ceda8c9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 20:03:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 20:03:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0IOx-0004cX-Ke; Wed, 22 Feb 2012 20:02:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0IOv-0004cS-QV
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 20:02:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1329940971!9351773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1841 invoked from network); 22 Feb 2012 20:02:51 -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;
	22 Feb 2012 20:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="10881511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 20:02:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 20:02:50 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0IOo-00008y-7c;
	Wed, 22 Feb 2012 20:02:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0IOo-0004wL-0c;
	Wed, 22 Feb 2012 20:02:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12022-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 20:02:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12022: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12022 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12022/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 12003

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   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-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  40785b479047
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 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:   24865:40785b479047
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Feb 22 14:27:18 2012 +0000
    
    autoconf: Rerun autogen.sh
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24864:d370b93ba754
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 13:06:42 2012 +0000
    
    autoconf: clean brctl options
    
    This bit was missing, sorry.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24863:4aa563f19a18
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:56:24 2012 +0000
    
    autoconf: remove udev checks from build
    
    There's no need to have udev when building Xen since it's only used at
    run time.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24862:69c6e5d33f10
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 22 11:54:16 2012 +0000
    
    autoconf: remove brctl check
    
    Remove brctl check since it's usually only available to users with
    high privileges, but Xen should be buildable by regular users.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24861:8ee81ceda8c9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:04 2012 +0000
    
    .gitignore: add autoconf-related files
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24860:a19c6d90fd41
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Wed Feb 22 01:55:03 2012 +0000
    
    build: add autoconf to replace custom checks in tools/check
    
    Added autotools magic to replace custom check scripts. The previous
    checks have been ported to autoconf, and some additional ones have
    been added (plus the suggestions from running autoscan). Two files are
    created as a result from executing configure script, config/Tools.mk
    and config.h.
    
    conf/Tools.mk is included by tools/Rules.mk, and contains most of the
    options previously defined in .config, that can now be set passing
    parameters or defining environment variables when executing configure
    script.
    
    config.h is only used by libxl/xl to detect yajl_version.h.
    
    [ tools/config.sub and config.guess copied from
      autotools-dev 20100122.1 from Debian squeeze i386,
      which is GPLv2.
    
      tools/configure generated using the included ./autogen.sh
      which ran autoconf 2.67-2 from Debian squeeze i386.  autoconf
      is GPLv3+ but has a special exception for the autoconf output;
      this exception applies to us and exempts us from complying
      with GPLv3+ for configure, which is good as Xen is GPL2 only.
    
      - Ian Jackson ]
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24859:6a34a42a2b5d
user:        Bamvor Jian Zhang <bjzhang@suse.com>
date:        Tue Feb 21 18:01:04 2012 +0000
    
    libxl: Export libxl_event.h
    
    This fixes a compile error in libvirt.
    
    Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24858:a88ba599add1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Tue Feb 21 17:45:59 2012 +0000
    
    libxl: cleanup: Remove pointless ERRNOVAL
    
    Just call LIBXL__LOG rather than passing a meaningless ERRNOVAL.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 20:39:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 20: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 1S0Ixh-0005Hs-10; Wed, 22 Feb 2012 20:38:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Ixf-0005Hk-E4
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 20:38:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329943119!16217372!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29677 invoked from network); 22 Feb 2012 20:38: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;
	22 Feb 2012 20:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,466,1325462400"; d="scan'208";a="10881760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 20:38:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 20:38:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0IxS-0000XD-OQ;
	Wed, 22 Feb 2012 20:38:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0IxS-0001zI-NG;
	Wed, 22 Feb 2012 20:38:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12012-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 20:38:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12012: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12012 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12012/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2          fail   like 11789

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 20:39:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 20: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 1S0Ixh-0005Hs-10; Wed, 22 Feb 2012 20:38:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0Ixf-0005Hk-E4
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 20:38:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1329943119!16217372!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDMwNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29677 invoked from network); 22 Feb 2012 20:38: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;
	22 Feb 2012 20:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,466,1325462400"; d="scan'208";a="10881760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2012 20:38:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 22 Feb 2012 20:38:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0IxS-0000XD-OQ;
	Wed, 22 Feb 2012 20:38:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0IxS-0001zI-NG;
	Wed, 22 Feb 2012 20:38:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12012-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 22 Feb 2012 20:38:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12012: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12012 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12012/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2          fail   like 11789

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-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-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 21:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 21: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 1S0JvE-0005qL-3m; Wed, 22 Feb 2012 21:40:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1S0JvC-0005qG-DS
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 21:40:22 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329946814!15997799!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29891 invoked from network); 22 Feb 2012 21:40:15 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2012 21:40:15 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 22 Feb 2012 14:40:13 -0700
Message-ID: <4F4560BC.30002@suse.com>
Date: Wed, 22 Feb 2012 14:40:12 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>	<20291.56383.499378.463797@mariner.uk.xensource.com>	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
In-Reply-To: <20292.55062.209546.961330@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson wrote:
> Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
>   
>> Ian Jackson wrote: 
>>     
>>> Users of libxl should not be using libxc directly and therefore should 
>>> not be including xenctrl.h. 
>>>       
> ...
>   
>> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
>> it seems that add __XEN_TOOLS_ to libvirt code is not good. 
>>     
>
> Can you tell us the error message you get ?  I think the problem is
> probably that libvirt is trying to use libxc directly.
>   

The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
is that libxl.h includes <xen/sysctl.h>, which has this

#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
#error "sysctl operations are intended for use by node control tools only"
#endif

Without the defines, Bamvor is hitting the #error directive.

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 Feb 22 21:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 21: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 1S0JvE-0005qL-3m; Wed, 22 Feb 2012 21:40:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1S0JvC-0005qG-DS
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 21:40:22 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329946814!15997799!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29891 invoked from network); 22 Feb 2012 21:40:15 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2012 21:40:15 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 22 Feb 2012 14:40:13 -0700
Message-ID: <4F4560BC.30002@suse.com>
Date: Wed, 22 Feb 2012 14:40:12 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>	<20291.56383.499378.463797@mariner.uk.xensource.com>	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
In-Reply-To: <20292.55062.209546.961330@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson wrote:
> Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
>   
>> Ian Jackson wrote: 
>>     
>>> Users of libxl should not be using libxc directly and therefore should 
>>> not be including xenctrl.h. 
>>>       
> ...
>   
>> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
>> it seems that add __XEN_TOOLS_ to libvirt code is not good. 
>>     
>
> Can you tell us the error message you get ?  I think the problem is
> probably that libvirt is trying to use libxc directly.
>   

The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
is that libxl.h includes <xen/sysctl.h>, which has this

#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
#error "sysctl operations are intended for use by node control tools only"
#endif

Without the defines, Bamvor is hitting the #error directive.

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 Feb 22 21:43:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 21:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0JxP-0005un-Sc; Wed, 22 Feb 2012 21:42:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1S0JxN-0005ub-FM
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 21:42:37 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329946949!10116189!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12636 invoked from network); 22 Feb 2012 21:42:31 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2012 21:42:31 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 22 Feb 2012 14:42:15 -0700
Message-ID: <4F456136.7070904@suse.com>
Date: Wed, 22 Feb 2012 14:42:14 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
In-Reply-To: <20291.56383.499378.463797@mariner.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error
	of	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson wrote:
> Note that the API for libxl has changed in xen-unstable.hg compared to
> 4.1, and further changes are forthcoming.  So there will have to be
> changes in libvirt.
>   

I suppose libvirt is the only out-of-tree libxl app feeling this pain :-(.

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 Feb 22 21:43:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 21:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0JxP-0005un-Sc; Wed, 22 Feb 2012 21:42:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1S0JxN-0005ub-FM
	for xen-devel@lists.xensource.com; Wed, 22 Feb 2012 21:42:37 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329946949!10116189!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12636 invoked from network); 22 Feb 2012 21:42:31 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2012 21:42:31 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 22 Feb 2012 14:42:15 -0700
Message-ID: <4F456136.7070904@suse.com>
Date: Wed, 22 Feb 2012 14:42:14 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
In-Reply-To: <20291.56383.499378.463797@mariner.uk.xensource.com>
Cc: xen-devel@lists.xensource.com, Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error
	of	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson wrote:
> Note that the API for libxl has changed in xen-unstable.hg compared to
> 4.1, and further changes are forthcoming.  So there will have to be
> changes in libvirt.
>   

I suppose libvirt is the only out-of-tree libxl app feeling this pain :-(.

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 Feb 22 22:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 22: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 1S0KXE-0006HO-CZ; Wed, 22 Feb 2012 22:19:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henrik@fixme.se>) id 1S0KXB-0006HI-MH
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 22:19:38 +0000
X-Env-Sender: henrik@fixme.se
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329949165!14509752!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15745 invoked from network); 22 Feb 2012 22:19:27 -0000
Received: from mail-vw0-f45.google.com (HELO mail-vw0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 22:19:27 -0000
Received: by vbal1 with SMTP id l1so520731vba.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:19:25 -0800 (PST)
Received-SPF: pass (google.com: domain of henrik@fixme.se designates
	10.220.7.208 as permitted sender) client-ip=10.220.7.208; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of henrik@fixme.se
	designates 10.220.7.208 as permitted sender)
	smtp.mail=henrik@fixme.se
Received: from mr.google.com ([10.220.7.208])
	by 10.220.7.208 with SMTP id e16mr18568057vce.0.1329949165540 (num_hops
	= 1); Wed, 22 Feb 2012 14:19:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.7.208 with SMTP id e16mr14982853vce.0.1329949165190; Wed,
	22 Feb 2012 14:19:25 -0800 (PST)
Received: by 10.220.198.133 with HTTP; Wed, 22 Feb 2012 14:19:25 -0800 (PST)
Date: Wed, 22 Feb 2012 23:19:25 +0100
Message-ID: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
From: Henrik Olsson <henrik@fixme.se>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=bcaec54faf688f7e2504b994eb2f
X-Gm-Message-State: ALoCoQk/jMDljUGhmg2cTVC4fpmKy97M30xAoqyntn72uqSRGVSXXA+bwm3JmVgHMalsRVh7iBxG
Subject: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=ISO-8859-1

Hi, i'm having some trouble with assigning memory to my dom0.

I've added "dom0_mem=8192M" to the xen command line yet "free -m"
reports only 5686MB total.

Running Xen 4.1.2 with kernel 3.2.0-1-amd64, debian testing.

Attached are the outputs of dmesg, xm dmesg, xm info and xm list.

Regards,
Henrik Olsson

--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt"
Content-Disposition: attachment; filename="dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxbpfb0

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAgMC4w
MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAwXSBMaW51
eCB2ZXJzaW9uIDMuMi4wLTEtYW1kNjQgKERlYmlhbiAzLjIuNC0xKSAod2FsZGlAZGViaWFuLm9y
ZykgKGdjYyB2ZXJzaW9uIDQuNi4yIChEZWJpYW4gNC42LjItMTIpICkgIzEgU01QIFN1biBGZWIg
NSAxNToxNzoxNSBVVEMgMjAxMgpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6IHBsYWNlaG9s
ZGVyIHJvb3Q9L2Rldi9tYXBwZXIvbXVhZGRpYi1yb290IHJvIHJkYmxhY2tsaXN0PXJhZGVvbiBy
YWRlb24ubW9kc2V0PTAgbWVtPTgxOTJNClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgIDlkLTEwMCBw
Zm4gcmFuZ2U6IDk5IHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDlk
LT4xMDAKWyAgICAwLjAwMDAwMF0gRnJlZWluZyAgMjAwMDAtMjAyMDAgcGZuIHJhbmdlOiA1MTIg
cGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gMjAwMDAtPjIwMjAwClsg
ICAgMC4wMDAwMDBdIEZyZWVpbmcgIDQwMDAwLTQwMjAwIHBmbiByYW5nZTogNTEyIHBhZ2VzIGZy
ZWVkClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDQwMDAwLT40MDIwMApbICAgIDAuMDAw
MDAwXSBGcmVlaW5nICA2ZWQ2ZC02ZWRmMiBwZm4gcmFuZ2U6IDEzMyBwYWdlcyBmcmVlZApbICAg
IDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiA2ZWQ2ZC0+NmVkZjIKWyAgICAwLjAwMDAwMF0gRnJl
ZWluZyAgNmVkZjMtNmVlN2IgcGZuIHJhbmdlOiAxMzYgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAw
MF0gMS0xIG1hcHBpbmcgb24gNmVkZjMtPjZlZTdiClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgIDZm
MDAwLTEwMDAwMCBwZm4gcmFuZ2U6IDU5MzkyMCBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSAx
LTEgbWFwcGluZyBvbiA2ZjAwMC0+MTAwMDAwClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDU5NTMx
MiBwYWdlcyBvZiB1bnVzZWQgbWVtb3J5ClsgICAgMC4wMDAwMDBdIFNldCA1OTUzMTIgcGFnZShz
KSB0byAxLTEgbWFwcGluZwpbICAgIDAuMDAwMDAwXSBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJB
TSBtYXA6ClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDlkMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwOWQ4MDAgLSAw
MDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAw
MDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjog
MDAwMDAwMDAyMDAwMDAwMCAtIDAwMDAwMDAwMjAyMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAw
MDAwXSAgWGVuOiAwMDAwMDAwMDIwMjAwMDAwIC0gMDAwMDAwMDA0MDAwMDAwMCAodXNhYmxlKQpb
ICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAo
cmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNDAyMDAwMDAgLSAwMDAwMDAw
MDZlZDZkMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNmVkNmQwMDAg
LSAwMDAwMDAwMDZlZGJjMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAw
MDA2ZWRiYzAwMCAtIDAwMDAwMDAwNmVkYzUwMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAwMDAwMF0g
IFhlbjogMDAwMDAwMDA2ZWRjNTAwMCAtIDAwMDAwMDAwNmVkZjIwMDAgKHJlc2VydmVkKQpbICAg
IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDZlZGYyMDAwIC0gMDAwMDAwMDA2ZWRmMzAwMCAodXNh
YmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDZlZGYzMDAwIC0gMDAwMDAwMDA2ZWUw
MzAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNmVlMDMwMDAgLSAw
MDAwMDAwMDZlZTEwMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDA2
ZWUxMDAwMCAtIDAwMDAwMDAwNmVlMzgwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVu
OiAwMDAwMDAwMDZlZTM4MDAwIC0gMDAwMDAwMDA2ZWU3YjAwMCAoQUNQSSBOVlMpClsgICAgMC4w
MDAwMDBdICBYZW46IDAwMDAwMDAwNmVlN2IwMDAgLSAwMDAwMDAwMDZmMDAwMDAwICh1c2FibGUp
ClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNmY4MDAwMDAgLSAwMDAwMDAwMDdmYTAwMDAw
IChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWMwMDAwMCAtIDAwMDAw
MDAwZmVjMDEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZlZDFj
MDAwIC0gMDAwMDAwMDBmZWQ0MDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAw
MDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAw
MF0gIFhlbjogMDAwMDAwMDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQpb
ICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMDQ3ZmUwMDAwMCAo
dXNhYmxlKQpbICAgIDAuMDAwMDAwXSBlODIwIHJlbW92ZSByYW5nZTogMDAwMDAwMDIwMDAwMDAw
MCAtIGZmZmZmZmZmZmZmZmZmZmYgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUg
RGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlClsgICAgMC4wMDAwMDBdIHVzZXItZGVmaW5lZCBw
aHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDAwMDAwMDAwMCAt
IDAwMDAwMDAwMDAwOWQwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAw
MDAwOWQ4MDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVz
ZXI6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDIwMDAwMDAwICh1c2FibGUpClsgICAgMC4w
MDAwMDBdICB1c2VyOiAwMDAwMDAwMDIwMDAwMDAwIC0gMDAwMDAwMDAyMDIwMDAwMCAocmVzZXJ2
ZWQpClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDIwMjAwMDAwIC0gMDAwMDAwMDA0MDAw
MDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA0MDAwMDAwMCAtIDAw
MDAwMDAwNDAyMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA0
MDIwMDAwMCAtIDAwMDAwMDAwNmVkNmQwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIHVzZXI6
IDAwMDAwMDAwNmVkNmQwMDAgLSAwMDAwMDAwMDZlZGJjMDAwIChBQ1BJIE5WUykKWyAgICAwLjAw
MDAwMF0gIHVzZXI6IDAwMDAwMDAwNmVkYmMwMDAgLSAwMDAwMDAwMDZlZGM1MDAwIChBQ1BJIGRh
dGEpClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDZlZGM1MDAwIC0gMDAwMDAwMDA2ZWRm
MjAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDZlZGYyMDAwIC0g
MDAwMDAwMDA2ZWRmMzAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2
ZWRmMzAwMCAtIDAwMDAwMDAwNmVlMDMwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgdXNl
cjogMDAwMDAwMDA2ZWUwMzAwMCAtIDAwMDAwMDAwNmVlMTAwMDAgKEFDUEkgTlZTKQpbICAgIDAu
MDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2ZWUxMDAwMCAtIDAwMDAwMDAwNmVlMzgwMDAgKHJlc2Vy
dmVkKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2ZWUzODAwMCAtIDAwMDAwMDAwNmVl
N2IwMDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2ZWU3YjAwMCAt
IDAwMDAwMDAwNmYwMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAw
NmY4MDAwMDAgLSAwMDAwMDAwMDdmYTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVz
ZXI6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKWyAgICAw
LjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwIChyZXNl
cnZlZCkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZl
ZTAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwZmYwMDAwMDAg
LSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAw
MDAxMDAwMDAwMDAgLSAwMDAwMDAwMjAwMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdIERN
SSAyLjcgcHJlc2VudC4KWyAgICAwLjAwMDAwMF0gRE1JOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0u
IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4vWjY4IEV4dHJlbWU0IEdlbjMsIEJJT1MgUDEuMDAgMDcv
MDgvMjAxMQpbICAgIDAuMDAwMDAwXSBlODIwIHVwZGF0ZSByYW5nZTogMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwMTAwMDAgKHVzYWJsZSkgPT0+IChyZXNlcnZlZCkKWyAgICAwLjAwMDAw
MF0gZTgyMCByZW1vdmUgcmFuZ2U6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw
ICh1c2FibGUpClsgICAgMC4wMDAwMDBdIE5vIEFHUCBicmlkZ2UgZm91bmQKWyAgICAwLjAwMDAw
MF0gbGFzdF9wZm4gPSAweDIwMDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAu
MDAwMDAwXSB4MmFwaWMgZW5hYmxlZCBieSBCSU9TLCBzd2l0Y2hpbmcgdG8geDJhcGljIG9wcwpb
ICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4NmYwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAw
MDAKWyAgICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRhYmxlIGF0IFtmZmZmODgwMDAwMGZkMjMw
XSBmZDIzMApbICAgIDAuMDAwMDAwXSBpbml0aWFsIG1lbW9yeSBtYXBwZWQgOiAwIC0gMDNhMmMw
MDAKWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbZmZmZjg4MDAwMDA5
ODAwMF0gOTgwMDAgc2l6ZSAyMDQ4MApbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5n
OiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwNmYwMDAwMDAKWyAgICAwLjAwMDAwMF0gIDAwMDAw
MDAwMDAgLSAwMDZmMDAwMDAwIHBhZ2UgNGsKWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBt
YXBwaW5nIHRhYmxlcyB1cCB0byA2ZjAwMDAwMCBAIGM4NTAwMC0xMDAwMDAwClsgICAgMC4wMDAw
MDBdIHhlbjogc2V0dGluZyBSVyB0aGUgcmFuZ2UgZmQ0MDAwIC0gMTAwMDAwMApbICAgIDAuMDAw
MDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMTAwMDAwMDAwLTAwMDAwMDAyMDAwMDAw
MDAKWyAgICAwLjAwMDAwMF0gIDAxMDAwMDAwMDAgLSAwMjAwMDAwMDAwIHBhZ2UgNGsKWyAgICAw
LjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAyMDAwMDAwMDAgQCA2
ZGQ2NDAwMC02ZWQ2ZDAwMApbICAgIDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdl
IDZlNTY4MDAwIC0gNmVkNmQwMDAKWyAgICAwLjAwMDAwMF0gUkFNRElTSzogMDE5M2EwMDAgLSAw
M2EyYzAwMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDAwMDAwMDAwMDAwZjA0NTAgMDAwMjQg
KHYwMiBBTEFTS0EpClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA2ZWRiYzA3MCAw
MDA1QyAodjAxIEFMQVNLQSAgICBBIE0gSSAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBGQUNQIDAwMDAwMDAwNmVkYzQxNTggMDAwRjQgKHYwNCBBTEFTS0EgICAg
QSBNIEkgMDEwNzIwMDkgQU1JICAwMDAxMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAw
MDAwMDAwMDZlZGJjMTU4IDA3RkZCICh2MDIgQUxBU0tBICAgIEEgTSBJIDAwMDAwMDAwIElOVEwg
MjAwNTExMTcpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDA2ZWUwN2Y4MCAwMDA0
MApbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDAwMDAwMDAwNmVkYzQyNTAgMDAwOTIgKHYwMyBB
TEFTS0EgICAgQSBNIEkgMDEwNzIwMDkgQU1JICAwMDAxMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQ
STogU1NEVCAwMDAwMDAwMDZlZGM0MmU4IDAwMUQ2ICh2MDEgQU1JQ1BVICAgICBQUk9DIDAwMDAw
MDAxIE1TRlQgMDMwMDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IE1DRkcgMDAwMDAwMDA2ZWRj
NDRjMCAwMDAzQyAodjAxIEFMQVNLQSAgICBBIE0gSSAwMTA3MjAwOSBNU0ZUIDAwMDAwMDk3KQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBBQUZUIDAwMDAwMDAwNmVkYzQ1MDAgMDAwRDMgKHYwMSBBTEFT
S0EgT0VNQUFGVCAgMDEwNzIwMDkgTVNGVCAwMDAwMDA5NykKWyAgICAwLjAwMDAwMF0gQUNQSTog
SFBFVCAwMDAwMDAwMDZlZGM0NWQ4IDAwMDM4ICh2MDEgQUxBU0tBICAgIEEgTSBJIDAxMDcyMDA5
IEFNSS4gMDAwMDAwMDQpClsgICAgMC4wMDAwMDBdIEFDUEk6IFhNQVIgMDAwMDAwMDA2ZWRjNDYx
MCAwMDBFOCAodjAxIEFMQVNLQSAgICBBIE0gSSAwMDAwMDAwMSBJTlRMIDAwMDAwMDAxKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAw
MDAwXSBTZXR0aW5nIEFQSUMgcm91dGluZyB0byBjbHVzdGVyIHgyYXBpYy4KWyAgICAwLjAwMDAw
MF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5v
ZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMjAwMDAwMDAwClsgICAgMC4wMDAwMDBdIElu
aXRtZW0gc2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIwMDAwMDAwMApbICAg
IDAuMDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDFmZmZmYjAwMCAtIDAwMDAwMDAxZmZmZmZm
ZmZdClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAwMF0gICBETUEg
ICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAw
eDAwMDAxMDAwIC0+IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgICAweDAwMTAw
MDAwIC0+IDB4MDAyMDAwMDAKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IFBGTiBm
b3IgZWFjaCBub2RlClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzddIGFjdGl2ZSBQRk4g
cmFuZ2VzClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwOWQKWyAg
ICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApbICAgIDAuMDAwMDAw
XSAgICAgMDogMHgwMDAyMDIwMCAtPiAweDAwMDQwMDAwClsgICAgMC4wMDAwMDBdICAgICAwOiAw
eDAwMDQwMjAwIC0+IDB4MDAwNmVkNmQKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwNmVkZjIg
LT4gMHgwMDA2ZWRmMwpbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDA2ZWU3YiAtPiAweDAwMDZm
MDAwClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMTAwMDAwIC0+IDB4MDAyMDAwMDAKWyAgICAw
LjAwMDAwMF0gT24gbm9kZSAwIHRvdGFscGFnZXM6IDE1MDE4MjQKWyAgICAwLjAwMDAwMF0gICBE
TUEgem9uZTogNTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BIHpv
bmU6IDg1MiBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzMDczIHBh
Z2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAxNDI4MCBwYWdl
cyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MzQ5ODcgcGFn
ZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTogMTQzMzYgcGFn
ZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6IDEwMzQyNDAg
cGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9y
dDogMHg0MDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAw
MDAKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgw
MF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw
aWNfaWRbMHgwMl0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwNV0g
ZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNf
aWRbMHgwN10gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk
WzB4ZmZdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAo
aWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKWyAgICAwLjAwMDAwMF0g
SU9BUElDWzBdOiBhcGljX2lkIDAsIHZlcnNpb24gMjU1LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdT
SSAwLTI1NQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAw
IGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNl
ZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRl
LgpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g
aW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNl
OiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDogQWxsb3dpbmcgOCBDUFVzLCAwIGhvdHBs
dWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogMjcyClsgICAgMC4wMDAwMDBdIFBN
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAw
MDllMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw
MDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl
cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwClsg
ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNDAwMDAw
MDAgLSAwMDAwMDAwMDQwMjAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IDAwMDAwMDAwNmVkNmQwMDAgLSAwMDAwMDAwMDZlZGJjMDAwClsgICAgMC4wMDAw
MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVkYmMwMDAgLSAwMDAw
MDAwMDZlZGM1MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IDAwMDAwMDAwNmVkYzUwMDAgLSAwMDAwMDAwMDZlZGYyMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVkZjMwMDAgLSAwMDAwMDAwMDZlZTAz
MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw
NmVlMDMwMDAgLSAwMDAwMDAwMDZlZTEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk
IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVlMTAwMDAgLSAwMDAwMDAwMDZlZTM4MDAwClsgICAg
MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVlMzgwMDAg
LSAwMDAwMDAwMDZlZTdiMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IDAwMDAwMDAwNmYwMDAwMDAgLSAwMDAwMDAwMDZmODAwMDAwClsgICAgMC4wMDAwMDBd
IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmY4MDAwMDAgLSAwMDAwMDAw
MDdmYTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAw
MDAwMDAwN2ZhMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAw
ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVj
MDEwMDAgLSAwMDAwMDAwMGZlZDFjMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwClsgICAgMC4w
MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkNDAwMDAgLSAw
MDAwMDAwMGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwClsgICAgMC4wMDAwMDBdIFBN
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDEwMDAgLSAwMDAwMDAwMGZm
MDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw
MDAwZmYwMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcg
UENJIHJlc291cmNlcyBzdGFydGluZyBhdCA3ZmEwMDAwMCAoZ2FwOiA3ZmEwMDAwMDo3ZjIwMDAw
MCkKWyAgICAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpb
ICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4xLjIgKHByZXNlcnZlLUFEKQpbICAgIDAuMDAw
MDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6NTEyIG5yX2NwdW1hc2tfYml0czo1MTIgbnJfY3B1
X2lkczo4IG5yX25vZGVfaWRzOjEKWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAyOCBw
YWdlcy9jcHUgQGZmZmY4ODAxZmZlY2EwMDAgczgyMzA0IHI4MTkyIGQyNDE5MiB1MTE0Njg4Clsg
ICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IHM4MjMwNCByODE5MiBkMjQxOTIgdTExNDY4OCBhbGxv
Yz0yOCo0MDk2ClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIFswXSAxIFswXSAyIFsw
XSAzIFswXSA0IFswXSA1IFswXSA2IFswXSA3IApbICAgIDQuMDQwMjc4XSBCdWlsdCAxIHpvbmVs
aXN0cyBpbiBab25lIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAx
NDcyMzAwClsgICAgNC4wNDAyNzldIFBvbGljeSB6b25lOiBOb3JtYWwKWyAgICA0LjA0MDI4MV0g
S2VybmVsIGNvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgcm9vdD0vZGV2L21hcHBlci9tdWFkZGli
LXJvb3Qgcm8gcmRibGFja2xpc3Q9cmFkZW9uIHJhZGVvbi5tb2RzZXQ9MCBtZW09ODE5Mk0KWyAg
ICA0LjA0MDMzMV0gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4
IGJ5dGVzKQpbICAgIDQuMDU3MTkxXSBQbGFjaW5nIDY0TUIgc29mdHdhcmUgSU8gVExCIGJldHdl
ZW4gZmZmZjg4MDFmNWEwMDAwMCAtIGZmZmY4ODAxZjlhMDAwMDAKWyAgICA0LjA1NzE5M10gc29m
dHdhcmUgSU8gVExCIGF0IHBoeXMgMHgxZjVhMDAwMDAgLSAweDFmOWEwMDAwMApbICAgIDQuMDcz
MTExXSBNZW1vcnk6IDU3ODcyMjhrLzgzODg2MDhrIGF2YWlsYWJsZSAoMzM2OGsga2VybmVsIGNv
ZGUsIDIzODEzMTJrIGFic2VudCwgMjIwMDY4ayByZXNlcnZlZCwgMzM2MWsgZGF0YSwgNTY4ayBp
bml0KQpbICAgIDQuMDczMTc1XSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLgpbICAg
IDQuMDczMTc2XSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlz
IGVuYWJsZWQuClsgICAgNC4wNzMxODNdIE5SX0lSUVM6MzMwMjQgbnJfaXJxczoyMDQ4IDE2Clsg
ICAgNC4wNzMyMzRdIHhlbjogc2NpIG92ZXJyaWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBv
bGFyaXR5PTAKWyAgICA0LjA3MzIzN10geGVuOiByZWdpc3RlcmluZyBnc2kgOSB0cmlnZ2VyaW5n
IDAgcG9sYXJpdHkgMApbICAgIDQuMDczMjQzXSB4ZW46IC0tPiBwaXJxPTkgLT4gaXJxPTkgKGdz
aT05KQpbICAgIDQuMDczMjYyXSB4ZW46IGFjcGkgc2NpIDkKWyAgICA0LjA3MzI2NF0geGVuOiAt
LT4gcGlycT0xIC0+IGlycT0xIChnc2k9MSkKWyAgICA0LjA3MzI2N10geGVuOiAtLT4gcGlycT0y
IC0+IGlycT0yIChnc2k9MikKWyAgICA0LjA3MzI2OV0geGVuOiAtLT4gcGlycT0zIC0+IGlycT0z
IChnc2k9MykKWyAgICA0LjA3MzI3MV0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkK
WyAgICA0LjA3MzI3NF0geGVuOiAtLT4gcGlycT01IC0+IGlycT01IChnc2k9NSkKWyAgICA0LjA3
MzI3Nl0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikKWyAgICA0LjA3MzI3OF0geGVu
OiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykKWyAgICA0LjA3MzI4MV0geGVuOiAtLT4gcGly
cT04IC0+IGlycT04IChnc2k9OCkKWyAgICA0LjA3MzI4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSA5IGZvciBnc2kgOQpbICAgIDQuMDczMjg0XSB4ZW46IC0tPiBwaXJxPTkgLT4g
aXJxPTkgKGdzaT05KQpbICAgIDQuMDczMjg2XSB4ZW46IC0tPiBwaXJxPTEwIC0+IGlycT0xMCAo
Z3NpPTEwKQpbICAgIDQuMDczMjg4XSB4ZW46IC0tPiBwaXJxPTExIC0+IGlycT0xMSAoZ3NpPTEx
KQpbICAgIDQuMDczMjkxXSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0xMiAoZ3NpPTEyKQpbICAg
IDQuMDczMjkzXSB4ZW46IC0tPiBwaXJxPTEzIC0+IGlycT0xMyAoZ3NpPTEzKQpbICAgIDQuMDcz
Mjk1XSB4ZW46IC0tPiBwaXJxPTE0IC0+IGlycT0xNCAoZ3NpPTE0KQpbICAgIDQuMDczMjk4XSB4
ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAoZ3NpPTE1KQpbICAgIDQuMDc1MDYxXSBDb25zb2xl
OiBjb2xvdXIgVkdBKyA4MHgyNQpbICAgIDQuMDc5ODA3XSBjb25zb2xlIFt0dHkwXSBlbmFibGVk
ClsgICAgNC4wNzk4NThdIFhlbjogdXNpbmcgdmNwdW9wIHRpbWVyIGludGVyZmFjZQpbICAgIDQu
MDc5ODYxXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDAKWyAgICA0LjA3OTkwNF0gRGV0
ZWN0ZWQgMzM5Mi4zNzYgTUh6IHByb2Nlc3Nvci4KWyAgICA0LjA3OTkzOF0gQ2FsaWJyYXRpbmcg
ZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVl
bmN5Li4gNjc4NC43NSBCb2dvTUlQUyAobHBqPTEzNTY5NTA0KQpbICAgIDQuMDgwMDAxXSBwaWRf
bWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEKWyAgICA0LjA4MDA2NV0gU2VjdXJpdHkg
RnJhbWV3b3JrIGluaXRpYWxpemVkClsgICAgNC4wODAwOTZdIEFwcEFybW9yOiBBcHBBcm1vciBk
aXNhYmxlZCBieSBib290IHRpbWUgcGFyYW1ldGVyClsgICAgNC4wODE3NDBdIERlbnRyeSBjYWNo
ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEwNDg1NzYgKG9yZGVyOiAxMSwgODM4ODYwOCBieXRlcykK
WyAgICA0LjA4MzczOV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MjQyODggKG9y
ZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKWyAgICA0LjA4NDM3OV0gTW91bnQtY2FjaGUgaGFzaCB0
YWJsZSBlbnRyaWVzOiAyNTYKWyAgICA0LjA4NDUwNV0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJz
eXMgY3B1YWNjdApbICAgIDQuMDg0NTM3XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1v
cnkKWyAgICA0LjA4NDU3N10gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcwpbICAg
IDQuMDg0NjA3XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyClsgICAgNC4wODQ2
MzhdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKWyAgICA0LjA4NDY2OV0gSW5p
dGlhbGl6aW5nIGNncm91cCBzdWJzeXMgYmxraW8KWyAgICA0LjA4NDc0OV0gRU5FUkdZX1BFUkZf
QklBUzogU2V0IHRvICdub3JtYWwnLCB3YXMgJ3BlcmZvcm1hbmNlJwpbICAgIDQuMDg0NzQ5XSBF
TkVSR1lfUEVSRl9CSUFTOiBWaWV3IGFuZCB1cGRhdGUgd2l0aCB4ODZfZW5lcmd5X3BlcmZfcG9s
aWN5KDgpClsgICAgNC4wODQ4MTddIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwClsgICAg
NC4wODQ4NDZdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDAKWyAgICA0LjA4NTMwNF0gQUNQSTog
Q29yZSByZXZpc2lvbiAyMDExMDYyMwpbICAgIDQuMDk1MjA4XSBQZXJmb3JtYW5jZSBFdmVudHM6
IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCA0MiBubyBQTVUgZHJpdmVyLCBzb2Z0d2FyZSBldmVu
dHMgb25seS4KWyAgICA0LjA5NTM3MV0gTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUwKTogaGFy
ZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgNC4wOTU0ODldIGluc3RhbGxpbmcgWGVuIHRp
bWVyIGZvciBDUFUgMQpbICAgIDQuMDk1NjI2XSBOTUkgd2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTEp
OiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJsZWQKWyAgICA0LjA5NTY3OF0gQnJvdWdodCB1cCAy
IENQVXMKWyAgICA0LjA5NTg5N10gZGV2dG1wZnM6IGluaXRpYWxpemVkClsgICAgNC4wOTgwNzhd
IFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24gYXQgNmVkNmQwMDAgKDMyMzU4NCBieXRl
cykKWyAgICA0LjA5ODEyOF0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCA2ZWUw
MzAwMCAoNTMyNDggYnl0ZXMpClsgICAgNC4wOTk0NjBdIFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5W
UyByZWdpb24gYXQgNmVlMzgwMDAgKDI3NDQzMiBieXRlcykKWyAgICA0LjA5OTU3OF0gR3JhbnQg
dGFibGUgaW5pdGlhbGl6ZWQKWyAgICA0LjA5OTY2MF0gcHJpbnRfY29uc3RyYWludHM6IGR1bW15
OiAKWyAgICA0LjA5OTc0MF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpbICAg
IDQuMDk5OTI2XSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApbICAgIDQuMTAwMDE4XSBQ
Q0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4ZTAwMDAw
MDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkKWyAgICA0LjEwMDA2N10gUENJOiBub3Qg
dXNpbmcgTU1DT05GSUcKWyAgICA0LjEwMDA5N10gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5
cGUgMSBmb3IgYmFzZSBhY2Nlc3MKWyAgICA0LjEwMDc0OV0gYmlvOiBjcmVhdGUgc2xhYiA8Ymlv
LTA+IGF0IDAKWyAgICA0LjEwMDg4N10gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQpb
ICAgIDQuMTAwOTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpClsgICAgNC4x
MDA5NTBdIEFDUEk6IEFkZGVkIF9PU0koMy4wIF9TQ1AgRXh0ZW5zaW9ucykKWyAgICA0LjEwMDk4
MV0gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpClsgICAgNC4x
MDI3MDhdIEFDUEk6IEVDOiBMb29rIHVwIEVDIGluIERTRFQKWyAgICA0LjEwNDU0N10gQUNQSTog
RXhlY3V0ZWQgMSBibG9ja3Mgb2YgbW9kdWxlLWxldmVsIGV4ZWN1dGFibGUgQU1MIGNvZGUKWyAg
ICA0LjExMTgxOV0gQUNQSTogU1NEVCAwMDAwMDAwMDZlZTBmODk4IDAwNkY0ICh2MDEgICAgQU1J
ICAgICAgSVNUIDAwMDAwMDAxIE1TRlQgMDMwMDAwMDEpClsgICAgNC4xMTI1MThdIEFDUEk6IER5
bmFtaWMgT0VNIFRhYmxlIExvYWQ6ClsgICAgNC4xMTI1NzJdIEFDUEk6IFNTRFQgICAgICAgICAg
IChudWxsKSAwMDZGNCAodjAxICAgIEFNSSAgICAgIElTVCAwMDAwMDAwMSBNU0ZUIDAzMDAwMDAx
KQpbICAgIDQuMTEyNzA4XSBBQ1BJOiBTU0RUIDAwMDAwMDAwNmVlMDZkOTggMDAwRTQgKHYwMSAg
ICBBTUkgICAgICBDU1QgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkKWyAgICA0LjExMzIzMV0gQUNQ
STogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAgICA0LjExMzI4NV0gQUNQSTogU1NEVCAgICAg
ICAgICAgKG51bGwpIDAwMEU0ICh2MDEgICAgQU1JICAgICAgQ1NUIDAwMDAwMDAxIE1TRlQgMDMw
MDAwMDEpClsgICAgNC4xMTM4MzJdIEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQKWyAgICA0LjEx
Mzg2M10gQUNQSTogKHN1cHBvcnRzIFMwIFMxIFMzIFM0IFM1KQpbICAgIDQuMTEzOTc1XSBBQ1BJ
OiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nClsgICAgNC4xMTQwMzRdIFBDSTog
TU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0w
eGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQpbICAgIDQuMTE0MTg3XSBQQ0k6IE1NQ09ORklH
IGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZlZCBpbiBBQ1BJIG1vdGhlcmJv
YXJkIHJlc291cmNlcwpbICAgIDQuMTY2ODUxXSBbRmlybXdhcmUgQnVnXTogQUNQSTogQklPUyBf
T1NJKExpbnV4KSBxdWVyeSBpZ25vcmVkClsgICAgNC4xNzQwNjVdIEFDUEk6IE5vIGRvY2sgZGV2
aWNlcyBmb3VuZC4KWyAgICA0LjE3NDA5Nl0gSEVTVDogVGFibGUgbm90IGZvdW5kLgpbICAgIDQu
MTc0MTI2XSBQQ0k6IFVzaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBpZiBuZWNl
c3NhcnksIHVzZSAicGNpPW5vY3JzIiBhbmQgcmVwb3J0IGEgYnVnClsgICAgNC4xNzQ2MDRdIEFD
UEk6IFBDSSBSb290IEJyaWRnZSBbUENJMF0gKGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdKQpbICAg
IDQuMTc1MDYzXSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAw
eDAwMDAtMHgwM2FmXQpbICAgIDQuMTc1MDk4XSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJy
aWRnZSB3aW5kb3cgW2lvICAweDAzZTAtMHgwY2Y3XQpbICAgIDQuMTc1MTMyXSBwY2lfcm9vdCBQ
TlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDAzYjAtMHgwM2RmXQpbICAgIDQu
MTc1MTY2XSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDBk
MDAtMHhmZmZmXQpbICAgIDQuMTc1MjAwXSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRn
ZSB3aW5kb3cgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgNC4xNzUyNDVdIHBjaV9y
b290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwYzAwMDAtMHgwMDBk
ZmZmZl0KWyAgICA0LjE3NTI5MV0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2lu
ZG93IFttZW0gMHg3ZmEwMDAwMC0weGZmZmZmZmZmXQpbICAgIDQuMTc1MzUxXSBwY2kgMDAwMDow
MDowMC4wOiBbODA4NjowMTAwXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDAKWyAgICA0LjE3NTQyOV0g
cGNpIDAwMDA6MDA6MDEuMDogWzgwODY6MDEwMV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAg
NC4xNzU1MDZdIHBjaSAwMDAwOjAwOjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkClsgICAgNC4xNzU1MDldIHBjaSAwMDAwOjAwOjAxLjA6IFBNRSMgZGlzYWJsZWQKWyAg
ICA0LjE3NTU0OF0gcGNpIDAwMDA6MDA6MDIuMDogWzgwODY6MDEwMl0gdHlwZSAwIGNsYXNzIDB4
MDAwMzAwClsgICAgNC4xNzU1NzFdIHBjaSAwMDAwOjAwOjAyLjA6IHJlZyAxMDogW21lbSAweGZi
NDAwMDAwLTB4ZmI3ZmZmZmYgNjRiaXRdClsgICAgNC4xNzU1ODNdIHBjaSAwMDAwOjAwOjAyLjA6
IHJlZyAxODogW21lbSAweGIwMDAwMDAwLTB4YmZmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICA0LjE3
NTU5Ml0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDIwOiBbaW8gIDB4ZjAwMC0weGYwM2ZdClsgICAg
NC4xNzU3MTNdIHBjaSAwMDAwOjAwOjE2LjA6IFs4MDg2OjFjM2FdIHR5cGUgMCBjbGFzcyAweDAw
MDc4MApbICAgIDQuMTc1NzU3XSBwY2kgMDAwMDowMDoxNi4wOiByZWcgMTA6IFttZW0gMHhmYmYw
NDAwMC0weGZiZjA0MDBmIDY0Yml0XQpbICAgIDQuMTc1OTA4XSBwY2kgMDAwMDowMDoxNi4wOiBQ
TUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc1OTEzXSBwY2kgMDAw
MDowMDoxNi4wOiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzU5NzZdIHBjaSAwMDAwOjAwOjFhLjA6
IFs4MDg2OjFjMmRdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDQuMTc2MDE1XSBwY2kgMDAw
MDowMDoxYS4wOiByZWcgMTA6IFttZW0gMHhmYmYwMzAwMC0weGZiZjAzM2ZmXQpbICAgIDQuMTc2
MTk3XSBwY2kgMDAwMDowMDoxYS4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29s
ZApbICAgIDQuMTc2MjAzXSBwY2kgMDAwMDowMDoxYS4wOiBQTUUjIGRpc2FibGVkClsgICAgNC4x
NzYyNDRdIHBjaSAwMDAwOjAwOjFjLjA6IFs4MDg2OjFjMTBdIHR5cGUgMSBjbGFzcyAweDAwMDYw
NApbICAgIDQuMTc2NDA5XSBwY2kgMDAwMDowMDoxYy4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQzaG90IEQzY29sZApbICAgIDQuMTc2NDE1XSBwY2kgMDAwMDowMDoxYy4wOiBQTUUjIGRpc2Fi
bGVkClsgICAgNC4xNzY0NjZdIHBjaSAwMDAwOjAwOjFjLjQ6IFs4MDg2OjFjMThdIHR5cGUgMSBj
bGFzcyAweDAwMDYwNApbICAgIDQuMTc2NjMyXSBwY2kgMDAwMDowMDoxYy40OiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc2NjM4XSBwY2kgMDAwMDowMDoxYy40
OiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzY2ODVdIHBjaSAwMDAwOjAwOjFjLjU6IFs4MDg2OjFj
MWFdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDQuMTc2ODQ5XSBwY2kgMDAwMDowMDoxYy41
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc2ODU1XSBwY2kg
MDAwMDowMDoxYy41OiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzY5MDBdIHBjaSAwMDAwOjAwOjFj
LjY6IFs4MDg2OjFjMWNdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDQuMTc3MDY0XSBwY2kg
MDAwMDowMDoxYy42OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQu
MTc3MDcwXSBwY2kgMDAwMDowMDoxYy42OiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzcxMTZdIHBj
aSAwMDAwOjAwOjFjLjc6IFs4MDg2OjFjMWVdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDQu
MTc3MjgyXSBwY2kgMDAwMDowMDoxYy43OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQz
Y29sZApbICAgIDQuMTc3Mjg4XSBwY2kgMDAwMDowMDoxYy43OiBQTUUjIGRpc2FibGVkClsgICAg
NC4xNzczNDBdIHBjaSAwMDAwOjAwOjFkLjA6IFs4MDg2OjFjMjZdIHR5cGUgMCBjbGFzcyAweDAw
MGMwMwpbICAgIDQuMTc3MzgwXSBwY2kgMDAwMDowMDoxZC4wOiByZWcgMTA6IFttZW0gMHhmYmYw
MjAwMC0weGZiZjAyM2ZmXQpbICAgIDQuMTc3NTYxXSBwY2kgMDAwMDowMDoxZC4wOiBQTUUjIHN1
cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc3NTY4XSBwY2kgMDAwMDowMDox
ZC4wOiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzc2MDhdIHBjaSAwMDAwOjAwOjFmLjA6IFs4MDg2
OjFjNDRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMQpbICAgIDQuMTc3ODQwXSBwY2kgMDAwMDowMDox
Zi4yOiBbODA4NjoxYzAyXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDYKWyAgICA0LjE3Nzg4MV0gcGNp
IDAwMDA6MDA6MWYuMjogcmVnIDEwOiBbaW8gIDB4ZjBiMC0weGYwYjddClsgICAgNC4xNzc4OTdd
IHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxNDogW2lvICAweGYwYTAtMHhmMGEzXQpbICAgIDQuMTc3
OTEyXSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTg6IFtpbyAgMHhmMDkwLTB4ZjA5N10KWyAgICA0
LjE3NzkyOF0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDFjOiBbaW8gIDB4ZjA4MC0weGYwODNdClsg
ICAgNC4xNzc5NDNdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAyMDogW2lvICAweGYwNjAtMHhmMDdm
XQpbICAgIDQuMTc3OTU5XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMjQ6IFttZW0gMHhmYmYwMTAw
MC0weGZiZjAxN2ZmXQpbICAgIDQuMTc4MDYyXSBwY2kgMDAwMDowMDoxZi4yOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQzaG90ClsgICAgNC4xNzgwNjddIHBjaSAwMDAwOjAwOjFmLjI6IFBNRSMgZGlz
YWJsZWQKWyAgICA0LjE3ODA5OV0gcGNpIDAwMDA6MDA6MWYuMzogWzgwODY6MWMyMl0gdHlwZSAw
IGNsYXNzIDB4MDAwYzA1ClsgICAgNC4xNzgxMzBdIHBjaSAwMDAwOjAwOjFmLjM6IHJlZyAxMDog
W21lbSAweGZiZjAwMDAwLTB4ZmJmMDAwZmYgNjRiaXRdClsgICAgNC4xNzgxNzVdIHBjaSAwMDAw
OjAwOjFmLjM6IHJlZyAyMDogW2lvICAweGYwNDAtMHhmMDVmXQpbICAgIDQuMTc4MjkyXSBwY2kg
MDAwMDowMTowMC4wOiBbMTAwMjo2NzE5XSB0eXBlIDAgY2xhc3MgMHgwMDAzMDAKWyAgICA0LjE3
ODMxNF0gcGNpIDAwMDA6MDE6MDAuMDogcmVnIDEwOiBbbWVtIDB4YzAwMDAwMDAtMHhjZmZmZmZm
ZiA2NGJpdCBwcmVmXQpbICAgIDQuMTc4MzMxXSBwY2kgMDAwMDowMTowMC4wOiByZWcgMTg6IFtt
ZW0gMHhmYmUyMDAwMC0weGZiZTNmZmZmIDY0Yml0XQpbICAgIDQuMTc4MzQzXSBwY2kgMDAwMDow
MTowMC4wOiByZWcgMjA6IFtpbyAgMHhlMDAwLTB4ZTBmZl0KWyAgICA0LjE3ODM2NV0gcGNpIDAw
MDA6MDE6MDAuMDogcmVnIDMwOiBbbWVtIDB4ZmJlMDAwMDAtMHhmYmUxZmZmZiBwcmVmXQpbICAg
IDQuMTc4NDIxXSBwY2kgMDAwMDowMTowMC4wOiBzdXBwb3J0cyBEMSBEMgpbICAgIDQuMTc4NDU1
XSBwY2kgMDAwMDowMTowMC4xOiBbMTAwMjphYTgwXSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMKWyAg
ICA0LjE3ODQ3Nl0gcGNpIDAwMDA6MDE6MDAuMTogcmVnIDEwOiBbbWVtIDB4ZmJlNDAwMDAtMHhm
YmU0M2ZmZiA2NGJpdF0KWyAgICA0LjE3ODU4M10gcGNpIDAwMDA6MDE6MDAuMTogc3VwcG9ydHMg
RDEgRDIKWyAgICA0LjE4NTM5MV0gcGNpIDAwMDA6MDA6MDEuMDogUENJIGJyaWRnZSB0byBbYnVz
IDAxLTAxXQpbICAgIDQuMTg1NDQ1XSBwY2kgMDAwMDowMDowMS4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDQuMTg1NDQ5XSBwY2kgMDAwMDowMDowMS4wOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGZiZTAwMDAwLTB4ZmJlZmZmZmZdClsgICAgNC4xODU0NTVdIHBj
aSAwMDAwOjAwOjAxLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4YzAwMDAwMDAtMHhjZmZmZmZm
ZiA2NGJpdCBwcmVmXQpbICAgIDQuMTg1NTgxXSBwY2kgMDAwMDowMjowMC4wOiBbMTBiNTo4MTEy
XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE4NTgzMV0gcGNpIDAwMDA6MDI6MDAuMDog
ZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEuMSBQQ0llIGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0
IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScKWyAgICA0LjE4NTg5N10gcGNpIDAwMDA6MDA6MWMuMDog
UENJIGJyaWRnZSB0byBbYnVzIDAyLTAzXQpbICAgIDQuMTg1OTMzXSBwY2kgMDAwMDowMDoxYy4w
OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDQuMTg2MDkzXSBwY2kg
MDAwMDowMzowNC4wOiBbMTNmNjo4Nzg4XSB0eXBlIDAgY2xhc3MgMHgwMDA0MDEKWyAgICA0LjE4
NjE0NF0gcGNpIDAwMDA6MDM6MDQuMDogcmVnIDEwOiBbaW8gIDB4ZDAwMC0weGQwZmZdClsgICAg
NC4xODYzODldIHBjaSAwMDAwOjAzOjA0LjA6IHN1cHBvcnRzIEQxIEQyClsgICAgNC4xODY1MDZd
IHBjaSAwMDAwOjAyOjAwLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMy0wM10KWyAgICA0LjE4NjU0
NV0gcGNpIDAwMDA6MDI6MDAuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0K
WyAgICA0LjE4NjcwMF0gcGNpIDAwMDA6MDQ6MDAuMDogWzFiNGI6OTEyMF0gdHlwZSAwIGNsYXNz
IDB4MDAwMTA2ClsgICAgNC4xODY3MjhdIHBjaSAwMDAwOjA0OjAwLjA6IHJlZyAxMDogW2lvICAw
eGMwNDAtMHhjMDQ3XQpbICAgIDQuMTg2NzQ4XSBwY2kgMDAwMDowNDowMC4wOiByZWcgMTQ6IFtp
byAgMHhjMDMwLTB4YzAzM10KWyAgICA0LjE4Njc2OF0gcGNpIDAwMDA6MDQ6MDAuMDogcmVnIDE4
OiBbaW8gIDB4YzAyMC0weGMwMjddClsgICAgNC4xODY3ODldIHBjaSAwMDAwOjA0OjAwLjA6IHJl
ZyAxYzogW2lvICAweGMwMTAtMHhjMDEzXQpbICAgIDQuMTg2ODA5XSBwY2kgMDAwMDowNDowMC4w
OiByZWcgMjA6IFtpbyAgMHhjMDAwLTB4YzAwZl0KWyAgICA0LjE4NjgzMF0gcGNpIDAwMDA6MDQ6
MDAuMDogcmVnIDI0OiBbbWVtIDB4ZmJkMTAwMDAtMHhmYmQxMDdmZl0KWyAgICA0LjE4Njg1MV0g
cGNpIDAwMDA6MDQ6MDAuMDogcmVnIDMwOiBbbWVtIDB4ZmJkMDAwMDAtMHhmYmQwZmZmZiBwcmVm
XQpbICAgIDQuMTg2OTUwXSBwY2kgMDAwMDowNDowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQz
aG90ClsgICAgNC4xODY5NTddIHBjaSAwMDAwOjA0OjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA0
LjE4NzAyNF0gcGNpIDAwMDA6MDA6MWMuNDogUENJIGJyaWRnZSB0byBbYnVzIDA0LTA0XQpbICAg
IDQuMTg3MDYwXSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMwMDAt
MHhjZmZmXQpbICAgIDQuMTg3MDY2XSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cg
W21lbSAweGZiZDAwMDAwLTB4ZmJkZmZmZmZdClsgICAgNC4xODcxOThdIHBjaSAwMDAwOjA1OjAw
LjA6IFsxYjZmOjcwMjNdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDQuMTg3MjQwXSBwY2kg
MDAwMDowNTowMC4wOiByZWcgMTA6IFttZW0gMHhmYmMwMDAwMC0weGZiYzA3ZmZmIDY0Yml0XQpb
ICAgIDQuMTg3NDQ3XSBwY2kgMDAwMDowNTowMC4wOiBzdXBwb3J0cyBEMSBEMgpbICAgIDQuMTg3
NDQ5XSBwY2kgMDAwMDowNTowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90
IEQzY29sZApbICAgIDQuMTg3NDU2XSBwY2kgMDAwMDowNTowMC4wOiBQTUUjIGRpc2FibGVkClsg
ICAgNC4xODc1MzVdIHBjaSAwMDAwOjAwOjFjLjU6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNS0wNV0K
WyAgICA0LjE4NzU3Nl0gcGNpIDAwMDA6MDA6MWMuNTogICBicmlkZ2Ugd2luZG93IFttZW0gMHhm
YmMwMDAwMC0weGZiY2ZmZmZmXQpbICAgIDQuMTg3NzA5XSBwY2kgMDAwMDowNjowMC4wOiBbMWI2
Zjo3MDIzXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMKWyAgICA0LjE4Nzc1MF0gcGNpIDAwMDA6MDY6
MDAuMDogcmVnIDEwOiBbbWVtIDB4ZmJiMDAwMDAtMHhmYmIwN2ZmZiA2NGJpdF0KWyAgICA0LjE4
Nzk1Nl0gcGNpIDAwMDA6MDY6MDAuMDogc3VwcG9ydHMgRDEgRDIKWyAgICA0LjE4Nzk1OF0gcGNp
IDAwMDA6MDY6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQK
WyAgICA0LjE4Nzk2NV0gcGNpIDAwMDA6MDY6MDAuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTg4
MDQ0XSBwY2kgMDAwMDowMDoxYy42OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDZdClsgICAgNC4x
ODgwODRdIHBjaSAwMDAwOjAwOjFjLjY6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmJiMDAwMDAt
MHhmYmJmZmZmZl0KWyAgICA0LjE4ODIxNV0gcGNpIDAwMDA6MDc6MDAuMDogWzEwYjU6ODYwOF0g
dHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgNC4xODgyNDNdIHBjaSAwMDAwOjA3OjAwLjA6IHJl
ZyAxMDogW21lbSAweGZiYTAwMDAwLTB4ZmJhMWZmZmZdClsgICAgNC4xODg0MjJdIHBjaSAwMDAw
OjA3OjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgNC4xODg0
MjldIHBjaSAwMDAwOjA3OjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA0LjE4ODUyOV0gcGNpIDAw
MDA6MDA6MWMuNzogUENJIGJyaWRnZSB0byBbYnVzIDA3LTEwXQpbICAgIDQuMTg4NTY1XSBwY2kg
MDAwMDowMDoxYy43OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQpbICAgIDQu
MTg4NTcwXSBwY2kgMDAwMDowMDoxYy43OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZiODAwMDAw
LTB4ZmJhZmZmZmZdClsgICAgNC4xODg1ODFdIHBjaSAwMDAwOjAwOjFjLjc6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMTg4NzM4
XSBwY2kgMDAwMDowODowMS4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAg
ICA0LjE4ODk1MF0gcGNpIDAwMDA6MDg6MDEuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQKWyAgICA0LjE4ODk1N10gcGNpIDAwMDA6MDg6MDEuMDogUE1FIyBkaXNhYmxlZApb
ICAgIDQuMTg5MDU0XSBwY2kgMDAwMDowODowNC4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3Mg
MHgwMDA2MDQKWyAgICA0LjE4OTI2NF0gcGNpIDAwMDA6MDg6MDQuMDogUE1FIyBzdXBwb3J0ZWQg
ZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE4OTI3MV0gcGNpIDAwMDA6MDg6MDQuMDogUE1F
IyBkaXNhYmxlZApbICAgIDQuMTg5MzYzXSBwY2kgMDAwMDowODowNS4wOiBbMTBiNTo4NjA4XSB0
eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE4OTU3NF0gcGNpIDAwMDA6MDg6MDUuMDogUE1F
IyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE4OTU4MV0gcGNpIDAwMDA6
MDg6MDUuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTg5Njc4XSBwY2kgMDAwMDowODowNi4wOiBb
MTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE4OTg4N10gcGNpIDAwMDA6
MDg6MDYuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE4OTg5
NV0gcGNpIDAwMDA6MDg6MDYuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTg5OTk0XSBwY2kgMDAw
MDowODowNy4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE5MDIw
M10gcGNpIDAwMDA6MDg6MDcuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQK
WyAgICA0LjE5MDIxMF0gcGNpIDAwMDA6MDg6MDcuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTkw
MzExXSBwY2kgMDAwMDowODowOC4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQK
WyAgICA0LjE5MDUyMF0gcGNpIDAwMDA6MDg6MDguMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE
M2hvdCBEM2NvbGQKWyAgICA0LjE5MDUyN10gcGNpIDAwMDA6MDg6MDguMDogUE1FIyBkaXNhYmxl
ZApbICAgIDQuMTkwNjMyXSBwY2kgMDAwMDowODowOS4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xh
c3MgMHgwMDA2MDQKWyAgICA0LjE5MDg0MV0gcGNpIDAwMDA6MDg6MDkuMDogUE1FIyBzdXBwb3J0
ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE5MDg0OV0gcGNpIDAwMDA6MDg6MDkuMDog
UE1FIyBkaXNhYmxlZApbICAgIDQuMTkwOTgyXSBwY2kgMDAwMDowNzowMC4wOiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDgtMTBdClsgICAgNC4xOTEwMjVdIHBjaSAwMDAwOjA3OjAwLjA6ICAgYnJpZGdl
IHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZdClsgICAgNC4xOTEwMzJdIHBjaSAwMDAwOjA3OjAw
LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmI4MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0LjE5
MTA0NV0gcGNpIDAwMDA6MDc6MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0w
eGQwMGZmZmZmIDY0Yml0IHByZWZdClsgICAgNC4xOTExNjddIHBjaSAwMDAwOjA4OjAxLjA6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwOS0wOV0KWyAgICA0LjE5MTM5M10gcGNpIDAwMDA6MGE6MDAuMDog
WzFiMjE6MTA4MF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgNC4xOTE2NTldIHBjaSAwMDAw
OjBhOjAwLjA6IHN1cHBvcnRzIEQxIEQyClsgICAgNC4xOTE2NjBdIHBjaSAwMDAwOjBhOjAwLjA6
IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QgRDNjb2xkClsgICAgNC4xOTE2Njld
IHBjaSAwMDAwOjBhOjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA0LjE5MTc2MF0gcGNpIDAwMDA6
MDg6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDBhLTBiXQpbICAgIDQuMTkyMDkzXSBwY2kgMDAw
MDowYTowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGItMGJdClsgICAgNC4xOTIzNDFdIHBjaSAw
MDAwOjBjOjAwLjA6IFsxMTA2OjM0MDNdIHR5cGUgMCBjbGFzcyAweDAwMGMwMApbICAgIDQuMTky
Mzg5XSBwY2kgMDAwMDowYzowMC4wOiByZWcgMTA6IFttZW0gMHhmYjkwMDAwMC0weGZiOTAwN2Zm
IDY0Yml0XQpbICAgIDQuMTkyNDE0XSBwY2kgMDAwMDowYzowMC4wOiByZWcgMTg6IFtpbyAgMHhi
MDAwLTB4YjBmZl0KWyAgICA0LjE5MjYzMF0gcGNpIDAwMDA6MGM6MDAuMDogc3VwcG9ydHMgRDIK
WyAgICA0LjE5MjYzMl0gcGNpIDAwMDA6MGM6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMiBE
M2hvdCBEM2NvbGQKWyAgICA0LjE5MjY0MF0gcGNpIDAwMDA6MGM6MDAuMDogUE1FIyBkaXNhYmxl
ZApbICAgIDQuMTkyNzM0XSBwY2kgMDAwMDowODowNS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGMt
MGNdClsgICAgNC4xOTI3NzZdIHBjaSAwMDAwOjA4OjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IDB4YjAwMC0weGJmZmZdClsgICAgNC4xOTI3ODNdIHBjaSAwMDAwOjA4OjA1LjA6ICAgYnJpZGdl
IHdpbmRvdyBbbWVtIDB4ZmI5MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0LjE5Mjk3MF0gcGNpIDAw
MDA6MGQ6MDAuMDogWzE0ZTQ6MTZiMV0gdHlwZSAwIGNsYXNzIDB4MDAwMjAwClsgICAgNC4xOTMw
MjBdIHBjaSAwMDAwOjBkOjAwLjA6IHJlZyAxMDogW21lbSAweGQwMDEwMDAwLTB4ZDAwMWZmZmYg
NjRiaXQgcHJlZl0KWyAgICA0LjE5MzA2MF0gcGNpIDAwMDA6MGQ6MDAuMDogcmVnIDE4OiBbbWVt
IDB4ZDAwMDAwMDAtMHhkMDAwZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMTkzMTM1XSBwY2kgMDAw
MDowZDowMC4wOiByZWcgMzA6IFttZW0gMHhmYjgwMDAwMC0weGZiODAwN2ZmIHByZWZdClsgICAg
NC4xOTMyODFdIHBjaSAwMDAwOjBkOjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkClsgICAgNC4xOTMyODldIHBjaSAwMDAwOjBkOjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAg
ICA0LjE5MzQxMF0gcGNpIDAwMDA6MDg6MDYuMDogUENJIGJyaWRnZSB0byBbYnVzIDBkLTBkXQpb
ICAgIDQuMTkzNDU4XSBwY2kgMDAwMDowODowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZi
ODAwMDAwLTB4ZmI4ZmZmZmZdClsgICAgNC4xOTM0NzFdIHBjaSAwMDAwOjA4OjA2LjA6ICAgYnJp
ZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQu
MTkzNTk1XSBwY2kgMDAwMDowODowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGUtMGVdClsgICAg
NC4xOTM3NzZdIHBjaSAwMDAwOjA4OjA4LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwZi0wZl0KWyAg
ICA0LjE5Mzk2Ml0gcGNpIDAwMDA6MDg6MDkuMDogUENJIGJyaWRnZSB0byBbYnVzIDEwLTEwXQpb
ICAgIDQuMTk0MTY5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBD
STAuX1BSVF0KWyAgICA0LjE5NDM1Ml0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxl
IFtcX1NCXy5QQ0kwLlBFWDAuX1BSVF0KWyAgICA0LjE5NDQwNF0gQUNQSTogUENJIEludGVycnVw
dCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDQuX1BSVF0KWyAgICA0LjE5NDQ0N10gQUNQ
STogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDUuX1BSVF0KWyAg
ICA0LjE5NDQ5MF0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw
LlBFWDYuX1BSVF0KWyAgICA0LjE5NDUzM10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRh
YmxlIFtcX1NCXy5QQ0kwLlBFWDcuX1BSVF0KWyAgICA0LjE5NDU3OV0gQUNQSTogUENJIEludGVy
cnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDcuQlIyMS5fUFJUXQpbICAgIDQuMTk0
NzY5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVYNy5C
UjIxLkJSMzEuX1BSVF0KWyAgICA0LjE5NDgxOF0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5n
IFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDcuQlIyMS5CUjM0Ll9QUlRdClsgICAgNC4xOTQ4NjhdIEFD
UEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QRVg3LkJSMjEuQlIz
NC5CUjIyLl9QUlRdClsgICAgNC4xOTQ5NDBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU
YWJsZSBbXF9TQl8uUENJMC5QRVg3LkJSMjEuQlIzNS5fUFJUXQpbICAgIDQuMTk0OTg4XSBBQ1BJ
OiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVYNy5CUjIxLkJSMzYu
X1BSVF0KWyAgICA0LjE5NTAzNl0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtc
X1NCXy5QQ0kwLlBFWDcuQlIyMS5CUjM3Ll9QUlRdClsgICAgNC4xOTUwODRdIEFDUEk6IFBDSSBJ
bnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QRVg3LkJSMjEuQlIzOC5fUFJUXQpb
ICAgIDQuMTk1MTMyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBD
STAuUEVYNy5CUjIxLkJSMzkuX1BSVF0KWyAgICA0LjE5NTE3NV0gQUNQSTogUENJIEludGVycnVw
dCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlAwUDEuX1BSVF0KWyAgICA0LjE5NTM2OV0gIHBj
aTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpClsgICAgNC4xOTU3
OTRdICBwY2kwMDAwOjAwOiBBQ1BJIF9PU0MgY29udHJvbCAoMHgxYykgZ3JhbnRlZApbICAgIDQu
MjAyNjkwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDMgNCA1IDYgNyAx
MCAqMTEgMTIgMTQgMTUpClsgICAgNC4yMDI5MjZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb
TE5LQl0gKElSUXMgMyA0IDUgNiA3ICoxMCAxMSAxMiAxNCAxNSkKWyAgICA0LjIwMzE1OF0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAzIDQgKjUgNiAxMCAxMSAxMiAxNCAx
NSkKWyAgICA0LjIwMzM3Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAq
MyA0IDUgNiAxMCAxMSAxMiAxNCAxNSkKWyAgICA0LjIwMzU5NV0gQUNQSTogUENJIEludGVycnVw
dCBMaW5rIFtMTktFXSAoSVJRcyAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUpICowClsgICAgNC4y
MDM4NDhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRl0gKElSUXMgMyA0IDUgNiA3IDEw
IDExIDEyIDE0IDE1KSAqMApbICAgIDQuMjA0MTAyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg
W0xOS0ddIChJUlFzIDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNSkgKjAKWyAgICA0LjIwNDM1NV0g
QUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktIXSAoSVJRcyAzIDQgNSA2ICo3IDEwIDExIDEy
IDE0IDE1KQpbICAgIDQuMjA0NTY0XSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDQuMjA0NjExXSB4ZW4tYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDQuMjA0NzA2XSB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDA6
MDIuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lClsgICAgNC4yMDQ3NjJd
IHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6MDAwMDowMTowMC4wLGRlY29kZXM9aW8rbWVtLG93
bnM9bm9uZSxsb2Nrcz1ub25lClsgICAgNC4yMDQ4MTVdIHZnYWFyYjogbG9hZGVkClsgICAgNC4y
MDQ4NDJdIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMTowMC4wClsgICAg
NC4yMDQ4NzNdIHZnYWFyYjogbm8gYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMDowMi4w
ClsgICAgNC4yMDQ5MzVdIFBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcKWyAgICA0LjIx
OTQ5MF0gUENJOiBwY2lfY2FjaGVfbGluZV9zaXplIHNldCB0byA2NCBieXRlcwpbICAgIDQuMjE5
Njc0XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAwMDlm
ZmZmIApbICAgIDQuMjE5Njc2XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwNmVkNmQwMDAg
LSAwMDAwMDAwMDZmZmZmZmZmIApbICAgIDQuMjE5NjgwXSByZXNlcnZlIFJBTSBidWZmZXI6IDAw
MDAwMDAwNmVkZjMwMDAgLSAwMDAwMDAwMDZmZmZmZmZmIApbICAgIDQuMjE5NjgzXSByZXNlcnZl
IFJBTSBidWZmZXI6IDAwMDAwMDAwNmYwMDAwMDAgLSAwMDAwMDAwMDZmZmZmZmZmIApbICAgIDQu
MjE5Nzg0XSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3VyY2UgeGVuClsgICAgNC4yMjEzNDRdIHBucDog
UG5QIEFDUEkgaW5pdApbICAgIDQuMjIxMzgyXSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJl
ZApbICAgIDQuMjIxNjI5XSBwbnAgMDA6MDA6IFtidXMgMDAtZmZdClsgICAgNC4yMjE2MzFdIHBu
cCAwMDowMDogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDQuMjIxNjMzXSBwbnAgMDA6MDA6IFtp
byAgMHgwMDAwLTB4MDNhZiB3aW5kb3ddClsgICAgNC4yMjE2MzVdIHBucCAwMDowMDogW2lvICAw
eDAzZTAtMHgwY2Y3IHdpbmRvd10KWyAgICA0LjIyMTYzNl0gcG5wIDAwOjAwOiBbaW8gIDB4MDNi
MC0weDAzZGYgd2luZG93XQpbICAgIDQuMjIxNjM4XSBwbnAgMDA6MDA6IFtpbyAgMHgwZDAwLTB4
ZmZmZiB3aW5kb3ddClsgICAgNC4yMjE2NDBdIHBucCAwMDowMDogW21lbSAweDAwMGEwMDAwLTB4
MDAwYmZmZmYgd2luZG93XQpbICAgIDQuMjIxNjQxXSBwbnAgMDA6MDA6IFttZW0gMHgwMDBjMDAw
MC0weDAwMGRmZmZmIHdpbmRvd10KWyAgICA0LjIyMTY0M10gcG5wIDAwOjAwOiBbbWVtIDB4N2Zh
MDAwMDAtMHhmZmZmZmZmZiB3aW5kb3ddClsgICAgNC4yMjE2NDVdIHBucCAwMDowMDogW21lbSAw
eDAwMDAwMDAwIHdpbmRvd10KWyAgICA0LjIyMTY4N10gcG5wIDAwOjAwOiBQbHVnIGFuZCBQbGF5
IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAzIChhY3RpdmUpClsgICAgNC4yMjE3ODZd
IHBucCAwMDowMTogW21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZdClsgICAgNC4yMjE3ODddIHBu
cCAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdClsgICAgNC4yMjE3ODldIHBucCAw
MDowMTogW21lbSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdClsgICAgNC4yMjE3OTFdIHBucCAwMDow
MTogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdClsgICAgNC4yMjE3OTJdIHBucCAwMDowMTog
W21lbSAweGZlZTAwMDAwLTB4ZmVlMGZmZmZdClsgICAgNC4yMjE4MzNdIHN5c3RlbSAwMDowMTog
W21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjE4
NjhdIHN5c3RlbSAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIGhhcyBiZWVuIHJl
c2VydmVkClsgICAgNC4yMjE5MDJdIHN5c3RlbSAwMDowMTogW21lbSAweGZlZDkwMDAwLTB4ZmVk
OTNmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjE5MzddIHN5c3RlbSAwMDowMTogW21l
bSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjE5NzFd
IHN5c3RlbSAwMDowMTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMGZmZmZdIGNvdWxkIG5vdCBiZSBy
ZXNlcnZlZApbICAgIDQuMjIyMDA2XSBzeXN0ZW0gMDA6MDE6IFBsdWcgYW5kIFBsYXkgQUNQSSBk
ZXZpY2UsIElEcyBQTlAwYzAxIChhY3RpdmUpClsgICAgNC4yMjIwOTBdIHBucCAwMDowMjogW2lv
ICAweDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZmIGRpc2FibGVkXQpbICAgIDQuMjIyMDkyXSBwbnAg
MDA6MDI6IFtpbyAgMHgwMjkwLTB4MDI5Zl0KWyAgICA0LjIyMjA5M10gcG5wIDAwOjAyOiBbaW8g
IDB4MDAwMC0weGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgNC4yMjIxMzFdIHN5c3Rl
bSAwMDowMjogW2lvICAweDAyOTAtMHgwMjlmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDQuMjIy
MTY1XSBzeXN0ZW0gMDA6MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAy
IChhY3RpdmUpClsgICAgNC4yMjI2NDVdIHBucCAwMDowMzogW2RtYSA0XQpbICAgIDQuMjIyNjQ3
XSBwbnAgMDA6MDM6IFtpbyAgMHgwMDAwLTB4MDAwZl0KWyAgICA0LjIyMjY0OV0gcG5wIDAwOjAz
OiBbaW8gIDB4MDA4MS0weDAwODNdClsgICAgNC4yMjI2NTFdIHBucCAwMDowMzogW2lvICAweDAw
ODddClsgICAgNC4yMjI2NTNdIHBucCAwMDowMzogW2lvICAweDAwODktMHgwMDhiXQpbICAgIDQu
MjIyNjU0XSBwbnAgMDA6MDM6IFtpbyAgMHgwMDhmXQpbICAgIDQuMjIyNjU1XSBwbnAgMDA6MDM6
IFtpbyAgMHgwMGMwLTB4MDBkZl0KWyAgICA0LjIyMjY3N10gcG5wIDAwOjAzOiBQbHVnIGFuZCBQ
bGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDIwMCAoYWN0aXZlKQpbICAgIDQuMjIyNjg4XSBwbnAg
MDA6MDQ6IFtpbyAgMHgwMDcwLTB4MDA3MV0KWyAgICA0LjIyMjY5MF0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgOCB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDQuMjIyNjkzXSB4ZW5fbWFwX3Bp
cnFfZ3NpOiByZXR1cm5pbmcgaXJxIDggZm9yIGdzaSA4ClsgICAgNC4yMjI3MjVdIHhlbjogLS0+
IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgNC4yMjI3NDNdIHBucCAwMDowNDogW2lycSA4
XQpbICAgIDQuMjIyNzY0XSBwbnAgMDA6MDQ6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE
cyBQTlAwYjAwIChhY3RpdmUpClsgICAgNC4yMjI3NzNdIHBucCAwMDowNTogW2lvICAweDAwNjFd
ClsgICAgNC4yMjI3OTNdIHBucCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDA4MDAgKGFjdGl2ZSkKWyAgICA0LjIyMjgxOV0gcG5wIDAwOjA2OiBbaW8gIDB4MDAxMC0w
eDAwMWZdClsgICAgNC4yMjI4MjFdIHBucCAwMDowNjogW2lvICAweDAwMjItMHgwMDNmXQpbICAg
IDQuMjIyODIyXSBwbnAgMDA6MDY6IFtpbyAgMHgwMDQ0LTB4MDA1Zl0KWyAgICA0LjIyMjgyNF0g
cG5wIDAwOjA2OiBbaW8gIDB4MDA2Mi0weDAwNjNdClsgICAgNC4yMjI4MjVdIHBucCAwMDowNjog
W2lvICAweDAwNjUtMHgwMDZmXQpbICAgIDQuMjIyODI3XSBwbnAgMDA6MDY6IFtpbyAgMHgwMDcy
LTB4MDA3Zl0KWyAgICA0LjIyMjgyOF0gcG5wIDAwOjA2OiBbaW8gIDB4MDA4MF0KWyAgICA0LjIy
MjgzMF0gcG5wIDAwOjA2OiBbaW8gIDB4MDA4NC0weDAwODZdClsgICAgNC4yMjI4MzFdIHBucCAw
MDowNjogW2lvICAweDAwODhdClsgICAgNC4yMjI4MzNdIHBucCAwMDowNjogW2lvICAweDAwOGMt
MHgwMDhlXQpbICAgIDQuMjIyODM0XSBwbnAgMDA6MDY6IFtpbyAgMHgwMDkwLTB4MDA5Zl0KWyAg
ICA0LjIyMjgzNV0gcG5wIDAwOjA2OiBbaW8gIDB4MDBhMi0weDAwYmZdClsgICAgNC4yMjI4Mzdd
IHBucCAwMDowNjogW2lvICAweDAwZTAtMHgwMGVmXQpbICAgIDQuMjIyODM4XSBwbnAgMDA6MDY6
IFtpbyAgMHgwNGQwLTB4MDRkMV0KWyAgICA0LjIyMjg4MV0gc3lzdGVtIDAwOjA2OiBbaW8gIDB4
MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjI5MTVdIHN5c3RlbSAwMDow
NjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICA0
LjIyMjkyM10gcG5wIDAwOjA3OiBbaW8gIDB4MDBmMC0weDAwZmZdClsgICAgNC4yMjI5MjVdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDEzIHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgNC4yMjI5
MjddIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwpbICAgIDQu
MjIyOTU5XSB4ZW46IC0tPiBwaXJxPTEzIC0+IGlycT0xMyAoZ3NpPTEzKQpbICAgIDQuMjIyOTc2
XSBwbnAgMDA6MDc6IFtpcnEgMTNdClsgICAgNC4yMjI5OTldIHBucCAwMDowNzogUGx1ZyBhbmQg
UGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDQgKGFjdGl2ZSkKWyAgICA0LjIyMzM5Nl0gcG5w
IDAwOjA4OiBbaW8gIDB4MDNmOC0weDAzZmZdClsgICAgNC4yMjMzOThdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDQgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICA0LjIyMzQwMF0geGVuX21hcF9w
aXJxX2dzaTogcmV0dXJuaW5nIGlycSA0IGZvciBnc2kgNApbICAgIDQuMjIzNDMyXSB4ZW46IC0t
PiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQpbICAgIDQuMjIzNDQ4XSBwbnAgMDA6MDg6IFtpcnEg
NF0KWyAgICA0LjIyMzQ1MF0gcG5wIDAwOjA4OiBbZG1hIDAgZGlzYWJsZWRdClsgICAgNC4yMjM1
MDBdIHBucCAwMDowODogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEgKGFj
dGl2ZSkKWyAgICA0LjIyMzgxNV0gcG5wIDAwOjA5OiBbaW8gIDB4MDQwMC0weDA0NTNdClsgICAg
NC4yMjM4MTddIHBucCAwMDowOTogW2lvICAweDA0NTgtMHgwNDdmXQpbICAgIDQuMjIzODE4XSBw
bnAgMDA6MDk6IFtpbyAgMHgxMTgwLTB4MTE5Zl0KWyAgICA0LjIyMzgyMF0gcG5wIDAwOjA5OiBb
aW8gIDB4MDUwMC0weDA1N2ZdClsgICAgNC4yMjM4MjJdIHBucCAwMDowOTogW21lbSAweGZlZDFj
MDAwLTB4ZmVkMWZmZmZdClsgICAgNC4yMjM4MjNdIHBucCAwMDowOTogW21lbSAweGZlYzAwMDAw
LTB4ZmVjZmZmZmZdClsgICAgNC4yMjM4MjVdIHBucCAwMDowOTogW21lbSAweGZlZDA4MDAwLTB4
ZmVkMDhmZmZdClsgICAgNC4yMjM4MjZdIHBucCAwMDowOTogW21lbSAweGZmMDAwMDAwLTB4ZmZm
ZmZmZmZdClsgICAgNC4yMjM4NzFdIHN5c3RlbSAwMDowOTogW2lvICAweDA0MDAtMHgwNDUzXSBo
YXMgYmVlbiByZXNlcnZlZApbICAgIDQuMjIzOTA1XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwNDU4
LTB4MDQ3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICA0LjIyMzkzOF0gc3lzdGVtIDAwOjA5OiBb
aW8gIDB4MTE4MC0weDExOWZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjM5NzFdIHN5c3Rl
bSAwMDowOTogW2lvICAweDA1MDAtMHgwNTdmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDQuMjI0
MDA1XSBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXSBoYXMgYmVlbiBy
ZXNlcnZlZApbICAgIDQuMjI0MDM5XSBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZWMwMDAwMC0weGZl
Y2ZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA0LjIyNDA3NF0gc3lzdGVtIDAwOjA5
OiBbbWVtIDB4ZmVkMDgwMDAtMHhmZWQwOGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICA0LjIy
NDEwOF0gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmYwMDAwMDAtMHhmZmZmZmZmZl0gaGFzIGJlZW4g
cmVzZXJ2ZWQKWyAgICA0LjIyNDE0Ml0gc3lzdGVtIDAwOjA5OiBQbHVnIGFuZCBQbGF5IEFDUEkg
ZGV2aWNlLCBJRHMgUE5QMGMwMSAoYWN0aXZlKQpbICAgIDQuMjI0MjAyXSBwbnAgMDA6MGE6IFtp
byAgMHgwNDU0LTB4MDQ1N10KWyAgICA0LjIyNDI0M10gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDQ1
NC0weDA0NTddIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjQyNzddIHN5c3RlbSAwMDowYTog
UGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIElOVDNmMGQgUE5QMGMwMiAoYWN0aXZlKQpb
ICAgIDQuMjI0NDM4XSBwbnAgMDA6MGI6IFttZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmXQpbICAg
IDQuMjI0NDc0XSBwbnAgMDA6MGI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAw
MTAzIChhY3RpdmUpClsgICAgNC4yMjQ2ODVdIHBucDogUG5QIEFDUEk6IGZvdW5kIDEyIGRldmlj
ZXMKWyAgICA0LjIyNDcxNV0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkClsg
ICAgNC4yMzAyNjhdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAgKDB4MHhmZmZm
ZmYpIC0gYWJvcnRpbmcuClsgICAgNC4yMzAzMThdIFBDSTogbWF4IGJ1cyBkZXB0aDogNCBwY2lf
dHJ5X251bTogNQpbICAgIDQuMjMwNTU5XSBwY2kgMDAwMDowMDowMS4wOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDEtMDFdClsgICAgNC4yMzA1OTJdIHBjaSAwMDAwOjAwOjAxLjA6ICAgYnJpZGdlIHdp
bmRvdyBbaW8gIDB4ZTAwMC0weGVmZmZdClsgICAgNC4yMzA2MjhdIHBjaSAwMDAwOjAwOjAxLjA6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmJlMDAwMDAtMHhmYmVmZmZmZl0KWyAgICA0LjIzMDY2
NF0gcGNpIDAwMDA6MDA6MDEuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhjMDAwMDAwMC0weGNm
ZmZmZmZmIDY0Yml0IHByZWZdClsgICAgNC4yMzA3MTVdIHBjaSAwMDAwOjAyOjAwLjA6IFBDSSBi
cmlkZ2UgdG8gW2J1cyAwMy0wM10KWyAgICA0LjIzMDc1MF0gcGNpIDAwMDA6MDI6MDAuMDogICBi
cmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0KWyAgICA0LjIzMDgxNV0gcGNpIDAwMDA6
MDA6MWMuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAzXQpbICAgIDQuMjMwODQ5XSBwY2kgMDAw
MDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDQuMjMw
OTAyXSBwY2kgMDAwMDowMDoxYy40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdClsgICAgNC4y
MzA5MzVdIHBjaSAwMDAwOjAwOjFjLjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNm
ZmZdClsgICAgNC4yMzA5NzVdIHBjaSAwMDAwOjAwOjFjLjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4ZmJkMDAwMDAtMHhmYmRmZmZmZl0KWyAgICA0LjIzMTAyMV0gcGNpIDAwMDA6MDA6MWMuNTog
UENJIGJyaWRnZSB0byBbYnVzIDA1LTA1XQpbICAgIDQuMjMxMDYwXSBwY2kgMDAwMDowMDoxYy41
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZiYzAwMDAwLTB4ZmJjZmZmZmZdClsgICAgNC4yMzEx
MDddIHBjaSAwMDAwOjAwOjFjLjY6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0wNl0KWyAgICA0LjIz
MTE0NF0gcGNpIDAwMDA6MDA6MWMuNjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYmIwMDAwMC0w
eGZiYmZmZmZmXQpbICAgIDQuMjMxMTkyXSBwY2kgMDAwMDowODowMS4wOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDktMDldClsgICAgNC4yMzEyNDhdIHBjaSAwMDAwOjBhOjAwLjA6IFBDSSBicmlkZ2Ug
dG8gW2J1cyAwYi0wYl0KWyAgICA0LjIzMTMxMl0gcGNpIDAwMDA6MDg6MDQuMDogUENJIGJyaWRn
ZSB0byBbYnVzIDBhLTBiXQpbICAgIDQuMjMxMzY4XSBwY2kgMDAwMDowODowNS4wOiBQQ0kgYnJp
ZGdlIHRvIFtidXMgMGMtMGNdClsgICAgNC4yMzE0MDJdIHBjaSAwMDAwOjA4OjA1LjA6ICAgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZdClsgICAgNC4yMzE0NDRdIHBjaSAwMDAwOjA4
OjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmI5MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0
LjIzMTQ5NF0gcGNpIDAwMDA6MDg6MDYuMDogUENJIGJyaWRnZSB0byBbYnVzIDBkLTBkXQpbICAg
IDQuMjMxNTM0XSBwY2kgMDAwMDowODowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZiODAw
MDAwLTB4ZmI4ZmZmZmZdClsgICAgNC4yMzE1NzNdIHBjaSAwMDAwOjA4OjA2LjA6ICAgYnJpZGdl
IHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMjMx
NjMwXSBwY2kgMDAwMDowODowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGUtMGVdClsgICAgNC4y
MzE2ODddIHBjaSAwMDAwOjA4OjA4LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwZi0wZl0KWyAgICA0
LjIzMTc0NF0gcGNpIDAwMDA6MDg6MDkuMDogUENJIGJyaWRnZSB0byBbYnVzIDEwLTEwXQpbICAg
IDQuMjMxODAwXSBwY2kgMDAwMDowNzowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDgtMTBdClsg
ICAgNC4yMzE4MzRdIHBjaSAwMDAwOjA3OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YjAw
MC0weGJmZmZdClsgICAgNC4yMzE4NzZdIHBjaSAwMDAwOjA3OjAwLjA6ICAgYnJpZGdlIHdpbmRv
dyBbbWVtIDB4ZmI4MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0LjIzMTkxNV0gcGNpIDAwMDA6MDc6
MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0weGQwMGZmZmZmIDY0Yml0IHBy
ZWZdClsgICAgNC4yMzE5NzJdIHBjaSAwMDAwOjAwOjFjLjc6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
Ny0xMF0KWyAgICA0LjIzMjAwNV0gcGNpIDAwMDA6MDA6MWMuNzogICBicmlkZ2Ugd2luZG93IFtp
byAgMHhiMDAwLTB4YmZmZl0KWyAgICA0LjIzMjA0NF0gcGNpIDAwMDA6MDA6MWMuNzogICBicmlk
Z2Ugd2luZG93IFttZW0gMHhmYjgwMDAwMC0weGZiYWZmZmZmXQpbICAgIDQuMjMyMDgzXSBwY2kg
MDAwMDowMDoxYy43OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZDAwZmZmZmYg
NjRiaXQgcHJlZl0KWyAgICA0LjIzMjE0Ml0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjIzMjE1Ml0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9
MTYgKGdzaT0xNikKWyAgICA0LjIzMjE2N10gcGNpIDAwMDA6MDA6MDEuMDogUENJIElOVCBBIC0+
IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgNC4yMzIyMDRdIHBjaSAwMDAwOjAw
OjAxLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjMyMjEyXSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjMyMjE2XSB4
ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQpbICAgIDQuMjMyMjMxXSBwY2kgMDAw
MDowMDoxYy4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKWyAg
ICA0LjIzMjI2OV0gcGNpIDAwMDA6MDA6MWMuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0
ClsgICAgNC4yMzIyNzddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxClsgICAgNC4yMzIyNzhdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTYg
Zm9yIGdzaSAxNgpbICAgIDQuMjMyMzEwXSB4ZW46IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3Np
PTE2KQpbICAgIDQuMjMyMzExXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgNC4yMzIz
NDBdIHBjaSAwMDAwOjAyOjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+
IElSUSAxNgpbICAgIDQuMjMyMzgyXSBwY2kgMDAwMDowMjowMC4wOiBzZXR0aW5nIGxhdGVuY3kg
dGltZXIgdG8gNjQKWyAgICA0LjIzMjM5Ml0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjIzMjM5NF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJu
aW5nIGlycSAxNyBmb3IgZ3NpIDE3ClsgICAgNC4yMzI0MjVdIHhlbjogLS0+IHBpcnE9MTcgLT4g
aXJxPTE3IChnc2k9MTcpClsgICAgNC4yMzI0MjZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcK
WyAgICA0LjIzMjQ1NV0gcGNpIDAwMDA6MDA6MWMuNDogUENJIElOVCBBIC0+IEdTSSAxNyAobGV2
ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgNC4yMzI0OTNdIHBjaSAwMDAwOjAwOjFjLjQ6IHNldHRp
bmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjMyNTAyXSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjMyNTAzXSB4ZW5fbWFwX3BpcnFf
Z3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgICA0LjIzMjUzNV0geGVuOiAtLT4g
cGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgICA0LjIzMjUzNl0gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDoxNgpbICAgIDQuMjMyNTY1XSBwY2kgMDAwMDowMDoxYy41OiBQQ0kgSU5UIEIgLT4g
R1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKWyAgICA0LjIzMjYwM10gcGNpIDAwMDA6MDA6
MWMuNTogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4yMzI2MTJdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4yMzI2MTZdIHhl
bjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpClsgICAgNC4yMzI2MzFdIHBjaSAwMDAw
OjAwOjFjLjY6IFBDSSBJTlQgQyAtPiBHU0kgMTggKGxldmVsLCBsb3cpIC0+IElSUSAxOApbICAg
IDQuMjMyNjY5XSBwY2kgMDAwMDowMDoxYy42OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQK
WyAgICA0LjIzMjY3OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDEKWyAgICA0LjIzMjY4MV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkK
WyAgICA0LjIzMjY5Nl0gcGNpIDAwMDA6MDA6MWMuNzogUENJIElOVCBEIC0+IEdTSSAxOSAobGV2
ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAgNC4yMzI3MzNdIHBjaSAwMDAwOjAwOjFjLjc6IHNldHRp
bmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjMyNzQzXSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjMyNzQ1XSB4ZW5fbWFwX3BpcnFf
Z3NpOiByZXR1cm5pbmcgaXJxIDE5IGZvciBnc2kgMTkKWyAgICA0LjIzMjc3N10geGVuOiAtLT4g
cGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkKWyAgICA0LjIzMjc3OF0gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDoxOQpbICAgIDQuMjMyODA3XSBwY2kgMDAwMDowNzowMC4wOiBQQ0kgSU5UIEEgLT4g
R1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICA0LjIzMjg0N10gcGNpIDAwMDA6MDc6
MDAuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4yMzI4NTddIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4yMzI4NTldIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuMjMyODkw
XSB4ZW46IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDQuMjMyODkxXSBBbHJl
YWR5IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgNC4yMzI5MjFdIHBjaSAwMDAwOjA4OjAxLjA6IFBD
SSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAxNgpbICAgIDQuMjMyOTYwXSBw
Y2kgMDAwMDowODowMS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjIzMjk3
MV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0
LjIzMjk3Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOSBmb3IgZ3NpIDE5Clsg
ICAgNC4yMzMwMDRdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTE5IChnc2k9MTkpClsgICAgNC4y
MzMwMDVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTkKWyAgICA0LjIzMzAzNF0gcGNpIDAwMDA6
MDg6MDQuMDogUENJIElOVCBBIC0+IEdTSSAxOSAobGV2ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAg
NC4yMzMwNzRdIHBjaSAwMDAwOjA4OjA0LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApb
ICAgIDQuMjMzMDg2XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQpbICAgIDQuMjMzMDg3XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE5IGZv
ciBnc2kgMTkKWyAgICA0LjIzMzExOV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0x
OSkKWyAgICA0LjIzMzEyMF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAgIDQuMjMzMTUw
XSBwY2kgMDAwMDowYTowMC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJ
UlEgMTkKWyAgICA0LjIzMzE5MF0gcGNpIDAwMDA6MGE6MDAuMDogc2V0dGluZyBsYXRlbmN5IHRp
bWVyIHRvIDY0ClsgICAgNC4yMzMyMDJdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAgNC4yMzMyMDNdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmlu
ZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuMjMzMjM1XSB4ZW46IC0tPiBwaXJxPTE2IC0+IGly
cT0xNiAoZ3NpPTE2KQpbICAgIDQuMjMzMjM2XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2Clsg
ICAgNC4yMzQ1NjBdIHBjaSAwMDAwOjA4OjA1LjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVs
LCBsb3cpIC0+IElSUSAxNgpbICAgIDQuMjM0NTk5XSBwY2kgMDAwMDowODowNS4wOiBzZXR0aW5n
IGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjIzNDYxMF0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjIzNDYxMV0geGVuX21hcF9waXJxX2dz
aTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3ClsgICAgNC4yMzQ2NDNdIHhlbjogLS0+IHBp
cnE9MTcgLT4gaXJxPTE3IChnc2k9MTcpClsgICAgNC4yMzQ2NDRdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTcKWyAgICA0LjIzNDY3M10gcGNpIDAwMDA6MDg6MDYuMDogUENJIElOVCBBIC0+IEdT
SSAxNyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgNC4yMzQ3MTNdIHBjaSAwMDAwOjA4OjA2
LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjM0NzIzXSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjM0NzI1XSB4ZW5f
bWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKWyAgICA0LjIzNDc1Nl0g
eGVuOiAtLT4gcGlycT0xOCAtPiBpcnE9MTggKGdzaT0xOCkKWyAgICA0LjIzNDc1OF0gQWxyZWFk
eSBzZXR1cCB0aGUgR1NJIDoxOApbICAgIDQuMjM0Nzg3XSBwY2kgMDAwMDowODowNy4wOiBQQ0kg
SU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgICA0LjIzNDgyNl0gcGNp
IDAwMDA6MDg6MDcuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4yMzQ4Mzdd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4y
MzQ4MzhdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTkgZm9yIGdzaSAxOQpbICAg
IDQuMjM0ODcwXSB4ZW46IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDQuMjM0
ODcxXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE5ClsgICAgNC4yMzQ5MDBdIHBjaSAwMDAwOjA4
OjA4LjA6IFBDSSBJTlQgQSAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAxOQpbICAgIDQu
MjM0OTM5XSBwY2kgMDAwMDowODowOC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAg
ICA0LjIzNDk1MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5
IDEKWyAgICA0LjIzNDk1Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3Ig
Z3NpIDE2ClsgICAgNC4yMzQ5ODNdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYp
ClsgICAgNC4yMzQ5ODVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICA0LjIzNTAxM10g
cGNpIDAwMDA6MDg6MDkuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJR
IDE2ClsgICAgNC4yMzUwNTNdIHBjaSAwMDAwOjA4OjA5LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1l
ciB0byA2NApbICAgIDQuMjM1MDU3XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAw
eDAwMDAtMHgwM2FmXQpbICAgIDQuMjM1MDU5XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUg
W2lvICAweDAzZTAtMHgwY2Y3XQpbICAgIDQuMjM1MDYwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291
cmNlIDYgW2lvICAweDAzYjAtMHgwM2RmXQpbICAgIDQuMjM1MDYyXSBwY2lfYnVzIDAwMDA6MDA6
IHJlc291cmNlIDcgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDQuMjM1MDYzXSBwY2lfYnVzIDAw
MDA6MDA6IHJlc291cmNlIDggW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgNC4yMzUw
NjVdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgOSBbbWVtIDB4MDAwYzAwMDAtMHgwMDBkZmZm
Zl0KWyAgICA0LjIzNTA2N10gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxMCBbbWVtIDB4N2Zh
MDAwMDAtMHhmZmZmZmZmZl0KWyAgICA0LjIzNTA2OF0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJj
ZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0KWyAgICA0LjIzNTA3MF0gcGNpX2J1cyAwMDAwOjAxOiBy
ZXNvdXJjZSAxIFttZW0gMHhmYmUwMDAwMC0weGZiZWZmZmZmXQpbICAgIDQuMjM1MDcxXSBwY2lf
YnVzIDAwMDA6MDE6IHJlc291cmNlIDIgW21lbSAweGMwMDAwMDAwLTB4Y2ZmZmZmZmYgNjRiaXQg
cHJlZl0KWyAgICA0LjIzNTA3M10gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSAwIFtpbyAgMHhk
MDAwLTB4ZGZmZl0KWyAgICA0LjIzNTA3NV0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSAwIFtp
byAgMHhkMDAwLTB4ZGZmZl0KWyAgICA0LjIzNTA3Nl0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJj
ZSAwIFtpbyAgMHhjMDAwLTB4Y2ZmZl0KWyAgICA0LjIzNTA3OF0gcGNpX2J1cyAwMDAwOjA0OiBy
ZXNvdXJjZSAxIFttZW0gMHhmYmQwMDAwMC0weGZiZGZmZmZmXQpbICAgIDQuMjM1MDc5XSBwY2lf
YnVzIDAwMDA6MDU6IHJlc291cmNlIDEgW21lbSAweGZiYzAwMDAwLTB4ZmJjZmZmZmZdClsgICAg
NC4yMzUwODFdIHBjaV9idXMgMDAwMDowNjogcmVzb3VyY2UgMSBbbWVtIDB4ZmJiMDAwMDAtMHhm
YmJmZmZmZl0KWyAgICA0LjIzNTA4Ml0gcGNpX2J1cyAwMDAwOjA3OiByZXNvdXJjZSAwIFtpbyAg
MHhiMDAwLTB4YmZmZl0KWyAgICA0LjIzNTA4NF0gcGNpX2J1cyAwMDAwOjA3OiByZXNvdXJjZSAx
IFttZW0gMHhmYjgwMDAwMC0weGZiYWZmZmZmXQpbICAgIDQuMjM1MDg1XSBwY2lfYnVzIDAwMDA6
MDc6IHJlc291cmNlIDIgW21lbSAweGQwMDAwMDAwLTB4ZDAwZmZmZmYgNjRiaXQgcHJlZl0KWyAg
ICA0LjIzNTA4N10gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAwIFtpbyAgMHhiMDAwLTB4YmZm
Zl0KWyAgICA0LjIzNTA4OF0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAxIFttZW0gMHhmYjgw
MDAwMC0weGZiOWZmZmZmXQpbICAgIDQuMjM1MDkwXSBwY2lfYnVzIDAwMDA6MDg6IHJlc291cmNl
IDIgW21lbSAweGQwMDAwMDAwLTB4ZDAwZmZmZmYgNjRiaXQgcHJlZl0KWyAgICA0LjIzNTA5Ml0g
cGNpX2J1cyAwMDAwOjBjOiByZXNvdXJjZSAwIFtpbyAgMHhiMDAwLTB4YmZmZl0KWyAgICA0LjIz
NTA5M10gcGNpX2J1cyAwMDAwOjBjOiByZXNvdXJjZSAxIFttZW0gMHhmYjkwMDAwMC0weGZiOWZm
ZmZmXQpbICAgIDQuMjM1MDk1XSBwY2lfYnVzIDAwMDA6MGQ6IHJlc291cmNlIDEgW21lbSAweGZi
ODAwMDAwLTB4ZmI4ZmZmZmZdClsgICAgNC4yMzUwOTddIHBjaV9idXMgMDAwMDowZDogcmVzb3Vy
Y2UgMiBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMjM1MTQ5
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIKWyAgICA0LjIzNTYyNl0gSVAgcm91
dGUgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5
dGVzKQpbICAgIDQuMjM3NTIzXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiA1
MjQyODggKG9yZGVyOiAxMSwgODM4ODYwOCBieXRlcykKWyAgICA0LjIzODgzM10gVENQIGJpbmQg
aGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpClsgICAg
NC4yMzkwMDhdIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgNTI0Mjg4
IGJpbmQgNjU1MzYpClsgICAgNC4yMzkwNDJdIFRDUCByZW5vIHJlZ2lzdGVyZWQKWyAgICA0LjIz
OTA5OF0gVURQIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDUsIDEzMTA3MiBieXRl
cykKWyAgICA0LjIzOTE3NF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRl
cjogNSwgMTMxMDcyIGJ5dGVzKQpbICAgIDQuMjM5MzE4XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9j
b2wgZmFtaWx5IDEKWyAgICA0LjIzOTM2OF0gcGNpIDAwMDA6MDA6MDIuMDogQm9vdCB2aWRlbyBk
ZXZpY2UKWyAgICA0LjQ2Mzk5NV0gUENJOiBDTFMgNjQgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICA0
LjQ2NDAzNF0gVW5wYWNraW5nIGluaXRyYW1mcy4uLgpbICAgIDQuNDg5OTQyXSBGcmVlaW5nIGlu
aXRyZCBtZW1vcnk6IDMzNzM2ayBmcmVlZApbICAgIDQuNDk1NDI4XSBhdWRpdDogaW5pdGlhbGl6
aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkKWyAgICA0LjQ5NTQ3M10gdHlwZT0yMDAwIGF1
ZGl0KDEzMjk5NDg0NDEuNDc1OjEpOiBpbml0aWFsaXplZApbICAgIDQuNTExMjE1XSBIdWdlVExC
IHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDQu
NTExNDgxXSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgNC41MTE1NDRdIERxdW90
LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQpbICAg
IDQuNTExNjU5XSBtc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDExMzY5ClsgICAgNC41MTE4NTldIGFs
ZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5nKQpbICAgIDQuNTExOTE5XSBCbG9jayBsYXllciBT
Q1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUzKQpb
ICAgIDQuNTExOTY4XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgNC41MTE5OThd
IGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgNC41MTIwNDJdIGlvIHNjaGVk
dWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKWyAgICA0LjUxMjE3OF0gcGNpZXBvcnQgMDAw
MDowMDowMS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMjMzNV0gcGNp
ZXBvcnQgMDAwMDowMDoxYy4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUx
MjU1Ml0gcGNpZXBvcnQgMDAwMDowMDoxYy40OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQK
WyAgICA0LjUxMjc2OV0gcGNpZXBvcnQgMDAwMDowMDoxYy41OiBzZXR0aW5nIGxhdGVuY3kgdGlt
ZXIgdG8gNjQKWyAgICA0LjUxMjk4Nl0gcGNpZXBvcnQgMDAwMDowMDoxYy42OiBzZXR0aW5nIGxh
dGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMzIwMl0gcGNpZXBvcnQgMDAwMDowMDoxYy43OiBz
ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMzQzN10gcGNpZXBvcnQgMDAwMDow
NzowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMzc0N10gcGNpZXBv
cnQgMDAwMDowODowMS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNDA1
OF0gcGNpZXBvcnQgMDAwMDowODowNC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAg
ICA0LjUxNDM3MV0gcGNpZXBvcnQgMDAwMDowODowNS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg
dG8gNjQKWyAgICA0LjUxNDY4MV0gcGNpZXBvcnQgMDAwMDowODowNi4wOiBzZXR0aW5nIGxhdGVu
Y3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNDk5Ml0gcGNpZXBvcnQgMDAwMDowODowNy4wOiBzZXR0
aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNTMwM10gcGNpZXBvcnQgMDAwMDowODow
OC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNTYxNF0gcGNpZXBvcnQg
MDAwMDowODowOS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNTk1OF0g
cGNpZXBvcnQgMDAwMDowMDowMS4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50
ZXJydXB0ClsgICAgNC41MTU5OTRdIHBjaSAwMDAwOjAxOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhy
b3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjAyOF0gcGNpIDAwMDA6MDE6MDAuMTog
U2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuNTE2MDYzXSBw
Y2llX3BtZSAwMDAwOjAwOjAxLjA6cGNpZTAxOiBzZXJ2aWNlIGRyaXZlciBwY2llX3BtZSBsb2Fk
ZWQKWyAgICA0LjUxNjA5OF0gcGNpZXBvcnQgMDAwMDowMDoxYy4wOiBTaWduYWxpbmcgUE1FIHRo
cm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTYxMzJdIHBjaSAwMDAwOjAyOjAwLjA6
IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjE2Nl0g
cGNpIDAwMDA6MDM6MDQuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVw
dApbICAgIDQuNTE2MjA0XSBwY2llX3BtZSAwMDAwOjAwOjFjLjA6cGNpZTAxOiBzZXJ2aWNlIGRy
aXZlciBwY2llX3BtZSBsb2FkZWQKWyAgICA0LjUxNjIzOV0gcGNpZXBvcnQgMDAwMDowMDoxYy40
OiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTYyNzRd
IHBjaSAwMDAwOjA0OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1
cHQKWyAgICA0LjUxNjMxMl0gcGNpZV9wbWUgMDAwMDowMDoxYy40OnBjaWUwMTogc2VydmljZSBk
cml2ZXIgcGNpZV9wbWUgbG9hZGVkClsgICAgNC41MTYzNDddIHBjaWVwb3J0IDAwMDA6MDA6MWMu
NTogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuNTE2Mzgx
XSBwY2kgMDAwMDowNTowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJy
dXB0ClsgICAgNC41MTY0MTldIHBjaWVfcG1lIDAwMDA6MDA6MWMuNTpwY2llMDE6IHNlcnZpY2Ug
ZHJpdmVyIHBjaWVfcG1lIGxvYWRlZApbICAgIDQuNTE2NDUzXSBwY2llcG9ydCAwMDAwOjAwOjFj
LjY6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjQ4
OF0gcGNpIDAwMDA6MDY6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVy
cnVwdApbICAgIDQuNTE2NTI2XSBwY2llX3BtZSAwMDAwOjAwOjFjLjY6cGNpZTAxOiBzZXJ2aWNl
IGRyaXZlciBwY2llX3BtZSBsb2FkZWQKWyAgICA0LjUxNjU2MV0gcGNpZXBvcnQgMDAwMDowMDox
Yy43OiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTY1
OTVdIHBjaWVwb3J0IDAwMDA6MDc6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1F
IGludGVycnVwdApbICAgIDQuNTE2NjI5XSBwY2llcG9ydCAwMDAwOjA4OjAxLjA6IFNpZ25hbGlu
ZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjY2M10gcGNpZXBvcnQg
MDAwMDowODowNC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Clsg
ICAgNC41MTY2OTddIHBjaSAwMDAwOjBhOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll
IFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjczMV0gcGNpZXBvcnQgMDAwMDowODowNS4wOiBTaWdu
YWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTY3NjVdIHBjaSAw
MDAwOjBjOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAg
ICA0LjUxNjc5OF0gcGNpZXBvcnQgMDAwMDowODowNi4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2gg
UENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTY4MzJdIHBjaSAwMDAwOjBkOjAwLjA6IFNpZ25h
bGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjg2NV0gcGNpZXBv
cnQgMDAwMDowODowNy4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0
ClsgICAgNC41MTY4OTldIHBjaWVwb3J0IDAwMDA6MDg6MDguMDogU2lnbmFsaW5nIFBNRSB0aHJv
dWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuNTE2OTMzXSBwY2llcG9ydCAwMDAwOjA4OjA5
LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjk3
Ml0gcGNpZV9wbWUgMDAwMDowMDoxYy43OnBjaWUwMTogc2VydmljZSBkcml2ZXIgcGNpZV9wbWUg
bG9hZGVkClsgICAgNC41MTcwNjldIEVSU1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCEKWyAgICA0LjUx
NzA5OF0gR0hFUzogSEVTVCBpcyBub3QgZW5hYmxlZCEKWyAgICA0LjUxNzQ5N10gU2VyaWFsOiA4
MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDQuNTM4
MjUyXSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBB
ClsgICAgNC41ODg3NDRdIDAwOjA4OiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEg
MTY1NTBBClsgICAgNC42MDQxMDZdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBp
biBfQ1JTClsgICAgNC42MDQxNDZdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMwpbICAg
IDQuNjA0MjQ5XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAuMDogSW50ZWwgU2FuZHlicmlkZ2Ug
Q2hpcHNldApbICAgIDQuNjA0NDE4XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAuMDogZGV0ZWN0
ZWQgZ3R0IHNpemU6IDIwOTcxNTJLIHRvdGFsLCAyNjIxNDRLIG1hcHBhYmxlClsgICAgNC42MDU0
NjFdIGFncGdhcnQtaW50ZWwgMDAwMDowMDowMC4wOiBkZXRlY3RlZCAyNjIxNDRLIHN0b2xlbiBt
ZW1vcnkKWyAgICA0LjYwNTYzOF0gYWdwZ2FydC1pbnRlbCAwMDAwOjAwOjAwLjA6IEFHUCBhcGVy
dHVyZSBpcyAyNTZNIEAgMHhiMDAwMDAwMApbICAgIDQuNjA1NzcxXSBpODA0MjogUE5QOiBObyBQ
Uy8yIGNvbnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuClsgICAgNC42MDg2
OThdIHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKWyAgICA0LjYwODcz
NV0gc2VyaW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKWyAgICA0LjYwODkx
MF0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICA0
LjYwODk5MV0gcnRjX2Ntb3MgMDA6MDQ6IFJUQyBjYW4gd2FrZSBmcm9tIFM0ClsgICAgNC42MDkx
ODZdIHJ0Y19jbW9zIDAwOjA0OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMw
ClsgICAgNC42MDkyNzhdIHJ0YzA6IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5
dGVzIG52cmFtClsgICAgNC42MDk0MzFdIFRDUCBjdWJpYyByZWdpc3RlcmVkClsgICAgNC42MDk1
MDJdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAgICA0LjYwOTgwOV0gTW9i
aWxlIElQdjYKWyAgICA0LjYwOTgzN10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAx
NwpbICAgIDQuNjA5ODY5XSBSZWdpc3RlcmluZyB0aGUgZG5zX3Jlc29sdmVyIGtleSB0eXBlClsg
ICAgNC42MTAwMzddIFBNOiBIaWJlcm5hdGlvbiBpbWFnZSBub3QgcHJlc2VudCBvciBjb3VsZCBu
b3QgYmUgbG9hZGVkLgpbICAgIDQuNjEwMDQ4XSByZWdpc3RlcmVkIHRhc2tzdGF0cyB2ZXJzaW9u
IDEKWyAgICA0LjYxMTA0OF0gcnRjX2Ntb3MgMDA6MDQ6IHNldHRpbmcgc3lzdGVtIGNsb2NrIHRv
IDIwMTItMDItMjIgMjI6MDc6MjAgVVRDICgxMzI5OTQ4NDQwKQpbICAgIDQuNjExMTUyXSBJbml0
aWFsaXppbmcgbmV0d29yayBkcm9wIG1vbml0b3Igc2VydmljZQpbICAgIDQuNjExMzgzXSBGcmVl
aW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA1NjhrIGZyZWVkClsgICAgNC42MTE0NjldIFdyaXRl
IHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogNjE0NGsKWyAgICA0LjYxMzQy
OF0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogNzEyayBmcmVlZApbICAgIDQuNjEzNzEx
XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA2ODRrIGZyZWVkClsgICAgNC42MzM0NTVd
IHVkZXZkWzUwXTogc3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgICA0LjY2NzA2OV0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDQuNjY3MTM0XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1YgpbICAgIDQuNjc3MDQ0XSBT
Q1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZApbICAgIDQuNjc5NTQ5XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDQuNjgwMjg2XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuNjgwMjkyXSB4ZW5fbWFwX3Bp
cnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKWyAgICA0LjY4MDMzMV0geGVuOiAt
LT4gcGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykKWyAgICA0LjY4MDMzM10gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDoxNwpbICAgIDQuNjgwMzcwXSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IFBDSSBJ
TlQgQSAtPiBHU0kgMTcgKGxldmVsLCBsb3cpIC0+IElSUSAxNwpbICAgIDQuNjgwNDQxXSB4aGNp
X2hjZCAwMDAwOjA1OjAwLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNjgw
NDQ3XSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IHhIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgNC42
ODA1MDNdIHhoY2lfaGNkIDAwMDA6MDU6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciAxClsgICAgNC42ODA3NzBdIHhoY2lfaGNkIDAwMDA6MDU6MDAuMDog
aXJxIDE3LCBpbyBtZW0gMHhmYmMwMDAwMApbICAgIDQuNjgwODYwXSB4aGNpX2hjZCAwMDAwOjA1
OjAwLjA6IEZhaWxlZCB0byBlbmFibGUgTVNJLVgKWyAgICA0LjY4MTE0OV0gdXNiIHVzYjE6IE5l
dyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgpbICAgIDQu
NjgxMTg5XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9
MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0LjY4MTI0MV0gdXNiIHVzYjE6IFByb2R1Y3Q6IHhIQ0kg
SG9zdCBDb250cm9sbGVyClsgICAgNC42ODEyNzddIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExp
bnV4IDMuMi4wLTEtYW1kNjQgeGhjaV9oY2QKWyAgICA0LjY4MTMxNV0gdXNiIHVzYjE6IFNlcmlh
bE51bWJlcjogMDAwMDowNTowMC4wClsgICAgNC42ODU0NzNdIHhIQ0kgeGhjaV9hZGRfZW5kcG9p
bnQgY2FsbGVkIGZvciByb290IGh1YgpbICAgIDQuNjg1NDc2XSB4SENJIHhoY2lfY2hlY2tfYmFu
ZHdpZHRoIGNhbGxlZCBmb3Igcm9vdCBodWIKWyAgICA0LjY4NTUxMF0gaHViIDEtMDoxLjA6IFVT
QiBodWIgZm91bmQKWyAgICA0LjY4NTU1NV0gaHViIDEtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQK
WyAgICA0LjY4NTY4OF0geGhjaV9oY2QgMDAwMDowNTowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxl
cgpbICAgIDQuNjg1NzMzXSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IG5ldyBVU0IgYnVzIHJlZ2lz
dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMgpbICAgIDQuNjg1ODMxXSB1c2IgdXNiMjogTmV3
IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzClsgICAgNC42
ODU4NzRdIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0y
LCBTZXJpYWxOdW1iZXI9MQpbICAgIDQuNjg1OTI2XSB1c2IgdXNiMjogUHJvZHVjdDogeEhDSSBI
b3N0IENvbnRyb2xsZXIKWyAgICA0LjY4NTk2M10gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGlu
dXggMy4yLjAtMS1hbWQ2NCB4aGNpX2hjZApbICAgIDQuNjg2MDAxXSB1c2IgdXNiMjogU2VyaWFs
TnVtYmVyOiAwMDAwOjA1OjAwLjAKWyAgICA0LjY4ODMxOV0geEhDSSB4aGNpX2FkZF9lbmRwb2lu
dCBjYWxsZWQgZm9yIHJvb3QgaHViClsgICAgNC42ODgzMjJdIHhIQ0kgeGhjaV9jaGVja19iYW5k
d2lkdGggY2FsbGVkIGZvciByb290IGh1YgpbICAgIDQuNjg4MzU2XSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZApbICAgIDQuNjg4Mzk5XSBodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApb
ICAgIDQuNzAwNTE2XSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxl
ciAoRUhDSSkgRHJpdmVyClsgICAgNC43MDA1ODNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRy
aWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC43MDA1ODldIHhlbl9tYXBfcGlycV9nc2k6IHJl
dHVybmluZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuNzAwNjI4XSB4ZW46IC0tPiBwaXJxPTE2
IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDQuNzAwNjMxXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kg
OjE2ClsgICAgNC43MDA2NjddIGVoY2lfaGNkIDAwMDA6MDA6MWEuMDogUENJIElOVCBBIC0+IEdT
SSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgNC43MDA3MjhdIGVoY2lfaGNkIDAwMDA6
MDA6MWEuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC43MDA3MzRdIGVoY2lf
aGNkIDAwMDA6MDA6MWEuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA0LjcwMDc4MF0gZWhj
aV9oY2QgMDAwMDowMDoxYS4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMg
bnVtYmVyIDMKWyAgICA0LjcwMDg4Ml0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBkZWJ1ZyBwb3J0
IDIKWyAgICA0LjcwNDgyM10gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBjYWNoZSBsaW5lIHNpemUg
b2YgNjQgaXMgbm90IHN1cHBvcnRlZApbICAgIDQuNzA1MjU1XSBlaGNpX2hjZCAwMDAwOjAwOjFh
LjA6IGlycSAxNiwgaW8gbWVtIDB4ZmJmMDMwMDAKWyAgICA0LjcwNzk1M10geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjcwNzk1N10geGVuX21h
cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4ClsgICAgNC43MDgwMjZdIHhl
bjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpClsgICAgNC43MDgwMjhdIEFscmVhZHkg
c2V0dXAgdGhlIEdTSSA6MTgKWyAgICA0LjcwODA5N10geGhjaV9oY2QgMDAwMDowNjowMC4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgICA0LjcwODIwM10g
eGhjaV9oY2QgMDAwMDowNjowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0
LjcwODIwOV0geGhjaV9oY2QgMDAwMDowNjowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgpbICAg
IDQuNzA4MjgxXSB4aGNpX2hjZCAwMDAwOjA2OjAwLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgNApbICAgIDQuNzA4NjA5XSB4aGNpX2hjZCAwMDAwOjA2OjAw
LjA6IGlycSAxOCwgaW8gbWVtIDB4ZmJiMDAwMDAKWyAgICA0LjcwODc0MF0geGhjaV9oY2QgMDAw
MDowNjowMC4wOiBGYWlsZWQgdG8gZW5hYmxlIE1TSS1YClsgICAgNC43MDkwODhdIHVzYiB1c2I0
OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIKWyAg
ICA0LjcwOTE2Ml0gdXNiIHVzYjQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9k
dWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAgNC43MDkyMjFdIHVzYiB1c2I0OiBQcm9kdWN0OiB4
SENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQuNzA5MjU4XSB1c2IgdXNiNDogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjIuMC0xLWFtZDY0IHhoY2lfaGNkClsgICAgNC43MDkyOTVdIHVzYiB1c2I0OiBT
ZXJpYWxOdW1iZXI6IDAwMDA6MDY6MDAuMApbICAgIDQuNzA5NDE2XSB4SENJIHhoY2lfYWRkX2Vu
ZHBvaW50IGNhbGxlZCBmb3Igcm9vdCBodWIKWyAgICA0LjcwOTQxOV0geEhDSSB4aGNpX2NoZWNr
X2JhbmR3aWR0aCBjYWxsZWQgZm9yIHJvb3QgaHViClsgICAgNC43MDk0NTNdIGh1YiA0LTA6MS4w
OiBVU0IgaHViIGZvdW5kClsgICAgNC43MDk0OTZdIGh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVj
dGVkClsgICAgNC43MDk2MDhdIHhoY2lfaGNkIDAwMDA6MDY6MDAuMDogeEhDSSBIb3N0IENvbnRy
b2xsZXIKWyAgICA0LjcwOTY1MV0geGhjaV9oY2QgMDAwMDowNjowMC4wOiBuZXcgVVNCIGJ1cyBy
ZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUKWyAgICA0LjcwOTcyOF0gdXNiIHVzYjU6
IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMwpbICAg
IDQuNzA5NzY4XSB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0LjcwOTgxOV0gdXNiIHVzYjU6IFByb2R1Y3Q6IHhI
Q0kgSG9zdCBDb250cm9sbGVyClsgICAgNC43MDk4NTVdIHVzYiB1c2I1OiBNYW51ZmFjdHVyZXI6
IExpbnV4IDMuMi4wLTEtYW1kNjQgeGhjaV9oY2QKWyAgICA0LjcwOTg5M10gdXNiIHVzYjU6IFNl
cmlhbE51bWJlcjogMDAwMDowNjowMC4wClsgICAgNC43MTAwMzJdIGxpYmF0YSB2ZXJzaW9uIDMu
MDAgbG9hZGVkLgpbICAgIDQuNzEwMTM3XSB4SENJIHhoY2lfYWRkX2VuZHBvaW50IGNhbGxlZCBm
b3Igcm9vdCBodWIKWyAgICA0LjcxMDE0MF0geEhDSSB4aGNpX2NoZWNrX2JhbmR3aWR0aCBjYWxs
ZWQgZm9yIHJvb3QgaHViClsgICAgNC43MTAxNzFdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5k
ClsgICAgNC43MTAyMTRdIGh1YiA1LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAgNC43Mjc5
MDZdIGVoY2lfaGNkIDAwMDA6MDA6MWEuMDogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKWyAg
ICA0LjcyNzk3N10gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi
LCBpZFByb2R1Y3Q9MDAwMgpbICAgIDQuNzI4MDIyXSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2Ug
c3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0LjcyODA3N10g
dXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgNC43MjgxMTVdIHVz
YiB1c2IzOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMi4wLTEtYW1kNjQgZWhjaV9oY2QKWyAgICA0
LjcyODE1NF0gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxYS4wClsgICAgNC43Mjgz
MzVdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgNC43MjgzNzRdIGh1YiAzLTA6MS4w
OiAyIHBvcnRzIGRldGVjdGVkClsgICAgNC43Mjg1MDRdIGFoY2kgMDAwMDowMDoxZi4yOiB2ZXJz
aW9uIDMuMApbICAgIDQuNzI4NTE5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5n
IDAgcG9sYXJpdHkgMQpbICAgIDQuNzI4NTI3XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg
aXJxIDE5IGZvciBnc2kgMTkKWyAgICA0LjcyODU3M10geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9
MTkgKGdzaT0xOSkKWyAgICA0LjcyODU3Nl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAg
IDQuNzI4NjEzXSBhaGNpIDAwMDA6MDA6MWYuMjogUENJIElOVCBCIC0+IEdTSSAxOSAobGV2ZWws
IGxvdykgLT4gSVJRIDE5ClsgICAgNC43NDE1ODFdIHRnMy5jOnYzLjEyMSAoTm92ZW1iZXIgMiwg
MjAxMSkKWyAgICA0Ljc0MTYzMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICA0Ljc0MTYzNl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSAxNyBmb3IgZ3NpIDE3ClsgICAgNC43NDE2NzRdIHhlbjogLS0+IHBpcnE9MTcgLT4gaXJxPTE3
IChnc2k9MTcpClsgICAgNC43NDE2NzZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcKWyAgICA0
Ljc0MTcxMV0gdGczIDAwMDA6MGQ6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNyAobGV2ZWwsIGxv
dykgLT4gSVJRIDE3ClsgICAgNC43NDE3NjJdIHRnMyAwMDAwOjBkOjAwLjA6IHNldHRpbmcgbGF0
ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzQzOTIwXSBhaGNpIDAwMDA6MDA6MWYuMjogQUhDSSAw
MDAxLjAzMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFNBVEEgbW9kZQpbICAg
IDQuNzQ1Mjc4XSBhaGNpIDAwMDA6MDA6MWYuMjogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIHBtIGxl
ZCBjbG8gcGlvIHNsdW0gcGFydCBlbXMgYXBzdCAKWyAgICA0Ljc0NTMzOF0gYWhjaSAwMDAwOjAw
OjFmLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzQ5OTYwXSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuNzQ5OTY1XSB4
ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgICA0Ljc1MDAw
M10geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgICA0Ljc1MDAwNV0gQWxy
ZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgIDQuNzUwMDQxXSBmaXJld2lyZV9vaGNpIDAwMDA6
MGM6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAg
NC43NTAxMDJdIGZpcmV3aXJlX29oY2kgMDAwMDowYzowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGlt
ZXIgdG8gNjQKWyAgICA0Ljc2OTI5Ml0gdGczIDAwMDA6MGQ6MDAuMDogZXRoMDogVGlnb24zIFtw
YXJ0bm8oQkNNNTc3ODEpIHJldiA1Nzc4NTEwMF0gKFBDSSBFeHByZXNzKSBNQUMgYWRkcmVzcyAw
MDoyNToyMjpmNjpiOToyZQpbICAgIDQuNzY5MzY0XSB0ZzMgMDAwMDowZDowMC4wOiBldGgwOiBh
dHRhY2hlZCBQSFkgaXMgNTc3NjUgKDEwLzEwMC8xMDAwQmFzZS1UIEV0aGVybmV0KSAoV2lyZVNw
ZWVkWzFdLCBFRUVbMV0pClsgICAgNC43Njk0MjFdIHRnMyAwMDAwOjBkOjAwLjA6IGV0aDA6IFJY
Y3N1bXNbMV0gTGlua0NoZ1JFR1swXSBNSWlycVswXSBBU0ZbMF0gVFNPY2FwWzFdClsgICAgNC43
Njk0NzldIHRnMyAwMDAwOjBkOjAwLjA6IGV0aDA6IGRtYV9yd2N0cmxbMDAwMDAwMDFdIGRtYV9t
YXNrWzY0LWJpdF0KWyAgICA0Ljc4NDU1NF0gc2NzaTAgOiBhaGNpClsgICAgNC43ODQ2ODRdIHNj
c2kxIDogYWhjaQpbICAgIDQuNzg0Nzg4XSBzY3NpMiA6IGFoY2kKWyAgICA0Ljc4NDg5Ml0gc2Nz
aTMgOiBhaGNpClsgICAgNC43ODUwMTFdIHNjc2k0IDogYWhjaQpbICAgIDQuNzg1MTE3XSBzY3Np
NSA6IGFoY2kKWyAgICA0Ljc4NTM0MV0gYXRhMTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0
OEAweGZiZjAxMDAwIHBvcnQgMHhmYmYwMTEwMCBpcnEgMzAwClsgICAgNC43ODUzOTBdIGF0YTI6
IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmYmYwMTAwMCBwb3J0IDB4ZmJmMDExODAg
aXJxIDMwMApbICAgIDQuNzg1NDM3XSBhdGEzOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4
QDB4ZmJmMDEwMDAgcG9ydCAweGZiZjAxMjAwIGlycSAzMDAKWyAgICA0Ljc4NTQ4NV0gYXRhNDog
U0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0OEAweGZiZjAxMDAwIHBvcnQgMHhmYmYwMTI4MCBp
cnEgMzAwClsgICAgNC43ODU1MzNdIGF0YTU6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhA
MHhmYmYwMTAwMCBwb3J0IDB4ZmJmMDEzMDAgaXJxIDMwMApbICAgIDQuNzg1NTgwXSBhdGE2OiBT
QVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4QDB4ZmJmMDEwMDAgcG9ydCAweGZiZjAxMzgwIGly
cSAzMDAKWyAgICA0Ljc4NTY1NV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICA0Ljc4NTY1OV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSAxNiBmb3IgZ3NpIDE2ClsgICAgNC43ODU3MDBdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2
IChnc2k9MTYpClsgICAgNC43ODU3MDJdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICA0
Ljc4NTc0MF0gYWhjaSAwMDAwOjA0OjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBs
b3cpIC0+IElSUSAxNgpbICAgIDQuNzg1OTkyXSBhaGNpIDAwMDA6MDQ6MDAuMDogQUhDSSAwMDAx
LjAwMDAgMzIgc2xvdHMgMiBwb3J0cyA2IEdicHMgMHgzIGltcGwgU0FUQSBtb2RlClsgICAgNC43
ODYwNDBdIGFoY2kgMDAwMDowNDowMC4wOiBmbGFnczogNjRiaXQgbmNxIHNudGYgbGVkIG9ubHkg
cG1wIGZicyBwaW8gc2x1bSBwYXJ0IHN4cyAKWyAgICA0Ljc4NjA5M10gYWhjaSAwMDAwOjA0OjAw
LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzg2MzgzXSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuNzg2MzkyXSB4ZW46
IC0tPiBwaXJxPTIzIC0+IGlycT0yMyAoZ3NpPTIzKQpbICAgIDQuNzg2NDA2XSBzY3NpNiA6IGFo
Y2kKWyAgICA0Ljc4NjQxMl0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBQQ0kgSU5UIEEgLT4gR1NJ
IDIzIChsZXZlbCwgbG93KSAtPiBJUlEgMjMKWyAgICA0Ljc4NjQzNl0gZWhjaV9oY2QgMDAwMDow
MDoxZC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0Ljc4NjQ0MV0gZWhjaV9o
Y2QgMDAwMDowMDoxZC4wOiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQuNzg2NDUzXSBlaGNp
X2hjZCAwMDAwOjAwOjFkLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBu
dW1iZXIgNgpbICAgIDQuNzg2NTEyXSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IGRlYnVnIHBvcnQg
MgpbICAgIDQuNzg2ODM0XSBzY3NpNyA6IGFoY2kKWyAgICA0Ljc4Njk0M10gYXRhNzogU0FUQSBt
YXggVURNQS8xMzMgYWJhciBtMjA0OEAweGZiZDEwMDAwIHBvcnQgMHhmYmQxMDEwMCBpcnEgMzAx
ClsgICAgNC43ODcwNDBdIGF0YTg6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmYmQx
MDAwMCBwb3J0IDB4ZmJkMTAxODAgaXJxIDMwMQpbICAgIDQuNzkwMzkxXSBlaGNpX2hjZCAwMDAw
OjAwOjFkLjA6IGNhY2hlIGxpbmUgc2l6ZSBvZiA2NCBpcyBub3Qgc3VwcG9ydGVkClsgICAgNC43
OTA0MzFdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogaXJxIDIzLCBpbyBtZW0gMHhmYmYwMjAwMApb
ICAgIDQuODAzODkyXSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IFVTQiAyLjAgc3RhcnRlZCwgRUhD
SSAxLjAwClsgICAgNC44MDM5NjZdIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRW
ZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIKWyAgICA0LjgwNDAwMV0gdXNiIHVzYjY6IE5ldyBV
U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAg
NC44MDQwNDZdIHVzYiB1c2I2OiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQu
ODA0MDc3XSB1c2IgdXNiNjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjIuMC0xLWFtZDY0IGVoY2lf
aGNkClsgICAgNC44MDQxMTBdIHVzYiB1c2I2OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWQuMApb
ICAgIDQuODA0MjQ0XSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDQuODA0MjgxXSBo
dWIgNi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAgIDQuODExOTYxXSBmaXJld2lyZV9vaGNp
OiBBZGRlZCBmdy1vaGNpIGRldmljZSAwMDAwOjBjOjAwLjAsIE9IQ0kgdjEuMTAsIDQgSVIgKyA4
IElUIGNvbnRleHRzLCBxdWlya3MgMHgxMQpbICAgIDQuOTk1OTQyXSB1c2IgMS0yOiBuZXcgaGln
aC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIHhoY2lfaGNkClsgICAgNS4wMTMxOTZd
IHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNDA5LCBpZFByb2R1Y3Q9
MDA1YQpbICAgIDUuMDEzMjU0XSB1c2IgMS0yOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9
MCwgUHJvZHVjdD0wLCBTZXJpYWxOdW1iZXI9MApbICAgIDUuMDEzNDgwXSBodWIgMS0yOjEuMDog
VVNCIGh1YiBmb3VuZApbICAgIDUuMDEzNjgyXSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IFdBUk46
IHNob3J0IHRyYW5zZmVyIG9uIGNvbnRyb2wgZXAKWyAgICA1LjAxMzgxNl0gaHViIDEtMjoxLjA6
IDQgcG9ydHMgZGV0ZWN0ZWQKWyAgICA1LjEwMzkwNF0gYXRhMzogU0FUQSBsaW5rIGRvd24gKFNT
dGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAgNS4xMDM5OTJdIGF0YTY6IFNBVEEgbGluayBkb3du
IChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgIDUuMTA0MDA2XSBhdGE3OiBTQVRBIGxpbmsg
ZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMzMCkKWyAgICA1LjEwNDA1NV0gYXRhODogU0FUQSBs
aW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMzApClsgICAgNS4xMDQxNzBdIGF0YTE6IFNB
VEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgIDUuMTA0MjMwXSBhdGE1
OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkKWyAgICA1LjExMTkxMF0g
YXRhNDogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAgNS4xMTE5
OTRdIGF0YTI6IFNBVEEgbGluayB1cCA2LjAgR2JwcyAoU1N0YXR1cyAxMzMgU0NvbnRyb2wgMzAw
KQpbICAgIDUuMTEyMzA0XSBhdGEyLjAwOiBBVEEtODogSU5URUwgU1NEU0MyTUgxMjBBMiwgUFBH
NCwgbWF4IFVETUEvMTMzClsgICAgNS4xMTIzNTVdIGF0YTIuMDA6IDIzNDQ0MTY0OCBzZWN0b3Jz
LCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBClsgICAgNS4xMTI3MDNdIGF0
YTIuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzClsgICAgNS4xMTI4NTRdIHNjc2kgMTowOjA6
MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgSU5URUwgU1NEU0MyTUgxMiBQUEc0IFBROiAw
IEFOU0k6IDUKWyAgICA1LjExNjc4Ml0gc2QgMTowOjA6MDogW3NkYV0gMjM0NDQxNjQ4IDUxMi1i
eXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTIwIEdCLzExMSBHaUIpClsgICAgNS4xMTY5NTldIHNkIDE6
MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNS4xMTY5OTFdIHNkIDE6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNS4xMTcwMjZdIHNkIDE6MDow
OjA6IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBkb2Vz
bid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDUuMTE5MDcwXSAgc2RhOiBzZGExIHNkYTIgc2Rh
MwpbICAgIDUuMTE5NDgwXSBzZCAxOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAg
ICA1LjEyMzg4N10gdXNiIDMtMTogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1
c2luZyBlaGNpX2hjZApbICAgIDUuMjU2MjM1XSB1c2IgMy0xOiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9ODA4NywgaWRQcm9kdWN0PTAwMjQKWyAgICA1LjI1NjI5NF0gdXNiIDMtMTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAK
WyAgICA1LjI1NjUzNV0gaHViIDMtMToxLjA6IFVTQiBodWIgZm91bmQKWyAgICA1LjI1NjczNl0g
aHViIDMtMToxLjA6IDYgcG9ydHMgZGV0ZWN0ZWQKWyAgICA1LjMxMjI0M10gZmlyZXdpcmVfY29y
ZTogY3JlYXRlZCBkZXZpY2UgZncwOiBHVUlEIDAwOGYxMzAwNWQ2NTBmMDAsIFM0MDAKWyAgICA1
LjM2NzkwNF0gdXNiIDYtMTogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2lu
ZyBlaGNpX2hjZApbICAgIDUuMzg1ODY2XSBkZXZpY2UtbWFwcGVyOiB1ZXZlbnQ6IHZlcnNpb24g
MS4wLjMKWyAgICA1LjM4NTk3Nl0gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjIuMC1pb2N0bCAo
MjAxMS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KWyAgICA1LjUwMDIy
NV0gdXNiIDYtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTgwODcsIGlkUHJvZHVj
dD0wMDI0ClsgICAgNS41MDAyMzBdIHVzYiA2LTE6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0wLCBQcm9kdWN0PTAsIFNlcmlhbE51bWJlcj0wClsgICAgNS41MDA1MTJdIGh1YiA2LTE6MS4w
OiBVU0IgaHViIGZvdW5kClsgICAgNS41MDA1OTVdIGh1YiA2LTE6MS4wOiA4IHBvcnRzIGRldGVj
dGVkClsgICAgNS41NzE5NzddIHVzYiAzLTEuNDogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmljZSBu
dW1iZXIgMyB1c2luZyBlaGNpX2hjZApbICAgIDUuNjY0NzIzXSB1c2IgMy0xLjQ6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNzgxLCBpZFByb2R1Y3Q9NTU2NwpbICAgIDUuNjY0NzI3
XSB1c2IgMy0xLjQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNl
cmlhbE51bWJlcj0zClsgICAgNS42NjQ3MzFdIHVzYiAzLTEuNDogUHJvZHVjdDogQ3J1emVyIEJs
YWRlClsgICAgNS42NjQ3MzRdIHVzYiAzLTEuNDogTWFudWZhY3R1cmVyOiBTYW5EaXNrClsgICAg
NS42NjQ3MzZdIHVzYiAzLTEuNDogU2VyaWFsTnVtYmVyOiAyMDA1MTUzNTgyMThCNUEzM0NCRQpb
ICAgIDUuNjY3MDYyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVh
cwpbICAgIDUuNjY3NzcxXSBJbml0aWFsaXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4K
WyAgICA1LjY2Nzg4OF0gc2NzaTggOiB1c2Itc3RvcmFnZSAzLTEuNDoxLjAKWyAgICA1LjY2Nzk4
NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQpb
ICAgIDUuNjY3OTg3XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KWyAgICA1
Ljc3MTk2N10gdXNiIDYtMS4xOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDMgdXNp
bmcgZWhjaV9oY2QKWyAgICA1Ljg4MjExNV0gdXNiIDYtMS4xOiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9MDRkOSwgaWRQcm9kdWN0PTIyMjEKWyAgICA1Ljg4MjExOV0gdXNiIDYtMS4x
OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MCwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9
MApbICAgIDUuODgyMTIzXSB1c2IgNi0xLjE6IFByb2R1Y3Q6IFVTQiBLZXlib2FyZApbICAgIDUu
ODk1NTMzXSBpbnB1dDogVVNCIEtleWJvYXJkIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDow
MDoxZC4wL3VzYjYvNi0xLzYtMS4xLzYtMS4xOjEuMC9pbnB1dC9pbnB1dDAKWyAgICA1Ljg5NTYw
NF0gZ2VuZXJpYy11c2IgMDAwMzowNEQ5OjIyMjEuMDAwMTogaW5wdXQsaGlkcmF3MDogVVNCIEhJ
RCB2MS4xMCBLZXlib2FyZCBbVVNCIEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDoxZC4wLTEuMS9p
bnB1dDAKWyAgICA1LjkxODYzNl0gaW5wdXQ6IFVTQiBLZXlib2FyZCBhcyAvZGV2aWNlcy9wY2kw
MDAwOjAwLzAwMDA6MDA6MWQuMC91c2I2LzYtMS82LTEuMS82LTEuMToxLjEvaW5wdXQvaW5wdXQx
ClsgICAgNS45MTg3MDhdIGdlbmVyaWMtdXNiIDAwMDM6MDREOToyMjIxLjAwMDI6IGlucHV0LGhp
ZHJhdzE6IFVTQiBISUQgdjEuMTAgRGV2aWNlIFtVU0IgS2V5Ym9hcmRdIG9uIHVzYi0wMDAwOjAw
OjFkLjAtMS4xL2lucHV0MQpbICAgIDUuOTE4NzI0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIHVzYmhpZApbICAgIDUuOTE4NzI2XSB1c2JoaWQ6IFVTQiBISUQgY29y
ZSBkcml2ZXIKWyAgICA1Ljk1MTk5MV0gdXNiIDYtMS4yOiBuZXcgZnVsbC1zcGVlZCBVU0IgZGV2
aWNlIG51bWJlciA0IHVzaW5nIGVoY2lfaGNkClsgICAgNi4wNDYzNTddIHVzYiA2LTEuMjogTmV3
IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTE1MzIsIGlkUHJvZHVjdD0wMDE1ClsgICAgNi4w
NDYzNjJdIHVzYiA2LTEuMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9
MiwgU2VyaWFsTnVtYmVyPTAKWyAgICA2LjA0NjM2Nl0gdXNiIDYtMS4yOiBQcm9kdWN0OiBSYXpl
ciBOYWdhClsgICAgNi4wNDYzNjhdIHVzYiA2LTEuMjogTWFudWZhY3R1cmVyOiBSYXplcgpbICAg
IDYuMDkyNjMwXSBpbnB1dDogUmF6ZXIgUmF6ZXIgTmFnYSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAw
LzAwMDA6MDA6MWQuMC91c2I2LzYtMS82LTEuMi82LTEuMjoxLjAvaW5wdXQvaW5wdXQyClsgICAg
Ni4wOTI3NTRdIGdlbmVyaWMtdXNiIDAwMDM6MTUzMjowMDE1LjAwMDM6IGlucHV0LGhpZHJhdzI6
IFVTQiBISUQgdjEuMTEgTW91c2UgW1JhemVyIFJhemVyIE5hZ2FdIG9uIHVzYi0wMDAwOjAwOjFk
LjAtMS4yL2lucHV0MApbICAgIDYuMDkzODE1XSBpbnB1dDogUmF6ZXIgUmF6ZXIgTmFnYSBhcyAv
ZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MWQuMC91c2I2LzYtMS82LTEuMi82LTEuMjoxLjEv
aW5wdXQvaW5wdXQzClsgICAgNi4wOTM5MzRdIGdlbmVyaWMtdXNiIDAwMDM6MTUzMjowMDE1LjAw
MDQ6IGlucHV0LGhpZHJhdzM6IFVTQiBISUQgdjEuMTEgS2V5Ym9hcmQgW1JhemVyIFJhemVyIE5h
Z2FdIG9uIHVzYi0wMDAwOjAwOjFkLjAtMS4yL2lucHV0MQpbICAgIDYuNjY4NjM3XSBzY3NpIDg6
MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIFNhbkRpc2sgIENydXplciBCbGFkZSAgICAgMS4wMCBQ
UTogMCBBTlNJOiAyClsgICAgNi42Njk5NzZdIHNkIDg6MDowOjA6IFtzZGJdIDMxMjUwNDMyIDUx
Mi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTYuMCBHQi8xNC45IEdpQikKWyAgICA2LjY3MDcyM10g
c2QgODowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA2LjY3MDcyNl0gc2Qg
ODowOjA6MDogW3NkYl0gTW9kZSBTZW5zZTogMDMgMDAgMDAgMDAKWyAgICA2LjY3MTczOV0gc2Qg
ODowOjA6MDogW3NkYl0gTm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDYuNjcxNzQ0
XSBzZCA4OjA6MDowOiBbc2RiXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaApb
ICAgIDYuNjc0NjA3XSBzZCA4OjA6MDowOiBbc2RiXSBObyBDYWNoaW5nIG1vZGUgcGFnZSBwcmVz
ZW50ClsgICAgNi42NzQ2MTFdIHNkIDg6MDowOjA6IFtzZGJdIEFzc3VtaW5nIGRyaXZlIGNhY2hl
OiB3cml0ZSB0aHJvdWdoClsgICAgNi42NzUzNzNdICBzZGI6IHNkYjEKWyAgICA2LjY3ODIxOV0g
c2QgODowOjA6MDogW3NkYl0gTm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDYuNjc4
MjIyXSBzZCA4OjA6MDowOiBbc2RiXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3Vn
aApbICAgIDYuNjc4MjI1XSBzZCA4OjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIHJlbW92YWJs
ZSBkaXNrClsgICAxMS42OTY5MThdIGFsZzogTm8gdGVzdCBmb3IgX19nY20tYWVzLWFlc25pIChf
X2RyaXZlci1nY20tYWVzLWFlc25pKQpbICAgMTEuNzAwOTc2XSBhbGc6IE5vIHRlc3QgZm9yIF9f
Y2JjLWFlcy1hZXNuaSAoY3J5cHRkKF9fZHJpdmVyLWNiYy1hZXMtYWVzbmkpKQpbICAgMTIuMjgx
NTUzXSBFWFQ0LWZzIChkbS0xKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRh
IG1vZGUuIE9wdHM6IChudWxsKQpbICAgMTIuNTE5MTAzXSB1ZGV2ZFszODNdOiBzdGFydGluZyB2
ZXJzaW9uIDE3NQpbICAgMTIuNjEzODIwXSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2Vz
L0xOWFNZU1RNOjAwL2RldmljZTowMC9QTlAwQzBDOjAwL2lucHV0L2lucHV0NApbICAgMTIuNjEz
ODg3XSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkJdClsgICAxMi42MTM5NzFdIGlucHV0OiBQb3dl
ciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQ1
ClsgICAxMi42MTQwMjVdIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgIDEyLjY0MjA5MF0g
d21pOiBNYXBwZXIgbG9hZGVkClsgICAxMi42OTAwMzVdIFtkcm1dIEluaXRpYWxpemVkIGRybSAx
LjEuMCAyMDA2MDgxMApbICAgMTIuNzA0MDc5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmln
Z2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgMTIuNzA0MDg1XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1
cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgIDEyLjcwNDEyNF0geGVuOiAtLT4gcGlycT0xNiAt
PiBpcnE9MTYgKGdzaT0xNikKWyAgIDEyLjcwNDEyNl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDox
NgpbICAgMTIuNzA0MTYyXSBpOTE1IDAwMDA6MDA6MDIuMDogUENJIElOVCBBIC0+IEdTSSAxNiAo
bGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAxMi43MDQyMDZdIGk5MTUgMDAwMDowMDowMi4wOiBz
ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDEyLjcwODgzOV0gcGNpX2hvdHBsdWc6IFBD
SSBIb3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUKWyAgIDEyLjc4NzYwOF0gaVRDT192ZW5k
b3Jfc3VwcG9ydDogdmVuZG9yLXN1cHBvcnQ9MApbICAgMTIuNzg5OTAxXSBpbnB1dDogUEMgU3Bl
YWtlciBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9wY3Nwa3IvaW5wdXQvaW5wdXQ2ClsgICAxMi43OTA1
ODRdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYxLjA3ClsgICAx
Mi43OTA3MDldIGlUQ09fd2R0OiBGb3VuZCBhIENvdWdhciBQb2ludCBUQ08gZGV2aWNlIChWZXJz
aW9uPTIsIFRDT0JBU0U9MHgwNDYwKQpbICAgMTIuNzkwODI2XSBpVENPX3dkdDogaW5pdGlhbGl6
ZWQuIGhlYXJ0YmVhdD0zMCBzZWMgKG5vd2F5b3V0PTApClsgICAxMi44NDAwNDZdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAxMi44NDAwNTJdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwpbICAgMTIuODQwMDk0
XSB4ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQpbICAgMTIuODQwMDk2XSBBbHJl
YWR5IHNldHVwIHRoZSBHU0kgOjE3ClsgICAxMi44NDAxMzNdIHNuZF9oZGFfaW50ZWwgMDAwMDow
MTowMC4xOiBQQ0kgSU5UIEIgLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKWyAgIDEy
Ljg0MDM0MV0gc25kX2hkYV9pbnRlbCAwMDAwOjAxOjAwLjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1l
ciB0byA2NApbICAgMTIuODU5Mjc5XSBbZHJtXSBNVFJSIGFsbG9jYXRpb24gZmFpbGVkLiAgR3Jh
cGhpY3MgcGVyZm9ybWFuY2UgbWF5IHN1ZmZlci4KWyAgIDEyLjg2MDQ5NF0gW2RybV0gU3VwcG9y
dHMgdmJsYW5rIHRpbWVzdGFtcCBjYWNoaW5nIFJldiAxICgxMC4xMC4yMDEwKS4KWyAgIDEyLjg2
MDUzNF0gW2RybV0gRHJpdmVyIHN1cHBvcnRzIHByZWNpc2UgdmJsYW5rIHRpbWVzdGFtcCBxdWVy
eS4KWyAgIDEyLjg2MDY1NV0gdmdhYXJiOiBkZXZpY2UgY2hhbmdlZCBkZWNvZGVzOiBQQ0k6MDAw
MDowMDowMi4wLG9sZGRlY29kZXM9aW8rbWVtLGRlY29kZXM9bm9uZTpvd25zPWlvK21lbQpbICAg
MTIuODYwNzExXSB2Z2FhcmI6IHRyYW5zZmVycmluZyBvd25lciBmcm9tIFBDSTowMDAwOjAwOjAy
LjAgdG8gUENJOjAwMDA6MDE6MDAuMApbICAgMTIuODYyOTQ3XSBIRE1JIHN0YXR1czogQ29kZWM9
MCBQaW49MyBQcmVzZW5jZV9EZXRlY3Q9MCBFTERfVmFsaWQ9MApbICAgMTIuODYzMDkwXSBpbnB1
dDogSEQtQXVkaW8gR2VuZXJpYyBIRE1JL0RQLHBjbT0zIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAv
MDAwMDowMDowMS4wLzAwMDA6MDE6MDAuMS9zb3VuZC9jYXJkMC9pbnB1dDcKWyAgIDEzLjYxMjI3
Nl0gZmJjb246IGludGVsZHJtZmIgKGZiMCkgaXMgcHJpbWFyeSBkZXZpY2UKWyAgIDEzLjk2MzYz
OV0gQ29uc29sZTogc3dpdGNoaW5nIHRvIGNvbG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDI0MHg2
NwpbICAgMTMuOTY4ODA0XSBmYjA6IGludGVsZHJtZmIgZnJhbWUgYnVmZmVyIGRldmljZQpbICAg
MTMuOTY4ODA1XSBkcm06IHJlZ2lzdGVyZWQgcGFuaWMgbm90aWZpZXIKWyAgIDEzLjk2ODg2Ml0g
Tm8gQUNQSSB2aWRlbyBidXMgZm91bmQKWyAgIDEzLjk2ODk0N10gW2RybV0gSW5pdGlhbGl6ZWQg
aTkxNSAxLjYuMCAyMDA4MDczMCBmb3IgMDAwMDowMDowMi4wIG9uIG1pbm9yIDAKWyAgIDEzLjk2
OTExOF0gc2hwY2hwOiBTdGFuZGFyZCBIb3QgUGx1ZyBQQ0kgQ29udHJvbGxlciBEcml2ZXIgdmVy
c2lvbjogMC40ClsgICAxMy45NjkxNDhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAxMy45NjkxNTNdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmlu
ZyBpcnEgMTggZm9yIGdzaSAxOApbICAgMTMuOTY5MTU1XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGly
cT0xOCAoZ3NpPTE4KQpbICAgMTMuOTY5MTU4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Clsg
ICAxMy45NjkxNjJdIGk4MDFfc21idXMgMDAwMDowMDoxZi4zOiBQQ0kgSU5UIEMgLT4gR1NJIDE4
IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgIDEzLjk4OTg0MF0geGVuOiByZWdpc3RlcmluZyBn
c2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgIDEzLjk4OTg0NV0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2ClsgICAxMy45ODk4ODRdIHhlbjogLS0+
IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAxMy45ODk4ODZdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MTYKWyAgIDEzLjk4OTkxM10gc25kX3ZpcnR1b3NvIDAwMDA6MDM6MDQuMDogUENJ
IElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAxNS40MDI2NDVdIEVY
VDQtZnMgKGRtLTEpOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkKWyAgIDE1LjQyNzcyOV0gRVhU
NC1mcyAoZG0tMSk6IHJlLW1vdW50ZWQuIE9wdHM6IHVzZXJfeGF0dHIsZXJyb3JzPXJlbW91bnQt
cm8KWyAgIDE1LjU0NTkwOV0gbG9vcDogbW9kdWxlIGxvYWRlZApbICAgMTUuODk3MDAxXSBFWFQ0
LWZzIChzZGEyKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9w
dHM6IChudWxsKQpbICAgMTYuMDEzMTY3XSBCcmlkZ2UgZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZApb
ICAgMTYuMDE4MjIzXSBkZXZpY2UgZXRoMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUKWyAgIDE2
LjE3NTM2OV0gQUREUkNPTkYoTkVUREVWX1VQKTogZXRoMDogbGluayBpcyBub3QgcmVhZHkKWyAg
IDE2LjE3OTU2MV0gQUREUkNPTkYoTkVUREVWX1VQKTogYnIwOiBsaW5rIGlzIG5vdCByZWFkeQpb
ICAgMTkuNTIxMDM2XSB0ZzMgMDAwMDowZDowMC4wOiBldGgwOiBMaW5rIGlzIHVwIGF0IDEwMDAg
TWJwcywgZnVsbCBkdXBsZXgKWyAgIDE5LjUyMjU5NF0gdGczIDAwMDA6MGQ6MDAuMDogZXRoMDog
RmxvdyBjb250cm9sIGlzIG9uIGZvciBUWCBhbmQgb24gZm9yIFJYClsgICAxOS41MjQxMzJdIHRn
MyAwMDAwOjBkOjAwLjA6IGV0aDA6IEVFRSBpcyBkaXNhYmxlZApbICAgMTkuNTI2MDQ0XSBBRERS
Q09ORihORVRERVZfQ0hBTkdFKTogZXRoMDogbGluayBiZWNvbWVzIHJlYWR5ClsgICAxOS41Mjc1
NzRdIGJyMDogdG9wb2xvZ3kgY2hhbmdlIGRldGVjdGVkLCBwcm9wYWdhdGluZwpbICAgMTkuNTI5
MDg5XSBicjA6IHBvcnQgMShldGgwKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlClsgICAxOS41
MzA2MDJdIGJyMDogcG9ydCAxKGV0aDApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKWyAgIDE5
LjUzMjQyOF0gQUREUkNPTkYoTkVUREVWX0NIQU5HRSk6IGJyMDogbGluayBiZWNvbWVzIHJlYWR5
ClsgICAyMi4zODY1NjVdIFJQQzogUmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNvY2tldCB0cmFuc3Bv
cnQgbW9kdWxlLgpbICAgMjIuMzg4MDE5XSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBt
b2R1bGUuClsgICAyMi4zODk0NjhdIFJQQzogUmVnaXN0ZXJlZCB0Y3AgdHJhbnNwb3J0IG1vZHVs
ZS4KWyAgIDIyLjM5MDkwOF0gUlBDOiBSZWdpc3RlcmVkIHRjcCBORlN2NC4xIGJhY2tjaGFubmVs
IHRyYW5zcG9ydCBtb2R1bGUuClsgICAyMi4zOTgxNDBdIEZTLUNhY2hlOiBMb2FkZWQKWyAgIDIy
LjQwNzEzM10gRlMtQ2FjaGU6IE5ldGZzICduZnMnIHJlZ2lzdGVyZWQgZm9yIGNhY2hpbmcKWyAg
IDIyLjQxNDI1Ml0gSW5zdGFsbGluZyBrbmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJAbW9u
YWQuc3diLmRlKS4KWyAgIDIzLjM5MDMzNV0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjE3KQpb
ICAgMjQuMTE0MTUyXSBCbHVldG9vdGg6IENvcmUgdmVyIDIuMTYKWyAgIDI0LjExNDE3Ml0gTkVU
OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAzMQpbICAgMjQuMTE0MTczXSBCbHVldG9vdGg6
IEhDSSBkZXZpY2UgYW5kIGNvbm5lY3Rpb24gbWFuYWdlciBpbml0aWFsaXplZApbICAgMjQuMTE0
MTc1XSBCbHVldG9vdGg6IEhDSSBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgIDI0LjExNDE3
Nl0gQmx1ZXRvb3RoOiBMMkNBUCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgIDI0LjExNDQz
NF0gQmx1ZXRvb3RoOiBTQ08gc29ja2V0IGxheWVyIGluaXRpYWxpemVkClsgICAyNC4xMjA5Nzld
IEJsdWV0b290aDogQk5FUCAoRXRoZXJuZXQgRW11bGF0aW9uKSB2ZXIgMS4zClsgICAyNC4xMjA5
ODFdIEJsdWV0b290aDogQk5FUCBmaWx0ZXJzOiBwcm90b2NvbCBtdWx0aWNhc3QKWyAgIDI0LjU2
MDQ1OF0gQmx1ZXRvb3RoOiBSRkNPTU0gVFRZIGxheWVyIGluaXRpYWxpemVkClsgICAyNC41NjA0
NjNdIEJsdWV0b290aDogUkZDT01NIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgMjQuNTYw
NDY0XSBCbHVldG9vdGg6IFJGQ09NTSB2ZXIgMS4xMQpbICAgMjYuMTYwNzAxXSBFdmVudC1jaGFu
bmVsIGRldmljZSBpbnN0YWxsZWQuClsgICAyNi4xOTczOTNdIFhFTkJVUzogVW5hYmxlIHRvIHJl
YWQgY3B1IHN0YXRlClsgICAyNi4xOTc1MzVdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0
YXRlClsgICAyNi45MDc4ODhdIFtkcm06aW50ZWxfZGlzYWJsZV90cmFuc2NvZGVyXSAqRVJST1Iq
IGZhaWxlZCB0byBkaXNhYmxlIHRyYW5zY29kZXIgMQpbICAgNDkuNjc0MzI3XSBGQVQtZnMgKHNk
YjEpOiB1dGY4IGlzIG5vdCBhIHJlY29tbWVuZGVkIElPIGNoYXJzZXQgZm9yIEZBVCBmaWxlc3lz
dGVtcywgZmlsZXN5c3RlbSB3aWxsIGJlIGNhc2Ugc2Vuc2l0aXZlIQpbICAgODAuNDE4ODkxXSBX
QVJOSU5HISBwb3dlci9sZXZlbCBpcyBkZXByZWNhdGVkOyB1c2UgcG93ZXIvY29udHJvbCBpbnN0
ZWFkClsgICA4MC40OTYwODhdIHVzYiAzLTEuNDogVVNCIGRpc2Nvbm5lY3QsIGRldmljZSBudW1i
ZXIgMwo=
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="xm_dmesg.txt"
Content-Disposition: attachment; filename="xm_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxc0691

KFhFTikgWGVuIHZlcnNpb24gNC4xLjIgKERlYmlhbiA0LjEuMi0yKSAod2FsZGlAZGViaWFuLm9y
ZykgKGdjYyB2ZXJzaW9uIDQuNi4yIChEZWJpYW4gNC42LjItNikgKSBTYXQgRGVjIDEwIDE5OjU4
OjIxIFVUQyAyMDExCihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OS0xNAooWEVOKSBDb21tYW5k
IGxpbmU6IHBsYWNlaG9sZGVyIGRvbTBfbWF4X3ZjcHVzPTIgZG9tMF92Y3B1c19waW4gZG9tMF9t
ZW09ODE5Mk0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2Rl
IDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNm
ZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAy
IE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVz
CihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAw
MDAwMDA5ZDgwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5ZDgwMCAtIDAwMDAwMDAwMDAw
YTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAw
MDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAg
KHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwIChyZXNl
cnZlZCkKKFhFTikgIDAwMDAwMDAwMjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAwICh1c2FibGUp
CihYRU4pICAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAocmVzZXJ2ZWQpCihY
RU4pICAwMDAwMDAwMDQwMjAwMDAwIC0gMDAwMDAwMDA2ZWQ2ZDAwMCAodXNhYmxlKQooWEVOKSAg
MDAwMDAwMDA2ZWQ2ZDAwMCAtIDAwMDAwMDAwNmVkYmMwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAw
MDAwMDA2ZWRiYzAwMCAtIDAwMDAwMDAwNmVkYzUwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAw
MDAwNmVkYzUwMDAgLSAwMDAwMDAwMDZlZGYyMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAw
NmVkZjIwMDAgLSAwMDAwMDAwMDZlZGYzMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDZlZGYz
MDAwIC0gMDAwMDAwMDA2ZWUwMzAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDZlZTAzMDAw
IC0gMDAwMDAwMDA2ZWUxMDAwMCAoQUNQSSBOVlMpCihYRU4pICAwMDAwMDAwMDZlZTEwMDAwIC0g
MDAwMDAwMDA2ZWUzODAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDZlZTM4MDAwIC0gMDAw
MDAwMDA2ZWU3YjAwMCAoQUNQSSBOVlMpCihYRU4pICAwMDAwMDAwMDZlZTdiMDAwIC0gMDAwMDAw
MDA2ZjAwMDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDA2ZjgwMDAwMCAtIDAwMDAwMDAwN2Zh
MDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZWQxYzAwMCAtIDAwMDAwMDAwZmVkNDAw
MDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAg
KHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA0N2ZlMDAwMDAgKHVz
YWJsZSkKKFhFTikgQUNQSTogUlNEUCAwMDBGMDQ1MCwgMDAyNCAocjIgQUxBU0tBKQooWEVOKSBB
Q1BJOiBYU0RUIDZFREJDMDcwLCAwMDVDIChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgQU1J
ICAgICAxMDAxMykKKFhFTikgQUNQSTogRkFDUCA2RURDNDE1OCwgMDBGNCAocjQgQUxBU0tBICAg
IEEgTSBJICAxMDcyMDA5IEFNSSAgICAgMTAwMTMpCihYRU4pIEFDUEk6IERTRFQgNkVEQkMxNTgs
IDdGRkIgKHIyIEFMQVNLQSAgICBBIE0gSSAgICAgICAgMCBJTlRMIDIwMDUxMTE3KQooWEVOKSBB
Q1BJOiBGQUNTIDZFRTA3RjgwLCAwMDQwCihYRU4pIEFDUEk6IEFQSUMgNkVEQzQyNTAsIDAwOTIg
KHIzIEFMQVNLQSAgICBBIE0gSSAgMTA3MjAwOSBBTUkgICAgIDEwMDEzKQooWEVOKSBBQ1BJOiBT
U0RUIDZFREM0MkU4LCAwMUQ2IChyMSBBTUlDUFUgICAgIFBST0MgICAgICAgIDEgTVNGVCAgMzAw
MDAwMSkKKFhFTikgQUNQSTogTUNGRyA2RURDNDRDMCwgMDAzQyAocjEgQUxBU0tBICAgIEEgTSBJ
ICAxMDcyMDA5IE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IEFBRlQgNkVEQzQ1MDAsIDAwRDMg
KHIxIEFMQVNLQSBPRU1BQUZUICAgMTA3MjAwOSBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBI
UEVUIDZFREM0NUQ4LCAwMDM4IChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgQU1JLiAgICAg
ICAgNCkKKFhFTikgQUNQSTogRE1BUiA2RURDNDYxMCwgMDBFOCAocjEgQUxBU0tBICAgIEEgTSBJ
ICAgICAgICAxIElOVEwgICAgICAgIDEpCihYRU4pIFN5c3RlbSBSQU06IDE2MTA0TUIgKDE2NDkx
MDcya0IpCihYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCihYRU4pIEFDUEk6IDMyLzY0WCBG
QUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAtIDZlZTA3ZjgwLzAwMDAwMDAwMDAwMDAwMDAs
IHVzaW5nIDMyCihYRU4pIFByb2Nlc3NvciAjMCA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBQ
cm9jZXNzb3IgIzIgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgUHJvY2Vzc29yICM0IDY6MTAg
QVBJQyB2ZXJzaW9uIDIxCihYRU4pIFByb2Nlc3NvciAjNiA2OjEwIEFQSUMgdmVyc2lvbiAyMQoo
WEVOKSBQcm9jZXNzb3IgIzEgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgUHJvY2Vzc29yICMz
IDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIFByb2Nlc3NvciAjNSA2OjEwIEFQSUMgdmVyc2lv
biAyMQooWEVOKSBQcm9jZXNzb3IgIzcgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgSU9BUElD
WzBdOiBhcGljX2lkIDAsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMK
KFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDEgSS9PIEFQSUNzCihYRU4p
IFRhYmxlIGlzIG5vdCBmb3VuZCEKKFhFTikgU3dpdGNoZWQgdG8gQVBJQyBkcml2ZXIgeDJhcGlj
X2NsdXN0ZXIuCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNy
ZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMzM5Mi4zNzYgTUh6IHByb2Nlc3Nvci4KKFhFTikgSW5pdGlu
ZyBtZW1vcnkgc2hhcmluZy4KKFhFTikgSW50ZWwgVlQtZCBTbm9vcCBDb250cm9sIG5vdCBlbmFi
bGVkLgooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1BIFBhc3N0aHJvdWdoIG5vdCBlbmFibGVkLgoo
WEVOKSBJbnRlbCBWVC1kIFF1ZXVlZCBJbnZhbGlkYXRpb24gZW5hYmxlZC4KKFhFTikgSW50ZWwg
VlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgU2hhcmVk
IEVQVCB0YWJsZXMgbm90IGVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVk
CihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBFbmFibGVkIGRpcmVjdGVkIEVPSSB3
aXRoIGlvYXBpY19hY2tfb2xkIG9uIQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKKFhFTikg
IC0+IFVzaW5nIG9sZCBBQ0sgbWV0aG9kCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1I
eiBIUEVUCihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgMTYgS2lCLgooWEVOKSBWTVg6
IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2
aXJ0dWFsaXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gRXh0ZW5kZWQg
UGFnZSBUYWJsZXMgKEVQVCkKKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMg
KFZQSUQpCihYRU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJp
dG1hcAooWEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhFTikgRVBUIHN1cHBvcnRzIDJNQiBz
dXBlciBwYWdlLgooWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCihYRU4pIEhWTTogVk1YIGVuYWJs
ZWQKKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgZGV0ZWN0ZWQuCihYRU4pIEJy
b3VnaHQgdXAgOCBDUFVzCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVu
ICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJp
dCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDE5M2EwMDAKKFhFTikgUEhZU0lDQUwg
TUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDQ2YzAwMDAw
MC0+MDAwMDAwMDQ3MDAwMDAwMCAoMjA3MjMzNCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4p
ICBJbml0LiByYW1kaXNrOiAwMDAwMDAwNDdkZDBlMDAwLT4wMDAwMDAwNDdmZGZmZTAwCihYRU4p
IFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZm
ZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MTkzYTAwMAooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZm
ZmY4MTkzYTAwMC0+ZmZmZmZmZmY4M2EyYmUwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZm
ZmY4M2EyYzAwMC0+ZmZmZmZmZmY4NGEyYzAwMAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZm
ZmY4NGEyYzAwMC0+ZmZmZmZmZmY4NGEyYzRiNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZm
ZmY4NGEyZDAwMC0+ZmZmZmZmZmY4NGE1NjAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZm
ZmY4NGE1NjAwMC0+ZmZmZmZmZmY4NGE1NzAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZm
ZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NGMwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZm
ZmY4MTZhOTIwMAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDIgVkNQVXMKKFhFTikgU2NydWJiaW5n
IEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuCihYRU4pIFhlbiB0cmFjZSBidWZm
ZXJzOiBkaXNhYmxlZAooWEVOKSBTdGQuIExvZ2xldmVsOiBFcnJvcnMgYW5kIHdhcm5pbmdzCihY
RU4pIEd1ZXN0IExvZ2xldmVsOiBOb3RoaW5nIChSYXRlLWxpbWl0ZWQ6IEVycm9ycyBhbmQgd2Fy
bmluZ3MpCihYRU4pIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSAqKiog
U2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNo
IGlucHV0IHRvIFhlbikKKFhFTikgRnJlZWQgMjE2a0IgaW5pdCBtZW1vcnkuCihYRU4pIHBoeXNk
ZXYuYzoxNTU6IGRvbTA6IHdyb25nIG1hcF9waXJxIHR5cGUgMwo=
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="xm_info.txt"
Content-Disposition: attachment; filename="xm_info.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxc7bs2

aG9zdCAgICAgICAgICAgICAgICAgICA6IG11YWRkaWIKcmVsZWFzZSAgICAgICAgICAgICAgICA6
IDMuMi4wLTEtYW1kNjQKdmVyc2lvbiAgICAgICAgICAgICAgICA6ICMxIFNNUCBTdW4gRmViIDUg
MTU6MTc6MTUgVVRDIDIwMTIKbWFjaGluZSAgICAgICAgICAgICAgICA6IHg4Nl82NApucl9jcHVz
ICAgICAgICAgICAgICAgIDogOApucl9ub2RlcyAgICAgICAgICAgICAgIDogMQpjb3Jlc19wZXJf
c29ja2V0ICAgICAgIDogNAp0aHJlYWRzX3Blcl9jb3JlICAgICAgIDogMgpjcHVfbWh6ICAgICAg
ICAgICAgICAgIDogMzM5Mgpod19jYXBzICAgICAgICAgICAgICAgIDogYmZlYmZiZmY6MjgxMDA4
MDA6MDAwMDAwMDA6MDAwMDNmNDA6MTNiYWUzZmY6MDAwMDAwMDA6MDAwMDAwMDE6MDAwMDAwMDAK
dmlydF9jYXBzICAgICAgICAgICAgICA6IGh2bSBodm1fZGlyZWN0aW8KdG90YWxfbWVtb3J5ICAg
ICAgICAgICA6IDE2MTA0CmZyZWVfbWVtb3J5ICAgICAgICAgICAgOiAxMDAyMgpmcmVlX2NwdXMg
ICAgICAgICAgICAgIDogMAp4ZW5fbWFqb3IgICAgICAgICAgICAgIDogNAp4ZW5fbWlub3IgICAg
ICAgICAgICAgIDogMQp4ZW5fZXh0cmEgICAgICAgICAgICAgIDogLjIKeGVuX2NhcHMgICAgICAg
ICAgICAgICA6IHhlbi0zLjAteDg2XzY0IHhlbi0zLjAteDg2XzMycCBodm0tMy4wLXg4Nl8zMiBo
dm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14ODZfNjQgCnhlbl9zY2hlZHVsZXIgICAgICAgICAgOiBj
cmVkaXQKeGVuX3BhZ2VzaXplICAgICAgICAgICA6IDQwOTYKcGxhdGZvcm1fcGFyYW1zICAgICAg
ICA6IHZpcnRfc3RhcnQ9MHhmZmZmODAwMDAwMDAwMDAwCnhlbl9jaGFuZ2VzZXQgICAgICAgICAg
OiB1bmF2YWlsYWJsZQp4ZW5fY29tbWFuZGxpbmUgICAgICAgIDogcGxhY2Vob2xkZXIgZG9tMF9t
YXhfdmNwdXM9MiBkb20wX3ZjcHVzX3BpbiBkb20wX21lbT04MTkyTQpjY19jb21waWxlciAgICAg
ICAgICAgIDogZ2NjIHZlcnNpb24gNC42LjIgKERlYmlhbiA0LjYuMi02KSAKY2NfY29tcGlsZV9i
eSAgICAgICAgICA6IHdhbGRpCmNjX2NvbXBpbGVfZG9tYWluICAgICAgOiBkZWJpYW4ub3JnCmNj
X2NvbXBpbGVfZGF0ZSAgICAgICAgOiBTYXQgRGVjIDEwIDE5OjU4OjIxIFVUQyAyMDExCnhlbmRf
Y29uZmlnX2Zvcm1hdCAgICAgOiA0Cg==
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="xm_list.txt"
Content-Disposition: attachment; filename="xm_list.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxca7r3

TmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAgIE1lbSBWQ1BV
cyAgICAgIFN0YXRlICAgVGltZShzKQpEb21haW4tMCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwICA1ODY2ICAgICAyICAgICByLS0tLS0gICAgMTE3LjAK
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bcaec54faf688f7e2504b994eb2f--


From xen-devel-bounces@lists.xen.org Wed Feb 22 22:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 22: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 1S0KXE-0006HO-CZ; Wed, 22 Feb 2012 22:19:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henrik@fixme.se>) id 1S0KXB-0006HI-MH
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 22:19:38 +0000
X-Env-Sender: henrik@fixme.se
X-Msg-Ref: server-5.tower-174.messagelabs.com!1329949165!14509752!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15745 invoked from network); 22 Feb 2012 22:19:27 -0000
Received: from mail-vw0-f45.google.com (HELO mail-vw0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 22:19:27 -0000
Received: by vbal1 with SMTP id l1so520731vba.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:19:25 -0800 (PST)
Received-SPF: pass (google.com: domain of henrik@fixme.se designates
	10.220.7.208 as permitted sender) client-ip=10.220.7.208; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of henrik@fixme.se
	designates 10.220.7.208 as permitted sender)
	smtp.mail=henrik@fixme.se
Received: from mr.google.com ([10.220.7.208])
	by 10.220.7.208 with SMTP id e16mr18568057vce.0.1329949165540 (num_hops
	= 1); Wed, 22 Feb 2012 14:19:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.7.208 with SMTP id e16mr14982853vce.0.1329949165190; Wed,
	22 Feb 2012 14:19:25 -0800 (PST)
Received: by 10.220.198.133 with HTTP; Wed, 22 Feb 2012 14:19:25 -0800 (PST)
Date: Wed, 22 Feb 2012 23:19:25 +0100
Message-ID: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
From: Henrik Olsson <henrik@fixme.se>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=bcaec54faf688f7e2504b994eb2f
X-Gm-Message-State: ALoCoQk/jMDljUGhmg2cTVC4fpmKy97M30xAoqyntn72uqSRGVSXXA+bwm3JmVgHMalsRVh7iBxG
Subject: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=ISO-8859-1

Hi, i'm having some trouble with assigning memory to my dom0.

I've added "dom0_mem=8192M" to the xen command line yet "free -m"
reports only 5686MB total.

Running Xen 4.1.2 with kernel 3.2.0-1-amd64, debian testing.

Attached are the outputs of dmesg, xm dmesg, xm info and xm list.

Regards,
Henrik Olsson

--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt"
Content-Disposition: attachment; filename="dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxbpfb0

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAgMC4w
MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAwXSBMaW51
eCB2ZXJzaW9uIDMuMi4wLTEtYW1kNjQgKERlYmlhbiAzLjIuNC0xKSAod2FsZGlAZGViaWFuLm9y
ZykgKGdjYyB2ZXJzaW9uIDQuNi4yIChEZWJpYW4gNC42LjItMTIpICkgIzEgU01QIFN1biBGZWIg
NSAxNToxNzoxNSBVVEMgMjAxMgpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6IHBsYWNlaG9s
ZGVyIHJvb3Q9L2Rldi9tYXBwZXIvbXVhZGRpYi1yb290IHJvIHJkYmxhY2tsaXN0PXJhZGVvbiBy
YWRlb24ubW9kc2V0PTAgbWVtPTgxOTJNClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgIDlkLTEwMCBw
Zm4gcmFuZ2U6IDk5IHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDlk
LT4xMDAKWyAgICAwLjAwMDAwMF0gRnJlZWluZyAgMjAwMDAtMjAyMDAgcGZuIHJhbmdlOiA1MTIg
cGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gMjAwMDAtPjIwMjAwClsg
ICAgMC4wMDAwMDBdIEZyZWVpbmcgIDQwMDAwLTQwMjAwIHBmbiByYW5nZTogNTEyIHBhZ2VzIGZy
ZWVkClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDQwMDAwLT40MDIwMApbICAgIDAuMDAw
MDAwXSBGcmVlaW5nICA2ZWQ2ZC02ZWRmMiBwZm4gcmFuZ2U6IDEzMyBwYWdlcyBmcmVlZApbICAg
IDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiA2ZWQ2ZC0+NmVkZjIKWyAgICAwLjAwMDAwMF0gRnJl
ZWluZyAgNmVkZjMtNmVlN2IgcGZuIHJhbmdlOiAxMzYgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAw
MF0gMS0xIG1hcHBpbmcgb24gNmVkZjMtPjZlZTdiClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgIDZm
MDAwLTEwMDAwMCBwZm4gcmFuZ2U6IDU5MzkyMCBwYWdlcyBmcmVlZApbICAgIDAuMDAwMDAwXSAx
LTEgbWFwcGluZyBvbiA2ZjAwMC0+MTAwMDAwClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDU5NTMx
MiBwYWdlcyBvZiB1bnVzZWQgbWVtb3J5ClsgICAgMC4wMDAwMDBdIFNldCA1OTUzMTIgcGFnZShz
KSB0byAxLTEgbWFwcGluZwpbICAgIDAuMDAwMDAwXSBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJB
TSBtYXA6ClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDlkMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwOWQ4MDAgLSAw
MDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAw
MDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjog
MDAwMDAwMDAyMDAwMDAwMCAtIDAwMDAwMDAwMjAyMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAw
MDAwXSAgWGVuOiAwMDAwMDAwMDIwMjAwMDAwIC0gMDAwMDAwMDA0MDAwMDAwMCAodXNhYmxlKQpb
ICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAo
cmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNDAyMDAwMDAgLSAwMDAwMDAw
MDZlZDZkMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNmVkNmQwMDAg
LSAwMDAwMDAwMDZlZGJjMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAw
MDA2ZWRiYzAwMCAtIDAwMDAwMDAwNmVkYzUwMDAgKEFDUEkgZGF0YSkKWyAgICAwLjAwMDAwMF0g
IFhlbjogMDAwMDAwMDA2ZWRjNTAwMCAtIDAwMDAwMDAwNmVkZjIwMDAgKHJlc2VydmVkKQpbICAg
IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDZlZGYyMDAwIC0gMDAwMDAwMDA2ZWRmMzAwMCAodXNh
YmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDZlZGYzMDAwIC0gMDAwMDAwMDA2ZWUw
MzAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNmVlMDMwMDAgLSAw
MDAwMDAwMDZlZTEwMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDA2
ZWUxMDAwMCAtIDAwMDAwMDAwNmVlMzgwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVu
OiAwMDAwMDAwMDZlZTM4MDAwIC0gMDAwMDAwMDA2ZWU3YjAwMCAoQUNQSSBOVlMpClsgICAgMC4w
MDAwMDBdICBYZW46IDAwMDAwMDAwNmVlN2IwMDAgLSAwMDAwMDAwMDZmMDAwMDAwICh1c2FibGUp
ClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwNmY4MDAwMDAgLSAwMDAwMDAwMDdmYTAwMDAw
IChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWMwMDAwMCAtIDAwMDAw
MDAwZmVjMDEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZlZDFj
MDAwIC0gMDAwMDAwMDBmZWQ0MDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAw
MDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAw
MF0gIFhlbjogMDAwMDAwMDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQpb
ICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMDQ3ZmUwMDAwMCAo
dXNhYmxlKQpbICAgIDAuMDAwMDAwXSBlODIwIHJlbW92ZSByYW5nZTogMDAwMDAwMDIwMDAwMDAw
MCAtIGZmZmZmZmZmZmZmZmZmZmYgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUg
RGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlClsgICAgMC4wMDAwMDBdIHVzZXItZGVmaW5lZCBw
aHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDAwMDAwMDAwMCAt
IDAwMDAwMDAwMDAwOWQwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAw
MDAwOWQ4MDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVz
ZXI6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDIwMDAwMDAwICh1c2FibGUpClsgICAgMC4w
MDAwMDBdICB1c2VyOiAwMDAwMDAwMDIwMDAwMDAwIC0gMDAwMDAwMDAyMDIwMDAwMCAocmVzZXJ2
ZWQpClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDIwMjAwMDAwIC0gMDAwMDAwMDA0MDAw
MDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA0MDAwMDAwMCAtIDAw
MDAwMDAwNDAyMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA0
MDIwMDAwMCAtIDAwMDAwMDAwNmVkNmQwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIHVzZXI6
IDAwMDAwMDAwNmVkNmQwMDAgLSAwMDAwMDAwMDZlZGJjMDAwIChBQ1BJIE5WUykKWyAgICAwLjAw
MDAwMF0gIHVzZXI6IDAwMDAwMDAwNmVkYmMwMDAgLSAwMDAwMDAwMDZlZGM1MDAwIChBQ1BJIGRh
dGEpClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDZlZGM1MDAwIC0gMDAwMDAwMDA2ZWRm
MjAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDZlZGYyMDAwIC0g
MDAwMDAwMDA2ZWRmMzAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2
ZWRmMzAwMCAtIDAwMDAwMDAwNmVlMDMwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgdXNl
cjogMDAwMDAwMDA2ZWUwMzAwMCAtIDAwMDAwMDAwNmVlMTAwMDAgKEFDUEkgTlZTKQpbICAgIDAu
MDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2ZWUxMDAwMCAtIDAwMDAwMDAwNmVlMzgwMDAgKHJlc2Vy
dmVkKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2ZWUzODAwMCAtIDAwMDAwMDAwNmVl
N2IwMDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDA2ZWU3YjAwMCAt
IDAwMDAwMDAwNmYwMDAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAw
NmY4MDAwMDAgLSAwMDAwMDAwMDdmYTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVz
ZXI6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKWyAgICAw
LjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwIChyZXNl
cnZlZCkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZl
ZTAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwZmYwMDAwMDAg
LSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAw
MDAxMDAwMDAwMDAgLSAwMDAwMDAwMjAwMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdIERN
SSAyLjcgcHJlc2VudC4KWyAgICAwLjAwMDAwMF0gRE1JOiBUbyBCZSBGaWxsZWQgQnkgTy5FLk0u
IFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4vWjY4IEV4dHJlbWU0IEdlbjMsIEJJT1MgUDEuMDAgMDcv
MDgvMjAxMQpbICAgIDAuMDAwMDAwXSBlODIwIHVwZGF0ZSByYW5nZTogMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwMTAwMDAgKHVzYWJsZSkgPT0+IChyZXNlcnZlZCkKWyAgICAwLjAwMDAw
MF0gZTgyMCByZW1vdmUgcmFuZ2U6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw
ICh1c2FibGUpClsgICAgMC4wMDAwMDBdIE5vIEFHUCBicmlkZ2UgZm91bmQKWyAgICAwLjAwMDAw
MF0gbGFzdF9wZm4gPSAweDIwMDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMApbICAgIDAu
MDAwMDAwXSB4MmFwaWMgZW5hYmxlZCBieSBCSU9TLCBzd2l0Y2hpbmcgdG8geDJhcGljIG9wcwpb
ICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4NmYwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAw
MDAKWyAgICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRhYmxlIGF0IFtmZmZmODgwMDAwMGZkMjMw
XSBmZDIzMApbICAgIDAuMDAwMDAwXSBpbml0aWFsIG1lbW9yeSBtYXBwZWQgOiAwIC0gMDNhMmMw
MDAKWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbZmZmZjg4MDAwMDA5
ODAwMF0gOTgwMDAgc2l6ZSAyMDQ4MApbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5n
OiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwNmYwMDAwMDAKWyAgICAwLjAwMDAwMF0gIDAwMDAw
MDAwMDAgLSAwMDZmMDAwMDAwIHBhZ2UgNGsKWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBt
YXBwaW5nIHRhYmxlcyB1cCB0byA2ZjAwMDAwMCBAIGM4NTAwMC0xMDAwMDAwClsgICAgMC4wMDAw
MDBdIHhlbjogc2V0dGluZyBSVyB0aGUgcmFuZ2UgZmQ0MDAwIC0gMTAwMDAwMApbICAgIDAuMDAw
MDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMTAwMDAwMDAwLTAwMDAwMDAyMDAwMDAw
MDAKWyAgICAwLjAwMDAwMF0gIDAxMDAwMDAwMDAgLSAwMjAwMDAwMDAwIHBhZ2UgNGsKWyAgICAw
LjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAyMDAwMDAwMDAgQCA2
ZGQ2NDAwMC02ZWQ2ZDAwMApbICAgIDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdl
IDZlNTY4MDAwIC0gNmVkNmQwMDAKWyAgICAwLjAwMDAwMF0gUkFNRElTSzogMDE5M2EwMDAgLSAw
M2EyYzAwMApbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDAwMDAwMDAwMDAwZjA0NTAgMDAwMjQg
KHYwMiBBTEFTS0EpClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA2ZWRiYzA3MCAw
MDA1QyAodjAxIEFMQVNLQSAgICBBIE0gSSAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBGQUNQIDAwMDAwMDAwNmVkYzQxNTggMDAwRjQgKHYwNCBBTEFTS0EgICAg
QSBNIEkgMDEwNzIwMDkgQU1JICAwMDAxMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAw
MDAwMDAwMDZlZGJjMTU4IDA3RkZCICh2MDIgQUxBU0tBICAgIEEgTSBJIDAwMDAwMDAwIElOVEwg
MjAwNTExMTcpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDA2ZWUwN2Y4MCAwMDA0
MApbICAgIDAuMDAwMDAwXSBBQ1BJOiBBUElDIDAwMDAwMDAwNmVkYzQyNTAgMDAwOTIgKHYwMyBB
TEFTS0EgICAgQSBNIEkgMDEwNzIwMDkgQU1JICAwMDAxMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQ
STogU1NEVCAwMDAwMDAwMDZlZGM0MmU4IDAwMUQ2ICh2MDEgQU1JQ1BVICAgICBQUk9DIDAwMDAw
MDAxIE1TRlQgMDMwMDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IE1DRkcgMDAwMDAwMDA2ZWRj
NDRjMCAwMDAzQyAodjAxIEFMQVNLQSAgICBBIE0gSSAwMTA3MjAwOSBNU0ZUIDAwMDAwMDk3KQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBBQUZUIDAwMDAwMDAwNmVkYzQ1MDAgMDAwRDMgKHYwMSBBTEFT
S0EgT0VNQUFGVCAgMDEwNzIwMDkgTVNGVCAwMDAwMDA5NykKWyAgICAwLjAwMDAwMF0gQUNQSTog
SFBFVCAwMDAwMDAwMDZlZGM0NWQ4IDAwMDM4ICh2MDEgQUxBU0tBICAgIEEgTSBJIDAxMDcyMDA5
IEFNSS4gMDAwMDAwMDQpClsgICAgMC4wMDAwMDBdIEFDUEk6IFhNQVIgMDAwMDAwMDA2ZWRjNDYx
MCAwMDBFOCAodjAxIEFMQVNLQSAgICBBIE0gSSAwMDAwMDAwMSBJTlRMIDAwMDAwMDAxKQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAw
MDAwXSBTZXR0aW5nIEFQSUMgcm91dGluZyB0byBjbHVzdGVyIHgyYXBpYy4KWyAgICAwLjAwMDAw
MF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5v
ZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMjAwMDAwMDAwClsgICAgMC4wMDAwMDBdIElu
aXRtZW0gc2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIwMDAwMDAwMApbICAg
IDAuMDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDFmZmZmYjAwMCAtIDAwMDAwMDAxZmZmZmZm
ZmZdClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAwMF0gICBETUEg
ICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAw
eDAwMDAxMDAwIC0+IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgICAweDAwMTAw
MDAwIC0+IDB4MDAyMDAwMDAKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IFBGTiBm
b3IgZWFjaCBub2RlClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzddIGFjdGl2ZSBQRk4g
cmFuZ2VzClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwOWQKWyAg
ICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApbICAgIDAuMDAwMDAw
XSAgICAgMDogMHgwMDAyMDIwMCAtPiAweDAwMDQwMDAwClsgICAgMC4wMDAwMDBdICAgICAwOiAw
eDAwMDQwMjAwIC0+IDB4MDAwNmVkNmQKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwNmVkZjIg
LT4gMHgwMDA2ZWRmMwpbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDA2ZWU3YiAtPiAweDAwMDZm
MDAwClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMTAwMDAwIC0+IDB4MDAyMDAwMDAKWyAgICAw
LjAwMDAwMF0gT24gbm9kZSAwIHRvdGFscGFnZXM6IDE1MDE4MjQKWyAgICAwLjAwMDAwMF0gICBE
TUEgem9uZTogNTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BIHpv
bmU6IDg1MiBwYWdlcyByZXNlcnZlZApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzMDczIHBh
Z2VzLCBMSUZPIGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAxNDI4MCBwYWdl
cyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MzQ5ODcgcGFn
ZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTogMTQzMzYgcGFn
ZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6IDEwMzQyNDAg
cGFnZXMsIExJRk8gYmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9y
dDogMHg0MDgKWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAw
MDAKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgw
MF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw
aWNfaWRbMHgwMl0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwM10gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKWyAgICAwLjAw
MDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkK
WyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwNV0g
ZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNf
aWRbMHgwN10gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk
WzB4ZmZdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAo
aWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKWyAgICAwLjAwMDAwMF0g
SU9BUElDWzBdOiBhcGljX2lkIDAsIHZlcnNpb24gMjU1LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdT
SSAwLTI1NQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAw
IGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdoIGxldmVsKQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNl
ZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRl
LgpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g
aW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNl
OiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDogQWxsb3dpbmcgOCBDUFVzLCAwIGhvdHBs
dWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogMjcyClsgICAgMC4wMDAwMDBdIFBN
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAw
MDllMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw
MDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl
cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwClsg
ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNDAwMDAw
MDAgLSAwMDAwMDAwMDQwMjAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IDAwMDAwMDAwNmVkNmQwMDAgLSAwMDAwMDAwMDZlZGJjMDAwClsgICAgMC4wMDAw
MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVkYmMwMDAgLSAwMDAw
MDAwMDZlZGM1MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IDAwMDAwMDAwNmVkYzUwMDAgLSAwMDAwMDAwMDZlZGYyMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVkZjMwMDAgLSAwMDAwMDAwMDZlZTAz
MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw
NmVlMDMwMDAgLSAwMDAwMDAwMDZlZTEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk
IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVlMTAwMDAgLSAwMDAwMDAwMDZlZTM4MDAwClsgICAg
MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmVlMzgwMDAg
LSAwMDAwMDAwMDZlZTdiMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IDAwMDAwMDAwNmYwMDAwMDAgLSAwMDAwMDAwMDZmODAwMDAwClsgICAgMC4wMDAwMDBd
IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwNmY4MDAwMDAgLSAwMDAwMDAw
MDdmYTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAw
MDAwMDAwN2ZhMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAw
ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVj
MDEwMDAgLSAwMDAwMDAwMGZlZDFjMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwClsgICAgMC4w
MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkNDAwMDAgLSAw
MDAwMDAwMGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwClsgICAgMC4wMDAwMDBdIFBN
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDEwMDAgLSAwMDAwMDAwMGZm
MDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw
MDAwZmYwMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcg
UENJIHJlc291cmNlcyBzdGFydGluZyBhdCA3ZmEwMDAwMCAoZ2FwOiA3ZmEwMDAwMDo3ZjIwMDAw
MCkKWyAgICAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpb
ICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4xLjIgKHByZXNlcnZlLUFEKQpbICAgIDAuMDAw
MDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6NTEyIG5yX2NwdW1hc2tfYml0czo1MTIgbnJfY3B1
X2lkczo4IG5yX25vZGVfaWRzOjEKWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAyOCBw
YWdlcy9jcHUgQGZmZmY4ODAxZmZlY2EwMDAgczgyMzA0IHI4MTkyIGQyNDE5MiB1MTE0Njg4Clsg
ICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IHM4MjMwNCByODE5MiBkMjQxOTIgdTExNDY4OCBhbGxv
Yz0yOCo0MDk2ClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIFswXSAxIFswXSAyIFsw
XSAzIFswXSA0IFswXSA1IFswXSA2IFswXSA3IApbICAgIDQuMDQwMjc4XSBCdWlsdCAxIHpvbmVs
aXN0cyBpbiBab25lIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAx
NDcyMzAwClsgICAgNC4wNDAyNzldIFBvbGljeSB6b25lOiBOb3JtYWwKWyAgICA0LjA0MDI4MV0g
S2VybmVsIGNvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgcm9vdD0vZGV2L21hcHBlci9tdWFkZGli
LXJvb3Qgcm8gcmRibGFja2xpc3Q9cmFkZW9uIHJhZGVvbi5tb2RzZXQ9MCBtZW09ODE5Mk0KWyAg
ICA0LjA0MDMzMV0gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4
IGJ5dGVzKQpbICAgIDQuMDU3MTkxXSBQbGFjaW5nIDY0TUIgc29mdHdhcmUgSU8gVExCIGJldHdl
ZW4gZmZmZjg4MDFmNWEwMDAwMCAtIGZmZmY4ODAxZjlhMDAwMDAKWyAgICA0LjA1NzE5M10gc29m
dHdhcmUgSU8gVExCIGF0IHBoeXMgMHgxZjVhMDAwMDAgLSAweDFmOWEwMDAwMApbICAgIDQuMDcz
MTExXSBNZW1vcnk6IDU3ODcyMjhrLzgzODg2MDhrIGF2YWlsYWJsZSAoMzM2OGsga2VybmVsIGNv
ZGUsIDIzODEzMTJrIGFic2VudCwgMjIwMDY4ayByZXNlcnZlZCwgMzM2MWsgZGF0YSwgNTY4ayBp
bml0KQpbICAgIDQuMDczMTc1XSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLgpbICAg
IDQuMDczMTc2XSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlz
IGVuYWJsZWQuClsgICAgNC4wNzMxODNdIE5SX0lSUVM6MzMwMjQgbnJfaXJxczoyMDQ4IDE2Clsg
ICAgNC4wNzMyMzRdIHhlbjogc2NpIG92ZXJyaWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBv
bGFyaXR5PTAKWyAgICA0LjA3MzIzN10geGVuOiByZWdpc3RlcmluZyBnc2kgOSB0cmlnZ2VyaW5n
IDAgcG9sYXJpdHkgMApbICAgIDQuMDczMjQzXSB4ZW46IC0tPiBwaXJxPTkgLT4gaXJxPTkgKGdz
aT05KQpbICAgIDQuMDczMjYyXSB4ZW46IGFjcGkgc2NpIDkKWyAgICA0LjA3MzI2NF0geGVuOiAt
LT4gcGlycT0xIC0+IGlycT0xIChnc2k9MSkKWyAgICA0LjA3MzI2N10geGVuOiAtLT4gcGlycT0y
IC0+IGlycT0yIChnc2k9MikKWyAgICA0LjA3MzI2OV0geGVuOiAtLT4gcGlycT0zIC0+IGlycT0z
IChnc2k9MykKWyAgICA0LjA3MzI3MV0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkK
WyAgICA0LjA3MzI3NF0geGVuOiAtLT4gcGlycT01IC0+IGlycT01IChnc2k9NSkKWyAgICA0LjA3
MzI3Nl0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikKWyAgICA0LjA3MzI3OF0geGVu
OiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykKWyAgICA0LjA3MzI4MV0geGVuOiAtLT4gcGly
cT04IC0+IGlycT04IChnc2k9OCkKWyAgICA0LjA3MzI4Ml0geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSA5IGZvciBnc2kgOQpbICAgIDQuMDczMjg0XSB4ZW46IC0tPiBwaXJxPTkgLT4g
aXJxPTkgKGdzaT05KQpbICAgIDQuMDczMjg2XSB4ZW46IC0tPiBwaXJxPTEwIC0+IGlycT0xMCAo
Z3NpPTEwKQpbICAgIDQuMDczMjg4XSB4ZW46IC0tPiBwaXJxPTExIC0+IGlycT0xMSAoZ3NpPTEx
KQpbICAgIDQuMDczMjkxXSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0xMiAoZ3NpPTEyKQpbICAg
IDQuMDczMjkzXSB4ZW46IC0tPiBwaXJxPTEzIC0+IGlycT0xMyAoZ3NpPTEzKQpbICAgIDQuMDcz
Mjk1XSB4ZW46IC0tPiBwaXJxPTE0IC0+IGlycT0xNCAoZ3NpPTE0KQpbICAgIDQuMDczMjk4XSB4
ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAoZ3NpPTE1KQpbICAgIDQuMDc1MDYxXSBDb25zb2xl
OiBjb2xvdXIgVkdBKyA4MHgyNQpbICAgIDQuMDc5ODA3XSBjb25zb2xlIFt0dHkwXSBlbmFibGVk
ClsgICAgNC4wNzk4NThdIFhlbjogdXNpbmcgdmNwdW9wIHRpbWVyIGludGVyZmFjZQpbICAgIDQu
MDc5ODYxXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDAKWyAgICA0LjA3OTkwNF0gRGV0
ZWN0ZWQgMzM5Mi4zNzYgTUh6IHByb2Nlc3Nvci4KWyAgICA0LjA3OTkzOF0gQ2FsaWJyYXRpbmcg
ZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVl
bmN5Li4gNjc4NC43NSBCb2dvTUlQUyAobHBqPTEzNTY5NTA0KQpbICAgIDQuMDgwMDAxXSBwaWRf
bWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEKWyAgICA0LjA4MDA2NV0gU2VjdXJpdHkg
RnJhbWV3b3JrIGluaXRpYWxpemVkClsgICAgNC4wODAwOTZdIEFwcEFybW9yOiBBcHBBcm1vciBk
aXNhYmxlZCBieSBib290IHRpbWUgcGFyYW1ldGVyClsgICAgNC4wODE3NDBdIERlbnRyeSBjYWNo
ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEwNDg1NzYgKG9yZGVyOiAxMSwgODM4ODYwOCBieXRlcykK
WyAgICA0LjA4MzczOV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MjQyODggKG9y
ZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKWyAgICA0LjA4NDM3OV0gTW91bnQtY2FjaGUgaGFzaCB0
YWJsZSBlbnRyaWVzOiAyNTYKWyAgICA0LjA4NDUwNV0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJz
eXMgY3B1YWNjdApbICAgIDQuMDg0NTM3XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1v
cnkKWyAgICA0LjA4NDU3N10gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcwpbICAg
IDQuMDg0NjA3XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyClsgICAgNC4wODQ2
MzhdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKWyAgICA0LjA4NDY2OV0gSW5p
dGlhbGl6aW5nIGNncm91cCBzdWJzeXMgYmxraW8KWyAgICA0LjA4NDc0OV0gRU5FUkdZX1BFUkZf
QklBUzogU2V0IHRvICdub3JtYWwnLCB3YXMgJ3BlcmZvcm1hbmNlJwpbICAgIDQuMDg0NzQ5XSBF
TkVSR1lfUEVSRl9CSUFTOiBWaWV3IGFuZCB1cGRhdGUgd2l0aCB4ODZfZW5lcmd5X3BlcmZfcG9s
aWN5KDgpClsgICAgNC4wODQ4MTddIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwClsgICAg
NC4wODQ4NDZdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDAKWyAgICA0LjA4NTMwNF0gQUNQSTog
Q29yZSByZXZpc2lvbiAyMDExMDYyMwpbICAgIDQuMDk1MjA4XSBQZXJmb3JtYW5jZSBFdmVudHM6
IHVuc3VwcG9ydGVkIHA2IENQVSBtb2RlbCA0MiBubyBQTVUgZHJpdmVyLCBzb2Z0d2FyZSBldmVu
dHMgb25seS4KWyAgICA0LjA5NTM3MV0gTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUwKTogaGFy
ZHdhcmUgZXZlbnRzIG5vdCBlbmFibGVkClsgICAgNC4wOTU0ODldIGluc3RhbGxpbmcgWGVuIHRp
bWVyIGZvciBDUFUgMQpbICAgIDQuMDk1NjI2XSBOTUkgd2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTEp
OiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJsZWQKWyAgICA0LjA5NTY3OF0gQnJvdWdodCB1cCAy
IENQVXMKWyAgICA0LjA5NTg5N10gZGV2dG1wZnM6IGluaXRpYWxpemVkClsgICAgNC4wOTgwNzhd
IFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24gYXQgNmVkNmQwMDAgKDMyMzU4NCBieXRl
cykKWyAgICA0LjA5ODEyOF0gUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBhdCA2ZWUw
MzAwMCAoNTMyNDggYnl0ZXMpClsgICAgNC4wOTk0NjBdIFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5W
UyByZWdpb24gYXQgNmVlMzgwMDAgKDI3NDQzMiBieXRlcykKWyAgICA0LjA5OTU3OF0gR3JhbnQg
dGFibGUgaW5pdGlhbGl6ZWQKWyAgICA0LjA5OTY2MF0gcHJpbnRfY29uc3RyYWludHM6IGR1bW15
OiAKWyAgICA0LjA5OTc0MF0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpbICAg
IDQuMDk5OTI2XSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApbICAgIDQuMTAwMDE4XSBQ
Q0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4ZTAwMDAw
MDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkKWyAgICA0LjEwMDA2N10gUENJOiBub3Qg
dXNpbmcgTU1DT05GSUcKWyAgICA0LjEwMDA5N10gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5
cGUgMSBmb3IgYmFzZSBhY2Nlc3MKWyAgICA0LjEwMDc0OV0gYmlvOiBjcmVhdGUgc2xhYiA8Ymlv
LTA+IGF0IDAKWyAgICA0LjEwMDg4N10gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQpb
ICAgIDQuMTAwOTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpClsgICAgNC4x
MDA5NTBdIEFDUEk6IEFkZGVkIF9PU0koMy4wIF9TQ1AgRXh0ZW5zaW9ucykKWyAgICA0LjEwMDk4
MV0gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpClsgICAgNC4x
MDI3MDhdIEFDUEk6IEVDOiBMb29rIHVwIEVDIGluIERTRFQKWyAgICA0LjEwNDU0N10gQUNQSTog
RXhlY3V0ZWQgMSBibG9ja3Mgb2YgbW9kdWxlLWxldmVsIGV4ZWN1dGFibGUgQU1MIGNvZGUKWyAg
ICA0LjExMTgxOV0gQUNQSTogU1NEVCAwMDAwMDAwMDZlZTBmODk4IDAwNkY0ICh2MDEgICAgQU1J
ICAgICAgSVNUIDAwMDAwMDAxIE1TRlQgMDMwMDAwMDEpClsgICAgNC4xMTI1MThdIEFDUEk6IER5
bmFtaWMgT0VNIFRhYmxlIExvYWQ6ClsgICAgNC4xMTI1NzJdIEFDUEk6IFNTRFQgICAgICAgICAg
IChudWxsKSAwMDZGNCAodjAxICAgIEFNSSAgICAgIElTVCAwMDAwMDAwMSBNU0ZUIDAzMDAwMDAx
KQpbICAgIDQuMTEyNzA4XSBBQ1BJOiBTU0RUIDAwMDAwMDAwNmVlMDZkOTggMDAwRTQgKHYwMSAg
ICBBTUkgICAgICBDU1QgMDAwMDAwMDEgTVNGVCAwMzAwMDAwMSkKWyAgICA0LjExMzIzMV0gQUNQ
STogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAgICA0LjExMzI4NV0gQUNQSTogU1NEVCAgICAg
ICAgICAgKG51bGwpIDAwMEU0ICh2MDEgICAgQU1JICAgICAgQ1NUIDAwMDAwMDAxIE1TRlQgMDMw
MDAwMDEpClsgICAgNC4xMTM4MzJdIEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQKWyAgICA0LjEx
Mzg2M10gQUNQSTogKHN1cHBvcnRzIFMwIFMxIFMzIFM0IFM1KQpbICAgIDQuMTEzOTc1XSBBQ1BJ
OiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nClsgICAgNC4xMTQwMzRdIFBDSTog
TU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0w
eGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQpbICAgIDQuMTE0MTg3XSBQQ0k6IE1NQ09ORklH
IGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZlZCBpbiBBQ1BJIG1vdGhlcmJv
YXJkIHJlc291cmNlcwpbICAgIDQuMTY2ODUxXSBbRmlybXdhcmUgQnVnXTogQUNQSTogQklPUyBf
T1NJKExpbnV4KSBxdWVyeSBpZ25vcmVkClsgICAgNC4xNzQwNjVdIEFDUEk6IE5vIGRvY2sgZGV2
aWNlcyBmb3VuZC4KWyAgICA0LjE3NDA5Nl0gSEVTVDogVGFibGUgbm90IGZvdW5kLgpbICAgIDQu
MTc0MTI2XSBQQ0k6IFVzaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBpZiBuZWNl
c3NhcnksIHVzZSAicGNpPW5vY3JzIiBhbmQgcmVwb3J0IGEgYnVnClsgICAgNC4xNzQ2MDRdIEFD
UEk6IFBDSSBSb290IEJyaWRnZSBbUENJMF0gKGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdKQpbICAg
IDQuMTc1MDYzXSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAw
eDAwMDAtMHgwM2FmXQpbICAgIDQuMTc1MDk4XSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJy
aWRnZSB3aW5kb3cgW2lvICAweDAzZTAtMHgwY2Y3XQpbICAgIDQuMTc1MTMyXSBwY2lfcm9vdCBQ
TlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDAzYjAtMHgwM2RmXQpbICAgIDQu
MTc1MTY2XSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDBk
MDAtMHhmZmZmXQpbICAgIDQuMTc1MjAwXSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRn
ZSB3aW5kb3cgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgNC4xNzUyNDVdIHBjaV9y
b290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwYzAwMDAtMHgwMDBk
ZmZmZl0KWyAgICA0LjE3NTI5MV0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2lu
ZG93IFttZW0gMHg3ZmEwMDAwMC0weGZmZmZmZmZmXQpbICAgIDQuMTc1MzUxXSBwY2kgMDAwMDow
MDowMC4wOiBbODA4NjowMTAwXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDAKWyAgICA0LjE3NTQyOV0g
cGNpIDAwMDA6MDA6MDEuMDogWzgwODY6MDEwMV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAg
NC4xNzU1MDZdIHBjaSAwMDAwOjAwOjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkClsgICAgNC4xNzU1MDldIHBjaSAwMDAwOjAwOjAxLjA6IFBNRSMgZGlzYWJsZWQKWyAg
ICA0LjE3NTU0OF0gcGNpIDAwMDA6MDA6MDIuMDogWzgwODY6MDEwMl0gdHlwZSAwIGNsYXNzIDB4
MDAwMzAwClsgICAgNC4xNzU1NzFdIHBjaSAwMDAwOjAwOjAyLjA6IHJlZyAxMDogW21lbSAweGZi
NDAwMDAwLTB4ZmI3ZmZmZmYgNjRiaXRdClsgICAgNC4xNzU1ODNdIHBjaSAwMDAwOjAwOjAyLjA6
IHJlZyAxODogW21lbSAweGIwMDAwMDAwLTB4YmZmZmZmZmYgNjRiaXQgcHJlZl0KWyAgICA0LjE3
NTU5Ml0gcGNpIDAwMDA6MDA6MDIuMDogcmVnIDIwOiBbaW8gIDB4ZjAwMC0weGYwM2ZdClsgICAg
NC4xNzU3MTNdIHBjaSAwMDAwOjAwOjE2LjA6IFs4MDg2OjFjM2FdIHR5cGUgMCBjbGFzcyAweDAw
MDc4MApbICAgIDQuMTc1NzU3XSBwY2kgMDAwMDowMDoxNi4wOiByZWcgMTA6IFttZW0gMHhmYmYw
NDAwMC0weGZiZjA0MDBmIDY0Yml0XQpbICAgIDQuMTc1OTA4XSBwY2kgMDAwMDowMDoxNi4wOiBQ
TUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc1OTEzXSBwY2kgMDAw
MDowMDoxNi4wOiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzU5NzZdIHBjaSAwMDAwOjAwOjFhLjA6
IFs4MDg2OjFjMmRdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDQuMTc2MDE1XSBwY2kgMDAw
MDowMDoxYS4wOiByZWcgMTA6IFttZW0gMHhmYmYwMzAwMC0weGZiZjAzM2ZmXQpbICAgIDQuMTc2
MTk3XSBwY2kgMDAwMDowMDoxYS4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29s
ZApbICAgIDQuMTc2MjAzXSBwY2kgMDAwMDowMDoxYS4wOiBQTUUjIGRpc2FibGVkClsgICAgNC4x
NzYyNDRdIHBjaSAwMDAwOjAwOjFjLjA6IFs4MDg2OjFjMTBdIHR5cGUgMSBjbGFzcyAweDAwMDYw
NApbICAgIDQuMTc2NDA5XSBwY2kgMDAwMDowMDoxYy4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQzaG90IEQzY29sZApbICAgIDQuMTc2NDE1XSBwY2kgMDAwMDowMDoxYy4wOiBQTUUjIGRpc2Fi
bGVkClsgICAgNC4xNzY0NjZdIHBjaSAwMDAwOjAwOjFjLjQ6IFs4MDg2OjFjMThdIHR5cGUgMSBj
bGFzcyAweDAwMDYwNApbICAgIDQuMTc2NjMyXSBwY2kgMDAwMDowMDoxYy40OiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc2NjM4XSBwY2kgMDAwMDowMDoxYy40
OiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzY2ODVdIHBjaSAwMDAwOjAwOjFjLjU6IFs4MDg2OjFj
MWFdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDQuMTc2ODQ5XSBwY2kgMDAwMDowMDoxYy41
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc2ODU1XSBwY2kg
MDAwMDowMDoxYy41OiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzY5MDBdIHBjaSAwMDAwOjAwOjFj
LjY6IFs4MDg2OjFjMWNdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDQuMTc3MDY0XSBwY2kg
MDAwMDowMDoxYy42OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQu
MTc3MDcwXSBwY2kgMDAwMDowMDoxYy42OiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzcxMTZdIHBj
aSAwMDAwOjAwOjFjLjc6IFs4MDg2OjFjMWVdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAgIDQu
MTc3MjgyXSBwY2kgMDAwMDowMDoxYy43OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQz
Y29sZApbICAgIDQuMTc3Mjg4XSBwY2kgMDAwMDowMDoxYy43OiBQTUUjIGRpc2FibGVkClsgICAg
NC4xNzczNDBdIHBjaSAwMDAwOjAwOjFkLjA6IFs4MDg2OjFjMjZdIHR5cGUgMCBjbGFzcyAweDAw
MGMwMwpbICAgIDQuMTc3MzgwXSBwY2kgMDAwMDowMDoxZC4wOiByZWcgMTA6IFttZW0gMHhmYmYw
MjAwMC0weGZiZjAyM2ZmXQpbICAgIDQuMTc3NTYxXSBwY2kgMDAwMDowMDoxZC4wOiBQTUUjIHN1
cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDQuMTc3NTY4XSBwY2kgMDAwMDowMDox
ZC4wOiBQTUUjIGRpc2FibGVkClsgICAgNC4xNzc2MDhdIHBjaSAwMDAwOjAwOjFmLjA6IFs4MDg2
OjFjNDRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMQpbICAgIDQuMTc3ODQwXSBwY2kgMDAwMDowMDox
Zi4yOiBbODA4NjoxYzAyXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDYKWyAgICA0LjE3Nzg4MV0gcGNp
IDAwMDA6MDA6MWYuMjogcmVnIDEwOiBbaW8gIDB4ZjBiMC0weGYwYjddClsgICAgNC4xNzc4OTdd
IHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxNDogW2lvICAweGYwYTAtMHhmMGEzXQpbICAgIDQuMTc3
OTEyXSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTg6IFtpbyAgMHhmMDkwLTB4ZjA5N10KWyAgICA0
LjE3NzkyOF0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDFjOiBbaW8gIDB4ZjA4MC0weGYwODNdClsg
ICAgNC4xNzc5NDNdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAyMDogW2lvICAweGYwNjAtMHhmMDdm
XQpbICAgIDQuMTc3OTU5XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMjQ6IFttZW0gMHhmYmYwMTAw
MC0weGZiZjAxN2ZmXQpbICAgIDQuMTc4MDYyXSBwY2kgMDAwMDowMDoxZi4yOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQzaG90ClsgICAgNC4xNzgwNjddIHBjaSAwMDAwOjAwOjFmLjI6IFBNRSMgZGlz
YWJsZWQKWyAgICA0LjE3ODA5OV0gcGNpIDAwMDA6MDA6MWYuMzogWzgwODY6MWMyMl0gdHlwZSAw
IGNsYXNzIDB4MDAwYzA1ClsgICAgNC4xNzgxMzBdIHBjaSAwMDAwOjAwOjFmLjM6IHJlZyAxMDog
W21lbSAweGZiZjAwMDAwLTB4ZmJmMDAwZmYgNjRiaXRdClsgICAgNC4xNzgxNzVdIHBjaSAwMDAw
OjAwOjFmLjM6IHJlZyAyMDogW2lvICAweGYwNDAtMHhmMDVmXQpbICAgIDQuMTc4MjkyXSBwY2kg
MDAwMDowMTowMC4wOiBbMTAwMjo2NzE5XSB0eXBlIDAgY2xhc3MgMHgwMDAzMDAKWyAgICA0LjE3
ODMxNF0gcGNpIDAwMDA6MDE6MDAuMDogcmVnIDEwOiBbbWVtIDB4YzAwMDAwMDAtMHhjZmZmZmZm
ZiA2NGJpdCBwcmVmXQpbICAgIDQuMTc4MzMxXSBwY2kgMDAwMDowMTowMC4wOiByZWcgMTg6IFtt
ZW0gMHhmYmUyMDAwMC0weGZiZTNmZmZmIDY0Yml0XQpbICAgIDQuMTc4MzQzXSBwY2kgMDAwMDow
MTowMC4wOiByZWcgMjA6IFtpbyAgMHhlMDAwLTB4ZTBmZl0KWyAgICA0LjE3ODM2NV0gcGNpIDAw
MDA6MDE6MDAuMDogcmVnIDMwOiBbbWVtIDB4ZmJlMDAwMDAtMHhmYmUxZmZmZiBwcmVmXQpbICAg
IDQuMTc4NDIxXSBwY2kgMDAwMDowMTowMC4wOiBzdXBwb3J0cyBEMSBEMgpbICAgIDQuMTc4NDU1
XSBwY2kgMDAwMDowMTowMC4xOiBbMTAwMjphYTgwXSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMKWyAg
ICA0LjE3ODQ3Nl0gcGNpIDAwMDA6MDE6MDAuMTogcmVnIDEwOiBbbWVtIDB4ZmJlNDAwMDAtMHhm
YmU0M2ZmZiA2NGJpdF0KWyAgICA0LjE3ODU4M10gcGNpIDAwMDA6MDE6MDAuMTogc3VwcG9ydHMg
RDEgRDIKWyAgICA0LjE4NTM5MV0gcGNpIDAwMDA6MDA6MDEuMDogUENJIGJyaWRnZSB0byBbYnVz
IDAxLTAxXQpbICAgIDQuMTg1NDQ1XSBwY2kgMDAwMDowMDowMS4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweGUwMDAtMHhlZmZmXQpbICAgIDQuMTg1NDQ5XSBwY2kgMDAwMDowMDowMS4wOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGZiZTAwMDAwLTB4ZmJlZmZmZmZdClsgICAgNC4xODU0NTVdIHBj
aSAwMDAwOjAwOjAxLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4YzAwMDAwMDAtMHhjZmZmZmZm
ZiA2NGJpdCBwcmVmXQpbICAgIDQuMTg1NTgxXSBwY2kgMDAwMDowMjowMC4wOiBbMTBiNTo4MTEy
XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE4NTgzMV0gcGNpIDAwMDA6MDI6MDAuMDog
ZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEuMSBQQ0llIGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0
IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScKWyAgICA0LjE4NTg5N10gcGNpIDAwMDA6MDA6MWMuMDog
UENJIGJyaWRnZSB0byBbYnVzIDAyLTAzXQpbICAgIDQuMTg1OTMzXSBwY2kgMDAwMDowMDoxYy4w
OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDQuMTg2MDkzXSBwY2kg
MDAwMDowMzowNC4wOiBbMTNmNjo4Nzg4XSB0eXBlIDAgY2xhc3MgMHgwMDA0MDEKWyAgICA0LjE4
NjE0NF0gcGNpIDAwMDA6MDM6MDQuMDogcmVnIDEwOiBbaW8gIDB4ZDAwMC0weGQwZmZdClsgICAg
NC4xODYzODldIHBjaSAwMDAwOjAzOjA0LjA6IHN1cHBvcnRzIEQxIEQyClsgICAgNC4xODY1MDZd
IHBjaSAwMDAwOjAyOjAwLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMy0wM10KWyAgICA0LjE4NjU0
NV0gcGNpIDAwMDA6MDI6MDAuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0K
WyAgICA0LjE4NjcwMF0gcGNpIDAwMDA6MDQ6MDAuMDogWzFiNGI6OTEyMF0gdHlwZSAwIGNsYXNz
IDB4MDAwMTA2ClsgICAgNC4xODY3MjhdIHBjaSAwMDAwOjA0OjAwLjA6IHJlZyAxMDogW2lvICAw
eGMwNDAtMHhjMDQ3XQpbICAgIDQuMTg2NzQ4XSBwY2kgMDAwMDowNDowMC4wOiByZWcgMTQ6IFtp
byAgMHhjMDMwLTB4YzAzM10KWyAgICA0LjE4Njc2OF0gcGNpIDAwMDA6MDQ6MDAuMDogcmVnIDE4
OiBbaW8gIDB4YzAyMC0weGMwMjddClsgICAgNC4xODY3ODldIHBjaSAwMDAwOjA0OjAwLjA6IHJl
ZyAxYzogW2lvICAweGMwMTAtMHhjMDEzXQpbICAgIDQuMTg2ODA5XSBwY2kgMDAwMDowNDowMC4w
OiByZWcgMjA6IFtpbyAgMHhjMDAwLTB4YzAwZl0KWyAgICA0LjE4NjgzMF0gcGNpIDAwMDA6MDQ6
MDAuMDogcmVnIDI0OiBbbWVtIDB4ZmJkMTAwMDAtMHhmYmQxMDdmZl0KWyAgICA0LjE4Njg1MV0g
cGNpIDAwMDA6MDQ6MDAuMDogcmVnIDMwOiBbbWVtIDB4ZmJkMDAwMDAtMHhmYmQwZmZmZiBwcmVm
XQpbICAgIDQuMTg2OTUwXSBwY2kgMDAwMDowNDowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQz
aG90ClsgICAgNC4xODY5NTddIHBjaSAwMDAwOjA0OjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA0
LjE4NzAyNF0gcGNpIDAwMDA6MDA6MWMuNDogUENJIGJyaWRnZSB0byBbYnVzIDA0LTA0XQpbICAg
IDQuMTg3MDYwXSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMwMDAt
MHhjZmZmXQpbICAgIDQuMTg3MDY2XSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cg
W21lbSAweGZiZDAwMDAwLTB4ZmJkZmZmZmZdClsgICAgNC4xODcxOThdIHBjaSAwMDAwOjA1OjAw
LjA6IFsxYjZmOjcwMjNdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDQuMTg3MjQwXSBwY2kg
MDAwMDowNTowMC4wOiByZWcgMTA6IFttZW0gMHhmYmMwMDAwMC0weGZiYzA3ZmZmIDY0Yml0XQpb
ICAgIDQuMTg3NDQ3XSBwY2kgMDAwMDowNTowMC4wOiBzdXBwb3J0cyBEMSBEMgpbICAgIDQuMTg3
NDQ5XSBwY2kgMDAwMDowNTowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90
IEQzY29sZApbICAgIDQuMTg3NDU2XSBwY2kgMDAwMDowNTowMC4wOiBQTUUjIGRpc2FibGVkClsg
ICAgNC4xODc1MzVdIHBjaSAwMDAwOjAwOjFjLjU6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNS0wNV0K
WyAgICA0LjE4NzU3Nl0gcGNpIDAwMDA6MDA6MWMuNTogICBicmlkZ2Ugd2luZG93IFttZW0gMHhm
YmMwMDAwMC0weGZiY2ZmZmZmXQpbICAgIDQuMTg3NzA5XSBwY2kgMDAwMDowNjowMC4wOiBbMWI2
Zjo3MDIzXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMKWyAgICA0LjE4Nzc1MF0gcGNpIDAwMDA6MDY6
MDAuMDogcmVnIDEwOiBbbWVtIDB4ZmJiMDAwMDAtMHhmYmIwN2ZmZiA2NGJpdF0KWyAgICA0LjE4
Nzk1Nl0gcGNpIDAwMDA6MDY6MDAuMDogc3VwcG9ydHMgRDEgRDIKWyAgICA0LjE4Nzk1OF0gcGNp
IDAwMDA6MDY6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQK
WyAgICA0LjE4Nzk2NV0gcGNpIDAwMDA6MDY6MDAuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTg4
MDQ0XSBwY2kgMDAwMDowMDoxYy42OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDZdClsgICAgNC4x
ODgwODRdIHBjaSAwMDAwOjAwOjFjLjY6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmJiMDAwMDAt
MHhmYmJmZmZmZl0KWyAgICA0LjE4ODIxNV0gcGNpIDAwMDA6MDc6MDAuMDogWzEwYjU6ODYwOF0g
dHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgNC4xODgyNDNdIHBjaSAwMDAwOjA3OjAwLjA6IHJl
ZyAxMDogW21lbSAweGZiYTAwMDAwLTB4ZmJhMWZmZmZdClsgICAgNC4xODg0MjJdIHBjaSAwMDAw
OjA3OjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkClsgICAgNC4xODg0
MjldIHBjaSAwMDAwOjA3OjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA0LjE4ODUyOV0gcGNpIDAw
MDA6MDA6MWMuNzogUENJIGJyaWRnZSB0byBbYnVzIDA3LTEwXQpbICAgIDQuMTg4NTY1XSBwY2kg
MDAwMDowMDoxYy43OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQpbICAgIDQu
MTg4NTcwXSBwY2kgMDAwMDowMDoxYy43OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZiODAwMDAw
LTB4ZmJhZmZmZmZdClsgICAgNC4xODg1ODFdIHBjaSAwMDAwOjAwOjFjLjc6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMTg4NzM4
XSBwY2kgMDAwMDowODowMS4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAg
ICA0LjE4ODk1MF0gcGNpIDAwMDA6MDg6MDEuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQKWyAgICA0LjE4ODk1N10gcGNpIDAwMDA6MDg6MDEuMDogUE1FIyBkaXNhYmxlZApb
ICAgIDQuMTg5MDU0XSBwY2kgMDAwMDowODowNC4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3Mg
MHgwMDA2MDQKWyAgICA0LjE4OTI2NF0gcGNpIDAwMDA6MDg6MDQuMDogUE1FIyBzdXBwb3J0ZWQg
ZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE4OTI3MV0gcGNpIDAwMDA6MDg6MDQuMDogUE1F
IyBkaXNhYmxlZApbICAgIDQuMTg5MzYzXSBwY2kgMDAwMDowODowNS4wOiBbMTBiNTo4NjA4XSB0
eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE4OTU3NF0gcGNpIDAwMDA6MDg6MDUuMDogUE1F
IyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE4OTU4MV0gcGNpIDAwMDA6
MDg6MDUuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTg5Njc4XSBwY2kgMDAwMDowODowNi4wOiBb
MTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE4OTg4N10gcGNpIDAwMDA6
MDg6MDYuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE4OTg5
NV0gcGNpIDAwMDA6MDg6MDYuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTg5OTk0XSBwY2kgMDAw
MDowODowNy4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA0LjE5MDIw
M10gcGNpIDAwMDA6MDg6MDcuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQK
WyAgICA0LjE5MDIxMF0gcGNpIDAwMDA6MDg6MDcuMDogUE1FIyBkaXNhYmxlZApbICAgIDQuMTkw
MzExXSBwY2kgMDAwMDowODowOC4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQK
WyAgICA0LjE5MDUyMF0gcGNpIDAwMDA6MDg6MDguMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE
M2hvdCBEM2NvbGQKWyAgICA0LjE5MDUyN10gcGNpIDAwMDA6MDg6MDguMDogUE1FIyBkaXNhYmxl
ZApbICAgIDQuMTkwNjMyXSBwY2kgMDAwMDowODowOS4wOiBbMTBiNTo4NjA4XSB0eXBlIDEgY2xh
c3MgMHgwMDA2MDQKWyAgICA0LjE5MDg0MV0gcGNpIDAwMDA6MDg6MDkuMDogUE1FIyBzdXBwb3J0
ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA0LjE5MDg0OV0gcGNpIDAwMDA6MDg6MDkuMDog
UE1FIyBkaXNhYmxlZApbICAgIDQuMTkwOTgyXSBwY2kgMDAwMDowNzowMC4wOiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDgtMTBdClsgICAgNC4xOTEwMjVdIHBjaSAwMDAwOjA3OjAwLjA6ICAgYnJpZGdl
IHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZdClsgICAgNC4xOTEwMzJdIHBjaSAwMDAwOjA3OjAw
LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmI4MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0LjE5
MTA0NV0gcGNpIDAwMDA6MDc6MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0w
eGQwMGZmZmZmIDY0Yml0IHByZWZdClsgICAgNC4xOTExNjddIHBjaSAwMDAwOjA4OjAxLjA6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwOS0wOV0KWyAgICA0LjE5MTM5M10gcGNpIDAwMDA6MGE6MDAuMDog
WzFiMjE6MTA4MF0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0ClsgICAgNC4xOTE2NTldIHBjaSAwMDAw
OjBhOjAwLjA6IHN1cHBvcnRzIEQxIEQyClsgICAgNC4xOTE2NjBdIHBjaSAwMDAwOjBhOjAwLjA6
IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QgRDNjb2xkClsgICAgNC4xOTE2Njld
IHBjaSAwMDAwOjBhOjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA0LjE5MTc2MF0gcGNpIDAwMDA6
MDg6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDBhLTBiXQpbICAgIDQuMTkyMDkzXSBwY2kgMDAw
MDowYTowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGItMGJdClsgICAgNC4xOTIzNDFdIHBjaSAw
MDAwOjBjOjAwLjA6IFsxMTA2OjM0MDNdIHR5cGUgMCBjbGFzcyAweDAwMGMwMApbICAgIDQuMTky
Mzg5XSBwY2kgMDAwMDowYzowMC4wOiByZWcgMTA6IFttZW0gMHhmYjkwMDAwMC0weGZiOTAwN2Zm
IDY0Yml0XQpbICAgIDQuMTkyNDE0XSBwY2kgMDAwMDowYzowMC4wOiByZWcgMTg6IFtpbyAgMHhi
MDAwLTB4YjBmZl0KWyAgICA0LjE5MjYzMF0gcGNpIDAwMDA6MGM6MDAuMDogc3VwcG9ydHMgRDIK
WyAgICA0LjE5MjYzMl0gcGNpIDAwMDA6MGM6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMiBE
M2hvdCBEM2NvbGQKWyAgICA0LjE5MjY0MF0gcGNpIDAwMDA6MGM6MDAuMDogUE1FIyBkaXNhYmxl
ZApbICAgIDQuMTkyNzM0XSBwY2kgMDAwMDowODowNS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGMt
MGNdClsgICAgNC4xOTI3NzZdIHBjaSAwMDAwOjA4OjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IDB4YjAwMC0weGJmZmZdClsgICAgNC4xOTI3ODNdIHBjaSAwMDAwOjA4OjA1LjA6ICAgYnJpZGdl
IHdpbmRvdyBbbWVtIDB4ZmI5MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0LjE5Mjk3MF0gcGNpIDAw
MDA6MGQ6MDAuMDogWzE0ZTQ6MTZiMV0gdHlwZSAwIGNsYXNzIDB4MDAwMjAwClsgICAgNC4xOTMw
MjBdIHBjaSAwMDAwOjBkOjAwLjA6IHJlZyAxMDogW21lbSAweGQwMDEwMDAwLTB4ZDAwMWZmZmYg
NjRiaXQgcHJlZl0KWyAgICA0LjE5MzA2MF0gcGNpIDAwMDA6MGQ6MDAuMDogcmVnIDE4OiBbbWVt
IDB4ZDAwMDAwMDAtMHhkMDAwZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMTkzMTM1XSBwY2kgMDAw
MDowZDowMC4wOiByZWcgMzA6IFttZW0gMHhmYjgwMDAwMC0weGZiODAwN2ZmIHByZWZdClsgICAg
NC4xOTMyODFdIHBjaSAwMDAwOjBkOjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkClsgICAgNC4xOTMyODldIHBjaSAwMDAwOjBkOjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAg
ICA0LjE5MzQxMF0gcGNpIDAwMDA6MDg6MDYuMDogUENJIGJyaWRnZSB0byBbYnVzIDBkLTBkXQpb
ICAgIDQuMTkzNDU4XSBwY2kgMDAwMDowODowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZi
ODAwMDAwLTB4ZmI4ZmZmZmZdClsgICAgNC4xOTM0NzFdIHBjaSAwMDAwOjA4OjA2LjA6ICAgYnJp
ZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQu
MTkzNTk1XSBwY2kgMDAwMDowODowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGUtMGVdClsgICAg
NC4xOTM3NzZdIHBjaSAwMDAwOjA4OjA4LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwZi0wZl0KWyAg
ICA0LjE5Mzk2Ml0gcGNpIDAwMDA6MDg6MDkuMDogUENJIGJyaWRnZSB0byBbYnVzIDEwLTEwXQpb
ICAgIDQuMTk0MTY5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBD
STAuX1BSVF0KWyAgICA0LjE5NDM1Ml0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxl
IFtcX1NCXy5QQ0kwLlBFWDAuX1BSVF0KWyAgICA0LjE5NDQwNF0gQUNQSTogUENJIEludGVycnVw
dCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDQuX1BSVF0KWyAgICA0LjE5NDQ0N10gQUNQ
STogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDUuX1BSVF0KWyAg
ICA0LjE5NDQ5MF0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw
LlBFWDYuX1BSVF0KWyAgICA0LjE5NDUzM10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRh
YmxlIFtcX1NCXy5QQ0kwLlBFWDcuX1BSVF0KWyAgICA0LjE5NDU3OV0gQUNQSTogUENJIEludGVy
cnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDcuQlIyMS5fUFJUXQpbICAgIDQuMTk0
NzY5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVYNy5C
UjIxLkJSMzEuX1BSVF0KWyAgICA0LjE5NDgxOF0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5n
IFRhYmxlIFtcX1NCXy5QQ0kwLlBFWDcuQlIyMS5CUjM0Ll9QUlRdClsgICAgNC4xOTQ4NjhdIEFD
UEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QRVg3LkJSMjEuQlIz
NC5CUjIyLl9QUlRdClsgICAgNC4xOTQ5NDBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU
YWJsZSBbXF9TQl8uUENJMC5QRVg3LkJSMjEuQlIzNS5fUFJUXQpbICAgIDQuMTk0OTg4XSBBQ1BJ
OiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVYNy5CUjIxLkJSMzYu
X1BSVF0KWyAgICA0LjE5NTAzNl0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtc
X1NCXy5QQ0kwLlBFWDcuQlIyMS5CUjM3Ll9QUlRdClsgICAgNC4xOTUwODRdIEFDUEk6IFBDSSBJ
bnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QRVg3LkJSMjEuQlIzOC5fUFJUXQpb
ICAgIDQuMTk1MTMyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBD
STAuUEVYNy5CUjIxLkJSMzkuX1BSVF0KWyAgICA0LjE5NTE3NV0gQUNQSTogUENJIEludGVycnVw
dCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlAwUDEuX1BSVF0KWyAgICA0LjE5NTM2OV0gIHBj
aTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpClsgICAgNC4xOTU3
OTRdICBwY2kwMDAwOjAwOiBBQ1BJIF9PU0MgY29udHJvbCAoMHgxYykgZ3JhbnRlZApbICAgIDQu
MjAyNjkwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDMgNCA1IDYgNyAx
MCAqMTEgMTIgMTQgMTUpClsgICAgNC4yMDI5MjZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb
TE5LQl0gKElSUXMgMyA0IDUgNiA3ICoxMCAxMSAxMiAxNCAxNSkKWyAgICA0LjIwMzE1OF0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAzIDQgKjUgNiAxMCAxMSAxMiAxNCAx
NSkKWyAgICA0LjIwMzM3Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAq
MyA0IDUgNiAxMCAxMSAxMiAxNCAxNSkKWyAgICA0LjIwMzU5NV0gQUNQSTogUENJIEludGVycnVw
dCBMaW5rIFtMTktFXSAoSVJRcyAzIDQgNSA2IDcgMTAgMTEgMTIgMTQgMTUpICowClsgICAgNC4y
MDM4NDhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRl0gKElSUXMgMyA0IDUgNiA3IDEw
IDExIDEyIDE0IDE1KSAqMApbICAgIDQuMjA0MTAyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg
W0xOS0ddIChJUlFzIDMgNCA1IDYgNyAxMCAxMSAxMiAxNCAxNSkgKjAKWyAgICA0LjIwNDM1NV0g
QUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktIXSAoSVJRcyAzIDQgNSA2ICo3IDEwIDExIDEy
IDE0IDE1KQpbICAgIDQuMjA0NTY0XSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDQuMjA0NjExXSB4ZW4tYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDQuMjA0NzA2XSB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDA6
MDIuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lClsgICAgNC4yMDQ3NjJd
IHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6MDAwMDowMTowMC4wLGRlY29kZXM9aW8rbWVtLG93
bnM9bm9uZSxsb2Nrcz1ub25lClsgICAgNC4yMDQ4MTVdIHZnYWFyYjogbG9hZGVkClsgICAgNC4y
MDQ4NDJdIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMTowMC4wClsgICAg
NC4yMDQ4NzNdIHZnYWFyYjogbm8gYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowMDowMi4w
ClsgICAgNC4yMDQ5MzVdIFBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcKWyAgICA0LjIx
OTQ5MF0gUENJOiBwY2lfY2FjaGVfbGluZV9zaXplIHNldCB0byA2NCBieXRlcwpbICAgIDQuMjE5
Njc0XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAwMDlm
ZmZmIApbICAgIDQuMjE5Njc2XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwNmVkNmQwMDAg
LSAwMDAwMDAwMDZmZmZmZmZmIApbICAgIDQuMjE5NjgwXSByZXNlcnZlIFJBTSBidWZmZXI6IDAw
MDAwMDAwNmVkZjMwMDAgLSAwMDAwMDAwMDZmZmZmZmZmIApbICAgIDQuMjE5NjgzXSByZXNlcnZl
IFJBTSBidWZmZXI6IDAwMDAwMDAwNmYwMDAwMDAgLSAwMDAwMDAwMDZmZmZmZmZmIApbICAgIDQu
MjE5Nzg0XSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3VyY2UgeGVuClsgICAgNC4yMjEzNDRdIHBucDog
UG5QIEFDUEkgaW5pdApbICAgIDQuMjIxMzgyXSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJl
ZApbICAgIDQuMjIxNjI5XSBwbnAgMDA6MDA6IFtidXMgMDAtZmZdClsgICAgNC4yMjE2MzFdIHBu
cCAwMDowMDogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDQuMjIxNjMzXSBwbnAgMDA6MDA6IFtp
byAgMHgwMDAwLTB4MDNhZiB3aW5kb3ddClsgICAgNC4yMjE2MzVdIHBucCAwMDowMDogW2lvICAw
eDAzZTAtMHgwY2Y3IHdpbmRvd10KWyAgICA0LjIyMTYzNl0gcG5wIDAwOjAwOiBbaW8gIDB4MDNi
MC0weDAzZGYgd2luZG93XQpbICAgIDQuMjIxNjM4XSBwbnAgMDA6MDA6IFtpbyAgMHgwZDAwLTB4
ZmZmZiB3aW5kb3ddClsgICAgNC4yMjE2NDBdIHBucCAwMDowMDogW21lbSAweDAwMGEwMDAwLTB4
MDAwYmZmZmYgd2luZG93XQpbICAgIDQuMjIxNjQxXSBwbnAgMDA6MDA6IFttZW0gMHgwMDBjMDAw
MC0weDAwMGRmZmZmIHdpbmRvd10KWyAgICA0LjIyMTY0M10gcG5wIDAwOjAwOiBbbWVtIDB4N2Zh
MDAwMDAtMHhmZmZmZmZmZiB3aW5kb3ddClsgICAgNC4yMjE2NDVdIHBucCAwMDowMDogW21lbSAw
eDAwMDAwMDAwIHdpbmRvd10KWyAgICA0LjIyMTY4N10gcG5wIDAwOjAwOiBQbHVnIGFuZCBQbGF5
IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAzIChhY3RpdmUpClsgICAgNC4yMjE3ODZd
IHBucCAwMDowMTogW21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZdClsgICAgNC4yMjE3ODddIHBu
cCAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdClsgICAgNC4yMjE3ODldIHBucCAw
MDowMTogW21lbSAweGZlZDkwMDAwLTB4ZmVkOTNmZmZdClsgICAgNC4yMjE3OTFdIHBucCAwMDow
MTogW21lbSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdClsgICAgNC4yMjE3OTJdIHBucCAwMDowMTog
W21lbSAweGZlZTAwMDAwLTB4ZmVlMGZmZmZdClsgICAgNC4yMjE4MzNdIHN5c3RlbSAwMDowMTog
W21lbSAweGZlZDEwMDAwLTB4ZmVkMTlmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjE4
NjhdIHN5c3RlbSAwMDowMTogW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIGhhcyBiZWVuIHJl
c2VydmVkClsgICAgNC4yMjE5MDJdIHN5c3RlbSAwMDowMTogW21lbSAweGZlZDkwMDAwLTB4ZmVk
OTNmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjE5MzddIHN5c3RlbSAwMDowMTogW21l
bSAweGZlZDIwMDAwLTB4ZmVkM2ZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjE5NzFd
IHN5c3RlbSAwMDowMTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMGZmZmZdIGNvdWxkIG5vdCBiZSBy
ZXNlcnZlZApbICAgIDQuMjIyMDA2XSBzeXN0ZW0gMDA6MDE6IFBsdWcgYW5kIFBsYXkgQUNQSSBk
ZXZpY2UsIElEcyBQTlAwYzAxIChhY3RpdmUpClsgICAgNC4yMjIwOTBdIHBucCAwMDowMjogW2lv
ICAweDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZmIGRpc2FibGVkXQpbICAgIDQuMjIyMDkyXSBwbnAg
MDA6MDI6IFtpbyAgMHgwMjkwLTB4MDI5Zl0KWyAgICA0LjIyMjA5M10gcG5wIDAwOjAyOiBbaW8g
IDB4MDAwMC0weGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdClsgICAgNC4yMjIxMzFdIHN5c3Rl
bSAwMDowMjogW2lvICAweDAyOTAtMHgwMjlmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDQuMjIy
MTY1XSBzeXN0ZW0gMDA6MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAy
IChhY3RpdmUpClsgICAgNC4yMjI2NDVdIHBucCAwMDowMzogW2RtYSA0XQpbICAgIDQuMjIyNjQ3
XSBwbnAgMDA6MDM6IFtpbyAgMHgwMDAwLTB4MDAwZl0KWyAgICA0LjIyMjY0OV0gcG5wIDAwOjAz
OiBbaW8gIDB4MDA4MS0weDAwODNdClsgICAgNC4yMjI2NTFdIHBucCAwMDowMzogW2lvICAweDAw
ODddClsgICAgNC4yMjI2NTNdIHBucCAwMDowMzogW2lvICAweDAwODktMHgwMDhiXQpbICAgIDQu
MjIyNjU0XSBwbnAgMDA6MDM6IFtpbyAgMHgwMDhmXQpbICAgIDQuMjIyNjU1XSBwbnAgMDA6MDM6
IFtpbyAgMHgwMGMwLTB4MDBkZl0KWyAgICA0LjIyMjY3N10gcG5wIDAwOjAzOiBQbHVnIGFuZCBQ
bGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMDIwMCAoYWN0aXZlKQpbICAgIDQuMjIyNjg4XSBwbnAg
MDA6MDQ6IFtpbyAgMHgwMDcwLTB4MDA3MV0KWyAgICA0LjIyMjY5MF0geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgOCB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMApbICAgIDQuMjIyNjkzXSB4ZW5fbWFwX3Bp
cnFfZ3NpOiByZXR1cm5pbmcgaXJxIDggZm9yIGdzaSA4ClsgICAgNC4yMjI3MjVdIHhlbjogLS0+
IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgNC4yMjI3NDNdIHBucCAwMDowNDogW2lycSA4
XQpbICAgIDQuMjIyNzY0XSBwbnAgMDA6MDQ6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE
cyBQTlAwYjAwIChhY3RpdmUpClsgICAgNC4yMjI3NzNdIHBucCAwMDowNTogW2lvICAweDAwNjFd
ClsgICAgNC4yMjI3OTNdIHBucCAwMDowNTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDA4MDAgKGFjdGl2ZSkKWyAgICA0LjIyMjgxOV0gcG5wIDAwOjA2OiBbaW8gIDB4MDAxMC0w
eDAwMWZdClsgICAgNC4yMjI4MjFdIHBucCAwMDowNjogW2lvICAweDAwMjItMHgwMDNmXQpbICAg
IDQuMjIyODIyXSBwbnAgMDA6MDY6IFtpbyAgMHgwMDQ0LTB4MDA1Zl0KWyAgICA0LjIyMjgyNF0g
cG5wIDAwOjA2OiBbaW8gIDB4MDA2Mi0weDAwNjNdClsgICAgNC4yMjI4MjVdIHBucCAwMDowNjog
W2lvICAweDAwNjUtMHgwMDZmXQpbICAgIDQuMjIyODI3XSBwbnAgMDA6MDY6IFtpbyAgMHgwMDcy
LTB4MDA3Zl0KWyAgICA0LjIyMjgyOF0gcG5wIDAwOjA2OiBbaW8gIDB4MDA4MF0KWyAgICA0LjIy
MjgzMF0gcG5wIDAwOjA2OiBbaW8gIDB4MDA4NC0weDAwODZdClsgICAgNC4yMjI4MzFdIHBucCAw
MDowNjogW2lvICAweDAwODhdClsgICAgNC4yMjI4MzNdIHBucCAwMDowNjogW2lvICAweDAwOGMt
MHgwMDhlXQpbICAgIDQuMjIyODM0XSBwbnAgMDA6MDY6IFtpbyAgMHgwMDkwLTB4MDA5Zl0KWyAg
ICA0LjIyMjgzNV0gcG5wIDAwOjA2OiBbaW8gIDB4MDBhMi0weDAwYmZdClsgICAgNC4yMjI4Mzdd
IHBucCAwMDowNjogW2lvICAweDAwZTAtMHgwMGVmXQpbICAgIDQuMjIyODM4XSBwbnAgMDA6MDY6
IFtpbyAgMHgwNGQwLTB4MDRkMV0KWyAgICA0LjIyMjg4MV0gc3lzdGVtIDAwOjA2OiBbaW8gIDB4
MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjI5MTVdIHN5c3RlbSAwMDow
NjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkKWyAgICA0
LjIyMjkyM10gcG5wIDAwOjA3OiBbaW8gIDB4MDBmMC0weDAwZmZdClsgICAgNC4yMjI5MjVdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDEzIHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwClsgICAgNC4yMjI5
MjddIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwpbICAgIDQu
MjIyOTU5XSB4ZW46IC0tPiBwaXJxPTEzIC0+IGlycT0xMyAoZ3NpPTEzKQpbICAgIDQuMjIyOTc2
XSBwbnAgMDA6MDc6IFtpcnEgMTNdClsgICAgNC4yMjI5OTldIHBucCAwMDowNzogUGx1ZyBhbmQg
UGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDQgKGFjdGl2ZSkKWyAgICA0LjIyMzM5Nl0gcG5w
IDAwOjA4OiBbaW8gIDB4MDNmOC0weDAzZmZdClsgICAgNC4yMjMzOThdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDQgdHJpZ2dlcmluZyAxIHBvbGFyaXR5IDAKWyAgICA0LjIyMzQwMF0geGVuX21hcF9w
aXJxX2dzaTogcmV0dXJuaW5nIGlycSA0IGZvciBnc2kgNApbICAgIDQuMjIzNDMyXSB4ZW46IC0t
PiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQpbICAgIDQuMjIzNDQ4XSBwbnAgMDA6MDg6IFtpcnEg
NF0KWyAgICA0LjIyMzQ1MF0gcG5wIDAwOjA4OiBbZG1hIDAgZGlzYWJsZWRdClsgICAgNC4yMjM1
MDBdIHBucCAwMDowODogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEgKGFj
dGl2ZSkKWyAgICA0LjIyMzgxNV0gcG5wIDAwOjA5OiBbaW8gIDB4MDQwMC0weDA0NTNdClsgICAg
NC4yMjM4MTddIHBucCAwMDowOTogW2lvICAweDA0NTgtMHgwNDdmXQpbICAgIDQuMjIzODE4XSBw
bnAgMDA6MDk6IFtpbyAgMHgxMTgwLTB4MTE5Zl0KWyAgICA0LjIyMzgyMF0gcG5wIDAwOjA5OiBb
aW8gIDB4MDUwMC0weDA1N2ZdClsgICAgNC4yMjM4MjJdIHBucCAwMDowOTogW21lbSAweGZlZDFj
MDAwLTB4ZmVkMWZmZmZdClsgICAgNC4yMjM4MjNdIHBucCAwMDowOTogW21lbSAweGZlYzAwMDAw
LTB4ZmVjZmZmZmZdClsgICAgNC4yMjM4MjVdIHBucCAwMDowOTogW21lbSAweGZlZDA4MDAwLTB4
ZmVkMDhmZmZdClsgICAgNC4yMjM4MjZdIHBucCAwMDowOTogW21lbSAweGZmMDAwMDAwLTB4ZmZm
ZmZmZmZdClsgICAgNC4yMjM4NzFdIHN5c3RlbSAwMDowOTogW2lvICAweDA0MDAtMHgwNDUzXSBo
YXMgYmVlbiByZXNlcnZlZApbICAgIDQuMjIzOTA1XSBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwNDU4
LTB4MDQ3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICA0LjIyMzkzOF0gc3lzdGVtIDAwOjA5OiBb
aW8gIDB4MTE4MC0weDExOWZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjM5NzFdIHN5c3Rl
bSAwMDowOTogW2lvICAweDA1MDAtMHgwNTdmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDQuMjI0
MDA1XSBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXSBoYXMgYmVlbiBy
ZXNlcnZlZApbICAgIDQuMjI0MDM5XSBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZWMwMDAwMC0weGZl
Y2ZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA0LjIyNDA3NF0gc3lzdGVtIDAwOjA5
OiBbbWVtIDB4ZmVkMDgwMDAtMHhmZWQwOGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICA0LjIy
NDEwOF0gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmYwMDAwMDAtMHhmZmZmZmZmZl0gaGFzIGJlZW4g
cmVzZXJ2ZWQKWyAgICA0LjIyNDE0Ml0gc3lzdGVtIDAwOjA5OiBQbHVnIGFuZCBQbGF5IEFDUEkg
ZGV2aWNlLCBJRHMgUE5QMGMwMSAoYWN0aXZlKQpbICAgIDQuMjI0MjAyXSBwbnAgMDA6MGE6IFtp
byAgMHgwNDU0LTB4MDQ1N10KWyAgICA0LjIyNDI0M10gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDQ1
NC0weDA0NTddIGhhcyBiZWVuIHJlc2VydmVkClsgICAgNC4yMjQyNzddIHN5c3RlbSAwMDowYTog
UGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIElOVDNmMGQgUE5QMGMwMiAoYWN0aXZlKQpb
ICAgIDQuMjI0NDM4XSBwbnAgMDA6MGI6IFttZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmXQpbICAg
IDQuMjI0NDc0XSBwbnAgMDA6MGI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAw
MTAzIChhY3RpdmUpClsgICAgNC4yMjQ2ODVdIHBucDogUG5QIEFDUEk6IGZvdW5kIDEyIGRldmlj
ZXMKWyAgICA0LjIyNDcxNV0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVkClsg
ICAgNC4yMzAyNjhdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAgKDB4MHhmZmZm
ZmYpIC0gYWJvcnRpbmcuClsgICAgNC4yMzAzMThdIFBDSTogbWF4IGJ1cyBkZXB0aDogNCBwY2lf
dHJ5X251bTogNQpbICAgIDQuMjMwNTU5XSBwY2kgMDAwMDowMDowMS4wOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDEtMDFdClsgICAgNC4yMzA1OTJdIHBjaSAwMDAwOjAwOjAxLjA6ICAgYnJpZGdlIHdp
bmRvdyBbaW8gIDB4ZTAwMC0weGVmZmZdClsgICAgNC4yMzA2MjhdIHBjaSAwMDAwOjAwOjAxLjA6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmJlMDAwMDAtMHhmYmVmZmZmZl0KWyAgICA0LjIzMDY2
NF0gcGNpIDAwMDA6MDA6MDEuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhjMDAwMDAwMC0weGNm
ZmZmZmZmIDY0Yml0IHByZWZdClsgICAgNC4yMzA3MTVdIHBjaSAwMDAwOjAyOjAwLjA6IFBDSSBi
cmlkZ2UgdG8gW2J1cyAwMy0wM10KWyAgICA0LjIzMDc1MF0gcGNpIDAwMDA6MDI6MDAuMDogICBi
cmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0KWyAgICA0LjIzMDgxNV0gcGNpIDAwMDA6
MDA6MWMuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAzXQpbICAgIDQuMjMwODQ5XSBwY2kgMDAw
MDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQpbICAgIDQuMjMw
OTAyXSBwY2kgMDAwMDowMDoxYy40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdClsgICAgNC4y
MzA5MzVdIHBjaSAwMDAwOjAwOjFjLjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNm
ZmZdClsgICAgNC4yMzA5NzVdIHBjaSAwMDAwOjAwOjFjLjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4ZmJkMDAwMDAtMHhmYmRmZmZmZl0KWyAgICA0LjIzMTAyMV0gcGNpIDAwMDA6MDA6MWMuNTog
UENJIGJyaWRnZSB0byBbYnVzIDA1LTA1XQpbICAgIDQuMjMxMDYwXSBwY2kgMDAwMDowMDoxYy41
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZiYzAwMDAwLTB4ZmJjZmZmZmZdClsgICAgNC4yMzEx
MDddIHBjaSAwMDAwOjAwOjFjLjY6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0wNl0KWyAgICA0LjIz
MTE0NF0gcGNpIDAwMDA6MDA6MWMuNjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYmIwMDAwMC0w
eGZiYmZmZmZmXQpbICAgIDQuMjMxMTkyXSBwY2kgMDAwMDowODowMS4wOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDktMDldClsgICAgNC4yMzEyNDhdIHBjaSAwMDAwOjBhOjAwLjA6IFBDSSBicmlkZ2Ug
dG8gW2J1cyAwYi0wYl0KWyAgICA0LjIzMTMxMl0gcGNpIDAwMDA6MDg6MDQuMDogUENJIGJyaWRn
ZSB0byBbYnVzIDBhLTBiXQpbICAgIDQuMjMxMzY4XSBwY2kgMDAwMDowODowNS4wOiBQQ0kgYnJp
ZGdlIHRvIFtidXMgMGMtMGNdClsgICAgNC4yMzE0MDJdIHBjaSAwMDAwOjA4OjA1LjA6ICAgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZdClsgICAgNC4yMzE0NDRdIHBjaSAwMDAwOjA4
OjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmI5MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0
LjIzMTQ5NF0gcGNpIDAwMDA6MDg6MDYuMDogUENJIGJyaWRnZSB0byBbYnVzIDBkLTBkXQpbICAg
IDQuMjMxNTM0XSBwY2kgMDAwMDowODowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZiODAw
MDAwLTB4ZmI4ZmZmZmZdClsgICAgNC4yMzE1NzNdIHBjaSAwMDAwOjA4OjA2LjA6ICAgYnJpZGdl
IHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMjMx
NjMwXSBwY2kgMDAwMDowODowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGUtMGVdClsgICAgNC4y
MzE2ODddIHBjaSAwMDAwOjA4OjA4LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwZi0wZl0KWyAgICA0
LjIzMTc0NF0gcGNpIDAwMDA6MDg6MDkuMDogUENJIGJyaWRnZSB0byBbYnVzIDEwLTEwXQpbICAg
IDQuMjMxODAwXSBwY2kgMDAwMDowNzowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDgtMTBdClsg
ICAgNC4yMzE4MzRdIHBjaSAwMDAwOjA3OjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YjAw
MC0weGJmZmZdClsgICAgNC4yMzE4NzZdIHBjaSAwMDAwOjA3OjAwLjA6ICAgYnJpZGdlIHdpbmRv
dyBbbWVtIDB4ZmI4MDAwMDAtMHhmYjlmZmZmZl0KWyAgICA0LjIzMTkxNV0gcGNpIDAwMDA6MDc6
MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0weGQwMGZmZmZmIDY0Yml0IHBy
ZWZdClsgICAgNC4yMzE5NzJdIHBjaSAwMDAwOjAwOjFjLjc6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
Ny0xMF0KWyAgICA0LjIzMjAwNV0gcGNpIDAwMDA6MDA6MWMuNzogICBicmlkZ2Ugd2luZG93IFtp
byAgMHhiMDAwLTB4YmZmZl0KWyAgICA0LjIzMjA0NF0gcGNpIDAwMDA6MDA6MWMuNzogICBicmlk
Z2Ugd2luZG93IFttZW0gMHhmYjgwMDAwMC0weGZiYWZmZmZmXQpbICAgIDQuMjMyMDgzXSBwY2kg
MDAwMDowMDoxYy43OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZDAwZmZmZmYg
NjRiaXQgcHJlZl0KWyAgICA0LjIzMjE0Ml0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjIzMjE1Ml0geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9
MTYgKGdzaT0xNikKWyAgICA0LjIzMjE2N10gcGNpIDAwMDA6MDA6MDEuMDogUENJIElOVCBBIC0+
IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgNC4yMzIyMDRdIHBjaSAwMDAwOjAw
OjAxLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjMyMjEyXSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjMyMjE2XSB4
ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQpbICAgIDQuMjMyMjMxXSBwY2kgMDAw
MDowMDoxYy4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKWyAg
ICA0LjIzMjI2OV0gcGNpIDAwMDA6MDA6MWMuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0
ClsgICAgNC4yMzIyNzddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxClsgICAgNC4yMzIyNzhdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTYg
Zm9yIGdzaSAxNgpbICAgIDQuMjMyMzEwXSB4ZW46IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3Np
PTE2KQpbICAgIDQuMjMyMzExXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgNC4yMzIz
NDBdIHBjaSAwMDAwOjAyOjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+
IElSUSAxNgpbICAgIDQuMjMyMzgyXSBwY2kgMDAwMDowMjowMC4wOiBzZXR0aW5nIGxhdGVuY3kg
dGltZXIgdG8gNjQKWyAgICA0LjIzMjM5Ml0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjIzMjM5NF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJu
aW5nIGlycSAxNyBmb3IgZ3NpIDE3ClsgICAgNC4yMzI0MjVdIHhlbjogLS0+IHBpcnE9MTcgLT4g
aXJxPTE3IChnc2k9MTcpClsgICAgNC4yMzI0MjZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcK
WyAgICA0LjIzMjQ1NV0gcGNpIDAwMDA6MDA6MWMuNDogUENJIElOVCBBIC0+IEdTSSAxNyAobGV2
ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgNC4yMzI0OTNdIHBjaSAwMDAwOjAwOjFjLjQ6IHNldHRp
bmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjMyNTAyXSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjMyNTAzXSB4ZW5fbWFwX3BpcnFf
Z3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgICA0LjIzMjUzNV0geGVuOiAtLT4g
cGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgICA0LjIzMjUzNl0gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDoxNgpbICAgIDQuMjMyNTY1XSBwY2kgMDAwMDowMDoxYy41OiBQQ0kgSU5UIEIgLT4g
R1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKWyAgICA0LjIzMjYwM10gcGNpIDAwMDA6MDA6
MWMuNTogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4yMzI2MTJdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4yMzI2MTZdIHhl
bjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpClsgICAgNC4yMzI2MzFdIHBjaSAwMDAw
OjAwOjFjLjY6IFBDSSBJTlQgQyAtPiBHU0kgMTggKGxldmVsLCBsb3cpIC0+IElSUSAxOApbICAg
IDQuMjMyNjY5XSBwY2kgMDAwMDowMDoxYy42OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQK
WyAgICA0LjIzMjY3OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDEKWyAgICA0LjIzMjY4MV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkK
WyAgICA0LjIzMjY5Nl0gcGNpIDAwMDA6MDA6MWMuNzogUENJIElOVCBEIC0+IEdTSSAxOSAobGV2
ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAgNC4yMzI3MzNdIHBjaSAwMDAwOjAwOjFjLjc6IHNldHRp
bmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjMyNzQzXSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjMyNzQ1XSB4ZW5fbWFwX3BpcnFf
Z3NpOiByZXR1cm5pbmcgaXJxIDE5IGZvciBnc2kgMTkKWyAgICA0LjIzMjc3N10geGVuOiAtLT4g
cGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkKWyAgICA0LjIzMjc3OF0gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDoxOQpbICAgIDQuMjMyODA3XSBwY2kgMDAwMDowNzowMC4wOiBQQ0kgSU5UIEEgLT4g
R1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICA0LjIzMjg0N10gcGNpIDAwMDA6MDc6
MDAuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4yMzI4NTddIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4yMzI4NTldIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuMjMyODkw
XSB4ZW46IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDQuMjMyODkxXSBBbHJl
YWR5IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgNC4yMzI5MjFdIHBjaSAwMDAwOjA4OjAxLjA6IFBD
SSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAxNgpbICAgIDQuMjMyOTYwXSBw
Y2kgMDAwMDowODowMS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjIzMjk3
MV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0
LjIzMjk3Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOSBmb3IgZ3NpIDE5Clsg
ICAgNC4yMzMwMDRdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTE5IChnc2k9MTkpClsgICAgNC4y
MzMwMDVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTkKWyAgICA0LjIzMzAzNF0gcGNpIDAwMDA6
MDg6MDQuMDogUENJIElOVCBBIC0+IEdTSSAxOSAobGV2ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAg
NC4yMzMwNzRdIHBjaSAwMDAwOjA4OjA0LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApb
ICAgIDQuMjMzMDg2XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQpbICAgIDQuMjMzMDg3XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE5IGZv
ciBnc2kgMTkKWyAgICA0LjIzMzExOV0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0x
OSkKWyAgICA0LjIzMzEyMF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAgIDQuMjMzMTUw
XSBwY2kgMDAwMDowYTowMC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJ
UlEgMTkKWyAgICA0LjIzMzE5MF0gcGNpIDAwMDA6MGE6MDAuMDogc2V0dGluZyBsYXRlbmN5IHRp
bWVyIHRvIDY0ClsgICAgNC4yMzMyMDJdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAgNC4yMzMyMDNdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmlu
ZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuMjMzMjM1XSB4ZW46IC0tPiBwaXJxPTE2IC0+IGly
cT0xNiAoZ3NpPTE2KQpbICAgIDQuMjMzMjM2XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2Clsg
ICAgNC4yMzQ1NjBdIHBjaSAwMDAwOjA4OjA1LjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVs
LCBsb3cpIC0+IElSUSAxNgpbICAgIDQuMjM0NTk5XSBwY2kgMDAwMDowODowNS4wOiBzZXR0aW5n
IGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjIzNDYxMF0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjIzNDYxMV0geGVuX21hcF9waXJxX2dz
aTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3ClsgICAgNC4yMzQ2NDNdIHhlbjogLS0+IHBp
cnE9MTcgLT4gaXJxPTE3IChnc2k9MTcpClsgICAgNC4yMzQ2NDRdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTcKWyAgICA0LjIzNDY3M10gcGNpIDAwMDA6MDg6MDYuMDogUENJIElOVCBBIC0+IEdT
SSAxNyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgNC4yMzQ3MTNdIHBjaSAwMDAwOjA4OjA2
LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuMjM0NzIzXSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuMjM0NzI1XSB4ZW5f
bWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKWyAgICA0LjIzNDc1Nl0g
eGVuOiAtLT4gcGlycT0xOCAtPiBpcnE9MTggKGdzaT0xOCkKWyAgICA0LjIzNDc1OF0gQWxyZWFk
eSBzZXR1cCB0aGUgR1NJIDoxOApbICAgIDQuMjM0Nzg3XSBwY2kgMDAwMDowODowNy4wOiBQQ0kg
SU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgICA0LjIzNDgyNl0gcGNp
IDAwMDA6MDg6MDcuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC4yMzQ4Mzdd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC4y
MzQ4MzhdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTkgZm9yIGdzaSAxOQpbICAg
IDQuMjM0ODcwXSB4ZW46IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDQuMjM0
ODcxXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE5ClsgICAgNC4yMzQ5MDBdIHBjaSAwMDAwOjA4
OjA4LjA6IFBDSSBJTlQgQSAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAxOQpbICAgIDQu
MjM0OTM5XSBwY2kgMDAwMDowODowOC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAg
ICA0LjIzNDk1MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5
IDEKWyAgICA0LjIzNDk1Ml0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3Ig
Z3NpIDE2ClsgICAgNC4yMzQ5ODNdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYp
ClsgICAgNC4yMzQ5ODVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICA0LjIzNTAxM10g
cGNpIDAwMDA6MDg6MDkuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJR
IDE2ClsgICAgNC4yMzUwNTNdIHBjaSAwMDAwOjA4OjA5LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1l
ciB0byA2NApbICAgIDQuMjM1MDU3XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAw
eDAwMDAtMHgwM2FmXQpbICAgIDQuMjM1MDU5XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDUg
W2lvICAweDAzZTAtMHgwY2Y3XQpbICAgIDQuMjM1MDYwXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291
cmNlIDYgW2lvICAweDAzYjAtMHgwM2RmXQpbICAgIDQuMjM1MDYyXSBwY2lfYnVzIDAwMDA6MDA6
IHJlc291cmNlIDcgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDQuMjM1MDYzXSBwY2lfYnVzIDAw
MDA6MDA6IHJlc291cmNlIDggW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsgICAgNC4yMzUw
NjVdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgOSBbbWVtIDB4MDAwYzAwMDAtMHgwMDBkZmZm
Zl0KWyAgICA0LjIzNTA2N10gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxMCBbbWVtIDB4N2Zh
MDAwMDAtMHhmZmZmZmZmZl0KWyAgICA0LjIzNTA2OF0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJj
ZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0KWyAgICA0LjIzNTA3MF0gcGNpX2J1cyAwMDAwOjAxOiBy
ZXNvdXJjZSAxIFttZW0gMHhmYmUwMDAwMC0weGZiZWZmZmZmXQpbICAgIDQuMjM1MDcxXSBwY2lf
YnVzIDAwMDA6MDE6IHJlc291cmNlIDIgW21lbSAweGMwMDAwMDAwLTB4Y2ZmZmZmZmYgNjRiaXQg
cHJlZl0KWyAgICA0LjIzNTA3M10gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSAwIFtpbyAgMHhk
MDAwLTB4ZGZmZl0KWyAgICA0LjIzNTA3NV0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSAwIFtp
byAgMHhkMDAwLTB4ZGZmZl0KWyAgICA0LjIzNTA3Nl0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJj
ZSAwIFtpbyAgMHhjMDAwLTB4Y2ZmZl0KWyAgICA0LjIzNTA3OF0gcGNpX2J1cyAwMDAwOjA0OiBy
ZXNvdXJjZSAxIFttZW0gMHhmYmQwMDAwMC0weGZiZGZmZmZmXQpbICAgIDQuMjM1MDc5XSBwY2lf
YnVzIDAwMDA6MDU6IHJlc291cmNlIDEgW21lbSAweGZiYzAwMDAwLTB4ZmJjZmZmZmZdClsgICAg
NC4yMzUwODFdIHBjaV9idXMgMDAwMDowNjogcmVzb3VyY2UgMSBbbWVtIDB4ZmJiMDAwMDAtMHhm
YmJmZmZmZl0KWyAgICA0LjIzNTA4Ml0gcGNpX2J1cyAwMDAwOjA3OiByZXNvdXJjZSAwIFtpbyAg
MHhiMDAwLTB4YmZmZl0KWyAgICA0LjIzNTA4NF0gcGNpX2J1cyAwMDAwOjA3OiByZXNvdXJjZSAx
IFttZW0gMHhmYjgwMDAwMC0weGZiYWZmZmZmXQpbICAgIDQuMjM1MDg1XSBwY2lfYnVzIDAwMDA6
MDc6IHJlc291cmNlIDIgW21lbSAweGQwMDAwMDAwLTB4ZDAwZmZmZmYgNjRiaXQgcHJlZl0KWyAg
ICA0LjIzNTA4N10gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAwIFtpbyAgMHhiMDAwLTB4YmZm
Zl0KWyAgICA0LjIzNTA4OF0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAxIFttZW0gMHhmYjgw
MDAwMC0weGZiOWZmZmZmXQpbICAgIDQuMjM1MDkwXSBwY2lfYnVzIDAwMDA6MDg6IHJlc291cmNl
IDIgW21lbSAweGQwMDAwMDAwLTB4ZDAwZmZmZmYgNjRiaXQgcHJlZl0KWyAgICA0LjIzNTA5Ml0g
cGNpX2J1cyAwMDAwOjBjOiByZXNvdXJjZSAwIFtpbyAgMHhiMDAwLTB4YmZmZl0KWyAgICA0LjIz
NTA5M10gcGNpX2J1cyAwMDAwOjBjOiByZXNvdXJjZSAxIFttZW0gMHhmYjkwMDAwMC0weGZiOWZm
ZmZmXQpbICAgIDQuMjM1MDk1XSBwY2lfYnVzIDAwMDA6MGQ6IHJlc291cmNlIDEgW21lbSAweGZi
ODAwMDAwLTB4ZmI4ZmZmZmZdClsgICAgNC4yMzUwOTddIHBjaV9idXMgMDAwMDowZDogcmVzb3Vy
Y2UgMiBbbWVtIDB4ZDAwMDAwMDAtMHhkMDBmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDQuMjM1MTQ5
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIKWyAgICA0LjIzNTYyNl0gSVAgcm91
dGUgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5
dGVzKQpbICAgIDQuMjM3NTIzXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiA1
MjQyODggKG9yZGVyOiAxMSwgODM4ODYwOCBieXRlcykKWyAgICA0LjIzODgzM10gVENQIGJpbmQg
aGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpClsgICAg
NC4yMzkwMDhdIFRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgNTI0Mjg4
IGJpbmQgNjU1MzYpClsgICAgNC4yMzkwNDJdIFRDUCByZW5vIHJlZ2lzdGVyZWQKWyAgICA0LjIz
OTA5OF0gVURQIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDUsIDEzMTA3MiBieXRl
cykKWyAgICA0LjIzOTE3NF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRl
cjogNSwgMTMxMDcyIGJ5dGVzKQpbICAgIDQuMjM5MzE4XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9j
b2wgZmFtaWx5IDEKWyAgICA0LjIzOTM2OF0gcGNpIDAwMDA6MDA6MDIuMDogQm9vdCB2aWRlbyBk
ZXZpY2UKWyAgICA0LjQ2Mzk5NV0gUENJOiBDTFMgNjQgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICA0
LjQ2NDAzNF0gVW5wYWNraW5nIGluaXRyYW1mcy4uLgpbICAgIDQuNDg5OTQyXSBGcmVlaW5nIGlu
aXRyZCBtZW1vcnk6IDMzNzM2ayBmcmVlZApbICAgIDQuNDk1NDI4XSBhdWRpdDogaW5pdGlhbGl6
aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkKWyAgICA0LjQ5NTQ3M10gdHlwZT0yMDAwIGF1
ZGl0KDEzMjk5NDg0NDEuNDc1OjEpOiBpbml0aWFsaXplZApbICAgIDQuNTExMjE1XSBIdWdlVExC
IHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDQu
NTExNDgxXSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgNC41MTE1NDRdIERxdW90
LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQpbICAg
IDQuNTExNjU5XSBtc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDExMzY5ClsgICAgNC41MTE4NTldIGFs
ZzogTm8gdGVzdCBmb3Igc3Rkcm5nIChrcm5nKQpbICAgIDQuNTExOTE5XSBCbG9jayBsYXllciBT
Q1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUzKQpb
ICAgIDQuNTExOTY4XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkClsgICAgNC41MTE5OThd
IGlvIHNjaGVkdWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgNC41MTIwNDJdIGlvIHNjaGVk
dWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKWyAgICA0LjUxMjE3OF0gcGNpZXBvcnQgMDAw
MDowMDowMS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMjMzNV0gcGNp
ZXBvcnQgMDAwMDowMDoxYy4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUx
MjU1Ml0gcGNpZXBvcnQgMDAwMDowMDoxYy40OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQK
WyAgICA0LjUxMjc2OV0gcGNpZXBvcnQgMDAwMDowMDoxYy41OiBzZXR0aW5nIGxhdGVuY3kgdGlt
ZXIgdG8gNjQKWyAgICA0LjUxMjk4Nl0gcGNpZXBvcnQgMDAwMDowMDoxYy42OiBzZXR0aW5nIGxh
dGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMzIwMl0gcGNpZXBvcnQgMDAwMDowMDoxYy43OiBz
ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMzQzN10gcGNpZXBvcnQgMDAwMDow
NzowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxMzc0N10gcGNpZXBv
cnQgMDAwMDowODowMS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNDA1
OF0gcGNpZXBvcnQgMDAwMDowODowNC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAg
ICA0LjUxNDM3MV0gcGNpZXBvcnQgMDAwMDowODowNS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg
dG8gNjQKWyAgICA0LjUxNDY4MV0gcGNpZXBvcnQgMDAwMDowODowNi4wOiBzZXR0aW5nIGxhdGVu
Y3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNDk5Ml0gcGNpZXBvcnQgMDAwMDowODowNy4wOiBzZXR0
aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNTMwM10gcGNpZXBvcnQgMDAwMDowODow
OC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNTYxNF0gcGNpZXBvcnQg
MDAwMDowODowOS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0LjUxNTk1OF0g
cGNpZXBvcnQgMDAwMDowMDowMS4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50
ZXJydXB0ClsgICAgNC41MTU5OTRdIHBjaSAwMDAwOjAxOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhy
b3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjAyOF0gcGNpIDAwMDA6MDE6MDAuMTog
U2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuNTE2MDYzXSBw
Y2llX3BtZSAwMDAwOjAwOjAxLjA6cGNpZTAxOiBzZXJ2aWNlIGRyaXZlciBwY2llX3BtZSBsb2Fk
ZWQKWyAgICA0LjUxNjA5OF0gcGNpZXBvcnQgMDAwMDowMDoxYy4wOiBTaWduYWxpbmcgUE1FIHRo
cm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTYxMzJdIHBjaSAwMDAwOjAyOjAwLjA6
IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjE2Nl0g
cGNpIDAwMDA6MDM6MDQuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVw
dApbICAgIDQuNTE2MjA0XSBwY2llX3BtZSAwMDAwOjAwOjFjLjA6cGNpZTAxOiBzZXJ2aWNlIGRy
aXZlciBwY2llX3BtZSBsb2FkZWQKWyAgICA0LjUxNjIzOV0gcGNpZXBvcnQgMDAwMDowMDoxYy40
OiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTYyNzRd
IHBjaSAwMDAwOjA0OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1
cHQKWyAgICA0LjUxNjMxMl0gcGNpZV9wbWUgMDAwMDowMDoxYy40OnBjaWUwMTogc2VydmljZSBk
cml2ZXIgcGNpZV9wbWUgbG9hZGVkClsgICAgNC41MTYzNDddIHBjaWVwb3J0IDAwMDA6MDA6MWMu
NTogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuNTE2Mzgx
XSBwY2kgMDAwMDowNTowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJy
dXB0ClsgICAgNC41MTY0MTldIHBjaWVfcG1lIDAwMDA6MDA6MWMuNTpwY2llMDE6IHNlcnZpY2Ug
ZHJpdmVyIHBjaWVfcG1lIGxvYWRlZApbICAgIDQuNTE2NDUzXSBwY2llcG9ydCAwMDAwOjAwOjFj
LjY6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjQ4
OF0gcGNpIDAwMDA6MDY6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVy
cnVwdApbICAgIDQuNTE2NTI2XSBwY2llX3BtZSAwMDAwOjAwOjFjLjY6cGNpZTAxOiBzZXJ2aWNl
IGRyaXZlciBwY2llX3BtZSBsb2FkZWQKWyAgICA0LjUxNjU2MV0gcGNpZXBvcnQgMDAwMDowMDox
Yy43OiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTY1
OTVdIHBjaWVwb3J0IDAwMDA6MDc6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1F
IGludGVycnVwdApbICAgIDQuNTE2NjI5XSBwY2llcG9ydCAwMDAwOjA4OjAxLjA6IFNpZ25hbGlu
ZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjY2M10gcGNpZXBvcnQg
MDAwMDowODowNC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Clsg
ICAgNC41MTY2OTddIHBjaSAwMDAwOjBhOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll
IFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjczMV0gcGNpZXBvcnQgMDAwMDowODowNS4wOiBTaWdu
YWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTY3NjVdIHBjaSAw
MDAwOjBjOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAg
ICA0LjUxNjc5OF0gcGNpZXBvcnQgMDAwMDowODowNi4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2gg
UENJZSBQTUUgaW50ZXJydXB0ClsgICAgNC41MTY4MzJdIHBjaSAwMDAwOjBkOjAwLjA6IFNpZ25h
bGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjg2NV0gcGNpZXBv
cnQgMDAwMDowODowNy4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0
ClsgICAgNC41MTY4OTldIHBjaWVwb3J0IDAwMDA6MDg6MDguMDogU2lnbmFsaW5nIFBNRSB0aHJv
dWdoIFBDSWUgUE1FIGludGVycnVwdApbICAgIDQuNTE2OTMzXSBwY2llcG9ydCAwMDAwOjA4OjA5
LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKWyAgICA0LjUxNjk3
Ml0gcGNpZV9wbWUgMDAwMDowMDoxYy43OnBjaWUwMTogc2VydmljZSBkcml2ZXIgcGNpZV9wbWUg
bG9hZGVkClsgICAgNC41MTcwNjldIEVSU1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCEKWyAgICA0LjUx
NzA5OF0gR0hFUzogSEVTVCBpcyBub3QgZW5hYmxlZCEKWyAgICA0LjUxNzQ5N10gU2VyaWFsOiA4
MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDQuNTM4
MjUyXSBzZXJpYWw4MjUwOiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBB
ClsgICAgNC41ODg3NDRdIDAwOjA4OiB0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEg
MTY1NTBBClsgICAgNC42MDQxMDZdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBp
biBfQ1JTClsgICAgNC42MDQxNDZdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMwpbICAg
IDQuNjA0MjQ5XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAuMDogSW50ZWwgU2FuZHlicmlkZ2Ug
Q2hpcHNldApbICAgIDQuNjA0NDE4XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAuMDogZGV0ZWN0
ZWQgZ3R0IHNpemU6IDIwOTcxNTJLIHRvdGFsLCAyNjIxNDRLIG1hcHBhYmxlClsgICAgNC42MDU0
NjFdIGFncGdhcnQtaW50ZWwgMDAwMDowMDowMC4wOiBkZXRlY3RlZCAyNjIxNDRLIHN0b2xlbiBt
ZW1vcnkKWyAgICA0LjYwNTYzOF0gYWdwZ2FydC1pbnRlbCAwMDAwOjAwOjAwLjA6IEFHUCBhcGVy
dHVyZSBpcyAyNTZNIEAgMHhiMDAwMDAwMApbICAgIDQuNjA1NzcxXSBpODA0MjogUE5QOiBObyBQ
Uy8yIGNvbnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuClsgICAgNC42MDg2
OThdIHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKWyAgICA0LjYwODcz
NV0gc2VyaW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKWyAgICA0LjYwODkx
MF0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKWyAgICA0
LjYwODk5MV0gcnRjX2Ntb3MgMDA6MDQ6IFJUQyBjYW4gd2FrZSBmcm9tIFM0ClsgICAgNC42MDkx
ODZdIHJ0Y19jbW9zIDAwOjA0OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMw
ClsgICAgNC42MDkyNzhdIHJ0YzA6IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5
dGVzIG52cmFtClsgICAgNC42MDk0MzFdIFRDUCBjdWJpYyByZWdpc3RlcmVkClsgICAgNC42MDk1
MDJdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAgICA0LjYwOTgwOV0gTW9i
aWxlIElQdjYKWyAgICA0LjYwOTgzN10gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAx
NwpbICAgIDQuNjA5ODY5XSBSZWdpc3RlcmluZyB0aGUgZG5zX3Jlc29sdmVyIGtleSB0eXBlClsg
ICAgNC42MTAwMzddIFBNOiBIaWJlcm5hdGlvbiBpbWFnZSBub3QgcHJlc2VudCBvciBjb3VsZCBu
b3QgYmUgbG9hZGVkLgpbICAgIDQuNjEwMDQ4XSByZWdpc3RlcmVkIHRhc2tzdGF0cyB2ZXJzaW9u
IDEKWyAgICA0LjYxMTA0OF0gcnRjX2Ntb3MgMDA6MDQ6IHNldHRpbmcgc3lzdGVtIGNsb2NrIHRv
IDIwMTItMDItMjIgMjI6MDc6MjAgVVRDICgxMzI5OTQ4NDQwKQpbICAgIDQuNjExMTUyXSBJbml0
aWFsaXppbmcgbmV0d29yayBkcm9wIG1vbml0b3Igc2VydmljZQpbICAgIDQuNjExMzgzXSBGcmVl
aW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA1NjhrIGZyZWVkClsgICAgNC42MTE0NjldIFdyaXRl
IHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogNjE0NGsKWyAgICA0LjYxMzQy
OF0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogNzEyayBmcmVlZApbICAgIDQuNjEzNzEx
XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA2ODRrIGZyZWVkClsgICAgNC42MzM0NTVd
IHVkZXZkWzUwXTogc3RhcnRpbmcgdmVyc2lvbiAxNzUKWyAgICA0LjY2NzA2OV0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDQuNjY3MTM0XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1YgpbICAgIDQuNjc3MDQ0XSBT
Q1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZApbICAgIDQuNjc5NTQ5XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDQuNjgwMjg2XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuNjgwMjkyXSB4ZW5fbWFwX3Bp
cnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKWyAgICA0LjY4MDMzMV0geGVuOiAt
LT4gcGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykKWyAgICA0LjY4MDMzM10gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDoxNwpbICAgIDQuNjgwMzcwXSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IFBDSSBJ
TlQgQSAtPiBHU0kgMTcgKGxldmVsLCBsb3cpIC0+IElSUSAxNwpbICAgIDQuNjgwNDQxXSB4aGNp
X2hjZCAwMDAwOjA1OjAwLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNjgw
NDQ3XSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IHhIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgNC42
ODA1MDNdIHhoY2lfaGNkIDAwMDA6MDU6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciAxClsgICAgNC42ODA3NzBdIHhoY2lfaGNkIDAwMDA6MDU6MDAuMDog
aXJxIDE3LCBpbyBtZW0gMHhmYmMwMDAwMApbICAgIDQuNjgwODYwXSB4aGNpX2hjZCAwMDAwOjA1
OjAwLjA6IEZhaWxlZCB0byBlbmFibGUgTVNJLVgKWyAgICA0LjY4MTE0OV0gdXNiIHVzYjE6IE5l
dyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgpbICAgIDQu
NjgxMTg5XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9
MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0LjY4MTI0MV0gdXNiIHVzYjE6IFByb2R1Y3Q6IHhIQ0kg
SG9zdCBDb250cm9sbGVyClsgICAgNC42ODEyNzddIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExp
bnV4IDMuMi4wLTEtYW1kNjQgeGhjaV9oY2QKWyAgICA0LjY4MTMxNV0gdXNiIHVzYjE6IFNlcmlh
bE51bWJlcjogMDAwMDowNTowMC4wClsgICAgNC42ODU0NzNdIHhIQ0kgeGhjaV9hZGRfZW5kcG9p
bnQgY2FsbGVkIGZvciByb290IGh1YgpbICAgIDQuNjg1NDc2XSB4SENJIHhoY2lfY2hlY2tfYmFu
ZHdpZHRoIGNhbGxlZCBmb3Igcm9vdCBodWIKWyAgICA0LjY4NTUxMF0gaHViIDEtMDoxLjA6IFVT
QiBodWIgZm91bmQKWyAgICA0LjY4NTU1NV0gaHViIDEtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQK
WyAgICA0LjY4NTY4OF0geGhjaV9oY2QgMDAwMDowNTowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxl
cgpbICAgIDQuNjg1NzMzXSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IG5ldyBVU0IgYnVzIHJlZ2lz
dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMgpbICAgIDQuNjg1ODMxXSB1c2IgdXNiMjogTmV3
IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzClsgICAgNC42
ODU4NzRdIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0y
LCBTZXJpYWxOdW1iZXI9MQpbICAgIDQuNjg1OTI2XSB1c2IgdXNiMjogUHJvZHVjdDogeEhDSSBI
b3N0IENvbnRyb2xsZXIKWyAgICA0LjY4NTk2M10gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGlu
dXggMy4yLjAtMS1hbWQ2NCB4aGNpX2hjZApbICAgIDQuNjg2MDAxXSB1c2IgdXNiMjogU2VyaWFs
TnVtYmVyOiAwMDAwOjA1OjAwLjAKWyAgICA0LjY4ODMxOV0geEhDSSB4aGNpX2FkZF9lbmRwb2lu
dCBjYWxsZWQgZm9yIHJvb3QgaHViClsgICAgNC42ODgzMjJdIHhIQ0kgeGhjaV9jaGVja19iYW5k
d2lkdGggY2FsbGVkIGZvciByb290IGh1YgpbICAgIDQuNjg4MzU2XSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZApbICAgIDQuNjg4Mzk5XSBodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApb
ICAgIDQuNzAwNTE2XSBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxl
ciAoRUhDSSkgRHJpdmVyClsgICAgNC43MDA1ODNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRy
aWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgNC43MDA1ODldIHhlbl9tYXBfcGlycV9nc2k6IHJl
dHVybmluZyBpcnEgMTYgZm9yIGdzaSAxNgpbICAgIDQuNzAwNjI4XSB4ZW46IC0tPiBwaXJxPTE2
IC0+IGlycT0xNiAoZ3NpPTE2KQpbICAgIDQuNzAwNjMxXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kg
OjE2ClsgICAgNC43MDA2NjddIGVoY2lfaGNkIDAwMDA6MDA6MWEuMDogUENJIElOVCBBIC0+IEdT
SSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAgNC43MDA3MjhdIGVoY2lfaGNkIDAwMDA6
MDA6MWEuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgNC43MDA3MzRdIGVoY2lf
aGNkIDAwMDA6MDA6MWEuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICA0LjcwMDc4MF0gZWhj
aV9oY2QgMDAwMDowMDoxYS4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMg
bnVtYmVyIDMKWyAgICA0LjcwMDg4Ml0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBkZWJ1ZyBwb3J0
IDIKWyAgICA0LjcwNDgyM10gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBjYWNoZSBsaW5lIHNpemUg
b2YgNjQgaXMgbm90IHN1cHBvcnRlZApbICAgIDQuNzA1MjU1XSBlaGNpX2hjZCAwMDAwOjAwOjFh
LjA6IGlycSAxNiwgaW8gbWVtIDB4ZmJmMDMwMDAKWyAgICA0LjcwNzk1M10geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgICA0LjcwNzk1N10geGVuX21h
cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4ClsgICAgNC43MDgwMjZdIHhl
bjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpClsgICAgNC43MDgwMjhdIEFscmVhZHkg
c2V0dXAgdGhlIEdTSSA6MTgKWyAgICA0LjcwODA5N10geGhjaV9oY2QgMDAwMDowNjowMC4wOiBQ
Q0kgSU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgICA0LjcwODIwM10g
eGhjaV9oY2QgMDAwMDowNjowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0
LjcwODIwOV0geGhjaV9oY2QgMDAwMDowNjowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgpbICAg
IDQuNzA4MjgxXSB4aGNpX2hjZCAwMDAwOjA2OjAwLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgNApbICAgIDQuNzA4NjA5XSB4aGNpX2hjZCAwMDAwOjA2OjAw
LjA6IGlycSAxOCwgaW8gbWVtIDB4ZmJiMDAwMDAKWyAgICA0LjcwODc0MF0geGhjaV9oY2QgMDAw
MDowNjowMC4wOiBGYWlsZWQgdG8gZW5hYmxlIE1TSS1YClsgICAgNC43MDkwODhdIHVzYiB1c2I0
OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIKWyAg
ICA0LjcwOTE2Ml0gdXNiIHVzYjQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9k
dWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAgNC43MDkyMjFdIHVzYiB1c2I0OiBQcm9kdWN0OiB4
SENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQuNzA5MjU4XSB1c2IgdXNiNDogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjIuMC0xLWFtZDY0IHhoY2lfaGNkClsgICAgNC43MDkyOTVdIHVzYiB1c2I0OiBT
ZXJpYWxOdW1iZXI6IDAwMDA6MDY6MDAuMApbICAgIDQuNzA5NDE2XSB4SENJIHhoY2lfYWRkX2Vu
ZHBvaW50IGNhbGxlZCBmb3Igcm9vdCBodWIKWyAgICA0LjcwOTQxOV0geEhDSSB4aGNpX2NoZWNr
X2JhbmR3aWR0aCBjYWxsZWQgZm9yIHJvb3QgaHViClsgICAgNC43MDk0NTNdIGh1YiA0LTA6MS4w
OiBVU0IgaHViIGZvdW5kClsgICAgNC43MDk0OTZdIGh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVj
dGVkClsgICAgNC43MDk2MDhdIHhoY2lfaGNkIDAwMDA6MDY6MDAuMDogeEhDSSBIb3N0IENvbnRy
b2xsZXIKWyAgICA0LjcwOTY1MV0geGhjaV9oY2QgMDAwMDowNjowMC4wOiBuZXcgVVNCIGJ1cyBy
ZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUKWyAgICA0LjcwOTcyOF0gdXNiIHVzYjU6
IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMwpbICAg
IDQuNzA5NzY4XSB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0LjcwOTgxOV0gdXNiIHVzYjU6IFByb2R1Y3Q6IHhI
Q0kgSG9zdCBDb250cm9sbGVyClsgICAgNC43MDk4NTVdIHVzYiB1c2I1OiBNYW51ZmFjdHVyZXI6
IExpbnV4IDMuMi4wLTEtYW1kNjQgeGhjaV9oY2QKWyAgICA0LjcwOTg5M10gdXNiIHVzYjU6IFNl
cmlhbE51bWJlcjogMDAwMDowNjowMC4wClsgICAgNC43MTAwMzJdIGxpYmF0YSB2ZXJzaW9uIDMu
MDAgbG9hZGVkLgpbICAgIDQuNzEwMTM3XSB4SENJIHhoY2lfYWRkX2VuZHBvaW50IGNhbGxlZCBm
b3Igcm9vdCBodWIKWyAgICA0LjcxMDE0MF0geEhDSSB4aGNpX2NoZWNrX2JhbmR3aWR0aCBjYWxs
ZWQgZm9yIHJvb3QgaHViClsgICAgNC43MTAxNzFdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5k
ClsgICAgNC43MTAyMTRdIGh1YiA1LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAgNC43Mjc5
MDZdIGVoY2lfaGNkIDAwMDA6MDA6MWEuMDogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKWyAg
ICA0LjcyNzk3N10gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi
LCBpZFByb2R1Y3Q9MDAwMgpbICAgIDQuNzI4MDIyXSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2Ug
c3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICA0LjcyODA3N10g
dXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgNC43MjgxMTVdIHVz
YiB1c2IzOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMi4wLTEtYW1kNjQgZWhjaV9oY2QKWyAgICA0
LjcyODE1NF0gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxYS4wClsgICAgNC43Mjgz
MzVdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgNC43MjgzNzRdIGh1YiAzLTA6MS4w
OiAyIHBvcnRzIGRldGVjdGVkClsgICAgNC43Mjg1MDRdIGFoY2kgMDAwMDowMDoxZi4yOiB2ZXJz
aW9uIDMuMApbICAgIDQuNzI4NTE5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5n
IDAgcG9sYXJpdHkgMQpbICAgIDQuNzI4NTI3XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg
aXJxIDE5IGZvciBnc2kgMTkKWyAgICA0LjcyODU3M10geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9
MTkgKGdzaT0xOSkKWyAgICA0LjcyODU3Nl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAg
IDQuNzI4NjEzXSBhaGNpIDAwMDA6MDA6MWYuMjogUENJIElOVCBCIC0+IEdTSSAxOSAobGV2ZWws
IGxvdykgLT4gSVJRIDE5ClsgICAgNC43NDE1ODFdIHRnMy5jOnYzLjEyMSAoTm92ZW1iZXIgMiwg
MjAxMSkKWyAgICA0Ljc0MTYzMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICA0Ljc0MTYzNl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSAxNyBmb3IgZ3NpIDE3ClsgICAgNC43NDE2NzRdIHhlbjogLS0+IHBpcnE9MTcgLT4gaXJxPTE3
IChnc2k9MTcpClsgICAgNC43NDE2NzZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcKWyAgICA0
Ljc0MTcxMV0gdGczIDAwMDA6MGQ6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNyAobGV2ZWwsIGxv
dykgLT4gSVJRIDE3ClsgICAgNC43NDE3NjJdIHRnMyAwMDAwOjBkOjAwLjA6IHNldHRpbmcgbGF0
ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzQzOTIwXSBhaGNpIDAwMDA6MDA6MWYuMjogQUhDSSAw
MDAxLjAzMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFNBVEEgbW9kZQpbICAg
IDQuNzQ1Mjc4XSBhaGNpIDAwMDA6MDA6MWYuMjogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIHBtIGxl
ZCBjbG8gcGlvIHNsdW0gcGFydCBlbXMgYXBzdCAKWyAgICA0Ljc0NTMzOF0gYWhjaSAwMDAwOjAw
OjFmLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzQ5OTYwXSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAxNiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuNzQ5OTY1XSB4
ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgICA0Ljc1MDAw
M10geGVuOiAtLT4gcGlycT0xNiAtPiBpcnE9MTYgKGdzaT0xNikKWyAgICA0Ljc1MDAwNV0gQWxy
ZWFkeSBzZXR1cCB0aGUgR1NJIDoxNgpbICAgIDQuNzUwMDQxXSBmaXJld2lyZV9vaGNpIDAwMDA6
MGM6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAg
NC43NTAxMDJdIGZpcmV3aXJlX29oY2kgMDAwMDowYzowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGlt
ZXIgdG8gNjQKWyAgICA0Ljc2OTI5Ml0gdGczIDAwMDA6MGQ6MDAuMDogZXRoMDogVGlnb24zIFtw
YXJ0bm8oQkNNNTc3ODEpIHJldiA1Nzc4NTEwMF0gKFBDSSBFeHByZXNzKSBNQUMgYWRkcmVzcyAw
MDoyNToyMjpmNjpiOToyZQpbICAgIDQuNzY5MzY0XSB0ZzMgMDAwMDowZDowMC4wOiBldGgwOiBh
dHRhY2hlZCBQSFkgaXMgNTc3NjUgKDEwLzEwMC8xMDAwQmFzZS1UIEV0aGVybmV0KSAoV2lyZVNw
ZWVkWzFdLCBFRUVbMV0pClsgICAgNC43Njk0MjFdIHRnMyAwMDAwOjBkOjAwLjA6IGV0aDA6IFJY
Y3N1bXNbMV0gTGlua0NoZ1JFR1swXSBNSWlycVswXSBBU0ZbMF0gVFNPY2FwWzFdClsgICAgNC43
Njk0NzldIHRnMyAwMDAwOjBkOjAwLjA6IGV0aDA6IGRtYV9yd2N0cmxbMDAwMDAwMDFdIGRtYV9t
YXNrWzY0LWJpdF0KWyAgICA0Ljc4NDU1NF0gc2NzaTAgOiBhaGNpClsgICAgNC43ODQ2ODRdIHNj
c2kxIDogYWhjaQpbICAgIDQuNzg0Nzg4XSBzY3NpMiA6IGFoY2kKWyAgICA0Ljc4NDg5Ml0gc2Nz
aTMgOiBhaGNpClsgICAgNC43ODUwMTFdIHNjc2k0IDogYWhjaQpbICAgIDQuNzg1MTE3XSBzY3Np
NSA6IGFoY2kKWyAgICA0Ljc4NTM0MV0gYXRhMTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0
OEAweGZiZjAxMDAwIHBvcnQgMHhmYmYwMTEwMCBpcnEgMzAwClsgICAgNC43ODUzOTBdIGF0YTI6
IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmYmYwMTAwMCBwb3J0IDB4ZmJmMDExODAg
aXJxIDMwMApbICAgIDQuNzg1NDM3XSBhdGEzOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4
QDB4ZmJmMDEwMDAgcG9ydCAweGZiZjAxMjAwIGlycSAzMDAKWyAgICA0Ljc4NTQ4NV0gYXRhNDog
U0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0OEAweGZiZjAxMDAwIHBvcnQgMHhmYmYwMTI4MCBp
cnEgMzAwClsgICAgNC43ODU1MzNdIGF0YTU6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhA
MHhmYmYwMTAwMCBwb3J0IDB4ZmJmMDEzMDAgaXJxIDMwMApbICAgIDQuNzg1NTgwXSBhdGE2OiBT
QVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4QDB4ZmJmMDEwMDAgcG9ydCAweGZiZjAxMzgwIGly
cSAzMDAKWyAgICA0Ljc4NTY1NV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDEKWyAgICA0Ljc4NTY1OV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSAxNiBmb3IgZ3NpIDE2ClsgICAgNC43ODU3MDBdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2
IChnc2k9MTYpClsgICAgNC43ODU3MDJdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgICA0
Ljc4NTc0MF0gYWhjaSAwMDAwOjA0OjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBs
b3cpIC0+IElSUSAxNgpbICAgIDQuNzg1OTkyXSBhaGNpIDAwMDA6MDQ6MDAuMDogQUhDSSAwMDAx
LjAwMDAgMzIgc2xvdHMgMiBwb3J0cyA2IEdicHMgMHgzIGltcGwgU0FUQSBtb2RlClsgICAgNC43
ODYwNDBdIGFoY2kgMDAwMDowNDowMC4wOiBmbGFnczogNjRiaXQgbmNxIHNudGYgbGVkIG9ubHkg
cG1wIGZicyBwaW8gc2x1bSBwYXJ0IHN4cyAKWyAgICA0Ljc4NjA5M10gYWhjaSAwMDAwOjA0OjAw
LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDQuNzg2MzgzXSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDQuNzg2MzkyXSB4ZW46
IC0tPiBwaXJxPTIzIC0+IGlycT0yMyAoZ3NpPTIzKQpbICAgIDQuNzg2NDA2XSBzY3NpNiA6IGFo
Y2kKWyAgICA0Ljc4NjQxMl0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBQQ0kgSU5UIEEgLT4gR1NJ
IDIzIChsZXZlbCwgbG93KSAtPiBJUlEgMjMKWyAgICA0Ljc4NjQzNl0gZWhjaV9oY2QgMDAwMDow
MDoxZC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICA0Ljc4NjQ0MV0gZWhjaV9o
Y2QgMDAwMDowMDoxZC4wOiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQuNzg2NDUzXSBlaGNp
X2hjZCAwMDAwOjAwOjFkLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBu
dW1iZXIgNgpbICAgIDQuNzg2NTEyXSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IGRlYnVnIHBvcnQg
MgpbICAgIDQuNzg2ODM0XSBzY3NpNyA6IGFoY2kKWyAgICA0Ljc4Njk0M10gYXRhNzogU0FUQSBt
YXggVURNQS8xMzMgYWJhciBtMjA0OEAweGZiZDEwMDAwIHBvcnQgMHhmYmQxMDEwMCBpcnEgMzAx
ClsgICAgNC43ODcwNDBdIGF0YTg6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmYmQx
MDAwMCBwb3J0IDB4ZmJkMTAxODAgaXJxIDMwMQpbICAgIDQuNzkwMzkxXSBlaGNpX2hjZCAwMDAw
OjAwOjFkLjA6IGNhY2hlIGxpbmUgc2l6ZSBvZiA2NCBpcyBub3Qgc3VwcG9ydGVkClsgICAgNC43
OTA0MzFdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogaXJxIDIzLCBpbyBtZW0gMHhmYmYwMjAwMApb
ICAgIDQuODAzODkyXSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IFVTQiAyLjAgc3RhcnRlZCwgRUhD
SSAxLjAwClsgICAgNC44MDM5NjZdIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRW
ZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIKWyAgICA0LjgwNDAwMV0gdXNiIHVzYjY6IE5ldyBV
U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAg
NC44MDQwNDZdIHVzYiB1c2I2OiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDQu
ODA0MDc3XSB1c2IgdXNiNjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjIuMC0xLWFtZDY0IGVoY2lf
aGNkClsgICAgNC44MDQxMTBdIHVzYiB1c2I2OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWQuMApb
ICAgIDQuODA0MjQ0XSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDQuODA0MjgxXSBo
dWIgNi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAgIDQuODExOTYxXSBmaXJld2lyZV9vaGNp
OiBBZGRlZCBmdy1vaGNpIGRldmljZSAwMDAwOjBjOjAwLjAsIE9IQ0kgdjEuMTAsIDQgSVIgKyA4
IElUIGNvbnRleHRzLCBxdWlya3MgMHgxMQpbICAgIDQuOTk1OTQyXSB1c2IgMS0yOiBuZXcgaGln
aC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIHhoY2lfaGNkClsgICAgNS4wMTMxOTZd
IHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNDA5LCBpZFByb2R1Y3Q9
MDA1YQpbICAgIDUuMDEzMjU0XSB1c2IgMS0yOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9
MCwgUHJvZHVjdD0wLCBTZXJpYWxOdW1iZXI9MApbICAgIDUuMDEzNDgwXSBodWIgMS0yOjEuMDog
VVNCIGh1YiBmb3VuZApbICAgIDUuMDEzNjgyXSB4aGNpX2hjZCAwMDAwOjA1OjAwLjA6IFdBUk46
IHNob3J0IHRyYW5zZmVyIG9uIGNvbnRyb2wgZXAKWyAgICA1LjAxMzgxNl0gaHViIDEtMjoxLjA6
IDQgcG9ydHMgZGV0ZWN0ZWQKWyAgICA1LjEwMzkwNF0gYXRhMzogU0FUQSBsaW5rIGRvd24gKFNT
dGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAgNS4xMDM5OTJdIGF0YTY6IFNBVEEgbGluayBkb3du
IChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgIDUuMTA0MDA2XSBhdGE3OiBTQVRBIGxpbmsg
ZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMzMCkKWyAgICA1LjEwNDA1NV0gYXRhODogU0FUQSBs
aW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMzApClsgICAgNS4xMDQxNzBdIGF0YTE6IFNB
VEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgIDUuMTA0MjMwXSBhdGE1
OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkKWyAgICA1LjExMTkxMF0g
YXRhNDogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAgNS4xMTE5
OTRdIGF0YTI6IFNBVEEgbGluayB1cCA2LjAgR2JwcyAoU1N0YXR1cyAxMzMgU0NvbnRyb2wgMzAw
KQpbICAgIDUuMTEyMzA0XSBhdGEyLjAwOiBBVEEtODogSU5URUwgU1NEU0MyTUgxMjBBMiwgUFBH
NCwgbWF4IFVETUEvMTMzClsgICAgNS4xMTIzNTVdIGF0YTIuMDA6IDIzNDQ0MTY0OCBzZWN0b3Jz
LCBtdWx0aSAxNjogTEJBNDggTkNRIChkZXB0aCAzMS8zMiksIEFBClsgICAgNS4xMTI3MDNdIGF0
YTIuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzClsgICAgNS4xMTI4NTRdIHNjc2kgMTowOjA6
MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgSU5URUwgU1NEU0MyTUgxMiBQUEc0IFBROiAw
IEFOU0k6IDUKWyAgICA1LjExNjc4Ml0gc2QgMTowOjA6MDogW3NkYV0gMjM0NDQxNjQ4IDUxMi1i
eXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTIwIEdCLzExMSBHaUIpClsgICAgNS4xMTY5NTldIHNkIDE6
MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNS4xMTY5OTFdIHNkIDE6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNS4xMTcwMjZdIHNkIDE6MDow
OjA6IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBkb2Vz
bid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDUuMTE5MDcwXSAgc2RhOiBzZGExIHNkYTIgc2Rh
MwpbICAgIDUuMTE5NDgwXSBzZCAxOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAg
ICA1LjEyMzg4N10gdXNiIDMtMTogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1
c2luZyBlaGNpX2hjZApbICAgIDUuMjU2MjM1XSB1c2IgMy0xOiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9ODA4NywgaWRQcm9kdWN0PTAwMjQKWyAgICA1LjI1NjI5NF0gdXNiIDMtMTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAK
WyAgICA1LjI1NjUzNV0gaHViIDMtMToxLjA6IFVTQiBodWIgZm91bmQKWyAgICA1LjI1NjczNl0g
aHViIDMtMToxLjA6IDYgcG9ydHMgZGV0ZWN0ZWQKWyAgICA1LjMxMjI0M10gZmlyZXdpcmVfY29y
ZTogY3JlYXRlZCBkZXZpY2UgZncwOiBHVUlEIDAwOGYxMzAwNWQ2NTBmMDAsIFM0MDAKWyAgICA1
LjM2NzkwNF0gdXNiIDYtMTogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2lu
ZyBlaGNpX2hjZApbICAgIDUuMzg1ODY2XSBkZXZpY2UtbWFwcGVyOiB1ZXZlbnQ6IHZlcnNpb24g
MS4wLjMKWyAgICA1LjM4NTk3Nl0gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjIuMC1pb2N0bCAo
MjAxMS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KWyAgICA1LjUwMDIy
NV0gdXNiIDYtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTgwODcsIGlkUHJvZHVj
dD0wMDI0ClsgICAgNS41MDAyMzBdIHVzYiA2LTE6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0wLCBQcm9kdWN0PTAsIFNlcmlhbE51bWJlcj0wClsgICAgNS41MDA1MTJdIGh1YiA2LTE6MS4w
OiBVU0IgaHViIGZvdW5kClsgICAgNS41MDA1OTVdIGh1YiA2LTE6MS4wOiA4IHBvcnRzIGRldGVj
dGVkClsgICAgNS41NzE5NzddIHVzYiAzLTEuNDogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmljZSBu
dW1iZXIgMyB1c2luZyBlaGNpX2hjZApbICAgIDUuNjY0NzIzXSB1c2IgMy0xLjQ6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNzgxLCBpZFByb2R1Y3Q9NTU2NwpbICAgIDUuNjY0NzI3
XSB1c2IgMy0xLjQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNl
cmlhbE51bWJlcj0zClsgICAgNS42NjQ3MzFdIHVzYiAzLTEuNDogUHJvZHVjdDogQ3J1emVyIEJs
YWRlClsgICAgNS42NjQ3MzRdIHVzYiAzLTEuNDogTWFudWZhY3R1cmVyOiBTYW5EaXNrClsgICAg
NS42NjQ3MzZdIHVzYiAzLTEuNDogU2VyaWFsTnVtYmVyOiAyMDA1MTUzNTgyMThCNUEzM0NCRQpb
ICAgIDUuNjY3MDYyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVh
cwpbICAgIDUuNjY3NzcxXSBJbml0aWFsaXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4K
WyAgICA1LjY2Nzg4OF0gc2NzaTggOiB1c2Itc3RvcmFnZSAzLTEuNDoxLjAKWyAgICA1LjY2Nzk4
NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQpb
ICAgIDUuNjY3OTg3XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KWyAgICA1
Ljc3MTk2N10gdXNiIDYtMS4xOiBuZXcgbG93LXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDMgdXNp
bmcgZWhjaV9oY2QKWyAgICA1Ljg4MjExNV0gdXNiIDYtMS4xOiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9MDRkOSwgaWRQcm9kdWN0PTIyMjEKWyAgICA1Ljg4MjExOV0gdXNiIDYtMS4x
OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MCwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9
MApbICAgIDUuODgyMTIzXSB1c2IgNi0xLjE6IFByb2R1Y3Q6IFVTQiBLZXlib2FyZApbICAgIDUu
ODk1NTMzXSBpbnB1dDogVVNCIEtleWJvYXJkIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDow
MDoxZC4wL3VzYjYvNi0xLzYtMS4xLzYtMS4xOjEuMC9pbnB1dC9pbnB1dDAKWyAgICA1Ljg5NTYw
NF0gZ2VuZXJpYy11c2IgMDAwMzowNEQ5OjIyMjEuMDAwMTogaW5wdXQsaGlkcmF3MDogVVNCIEhJ
RCB2MS4xMCBLZXlib2FyZCBbVVNCIEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDoxZC4wLTEuMS9p
bnB1dDAKWyAgICA1LjkxODYzNl0gaW5wdXQ6IFVTQiBLZXlib2FyZCBhcyAvZGV2aWNlcy9wY2kw
MDAwOjAwLzAwMDA6MDA6MWQuMC91c2I2LzYtMS82LTEuMS82LTEuMToxLjEvaW5wdXQvaW5wdXQx
ClsgICAgNS45MTg3MDhdIGdlbmVyaWMtdXNiIDAwMDM6MDREOToyMjIxLjAwMDI6IGlucHV0LGhp
ZHJhdzE6IFVTQiBISUQgdjEuMTAgRGV2aWNlIFtVU0IgS2V5Ym9hcmRdIG9uIHVzYi0wMDAwOjAw
OjFkLjAtMS4xL2lucHV0MQpbICAgIDUuOTE4NzI0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIHVzYmhpZApbICAgIDUuOTE4NzI2XSB1c2JoaWQ6IFVTQiBISUQgY29y
ZSBkcml2ZXIKWyAgICA1Ljk1MTk5MV0gdXNiIDYtMS4yOiBuZXcgZnVsbC1zcGVlZCBVU0IgZGV2
aWNlIG51bWJlciA0IHVzaW5nIGVoY2lfaGNkClsgICAgNi4wNDYzNTddIHVzYiA2LTEuMjogTmV3
IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTE1MzIsIGlkUHJvZHVjdD0wMDE1ClsgICAgNi4w
NDYzNjJdIHVzYiA2LTEuMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9
MiwgU2VyaWFsTnVtYmVyPTAKWyAgICA2LjA0NjM2Nl0gdXNiIDYtMS4yOiBQcm9kdWN0OiBSYXpl
ciBOYWdhClsgICAgNi4wNDYzNjhdIHVzYiA2LTEuMjogTWFudWZhY3R1cmVyOiBSYXplcgpbICAg
IDYuMDkyNjMwXSBpbnB1dDogUmF6ZXIgUmF6ZXIgTmFnYSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAw
LzAwMDA6MDA6MWQuMC91c2I2LzYtMS82LTEuMi82LTEuMjoxLjAvaW5wdXQvaW5wdXQyClsgICAg
Ni4wOTI3NTRdIGdlbmVyaWMtdXNiIDAwMDM6MTUzMjowMDE1LjAwMDM6IGlucHV0LGhpZHJhdzI6
IFVTQiBISUQgdjEuMTEgTW91c2UgW1JhemVyIFJhemVyIE5hZ2FdIG9uIHVzYi0wMDAwOjAwOjFk
LjAtMS4yL2lucHV0MApbICAgIDYuMDkzODE1XSBpbnB1dDogUmF6ZXIgUmF6ZXIgTmFnYSBhcyAv
ZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MWQuMC91c2I2LzYtMS82LTEuMi82LTEuMjoxLjEv
aW5wdXQvaW5wdXQzClsgICAgNi4wOTM5MzRdIGdlbmVyaWMtdXNiIDAwMDM6MTUzMjowMDE1LjAw
MDQ6IGlucHV0LGhpZHJhdzM6IFVTQiBISUQgdjEuMTEgS2V5Ym9hcmQgW1JhemVyIFJhemVyIE5h
Z2FdIG9uIHVzYi0wMDAwOjAwOjFkLjAtMS4yL2lucHV0MQpbICAgIDYuNjY4NjM3XSBzY3NpIDg6
MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIFNhbkRpc2sgIENydXplciBCbGFkZSAgICAgMS4wMCBQ
UTogMCBBTlNJOiAyClsgICAgNi42Njk5NzZdIHNkIDg6MDowOjA6IFtzZGJdIDMxMjUwNDMyIDUx
Mi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTYuMCBHQi8xNC45IEdpQikKWyAgICA2LjY3MDcyM10g
c2QgODowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA2LjY3MDcyNl0gc2Qg
ODowOjA6MDogW3NkYl0gTW9kZSBTZW5zZTogMDMgMDAgMDAgMDAKWyAgICA2LjY3MTczOV0gc2Qg
ODowOjA6MDogW3NkYl0gTm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDYuNjcxNzQ0
XSBzZCA4OjA6MDowOiBbc2RiXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaApb
ICAgIDYuNjc0NjA3XSBzZCA4OjA6MDowOiBbc2RiXSBObyBDYWNoaW5nIG1vZGUgcGFnZSBwcmVz
ZW50ClsgICAgNi42NzQ2MTFdIHNkIDg6MDowOjA6IFtzZGJdIEFzc3VtaW5nIGRyaXZlIGNhY2hl
OiB3cml0ZSB0aHJvdWdoClsgICAgNi42NzUzNzNdICBzZGI6IHNkYjEKWyAgICA2LjY3ODIxOV0g
c2QgODowOjA6MDogW3NkYl0gTm8gQ2FjaGluZyBtb2RlIHBhZ2UgcHJlc2VudApbICAgIDYuNjc4
MjIyXSBzZCA4OjA6MDowOiBbc2RiXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3Vn
aApbICAgIDYuNjc4MjI1XSBzZCA4OjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIHJlbW92YWJs
ZSBkaXNrClsgICAxMS42OTY5MThdIGFsZzogTm8gdGVzdCBmb3IgX19nY20tYWVzLWFlc25pIChf
X2RyaXZlci1nY20tYWVzLWFlc25pKQpbICAgMTEuNzAwOTc2XSBhbGc6IE5vIHRlc3QgZm9yIF9f
Y2JjLWFlcy1hZXNuaSAoY3J5cHRkKF9fZHJpdmVyLWNiYy1hZXMtYWVzbmkpKQpbICAgMTIuMjgx
NTUzXSBFWFQ0LWZzIChkbS0xKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRh
IG1vZGUuIE9wdHM6IChudWxsKQpbICAgMTIuNTE5MTAzXSB1ZGV2ZFszODNdOiBzdGFydGluZyB2
ZXJzaW9uIDE3NQpbICAgMTIuNjEzODIwXSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2Vz
L0xOWFNZU1RNOjAwL2RldmljZTowMC9QTlAwQzBDOjAwL2lucHV0L2lucHV0NApbICAgMTIuNjEz
ODg3XSBBQ1BJOiBQb3dlciBCdXR0b24gW1BXUkJdClsgICAxMi42MTM5NzFdIGlucHV0OiBQb3dl
ciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQ1
ClsgICAxMi42MTQwMjVdIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgIDEyLjY0MjA5MF0g
d21pOiBNYXBwZXIgbG9hZGVkClsgICAxMi42OTAwMzVdIFtkcm1dIEluaXRpYWxpemVkIGRybSAx
LjEuMCAyMDA2MDgxMApbICAgMTIuNzA0MDc5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNiB0cmln
Z2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgMTIuNzA0MDg1XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1
cm5pbmcgaXJxIDE2IGZvciBnc2kgMTYKWyAgIDEyLjcwNDEyNF0geGVuOiAtLT4gcGlycT0xNiAt
PiBpcnE9MTYgKGdzaT0xNikKWyAgIDEyLjcwNDEyNl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDox
NgpbICAgMTIuNzA0MTYyXSBpOTE1IDAwMDA6MDA6MDIuMDogUENJIElOVCBBIC0+IEdTSSAxNiAo
bGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAxMi43MDQyMDZdIGk5MTUgMDAwMDowMDowMi4wOiBz
ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDEyLjcwODgzOV0gcGNpX2hvdHBsdWc6IFBD
SSBIb3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUKWyAgIDEyLjc4NzYwOF0gaVRDT192ZW5k
b3Jfc3VwcG9ydDogdmVuZG9yLXN1cHBvcnQ9MApbICAgMTIuNzg5OTAxXSBpbnB1dDogUEMgU3Bl
YWtlciBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9wY3Nwa3IvaW5wdXQvaW5wdXQ2ClsgICAxMi43OTA1
ODRdIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYxLjA3ClsgICAx
Mi43OTA3MDldIGlUQ09fd2R0OiBGb3VuZCBhIENvdWdhciBQb2ludCBUQ08gZGV2aWNlIChWZXJz
aW9uPTIsIFRDT0JBU0U9MHgwNDYwKQpbICAgMTIuNzkwODI2XSBpVENPX3dkdDogaW5pdGlhbGl6
ZWQuIGhlYXJ0YmVhdD0zMCBzZWMgKG5vd2F5b3V0PTApClsgICAxMi44NDAwNDZdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAxMi44NDAwNTJdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwpbICAgMTIuODQwMDk0
XSB4ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQpbICAgMTIuODQwMDk2XSBBbHJl
YWR5IHNldHVwIHRoZSBHU0kgOjE3ClsgICAxMi44NDAxMzNdIHNuZF9oZGFfaW50ZWwgMDAwMDow
MTowMC4xOiBQQ0kgSU5UIEIgLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKWyAgIDEy
Ljg0MDM0MV0gc25kX2hkYV9pbnRlbCAwMDAwOjAxOjAwLjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1l
ciB0byA2NApbICAgMTIuODU5Mjc5XSBbZHJtXSBNVFJSIGFsbG9jYXRpb24gZmFpbGVkLiAgR3Jh
cGhpY3MgcGVyZm9ybWFuY2UgbWF5IHN1ZmZlci4KWyAgIDEyLjg2MDQ5NF0gW2RybV0gU3VwcG9y
dHMgdmJsYW5rIHRpbWVzdGFtcCBjYWNoaW5nIFJldiAxICgxMC4xMC4yMDEwKS4KWyAgIDEyLjg2
MDUzNF0gW2RybV0gRHJpdmVyIHN1cHBvcnRzIHByZWNpc2UgdmJsYW5rIHRpbWVzdGFtcCBxdWVy
eS4KWyAgIDEyLjg2MDY1NV0gdmdhYXJiOiBkZXZpY2UgY2hhbmdlZCBkZWNvZGVzOiBQQ0k6MDAw
MDowMDowMi4wLG9sZGRlY29kZXM9aW8rbWVtLGRlY29kZXM9bm9uZTpvd25zPWlvK21lbQpbICAg
MTIuODYwNzExXSB2Z2FhcmI6IHRyYW5zZmVycmluZyBvd25lciBmcm9tIFBDSTowMDAwOjAwOjAy
LjAgdG8gUENJOjAwMDA6MDE6MDAuMApbICAgMTIuODYyOTQ3XSBIRE1JIHN0YXR1czogQ29kZWM9
MCBQaW49MyBQcmVzZW5jZV9EZXRlY3Q9MCBFTERfVmFsaWQ9MApbICAgMTIuODYzMDkwXSBpbnB1
dDogSEQtQXVkaW8gR2VuZXJpYyBIRE1JL0RQLHBjbT0zIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAv
MDAwMDowMDowMS4wLzAwMDA6MDE6MDAuMS9zb3VuZC9jYXJkMC9pbnB1dDcKWyAgIDEzLjYxMjI3
Nl0gZmJjb246IGludGVsZHJtZmIgKGZiMCkgaXMgcHJpbWFyeSBkZXZpY2UKWyAgIDEzLjk2MzYz
OV0gQ29uc29sZTogc3dpdGNoaW5nIHRvIGNvbG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDI0MHg2
NwpbICAgMTMuOTY4ODA0XSBmYjA6IGludGVsZHJtZmIgZnJhbWUgYnVmZmVyIGRldmljZQpbICAg
MTMuOTY4ODA1XSBkcm06IHJlZ2lzdGVyZWQgcGFuaWMgbm90aWZpZXIKWyAgIDEzLjk2ODg2Ml0g
Tm8gQUNQSSB2aWRlbyBidXMgZm91bmQKWyAgIDEzLjk2ODk0N10gW2RybV0gSW5pdGlhbGl6ZWQg
aTkxNSAxLjYuMCAyMDA4MDczMCBmb3IgMDAwMDowMDowMi4wIG9uIG1pbm9yIDAKWyAgIDEzLjk2
OTExOF0gc2hwY2hwOiBTdGFuZGFyZCBIb3QgUGx1ZyBQQ0kgQ29udHJvbGxlciBEcml2ZXIgdmVy
c2lvbjogMC40ClsgICAxMy45NjkxNDhdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJp
bmcgMCBwb2xhcml0eSAxClsgICAxMy45NjkxNTNdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmlu
ZyBpcnEgMTggZm9yIGdzaSAxOApbICAgMTMuOTY5MTU1XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGly
cT0xOCAoZ3NpPTE4KQpbICAgMTMuOTY5MTU4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Clsg
ICAxMy45NjkxNjJdIGk4MDFfc21idXMgMDAwMDowMDoxZi4zOiBQQ0kgSU5UIEMgLT4gR1NJIDE4
IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgIDEzLjk4OTg0MF0geGVuOiByZWdpc3RlcmluZyBn
c2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgIDEzLjk4OTg0NV0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2ClsgICAxMy45ODk4ODRdIHhlbjogLS0+
IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAxMy45ODk4ODZdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MTYKWyAgIDEzLjk4OTkxM10gc25kX3ZpcnR1b3NvIDAwMDA6MDM6MDQuMDogUENJ
IElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2ClsgICAxNS40MDI2NDVdIEVY
VDQtZnMgKGRtLTEpOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkKWyAgIDE1LjQyNzcyOV0gRVhU
NC1mcyAoZG0tMSk6IHJlLW1vdW50ZWQuIE9wdHM6IHVzZXJfeGF0dHIsZXJyb3JzPXJlbW91bnQt
cm8KWyAgIDE1LjU0NTkwOV0gbG9vcDogbW9kdWxlIGxvYWRlZApbICAgMTUuODk3MDAxXSBFWFQ0
LWZzIChzZGEyKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9w
dHM6IChudWxsKQpbICAgMTYuMDEzMTY3XSBCcmlkZ2UgZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZApb
ICAgMTYuMDE4MjIzXSBkZXZpY2UgZXRoMCBlbnRlcmVkIHByb21pc2N1b3VzIG1vZGUKWyAgIDE2
LjE3NTM2OV0gQUREUkNPTkYoTkVUREVWX1VQKTogZXRoMDogbGluayBpcyBub3QgcmVhZHkKWyAg
IDE2LjE3OTU2MV0gQUREUkNPTkYoTkVUREVWX1VQKTogYnIwOiBsaW5rIGlzIG5vdCByZWFkeQpb
ICAgMTkuNTIxMDM2XSB0ZzMgMDAwMDowZDowMC4wOiBldGgwOiBMaW5rIGlzIHVwIGF0IDEwMDAg
TWJwcywgZnVsbCBkdXBsZXgKWyAgIDE5LjUyMjU5NF0gdGczIDAwMDA6MGQ6MDAuMDogZXRoMDog
RmxvdyBjb250cm9sIGlzIG9uIGZvciBUWCBhbmQgb24gZm9yIFJYClsgICAxOS41MjQxMzJdIHRn
MyAwMDAwOjBkOjAwLjA6IGV0aDA6IEVFRSBpcyBkaXNhYmxlZApbICAgMTkuNTI2MDQ0XSBBRERS
Q09ORihORVRERVZfQ0hBTkdFKTogZXRoMDogbGluayBiZWNvbWVzIHJlYWR5ClsgICAxOS41Mjc1
NzRdIGJyMDogdG9wb2xvZ3kgY2hhbmdlIGRldGVjdGVkLCBwcm9wYWdhdGluZwpbICAgMTkuNTI5
MDg5XSBicjA6IHBvcnQgMShldGgwKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlClsgICAxOS41
MzA2MDJdIGJyMDogcG9ydCAxKGV0aDApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKWyAgIDE5
LjUzMjQyOF0gQUREUkNPTkYoTkVUREVWX0NIQU5HRSk6IGJyMDogbGluayBiZWNvbWVzIHJlYWR5
ClsgICAyMi4zODY1NjVdIFJQQzogUmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNvY2tldCB0cmFuc3Bv
cnQgbW9kdWxlLgpbICAgMjIuMzg4MDE5XSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBt
b2R1bGUuClsgICAyMi4zODk0NjhdIFJQQzogUmVnaXN0ZXJlZCB0Y3AgdHJhbnNwb3J0IG1vZHVs
ZS4KWyAgIDIyLjM5MDkwOF0gUlBDOiBSZWdpc3RlcmVkIHRjcCBORlN2NC4xIGJhY2tjaGFubmVs
IHRyYW5zcG9ydCBtb2R1bGUuClsgICAyMi4zOTgxNDBdIEZTLUNhY2hlOiBMb2FkZWQKWyAgIDIy
LjQwNzEzM10gRlMtQ2FjaGU6IE5ldGZzICduZnMnIHJlZ2lzdGVyZWQgZm9yIGNhY2hpbmcKWyAg
IDIyLjQxNDI1Ml0gSW5zdGFsbGluZyBrbmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJAbW9u
YWQuc3diLmRlKS4KWyAgIDIzLjM5MDMzNV0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjE3KQpb
ICAgMjQuMTE0MTUyXSBCbHVldG9vdGg6IENvcmUgdmVyIDIuMTYKWyAgIDI0LjExNDE3Ml0gTkVU
OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAzMQpbICAgMjQuMTE0MTczXSBCbHVldG9vdGg6
IEhDSSBkZXZpY2UgYW5kIGNvbm5lY3Rpb24gbWFuYWdlciBpbml0aWFsaXplZApbICAgMjQuMTE0
MTc1XSBCbHVldG9vdGg6IEhDSSBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgIDI0LjExNDE3
Nl0gQmx1ZXRvb3RoOiBMMkNBUCBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6ZWQKWyAgIDI0LjExNDQz
NF0gQmx1ZXRvb3RoOiBTQ08gc29ja2V0IGxheWVyIGluaXRpYWxpemVkClsgICAyNC4xMjA5Nzld
IEJsdWV0b290aDogQk5FUCAoRXRoZXJuZXQgRW11bGF0aW9uKSB2ZXIgMS4zClsgICAyNC4xMjA5
ODFdIEJsdWV0b290aDogQk5FUCBmaWx0ZXJzOiBwcm90b2NvbCBtdWx0aWNhc3QKWyAgIDI0LjU2
MDQ1OF0gQmx1ZXRvb3RoOiBSRkNPTU0gVFRZIGxheWVyIGluaXRpYWxpemVkClsgICAyNC41NjA0
NjNdIEJsdWV0b290aDogUkZDT01NIHNvY2tldCBsYXllciBpbml0aWFsaXplZApbICAgMjQuNTYw
NDY0XSBCbHVldG9vdGg6IFJGQ09NTSB2ZXIgMS4xMQpbICAgMjYuMTYwNzAxXSBFdmVudC1jaGFu
bmVsIGRldmljZSBpbnN0YWxsZWQuClsgICAyNi4xOTczOTNdIFhFTkJVUzogVW5hYmxlIHRvIHJl
YWQgY3B1IHN0YXRlClsgICAyNi4xOTc1MzVdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0
YXRlClsgICAyNi45MDc4ODhdIFtkcm06aW50ZWxfZGlzYWJsZV90cmFuc2NvZGVyXSAqRVJST1Iq
IGZhaWxlZCB0byBkaXNhYmxlIHRyYW5zY29kZXIgMQpbICAgNDkuNjc0MzI3XSBGQVQtZnMgKHNk
YjEpOiB1dGY4IGlzIG5vdCBhIHJlY29tbWVuZGVkIElPIGNoYXJzZXQgZm9yIEZBVCBmaWxlc3lz
dGVtcywgZmlsZXN5c3RlbSB3aWxsIGJlIGNhc2Ugc2Vuc2l0aXZlIQpbICAgODAuNDE4ODkxXSBX
QVJOSU5HISBwb3dlci9sZXZlbCBpcyBkZXByZWNhdGVkOyB1c2UgcG93ZXIvY29udHJvbCBpbnN0
ZWFkClsgICA4MC40OTYwODhdIHVzYiAzLTEuNDogVVNCIGRpc2Nvbm5lY3QsIGRldmljZSBudW1i
ZXIgMwo=
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="xm_dmesg.txt"
Content-Disposition: attachment; filename="xm_dmesg.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxc0691

KFhFTikgWGVuIHZlcnNpb24gNC4xLjIgKERlYmlhbiA0LjEuMi0yKSAod2FsZGlAZGViaWFuLm9y
ZykgKGdjYyB2ZXJzaW9uIDQuNi4yIChEZWJpYW4gNC42LjItNikgKSBTYXQgRGVjIDEwIDE5OjU4
OjIxIFVUQyAyMDExCihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OS0xNAooWEVOKSBDb21tYW5k
IGxpbmU6IHBsYWNlaG9sZGVyIGRvbTBfbWF4X3ZjcHVzPTIgZG9tMF92Y3B1c19waW4gZG9tMF9t
ZW09ODE5Mk0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2Rl
IDgweDI1LCBmb250IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNm
ZXIgdGltZTogMSBzZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAy
IE1CUiBzaWduYXR1cmVzCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVz
CihYRU4pIFhlbi1lODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAw
MDAwMDA5ZDgwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5ZDgwMCAtIDAwMDAwMDAwMDAw
YTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAw
MDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMjAwMDAwMDAg
KHVzYWJsZSkKKFhFTikgIDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwIChyZXNl
cnZlZCkKKFhFTikgIDAwMDAwMDAwMjAyMDAwMDAgLSAwMDAwMDAwMDQwMDAwMDAwICh1c2FibGUp
CihYRU4pICAwMDAwMDAwMDQwMDAwMDAwIC0gMDAwMDAwMDA0MDIwMDAwMCAocmVzZXJ2ZWQpCihY
RU4pICAwMDAwMDAwMDQwMjAwMDAwIC0gMDAwMDAwMDA2ZWQ2ZDAwMCAodXNhYmxlKQooWEVOKSAg
MDAwMDAwMDA2ZWQ2ZDAwMCAtIDAwMDAwMDAwNmVkYmMwMDAgKEFDUEkgTlZTKQooWEVOKSAgMDAw
MDAwMDA2ZWRiYzAwMCAtIDAwMDAwMDAwNmVkYzUwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAw
MDAwNmVkYzUwMDAgLSAwMDAwMDAwMDZlZGYyMDAwIChyZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAw
NmVkZjIwMDAgLSAwMDAwMDAwMDZlZGYzMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDZlZGYz
MDAwIC0gMDAwMDAwMDA2ZWUwMzAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDZlZTAzMDAw
IC0gMDAwMDAwMDA2ZWUxMDAwMCAoQUNQSSBOVlMpCihYRU4pICAwMDAwMDAwMDZlZTEwMDAwIC0g
MDAwMDAwMDA2ZWUzODAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDZlZTM4MDAwIC0gMDAw
MDAwMDA2ZWU3YjAwMCAoQUNQSSBOVlMpCihYRU4pICAwMDAwMDAwMDZlZTdiMDAwIC0gMDAwMDAw
MDA2ZjAwMDAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDA2ZjgwMDAwMCAtIDAwMDAwMDAwN2Zh
MDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZWQxYzAwMCAtIDAwMDAwMDAwZmVkNDAw
MDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAg
KHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA0N2ZlMDAwMDAgKHVz
YWJsZSkKKFhFTikgQUNQSTogUlNEUCAwMDBGMDQ1MCwgMDAyNCAocjIgQUxBU0tBKQooWEVOKSBB
Q1BJOiBYU0RUIDZFREJDMDcwLCAwMDVDIChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgQU1J
ICAgICAxMDAxMykKKFhFTikgQUNQSTogRkFDUCA2RURDNDE1OCwgMDBGNCAocjQgQUxBU0tBICAg
IEEgTSBJICAxMDcyMDA5IEFNSSAgICAgMTAwMTMpCihYRU4pIEFDUEk6IERTRFQgNkVEQkMxNTgs
IDdGRkIgKHIyIEFMQVNLQSAgICBBIE0gSSAgICAgICAgMCBJTlRMIDIwMDUxMTE3KQooWEVOKSBB
Q1BJOiBGQUNTIDZFRTA3RjgwLCAwMDQwCihYRU4pIEFDUEk6IEFQSUMgNkVEQzQyNTAsIDAwOTIg
KHIzIEFMQVNLQSAgICBBIE0gSSAgMTA3MjAwOSBBTUkgICAgIDEwMDEzKQooWEVOKSBBQ1BJOiBT
U0RUIDZFREM0MkU4LCAwMUQ2IChyMSBBTUlDUFUgICAgIFBST0MgICAgICAgIDEgTVNGVCAgMzAw
MDAwMSkKKFhFTikgQUNQSTogTUNGRyA2RURDNDRDMCwgMDAzQyAocjEgQUxBU0tBICAgIEEgTSBJ
ICAxMDcyMDA5IE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IEFBRlQgNkVEQzQ1MDAsIDAwRDMg
KHIxIEFMQVNLQSBPRU1BQUZUICAgMTA3MjAwOSBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBI
UEVUIDZFREM0NUQ4LCAwMDM4IChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgQU1JLiAgICAg
ICAgNCkKKFhFTikgQUNQSTogRE1BUiA2RURDNDYxMCwgMDBFOCAocjEgQUxBU0tBICAgIEEgTSBJ
ICAgICAgICAxIElOVEwgICAgICAgIDEpCihYRU4pIFN5c3RlbSBSQU06IDE2MTA0TUIgKDE2NDkx
MDcya0IpCihYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCihYRU4pIEFDUEk6IDMyLzY0WCBG
QUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAtIDZlZTA3ZjgwLzAwMDAwMDAwMDAwMDAwMDAs
IHVzaW5nIDMyCihYRU4pIFByb2Nlc3NvciAjMCA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBQ
cm9jZXNzb3IgIzIgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgUHJvY2Vzc29yICM0IDY6MTAg
QVBJQyB2ZXJzaW9uIDIxCihYRU4pIFByb2Nlc3NvciAjNiA2OjEwIEFQSUMgdmVyc2lvbiAyMQoo
WEVOKSBQcm9jZXNzb3IgIzEgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgUHJvY2Vzc29yICMz
IDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIFByb2Nlc3NvciAjNSA2OjEwIEFQSUMgdmVyc2lv
biAyMQooWEVOKSBQcm9jZXNzb3IgIzcgNjoxMCBBUElDIHZlcnNpb24gMjEKKFhFTikgSU9BUElD
WzBdOiBhcGljX2lkIDAsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMK
KFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDEgSS9PIEFQSUNzCihYRU4p
IFRhYmxlIGlzIG5vdCBmb3VuZCEKKFhFTikgU3dpdGNoZWQgdG8gQVBJQyBkcml2ZXIgeDJhcGlj
X2NsdXN0ZXIuCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNy
ZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMzM5Mi4zNzYgTUh6IHByb2Nlc3Nvci4KKFhFTikgSW5pdGlu
ZyBtZW1vcnkgc2hhcmluZy4KKFhFTikgSW50ZWwgVlQtZCBTbm9vcCBDb250cm9sIG5vdCBlbmFi
bGVkLgooWEVOKSBJbnRlbCBWVC1kIERvbTAgRE1BIFBhc3N0aHJvdWdoIG5vdCBlbmFibGVkLgoo
WEVOKSBJbnRlbCBWVC1kIFF1ZXVlZCBJbnZhbGlkYXRpb24gZW5hYmxlZC4KKFhFTikgSW50ZWwg
VlQtZCBJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuYWJsZWQuCihYRU4pIEludGVsIFZULWQgU2hhcmVk
IEVQVCB0YWJsZXMgbm90IGVuYWJsZWQuCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVk
CihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZAooWEVOKSBFbmFibGVkIGRpcmVjdGVkIEVPSSB3
aXRoIGlvYXBpY19hY2tfb2xkIG9uIQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKKFhFTikg
IC0+IFVzaW5nIG9sZCBBQ0sgbWV0aG9kCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1I
eiBIUEVUCihYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgMTYgS2lCLgooWEVOKSBWTVg6
IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2VzcyB2
aXJ0dWFsaXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gRXh0ZW5kZWQg
UGFnZSBUYWJsZXMgKEVQVCkKKFhFTikgIC0gVmlydHVhbC1Qcm9jZXNzb3IgSWRlbnRpZmllcnMg
KFZQSUQpCihYRU4pICAtIFZpcnR1YWwgTk1JCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNzIGJp
dG1hcAooWEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vlc3QKKFhFTikgRVBUIHN1cHBvcnRzIDJNQiBz
dXBlciBwYWdlLgooWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCihYRU4pIEhWTTogVk1YIGVuYWJs
ZWQKKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgZGV0ZWN0ZWQuCihYRU4pIEJy
b3VnaHQgdXAgOCBDUFVzCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVu
ICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJp
dCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDE5M2EwMDAKKFhFTikgUEhZU0lDQUwg
TUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDQ2YzAwMDAw
MC0+MDAwMDAwMDQ3MDAwMDAwMCAoMjA3MjMzNCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4p
ICBJbml0LiByYW1kaXNrOiAwMDAwMDAwNDdkZDBlMDAwLT4wMDAwMDAwNDdmZGZmZTAwCihYRU4p
IFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZm
ZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MTkzYTAwMAooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZm
ZmY4MTkzYTAwMC0+ZmZmZmZmZmY4M2EyYmUwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZm
ZmY4M2EyYzAwMC0+ZmZmZmZmZmY4NGEyYzAwMAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZm
ZmY4NGEyYzAwMC0+ZmZmZmZmZmY4NGEyYzRiNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZm
ZmY4NGEyZDAwMC0+ZmZmZmZmZmY4NGE1NjAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZm
ZmY4NGE1NjAwMC0+ZmZmZmZmZmY4NGE1NzAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZm
ZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NGMwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZm
ZmY4MTZhOTIwMAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDIgVkNQVXMKKFhFTikgU2NydWJiaW5n
IEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuCihYRU4pIFhlbiB0cmFjZSBidWZm
ZXJzOiBkaXNhYmxlZAooWEVOKSBTdGQuIExvZ2xldmVsOiBFcnJvcnMgYW5kIHdhcm5pbmdzCihY
RU4pIEd1ZXN0IExvZ2xldmVsOiBOb3RoaW5nIChSYXRlLWxpbWl0ZWQ6IEVycm9ycyBhbmQgd2Fy
bmluZ3MpCihYRU4pIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSAqKiog
U2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNo
IGlucHV0IHRvIFhlbikKKFhFTikgRnJlZWQgMjE2a0IgaW5pdCBtZW1vcnkuCihYRU4pIHBoeXNk
ZXYuYzoxNTU6IGRvbTA6IHdyb25nIG1hcF9waXJxIHR5cGUgMwo=
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="xm_info.txt"
Content-Disposition: attachment; filename="xm_info.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxc7bs2

aG9zdCAgICAgICAgICAgICAgICAgICA6IG11YWRkaWIKcmVsZWFzZSAgICAgICAgICAgICAgICA6
IDMuMi4wLTEtYW1kNjQKdmVyc2lvbiAgICAgICAgICAgICAgICA6ICMxIFNNUCBTdW4gRmViIDUg
MTU6MTc6MTUgVVRDIDIwMTIKbWFjaGluZSAgICAgICAgICAgICAgICA6IHg4Nl82NApucl9jcHVz
ICAgICAgICAgICAgICAgIDogOApucl9ub2RlcyAgICAgICAgICAgICAgIDogMQpjb3Jlc19wZXJf
c29ja2V0ICAgICAgIDogNAp0aHJlYWRzX3Blcl9jb3JlICAgICAgIDogMgpjcHVfbWh6ICAgICAg
ICAgICAgICAgIDogMzM5Mgpod19jYXBzICAgICAgICAgICAgICAgIDogYmZlYmZiZmY6MjgxMDA4
MDA6MDAwMDAwMDA6MDAwMDNmNDA6MTNiYWUzZmY6MDAwMDAwMDA6MDAwMDAwMDE6MDAwMDAwMDAK
dmlydF9jYXBzICAgICAgICAgICAgICA6IGh2bSBodm1fZGlyZWN0aW8KdG90YWxfbWVtb3J5ICAg
ICAgICAgICA6IDE2MTA0CmZyZWVfbWVtb3J5ICAgICAgICAgICAgOiAxMDAyMgpmcmVlX2NwdXMg
ICAgICAgICAgICAgIDogMAp4ZW5fbWFqb3IgICAgICAgICAgICAgIDogNAp4ZW5fbWlub3IgICAg
ICAgICAgICAgIDogMQp4ZW5fZXh0cmEgICAgICAgICAgICAgIDogLjIKeGVuX2NhcHMgICAgICAg
ICAgICAgICA6IHhlbi0zLjAteDg2XzY0IHhlbi0zLjAteDg2XzMycCBodm0tMy4wLXg4Nl8zMiBo
dm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14ODZfNjQgCnhlbl9zY2hlZHVsZXIgICAgICAgICAgOiBj
cmVkaXQKeGVuX3BhZ2VzaXplICAgICAgICAgICA6IDQwOTYKcGxhdGZvcm1fcGFyYW1zICAgICAg
ICA6IHZpcnRfc3RhcnQ9MHhmZmZmODAwMDAwMDAwMDAwCnhlbl9jaGFuZ2VzZXQgICAgICAgICAg
OiB1bmF2YWlsYWJsZQp4ZW5fY29tbWFuZGxpbmUgICAgICAgIDogcGxhY2Vob2xkZXIgZG9tMF9t
YXhfdmNwdXM9MiBkb20wX3ZjcHVzX3BpbiBkb20wX21lbT04MTkyTQpjY19jb21waWxlciAgICAg
ICAgICAgIDogZ2NjIHZlcnNpb24gNC42LjIgKERlYmlhbiA0LjYuMi02KSAKY2NfY29tcGlsZV9i
eSAgICAgICAgICA6IHdhbGRpCmNjX2NvbXBpbGVfZG9tYWluICAgICAgOiBkZWJpYW4ub3JnCmNj
X2NvbXBpbGVfZGF0ZSAgICAgICAgOiBTYXQgRGVjIDEwIDE5OjU4OjIxIFVUQyAyMDExCnhlbmRf
Y29uZmlnX2Zvcm1hdCAgICAgOiA0Cg==
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset=US-ASCII; name="xm_list.txt"
Content-Disposition: attachment; filename="xm_list.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyyxca7r3

TmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAgIE1lbSBWQ1BV
cyAgICAgIFN0YXRlICAgVGltZShzKQpEb21haW4tMCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwICA1ODY2ICAgICAyICAgICByLS0tLS0gICAgMTE3LjAK
--bcaec54faf688f7e2504b994eb2f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bcaec54faf688f7e2504b994eb2f--


From xen-devel-bounces@lists.xen.org Wed Feb 22 22:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 22: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 1S0Krj-0006rQ-Lg; Wed, 22 Feb 2012 22:40:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henrik@fixme.se>) id 1S0Kri-0006rI-GJ
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 22:40:50 +0000
X-Env-Sender: henrik@fixme.se
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329950443!10309701!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18128 invoked from network); 22 Feb 2012 22:40:44 -0000
Received: from mail-vw0-f45.google.com (HELO mail-vw0-f45.google.com)
	(209.85.212.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 22:40:44 -0000
Received: by vbal1 with SMTP id l1so536484vba.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:40:42 -0800 (PST)
Received-SPF: pass (google.com: domain of henrik@fixme.se designates
	10.220.209.200 as permitted sender) client-ip=10.220.209.200; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of henrik@fixme.se
	designates 10.220.209.200 as permitted sender)
	smtp.mail=henrik@fixme.se
Received: from mr.google.com ([10.220.209.200])
	by 10.220.209.200 with SMTP id gh8mr7139780vcb.55.1329950442624
	(num_hops = 1); Wed, 22 Feb 2012 14:40:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.209.200 with SMTP id gh8mr5886333vcb.55.1329950442252;
	Wed, 22 Feb 2012 14:40:42 -0800 (PST)
Received: by 10.220.198.133 with HTTP; Wed, 22 Feb 2012 14:40:42 -0800 (PST)
In-Reply-To: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
Date: Wed, 22 Feb 2012 23:40:42 +0100
Message-ID: <CAA_XowPjofdnHpyoXX4xeGPAB9Zy=xNOOKyO2SK_Fj_=pJA+xw@mail.gmail.com>
From: Henrik Olsson <henrik@fixme.se>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQkzR4JUxAq5DvpyAm9+KV3DzSZRQITXV6lFIGrCcSvxLdAVw9Jv41BsPJh9NcBGAZFRv8gi
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 22, 2012 at 23:19, Henrik Olsson <henrik@fixme.se> wrote:
> Hi, i'm having some trouble with assigning memory to my dom0.
>
> I've added "dom0_mem=8192M" to the xen command line yet "free -m"
> reports only 5686MB total.
>
> Running Xen 4.1.2 with kernel 3.2.0-1-amd64, debian testing.
>
> Attached are the outputs of dmesg, xm dmesg, xm info and xm list.
>
> Regards,
> Henrik Olsson

Forgot to mention, issuing xm mem-set changes what xm list says but not free.
root@muaddib:~# xm mem-set Domain-0 8192M
root@muaddib:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  8192     2     r-----    598.1
root@muaddib:~# free -m
             total       used       free     shared    buffers     cached
Mem:          5686       2133       3552          0         54        884

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 22 22:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 22 Feb 2012 22: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 1S0Krj-0006rQ-Lg; Wed, 22 Feb 2012 22:40:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henrik@fixme.se>) id 1S0Kri-0006rI-GJ
	for xen-devel@lists.xen.org; Wed, 22 Feb 2012 22:40:50 +0000
X-Env-Sender: henrik@fixme.se
X-Msg-Ref: server-13.tower-21.messagelabs.com!1329950443!10309701!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18128 invoked from network); 22 Feb 2012 22:40:44 -0000
Received: from mail-vw0-f45.google.com (HELO mail-vw0-f45.google.com)
	(209.85.212.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2012 22:40:44 -0000
Received: by vbal1 with SMTP id l1so536484vba.32
	for <xen-devel@lists.xen.org>; Wed, 22 Feb 2012 14:40:42 -0800 (PST)
Received-SPF: pass (google.com: domain of henrik@fixme.se designates
	10.220.209.200 as permitted sender) client-ip=10.220.209.200; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of henrik@fixme.se
	designates 10.220.209.200 as permitted sender)
	smtp.mail=henrik@fixme.se
Received: from mr.google.com ([10.220.209.200])
	by 10.220.209.200 with SMTP id gh8mr7139780vcb.55.1329950442624
	(num_hops = 1); Wed, 22 Feb 2012 14:40:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.209.200 with SMTP id gh8mr5886333vcb.55.1329950442252;
	Wed, 22 Feb 2012 14:40:42 -0800 (PST)
Received: by 10.220.198.133 with HTTP; Wed, 22 Feb 2012 14:40:42 -0800 (PST)
In-Reply-To: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
Date: Wed, 22 Feb 2012 23:40:42 +0100
Message-ID: <CAA_XowPjofdnHpyoXX4xeGPAB9Zy=xNOOKyO2SK_Fj_=pJA+xw@mail.gmail.com>
From: Henrik Olsson <henrik@fixme.se>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQkzR4JUxAq5DvpyAm9+KV3DzSZRQITXV6lFIGrCcSvxLdAVw9Jv41BsPJh9NcBGAZFRv8gi
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 22, 2012 at 23:19, Henrik Olsson <henrik@fixme.se> wrote:
> Hi, i'm having some trouble with assigning memory to my dom0.
>
> I've added "dom0_mem=8192M" to the xen command line yet "free -m"
> reports only 5686MB total.
>
> Running Xen 4.1.2 with kernel 3.2.0-1-amd64, debian testing.
>
> Attached are the outputs of dmesg, xm dmesg, xm info and xm list.
>
> Regards,
> Henrik Olsson

Forgot to mention, issuing xm mem-set changes what xm list says but not free.
root@muaddib:~# xm mem-set Domain-0 8192M
root@muaddib:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  8192     2     r-----    598.1
root@muaddib:~# free -m
             total       used       free     shared    buffers     cached
Mem:          5686       2133       3552          0         54        884

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 05:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 05: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 1S0RQU-0006Kk-5S; Thu, 23 Feb 2012 05:41:10 +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 1S0RQS-0006Kf-QD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 05:41:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329975631!57881325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDUyOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8028 invoked from network); 23 Feb 2012 05:40:31 -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;
	23 Feb 2012 05:40:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,468,1325462400"; d="scan'208";a="10885667"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 05:41:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 05:41:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0RQL-00061L-VN;
	Thu, 23 Feb 2012 05:41:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0RQL-0008Vq-Uy;
	Thu, 23 Feb 2012 05:41:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12024-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 05:41:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12024: 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 12024 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12024/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  a4d93d0e0df2
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4d93d0e0df2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a4d93d0e0df2
+ branch=xen-unstable
+ revision=a4d93d0e0df2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4d93d0e0df2 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 54 changes to 47 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 05:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 05: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 1S0RQU-0006Kk-5S; Thu, 23 Feb 2012 05:41:10 +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 1S0RQS-0006Kf-QD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 05:41:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1329975631!57881325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDUyOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8028 invoked from network); 23 Feb 2012 05:40:31 -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;
	23 Feb 2012 05:40:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,468,1325462400"; d="scan'208";a="10885667"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 05:41:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 05:41:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0RQL-00061L-VN;
	Thu, 23 Feb 2012 05:41:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0RQL-0008Vq-Uy;
	Thu, 23 Feb 2012 05:41:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12024-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 05:41:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12024: 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 12024 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12024/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12003

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  a4d93d0e0df2
baseline version:
 xen                  a88ba599add1

------------------------------------------------------------
People who touched revisions under test:
  Bamvor Jian Zhang <bjzhang@suse.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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a4d93d0e0df2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a4d93d0e0df2
+ branch=xen-unstable
+ revision=a4d93d0e0df2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a4d93d0e0df2 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 54 changes to 47 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnr-0006yU-KE; Thu, 23 Feb 2012 06:05:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnp-0006xt-Hq
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:17 +0000
Received: from [85.158.139.83:20779] by server-8.bemta-5.messagelabs.com id
	45/D0-09797-C17D54F4; Thu, 23 Feb 2012 06:05:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329977114!15707761!2
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17028 invoked from network); 23 Feb 2012 06:05:15 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:15 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5156045807B;
	Wed, 22 Feb 2012 22:05:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=amojlYJkrh2yKlPLpkpOVA8P75dgJkEYzo7QV5mKO5A3
	OSpVg9IA4rjrLxsvNQXJ2I3KW1HVa53Kmncxe7gp9nQYXgmi+TXeuLojNJ4/yaRg
	mnBXJFyoDonKcrXD9/AQowh0oj01uJX90mm/yi3J4krQ+sjo1+Y0Z9+39Mw7JMk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=wIP28E8SOTZpRioOWpzY9JQDoSY=; b=r/VfQpdvv2u
	dyapC5wTmgjLUZZDoCtFi4Y788mrTAF6a6h8rC1uxh+aFmUjeFkxQguvuhGnI22p
	8gl1FuCn7tMp1jx9oZrNM5Pnhv72MEheTzPf4SvAcyqvM+kf4Rgg56wmK1Ljwbs9
	jVjU68xrfz5YDlHedJDQieR0YhiG7TcU=
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 83A79458079; 
	Wed, 22 Feb 2012 22:05:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 85157ed138a9a8e1be48451748dd3f4a76718118
Message-Id: <85157ed138a9a8e1be48.1329977109@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 7] x86/mm: wire up sharing 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

 xen/arch/x86/mm/mem_event.c |  41 +++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h |  20 +++++++++++++++++++-
 xen/include/xen/sched.h     |   3 +++
 3 files changed, 63 insertions(+), 1 deletions(-)


Now that we have an interface close to finalizing, do the necessary plumbing to
set up a ring for reporting failed allocations in the unshare path.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 0e79f8005b6b -r 85157ed138a9 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -432,6 +432,13 @@ static void mem_access_notification(stru
         p2m_mem_access_resume(v->domain);
 }
 
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_sharing_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->mem_event->share.ring_page != NULL) )
+        mem_sharing_sharing_resume(v->domain);
+}
+
 struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
 {
     struct domain *d;
@@ -599,6 +606,40 @@ int mem_event_domctl(struct domain *d, x
     }
     break;
 
+    case XEN_DOMCTL_MEM_EVENT_OP_SHARING: 
+    {
+        struct mem_event_domain *med = &d->mem_event->share;
+        rc = -EINVAL;
+
+        switch( mec->op )
+        {
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE:
+        {
+            rc = -ENODEV;
+            /* Only HAP is supported */
+            if ( !hap_enabled(d) )
+                break;
+
+            rc = mem_event_enable(d, mec, med, _VPF_mem_sharing, 
+                                    HVM_PARAM_SHARING_RING_PFN,
+                                    mem_sharing_notification);
+        }
+        break;
+
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE:
+        {
+            if ( med->ring_page )
+                rc = mem_event_disable(d, med);
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+
     default:
         rc = -ENOSYS;
     }
diff -r 0e79f8005b6b -r 85157ed138a9 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -710,7 +710,7 @@ struct xen_domctl_gdbsx_domstatus {
 /* XEN_DOMCTL_mem_event_op */
 
 /*
-* Domain memory paging
+ * Domain memory paging
  * Page memory in and out.
  * Domctl interface to set up and tear down the 
  * pager<->hypervisor interface. Use XENMEM_paging_op*
@@ -740,6 +740,24 @@ struct xen_domctl_gdbsx_domstatus {
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
 
+/*
+ * Sharing ENOMEM helper.
+ *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
+ * If setup, this ring is used to communicate failed allocations
+ * in the unshare path. XENMEM_sharing_op_resume is used to wake up
+ * vcpus that could not unshare.
+ *
+ * Note that shring can be turned on (as per the domctl below)
+ * *without* this ring being setup.
+ */
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING           3
+
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE    0
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE   1
+
 /* Use for teardown/setup of helper<->hypervisor interface for paging, 
  * access and sharing.*/
 struct xen_domctl_mem_event_op {
diff -r 0e79f8005b6b -r 85157ed138a9 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -643,6 +643,9 @@ static inline struct domain *next_domain
  /* VCPU is blocked due to missing mem_access ring. */
 #define _VPF_mem_access      5
 #define VPF_mem_access       (1UL<<_VPF_mem_access)
+ /* VCPU is blocked due to missing mem_sharing ring. */
+#define _VPF_mem_sharing     6
+#define VPF_mem_sharing      (1UL<<_VPF_mem_sharing)
 
 static inline int vcpu_runnable(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 Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnr-0006yU-KE; Thu, 23 Feb 2012 06:05:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnp-0006xt-Hq
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:17 +0000
Received: from [85.158.139.83:20779] by server-8.bemta-5.messagelabs.com id
	45/D0-09797-C17D54F4; Thu, 23 Feb 2012 06:05:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329977114!15707761!2
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17028 invoked from network); 23 Feb 2012 06:05:15 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:15 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5156045807B;
	Wed, 22 Feb 2012 22:05:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=amojlYJkrh2yKlPLpkpOVA8P75dgJkEYzo7QV5mKO5A3
	OSpVg9IA4rjrLxsvNQXJ2I3KW1HVa53Kmncxe7gp9nQYXgmi+TXeuLojNJ4/yaRg
	mnBXJFyoDonKcrXD9/AQowh0oj01uJX90mm/yi3J4krQ+sjo1+Y0Z9+39Mw7JMk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=wIP28E8SOTZpRioOWpzY9JQDoSY=; b=r/VfQpdvv2u
	dyapC5wTmgjLUZZDoCtFi4Y788mrTAF6a6h8rC1uxh+aFmUjeFkxQguvuhGnI22p
	8gl1FuCn7tMp1jx9oZrNM5Pnhv72MEheTzPf4SvAcyqvM+kf4Rgg56wmK1Ljwbs9
	jVjU68xrfz5YDlHedJDQieR0YhiG7TcU=
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 83A79458079; 
	Wed, 22 Feb 2012 22:05:14 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 85157ed138a9a8e1be48451748dd3f4a76718118
Message-Id: <85157ed138a9a8e1be48.1329977109@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 7] x86/mm: wire up sharing 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

 xen/arch/x86/mm/mem_event.c |  41 +++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h |  20 +++++++++++++++++++-
 xen/include/xen/sched.h     |   3 +++
 3 files changed, 63 insertions(+), 1 deletions(-)


Now that we have an interface close to finalizing, do the necessary plumbing to
set up a ring for reporting failed allocations in the unshare path.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 0e79f8005b6b -r 85157ed138a9 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -432,6 +432,13 @@ static void mem_access_notification(stru
         p2m_mem_access_resume(v->domain);
 }
 
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_sharing_notification(struct vcpu *v, unsigned int port)
+{
+    if ( likely(v->domain->mem_event->share.ring_page != NULL) )
+        mem_sharing_sharing_resume(v->domain);
+}
+
 struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
 {
     struct domain *d;
@@ -599,6 +606,40 @@ int mem_event_domctl(struct domain *d, x
     }
     break;
 
+    case XEN_DOMCTL_MEM_EVENT_OP_SHARING: 
+    {
+        struct mem_event_domain *med = &d->mem_event->share;
+        rc = -EINVAL;
+
+        switch( mec->op )
+        {
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE:
+        {
+            rc = -ENODEV;
+            /* Only HAP is supported */
+            if ( !hap_enabled(d) )
+                break;
+
+            rc = mem_event_enable(d, mec, med, _VPF_mem_sharing, 
+                                    HVM_PARAM_SHARING_RING_PFN,
+                                    mem_sharing_notification);
+        }
+        break;
+
+        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE:
+        {
+            if ( med->ring_page )
+                rc = mem_event_disable(d, med);
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+            break;
+        }
+    }
+    break;
+
     default:
         rc = -ENOSYS;
     }
diff -r 0e79f8005b6b -r 85157ed138a9 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -710,7 +710,7 @@ struct xen_domctl_gdbsx_domstatus {
 /* XEN_DOMCTL_mem_event_op */
 
 /*
-* Domain memory paging
+ * Domain memory paging
  * Page memory in and out.
  * Domctl interface to set up and tear down the 
  * pager<->hypervisor interface. Use XENMEM_paging_op*
@@ -740,6 +740,24 @@ struct xen_domctl_gdbsx_domstatus {
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
 
+/*
+ * Sharing ENOMEM helper.
+ *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
+ * If setup, this ring is used to communicate failed allocations
+ * in the unshare path. XENMEM_sharing_op_resume is used to wake up
+ * vcpus that could not unshare.
+ *
+ * Note that shring can be turned on (as per the domctl below)
+ * *without* this ring being setup.
+ */
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING           3
+
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE    0
+#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE   1
+
 /* Use for teardown/setup of helper<->hypervisor interface for paging, 
  * access and sharing.*/
 struct xen_domctl_mem_event_op {
diff -r 0e79f8005b6b -r 85157ed138a9 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -643,6 +643,9 @@ static inline struct domain *next_domain
  /* VCPU is blocked due to missing mem_access ring. */
 #define _VPF_mem_access      5
 #define VPF_mem_access       (1UL<<_VPF_mem_access)
+ /* VCPU is blocked due to missing mem_sharing ring. */
+#define _VPF_mem_sharing     6
+#define VPF_mem_sharing      (1UL<<_VPF_mem_sharing)
 
 static inline int vcpu_runnable(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 Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnx-000712-Qm; Thu, 23 Feb 2012 06:05:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnw-0006yI-1x
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329977116!10159543!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTg0MjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29608 invoked from network); 23 Feb 2012 06:05:17 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-12.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 06:05:17 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4FDCD45807C;
	Wed, 22 Feb 2012 22:05:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JmEMr5/RgTw/PdKq283feabguenuMlh1mgg2kRd+DOKW
	Uh/J4acCYHooBTe/04MGHOcLCSTp/6ewFlzmytSGiJ8VSZ/ot4PGWCcJSSd0sERA
	HEz4qQIXzxjgAbVBOr5Rw9toMZ/HRhfMxvGni4xYu55ffL78Mb+WtLwib2hA0/I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6PGznW/Lj5Eu7hLJBRKP8srIcQQ=; b=SpH4U/q0aVZ
	Ojh13NGH8JZ9WJ12c0P4Vpjdr2qw5kqLZqODukbth8A3Za87YGp3TkrcmQYrCkpk
	vNWfKIjh6d12B5/KVkAu4MeI/JNjXaZoVb815Keic4RsBDKCEYxDsY6oVLFywjyx
	b5Bxc7Ua0tMTbLgCmhdkGfIWMJBI4OYQ=
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 7F098458079; 
	Wed, 22 Feb 2012 22:05:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9c6cbbe72dc44e27a732df181a4af218d68b9465
Message-Id: <9c6cbbe72dc44e27a732.1329977110@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:10 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 7] Tools: libxc side for setting up the mem
	sharing 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

 tools/libxc/xc_memshr.c |  25 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h   |   5 +++++
 2 files changed, 30 insertions(+), 0 deletions(-)


This ring is used to report failed allocations in the unshare path.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 85157ed138a9 -r 9c6cbbe72dc4 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -42,6 +42,31 @@ int xc_memshr_control(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_ring_enable(xc_interface *xch, 
+                          domid_t domid, 
+                          uint32_t *port)
+{
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+        
+    return xc_mem_event_control(xch, domid,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
+                                port);
+}
+
+int xc_memshr_ring_disable(xc_interface *xch, 
+                           domid_t domid)
+{
+    return xc_mem_event_control(xch, domid,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
+                                NULL);
+}
+
 static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
                             xen_mem_sharing_op_t *mso)
 {
diff -r 85157ed138a9 -r 9c6cbbe72dc4 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1915,6 +1915,11 @@ int xc_mem_access_resume(xc_interface *x
 int xc_memshr_control(xc_interface *xch,
                       domid_t domid,
                       int enable);
+int xc_memshr_ring_enable(xc_interface *xch, 
+                          domid_t domid, 
+                          uint32_t *port);
+int xc_memshr_ring_disable(xc_interface *xch, 
+                           domid_t domid);
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnx-000712-Qm; Thu, 23 Feb 2012 06:05:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnw-0006yI-1x
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329977116!10159543!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTg0MjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29608 invoked from network); 23 Feb 2012 06:05:17 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-12.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 06:05:17 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4FDCD45807C;
	Wed, 22 Feb 2012 22:05:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JmEMr5/RgTw/PdKq283feabguenuMlh1mgg2kRd+DOKW
	Uh/J4acCYHooBTe/04MGHOcLCSTp/6ewFlzmytSGiJ8VSZ/ot4PGWCcJSSd0sERA
	HEz4qQIXzxjgAbVBOr5Rw9toMZ/HRhfMxvGni4xYu55ffL78Mb+WtLwib2hA0/I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=6PGznW/Lj5Eu7hLJBRKP8srIcQQ=; b=SpH4U/q0aVZ
	Ojh13NGH8JZ9WJ12c0P4Vpjdr2qw5kqLZqODukbth8A3Za87YGp3TkrcmQYrCkpk
	vNWfKIjh6d12B5/KVkAu4MeI/JNjXaZoVb815Keic4RsBDKCEYxDsY6oVLFywjyx
	b5Bxc7Ua0tMTbLgCmhdkGfIWMJBI4OYQ=
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 7F098458079; 
	Wed, 22 Feb 2012 22:05:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9c6cbbe72dc44e27a732df181a4af218d68b9465
Message-Id: <9c6cbbe72dc44e27a732.1329977110@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:10 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 7] Tools: libxc side for setting up the mem
	sharing 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

 tools/libxc/xc_memshr.c |  25 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h   |   5 +++++
 2 files changed, 30 insertions(+), 0 deletions(-)


This ring is used to report failed allocations in the unshare path.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 85157ed138a9 -r 9c6cbbe72dc4 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -42,6 +42,31 @@ int xc_memshr_control(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_ring_enable(xc_interface *xch, 
+                          domid_t domid, 
+                          uint32_t *port)
+{
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+        
+    return xc_mem_event_control(xch, domid,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
+                                port);
+}
+
+int xc_memshr_ring_disable(xc_interface *xch, 
+                           domid_t domid)
+{
+    return xc_mem_event_control(xch, domid,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_DISABLE,
+                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
+                                NULL);
+}
+
 static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
                             xen_mem_sharing_op_t *mso)
 {
diff -r 85157ed138a9 -r 9c6cbbe72dc4 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1915,6 +1915,11 @@ int xc_mem_access_resume(xc_interface *x
 int xc_memshr_control(xc_interface *xch,
                       domid_t domid,
                       int enable);
+int xc_memshr_ring_enable(xc_interface *xch, 
+                          domid_t domid, 
+                          uint32_t *port);
+int xc_memshr_ring_disable(xc_interface *xch, 
+                           domid_t domid);
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnt-0006zX-Uu; Thu, 23 Feb 2012 06:05:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnr-0006xe-S6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:20 +0000
Received: from [85.158.139.83:20865] by server-12.bemta-5.messagelabs.com id
	61/C5-24595-F17D54F4; Thu, 23 Feb 2012 06:05:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329977117!16215305!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28743 invoked from network); 23 Feb 2012 06:05:18 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-11.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:18 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4005C45807B;
	Wed, 22 Feb 2012 22:05:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Cl/6PDjvs13P5HyJBiycgnxJhLj2aY8GiI9lDptw6HX5
	RXU3mvYg0+ZzGFonrVLL42fLl9xyEn8rXoqYj/nCYcHn+pSGWcJLJAXINI6jVKEh
	0+G46cPRA1X1yhdaY66t1t0NZ6AqhA9bt1qC81/LIWBQIo3/JXdOj9u2roBy3F4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=WuOTXlZBc/YrOeMhN0yHg8zA3oc=; b=mJ6ue+6t/cd
	Kl1t+tF2GAOc+G7siIJGQAE7PGpNZgV0j2Wag9KFntQqrZN6rjJdl/z++3JBj/2r
	MwG4wt85WqXyBbUMOzI15A60+t/KWNWUlb+ExbK550jbSLsflVqSKwMa3ou6iKJy
	BYgR+SAEkmsQESnIlKi/t1bzLX60rlD0=
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 7D3D9458079; 
	Wed, 22 Feb 2012 22:05:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1a76b2f7641bec1dba820e9261eb426851d9bec4
Message-Id: <1a76b2f7641bec1dba82.1329977111@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 7] x86/mm: Clean up mem event structures on
 domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_event.c |  11 +++++++++++
 xen/common/domain.c         |   3 +++
 xen/include/asm-arm/mm.h    |   3 ++-
 xen/include/asm-ia64/mm.h   |   3 ++-
 xen/include/asm-x86/mm.h    |   2 ++
 5 files changed, 20 insertions(+), 2 deletions(-)


Otherwise we wind up with zombie domains, still holding onto refs to the mem
event ring pages.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -487,6 +487,17 @@ int do_mem_event_op(int op, uint32_t dom
     return ret;
 }
 
+/* Clean up on domain destruction */
+void mem_event_cleanup(struct domain *d)
+{
+    if ( d->mem_event->paging.ring_page )
+        (void)mem_event_disable(d, &d->mem_event->paging);
+    if ( d->mem_event->access.ring_page )
+        (void)mem_event_disable(d, &d->mem_event->access);
+    if ( d->mem_event->share.ring_page )
+        (void)mem_event_disable(d, &d->mem_event->share);
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -480,6 +480,9 @@ int domain_kill(struct domain *d)
             break;
         }
         d->is_dying = DOMDYING_dead;
+        /* Mem event cleanup has to go here because the rings 
+         * have to be put before we call put_domain. */
+        mem_event_cleanup(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-arm/mm.h
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -266,7 +266,8 @@ int  get_page(struct page_info *page, st
         machine_to_phys_mapping[(mfn)] = (pfn);                \
     })
 
-#define put_gfn(d, g)   ((void)0)
+#define put_gfn(d, g)           ((void)0)
+#define mem_event_cleanup(d)    ((void)0)
 
 #define INVALID_MFN             (~0UL)
 
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -551,7 +551,8 @@ extern u64 translate_domain_pte(u64 ptev
     gmfn_to_mfn_foreign((_d), (gpfn))
 
 #define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
-#define put_gfn(d, g)   ((void)0)
+#define put_gfn(d, g)           ((void)0)
+#define mem_event_cleanup(d)    ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
 	(lookup_domain_mpa((_d), ((gpfn)<<PAGE_SHIFT), NULL) == INVALID_MFN)
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -634,6 +634,8 @@ unsigned int domain_clamp_alloc_bitsize(
 
 unsigned long domain_get_maximum_gpfn(struct domain *d);
 
+void mem_event_cleanup(struct domain *d);
+
 extern struct domain *dom_xen, *dom_io, *dom_cow;	/* for vmcoreinfo */
 
 /* Definition of an mm lock: spinlock with extra fields for debugging */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnt-0006zX-Uu; Thu, 23 Feb 2012 06:05:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnr-0006xe-S6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:20 +0000
Received: from [85.158.139.83:20865] by server-12.bemta-5.messagelabs.com id
	61/C5-24595-F17D54F4; Thu, 23 Feb 2012 06:05:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329977117!16215305!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28743 invoked from network); 23 Feb 2012 06:05:18 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-11.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:18 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4005C45807B;
	Wed, 22 Feb 2012 22:05:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Cl/6PDjvs13P5HyJBiycgnxJhLj2aY8GiI9lDptw6HX5
	RXU3mvYg0+ZzGFonrVLL42fLl9xyEn8rXoqYj/nCYcHn+pSGWcJLJAXINI6jVKEh
	0+G46cPRA1X1yhdaY66t1t0NZ6AqhA9bt1qC81/LIWBQIo3/JXdOj9u2roBy3F4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=WuOTXlZBc/YrOeMhN0yHg8zA3oc=; b=mJ6ue+6t/cd
	Kl1t+tF2GAOc+G7siIJGQAE7PGpNZgV0j2Wag9KFntQqrZN6rjJdl/z++3JBj/2r
	MwG4wt85WqXyBbUMOzI15A60+t/KWNWUlb+ExbK550jbSLsflVqSKwMa3ou6iKJy
	BYgR+SAEkmsQESnIlKi/t1bzLX60rlD0=
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 7D3D9458079; 
	Wed, 22 Feb 2012 22:05:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1a76b2f7641bec1dba820e9261eb426851d9bec4
Message-Id: <1a76b2f7641bec1dba82.1329977111@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 7] x86/mm: Clean up mem event structures on
 domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_event.c |  11 +++++++++++
 xen/common/domain.c         |   3 +++
 xen/include/asm-arm/mm.h    |   3 ++-
 xen/include/asm-ia64/mm.h   |   3 ++-
 xen/include/asm-x86/mm.h    |   2 ++
 5 files changed, 20 insertions(+), 2 deletions(-)


Otherwise we wind up with zombie domains, still holding onto refs to the mem
event ring pages.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -487,6 +487,17 @@ int do_mem_event_op(int op, uint32_t dom
     return ret;
 }
 
+/* Clean up on domain destruction */
+void mem_event_cleanup(struct domain *d)
+{
+    if ( d->mem_event->paging.ring_page )
+        (void)mem_event_disable(d, &d->mem_event->paging);
+    if ( d->mem_event->access.ring_page )
+        (void)mem_event_disable(d, &d->mem_event->access);
+    if ( d->mem_event->share.ring_page )
+        (void)mem_event_disable(d, &d->mem_event->share);
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -480,6 +480,9 @@ int domain_kill(struct domain *d)
             break;
         }
         d->is_dying = DOMDYING_dead;
+        /* Mem event cleanup has to go here because the rings 
+         * have to be put before we call put_domain. */
+        mem_event_cleanup(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-arm/mm.h
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -266,7 +266,8 @@ int  get_page(struct page_info *page, st
         machine_to_phys_mapping[(mfn)] = (pfn);                \
     })
 
-#define put_gfn(d, g)   ((void)0)
+#define put_gfn(d, g)           ((void)0)
+#define mem_event_cleanup(d)    ((void)0)
 
 #define INVALID_MFN             (~0UL)
 
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -551,7 +551,8 @@ extern u64 translate_domain_pte(u64 ptev
     gmfn_to_mfn_foreign((_d), (gpfn))
 
 #define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
-#define put_gfn(d, g)   ((void)0)
+#define put_gfn(d, g)           ((void)0)
+#define mem_event_cleanup(d)    ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
 	(lookup_domain_mpa((_d), ((gpfn)<<PAGE_SHIFT), NULL) == INVALID_MFN)
diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -634,6 +634,8 @@ unsigned int domain_clamp_alloc_bitsize(
 
 unsigned long domain_get_maximum_gpfn(struct domain *d);
 
+void mem_event_cleanup(struct domain *d);
+
 extern struct domain *dom_xen, *dom_io, *dom_cow;	/* for vmcoreinfo */
 
 /* Definition of an mm lock: spinlock with extra fields for debugging */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnw-00070Y-D5; Thu, 23 Feb 2012 06:05:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnv-0006yT-2U
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329977077!53601790!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYzODY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29336 invoked from network); 23 Feb 2012 06:04:37 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-12.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 06:04:37 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 3D9A045807C;
	Wed, 22 Feb 2012 22:05:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=pdtI764yQVHsaiMO5n2OGxluAMtnza1/D4QLcAATGRtw
	gctMj8mf+3x+ulko8JLA6mYx77wKSuqml3R94GPvLbN0aS7IdKrHbne+EY+7pa1X
	8tvOJVY7O+XdsS28yDAEfRDyxredBw8ANHildjLNe4zXkgX2wZ62XQqLYrPzAl0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=qdnKiQDfLvB9rhNYQxGm6PTHO3E=; b=Jnno9CKxMcT
	cSa/Gyfy6kSkLERq3RnXjosezqYFCYaTRpSxrhQ9UhSwZ25L9GWs7/qx70NtrgC+
	03rCsAKKdiwjaPQNmmD6+O1xAoaTQfCngqgQ3ziq9m5tGaA4Jup1o8vVC1Z9mIiT
	PgCCo8xTwes92YxndWwoxWm7Ojffz57w=
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 6FF59458079; 
	Wed, 22 Feb 2012 22:05:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 642df88bf5a01e59469824c1acbd9f4199500428
Message-Id: <642df88bf5a01e594698.1329977112@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 7] x86/mm: Fix mem event error message typos
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_event.c |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1a76b2f7641b -r 642df88bf5a0 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -505,13 +505,13 @@ int mem_event_domctl(struct domain *d, x
 
     if ( unlikely(d == current->domain) )
     {
-        gdprintk(XENLOG_INFO, "Tried to do a memory paging op on itself.\n");
+        gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
         return -EINVAL;
     }
 
     if ( unlikely(d->is_dying) )
     {
-        gdprintk(XENLOG_INFO, "Ignoring memory paging op on dying domain %u\n",
+        gdprintk(XENLOG_INFO, "Ignoring memory event op on dying domain %u\n",
                  d->domain_id);
         return 0;
     }
@@ -519,7 +519,7 @@ int mem_event_domctl(struct domain *d, x
     if ( unlikely(d->vcpu == NULL) || unlikely(d->vcpu[0] == NULL) )
     {
         gdprintk(XENLOG_INFO,
-                 "Memory paging op on a domain (%u) with no vcpus\n",
+                 "Memory event op on a domain (%u) with no vcpus\n",
                  d->domain_id);
         return -EINVAL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnw-00070Y-D5; Thu, 23 Feb 2012 06:05:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnv-0006yT-2U
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329977077!53601790!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTYzODY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29336 invoked from network); 23 Feb 2012 06:04:37 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-12.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 06:04:37 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 3D9A045807C;
	Wed, 22 Feb 2012 22:05:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=pdtI764yQVHsaiMO5n2OGxluAMtnza1/D4QLcAATGRtw
	gctMj8mf+3x+ulko8JLA6mYx77wKSuqml3R94GPvLbN0aS7IdKrHbne+EY+7pa1X
	8tvOJVY7O+XdsS28yDAEfRDyxredBw8ANHildjLNe4zXkgX2wZ62XQqLYrPzAl0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=qdnKiQDfLvB9rhNYQxGm6PTHO3E=; b=Jnno9CKxMcT
	cSa/Gyfy6kSkLERq3RnXjosezqYFCYaTRpSxrhQ9UhSwZ25L9GWs7/qx70NtrgC+
	03rCsAKKdiwjaPQNmmD6+O1xAoaTQfCngqgQ3ziq9m5tGaA4Jup1o8vVC1Z9mIiT
	PgCCo8xTwes92YxndWwoxWm7Ojffz57w=
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 6FF59458079; 
	Wed, 22 Feb 2012 22:05:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 642df88bf5a01e59469824c1acbd9f4199500428
Message-Id: <642df88bf5a01e594698.1329977112@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 7] x86/mm: Fix mem event error message typos
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/arch/x86/mm/mem_event.c |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1a76b2f7641b -r 642df88bf5a0 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -505,13 +505,13 @@ int mem_event_domctl(struct domain *d, x
 
     if ( unlikely(d == current->domain) )
     {
-        gdprintk(XENLOG_INFO, "Tried to do a memory paging op on itself.\n");
+        gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
         return -EINVAL;
     }
 
     if ( unlikely(d->is_dying) )
     {
-        gdprintk(XENLOG_INFO, "Ignoring memory paging op on dying domain %u\n",
+        gdprintk(XENLOG_INFO, "Ignoring memory event op on dying domain %u\n",
                  d->domain_id);
         return 0;
     }
@@ -519,7 +519,7 @@ int mem_event_domctl(struct domain *d, x
     if ( unlikely(d->vcpu == NULL) || unlikely(d->vcpu[0] == NULL) )
     {
         gdprintk(XENLOG_INFO,
-                 "Memory paging op on a domain (%u) with no vcpus\n",
+                 "Memory event op on a domain (%u) with no vcpus\n",
                  d->domain_id);
         return -EINVAL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnr-0006yd-W7; Thu, 23 Feb 2012 06:05:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnp-0006xm-Cv
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:17 +0000
Received: from [85.158.139.83:35154] by server-6.bemta-5.messagelabs.com id
	71/67-27305-C17D54F4; Thu, 23 Feb 2012 06:05:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329977115!16250005!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzAzOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 23 Feb 2012 06:05:15 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-3.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:15 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5607845807C;
	Wed, 22 Feb 2012 22:05:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=C7HCmqxDWmIrm4/AlprOXLhYcE0E+uLhdN/XeYMJZ9xy
	6WVzXQHacYdPBOhWs7Fj8bwuLOgKFx0dHD++3cbRf9g2eBUVs8m0Q+fY1viyb7T3
	Akg0kFBo1UzgvTGjcC6/eAfIZA7+zBsV0kU9e51BZ/Lcazp8DoBqb514GCabJBY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=5EbTnF5eesBpIOovF8qoVO51cNI=; b=k0td0dVY/6Z
	GOOAbrFT2P++Ytdk14X0NAjGHJ1BG176IIPVuaKLU6wa/Zr23XgTKFmOsNLeieSn
	eEjynqBbU3gw+TlyPaQmBW5t1m+2gBnpzj0NvivwK2zB3rFaZUST/pOS5evZYj+Y
	QEKgR2bTKgNDOFYwoUhaalJrubrobPXU=
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 68471458079; 
	Wed, 22 Feb 2012 22:05:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0e79f8005b6b68e84a0fb67c22ed06f99e34bde9
Message-Id: <0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest address
 space to store mem event rings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_domain_restore.c     |  42 ++++++++++++++++++
 tools/libxc/xc_domain_save.c        |  36 ++++++++++++++++
 tools/libxc/xc_hvm_build.c          |  21 ++++++--
 tools/libxc/xc_mem_access.c         |   6 +-
 tools/libxc/xc_mem_event.c          |   3 +-
 tools/libxc/xc_mem_paging.c         |   6 +-
 tools/libxc/xenctrl.h               |   8 +--
 tools/libxc/xg_save_restore.h       |   4 +
 tools/tests/xen-access/xen-access.c |  83 +++++++++++++++++-------------------
 tools/xenpaging/xenpaging.c         |  52 ++++++++++++++++------
 xen/arch/x86/mm/mem_event.c         |  50 ++++++++++------------
 xen/include/public/domctl.h         |   1 -
 xen/include/public/hvm/params.h     |   7 ++-
 xen/include/xen/sched.h             |   1 +
 14 files changed, 214 insertions(+), 106 deletions(-)


This solves a long-standing issue in which the pages backing these rings were
pages belonging to dom0 user-space processes. Thus, if the process would die
unexpectedly, Xen would keep posting events to a page now belonging to some
other process.

We update all API-consumers in tree (xenpaging and xen-access).

This is an API/ABI change, so please speak up if it breaks your accumptions.

The patch touches tools, hypervisor x86/hvm bits, and hypervisor x86/mm bits.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -677,6 +677,9 @@ typedef struct {
     int max_vcpu_id;
     uint64_t vcpumap;
     uint64_t identpt;
+    uint64_t paging_ring_pfn;
+    uint64_t access_ring_pfn;
+    uint64_t sharing_ring_pfn;
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
@@ -750,6 +753,39 @@ static int pagebuf_get_one(xc_interface 
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_PAGING_RING_PFN:
+        /* Skip padding 4 bytes then read the paging ring location. */
+        if ( RDEXACT(fd, &buf->paging_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->paging_ring_pfn, sizeof(uint64_t)) )
+        {
+            PERROR("error read the paging ring pfn");
+            return -1;
+        }
+        // DPRINTF("paging ring pfn address: %llx\n", buf->paging_ring_pfn);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
+    case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+        /* Skip padding 4 bytes then read the mem access ring location. */
+        if ( RDEXACT(fd, &buf->access_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->access_ring_pfn, sizeof(uint64_t)) )
+        {
+            PERROR("error read the access ring pfn");
+            return -1;
+        }
+        // DPRINTF("access ring pfn address: %llx\n", buf->access_ring_pfn);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
+    case XC_SAVE_ID_HVM_SHARING_RING_PFN:
+        /* Skip padding 4 bytes then read the sharing ring location. */
+        if ( RDEXACT(fd, &buf->sharing_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->sharing_ring_pfn, sizeof(uint64_t)) )
+        {
+            PERROR("error read the sharing ring pfn");
+            return -1;
+        }
+        // DPRINTF("sharing ring pfn address: %llx\n", buf->sharing_ring_pfn);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
         if ( RDEXACT(fd, &buf->vm86_tss, sizeof(uint32_t)) ||
@@ -1460,6 +1496,12 @@ int xc_domain_restore(xc_interface *xch,
             /* should this be deferred? does it change? */
             if ( pagebuf.identpt )
                 xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, pagebuf.identpt);
+            if ( pagebuf.paging_ring_pfn )
+                xc_set_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN, pagebuf.paging_ring_pfn);
+            if ( pagebuf.access_ring_pfn )
+                xc_set_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN, pagebuf.access_ring_pfn);
+            if ( pagebuf.sharing_ring_pfn )
+                xc_set_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN, pagebuf.sharing_ring_pfn);
             if ( pagebuf.vm86_tss )
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1639,6 +1639,42 @@ int xc_domain_save(xc_interface *xch, in
             goto out;
         }
 
+        chunk.id = XC_SAVE_ID_HVM_PAGING_RING_PFN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the paging ring pfn for guest");
+            goto out;
+        }
+
+        chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the access ring pfn for guest");
+            goto out;
+        }
+
+        chunk.id = XC_SAVE_ID_HVM_SHARING_RING_PFN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the sharing ring pfn for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_VM86_TSS;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -38,12 +38,15 @@
 #define SUPERPAGE_1GB_SHIFT   18
 #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
 
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
+#define SPECIALPAGE_PAGING   0
+#define SPECIALPAGE_ACCESS   1
+#define SPECIALPAGE_SHARING  2
+#define SPECIALPAGE_BUFIOREQ 3
+#define SPECIALPAGE_XENSTORE 4
+#define SPECIALPAGE_IOREQ    5
+#define SPECIALPAGE_IDENT_PT 6
+#define SPECIALPAGE_CONSOLE  7
+#define NR_SPECIAL_PAGES     8
 #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
 
 static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
@@ -356,6 +359,12 @@ static int setup_guest(xc_interface *xch
                      special_pfn(SPECIALPAGE_IOREQ));
     xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
                      special_pfn(SPECIALPAGE_CONSOLE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN,
+                     special_pfn(SPECIALPAGE_PAGING));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+                     special_pfn(SPECIALPAGE_ACCESS));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN,
+                     special_pfn(SPECIALPAGE_SHARING));
 
     /*
      * Identity-map page table is required for running with CR0.PG=0 when
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,7 +25,7 @@
 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page)
+                         uint32_t *port)
 {
     if ( !port )
     {
@@ -36,7 +36,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                port, ring_page);
+                                port);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -44,7 +44,7 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL);
+                                NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,7 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, uint32_t *port, void *ring_page)
+                         unsigned int mode, uint32_t *port)
 {
     DECLARE_DOMCTL;
     int rc;
@@ -33,7 +33,6 @@ int xc_mem_event_control(xc_interface *x
     domctl.domain = domain_id;
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
-    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
     
     errno = 0;
     rc = do_domctl(xch, &domctl);
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,7 +25,7 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page)
+                         uint32_t *port)
 {
     if ( !port )
     {
@@ -36,7 +36,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                port, ring_page);
+                                port);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -44,7 +44,7 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL);
+                                NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,13 +1888,12 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, uint32_t *port, void *ring_page);
+                         unsigned int mode, uint32_t *port);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
-int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page);
+int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
                            unsigned long gfn);
@@ -1905,8 +1904,7 @@ int xc_mem_paging_load(xc_interface *xch
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 
-int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page);
+int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,10 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+/* Markers for the pfn's hosting these mem event rings */
+#define XC_SAVE_ID_HVM_PAGING_RING_PFN  -15
+#define XC_SAVE_ID_HVM_ACCESS_RING_PFN  -16
+#define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -166,36 +166,13 @@ int xc_wait_for_event_or_timeout(xc_inte
  err:
     return -errno;
 }
- 
-static void *init_page(void)
-{
-    void *buffer;
-    int ret;
-
-    /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
-
-    /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
-
-    return buffer;
-
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
-}
 
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
     xenaccess_t *xenaccess;
     xc_interface *xch;
     int rc;
+    unsigned long ring_pfn, mmap_pfn;
 
     xch = xc_interface_open(NULL, NULL, 0);
     if ( !xch )
@@ -214,28 +191,42 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Set domain id */
     xenaccess->mem_event.domain_id = domain_id;
 
-    /* Initialise ring page */
-    xenaccess->mem_event.ring_page = init_page();
-    if ( xenaccess->mem_event.ring_page == NULL )
-    {
-        ERROR("Error initialising ring page");
-        goto err;
-    }
-
-
-    /* Initialise ring */
-    SHARED_RING_INIT((mem_event_sring_t *)xenaccess->mem_event.ring_page);
-    BACK_RING_INIT(&xenaccess->mem_event.back_ring,
-                   (mem_event_sring_t *)xenaccess->mem_event.ring_page,
-                   PAGE_SIZE);
-
     /* Initialise lock */
     mem_event_ring_lock_init(&xenaccess->mem_event);
 
+    /* Map the ring page */
+    xc_get_hvm_param(xch, xenaccess->mem_event.domain_id, 
+                        HVM_PARAM_ACCESS_RING_PFN, &ring_pfn);
+    mmap_pfn = ring_pfn;
+    xenaccess->mem_event.ring_page = 
+        xc_map_foreign_batch(xch, xenaccess->mem_event.domain_id, 
+                                PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+    {
+        /* Map failed, populate ring page */
+        rc = xc_domain_populate_physmap_exact(xenaccess->xc_handle, 
+                                              xenaccess->mem_event.domain_id,
+                                              1, 0, 0, &ring_pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Failed to populate ring gfn\n");
+            goto err;
+        }
+
+        mmap_pfn = ring_pfn;
+        xenaccess->mem_event.ring_page = 
+            xc_map_foreign_batch(xch, xenaccess->mem_event.domain_id, 
+                                    PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+        if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+        {
+            PERROR("Could not map the ring page\n");
+            goto err;
+        }
+    }
+
     /* Initialise Xen */
     rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id,
-                             &xenaccess->mem_event.evtchn_port,
-                             xenaccess->mem_event.ring_page);
+                             &xenaccess->mem_event.evtchn_port);
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -272,6 +263,12 @@ xenaccess_t *xenaccess_init(xc_interface
 
     xenaccess->mem_event.port = rc;
 
+    /* Initialise ring */
+    SHARED_RING_INIT((mem_event_sring_t *)xenaccess->mem_event.ring_page);
+    BACK_RING_INIT(&xenaccess->mem_event.back_ring,
+                   (mem_event_sring_t *)xenaccess->mem_event.ring_page,
+                   PAGE_SIZE);
+
     /* Get platform info */
     xenaccess->platform_info = malloc(sizeof(xc_platform_info_t));
     if ( xenaccess->platform_info == NULL )
@@ -316,8 +313,7 @@ xenaccess_t *xenaccess_init(xc_interface
     {
         if ( xenaccess->mem_event.ring_page )
         {
-            munlock(xenaccess->mem_event.ring_page, PAGE_SIZE);
-            free(xenaccess->mem_event.ring_page);
+            munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
         }
 
         free(xenaccess->platform_info);
@@ -337,6 +333,7 @@ int xenaccess_teardown(xc_interface *xch
         return 0;
 
     /* Tear down domain xenaccess in Xen */
+    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
     rc = xc_mem_access_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id);
     if ( rc != 0 )
     {
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -285,6 +285,7 @@ static struct xenpaging *xenpaging_init(
     xentoollog_logger *dbg = NULL;
     char *p;
     int rc;
+    unsigned long ring_pfn, mmap_pfn;
 
     /* Allocate memory */
     paging = calloc(1, sizeof(struct xenpaging));
@@ -341,24 +342,39 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    /* Initialise ring page */
-    paging->mem_event.ring_page = init_page();
-    if ( paging->mem_event.ring_page == NULL )
+    /* Map the ring page */
+    xc_get_hvm_param(xch, paging->mem_event.domain_id, 
+                        HVM_PARAM_PAGING_RING_PFN, &ring_pfn);
+    mmap_pfn = ring_pfn;
+    paging->mem_event.ring_page = 
+        xc_map_foreign_batch(xch, paging->mem_event.domain_id, 
+                                PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
     {
-        PERROR("Error initialising ring page");
-        goto err;
+        /* Map failed, populate ring page */
+        rc = xc_domain_populate_physmap_exact(paging->xc_handle, 
+                                              paging->mem_event.domain_id,
+                                              1, 0, 0, &ring_pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Failed to populate ring gfn\n");
+            goto err;
+        }
+
+        mmap_pfn = ring_pfn;
+        paging->mem_event.ring_page = 
+            xc_map_foreign_batch(xch, paging->mem_event.domain_id, 
+                                    PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+        if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+        {
+            PERROR("Could not map the ring page\n");
+            goto err;
+        }
     }
-
-    /* Initialise ring */
-    SHARED_RING_INIT((mem_event_sring_t *)paging->mem_event.ring_page);
-    BACK_RING_INIT(&paging->mem_event.back_ring,
-                   (mem_event_sring_t *)paging->mem_event.ring_page,
-                   PAGE_SIZE);
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             &paging->mem_event.evtchn_port, 
-                             paging->mem_event.ring_page);
+                             &paging->mem_event.evtchn_port);
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -398,6 +414,12 @@ static struct xenpaging *xenpaging_init(
 
     paging->mem_event.port = rc;
 
+    /* Initialise ring */
+    SHARED_RING_INIT((mem_event_sring_t *)paging->mem_event.ring_page);
+    BACK_RING_INIT(&paging->mem_event.back_ring,
+                   (mem_event_sring_t *)paging->mem_event.ring_page,
+                   PAGE_SIZE);
+
     /* Get max_pages from guest if not provided via cmdline */
     if ( !paging->max_pages )
     {
@@ -450,8 +472,7 @@ static struct xenpaging *xenpaging_init(
 
         if ( paging->mem_event.ring_page )
         {
-            munlock(paging->mem_event.ring_page, PAGE_SIZE);
-            free(paging->mem_event.ring_page);
+            munmap(paging->mem_event.ring_page, PAGE_SIZE);
         }
 
         free(dom_path);
@@ -477,6 +498,7 @@ static int xenpaging_teardown(struct xen
     xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */
+    munmap(paging->mem_event.ring_page, PAGE_SIZE);
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
     if ( rc != 0 )
     {
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -44,16 +44,11 @@ static int mem_event_enable(
     xen_domctl_mem_event_op_t *mec,
     struct mem_event_domain *med,
     int pause_flag,
+    int param,
     xen_event_channel_notification_t notification_fn)
 {
     int rc;
-    struct domain *dom_mem_event = current->domain;
-    struct vcpu *v = current;
-    unsigned long ring_addr = mec->ring_addr;
-    l1_pgentry_t l1e;
-    unsigned long ring_gfn = 0; /* gcc ... */
-    p2m_type_t p2mt;
-    mfn_t ring_mfn;
+    unsigned long ring_gfn = d->arch.hvm_domain.params[param];
 
     /* Only one helper at a time. If the helper crashed,
      * the ring is in an undefined state and so is the guest.
@@ -61,22 +56,18 @@ static int mem_event_enable(
     if ( med->ring_page )
         return -EBUSY;
 
-    /* Get MFN of ring page */
-    guest_get_eff_l1e(v, ring_addr, &l1e);
-    ring_gfn = l1e_get_pfn(l1e);
-    ring_mfn = get_gfn(dom_mem_event, ring_gfn, &p2mt);
-
-    if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) )
-    {
-        put_gfn(dom_mem_event, ring_gfn);
-        return -EINVAL;
-    }
+    /* The parameter defaults to zero, and it should be 
+     * set to something */
+    if ( ring_gfn == 0 )
+        return -ENOSYS;
 
     mem_event_ring_lock_init(med);
+    mem_event_ring_lock(med);
 
-    /* Map ring page */
-    med->ring_page = map_domain_page(mfn_x(ring_mfn));
-    put_gfn(dom_mem_event, ring_gfn);
+    rc = prepare_ring_for_helper(d, ring_gfn, &med->ring_pg_struct, 
+                                    &med->ring_page);
+    if ( rc < 0 )
+        goto err;
 
     /* Set the number of currently blocked vCPUs to 0. */
     med->blocked = 0;
@@ -101,11 +92,13 @@ static int mem_event_enable(
     /* Initialize the last-chance wait queue. */
     init_waitqueue_head(&med->wq);
 
+    mem_event_ring_unlock(med);
     return 0;
 
  err:
-    unmap_domain_page(med->ring_page);
-    med->ring_page = NULL;
+    destroy_ring_for_helper(&med->ring_page, 
+                            med->ring_pg_struct);
+    mem_event_ring_unlock(med);
 
     return rc;
 }
@@ -221,9 +214,6 @@ static int mem_event_disable(struct doma
 
         /* Free domU's event channel and leave the other one unbound */
         free_xen_event_channel(d->vcpu[0], med->xen_port);
-        
-        unmap_domain_page(med->ring_page);
-        med->ring_page = NULL;
 
         /* Unblock all vCPUs */
         for_each_vcpu ( d, v )
@@ -235,6 +225,8 @@ static int mem_event_disable(struct doma
             }
         }
 
+        destroy_ring_for_helper(&med->ring_page, 
+                                med->ring_pg_struct);
         mem_event_ring_unlock(med);
     }
 
@@ -549,7 +541,9 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, mem_paging_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, 
+                                    HVM_PARAM_PAGING_RING_PFN,
+                                    mem_paging_notification);
         }
         break;
 
@@ -585,7 +579,9 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med, _VPF_mem_access, mem_access_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_access, 
+                                    HVM_PARAM_ACCESS_RING_PFN,
+                                    mem_access_notification);
         }
         break;
 
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -747,7 +747,6 @@ struct xen_domctl_mem_event_op {
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
     uint32_t port;              /* OUT: event channel for ring */
-    uint64_aligned_t ring_addr; /* IN:  Virtual address of ring page */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,11 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+/* Params for the mem event rings */
+#define HVM_PARAM_PAGING_RING_PFN   27
+#define HVM_PARAM_ACCESS_RING_PFN   28
+#define HVM_PARAM_SHARING_RING_PFN  29
+
+#define HVM_NR_PARAMS          30
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -192,6 +192,7 @@ struct mem_event_domain
     unsigned char target_producers;
     /* shared ring page */
     void *ring_page;
+    struct page_info *ring_pg_struct;
     /* front-end ring */
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnr-0006yd-W7; Thu, 23 Feb 2012 06:05:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnp-0006xm-Cv
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:17 +0000
Received: from [85.158.139.83:35154] by server-6.bemta-5.messagelabs.com id
	71/67-27305-C17D54F4; Thu, 23 Feb 2012 06:05:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1329977115!16250005!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzAzOQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 23 Feb 2012 06:05:15 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-3.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:15 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 5607845807C;
	Wed, 22 Feb 2012 22:05:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=C7HCmqxDWmIrm4/AlprOXLhYcE0E+uLhdN/XeYMJZ9xy
	6WVzXQHacYdPBOhWs7Fj8bwuLOgKFx0dHD++3cbRf9g2eBUVs8m0Q+fY1viyb7T3
	Akg0kFBo1UzgvTGjcC6/eAfIZA7+zBsV0kU9e51BZ/Lcazp8DoBqb514GCabJBY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=5EbTnF5eesBpIOovF8qoVO51cNI=; b=k0td0dVY/6Z
	GOOAbrFT2P++Ytdk14X0NAjGHJ1BG176IIPVuaKLU6wa/Zr23XgTKFmOsNLeieSn
	eEjynqBbU3gw+TlyPaQmBW5t1m+2gBnpzj0NvivwK2zB3rFaZUST/pOS5evZYj+Y
	QEKgR2bTKgNDOFYwoUhaalJrubrobPXU=
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 68471458079; 
	Wed, 22 Feb 2012 22:05:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0e79f8005b6b68e84a0fb67c22ed06f99e34bde9
Message-Id: <0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest address
 space to store mem event rings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_domain_restore.c     |  42 ++++++++++++++++++
 tools/libxc/xc_domain_save.c        |  36 ++++++++++++++++
 tools/libxc/xc_hvm_build.c          |  21 ++++++--
 tools/libxc/xc_mem_access.c         |   6 +-
 tools/libxc/xc_mem_event.c          |   3 +-
 tools/libxc/xc_mem_paging.c         |   6 +-
 tools/libxc/xenctrl.h               |   8 +--
 tools/libxc/xg_save_restore.h       |   4 +
 tools/tests/xen-access/xen-access.c |  83 +++++++++++++++++-------------------
 tools/xenpaging/xenpaging.c         |  52 ++++++++++++++++------
 xen/arch/x86/mm/mem_event.c         |  50 ++++++++++------------
 xen/include/public/domctl.h         |   1 -
 xen/include/public/hvm/params.h     |   7 ++-
 xen/include/xen/sched.h             |   1 +
 14 files changed, 214 insertions(+), 106 deletions(-)


This solves a long-standing issue in which the pages backing these rings were
pages belonging to dom0 user-space processes. Thus, if the process would die
unexpectedly, Xen would keep posting events to a page now belonging to some
other process.

We update all API-consumers in tree (xenpaging and xen-access).

This is an API/ABI change, so please speak up if it breaks your accumptions.

The patch touches tools, hypervisor x86/hvm bits, and hypervisor x86/mm bits.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -677,6 +677,9 @@ typedef struct {
     int max_vcpu_id;
     uint64_t vcpumap;
     uint64_t identpt;
+    uint64_t paging_ring_pfn;
+    uint64_t access_ring_pfn;
+    uint64_t sharing_ring_pfn;
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
@@ -750,6 +753,39 @@ static int pagebuf_get_one(xc_interface 
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_PAGING_RING_PFN:
+        /* Skip padding 4 bytes then read the paging ring location. */
+        if ( RDEXACT(fd, &buf->paging_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->paging_ring_pfn, sizeof(uint64_t)) )
+        {
+            PERROR("error read the paging ring pfn");
+            return -1;
+        }
+        // DPRINTF("paging ring pfn address: %llx\n", buf->paging_ring_pfn);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
+    case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+        /* Skip padding 4 bytes then read the mem access ring location. */
+        if ( RDEXACT(fd, &buf->access_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->access_ring_pfn, sizeof(uint64_t)) )
+        {
+            PERROR("error read the access ring pfn");
+            return -1;
+        }
+        // DPRINTF("access ring pfn address: %llx\n", buf->access_ring_pfn);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
+    case XC_SAVE_ID_HVM_SHARING_RING_PFN:
+        /* Skip padding 4 bytes then read the sharing ring location. */
+        if ( RDEXACT(fd, &buf->sharing_ring_pfn, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->sharing_ring_pfn, sizeof(uint64_t)) )
+        {
+            PERROR("error read the sharing ring pfn");
+            return -1;
+        }
+        // DPRINTF("sharing ring pfn address: %llx\n", buf->sharing_ring_pfn);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
         if ( RDEXACT(fd, &buf->vm86_tss, sizeof(uint32_t)) ||
@@ -1460,6 +1496,12 @@ int xc_domain_restore(xc_interface *xch,
             /* should this be deferred? does it change? */
             if ( pagebuf.identpt )
                 xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT, pagebuf.identpt);
+            if ( pagebuf.paging_ring_pfn )
+                xc_set_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN, pagebuf.paging_ring_pfn);
+            if ( pagebuf.access_ring_pfn )
+                xc_set_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN, pagebuf.access_ring_pfn);
+            if ( pagebuf.sharing_ring_pfn )
+                xc_set_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN, pagebuf.sharing_ring_pfn);
             if ( pagebuf.vm86_tss )
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1639,6 +1639,42 @@ int xc_domain_save(xc_interface *xch, in
             goto out;
         }
 
+        chunk.id = XC_SAVE_ID_HVM_PAGING_RING_PFN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the paging ring pfn for guest");
+            goto out;
+        }
+
+        chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the access ring pfn for guest");
+            goto out;
+        }
+
+        chunk.id = XC_SAVE_ID_HVM_SHARING_RING_PFN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the sharing ring pfn for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_VM86_TSS;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_VM86_TSS,
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -38,12 +38,15 @@
 #define SUPERPAGE_1GB_SHIFT   18
 #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
 
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
+#define SPECIALPAGE_PAGING   0
+#define SPECIALPAGE_ACCESS   1
+#define SPECIALPAGE_SHARING  2
+#define SPECIALPAGE_BUFIOREQ 3
+#define SPECIALPAGE_XENSTORE 4
+#define SPECIALPAGE_IOREQ    5
+#define SPECIALPAGE_IDENT_PT 6
+#define SPECIALPAGE_CONSOLE  7
+#define NR_SPECIAL_PAGES     8
 #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
 
 static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
@@ -356,6 +359,12 @@ static int setup_guest(xc_interface *xch
                      special_pfn(SPECIALPAGE_IOREQ));
     xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
                      special_pfn(SPECIALPAGE_CONSOLE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN,
+                     special_pfn(SPECIALPAGE_PAGING));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+                     special_pfn(SPECIALPAGE_ACCESS));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN,
+                     special_pfn(SPECIALPAGE_SHARING));
 
     /*
      * Identity-map page table is required for running with CR0.PG=0 when
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,7 +25,7 @@
 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page)
+                         uint32_t *port)
 {
     if ( !port )
     {
@@ -36,7 +36,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                port, ring_page);
+                                port);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -44,7 +44,7 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL);
+                                NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,7 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, uint32_t *port, void *ring_page)
+                         unsigned int mode, uint32_t *port)
 {
     DECLARE_DOMCTL;
     int rc;
@@ -33,7 +33,6 @@ int xc_mem_event_control(xc_interface *x
     domctl.domain = domain_id;
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
-    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
     
     errno = 0;
     rc = do_domctl(xch, &domctl);
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,7 +25,7 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page)
+                         uint32_t *port)
 {
     if ( !port )
     {
@@ -36,7 +36,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                port, ring_page);
+                                port);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -44,7 +44,7 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL);
+                                NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,13 +1888,12 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, uint32_t *port, void *ring_page);
+                         unsigned int mode, uint32_t *port);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
-int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page);
+int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
                            unsigned long gfn);
@@ -1905,8 +1904,7 @@ int xc_mem_paging_load(xc_interface *xch
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 
-int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                         uint32_t *port, void *ring_page);
+int xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,10 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+/* Markers for the pfn's hosting these mem event rings */
+#define XC_SAVE_ID_HVM_PAGING_RING_PFN  -15
+#define XC_SAVE_ID_HVM_ACCESS_RING_PFN  -16
+#define XC_SAVE_ID_HVM_SHARING_RING_PFN -17
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -166,36 +166,13 @@ int xc_wait_for_event_or_timeout(xc_inte
  err:
     return -errno;
 }
- 
-static void *init_page(void)
-{
-    void *buffer;
-    int ret;
-
-    /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
-
-    /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
-
-    return buffer;
-
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
-}
 
 xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t domain_id)
 {
     xenaccess_t *xenaccess;
     xc_interface *xch;
     int rc;
+    unsigned long ring_pfn, mmap_pfn;
 
     xch = xc_interface_open(NULL, NULL, 0);
     if ( !xch )
@@ -214,28 +191,42 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Set domain id */
     xenaccess->mem_event.domain_id = domain_id;
 
-    /* Initialise ring page */
-    xenaccess->mem_event.ring_page = init_page();
-    if ( xenaccess->mem_event.ring_page == NULL )
-    {
-        ERROR("Error initialising ring page");
-        goto err;
-    }
-
-
-    /* Initialise ring */
-    SHARED_RING_INIT((mem_event_sring_t *)xenaccess->mem_event.ring_page);
-    BACK_RING_INIT(&xenaccess->mem_event.back_ring,
-                   (mem_event_sring_t *)xenaccess->mem_event.ring_page,
-                   PAGE_SIZE);
-
     /* Initialise lock */
     mem_event_ring_lock_init(&xenaccess->mem_event);
 
+    /* Map the ring page */
+    xc_get_hvm_param(xch, xenaccess->mem_event.domain_id, 
+                        HVM_PARAM_ACCESS_RING_PFN, &ring_pfn);
+    mmap_pfn = ring_pfn;
+    xenaccess->mem_event.ring_page = 
+        xc_map_foreign_batch(xch, xenaccess->mem_event.domain_id, 
+                                PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+    {
+        /* Map failed, populate ring page */
+        rc = xc_domain_populate_physmap_exact(xenaccess->xc_handle, 
+                                              xenaccess->mem_event.domain_id,
+                                              1, 0, 0, &ring_pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Failed to populate ring gfn\n");
+            goto err;
+        }
+
+        mmap_pfn = ring_pfn;
+        xenaccess->mem_event.ring_page = 
+            xc_map_foreign_batch(xch, xenaccess->mem_event.domain_id, 
+                                    PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+        if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+        {
+            PERROR("Could not map the ring page\n");
+            goto err;
+        }
+    }
+
     /* Initialise Xen */
     rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id,
-                             &xenaccess->mem_event.evtchn_port,
-                             xenaccess->mem_event.ring_page);
+                             &xenaccess->mem_event.evtchn_port);
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -272,6 +263,12 @@ xenaccess_t *xenaccess_init(xc_interface
 
     xenaccess->mem_event.port = rc;
 
+    /* Initialise ring */
+    SHARED_RING_INIT((mem_event_sring_t *)xenaccess->mem_event.ring_page);
+    BACK_RING_INIT(&xenaccess->mem_event.back_ring,
+                   (mem_event_sring_t *)xenaccess->mem_event.ring_page,
+                   PAGE_SIZE);
+
     /* Get platform info */
     xenaccess->platform_info = malloc(sizeof(xc_platform_info_t));
     if ( xenaccess->platform_info == NULL )
@@ -316,8 +313,7 @@ xenaccess_t *xenaccess_init(xc_interface
     {
         if ( xenaccess->mem_event.ring_page )
         {
-            munlock(xenaccess->mem_event.ring_page, PAGE_SIZE);
-            free(xenaccess->mem_event.ring_page);
+            munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
         }
 
         free(xenaccess->platform_info);
@@ -337,6 +333,7 @@ int xenaccess_teardown(xc_interface *xch
         return 0;
 
     /* Tear down domain xenaccess in Xen */
+    munmap(xenaccess->mem_event.ring_page, PAGE_SIZE);
     rc = xc_mem_access_disable(xenaccess->xc_handle, xenaccess->mem_event.domain_id);
     if ( rc != 0 )
     {
diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -285,6 +285,7 @@ static struct xenpaging *xenpaging_init(
     xentoollog_logger *dbg = NULL;
     char *p;
     int rc;
+    unsigned long ring_pfn, mmap_pfn;
 
     /* Allocate memory */
     paging = calloc(1, sizeof(struct xenpaging));
@@ -341,24 +342,39 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    /* Initialise ring page */
-    paging->mem_event.ring_page = init_page();
-    if ( paging->mem_event.ring_page == NULL )
+    /* Map the ring page */
+    xc_get_hvm_param(xch, paging->mem_event.domain_id, 
+                        HVM_PARAM_PAGING_RING_PFN, &ring_pfn);
+    mmap_pfn = ring_pfn;
+    paging->mem_event.ring_page = 
+        xc_map_foreign_batch(xch, paging->mem_event.domain_id, 
+                                PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+    if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
     {
-        PERROR("Error initialising ring page");
-        goto err;
+        /* Map failed, populate ring page */
+        rc = xc_domain_populate_physmap_exact(paging->xc_handle, 
+                                              paging->mem_event.domain_id,
+                                              1, 0, 0, &ring_pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Failed to populate ring gfn\n");
+            goto err;
+        }
+
+        mmap_pfn = ring_pfn;
+        paging->mem_event.ring_page = 
+            xc_map_foreign_batch(xch, paging->mem_event.domain_id, 
+                                    PROT_READ | PROT_WRITE, &mmap_pfn, 1);
+        if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
+        {
+            PERROR("Could not map the ring page\n");
+            goto err;
+        }
     }
-
-    /* Initialise ring */
-    SHARED_RING_INIT((mem_event_sring_t *)paging->mem_event.ring_page);
-    BACK_RING_INIT(&paging->mem_event.back_ring,
-                   (mem_event_sring_t *)paging->mem_event.ring_page,
-                   PAGE_SIZE);
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             &paging->mem_event.evtchn_port, 
-                             paging->mem_event.ring_page);
+                             &paging->mem_event.evtchn_port);
     if ( rc != 0 )
     {
         switch ( errno ) {
@@ -398,6 +414,12 @@ static struct xenpaging *xenpaging_init(
 
     paging->mem_event.port = rc;
 
+    /* Initialise ring */
+    SHARED_RING_INIT((mem_event_sring_t *)paging->mem_event.ring_page);
+    BACK_RING_INIT(&paging->mem_event.back_ring,
+                   (mem_event_sring_t *)paging->mem_event.ring_page,
+                   PAGE_SIZE);
+
     /* Get max_pages from guest if not provided via cmdline */
     if ( !paging->max_pages )
     {
@@ -450,8 +472,7 @@ static struct xenpaging *xenpaging_init(
 
         if ( paging->mem_event.ring_page )
         {
-            munlock(paging->mem_event.ring_page, PAGE_SIZE);
-            free(paging->mem_event.ring_page);
+            munmap(paging->mem_event.ring_page, PAGE_SIZE);
         }
 
         free(dom_path);
@@ -477,6 +498,7 @@ static int xenpaging_teardown(struct xen
     xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */
+    munmap(paging->mem_event.ring_page, PAGE_SIZE);
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
     if ( rc != 0 )
     {
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -44,16 +44,11 @@ static int mem_event_enable(
     xen_domctl_mem_event_op_t *mec,
     struct mem_event_domain *med,
     int pause_flag,
+    int param,
     xen_event_channel_notification_t notification_fn)
 {
     int rc;
-    struct domain *dom_mem_event = current->domain;
-    struct vcpu *v = current;
-    unsigned long ring_addr = mec->ring_addr;
-    l1_pgentry_t l1e;
-    unsigned long ring_gfn = 0; /* gcc ... */
-    p2m_type_t p2mt;
-    mfn_t ring_mfn;
+    unsigned long ring_gfn = d->arch.hvm_domain.params[param];
 
     /* Only one helper at a time. If the helper crashed,
      * the ring is in an undefined state and so is the guest.
@@ -61,22 +56,18 @@ static int mem_event_enable(
     if ( med->ring_page )
         return -EBUSY;
 
-    /* Get MFN of ring page */
-    guest_get_eff_l1e(v, ring_addr, &l1e);
-    ring_gfn = l1e_get_pfn(l1e);
-    ring_mfn = get_gfn(dom_mem_event, ring_gfn, &p2mt);
-
-    if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) )
-    {
-        put_gfn(dom_mem_event, ring_gfn);
-        return -EINVAL;
-    }
+    /* The parameter defaults to zero, and it should be 
+     * set to something */
+    if ( ring_gfn == 0 )
+        return -ENOSYS;
 
     mem_event_ring_lock_init(med);
+    mem_event_ring_lock(med);
 
-    /* Map ring page */
-    med->ring_page = map_domain_page(mfn_x(ring_mfn));
-    put_gfn(dom_mem_event, ring_gfn);
+    rc = prepare_ring_for_helper(d, ring_gfn, &med->ring_pg_struct, 
+                                    &med->ring_page);
+    if ( rc < 0 )
+        goto err;
 
     /* Set the number of currently blocked vCPUs to 0. */
     med->blocked = 0;
@@ -101,11 +92,13 @@ static int mem_event_enable(
     /* Initialize the last-chance wait queue. */
     init_waitqueue_head(&med->wq);
 
+    mem_event_ring_unlock(med);
     return 0;
 
  err:
-    unmap_domain_page(med->ring_page);
-    med->ring_page = NULL;
+    destroy_ring_for_helper(&med->ring_page, 
+                            med->ring_pg_struct);
+    mem_event_ring_unlock(med);
 
     return rc;
 }
@@ -221,9 +214,6 @@ static int mem_event_disable(struct doma
 
         /* Free domU's event channel and leave the other one unbound */
         free_xen_event_channel(d->vcpu[0], med->xen_port);
-        
-        unmap_domain_page(med->ring_page);
-        med->ring_page = NULL;
 
         /* Unblock all vCPUs */
         for_each_vcpu ( d, v )
@@ -235,6 +225,8 @@ static int mem_event_disable(struct doma
             }
         }
 
+        destroy_ring_for_helper(&med->ring_page, 
+                                med->ring_pg_struct);
         mem_event_ring_unlock(med);
     }
 
@@ -549,7 +541,9 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, mem_paging_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_paging, 
+                                    HVM_PARAM_PAGING_RING_PFN,
+                                    mem_paging_notification);
         }
         break;
 
@@ -585,7 +579,9 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med, _VPF_mem_access, mem_access_notification);
+            rc = mem_event_enable(d, mec, med, _VPF_mem_access, 
+                                    HVM_PARAM_ACCESS_RING_PFN,
+                                    mem_access_notification);
         }
         break;
 
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -747,7 +747,6 @@ struct xen_domctl_mem_event_op {
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
     uint32_t port;              /* OUT: event channel for ring */
-    uint64_aligned_t ring_addr; /* IN:  Virtual address of ring page */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,11 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+/* Params for the mem event rings */
+#define HVM_PARAM_PAGING_RING_PFN   27
+#define HVM_PARAM_ACCESS_RING_PFN   28
+#define HVM_PARAM_SHARING_RING_PFN  29
+
+#define HVM_NR_PARAMS          30
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
diff -r 99e6c9b9e971 -r 0e79f8005b6b xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -192,6 +192,7 @@ struct mem_event_domain
     unsigned char target_producers;
     /* shared ring page */
     void *ring_page;
+    struct page_info *ring_pg_struct;
     /* front-end ring */
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rns-0006z2-HS; Thu, 23 Feb 2012 06:05:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnr-0006xU-4b
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329977111!4139894!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4945 invoked from network); 23 Feb 2012 06:05:12 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 06:05:12 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 2BC7B45807B;
	Wed, 22 Feb 2012 22:05:11 -0800 (PST)
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=ao0WkGjGKkP9iQFEq+bjXU
	Ii0vic5RoQXkglUBY5SQVKuCexWLhuViaJ2hRa5+6foghMfY5zT6plWaTsoGACap
	P4LlW3wBCnT86fHMnb2AIzmCenUl4VXJQ5ymhg1C05yWmr/3swZPUheKkurLYdDz
	QnJHfm6T9Oem6dNVXDKjc=
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=zGx5XzOOpEFo
	MYXLubhbvscvVIo=; b=V0q1JGtNTFxADbHQv/2lDEfWEeJdnR2wx8OmviApFuLS
	hhbtwaGWvrxmCnHxbBq22RMD7XcJXqG3yPgj8UakI2f6sAskvY2drGgOBdt/tgLH
	fRT44597fPVY9iuko6T0S6yAUZYSzhGxvYQnRojN9rKZlpipaHKXIsZ1meewwuw=
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 53AD2458079; 
	Wed, 22 Feb 2012 22:05:10 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:05 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 7] Mem event ring setup interface 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

Update the interface for setting up mem event rings (for sharing, mem access or
paging).

Remove the "shared page", which was a waste of a whole page for a single event
channel port value.

More importantly, both the shared page and the ring page were dom0 user-space
process pages mapped by the hypervisor. If the dom0 process does not clean up,
the hypervisor keeps posting events (and holding a map) to a page now belonging
to another process.

Solutions proposed:
- Pass the event channel port explicitly as part of the domctl payload.
- Reserve a pfn in the guest physmap for a each mem event ring. Set/retrieve
these pfns via hvm params. Ensure they are set during build and restore, and
retrieved during save. Ensure these pages don't leak and domains are left zombie.

In all cases mem events consumers in-tree (xenpaging and xen-access) have been
updated.

Updating the interface to deal with these problems requires
backwards-incompatible changes on both the helper<->libxc and
libxc<->hypervisor interfaces.

Take advantage of the interface update to plumb setting up of the sharing ring,
which was missing.

All patches touch x86/mm hypervisor bits. Patches 1, 3 and 5 are tools patches
as well.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 tools/libxc/xc_mem_access.c         |  10 +++-
 tools/libxc/xc_mem_event.c          |  13 +++--
 tools/libxc/xc_mem_paging.c         |  10 +++-
 tools/libxc/xenctrl.h               |   6 +-
 tools/tests/xen-access/xen-access.c |  22 +--------
 tools/xenpaging/xenpaging.c         |  18 +------
 tools/xenpaging/xenpaging.h         |   2 +-
 xen/arch/x86/mm/mem_event.c         |  33 +-------------
 xen/include/public/domctl.h         |   4 +-
 xen/include/public/mem_event.h      |   4 -
 xen/include/xen/sched.h             |   2 -
 xen/arch/x86/hvm/hvm.c              |  48 ++++++++++++++++-----
 xen/include/asm-x86/hvm/hvm.h       |   7 +++
 tools/libxc/xc_domain_restore.c     |  42 ++++++++++++++++++
 tools/libxc/xc_domain_save.c        |  36 ++++++++++++++++
 tools/libxc/xc_hvm_build.c          |  21 ++++++--
 tools/libxc/xc_mem_access.c         |   6 +-
 tools/libxc/xc_mem_event.c          |   3 +-
 tools/libxc/xc_mem_paging.c         |   6 +-
 tools/libxc/xenctrl.h               |   8 +--
 tools/libxc/xg_save_restore.h       |   4 +
 tools/tests/xen-access/xen-access.c |  83 +++++++++++++++++-------------------
 tools/xenpaging/xenpaging.c         |  52 ++++++++++++++++------
 xen/arch/x86/mm/mem_event.c         |  50 ++++++++++------------
 xen/include/public/domctl.h         |   1 -
 xen/include/public/hvm/params.h     |   7 ++-
 xen/include/xen/sched.h             |   1 +
 xen/arch/x86/mm/mem_event.c         |  41 ++++++++++++++++++
 xen/include/public/domctl.h         |  20 ++++++++-
 xen/include/xen/sched.h             |   3 +
 tools/libxc/xc_memshr.c             |  25 +++++++++++
 tools/libxc/xenctrl.h               |   5 ++
 xen/arch/x86/mm/mem_event.c         |  11 ++++
 xen/common/domain.c                 |   3 +
 xen/include/asm-arm/mm.h            |   3 +-
 xen/include/asm-ia64/mm.h           |   3 +-
 xen/include/asm-x86/mm.h            |   2 +
 xen/arch/x86/mm/mem_event.c         |   6 +-
 38 files changed, 413 insertions(+), 208 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rns-0006z2-HS; Thu, 23 Feb 2012 06:05:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnr-0006xU-4b
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329977111!4139894!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTU3Njk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4945 invoked from network); 23 Feb 2012 06:05:12 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-5.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 06:05:12 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 2BC7B45807B;
	Wed, 22 Feb 2012 22:05:11 -0800 (PST)
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=ao0WkGjGKkP9iQFEq+bjXU
	Ii0vic5RoQXkglUBY5SQVKuCexWLhuViaJ2hRa5+6foghMfY5zT6plWaTsoGACap
	P4LlW3wBCnT86fHMnb2AIzmCenUl4VXJQ5ymhg1C05yWmr/3swZPUheKkurLYdDz
	QnJHfm6T9Oem6dNVXDKjc=
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=zGx5XzOOpEFo
	MYXLubhbvscvVIo=; b=V0q1JGtNTFxADbHQv/2lDEfWEeJdnR2wx8OmviApFuLS
	hhbtwaGWvrxmCnHxbBq22RMD7XcJXqG3yPgj8UakI2f6sAskvY2drGgOBdt/tgLH
	fRT44597fPVY9iuko6T0S6yAUZYSzhGxvYQnRojN9rKZlpipaHKXIsZ1meewwuw=
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 53AD2458079; 
	Wed, 22 Feb 2012 22:05:10 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:05 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 7] Mem event ring setup interface 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

Update the interface for setting up mem event rings (for sharing, mem access or
paging).

Remove the "shared page", which was a waste of a whole page for a single event
channel port value.

More importantly, both the shared page and the ring page were dom0 user-space
process pages mapped by the hypervisor. If the dom0 process does not clean up,
the hypervisor keeps posting events (and holding a map) to a page now belonging
to another process.

Solutions proposed:
- Pass the event channel port explicitly as part of the domctl payload.
- Reserve a pfn in the guest physmap for a each mem event ring. Set/retrieve
these pfns via hvm params. Ensure they are set during build and restore, and
retrieved during save. Ensure these pages don't leak and domains are left zombie.

In all cases mem events consumers in-tree (xenpaging and xen-access) have been
updated.

Updating the interface to deal with these problems requires
backwards-incompatible changes on both the helper<->libxc and
libxc<->hypervisor interfaces.

Take advantage of the interface update to plumb setting up of the sharing ring,
which was missing.

All patches touch x86/mm hypervisor bits. Patches 1, 3 and 5 are tools patches
as well.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 tools/libxc/xc_mem_access.c         |  10 +++-
 tools/libxc/xc_mem_event.c          |  13 +++--
 tools/libxc/xc_mem_paging.c         |  10 +++-
 tools/libxc/xenctrl.h               |   6 +-
 tools/tests/xen-access/xen-access.c |  22 +--------
 tools/xenpaging/xenpaging.c         |  18 +------
 tools/xenpaging/xenpaging.h         |   2 +-
 xen/arch/x86/mm/mem_event.c         |  33 +-------------
 xen/include/public/domctl.h         |   4 +-
 xen/include/public/mem_event.h      |   4 -
 xen/include/xen/sched.h             |   2 -
 xen/arch/x86/hvm/hvm.c              |  48 ++++++++++++++++-----
 xen/include/asm-x86/hvm/hvm.h       |   7 +++
 tools/libxc/xc_domain_restore.c     |  42 ++++++++++++++++++
 tools/libxc/xc_domain_save.c        |  36 ++++++++++++++++
 tools/libxc/xc_hvm_build.c          |  21 ++++++--
 tools/libxc/xc_mem_access.c         |   6 +-
 tools/libxc/xc_mem_event.c          |   3 +-
 tools/libxc/xc_mem_paging.c         |   6 +-
 tools/libxc/xenctrl.h               |   8 +--
 tools/libxc/xg_save_restore.h       |   4 +
 tools/tests/xen-access/xen-access.c |  83 +++++++++++++++++-------------------
 tools/xenpaging/xenpaging.c         |  52 ++++++++++++++++------
 xen/arch/x86/mm/mem_event.c         |  50 ++++++++++------------
 xen/include/public/domctl.h         |   1 -
 xen/include/public/hvm/params.h     |   7 ++-
 xen/include/xen/sched.h             |   1 +
 xen/arch/x86/mm/mem_event.c         |  41 ++++++++++++++++++
 xen/include/public/domctl.h         |  20 ++++++++-
 xen/include/xen/sched.h             |   3 +
 tools/libxc/xc_memshr.c             |  25 +++++++++++
 tools/libxc/xenctrl.h               |   5 ++
 xen/arch/x86/mm/mem_event.c         |  11 ++++
 xen/common/domain.c                 |   3 +
 xen/include/asm-arm/mm.h            |   3 +-
 xen/include/asm-ia64/mm.h           |   3 +-
 xen/include/asm-x86/mm.h            |   2 +
 xen/arch/x86/mm/mem_event.c         |   6 +-
 38 files changed, 413 insertions(+), 208 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnn-0006xa-Lz; Thu, 23 Feb 2012 06:05:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnm-0006xV-LV
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329977059!53915502!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25168 invoked from network); 23 Feb 2012 06:04:19 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.177) by server-5.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 06:04:19 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4555845807C;
	Wed, 22 Feb 2012 22:05:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=W430t+oZNasvw1XHStxXZlWenFqv3HaEBru6236TFbP9
	h5ykJa2kKnwgBkE8/sbLzB27R+OS0aT7J8tN1pgWyxSKogkZYtiM6yLmNNpkIFcO
	Qxs8BDtZNPYmn8/IeUw/j00LlZ9kaLYPA1p/iI4nt8RafEdG0eGtdhQZTMz+9Bs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ErfRjo6b3ik3QBFlg0dGOHnXIGM=; b=kuq6bE21SQR
	+/94L3Vhl4QY6zaEgc0TL5DJEsXHlIhcnPAh/iAEd/wBxzfjDKA8IrbvMsfmHHzE
	RAC32sfMBaHydzTtbySLdHElj5MFzIeWoRP7b9ty4hb2bkv7IQ9unfCjEWzQKROG
	9WTKvyREgW7nbmDwWgG6uq1xQtd2PYIA=
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 5B966458079; 
	Wed, 22 Feb 2012 22:05:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3b24188d8815aa5a5abbe507921dd90f2f59d025
Message-Id: <3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize mem_event/access/paging
	interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_mem_access.c         |  10 ++++++++--
 tools/libxc/xc_mem_event.c          |  13 ++++++++-----
 tools/libxc/xc_mem_paging.c         |  10 ++++++++--
 tools/libxc/xenctrl.h               |   6 +++---
 tools/tests/xen-access/xen-access.c |  22 ++++------------------
 tools/xenpaging/xenpaging.c         |  18 +++---------------
 tools/xenpaging/xenpaging.h         |   2 +-
 xen/arch/x86/mm/mem_event.c         |  33 +++------------------------------
 xen/include/public/domctl.h         |   4 ++--
 xen/include/public/mem_event.h      |   4 ----
 xen/include/xen/sched.h             |   2 --
 11 files changed, 40 insertions(+), 84 deletions(-)


Don't use the superfluous shared page, return the event channel directly as
part of the domctl struct, instead.

In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
so please voice any concerns.

Known pending issues:
- pager could die and its ring page could be used by some other process, yet
  Xen retains the mapping to it.
- use a saner interface for the paging_load buffer.

This change also affects the x86/mm bits in the hypervisor that process the
mem_event setup domctl.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, void *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,19 +24,22 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page, void *ring_page)
+                         unsigned int mode, uint32_t *port, void *ring_page)
 {
     DECLARE_DOMCTL;
+    int rc;
 
     domctl.cmd = XEN_DOMCTL_mem_event_op;
     domctl.domain = domain_id;
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
-
-    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
-    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
+    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
     
-    return do_domctl(xch, &domctl);
+    errno = 0;
+    rc = do_domctl(xch, &domctl);
+    if ( !rc && port )
+        *port = domctl.u.mem_event_op.port;
+    return rc;
 }
 
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, void *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+        
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,13 +1888,13 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page, void *ring_page);
+                         unsigned int mode, uint32_t *port, void *ring_page);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, void *ring_page);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
                            unsigned long gfn);
@@ -1906,7 +1906,7 @@ int xc_mem_paging_resume(xc_interface *x
                          unsigned long gfn);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, void *ring_page);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
diff -r 8ddd13cc783e -r 3b24188d8815 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -98,7 +98,7 @@ typedef struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
     spinlock_t ring_lock;
 } mem_event_t;
@@ -166,7 +166,7 @@ int xc_wait_for_event_or_timeout(xc_inte
  err:
     return -errno;
 }
-
+ 
 static void *init_page(void)
 {
     void *buffer;
@@ -214,14 +214,6 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Set domain id */
     xenaccess->mem_event.domain_id = domain_id;
 
-    /* Initialise shared page */
-    xenaccess->mem_event.shared_page = init_page();
-    if ( xenaccess->mem_event.shared_page == NULL )
-    {
-        ERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
     xenaccess->mem_event.ring_page = init_page();
     if ( xenaccess->mem_event.ring_page == NULL )
@@ -242,7 +234,7 @@ xenaccess_t *xenaccess_init(xc_interface
 
     /* Initialise Xen */
     rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id,
-                             xenaccess->mem_event.shared_page,
+                             &xenaccess->mem_event.evtchn_port,
                              xenaccess->mem_event.ring_page);
     if ( rc != 0 )
     {
@@ -271,7 +263,7 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
                                     xenaccess->mem_event.domain_id,
-                                    xenaccess->mem_event.shared_page->port);
+                                    xenaccess->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         ERROR("Failed to bind event channel");
@@ -322,12 +314,6 @@ xenaccess_t *xenaccess_init(xc_interface
  err:
     if ( xenaccess )
     {
-        if ( xenaccess->mem_event.shared_page )
-        {
-            munlock(xenaccess->mem_event.shared_page, PAGE_SIZE);
-            free(xenaccess->mem_event.shared_page);
-        }
-
         if ( xenaccess->mem_event.ring_page )
         {
             munlock(xenaccess->mem_event.ring_page, PAGE_SIZE);
diff -r 8ddd13cc783e -r 3b24188d8815 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -341,14 +341,6 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    /* Initialise shared page */
-    paging->mem_event.shared_page = init_page();
-    if ( paging->mem_event.shared_page == NULL )
-    {
-        PERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
     paging->mem_event.ring_page = init_page();
     if ( paging->mem_event.ring_page == NULL )
@@ -365,7 +357,7 @@ static struct xenpaging *xenpaging_init(
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             paging->mem_event.shared_page,
+                             &paging->mem_event.evtchn_port, 
                              paging->mem_event.ring_page);
     if ( rc != 0 )
     {
@@ -397,7 +389,7 @@ static struct xenpaging *xenpaging_init(
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(paging->mem_event.xce_handle,
                                     paging->mem_event.domain_id,
-                                    paging->mem_event.shared_page->port);
+                                    paging->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         PERROR("Failed to bind event channel");
@@ -452,13 +444,9 @@ static struct xenpaging *xenpaging_init(
     {
         if ( paging->xs_handle )
             xs_close(paging->xs_handle);
+
         if ( xch )
             xc_interface_close(xch);
-        if ( paging->mem_event.shared_page )
-        {
-            munlock(paging->mem_event.shared_page, PAGE_SIZE);
-            free(paging->mem_event.shared_page);
-        }
 
         if ( paging->mem_event.ring_page )
         {
diff -r 8ddd13cc783e -r 3b24188d8815 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -36,7 +36,7 @@ struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
 };
 
diff -r 8ddd13cc783e -r 3b24188d8815 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -50,12 +50,10 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
-    unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
+    unsigned long ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
     mfn_t ring_mfn;
-    mfn_t shared_mfn;
 
     /* Only one helper at a time. If the helper crashed,
      * the ring is in an undefined state and so is the guest.
@@ -66,10 +64,6 @@ static int mem_event_enable(
     /* Get MFN of ring page */
     guest_get_eff_l1e(v, ring_addr, &l1e);
     ring_gfn = l1e_get_pfn(l1e);
-    /* We're grabbing these two in an order that could deadlock
-     * dom0 if 1. it were an hvm 2. there were two concurrent
-     * enables 3. the two gfn's in each enable criss-crossed
-     * 2MB regions. Duly noted.... */
     ring_mfn = get_gfn(dom_mem_event, ring_gfn, &p2mt);
 
     if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) )
@@ -80,23 +74,9 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Get MFN of shared page */
-    guest_get_eff_l1e(v, shared_addr, &l1e);
-    shared_gfn = l1e_get_pfn(l1e);
-    shared_mfn = get_gfn(dom_mem_event, shared_gfn, &p2mt);
-
-    if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) )
-    {
-        put_gfn(dom_mem_event, ring_gfn);
-        put_gfn(dom_mem_event, shared_gfn);
-        return -EINVAL;
-    }
-
-    /* Map ring and shared pages */
+    /* Map ring page */
     med->ring_page = map_domain_page(mfn_x(ring_mfn));
-    med->shared_page = map_domain_page(mfn_x(shared_mfn));
     put_gfn(dom_mem_event, ring_gfn);
-    put_gfn(dom_mem_event, shared_gfn); 
 
     /* Set the number of currently blocked vCPUs to 0. */
     med->blocked = 0;
@@ -108,8 +88,7 @@ static int mem_event_enable(
     if ( rc < 0 )
         goto err;
 
-    ((mem_event_shared_page_t *)med->shared_page)->port = rc;
-    med->xen_port = rc;
+    med->xen_port = mec->port = rc;
 
     /* Prepare ring buffer */
     FRONT_RING_INIT(&med->front_ring,
@@ -125,9 +104,6 @@ static int mem_event_enable(
     return 0;
 
  err:
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
-
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -249,9 +225,6 @@ static int mem_event_disable(struct doma
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 
-        unmap_domain_page(med->shared_page);
-        med->shared_page = NULL;
-
         /* Unblock all vCPUs */
         for_each_vcpu ( d, v )
         {
diff -r 8ddd13cc783e -r 3b24188d8815 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -746,8 +746,8 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
-    uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
+    uint32_t port;              /* OUT: event channel for ring */
+    uint64_aligned_t ring_addr; /* IN:  Virtual address of ring page */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
diff -r 8ddd13cc783e -r 3b24188d8815 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -51,10 +51,6 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-typedef struct mem_event_shared_page {
-    uint32_t port;
-} mem_event_shared_page_t;
-
 typedef struct mem_event_st {
     uint16_t type;
     uint16_t flags;
diff -r 8ddd13cc783e -r 3b24188d8815 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -190,8 +190,6 @@ struct mem_event_domain
     /* The ring has 64 entries */
     unsigned char foreign_producers;
     unsigned char target_producers;
-    /* shared page */
-    mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnn-0006xa-Lz; Thu, 23 Feb 2012 06:05:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rnm-0006xV-LV
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329977059!53915502!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQyMDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25168 invoked from network); 23 Feb 2012 06:04:19 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.177) by server-5.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 06:04:19 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 4555845807C;
	Wed, 22 Feb 2012 22:05:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=W430t+oZNasvw1XHStxXZlWenFqv3HaEBru6236TFbP9
	h5ykJa2kKnwgBkE8/sbLzB27R+OS0aT7J8tN1pgWyxSKogkZYtiM6yLmNNpkIFcO
	Qxs8BDtZNPYmn8/IeUw/j00LlZ9kaLYPA1p/iI4nt8RafEdG0eGtdhQZTMz+9Bs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ErfRjo6b3ik3QBFlg0dGOHnXIGM=; b=kuq6bE21SQR
	+/94L3Vhl4QY6zaEgc0TL5DJEsXHlIhcnPAh/iAEd/wBxzfjDKA8IrbvMsfmHHzE
	RAC32sfMBaHydzTtbySLdHElj5MFzIeWoRP7b9ty4hb2bkv7IQ9unfCjEWzQKROG
	9WTKvyREgW7nbmDwWgG6uq1xQtd2PYIA=
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 5B966458079; 
	Wed, 22 Feb 2012 22:05:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3b24188d8815aa5a5abbe507921dd90f2f59d025
Message-Id: <3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize mem_event/access/paging
	interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/libxc/xc_mem_access.c         |  10 ++++++++--
 tools/libxc/xc_mem_event.c          |  13 ++++++++-----
 tools/libxc/xc_mem_paging.c         |  10 ++++++++--
 tools/libxc/xenctrl.h               |   6 +++---
 tools/tests/xen-access/xen-access.c |  22 ++++------------------
 tools/xenpaging/xenpaging.c         |  18 +++---------------
 tools/xenpaging/xenpaging.h         |   2 +-
 xen/arch/x86/mm/mem_event.c         |  33 +++------------------------------
 xen/include/public/domctl.h         |   4 ++--
 xen/include/public/mem_event.h      |   4 ----
 xen/include/xen/sched.h             |   2 --
 11 files changed, 40 insertions(+), 84 deletions(-)


Don't use the superfluous shared page, return the event channel directly as
part of the domctl struct, instead.

In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
so please voice any concerns.

Known pending issues:
- pager could die and its ring page could be used by some other process, yet
  Xen retains the mapping to it.
- use a saner interface for the paging_load buffer.

This change also affects the x86/mm bits in the hypervisor that process the
mem_event setup domctl.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, void *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,19 +24,22 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page, void *ring_page)
+                         unsigned int mode, uint32_t *port, void *ring_page)
 {
     DECLARE_DOMCTL;
+    int rc;
 
     domctl.cmd = XEN_DOMCTL_mem_event_op;
     domctl.domain = domain_id;
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
-
-    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
-    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
+    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
     
-    return do_domctl(xch, &domctl);
+    errno = 0;
+    rc = do_domctl(xch, &domctl);
+    if ( !rc && port )
+        *port = domctl.u.mem_event_op.port;
+    return rc;
 }
 
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -25,12 +25,18 @@
 
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page)
+                         uint32_t *port, void *ring_page)
 {
+    if ( !port )
+    {
+        errno = -EINVAL;
+        return -1;
+    }
+        
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page);
+                                port, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1888,13 +1888,13 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page, void *ring_page);
+                         unsigned int mode, uint32_t *port, void *ring_page);
 int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
                         unsigned int op, unsigned int mode,
                         uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, void *ring_page);
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
                            unsigned long gfn);
@@ -1906,7 +1906,7 @@ int xc_mem_paging_resume(xc_interface *x
                          unsigned long gfn);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
-                        void *shared_page, void *ring_page);
+                         uint32_t *port, void *ring_page);
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
diff -r 8ddd13cc783e -r 3b24188d8815 tools/tests/xen-access/xen-access.c
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -98,7 +98,7 @@ typedef struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
     spinlock_t ring_lock;
 } mem_event_t;
@@ -166,7 +166,7 @@ int xc_wait_for_event_or_timeout(xc_inte
  err:
     return -errno;
 }
-
+ 
 static void *init_page(void)
 {
     void *buffer;
@@ -214,14 +214,6 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Set domain id */
     xenaccess->mem_event.domain_id = domain_id;
 
-    /* Initialise shared page */
-    xenaccess->mem_event.shared_page = init_page();
-    if ( xenaccess->mem_event.shared_page == NULL )
-    {
-        ERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
     xenaccess->mem_event.ring_page = init_page();
     if ( xenaccess->mem_event.ring_page == NULL )
@@ -242,7 +234,7 @@ xenaccess_t *xenaccess_init(xc_interface
 
     /* Initialise Xen */
     rc = xc_mem_access_enable(xenaccess->xc_handle, xenaccess->mem_event.domain_id,
-                             xenaccess->mem_event.shared_page,
+                             &xenaccess->mem_event.evtchn_port,
                              xenaccess->mem_event.ring_page);
     if ( rc != 0 )
     {
@@ -271,7 +263,7 @@ xenaccess_t *xenaccess_init(xc_interface
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(xenaccess->mem_event.xce_handle,
                                     xenaccess->mem_event.domain_id,
-                                    xenaccess->mem_event.shared_page->port);
+                                    xenaccess->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         ERROR("Failed to bind event channel");
@@ -322,12 +314,6 @@ xenaccess_t *xenaccess_init(xc_interface
  err:
     if ( xenaccess )
     {
-        if ( xenaccess->mem_event.shared_page )
-        {
-            munlock(xenaccess->mem_event.shared_page, PAGE_SIZE);
-            free(xenaccess->mem_event.shared_page);
-        }
-
         if ( xenaccess->mem_event.ring_page )
         {
             munlock(xenaccess->mem_event.ring_page, PAGE_SIZE);
diff -r 8ddd13cc783e -r 3b24188d8815 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -341,14 +341,6 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    /* Initialise shared page */
-    paging->mem_event.shared_page = init_page();
-    if ( paging->mem_event.shared_page == NULL )
-    {
-        PERROR("Error initialising shared page");
-        goto err;
-    }
-
     /* Initialise ring page */
     paging->mem_event.ring_page = init_page();
     if ( paging->mem_event.ring_page == NULL )
@@ -365,7 +357,7 @@ static struct xenpaging *xenpaging_init(
     
     /* Initialise Xen */
     rc = xc_mem_paging_enable(xch, paging->mem_event.domain_id,
-                             paging->mem_event.shared_page,
+                             &paging->mem_event.evtchn_port, 
                              paging->mem_event.ring_page);
     if ( rc != 0 )
     {
@@ -397,7 +389,7 @@ static struct xenpaging *xenpaging_init(
     /* Bind event notification */
     rc = xc_evtchn_bind_interdomain(paging->mem_event.xce_handle,
                                     paging->mem_event.domain_id,
-                                    paging->mem_event.shared_page->port);
+                                    paging->mem_event.evtchn_port);
     if ( rc < 0 )
     {
         PERROR("Failed to bind event channel");
@@ -452,13 +444,9 @@ static struct xenpaging *xenpaging_init(
     {
         if ( paging->xs_handle )
             xs_close(paging->xs_handle);
+
         if ( xch )
             xc_interface_close(xch);
-        if ( paging->mem_event.shared_page )
-        {
-            munlock(paging->mem_event.shared_page, PAGE_SIZE);
-            free(paging->mem_event.shared_page);
-        }
 
         if ( paging->mem_event.ring_page )
         {
diff -r 8ddd13cc783e -r 3b24188d8815 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -36,7 +36,7 @@ struct mem_event {
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
-    mem_event_shared_page_t *shared_page;
+    uint32_t evtchn_port;
     void *ring_page;
 };
 
diff -r 8ddd13cc783e -r 3b24188d8815 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -50,12 +50,10 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
-    unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
+    unsigned long ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
     mfn_t ring_mfn;
-    mfn_t shared_mfn;
 
     /* Only one helper at a time. If the helper crashed,
      * the ring is in an undefined state and so is the guest.
@@ -66,10 +64,6 @@ static int mem_event_enable(
     /* Get MFN of ring page */
     guest_get_eff_l1e(v, ring_addr, &l1e);
     ring_gfn = l1e_get_pfn(l1e);
-    /* We're grabbing these two in an order that could deadlock
-     * dom0 if 1. it were an hvm 2. there were two concurrent
-     * enables 3. the two gfn's in each enable criss-crossed
-     * 2MB regions. Duly noted.... */
     ring_mfn = get_gfn(dom_mem_event, ring_gfn, &p2mt);
 
     if ( unlikely(!mfn_valid(mfn_x(ring_mfn))) )
@@ -80,23 +74,9 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Get MFN of shared page */
-    guest_get_eff_l1e(v, shared_addr, &l1e);
-    shared_gfn = l1e_get_pfn(l1e);
-    shared_mfn = get_gfn(dom_mem_event, shared_gfn, &p2mt);
-
-    if ( unlikely(!mfn_valid(mfn_x(shared_mfn))) )
-    {
-        put_gfn(dom_mem_event, ring_gfn);
-        put_gfn(dom_mem_event, shared_gfn);
-        return -EINVAL;
-    }
-
-    /* Map ring and shared pages */
+    /* Map ring page */
     med->ring_page = map_domain_page(mfn_x(ring_mfn));
-    med->shared_page = map_domain_page(mfn_x(shared_mfn));
     put_gfn(dom_mem_event, ring_gfn);
-    put_gfn(dom_mem_event, shared_gfn); 
 
     /* Set the number of currently blocked vCPUs to 0. */
     med->blocked = 0;
@@ -108,8 +88,7 @@ static int mem_event_enable(
     if ( rc < 0 )
         goto err;
 
-    ((mem_event_shared_page_t *)med->shared_page)->port = rc;
-    med->xen_port = rc;
+    med->xen_port = mec->port = rc;
 
     /* Prepare ring buffer */
     FRONT_RING_INIT(&med->front_ring,
@@ -125,9 +104,6 @@ static int mem_event_enable(
     return 0;
 
  err:
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
-
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -249,9 +225,6 @@ static int mem_event_disable(struct doma
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 
-        unmap_domain_page(med->shared_page);
-        med->shared_page = NULL;
-
         /* Unblock all vCPUs */
         for_each_vcpu ( d, v )
         {
diff -r 8ddd13cc783e -r 3b24188d8815 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -746,8 +746,8 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
-    uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
+    uint32_t port;              /* OUT: event channel for ring */
+    uint64_aligned_t ring_addr; /* IN:  Virtual address of ring page */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
diff -r 8ddd13cc783e -r 3b24188d8815 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -51,10 +51,6 @@
 #define MEM_EVENT_REASON_INT3        5    /* int3 was hit: gla/gfn are RIP */
 #define MEM_EVENT_REASON_SINGLESTEP  6    /* single step was invoked: gla/gfn are RIP */
 
-typedef struct mem_event_shared_page {
-    uint32_t port;
-} mem_event_shared_page_t;
-
 typedef struct mem_event_st {
     uint16_t type;
     uint16_t flags;
diff -r 8ddd13cc783e -r 3b24188d8815 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -190,8 +190,6 @@ struct mem_event_domain
     /* The ring has 64 entries */
     unsigned char foreign_producers;
     unsigned char target_producers;
-    /* shared page */
-    mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnq-0006yA-7T; Thu, 23 Feb 2012 06:05:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rno-0006xe-Ct
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:16 +0000
Received: from [85.158.139.83:20758] by server-12.bemta-5.messagelabs.com id
	1F/A5-24595-B17D54F4; Thu, 23 Feb 2012 06:05:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329977114!15707761!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16978 invoked from network); 23 Feb 2012 06:05:14 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:14 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 3A0E945807B;
	Wed, 22 Feb 2012 22:05:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cWNVs6/ROIiAIAfGedr77AZPYjxIXcS1P7UOwv4TYRBl
	c9RtQZ+vl0ByBKEehFvs1y2+epMVDDAOVvqc8uVCxzCDz4+L/QapM2L7oCL3dNMh
	8p9gwAa4ryKX2tJSeJmVMr4L9Q811ygkOcYjw+9G+CwRw77EW+clwGyijDe1RWo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=qJSI2120TMtJuyMwdd7IsZYUrMc=; b=iCq0gHdABs4
	J3ETFJ9hFOgBtSmKtLXqD+5H8HreO6UVSqmN8AMafJe1fLDW20URYaEXbybr1wMB
	n7P4oj1U1wTL6N7rih/5ankAtcce7Q1bk6T+pfapOGf2OyGduSAsSKx3eFRee1gS
	W4x36PNav2rEBfNsZLyirDMTLBGjpQ50=
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 76C73458079; 
	Wed, 22 Feb 2012 22:05:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 99e6c9b9e97137ee7404aa86a921f4f7664f6978
Message-Id: <99e6c9b9e97137ee7404.1329977107@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 7] x86/hvm: refactor calls to prepare and
 tear down a helper 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

 xen/arch/x86/hvm/hvm.c        |  48 ++++++++++++++++++++++++++++++++----------
 xen/include/asm-x86/hvm/hvm.h |   7 ++++++
 2 files changed, 43 insertions(+), 12 deletions(-)


These are currently used for the rings connecting Xen with qemu. Refactor them
so the same code can be later used for mem event rings.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3b24188d8815 -r 99e6c9b9e971 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -331,6 +331,19 @@ static void hvm_init_ioreq_page(
     domain_pause(d);
 }
 
+void destroy_ring_for_helper(
+    void **_va, struct page_info *page)
+{
+    void *va = *_va;
+
+    if ( va != NULL )
+    {
+        unmap_domain_page_global(va);
+        put_page_and_type(page);
+        *_va = NULL;
+    }
+}
+
 static void hvm_destroy_ioreq_page(
     struct domain *d, struct hvm_ioreq_page *iorp)
 {
@@ -338,18 +351,14 @@ static void hvm_destroy_ioreq_page(
 
     ASSERT(d->is_dying);
 
-    if ( iorp->va != NULL )
-    {
-        unmap_domain_page_global(iorp->va);
-        put_page_and_type(iorp->page);
-        iorp->va = NULL;
-    }
+    destroy_ring_for_helper(&iorp->va, iorp->page);
 
     spin_unlock(&iorp->lock);
 }
 
-static int hvm_set_ioreq_page(
-    struct domain *d, struct hvm_ioreq_page *iorp, unsigned long gmfn)
+int prepare_ring_for_helper(
+    struct domain *d, unsigned long gmfn, struct page_info **_page,
+    void **_va)
 {
     struct page_info *page;
     p2m_type_t p2mt;
@@ -390,14 +399,30 @@ static int hvm_set_ioreq_page(
         return -ENOMEM;
     }
 
+    *_va = va;
+    *_page = page;
+
+    put_gfn(d, gmfn);
+
+    return 0;
+}
+
+static int hvm_set_ioreq_page(
+    struct domain *d, struct hvm_ioreq_page *iorp, unsigned long gmfn)
+{
+    struct page_info *page;
+    void *va;
+    int rc;
+
+    if ( (rc = prepare_ring_for_helper(d, gmfn, &page, &va)) )
+        return rc;
+
     spin_lock(&iorp->lock);
 
     if ( (iorp->va != NULL) || d->is_dying )
     {
+        destroy_ring_for_helper(&iorp->va, iorp->page);
         spin_unlock(&iorp->lock);
-        unmap_domain_page_global(va);
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gmfn);
         return -EINVAL;
     }
 
@@ -405,7 +430,6 @@ static int hvm_set_ioreq_page(
     iorp->page = page;
 
     spin_unlock(&iorp->lock);
-    put_gfn(d, gmfn);
 
     domain_unpause(d);
 
diff -r 3b24188d8815 -r 99e6c9b9e971 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -26,6 +26,7 @@
 #include <asm/hvm/asid.h>
 #include <public/domctl.h>
 #include <public/hvm/save.h>
+#include <asm/mm.h>
 
 /* Interrupt acknowledgement sources. */
 enum hvm_intsrc {
@@ -191,6 +192,12 @@ int hvm_vcpu_cacheattr_init(struct vcpu 
 void hvm_vcpu_cacheattr_destroy(struct vcpu *v);
 void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip);
 
+/* Prepare/destroy a ring for a dom0 helper. Helper with talk
+ * with Xen on behalf of this hvm domain. */
+int prepare_ring_for_helper(struct domain *d, unsigned long gmfn, 
+                            struct page_info **_page, void **_va);
+void destroy_ring_for_helper(void **_va, struct page_info *page);
+
 bool_t hvm_send_assist_req(struct vcpu *v);
 
 void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:05:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:05:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rnq-0006yA-7T; Thu, 23 Feb 2012 06:05:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0Rno-0006xe-Ct
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:05:16 +0000
Received: from [85.158.139.83:20758] by server-12.bemta-5.messagelabs.com id
	1F/A5-24595-B17D54F4; Thu, 23 Feb 2012 06:05:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329977114!15707761!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2NzM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16978 invoked from network); 23 Feb 2012 06:05:14 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 06:05:14 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 3A0E945807B;
	Wed, 22 Feb 2012 22:05:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cWNVs6/ROIiAIAfGedr77AZPYjxIXcS1P7UOwv4TYRBl
	c9RtQZ+vl0ByBKEehFvs1y2+epMVDDAOVvqc8uVCxzCDz4+L/QapM2L7oCL3dNMh
	8p9gwAa4ryKX2tJSeJmVMr4L9Q811ygkOcYjw+9G+CwRw77EW+clwGyijDe1RWo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=qJSI2120TMtJuyMwdd7IsZYUrMc=; b=iCq0gHdABs4
	J3ETFJ9hFOgBtSmKtLXqD+5H8HreO6UVSqmN8AMafJe1fLDW20URYaEXbybr1wMB
	n7P4oj1U1wTL6N7rih/5ankAtcce7Q1bk6T+pfapOGf2OyGduSAsSKx3eFRee1gS
	W4x36PNav2rEBfNsZLyirDMTLBGjpQ50=
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 76C73458079; 
	Wed, 22 Feb 2012 22:05:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 99e6c9b9e97137ee7404aa86a921f4f7664f6978
Message-Id: <99e6c9b9e97137ee7404.1329977107@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 01:05:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 7] x86/hvm: refactor calls to prepare and
 tear down a helper 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

 xen/arch/x86/hvm/hvm.c        |  48 ++++++++++++++++++++++++++++++++----------
 xen/include/asm-x86/hvm/hvm.h |   7 ++++++
 2 files changed, 43 insertions(+), 12 deletions(-)


These are currently used for the rings connecting Xen with qemu. Refactor them
so the same code can be later used for mem event rings.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3b24188d8815 -r 99e6c9b9e971 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -331,6 +331,19 @@ static void hvm_init_ioreq_page(
     domain_pause(d);
 }
 
+void destroy_ring_for_helper(
+    void **_va, struct page_info *page)
+{
+    void *va = *_va;
+
+    if ( va != NULL )
+    {
+        unmap_domain_page_global(va);
+        put_page_and_type(page);
+        *_va = NULL;
+    }
+}
+
 static void hvm_destroy_ioreq_page(
     struct domain *d, struct hvm_ioreq_page *iorp)
 {
@@ -338,18 +351,14 @@ static void hvm_destroy_ioreq_page(
 
     ASSERT(d->is_dying);
 
-    if ( iorp->va != NULL )
-    {
-        unmap_domain_page_global(iorp->va);
-        put_page_and_type(iorp->page);
-        iorp->va = NULL;
-    }
+    destroy_ring_for_helper(&iorp->va, iorp->page);
 
     spin_unlock(&iorp->lock);
 }
 
-static int hvm_set_ioreq_page(
-    struct domain *d, struct hvm_ioreq_page *iorp, unsigned long gmfn)
+int prepare_ring_for_helper(
+    struct domain *d, unsigned long gmfn, struct page_info **_page,
+    void **_va)
 {
     struct page_info *page;
     p2m_type_t p2mt;
@@ -390,14 +399,30 @@ static int hvm_set_ioreq_page(
         return -ENOMEM;
     }
 
+    *_va = va;
+    *_page = page;
+
+    put_gfn(d, gmfn);
+
+    return 0;
+}
+
+static int hvm_set_ioreq_page(
+    struct domain *d, struct hvm_ioreq_page *iorp, unsigned long gmfn)
+{
+    struct page_info *page;
+    void *va;
+    int rc;
+
+    if ( (rc = prepare_ring_for_helper(d, gmfn, &page, &va)) )
+        return rc;
+
     spin_lock(&iorp->lock);
 
     if ( (iorp->va != NULL) || d->is_dying )
     {
+        destroy_ring_for_helper(&iorp->va, iorp->page);
         spin_unlock(&iorp->lock);
-        unmap_domain_page_global(va);
-        put_page_and_type(mfn_to_page(mfn));
-        put_gfn(d, gmfn);
         return -EINVAL;
     }
 
@@ -405,7 +430,6 @@ static int hvm_set_ioreq_page(
     iorp->page = page;
 
     spin_unlock(&iorp->lock);
-    put_gfn(d, gmfn);
 
     domain_unpause(d);
 
diff -r 3b24188d8815 -r 99e6c9b9e971 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -26,6 +26,7 @@
 #include <asm/hvm/asid.h>
 #include <public/domctl.h>
 #include <public/hvm/save.h>
+#include <asm/mm.h>
 
 /* Interrupt acknowledgement sources. */
 enum hvm_intsrc {
@@ -191,6 +192,12 @@ int hvm_vcpu_cacheattr_init(struct vcpu 
 void hvm_vcpu_cacheattr_destroy(struct vcpu *v);
 void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip);
 
+/* Prepare/destroy a ring for a dom0 helper. Helper with talk
+ * with Xen on behalf of this hvm domain. */
+int prepare_ring_for_helper(struct domain *d, unsigned long gmfn, 
+                            struct page_info **_page, void **_va);
+void destroy_ring_for_helper(void **_va, struct page_info *page);
+
 bool_t hvm_send_assist_req(struct vcpu *v);
 
 void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:08:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:08:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rr4-0007nD-Ik; Thu, 23 Feb 2012 06:08: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 1S0Rr3-0007mk-5l
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:08:37 +0000
Received: from [85.158.139.83:46876] by server-10.bemta-5.messagelabs.com id
	78/01-07861-4E7D54F4; Thu, 23 Feb 2012 06:08:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329977314!12384427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDUyOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5057 invoked from network); 23 Feb 2012 06:08:35 -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;
	23 Feb 2012 06:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,468,1325462400"; d="scan'208";a="10885838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 06:08:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 06:08:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0Rr0-0006FT-6P;
	Thu, 23 Feb 2012 06:08:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0Rr0-0004gk-51;
	Thu, 23 Feb 2012 06:08:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12025-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 06:08:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12025: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12025 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12025/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12012

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12012 like 11891
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2   fail in 12012 like 11789

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 06:08:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 06:08:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Rr4-0007nD-Ik; Thu, 23 Feb 2012 06:08: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 1S0Rr3-0007mk-5l
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 06:08:37 +0000
Received: from [85.158.139.83:46876] by server-10.bemta-5.messagelabs.com id
	78/01-07861-4E7D54F4; Thu, 23 Feb 2012 06:08:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1329977314!12384427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDUyOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5057 invoked from network); 23 Feb 2012 06:08:35 -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;
	23 Feb 2012 06:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,468,1325462400"; d="scan'208";a="10885838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 06:08:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 06:08:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0Rr0-0006FT-6P;
	Thu, 23 Feb 2012 06:08:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0Rr0-0004gk-51;
	Thu, 23 Feb 2012 06:08:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12025-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 06:08:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12025: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12025 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12025/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12012

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12012 like 11891
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2   fail in 12012 like 11789

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UIt-0001Ft-PC; Thu, 23 Feb 2012 08:45:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UIr-0001Fk-83
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:45:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329986723!10181818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12392 invoked from network); 23 Feb 2012 08:45:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 08:45:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10887847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:45:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:45:22 +0000
Message-ID: <1329986720.8557.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 08:45:20 +0000
In-Reply-To: <4F4560BC.30002@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 21:40 +0000, Jim Fehlig wrote:
> Ian Jackson wrote:
> > Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> >   
> >> Ian Jackson wrote: 
> >>     
> >>> Users of libxl should not be using libxc directly and therefore should 
> >>> not be including xenctrl.h. 
> >>>       
> > ...
> >   
> >> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
> >> it seems that add __XEN_TOOLS_ to libvirt code is not good. 
> >>     
> >
> > Can you tell us the error message you get ?  I think the problem is
> > probably that libvirt is trying to use libxc directly.
> >   
> 
> The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> is that libxl.h includes <xen/sysctl.h>, which has this
> 
> #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> #error "sysctl operations are intended for use by node control tools only"
> #endif
> 
> Without the defines, Bamvor is hitting the #error directive.

I thought we'd discussed and resolved this ages ago but I guess we only
discussed it...

How about the following:

8<-------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329986233 0
# Node ID d256d6b42ee77cdff0356c37d6fcaf6203a21ba6
# Parent  aa82c27ea0a3cdfb5e58244918d2046cf4e314a9
libxl: remove sysctl.h from public interface

Using sysctl.h is restricted to "node control tools only" and requires magic
defines. Therefore make its use internal to libxl.

Also removes an indirect include of domctl.h which has the same restrction.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 08:37:13 2012 +0000
@@ -491,7 +491,7 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         }
         ptr = tmp;
         ptr[i].poolid = info->cpupool_id;
-        ptr[i].sched_id = info->sched_id;
+        ptr[i].sched = info->sched_id;
         ptr[i].n_dom = info->n_dom;
         if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {
             xc_cpupool_infofree(ctx->xch, info);
@@ -2750,7 +2750,10 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
-    physinfo->phys_cap = xcphysinfo.capabilities;
+
+    physinfo->cap_hvm = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm);
+    physinfo->cap_hvm_directio =
+        !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm_directio);
 
     return 0;
 }
@@ -2965,14 +2968,11 @@ out:
     return rc;
 }
 
-/*
- * returns one of the XEN_SCHEDULER_* constants from public/domctl.h
- */
-int libxl_get_sched_id(libxl_ctx *ctx)
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx)
 {
-    int sched, ret;
-
-    if ((ret = xc_sched_id(ctx->xch, &sched)) != 0) {
+    libxl_scheduler sched, ret;
+
+    if ((ret = xc_sched_id(ctx->xch, (int *)&sched)) != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
@@ -3445,7 +3445,8 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
@@ -3461,7 +3462,7 @@ int libxl_cpupool_create(libxl_ctx *ctx,
         return ERROR_NOMEM;
     }
 
-    rc = xc_cpupool_create(ctx->xch, poolid, schedid);
+    rc = xc_cpupool_create(ctx->xch, poolid, sched);
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 08:37:13 2012 +0000
@@ -138,7 +138,6 @@
 #include <xentoollog.h>
 
 #include <xen/sched.h>
-#include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
@@ -584,7 +583,7 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
                                unsigned int max_vcpus, libxl_cpumap *cpumap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
 
-int libxl_get_sched_id(libxl_ctx *ctx);
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
@@ -627,7 +626,8 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 08:37:13 2012 +0000
@@ -99,6 +99,14 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+# Consistent with values defined in domctl.h
+libxl_scheduler = Enumeration("scheduler", [
+    (4, "sedf"),
+    (5, "credit"),
+    (6, "credit2"),
+    (7, "arinc653"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -158,7 +166,7 @@ libxl_dominfo = Struct("dominfo",[
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
-    ("sched_id",    uint32),
+    ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
     ])
@@ -381,7 +389,9 @@ libxl_physinfo = Struct("physinfo", [
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
-    ("phys_cap", uint32),
+
+    ("cap_hvm", bool),
+    ("cap_hvm_directio", bool),
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_cputopology = Struct("cputopology", [
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 08:37:13 2012 +0000
@@ -19,18 +19,6 @@
 
 #include "libxl_internal.h"
 
-struct schedid_name {
-    char *name;
-    int id;
-};
-
-static struct schedid_name schedid_name[] = {
-    { "credit", XEN_SCHEDULER_CREDIT },
-    { "sedf", XEN_SCHEDULER_SEDF },
-    { "credit2", XEN_SCHEDULER_CREDIT2 },
-    { NULL, -1 }
-};
-
 const char *libxl_basename(const char *name)
 {
     const char *filename;
@@ -151,28 +139,6 @@ int libxl_name_to_cpupoolid(libxl_ctx *c
     return ret;
 }
 
-int libxl_name_to_schedid(libxl_ctx *ctx, const char *name)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (strcmp(name, schedid_name[i].name) == 0)
-            return schedid_name[i].id;
-
-    return ERROR_INVAL;
-}
-
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (schedid_name[i].id == schedid)
-            return schedid_name[i].name;
-
-    return "unknown";
-}
-
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
     GC_INIT(ctx);
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Thu Feb 23 08:37:13 2012 +0000
@@ -24,8 +24,6 @@ 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_name_to_schedid(libxl_ctx *ctx, const char *name);
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 08:37:13 2012 +0000
@@ -3688,15 +3688,15 @@ int main_vcpuset(int argc, char **argv)
 static void output_xeninfo(void)
 {
     const libxl_version_info *info;
-    int sched_id;
+    libxl_scheduler sched;
 
     if (!(info = libxl_get_version_info(ctx))) {
         fprintf(stderr, "libxl_get_version_info failed.\n");
         return;
     }
 
-    if ((sched_id = libxl_get_sched_id(ctx)) < 0) {
-        fprintf(stderr, "get_sched_id sysctl failed.\n");
+    if ((sched = libxl_get_scheduler(ctx)) < 0) {
+        fprintf(stderr, "get_scheduler sysctl failed.\n");
         return;
     }
 
@@ -3704,7 +3704,7 @@ static void output_xeninfo(void)
     printf("xen_minor              : %d\n", info->xen_version_minor);
     printf("xen_extra              : %s\n", info->xen_version_extra);
     printf("xen_caps               : %s\n", info->capabilities);
-    printf("xen_scheduler          : %s\n", libxl_schedid_to_name(ctx, sched_id));
+    printf("xen_scheduler          : %s\n", libxl_scheduler_to_string(sched));
     printf("xen_pagesize           : %u\n", info->pagesize);
     printf("platform_params        : virt_start=0x%"PRIx64"\n", info->virt_start);
     printf("xen_changeset          : %s\n", info->changeset);
@@ -3752,9 +3752,9 @@ static void output_physinfo(void)
     for (i = 0; i < 8; i++)
         printf("%08x%c", info.hw_cap[i], i < 7 ? ':' : '\n');
     printf("virt_caps              :");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm)
+    if (info.cap_hvm)
         printf(" hvm");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm_directio)
+    if (info.cap_hvm_directio)
         printf(" hvm_directio");
     printf("\n");
     vinfo = libxl_get_version_info(ctx);
@@ -4060,7 +4060,7 @@ static int sched_sedf_domain_output(
 }
 
 static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+    libxl_scheduler sched, int (*output)(int), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
@@ -4089,7 +4089,7 @@ static int sched_domain_output(
     }
 
     for (p = 0; !rc && (p < n_pools); p++) {
-        if ((poolinfo[p].sched_id != sched) ||
+        if ((poolinfo[p].sched != sched) ||
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
@@ -4170,7 +4170,7 @@ int main_sched_credit(int argc, char **a
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT,
                                     sched_credit_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4246,7 +4246,7 @@ int main_sched_credit2(int argc, char **
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT2,
                                     sched_credit2_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4348,7 +4348,7 @@ int main_sched_sedf(int argc, char **arg
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_SEDF,
+        return -sched_domain_output(LIBXL_SCHEDULER_SEDF,
                                     sched_sedf_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -5287,9 +5287,8 @@ int main_cpupoolcreate(int argc, char **
     XLU_Config *config;
     const char *buf;
     const char *name;
-    const char *sched;
     uint32_t poolid;
-    int schedid = -1;
+    libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
     XLU_ConfigList *nodes;
     int n_cpus, n_nodes, i, n;
@@ -5384,17 +5383,16 @@ int main_cpupoolcreate(int argc, char **
     }
 
     if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
-        if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
+        if ((libxl_scheduler_from_string(buf, &sched)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;
         }
     } else {
-        if ((schedid = libxl_get_sched_id(ctx)) < 0) {
-            fprintf(stderr, "get_sched_id sysctl failed.\n");
+        if ((sched = libxl_get_scheduler(ctx)) < 0) {
+            fprintf(stderr, "get_scheduler sysctl failed.\n");
             return -ERROR_FAIL;
         }
     }
-    sched = libxl_schedid_to_name(ctx, schedid);
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         fprintf(stderr, "libxl_get_freecpus failed\n");
@@ -5462,14 +5460,14 @@ int main_cpupoolcreate(int argc, char **
 
     printf("Using config file \"%s\"\n", filename);
     printf("cpupool name:   %s\n", name);
-    printf("scheduler:      %s\n", sched);
+    printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
 
     if (dryrun_only)
         return 0;
 
     poolid = 0;
-    if (libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid)) {
+    if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) {
         fprintf(stderr, "error on creating cpupool\n");
         return -ERROR_FAIL;
     }
@@ -5554,7 +5552,7 @@ int main_cpupoollist(int argc, char **ar
                     }
                 if (!opt_cpus) {
                     printf("%3d %9s       y       %4d", n,
-                           libxl_schedid_to_name(ctx, poolinfo[p].sched_id),
+                           libxl_scheduler_to_string(poolinfo[p].sched),
                            poolinfo[p].n_dom);
                 }
                 printf("\n");
@@ -5739,7 +5737,7 @@ int main_cpupoolnumasplit(int argc, char
     int c;
     int n;
     uint32_t poolid;
-    int schedid;
+    libxl_scheduler sched;
     int n_pools;
     int node;
     int n_cpus;
@@ -5760,7 +5758,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_NOMEM;
     }
     poolid = poolinfo[0].poolid;
-    schedid = poolinfo[0].sched_id;
+    sched = poolinfo[0].sched;
     for (p = 0; p < n_pools; p++) {
         libxl_cpupoolinfo_dispose(poolinfo + p);
     }
@@ -5840,7 +5838,7 @@ int main_cpupoolnumasplit(int argc, char
         snprintf(name, 15, "Pool-node%d", node);
         libxl_uuid_generate(&uuid);
         poolid = 0;
-        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid);
+        ret = -libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid);
         if (ret) {
             fprintf(stderr, "error on creating cpupool\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 Feb 23 08:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UIt-0001Ft-PC; Thu, 23 Feb 2012 08:45:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UIr-0001Fk-83
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:45:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1329986723!10181818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12392 invoked from network); 23 Feb 2012 08:45:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 08:45:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10887847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:45:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:45:22 +0000
Message-ID: <1329986720.8557.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 08:45:20 +0000
In-Reply-To: <4F4560BC.30002@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 21:40 +0000, Jim Fehlig wrote:
> Ian Jackson wrote:
> > Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> >   
> >> Ian Jackson wrote: 
> >>     
> >>> Users of libxl should not be using libxc directly and therefore should 
> >>> not be including xenctrl.h. 
> >>>       
> > ...
> >   
> >> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it? 
> >> it seems that add __XEN_TOOLS_ to libvirt code is not good. 
> >>     
> >
> > Can you tell us the error message you get ?  I think the problem is
> > probably that libvirt is trying to use libxc directly.
> >   
> 
> The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> is that libxl.h includes <xen/sysctl.h>, which has this
> 
> #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> #error "sysctl operations are intended for use by node control tools only"
> #endif
> 
> Without the defines, Bamvor is hitting the #error directive.

I thought we'd discussed and resolved this ages ago but I guess we only
discussed it...

How about the following:

8<-------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329986233 0
# Node ID d256d6b42ee77cdff0356c37d6fcaf6203a21ba6
# Parent  aa82c27ea0a3cdfb5e58244918d2046cf4e314a9
libxl: remove sysctl.h from public interface

Using sysctl.h is restricted to "node control tools only" and requires magic
defines. Therefore make its use internal to libxl.

Also removes an indirect include of domctl.h which has the same restrction.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 08:37:13 2012 +0000
@@ -491,7 +491,7 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         }
         ptr = tmp;
         ptr[i].poolid = info->cpupool_id;
-        ptr[i].sched_id = info->sched_id;
+        ptr[i].sched = info->sched_id;
         ptr[i].n_dom = info->n_dom;
         if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {
             xc_cpupool_infofree(ctx->xch, info);
@@ -2750,7 +2750,10 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
-    physinfo->phys_cap = xcphysinfo.capabilities;
+
+    physinfo->cap_hvm = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm);
+    physinfo->cap_hvm_directio =
+        !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm_directio);
 
     return 0;
 }
@@ -2965,14 +2968,11 @@ out:
     return rc;
 }
 
-/*
- * returns one of the XEN_SCHEDULER_* constants from public/domctl.h
- */
-int libxl_get_sched_id(libxl_ctx *ctx)
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx)
 {
-    int sched, ret;
-
-    if ((ret = xc_sched_id(ctx->xch, &sched)) != 0) {
+    libxl_scheduler sched, ret;
+
+    if ((ret = xc_sched_id(ctx->xch, (int *)&sched)) != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
@@ -3445,7 +3445,8 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
@@ -3461,7 +3462,7 @@ int libxl_cpupool_create(libxl_ctx *ctx,
         return ERROR_NOMEM;
     }
 
-    rc = xc_cpupool_create(ctx->xch, poolid, schedid);
+    rc = xc_cpupool_create(ctx->xch, poolid, sched);
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 08:37:13 2012 +0000
@@ -138,7 +138,6 @@
 #include <xentoollog.h>
 
 #include <xen/sched.h>
-#include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
@@ -584,7 +583,7 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
                                unsigned int max_vcpus, libxl_cpumap *cpumap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
 
-int libxl_get_sched_id(libxl_ctx *ctx);
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
@@ -627,7 +626,8 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 08:37:13 2012 +0000
@@ -99,6 +99,14 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+# Consistent with values defined in domctl.h
+libxl_scheduler = Enumeration("scheduler", [
+    (4, "sedf"),
+    (5, "credit"),
+    (6, "credit2"),
+    (7, "arinc653"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -158,7 +166,7 @@ libxl_dominfo = Struct("dominfo",[
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
-    ("sched_id",    uint32),
+    ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
     ])
@@ -381,7 +389,9 @@ libxl_physinfo = Struct("physinfo", [
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
-    ("phys_cap", uint32),
+
+    ("cap_hvm", bool),
+    ("cap_hvm_directio", bool),
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_cputopology = Struct("cputopology", [
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 08:37:13 2012 +0000
@@ -19,18 +19,6 @@
 
 #include "libxl_internal.h"
 
-struct schedid_name {
-    char *name;
-    int id;
-};
-
-static struct schedid_name schedid_name[] = {
-    { "credit", XEN_SCHEDULER_CREDIT },
-    { "sedf", XEN_SCHEDULER_SEDF },
-    { "credit2", XEN_SCHEDULER_CREDIT2 },
-    { NULL, -1 }
-};
-
 const char *libxl_basename(const char *name)
 {
     const char *filename;
@@ -151,28 +139,6 @@ int libxl_name_to_cpupoolid(libxl_ctx *c
     return ret;
 }
 
-int libxl_name_to_schedid(libxl_ctx *ctx, const char *name)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (strcmp(name, schedid_name[i].name) == 0)
-            return schedid_name[i].id;
-
-    return ERROR_INVAL;
-}
-
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (schedid_name[i].id == schedid)
-            return schedid_name[i].name;
-
-    return "unknown";
-}
-
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
     GC_INIT(ctx);
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Thu Feb 23 08:37:13 2012 +0000
@@ -24,8 +24,6 @@ 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_name_to_schedid(libxl_ctx *ctx, const char *name);
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
diff -r aa82c27ea0a3 -r d256d6b42ee7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 14:43:57 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 08:37:13 2012 +0000
@@ -3688,15 +3688,15 @@ int main_vcpuset(int argc, char **argv)
 static void output_xeninfo(void)
 {
     const libxl_version_info *info;
-    int sched_id;
+    libxl_scheduler sched;
 
     if (!(info = libxl_get_version_info(ctx))) {
         fprintf(stderr, "libxl_get_version_info failed.\n");
         return;
     }
 
-    if ((sched_id = libxl_get_sched_id(ctx)) < 0) {
-        fprintf(stderr, "get_sched_id sysctl failed.\n");
+    if ((sched = libxl_get_scheduler(ctx)) < 0) {
+        fprintf(stderr, "get_scheduler sysctl failed.\n");
         return;
     }
 
@@ -3704,7 +3704,7 @@ static void output_xeninfo(void)
     printf("xen_minor              : %d\n", info->xen_version_minor);
     printf("xen_extra              : %s\n", info->xen_version_extra);
     printf("xen_caps               : %s\n", info->capabilities);
-    printf("xen_scheduler          : %s\n", libxl_schedid_to_name(ctx, sched_id));
+    printf("xen_scheduler          : %s\n", libxl_scheduler_to_string(sched));
     printf("xen_pagesize           : %u\n", info->pagesize);
     printf("platform_params        : virt_start=0x%"PRIx64"\n", info->virt_start);
     printf("xen_changeset          : %s\n", info->changeset);
@@ -3752,9 +3752,9 @@ static void output_physinfo(void)
     for (i = 0; i < 8; i++)
         printf("%08x%c", info.hw_cap[i], i < 7 ? ':' : '\n');
     printf("virt_caps              :");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm)
+    if (info.cap_hvm)
         printf(" hvm");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm_directio)
+    if (info.cap_hvm_directio)
         printf(" hvm_directio");
     printf("\n");
     vinfo = libxl_get_version_info(ctx);
@@ -4060,7 +4060,7 @@ static int sched_sedf_domain_output(
 }
 
 static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+    libxl_scheduler sched, int (*output)(int), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
@@ -4089,7 +4089,7 @@ static int sched_domain_output(
     }
 
     for (p = 0; !rc && (p < n_pools); p++) {
-        if ((poolinfo[p].sched_id != sched) ||
+        if ((poolinfo[p].sched != sched) ||
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
@@ -4170,7 +4170,7 @@ int main_sched_credit(int argc, char **a
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT,
                                     sched_credit_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4246,7 +4246,7 @@ int main_sched_credit2(int argc, char **
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT2,
                                     sched_credit2_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4348,7 +4348,7 @@ int main_sched_sedf(int argc, char **arg
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_SEDF,
+        return -sched_domain_output(LIBXL_SCHEDULER_SEDF,
                                     sched_sedf_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -5287,9 +5287,8 @@ int main_cpupoolcreate(int argc, char **
     XLU_Config *config;
     const char *buf;
     const char *name;
-    const char *sched;
     uint32_t poolid;
-    int schedid = -1;
+    libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
     XLU_ConfigList *nodes;
     int n_cpus, n_nodes, i, n;
@@ -5384,17 +5383,16 @@ int main_cpupoolcreate(int argc, char **
     }
 
     if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
-        if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
+        if ((libxl_scheduler_from_string(buf, &sched)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;
         }
     } else {
-        if ((schedid = libxl_get_sched_id(ctx)) < 0) {
-            fprintf(stderr, "get_sched_id sysctl failed.\n");
+        if ((sched = libxl_get_scheduler(ctx)) < 0) {
+            fprintf(stderr, "get_scheduler sysctl failed.\n");
             return -ERROR_FAIL;
         }
     }
-    sched = libxl_schedid_to_name(ctx, schedid);
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         fprintf(stderr, "libxl_get_freecpus failed\n");
@@ -5462,14 +5460,14 @@ int main_cpupoolcreate(int argc, char **
 
     printf("Using config file \"%s\"\n", filename);
     printf("cpupool name:   %s\n", name);
-    printf("scheduler:      %s\n", sched);
+    printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
 
     if (dryrun_only)
         return 0;
 
     poolid = 0;
-    if (libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid)) {
+    if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) {
         fprintf(stderr, "error on creating cpupool\n");
         return -ERROR_FAIL;
     }
@@ -5554,7 +5552,7 @@ int main_cpupoollist(int argc, char **ar
                     }
                 if (!opt_cpus) {
                     printf("%3d %9s       y       %4d", n,
-                           libxl_schedid_to_name(ctx, poolinfo[p].sched_id),
+                           libxl_scheduler_to_string(poolinfo[p].sched),
                            poolinfo[p].n_dom);
                 }
                 printf("\n");
@@ -5739,7 +5737,7 @@ int main_cpupoolnumasplit(int argc, char
     int c;
     int n;
     uint32_t poolid;
-    int schedid;
+    libxl_scheduler sched;
     int n_pools;
     int node;
     int n_cpus;
@@ -5760,7 +5758,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_NOMEM;
     }
     poolid = poolinfo[0].poolid;
-    schedid = poolinfo[0].sched_id;
+    sched = poolinfo[0].sched;
     for (p = 0; p < n_pools; p++) {
         libxl_cpupoolinfo_dispose(poolinfo + p);
     }
@@ -5840,7 +5838,7 @@ int main_cpupoolnumasplit(int argc, char
         snprintf(name, 15, "Pool-node%d", node);
         libxl_uuid_generate(&uuid);
         poolid = 0;
-        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid);
+        ret = -libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid);
         if (ret) {
             fprintf(stderr, "error on creating cpupool\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 Feb 23 08:50:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08: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 1S0UMh-0001Nf-FI; Thu, 23 Feb 2012 08:49:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0UMf-0001NP-Qn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:49:26 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329986958!15489314!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13769 invoked from network); 23 Feb 2012 08:49:19 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 08:49:19 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0UMX-0005DC-Ao
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 00:49:17 -0800
Date: Thu, 23 Feb 2012 00:49:17 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329986957327-5507375.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

#/var/log/xen/qemu-dm-PRECISEHVM.log
bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory
chardev: opening backend "socket" failed: No such file or directory

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:50:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08: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 1S0UMh-0001Nf-FI; Thu, 23 Feb 2012 08:49:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0UMf-0001NP-Qn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:49:26 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329986958!15489314!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13769 invoked from network); 23 Feb 2012 08:49:19 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 08:49:19 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0UMX-0005DC-Ao
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 00:49:17 -0800
Date: Thu, 23 Feb 2012 00:49:17 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329986957327-5507375.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

#/var/log/xen/qemu-dm-PRECISEHVM.log
bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory
chardev: opening backend "socket" failed: No such file or directory

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:53:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UPM-0001XI-Mo; Thu, 23 Feb 2012 08:52:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UPK-0001Wq-8d
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:52:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329987124!15441698!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17735 invoked from network); 23 Feb 2012 08:52:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 08:52:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10887998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:52:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:52:04 +0000
Message-ID: <1329987122.8557.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 08:52:02 +0000
In-Reply-To: <1329986720.8557.10.camel@zakaz.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<1329986720.8557.10.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 08:45 +0000, Ian Campbell wrote:
> On Wed, 2012-02-22 at 21:40 +0000, Jim Fehlig wrote:
> > Ian Jackson wrote:
> > > Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > >
> > >> Ian Jackson wrote:
> > >>
> > >>> Users of libxl should not be using libxc directly and therefore should
> > >>> not be including xenctrl.h.
> > >>>
> > > ...
> > >
> > >> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it?
> > >> it seems that add __XEN_TOOLS_ to libvirt code is not good.
> > >>
> > >
> > > Can you tell us the error message you get ?  I think the problem is
> > > probably that libvirt is trying to use libxc directly.
> > >
> >
> > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > is that libxl.h includes <xen/sysctl.h>, which has this
> >
> > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > #error "sysctl operations are intended for use by node control tools only"
> > #endif
> >
> > Without the defines, Bamvor is hitting the #error directive.
> 
> I thought we'd discussed and resolved this ages ago but I guess we only
> discussed it...
> 
> How about the following:

I also have the following, I think the benefits are less obvious for
this one though but it does mean we are consistently avoiding all xen
public headers in the libxl public API which at least has the benefit of
being simple to describe.

8<-------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329986824 0
# Node ID ad39625c16966fe004c25e5be81af0e32cf8646a
# Parent  d256d6b42ee77cdff0356c37d6fcaf6203a21ba6
libxl: Remove xen/sched.h from public interface

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 08:47:04 2012 +0000
@@ -137,8 +137,6 @@
 
 #include <xentoollog.h>
 
-#include <xen/sched.h>
-
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
 
@@ -638,12 +636,7 @@ int libxl_cpupool_cpuremove(libxl_ctx *c
 int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
 
-static inline int libxl_domid_valid_guest(uint32_t domid)
-{
-    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
-     * does not check whether the domain actually exists */
-    return domid > 0 && domid < DOMID_FIRST_RESERVED;
-}
+int libxl_domid_valid_guest(uint32_t domid);
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
                                uint32_t *ssidref);
diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 08:47:04 2012 +0000
@@ -107,6 +107,15 @@ libxl_scheduler = Enumeration("scheduler
     (7, "arinc653"),
     ])
 
+# Consistent with SHUTDOWN_* in sched.h
+libxl_shutdown_reason = Enumeration("shutdown_reason", [
+    (0, "poweroff"),
+    (1, "reboot"),
+    (2, "suspend"),
+    (3, "crash"),
+    (4, "watchdog"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +163,7 @@ libxl_dominfo = Struct("dominfo",[
     #
     # Otherwise set to a value guaranteed not to clash with any valid
     # SHUTDOWN_* constant.
-    ("shutdown_reason", uint8),
+    ("shutdown_reason", libxl_shutdown_reason),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 08:47:04 2012 +0000
@@ -507,6 +507,13 @@ void libxl_cputopology_list_free(libxl_c
     free(list);
 }
 
+int libxl_domid_valid_guest(uint32_t domid)
+{
+    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
+     * does not check whether the domain actually exists */
+    return domid > 0 && domid < DOMID_FIRST_RESERVED;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 08:47:04 2012 +0000
@@ -1230,19 +1230,19 @@ static int handle_domain_death(libxl_ctx
     libxl_action_on_shutdown action;
 
     switch (event->u.domain_shutdown.shutdown_reason) {
-    case SHUTDOWN_poweroff:
+    case LIBXL_SHUTDOWN_REASON_POWEROFF:
         action = d_config->on_poweroff;
         break;
-    case SHUTDOWN_reboot:
+    case LIBXL_SHUTDOWN_REASON_REBOOT:
         action = d_config->on_reboot;
         break;
-    case SHUTDOWN_suspend:
+    case LIBXL_SHUTDOWN_REASON_SUSPEND:
         LOG("Domain has suspended.");
         return 0;
-    case SHUTDOWN_crash:
+    case LIBXL_SHUTDOWN_REASON_CRASH:
         action = d_config->on_crash;
         break;
-    case SHUTDOWN_watchdog:
+    case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
     default:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:53:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UPM-0001XI-Mo; Thu, 23 Feb 2012 08:52:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UPK-0001Wq-8d
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:52:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1329987124!15441698!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17735 invoked from network); 23 Feb 2012 08:52:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 08:52:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10887998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:52:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:52:04 +0000
Message-ID: <1329987122.8557.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 08:52:02 +0000
In-Reply-To: <1329986720.8557.10.camel@zakaz.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<1329986720.8557.10.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 08:45 +0000, Ian Campbell wrote:
> On Wed, 2012-02-22 at 21:40 +0000, Jim Fehlig wrote:
> > Ian Jackson wrote:
> > > Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > >
> > >> Ian Jackson wrote:
> > >>
> > >>> Users of libxl should not be using libxc directly and therefore should
> > >>> not be including xenctrl.h.
> > >>>
> > > ...
> > >
> > >> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it?
> > >> it seems that add __XEN_TOOLS_ to libvirt code is not good.
> > >>
> > >
> > > Can you tell us the error message you get ?  I think the problem is
> > > probably that libvirt is trying to use libxc directly.
> > >
> >
> > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > is that libxl.h includes <xen/sysctl.h>, which has this
> >
> > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > #error "sysctl operations are intended for use by node control tools only"
> > #endif
> >
> > Without the defines, Bamvor is hitting the #error directive.
> 
> I thought we'd discussed and resolved this ages ago but I guess we only
> discussed it...
> 
> How about the following:

I also have the following, I think the benefits are less obvious for
this one though but it does mean we are consistently avoiding all xen
public headers in the libxl public API which at least has the benefit of
being simple to describe.

8<-------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1329986824 0
# Node ID ad39625c16966fe004c25e5be81af0e32cf8646a
# Parent  d256d6b42ee77cdff0356c37d6fcaf6203a21ba6
libxl: Remove xen/sched.h from public interface

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 08:47:04 2012 +0000
@@ -137,8 +137,6 @@
 
 #include <xentoollog.h>
 
-#include <xen/sched.h>
-
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
 
@@ -638,12 +636,7 @@ int libxl_cpupool_cpuremove(libxl_ctx *c
 int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
 
-static inline int libxl_domid_valid_guest(uint32_t domid)
-{
-    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
-     * does not check whether the domain actually exists */
-    return domid > 0 && domid < DOMID_FIRST_RESERVED;
-}
+int libxl_domid_valid_guest(uint32_t domid);
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
                                uint32_t *ssidref);
diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 08:47:04 2012 +0000
@@ -107,6 +107,15 @@ libxl_scheduler = Enumeration("scheduler
     (7, "arinc653"),
     ])
 
+# Consistent with SHUTDOWN_* in sched.h
+libxl_shutdown_reason = Enumeration("shutdown_reason", [
+    (0, "poweroff"),
+    (1, "reboot"),
+    (2, "suspend"),
+    (3, "crash"),
+    (4, "watchdog"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +163,7 @@ libxl_dominfo = Struct("dominfo",[
     #
     # Otherwise set to a value guaranteed not to clash with any valid
     # SHUTDOWN_* constant.
-    ("shutdown_reason", uint8),
+    ("shutdown_reason", libxl_shutdown_reason),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 08:47:04 2012 +0000
@@ -507,6 +507,13 @@ void libxl_cputopology_list_free(libxl_c
     free(list);
 }
 
+int libxl_domid_valid_guest(uint32_t domid)
+{
+    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
+     * does not check whether the domain actually exists */
+    return domid > 0 && domid < DOMID_FIRST_RESERVED;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r d256d6b42ee7 -r ad39625c1696 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 08:37:13 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 08:47:04 2012 +0000
@@ -1230,19 +1230,19 @@ static int handle_domain_death(libxl_ctx
     libxl_action_on_shutdown action;
 
     switch (event->u.domain_shutdown.shutdown_reason) {
-    case SHUTDOWN_poweroff:
+    case LIBXL_SHUTDOWN_REASON_POWEROFF:
         action = d_config->on_poweroff;
         break;
-    case SHUTDOWN_reboot:
+    case LIBXL_SHUTDOWN_REASON_REBOOT:
         action = d_config->on_reboot;
         break;
-    case SHUTDOWN_suspend:
+    case LIBXL_SHUTDOWN_REASON_SUSPEND:
         LOG("Domain has suspended.");
         return 0;
-    case SHUTDOWN_crash:
+    case LIBXL_SHUTDOWN_REASON_CRASH:
         action = d_config->on_crash;
         break;
-    case SHUTDOWN_watchdog:
+    case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
     default:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:58:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UVZ-0001zz-H9; Thu, 23 Feb 2012 08:58:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UVY-0001zk-2t
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:58:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329987509!14577274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 23 Feb 2012 08:58:30 -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;
	23 Feb 2012 08:58:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10888159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:58:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:58:29 +0000
Message-ID: <1329987508.8557.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 23 Feb 2012 08:58:28 +0000
In-Reply-To: <1329986957327-5507375.post@n5.nabble.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
 Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 08:49 +0000, Fantu wrote:
> #/var/log/xen/qemu-dm-PRECISEHVM.log
> bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory

Does /var/run/xen exist? IIRC this was an issue in some versions of the
Wheezy packages.

BTW, please could you try and quote some context in each of your posts
for those of us not reading via nabble. As it stands your posts are very
hard to follow due to the lack of context -- that requires me us skip up
and down the thread to figure out what is going on -- which, at least in
my case, makes it all the more likely that I'll get distracted by
something else.

In fact I would encourage you to post using a normal email client rather
than nabble -- you can subscribe, so that your posts go straight through
without moderation, but disable mail delivery in your mailman options if
you don't want to receive the full firehose of xen-devel -- we always CC
people with replies on this list so you won't miss anything in threads
which you start.

Ian.

> chardev: opening backend "socket" failed: No such file or directory
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:58:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UVZ-0001zz-H9; Thu, 23 Feb 2012 08:58:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UVY-0001zk-2t
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:58:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329987509!14577274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21170 invoked from network); 23 Feb 2012 08:58:30 -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;
	23 Feb 2012 08:58:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10888159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:58:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:58:29 +0000
Message-ID: <1329987508.8557.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Thu, 23 Feb 2012 08:58:28 +0000
In-Reply-To: <1329986957327-5507375.post@n5.nabble.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
 Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 08:49 +0000, Fantu wrote:
> #/var/log/xen/qemu-dm-PRECISEHVM.log
> bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory

Does /var/run/xen exist? IIRC this was an issue in some versions of the
Wheezy packages.

BTW, please could you try and quote some context in each of your posts
for those of us not reading via nabble. As it stands your posts are very
hard to follow due to the lack of context -- that requires me us skip up
and down the thread to figure out what is going on -- which, at least in
my case, makes it all the more likely that I'll get distracted by
something else.

In fact I would encourage you to post using a normal email client rather
than nabble -- you can subscribe, so that your posts go straight through
without moderation, but disable mail delivery in your mailman options if
you don't want to receive the full firehose of xen-devel -- we always CC
people with replies on this list so you won't miss anything in threads
which you start.

Ian.

> chardev: opening backend "socket" failed: No such file or directory
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:59:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UW9-00023W-3K; Thu, 23 Feb 2012 08:59:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UW7-00022e-Cc
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:59:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329987545!4166873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7518 invoked from network); 23 Feb 2012 08:59:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 08:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10888170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:59:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:59:05 +0000
Message-ID: <1329987543.8557.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 08:59:03 +0000
In-Reply-To: <4F456136.7070904@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F456136.7070904@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error	of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 21:42 +0000, Jim Fehlig wrote:
> Ian Jackson wrote:
> > Note that the API for libxl has changed in xen-unstable.hg compared to
> > 4.1, and further changes are forthcoming.  So there will have to be
> > changes in libvirt.
> >   
> 
> I suppose libvirt is the only out-of-tree libxl app feeling this pain :-(.

We're sorry about this, we felt it was necessary to break the API
between 4.1 and 4.2 in order that we can support a stable API from 4.2
onwards (I think we discussed this at the time?). From 4.2 onwards we
will make changes in a compatible way or provide compatibility shims etc
or in extreme circumstances do things in a way which is easily
detectable e.g. via configure tests.

I was wondering the other day if "libxl v2" support for libvirt might
make a nice GSoC project, what do you think? Would you be interested in
mentoring such a project?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 08:59:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 08:59:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UW9-00023W-3K; Thu, 23 Feb 2012 08:59:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0UW7-00022e-Cc
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 08:59:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1329987545!4166873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7518 invoked from network); 23 Feb 2012 08:59:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 08:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10888170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:59:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:59:05 +0000
Message-ID: <1329987543.8557.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 08:59:03 +0000
In-Reply-To: <4F456136.7070904@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F456136.7070904@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error	of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 21:42 +0000, Jim Fehlig wrote:
> Ian Jackson wrote:
> > Note that the API for libxl has changed in xen-unstable.hg compared to
> > 4.1, and further changes are forthcoming.  So there will have to be
> > changes in libvirt.
> >   
> 
> I suppose libvirt is the only out-of-tree libxl app feeling this pain :-(.

We're sorry about this, we felt it was necessary to break the API
between 4.1 and 4.2 in order that we can support a stable API from 4.2
onwards (I think we discussed this at the time?). From 4.2 onwards we
will make changes in a compatible way or provide compatibility shims etc
or in extreme circumstances do things in a way which is easily
detectable e.g. via configure tests.

I was wondering the other day if "libxl v2" support for libvirt might
make a nice GSoC project, what do you think? Would you be interested in
mentoring such a project?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:05:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0Ubh-0002QJ-1y; Thu, 23 Feb 2012 09:04:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ubf-0002QB-Jd
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:04:55 +0000
Received: from [85.158.139.83:19291] by server-8.bemta-5.messagelabs.com id
	93/A1-09797-631064F4; Thu, 23 Feb 2012 09:04:54 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329987892!16279006!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28750 invoked from network); 23 Feb 2012 09:04:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 09:04:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ubc-0007QQ-Ct
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 01:04:52 -0800
Date: Thu, 23 Feb 2012 01:04:52 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329987892392-5507435.post@n5.nabble.com>
In-Reply-To: <1329987508.8557.23.camel@zakaz.uk.xensource.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply.

ls /var/run/xen
xenconsoled.pid  xen-hotplug/     xenstored/       xenstored.pid


Ian Campbell-10 wrote
> 
> On Thu, 2012-02-23 at 08:49 +0000, Fantu wrote:
>> #/var/log/xen/qemu-dm-PRECISEHVM.log
>> bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory
> 
> Does /var/run/xen exist? IIRC this was an issue in some versions of the
> Wheezy packages.
> 
> BTW, please could you try and quote some context in each of your posts
> for those of us not reading via nabble. As it stands your posts are very
> hard to follow due to the lack of context -- that requires me us skip up
> and down the thread to figure out what is going on -- which, at least in
> my case, makes it all the more likely that I'll get distracted by
> something else.
> 
> In fact I would encourage you to post using a normal email client rather
> than nabble -- you can subscribe, so that your posts go straight through
> without moderation, but disable mail delivery in your mailman options if
> you don't want to receive the full firehose of xen-devel -- we always CC
> people with replies on this list so you won't miss anything in threads
> which you start.
> 
> Ian.
> 
>> chardev: opening backend "socket" failed: No such file or directory
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Fantu wrote
> 
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> And also this change for lib patch modified with multiarch support:
> vi config/StdGNU.mk
> LIBLEAFDIR_x86_64 ?= lib
> 
> DomUs PV working, domUs with qemu-upstream not start.
> 
> The xl configuration file:
> ---------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/sr0,raw,hdb,ro,cdrom']
> boot='c'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #stdvga=1
> #videoram=16
> sdl=0
> #spice=1
> #spicehost='192.168.1.137'
> #spiceport=6000
> #spicepasswd='test'
> #on_crash='preserve'
> ---------------------------------
> 
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model
> died during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> The same with change only device_model_version to qemu-xen-traditional
> work
> 
> 
> If you need more test and data ask me and I will do and post.
> Thanks for any reply and sorry for bad english.
> 

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507435.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:05:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0Ubh-0002QJ-1y; Thu, 23 Feb 2012 09:04:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ubf-0002QB-Jd
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:04:55 +0000
Received: from [85.158.139.83:19291] by server-8.bemta-5.messagelabs.com id
	93/A1-09797-631064F4; Thu, 23 Feb 2012 09:04:54 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1329987892!16279006!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28750 invoked from network); 23 Feb 2012 09:04:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 09:04:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ubc-0007QQ-Ct
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 01:04:52 -0800
Date: Thu, 23 Feb 2012 01:04:52 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329987892392-5507435.post@n5.nabble.com>
In-Reply-To: <1329987508.8557.23.camel@zakaz.uk.xensource.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply.

ls /var/run/xen
xenconsoled.pid  xen-hotplug/     xenstored/       xenstored.pid


Ian Campbell-10 wrote
> 
> On Thu, 2012-02-23 at 08:49 +0000, Fantu wrote:
>> #/var/log/xen/qemu-dm-PRECISEHVM.log
>> bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory
> 
> Does /var/run/xen exist? IIRC this was an issue in some versions of the
> Wheezy packages.
> 
> BTW, please could you try and quote some context in each of your posts
> for those of us not reading via nabble. As it stands your posts are very
> hard to follow due to the lack of context -- that requires me us skip up
> and down the thread to figure out what is going on -- which, at least in
> my case, makes it all the more likely that I'll get distracted by
> something else.
> 
> In fact I would encourage you to post using a normal email client rather
> than nabble -- you can subscribe, so that your posts go straight through
> without moderation, but disable mail delivery in your mailman options if
> you don't want to receive the full firehose of xen-devel -- we always CC
> people with replies on this list so you won't miss anything in threads
> which you start.
> 
> Ian.
> 
>> chardev: opening backend "socket" failed: No such file or directory
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Fantu wrote
> 
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> And also this change for lib patch modified with multiarch support:
> vi config/StdGNU.mk
> LIBLEAFDIR_x86_64 ?= lib
> 
> DomUs PV working, domUs with qemu-upstream not start.
> 
> The xl configuration file:
> ---------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/sr0,raw,hdb,ro,cdrom']
> boot='c'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #stdvga=1
> #videoram=16
> sdl=0
> #spice=1
> #spicehost='192.168.1.137'
> #spiceport=6000
> #spicepasswd='test'
> #on_crash='preserve'
> ---------------------------------
> 
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model
> died during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> The same with change only device_model_version to qemu-xen-traditional
> work
> 
> 
> If you need more test and data ask me and I will do and post.
> Thanks for any reply and sorry for bad english.
> 

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507435.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:06:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ud8-0002V2-HQ; Thu, 23 Feb 2012 09:06:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ud6-0002Uj-QR
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:06:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329987976!6423774!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19466 invoked from network); 23 Feb 2012 09:06:18 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 09:06:18 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ucy-0007iH-Dw
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 01:06:16 -0800
Date: Thu, 23 Feb 2012 01:06:15 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329987975739-5507438.post@n5.nabble.com>
In-Reply-To: <1329987508.8557.23.camel@zakaz.uk.xensource.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply.

ls /var/run/xen
xenconsoled.pid  xen-hotplug/     xenstored/       xenstored.pid


Ian Campbell-10 wrote
> 
> On Thu, 2012-02-23 at 08:49 +0000, Fantu wrote:
>> #/var/log/xen/qemu-dm-PRECISEHVM.log
>> bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory
> 
> Does /var/run/xen exist? IIRC this was an issue in some versions of the
> Wheezy packages.
> 
> BTW, please could you try and quote some context in each of your posts
> for those of us not reading via nabble. As it stands your posts are very
> hard to follow due to the lack of context -- that requires me us skip up
> and down the thread to figure out what is going on -- which, at least in
> my case, makes it all the more likely that I'll get distracted by
> something else.
> 
> In fact I would encourage you to post using a normal email client rather
> than nabble -- you can subscribe, so that your posts go straight through
> without moderation, but disable mail delivery in your mailman options if
> you don't want to receive the full firehose of xen-devel -- we always CC
> people with replies on this list so you won't miss anything in threads
> which you start.
> 
> Ian.
> 
>> chardev: opening backend "socket" failed: No such file or directory
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Fantu wrote
> 
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> And also this change for lib patch modified with multiarch support:
> vi config/StdGNU.mk
> LIBLEAFDIR_x86_64 ?= lib
> 
> DomUs PV working, domUs with qemu-upstream not start.
> 
> The xl configuration file:
> ---------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/sr0,raw,hdb,ro,cdrom']
> boot='c'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #stdvga=1
> #videoram=16
> sdl=0
> #spice=1
> #spicehost='192.168.1.137'
> #spiceport=6000
> #spicepasswd='test'
> #on_crash='preserve'
> ---------------------------------
> 
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model
> died during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> The same with change only device_model_version to qemu-xen-traditional
> work
> 
> 
> If you need more test and data ask me and I will do and post.
> Thanks for any reply and sorry for bad english.
> 

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507438.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:06:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ud8-0002V2-HQ; Thu, 23 Feb 2012 09:06:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ud6-0002Uj-QR
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:06:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329987976!6423774!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19466 invoked from network); 23 Feb 2012 09:06:18 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 09:06:18 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0Ucy-0007iH-Dw
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 01:06:16 -0800
Date: Thu, 23 Feb 2012 01:06:15 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1329987975739-5507438.post@n5.nabble.com>
In-Reply-To: <1329987508.8557.23.camel@zakaz.uk.xensource.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for reply.

ls /var/run/xen
xenconsoled.pid  xen-hotplug/     xenstored/       xenstored.pid


Ian Campbell-10 wrote
> 
> On Thu, 2012-02-23 at 08:49 +0000, Fantu wrote:
>> #/var/log/xen/qemu-dm-PRECISEHVM.log
>> bind(unix:/var/run/xen/qmp-libxl-2): No such file or directory
> 
> Does /var/run/xen exist? IIRC this was an issue in some versions of the
> Wheezy packages.
> 
> BTW, please could you try and quote some context in each of your posts
> for those of us not reading via nabble. As it stands your posts are very
> hard to follow due to the lack of context -- that requires me us skip up
> and down the thread to figure out what is going on -- which, at least in
> my case, makes it all the more likely that I'll get distracted by
> something else.
> 
> In fact I would encourage you to post using a normal email client rather
> than nabble -- you can subscribe, so that your posts go straight through
> without moderation, but disable mail delivery in your mailman options if
> you don't want to receive the full firehose of xen-devel -- we always CC
> people with replies on this list so you won't miss anything in threads
> which you start.
> 
> Ian.
> 
>> chardev: opening backend "socket" failed: No such file or directory
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507375.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Fantu wrote
> 
> Dom0 is Wheezy 64 bit with kernel 3.2.0-1-amd64 version 3.2.4-1, xen from
> xen-unstable.hg changeset 24858:a88ba599add1 plus these patch for not fail
> build:
> http://xen.1045712.n5.nabble.com/PATCH-0-of-2-rename-libxl-yajl-gen-alloc-td5469362.html
> And also this change for lib patch modified with multiarch support:
> vi config/StdGNU.mk
> LIBLEAFDIR_x86_64 ?= lib
> 
> DomUs PV working, domUs with qemu-upstream not start.
> 
> The xl configuration file:
> ---------------------------------
> name='PRECISEHVM'
> builder="hvm"
> memory=1024
> vcpus=2
> hap=1
> pae=1
> acpi=1
> apic=1
> nx=1
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"']
> disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',
> '/dev/sr0,raw,hdb,ro,cdrom']
> boot='c'
> xen_platform_pci=1
> device_model_version='qemu-xen'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> keymap="it"
> #stdvga=1
> #videoram=16
> sdl=0
> #spice=1
> #spicehost='192.168.1.137'
> #spiceport=6000
> #spicepasswd='test'
> #on_crash='preserve'
> ---------------------------------
> 
> xl create /etc/xen/PRECISEHVM.cfg
> Parsing config file /etc/xen/PRECISEHVM.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019dc88
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_qmp.c:638:libxl__qmp_initialize: Connection error: No
> such file or directory
> libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model
> died during startup
> libxl: error: libxl_create.c:602:do_domain_create: device model did not
> start: -1
> 
> The same with change only device_model_version to qemu-xen-traditional
> work
> 
> 
> If you need more test and data ask me and I will do and post.
> Thanks for any reply and sorry for bad english.
> 

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5507438.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:08:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UfG-0002dO-1t; Thu, 23 Feb 2012 09:08:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1S0UfE-0002cx-F3
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:08:36 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329988071!53628027!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 688 invoked from network); 23 Feb 2012 09:07:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 09:07:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 09:08:33 +0000
Message-Id: <4F46020C020000780007F6F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 09:08:28 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <avscomputing@gmail.com>,<konrad.wilk@oracle.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
	<20120221165830.GA32413@phenom.dumpdata.com>
	<CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
In-Reply-To: <CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IEFudG9uIFNhbXNvbm92IDxhdnNjb21wdXRpbmdAZ21haWwuY29tPiAwMi8yMi8xMiAxMTo0
NiBQTSA+Pj4KPkFzIGFuIGV4YW1wbGUgb2YgdGhlIGxhdHRlciwgbG9vayBhZ2FpbiBhdCB0aGUg
Tm92ZWxsIEJaICM3MjcwODEgbWVudGlvbmVkCj5pbiB0aGUgb3JpZ2luYWwgcG9zdCDigJQgdGhl
IGNvbW1lbnQgIzMwIHNheXM6ICJUaGUgY29tcGlsZXIgYXBwYXJlbnRseSBtYWtlcyB1c2UKPm9m
IHRoZSAxMjgtYnl0ZSBhcmVhIGNhbGxlZCAncmVkIHpvbmUnIGluIHRoZSBBQkksIGFuZCB0aGlz
IGlzIGluY29tcGF0aWJsZQo+d2l0aCB4Y19jcHVpZF94ODYuYzpjcHVpZCgpIHVzaW5nIHB1c2hl
cyBhbmQgcG9wcyBhcm91bmQgdGhlIGNwdWlkIGluc3RydWN0aW9uIi4KPlRoZSBjb25zZXF1ZW5j
ZSBpcyB0aGF0LCBvbiBzb21lIG1hY2hpbmVzLCBsaWJ4ZW5ndWVzdCBzZWdmYXVsdHMgd2hlbiB5
b3UKPnRyeSB0byBzdGFydCBhIERvbVUuIFdpdGggQ29yZSBpNy05MjAgdGhlcmUgaXMgbm8gcHJv
YmxlbSwgYnV0IHdpdGggQ29yZSBpNS0yMzAwCj5JIGZhY2VkIHRoYXQgaXNzdWUsIGFuZCB3b25k
ZXIgd2hldGhlciB0aGUgc2FtZSBpbmNvbXBhdGliaWxpdHkgY2FuIHRha2UgcGxhY2UKPmluIG5l
dGJhY2sgbW9kdWxlLiBJIHRob3VnaCB0aGUgdHJhY2ViYWNrIGdpdmVzIHNvbWUgaGludHMgb24g
d2hlcmUgdG8gZGVidWcuCgpUaGF0J3MgaW1wb3NzaWJsZSAtIHVzZSBvZiB0aGUgcmVkIHpvbmUg
aXMgZGlzYWxsb3dlZCBpbiB0aGUga2VybmVsIHZpYSBjb21waWxlcgpvcHRpb24uIEFuZCB0aGUg
cHJvYmxlbSB5b3UgY2l0ZSB3YXMgYSBzb3VyY2UgY29kZSBwcm9ibGVtLCBub3QgYSBjb21waWxl
cgpvbmUgKHRoZSBmYWN0IHRoYXQgaXQgaGFkIGFuIGVmZmVjdCBvbmx5IG9uIHNvbWUgc3lzdGVt
cyB3YXMgYXR0cmlidXRlZCB0byB0aGUKZnVuY3Rpb24gaW4gcXVlc3Rpb24gb25seSBnZXR0aW5n
IHJ1biB3aGVuIGEgc3BlY2lmaWMgaGFyZHdhcmUgZmVhdHVyZSB3YXMKYXZhaWxhYmxlIGlpcmMp
LgoKSmFuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:08:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UfG-0002dO-1t; Thu, 23 Feb 2012 09:08:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1S0UfE-0002cx-F3
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:08:36 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329988071!53628027!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 688 invoked from network); 23 Feb 2012 09:07:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 09:07:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 09:08:33 +0000
Message-Id: <4F46020C020000780007F6F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 09:08:28 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <avscomputing@gmail.com>,<konrad.wilk@oracle.com>
References: <CALtE5pkBhJ_GzVBbuMuuH0vvaHSSCnHzR-vvazhygQAsWb=2aA@mail.gmail.com>
	<20120209211316.GD14007@andromeda.dapyr.net>
	<CALtE5pmfz_7sF4fRJUyYtDub+ARo4yoozhOn9JVEvsB7FAnv_A@mail.gmail.com>
	<20120215183122.GO12984@reaktio.net>
	<CALtE5p=vdM-3myFDpAFQb2Fq7RW_v0B8ipFp2ai1kL2OO1oLXg@mail.gmail.com>
	<20120221165830.GA32413@phenom.dumpdata.com>
	<CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
In-Reply-To: <CALtE5pnhX7X83PV_XKyon8Z0-RU4BHAvrmtg+yQ2DH72HEkyKg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] General protection fault in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IEFudG9uIFNhbXNvbm92IDxhdnNjb21wdXRpbmdAZ21haWwuY29tPiAwMi8yMi8xMiAxMTo0
NiBQTSA+Pj4KPkFzIGFuIGV4YW1wbGUgb2YgdGhlIGxhdHRlciwgbG9vayBhZ2FpbiBhdCB0aGUg
Tm92ZWxsIEJaICM3MjcwODEgbWVudGlvbmVkCj5pbiB0aGUgb3JpZ2luYWwgcG9zdCDigJQgdGhl
IGNvbW1lbnQgIzMwIHNheXM6ICJUaGUgY29tcGlsZXIgYXBwYXJlbnRseSBtYWtlcyB1c2UKPm9m
IHRoZSAxMjgtYnl0ZSBhcmVhIGNhbGxlZCAncmVkIHpvbmUnIGluIHRoZSBBQkksIGFuZCB0aGlz
IGlzIGluY29tcGF0aWJsZQo+d2l0aCB4Y19jcHVpZF94ODYuYzpjcHVpZCgpIHVzaW5nIHB1c2hl
cyBhbmQgcG9wcyBhcm91bmQgdGhlIGNwdWlkIGluc3RydWN0aW9uIi4KPlRoZSBjb25zZXF1ZW5j
ZSBpcyB0aGF0LCBvbiBzb21lIG1hY2hpbmVzLCBsaWJ4ZW5ndWVzdCBzZWdmYXVsdHMgd2hlbiB5
b3UKPnRyeSB0byBzdGFydCBhIERvbVUuIFdpdGggQ29yZSBpNy05MjAgdGhlcmUgaXMgbm8gcHJv
YmxlbSwgYnV0IHdpdGggQ29yZSBpNS0yMzAwCj5JIGZhY2VkIHRoYXQgaXNzdWUsIGFuZCB3b25k
ZXIgd2hldGhlciB0aGUgc2FtZSBpbmNvbXBhdGliaWxpdHkgY2FuIHRha2UgcGxhY2UKPmluIG5l
dGJhY2sgbW9kdWxlLiBJIHRob3VnaCB0aGUgdHJhY2ViYWNrIGdpdmVzIHNvbWUgaGludHMgb24g
d2hlcmUgdG8gZGVidWcuCgpUaGF0J3MgaW1wb3NzaWJsZSAtIHVzZSBvZiB0aGUgcmVkIHpvbmUg
aXMgZGlzYWxsb3dlZCBpbiB0aGUga2VybmVsIHZpYSBjb21waWxlcgpvcHRpb24uIEFuZCB0aGUg
cHJvYmxlbSB5b3UgY2l0ZSB3YXMgYSBzb3VyY2UgY29kZSBwcm9ibGVtLCBub3QgYSBjb21waWxl
cgpvbmUgKHRoZSBmYWN0IHRoYXQgaXQgaGFkIGFuIGVmZmVjdCBvbmx5IG9uIHNvbWUgc3lzdGVt
cyB3YXMgYXR0cmlidXRlZCB0byB0aGUKZnVuY3Rpb24gaW4gcXVlc3Rpb24gb25seSBnZXR0aW5n
IHJ1biB3aGVuIGEgc3BlY2lmaWMgaGFyZHdhcmUgZmVhdHVyZSB3YXMKYXZhaWxhYmxlIGlpcmMp
LgoKSmFuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:11:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:11:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Uhc-0002oA-JR; Thu, 23 Feb 2012 09:11:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Uha-0002o3-2e
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:11:02 +0000
Received: from [85.158.139.83:12284] by server-6.bemta-5.messagelabs.com id
	50/8E-27305-5A2064F4; Thu, 23 Feb 2012 09:11:01 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329988257!16239966!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30879 invoked from network); 23 Feb 2012 09:10:59 -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; 23 Feb 2012 09:10:59 -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 q1N9AtXm012684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:10: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
	q1N9AsKe013032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:10:55 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
	q1N9Ar8a021353; Thu, 23 Feb 2012 03:10:54 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:10:53 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:11:23 +0800
Message-Id: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F4602A1.0047,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 0/5] xen: patches for supporting efi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

The following patches introduce and implement efi support in dom0.
The efi memory is owned by Xen and efi run-time service can not be called 
directly in dom0, so a new efi driver is needed by Xen efi. 
These patches are based on v3.3.0-rc2+. 

Descriptions for these patches:

The efi public functions are changed to function pointers in efi_init_funcs 
struct. They act as efi generic functions as default. 
As a benefit from this change, we can register xen efi init func. 

In order to add xen efi video support, it is required to add xen-efi's 
new video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga 
and set the video type to VIDEO_TYPE_EFI to enable efi video mode. 

I have tested this patch on Dell Opti 790.

Xen efi boot support is added by Jan Beulich, more detail information can be 
gotten from the url: 
http://wiki.xen.org/xenwiki/XenParavirtOps, search "efi" in the page.

The example of config file for efi boot:
kernel=vmlinuz-3.3.0-rc2+ root=xx ro console=tty0
ramdisk=initramfs-3.3.0-rc2+.img
video=gfx-x.0 

The detailed test which i have done: 
First, Check efifb driver work well or not and check the kernel messesge ro
see the follow info:
[    0.576705] efifb: probing for efifb
[    0.577357] efifb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 3752k, total 65472k
[    0.577360] efifb: mode is 800x600x32, linelength=3200, pages=1
[    0.577362] efifb: scrolling: redraw
[    0.577364] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 

Second, Check efi systab and variable is work well or not. 
cat the information in /sys/firmware/efi to check the efi systab and variable 
is right or not. 
 
Third, Run Linux firmware testing tools which is downloaded from this Url.
http://linuxfirmwarekit.org/download.php 

Jan Beulich (1):
      EFI: add efi driver for Xen efi

Tang Liang (4):
      EFI: Provide registration for efi_init.. etc efi public      function
      EFI: seperate get efi table info code to single function
      Xen efi: Add xen efi enabled detect
      Xen vga: add the xen efi video mode support

 arch/x86/platform/efi/Makefile   |    2 +-
 arch/x86/platform/efi/efi-xen.c  |  460 ++++++++++++++++++++++++++++++++++++++
 arch/x86/platform/efi/efi.c      |   63 +++++-
 arch/x86/xen/enlighten.c         |    3 +
 arch/x86/xen/vga.c               |    7 +
 include/linux/efi.h              |   14 +-
 include/xen/interface/platform.h |  122 ++++++++++
 include/xen/interface/xen.h      |    1 +
 8 files changed, 665 insertions(+), 7 deletions(-)

Thanks
Liang.
-- 
1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:11:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:11:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Uhc-0002oA-JR; Thu, 23 Feb 2012 09:11:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Uha-0002o3-2e
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:11:02 +0000
Received: from [85.158.139.83:12284] by server-6.bemta-5.messagelabs.com id
	50/8E-27305-5A2064F4; Thu, 23 Feb 2012 09:11:01 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1329988257!16239966!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30879 invoked from network); 23 Feb 2012 09:10:59 -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; 23 Feb 2012 09:10:59 -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 q1N9AtXm012684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:10: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
	q1N9AsKe013032
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:10:55 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
	q1N9Ar8a021353; Thu, 23 Feb 2012 03:10:54 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:10:53 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:11:23 +0800
Message-Id: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F4602A1.0047,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 0/5] xen: patches for supporting efi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi

The following patches introduce and implement efi support in dom0.
The efi memory is owned by Xen and efi run-time service can not be called 
directly in dom0, so a new efi driver is needed by Xen efi. 
These patches are based on v3.3.0-rc2+. 

Descriptions for these patches:

The efi public functions are changed to function pointers in efi_init_funcs 
struct. They act as efi generic functions as default. 
As a benefit from this change, we can register xen efi init func. 

In order to add xen efi video support, it is required to add xen-efi's 
new video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga 
and set the video type to VIDEO_TYPE_EFI to enable efi video mode. 

I have tested this patch on Dell Opti 790.

Xen efi boot support is added by Jan Beulich, more detail information can be 
gotten from the url: 
http://wiki.xen.org/xenwiki/XenParavirtOps, search "efi" in the page.

The example of config file for efi boot:
kernel=vmlinuz-3.3.0-rc2+ root=xx ro console=tty0
ramdisk=initramfs-3.3.0-rc2+.img
video=gfx-x.0 

The detailed test which i have done: 
First, Check efifb driver work well or not and check the kernel messesge ro
see the follow info:
[    0.576705] efifb: probing for efifb
[    0.577357] efifb: framebuffer at 0xd0000000, mapped to 0xffffc90005800000, using 3752k, total 65472k
[    0.577360] efifb: mode is 800x600x32, linelength=3200, pages=1
[    0.577362] efifb: scrolling: redraw
[    0.577364] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 

Second, Check efi systab and variable is work well or not. 
cat the information in /sys/firmware/efi to check the efi systab and variable 
is right or not. 
 
Third, Run Linux firmware testing tools which is downloaded from this Url.
http://linuxfirmwarekit.org/download.php 

Jan Beulich (1):
      EFI: add efi driver for Xen efi

Tang Liang (4):
      EFI: Provide registration for efi_init.. etc efi public      function
      EFI: seperate get efi table info code to single function
      Xen efi: Add xen efi enabled detect
      Xen vga: add the xen efi video mode support

 arch/x86/platform/efi/Makefile   |    2 +-
 arch/x86/platform/efi/efi-xen.c  |  460 ++++++++++++++++++++++++++++++++++++++
 arch/x86/platform/efi/efi.c      |   63 +++++-
 arch/x86/xen/enlighten.c         |    3 +
 arch/x86/xen/vga.c               |    7 +
 include/linux/efi.h              |   14 +-
 include/xen/interface/platform.h |  122 ++++++++++
 include/xen/interface/xen.h      |    1 +
 8 files changed, 665 insertions(+), 7 deletions(-)

Thanks
Liang.
-- 
1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ujf-0002xe-5a; Thu, 23 Feb 2012 09:13:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Uje-0002xI-6q
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:10 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329988330!53941271!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30831 invoked from network); 23 Feb 2012 09:12:12 -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; 23 Feb 2012 09:12:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1N9D2cE014802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1N9D1oa012342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:02 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
	q1N9D1Vu024018; Thu, 23 Feb 2012 03:13:01 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:01 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:13:30 +0800
Message-Id: <1329988410-26930-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F460320.000A,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 2/5V2] EFI: seperate get efi table info code to
	single 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

Seperate get efi table info code to generic function,
xen efi driver will call it too.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Suggested-by:: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/platform/efi/efi.c |   77 ++++++++++++++++++++++++-------------------
 include/linux/efi.h         |    2 +
 2 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index dd690e6..dcb7842 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -447,6 +447,47 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
+void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			struct efi *efi_t)
+{
+	int i;
+
+	printk(KERN_INFO);
+	for (i = 0; i < nr_tables; i++) {
+		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
+			efi_t->mps = config_tables[i].table;
+			printk(" MPS=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_20_TABLE_GUID)) {
+			efi_t->acpi20 = config_tables[i].table;
+			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_TABLE_GUID)) {
+			efi_t->acpi = config_tables[i].table;
+			printk(" ACPI=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					SMBIOS_TABLE_GUID)) {
+			efi_t->smbios = config_tables[i].table;
+			printk(" SMBIOS=0x%lx ", config_tables[i].table);
+#ifdef CONFIG_X86_UV
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UV_SYSTEM_TABLE_GUID)) {
+			efi_t->uv_systab = config_tables[i].table;
+			printk(" UVsystab=0x%lx ", config_tables[i].table);
+#endif
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					HCDP_TABLE_GUID)) {
+			efi_t->hcdp = config_tables[i].table;
+			printk(" HCDP=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UGA_IO_PROTOCOL_GUID)) {
+			efi_t->uga = config_tables[i].table;
+			printk(" UGA=0x%lx ", config_tables[i].table);
+		}
+	}
+	printk("\n");
+}
+
 static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
@@ -508,40 +549,8 @@ static void efi_init_generic(void)
 	if (config_tables == NULL)
 		printk(KERN_ERR "Could not map EFI Configuration Table!\n");
 
-	printk(KERN_INFO);
-	for (i = 0; i < efi.systab->nr_tables; i++) {
-		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
-			efi.mps = config_tables[i].table;
-			printk(" MPS=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_20_TABLE_GUID)) {
-			efi.acpi20 = config_tables[i].table;
-			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_TABLE_GUID)) {
-			efi.acpi = config_tables[i].table;
-			printk(" ACPI=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					SMBIOS_TABLE_GUID)) {
-			efi.smbios = config_tables[i].table;
-			printk(" SMBIOS=0x%lx ", config_tables[i].table);
-#ifdef CONFIG_X86_UV
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UV_SYSTEM_TABLE_GUID)) {
-			efi.uv_systab = config_tables[i].table;
-			printk(" UVsystab=0x%lx ", config_tables[i].table);
-#endif
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					HCDP_TABLE_GUID)) {
-			efi.hcdp = config_tables[i].table;
-			printk(" HCDP=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UGA_IO_PROTOCOL_GUID)) {
-			efi.uga = config_tables[i].table;
-			printk(" UGA=0x%lx ", config_tables[i].table);
-		}
-	}
-	printk("\n");
+	get_efi_table_info(config_tables, efi.systab->nr_tables, &efi);
+
 	early_iounmap(config_tables,
 			  efi.systab->nr_tables * sizeof(efi_config_table_t));
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 469ac66..4276c96 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -475,6 +475,8 @@ extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
 extern void efi_init_function_register(const struct efi_init_funcs *funcs);
+extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			       struct efi *efi_t);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ujf-0002xe-5a; Thu, 23 Feb 2012 09:13:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Uje-0002xI-6q
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:10 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1329988330!53941271!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30831 invoked from network); 23 Feb 2012 09:12:12 -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; 23 Feb 2012 09:12:12 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1N9D2cE014802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1N9D1oa012342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:02 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
	q1N9D1Vu024018; Thu, 23 Feb 2012 03:13:01 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:01 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:13:30 +0800
Message-Id: <1329988410-26930-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F460320.000A,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 2/5V2] EFI: seperate get efi table info code to
	single 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

Seperate get efi table info code to generic function,
xen efi driver will call it too.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Suggested-by:: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/platform/efi/efi.c |   77 ++++++++++++++++++++++++-------------------
 include/linux/efi.h         |    2 +
 2 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index dd690e6..dcb7842 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -447,6 +447,47 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
+void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			struct efi *efi_t)
+{
+	int i;
+
+	printk(KERN_INFO);
+	for (i = 0; i < nr_tables; i++) {
+		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
+			efi_t->mps = config_tables[i].table;
+			printk(" MPS=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_20_TABLE_GUID)) {
+			efi_t->acpi20 = config_tables[i].table;
+			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					ACPI_TABLE_GUID)) {
+			efi_t->acpi = config_tables[i].table;
+			printk(" ACPI=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					SMBIOS_TABLE_GUID)) {
+			efi_t->smbios = config_tables[i].table;
+			printk(" SMBIOS=0x%lx ", config_tables[i].table);
+#ifdef CONFIG_X86_UV
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UV_SYSTEM_TABLE_GUID)) {
+			efi_t->uv_systab = config_tables[i].table;
+			printk(" UVsystab=0x%lx ", config_tables[i].table);
+#endif
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					HCDP_TABLE_GUID)) {
+			efi_t->hcdp = config_tables[i].table;
+			printk(" HCDP=0x%lx ", config_tables[i].table);
+		} else if (!efi_guidcmp(config_tables[i].guid,
+					UGA_IO_PROTOCOL_GUID)) {
+			efi_t->uga = config_tables[i].table;
+			printk(" UGA=0x%lx ", config_tables[i].table);
+		}
+	}
+	printk("\n");
+}
+
 static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
@@ -508,40 +549,8 @@ static void efi_init_generic(void)
 	if (config_tables == NULL)
 		printk(KERN_ERR "Could not map EFI Configuration Table!\n");
 
-	printk(KERN_INFO);
-	for (i = 0; i < efi.systab->nr_tables; i++) {
-		if (!efi_guidcmp(config_tables[i].guid, MPS_TABLE_GUID)) {
-			efi.mps = config_tables[i].table;
-			printk(" MPS=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_20_TABLE_GUID)) {
-			efi.acpi20 = config_tables[i].table;
-			printk(" ACPI 2.0=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					ACPI_TABLE_GUID)) {
-			efi.acpi = config_tables[i].table;
-			printk(" ACPI=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					SMBIOS_TABLE_GUID)) {
-			efi.smbios = config_tables[i].table;
-			printk(" SMBIOS=0x%lx ", config_tables[i].table);
-#ifdef CONFIG_X86_UV
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UV_SYSTEM_TABLE_GUID)) {
-			efi.uv_systab = config_tables[i].table;
-			printk(" UVsystab=0x%lx ", config_tables[i].table);
-#endif
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					HCDP_TABLE_GUID)) {
-			efi.hcdp = config_tables[i].table;
-			printk(" HCDP=0x%lx ", config_tables[i].table);
-		} else if (!efi_guidcmp(config_tables[i].guid,
-					UGA_IO_PROTOCOL_GUID)) {
-			efi.uga = config_tables[i].table;
-			printk(" UGA=0x%lx ", config_tables[i].table);
-		}
-	}
-	printk("\n");
+	get_efi_table_info(config_tables, efi.systab->nr_tables, &efi);
+
 	early_iounmap(config_tables,
 			  efi.systab->nr_tables * sizeof(efi_config_table_t));
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 469ac66..4276c96 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -475,6 +475,8 @@ extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
 extern void efi_init_function_register(const struct efi_init_funcs *funcs);
+extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
+			       struct efi *efi_t);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ujg-0002y6-NT; Thu, 23 Feb 2012 09:13:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Ujf-0002xF-Ea
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:11 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329988384!15991904!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11069 invoked from network); 23 Feb 2012 09:13: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; 23 Feb 2012 09:13:05 -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 q1N9CWq6014476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:12:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1N9CVk0011567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:12:31 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
	q1N9CUQK002369; Thu, 23 Feb 2012 03:12:30 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:12:30 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:12:58 +0800
Message-Id: <1329988378-26895-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A02020A.4F460301.00B7,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 1/5V2] EFI: Provide registration for efi_init..
	etc efi public 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

The efi public functions are changed to function pointer in efi_init_funcs
struct.
They act as efi generic functions as default.
As a benefit from this change, we can register xen efi init func.

[v2: Fixed compile issues spotted by Konrad,
change variables defined suggested by Jan]

Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/efi.c |   66 +++++++++++++++++++++++++++++++++++++++---
 include/linux/efi.h         |   11 +++++++
 2 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 4cf9bd0..dd690e6 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -50,6 +50,24 @@
 #define PFX 		"EFI: "
 
 int efi_enabled;
+
+static void efi_init_generic(void);
+
+static void efi_enter_virtual_mode_generic(void);
+static u32 efi_mem_type_generic(unsigned long phys_addr);
+static u64 efi_mem_attributes_generic(unsigned long phys_addr);
+static void efi_reserve_boot_services_generic(void);
+
+static const struct efi_init_funcs efi_generic_funcs = {
+	.efi_init		     = efi_init_generic,
+	.efi_reserve_boot_services = efi_reserve_boot_services_generic,
+	.efi_enter_virtual_mode    = efi_enter_virtual_mode_generic,
+	.efi_mem_type		     = efi_mem_type_generic,
+	.efi_mem_attributes	     = efi_mem_attributes_generic
+};
+
+const struct efi_init_funcs *efi_override_funcs =  &efi_generic_funcs;
+
 EXPORT_SYMBOL(efi_enabled);
 
 struct efi __read_mostly efi = {
@@ -376,7 +394,7 @@ static void __init print_efi_memmap(void)
 }
 #endif  /*  EFI_DEBUG  */
 
-void __init efi_reserve_boot_services(void)
+static void efi_reserve_boot_services_generic(void)
 {
 	void *p;
 
@@ -429,7 +447,7 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
-void __init efi_init(void)
+static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
 	efi_runtime_services_t *runtime;
@@ -618,7 +636,7 @@ static void __init runtime_code_page_mkexec(void)
  * This enables the runtime services to be called without having to
  * thunk back into physical mode for every invocation.
  */
-void __init efi_enter_virtual_mode(void)
+static void efi_enter_virtual_mode_generic(void)
 {
 	efi_memory_desc_t *md, *prev_md = NULL;
 	efi_status_t status;
@@ -752,7 +770,7 @@ void __init efi_enter_virtual_mode(void)
 /*
  * Convenience functions to obtain memory types and attributes
  */
-u32 efi_mem_type(unsigned long phys_addr)
+static u32 efi_mem_type_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -767,7 +785,7 @@ u32 efi_mem_type(unsigned long phys_addr)
 	return 0;
 }
 
-u64 efi_mem_attributes(unsigned long phys_addr)
+static u64 efi_mem_attributes_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -781,3 +799,41 @@ u64 efi_mem_attributes(unsigned long phys_addr)
 	}
 	return 0;
 }
+
+void efi_init_function_register(const struct efi_init_funcs *funcs)
+{
+	efi_override_funcs = funcs;
+}
+
+void __init efi_init(void)
+{
+	if (efi_override_funcs->efi_init)
+		efi_override_funcs->efi_init();
+}
+
+void __init efi_reserve_boot_services(void)
+{
+	if (efi_override_funcs->efi_reserve_boot_services)
+		efi_override_funcs->efi_reserve_boot_services();
+}
+
+void __init efi_enter_virtual_mode(void)
+{
+	if (efi_override_funcs->efi_enter_virtual_mode)
+		efi_override_funcs->efi_enter_virtual_mode();
+}
+
+
+u32 efi_mem_type(unsigned long phys_addr)
+{
+	if (efi_override_funcs->efi_mem_type)
+		return efi_override_funcs->efi_mem_type(phys_addr);
+	return EFI_INVALID_TYPE;
+}
+
+u64 efi_mem_attributes(unsigned long phys_addr)
+{
+	if (efi_override_funcs->efi_mem_attributes)
+		return efi_override_funcs->efi_mem_attributes(phys_addr);
+	return EFI_INVALID_ATTRIBUTE;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 37c3007..469ac66 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -79,8 +79,10 @@ typedef	struct {
 #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
 #define EFI_PAL_CODE			13
 #define EFI_MAX_MEMORY_TYPE		14
+#define EFI_INVALID_TYPE		0xffffffff
 
 /* Attribute values: */
+#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid attribute*/
 #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
@@ -434,6 +436,14 @@ extern struct efi {
 	efi_set_virtual_address_map_t *set_virtual_address_map;
 } efi;
 
+struct efi_init_funcs {
+	void (*efi_init)(void);
+	void (*efi_reserve_boot_services)(void);
+	void (*efi_enter_virtual_mode)(void);
+	u32 (*efi_mem_type)(unsigned long phys_addr);
+	u64 (*efi_mem_attributes)(unsigned long phys_addr);
+};
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
@@ -464,6 +474,7 @@ extern unsigned long efi_get_time(void);
 extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
+extern void efi_init_function_register(const struct efi_init_funcs *funcs);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ujg-0002y6-NT; Thu, 23 Feb 2012 09:13:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Ujf-0002xF-Ea
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:11 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1329988384!15991904!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11069 invoked from network); 23 Feb 2012 09:13: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; 23 Feb 2012 09:13:05 -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 q1N9CWq6014476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:12:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1N9CVk0011567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:12:31 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
	q1N9CUQK002369; Thu, 23 Feb 2012 03:12:30 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:12:30 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:12:58 +0800
Message-Id: <1329988378-26895-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A02020A.4F460301.00B7,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 1/5V2] EFI: Provide registration for efi_init..
	etc efi public 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

The efi public functions are changed to function pointer in efi_init_funcs
struct.
They act as efi generic functions as default.
As a benefit from this change, we can register xen efi init func.

[v2: Fixed compile issues spotted by Konrad,
change variables defined suggested by Jan]

Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/efi.c |   66 +++++++++++++++++++++++++++++++++++++++---
 include/linux/efi.h         |   11 +++++++
 2 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 4cf9bd0..dd690e6 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -50,6 +50,24 @@
 #define PFX 		"EFI: "
 
 int efi_enabled;
+
+static void efi_init_generic(void);
+
+static void efi_enter_virtual_mode_generic(void);
+static u32 efi_mem_type_generic(unsigned long phys_addr);
+static u64 efi_mem_attributes_generic(unsigned long phys_addr);
+static void efi_reserve_boot_services_generic(void);
+
+static const struct efi_init_funcs efi_generic_funcs = {
+	.efi_init		     = efi_init_generic,
+	.efi_reserve_boot_services = efi_reserve_boot_services_generic,
+	.efi_enter_virtual_mode    = efi_enter_virtual_mode_generic,
+	.efi_mem_type		     = efi_mem_type_generic,
+	.efi_mem_attributes	     = efi_mem_attributes_generic
+};
+
+const struct efi_init_funcs *efi_override_funcs =  &efi_generic_funcs;
+
 EXPORT_SYMBOL(efi_enabled);
 
 struct efi __read_mostly efi = {
@@ -376,7 +394,7 @@ static void __init print_efi_memmap(void)
 }
 #endif  /*  EFI_DEBUG  */
 
-void __init efi_reserve_boot_services(void)
+static void efi_reserve_boot_services_generic(void)
 {
 	void *p;
 
@@ -429,7 +447,7 @@ static void __init efi_free_boot_services(void)
 	}
 }
 
-void __init efi_init(void)
+static void efi_init_generic(void)
 {
 	efi_config_table_t *config_tables;
 	efi_runtime_services_t *runtime;
@@ -618,7 +636,7 @@ static void __init runtime_code_page_mkexec(void)
  * This enables the runtime services to be called without having to
  * thunk back into physical mode for every invocation.
  */
-void __init efi_enter_virtual_mode(void)
+static void efi_enter_virtual_mode_generic(void)
 {
 	efi_memory_desc_t *md, *prev_md = NULL;
 	efi_status_t status;
@@ -752,7 +770,7 @@ void __init efi_enter_virtual_mode(void)
 /*
  * Convenience functions to obtain memory types and attributes
  */
-u32 efi_mem_type(unsigned long phys_addr)
+static u32 efi_mem_type_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -767,7 +785,7 @@ u32 efi_mem_type(unsigned long phys_addr)
 	return 0;
 }
 
-u64 efi_mem_attributes(unsigned long phys_addr)
+static u64 efi_mem_attributes_generic(unsigned long phys_addr)
 {
 	efi_memory_desc_t *md;
 	void *p;
@@ -781,3 +799,41 @@ u64 efi_mem_attributes(unsigned long phys_addr)
 	}
 	return 0;
 }
+
+void efi_init_function_register(const struct efi_init_funcs *funcs)
+{
+	efi_override_funcs = funcs;
+}
+
+void __init efi_init(void)
+{
+	if (efi_override_funcs->efi_init)
+		efi_override_funcs->efi_init();
+}
+
+void __init efi_reserve_boot_services(void)
+{
+	if (efi_override_funcs->efi_reserve_boot_services)
+		efi_override_funcs->efi_reserve_boot_services();
+}
+
+void __init efi_enter_virtual_mode(void)
+{
+	if (efi_override_funcs->efi_enter_virtual_mode)
+		efi_override_funcs->efi_enter_virtual_mode();
+}
+
+
+u32 efi_mem_type(unsigned long phys_addr)
+{
+	if (efi_override_funcs->efi_mem_type)
+		return efi_override_funcs->efi_mem_type(phys_addr);
+	return EFI_INVALID_TYPE;
+}
+
+u64 efi_mem_attributes(unsigned long phys_addr)
+{
+	if (efi_override_funcs->efi_mem_attributes)
+		return efi_override_funcs->efi_mem_attributes(phys_addr);
+	return EFI_INVALID_ATTRIBUTE;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 37c3007..469ac66 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -79,8 +79,10 @@ typedef	struct {
 #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
 #define EFI_PAL_CODE			13
 #define EFI_MAX_MEMORY_TYPE		14
+#define EFI_INVALID_TYPE		0xffffffff
 
 /* Attribute values: */
+#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid attribute*/
 #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
@@ -434,6 +436,14 @@ extern struct efi {
 	efi_set_virtual_address_map_t *set_virtual_address_map;
 } efi;
 
+struct efi_init_funcs {
+	void (*efi_init)(void);
+	void (*efi_reserve_boot_services)(void);
+	void (*efi_enter_virtual_mode)(void);
+	u32 (*efi_mem_type)(unsigned long phys_addr);
+	u64 (*efi_mem_attributes)(unsigned long phys_addr);
+};
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
@@ -464,6 +474,7 @@ extern unsigned long efi_get_time(void);
 extern int efi_set_rtc_mmss(unsigned long nowtime);
 extern void efi_reserve_boot_services(void);
 extern struct efi_memory_map memmap;
+extern void efi_init_function_register(const struct efi_init_funcs *funcs);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ujx-00031F-4r; Thu, 23 Feb 2012 09:13:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Ujv-0002zm-3T
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:27 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329988399!13665720!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4543 invoked from network); 23 Feb 2012 09:13:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 09:13:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1N9DICb015035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:18 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
	q1N9DHo2019693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:17 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
	q1N9DGwx023032; Thu, 23 Feb 2012 03:13:16 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:16 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:13:45 +0800
Message-Id: <1329988425-26970-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090203.4F46032F.0025,ss=1,re=-2.300,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 3/5V2] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich <JBeulich@suse.com>

The efi memory is owned by Xen and efi run-time service can not be called
directly,so a new efi driver is needed by Xen efi.
We call efi run-time service through the Xen in Xen efi driver.

[v2: Modifications done to abstract calls]

Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/Makefile   |    3 +
 arch/x86/platform/efi/efi-xen.c  |  432 ++++++++++++++++++++++++++++++++++++++
 include/linux/efi.h              |    1 +
 include/xen/interface/platform.h |  122 +++++++++++
 4 files changed, 558 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/platform/efi/efi-xen.c

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 73b8be0..9577899 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1 +1,4 @@
 obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
+ifdef CONFIG_XEN
+obj-$(CONFIG_EFI)		+= efi-xen.o
+endif
diff --git a/arch/x86/platform/efi/efi-xen.c b/arch/x86/platform/efi/efi-xen.c
new file mode 100644
index 0000000..c133d60
--- /dev/null
+++ b/arch/x86/platform/efi/efi-xen.c
@@ -0,0 +1,432 @@
+/*
+ * Common EFI (Extensible Firmware Interface) support functions
+ * Based on Extensible Firmware Interface Specification version 1.0
+ *
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
+ * Copyright (C) 1999-2002 Hewlett-Packard Co.
+ *	David Mosberger-Tang <davidm@hpl.hp.com>
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ * Copyright (C) 2005-2008 Intel Co.
+ *	Fenghua Yu <fenghua.yu@intel.com>
+ *	Bibo Mao <bibo.mao@intel.com>
+ *	Chandramouli Narayanan <mouli@linux.intel.com>
+ *	Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2011 Novell Co.
+ *	Jan Beulic <JBeulich@suse.com>
+ * Copyright (C) 2011-2012 Oracle Co.
+ *	Liang Tang <liang.tang@oracle.com>
+ *
+ *
+ * Copied from efi_32.c to eliminate the duplicated code between EFI
+ * 32/64 support code. --ying 2007-10-26
+ *
+ * All EFI Runtime Services are not implemented yet as EFI only
+ * supports physical mode addressing on SoftSDV. This is to be fixed
+ * in a future version.  --drummond 1999-07-20
+ *
+ * Implemented EFI runtime services and virtual mode calls.  --davidm
+ *
+ * Goutham Rao: <goutham.rao@intel.com>
+ *	Skip non-WB memory and ignore empty memory ranges.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+#include <asm/setup.h>
+#include <asm/efi.h>
+#include <asm/time.h>
+#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
+#include <asm/x86_init.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define PFX		"EFI: "
+
+#define call (op.u.efi_runtime_call)
+#define DECLARE_CALL(what) \
+	struct xen_platform_op op; \
+	op.cmd = XENPF_efi_runtime_call; \
+	call.function = XEN_EFI_##what; \
+	call.misc = 0
+
+static void register_xen_efi_function(void);
+
+static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+{
+	int err;
+	DECLARE_CALL(get_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time));
+		memcpy(tm, &call.u.get_time.time, sizeof(*tm));
+	}
+
+	if (tc) {
+		tc->resolution = call.u.get_time.resolution;
+		tc->accuracy = call.u.get_time.accuracy;
+		tc->sets_to_zero = !!(call.misc &
+				      XEN_EFI_GET_TIME_SET_CLEARS_NS);
+	}
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_time(efi_time_t *tm)
+{
+	DECLARE_CALL(set_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time));
+	memcpy(&call.u.set_time, tm, sizeof(*tm));
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
+					    efi_bool_t *pending,
+					    efi_time_t *tm)
+{
+	int err;
+	DECLARE_CALL(get_wakeup_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time));
+		memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm));
+	}
+
+	if (enabled)
+		*enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED);
+
+	if (pending)
+		*pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING);
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+{
+	DECLARE_CALL(set_wakeup_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time));
+	if (enabled)
+		call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE;
+	if (tm)
+		memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm));
+	else
+		call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 *attr,
+					 unsigned long *data_size,
+					 void *data)
+{
+	int err;
+	DECLARE_CALL(get_variable);
+
+	set_xen_guest_handle(call.u.get_variable.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_variable.vendor_guid));
+	memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.get_variable.size = *data_size;
+	set_xen_guest_handle(call.u.get_variable.data, data);
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*data_size = call.u.get_variable.size;
+	*attr = call.misc; /* misc in struction is U32 variable*/
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+					      efi_char16_t *name,
+					      efi_guid_t *vendor)
+{
+	int err;
+	DECLARE_CALL(get_next_variable_name);
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+	call.u.get_next_variable_name.size = *name_size;
+	set_xen_guest_handle(call.u.get_next_variable_name.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_next_variable_name.vendor_guid));
+	memcpy(&call.u.get_next_variable_name.vendor_guid, vendor,
+	       sizeof(*vendor));
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*name_size = call.u.get_next_variable_name.size;
+	memcpy(vendor, &call.u.get_next_variable_name.vendor_guid,
+	       sizeof(*vendor));
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 attr,
+					 unsigned long data_size,
+					 void *data)
+{
+	DECLARE_CALL(set_variable);
+
+	set_xen_guest_handle(call.u.set_variable.name, name);
+	call.misc = attr;
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.set_variable.vendor_guid));
+	memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.set_variable.size = data_size;
+	set_xen_guest_handle(call.u.set_variable.data, data);
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_variable_info(u32 attr,
+						u64 *storage_space,
+						u64 *remaining_space,
+						u64 *max_variable_size)
+{
+	int err;
+	DECLARE_CALL(query_variable_info);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*storage_space = call.u.query_variable_info.max_store_size;
+	*remaining_space = call.u.query_variable_info.remain_store_size;
+	*max_variable_size = call.u.query_variable_info.max_size;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+{
+	int err;
+	DECLARE_CALL(get_next_high_monotonic_count);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*count = call.misc;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+					   unsigned long count,
+					   unsigned long sg_list)
+{
+	DECLARE_CALL(update_capsule);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.update_capsule.capsule_header_array,
+			     capsules);
+	call.u.update_capsule.capsule_count = count;
+	call.u.update_capsule.sg_list = sg_list;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+					       unsigned long count,
+					       u64 *max_size,
+					       int *reset_type)
+{
+	int err;
+	DECLARE_CALL(query_capsule_capabilities);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.query_capsule_capabilities.
+		capsule_header_array, capsules);
+	call.u.query_capsule_capabilities.capsule_count = count;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*max_size = call.u.query_capsule_capabilities.max_capsule_size;
+	*reset_type = call.u.query_capsule_capabilities.reset_type;
+
+	return call.status;
+}
+
+#undef DECLARE_CALL
+#undef call
+
+static struct efi __read_mostly efi_xen = {
+	.mps                      = EFI_INVALID_TABLE_ADDR,
+	.acpi                     = EFI_INVALID_TABLE_ADDR,
+	.acpi20                   = EFI_INVALID_TABLE_ADDR,
+	.smbios                   = EFI_INVALID_TABLE_ADDR,
+	.sal_systab               = EFI_INVALID_TABLE_ADDR,
+	.boot_info                = EFI_INVALID_TABLE_ADDR,
+	.hcdp                     = EFI_INVALID_TABLE_ADDR,
+	.uga                      = EFI_INVALID_TABLE_ADDR,
+	.uv_systab                = EFI_INVALID_TABLE_ADDR,
+	.get_time                 = xen_efi_get_time,
+	.set_time                 = xen_efi_set_time,
+	.get_wakeup_time          = xen_efi_get_wakeup_time,
+	.set_wakeup_time          = xen_efi_set_wakeup_time,
+	.get_variable             = xen_efi_get_variable,
+	.get_next_variable        = xen_efi_get_next_variable,
+	.set_variable             = xen_efi_set_variable,
+	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+	.query_variable_info      = xen_efi_query_variable_info,
+	.update_capsule           = xen_efi_update_capsule,
+	.query_capsule_caps       = xen_efi_query_capsule_caps,
+};
+
+void xen_efi_probe(void)
+{
+	static struct xen_platform_op __initdata op = {
+		.cmd = XENPF_firmware_info,
+		.u.firmware_info = {
+			.type = XEN_FW_EFI_INFO,
+			.index = XEN_FW_EFI_CONFIG_TABLE
+		}
+	};
+
+	if (HYPERVISOR_dom0_op(&op) == 0) {
+		efi_enabled = 1;
+
+		register_xen_efi_function();
+	}
+}
+
+
+static void __init efi_init_xen(void)
+{
+	efi_config_table_t *config_tables;
+	efi_char16_t c16[100];
+	char vendor[ARRAY_SIZE(c16)] = "unknown";
+	int ret, i;
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	efi = efi_xen;
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+
+	/*
+	 * Show what we know for posterity
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+	info->vendor.bufsz = sizeof(c16);
+	set_xen_guest_handle(info->vendor.name, c16);
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret) {
+		for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i)
+			vendor[i] = c16[i];
+		vendor[i] = '\0';
+	} else
+		pr_err("Could not get the firmware vendor!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		pr_info("EFI v%u.%.02u by %s\n",
+		       info->version >> 16,
+		       info->version & 0xffff, vendor);
+	else
+		pr_err("Could not get EFI revision!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		efi.runtime_version = info->version;
+	else
+		pr_warn(PFX "Could not get runtime services revision.\n");
+
+	/*
+	 * Let's see what config tables the firmware passed to us.
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE;
+	if (HYPERVISOR_dom0_op(&op))
+		BUG();
+	config_tables = early_ioremap(
+		info->cfg.addr,
+		info->cfg.nent * sizeof(efi_config_table_t));
+	if (config_tables == NULL)
+		panic("Could not map EFI Configuration Table!\n");
+
+	get_efi_table_info(config_tables, info->cfg.nent, &efi);
+
+	early_iounmap(config_tables,
+		info->cfg.nent * sizeof(efi_config_table_t));
+
+	x86_platform.get_wallclock = efi_get_time;
+	x86_platform.set_wallclock = efi_set_rtc_mmss;
+}
+
+/*
+ * Convenience functions to obtain memory types and attributes
+ */
+static u32 efi_mem_type_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type;
+}
+
+static u64 efi_mem_attributes_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr;
+}
+
+static const struct efi_init_funcs xen_efi_funcs = {
+	.efi_init		     = efi_init_xen,
+	.efi_reserve_boot_services = NULL,
+	.efi_enter_virtual_mode    = NULL,
+	.efi_mem_type		     = efi_mem_type_xen,
+	.efi_mem_attributes	     = efi_mem_attributes_xen
+};
+
+static void register_xen_efi_function(void)
+{
+	efi_init_function_register(&xen_efi_funcs);
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 4276c96..7b46590 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -477,6 +477,7 @@ extern struct efi_memory_map memmap;
 extern void efi_init_function_register(const struct efi_init_funcs *funcs);
 extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
 			       struct efi *efi_t);
+extern void xen_efi_probe(void);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..77eb0fa 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -108,10 +108,112 @@ struct xenpf_platform_quirk {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
 
+#define XENPF_efi_runtime_call    49
+#define XEN_EFI_get_time                      1
+#define XEN_EFI_set_time                      2
+#define XEN_EFI_get_wakeup_time               3
+#define XEN_EFI_set_wakeup_time               4
+#define XEN_EFI_get_next_high_monotonic_count 5
+#define XEN_EFI_get_variable                  6
+#define XEN_EFI_set_variable                  7
+#define XEN_EFI_get_next_variable_name        8
+#define XEN_EFI_query_variable_info           9
+#define XEN_EFI_query_capsule_capabilities   10
+#define XEN_EFI_update_capsule               11
+
+struct xenpf_efi_runtime_call {
+	uint32_t function;
+    /*
+     * This field is generally used for per sub-function flags (defined
+     * below), except for the XEN_EFI_get_next_high_monotonic_count case,
+     * where it holds the single returned value.
+     */
+	uint32_t misc;
+	unsigned long status;
+	union {
+#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
+	struct {
+		struct xenpf_efi_time {
+			uint16_t year;
+			uint8_t month;
+			uint8_t day;
+			uint8_t hour;
+			uint8_t min;
+			uint8_t sec;
+			uint32_t ns;
+			int16_t tz;
+			uint8_t daylight;
+		} time;
+		uint32_t resolution;
+		uint32_t accuracy;
+	} get_time;
+
+	struct xenpf_efi_time set_time;
+
+#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001
+#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002
+	struct xenpf_efi_time get_wakeup_time;
+
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE      0x00000001
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002
+	struct xenpf_efi_time set_wakeup_time;
+
+#define XEN_EFI_VARIABLE_NON_VOLATILE       0x00000001
+#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
+#define XEN_EFI_VARIABLE_RUNTIME_ACCESS     0x00000004
+	struct {
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		unsigned long size;
+		GUEST_HANDLE(void) data;
+		struct xenpf_efi_guid {
+			uint32_t data1;
+			uint16_t data2;
+			uint16_t data3;
+			uint8_t data4[8];
+			} vendor_guid;
+		} get_variable, set_variable;
+
+	struct {
+		unsigned long size;
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		struct xenpf_efi_guid vendor_guid;
+		} get_next_variable_name;
+
+	struct {
+		uint32_t attr;
+		uint64_t max_store_size;
+		uint64_t remain_store_size;
+		uint64_t max_size;
+		} query_variable_info;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t max_capsule_size;
+		unsigned int reset_type;
+		} query_capsule_capabilities;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t sg_list; /* machine address */
+		} update_capsule;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call);
+
+#define  XEN_FW_EFI_VERSION        0
+#define  XEN_FW_EFI_CONFIG_TABLE   1
+#define  XEN_FW_EFI_VENDOR         2
+#define  XEN_FW_EFI_MEM_INFO       3
+#define  XEN_FW_EFI_RT_VERSION     4
+
 #define XENPF_firmware_info       50
 #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_EFI_INFO           4 /* from EFI */
+
 struct xenpf_firmware_info {
 	/* IN variables. */
 	uint32_t type;
@@ -142,6 +244,25 @@ struct xenpf_firmware_info {
 			/* must refer to 128-byte buffer */
 			GUEST_HANDLE(uchar) edid;
 		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		union xenpf_efi_info {
+			uint32_t version;
+			struct {
+				uint64_t addr;   /* EFI_CONFIGURATION_TABLE */
+				uint32_t nent;
+			} cfg;
+			struct {
+				uint32_t revision;
+				uint32_t bufsz;  /* input, in bytes */
+				GUEST_HANDLE(void) name;
+				/* UCS-2/UTF-16 string */
+				} vendor;
+			struct {
+				uint64_t addr;
+				uint64_t size;
+				uint64_t attr;
+				uint32_t type;
+				} mem;
+		} efi_info; /* XEN_FW_EFI_INFO */
 	} u;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
@@ -307,6 +428,7 @@ struct xen_platform_op {
 		struct xenpf_read_memtype      read_memtype;
 		struct xenpf_microcode_update  microcode;
 		struct xenpf_platform_quirk    platform_quirk;
+		struct xenpf_efi_runtime_call  efi_runtime_call;
 		struct xenpf_firmware_info     firmware_info;
 		struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
 		struct xenpf_change_freq       change_freq;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Ujx-00031F-4r; Thu, 23 Feb 2012 09:13:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0Ujv-0002zm-3T
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:27 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329988399!13665720!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4543 invoked from network); 23 Feb 2012 09:13:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 09:13:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1N9DICb015035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:18 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
	q1N9DHo2019693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:17 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
	q1N9DGwx023032; Thu, 23 Feb 2012 03:13:16 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:16 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:13:45 +0800
Message-Id: <1329988425-26970-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090203.4F46032F.0025,ss=1,re=-2.300,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 3/5V2] EFI: add efi driver for Xen efi
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich <JBeulich@suse.com>

The efi memory is owned by Xen and efi run-time service can not be called
directly,so a new efi driver is needed by Xen efi.
We call efi run-time service through the Xen in Xen efi driver.

[v2: Modifications done to abstract calls]

Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
---
 arch/x86/platform/efi/Makefile   |    3 +
 arch/x86/platform/efi/efi-xen.c  |  432 ++++++++++++++++++++++++++++++++++++++
 include/linux/efi.h              |    1 +
 include/xen/interface/platform.h |  122 +++++++++++
 4 files changed, 558 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/platform/efi/efi-xen.c

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 73b8be0..9577899 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1 +1,4 @@
 obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
+ifdef CONFIG_XEN
+obj-$(CONFIG_EFI)		+= efi-xen.o
+endif
diff --git a/arch/x86/platform/efi/efi-xen.c b/arch/x86/platform/efi/efi-xen.c
new file mode 100644
index 0000000..c133d60
--- /dev/null
+++ b/arch/x86/platform/efi/efi-xen.c
@@ -0,0 +1,432 @@
+/*
+ * Common EFI (Extensible Firmware Interface) support functions
+ * Based on Extensible Firmware Interface Specification version 1.0
+ *
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
+ * Copyright (C) 1999-2002 Hewlett-Packard Co.
+ *	David Mosberger-Tang <davidm@hpl.hp.com>
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ * Copyright (C) 2005-2008 Intel Co.
+ *	Fenghua Yu <fenghua.yu@intel.com>
+ *	Bibo Mao <bibo.mao@intel.com>
+ *	Chandramouli Narayanan <mouli@linux.intel.com>
+ *	Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2011 Novell Co.
+ *	Jan Beulic <JBeulich@suse.com>
+ * Copyright (C) 2011-2012 Oracle Co.
+ *	Liang Tang <liang.tang@oracle.com>
+ *
+ *
+ * Copied from efi_32.c to eliminate the duplicated code between EFI
+ * 32/64 support code. --ying 2007-10-26
+ *
+ * All EFI Runtime Services are not implemented yet as EFI only
+ * supports physical mode addressing on SoftSDV. This is to be fixed
+ * in a future version.  --drummond 1999-07-20
+ *
+ * Implemented EFI runtime services and virtual mode calls.  --davidm
+ *
+ * Goutham Rao: <goutham.rao@intel.com>
+ *	Skip non-WB memory and ignore empty memory ranges.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+#include <asm/setup.h>
+#include <asm/efi.h>
+#include <asm/time.h>
+#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
+#include <asm/x86_init.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define PFX		"EFI: "
+
+#define call (op.u.efi_runtime_call)
+#define DECLARE_CALL(what) \
+	struct xen_platform_op op; \
+	op.cmd = XENPF_efi_runtime_call; \
+	call.function = XEN_EFI_##what; \
+	call.misc = 0
+
+static void register_xen_efi_function(void);
+
+static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+{
+	int err;
+	DECLARE_CALL(get_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time));
+		memcpy(tm, &call.u.get_time.time, sizeof(*tm));
+	}
+
+	if (tc) {
+		tc->resolution = call.u.get_time.resolution;
+		tc->accuracy = call.u.get_time.accuracy;
+		tc->sets_to_zero = !!(call.misc &
+				      XEN_EFI_GET_TIME_SET_CLEARS_NS);
+	}
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_time(efi_time_t *tm)
+{
+	DECLARE_CALL(set_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time));
+	memcpy(&call.u.set_time, tm, sizeof(*tm));
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
+					    efi_bool_t *pending,
+					    efi_time_t *tm)
+{
+	int err;
+	DECLARE_CALL(get_wakeup_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time));
+		memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm));
+	}
+
+	if (enabled)
+		*enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED);
+
+	if (pending)
+		*pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING);
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+{
+	DECLARE_CALL(set_wakeup_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time));
+	if (enabled)
+		call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE;
+	if (tm)
+		memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm));
+	else
+		call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 *attr,
+					 unsigned long *data_size,
+					 void *data)
+{
+	int err;
+	DECLARE_CALL(get_variable);
+
+	set_xen_guest_handle(call.u.get_variable.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_variable.vendor_guid));
+	memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.get_variable.size = *data_size;
+	set_xen_guest_handle(call.u.get_variable.data, data);
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*data_size = call.u.get_variable.size;
+	*attr = call.misc; /* misc in struction is U32 variable*/
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+					      efi_char16_t *name,
+					      efi_guid_t *vendor)
+{
+	int err;
+	DECLARE_CALL(get_next_variable_name);
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+	call.u.get_next_variable_name.size = *name_size;
+	set_xen_guest_handle(call.u.get_next_variable_name.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_next_variable_name.vendor_guid));
+	memcpy(&call.u.get_next_variable_name.vendor_guid, vendor,
+	       sizeof(*vendor));
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*name_size = call.u.get_next_variable_name.size;
+	memcpy(vendor, &call.u.get_next_variable_name.vendor_guid,
+	       sizeof(*vendor));
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 attr,
+					 unsigned long data_size,
+					 void *data)
+{
+	DECLARE_CALL(set_variable);
+
+	set_xen_guest_handle(call.u.set_variable.name, name);
+	call.misc = attr;
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.set_variable.vendor_guid));
+	memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.set_variable.size = data_size;
+	set_xen_guest_handle(call.u.set_variable.data, data);
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_variable_info(u32 attr,
+						u64 *storage_space,
+						u64 *remaining_space,
+						u64 *max_variable_size)
+{
+	int err;
+	DECLARE_CALL(query_variable_info);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*storage_space = call.u.query_variable_info.max_store_size;
+	*remaining_space = call.u.query_variable_info.remain_store_size;
+	*max_variable_size = call.u.query_variable_info.max_size;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+{
+	int err;
+	DECLARE_CALL(get_next_high_monotonic_count);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*count = call.misc;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+					   unsigned long count,
+					   unsigned long sg_list)
+{
+	DECLARE_CALL(update_capsule);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.update_capsule.capsule_header_array,
+			     capsules);
+	call.u.update_capsule.capsule_count = count;
+	call.u.update_capsule.sg_list = sg_list;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+					       unsigned long count,
+					       u64 *max_size,
+					       int *reset_type)
+{
+	int err;
+	DECLARE_CALL(query_capsule_capabilities);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.query_capsule_capabilities.
+		capsule_header_array, capsules);
+	call.u.query_capsule_capabilities.capsule_count = count;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*max_size = call.u.query_capsule_capabilities.max_capsule_size;
+	*reset_type = call.u.query_capsule_capabilities.reset_type;
+
+	return call.status;
+}
+
+#undef DECLARE_CALL
+#undef call
+
+static struct efi __read_mostly efi_xen = {
+	.mps                      = EFI_INVALID_TABLE_ADDR,
+	.acpi                     = EFI_INVALID_TABLE_ADDR,
+	.acpi20                   = EFI_INVALID_TABLE_ADDR,
+	.smbios                   = EFI_INVALID_TABLE_ADDR,
+	.sal_systab               = EFI_INVALID_TABLE_ADDR,
+	.boot_info                = EFI_INVALID_TABLE_ADDR,
+	.hcdp                     = EFI_INVALID_TABLE_ADDR,
+	.uga                      = EFI_INVALID_TABLE_ADDR,
+	.uv_systab                = EFI_INVALID_TABLE_ADDR,
+	.get_time                 = xen_efi_get_time,
+	.set_time                 = xen_efi_set_time,
+	.get_wakeup_time          = xen_efi_get_wakeup_time,
+	.set_wakeup_time          = xen_efi_set_wakeup_time,
+	.get_variable             = xen_efi_get_variable,
+	.get_next_variable        = xen_efi_get_next_variable,
+	.set_variable             = xen_efi_set_variable,
+	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+	.query_variable_info      = xen_efi_query_variable_info,
+	.update_capsule           = xen_efi_update_capsule,
+	.query_capsule_caps       = xen_efi_query_capsule_caps,
+};
+
+void xen_efi_probe(void)
+{
+	static struct xen_platform_op __initdata op = {
+		.cmd = XENPF_firmware_info,
+		.u.firmware_info = {
+			.type = XEN_FW_EFI_INFO,
+			.index = XEN_FW_EFI_CONFIG_TABLE
+		}
+	};
+
+	if (HYPERVISOR_dom0_op(&op) == 0) {
+		efi_enabled = 1;
+
+		register_xen_efi_function();
+	}
+}
+
+
+static void __init efi_init_xen(void)
+{
+	efi_config_table_t *config_tables;
+	efi_char16_t c16[100];
+	char vendor[ARRAY_SIZE(c16)] = "unknown";
+	int ret, i;
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	efi = efi_xen;
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+
+	/*
+	 * Show what we know for posterity
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+	info->vendor.bufsz = sizeof(c16);
+	set_xen_guest_handle(info->vendor.name, c16);
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret) {
+		for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i)
+			vendor[i] = c16[i];
+		vendor[i] = '\0';
+	} else
+		pr_err("Could not get the firmware vendor!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		pr_info("EFI v%u.%.02u by %s\n",
+		       info->version >> 16,
+		       info->version & 0xffff, vendor);
+	else
+		pr_err("Could not get EFI revision!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		efi.runtime_version = info->version;
+	else
+		pr_warn(PFX "Could not get runtime services revision.\n");
+
+	/*
+	 * Let's see what config tables the firmware passed to us.
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE;
+	if (HYPERVISOR_dom0_op(&op))
+		BUG();
+	config_tables = early_ioremap(
+		info->cfg.addr,
+		info->cfg.nent * sizeof(efi_config_table_t));
+	if (config_tables == NULL)
+		panic("Could not map EFI Configuration Table!\n");
+
+	get_efi_table_info(config_tables, info->cfg.nent, &efi);
+
+	early_iounmap(config_tables,
+		info->cfg.nent * sizeof(efi_config_table_t));
+
+	x86_platform.get_wallclock = efi_get_time;
+	x86_platform.set_wallclock = efi_set_rtc_mmss;
+}
+
+/*
+ * Convenience functions to obtain memory types and attributes
+ */
+static u32 efi_mem_type_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type;
+}
+
+static u64 efi_mem_attributes_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr;
+}
+
+static const struct efi_init_funcs xen_efi_funcs = {
+	.efi_init		     = efi_init_xen,
+	.efi_reserve_boot_services = NULL,
+	.efi_enter_virtual_mode    = NULL,
+	.efi_mem_type		     = efi_mem_type_xen,
+	.efi_mem_attributes	     = efi_mem_attributes_xen
+};
+
+static void register_xen_efi_function(void)
+{
+	efi_init_function_register(&xen_efi_funcs);
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 4276c96..7b46590 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -477,6 +477,7 @@ extern struct efi_memory_map memmap;
 extern void efi_init_function_register(const struct efi_init_funcs *funcs);
 extern void get_efi_table_info(efi_config_table_t *config_tables, int nr_tables,
 			       struct efi *efi_t);
+extern void xen_efi_probe(void);
 
 /**
  * efi_range_is_wc - check the WC bit on an address range
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..77eb0fa 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -108,10 +108,112 @@ struct xenpf_platform_quirk {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
 
+#define XENPF_efi_runtime_call    49
+#define XEN_EFI_get_time                      1
+#define XEN_EFI_set_time                      2
+#define XEN_EFI_get_wakeup_time               3
+#define XEN_EFI_set_wakeup_time               4
+#define XEN_EFI_get_next_high_monotonic_count 5
+#define XEN_EFI_get_variable                  6
+#define XEN_EFI_set_variable                  7
+#define XEN_EFI_get_next_variable_name        8
+#define XEN_EFI_query_variable_info           9
+#define XEN_EFI_query_capsule_capabilities   10
+#define XEN_EFI_update_capsule               11
+
+struct xenpf_efi_runtime_call {
+	uint32_t function;
+    /*
+     * This field is generally used for per sub-function flags (defined
+     * below), except for the XEN_EFI_get_next_high_monotonic_count case,
+     * where it holds the single returned value.
+     */
+	uint32_t misc;
+	unsigned long status;
+	union {
+#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
+	struct {
+		struct xenpf_efi_time {
+			uint16_t year;
+			uint8_t month;
+			uint8_t day;
+			uint8_t hour;
+			uint8_t min;
+			uint8_t sec;
+			uint32_t ns;
+			int16_t tz;
+			uint8_t daylight;
+		} time;
+		uint32_t resolution;
+		uint32_t accuracy;
+	} get_time;
+
+	struct xenpf_efi_time set_time;
+
+#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001
+#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002
+	struct xenpf_efi_time get_wakeup_time;
+
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE      0x00000001
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002
+	struct xenpf_efi_time set_wakeup_time;
+
+#define XEN_EFI_VARIABLE_NON_VOLATILE       0x00000001
+#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
+#define XEN_EFI_VARIABLE_RUNTIME_ACCESS     0x00000004
+	struct {
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		unsigned long size;
+		GUEST_HANDLE(void) data;
+		struct xenpf_efi_guid {
+			uint32_t data1;
+			uint16_t data2;
+			uint16_t data3;
+			uint8_t data4[8];
+			} vendor_guid;
+		} get_variable, set_variable;
+
+	struct {
+		unsigned long size;
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		struct xenpf_efi_guid vendor_guid;
+		} get_next_variable_name;
+
+	struct {
+		uint32_t attr;
+		uint64_t max_store_size;
+		uint64_t remain_store_size;
+		uint64_t max_size;
+		} query_variable_info;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t max_capsule_size;
+		unsigned int reset_type;
+		} query_capsule_capabilities;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t sg_list; /* machine address */
+		} update_capsule;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call);
+
+#define  XEN_FW_EFI_VERSION        0
+#define  XEN_FW_EFI_CONFIG_TABLE   1
+#define  XEN_FW_EFI_VENDOR         2
+#define  XEN_FW_EFI_MEM_INFO       3
+#define  XEN_FW_EFI_RT_VERSION     4
+
 #define XENPF_firmware_info       50
 #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_EFI_INFO           4 /* from EFI */
+
 struct xenpf_firmware_info {
 	/* IN variables. */
 	uint32_t type;
@@ -142,6 +244,25 @@ struct xenpf_firmware_info {
 			/* must refer to 128-byte buffer */
 			GUEST_HANDLE(uchar) edid;
 		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		union xenpf_efi_info {
+			uint32_t version;
+			struct {
+				uint64_t addr;   /* EFI_CONFIGURATION_TABLE */
+				uint32_t nent;
+			} cfg;
+			struct {
+				uint32_t revision;
+				uint32_t bufsz;  /* input, in bytes */
+				GUEST_HANDLE(void) name;
+				/* UCS-2/UTF-16 string */
+				} vendor;
+			struct {
+				uint64_t addr;
+				uint64_t size;
+				uint64_t attr;
+				uint32_t type;
+				} mem;
+		} efi_info; /* XEN_FW_EFI_INFO */
 	} u;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
@@ -307,6 +428,7 @@ struct xen_platform_op {
 		struct xenpf_read_memtype      read_memtype;
 		struct xenpf_microcode_update  microcode;
 		struct xenpf_platform_quirk    platform_quirk;
+		struct xenpf_efi_runtime_call  efi_runtime_call;
 		struct xenpf_firmware_info     firmware_info;
 		struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
 		struct xenpf_change_freq       change_freq;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0UkE-00034m-Hu; Thu, 23 Feb 2012 09:13:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0UkD-00033i-GA
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:45 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329988417!14398607!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15195 invoked from network); 23 Feb 2012 09:13:38 -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; 23 Feb 2012 09:13:38 -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 q1N9DZr5015248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:36 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
	q1N9DYmJ020100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:35 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1N9DX5E023209; Thu, 23 Feb 2012 03:13:34 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:33 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:14:00 +0800
Message-Id: <1329988440-27004-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090204.4F460340.0099,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 4/5V2] Xen efi: Add xen efi enabled detect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need to use hypercall to detect the xen efi enabled or not.
If xen efi enable is set,replace the efi public function to xen efi public
function and set efi_enabled to 1 in the function efi_probe;

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..92982c1 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/efi.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -1282,6 +1283,8 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_setup_runstate_info(0);
 
+	if (xen_initial_domain())
+		xen_efi_probe();
 	/* Start the world */
 #ifdef CONFIG_X86_32
 	i386_start_kernel();
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:13:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0UkE-00034m-Hu; Thu, 23 Feb 2012 09:13:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0UkD-00033i-GA
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:13:45 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329988417!14398607!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15195 invoked from network); 23 Feb 2012 09:13:38 -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; 23 Feb 2012 09:13:38 -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 q1N9DZr5015248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:36 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
	q1N9DYmJ020100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:35 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1N9DX5E023209; Thu, 23 Feb 2012 03:13:34 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:33 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:14:00 +0800
Message-Id: <1329988440-27004-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090204.4F460340.0099,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 4/5V2] Xen efi: Add xen efi enabled detect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We need to use hypercall to detect the xen efi enabled or not.
If xen efi enable is set,replace the efi public function to xen efi public
function and set efi_enabled to 1 in the function efi_probe;

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..92982c1 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/efi.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -1282,6 +1283,8 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_setup_runstate_info(0);
 
+	if (xen_initial_domain())
+		xen_efi_probe();
 	/* Start the world */
 #ifdef CONFIG_X86_32
 	i386_start_kernel();
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:14:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:14:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UkV-00039A-3E; Thu, 23 Feb 2012 09:14:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0UkT-00037c-Ci
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:14:01 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329988432!14549276!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21687 invoked from network); 23 Feb 2012 09:13:54 -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; 23 Feb 2012 09:13: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 q1N9Do1F015639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:51 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
	q1N9Dnk3017665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:50 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
	q1N9DnOh024577; Thu, 23 Feb 2012 03:13:49 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:49 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:14:18 +0800
Message-Id: <1329988458-27038-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F460350.004B,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 5/5V2] Xen vga: add the xen efi video mode
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to add xen efi video support, it is required to add xen-efi's new
video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga
and set the video type to VIDEO_TYPE_EFI to enable efi video mode.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/vga.c          |    7 +++++++
 include/xen/interface/xen.h |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/vga.c b/arch/x86/xen/vga.c
index 1cd7f4d..6722e37 100644
--- a/arch/x86/xen/vga.c
+++ b/arch/x86/xen/vga.c
@@ -35,6 +35,7 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 			info->u.text_mode_3.font_height;
 		break;
 
+	case XEN_VGATYPE_EFI_LFB:
 	case XEN_VGATYPE_VESA_LFB:
 		if (size < offsetof(struct dom0_vga_console_info,
 				    u.vesa_lfb.gbl_caps))
@@ -54,6 +55,12 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 		screen_info->blue_pos = info->u.vesa_lfb.blue_pos;
 		screen_info->rsvd_size = info->u.vesa_lfb.rsvd_size;
 		screen_info->rsvd_pos = info->u.vesa_lfb.rsvd_pos;
+
+		if (info->video_type == XEN_VGATYPE_EFI_LFB) {
+			screen_info->orig_video_isVGA = VIDEO_TYPE_EFI;
+			break;
+		}
+
 		if (size >= offsetof(struct dom0_vga_console_info,
 				     u.vesa_lfb.gbl_caps)
 		    + sizeof(info->u.vesa_lfb.gbl_caps))
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..c84ba71 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -454,6 +454,7 @@ struct dom0_vga_console_info {
 	uint8_t video_type;
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
 #define XEN_VGATYPE_VESA_LFB    0x23
+#define XEN_VGATYPE_EFI_LFB     0x70
 
 	union {
 		struct {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:14:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:14:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UkV-00039A-3E; Thu, 23 Feb 2012 09:14:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liang.tang@oracle.com>) id 1S0UkT-00037c-Ci
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:14:01 +0000
X-Env-Sender: liang.tang@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1329988432!14549276!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21687 invoked from network); 23 Feb 2012 09:13:54 -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; 23 Feb 2012 09:13: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 q1N9Do1F015639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 09:13:51 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
	q1N9Dnk3017665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 09:13:50 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
	q1N9DnOh024577; Thu, 23 Feb 2012 03:13:49 -0600
Received: from dddd.cn.oracle.com (/10.182.38.40)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 01:13:49 -0800
From: Tang Liang <liang.tang@oracle.com>
To: mjg59@srcf.ucam.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	konrad.wilk@oracle.com, JBeulich@suse.com
Date: Thu, 23 Feb 2012 17:14:18 +0800
Message-Id: <1329988458-27038-1-git-send-email-liang.tang@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
References: <1329988283-26722-1-git-send-email-liang.tang@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F460350.004B,ss=1,re=0.000,fgs=0
Cc: liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 5/5V2] Xen vga: add the xen efi video mode
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to add xen efi video support, it is required to add xen-efi's new
video type(XEN_VGATYPE_EFI_LFB) case handler in the function xen_init_vga
and set the video type to VIDEO_TYPE_EFI to enable efi video mode.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/vga.c          |    7 +++++++
 include/xen/interface/xen.h |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/vga.c b/arch/x86/xen/vga.c
index 1cd7f4d..6722e37 100644
--- a/arch/x86/xen/vga.c
+++ b/arch/x86/xen/vga.c
@@ -35,6 +35,7 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 			info->u.text_mode_3.font_height;
 		break;
 
+	case XEN_VGATYPE_EFI_LFB:
 	case XEN_VGATYPE_VESA_LFB:
 		if (size < offsetof(struct dom0_vga_console_info,
 				    u.vesa_lfb.gbl_caps))
@@ -54,6 +55,12 @@ void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size)
 		screen_info->blue_pos = info->u.vesa_lfb.blue_pos;
 		screen_info->rsvd_size = info->u.vesa_lfb.rsvd_size;
 		screen_info->rsvd_pos = info->u.vesa_lfb.rsvd_pos;
+
+		if (info->video_type == XEN_VGATYPE_EFI_LFB) {
+			screen_info->orig_video_isVGA = VIDEO_TYPE_EFI;
+			break;
+		}
+
 		if (size >= offsetof(struct dom0_vga_console_info,
 				     u.vesa_lfb.gbl_caps)
 		    + sizeof(info->u.vesa_lfb.gbl_caps))
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..c84ba71 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -454,6 +454,7 @@ struct dom0_vga_console_info {
 	uint8_t video_type;
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
 #define XEN_VGATYPE_VESA_LFB    0x23
+#define XEN_VGATYPE_EFI_LFB     0x70
 
 	union {
 		struct {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:14:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0UkX-00039v-HQ; Thu, 23 Feb 2012 09:14:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1S0UkV-00039E-Pu
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:14:04 +0000
Received: from [85.158.139.83:37691] by server-4.bemta-5.messagelabs.com id
	31/B0-10788-A53064F4; Thu, 23 Feb 2012 09:14:02 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329988441!15734291!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDQyNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31316 invoked from network); 23 Feb 2012 09:14:02 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 09:14:02 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5CCE72126C
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 04:14:01 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Thu, 23 Feb 2012 04:14:01 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=mesmtp; bh=7HDtYgK5mvgXriaqFjxb3sxn5BU=; b=
	qXXeo58E6VTQWqwAI347yPNv6UlhEH+RinM5qxS/ifeAvnFoBhcA7YOlJE4n16VN
	0rtcIshahg42iQ4MwK8HxvpctKO3Fk/W+WuCA+n/2liyzVjYQgL4KeTlEn7F+goz
	ZkotUlVNEwU3KiPsGsysbq8xOHLanFZT94njPnKmL7U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=smtpout; bh=7HDtYgK5mvgXriaqFjxb3sxn5BU
	=; b=E1ZvZoMnJfNr7+Py3FF/qvrFLhR9LjVJc1k7asK57LprT0wFVKj0UaD0hTh
	XKSVf90YIewEIJfFtOdjcg+QhBohb4LWBzW22TB6R/yyqfpHTp9wilTKkbS38KFa
	9D6Ujj9lQQCd6lZlUlhzwXTegiMv0uMfjGqLwQm1OI0C6DXE=
X-Sasl-enc: kz9+0B3w+ozykWUC0a+B32e6OOjKVxt02GHrsv++N0yo 1329988440
Received: from [10.137.2.12] (aavn41.neoplus.adsl.tpnet.pl [83.6.47.41])
	by mail.messagingengine.com (Postfix) with ESMTPSA id BF8AE4825CC
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 04:14:00 -0500 (EST)
Message-ID: <4F460354.7080907@invisiblethingslab.com>
Date: Thu, 23 Feb 2012 10:13:56 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.5
Subject: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0609732287047609459=="
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)
--===============0609732287047609459==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigBF6F0A50A650177BB61083DD"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBF6F0A50A650177BB61083DD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
integrated GPU) freezing at resume from S3 sleep... It seems like a
Xen-related problems, as a similar kernel to what we use in Dom0
(2.6.38+xenlinux), when run on baremetal shows no signs of problems at
suspend/resume. Also I cannot find any problems reported on the internet
with people having problems here.

Unfortunately the only COM port on ExpressCard I have, presents itself
as a USB device, and so I cannot really debug this issue via console.
The /var/log/pm-suspend also doesn't reveal anything useful (after I
reboot, that is).

Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
to approach debugging it?

I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
patches, and the i915 for the graphics. (Unfortunately I cannot just
boot the same Dom0 kernel without Xen, as the GRUB complains about
executable being unrecognized -- probably some problem with wrong
compression algo).

I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
-- in this case it's even worse, as the system hangs at suspend and
never enters S3 :/

Thanks,
joanna.


--------------enigBF6F0A50A650177BB61083DD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPRgNUAAoJEDaIqHeRBUM0cqwIALj+pQlIcdUAT0paHI8L3coF
QGNw1PaoR69EW4Z6C+WvLtp2H+ggQMcj3/0kppPFr6HG9LLtHW+ZSE2DA2q63IGW
PehyJ3rCHJr5kuo8RreMRrPAZH5rp9YyHoagHkPcidmn392X5H9JTnR/LQwgiy0h
Bed8A6FAnE9MH3S/6N+fkIpC52Bhv2Wvd1gnwDiamV7p6R/J9JwJseF2G7IIRDFz
oNvDwRUCiL27k+xL4yp0X0C1q084BS13kLFKHdTrcBQNr7FVUxYgygfps07me+Sc
xdqLo/xfXx51e9uymy8bnDQFLzi5WDZdQMYHZ9D63ueqepAd4fV+d0H8fAuOIYU=
=8maC
-----END PGP SIGNATURE-----

--------------enigBF6F0A50A650177BB61083DD--


--===============0609732287047609459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0609732287047609459==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 09:14:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0UkX-00039v-HQ; Thu, 23 Feb 2012 09:14:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1S0UkV-00039E-Pu
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:14:04 +0000
Received: from [85.158.139.83:37691] by server-4.bemta-5.messagelabs.com id
	31/B0-10788-A53064F4; Thu, 23 Feb 2012 09:14:02 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329988441!15734291!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDQyNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31316 invoked from network); 23 Feb 2012 09:14:02 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 09:14:02 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5CCE72126C
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 04:14:01 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Thu, 23 Feb 2012 04:14:01 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=mesmtp; bh=7HDtYgK5mvgXriaqFjxb3sxn5BU=; b=
	qXXeo58E6VTQWqwAI347yPNv6UlhEH+RinM5qxS/ifeAvnFoBhcA7YOlJE4n16VN
	0rtcIshahg42iQ4MwK8HxvpctKO3Fk/W+WuCA+n/2liyzVjYQgL4KeTlEn7F+goz
	ZkotUlVNEwU3KiPsGsysbq8xOHLanFZT94njPnKmL7U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to
	:subject:content-type; s=smtpout; bh=7HDtYgK5mvgXriaqFjxb3sxn5BU
	=; b=E1ZvZoMnJfNr7+Py3FF/qvrFLhR9LjVJc1k7asK57LprT0wFVKj0UaD0hTh
	XKSVf90YIewEIJfFtOdjcg+QhBohb4LWBzW22TB6R/yyqfpHTp9wilTKkbS38KFa
	9D6Ujj9lQQCd6lZlUlhzwXTegiMv0uMfjGqLwQm1OI0C6DXE=
X-Sasl-enc: kz9+0B3w+ozykWUC0a+B32e6OOjKVxt02GHrsv++N0yo 1329988440
Received: from [10.137.2.12] (aavn41.neoplus.adsl.tpnet.pl [83.6.47.41])
	by mail.messagingengine.com (Postfix) with ESMTPSA id BF8AE4825CC
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 04:14:00 -0500 (EST)
Message-ID: <4F460354.7080907@invisiblethingslab.com>
Date: Thu, 23 Feb 2012 10:13:56 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.5
Subject: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0609732287047609459=="
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)
--===============0609732287047609459==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigBF6F0A50A650177BB61083DD"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBF6F0A50A650177BB61083DD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
integrated GPU) freezing at resume from S3 sleep... It seems like a
Xen-related problems, as a similar kernel to what we use in Dom0
(2.6.38+xenlinux), when run on baremetal shows no signs of problems at
suspend/resume. Also I cannot find any problems reported on the internet
with people having problems here.

Unfortunately the only COM port on ExpressCard I have, presents itself
as a USB device, and so I cannot really debug this issue via console.
The /var/log/pm-suspend also doesn't reveal anything useful (after I
reboot, that is).

Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
to approach debugging it?

I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
patches, and the i915 for the graphics. (Unfortunately I cannot just
boot the same Dom0 kernel without Xen, as the GRUB complains about
executable being unrecognized -- probably some problem with wrong
compression algo).

I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
-- in this case it's even worse, as the system hangs at suspend and
never enters S3 :/

Thanks,
joanna.


--------------enigBF6F0A50A650177BB61083DD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPRgNUAAoJEDaIqHeRBUM0cqwIALj+pQlIcdUAT0paHI8L3coF
QGNw1PaoR69EW4Z6C+WvLtp2H+ggQMcj3/0kppPFr6HG9LLtHW+ZSE2DA2q63IGW
PehyJ3rCHJr5kuo8RreMRrPAZH5rp9YyHoagHkPcidmn392X5H9JTnR/LQwgiy0h
Bed8A6FAnE9MH3S/6N+fkIpC52Bhv2Wvd1gnwDiamV7p6R/J9JwJseF2G7IIRDFz
oNvDwRUCiL27k+xL4yp0X0C1q084BS13kLFKHdTrcBQNr7FVUxYgygfps07me+Sc
xdqLo/xfXx51e9uymy8bnDQFLzi5WDZdQMYHZ9D63ueqepAd4fV+d0H8fAuOIYU=
=8maC
-----END PGP SIGNATURE-----

--------------enigBF6F0A50A650177BB61083DD--


--===============0609732287047609459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0609732287047609459==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 09:18:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:18:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UoU-0003t7-CB; Thu, 23 Feb 2012 09:18:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0UoT-0003sw-7r
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:18:09 +0000
Received: from [85.158.139.83:16205] by server-10.bemta-5.messagelabs.com id
	1C/9D-07861-054064F4; Thu, 23 Feb 2012 09:18:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329988687!15735230!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18100 invoked from network); 23 Feb 2012 09:18:08 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 09:18:08 -0000
Received: by wgbdt11 with SMTP id dt11so6638482wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 01:18:07 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr1399101wia.3.1329988687726 (num_hops =
	1); Thu, 23 Feb 2012 01:18:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=bCEdvTLth1e6oHYQSJyjwmeHLtgTFEhGqXatG7zzm1I=;
	b=p6z4Lf+TZphhgqwuU48OjaTbufE0LL5vF+M53jrlMK+bZabKstyRZ9MM3QSQX18pkK
	fZrpQIVr7KiqC07HzgqEYsTTm6uC2m08QSHzGSnroGNS7j9mdqoy81Z+a9zHtNvWUekE
	vJOLy3ALCe94+UbTJ48t/JddtgcpOV0xXrL58=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr1142815wia.3.1329988687675; Thu, 23
	Feb 2012 01:18:07 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 23 Feb 2012 01:18:07 -0800 (PST)
In-Reply-To: <4F44C1A7.6070405@amd.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
Date: Thu, 23 Feb 2012 10:18:07 +0100
X-Google-Sender-Auth: HnGtJjSXa7hZeuOyNWRKqaJtXuI
Message-ID: <CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+IE9u
IDAyLzIyLzEyIDEwOjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pgo+PiAyMDEyLzIvMjIg
Q2hyaXN0b3BoIEVnZ2VyPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPj4+Cj4+Pgo+Pj4gSGks
Cj4+Pgo+Pj4gY29uZmlndXJlIGZhaWxzIG9uIE5ldEJTRCB0aGF0IHRoZXJlIGlzIG5vIGJyY3Rs
Lgo+Pj4gTmV0QlNEIGhhcyBubyBicmN0bCwgTmV0QlNEIGhhcyBicmNvbmZpZy4KPj4KPj4KPj4g
U29ycnkgQ2hyaXN0b3BoLCB0aGUgYnJjdGwgdGVzdCBpcyBnb2luZyBhd2F5IChmcm9tIGNvbmZp
Z3VyZSBhdCBsZWFzdCkuCj4KPgo+IFRoZXJlIGFyZSBzb21lIG1vcmUgTGludXggc3BlY2lmaWMg
dGVzdHM6Cj4gLSBpcAo+IC0gdXVpZF9jbGVhciBpbiBsaWJ1dWlkCgpJJ20gZ29pbmcgdG8gZml4
IHRoaXMgcmlnaHQgbm93LiBTaG91bGQgSSBjb21taXQgdGhlIG91dHB1dCBmcm9tCmF1dG9jb25m
IGFsc28gd2l0aCBteSBwYXRjaGVzIElhbj8gSSdtIGFza2luZyB0aGlzIGJlY2F1c2Ugd2UgdXNl
CmRpZmZlcmVudCB2ZXJzaW9ucyBhbmQgdGhlIG91dHB1dCBpcyBzbGlnaHRseSBkaWZmZXJlbnQu
Cgo+IEFsc28gdGhlIGNoZWNrIGZvciB5YWpsX2FsbG9jIGluIGxpYnlhamwgZmFpbHMgYWx0aG91
Z2ggSSBoYXZlIGxpYnlhamwKPiB2ZXJzaW9uIDEgaW5zdGFsbGVkLiBUaGUgY2hlY2sgbWF5IGJl
IGNvcnJlY3QgYnV0IGNvbmZpZ3VyZSBzaG91bGRuJ3QgZmFpbAo+IGlmIHZlcnNpb24gMSBpcyBz
dGlsbCBzdXBwb3J0ZWQuCj4KPgo+IENocmlzdG9waAo+Cj4gLS0KPiAtLS10byBzYXRpc2Z5IEV1
cm9wZWFuIExhdyBmb3IgYnVzaW5lc3MgbGV0dGVyczoKPiBBZHZhbmNlZCBNaWNybyBEZXZpY2Vz
IEdtYkgKPiBFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERvcm5hY2ggYi4gTXVlbmNoZW4KPiBHZXNj
aGFlZnRzZnVlaHJlcjogQWxiZXJ0byBCb3p6bywgQW5kcmV3IEJvd2QKPiBTaXR6OiBEb3JuYWNo
LCBHZW1laW5kZSBBc2NoaGVpbSwgTGFuZGtyZWlzIE11ZW5jaGVuCj4gUmVnaXN0ZXJnZXJpY2h0
IE11ZW5jaGVuLCBIUkIgTnIuIDQzNjMyCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:18:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:18:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0UoU-0003t7-CB; Thu, 23 Feb 2012 09:18:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0UoT-0003sw-7r
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:18:09 +0000
Received: from [85.158.139.83:16205] by server-10.bemta-5.messagelabs.com id
	1C/9D-07861-054064F4; Thu, 23 Feb 2012 09:18:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329988687!15735230!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18100 invoked from network); 23 Feb 2012 09:18:08 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 09:18:08 -0000
Received: by wgbdt11 with SMTP id dt11so6638482wgb.0
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 01:18:07 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr1399101wia.3.1329988687726 (num_hops =
	1); Thu, 23 Feb 2012 01:18:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=bCEdvTLth1e6oHYQSJyjwmeHLtgTFEhGqXatG7zzm1I=;
	b=p6z4Lf+TZphhgqwuU48OjaTbufE0LL5vF+M53jrlMK+bZabKstyRZ9MM3QSQX18pkK
	fZrpQIVr7KiqC07HzgqEYsTTm6uC2m08QSHzGSnroGNS7j9mdqoy81Z+a9zHtNvWUekE
	vJOLy3ALCe94+UbTJ48t/JddtgcpOV0xXrL58=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr1142815wia.3.1329988687675; Thu, 23
	Feb 2012 01:18:07 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 23 Feb 2012 01:18:07 -0800 (PST)
In-Reply-To: <4F44C1A7.6070405@amd.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
Date: Thu, 23 Feb 2012 10:18:07 +0100
X-Google-Sender-Auth: HnGtJjSXa7hZeuOyNWRKqaJtXuI
Message-ID: <CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+Ogo+IE9u
IDAyLzIyLzEyIDEwOjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Pgo+PiAyMDEyLzIvMjIg
Q2hyaXN0b3BoIEVnZ2VyPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPj4+Cj4+Pgo+Pj4gSGks
Cj4+Pgo+Pj4gY29uZmlndXJlIGZhaWxzIG9uIE5ldEJTRCB0aGF0IHRoZXJlIGlzIG5vIGJyY3Rs
Lgo+Pj4gTmV0QlNEIGhhcyBubyBicmN0bCwgTmV0QlNEIGhhcyBicmNvbmZpZy4KPj4KPj4KPj4g
U29ycnkgQ2hyaXN0b3BoLCB0aGUgYnJjdGwgdGVzdCBpcyBnb2luZyBhd2F5IChmcm9tIGNvbmZp
Z3VyZSBhdCBsZWFzdCkuCj4KPgo+IFRoZXJlIGFyZSBzb21lIG1vcmUgTGludXggc3BlY2lmaWMg
dGVzdHM6Cj4gLSBpcAo+IC0gdXVpZF9jbGVhciBpbiBsaWJ1dWlkCgpJJ20gZ29pbmcgdG8gZml4
IHRoaXMgcmlnaHQgbm93LiBTaG91bGQgSSBjb21taXQgdGhlIG91dHB1dCBmcm9tCmF1dG9jb25m
IGFsc28gd2l0aCBteSBwYXRjaGVzIElhbj8gSSdtIGFza2luZyB0aGlzIGJlY2F1c2Ugd2UgdXNl
CmRpZmZlcmVudCB2ZXJzaW9ucyBhbmQgdGhlIG91dHB1dCBpcyBzbGlnaHRseSBkaWZmZXJlbnQu
Cgo+IEFsc28gdGhlIGNoZWNrIGZvciB5YWpsX2FsbG9jIGluIGxpYnlhamwgZmFpbHMgYWx0aG91
Z2ggSSBoYXZlIGxpYnlhamwKPiB2ZXJzaW9uIDEgaW5zdGFsbGVkLiBUaGUgY2hlY2sgbWF5IGJl
IGNvcnJlY3QgYnV0IGNvbmZpZ3VyZSBzaG91bGRuJ3QgZmFpbAo+IGlmIHZlcnNpb24gMSBpcyBz
dGlsbCBzdXBwb3J0ZWQuCj4KPgo+IENocmlzdG9waAo+Cj4gLS0KPiAtLS10byBzYXRpc2Z5IEV1
cm9wZWFuIExhdyBmb3IgYnVzaW5lc3MgbGV0dGVyczoKPiBBZHZhbmNlZCBNaWNybyBEZXZpY2Vz
IEdtYkgKPiBFaW5zdGVpbnJpbmcgMjQsIDg1Njg5IERvcm5hY2ggYi4gTXVlbmNoZW4KPiBHZXNj
aGFlZnRzZnVlaHJlcjogQWxiZXJ0byBCb3p6bywgQW5kcmV3IEJvd2QKPiBTaXR6OiBEb3JuYWNo
LCBHZW1laW5kZSBBc2NoaGVpbSwgTGFuZGtyZWlzIE11ZW5jaGVuCj4gUmVnaXN0ZXJnZXJpY2h0
IE11ZW5jaGVuLCBIUkIgTnIuIDQzNjMyCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:55:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0VOW-0004tc-ML; Thu, 23 Feb 2012 09:55:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0VOU-0004tU-U9
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:55:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329990916!14406876!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 23 Feb 2012 09:55:16 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 09:55:16 -0000
Received: by wibhm2 with SMTP id hm2so2288962wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 01:55:16 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.216.137.4 as permitted sender) client-ip=10.216.137.4; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.216.137.4 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.216.137.4])
	by 10.216.137.4 with SMTP id x4mr405419wei.15.1329990916119 (num_hops =
	1); Thu, 23 Feb 2012 01:55:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=e/NUhtit0B31vtHgyrncP6Euwk2D72WNnQ6qXPRc5fE=;
	b=s8s66AkwWo35dBBwllmQM/emtM4oj09PtLavZ5YcieFpl0abYM8eLRRDIYvKLKviaX
	FeCeh4Bq65sCoFU/27hDKsNjVJihWu9QdkvLtXs1v7xmVnA8olIsZCr6GZSI2NxJX3SF
	oaiiUj+5WtGceLM2Ac/+RJ6T1bbUhPVQPGfU8=
Received: by 10.216.137.4 with SMTP id x4mr332491wei.15.1329990915965;
	Thu, 23 Feb 2012 01:55:15 -0800 (PST)
Received: from [192.168.1.3] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id n5sm4301631wiw.7.2012.02.23.01.55.13
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 01:55:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 23 Feb 2012 09:55:11 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB6BBD7F.39F64%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/2] x86/vMCE: save/restore MCA capabilities
Thread-Index: AczyETtKgb0Bti/1f0CpCZEexhArOg==
In-Reply-To: <4F3B9E2A0200007800073210@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/vMCE: save/restore MCA capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/2012 10:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> When migrating to a host with less MCA banks than the source host
> had, accesses to the extra banks' MCi_* MSRs caused #GP-s so far.
> By making the bank count (and other MCA capabilities) available to
> the destination host, it can properly ignore writes to extra banks the
> guest may know of, and return appropriate default values for reads.
> 
> The two patches can be applied independently (the second patch
> may need some refinement), but proper save/restore functionality
> can only be expected with both applied.
> 
> 1: don't advertise features we don't support
> 2: save/restore MCA capabilities
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:55:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09: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 1S0VOW-0004tc-ML; Thu, 23 Feb 2012 09:55:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0VOU-0004tU-U9
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:55:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1329990916!14406876!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 23 Feb 2012 09:55:16 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 09:55:16 -0000
Received: by wibhm2 with SMTP id hm2so2288962wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 01:55:16 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.216.137.4 as permitted sender) client-ip=10.216.137.4; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.216.137.4 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.216.137.4])
	by 10.216.137.4 with SMTP id x4mr405419wei.15.1329990916119 (num_hops =
	1); Thu, 23 Feb 2012 01:55:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=e/NUhtit0B31vtHgyrncP6Euwk2D72WNnQ6qXPRc5fE=;
	b=s8s66AkwWo35dBBwllmQM/emtM4oj09PtLavZ5YcieFpl0abYM8eLRRDIYvKLKviaX
	FeCeh4Bq65sCoFU/27hDKsNjVJihWu9QdkvLtXs1v7xmVnA8olIsZCr6GZSI2NxJX3SF
	oaiiUj+5WtGceLM2Ac/+RJ6T1bbUhPVQPGfU8=
Received: by 10.216.137.4 with SMTP id x4mr332491wei.15.1329990915965;
	Thu, 23 Feb 2012 01:55:15 -0800 (PST)
Received: from [192.168.1.3] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id n5sm4301631wiw.7.2012.02.23.01.55.13
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 01:55:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 23 Feb 2012 09:55:11 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB6BBD7F.39F64%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/2] x86/vMCE: save/restore MCA capabilities
Thread-Index: AczyETtKgb0Bti/1f0CpCZEexhArOg==
In-Reply-To: <4F3B9E2A0200007800073210@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH 0/2] x86/vMCE: save/restore MCA capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/2012 10:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> When migrating to a host with less MCA banks than the source host
> had, accesses to the extra banks' MCi_* MSRs caused #GP-s so far.
> By making the bank count (and other MCA capabilities) available to
> the destination host, it can properly ignore writes to extra banks the
> guest may know of, and return appropriate default values for reads.
> 
> The two patches can be applied independently (the second patch
> may need some refinement), but proper save/restore functionality
> can only be expected with both applied.
> 
> 1: don't advertise features we don't support
> 2: save/restore MCA capabilities
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 09:58:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0VRQ-00050n-89; Thu, 23 Feb 2012 09:58: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 1S0VRO-00050h-GK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:58:22 +0000
Received: from [85.158.139.83:57649] by server-4.bemta-5.messagelabs.com id
	15/3A-10788-DBD064F4; Thu, 23 Feb 2012 09:58:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329991101!15742727!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 23 Feb 2012 09:58:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 09:58:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10889770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:58:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:58:19 +0000
Message-ID: <1329991097.8557.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 23 Feb 2012 09:58:17 +0000
In-Reply-To: <2d1ac43212fa31cedda2.1329927860@probook.site>
References: <2d1ac43212fa31cedda2.1329927860@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: workaround make 3.82
 dependency flaw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 16:24 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1329927731 -3600
> # Node ID 2d1ac43212fa31cedda2b8e4ed90bea1d63d229b
> # Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
> tools/xenstore: workaround make 3.82 dependency flaw
> 
> After changeset 24767:28300f4562de build sometimes fails when make v3.82
> as shipped with openSuSE 11.4/12.1 is used.

Is there a corresponding bug report against make, either upstream or
SuSE?

I'd be much happier making an apparently random change as a workaround
if someone had suggest some reason why it should be the case.

> 
> Add a workaround until the reason for the changed dependency handling in
> make v3.82 is known.
> 
> The failure is a link error because the required libxenstore.so is not
> created before init-xenstore-domain is about to be linked. All required
> dependencies are listed, but they are ignored. So far the only way to
> hide the error is to list init-xenstore-domain first in ALL_TARGETS.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 0900b1c905f1 -r 2d1ac43212fa tools/xenstore/Makefile
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -27,7 +27,7 @@ LIBXENSTORE := libxenstore.a
>  xenstore xenstore-control: CFLAGS += -static
>  endif
>  
> -ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
> +ALL_TARGETS = init-xenstore-domain libxenstore.a libxenstore.so clients xs_tdb_dump xenstored
>  
>  ifdef CONFIG_STUBDOM
>  CFLAGS += -DNO_SOCKETS=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 Feb 23 09:58:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 09:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0VRQ-00050n-89; Thu, 23 Feb 2012 09:58: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 1S0VRO-00050h-GK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 09:58:22 +0000
Received: from [85.158.139.83:57649] by server-4.bemta-5.messagelabs.com id
	15/3A-10788-DBD064F4; Thu, 23 Feb 2012 09:58:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1329991101!15742727!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 23 Feb 2012 09:58:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 09:58:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10889770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:58:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:58:19 +0000
Message-ID: <1329991097.8557.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 23 Feb 2012 09:58:17 +0000
In-Reply-To: <2d1ac43212fa31cedda2.1329927860@probook.site>
References: <2d1ac43212fa31cedda2.1329927860@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: workaround make 3.82
 dependency flaw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 16:24 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1329927731 -3600
> # Node ID 2d1ac43212fa31cedda2b8e4ed90bea1d63d229b
> # Parent  0900b1c905f1d038aad58a2732fe2bad682149a3
> tools/xenstore: workaround make 3.82 dependency flaw
> 
> After changeset 24767:28300f4562de build sometimes fails when make v3.82
> as shipped with openSuSE 11.4/12.1 is used.

Is there a corresponding bug report against make, either upstream or
SuSE?

I'd be much happier making an apparently random change as a workaround
if someone had suggest some reason why it should be the case.

> 
> Add a workaround until the reason for the changed dependency handling in
> make v3.82 is known.
> 
> The failure is a link error because the required libxenstore.so is not
> created before init-xenstore-domain is about to be linked. All required
> dependencies are listed, but they are ignored. So far the only way to
> hide the error is to list init-xenstore-domain first in ALL_TARGETS.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 0900b1c905f1 -r 2d1ac43212fa tools/xenstore/Makefile
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -27,7 +27,7 @@ LIBXENSTORE := libxenstore.a
>  xenstore xenstore-control: CFLAGS += -static
>  endif
>  
> -ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
> +ALL_TARGETS = init-xenstore-domain libxenstore.a libxenstore.so clients xs_tdb_dump xenstored
>  
>  ifdef CONFIG_STUBDOM
>  CFLAGS += -DNO_SOCKETS=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 Feb 23 10:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Va4-0005Jd-AE; Thu, 23 Feb 2012 10:07:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Va2-0005JY-QT
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:07:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329991632!10351505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8149 invoked from network); 23 Feb 2012 10:07:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:07:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:07:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:07:12 +0000
Message-ID: <1329991630.8557.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:07:10 +0000
In-Reply-To: <032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> A way to integrate OVMF build directly into XEN has still be discussed
> on the mailing list appropriately.

AIUI OVMF is maintained in SVN. Our normal procedure for adding an
external dependency would be for us to mirror it on xenbits as a
convenience to our users, who don't need to get stuff from multiple
places, and as a courtesy to our upstreams, so our users don't consume
their resources.

I don't much fancy setting the necessary webdav or whatever stuff on
xenbits and integrating SVN support into our build system though. What
do people think about using git-svn to manage our mirror in git instead?
Or better: perhaps OVMF have an official git or hg mirror?

Anyone have any thoughts/opinions/better ideas etc?

> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
> @@ -35,6 +35,8 @@ struct bios_config {
>  
>  extern struct bios_config rombios_config;
>  extern struct bios_config seabios_config;
> +extern struct bios_config ovmf32_config;
> +extern struct bios_config ovmf64_config;

Can you confirm that you need an OVMF which matches the OS bit-width you
are installing. i..e that there is no support for booting a 32 bit EFI
OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

[...]
> +static void ovmf_acpi_build_tables(void)
> +{
> +    struct acpi_config config = {
> +        .dsdt_anycpu = dsdt_anycpu,
> +        .dsdt_anycpu_len = dsdt_anycpu_len,
> +        .dsdt_15cpu = dsdt_15cpu,
> +        .dsdt_15cpu_len = dsdt_15cpu_len,
> +    };

IIRC the 15cpu tables are there to workaround a bug in some old version
of Windows (2k?). I think therefore you can omit these on the basis that
no version of Windows with that bug also supports EFI. seabios.c does
this too.

[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Va4-0005Jd-AE; Thu, 23 Feb 2012 10:07:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Va2-0005JY-QT
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:07:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329991632!10351505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8149 invoked from network); 23 Feb 2012 10:07:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:07:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:07:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:07:12 +0000
Message-ID: <1329991630.8557.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:07:10 +0000
In-Reply-To: <032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> A way to integrate OVMF build directly into XEN has still be discussed
> on the mailing list appropriately.

AIUI OVMF is maintained in SVN. Our normal procedure for adding an
external dependency would be for us to mirror it on xenbits as a
convenience to our users, who don't need to get stuff from multiple
places, and as a courtesy to our upstreams, so our users don't consume
their resources.

I don't much fancy setting the necessary webdav or whatever stuff on
xenbits and integrating SVN support into our build system though. What
do people think about using git-svn to manage our mirror in git instead?
Or better: perhaps OVMF have an official git or hg mirror?

Anyone have any thoughts/opinions/better ideas etc?

> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
> @@ -35,6 +35,8 @@ struct bios_config {
>  
>  extern struct bios_config rombios_config;
>  extern struct bios_config seabios_config;
> +extern struct bios_config ovmf32_config;
> +extern struct bios_config ovmf64_config;

Can you confirm that you need an OVMF which matches the OS bit-width you
are installing. i..e that there is no support for booting a 32 bit EFI
OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?

[...]
> +static void ovmf_acpi_build_tables(void)
> +{
> +    struct acpi_config config = {
> +        .dsdt_anycpu = dsdt_anycpu,
> +        .dsdt_anycpu_len = dsdt_anycpu_len,
> +        .dsdt_15cpu = dsdt_15cpu,
> +        .dsdt_15cpu_len = dsdt_15cpu_len,
> +    };

IIRC the 15cpu tables are there to workaround a bug in some old version
of Windows (2k?). I think therefore you can omit these on the basis that
no version of Windows with that bug also supports EFI. seabios.c does
this too.

[...]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:13:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Vfv-0005UG-Fe; Thu, 23 Feb 2012 10:13:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0Vfu-0005U7-3k
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:13:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329991995!16076251!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1999 invoked from network); 23 Feb 2012 10:13:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:13:15 -0000
Received: by werb14 with SMTP id b14so2312074wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 02:13:15 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.82.39 as permitted sender) client-ip=10.180.82.39; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.82.39 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.82.39])
	by 10.180.82.39 with SMTP id f7mr1666217wiy.19.1329991995353 (num_hops
	= 1); Thu, 23 Feb 2012 02:13:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=BsAXGfwc1Nr1Y+/ZV7/1rkPl7bT8Tw1i4XBM2TD19sM=;
	b=AmPADM1ZcJtuQGi3gpu12+hPjM2JttdhNc3HMtr666O9vyGkWuMz3HdNEjLWBAv7es
	n1HAhwWfzvcPqCZVQiptYMLf2F9DbHC2IkG08HQBLyX7MaythMS+LmkijUt1/eFlnUu8
	IvyaVZfL52pH3EEBmzdTaUNgenckJDZqvSd6A=
Received: by 10.180.82.39 with SMTP id f7mr1364050wiy.19.1329991995221;
	Thu, 23 Feb 2012 02:13:15 -0800 (PST)
Received: from [192.168.1.3] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id dw7sm3335667wib.4.2012.02.23.02.13.13
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 02:13:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 23 Feb 2012 10:13:08 +0000
From: Keir Fraser <keir@xen.org>
To: Attilio Rao <attilio.rao@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB6BC1B4.39F6C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
	OVMF UEFI support and directly use it
Thread-Index: AczyE707bmmSdtL7NEqeCg5QfmdS5g==
In-Reply-To: <032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
Mime-version: 1.0
Cc: gbtju85@gmail.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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 22/02/2012 19:17, "Attilio Rao" <attilio.rao@citrix.com> wrote:

> when specified in the guest configuration file.
> This work is somewhat based on Bei Guan effort during the SoC 2011 and
> relies on upstream edk2/ovmf Tianocore ROM to be built separately and
> manually copied as:
> Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd -> tools/firmware/ovmf/ovmf-x64.bin
> Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd -> toolf/firmware/ovmf/ovmf-ia32.bin
> 
> A way to integrate OVMF build directly into XEN has still be discussed
> on the mailing list appropriately.

I applied this patch but changed CONFIG_OVMF to 'n' so that we don't break
the default build while ovmf is not integrated into our build process.

I have not applied the other patch (to libxl), but leave that to be reviewed
by libxl maintainers.

 -- Keir

> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> 
> diff -r a88ba599add1 -r 032fea10f8d1 Config.mk
> --- a/Config.mk Tue Feb 21 17:45:59 2012 +0000
> +++ b/Config.mk Wed Feb 22 18:54:03 2012 +0000
> @@ -224,6 +224,7 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
>  
>  ETHERBOOT_NICS ?= rtl8139 8086100e
>  
> +CONFIG_OVMF ?= y
>  CONFIG_ROMBIOS ?= y
>  CONFIG_SEABIOS ?= y
>  
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/Makefile
> --- a/tools/firmware/hvmloader/Makefile Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/Makefile Wed Feb 22 18:54:03 2012 +0000
> @@ -37,6 +37,7 @@ endif
>  
>  CIRRUSVGA_DEBUG ?= n
>  
> +OVMF_DIR := ../ovmf
>  ROMBIOS_DIR := ../rombios
>  SEABIOS_DIR := ../seabios-dir
>  
> @@ -52,6 +53,14 @@ endif
>  
>  ROMS := 
>  
> +ifeq ($(CONFIG_OVMF),y)
> +OBJS += ovmf.o
> +CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
> +OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
> +OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
> +ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
> +endif
> +
>  ifeq ($(CONFIG_ROMBIOS),y)
>  OBJS += optionroms.o 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
> @@ -70,7 +79,7 @@ endif
>  all: subdirs-all
> $(MAKE) hvmloader
>  
> -rombios.o seabios.o hvmloader.o: roms.inc
> +ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
>  
>  hvmloader: $(OBJS) acpi/acpi.a
> @@ -93,6 +102,18 @@ ifneq ($(SEABIOS_ROM),)
> echo "#endif" >> $@.new
>  endif
>  
> +ifneq ($(OVMF32_ROM),)
> + echo "#ifdef ROM_INCLUDE_OVMF32" >> $@.new
> + sh ./mkhex ovmf32 $(OVMF32_ROM) >> $@.new
> + echo "#endif" >> $@.new 
> +endif 
> +
> +ifneq ($(OVMF64_ROM),)
> + echo "#ifdef ROM_INCLUDE_OVMF64" >> $@.new
> + sh ./mkhex ovmf64 $(OVMF64_ROM) >> $@.new
> + echo "#endif" >> $@.new 
> +endif 
> +
>  ifneq ($(STDVGA_ROM),)
> echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
> sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/config.h Wed Feb 22 18:54:03 2012 +0000
> @@ -35,6 +35,8 @@ struct bios_config {
>  
>  extern struct bios_config rombios_config;
>  extern struct bios_config seabios_config;
> +extern struct bios_config ovmf32_config;
> +extern struct bios_config ovmf64_config;
>  
>  #define PAGE_SHIFT 12
>  #define PAGE_SIZE  (1ul << PAGE_SHIFT)
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c Wed Feb 22 18:54:03 2012 +0000
> @@ -212,6 +212,12 @@ struct bios_info {
>  #ifdef ENABLE_SEABIOS
>      { "seabios", &seabios_config, },
>  #endif
> +#ifdef ENABLE_OVMF32
> +    { "ovmf-ia32", &ovmf32_config, },
> +#endif
> +#ifdef ENABLE_OVMF64
> +    { "ovmf-x64", &ovmf64_config, },
> +#endif
>      { NULL, NULL }
>  };
>  
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/ovmf.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/ovmf.c Wed Feb 22 18:54:03 2012 +0000
> @@ -0,0 +1,147 @@
> +/*
> + * HVM OVMF UEFI support.
> + *
> + * Bei Guan, gbtju85@gmail.com
> + * Andrei Warkentin, andreiw@motorola.com
> + * Leendert van Doorn, leendert@watson.ibm.com
> + * Copyright (c) 2005, International Business Machines Corporation.
> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
> + * Copyright (c) 2011, Citrix Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59
> Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + */
> +
> +#include "config.h"
> +#include "smbios_types.h"
> +#include "acpi/acpi2_0.h"
> +#include "apic_regs.h"
> +#include "../rombios/config.h"
> +#include "util.h"
> +#include "pci_regs.h"
> +#include "hypercall.h"
> +
> +#include <xen/hvm/params.h>
> +#include <xen/hvm/ioreq.h>
> +#include <xen/memory.h>
> +
> +#define ROM_INCLUDE_OVMF32
> +#define ROM_INCLUDE_OVMF64
> +#include "roms.inc"
> +
> +#define OVMF_BEGIN              0xFFF00000ULL
> +#define OVMF_SIZE               0x00100000ULL
> +#define OVMF_MAXOFFSET          0x000FFFFFULL
> +#define OVMF_END                (OVMF_BEGIN + OVMF_SIZE)
> +#define LOWCHUNK_BEGIN          0x000F0000
> +#define LOWCHUNK_SIZE           0x00010000
> +#define LOWCHUNK_MAXOFFSET      0x0000FFFF
> +#define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
> +
> +extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
> +extern int dsdt_anycpu_len, dsdt_15cpu_len;
> +
> +static void ovmf_load(const struct bios_config *config)
> +{
> +    xen_pfn_t mfn;
> +    uint64_t addr = OVMF_BEGIN;
> +
> +    /* Copy low-reset vector portion. */
> +    memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
> +           + OVMF_SIZE
> +           - LOWCHUNK_SIZE,
> +           LOWCHUNK_SIZE);
> +
> +    /* Ensure we have backing page prior to moving FD. */
> +    while ((addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT)) {
> +        mfn = (uint32_t) (addr >> PAGE_SHIFT);
> +        addr += PAGE_SIZE;
> + mem_hole_populate_ram(mfn, 1);
> +    }
> +
> +    /* Copy FD. */
> +    memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
> +}
> +
> +static void ovmf_acpi_build_tables(void)
> +{
> +    struct acpi_config config = {
> +        .dsdt_anycpu = dsdt_anycpu,
> +        .dsdt_anycpu_len = dsdt_anycpu_len,
> +        .dsdt_15cpu = dsdt_15cpu,
> +        .dsdt_15cpu_len = dsdt_15cpu_len,
> +    };
> +
> +    acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> +}
> +
> +static void ovmf_create_smbios_tables(void)
> +{
> +    hvm_write_smbios_tables(SMBIOS_PHYSICAL_ADDRESS,
> +                            SMBIOS_PHYSICAL_ADDRESS + sizeof(struct
> smbios_entry_point),
> +                            SMBIOS_PHYSICAL_END);
> +}
> +
> +struct bios_config ovmf32_config =  {
> +    .name = "OVMF-IA32",
> +
> +    .image = ovmf32,
> +    .image_size = sizeof(ovmf32),
> +
> +    .bios_address = 0,
> +    .bios_load = ovmf_load,
> +
> +    .load_roms = 0,
> +
> +    .bios_info_setup = NULL,
> +    .bios_info_finish = NULL,
> +
> +    .e820_setup = NULL,
> +
> +    .acpi_build_tables = ovmf_acpi_build_tables,
> +    .create_mp_tables = NULL,
> +    .create_smbios_tables = ovmf_create_smbios_tables,
> +    .create_pir_tables = NULL,
> +};
> +
> +struct bios_config ovmf64_config =  {
> +    .name = "OVMF-X64",
> +
> +    .image = ovmf64,
> +    .image_size = sizeof(ovmf64),
> +
> +    .bios_address = 0,
> +    .bios_load = ovmf_load,
> +
> +    .load_roms = 0,
> +
> +    .bios_info_setup = NULL,
> +    .bios_info_finish = NULL,
> +
> +    .e820_setup = NULL,
> +
> +    .acpi_build_tables = ovmf_acpi_build_tables,
> +    .create_mp_tables = NULL,
> +    .create_smbios_tables = ovmf_create_smbios_tables,
> +    .create_pir_tables = NULL,
> +};
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:13:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Vfv-0005UG-Fe; Thu, 23 Feb 2012 10:13:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0Vfu-0005U7-3k
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:13:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1329991995!16076251!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1999 invoked from network); 23 Feb 2012 10:13:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:13:15 -0000
Received: by werb14 with SMTP id b14so2312074wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 02:13:15 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.82.39 as permitted sender) client-ip=10.180.82.39; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.82.39 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.82.39])
	by 10.180.82.39 with SMTP id f7mr1666217wiy.19.1329991995353 (num_hops
	= 1); Thu, 23 Feb 2012 02:13:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=BsAXGfwc1Nr1Y+/ZV7/1rkPl7bT8Tw1i4XBM2TD19sM=;
	b=AmPADM1ZcJtuQGi3gpu12+hPjM2JttdhNc3HMtr666O9vyGkWuMz3HdNEjLWBAv7es
	n1HAhwWfzvcPqCZVQiptYMLf2F9DbHC2IkG08HQBLyX7MaythMS+LmkijUt1/eFlnUu8
	IvyaVZfL52pH3EEBmzdTaUNgenckJDZqvSd6A=
Received: by 10.180.82.39 with SMTP id f7mr1364050wiy.19.1329991995221;
	Thu, 23 Feb 2012 02:13:15 -0800 (PST)
Received: from [192.168.1.3] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id dw7sm3335667wib.4.2012.02.23.02.13.13
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 02:13:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 23 Feb 2012 10:13:08 +0000
From: Keir Fraser <keir@xen.org>
To: Attilio Rao <attilio.rao@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB6BC1B4.39F6C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
	OVMF UEFI support and directly use it
Thread-Index: AczyE707bmmSdtL7NEqeCg5QfmdS5g==
In-Reply-To: <032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
Mime-version: 1.0
Cc: gbtju85@gmail.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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 22/02/2012 19:17, "Attilio Rao" <attilio.rao@citrix.com> wrote:

> when specified in the guest configuration file.
> This work is somewhat based on Bei Guan effort during the SoC 2011 and
> relies on upstream edk2/ovmf Tianocore ROM to be built separately and
> manually copied as:
> Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd -> tools/firmware/ovmf/ovmf-x64.bin
> Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd -> toolf/firmware/ovmf/ovmf-ia32.bin
> 
> A way to integrate OVMF build directly into XEN has still be discussed
> on the mailing list appropriately.

I applied this patch but changed CONFIG_OVMF to 'n' so that we don't break
the default build while ovmf is not integrated into our build process.

I have not applied the other patch (to libxl), but leave that to be reviewed
by libxl maintainers.

 -- Keir

> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> 
> diff -r a88ba599add1 -r 032fea10f8d1 Config.mk
> --- a/Config.mk Tue Feb 21 17:45:59 2012 +0000
> +++ b/Config.mk Wed Feb 22 18:54:03 2012 +0000
> @@ -224,6 +224,7 @@ SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
>  
>  ETHERBOOT_NICS ?= rtl8139 8086100e
>  
> +CONFIG_OVMF ?= y
>  CONFIG_ROMBIOS ?= y
>  CONFIG_SEABIOS ?= y
>  
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/Makefile
> --- a/tools/firmware/hvmloader/Makefile Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/Makefile Wed Feb 22 18:54:03 2012 +0000
> @@ -37,6 +37,7 @@ endif
>  
>  CIRRUSVGA_DEBUG ?= n
>  
> +OVMF_DIR := ../ovmf
>  ROMBIOS_DIR := ../rombios
>  SEABIOS_DIR := ../seabios-dir
>  
> @@ -52,6 +53,14 @@ endif
>  
>  ROMS := 
>  
> +ifeq ($(CONFIG_OVMF),y)
> +OBJS += ovmf.o
> +CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
> +OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
> +OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
> +ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
> +endif
> +
>  ifeq ($(CONFIG_ROMBIOS),y)
>  OBJS += optionroms.o 32bitbios_support.o rombios.o
>  CFLAGS += -DENABLE_ROMBIOS
> @@ -70,7 +79,7 @@ endif
>  all: subdirs-all
> $(MAKE) hvmloader
>  
> -rombios.o seabios.o hvmloader.o: roms.inc
> +ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(shell date +%m/%d/%Y)\""
>  
>  hvmloader: $(OBJS) acpi/acpi.a
> @@ -93,6 +102,18 @@ ifneq ($(SEABIOS_ROM),)
> echo "#endif" >> $@.new
>  endif
>  
> +ifneq ($(OVMF32_ROM),)
> + echo "#ifdef ROM_INCLUDE_OVMF32" >> $@.new
> + sh ./mkhex ovmf32 $(OVMF32_ROM) >> $@.new
> + echo "#endif" >> $@.new 
> +endif 
> +
> +ifneq ($(OVMF64_ROM),)
> + echo "#ifdef ROM_INCLUDE_OVMF64" >> $@.new
> + sh ./mkhex ovmf64 $(OVMF64_ROM) >> $@.new
> + echo "#endif" >> $@.new 
> +endif 
> +
>  ifneq ($(STDVGA_ROM),)
> echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
> sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/config.h Wed Feb 22 18:54:03 2012 +0000
> @@ -35,6 +35,8 @@ struct bios_config {
>  
>  extern struct bios_config rombios_config;
>  extern struct bios_config seabios_config;
> +extern struct bios_config ovmf32_config;
> +extern struct bios_config ovmf64_config;
>  
>  #define PAGE_SHIFT 12
>  #define PAGE_SIZE  (1ul << PAGE_SHIFT)
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c Tue Feb 21 17:45:59 2012 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c Wed Feb 22 18:54:03 2012 +0000
> @@ -212,6 +212,12 @@ struct bios_info {
>  #ifdef ENABLE_SEABIOS
>      { "seabios", &seabios_config, },
>  #endif
> +#ifdef ENABLE_OVMF32
> +    { "ovmf-ia32", &ovmf32_config, },
> +#endif
> +#ifdef ENABLE_OVMF64
> +    { "ovmf-x64", &ovmf64_config, },
> +#endif
>      { NULL, NULL }
>  };
>  
> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/ovmf.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/ovmf.c Wed Feb 22 18:54:03 2012 +0000
> @@ -0,0 +1,147 @@
> +/*
> + * HVM OVMF UEFI support.
> + *
> + * Bei Guan, gbtju85@gmail.com
> + * Andrei Warkentin, andreiw@motorola.com
> + * Leendert van Doorn, leendert@watson.ibm.com
> + * Copyright (c) 2005, International Business Machines Corporation.
> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
> + * Copyright (c) 2011, Citrix Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59
> Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + */
> +
> +#include "config.h"
> +#include "smbios_types.h"
> +#include "acpi/acpi2_0.h"
> +#include "apic_regs.h"
> +#include "../rombios/config.h"
> +#include "util.h"
> +#include "pci_regs.h"
> +#include "hypercall.h"
> +
> +#include <xen/hvm/params.h>
> +#include <xen/hvm/ioreq.h>
> +#include <xen/memory.h>
> +
> +#define ROM_INCLUDE_OVMF32
> +#define ROM_INCLUDE_OVMF64
> +#include "roms.inc"
> +
> +#define OVMF_BEGIN              0xFFF00000ULL
> +#define OVMF_SIZE               0x00100000ULL
> +#define OVMF_MAXOFFSET          0x000FFFFFULL
> +#define OVMF_END                (OVMF_BEGIN + OVMF_SIZE)
> +#define LOWCHUNK_BEGIN          0x000F0000
> +#define LOWCHUNK_SIZE           0x00010000
> +#define LOWCHUNK_MAXOFFSET      0x0000FFFF
> +#define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
> +
> +extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
> +extern int dsdt_anycpu_len, dsdt_15cpu_len;
> +
> +static void ovmf_load(const struct bios_config *config)
> +{
> +    xen_pfn_t mfn;
> +    uint64_t addr = OVMF_BEGIN;
> +
> +    /* Copy low-reset vector portion. */
> +    memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
> +           + OVMF_SIZE
> +           - LOWCHUNK_SIZE,
> +           LOWCHUNK_SIZE);
> +
> +    /* Ensure we have backing page prior to moving FD. */
> +    while ((addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT)) {
> +        mfn = (uint32_t) (addr >> PAGE_SHIFT);
> +        addr += PAGE_SIZE;
> + mem_hole_populate_ram(mfn, 1);
> +    }
> +
> +    /* Copy FD. */
> +    memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
> +}
> +
> +static void ovmf_acpi_build_tables(void)
> +{
> +    struct acpi_config config = {
> +        .dsdt_anycpu = dsdt_anycpu,
> +        .dsdt_anycpu_len = dsdt_anycpu_len,
> +        .dsdt_15cpu = dsdt_15cpu,
> +        .dsdt_15cpu_len = dsdt_15cpu_len,
> +    };
> +
> +    acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> +}
> +
> +static void ovmf_create_smbios_tables(void)
> +{
> +    hvm_write_smbios_tables(SMBIOS_PHYSICAL_ADDRESS,
> +                            SMBIOS_PHYSICAL_ADDRESS + sizeof(struct
> smbios_entry_point),
> +                            SMBIOS_PHYSICAL_END);
> +}
> +
> +struct bios_config ovmf32_config =  {
> +    .name = "OVMF-IA32",
> +
> +    .image = ovmf32,
> +    .image_size = sizeof(ovmf32),
> +
> +    .bios_address = 0,
> +    .bios_load = ovmf_load,
> +
> +    .load_roms = 0,
> +
> +    .bios_info_setup = NULL,
> +    .bios_info_finish = NULL,
> +
> +    .e820_setup = NULL,
> +
> +    .acpi_build_tables = ovmf_acpi_build_tables,
> +    .create_mp_tables = NULL,
> +    .create_smbios_tables = ovmf_create_smbios_tables,
> +    .create_pir_tables = NULL,
> +};
> +
> +struct bios_config ovmf64_config =  {
> +    .name = "OVMF-X64",
> +
> +    .image = ovmf64,
> +    .image_size = sizeof(ovmf64),
> +
> +    .bios_address = 0,
> +    .bios_load = ovmf_load,
> +
> +    .load_roms = 0,
> +
> +    .bios_info_setup = NULL,
> +    .bios_info_finish = NULL,
> +
> +    .e820_setup = NULL,
> +
> +    .acpi_build_tables = ovmf_acpi_build_tables,
> +    .create_mp_tables = NULL,
> +    .create_smbios_tables = ovmf_create_smbios_tables,
> +    .create_pir_tables = NULL,
> +};
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:13:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0Vg6-0005VV-1Q; Thu, 23 Feb 2012 10:13:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Vg4-0005Uo-3F
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:13:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329992004!9290395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18169 invoked from network); 23 Feb 2012 10:13:24 -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;
	23 Feb 2012 10:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:13:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:13:24 +0000
Message-ID: <1329992002.8557.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:13:22 +0000
In-Reply-To: <520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the
 option "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> configuration file.
> An example is given by:
> bios_override="ovmf-x64"

I'm not sure I would use the override suffix here -- that is generally
for settings where we recommend that the user accepts the default. In
this case though a user has perfectly valid reasons for selecting
ovmf-{32,64} or seabios etc.

Also please update docs/man/xl.cfg.pod.5 to document the new setting.

> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>  static const char *libxl__domain_bios(libxl__gc *gc,
>                                  const libxl_domain_build_info *info)
>  {
> +    if (info->u.hvm.bios)
> +       return info->u.hvm.bios;
>      switch (info->device_model_version) {
>      case 1: return "rombios";
>      case 2: return "seabios";

Should integrate this function into libxl__domain_build_info_setdefaults
from my "libxl: improved handling for default values in API" series.

Also it would be good to use that same infrastructure to enforce that
qemu-xen-traditional can only use rombios and that seabios and ovmf-*
are only valid with qemu-xen.

> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
> @@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
>  
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware", string),
> +                                       ("bios", string),

I think an Enumeration would be better here.

>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:54:03 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:56:22 2012 +0000
> @@ -704,6 +704,8 @@ static void parse_config_data(const char
>  
>          xlu_cfg_replace_string (config, "firmware_override",
>                                  &b_info->u.hvm.firmware, 0);
> +        xlu_cfg_replace_string (config, "bios_override",
> +                                &b_info->u.hvm.bios, 0);
>          if (!xlu_cfg_get_long (config, "pae", &l, 0))
>              b_info->u.hvm.pae = l;
>          if (!xlu_cfg_get_long (config, "apic", &l, 0))
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:13:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0Vg6-0005VV-1Q; Thu, 23 Feb 2012 10:13:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Vg4-0005Uo-3F
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:13:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1329992004!9290395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18169 invoked from network); 23 Feb 2012 10:13:24 -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;
	23 Feb 2012 10:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:13:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:13:24 +0000
Message-ID: <1329992002.8557.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:13:22 +0000
In-Reply-To: <520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the
 option "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> configuration file.
> An example is given by:
> bios_override="ovmf-x64"

I'm not sure I would use the override suffix here -- that is generally
for settings where we recommend that the user accepts the default. In
this case though a user has perfectly valid reasons for selecting
ovmf-{32,64} or seabios etc.

Also please update docs/man/xl.cfg.pod.5 to document the new setting.

> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>  static const char *libxl__domain_bios(libxl__gc *gc,
>                                  const libxl_domain_build_info *info)
>  {
> +    if (info->u.hvm.bios)
> +       return info->u.hvm.bios;
>      switch (info->device_model_version) {
>      case 1: return "rombios";
>      case 2: return "seabios";

Should integrate this function into libxl__domain_build_info_setdefaults
from my "libxl: improved handling for default values in API" series.

Also it would be good to use that same infrastructure to enforce that
qemu-xen-traditional can only use rombios and that seabios and ovmf-*
are only valid with qemu-xen.

> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
> @@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
>  
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware", string),
> +                                       ("bios", string),

I think an Enumeration would be better here.

>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:54:03 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 22 18:56:22 2012 +0000
> @@ -704,6 +704,8 @@ static void parse_config_data(const char
>  
>          xlu_cfg_replace_string (config, "firmware_override",
>                                  &b_info->u.hvm.firmware, 0);
> +        xlu_cfg_replace_string (config, "bios_override",
> +                                &b_info->u.hvm.bios, 0);
>          if (!xlu_cfg_get_long (config, "pae", &l, 0))
>              b_info->u.hvm.pae = l;
>          if (!xlu_cfg_get_long (config, "apic", &l, 0))
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:17:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0Vk0-0005mb-Me; Thu, 23 Feb 2012 10:17:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0Vjz-0005m8-D1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:17:35 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329992182!62270949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5842 invoked from network); 23 Feb 2012 10:16:22 -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;
	23 Feb 2012 10:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:17:29 +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.213.0;
	Thu, 23 Feb 2012 10:17:29 +0000
Message-ID: <4F461276.1030108@citrix.com>
Date: Thu, 23 Feb 2012 10:18:30 +0000
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: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>	
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329991630.8557.52.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/02/12 10:07, Ian Campbell wrote:
> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>    
>> A way to integrate OVMF build directly into XEN has still be discussed
>> on the mailing list appropriately.
>>      
> AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> external dependency would be for us to mirror it on xenbits as a
> convenience to our users, who don't need to get stuff from multiple
> places, and as a courtesy to our upstreams, so our users don't consume
> their resources.
>
> I don't much fancy setting the necessary webdav or whatever stuff on
> xenbits and integrating SVN support into our build system though. What
> do people think about using git-svn to manage our mirror in git instead?
> Or better: perhaps OVMF have an official git or hg mirror?
>
> Anyone have any thoughts/opinions/better ideas etc?
>
>    
>> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
>> --- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
>> +++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
>> @@ -35,6 +35,8 @@ struct bios_config {
>>
>>   extern struct bios_config rombios_config;
>>   extern struct bios_config seabios_config;
>> +extern struct bios_config ovmf32_config;
>> +extern struct bios_config ovmf64_config;
>>      
> Can you confirm that you need an OVMF which matches the OS bit-width you
> are installing. i..e that there is no support for booting a 32 bit EFI
> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>
>    

I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
possibly work.
You are suggesting if this is the case we should just ship the 64-bit 
emulation?
> [...]
>    
>> +static void ovmf_acpi_build_tables(void)
>> +{
>> +    struct acpi_config config = {
>> +        .dsdt_anycpu = dsdt_anycpu,
>> +        .dsdt_anycpu_len = dsdt_anycpu_len,
>> +        .dsdt_15cpu = dsdt_15cpu,
>> +        .dsdt_15cpu_len = dsdt_15cpu_len,
>> +    };
>>      
> IIRC the 15cpu tables are there to workaround a bug in some old version
> of Windows (2k?). I think therefore you can omit these on the basis that
> no version of Windows with that bug also supports EFI. seabios.c does
> this too.
>    

Yes, I was just unsure which of the 2 approaches (use dsdt_15cpu/skip 
completely) was preferred here so I went with the more 'complete' but it 
makes sense.

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 Feb 23 10:17:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0Vk0-0005mb-Me; Thu, 23 Feb 2012 10:17:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0Vjz-0005m8-D1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:17:35 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1329992182!62270949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5842 invoked from network); 23 Feb 2012 10:16:22 -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;
	23 Feb 2012 10:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:17:29 +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.213.0;
	Thu, 23 Feb 2012 10:17:29 +0000
Message-ID: <4F461276.1030108@citrix.com>
Date: Thu, 23 Feb 2012 10:18:30 +0000
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: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>	
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329991630.8557.52.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/02/12 10:07, Ian Campbell wrote:
> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>    
>> A way to integrate OVMF build directly into XEN has still be discussed
>> on the mailing list appropriately.
>>      
> AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> external dependency would be for us to mirror it on xenbits as a
> convenience to our users, who don't need to get stuff from multiple
> places, and as a courtesy to our upstreams, so our users don't consume
> their resources.
>
> I don't much fancy setting the necessary webdav or whatever stuff on
> xenbits and integrating SVN support into our build system though. What
> do people think about using git-svn to manage our mirror in git instead?
> Or better: perhaps OVMF have an official git or hg mirror?
>
> Anyone have any thoughts/opinions/better ideas etc?
>
>    
>> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
>> --- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
>> +++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
>> @@ -35,6 +35,8 @@ struct bios_config {
>>
>>   extern struct bios_config rombios_config;
>>   extern struct bios_config seabios_config;
>> +extern struct bios_config ovmf32_config;
>> +extern struct bios_config ovmf64_config;
>>      
> Can you confirm that you need an OVMF which matches the OS bit-width you
> are installing. i..e that there is no support for booting a 32 bit EFI
> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>
>    

I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
possibly work.
You are suggesting if this is the case we should just ship the 64-bit 
emulation?
> [...]
>    
>> +static void ovmf_acpi_build_tables(void)
>> +{
>> +    struct acpi_config config = {
>> +        .dsdt_anycpu = dsdt_anycpu,
>> +        .dsdt_anycpu_len = dsdt_anycpu_len,
>> +        .dsdt_15cpu = dsdt_15cpu,
>> +        .dsdt_15cpu_len = dsdt_15cpu_len,
>> +    };
>>      
> IIRC the 15cpu tables are there to workaround a bug in some old version
> of Windows (2k?). I think therefore you can omit these on the basis that
> no version of Windows with that bug also supports EFI. seabios.c does
> this too.
>    

Yes, I was just unsure which of the 2 approaches (use dsdt_15cpu/skip 
completely) was preferred here so I went with the more 'complete' but it 
makes sense.

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 Feb 23 10:21:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0VnD-0005wT-AJ; Thu, 23 Feb 2012 10:20:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0VnC-0005wA-4y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:20:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329992446!17892975!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26439 invoked from network); 23 Feb 2012 10:20:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:20:47 -0000
Received: by werb14 with SMTP id b14so2329410wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 02:20:46 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.216.138.34 as permitted sender) client-ip=10.216.138.34; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.216.138.34 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.216.138.34])
	by 10.216.138.34 with SMTP id z34mr427629wei.27.1329992446734 (num_hops
	= 1); Thu, 23 Feb 2012 02:20:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=7SSsCjTny6090tqMgUUy9EUv1tiBDG3O5bZ3vL4KE7E=;
	b=nJmAqHHvUHOldnuTLZiHZ9FlsUDO85m7IYbPfQezhS9ivm0bcprYKS7NaIgkM9YKhL
	FJD/oAdhgcozf2Az3FGXh6X9MONJRZ6KhYDT/sHRUmP2n+6t8+Qs/zsWCz0XR6tJDVNF
	7t4pO23juGemb2iKgurmDIwT1a7z86hPcma0w=
Received: by 10.216.138.34 with SMTP id z34mr350258wei.27.1329992446629;
	Thu, 23 Feb 2012 02:20:46 -0800 (PST)
Received: from [192.168.1.3] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id fw5sm3401806wib.0.2012.02.23.02.20.44
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 02:20:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 23 Feb 2012 10:20:41 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB6BC379.39F6F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 6 of 9] libxl: Rename libxl_sched_* to
	include _domain
Thread-Index: AczyFMs9UquOsU5EXkOzg4+Jy/iCiA==
In-Reply-To: <af02b1ea16dabf3d96f2.1329927312@kodo2>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9] libxl: Rename libxl_sched_* to
 include _domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/02/2012 16:15, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> In preparation for introducing a schedule parameter-based structure,
> rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
> 
> No functional changes.
> 
> v2: Wrap long lines while I'm at it

I've applied up to and including this patch (since it's Acked by Ian). I
leave the remaining three patches to a libxl maintainer.

 -- Keir

> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/libxl.c Wed Feb 22 16:08:28 2012 +0000
> @@ -2975,7 +2975,8 @@ int libxl_get_sched_id(libxl_ctx *ctx)
>      return sched;
>  }
>  
> -int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
> libxl_sched_credit *scinfo)
> +int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_sched_credit_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit sdom;
>      int rc;
> @@ -2992,7 +2993,8 @@ int libxl_sched_credit_domain_get(libxl_
>      return 0;
>  }
>  
> -int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
> libxl_sched_credit *scinfo)
> +int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_sched_credit_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit sdom;
>      xc_domaininfo_t domaininfo;
> @@ -3033,7 +3035,7 @@ int libxl_sched_credit_domain_set(libxl_
>  }
>  
>  int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo)
> +                                   libxl_sched_credit2_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit2 sdom;
>      int rc;
> @@ -3051,7 +3053,7 @@ int libxl_sched_credit2_domain_get(libxl
>  }
>  
>  int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo)
> +                                   libxl_sched_credit2_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit2 sdom;
>      xc_domaininfo_t domaininfo;
> @@ -3086,7 +3088,7 @@ int libxl_sched_credit2_domain_set(libxl
>  }
>  
>  int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo)
> +                                libxl_sched_sedf_domain *scinfo)
>  {
>      uint64_t period;
>      uint64_t slice;
> @@ -3112,7 +3114,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
>  }
>  
>  int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo)
> +                                libxl_sched_sedf_domain *scinfo)
>  {
>      xc_domaininfo_t domaininfo;
>      int rc;
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/libxl.h Wed Feb 22 16:08:28 2012 +0000
> @@ -588,17 +588,17 @@ int libxl_get_sched_id(libxl_ctx *ctx);
>  
>  
>  int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                  libxl_sched_credit *scinfo);
> +                                  libxl_sched_credit_domain *scinfo);
>  int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                  libxl_sched_credit *scinfo);
> +                                  libxl_sched_credit_domain *scinfo);
>  int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo);
> +                                   libxl_sched_credit2_domain *scinfo);
>  int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo);
> +                                   libxl_sched_credit2_domain *scinfo);
>  int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo);
> +                                libxl_sched_sedf_domain *scinfo);
>  int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo);
> +                                libxl_sched_sedf_domain *scinfo);
>  int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
>                         libxl_trigger trigger, uint32_t vcpuid);
>  int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/libxl_types.idl Wed Feb 22 16:08:28 2012 +0000
> @@ -390,16 +390,16 @@ libxl_cputopology = Struct("cputopology"
>      ("node", uint32),
>      ])
>  
> -libxl_sched_credit = Struct("sched_credit", [
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
>      ("weight", integer),
>      ("cap", integer),
>      ], dispose_fn=None)
>  
> -libxl_sched_credit2 = Struct("sched_credit2", [
> +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
>      ("weight", integer),
>      ], dispose_fn=None)
>  
> -libxl_sched_sedf = Struct("sched_sedf", [
> +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
>      ("period", integer),
>      ("slice", integer),
>      ("latency", integer),
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c Wed Feb 22 16:08:28 2012 +0000
> @@ -3913,7 +3913,7 @@ int main_sharing(int argc, char **argv)
>  }
>  
>  static int sched_credit_domain_get(
> -    int domid, libxl_sched_credit *scinfo)
> +    int domid, libxl_sched_credit_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3925,7 +3925,7 @@ static int sched_credit_domain_get(
>  }
>  
>  static int sched_credit_domain_set(
> -    int domid, libxl_sched_credit *scinfo)
> +    int domid, libxl_sched_credit_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3940,7 +3940,7 @@ static int sched_credit_domain_output(
>      int domid)
>  {
>      char *domname;
> -    libxl_sched_credit scinfo;
> +    libxl_sched_credit_domain scinfo;
>      int rc;
>  
>      if (domid < 0) {
> @@ -3961,7 +3961,7 @@ static int sched_credit_domain_output(
>  }
>  
>  static int sched_credit2_domain_get(
> -    int domid, libxl_sched_credit2 *scinfo)
> +    int domid, libxl_sched_credit2_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3973,7 +3973,7 @@ static int sched_credit2_domain_get(
>  }
>  
>  static int sched_credit2_domain_set(
> -    int domid, libxl_sched_credit2 *scinfo)
> +    int domid, libxl_sched_credit2_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3988,7 +3988,7 @@ static int sched_credit2_domain_output(
>      int domid)
>  {
>      char *domname;
> -    libxl_sched_credit2 scinfo;
> +    libxl_sched_credit2_domain scinfo;
>      int rc;
>  
>      if (domid < 0) {
> @@ -4008,7 +4008,7 @@ static int sched_credit2_domain_output(
>  }
>  
>  static int sched_sedf_domain_get(
> -    int domid, libxl_sched_sedf *scinfo)
> +    int domid, libxl_sched_sedf_domain *scinfo)
>  {
>      int rc;
>  
> @@ -4020,7 +4020,7 @@ static int sched_sedf_domain_get(
>  }
>  
>  static int sched_sedf_domain_set(
> -    int domid, libxl_sched_sedf *scinfo)
> +    int domid, libxl_sched_sedf_domain *scinfo)
>  {
>      int rc;
>  
> @@ -4035,7 +4035,7 @@ static int sched_sedf_domain_output(
>      int domid)
>  {
>      char *domname;
> -    libxl_sched_sedf scinfo;
> +    libxl_sched_sedf_domain scinfo;
>      int rc;
>  
>      if (domid < 0) {
> @@ -4116,7 +4116,7 @@ static int sched_domain_output(
>  
>  int main_sched_credit(int argc, char **argv)
>  {
> -    libxl_sched_credit scinfo;
> +    libxl_sched_credit_domain scinfo;
>      const char *dom = NULL;
>      const char *cpupool = NULL;
>      int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
> @@ -4198,7 +4198,7 @@ int main_sched_credit(int argc, char **a
>  
>  int main_sched_credit2(int argc, char **argv)
>  {
> -    libxl_sched_credit2 scinfo;
> +    libxl_sched_credit2_domain scinfo;
>      const char *dom = NULL;
>      const char *cpupool = NULL;
>      int weight = 256, opt_w = 0;
> @@ -4272,7 +4272,7 @@ int main_sched_credit2(int argc, char **
>  
>  int main_sched_sedf(int argc, char **argv)
>  {
> -    libxl_sched_sedf scinfo;
> +    libxl_sched_sedf_domain scinfo;
>      const char *dom = NULL;
>      const char *cpupool = NULL;
>      int period = 0, opt_p = 0;
> diff -r b5d446a34508 -r af02b1ea16da tools/ocaml/libs/xl/xenlight_stubs.c
> --- a/tools/ocaml/libs/xl/xenlight_stubs.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/ocaml/libs/xl/xenlight_stubs.c Wed Feb 22 16:08:28 2012 +0000
> @@ -473,7 +473,7 @@ value stub_xl_sched_credit_domain_get(va
>  {
> CAMLparam1(domid);
> CAMLlocal1(scinfo);
> - libxl_sched_credit c_scinfo;
> + libxl_sched_credit_domain c_scinfo;
> int ret;
> INIT_STRUCT();
>  
> @@ -483,18 +483,18 @@ value stub_xl_sched_credit_domain_get(va
> failwith_xl("sched_credit_domain_get", &lg);
> FREE_CTX();
>  
> - scinfo = Val_sched_credit(&gc, &lg, &c_scinfo);
> + scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
> CAMLreturn(scinfo);
>  }
>  
>  value stub_xl_sched_credit_domain_set(value domid, value scinfo)
>  {
> CAMLparam2(domid, scinfo);
> - libxl_sched_credit c_scinfo;
> + libxl_sched_credit_domain c_scinfo;
> int ret;
> INIT_STRUCT();
>  
> - sched_credit_val(&gc, &lg, &c_scinfo, scinfo);
> + sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
>  
> INIT_CTX();
> ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:21:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0VnD-0005wT-AJ; Thu, 23 Feb 2012 10:20:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0VnC-0005wA-4y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:20:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1329992446!17892975!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26439 invoked from network); 23 Feb 2012 10:20:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:20:47 -0000
Received: by werb14 with SMTP id b14so2329410wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 02:20:46 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.216.138.34 as permitted sender) client-ip=10.216.138.34; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.216.138.34 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.216.138.34])
	by 10.216.138.34 with SMTP id z34mr427629wei.27.1329992446734 (num_hops
	= 1); Thu, 23 Feb 2012 02:20:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=7SSsCjTny6090tqMgUUy9EUv1tiBDG3O5bZ3vL4KE7E=;
	b=nJmAqHHvUHOldnuTLZiHZ9FlsUDO85m7IYbPfQezhS9ivm0bcprYKS7NaIgkM9YKhL
	FJD/oAdhgcozf2Az3FGXh6X9MONJRZ6KhYDT/sHRUmP2n+6t8+Qs/zsWCz0XR6tJDVNF
	7t4pO23juGemb2iKgurmDIwT1a7z86hPcma0w=
Received: by 10.216.138.34 with SMTP id z34mr350258wei.27.1329992446629;
	Thu, 23 Feb 2012 02:20:46 -0800 (PST)
Received: from [192.168.1.3] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id fw5sm3401806wib.0.2012.02.23.02.20.44
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 02:20:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 23 Feb 2012 10:20:41 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB6BC379.39F6F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 6 of 9] libxl: Rename libxl_sched_* to
	include _domain
Thread-Index: AczyFMs9UquOsU5EXkOzg4+Jy/iCiA==
In-Reply-To: <af02b1ea16dabf3d96f2.1329927312@kodo2>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9] libxl: Rename libxl_sched_* to
 include _domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/02/2012 16:15, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> In preparation for introducing a schedule parameter-based structure,
> rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
> 
> No functional changes.
> 
> v2: Wrap long lines while I'm at it

I've applied up to and including this patch (since it's Acked by Ian). I
leave the remaining three patches to a libxl maintainer.

 -- Keir

> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/libxl.c Wed Feb 22 16:08:28 2012 +0000
> @@ -2975,7 +2975,8 @@ int libxl_get_sched_id(libxl_ctx *ctx)
>      return sched;
>  }
>  
> -int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
> libxl_sched_credit *scinfo)
> +int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_sched_credit_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit sdom;
>      int rc;
> @@ -2992,7 +2993,8 @@ int libxl_sched_credit_domain_get(libxl_
>      return 0;
>  }
>  
> -int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
> libxl_sched_credit *scinfo)
> +int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_sched_credit_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit sdom;
>      xc_domaininfo_t domaininfo;
> @@ -3033,7 +3035,7 @@ int libxl_sched_credit_domain_set(libxl_
>  }
>  
>  int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo)
> +                                   libxl_sched_credit2_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit2 sdom;
>      int rc;
> @@ -3051,7 +3053,7 @@ int libxl_sched_credit2_domain_get(libxl
>  }
>  
>  int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo)
> +                                   libxl_sched_credit2_domain *scinfo)
>  {
>      struct xen_domctl_sched_credit2 sdom;
>      xc_domaininfo_t domaininfo;
> @@ -3086,7 +3088,7 @@ int libxl_sched_credit2_domain_set(libxl
>  }
>  
>  int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo)
> +                                libxl_sched_sedf_domain *scinfo)
>  {
>      uint64_t period;
>      uint64_t slice;
> @@ -3112,7 +3114,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
>  }
>  
>  int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo)
> +                                libxl_sched_sedf_domain *scinfo)
>  {
>      xc_domaininfo_t domaininfo;
>      int rc;
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/libxl.h Wed Feb 22 16:08:28 2012 +0000
> @@ -588,17 +588,17 @@ int libxl_get_sched_id(libxl_ctx *ctx);
>  
>  
>  int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                  libxl_sched_credit *scinfo);
> +                                  libxl_sched_credit_domain *scinfo);
>  int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                  libxl_sched_credit *scinfo);
> +                                  libxl_sched_credit_domain *scinfo);
>  int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo);
> +                                   libxl_sched_credit2_domain *scinfo);
>  int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                   libxl_sched_credit2 *scinfo);
> +                                   libxl_sched_credit2_domain *scinfo);
>  int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo);
> +                                libxl_sched_sedf_domain *scinfo);
>  int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf *scinfo);
> +                                libxl_sched_sedf_domain *scinfo);
>  int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
>                         libxl_trigger trigger, uint32_t vcpuid);
>  int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/libxl_types.idl Wed Feb 22 16:08:28 2012 +0000
> @@ -390,16 +390,16 @@ libxl_cputopology = Struct("cputopology"
>      ("node", uint32),
>      ])
>  
> -libxl_sched_credit = Struct("sched_credit", [
> +libxl_sched_credit_domain = Struct("sched_credit_domain", [
>      ("weight", integer),
>      ("cap", integer),
>      ], dispose_fn=None)
>  
> -libxl_sched_credit2 = Struct("sched_credit2", [
> +libxl_sched_credit2_domain = Struct("sched_credit2_domain", [
>      ("weight", integer),
>      ], dispose_fn=None)
>  
> -libxl_sched_sedf = Struct("sched_sedf", [
> +libxl_sched_sedf_domain = Struct("sched_sedf_domain", [
>      ("period", integer),
>      ("slice", integer),
>      ("latency", integer),
> diff -r b5d446a34508 -r af02b1ea16da tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c Wed Feb 22 16:08:28 2012 +0000
> @@ -3913,7 +3913,7 @@ int main_sharing(int argc, char **argv)
>  }
>  
>  static int sched_credit_domain_get(
> -    int domid, libxl_sched_credit *scinfo)
> +    int domid, libxl_sched_credit_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3925,7 +3925,7 @@ static int sched_credit_domain_get(
>  }
>  
>  static int sched_credit_domain_set(
> -    int domid, libxl_sched_credit *scinfo)
> +    int domid, libxl_sched_credit_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3940,7 +3940,7 @@ static int sched_credit_domain_output(
>      int domid)
>  {
>      char *domname;
> -    libxl_sched_credit scinfo;
> +    libxl_sched_credit_domain scinfo;
>      int rc;
>  
>      if (domid < 0) {
> @@ -3961,7 +3961,7 @@ static int sched_credit_domain_output(
>  }
>  
>  static int sched_credit2_domain_get(
> -    int domid, libxl_sched_credit2 *scinfo)
> +    int domid, libxl_sched_credit2_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3973,7 +3973,7 @@ static int sched_credit2_domain_get(
>  }
>  
>  static int sched_credit2_domain_set(
> -    int domid, libxl_sched_credit2 *scinfo)
> +    int domid, libxl_sched_credit2_domain *scinfo)
>  {
>      int rc;
>  
> @@ -3988,7 +3988,7 @@ static int sched_credit2_domain_output(
>      int domid)
>  {
>      char *domname;
> -    libxl_sched_credit2 scinfo;
> +    libxl_sched_credit2_domain scinfo;
>      int rc;
>  
>      if (domid < 0) {
> @@ -4008,7 +4008,7 @@ static int sched_credit2_domain_output(
>  }
>  
>  static int sched_sedf_domain_get(
> -    int domid, libxl_sched_sedf *scinfo)
> +    int domid, libxl_sched_sedf_domain *scinfo)
>  {
>      int rc;
>  
> @@ -4020,7 +4020,7 @@ static int sched_sedf_domain_get(
>  }
>  
>  static int sched_sedf_domain_set(
> -    int domid, libxl_sched_sedf *scinfo)
> +    int domid, libxl_sched_sedf_domain *scinfo)
>  {
>      int rc;
>  
> @@ -4035,7 +4035,7 @@ static int sched_sedf_domain_output(
>      int domid)
>  {
>      char *domname;
> -    libxl_sched_sedf scinfo;
> +    libxl_sched_sedf_domain scinfo;
>      int rc;
>  
>      if (domid < 0) {
> @@ -4116,7 +4116,7 @@ static int sched_domain_output(
>  
>  int main_sched_credit(int argc, char **argv)
>  {
> -    libxl_sched_credit scinfo;
> +    libxl_sched_credit_domain scinfo;
>      const char *dom = NULL;
>      const char *cpupool = NULL;
>      int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
> @@ -4198,7 +4198,7 @@ int main_sched_credit(int argc, char **a
>  
>  int main_sched_credit2(int argc, char **argv)
>  {
> -    libxl_sched_credit2 scinfo;
> +    libxl_sched_credit2_domain scinfo;
>      const char *dom = NULL;
>      const char *cpupool = NULL;
>      int weight = 256, opt_w = 0;
> @@ -4272,7 +4272,7 @@ int main_sched_credit2(int argc, char **
>  
>  int main_sched_sedf(int argc, char **argv)
>  {
> -    libxl_sched_sedf scinfo;
> +    libxl_sched_sedf_domain scinfo;
>      const char *dom = NULL;
>      const char *cpupool = NULL;
>      int period = 0, opt_p = 0;
> diff -r b5d446a34508 -r af02b1ea16da tools/ocaml/libs/xl/xenlight_stubs.c
> --- a/tools/ocaml/libs/xl/xenlight_stubs.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/ocaml/libs/xl/xenlight_stubs.c Wed Feb 22 16:08:28 2012 +0000
> @@ -473,7 +473,7 @@ value stub_xl_sched_credit_domain_get(va
>  {
> CAMLparam1(domid);
> CAMLlocal1(scinfo);
> - libxl_sched_credit c_scinfo;
> + libxl_sched_credit_domain c_scinfo;
> int ret;
> INIT_STRUCT();
>  
> @@ -483,18 +483,18 @@ value stub_xl_sched_credit_domain_get(va
> failwith_xl("sched_credit_domain_get", &lg);
> FREE_CTX();
>  
> - scinfo = Val_sched_credit(&gc, &lg, &c_scinfo);
> + scinfo = Val_sched_credit_domain(&gc, &lg, &c_scinfo);
> CAMLreturn(scinfo);
>  }
>  
>  value stub_xl_sched_credit_domain_set(value domid, value scinfo)
>  {
> CAMLparam2(domid, scinfo);
> - libxl_sched_credit c_scinfo;
> + libxl_sched_credit_domain c_scinfo;
> int ret;
> INIT_STRUCT();
>  
> - sched_credit_val(&gc, &lg, &c_scinfo, scinfo);
> + sched_credit_domain_val(&gc, &lg, &c_scinfo, scinfo);
>  
> INIT_CTX();
> ret = libxl_sched_credit_domain_set(ctx, Int_val(domid), &c_scinfo);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:30:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0VwX-00069u-Jg; Thu, 23 Feb 2012 10:30:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0VwV-00069p-G6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:30:31 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329993025!15510138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2360 invoked from network); 23 Feb 2012 10:30:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:30:24 +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.213.0;
	Thu, 23 Feb 2012 10:30:25 +0000
Message-ID: <4F46157E.5000705@citrix.com>
Date: Thu, 23 Feb 2012 10:31:26 +0000
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: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>	
	<520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
	<1329992002.8557.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329992002.8557.58.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the
 option "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/02/12 10:13, Ian Campbell wrote:
> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>    
>> configuration file.
>> An example is given by:
>> bios_override="ovmf-x64"
>>      
> I'm not sure I would use the override suffix here -- that is generally
> for settings where we recommend that the user accepts the default. In
> this case though a user has perfectly valid reasons for selecting
> ovmf-{32,64} or seabios etc.
>
> Also please update docs/man/xl.cfg.pod.5 to document the new setting.
>    

It makes sense, thanks.

>> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
>> --- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
>> +++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
>> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>>   static const char *libxl__domain_bios(libxl__gc *gc,
>>                                   const libxl_domain_build_info *info)
>>   {
>> +    if (info->u.hvm.bios)
>> +       return info->u.hvm.bios;
>>       switch (info->device_model_version) {
>>       case 1: return "rombios";
>>       case 2: return "seabios";
>>      
> Should integrate this function into libxl__domain_build_info_setdefaults
> from my "libxl: improved handling for default values in API" series.
>
>    

I really wanted to do this type of integration in a separate step.

> Also it would be good to use that same infrastructure to enforce that
> qemu-xen-traditional can only use rombios and that seabios and ovmf-*
> are only valid with qemu-xen.
>
>    
>> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
>> --- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
>> +++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
>> @@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
>>
>>       ("u", KeyedUnion(None, libxl_domain_type, "type",
>>                   [("hvm", Struct(None, [("firmware", string),
>> +                                       ("bios", string),
>>      
> I think an Enumeration would be better here.
> libxl__domain_bios

I just found it quicker/cleaner to just store the string and pass it 
down, rather than translating to an Enumeration and then translate it 
back to a string into libxl__domain_bios(), don't you think?
However I'm open to do what you feel is better.

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 Feb 23 10:30:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0VwX-00069u-Jg; Thu, 23 Feb 2012 10:30:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0VwV-00069p-G6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:30:31 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329993025!15510138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2360 invoked from network); 23 Feb 2012 10:30:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10890919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:30:24 +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.213.0;
	Thu, 23 Feb 2012 10:30:25 +0000
Message-ID: <4F46157E.5000705@citrix.com>
Date: Thu, 23 Feb 2012 10:31:26 +0000
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: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>	
	<520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
	<1329992002.8557.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329992002.8557.58.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the
 option "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/02/12 10:13, Ian Campbell wrote:
> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>    
>> configuration file.
>> An example is given by:
>> bios_override="ovmf-x64"
>>      
> I'm not sure I would use the override suffix here -- that is generally
> for settings where we recommend that the user accepts the default. In
> this case though a user has perfectly valid reasons for selecting
> ovmf-{32,64} or seabios etc.
>
> Also please update docs/man/xl.cfg.pod.5 to document the new setting.
>    

It makes sense, thanks.

>> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
>> --- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
>> +++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
>> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>>   static const char *libxl__domain_bios(libxl__gc *gc,
>>                                   const libxl_domain_build_info *info)
>>   {
>> +    if (info->u.hvm.bios)
>> +       return info->u.hvm.bios;
>>       switch (info->device_model_version) {
>>       case 1: return "rombios";
>>       case 2: return "seabios";
>>      
> Should integrate this function into libxl__domain_build_info_setdefaults
> from my "libxl: improved handling for default values in API" series.
>
>    

I really wanted to do this type of integration in a separate step.

> Also it would be good to use that same infrastructure to enforce that
> qemu-xen-traditional can only use rombios and that seabios and ovmf-*
> are only valid with qemu-xen.
>
>    
>> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
>> --- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
>> +++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
>> @@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
>>
>>       ("u", KeyedUnion(None, libxl_domain_type, "type",
>>                   [("hvm", Struct(None, [("firmware", string),
>> +                                       ("bios", string),
>>      
> I think an Enumeration would be better here.
> libxl__domain_bios

I just found it quicker/cleaner to just store the string and pass it 
down, rather than translating to an Enumeration and then translate it 
back to a string into libxl__domain_bios(), don't you think?
However I'm open to do what you feel is better.

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 Feb 23 10:34:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Vzp-0006Gx-7h; Thu, 23 Feb 2012 10:33:57 +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 1S0Vzn-0006Gs-4l
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 10:33:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329993192!53646280!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20017 invoked from network); 23 Feb 2012 10:33:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 10:33:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0Vzj-0006ld-8S; Thu, 23 Feb 2012 10:33:51 +0000
Date: Thu, 23 Feb 2012 10:33:51 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120223103351.GB25694@ocelot.phlegethon.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
	<4F3E95610200007800073B97@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3E95610200007800073B97@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
	pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:58 +0000 on 17 Feb (1329497937), Jan Beulich wrote:
> >>> On 17.02.12 at 17:23, Tim Deegan <tim@xen.org> wrote:
> > At 15:50 +0000 on 17 Feb (1329493838), Jan Beulich wrote:
> >> The problem appears to be that the or-ing in of PFEC_reserved_bit
> >> happens without consideration of PFEC_present. If you can confirm
> >> I'm not mis-interpreting things, fixing this should be relatively
> >> strait forward (though the question would be whether it should be
> >> guest_walk_tables() or its callers that should be fixed).
> > 
> > We should fix it in guest_walk_tables, since AFAICS it's possible for
> > PFEC_reserved_bit to be set based on a bad higher-level entry even if a
> > lower-level one has _PAGE_PRESENT clear.
> > 
> > Something like the attached (compile-tested only) patch? 
> 
> That was really fast, thanks!
> 
> Yes, that looks like it should do it. We'll want to give it a try early
> next week.

I've applied it, since it seemed not to break anything and I'll be away
from my test boxes for a while.  Let me know of you're still seeing any
problems. 

Cheers,

Tim.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:34:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Vzp-0006Gx-7h; Thu, 23 Feb 2012 10:33:57 +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 1S0Vzn-0006Gs-4l
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 10:33:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1329993192!53646280!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20017 invoked from network); 23 Feb 2012 10:33:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 10:33:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0Vzj-0006ld-8S; Thu, 23 Feb 2012 10:33:51 +0000
Date: Thu, 23 Feb 2012 10:33:51 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120223103351.GB25694@ocelot.phlegethon.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
	<4F3E95610200007800073B97@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F3E95610200007800073B97@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
	pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:58 +0000 on 17 Feb (1329497937), Jan Beulich wrote:
> >>> On 17.02.12 at 17:23, Tim Deegan <tim@xen.org> wrote:
> > At 15:50 +0000 on 17 Feb (1329493838), Jan Beulich wrote:
> >> The problem appears to be that the or-ing in of PFEC_reserved_bit
> >> happens without consideration of PFEC_present. If you can confirm
> >> I'm not mis-interpreting things, fixing this should be relatively
> >> strait forward (though the question would be whether it should be
> >> guest_walk_tables() or its callers that should be fixed).
> > 
> > We should fix it in guest_walk_tables, since AFAICS it's possible for
> > PFEC_reserved_bit to be set based on a bad higher-level entry even if a
> > lower-level one has _PAGE_PRESENT clear.
> > 
> > Something like the attached (compile-tested only) patch? 
> 
> That was really fast, thanks!
> 
> Yes, that looks like it should do it. We'll want to give it a try early
> next week.

I've applied it, since it seemed not to break anything and I'll be away
from my test boxes for a while.  Let me know of you're still seeing any
problems. 

Cheers,

Tim.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:43:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0W8M-0006Ux-Cx; Thu, 23 Feb 2012 10:42:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0W8L-0006Up-1i
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:42:45 +0000
Received: from [85.158.139.83:46035] by server-7.bemta-5.messagelabs.com id
	B2/30-16195-428164F4; Thu, 23 Feb 2012 10:42:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329993763!15443085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28243 invoked from network); 23 Feb 2012 10:42:43 -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;
	23 Feb 2012 10:42:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891248"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:42:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:42:43 +0000
Message-ID: <1329993761.8557.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Thu, 23 Feb 2012 10:42:41 +0000
In-Reply-To: <1329826841.2196.85.camel@elijah>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 12:20 +0000, George Dunlap wrote:
> On Tue, 2012-02-21 at 09:59 +0000, Ian Campbell wrote:

> > So why not make the "on" case the same as your "delay" case and do away
> > with the distinction? If advanced users really want what you describe as
> > "on" then they can set the delay to 0.
> 
> The only thing with this is that then the command will by default pause
> until we reach the target, which may be several seconds.  We should make
> sure to print a message saying that's what we're doing, so users don't
> get confused.

I'm not sure this isn't actually a feature...

$ xl mem-set dom 128
xl: setting domain `dom' memory target to 128M
xl: waiting for domain to reach target: 60... 55... 50... (etc) 5... timeout!
xl: domain `dom' did not reach target (reached 156M)
xl: enabling paging, setting domain footprint to 128M.

> > > xl mem-balloon-set domain M
> > >  Set balloon target to M
> > > xl mem-paging-set domain M
> > >  Set paging target to M
> > 
> > How do these interact with mem-set. Especially in the delay case?
> 
> My idea was that "xl mem-paging-set domain M" would basically be
> equivalent to xenstore-write /local/[whatever]/[whatever]: that is, no
> attempt at synchronization.  If I do "xl mem-set" with a delay in one
> window, then do "xl mem-paging-set" in another window, the first one
> will take effect immediately, then the other one will take effect after
> the delay.  If that's not what you want, either Ctrl-C the first one or
> wait for it to finish. :-)
> 
> > e.g. would mem-paging-set disable the after delay behaviour of mem-set?
> > Should we have "mem-paging-set domain auto" to turn that back on?
> 
> That's one of the reasons I conceived having mem-balloon-set: if you
> want to switch to full-manual, you just switch to using full-manual
> commands.  If/when you have stuff in a state that the simpler command
> will work again, you can switch back.

What if you switch back without making sure you are in such a state? I
think switching between the two is where the potential for unexpected
behaviour is most likely.

> 
> > How about the following? I've tried to include the "user facing"
> > description as well as the actual implementation. I think the "user
> > facing" portion is actually where we disagree but I also suspect that we
> > may not actually disagree -- it's just that we are talking in terms of
> > implementation so we don't see that the user facing interface is the
> > same in what we are each thinking of ;-)
> > 
> > maxmem=X			# maximum RAM the domain can ever see
> > memory=M			# current amount of RAM seen by the domain
> > paging=[off|on]			# allow the amount of memory a guest 
> > 				# thinks it has to differ from the
> > 				# amount actually available to it (its
> > 				# "footprint")
> > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> > 				# "footprint" for guests which do not
> > 				# voluntarily obey changes to memory=M 
> > pagingdelay=60			# amount of time to give a guest to 
> > 				# voluntarily comply before enforcing a 
> > 				# footprint
> > 
> > xl mem-set domain M
> >         Sets the amount of RAM which the guest believes it has available
> >         to M. The guest should arrange to use only that much RAM and
> >         return the rest to the hypervisor (e.g. by using a balloon
> >         driver). If the guest does not do so then the host may use
> >         technical means to enforce the guest's footprint of M. The guest
> >         may suffer a performance penalty for this enforcement.
> > 
> > 	paging off:	set balloon target to M.
> > 	paging on: 	set balloon target to M.
> > 			if pagingauto:
> > 				wait delay IFF new target < old
> > 				set paging target to M
> > 				support -t <delay> to override default?
> > 
> > xl mem-paging-set domain N
> >         Overrides the amount of RAM which the guest actually has
> >         available (its "footprint") to N. The host will use technical
> >         means to continue to provide the illusion to the guest that it
> >         has memory=M (as adjusted by mem-set). There may be a
> >         performance penalty for this.
> >         
> > 	paging off:	error
> > 	paging on:	set paging target
> > 			set pagingauto=off
> > 
> > xl mem-paging-set domain auto
> >         Automatically manage paging. Request that the guest uses
> >         memory=M (current value of memory, as adjusted by mem-set)
> >         enforced when the guest is uncooperative (as described in
> >         "mem-set")
> >         
> > 	paging off:	error
> > 	paging on:	set paging target to M
> > 			set pagingauto=on
> > 
> > No need for a separate balloon-set since that == mem-set with
> > pagingauto=off.
> > 
> > Perhaps a separate "mem-paging-set domain manual" would be handy to
> > enable that mode without having to remember M so you can use it as N 
> 
> I'd be OK with this.

Great.

I like that you have to explicitly ask for the safety wheels to come off
and explicitly put them back on again. It avoids the corner cases I
alluded to above (at least I hope so).

> 
> > We could consider making "mem-paging-set domain N" fail with an error
> > unless you previously set manual, to prevent users accidentally
> > disabling the recommended automatic behaviour e.g. by typing
> > mem-paging-set when they mean mem-set.
> > 
> > I liked Andres' suggestions of footprint as a term here BTW so I would
> > prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
> > not 100% on that). If we don't have balloon-set then avoiding the name
> > paging seems like a good idea too. Other possible names might be
> > "mem-override-set" or something.
> 
> Well for one, "footprint" to me would imply "I don't care how you got
> there, just make it take this much memory".  So saying in the docs that
> "xl mem-set" would attempt to set the memory footprint would be OK.  But
> I definitely don't think we should use "footprint" to mean "paging
> target".  Even apart from the fact that the name to me means something
> else, the config options are called "paging".  In any case, if it's
> supposed to be an "advanced feature", it should be OK to expect the user
> to know (or find out) what paging means.

I see what you mean, yes.

Without wishing to put words in Andres' mouth I expect that he intended
"footprint" to cover other technical means than paging too --
specifically I expect he was thinking of page sharing. (I suppose it
also covers PoD to some extent too, although that is something of a
special case)

While I don't expect there will be a knob to control number of shared
pages (either you can share some pages or not, the settings would be
more about how aggressively you search for sharable pages) it might be
useful to consider the interaction between paging and sharing, I expect
that most sharing configurations would want to have paging on at the
same time (for safety). It seems valid to me to want to say "make the
guest use this amount of actual RAM" and to achieve that by sharing what
you can and then paging the rest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:43:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0W8M-0006Ux-Cx; Thu, 23 Feb 2012 10:42:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0W8L-0006Up-1i
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:42:45 +0000
Received: from [85.158.139.83:46035] by server-7.bemta-5.messagelabs.com id
	B2/30-16195-428164F4; Thu, 23 Feb 2012 10:42:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1329993763!15443085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28243 invoked from network); 23 Feb 2012 10:42:43 -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;
	23 Feb 2012 10:42:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891248"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:42:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:42:43 +0000
Message-ID: <1329993761.8557.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Thu, 23 Feb 2012 10:42:41 +0000
In-Reply-To: <1329826841.2196.85.camel@elijah>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-21 at 12:20 +0000, George Dunlap wrote:
> On Tue, 2012-02-21 at 09:59 +0000, Ian Campbell wrote:

> > So why not make the "on" case the same as your "delay" case and do away
> > with the distinction? If advanced users really want what you describe as
> > "on" then they can set the delay to 0.
> 
> The only thing with this is that then the command will by default pause
> until we reach the target, which may be several seconds.  We should make
> sure to print a message saying that's what we're doing, so users don't
> get confused.

I'm not sure this isn't actually a feature...

$ xl mem-set dom 128
xl: setting domain `dom' memory target to 128M
xl: waiting for domain to reach target: 60... 55... 50... (etc) 5... timeout!
xl: domain `dom' did not reach target (reached 156M)
xl: enabling paging, setting domain footprint to 128M.

> > > xl mem-balloon-set domain M
> > >  Set balloon target to M
> > > xl mem-paging-set domain M
> > >  Set paging target to M
> > 
> > How do these interact with mem-set. Especially in the delay case?
> 
> My idea was that "xl mem-paging-set domain M" would basically be
> equivalent to xenstore-write /local/[whatever]/[whatever]: that is, no
> attempt at synchronization.  If I do "xl mem-set" with a delay in one
> window, then do "xl mem-paging-set" in another window, the first one
> will take effect immediately, then the other one will take effect after
> the delay.  If that's not what you want, either Ctrl-C the first one or
> wait for it to finish. :-)
> 
> > e.g. would mem-paging-set disable the after delay behaviour of mem-set?
> > Should we have "mem-paging-set domain auto" to turn that back on?
> 
> That's one of the reasons I conceived having mem-balloon-set: if you
> want to switch to full-manual, you just switch to using full-manual
> commands.  If/when you have stuff in a state that the simpler command
> will work again, you can switch back.

What if you switch back without making sure you are in such a state? I
think switching between the two is where the potential for unexpected
behaviour is most likely.

> 
> > How about the following? I've tried to include the "user facing"
> > description as well as the actual implementation. I think the "user
> > facing" portion is actually where we disagree but I also suspect that we
> > may not actually disagree -- it's just that we are talking in terms of
> > implementation so we don't see that the user facing interface is the
> > same in what we are each thinking of ;-)
> > 
> > maxmem=X			# maximum RAM the domain can ever see
> > memory=M			# current amount of RAM seen by the domain
> > paging=[off|on]			# allow the amount of memory a guest 
> > 				# thinks it has to differ from the
> > 				# amount actually available to it (its
> > 				# "footprint")
> > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> > 				# "footprint" for guests which do not
> > 				# voluntarily obey changes to memory=M 
> > pagingdelay=60			# amount of time to give a guest to 
> > 				# voluntarily comply before enforcing a 
> > 				# footprint
> > 
> > xl mem-set domain M
> >         Sets the amount of RAM which the guest believes it has available
> >         to M. The guest should arrange to use only that much RAM and
> >         return the rest to the hypervisor (e.g. by using a balloon
> >         driver). If the guest does not do so then the host may use
> >         technical means to enforce the guest's footprint of M. The guest
> >         may suffer a performance penalty for this enforcement.
> > 
> > 	paging off:	set balloon target to M.
> > 	paging on: 	set balloon target to M.
> > 			if pagingauto:
> > 				wait delay IFF new target < old
> > 				set paging target to M
> > 				support -t <delay> to override default?
> > 
> > xl mem-paging-set domain N
> >         Overrides the amount of RAM which the guest actually has
> >         available (its "footprint") to N. The host will use technical
> >         means to continue to provide the illusion to the guest that it
> >         has memory=M (as adjusted by mem-set). There may be a
> >         performance penalty for this.
> >         
> > 	paging off:	error
> > 	paging on:	set paging target
> > 			set pagingauto=off
> > 
> > xl mem-paging-set domain auto
> >         Automatically manage paging. Request that the guest uses
> >         memory=M (current value of memory, as adjusted by mem-set)
> >         enforced when the guest is uncooperative (as described in
> >         "mem-set")
> >         
> > 	paging off:	error
> > 	paging on:	set paging target to M
> > 			set pagingauto=on
> > 
> > No need for a separate balloon-set since that == mem-set with
> > pagingauto=off.
> > 
> > Perhaps a separate "mem-paging-set domain manual" would be handy to
> > enable that mode without having to remember M so you can use it as N 
> 
> I'd be OK with this.

Great.

I like that you have to explicitly ask for the safety wheels to come off
and explicitly put them back on again. It avoids the corner cases I
alluded to above (at least I hope so).

> 
> > We could consider making "mem-paging-set domain N" fail with an error
> > unless you previously set manual, to prevent users accidentally
> > disabling the recommended automatic behaviour e.g. by typing
> > mem-paging-set when they mean mem-set.
> > 
> > I liked Andres' suggestions of footprint as a term here BTW so I would
> > prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
> > not 100% on that). If we don't have balloon-set then avoiding the name
> > paging seems like a good idea too. Other possible names might be
> > "mem-override-set" or something.
> 
> Well for one, "footprint" to me would imply "I don't care how you got
> there, just make it take this much memory".  So saying in the docs that
> "xl mem-set" would attempt to set the memory footprint would be OK.  But
> I definitely don't think we should use "footprint" to mean "paging
> target".  Even apart from the fact that the name to me means something
> else, the config options are called "paging".  In any case, if it's
> supposed to be an "advanced feature", it should be OK to expect the user
> to know (or find out) what paging means.

I see what you mean, yes.

Without wishing to put words in Andres' mouth I expect that he intended
"footprint" to cover other technical means than paging too --
specifically I expect he was thinking of page sharing. (I suppose it
also covers PoD to some extent too, although that is something of a
special case)

While I don't expect there will be a knob to control number of shared
pages (either you can share some pages or not, the settings would be
more about how aggressively you search for sharable pages) it might be
useful to consider the interaction between paging and sharing, I expect
that most sharing configurations would want to have paging on at the
same time (for safety). It seems valid to me to want to say "make the
guest use this amount of actual RAM" and to achieve that by sharing what
you can and then paging the rest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0W8Y-0006Vd-Pe; Thu, 23 Feb 2012 10:42:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0W8W-0006VI-N8
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:42:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329993770!13688777!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23032 invoked from network); 23 Feb 2012 10:42:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 10:42:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0W8O-0006nn-N9; Thu, 23 Feb 2012 10:42:48 +0000
Date: Thu, 23 Feb 2012 10:42:48 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223104248.GC25694@ocelot.phlegethon.org>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
	<1329837682.3990.114.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329837682.3990.114.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 guess a third option might be to have a facility to load extra
> > modules/files into the new domain at start time and specify their
> > gpa's in xenstore. They could then be discarded after the initial
> > domain setup is complete.
> 
> That might work. What do others around here think?

That seems better than passing it through the hypervisor. :)  If the
builder is already loading them into RAM we could just stick a linked
list at a know address rather than go through Xenstore - at least for
things that aren't needed by anything except hvmloader.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0W8Y-0006Vd-Pe; Thu, 23 Feb 2012 10:42:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0W8W-0006VI-N8
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:42:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329993770!13688777!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23032 invoked from network); 23 Feb 2012 10:42:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 10:42:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0W8O-0006nn-N9; Thu, 23 Feb 2012 10:42:48 +0000
Date: Thu, 23 Feb 2012 10:42:48 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223104248.GC25694@ocelot.phlegethon.org>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
	<1329837682.3990.114.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329837682.3990.114.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 guess a third option might be to have a facility to load extra
> > modules/files into the new domain at start time and specify their
> > gpa's in xenstore. They could then be discarded after the initial
> > domain setup is complete.
> 
> That might work. What do others around here think?

That seems better than passing it through the hypervisor. :)  If the
builder is already loading them into RAM we could just stick a linked
list at a know address rather than go through Xenstore - at least for
things that aren't needed by anything except hvmloader.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0W9y-0006ez-FA; Thu, 23 Feb 2012 10:44:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0W9x-0006dF-Dm
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:44:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329993859!16074874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32522 invoked from network); 23 Feb 2012 10:44:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:44:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:44:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:44:19 +0000
Message-ID: <1329993857.8557.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:44:17 +0000
In-Reply-To: <4F461276.1030108@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:18 +0000, Attilio Rao wrote:
> On 23/02/12 10:07, Ian Campbell wrote:
> > On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >    
> >> A way to integrate OVMF build directly into XEN has still be discussed
> >> on the mailing list appropriately.
> >>      
> > AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> > external dependency would be for us to mirror it on xenbits as a
> > convenience to our users, who don't need to get stuff from multiple
> > places, and as a courtesy to our upstreams, so our users don't consume
> > their resources.
> >
> > I don't much fancy setting the necessary webdav or whatever stuff on
> > xenbits and integrating SVN support into our build system though. What
> > do people think about using git-svn to manage our mirror in git instead?
> > Or better: perhaps OVMF have an official git or hg mirror?
> >
> > Anyone have any thoughts/opinions/better ideas etc?
> >
> >    
> >> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
> >> --- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
> >> +++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
> >> @@ -35,6 +35,8 @@ struct bios_config {
> >>
> >>   extern struct bios_config rombios_config;
> >>   extern struct bios_config seabios_config;
> >> +extern struct bios_config ovmf32_config;
> >> +extern struct bios_config ovmf64_config;
> >>      
> > Can you confirm that you need an OVMF which matches the OS bit-width you
> > are installing. i..e that there is no support for booting a 32 bit EFI
> > OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >
> >    
> 
> I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
> possibly work.
> You are suggesting if this is the case we should just ship the 64-bit 
> emulation?

That would be preferable if possible. I thought this didn't work though
(but I may have misunderstood or misremembered something).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0W9y-0006ez-FA; Thu, 23 Feb 2012 10:44:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0W9x-0006dF-Dm
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:44:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1329993859!16074874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32522 invoked from network); 23 Feb 2012 10:44:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:44:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:44:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:44:19 +0000
Message-ID: <1329993857.8557.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:44:17 +0000
In-Reply-To: <4F461276.1030108@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:18 +0000, Attilio Rao wrote:
> On 23/02/12 10:07, Ian Campbell wrote:
> > On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >    
> >> A way to integrate OVMF build directly into XEN has still be discussed
> >> on the mailing list appropriately.
> >>      
> > AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> > external dependency would be for us to mirror it on xenbits as a
> > convenience to our users, who don't need to get stuff from multiple
> > places, and as a courtesy to our upstreams, so our users don't consume
> > their resources.
> >
> > I don't much fancy setting the necessary webdav or whatever stuff on
> > xenbits and integrating SVN support into our build system though. What
> > do people think about using git-svn to manage our mirror in git instead?
> > Or better: perhaps OVMF have an official git or hg mirror?
> >
> > Anyone have any thoughts/opinions/better ideas etc?
> >
> >    
> >> diff -r a88ba599add1 -r 032fea10f8d1 tools/firmware/hvmloader/config.h
> >> --- a/tools/firmware/hvmloader/config.h	Tue Feb 21 17:45:59 2012 +0000
> >> +++ b/tools/firmware/hvmloader/config.h	Wed Feb 22 18:54:03 2012 +0000
> >> @@ -35,6 +35,8 @@ struct bios_config {
> >>
> >>   extern struct bios_config rombios_config;
> >>   extern struct bios_config seabios_config;
> >> +extern struct bios_config ovmf32_config;
> >> +extern struct bios_config ovmf64_config;
> >>      
> > Can you confirm that you need an OVMF which matches the OS bit-width you
> > are installing. i..e that there is no support for booting a 32 bit EFI
> > OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >
> >    
> 
> I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
> possibly work.
> You are suggesting if this is the case we should just ship the 64-bit 
> emulation?

That would be preferable if possible. I thought this didn't work though
(but I may have misunderstood or misremembered something).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0WAy-0006m9-W1; Thu, 23 Feb 2012 10:45:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0WAx-0006la-Gk
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:45:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329993921!13689432!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3458 invoked from network); 23 Feb 2012 10:45:21 -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; 23 Feb 2012 10:45:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0WAq-0006ob-PK; Thu, 23 Feb 2012 10:45:20 +0000
Date: Thu, 23 Feb 2012 10:45:20 +0000
From: Tim Deegan <tim@xen.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120223104520.GD25694@ocelot.phlegethon.org>
References: <1329922812.5468.55.camel@leeds.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329922812.5468.55.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add gtags target for xen/Makefile. Also
	update .hgignore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:00 +0000 on 22 Feb (1329922812), Wei Liu wrote:
> +.PHONY: _gtags
> +_gtags:
> +	set -e; rm -f GTAGS GSYMS GPATH GRTAGS
> +	$(all_sources) > gtags.files
> +	gtags -f gtags.files
> +

Minor nit: the gtags manpage suggests that '$(all_sources) | gtags -f -'
would work, and save us from tracking another file.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10: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 1S0WAy-0006m9-W1; Thu, 23 Feb 2012 10:45:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0WAx-0006la-Gk
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:45:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1329993921!13689432!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3458 invoked from network); 23 Feb 2012 10:45:21 -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; 23 Feb 2012 10:45:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0WAq-0006ob-PK; Thu, 23 Feb 2012 10:45:20 +0000
Date: Thu, 23 Feb 2012 10:45:20 +0000
From: Tim Deegan <tim@xen.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120223104520.GD25694@ocelot.phlegethon.org>
References: <1329922812.5468.55.camel@leeds.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329922812.5468.55.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add gtags target for xen/Makefile. Also
	update .hgignore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:00 +0000 on 22 Feb (1329922812), Wei Liu wrote:
> +.PHONY: _gtags
> +_gtags:
> +	set -e; rm -f GTAGS GSYMS GPATH GRTAGS
> +	$(all_sources) > gtags.files
> +	gtags -f gtags.files
> +

Minor nit: the gtags manpage suggests that '$(all_sources) | gtags -f -'
would work, and save us from tracking another file.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 10:46:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0WCF-0006xo-EU; Thu, 23 Feb 2012 10:46:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0WCD-0006x1-Sq
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:46:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329993999!6449188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9304 invoked from network); 23 Feb 2012 10:46:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:46:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:46:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:46:40 +0000
Message-ID: <1329993998.8557.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:46:38 +0000
In-Reply-To: <4F46157E.5000705@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
	<1329992002.8557.58.camel@zakaz.uk.xensource.com>
	<4F46157E.5000705@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the
 option "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:31 +0000, Attilio Rao wrote:
> On 23/02/12 10:13, Ian Campbell wrote:
> > On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >    
> >> configuration file.
> >> An example is given by:
> >> bios_override="ovmf-x64"
> >>      
> > I'm not sure I would use the override suffix here -- that is generally
> > for settings where we recommend that the user accepts the default. In
> > this case though a user has perfectly valid reasons for selecting
> > ovmf-{32,64} or seabios etc.
> >
> > Also please update docs/man/xl.cfg.pod.5 to document the new setting.
> >    
> 
> It makes sense, thanks.
> 
> >> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
> >> --- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
> >> +++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
> >> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
> >>   static const char *libxl__domain_bios(libxl__gc *gc,
> >>                                   const libxl_domain_build_info *info)
> >>   {
> >> +    if (info->u.hvm.bios)
> >> +       return info->u.hvm.bios;
> >>       switch (info->device_model_version) {
> >>       case 1: return "rombios";
> >>       case 2: return "seabios";
> >>      
> > Should integrate this function into libxl__domain_build_info_setdefaults
> > from my "libxl: improved handling for default values in API" series.
> >
> >    
> 
> I really wanted to do this type of integration in a separate step.

Sure, either you or I can take a look after both series are in.

> > Also it would be good to use that same infrastructure to enforce that
> > qemu-xen-traditional can only use rombios and that seabios and ovmf-*
> > are only valid with qemu-xen.
> >
> >    
> >> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
> >> --- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
> >> +++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
> >> @@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
> >>
> >>       ("u", KeyedUnion(None, libxl_domain_type, "type",
> >>                   [("hvm", Struct(None, [("firmware", string),
> >> +                                       ("bios", string),
> >>      
> > I think an Enumeration would be better here.
> > libxl__domain_bios
> 
> I just found it quicker/cleaner to just store the string and pass it 
> down, rather than translating to an Enumeration and then translate it 
> back to a string into libxl__domain_bios(), don't you think?

The IDL provides helpers for doing this (..._{to,from}_string). You
would end up just calling that instead of libxl__domain_bios(). i.e.
libxl__domain_bios goes away because the logic for setting
info->u.hvm.bios (in the future in setdefaults) ensures it is always a
specific valid value.

> However I'm open to do what you feel is better.
> 
> 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 Feb 23 10:46:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 10:46:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0WCF-0006xo-EU; Thu, 23 Feb 2012 10:46:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0WCD-0006x1-Sq
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 10:46:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1329993999!6449188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9304 invoked from network); 23 Feb 2012 10:46:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 10:46:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 10:46:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 10:46:40 +0000
Message-ID: <1329993998.8557.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Thu, 23 Feb 2012 10:46:38 +0000
In-Reply-To: <4F46157E.5000705@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<520ba1527b7ad2c73c41.1329938234@dhcp-3-145.uk.xensource.com>
	<1329992002.8557.58.camel@zakaz.uk.xensource.com>
	<4F46157E.5000705@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add the ability to specify the
 option "bios_override" in the guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:31 +0000, Attilio Rao wrote:
> On 23/02/12 10:13, Ian Campbell wrote:
> > On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >    
> >> configuration file.
> >> An example is given by:
> >> bios_override="ovmf-x64"
> >>      
> > I'm not sure I would use the override suffix here -- that is generally
> > for settings where we recommend that the user accepts the default. In
> > this case though a user has perfectly valid reasons for selecting
> > ovmf-{32,64} or seabios etc.
> >
> > Also please update docs/man/xl.cfg.pod.5 to document the new setting.
> >    
> 
> It makes sense, thanks.
> 
> >> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_dm.c
> >> --- a/tools/libxl/libxl_dm.c	Wed Feb 22 18:54:03 2012 +0000
> >> +++ b/tools/libxl/libxl_dm.c	Wed Feb 22 18:56:22 2012 +0000
> >> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
> >>   static const char *libxl__domain_bios(libxl__gc *gc,
> >>                                   const libxl_domain_build_info *info)
> >>   {
> >> +    if (info->u.hvm.bios)
> >> +       return info->u.hvm.bios;
> >>       switch (info->device_model_version) {
> >>       case 1: return "rombios";
> >>       case 2: return "seabios";
> >>      
> > Should integrate this function into libxl__domain_build_info_setdefaults
> > from my "libxl: improved handling for default values in API" series.
> >
> >    
> 
> I really wanted to do this type of integration in a separate step.

Sure, either you or I can take a look after both series are in.

> > Also it would be good to use that same infrastructure to enforce that
> > qemu-xen-traditional can only use rombios and that seabios and ovmf-*
> > are only valid with qemu-xen.
> >
> >    
> >> diff -r 032fea10f8d1 -r 520ba1527b7a tools/libxl/libxl_types.idl
> >> --- a/tools/libxl/libxl_types.idl	Wed Feb 22 18:54:03 2012 +0000
> >> +++ b/tools/libxl/libxl_types.idl	Wed Feb 22 18:56:22 2012 +0000
> >> @@ -228,6 +228,7 @@ libxl_domain_build_info = Struct("domain
> >>
> >>       ("u", KeyedUnion(None, libxl_domain_type, "type",
> >>                   [("hvm", Struct(None, [("firmware", string),
> >> +                                       ("bios", string),
> >>      
> > I think an Enumeration would be better here.
> > libxl__domain_bios
> 
> I just found it quicker/cleaner to just store the string and pass it 
> down, rather than translating to an Enumeration and then translate it 
> back to a string into libxl__domain_bios(), don't you think?

The IDL provides helpers for doing this (..._{to,from}_string). You
would end up just calling that instead of libxl__domain_bios(). i.e.
libxl__domain_bios goes away because the logic for setting
info->u.hvm.bios (in the future in setdefaults) ensures it is always a
specific valid value.

> However I'm open to do what you feel is better.
> 
> 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 Feb 23 11:02:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11:02:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0WQh-0007hu-5j; Thu, 23 Feb 2012 11:01:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0WQg-0007hk-0U
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 11:01:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329994895!15528058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20198 invoked from network); 23 Feb 2012 11:01:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 11:01:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:01:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:01:35 +0000
Message-ID: <1329994893.8557.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 11:01:33 +0000
In-Reply-To: <1329987122.8557.16.camel@zakaz.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>	<1329986720.8557.10.camel@zakaz.uk.xensource.com>
	<1329987122.8557.16.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 08:52 +0000, Ian Campbell wrote:
> On Thu, 2012-02-23 at 08:45 +0000, Ian Campbell wrote:
> > On Wed, 2012-02-22 at 21:40 +0000, Jim Fehlig wrote:
> > > Ian Jackson wrote:
> > > > Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > > >
> > > >> Ian Jackson wrote:
> > > >>
> > > >>> Users of libxl should not be using libxc directly and therefore should
> > > >>> not be including xenctrl.h.
> > > >>>
> > > > ...
> > > >
> > > >> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it?
> > > >> it seems that add __XEN_TOOLS_ to libvirt code is not good.
> > > >>
> > > >
> > > > Can you tell us the error message you get ?  I think the problem is
> > > > probably that libvirt is trying to use libxc directly.
> > > >
> > >
> > > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > > is that libxl.h includes <xen/sysctl.h>, which has this
> > >
> > > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > > #error "sysctl operations are intended for use by node control tools only"
> > > #endif
> > >
> > > Without the defines, Bamvor is hitting the #error directive.
> > 
> > I thought we'd discussed and resolved this ages ago but I guess we only
> > discussed it...
> > 
> > How about the following:
> 
> I also have the following,

One or both of which break the bindings build...

I'll resend as precursor to my resend of the "better defaults handling".
Simply because there are some textual conflicts between the two.

I'd still be happy to have Acks for the libxl side though (the bindings
changes will be obvious I expect)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:02:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11:02:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0WQh-0007hu-5j; Thu, 23 Feb 2012 11:01:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0WQg-0007hk-0U
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 11:01:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1329994895!15528058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20198 invoked from network); 23 Feb 2012 11:01:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 11:01:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10891886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:01:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:01:35 +0000
Message-ID: <1329994893.8557.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Thu, 23 Feb 2012 11:01:33 +0000
In-Reply-To: <1329987122.8557.16.camel@zakaz.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>	<1329986720.8557.10.camel@zakaz.uk.xensource.com>
	<1329987122.8557.16.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 08:52 +0000, Ian Campbell wrote:
> On Thu, 2012-02-23 at 08:45 +0000, Ian Campbell wrote:
> > On Wed, 2012-02-22 at 21:40 +0000, Jim Fehlig wrote:
> > > Ian Jackson wrote:
> > > > Bamvor Jian Zhang writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > > >
> > > >> Ian Jackson wrote:
> > > >>
> > > >>> Users of libxl should not be using libxc directly and therefore should
> > > >>> not be including xenctrl.h.
> > > >>>
> > > > ...
> > > >
> > > >> but after your commit "23174:751c6dcec0d4"(remove xenctrl.h from libxl.h), the aplication(like libvirt) compile fail. How do i deal with it?
> > > >> it seems that add __XEN_TOOLS_ to libvirt code is not good.
> > > >>
> > > >
> > > > Can you tell us the error message you get ?  I think the problem is
> > > > probably that libvirt is trying to use libxc directly.
> > > >
> > >
> > > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > > is that libxl.h includes <xen/sysctl.h>, which has this
> > >
> > > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > > #error "sysctl operations are intended for use by node control tools only"
> > > #endif
> > >
> > > Without the defines, Bamvor is hitting the #error directive.
> > 
> > I thought we'd discussed and resolved this ages ago but I guess we only
> > discussed it...
> > 
> > How about the following:
> 
> I also have the following,

One or both of which break the bindings build...

I'll resend as precursor to my resend of the "better defaults handling".
Simply because there are some textual conflicts between the two.

I'd still be happy to have Acks for the libxl side though (the bindings
changes will be obvious I expect)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:07:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0WVi-0007uu-T4; Thu, 23 Feb 2012 11:06:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1S0WVh-0007uj-Jr; Thu, 23 Feb 2012 11:06:53 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329995184!54122170!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28597 invoked from network); 23 Feb 2012 11:06:24 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-11.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 11:06:24 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id AEE2CD347BD;
	Thu, 23 Feb 2012 12:06:48 +0100 (CET)
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 Nr2eMy4Mk-2W; Thu, 23 Feb 2012 12:06:46 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 84FD8D34180;
	Thu, 23 Feb 2012 12:06:46 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-users@lists.xen.org
Date: Thu, 23 Feb 2012 12:06:44 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20120222173908.1753ead7c2b35a7d15c5b99498690bcc.389610f355.wbe@email11.secureserver.net>
In-Reply-To: <20120222173908.1753ead7c2b35a7d15c5b99498690bcc.389610f355.wbe@email11.secureserver.net>
MIME-Version: 1.0
Message-Id: <201202231206.45263.tobias.geiger@vido.info>
Cc: ray@aarden.us, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] GPU Pass Through Comment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Ray!

BIG THANKS for that information!

I switched from the Catalyst Driver to this FirePro Driver - and the Reboot-
Problems regarding GPU Performance are gone!

Gladly this driver seems to work also for non FirePro-Cards, here it works 
with a Radeon HD 6970 without problems so far.

Thanks for asking AMD - it never came to my mind it could be a driver-only 
solution for this problem... 

Greetings
Tobias

P.S.: just in case someone searches for GPU Passthrough stuff i cc'ed xen-devel

Am Donnerstag, 23. Februar 2012, 01:39:08 schrieb ray@aarden.us:
> After reading many posts on GPU pass through failing on reboot of the domU, 
>I questioned AMD and they responded with:
> 
>This is the known and documented issue with hypervisor - Resolved issues 
>(release notes) with driver  8.83.5.4 and above - May see system hang on 
>restart with some hypervisors.  Consider using a more recent firepro driver at 
>support.amd.com. 
>
>
>ray

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:07:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11:07:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0WVi-0007uu-T4; Thu, 23 Feb 2012 11:06:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1S0WVh-0007uj-Jr; Thu, 23 Feb 2012 11:06:53 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-11.tower-27.messagelabs.com!1329995184!54122170!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28597 invoked from network); 23 Feb 2012 11:06:24 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-11.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 11:06:24 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id AEE2CD347BD;
	Thu, 23 Feb 2012 12:06:48 +0100 (CET)
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 Nr2eMy4Mk-2W; Thu, 23 Feb 2012 12:06:46 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 84FD8D34180;
	Thu, 23 Feb 2012 12:06:46 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-users@lists.xen.org
Date: Thu, 23 Feb 2012 12:06:44 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20120222173908.1753ead7c2b35a7d15c5b99498690bcc.389610f355.wbe@email11.secureserver.net>
In-Reply-To: <20120222173908.1753ead7c2b35a7d15c5b99498690bcc.389610f355.wbe@email11.secureserver.net>
MIME-Version: 1.0
Message-Id: <201202231206.45263.tobias.geiger@vido.info>
Cc: ray@aarden.us, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] GPU Pass Through Comment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Ray!

BIG THANKS for that information!

I switched from the Catalyst Driver to this FirePro Driver - and the Reboot-
Problems regarding GPU Performance are gone!

Gladly this driver seems to work also for non FirePro-Cards, here it works 
with a Radeon HD 6970 without problems so far.

Thanks for asking AMD - it never came to my mind it could be a driver-only 
solution for this problem... 

Greetings
Tobias

P.S.: just in case someone searches for GPU Passthrough stuff i cc'ed xen-devel

Am Donnerstag, 23. Februar 2012, 01:39:08 schrieb ray@aarden.us:
> After reading many posts on GPU pass through failing on reboot of the domU, 
>I questioned AMD and they responded with:
> 
>This is the known and documented issue with hypervisor - Resolved issues 
>(release notes) with driver  8.83.5.4 and above - May see system hang on 
>restart with some hypervisors.  Consider using a more recent firepro driver at 
>support.amd.com. 
>
>
>ray

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11: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 1S0WgI-0008Re-T5; Thu, 23 Feb 2012 11:17:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0WgH-0008RU-Jz
	for Xen-devel@lists.xensource.com; Thu, 23 Feb 2012 11:17:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329995863!15519636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 434 invoked from network); 23 Feb 2012 11:17:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 11:17:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10892365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:17:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:17:43 +0000
Message-ID: <1329995862.8557.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 11:17:42 +0000
In-Reply-To: <1328718722.6133.60.camel@zakaz.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-08 at 16:32 +0000, Ian Campbell wrote:
> Hi Andy, 
> 
> Good to meet you over the w.e.
> 
> On Tue, 2012-02-07 at 17:30 +0000, Ian Jackson wrote:
> > Andy Smith writes ("[Xen-devel] Re-reading domain configs on domain restart"):
> > > I understand this will never be fixed in xend/xm, but would it be
> > > possible to have xl re-read the domU's config when the domU
> > > restarts?
> > 
> > Yes, this would certainly be possible.  Straightforward, even.
> > There are two questions we need to answer first:
> > 
> > Firstly, how should this be requested ?  I think a command-line option
> > to xl would do the trick.

> > Secondly, should we change the default behaviour ?  I'd be inclined
> > towards "yes" as the current arrangement is really rather perverse,
> > but I'm open to opinions.

Did we decide what to do here?

It occurred to me that rereading by default requires that the config
file still exist when the reboot happens, which may not be the case for
certain usecase which dump the config in a $TMPFILE or use the command
line syntax (someone said they did this). I suppose we could fallback to
the original config if the file no longer exists, but that would be
potentially confusing. Also I wonder if people do
	xl create template.cfg name="VM1"
	vi template.cfg
	hack it around
	xl create template.cfg name="VM2"
It would be odd for VM1 to turn into VM2 on reboot. Hrm, rereading also
takes no account of options passed on the command line on reboot.

As another (hopefully simple) idea how about a "xl dom-set-config" or
similar which (only) updates the config stashed in the userinfo to be
used on reboot? I would specifically exclude the possibility of this
reconfiguring the running domain for simplicity.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11: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 1S0WgI-0008Re-T5; Thu, 23 Feb 2012 11:17:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0WgH-0008RU-Jz
	for Xen-devel@lists.xensource.com; Thu, 23 Feb 2012 11:17:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1329995863!15519636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 434 invoked from network); 23 Feb 2012 11:17:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 11:17:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,469,1325462400"; d="scan'208";a="10892365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:17:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:17:43 +0000
Message-ID: <1329995862.8557.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 11:17:42 +0000
In-Reply-To: <1328718722.6133.60.camel@zakaz.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-08 at 16:32 +0000, Ian Campbell wrote:
> Hi Andy, 
> 
> Good to meet you over the w.e.
> 
> On Tue, 2012-02-07 at 17:30 +0000, Ian Jackson wrote:
> > Andy Smith writes ("[Xen-devel] Re-reading domain configs on domain restart"):
> > > I understand this will never be fixed in xend/xm, but would it be
> > > possible to have xl re-read the domU's config when the domU
> > > restarts?
> > 
> > Yes, this would certainly be possible.  Straightforward, even.
> > There are two questions we need to answer first:
> > 
> > Firstly, how should this be requested ?  I think a command-line option
> > to xl would do the trick.

> > Secondly, should we change the default behaviour ?  I'd be inclined
> > towards "yes" as the current arrangement is really rather perverse,
> > but I'm open to opinions.

Did we decide what to do here?

It occurred to me that rereading by default requires that the config
file still exist when the reboot happens, which may not be the case for
certain usecase which dump the config in a $TMPFILE or use the command
line syntax (someone said they did this). I suppose we could fallback to
the original config if the file no longer exists, but that would be
potentially confusing. Also I wonder if people do
	xl create template.cfg name="VM1"
	vi template.cfg
	hack it around
	xl create template.cfg name="VM2"
It would be odd for VM1 to turn into VM2 on reboot. Hrm, rereading also
takes no account of options passed on the command line on reboot.

As another (hopefully simple) idea how about a "xl dom-set-config" or
similar which (only) updates the config stashed in the userinfo to be
used on reboot? I would specifically exclude the possibility of this
reconfiguring the running domain for simplicity.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11: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 1S0Wou-0000Fd-40; Thu, 23 Feb 2012 11:26:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1S0Wos-0000FY-9B
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 11:26:42 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329996395!14583882!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4019 invoked from network); 23 Feb 2012 11:26:35 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 11:26:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=DG0y7p/Lylzkrqb4y6CIgAEm/F+ZLNVuqUSugP9FUAE=; 
	b=3CHShKmhUAze5l2X2IviQnu7zetVmBP0WdRZPiRzCk/UeegVmAXjvwCm1GhANBxAdAG8COA79m2aZh/vaDIzTGBjBHKpcE2HXR9VFgBNGpTRp2aANl1CLg1lg6FVnEP2;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1S0Woj-0001y1-SV
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 11:26:34 +0000
Date: Thu, 23 Feb 2012 11:26:33 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xen.org
Message-ID: <20120223112633.GJ4154@bitfolk.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
	<1329995862.8557.83.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329995862.8557.83.camel@zakaz.uk.xensource.com>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Thu,
	23 Feb 2012 11:26:33 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd0.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Thu, Feb 23, 2012 at 11:17:42AM +0000, Ian Campbell wrote:
> As another (hopefully simple) idea how about a "xl dom-set-config" or
> similar which (only) updates the config stashed in the userinfo to be
> used on reboot? I would specifically exclude the possibility of this
> reconfiguring the running domain for simplicity.

As a user I would be happy with this solution as it still lets me do
what I want to do.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11: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 1S0Wou-0000Fd-40; Thu, 23 Feb 2012 11:26:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1S0Wos-0000FY-9B
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 11:26:42 +0000
X-Env-Sender: andy@strugglers.net
X-Msg-Ref: server-10.tower-174.messagelabs.com!1329996395!14583882!1
X-Originating-IP: [85.119.80.223]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4019 invoked from network); 23 Feb 2012 11:26:35 -0000
Received: from bitfolk.com (HELO mail.bitfolk.com) (85.119.80.223)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Feb 2012 11:26:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitfolk.com;
	s=alpha; 
	h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:To:From:Date;
	bh=DG0y7p/Lylzkrqb4y6CIgAEm/F+ZLNVuqUSugP9FUAE=; 
	b=3CHShKmhUAze5l2X2IviQnu7zetVmBP0WdRZPiRzCk/UeegVmAXjvwCm1GhANBxAdAG8COA79m2aZh/vaDIzTGBjBHKpcE2HXR9VFgBNGpTRp2aANl1CLg1lg6FVnEP2;
Received: from andy by mail.bitfolk.com with local (Exim 4.72)
	(envelope-from <andy@strugglers.net>) id 1S0Woj-0001y1-SV
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 11:26:34 +0000
Date: Thu, 23 Feb 2012 11:26:33 +0000
From: Andy Smith <andy@strugglers.net>
To: xen-devel@lists.xen.org
Message-ID: <20120223112633.GJ4154@bitfolk.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
	<1329995862.8557.83.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329995862.8557.83.camel@zakaz.uk.xensource.com>
OpenPGP: id=BF15490B; url=http://strugglers.net/~andy/pubkey.asc
X-URL: http://strugglers.net/wiki/User:Andy
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanner: Scanned by ClamAV on mail.bitfolk.com at Thu,
	23 Feb 2012 11:26:33 +0000
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: andy@strugglers.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamd0.lon.bitfolk.com
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS shortcircuit=no
	autolearn=disabled version=3.3.1
X-Spam-Report: * -0.0 NO_RELAYS Informational: message was not relayed via SMTP
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.bitfolk.com)
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On Thu, Feb 23, 2012 at 11:17:42AM +0000, Ian Campbell wrote:
> As another (hopefully simple) idea how about a "xl dom-set-config" or
> similar which (only) updates the config stashed in the userinfo to be
> used on reboot? I would specifically exclude the possibility of this
> reconfiguring the running domain for simplicity.

As a user I would be happy with this solution as it still lets me do
what I want to do.

Cheers,
Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:42:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0X3k-0001B3-Lh; Thu, 23 Feb 2012 11:42:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1S0X3j-0001AN-FQ; Thu, 23 Feb 2012 11:42:03 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329997317!10370180!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21313 invoked from network); 23 Feb 2012 11:41:57 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Feb 2012 11:41:57 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id E647FD34729;
	Thu, 23 Feb 2012 12:41:56 +0100 (CET)
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 i4u1w8nyBdVI; Thu, 23 Feb 2012 12:41:50 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id AF809D34180;
	Thu, 23 Feb 2012 12:41:50 +0100 (CET)
To: xen-users@lists.xen.org
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
Date: Thu, 23 Feb 2012 12:41:49 +0100
MIME-Version: 1.0
Message-Id: <201202231241.49679.tobias.geiger@vido.info>
Cc: ray@aarden.us, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] GPU Pass Through Comment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi again,

seems i was to early with my excitement - after another DomU Reboot the 
Performance is again degraded , even with the FirePro Driver :(

After a cold boot i get about 3000 points in a 720p Benchmark (with a tool 
called "Furmark"), after a DomU reboot it gets down to 500 points...

So - no real enhancement here even with the FirePro Driver

Greetings
Tobias

Am Donnerstag, 23. Februar 2012, 01:39:08 schrieb ray@aarden.us:
> After reading many posts on GPU pass through failing on reboot of the domU, 
>I questioned AMD and they responded with:
> 
>This is the known and documented issue with hypervisor - Resolved issues 
>(release notes) with driver  8.83.5.4 and above - May see system hang on 
>restart with some hypervisors.  Consider using a more recent firepro driver at 
>support.amd.com. 
>
>
>ray

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 11:42:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 11:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0X3k-0001B3-Lh; Thu, 23 Feb 2012 11:42:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1S0X3j-0001AN-FQ; Thu, 23 Feb 2012 11:42:03 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-174.messagelabs.com!1329997317!10370180!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21313 invoked from network); 23 Feb 2012 11:41:57 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Feb 2012 11:41:57 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id E647FD34729;
	Thu, 23 Feb 2012 12:41:56 +0100 (CET)
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 i4u1w8nyBdVI; Thu, 23 Feb 2012 12:41:50 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id AF809D34180;
	Thu, 23 Feb 2012 12:41:50 +0100 (CET)
To: xen-users@lists.xen.org
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
Date: Thu, 23 Feb 2012 12:41:49 +0100
MIME-Version: 1.0
Message-Id: <201202231241.49679.tobias.geiger@vido.info>
Cc: ray@aarden.us, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] GPU Pass Through Comment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi again,

seems i was to early with my excitement - after another DomU Reboot the 
Performance is again degraded , even with the FirePro Driver :(

After a cold boot i get about 3000 points in a 720p Benchmark (with a tool 
called "Furmark"), after a DomU reboot it gets down to 500 points...

So - no real enhancement here even with the FirePro Driver

Greetings
Tobias

Am Donnerstag, 23. Februar 2012, 01:39:08 schrieb ray@aarden.us:
> After reading many posts on GPU pass through failing on reboot of the domU, 
>I questioned AMD and they responded with:
> 
>This is the known and documented issue with hypervisor - Resolved issues 
>(release notes) with driver  8.83.5.4 and above - May see system hang on 
>restart with some hypervisors.  Consider using a more recent firepro driver at 
>support.amd.com. 
>
>
>ray

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 12:19:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 12: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 1S0XdW-0002Ef-AO; Thu, 23 Feb 2012 12:19:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0XdU-0002Ea-S8
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 12:19:01 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329999533!14617088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17526 invoked from network); 23 Feb 2012 12:18:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 12:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22372866"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 07:18:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 07:18:52 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1S0XdM-0006WY-4w;
	Thu, 23 Feb 2012 12:18:52 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329993761.8557.66.camel@zakaz.uk.xensource.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
Date: Thu, 23 Feb 2012 12:18:51 +0000
Message-ID: <1329999531.19361.74.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
> What if you switch back without making sure you are in such a state? I
> think switching between the two is where the potential for unexpected
> behaviour is most likely.

Yeah, correctly predicting what would happen requires understanding what
mem-set does under the hood.

> I like that you have to explicitly ask for the safety wheels to come off
> and explicitly put them back on again. It avoids the corner cases I
> alluded to above (at least I hope so).

Yes, I think your suggestion sounds more like driving a car with a
proper hood, and less like driving a go-kart with the engine
exposed. :-)

> Without wishing to put words in Andres' mouth I expect that he intended
> "footprint" to cover other technical means than paging too --
> specifically I expect he was thinking of page sharing. (I suppose it
> also covers PoD to some extent too, although that is something of a
> special case)
> 
> While I don't expect there will be a knob to control number of shared
> pages (either you can share some pages or not, the settings would be
> more about how aggressively you search for sharable pages) it might be
> useful to consider the interaction between paging and sharing, I expect
> that most sharing configurations would want to have paging on at the
> same time (for safety). It seems valid to me to want to say "make the
> guest use this amount of actual RAM" and to achieve that by sharing what
> you can and then paging the rest.

Yes, it's worth thinking about; as long as it doesn't stall the paging
UI too long. :-)

The thing is, you can't actually control how much sharing happens.  That
depends largely on whether the guests create and maintain pages which
are share-able, and whether the sharing detection algorithm can find
such pages.  Even if two guests are sharing 95% of their pages, at any
point one of the guests may simply go wild and change them all.  So it
seems to me that shared pages need to be treated like sunny days in the
UK: Enjoy them while they're there, but don't count on them. :-)

Given that, I think that each VM should have a "guaranteed minimum
memory footprint", which would be the amount of actual host ram it will
have if suddenly no shared pages become available.  After that, there
should be a policy of how to use the "windfall" or "bonus" pages
generated by sharing.

One sensible default policy would be "givers gain": Every guest which
creates a page which happens to be shared by another VM gets a share of
the pages freed up by the sharing.  Another policy might be "communism",
where the freed up pages are shared among all VMs, regardless of whose
pages made the benefit possible.  (In fact, if shared pages come from
zero pages, they should probably be given to VMs with no zero pages,
regardless of the policy.)

However, I'd say the main public "knobs" should be just consist of two
things: 
* xl mem-set memory-target.  This is the minimum amount of physical RAM
a guest can get; we make sure that the sum of these for all VMs does not
exceed the host capacity.
* xl sharing-policy [policy].  This tells the sharing system how to use
the "windfall" pages gathered from page sharing.  

Then internally, the sharing system should combine the "minimum
footprint" with the number of extra pages and the policy to set the
amount of memory actually used (via balloon driver or paging).

You could imagine a manual mode, where the administrator shares out the
extra pages manually to VMs that he thinks needs them; but because those
extra pages may go away at any time, that needs to be a separate knob
(and preferably one which most admins don't ever touch).

Andres, what do you think?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 12:19:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 12: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 1S0XdW-0002Ef-AO; Thu, 23 Feb 2012 12:19:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0XdU-0002Ea-S8
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 12:19:01 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1329999533!14617088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17526 invoked from network); 23 Feb 2012 12:18:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 12:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22372866"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 07:18:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 07:18:52 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1S0XdM-0006WY-4w;
	Thu, 23 Feb 2012 12:18:52 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329993761.8557.66.camel@zakaz.uk.xensource.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
Date: Thu, 23 Feb 2012 12:18:51 +0000
Message-ID: <1329999531.19361.74.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
> What if you switch back without making sure you are in such a state? I
> think switching between the two is where the potential for unexpected
> behaviour is most likely.

Yeah, correctly predicting what would happen requires understanding what
mem-set does under the hood.

> I like that you have to explicitly ask for the safety wheels to come off
> and explicitly put them back on again. It avoids the corner cases I
> alluded to above (at least I hope so).

Yes, I think your suggestion sounds more like driving a car with a
proper hood, and less like driving a go-kart with the engine
exposed. :-)

> Without wishing to put words in Andres' mouth I expect that he intended
> "footprint" to cover other technical means than paging too --
> specifically I expect he was thinking of page sharing. (I suppose it
> also covers PoD to some extent too, although that is something of a
> special case)
> 
> While I don't expect there will be a knob to control number of shared
> pages (either you can share some pages or not, the settings would be
> more about how aggressively you search for sharable pages) it might be
> useful to consider the interaction between paging and sharing, I expect
> that most sharing configurations would want to have paging on at the
> same time (for safety). It seems valid to me to want to say "make the
> guest use this amount of actual RAM" and to achieve that by sharing what
> you can and then paging the rest.

Yes, it's worth thinking about; as long as it doesn't stall the paging
UI too long. :-)

The thing is, you can't actually control how much sharing happens.  That
depends largely on whether the guests create and maintain pages which
are share-able, and whether the sharing detection algorithm can find
such pages.  Even if two guests are sharing 95% of their pages, at any
point one of the guests may simply go wild and change them all.  So it
seems to me that shared pages need to be treated like sunny days in the
UK: Enjoy them while they're there, but don't count on them. :-)

Given that, I think that each VM should have a "guaranteed minimum
memory footprint", which would be the amount of actual host ram it will
have if suddenly no shared pages become available.  After that, there
should be a policy of how to use the "windfall" or "bonus" pages
generated by sharing.

One sensible default policy would be "givers gain": Every guest which
creates a page which happens to be shared by another VM gets a share of
the pages freed up by the sharing.  Another policy might be "communism",
where the freed up pages are shared among all VMs, regardless of whose
pages made the benefit possible.  (In fact, if shared pages come from
zero pages, they should probably be given to VMs with no zero pages,
regardless of the policy.)

However, I'd say the main public "knobs" should be just consist of two
things: 
* xl mem-set memory-target.  This is the minimum amount of physical RAM
a guest can get; we make sure that the sum of these for all VMs does not
exceed the host capacity.
* xl sharing-policy [policy].  This tells the sharing system how to use
the "windfall" pages gathered from page sharing.  

Then internally, the sharing system should combine the "minimum
footprint" with the number of extra pages and the policy to set the
amount of memory actually used (via balloon driver or paging).

You could imagine a manual mode, where the administrator shares out the
extra pages manually to VMs that he thinks needs them; but because those
extra pages may go away at any time, that needs to be a separate knob
(and preferably one which most admins don't ever touch).

Andres, what do you think?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 12:28:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 12:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0XmL-0002Pp-AL; Thu, 23 Feb 2012 12:28:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S0XmJ-0002Pk-Qa
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 12:28:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330000079!10379335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10993 invoked from network); 23 Feb 2012 12:28:00 -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;
	23 Feb 2012 12:28:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10894218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:27:59 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:27:59 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120223104520.GD25694@ocelot.phlegethon.org>
References: <1329922812.5468.55.camel@leeds.uk.xensource.com>
	<20120223104520.GD25694@ocelot.phlegethon.org>
Date: Thu, 23 Feb 2012 12:27:22 +0000
Message-ID: <1330000043.5468.73.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] Add gtags target for xen/Makefile. Also
 update .hgignore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:45 +0000, Tim Deegan wrote:
> At 15:00 +0000 on 22 Feb (1329922812), Wei Liu wrote:
> > +.PHONY: _gtags
> > +_gtags:
> > +	set -e; rm -f GTAGS GSYMS GPATH GRTAGS
> > +	$(all_sources) > gtags.files
> > +	gtags -f gtags.files
> > +
> 
> Minor nit: the gtags manpage suggests that '$(all_sources) | gtags -f -'
> would work, and save us from tracking another file.
> 
> Tim.

----8<--------

# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1330000012 0
# Node ID 0f817275c625527d560ebf9ec82c5037a502d3d5
# Parent  d433a9cb0089683b8f75458807c5437341f2cdcc
Add gtags target for xen/Makefile. Also update .hgignore.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -23,6 +23,7 @@
 ^\.config$
 ^\.pc
 (^|/)(tags|TAGS)$
+(^|/)(GTAGS|GPATH|GSYMS|GRTAGS)$
 ^build-.*$
 ^dist/.*$
 ^docs/.*\.aux$
diff --git a/xen/Makefile b/xen/Makefile
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,8 +20,8 @@ default: build
 .PHONY: dist
 dist: install
 
-.PHONY: build install clean distclean cscope TAGS tags MAP
-build install debug clean distclean cscope TAGS tags MAP::
+.PHONY: build install clean distclean cscope TAGS tags MAP gtags
+build install debug clean distclean cscope TAGS tags MAP gtags::
        $(MAKE) -f Rules.mk _$@
 
 .PHONY: _build
@@ -67,7 +67,7 @@ _clean: delete-unfresh-files
 
 .PHONY: _distclean
 _distclean: clean
-       rm -f tags TAGS cscope.files cscope.in.out cscope.out
cscope.po.out
+       rm -f tags TAGS cscope.files cscope.in.out cscope.out
cscope.po.out GTAGS GPATH GRTAGS GSYMS
 
 $(TARGET).gz: $(TARGET)
        gzip -f -9 < $< > $@.new
@@ -159,6 +159,11 @@ _tags:
        $(call set_exuberant_flags,ctags); \
        $(all_sources) | xargs ctags $$exuberant_flags -a
 
+.PHONY: _gtags
+_gtags:
+       set -e; rm -f GTAGS GSYMS GPATH GRTAGS
+       $(all_sources) | gtags -f -
+
 .PHONY: _cscope
 _cscope:
        $(all_sources) > cscope.files



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 12:28:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 12:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0XmL-0002Pp-AL; Thu, 23 Feb 2012 12:28:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S0XmJ-0002Pk-Qa
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 12:28:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330000079!10379335!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10993 invoked from network); 23 Feb 2012 12:28:00 -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;
	23 Feb 2012 12:28:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10894218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:27:59 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:27:59 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120223104520.GD25694@ocelot.phlegethon.org>
References: <1329922812.5468.55.camel@leeds.uk.xensource.com>
	<20120223104520.GD25694@ocelot.phlegethon.org>
Date: Thu, 23 Feb 2012 12:27:22 +0000
Message-ID: <1330000043.5468.73.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] Add gtags target for xen/Makefile. Also
 update .hgignore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 10:45 +0000, Tim Deegan wrote:
> At 15:00 +0000 on 22 Feb (1329922812), Wei Liu wrote:
> > +.PHONY: _gtags
> > +_gtags:
> > +	set -e; rm -f GTAGS GSYMS GPATH GRTAGS
> > +	$(all_sources) > gtags.files
> > +	gtags -f gtags.files
> > +
> 
> Minor nit: the gtags manpage suggests that '$(all_sources) | gtags -f -'
> would work, and save us from tracking another file.
> 
> Tim.

----8<--------

# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1330000012 0
# Node ID 0f817275c625527d560ebf9ec82c5037a502d3d5
# Parent  d433a9cb0089683b8f75458807c5437341f2cdcc
Add gtags target for xen/Makefile. Also update .hgignore.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -23,6 +23,7 @@
 ^\.config$
 ^\.pc
 (^|/)(tags|TAGS)$
+(^|/)(GTAGS|GPATH|GSYMS|GRTAGS)$
 ^build-.*$
 ^dist/.*$
 ^docs/.*\.aux$
diff --git a/xen/Makefile b/xen/Makefile
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,8 +20,8 @@ default: build
 .PHONY: dist
 dist: install
 
-.PHONY: build install clean distclean cscope TAGS tags MAP
-build install debug clean distclean cscope TAGS tags MAP::
+.PHONY: build install clean distclean cscope TAGS tags MAP gtags
+build install debug clean distclean cscope TAGS tags MAP gtags::
        $(MAKE) -f Rules.mk _$@
 
 .PHONY: _build
@@ -67,7 +67,7 @@ _clean: delete-unfresh-files
 
 .PHONY: _distclean
 _distclean: clean
-       rm -f tags TAGS cscope.files cscope.in.out cscope.out
cscope.po.out
+       rm -f tags TAGS cscope.files cscope.in.out cscope.out
cscope.po.out GTAGS GPATH GRTAGS GSYMS
 
 $(TARGET).gz: $(TARGET)
        gzip -f -9 < $< > $@.new
@@ -159,6 +159,11 @@ _tags:
        $(call set_exuberant_flags,ctags); \
        $(all_sources) | xargs ctags $$exuberant_flags -a
 
+.PHONY: _gtags
+_gtags:
+       set -e; rm -f GTAGS GSYMS GPATH GRTAGS
+       $(all_sources) | gtags -f -
+
 .PHONY: _cscope
 _cscope:
        $(all_sources) > cscope.files



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 12:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 12:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YBi-0002c6-H4; Thu, 23 Feb 2012 12:54: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 1S0YBh-0002c1-Fx
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 12:54:21 +0000
Received: from [85.158.139.83:17096] by server-11.bemta-5.messagelabs.com id
	1F/F3-14397-CF6364F4; Thu, 23 Feb 2012 12:54:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330001659!16331562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18351 invoked from network); 23 Feb 2012 12:54:20 -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;
	23 Feb 2012 12:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10895071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:54:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 12:54:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0YBf-0002AH-Hb;
	Thu, 23 Feb 2012 12:54:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0YBf-0004zI-Cf;
	Thu, 23 Feb 2012 12:54:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12031-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 12:54:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12031: 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 12031 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12031/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2         fail pass in 12024

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12024

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail in 12024 never pass

version targeted for testing:
 xen                  a4d93d0e0df2
baseline version:
 xen                  a4d93d0e0df2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 12:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 12:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YBi-0002c6-H4; Thu, 23 Feb 2012 12:54: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 1S0YBh-0002c1-Fx
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 12:54:21 +0000
Received: from [85.158.139.83:17096] by server-11.bemta-5.messagelabs.com id
	1F/F3-14397-CF6364F4; Thu, 23 Feb 2012 12:54:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330001659!16331562!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18351 invoked from network); 23 Feb 2012 12:54:20 -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;
	23 Feb 2012 12:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10895071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:54:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 12:54:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0YBf-0002AH-Hb;
	Thu, 23 Feb 2012 12:54:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0YBf-0004zI-Cf;
	Thu, 23 Feb 2012 12:54:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12031-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 12:54:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12031: 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 12031 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12031/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2         fail pass in 12024

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12024

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail in 12024 never pass

version targeted for testing:
 xen                  a4d93d0e0df2
baseline version:
 xen                  a4d93d0e0df2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0YJ8-0002nh-Dg; Thu, 23 Feb 2012 13:02:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ6-0002nB-Th
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330002113!14579791!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19893 invoked from network); 23 Feb 2012 13:01:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-5t;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 26 V3] libxl: improved handling for
	default values in API
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a mechanism for users of libxl to explicitly say "pick the
default for me".

To do this each field has a distinguished "init_val" and each struct
has a "_setdefault" method which sets (idempotently) the defaults for
fields which have not been set to an explicit value.

Previously I went through some contortions (with "timer_mode" in
particular but also with *_memkb fields) to try and arrange that this
distinguished value was the all zeroes bit pattern.

Instead of that pain this time I have arranged that the IDL supports
the specification the distinguished val for each type/field and we
autogenerate an _init function for each data type based on that.

For reviewer convenience I've also put the series in git (based on
IanJ's git tree at: git://xenbits.xen.org/people/iwj/xen-unstable.git
(because IanJ was the reviewer who asked for it...)

The following changes since commit e4296962b0e5d913929164b913f47fe288ab783e:

  tools/hotplug: remove 4 from default runlevel in xencommons (2012-02-20 18:58:07 +0000)

are available in the git repository at:
  git://xenbits.xen.org/people/ianc/xen-unstable.git for-ianj/libxl

Changes since last time:

* Added two unrelated patches to remove Xen public headers from
  libxl's API to the head of the queue
* Produce _dispose and _init for all Aggregate types.
* Be more assertive about why we should drop the 8M slack on PV.
* Happens to fix stubdomains, broken by 24612:54000bca7a6a due to not
  setting the CPU affinity for the stub domain.
Changes since the time before:

* I have posted large parts of the previous series as
  * libxl: drop device_model_info
  * libxl: API updates + xl: JSON
  These have been committed thereby reducing the size of this series.
* _init function support as described above
* Dropped final patch to actually select stubdoms when possible --
  this needs more investigation/sanity checking.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0YJ8-0002nh-Dg; Thu, 23 Feb 2012 13:02:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ6-0002nB-Th
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330002113!14579791!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19893 invoked from network); 23 Feb 2012 13:01:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-5t;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 26 V3] libxl: improved handling for
	default values in API
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a mechanism for users of libxl to explicitly say "pick the
default for me".

To do this each field has a distinguished "init_val" and each struct
has a "_setdefault" method which sets (idempotently) the defaults for
fields which have not been set to an explicit value.

Previously I went through some contortions (with "timer_mode" in
particular but also with *_memkb fields) to try and arrange that this
distinguished value was the all zeroes bit pattern.

Instead of that pain this time I have arranged that the IDL supports
the specification the distinguished val for each type/field and we
autogenerate an _init function for each data type based on that.

For reviewer convenience I've also put the series in git (based on
IanJ's git tree at: git://xenbits.xen.org/people/iwj/xen-unstable.git
(because IanJ was the reviewer who asked for it...)

The following changes since commit e4296962b0e5d913929164b913f47fe288ab783e:

  tools/hotplug: remove 4 from default runlevel in xencommons (2012-02-20 18:58:07 +0000)

are available in the git repository at:
  git://xenbits.xen.org/people/ianc/xen-unstable.git for-ianj/libxl

Changes since last time:

* Added two unrelated patches to remove Xen public headers from
  libxl's API to the head of the queue
* Produce _dispose and _init for all Aggregate types.
* Be more assertive about why we should drop the 8M slack on PV.
* Happens to fix stubdomains, broken by 24612:54000bca7a6a due to not
  setting the CPU affinity for the stub domain.
Changes since the time before:

* I have posted large parts of the previous series as
  * libxl: drop device_model_info
  * libxl: API updates + xl: JSON
  These have been committed thereby reducing the size of this series.
* _init function support as described above
* Dropped final patch to actually select stubdoms when possible --
  this needs more investigation/sanity checking.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJC-0002q4-7a; Thu, 23 Feb 2012 13:02:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ9-0002nM-Qh
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330002115!15540727!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11894 invoked from network); 23 Feb 2012 13:01:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106537"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-6Z;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: d3332d3bc6fbf50aa2054f2f458afa4cf1232377
Message-ID: <d3332d3bc6fbf50aa205.1330002110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 26 V3] libxl: remove sysctl.h from public
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000275 0
# Node ID d3332d3bc6fbf50aa2054f2f458afa4cf1232377
# Parent  0b8f336ac283e9f5107ae04b5f4d50bdaff72cba
libxl: remove sysctl.h from public interface

Using sysctl.h is restricted to "node control tools only" and requires magic
defines. Therefore make its use internal to libxl.

Also removes an indirect include of domctl.h which has the same restrction.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:15 2012 +0000
@@ -491,7 +491,7 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         }
         ptr = tmp;
         ptr[i].poolid = info->cpupool_id;
-        ptr[i].sched_id = info->sched_id;
+        ptr[i].sched = info->sched_id;
         ptr[i].n_dom = info->n_dom;
         if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {
             xc_cpupool_infofree(ctx->xch, info);
@@ -2750,7 +2750,10 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
-    physinfo->phys_cap = xcphysinfo.capabilities;
+
+    physinfo->cap_hvm = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm);
+    physinfo->cap_hvm_directio =
+        !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm_directio);
 
     return 0;
 }
@@ -2961,14 +2964,11 @@ out:
     return rc;
 }
 
-/*
- * returns one of the XEN_SCHEDULER_* constants from public/domctl.h
- */
-int libxl_get_sched_id(libxl_ctx *ctx)
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx)
 {
-    int sched, ret;
-
-    if ((ret = xc_sched_id(ctx->xch, &sched)) != 0) {
+    libxl_scheduler sched, ret;
+
+    if ((ret = xc_sched_id(ctx->xch, (int *)&sched)) != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
@@ -3441,7 +3441,8 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
@@ -3457,7 +3458,7 @@ int libxl_cpupool_create(libxl_ctx *ctx,
         return ERROR_NOMEM;
     }
 
-    rc = xc_cpupool_create(ctx->xch, poolid, schedid);
+    rc = xc_cpupool_create(ctx->xch, poolid, sched);
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:15 2012 +0000
@@ -138,7 +138,6 @@
 #include <xentoollog.h>
 
 #include <xen/sched.h>
-#include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
@@ -584,7 +583,7 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
                                unsigned int max_vcpus, libxl_cpumap *cpumap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
 
-int libxl_get_sched_id(libxl_ctx *ctx);
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
@@ -627,7 +626,8 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:15 2012 +0000
@@ -99,6 +99,14 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+# Consistent with values defined in domctl.h
+libxl_scheduler = Enumeration("scheduler", [
+    (4, "sedf"),
+    (5, "credit"),
+    (6, "credit2"),
+    (7, "arinc653"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -158,7 +166,7 @@ libxl_dominfo = Struct("dominfo",[
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
-    ("sched_id",    uint32),
+    ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
     ])
@@ -381,7 +389,9 @@ libxl_physinfo = Struct("physinfo", [
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
-    ("phys_cap", uint32),
+
+    ("cap_hvm", bool),
+    ("cap_hvm_directio", bool),
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_cputopology = Struct("cputopology", [
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:15 2012 +0000
@@ -19,18 +19,6 @@
 
 #include "libxl_internal.h"
 
-struct schedid_name {
-    char *name;
-    int id;
-};
-
-static struct schedid_name schedid_name[] = {
-    { "credit", XEN_SCHEDULER_CREDIT },
-    { "sedf", XEN_SCHEDULER_SEDF },
-    { "credit2", XEN_SCHEDULER_CREDIT2 },
-    { NULL, -1 }
-};
-
 const char *libxl_basename(const char *name)
 {
     const char *filename;
@@ -151,28 +139,6 @@ int libxl_name_to_cpupoolid(libxl_ctx *c
     return ret;
 }
 
-int libxl_name_to_schedid(libxl_ctx *ctx, const char *name)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (strcmp(name, schedid_name[i].name) == 0)
-            return schedid_name[i].id;
-
-    return ERROR_INVAL;
-}
-
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (schedid_name[i].id == schedid)
-            return schedid_name[i].name;
-
-    return "unknown";
-}
-
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
     GC_INIT(ctx);
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Thu Feb 23 12:31:15 2012 +0000
@@ -24,8 +24,6 @@ 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_name_to_schedid(libxl_ctx *ctx, const char *name);
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:15 2012 +0000
@@ -3688,15 +3688,15 @@ int main_vcpuset(int argc, char **argv)
 static void output_xeninfo(void)
 {
     const libxl_version_info *info;
-    int sched_id;
+    libxl_scheduler sched;
 
     if (!(info = libxl_get_version_info(ctx))) {
         fprintf(stderr, "libxl_get_version_info failed.\n");
         return;
     }
 
-    if ((sched_id = libxl_get_sched_id(ctx)) < 0) {
-        fprintf(stderr, "get_sched_id sysctl failed.\n");
+    if ((sched = libxl_get_scheduler(ctx)) < 0) {
+        fprintf(stderr, "get_scheduler sysctl failed.\n");
         return;
     }
 
@@ -3704,7 +3704,7 @@ static void output_xeninfo(void)
     printf("xen_minor              : %d\n", info->xen_version_minor);
     printf("xen_extra              : %s\n", info->xen_version_extra);
     printf("xen_caps               : %s\n", info->capabilities);
-    printf("xen_scheduler          : %s\n", libxl_schedid_to_name(ctx, sched_id));
+    printf("xen_scheduler          : %s\n", libxl_scheduler_to_string(sched));
     printf("xen_pagesize           : %u\n", info->pagesize);
     printf("platform_params        : virt_start=0x%"PRIx64"\n", info->virt_start);
     printf("xen_changeset          : %s\n", info->changeset);
@@ -3752,9 +3752,9 @@ static void output_physinfo(void)
     for (i = 0; i < 8; i++)
         printf("%08x%c", info.hw_cap[i], i < 7 ? ':' : '\n');
     printf("virt_caps              :");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm)
+    if (info.cap_hvm)
         printf(" hvm");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm_directio)
+    if (info.cap_hvm_directio)
         printf(" hvm_directio");
     printf("\n");
     vinfo = libxl_get_version_info(ctx);
@@ -4060,7 +4060,7 @@ static int sched_sedf_domain_output(
 }
 
 static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+    libxl_scheduler sched, int (*output)(int), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
@@ -4089,7 +4089,7 @@ static int sched_domain_output(
     }
 
     for (p = 0; !rc && (p < n_pools); p++) {
-        if ((poolinfo[p].sched_id != sched) ||
+        if ((poolinfo[p].sched != sched) ||
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
@@ -4170,7 +4170,7 @@ int main_sched_credit(int argc, char **a
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT,
                                     sched_credit_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4246,7 +4246,7 @@ int main_sched_credit2(int argc, char **
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT2,
                                     sched_credit2_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4348,7 +4348,7 @@ int main_sched_sedf(int argc, char **arg
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_SEDF,
+        return -sched_domain_output(LIBXL_SCHEDULER_SEDF,
                                     sched_sedf_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -5287,9 +5287,8 @@ int main_cpupoolcreate(int argc, char **
     XLU_Config *config;
     const char *buf;
     const char *name;
-    const char *sched;
     uint32_t poolid;
-    int schedid = -1;
+    libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
     XLU_ConfigList *nodes;
     int n_cpus, n_nodes, i, n;
@@ -5384,17 +5383,16 @@ int main_cpupoolcreate(int argc, char **
     }
 
     if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
-        if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
+        if ((libxl_scheduler_from_string(buf, &sched)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;
         }
     } else {
-        if ((schedid = libxl_get_sched_id(ctx)) < 0) {
-            fprintf(stderr, "get_sched_id sysctl failed.\n");
+        if ((sched = libxl_get_scheduler(ctx)) < 0) {
+            fprintf(stderr, "get_scheduler sysctl failed.\n");
             return -ERROR_FAIL;
         }
     }
-    sched = libxl_schedid_to_name(ctx, schedid);
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         fprintf(stderr, "libxl_get_freecpus failed\n");
@@ -5462,14 +5460,14 @@ int main_cpupoolcreate(int argc, char **
 
     printf("Using config file \"%s\"\n", filename);
     printf("cpupool name:   %s\n", name);
-    printf("scheduler:      %s\n", sched);
+    printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
 
     if (dryrun_only)
         return 0;
 
     poolid = 0;
-    if (libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid)) {
+    if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) {
         fprintf(stderr, "error on creating cpupool\n");
         return -ERROR_FAIL;
     }
@@ -5554,7 +5552,7 @@ int main_cpupoollist(int argc, char **ar
                     }
                 if (!opt_cpus) {
                     printf("%3d %9s       y       %4d", n,
-                           libxl_schedid_to_name(ctx, poolinfo[p].sched_id),
+                           libxl_scheduler_to_string(poolinfo[p].sched),
                            poolinfo[p].n_dom);
                 }
                 printf("\n");
@@ -5739,7 +5737,7 @@ int main_cpupoolnumasplit(int argc, char
     int c;
     int n;
     uint32_t poolid;
-    int schedid;
+    libxl_scheduler sched;
     int n_pools;
     int node;
     int n_cpus;
@@ -5760,7 +5758,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_NOMEM;
     }
     poolid = poolinfo[0].poolid;
-    schedid = poolinfo[0].sched_id;
+    sched = poolinfo[0].sched;
     for (p = 0; p < n_pools; p++) {
         libxl_cpupoolinfo_dispose(poolinfo + p);
     }
@@ -5840,7 +5838,7 @@ int main_cpupoolnumasplit(int argc, char
         snprintf(name, 15, "Pool-node%d", node);
         libxl_uuid_generate(&uuid);
         poolid = 0;
-        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid);
+        ret = -libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid);
         if (ret) {
             fprintf(stderr, "error on creating cpupool\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 Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJC-0002q4-7a; Thu, 23 Feb 2012 13:02:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ9-0002nM-Qh
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330002115!15540727!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11894 invoked from network); 23 Feb 2012 13:01:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106537"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-6Z;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: d3332d3bc6fbf50aa2054f2f458afa4cf1232377
Message-ID: <d3332d3bc6fbf50aa205.1330002110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 26 V3] libxl: remove sysctl.h from public
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000275 0
# Node ID d3332d3bc6fbf50aa2054f2f458afa4cf1232377
# Parent  0b8f336ac283e9f5107ae04b5f4d50bdaff72cba
libxl: remove sysctl.h from public interface

Using sysctl.h is restricted to "node control tools only" and requires magic
defines. Therefore make its use internal to libxl.

Also removes an indirect include of domctl.h which has the same restrction.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:15 2012 +0000
@@ -491,7 +491,7 @@ libxl_cpupoolinfo * libxl_list_cpupool(l
         }
         ptr = tmp;
         ptr[i].poolid = info->cpupool_id;
-        ptr[i].sched_id = info->sched_id;
+        ptr[i].sched = info->sched_id;
         ptr[i].n_dom = info->n_dom;
         if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {
             xc_cpupool_infofree(ctx->xch, info);
@@ -2750,7 +2750,10 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
-    physinfo->phys_cap = xcphysinfo.capabilities;
+
+    physinfo->cap_hvm = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm);
+    physinfo->cap_hvm_directio =
+        !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm_directio);
 
     return 0;
 }
@@ -2961,14 +2964,11 @@ out:
     return rc;
 }
 
-/*
- * returns one of the XEN_SCHEDULER_* constants from public/domctl.h
- */
-int libxl_get_sched_id(libxl_ctx *ctx)
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx)
 {
-    int sched, ret;
-
-    if ((ret = xc_sched_id(ctx->xch, &sched)) != 0) {
+    libxl_scheduler sched, ret;
+
+    if ((ret = xc_sched_id(ctx->xch, (int *)&sched)) != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
         return ERROR_FAIL;
     }
@@ -3441,7 +3441,8 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
@@ -3457,7 +3458,7 @@ int libxl_cpupool_create(libxl_ctx *ctx,
         return ERROR_NOMEM;
     }
 
-    rc = xc_cpupool_create(ctx->xch, poolid, schedid);
+    rc = xc_cpupool_create(ctx->xch, poolid, sched);
     if (rc) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
            "Could not create cpupool");
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:15 2012 +0000
@@ -138,7 +138,6 @@
 #include <xentoollog.h>
 
 #include <xen/sched.h>
-#include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
@@ -584,7 +583,7 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
                                unsigned int max_vcpus, libxl_cpumap *cpumap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
 
-int libxl_get_sched_id(libxl_ctx *ctx);
+libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);
 
 
 int libxl_sched_credit_domain_get(libxl_ctx *ctx, uint32_t domid,
@@ -627,7 +626,8 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+                         libxl_scheduler sched,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:15 2012 +0000
@@ -99,6 +99,14 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+# Consistent with values defined in domctl.h
+libxl_scheduler = Enumeration("scheduler", [
+    (4, "sedf"),
+    (5, "credit"),
+    (6, "credit2"),
+    (7, "arinc653"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -158,7 +166,7 @@ libxl_dominfo = Struct("dominfo",[
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
-    ("sched_id",    uint32),
+    ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
     ])
@@ -381,7 +389,9 @@ libxl_physinfo = Struct("physinfo", [
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
-    ("phys_cap", uint32),
+
+    ("cap_hvm", bool),
+    ("cap_hvm_directio", bool),
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_cputopology = Struct("cputopology", [
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:15 2012 +0000
@@ -19,18 +19,6 @@
 
 #include "libxl_internal.h"
 
-struct schedid_name {
-    char *name;
-    int id;
-};
-
-static struct schedid_name schedid_name[] = {
-    { "credit", XEN_SCHEDULER_CREDIT },
-    { "sedf", XEN_SCHEDULER_SEDF },
-    { "credit2", XEN_SCHEDULER_CREDIT2 },
-    { NULL, -1 }
-};
-
 const char *libxl_basename(const char *name)
 {
     const char *filename;
@@ -151,28 +139,6 @@ int libxl_name_to_cpupoolid(libxl_ctx *c
     return ret;
 }
 
-int libxl_name_to_schedid(libxl_ctx *ctx, const char *name)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (strcmp(name, schedid_name[i].name) == 0)
-            return schedid_name[i].id;
-
-    return ERROR_INVAL;
-}
-
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid)
-{
-    int i;
-
-    for (i = 0; schedid_name[i].name != NULL; i++)
-        if (schedid_name[i].id == schedid)
-            return schedid_name[i].name;
-
-    return "unknown";
-}
-
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid)
 {
     GC_INIT(ctx);
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Thu Feb 23 12:31:15 2012 +0000
@@ -24,8 +24,6 @@ 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_name_to_schedid(libxl_ctx *ctx, const char *name);
-char *libxl_schedid_to_name(libxl_ctx *ctx, int schedid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
 int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name);
diff -r 0b8f336ac283 -r d3332d3bc6fb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:02 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:15 2012 +0000
@@ -3688,15 +3688,15 @@ int main_vcpuset(int argc, char **argv)
 static void output_xeninfo(void)
 {
     const libxl_version_info *info;
-    int sched_id;
+    libxl_scheduler sched;
 
     if (!(info = libxl_get_version_info(ctx))) {
         fprintf(stderr, "libxl_get_version_info failed.\n");
         return;
     }
 
-    if ((sched_id = libxl_get_sched_id(ctx)) < 0) {
-        fprintf(stderr, "get_sched_id sysctl failed.\n");
+    if ((sched = libxl_get_scheduler(ctx)) < 0) {
+        fprintf(stderr, "get_scheduler sysctl failed.\n");
         return;
     }
 
@@ -3704,7 +3704,7 @@ static void output_xeninfo(void)
     printf("xen_minor              : %d\n", info->xen_version_minor);
     printf("xen_extra              : %s\n", info->xen_version_extra);
     printf("xen_caps               : %s\n", info->capabilities);
-    printf("xen_scheduler          : %s\n", libxl_schedid_to_name(ctx, sched_id));
+    printf("xen_scheduler          : %s\n", libxl_scheduler_to_string(sched));
     printf("xen_pagesize           : %u\n", info->pagesize);
     printf("platform_params        : virt_start=0x%"PRIx64"\n", info->virt_start);
     printf("xen_changeset          : %s\n", info->changeset);
@@ -3752,9 +3752,9 @@ static void output_physinfo(void)
     for (i = 0; i < 8; i++)
         printf("%08x%c", info.hw_cap[i], i < 7 ? ':' : '\n');
     printf("virt_caps              :");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm)
+    if (info.cap_hvm)
         printf(" hvm");
-    if (info.phys_cap & XEN_SYSCTL_PHYSCAP_hvm_directio)
+    if (info.cap_hvm_directio)
         printf(" hvm_directio");
     printf("\n");
     vinfo = libxl_get_version_info(ctx);
@@ -4060,7 +4060,7 @@ static int sched_sedf_domain_output(
 }
 
 static int sched_domain_output(
-    uint32_t sched, int (*output)(int), const char *cpupool)
+    libxl_scheduler sched, int (*output)(int), const char *cpupool)
 {
     libxl_dominfo *info;
     libxl_cpupoolinfo *poolinfo = NULL;
@@ -4089,7 +4089,7 @@ static int sched_domain_output(
     }
 
     for (p = 0; !rc && (p < n_pools); p++) {
-        if ((poolinfo[p].sched_id != sched) ||
+        if ((poolinfo[p].sched != sched) ||
             (cpupool && (poolid != poolinfo[p].poolid)))
             continue;
 
@@ -4170,7 +4170,7 @@ int main_sched_credit(int argc, char **a
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT,
                                     sched_credit_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4246,7 +4246,7 @@ int main_sched_credit2(int argc, char **
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
+        return -sched_domain_output(LIBXL_SCHEDULER_CREDIT2,
                                     sched_credit2_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -4348,7 +4348,7 @@ int main_sched_sedf(int argc, char **arg
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        return -sched_domain_output(XEN_SCHEDULER_SEDF,
+        return -sched_domain_output(LIBXL_SCHEDULER_SEDF,
                                     sched_sedf_domain_output, cpupool);
     } else {
         find_domain(dom);
@@ -5287,9 +5287,8 @@ int main_cpupoolcreate(int argc, char **
     XLU_Config *config;
     const char *buf;
     const char *name;
-    const char *sched;
     uint32_t poolid;
-    int schedid = -1;
+    libxl_scheduler sched = 0;
     XLU_ConfigList *cpus;
     XLU_ConfigList *nodes;
     int n_cpus, n_nodes, i, n;
@@ -5384,17 +5383,16 @@ int main_cpupoolcreate(int argc, char **
     }
 
     if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
-        if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
+        if ((libxl_scheduler_from_string(buf, &sched)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;
         }
     } else {
-        if ((schedid = libxl_get_sched_id(ctx)) < 0) {
-            fprintf(stderr, "get_sched_id sysctl failed.\n");
+        if ((sched = libxl_get_scheduler(ctx)) < 0) {
+            fprintf(stderr, "get_scheduler sysctl failed.\n");
             return -ERROR_FAIL;
         }
     }
-    sched = libxl_schedid_to_name(ctx, schedid);
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         fprintf(stderr, "libxl_get_freecpus failed\n");
@@ -5462,14 +5460,14 @@ int main_cpupoolcreate(int argc, char **
 
     printf("Using config file \"%s\"\n", filename);
     printf("cpupool name:   %s\n", name);
-    printf("scheduler:      %s\n", sched);
+    printf("scheduler:      %s\n", libxl_scheduler_to_string(sched));
     printf("number of cpus: %d\n", n_cpus);
 
     if (dryrun_only)
         return 0;
 
     poolid = 0;
-    if (libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid)) {
+    if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) {
         fprintf(stderr, "error on creating cpupool\n");
         return -ERROR_FAIL;
     }
@@ -5554,7 +5552,7 @@ int main_cpupoollist(int argc, char **ar
                     }
                 if (!opt_cpus) {
                     printf("%3d %9s       y       %4d", n,
-                           libxl_schedid_to_name(ctx, poolinfo[p].sched_id),
+                           libxl_scheduler_to_string(poolinfo[p].sched),
                            poolinfo[p].n_dom);
                 }
                 printf("\n");
@@ -5739,7 +5737,7 @@ int main_cpupoolnumasplit(int argc, char
     int c;
     int n;
     uint32_t poolid;
-    int schedid;
+    libxl_scheduler sched;
     int n_pools;
     int node;
     int n_cpus;
@@ -5760,7 +5758,7 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_NOMEM;
     }
     poolid = poolinfo[0].poolid;
-    schedid = poolinfo[0].sched_id;
+    sched = poolinfo[0].sched;
     for (p = 0; p < n_pools; p++) {
         libxl_cpupoolinfo_dispose(poolinfo + p);
     }
@@ -5840,7 +5838,7 @@ int main_cpupoolnumasplit(int argc, char
         snprintf(name, 15, "Pool-node%d", node);
         libxl_uuid_generate(&uuid);
         poolid = 0;
-        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid);
+        ret = -libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid);
         if (ret) {
             fprintf(stderr, "error on creating cpupool\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 Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ8-0002nw-PF; Thu, 23 Feb 2012 13:02:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nC-1y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32093 invoked from network); 23 Feb 2012 13:01:54 -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;
	23 Feb 2012 13:01:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106534"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Ak;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 773115e7c26a0ef77b1a8737361b51460515997a
Message-ID: <773115e7c26a0ef77b1a.1330002117@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 26 V3] libxl: use an explicit
 LIBXL_TIMER_MODE_DEFAULT value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 773115e7c26a0ef77b1a8737361b51460515997a
# Parent  bd8a0016da72365006cc283276f6dd9fb16f68e9
libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r bd8a0016da72 -r 773115e7c26a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -245,7 +245,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 
 typedef struct libxl__ctx libxl_ctx;
 
-#define LIBXL_TIMER_MODE_DEFAULT LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS
+#define LIBXL_TIMER_MODE_DEFAULT -1
 
 #include "_libxl_types.h"
 
diff -r bd8a0016da72 -r 773115e7c26a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -93,7 +93,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
         b_info->u.hvm.vpt_align = 1;
-        b_info->u.hvm.timer_mode = 1;
+        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
@@ -134,6 +134,10 @@ int libxl__domain_build_info_setdefault(
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
+            b_info->u.hvm.timer_mode =
+                LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ8-0002nw-PF; Thu, 23 Feb 2012 13:02:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nC-1y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32093 invoked from network); 23 Feb 2012 13:01:54 -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;
	23 Feb 2012 13:01:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106534"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Ak;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 773115e7c26a0ef77b1a8737361b51460515997a
Message-ID: <773115e7c26a0ef77b1a.1330002117@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 26 V3] libxl: use an explicit
 LIBXL_TIMER_MODE_DEFAULT value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 773115e7c26a0ef77b1a8737361b51460515997a
# Parent  bd8a0016da72365006cc283276f6dd9fb16f68e9
libxl: use an explicit LIBXL_TIMER_MODE_DEFAULT value

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r bd8a0016da72 -r 773115e7c26a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -245,7 +245,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 
 typedef struct libxl__ctx libxl_ctx;
 
-#define LIBXL_TIMER_MODE_DEFAULT LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS
+#define LIBXL_TIMER_MODE_DEFAULT -1
 
 #include "_libxl_types.h"
 
diff -r bd8a0016da72 -r 773115e7c26a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -93,7 +93,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
         b_info->u.hvm.vpt_align = 1;
-        b_info->u.hvm.timer_mode = 1;
+        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
@@ -134,6 +134,10 @@ int libxl__domain_build_info_setdefault(
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
+            b_info->u.hvm.timer_mode =
+                LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJB-0002pF-6e; Thu, 23 Feb 2012 13:02:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ9-0002nK-4h
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32473 invoked from network); 23 Feb 2012 13:01:56 -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;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106538"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-8L;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: e796677f2c76b844d46a81acbf827fcee9809b1c
Message-ID: <e796677f2c76b844d46a.1330002113@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 26 V3] libxl: generate a _dispose function
 for all Aggregate 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID e796677f2c76b844d46a81acbf827fcee9809b1c
# Parent  a706d11ed26cd0c2bc4654ff3cc95fc752a90c1b
libxl: generate a _dispose function for all Aggregate types

Don't special case types which we happen to know do not contain allocated data
such that in the future if this changes we do not need to add an API. Although
there is likely to be latent bugs in callers due to this having the API in old
libraries mean that when callers are fixed they will not need to make special
arrangements to handle old and new versions of the library.

Adds dispose functions for:
 - libxl_dominfo
 - libxl_cpupoolinfo
 - libxl_physinfo
 - libxl_sched_credit
 - libxl_sched_credit2

I have attempted to fix any latent bugs in xl by inspection but have not
bothered with libxl (on the basis that internally the library is allowed to
make these sorts of assumptions and because it was looking like a very invasive
job and that more would only creep in anyway).

Several callsites use libxl_domain_info to check for the presence of a domain
and throw away the actual info. As a convenience accept a NULL info pointer and
just return the status.

Also fix a memory leak in libxl_domain_list.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -442,6 +442,7 @@ libxl_dominfo * libxl_list_domain(libxl_
     ret = xc_domain_getinfolist(ctx->xch, 0, 1024, info);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
+        free(ptr);
         return NULL;
     }
 
@@ -464,7 +465,8 @@ int libxl_domain_info(libxl_ctx *ctx, li
     }
     if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
 
-    xcinfo2xlinfo(&xcinfo, info_r);
+    if (info_r)
+        xcinfo2xlinfo(&xcinfo, info_r);
     return 0;
 }
 
@@ -986,13 +988,12 @@ void libxl_evdisable_disk_eject(libxl_ct
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
-    libxl_dominfo dominfo;
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
 
-    rc = libxl_domain_info(ctx, &dominfo, domid);
+    rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
     case 0:
         break;
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -387,11 +387,14 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
 
+/* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
 libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
+void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
 libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
+void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 
 /*
  * Devices
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
@@ -171,7 +171,7 @@ libxl_dominfo = Struct("dominfo",[
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
     ("cpupool",     uint32),
-    ], dispose_fn=None)
+    ])
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
@@ -183,7 +183,7 @@ libxl_cpupoolinfo = Struct("cpupoolinfo"
 libxl_vminfo = Struct("vminfo", [
     ("uuid", libxl_uuid),
     ("domid", libxl_domid),
-    ], dispose_fn=None)
+    ])
 
 libxl_version_info = Struct("version_info", [
     ("xen_version_major", integer),
@@ -401,7 +401,7 @@ libxl_physinfo = Struct("physinfo", [
 
     ("cap_hvm", bool),
     ("cap_hvm_directio", bool),
-    ], dispose_fn=None, dir=DIR_OUT)
+    ], dir=DIR_OUT)
 
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
@@ -412,11 +412,11 @@ libxl_cputopology = Struct("cputopology"
 libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
-    ], dispose_fn=None)
+    ])
 
 libxl_sched_credit2 = Struct("sched_credit2", [
     ("weight", integer),
-    ], dispose_fn=None)
+    ])
 
 libxl_sched_sedf = Struct("sched_sedf", [
     ("period", integer),
@@ -424,7 +424,7 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("latency", integer),
     ("extratime", integer),
     ("weight", integer),
-    ], dispose_fn=None)
+    ])
 
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:16 2012 +0000
@@ -507,6 +507,22 @@ void libxl_cputopology_list_free(libxl_c
     free(list);
 }
 
+void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_dominfo_dispose(&list[i]);
+    free(list);
+}
+
+void libxl_vminfo_list_free(libxl_vminfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_vminfo_dispose(&list[i]);
+    free(list);
+}
+
 int libxl_domid_valid_guest(uint32_t domid)
 {
     /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -144,7 +144,6 @@ static int qualifier_to_id(const char *p
 static int domain_qualifier_to_domid(const char *p, uint32_t *domid_r,
                                      int *was_name_r)
 {
-    libxl_dominfo dominfo;
     int was_name, rc;
 
     was_name = qualifier_to_id(p, domid_r);
@@ -156,7 +155,7 @@ static int domain_qualifier_to_domid(con
         if (rc)
             return rc;
     } else {
-        rc = libxl_domain_info(ctx, &dominfo, *domid_r);
+        rc = libxl_domain_info(ctx, NULL, *domid_r);
         /* error only if domain does not exist */
         if (rc == ERROR_INVAL)
             return rc;
@@ -2500,7 +2499,7 @@ static void list_vm(void)
             info[i].domid, domname);
         free(domname);
     }
-    free(info);
+    libxl_vminfo_list_free(info, nb_vm);
 }
 
 static void save_domain_core_begin(const char *domain_spec,
@@ -3297,7 +3296,10 @@ int main_list(int argc, char **argv)
     else
         list_domains(verbose, context, info, nb_domain);
 
-    free(info_free);
+    if (info_free)
+        libxl_dominfo_list_free(info, nb_domain);
+    else
+        libxl_dominfo_dispose(info);
 
     return 0;
 }
@@ -3560,8 +3562,7 @@ static void vcpulist(int argc, char **ar
         for (i = 0; i<nb_domain; i++)
             print_domain_vcpuinfo(dominfo[i].domid, physinfo.nr_cpus);
 
-        free(dominfo);
-
+        libxl_dominfo_list_free(dominfo, nb_domain);
     } else {
         for (; argc > 0; ++argv, --argc) {
             if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
@@ -3573,7 +3574,7 @@ static void vcpulist(int argc, char **ar
         }
     }
   vcpulist_out:
-    ;
+    libxl_physinfo_dispose(&physinfo);
 }
 
 int main_vcpulist(int argc, char **argv)
@@ -3773,6 +3774,7 @@ static void output_physinfo(void)
         free(cpumap.map);
     }
 
+    libxl_physinfo_dispose(&info);
     return;
 }
 
@@ -3907,7 +3909,9 @@ int main_sharing(int argc, char **argv)
     sharing(info, nb_domain);
 
     if (info_free)
-        free(info_free);
+        libxl_dominfo_list_free(info_free, nb_domain);
+    else
+        libxl_dominfo_dispose(info);
 
     return 0;
 }
@@ -4963,6 +4967,7 @@ static void print_uptime(int short_mode,
         info = libxl_list_vm(ctx, &nb_vm);
         for (i = 0; i < nb_vm; i++)
             print_domU_uptime(info[i].domid, short_mode, now);
+        libxl_vminfo_list_free(info, nb_vm);
     } else {
         for (i = 0; i < nb_doms; i++) {
             if (doms[i] == 0)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJB-0002pF-6e; Thu, 23 Feb 2012 13:02:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ9-0002nK-4h
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32473 invoked from network); 23 Feb 2012 13:01:56 -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;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106538"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-8L;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: e796677f2c76b844d46a81acbf827fcee9809b1c
Message-ID: <e796677f2c76b844d46a.1330002113@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 26 V3] libxl: generate a _dispose function
 for all Aggregate 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID e796677f2c76b844d46a81acbf827fcee9809b1c
# Parent  a706d11ed26cd0c2bc4654ff3cc95fc752a90c1b
libxl: generate a _dispose function for all Aggregate types

Don't special case types which we happen to know do not contain allocated data
such that in the future if this changes we do not need to add an API. Although
there is likely to be latent bugs in callers due to this having the API in old
libraries mean that when callers are fixed they will not need to make special
arrangements to handle old and new versions of the library.

Adds dispose functions for:
 - libxl_dominfo
 - libxl_cpupoolinfo
 - libxl_physinfo
 - libxl_sched_credit
 - libxl_sched_credit2

I have attempted to fix any latent bugs in xl by inspection but have not
bothered with libxl (on the basis that internally the library is allowed to
make these sorts of assumptions and because it was looking like a very invasive
job and that more would only creep in anyway).

Several callsites use libxl_domain_info to check for the presence of a domain
and throw away the actual info. As a convenience accept a NULL info pointer and
just return the status.

Also fix a memory leak in libxl_domain_list.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -442,6 +442,7 @@ libxl_dominfo * libxl_list_domain(libxl_
     ret = xc_domain_getinfolist(ctx->xch, 0, 1024, info);
     if (ret<0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
+        free(ptr);
         return NULL;
     }
 
@@ -464,7 +465,8 @@ int libxl_domain_info(libxl_ctx *ctx, li
     }
     if (ret==0 || xcinfo.domain != domid) return ERROR_INVAL;
 
-    xcinfo2xlinfo(&xcinfo, info_r);
+    if (info_r)
+        xcinfo2xlinfo(&xcinfo, info_r);
     return 0;
 }
 
@@ -986,13 +988,12 @@ void libxl_evdisable_disk_eject(libxl_ct
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid)
 {
     GC_INIT(ctx);
-    libxl_dominfo dominfo;
     char *dom_path;
     char *vm_path;
     char *pid;
     int rc, dm_present;
 
-    rc = libxl_domain_info(ctx, &dominfo, domid);
+    rc = libxl_domain_info(ctx, NULL, domid);
     switch(rc) {
     case 0:
         break;
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -387,11 +387,14 @@ int libxl_console_exec(libxl_ctx *ctx, u
  * guests using pygrub. */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
 
+/* May be called with info_r == NULL to check for domain's existance */
 int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
                       uint32_t domid);
 libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain);
+void libxl_dominfo_list_free(libxl_dominfo *list, int nr);
 libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool);
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
+void libxl_vminfo_list_free(libxl_vminfo *list, int nr);
 
 /*
  * Devices
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
@@ -171,7 +171,7 @@ libxl_dominfo = Struct("dominfo",[
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
     ("cpupool",     uint32),
-    ], dispose_fn=None)
+    ])
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
@@ -183,7 +183,7 @@ libxl_cpupoolinfo = Struct("cpupoolinfo"
 libxl_vminfo = Struct("vminfo", [
     ("uuid", libxl_uuid),
     ("domid", libxl_domid),
-    ], dispose_fn=None)
+    ])
 
 libxl_version_info = Struct("version_info", [
     ("xen_version_major", integer),
@@ -401,7 +401,7 @@ libxl_physinfo = Struct("physinfo", [
 
     ("cap_hvm", bool),
     ("cap_hvm_directio", bool),
-    ], dispose_fn=None, dir=DIR_OUT)
+    ], dir=DIR_OUT)
 
 libxl_cputopology = Struct("cputopology", [
     ("core", uint32),
@@ -412,11 +412,11 @@ libxl_cputopology = Struct("cputopology"
 libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
-    ], dispose_fn=None)
+    ])
 
 libxl_sched_credit2 = Struct("sched_credit2", [
     ("weight", integer),
-    ], dispose_fn=None)
+    ])
 
 libxl_sched_sedf = Struct("sched_sedf", [
     ("period", integer),
@@ -424,7 +424,7 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("latency", integer),
     ("extratime", integer),
     ("weight", integer),
-    ], dispose_fn=None)
+    ])
 
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:16 2012 +0000
@@ -507,6 +507,22 @@ void libxl_cputopology_list_free(libxl_c
     free(list);
 }
 
+void libxl_dominfo_list_free(libxl_dominfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_dominfo_dispose(&list[i]);
+    free(list);
+}
+
+void libxl_vminfo_list_free(libxl_vminfo *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_vminfo_dispose(&list[i]);
+    free(list);
+}
+
 int libxl_domid_valid_guest(uint32_t domid)
 {
     /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
diff -r a706d11ed26c -r e796677f2c76 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -144,7 +144,6 @@ static int qualifier_to_id(const char *p
 static int domain_qualifier_to_domid(const char *p, uint32_t *domid_r,
                                      int *was_name_r)
 {
-    libxl_dominfo dominfo;
     int was_name, rc;
 
     was_name = qualifier_to_id(p, domid_r);
@@ -156,7 +155,7 @@ static int domain_qualifier_to_domid(con
         if (rc)
             return rc;
     } else {
-        rc = libxl_domain_info(ctx, &dominfo, *domid_r);
+        rc = libxl_domain_info(ctx, NULL, *domid_r);
         /* error only if domain does not exist */
         if (rc == ERROR_INVAL)
             return rc;
@@ -2500,7 +2499,7 @@ static void list_vm(void)
             info[i].domid, domname);
         free(domname);
     }
-    free(info);
+    libxl_vminfo_list_free(info, nb_vm);
 }
 
 static void save_domain_core_begin(const char *domain_spec,
@@ -3297,7 +3296,10 @@ int main_list(int argc, char **argv)
     else
         list_domains(verbose, context, info, nb_domain);
 
-    free(info_free);
+    if (info_free)
+        libxl_dominfo_list_free(info, nb_domain);
+    else
+        libxl_dominfo_dispose(info);
 
     return 0;
 }
@@ -3560,8 +3562,7 @@ static void vcpulist(int argc, char **ar
         for (i = 0; i<nb_domain; i++)
             print_domain_vcpuinfo(dominfo[i].domid, physinfo.nr_cpus);
 
-        free(dominfo);
-
+        libxl_dominfo_list_free(dominfo, nb_domain);
     } else {
         for (; argc > 0; ++argv, --argc) {
             if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
@@ -3573,7 +3574,7 @@ static void vcpulist(int argc, char **ar
         }
     }
   vcpulist_out:
-    ;
+    libxl_physinfo_dispose(&physinfo);
 }
 
 int main_vcpulist(int argc, char **argv)
@@ -3773,6 +3774,7 @@ static void output_physinfo(void)
         free(cpumap.map);
     }
 
+    libxl_physinfo_dispose(&info);
     return;
 }
 
@@ -3907,7 +3909,9 @@ int main_sharing(int argc, char **argv)
     sharing(info, nb_domain);
 
     if (info_free)
-        free(info_free);
+        libxl_dominfo_list_free(info_free, nb_domain);
+    else
+        libxl_dominfo_dispose(info);
 
     return 0;
 }
@@ -4963,6 +4967,7 @@ static void print_uptime(int short_mode,
         info = libxl_list_vm(ctx, &nb_vm);
         for (i = 0; i < nb_vm; i++)
             print_domU_uptime(info[i].domid, short_mode, now);
+        libxl_vminfo_list_free(info, nb_vm);
     } else {
         for (i = 0; i < nb_doms; i++) {
             if (doms[i] == 0)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJA-0002oa-82; Thu, 23 Feb 2012 13:02:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ8-0002nH-9L
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330002114!16109653!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26386 invoked from network); 23 Feb 2012 13:01:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374118"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-8w;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: b218d889232a922085e7e9edc50c369e50a4958e
Message-ID: <b218d889232a922085e7.1330002114@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 26 V3] libxl: Document
 _init/_dispose/_setdefault 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 1330000276 0
# Node ID b218d889232a922085e7e9edc50c369e50a4958e
# Parent  e796677f2c76b844d46a81acbf827fcee9809b1c
libxl: Document _init/_dispose/_setdefault functions.

Subsequent patches will transition to them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e796677f2c76 -r b218d889232a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -124,6 +124,50 @@
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
  */
+/*
+ * libxl types
+ *
+ * Most libxl types are defined by the libxl IDL (see
+ * libxl_types.idl). The library provides a common set of methods for
+ * initialising and freeing these types.
+ *
+ * void libxl_<type>_init(<type> *p):
+ *
+ *    Initialises the members of "p" to all defaults. These may either
+ *    be special value which indicates to the library that it should
+ *    select an appropriate default when using this field or actual
+ *    default values.
+ *
+ *    Some fields within a data type (e.g. unions) cannot be sensibly
+ *    initialised without further information. In these cases a
+ *    separate subfield initialisation function is provided (see
+ *    below).
+ *
+ *    An instance which has been initialised using this method can
+ *    always be safely passed to the dispose function (see
+ *    below). This is true even if the data type contains fields which
+ *    require a separate call to a subfield initialisation function.
+ *
+ *    This method is provided for any aggregate type which is used as
+ *    an input parameter.
+ *
+ * void libxl_<type>_init_<subfield>(<type> *p, subfield):
+ *
+ *    Initialise those parts of "p" which are not initialised by the
+ *    main init function due to the unknown value of "subfield". Sets
+ *    p->subfield as well as initialising any fields to their default
+ *    values.
+ *
+ *    p->subfield must not have been previously initialised.
+ *
+ *    This method is provided for any aggregate type.
+ *
+ * void libxl_<type>_dispose(instance *p):
+ *
+ *    Frees any dynamically allocated memory used by the members of
+ *    "p" but not the storage used by "p" itself (this allows for the
+ *    allocation of arrays of types and for the composition of types).
+ */
 #ifndef LIBXL_H
 #define LIBXL_H
 
@@ -405,8 +449,9 @@ void libxl_vminfo_list_free(libxl_vminfo
  * additional data type libxl_device_<TYPE>_getinfo which contains
  * further runtime information about the device.
  *
- * A common set of methods are available for each device type. These
- * are described below.
+ * In addition to the general methods available for libxl types (see
+ * "libxl types" above) a common set of methods are available for each
+ * device type. These are described below.
  *
  * Querying
  * --------
@@ -424,10 +469,6 @@ void libxl_vminfo_list_free(libxl_vminfo
  * Creation / Control
  * ------------------
  *
- * libxl_device_<type>_init(ctx, device):
- *
- *    Initalises device to a default configuration.
- *
  * libxl_device_<type>_add(ctx, domid, device):
  *
  *   Adds the given device to the specified domain. This can be called
diff -r e796677f2c76 -r b218d889232a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -665,6 +665,19 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * For each aggregate type which can be used as an input we provide:
+ *
+ * int libxl__<type>_setdefault(gc, <type> *p):
+ *
+ *     Idempotently sets any members of "p" which is currently set to
+ *     a special value indicating that the defaults should be used
+ *     (per libxl_<type>_init) to a specific value.
+ *
+ *     All libxl API functions are expected to have arranged for this
+ *     to be called before using any values within these structures.
+ */
+
 /* Arranges that dev will be removed from its guest.  When
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ9-0002oL-SX; Thu, 23 Feb 2012 13:02:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nG-Tn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330002113!14579791!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20075 invoked from network); 23 Feb 2012 13:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374117"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-7k;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: a706d11ed26cd0c2bc4654ff3cc95fc752a90c1b
Message-ID: <a706d11ed26cd0c2bc46.1330002112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 26 V3] libxl: allow specification of
	testidl random seed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID a706d11ed26cd0c2bc4654ff3cc95fc752a90c1b
# Parent  67349816c1ccec5d2e665c1dde956d1d38b10f9f
libxl: allow specification of testidl random seed.

Useful if you are interested in before/after results of changing the IDL or
generator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 67349816c1cc -r a706d11ed26c tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
@@ -1,5 +1,6 @@
 #!/usr/bin/python
 
+import os
 import sys
 import re
 import random
@@ -72,7 +73,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: gentest.py <idl> <implementation>"
         sys.exit(1)
 
-    random.seed()
+    random.seed(os.getenv('LIBXL_TESTIDL_SEED'))
 
     (builtins,types) = idl.parse(sys.argv[1])
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJA-0002oa-82; Thu, 23 Feb 2012 13:02:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ8-0002nH-9L
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330002114!16109653!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26386 invoked from network); 23 Feb 2012 13:01:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374118"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-8w;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: b218d889232a922085e7e9edc50c369e50a4958e
Message-ID: <b218d889232a922085e7.1330002114@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 26 V3] libxl: Document
 _init/_dispose/_setdefault 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 1330000276 0
# Node ID b218d889232a922085e7e9edc50c369e50a4958e
# Parent  e796677f2c76b844d46a81acbf827fcee9809b1c
libxl: Document _init/_dispose/_setdefault functions.

Subsequent patches will transition to them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e796677f2c76 -r b218d889232a tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -124,6 +124,50 @@
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
  */
+/*
+ * libxl types
+ *
+ * Most libxl types are defined by the libxl IDL (see
+ * libxl_types.idl). The library provides a common set of methods for
+ * initialising and freeing these types.
+ *
+ * void libxl_<type>_init(<type> *p):
+ *
+ *    Initialises the members of "p" to all defaults. These may either
+ *    be special value which indicates to the library that it should
+ *    select an appropriate default when using this field or actual
+ *    default values.
+ *
+ *    Some fields within a data type (e.g. unions) cannot be sensibly
+ *    initialised without further information. In these cases a
+ *    separate subfield initialisation function is provided (see
+ *    below).
+ *
+ *    An instance which has been initialised using this method can
+ *    always be safely passed to the dispose function (see
+ *    below). This is true even if the data type contains fields which
+ *    require a separate call to a subfield initialisation function.
+ *
+ *    This method is provided for any aggregate type which is used as
+ *    an input parameter.
+ *
+ * void libxl_<type>_init_<subfield>(<type> *p, subfield):
+ *
+ *    Initialise those parts of "p" which are not initialised by the
+ *    main init function due to the unknown value of "subfield". Sets
+ *    p->subfield as well as initialising any fields to their default
+ *    values.
+ *
+ *    p->subfield must not have been previously initialised.
+ *
+ *    This method is provided for any aggregate type.
+ *
+ * void libxl_<type>_dispose(instance *p):
+ *
+ *    Frees any dynamically allocated memory used by the members of
+ *    "p" but not the storage used by "p" itself (this allows for the
+ *    allocation of arrays of types and for the composition of types).
+ */
 #ifndef LIBXL_H
 #define LIBXL_H
 
@@ -405,8 +449,9 @@ void libxl_vminfo_list_free(libxl_vminfo
  * additional data type libxl_device_<TYPE>_getinfo which contains
  * further runtime information about the device.
  *
- * A common set of methods are available for each device type. These
- * are described below.
+ * In addition to the general methods available for libxl types (see
+ * "libxl types" above) a common set of methods are available for each
+ * device type. These are described below.
  *
  * Querying
  * --------
@@ -424,10 +469,6 @@ void libxl_vminfo_list_free(libxl_vminfo
  * Creation / Control
  * ------------------
  *
- * libxl_device_<type>_init(ctx, device):
- *
- *    Initalises device to a default configuration.
- *
  * libxl_device_<type>_add(ctx, domid, device):
  *
  *   Adds the given device to the specified domain. This can be called
diff -r e796677f2c76 -r b218d889232a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -665,6 +665,19 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * For each aggregate type which can be used as an input we provide:
+ *
+ * int libxl__<type>_setdefault(gc, <type> *p):
+ *
+ *     Idempotently sets any members of "p" which is currently set to
+ *     a special value indicating that the defaults should be used
+ *     (per libxl_<type>_init) to a specific value.
+ *
+ *     All libxl API functions are expected to have arranged for this
+ *     to be called before using any values within these structures.
+ */
+
 /* Arranges that dev will be removed from its guest.  When
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ9-0002oL-SX; Thu, 23 Feb 2012 13:02:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nG-Tn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330002113!14579791!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20075 invoked from network); 23 Feb 2012 13:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374117"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-7k;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: a706d11ed26cd0c2bc4654ff3cc95fc752a90c1b
Message-ID: <a706d11ed26cd0c2bc46.1330002112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 26 V3] libxl: allow specification of
	testidl random seed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID a706d11ed26cd0c2bc4654ff3cc95fc752a90c1b
# Parent  67349816c1ccec5d2e665c1dde956d1d38b10f9f
libxl: allow specification of testidl random seed.

Useful if you are interested in before/after results of changing the IDL or
generator.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 67349816c1cc -r a706d11ed26c tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
@@ -1,5 +1,6 @@
 #!/usr/bin/python
 
+import os
 import sys
 import re
 import random
@@ -72,7 +73,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: gentest.py <idl> <implementation>"
         sys.exit(1)
 
-    random.seed()
+    random.seed(os.getenv('LIBXL_TESTIDL_SEED'))
 
     (builtins,types) = idl.parse(sys.argv[1])
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ9-0002oB-Gj; Thu, 23 Feb 2012 13:02:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nF-RY
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32406 invoked from network); 23 Feb 2012 13:01:55 -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;
	23 Feb 2012 13:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106533"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-9W;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8052126f50e2dae878ad227a3f0e45cec193c19f
Message-ID: <8052126f50e2dae878ad.1330002115@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 26 V3] libxl: provide _init and
 _setdefault for libxl_domain_create_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 8052126f50e2dae878ad227a3f0e45cec193c19f
# Parent  b218d889232a922085e7e9edc50c369e50a4958e
libxl: provide _init and _setdefault for libxl_domain_create_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

It doesn't seem reasonable for the library to pick a default for the domain
type so reject as invalid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -356,7 +356,7 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -50,16 +50,19 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->xsdata = NULL;
-    c_info->platformdata = NULL;
     c_info->hap = 1;
-    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
     c_info->oos = 1;
-    c_info->ssidref = 0;
-    c_info->poolid = 0;
+}
+
+int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                         libxl_domain_create_info *c_info)
+{
+    if (!c_info->type)
+        return ERROR_INVAL;
+
     return 0;
 }
 
@@ -469,6 +472,9 @@ static int do_domain_create(libxl__gc *g
 
     domid = 0;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
@@ -703,7 +703,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    libxl_domain_create_info_init(&dm_config.c_info);
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
@@ -738,6 +738,9 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    if (ret) goto out;
+
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -187,6 +187,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  * version of the _evdisable_FOO function; the internal one is
  * used during cleanup.
  */
+_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_create_info *c_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r b218d889232a -r 8052126f50e2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -536,8 +536,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_create_info(ctx, c_info))
-        exit(1);
+    libxl_domain_create_info_init(c_info);
 
     if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ9-0002oB-Gj; Thu, 23 Feb 2012 13:02:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nF-RY
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32406 invoked from network); 23 Feb 2012 13:01:55 -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;
	23 Feb 2012 13:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106533"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-9W;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8052126f50e2dae878ad227a3f0e45cec193c19f
Message-ID: <8052126f50e2dae878ad.1330002115@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 26 V3] libxl: provide _init and
 _setdefault for libxl_domain_create_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 8052126f50e2dae878ad227a3f0e45cec193c19f
# Parent  b218d889232a922085e7e9edc50c369e50a4958e
libxl: provide _init and _setdefault for libxl_domain_create_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

It doesn't seem reasonable for the library to pick a default for the domain
type so reject as invalid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -356,7 +356,7 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -50,16 +50,19 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
+void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->xsdata = NULL;
-    c_info->platformdata = NULL;
     c_info->hap = 1;
-    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
     c_info->oos = 1;
-    c_info->ssidref = 0;
-    c_info->poolid = 0;
+}
+
+int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                         libxl_domain_create_info *c_info)
+{
+    if (!c_info->type)
+        return ERROR_INVAL;
+
     return 0;
 }
 
@@ -469,6 +472,9 @@ static int do_domain_create(libxl__gc *g
 
     domid = 0;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
@@ -703,7 +703,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    libxl_domain_create_info_init(&dm_config.c_info);
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
@@ -738,6 +738,9 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
+    ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
+    if (ret) goto out;
+
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
diff -r b218d889232a -r 8052126f50e2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -187,6 +187,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  * version of the _evdisable_FOO function; the internal one is
  * used during cleanup.
  */
+_hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_create_info *c_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r b218d889232a -r 8052126f50e2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -536,8 +536,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_create_info(ctx, c_info))
-        exit(1);
+    libxl_domain_create_info_init(c_info);
 
     if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJB-0002pS-LF; Thu, 23 Feb 2012 13:02:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ9-0002nL-PR
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330002115!15540727!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11974 invoked from network); 23 Feb 2012 13:01:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106539"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-A5;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: bd8a0016da72365006cc283276f6dd9fb16f68e9
Message-ID: <bd8a0016da72365006cc.1330002116@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 26 V3] libxl: provide _init and
 _setdefault for libxl_domain_build_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID bd8a0016da72365006cc283276f6dd9fb16f68e9
# Parent  8052126f50e2dae878ad227a3f0e45cec193c19f
libxl: provide _init and _setdefault for libxl_domain_build_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -2625,7 +2625,11 @@ int libxl_domain_need_memory(libxl_ctx *
                              uint32_t *need_memkb)
 {
     GC_INIT(ctx);
-    int rc = ERROR_INVAL;
+    int rc;
+
+    rc = libxl__domain_build_info_setdefault(gc, b_info);
+    if (rc) goto out;
+
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -2637,6 +2641,7 @@ int libxl_domain_need_memory(libxl_ctx *
         *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
         break;
     default:
+        rc = ERROR_INVAL;
         goto out;
     }
     if (*need_memkb % (2 * 1024))
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -357,9 +357,8 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                          const libxl_domain_create_info *c_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:16 2012 +0000
@@ -346,6 +346,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     struct stat st_buf;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -66,16 +66,10 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                                  const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_vcpus = 1;
-    b_info->cur_vcpus = 1;
-    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
-        return ERROR_NOMEM;
-    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
@@ -83,8 +77,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
-    b_info->device_model_version =
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
@@ -107,15 +99,9 @@ int libxl_init_build_info(libxl_ctx *ctx
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
-        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
-        b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.sdl.enable = 0;
-        b_info->u.hvm.sdl.opengl = 0;
-        b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.boot = strdup("cda");
         b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
         b_info->u.hvm.xen_platform_pci = 1;
@@ -124,7 +110,47 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.pv.slack_memkb = 8 * 1024;
         break;
     default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+        abort();
+    }
+}
+
+int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info)
+{
+    if (!b_info->device_model_version)
+        b_info->device_model_version =
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+    if (!b_info->max_vcpus)
+        b_info->max_vcpus = 1;
+    if (!b_info->cur_vcpus)
+        b_info->cur_vcpus = 1;
+
+    if (!b_info->cpumap.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
+            return ERROR_NOMEM;
+        libxl_cpumap_set_any(&b_info->cpumap);
+    }
+
+    switch (b_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        if (!b_info->u.hvm.boot) {
+            b_info->u.hvm.boot = strdup("cda");
+            if (!b_info->u.hvm.boot) return ERROR_NOMEM;
+        }
+
+        if (b_info->u.hvm.vnc.enable) {
+            if (!b_info->u.hvm.vnc.listen) {
+                b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+                if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
+            }
+        }
+
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        break;
+    default:
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                    "invalid domain type %s in create info",
                    libxl_domain_type_to_string(b_info->type));
         return ERROR_INVAL;
@@ -487,6 +513,8 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
+    if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
@@ -711,13 +711,12 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
-    dm_config.b_info.type = dm_config.c_info.type;
+    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
-    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
@@ -740,6 +739,8 @@ static int libxl__create_stubdom(libxl__
 
     ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
     if (ret) goto out;
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -189,6 +189,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  */
 _hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                         libxl_domain_create_info *c_info);
+_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -585,8 +585,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_build_info(ctx, b_info, c_info))
-        exit(1);
+    libxl_domain_build_info_init(b_info, c_info);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -600,6 +599,11 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
@@ -614,6 +618,11 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         if (vcpupin_parse(buf2, &b_info->cpumap))
             exit(1);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJB-0002pS-LF; Thu, 23 Feb 2012 13:02:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ9-0002nL-PR
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330002115!15540727!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11974 invoked from network); 23 Feb 2012 13:01:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106539"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-A5;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: bd8a0016da72365006cc283276f6dd9fb16f68e9
Message-ID: <bd8a0016da72365006cc.1330002116@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 26 V3] libxl: provide _init and
 _setdefault for libxl_domain_build_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID bd8a0016da72365006cc283276f6dd9fb16f68e9
# Parent  8052126f50e2dae878ad227a3f0e45cec193c19f
libxl: provide _init and _setdefault for libxl_domain_build_info.

Some fields require further scaffolding before they can use the
_init/_setdefault scheme and are handled in later patches.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -2625,7 +2625,11 @@ int libxl_domain_need_memory(libxl_ctx *
                              uint32_t *need_memkb)
 {
     GC_INIT(ctx);
-    int rc = ERROR_INVAL;
+    int rc;
+
+    rc = libxl__domain_build_info_setdefault(gc, b_info);
+    if (rc) goto out;
+
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -2637,6 +2641,7 @@ int libxl_domain_need_memory(libxl_ctx *
         *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
         break;
     default:
+        rc = ERROR_INVAL;
         goto out;
     }
     if (*need_memkb % (2 * 1024))
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -357,9 +357,8 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                          const libxl_domain_create_info *c_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:16 2012 +0000
@@ -346,6 +346,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
     struct stat st_buf;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -66,16 +66,10 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-int libxl_init_build_info(libxl_ctx *ctx,
-                          libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
+                                  const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_vcpus = 1;
-    b_info->cur_vcpus = 1;
-    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
-        return ERROR_NOMEM;
-    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
@@ -83,8 +77,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
-    b_info->device_model_version =
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
@@ -107,15 +99,9 @@ int libxl_init_build_info(libxl_ctx *ctx
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
-        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
-        b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.sdl.enable = 0;
-        b_info->u.hvm.sdl.opengl = 0;
-        b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.boot = strdup("cda");
         b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
         b_info->u.hvm.xen_platform_pci = 1;
@@ -124,7 +110,47 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.pv.slack_memkb = 8 * 1024;
         break;
     default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+        abort();
+    }
+}
+
+int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info)
+{
+    if (!b_info->device_model_version)
+        b_info->device_model_version =
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+    if (!b_info->max_vcpus)
+        b_info->max_vcpus = 1;
+    if (!b_info->cur_vcpus)
+        b_info->cur_vcpus = 1;
+
+    if (!b_info->cpumap.size) {
+        if (libxl_cpumap_alloc(CTX, &b_info->cpumap))
+            return ERROR_NOMEM;
+        libxl_cpumap_set_any(&b_info->cpumap);
+    }
+
+    switch (b_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        if (!b_info->u.hvm.boot) {
+            b_info->u.hvm.boot = strdup("cda");
+            if (!b_info->u.hvm.boot) return ERROR_NOMEM;
+        }
+
+        if (b_info->u.hvm.vnc.enable) {
+            if (!b_info->u.hvm.vnc.listen) {
+                b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+                if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
+            }
+        }
+
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        break;
+    default:
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                    "invalid domain type %s in create info",
                    libxl_domain_type_to_string(b_info->type));
         return ERROR_INVAL;
@@ -487,6 +513,8 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info);
+    if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
@@ -711,13 +711,12 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
-    dm_config.b_info.type = dm_config.c_info.type;
+    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
-    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
@@ -740,6 +739,8 @@ static int libxl__create_stubdom(libxl__
 
     ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info);
     if (ret) goto out;
+    ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info);
+    if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -189,6 +189,8 @@ libxl__ev_xswatch *libxl__watch_slot_con
  */
 _hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                         libxl_domain_create_info *c_info);
+_hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
+                                        libxl_domain_build_info *b_info);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 8052126f50e2 -r bd8a0016da72 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -585,8 +585,7 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    if (libxl_init_build_info(ctx, b_info, c_info))
-        exit(1);
+    libxl_domain_build_info_init(b_info, c_info);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -600,6 +599,11 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
         int i, n_cpus = 0;
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
             i = atoi(buf);
@@ -614,6 +618,11 @@ static void parse_config_data(const char
     else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
         char *buf2 = strdup(buf);
 
+        if (libxl_cpumap_alloc(ctx, &b_info->cpumap)) {
+            fprintf(stderr, "Unable to allocate cpumap\n");
+            exit(1);
+        }
+
         libxl_cpumap_set_none(&b_info->cpumap);
         if (vcpupin_parse(buf2, &b_info->cpumap))
             exit(1);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJA-0002or-L0; Thu, 23 Feb 2012 13:02:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ8-0002nI-Bv
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32450 invoked from network); 23 Feb 2012 13:01:56 -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;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106536"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-BM;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4126474b72b57433538374ece5da684f594217a1
Message-ID: <4126474b72b574335383.1330002118@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 26 V3] libxl: drop 8M slack for PV 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 4126474b72b57433538374ece5da684f594217a1
# Parent  773115e7c26a0ef77b1a8737361b51460515997a
libxl: drop 8M slack for PV guests.

This serves no purpose. It relates to the old 8M to "account for backend
allocations" which we used to add. This leaves a bit of unpopulated space in
the Pseudo-physical address space which can be used by backends when mapping
foreign memory. However 8M is not representative of that any more and modern
kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets just set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 773115e7c26a -r 4126474b72b5 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -107,7 +107,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
+        b_info->u.pv.slack_memkb = 0;
         break;
     default:
         abort();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ9-0002o3-4s; Thu, 23 Feb 2012 13:02:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nE-M7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330002113!14579791!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19971 invoked from network); 23 Feb 2012 13:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374116"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-7A;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 67349816c1ccec5d2e665c1dde956d1d38b10f9f
Message-ID: <67349816c1ccec5d2e66.1330002111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 26 V3] libxl: Remove xen/sched.h from
	public 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 67349816c1ccec5d2e665c1dde956d1d38b10f9f
# Parent  d3332d3bc6fbf50aa2054f2f458afa4cf1232377
libxl: Remove xen/sched.h from public interface

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -137,8 +137,6 @@
 
 #include <xentoollog.h>
 
-#include <xen/sched.h>
-
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
 
@@ -638,12 +636,7 @@ int libxl_cpupool_cpuremove(libxl_ctx *c
 int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
 
-static inline int libxl_domid_valid_guest(uint32_t domid)
-{
-    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
-     * does not check whether the domain actually exists */
-    return domid > 0 && domid < DOMID_FIRST_RESERVED;
-}
+int libxl_domid_valid_guest(uint32_t domid);
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
                                uint32_t *ssidref);
diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
@@ -107,6 +107,15 @@ libxl_scheduler = Enumeration("scheduler
     (7, "arinc653"),
     ])
 
+# Consistent with SHUTDOWN_* in sched.h
+libxl_shutdown_reason = Enumeration("shutdown_reason", [
+    (0, "poweroff"),
+    (1, "reboot"),
+    (2, "suspend"),
+    (3, "crash"),
+    (4, "watchdog"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -150,11 +159,11 @@ libxl_dominfo = Struct("dominfo",[
     ("shutdown",    bool),
     ("dying",       bool),
 
-    # Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+    # Valid iff (shutdown||dying).
     #
     # Otherwise set to a value guaranteed not to clash with any valid
-    # SHUTDOWN_* constant.
-    ("shutdown_reason", uint8),
+    # LIBXL_SHUTDOWN_REASON_* constant.
+    ("shutdown_reason", libxl_shutdown_reason),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:16 2012 +0000
@@ -507,6 +507,13 @@ void libxl_cputopology_list_free(libxl_c
     free(list);
 }
 
+int libxl_domid_valid_guest(uint32_t domid)
+{
+    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
+     * does not check whether the domain actually exists */
+    return domid > 0 && domid < DOMID_FIRST_RESERVED;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -1230,19 +1230,19 @@ static int handle_domain_death(libxl_ctx
     libxl_action_on_shutdown action;
 
     switch (event->u.domain_shutdown.shutdown_reason) {
-    case SHUTDOWN_poweroff:
+    case LIBXL_SHUTDOWN_REASON_POWEROFF:
         action = d_config->on_poweroff;
         break;
-    case SHUTDOWN_reboot:
+    case LIBXL_SHUTDOWN_REASON_REBOOT:
         action = d_config->on_reboot;
         break;
-    case SHUTDOWN_suspend:
+    case LIBXL_SHUTDOWN_REASON_SUSPEND:
         LOG("Domain has suspended.");
         return 0;
-    case SHUTDOWN_crash:
+    case LIBXL_SHUTDOWN_REASON_CRASH:
         action = d_config->on_crash;
         break;
-    case SHUTDOWN_watchdog:
+    case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
     default:
diff -r d3332d3bc6fb -r 67349816c1cc tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -762,11 +762,11 @@ PyMODINIT_FUNC initxl(void)
     Py_INCREF(xl_error_obj);
     PyModule_AddObject(m, "Error", xl_error_obj);
 
-    _INT_CONST(m, SHUTDOWN_poweroff);
-    _INT_CONST(m, SHUTDOWN_reboot);
-    _INT_CONST(m, SHUTDOWN_suspend);
-    _INT_CONST(m, SHUTDOWN_crash);
-    _INT_CONST(m, SHUTDOWN_watchdog);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_POWEROFF);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_REBOOT);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
 
     genwrap__init(m);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJA-0002or-L0; Thu, 23 Feb 2012 13:02:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ8-0002nI-Bv
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330002113!15787040!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32450 invoked from network); 23 Feb 2012 13:01:56 -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;
	23 Feb 2012 13:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183106536"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:53 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-BM;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4126474b72b57433538374ece5da684f594217a1
Message-ID: <4126474b72b574335383.1330002118@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 26 V3] libxl: drop 8M slack for PV 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 4126474b72b57433538374ece5da684f594217a1
# Parent  773115e7c26a0ef77b1a8737361b51460515997a
libxl: drop 8M slack for PV guests.

This serves no purpose. It relates to the old 8M to "account for backend
allocations" which we used to add. This leaves a bit of unpopulated space in
the Pseudo-physical address space which can be used by backends when mapping
foreign memory. However 8M is not representative of that any more and modern
kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets just set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 773115e7c26a -r 4126474b72b5 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -107,7 +107,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
+        b_info->u.pv.slack_memkb = 0;
         break;
     default:
         abort();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:02:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YJ9-0002o3-4s; Thu, 23 Feb 2012 13:02:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YJ7-0002nE-M7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330002113!14579791!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19971 invoked from network); 23 Feb 2012 13:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374116"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:01:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:01:52 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-7A;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 67349816c1ccec5d2e665c1dde956d1d38b10f9f
Message-ID: <67349816c1ccec5d2e66.1330002111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 26 V3] libxl: Remove xen/sched.h from
	public 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000276 0
# Node ID 67349816c1ccec5d2e665c1dde956d1d38b10f9f
# Parent  d3332d3bc6fbf50aa2054f2f458afa4cf1232377
libxl: Remove xen/sched.h from public interface

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -137,8 +137,6 @@
 
 #include <xentoollog.h>
 
-#include <xen/sched.h>
-
 #include <libxl_uuid.h>
 #include <_libxl_list.h>
 
@@ -638,12 +636,7 @@ int libxl_cpupool_cpuremove(libxl_ctx *c
 int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus);
 int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid);
 
-static inline int libxl_domid_valid_guest(uint32_t domid)
-{
-    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
-     * does not check whether the domain actually exists */
-    return domid > 0 && domid < DOMID_FIRST_RESERVED;
-}
+int libxl_domid_valid_guest(uint32_t domid);
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
                                uint32_t *ssidref);
diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
@@ -107,6 +107,15 @@ libxl_scheduler = Enumeration("scheduler
     (7, "arinc653"),
     ])
 
+# Consistent with SHUTDOWN_* in sched.h
+libxl_shutdown_reason = Enumeration("shutdown_reason", [
+    (0, "poweroff"),
+    (1, "reboot"),
+    (2, "suspend"),
+    (3, "crash"),
+    (4, "watchdog"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -150,11 +159,11 @@ libxl_dominfo = Struct("dominfo",[
     ("shutdown",    bool),
     ("dying",       bool),
 
-    # Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+    # Valid iff (shutdown||dying).
     #
     # Otherwise set to a value guaranteed not to clash with any valid
-    # SHUTDOWN_* constant.
-    ("shutdown_reason", uint8),
+    # LIBXL_SHUTDOWN_REASON_* constant.
+    ("shutdown_reason", libxl_shutdown_reason),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Thu Feb 23 12:31:16 2012 +0000
@@ -507,6 +507,13 @@ void libxl_cputopology_list_free(libxl_c
     free(list);
 }
 
+int libxl_domid_valid_guest(uint32_t domid)
+{
+    /* returns 1 if the value _could_ be a valid guest domid, 0 otherwise
+     * does not check whether the domain actually exists */
+    return domid > 0 && domid < DOMID_FIRST_RESERVED;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r d3332d3bc6fb -r 67349816c1cc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -1230,19 +1230,19 @@ static int handle_domain_death(libxl_ctx
     libxl_action_on_shutdown action;
 
     switch (event->u.domain_shutdown.shutdown_reason) {
-    case SHUTDOWN_poweroff:
+    case LIBXL_SHUTDOWN_REASON_POWEROFF:
         action = d_config->on_poweroff;
         break;
-    case SHUTDOWN_reboot:
+    case LIBXL_SHUTDOWN_REASON_REBOOT:
         action = d_config->on_reboot;
         break;
-    case SHUTDOWN_suspend:
+    case LIBXL_SHUTDOWN_REASON_SUSPEND:
         LOG("Domain has suspended.");
         return 0;
-    case SHUTDOWN_crash:
+    case LIBXL_SHUTDOWN_REASON_CRASH:
         action = d_config->on_crash;
         break;
-    case SHUTDOWN_watchdog:
+    case LIBXL_SHUTDOWN_REASON_WATCHDOG:
         action = d_config->on_watchdog;
         break;
     default:
diff -r d3332d3bc6fb -r 67349816c1cc tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:15 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -762,11 +762,11 @@ PyMODINIT_FUNC initxl(void)
     Py_INCREF(xl_error_obj);
     PyModule_AddObject(m, "Error", xl_error_obj);
 
-    _INT_CONST(m, SHUTDOWN_poweroff);
-    _INT_CONST(m, SHUTDOWN_reboot);
-    _INT_CONST(m, SHUTDOWN_suspend);
-    _INT_CONST(m, SHUTDOWN_crash);
-    _INT_CONST(m, SHUTDOWN_watchdog);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_POWEROFF);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_REBOOT);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
+    _INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
 
     genwrap__init(m);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:14:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YUW-0004HX-IT; Thu, 23 Feb 2012 13:13:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0YUV-0004HP-7j
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:13:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330002820!10250813!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27873 invoked from network); 23 Feb 2012 13:13:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Feb 2012 13:13:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330002820; l=879;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6i71Quyn7j87xLpxogwMiwhvfWI=;
	b=Q40LTfKvd372wH8a9xRWz8sFQixV6GDjTshs5M+37EDzO26PcG79uRMdfuSYUKDpSaR
	1VfEb0L++/MGZnFuCf0VOkQN2GZ0ZzS1M/8oQbRgcnReHRe2y00rZzRKh1lCsurA+gWvq
	hABRp82Yx/sRB83vB0PYFN+IPkSguX9eCKI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by post.strato.de (mrclete mo13) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y04e76o1NCYAB2 ;
	Thu, 23 Feb 2012 14:13:22 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2574B18638; Thu, 23 Feb 2012 14:13:20 +0100 (CET)
Date: Thu, 23 Feb 2012 14:13:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@entel.upc.edu>
Message-ID: <20120223131320.GA12900@aepfle.de>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCBGZWIgMjMsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cgo+IDIwMTIvMi8yMiBDaHJp
c3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPiA+IE9uIDAyLzIyLzEyIDEw
OjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ID4+Cj4gPj4gMjAxMi8yLzIyIENocmlzdG9w
aCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4gPj4+Cj4gPj4+Cj4gPj4+IEhpLAo+
ID4+Pgo+ID4+PiBjb25maWd1cmUgZmFpbHMgb24gTmV0QlNEIHRoYXQgdGhlcmUgaXMgbm8gYnJj
dGwuCj4gPj4+IE5ldEJTRCBoYXMgbm8gYnJjdGwsIE5ldEJTRCBoYXMgYnJjb25maWcuCj4gPj4K
PiA+Pgo+ID4+IFNvcnJ5IENocmlzdG9waCwgdGhlIGJyY3RsIHRlc3QgaXMgZ29pbmcgYXdheSAo
ZnJvbSBjb25maWd1cmUgYXQgbGVhc3QpLgo+ID4KPiA+Cj4gPiBUaGVyZSBhcmUgc29tZSBtb3Jl
IExpbnV4IHNwZWNpZmljIHRlc3RzOgo+ID4gLSBpcAo+ID4gLSB1dWlkX2NsZWFyIGluIGxpYnV1
aWQKPiAKPiBJJ20gZ29pbmcgdG8gZml4IHRoaXMgcmlnaHQgbm93LiBTaG91bGQgSSBjb21taXQg
dGhlIG91dHB1dCBmcm9tCj4gYXV0b2NvbmYgYWxzbyB3aXRoIG15IHBhdGNoZXMgSWFuPyBJJ20g
YXNraW5nIHRoaXMgYmVjYXVzZSB3ZSB1c2UKPiBkaWZmZXJlbnQgdmVyc2lvbnMgYW5kIHRoZSBv
dXRwdXQgaXMgc2xpZ2h0bHkgZGlmZmVyZW50LgoKSSBhbHNvIHRoaW5rIGNvbmZpZ3VyZSBzaG91
bGQganVzdCBjaGVjayBjb21waWxlIHRpbWUgcmVxdWlyZW1lbnRzLgppcCgxKSBpcyBtb3N0IGxp
a2VseSBub3QgbmVlZGVkIHRvIGNvbXBpbGUgYW5kIGxpbmsgeGVuK3Rvb2xzLgoKT2xhZgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:14:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YUW-0004HX-IT; Thu, 23 Feb 2012 13:13:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0YUV-0004HP-7j
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:13:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330002820!10250813!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27873 invoked from network); 23 Feb 2012 13:13:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Feb 2012 13:13:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330002820; l=879;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:
	References:Subject:Cc:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6i71Quyn7j87xLpxogwMiwhvfWI=;
	b=Q40LTfKvd372wH8a9xRWz8sFQixV6GDjTshs5M+37EDzO26PcG79uRMdfuSYUKDpSaR
	1VfEb0L++/MGZnFuCf0VOkQN2GZ0ZzS1M/8oQbRgcnReHRe2y00rZzRKh1lCsurA+gWvq
	hABRp82Yx/sRB83vB0PYFN+IPkSguX9eCKI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by post.strato.de (mrclete mo13) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y04e76o1NCYAB2 ;
	Thu, 23 Feb 2012 14:13:22 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2574B18638; Thu, 23 Feb 2012 14:13:20 +0100 (CET)
Date: Thu, 23 Feb 2012 14:13:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@entel.upc.edu>
Message-ID: <20120223131320.GA12900@aepfle.de>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCBGZWIgMjMsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cgo+IDIwMTIvMi8yMiBDaHJp
c3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29tPjoKPiA+IE9uIDAyLzIyLzEyIDEw
OjU5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ID4+Cj4gPj4gMjAxMi8yLzIyIENocmlzdG9w
aCBFZ2dlcjxDaHJpc3RvcGguRWdnZXJAYW1kLmNvbT46Cj4gPj4+Cj4gPj4+Cj4gPj4+IEhpLAo+
ID4+Pgo+ID4+PiBjb25maWd1cmUgZmFpbHMgb24gTmV0QlNEIHRoYXQgdGhlcmUgaXMgbm8gYnJj
dGwuCj4gPj4+IE5ldEJTRCBoYXMgbm8gYnJjdGwsIE5ldEJTRCBoYXMgYnJjb25maWcuCj4gPj4K
PiA+Pgo+ID4+IFNvcnJ5IENocmlzdG9waCwgdGhlIGJyY3RsIHRlc3QgaXMgZ29pbmcgYXdheSAo
ZnJvbSBjb25maWd1cmUgYXQgbGVhc3QpLgo+ID4KPiA+Cj4gPiBUaGVyZSBhcmUgc29tZSBtb3Jl
IExpbnV4IHNwZWNpZmljIHRlc3RzOgo+ID4gLSBpcAo+ID4gLSB1dWlkX2NsZWFyIGluIGxpYnV1
aWQKPiAKPiBJJ20gZ29pbmcgdG8gZml4IHRoaXMgcmlnaHQgbm93LiBTaG91bGQgSSBjb21taXQg
dGhlIG91dHB1dCBmcm9tCj4gYXV0b2NvbmYgYWxzbyB3aXRoIG15IHBhdGNoZXMgSWFuPyBJJ20g
YXNraW5nIHRoaXMgYmVjYXVzZSB3ZSB1c2UKPiBkaWZmZXJlbnQgdmVyc2lvbnMgYW5kIHRoZSBv
dXRwdXQgaXMgc2xpZ2h0bHkgZGlmZmVyZW50LgoKSSBhbHNvIHRoaW5rIGNvbmZpZ3VyZSBzaG91
bGQganVzdCBjaGVjayBjb21waWxlIHRpbWUgcmVxdWlyZW1lbnRzLgppcCgxKSBpcyBtb3N0IGxp
a2VseSBub3QgbmVlZGVkIHRvIGNvbXBpbGUgYW5kIGxpbmsgeGVuK3Rvb2xzLgoKT2xhZgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaA-0004UC-3Q; Thu, 23 Feb 2012 13:19:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Ya7-0004Ts-Uj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:36 +0000
Received: from [85.158.139.83:27499] by server-9.bemta-5.messagelabs.com id
	80/EB-30171-7EC364F4; Thu, 23 Feb 2012 13:19:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17162 invoked from network); 23 Feb 2012 13:19:34 -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;
	23 Feb 2012 13:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374660"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:33 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:32 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-G2;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: b66dbc17bc1b2f6ffcccc3dd5440105247ce65c3
Message-ID: <b66dbc17bc1b2f6ffccc.1330002124@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 15 of 26 V3] libxl: pci: use _init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID b66dbc17bc1b2f6ffcccc3dd5440105247ce65c3
# Parent  af38d2c2926aaa5fbc8ecb90e6e2d327d5ac1733
libxl: pci: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
@@ -552,7 +552,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-int libxl_device_pci_init(libxl_ctx *ctx, libxl_device_pci *pci);
+void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
@@ -196,6 +196,7 @@ _hidden int libxl__device_disk_setdefaul
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
+_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
@@ -765,6 +765,16 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
+void libxl_device_pci_init(libxl_device_pci *pci)
+{
+    memset(pci, '\0', sizeof(*pci));
+}
+
+int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
+{
+    return 0;
+}
+
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
     GC_INIT(ctx);
@@ -782,6 +792,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     int num_assigned, i, rc;
     int stubdomid = 0;
 
+    rc = libxl__device_pci_setdefault(gc, pcidev);
+    if (rc) goto out;
+
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -1016,7 +1016,7 @@ skip_vfb:
 
             d_config->pcidevs = (libxl_device_pci *) realloc(d_config->pcidevs, sizeof (libxl_device_pci) * (d_config->num_pcidevs + 1));
             pcidev = d_config->pcidevs + d_config->num_pcidevs;
-            memset(pcidev, 0x00, sizeof(libxl_device_pci));
+            libxl_device_pci_init(pcidev);
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaA-0004UC-3Q; Thu, 23 Feb 2012 13:19:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0Ya7-0004Ts-Uj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:36 +0000
Received: from [85.158.139.83:27499] by server-9.bemta-5.messagelabs.com id
	80/EB-30171-7EC364F4; Thu, 23 Feb 2012 13:19:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17162 invoked from network); 23 Feb 2012 13:19:34 -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;
	23 Feb 2012 13:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374660"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:33 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:32 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-G2;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: b66dbc17bc1b2f6ffcccc3dd5440105247ce65c3
Message-ID: <b66dbc17bc1b2f6ffccc.1330002124@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 15 of 26 V3] libxl: pci: use _init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID b66dbc17bc1b2f6ffcccc3dd5440105247ce65c3
# Parent  af38d2c2926aaa5fbc8ecb90e6e2d327d5ac1733
libxl: pci: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
@@ -552,7 +552,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-int libxl_device_pci_init(libxl_ctx *ctx, libxl_device_pci *pci);
+void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
@@ -196,6 +196,7 @@ _hidden int libxl__device_disk_setdefaul
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
+_hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
@@ -765,6 +765,16 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
+void libxl_device_pci_init(libxl_device_pci *pci)
+{
+    memset(pci, '\0', sizeof(*pci));
+}
+
+int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
+{
+    return 0;
+}
+
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev)
 {
     GC_INIT(ctx);
@@ -782,6 +792,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     int num_assigned, i, rc;
     int stubdomid = 0;
 
+    rc = libxl__device_pci_setdefault(gc, pcidev);
+    if (rc) goto out;
+
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
diff -r af38d2c2926a -r b66dbc17bc1b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -1016,7 +1016,7 @@ skip_vfb:
 
             d_config->pcidevs = (libxl_device_pci *) realloc(d_config->pcidevs, sizeof (libxl_device_pci) * (d_config->num_pcidevs + 1));
             pcidev = d_config->pcidevs + d_config->num_pcidevs;
-            memset(pcidev, 0x00, sizeof(libxl_device_pci));
+            libxl_device_pci_init(pcidev);
 
             pcidev->msitranslate = pci_msitranslate;
             pcidev->power_mgmt = pci_power_mgmt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0Ya7-0004Tu-NJ; Thu, 23 Feb 2012 13:19: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 1S0Ya6-0004Tl-Nl
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:34 +0000
Received: from [85.158.139.83:41316] by server-3.bemta-5.messagelabs.com id
	33/C8-06438-6EC364F4; Thu, 23 Feb 2012 13:19:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17108 invoked from network); 23 Feb 2012 13:19:33 -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;
	23 Feb 2012 13:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374659"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:31 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:31 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-MI;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6dedf527d9b77f5ed3ca583683c00afd88c7bb6f
Message-ID: <6dedf527d9b77f5ed3ca.1330002134@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 25 of 26 V3] libxl: idl: generate KeyedUnion key
 member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000278 0
# Node ID 6dedf527d9b77f5ed3ca583683c00afd88c7bb6f
# Parent  7c9766bee67645daf47b08b578639025f3427c24
libxl: idl: generate KeyedUnion key member as part of the KeyedUnion

Rather than specifying it twice in the IDL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7c9766bee676 -r 6dedf527d9b7 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar.type, ty.keyvar.name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff -r 7c9766bee676 -r 6dedf527d9b7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
@@ -231,7 +231,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    MemKB),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
@@ -440,7 +439,6 @@ libxl_event = Struct("event",[
     ("domid",    libxl_domid),
     ("domuuid",  libxl_uuid),
     ("for_user", libxl_ev_user),
-    ("type",     libxl_event_type),
     ("u", KeyedUnion(None, libxl_event_type, "type",
           [("domain_shutdown", Struct(None, [
                                              ("shutdown_reason", uint8),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0Ya7-0004Tu-NJ; Thu, 23 Feb 2012 13:19: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 1S0Ya6-0004Tl-Nl
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:34 +0000
Received: from [85.158.139.83:41316] by server-3.bemta-5.messagelabs.com id
	33/C8-06438-6EC364F4; Thu, 23 Feb 2012 13:19:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17108 invoked from network); 23 Feb 2012 13:19:33 -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;
	23 Feb 2012 13:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374659"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:31 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:31 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-MI;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6dedf527d9b77f5ed3ca583683c00afd88c7bb6f
Message-ID: <6dedf527d9b77f5ed3ca.1330002134@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 25 of 26 V3] libxl: idl: generate KeyedUnion key
 member as part of the KeyedUnion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000278 0
# Node ID 6dedf527d9b77f5ed3ca583683c00afd88c7bb6f
# Parent  7c9766bee67645daf47b08b578639025f3427c24
libxl: idl: generate KeyedUnion key member as part of the KeyedUnion

Rather than specifying it twice in the IDL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7c9766bee676 -r 6dedf527d9b7 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar.type, ty.keyvar.name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff -r 7c9766bee676 -r 6dedf527d9b7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
@@ -231,7 +231,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    MemKB),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", libxl_defbool),
@@ -440,7 +439,6 @@ libxl_event = Struct("event",[
     ("domid",    libxl_domid),
     ("domuuid",  libxl_uuid),
     ("for_user", libxl_ev_user),
-    ("type",     libxl_event_type),
     ("u", KeyedUnion(None, libxl_event_type, "type",
           [("domain_shutdown", Struct(None, [
                                              ("shutdown_reason", uint8),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaB-0004Uf-ST; Thu, 23 Feb 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 1S0YaA-0004UB-Eh
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:38 +0000
Received: from [85.158.139.83:27768] by server-5.bemta-5.messagelabs.com id
	4C/98-13566-9EC364F4; Thu, 23 Feb 2012 13:19:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17337 invoked from network); 23 Feb 2012 13:19:37 -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;
	23 Feb 2012 13:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374662"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:36 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:36 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Lj;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7c9766bee67645daf47b08b578639025f3427c24
Message-ID: <7c9766bee67645daf47b.1330002133@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 24 of 26 V3] libxl: Make IDL KeyedUnion keyvar
	an idl.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000278 0
# Node ID 7c9766bee67645daf47b08b578639025f3427c24
# Parent  36a4fefcb0c78946a81c93c68302c9344a603f06
libxl: Make IDL KeyedUnion keyvar an idl.Field

This is more logical than having keyvar_name and keyvar_type members.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:18 2012 +0000
@@ -31,7 +31,7 @@ def gen_rand_init(ty, v, indent = "    "
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
@@ -56,7 +56,7 @@ def libxl_C_type_dispose(ty, v, indent =
     if isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
@@ -86,7 +86,7 @@ def libxl_C_type_gen_json(ty, v, indent 
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
@@ -206,8 +206,9 @@ class KeyedUnion(Aggregate):
         if not isinstance(keyvar_type, Enumeration):
             raise ValueError
 
-        self.keyvar_name = keyvar_name
-        self.keyvar_type = keyvar_type
+        kv_kwargs = dict([(x.lstrip('keyvar_'),y) for (x,y) in kwargs.items() if x.startswith('keyvar_')])
+        
+        self.keyvar = Field(keyvar_type, keyvar_name, **kv_kwargs)
 
         for f in fields:
             # (name, enum, type)
diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
@@ -128,10 +128,9 @@ idl.KeyedUnion
  where the currently valid member of the union can be determined based
  upon another member in the containing type.
 
- The KeyedUnion.keyvar_name must contain the name of the member of the
+ The KeyedUnion.keyvar contains an idl.type the member of the
  containing type which determines the valid member of the union. The
- member referenced by KeyedUnion.keyvar_name has type
- KeyedUnion.keyvar_type which must be an instance of the Enumeration type.
+ must be an instance of the Enumeration type.
 
 Standard Types
 --------------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaB-0004Uf-ST; Thu, 23 Feb 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 1S0YaA-0004UB-Eh
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:38 +0000
Received: from [85.158.139.83:27768] by server-5.bemta-5.messagelabs.com id
	4C/98-13566-9EC364F4; Thu, 23 Feb 2012 13:19:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17337 invoked from network); 23 Feb 2012 13:19:37 -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;
	23 Feb 2012 13:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374662"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:36 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:36 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Lj;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7c9766bee67645daf47b08b578639025f3427c24
Message-ID: <7c9766bee67645daf47b.1330002133@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 24 of 26 V3] libxl: Make IDL KeyedUnion keyvar
	an idl.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000278 0
# Node ID 7c9766bee67645daf47b08b578639025f3427c24
# Parent  36a4fefcb0c78946a81c93c68302c9344a603f06
libxl: Make IDL KeyedUnion keyvar an idl.Field

This is more logical than having keyvar_name and keyvar_type members.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:18 2012 +0000
@@ -31,7 +31,7 @@ def gen_rand_init(ty, v, indent = "    "
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
@@ -56,7 +56,7 @@ def libxl_C_type_dispose(ty, v, indent =
     if isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
@@ -86,7 +86,7 @@ def libxl_C_type_gen_json(ty, v, indent 
     elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
-        s += "switch (%s) {\n" % (parent + ty.keyvar_name)
+        s += "switch (%s) {\n" % (parent + ty.keyvar.name)
         for f in ty.fields:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += "case %s:\n" % f.enumname
diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/idl.py
--- a/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
@@ -206,8 +206,9 @@ class KeyedUnion(Aggregate):
         if not isinstance(keyvar_type, Enumeration):
             raise ValueError
 
-        self.keyvar_name = keyvar_name
-        self.keyvar_type = keyvar_type
+        kv_kwargs = dict([(x.lstrip('keyvar_'),y) for (x,y) in kwargs.items() if x.startswith('keyvar_')])
+        
+        self.keyvar = Field(keyvar_type, keyvar_name, **kv_kwargs)
 
         for f in fields:
             # (name, enum, type)
diff -r 36a4fefcb0c7 -r 7c9766bee676 tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
@@ -128,10 +128,9 @@ idl.KeyedUnion
  where the currently valid member of the union can be determined based
  upon another member in the containing type.
 
- The KeyedUnion.keyvar_name must contain the name of the member of the
+ The KeyedUnion.keyvar contains an idl.type the member of the
  containing type which determines the valid member of the union. The
- member referenced by KeyedUnion.keyvar_name has type
- KeyedUnion.keyvar_type which must be an instance of the Enumeration type.
+ must be an instance of the Enumeration type.
 
 Standard Types
 --------------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaE-0004Vx-7u; Thu, 23 Feb 2012 13:19:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaD-0004Tt-8R
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26252 invoked from network); 23 Feb 2012 13:19:34 -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;
	23 Feb 2012 13:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109326"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:32 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:32 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-D3;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 001f5db5cdb8097051a1fb7b6f5c21a63cfd7872
Message-ID: <001f5db5cdb8097051a1.1330002121@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 12 of 26 V3] libxl: nic: use _init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID 001f5db5cdb8097051a1fb7b6f5c21a63cfd7872
# Parent  17abebd7ba97185f6dce327b6c29b3e380d55d20
libxl: nic: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -1677,32 +1677,43 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic)
+void libxl_device_nic_init(libxl_device_nic *nic)
 {
-    const uint8_t *r;
-    libxl_uuid uuid;
-
-    libxl_uuid_generate(&uuid);
-    r = libxl_uuid_bytearray(&uuid);
     memset(nic, '\0', sizeof(*nic));
-
-    nic->backend_domid = 0;
-    nic->devid = -1;
-    nic->mtu = 1492;
-    nic->model = strdup("rtl8139");
-    nic->mac[0] = 0x00;
-    nic->mac[1] = 0x16;
-    nic->mac[2] = 0x3e;
-    nic->mac[3] = r[0] & 0x7f;
-    nic->mac[4] = r[1];
-    nic->mac[5] = r[2];
-    nic->ifname = NULL;
-    nic->bridge = strdup("xenbr0");
-    nic->ip = NULL;
-    if ( asprintf(&nic->script, "%s/vif-bridge",
-               libxl_xen_script_dir_path()) < 0 )
+}
+
+int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
+{
+    if (!nic->mtu)
+        nic->mtu = 1492;
+    if (!nic->model) {
+        nic->model = strdup("rtl8139");
+        if (!nic->model) return ERROR_NOMEM;
+    }
+    if (!nic->mac[0] && !nic->mac[1] && !nic->mac[2] &&
+        !nic->mac[3] && !nic->mac[4] && !nic->mac[5]) {
+        const uint8_t *r;
+        libxl_uuid uuid;
+
+        libxl_uuid_generate(&uuid);
+        r = libxl_uuid_bytearray(&uuid);
+
+        nic->mac[0] = 0x00;
+        nic->mac[1] = 0x16;
+        nic->mac[2] = 0x3e;
+        nic->mac[3] = r[0] & 0x7f;
+        nic->mac[4] = r[1];
+        nic->mac[5] = r[2];
+    }
+    if (!nic->bridge) {
+        nic->bridge = strdup("xenbr0");
+        if (!nic->bridge) return ERROR_NOMEM;
+    }
+    if ( !nic->script && asprintf(&nic->script, "%s/vif-bridge",
+                                  libxl_xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
-    nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+    if (!nic->nictype)
+        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
     return 0;
 }
 
@@ -1729,6 +1740,9 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     char *dompath, **l;
     unsigned int nb, rc;
 
+    rc = libxl__device_nic_setdefault(gc, nic);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -524,7 +524,7 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
+void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -193,6 +193,7 @@ _hidden int libxl__domain_build_info_set
                                         libxl_domain_build_info *b_info);
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
+_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -839,7 +839,7 @@ static void parse_config_data(const char
 
             d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1));
             nic = d_config->vifs + d_config->num_vifs;
-            CHK_ERRNO( libxl_device_nic_init(ctx, nic) );
+            libxl_device_nic_init(nic);
             nic->devid = d_config->num_vifs;
 
             if (default_vifscript) {
@@ -4609,7 +4609,7 @@ int main_networkattach(int argc, char **
         fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
         return 1;
     }
-    libxl_device_nic_init(ctx, &nic);
+    libxl_device_nic_init(&nic);
     for (argv += optind+1, argc -= optind+1; argc > 0; ++argv, --argc) {
         if (MATCH_OPTION("type", *argv, oparg)) {
             if (!strcmp("vif", oparg)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaE-0004Vx-7u; Thu, 23 Feb 2012 13:19:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaD-0004Tt-8R
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26252 invoked from network); 23 Feb 2012 13:19:34 -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;
	23 Feb 2012 13:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109326"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:32 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:32 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-D3;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 001f5db5cdb8097051a1fb7b6f5c21a63cfd7872
Message-ID: <001f5db5cdb8097051a1.1330002121@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 12 of 26 V3] libxl: nic: use _init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID 001f5db5cdb8097051a1fb7b6f5c21a63cfd7872
# Parent  17abebd7ba97185f6dce327b6c29b3e380d55d20
libxl: nic: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -1677,32 +1677,43 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic)
+void libxl_device_nic_init(libxl_device_nic *nic)
 {
-    const uint8_t *r;
-    libxl_uuid uuid;
-
-    libxl_uuid_generate(&uuid);
-    r = libxl_uuid_bytearray(&uuid);
     memset(nic, '\0', sizeof(*nic));
-
-    nic->backend_domid = 0;
-    nic->devid = -1;
-    nic->mtu = 1492;
-    nic->model = strdup("rtl8139");
-    nic->mac[0] = 0x00;
-    nic->mac[1] = 0x16;
-    nic->mac[2] = 0x3e;
-    nic->mac[3] = r[0] & 0x7f;
-    nic->mac[4] = r[1];
-    nic->mac[5] = r[2];
-    nic->ifname = NULL;
-    nic->bridge = strdup("xenbr0");
-    nic->ip = NULL;
-    if ( asprintf(&nic->script, "%s/vif-bridge",
-               libxl_xen_script_dir_path()) < 0 )
+}
+
+int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
+{
+    if (!nic->mtu)
+        nic->mtu = 1492;
+    if (!nic->model) {
+        nic->model = strdup("rtl8139");
+        if (!nic->model) return ERROR_NOMEM;
+    }
+    if (!nic->mac[0] && !nic->mac[1] && !nic->mac[2] &&
+        !nic->mac[3] && !nic->mac[4] && !nic->mac[5]) {
+        const uint8_t *r;
+        libxl_uuid uuid;
+
+        libxl_uuid_generate(&uuid);
+        r = libxl_uuid_bytearray(&uuid);
+
+        nic->mac[0] = 0x00;
+        nic->mac[1] = 0x16;
+        nic->mac[2] = 0x3e;
+        nic->mac[3] = r[0] & 0x7f;
+        nic->mac[4] = r[1];
+        nic->mac[5] = r[2];
+    }
+    if (!nic->bridge) {
+        nic->bridge = strdup("xenbr0");
+        if (!nic->bridge) return ERROR_NOMEM;
+    }
+    if ( !nic->script && asprintf(&nic->script, "%s/vif-bridge",
+                                  libxl_xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
-    nic->nictype = LIBXL_NIC_TYPE_IOEMU;
+    if (!nic->nictype)
+        nic->nictype = LIBXL_NIC_TYPE_IOEMU;
     return 0;
 }
 
@@ -1729,6 +1740,9 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     char *dompath, **l;
     unsigned int nb, rc;
 
+    rc = libxl__device_nic_setdefault(gc, nic);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -524,7 +524,7 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
+void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -193,6 +193,7 @@ _hidden int libxl__domain_build_info_set
                                         libxl_domain_build_info *b_info);
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
+_hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 17abebd7ba97 -r 001f5db5cdb8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -839,7 +839,7 @@ static void parse_config_data(const char
 
             d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1));
             nic = d_config->vifs + d_config->num_vifs;
-            CHK_ERRNO( libxl_device_nic_init(ctx, nic) );
+            libxl_device_nic_init(nic);
             nic->devid = d_config->num_vifs;
 
             if (default_vifscript) {
@@ -4609,7 +4609,7 @@ int main_networkattach(int argc, char **
         fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
         return 1;
     }
-    libxl_device_nic_init(ctx, &nic);
+    libxl_device_nic_init(&nic);
     for (argv += optind+1, argc -= optind+1; argc > 0; ++argv, --argc) {
         if (MATCH_OPTION("type", *argv, oparg)) {
             if (!strcmp("vif", oparg)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaD-0004Vh-Qm; Thu, 23 Feb 2012 13:19:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaC-0004Tn-5i
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26145 invoked from network); 23 Feb 2012 13:19:33 -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;
	23 Feb 2012 13:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109321"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:30 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-If;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7d012628126b838fcd19a9b65d141410d15705c8
Message-ID: <7d012628126b838fcd19.1330002128@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 19 of 26 V3] libxl: switch generation id control
 to libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID 7d012628126b838fcd19a9b65d141410d15705c8
# Parent  141ed25af0d954e270e3bca9f482efb4070abf0d
libxl: switch generation id control to libxl_defbool.

This allows it to be set via the _init/_setdefault methods.

Also switch the sense of the variable in the libxl API, since once you add
defbool to the mix the double negatives become even more confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>

diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -88,7 +88,6 @@ void libxl_domain_build_info_init(libxl_
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
@@ -150,6 +149,7 @@ int libxl__domain_build_info_setdefault(
         libxl_defbool_setdefault(&b_info->u.hvm.hpet,               true);
         libxl_defbool_setdefault(&b_info->u.hvm.vpt_align,          true);
         libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,         false);
+        libxl_defbool_setdefault(&b_info->u.hvm.incr_generationid,  false);
         libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
 
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
@@ -406,7 +406,7 @@ int libxl__domain_restore_common(libxl__
         hvm = 1;
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = info->u.hvm.no_incr_generationid;
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -260,7 +260,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
-                                       ("no_incr_generationid", bool),
+                                       ("incr_generationid",libxl_defbool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
                                        ("vnc",              libxl_vnc_info),
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -1352,7 +1352,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
-    int no_incr_generationid;
+    int incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info)
@@ -1603,8 +1603,8 @@ static int create_domain(struct domain_c
     }
 
     if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        d_config.b_info.u.hvm.no_incr_generationid =
-            dom_info->no_incr_generationid;
+        libxl_defbool_set(&d_config.b_info.u.hvm.incr_generationid,
+                          dom_info->incr_generationid);
 
     if (debug || dom_info->dryrun)
         printf_info(default_output_format, -1, &d_config);
@@ -2879,7 +2879,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
-    dom_info.no_incr_generationid = 1;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
@@ -3004,6 +3004,7 @@ int main_restore(int argc, char **argv)
     dom_info.restore_file = checkpoint_file;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
@@ -3389,6 +3390,7 @@ int main_create(int argc, char **argv)
     dom_info.extra_config = extra_config;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -108,8 +108,8 @@ void printf_info_sexp(int domid, libxl_d
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
+        printf("\t\t\t(no_incr_generationid %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
 
         printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
         printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaD-0004Vh-Qm; Thu, 23 Feb 2012 13:19:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaC-0004Tn-5i
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26145 invoked from network); 23 Feb 2012 13:19:33 -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;
	23 Feb 2012 13:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109321"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:30 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:30 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-If;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7d012628126b838fcd19a9b65d141410d15705c8
Message-ID: <7d012628126b838fcd19.1330002128@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 19 of 26 V3] libxl: switch generation id control
 to libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID 7d012628126b838fcd19a9b65d141410d15705c8
# Parent  141ed25af0d954e270e3bca9f482efb4070abf0d
libxl: switch generation id control to libxl_defbool.

This allows it to be set via the _init/_setdefault methods.

Also switch the sense of the variable in the libxl API, since once you add
defbool to the mix the double negatives become even more confusing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>

diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -88,7 +88,6 @@ void libxl_domain_build_info_init(libxl_
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
@@ -150,6 +149,7 @@ int libxl__domain_build_info_setdefault(
         libxl_defbool_setdefault(&b_info->u.hvm.hpet,               true);
         libxl_defbool_setdefault(&b_info->u.hvm.vpt_align,          true);
         libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,         false);
+        libxl_defbool_setdefault(&b_info->u.hvm.incr_generationid,  false);
         libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
 
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
@@ -406,7 +406,7 @@ int libxl__domain_restore_common(libxl__
         hvm = 1;
         superpages = 1;
         pae = libxl_defbool_val(info->u.hvm.pae);
-        no_incr_generationid = info->u.hvm.no_incr_generationid;
+        no_incr_generationid = !libxl_defbool_val(info->u.hvm.incr_generationid);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -260,7 +260,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
-                                       ("no_incr_generationid", bool),
+                                       ("incr_generationid",libxl_defbool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
                                        ("vnc",              libxl_vnc_info),
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -1352,7 +1352,7 @@ struct domain_create {
     const char *restore_file;
     int migrate_fd; /* -1 means none */
     char **migration_domname_r; /* from malloc */
-    int no_incr_generationid;
+    int incr_generationid;
 };
 
 static int freemem(libxl_domain_build_info *b_info)
@@ -1603,8 +1603,8 @@ static int create_domain(struct domain_c
     }
 
     if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        d_config.b_info.u.hvm.no_incr_generationid =
-            dom_info->no_incr_generationid;
+        libxl_defbool_set(&d_config.b_info.u.hvm.incr_generationid,
+                          dom_info->incr_generationid);
 
     if (debug || dom_info->dryrun)
         printf_info(default_output_format, -1, &d_config);
@@ -2879,7 +2879,7 @@ static void migrate_receive(int debug, i
     dom_info.restore_file = "incoming migration stream";
     dom_info.migrate_fd = 0; /* stdin */
     dom_info.migration_domname_r = &migration_domname;
-    dom_info.no_incr_generationid = 1;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0) {
@@ -3004,6 +3004,7 @@ int main_restore(int argc, char **argv)
     dom_info.restore_file = checkpoint_file;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 1;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
@@ -3389,6 +3390,7 @@ int main_create(int argc, char **argv)
     dom_info.extra_config = extra_config;
     dom_info.migrate_fd = -1;
     dom_info.console_autoconnect = console_autoconnect;
+    dom_info.incr_generationid = 0;
 
     rc = create_domain(&dom_info);
     if (rc < 0)
diff -r 141ed25af0d9 -r 7d012628126b tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -108,8 +108,8 @@ void printf_info_sexp(int domid, libxl_d
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
+        printf("\t\t\t(no_incr_generationid %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
 
         printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
         printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaD-0004VR-FK; Thu, 23 Feb 2012 13:19: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 1S0YaB-0004UB-90
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:39 +0000
Received: from [85.158.139.83:31820] by server-5.bemta-5.messagelabs.com id
	29/A8-13566-BEC364F4; Thu, 23 Feb 2012 13:19:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17649 invoked from network); 23 Feb 2012 13:19:38 -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;
	23 Feb 2012 13:19:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374663"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:37 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-KX;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1953cd5c411dfbf2f83f17b7de7063e05e441045
Message-ID: <1953cd5c411dfbf2f83f.1330002131@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 22 of 26 V3] libxl: switch device model
 selection over to libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000278 0
# Node ID 1953cd5c411dfbf2f83f17b7de7063e05e441045
# Parent  518c794143bb6d7f5a7c512096e06657a9bbb837
libxl: switch device model selection over to libxl_defbool

This allows it to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[since last v -- ERROR_INVAL on stubdomains + !traditional qemu]

diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -2714,7 +2714,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (b_info->device_model_stubdomain)
+        if (libxl_defbool_val(b_info->device_model_stubdomain))
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
@@ -80,9 +80,6 @@ void libxl_domain_build_info_init(libxl_
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
-    b_info->device_model_stubdomain = false;
-    b_info->device_model = NULL;
-
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
@@ -102,6 +99,17 @@ int libxl__domain_build_info_setdefault(
         b_info->device_model_version =
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version !=
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+        libxl_defbool_val(b_info->device_model_stubdomain)) {
+        LIBXL__LOG(CTX, XTL_ERROR,
+            "device model stubdomains require \"qemu-xen-traditional\"");
+        return ERROR_INVAL;
+    }
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:18 2012 +0000
@@ -39,7 +39,7 @@ const char *libxl__domain_device_model(l
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
 
-    if (info->device_model_stubdomain)
+    if (libxl_defbool_val(info->device_model_stubdomain))
         return NULL;
 
     if (info->device_model) {
@@ -909,7 +909,7 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (b_info->device_model_stubdomain) {
+    if (libxl_defbool_val(b_info->device_model_stubdomain)) {
         rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
@@ -234,8 +234,8 @@ libxl_domain_build_info = Struct("domain
     ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
+    ("device_model_stubdomain", libxl_defbool),
+    # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
 
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -1120,8 +1120,8 @@ skip_vfb:
         }
     } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        b_info->device_model_stubdomain = l;
+    xlu_cfg_get_defbool (config, "device_model_stubdomain_override",
+                         &b_info->device_model_stubdomain, 0);
 
     if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel",
                              &buf, 0)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaD-0004VR-FK; Thu, 23 Feb 2012 13:19: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 1S0YaB-0004UB-90
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:39 +0000
Received: from [85.158.139.83:31820] by server-5.bemta-5.messagelabs.com id
	29/A8-13566-BEC364F4; Thu, 23 Feb 2012 13:19:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17649 invoked from network); 23 Feb 2012 13:19:38 -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;
	23 Feb 2012 13:19:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374663"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:37 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-KX;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1953cd5c411dfbf2f83f17b7de7063e05e441045
Message-ID: <1953cd5c411dfbf2f83f.1330002131@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 22 of 26 V3] libxl: switch device model
 selection over to libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000278 0
# Node ID 1953cd5c411dfbf2f83f17b7de7063e05e441045
# Parent  518c794143bb6d7f5a7c512096e06657a9bbb837
libxl: switch device model selection over to libxl_defbool

This allows it to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[since last v -- ERROR_INVAL on stubdomains + !traditional qemu]

diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -2714,7 +2714,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (b_info->device_model_stubdomain)
+        if (libxl_defbool_val(b_info->device_model_stubdomain))
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
@@ -80,9 +80,6 @@ void libxl_domain_build_info_init(libxl_
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
-    b_info->device_model_stubdomain = false;
-    b_info->device_model = NULL;
-
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
@@ -102,6 +99,17 @@ int libxl__domain_build_info_setdefault(
         b_info->device_model_version =
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version !=
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+        libxl_defbool_val(b_info->device_model_stubdomain)) {
+        LIBXL__LOG(CTX, XTL_ERROR,
+            "device model stubdomains require \"qemu-xen-traditional\"");
+        return ERROR_INVAL;
+    }
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:18 2012 +0000
@@ -39,7 +39,7 @@ const char *libxl__domain_device_model(l
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
 
-    if (info->device_model_stubdomain)
+    if (libxl_defbool_val(info->device_model_stubdomain))
         return NULL;
 
     if (info->device_model) {
@@ -909,7 +909,7 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (b_info->device_model_stubdomain) {
+    if (libxl_defbool_val(b_info->device_model_stubdomain)) {
         rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
@@ -234,8 +234,8 @@ libxl_domain_build_info = Struct("domain
     ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
+    ("device_model_stubdomain", libxl_defbool),
+    # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
 
diff -r 518c794143bb -r 1953cd5c411d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -1120,8 +1120,8 @@ skip_vfb:
         }
     } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        b_info->device_model_stubdomain = l;
+    xlu_cfg_get_defbool (config, "device_model_stubdomain_override",
+                         &b_info->device_model_stubdomain, 0);
 
     if (!xlu_cfg_get_string (config, "device_model_stubdomain_seclabel",
                              &buf, 0)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaG-0004XJ-LY; Thu, 23 Feb 2012 13:19:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaE-0004U6-Jj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26354 invoked from network); 23 Feb 2012 13:19:36 -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;
	23 Feb 2012 13:19:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109337"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:35 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-L9;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 36a4fefcb0c78946a81c93c68302c9344a603f06
Message-ID: <36a4fefcb0c78946a81c.1330002132@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 23 of 26 V3] libxl: add
	libxl_domain_build_info_init_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000278 0
# Node ID 36a4fefcb0c78946a81c93c68302c9344a603f06
# Parent  1953cd5c411dfbf2f83f17b7de7063e05e441045
libxl: add libxl_domain_build_info_init_type

Use instead of parameterising libxl_domain_build_info_init. This allows callers
to initialise a libxl_domain_build_info but not to commit to a particular type
later on (e.g. after they've parsed the domain config)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
@@ -382,8 +382,9 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                          const libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
@@ -69,23 +69,29 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                                  const libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = c_info->type;
+    b_info->type = -1;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
+}
+
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type)
+{
+    assert(b_info->type == -1);
+    b_info->type = type;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 0;
+        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
         break;
     default:
         abort();
diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:18 2012 +0000
@@ -711,7 +711,8 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+    libxl_domain_build_info_init(&dm_config.b_info);
+    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
 
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -583,7 +583,8 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_build_info_init(b_info, c_info);
+    libxl_domain_build_info_init(b_info);
+    libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -700,7 +701,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    switch(c_info->type) {
+    switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaG-0004XJ-LY; Thu, 23 Feb 2012 13:19:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaE-0004U6-Jj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26354 invoked from network); 23 Feb 2012 13:19:36 -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;
	23 Feb 2012 13:19:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109337"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:35 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-L9;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 36a4fefcb0c78946a81c93c68302c9344a603f06
Message-ID: <36a4fefcb0c78946a81c.1330002132@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 23 of 26 V3] libxl: add
	libxl_domain_build_info_init_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000278 0
# Node ID 36a4fefcb0c78946a81c93c68302c9344a603f06
# Parent  1953cd5c411dfbf2f83f17b7de7063e05e441045
libxl: add libxl_domain_build_info_init_type

Use instead of parameterising libxl_domain_build_info_init. This allows callers
to initialise a libxl_domain_build_info but not to commit to a particular type
later on (e.g. after they've parsed the domain config)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
@@ -382,8 +382,9 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                          const libxl_domain_create_info *c_info);
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
@@ -69,23 +69,29 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info,
-                                  const libxl_domain_create_info *c_info)
+void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = c_info->type;
+    b_info->type = -1;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
     b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
 
+}
+
+void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
+                                       libxl_domain_type type)
+{
+    assert(b_info->type == -1);
+    b_info->type = type;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 0;
+        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
         break;
     default:
         abort();
diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:18 2012 +0000
@@ -711,7 +711,8 @@ static int libxl__create_stubdom(libxl__
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    libxl_domain_build_info_init(&dm_config.b_info, &dm_config.c_info);
+    libxl_domain_build_info_init(&dm_config.b_info);
+    libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV);
 
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
diff -r 1953cd5c411d -r 36a4fefcb0c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -583,7 +583,8 @@ static void parse_config_data(const char
         exit(1);
     }
 
-    libxl_domain_build_info_init(b_info, c_info);
+    libxl_domain_build_info_init(b_info);
+    libxl_domain_build_info_init_type(b_info, c_info->type);
 
     /* the following is the actual config parsing with overriding values in the structures */
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
@@ -700,7 +701,7 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    switch(c_info->type) {
+    switch(b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaH-0004Xv-Fr; Thu, 23 Feb 2012 13:19: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 1S0YaF-0004WE-Cz
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:43 +0000
Received: from [85.158.139.83:32194] by server-7.bemta-5.messagelabs.com id
	C0/3B-16195-EEC364F4; Thu, 23 Feb 2012 13:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17774 invoked from network); 23 Feb 2012 13:19:41 -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;
	23 Feb 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374666"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:40 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:40 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Jz;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 518c794143bb6d7f5a7c512096e06657a9bbb837
Message-ID: <518c794143bb6d7f5a7c.1330002130@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 21 of 26 V3] libxl: do not explicitly initialise
 members of build info to zero
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID 518c794143bb6d7f5a7c512096e06657a9bbb837
# Parent  1620730643994e949b486b07dc919f74d17fa3e1
libxl: do not explicitly initialise members of build info to zero

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 162073064399 -r 518c794143bb tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
@@ -86,12 +85,7 @@ void libxl_domain_build_info_init(libxl_
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-
-        b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usbdevice = NULL;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaH-0004Xv-Fr; Thu, 23 Feb 2012 13:19: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 1S0YaF-0004WE-Cz
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:43 +0000
Received: from [85.158.139.83:32194] by server-7.bemta-5.messagelabs.com id
	C0/3B-16195-EEC364F4; Thu, 23 Feb 2012 13:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17774 invoked from network); 23 Feb 2012 13:19:41 -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;
	23 Feb 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374666"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:40 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:40 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Jz;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 518c794143bb6d7f5a7c512096e06657a9bbb837
Message-ID: <518c794143bb6d7f5a7c.1330002130@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 21 of 26 V3] libxl: do not explicitly initialise
 members of build info to zero
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID 518c794143bb6d7f5a7c512096e06657a9bbb837
# Parent  1620730643994e949b486b07dc919f74d17fa3e1
libxl: do not explicitly initialise members of build info to zero

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 162073064399 -r 518c794143bb tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
     b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
@@ -86,12 +85,7 @@ void libxl_domain_build_info_init(libxl_
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-
-        b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usbdevice = NULL;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaB-0004UU-Ex; Thu, 23 Feb 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 1S0Ya9-0004U7-Np
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:38 +0000
Received: from [85.158.139.83:41566] by server-4.bemta-5.messagelabs.com id
	C6/E9-10788-9EC364F4; Thu, 23 Feb 2012 13:19:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17251 invoked from network); 23 Feb 2012 13:19:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374661"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:34 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-JJ;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1620730643994e949b486b07dc919f74d17fa3e1
Message-ID: <1620730643994e949b48.1330002129@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 20 of 26 V3] libxl: use defbool for graphics
	related 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1330000277 0
# Node ID 1620730643994e949b486b07dc919f74d17fa3e1
# Parent  7d012628126b838fcd19a9b65d141410d15705c8
libxl: use defbool for graphics related options

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 7d012628126b -r 162073064399 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -2257,22 +2257,23 @@ out:
 void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->vnc.enable = 1;
-    vfb->vnc.passwd = NULL;
-    vfb->vnc.display = 0;
-    vfb->vnc.findunused = 1;
-    vfb->keymap = NULL;
-    vfb->sdl.enable = 0;
-    vfb->sdl.opengl = 0;
-    vfb->sdl.display = NULL;
-    vfb->sdl.xauthority = NULL;
 }
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
-    if (!vfb->vnc.listen) {
-        vfb->vnc.listen = strdup("127.0.0.1");
-        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    libxl_defbool_setdefault(&vfb->vnc.enable, true);
+    if (libxl_defbool_val(vfb->vnc.enable)) {
+        if (!vfb->vnc.listen) {
+            vfb->vnc.listen = strdup("127.0.0.1");
+            if (!vfb->vnc.listen) return ERROR_NOMEM;
+        }
+
+        libxl_defbool_setdefault(&vfb->vnc.findunused, true);
+    }
+
+    libxl_defbool_setdefault(&vfb->sdl.enable, false);
+    if (libxl_defbool_val(vfb->sdl.enable)) {
+        libxl_defbool_setdefault(&vfb->sdl.opengl, false);
     }
 
     return 0;
@@ -2321,17 +2322,17 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
     flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
     flexarray_append_pair(back, "vnc",
-                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+                          libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
     flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
     flexarray_append_pair(back, "vncdisplay",
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
-                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
+                          libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0");
     flexarray_append_pair(back, "sdl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+                          libxl_defbool_val(vfb->sdl.enable) ? "1" : "0");
     flexarray_append_pair(back, "opengl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+                          libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0");
     if (vfb->sdl.xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
diff -r 7d012628126b -r 162073064399 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -89,10 +89,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
 
-        b_info->u.hvm.stdvga = 0;
-        b_info->u.hvm.vnc.enable = 1;
         b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.usbdevice = NULL;
         break;
@@ -158,13 +155,32 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }
 
-        if (b_info->u.hvm.vnc.enable) {
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
+        if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
             if (!b_info->u.hvm.vnc.listen) {
                 b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
                 if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
             }
         }
 
+        libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.sdl.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.sdl.opengl, false);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.disable_ticketing,
+                                     false);
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.agent_mouse, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.nographic, false);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false);
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
diff -r 7d012628126b -r 162073064399 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -81,7 +81,7 @@ const libxl_vnc_info *libxl__dm_vnc(cons
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
-    return vnc && vnc->enable ? vnc : NULL;
+    return vnc && libxl_defbool_val(vnc->enable) ? vnc : NULL;
 }
 
 static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
@@ -92,7 +92,7 @@ static const libxl_sdl_info *dm_sdl(cons
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
-    return sdl && sdl->enable ? sdl : NULL;
+    return sdl && libxl_defbool_val(sdl->enable) ? sdl : NULL;
 }
 
 static const char *dm_keymap(const libxl_domain_config *guest_config)
@@ -154,13 +154,13 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!sdl->opengl) {
+        if (!libxl_defbool_val(sdl->opengl)) {
             flexarray_append(dm_args, "-disable-opengl");
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
@@ -175,7 +175,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
@@ -185,7 +185,7 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -238,7 +238,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -291,7 +291,7 @@ static char *dm_spice_options(libxl__gc 
         return NULL;
     }
 
-    if (!spice->disable_ticketing) {
+    if (!libxl_defbool_val(spice->disable_ticketing)) {
         if (!spice->passwd) {
             LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                        "spice ticketing is enabled but missing password");
@@ -307,12 +307,12 @@ static char *dm_spice_options(libxl__gc 
                          spice->port, spice->tls_port);
     if (spice->host)
         opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
-    if (spice->disable_ticketing)
+    if (libxl_defbool_val(spice->disable_ticketing))
         opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
     else
         opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
     opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
-                         spice->agent_mouse ? "on" : "off");
+                         libxl_defbool_val(spice->agent_mouse) ? "on" : "off");
     return opt;
 }
 
@@ -381,7 +381,7 @@ static char ** libxl__build_device_model
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             /* This option asks to QEMU to try this number of port before to
              * give up.  So QEMU will try ports between $display and $display +
              * 99.  This option needs to be the last one of the vnc options. */
@@ -409,11 +409,11 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (b_info->u.hvm.spice.enable) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -423,7 +423,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }
 
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -483,7 +483,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 7d012628126b -r 162073064399 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -123,31 +123,31 @@ libxl_shutdown_reason = Enumeration("shu
 # Complex libxl types
 #
 libxl_vnc_info = Struct("vnc_info", [
-    ("enable",        bool),
+    ("enable",        libxl_defbool),
     # "address:port" that should be listened on
     ("listen",        string),
     ("passwd",        string),
     ("display",       integer),
     # If set then try to find an unused port
-    ("findunused",    bool),
+    ("findunused",    libxl_defbool),
     ])
 
 libxl_spice_info = Struct("spice_info", [
-    ("enable",            bool),
+    ("enable",      libxl_defbool),
     # At least one of spice port or spicetls_post must be given
     ("port",        integer),
     ("tls_port",    integer),
     # Interface to bind to
     ("host",        string),
     # enable client connection with no password
-    ("disable_ticketing", bool),
+    ("disable_ticketing", libxl_defbool),
     ("passwd",      string),
-    ("agent_mouse", bool),
+    ("agent_mouse", libxl_defbool),
     ])
 
 libxl_sdl_info = Struct("sdl_info", [
-    ("enable",        bool),
-    ("opengl",        bool),
+    ("enable",        libxl_defbool),
+    ("opengl",        libxl_defbool),
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -261,15 +261,15 @@ libxl_domain_build_info = Struct("domain
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
                                        ("incr_generationid",libxl_defbool),
-                                       ("nographic",        bool),
-                                       ("stdvga",           bool),
+                                       ("nographic",        libxl_defbool),
+                                       ("stdvga",           libxl_defbool),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is en-us keyboard
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
-                                       ("gfx_passthru",     bool),
+                                       ("gfx_passthru",     libxl_defbool),
                                        
                                        ("serial",           string),
                                        ("boot",             string),
diff -r 7d012628126b -r 162073064399 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -941,7 +941,7 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "vnclisten")) {
                     free(vfb->vnc.listen);
                     vfb->vnc.listen = strdup(p2 + 1);
@@ -951,14 +951,14 @@ skip:
                 } else if (!strcmp(p, "vncdisplay")) {
                     vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vnc.findunused = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.findunused, atoi(p2 + 1));
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->sdl.opengl = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.opengl, atoi(p2 + 1));
                 } else if (!strcmp(p, "display")) {
                     free(vfb->sdl.display);
                     vfb->sdl.display = strdup(p2 + 1);
@@ -1158,41 +1158,35 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            b_info->u.hvm.stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            b_info->u.hvm.vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
+        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
+        xlu_cfg_replace_string (config, "vnclisten",
+                                &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd",
+                                &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             b_info->u.hvm.vnc.display = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_get_defbool(config, "vncunused",
+                            &b_info->u.hvm.vnc.findunused, 0);
         xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
-        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            b_info->u.hvm.sdl.enable = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            b_info->u.hvm.sdl.opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            b_info->u.hvm.spice.enable = l;
+        xlu_cfg_get_defbool(config, "sdl", &b_info->u.hvm.sdl.enable, 0);
+        xlu_cfg_get_defbool(config, "opengl", &b_info->u.hvm.sdl.opengl, 0);
+        xlu_cfg_get_defbool (config, "spice", &b_info->u.hvm.spice.enable, 0);
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             b_info->u.hvm.spice.tls_port = l;
         xlu_cfg_replace_string (config, "spicehost",
                                 &b_info->u.hvm.spice.host, 0);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            b_info->u.hvm.spice.disable_ticketing = l;
+        xlu_cfg_get_defbool(config, "spicedisable_ticketing",
+                            &b_info->u.hvm.spice.disable_ticketing, 0);
         xlu_cfg_replace_string (config, "spicepasswd",
                                 &b_info->u.hvm.spice.passwd, 0);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            b_info->u.hvm.spice.agent_mouse = l;
-        else
-            b_info->u.hvm.spice.agent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            b_info->u.hvm.nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            b_info->u.hvm.gfx_passthru = l;
+        xlu_cfg_get_defbool(config, "spiceagent_mouse",
+                            &b_info->u.hvm.spice.agent_mouse, 0);
+        xlu_cfg_get_defbool(config, "nographic", &b_info->u.hvm.nographic, 0);
+        xlu_cfg_get_defbool(config, "gfx_passthru", 
+                            &b_info->u.hvm.gfx_passthru, 0);
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
diff -r 7d012628126b -r 162073064399 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -110,26 +110,34 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(stdvga %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.findunused));
         printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
+        printf("\t\t\t(nographic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nographic));
+        printf("\t\t\t(spice %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.enable));
         printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
         printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
         printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+        printf("\t\t\t(spicedisable_ticketing %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.disable_ticketing));
+        printf("\t\t\t(spiceagent_mouse %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.agent_mouse));
 
         printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(gfx_passthru %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.gfx_passthru));
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
@@ -204,13 +212,17 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.findunused));
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.opengl));
         printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
         printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaB-0004UU-Ex; Thu, 23 Feb 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 1S0Ya9-0004U7-Np
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:38 +0000
Received: from [85.158.139.83:41566] by server-4.bemta-5.messagelabs.com id
	C6/E9-10788-9EC364F4; Thu, 23 Feb 2012 13:19:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17251 invoked from network); 23 Feb 2012 13:19:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374661"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:34 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-JJ;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1620730643994e949b486b07dc919f74d17fa3e1
Message-ID: <1620730643994e949b48.1330002129@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 20 of 26 V3] libxl: use defbool for graphics
	related 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1330000277 0
# Node ID 1620730643994e949b486b07dc919f74d17fa3e1
# Parent  7d012628126b838fcd19a9b65d141410d15705c8
libxl: use defbool for graphics related options

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 7d012628126b -r 162073064399 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -2257,22 +2257,23 @@ out:
 void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->vnc.enable = 1;
-    vfb->vnc.passwd = NULL;
-    vfb->vnc.display = 0;
-    vfb->vnc.findunused = 1;
-    vfb->keymap = NULL;
-    vfb->sdl.enable = 0;
-    vfb->sdl.opengl = 0;
-    vfb->sdl.display = NULL;
-    vfb->sdl.xauthority = NULL;
 }
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
-    if (!vfb->vnc.listen) {
-        vfb->vnc.listen = strdup("127.0.0.1");
-        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    libxl_defbool_setdefault(&vfb->vnc.enable, true);
+    if (libxl_defbool_val(vfb->vnc.enable)) {
+        if (!vfb->vnc.listen) {
+            vfb->vnc.listen = strdup("127.0.0.1");
+            if (!vfb->vnc.listen) return ERROR_NOMEM;
+        }
+
+        libxl_defbool_setdefault(&vfb->vnc.findunused, true);
+    }
+
+    libxl_defbool_setdefault(&vfb->sdl.enable, false);
+    if (libxl_defbool_val(vfb->sdl.enable)) {
+        libxl_defbool_setdefault(&vfb->sdl.opengl, false);
     }
 
     return 0;
@@ -2321,17 +2322,17 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
     flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
     flexarray_append_pair(back, "vnc",
-                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+                          libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
     flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
     flexarray_append_pair(back, "vncdisplay",
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
-                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
+                          libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0");
     flexarray_append_pair(back, "sdl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+                          libxl_defbool_val(vfb->sdl.enable) ? "1" : "0");
     flexarray_append_pair(back, "opengl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+                          libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0");
     if (vfb->sdl.xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
diff -r 7d012628126b -r 162073064399 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -89,10 +89,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
 
-        b_info->u.hvm.stdvga = 0;
-        b_info->u.hvm.vnc.enable = 1;
         b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.usbdevice = NULL;
         break;
@@ -158,13 +155,32 @@ int libxl__domain_build_info_setdefault(
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
         }
 
-        if (b_info->u.hvm.vnc.enable) {
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
+        if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
             if (!b_info->u.hvm.vnc.listen) {
                 b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
                 if (!b_info->u.hvm.vnc.listen) return ERROR_NOMEM;
             }
         }
 
+        libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.sdl.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.sdl.opengl, false);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.disable_ticketing,
+                                     false);
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.agent_mouse, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.nographic, false);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false);
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
diff -r 7d012628126b -r 162073064399 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -81,7 +81,7 @@ const libxl_vnc_info *libxl__dm_vnc(cons
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
-    return vnc && vnc->enable ? vnc : NULL;
+    return vnc && libxl_defbool_val(vnc->enable) ? vnc : NULL;
 }
 
 static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
@@ -92,7 +92,7 @@ static const libxl_sdl_info *dm_sdl(cons
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
-    return sdl && sdl->enable ? sdl : NULL;
+    return sdl && libxl_defbool_val(sdl->enable) ? sdl : NULL;
 }
 
 static const char *dm_keymap(const libxl_domain_config *guest_config)
@@ -154,13 +154,13 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!sdl->opengl) {
+        if (!libxl_defbool_val(sdl->opengl)) {
             flexarray_append(dm_args, "-disable-opengl");
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
@@ -175,7 +175,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
@@ -185,7 +185,7 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -238,7 +238,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -291,7 +291,7 @@ static char *dm_spice_options(libxl__gc 
         return NULL;
     }
 
-    if (!spice->disable_ticketing) {
+    if (!libxl_defbool_val(spice->disable_ticketing)) {
         if (!spice->passwd) {
             LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                        "spice ticketing is enabled but missing password");
@@ -307,12 +307,12 @@ static char *dm_spice_options(libxl__gc 
                          spice->port, spice->tls_port);
     if (spice->host)
         opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
-    if (spice->disable_ticketing)
+    if (libxl_defbool_val(spice->disable_ticketing))
         opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
     else
         opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
     opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
-                         spice->agent_mouse ? "on" : "off");
+                         libxl_defbool_val(spice->agent_mouse) ? "on" : "off");
     return opt;
 }
 
@@ -381,7 +381,7 @@ static char ** libxl__build_device_model
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             /* This option asks to QEMU to try this number of port before to
              * give up.  So QEMU will try ports between $display and $display +
              * 99.  This option needs to be the last one of the vnc options. */
@@ -409,11 +409,11 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (b_info->u.hvm.spice.enable) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -423,7 +423,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }
 
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -483,7 +483,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 7d012628126b -r 162073064399 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -123,31 +123,31 @@ libxl_shutdown_reason = Enumeration("shu
 # Complex libxl types
 #
 libxl_vnc_info = Struct("vnc_info", [
-    ("enable",        bool),
+    ("enable",        libxl_defbool),
     # "address:port" that should be listened on
     ("listen",        string),
     ("passwd",        string),
     ("display",       integer),
     # If set then try to find an unused port
-    ("findunused",    bool),
+    ("findunused",    libxl_defbool),
     ])
 
 libxl_spice_info = Struct("spice_info", [
-    ("enable",            bool),
+    ("enable",      libxl_defbool),
     # At least one of spice port or spicetls_post must be given
     ("port",        integer),
     ("tls_port",    integer),
     # Interface to bind to
     ("host",        string),
     # enable client connection with no password
-    ("disable_ticketing", bool),
+    ("disable_ticketing", libxl_defbool),
     ("passwd",      string),
-    ("agent_mouse", bool),
+    ("agent_mouse", libxl_defbool),
     ])
 
 libxl_sdl_info = Struct("sdl_info", [
-    ("enable",        bool),
-    ("opengl",        bool),
+    ("enable",        libxl_defbool),
+    ("opengl",        libxl_defbool),
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -261,15 +261,15 @@ libxl_domain_build_info = Struct("domain
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
                                        ("incr_generationid",libxl_defbool),
-                                       ("nographic",        bool),
-                                       ("stdvga",           bool),
+                                       ("nographic",        libxl_defbool),
+                                       ("stdvga",           libxl_defbool),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is en-us keyboard
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
-                                       ("gfx_passthru",     bool),
+                                       ("gfx_passthru",     libxl_defbool),
                                        
                                        ("serial",           string),
                                        ("boot",             string),
diff -r 7d012628126b -r 162073064399 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -941,7 +941,7 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "vnclisten")) {
                     free(vfb->vnc.listen);
                     vfb->vnc.listen = strdup(p2 + 1);
@@ -951,14 +951,14 @@ skip:
                 } else if (!strcmp(p, "vncdisplay")) {
                     vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vnc.findunused = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.findunused, atoi(p2 + 1));
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->sdl.opengl = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.opengl, atoi(p2 + 1));
                 } else if (!strcmp(p, "display")) {
                     free(vfb->sdl.display);
                     vfb->sdl.display = strdup(p2 + 1);
@@ -1158,41 +1158,35 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            b_info->u.hvm.stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            b_info->u.hvm.vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
+        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
+        xlu_cfg_replace_string (config, "vnclisten",
+                                &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd",
+                                &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             b_info->u.hvm.vnc.display = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_get_defbool(config, "vncunused",
+                            &b_info->u.hvm.vnc.findunused, 0);
         xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
-        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            b_info->u.hvm.sdl.enable = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            b_info->u.hvm.sdl.opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            b_info->u.hvm.spice.enable = l;
+        xlu_cfg_get_defbool(config, "sdl", &b_info->u.hvm.sdl.enable, 0);
+        xlu_cfg_get_defbool(config, "opengl", &b_info->u.hvm.sdl.opengl, 0);
+        xlu_cfg_get_defbool (config, "spice", &b_info->u.hvm.spice.enable, 0);
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             b_info->u.hvm.spice.tls_port = l;
         xlu_cfg_replace_string (config, "spicehost",
                                 &b_info->u.hvm.spice.host, 0);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            b_info->u.hvm.spice.disable_ticketing = l;
+        xlu_cfg_get_defbool(config, "spicedisable_ticketing",
+                            &b_info->u.hvm.spice.disable_ticketing, 0);
         xlu_cfg_replace_string (config, "spicepasswd",
                                 &b_info->u.hvm.spice.passwd, 0);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            b_info->u.hvm.spice.agent_mouse = l;
-        else
-            b_info->u.hvm.spice.agent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            b_info->u.hvm.nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            b_info->u.hvm.gfx_passthru = l;
+        xlu_cfg_get_defbool(config, "spiceagent_mouse",
+                            &b_info->u.hvm.spice.agent_mouse, 0);
+        xlu_cfg_get_defbool(config, "nographic", &b_info->u.hvm.nographic, 0);
+        xlu_cfg_get_defbool(config, "gfx_passthru", 
+                            &b_info->u.hvm.gfx_passthru, 0);
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
diff -r 7d012628126b -r 162073064399 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -110,26 +110,34 @@ void printf_info_sexp(int domid, libxl_d
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.incr_generationid));
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(stdvga %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.findunused));
         printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
+        printf("\t\t\t(nographic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nographic));
+        printf("\t\t\t(spice %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.enable));
         printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
         printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
         printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+        printf("\t\t\t(spicedisable_ticketing %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.disable_ticketing));
+        printf("\t\t\t(spiceagent_mouse %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.agent_mouse));
 
         printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(gfx_passthru %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.gfx_passthru));
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
@@ -204,13 +212,17 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.findunused));
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.opengl));
         printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
         printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaH-0004Xd-2p; Thu, 23 Feb 2012 13:19: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 1S0YaE-0004Vt-IX
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:43 +0000
Received: from [85.158.139.83:42022] by server-9.bemta-5.messagelabs.com id
	C9/5C-30171-DEC364F4; Thu, 23 Feb 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17736 invoked from network); 23 Feb 2012 13:19:40 -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;
	23 Feb 2012 13:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374665"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:39 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:39 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Hx;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 141ed25af0d954e270e3bca9f482efb4070abf0d
Message-ID: <141ed25af0d954e270e3.1330002127@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 18 of 26 V3] libxl: make boolean members of
 libxl_domain_build_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID 141ed25af0d954e270e3bca9f482efb4070abf0d
# Parent  a27058f39b2cb2064e3370dfc216f08c49f0517d
libxl: make boolean members of libxl_domain_build_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

This just covers the obvious ones.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:17 2012 +0000
@@ -352,6 +352,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     rc = ERROR_INVAL;
     if (!disk)
         goto out;
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
@@ -88,17 +87,7 @@ void libxl_domain_build_info_init(libxl_
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
-        b_info->u.hvm.pae = 1;
-        b_info->u.hvm.apic = 1;
-        b_info->u.hvm.acpi = 1;
-        b_info->u.hvm.acpi_s3 = 1;
-        b_info->u.hvm.acpi_s4 = 1;
-        b_info->u.hvm.nx = 1;
-        b_info->u.hvm.viridian = 0;
-        b_info->u.hvm.hpet = 1;
-        b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
@@ -106,9 +95,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
-        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;
@@ -141,6 +128,8 @@ int libxl__domain_build_info_setdefault(
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->target_memkb = b_info->max_memkb;
 
+    libxl_defbool_setdefault(&b_info->disable_migrate, false);
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
@@ -151,6 +140,19 @@ int libxl__domain_build_info_setdefault(
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
 
+        libxl_defbool_setdefault(&b_info->u.hvm.pae,                true);
+        libxl_defbool_setdefault(&b_info->u.hvm.apic,               true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi,               true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3,            true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4,            true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nx,                 true);
+        libxl_defbool_setdefault(&b_info->u.hvm.viridian,           false);
+        libxl_defbool_setdefault(&b_info->u.hvm.hpet,               true);
+        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align,          true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,         false);
+        libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
@@ -165,6 +167,7 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
         if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
@@ -220,11 +223,11 @@ int libxl__domain_build(libxl__gc *gc,
 
         localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
-        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[1] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
-        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[3] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
-        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[5] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -426,7 +429,6 @@ retry_transaction:
     xs_rm(ctx->xsh, t, dom_path);
     libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
 
-
     xs_rm(ctx->xsh, t, vm_path);
     libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
@@ -673,7 +675,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
+        libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         int rc;
         rc = libxl__e820_alloc(gc, domid, d_config);
         if (rc)
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -192,7 +192,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.boot) {
             flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -202,7 +202,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (b_info->u.hvm.acpi) {
+        if (libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -431,7 +431,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-boot",
                     libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -441,7 +441,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (!b_info->u.hvm.acpi) {
+        if (!libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-no-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -943,7 +943,7 @@ int libxl__create_device_model(libxl__gc
         b_info->device_model_version
         == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
         libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                        "%d", !b_info->u.hvm.xen_platform_pci);
+                    "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
@@ -88,7 +88,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         abort();
     }
     xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if ( info->disable_migrate )
+    if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -292,7 +292,7 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->apic_mode = info->u.hvm.apic;
+    va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
@@ -302,14 +302,19 @@ static int hvm_build_set_params(xc_inter
 
     xc_get_hvm_param(handle, domid, HVM_PARAM_STORE_PFN, store_mfn);
     xc_get_hvm_param(handle, domid, HVM_PARAM_CONSOLE_PFN, console_mfn);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED, info->u.hvm.pae);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED,
+                     libxl_defbool_val(info->u.hvm.pae));
 #if defined(__i386__) || defined(__x86_64__)
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN,
+                     libxl_defbool_val(info->u.hvm.viridian));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
+                     libxl_defbool_val(info->u.hvm.hpet));
 #endif
     xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
+                     libxl_defbool_val(info->u.hvm.vpt_align));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
+                     libxl_defbool_val(info->u.hvm.nested_hvm));
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
 
@@ -400,7 +405,7 @@ int libxl__domain_restore_common(libxl__
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
-        pae = info->u.hvm.pae;
+        pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
@@ -1378,7 +1378,7 @@ int libxl__e820_alloc(libxl__gc *gc, uin
         return ERROR_INVAL;
 
     b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
+    if (!libxl_defbool_val(b_info->u.pv.e820_host))
         return ERROR_INVAL;
 
     rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -229,7 +229,7 @@ libxl_domain_build_info = Struct("domain
     ("target_memkb",    MemKB),
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
-    ("disable_migrate", bool),
+    ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     
@@ -247,19 +247,19 @@ libxl_domain_build_info = Struct("domain
     ("extra_hvm",        libxl_string_list),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
-                [("hvm", Struct(None, [("firmware", string),
-                                       ("pae", bool),
-                                       ("apic", bool),
-                                       ("acpi", bool),
-                                       ("acpi_s3", bool),
-                                       ("acpi_s4", bool),
-                                       ("nx", bool),
-                                       ("viridian", bool),
-                                       ("timeoffset", string),
-                                       ("hpet", bool),
-                                       ("vpt_align", bool),
-                                       ("timer_mode", libxl_timer_mode),
-                                       ("nested_hvm", bool),
+                [("hvm", Struct(None, [("firmware",         string),
+                                       ("pae",              libxl_defbool),
+                                       ("apic",             libxl_defbool),
+                                       ("acpi",             libxl_defbool),
+                                       ("acpi_s3",          libxl_defbool),
+                                       ("acpi_s4",          libxl_defbool),
+                                       ("nx",               libxl_defbool),
+                                       ("viridian",         libxl_defbool),
+                                       ("timeoffset",       string),
+                                       ("hpet",             libxl_defbool),
+                                       ("vpt_align",        libxl_defbool),
+                                       ("timer_mode",       libxl_timer_mode),
+                                       ("nested_hvm",       libxl_defbool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
@@ -273,13 +273,13 @@ libxl_domain_build_info = Struct("domain
                                        
                                        ("serial",           string),
                                        ("boot",             string),
-                                       ("usb",              bool),
+                                       ("usb",              libxl_defbool),
                                        # usbdevice:
                                        # - "tablet" for absolute mouse,
                                        # - "mouse" for PS/2 protocol relative mouse
                                        ("usbdevice",        string),
                                        ("soundhw",          string),
-                                       ("xen_platform_pci", bool),
+                                       ("xen_platform_pci", libxl_defbool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", MemKB),
@@ -289,7 +289,7 @@ libxl_domain_build_info = Struct("domain
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
-                                      ("e820_host", bool),
+                                      ("e820_host", libxl_defbool),
                                       ])),
                  ])),
     ],
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -672,8 +672,7 @@ static void parse_config_data(const char
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
-        b_info->disable_migrate = l;
+    xlu_cfg_get_defbool(config, "nomigrate", &b_info->disable_migrate, 0);
 
     if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
         const char *s = libxl_tsc_mode_to_string(l);
@@ -709,24 +708,16 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
-        if (!xlu_cfg_get_long (config, "pae", &l, 0))
-            b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l, 0))
-            b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
-            b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
-            b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
-            b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l, 0))
-            b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
-            b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
-            b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
-            b_info->u.hvm.vpt_align = l;
+
+        xlu_cfg_get_defbool(config, "pae", &b_info->u.hvm.pae, 0);
+        xlu_cfg_get_defbool(config, "apic", &b_info->u.hvm.apic, 0);
+        xlu_cfg_get_defbool(config, "acpi", &b_info->u.hvm.acpi, 0);
+        xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
+        xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
+        xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
+        xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
+        xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
+        xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
 
         if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
             const char *s = libxl_timer_mode_to_string(l);
@@ -751,8 +742,7 @@ static void parse_config_data(const char
             }
         }
 
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
-            b_info->u.hvm.nested_hvm = l;
+        xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -992,19 +982,10 @@ skip_vfb:
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
-        switch (c_info->type) {
-        case LIBXL_DOMAIN_TYPE_HVM:
-            fprintf(stderr, "Can't do e820_host in HVM mode!");
-            break;
-        case LIBXL_DOMAIN_TYPE_PV:
-            if (l)
-                b_info->u.pv.e820_host = true;
-            break;
-        default:
-            abort();
-        }
-    }
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
+        xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
+    }
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -1022,7 +1003,7 @@ skip_vfb:
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
-            b_info->u.pv.e820_host = true;
+            libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
@@ -1214,12 +1195,12 @@ skip_vfb:
             b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
-        if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            b_info->u.hvm.usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
+        xlu_cfg_replace_string (config, "usbdevice",
+                                &b_info->u.hvm.usbdevice, 0);
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            b_info->u.hvm.xen_platform_pci = l;
+        xlu_cfg_get_defbool(config, "xen_platform_pci",
+                            &b_info->u.hvm.xen_platform_pci, 0);
     }
 
     xlu_cfg_destroy(config);
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -71,7 +71,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
     printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+    printf("\t(nomigrate %s)\n",
+           libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
         int i;
@@ -91,16 +92,22 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
         printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
         printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
+        printf("\t\t\t(apic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.apic));
+        printf("\t\t\t(acpi %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.acpi));
+        printf("\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
+        printf("\t\t\t(viridian %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.viridian));
+        printf("\t\t\t(hpet %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.hpet));
+        printf("\t\t\t(vpt_align %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vpt_align));
         printf("\t\t\t(timer_mode %s)\n",
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(nestedhvm %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
 
@@ -125,7 +132,7 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
         printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
@@ -134,7 +141,8 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t\t(e820_host %s)\n",
+               libxl_defbool_to_string(b_info->u.pv.e820_host));
         printf("\t\t)\n");
         break;
     default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaH-0004Xd-2p; Thu, 23 Feb 2012 13:19: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 1S0YaE-0004Vt-IX
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:43 +0000
Received: from [85.158.139.83:42022] by server-9.bemta-5.messagelabs.com id
	C9/5C-30171-DEC364F4; Thu, 23 Feb 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330003172!16290429!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17736 invoked from network); 23 Feb 2012 13:19:40 -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;
	23 Feb 2012 13:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374665"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:39 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:39 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Hx;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 141ed25af0d954e270e3bca9f482efb4070abf0d
Message-ID: <141ed25af0d954e270e3.1330002127@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 18 of 26 V3] libxl: make boolean members of
 libxl_domain_build_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID 141ed25af0d954e270e3bca9f482efb4070abf0d
# Parent  a27058f39b2cb2064e3370dfc216f08c49f0517d
libxl: make boolean members of libxl_domain_build_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

This just covers the obvious ones.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Feb 23 12:31:17 2012 +0000
@@ -352,6 +352,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
+    rc = libxl__domain_build_info_setdefault(gc, info);
+    if (rc) goto out;
+
     rc = ERROR_INVAL;
     if (!disk)
         goto out;
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -73,7 +73,6 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
     b_info->type = c_info->type;
 
@@ -88,17 +87,7 @@ void libxl_domain_build_info_init(libxl_
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->u.hvm.firmware = NULL;
-        b_info->u.hvm.pae = 1;
-        b_info->u.hvm.apic = 1;
-        b_info->u.hvm.acpi = 1;
-        b_info->u.hvm.acpi_s3 = 1;
-        b_info->u.hvm.acpi_s4 = 1;
-        b_info->u.hvm.nx = 1;
-        b_info->u.hvm.viridian = 0;
-        b_info->u.hvm.hpet = 1;
-        b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
 
         b_info->u.hvm.stdvga = 0;
@@ -106,9 +95,7 @@ void libxl_domain_build_info_init(libxl_
         b_info->u.hvm.vnc.display = 0;
         b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
-        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 0;
@@ -141,6 +128,8 @@ int libxl__domain_build_info_setdefault(
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->target_memkb = b_info->max_memkb;
 
+    libxl_defbool_setdefault(&b_info->disable_migrate, false);
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
@@ -151,6 +140,19 @@ int libxl__domain_build_info_setdefault(
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
 
+        libxl_defbool_setdefault(&b_info->u.hvm.pae,                true);
+        libxl_defbool_setdefault(&b_info->u.hvm.apic,               true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi,               true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3,            true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4,            true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nx,                 true);
+        libxl_defbool_setdefault(&b_info->u.hvm.viridian,           false);
+        libxl_defbool_setdefault(&b_info->u.hvm.hpet,               true);
+        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align,          true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm,         false);
+        libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
+
         if (!b_info->u.hvm.boot) {
             b_info->u.hvm.boot = strdup("cda");
             if (!b_info->u.hvm.boot) return ERROR_NOMEM;
@@ -165,6 +167,7 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
         if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
@@ -220,11 +223,11 @@ int libxl__domain_build(libxl__gc *gc,
 
         localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
-        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[1] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
-        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[3] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
-        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[5] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -426,7 +429,6 @@ retry_transaction:
     xs_rm(ctx->xsh, t, dom_path);
     libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
 
-
     xs_rm(ctx->xsh, t, vm_path);
     libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
@@ -673,7 +675,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
+        libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         int rc;
         rc = libxl__e820_alloc(gc, domid, d_config);
         if (rc)
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -192,7 +192,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.boot) {
             flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -202,7 +202,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (b_info->u.hvm.acpi) {
+        if (libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -431,7 +431,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-boot",
                     libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -441,7 +441,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (!b_info->u.hvm.acpi) {
+        if (!libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-no-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -943,7 +943,7 @@ int libxl__create_device_model(libxl__gc
         b_info->device_model_version
         == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
         libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                        "%d", !b_info->u.hvm.xen_platform_pci);
+                    "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:17 2012 +0000
@@ -88,7 +88,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         abort();
     }
     xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if ( info->disable_migrate )
+    if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -292,7 +292,7 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->apic_mode = info->u.hvm.apic;
+    va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
@@ -302,14 +302,19 @@ static int hvm_build_set_params(xc_inter
 
     xc_get_hvm_param(handle, domid, HVM_PARAM_STORE_PFN, store_mfn);
     xc_get_hvm_param(handle, domid, HVM_PARAM_CONSOLE_PFN, console_mfn);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED, info->u.hvm.pae);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED,
+                     libxl_defbool_val(info->u.hvm.pae));
 #if defined(__i386__) || defined(__x86_64__)
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN,
+                     libxl_defbool_val(info->u.hvm.viridian));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
+                     libxl_defbool_val(info->u.hvm.hpet));
 #endif
     xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
+                     libxl_defbool_val(info->u.hvm.vpt_align));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
+                     libxl_defbool_val(info->u.hvm.nested_hvm));
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
 
@@ -400,7 +405,7 @@ int libxl__domain_restore_common(libxl__
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
-        pae = info->u.hvm.pae;
+        pae = libxl_defbool_val(info->u.hvm.pae);
         no_incr_generationid = info->u.hvm.no_incr_generationid;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:17 2012 +0000
@@ -1378,7 +1378,7 @@ int libxl__e820_alloc(libxl__gc *gc, uin
         return ERROR_INVAL;
 
     b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
+    if (!libxl_defbool_val(b_info->u.pv.e820_host))
         return ERROR_INVAL;
 
     rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -229,7 +229,7 @@ libxl_domain_build_info = Struct("domain
     ("target_memkb",    MemKB),
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
-    ("disable_migrate", bool),
+    ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     
@@ -247,19 +247,19 @@ libxl_domain_build_info = Struct("domain
     ("extra_hvm",        libxl_string_list),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
-                [("hvm", Struct(None, [("firmware", string),
-                                       ("pae", bool),
-                                       ("apic", bool),
-                                       ("acpi", bool),
-                                       ("acpi_s3", bool),
-                                       ("acpi_s4", bool),
-                                       ("nx", bool),
-                                       ("viridian", bool),
-                                       ("timeoffset", string),
-                                       ("hpet", bool),
-                                       ("vpt_align", bool),
-                                       ("timer_mode", libxl_timer_mode),
-                                       ("nested_hvm", bool),
+                [("hvm", Struct(None, [("firmware",         string),
+                                       ("pae",              libxl_defbool),
+                                       ("apic",             libxl_defbool),
+                                       ("acpi",             libxl_defbool),
+                                       ("acpi_s3",          libxl_defbool),
+                                       ("acpi_s4",          libxl_defbool),
+                                       ("nx",               libxl_defbool),
+                                       ("viridian",         libxl_defbool),
+                                       ("timeoffset",       string),
+                                       ("hpet",             libxl_defbool),
+                                       ("vpt_align",        libxl_defbool),
+                                       ("timer_mode",       libxl_timer_mode),
+                                       ("nested_hvm",       libxl_defbool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
@@ -273,13 +273,13 @@ libxl_domain_build_info = Struct("domain
                                        
                                        ("serial",           string),
                                        ("boot",             string),
-                                       ("usb",              bool),
+                                       ("usb",              libxl_defbool),
                                        # usbdevice:
                                        # - "tablet" for absolute mouse,
                                        # - "mouse" for PS/2 protocol relative mouse
                                        ("usbdevice",        string),
                                        ("soundhw",          string),
-                                       ("xen_platform_pci", bool),
+                                       ("xen_platform_pci", libxl_defbool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", MemKB),
@@ -289,7 +289,7 @@ libxl_domain_build_info = Struct("domain
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
-                                      ("e820_host", bool),
+                                      ("e820_host", libxl_defbool),
                                       ])),
                  ])),
     ],
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -672,8 +672,7 @@ static void parse_config_data(const char
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
-        b_info->disable_migrate = l;
+    xlu_cfg_get_defbool(config, "nomigrate", &b_info->disable_migrate, 0);
 
     if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
         const char *s = libxl_tsc_mode_to_string(l);
@@ -709,24 +708,16 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
-        if (!xlu_cfg_get_long (config, "pae", &l, 0))
-            b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l, 0))
-            b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
-            b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
-            b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
-            b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l, 0))
-            b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
-            b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
-            b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
-            b_info->u.hvm.vpt_align = l;
+
+        xlu_cfg_get_defbool(config, "pae", &b_info->u.hvm.pae, 0);
+        xlu_cfg_get_defbool(config, "apic", &b_info->u.hvm.apic, 0);
+        xlu_cfg_get_defbool(config, "acpi", &b_info->u.hvm.acpi, 0);
+        xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
+        xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
+        xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
+        xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
+        xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
+        xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
 
         if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
             const char *s = libxl_timer_mode_to_string(l);
@@ -751,8 +742,7 @@ static void parse_config_data(const char
             }
         }
 
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
-            b_info->u.hvm.nested_hvm = l;
+        xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -992,19 +982,10 @@ skip_vfb:
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
-        switch (c_info->type) {
-        case LIBXL_DOMAIN_TYPE_HVM:
-            fprintf(stderr, "Can't do e820_host in HVM mode!");
-            break;
-        case LIBXL_DOMAIN_TYPE_PV:
-            if (l)
-                b_info->u.pv.e820_host = true;
-            break;
-        default:
-            abort();
-        }
-    }
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
+        xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
+    }
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -1022,7 +1003,7 @@ skip_vfb:
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
-            b_info->u.pv.e820_host = true;
+            libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
@@ -1214,12 +1195,12 @@ skip_vfb:
             b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
-        if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            b_info->u.hvm.usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
+        xlu_cfg_replace_string (config, "usbdevice",
+                                &b_info->u.hvm.usbdevice, 0);
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            b_info->u.hvm.xen_platform_pci = l;
+        xlu_cfg_get_defbool(config, "xen_platform_pci",
+                            &b_info->u.hvm.xen_platform_pci, 0);
     }
 
     xlu_cfg_destroy(config);
diff -r a27058f39b2c -r 141ed25af0d9 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -71,7 +71,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
     printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+    printf("\t(nomigrate %s)\n",
+           libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
         int i;
@@ -91,16 +92,22 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
         printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
         printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
+        printf("\t\t\t(apic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.apic));
+        printf("\t\t\t(acpi %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.acpi));
+        printf("\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
+        printf("\t\t\t(viridian %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.viridian));
+        printf("\t\t\t(hpet %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.hpet));
+        printf("\t\t\t(vpt_align %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vpt_align));
         printf("\t\t\t(timer_mode %s)\n",
                libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(nestedhvm %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
 
@@ -125,7 +132,7 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
         printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
@@ -134,7 +141,8 @@ void printf_info_sexp(int domid, libxl_d
         printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t\t(e820_host %s)\n",
+               libxl_defbool_to_string(b_info->u.pv.e820_host));
         printf("\t\t)\n");
         break;
     default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaK-0004aZ-8M; Thu, 23 Feb 2012 13:19:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaI-0004VL-Jt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!6
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26682 invoked from network); 23 Feb 2012 13:19:39 -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;
	23 Feb 2012 13:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109344"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:38 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:38 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-De;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: ee62ab4c3c9d511b201a097e42e6f3f643d2ba5f
Message-ID: <ee62ab4c3c9d511b201a.1330002122@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 13 of 26 V3] libxl: vfb/vkb: use
	_init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID ee62ab4c3c9d511b201a097e42e6f3f643d2ba5f
# Parent  001f5db5cdb8097051a1fb7b6f5c21a63cfd7872
libxl: vfb/vkb: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -2101,9 +2101,13 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb)
+void libxl_device_vkb_init(libxl_device_vkb *vkb)
 {
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
+}
+
+int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
+{
     return 0;
 }
 
@@ -2129,6 +2133,9 @@ int libxl_device_vkb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vkb_setdefault(gc, vkb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
@@ -2206,12 +2213,11 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
+void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
-    vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
@@ -2219,6 +2225,15 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     vfb->sdl.opengl = 0;
     vfb->sdl.display = NULL;
     vfb->sdl.xauthority = NULL;
+}
+
+int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
+{
+    if (!vfb->vnc.listen) {
+        vfb->vnc.listen = strdup("127.0.0.1");
+        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    }
+
     return 0;
 }
 
@@ -2243,6 +2258,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vfb_setdefault(gc, vfb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
@@ -536,7 +536,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
+void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -544,7 +544,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
+void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -594,9 +594,7 @@ static int do_domain_create(libxl__gc *g
         libxl__device_console_add(gc, domid, &console, &state);
         libxl_device_console_dispose(&console);
 
-        ret = libxl_device_vkb_init(ctx, &vkb);
-        if ( ret )
-            goto error_out;
+        libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -614,8 +614,8 @@ static int libxl__vfb_and_vkb_from_hvm_g
     if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
         return ERROR_INVAL;
 
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
+    libxl_device_vfb_init(vfb);
+    libxl_device_vkb_init(vkb);
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
@@ -194,6 +194,8 @@ _hidden int libxl__domain_build_info_set
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
+_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
+_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -935,12 +935,12 @@ skip:
 
             d_config->vfbs = (libxl_device_vfb *) realloc(d_config->vfbs, sizeof(libxl_device_vfb) * (d_config->num_vfbs + 1));
             vfb = d_config->vfbs + d_config->num_vfbs;
-            libxl_device_vfb_init(ctx, vfb);
+            libxl_device_vfb_init(vfb);
             vfb->devid = d_config->num_vfbs;
 
             d_config->vkbs = (libxl_device_vkb *) realloc(d_config->vkbs, sizeof(libxl_device_vkb) * (d_config->num_vkbs + 1));
             vkb = d_config->vkbs + d_config->num_vkbs;
-            libxl_device_vkb_init(ctx, vkb);
+            libxl_device_vkb_init(vkb);
             vkb->devid = d_config->num_vkbs;
 
             p = strtok(buf2, ",");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaK-0004aZ-8M; Thu, 23 Feb 2012 13:19:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaI-0004VL-Jt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!6
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26682 invoked from network); 23 Feb 2012 13:19:39 -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;
	23 Feb 2012 13:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109344"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:38 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:38 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-De;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: ee62ab4c3c9d511b201a097e42e6f3f643d2ba5f
Message-ID: <ee62ab4c3c9d511b201a.1330002122@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 13 of 26 V3] libxl: vfb/vkb: use
	_init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID ee62ab4c3c9d511b201a097e42e6f3f643d2ba5f
# Parent  001f5db5cdb8097051a1fb7b6f5c21a63cfd7872
libxl: vfb/vkb: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -2101,9 +2101,13 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb)
+void libxl_device_vkb_init(libxl_device_vkb *vkb)
 {
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
+}
+
+int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
+{
     return 0;
 }
 
@@ -2129,6 +2133,9 @@ int libxl_device_vkb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vkb_setdefault(gc, vkb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
@@ -2206,12 +2213,11 @@ out:
 }
 
 /******************************************************************************/
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
+void libxl_device_vfb_init(libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
-    vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
@@ -2219,6 +2225,15 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     vfb->sdl.opengl = 0;
     vfb->sdl.display = NULL;
     vfb->sdl.xauthority = NULL;
+}
+
+int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
+{
+    if (!vfb->vnc.listen) {
+        vfb->vnc.listen = strdup("127.0.0.1");
+        if (!vfb->vnc.listen) return ERROR_NOMEM;
+    }
+
     return 0;
 }
 
@@ -2243,6 +2258,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vfb_setdefault(gc, vfb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
@@ -536,7 +536,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
+void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -544,7 +544,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
+void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -594,9 +594,7 @@ static int do_domain_create(libxl__gc *g
         libxl__device_console_add(gc, domid, &console, &state);
         libxl_device_console_dispose(&console);
 
-        ret = libxl_device_vkb_init(ctx, &vkb);
-        if ( ret )
-            goto error_out;
+        libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -614,8 +614,8 @@ static int libxl__vfb_and_vkb_from_hvm_g
     if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
         return ERROR_INVAL;
 
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
+    libxl_device_vfb_init(vfb);
+    libxl_device_vkb_init(vkb);
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
@@ -194,6 +194,8 @@ _hidden int libxl__domain_build_info_set
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic);
+_hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
+_hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 001f5db5cdb8 -r ee62ab4c3c9d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -935,12 +935,12 @@ skip:
 
             d_config->vfbs = (libxl_device_vfb *) realloc(d_config->vfbs, sizeof(libxl_device_vfb) * (d_config->num_vfbs + 1));
             vfb = d_config->vfbs + d_config->num_vfbs;
-            libxl_device_vfb_init(ctx, vfb);
+            libxl_device_vfb_init(vfb);
             vfb->devid = d_config->num_vfbs;
 
             d_config->vkbs = (libxl_device_vkb *) realloc(d_config->vkbs, sizeof(libxl_device_vkb) * (d_config->num_vkbs + 1));
             vkb = d_config->vkbs + d_config->num_vkbs;
-            libxl_device_vkb_init(ctx, vkb);
+            libxl_device_vkb_init(vkb);
             vkb->devid = d_config->num_vkbs;
 
             p = strtok(buf2, ",");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaL-0004cp-Mi; Thu, 23 Feb 2012 13:19:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaK-0004Wf-LW
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!7
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26913 invoked from network); 23 Feb 2012 13:19:42 -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;
	23 Feb 2012 13:19:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109353"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:41 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:41 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-HK;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: a27058f39b2cb2064e3370dfc216f08c49f0517d
Message-ID: <a27058f39b2cb2064e33.1330002126@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 17 of 26 V3] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID a27058f39b2cb2064e3370dfc216f08c49f0517d
# Parent  de102741f1e7dd0dec7df9edae7fda684bf7aa7b
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r de102741f1e7 -r a27058f39b2c tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
@@ -20,8 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
-             "libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -53,8 +53,6 @@ void libxl_domain_config_dispose(libxl_d
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->hap = 1;
-    c_info->oos = 1;
 }
 
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
@@ -63,6 +61,11 @@ int libxl__domain_create_info_setdefault
     if (!c_info->type)
         return ERROR_INVAL;
 
+    if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&c_info->hap, true);
+        libxl_defbool_setdefault(&c_info->oos, true);
+    }
+
     return 0;
 }
 
@@ -365,8 +368,8 @@ int libxl__domain_make(libxl__gc *gc, li
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
-        flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
-        flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
+        flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+        flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
     *domid = -1;
 
@@ -518,6 +521,9 @@ static int do_domain_create(libxl__gc *g
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -205,8 +205,8 @@ libxl_version_info = Struct("version_inf
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
-    ("hap",          bool),
-    ("oos",          bool),
+    ("hap",          libxl_defbool),
+    ("oos",          libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -556,8 +556,7 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l, 0))
-        c_info->hap = l;
+    xlu_cfg_get_defbool(config, "hap", &c_info->hap, 0);
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.\n");
@@ -573,8 +572,7 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l, 0))
-        c_info->oos = l;
+    xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -41,8 +41,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
+    printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaL-0004cp-Mi; Thu, 23 Feb 2012 13:19:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaK-0004Wf-LW
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!7
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26913 invoked from network); 23 Feb 2012 13:19:42 -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;
	23 Feb 2012 13:19:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109353"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:41 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:41 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-HK;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: a27058f39b2cb2064e3370dfc216f08c49f0517d
Message-ID: <a27058f39b2cb2064e33.1330002126@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 17 of 26 V3] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000277 0
# Node ID a27058f39b2cb2064e3370dfc216f08c49f0517d
# Parent  de102741f1e7dd0dec7df9edae7fda684bf7aa7b
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This allows them to be set via the _init/_setdefault methods.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r de102741f1e7 -r a27058f39b2c tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
@@ -20,8 +20,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
-             "libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -53,8 +53,6 @@ void libxl_domain_config_dispose(libxl_d
 void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->hap = 1;
-    c_info->oos = 1;
 }
 
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
@@ -63,6 +61,11 @@ int libxl__domain_create_info_setdefault
     if (!c_info->type)
         return ERROR_INVAL;
 
+    if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&c_info->hap, true);
+        libxl_defbool_setdefault(&c_info->oos, true);
+    }
+
     return 0;
 }
 
@@ -365,8 +368,8 @@ int libxl__domain_make(libxl__gc *gc, li
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
-        flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
-        flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
+        flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+        flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
     *domid = -1;
 
@@ -518,6 +521,9 @@ static int do_domain_create(libxl__gc *g
     ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
     if (ret) goto error_out;
 
+    ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -205,8 +205,8 @@ libxl_version_info = Struct("version_inf
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
-    ("hap",          bool),
-    ("oos",          bool),
+    ("hap",          libxl_defbool),
+    ("oos",          libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -556,8 +556,7 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l, 0))
-        c_info->hap = l;
+    xlu_cfg_get_defbool(config, "hap", &c_info->hap, 0);
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.\n");
@@ -573,8 +572,7 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l, 0))
-        c_info->oos = l;
+    xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
diff -r de102741f1e7 -r a27058f39b2c tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:17 2012 +0000
@@ -41,8 +41,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
+    printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaN-0004g0-AU; Thu, 23 Feb 2012 13:19:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaL-0004Wt-3C
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26521 invoked from network); 23 Feb 2012 13:19:37 -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;
	23 Feb 2012 13:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109340"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:37 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Ge;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: de102741f1e7dd0dec7df9edae7fda684bf7aa7b
Message-ID: <de102741f1e7dd0dec7d.1330002125@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 16 of 26 V3] libxl: add new "defbool" built in
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000277 0
# Node ID de102741f1e7dd0dec7df9edae7fda684bf7aa7b
# Parent  b66dbc17bc1b2f6ffcccc3dd5440105247ce65c3
libxl: add new "defbool" built in type.

This type is a but like a "boolean" but with a third state "default" (so really
I suppose it's a tristate).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
@@ -20,7 +20,8 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
+             "libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
@@ -55,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    "
               ty.pass_arg(v, parent is None))
     elif ty.typename in ["bool"]:
         s += "%s = rand() %% 2;\n" % v
+    elif ty.typename in ["libxl_defbool"]:
+        s += "libxl_defbool_set(%s, !!rand() %% 1);\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
     elif ty.private:
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -184,6 +184,47 @@ void libxl_key_value_list_dispose(libxl_
     free(kvl);
 }
 
+#define LIBXL__DEFBOOL_DEFAULT (0)
+#define LIBXL__DEFBOOL_FALSE (-1)
+#define LIBXL__DEFBOOL_TRUE (1)
+
+void libxl_defbool_set(libxl_defbool *db, bool b)
+{
+    db->val = b ? LIBXL__DEFBOOL_TRUE : LIBXL__DEFBOOL_FALSE;
+}
+
+void libxl_defbool_unset(libxl_defbool *db)
+{
+    db->val = LIBXL__DEFBOOL_DEFAULT;
+}
+
+bool libxl_defbool_is_default(libxl_defbool db)
+{
+    return !db.val;
+}
+
+void libxl_defbool_setdefault(libxl_defbool *db, bool b)
+{
+    if (libxl_defbool_is_default(*db))
+        libxl_defbool_set(db, b);
+}
+
+bool libxl_defbool_val(libxl_defbool db)
+{
+    assert(!libxl_defbool_is_default(db));
+    return db.val > 0;
+}
+
+const char *libxl_defbool_to_string(libxl_defbool b)
+{
+    if (b.val < 0)
+        return "False";
+    else if (b.val > 0)
+        return "True";
+    else
+        return "<default>";
+}
+
 /******************************************************************************/
 
 
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
@@ -243,6 +243,30 @@ typedef struct {
 struct libxl_event;
 typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
 
+/*
+ * A boolean variable with an explicit default state.
+ *
+ * Users should treat this struct as opaque and use the following
+ * defined macros and accessor functions.
+ *
+ * To allow users of the library to naively select all defaults this
+ * state is represented as 0. False is < 0 and True is > 0.
+ */
+typedef struct {
+    int val;
+} libxl_defbool;
+
+void libxl_defbool_set(libxl_defbool *db, bool b);
+/* Resets to default */
+void libxl_defbool_unset(libxl_defbool *db);
+/* Sets db only if it is currently == default */
+void libxl_defbool_setdefault(libxl_defbool *db, bool b);
+bool libxl_defbool_is_default(libxl_defbool db);
+/* db must not be == default */
+bool libxl_defbool_val(libxl_defbool db);
+
+const char *libxl_defbool_to_string(libxl_defbool b);
+
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_json.c	Thu Feb 23 12:31:17 2012 +0000
@@ -85,6 +85,12 @@ yajl_gen_status libxl__yajl_gen_enum(yaj
 /*
  * YAJL generators for builtin libxl types.
  */
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
+                                       libxl_defbool *db)
+{
+    return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
+}
+
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -5,6 +5,8 @@
 
 namespace("libxl_")
 
+libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
+
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Feb 23 12:31:17 2012 +0000
@@ -237,6 +237,17 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b,
+                     int dont_warn)
+{
+    int ret;
+    long l;
+
+    ret = xlu_cfg_get_long(cfg, n, &l, dont_warn);
+    if (ret) return ret;
+    libxl_defbool_set(b, !!l);
+    return 0;
+}
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxlutil.h	Thu Feb 23 12:31:17 2012 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r b66dbc17bc1b -r de102741f1e7 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
@@ -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_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),
     "libxl_mac":            ("int array",              "Mac_val(gc, lg, &%(c)s, %(o)s)",    "Val_mac(&%(c)s)"),
diff -r b66dbc17bc1b -r de102741f1e7 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Thu Feb 23 12:31:17 2012 +0000
@@ -195,6 +195,33 @@ static int Uuid_val(caml_gc *gc, struct 
 	CAMLreturn(0);
 }
 
+static value Val_defbool(libxl_defbool c_val)
+{
+	CAMLparam0();
+	CAMLlocal1(v);
+
+	if (libxl_defbool_is_default(c_val))
+		v = Val_none;
+	else {
+		bool b = libxl_defbool_val(c_val);
+		v = Val_some(b ? Val_bool(true) : Val_bool(false));
+	}
+	CAMLreturn(v);
+}
+
+static libxl_defbool Defbool_val(value v)
+{
+	CAMLparam1(v);
+	libxl_defbool db;
+	if (v == Val_none)
+		libxl_defbool_unset(&db);
+	else {
+		bool b = Bool_val(Some_val(v));
+		libxl_defbool_set(&db, b);
+	}
+	return db;
+}
+
 static value Val_hwcap(libxl_hwcap *c_val)
 {
 	CAMLparam0();
diff -r b66dbc17bc1b -r de102741f1e7 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/python/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
@@ -4,11 +4,13 @@ import sys,os
 
 import idl
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
 
 def py_type(ty):
     if ty == idl.bool:
         return TYPE_BOOL
+    if ty.typename == "libxl_defbool":
+        return TYPE_DEFBOOL
     if isinstance(ty, idl.Enumeration):
         return TYPE_UINT
     if isinstance(ty, idl.Number):
@@ -44,6 +46,8 @@ def py_decls(ty):
         for f in ty.fields:
             if py_type(f.type) is not None:
                 continue
+            if py_type(f.type) == TYPE_DEFBOOL:
+                continue
             if ty.marshal_out():
                 l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
                     fsanitize(f.type.typename), f.type.typename, f.name))
@@ -62,6 +66,8 @@ def py_attrib_get(ty, f):
         l.append('    ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
         l.append('    Py_INCREF(ret);')
         l.append('    return ret;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_get(&self->obj.%s);'%f.name)
     elif t == TYPE_INT:
         l.append('    return genwrap__ll_get(self->obj.%s);'%f.name)
     elif t == TYPE_UINT:
@@ -85,6 +91,8 @@ def py_attrib_set(ty, f):
     if t == TYPE_BOOL:
         l.append('    self->obj.%s = (NULL == v || Py_None == v || Py_False == v) ? 0 : 1;'%f.name)
         l.append('    return 0;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
     elif t == TYPE_UINT or t == TYPE_INT:
         l.append('    %slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
         l.append('    int ret;')
@@ -275,6 +283,8 @@ _hidden PyObject *genwrap__ull_get(unsig
 _hidden int genwrap__ull_set(PyObject *v, unsigned long long *val, unsigned long long mask);
 _hidden PyObject *genwrap__ll_get(long long val);
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
+_hidden PyObject *genwrap__defbool_get(libxl_defbool *db);
+_hidden int genwrap__defbool_set(PyObject *v, libxl_defbool *db);
 
 """ % " ".join(sys.argv))
     for ty in [ty for ty in types if isinstance(ty, idl.Aggregate)]:
diff -r b66dbc17bc1b -r de102741f1e7 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -156,6 +156,21 @@ int genwrap__ll_set(PyObject *v, long lo
     return 0;
 }
 
+PyObject *genwrap__defbool_get(libxl_defbool *db)
+{
+    PyObject *ret;
+    ret = libxl_defbool_val(*db) ? Py_True : Py_False;
+    Py_INCREF(ret);
+    return ret;
+}
+
+int genwrap__defbool_set(PyObject *v, libxl_defbool *db)
+{
+    bool val = !(NULL == v || Py_None == v || Py_False == v);
+    libxl_defbool_set(db, val);
+    return 0;
+}
+
 static int fixed_bytearray_set(PyObject *v, uint8_t *ptr, size_t len)
 {
     char *tmp;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaN-0004g0-AU; Thu, 23 Feb 2012 13:19:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaL-0004Wt-3C
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26521 invoked from network); 23 Feb 2012 13:19:37 -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;
	23 Feb 2012 13:19:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109340"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:37 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Ge;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: de102741f1e7dd0dec7df9edae7fda684bf7aa7b
Message-ID: <de102741f1e7dd0dec7d.1330002125@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 16 of 26 V3] libxl: add new "defbool" built in
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000277 0
# Node ID de102741f1e7dd0dec7df9edae7fda684bf7aa7b
# Parent  b66dbc17bc1b2f6ffcccc3dd5440105247ce65c3
libxl: add new "defbool" built in type.

This type is a but like a "boolean" but with a third state "default" (so really
I suppose it's a tristate).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:17 2012 +0000
@@ -20,7 +20,8 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
+             "libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list"]
 
@@ -55,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    "
               ty.pass_arg(v, parent is None))
     elif ty.typename in ["bool"]:
         s += "%s = rand() %% 2;\n" % v
+    elif ty.typename in ["libxl_defbool"]:
+        s += "libxl_defbool_set(%s, !!rand() %% 1);\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
     elif ty.private:
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -184,6 +184,47 @@ void libxl_key_value_list_dispose(libxl_
     free(kvl);
 }
 
+#define LIBXL__DEFBOOL_DEFAULT (0)
+#define LIBXL__DEFBOOL_FALSE (-1)
+#define LIBXL__DEFBOOL_TRUE (1)
+
+void libxl_defbool_set(libxl_defbool *db, bool b)
+{
+    db->val = b ? LIBXL__DEFBOOL_TRUE : LIBXL__DEFBOOL_FALSE;
+}
+
+void libxl_defbool_unset(libxl_defbool *db)
+{
+    db->val = LIBXL__DEFBOOL_DEFAULT;
+}
+
+bool libxl_defbool_is_default(libxl_defbool db)
+{
+    return !db.val;
+}
+
+void libxl_defbool_setdefault(libxl_defbool *db, bool b)
+{
+    if (libxl_defbool_is_default(*db))
+        libxl_defbool_set(db, b);
+}
+
+bool libxl_defbool_val(libxl_defbool db)
+{
+    assert(!libxl_defbool_is_default(db));
+    return db.val > 0;
+}
+
+const char *libxl_defbool_to_string(libxl_defbool b)
+{
+    if (b.val < 0)
+        return "False";
+    else if (b.val > 0)
+        return "True";
+    else
+        return "<default>";
+}
+
 /******************************************************************************/
 
 
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:17 2012 +0000
@@ -243,6 +243,30 @@ typedef struct {
 struct libxl_event;
 typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
 
+/*
+ * A boolean variable with an explicit default state.
+ *
+ * Users should treat this struct as opaque and use the following
+ * defined macros and accessor functions.
+ *
+ * To allow users of the library to naively select all defaults this
+ * state is represented as 0. False is < 0 and True is > 0.
+ */
+typedef struct {
+    int val;
+} libxl_defbool;
+
+void libxl_defbool_set(libxl_defbool *db, bool b);
+/* Resets to default */
+void libxl_defbool_unset(libxl_defbool *db);
+/* Sets db only if it is currently == default */
+void libxl_defbool_setdefault(libxl_defbool *db, bool b);
+bool libxl_defbool_is_default(libxl_defbool db);
+/* db must not be == default */
+bool libxl_defbool_val(libxl_defbool db);
+
+const char *libxl_defbool_to_string(libxl_defbool b);
+
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_json.c	Thu Feb 23 12:31:17 2012 +0000
@@ -85,6 +85,12 @@ yajl_gen_status libxl__yajl_gen_enum(yaj
 /*
  * YAJL generators for builtin libxl types.
  */
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
+                                       libxl_defbool *db)
+{
+    return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
+}
+
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -5,6 +5,8 @@
 
 namespace("libxl_")
 
+libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
+
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Feb 23 12:31:17 2012 +0000
@@ -237,6 +237,17 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b,
+                     int dont_warn)
+{
+    int ret;
+    long l;
+
+    ret = xlu_cfg_get_long(cfg, n, &l, dont_warn);
+    if (ret) return ret;
+    libxl_defbool_set(b, !!l);
+    return 0;
+}
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r b66dbc17bc1b -r de102741f1e7 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxlutil.h	Thu Feb 23 12:31:17 2012 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r b66dbc17bc1b -r de102741f1e7 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
@@ -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_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),
     "libxl_mac":            ("int array",              "Mac_val(gc, lg, &%(c)s, %(o)s)",    "Val_mac(&%(c)s)"),
diff -r b66dbc17bc1b -r de102741f1e7 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Thu Feb 23 12:31:17 2012 +0000
@@ -195,6 +195,33 @@ static int Uuid_val(caml_gc *gc, struct 
 	CAMLreturn(0);
 }
 
+static value Val_defbool(libxl_defbool c_val)
+{
+	CAMLparam0();
+	CAMLlocal1(v);
+
+	if (libxl_defbool_is_default(c_val))
+		v = Val_none;
+	else {
+		bool b = libxl_defbool_val(c_val);
+		v = Val_some(b ? Val_bool(true) : Val_bool(false));
+	}
+	CAMLreturn(v);
+}
+
+static libxl_defbool Defbool_val(value v)
+{
+	CAMLparam1(v);
+	libxl_defbool db;
+	if (v == Val_none)
+		libxl_defbool_unset(&db);
+	else {
+		bool b = Bool_val(Some_val(v));
+		libxl_defbool_set(&db, b);
+	}
+	return db;
+}
+
 static value Val_hwcap(libxl_hwcap *c_val)
 {
 	CAMLparam0();
diff -r b66dbc17bc1b -r de102741f1e7 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/python/genwrap.py	Thu Feb 23 12:31:17 2012 +0000
@@ -4,11 +4,13 @@ import sys,os
 
 import idl
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
 
 def py_type(ty):
     if ty == idl.bool:
         return TYPE_BOOL
+    if ty.typename == "libxl_defbool":
+        return TYPE_DEFBOOL
     if isinstance(ty, idl.Enumeration):
         return TYPE_UINT
     if isinstance(ty, idl.Number):
@@ -44,6 +46,8 @@ def py_decls(ty):
         for f in ty.fields:
             if py_type(f.type) is not None:
                 continue
+            if py_type(f.type) == TYPE_DEFBOOL:
+                continue
             if ty.marshal_out():
                 l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
                     fsanitize(f.type.typename), f.type.typename, f.name))
@@ -62,6 +66,8 @@ def py_attrib_get(ty, f):
         l.append('    ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
         l.append('    Py_INCREF(ret);')
         l.append('    return ret;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_get(&self->obj.%s);'%f.name)
     elif t == TYPE_INT:
         l.append('    return genwrap__ll_get(self->obj.%s);'%f.name)
     elif t == TYPE_UINT:
@@ -85,6 +91,8 @@ def py_attrib_set(ty, f):
     if t == TYPE_BOOL:
         l.append('    self->obj.%s = (NULL == v || Py_None == v || Py_False == v) ? 0 : 1;'%f.name)
         l.append('    return 0;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
     elif t == TYPE_UINT or t == TYPE_INT:
         l.append('    %slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
         l.append('    int ret;')
@@ -275,6 +283,8 @@ _hidden PyObject *genwrap__ull_get(unsig
 _hidden int genwrap__ull_set(PyObject *v, unsigned long long *val, unsigned long long mask);
 _hidden PyObject *genwrap__ll_get(long long val);
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
+_hidden PyObject *genwrap__defbool_get(libxl_defbool *db);
+_hidden int genwrap__defbool_set(PyObject *v, libxl_defbool *db);
 
 """ % " ".join(sys.argv))
     for ty in [ty for ty in types if isinstance(ty, idl.Aggregate)]:
diff -r b66dbc17bc1b -r de102741f1e7 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -156,6 +156,21 @@ int genwrap__ll_set(PyObject *v, long lo
     return 0;
 }
 
+PyObject *genwrap__defbool_get(libxl_defbool *db)
+{
+    PyObject *ret;
+    ret = libxl_defbool_val(*db) ? Py_True : Py_False;
+    Py_INCREF(ret);
+    return ret;
+}
+
+int genwrap__defbool_set(PyObject *v, libxl_defbool *db)
+{
+    bool val = !(NULL == v || Py_None == v || Py_False == v);
+    libxl_defbool_set(db, val);
+    return 0;
+}
+
 static int fixed_bytearray_set(PyObject *v, uint8_t *ptr, size_t len)
 {
     char *tmp;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaP-0004jD-1e; Thu, 23 Feb 2012 13:19:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaN-0004YF-9X
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330003183!10389391!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13392 invoked from network); 23 Feb 2012 13:19:44 -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;
	23 Feb 2012 13:19:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374667"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:42 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:42 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Ms;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8b82b7435b7d5a42c52221b3827ddde746794f1b
Message-ID: <8b82b7435b7d5a42c522.1330002135@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 26 of 26 V3] libxl: autogenerate libxl_FOO_init
 and libxl_FOO_init_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000278 0
# Node ID 8b82b7435b7d5a42c52221b3827ddde746794f1b
# Parent  6dedf527d9b77f5ed3ca583683c00afd88c7bb6f
libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
@@ -78,6 +78,88 @@ def libxl_C_type_dispose(ty, v, indent =
         s = indent + s
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
+def libxl_init_members(ty, nesting = 0):
+    """Returns a list of members of ty which require a separate init"""
+
+    if isinstance(ty, idl.Aggregate):
+        return [f for f in ty.fields if not f.const and isinstance(f.type,idl.KeyedUnion)]
+    else:
+        return []
+    
+def _libxl_C_type_init(ty, v, indent = "    ", parent = None, subinit=False):
+    s = ""
+    if isinstance(ty, idl.KeyedUnion):
+        if parent is None:
+            raise Exception("KeyedUnion type must have a parent")
+        if subinit:
+            s += "switch (%s) {\n" % (parent + ty.keyvar.name)
+            for f in ty.fields:
+                (nparent,fexpr) = ty.member(v, f, parent is None)
+                s += "case %s:\n" % f.enumname
+                s += _libxl_C_type_init(f.type, fexpr, "    ", nparent)
+                s += "    break;\n"
+            s += "}\n"
+        else:
+            if ty.keyvar.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.init_val)
+            elif ty.keyvar.type.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.type.init_val)
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.init_fn is None):
+        for f in [f for f in ty.fields if not f.const]:
+            (nparent,fexpr) = ty.member(v, f, parent is None)
+            if f.init_val is not None:
+                s += "%s = %s;\n" % (fexpr, f.init_val)
+            else:
+                s += _libxl_C_type_init(f.type, fexpr, "", nparent)
+    else:
+        if ty.init_val is not None:
+            s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), ty.init_val)
+        elif ty.init_fn is not None:
+            s += "%s(%s);\n" % (ty.init_fn, ty.pass_arg(v, parent is None))
+
+    if s != "":
+        s = indent + s
+    return s.replace("\n", "\n%s" % indent).rstrip(indent)
+
+def libxl_C_type_init(ty):
+    s = ""
+    s += "void %s(%s)\n" % (ty.init_fn, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))
+    s += "{\n"
+    s += "    memset(p, '\\0', sizeof(*p));\n"
+    s += _libxl_C_type_init(ty, "p")
+    s += "}\n"
+    s += "\n"
+    return s
+
+def libxl_C_type_member_init(ty, field):
+    if not isinstance(field.type, idl.KeyedUnion):
+        raise Exception("Only KeyedUnion is supported for member init")
+
+    ku = field.type
+    
+    s = ""
+    s += "void %s(%s, %s)\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                ty.make_arg("p", passby=idl.PASS_BY_REFERENCE),
+                                ku.keyvar.type.make_arg(ku.keyvar.name))
+    s += "{\n"
+    
+    if ku.keyvar.init_val:
+        init_val = ku.keyvar.init_val
+    elif ku.keyvar.type.init_val:
+        init_val = ku.keyvar.type.init_val
+    else:
+        init_val = None
+        
+    if init_val is not None:
+        (nparent,fexpr) = ty.member(ty.pass_arg("p"), ku.keyvar, isref=True)
+        s += "    assert(%s == %s);\n" % (fexpr, init_val)
+        s += "    %s = %s;\n" % (fexpr, ku.keyvar.name)
+    (nparent,fexpr) = ty.member(ty.pass_arg("p"), field, isref=True)
+    s += _libxl_C_type_init(ku, fexpr, parent=nparent, subinit=True)
+    s += "}\n"
+    s += "\n"
+    return s
+
 def libxl_C_type_gen_json(ty, v, indent = "    ", parent = None):
     s = ""
     if parent is None:
@@ -199,6 +281,15 @@ if __name__ == '__main__':
         f.write(libxl_C_type_define(ty) + ";\n")
         if ty.dispose_fn is not None:
             f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
+        if ty.init_fn is not None:
+            f.write("void %s(%s);\n" % (ty.init_fn, ty.make_arg("p")))
+            for field in libxl_init_members(ty):
+                if not isinstance(field.type, idl.KeyedUnion):
+                    raise Exception("Only KeyedUnion is supported for member init")
+                ku = field.type
+                f.write("void %s(%s, %s);\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                               ty.make_arg("p"),
+                                               ku.keyvar.type.make_arg(ku.keyvar.name)))
         if ty.json_fn is not None:
             f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
         if isinstance(ty, idl.Enumeration):
@@ -227,7 +318,7 @@ if __name__ == '__main__':
 
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
-    for ty in [ty for ty in types+builtins if ty.json_fn is not None]:
+    for ty in [ty for ty in types if ty.json_fn is not None]:
         f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
@@ -264,6 +355,11 @@ if __name__ == '__main__':
         f.write("    memset(p, LIBXL_DTOR_POISON, sizeof(*p));\n")
         f.write("}\n")
         f.write("\n")
+        
+    for ty in [t for t in types if t.init_fn is not None and t.autogenerate_init_fn]:
+        f.write(libxl_C_type_init(ty))
+        for field in libxl_init_members(ty):
+            f.write(libxl_C_type_member_init(ty, field))
 
     for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("const char *%s_to_string(%s e)\n" % (ty.typename, ty.typename))
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/idl.py
--- a/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
@@ -51,6 +51,10 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
+        self.init_fn = kwargs.setdefault('init_fn', None)
+        self.init_val = kwargs.setdefault('init_val', None)
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', False)
+
         if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
@@ -144,12 +148,20 @@ class Field(object):
         self.name = name
         self.const = kwargs.setdefault('const', False)
         self.enumname = kwargs.setdefault('enumname', None)
+        self.init_val = kwargs.setdefault('init_val', None)
 
 class Aggregate(Type):
     """A type containing a collection of other types"""
     def __init__(self, kind, typename, fields, **kwargs):
         Type.__init__(self, typename, **kwargs)
 
+        if self.typename is not None:
+            self.init_fn = kwargs.setdefault('init_fn', self.typename + "_init")
+        else:
+            self.init_fn = kwargs.setdefault('init_fn', None)
+
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', True)
+
         self.kind = kind
 
         self.fields = []
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
@@ -44,6 +44,22 @@ Type.autogenerate_dispose_fn: (default: 
  Indicates if the above named Type.dispose_fn should be
  autogenerated.
 
+Type.init_val: (default: None)
+
+ C expression for the value to initialise instances of this type to.
+
+ If present takes precendence over init_fn (see below).
+
+Type.init_fn: (default: typename + "_init" if dir in [IN, BOTH] and
+                        type != None)
+
+ The name of the C function which will initialist Type.
+
+Type.autogenerate_init_fn: (default: True if dir in [IN, BOTH])
+
+ Indicates if the above named Type.init_fn should be
+ autogenerated.
+
 Type.json_fn: (default: typename + "_gen_json" or None if type == None)
 
  The name of the C function which will generate a YAJL data structure
@@ -105,10 +121,13 @@ idl.Aggregate
 
  Each field has the following properties:
 
-  Field.type    The type of the member (a idl.Type).
-  Field.name    The name of the member (can be None for anonymous
-                fields).
-  Field.const   Boolean, true if the member is const.
+  Field.type     The type of the member (a idl.Type).
+  Field.name     The name of the member (can be None for anonymous
+                 fields).
+  Field.const    Boolean, true if the member is const.
+  Field.init_val The initialisation value for this field. Takes
+                 precendence over both Field.type.init_val and
+                 Field.type.init_fn.
 
 idl.Struct
 
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -1227,11 +1227,6 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-void libxl_device_disk_init(libxl_device_disk *disk)
-{
-    memset(disk, 0x00, sizeof(libxl_device_disk));
-}
-
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
     int rc;
@@ -1718,10 +1713,6 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-void libxl_device_nic_init(libxl_device_nic *nic)
-{
-    memset(nic, '\0', sizeof(*nic));
-}
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
 {
@@ -2142,10 +2133,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vkb_init(libxl_device_vkb *vkb)
-{
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
-}
 
 int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
 {
@@ -2254,10 +2241,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vfb_init(libxl_device_vfb *vfb)
-{
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-}
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
@@ -3066,6 +3049,8 @@ int libxl_sched_credit_domain_get(libxl_
     struct xen_domctl_sched_credit sdom;
     int rc;
 
+    libxl_sched_credit_init(scinfo);
+
     rc = xc_sched_credit_domain_get(ctx->xch, domid, &sdom);
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched credit");
@@ -3124,6 +3109,8 @@ int libxl_sched_credit2_domain_get(libxl
     struct xen_domctl_sched_credit2 sdom;
     int rc;
 
+    libxl_sched_credit2_init(scinfo);
+
     rc = xc_sched_credit2_domain_get(ctx->xch, domid, &sdom);
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -3181,6 +3168,8 @@ int libxl_sched_sedf_domain_get(libxl_ct
     uint16_t weight;
     int rc;
 
+    libxl_sched_sedf_init(scinfo);
+
     rc = xc_sedf_domain_get(ctx->xch, domid, &period, &slice, &latency,
                             &extratime, &weight);
     if (rc != 0) {
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
@@ -381,10 +381,6 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -523,7 +519,6 @@ void libxl_vminfo_list_free(libxl_vminfo
  */
 
 /* Disks */
-void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
@@ -549,7 +544,6 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
@@ -561,7 +555,6 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -569,7 +562,6 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
@@ -577,7 +569,6 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
@@ -50,11 +50,6 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
-{
-    memset(c_info, '\0', sizeof(*c_info));
-}
-
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -69,35 +64,6 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
-{
-    memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = -1;
-
-    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
-
-}
-
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type)
-{
-    assert(b_info->type == -1);
-    b_info->type = type;
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
-        break;
-    default:
-        abort();
-    }
-}
-
 int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info)
 {
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_json.h	Thu Feb 23 12:31:18 2012 +0000
@@ -22,6 +22,20 @@
 #  include <yajl/yajl_version.h>
 #endif
 
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
+yajl_gen_status libxl_domid_gen_json(yajl_gen hand, libxl_domid *p);
+yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
+yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
+yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                                 libxl_cpuid_policy_list *p);
+yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
+yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
+                                              libxl_key_value_list *p);
+yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand,
+                                              libxl_file_reference *p);
+yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
+
 #include <_libxl_types_json.h>
 
 /* YAJL version check */
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:18 2012 +0000
@@ -765,11 +765,6 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
-void libxl_device_pci_init(libxl_device_pci *pci)
-{
-    memset(pci, '\0', sizeof(*pci));
-}
-
 int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
 {
     return 0;
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
@@ -100,7 +100,7 @@ libxl_timer_mode = Enumeration("timer_mo
     (1, "no_delay_for_missed_ticks"),
     (2, "no_missed_ticks_pending"),
     (3, "one_missed_tick_pending"),
-    ])
+    ], init_val = "LIBXL_TIMER_MODE_DEFAULT")
 
 # Consistent with values defined in domctl.h
 libxl_scheduler = Enumeration("scheduler", [
@@ -174,19 +174,19 @@ libxl_dominfo = Struct("dominfo",[
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
     ("cpupool",     uint32),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
     ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vminfo = Struct("vminfo", [
     ("uuid", libxl_uuid),
     ("domid", libxl_domid),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_version_info = Struct("version_info", [
     ("xen_version_major", integer),
@@ -201,7 +201,7 @@ libxl_version_info = Struct("version_inf
     ("virt_start",        uint64),
     ("pagesize",          integer),
     ("commandline",       string),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
@@ -213,7 +213,9 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ])
+    ], dir=DIR_IN)
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
@@ -290,8 +292,8 @@ libxl_domain_build_info = Struct("domain
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", libxl_defbool),
                                       ])),
-                 ])),
-    ],
+                 ], keyvar_init_val = "-1")),
+    ], dir=DIR_IN
 )
 
 libxl_device_vfb = Struct("device_vfb", [
@@ -353,7 +355,7 @@ libxl_diskinfo = Struct("diskinfo", [
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_nicinfo = Struct("nicinfo", [
     ("backend", string),
@@ -365,7 +367,7 @@ libxl_nicinfo = Struct("nicinfo", [
     ("evtch", integer),
     ("rref_tx", integer),
     ("rref_rx", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
     ("vcpuid", uint32),
@@ -375,7 +377,7 @@ libxl_vcpuinfo = Struct("vcpuinfo", [
     ("running", bool),
     ("vcpu_time", uint64), # total vcpu time ran (ns)
     ("cpumap", libxl_cpumap), # current cpu's affinities
-    ])
+    ], dir=DIR_OUT)
 
 libxl_physinfo = Struct("physinfo", [
     ("threads_per_core", uint32),
@@ -402,7 +404,7 @@ libxl_cputopology = Struct("cputopology"
     ("core", uint32),
     ("socket", uint32),
     ("node", uint32),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -3917,6 +3917,7 @@ static int sched_credit_domain_set(
 {
     int rc;
 
+    
     rc = libxl_sched_credit_domain_set(ctx, domid, scinfo);
     if (rc)
         fprintf(stderr, "libxl_sched_credit_domain_set failed.\n");
@@ -3945,6 +3946,7 @@ static int sched_credit_domain_output(
         scinfo.weight,
         scinfo.cap);
     free(domname);
+    libxl_sched_credit_dispose(&scinfo);
     return 0;
 }
 
@@ -3992,6 +3994,7 @@ static int sched_credit2_domain_output(
         domid,
         scinfo.weight);
     free(domname);
+    libxl_sched_credit2_dispose(&scinfo);
     return 0;
 }
 
@@ -4015,7 +4018,6 @@ static int sched_sedf_domain_set(
     rc = libxl_sched_sedf_domain_set(ctx, domid, scinfo);
     if (rc)
         fprintf(stderr, "libxl_sched_sedf_domain_set failed.\n");
-
     return rc;
 }
 
@@ -4044,6 +4046,7 @@ static int sched_sedf_domain_output(
         scinfo.extratime,
         scinfo.weight);
     free(domname);
+    libxl_sched_sedf_dispose(&scinfo);
     return 0;
 }
 
@@ -4176,6 +4179,7 @@ int main_sched_credit(int argc, char **a
             if (opt_c)
                 scinfo.cap = cap;
             rc = sched_credit_domain_set(domid, &scinfo);
+            libxl_sched_credit_dispose(&scinfo);
             if (rc)
                 return -rc;
         }
@@ -4250,6 +4254,7 @@ int main_sched_credit2(int argc, char **
             if (opt_w)
                 scinfo.weight = weight;
             rc = sched_credit2_domain_set(domid, &scinfo);
+            libxl_sched_credit2_dispose(&scinfo);
             if (rc)
                 return -rc;
         }
@@ -4368,6 +4373,7 @@ int main_sched_sedf(int argc, char **arg
                 scinfo.slice = 0;
             }
             rc = sched_sedf_domain_set(domid, &scinfo);
+            libxl_sched_sedf_dispose(&scinfo);
             if (rc)
                 return -rc;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaN-0004h9-Sf; Thu, 23 Feb 2012 13:19:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaL-0004X7-Oh
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26309 invoked from network); 23 Feb 2012 13:19:35 -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;
	23 Feb 2012 13:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109333"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:34 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:33 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-FN;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: af38d2c2926aaa5fbc8ecb90e6e2d327d5ac1733
Message-ID: <af38d2c2926aaa5fbc8e.1330002123@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 14 of 26 V3] libxl: make libxl_device_console
	internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000277 0
# Node ID af38d2c2926aaa5fbc8ecb90e6e2d327d5ac1733
# Parent  ee62ab4c3c9d511b201a097e42e6f3f643d2ba5f
libxl: make libxl_device_console internal

consoles are not directly exposed to users of the library and there are no API
functions for manipluating them (only the console_exec function). Rather than
commit to a particular API now make the type internal.

When a user does come along it is much easier to add a completely new API
rather than to fix an existing broken one. It's easier to do this in a manner
which users of the library can cope with in a compatible way e.g. adding a new
API is easier to check for with ./configure.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -2023,7 +2023,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
 
 /******************************************************************************/
 int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                              libxl_device_console *console,
+                              libxl__device_console *console,
                               libxl__domain_build_state *state)
 {
     flexarray_t *front;
@@ -2070,7 +2070,7 @@ int libxl__device_console_add(libxl__gc 
     flexarray_append(front, "limit");
     flexarray_append(front, libxl__sprintf(gc, "%d", LIBXL_XENCONSOLE_LIMIT));
     flexarray_append(front, "type");
-    if (console->consback == LIBXL_CONSOLE_BACKEND_XENCONSOLED)
+    if (console->consback == LIBXL__CONSOLE_BACKEND_XENCONSOLED)
         flexarray_append(front, "xenconsoled");
     else
         flexarray_append(front, "ioemu");
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -176,17 +176,16 @@ int libxl__domain_build_info_setdefault(
     return 0;
 }
 
-static int init_console_info(libxl_device_console *console, int dev_num)
+static int init_console_info(libxl__device_console *console, int dev_num)
 {
-    memset(console, 0x00, sizeof(libxl_device_console));
+    memset(console, 0x00, sizeof(libxl__device_console));
     console->devid = dev_num;
-    console->consback = LIBXL_CONSOLE_BACKEND_XENCONSOLED;
+    console->consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
     console->output = strdup("pty");
-    if ( NULL == console->output )
+    if (!console->output)
         return ERROR_NOMEM;
     return 0;
 }
-
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
                         uint32_t domid,
@@ -585,14 +584,14 @@ static int do_domain_create(libxl__gc *g
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
-        libxl_device_console console;
+        libxl__device_console console;
         libxl_device_vkb vkb;
 
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
@@ -610,7 +609,7 @@ static int do_domain_create(libxl__gc *g
     case LIBXL_DOMAIN_TYPE_PV:
     {
         int need_qemu = 0;
-        libxl_device_console console;
+        libxl__device_console console;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -626,10 +625,10 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_disks, &d_config->disks[0]);
 
         if (need_qemu)
-             console.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         if (need_qemu) {
             libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -686,7 +686,7 @@ static int libxl__create_stubdom(libxl__
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
-    libxl_device_console *console;
+    libxl__device_console *console;
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
@@ -818,7 +818,7 @@ retry_transaction:
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
-    console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
+    console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
     if (!console) {
         ret = ERROR_NOMEM;
         goto out_free;
@@ -826,7 +826,7 @@ retry_transaction:
 
     for (i = 0; i < num_console; i++) {
         console[i].devid = i;
-        console[i].consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+        console[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
         /* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
          * STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
          * STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
@@ -1090,7 +1090,7 @@ out:
 }
 
 int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks)
 {
@@ -1102,7 +1102,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
     }
 
     for (i = 0; i < nr_consoles; i++) {
-        if (consoles[i].consback == LIBXL_CONSOLE_BACKEND_IOEMU) {
+        if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
             ret = 1;
             goto out;
         }
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
@@ -661,7 +661,7 @@ _hidden int libxl__device_disk_dev_numbe
                                           int *pdisk, int *ppartition);
 
 _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                                      libxl_device_console *console,
+                                      libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
@@ -904,7 +904,7 @@ _hidden int libxl__create_xenpv_qemu(lib
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks);
   /* Caller must either: pass starting_r==0, or on successful
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -42,11 +42,6 @@ libxl_console_type = Enumeration("consol
     (2, "PV"),
     ])
 
-libxl_console_backend = Enumeration("console_backend", [
-    (1, "XENCONSOLED"),
-    (2, "IOEMU"),
-    ])
-
 libxl_disk_format = Enumeration("disk_format", [
     (0, "UNKNOWN"),
     (1, "QCOW"),
@@ -312,13 +307,6 @@ libxl_device_vkb = Struct("device_vkb", 
     ("devid", integer),
     ])
 
-libxl_device_console = Struct("device_console", [
-    ("backend_domid", libxl_domid),
-    ("devid", integer),
-    ("consback", libxl_console_backend),
-    ("output", string),
-    ])
-
 libxl_device_disk = Struct("device_disk", [
     ("backend_domid", libxl_domid),
     ("pdev_path", string),
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types_internal.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -1,5 +1,7 @@
 namespace("libxl__")
 
+libxl_domid = Builtin("domid", namespace="libxl_", json_fn = "yajl_gen_integer")
+
 libxl__qmp_message_type = Enumeration("qmp_message_type", [
     (1, "QMP"),
     (2, "return"),
@@ -17,3 +19,15 @@ libxl__device_kind = Enumeration("device
     (6, "VKBD"),
     (7, "CONSOLE"),
     ])
+
+libxl__console_backend = Enumeration("console_backend", [
+    (1, "XENCONSOLED"),
+    (2, "IOEMU"),
+    ])
+
+libxl__device_console = Struct("device_console", [
+    ("backend_domid", libxl_domid),
+    ("devid", integer),
+    ("consback", libxl__console_backend),
+    ("output", string),
+    ])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaO-0004i1-CU; Thu, 23 Feb 2012 13:19:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaM-0004XN-3e
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!8
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27021 invoked from network); 23 Feb 2012 13:19:43 -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;
	23 Feb 2012 13:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109355"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:43 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:43 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Bt;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 35c5df3275f9d09e63f07e1d04d4a08232c4154e
Message-ID: <35c5df3275f9d09e63f0.1330002119@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 26 V3] libxl: introduce a descriminating
 default value for memkb fields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID 35c5df3275f9d09e63f07e1d04d4a08232c4154e
# Parent  4126474b72b57433538374ece5da684f594217a1
libxl: introduce a descriminating default value for memkb fields.

Consitently make such fields 64 bit values as used by dominfo.

It is not clear if ->video_memkb and/or shadow_memkb shouldn't be part of
->u.hvm but I have not changed that here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
@@ -197,6 +197,7 @@ static void libxl_string_list_rand_init(
 }
 """)
     for ty in builtins + types:
+        if isinstance(ty, idl.Number): continue
         if ty.typename not in handcoded:
             f.write("static void %s_rand_init(%s);\n" % \
                     (ty.typename,
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -246,6 +246,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
+#define LIBXL_MEMKB_DEFAULT ~0ULL
 
 #include "_libxl_types.h"
 
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -70,19 +70,20 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_memkb = 32 * 1024;
-    b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
-    b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
+    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
+
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
@@ -132,8 +133,17 @@ int libxl__domain_build_info_setdefault(
         libxl_cpumap_set_any(&b_info->cpumap);
     }
 
+    if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->max_memkb = 32 * 1024;
+    if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->target_memkb = b_info->max_memkb;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->video_memkb = 8 * 1024;
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
@@ -152,6 +162,10 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->u.pv.slack_memkb = 0;
         break;
     default:
         LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:16 2012 +0000
@@ -129,11 +129,12 @@ int libxl__build_post(libxl__gc *gc, uin
 
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
-    ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
+    ents[1] = libxl__sprintf(gc, "%"PRId64, info->max_memkb);
     ents[2] = "memory/target";
-    ents[3] = libxl__sprintf(gc, "%d", info->target_memkb - info->video_memkb);
+    ents[3] = libxl__sprintf(gc, "%"PRId64,
+                             info->target_memkb - info->video_memkb);
     ents[4] = "memory/videoram";
-    ents[5] = libxl__sprintf(gc, "%d", info->video_memkb);
+    ents[5] = libxl__sprintf(gc, "%"PRId64, info->video_memkb);
     ents[6] = "domid";
     ents[7] = libxl__sprintf(gc, "%d", domid);
     ents[8] = "store/port";
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
@@ -18,6 +18,12 @@ libxl_file_reference = Builtin("file_ref
 libxl_hwcap = Builtin("hwcap", passby=PASS_BY_REFERENCE)
 
 #
+# Specific integer types
+#
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
+
+#
 # Constants / Enumerations
 #
 
@@ -164,9 +170,9 @@ libxl_dominfo = Struct("dominfo",[
     # Otherwise set to a value guaranteed not to clash with any valid
     # LIBXL_SHUTDOWN_REASON_* constant.
     ("shutdown_reason", libxl_shutdown_reason),
-    ("current_memkb",   uint64),
-    ("shared_memkb", uint64),
-    ("max_memkb",   uint64),
+    ("current_memkb",   MemKB),
+    ("shared_memkb", MemKB),
+    ("max_memkb",   MemKB),
     ("cpu_time",    uint64),
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
@@ -222,10 +228,10 @@ libxl_domain_build_info = Struct("domain
     ("cur_vcpus",       integer),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
-    ("max_memkb",       uint32),
-    ("target_memkb",    uint32),
-    ("video_memkb",     uint32),
-    ("shadow_memkb",    uint32),
+    ("max_memkb",       MemKB),
+    ("target_memkb",    MemKB),
+    ("video_memkb",     MemKB),
+    ("shadow_memkb",    MemKB),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
@@ -279,7 +285,7 @@ libxl_domain_build_info = Struct("domain
                                        ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
-                                      ("slack_memkb", uint32),
+                                      ("slack_memkb", MemKB),
                                       ("bootloader", string),
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:16 2012 +0000
@@ -21,6 +21,7 @@
 #include "libxl_osdeps.h"
 
 #include <stdlib.h>
+#include <inttypes.h>
 
 #include "libxl.h"
 #include "libxl_utils.h"
@@ -68,8 +69,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
+    printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
@@ -88,8 +89,8 @@ void printf_info_sexp(int domid, libxl_d
     case LIBXL_DOMAIN_TYPE_HVM:
         printf("\t\t(hvm\n");
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
         printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
         printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
         printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YaP-0004jD-1e; Thu, 23 Feb 2012 13:19:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaN-0004YF-9X
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330003183!10389391!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13392 invoked from network); 23 Feb 2012 13:19:44 -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;
	23 Feb 2012 13:19:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374667"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:42 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:42 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Ms;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8b82b7435b7d5a42c52221b3827ddde746794f1b
Message-ID: <8b82b7435b7d5a42c522.1330002135@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 26 of 26 V3] libxl: autogenerate libxl_FOO_init
 and libxl_FOO_init_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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000278 0
# Node ID 8b82b7435b7d5a42c52221b3827ddde746794f1b
# Parent  6dedf527d9b77f5ed3ca583683c00afd88c7bb6f
libxl: autogenerate libxl_FOO_init and libxl_FOO_init_FIELD

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/gentypes.py	Thu Feb 23 12:31:18 2012 +0000
@@ -78,6 +78,88 @@ def libxl_C_type_dispose(ty, v, indent =
         s = indent + s
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
+def libxl_init_members(ty, nesting = 0):
+    """Returns a list of members of ty which require a separate init"""
+
+    if isinstance(ty, idl.Aggregate):
+        return [f for f in ty.fields if not f.const and isinstance(f.type,idl.KeyedUnion)]
+    else:
+        return []
+    
+def _libxl_C_type_init(ty, v, indent = "    ", parent = None, subinit=False):
+    s = ""
+    if isinstance(ty, idl.KeyedUnion):
+        if parent is None:
+            raise Exception("KeyedUnion type must have a parent")
+        if subinit:
+            s += "switch (%s) {\n" % (parent + ty.keyvar.name)
+            for f in ty.fields:
+                (nparent,fexpr) = ty.member(v, f, parent is None)
+                s += "case %s:\n" % f.enumname
+                s += _libxl_C_type_init(f.type, fexpr, "    ", nparent)
+                s += "    break;\n"
+            s += "}\n"
+        else:
+            if ty.keyvar.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.init_val)
+            elif ty.keyvar.type.init_val:
+                s += "%s = %s;\n" % (parent + ty.keyvar.name, ty.keyvar.type.init_val)
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.init_fn is None):
+        for f in [f for f in ty.fields if not f.const]:
+            (nparent,fexpr) = ty.member(v, f, parent is None)
+            if f.init_val is not None:
+                s += "%s = %s;\n" % (fexpr, f.init_val)
+            else:
+                s += _libxl_C_type_init(f.type, fexpr, "", nparent)
+    else:
+        if ty.init_val is not None:
+            s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), ty.init_val)
+        elif ty.init_fn is not None:
+            s += "%s(%s);\n" % (ty.init_fn, ty.pass_arg(v, parent is None))
+
+    if s != "":
+        s = indent + s
+    return s.replace("\n", "\n%s" % indent).rstrip(indent)
+
+def libxl_C_type_init(ty):
+    s = ""
+    s += "void %s(%s)\n" % (ty.init_fn, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE))
+    s += "{\n"
+    s += "    memset(p, '\\0', sizeof(*p));\n"
+    s += _libxl_C_type_init(ty, "p")
+    s += "}\n"
+    s += "\n"
+    return s
+
+def libxl_C_type_member_init(ty, field):
+    if not isinstance(field.type, idl.KeyedUnion):
+        raise Exception("Only KeyedUnion is supported for member init")
+
+    ku = field.type
+    
+    s = ""
+    s += "void %s(%s, %s)\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                ty.make_arg("p", passby=idl.PASS_BY_REFERENCE),
+                                ku.keyvar.type.make_arg(ku.keyvar.name))
+    s += "{\n"
+    
+    if ku.keyvar.init_val:
+        init_val = ku.keyvar.init_val
+    elif ku.keyvar.type.init_val:
+        init_val = ku.keyvar.type.init_val
+    else:
+        init_val = None
+        
+    if init_val is not None:
+        (nparent,fexpr) = ty.member(ty.pass_arg("p"), ku.keyvar, isref=True)
+        s += "    assert(%s == %s);\n" % (fexpr, init_val)
+        s += "    %s = %s;\n" % (fexpr, ku.keyvar.name)
+    (nparent,fexpr) = ty.member(ty.pass_arg("p"), field, isref=True)
+    s += _libxl_C_type_init(ku, fexpr, parent=nparent, subinit=True)
+    s += "}\n"
+    s += "\n"
+    return s
+
 def libxl_C_type_gen_json(ty, v, indent = "    ", parent = None):
     s = ""
     if parent is None:
@@ -199,6 +281,15 @@ if __name__ == '__main__':
         f.write(libxl_C_type_define(ty) + ";\n")
         if ty.dispose_fn is not None:
             f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
+        if ty.init_fn is not None:
+            f.write("void %s(%s);\n" % (ty.init_fn, ty.make_arg("p")))
+            for field in libxl_init_members(ty):
+                if not isinstance(field.type, idl.KeyedUnion):
+                    raise Exception("Only KeyedUnion is supported for member init")
+                ku = field.type
+                f.write("void %s(%s, %s);\n" % (ty.init_fn + "_" + ku.keyvar.name,
+                                               ty.make_arg("p"),
+                                               ku.keyvar.type.make_arg(ku.keyvar.name)))
         if ty.json_fn is not None:
             f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
         if isinstance(ty, idl.Enumeration):
@@ -227,7 +318,7 @@ if __name__ == '__main__':
 
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
-    for ty in [ty for ty in types+builtins if ty.json_fn is not None]:
+    for ty in [ty for ty in types if ty.json_fn is not None]:
         f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
@@ -264,6 +355,11 @@ if __name__ == '__main__':
         f.write("    memset(p, LIBXL_DTOR_POISON, sizeof(*p));\n")
         f.write("}\n")
         f.write("\n")
+        
+    for ty in [t for t in types if t.init_fn is not None and t.autogenerate_init_fn]:
+        f.write(libxl_C_type_init(ty))
+        for field in libxl_init_members(ty):
+            f.write(libxl_C_type_member_init(ty, field))
 
     for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("const char *%s_to_string(%s e)\n" % (ty.typename, ty.typename))
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/idl.py
--- a/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.py	Thu Feb 23 12:31:18 2012 +0000
@@ -51,6 +51,10 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
+        self.init_fn = kwargs.setdefault('init_fn', None)
+        self.init_val = kwargs.setdefault('init_val', None)
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', False)
+
         if self.typename is not None and not self.private:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
@@ -144,12 +148,20 @@ class Field(object):
         self.name = name
         self.const = kwargs.setdefault('const', False)
         self.enumname = kwargs.setdefault('enumname', None)
+        self.init_val = kwargs.setdefault('init_val', None)
 
 class Aggregate(Type):
     """A type containing a collection of other types"""
     def __init__(self, kind, typename, fields, **kwargs):
         Type.__init__(self, typename, **kwargs)
 
+        if self.typename is not None:
+            self.init_fn = kwargs.setdefault('init_fn', self.typename + "_init")
+        else:
+            self.init_fn = kwargs.setdefault('init_fn', None)
+
+        self.autogenerate_init_fn = kwargs.setdefault('autogenerate_init_fn', True)
+
         self.kind = kind
 
         self.fields = []
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/idl.txt
--- a/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/idl.txt	Thu Feb 23 12:31:18 2012 +0000
@@ -44,6 +44,22 @@ Type.autogenerate_dispose_fn: (default: 
  Indicates if the above named Type.dispose_fn should be
  autogenerated.
 
+Type.init_val: (default: None)
+
+ C expression for the value to initialise instances of this type to.
+
+ If present takes precendence over init_fn (see below).
+
+Type.init_fn: (default: typename + "_init" if dir in [IN, BOTH] and
+                        type != None)
+
+ The name of the C function which will initialist Type.
+
+Type.autogenerate_init_fn: (default: True if dir in [IN, BOTH])
+
+ Indicates if the above named Type.init_fn should be
+ autogenerated.
+
 Type.json_fn: (default: typename + "_gen_json" or None if type == None)
 
  The name of the C function which will generate a YAJL data structure
@@ -105,10 +121,13 @@ idl.Aggregate
 
  Each field has the following properties:
 
-  Field.type    The type of the member (a idl.Type).
-  Field.name    The name of the member (can be None for anonymous
-                fields).
-  Field.const   Boolean, true if the member is const.
+  Field.type     The type of the member (a idl.Type).
+  Field.name     The name of the member (can be None for anonymous
+                 fields).
+  Field.const    Boolean, true if the member is const.
+  Field.init_val The initialisation value for this field. Takes
+                 precendence over both Field.type.init_val and
+                 Field.type.init_fn.
 
 idl.Struct
 
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -1227,11 +1227,6 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-void libxl_device_disk_init(libxl_device_disk *disk)
-{
-    memset(disk, 0x00, sizeof(libxl_device_disk));
-}
-
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
     int rc;
@@ -1718,10 +1713,6 @@ int libxl_device_disk_local_detach(libxl
 }
 
 /******************************************************************************/
-void libxl_device_nic_init(libxl_device_nic *nic)
-{
-    memset(nic, '\0', sizeof(*nic));
-}
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
 {
@@ -2142,10 +2133,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vkb_init(libxl_device_vkb *vkb)
-{
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
-}
 
 int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
 {
@@ -2254,10 +2241,6 @@ out:
 }
 
 /******************************************************************************/
-void libxl_device_vfb_init(libxl_device_vfb *vfb)
-{
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-}
 
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
@@ -3066,6 +3049,8 @@ int libxl_sched_credit_domain_get(libxl_
     struct xen_domctl_sched_credit sdom;
     int rc;
 
+    libxl_sched_credit_init(scinfo);
+
     rc = xc_sched_credit_domain_get(ctx->xch, domid, &sdom);
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched credit");
@@ -3124,6 +3109,8 @@ int libxl_sched_credit2_domain_get(libxl
     struct xen_domctl_sched_credit2 sdom;
     int rc;
 
+    libxl_sched_credit2_init(scinfo);
+
     rc = xc_sched_credit2_domain_get(ctx->xch, domid, &sdom);
     if (rc != 0) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -3181,6 +3168,8 @@ int libxl_sched_sedf_domain_get(libxl_ct
     uint16_t weight;
     int rc;
 
+    libxl_sched_sedf_init(scinfo);
+
     rc = xc_sedf_domain_get(ctx->xch, domid, &period, &slice, &latency,
                             &extratime, &weight);
     if (rc != 0) {
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:18 2012 +0000
@@ -381,10 +381,6 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 i
 int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info);
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info);
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -523,7 +519,6 @@ void libxl_vminfo_list_free(libxl_vminfo
  */
 
 /* Disks */
-void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
@@ -549,7 +544,6 @@ char * libxl_device_disk_local_attach(li
 int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 
 /* Network Interfaces */
-void libxl_device_nic_init(libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_nic *nic,
@@ -561,7 +555,6 @@ int libxl_device_nic_getinfo(libxl_ctx *
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
 /* Keyboard */
-void libxl_device_vkb_init(libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vkb *vkb,
@@ -569,7 +562,6 @@ int libxl_device_vkb_remove(libxl_ctx *c
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
-void libxl_device_vfb_init(libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_device_vfb *vfb,
@@ -577,7 +569,6 @@ int libxl_device_vfb_remove(libxl_ctx *c
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
-void libxl_device_pci_init(libxl_device_pci *pci);
 int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
 int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_pci *pcidev);
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:18 2012 +0000
@@ -50,11 +50,6 @@ void libxl_domain_config_dispose(libxl_d
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
 
-void libxl_domain_create_info_init(libxl_domain_create_info *c_info)
-{
-    memset(c_info, '\0', sizeof(*c_info));
-}
-
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
                                          libxl_domain_create_info *c_info)
 {
@@ -69,35 +64,6 @@ int libxl__domain_create_info_setdefault
     return 0;
 }
 
-void libxl_domain_build_info_init(libxl_domain_build_info *b_info)
-{
-    memset(b_info, '\0', sizeof(*b_info));
-    b_info->type = -1;
-
-    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
-    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
-
-}
-
-void libxl_domain_build_info_init_type(libxl_domain_build_info *b_info,
-                                       libxl_domain_type type)
-{
-    assert(b_info->type == -1);
-    b_info->type = type;
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.timer_mode = LIBXL_TIMER_MODE_DEFAULT;
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = LIBXL_MEMKB_DEFAULT;
-        break;
-    default:
-        abort();
-    }
-}
-
 int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info)
 {
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_json.h	Thu Feb 23 12:31:18 2012 +0000
@@ -22,6 +22,20 @@
 #  include <yajl/yajl_version.h>
 #endif
 
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand, libxl_defbool *p);
+yajl_gen_status libxl_domid_gen_json(yajl_gen hand, libxl_domid *p);
+yajl_gen_status libxl_uuid_gen_json(yajl_gen hand, libxl_uuid *p);
+yajl_gen_status libxl_mac_gen_json(yajl_gen hand, libxl_mac *p);
+yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, libxl_cpumap *p);
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                                 libxl_cpuid_policy_list *p);
+yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *p);
+yajl_gen_status libxl_key_value_list_gen_json(yajl_gen hand,
+                                              libxl_key_value_list *p);
+yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand,
+                                              libxl_file_reference *p);
+yajl_gen_status libxl_hwcap_gen_json(yajl_gen hand, libxl_hwcap *p);
+
 #include <_libxl_types_json.h>
 
 /* YAJL version check */
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Thu Feb 23 12:31:18 2012 +0000
@@ -765,11 +765,6 @@ static int libxl__device_pci_reset(libxl
     return -1;
 }
 
-void libxl_device_pci_init(libxl_device_pci *pci)
-{
-    memset(pci, '\0', sizeof(*pci));
-}
-
 int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci)
 {
     return 0;
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:18 2012 +0000
@@ -100,7 +100,7 @@ libxl_timer_mode = Enumeration("timer_mo
     (1, "no_delay_for_missed_ticks"),
     (2, "no_missed_ticks_pending"),
     (3, "one_missed_tick_pending"),
-    ])
+    ], init_val = "LIBXL_TIMER_MODE_DEFAULT")
 
 # Consistent with values defined in domctl.h
 libxl_scheduler = Enumeration("scheduler", [
@@ -174,19 +174,19 @@ libxl_dominfo = Struct("dominfo",[
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
     ("cpupool",     uint32),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
     ("poolid",      uint32),
     ("sched",       libxl_scheduler),
     ("n_dom",       uint32),
     ("cpumap",      libxl_cpumap)
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vminfo = Struct("vminfo", [
     ("uuid", libxl_uuid),
     ("domid", libxl_domid),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_version_info = Struct("version_info", [
     ("xen_version_major", integer),
@@ -201,7 +201,7 @@ libxl_version_info = Struct("version_inf
     ("virt_start",        uint64),
     ("pagesize",          integer),
     ("commandline",       string),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
@@ -213,7 +213,9 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ])
+    ], dir=DIR_IN)
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
 
 # Instances of libxl_file_reference contained in this struct which
 # have been mapped (with libxl_file_reference_map) will be unmapped
@@ -290,8 +292,8 @@ libxl_domain_build_info = Struct("domain
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", libxl_defbool),
                                       ])),
-                 ])),
-    ],
+                 ], keyvar_init_val = "-1")),
+    ], dir=DIR_IN
 )
 
 libxl_device_vfb = Struct("device_vfb", [
@@ -353,7 +355,7 @@ libxl_diskinfo = Struct("diskinfo", [
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_nicinfo = Struct("nicinfo", [
     ("backend", string),
@@ -365,7 +367,7 @@ libxl_nicinfo = Struct("nicinfo", [
     ("evtch", integer),
     ("rref_tx", integer),
     ("rref_rx", integer),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
     ("vcpuid", uint32),
@@ -375,7 +377,7 @@ libxl_vcpuinfo = Struct("vcpuinfo", [
     ("running", bool),
     ("vcpu_time", uint64), # total vcpu time ran (ns)
     ("cpumap", libxl_cpumap), # current cpu's affinities
-    ])
+    ], dir=DIR_OUT)
 
 libxl_physinfo = Struct("physinfo", [
     ("threads_per_core", uint32),
@@ -402,7 +404,7 @@ libxl_cputopology = Struct("cputopology"
     ("core", uint32),
     ("socket", uint32),
     ("node", uint32),
-    ])
+    ], dir=DIR_OUT)
 
 libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
diff -r 6dedf527d9b7 -r 8b82b7435b7d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
@@ -3917,6 +3917,7 @@ static int sched_credit_domain_set(
 {
     int rc;
 
+    
     rc = libxl_sched_credit_domain_set(ctx, domid, scinfo);
     if (rc)
         fprintf(stderr, "libxl_sched_credit_domain_set failed.\n");
@@ -3945,6 +3946,7 @@ static int sched_credit_domain_output(
         scinfo.weight,
         scinfo.cap);
     free(domname);
+    libxl_sched_credit_dispose(&scinfo);
     return 0;
 }
 
@@ -3992,6 +3994,7 @@ static int sched_credit2_domain_output(
         domid,
         scinfo.weight);
     free(domname);
+    libxl_sched_credit2_dispose(&scinfo);
     return 0;
 }
 
@@ -4015,7 +4018,6 @@ static int sched_sedf_domain_set(
     rc = libxl_sched_sedf_domain_set(ctx, domid, scinfo);
     if (rc)
         fprintf(stderr, "libxl_sched_sedf_domain_set failed.\n");
-
     return rc;
 }
 
@@ -4044,6 +4046,7 @@ static int sched_sedf_domain_output(
         scinfo.extratime,
         scinfo.weight);
     free(domname);
+    libxl_sched_sedf_dispose(&scinfo);
     return 0;
 }
 
@@ -4176,6 +4179,7 @@ int main_sched_credit(int argc, char **a
             if (opt_c)
                 scinfo.cap = cap;
             rc = sched_credit_domain_set(domid, &scinfo);
+            libxl_sched_credit_dispose(&scinfo);
             if (rc)
                 return -rc;
         }
@@ -4250,6 +4254,7 @@ int main_sched_credit2(int argc, char **
             if (opt_w)
                 scinfo.weight = weight;
             rc = sched_credit2_domain_set(domid, &scinfo);
+            libxl_sched_credit2_dispose(&scinfo);
             if (rc)
                 return -rc;
         }
@@ -4368,6 +4373,7 @@ int main_sched_sedf(int argc, char **arg
                 scinfo.slice = 0;
             }
             rc = sched_sedf_domain_set(domid, &scinfo);
+            libxl_sched_sedf_dispose(&scinfo);
             if (rc)
                 return -rc;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaO-0004i1-CU; Thu, 23 Feb 2012 13:19:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaM-0004XN-3e
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!8
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27021 invoked from network); 23 Feb 2012 13:19:43 -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;
	23 Feb 2012 13:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109355"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:43 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:43 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-Bt;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 35c5df3275f9d09e63f07e1d04d4a08232c4154e
Message-ID: <35c5df3275f9d09e63f0.1330002119@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:01:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 26 V3] libxl: introduce a descriminating
 default value for memkb fields
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID 35c5df3275f9d09e63f07e1d04d4a08232c4154e
# Parent  4126474b72b57433538374ece5da684f594217a1
libxl: introduce a descriminating default value for memkb fields.

Consitently make such fields 64 bit values as used by dominfo.

It is not clear if ->video_memkb and/or shadow_memkb shouldn't be part of
->u.hvm but I have not changed that here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/gentest.py	Thu Feb 23 12:31:16 2012 +0000
@@ -197,6 +197,7 @@ static void libxl_string_list_rand_init(
 }
 """)
     for ty in builtins + types:
+        if isinstance(ty, idl.Number): continue
         if ty.typename not in handcoded:
             f.write("static void %s_rand_init(%s);\n" % \
                     (ty.typename,
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -246,6 +246,7 @@ typedef LIBXL_TAILQ_ENTRY(struct libxl_e
 typedef struct libxl__ctx libxl_ctx;
 
 #define LIBXL_TIMER_MODE_DEFAULT -1
+#define LIBXL_MEMKB_DEFAULT ~0ULL
 
 #include "_libxl_types.h"
 
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -70,19 +70,20 @@ void libxl_domain_build_info_init(libxl_
                                   const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_memkb = 32 * 1024;
-    b_info->target_memkb = b_info->max_memkb;
     b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
-    b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
+    b_info->max_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->target_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->shadow_memkb = LIBXL_MEMKB_DEFAULT;
+    b_info->video_memkb =  LIBXL_MEMKB_DEFAULT;
+
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
@@ -132,8 +133,17 @@ int libxl__domain_build_info_setdefault(
         libxl_cpumap_set_any(&b_info->cpumap);
     }
 
+    if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->max_memkb = 32 * 1024;
+    if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
+        b_info->target_memkb = b_info->max_memkb;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->video_memkb = 8 * 1024;
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
@@ -152,6 +162,10 @@ int libxl__domain_build_info_setdefault(
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
+        if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->shadow_memkb = 0;
+        if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
+            b_info->u.pv.slack_memkb = 0;
         break;
     default:
         LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Feb 23 12:31:16 2012 +0000
@@ -129,11 +129,12 @@ int libxl__build_post(libxl__gc *gc, uin
 
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
-    ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
+    ents[1] = libxl__sprintf(gc, "%"PRId64, info->max_memkb);
     ents[2] = "memory/target";
-    ents[3] = libxl__sprintf(gc, "%d", info->target_memkb - info->video_memkb);
+    ents[3] = libxl__sprintf(gc, "%"PRId64,
+                             info->target_memkb - info->video_memkb);
     ents[4] = "memory/videoram";
-    ents[5] = libxl__sprintf(gc, "%d", info->video_memkb);
+    ents[5] = libxl__sprintf(gc, "%"PRId64, info->video_memkb);
     ents[6] = "domid";
     ents[7] = libxl__sprintf(gc, "%d", domid);
     ents[8] = "store/port";
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:16 2012 +0000
@@ -18,6 +18,12 @@ libxl_file_reference = Builtin("file_ref
 libxl_hwcap = Builtin("hwcap", passby=PASS_BY_REFERENCE)
 
 #
+# Specific integer types
+#
+
+MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
+
+#
 # Constants / Enumerations
 #
 
@@ -164,9 +170,9 @@ libxl_dominfo = Struct("dominfo",[
     # Otherwise set to a value guaranteed not to clash with any valid
     # LIBXL_SHUTDOWN_REASON_* constant.
     ("shutdown_reason", libxl_shutdown_reason),
-    ("current_memkb",   uint64),
-    ("shared_memkb", uint64),
-    ("max_memkb",   uint64),
+    ("current_memkb",   MemKB),
+    ("shared_memkb", MemKB),
+    ("max_memkb",   MemKB),
     ("cpu_time",    uint64),
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
@@ -222,10 +228,10 @@ libxl_domain_build_info = Struct("domain
     ("cur_vcpus",       integer),
     ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
-    ("max_memkb",       uint32),
-    ("target_memkb",    uint32),
-    ("video_memkb",     uint32),
-    ("shadow_memkb",    uint32),
+    ("max_memkb",       MemKB),
+    ("target_memkb",    MemKB),
+    ("video_memkb",     MemKB),
+    ("shadow_memkb",    MemKB),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
@@ -279,7 +285,7 @@ libxl_domain_build_info = Struct("domain
                                        ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
-                                      ("slack_memkb", uint32),
+                                      ("slack_memkb", MemKB),
                                       ("bootloader", string),
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
diff -r 4126474b72b5 -r 35c5df3275f9 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_sxp.c	Thu Feb 23 12:31:16 2012 +0000
@@ -21,6 +21,7 @@
 #include "libxl_osdeps.h"
 
 #include <stdlib.h>
+#include <inttypes.h>
 
 #include "libxl.h"
 #include "libxl_utils.h"
@@ -68,8 +69,8 @@ void printf_info_sexp(int domid, libxl_d
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(max_memkb %"PRId64")\n", b_info->max_memkb);
+    printf("\t(target_memkb %"PRId64")\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
@@ -88,8 +89,8 @@ void printf_info_sexp(int domid, libxl_d
     case LIBXL_DOMAIN_TYPE_HVM:
         printf("\t\t(hvm\n");
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(video_memkb %"PRId64")\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %"PRId64")\n", b_info->shadow_memkb);
         printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
         printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
         printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaN-0004h9-Sf; Thu, 23 Feb 2012 13:19:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaL-0004X7-Oh
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330003172!1878344!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26309 invoked from network); 23 Feb 2012 13:19:35 -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;
	23 Feb 2012 13:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183109333"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:34 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:33 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-FN;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: af38d2c2926aaa5fbc8ecb90e6e2d327d5ac1733
Message-ID: <af38d2c2926aaa5fbc8e.1330002123@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 14 of 26 V3] libxl: make libxl_device_console
	internal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330000277 0
# Node ID af38d2c2926aaa5fbc8ecb90e6e2d327d5ac1733
# Parent  ee62ab4c3c9d511b201a097e42e6f3f643d2ba5f
libxl: make libxl_device_console internal

consoles are not directly exposed to users of the library and there are no API
functions for manipluating them (only the console_exec function). Rather than
commit to a particular API now make the type internal.

When a user does come along it is much easier to add a completely new API
rather than to fix an existing broken one. It's easier to do this in a manner
which users of the library can cope with in a compatible way e.g. adding a new
API is easier to check for with ./configure.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:17 2012 +0000
@@ -2023,7 +2023,7 @@ int libxl_device_nic_getinfo(libxl_ctx *
 
 /******************************************************************************/
 int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                              libxl_device_console *console,
+                              libxl__device_console *console,
                               libxl__domain_build_state *state)
 {
     flexarray_t *front;
@@ -2070,7 +2070,7 @@ int libxl__device_console_add(libxl__gc 
     flexarray_append(front, "limit");
     flexarray_append(front, libxl__sprintf(gc, "%d", LIBXL_XENCONSOLE_LIMIT));
     flexarray_append(front, "type");
-    if (console->consback == LIBXL_CONSOLE_BACKEND_XENCONSOLED)
+    if (console->consback == LIBXL__CONSOLE_BACKEND_XENCONSOLED)
         flexarray_append(front, "xenconsoled");
     else
         flexarray_append(front, "ioemu");
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:17 2012 +0000
@@ -176,17 +176,16 @@ int libxl__domain_build_info_setdefault(
     return 0;
 }
 
-static int init_console_info(libxl_device_console *console, int dev_num)
+static int init_console_info(libxl__device_console *console, int dev_num)
 {
-    memset(console, 0x00, sizeof(libxl_device_console));
+    memset(console, 0x00, sizeof(libxl__device_console));
     console->devid = dev_num;
-    console->consback = LIBXL_CONSOLE_BACKEND_XENCONSOLED;
+    console->consback = LIBXL__CONSOLE_BACKEND_XENCONSOLED;
     console->output = strdup("pty");
-    if ( NULL == console->output )
+    if (!console->output)
         return ERROR_NOMEM;
     return 0;
 }
-
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
                         uint32_t domid,
@@ -585,14 +584,14 @@ static int do_domain_create(libxl__gc *g
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
-        libxl_device_console console;
+        libxl__device_console console;
         libxl_device_vkb vkb;
 
         ret = init_console_info(&console, 0);
         if ( ret )
             goto error_out;
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         libxl_device_vkb_init(&vkb);
         libxl_device_vkb_add(ctx, domid, &vkb);
@@ -610,7 +609,7 @@ static int do_domain_create(libxl__gc *g
     case LIBXL_DOMAIN_TYPE_PV:
     {
         int need_qemu = 0;
-        libxl_device_console console;
+        libxl__device_console console;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -626,10 +625,10 @@ static int do_domain_create(libxl__gc *g
                 d_config->num_disks, &d_config->disks[0]);
 
         if (need_qemu)
-             console.consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+             console.consback = LIBXL__CONSOLE_BACKEND_IOEMU;
 
         libxl__device_console_add(gc, domid, &console, &state);
-        libxl_device_console_dispose(&console);
+        libxl__device_console_dispose(&console);
 
         if (need_qemu) {
             libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Feb 23 12:31:17 2012 +0000
@@ -686,7 +686,7 @@ static int libxl__create_stubdom(libxl__
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
-    libxl_device_console *console;
+    libxl__device_console *console;
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
@@ -818,7 +818,7 @@ retry_transaction:
     if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
-    console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
+    console = libxl__calloc(gc, num_console, sizeof(libxl__device_console));
     if (!console) {
         ret = ERROR_NOMEM;
         goto out_free;
@@ -826,7 +826,7 @@ retry_transaction:
 
     for (i = 0; i < num_console; i++) {
         console[i].devid = i;
-        console[i].consback = LIBXL_CONSOLE_BACKEND_IOEMU;
+        console[i].consback = LIBXL__CONSOLE_BACKEND_IOEMU;
         /* STUBDOM_CONSOLE_LOGGING (console 0) is for minios logging
          * STUBDOM_CONSOLE_SAVE (console 1) is for writing the save file
          * STUBDOM_CONSOLE_RESTORE (console 2) is for reading the save file
@@ -1090,7 +1090,7 @@ out:
 }
 
 int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks)
 {
@@ -1102,7 +1102,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc
     }
 
     for (i = 0; i < nr_consoles; i++) {
-        if (consoles[i].consback == LIBXL_CONSOLE_BACKEND_IOEMU) {
+        if (consoles[i].consback == LIBXL__CONSOLE_BACKEND_IOEMU) {
             ret = 1;
             goto out;
         }
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:17 2012 +0000
@@ -661,7 +661,7 @@ _hidden int libxl__device_disk_dev_numbe
                                           int *pdisk, int *ppartition);
 
 _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
-                                      libxl_device_console *console,
+                                      libxl__device_console *console,
                                       libxl__domain_build_state *state);
 
 _hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
@@ -904,7 +904,7 @@ _hidden int libxl__create_xenpv_qemu(lib
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
-        int nr_consoles, libxl_device_console *consoles,
+        int nr_consoles, libxl__device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
         int nr_disks, libxl_device_disk *disks);
   /* Caller must either: pass starting_r==0, or on successful
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -42,11 +42,6 @@ libxl_console_type = Enumeration("consol
     (2, "PV"),
     ])
 
-libxl_console_backend = Enumeration("console_backend", [
-    (1, "XENCONSOLED"),
-    (2, "IOEMU"),
-    ])
-
 libxl_disk_format = Enumeration("disk_format", [
     (0, "UNKNOWN"),
     (1, "QCOW"),
@@ -312,13 +307,6 @@ libxl_device_vkb = Struct("device_vkb", 
     ("devid", integer),
     ])
 
-libxl_device_console = Struct("device_console", [
-    ("backend_domid", libxl_domid),
-    ("devid", integer),
-    ("consback", libxl_console_backend),
-    ("output", string),
-    ])
-
 libxl_device_disk = Struct("device_disk", [
     ("backend_domid", libxl_domid),
     ("pdev_path", string),
diff -r ee62ab4c3c9d -r af38d2c2926a tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Thu Feb 23 12:31:17 2012 +0000
+++ b/tools/libxl/libxl_types_internal.idl	Thu Feb 23 12:31:17 2012 +0000
@@ -1,5 +1,7 @@
 namespace("libxl__")
 
+libxl_domid = Builtin("domid", namespace="libxl_", json_fn = "yajl_gen_integer")
+
 libxl__qmp_message_type = Enumeration("qmp_message_type", [
     (1, "QMP"),
     (2, "return"),
@@ -17,3 +19,15 @@ libxl__device_kind = Enumeration("device
     (6, "VKBD"),
     (7, "CONSOLE"),
     ])
+
+libxl__console_backend = Enumeration("console_backend", [
+    (1, "XENCONSOLED"),
+    (2, "IOEMU"),
+    ])
+
+libxl__device_console = Struct("device_console", [
+    ("backend_domid", libxl_domid),
+    ("devid", integer),
+    ("consback", libxl__console_backend),
+    ("output", string),
+    ])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaP-0004jk-Fk; Thu, 23 Feb 2012 13:19:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaN-0004Yy-Th
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330003183!10389391!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13465 invoked from network); 23 Feb 2012 13:19:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374669"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:44 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:43 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-CU;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 17abebd7ba97185f6dce327b6c29b3e380d55d20
Message-ID: <17abebd7ba97185f6dce.1330002120@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 11 of 26 V3] libxl: disk: use _init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID 17abebd7ba97185f6dce327b6c29b3e380d55d20
# Parent  35c5df3275f9d09e63f07e1d04d4a08232c4154e
libxl: disk: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -1186,10 +1186,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
+void libxl_device_disk_init(libxl_device_disk *disk)
 {
     memset(disk, 0x00, sizeof(libxl_device_disk));
-    return 0;
+}
+
+int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
+{
+    int rc;
+
+    rc = libxl__device_disk_set_backend(gc, disk);
+    if (rc) return rc;
+
+    return rc;
 }
 
 static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
@@ -1241,10 +1250,7 @@ int libxl_device_disk_add(libxl_ctx *ctx
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
-    if (rc) goto out;
-
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1396,7 +1402,7 @@ static void libxl__device_disk_from_xs_b
     unsigned int len;
     char *tmp;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     tmp = xs_read(ctx->xsh, XBT_NULL,
                   libxl__sprintf(gc, "%s/params", be_path), &len);
@@ -1440,7 +1446,7 @@ int libxl_devid_to_device_disk(libxl_ctx
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
@@ -1604,7 +1610,7 @@ char * libxl_device_disk_local_attach(li
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -498,7 +498,7 @@ void libxl_vminfo_list_free(libxl_vminfo
  */
 
 /* Disks */
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
+void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -535,7 +535,7 @@ static int do_domain_create(libxl__gc *g
     if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
+        ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
         if (ret) goto error_out;
     }
 
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -191,6 +191,8 @@ _hidden int libxl__domain_create_info_se
                                         libxl_domain_create_info *c_info);
 _hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info);
+_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
+                                          libxl_device_disk *disk);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -383,7 +383,7 @@ static void parse_disk_config_multistrin
 {
     int e;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     if (!*config) {
         *config = xlu_cfg_init(stderr, "command line");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:19:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YaP-0004jk-Fk; Thu, 23 Feb 2012 13:19:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0YaN-0004Yy-Th
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:19:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330003183!10389391!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13465 invoked from network); 23 Feb 2012 13:19:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 13:19:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22374669"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 08:19:44 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 08:19:43 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S0YIy-00079D-CU;
	Thu, 23 Feb 2012 13:01:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: 17abebd7ba97185f6dce327b6c29b3e380d55d20
Message-ID: <17abebd7ba97185f6dce.1330002120@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1330002109@cosworth.uk.xensource.com>
References: <patchbomb.1330002109@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 23 Feb 2012 13:02:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 11 of 26 V3] libxl: disk: use _init/_setdefault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330000276 0
# Node ID 17abebd7ba97185f6dce327b6c29b3e380d55d20
# Parent  35c5df3275f9d09e63f07e1d04d4a08232c4154e
libxl: disk: use _init/_setdefault

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -1186,10 +1186,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
 
 /******************************************************************************/
 
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk)
+void libxl_device_disk_init(libxl_device_disk *disk)
 {
     memset(disk, 0x00, sizeof(libxl_device_disk));
-    return 0;
+}
+
+int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
+{
+    int rc;
+
+    rc = libxl__device_disk_set_backend(gc, disk);
+    if (rc) return rc;
+
+    return rc;
 }
 
 static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
@@ -1241,10 +1250,7 @@ int libxl_device_disk_add(libxl_ctx *ctx
     libxl__device device;
     int major, minor, rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
-    if (rc) goto out;
-
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     front = flexarray_make(16, 1);
@@ -1396,7 +1402,7 @@ static void libxl__device_disk_from_xs_b
     unsigned int len;
     char *tmp;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     tmp = xs_read(ctx->xsh, XBT_NULL,
                   libxl__sprintf(gc, "%s/params", be_path), &len);
@@ -1440,7 +1446,7 @@ int libxl_devid_to_device_disk(libxl_ctx
     char *dompath, *path;
     int rc = ERROR_FAIL;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     dompath = libxl__xs_get_dompath(gc, domid);
     if (!dompath) {
@@ -1604,7 +1610,7 @@ char * libxl_device_disk_local_attach(li
     char *ret = NULL;
     int rc;
 
-    rc = libxl__device_disk_set_backend(gc, disk);
+    rc = libxl__device_disk_setdefault(gc, disk);
     if (rc) goto out;
 
     switch (disk->backend) {
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Feb 23 12:31:16 2012 +0000
@@ -498,7 +498,7 @@ void libxl_vminfo_list_free(libxl_vminfo
  */
 
 /* Disks */
-int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
+void libxl_device_disk_init(libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
                              libxl_device_disk *disk,
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Feb 23 12:31:16 2012 +0000
@@ -535,7 +535,7 @@ static int do_domain_create(libxl__gc *g
     if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
-        ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
+        ret = libxl__device_disk_setdefault(gc, &d_config->disks[i]);
         if (ret) goto error_out;
     }
 
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Feb 23 12:31:16 2012 +0000
@@ -191,6 +191,8 @@ _hidden int libxl__domain_create_info_se
                                         libxl_domain_create_info *c_info);
 _hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
                                         libxl_domain_build_info *b_info);
+_hidden int libxl__device_disk_setdefault(libxl__gc *gc,
+                                          libxl_device_disk *disk);
 
 struct libxl__evgen_domain_death {
     uint32_t domid;
diff -r 35c5df3275f9 -r 17abebd7ba97 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:16 2012 +0000
@@ -383,7 +383,7 @@ static void parse_disk_config_multistrin
 {
     int e;
 
-    libxl_device_disk_init(ctx, disk);
+    libxl_device_disk_init(disk);
 
     if (!*config) {
         *config = xlu_cfg_init(stderr, "command line");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Yf9-0006yY-4Y; Thu, 23 Feb 2012 13:24:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1S0Yf7-0006xA-4l
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:24:45 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330003348!60951027!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29791 invoked from network); 23 Feb 2012 13:22:28 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 13:22:28 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 59ED96EA24F;
	Thu, 23 Feb 2012 14:24:37 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 44EB95B86C1;
	Thu, 23 Feb 2012 14:24:37 +0100 (CET)
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 PzRT36QDjf8U; Thu, 23 Feb 2012 14:24:36 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 366B16EA24F;
	Thu, 23 Feb 2012 14:24:28 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: "Ted Ts'o" <tytso@mit.edu>,
 Eric Sandeen <sandeen@redhat.com>
Date: Thu, 23 Feb 2012 14:23:15 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <4D2F7B52.1040209@redhat.com> <20110207023336.GI10402@thunk.org>
	<20110207155936.GA3457@thunk.org>
In-Reply-To: <20110207155936.GA3457@thunk.org>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202231424.23645.hahn@univention.de>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] backport "ext4: serialize unaligned asynchronous
	DIO" to 2.6.32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8096001725940985653=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8096001725940985653==
Content-Type: multipart/signed;
  boundary="nextPart1849790.JziXrtG3Yg";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1849790.JziXrtG3Yg
Content-Type: multipart/mixed;
  boundary="Boundary-01=_D3jRPNguxyYS6GX"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_D3jRPNguxyYS6GX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ted, hello Eric,

On Monday February 7th 2011 16:59:36 Ted Ts'o wrote:
> commit 7520bb0f2980ef79d17dcbec2783760b37490ffc
> Author: Eric Sandeen <sandeen@redhat.com>
> Date:   Mon Feb 7 10:57:28 2011 -0500
>
>     ext4: serialize unaligned asynchronous DIO
>
>     ext4 has a data corruption case when doing non-block-aligned
>     asynchronous direct IO into a sparse file, as demonstrated
>     by xfstest 240.

I hope you remember that bug, because I encountered this data corruption bu=
g=20
on Debians 2.6.32(.51) kernel as well.

On the other hand RedHat seems to have back-ported that fix to RHEL5 (2.6.1=
8) =20
and probably RHEL6 (2.6.32) as well, but I don't have a subscription, so I=
=20
can't verify that:
<http://rpmfind.net/linux/RPM/centos/updates/5.7/x86_64/RPMS/kernel-devel-2=
=2E6.18-274.12.1.el5.x86_64.html>
<https://bugzilla.redhat.com/show_bug.cgi?id=3D689830>

The Xen-people also encountered it and asked for someone to backport it:
<http://osdir.com/ml/xen-development/2011-07/msg00474.html>

I tried to backport it from 2.6.38~rc5 to 2.6.32.51 and thus far it seems t=
o=20
fix the bug. But several other things were re-named and re-organized betwee=
n=20
those versions, so it was not slreight forward.

Since I'm no ext4 expert, I'd like to ask you to have a look at this backpo=
rt.=20
Is it sound or are there some tests I can throw at it to get it tested more=
=20
thoroughly?
Does is classify for <mailto:stable@vger.kernel.org>?

Thanks in advance
Philipp Hahn
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--Boundary-01=_D3jRPNguxyYS6GX
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="26192_ext4-serialize-unaligned-asynchronous-DIO.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="26192_ext4-serialize-unaligned-asynchronous-DIO.patch"

commit e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Sat Feb 12 08:17:34 2011 -0500

    ext4: serialize unaligned asynchronous DIO
   =20
    ext4 has a data corruption case when doing non-block-aligned
    asynchronous direct IO into a sparse file, as demonstrated
    by xfstest 240.
   =20
    The root cause is that while ext4 preallocates space in the
    hole, mappings of that space still look "new" and
    dio_zero_block() will zero out the unwritten portions.  When
    more than one AIO thread is going, they both find this "new"
    block and race to zero out their portion; this is uncoordinated
    and causes data corruption.
   =20
    Dave Chinner fixed this for xfs by simply serializing all
    unaligned asynchronous direct IO.  I've done the same here.
    The difference is that we only wait on conversions, not all IO.
    This is a very big hammer, and I'm not very pleased with
    stuffing this into ext4_file_write().  But since ext4 is
    DIO_LOCKING, we need to serialize it at this high level.
   =20
    I tried to move this into ext4_ext_direct_IO, but by then
    we have the i_mutex already, and we will wait on the
    work queue to do conversions - which must also take the
    i_mutex.  So that won't work.
   =20
    This was originally exposed by qemu-kvm installing to
    a raw disk image with a normal sector-63 alignment.  I've
    tested a backport of this patch with qemu, and it does
    avoid the corruption.  It is also quite a lot slower
    (14 min for package installs, vs. 8 min for well-aligned)
    but I'll take slow correctness over fast corruption any day.
   =20
    Mingming suggested that we can track outstanding
    conversions, and wait on those so that non-sparse
    files won't be affected, and I've implemented that here;
    unaligned AIO to nonsparse files won't take a perf hit.
   =20
    [tytso@mit.edu: Keep the mutex as a hashed array instead
     of bloating the ext4 inode]
   =20
    [tytso@mit.edu: Fix up namespace issues so that global
     variables are protected with an "ext4_" prefix.]
   =20
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 67c46ed..10edb67 100644
=2D-- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -781,6 +781,8 @@ struct ext4_inode_info {
 	/* on-disk additional length */
 	__u16 i_extra_isize;
=20
+	atomic_t i_aiodio_unwritten; /* Nr. of inflight conversions pending */
+
 	spinlock_t i_block_reservation_lock;
 #ifdef CONFIG_QUOTA
 	/* quota space reservation, managed internally by quota code */
@@ -1889,6 +1891,15 @@ static inline void set_bitmap_uptodate(struct buffer=
_head *bh)
=20
 #define in_range(b, first, len)	((b) >=3D (first) && (b) <=3D (first) + (l=
en) - 1)
=20
+/* For ioend & aio unwritten conversion wait queues */
+#define EXT4_WQ_HASH_SZ		37
+#define ext4_ioend_wq(v)   (&ext4__ioend_wq[((unsigned long)(v)) %\
+					    EXT4_WQ_HASH_SZ])
+#define ext4_aio_mutex(v)  (&ext4__aio_mutex[((unsigned long)(v)) %\
+					     EXT4_WQ_HASH_SZ])
+extern wait_queue_head_t ext4__ioend_wq[EXT4_WQ_HASH_SZ];
+extern struct mutex ext4__aio_mutex[EXT4_WQ_HASH_SZ];
+
 #endif	/* __KERNEL__ */
=20
 #endif	/* _EXT4_H */
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ecbe20d..f4830e6 100644
=2D-- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3118,9 +3118,10 @@ ext4_ext_handle_uninitialized_extents(handle_t *hand=
le, struct inode *inode,
 		 * that this IO needs to convertion to written when IO is
 		 * completed
 		 */
=2D		if (io)
+		if (io && !(io->flag & DIO_AIO_UNWRITTEN)) {
 			io->flag =3D DIO_AIO_UNWRITTEN;
=2D		else
+			atomic_inc(&EXT4_I(inode)->i_aiodio_unwritten);
+		} else
 			ext4_set_inode_state(inode, EXT4_STATE_DIO_UNWRITTEN);
 		goto out;
 	}
@@ -3404,9 +3405,10 @@ int ext4_ext_get_blocks(handle_t *handle, struct ino=
de *inode,
 		 * that we need to perform convertion when IO is done.
 		 */
 		if (flags =3D=3D EXT4_GET_BLOCKS_DIO_CREATE_EXT) {
=2D			if (io)
+			if (io && !(io->flag & DIO_AIO_UNWRITTEN)) {
 				io->flag =3D DIO_AIO_UNWRITTEN;
=2D			else
+				atomic_inc(&EXT4_I(inode)->i_aiodio_unwritten);
+			} else
 				ext4_set_inode_state(inode,
 						     EXT4_STATE_DIO_UNWRITTEN);
 		}
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 2a60541..a18b45c 100644
=2D-- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -54,11 +54,47 @@ static int ext4_release_file(struct inode *inode, struc=
t file *filp)
 	return 0;
 }
=20
+static void ext4_aiodio_wait(struct inode *inode)
+{
+	wait_queue_head_t *wq =3D ext4_ioend_wq(inode);
+
+	wait_event(*wq, (atomic_read(&EXT4_I(inode)->i_aiodio_unwritten) =3D=3D 0=
));
+}
+
+/*
+ * This tests whether the IO in question is block-aligned or not.
+ * Ext4 utilizes unwritten extents when hole-filling during direct IO, and=
 they
+ * are converted to written only after the IO is complete.  Until they are
+ * mapped, these blocks appear as holes, so dio_zero_block() will assume t=
hat
+ * it needs to zero out portions of the start and/or end block.  If 2 AIO
+ * threads are at work on the same unwritten block, they must be synchroni=
zed
+ * or one thread will zero the other's data, causing corruption.
+ */
+static int
+ext4_unaligned_aio(struct inode *inode, const struct iovec *iov,
+		   unsigned long nr_segs, loff_t pos)
+{
+	struct super_block *sb =3D inode->i_sb;
+	int blockmask =3D sb->s_blocksize - 1;
+	size_t count =3D iov_length(iov, nr_segs);
+	loff_t final_size =3D pos + count;
+
+	if (pos >=3D inode->i_size)
+		return 0;
+
+	if ((pos & blockmask) || (final_size & blockmask))
+		return 1;
+
+	return 0;
+}
+
 static ssize_t
 ext4_file_write(struct kiocb *iocb, const struct iovec *iov,
 		unsigned long nr_segs, loff_t pos)
 {
 	struct inode *inode =3D iocb->ki_filp->f_path.dentry->d_inode;
+	int unaligned_aio =3D 0;
+	int ret;
=20
 	/*
 	 * If we have encountered a bitmap-format file, the size limit
@@ -76,9 +112,31 @@ ext4_file_write(struct kiocb *iocb, const struct iovec =
*iov,
 			nr_segs =3D iov_shorten((struct iovec *)iov, nr_segs,
 					      sbi->s_bitmap_maxbytes - pos);
 		}
+	} else if (unlikely((iocb->ki_filp->f_flags & O_DIRECT) &&
+		   !is_sync_kiocb(iocb))) {
+		unaligned_aio =3D ext4_unaligned_aio(inode, iov, nr_segs, pos);
 	}
=20
=2D	return generic_file_aio_write(iocb, iov, nr_segs, pos);
+	/* Unaligned direct AIO must be serialized; see comment above */
+	if (unaligned_aio) {
+		static unsigned long unaligned_warn_time;
+
+		/* Warn about this once per day */
+		if (printk_timed_ratelimit(&unaligned_warn_time, 60*60*24*HZ))
+			ext4_msg(inode->i_sb, KERN_WARNING,
+				 "Unaligned AIO/DIO on inode %ld by %s; "
+				 "performance will be poor.",
+				 inode->i_ino, current->comm);
+		mutex_lock(ext4_aio_mutex(inode));
+		ext4_aiodio_wait(inode);
+	}
+
+	ret =3D generic_file_aio_write(iocb, iov, nr_segs, pos);
+
+	if (unaligned_aio)
+		mutex_unlock(ext4_aio_mutex(inode));
+
+	return ret;
 }
=20
 static const struct vm_operations_struct ext4_file_vm_ops =3D {
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index f27e045..2cb8748 100644
=2D-- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -713,6 +713,7 @@ static struct inode *ext4_alloc_inode(struct super_bloc=
k *sb)
 	ei->cur_aio_dio =3D NULL;
 	ei->i_sync_tid =3D 0;
 	ei->i_datasync_tid =3D 0;
+	atomic_set(&ei->i_aiodio_unwritten, 0);
=20
 	return &ei->vfs_inode;
 }
@@ -4002,11 +4003,21 @@ static struct file_system_type ext4_fs_type =3D {
 	.fs_flags	=3D FS_REQUIRES_DEV,
 };
=20
+/* Shared across all ext4 file systems */
+wait_queue_head_t ext4__ioend_wq[EXT4_WQ_HASH_SZ];
+struct mutex ext4__aio_mutex[EXT4_WQ_HASH_SZ];
+
 static int __init init_ext4_fs(void)
 {
=2D	int err;
+	int i, err;
=20
 	ext4_check_flag_values();
+
+	for (i =3D 0; i < EXT4_WQ_HASH_SZ; i++) {
+		mutex_init(&ext4__aio_mutex[i]);
+		init_waitqueue_head(&ext4__ioend_wq[i]);
+	}
+
 	err =3D init_ext4_system_zone();
 	if (err)
 		return err;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
=2D-- a/fs/ext4/inode.c	2012-02-22 18:21:15.000000000 +0100
+++ b/fs/ext4/inode.c	2012-02-23 10:53:48.893489058 +0100
@@ -3609,6 +3609,7 @@
 	struct inode *inode =3D io->inode;
 	loff_t offset =3D io->offset;
 	ssize_t size =3D io->size;
+	wait_queue_head_t *wq;
 	int ret =3D 0;
=20
 	ext4_debug("end_aio_dio_onlock: io 0x%p from inode %lu,list->next 0x%p,"
@@ -3619,7 +3620,7 @@
 	if (list_empty(&io->list))
 		return ret;
=20
=2D	if (io->flag !=3D DIO_AIO_UNWRITTEN)
+	if (!(io->flag & DIO_AIO_UNWRITTEN))
 		return ret;
=20
 	if (offset + size <=3D i_size_read(inode))
@@ -3633,7 +3634,16 @@
 	}
=20
 	/* clear the DIO AIO unwritten flag */
=2D	io->flag =3D 0;
+	if (io->flag & DIO_AIO_UNWRITTEN) {
+		io->flag &=3D ~DIO_AIO_UNWRITTEN;
+		/* Wake up anyone waiting on unwritten extent conversion */
+		wq =3D ext4_ioend_wq(io->inode);
+		if (atomic_dec_and_test(&EXT4_I(inode)->i_aiodio_unwritten) &&
+		    waitqueue_active(wq)) {
+			wake_up_all(wq);
+		}
+	}
+
 	return ret;
 }
 /*
@@ -3747,7 +3757,7 @@
 		  size);
=20
 	/* if not aio dio with unwritten extents, just free io and return */
=2D	if (io_end->flag !=3D DIO_AIO_UNWRITTEN){
+	if (!(io_end->flag & DIO_AIO_UNWRITTEN)) {
 		ext4_free_io_end(io_end);
 		iocb->private =3D NULL;
 		return;

--Boundary-01=_D3jRPNguxyYS6GX--

--nextPart1849790.JziXrtG3Yg
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)

iEYEABECAAYFAk9GPcMACgkQYPlgoZpUDjnX+wCdF3yNEwze7p9QDyxtLm4y3H7O
Oq0AoJysjortE/rngdExTlD4KdI1JYlK
=+s9j
-----END PGP SIGNATURE-----

--nextPart1849790.JziXrtG3Yg--


--===============8096001725940985653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8096001725940985653==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Yf9-0006yY-4Y; Thu, 23 Feb 2012 13:24:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1S0Yf7-0006xA-4l
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:24:45 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330003348!60951027!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29791 invoked from network); 23 Feb 2012 13:22:28 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-8.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 13:22:28 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 59ED96EA24F;
	Thu, 23 Feb 2012 14:24:37 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 44EB95B86C1;
	Thu, 23 Feb 2012 14:24:37 +0100 (CET)
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 PzRT36QDjf8U; Thu, 23 Feb 2012 14:24:36 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 366B16EA24F;
	Thu, 23 Feb 2012 14:24:28 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: "Ted Ts'o" <tytso@mit.edu>,
 Eric Sandeen <sandeen@redhat.com>
Date: Thu, 23 Feb 2012 14:23:15 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <4D2F7B52.1040209@redhat.com> <20110207023336.GI10402@thunk.org>
	<20110207155936.GA3457@thunk.org>
In-Reply-To: <20110207155936.GA3457@thunk.org>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202231424.23645.hahn@univention.de>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] backport "ext4: serialize unaligned asynchronous
	DIO" to 2.6.32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8096001725940985653=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8096001725940985653==
Content-Type: multipart/signed;
  boundary="nextPart1849790.JziXrtG3Yg";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1849790.JziXrtG3Yg
Content-Type: multipart/mixed;
  boundary="Boundary-01=_D3jRPNguxyYS6GX"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_D3jRPNguxyYS6GX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ted, hello Eric,

On Monday February 7th 2011 16:59:36 Ted Ts'o wrote:
> commit 7520bb0f2980ef79d17dcbec2783760b37490ffc
> Author: Eric Sandeen <sandeen@redhat.com>
> Date:   Mon Feb 7 10:57:28 2011 -0500
>
>     ext4: serialize unaligned asynchronous DIO
>
>     ext4 has a data corruption case when doing non-block-aligned
>     asynchronous direct IO into a sparse file, as demonstrated
>     by xfstest 240.

I hope you remember that bug, because I encountered this data corruption bu=
g=20
on Debians 2.6.32(.51) kernel as well.

On the other hand RedHat seems to have back-ported that fix to RHEL5 (2.6.1=
8) =20
and probably RHEL6 (2.6.32) as well, but I don't have a subscription, so I=
=20
can't verify that:
<http://rpmfind.net/linux/RPM/centos/updates/5.7/x86_64/RPMS/kernel-devel-2=
=2E6.18-274.12.1.el5.x86_64.html>
<https://bugzilla.redhat.com/show_bug.cgi?id=3D689830>

The Xen-people also encountered it and asked for someone to backport it:
<http://osdir.com/ml/xen-development/2011-07/msg00474.html>

I tried to backport it from 2.6.38~rc5 to 2.6.32.51 and thus far it seems t=
o=20
fix the bug. But several other things were re-named and re-organized betwee=
n=20
those versions, so it was not slreight forward.

Since I'm no ext4 expert, I'd like to ask you to have a look at this backpo=
rt.=20
Is it sound or are there some tests I can throw at it to get it tested more=
=20
thoroughly?
Does is classify for <mailto:stable@vger.kernel.org>?

Thanks in advance
Philipp Hahn
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--Boundary-01=_D3jRPNguxyYS6GX
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="26192_ext4-serialize-unaligned-asynchronous-DIO.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="26192_ext4-serialize-unaligned-asynchronous-DIO.patch"

commit e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Sat Feb 12 08:17:34 2011 -0500

    ext4: serialize unaligned asynchronous DIO
   =20
    ext4 has a data corruption case when doing non-block-aligned
    asynchronous direct IO into a sparse file, as demonstrated
    by xfstest 240.
   =20
    The root cause is that while ext4 preallocates space in the
    hole, mappings of that space still look "new" and
    dio_zero_block() will zero out the unwritten portions.  When
    more than one AIO thread is going, they both find this "new"
    block and race to zero out their portion; this is uncoordinated
    and causes data corruption.
   =20
    Dave Chinner fixed this for xfs by simply serializing all
    unaligned asynchronous direct IO.  I've done the same here.
    The difference is that we only wait on conversions, not all IO.
    This is a very big hammer, and I'm not very pleased with
    stuffing this into ext4_file_write().  But since ext4 is
    DIO_LOCKING, we need to serialize it at this high level.
   =20
    I tried to move this into ext4_ext_direct_IO, but by then
    we have the i_mutex already, and we will wait on the
    work queue to do conversions - which must also take the
    i_mutex.  So that won't work.
   =20
    This was originally exposed by qemu-kvm installing to
    a raw disk image with a normal sector-63 alignment.  I've
    tested a backport of this patch with qemu, and it does
    avoid the corruption.  It is also quite a lot slower
    (14 min for package installs, vs. 8 min for well-aligned)
    but I'll take slow correctness over fast corruption any day.
   =20
    Mingming suggested that we can track outstanding
    conversions, and wait on those so that non-sparse
    files won't be affected, and I've implemented that here;
    unaligned AIO to nonsparse files won't take a perf hit.
   =20
    [tytso@mit.edu: Keep the mutex as a hashed array instead
     of bloating the ext4 inode]
   =20
    [tytso@mit.edu: Fix up namespace issues so that global
     variables are protected with an "ext4_" prefix.]
   =20
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 67c46ed..10edb67 100644
=2D-- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -781,6 +781,8 @@ struct ext4_inode_info {
 	/* on-disk additional length */
 	__u16 i_extra_isize;
=20
+	atomic_t i_aiodio_unwritten; /* Nr. of inflight conversions pending */
+
 	spinlock_t i_block_reservation_lock;
 #ifdef CONFIG_QUOTA
 	/* quota space reservation, managed internally by quota code */
@@ -1889,6 +1891,15 @@ static inline void set_bitmap_uptodate(struct buffer=
_head *bh)
=20
 #define in_range(b, first, len)	((b) >=3D (first) && (b) <=3D (first) + (l=
en) - 1)
=20
+/* For ioend & aio unwritten conversion wait queues */
+#define EXT4_WQ_HASH_SZ		37
+#define ext4_ioend_wq(v)   (&ext4__ioend_wq[((unsigned long)(v)) %\
+					    EXT4_WQ_HASH_SZ])
+#define ext4_aio_mutex(v)  (&ext4__aio_mutex[((unsigned long)(v)) %\
+					     EXT4_WQ_HASH_SZ])
+extern wait_queue_head_t ext4__ioend_wq[EXT4_WQ_HASH_SZ];
+extern struct mutex ext4__aio_mutex[EXT4_WQ_HASH_SZ];
+
 #endif	/* __KERNEL__ */
=20
 #endif	/* _EXT4_H */
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ecbe20d..f4830e6 100644
=2D-- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3118,9 +3118,10 @@ ext4_ext_handle_uninitialized_extents(handle_t *hand=
le, struct inode *inode,
 		 * that this IO needs to convertion to written when IO is
 		 * completed
 		 */
=2D		if (io)
+		if (io && !(io->flag & DIO_AIO_UNWRITTEN)) {
 			io->flag =3D DIO_AIO_UNWRITTEN;
=2D		else
+			atomic_inc(&EXT4_I(inode)->i_aiodio_unwritten);
+		} else
 			ext4_set_inode_state(inode, EXT4_STATE_DIO_UNWRITTEN);
 		goto out;
 	}
@@ -3404,9 +3405,10 @@ int ext4_ext_get_blocks(handle_t *handle, struct ino=
de *inode,
 		 * that we need to perform convertion when IO is done.
 		 */
 		if (flags =3D=3D EXT4_GET_BLOCKS_DIO_CREATE_EXT) {
=2D			if (io)
+			if (io && !(io->flag & DIO_AIO_UNWRITTEN)) {
 				io->flag =3D DIO_AIO_UNWRITTEN;
=2D			else
+				atomic_inc(&EXT4_I(inode)->i_aiodio_unwritten);
+			} else
 				ext4_set_inode_state(inode,
 						     EXT4_STATE_DIO_UNWRITTEN);
 		}
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 2a60541..a18b45c 100644
=2D-- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -54,11 +54,47 @@ static int ext4_release_file(struct inode *inode, struc=
t file *filp)
 	return 0;
 }
=20
+static void ext4_aiodio_wait(struct inode *inode)
+{
+	wait_queue_head_t *wq =3D ext4_ioend_wq(inode);
+
+	wait_event(*wq, (atomic_read(&EXT4_I(inode)->i_aiodio_unwritten) =3D=3D 0=
));
+}
+
+/*
+ * This tests whether the IO in question is block-aligned or not.
+ * Ext4 utilizes unwritten extents when hole-filling during direct IO, and=
 they
+ * are converted to written only after the IO is complete.  Until they are
+ * mapped, these blocks appear as holes, so dio_zero_block() will assume t=
hat
+ * it needs to zero out portions of the start and/or end block.  If 2 AIO
+ * threads are at work on the same unwritten block, they must be synchroni=
zed
+ * or one thread will zero the other's data, causing corruption.
+ */
+static int
+ext4_unaligned_aio(struct inode *inode, const struct iovec *iov,
+		   unsigned long nr_segs, loff_t pos)
+{
+	struct super_block *sb =3D inode->i_sb;
+	int blockmask =3D sb->s_blocksize - 1;
+	size_t count =3D iov_length(iov, nr_segs);
+	loff_t final_size =3D pos + count;
+
+	if (pos >=3D inode->i_size)
+		return 0;
+
+	if ((pos & blockmask) || (final_size & blockmask))
+		return 1;
+
+	return 0;
+}
+
 static ssize_t
 ext4_file_write(struct kiocb *iocb, const struct iovec *iov,
 		unsigned long nr_segs, loff_t pos)
 {
 	struct inode *inode =3D iocb->ki_filp->f_path.dentry->d_inode;
+	int unaligned_aio =3D 0;
+	int ret;
=20
 	/*
 	 * If we have encountered a bitmap-format file, the size limit
@@ -76,9 +112,31 @@ ext4_file_write(struct kiocb *iocb, const struct iovec =
*iov,
 			nr_segs =3D iov_shorten((struct iovec *)iov, nr_segs,
 					      sbi->s_bitmap_maxbytes - pos);
 		}
+	} else if (unlikely((iocb->ki_filp->f_flags & O_DIRECT) &&
+		   !is_sync_kiocb(iocb))) {
+		unaligned_aio =3D ext4_unaligned_aio(inode, iov, nr_segs, pos);
 	}
=20
=2D	return generic_file_aio_write(iocb, iov, nr_segs, pos);
+	/* Unaligned direct AIO must be serialized; see comment above */
+	if (unaligned_aio) {
+		static unsigned long unaligned_warn_time;
+
+		/* Warn about this once per day */
+		if (printk_timed_ratelimit(&unaligned_warn_time, 60*60*24*HZ))
+			ext4_msg(inode->i_sb, KERN_WARNING,
+				 "Unaligned AIO/DIO on inode %ld by %s; "
+				 "performance will be poor.",
+				 inode->i_ino, current->comm);
+		mutex_lock(ext4_aio_mutex(inode));
+		ext4_aiodio_wait(inode);
+	}
+
+	ret =3D generic_file_aio_write(iocb, iov, nr_segs, pos);
+
+	if (unaligned_aio)
+		mutex_unlock(ext4_aio_mutex(inode));
+
+	return ret;
 }
=20
 static const struct vm_operations_struct ext4_file_vm_ops =3D {
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index f27e045..2cb8748 100644
=2D-- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -713,6 +713,7 @@ static struct inode *ext4_alloc_inode(struct super_bloc=
k *sb)
 	ei->cur_aio_dio =3D NULL;
 	ei->i_sync_tid =3D 0;
 	ei->i_datasync_tid =3D 0;
+	atomic_set(&ei->i_aiodio_unwritten, 0);
=20
 	return &ei->vfs_inode;
 }
@@ -4002,11 +4003,21 @@ static struct file_system_type ext4_fs_type =3D {
 	.fs_flags	=3D FS_REQUIRES_DEV,
 };
=20
+/* Shared across all ext4 file systems */
+wait_queue_head_t ext4__ioend_wq[EXT4_WQ_HASH_SZ];
+struct mutex ext4__aio_mutex[EXT4_WQ_HASH_SZ];
+
 static int __init init_ext4_fs(void)
 {
=2D	int err;
+	int i, err;
=20
 	ext4_check_flag_values();
+
+	for (i =3D 0; i < EXT4_WQ_HASH_SZ; i++) {
+		mutex_init(&ext4__aio_mutex[i]);
+		init_waitqueue_head(&ext4__ioend_wq[i]);
+	}
+
 	err =3D init_ext4_system_zone();
 	if (err)
 		return err;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
=2D-- a/fs/ext4/inode.c	2012-02-22 18:21:15.000000000 +0100
+++ b/fs/ext4/inode.c	2012-02-23 10:53:48.893489058 +0100
@@ -3609,6 +3609,7 @@
 	struct inode *inode =3D io->inode;
 	loff_t offset =3D io->offset;
 	ssize_t size =3D io->size;
+	wait_queue_head_t *wq;
 	int ret =3D 0;
=20
 	ext4_debug("end_aio_dio_onlock: io 0x%p from inode %lu,list->next 0x%p,"
@@ -3619,7 +3620,7 @@
 	if (list_empty(&io->list))
 		return ret;
=20
=2D	if (io->flag !=3D DIO_AIO_UNWRITTEN)
+	if (!(io->flag & DIO_AIO_UNWRITTEN))
 		return ret;
=20
 	if (offset + size <=3D i_size_read(inode))
@@ -3633,7 +3634,16 @@
 	}
=20
 	/* clear the DIO AIO unwritten flag */
=2D	io->flag =3D 0;
+	if (io->flag & DIO_AIO_UNWRITTEN) {
+		io->flag &=3D ~DIO_AIO_UNWRITTEN;
+		/* Wake up anyone waiting on unwritten extent conversion */
+		wq =3D ext4_ioend_wq(io->inode);
+		if (atomic_dec_and_test(&EXT4_I(inode)->i_aiodio_unwritten) &&
+		    waitqueue_active(wq)) {
+			wake_up_all(wq);
+		}
+	}
+
 	return ret;
 }
 /*
@@ -3747,7 +3757,7 @@
 		  size);
=20
 	/* if not aio dio with unwritten extents, just free io and return */
=2D	if (io_end->flag !=3D DIO_AIO_UNWRITTEN){
+	if (!(io_end->flag & DIO_AIO_UNWRITTEN)) {
 		ext4_free_io_end(io_end);
 		iocb->private =3D NULL;
 		return;

--Boundary-01=_D3jRPNguxyYS6GX--

--nextPart1849790.JziXrtG3Yg
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)

iEYEABECAAYFAk9GPcMACgkQYPlgoZpUDjnX+wCdF3yNEwze7p9QDyxtLm4y3H7O
Oq0AoJysjortE/rngdExTlD4KdI1JYlK
=+s9j
-----END PGP SIGNATURE-----

--nextPart1849790.JziXrtG3Yg--


--===============8096001725940985653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8096001725940985653==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 13:28:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YiZ-0007Dh-Tp; Thu, 23 Feb 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 <jinsong.liu@intel.com>) id 1S0YiZ-0007Db-3H
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:28:19 +0000
Received: from [85.158.139.83:9899] by server-3.bemta-5.messagelabs.com id
	F8/6D-06438-2FE364F4; Thu, 23 Feb 2012 13:28:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330003696!12401052!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAxODk4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24634 invoked from network); 23 Feb 2012 13:28:17 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 13:28:17 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 23 Feb 2012 05:28:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="109906500"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by azsmga001.ch.intel.com with ESMTP; 23 Feb 2012 05:28:01 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 21:26:55 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 21:26:53 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM8Y8IqETlTTaR00eoPTQ1GukvM5ZKdNlQ
Date: Thu, 23 Feb 2012 13:26:53 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD052@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
	<20120221142724.GB5652@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
	<20120222182312.GE3132@phenom.dumpdata.com>
In-Reply-To: <20120222182312.GE3132@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 22, 2012 at 05:02:59PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>>>>>> +struct pv_pad_ops {
>>>>>>>>> +	int (*acpi_pad_init)(void);
>>>>>>>>> +	void (*acpi_pad_exit)(void);
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>> 
>>>>>>> Looking at this a bit closer I am not sure why you choose the
>>>>>>> paravirt interface for this? There is another one - the x86 that
>>>>>>> could have been choosen. Or introduce a new one that is
>>>>>>> specific to ACPI. 
>>>>>>> 
>>>>>>> I am curious - what was the reason for using the paravirt
>>>>>>> interface? I understand it does get the job done, but it seems a
>>>>>>> bit overkill when something simple could have been used?
>>>>>>> 
>>>>>> 
>>>>>> It uses paravirt interface to avoid some code like 'xen_...' in
>>>>>> native code path (acpi_pad.c).
>>>>>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
>>>>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>>>>>> seems it's much simpler.
>>>>> 
>>>>> arch/x86/include/asm/x86_init.h
>>>>> 
>>>>> But before you go that way let me ask you another question - can
>>>>> ACPI PAD be used on ARM or IA64? If so, wouldn't this fail
>>>>> compilation as this pvops structure is not defined on IA64?
>>>> 
>>>> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
>>>> at least on IA64 (through currently no real PAD on IA64 platform as
>>>> far as I know). However, in native acpi_pad implementation, it
>>>> indeed depends on X86 for reason like mwait.
>>>> So for xen acpi_pad, I think it's OK to choose x86, defining an
>>>> acpi_pad_ops at x86_init.c which would be overwritten when xen
>>>> init. 
>>> 
>>> OK, or in osl.c. We need Len to chime in here as I can see this
>>> expanding in the future.
>>>> 
>>>> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
>>>> 'bool', which would disable native acpi_pad module.
>>> 
>>> Ewww. No.
>> 
>> I'm OK with x86_init approach, but advantage of 'config
>> ACPI_PROCESSOR_AGGREGATOR as bool' would get rid of X86/IA64/...
>> arch issue for xen (at least from coding view), through it need
>> disable native acpi_pad module (IMO acpi_pad module has not strong
>> reason to must be so). Have a re-consider of this approach? :-)   
> 
> But it is a compile option right? We wantone kernel that can do both
> baremetal and Xen.

Sorry, I didn't speak clear my approach.
The approach can enable kernel run both baremetal and Xen platform, and not bind acpi pad logic to x86.
Send 2 patches as RFC.

Thanks
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:28:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YiZ-0007Dh-Tp; Thu, 23 Feb 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 <jinsong.liu@intel.com>) id 1S0YiZ-0007Db-3H
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:28:19 +0000
Received: from [85.158.139.83:9899] by server-3.bemta-5.messagelabs.com id
	F8/6D-06438-2FE364F4; Thu, 23 Feb 2012 13:28:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330003696!12401052!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAxODk4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24634 invoked from network); 23 Feb 2012 13:28:17 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 13:28:17 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 23 Feb 2012 05:28:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="109906500"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by azsmga001.ch.intel.com with ESMTP; 23 Feb 2012 05:28:01 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 21:26:55 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 21:26:53 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
	platform
Thread-Index: AQHM8Y8IqETlTTaR00eoPTQ1GukvM5ZKdNlQ
Date: Thu, 23 Feb 2012 13:26:53 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD052@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D853@SHSMSX101.ccr.corp.intel.com>
	<20120217142909.GA29110@phenom.dumpdata.com>
	<20120217144742.GA29454@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A097D@SHSMSX101.ccr.corp.intel.com>
	<20120219182339.GA11882@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350A3E7C@SHSMSX101.ccr.corp.intel.com>
	<20120221142724.GB5652@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350AA0BE@SHSMSX101.ccr.corp.intel.com>
	<20120222182312.GE3132@phenom.dumpdata.com>
In-Reply-To: <20120222182312.GE3132@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 22, 2012 at 05:02:59PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>>>>>> +struct pv_pad_ops {
>>>>>>>>> +	int (*acpi_pad_init)(void);
>>>>>>>>> +	void (*acpi_pad_exit)(void);
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>> 
>>>>>>> Looking at this a bit closer I am not sure why you choose the
>>>>>>> paravirt interface for this? There is another one - the x86 that
>>>>>>> could have been choosen. Or introduce a new one that is
>>>>>>> specific to ACPI. 
>>>>>>> 
>>>>>>> I am curious - what was the reason for using the paravirt
>>>>>>> interface? I understand it does get the job done, but it seems a
>>>>>>> bit overkill when something simple could have been used?
>>>>>>> 
>>>>>> 
>>>>>> It uses paravirt interface to avoid some code like 'xen_...' in
>>>>>> native code path (acpi_pad.c).
>>>>>> I'm not quite sure what does 'x86' here mean? Adding 2 fields
>>>>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>>>>>> seems it's much simpler.
>>>>> 
>>>>> arch/x86/include/asm/x86_init.h
>>>>> 
>>>>> But before you go that way let me ask you another question - can
>>>>> ACPI PAD be used on ARM or IA64? If so, wouldn't this fail
>>>>> compilation as this pvops structure is not defined on IA64?
>>>> 
>>>> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
>>>> at least on IA64 (through currently no real PAD on IA64 platform as
>>>> far as I know). However, in native acpi_pad implementation, it
>>>> indeed depends on X86 for reason like mwait.
>>>> So for xen acpi_pad, I think it's OK to choose x86, defining an
>>>> acpi_pad_ops at x86_init.c which would be overwritten when xen
>>>> init. 
>>> 
>>> OK, or in osl.c. We need Len to chime in here as I can see this
>>> expanding in the future.
>>>> 
>>>> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
>>>> 'bool', which would disable native acpi_pad module.
>>> 
>>> Ewww. No.
>> 
>> I'm OK with x86_init approach, but advantage of 'config
>> ACPI_PROCESSOR_AGGREGATOR as bool' would get rid of X86/IA64/...
>> arch issue for xen (at least from coding view), through it need
>> disable native acpi_pad module (IMO acpi_pad module has not strong
>> reason to must be so). Have a re-consider of this approach? :-)   
> 
> But it is a compile option right? We wantone kernel that can do both
> baremetal and Xen.

Sorry, I didn't speak clear my approach.
The approach can enable kernel run both baremetal and Xen platform, and not bind acpi pad logic to x86.
Send 2 patches as RFC.

Thanks
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YkA-0007LF-DX; Thu, 23 Feb 2012 13:29:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S0Yk9-0007Kv-3O
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:29:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330003789!4236772!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5MTEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4341 invoked from network); 23 Feb 2012 13:29:50 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 13:29:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 23 Feb 2012 05:29:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="scan'208,223";a="111188421"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by orsmga001.jf.intel.com with ESMTP; 23 Feb 2012 05:29:44 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 23 Feb 2012 21:29:43 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 21:29:42 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 21:29:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AczyLzHym4MGy1d3TzK01xgwJYdnxQ==
Date: Thu, 23 Feb 2012 13:29:40 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD088@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_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 9a12d7c610bffb900015e8947a57e4e428058abf Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 24 Feb 2012 01:51:18 +0800
Subject: [PATCH 1/2] Prepare PAD for native and xen platform

This patch is to prepare PAD (Processor Aggregator Device) for native and x=
en platform.
When working under baremetal it initializes native acpi_pad, while working =
under
xen platform it would hook to xen acpi_pad (would implement at later patch)=
.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/acpi/Kconfig        |    3 ++-
 drivers/acpi/acpi_pad.c     |   21 +++++++++------------
 include/acpi/acpi_drivers.h |   15 +++++++++++++++
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7556913..2653a98 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
 	default y
=20
 config ACPI_PROCESSOR_AGGREGATOR
-	tristate "Processor Aggregator"
+	bool "Processor Aggregator"
 	depends on ACPI_PROCESSOR
 	depends on EXPERIMENTAL
 	depends on X86
+	default n
 	help
 	  ACPI 4.0 defines processor Aggregator, which enables OS to perform
 	  specific processor configuration and control that applies to all
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..8aebbe5 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -2,6 +2,7 @@
  * acpi_pad.c ACPI Processor Aggregator Driver
  *
  * Copyright (c) 2009, Intel Corporation.
+ *    Author: Li, Shaohua <shaohua.li@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,
@@ -32,9 +33,6 @@
 #include <acpi/acpi_drivers.h>
 #include <asm/mwait.h>
=20
-#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
-#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
-#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
 static DEFINE_MUTEX(isolated_cpus_lock);
=20
 static unsigned long power_saving_mwait_eax;
@@ -510,7 +508,7 @@ static struct acpi_driver acpi_pad_driver =3D {
 	},
 };
=20
-static int __init acpi_pad_init(void)
+static int __init native_acpi_pad_init(void)
 {
 	power_saving_mwait_init();
 	if (power_saving_mwait_eax =3D=3D 0)
@@ -519,13 +517,12 @@ static int __init acpi_pad_init(void)
 	return acpi_bus_register_driver(&acpi_pad_driver);
 }
=20
-static void __exit acpi_pad_exit(void)
+struct acpi_pad_ops acpi_pad_ops =3D {
+	.init =3D native_acpi_pad_init,
+};
+
+static int __init acpi_pad_init(void)
 {
-	acpi_bus_unregister_driver(&acpi_pad_driver);
+	return acpi_pad_ops.init();
 }
-
-module_init(acpi_pad_init);
-module_exit(acpi_pad_exit);
-MODULE_AUTHOR("Shaohua Li<shaohua.li@intel.com>");
-MODULE_DESCRIPTION("ACPI Processor Aggregator Driver");
-MODULE_LICENSE("GPL");
+device_initcall(acpi_pad_init);
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index bb145e4..d40abbc 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -115,6 +115,21 @@ void pci_acpi_crs_quirks(void);
 #define ACPI_PROCESSOR_LIMIT_INCREMENT	0x01
 #define ACPI_PROCESSOR_LIMIT_DECREMENT	0x02
=20
+/* -----------------------------------------------------------------------=
---
+			PAD (Processor Aggregator Device)
+   -----------------------------------------------------------------------=
--- */
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+struct acpi_pad_ops {
+	int (*init)(void);
+};
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+extern struct acpi_pad_ops acpi_pad_ops;
+#endif
+
 /*------------------------------------------------------------------------=
--
                                   Dock Station
   ------------------------------------------------------------------------=
-- */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Prepare-PAD-for-native-and-xen-platform.patch"
Content-Description: 0001-Prepare-PAD-for-native-and-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Prepare-PAD-for-native-and-xen-platform.patch"; size=3905;
	creation-date="Thu, 23 Feb 2012 13:05:12 GMT";
	modification-date="Thu, 23 Feb 2012 20:58:38 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5YTEyZDdjNjEwYmZmYjkwMDAxNWU4OTQ3YTU3ZTRlNDI4MDU4YWJmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNCBGZWIgMjAxMiAwMTo1MToxOCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBQcmVwYXJlIFBBRCBmb3IgbmF0aXZlIGFuZCB4ZW4gcGxhdGZvcm0KClRoaXMgcGF0Y2ggaXMg
dG8gcHJlcGFyZSBQQUQgKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkgZm9yIG5hdGl2ZSBh
bmQgeGVuIHBsYXRmb3JtLgpXaGVuIHdvcmtpbmcgdW5kZXIgYmFyZW1ldGFsIGl0IGluaXRpYWxp
emVzIG5hdGl2ZSBhY3BpX3BhZCwgd2hpbGUgd29ya2luZyB1bmRlcgp4ZW4gcGxhdGZvcm0gaXQg
d291bGQgaG9vayB0byB4ZW4gYWNwaV9wYWQgKHdvdWxkIGltcGxlbWVudCBhdCBsYXRlciBwYXRj
aCkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
LS0tCiBkcml2ZXJzL2FjcGkvS2NvbmZpZyAgICAgICAgfCAgICAzICsrLQogZHJpdmVycy9hY3Bp
L2FjcGlfcGFkLmMgICAgIHwgICAyMSArKysrKysrKystLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNw
aS9hY3BpX2RyaXZlcnMuaCB8ICAgMTUgKysrKysrKysrKysrKysrCiAzIGZpbGVzIGNoYW5nZWQs
IDI2IGluc2VydGlvbnMoKyksIDEzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMv
YWNwaS9LY29uZmlnIGIvZHJpdmVycy9hY3BpL0tjb25maWcKaW5kZXggNzU1NjkxMy4uMjY1M2E5
OCAxMDA2NDQKLS0tIGEvZHJpdmVycy9hY3BpL0tjb25maWcKKysrIGIvZHJpdmVycy9hY3BpL0tj
b25maWcKQEAgLTIxMywxMCArMjEzLDExIEBAIGNvbmZpZyBBQ1BJX0hPVFBMVUdfQ1BVCiAJZGVm
YXVsdCB5CiAKIGNvbmZpZyBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SCi0JdHJpc3RhdGUgIlBy
b2Nlc3NvciBBZ2dyZWdhdG9yIgorCWJvb2wgIlByb2Nlc3NvciBBZ2dyZWdhdG9yIgogCWRlcGVu
ZHMgb24gQUNQSV9QUk9DRVNTT1IKIAlkZXBlbmRzIG9uIEVYUEVSSU1FTlRBTAogCWRlcGVuZHMg
b24gWDg2CisJZGVmYXVsdCBuCiAJaGVscAogCSAgQUNQSSA0LjAgZGVmaW5lcyBwcm9jZXNzb3Ig
QWdncmVnYXRvciwgd2hpY2ggZW5hYmxlcyBPUyB0byBwZXJmb3JtCiAJICBzcGVjaWZpYyBwcm9j
ZXNzb3IgY29uZmlndXJhdGlvbiBhbmQgY29udHJvbCB0aGF0IGFwcGxpZXMgdG8gYWxsCmRpZmYg
LS1naXQgYS9kcml2ZXJzL2FjcGkvYWNwaV9wYWQuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX3BhZC5j
CmluZGV4IGE0M2ZhMWEuLjhhZWJiZTUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9hY3BpX3Bh
ZC5jCisrKyBiL2RyaXZlcnMvYWNwaS9hY3BpX3BhZC5jCkBAIC0yLDYgKzIsNyBAQAogICogYWNw
aV9wYWQuYyBBQ1BJIFByb2Nlc3NvciBBZ2dyZWdhdG9yIERyaXZlcgogICoKICAqIENvcHlyaWdo
dCAoYykgMjAwOSwgSW50ZWwgQ29ycG9yYXRpb24uCisgKiAgICBBdXRob3I6IExpLCBTaGFvaHVh
IDxzaGFvaHVhLmxpQGludGVsLmNvbT4KICAqCiAgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0
d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAogICogdW5kZXIg
dGhlIHRlcm1zIGFuZCBjb25kaXRpb25zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSwKQEAgLTMyLDkgKzMzLDYgQEAKICNpbmNsdWRlIDxhY3BpL2FjcGlfZHJpdmVycy5oPgogI2lu
Y2x1ZGUgPGFzbS9td2FpdC5oPgogCi0jZGVmaW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1Jf
Q0xBU1MJImFjcGlfcGFkIgotI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0RFVklD
RV9OQU1FICJQcm9jZXNzb3IgQWdncmVnYXRvciIKLSNkZWZpbmUgQUNQSV9QUk9DRVNTT1JfQUdH
UkVHQVRPUl9OT1RJRlkgMHg4MAogc3RhdGljIERFRklORV9NVVRFWChpc29sYXRlZF9jcHVzX2xv
Y2spOwogCiBzdGF0aWMgdW5zaWduZWQgbG9uZyBwb3dlcl9zYXZpbmdfbXdhaXRfZWF4OwpAQCAt
NTEwLDcgKzUwOCw3IEBAIHN0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgYWNwaV9wYWRfZHJpdmVy
ID0gewogCX0sCiB9OwogCi1zdGF0aWMgaW50IF9faW5pdCBhY3BpX3BhZF9pbml0KHZvaWQpCitz
dGF0aWMgaW50IF9faW5pdCBuYXRpdmVfYWNwaV9wYWRfaW5pdCh2b2lkKQogewogCXBvd2VyX3Nh
dmluZ19td2FpdF9pbml0KCk7CiAJaWYgKHBvd2VyX3NhdmluZ19td2FpdF9lYXggPT0gMCkKQEAg
LTUxOSwxMyArNTE3LDEyIEBAIHN0YXRpYyBpbnQgX19pbml0IGFjcGlfcGFkX2luaXQodm9pZCkK
IAlyZXR1cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIpOwogfQog
Ci1zdGF0aWMgdm9pZCBfX2V4aXQgYWNwaV9wYWRfZXhpdCh2b2lkKQorc3RydWN0IGFjcGlfcGFk
X29wcyBhY3BpX3BhZF9vcHMgPSB7CisJLmluaXQgPSBuYXRpdmVfYWNwaV9wYWRfaW5pdCwKK307
CisKK3N0YXRpYyBpbnQgX19pbml0IGFjcGlfcGFkX2luaXQodm9pZCkKIHsKLQlhY3BpX2J1c191
bnJlZ2lzdGVyX2RyaXZlcigmYWNwaV9wYWRfZHJpdmVyKTsKKwlyZXR1cm4gYWNwaV9wYWRfb3Bz
LmluaXQoKTsKIH0KLQotbW9kdWxlX2luaXQoYWNwaV9wYWRfaW5pdCk7Ci1tb2R1bGVfZXhpdChh
Y3BpX3BhZF9leGl0KTsKLU1PRFVMRV9BVVRIT1IoIlNoYW9odWEgTGk8c2hhb2h1YS5saUBpbnRl
bC5jb20+Iik7Ci1NT0RVTEVfREVTQ1JJUFRJT04oIkFDUEkgUHJvY2Vzc29yIEFnZ3JlZ2F0b3Ig
RHJpdmVyIik7Ci1NT0RVTEVfTElDRU5TRSgiR1BMIik7CitkZXZpY2VfaW5pdGNhbGwoYWNwaV9w
YWRfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNs
dWRlL2FjcGkvYWNwaV9kcml2ZXJzLmgKaW5kZXggYmIxNDVlNC4uZDQwYWJiYyAxMDA2NDQKLS0t
IGEvaW5jbHVkZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2Ry
aXZlcnMuaApAQCAtMTE1LDYgKzExNSwyMSBAQCB2b2lkIHBjaV9hY3BpX2Nyc19xdWlya3Modm9p
ZCk7CiAjZGVmaW5lIEFDUElfUFJPQ0VTU09SX0xJTUlUX0lOQ1JFTUVOVAkweDAxCiAjZGVmaW5l
IEFDUElfUFJPQ0VTU09SX0xJTUlUX0RFQ1JFTUVOVAkweDAyCiAKKy8qIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tCisJCQlQQUQgKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkKKyAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tICovCisKKyNkZWZpbmUgQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUwkiYWNw
aV9wYWQiCisjZGVmaW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfREVWSUNFX05BTUUgIlBy
b2Nlc3NvciBBZ2dyZWdhdG9yIgorI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05P
VElGWSAweDgwCisKK3N0cnVjdCBhY3BpX3BhZF9vcHMgeworCWludCAoKmluaXQpKHZvaWQpOwor
fTsKKyNpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUgorZXh0ZXJuIHN0cnVj
dCBhY3BpX3BhZF9vcHMgYWNwaV9wYWRfb3BzOworI2VuZGlmCisKIC8qLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEb2NrIFN0YXRpb24KICAgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gKi8KLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Feb 23 13:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13: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 1S0YkA-0007LF-DX; Thu, 23 Feb 2012 13:29:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S0Yk9-0007Kv-3O
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:29:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330003789!4236772!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5MTEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4341 invoked from network); 23 Feb 2012 13:29:50 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 13:29:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 23 Feb 2012 05:29:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; 
	d="scan'208,223";a="111188421"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by orsmga001.jf.intel.com with ESMTP; 23 Feb 2012 05:29:44 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 23 Feb 2012 21:29:43 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 21:29:42 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 21:29:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AczyLzHym4MGy1d3TzK01xgwJYdnxQ==
Date: Thu, 23 Feb 2012 13:29:40 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD088@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_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 9a12d7c610bffb900015e8947a57e4e428058abf Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 24 Feb 2012 01:51:18 +0800
Subject: [PATCH 1/2] Prepare PAD for native and xen platform

This patch is to prepare PAD (Processor Aggregator Device) for native and x=
en platform.
When working under baremetal it initializes native acpi_pad, while working =
under
xen platform it would hook to xen acpi_pad (would implement at later patch)=
.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 drivers/acpi/Kconfig        |    3 ++-
 drivers/acpi/acpi_pad.c     |   21 +++++++++------------
 include/acpi/acpi_drivers.h |   15 +++++++++++++++
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7556913..2653a98 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
 	default y
=20
 config ACPI_PROCESSOR_AGGREGATOR
-	tristate "Processor Aggregator"
+	bool "Processor Aggregator"
 	depends on ACPI_PROCESSOR
 	depends on EXPERIMENTAL
 	depends on X86
+	default n
 	help
 	  ACPI 4.0 defines processor Aggregator, which enables OS to perform
 	  specific processor configuration and control that applies to all
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..8aebbe5 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -2,6 +2,7 @@
  * acpi_pad.c ACPI Processor Aggregator Driver
  *
  * Copyright (c) 2009, Intel Corporation.
+ *    Author: Li, Shaohua <shaohua.li@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,
@@ -32,9 +33,6 @@
 #include <acpi/acpi_drivers.h>
 #include <asm/mwait.h>
=20
-#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
-#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
-#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
 static DEFINE_MUTEX(isolated_cpus_lock);
=20
 static unsigned long power_saving_mwait_eax;
@@ -510,7 +508,7 @@ static struct acpi_driver acpi_pad_driver =3D {
 	},
 };
=20
-static int __init acpi_pad_init(void)
+static int __init native_acpi_pad_init(void)
 {
 	power_saving_mwait_init();
 	if (power_saving_mwait_eax =3D=3D 0)
@@ -519,13 +517,12 @@ static int __init acpi_pad_init(void)
 	return acpi_bus_register_driver(&acpi_pad_driver);
 }
=20
-static void __exit acpi_pad_exit(void)
+struct acpi_pad_ops acpi_pad_ops =3D {
+	.init =3D native_acpi_pad_init,
+};
+
+static int __init acpi_pad_init(void)
 {
-	acpi_bus_unregister_driver(&acpi_pad_driver);
+	return acpi_pad_ops.init();
 }
-
-module_init(acpi_pad_init);
-module_exit(acpi_pad_exit);
-MODULE_AUTHOR("Shaohua Li<shaohua.li@intel.com>");
-MODULE_DESCRIPTION("ACPI Processor Aggregator Driver");
-MODULE_LICENSE("GPL");
+device_initcall(acpi_pad_init);
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index bb145e4..d40abbc 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -115,6 +115,21 @@ void pci_acpi_crs_quirks(void);
 #define ACPI_PROCESSOR_LIMIT_INCREMENT	0x01
 #define ACPI_PROCESSOR_LIMIT_DECREMENT	0x02
=20
+/* -----------------------------------------------------------------------=
---
+			PAD (Processor Aggregator Device)
+   -----------------------------------------------------------------------=
--- */
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+struct acpi_pad_ops {
+	int (*init)(void);
+};
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+extern struct acpi_pad_ops acpi_pad_ops;
+#endif
+
 /*------------------------------------------------------------------------=
--
                                   Dock Station
   ------------------------------------------------------------------------=
-- */
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Prepare-PAD-for-native-and-xen-platform.patch"
Content-Description: 0001-Prepare-PAD-for-native-and-xen-platform.patch
Content-Disposition: attachment;
	filename="0001-Prepare-PAD-for-native-and-xen-platform.patch"; size=3905;
	creation-date="Thu, 23 Feb 2012 13:05:12 GMT";
	modification-date="Thu, 23 Feb 2012 20:58:38 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5YTEyZDdjNjEwYmZmYjkwMDAxNWU4OTQ3YTU3ZTRlNDI4MDU4YWJmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNCBGZWIgMjAxMiAwMTo1MToxOCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBQcmVwYXJlIFBBRCBmb3IgbmF0aXZlIGFuZCB4ZW4gcGxhdGZvcm0KClRoaXMgcGF0Y2ggaXMg
dG8gcHJlcGFyZSBQQUQgKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkgZm9yIG5hdGl2ZSBh
bmQgeGVuIHBsYXRmb3JtLgpXaGVuIHdvcmtpbmcgdW5kZXIgYmFyZW1ldGFsIGl0IGluaXRpYWxp
emVzIG5hdGl2ZSBhY3BpX3BhZCwgd2hpbGUgd29ya2luZyB1bmRlcgp4ZW4gcGxhdGZvcm0gaXQg
d291bGQgaG9vayB0byB4ZW4gYWNwaV9wYWQgKHdvdWxkIGltcGxlbWVudCBhdCBsYXRlciBwYXRj
aCkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
LS0tCiBkcml2ZXJzL2FjcGkvS2NvbmZpZyAgICAgICAgfCAgICAzICsrLQogZHJpdmVycy9hY3Bp
L2FjcGlfcGFkLmMgICAgIHwgICAyMSArKysrKysrKystLS0tLS0tLS0tLS0KIGluY2x1ZGUvYWNw
aS9hY3BpX2RyaXZlcnMuaCB8ICAgMTUgKysrKysrKysrKysrKysrCiAzIGZpbGVzIGNoYW5nZWQs
IDI2IGluc2VydGlvbnMoKyksIDEzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMv
YWNwaS9LY29uZmlnIGIvZHJpdmVycy9hY3BpL0tjb25maWcKaW5kZXggNzU1NjkxMy4uMjY1M2E5
OCAxMDA2NDQKLS0tIGEvZHJpdmVycy9hY3BpL0tjb25maWcKKysrIGIvZHJpdmVycy9hY3BpL0tj
b25maWcKQEAgLTIxMywxMCArMjEzLDExIEBAIGNvbmZpZyBBQ1BJX0hPVFBMVUdfQ1BVCiAJZGVm
YXVsdCB5CiAKIGNvbmZpZyBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SCi0JdHJpc3RhdGUgIlBy
b2Nlc3NvciBBZ2dyZWdhdG9yIgorCWJvb2wgIlByb2Nlc3NvciBBZ2dyZWdhdG9yIgogCWRlcGVu
ZHMgb24gQUNQSV9QUk9DRVNTT1IKIAlkZXBlbmRzIG9uIEVYUEVSSU1FTlRBTAogCWRlcGVuZHMg
b24gWDg2CisJZGVmYXVsdCBuCiAJaGVscAogCSAgQUNQSSA0LjAgZGVmaW5lcyBwcm9jZXNzb3Ig
QWdncmVnYXRvciwgd2hpY2ggZW5hYmxlcyBPUyB0byBwZXJmb3JtCiAJICBzcGVjaWZpYyBwcm9j
ZXNzb3IgY29uZmlndXJhdGlvbiBhbmQgY29udHJvbCB0aGF0IGFwcGxpZXMgdG8gYWxsCmRpZmYg
LS1naXQgYS9kcml2ZXJzL2FjcGkvYWNwaV9wYWQuYyBiL2RyaXZlcnMvYWNwaS9hY3BpX3BhZC5j
CmluZGV4IGE0M2ZhMWEuLjhhZWJiZTUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYWNwaS9hY3BpX3Bh
ZC5jCisrKyBiL2RyaXZlcnMvYWNwaS9hY3BpX3BhZC5jCkBAIC0yLDYgKzIsNyBAQAogICogYWNw
aV9wYWQuYyBBQ1BJIFByb2Nlc3NvciBBZ2dyZWdhdG9yIERyaXZlcgogICoKICAqIENvcHlyaWdo
dCAoYykgMjAwOSwgSW50ZWwgQ29ycG9yYXRpb24uCisgKiAgICBBdXRob3I6IExpLCBTaGFvaHVh
IDxzaGFvaHVhLmxpQGludGVsLmNvbT4KICAqCiAgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0
d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAogICogdW5kZXIg
dGhlIHRlcm1zIGFuZCBjb25kaXRpb25zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSwKQEAgLTMyLDkgKzMzLDYgQEAKICNpbmNsdWRlIDxhY3BpL2FjcGlfZHJpdmVycy5oPgogI2lu
Y2x1ZGUgPGFzbS9td2FpdC5oPgogCi0jZGVmaW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1Jf
Q0xBU1MJImFjcGlfcGFkIgotI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0RFVklD
RV9OQU1FICJQcm9jZXNzb3IgQWdncmVnYXRvciIKLSNkZWZpbmUgQUNQSV9QUk9DRVNTT1JfQUdH
UkVHQVRPUl9OT1RJRlkgMHg4MAogc3RhdGljIERFRklORV9NVVRFWChpc29sYXRlZF9jcHVzX2xv
Y2spOwogCiBzdGF0aWMgdW5zaWduZWQgbG9uZyBwb3dlcl9zYXZpbmdfbXdhaXRfZWF4OwpAQCAt
NTEwLDcgKzUwOCw3IEBAIHN0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgYWNwaV9wYWRfZHJpdmVy
ID0gewogCX0sCiB9OwogCi1zdGF0aWMgaW50IF9faW5pdCBhY3BpX3BhZF9pbml0KHZvaWQpCitz
dGF0aWMgaW50IF9faW5pdCBuYXRpdmVfYWNwaV9wYWRfaW5pdCh2b2lkKQogewogCXBvd2VyX3Nh
dmluZ19td2FpdF9pbml0KCk7CiAJaWYgKHBvd2VyX3NhdmluZ19td2FpdF9lYXggPT0gMCkKQEAg
LTUxOSwxMyArNTE3LDEyIEBAIHN0YXRpYyBpbnQgX19pbml0IGFjcGlfcGFkX2luaXQodm9pZCkK
IAlyZXR1cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX3BhZF9kcml2ZXIpOwogfQog
Ci1zdGF0aWMgdm9pZCBfX2V4aXQgYWNwaV9wYWRfZXhpdCh2b2lkKQorc3RydWN0IGFjcGlfcGFk
X29wcyBhY3BpX3BhZF9vcHMgPSB7CisJLmluaXQgPSBuYXRpdmVfYWNwaV9wYWRfaW5pdCwKK307
CisKK3N0YXRpYyBpbnQgX19pbml0IGFjcGlfcGFkX2luaXQodm9pZCkKIHsKLQlhY3BpX2J1c191
bnJlZ2lzdGVyX2RyaXZlcigmYWNwaV9wYWRfZHJpdmVyKTsKKwlyZXR1cm4gYWNwaV9wYWRfb3Bz
LmluaXQoKTsKIH0KLQotbW9kdWxlX2luaXQoYWNwaV9wYWRfaW5pdCk7Ci1tb2R1bGVfZXhpdChh
Y3BpX3BhZF9leGl0KTsKLU1PRFVMRV9BVVRIT1IoIlNoYW9odWEgTGk8c2hhb2h1YS5saUBpbnRl
bC5jb20+Iik7Ci1NT0RVTEVfREVTQ1JJUFRJT04oIkFDUEkgUHJvY2Vzc29yIEFnZ3JlZ2F0b3Ig
RHJpdmVyIik7Ci1NT0RVTEVfTElDRU5TRSgiR1BMIik7CitkZXZpY2VfaW5pdGNhbGwoYWNwaV9w
YWRfaW5pdCk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL2FjcGkvYWNwaV9kcml2ZXJzLmggYi9pbmNs
dWRlL2FjcGkvYWNwaV9kcml2ZXJzLmgKaW5kZXggYmIxNDVlNC4uZDQwYWJiYyAxMDA2NDQKLS0t
IGEvaW5jbHVkZS9hY3BpL2FjcGlfZHJpdmVycy5oCisrKyBiL2luY2x1ZGUvYWNwaS9hY3BpX2Ry
aXZlcnMuaApAQCAtMTE1LDYgKzExNSwyMSBAQCB2b2lkIHBjaV9hY3BpX2Nyc19xdWlya3Modm9p
ZCk7CiAjZGVmaW5lIEFDUElfUFJPQ0VTU09SX0xJTUlUX0lOQ1JFTUVOVAkweDAxCiAjZGVmaW5l
IEFDUElfUFJPQ0VTU09SX0xJTUlUX0RFQ1JFTUVOVAkweDAyCiAKKy8qIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tCisJCQlQQUQgKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkKKyAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tICovCisKKyNkZWZpbmUgQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUwkiYWNw
aV9wYWQiCisjZGVmaW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfREVWSUNFX05BTUUgIlBy
b2Nlc3NvciBBZ2dyZWdhdG9yIgorI2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05P
VElGWSAweDgwCisKK3N0cnVjdCBhY3BpX3BhZF9vcHMgeworCWludCAoKmluaXQpKHZvaWQpOwor
fTsKKyNpZmRlZiBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUgorZXh0ZXJuIHN0cnVj
dCBhY3BpX3BhZF9vcHMgYWNwaV9wYWRfb3BzOworI2VuZGlmCisKIC8qLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEb2NrIFN0YXRpb24KICAgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gKi8KLS0gCjEuNy4xCgo=

--_002_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350AD088SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Feb 23 13:33:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:33:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Yn9-0007bk-A8; Thu, 23 Feb 2012 13:33:03 +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 1S0Yn6-0007bS-U6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:33:01 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330003926!61795604!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5MTEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17119 invoked from network); 23 Feb 2012 13:32:07 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 13:32:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 23 Feb 2012 05:32:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="scan'208,223";a="113984375"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 23 Feb 2012 05:32:55 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 21:31:28 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 21:31:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 2/2] RFC: Xen pad logic
Thread-Index: AczyL3DEMCwSvW3aReGRFhHGH2lzkA==
Date: Thu, 23 Feb 2012 13:31:25 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD0A6@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_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: [Xen-devel] [PATCH 2/2] RFC: Xen pad 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 24 Feb 2012 02:18:02 +0800
Subject: [PATCH 2/2] Xen pad logic

This patch implement Xen pad logic, and when getting pad device
notification, it hypercalls to Xen hypervisor for core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/xen/enlighten.c         |    2 +
 arch/x86/xen/xen-ops.h           |    1 +
 drivers/xen/Makefile             |    1 +
 drivers/xen/xen_acpi_pad.c       |  190 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   14 +++
 5 files changed, 208 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..3cce71f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1133,6 +1133,8 @@ asmlinkage void __init xen_start_kernel(void)
=20
 	xen_init_time_ops();
=20
+	xen_init_pad_ops();
+
 	/*
 	 * Set up some pagetable state before starting to set any ptes.
 	 */
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index b095739..7eee651 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -54,6 +54,7 @@ void xen_teardown_timer(int cpu);
 cycle_t xen_clocksource_read(void);
 void xen_setup_cpu_clockevents(void);
 void __init xen_init_time_ops(void);
+void __init xen_init_pad_ops(void);
 void __init xen_hvm_init_time_ops(void);
=20
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..c0268c9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
=20
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..4a1f2f7
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,190 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong <jinsong.liu@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 f=
or
+ * more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
+#include <asm/xen/hypercall.h>
+
+static DEFINE_MUTEX(xen_cpu_lock);
+
+static int xen_acpi_pad_idle_cpus(int *num_cpus)
+{
+	int ret;
+
+	struct xen_platform_op op =3D {
+		.cmd =3D XENPF_core_parking,
+		.interface_version =3D XENPF_INTERFACE_VERSION,
+	};
+
+	/* set cpu nums expected to be idled */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D (uint32_t)*num_cpus;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/*
+	 * get cpu nums actually be idled
+	 * cannot get it by using hypercall once (shared with _SET)
+	 * because of the characteristic of Xen continue_hypercall_on_cpu
+	 */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	*num_cpus =3D op.u.core_parking.idle_nums;
+	return 0;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int ret, num_cpus;
+
+	mutex_lock(&xen_cpu_lock);
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	ret =3D xen_acpi_pad_idle_cpus(&num_cpus);
+	if (ret) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device,
+	int type)
+{
+	int num_cpus =3D 0;
+
+	mutex_lock(&xen_cpu_lock);
+	xen_acpi_pad_idle_cpus(&num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+
+	acpi_remove_notify_handler(device->handle,
+		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
+	return 0;
+}
+
+static const struct acpi_device_id xen_pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D xen_pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+		.remove =3D xen_acpi_pad_remove,
+	},
+};
+
+static int __init xen_acpi_pad_init(void)
+{
+	return acpi_bus_register_driver(&xen_acpi_pad_driver);
+}
+
+void __init xen_init_pad_ops(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_pad_ops.init =3D xen_acpi_pad_init;
+#endif
+}
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..56ec72a 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_core_parking      60
+
+#define XEN_CORE_PARKING_SET    1
+#define XEN_CORE_PARKING_GET    2
+struct xenpf_core_parking {
+	/* IN variables */
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,6 +325,7 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="0002-Xen-pad-logic.patch"
Content-Description: 0002-Xen-pad-logic.patch
Content-Disposition: attachment; filename="0002-Xen-pad-logic.patch";
	size=7954; creation-date="Thu, 23 Feb 2012 13:05:12 GMT";
	modification-date="Thu, 23 Feb 2012 20:58:38 GMT"
Content-Transfer-Encoding: base64

RnJvbSBiYTlhYmY2ZWU3ZTVmZTA1MTVlMmQ1MWIxNDc0M2M4ZDU0MTYyODVjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNCBGZWIgMjAxMiAwMjoxODowMiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBYZW4gcGFkIGxvZ2ljCgpUaGlzIHBhdGNoIGltcGxlbWVudCBYZW4gcGFkIGxvZ2ljLCBhbmQg
d2hlbiBnZXR0aW5nIHBhZCBkZXZpY2UKbm90aWZpY2F0aW9uLCBpdCBoeXBlcmNhbGxzIHRvIFhl
biBoeXBlcnZpc29yIGZvciBjb3JlIHBhcmtpbmcuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNv
bmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMg
ICAgICAgICB8ICAgIDIgKwogYXJjaC94ODYveGVuL3hlbi1vcHMuaCAgICAgICAgICAgfCAgICAx
ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgIHwgICAgMSArCiBkcml2ZXJzL3hl
bi94ZW5fYWNwaV9wYWQuYyAgICAgICB8ICAxOTAgKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIGluY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAxNCArKysK
IDUgZmlsZXMgY2hhbmdlZCwgMjA4IGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCiBjcmVh
dGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMKCmRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXgg
MTJlYjA3Yi4uM2NjZTcxZiAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisr
KyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMTEzMyw2ICsxMTMzLDggQEAgYXNtbGlu
a2FnZSB2b2lkIF9faW5pdCB4ZW5fc3RhcnRfa2VybmVsKHZvaWQpCiAKIAl4ZW5faW5pdF90aW1l
X29wcygpOwogCisJeGVuX2luaXRfcGFkX29wcygpOworCiAJLyoKIAkgKiBTZXQgdXAgc29tZSBw
YWdldGFibGUgc3RhdGUgYmVmb3JlIHN0YXJ0aW5nIHRvIHNldCBhbnkgcHRlcy4KIAkgKi8KZGlm
ZiAtLWdpdCBhL2FyY2gveDg2L3hlbi94ZW4tb3BzLmggYi9hcmNoL3g4Ni94ZW4veGVuLW9wcy5o
CmluZGV4IGIwOTU3MzkuLjdlZWU2NTEgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi94ZW4tb3Bz
LmgKKysrIGIvYXJjaC94ODYveGVuL3hlbi1vcHMuaApAQCAtNTQsNiArNTQsNyBAQCB2b2lkIHhl
bl90ZWFyZG93bl90aW1lcihpbnQgY3B1KTsKIGN5Y2xlX3QgeGVuX2Nsb2Nrc291cmNlX3JlYWQo
dm9pZCk7CiB2b2lkIHhlbl9zZXR1cF9jcHVfY2xvY2tldmVudHModm9pZCk7CiB2b2lkIF9faW5p
dCB4ZW5faW5pdF90aW1lX29wcyh2b2lkKTsKK3ZvaWQgX19pbml0IHhlbl9pbml0X3BhZF9vcHMo
dm9pZCk7CiB2b2lkIF9faW5pdCB4ZW5faHZtX2luaXRfdGltZV9vcHModm9pZCk7CiAKIGlycXJl
dHVybl90IHhlbl9kZWJ1Z19pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKTsKZGlmZiAt
LWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXgg
YWEzMTMzNy4uYzAyNjhjOSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIv
ZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIwLDcgQEAgb2JqLSQoQ09ORklHX1NXSU9U
TEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09ORklHX1hFTl9ET00wKQkJCSs9IHBj
aS5vCiBvYmotJChDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EKQkrPSB4ZW4tcGNpYmFjay8KIG9i
ai0kKENPTkZJR19YRU5fUFJJVkNNRCkJCSs9IHhlbi1wcml2Y21kLm8KK29iai0kKENPTkZJR19Y
RU5fRE9NMCkJCQkrPSB4ZW5fYWNwaV9wYWQubwogCiB4ZW4tZXZ0Y2huLXkJCQkJOj0gZXZ0Y2hu
Lm8KIHhlbi1nbnRkZXYteQkJCQk6PSBnbnRkZXYubwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4v
eGVuX2FjcGlfcGFkLmMgYi9kcml2ZXJzL3hlbi94ZW5fYWNwaV9wYWQuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi40YTFmMmY3Ci0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4veGVuX2FjcGlfcGFkLmMKQEAgLTAsMCArMSwxOTAgQEAKKy8qCisgKiB4ZW5fYWNwaV9w
YWQuYyAtIFhlbiBwYWQgaW50ZXJmYWNlCisgKgorICogQ29weXJpZ2h0IChjKSAyMDEyLCBJbnRl
bCBDb3Jwb3JhdGlvbi4KKyAqICAgIEF1dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBp
bnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4g
cmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQKKyAqIHVuZGVyIHRoZSB0ZXJtcyBhbmQg
Y29uZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsCisgKiB2ZXJzaW9u
IDIsIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSBpdCB3aWxsIGJlIHVzZWZ1
bCwgYnV0IFdJVEhPVVQKKyAqIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVk
IHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBvcgorICogRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvcgorICog
bW9yZSBkZXRhaWxzLgorICovCisKKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNpbmNsdWRl
IDxsaW51eC90eXBlcy5oPgorI2luY2x1ZGUgPGFjcGkvYWNwaV9idXMuaD4KKyNpbmNsdWRlIDxh
Y3BpL2FjcGlfZHJpdmVycy5oPgorCisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKwor
c3RhdGljIERFRklORV9NVVRFWCh4ZW5fY3B1X2xvY2spOworCitzdGF0aWMgaW50IHhlbl9hY3Bp
X3BhZF9pZGxlX2NwdXMoaW50ICpudW1fY3B1cykKK3sKKwlpbnQgcmV0OworCisJc3RydWN0IHhl
bl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZCA9IFhFTlBGX2NvcmVfcGFya2luZywKKwkJLmlu
dGVyZmFjZV92ZXJzaW9uID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJfTsKKworCS8qIHNl
dCBjcHUgbnVtcyBleHBlY3RlZCB0byBiZSBpZGxlZCAqLworCW9wLnUuY29yZV9wYXJraW5nLnR5
cGUgPSBYRU5fQ09SRV9QQVJLSU5HX1NFVDsKKwlvcC51LmNvcmVfcGFya2luZy5pZGxlX251bXMg
PSAodWludDMyX3QpKm51bV9jcHVzOworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwor
CWlmIChyZXQpCisJCXJldHVybiByZXQ7CisKKwkvKgorCSAqIGdldCBjcHUgbnVtcyBhY3R1YWxs
eSBiZSBpZGxlZAorCSAqIGNhbm5vdCBnZXQgaXQgYnkgdXNpbmcgaHlwZXJjYWxsIG9uY2UgKHNo
YXJlZCB3aXRoIF9TRVQpCisJICogYmVjYXVzZSBvZiB0aGUgY2hhcmFjdGVyaXN0aWMgb2YgWGVu
IGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9jcHUKKwkgKi8KKwlvcC51LmNvcmVfcGFya2luZy50eXBl
ID0gWEVOX0NPUkVfUEFSS0lOR19HRVQ7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7
CisJaWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCSpudW1fY3B1cyA9IG9wLnUuY29yZV9wYXJr
aW5nLmlkbGVfbnVtczsKKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIFF1ZXJ5IGZpcm13YXJlIGhv
dyBtYW55IENQVXMgc2hvdWxkIGJlIGlkbGUKKyAqIHJldHVybiAtMSBvbiBmYWlsdXJlCisgKi8K
K3N0YXRpYyBpbnQgeGVuX2FjcGlfcGFkX3B1cihhY3BpX2hhbmRsZSBoYW5kbGUpCit7CisJc3Ry
dWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHtBQ1BJX0FMTE9DQVRFX0JVRkZFUiwgTlVMTH07CisJ
dW5pb24gYWNwaV9vYmplY3QgKnBhY2thZ2U7CisJaW50IG51bSA9IC0xOworCisJaWYgKEFDUElf
RkFJTFVSRShhY3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfUFVSIiwgTlVMTCwgJmJ1ZmZl
cikpKQorCQlyZXR1cm4gbnVtOworCisJaWYgKCFidWZmZXIubGVuZ3RoIHx8ICFidWZmZXIucG9p
bnRlcikKKwkJcmV0dXJuIG51bTsKKworCXBhY2thZ2UgPSBidWZmZXIucG9pbnRlcjsKKworCWlm
IChwYWNrYWdlLT50eXBlID09IEFDUElfVFlQRV9QQUNLQUdFICYmCisJCXBhY2thZ2UtPnBhY2th
Z2UuY291bnQgPT0gMiAmJgorCQlwYWNrYWdlLT5wYWNrYWdlLmVsZW1lbnRzWzBdLmludGVnZXIu
dmFsdWUgPT0gMSkgLyogcmV2IDEgKi8KKworCQludW0gPSBwYWNrYWdlLT5wYWNrYWdlLmVsZW1l
bnRzWzFdLmludGVnZXIudmFsdWU7CisKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJcmV0dXJu
IG51bTsKK30KKworLyogTm90aWZ5IGZpcm13YXJlIGhvdyBtYW55IENQVXMgYXJlIGlkbGUgKi8K
K3N0YXRpYyB2b2lkIHhlbl9hY3BpX3BhZF9vc3QoYWNwaV9oYW5kbGUgaGFuZGxlLCBpbnQgc3Rh
dCwKKwl1aW50MzJfdCBpZGxlX2NwdXMpCit7CisJdW5pb24gYWNwaV9vYmplY3QgcGFyYW1zWzNd
ID0geworCQl7LnR5cGUgPSBBQ1BJX1RZUEVfSU5URUdFUix9LAorCQl7LnR5cGUgPSBBQ1BJX1RZ
UEVfSU5URUdFUix9LAorCQl7LnR5cGUgPSBBQ1BJX1RZUEVfQlVGRkVSLH0sCisJfTsKKwlzdHJ1
Y3QgYWNwaV9vYmplY3RfbGlzdCBhcmdfbGlzdCA9IHszLCBwYXJhbXN9OworCisJcGFyYW1zWzBd
LmludGVnZXIudmFsdWUgPSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05PVElGWTsKKwlwYXJh
bXNbMV0uaW50ZWdlci52YWx1ZSA9ICBzdGF0OworCXBhcmFtc1syXS5idWZmZXIubGVuZ3RoID0g
NDsKKwlwYXJhbXNbMl0uYnVmZmVyLnBvaW50ZXIgPSAodm9pZCAqKSZpZGxlX2NwdXM7CisJYWNw
aV9ldmFsdWF0ZV9vYmplY3QoaGFuZGxlLCAiX09TVCIsICZhcmdfbGlzdCwgTlVMTCk7Cit9CisK
K3N0YXRpYyB2b2lkIHhlbl9hY3BpX3BhZF9oYW5kbGVfbm90aWZ5KGFjcGlfaGFuZGxlIGhhbmRs
ZSkKK3sKKwlpbnQgcmV0LCBudW1fY3B1czsKKworCW11dGV4X2xvY2soJnhlbl9jcHVfbG9jayk7
CisJbnVtX2NwdXMgPSB4ZW5fYWNwaV9wYWRfcHVyKGhhbmRsZSk7CisJaWYgKG51bV9jcHVzIDwg
MCkgeworCQltdXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7CisJCXJldHVybjsKKwl9CisKKwly
ZXQgPSB4ZW5fYWNwaV9wYWRfaWRsZV9jcHVzKCZudW1fY3B1cyk7CisJaWYgKHJldCkgeworCQlt
dXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7CisJCXJldHVybjsKKwl9CisKKwl4ZW5fYWNwaV9w
YWRfb3N0KGhhbmRsZSwgMCwgbnVtX2NwdXMpOworCW11dGV4X3VubG9jaygmeGVuX2NwdV9sb2Nr
KTsKK30KKworc3RhdGljIHZvaWQgeGVuX2FjcGlfcGFkX25vdGlmeShhY3BpX2hhbmRsZSBoYW5k
bGUsIHUzMiBldmVudCwKKwl2b2lkICpkYXRhKQoreworCXN3aXRjaCAoZXZlbnQpIHsKKwljYXNl
IEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZOgorCQl4ZW5fYWNwaV9wYWRfaGFuZGxl
X25vdGlmeShoYW5kbGUpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlwcmludGsoS0VSTl9XQVJO
SU5HICJVbnN1cHBvcnRlZCBldmVudCBbMHgleF1cbiIsIGV2ZW50KTsKKwkJYnJlYWs7CisJfQor
fQorCitzdGF0aWMgaW50IHhlbl9hY3BpX3BhZF9hZGQoc3RydWN0IGFjcGlfZGV2aWNlICpkZXZp
Y2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzOworCisJc3RyY3B5KGFjcGlfZGV2aWNlX25hbWUo
ZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9ERVZJQ0VfTkFNRSk7CisJc3RyY3B5
KGFjcGlfZGV2aWNlX2NsYXNzKGRldmljZSksIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfQ0xB
U1MpOworCisJc3RhdHVzID0gYWNwaV9pbnN0YWxsX25vdGlmeV9oYW5kbGVyKGRldmljZS0+aGFu
ZGxlLAorCQkgQUNQSV9ERVZJQ0VfTk9USUZZLCB4ZW5fYWNwaV9wYWRfbm90aWZ5LCBkZXZpY2Up
OworCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJcmV0dXJuIC1FTk9ERVY7CisKKwlyZXR1
cm4gMDsKK30KKworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRfcmVtb3ZlKHN0cnVjdCBhY3BpX2Rl
dmljZSAqZGV2aWNlLAorCWludCB0eXBlKQoreworCWludCBudW1fY3B1cyA9IDA7CisKKwltdXRl
eF9sb2NrKCZ4ZW5fY3B1X2xvY2spOworCXhlbl9hY3BpX3BhZF9pZGxlX2NwdXMoJm51bV9jcHVz
KTsKKwltdXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7CisKKwlhY3BpX3JlbW92ZV9ub3RpZnlf
aGFuZGxlcihkZXZpY2UtPmhhbmRsZSwKKwkJQUNQSV9ERVZJQ0VfTk9USUZZLCB4ZW5fYWNwaV9w
YWRfbm90aWZ5KTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGNvbnN0IHN0cnVjdCBhY3BpX2Rl
dmljZV9pZCB4ZW5fcGFkX2RldmljZV9pZHNbXSA9IHsKKwl7IkFDUEkwMDBDIiwgMH0sCisJeyIi
LCAwfSwKK307CisKK3N0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgeGVuX2FjcGlfcGFkX2RyaXZl
ciA9IHsKKwkubmFtZSA9ICJwcm9jZXNzb3JfYWdncmVnYXRvciIsCisJLmNsYXNzID0gQUNQSV9Q
Uk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUywKKwkuaWRzID0geGVuX3BhZF9kZXZpY2VfaWRzLAor
CS5vcHMgPSB7CisJCS5hZGQgPSB4ZW5fYWNwaV9wYWRfYWRkLAorCQkucmVtb3ZlID0geGVuX2Fj
cGlfcGFkX3JlbW92ZSwKKwl9LAorfTsKKworc3RhdGljIGludCBfX2luaXQgeGVuX2FjcGlfcGFk
X2luaXQodm9pZCkKK3sKKwlyZXR1cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZ4ZW5fYWNw
aV9wYWRfZHJpdmVyKTsKK30KKwordm9pZCBfX2luaXQgeGVuX2luaXRfcGFkX29wcyh2b2lkKQor
eworI2lmZGVmIENPTkZJR19BQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SCisJYWNwaV9wYWRfb3Bz
LmluaXQgPSB4ZW5fYWNwaV9wYWRfaW5pdDsKKyNlbmRpZgorfQpkaWZmIC0tZ2l0IGEvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaAppbmRleCBjMTY4NDY4Li41NmVjNzJhIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApA
QCAtMjk3LDYgKzI5NywxOSBAQCBzdHJ1Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gewog
fTsKIERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
KTsKIAorI2RlZmluZSBYRU5QRl9jb3JlX3BhcmtpbmcgICAgICA2MAorCisjZGVmaW5lIFhFTl9D
T1JFX1BBUktJTkdfU0VUICAgIDEKKyNkZWZpbmUgWEVOX0NPUkVfUEFSS0lOR19HRVQgICAgMgor
c3RydWN0IHhlbnBmX2NvcmVfcGFya2luZyB7CisJLyogSU4gdmFyaWFibGVzICovCisJdWludDMy
X3QgdHlwZTsKKwkvKiBJTiB2YXJpYWJsZXM6ICBzZXQgY3B1IG51bXMgZXhwZWN0ZWQgdG8gYmUg
aWRsZWQgKi8KKwkvKiBPVVQgdmFyaWFibGVzOiBnZXQgY3B1IG51bXMgYWN0dWFsbHkgYmUgaWRs
ZWQgKi8KKwl1aW50MzJfdCBpZGxlX251bXM7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoeGVucGZfY29yZV9wYXJraW5nKTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWlu
dDMyX3QgY21kOwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZB
Q0VfVkVSU0lPTiAqLwpAQCAtMzEyLDYgKzMyNSw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Ag
ewogCQlzdHJ1Y3QgeGVucGZfY2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVj
dCB4ZW5wZl9nZXRpZGxldGltZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3Nl
dF9wcm9jZXNzb3JfcG1pbmZvIHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9jb3JlX3Bhcmtp
bmcgICAgICBjb3JlX3Bhcmtpbmc7CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBw
YWRbMTI4XTsKIAl9IHU7CiB9OwotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Feb 23 13:33:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:33:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Yn9-0007bk-A8; Thu, 23 Feb 2012 13:33:03 +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 1S0Yn6-0007bS-U6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:33:01 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330003926!61795604!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5MTEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17119 invoked from network); 23 Feb 2012 13:32:07 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 13:32:07 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 23 Feb 2012 05:32:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; 
	d="scan'208,223";a="113984375"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 23 Feb 2012 05:32:55 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 23 Feb 2012 21:31:28 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Thu, 23 Feb 2012 21:31:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 2/2] RFC: Xen pad logic
Thread-Index: AczyL3DEMCwSvW3aReGRFhHGH2lzkA==
Date: Thu, 23 Feb 2012 13:31:25 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD0A6@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_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <JBeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: [Xen-devel] [PATCH 2/2] RFC: Xen pad 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 24 Feb 2012 02:18:02 +0800
Subject: [PATCH 2/2] Xen pad logic

This patch implement Xen pad logic, and when getting pad device
notification, it hypercalls to Xen hypervisor for core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/xen/enlighten.c         |    2 +
 arch/x86/xen/xen-ops.h           |    1 +
 drivers/xen/Makefile             |    1 +
 drivers/xen/xen_acpi_pad.c       |  190 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   14 +++
 5 files changed, 208 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..3cce71f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1133,6 +1133,8 @@ asmlinkage void __init xen_start_kernel(void)
=20
 	xen_init_time_ops();
=20
+	xen_init_pad_ops();
+
 	/*
 	 * Set up some pagetable state before starting to set any ptes.
 	 */
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index b095739..7eee651 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -54,6 +54,7 @@ void xen_teardown_timer(int cpu);
 cycle_t xen_clocksource_read(void);
 void xen_setup_cpu_clockevents(void);
 void __init xen_init_time_ops(void);
+void __init xen_init_pad_ops(void);
 void __init xen_hvm_init_time_ops(void);
=20
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..c0268c9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
=20
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..4a1f2f7
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,190 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong <jinsong.liu@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 f=
or
+ * more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
+#include <asm/xen/hypercall.h>
+
+static DEFINE_MUTEX(xen_cpu_lock);
+
+static int xen_acpi_pad_idle_cpus(int *num_cpus)
+{
+	int ret;
+
+	struct xen_platform_op op =3D {
+		.cmd =3D XENPF_core_parking,
+		.interface_version =3D XENPF_INTERFACE_VERSION,
+	};
+
+	/* set cpu nums expected to be idled */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D (uint32_t)*num_cpus;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/*
+	 * get cpu nums actually be idled
+	 * cannot get it by using hypercall once (shared with _SET)
+	 * because of the characteristic of Xen continue_hypercall_on_cpu
+	 */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	*num_cpus =3D op.u.core_parking.idle_nums;
+	return 0;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int ret, num_cpus;
+
+	mutex_lock(&xen_cpu_lock);
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	ret =3D xen_acpi_pad_idle_cpus(&num_cpus);
+	if (ret) {
+		mutex_unlock(&xen_cpu_lock);
+		return;
+	}
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		printk(KERN_WARNING "Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device,
+	int type)
+{
+	int num_cpus =3D 0;
+
+	mutex_lock(&xen_cpu_lock);
+	xen_acpi_pad_idle_cpus(&num_cpus);
+	mutex_unlock(&xen_cpu_lock);
+
+	acpi_remove_notify_handler(device->handle,
+		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
+	return 0;
+}
+
+static const struct acpi_device_id xen_pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D xen_pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+		.remove =3D xen_acpi_pad_remove,
+	},
+};
+
+static int __init xen_acpi_pad_init(void)
+{
+	return acpi_bus_register_driver(&xen_acpi_pad_driver);
+}
+
+void __init xen_init_pad_ops(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_pad_ops.init =3D xen_acpi_pad_init;
+#endif
+}
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index c168468..56ec72a 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
=20
+#define XENPF_core_parking      60
+
+#define XEN_CORE_PARKING_SET    1
+#define XEN_CORE_PARKING_GET    2
+struct xenpf_core_parking {
+	/* IN variables */
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -312,6 +325,7 @@ struct xen_platform_op {
 		struct xenpf_change_freq       change_freq;
 		struct xenpf_getidletime       getidletime;
 		struct xenpf_set_processor_pminfo set_pminfo;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="0002-Xen-pad-logic.patch"
Content-Description: 0002-Xen-pad-logic.patch
Content-Disposition: attachment; filename="0002-Xen-pad-logic.patch";
	size=7954; creation-date="Thu, 23 Feb 2012 13:05:12 GMT";
	modification-date="Thu, 23 Feb 2012 20:58:38 GMT"
Content-Transfer-Encoding: base64

RnJvbSBiYTlhYmY2ZWU3ZTVmZTA1MTVlMmQ1MWIxNDc0M2M4ZDU0MTYyODVjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNCBGZWIgMjAxMiAwMjoxODowMiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBYZW4gcGFkIGxvZ2ljCgpUaGlzIHBhdGNoIGltcGxlbWVudCBYZW4gcGFkIGxvZ2ljLCBhbmQg
d2hlbiBnZXR0aW5nIHBhZCBkZXZpY2UKbm90aWZpY2F0aW9uLCBpdCBoeXBlcmNhbGxzIHRvIFhl
biBoeXBlcnZpc29yIGZvciBjb3JlIHBhcmtpbmcuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNv
bmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMg
ICAgICAgICB8ICAgIDIgKwogYXJjaC94ODYveGVuL3hlbi1vcHMuaCAgICAgICAgICAgfCAgICAx
ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgIHwgICAgMSArCiBkcml2ZXJzL3hl
bi94ZW5fYWNwaV9wYWQuYyAgICAgICB8ICAxOTAgKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysKIGluY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9ybS5oIHwgICAxNCArKysK
IDUgZmlsZXMgY2hhbmdlZCwgMjA4IGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCiBjcmVh
dGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMKCmRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXgg
MTJlYjA3Yi4uM2NjZTcxZiAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisr
KyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMTEzMyw2ICsxMTMzLDggQEAgYXNtbGlu
a2FnZSB2b2lkIF9faW5pdCB4ZW5fc3RhcnRfa2VybmVsKHZvaWQpCiAKIAl4ZW5faW5pdF90aW1l
X29wcygpOwogCisJeGVuX2luaXRfcGFkX29wcygpOworCiAJLyoKIAkgKiBTZXQgdXAgc29tZSBw
YWdldGFibGUgc3RhdGUgYmVmb3JlIHN0YXJ0aW5nIHRvIHNldCBhbnkgcHRlcy4KIAkgKi8KZGlm
ZiAtLWdpdCBhL2FyY2gveDg2L3hlbi94ZW4tb3BzLmggYi9hcmNoL3g4Ni94ZW4veGVuLW9wcy5o
CmluZGV4IGIwOTU3MzkuLjdlZWU2NTEgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi94ZW4tb3Bz
LmgKKysrIGIvYXJjaC94ODYveGVuL3hlbi1vcHMuaApAQCAtNTQsNiArNTQsNyBAQCB2b2lkIHhl
bl90ZWFyZG93bl90aW1lcihpbnQgY3B1KTsKIGN5Y2xlX3QgeGVuX2Nsb2Nrc291cmNlX3JlYWQo
dm9pZCk7CiB2b2lkIHhlbl9zZXR1cF9jcHVfY2xvY2tldmVudHModm9pZCk7CiB2b2lkIF9faW5p
dCB4ZW5faW5pdF90aW1lX29wcyh2b2lkKTsKK3ZvaWQgX19pbml0IHhlbl9pbml0X3BhZF9vcHMo
dm9pZCk7CiB2b2lkIF9faW5pdCB4ZW5faHZtX2luaXRfdGltZV9vcHModm9pZCk7CiAKIGlycXJl
dHVybl90IHhlbl9kZWJ1Z19pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKTsKZGlmZiAt
LWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXgg
YWEzMTMzNy4uYzAyNjhjOSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vTWFrZWZpbGUKKysrIGIv
ZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTIwLDYgKzIwLDcgQEAgb2JqLSQoQ09ORklHX1NXSU9U
TEJfWEVOKQkJKz0gc3dpb3RsYi14ZW4ubwogb2JqLSQoQ09ORklHX1hFTl9ET00wKQkJCSs9IHBj
aS5vCiBvYmotJChDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EKQkrPSB4ZW4tcGNpYmFjay8KIG9i
ai0kKENPTkZJR19YRU5fUFJJVkNNRCkJCSs9IHhlbi1wcml2Y21kLm8KK29iai0kKENPTkZJR19Y
RU5fRE9NMCkJCQkrPSB4ZW5fYWNwaV9wYWQubwogCiB4ZW4tZXZ0Y2huLXkJCQkJOj0gZXZ0Y2hu
Lm8KIHhlbi1nbnRkZXYteQkJCQk6PSBnbnRkZXYubwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4v
eGVuX2FjcGlfcGFkLmMgYi9kcml2ZXJzL3hlbi94ZW5fYWNwaV9wYWQuYwpuZXcgZmlsZSBtb2Rl
IDEwMDY0NAppbmRleCAwMDAwMDAwLi40YTFmMmY3Ci0tLSAvZGV2L251bGwKKysrIGIvZHJpdmVy
cy94ZW4veGVuX2FjcGlfcGFkLmMKQEAgLTAsMCArMSwxOTAgQEAKKy8qCisgKiB4ZW5fYWNwaV9w
YWQuYyAtIFhlbiBwYWQgaW50ZXJmYWNlCisgKgorICogQ29weXJpZ2h0IChjKSAyMDEyLCBJbnRl
bCBDb3Jwb3JhdGlvbi4KKyAqICAgIEF1dGhvcjogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBp
bnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4g
cmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkgaXQKKyAqIHVuZGVyIHRoZSB0ZXJtcyBhbmQg
Y29uZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsCisgKiB2ZXJzaW9u
IDIsIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgorICoKKyAq
IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSBpdCB3aWxsIGJlIHVzZWZ1
bCwgYnV0IFdJVEhPVVQKKyAqIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVk
IHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBvcgorICogRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvcgorICog
bW9yZSBkZXRhaWxzLgorICovCisKKyNpbmNsdWRlIDxsaW51eC9rZXJuZWwuaD4KKyNpbmNsdWRl
IDxsaW51eC90eXBlcy5oPgorI2luY2x1ZGUgPGFjcGkvYWNwaV9idXMuaD4KKyNpbmNsdWRlIDxh
Y3BpL2FjcGlfZHJpdmVycy5oPgorCisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKwor
c3RhdGljIERFRklORV9NVVRFWCh4ZW5fY3B1X2xvY2spOworCitzdGF0aWMgaW50IHhlbl9hY3Bp
X3BhZF9pZGxlX2NwdXMoaW50ICpudW1fY3B1cykKK3sKKwlpbnQgcmV0OworCisJc3RydWN0IHhl
bl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZCA9IFhFTlBGX2NvcmVfcGFya2luZywKKwkJLmlu
dGVyZmFjZV92ZXJzaW9uID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJfTsKKworCS8qIHNl
dCBjcHUgbnVtcyBleHBlY3RlZCB0byBiZSBpZGxlZCAqLworCW9wLnUuY29yZV9wYXJraW5nLnR5
cGUgPSBYRU5fQ09SRV9QQVJLSU5HX1NFVDsKKwlvcC51LmNvcmVfcGFya2luZy5pZGxlX251bXMg
PSAodWludDMyX3QpKm51bV9jcHVzOworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOwor
CWlmIChyZXQpCisJCXJldHVybiByZXQ7CisKKwkvKgorCSAqIGdldCBjcHUgbnVtcyBhY3R1YWxs
eSBiZSBpZGxlZAorCSAqIGNhbm5vdCBnZXQgaXQgYnkgdXNpbmcgaHlwZXJjYWxsIG9uY2UgKHNo
YXJlZCB3aXRoIF9TRVQpCisJICogYmVjYXVzZSBvZiB0aGUgY2hhcmFjdGVyaXN0aWMgb2YgWGVu
IGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9jcHUKKwkgKi8KKwlvcC51LmNvcmVfcGFya2luZy50eXBl
ID0gWEVOX0NPUkVfUEFSS0lOR19HRVQ7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20wX29wKCZvcCk7
CisJaWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCSpudW1fY3B1cyA9IG9wLnUuY29yZV9wYXJr
aW5nLmlkbGVfbnVtczsKKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIFF1ZXJ5IGZpcm13YXJlIGhv
dyBtYW55IENQVXMgc2hvdWxkIGJlIGlkbGUKKyAqIHJldHVybiAtMSBvbiBmYWlsdXJlCisgKi8K
K3N0YXRpYyBpbnQgeGVuX2FjcGlfcGFkX3B1cihhY3BpX2hhbmRsZSBoYW5kbGUpCit7CisJc3Ry
dWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHtBQ1BJX0FMTE9DQVRFX0JVRkZFUiwgTlVMTH07CisJ
dW5pb24gYWNwaV9vYmplY3QgKnBhY2thZ2U7CisJaW50IG51bSA9IC0xOworCisJaWYgKEFDUElf
RkFJTFVSRShhY3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfUFVSIiwgTlVMTCwgJmJ1ZmZl
cikpKQorCQlyZXR1cm4gbnVtOworCisJaWYgKCFidWZmZXIubGVuZ3RoIHx8ICFidWZmZXIucG9p
bnRlcikKKwkJcmV0dXJuIG51bTsKKworCXBhY2thZ2UgPSBidWZmZXIucG9pbnRlcjsKKworCWlm
IChwYWNrYWdlLT50eXBlID09IEFDUElfVFlQRV9QQUNLQUdFICYmCisJCXBhY2thZ2UtPnBhY2th
Z2UuY291bnQgPT0gMiAmJgorCQlwYWNrYWdlLT5wYWNrYWdlLmVsZW1lbnRzWzBdLmludGVnZXIu
dmFsdWUgPT0gMSkgLyogcmV2IDEgKi8KKworCQludW0gPSBwYWNrYWdlLT5wYWNrYWdlLmVsZW1l
bnRzWzFdLmludGVnZXIudmFsdWU7CisKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJcmV0dXJu
IG51bTsKK30KKworLyogTm90aWZ5IGZpcm13YXJlIGhvdyBtYW55IENQVXMgYXJlIGlkbGUgKi8K
K3N0YXRpYyB2b2lkIHhlbl9hY3BpX3BhZF9vc3QoYWNwaV9oYW5kbGUgaGFuZGxlLCBpbnQgc3Rh
dCwKKwl1aW50MzJfdCBpZGxlX2NwdXMpCit7CisJdW5pb24gYWNwaV9vYmplY3QgcGFyYW1zWzNd
ID0geworCQl7LnR5cGUgPSBBQ1BJX1RZUEVfSU5URUdFUix9LAorCQl7LnR5cGUgPSBBQ1BJX1RZ
UEVfSU5URUdFUix9LAorCQl7LnR5cGUgPSBBQ1BJX1RZUEVfQlVGRkVSLH0sCisJfTsKKwlzdHJ1
Y3QgYWNwaV9vYmplY3RfbGlzdCBhcmdfbGlzdCA9IHszLCBwYXJhbXN9OworCisJcGFyYW1zWzBd
LmludGVnZXIudmFsdWUgPSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05PVElGWTsKKwlwYXJh
bXNbMV0uaW50ZWdlci52YWx1ZSA9ICBzdGF0OworCXBhcmFtc1syXS5idWZmZXIubGVuZ3RoID0g
NDsKKwlwYXJhbXNbMl0uYnVmZmVyLnBvaW50ZXIgPSAodm9pZCAqKSZpZGxlX2NwdXM7CisJYWNw
aV9ldmFsdWF0ZV9vYmplY3QoaGFuZGxlLCAiX09TVCIsICZhcmdfbGlzdCwgTlVMTCk7Cit9CisK
K3N0YXRpYyB2b2lkIHhlbl9hY3BpX3BhZF9oYW5kbGVfbm90aWZ5KGFjcGlfaGFuZGxlIGhhbmRs
ZSkKK3sKKwlpbnQgcmV0LCBudW1fY3B1czsKKworCW11dGV4X2xvY2soJnhlbl9jcHVfbG9jayk7
CisJbnVtX2NwdXMgPSB4ZW5fYWNwaV9wYWRfcHVyKGhhbmRsZSk7CisJaWYgKG51bV9jcHVzIDwg
MCkgeworCQltdXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7CisJCXJldHVybjsKKwl9CisKKwly
ZXQgPSB4ZW5fYWNwaV9wYWRfaWRsZV9jcHVzKCZudW1fY3B1cyk7CisJaWYgKHJldCkgeworCQlt
dXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7CisJCXJldHVybjsKKwl9CisKKwl4ZW5fYWNwaV9w
YWRfb3N0KGhhbmRsZSwgMCwgbnVtX2NwdXMpOworCW11dGV4X3VubG9jaygmeGVuX2NwdV9sb2Nr
KTsKK30KKworc3RhdGljIHZvaWQgeGVuX2FjcGlfcGFkX25vdGlmeShhY3BpX2hhbmRsZSBoYW5k
bGUsIHUzMiBldmVudCwKKwl2b2lkICpkYXRhKQoreworCXN3aXRjaCAoZXZlbnQpIHsKKwljYXNl
IEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZOgorCQl4ZW5fYWNwaV9wYWRfaGFuZGxl
X25vdGlmeShoYW5kbGUpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlwcmludGsoS0VSTl9XQVJO
SU5HICJVbnN1cHBvcnRlZCBldmVudCBbMHgleF1cbiIsIGV2ZW50KTsKKwkJYnJlYWs7CisJfQor
fQorCitzdGF0aWMgaW50IHhlbl9hY3BpX3BhZF9hZGQoc3RydWN0IGFjcGlfZGV2aWNlICpkZXZp
Y2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzOworCisJc3RyY3B5KGFjcGlfZGV2aWNlX25hbWUo
ZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9ERVZJQ0VfTkFNRSk7CisJc3RyY3B5
KGFjcGlfZGV2aWNlX2NsYXNzKGRldmljZSksIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfQ0xB
U1MpOworCisJc3RhdHVzID0gYWNwaV9pbnN0YWxsX25vdGlmeV9oYW5kbGVyKGRldmljZS0+aGFu
ZGxlLAorCQkgQUNQSV9ERVZJQ0VfTk9USUZZLCB4ZW5fYWNwaV9wYWRfbm90aWZ5LCBkZXZpY2Up
OworCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJcmV0dXJuIC1FTk9ERVY7CisKKwlyZXR1
cm4gMDsKK30KKworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRfcmVtb3ZlKHN0cnVjdCBhY3BpX2Rl
dmljZSAqZGV2aWNlLAorCWludCB0eXBlKQoreworCWludCBudW1fY3B1cyA9IDA7CisKKwltdXRl
eF9sb2NrKCZ4ZW5fY3B1X2xvY2spOworCXhlbl9hY3BpX3BhZF9pZGxlX2NwdXMoJm51bV9jcHVz
KTsKKwltdXRleF91bmxvY2soJnhlbl9jcHVfbG9jayk7CisKKwlhY3BpX3JlbW92ZV9ub3RpZnlf
aGFuZGxlcihkZXZpY2UtPmhhbmRsZSwKKwkJQUNQSV9ERVZJQ0VfTk9USUZZLCB4ZW5fYWNwaV9w
YWRfbm90aWZ5KTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGNvbnN0IHN0cnVjdCBhY3BpX2Rl
dmljZV9pZCB4ZW5fcGFkX2RldmljZV9pZHNbXSA9IHsKKwl7IkFDUEkwMDBDIiwgMH0sCisJeyIi
LCAwfSwKK307CisKK3N0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgeGVuX2FjcGlfcGFkX2RyaXZl
ciA9IHsKKwkubmFtZSA9ICJwcm9jZXNzb3JfYWdncmVnYXRvciIsCisJLmNsYXNzID0gQUNQSV9Q
Uk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUywKKwkuaWRzID0geGVuX3BhZF9kZXZpY2VfaWRzLAor
CS5vcHMgPSB7CisJCS5hZGQgPSB4ZW5fYWNwaV9wYWRfYWRkLAorCQkucmVtb3ZlID0geGVuX2Fj
cGlfcGFkX3JlbW92ZSwKKwl9LAorfTsKKworc3RhdGljIGludCBfX2luaXQgeGVuX2FjcGlfcGFk
X2luaXQodm9pZCkKK3sKKwlyZXR1cm4gYWNwaV9idXNfcmVnaXN0ZXJfZHJpdmVyKCZ4ZW5fYWNw
aV9wYWRfZHJpdmVyKTsKK30KKwordm9pZCBfX2luaXQgeGVuX2luaXRfcGFkX29wcyh2b2lkKQor
eworI2lmZGVmIENPTkZJR19BQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SCisJYWNwaV9wYWRfb3Bz
LmluaXQgPSB4ZW5fYWNwaV9wYWRfaW5pdDsKKyNlbmRpZgorfQpkaWZmIC0tZ2l0IGEvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv
cm0uaAppbmRleCBjMTY4NDY4Li41NmVjNzJhIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvcGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApA
QCAtMjk3LDYgKzI5NywxOSBAQCBzdHJ1Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWluZm8gewog
fTsKIERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZv
KTsKIAorI2RlZmluZSBYRU5QRl9jb3JlX3BhcmtpbmcgICAgICA2MAorCisjZGVmaW5lIFhFTl9D
T1JFX1BBUktJTkdfU0VUICAgIDEKKyNkZWZpbmUgWEVOX0NPUkVfUEFSS0lOR19HRVQgICAgMgor
c3RydWN0IHhlbnBmX2NvcmVfcGFya2luZyB7CisJLyogSU4gdmFyaWFibGVzICovCisJdWludDMy
X3QgdHlwZTsKKwkvKiBJTiB2YXJpYWJsZXM6ICBzZXQgY3B1IG51bXMgZXhwZWN0ZWQgdG8gYmUg
aWRsZWQgKi8KKwkvKiBPVVQgdmFyaWFibGVzOiBnZXQgY3B1IG51bXMgYWN0dWFsbHkgYmUgaWRs
ZWQgKi8KKwl1aW50MzJfdCBpZGxlX251bXM7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoeGVucGZfY29yZV9wYXJraW5nKTsKKwogc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJdWlu
dDMyX3QgY21kOwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJzaW9uOyAvKiBYRU5QRl9JTlRFUkZB
Q0VfVkVSU0lPTiAqLwpAQCAtMzEyLDYgKzMyNSw3IEBAIHN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Ag
ewogCQlzdHJ1Y3QgeGVucGZfY2hhbmdlX2ZyZXEgICAgICAgY2hhbmdlX2ZyZXE7CiAJCXN0cnVj
dCB4ZW5wZl9nZXRpZGxldGltZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3Nl
dF9wcm9jZXNzb3JfcG1pbmZvIHNldF9wbWluZm87CisJCXN0cnVjdCB4ZW5wZl9jb3JlX3Bhcmtp
bmcgICAgICBjb3JlX3Bhcmtpbmc7CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAgICAgICBw
YWRbMTI4XTsKIAl9IHU7CiB9OwotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350AD0A6SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Feb 23 13:34:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:34:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Yon-0007k9-T5; Thu, 23 Feb 2012 13:34:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0Yon-0007jm-7z
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 13:34:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330004079!14608781!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22204 invoked from network); 23 Feb 2012 13:34:39 -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;
	23 Feb 2012 13:34:39 -0000
Received: by werh12 with SMTP id h12so981883wer.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 05:34:39 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.135.193 as permitted sender) client-ip=10.216.135.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.135.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.135.193])
	by 10.216.135.193 with SMTP id u43mr865785wei.34.1330004079073
	(num_hops = 1); Thu, 23 Feb 2012 05:34:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5iE1dmwyUBYi+nYGV6AbYUzVgJsCImJ61gsEphd9ZkQ=;
	b=eobhi9gMkuJJMasdJ7hK7DyjWaj6DY0KeqbENI2fTnv3N7WvW0hinyWhCPaVaPEJGU
	3AWTRp8n62C2YYV7Sw3SW5IMgzcg1RqzVE8koFz8oK2YksxRVTbJ7eDwX2V9SLnzcF0d
	XbW7H5YQt+bwTKlmscOXbcOq5tw+uiRsT6fOQ=
MIME-Version: 1.0
Received: by 10.216.135.193 with SMTP id u43mr709297wei.34.1330004078976; Thu,
	23 Feb 2012 05:34:38 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 23 Feb 2012 05:34:38 -0800 (PST)
In-Reply-To: <4F454146.1050007@codemonkey.ws>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
Date: Thu, 23 Feb 2012 14:34:38 +0100
X-Google-Sender-Auth: Lcrk-0EGHHeG5SyrbzqI5k6mnVU
Message-ID: <CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIEFudGhvbnkgTGlndW9yaSA8YW50aG9ueUBjb2RlbW9ua2V5LndzPjoKPiBPbiAw
Mi8yMC8yMDEyIDA2OjExIEFNLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+Cj4+IFJlcGxhY2Ug
Y2xvY2tfZ2V0dGltZSB3aXRoIHRpbWVyX2dldHRpbWUsIHNpbmNlIGF0IGxlYXN0IHVuZGVyCj4+
IHVjbGliYyAwLjkuMzMgdGhlIGNsb2NrX2dldHR0aW1lIGZ1bmN0aW9uIGNhbiBiZSB1c2VkIHdp
dGhvdXQgbGlua2luZwo+PiBhZ2FpbnN0IGxpYnJ0IChhbHRob3VnaCB0aGUgbWFudWFsIHBhZ2Ug
c3RhdGVzIHRoZSBvcHBvc2l0ZSkuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25u
ZTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPgo+Cj4gSSBkb24ndCB0aGluayB0aGlzIGlzIGFn
YWluc3QgcWVtdS5naXQuIMKgUGxlYXNlIGRvIG5vdCBzZW5kIHBhdGNoZXMgdG8KPiBxZW11LWRl
dmVsIHRoYXQgYXJlIG5vdCBhZ2FpbnN0IHFlbXUuZ2l0IHdpdGhvdXQgY2xlYXJseSBpbmRpY2F0
aW5nIHRoaXMuCgpTb3JyeSwgdGhpcyBpcyBhZ2FpbnN0IHFlbXUteGVuLXVwc3RyZWFtLCBzaG91
bGQgSSBhZGQgYSB0YWcgdG8gbXkKcGF0Y2hlcyBhbmQgcmVzZW5kIHRoZW0gdG8gcWVtdS1kZXZl
bD8KClRoYW5rcywgUm9nZXIuCgo+IFJlZ2FyZHMsCj4KPiBBbnRob255IExpZ3VvcmkKPgo+Cj4+
IC0tLQo+PiDCoGNvbmZpZ3VyZSB8IMKgIMKgMyArKy0KPj4gwqAxIGZpbGVzIGNoYW5nZWQsIDIg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL2NvbmZpZ3Vy
ZSBiL2NvbmZpZ3VyZQo+PiBpbmRleCA3YmNkNTQ3Li5mYjk5NjMyIDEwMDc1NQo+PiAtLS0gYS9j
b25maWd1cmUKPj4gKysrIGIvY29uZmlndXJlCj4+IEBAIC0yNDM4LDcgKzI0MzgsOCBAQCBmaQo+
PiDCoGNhdD4gwqAkVE1QQzw8RU9GCj4+IMKgI2luY2x1ZGU8c2lnbmFsLmg+Cj4+IMKgI2luY2x1
ZGU8dGltZS5oPgo+PiAtaW50IG1haW4odm9pZCkgeyBjbG9ja2lkX3QgaWQ7IHJldHVybiBjbG9j
a19nZXR0aW1lKGlkLCBOVUxMKTsgfQo+PiAraW50IG1haW4odm9pZCkgeyB0aW1lcl90IHRpZDsg
c3RydWN0IGl0aW1lcnNwZWMgaXQ7IFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1
cm4gdGltZXJfZ2V0dGltZSh0aWQsJml0KTsgfQo+PiDCoEVPRgo+Pgo+PiDCoGlmIGNvbXBpbGVf
cHJvZyAiIiAiIiA7IHRoZW4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:34:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:34:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Yon-0007k9-T5; Thu, 23 Feb 2012 13:34:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0Yon-0007jm-7z
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 13:34:45 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330004079!14608781!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22204 invoked from network); 23 Feb 2012 13:34:39 -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;
	23 Feb 2012 13:34:39 -0000
Received: by werh12 with SMTP id h12so981883wer.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 05:34:39 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.135.193 as permitted sender) client-ip=10.216.135.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.135.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.135.193])
	by 10.216.135.193 with SMTP id u43mr865785wei.34.1330004079073
	(num_hops = 1); Thu, 23 Feb 2012 05:34:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5iE1dmwyUBYi+nYGV6AbYUzVgJsCImJ61gsEphd9ZkQ=;
	b=eobhi9gMkuJJMasdJ7hK7DyjWaj6DY0KeqbENI2fTnv3N7WvW0hinyWhCPaVaPEJGU
	3AWTRp8n62C2YYV7Sw3SW5IMgzcg1RqzVE8koFz8oK2YksxRVTbJ7eDwX2V9SLnzcF0d
	XbW7H5YQt+bwTKlmscOXbcOq5tw+uiRsT6fOQ=
MIME-Version: 1.0
Received: by 10.216.135.193 with SMTP id u43mr709297wei.34.1330004078976; Thu,
	23 Feb 2012 05:34:38 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 23 Feb 2012 05:34:38 -0800 (PST)
In-Reply-To: <4F454146.1050007@codemonkey.ws>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
Date: Thu, 23 Feb 2012 14:34:38 +0100
X-Google-Sender-Auth: Lcrk-0EGHHeG5SyrbzqI5k6mnVU
Message-ID: <CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzIyIEFudGhvbnkgTGlndW9yaSA8YW50aG9ueUBjb2RlbW9ua2V5LndzPjoKPiBPbiAw
Mi8yMC8yMDEyIDA2OjExIEFNLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+Cj4+IFJlcGxhY2Ug
Y2xvY2tfZ2V0dGltZSB3aXRoIHRpbWVyX2dldHRpbWUsIHNpbmNlIGF0IGxlYXN0IHVuZGVyCj4+
IHVjbGliYyAwLjkuMzMgdGhlIGNsb2NrX2dldHR0aW1lIGZ1bmN0aW9uIGNhbiBiZSB1c2VkIHdp
dGhvdXQgbGlua2luZwo+PiBhZ2FpbnN0IGxpYnJ0IChhbHRob3VnaCB0aGUgbWFudWFsIHBhZ2Ug
c3RhdGVzIHRoZSBvcHBvc2l0ZSkuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25u
ZTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPgo+Cj4gSSBkb24ndCB0aGluayB0aGlzIGlzIGFn
YWluc3QgcWVtdS5naXQuIMKgUGxlYXNlIGRvIG5vdCBzZW5kIHBhdGNoZXMgdG8KPiBxZW11LWRl
dmVsIHRoYXQgYXJlIG5vdCBhZ2FpbnN0IHFlbXUuZ2l0IHdpdGhvdXQgY2xlYXJseSBpbmRpY2F0
aW5nIHRoaXMuCgpTb3JyeSwgdGhpcyBpcyBhZ2FpbnN0IHFlbXUteGVuLXVwc3RyZWFtLCBzaG91
bGQgSSBhZGQgYSB0YWcgdG8gbXkKcGF0Y2hlcyBhbmQgcmVzZW5kIHRoZW0gdG8gcWVtdS1kZXZl
bD8KClRoYW5rcywgUm9nZXIuCgo+IFJlZ2FyZHMsCj4KPiBBbnRob255IExpZ3VvcmkKPgo+Cj4+
IC0tLQo+PiDCoGNvbmZpZ3VyZSB8IMKgIMKgMyArKy0KPj4gwqAxIGZpbGVzIGNoYW5nZWQsIDIg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL2NvbmZpZ3Vy
ZSBiL2NvbmZpZ3VyZQo+PiBpbmRleCA3YmNkNTQ3Li5mYjk5NjMyIDEwMDc1NQo+PiAtLS0gYS9j
b25maWd1cmUKPj4gKysrIGIvY29uZmlndXJlCj4+IEBAIC0yNDM4LDcgKzI0MzgsOCBAQCBmaQo+
PiDCoGNhdD4gwqAkVE1QQzw8RU9GCj4+IMKgI2luY2x1ZGU8c2lnbmFsLmg+Cj4+IMKgI2luY2x1
ZGU8dGltZS5oPgo+PiAtaW50IG1haW4odm9pZCkgeyBjbG9ja2lkX3QgaWQ7IHJldHVybiBjbG9j
a19nZXR0aW1lKGlkLCBOVUxMKTsgfQo+PiAraW50IG1haW4odm9pZCkgeyB0aW1lcl90IHRpZDsg
c3RydWN0IGl0aW1lcnNwZWMgaXQ7IFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1
cm4gdGltZXJfZ2V0dGltZSh0aWQsJml0KTsgfQo+PiDCoEVPRgo+Pgo+PiDCoGlmIGNvbXBpbGVf
cHJvZyAiIiAiIiA7IHRoZW4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:35:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YpC-0007mi-AS; Thu, 23 Feb 2012 13:35: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 1S0YpB-0007mX-E0
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:35:09 +0000
Received: from [85.158.139.83:49654] by server-9.bemta-5.messagelabs.com id
	02/2B-30171-C80464F4; Thu, 23 Feb 2012 13:35:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330004107!15786154!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 23 Feb 2012 13:35:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Feb 2012 13:35:08 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330004107; l=606;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=XVU4Onuu4TePAM+JUJ4LL1j+6+s=;
	b=tG2rXNK3JLLuFbqaJ2pIiwJGCnoXOesPn9m0D8Ikv6XgT59Twe6vJKOfDLKRDegA5Mu
	7cSraSuXENuRA9RzGIT/yQQHNTIl+OLS8zGcWlZz7rdhTt3TDlEk3qA8svYdr8CoVB9qG
	O7xRTTyq+v5b76UKBpV8PnSaNfN4Lmgtxl8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by post.strato.de (mrclete mo19) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C05173o1NDSTqO ;
	Thu, 23 Feb 2012 14:35:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 533A018638; Thu, 23 Feb 2012 14:35:00 +0100 (CET)
Date: Thu, 23 Feb 2012 14:35:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223133500.GA15830@aepfle.de>
References: <2d1ac43212fa31cedda2.1329927860@probook.site>
	<1329991097.8557.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329991097.8557.44.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: workaround make 3.82
 dependency flaw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Ian Campbell wrote:

> On Wed, 2012-02-22 at 16:24 +0000, Olaf Hering wrote:
> > After changeset 24767:28300f4562de build sometimes fails when make v3.82
> > as shipped with openSuSE 11.4/12.1 is used.
> 
> Is there a corresponding bug report against make, either upstream or
> SuSE?
> 
> I'd be much happier making an apparently random change as a workaround
> if someone had suggest some reason why it should be the case.

I asked upstream yesterday, but got no response so far.

The weird thing is that even libxenstore.so.$(MAJOR).$(MINOR) as a
prereq is ignored.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 13:35:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 13:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0YpC-0007mi-AS; Thu, 23 Feb 2012 13:35: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 1S0YpB-0007mX-E0
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 13:35:09 +0000
Received: from [85.158.139.83:49654] by server-9.bemta-5.messagelabs.com id
	02/2B-30171-C80464F4; Thu, 23 Feb 2012 13:35:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330004107!15786154!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 23 Feb 2012 13:35:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Feb 2012 13:35:08 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330004107; l=606;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=XVU4Onuu4TePAM+JUJ4LL1j+6+s=;
	b=tG2rXNK3JLLuFbqaJ2pIiwJGCnoXOesPn9m0D8Ikv6XgT59Twe6vJKOfDLKRDegA5Mu
	7cSraSuXENuRA9RzGIT/yQQHNTIl+OLS8zGcWlZz7rdhTt3TDlEk3qA8svYdr8CoVB9qG
	O7xRTTyq+v5b76UKBpV8PnSaNfN4Lmgtxl8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by post.strato.de (mrclete mo19) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C05173o1NDSTqO ;
	Thu, 23 Feb 2012 14:35:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 533A018638; Thu, 23 Feb 2012 14:35:00 +0100 (CET)
Date: Thu, 23 Feb 2012 14:35:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223133500.GA15830@aepfle.de>
References: <2d1ac43212fa31cedda2.1329927860@probook.site>
	<1329991097.8557.44.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329991097.8557.44.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] tools/xenstore: workaround make 3.82
 dependency flaw
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Ian Campbell wrote:

> On Wed, 2012-02-22 at 16:24 +0000, Olaf Hering wrote:
> > After changeset 24767:28300f4562de build sometimes fails when make v3.82
> > as shipped with openSuSE 11.4/12.1 is used.
> 
> Is there a corresponding bug report against make, either upstream or
> SuSE?
> 
> I'd be much happier making an apparently random change as a workaround
> if someone had suggest some reason why it should be the case.

I asked upstream yesterday, but got no response so far.

The weird thing is that even libxenstore.so.$(MAJOR).$(MINOR) as a
prereq is ignored.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:20:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:20:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZW3-0008Ri-Tq; Thu, 23 Feb 2012 14:19: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 1S0ZW2-0008Rd-Fp
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:19:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330006685!62614225!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7793 invoked from network); 23 Feb 2012 14:18:06 -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; 23 Feb 2012 14:18:06 -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 q1NEJFrQ008065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:19:16 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
	q1NEJEaI028948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:19: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
	q1NEJD35016368; Thu, 23 Feb 2012 08:19:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:19:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3A4314171C; Thu, 23 Feb 2012 09:15:51 -0500 (EST)
Date: Thu, 23 Feb 2012 09:15:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223141551.GA23963@phenom.dumpdata.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
	<1329814775.25232.13.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329814775.25232.13.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F464AE4.0084,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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 Tue, Feb 21, 2012 at 08:59:35AM +0000, Ian Campbell wrote:
> On Mon, 2012-02-20 at 18:32 +0000, Konrad Rzeszutek Wilk wrote:
> [...]
> > sh-4.1# xm create /mnt/lab/latest/test.xm 
> > Using config file "/mnt/lab/latest/test.xm".
> > Error: (1, 'Internal error', 'panic: xc_dom_core.c:273:
> > xc_dom_do_gunzip: inflate failed (rc=-3)')
> 
> -3 == ESRCH? Seems unlikely...
> 
> Aha, in this context it is the return value of inflate() and therefore
> it is Z_DATA_ERROR.
> 
> > And only on Intel.. and only if it is a 32-bit dom0. If I do the same
> > test with a 64-bit dom0 I do not see this problem.
> 
> Different decompression libraries in your root filesystems perhaps? Can

Hm, not sure. So I tried the code on the root filesystem and it worked
fine and gave an binary image that was the same as on another machine.

But I wonder if the libxl use the shared library or compile it in. Perhaps
there is some weird library version mismatch. Will double-check.

> you decompress the bzImage by hand? (perhaps using the attached bzeplode
> to extract the compressed data payload)
> 
> Does it work with xl?

Nope.
> 
> > Any thoughts of what it might be or what I should try out? My thought
> > was to swap out the hypervisor (use a Xen 4.0) or unstable and see if
> > I get the same result.
> 
> It is unlikely to be the hypervisor, more likely to be one of the
> userspace components of the toolstack.

I think 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 Thu Feb 23 14:20:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:20:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZW3-0008Ri-Tq; Thu, 23 Feb 2012 14:19: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 1S0ZW2-0008Rd-Fp
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:19:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330006685!62614225!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7793 invoked from network); 23 Feb 2012 14:18:06 -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; 23 Feb 2012 14:18:06 -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 q1NEJFrQ008065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:19:16 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
	q1NEJEaI028948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:19: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
	q1NEJD35016368; Thu, 23 Feb 2012 08:19:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:19:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3A4314171C; Thu, 23 Feb 2012 09:15:51 -0500 (EST)
Date: Thu, 23 Feb 2012 09:15:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223141551.GA23963@phenom.dumpdata.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
	<1329814775.25232.13.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329814775.25232.13.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F464AE4.0084,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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 Tue, Feb 21, 2012 at 08:59:35AM +0000, Ian Campbell wrote:
> On Mon, 2012-02-20 at 18:32 +0000, Konrad Rzeszutek Wilk wrote:
> [...]
> > sh-4.1# xm create /mnt/lab/latest/test.xm 
> > Using config file "/mnt/lab/latest/test.xm".
> > Error: (1, 'Internal error', 'panic: xc_dom_core.c:273:
> > xc_dom_do_gunzip: inflate failed (rc=-3)')
> 
> -3 == ESRCH? Seems unlikely...
> 
> Aha, in this context it is the return value of inflate() and therefore
> it is Z_DATA_ERROR.
> 
> > And only on Intel.. and only if it is a 32-bit dom0. If I do the same
> > test with a 64-bit dom0 I do not see this problem.
> 
> Different decompression libraries in your root filesystems perhaps? Can

Hm, not sure. So I tried the code on the root filesystem and it worked
fine and gave an binary image that was the same as on another machine.

But I wonder if the libxl use the shared library or compile it in. Perhaps
there is some weird library version mismatch. Will double-check.

> you decompress the bzImage by hand? (perhaps using the attached bzeplode
> to extract the compressed data payload)
> 
> Does it work with xl?

Nope.
> 
> > Any thoughts of what it might be or what I should try out? My thought
> > was to swap out the hypervisor (use a Xen 4.0) or unstable and see if
> > I get the same result.
> 
> It is unlikely to be the hypervisor, more likely to be one of the
> userspace components of the toolstack.

I think 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 Thu Feb 23 14:20:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZWc-0008TZ-H8; Thu, 23 Feb 2012 14:20:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ZWa-0008TF-Jy
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 14:20:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330006792!3785754!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5915 invoked from network); 23 Feb 2012 14:19: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; 23 Feb 2012 14:19: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 q1NEJjTh008653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:19: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
	q1NEJicn002373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:19:44 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
	q1NEJh3c028648; Thu, 23 Feb 2012 08:19:43 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:19:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D9DD94171C; Thu, 23 Feb 2012 09:16:22 -0500 (EST)
Date: Thu, 23 Feb 2012 09:16:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120223141622.GB23963@phenom.dumpdata.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
	<4F43B4C40200007800074350@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F43B4C40200007800074350@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F464B03.000D,ss=1,re=0.000,fgs=0
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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 Tue, Feb 21, 2012 at 02:14:12PM +0000, Jan Beulich wrote:
> >>> On 20.02.12 at 19:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > And only on Intel.. and only if it is a 32-bit dom0. If I do the same test 
> > with a 64-bit dom0 I do not see this problem.
> > 
> > Any thoughts of what it might be or what I should try out? My thought
> > was to swap out the hypervisor (use a Xen 4.0) or unstable and see if I get 
> > the same result.
> > But maybe there is something obvious out there?
> 
> Did you check that it's not the kernel image itself on that particular box
> that's corrupted?

The MD5sum looks to same. I think Ian's thoughts of looking at the different
libraries is my next thing to dive into.

Thanks!
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:20:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:20:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZWc-0008TZ-H8; Thu, 23 Feb 2012 14:20:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ZWa-0008TF-Jy
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 14:20:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330006792!3785754!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5915 invoked from network); 23 Feb 2012 14:19: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; 23 Feb 2012 14:19: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 q1NEJjTh008653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:19: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
	q1NEJicn002373
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:19:44 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
	q1NEJh3c028648; Thu, 23 Feb 2012 08:19:43 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:19:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D9DD94171C; Thu, 23 Feb 2012 09:16:22 -0500 (EST)
Date: Thu, 23 Feb 2012 09:16:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120223141622.GB23963@phenom.dumpdata.com>
References: <20120220183207.GA7170@phenom.dumpdata.com>
	<4F43B4C40200007800074350@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F43B4C40200007800074350@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F464B03.000D,ss=1,re=0.000,fgs=0
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] r: (1, 'Internal error',
 'panic: xc_dom_core.c:273: xc_dom_do_gunzip: inflate failed
 (rc=-3)').. only on Intel hardware and only under 32-bit 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 Tue, Feb 21, 2012 at 02:14:12PM +0000, Jan Beulich wrote:
> >>> On 20.02.12 at 19:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > And only on Intel.. and only if it is a 32-bit dom0. If I do the same test 
> > with a 64-bit dom0 I do not see this problem.
> > 
> > Any thoughts of what it might be or what I should try out? My thought
> > was to swap out the hypervisor (use a Xen 4.0) or unstable and see if I get 
> > the same result.
> > But maybe there is something obvious out there?
> 
> Did you check that it's not the kernel image itself on that particular box
> that's corrupted?

The MD5sum looks to same. I think Ian's thoughts of looking at the different
libraries is my next thing to dive into.

Thanks!
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:22:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZYU-0000C3-1I; Thu, 23 Feb 2012 14:21: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 1S0ZYR-0000Br-Sj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:21:56 +0000
Received: from [85.158.139.83:60892] by server-2.bemta-5.messagelabs.com id
	17/D5-20263-38B464F4; Thu, 23 Feb 2012 14:21:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330006913!16348574!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4483 invoked from network); 23 Feb 2012 14:21:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 14:21: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 q1NELno2012507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:21: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
	q1NELnWa004090
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:21:49 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
	q1NELmFV018575; Thu, 23 Feb 2012 08:21:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:21:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B01374171C; Thu, 23 Feb 2012 09:18:27 -0500 (EST)
Date: Thu, 23 Feb 2012 09:18:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120223141827.GC23963@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F460354.7080907@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F464B7E.00F9,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
> Hello,
> 
> I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
> integrated GPU) freezing at resume from S3 sleep... It seems like a
> Xen-related problems, as a similar kernel to what we use in Dom0
> (2.6.38+xenlinux), when run on baremetal shows no signs of problems at
> suspend/resume. Also I cannot find any problems reported on the internet
> with people having problems here.
> 
> Unfortunately the only COM port on ExpressCard I have, presents itself
> as a USB device, and so I cannot really debug this issue via console.
> The /var/log/pm-suspend also doesn't reveal anything useful (after I
> reboot, that is).
> 
> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> to approach debugging it?
> 
> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
> patches, and the i915 for the graphics. (Unfortunately I cannot just
> boot the same Dom0 kernel without Xen, as the GRUB complains about
> executable being unrecognized -- probably some problem with wrong
> compression algo).
> 
> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
> -- in this case it's even worse, as the system hangs at suspend and
> never enters S3 :/

Right. You need some patches for that in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
to make that work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:22:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZYU-0000C3-1I; Thu, 23 Feb 2012 14:21: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 1S0ZYR-0000Br-Sj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:21:56 +0000
Received: from [85.158.139.83:60892] by server-2.bemta-5.messagelabs.com id
	17/D5-20263-38B464F4; Thu, 23 Feb 2012 14:21:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330006913!16348574!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4483 invoked from network); 23 Feb 2012 14:21:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 14:21: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 q1NELno2012507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:21: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
	q1NELnWa004090
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:21:49 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
	q1NELmFV018575; Thu, 23 Feb 2012 08:21:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:21:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B01374171C; Thu, 23 Feb 2012 09:18:27 -0500 (EST)
Date: Thu, 23 Feb 2012 09:18:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120223141827.GC23963@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F460354.7080907@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F464B7E.00F9,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
> Hello,
> 
> I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
> integrated GPU) freezing at resume from S3 sleep... It seems like a
> Xen-related problems, as a similar kernel to what we use in Dom0
> (2.6.38+xenlinux), when run on baremetal shows no signs of problems at
> suspend/resume. Also I cannot find any problems reported on the internet
> with people having problems here.
> 
> Unfortunately the only COM port on ExpressCard I have, presents itself
> as a USB device, and so I cannot really debug this issue via console.
> The /var/log/pm-suspend also doesn't reveal anything useful (after I
> reboot, that is).
> 
> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> to approach debugging it?
> 
> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
> patches, and the i915 for the graphics. (Unfortunately I cannot just
> boot the same Dom0 kernel without Xen, as the GRUB complains about
> executable being unrecognized -- probably some problem with wrong
> compression algo).
> 
> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
> -- in this case it's even worse, as the system hangs at suspend and
> never enters S3 :/

Right. You need some patches for that in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
to make that work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:29:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zfp-0000UU-UN; Thu, 23 Feb 2012 14:29:33 +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 1S0Zfo-0000UP-Qw
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:29:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330007296!62322338!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9809 invoked from network); 23 Feb 2012 14:28:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Feb 2012 14:28:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330007363; l=328;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=22wCkN7tgbFzmDlT/v7gYmL7mY4=;
	b=aOHWAOFW4/bvveSBbTS04qVSe9GVAQUUb8ddBka+wNiUAPK0edXqLOjNjjZdO2oj7o7
	Dt/wG/XNrMyZQqvgzdUPxZJeANZXPLRVsH325DgkjOAnFcRPjZnABz/uns3+QkP0z39QY
	P4Z14nPd6ASN+usCGaFKD1V9/nfpV7Sul0s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (klopstock mo17) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w00284o1NDQiuG ;
	Thu, 23 Feb 2012 15:29:20 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3DE4A18638; Thu, 23 Feb 2012 15:29:18 +0100 (CET)
Date: Thu, 23 Feb 2012 15:29:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223142918.GA25289@aepfle.de>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize
	mem_event/access/paging interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Andres Lagar-Cavilla wrote:

> In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
> so please voice any concerns.

Too many changes already since 4.1, out of tree binaries are already
covered by bumped SONAME and bumped domctl version.

Acked-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 Thu Feb 23 14:29:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zfp-0000UU-UN; Thu, 23 Feb 2012 14:29:33 +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 1S0Zfo-0000UP-Qw
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:29:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330007296!62322338!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9809 invoked from network); 23 Feb 2012 14:28:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Feb 2012 14:28:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330007363; l=328;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=22wCkN7tgbFzmDlT/v7gYmL7mY4=;
	b=aOHWAOFW4/bvveSBbTS04qVSe9GVAQUUb8ddBka+wNiUAPK0edXqLOjNjjZdO2oj7o7
	Dt/wG/XNrMyZQqvgzdUPxZJeANZXPLRVsH325DgkjOAnFcRPjZnABz/uns3+QkP0z39QY
	P4Z14nPd6ASN+usCGaFKD1V9/nfpV7Sul0s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (klopstock mo17) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w00284o1NDQiuG ;
	Thu, 23 Feb 2012 15:29:20 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3DE4A18638; Thu, 23 Feb 2012 15:29:18 +0100 (CET)
Date: Thu, 23 Feb 2012 15:29:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223142918.GA25289@aepfle.de>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize
	mem_event/access/paging interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Andres Lagar-Cavilla wrote:

> In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
> so please voice any concerns.

Too many changes already since 4.1, out of tree binaries are already
covered by bumped SONAME and bumped domctl version.

Acked-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 Thu Feb 23 14:33:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zj4-0000ak-HT; Thu, 23 Feb 2012 14:32:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0Zj2-0000aZ-Ll
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:32:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330007566!10403158!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15106 invoked from network); 23 Feb 2012 14:32:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 14:32:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330007565; l=897;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=yCTwQ93XjJMiFGmLAWUUWVljHvs=;
	b=jA+g2L65T+ltTsQNTyYBjJROZ7pHLTcZ5jEH5F75CJRT2PxNpAjPlfTodm3BxI0Onqn
	9Vey9uUdZmHFgA2uM+UEiAbyLqT0nyp7H9uNSXUlXlMbpq3LsU46VFs26ZesqHaO2Uv6f
	apuhwWq/TP6+8b3BzDZXRHtm7wKtH/ho3U0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo10) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 9008b3o1NEK1kt ;
	Thu, 23 Feb 2012 15:32:33 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4B4E718638; Thu, 23 Feb 2012 15:32:31 +0100 (CET)
Date: Thu, 23 Feb 2012 15:32:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223143231.GB25289@aepfle.de>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<1a76b2f7641bec1dba82.1329977111@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1a76b2f7641bec1dba82.1329977111@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 7] x86/mm: Clean up mem event
 structures on domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Andres Lagar-Cavilla wrote:

> +++ b/xen/include/asm-arm/mm.h
> @@ -266,7 +266,8 @@ int  get_page(struct page_info *page, st
>          machine_to_phys_mapping[(mfn)] = (pfn);                \
>      })
>  
> -#define put_gfn(d, g)   ((void)0)
> +#define put_gfn(d, g)           ((void)0)
> +#define mem_event_cleanup(d)    ((void)0)
>  
>  #define INVALID_MFN             (~0UL)
>  
> diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-ia64/mm.h
> --- a/xen/include/asm-ia64/mm.h
> +++ b/xen/include/asm-ia64/mm.h
> @@ -551,7 +551,8 @@ extern u64 translate_domain_pte(u64 ptev
>      gmfn_to_mfn_foreign((_d), (gpfn))
>  
>  #define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
> -#define put_gfn(d, g)   ((void)0)
> +#define put_gfn(d, g)           ((void)0)
> +#define mem_event_cleanup(d)    ((void)0)

This is C, not cpp, so these should have been like this in the first place:

static inline int foo( .... ) { return 0; }


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:33:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zj4-0000ak-HT; Thu, 23 Feb 2012 14:32:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0Zj2-0000aZ-Ll
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:32:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330007566!10403158!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMzQwNDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15106 invoked from network); 23 Feb 2012 14:32:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 14:32:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330007565; l=897;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=yCTwQ93XjJMiFGmLAWUUWVljHvs=;
	b=jA+g2L65T+ltTsQNTyYBjJROZ7pHLTcZ5jEH5F75CJRT2PxNpAjPlfTodm3BxI0Onqn
	9Vey9uUdZmHFgA2uM+UEiAbyLqT0nyp7H9uNSXUlXlMbpq3LsU46VFs26ZesqHaO2Uv6f
	apuhwWq/TP6+8b3BzDZXRHtm7wKtH/ho3U0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo10) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 9008b3o1NEK1kt ;
	Thu, 23 Feb 2012 15:32:33 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4B4E718638; Thu, 23 Feb 2012 15:32:31 +0100 (CET)
Date: Thu, 23 Feb 2012 15:32:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223143231.GB25289@aepfle.de>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<1a76b2f7641bec1dba82.1329977111@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1a76b2f7641bec1dba82.1329977111@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 7] x86/mm: Clean up mem event
 structures on domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Andres Lagar-Cavilla wrote:

> +++ b/xen/include/asm-arm/mm.h
> @@ -266,7 +266,8 @@ int  get_page(struct page_info *page, st
>          machine_to_phys_mapping[(mfn)] = (pfn);                \
>      })
>  
> -#define put_gfn(d, g)   ((void)0)
> +#define put_gfn(d, g)           ((void)0)
> +#define mem_event_cleanup(d)    ((void)0)
>  
>  #define INVALID_MFN             (~0UL)
>  
> diff -r 9c6cbbe72dc4 -r 1a76b2f7641b xen/include/asm-ia64/mm.h
> --- a/xen/include/asm-ia64/mm.h
> +++ b/xen/include/asm-ia64/mm.h
> @@ -551,7 +551,8 @@ extern u64 translate_domain_pte(u64 ptev
>      gmfn_to_mfn_foreign((_d), (gpfn))
>  
>  #define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
> -#define put_gfn(d, g)   ((void)0)
> +#define put_gfn(d, g)           ((void)0)
> +#define mem_event_cleanup(d)    ((void)0)

This is C, not cpp, so these should have been like this in the first place:

static inline int foo( .... ) { return 0; }


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zka-0000h1-2f; Thu, 23 Feb 2012 14:34:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1S0ZkY-0000gh-0S
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 14:34:26 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330007659!15559465!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12874 invoked from network); 23 Feb 2012 14:34:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 14:34:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 14:34:19 +0000
Message-Id: <4F464E68020000780007F738@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 14:34:16 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <tim@xen.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
	<4F3E95610200007800073B97@nat28.tlf.novell.com>
	<20120223103351.GB25694@ocelot.phlegethon.org>
In-Reply-To: <20120223103351.GB25694@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
 pagetable walker: check for invalid bits in pagetable 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

>>> Tim Deegan <tim@xen.org> 02/23/12 11:34 AM >>>
>I've applied it, since it seemed not to break anything and I'll be away
>from my test boxes for a while.  Let me know of you're still seeing any
>problems. 

Thanks - I had hoped we would have reported testing results earlier, but
this unfortunately is going pretty slowly.

One thing though - shouldn't further walking be suppressed if at a
given level any violation is detected (i.e. if rc became non-zero)? For
sure the hardware aborts a walk at least if reserved bits are found
set, and I'd suspect it also doesn't bother continuing the walk if access
rights don't permit the result to be used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zka-0000h1-2f; Thu, 23 Feb 2012 14:34:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1S0ZkY-0000gh-0S
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 14:34:26 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330007659!15559465!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12874 invoked from network); 23 Feb 2012 14:34:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 14:34:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 14:34:19 +0000
Message-Id: <4F464E68020000780007F738@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 14:34:16 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <tim@xen.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
	<4F3E95610200007800073B97@nat28.tlf.novell.com>
	<20120223103351.GB25694@ocelot.phlegethon.org>
In-Reply-To: <20120223103351.GB25694@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
 pagetable walker: check for invalid bits in pagetable 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

>>> Tim Deegan <tim@xen.org> 02/23/12 11:34 AM >>>
>I've applied it, since it seemed not to break anything and I'll be away
>from my test boxes for a while.  Let me know of you're still seeing any
>problems. 

Thanks - I had hoped we would have reported testing results earlier, but
this unfortunately is going pretty slowly.

One thing though - shouldn't further walking be suppressed if at a
given level any violation is detected (i.e. if rc became non-zero)? For
sure the hardware aborts a walk at least if reserved bits are found
set, and I'd suspect it also doesn't bother continuing the walk if access
rights don't permit the result to be used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zuw-0000wb-6V; Thu, 23 Feb 2012 14:45:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zuv-0000wW-JF
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:45:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330008302!9483257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30974 invoked from network); 23 Feb 2012 14:45:03 -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;
	23 Feb 2012 14:45:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10898414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 14:45:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 14:45:02 +0000
Date: Thu, 23 Feb 2012 14:50:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v5 0/7] arm: compile 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

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v5:

- libxc: return -1 and set errno on error;

- add few missing emacs runes in new files.


Changes in v4:

- rebased on 55a36564fb4f85722c67f16fe508f3ecbd204549;

- minor compile fixes.



Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;

- remove "libxl: do not allocate e820 for non x86 guests.";

- introduce libxl__arch_domain_create.



Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (1):
      arm: add stub hvm/save.h

Stefano Stabellini (6):
      arm: compile libxc
      arm: compile libxenguest
      arm: compile memshr
      arm: compile xentrace
      arm: compile libxl
      libxl: Introduce libxl__arch_domain_create

 tools/libxc/Makefile                   |   13 +-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  107 +++++++
 tools/libxc/xc_core_arm.h              |   60 ++++
 tools/libxc/xc_dom_arm.c               |   50 +++
 tools/libxc/xc_hvm_build.c             |  511 --------------------------------
 tools/libxc/xc_hvm_build_arm.c         |   61 ++++
 tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c             |   53 ++++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    5 +-
 tools/libxl/libxl_arch.h               |   22 ++
 tools/libxl/libxl_cpuid.c              |   60 ++++
 tools/libxl/libxl_create.c             |   12 +-
 tools/libxl/libxl_internal.h           |    2 -
 tools/libxl/libxl_json.c               |   60 ----
 tools/libxl/libxl_noarch.c             |    8 +
 tools/libxl/libxl_nocpuid.c            |    8 +-
 tools/libxl/libxl_pci.c                |  242 ---------------
 tools/libxl/libxl_x86.c                |  259 ++++++++++++++++
 tools/memshr/bidir-hash.c              |   31 ++
 tools/xentrace/xenctx.c                |   12 +
 xen/include/public/arch-arm/hvm/save.h |   39 +++
 xen/include/public/hvm/save.h          |    2 +
 24 files changed, 1303 insertions(+), 831 deletions(-)


A git tree based on 6c69c04ed2b1d5fd0cbebb61e649c03d9d2e8d9a, is
available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-5


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zuw-0000wb-6V; Thu, 23 Feb 2012 14:45:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zuv-0000wW-JF
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:45:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330008302!9483257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30974 invoked from network); 23 Feb 2012 14:45:03 -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;
	23 Feb 2012 14:45:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10898414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 14:45:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 14:45:02 +0000
Date: Thu, 23 Feb 2012 14:50:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: [Xen-devel] [PATCH v5 0/7] arm: compile 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

Hi all,
this patch series allows tools/ to compile on ARM, mostly providing an
empty implementation for all the arch specific functions that are needed.


Changes in v5:

- libxc: return -1 and set errno on error;

- add few missing emacs runes in new files.


Changes in v4:

- rebased on 55a36564fb4f85722c67f16fe508f3ecbd204549;

- minor compile fixes.



Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c;

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;

- remove "libxl: do not allocate e820 for non x86 guests.";

- introduce libxl__arch_domain_create.



Changes in v2:

- rebased on a22587ae517170a7755d3a88611ae0e2d5bb555e;

- dropped "arm: arch_dump_shared_mem_info as a no-op" that is already in
xen-unstable;

- define xen_callback_t as uint64_t;

- define guest_word_t as uint64_t.



Ian Campbell (1):
      arm: add stub hvm/save.h

Stefano Stabellini (6):
      arm: compile libxc
      arm: compile libxenguest
      arm: compile memshr
      arm: compile xentrace
      arm: compile libxl
      libxl: Introduce libxl__arch_domain_create

 tools/libxc/Makefile                   |   13 +-
 tools/libxc/xc_core.h                  |    2 +
 tools/libxc/xc_core_arm.c              |  107 +++++++
 tools/libxc/xc_core_arm.h              |   60 ++++
 tools/libxc/xc_dom_arm.c               |   50 +++
 tools/libxc/xc_hvm_build.c             |  511 --------------------------------
 tools/libxc/xc_hvm_build_arm.c         |   61 ++++
 tools/libxc/xc_hvm_build_x86.c         |  511 ++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c             |   53 ++++
 tools/libxc/xenctrl.h                  |    4 +
 tools/libxl/Makefile                   |    5 +-
 tools/libxl/libxl_arch.h               |   22 ++
 tools/libxl/libxl_cpuid.c              |   60 ++++
 tools/libxl/libxl_create.c             |   12 +-
 tools/libxl/libxl_internal.h           |    2 -
 tools/libxl/libxl_json.c               |   60 ----
 tools/libxl/libxl_noarch.c             |    8 +
 tools/libxl/libxl_nocpuid.c            |    8 +-
 tools/libxl/libxl_pci.c                |  242 ---------------
 tools/libxl/libxl_x86.c                |  259 ++++++++++++++++
 tools/memshr/bidir-hash.c              |   31 ++
 tools/xentrace/xenctx.c                |   12 +
 xen/include/public/arch-arm/hvm/save.h |   39 +++
 xen/include/public/hvm/save.h          |    2 +
 24 files changed, 1303 insertions(+), 831 deletions(-)


A git tree based on 6c69c04ed2b1d5fd0cbebb61e649c03d9d2e8d9a, is
available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-tools-5


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zvt-0000zT-Gn; Thu, 23 Feb 2012 14:46:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvs-0000yY-Kt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330008359!14622510!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26979 invoked from network); 23 Feb 2012 14:46:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377446"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Pi; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:46 +0000
Message-ID: <1330008712-17715-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 2/7] arm: compile 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

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  107 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 174 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..e6716e4
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,107 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..29c13a7 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14: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 1S0Zvt-0000zT-Gn; Thu, 23 Feb 2012 14:46:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvs-0000yY-Kt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330008359!14622510!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26979 invoked from network); 23 Feb 2012 14:46:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377446"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Pi; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:46 +0000
Message-ID: <1330008712-17715-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 2/7] arm: compile 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

Introduce an empty implementation of the arch specific ARM functions in
xc_core_arm.c and xc_core_arm.h; define barriers on ARM.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |  107 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   60 +++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 5 files changed, 174 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..f2e1ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -8,6 +8,7 @@ CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-y       += xc_cpupool.c
 CTRL_SRCS-y       += xc_domain.c
 CTRL_SRCS-y       += xc_evtchn.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..e6716e4
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,107 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011 Citrix Systems
+ *
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* TODO: memory from DT */
+    if (pfn >= 0x80000 && pfn < 0x88000)
+        return 1;
+    return 0;
+}
+
+
+static int nr_gpfns(xc_interface *xch, domid_t domid)
+{
+    return xc_domain_maximum_gpfn(xch, domid) + 1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unused,
+                            xc_dominfo_t *info, shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    unsigned long p2m_size = nr_gpfns(xch, info->domid);
+    xc_core_memory_map_t *map;
+
+    map = malloc(sizeof(*map));
+    if ( map == NULL )
+    {
+        PERROR("Could not allocate memory");
+        return -1;
+    }
+
+    map->addr = 0;
+    map->size = ((uint64_t)p2m_size) << PAGE_SHIFT;
+
+    *mapp = map;
+    *nr_entries = 1;
+    return 0;
+}
+
+static int
+xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp, int rw)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                        shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                        unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 0);
+}
+
+int
+xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                              shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                              unsigned long *pfnp)
+{
+    struct domain_info_context _dinfo = { .guest_width = guest_width };
+    struct domain_info_context *dinfo = &_dinfo;
+    return xc_core_arch_map_p2m_rw(xch, dinfo, info,
+                                   live_shinfo, live_p2m, pfnp, 1);
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..3a6be2a
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,60 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..29c13a7 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -83,6 +83,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zvt-0000zg-T4; Thu, 23 Feb 2012 14:46:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvs-0000yZ-Ls
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330008361!12985576!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 23 Feb 2012 14:46:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377447"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Rv; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:49 +0000
Message-ID: <1330008712-17715-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 5/7] arm: compile xentrace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zvt-0000zg-T4; Thu, 23 Feb 2012 14:46:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvs-0000yZ-Ls
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330008361!12985576!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 23 Feb 2012 14:46:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377447"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Rv; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:49 +0000
Message-ID: <1330008712-17715-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 5/7] arm: compile xentrace
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xentrace/xenctx.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index a12cc21..530ef65 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -60,6 +60,12 @@ int disp_ar_regs;
 int disp_br_regs;
 int disp_bank_regs;
 int disp_tlb;
+
+#elif defined(__arm__)
+#define NO_TRANSLATION
+typedef uint64_t guest_word_t;
+#define FMT_32B_WORD "%08llx"
+#define FMT_64B_WORD "%016llx"
 #endif
 
 struct symbol {
@@ -678,6 +684,12 @@ void print_ctx(vcpu_guest_context_any_t *ctx)
             print_tr(i, &tr->dtrs[i]);
     }
 }
+#elif defined(__arm__)
+static void print_ctx(vcpu_guest_context_any_t *ctx)
+{
+    /* XXX: properly implement this */
+    print_symbol(0);
+}
 #endif
 
 #ifndef NO_TRANSLATION
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zvs-0000yx-Kf; Thu, 23 Feb 2012 14:46:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvq-0000yU-WF
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330008359!14622510!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26888 invoked from network); 23 Feb 2012 14:46:00 -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;
	23 Feb 2012 14:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377444"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Nu; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:45 +0000
Message-ID: <1330008712-17715-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 1/7] arm: add stub hvm/save.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

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zvs-0000yx-Kf; Thu, 23 Feb 2012 14:46:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvq-0000yU-WF
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330008359!14622510!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26888 invoked from network); 23 Feb 2012 14:46:00 -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;
	23 Feb 2012 14:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377444"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Nu; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:45 +0000
Message-ID: <1330008712-17715-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 1/7] arm: add stub hvm/save.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

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * 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_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zw2-00012G-NI; Thu, 23 Feb 2012 14:46:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zw0-000108-8D
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330008366!15562002!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32692 invoked from network); 23 Feb 2012 14:46:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183125010"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-UF; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:51 +0000
Message-ID: <1330008712-17715-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce an arch specific internal domain creation function. At the
moment only x86 provides an implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile         |    6 +-
 tools/libxl/libxl_arch.h     |   22 ++++
 tools/libxl/libxl_create.c   |   12 +--
 tools/libxl/libxl_internal.h |    2 -
 tools/libxl/libxl_noarch.c   |    8 ++
 tools/libxl/libxl_pci.c      |  242 ---------------------------------------
 tools/libxl/libxl_x86.c      |  259 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 294 insertions(+), 257 deletions(-)
 create mode 100644 tools/libxl/libxl_arch.h
 create mode 100644 tools/libxl/libxl_noarch.c
 create mode 100644 tools/libxl/libxl_x86.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 41b6ac4..ba5852b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
 endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
-LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
+LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
new file mode 100644
index 0000000..d1bbdf7
--- /dev/null
+++ b/tools/libxl/libxl_arch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_ARCH_H
+#define LIBXL_ARCH_H
+
+/* arch specific internal domain creation function */
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+		uint32_t domid);
+
+#endif
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..ff589a8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -18,6 +18,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 
 #include <xc_dom.h>
 #include <xenguest.h>
@@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
-    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                      "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
-    }
+    libxl__arch_domain_create(gc, d_config, domid);
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8846c68..bd384e2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -975,8 +975,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
 
-_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
-
 /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
 _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
new file mode 100644
index 0000000..7893535
--- /dev/null
+++ b/tools/libxl/libxl_noarch.c
@@ -0,0 +1,8 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+                              uint32_t domid)
+{
+    return 0;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 33425f5..d960f4b 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static const char *e820_names(int type)
-{
-    switch (type) {
-        case E820_RAM: return "RAM";
-        case E820_RESERVED: return "Reserved";
-        case E820_ACPI: return "ACPI";
-        case E820_NVS: return "ACPI NVS";
-        case E820_UNUSABLE: return "Unusable";
-        default: break;
-    }
-    return "Unknown";
-}
-
-static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
-                         uint32_t *nr_entries,
-                         unsigned long map_limitkb,
-                         unsigned long balloon_kb)
-{
-    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
-    uint32_t i, idx = 0, nr;
-    struct e820entry e820[E820MAX];
-
-    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
-        return ERROR_INVAL;
-
-    nr = *nr_entries;
-    if (!nr)
-        return ERROR_INVAL;
-
-    if (nr > E820MAX)
-        return ERROR_NOMEM;
-
-    /* Weed out anything under 1MB */
-    for (i = 0; i < nr; i++) {
-        if (src[i].addr > 0x100000)
-            continue;
-
-        src[i].type = 0;
-        src[i].size = 0;
-        src[i].addr = -1ULL;
-    }
-
-    /* Find the lowest and highest entry in E820, skipping over
-     * undesired entries. */
-    start = -1ULL;
-    last = 0;
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == E820_UNUSABLE) ||
-            (src[i].type == 0))
-            continue;
-
-        start = src[i].addr < start ? src[i].addr : start;
-        last = src[i].addr + src[i].size > last ?
-               src[i].addr + src[i].size > last : last;
-    }
-    if (start > 1024)
-        start_kb = start >> 10;
-
-    /* Add the memory RAM region for the guest */
-    e820[idx].addr = 0;
-    e820[idx].size = (uint64_t)map_limitkb << 10;
-    e820[idx].type = E820_RAM;
-
-    /* .. and trim if neccessary */
-    if (start_kb && map_limitkb > start_kb) {
-        delta_kb = map_limitkb - start_kb;
-        if (delta_kb)
-            e820[idx].size -= (uint64_t)(delta_kb << 10);
-    }
-    /* Note: We don't touch balloon_kb here. Will add it at the end. */
-    ram_end = e820[idx].addr + e820[idx].size;
-    idx ++;
-
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
-               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
-               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
-               ram_end >> 12, delta_kb, start_kb ,start >> 12,
-               (uint64_t)balloon_kb);
-
-
-    /* This whole code below is to guard against if the Intel IGD is passed into
-     * the guest. If we don't pass in IGD, this whole code can be ignored.
-     *
-     * The reason for this code is that Intel boxes fill their E820 with
-     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
-     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
-     * Linux and it would be utilized by the Intel IGD as I/O space while
-     * in reality it was an RAM region.
-     *
-     * What this means is that we have to walk the E820 and for any region
-     * that is RAM and below 4GB and above ram_end, needs to change its type
-     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
-     * the overlap with ram_end. */
-    for (i = 0; i < nr; i++) {
-        uint64_t end = src[i].addr + src[i].size;
-
-        /* We don't care about E820_UNUSABLE, but we need to
-         * change the type to zero b/c the loop after this
-         * sticks E820_UNUSABLE on the guest's E820 but ignores
-         * the ones with type zero. */
-        if ((src[i].type == E820_UNUSABLE) ||
-            /* Any region that is within the "RAM region" can
-             * be safely ditched. */
-            (end < ram_end)) {
-                src[i].type = 0;
-                continue;
-        }
-
-        /* Look only at RAM regions. */
-        if (src[i].type != E820_RAM)
-            continue;
-
-        /* We only care about RAM regions below 4GB. */
-        if (src[i].addr >= (1ULL<<32))
-            continue;
-
-        /* E820_RAM overlaps with our RAM region. Move it */
-        if (src[i].addr < ram_end) {
-            uint64_t delta;
-
-            src[i].type = E820_UNUSABLE;
-            delta = ram_end - src[i].addr;
-            /* The end < ram_end should weed this out */
-            if (src[i].size - delta < 0)
-                src[i].type = 0;
-            else {
-                src[i].size -= delta;
-                src[i].addr = ram_end;
-            }
-            if (src[i].addr + src[i].size != end) {
-                /* We messed up somewhere */
-                src[i].type = 0;
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
-            }
-        }
-        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
-           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
-            "xen/setup: Inhibit resource API from using System RAM E820
-           gaps as PCI mem gaps" for full explanation. */
-        if (end > ram_end)
-            src[i].type = E820_UNUSABLE;
-    }
-
-    /* Check if there is a region between ram_end and start. */
-    if (start > ram_end) {
-        int add_unusable = 1;
-        for (i = 0; i < nr && add_unusable; i++) {
-            if (src[i].type != E820_UNUSABLE)
-                continue;
-            if (ram_end != src[i].addr)
-                continue;
-            if (start != src[i].addr + src[i].size) {
-                /* there is one, adjust it */
-                src[i].size = start - src[i].addr;
-            }
-            add_unusable = 0;
-        }
-        /* .. and if not present, add it in. This is to guard against
-           the Linux guest assuming that the gap between the end of
-           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-           is PCI I/O space. Which it certainly is _not_. */
-        if (add_unusable) {
-            e820[idx].type = E820_UNUSABLE;
-            e820[idx].addr = ram_end;
-            e820[idx].size = start - ram_end;
-            idx++;
-        }
-    }
-    /* Almost done: copy them over, ignoring the undesireable ones */
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == 0))
-            continue;
-
-        e820[idx].type = src[i].type;
-        e820[idx].addr = src[i].addr;
-        e820[idx].size = src[i].size;
-        idx++;
-    }
-    /* At this point we have the mapped RAM + E820 entries from src. */
-    if (balloon_kb) {
-        /* and if we truncated the RAM region, then add it to the end. */
-        e820[idx].type = E820_RAM;
-        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
-                         (uint64_t)(1ULL << 32) : last;
-        /* also add the balloon memory to the end. */
-        e820[idx].size = (uint64_t)(delta_kb << 10) +
-                         (uint64_t)(balloon_kb << 10);
-        idx++;
-
-    }
-    nr = idx;
-
-    for (i = 0; i < nr; i++) {
-      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
-                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
-                 e820_names(e820[i].type));
-    }
-
-    /* Done: copy the sanitized version. */
-    *nr_entries = nr;
-    memcpy(src, e820, nr * sizeof(struct e820entry));
-    return 0;
-}
-
-int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc;
-    uint32_t nr;
-    struct e820entry map[E820MAX];
-    libxl_domain_build_info *b_info;
-
-    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        return ERROR_INVAL;
-
-    b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
-        return ERROR_INVAL;
-
-    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
-    if (rc < 0) {
-        errno = rc;
-        return ERROR_FAIL;
-    }
-    nr = rc;
-    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
-                       (b_info->max_memkb - b_info->target_memkb) +
-                       b_info->u.pv.slack_memkb);
-    if (rc)
-        return ERROR_FAIL;
-
-    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
-
-    if (rc < 0) {
-        errno  = rc;
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
new file mode 100644
index 0000000..7e11f2d
--- /dev/null
+++ b/tools/libxl/libxl_x86.c
@@ -0,0 +1,259 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+            continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+        uint64_t end = src[i].addr + src[i].size;
+
+        /* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+            /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+        if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+        /* E820_RAM overlaps with our RAM region. Move it */
+        if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
+        /* .. and if not present, add it in. This is to guard against
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == 0))
+            continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+        uint32_t domid)
+{
+    int rc = 0;
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
+        d_config->b_info.u.pv.e820_host) {
+        rc = libxl__e820_alloc(gc, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
+    return rc;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zw2-00012G-NI; Thu, 23 Feb 2012 14:46:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zw0-000108-8D
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330008366!15562002!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32692 invoked from network); 23 Feb 2012 14:46:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183125010"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-UF; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:51 +0000
Message-ID: <1330008712-17715-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce an arch specific internal domain creation function. At the
moment only x86 provides an implementation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/Makefile         |    6 +-
 tools/libxl/libxl_arch.h     |   22 ++++
 tools/libxl/libxl_create.c   |   12 +--
 tools/libxl/libxl_internal.h |    2 -
 tools/libxl/libxl_noarch.c   |    8 ++
 tools/libxl/libxl_pci.c      |  242 ---------------------------------------
 tools/libxl/libxl_x86.c      |  259 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 294 insertions(+), 257 deletions(-)
 create mode 100644 tools/libxl/libxl_arch.h
 create mode 100644 tools/libxl/libxl_noarch.c
 create mode 100644 tools/libxl/libxl_x86.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 41b6ac4..ba5852b 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
 endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
-LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
+LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
new file mode 100644
index 0000000..d1bbdf7
--- /dev/null
+++ b/tools/libxl/libxl_arch.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_ARCH_H
+#define LIBXL_ARCH_H
+
+/* arch specific internal domain creation function */
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+		uint32_t domid);
+
+#endif
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f28d814..ff589a8 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -18,6 +18,7 @@
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
+#include "libxl_arch.h"
 
 #include <xc_dom.h>
 #include <xenguest.h>
@@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
-    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
-        int rc;
-        rc = libxl__e820_alloc(gc, domid, d_config);
-        if (rc)
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                      "Failed while collecting E820 with: %d (errno:%d)\n",
-                      rc, errno);
-    }
+    libxl__arch_domain_create(gc, d_config, domid);
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8846c68..bd384e2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -975,8 +975,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
 
-_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
-
 /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
 _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
new file mode 100644
index 0000000..7893535
--- /dev/null
+++ b/tools/libxl/libxl_noarch.c
@@ -0,0 +1,8 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+                              uint32_t domid)
+{
+    return 0;
+}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 33425f5..d960f4b 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
-static const char *e820_names(int type)
-{
-    switch (type) {
-        case E820_RAM: return "RAM";
-        case E820_RESERVED: return "Reserved";
-        case E820_ACPI: return "ACPI";
-        case E820_NVS: return "ACPI NVS";
-        case E820_UNUSABLE: return "Unusable";
-        default: break;
-    }
-    return "Unknown";
-}
-
-static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
-                         uint32_t *nr_entries,
-                         unsigned long map_limitkb,
-                         unsigned long balloon_kb)
-{
-    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
-    uint32_t i, idx = 0, nr;
-    struct e820entry e820[E820MAX];
-
-    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
-        return ERROR_INVAL;
-
-    nr = *nr_entries;
-    if (!nr)
-        return ERROR_INVAL;
-
-    if (nr > E820MAX)
-        return ERROR_NOMEM;
-
-    /* Weed out anything under 1MB */
-    for (i = 0; i < nr; i++) {
-        if (src[i].addr > 0x100000)
-            continue;
-
-        src[i].type = 0;
-        src[i].size = 0;
-        src[i].addr = -1ULL;
-    }
-
-    /* Find the lowest and highest entry in E820, skipping over
-     * undesired entries. */
-    start = -1ULL;
-    last = 0;
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == E820_UNUSABLE) ||
-            (src[i].type == 0))
-            continue;
-
-        start = src[i].addr < start ? src[i].addr : start;
-        last = src[i].addr + src[i].size > last ?
-               src[i].addr + src[i].size > last : last;
-    }
-    if (start > 1024)
-        start_kb = start >> 10;
-
-    /* Add the memory RAM region for the guest */
-    e820[idx].addr = 0;
-    e820[idx].size = (uint64_t)map_limitkb << 10;
-    e820[idx].type = E820_RAM;
-
-    /* .. and trim if neccessary */
-    if (start_kb && map_limitkb > start_kb) {
-        delta_kb = map_limitkb - start_kb;
-        if (delta_kb)
-            e820[idx].size -= (uint64_t)(delta_kb << 10);
-    }
-    /* Note: We don't touch balloon_kb here. Will add it at the end. */
-    ram_end = e820[idx].addr + e820[idx].size;
-    idx ++;
-
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
-               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
-               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
-               ram_end >> 12, delta_kb, start_kb ,start >> 12,
-               (uint64_t)balloon_kb);
-
-
-    /* This whole code below is to guard against if the Intel IGD is passed into
-     * the guest. If we don't pass in IGD, this whole code can be ignored.
-     *
-     * The reason for this code is that Intel boxes fill their E820 with
-     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
-     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
-     * Linux and it would be utilized by the Intel IGD as I/O space while
-     * in reality it was an RAM region.
-     *
-     * What this means is that we have to walk the E820 and for any region
-     * that is RAM and below 4GB and above ram_end, needs to change its type
-     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
-     * the overlap with ram_end. */
-    for (i = 0; i < nr; i++) {
-        uint64_t end = src[i].addr + src[i].size;
-
-        /* We don't care about E820_UNUSABLE, but we need to
-         * change the type to zero b/c the loop after this
-         * sticks E820_UNUSABLE on the guest's E820 but ignores
-         * the ones with type zero. */
-        if ((src[i].type == E820_UNUSABLE) ||
-            /* Any region that is within the "RAM region" can
-             * be safely ditched. */
-            (end < ram_end)) {
-                src[i].type = 0;
-                continue;
-        }
-
-        /* Look only at RAM regions. */
-        if (src[i].type != E820_RAM)
-            continue;
-
-        /* We only care about RAM regions below 4GB. */
-        if (src[i].addr >= (1ULL<<32))
-            continue;
-
-        /* E820_RAM overlaps with our RAM region. Move it */
-        if (src[i].addr < ram_end) {
-            uint64_t delta;
-
-            src[i].type = E820_UNUSABLE;
-            delta = ram_end - src[i].addr;
-            /* The end < ram_end should weed this out */
-            if (src[i].size - delta < 0)
-                src[i].type = 0;
-            else {
-                src[i].size -= delta;
-                src[i].addr = ram_end;
-            }
-            if (src[i].addr + src[i].size != end) {
-                /* We messed up somewhere */
-                src[i].type = 0;
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
-            }
-        }
-        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
-           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
-            "xen/setup: Inhibit resource API from using System RAM E820
-           gaps as PCI mem gaps" for full explanation. */
-        if (end > ram_end)
-            src[i].type = E820_UNUSABLE;
-    }
-
-    /* Check if there is a region between ram_end and start. */
-    if (start > ram_end) {
-        int add_unusable = 1;
-        for (i = 0; i < nr && add_unusable; i++) {
-            if (src[i].type != E820_UNUSABLE)
-                continue;
-            if (ram_end != src[i].addr)
-                continue;
-            if (start != src[i].addr + src[i].size) {
-                /* there is one, adjust it */
-                src[i].size = start - src[i].addr;
-            }
-            add_unusable = 0;
-        }
-        /* .. and if not present, add it in. This is to guard against
-           the Linux guest assuming that the gap between the end of
-           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
-           is PCI I/O space. Which it certainly is _not_. */
-        if (add_unusable) {
-            e820[idx].type = E820_UNUSABLE;
-            e820[idx].addr = ram_end;
-            e820[idx].size = start - ram_end;
-            idx++;
-        }
-    }
-    /* Almost done: copy them over, ignoring the undesireable ones */
-    for (i = 0; i < nr; i++) {
-        if ((src[i].type == E820_RAM) ||
-            (src[i].type == 0))
-            continue;
-
-        e820[idx].type = src[i].type;
-        e820[idx].addr = src[i].addr;
-        e820[idx].size = src[i].size;
-        idx++;
-    }
-    /* At this point we have the mapped RAM + E820 entries from src. */
-    if (balloon_kb) {
-        /* and if we truncated the RAM region, then add it to the end. */
-        e820[idx].type = E820_RAM;
-        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
-                         (uint64_t)(1ULL << 32) : last;
-        /* also add the balloon memory to the end. */
-        e820[idx].size = (uint64_t)(delta_kb << 10) +
-                         (uint64_t)(balloon_kb << 10);
-        idx++;
-
-    }
-    nr = idx;
-
-    for (i = 0; i < nr; i++) {
-      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
-                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
-                 e820_names(e820[i].type));
-    }
-
-    /* Done: copy the sanitized version. */
-    *nr_entries = nr;
-    memcpy(src, e820, nr * sizeof(struct e820entry));
-    return 0;
-}
-
-int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc;
-    uint32_t nr;
-    struct e820entry map[E820MAX];
-    libxl_domain_build_info *b_info;
-
-    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
-        return ERROR_INVAL;
-
-    b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
-        return ERROR_INVAL;
-
-    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
-    if (rc < 0) {
-        errno = rc;
-        return ERROR_FAIL;
-    }
-    nr = rc;
-    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
-                       (b_info->max_memkb - b_info->target_memkb) +
-                       b_info->u.pv.slack_memkb);
-    if (rc)
-        return ERROR_FAIL;
-
-    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
-
-    if (rc < 0) {
-        errno  = rc;
-        return ERROR_FAIL;
-    }
-    return 0;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
new file mode 100644
index 0000000..7e11f2d
--- /dev/null
+++ b/tools/libxl/libxl_x86.c
@@ -0,0 +1,259 @@
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+static const char *e820_names(int type)
+{
+    switch (type) {
+        case E820_RAM: return "RAM";
+        case E820_RESERVED: return "Reserved";
+        case E820_ACPI: return "ACPI";
+        case E820_NVS: return "ACPI NVS";
+        case E820_UNUSABLE: return "Unusable";
+        default: break;
+    }
+    return "Unknown";
+}
+
+static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
+                         uint32_t *nr_entries,
+                         unsigned long map_limitkb,
+                         unsigned long balloon_kb)
+{
+    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
+    uint32_t i, idx = 0, nr;
+    struct e820entry e820[E820MAX];
+
+    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
+        return ERROR_INVAL;
+
+    nr = *nr_entries;
+    if (!nr)
+        return ERROR_INVAL;
+
+    if (nr > E820MAX)
+        return ERROR_NOMEM;
+
+    /* Weed out anything under 1MB */
+    for (i = 0; i < nr; i++) {
+        if (src[i].addr > 0x100000)
+            continue;
+
+        src[i].type = 0;
+        src[i].size = 0;
+        src[i].addr = -1ULL;
+    }
+
+    /* Find the lowest and highest entry in E820, skipping over
+     * undesired entries. */
+    start = -1ULL;
+    last = 0;
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == E820_UNUSABLE) ||
+            (src[i].type == 0))
+            continue;
+
+        start = src[i].addr < start ? src[i].addr : start;
+        last = src[i].addr + src[i].size > last ?
+               src[i].addr + src[i].size > last : last;
+    }
+    if (start > 1024)
+        start_kb = start >> 10;
+
+    /* Add the memory RAM region for the guest */
+    e820[idx].addr = 0;
+    e820[idx].size = (uint64_t)map_limitkb << 10;
+    e820[idx].type = E820_RAM;
+
+    /* .. and trim if neccessary */
+    if (start_kb && map_limitkb > start_kb) {
+        delta_kb = map_limitkb - start_kb;
+        if (delta_kb)
+            e820[idx].size -= (uint64_t)(delta_kb << 10);
+    }
+    /* Note: We don't touch balloon_kb here. Will add it at the end. */
+    ram_end = e820[idx].addr + e820[idx].size;
+    idx ++;
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
+               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
+               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
+               ram_end >> 12, delta_kb, start_kb ,start >> 12,
+               (uint64_t)balloon_kb);
+
+
+    /* This whole code below is to guard against if the Intel IGD is passed into
+     * the guest. If we don't pass in IGD, this whole code can be ignored.
+     *
+     * The reason for this code is that Intel boxes fill their E820 with
+     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
+     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
+     * Linux and it would be utilized by the Intel IGD as I/O space while
+     * in reality it was an RAM region.
+     *
+     * What this means is that we have to walk the E820 and for any region
+     * that is RAM and below 4GB and above ram_end, needs to change its type
+     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
+     * the overlap with ram_end. */
+    for (i = 0; i < nr; i++) {
+        uint64_t end = src[i].addr + src[i].size;
+
+        /* We don't care about E820_UNUSABLE, but we need to
+         * change the type to zero b/c the loop after this
+         * sticks E820_UNUSABLE on the guest's E820 but ignores
+         * the ones with type zero. */
+        if ((src[i].type == E820_UNUSABLE) ||
+            /* Any region that is within the "RAM region" can
+             * be safely ditched. */
+            (end < ram_end)) {
+                src[i].type = 0;
+                continue;
+        }
+
+        /* Look only at RAM regions. */
+        if (src[i].type != E820_RAM)
+            continue;
+
+        /* We only care about RAM regions below 4GB. */
+        if (src[i].addr >= (1ULL<<32))
+            continue;
+
+        /* E820_RAM overlaps with our RAM region. Move it */
+        if (src[i].addr < ram_end) {
+            uint64_t delta;
+
+            src[i].type = E820_UNUSABLE;
+            delta = ram_end - src[i].addr;
+            /* The end < ram_end should weed this out */
+            if (src[i].size - delta < 0)
+                src[i].type = 0;
+            else {
+                src[i].size -= delta;
+                src[i].addr = ram_end;
+            }
+            if (src[i].addr + src[i].size != end) {
+                /* We messed up somewhere */
+                src[i].type = 0;
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
+            }
+        }
+        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
+           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
+            "xen/setup: Inhibit resource API from using System RAM E820
+           gaps as PCI mem gaps" for full explanation. */
+        if (end > ram_end)
+            src[i].type = E820_UNUSABLE;
+    }
+
+    /* Check if there is a region between ram_end and start. */
+    if (start > ram_end) {
+        int add_unusable = 1;
+        for (i = 0; i < nr && add_unusable; i++) {
+            if (src[i].type != E820_UNUSABLE)
+                continue;
+            if (ram_end != src[i].addr)
+                continue;
+            if (start != src[i].addr + src[i].size) {
+                /* there is one, adjust it */
+                src[i].size = start - src[i].addr;
+            }
+            add_unusable = 0;
+        }
+        /* .. and if not present, add it in. This is to guard against
+           the Linux guest assuming that the gap between the end of
+           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
+           is PCI I/O space. Which it certainly is _not_. */
+        if (add_unusable) {
+            e820[idx].type = E820_UNUSABLE;
+            e820[idx].addr = ram_end;
+            e820[idx].size = start - ram_end;
+            idx++;
+        }
+    }
+    /* Almost done: copy them over, ignoring the undesireable ones */
+    for (i = 0; i < nr; i++) {
+        if ((src[i].type == E820_RAM) ||
+            (src[i].type == 0))
+            continue;
+
+        e820[idx].type = src[i].type;
+        e820[idx].addr = src[i].addr;
+        e820[idx].size = src[i].size;
+        idx++;
+    }
+    /* At this point we have the mapped RAM + E820 entries from src. */
+    if (balloon_kb) {
+        /* and if we truncated the RAM region, then add it to the end. */
+        e820[idx].type = E820_RAM;
+        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
+                         (uint64_t)(1ULL << 32) : last;
+        /* also add the balloon memory to the end. */
+        e820[idx].size = (uint64_t)(delta_kb << 10) +
+                         (uint64_t)(balloon_kb << 10);
+        idx++;
+
+    }
+    nr = idx;
+
+    for (i = 0; i < nr; i++) {
+      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
+                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
+                 e820_names(e820[i].type));
+    }
+
+    /* Done: copy the sanitized version. */
+    *nr_entries = nr;
+    memcpy(src, e820, nr * sizeof(struct e820entry));
+    return 0;
+}
+
+static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int rc;
+    uint32_t nr;
+    struct e820entry map[E820MAX];
+    libxl_domain_build_info *b_info;
+
+    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
+    b_info = &d_config->b_info;
+    if (!b_info->u.pv.e820_host)
+        return ERROR_INVAL;
+
+    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
+    if (rc < 0) {
+        errno = rc;
+        return ERROR_FAIL;
+    }
+    nr = rc;
+    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
+                       (b_info->max_memkb - b_info->target_memkb) +
+                       b_info->u.pv.slack_memkb);
+    if (rc)
+        return ERROR_FAIL;
+
+    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
+
+    if (rc < 0) {
+        errno  = rc;
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
+        uint32_t domid)
+{
+    int rc = 0;
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
+        d_config->b_info.u.pv.e820_host) {
+        rc = libxl__e820_alloc(gc, domid, d_config);
+        if (rc)
+            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
+                      "Failed while collecting E820 with: %d (errno:%d)\n",
+                      rc, errno);
+    }
+    return rc;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zw3-00012R-4F; Thu, 23 Feb 2012 14:46:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zw0-00010O-Uj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330008366!15562002!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32759 invoked from network); 23 Feb 2012 14:46:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183125011"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:59 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Qi; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:47 +0000
Message-ID: <1330008712-17715-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Provide empty implementations of xc_domain_save and xc_domain_restore
when CONFIG_MIGRATE is not set.
Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
x86 specific, introduce xc_hvm_build_arm.c with empty stubs.


Changes in v3:

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;



Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile           |   12 +-
 tools/libxc/xc_dom_arm.c       |   50 ++++
 tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
 tools/libxc/xc_hvm_build_arm.c |   61 +++++
 tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c     |   53 ++++
 6 files changed, 684 insertions(+), 514 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build.c
 create mode 100644 tools/libxc/xc_hvm_build_arm.c
 create mode 100644 tools/libxc/xc_hvm_build_x86.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..02d39a3 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..122d0e8
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,50 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
deleted file mode 100644
index 1fa5658..0000000
--- a/tools/libxc/xc_hvm_build.c
+++ /dev/null
@@ -1,511 +0,0 @@
-/******************************************************************************
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <stddef.h>
-#include <inttypes.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <zlib.h>
-
-#include "xg_private.h"
-#include "xc_private.h"
-
-#include <xen/foreign/x86_32.h>
-#include <xen/foreign/x86_64.h>
-#include <xen/hvm/hvm_info_table.h>
-#include <xen/hvm/params.h>
-#include <xen/hvm/e820.h>
-
-#include <xen/libelf/libelf.h>
-
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
-
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
-{
-    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
-        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
-    uint64_t lowmem_end = mem_size, highmem_end = 0;
-    uint8_t sum;
-    int i;
-
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
-    {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
-    }
-
-    memset(hvm_info_page, 0, PAGE_SIZE);
-
-    /* Fill in the header. */
-    strncpy(hvm_info->signature, "HVM INFO", 8);
-    hvm_info->length = sizeof(struct hvm_info_table);
-
-    /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->apic_mode = 1;
-    hvm_info->nr_vcpus = 1;
-    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
-
-    /* Memory parameters. */
-    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
-    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
-    hvm_info->reserved_mem_pgstart = special_pfn(0);
-
-    /* Finish with the checksum. */
-    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
-        sum += ((uint8_t *)hvm_info)[i];
-    hvm_info->checksum = -sum;
-}
-
-static int loadelfimage(
-    xc_interface *xch,
-    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
-{
-    privcmd_mmap_entry_t *entries = NULL;
-    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
-    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
-    size_t pages = pfn_end - pfn_start;
-    int i, rc = -1;
-
-    /* Map address space for initial elf image. */
-    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-    if ( entries == NULL )
-        goto err;
-
-    for ( i = 0; i < pages; i++ )
-        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
-
-    elf->dest = xc_map_foreign_ranges(
-        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
-        entries, pages);
-    if ( elf->dest == NULL )
-        goto err;
-
-    elf->dest += elf->pstart & (PAGE_SIZE - 1);
-
-    /* Load the initial elf image. */
-    rc = elf_load_binary(elf);
-    if ( rc < 0 )
-        PERROR("Failed to load elf binary\n");
-
-    munmap(elf->dest, pages << PAGE_SHIFT);
-    elf->dest = NULL;
-
- err:
-    free(entries);
-
-    return rc;
-}
-
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
-{
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
-        return 0;
-    else
-        return 1;
-}
-
-static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
-                       char *image, unsigned long image_size)
-{
-    xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
-    unsigned long entry_eip, cur_pages, cur_pfn;
-    void *hvm_info_page;
-    uint32_t *ident_pt;
-    struct elf_binary elf;
-    uint64_t v_start, v_end;
-    int rc;
-    xen_capabilities_info_t caps;
-    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
-        stat_1gb_pages = 0;
-    int pod_mode = 0;
-
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
-        pod_mode = 1;
-
-    memset(&elf, 0, sizeof(elf));
-    if ( elf_init(&elf, image, image_size) != 0 )
-        goto error_out;
-
-    xc_elf_set_logfile(xch, &elf, 1);
-
-    elf_parse_binary(&elf);
-    v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
-
-    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
-    {
-        PERROR("Could not get Xen capabilities");
-        goto error_out;
-    }
-
-    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
-            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
-            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
-            "  ENTRY ADDRESS: %016"PRIx64"\n",
-            elf.pstart, elf.pend,
-            v_start, v_end,
-            elf_uval(&elf, elf.ehdr, e_entry));
-
-    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
-    {
-        PERROR("Could not allocate memory.");
-        goto error_out;
-    }
-
-    for ( i = 0; i < nr_pages; i++ )
-        page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
-
-    /*
-     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
-     *
-     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
-     * pages if 1GB allocation fails. 4KB pages will be used eventually if
-     * both fail.
-     * 
-     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
-     * ensure that we can be preempted and hence dom0 remains responsive.
-     */
-    rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
-    cur_pages = 0xc0;
-    stat_normal_pages = 0xc0;
-    while ( (rc == 0) && (nr_pages > cur_pages) )
-    {
-        /* Clip count to maximum 1GB extent. */
-        unsigned long count = nr_pages - cur_pages;
-        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-        if ( count > max_pages )
-            count = max_pages;
-
-        cur_pfn = page_array[cur_pages];
-
-        /* Take care the corner cases of super page tails */
-        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
-            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
-        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-                  (count > SUPERPAGE_1GB_NR_PFNS) )
-            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-        /* Attemp to allocate 1GB super page. Because in each pass we only
-         * allocate at most 1GB, we don't have to clip super page boundaries.
-         */
-        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
-             /* Check if there exists MMIO hole in the 1GB memory range */
-             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
-        {
-            long done;
-            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
-            xen_pfn_t sp_extents[nr_extents];
-
-            for ( i = 0; i < nr_extents; i++ )
-                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
-
-            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
-                                              pod_mode ? XENMEMF_populate_on_demand : 0,
-                                              sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
-        }
-
-        if ( count != 0 )
-        {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
-            if ( count > max_pages )
-                count = max_pages;
-            
-            /* Clip partial superpage extents to superpage boundaries. */
-            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
-                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
-            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                      (count > SUPERPAGE_2MB_NR_PFNS) )
-                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-            /* Attempt to allocate superpage extents. */
-            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
-            {
-                long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
-                xen_pfn_t sp_extents[nr_extents];
-
-                for ( i = 0; i < nr_extents; i++ )
-                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
-
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
-                                                  sp_extents);
-
-                if ( done > 0 )
-                {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
-                    cur_pages += done;
-                    count -= done;
-                }
-            }
-        }
-
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, 0, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
-        }
-    }
-
-    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
-     * adjust the PoD cache size so that domain tot_pages will be
-     * target_pages - 0x20 after this call. */
-    if ( pod_mode )
-        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
-                                      NULL, NULL, NULL);
-
-    if ( rc != 0 )
-    {
-        PERROR("Could not allocate memory for HVM guest.");
-        goto error_out;
-    }
-
-    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
-            "  4KB PAGES: 0x%016lx\n"
-            "  2MB PAGES: 0x%016lx\n"
-            "  1GB PAGES: 0x%016lx\n",
-            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
-    
-    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
-        goto error_out;
-
-    if ( (hvm_info_page = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              HVM_INFO_PFN)) == NULL )
-        goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
-    munmap(hvm_info_page, PAGE_SIZE);
-
-    /* Allocate and clear special pages. */
-    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-    {
-        xen_pfn_t pfn = special_pfn(i);
-        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
-        if ( rc != 0 )
-        {
-            PERROR("Could not allocate %d'th special page.", i);
-            goto error_out;
-        }
-        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
-            goto error_out;
-    }
-
-    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
-                     special_pfn(SPECIALPAGE_XENSTORE));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
-                     special_pfn(SPECIALPAGE_BUFIOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
-                     special_pfn(SPECIALPAGE_IOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
-                     special_pfn(SPECIALPAGE_CONSOLE));
-
-    /*
-     * Identity-map page table is required for running with CR0.PG=0 when
-     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
-     */
-    if ( (ident_pt = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
-        goto error_out;
-    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
-        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
-                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-    munmap(ident_pt, PAGE_SIZE);
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
-                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
-
-    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
-    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
-    if ( entry_eip != 0 )
-    {
-        char *page0 = xc_map_foreign_range(
-            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
-        if ( page0 == NULL )
-            goto error_out;
-        page0[0] = 0xe9;
-        *(uint32_t *)&page0[1] = entry_eip - 5;
-        munmap(page0, PAGE_SIZE);
-    }
-
-    free(page_array);
-    return 0;
-
- error_out:
-    free(page_array);
-    return -1;
-}
-
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
-/* xc_hvm_build:
- * Create a domain for a virtualized Linux, using files/filenames.
- */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_target_mem: 
- * Create a domain for a pre-ballooned virtualized Linux, using
- * files/filenames.  If target < memsize, domain is created with
- * memsize pages marked populate-on-demand, 
- * calculating pod cache size based on target.
- * If target == memsize, pages are populated normally.
- */
-int xc_hvm_build_target_mem(xc_interface *xch,
-                           uint32_t domid,
-                           int memsize,
-                           int target,
-                           const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
new file mode 100644
index 0000000..010ebdb
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_arm.c
@@ -0,0 +1,61 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
new file mode 100644
index 0000000..1fa5658
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -0,0 +1,511 @@
+/******************************************************************************
+ * xc_hvm_build.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stddef.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <zlib.h>
+
+#include "xg_private.h"
+#include "xc_private.h"
+
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/params.h>
+#include <xen/hvm/e820.h>
+
+#include <xen/libelf/libelf.h>
+
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define SPECIALPAGE_BUFIOREQ 0
+#define SPECIALPAGE_XENSTORE 1
+#define SPECIALPAGE_IOREQ    2
+#define SPECIALPAGE_IDENT_PT 3
+#define SPECIALPAGE_CONSOLE  4
+#define NR_SPECIAL_PAGES     5
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+{
+    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+    uint64_t lowmem_end = mem_size, highmem_end = 0;
+    uint8_t sum;
+    int i;
+
+    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    {
+        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
+        lowmem_end = HVM_BELOW_4G_RAM_END;
+    }
+
+    memset(hvm_info_page, 0, PAGE_SIZE);
+
+    /* Fill in the header. */
+    strncpy(hvm_info->signature, "HVM INFO", 8);
+    hvm_info->length = sizeof(struct hvm_info_table);
+
+    /* Sensible defaults: these can be overridden by the caller. */
+    hvm_info->apic_mode = 1;
+    hvm_info->nr_vcpus = 1;
+    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+    /* Memory parameters. */
+    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
+    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
+    hvm_info->reserved_mem_pgstart = special_pfn(0);
+
+    /* Finish with the checksum. */
+    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+        sum += ((uint8_t *)hvm_info)[i];
+    hvm_info->checksum = -sum;
+}
+
+static int loadelfimage(
+    xc_interface *xch,
+    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
+{
+    privcmd_mmap_entry_t *entries = NULL;
+    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
+    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
+    size_t pages = pfn_end - pfn_start;
+    int i, rc = -1;
+
+    /* Map address space for initial elf image. */
+    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
+    if ( entries == NULL )
+        goto err;
+
+    for ( i = 0; i < pages; i++ )
+        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
+
+    elf->dest = xc_map_foreign_ranges(
+        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
+        entries, pages);
+    if ( elf->dest == NULL )
+        goto err;
+
+    elf->dest += elf->pstart & (PAGE_SIZE - 1);
+
+    /* Load the initial elf image. */
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
+
+    munmap(elf->dest, pages << PAGE_SHIFT);
+    elf->dest = NULL;
+
+ err:
+    free(entries);
+
+    return rc;
+}
+
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize)
+{
+    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
+         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+        return 0;
+    else
+        return 1;
+}
+
+static int setup_guest(xc_interface *xch,
+                       uint32_t dom, int memsize, int target,
+                       char *image, unsigned long image_size)
+{
+    xen_pfn_t *page_array = NULL;
+    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
+    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long entry_eip, cur_pages, cur_pfn;
+    void *hvm_info_page;
+    uint32_t *ident_pt;
+    struct elf_binary elf;
+    uint64_t v_start, v_end;
+    int rc;
+    xen_capabilities_info_t caps;
+    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
+        stat_1gb_pages = 0;
+    int pod_mode = 0;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( memsize < 2 || target < 2 )
+        goto error_out;
+
+    if ( memsize > target )
+        pod_mode = 1;
+
+    memset(&elf, 0, sizeof(elf));
+    if ( elf_init(&elf, image, image_size) != 0 )
+        goto error_out;
+
+    xc_elf_set_logfile(xch, &elf, 1);
+
+    elf_parse_binary(&elf);
+    v_start = 0;
+    v_end = (unsigned long long)memsize << 20;
+
+    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+    {
+        PERROR("Could not get Xen capabilities");
+        goto error_out;
+    }
+
+    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
+            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
+            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
+            "  ENTRY ADDRESS: %016"PRIx64"\n",
+            elf.pstart, elf.pend,
+            v_start, v_end,
+            elf_uval(&elf, elf.ehdr, e_entry));
+
+    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
+    {
+        PERROR("Could not allocate memory.");
+        goto error_out;
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+        page_array[i] = i;
+    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+
+    /*
+     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
+     *
+     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+     * pages if 1GB allocation fails. 4KB pages will be used eventually if
+     * both fail.
+     * 
+     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
+     * ensure that we can be preempted and hence dom0 remains responsive.
+     */
+    rc = xc_domain_populate_physmap_exact(
+        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
+    cur_pages = 0xc0;
+    stat_normal_pages = 0xc0;
+    while ( (rc == 0) && (nr_pages > cur_pages) )
+    {
+        /* Clip count to maximum 1GB extent. */
+        unsigned long count = nr_pages - cur_pages;
+        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+        if ( count > max_pages )
+            count = max_pages;
+
+        cur_pfn = page_array[cur_pages];
+
+        /* Take care the corner cases of super page tails */
+        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
+            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
+        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+                  (count > SUPERPAGE_1GB_NR_PFNS) )
+            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+        /* Attemp to allocate 1GB super page. Because in each pass we only
+         * allocate at most 1GB, we don't have to clip super page boundaries.
+         */
+        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
+             /* Check if there exists MMIO hole in the 1GB memory range */
+             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+        {
+            long done;
+            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
+            xen_pfn_t sp_extents[nr_extents];
+
+            for ( i = 0; i < nr_extents; i++ )
+                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
+
+            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                              pod_mode ? XENMEMF_populate_on_demand : 0,
+                                              sp_extents);
+
+            if ( done > 0 )
+            {
+                stat_1gb_pages += done;
+                done <<= SUPERPAGE_1GB_SHIFT;
+                cur_pages += done;
+                count -= done;
+            }
+        }
+
+        if ( count != 0 )
+        {
+            /* Clip count to maximum 8MB extent. */
+            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            if ( count > max_pages )
+                count = max_pages;
+            
+            /* Clip partial superpage extents to superpage boundaries. */
+            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
+                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
+            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                      (count > SUPERPAGE_2MB_NR_PFNS) )
+                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+            /* Attempt to allocate superpage extents. */
+            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+            {
+                long done;
+                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                xen_pfn_t sp_extents[nr_extents];
+
+                for ( i = 0; i < nr_extents; i++ )
+                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
+                                                  sp_extents);
+
+                if ( done > 0 )
+                {
+                    stat_2mb_pages += done;
+                    done <<= SUPERPAGE_2MB_SHIFT;
+                    cur_pages += done;
+                    count -= done;
+                }
+            }
+        }
+
+        /* Fall back to 4kB extents. */
+        if ( count != 0 )
+        {
+            rc = xc_domain_populate_physmap_exact(
+                xch, dom, count, 0, 0, &page_array[cur_pages]);
+            cur_pages += count;
+            stat_normal_pages += count;
+        }
+    }
+
+    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
+     * adjust the PoD cache size so that domain tot_pages will be
+     * target_pages - 0x20 after this call. */
+    if ( pod_mode )
+        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
+                                      NULL, NULL, NULL);
+
+    if ( rc != 0 )
+    {
+        PERROR("Could not allocate memory for HVM guest.");
+        goto error_out;
+    }
+
+    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+            "  4KB PAGES: 0x%016lx\n"
+            "  2MB PAGES: 0x%016lx\n"
+            "  1GB PAGES: 0x%016lx\n",
+            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+    
+    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
+        goto error_out;
+
+    if ( (hvm_info_page = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              HVM_INFO_PFN)) == NULL )
+        goto error_out;
+    build_hvm_info(hvm_info_page, v_end);
+    munmap(hvm_info_page, PAGE_SIZE);
+
+    /* Allocate and clear special pages. */
+    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+    {
+        xen_pfn_t pfn = special_pfn(i);
+        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Could not allocate %d'th special page.", i);
+            goto error_out;
+        }
+        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+            goto error_out;
+    }
+
+    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
+                     special_pfn(SPECIALPAGE_XENSTORE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
+                     special_pfn(SPECIALPAGE_BUFIOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
+                     special_pfn(SPECIALPAGE_IOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
+                     special_pfn(SPECIALPAGE_CONSOLE));
+
+    /*
+     * Identity-map page table is required for running with CR0.PG=0 when
+     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
+     */
+    if ( (ident_pt = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
+        goto error_out;
+    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
+        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+    munmap(ident_pt, PAGE_SIZE);
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
+                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
+
+    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
+    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
+    if ( entry_eip != 0 )
+    {
+        char *page0 = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+        if ( page0 == NULL )
+            goto error_out;
+        page0[0] = 0xe9;
+        *(uint32_t *)&page0[1] = entry_eip - 5;
+        munmap(page0, PAGE_SIZE);
+    }
+
+    free(page_array);
+    return 0;
+
+ error_out:
+    free(page_array);
+    return -1;
+}
+
+static int xc_hvm_build_internal(xc_interface *xch,
+                                 uint32_t domid,
+                                 int memsize,
+                                 int target,
+                                 char *image,
+                                 unsigned long image_size)
+{
+    if ( (image == NULL) || (image_size == 0) )
+    {
+        ERROR("Image required");
+        return -1;
+    }
+
+    return setup_guest(xch, domid, memsize, target, image, image_size);
+}
+
+/* xc_hvm_build:
+ * Create a domain for a virtualized Linux, using files/filenames.
+ */
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_target_mem: 
+ * Create a domain for a pre-ballooned virtualized Linux, using
+ * files/filenames.  If target < memsize, domain is created with
+ * memsize pages marked populate-on-demand, 
+ * calculating pod cache size based on target.
+ * If target == memsize, pages are populated normally.
+ */
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_mem:
+ * Create a domain for a virtualized Linux, using memory buffers.
+ */
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    int           sts;
+    unsigned long img_len;
+    char         *img;
+
+    /* Validate that there is a kernel buffer */
+
+    if ( (image_buffer == NULL) || (image_size == 0) )
+    {
+        ERROR("kernel image buffer not present");
+        return -1;
+    }
+
+    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
+    if ( img == NULL )
+    {
+        ERROR("unable to inflate ram disk buffer");
+        return -1;
+    }
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
+                                img, img_len);
+
+    /* xc_inflate_buffer may return the original buffer pointer (for
+       for already inflated buffers), so exercise some care in freeing */
+
+    if ( (img != NULL) && (img != image_buffer) )
+        free(img);
+
+    return sts;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..e734d73
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,53 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zw3-00012R-4F; Thu, 23 Feb 2012 14:46:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zw0-00010O-Uj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330008366!15562002!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32759 invoked from network); 23 Feb 2012 14:46:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183125011"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:59 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-Qi; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:47 +0000
Message-ID: <1330008712-17715-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 an empty implementation of the arch specific ARM functions in
xc_dom_arm.c.
Provide empty implementations of xc_domain_save and xc_domain_restore
when CONFIG_MIGRATE is not set.
Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
x86 specific, introduce xc_hvm_build_arm.c with empty stubs.


Changes in v3:

- rename xc_hvm_build.c to xc_hvm_build_x86.c;

- remove xc_nohvm, introduce xc_hvm_build_arm.c instead;



Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/Makefile           |   12 +-
 tools/libxc/xc_dom_arm.c       |   50 ++++
 tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
 tools/libxc/xc_hvm_build_arm.c |   61 +++++
 tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_nomigrate.c     |   53 ++++
 6 files changed, 684 insertions(+), 514 deletions(-)
 create mode 100644 tools/libxc/xc_dom_arm.c
 delete mode 100644 tools/libxc/xc_hvm_build.c
 create mode 100644 tools/libxc/xc_hvm_build_arm.c
 create mode 100644 tools/libxc/xc_hvm_build_x86.c
 create mode 100644 tools/libxc/xc_nomigrate.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index f2e1ba7..02d39a3 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
-GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
-GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
+ifeq ($(CONFIG_MIGRATE),y)
+GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
+GUEST_SRCS-y += xc_offline_page.c xc_compression.c
+else
+GUEST_SRCS-y += xc_nomigrate.c
+endif
 
 vpath %.c ../../xen/common/libelf
 CFLAGS += -I../../xen/common/libelf
@@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
 GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
+GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
new file mode 100644
index 0000000..122d0e8
--- /dev/null
+++ b/tools/libxc/xc_dom_arm.c
@@ -0,0 +1,50 @@
+/*
+ * Xen domain builder -- ARM
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+#include <inttypes.h>
+#include <xen/xen.h>
+#include "xg_private.h"
+#include "xc_dom.h"
+
+int arch_setup_meminit(struct xc_dom_image *dom)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int arch_setup_bootearly(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+
+int arch_setup_bootlate(struct xc_dom_image *dom)
+{
+    DOMPRINTF("%s: doing nothing", __FUNCTION__);
+    return 0;
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
deleted file mode 100644
index 1fa5658..0000000
--- a/tools/libxc/xc_hvm_build.c
+++ /dev/null
@@ -1,511 +0,0 @@
-/******************************************************************************
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <stddef.h>
-#include <inttypes.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <zlib.h>
-
-#include "xg_private.h"
-#include "xc_private.h"
-
-#include <xen/foreign/x86_32.h>
-#include <xen/foreign/x86_64.h>
-#include <xen/hvm/hvm_info_table.h>
-#include <xen/hvm/params.h>
-#include <xen/hvm/e820.h>
-
-#include <xen/libelf/libelf.h>
-
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_BUFIOREQ 0
-#define SPECIALPAGE_XENSTORE 1
-#define SPECIALPAGE_IOREQ    2
-#define SPECIALPAGE_IDENT_PT 3
-#define SPECIALPAGE_CONSOLE  4
-#define NR_SPECIAL_PAGES     5
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
-
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
-{
-    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
-        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
-    uint64_t lowmem_end = mem_size, highmem_end = 0;
-    uint8_t sum;
-    int i;
-
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
-    {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
-    }
-
-    memset(hvm_info_page, 0, PAGE_SIZE);
-
-    /* Fill in the header. */
-    strncpy(hvm_info->signature, "HVM INFO", 8);
-    hvm_info->length = sizeof(struct hvm_info_table);
-
-    /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->apic_mode = 1;
-    hvm_info->nr_vcpus = 1;
-    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
-
-    /* Memory parameters. */
-    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
-    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
-    hvm_info->reserved_mem_pgstart = special_pfn(0);
-
-    /* Finish with the checksum. */
-    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
-        sum += ((uint8_t *)hvm_info)[i];
-    hvm_info->checksum = -sum;
-}
-
-static int loadelfimage(
-    xc_interface *xch,
-    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
-{
-    privcmd_mmap_entry_t *entries = NULL;
-    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
-    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
-    size_t pages = pfn_end - pfn_start;
-    int i, rc = -1;
-
-    /* Map address space for initial elf image. */
-    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-    if ( entries == NULL )
-        goto err;
-
-    for ( i = 0; i < pages; i++ )
-        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
-
-    elf->dest = xc_map_foreign_ranges(
-        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
-        entries, pages);
-    if ( elf->dest == NULL )
-        goto err;
-
-    elf->dest += elf->pstart & (PAGE_SIZE - 1);
-
-    /* Load the initial elf image. */
-    rc = elf_load_binary(elf);
-    if ( rc < 0 )
-        PERROR("Failed to load elf binary\n");
-
-    munmap(elf->dest, pages << PAGE_SHIFT);
-    elf->dest = NULL;
-
- err:
-    free(entries);
-
-    return rc;
-}
-
-/*
- * Check whether there exists mmio hole in the specified memory range.
- * Returns 1 if exists, else returns 0.
- */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
-{
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
-        return 0;
-    else
-        return 1;
-}
-
-static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
-                       char *image, unsigned long image_size)
-{
-    xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
-    unsigned long entry_eip, cur_pages, cur_pfn;
-    void *hvm_info_page;
-    uint32_t *ident_pt;
-    struct elf_binary elf;
-    uint64_t v_start, v_end;
-    int rc;
-    xen_capabilities_info_t caps;
-    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
-        stat_1gb_pages = 0;
-    int pod_mode = 0;
-
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
-        pod_mode = 1;
-
-    memset(&elf, 0, sizeof(elf));
-    if ( elf_init(&elf, image, image_size) != 0 )
-        goto error_out;
-
-    xc_elf_set_logfile(xch, &elf, 1);
-
-    elf_parse_binary(&elf);
-    v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
-
-    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
-    {
-        PERROR("Could not get Xen capabilities");
-        goto error_out;
-    }
-
-    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
-            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
-            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
-            "  ENTRY ADDRESS: %016"PRIx64"\n",
-            elf.pstart, elf.pend,
-            v_start, v_end,
-            elf_uval(&elf, elf.ehdr, e_entry));
-
-    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
-    {
-        PERROR("Could not allocate memory.");
-        goto error_out;
-    }
-
-    for ( i = 0; i < nr_pages; i++ )
-        page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
-
-    /*
-     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
-     *
-     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
-     * pages if 1GB allocation fails. 4KB pages will be used eventually if
-     * both fail.
-     * 
-     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
-     * ensure that we can be preempted and hence dom0 remains responsive.
-     */
-    rc = xc_domain_populate_physmap_exact(
-        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
-    cur_pages = 0xc0;
-    stat_normal_pages = 0xc0;
-    while ( (rc == 0) && (nr_pages > cur_pages) )
-    {
-        /* Clip count to maximum 1GB extent. */
-        unsigned long count = nr_pages - cur_pages;
-        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-        if ( count > max_pages )
-            count = max_pages;
-
-        cur_pfn = page_array[cur_pages];
-
-        /* Take care the corner cases of super page tails */
-        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
-            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
-        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
-                  (count > SUPERPAGE_1GB_NR_PFNS) )
-            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-        /* Attemp to allocate 1GB super page. Because in each pass we only
-         * allocate at most 1GB, we don't have to clip super page boundaries.
-         */
-        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
-             /* Check if there exists MMIO hole in the 1GB memory range */
-             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
-        {
-            long done;
-            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
-            xen_pfn_t sp_extents[nr_extents];
-
-            for ( i = 0; i < nr_extents; i++ )
-                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
-
-            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
-                                              pod_mode ? XENMEMF_populate_on_demand : 0,
-                                              sp_extents);
-
-            if ( done > 0 )
-            {
-                stat_1gb_pages += done;
-                done <<= SUPERPAGE_1GB_SHIFT;
-                cur_pages += done;
-                count -= done;
-            }
-        }
-
-        if ( count != 0 )
-        {
-            /* Clip count to maximum 8MB extent. */
-            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
-            if ( count > max_pages )
-                count = max_pages;
-            
-            /* Clip partial superpage extents to superpage boundaries. */
-            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
-                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
-            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
-                      (count > SUPERPAGE_2MB_NR_PFNS) )
-                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-            /* Attempt to allocate superpage extents. */
-            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
-            {
-                long done;
-                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
-                xen_pfn_t sp_extents[nr_extents];
-
-                for ( i = 0; i < nr_extents; i++ )
-                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
-
-                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
-                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
-                                                  sp_extents);
-
-                if ( done > 0 )
-                {
-                    stat_2mb_pages += done;
-                    done <<= SUPERPAGE_2MB_SHIFT;
-                    cur_pages += done;
-                    count -= done;
-                }
-            }
-        }
-
-        /* Fall back to 4kB extents. */
-        if ( count != 0 )
-        {
-            rc = xc_domain_populate_physmap_exact(
-                xch, dom, count, 0, 0, &page_array[cur_pages]);
-            cur_pages += count;
-            stat_normal_pages += count;
-        }
-    }
-
-    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
-     * adjust the PoD cache size so that domain tot_pages will be
-     * target_pages - 0x20 after this call. */
-    if ( pod_mode )
-        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
-                                      NULL, NULL, NULL);
-
-    if ( rc != 0 )
-    {
-        PERROR("Could not allocate memory for HVM guest.");
-        goto error_out;
-    }
-
-    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
-            "  4KB PAGES: 0x%016lx\n"
-            "  2MB PAGES: 0x%016lx\n"
-            "  1GB PAGES: 0x%016lx\n",
-            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
-    
-    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
-        goto error_out;
-
-    if ( (hvm_info_page = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              HVM_INFO_PFN)) == NULL )
-        goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
-    munmap(hvm_info_page, PAGE_SIZE);
-
-    /* Allocate and clear special pages. */
-    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
-    {
-        xen_pfn_t pfn = special_pfn(i);
-        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
-        if ( rc != 0 )
-        {
-            PERROR("Could not allocate %d'th special page.", i);
-            goto error_out;
-        }
-        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
-            goto error_out;
-    }
-
-    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
-                     special_pfn(SPECIALPAGE_XENSTORE));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
-                     special_pfn(SPECIALPAGE_BUFIOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
-                     special_pfn(SPECIALPAGE_IOREQ));
-    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
-                     special_pfn(SPECIALPAGE_CONSOLE));
-
-    /*
-     * Identity-map page table is required for running with CR0.PG=0 when
-     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
-     */
-    if ( (ident_pt = xc_map_foreign_range(
-              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
-              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
-        goto error_out;
-    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
-        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
-                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
-    munmap(ident_pt, PAGE_SIZE);
-    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
-                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
-
-    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
-    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
-    if ( entry_eip != 0 )
-    {
-        char *page0 = xc_map_foreign_range(
-            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
-        if ( page0 == NULL )
-            goto error_out;
-        page0[0] = 0xe9;
-        *(uint32_t *)&page0[1] = entry_eip - 5;
-        munmap(page0, PAGE_SIZE);
-    }
-
-    free(page_array);
-    return 0;
-
- error_out:
-    free(page_array);
-    return -1;
-}
-
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
-/* xc_hvm_build:
- * Create a domain for a virtualized Linux, using files/filenames.
- */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_target_mem: 
- * Create a domain for a pre-ballooned virtualized Linux, using
- * files/filenames.  If target < memsize, domain is created with
- * memsize pages marked populate-on-demand, 
- * calculating pod cache size based on target.
- * If target == memsize, pages are populated normally.
- */
-int xc_hvm_build_target_mem(xc_interface *xch,
-                           uint32_t domid,
-                           int memsize,
-                           int target,
-                           const char *image_name)
-{
-    char *image;
-    int  sts;
-    unsigned long image_size;
-
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * tab-width: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
new file mode 100644
index 0000000..010ebdb
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_arm.c
@@ -0,0 +1,61 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
new file mode 100644
index 0000000..1fa5658
--- /dev/null
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -0,0 +1,511 @@
+/******************************************************************************
+ * xc_hvm_build.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stddef.h>
+#include <inttypes.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <zlib.h>
+
+#include "xg_private.h"
+#include "xc_private.h"
+
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/params.h>
+#include <xen/hvm/e820.h>
+
+#include <xen/libelf/libelf.h>
+
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
+#define SPECIALPAGE_BUFIOREQ 0
+#define SPECIALPAGE_XENSTORE 1
+#define SPECIALPAGE_IOREQ    2
+#define SPECIALPAGE_IDENT_PT 3
+#define SPECIALPAGE_CONSOLE  4
+#define NR_SPECIAL_PAGES     5
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+{
+    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+    uint64_t lowmem_end = mem_size, highmem_end = 0;
+    uint8_t sum;
+    int i;
+
+    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    {
+        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
+        lowmem_end = HVM_BELOW_4G_RAM_END;
+    }
+
+    memset(hvm_info_page, 0, PAGE_SIZE);
+
+    /* Fill in the header. */
+    strncpy(hvm_info->signature, "HVM INFO", 8);
+    hvm_info->length = sizeof(struct hvm_info_table);
+
+    /* Sensible defaults: these can be overridden by the caller. */
+    hvm_info->apic_mode = 1;
+    hvm_info->nr_vcpus = 1;
+    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
+
+    /* Memory parameters. */
+    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
+    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
+    hvm_info->reserved_mem_pgstart = special_pfn(0);
+
+    /* Finish with the checksum. */
+    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
+        sum += ((uint8_t *)hvm_info)[i];
+    hvm_info->checksum = -sum;
+}
+
+static int loadelfimage(
+    xc_interface *xch,
+    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
+{
+    privcmd_mmap_entry_t *entries = NULL;
+    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
+    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
+    size_t pages = pfn_end - pfn_start;
+    int i, rc = -1;
+
+    /* Map address space for initial elf image. */
+    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
+    if ( entries == NULL )
+        goto err;
+
+    for ( i = 0; i < pages; i++ )
+        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
+
+    elf->dest = xc_map_foreign_ranges(
+        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
+        entries, pages);
+    if ( elf->dest == NULL )
+        goto err;
+
+    elf->dest += elf->pstart & (PAGE_SIZE - 1);
+
+    /* Load the initial elf image. */
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
+
+    munmap(elf->dest, pages << PAGE_SHIFT);
+    elf->dest = NULL;
+
+ err:
+    free(entries);
+
+    return rc;
+}
+
+/*
+ * Check whether there exists mmio hole in the specified memory range.
+ * Returns 1 if exists, else returns 0.
+ */
+static int check_mmio_hole(uint64_t start, uint64_t memsize)
+{
+    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
+         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+        return 0;
+    else
+        return 1;
+}
+
+static int setup_guest(xc_interface *xch,
+                       uint32_t dom, int memsize, int target,
+                       char *image, unsigned long image_size)
+{
+    xen_pfn_t *page_array = NULL;
+    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
+    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long entry_eip, cur_pages, cur_pfn;
+    void *hvm_info_page;
+    uint32_t *ident_pt;
+    struct elf_binary elf;
+    uint64_t v_start, v_end;
+    int rc;
+    xen_capabilities_info_t caps;
+    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0, 
+        stat_1gb_pages = 0;
+    int pod_mode = 0;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( memsize < 2 || target < 2 )
+        goto error_out;
+
+    if ( memsize > target )
+        pod_mode = 1;
+
+    memset(&elf, 0, sizeof(elf));
+    if ( elf_init(&elf, image, image_size) != 0 )
+        goto error_out;
+
+    xc_elf_set_logfile(xch, &elf, 1);
+
+    elf_parse_binary(&elf);
+    v_start = 0;
+    v_end = (unsigned long long)memsize << 20;
+
+    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+    {
+        PERROR("Could not get Xen capabilities");
+        goto error_out;
+    }
+
+    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
+            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
+            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
+            "  ENTRY ADDRESS: %016"PRIx64"\n",
+            elf.pstart, elf.pend,
+            v_start, v_end,
+            elf_uval(&elf, elf.ehdr, e_entry));
+
+    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
+    {
+        PERROR("Could not allocate memory.");
+        goto error_out;
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+        page_array[i] = i;
+    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+
+    /*
+     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
+     *
+     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+     * pages if 1GB allocation fails. 4KB pages will be used eventually if
+     * both fail.
+     * 
+     * Under 2MB mode, we allocate pages in batches of no more than 8MB to 
+     * ensure that we can be preempted and hence dom0 remains responsive.
+     */
+    rc = xc_domain_populate_physmap_exact(
+        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
+    cur_pages = 0xc0;
+    stat_normal_pages = 0xc0;
+    while ( (rc == 0) && (nr_pages > cur_pages) )
+    {
+        /* Clip count to maximum 1GB extent. */
+        unsigned long count = nr_pages - cur_pages;
+        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+        if ( count > max_pages )
+            count = max_pages;
+
+        cur_pfn = page_array[cur_pages];
+
+        /* Take care the corner cases of super page tails */
+        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
+            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
+        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+                  (count > SUPERPAGE_1GB_NR_PFNS) )
+            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+        /* Attemp to allocate 1GB super page. Because in each pass we only
+         * allocate at most 1GB, we don't have to clip super page boundaries.
+         */
+        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
+             /* Check if there exists MMIO hole in the 1GB memory range */
+             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+        {
+            long done;
+            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
+            xen_pfn_t sp_extents[nr_extents];
+
+            for ( i = 0; i < nr_extents; i++ )
+                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
+
+            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
+                                              pod_mode ? XENMEMF_populate_on_demand : 0,
+                                              sp_extents);
+
+            if ( done > 0 )
+            {
+                stat_1gb_pages += done;
+                done <<= SUPERPAGE_1GB_SHIFT;
+                cur_pages += done;
+                count -= done;
+            }
+        }
+
+        if ( count != 0 )
+        {
+            /* Clip count to maximum 8MB extent. */
+            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
+            if ( count > max_pages )
+                count = max_pages;
+            
+            /* Clip partial superpage extents to superpage boundaries. */
+            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
+                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
+            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+                      (count > SUPERPAGE_2MB_NR_PFNS) )
+                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+            /* Attempt to allocate superpage extents. */
+            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+            {
+                long done;
+                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
+                xen_pfn_t sp_extents[nr_extents];
+
+                for ( i = 0; i < nr_extents; i++ )
+                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+
+                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
+                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
+                                                  sp_extents);
+
+                if ( done > 0 )
+                {
+                    stat_2mb_pages += done;
+                    done <<= SUPERPAGE_2MB_SHIFT;
+                    cur_pages += done;
+                    count -= done;
+                }
+            }
+        }
+
+        /* Fall back to 4kB extents. */
+        if ( count != 0 )
+        {
+            rc = xc_domain_populate_physmap_exact(
+                xch, dom, count, 0, 0, &page_array[cur_pages]);
+            cur_pages += count;
+            stat_normal_pages += count;
+        }
+    }
+
+    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
+     * adjust the PoD cache size so that domain tot_pages will be
+     * target_pages - 0x20 after this call. */
+    if ( pod_mode )
+        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
+                                      NULL, NULL, NULL);
+
+    if ( rc != 0 )
+    {
+        PERROR("Could not allocate memory for HVM guest.");
+        goto error_out;
+    }
+
+    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+            "  4KB PAGES: 0x%016lx\n"
+            "  2MB PAGES: 0x%016lx\n"
+            "  1GB PAGES: 0x%016lx\n",
+            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+    
+    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
+        goto error_out;
+
+    if ( (hvm_info_page = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              HVM_INFO_PFN)) == NULL )
+        goto error_out;
+    build_hvm_info(hvm_info_page, v_end);
+    munmap(hvm_info_page, PAGE_SIZE);
+
+    /* Allocate and clear special pages. */
+    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
+    {
+        xen_pfn_t pfn = special_pfn(i);
+        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
+        if ( rc != 0 )
+        {
+            PERROR("Could not allocate %d'th special page.", i);
+            goto error_out;
+        }
+        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+            goto error_out;
+    }
+
+    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
+                     special_pfn(SPECIALPAGE_XENSTORE));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
+                     special_pfn(SPECIALPAGE_BUFIOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
+                     special_pfn(SPECIALPAGE_IOREQ));
+    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
+                     special_pfn(SPECIALPAGE_CONSOLE));
+
+    /*
+     * Identity-map page table is required for running with CR0.PG=0 when
+     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
+     */
+    if ( (ident_pt = xc_map_foreign_range(
+              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
+              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
+        goto error_out;
+    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
+        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+    munmap(ident_pt, PAGE_SIZE);
+    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
+                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
+
+    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
+    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
+    if ( entry_eip != 0 )
+    {
+        char *page0 = xc_map_foreign_range(
+            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
+        if ( page0 == NULL )
+            goto error_out;
+        page0[0] = 0xe9;
+        *(uint32_t *)&page0[1] = entry_eip - 5;
+        munmap(page0, PAGE_SIZE);
+    }
+
+    free(page_array);
+    return 0;
+
+ error_out:
+    free(page_array);
+    return -1;
+}
+
+static int xc_hvm_build_internal(xc_interface *xch,
+                                 uint32_t domid,
+                                 int memsize,
+                                 int target,
+                                 char *image,
+                                 unsigned long image_size)
+{
+    if ( (image == NULL) || (image_size == 0) )
+    {
+        ERROR("Image required");
+        return -1;
+    }
+
+    return setup_guest(xch, domid, memsize, target, image, image_size);
+}
+
+/* xc_hvm_build:
+ * Create a domain for a virtualized Linux, using files/filenames.
+ */
+int xc_hvm_build(xc_interface *xch,
+                 uint32_t domid,
+                 int memsize,
+                 const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_target_mem: 
+ * Create a domain for a pre-ballooned virtualized Linux, using
+ * files/filenames.  If target < memsize, domain is created with
+ * memsize pages marked populate-on-demand, 
+ * calculating pod cache size based on target.
+ * If target == memsize, pages are populated normally.
+ */
+int xc_hvm_build_target_mem(xc_interface *xch,
+                           uint32_t domid,
+                           int memsize,
+                           int target,
+                           const char *image_name)
+{
+    char *image;
+    int  sts;
+    unsigned long image_size;
+
+    if ( (image_name == NULL) ||
+         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+        return -1;
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
+
+    free(image);
+
+    return sts;
+}
+
+/* xc_hvm_build_mem:
+ * Create a domain for a virtualized Linux, using memory buffers.
+ */
+int xc_hvm_build_mem(xc_interface *xch,
+                     uint32_t domid,
+                     int memsize,
+                     const char *image_buffer,
+                     unsigned long image_size)
+{
+    int           sts;
+    unsigned long img_len;
+    char         *img;
+
+    /* Validate that there is a kernel buffer */
+
+    if ( (image_buffer == NULL) || (image_size == 0) )
+    {
+        ERROR("kernel image buffer not present");
+        return -1;
+    }
+
+    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
+    if ( img == NULL )
+    {
+        ERROR("unable to inflate ram disk buffer");
+        return -1;
+    }
+
+    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
+                                img, img_len);
+
+    /* xc_inflate_buffer may return the original buffer pointer (for
+       for already inflated buffers), so exercise some care in freeing */
+
+    if ( (img != NULL) && (img != image_buffer) )
+        free(img);
+
+    return sts;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
new file mode 100644
index 0000000..e734d73
--- /dev/null
+++ b/tools/libxc/xc_nomigrate.c
@@ -0,0 +1,53 @@
+/******************************************************************************
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2011, Citrix Systems
+ */
+
+#include <inttypes.h>
+#include <errno.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
+                   uint32_t max_factor, uint32_t flags,
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_generationid_addr)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
+                      unsigned int store_evtchn, unsigned long *store_mfn,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      int no_incr_generationid,
+                      unsigned long *vm_generationid_addr)
+{
+    errno = ENOSYS;
+    return -1;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zvs-0000z4-W8; Thu, 23 Feb 2012 14:46:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvr-0000yV-QX
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330008359!14622510!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26926 invoked from network); 23 Feb 2012 14:46:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377445"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-RO; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:48 +0000
Message-ID: <1330008712-17715-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 4/7] arm: compile memshr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0Zvs-0000z4-W8; Thu, 23 Feb 2012 14:46:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvr-0000yV-QX
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330008359!14622510!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26926 invoked from network); 23 Feb 2012 14:46:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22377445"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-RO; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:48 +0000
Message-ID: <1330008712-17715-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 4/7] arm: compile memshr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
---
 tools/memshr/bidir-hash.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
index 6c0dc3d..45d473e 100644
--- a/tools/memshr/bidir-hash.c
+++ b/tools/memshr/bidir-hash.c
@@ -109,6 +109,37 @@ static void      hash_resize(struct __hash *h);
 } while (0)
 static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
 static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
+#elif defined(__arm__)
+static inline void atomic_inc(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
+static inline void atomic_dec(uint32_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, #1\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (*v)
+        : "r" (v)
+        : "cc");
+}
 #else /* __x86__ */
 static inline void atomic_inc(uint32_t *v)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Zw1-00011i-Ah; Thu, 23 Feb 2012 14:46:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvz-0000zm-EK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330008366!15562002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32671 invoked from network); 23 Feb 2012 14:46:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183125007"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-ST; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:50 +0000
Message-ID: <1330008712-17715-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 6/7] arm: compile 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

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_cpuid.c   |   60 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_json.c    |   60 -------------------------------------------
 tools/libxl/libxl_nocpuid.c |    8 +++++-
 4 files changed, 68 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index dcdb9d02..ff7531f 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -333,6 +333,66 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
                      (const char**)(cpuid[i].policy), cpuid_res);
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    libxl_cpuid_policy_list cpuid = *pcpuid;
+    yajl_gen_status s;
+    const char *input_names[2] = { "leaf", "subleaf" };
+    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
+    int i, j;
+
+    /*
+     * Aiming for:
+     * [
+     *     { 'leaf':    'val-eax',
+     *       'subleaf': 'val-ecx',
+     *       'eax':     'filter',
+     *       'ebx':     'filter',
+     *       'ecx':     'filter',
+     *       'edx':     'filter' },
+     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
+     *     ... etc ...
+     * ]
+     */
+
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    if (cpuid == NULL) goto empty;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        s = yajl_gen_map_open(hand);
+        if (s != yajl_gen_status_ok) goto out;
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_integer(hand, cpuid[i].input[j]);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_string(hand,
+                               (const unsigned char *)cpuid[i].policy[j], 32);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+        s = yajl_gen_map_close(hand);
+        if (s != yajl_gen_status_ok) goto out;
+    }
+
+empty:
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index be6ad96..4cbcd57 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,66 +140,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                libxl_cpuid_policy_list *pcpuid)
-{
-    libxl_cpuid_policy_list cpuid = *pcpuid;
-    yajl_gen_status s;
-    const char *input_names[2] = { "leaf", "subleaf" };
-    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
-    int i, j;
-
-    /*
-     * Aiming for:
-     * [
-     *     { 'leaf':    'val-eax',
-     *       'subleaf': 'val-ecx',
-     *       'eax':     'filter',
-     *       'ebx':     'filter',
-     *       'ecx':     'filter',
-     *       'edx':     'filter' },
-     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
-     *     ... etc ...
-     * ]
-     */
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    if (cpuid == NULL) goto empty;
-
-    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-        s = yajl_gen_map_open(hand);
-        if (s != yajl_gen_status_ok) goto out;
-
-        for (j = 0; j < 2; j++) {
-            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
-                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_integer(hand, cpuid[i].input[j]);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-
-        for (j = 0; j < 4; j++) {
-            if (cpuid[i].policy[j] != NULL) {
-                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_string(hand,
-                               (const unsigned char *)cpuid[i].policy[j], 32);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-        s = yajl_gen_map_close(hand);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-
-empty:
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..5f7cb6a 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
@@ -38,6 +38,12 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
 {
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:46:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0Zw1-00011i-Ah; Thu, 23 Feb 2012 14:46:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0Zvz-0000zm-EK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:46:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330008366!15562002!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32671 invoked from network); 23 Feb 2012 14:46:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183125007"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 09:45:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 09:45:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0Zvc-0000E6-ST; Thu, 23 Feb 2012 14:45:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 14:51:50 +0000
Message-ID: <1330008712-17715-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v5 6/7] arm: compile 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

libxl_cpuid_destroy has been renamed to libxl_cpuid_dispose; also cpuid
functions are only available on x86, so ifdef the new cpuid related
function in libxl_json.c.


Changes in v3:

- move libxl_cpuid_policy_list_gen_json to libxl_(no)cpuid.c.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/Makefile        |    1 +
 tools/libxl/libxl_cpuid.c   |   60 +++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_json.c    |   60 -------------------------------------------
 tools/libxl/libxl_nocpuid.c |    8 +++++-
 4 files changed, 68 insertions(+), 61 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..41b6ac4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -36,6 +36,7 @@ LIBXL_OBJS-y += libxl_noblktap2.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index dcdb9d02..ff7531f 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -333,6 +333,66 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
                      (const char**)(cpuid[i].policy), cpuid_res);
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    libxl_cpuid_policy_list cpuid = *pcpuid;
+    yajl_gen_status s;
+    const char *input_names[2] = { "leaf", "subleaf" };
+    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
+    int i, j;
+
+    /*
+     * Aiming for:
+     * [
+     *     { 'leaf':    'val-eax',
+     *       'subleaf': 'val-ecx',
+     *       'eax':     'filter',
+     *       'ebx':     'filter',
+     *       'ecx':     'filter',
+     *       'edx':     'filter' },
+     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
+     *     ... etc ...
+     * ]
+     */
+
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok) goto out;
+
+    if (cpuid == NULL) goto empty;
+
+    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+        s = yajl_gen_map_open(hand);
+        if (s != yajl_gen_status_ok) goto out;
+
+        for (j = 0; j < 2; j++) {
+            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
+                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_integer(hand, cpuid[i].input[j]);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+
+        for (j = 0; j < 4; j++) {
+            if (cpuid[i].policy[j] != NULL) {
+                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
+                if (s != yajl_gen_status_ok) goto out;
+                s = yajl_gen_string(hand,
+                               (const unsigned char *)cpuid[i].policy[j], 32);
+                if (s != yajl_gen_status_ok) goto out;
+            }
+        }
+        s = yajl_gen_map_close(hand);
+        if (s != yajl_gen_status_ok) goto out;
+    }
+
+empty:
+    s = yajl_gen_array_close(hand);
+out:
+    return s;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index be6ad96..4cbcd57 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -140,66 +140,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
-                                libxl_cpuid_policy_list *pcpuid)
-{
-    libxl_cpuid_policy_list cpuid = *pcpuid;
-    yajl_gen_status s;
-    const char *input_names[2] = { "leaf", "subleaf" };
-    const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
-    int i, j;
-
-    /*
-     * Aiming for:
-     * [
-     *     { 'leaf':    'val-eax',
-     *       'subleaf': 'val-ecx',
-     *       'eax':     'filter',
-     *       'ebx':     'filter',
-     *       'ecx':     'filter',
-     *       'edx':     'filter' },
-     *     { 'leaf':    'val-eax', ..., 'eax': 'filter', ... },
-     *     ... etc ...
-     * ]
-     */
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    if (cpuid == NULL) goto empty;
-
-    for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-        s = yajl_gen_map_open(hand);
-        if (s != yajl_gen_status_ok) goto out;
-
-        for (j = 0; j < 2; j++) {
-            if (cpuid[i].input[j] != XEN_CPUID_INPUT_UNUSED) {
-                s = libxl__yajl_gen_asciiz(hand, input_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_integer(hand, cpuid[i].input[j]);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-
-        for (j = 0; j < 4; j++) {
-            if (cpuid[i].policy[j] != NULL) {
-                s = libxl__yajl_gen_asciiz(hand, policy_names[j]);
-                if (s != yajl_gen_status_ok) goto out;
-                s = yajl_gen_string(hand,
-                               (const unsigned char *)cpuid[i].policy[j], 32);
-                if (s != yajl_gen_status_ok) goto out;
-            }
-        }
-        s = yajl_gen_map_close(hand);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-
-empty:
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_string_list_gen_json(yajl_gen hand, libxl_string_list *pl)
 {
     libxl_string_list l = *pl;
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 9e52f8d..5f7cb6a 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -14,7 +14,7 @@
 
 #include "libxl_internal.h"
 
-void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
 {
 }
 
@@ -38,6 +38,12 @@ void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
 {
 }
 
+yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
+                                libxl_cpuid_policy_list *pcpuid)
+{
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:48:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:48: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 1S0Zxt-0001gi-1O; Thu, 23 Feb 2012 14:48: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 1S0Zxr-0001gD-B9
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:48:11 +0000
Received: from [85.158.139.83:8939] by server-3.bemta-5.messagelabs.com id
	44/08-06438-AA1564F4; Thu, 23 Feb 2012 14:48:10 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330008489!16283025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4528 invoked from network); 23 Feb 2012 14:48:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 14:48:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 14:48:09 +0000
Message-Id: <4F4651A7020000780007F749@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 14:48:07 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <attilio.rao@citrix.com>,<Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
In-Reply-To: <4F461276.1030108@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, gbtju85@gmail.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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

>>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>On 23/02/12 10:07, Ian Campbell wrote:
>> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> Can you confirm that you need an OVMF which matches the OS bit-width you
>> are installing. i..e that there is no support for booting a 32 bit EFI
>> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>
>I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
>possibly work.

Native EFI requires bit-matched OS loaders, and I can't see how OVMF would
be able to get around this (but yes, it is theoretically possible, just that I
doubt anyone cared to implement this).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:48:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:48: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 1S0Zxt-0001gi-1O; Thu, 23 Feb 2012 14:48: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 1S0Zxr-0001gD-B9
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:48:11 +0000
Received: from [85.158.139.83:8939] by server-3.bemta-5.messagelabs.com id
	44/08-06438-AA1564F4; Thu, 23 Feb 2012 14:48:10 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330008489!16283025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4528 invoked from network); 23 Feb 2012 14:48:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 14:48:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 14:48:09 +0000
Message-Id: <4F4651A7020000780007F749@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 14:48:07 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <attilio.rao@citrix.com>,<Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
In-Reply-To: <4F461276.1030108@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, gbtju85@gmail.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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

>>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>On 23/02/12 10:07, Ian Campbell wrote:
>> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> Can you confirm that you need an OVMF which matches the OS bit-width you
>> are installing. i..e that there is no support for booting a 32 bit EFI
>> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>
>I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
>possibly work.

Native EFI requires bit-matched OS loaders, and I can't see how OVMF would
be able to get around this (but yes, it is theoretically possible, just that I
doubt anyone cared to implement this).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:50:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZzG-00020s-H8; Thu, 23 Feb 2012 14:49:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0ZzF-0001zQ-Ig
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:49:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330008571!12986377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25306 invoked from network); 23 Feb 2012 14:49:31 -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;
	23 Feb 2012 14:49:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10898572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 14:49:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 14:49:31 +0000
Date: Thu, 23 Feb 2012 14:55:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329483039.3131.74.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231454230.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329483039.3131.74.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: replace list_del and INIT_LIST_HEAD
 with list_del_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 Fri, 17 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Is this safe to take without the other vgic patch?

yep


> > ---
> >  xen/arch/arm/gic.c |    3 +--
> >  1 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 520a400..c34661b 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -501,8 +501,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >                  p->desc->status &= ~IRQ_INPROGRESS;
> >                  GICC[GICC_DIR] = virq;
> >              }
> > -            list_del(&p->link);
> > -            INIT_LIST_HEAD(&p->link);
> > +            list_del_init(&p->link);
> 
> David said:
>         
>         I don't think you need the INIT_LIST_HEAD() here (and even if
>         you did you should use list_del_init()).  You only need to init
>         nodes if you need to test if they are in a list or not.
>         
> But I'm not seeing where we test if a node is in a list or not, have I
> missed it?

the test is in xen/arch/arm/vgic.c:vgic_vcpu_inject_irq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:50:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ZzG-00020s-H8; Thu, 23 Feb 2012 14:49:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0ZzF-0001zQ-Ig
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:49:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330008571!12986377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25306 invoked from network); 23 Feb 2012 14:49:31 -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;
	23 Feb 2012 14:49:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10898572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 14:49:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 14:49:31 +0000
Date: Thu, 23 Feb 2012 14:55:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329483039.3131.74.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231454230.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329314609-31761-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329483039.3131.74.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: replace list_del and INIT_LIST_HEAD
 with list_del_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 Fri, 17 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Is this safe to take without the other vgic patch?

yep


> > ---
> >  xen/arch/arm/gic.c |    3 +--
> >  1 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 520a400..c34661b 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -501,8 +501,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >                  p->desc->status &= ~IRQ_INPROGRESS;
> >                  GICC[GICC_DIR] = virq;
> >              }
> > -            list_del(&p->link);
> > -            INIT_LIST_HEAD(&p->link);
> > +            list_del_init(&p->link);
> 
> David said:
>         
>         I don't think you need the INIT_LIST_HEAD() here (and even if
>         you did you should use list_del_init()).  You only need to init
>         nodes if you need to test if they are in a list or not.
>         
> But I'm not seeing where we test if a node is in a list or not, have I
> missed it?

the test is in xen/arch/arm/vgic.c:vgic_vcpu_inject_irq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0a13-0002LF-2M; Thu, 23 Feb 2012 14:51:29 +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 1S0a11-0002Kb-8f
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:51:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330008627!51302876!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 23 Feb 2012 14:50:28 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:50:28 -0000
Received: by ggnu1 with SMTP id u1so8698759ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 06:51:19 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.217.130 as permitted sender) client-ip=10.50.217.130; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.217.130 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.217.130])
	by 10.50.217.130 with SMTP id oy2mr1997622igc.10.1330008679377
	(num_hops = 1); Thu, 23 Feb 2012 06:51:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=rM16ZzTWry44m3fDO7zC4JjbuEYK1odjrBnIjiPBPQM=;
	b=jWgGbMpHzxZMwlFiHAi/DY1OAi2Aqr/bIBy6gqHEktG+8FoNKRm6FW90gM4zf0hcqS
	Ea0zyiW4jax9IjaoT1MqKmmP2/iDZuXDIY2+sshvqC4D8iu7Yk5IvR8YuSIeFlebRbnI
	awSI39aWZUFTKdcHKObgnibwAI7z7qJDabt0s=
MIME-Version: 1.0
Received: by 10.50.217.130 with SMTP id oy2mr1715660igc.10.1330008679117; Thu,
	23 Feb 2012 06:51:19 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Thu, 23 Feb 2012 06:51:19 -0800 (PST)
In-Reply-To: <0f91ce7b095af8506e94.1329927315@kodo2>
References: <patchbomb.1329927306@kodo2>
	<0f91ce7b095af8506e94.1329927315@kodo2>
Date: Thu, 23 Feb 2012 14:51:19 +0000
X-Google-Sender-Auth: Hwd1YhisTAPsJtg7M-odzN4G-pU
Message-ID: <CAFLBxZY0NNrDa+zV3YoOAfMqnVfnGA1sBOsVJXARo83inKQ0vw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 9 of 9] xl: Implement sched-credit schedule
 parameter command-line 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 22, 2012 at 4:15 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> Add features to the sched-credit interface to allow querying and
> displaying scheduler parameters.
>
> v2:
> =A0- Change function line breaks
> =A0- Pool output deals gracefully with other schedulers
> =A0- Add new parameters, as well as a description of how they
> =A0 interact, to the xl man page

BTW, there was a brief suggestion that rather than sharing the same
command (which requires a big table to explain how the various options
interact), we break out sched-credit into two, possibly three
commands; one of which would read all scheduler information, the other
two which would specifically get or set domain and scheduler-wide
parameters.  Any thoughts on this?

 -G

>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff -r 5600db2bcd0e -r 0f91ce7b095a docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1 Wed Feb 22 16:08:28 2012 +0000
> +++ b/docs/man/xl.pod.1 Wed Feb 22 16:08:28 2012 +0000
> @@ -714,6 +714,53 @@ no upper cap.
>
> =A0Restrict output to domains in the specified cpupool.
>
> +=3Ditem B<-s>, B<--schedparam>
> +
> +Specify to list or set pool-wide scheduler parameters.
> +
> +=3Ditem B<-t TSLICE>, B<--tslice_ms=3DTSLICE>
> +
> +Timeslice tells the scheduler how long to allow VMs to run before
> +pre-empting. =A0The default is 30ms. =A0Valid ranges are 1ms to 1000ms.
> +The length of the timeslice (in ms) must be higher than the length of
> +the ratelimit (see below).
> +
> +=3Ditem B<-r RLIMIT>, B<--ratelimit_us=3DRLIMIT>
> +
> +Ratelimit attempts to limit the number of schedules per second. =A0It
> +sets a minimum amount of time (in microseconds) a VM must run before
> +we will allow a higher-prioirty VM to pre-empt it. =A0The default value
> +is 1000 microseconds (1ms). =A0Valid range is 100 to 500000 (500ms).
> +The ratelimit length must be lower than the timeslice length.
> +
> +=3Dback
> +
> +B<COMBINATION>
> +
> +The following is the effect of combining the above options:
> +
> +=3Dover 4
> +
> +=3Ditem B<E<lt>nothingE<gt>> =A0 =A0 =A0 =A0 =A0 =A0 : List all domain p=
arams and sched params from all pools
> +
> +=3Ditem B<-d [domid]> =A0 =A0 =A0 =A0 =A0 =A0: List domain params for do=
main [domid]
> +
> +=3Ditem B<-d [domid] [params]> =A0 : Set domain params for domain [domid]
> +
> +=3Ditem B<-p [pool]> =A0 =A0 =A0 =A0 =A0 =A0 : list all domains and sche=
d params for [pool]
> +
> +=3Ditem B<-s> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: List sched params=
 for poolid 0
> +
> +=3Ditem B<-s [params]> =A0 =A0 =A0 =A0 =A0 : Set sched params for poolid=
 0
> +
> +=3Ditem B<-p [pool] -s> =A0 =A0 =A0 =A0 =A0: List sched params for [pool]
> +
> +=3Ditem B<-p [pool] -s [params]> : Set sched params for [pool]
> +
> +=3Ditem B<-p [pool] -d>... =A0 =A0 =A0 : Illegal
> +
> +=3Ditem
> +
> =A0=3Dback
>
> =A0=3Ditem B<sched-credit2> [I<OPTIONS>]
> diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c =A0Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c =A0Wed Feb 22 16:08:28 2012 +0000
> @@ -3912,8 +3912,7 @@ int main_sharing(int argc, char **argv)
> =A0 =A0 return 0;
> =A0}
>
> -static int sched_credit_domain_get(
> - =A0 =A0int domid, libxl_sched_credit_domain *scinfo)
> +static int sched_credit_domain_get(int domid, libxl_sched_credit_domain =
*scinfo)
> =A0{
> =A0 =A0 int rc;
>
> @@ -3924,8 +3923,7 @@ static int sched_credit_domain_get(
> =A0 =A0 return rc;
> =A0}
>
> -static int sched_credit_domain_set(
> - =A0 =A0int domid, libxl_sched_credit_domain *scinfo)
> +static int sched_credit_domain_set(int domid, libxl_sched_credit_domain =
*scinfo)
> =A0{
> =A0 =A0 int rc;
>
> @@ -3936,8 +3934,29 @@ static int sched_credit_domain_set(
> =A0 =A0 return rc;
> =A0}
>
> -static int sched_credit_domain_output(
> - =A0 =A0int domid)
> +static int sched_credit_params_set(int poolid, libxl_sched_credit_params=
 *scinfo)
> +{
> + =A0 =A0int rc;
> +
> + =A0 =A0rc =3D libxl_sched_credit_params_set(ctx, poolid, scinfo);
> + =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0fprintf(stderr, "libxl_sched_credit_params_set failed.\n=
");
> +
> + =A0 =A0return rc;
> +}
> +
> +static int sched_credit_params_get(int poolid, libxl_sched_credit_params=
 *scinfo)
> +{
> + =A0 =A0int rc;
> +
> + =A0 =A0rc =3D libxl_sched_credit_params_get(ctx, poolid, scinfo);
> + =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0fprintf(stderr, "libxl_sched_credit_params_get failed.\n=
");
> +
> + =A0 =A0return rc;
> +}
> +
> +static int sched_credit_domain_output(int domid)
> =A0{
> =A0 =A0 char *domname;
> =A0 =A0 libxl_sched_credit_domain scinfo;
> @@ -3960,6 +3979,27 @@ static int sched_credit_domain_output(
> =A0 =A0 return 0;
> =A0}
>
> +static int sched_credit_pool_output(uint32_t poolid)
> +{
> + =A0 =A0libxl_sched_credit_params scparam;
> + =A0 =A0char *poolname;
> + =A0 =A0int rc;
> +
> + =A0 =A0poolname =3D libxl_cpupoolid_to_name(ctx, poolid);
> + =A0 =A0rc =3D sched_credit_params_get(poolid, &scparam);
> + =A0 =A0if (rc) {
> + =A0 =A0 =A0 =A0printf("Cpupool %s: [sched params unavailable]\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 poolname);
> + =A0 =A0} else {
> + =A0 =A0 =A0 =A0printf("Cpupool %s: tslice=3D%dms ratelimit=3D%dus\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 poolname,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 scparam.tslice_ms,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 scparam.ratelimit_us);
> + =A0 =A0}
> + =A0 =A0free(poolname);
> + =A0 =A0return 0;
> +}
> +
> =A0static int sched_credit2_domain_get(
> =A0 =A0 int domid, libxl_sched_credit2_domain *scinfo)
> =A0{
> @@ -4122,25 +4162,41 @@ static int sched_domain_output(uint32_t
> =A0 =A0 return 0;
> =A0}
>
> +/*
> + * <nothing> =A0 =A0 =A0 =A0 =A0 =A0 : List all domain params and sched =
params from all pools
> + * -d [domid] =A0 =A0 =A0 =A0 =A0 =A0: List domain params for domain
> + * -d [domid] [params] =A0 : Set domain params for domain
> + * -p [pool] =A0 =A0 =A0 =A0 =A0 =A0 : list all domains and sched params=
 for pool
> + * -s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: List sched params for poo=
lid 0
> + * -s [params] =A0 =A0 =A0 =A0 =A0 : Set sched params for poolid 0
> + * -p [pool] -s =A0 =A0 =A0 =A0 =A0: List sched params for pool
> + * -p [pool] -s [params] : Set sched params for pool
> + * -p [pool] -d... =A0 =A0 =A0 : Illegal
> + */
> =A0int main_sched_credit(int argc, char **argv)
> =A0{
> =A0 =A0 libxl_sched_credit_domain scinfo;
> =A0 =A0 const char *dom =3D NULL;
> =A0 =A0 const char *cpupool =3D NULL;
> =A0 =A0 int weight =3D 256, cap =3D 0, opt_w =3D 0, opt_c =3D 0;
> + =A0 =A0int opt_s =3D 0;
> + =A0 =A0int tslice =3D 0, opt_t =3D 0, ratelimit =3D 0, opt_r =3D 0;
> =A0 =A0 int opt, rc;
> =A0 =A0 int option_index =3D 0;
> =A0 =A0 static struct option long_options[] =3D {
> =A0 =A0 =A0 =A0 {"domain", 1, 0, 'd'},
> =A0 =A0 =A0 =A0 {"weight", 1, 0, 'w'},
> =A0 =A0 =A0 =A0 {"cap", 1, 0, 'c'},
> + =A0 =A0 =A0 =A0{"schedparam", 0, 0, 's'},
> + =A0 =A0 =A0 =A0{"tslice_ms", 1, 0, 't'},
> + =A0 =A0 =A0 =A0{"ratelimit_us", 1, 0, 'r'},
> =A0 =A0 =A0 =A0 {"cpupool", 1, 0, 'p'},
> =A0 =A0 =A0 =A0 {"help", 0, 0, 'h'},
> =A0 =A0 =A0 =A0 {0, 0, 0, 0}
> =A0 =A0 };
>
> =A0 =A0 while (1) {
> - =A0 =A0 =A0 =A0opt =3D getopt_long(argc, argv, "d:w:c:p:h", long_option=
s,
> + =A0 =A0 =A0 =A0opt =3D getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_o=
ptions,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &option_index);
> =A0 =A0 =A0 =A0 if (opt =3D=3D -1)
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> @@ -4158,6 +4214,17 @@ int main_sched_credit(int argc, char **a
> =A0 =A0 =A0 =A0 =A0 =A0 cap =3D strtol(optarg, NULL, 10);
> =A0 =A0 =A0 =A0 =A0 =A0 opt_c =3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 =A0case 't':
> + =A0 =A0 =A0 =A0 =A0 =A0tslice =3D strtol(optarg, NULL, 10);
> + =A0 =A0 =A0 =A0 =A0 =A0opt_t =3D 1;
> + =A0 =A0 =A0 =A0 =A0 =A0break;
> + =A0 =A0 =A0 =A0case 'r':
> + =A0 =A0 =A0 =A0 =A0 =A0ratelimit =3D strtol(optarg, NULL, 10);
> + =A0 =A0 =A0 =A0 =A0 =A0opt_r =3D 1;
> + =A0 =A0 =A0 =A0 =A0 =A0break;
> + =A0 =A0 =A0 =A0case 's':
> + =A0 =A0 =A0 =A0 =A0 =A0opt_s =3D 1;
> + =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0 case 'p':
> =A0 =A0 =A0 =A0 =A0 =A0 cpupool =3D optarg;
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> @@ -4167,20 +4234,54 @@ int main_sched_credit(int argc, char **a
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> - =A0 =A0if (cpupool && (dom || opt_w || opt_c)) {
> - =A0 =A0 =A0 =A0fprintf(stderr, "Specifying a cpupool is not allowed wit=
h other "
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"options.\n");
> + =A0 =A0if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
> + =A0 =A0 =A0 =A0fprintf(stderr, "Specifying a cpupool or schedparam is n=
ot "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"allowed with domain options.\n");
> =A0 =A0 =A0 =A0 return 1;
> =A0 =A0 }
> =A0 =A0 if (!dom && (opt_w || opt_c)) {
> =A0 =A0 =A0 =A0 fprintf(stderr, "Must specify a domain.\n");
> =A0 =A0 =A0 =A0 return 1;
> =A0 =A0 }
> -
> - =A0 =A0if (!dom) { /* list all domain's credit scheduler info */
> + =A0 =A0if (!opt_s && (opt_t || opt_r)) {
> + =A0 =A0 =A0 =A0fprintf(stderr, "Must specify schedparam to set schedule=
 "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"parameter values.\n");
> + =A0 =A0 =A0 =A0return 1;
> + =A0 =A0}
> +
> + =A0 =A0if (opt_s) {
> + =A0 =A0 =A0 =A0libxl_sched_credit_params =A0scparam;
> + =A0 =A0 =A0 =A0uint32_t poolid =3D 0;
> +
> + =A0 =A0 =A0 =A0if (cpupool) {
> + =A0 =A0 =A0 =A0 =A0 =A0if (cpupool_qualifier_to_cpupoolid(cpupool, &poo=
lid, NULL) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0!libxl_cpupoolid_to_name(ctx, poolid)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, "unknown cpupool \'%s\'\=
n", cpupool);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ERROR_FAIL;
> + =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0}
> +
> + =A0 =A0 =A0 =A0if (!opt_t && !opt_r) { /* Output scheduling parameters =
*/
> + =A0 =A0 =A0 =A0 =A0 =A0return -sched_credit_pool_output(poolid);
> + =A0 =A0 =A0 =A0} else { /* Set scheduling parameters*/
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D sched_credit_params_get(poolid, &scparam);
> + =A0 =A0 =A0 =A0 =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -rc;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0if (opt_t)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scparam.tslice_ms =3D tslice;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0if (opt_r)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scparam.ratelimit_us =3D ratelimit;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D sched_credit_params_set(poolid, &scparam);
> + =A0 =A0 =A0 =A0 =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -rc;
> + =A0 =A0 =A0 =A0}
> + =A0 =A0} else if (!dom) { /* list all domain's credit scheduler info */
> =A0 =A0 =A0 =A0 return -sched_domain_output(XEN_SCHEDULER_CREDIT,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s=
ched_credit_domain_output,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
sched_default_pool_output,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
sched_credit_pool_output,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 c=
pupool);
> =A0 =A0 } else {
> =A0 =A0 =A0 =A0 find_domain(dom);
> diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/xl_cmdtable.c Wed Feb 22 16:08:28 2012 +0000
> @@ -204,11 +204,14 @@ struct cmd_spec cmd_table[] =3D {
> =A0 =A0 { "sched-credit",
> =A0 =A0 =A0 &main_sched_credit, 0,
> =A0 =A0 =A0 "Get/set credit scheduler parameters",
> - =A0 =A0 =A0"[-d <Domain> [-w[=3DWEIGHT]|-c[=3DCAP]]] [-p CPUPOOL]",
> - =A0 =A0 =A0"-d DOMAIN, --domain=3DDOMAIN =A0 =A0 Domain to modify\n"
> - =A0 =A0 =A0"-w WEIGHT, --weight=3DWEIGHT =A0 =A0 Weight (int)\n"
> - =A0 =A0 =A0"-c CAP, --cap=3DCAP =A0 =A0 =A0 =A0 =A0 =A0 =A0Cap (int)\n"
> - =A0 =A0 =A0"-p CPUPOOL, --cpupool=3DCPUPOOL =A0Restrict output to CPUPO=
OL"
> + =A0 =A0 =A0"[-d <Domain> [-w[=3DWEIGHT]|-c[=3DCAP]]] [-s [-t TSLICE] [-=
r RATELIMIT]] [-p CPUPOOL]",
> + =A0 =A0 =A0"-d DOMAIN, --domain=3DDOMAIN =A0 =A0 =A0 =A0Domain to modif=
y\n"
> + =A0 =A0 =A0"-w WEIGHT, --weight=3DWEIGHT =A0 =A0 =A0 =A0Weight (int)\n"
> + =A0 =A0 =A0"-c CAP, --cap=3DCAP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cap (in=
t)\n"
> + =A0 =A0 =A0"-s =A0 =A0 =A0 =A0 --schedparam =A0 =A0 =A0 =A0 =A0 Query /=
 modify scheduler parameters\n"
> + =A0 =A0 =A0"-t TSLICE, --tslice_ms=3DTSLICE =A0 =A0 Set the timeslice, =
in milliseconds\n"
> + =A0 =A0 =A0"-r RLIMIT, --ratelimit_us=3DRLIMIT =A0Set the scheduling ra=
te limit, in microseconds\n"
> + =A0 =A0 =A0"-p CPUPOOL, --cpupool=3DCPUPOOL =A0 =A0 Restrict output to =
CPUPOOL"
> =A0 =A0 },
> =A0 =A0 { "sched-credit2",
> =A0 =A0 =A0 &main_sched_credit2, 0,
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:52:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0a13-0002LF-2M; Thu, 23 Feb 2012 14:51:29 +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 1S0a11-0002Kb-8f
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:51:27 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330008627!51302876!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 23 Feb 2012 14:50:28 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 14:50:28 -0000
Received: by ggnu1 with SMTP id u1so8698759ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 06:51:19 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.217.130 as permitted sender) client-ip=10.50.217.130; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.217.130 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.217.130])
	by 10.50.217.130 with SMTP id oy2mr1997622igc.10.1330008679377
	(num_hops = 1); Thu, 23 Feb 2012 06:51:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=rM16ZzTWry44m3fDO7zC4JjbuEYK1odjrBnIjiPBPQM=;
	b=jWgGbMpHzxZMwlFiHAi/DY1OAi2Aqr/bIBy6gqHEktG+8FoNKRm6FW90gM4zf0hcqS
	Ea0zyiW4jax9IjaoT1MqKmmP2/iDZuXDIY2+sshvqC4D8iu7Yk5IvR8YuSIeFlebRbnI
	awSI39aWZUFTKdcHKObgnibwAI7z7qJDabt0s=
MIME-Version: 1.0
Received: by 10.50.217.130 with SMTP id oy2mr1715660igc.10.1330008679117; Thu,
	23 Feb 2012 06:51:19 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Thu, 23 Feb 2012 06:51:19 -0800 (PST)
In-Reply-To: <0f91ce7b095af8506e94.1329927315@kodo2>
References: <patchbomb.1329927306@kodo2>
	<0f91ce7b095af8506e94.1329927315@kodo2>
Date: Thu, 23 Feb 2012 14:51:19 +0000
X-Google-Sender-Auth: Hwd1YhisTAPsJtg7M-odzN4G-pU
Message-ID: <CAFLBxZY0NNrDa+zV3YoOAfMqnVfnGA1sBOsVJXARo83inKQ0vw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 9 of 9] xl: Implement sched-credit schedule
 parameter command-line 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 22, 2012 at 4:15 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> Add features to the sched-credit interface to allow querying and
> displaying scheduler parameters.
>
> v2:
> =A0- Change function line breaks
> =A0- Pool output deals gracefully with other schedulers
> =A0- Add new parameters, as well as a description of how they
> =A0 interact, to the xl man page

BTW, there was a brief suggestion that rather than sharing the same
command (which requires a big table to explain how the various options
interact), we break out sched-credit into two, possibly three
commands; one of which would read all scheduler information, the other
two which would specifically get or set domain and scheduler-wide
parameters.  Any thoughts on this?

 -G

>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff -r 5600db2bcd0e -r 0f91ce7b095a docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1 Wed Feb 22 16:08:28 2012 +0000
> +++ b/docs/man/xl.pod.1 Wed Feb 22 16:08:28 2012 +0000
> @@ -714,6 +714,53 @@ no upper cap.
>
> =A0Restrict output to domains in the specified cpupool.
>
> +=3Ditem B<-s>, B<--schedparam>
> +
> +Specify to list or set pool-wide scheduler parameters.
> +
> +=3Ditem B<-t TSLICE>, B<--tslice_ms=3DTSLICE>
> +
> +Timeslice tells the scheduler how long to allow VMs to run before
> +pre-empting. =A0The default is 30ms. =A0Valid ranges are 1ms to 1000ms.
> +The length of the timeslice (in ms) must be higher than the length of
> +the ratelimit (see below).
> +
> +=3Ditem B<-r RLIMIT>, B<--ratelimit_us=3DRLIMIT>
> +
> +Ratelimit attempts to limit the number of schedules per second. =A0It
> +sets a minimum amount of time (in microseconds) a VM must run before
> +we will allow a higher-prioirty VM to pre-empt it. =A0The default value
> +is 1000 microseconds (1ms). =A0Valid range is 100 to 500000 (500ms).
> +The ratelimit length must be lower than the timeslice length.
> +
> +=3Dback
> +
> +B<COMBINATION>
> +
> +The following is the effect of combining the above options:
> +
> +=3Dover 4
> +
> +=3Ditem B<E<lt>nothingE<gt>> =A0 =A0 =A0 =A0 =A0 =A0 : List all domain p=
arams and sched params from all pools
> +
> +=3Ditem B<-d [domid]> =A0 =A0 =A0 =A0 =A0 =A0: List domain params for do=
main [domid]
> +
> +=3Ditem B<-d [domid] [params]> =A0 : Set domain params for domain [domid]
> +
> +=3Ditem B<-p [pool]> =A0 =A0 =A0 =A0 =A0 =A0 : list all domains and sche=
d params for [pool]
> +
> +=3Ditem B<-s> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: List sched params=
 for poolid 0
> +
> +=3Ditem B<-s [params]> =A0 =A0 =A0 =A0 =A0 : Set sched params for poolid=
 0
> +
> +=3Ditem B<-p [pool] -s> =A0 =A0 =A0 =A0 =A0: List sched params for [pool]
> +
> +=3Ditem B<-p [pool] -s [params]> : Set sched params for [pool]
> +
> +=3Ditem B<-p [pool] -d>... =A0 =A0 =A0 : Illegal
> +
> +=3Ditem
> +
> =A0=3Dback
>
> =A0=3Ditem B<sched-credit2> [I<OPTIONS>]
> diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c =A0Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c =A0Wed Feb 22 16:08:28 2012 +0000
> @@ -3912,8 +3912,7 @@ int main_sharing(int argc, char **argv)
> =A0 =A0 return 0;
> =A0}
>
> -static int sched_credit_domain_get(
> - =A0 =A0int domid, libxl_sched_credit_domain *scinfo)
> +static int sched_credit_domain_get(int domid, libxl_sched_credit_domain =
*scinfo)
> =A0{
> =A0 =A0 int rc;
>
> @@ -3924,8 +3923,7 @@ static int sched_credit_domain_get(
> =A0 =A0 return rc;
> =A0}
>
> -static int sched_credit_domain_set(
> - =A0 =A0int domid, libxl_sched_credit_domain *scinfo)
> +static int sched_credit_domain_set(int domid, libxl_sched_credit_domain =
*scinfo)
> =A0{
> =A0 =A0 int rc;
>
> @@ -3936,8 +3934,29 @@ static int sched_credit_domain_set(
> =A0 =A0 return rc;
> =A0}
>
> -static int sched_credit_domain_output(
> - =A0 =A0int domid)
> +static int sched_credit_params_set(int poolid, libxl_sched_credit_params=
 *scinfo)
> +{
> + =A0 =A0int rc;
> +
> + =A0 =A0rc =3D libxl_sched_credit_params_set(ctx, poolid, scinfo);
> + =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0fprintf(stderr, "libxl_sched_credit_params_set failed.\n=
");
> +
> + =A0 =A0return rc;
> +}
> +
> +static int sched_credit_params_get(int poolid, libxl_sched_credit_params=
 *scinfo)
> +{
> + =A0 =A0int rc;
> +
> + =A0 =A0rc =3D libxl_sched_credit_params_get(ctx, poolid, scinfo);
> + =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0fprintf(stderr, "libxl_sched_credit_params_get failed.\n=
");
> +
> + =A0 =A0return rc;
> +}
> +
> +static int sched_credit_domain_output(int domid)
> =A0{
> =A0 =A0 char *domname;
> =A0 =A0 libxl_sched_credit_domain scinfo;
> @@ -3960,6 +3979,27 @@ static int sched_credit_domain_output(
> =A0 =A0 return 0;
> =A0}
>
> +static int sched_credit_pool_output(uint32_t poolid)
> +{
> + =A0 =A0libxl_sched_credit_params scparam;
> + =A0 =A0char *poolname;
> + =A0 =A0int rc;
> +
> + =A0 =A0poolname =3D libxl_cpupoolid_to_name(ctx, poolid);
> + =A0 =A0rc =3D sched_credit_params_get(poolid, &scparam);
> + =A0 =A0if (rc) {
> + =A0 =A0 =A0 =A0printf("Cpupool %s: [sched params unavailable]\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 poolname);
> + =A0 =A0} else {
> + =A0 =A0 =A0 =A0printf("Cpupool %s: tslice=3D%dms ratelimit=3D%dus\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 poolname,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 scparam.tslice_ms,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 scparam.ratelimit_us);
> + =A0 =A0}
> + =A0 =A0free(poolname);
> + =A0 =A0return 0;
> +}
> +
> =A0static int sched_credit2_domain_get(
> =A0 =A0 int domid, libxl_sched_credit2_domain *scinfo)
> =A0{
> @@ -4122,25 +4162,41 @@ static int sched_domain_output(uint32_t
> =A0 =A0 return 0;
> =A0}
>
> +/*
> + * <nothing> =A0 =A0 =A0 =A0 =A0 =A0 : List all domain params and sched =
params from all pools
> + * -d [domid] =A0 =A0 =A0 =A0 =A0 =A0: List domain params for domain
> + * -d [domid] [params] =A0 : Set domain params for domain
> + * -p [pool] =A0 =A0 =A0 =A0 =A0 =A0 : list all domains and sched params=
 for pool
> + * -s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: List sched params for poo=
lid 0
> + * -s [params] =A0 =A0 =A0 =A0 =A0 : Set sched params for poolid 0
> + * -p [pool] -s =A0 =A0 =A0 =A0 =A0: List sched params for pool
> + * -p [pool] -s [params] : Set sched params for pool
> + * -p [pool] -d... =A0 =A0 =A0 : Illegal
> + */
> =A0int main_sched_credit(int argc, char **argv)
> =A0{
> =A0 =A0 libxl_sched_credit_domain scinfo;
> =A0 =A0 const char *dom =3D NULL;
> =A0 =A0 const char *cpupool =3D NULL;
> =A0 =A0 int weight =3D 256, cap =3D 0, opt_w =3D 0, opt_c =3D 0;
> + =A0 =A0int opt_s =3D 0;
> + =A0 =A0int tslice =3D 0, opt_t =3D 0, ratelimit =3D 0, opt_r =3D 0;
> =A0 =A0 int opt, rc;
> =A0 =A0 int option_index =3D 0;
> =A0 =A0 static struct option long_options[] =3D {
> =A0 =A0 =A0 =A0 {"domain", 1, 0, 'd'},
> =A0 =A0 =A0 =A0 {"weight", 1, 0, 'w'},
> =A0 =A0 =A0 =A0 {"cap", 1, 0, 'c'},
> + =A0 =A0 =A0 =A0{"schedparam", 0, 0, 's'},
> + =A0 =A0 =A0 =A0{"tslice_ms", 1, 0, 't'},
> + =A0 =A0 =A0 =A0{"ratelimit_us", 1, 0, 'r'},
> =A0 =A0 =A0 =A0 {"cpupool", 1, 0, 'p'},
> =A0 =A0 =A0 =A0 {"help", 0, 0, 'h'},
> =A0 =A0 =A0 =A0 {0, 0, 0, 0}
> =A0 =A0 };
>
> =A0 =A0 while (1) {
> - =A0 =A0 =A0 =A0opt =3D getopt_long(argc, argv, "d:w:c:p:h", long_option=
s,
> + =A0 =A0 =A0 =A0opt =3D getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_o=
ptions,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &option_index);
> =A0 =A0 =A0 =A0 if (opt =3D=3D -1)
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> @@ -4158,6 +4214,17 @@ int main_sched_credit(int argc, char **a
> =A0 =A0 =A0 =A0 =A0 =A0 cap =3D strtol(optarg, NULL, 10);
> =A0 =A0 =A0 =A0 =A0 =A0 opt_c =3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 =A0case 't':
> + =A0 =A0 =A0 =A0 =A0 =A0tslice =3D strtol(optarg, NULL, 10);
> + =A0 =A0 =A0 =A0 =A0 =A0opt_t =3D 1;
> + =A0 =A0 =A0 =A0 =A0 =A0break;
> + =A0 =A0 =A0 =A0case 'r':
> + =A0 =A0 =A0 =A0 =A0 =A0ratelimit =3D strtol(optarg, NULL, 10);
> + =A0 =A0 =A0 =A0 =A0 =A0opt_r =3D 1;
> + =A0 =A0 =A0 =A0 =A0 =A0break;
> + =A0 =A0 =A0 =A0case 's':
> + =A0 =A0 =A0 =A0 =A0 =A0opt_s =3D 1;
> + =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0 case 'p':
> =A0 =A0 =A0 =A0 =A0 =A0 cpupool =3D optarg;
> =A0 =A0 =A0 =A0 =A0 =A0 break;
> @@ -4167,20 +4234,54 @@ int main_sched_credit(int argc, char **a
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
>
> - =A0 =A0if (cpupool && (dom || opt_w || opt_c)) {
> - =A0 =A0 =A0 =A0fprintf(stderr, "Specifying a cpupool is not allowed wit=
h other "
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"options.\n");
> + =A0 =A0if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
> + =A0 =A0 =A0 =A0fprintf(stderr, "Specifying a cpupool or schedparam is n=
ot "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"allowed with domain options.\n");
> =A0 =A0 =A0 =A0 return 1;
> =A0 =A0 }
> =A0 =A0 if (!dom && (opt_w || opt_c)) {
> =A0 =A0 =A0 =A0 fprintf(stderr, "Must specify a domain.\n");
> =A0 =A0 =A0 =A0 return 1;
> =A0 =A0 }
> -
> - =A0 =A0if (!dom) { /* list all domain's credit scheduler info */
> + =A0 =A0if (!opt_s && (opt_t || opt_r)) {
> + =A0 =A0 =A0 =A0fprintf(stderr, "Must specify schedparam to set schedule=
 "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"parameter values.\n");
> + =A0 =A0 =A0 =A0return 1;
> + =A0 =A0}
> +
> + =A0 =A0if (opt_s) {
> + =A0 =A0 =A0 =A0libxl_sched_credit_params =A0scparam;
> + =A0 =A0 =A0 =A0uint32_t poolid =3D 0;
> +
> + =A0 =A0 =A0 =A0if (cpupool) {
> + =A0 =A0 =A0 =A0 =A0 =A0if (cpupool_qualifier_to_cpupoolid(cpupool, &poo=
lid, NULL) ||
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0!libxl_cpupoolid_to_name(ctx, poolid)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, "unknown cpupool \'%s\'\=
n", cpupool);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ERROR_FAIL;
> + =A0 =A0 =A0 =A0 =A0 =A0}
> + =A0 =A0 =A0 =A0}
> +
> + =A0 =A0 =A0 =A0if (!opt_t && !opt_r) { /* Output scheduling parameters =
*/
> + =A0 =A0 =A0 =A0 =A0 =A0return -sched_credit_pool_output(poolid);
> + =A0 =A0 =A0 =A0} else { /* Set scheduling parameters*/
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D sched_credit_params_get(poolid, &scparam);
> + =A0 =A0 =A0 =A0 =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -rc;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0if (opt_t)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scparam.tslice_ms =3D tslice;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0if (opt_r)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scparam.ratelimit_us =3D ratelimit;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0rc =3D sched_credit_params_set(poolid, &scparam);
> + =A0 =A0 =A0 =A0 =A0 =A0if (rc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -rc;
> + =A0 =A0 =A0 =A0}
> + =A0 =A0} else if (!dom) { /* list all domain's credit scheduler info */
> =A0 =A0 =A0 =A0 return -sched_domain_output(XEN_SCHEDULER_CREDIT,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s=
ched_credit_domain_output,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
sched_default_pool_output,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
sched_credit_pool_output,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 c=
pupool);
> =A0 =A0 } else {
> =A0 =A0 =A0 =A0 find_domain(dom);
> diff -r 5600db2bcd0e -r 0f91ce7b095a tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c Wed Feb 22 16:08:28 2012 +0000
> +++ b/tools/libxl/xl_cmdtable.c Wed Feb 22 16:08:28 2012 +0000
> @@ -204,11 +204,14 @@ struct cmd_spec cmd_table[] =3D {
> =A0 =A0 { "sched-credit",
> =A0 =A0 =A0 &main_sched_credit, 0,
> =A0 =A0 =A0 "Get/set credit scheduler parameters",
> - =A0 =A0 =A0"[-d <Domain> [-w[=3DWEIGHT]|-c[=3DCAP]]] [-p CPUPOOL]",
> - =A0 =A0 =A0"-d DOMAIN, --domain=3DDOMAIN =A0 =A0 Domain to modify\n"
> - =A0 =A0 =A0"-w WEIGHT, --weight=3DWEIGHT =A0 =A0 Weight (int)\n"
> - =A0 =A0 =A0"-c CAP, --cap=3DCAP =A0 =A0 =A0 =A0 =A0 =A0 =A0Cap (int)\n"
> - =A0 =A0 =A0"-p CPUPOOL, --cpupool=3DCPUPOOL =A0Restrict output to CPUPO=
OL"
> + =A0 =A0 =A0"[-d <Domain> [-w[=3DWEIGHT]|-c[=3DCAP]]] [-s [-t TSLICE] [-=
r RATELIMIT]] [-p CPUPOOL]",
> + =A0 =A0 =A0"-d DOMAIN, --domain=3DDOMAIN =A0 =A0 =A0 =A0Domain to modif=
y\n"
> + =A0 =A0 =A0"-w WEIGHT, --weight=3DWEIGHT =A0 =A0 =A0 =A0Weight (int)\n"
> + =A0 =A0 =A0"-c CAP, --cap=3DCAP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cap (in=
t)\n"
> + =A0 =A0 =A0"-s =A0 =A0 =A0 =A0 --schedparam =A0 =A0 =A0 =A0 =A0 Query /=
 modify scheduler parameters\n"
> + =A0 =A0 =A0"-t TSLICE, --tslice_ms=3DTSLICE =A0 =A0 Set the timeslice, =
in milliseconds\n"
> + =A0 =A0 =A0"-r RLIMIT, --ratelimit_us=3DRLIMIT =A0Set the scheduling ra=
te limit, in microseconds\n"
> + =A0 =A0 =A0"-p CPUPOOL, --cpupool=3DCPUPOOL =A0 =A0 Restrict output to =
CPUPOOL"
> =A0 =A0 },
> =A0 =A0 { "sched-credit2",
> =A0 =A0 =A0 &main_sched_credit2, 0,
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:53:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:53:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0a2d-0002Wd-Ib; Thu, 23 Feb 2012 14:53:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0a2b-0002W3-Em
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:53:05 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330008777!14623993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22292 invoked from network); 23 Feb 2012 14:52:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 14:52:58 -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 q1NEqsnq015544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:52: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
	q1NEqr1B015098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:52:53 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
	q1NEqrCX011756; Thu, 23 Feb 2012 08:52:53 -0600
Received: from [123.113.71.129] (/123.113.71.129)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:52:52 -0800
Message-ID: <4F4652BB.4020809@oracle.com>
Date: Thu, 23 Feb 2012 22:52:43 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F41F41F.9060601@oracle.com>	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	<4F430201.3040208@oracle.com>	<1329908701.2880.26.camel@zakaz.uk.xensource.com>	<4F44E94A.2060209@oracle.com>
	<1329919132.8557.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329919132.8557.2.camel@zakaz.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------030803060006070505090208"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F4652C7.0022,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-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.
--------------030803060006070505090208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 2012-2-22 21:58, Ian Campbell wrote:
>
> Yes, this looks plausible to me (although I'm no expert on this code).
> Something similar happens in rtc_next_second. 
>
> Perhaps it would be better to add a function or macro to do the
> conversion, such that it is somewhat self documenting? Or at least make
> the 1900 a #define with a suitable name.
>   
I changed the 1900 to a macro and added a new function get_year. The new 
patch is attached.

Thanks
Annie

--------------030803060006070505090208
Content-Type: text/plain;
 name="rtc-timeoffset.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rtc-timeoffset.patch"

# HG changeset patch
# Parent f2543f449a49b8979becbf6888e009973427089a
hvm: correct RTC time offset update error due to tm->tm_year

tm->tm_year in rtc.c is year number offsetting from 1900. So it is necessary to 
add the offset 1900 when calling mktime funtion in Xen. Otherwise, the 
calculation result of mktime is incorrect.

Signed-off-by: Annie Li <annie.li@oracle.com>

diff -r f2543f449a49 xen/arch/x86/hvm/rtc.c
--- a/xen/arch/x86/hvm/rtc.c	Mon Feb 13 17:57:47 2012 +0000
+++ b/xen/arch/x86/hvm/rtc.c	Thu Feb 23 18:21:19 2012 +0800
@@ -33,6 +33,8 @@
 #define vrtc_domain(x) (container_of((x), struct domain, \
                                      arch.hvm_domain.pl_time.vrtc))
 #define vrtc_vcpu(x)   (pt_global_vcpu_target(vrtc_domain(x)))
+#define epoch_year     1900
+#define get_year(x)    (x + epoch_year)
 
 static void rtc_periodic_cb(struct vcpu *v, void *opaque)
 {
@@ -165,7 +167,7 @@ static void rtc_set_time(RTCState *s)
       
     ASSERT(spin_is_locked(&s->lock));
 
-    before = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+    before = mktime(get_year(tm->tm_year), tm->tm_mon + 1, tm->tm_mday,
 		    tm->tm_hour, tm->tm_min, tm->tm_sec);
     
     tm->tm_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
@@ -179,7 +181,7 @@ static void rtc_set_time(RTCState *s)
     tm->tm_mon = from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1;
     tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
 
-    after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+    after = mktime(get_year(tm->tm_year), tm->tm_mon + 1, tm->tm_mday,
                    tm->tm_hour, tm->tm_min, tm->tm_sec);
 
     /* We use the guest's setting of the RTC to define the local-time 
@@ -257,7 +259,7 @@ static void rtc_next_second(RTCState *s)
                 if ( (unsigned)tm->tm_wday >= 7 )
                     tm->tm_wday = 0;
                 days_in_month = get_days_in_month(tm->tm_mon, 
-                                                  tm->tm_year + 1900);
+                                                  get_year(tm->tm_year));
                 tm->tm_mday++;
                 if ( tm->tm_mday < 1 )
                 {

--------------030803060006070505090208
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030803060006070505090208--


From xen-devel-bounces@lists.xen.org Thu Feb 23 14:53:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:53:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0a2d-0002Wd-Ib; Thu, 23 Feb 2012 14:53:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0a2b-0002W3-Em
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:53:05 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330008777!14623993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22292 invoked from network); 23 Feb 2012 14:52:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 14:52:58 -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 q1NEqsnq015544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 14:52: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
	q1NEqr1B015098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 14:52:53 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
	q1NEqrCX011756; Thu, 23 Feb 2012 08:52:53 -0600
Received: from [123.113.71.129] (/123.113.71.129)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 06:52:52 -0800
Message-ID: <4F4652BB.4020809@oracle.com>
Date: Thu, 23 Feb 2012 22:52:43 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F41F41F.9060601@oracle.com>	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	<4F430201.3040208@oracle.com>	<1329908701.2880.26.camel@zakaz.uk.xensource.com>	<4F44E94A.2060209@oracle.com>
	<1329919132.8557.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329919132.8557.2.camel@zakaz.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------030803060006070505090208"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F4652C7.0022,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-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.
--------------030803060006070505090208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 2012-2-22 21:58, Ian Campbell wrote:
>
> Yes, this looks plausible to me (although I'm no expert on this code).
> Something similar happens in rtc_next_second. 
>
> Perhaps it would be better to add a function or macro to do the
> conversion, such that it is somewhat self documenting? Or at least make
> the 1900 a #define with a suitable name.
>   
I changed the 1900 to a macro and added a new function get_year. The new 
patch is attached.

Thanks
Annie

--------------030803060006070505090208
Content-Type: text/plain;
 name="rtc-timeoffset.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rtc-timeoffset.patch"

# HG changeset patch
# Parent f2543f449a49b8979becbf6888e009973427089a
hvm: correct RTC time offset update error due to tm->tm_year

tm->tm_year in rtc.c is year number offsetting from 1900. So it is necessary to 
add the offset 1900 when calling mktime funtion in Xen. Otherwise, the 
calculation result of mktime is incorrect.

Signed-off-by: Annie Li <annie.li@oracle.com>

diff -r f2543f449a49 xen/arch/x86/hvm/rtc.c
--- a/xen/arch/x86/hvm/rtc.c	Mon Feb 13 17:57:47 2012 +0000
+++ b/xen/arch/x86/hvm/rtc.c	Thu Feb 23 18:21:19 2012 +0800
@@ -33,6 +33,8 @@
 #define vrtc_domain(x) (container_of((x), struct domain, \
                                      arch.hvm_domain.pl_time.vrtc))
 #define vrtc_vcpu(x)   (pt_global_vcpu_target(vrtc_domain(x)))
+#define epoch_year     1900
+#define get_year(x)    (x + epoch_year)
 
 static void rtc_periodic_cb(struct vcpu *v, void *opaque)
 {
@@ -165,7 +167,7 @@ static void rtc_set_time(RTCState *s)
       
     ASSERT(spin_is_locked(&s->lock));
 
-    before = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+    before = mktime(get_year(tm->tm_year), tm->tm_mon + 1, tm->tm_mday,
 		    tm->tm_hour, tm->tm_min, tm->tm_sec);
     
     tm->tm_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
@@ -179,7 +181,7 @@ static void rtc_set_time(RTCState *s)
     tm->tm_mon = from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1;
     tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100;
 
-    after = mktime(tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+    after = mktime(get_year(tm->tm_year), tm->tm_mon + 1, tm->tm_mday,
                    tm->tm_hour, tm->tm_min, tm->tm_sec);
 
     /* We use the guest's setting of the RTC to define the local-time 
@@ -257,7 +259,7 @@ static void rtc_next_second(RTCState *s)
                 if ( (unsigned)tm->tm_wday >= 7 )
                     tm->tm_wday = 0;
                 days_in_month = get_days_in_month(tm->tm_mon, 
-                                                  tm->tm_year + 1900);
+                                                  get_year(tm->tm_year));
                 tm->tm_mday++;
                 if ( tm->tm_mday < 1 )
                 {

--------------030803060006070505090208
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030803060006070505090208--


From xen-devel-bounces@lists.xen.org Thu Feb 23 14:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0a3c-0002c1-12; Thu, 23 Feb 2012 14:54:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1S0a3b-0002bs-Hm
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:54:07 +0000
Received: from [85.158.139.83:23058] by server-11.bemta-5.messagelabs.com id
	7C/43-14397-E03564F4; Thu, 23 Feb 2012 14:54:06 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330008846!15492882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31480 invoked from network); 23 Feb 2012 14:54: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 14:54:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 14:54:05 +0000
Message-Id: <4F46530B020000780007F751@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 14:54:03 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <jinsong.liu@intel.com>,<konrad.wilk@oracle.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: len.brown@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	keir.xen@gmail.com, shaohua.li@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>--- a/drivers/acpi/Kconfig
>+++ b/drivers/acpi/Kconfig
>@@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>    default y
 >
>config ACPI_PROCESSOR_AGGREGATOR
>-    tristate "Processor Aggregator"
>+    bool "Processor Aggregator"

There must be ways to address whatever strange problem you see without
making this piece of code non-modular.

>    depends on ACPI_PROCESSOR
>    depends on EXPERIMENTAL
>    depends on X86
>+    default n

This is pointless.

>    help
>      ACPI 4.0 defines processor Aggregator, which enables OS to perform
>      specific processor configuration and control that applies to all

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0a3c-0002c1-12; Thu, 23 Feb 2012 14:54:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jbeulich@suse.com>) id 1S0a3b-0002bs-Hm
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 14:54:07 +0000
Received: from [85.158.139.83:23058] by server-11.bemta-5.messagelabs.com id
	7C/43-14397-E03564F4; Thu, 23 Feb 2012 14:54:06 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330008846!15492882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31480 invoked from network); 23 Feb 2012 14:54: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 14:54:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 23 Feb 2012 14:54:05 +0000
Message-Id: <4F46530B020000780007F751@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 23 Feb 2012 14:54:03 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <jinsong.liu@intel.com>,<konrad.wilk@oracle.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: len.brown@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	keir.xen@gmail.com, shaohua.li@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>--- a/drivers/acpi/Kconfig
>+++ b/drivers/acpi/Kconfig
>@@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>    default y
 >
>config ACPI_PROCESSOR_AGGREGATOR
>-    tristate "Processor Aggregator"
>+    bool "Processor Aggregator"

There must be ways to address whatever strange problem you see without
making this piece of code non-modular.

>    depends on ACPI_PROCESSOR
>    depends on EXPERIMENTAL
>    depends on X86
>+    default n

This is pointless.

>    help
>      ACPI 4.0 defines processor Aggregator, which enables OS to perform
>      specific processor configuration and control that applies to all

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:59:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0a8Y-0002vV-V2; Thu, 23 Feb 2012 14:59:14 +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 1S0a8X-0002vM-4J
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 14:59:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330009072!62622544!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29335 invoked from network); 23 Feb 2012 14:57:52 -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; 23 Feb 2012 14:57:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0a8Q-0007cO-KF; Thu, 23 Feb 2012 14:59:06 +0000
Date: Thu, 23 Feb 2012 14:59:06 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20120223145906.GF25694@ocelot.phlegethon.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
	<4F3E95610200007800073B97@nat28.tlf.novell.com>
	<20120223103351.GB25694@ocelot.phlegethon.org>
	<4F464E68020000780007F738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F464E68020000780007F738@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
	pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:34 +0000 on 23 Feb (1330007656), Jan Beulich wrote:
> >>> Tim Deegan <tim@xen.org> 02/23/12 11:34 AM >>>
> >I've applied it, since it seemed not to break anything and I'll be away
> >from my test boxes for a while.  Let me know of you're still seeing any
> >problems. 
> 
> Thanks - I had hoped we would have reported testing results earlier, but
> this unfortunately is going pretty slowly.
> 
> One thing though - shouldn't further walking be suppressed if at a
> given level any violation is detected (i.e. if rc became non-zero)? For
> sure the hardware aborts a walk at least if reserved bits are found
> set, and I'd suspect it also doesn't bother continuing the walk if access
> rights don't permit the result to be used.

That sounds plausible, but I recall there being some subtleties about
that when we first looked at it and I haven't time to dig up what they
were right now.  I may be misremembering but I don't want to tinker with
it without being sure.  I'll look into it again when I get a minute.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 14:59:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 14:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0a8Y-0002vV-V2; Thu, 23 Feb 2012 14:59:14 +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 1S0a8X-0002vM-4J
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 14:59:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330009072!62622544!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29335 invoked from network); 23 Feb 2012 14:57:52 -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; 23 Feb 2012 14:57:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0a8Q-0007cO-KF; Thu, 23 Feb 2012 14:59:06 +0000
Date: Thu, 23 Feb 2012 14:59:06 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Message-ID: <20120223145906.GF25694@ocelot.phlegethon.org>
References: <4F3E855E0200007800073B20@nat28.tlf.novell.com>
	<20120217162344.GA59026@ocelot.phlegethon.org>
	<4F3E95610200007800073B97@nat28.tlf.novell.com>
	<20120223103351.GB25694@ocelot.phlegethon.org>
	<4F464E68020000780007F738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F464E68020000780007F738@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] regression from 22242:7831b8e5aae2 (x86 guest
	pagetable walker: check for invalid bits in pagetable entries)?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:34 +0000 on 23 Feb (1330007656), Jan Beulich wrote:
> >>> Tim Deegan <tim@xen.org> 02/23/12 11:34 AM >>>
> >I've applied it, since it seemed not to break anything and I'll be away
> >from my test boxes for a while.  Let me know of you're still seeing any
> >problems. 
> 
> Thanks - I had hoped we would have reported testing results earlier, but
> this unfortunately is going pretty slowly.
> 
> One thing though - shouldn't further walking be suppressed if at a
> given level any violation is detected (i.e. if rc became non-zero)? For
> sure the hardware aborts a walk at least if reserved bits are found
> set, and I'd suspect it also doesn't bother continuing the walk if access
> rights don't permit the result to be used.

That sounds plausible, but I recall there being some subtleties about
that when we first looked at it and I haven't time to dig up what they
were right now.  I may be misremembering but I don't want to tinker with
it without being sure.  I'll look into it again when I get a minute.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEO-00038r-KU; Thu, 23 Feb 2012 15:05:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEN-000382-Fg
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330009508!15219875!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1484 invoked from network); 23 Feb 2012 15:05:09 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:05:09 -0000
Received: by werh12 with SMTP id h12so1065024wer.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:08 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.99.7 as permitted sender) client-ip=10.180.99.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.99.7 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.99.7])
	by 10.180.99.7 with SMTP id em7mr3758397wib.7.1330009508718 (num_hops =
	1); Thu, 23 Feb 2012 07:05:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=sAWHtMrfvVynMg5ly96uh18wTdlRQtUEfe2vs/tRMpE=;
	b=EqBLKAOVFC70M72IUxmzUR3tjPBxK6BbIGF6P9Kbp8IvsUOS2iZsybXda4T54zIiEp
	FbCMC2J/b5pkQTThFAareiDlB50vtDwanr7sJ0C+/N1MIZeh1Fw8vEWJfcYoTIAAliT5
	idT8n4GIXe5wU/HkW39d+/GMmVMMMdxKJYqSI=
Received: by 10.180.99.7 with SMTP id em7mr3070373wib.7.1330009508680;
	Thu, 23 Feb 2012 07:05:08 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 72fc6b55447b9f45fd4d8a5d7ef09d4dd899edc2
Message-Id: <72fc6b55447b9f45fd4d.1329858638@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 5] autoconf: remove (yet another) brctl
	leftover
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329857655 -3600
# Node ID 72fc6b55447b9f45fd4d8a5d7ef09d4dd899edc2
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
autoconf: remove (yet another) brctl leftover

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a4d93d0e0df2 -r 72fc6b55447b config/Tools.mk.in
--- a/config/Tools.mk.in	Wed Feb 22 14:33:24 2012 +0000
+++ b/config/Tools.mk.in	Tue Feb 21 21:54:15 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-BRCTL               := @BRCTL@
 IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEO-00038r-KU; Thu, 23 Feb 2012 15:05:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEN-000382-Fg
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330009508!15219875!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1484 invoked from network); 23 Feb 2012 15:05:09 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:05:09 -0000
Received: by werh12 with SMTP id h12so1065024wer.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:08 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.99.7 as permitted sender) client-ip=10.180.99.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.99.7 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.99.7])
	by 10.180.99.7 with SMTP id em7mr3758397wib.7.1330009508718 (num_hops =
	1); Thu, 23 Feb 2012 07:05:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=sAWHtMrfvVynMg5ly96uh18wTdlRQtUEfe2vs/tRMpE=;
	b=EqBLKAOVFC70M72IUxmzUR3tjPBxK6BbIGF6P9Kbp8IvsUOS2iZsybXda4T54zIiEp
	FbCMC2J/b5pkQTThFAareiDlB50vtDwanr7sJ0C+/N1MIZeh1Fw8vEWJfcYoTIAAliT5
	idT8n4GIXe5wU/HkW39d+/GMmVMMMdxKJYqSI=
Received: by 10.180.99.7 with SMTP id em7mr3070373wib.7.1330009508680;
	Thu, 23 Feb 2012 07:05:08 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 72fc6b55447b9f45fd4d8a5d7ef09d4dd899edc2
Message-Id: <72fc6b55447b9f45fd4d.1329858638@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 5] autoconf: remove (yet another) brctl
	leftover
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329857655 -3600
# Node ID 72fc6b55447b9f45fd4d8a5d7ef09d4dd899edc2
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
autoconf: remove (yet another) brctl leftover

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a4d93d0e0df2 -r 72fc6b55447b config/Tools.mk.in
--- a/config/Tools.mk.in	Wed Feb 22 14:33:24 2012 +0000
+++ b/config/Tools.mk.in	Tue Feb 21 21:54:15 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-BRCTL               := @BRCTL@
 IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEK-00038H-Sj; Thu, 23 Feb 2012 15:05:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEJ-000384-GD
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330009461!61382969!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16508 invoked from network); 23 Feb 2012 15:04:24 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:04:24 -0000
Received: by mail-wi0-f173.google.com with SMTP id hi20so1078088wib.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:10 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.77.228 as permitted sender) client-ip=10.180.77.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.77.228 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.77.228])
	by 10.180.77.228 with SMTP id v4mr3807471wiw.2.1330009510332 (num_hops
	= 1); Thu, 23 Feb 2012 07:05:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=bBMhVNzSYEMAouwYBYFl9RdPo94DL1vqMs21bBCMCBY=;
	b=F9NrZdXSSmHRoHfa6aGcGtKWeM9AZnh57GXG0JWU+4v5s9tFBPS7pcMtTnaOHVp18x
	wXoI4NHdVupSkPw6Bx34DpMgAPTyb8Tj/76rdMZWPRqmDQRrYur4iBV9xfT2qGgbA0J9
	iXlzWHu3tmXnQ3ZFJTHUzHy3z3taE2Zfm6dbY=
Received: by 10.180.77.228 with SMTP id v4mr3106157wiw.2.1330009510260;
	Thu, 23 Feb 2012 07:05:10 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8bd684735341cd4e41aa6ea1047556a88b84f625
Message-Id: <8bd684735341cd4e41aa.1329858640@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 5] autoconf: run libuuid test under Linux
	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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330004063 -3600
# Node ID 8bd684735341cd4e41aa6ea1047556a88b84f625
# Parent  21734a9d28823bdda72423282582ff973289c758
autoconf: run libuuid test under Linux only

libuuid is only required to compile Xen tools under Linux.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 21734a9d2882 -r 8bd684735341 tools/configure
--- a/tools/configure	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:34:23 2012 +0100
@@ -6840,7 +6840,9 @@ if test "x$ac_cv_lib_rt_clock_gettime" =
 
 fi
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
+if test "x$host_os" == "xlinux-gnu"; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
 if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
   $as_echo_n "(cached) " >&6
@@ -6887,6 +6889,8 @@ else
   as_fn_error $? "Could not find libuuid" "$LINENO" 5
 fi
 
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff -r 21734a9d2882 -r 8bd684735341 tools/configure.ac
--- a/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:34:23 2012 +0100
@@ -120,8 +120,10 @@ AC_SUBST(libgcrypt)
 AC_CHECK_LIB([pthread], [pthread_create], [] ,
     [AC_MSG_ERROR([Could not find libpthread])])
 AC_CHECK_LIB([rt], [clock_gettime])
-AC_CHECK_LIB([uuid], [uuid_clear], [],
-    [AC_MSG_ERROR([Could not find libuuid])])
+AS_IF([test "x$host_os" == "xlinux-gnu"], [
+    AC_CHECK_LIB([uuid], [uuid_clear], [],
+        [AC_MSG_ERROR([Could not find libuuid])])
+])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEK-00038H-Sj; Thu, 23 Feb 2012 15:05:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEJ-000384-GD
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330009461!61382969!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16508 invoked from network); 23 Feb 2012 15:04:24 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:04:24 -0000
Received: by mail-wi0-f173.google.com with SMTP id hi20so1078088wib.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:10 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.77.228 as permitted sender) client-ip=10.180.77.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.77.228 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.77.228])
	by 10.180.77.228 with SMTP id v4mr3807471wiw.2.1330009510332 (num_hops
	= 1); Thu, 23 Feb 2012 07:05:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=bBMhVNzSYEMAouwYBYFl9RdPo94DL1vqMs21bBCMCBY=;
	b=F9NrZdXSSmHRoHfa6aGcGtKWeM9AZnh57GXG0JWU+4v5s9tFBPS7pcMtTnaOHVp18x
	wXoI4NHdVupSkPw6Bx34DpMgAPTyb8Tj/76rdMZWPRqmDQRrYur4iBV9xfT2qGgbA0J9
	iXlzWHu3tmXnQ3ZFJTHUzHy3z3taE2Zfm6dbY=
Received: by 10.180.77.228 with SMTP id v4mr3106157wiw.2.1330009510260;
	Thu, 23 Feb 2012 07:05:10 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8bd684735341cd4e41aa6ea1047556a88b84f625
Message-Id: <8bd684735341cd4e41aa.1329858640@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 5] autoconf: run libuuid test under Linux
	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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330004063 -3600
# Node ID 8bd684735341cd4e41aa6ea1047556a88b84f625
# Parent  21734a9d28823bdda72423282582ff973289c758
autoconf: run libuuid test under Linux only

libuuid is only required to compile Xen tools under Linux.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 21734a9d2882 -r 8bd684735341 tools/configure
--- a/tools/configure	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:34:23 2012 +0100
@@ -6840,7 +6840,9 @@ if test "x$ac_cv_lib_rt_clock_gettime" =
 
 fi
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
+if test "x$host_os" == "xlinux-gnu"; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
 if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
   $as_echo_n "(cached) " >&6
@@ -6887,6 +6889,8 @@ else
   as_fn_error $? "Could not find libuuid" "$LINENO" 5
 fi
 
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff -r 21734a9d2882 -r 8bd684735341 tools/configure.ac
--- a/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:34:23 2012 +0100
@@ -120,8 +120,10 @@ AC_SUBST(libgcrypt)
 AC_CHECK_LIB([pthread], [pthread_create], [] ,
     [AC_MSG_ERROR([Could not find libpthread])])
 AC_CHECK_LIB([rt], [clock_gettime])
-AC_CHECK_LIB([uuid], [uuid_clear], [],
-    [AC_MSG_ERROR([Could not find libuuid])])
+AS_IF([test "x$host_os" == "xlinux-gnu"], [
+    AC_CHECK_LIB([uuid], [uuid_clear], [],
+        [AC_MSG_ERROR([Could not find libuuid])])
+])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEQ-00039H-1M; Thu, 23 Feb 2012 15:05:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEO-000383-AX
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330009509!16600674!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11313 invoked from network); 23 Feb 2012 15:05:10 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:05:10 -0000
Received: by wgbdy1 with SMTP id dy1so863685wgb.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:09 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.101.228 as permitted sender) client-ip=10.180.101.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.101.228 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.101.228])
	by 10.180.101.228 with SMTP id fj4mr4087654wib.4.1330009509667
	(num_hops = 1); Thu, 23 Feb 2012 07:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ez553iZmlKxCkKsWouuBwdlj4uPexNwvFEJi4+CqP3o=;
	b=AdsHRpU5fOxLAT0kVj2qo7zAHpslh7FXx2zk9003JGD84Xkthu/2wSJSSjrApWCZGq
	GgCE4j4hAHg8b86k1lbi3bdBbRlqze8JqcBTVkjT8dZMM3eXuJBXYi4gzFxihhnGkEGc
	m9m0uD/KzGt9xVPdBBb+nl9VdzAFGJM6/Bpjk=
Received: by 10.180.101.228 with SMTP id fj4mr3347303wib.4.1330009509619;
	Thu, 23 Feb 2012 07:05:09 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 21734a9d28823bdda72423282582ff973289c758
Message-Id: <21734a9d28823bdda724.1329858639@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:39 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 5] autconf: remove ip 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330003783 -3600
# Node ID 21734a9d28823bdda72423282582ff973289c758
# Parent  72fc6b55447b9f45fd4d8a5d7ef09d4dd899edc2
autconf: remove ip check

ip is a run-time dependency, and it is not needed to build Xen tools.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 72fc6b55447b -r 21734a9d2882 config/Tools.mk.in
--- a/config/Tools.mk.in	Tue Feb 21 21:54:15 2012 +0100
+++ b/config/Tools.mk.in	Thu Feb 23 14:29:43 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@
 BASH                := @BASH@
diff -r 72fc6b55447b -r 21734a9d2882 tools/configure
--- a/tools/configure	Tue Feb 21 21:54:15 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:29:43 2012 +0100
@@ -637,7 +637,6 @@ XML
 CURL
 FLEX
 BISON
-IP
 PERL
 PYTHON
 APPEND_LIB
@@ -739,7 +738,6 @@ APPEND_INCLUDES
 APPEND_LIB
 PYTHON
 PERL
-IP
 BISON
 FLEX
 CURL
@@ -1394,7 +1392,6 @@ Some influential environment variables:
   APPEND_LIB  List of library folders to append to LDFLAGS (without -L)
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
-  IP          Path to ip tool
   BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
   CURL        Path to curl-config tool
@@ -4158,7 +4155,6 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPE
 
 
 
-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
@@ -4949,51 +4945,6 @@ if test x"${PERL}" == x"no"
 then
     as_fn_error $? "Unable to find perl, please install perl" "$LINENO" 5
 fi
-# Extract the first word of "ip", so it can be a program name with args.
-set dummy ip; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_IP+set}" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $IP in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_IP="$IP" # Let the user override the test with a path.
-  ;;
-  *)
-  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
-    ac_cv_path_IP="$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=$as_save_IFS
-
-  test -z "$ac_cv_path_IP" && ac_cv_path_IP="no"
-  ;;
-esac
-fi
-IP=$ac_cv_path_IP
-if test -n "$IP"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $IP" >&5
-$as_echo "$IP" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-if test x"${IP}" == x"no"
-then
-    as_fn_error $? "Unable to find ip, please install ip" "$LINENO" 5
-fi
 # Extract the first word of "bison", so it can be a program name with args.
 set dummy bison; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
diff -r 72fc6b55447b -r 21734a9d2882 tools/configure.ac
--- a/tools/configure.ac	Tue Feb 21 21:54:15 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
@@ -62,7 +62,6 @@ AX_SET_FLAGS
 
 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
-AC_ARG_VAR([IP], [Path to ip tool])
 AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
 AC_ARG_VAR([CURL], [Path to curl-config tool])
@@ -77,7 +76,6 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
-AX_PATH_PROG_OR_FAIL([IP], [ip])
 AX_PATH_PROG_OR_FAIL([BISON], [bison])
 AX_PATH_PROG_OR_FAIL([FLEX], [flex])
 AS_IF([test "x$xapi" = "xy"], [

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEQ-00039H-1M; Thu, 23 Feb 2012 15:05:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEO-000383-AX
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330009509!16600674!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11313 invoked from network); 23 Feb 2012 15:05:10 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:05:10 -0000
Received: by wgbdy1 with SMTP id dy1so863685wgb.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:09 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.101.228 as permitted sender) client-ip=10.180.101.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.101.228 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.101.228])
	by 10.180.101.228 with SMTP id fj4mr4087654wib.4.1330009509667
	(num_hops = 1); Thu, 23 Feb 2012 07:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ez553iZmlKxCkKsWouuBwdlj4uPexNwvFEJi4+CqP3o=;
	b=AdsHRpU5fOxLAT0kVj2qo7zAHpslh7FXx2zk9003JGD84Xkthu/2wSJSSjrApWCZGq
	GgCE4j4hAHg8b86k1lbi3bdBbRlqze8JqcBTVkjT8dZMM3eXuJBXYi4gzFxihhnGkEGc
	m9m0uD/KzGt9xVPdBBb+nl9VdzAFGJM6/Bpjk=
Received: by 10.180.101.228 with SMTP id fj4mr3347303wib.4.1330009509619;
	Thu, 23 Feb 2012 07:05:09 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 21734a9d28823bdda72423282582ff973289c758
Message-Id: <21734a9d28823bdda724.1329858639@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:39 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 5] autconf: remove ip 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330003783 -3600
# Node ID 21734a9d28823bdda72423282582ff973289c758
# Parent  72fc6b55447b9f45fd4d8a5d7ef09d4dd899edc2
autconf: remove ip check

ip is a run-time dependency, and it is not needed to build Xen tools.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 72fc6b55447b -r 21734a9d2882 config/Tools.mk.in
--- a/config/Tools.mk.in	Tue Feb 21 21:54:15 2012 +0100
+++ b/config/Tools.mk.in	Thu Feb 23 14:29:43 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@
 BASH                := @BASH@
diff -r 72fc6b55447b -r 21734a9d2882 tools/configure
--- a/tools/configure	Tue Feb 21 21:54:15 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:29:43 2012 +0100
@@ -637,7 +637,6 @@ XML
 CURL
 FLEX
 BISON
-IP
 PERL
 PYTHON
 APPEND_LIB
@@ -739,7 +738,6 @@ APPEND_INCLUDES
 APPEND_LIB
 PYTHON
 PERL
-IP
 BISON
 FLEX
 CURL
@@ -1394,7 +1392,6 @@ Some influential environment variables:
   APPEND_LIB  List of library folders to append to LDFLAGS (without -L)
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
-  IP          Path to ip tool
   BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
   CURL        Path to curl-config tool
@@ -4158,7 +4155,6 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPE
 
 
 
-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
@@ -4949,51 +4945,6 @@ if test x"${PERL}" == x"no"
 then
     as_fn_error $? "Unable to find perl, please install perl" "$LINENO" 5
 fi
-# Extract the first word of "ip", so it can be a program name with args.
-set dummy ip; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_IP+set}" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $IP in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_IP="$IP" # Let the user override the test with a path.
-  ;;
-  *)
-  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
-    ac_cv_path_IP="$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=$as_save_IFS
-
-  test -z "$ac_cv_path_IP" && ac_cv_path_IP="no"
-  ;;
-esac
-fi
-IP=$ac_cv_path_IP
-if test -n "$IP"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $IP" >&5
-$as_echo "$IP" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-if test x"${IP}" == x"no"
-then
-    as_fn_error $? "Unable to find ip, please install ip" "$LINENO" 5
-fi
 # Extract the first word of "bison", so it can be a program name with args.
 set dummy bison; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
diff -r 72fc6b55447b -r 21734a9d2882 tools/configure.ac
--- a/tools/configure.ac	Tue Feb 21 21:54:15 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
@@ -62,7 +62,6 @@ AX_SET_FLAGS
 
 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
-AC_ARG_VAR([IP], [Path to ip tool])
 AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
 AC_ARG_VAR([CURL], [Path to curl-config tool])
@@ -77,7 +76,6 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
-AX_PATH_PROG_OR_FAIL([IP], [ip])
 AX_PATH_PROG_OR_FAIL([BISON], [bison])
 AX_PATH_PROG_OR_FAIL([FLEX], [flex])
 AS_IF([test "x$xapi" = "xy"], [

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEM-00038V-7n; Thu, 23 Feb 2012 15:05:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEL-00037z-LC
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330009461!61382969!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16273 invoked from network); 23 Feb 2012 15:04:21 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:04:21 -0000
Received: by wibhi20 with SMTP id hi20so1078088wib.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:07 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.83.97 as permitted sender) client-ip=10.180.83.97; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.83.97 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.83.97])
	by 10.180.83.97 with SMTP id p1mr3664040wiy.19.1330009507561 (num_hops
	= 1); Thu, 23 Feb 2012 07:05:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=6PXyO7SRyvv2/vh7i9mUM6wr9fnfP2Sajw1X2bZLT20=;
	b=HLgA9lm5VmpGf3D+g00aaGUoEF5/l8VTTp3qe+CoGr+O5LuBwxxdLXv47002neWpoJ
	qqipxaMpHgVcV87od4tGGLovebiYToJBYKt+8b7wM8m80g6M0VX6Jy+z68ByXNgg9ATr
	ZFtWyCvh1ZeCsLFhIJ3ZE1aqPHhoDNWqQX5AA=
Received: by 10.180.83.97 with SMTP id p1mr2988383wiy.19.1330009507522;
	Thu, 23 Feb 2012 07:05:07 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:37 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 5] Several fixes for autoconf and xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix autoconf under NetBSD and add some tests to Linux xencommons to
check for the necessary tools to run hotplug scripts.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aEM-00038V-7n; Thu, 23 Feb 2012 15:05:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEL-00037z-LC
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330009461!61382969!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16273 invoked from network); 23 Feb 2012 15:04:21 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:04:21 -0000
Received: by wibhi20 with SMTP id hi20so1078088wib.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:07 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.83.97 as permitted sender) client-ip=10.180.83.97; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.83.97 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.83.97])
	by 10.180.83.97 with SMTP id p1mr3664040wiy.19.1330009507561 (num_hops
	= 1); Thu, 23 Feb 2012 07:05:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=6PXyO7SRyvv2/vh7i9mUM6wr9fnfP2Sajw1X2bZLT20=;
	b=HLgA9lm5VmpGf3D+g00aaGUoEF5/l8VTTp3qe+CoGr+O5LuBwxxdLXv47002neWpoJ
	qqipxaMpHgVcV87od4tGGLovebiYToJBYKt+8b7wM8m80g6M0VX6Jy+z68ByXNgg9ATr
	ZFtWyCvh1ZeCsLFhIJ3ZE1aqPHhoDNWqQX5AA=
Received: by 10.180.83.97 with SMTP id p1mr2988383wiy.19.1330009507522;
	Thu, 23 Feb 2012 07:05:07 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:37 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 5] Several fixes for autoconf and xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fix autoconf under NetBSD and add some tests to Linux xencommons to
check for the necessary tools to run hotplug scripts.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aER-00039f-E2; Thu, 23 Feb 2012 15:05:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEP-00038A-9d
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330009461!61382969!3
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16564 invoked from network); 23 Feb 2012 15:04:25 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:04:25 -0000
Received: by mail-wi0-f173.google.com with SMTP id hi20so1078088wib.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:11 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.82.39 as permitted sender) client-ip=10.180.82.39; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.82.39 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.82.39])
	by 10.180.82.39 with SMTP id f7mr4187161wiy.19.1330009511336 (num_hops
	= 1); Thu, 23 Feb 2012 07:05:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=E0VXs+1acZ0jnEWsX2Er6y1P7wpY5tWrRG8UYByiAgI=;
	b=KUOVtXXxkChV+Jgvir+bJq3yZIfok0VwVB6ucPrIEhvtQQKdRH5Yk1dgd3fV3yasb1
	EUC+xKvhXbyyQrToiNpM6tXlYhoxxSibNAzlup0AyJJ1sFzVbKWQ0KqmguR0aEWz+AwC
	m21x+1zFS5hSAdJUsA2MocSdx5Isg/qCUSUEA=
Received: by 10.180.82.39 with SMTP id f7mr3416993wiy.19.1330009511283;
	Thu, 23 Feb 2012 07:05:11 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6c6c59861319b2be13fde935e20b62ead39905ca
Message-Id: <6c6c59861319b2be13fd.1329858641@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:41 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 5] Linux/init: check for brctl and ip at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329811412 -3600
# Node ID 6c6c59861319b2be13fde935e20b62ead39905ca
# Parent  8bd684735341cd4e41aa6ea1047556a88b84f625
Linux/init: check for brctl and ip at xencommons

Check for brctl and ip at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8bd684735341 -r 6c6c59861319 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 14:34:23 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
@@ -50,6 +50,14 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# List of tools needed by xen (hotplug scripts)
+REQ_TOOLS="brctl ip"
+
+for tool in $REQ_TOOLS
+do
+	hash $tool > /dev/null 2>&1 || echo "Warning: $tool not found"
+done
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aER-00039f-E2; Thu, 23 Feb 2012 15:05:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aEP-00038A-9d
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330009461!61382969!3
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16564 invoked from network); 23 Feb 2012 15:04:25 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:04:25 -0000
Received: by mail-wi0-f173.google.com with SMTP id hi20so1078088wib.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:11 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.82.39 as permitted sender) client-ip=10.180.82.39; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.82.39 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.82.39])
	by 10.180.82.39 with SMTP id f7mr4187161wiy.19.1330009511336 (num_hops
	= 1); Thu, 23 Feb 2012 07:05:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=E0VXs+1acZ0jnEWsX2Er6y1P7wpY5tWrRG8UYByiAgI=;
	b=KUOVtXXxkChV+Jgvir+bJq3yZIfok0VwVB6ucPrIEhvtQQKdRH5Yk1dgd3fV3yasb1
	EUC+xKvhXbyyQrToiNpM6tXlYhoxxSibNAzlup0AyJJ1sFzVbKWQ0KqmguR0aEWz+AwC
	m21x+1zFS5hSAdJUsA2MocSdx5Isg/qCUSUEA=
Received: by 10.180.82.39 with SMTP id f7mr3416993wiy.19.1330009511283;
	Thu, 23 Feb 2012 07:05:11 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6c6c59861319b2be13fde935e20b62ead39905ca
Message-Id: <6c6c59861319b2be13fd.1329858641@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:41 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 5] Linux/init: check for brctl and ip at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329811412 -3600
# Node ID 6c6c59861319b2be13fde935e20b62ead39905ca
# Parent  8bd684735341cd4e41aa6ea1047556a88b84f625
Linux/init: check for brctl and ip at xencommons

Check for brctl and ip at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8bd684735341 -r 6c6c59861319 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 14:34:23 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
@@ -50,6 +50,14 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# List of tools needed by xen (hotplug scripts)
+REQ_TOOLS="brctl ip"
+
+for tool in $REQ_TOOLS
+do
+	hash $tool > /dev/null 2>&1 || echo "Warning: $tool not found"
+done
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aER-00039o-RP; Thu, 23 Feb 2012 15:05:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aER-00038O-1S
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330009509!16600674!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11539 invoked from network); 23 Feb 2012 15:05:12 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:05:12 -0000
Received: by mail-ww0-f51.google.com with SMTP id dy1so863685wgb.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:12 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.181.13.113 as permitted sender) client-ip=10.181.13.113; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.181.13.113 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.181.13.113])
	by 10.181.13.113 with SMTP id ex17mr4252497wid.15.1330009512589
	(num_hops = 1); Thu, 23 Feb 2012 07:05:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=IqDP4igjqfvXRPuhKHZinTrUMo2m2UsXDTOlOFGeVl8=;
	b=tEdeMh2+Mpe7bytMfWopd1RB8YubPvm7CH1gmu8x+++NawciYB5RCUOg7nWausCAvf
	3n94OiuwBrah0jUS61ophTN3N9fODX645wes2Zv4Rh7CjHQxfsl8zfmWaealG0VTUeIc
	bSnmvS4U6/xLU7MQ4/ZrzTUS4JrobFWv6LcFQ=
Received: by 10.181.13.113 with SMTP id ex17mr3465054wid.15.1330009512543;
	Thu, 23 Feb 2012 07:05:12 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9fa89fb4ee2b3a587ec537c404a270f0c0e2169d
Message-Id: <9fa89fb4ee2b3a587ec5.1329858642@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 5] Linux/init: check for udev >= 59 at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329814249 -3600
# Node ID 9fa89fb4ee2b3a587ec537c404a270f0c0e2169d
# Parent  6c6c59861319b2be13fde935e20b62ead39905ca
Linux/init: check for udev >= 59 at xencommons

Check for udev at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6c6c59861319 -r 9fa89fb4ee2b tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:50:49 2012 +0100
@@ -58,6 +58,26 @@ do
 	hash $tool > /dev/null 2>&1 || echo "Warning: $tool not found"
 done
 
+# Check for udev >= 59
+if ! hash udevadm > /dev/null 2>&1
+then
+	if ! hash udevinfo > /dev/null 2>&1
+	then
+		echo "Warning: unable to find udevadm or udevinfo"
+	else
+		udevver=`udevinfo -V | awk '{print $NF}'`
+	fi
+else
+	udevver=`udevadm info -V | awk '{print $NF}'`
+fi
+if test -z "${udevver}" || test "${udevver}" -lt 59
+then
+	if ! hash hotplug > /dev/null 2>&1
+	then
+		echo "Warning: udev is too old, upgrade to version 59 or later"
+	fi
+fi
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:05:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aER-00039o-RP; Thu, 23 Feb 2012 15:05:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aER-00038O-1S
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:05:19 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330009509!16600674!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_24_48, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11539 invoked from network); 23 Feb 2012 15:05:12 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:05:12 -0000
Received: by mail-ww0-f51.google.com with SMTP id dy1so863685wgb.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:05:12 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.181.13.113 as permitted sender) client-ip=10.181.13.113; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.181.13.113 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.181.13.113])
	by 10.181.13.113 with SMTP id ex17mr4252497wid.15.1330009512589
	(num_hops = 1); Thu, 23 Feb 2012 07:05:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=IqDP4igjqfvXRPuhKHZinTrUMo2m2UsXDTOlOFGeVl8=;
	b=tEdeMh2+Mpe7bytMfWopd1RB8YubPvm7CH1gmu8x+++NawciYB5RCUOg7nWausCAvf
	3n94OiuwBrah0jUS61ophTN3N9fODX645wes2Zv4Rh7CjHQxfsl8zfmWaealG0VTUeIc
	bSnmvS4U6/xLU7MQ4/ZrzTUS4JrobFWv6LcFQ=
Received: by 10.181.13.113 with SMTP id ex17mr3465054wid.15.1330009512543;
	Thu, 23 Feb 2012 07:05:12 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ft8sm4831117wib.11.2012.02.23.07.05.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Feb 2012 07:05:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9fa89fb4ee2b3a587ec537c404a270f0c0e2169d
Message-Id: <9fa89fb4ee2b3a587ec5.1329858642@debian.localdomain>
In-Reply-To: <patchbomb.1329858637@debian.localdomain>
References: <patchbomb.1329858637@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 21 Feb 2012 22:10:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 5] Linux/init: check for udev >= 59 at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329814249 -3600
# Node ID 9fa89fb4ee2b3a587ec537c404a270f0c0e2169d
# Parent  6c6c59861319b2be13fde935e20b62ead39905ca
Linux/init: check for udev >= 59 at xencommons

Check for udev at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 6c6c59861319 -r 9fa89fb4ee2b tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:50:49 2012 +0100
@@ -58,6 +58,26 @@ do
 	hash $tool > /dev/null 2>&1 || echo "Warning: $tool not found"
 done
 
+# Check for udev >= 59
+if ! hash udevadm > /dev/null 2>&1
+then
+	if ! hash udevinfo > /dev/null 2>&1
+	then
+		echo "Warning: unable to find udevadm or udevinfo"
+	else
+		udevver=`udevinfo -V | awk '{print $NF}'`
+	fi
+else
+	udevver=`udevadm info -V | awk '{print $NF}'`
+fi
+if test -z "${udevver}" || test "${udevver}" -lt 59
+then
+	if ! hash hotplug > /dev/null 2>&1
+	then
+		echo "Warning: udev is too old, upgrade to version 59 or later"
+	fi
+fi
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aFV-0003Vg-GI; Thu, 23 Feb 2012 15:06:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aFT-0003Uz-H5
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:06:23 +0000
Received: from [85.158.139.83:63976] by server-12.bemta-5.messagelabs.com id
	42/C5-05100-EE5564F4; Thu, 23 Feb 2012 15:06:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330009582!12420144!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3887 invoked from network); 23 Feb 2012 15:06:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:06:22 -0000
Received: by werh12 with SMTP id h12so1066140wer.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:06:21 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr4959695wia.3.1330009581927 (num_hops =
	1); Thu, 23 Feb 2012 07:06:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=M+67/JxKfQxJO0mtgqyHf3pZogRS6AvYgrBUiwzBmyU=;
	b=aw6Gj/reeRfyUYDEBAG9b4sG1E/858vcbQmDxtW1zNrYUBrfm1szH2164fw1gijoOS
	R8QKOfxKn/1b1AxSIpqFCShGT65Ux56if2mij84Lz7ekfj7J5Mr+JZxkLEavvwMEPRvZ
	2vatyYdnBruYbJZGrXsv1zpPMMDEAfqDLM+LE=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr4043512wia.3.1330009581854; Thu, 23
	Feb 2012 07:06:21 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 23 Feb 2012 07:06:21 -0800 (PST)
In-Reply-To: <patchbomb.1329815952@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
Date: Thu, 23 Feb 2012 16:06:21 +0100
X-Google-Sender-Auth: 8Ue8O4CxaxxB-j1RMUtNyU4Aw1A
Message-ID: <CAPLaKK5yCRqRY6AkjJ8VDmYd-X9SC=9LJhjPB1UBrbTxNfZx+g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] Linux/init: add udev and brctl
	checks to xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 sent an updated version of this, so forget about this series.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:06:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:06:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0aFV-0003Vg-GI; Thu, 23 Feb 2012 15:06:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0aFT-0003Uz-H5
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 15:06:23 +0000
Received: from [85.158.139.83:63976] by server-12.bemta-5.messagelabs.com id
	42/C5-05100-EE5564F4; Thu, 23 Feb 2012 15:06:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330009582!12420144!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3887 invoked from network); 23 Feb 2012 15:06:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:06:22 -0000
Received: by werh12 with SMTP id h12so1066140wer.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 07:06:21 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr4959695wia.3.1330009581927 (num_hops =
	1); Thu, 23 Feb 2012 07:06:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=M+67/JxKfQxJO0mtgqyHf3pZogRS6AvYgrBUiwzBmyU=;
	b=aw6Gj/reeRfyUYDEBAG9b4sG1E/858vcbQmDxtW1zNrYUBrfm1szH2164fw1gijoOS
	R8QKOfxKn/1b1AxSIpqFCShGT65Ux56if2mij84Lz7ekfj7J5Mr+JZxkLEavvwMEPRvZ
	2vatyYdnBruYbJZGrXsv1zpPMMDEAfqDLM+LE=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr4043512wia.3.1330009581854; Thu, 23
	Feb 2012 07:06:21 -0800 (PST)
Received: by 10.216.213.219 with HTTP; Thu, 23 Feb 2012 07:06:21 -0800 (PST)
In-Reply-To: <patchbomb.1329815952@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
Date: Thu, 23 Feb 2012 16:06:21 +0100
X-Google-Sender-Auth: 8Ue8O4CxaxxB-j1RMUtNyU4Aw1A
Message-ID: <CAPLaKK5yCRqRY6AkjJ8VDmYd-X9SC=9LJhjPB1UBrbTxNfZx+g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] Linux/init: add udev and brctl
	checks to xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 sent an updated version of this, so forget about this series.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15: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 1S0aPe-0004i8-4b; Thu, 23 Feb 2012 15:16:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0aPc-0004hv-Lz
	for Xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:16:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330010206!12304970!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27182 invoked from network); 23 Feb 2012 15:16:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10899508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 15:16:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 15:16:46 +0000
Message-ID: <1330010204.8557.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 15:16:44 +0000
In-Reply-To: <1329995862.8557.83.camel@zakaz.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
	<1329995862.8557.83.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 11:17 +0000, Ian Campbell wrote:
> As another (hopefully simple) idea how about a "xl dom-set-config" or
> similar which (only) updates the config stashed in the userinfo to be
> used on reboot? I would specifically exclude the possibility of this
> reconfiguring the running domain for simplicity.

I've only lightly tested the following, but it seemed to do what I
expected (I used it to change memory from 512 to 1024 for a Windows VM
on reboot).

I think there might be a better name, that better reflects the fact that
it doesn't actually change the config right now, any ideas?
"domain-config-override"?

Thoughts on the general concept?

Ian.
8<-------------------------------------------------------

xl: provide a command to set the saved configuration for a running domain

Pickup this new configuration on reboot.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8b82b7435b7d -r 063d98ba8309 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Feb 23 12:31:18 2012 +0000
+++ b/docs/man/xl.pod.1	Thu Feb 23 15:14:29 2012 +0000
@@ -148,6 +148,31 @@ soon as it is run.
 
 =back
 
+=item B<config-update> B<domid> [I<configfile>] [I<OPTIONS>]
+
+Update the saved configuration for a running domain. This has no
+immediate effect but will be applied when the guest is next
+restarted. This command is useful to ensure that runtime modifications
+made to the guest will be preserved when the guest is restarted.
+
+I<configfile> has to be an absolute path to a file.
+
+B<OPTIONS>
+
+=over 4 
+
+=item B<-f=FILE>, B<--defconfig=FILE>
+
+Use the given configuration file.
+
+=item B<key=value>
+
+It is possible to pass I<key=value> pairs on the command line to provide
+options as if they were written in the configuration file; these override
+whatever is in the I<configfile>.
+
+=back
+
 =item B<console> [I<OPTIONS>] I<domain-id>
 
 Attach to domain I<domain-id>'s console.  If you've set up your domains to
diff -r 8b82b7435b7d -r 063d98ba8309 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl.h	Thu Feb 23 15:14:29 2012 +0000
@@ -50,6 +50,7 @@ int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
 int main_list_vm(int argc, char **argv);
 int main_create(int argc, char **argv);
+int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
 int main_vcpupin(int argc, char **argv);
 int main_vcpuset(int argc, char **argv);
diff -r 8b82b7435b7d -r 063d98ba8309 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 15:14:29 2012 +0000
@@ -1201,11 +1201,31 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
+static void reload_domain_config(libxl_ctx *ctx, uint32_t domid,
+                                 uint8_t **config_data, int *config_len)
+{
+    uint8_t *t_data;
+    int ret, t_len;
+
+    ret = libxl_userdata_retrieve(ctx, domid, "xl", &t_data, &t_len);
+    if (ret) {
+        LOG("failed to retrieve guest configuration (rc=%d). "
+            "reusing old configuration", ret);
+        return;
+    }
+
+    free(*config_data);
+    *config_data = t_data;
+    *config_len = t_len;
+}
+
 /* Returns 1 if domain should be restarted,
  * 2 if domain should be renamed then restarted, or 0 */
 static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
                                libxl_event *event,
+                               uint8_t **config_data, int *config_len,
                                libxl_domain_config *d_config)
+
 {
     int restart = 0;
     libxl_action_on_shutdown action;
@@ -1260,10 +1280,13 @@ static int handle_domain_death(libxl_ctx
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_RESTART_RENAME:
+        reload_domain_config(ctx, domid, config_data, config_len);
         restart = 2;
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_RESTART:
+        reload_domain_config(ctx, domid, config_data, config_len);
+
         restart = 1;
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
@@ -1748,7 +1771,9 @@ start:
             LOG("Domain %d has shut down, reason code %d 0x%x", domid,
                 event->u.domain_shutdown.shutdown_reason,
                 event->u.domain_shutdown.shutdown_reason);
-            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            switch (handle_domain_death(ctx, domid, event,
+                                        (uint8_t **)&config_data, &config_len,
+                                        &d_config)) {
             case 2:
                 if (!preserve_domain(ctx, domid, event, &d_config)) {
                     /* If we fail then exit leaving the old domain in place. */
@@ -1785,6 +1810,12 @@ start:
                     d_config.c_info.name = strdup(common_domname);
                 }
 
+                /* Reparse the configuration in case it has changed */
+                libxl_domain_config_dispose(&d_config);
+                memset(&d_config, 0, sizeof(d_config));
+                parse_config_data(config_file, config_data, config_len,
+                                  &d_config);
+
                 /*
                  * XXX FIXME: If this sleep is not there then domain
                  * re-creation fails sometimes.
@@ -3394,6 +3425,120 @@ int main_create(int argc, char **argv)
     return 0;
 }
 
+int main_config_update(int argc, char **argv)
+{
+    const char *filename = NULL;
+    char *p;
+    char extra_config[1024];
+    void *config_data = 0;
+    int config_len = 0;
+    libxl_domain_config d_config;
+    int opt, rc;
+    int option_index = 0;
+    int debug = 0;
+    static struct option long_options[] = {
+        {"help", 0, 0, 'h'},
+        {"defconfig", 1, 0, 'f'},
+        {0, 0, 0, 0}
+    };
+
+    if (argc < 2) {
+        fprintf(stderr, "xl config-update requires a domain argument\n");
+        help("config-update");
+        exit(1);
+    }
+
+    find_domain(argv[1]);
+    argc--; argv++;
+
+    if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) {
+        filename = argv[1];
+        argc--; argv++;
+    }
+
+    while (1) {
+        opt = getopt_long(argc, argv, "dhqf:", long_options, &option_index);
+        if (opt == -1)
+            break;
+
+        switch (opt) {
+        case 'd':
+            debug = 1;
+            break;
+        case 'f':
+            filename = optarg;
+            break;
+        case 'h':
+            help("create");
+            return 0;
+        default:
+            fprintf(stderr, "option `%c' not supported.\n", optopt);
+            break;
+        }
+    }
+
+    extra_config[0] = '\0';
+    for (p = extra_config; optind < argc; optind++) {
+        if (strchr(argv[optind], '=') != NULL) {
+            p += snprintf(p, sizeof(extra_config) - (p - extra_config),
+                "%s\n", argv[optind]);
+        } else if (!filename) {
+            filename = argv[optind];
+        } else {
+            help("create");
+            return 2;
+        }
+    }
+    if (filename) {
+        free(config_data);  config_data = 0;
+        rc = libxl_read_file_contents(ctx, filename,
+                                      &config_data, &config_len);
+        if (rc) { fprintf(stderr, "Failed to read config file: %s: %s\n",
+                           filename, strerror(errno)); return ERROR_FAIL; }
+        if (strlen(extra_config)) {
+            if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
+                fprintf(stderr, "Failed to attach extra configration\n");
+                exit(1);
+            }
+            /* allocate space for the extra config plus two EOLs plus \0 */
+            config_data = realloc(config_data, config_len
+                + strlen(extra_config) + 2 + 1);
+            if (!config_data) {
+                fprintf(stderr, "Failed to realloc config_data\n");
+                exit(1);
+            }
+            config_len += sprintf(config_data + config_len, "\n%s\n",
+                extra_config);
+        }
+    } else {
+        fprintf(stderr, "Config file not specified\n");
+        exit(1);
+    }
+
+    memset(&d_config, 0x00, sizeof(d_config));
+
+    parse_config_data(filename, config_data, config_len, &d_config);
+
+    if (debug || dryrun_only)
+        printf_info(default_output_format, -1, &d_config);
+
+    if (!dryrun_only) {
+        fprintf(stderr, "setting dom%d configuration\n", domid);
+        rc = libxl_userdata_store(ctx, domid, "xl",
+                                   config_data, config_len);
+        if (rc) {
+            fprintf(stderr, "failed to update configuration\n");
+            exit(1);
+        }
+    }
+
+    libxl_domain_config_dispose(&d_config);
+
+    free(config_data);
+
+    return 0;
+}
+
 static void button_press(const char *p, const char *b)
 {
     libxl_trigger trigger;
@@ -3917,7 +4062,6 @@ static int sched_credit_domain_set(
 {
     int rc;
 
-    
     rc = libxl_sched_credit_domain_set(ctx, domid, scinfo);
     if (rc)
         fprintf(stderr, "libxl_sched_credit_domain_set failed.\n");
diff -r 8b82b7435b7d -r 063d98ba8309 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Thu Feb 23 15:14:29 2012 +0000
@@ -32,6 +32,15 @@ struct cmd_spec cmd_table[] = {
       "-d                      Enable debug messages.\n"
       "-e                      Do not wait in the background for the death of the domain."
     },
+    { "config-update",
+      &main_config_update, 1,
+      "Update a running domain's saved configuration, used when rebuilding "
+      "the domain after reboot",
+      "<Domain> <ConfigFile> [options] [vars]",
+      "-h                      Print this help.\n"
+      "-f FILE, --defconfig=FILE\n                     Use the given configuration file.\n"
+      "-d                      Enable debug messages.\n"
+    },
     { "list",
       &main_list, 0,
       "List information about all/some domains",



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15: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 1S0aPe-0004i8-4b; Thu, 23 Feb 2012 15:16:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0aPc-0004hv-Lz
	for Xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:16:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330010206!12304970!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27182 invoked from network); 23 Feb 2012 15:16:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10899508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 15:16:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 15:16:46 +0000
Message-ID: <1330010204.8557.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 15:16:44 +0000
In-Reply-To: <1329995862.8557.83.camel@zakaz.uk.xensource.com>
References: <20120207170443.GN32046@bitfolk.com>
	<20273.24520.100024.694018@mariner.uk.xensource.com>
	<1328718722.6133.60.camel@zakaz.uk.xensource.com>
	<1329995862.8557.83.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>, Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Re-reading domain configs on domain restart
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 11:17 +0000, Ian Campbell wrote:
> As another (hopefully simple) idea how about a "xl dom-set-config" or
> similar which (only) updates the config stashed in the userinfo to be
> used on reboot? I would specifically exclude the possibility of this
> reconfiguring the running domain for simplicity.

I've only lightly tested the following, but it seemed to do what I
expected (I used it to change memory from 512 to 1024 for a Windows VM
on reboot).

I think there might be a better name, that better reflects the fact that
it doesn't actually change the config right now, any ideas?
"domain-config-override"?

Thoughts on the general concept?

Ian.
8<-------------------------------------------------------

xl: provide a command to set the saved configuration for a running domain

Pickup this new configuration on reboot.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8b82b7435b7d -r 063d98ba8309 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Feb 23 12:31:18 2012 +0000
+++ b/docs/man/xl.pod.1	Thu Feb 23 15:14:29 2012 +0000
@@ -148,6 +148,31 @@ soon as it is run.
 
 =back
 
+=item B<config-update> B<domid> [I<configfile>] [I<OPTIONS>]
+
+Update the saved configuration for a running domain. This has no
+immediate effect but will be applied when the guest is next
+restarted. This command is useful to ensure that runtime modifications
+made to the guest will be preserved when the guest is restarted.
+
+I<configfile> has to be an absolute path to a file.
+
+B<OPTIONS>
+
+=over 4 
+
+=item B<-f=FILE>, B<--defconfig=FILE>
+
+Use the given configuration file.
+
+=item B<key=value>
+
+It is possible to pass I<key=value> pairs on the command line to provide
+options as if they were written in the configuration file; these override
+whatever is in the I<configfile>.
+
+=back
+
 =item B<console> [I<OPTIONS>] I<domain-id>
 
 Attach to domain I<domain-id>'s console.  If you've set up your domains to
diff -r 8b82b7435b7d -r 063d98ba8309 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl.h	Thu Feb 23 15:14:29 2012 +0000
@@ -50,6 +50,7 @@ int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
 int main_list_vm(int argc, char **argv);
 int main_create(int argc, char **argv);
+int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
 int main_vcpupin(int argc, char **argv);
 int main_vcpuset(int argc, char **argv);
diff -r 8b82b7435b7d -r 063d98ba8309 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Feb 23 15:14:29 2012 +0000
@@ -1201,11 +1201,31 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
+static void reload_domain_config(libxl_ctx *ctx, uint32_t domid,
+                                 uint8_t **config_data, int *config_len)
+{
+    uint8_t *t_data;
+    int ret, t_len;
+
+    ret = libxl_userdata_retrieve(ctx, domid, "xl", &t_data, &t_len);
+    if (ret) {
+        LOG("failed to retrieve guest configuration (rc=%d). "
+            "reusing old configuration", ret);
+        return;
+    }
+
+    free(*config_data);
+    *config_data = t_data;
+    *config_len = t_len;
+}
+
 /* Returns 1 if domain should be restarted,
  * 2 if domain should be renamed then restarted, or 0 */
 static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
                                libxl_event *event,
+                               uint8_t **config_data, int *config_len,
                                libxl_domain_config *d_config)
+
 {
     int restart = 0;
     libxl_action_on_shutdown action;
@@ -1260,10 +1280,13 @@ static int handle_domain_death(libxl_ctx
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_RESTART_RENAME:
+        reload_domain_config(ctx, domid, config_data, config_len);
         restart = 2;
         break;
 
     case LIBXL_ACTION_ON_SHUTDOWN_RESTART:
+        reload_domain_config(ctx, domid, config_data, config_len);
+
         restart = 1;
         /* fall-through */
     case LIBXL_ACTION_ON_SHUTDOWN_DESTROY:
@@ -1748,7 +1771,9 @@ start:
             LOG("Domain %d has shut down, reason code %d 0x%x", domid,
                 event->u.domain_shutdown.shutdown_reason,
                 event->u.domain_shutdown.shutdown_reason);
-            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            switch (handle_domain_death(ctx, domid, event,
+                                        (uint8_t **)&config_data, &config_len,
+                                        &d_config)) {
             case 2:
                 if (!preserve_domain(ctx, domid, event, &d_config)) {
                     /* If we fail then exit leaving the old domain in place. */
@@ -1785,6 +1810,12 @@ start:
                     d_config.c_info.name = strdup(common_domname);
                 }
 
+                /* Reparse the configuration in case it has changed */
+                libxl_domain_config_dispose(&d_config);
+                memset(&d_config, 0, sizeof(d_config));
+                parse_config_data(config_file, config_data, config_len,
+                                  &d_config);
+
                 /*
                  * XXX FIXME: If this sleep is not there then domain
                  * re-creation fails sometimes.
@@ -3394,6 +3425,120 @@ int main_create(int argc, char **argv)
     return 0;
 }
 
+int main_config_update(int argc, char **argv)
+{
+    const char *filename = NULL;
+    char *p;
+    char extra_config[1024];
+    void *config_data = 0;
+    int config_len = 0;
+    libxl_domain_config d_config;
+    int opt, rc;
+    int option_index = 0;
+    int debug = 0;
+    static struct option long_options[] = {
+        {"help", 0, 0, 'h'},
+        {"defconfig", 1, 0, 'f'},
+        {0, 0, 0, 0}
+    };
+
+    if (argc < 2) {
+        fprintf(stderr, "xl config-update requires a domain argument\n");
+        help("config-update");
+        exit(1);
+    }
+
+    find_domain(argv[1]);
+    argc--; argv++;
+
+    if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) {
+        filename = argv[1];
+        argc--; argv++;
+    }
+
+    while (1) {
+        opt = getopt_long(argc, argv, "dhqf:", long_options, &option_index);
+        if (opt == -1)
+            break;
+
+        switch (opt) {
+        case 'd':
+            debug = 1;
+            break;
+        case 'f':
+            filename = optarg;
+            break;
+        case 'h':
+            help("create");
+            return 0;
+        default:
+            fprintf(stderr, "option `%c' not supported.\n", optopt);
+            break;
+        }
+    }
+
+    extra_config[0] = '\0';
+    for (p = extra_config; optind < argc; optind++) {
+        if (strchr(argv[optind], '=') != NULL) {
+            p += snprintf(p, sizeof(extra_config) - (p - extra_config),
+                "%s\n", argv[optind]);
+        } else if (!filename) {
+            filename = argv[optind];
+        } else {
+            help("create");
+            return 2;
+        }
+    }
+    if (filename) {
+        free(config_data);  config_data = 0;
+        rc = libxl_read_file_contents(ctx, filename,
+                                      &config_data, &config_len);
+        if (rc) { fprintf(stderr, "Failed to read config file: %s: %s\n",
+                           filename, strerror(errno)); return ERROR_FAIL; }
+        if (strlen(extra_config)) {
+            if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) {
+                fprintf(stderr, "Failed to attach extra configration\n");
+                exit(1);
+            }
+            /* allocate space for the extra config plus two EOLs plus \0 */
+            config_data = realloc(config_data, config_len
+                + strlen(extra_config) + 2 + 1);
+            if (!config_data) {
+                fprintf(stderr, "Failed to realloc config_data\n");
+                exit(1);
+            }
+            config_len += sprintf(config_data + config_len, "\n%s\n",
+                extra_config);
+        }
+    } else {
+        fprintf(stderr, "Config file not specified\n");
+        exit(1);
+    }
+
+    memset(&d_config, 0x00, sizeof(d_config));
+
+    parse_config_data(filename, config_data, config_len, &d_config);
+
+    if (debug || dryrun_only)
+        printf_info(default_output_format, -1, &d_config);
+
+    if (!dryrun_only) {
+        fprintf(stderr, "setting dom%d configuration\n", domid);
+        rc = libxl_userdata_store(ctx, domid, "xl",
+                                   config_data, config_len);
+        if (rc) {
+            fprintf(stderr, "failed to update configuration\n");
+            exit(1);
+        }
+    }
+
+    libxl_domain_config_dispose(&d_config);
+
+    free(config_data);
+
+    return 0;
+}
+
 static void button_press(const char *p, const char *b)
 {
     libxl_trigger trigger;
@@ -3917,7 +4062,6 @@ static int sched_credit_domain_set(
 {
     int rc;
 
-    
     rc = libxl_sched_credit_domain_set(ctx, domid, scinfo);
     if (rc)
         fprintf(stderr, "libxl_sched_credit_domain_set failed.\n");
diff -r 8b82b7435b7d -r 063d98ba8309 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Feb 23 12:31:18 2012 +0000
+++ b/tools/libxl/xl_cmdtable.c	Thu Feb 23 15:14:29 2012 +0000
@@ -32,6 +32,15 @@ struct cmd_spec cmd_table[] = {
       "-d                      Enable debug messages.\n"
       "-e                      Do not wait in the background for the death of the domain."
     },
+    { "config-update",
+      &main_config_update, 1,
+      "Update a running domain's saved configuration, used when rebuilding "
+      "the domain after reboot",
+      "<Domain> <ConfigFile> [options] [vars]",
+      "-h                      Print this help.\n"
+      "-f FILE, --defconfig=FILE\n                     Use the given configuration file.\n"
+      "-d                      Enable debug messages.\n"
+    },
     { "list",
       &main_list, 0,
       "List information about all/some domains",



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15: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 1S0aQ9-0004l1-IB; Thu, 23 Feb 2012 15:17:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0aQ8-0004kB-JD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:17:24 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330010191!61385392!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4640 invoked from network); 23 Feb 2012 15:16:32 -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; 23 Feb 2012 15:16:32 -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 q1NFHCwB011273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 15:17:13 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1NFHB30003049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 15:17:12 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
	q1NFHASN030622; Thu, 23 Feb 2012 09:17:10 -0600
Received: from [114.253.101.209] (/114.253.101.209)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 07:17:10 -0800
Message-ID: <4F46586D.30605@oracle.com>
Date: Thu, 23 Feb 2012 23:17:01 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: annie li <annie.li@oracle.com>
References: <4F41F41F.9060601@oracle.com>	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	<4F430201.3040208@oracle.com>	<1329908701.2880.26.camel@zakaz.uk.xensource.com>	<4F44E94A.2060209@oracle.com>
	<1329919132.8557.2.camel@zakaz.uk.xensource.com>
	<4F4652BB.4020809@oracle.com>
In-Reply-To: <4F4652BB.4020809@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F465879.0197,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-2-23 22:52, annie li wrote:
>
>
> On 2012-2-22 21:58, Ian Campbell wrote:
>>
>> Yes, this looks plausible to me (although I'm no expert on this code).
>> Something similar happens in rtc_next_second.
>> Perhaps it would be better to add a function or macro to do the
>> conversion, such that it is somewhat self documenting? Or at least make
>> the 1900 a #define with a suitable name.
>>   
> I changed the 1900 to a macro and added a new function get_year. The 
> new patch is attached.
Sorry, two macro define: epoch_year and get_year.

Thanks
Annie

                {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15: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 1S0aQ9-0004l1-IB; Thu, 23 Feb 2012 15:17:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1S0aQ8-0004kB-JD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:17:24 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330010191!61385392!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4640 invoked from network); 23 Feb 2012 15:16:32 -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; 23 Feb 2012 15:16:32 -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 q1NFHCwB011273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 15:17:13 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1NFHB30003049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 15:17:12 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
	q1NFHASN030622; Thu, 23 Feb 2012 09:17:10 -0600
Received: from [114.253.101.209] (/114.253.101.209)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 07:17:10 -0800
Message-ID: <4F46586D.30605@oracle.com>
Date: Thu, 23 Feb 2012 23:17:01 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: annie li <annie.li@oracle.com>
References: <4F41F41F.9060601@oracle.com>	<A9667DDFB95DB7438FA9D7D576C3D87E073EDE@SHSMSX101.ccr.corp.intel.com>	<CABaSDNjRaqEKCQuxTRRXpXQnEW4=4Yo_HW7hFObyRhbn8HD+Aw@mail.gmail.com>	<A9667DDFB95DB7438FA9D7D576C3D87E07565C@SHSMSX101.ccr.corp.intel.com>	<4F430201.3040208@oracle.com>	<1329908701.2880.26.camel@zakaz.uk.xensource.com>	<4F44E94A.2060209@oracle.com>
	<1329919132.8557.2.camel@zakaz.uk.xensource.com>
	<4F4652BB.4020809@oracle.com>
In-Reply-To: <4F4652BB.4020809@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F465879.0197,ss=1,re=0.000,fgs=0
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	young zhang <young.zhang.free@gmail.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvm: Correct RTC time offset update error
 due to tm->tm_year
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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-2-23 22:52, annie li wrote:
>
>
> On 2012-2-22 21:58, Ian Campbell wrote:
>>
>> Yes, this looks plausible to me (although I'm no expert on this code).
>> Something similar happens in rtc_next_second.
>> Perhaps it would be better to add a function or macro to do the
>> conversion, such that it is somewhat self documenting? Or at least make
>> the 1900 a #define with a suitable name.
>>   
> I changed the 1900 to a macro and added a new function get_year. The 
> new patch is attached.
Sorry, two macro define: epoch_year and get_year.

Thanks
Annie

                {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0ad1-0005br-E6; Thu, 23 Feb 2012 15:30:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0acz-0005bF-Om
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:30:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330011034!9491969!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10580 invoked from network); 23 Feb 2012 15:30:35 -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; 23 Feb 2012 15:30:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0acp-0007kh-NQ; Thu, 23 Feb 2012 15:30:31 +0000
Date: Thu, 23 Feb 2012 15:30:31 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223153031.GG25694@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
	<8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

I'm about to repost this patch, with a few other changes and fixups. 
Further comments below.

At 12:57 -0800 on 17 Feb (1329483430), Andres Lagar-Cavilla wrote:
> > At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
> >> Well, thanks for taking a stab at it. Looks fairly well. My main
> >> observation is that we do not want to unconditionally go on a wait queue
> >> everywhere. For example, the grant table code pretty reliable unwinds
> >> itself and correctly tells the grant mapper to retry, in the presence of
> >> a
> >> paged page.
> >
> > The grant table code is unlikely to hit a paged-out gfn in the caller's
> > address space.
> 
> Oh yeah they do. At least for the target gfn's behind the grants. That's
> why we need the retry loops in the PV backends in dom0.

The target gfns aren't in the caller's p2m, though. 

> > The balloon code should not be trying to populate at all!
> 
> Agreed. get_gfn_query is needed there. Nothing bad happens because we
> immediately send drop_page. But it's wrong-ish.

Fixed

> >> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
> >> wait queue code is invoked only there. And then we can call
> >> get_gfn_sleep
> >> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.
> >
> > I see.  In the longer term I definitely do not want get_gfn()'s callers
> > to have to deal with p2m_is_paged(), and PoD, and sharing, and every
> > other p2m hack we come up with.  I want all that stuff hidden behind
> > get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.
> >
> > I don't like get_gfn_sleep() very much but I'll see if I can find a way
> > to do the equivalent with a flag to get_gfn_*().  But I suspect it will
> > end up with a tri-state argument of:
> >  a) just give me the current state;
> >  b) try (without sleeping) to fix up paging, PoD and sharing but
> >     still maybe make me handle it myself by error propagation; and
> >  c) just fix it up.
> >
> > 'b' is a pretty weird interface.  Specially given that in corner cases,
> > 'make me handle it' might involve hitting a wait queue anyway.  If we
> > intend in the fullness of time to get rid of it (as I hope we would)
> > then probably we shouldn't introduce it.  (And if that means pushing
> > this whole change out past 4.2, we should consider doing that.)
> >
> It's weird. b) is an evolutionary side-effect. It should disappear. I
> guess what I'm arguing for is "it should disappear in the long term, not
> on a patch so close to 4.2"

Well, I tried making the 'but don't go to a waitq' flag; the
implementation is trivial on top of the patches I'm about to post but
the question of when to set it was so ugly I gave up.

I have hit another stumbling block though - get_two_gfns() can't be
safely ask get_gfn to populate or unshare if that might involve a waitq,
since by definition one of its two calls is made with a lock held.  I
can't see a nice way of having it retry (not one that's guaranteed to
make progress) without pulling the fixup-and-retry up into that
function.  I might do that in the next revision.

> > Can't be soon enough for me.  I've been sharpening the axe for that one
> > for years now. :)
> 
> What's stopping the death blow?

People said they still need it.

> >> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
> >> still have the mfn in place.
> >
> > Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
> > not, it really should.
> 
> It's not about populate, it's about killing the domain unnecessarily in
> the in_atomic check.

Oh I see, thanks.  Fixed.

> >> >> +
> >> >> +        /* Safety catch: it _should_ be safe to wait here but if
> >> it's
> >> >> not,
> >> >> +         * crash the VM, not the host */
> >> >> +        if ( in_atomic() )
> >> >> +        {
> >> >> +            WARN();
> >> >> +            domain_crash(p2m->domain);
> >> >> +        }
> >> >> +        else
> >> >> +        {
> >> >> +            current->arch.mem_paging_gfn = gfn;
> >> >> +            wait_event(current->arch.mem_paging_wq, ({
> >> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
> >> >> +                                             p2m_query, page_order);
> >> >> +                        (*t != p2m_ram_paging_in);
> >>
> >> Well, first of all mfn->get_entry will not happen in a locked context,
> >> so
> >> you will exit the wait loop not holding the p2m lock and crash later.
> >
> > Yes - we always exit the loop without the lock; then we 'goto again' and
> > do things properly.  I realise it's a bit inefficient, but on the
> > page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
> > write the version that handled the locking in this loop but it got a bit
> > twisty, plus we need the 'goto again' for other reasons (see below).
> 
> Yes, but, you'll be reading the p2m in a racy manner.

I don't think there are any real races here.  Either we see
p2m_paging_in (and someone will eventually wake us when it pages in) 
or we don't (and we go back and do the lookup safely).

> > As a follow-up I ought to make the page-sharing fixup code that's just
> > below this use 'goto again' as well; we shouldn't really leave this
> > function until we get a lookup where all these cases are dealt with.

On closer inspection the page-sharing version is OK because it doesn't
release the lock, and the unshare function won't leave us with a
paged-out page.

> I think we won't be able to have a magic
> get_gfn_solve_everything_silently() call until we find a solution to the
> fact that get_gfn happens in locked contexts.

Yes, I agree, and I'm coming round to the opinion that we might be too
late to fix that in 4.2. :|

> I've though about a wacky
> idea that
> 1. schedules a sleep-n-retry softirq
> 2. fails the call
> 3. avoids crashing the domain on the unwind path
> 4. when executing softirqs pauses the vcpu as per 1.
> 5. When woken up retries the last failed hypercall/vmexit/whatever
> 
> I shouldn't have said that out loud...

The first time I approached the idea of paging guest RAM (before Patrick
started on the current system) I prototyped something not a million
miles from this (basically, a sort of setjmp() on hypervisor entry) but
the question of making all hypercalls and VMEXITs idempotent scared me
off. :)

> >> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >> >> {
> >> >>     struct vcpu *v = current;
> >> >> -    mem_event_request_t req;
> >> >> +    mem_event_request_t req = {0};
> >> >>     p2m_type_t p2mt;
> >> >>     p2m_access_t a;
> >> >>     mfn_t mfn;
> >> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> >> +    int send_request = 0;
> >> >>
> >> >>     /* We're paging. There should be a ring */
> >> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> >>
> >> Given all the optimizations around the send_request flag, it might be
> >> worth moving the claim_slot call to an if(send_request) block at the
> >> bottom, and get rid of cancel_slot altogether. Claim_slot could
> >> potentially go (or cause someone else to go) to a wait queue, and it's
> >> best to not be that rude.
> >
> > Sure.  It might be tricky to make sure we unwind properly in the failure
> > case, but I'll have a go at a follow-up patch that looks at that.
> >
> > (This is not really a regression in this patch AFAICS - in the existing
> > code
> > the get_gfn() callers end up calling this function anyway.)
> 
> *After* they've put gfn. Not a regression, just cleaner code imo.

This is also called after putting the gfn - but in any case I've
reshuffled the mem_event_claim_slot in the new version.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0ad1-0005br-E6; Thu, 23 Feb 2012 15:30:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0acz-0005bF-Om
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:30:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330011034!9491969!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10580 invoked from network); 23 Feb 2012 15:30:35 -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; 23 Feb 2012 15:30:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0acp-0007kh-NQ; Thu, 23 Feb 2012 15:30:31 +0000
Date: Thu, 23 Feb 2012 15:30:31 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223153031.GG25694@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
	<8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

I'm about to repost this patch, with a few other changes and fixups. 
Further comments below.

At 12:57 -0800 on 17 Feb (1329483430), Andres Lagar-Cavilla wrote:
> > At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
> >> Well, thanks for taking a stab at it. Looks fairly well. My main
> >> observation is that we do not want to unconditionally go on a wait queue
> >> everywhere. For example, the grant table code pretty reliable unwinds
> >> itself and correctly tells the grant mapper to retry, in the presence of
> >> a
> >> paged page.
> >
> > The grant table code is unlikely to hit a paged-out gfn in the caller's
> > address space.
> 
> Oh yeah they do. At least for the target gfn's behind the grants. That's
> why we need the retry loops in the PV backends in dom0.

The target gfns aren't in the caller's p2m, though. 

> > The balloon code should not be trying to populate at all!
> 
> Agreed. get_gfn_query is needed there. Nothing bad happens because we
> immediately send drop_page. But it's wrong-ish.

Fixed

> >> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if the
> >> wait queue code is invoked only there. And then we can call
> >> get_gfn_sleep
> >> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.
> >
> > I see.  In the longer term I definitely do not want get_gfn()'s callers
> > to have to deal with p2m_is_paged(), and PoD, and sharing, and every
> > other p2m hack we come up with.  I want all that stuff hidden behind
> > get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.
> >
> > I don't like get_gfn_sleep() very much but I'll see if I can find a way
> > to do the equivalent with a flag to get_gfn_*().  But I suspect it will
> > end up with a tri-state argument of:
> >  a) just give me the current state;
> >  b) try (without sleeping) to fix up paging, PoD and sharing but
> >     still maybe make me handle it myself by error propagation; and
> >  c) just fix it up.
> >
> > 'b' is a pretty weird interface.  Specially given that in corner cases,
> > 'make me handle it' might involve hitting a wait queue anyway.  If we
> > intend in the fullness of time to get rid of it (as I hope we would)
> > then probably we shouldn't introduce it.  (And if that means pushing
> > this whole change out past 4.2, we should consider doing that.)
> >
> It's weird. b) is an evolutionary side-effect. It should disappear. I
> guess what I'm arguing for is "it should disappear in the long term, not
> on a patch so close to 4.2"

Well, I tried making the 'but don't go to a waitq' flag; the
implementation is trivial on top of the patches I'm about to post but
the question of when to set it was so ugly I gave up.

I have hit another stumbling block though - get_two_gfns() can't be
safely ask get_gfn to populate or unshare if that might involve a waitq,
since by definition one of its two calls is made with a lock held.  I
can't see a nice way of having it retry (not one that's guaranteed to
make progress) without pulling the fixup-and-retry up into that
function.  I might do that in the next revision.

> > Can't be soon enough for me.  I've been sharpening the axe for that one
> > for years now. :)
> 
> What's stopping the death blow?

People said they still need it.

> >> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
> >> still have the mfn in place.
> >
> > Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
> > not, it really should.
> 
> It's not about populate, it's about killing the domain unnecessarily in
> the in_atomic check.

Oh I see, thanks.  Fixed.

> >> >> +
> >> >> +        /* Safety catch: it _should_ be safe to wait here but if
> >> it's
> >> >> not,
> >> >> +         * crash the VM, not the host */
> >> >> +        if ( in_atomic() )
> >> >> +        {
> >> >> +            WARN();
> >> >> +            domain_crash(p2m->domain);
> >> >> +        }
> >> >> +        else
> >> >> +        {
> >> >> +            current->arch.mem_paging_gfn = gfn;
> >> >> +            wait_event(current->arch.mem_paging_wq, ({
> >> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
> >> >> +                                             p2m_query, page_order);
> >> >> +                        (*t != p2m_ram_paging_in);
> >>
> >> Well, first of all mfn->get_entry will not happen in a locked context,
> >> so
> >> you will exit the wait loop not holding the p2m lock and crash later.
> >
> > Yes - we always exit the loop without the lock; then we 'goto again' and
> > do things properly.  I realise it's a bit inefficient, but on the
> > page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
> > write the version that handled the locking in this loop but it got a bit
> > twisty, plus we need the 'goto again' for other reasons (see below).
> 
> Yes, but, you'll be reading the p2m in a racy manner.

I don't think there are any real races here.  Either we see
p2m_paging_in (and someone will eventually wake us when it pages in) 
or we don't (and we go back and do the lookup safely).

> > As a follow-up I ought to make the page-sharing fixup code that's just
> > below this use 'goto again' as well; we shouldn't really leave this
> > function until we get a lookup where all these cases are dealt with.

On closer inspection the page-sharing version is OK because it doesn't
release the lock, and the unshare function won't leave us with a
paged-out page.

> I think we won't be able to have a magic
> get_gfn_solve_everything_silently() call until we find a solution to the
> fact that get_gfn happens in locked contexts.

Yes, I agree, and I'm coming round to the opinion that we might be too
late to fix that in 4.2. :|

> I've though about a wacky
> idea that
> 1. schedules a sleep-n-retry softirq
> 2. fails the call
> 3. avoids crashing the domain on the unwind path
> 4. when executing softirqs pauses the vcpu as per 1.
> 5. When woken up retries the last failed hypercall/vmexit/whatever
> 
> I shouldn't have said that out loud...

The first time I approached the idea of paging guest RAM (before Patrick
started on the current system) I prototyped something not a million
miles from this (basically, a sort of setjmp() on hypervisor entry) but
the question of making all hypercalls and VMEXITs idempotent scared me
off. :)

> >> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >> >> {
> >> >>     struct vcpu *v = current;
> >> >> -    mem_event_request_t req;
> >> >> +    mem_event_request_t req = {0};
> >> >>     p2m_type_t p2mt;
> >> >>     p2m_access_t a;
> >> >>     mfn_t mfn;
> >> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> >> +    int send_request = 0;
> >> >>
> >> >>     /* We're paging. There should be a ring */
> >> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> >>
> >> Given all the optimizations around the send_request flag, it might be
> >> worth moving the claim_slot call to an if(send_request) block at the
> >> bottom, and get rid of cancel_slot altogether. Claim_slot could
> >> potentially go (or cause someone else to go) to a wait queue, and it's
> >> best to not be that rude.
> >
> > Sure.  It might be tricky to make sure we unwind properly in the failure
> > case, but I'll have a go at a follow-up patch that looks at that.
> >
> > (This is not really a regression in this patch AFAICS - in the existing
> > code
> > the get_gfn() callers end up calling this function anyway.)
> 
> *After* they've put gfn. Not a regression, just cleaner code imo.

This is also called after putting the gfn - but in any case I've
reshuffled the mem_event_claim_slot in the new version.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0akI-00062N-BD; Thu, 23 Feb 2012 15:38:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0akG-00062B-3K
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:38:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330011485!16606962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28229 invoked from network); 23 Feb 2012 15:38:06 -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;
	23 Feb 2012 15:38:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10900344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 15:37:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 15:37:43 +0000
Message-ID: <1330011462.8557.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Date: Thu, 23 Feb 2012 15:37:42 +0000
In-Reply-To: <4F4651A7020000780007F749@nat28.tlf.novell.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
> >On 23/02/12 10:07, Ian Campbell wrote:
> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> Can you confirm that you need an OVMF which matches the OS bit-width you
> >> are installing. i..e that there is no support for booting a 32 bit EFI
> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >
> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
> >possibly work.
> 
> Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
of loading a 32 bit OS?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:38:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0akI-00062N-BD; Thu, 23 Feb 2012 15:38:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0akG-00062B-3K
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:38:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330011485!16606962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28229 invoked from network); 23 Feb 2012 15:38:06 -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;
	23 Feb 2012 15:38:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10900344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 15:37:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 15:37:43 +0000
Message-ID: <1330011462.8557.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Date: Thu, 23 Feb 2012 15:37:42 +0000
In-Reply-To: <4F4651A7020000780007F749@nat28.tlf.novell.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
> >On 23/02/12 10:07, Ian Campbell wrote:
> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> Can you confirm that you need an OVMF which matches the OS bit-width you
> >> are installing. i..e that there is no support for booting a 32 bit EFI
> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >
> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
> >possibly work.
> 
> Native EFI requires bit-matched OS loaders,

Is that a shortcoming of EFI generally or just this implementation?

Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
of loading a 32 bit OS?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:39:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15: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 1S0alj-0006Aq-V5; Thu, 23 Feb 2012 15:39:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0ali-0006AV-Tn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:39:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330011576!2321430!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20156 invoked from network); 23 Feb 2012 15:39:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:39:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10900401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 15:39:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 15:39:36 +0000
Date: Thu, 23 Feb 2012 15:45:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329482789.3131.71.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329482789.3131.71.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual 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 Fri, 17 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> > If the vgic needs to inject a virtual irq into the guest, but no free
> > LR registers are available, add the irq to a list and return.
> > Whenever an LR register becomes available we add the queued irq to it
> > and remove it from the list.
> > We use the gic lock to protect the list and the bitmask.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c           |   61 ++++++++++++++++++++++++++++++++++++++---
> >  xen/include/asm-arm/domain.h |    1 +
> >  2 files changed, 57 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index adc10bb..520a400 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -25,6 +25,7 @@
> >  #include <xen/sched.h>
> >  #include <xen/errno.h>
> >  #include <xen/softirq.h>
> > +#include <xen/list.h>
> >  #include <asm/p2m.h>
> >  #include <asm/domain.h>
> >  
> > @@ -45,6 +46,8 @@ static struct {
> >      unsigned int lines;
> >      unsigned int cpus;
> >      spinlock_t lock;
> > +    uint64_t lr_mask;
> 
> Is there somewhere in the code which clamps the number of LRs reported
> by the h/w to 64? (and warns appropriately)

The hardware spec :)
64 is the maximum number of LR registers.


> This is a mask of in-use LRs, right?

Yes


> > +    struct list_head lr_pending;
> >  } gic;
> >  
> >  irq_desc_t irq_desc[NR_IRQS];
> > @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
> >  
> >      GICH[GICH_HCR] = GICH_HCR_EN;
> >      GICH[GICH_MISR] = GICH_MISR_EOI;
> > +    gic.lr_mask = 0ULL;
> > +    INIT_LIST_HEAD(&gic.lr_pending);
> >  }
> >  
> >  /* Set up the GIC */
> > @@ -345,16 +350,51 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
> >      return rc;
> >  }
> >  
> > -void gic_set_guest_irq(unsigned int virtual_irq,
> > +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
> >          unsigned int state, unsigned int priority)
> >  {
> > -    BUG_ON(virtual_irq > nr_lrs);
> > -    GICH[GICH_LR + virtual_irq] = state |
> > +    BUG_ON(lr > nr_lrs);
> > +    GICH[GICH_LR + lr] = state |
> >          GICH_LR_MAINTENANCE_IRQ |
> >          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> >          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >  }
> >  
> > +void gic_set_guest_irq(unsigned int virtual_irq,
> > +        unsigned int state, unsigned int priority)
> > +{
> > +    int i;
> > +    struct pending_irq *iter, *n;
> > +
> > +    spin_lock(&gic.lock);
> > +
> > +    if ( list_empty(&gic.lr_pending) )
> > +    {
> > +        for (i = 0; i < nr_lrs; i++) {
> 
> One of the bitops.h functions should be usable avoid this loop. We don't
> seem to have a find-and-set type operation so you still need the lock.
> 
> Do we have any per-LR state which we keep? If we did then it be worth
> chaining them into a free list, which you could cheaply enqueue and
> dequeue entries from.
> 
> > +            if (!test_and_set_bit(i, &gic.lr_mask))
> 
> test_and_set_bit is atomic which is unnecessary since you are also
> protecting this field with a lock, or if you use the find_first_zero
> idea you could just use __set_bit.

good idea


> > +            {
> > +                gic_set_lr(i, virtual_irq, state, priority);
> > +                spin_unlock(&gic.lock);
> > +                return;
> > +            }
> > +        }
> > +    }
> > +
> > +    n = irq_to_pending(current, virtual_irq);
> > +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> > +    {
> > +        if ( iter->priority < priority )
> > +        {
> > +            list_add_tail(&n->lr_link, &iter->lr_link);
> > +            spin_unlock(&gic.lock);
> > +            return;
> > +        }
> > +    }
> > +    list_add(&n->lr_link, &gic.lr_pending);
> > +    spin_unlock(&gic.lock);
> 
> I'm not sure I follow the logic here -- it seems that only one IRQ will
> ever be pending in the LRs at a time, but if we've got 4 LRs wouldn't we
> want to have 4 active at once and only trap every 4 Acks?
> 
> If there's only going to be one active LR then we can jut always use LR0
> and do away with the bitmap for the time being.

We have two lists: one list, inflight_irqs, is kept by the vgic to keep
track of which irqs the vgic has injected and have not been eoi'd by the
guest yet.

The second list, gic.lr_pending, is a list of irqs that from the vgic
POV have been already injected (they have been added to
inflight_irqs already) but because of hardware limitations
(limited availability of LR registers) the gic hasn't been able to
inject them yet.

Here we are going through the second list, gic.lr_pending, that is
ordered by priority, and we are inserting this last guest irq in the
right spot so that as soon as an LR register is available we can
actually inject it into the guest.

The vgic is not actually aware that the gic hasn't managed to inject the
irq yet.



> Are interrupts only on lr_pending if they are not active in an LR?

Yes


> Are
> pending irqs which are in an lr kept in a list somewhere else?

They are in inflight_irqs until eoi'd by the guest.


> Also it would be nice to have a single exit and unlock path.

OK


> > +    return;
> > +}
> > +
> >  void gic_inject_irq_start(void)
> >  {
> >      uint32_t hcr;
> > @@ -435,13 +475,25 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >      uint32_t lr;
> >      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
> >  
> > -    for ( i = 0; i < 64; i++ ) {
> > +    for ( i = 0; i < nr_lrs; i++ ) {
> >          if ( eisr & ((uint64_t)1 << i) ) {
> 
> This loop and test could also use a call to whichever bitops.h thing is
> appropriate.
> 
> Maybe doesn't matter for loops of the order of 64 iterations but would
> be a nice cleanup to make.

OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:39:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15: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 1S0alj-0006Aq-V5; Thu, 23 Feb 2012 15:39:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0ali-0006AV-Tn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:39:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330011576!2321430!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20156 invoked from network); 23 Feb 2012 15:39:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 15:39:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10900401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 15:39:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 15:39:36 +0000
Date: Thu, 23 Feb 2012 15:45:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1329482789.3131.71.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329482789.3131.71.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual 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 Fri, 17 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-15 at 14:03 +0000, Stefano Stabellini wrote:
> > If the vgic needs to inject a virtual irq into the guest, but no free
> > LR registers are available, add the irq to a list and return.
> > Whenever an LR register becomes available we add the queued irq to it
> > and remove it from the list.
> > We use the gic lock to protect the list and the bitmask.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c           |   61 ++++++++++++++++++++++++++++++++++++++---
> >  xen/include/asm-arm/domain.h |    1 +
> >  2 files changed, 57 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index adc10bb..520a400 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -25,6 +25,7 @@
> >  #include <xen/sched.h>
> >  #include <xen/errno.h>
> >  #include <xen/softirq.h>
> > +#include <xen/list.h>
> >  #include <asm/p2m.h>
> >  #include <asm/domain.h>
> >  
> > @@ -45,6 +46,8 @@ static struct {
> >      unsigned int lines;
> >      unsigned int cpus;
> >      spinlock_t lock;
> > +    uint64_t lr_mask;
> 
> Is there somewhere in the code which clamps the number of LRs reported
> by the h/w to 64? (and warns appropriately)

The hardware spec :)
64 is the maximum number of LR registers.


> This is a mask of in-use LRs, right?

Yes


> > +    struct list_head lr_pending;
> >  } gic;
> >  
> >  irq_desc_t irq_desc[NR_IRQS];
> > @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
> >  
> >      GICH[GICH_HCR] = GICH_HCR_EN;
> >      GICH[GICH_MISR] = GICH_MISR_EOI;
> > +    gic.lr_mask = 0ULL;
> > +    INIT_LIST_HEAD(&gic.lr_pending);
> >  }
> >  
> >  /* Set up the GIC */
> > @@ -345,16 +350,51 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
> >      return rc;
> >  }
> >  
> > -void gic_set_guest_irq(unsigned int virtual_irq,
> > +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
> >          unsigned int state, unsigned int priority)
> >  {
> > -    BUG_ON(virtual_irq > nr_lrs);
> > -    GICH[GICH_LR + virtual_irq] = state |
> > +    BUG_ON(lr > nr_lrs);
> > +    GICH[GICH_LR + lr] = state |
> >          GICH_LR_MAINTENANCE_IRQ |
> >          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> >          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >  }
> >  
> > +void gic_set_guest_irq(unsigned int virtual_irq,
> > +        unsigned int state, unsigned int priority)
> > +{
> > +    int i;
> > +    struct pending_irq *iter, *n;
> > +
> > +    spin_lock(&gic.lock);
> > +
> > +    if ( list_empty(&gic.lr_pending) )
> > +    {
> > +        for (i = 0; i < nr_lrs; i++) {
> 
> One of the bitops.h functions should be usable avoid this loop. We don't
> seem to have a find-and-set type operation so you still need the lock.
> 
> Do we have any per-LR state which we keep? If we did then it be worth
> chaining them into a free list, which you could cheaply enqueue and
> dequeue entries from.
> 
> > +            if (!test_and_set_bit(i, &gic.lr_mask))
> 
> test_and_set_bit is atomic which is unnecessary since you are also
> protecting this field with a lock, or if you use the find_first_zero
> idea you could just use __set_bit.

good idea


> > +            {
> > +                gic_set_lr(i, virtual_irq, state, priority);
> > +                spin_unlock(&gic.lock);
> > +                return;
> > +            }
> > +        }
> > +    }
> > +
> > +    n = irq_to_pending(current, virtual_irq);
> > +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> > +    {
> > +        if ( iter->priority < priority )
> > +        {
> > +            list_add_tail(&n->lr_link, &iter->lr_link);
> > +            spin_unlock(&gic.lock);
> > +            return;
> > +        }
> > +    }
> > +    list_add(&n->lr_link, &gic.lr_pending);
> > +    spin_unlock(&gic.lock);
> 
> I'm not sure I follow the logic here -- it seems that only one IRQ will
> ever be pending in the LRs at a time, but if we've got 4 LRs wouldn't we
> want to have 4 active at once and only trap every 4 Acks?
> 
> If there's only going to be one active LR then we can jut always use LR0
> and do away with the bitmap for the time being.

We have two lists: one list, inflight_irqs, is kept by the vgic to keep
track of which irqs the vgic has injected and have not been eoi'd by the
guest yet.

The second list, gic.lr_pending, is a list of irqs that from the vgic
POV have been already injected (they have been added to
inflight_irqs already) but because of hardware limitations
(limited availability of LR registers) the gic hasn't been able to
inject them yet.

Here we are going through the second list, gic.lr_pending, that is
ordered by priority, and we are inserting this last guest irq in the
right spot so that as soon as an LR register is available we can
actually inject it into the guest.

The vgic is not actually aware that the gic hasn't managed to inject the
irq yet.



> Are interrupts only on lr_pending if they are not active in an LR?

Yes


> Are
> pending irqs which are in an lr kept in a list somewhere else?

They are in inflight_irqs until eoi'd by the guest.


> Also it would be nice to have a single exit and unlock path.

OK


> > +    return;
> > +}
> > +
> >  void gic_inject_irq_start(void)
> >  {
> >      uint32_t hcr;
> > @@ -435,13 +475,25 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
> >      uint32_t lr;
> >      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
> >  
> > -    for ( i = 0; i < 64; i++ ) {
> > +    for ( i = 0; i < nr_lrs; i++ ) {
> >          if ( eisr & ((uint64_t)1 << i) ) {
> 
> This loop and test could also use a call to whichever bitops.h thing is
> appropriate.
> 
> Maybe doesn't matter for loops of the order of 64 iterations but would
> be a nice cleanup to make.

OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0b1H-00079y-04; Thu, 23 Feb 2012 15:55:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0b1F-00079m-7o
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:55:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330012537!16135311!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMzc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11147 invoked from network); 23 Feb 2012 15:55:37 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-216.messagelabs.com with SMTP;
	23 Feb 2012 15:55:37 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 999FB71406F;
	Thu, 23 Feb 2012 07:55:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=FCi2Q5bRucm/ieN6FOU6fW06ti5Tj8Lz/xC8ZzUbabmG
	F/cCxCeF+m5nT/st3IBebtQUEXIPNIHrsqvkYIoZ0VJ3Z5CujQoG7QoTTFmSSDly
	+YE3KwcUzC+MbK79UnwhJlcJJP8c0mmRvIBt9Z8WNR4DXljSWPVuXX+SmPsbThg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=G9Glnf/ogi7oo6g3sjXWY4nKWKU=; b=Au/9ZFtc
	IvqagcLuJy0pkG573a13w1DAMt1AOphzfIbbJdHw0zfJNAYQhZmxR5YeUD+ukWK7
	z1odYjIZS1HfMTeU0Lbn/0DBDEUU9uGdxATvn6+IHDHCq1T7gOgzNK8Y+6t6jZZV
	dhbU3DBOyyT0Lz372l0h02qffPPvTWxZLj8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id EA9FF71406B; 
	Thu, 23 Feb 2012 07:55:35 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 23 Feb 2012 07:55:36 -0800
Message-ID: <5634f0a8b91c7bb18c9e85fd76fcaaf1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120223153031.GG25694@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
	<8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
	<20120223153031.GG25694@ocelot.phlegethon.org>
Date: Thu, 23 Feb 2012 07:55:36 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi,
>
> I'm about to repost this patch, with a few other changes and fixups.
> Further comments below.
>
> At 12:57 -0800 on 17 Feb (1329483430), Andres Lagar-Cavilla wrote:
>> > At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
>> >> Well, thanks for taking a stab at it. Looks fairly well. My main
>> >> observation is that we do not want to unconditionally go on a wait
>> queue
>> >> everywhere. For example, the grant table code pretty reliable unwinds
>> >> itself and correctly tells the grant mapper to retry, in the presence
>> of
>> >> a
>> >> paged page.
>> >
>> > The grant table code is unlikely to hit a paged-out gfn in the
>> caller's
>> > address space.
>>
>> Oh yeah they do. At least for the target gfn's behind the grants. That's
>> why we need the retry loops in the PV backends in dom0.
>
> The target gfns aren't in the caller's p2m, though.
>
>> > The balloon code should not be trying to populate at all!
>>
>> Agreed. get_gfn_query is needed there. Nothing bad happens because we
>> immediately send drop_page. But it's wrong-ish.
>
> Fixed
>
>> >> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if
>> the
>> >> wait queue code is invoked only there. And then we can call
>> >> get_gfn_sleep
>> >> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.
>> >
>> > I see.  In the longer term I definitely do not want get_gfn()'s
>> callers
>> > to have to deal with p2m_is_paged(), and PoD, and sharing, and every
>> > other p2m hack we come up with.  I want all that stuff hidden behind
>> > get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.
>> >
>> > I don't like get_gfn_sleep() very much but I'll see if I can find a
>> way
>> > to do the equivalent with a flag to get_gfn_*().  But I suspect it
>> will
>> > end up with a tri-state argument of:
>> >  a) just give me the current state;
>> >  b) try (without sleeping) to fix up paging, PoD and sharing but
>> >     still maybe make me handle it myself by error propagation; and
>> >  c) just fix it up.
>> >
>> > 'b' is a pretty weird interface.  Specially given that in corner
>> cases,
>> > 'make me handle it' might involve hitting a wait queue anyway.  If we
>> > intend in the fullness of time to get rid of it (as I hope we would)
>> > then probably we shouldn't introduce it.  (And if that means pushing
>> > this whole change out past 4.2, we should consider doing that.)
>> >
>> It's weird. b) is an evolutionary side-effect. It should disappear. I
>> guess what I'm arguing for is "it should disappear in the long term, not
>> on a patch so close to 4.2"
>
> Well, I tried making the 'but don't go to a waitq' flag; the
> implementation is trivial on top of the patches I'm about to post but
> the question of when to set it was so ugly I gave up.
>
> I have hit another stumbling block though - get_two_gfns() can't be
> safely ask get_gfn to populate or unshare if that might involve a waitq,
> since by definition one of its two calls is made with a lock held.  I
> can't see a nice way of having it retry (not one that's guaranteed to
> make progress) without pulling the fixup-and-retry up into that
> function.  I might do that in the next revision.

One way to do this is use query_unlocked on the second. If we sense
danger, drop the lock on the first, then do the right thing for the
second, then drop the lock for the second, then retry at the top.
Front-runner for ugliest-thing-in-the-hypervisor award.

hvm_task_switch also gets two gfns, although in a manner that prevents
easily using get_two_gfns (hvm_map_entry on gdt offsets). It's unlikely
this will ever be a problem (it's somewhat reasonable to expect both gdt
entries to fall in the same gfn) but it's something worth keeping in mind.

>
>> > Can't be soon enough for me.  I've been sharpening the axe for that
>> one
>> > for years now. :)
>>
>> What's stopping the death blow?
>
> People said they still need it.
>
>> >> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
>> >> still have the mfn in place.
>> >
>> > Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
>> > not, it really should.
>>
>> It's not about populate, it's about killing the domain unnecessarily in
>> the in_atomic check.
>
> Oh I see, thanks.  Fixed.
>
>> >> >> +
>> >> >> +        /* Safety catch: it _should_ be safe to wait here but if
>> >> it's
>> >> >> not,
>> >> >> +         * crash the VM, not the host */
>> >> >> +        if ( in_atomic() )
>> >> >> +        {
>> >> >> +            WARN();
>> >> >> +            domain_crash(p2m->domain);
>> >> >> +        }
>> >> >> +        else
>> >> >> +        {
>> >> >> +            current->arch.mem_paging_gfn = gfn;
>> >> >> +            wait_event(current->arch.mem_paging_wq, ({
>> >> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
>> >> >> +                                             p2m_query,
>> page_order);
>> >> >> +                        (*t != p2m_ram_paging_in);
>> >>
>> >> Well, first of all mfn->get_entry will not happen in a locked
>> context,
>> >> so
>> >> you will exit the wait loop not holding the p2m lock and crash later.
>> >
>> > Yes - we always exit the loop without the lock; then we 'goto again'
>> and
>> > do things properly.  I realise it's a bit inefficient, but on the
>> > page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
>> > write the version that handled the locking in this loop but it got a
>> bit
>> > twisty, plus we need the 'goto again' for other reasons (see below).
>>
>> Yes, but, you'll be reading the p2m in a racy manner.
>
> I don't think there are any real races here.  Either we see
> p2m_paging_in (and someone will eventually wake us when it pages in)
> or we don't (and we go back and do the lookup safely).
>
>> > As a follow-up I ought to make the page-sharing fixup code that's just
>> > below this use 'goto again' as well; we shouldn't really leave this
>> > function until we get a lookup where all these cases are dealt with.
>
> On closer inspection the page-sharing version is OK because it doesn't
> release the lock, and the unshare function won't leave us with a
> paged-out page.
>
>> I think we won't be able to have a magic
>> get_gfn_solve_everything_silently() call until we find a solution to the
>> fact that get_gfn happens in locked contexts.
>
> Yes, I agree, and I'm coming round to the opinion that we might be too
> late to fix that in 4.2. :|
>
>> I've though about a wacky
>> idea that
>> 1. schedules a sleep-n-retry softirq
>> 2. fails the call
>> 3. avoids crashing the domain on the unwind path
>> 4. when executing softirqs pauses the vcpu as per 1.
>> 5. When woken up retries the last failed hypercall/vmexit/whatever
>>
>> I shouldn't have said that out loud...
>
> The first time I approached the idea of paging guest RAM (before Patrick
> started on the current system) I prototyped something not a million
> miles from this (basically, a sort of setjmp() on hypervisor entry) but
> the question of making all hypercalls and VMEXITs idempotent scared me
> off. :)
>

We've used long jump-like stuff. It's fragile, but it carried us through
the day. It's a non-starter here, I hope.

Looking forward to the new patch.
Andres

>> >> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >> >> {
>> >> >>     struct vcpu *v = current;
>> >> >> -    mem_event_request_t req;
>> >> >> +    mem_event_request_t req = {0};
>> >> >>     p2m_type_t p2mt;
>> >> >>     p2m_access_t a;
>> >> >>     mfn_t mfn;
>> >> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> >> >> +    int send_request = 0;
>> >> >>
>> >> >>     /* We're paging. There should be a ring */
>> >> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
>> >>
>> >> Given all the optimizations around the send_request flag, it might be
>> >> worth moving the claim_slot call to an if(send_request) block at the
>> >> bottom, and get rid of cancel_slot altogether. Claim_slot could
>> >> potentially go (or cause someone else to go) to a wait queue, and
>> it's
>> >> best to not be that rude.
>> >
>> > Sure.  It might be tricky to make sure we unwind properly in the
>> failure
>> > case, but I'll have a go at a follow-up patch that looks at that.
>> >
>> > (This is not really a regression in this patch AFAICS - in the
>> existing
>> > code
>> > the get_gfn() callers end up calling this function anyway.)
>>
>> *After* they've put gfn. Not a regression, just cleaner code imo.
>
> This is also called after putting the gfn - but in any case I've
> reshuffled the mem_event_claim_slot in the new version.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:56:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0b1H-00079y-04; Thu, 23 Feb 2012 15:55:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0b1F-00079m-7o
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:55:45 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330012537!16135311!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMzc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11147 invoked from network); 23 Feb 2012 15:55:37 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-15.tower-216.messagelabs.com with SMTP;
	23 Feb 2012 15:55:37 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 999FB71406F;
	Thu, 23 Feb 2012 07:55:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=FCi2Q5bRucm/ieN6FOU6fW06ti5Tj8Lz/xC8ZzUbabmG
	F/cCxCeF+m5nT/st3IBebtQUEXIPNIHrsqvkYIoZ0VJ3Z5CujQoG7QoTTFmSSDly
	+YE3KwcUzC+MbK79UnwhJlcJJP8c0mmRvIBt9Z8WNR4DXljSWPVuXX+SmPsbThg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=G9Glnf/ogi7oo6g3sjXWY4nKWKU=; b=Au/9ZFtc
	IvqagcLuJy0pkG573a13w1DAMt1AOphzfIbbJdHw0zfJNAYQhZmxR5YeUD+ukWK7
	z1odYjIZS1HfMTeU0Lbn/0DBDEUU9uGdxATvn6+IHDHCq1T7gOgzNK8Y+6t6jZZV
	dhbU3DBOyyT0Lz372l0h02qffPPvTWxZLj8=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id EA9FF71406B; 
	Thu, 23 Feb 2012 07:55:35 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 23 Feb 2012 07:55:36 -0800
Message-ID: <5634f0a8b91c7bb18c9e85fd76fcaaf1.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120223153031.GG25694@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
	<8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
	<20120223153031.GG25694@ocelot.phlegethon.org>
Date: Thu, 23 Feb 2012 07:55:36 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi,
>
> I'm about to repost this patch, with a few other changes and fixups.
> Further comments below.
>
> At 12:57 -0800 on 17 Feb (1329483430), Andres Lagar-Cavilla wrote:
>> > At 08:05 -0800 on 17 Feb (1329465959), Andres Lagar-Cavilla wrote:
>> >> Well, thanks for taking a stab at it. Looks fairly well. My main
>> >> observation is that we do not want to unconditionally go on a wait
>> queue
>> >> everywhere. For example, the grant table code pretty reliable unwinds
>> >> itself and correctly tells the grant mapper to retry, in the presence
>> of
>> >> a
>> >> paged page.
>> >
>> > The grant table code is unlikely to hit a paged-out gfn in the
>> caller's
>> > address space.
>>
>> Oh yeah they do. At least for the target gfn's behind the grants. That's
>> why we need the retry loops in the PV backends in dom0.
>
> The target gfns aren't in the caller's p2m, though.
>
>> > The balloon code should not be trying to populate at all!
>>
>> Agreed. get_gfn_query is needed there. Nothing bad happens because we
>> immediately send drop_page. But it's wrong-ish.
>
> Fixed
>
>> >> Hence I had proposed introducing get_gfn_sleep, and I'd be happy if
>> the
>> >> wait queue code is invoked only there. And then we can call
>> >> get_gfn_sleep
>> >> in vmx_load_pdptrs, in guest page table walks, and in __hvm_copy.
>> >
>> > I see.  In the longer term I definitely do not want get_gfn()'s
>> callers
>> > to have to deal with p2m_is_paged(), and PoD, and sharing, and every
>> > other p2m hack we come up with.  I want all that stuff hidden behind
>> > get_gfn_*(), with at most a flag to say 'fix up magic MM tricks'.
>> >
>> > I don't like get_gfn_sleep() very much but I'll see if I can find a
>> way
>> > to do the equivalent with a flag to get_gfn_*().  But I suspect it
>> will
>> > end up with a tri-state argument of:
>> >  a) just give me the current state;
>> >  b) try (without sleeping) to fix up paging, PoD and sharing but
>> >     still maybe make me handle it myself by error propagation; and
>> >  c) just fix it up.
>> >
>> > 'b' is a pretty weird interface.  Specially given that in corner
>> cases,
>> > 'make me handle it' might involve hitting a wait queue anyway.  If we
>> > intend in the fullness of time to get rid of it (as I hope we would)
>> > then probably we shouldn't introduce it.  (And if that means pushing
>> > this whole change out past 4.2, we should consider doing that.)
>> >
>> It's weird. b) is an evolutionary side-effect. It should disappear. I
>> guess what I'm arguing for is "it should disappear in the long term, not
>> on a patch so close to 4.2"
>
> Well, I tried making the 'but don't go to a waitq' flag; the
> implementation is trivial on top of the patches I'm about to post but
> the question of when to set it was so ugly I gave up.
>
> I have hit another stumbling block though - get_two_gfns() can't be
> safely ask get_gfn to populate or unshare if that might involve a waitq,
> since by definition one of its two calls is made with a lock held.  I
> can't see a nice way of having it retry (not one that's guaranteed to
> make progress) without pulling the fixup-and-retry up into that
> function.  I might do that in the next revision.

One way to do this is use query_unlocked on the second. If we sense
danger, drop the lock on the first, then do the right thing for the
second, then drop the lock for the second, then retry at the top.
Front-runner for ugliest-thing-in-the-hypervisor award.

hvm_task_switch also gets two gfns, although in a manner that prevents
easily using get_two_gfns (hvm_map_entry on gdt offsets). It's unlikely
this will ever be a problem (it's somewhat reasonable to expect both gdt
entries to fall in the same gfn) but it's something worth keeping in mind.

>
>> > Can't be soon enough for me.  I've been sharpening the axe for that
>> one
>> > for years now. :)
>>
>> What's stopping the death blow?
>
> People said they still need it.
>
>> >> You want to make sure the mfn is not valid. For p2m_ram_paging_out we
>> >> still have the mfn in place.
>> >
>> > Doesn't p2m_mem_paging_populate already DTRT in all these cases?  If
>> > not, it really should.
>>
>> It's not about populate, it's about killing the domain unnecessarily in
>> the in_atomic check.
>
> Oh I see, thanks.  Fixed.
>
>> >> >> +
>> >> >> +        /* Safety catch: it _should_ be safe to wait here but if
>> >> it's
>> >> >> not,
>> >> >> +         * crash the VM, not the host */
>> >> >> +        if ( in_atomic() )
>> >> >> +        {
>> >> >> +            WARN();
>> >> >> +            domain_crash(p2m->domain);
>> >> >> +        }
>> >> >> +        else
>> >> >> +        {
>> >> >> +            current->arch.mem_paging_gfn = gfn;
>> >> >> +            wait_event(current->arch.mem_paging_wq, ({
>> >> >> +                        mfn = p2m->get_entry(p2m, gfn, t, a,
>> >> >> +                                             p2m_query,
>> page_order);
>> >> >> +                        (*t != p2m_ram_paging_in);
>> >>
>> >> Well, first of all mfn->get_entry will not happen in a locked
>> context,
>> >> so
>> >> you will exit the wait loop not holding the p2m lock and crash later.
>> >
>> > Yes - we always exit the loop without the lock; then we 'goto again'
>> and
>> > do things properly.  I realise it's a bit inefficient, but on the
>> > page-in path the p2m lookups shouldn't be the bottleneck. :)  I did
>> > write the version that handled the locking in this loop but it got a
>> bit
>> > twisty, plus we need the 'goto again' for other reasons (see below).
>>
>> Yes, but, you'll be reading the p2m in a racy manner.
>
> I don't think there are any real races here.  Either we see
> p2m_paging_in (and someone will eventually wake us when it pages in)
> or we don't (and we go back and do the lookup safely).
>
>> > As a follow-up I ought to make the page-sharing fixup code that's just
>> > below this use 'goto again' as well; we shouldn't really leave this
>> > function until we get a lookup where all these cases are dealt with.
>
> On closer inspection the page-sharing version is OK because it doesn't
> release the lock, and the unshare function won't leave us with a
> paged-out page.
>
>> I think we won't be able to have a magic
>> get_gfn_solve_everything_silently() call until we find a solution to the
>> fact that get_gfn happens in locked contexts.
>
> Yes, I agree, and I'm coming round to the opinion that we might be too
> late to fix that in 4.2. :|
>
>> I've though about a wacky
>> idea that
>> 1. schedules a sleep-n-retry softirq
>> 2. fails the call
>> 3. avoids crashing the domain on the unwind path
>> 4. when executing softirqs pauses the vcpu as per 1.
>> 5. When woken up retries the last failed hypercall/vmexit/whatever
>>
>> I shouldn't have said that out loud...
>
> The first time I approached the idea of paging guest RAM (before Patrick
> started on the current system) I prototyped something not a million
> miles from this (basically, a sort of setjmp() on hypervisor entry) but
> the question of making all hypercalls and VMEXITs idempotent scared me
> off. :)
>

We've used long jump-like stuff. It's fragile, but it carried us through
the day. It's a non-starter here, I hope.

Looking forward to the new patch.
Andres

>> >> >> void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >> >> {
>> >> >>     struct vcpu *v = current;
>> >> >> -    mem_event_request_t req;
>> >> >> +    mem_event_request_t req = {0};
>> >> >>     p2m_type_t p2mt;
>> >> >>     p2m_access_t a;
>> >> >>     mfn_t mfn;
>> >> >>     struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> >> >> +    int send_request = 0;
>> >> >>
>> >> >>     /* We're paging. There should be a ring */
>> >> >>     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
>> >>
>> >> Given all the optimizations around the send_request flag, it might be
>> >> worth moving the claim_slot call to an if(send_request) block at the
>> >> bottom, and get rid of cancel_slot altogether. Claim_slot could
>> >> potentially go (or cause someone else to go) to a wait queue, and
>> it's
>> >> best to not be that rude.
>> >
>> > Sure.  It might be tricky to make sure we unwind properly in the
>> failure
>> > case, but I'll have a go at a follow-up patch that looks at that.
>> >
>> > (This is not really a regression in this patch AFAICS - in the
>> existing
>> > code
>> > the get_gfn() callers end up calling this function anyway.)
>>
>> *After* they've put gfn. Not a regression, just cleaner code imo.
>
> This is also called after putting the gfn - but in any case I've
> reshuffled the mem_event_claim_slot in the new version.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:56:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:56:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0b1u-0007CV-DY; Thu, 23 Feb 2012 15:56:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0b1t-0007Bz-Si
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:56:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330012579!16069518!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 23 Feb 2012 15:56:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 15:56:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0b1n-0007sq-07; Thu, 23 Feb 2012 15:56:19 +0000
Date: Thu, 23 Feb 2012 15:56:18 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120223155618.GH25694@ocelot.phlegethon.org>
References: <patchbomb.1329772680@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329772680@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] remove type from mem_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 22:18 +0100 on 20 Feb (1329776280), Olaf Hering wrote:
> 
> The intention of the first patch was to shrink mem_event_st to make room
> for more events in the ring buffer. But since type is just u16 and the
> struct would need much more shrinking to get more events per ring this
> goal was not reached.
> 
> Now both patches just serve as cleanup.

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 15:56:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 15:56:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0b1u-0007CV-DY; Thu, 23 Feb 2012 15:56:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0b1t-0007Bz-Si
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 15:56:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330012579!16069518!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 23 Feb 2012 15:56:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 15:56:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0b1n-0007sq-07; Thu, 23 Feb 2012 15:56:19 +0000
Date: Thu, 23 Feb 2012 15:56:18 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120223155618.GH25694@ocelot.phlegethon.org>
References: <patchbomb.1329772680@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329772680@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 2] remove type from mem_event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 22:18 +0100 on 20 Feb (1329776280), Olaf Hering wrote:
> 
> The intention of the first patch was to shrink mem_event_st to make room
> for more events in the ring buffer. But since type is just u16 and the
> struct would need much more shrinking to get more events per ring this
> goal was not reached.
> 
> Now both patches just serve as cleanup.

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bDA-0007wc-JR; Thu, 23 Feb 2012 16:08:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bD9-0007wX-HJ
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:08:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330013277!14614504!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12202 invoked from network); 23 Feb 2012 16:07:57 -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; 23 Feb 2012 16:07:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0bD1-0007uW-PS; Thu, 23 Feb 2012 16:07:55 +0000
Date: Thu, 23 Feb 2012 16:07:55 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223160755.GI25694@ocelot.phlegethon.org>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 7] Mem event ring setup interface 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

At 01:05 -0500 on 23 Feb (1329959105), Andres Lagar-Cavilla wrote:
> Update the interface for setting up mem event rings (for sharing, mem access or
> paging).
> 
> Remove the "shared page", which was a waste of a whole page for a single event
> channel port value.
> 
> More importantly, both the shared page and the ring page were dom0 user-space
> process pages mapped by the hypervisor. If the dom0 process does not clean up,
> the hypervisor keeps posting events (and holding a map) to a page now belonging
> to another process.
> 
> Solutions proposed:
> - Pass the event channel port explicitly as part of the domctl payload.
> - Reserve a pfn in the guest physmap for a each mem event ring. Set/retrieve
> these pfns via hvm params. Ensure they are set during build and restore, and
> retrieved during save. Ensure these pages don't leak and domains are left zombie.
> 
> In all cases mem events consumers in-tree (xenpaging and xen-access) have been
> updated.
> 
> Updating the interface to deal with these problems requires
> backwards-incompatible changes on both the helper<->libxc and
> libxc<->hypervisor interfaces.
5A> 
> Take advantage of the interface update to plumb setting up of the sharing ring,
> which was missing.
> 
> All patches touch x86/mm hypervisor bits. Patches 1, 3 and 5 are tools patches
> as well.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

For the Xen parts:
Acked-by: Tim Deegan <tim@xen.org>

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bDA-0007wc-JR; Thu, 23 Feb 2012 16:08:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bD9-0007wX-HJ
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:08:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330013277!14614504!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12202 invoked from network); 23 Feb 2012 16:07:57 -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; 23 Feb 2012 16:07:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0bD1-0007uW-PS; Thu, 23 Feb 2012 16:07:55 +0000
Date: Thu, 23 Feb 2012 16:07:55 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223160755.GI25694@ocelot.phlegethon.org>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1329977105@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 7] Mem event ring setup interface 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

At 01:05 -0500 on 23 Feb (1329959105), Andres Lagar-Cavilla wrote:
> Update the interface for setting up mem event rings (for sharing, mem access or
> paging).
> 
> Remove the "shared page", which was a waste of a whole page for a single event
> channel port value.
> 
> More importantly, both the shared page and the ring page were dom0 user-space
> process pages mapped by the hypervisor. If the dom0 process does not clean up,
> the hypervisor keeps posting events (and holding a map) to a page now belonging
> to another process.
> 
> Solutions proposed:
> - Pass the event channel port explicitly as part of the domctl payload.
> - Reserve a pfn in the guest physmap for a each mem event ring. Set/retrieve
> these pfns via hvm params. Ensure they are set during build and restore, and
> retrieved during save. Ensure these pages don't leak and domains are left zombie.
> 
> In all cases mem events consumers in-tree (xenpaging and xen-access) have been
> updated.
> 
> Updating the interface to deal with these problems requires
> backwards-incompatible changes on both the helper<->libxc and
> libxc<->hypervisor interfaces.
5A> 
> Take advantage of the interface update to plumb setting up of the sharing ring,
> which was missing.
> 
> All patches touch x86/mm hypervisor bits. Patches 1, 3 and 5 are tools patches
> as well.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

For the Xen parts:
Acked-by: Tim Deegan <tim@xen.org>

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bEi-00082z-2h; Thu, 23 Feb 2012 16:09:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1S0bEg-00082i-4A
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:09:38 +0000
Received: from [85.158.139.83:15175] by server-7.bemta-5.messagelabs.com id
	66/D8-16195-1C4664F4; Thu, 23 Feb 2012 16:09:37 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330013375!12490483!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2393 invoked from network); 23 Feb 2012 16:09:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:09:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22382302"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:09:34 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Thu, 23 Feb 2012
	11:09:34 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 23 Feb 2012 11:09:38 -0500
Thread-Topic: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwQMeKjMMBX2CPRpih3BdESm407wAd6VwAAApPlwAAA3afAAAF9pNwAE8XiTA=
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EE281AA@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
	<1329837682.3990.114.camel@zakaz.uk.xensource.com>
	<9F57BF860713DF4BA3EFA4F8C6DFEDAC382173FC@ORSMSX101.amr.corp.intel.com>
In-Reply-To: <9F57BF860713DF4BA3EFA4F8C6DFEDAC382173FC@ORSMSX101.amr.corp.intel.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: "Cihula, Joseph" <joseph.cihula@intel.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Cihula, Joseph [mailto:joseph.cihula@intel.com]
> Sent: Tuesday, February 21, 2012 3:35 PM
> To: Ian Campbell; Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> 
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> > Sent: Tuesday, February 21, 2012 7:21 AM
> >
> > On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > > To: Ross Philipson
> > > > Cc: xen-devel@lists.xensource.com
> > > > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough
> > > > support
> > > >
> > > > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > > > Updates to the layout of the HVM parameter and information page
> > > > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > > > written to the bottom half of this page.
> > > >
> > > > We would like to eventually get rid of the HVM info page and would
> > > > certainly like to avoid adding anything further there. Could this
> > > > data not be supplied via xenstore? Certainly they could and should
> > > > be for the ones controlled by the flags entry which you add.
> > > >
> > > > Ian.
> > > >
> > >
> > > Ah I did not realize that. The original incarnation of this code
> > > came from 2+ years ago. I have no objection to using xenstore but I
> > > did not think xenstore was suitable for passing arbitrary blocks of
> > > binary data (i.e. the raw SMBIOS firmware tables). Perhaps I am
> > > incorrect in this assumption.
> >
> > I think in principal binary data is supported, but its use is
> > discouraged. docs/misc/xenstore.txt talks about it a bit.
> >
> > For well defined entries it should be reasonable to have human
> > readable content in xenstore which simply enable/disables the table
> and perhaps contains some configuration values as appropriate.
> >
> > For adding arbitrary tables I'm less sure what the right answer is.
> > Common header elements in human readable form, payload as hex encoded
> > strings or something? Seems a bit icky though.
> >
> > > I am not sure what other mechanisms could be employed. In other code
> > > I use in out hvmloader, I pass an ACPI SSDT to the hvmloader at
> runtime.
> > > I use a little DMAish interface I built into qemu to push the SSDT
> > > to hvmloader while it is building the ACPI tables. Something like
> > > this could be used but I don't really want to get qemu involved in
> > > this operation.
> >
> > Yes, I think we should avoid that too.
> >
> > > I guess a third option might be to have a facility to load extra
> > > modules/files into the new domain at start time and specify their
> > > gpa's in xenstore. They could then be discarded after the initial
> > > domain setup is complete.
> >
> > That might work. What do others around here think?
> >
> > Ian.
> 
> In deciding which approach to use, you should keep in mind that
> eventually it will be desirable to measure the VM (i.e. into a virtual
> TPM).  So if the data is going to be processed by code that is TPM-
> aware, then any approach to getting it the data should allow for
> measurement.  But if the processing code is not TPM-aware and is
> measured by the domain builder code, then the data should be provided in
> a way that the domain builder can easily measure it.
> 
> Joe

Joe, thanks for the feedback. From the other comments I have received, I believe I will use an approach where bits of virtual firmware like passed in SMBIOS tables (or other pieces I am working on like ACPI SSDTs that are passed in at runtime) will be loaded into the new guest as a set of modules. These modules will solely be for consumption by hvmloader. In light of this, I believe the latter of the two scenarios you mentioned will be the case; that a domain builder measures the initial building blocks like hvmloader any associated modules.

The area I am still considering though is dealing with platform firmware updates and how they would be reflected in a given set of hvmloader modules where obviously changing those modules would mean a different measurement. More broadly, I guess I don't know enough about how changes to platform firmware is handled with respect of platform measurements (and it seems to me the case of the guest and vTPMs is just an extension of this)?

Ross

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bEi-00082z-2h; Thu, 23 Feb 2012 16:09:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1S0bEg-00082i-4A
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:09:38 +0000
Received: from [85.158.139.83:15175] by server-7.bemta-5.messagelabs.com id
	66/D8-16195-1C4664F4; Thu, 23 Feb 2012 16:09:37 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330013375!12490483!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2393 invoked from network); 23 Feb 2012 16:09:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:09:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22382302"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:09:34 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Thu, 23 Feb 2012
	11:09:34 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 23 Feb 2012 11:09:38 -0500
Thread-Topic: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
Thread-Index: AczwQMeKjMMBX2CPRpih3BdESm407wAd6VwAAApPlwAAA3afAAAF9pNwAE8XiTA=
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724EE281AA@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724EC323D8@FTLPMAILBOX02.citrite.net>
	<1329814018.25232.3.camel@dagon.hellion.org.uk>
	<831D55AF5A11D64C9B4B43F59EEBF720724EC323F0@FTLPMAILBOX02.citrite.net>
	<1329837682.3990.114.camel@zakaz.uk.xensource.com>
	<9F57BF860713DF4BA3EFA4F8C6DFEDAC382173FC@ORSMSX101.amr.corp.intel.com>
In-Reply-To: <9F57BF860713DF4BA3EFA4F8C6DFEDAC382173FC@ORSMSX101.amr.corp.intel.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: "Cihula, Joseph" <joseph.cihula@intel.com>
Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Cihula, Joseph [mailto:joseph.cihula@intel.com]
> Sent: Tuesday, February 21, 2012 3:35 PM
> To: Ian Campbell; Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> 
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> > Sent: Tuesday, February 21, 2012 7:21 AM
> >
> > On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > > To: Ross Philipson
> > > > Cc: xen-devel@lists.xensource.com
> > > > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough
> > > > support
> > > >
> > > > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > > > Updates to the layout of the HVM parameter and information page
> > > > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > > > written to the bottom half of this page.
> > > >
> > > > We would like to eventually get rid of the HVM info page and would
> > > > certainly like to avoid adding anything further there. Could this
> > > > data not be supplied via xenstore? Certainly they could and should
> > > > be for the ones controlled by the flags entry which you add.
> > > >
> > > > Ian.
> > > >
> > >
> > > Ah I did not realize that. The original incarnation of this code
> > > came from 2+ years ago. I have no objection to using xenstore but I
> > > did not think xenstore was suitable for passing arbitrary blocks of
> > > binary data (i.e. the raw SMBIOS firmware tables). Perhaps I am
> > > incorrect in this assumption.
> >
> > I think in principal binary data is supported, but its use is
> > discouraged. docs/misc/xenstore.txt talks about it a bit.
> >
> > For well defined entries it should be reasonable to have human
> > readable content in xenstore which simply enable/disables the table
> and perhaps contains some configuration values as appropriate.
> >
> > For adding arbitrary tables I'm less sure what the right answer is.
> > Common header elements in human readable form, payload as hex encoded
> > strings or something? Seems a bit icky though.
> >
> > > I am not sure what other mechanisms could be employed. In other code
> > > I use in out hvmloader, I pass an ACPI SSDT to the hvmloader at
> runtime.
> > > I use a little DMAish interface I built into qemu to push the SSDT
> > > to hvmloader while it is building the ACPI tables. Something like
> > > this could be used but I don't really want to get qemu involved in
> > > this operation.
> >
> > Yes, I think we should avoid that too.
> >
> > > I guess a third option might be to have a facility to load extra
> > > modules/files into the new domain at start time and specify their
> > > gpa's in xenstore. They could then be discarded after the initial
> > > domain setup is complete.
> >
> > That might work. What do others around here think?
> >
> > Ian.
> 
> In deciding which approach to use, you should keep in mind that
> eventually it will be desirable to measure the VM (i.e. into a virtual
> TPM).  So if the data is going to be processed by code that is TPM-
> aware, then any approach to getting it the data should allow for
> measurement.  But if the processing code is not TPM-aware and is
> measured by the domain builder code, then the data should be provided in
> a way that the domain builder can easily measure it.
> 
> Joe

Joe, thanks for the feedback. From the other comments I have received, I believe I will use an approach where bits of virtual firmware like passed in SMBIOS tables (or other pieces I am working on like ACPI SSDTs that are passed in at runtime) will be loaded into the new guest as a set of modules. These modules will solely be for consumption by hvmloader. In light of this, I believe the latter of the two scenarios you mentioned will be the case; that a domain builder measures the initial building blocks like hvmloader any associated modules.

The area I am still considering though is dealing with platform firmware updates and how they would be reflected in a given set of hvmloader modules where obviously changing those modules would mean a different measurement. More broadly, I guess I don't know enough about how changes to platform firmware is handled with respect of platform measurements (and it seems to me the case of the guest and vTPMs is just an extension of this)?

Ross

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:13:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bIJ-0008Ii-UA; Thu, 23 Feb 2012 16:13:23 +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 1S0bII-0008Ia-Dj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:13:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330013577!64781828!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3594 invoked from network); 23 Feb 2012 16:12:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 16:12:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0bIG-0007vo-9b; Thu, 23 Feb 2012 16:13:20 +0000
Date: Thu, 23 Feb 2012 16:13:20 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223161320.GJ25694@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
	<8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
	<20120223153031.GG25694@ocelot.phlegethon.org>
	<5634f0a8b91c7bb18c9e85fd76fcaaf1.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5634f0a8b91c7bb18c9e85fd76fcaaf1.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:55 -0800 on 23 Feb (1329983736), Andres Lagar-Cavilla wrote:
> > I have hit another stumbling block though - get_two_gfns() can't be
> > safely ask get_gfn to populate or unshare if that might involve a waitq,
> > since by definition one of its two calls is made with a lock held.  I
> > can't see a nice way of having it retry (not one that's guaranteed to
> > make progress) without pulling the fixup-and-retry up into that
> > function.  I might do that in the next revision.
> 
> One way to do this is use query_unlocked on the second. If we sense
> danger, drop the lock on the first, then do the right thing for the
> second, then drop the lock for the second, then retry at the top.

Sadly, this isn't guaranteed to make progress in the face of an
aggressive pager or sharer.  It might be OK with yet another waitq
invocation, though...

> hvm_task_switch also gets two gfns, although in a manner that prevents
> easily using get_two_gfns (hvm_map_entry on gdt offsets). It's unlikely
> this will ever be a problem (it's somewhat reasonable to expect both gdt
> entries to fall in the same gfn) but it's something worth keeping in mind.

Thanks, I'll add it to the list.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:13:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bIJ-0008Ii-UA; Thu, 23 Feb 2012 16:13:23 +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 1S0bII-0008Ia-Dj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:13:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330013577!64781828!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3594 invoked from network); 23 Feb 2012 16:12:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 16:12:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0bIG-0007vo-9b; Thu, 23 Feb 2012 16:13:20 +0000
Date: Thu, 23 Feb 2012 16:13:20 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120223161320.GJ25694@ocelot.phlegethon.org>
References: <20120216152040.GC41163@ocelot.phlegethon.org>
	<6925397F-ABDD-4C23-9C4C-AA6761E32542@gridcentric.ca>
	<0fee4ca1da141be27e1269a75f20ca2a.squirrel@webmail.lagarcavilla.org>
	<20120217175619.GB59026@ocelot.phlegethon.org>
	<8023c23180d43354d6f7a2510dc61502.squirrel@webmail.lagarcavilla.org>
	<20120223153031.GG25694@ocelot.phlegethon.org>
	<5634f0a8b91c7bb18c9e85fd76fcaaf1.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5634f0a8b91c7bb18c9e85fd76fcaaf1.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [RFC] [PATCH] x86/mm: use wait queues for mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 07:55 -0800 on 23 Feb (1329983736), Andres Lagar-Cavilla wrote:
> > I have hit another stumbling block though - get_two_gfns() can't be
> > safely ask get_gfn to populate or unshare if that might involve a waitq,
> > since by definition one of its two calls is made with a lock held.  I
> > can't see a nice way of having it retry (not one that's guaranteed to
> > make progress) without pulling the fixup-and-retry up into that
> > function.  I might do that in the next revision.
> 
> One way to do this is use query_unlocked on the second. If we sense
> danger, drop the lock on the first, then do the right thing for the
> second, then drop the lock for the second, then retry at the top.

Sadly, this isn't guaranteed to make progress in the face of an
aggressive pager or sharer.  It might be OK with yet another waitq
invocation, though...

> hvm_task_switch also gets two gfns, although in a manner that prevents
> easily using get_two_gfns (hvm_map_entry on gdt offsets). It's unlikely
> this will ever be a problem (it's somewhat reasonable to expect both gdt
> entries to fall in the same gfn) but it's something worth keeping in mind.

Thanks, I'll add it to the list.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:16:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bLM-0008S5-HU; Thu, 23 Feb 2012 16:16:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0bLK-0008Rw-Rx
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 16:16:31 +0000
Received: from [85.158.139.83:48669] by server-4.bemta-5.messagelabs.com id
	30/EC-10788-E56664F4; Thu, 23 Feb 2012 16:16:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330013789!16322196!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15296 invoked from network); 23 Feb 2012 16:16:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 16:16:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330013789; l=610;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vPT2h+UUtAcxg6NTUyeH0uK7k3E=;
	b=GujoJeMmfZQy7vca/sO8jjOg/QpLPVo8nGOon1XUBmAmmA7Gg1dCIaiQNxmtI0LZ+Zx
	e95+gHSh04MNGQEsfsIwtA9XB/Y1F3XST1g7wbEbZjUUSe/T3eRZsZGD/SXAmECBj5mno
	5/wJhyoTw5NcqArpXz21N65H5XVdJk0RUa4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo35) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a01adeo1NFDx0h ;
	Thu, 23 Feb 2012 17:16:13 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 68F3B18638; Thu, 23 Feb 2012 17:16:11 +0100 (CET)
Date: Thu, 23 Feb 2012 17:16:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20120223161611.GA10528@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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 Tue, Feb 21, Roger Pau Monne wrote:

> +AS_IF([test "x$pythontools" = "xy"], [
> +    AS_IF([echo "$PYTHON" | grep -q "^/"], [
> +        PYTHONPATH=$PYTHON
> +        PYTHON=`basename $PYTHONPATH`
> +    ],[test -z "$PYTHON"], [PYTHON="python"],
> +    [AC_MSG_ERROR([PYTHON specified, but is not an absolute path])])
> +    AX_PATH_PROG_OR_FAIL([PYTHONPATH], [$PYTHON])
> +    AX_CHECK_PYTHON_VERSION([2], [3])
> +    AX_CHECK_PYTHON_XML()
> +    AX_CHECK_PYTHON_DEVEL()
> +])

Is the AX_CHECK_PYTHON_XML check really required for compilation? It
seems to check for xml.dom.minidom which is used in xend at runtime.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:16:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bLM-0008S5-HU; Thu, 23 Feb 2012 16:16:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0bLK-0008Rw-Rx
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 16:16:31 +0000
Received: from [85.158.139.83:48669] by server-4.bemta-5.messagelabs.com id
	30/EC-10788-E56664F4; Thu, 23 Feb 2012 16:16:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330013789!16322196!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15296 invoked from network); 23 Feb 2012 16:16:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 16:16:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330013789; l=610;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=vPT2h+UUtAcxg6NTUyeH0uK7k3E=;
	b=GujoJeMmfZQy7vca/sO8jjOg/QpLPVo8nGOon1XUBmAmmA7Gg1dCIaiQNxmtI0LZ+Zx
	e95+gHSh04MNGQEsfsIwtA9XB/Y1F3XST1g7wbEbZjUUSe/T3eRZsZGD/SXAmECBj5mno
	5/wJhyoTw5NcqArpXz21N65H5XVdJk0RUa4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo35) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a01adeo1NFDx0h ;
	Thu, 23 Feb 2012 17:16:13 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 68F3B18638; Thu, 23 Feb 2012 17:16:11 +0100 (CET)
Date: Thu, 23 Feb 2012 17:16:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20120223161611.GA10528@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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 Tue, Feb 21, Roger Pau Monne wrote:

> +AS_IF([test "x$pythontools" = "xy"], [
> +    AS_IF([echo "$PYTHON" | grep -q "^/"], [
> +        PYTHONPATH=$PYTHON
> +        PYTHON=`basename $PYTHONPATH`
> +    ],[test -z "$PYTHON"], [PYTHON="python"],
> +    [AC_MSG_ERROR([PYTHON specified, but is not an absolute path])])
> +    AX_PATH_PROG_OR_FAIL([PYTHONPATH], [$PYTHON])
> +    AX_CHECK_PYTHON_VERSION([2], [3])
> +    AX_CHECK_PYTHON_XML()
> +    AX_CHECK_PYTHON_DEVEL()
> +])

Is the AX_CHECK_PYTHON_XML check really required for compilation? It
seems to check for xml.dom.minidom which is used in xend at runtime.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:21:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bPt-0000EL-7Q; Thu, 23 Feb 2012 16:21:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jljusten@gmail.com>) id 1S0bPr-0000Dt-2a
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:21:11 +0000
X-Env-Sender: jljusten@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330014063!3811168!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24124 invoked from network); 23 Feb 2012 16:21:04 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:21:04 -0000
Received: by yenm7 with SMTP id m7so9533875yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 08:21:03 -0800 (PST)
Received-SPF: pass (google.com: domain of jljusten@gmail.com designates
	10.101.136.35 as permitted sender) client-ip=10.101.136.35; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jljusten@gmail.com
	designates 10.101.136.35 as permitted sender)
	smtp.mail=jljusten@gmail.com;
	dkim=pass header.i=jljusten@gmail.com
Received: from mr.google.com ([10.101.136.35])
	by 10.101.136.35 with SMTP id o35mr1167385ann.67.1330014063306
	(num_hops = 1); Thu, 23 Feb 2012 08:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Vh288eDN4XtEb6e7jLGOmpe2VaR349y4KYuAW71tF30=;
	b=pytgxqB8S3GLHMgA9GGMv8rTe5INzQvt2VS8SS2o74xiTJ580k7P1xqglmczwXF50H
	L5zab/MtXtDCjrno1iNV15hnDx+ydvKp8XFNwKiHrmSegNIqUJTwPeURiJIY44A9Lwpr
	4qp1DQHKpUl57gMe6w9dFd3XATHRfG9Vlh7XQ=
MIME-Version: 1.0
Received: by 10.101.136.35 with SMTP id o35mr939399ann.67.1330014063224; Thu,
	23 Feb 2012 08:21:03 -0800 (PST)
Received: by 10.147.38.20 with HTTP; Thu, 23 Feb 2012 08:21:03 -0800 (PST)
In-Reply-To: <1329991630.8557.52.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
Date: Thu, 23 Feb 2012 08:21:03 -0800
Message-ID: <CAFe8ug-7RARVDFvch00Zh3Zu-SaNFgg2eiwcjB2Ma9+GmwwSxQ@mail.gmail.com>
From: Jordan Justen <jljusten@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 02:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> A way to integrate OVMF build directly into XEN has still be discussed
>> on the mailing list appropriately.
>
> AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> external dependency would be for us to mirror it on xenbits as a
> convenience to our users, who don't need to get stuff from multiple
> places, and as a courtesy to our upstreams, so our users don't consume
> their resources.
>
> I don't much fancy setting the necessary webdav or whatever stuff on
> xenbits and integrating SVN support into our build system though. What
> do people think about using git-svn to manage our mirror in git instead?
> Or better: perhaps OVMF have an official git or hg mirror?

These are not 100% official, but I have been mirroring to git for over
a year now:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control#Mirrors

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:21:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bPt-0000EL-7Q; Thu, 23 Feb 2012 16:21:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jljusten@gmail.com>) id 1S0bPr-0000Dt-2a
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:21:11 +0000
X-Env-Sender: jljusten@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330014063!3811168!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24124 invoked from network); 23 Feb 2012 16:21:04 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:21:04 -0000
Received: by yenm7 with SMTP id m7so9533875yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 08:21:03 -0800 (PST)
Received-SPF: pass (google.com: domain of jljusten@gmail.com designates
	10.101.136.35 as permitted sender) client-ip=10.101.136.35; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jljusten@gmail.com
	designates 10.101.136.35 as permitted sender)
	smtp.mail=jljusten@gmail.com;
	dkim=pass header.i=jljusten@gmail.com
Received: from mr.google.com ([10.101.136.35])
	by 10.101.136.35 with SMTP id o35mr1167385ann.67.1330014063306
	(num_hops = 1); Thu, 23 Feb 2012 08:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Vh288eDN4XtEb6e7jLGOmpe2VaR349y4KYuAW71tF30=;
	b=pytgxqB8S3GLHMgA9GGMv8rTe5INzQvt2VS8SS2o74xiTJ580k7P1xqglmczwXF50H
	L5zab/MtXtDCjrno1iNV15hnDx+ydvKp8XFNwKiHrmSegNIqUJTwPeURiJIY44A9Lwpr
	4qp1DQHKpUl57gMe6w9dFd3XATHRfG9Vlh7XQ=
MIME-Version: 1.0
Received: by 10.101.136.35 with SMTP id o35mr939399ann.67.1330014063224; Thu,
	23 Feb 2012 08:21:03 -0800 (PST)
Received: by 10.147.38.20 with HTTP; Thu, 23 Feb 2012 08:21:03 -0800 (PST)
In-Reply-To: <1329991630.8557.52.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
Date: Thu, 23 Feb 2012 08:21:03 -0800
Message-ID: <CAFe8ug-7RARVDFvch00Zh3Zu-SaNFgg2eiwcjB2Ma9+GmwwSxQ@mail.gmail.com>
From: Jordan Justen <jljusten@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 02:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> A way to integrate OVMF build directly into XEN has still be discussed
>> on the mailing list appropriately.
>
> AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> external dependency would be for us to mirror it on xenbits as a
> convenience to our users, who don't need to get stuff from multiple
> places, and as a courtesy to our upstreams, so our users don't consume
> their resources.
>
> I don't much fancy setting the necessary webdav or whatever stuff on
> xenbits and integrating SVN support into our build system though. What
> do people think about using git-svn to manage our mirror in git instead?
> Or better: perhaps OVMF have an official git or hg mirror?

These are not 100% official, but I have been mirroring to git for over
a year now:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control#Mirrors

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:23:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bRV-0000L1-QS; Thu, 23 Feb 2012 16:22:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0bRU-0000Kq-EU
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:22:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330014165!14584322!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTYwOTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2238 invoked from network); 23 Feb 2012 16:22:46 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-3.tower-174.messagelabs.com with SMTP;
	23 Feb 2012 16:22:46 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 28CF3458084;
	Thu, 23 Feb 2012 08:22:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=KujJK8rysTU8heyHu9dGJlMlxnHWs4RKqK8HkYS8LuXn
	m7/7EkRHVp68D2HV9j/31yzx8gkKc6F8oVUEBf66bQ26tPHiAlHPOQhlHpadSqBX
	ClMVHUXKMzsI7Wa25VJGw6WWJ0rnLVYbvzoT9Fgo2k+RQX0H9iX/2IdJlohFNjY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=O/Q3PefkwxAjxKgcnqdVKFfwneA=; b=EER/1Gpo
	92hX1LHrLM81xqPIf4vyLE14bfo+5r+dDAY+gH2k72Rcx5FIh4+ZLyAtMkDN12iN
	uLDl0XB/MHOMqkN+AUprsH0/Pt3gsKXrO/9gSqO+/Cnq4layTUqxcwnpNVQecpoD
	RHmucrL8GgbURiCO+XNrOvOOzB4XTTnoglo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 88DCA458081; 
	Thu, 23 Feb 2012 08:22:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 23 Feb 2012 08:22:45 -0800
Message-ID: <4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1329999531.19361.74.camel@elijah>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
Date: Thu, 23 Feb 2012 08:22:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <george.dunlap@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
>> What if you switch back without making sure you are in such a state? I
>> think switching between the two is where the potential for unexpected
>> behaviour is most likely.
>
> Yeah, correctly predicting what would happen requires understanding what
> mem-set does under the hood.
>
>> I like that you have to explicitly ask for the safety wheels to come off
>> and explicitly put them back on again. It avoids the corner cases I
>> alluded to above (at least I hope so).
>
> Yes, I think your suggestion sounds more like driving a car with a
> proper hood, and less like driving a go-kart with the engine
> exposed. :-)
>
>> Without wishing to put words in Andres' mouth I expect that he intended
>> "footprint" to cover other technical means than paging too --
>> specifically I expect he was thinking of page sharing. (I suppose it
>> also covers PoD to some extent too, although that is something of a
>> special case)
>>
>> While I don't expect there will be a knob to control number of shared
>> pages (either you can share some pages or not, the settings would be
>> more about how aggressively you search for sharable pages) it might be
>> useful to consider the interaction between paging and sharing, I expect
>> that most sharing configurations would want to have paging on at the
>> same time (for safety). It seems valid to me to want to say "make the
>> guest use this amount of actual RAM" and to achieve that by sharing what
>> you can and then paging the rest.
>
> Yes, it's worth thinking about; as long as it doesn't stall the paging
> UI too long. :-)
>
> The thing is, you can't actually control how much sharing happens.  That
> depends largely on whether the guests create and maintain pages which
> are share-able, and whether the sharing detection algorithm can find
> such pages.  Even if two guests are sharing 95% of their pages, at any
> point one of the guests may simply go wild and change them all.  So it
> seems to me that shared pages need to be treated like sunny days in the
> UK: Enjoy them while they're there, but don't count on them. :-)
>
> Given that, I think that each VM should have a "guaranteed minimum
> memory footprint", which would be the amount of actual host ram it will
> have if suddenly no shared pages become available.  After that, there
> should be a policy of how to use the "windfall" or "bonus" pages
> generated by sharing.
>
> One sensible default policy would be "givers gain": Every guest which
> creates a page which happens to be shared by another VM gets a share of
> the pages freed up by the sharing.  Another policy might be "communism",
> where the freed up pages are shared among all VMs, regardless of whose
> pages made the benefit possible.  (In fact, if shared pages come from
> zero pages, they should probably be given to VMs with no zero pages,
> regardless of the policy.)
>
> However, I'd say the main public "knobs" should be just consist of two
> things:
> * xl mem-set memory-target.  This is the minimum amount of physical RAM
> a guest can get; we make sure that the sum of these for all VMs does not
> exceed the host capacity.
> * xl sharing-policy [policy].  This tells the sharing system how to use
> the "windfall" pages gathered from page sharing.
>
> Then internally, the sharing system should combine the "minimum
> footprint" with the number of extra pages and the policy to set the
> amount of memory actually used (via balloon driver or paging).
>
> You could imagine a manual mode, where the administrator shares out the
> extra pages manually to VMs that he thinks needs them; but because those
> extra pages may go away at any time, that needs to be a separate knob
> (and preferably one which most admins don't ever touch).
>
> Andres, what do you think?

I think it's a lot to process :) I will issue a few statements in no
particular order.

How about we have a BoF/powwow on this at the Hackathon?

For the sake of expediency we need a simple UI, with two/three obvious
commands doing things, and then a full arsenal of knob-ery as a separate
entity. I agree with the general sentiment here.

I actually intended footprint to convey a human-understandable name for
what paging is doing. I think if we try to combine under 'footprint' all
possible means of trimming pages from the guest, *in libxl*, we'll end up
pleasing nobody.

Taking a few steps back, Olaf's purpose is to be able to control the *one*
knob xenpaging has with its linear sweep policy via libxl. (I guess you
have a second knob, throttling how fast you try to page in things back)

Somebody has to ask this: are you really sure you want to bake policies
into libxl? What will toolstacks be left with? I think it's great to wire
some straightforward control of xenpaging into libxl -- as straightforward
control of the balloon and PoD is already in place. But when the
conversation starts escalating, the complexity of libxl grows
exponentially, and I get all kinds of shivers.

The original stated goal of libxl is to be a common substrate for
toolstacks. Let toolstacks decide if they want fancier paging or Marxist
sharing, or what not :)

My two cents
Andres

>
>  -George
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:23:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bRV-0000L1-QS; Thu, 23 Feb 2012 16:22:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0bRU-0000Kq-EU
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:22:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330014165!14584322!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTYwOTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2238 invoked from network); 23 Feb 2012 16:22:46 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-3.tower-174.messagelabs.com with SMTP;
	23 Feb 2012 16:22:46 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 28CF3458084;
	Thu, 23 Feb 2012 08:22:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=KujJK8rysTU8heyHu9dGJlMlxnHWs4RKqK8HkYS8LuXn
	m7/7EkRHVp68D2HV9j/31yzx8gkKc6F8oVUEBf66bQ26tPHiAlHPOQhlHpadSqBX
	ClMVHUXKMzsI7Wa25VJGw6WWJ0rnLVYbvzoT9Fgo2k+RQX0H9iX/2IdJlohFNjY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=O/Q3PefkwxAjxKgcnqdVKFfwneA=; b=EER/1Gpo
	92hX1LHrLM81xqPIf4vyLE14bfo+5r+dDAY+gH2k72Rcx5FIh4+ZLyAtMkDN12iN
	uLDl0XB/MHOMqkN+AUprsH0/Pt3gsKXrO/9gSqO+/Cnq4layTUqxcwnpNVQecpoD
	RHmucrL8GgbURiCO+XNrOvOOzB4XTTnoglo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 88DCA458081; 
	Thu, 23 Feb 2012 08:22:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 23 Feb 2012 08:22:45 -0800
Message-ID: <4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1329999531.19361.74.camel@elijah>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
Date: Thu, 23 Feb 2012 08:22:45 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <george.dunlap@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
>> What if you switch back without making sure you are in such a state? I
>> think switching between the two is where the potential for unexpected
>> behaviour is most likely.
>
> Yeah, correctly predicting what would happen requires understanding what
> mem-set does under the hood.
>
>> I like that you have to explicitly ask for the safety wheels to come off
>> and explicitly put them back on again. It avoids the corner cases I
>> alluded to above (at least I hope so).
>
> Yes, I think your suggestion sounds more like driving a car with a
> proper hood, and less like driving a go-kart with the engine
> exposed. :-)
>
>> Without wishing to put words in Andres' mouth I expect that he intended
>> "footprint" to cover other technical means than paging too --
>> specifically I expect he was thinking of page sharing. (I suppose it
>> also covers PoD to some extent too, although that is something of a
>> special case)
>>
>> While I don't expect there will be a knob to control number of shared
>> pages (either you can share some pages or not, the settings would be
>> more about how aggressively you search for sharable pages) it might be
>> useful to consider the interaction between paging and sharing, I expect
>> that most sharing configurations would want to have paging on at the
>> same time (for safety). It seems valid to me to want to say "make the
>> guest use this amount of actual RAM" and to achieve that by sharing what
>> you can and then paging the rest.
>
> Yes, it's worth thinking about; as long as it doesn't stall the paging
> UI too long. :-)
>
> The thing is, you can't actually control how much sharing happens.  That
> depends largely on whether the guests create and maintain pages which
> are share-able, and whether the sharing detection algorithm can find
> such pages.  Even if two guests are sharing 95% of their pages, at any
> point one of the guests may simply go wild and change them all.  So it
> seems to me that shared pages need to be treated like sunny days in the
> UK: Enjoy them while they're there, but don't count on them. :-)
>
> Given that, I think that each VM should have a "guaranteed minimum
> memory footprint", which would be the amount of actual host ram it will
> have if suddenly no shared pages become available.  After that, there
> should be a policy of how to use the "windfall" or "bonus" pages
> generated by sharing.
>
> One sensible default policy would be "givers gain": Every guest which
> creates a page which happens to be shared by another VM gets a share of
> the pages freed up by the sharing.  Another policy might be "communism",
> where the freed up pages are shared among all VMs, regardless of whose
> pages made the benefit possible.  (In fact, if shared pages come from
> zero pages, they should probably be given to VMs with no zero pages,
> regardless of the policy.)
>
> However, I'd say the main public "knobs" should be just consist of two
> things:
> * xl mem-set memory-target.  This is the minimum amount of physical RAM
> a guest can get; we make sure that the sum of these for all VMs does not
> exceed the host capacity.
> * xl sharing-policy [policy].  This tells the sharing system how to use
> the "windfall" pages gathered from page sharing.
>
> Then internally, the sharing system should combine the "minimum
> footprint" with the number of extra pages and the policy to set the
> amount of memory actually used (via balloon driver or paging).
>
> You could imagine a manual mode, where the administrator shares out the
> extra pages manually to VMs that he thinks needs them; but because those
> extra pages may go away at any time, that needs to be a separate knob
> (and preferably one which most admins don't ever touch).
>
> Andres, what do you think?

I think it's a lot to process :) I will issue a few statements in no
particular order.

How about we have a BoF/powwow on this at the Hackathon?

For the sake of expediency we need a simple UI, with two/three obvious
commands doing things, and then a full arsenal of knob-ery as a separate
entity. I agree with the general sentiment here.

I actually intended footprint to convey a human-understandable name for
what paging is doing. I think if we try to combine under 'footprint' all
possible means of trimming pages from the guest, *in libxl*, we'll end up
pleasing nobody.

Taking a few steps back, Olaf's purpose is to be able to control the *one*
knob xenpaging has with its linear sweep policy via libxl. (I guess you
have a second knob, throttling how fast you try to page in things back)

Somebody has to ask this: are you really sure you want to bake policies
into libxl? What will toolstacks be left with? I think it's great to wire
some straightforward control of xenpaging into libxl -- as straightforward
control of the balloon and PoD is already in place. But when the
conversation starts escalating, the complexity of libxl grows
exponentially, and I get all kinds of shivers.

The original stated goal of libxl is to be a common substrate for
toolstacks. Let toolstacks decide if they want fancier paging or Marxist
sharing, or what not :)

My two cents
Andres

>
>  -George
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:29:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bY9-0000ZA-NN; Thu, 23 Feb 2012 16:29:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.chander@gmail.com>) id 1S0bY8-0000Z4-3y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:29:44 +0000
X-Env-Sender: vijay.chander@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1330014576!15589114!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19725 invoked from network); 23 Feb 2012 16:29:37 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:29:37 -0000
Received: by iaeh11 with SMTP id h11so6576210iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 08:29:36 -0800 (PST)
Received-SPF: pass (google.com: domain of vijay.chander@gmail.com designates
	10.42.169.198 as permitted sender) client-ip=10.42.169.198; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	vijay.chander@gmail.com designates 10.42.169.198 as permitted
	sender) smtp.mail=vijay.chander@gmail.com;
	dkim=pass header.i=vijay.chander@gmail.com
Received: from mr.google.com ([10.42.169.198])
	by 10.42.169.198 with SMTP id c6mr2457910icz.31.1330014576338 (num_hops
	= 1); Thu, 23 Feb 2012 08:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=xNt6ZW1n7oKx5e9xHMqlDeRwnaMEV2FQ8NXqkypYC7M=;
	b=x9OuLYxOf0XmALi4q3sCwZL2cFZWcl09RA2WK1W3rKmEgKz2nFO0XmWtoYGiTB1iYr
	Xp7mfiB7y6UkuD4RHkfMcmfYcybgR41qzCI48UXlQVvD79ojgH1cRz8cgPGBb0vZNILP
	cSsnY7q1MTMz3LUBD8kuuOa0NL0OoAcKupx7w=
MIME-Version: 1.0
Received: by 10.42.169.198 with SMTP id c6mr2062059icz.31.1330014576197; Thu,
	23 Feb 2012 08:29:36 -0800 (PST)
Received: by 10.231.167.132 with HTTP; Thu, 23 Feb 2012 08:29:36 -0800 (PST)
In-Reply-To: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
Date: Thu, 23 Feb 2012 08:29:36 -0800
Message-ID: <CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
From: Vijay Chander <vijay.chander@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Pls help: netfront tx ring frozen (any clues
	appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3765578350091501053=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3765578350091501053==
Content-Type: multipart/alternative; boundary=90e6ba6e84065c407d04b9a42664

--90e6ba6e84065c407d04b9a42664
Content-Type: text/plain; charset=ISO-8859-1

Hi,

    We are running into a situation where rsp_prod index in the shared ring
is not getting updated
for the netfront tx ring by the netback.

    We see that rsp_cons is the same value as rsp_prod, with req_prod 236
slots away(tx ring is full).
>From looking at the netfront driver code, it looks as if xennet_tx_buf_gc
processing only happens if rsp_prod is more
than rsp_cons.

   Our understanding is that netfront sets rsp_cons to tell the netback to
start processing transmits
from rsp_cons index onwards till req_prod. Once netback is done process X
requests, it will increment rsp_prod
by X. This will cause netfront to look at the status of each of individual
responses for the slots starting
from rsp_cons till rsp_prod (with rsp_prod  - rsp_cons = X in this case).

   Is there anyway to workaround this ? Will xennet_disconnect_backend(),
xennet_connect()
on the netfront cause us to recover from this stuck situation. We are ok
with pending TX packets getting dropped
since we have TCP running on top.

   Thanks,
-vijay

--90e6ba6e84065c407d04b9a42664
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><br><br>Hi, =A0<div>=A0<br><div>=A0 =A0 We are r=
unning into a situation where rsp_prod index in the shared ring is not gett=
ing updated</div></div><div>for the netfront tx ring by the netback.</div><=
div><br>
</div><div>=A0 =A0 We see that rsp_cons is the same value as rsp_prod, with=
 req_prod 236 slots away(tx ring is full).=A0</div>
<div>From looking=A0at the netfront driver code, it looks as if xennet_tx_b=
uf_gc processing only happens if rsp_prod is more=A0</div><div>than rsp_con=
s.</div><div><br></div><div>=A0 =A0Our understanding is that netfront sets =
rsp_cons to tell the netback to start processing transmits</div>

<div>from rsp_cons index onwards till req_prod. Once netback is done proces=
s X requests, it will increment rsp_prod</div><div>by X. This will cause ne=
tfront to look at the status of each of individual responses for the slots =
starting</div>

<div>from rsp_cons till rsp_prod (with rsp_prod =A0- rsp_cons =3D X in this=
 case).</div><div><br></div><div>=A0 =A0Is there anyway to workaround this =
? Will xennet_disconnect_backend(), xennet_connect()</div><div>on the netfr=
ont cause us to recover from this stuck situation. We are ok with pending T=
X packets getting dropped</div>

<div>since we have TCP running on top.</div><div><br></div><div>=A0 =A0Than=
ks,</div><div>-vijay</div>
</div><br>

--90e6ba6e84065c407d04b9a42664--


--===============3765578350091501053==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3765578350091501053==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:29:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bY9-0000ZA-NN; Thu, 23 Feb 2012 16:29:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.chander@gmail.com>) id 1S0bY8-0000Z4-3y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:29:44 +0000
X-Env-Sender: vijay.chander@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1330014576!15589114!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19725 invoked from network); 23 Feb 2012 16:29:37 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:29:37 -0000
Received: by iaeh11 with SMTP id h11so6576210iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 08:29:36 -0800 (PST)
Received-SPF: pass (google.com: domain of vijay.chander@gmail.com designates
	10.42.169.198 as permitted sender) client-ip=10.42.169.198; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	vijay.chander@gmail.com designates 10.42.169.198 as permitted
	sender) smtp.mail=vijay.chander@gmail.com;
	dkim=pass header.i=vijay.chander@gmail.com
Received: from mr.google.com ([10.42.169.198])
	by 10.42.169.198 with SMTP id c6mr2457910icz.31.1330014576338 (num_hops
	= 1); Thu, 23 Feb 2012 08:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=xNt6ZW1n7oKx5e9xHMqlDeRwnaMEV2FQ8NXqkypYC7M=;
	b=x9OuLYxOf0XmALi4q3sCwZL2cFZWcl09RA2WK1W3rKmEgKz2nFO0XmWtoYGiTB1iYr
	Xp7mfiB7y6UkuD4RHkfMcmfYcybgR41qzCI48UXlQVvD79ojgH1cRz8cgPGBb0vZNILP
	cSsnY7q1MTMz3LUBD8kuuOa0NL0OoAcKupx7w=
MIME-Version: 1.0
Received: by 10.42.169.198 with SMTP id c6mr2062059icz.31.1330014576197; Thu,
	23 Feb 2012 08:29:36 -0800 (PST)
Received: by 10.231.167.132 with HTTP; Thu, 23 Feb 2012 08:29:36 -0800 (PST)
In-Reply-To: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
Date: Thu, 23 Feb 2012 08:29:36 -0800
Message-ID: <CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
From: Vijay Chander <vijay.chander@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Pls help: netfront tx ring frozen (any clues
	appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3765578350091501053=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3765578350091501053==
Content-Type: multipart/alternative; boundary=90e6ba6e84065c407d04b9a42664

--90e6ba6e84065c407d04b9a42664
Content-Type: text/plain; charset=ISO-8859-1

Hi,

    We are running into a situation where rsp_prod index in the shared ring
is not getting updated
for the netfront tx ring by the netback.

    We see that rsp_cons is the same value as rsp_prod, with req_prod 236
slots away(tx ring is full).
>From looking at the netfront driver code, it looks as if xennet_tx_buf_gc
processing only happens if rsp_prod is more
than rsp_cons.

   Our understanding is that netfront sets rsp_cons to tell the netback to
start processing transmits
from rsp_cons index onwards till req_prod. Once netback is done process X
requests, it will increment rsp_prod
by X. This will cause netfront to look at the status of each of individual
responses for the slots starting
from rsp_cons till rsp_prod (with rsp_prod  - rsp_cons = X in this case).

   Is there anyway to workaround this ? Will xennet_disconnect_backend(),
xennet_connect()
on the netfront cause us to recover from this stuck situation. We are ok
with pending TX packets getting dropped
since we have TCP running on top.

   Thanks,
-vijay

--90e6ba6e84065c407d04b9a42664
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><br><br>Hi, =A0<div>=A0<br><div>=A0 =A0 We are r=
unning into a situation where rsp_prod index in the shared ring is not gett=
ing updated</div></div><div>for the netfront tx ring by the netback.</div><=
div><br>
</div><div>=A0 =A0 We see that rsp_cons is the same value as rsp_prod, with=
 req_prod 236 slots away(tx ring is full).=A0</div>
<div>From looking=A0at the netfront driver code, it looks as if xennet_tx_b=
uf_gc processing only happens if rsp_prod is more=A0</div><div>than rsp_con=
s.</div><div><br></div><div>=A0 =A0Our understanding is that netfront sets =
rsp_cons to tell the netback to start processing transmits</div>

<div>from rsp_cons index onwards till req_prod. Once netback is done proces=
s X requests, it will increment rsp_prod</div><div>by X. This will cause ne=
tfront to look at the status of each of individual responses for the slots =
starting</div>

<div>from rsp_cons till rsp_prod (with rsp_prod =A0- rsp_cons =3D X in this=
 case).</div><div><br></div><div>=A0 =A0Is there anyway to workaround this =
? Will xennet_disconnect_backend(), xennet_connect()</div><div>on the netfr=
ont cause us to recover from this stuck situation. We are ok with pending T=
X packets getting dropped</div>

<div>since we have TCP running on top.</div><div><br></div><div>=A0 =A0Than=
ks,</div><div>-vijay</div>
</div><br>

--90e6ba6e84065c407d04b9a42664--


--===============3765578350091501053==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3765578350091501053==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bd8-0000hb-GZ; Thu, 23 Feb 2012 16:34:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bd6-0000hV-Ei
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:34:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330014884!16599678!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11157 invoked from network); 23 Feb 2012 16:34:45 -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;
	23 Feb 2012 16:34:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22383697"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:43 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:43 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcw-0001jG-UJ; Thu, 23 Feb 2012 16:34:42 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcw-0001ne-KW;
	Thu, 23 Feb 2012 16:34:42 +0000
Content-Type: multipart/mixed; boundary="===============1441564191045895476=="
MIME-Version: 1.0
X-Mercurial-Node: e165cfc82565addf9881487ee1aa829de1ee1402
Message-ID: <e165cfc82565addf9881.1330014863@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:23 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 6] mm: guest_remove_page() should not
	populate or unshare
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1441564191045895476==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-1.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID e165cfc82565addf9881487ee1aa829de1ee1402
# Parent  0c3d19f40ab145d101de84051c3e00eef17fa1cb
mm: guest_remove_page() should not populate or unshare.

guest_remove_page() ought to use get_gfn_query() to look up the
current state of the gfn.  Otherwise it might populate or unshare
the gfn just before dropping it.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0c3d19f40ab1 -r e165cfc82565 xen/common/memory.c
--- a/xen/common/memory.c	Mon Feb 20 22:16:32 2012 +0100
+++ b/xen/common/memory.c	Thu Feb 23 16:15:29 2012 +0000
@@ -162,7 +162,7 @@ int guest_remove_page(struct domain *d, 
     unsigned long mfn;
 
 #ifdef CONFIG_X86
-    mfn = mfn_x(get_gfn(d, gmfn, &p2mt)); 
+    mfn = mfn_x(get_gfn_query(d, gmfn, &p2mt)); 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);

--===============1441564191045895476==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1441564191045895476==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bd8-0000hb-GZ; Thu, 23 Feb 2012 16:34:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bd6-0000hV-Ei
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:34:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330014884!16599678!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11157 invoked from network); 23 Feb 2012 16:34:45 -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;
	23 Feb 2012 16:34:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22383697"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:43 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:43 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcw-0001jG-UJ; Thu, 23 Feb 2012 16:34:42 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcw-0001ne-KW;
	Thu, 23 Feb 2012 16:34:42 +0000
Content-Type: multipart/mixed; boundary="===============1441564191045895476=="
MIME-Version: 1.0
X-Mercurial-Node: e165cfc82565addf9881487ee1aa829de1ee1402
Message-ID: <e165cfc82565addf9881.1330014863@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:23 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 6] mm: guest_remove_page() should not
	populate or unshare
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1441564191045895476==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-1.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID e165cfc82565addf9881487ee1aa829de1ee1402
# Parent  0c3d19f40ab145d101de84051c3e00eef17fa1cb
mm: guest_remove_page() should not populate or unshare.

guest_remove_page() ought to use get_gfn_query() to look up the
current state of the gfn.  Otherwise it might populate or unshare
the gfn just before dropping it.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0c3d19f40ab1 -r e165cfc82565 xen/common/memory.c
--- a/xen/common/memory.c	Mon Feb 20 22:16:32 2012 +0100
+++ b/xen/common/memory.c	Thu Feb 23 16:15:29 2012 +0000
@@ -162,7 +162,7 @@ int guest_remove_page(struct domain *d, 
     unsigned long mfn;
 
 #ifdef CONFIG_X86
-    mfn = mfn_x(get_gfn(d, gmfn, &p2mt)); 
+    mfn = mfn_x(get_gfn_query(d, gmfn, &p2mt)); 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
         guest_physmap_remove_page(d, gmfn, mfn, 0);

--===============1441564191045895476==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1441564191045895476==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bdT-0000k4-9v; Thu, 23 Feb 2012 16:35:15 +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 1S0bdR-0000jB-Pm
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330014858!51321806!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3023 invoked from network); 23 Feb 2012 16:34:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150116"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:44 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcy-0001jY-GC; Thu, 23 Feb 2012 16:34:44 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcy-0001ny-5a;
	Thu, 23 Feb 2012 16:34:44 +0000
Content-Type: multipart/mixed; boundary="===============3060608097501369073=="
MIME-Version: 1.0
X-Mercurial-Node: 516f96172e67ff463c371357e0ab93724c8b9048
Message-ID: <516f96172e67ff463c37.1330014868@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:28 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 6] x86/mm: Don't claim a slot on the paging
 ring if we might not need it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3060608097501369073==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-6.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013929 0
# Node ID 516f96172e67ff463c371357e0ab93724c8b9048
# Parent  510d80343793227bd39b9a5d4d3b61b9a3f776e4
x86/mm: Don't claim a slot on the paging ring if we might not need it.

This avoids the possibility of hitting a wait queue for a slot and then
finding out later that it wasn't necessary.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 510d80343793 -r 516f96172e67 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:09 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:49 2012 +0000
@@ -1001,19 +1001,23 @@ void p2m_mem_paging_populate(struct doma
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int send_request = 0;
+    int rc, send_request = 0;
 
-    /* We're paging. There should be a ring */
-    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
-    if ( rc == -ENOSYS )
+    if ( !d->mem_event->paging.ring_page )
     {
         gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
                              "in place\n", d->domain_id, gfn);
         domain_crash(d);
         return;
     }
-    else if ( rc < 0 )
-        return;
+
+    /* Foreign users must grab a ring entry before doing any work since
+     * they might not be able to get one later.  Local users shouldn't
+     * grab a slot until they know they need it, to avoid going on a
+     * wait-queue unnecessarily. */
+    if ( d != current->domain )
+        if ( mem_event_claim_slot(d, &d->mem_event->paging) < 0 )
+            return;
 
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
@@ -1042,10 +1046,18 @@ void p2m_mem_paging_populate(struct doma
     if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_cancel_slot(d, &d->mem_event->paging);
+        if ( d != current->domain )
+            mem_event_cancel_slot(d, &d->mem_event->paging);
         return;
     }
 
+    /* Now local users should claim a slot. */
+    if ( d == current->domain ) 
+    {
+        rc = mem_event_claim_slot(d, &d->mem_event->paging);
+        ASSERT(rc == 0);
+    }
+
     /* Send request to pager */
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;

--===============3060608097501369073==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3060608097501369073==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bdT-0000k4-9v; Thu, 23 Feb 2012 16:35:15 +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 1S0bdR-0000jB-Pm
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330014858!51321806!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3023 invoked from network); 23 Feb 2012 16:34:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150116"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:44 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcy-0001jY-GC; Thu, 23 Feb 2012 16:34:44 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcy-0001ny-5a;
	Thu, 23 Feb 2012 16:34:44 +0000
Content-Type: multipart/mixed; boundary="===============3060608097501369073=="
MIME-Version: 1.0
X-Mercurial-Node: 516f96172e67ff463c371357e0ab93724c8b9048
Message-ID: <516f96172e67ff463c37.1330014868@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:28 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 6] x86/mm: Don't claim a slot on the paging
 ring if we might not need it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3060608097501369073==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-6.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013929 0
# Node ID 516f96172e67ff463c371357e0ab93724c8b9048
# Parent  510d80343793227bd39b9a5d4d3b61b9a3f776e4
x86/mm: Don't claim a slot on the paging ring if we might not need it.

This avoids the possibility of hitting a wait queue for a slot and then
finding out later that it wasn't necessary.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 510d80343793 -r 516f96172e67 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:09 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:49 2012 +0000
@@ -1001,19 +1001,23 @@ void p2m_mem_paging_populate(struct doma
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int send_request = 0;
+    int rc, send_request = 0;
 
-    /* We're paging. There should be a ring */
-    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
-    if ( rc == -ENOSYS )
+    if ( !d->mem_event->paging.ring_page )
     {
         gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
                              "in place\n", d->domain_id, gfn);
         domain_crash(d);
         return;
     }
-    else if ( rc < 0 )
-        return;
+
+    /* Foreign users must grab a ring entry before doing any work since
+     * they might not be able to get one later.  Local users shouldn't
+     * grab a slot until they know they need it, to avoid going on a
+     * wait-queue unnecessarily. */
+    if ( d != current->domain )
+        if ( mem_event_claim_slot(d, &d->mem_event->paging) < 0 )
+            return;
 
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
@@ -1042,10 +1046,18 @@ void p2m_mem_paging_populate(struct doma
     if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_cancel_slot(d, &d->mem_event->paging);
+        if ( d != current->domain )
+            mem_event_cancel_slot(d, &d->mem_event->paging);
         return;
     }
 
+    /* Now local users should claim a slot. */
+    if ( d == current->domain ) 
+    {
+        rc = mem_event_claim_slot(d, &d->mem_event->paging);
+        ASSERT(rc == 0);
+    }
+
     /* Send request to pager */
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;

--===============3060608097501369073==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3060608097501369073==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bdS-0000jg-GF; Thu, 23 Feb 2012 16:35:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdR-0000j1-4Y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:13 +0000
Received: from [85.158.139.83:53226] by server-1.bemta-5.messagelabs.com id
	E3/92-28458-0CA664F4; Thu, 23 Feb 2012 16:35:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330014907!16365449!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16497 invoked from network); 23 Feb 2012 16:35:11 -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;
	23 Feb 2012 16:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150109"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:46 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:44 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcx-0001jS-Rb; Thu, 23 Feb 2012 16:34:43 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcx-0001nq-HY;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============4342237047731095248=="
MIME-Version: 1.0
X-Mercurial-Node: 4ed10bf6325a8b07a9fb490ed575965c698a0cdd
Message-ID: <4ed10bf6325a8b07a9fb.1330014866@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:26 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 6] x86/mm: tidy up get_two_gfns() a little
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4342237047731095248==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-4.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID 4ed10bf6325a8b07a9fb490ed575965c698a0cdd
# Parent  00f61d0186a6b098b349b6f94c9a11c5a18dc99a
x86/mm: tidy up get_two_gfns() a little

Move some more repeated code into the macro, and delete the macro after
we're done.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 00f61d0186a6 -r 4ed10bf6325a xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
@@ -383,13 +383,6 @@ struct two_gfns {
     unsigned long   second_gfn;
 };
 
-#define assign_pointers(dest, source)                                        \
-do {                                                                         \
-    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
-    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
-    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
-} while(0)
-
 /* Returns mfn, type and access for potential caller consumption, but any
  * of those can be NULL */
 static inline void get_two_gfns(struct domain *rd, unsigned long rgfn,
@@ -397,28 +390,32 @@ static inline void get_two_gfns(struct d
         unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
         p2m_query_t q, struct two_gfns *rval)
 {
-    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
-    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
-    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
+    mfn_t           *first_mfn, *second_mfn, scratch_mfn;
+    p2m_access_t    *first_a, *second_a, scratch_a;
+    p2m_type_t      *first_t, *second_t, scratch_t;
 
     /* Sort by domain, if same domain by gfn */
+
+#define assign_pointers(dest, source)                   \
+do {                                                    \
+    rval-> dest ## _domain = source ## d;               \
+    rval-> dest ## _gfn = source ## gfn;                \
+    dest ## _mfn = (source ## mfn) ?: &scratch_mfn;     \
+    dest ## _a   = (source ## a)   ?: &scratch_a;       \
+    dest ## _t   = (source ## t)   ?: &scratch_t;       \
+} while (0)
+
     if ( (rd->domain_id <= ld->domain_id) || ((rd == ld) && (rgfn <= lgfn)) )
     {
-        rval->first_domain  = rd;
-        rval->first_gfn     = rgfn;
-        rval->second_domain = ld;
-        rval->second_gfn    = lgfn;
         assign_pointers(first, r);
         assign_pointers(second, l);
     } else {
-        rval->first_domain  = ld;
-        rval->first_gfn     = lgfn;
-        rval->second_domain = rd;
-        rval->second_gfn    = rgfn;
         assign_pointers(first, l);
         assign_pointers(second, r);
     }
 
+#undef assign_pointers
+
     /* Now do the gets */
     *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
                                       rval->first_gfn, first_t, first_a, q, NULL);

--===============4342237047731095248==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4342237047731095248==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16: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 1S0bdS-0000jg-GF; Thu, 23 Feb 2012 16:35:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdR-0000j1-4Y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:13 +0000
Received: from [85.158.139.83:53226] by server-1.bemta-5.messagelabs.com id
	E3/92-28458-0CA664F4; Thu, 23 Feb 2012 16:35:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330014907!16365449!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16497 invoked from network); 23 Feb 2012 16:35:11 -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;
	23 Feb 2012 16:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150109"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:46 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:44 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcx-0001jS-Rb; Thu, 23 Feb 2012 16:34:43 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcx-0001nq-HY;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============4342237047731095248=="
MIME-Version: 1.0
X-Mercurial-Node: 4ed10bf6325a8b07a9fb490ed575965c698a0cdd
Message-ID: <4ed10bf6325a8b07a9fb.1330014866@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:26 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 6] x86/mm: tidy up get_two_gfns() a little
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4342237047731095248==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-4.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID 4ed10bf6325a8b07a9fb490ed575965c698a0cdd
# Parent  00f61d0186a6b098b349b6f94c9a11c5a18dc99a
x86/mm: tidy up get_two_gfns() a little

Move some more repeated code into the macro, and delete the macro after
we're done.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 00f61d0186a6 -r 4ed10bf6325a xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
@@ -383,13 +383,6 @@ struct two_gfns {
     unsigned long   second_gfn;
 };
 
-#define assign_pointers(dest, source)                                        \
-do {                                                                         \
-    dest ## _mfn = (source ## mfn) ? (source ## mfn) : &__ ## dest ## _mfn;  \
-    dest ## _a   = (source ## a)   ? (source ## a)   : &__ ## dest ## _a;    \
-    dest ## _t   = (source ## t)   ? (source ## t)   : &__ ## dest ## _t;    \
-} while(0)
-
 /* Returns mfn, type and access for potential caller consumption, but any
  * of those can be NULL */
 static inline void get_two_gfns(struct domain *rd, unsigned long rgfn,
@@ -397,28 +390,32 @@ static inline void get_two_gfns(struct d
         unsigned long lgfn, p2m_type_t *lt, p2m_access_t *la, mfn_t *lmfn,
         p2m_query_t q, struct two_gfns *rval)
 {
-    mfn_t           *first_mfn, *second_mfn, __first_mfn, __second_mfn;
-    p2m_access_t    *first_a, *second_a, __first_a, __second_a;
-    p2m_type_t      *first_t, *second_t, __first_t, __second_t;
+    mfn_t           *first_mfn, *second_mfn, scratch_mfn;
+    p2m_access_t    *first_a, *second_a, scratch_a;
+    p2m_type_t      *first_t, *second_t, scratch_t;
 
     /* Sort by domain, if same domain by gfn */
+
+#define assign_pointers(dest, source)                   \
+do {                                                    \
+    rval-> dest ## _domain = source ## d;               \
+    rval-> dest ## _gfn = source ## gfn;                \
+    dest ## _mfn = (source ## mfn) ?: &scratch_mfn;     \
+    dest ## _a   = (source ## a)   ?: &scratch_a;       \
+    dest ## _t   = (source ## t)   ?: &scratch_t;       \
+} while (0)
+
     if ( (rd->domain_id <= ld->domain_id) || ((rd == ld) && (rgfn <= lgfn)) )
     {
-        rval->first_domain  = rd;
-        rval->first_gfn     = rgfn;
-        rval->second_domain = ld;
-        rval->second_gfn    = lgfn;
         assign_pointers(first, r);
         assign_pointers(second, l);
     } else {
-        rval->first_domain  = ld;
-        rval->first_gfn     = lgfn;
-        rval->second_domain = rd;
-        rval->second_gfn    = rgfn;
         assign_pointers(first, l);
         assign_pointers(second, r);
     }
 
+#undef assign_pointers
+
     /* Now do the gets */
     *first_mfn  = get_gfn_type_access(p2m_get_hostp2m(rval->first_domain), 
                                       rval->first_gfn, first_t, first_a, q, NULL);

--===============4342237047731095248==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4342237047731095248==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdR-0000jK-TF; Thu, 23 Feb 2012 16:35:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdQ-0000it-8v
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:12 +0000
Received: from [85.158.139.83:53152] by server-7.bemta-5.messagelabs.com id
	5A/0F-16195-FBA664F4; Thu, 23 Feb 2012 16:35:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330014907!16365449!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16413 invoked from network); 23 Feb 2012 16:35:10 -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;
	23 Feb 2012 16:35:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150099"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:45 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:43 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcx-0001jJ-7a; Thu, 23 Feb 2012 16:34:43 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcw-0001ni-UW;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============7673527983294314386=="
MIME-Version: 1.0
X-Mercurial-Node: ec94098841bfae20101608f3daf7a1a01ff71c49
Message-ID: <ec94098841bfae201016.1330014864@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:24 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 6] x86/mm: remove 'p2m_guest' lookup 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7673527983294314386==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-2.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID ec94098841bfae20101608f3daf7a1a01ff71c49
# Parent  e165cfc82565addf9881487ee1aa829de1ee1402
x86/mm: remove 'p2m_guest' lookup type.

It was neither consistently used by callers nor correctly handled by the
lookup code.  Instead, treat any lookup that might allocate or unshare
memory as a 'guest' lookup for the purposes of:
 - detecting the highest pod gfn populated; and
 - crashing the guest on access to a broken page
which were the only things this was used for.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
@@ -696,7 +696,7 @@ static int hvmemul_rep_movs(
 
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 p2m_guest, &tg);
+                 p2m_alloc, &tg);
 
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1234,7 +1234,8 @@ int hvm_hap_nested_page_fault(unsigned l
     }
 
     p2m = p2m_get_hostp2m(v->domain);
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL);
+    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 
+                              access_w ? p2m_unshare : p2m_alloc, NULL);
 
     /* Check access permissions first, then handle faults */
     if ( mfn_x(mfn) != INVALID_MFN )
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1287,7 +1287,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL);
+    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
     __put_gfn(p2m, gfn);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1023,7 +1023,7 @@ p2m_pod_demand_populate(struct p2m_domai
     }
 
     /* Keep track of the highest gfn demand-populated by a guest fault */
-    if ( q == p2m_guest && gfn > p2m->pod.max_guest )
+    if ( gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
     if ( p2m->pod.count == 0 )
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
@@ -180,7 +180,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     {
         /* Return invalid_mfn to avoid caller's access */
         mfn = _mfn(INVALID_MFN);
-        if (q == p2m_guest)
+        if (q != p2m_query)
             domain_crash(p2m->domain);
     }
 #endif
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/shadow/multi.c	Thu Feb 23 16:15:29 2012 +0000
@@ -3189,7 +3189,7 @@ static int sh_page_fault(struct vcpu *v,
 
     /* What mfn is the guest trying to access? */
     gfn = guest_l1e_get_gfn(gw.l1e);
-    gmfn = get_gfn_guest(d, gfn, &p2mt);
+    gmfn = get_gfn(d, gfn, &p2mt);
 
     if ( shadow_mode_refcounts(d) && 
          ((!p2m_is_valid(p2mt) && !p2m_is_grant(p2mt)) ||
@@ -4840,7 +4840,7 @@ static mfn_t emulate_gva_to_mfn(struct v
 
     /* Translate the GFN to an MFN */
     ASSERT(!paging_locked_by_me(v->domain));
-    mfn = get_gfn_guest(v->domain, _gfn(gfn), &p2mt);
+    mfn = get_gfn(v->domain, _gfn(gfn), &p2mt);
         
     if ( p2m_is_readonly(p2mt) )
     {
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/shadow/types.h
--- a/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
@@ -194,8 +194,6 @@ static inline shadow_l4e_t shadow_l4e_fr
  /* Override get_gfn to work with gfn_t */
 #undef get_gfn_query
 #define get_gfn_query(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_query)
-#undef get_gfn_guest
-#define get_gfn_guest(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_guest)
 
 /* The shadow types needed for the various levels. */
 
diff -r e165cfc82565 -r ec94098841bf xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
@@ -114,11 +114,11 @@ typedef enum {
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
 
+/* Modifiers to the query */
 typedef enum {
     p2m_query,              /* Do not populate a PoD entries      */
     p2m_alloc,              /* Automatically populate PoD entries */
     p2m_unshare,            /* Break c-o-w sharing; implies alloc */
-    p2m_guest,              /* Guest demand-fault; implies alloc  */
 } p2m_query_t;
 
 /* We use bitmaps and maks to handle groups of types */
@@ -332,7 +332,6 @@ static inline mfn_t get_gfn_type(struct 
  * lock held. */
 #define get_gfn(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
 #define get_gfn_query(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_guest(d, g, t)   get_gfn_type((d), (g), (t), p2m_guest)
 #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
 
 /* Compatibility function exporting the old untyped interface */

--===============7673527983294314386==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7673527983294314386==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdR-0000jK-TF; Thu, 23 Feb 2012 16:35:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdQ-0000it-8v
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:12 +0000
Received: from [85.158.139.83:53152] by server-7.bemta-5.messagelabs.com id
	5A/0F-16195-FBA664F4; Thu, 23 Feb 2012 16:35:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330014907!16365449!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16413 invoked from network); 23 Feb 2012 16:35:10 -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;
	23 Feb 2012 16:35:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150099"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:45 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:43 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcx-0001jJ-7a; Thu, 23 Feb 2012 16:34:43 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcw-0001ni-UW;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============7673527983294314386=="
MIME-Version: 1.0
X-Mercurial-Node: ec94098841bfae20101608f3daf7a1a01ff71c49
Message-ID: <ec94098841bfae201016.1330014864@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:24 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 6] x86/mm: remove 'p2m_guest' lookup 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7673527983294314386==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-2.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID ec94098841bfae20101608f3daf7a1a01ff71c49
# Parent  e165cfc82565addf9881487ee1aa829de1ee1402
x86/mm: remove 'p2m_guest' lookup type.

It was neither consistently used by callers nor correctly handled by the
lookup code.  Instead, treat any lookup that might allocate or unshare
memory as a 'guest' lookup for the purposes of:
 - detecting the highest pod gfn populated; and
 - crashing the guest on access to a broken page
which were the only things this was used for.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
@@ -696,7 +696,7 @@ static int hvmemul_rep_movs(
 
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 p2m_guest, &tg);
+                 p2m_alloc, &tg);
 
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1234,7 +1234,8 @@ int hvm_hap_nested_page_fault(unsigned l
     }
 
     p2m = p2m_get_hostp2m(v->domain);
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL);
+    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 
+                              access_w ? p2m_unshare : p2m_alloc, NULL);
 
     /* Check access permissions first, then handle faults */
     if ( mfn_x(mfn) != INVALID_MFN )
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1287,7 +1287,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL);
+    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
     __put_gfn(p2m, gfn);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1023,7 +1023,7 @@ p2m_pod_demand_populate(struct p2m_domai
     }
 
     /* Keep track of the highest gfn demand-populated by a guest fault */
-    if ( q == p2m_guest && gfn > p2m->pod.max_guest )
+    if ( gfn > p2m->pod.max_guest )
         p2m->pod.max_guest = gfn;
 
     if ( p2m->pod.count == 0 )
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
@@ -180,7 +180,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     {
         /* Return invalid_mfn to avoid caller's access */
         mfn = _mfn(INVALID_MFN);
-        if (q == p2m_guest)
+        if (q != p2m_query)
             domain_crash(p2m->domain);
     }
 #endif
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/shadow/multi.c	Thu Feb 23 16:15:29 2012 +0000
@@ -3189,7 +3189,7 @@ static int sh_page_fault(struct vcpu *v,
 
     /* What mfn is the guest trying to access? */
     gfn = guest_l1e_get_gfn(gw.l1e);
-    gmfn = get_gfn_guest(d, gfn, &p2mt);
+    gmfn = get_gfn(d, gfn, &p2mt);
 
     if ( shadow_mode_refcounts(d) && 
          ((!p2m_is_valid(p2mt) && !p2m_is_grant(p2mt)) ||
@@ -4840,7 +4840,7 @@ static mfn_t emulate_gva_to_mfn(struct v
 
     /* Translate the GFN to an MFN */
     ASSERT(!paging_locked_by_me(v->domain));
-    mfn = get_gfn_guest(v->domain, _gfn(gfn), &p2mt);
+    mfn = get_gfn(v->domain, _gfn(gfn), &p2mt);
         
     if ( p2m_is_readonly(p2mt) )
     {
diff -r e165cfc82565 -r ec94098841bf xen/arch/x86/mm/shadow/types.h
--- a/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
@@ -194,8 +194,6 @@ static inline shadow_l4e_t shadow_l4e_fr
  /* Override get_gfn to work with gfn_t */
 #undef get_gfn_query
 #define get_gfn_query(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_query)
-#undef get_gfn_guest
-#define get_gfn_guest(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_guest)
 
 /* The shadow types needed for the various levels. */
 
diff -r e165cfc82565 -r ec94098841bf xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
@@ -114,11 +114,11 @@ typedef enum {
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
 
+/* Modifiers to the query */
 typedef enum {
     p2m_query,              /* Do not populate a PoD entries      */
     p2m_alloc,              /* Automatically populate PoD entries */
     p2m_unshare,            /* Break c-o-w sharing; implies alloc */
-    p2m_guest,              /* Guest demand-fault; implies alloc  */
 } p2m_query_t;
 
 /* We use bitmaps and maks to handle groups of types */
@@ -332,7 +332,6 @@ static inline mfn_t get_gfn_type(struct 
  * lock held. */
 #define get_gfn(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
 #define get_gfn_query(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_guest(d, g, t)   get_gfn_type((d), (g), (t), p2m_guest)
 #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
 
 /* Compatibility function exporting the old untyped interface */

--===============7673527983294314386==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7673527983294314386==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdZ-0000ln-2p; Thu, 23 Feb 2012 16:35:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdX-0000jU-K1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330014909!10292857!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19872 invoked from network); 23 Feb 2012 16:35:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150114"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:47 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:44 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcy-0001jV-5K; Thu, 23 Feb 2012 16:34:44 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcx-0001nu-Ro;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============6580150332276272341=="
MIME-Version: 1.0
X-Mercurial-Node: 510d80343793227bd39b9a5d4d3b61b9a3f776e4
Message-ID: <510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:27 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6580150332276272341==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-5.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013889 0
# Node ID 510d80343793227bd39b9a5d4d3b61b9a3f776e4
# Parent  4ed10bf6325a8b07a9fb490ed575965c698a0cdd
[RFC] x86/mm: use wait queues for mem_paging

Use a wait queue to put a guest vcpu to sleep while the requested gfn is
in paging state. This adds missing p2m_mem_paging_populate() calls to
some callers of the new get_gfn* variants, which would crash now
because they get an invalid mfn. It also fixes guest crashes due to
unexpected returns from do_memory_op because copy_to/from_guest ran into
a paged gfn. Now those places will always get a valid mfn.

This is based on an earlier RFC patch by Olaf Hering, but heavily
simplified (removing a per-gfn queue of waiting vcpus in favour of
a scan of all vcpus on page-in).

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4ed10bf6325a -r 510d80343793 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:09 2012 +0000
@@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    locked = locked && hap_enabled(p2m->domain);
+
+#ifdef __x86_64__
+again:
+#endif
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
+    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
+         && p2m->domain == current->domain ) 
+    {
+        if ( locked )
+            gfn_unlock(p2m, gfn, 0);
+
+        /* Ping the pager */
+        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+            p2m_mem_paging_populate(p2m->domain, gfn);
+
+        /* Wait until the pager finishes paging it in */
+        current->arch.mem_paging_gfn = gfn;
+        wait_event(current->arch.mem_paging_wq, ({
+                    int done;
+                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
+                    done = (*t != p2m_ram_paging_in);
+                    /* Safety catch: it _should_ be safe to wait here
+                     * but if it's not, crash the VM, not the host */
+                    if ( in_atomic() )
+                    {
+                        WARN();
+                        domain_crash(p2m->domain);
+                        done = 1;
+                    }
+                    done;
+                }));
+        goto again;
+    }
+#endif
+
+#ifdef __x86_64__
     if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -946,17 +982,17 @@ void p2m_mem_paging_drop_page(struct dom
  * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
  * paging types because the gfn may not be backed by a mfn.
  *
- * The gfn can be in any of the paging states, but the pager needs only be
- * notified when the gfn is in the paging-out path (paging_out or paged).  This
- * function may be called more than once from several vcpus. If the vcpu belongs
- * to the guest, the vcpu must be stopped and the pager notified that the vcpu
- * was stopped. The pager needs to handle several requests for the same gfn.
+ * The gfn can be in any of the paging states, but the pager needs only
+ * be notified when the gfn is in the paging-out path (paging_out or
+ * paged).  This function may be called more than once from several
+ * vcpus.  The pager needs to handle several requests for the same gfn.
  *
- * If the gfn is not in the paging-out path and the vcpu does not belong to the
- * guest, nothing needs to be done and the function assumes that a request was
- * already sent to the pager. In this case the caller has to try again until the
- * gfn is fully paged in again.
+ * If the gfn is not in the paging-out path nothing needs to be done and
+ * the function assumes that a request was already sent to the pager.
+ * In this case the caller has to try again until the gfn is fully paged
+ * in again.
  */
+
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
@@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int send_request = 0;
 
     /* We're paging. There should be a ring */
     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
@@ -987,19 +1024,22 @@ void p2m_mem_paging_populate(struct doma
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
-
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain == d )
+            /* Short-cut back to paged-in state (but not for foreign 
+             * mappings, or the pager couldn't map it to page it out) */
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                          paging_mode_log_dirty(d) 
+                          ? p2m_ram_logdirty : p2m_ram_rw, a);
+        else
+        {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+            send_request = 1;
+        }
     }
     gfn_unlock(p2m, gfn, 0);
 
-    /* Pause domain if request came from guest and gfn has paging type */
-    if ( p2m_is_paging(p2mt) && v->domain == d )
-    {
-        vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    }
     /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
+    if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_cancel_slot(d, &d->mem_event->paging);
@@ -1122,6 +1162,7 @@ void p2m_mem_paging_resume(struct domain
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     mem_event_response_t rsp;
+    struct vcpu *v;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -1147,9 +1188,10 @@ void p2m_mem_paging_resume(struct domain
             }
             gfn_unlock(p2m, rsp.gfn, 0);
         }
-        /* Unpause domain */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+        /* Wake any vcpus that were waiting for this GFN */
+        for_each_vcpu ( d, v )
+            if ( v->arch.mem_paging_gfn == rsp.gfn )
+                wake_up_all(&v->arch.mem_paging_wq);
     }
 }
 
diff -r 4ed10bf6325a -r 510d80343793 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/domain.h	Thu Feb 23 16:18:09 2012 +0000
@@ -4,6 +4,7 @@
 #include <xen/config.h>
 #include <xen/mm.h>
 #include <xen/radix-tree.h>
+#include <xen/wait.h>
 #include <asm/hvm/vcpu.h>
 #include <asm/hvm/domain.h>
 #include <asm/e820.h>
@@ -491,6 +492,12 @@ struct arch_vcpu
     
     struct paging_vcpu paging;
 
+#ifdef CONFIG_X86_64
+    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
+    struct waitqueue_head mem_paging_wq;
+    unsigned long mem_paging_gfn;
+#endif
+
 #ifdef CONFIG_X86_32
     /* map_domain_page() mapping cache. */
     struct mapcache_vcpu mapcache;

--===============6580150332276272341==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6580150332276272341==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdZ-0000ln-2p; Thu, 23 Feb 2012 16:35:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdX-0000jU-K1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330014909!10292857!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19872 invoked from network); 23 Feb 2012 16:35:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150114"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:47 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:44 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcy-0001jV-5K; Thu, 23 Feb 2012 16:34:44 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcx-0001nu-Ro;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============6580150332276272341=="
MIME-Version: 1.0
X-Mercurial-Node: 510d80343793227bd39b9a5d4d3b61b9a3f776e4
Message-ID: <510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:27 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6580150332276272341==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-5.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013889 0
# Node ID 510d80343793227bd39b9a5d4d3b61b9a3f776e4
# Parent  4ed10bf6325a8b07a9fb490ed575965c698a0cdd
[RFC] x86/mm: use wait queues for mem_paging

Use a wait queue to put a guest vcpu to sleep while the requested gfn is
in paging state. This adds missing p2m_mem_paging_populate() calls to
some callers of the new get_gfn* variants, which would crash now
because they get an invalid mfn. It also fixes guest crashes due to
unexpected returns from do_memory_op because copy_to/from_guest ran into
a paged gfn. Now those places will always get a valid mfn.

This is based on an earlier RFC patch by Olaf Hering, but heavily
simplified (removing a per-gfn queue of waiting vcpus in favour of
a scan of all vcpus on page-in).

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4ed10bf6325a -r 510d80343793 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:09 2012 +0000
@@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    locked = locked && hap_enabled(p2m->domain);
+
+#ifdef __x86_64__
+again:
+#endif
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
+    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
+         && p2m->domain == current->domain ) 
+    {
+        if ( locked )
+            gfn_unlock(p2m, gfn, 0);
+
+        /* Ping the pager */
+        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
+            p2m_mem_paging_populate(p2m->domain, gfn);
+
+        /* Wait until the pager finishes paging it in */
+        current->arch.mem_paging_gfn = gfn;
+        wait_event(current->arch.mem_paging_wq, ({
+                    int done;
+                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
+                    done = (*t != p2m_ram_paging_in);
+                    /* Safety catch: it _should_ be safe to wait here
+                     * but if it's not, crash the VM, not the host */
+                    if ( in_atomic() )
+                    {
+                        WARN();
+                        domain_crash(p2m->domain);
+                        done = 1;
+                    }
+                    done;
+                }));
+        goto again;
+    }
+#endif
+
+#ifdef __x86_64__
     if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -946,17 +982,17 @@ void p2m_mem_paging_drop_page(struct dom
  * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
  * paging types because the gfn may not be backed by a mfn.
  *
- * The gfn can be in any of the paging states, but the pager needs only be
- * notified when the gfn is in the paging-out path (paging_out or paged).  This
- * function may be called more than once from several vcpus. If the vcpu belongs
- * to the guest, the vcpu must be stopped and the pager notified that the vcpu
- * was stopped. The pager needs to handle several requests for the same gfn.
+ * The gfn can be in any of the paging states, but the pager needs only
+ * be notified when the gfn is in the paging-out path (paging_out or
+ * paged).  This function may be called more than once from several
+ * vcpus.  The pager needs to handle several requests for the same gfn.
  *
- * If the gfn is not in the paging-out path and the vcpu does not belong to the
- * guest, nothing needs to be done and the function assumes that a request was
- * already sent to the pager. In this case the caller has to try again until the
- * gfn is fully paged in again.
+ * If the gfn is not in the paging-out path nothing needs to be done and
+ * the function assumes that a request was already sent to the pager.
+ * In this case the caller has to try again until the gfn is fully paged
+ * in again.
  */
+
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
@@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int send_request = 0;
 
     /* We're paging. There should be a ring */
     int rc = mem_event_claim_slot(d, &d->mem_event->paging);
@@ -987,19 +1024,22 @@ void p2m_mem_paging_populate(struct doma
         /* Evict will fail now, tag this request for pager */
         if ( p2mt == p2m_ram_paging_out )
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
-
-        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain == d )
+            /* Short-cut back to paged-in state (but not for foreign 
+             * mappings, or the pager couldn't map it to page it out) */
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
+                          paging_mode_log_dirty(d) 
+                          ? p2m_ram_logdirty : p2m_ram_rw, a);
+        else
+        {
+            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+            send_request = 1;
+        }
     }
     gfn_unlock(p2m, gfn, 0);
 
-    /* Pause domain if request came from guest and gfn has paging type */
-    if ( p2m_is_paging(p2mt) && v->domain == d )
-    {
-        vcpu_pause_nosync(v);
-        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
-    }
     /* No need to inform pager if the gfn is not in the page-out path */
-    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
+    if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_cancel_slot(d, &d->mem_event->paging);
@@ -1122,6 +1162,7 @@ void p2m_mem_paging_resume(struct domain
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     mem_event_response_t rsp;
+    struct vcpu *v;
     p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
@@ -1147,9 +1188,10 @@ void p2m_mem_paging_resume(struct domain
             }
             gfn_unlock(p2m, rsp.gfn, 0);
         }
-        /* Unpause domain */
-        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+        /* Wake any vcpus that were waiting for this GFN */
+        for_each_vcpu ( d, v )
+            if ( v->arch.mem_paging_gfn == rsp.gfn )
+                wake_up_all(&v->arch.mem_paging_wq);
     }
 }
 
diff -r 4ed10bf6325a -r 510d80343793 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/domain.h	Thu Feb 23 16:18:09 2012 +0000
@@ -4,6 +4,7 @@
 #include <xen/config.h>
 #include <xen/mm.h>
 #include <xen/radix-tree.h>
+#include <xen/wait.h>
 #include <asm/hvm/vcpu.h>
 #include <asm/hvm/domain.h>
 #include <asm/e820.h>
@@ -491,6 +492,12 @@ struct arch_vcpu
     
     struct paging_vcpu paging;
 
+#ifdef CONFIG_X86_64
+    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
+    struct waitqueue_head mem_paging_wq;
+    unsigned long mem_paging_gfn;
+#endif
+
 #ifdef CONFIG_X86_32
     /* map_domain_page() mapping cache. */
     struct mapcache_vcpu mapcache;

--===============6580150332276272341==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6580150332276272341==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdS-0000js-Sm; Thu, 23 Feb 2012 16:35:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdR-0000it-Gj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:13 +0000
Received: from [85.158.139.83:61799] by server-7.bemta-5.messagelabs.com id
	8D/1F-16195-0CA664F4; Thu, 23 Feb 2012 16:35:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330014907!16365449!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16557 invoked from network); 23 Feb 2012 16:35:12 -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;
	23 Feb 2012 16:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150125"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:45 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcw-0001jD-KI; Thu, 23 Feb 2012 16:34:42 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcw-0001nb-D4;
	Thu, 23 Feb 2012 16:34:42 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:22 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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

This is v2 of the patch I posted last week, after feedback from Andres. 

The first four patches are cleanups that should probably happen even
if the main waitq patch doesn't go in.

Patch 5 is the waitq patch, updated but largely following the same 
approach. I'm not suggesting it be applied right now because I know
at least one path (get_two_gfns()) needs work before it's safe.

Patch 6 is a follow-up to avoid claiming a slot unnecessarily in 
p2m_mem_paging_populate(); it's also a good idea even if the main 
waitq patch doesn't happen but would need to be backported since 
it only applies on top of those changes.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdS-0000js-Sm; Thu, 23 Feb 2012 16:35:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdR-0000it-Gj
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:13 +0000
Received: from [85.158.139.83:61799] by server-7.bemta-5.messagelabs.com id
	8D/1F-16195-0CA664F4; Thu, 23 Feb 2012 16:35:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330014907!16365449!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16557 invoked from network); 23 Feb 2012 16:35:12 -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;
	23 Feb 2012 16:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150125"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:52 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:45 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcw-0001jD-KI; Thu, 23 Feb 2012 16:34:42 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcw-0001nb-D4;
	Thu, 23 Feb 2012 16:34:42 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:22 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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

This is v2 of the patch I posted last week, after feedback from Andres. 

The first four patches are cleanups that should probably happen even
if the main waitq patch doesn't go in.

Patch 5 is the waitq patch, updated but largely following the same 
approach. I'm not suggesting it be applied right now because I know
at least one path (get_two_gfns()) needs work before it's safe.

Patch 6 is a follow-up to avoid claiming a slot unnecessarily in 
p2m_mem_paging_populate(); it's also a good idea even if the main 
waitq patch doesn't happen but would need to be backported since 
it only applies on top of those changes.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdY-0000lb-Mr; Thu, 23 Feb 2012 16:35:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdW-0000jA-Iw
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330014909!10292857!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19831 invoked from network); 23 Feb 2012 16:35:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150103"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:45 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:43 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcx-0001jM-HP; Thu, 23 Feb 2012 16:34:43 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcx-0001nm-7o;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============2082719476049360885=="
MIME-Version: 1.0
X-Mercurial-Node: 00f61d0186a6b098b349b6f94c9a11c5a18dc99a
Message-ID: <00f61d0186a6b098b349.1330014865@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:25 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 6] x86/mm: make 'query type' argument to
 get_gfn into a set of flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2082719476049360885==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-3.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID 00f61d0186a6b098b349b6f94c9a11c5a18dc99a
# Parent  ec94098841bfae20101608f3daf7a1a01ff71c49
x86/mm: make 'query type' argument to get_gfn into a set of flags

Having an enum for this won't work if we want to add any orthogonal
options to it -- the existing code is only correct (after the removal of
p2m_guest in the previous patch) because there are no tests anywhere for
'== p2m_alloc', only for '!= p2m_query' and '== p2m_unshare'.

Replace it with a set of flags.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
@@ -696,7 +696,7 @@ static int hvmemul_rep_movs(
 
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 p2m_alloc, &tg);
+                 P2M_ALLOC, &tg);
 
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1235,7 +1235,7 @@ int hvm_hap_nested_page_fault(unsigned l
 
     p2m = p2m_get_hostp2m(v->domain);
     mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 
-                              access_w ? p2m_unshare : p2m_alloc, NULL);
+                              P2M_ALLOC | (access_w ? P2M_UNSHARE : 0), NULL);
 
     /* Check access permissions first, then handle faults */
     if ( mfn_x(mfn) != INVALID_MFN )
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1265,7 +1265,7 @@ static void svm_do_nested_pgfault(struct
         p2m = p2m_get_p2m(v);
         _d.gpa = gpa;
         _d.qualification = 0;
-        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, p2m_query, NULL);
+        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL);
         __put_gfn(p2m, gfn);
         _d.mfn = mfn_x(mfn);
         
@@ -1287,7 +1287,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
+    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
     __put_gfn(p2m, gfn);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
@@ -98,7 +98,8 @@ static inline void *map_domain_gfn(struc
     void *map;
 
     /* Translate the gfn, unsharing if shared */
-    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, p2m_unshare, NULL);
+    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, 
+                               P2M_ALLOC | P2M_UNSHARE, NULL);
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/hap/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
@@ -60,7 +60,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 
     /* Get the top-level table's MFN */
     top_gfn = cr3 >> PAGE_SHIFT;
-    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, p2m_unshare, NULL);
+    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, 
+                                  P2M_ALLOC | P2M_UNSHARE, NULL);
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -96,7 +97,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( missing == 0 )
     {
         gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
-        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma, p2m_unshare, NULL); 
+        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
+                                  P2M_ALLOC | P2M_UNSHARE, NULL); 
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/hap/nested_hap.c
--- a/xen/arch/x86/mm/hap/nested_hap.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/hap/nested_hap.c	Thu Feb 23 16:15:29 2012 +0000
@@ -150,7 +150,7 @@ nestedhap_walk_L0_p2m(struct p2m_domain 
 
     /* walk L0 P2M table */
     mfn = get_gfn_type_access(p2m, L1_gpa >> PAGE_SHIFT, &p2mt, &p2ma, 
-                              p2m_query, page_order);
+                              0, page_order);
 
     rc = NESTEDHVM_PAGEFAULT_MMIO;
     if ( p2m_is_mmio(p2mt) )
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/mem_sharing.c	Thu Feb 23 16:15:29 2012 +0000
@@ -734,7 +734,7 @@ int mem_sharing_share_pages(struct domai
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, NULL, &cmfn,
-                 p2m_query, &tg);
+                 0, &tg);
 
     /* This tricky business is to avoid two callers deadlocking if 
      * grabbing pages in opposite client/source order */
@@ -849,7 +849,7 @@ int mem_sharing_add_to_physmap(struct do
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, &a, &cmfn,
-                 p2m_query, &tg);
+                 0, &tg);
 
     /* Get the source shared page, check and lock */
     ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Feb 23 16:15:29 2012 +0000
@@ -514,7 +514,7 @@ static mfn_t ept_get_entry(struct p2m_do
             goto out;
         else if ( ret == GUEST_TABLE_POD_PAGE )
         {
-            if ( q == p2m_query )
+            if ( !(q & P2M_ALLOC) )
             {
                 *t = p2m_populate_on_demand;
                 goto out;
@@ -541,7 +541,7 @@ static mfn_t ept_get_entry(struct p2m_do
 
     if ( ept_entry->sa_p2mt == p2m_populate_on_demand )
     {
-        if ( q == p2m_query )
+        if ( !(q & P2M_ALLOC) )
         {
             *t = p2m_populate_on_demand;
             goto out;
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
@@ -529,7 +529,7 @@ p2m_pod_decrease_reservation(struct doma
         p2m_access_t a;
         p2m_type_t t;
 
-        (void)p2m->get_entry(p2m, gpfn + i, &t, &a, p2m_query, NULL);
+        (void)p2m->get_entry(p2m, gpfn + i, &t, &a, 0, NULL);
 
         if ( t == p2m_populate_on_demand )
             pod++;
@@ -570,7 +570,7 @@ p2m_pod_decrease_reservation(struct doma
         p2m_type_t t;
         p2m_access_t a;
 
-        mfn = p2m->get_entry(p2m, gpfn + i, &t, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gpfn + i, &t, &a, 0, NULL);
         if ( t == p2m_populate_on_demand )
         {
             set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, p2m->default_access);
@@ -656,7 +656,7 @@ p2m_pod_zero_check_superpage(struct p2m_
     for ( i=0; i<SUPERPAGE_PAGES; i++ )
     {
         p2m_access_t a; 
-        mfn = p2m->get_entry(p2m, gfn + i, &type, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gfn + i, &type, &a, 0, NULL);
 
         if ( i == 0 )
         {
@@ -786,7 +786,7 @@ p2m_pod_zero_check(struct p2m_domain *p2
     for ( i=0; i<count; i++ )
     {
         p2m_access_t a;
-        mfns[i] = p2m->get_entry(p2m, gfns[i], types + i, &a, p2m_query, NULL);
+        mfns[i] = p2m->get_entry(p2m, gfns[i], types + i, &a, 0, NULL);
         /* If this is ram, and not a pagetable or from the xen heap, and probably not mapped
            elsewhere, map it; otherwise, skip. */
         if ( p2m_is_ram(types[i])
@@ -932,7 +932,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
     for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
     {
         p2m_access_t a;
-        (void)p2m->get_entry(p2m, i, &t, &a, p2m_query, NULL);
+        (void)p2m->get_entry(p2m, i, &t, &a, 0, NULL);
         if ( p2m_is_ram(t) )
         {
             gfns[j] = i;
@@ -1130,7 +1130,7 @@ guest_physmap_mark_populate_on_demand(st
     for ( i = 0; i < (1UL << order); i++ )
     {
         p2m_access_t a;
-        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL);
         if ( p2m_is_ram(ot) )
         {
             printk("%s: gfn_to_mfn returned type %d!\n",
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Feb 23 16:15:29 2012 +0000
@@ -513,7 +513,7 @@ pod_retry_l3:
              (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_query )
+            if ( q & P2M_ALLOC )
             {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                     goto pod_retry_l3;
@@ -565,7 +565,7 @@ pod_retry_l2:
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
-            if ( q != p2m_query )
+            if ( q & P2M_ALLOC )
             {
                 if ( !p2m_pod_demand_populate(p2m, gfn, 
                                                 PAGE_ORDER_2M, q) )
@@ -623,7 +623,7 @@ pod_retry_l1:
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
-            if ( q != p2m_query )
+            if ( q & P2M_ALLOC )
             {
                 if ( !p2m_pod_demand_populate(p2m, gfn, 
                                                 PAGE_ORDER_4K, q) )
@@ -714,7 +714,7 @@ pod_retry_l3:
         {
             if ( p2m_flags_to_type(l3e_get_flags(*l3e)) == p2m_populate_on_demand )
             {
-                if ( q != p2m_query )
+                if ( q & P2M_ALLOC )
                 {
                     if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
@@ -753,7 +753,7 @@ pod_retry_l2:
         /* PoD: Try to populate a 2-meg chunk */
         if ( p2m_flags_to_type(l2e_get_flags(*l2e)) == p2m_populate_on_demand )
         {
-            if ( q != p2m_query ) {
+            if ( q & P2M_ALLOC ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
             } else
@@ -786,7 +786,7 @@ pod_retry_l1:
         /* PoD: Try to populate */
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
         {
-            if ( q != p2m_query ) {
+            if ( q & P2M_ALLOC ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
@@ -167,7 +167,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
-    if ( q == p2m_unshare && p2m_is_shared(*t) )
+    if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -180,7 +180,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     {
         /* Return invalid_mfn to avoid caller's access */
         mfn = _mfn(INVALID_MFN);
-        if (q != p2m_query)
+        if ( q & P2M_ALLOC )
             domain_crash(p2m->domain);
     }
 #endif
@@ -367,7 +367,7 @@ void p2m_teardown(struct p2m_domain *p2m
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
         p2m_access_t a;
-        mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
@@ -437,7 +437,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
     {
         for ( i = 0; i < (1UL << page_order); i++ )
         {
-            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
+            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, 0, NULL);
             if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
@@ -499,7 +499,7 @@ guest_physmap_add_entry(struct domain *d
     /* First, remove m->p mappings for existing p->m mappings */
     for ( i = 0; i < (1UL << page_order); i++ )
     {
-        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL);
 #ifdef __x86_64__
         if ( p2m_is_shared(ot) )
         {
@@ -512,7 +512,7 @@ guest_physmap_add_entry(struct domain *d
                 p2m_unlock(p2m);
                 return rc;
             }
-            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL);
             ASSERT(!p2m_is_shared(ot));
         }
 #endif /* __x86_64__ */
@@ -561,7 +561,7 @@ guest_physmap_add_entry(struct domain *d
              * address */
             P2M_DEBUG("aliased! mfn=%#lx, old gfn=%#lx, new gfn=%#lx\n",
                       mfn + i, ogfn, gfn + i);
-            omfn = p2m->get_entry(p2m, ogfn, &ot, &a, p2m_query, NULL);
+            omfn = p2m->get_entry(p2m, ogfn, &ot, &a, 0, NULL);
             if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
             {
                 ASSERT(mfn_valid(omfn));
@@ -620,7 +620,7 @@ p2m_type_t p2m_change_type(struct domain
 
     gfn_lock(p2m, gfn, 0);
 
-    mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &pt, &a, 0, NULL);
     if ( pt == ot )
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
 
@@ -648,7 +648,7 @@ void p2m_change_type_range(struct domain
 
     for ( gfn = start; gfn < end; gfn++ )
     {
-        mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gfn, &pt, &a, 0, NULL);
         if ( pt == ot )
             set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
     }
@@ -674,7 +674,7 @@ set_mmio_p2m_entry(struct domain *d, uns
         return 0;
 
     gfn_lock(p2m, gfn, 0);
-    omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
+    omfn = p2m->get_entry(p2m, gfn, &ot, &a, 0, NULL);
     if ( p2m_is_grant(ot) )
     {
         p2m_unlock(p2m);
@@ -710,7 +710,7 @@ clear_mmio_p2m_entry(struct domain *d, u
         return 0;
 
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
 
     /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
     if ( (INVALID_MFN == mfn_x(mfn)) || (t != p2m_mmio_direct) )
@@ -741,7 +741,7 @@ set_shared_p2m_entry(struct domain *d, u
         return 0;
 
     gfn_lock(p2m, gfn, 0);
-    omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
+    omfn = p2m->get_entry(p2m, gfn, &ot, &a, 0, NULL);
     /* At the moment we only allow p2m change if gfn has already been made
      * sharable first */
     ASSERT(p2m_is_shared(ot));
@@ -793,7 +793,7 @@ int p2m_mem_paging_nominate(struct domai
 
     gfn_lock(p2m, gfn, 0);
 
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
 
     /* Check if mfn is valid */
     if ( !mfn_valid(mfn) )
@@ -856,7 +856,7 @@ int p2m_mem_paging_evict(struct domain *
     gfn_lock(p2m, gfn, 0);
 
     /* Get mfn */
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
     if ( unlikely(!mfn_valid(mfn)) )
         goto out;
 
@@ -980,7 +980,7 @@ void p2m_mem_paging_populate(struct doma
 
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
     {
@@ -1042,7 +1042,7 @@ int p2m_mem_paging_prep(struct domain *d
 
     gfn_lock(p2m, gfn, 0);
 
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
 
     ret = -ENOENT;
     /* Allow missing pages */
@@ -1135,7 +1135,7 @@ void p2m_mem_paging_resume(struct domain
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
             gfn_lock(p2m, rsp.gfn, 0);
-            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
+            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, 0, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
             if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
@@ -1168,7 +1168,7 @@ bool_t p2m_mem_access_check(unsigned lon
 
     /* First, handle rx2rw conversion automatically */
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
@@ -1297,7 +1297,7 @@ int p2m_set_mem_access(struct domain *d,
     p2m_lock(p2m);
     for ( pfn = start_pfn; pfn < start_pfn + nr; pfn++ )
     {
-        mfn = p2m->get_entry(p2m, pfn, &t, &_a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, pfn, &t, &_a, 0, NULL);
         if ( p2m->set_entry(p2m, pfn, mfn, PAGE_ORDER_4K, t, a) == 0 )
         {
             rc = -ENOMEM;
@@ -1338,7 +1338,7 @@ int p2m_get_mem_access(struct domain *d,
     }
 
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, pfn, &t, &a, 0, NULL);
     gfn_unlock(p2m, gfn, 0);
 
     if ( mfn_x(mfn) == INVALID_MFN )
@@ -1579,7 +1579,7 @@ void audit_p2m(struct domain *d,
             continue;
         }
 
-        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, p2m_query, NULL);
+        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, 0, NULL);
         if ( mfn_x(p2mfn) != mfn )
         {
             mpbad++;
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/shadow/types.h
--- a/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
@@ -193,7 +193,7 @@ static inline shadow_l4e_t shadow_l4e_fr
 
  /* Override get_gfn to work with gfn_t */
 #undef get_gfn_query
-#define get_gfn_query(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_query)
+#define get_gfn_query(d, g, t) get_gfn_type((d), gfn_x(g), (t), 0)
 
 /* The shadow types needed for the various levels. */
 
diff -r ec94098841bf -r 00f61d0186a6 xen/include/asm-x86/guest_pt.h
--- a/xen/include/asm-x86/guest_pt.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/guest_pt.h	Thu Feb 23 16:15:29 2012 +0000
@@ -53,7 +53,7 @@ gfn_to_paddr(gfn_t gfn)
 
 /* Override get_gfn to work with gfn_t */
 #undef get_gfn
-#define get_gfn(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_alloc)
+#define get_gfn(d, g, t) get_gfn_type((d), gfn_x(g), (t), P2M_ALLOC)
 
 
 /* Types of the guest's page tables and access functions for them */
diff -r ec94098841bf -r 00f61d0186a6 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
@@ -115,11 +115,9 @@ typedef enum {
 } p2m_access_t;
 
 /* Modifiers to the query */
-typedef enum {
-    p2m_query,              /* Do not populate a PoD entries      */
-    p2m_alloc,              /* Automatically populate PoD entries */
-    p2m_unshare,            /* Break c-o-w sharing; implies alloc */
-} p2m_query_t;
+typedef unsigned int p2m_query_t;
+#define P2M_ALLOC    (1u<<0)   /* Populate PoD and paged-out entries */
+#define P2M_UNSHARE  (1u<<1)   /* Break CoW sharing */
 
 /* We use bitmaps and maks to handle groups of types */
 #define p2m_to_mask(_t) (1UL << (_t))
@@ -330,9 +328,10 @@ static inline mfn_t get_gfn_type(struct 
  * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
  * p2m lock; none of the others can be called with the p2m or paging
  * lock held. */
-#define get_gfn(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
-#define get_gfn_query(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
+#define get_gfn(d, g, t)         get_gfn_type((d), (g), (t), P2M_ALLOC)
+#define get_gfn_query(d, g, t)   get_gfn_type((d), (g), (t), 0)
+#define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \
+                                              P2M_ALLOC | P2M_UNSHARE)
 
 /* Compatibility function exporting the old untyped interface */
 static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
@@ -364,8 +363,7 @@ static inline mfn_t get_gfn_query_unlock
                                            p2m_type_t *t)
 {
     p2m_access_t a;
-    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 
-                                    p2m_query, NULL, 0);
+    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0);
 }
 
 /* General conversion function from mfn to gfn */

--===============2082719476049360885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2082719476049360885==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bdY-0000lb-Mr; Thu, 23 Feb 2012 16:35:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0bdW-0000jA-Iw
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:35:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330014909!10292857!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19831 invoked from network); 23 Feb 2012 16:35:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183150103"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:34:45 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:34:43 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0bcx-0001jM-HP; Thu, 23 Feb 2012 16:34:43 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0bcx-0001nm-7o;
	Thu, 23 Feb 2012 16:34:43 +0000
Content-Type: multipart/mixed; boundary="===============2082719476049360885=="
MIME-Version: 1.0
X-Mercurial-Node: 00f61d0186a6b098b349b6f94c9a11c5a18dc99a
Message-ID: <00f61d0186a6b098b349.1330014865@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 16:34:25 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 6] x86/mm: make 'query type' argument to
 get_gfn into a set of flags
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2082719476049360885==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="xen-unstable.hg-3.patch"

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330013729 0
# Node ID 00f61d0186a6b098b349b6f94c9a11c5a18dc99a
# Parent  ec94098841bfae20101608f3daf7a1a01ff71c49
x86/mm: make 'query type' argument to get_gfn into a set of flags

Having an enum for this won't work if we want to add any orthogonal
options to it -- the existing code is only correct (after the removal of
p2m_guest in the previous patch) because there are no tests anywhere for
'== p2m_alloc', only for '!= p2m_query' and '== p2m_unshare'.

Replace it with a set of flags.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/emulate.c	Thu Feb 23 16:15:29 2012 +0000
@@ -696,7 +696,7 @@ static int hvmemul_rep_movs(
 
     get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
                  current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
-                 p2m_alloc, &tg);
+                 P2M_ALLOC, &tg);
 
     if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) )
     {
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1235,7 +1235,7 @@ int hvm_hap_nested_page_fault(unsigned l
 
     p2m = p2m_get_hostp2m(v->domain);
     mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 
-                              access_w ? p2m_unshare : p2m_alloc, NULL);
+                              P2M_ALLOC | (access_w ? P2M_UNSHARE : 0), NULL);
 
     /* Check access permissions first, then handle faults */
     if ( mfn_x(mfn) != INVALID_MFN )
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Thu Feb 23 16:15:29 2012 +0000
@@ -1265,7 +1265,7 @@ static void svm_do_nested_pgfault(struct
         p2m = p2m_get_p2m(v);
         _d.gpa = gpa;
         _d.qualification = 0;
-        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, p2m_query, NULL);
+        mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL);
         __put_gfn(p2m, gfn);
         _d.mfn = mfn_x(mfn);
         
@@ -1287,7 +1287,7 @@ static void svm_do_nested_pgfault(struct
     if ( p2m == NULL )
         p2m = p2m_get_p2m(v);
     /* Everything else is an error. */
-    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
+    mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL);
     __put_gfn(p2m, gfn);
     gdprintk(XENLOG_ERR,
          "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
@@ -98,7 +98,8 @@ static inline void *map_domain_gfn(struc
     void *map;
 
     /* Translate the gfn, unsharing if shared */
-    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, p2m_unshare, NULL);
+    *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, 
+                               P2M_ALLOC | P2M_UNSHARE, NULL);
     if ( p2m_is_paging(*p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/hap/guest_walk.c
--- a/xen/arch/x86/mm/hap/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/hap/guest_walk.c	Thu Feb 23 16:15:29 2012 +0000
@@ -60,7 +60,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
 
     /* Get the top-level table's MFN */
     top_gfn = cr3 >> PAGE_SHIFT;
-    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, p2m_unshare, NULL);
+    top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, 
+                                  P2M_ALLOC | P2M_UNSHARE, NULL);
     if ( p2m_is_paging(p2mt) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
@@ -96,7 +97,8 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA
     if ( missing == 0 )
     {
         gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
-        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma, p2m_unshare, NULL); 
+        (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
+                                  P2M_ALLOC | P2M_UNSHARE, NULL); 
         if ( p2m_is_paging(p2mt) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/hap/nested_hap.c
--- a/xen/arch/x86/mm/hap/nested_hap.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/hap/nested_hap.c	Thu Feb 23 16:15:29 2012 +0000
@@ -150,7 +150,7 @@ nestedhap_walk_L0_p2m(struct p2m_domain 
 
     /* walk L0 P2M table */
     mfn = get_gfn_type_access(p2m, L1_gpa >> PAGE_SHIFT, &p2mt, &p2ma, 
-                              p2m_query, page_order);
+                              0, page_order);
 
     rc = NESTEDHVM_PAGEFAULT_MMIO;
     if ( p2m_is_mmio(p2mt) )
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/mem_sharing.c	Thu Feb 23 16:15:29 2012 +0000
@@ -734,7 +734,7 @@ int mem_sharing_share_pages(struct domai
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, NULL, &cmfn,
-                 p2m_query, &tg);
+                 0, &tg);
 
     /* This tricky business is to avoid two callers deadlocking if 
      * grabbing pages in opposite client/source order */
@@ -849,7 +849,7 @@ int mem_sharing_add_to_physmap(struct do
 
     get_two_gfns(sd, sgfn, &smfn_type, NULL, &smfn,
                  cd, cgfn, &cmfn_type, &a, &cmfn,
-                 p2m_query, &tg);
+                 0, &tg);
 
     /* Get the source shared page, check and lock */
     ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Feb 23 16:15:29 2012 +0000
@@ -514,7 +514,7 @@ static mfn_t ept_get_entry(struct p2m_do
             goto out;
         else if ( ret == GUEST_TABLE_POD_PAGE )
         {
-            if ( q == p2m_query )
+            if ( !(q & P2M_ALLOC) )
             {
                 *t = p2m_populate_on_demand;
                 goto out;
@@ -541,7 +541,7 @@ static mfn_t ept_get_entry(struct p2m_do
 
     if ( ept_entry->sa_p2mt == p2m_populate_on_demand )
     {
-        if ( q == p2m_query )
+        if ( !(q & P2M_ALLOC) )
         {
             *t = p2m_populate_on_demand;
             goto out;
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-pod.c	Thu Feb 23 16:15:29 2012 +0000
@@ -529,7 +529,7 @@ p2m_pod_decrease_reservation(struct doma
         p2m_access_t a;
         p2m_type_t t;
 
-        (void)p2m->get_entry(p2m, gpfn + i, &t, &a, p2m_query, NULL);
+        (void)p2m->get_entry(p2m, gpfn + i, &t, &a, 0, NULL);
 
         if ( t == p2m_populate_on_demand )
             pod++;
@@ -570,7 +570,7 @@ p2m_pod_decrease_reservation(struct doma
         p2m_type_t t;
         p2m_access_t a;
 
-        mfn = p2m->get_entry(p2m, gpfn + i, &t, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gpfn + i, &t, &a, 0, NULL);
         if ( t == p2m_populate_on_demand )
         {
             set_p2m_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid, p2m->default_access);
@@ -656,7 +656,7 @@ p2m_pod_zero_check_superpage(struct p2m_
     for ( i=0; i<SUPERPAGE_PAGES; i++ )
     {
         p2m_access_t a; 
-        mfn = p2m->get_entry(p2m, gfn + i, &type, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gfn + i, &type, &a, 0, NULL);
 
         if ( i == 0 )
         {
@@ -786,7 +786,7 @@ p2m_pod_zero_check(struct p2m_domain *p2
     for ( i=0; i<count; i++ )
     {
         p2m_access_t a;
-        mfns[i] = p2m->get_entry(p2m, gfns[i], types + i, &a, p2m_query, NULL);
+        mfns[i] = p2m->get_entry(p2m, gfns[i], types + i, &a, 0, NULL);
         /* If this is ram, and not a pagetable or from the xen heap, and probably not mapped
            elsewhere, map it; otherwise, skip. */
         if ( p2m_is_ram(types[i])
@@ -932,7 +932,7 @@ p2m_pod_emergency_sweep(struct p2m_domai
     for ( i=p2m->pod.reclaim_single; i > 0 ; i-- )
     {
         p2m_access_t a;
-        (void)p2m->get_entry(p2m, i, &t, &a, p2m_query, NULL);
+        (void)p2m->get_entry(p2m, i, &t, &a, 0, NULL);
         if ( p2m_is_ram(t) )
         {
             gfns[j] = i;
@@ -1130,7 +1130,7 @@ guest_physmap_mark_populate_on_demand(st
     for ( i = 0; i < (1UL << order); i++ )
     {
         p2m_access_t a;
-        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL);
         if ( p2m_is_ram(ot) )
         {
             printk("%s: gfn_to_mfn returned type %d!\n",
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Feb 23 16:15:29 2012 +0000
@@ -513,7 +513,7 @@ pod_retry_l3:
              (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_query )
+            if ( q & P2M_ALLOC )
             {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                     goto pod_retry_l3;
@@ -565,7 +565,7 @@ pod_retry_l2:
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
-            if ( q != p2m_query )
+            if ( q & P2M_ALLOC )
             {
                 if ( !p2m_pod_demand_populate(p2m, gfn, 
                                                 PAGE_ORDER_2M, q) )
@@ -623,7 +623,7 @@ pod_retry_l1:
         {
             /* The read has succeeded, so we know that the mapping
              * exits at this point.  */
-            if ( q != p2m_query )
+            if ( q & P2M_ALLOC )
             {
                 if ( !p2m_pod_demand_populate(p2m, gfn, 
                                                 PAGE_ORDER_4K, q) )
@@ -714,7 +714,7 @@ pod_retry_l3:
         {
             if ( p2m_flags_to_type(l3e_get_flags(*l3e)) == p2m_populate_on_demand )
             {
-                if ( q != p2m_query )
+                if ( q & P2M_ALLOC )
                 {
                     if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
@@ -753,7 +753,7 @@ pod_retry_l2:
         /* PoD: Try to populate a 2-meg chunk */
         if ( p2m_flags_to_type(l2e_get_flags(*l2e)) == p2m_populate_on_demand )
         {
-            if ( q != p2m_query ) {
+            if ( q & P2M_ALLOC ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_2M, q) )
                     goto pod_retry_l2;
             } else
@@ -786,7 +786,7 @@ pod_retry_l1:
         /* PoD: Try to populate */
         if ( p2m_flags_to_type(l1e_get_flags(*l1e)) == p2m_populate_on_demand )
         {
-            if ( q != p2m_query ) {
+            if ( q & P2M_ALLOC ) {
                 if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_4K, q) )
                     goto pod_retry_l1;
             } else
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:15:29 2012 +0000
@@ -167,7 +167,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
 
 #ifdef __x86_64__
-    if ( q == p2m_unshare && p2m_is_shared(*t) )
+    if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -180,7 +180,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     {
         /* Return invalid_mfn to avoid caller's access */
         mfn = _mfn(INVALID_MFN);
-        if (q != p2m_query)
+        if ( q & P2M_ALLOC )
             domain_crash(p2m->domain);
     }
 #endif
@@ -367,7 +367,7 @@ void p2m_teardown(struct p2m_domain *p2m
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
         p2m_access_t a;
-        mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
         if ( mfn_valid(mfn) && (t == p2m_ram_shared) )
         {
             ASSERT(!p2m_is_nestedp2m(p2m));
@@ -437,7 +437,7 @@ p2m_remove_page(struct p2m_domain *p2m, 
     {
         for ( i = 0; i < (1UL << page_order); i++ )
         {
-            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, p2m_query, NULL);
+            mfn_return = p2m->get_entry(p2m, gfn + i, &t, &a, 0, NULL);
             if ( !p2m_is_grant(t) && !p2m_is_shared(t) )
                 set_gpfn_from_mfn(mfn+i, INVALID_M2P_ENTRY);
             ASSERT( !p2m_is_valid(t) || mfn + i == mfn_x(mfn_return) );
@@ -499,7 +499,7 @@ guest_physmap_add_entry(struct domain *d
     /* First, remove m->p mappings for existing p->m mappings */
     for ( i = 0; i < (1UL << page_order); i++ )
     {
-        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+        omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL);
 #ifdef __x86_64__
         if ( p2m_is_shared(ot) )
         {
@@ -512,7 +512,7 @@ guest_physmap_add_entry(struct domain *d
                 p2m_unlock(p2m);
                 return rc;
             }
-            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, p2m_query, NULL);
+            omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL);
             ASSERT(!p2m_is_shared(ot));
         }
 #endif /* __x86_64__ */
@@ -561,7 +561,7 @@ guest_physmap_add_entry(struct domain *d
              * address */
             P2M_DEBUG("aliased! mfn=%#lx, old gfn=%#lx, new gfn=%#lx\n",
                       mfn + i, ogfn, gfn + i);
-            omfn = p2m->get_entry(p2m, ogfn, &ot, &a, p2m_query, NULL);
+            omfn = p2m->get_entry(p2m, ogfn, &ot, &a, 0, NULL);
             if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
             {
                 ASSERT(mfn_valid(omfn));
@@ -620,7 +620,7 @@ p2m_type_t p2m_change_type(struct domain
 
     gfn_lock(p2m, gfn, 0);
 
-    mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &pt, &a, 0, NULL);
     if ( pt == ot )
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
 
@@ -648,7 +648,7 @@ void p2m_change_type_range(struct domain
 
     for ( gfn = start; gfn < end; gfn++ )
     {
-        mfn = p2m->get_entry(p2m, gfn, &pt, &a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, gfn, &pt, &a, 0, NULL);
         if ( pt == ot )
             set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, nt, p2m->default_access);
     }
@@ -674,7 +674,7 @@ set_mmio_p2m_entry(struct domain *d, uns
         return 0;
 
     gfn_lock(p2m, gfn, 0);
-    omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
+    omfn = p2m->get_entry(p2m, gfn, &ot, &a, 0, NULL);
     if ( p2m_is_grant(ot) )
     {
         p2m_unlock(p2m);
@@ -710,7 +710,7 @@ clear_mmio_p2m_entry(struct domain *d, u
         return 0;
 
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &t, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL);
 
     /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
     if ( (INVALID_MFN == mfn_x(mfn)) || (t != p2m_mmio_direct) )
@@ -741,7 +741,7 @@ set_shared_p2m_entry(struct domain *d, u
         return 0;
 
     gfn_lock(p2m, gfn, 0);
-    omfn = p2m->get_entry(p2m, gfn, &ot, &a, p2m_query, NULL);
+    omfn = p2m->get_entry(p2m, gfn, &ot, &a, 0, NULL);
     /* At the moment we only allow p2m change if gfn has already been made
      * sharable first */
     ASSERT(p2m_is_shared(ot));
@@ -793,7 +793,7 @@ int p2m_mem_paging_nominate(struct domai
 
     gfn_lock(p2m, gfn, 0);
 
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
 
     /* Check if mfn is valid */
     if ( !mfn_valid(mfn) )
@@ -856,7 +856,7 @@ int p2m_mem_paging_evict(struct domain *
     gfn_lock(p2m, gfn, 0);
 
     /* Get mfn */
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
     if ( unlikely(!mfn_valid(mfn)) )
         goto out;
 
@@ -980,7 +980,7 @@ void p2m_mem_paging_populate(struct doma
 
     /* Fix p2m mapping */
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
     /* Allow only nominated or evicted pages to enter page-in path */
     if ( p2mt == p2m_ram_paging_out || p2mt == p2m_ram_paged )
     {
@@ -1042,7 +1042,7 @@ int p2m_mem_paging_prep(struct domain *d
 
     gfn_lock(p2m, gfn, 0);
 
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
 
     ret = -ENOENT;
     /* Allow missing pages */
@@ -1135,7 +1135,7 @@ void p2m_mem_paging_resume(struct domain
         if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
         {
             gfn_lock(p2m, rsp.gfn, 0);
-            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
+            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, 0, NULL);
             /* Allow only pages which were prepared properly, or pages which
              * were nominated but not evicted */
             if ( mfn_valid(mfn) && (p2mt == p2m_ram_paging_in) )
@@ -1168,7 +1168,7 @@ bool_t p2m_mem_access_check(unsigned lon
 
     /* First, handle rx2rw conversion automatically */
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL);
 
     if ( access_w && p2ma == p2m_access_rx2rw ) 
     {
@@ -1297,7 +1297,7 @@ int p2m_set_mem_access(struct domain *d,
     p2m_lock(p2m);
     for ( pfn = start_pfn; pfn < start_pfn + nr; pfn++ )
     {
-        mfn = p2m->get_entry(p2m, pfn, &t, &_a, p2m_query, NULL);
+        mfn = p2m->get_entry(p2m, pfn, &t, &_a, 0, NULL);
         if ( p2m->set_entry(p2m, pfn, mfn, PAGE_ORDER_4K, t, a) == 0 )
         {
             rc = -ENOMEM;
@@ -1338,7 +1338,7 @@ int p2m_get_mem_access(struct domain *d,
     }
 
     gfn_lock(p2m, gfn, 0);
-    mfn = p2m->get_entry(p2m, pfn, &t, &a, p2m_query, NULL);
+    mfn = p2m->get_entry(p2m, pfn, &t, &a, 0, NULL);
     gfn_unlock(p2m, gfn, 0);
 
     if ( mfn_x(mfn) == INVALID_MFN )
@@ -1579,7 +1579,7 @@ void audit_p2m(struct domain *d,
             continue;
         }
 
-        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, p2m_query, NULL);
+        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, 0, NULL);
         if ( mfn_x(p2mfn) != mfn )
         {
             mpbad++;
diff -r ec94098841bf -r 00f61d0186a6 xen/arch/x86/mm/shadow/types.h
--- a/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/arch/x86/mm/shadow/types.h	Thu Feb 23 16:15:29 2012 +0000
@@ -193,7 +193,7 @@ static inline shadow_l4e_t shadow_l4e_fr
 
  /* Override get_gfn to work with gfn_t */
 #undef get_gfn_query
-#define get_gfn_query(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_query)
+#define get_gfn_query(d, g, t) get_gfn_type((d), gfn_x(g), (t), 0)
 
 /* The shadow types needed for the various levels. */
 
diff -r ec94098841bf -r 00f61d0186a6 xen/include/asm-x86/guest_pt.h
--- a/xen/include/asm-x86/guest_pt.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/guest_pt.h	Thu Feb 23 16:15:29 2012 +0000
@@ -53,7 +53,7 @@ gfn_to_paddr(gfn_t gfn)
 
 /* Override get_gfn to work with gfn_t */
 #undef get_gfn
-#define get_gfn(d, g, t) get_gfn_type((d), gfn_x(g), (t), p2m_alloc)
+#define get_gfn(d, g, t) get_gfn_type((d), gfn_x(g), (t), P2M_ALLOC)
 
 
 /* Types of the guest's page tables and access functions for them */
diff -r ec94098841bf -r 00f61d0186a6 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
+++ b/xen/include/asm-x86/p2m.h	Thu Feb 23 16:15:29 2012 +0000
@@ -115,11 +115,9 @@ typedef enum {
 } p2m_access_t;
 
 /* Modifiers to the query */
-typedef enum {
-    p2m_query,              /* Do not populate a PoD entries      */
-    p2m_alloc,              /* Automatically populate PoD entries */
-    p2m_unshare,            /* Break c-o-w sharing; implies alloc */
-} p2m_query_t;
+typedef unsigned int p2m_query_t;
+#define P2M_ALLOC    (1u<<0)   /* Populate PoD and paged-out entries */
+#define P2M_UNSHARE  (1u<<1)   /* Break CoW sharing */
 
 /* We use bitmaps and maks to handle groups of types */
 #define p2m_to_mask(_t) (1UL << (_t))
@@ -330,9 +328,10 @@ static inline mfn_t get_gfn_type(struct 
  * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
  * p2m lock; none of the others can be called with the p2m or paging
  * lock held. */
-#define get_gfn(d, g, t)         get_gfn_type((d), (g), (t), p2m_alloc)
-#define get_gfn_query(d, g, t)   get_gfn_type((d), (g), (t), p2m_query)
-#define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), p2m_unshare)
+#define get_gfn(d, g, t)         get_gfn_type((d), (g), (t), P2M_ALLOC)
+#define get_gfn_query(d, g, t)   get_gfn_type((d), (g), (t), 0)
+#define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \
+                                              P2M_ALLOC | P2M_UNSHARE)
 
 /* Compatibility function exporting the old untyped interface */
 static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
@@ -364,8 +363,7 @@ static inline mfn_t get_gfn_query_unlock
                                            p2m_type_t *t)
 {
     p2m_access_t a;
-    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 
-                                    p2m_query, NULL, 0);
+    return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0);
 }
 
 /* General conversion function from mfn to gfn */

--===============2082719476049360885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2082719476049360885==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 16:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bef-0001C3-NM; Thu, 23 Feb 2012 16:36: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 1S0bee-0001AD-GR
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:36:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330014958!64785675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15172 invoked from network); 23 Feb 2012 16:35:58 -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;
	23 Feb 2012 16:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10902234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 16:36:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 16:36:07 +0000
Message-ID: <1330014965.8557.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jordan Justen <jljusten@gmail.com>
Date: Thu, 23 Feb 2012 16:36:05 +0000
In-Reply-To: <CAFe8ug-7RARVDFvch00Zh3Zu-SaNFgg2eiwcjB2Ma9+GmwwSxQ@mail.gmail.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<CAFe8ug-7RARVDFvch00Zh3Zu-SaNFgg2eiwcjB2Ma9+GmwwSxQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 16:21 +0000, Jordan Justen wrote:
> On Thu, Feb 23, 2012 at 02:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> A way to integrate OVMF build directly into XEN has still be discussed
> >> on the mailing list appropriately.
> >
> > AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> > external dependency would be for us to mirror it on xenbits as a
> > convenience to our users, who don't need to get stuff from multiple
> > places, and as a courtesy to our upstreams, so our users don't consume
> > their resources.
> >
> > I don't much fancy setting the necessary webdav or whatever stuff on
> > xenbits and integrating SVN support into our build system though. What
> > do people think about using git-svn to manage our mirror in git instead?
> > Or better: perhaps OVMF have an official git or hg mirror?
> 
> These are not 100% official, but I have been mirroring to git for over
> a year now:
> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control#Mirrors

More official than anything we would have come up with so I think this
is what we should use.

Thanks Jordan!

> 
> -Jordan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:36:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bef-0001C3-NM; Thu, 23 Feb 2012 16:36: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 1S0bee-0001AD-GR
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:36:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330014958!64785675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15172 invoked from network); 23 Feb 2012 16:35:58 -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;
	23 Feb 2012 16:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10902234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 16:36:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 16:36:07 +0000
Message-ID: <1330014965.8557.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jordan Justen <jljusten@gmail.com>
Date: Thu, 23 Feb 2012 16:36:05 +0000
In-Reply-To: <CAFe8ug-7RARVDFvch00Zh3Zu-SaNFgg2eiwcjB2Ma9+GmwwSxQ@mail.gmail.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<CAFe8ug-7RARVDFvch00Zh3Zu-SaNFgg2eiwcjB2Ma9+GmwwSxQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 16:21 +0000, Jordan Justen wrote:
> On Thu, Feb 23, 2012 at 02:07, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> A way to integrate OVMF build directly into XEN has still be discussed
> >> on the mailing list appropriately.
> >
> > AIUI OVMF is maintained in SVN. Our normal procedure for adding an
> > external dependency would be for us to mirror it on xenbits as a
> > convenience to our users, who don't need to get stuff from multiple
> > places, and as a courtesy to our upstreams, so our users don't consume
> > their resources.
> >
> > I don't much fancy setting the necessary webdav or whatever stuff on
> > xenbits and integrating SVN support into our build system though. What
> > do people think about using git-svn to manage our mirror in git instead?
> > Or better: perhaps OVMF have an official git or hg mirror?
> 
> These are not 100% official, but I have been mirroring to git for over
> a year now:
> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control#Mirrors

More official than anything we would have come up with so I think this
is what we should use.

Thanks Jordan!

> 
> -Jordan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:43:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0blG-0001u8-U0; Thu, 23 Feb 2012 16:43:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0blE-0001tv-Sn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:43:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330015390!16601036!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5701 invoked from network); 23 Feb 2012 16:43:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 16:43:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0bl6-00081l-9m; Thu, 23 Feb 2012 16:43:08 +0000
Date: Thu, 23 Feb 2012 16:43:08 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120223164308.GK25694@ocelot.phlegethon.org>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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

At 16:34 +0000 on 23 Feb (1330014862), Tim Deegan wrote:
> This is v2 of the patch I posted last week, after feedback from Andres. 
> 
> The first four patches are cleanups that should probably happen even
> if the main waitq patch doesn't go in.
> 
> Patch 5 is the waitq patch, updated but largely following the same 
> approach. I'm not suggesting it be applied right now because I know
> at least one path (get_two_gfns()) needs work before it's safe.
> 
> Patch 6 is a follow-up to avoid claiming a slot unnecessarily in 
> p2m_mem_paging_populate(); it's also a good idea even if the main 
> waitq patch doesn't happen but would need to be backported since 
> it only applies on top of those changes.

My apologies for these being attached rather than inline -- my hg email
runes are clearly rusty. :) 

Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:43:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0blG-0001u8-U0; Thu, 23 Feb 2012 16:43:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0blE-0001tv-Sn
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:43:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330015390!16601036!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5701 invoked from network); 23 Feb 2012 16:43:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 16:43:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S0bl6-00081l-9m; Thu, 23 Feb 2012 16:43:08 +0000
Date: Thu, 23 Feb 2012 16:43:08 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120223164308.GK25694@ocelot.phlegethon.org>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, olaf@aepfle.de, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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

At 16:34 +0000 on 23 Feb (1330014862), Tim Deegan wrote:
> This is v2 of the patch I posted last week, after feedback from Andres. 
> 
> The first four patches are cleanups that should probably happen even
> if the main waitq patch doesn't go in.
> 
> Patch 5 is the waitq patch, updated but largely following the same 
> approach. I'm not suggesting it be applied right now because I know
> at least one path (get_two_gfns()) needs work before it's safe.
> 
> Patch 6 is a follow-up to avoid claiming a slot unnecessarily in 
> p2m_mem_paging_populate(); it's also a good idea even if the main 
> waitq patch doesn't happen but would need to be backported since 
> it only applies on top of those changes.

My apologies for these being attached rather than inline -- my hg email
runes are clearly rusty. :) 

Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bo4-00020i-J6; Thu, 23 Feb 2012 16:46:12 +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 1S0bo2-00020Z-Eo
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:46:10 +0000
Received: from [85.158.139.83:51152] by server-11.bemta-5.messagelabs.com id
	01/75-14397-15D664F4; Thu, 23 Feb 2012 16:46:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330015568!15728030!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17450 invoked from network); 23 Feb 2012 16:46:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 16:46:08 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330015568; l=1991;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MSFM4fp6Hi9YDMC0QwttM3RE6IM=;
	b=Sd1u3F2g5RVC5ZT3NWRb5W7z8HKi01kDjWHv9thLBQB+0DZljwlrcrsTjgO9UmmTJjn
	AJWauJzSBmsbGZjPTiJsAlQLW+dkFr6gh7BIs9XXstRJra9cRRxK4IFpW/CFl4YCbOfQf
	JrXrsbBjajgqzrrkTRyJ5ir9MoudgFGMBrU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo29) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u0163ao1NGh3PZ
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 17:46:00 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B412F18635
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 17:45:58 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5bdbdcb03d60a7b58f41306ef39cb988100efbe4
Message-Id: <5bdbdcb03d60a7b58f41.1330015557@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 23 Feb 2012 17:45:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/qemu-xen: remove CFLAGS for qemu build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1330015545 -3600
# Node ID 5bdbdcb03d60a7b58f41306ef39cb988100efbe4
# Parent  56214b978466914c1b9f8adb1158a3217a823e42
tools/qemu-xen: remove CFLAGS for qemu build

Currently qemu-xen gets build with CFLAGS only if CFLAGS was already in
the environment during make invocation. If CFLAGS is in environment then
make will append all of the various flags specified in xen Makefiles,
which is then passed to qemu configure. If CFLAGS is not set, then
configure will use just "-O2 -g" because make does not export its own
CFLAGS variable.

To make qemu-xen build consistent this change removes CFLAGS from the
environment so that only the CFLAGS from qemu configure script will be
used. This matches what is done in kvm.rpm and qemu.rpm where for
example RPM_OPT_FLAGS is not passes as CFLAGS. Otherwise those packages
would not build as well.

Passing makes CFLAGS to configure will lead to build errors:
- xen Makefiles append -std=gnu99, this breaks qemu build due to a bug
  in header file:
fpu/softfloat-specialize.h:107: error: initializer element is not constant
- in 32bit builds, qemus configure script will append -mcpu=i486 in an
  odd way, which leads to unknown gcc cmdline options due to a missing
  space
- xen Makefiles will append -Wall which will expose all sorts of style
  issues in the qemu code
- in one case some of the asm() blocks will not compile with gcc 4.6 in
  openSuSE 12.1

Until upstream qemu has fixed all these issues use no extra CFLAGS to
configure qemu-xen.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 56214b978466 -r 5bdbdcb03d60 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -146,6 +146,7 @@ subdir-all-qemu-xen-dir subdir-install-q
 		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 \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:46:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bo4-00020i-J6; Thu, 23 Feb 2012 16:46:12 +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 1S0bo2-00020Z-Eo
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:46:10 +0000
Received: from [85.158.139.83:51152] by server-11.bemta-5.messagelabs.com id
	01/75-14397-15D664F4; Thu, 23 Feb 2012 16:46:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330015568!15728030!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17450 invoked from network); 23 Feb 2012 16:46:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 16:46:08 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330015568; l=1991;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MSFM4fp6Hi9YDMC0QwttM3RE6IM=;
	b=Sd1u3F2g5RVC5ZT3NWRb5W7z8HKi01kDjWHv9thLBQB+0DZljwlrcrsTjgO9UmmTJjn
	AJWauJzSBmsbGZjPTiJsAlQLW+dkFr6gh7BIs9XXstRJra9cRRxK4IFpW/CFl4YCbOfQf
	JrXrsbBjajgqzrrkTRyJ5ir9MoudgFGMBrU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo29) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u0163ao1NGh3PZ
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 17:46:00 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B412F18635
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 17:45:58 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5bdbdcb03d60a7b58f41306ef39cb988100efbe4
Message-Id: <5bdbdcb03d60a7b58f41.1330015557@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 23 Feb 2012 17:45:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/qemu-xen: remove CFLAGS for qemu build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1330015545 -3600
# Node ID 5bdbdcb03d60a7b58f41306ef39cb988100efbe4
# Parent  56214b978466914c1b9f8adb1158a3217a823e42
tools/qemu-xen: remove CFLAGS for qemu build

Currently qemu-xen gets build with CFLAGS only if CFLAGS was already in
the environment during make invocation. If CFLAGS is in environment then
make will append all of the various flags specified in xen Makefiles,
which is then passed to qemu configure. If CFLAGS is not set, then
configure will use just "-O2 -g" because make does not export its own
CFLAGS variable.

To make qemu-xen build consistent this change removes CFLAGS from the
environment so that only the CFLAGS from qemu configure script will be
used. This matches what is done in kvm.rpm and qemu.rpm where for
example RPM_OPT_FLAGS is not passes as CFLAGS. Otherwise those packages
would not build as well.

Passing makes CFLAGS to configure will lead to build errors:
- xen Makefiles append -std=gnu99, this breaks qemu build due to a bug
  in header file:
fpu/softfloat-specialize.h:107: error: initializer element is not constant
- in 32bit builds, qemus configure script will append -mcpu=i486 in an
  odd way, which leads to unknown gcc cmdline options due to a missing
  space
- xen Makefiles will append -Wall which will expose all sorts of style
  issues in the qemu code
- in one case some of the asm() blocks will not compile with gcc 4.6 in
  openSuSE 12.1

Until upstream qemu has fixed all these issues use no extra CFLAGS to
configure qemu-xen.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 56214b978466 -r 5bdbdcb03d60 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -146,6 +146,7 @@ subdir-all-qemu-xen-dir subdir-install-q
 		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 \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:55:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bwm-0002Ki-C0; Thu, 23 Feb 2012 16:55:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0bwl-0002KJ-0b
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:55:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330016102!14444645!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25105 invoked from network); 23 Feb 2012 16:55:04 -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;
	23 Feb 2012 16:55:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183154571"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:55:02 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:55:01 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0bwW-0001zO-Eo; Thu, 23 Feb 2012 16:54:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:00:53 +0000
Message-ID: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v4 1/2] arm: support fewer LR registers than
	virtual 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

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   95 ++++++++++++++++++++++++++++++++----------
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..2ff7bce 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,50 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+    struct pending_irq *iter, *n;
+
+    spin_lock(&gic.lock);
+
+    if ( list_empty(&gic.lr_pending) )
+    {
+        i = find_first_zero_bit(&gic.lr_mask, sizeof(uint64_t));
+        if (i < sizeof(uint64_t)) {
+            set_bit(i, &gic.lr_mask);
+            gic_set_lr(i, virtual_irq, state, priority);
+            goto out;
+        }
+    }
+
+    n = irq_to_pending(current, virtual_irq);
+    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->lr_link, &iter->lr_link);
+            goto out;
+        }
+    }
+    list_add(&n->lr_link, &gic.lr_pending);
+
+out:
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -431,30 +470,42 @@ void gicv_setup(struct domain *d)
 
 static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    int i, virq;
+    int i = 0, virq;
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
-        if ( eisr & ((uint64_t)1 << i) ) {
-            struct pending_irq *p;
-
-            lr = GICH[GICH_LR + i];
-            virq = lr & GICH_LR_VIRTUAL_MASK;
-            GICH[GICH_LR + i] = 0;
-
-            spin_lock(&current->arch.vgic.lock);
-            p = irq_to_pending(current, virq);
-            if ( p->desc != NULL ) {
-                p->desc->status &= ~IRQ_INPROGRESS;
-                GICC[GICC_DIR] = virq;
-            }
+    while ((i = find_next_bit((const long unsigned int *) &eisr,
+                              sizeof(eisr), i)) < sizeof(eisr)) {
+        struct pending_irq *p;
+
+        spin_lock(&gic.lock);
+        lr = GICH[GICH_LR + i];
+        virq = lr & GICH_LR_VIRTUAL_MASK;
+        GICH[GICH_LR + i] = 0;
+        clear_bit(i, &gic.lr_mask);
+
+        if ( !list_empty(gic.lr_pending.next) ) {
+            p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+            list_del_init(&p->lr_link);
+            set_bit(i, &gic.lr_mask);
+        } else {
             gic_inject_irq_stop();
-            list_del(&p->link);
-            INIT_LIST_HEAD(&p->link);
-            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
-            spin_unlock(&current->arch.vgic.lock);
         }
+        spin_unlock(&gic.lock);
+
+        spin_lock(&current->arch.vgic.lock);
+        p = irq_to_pending(current, virq);
+        if ( p->desc != NULL ) {
+            p->desc->status &= ~IRQ_INPROGRESS;
+            GICC[GICC_DIR] = virq;
+        }
+        list_del(&p->link);
+        INIT_LIST_HEAD(&p->link);
+        cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+        spin_unlock(&current->arch.vgic.lock);
+
+        i++;
     }
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:55:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bwm-0002Ki-C0; Thu, 23 Feb 2012 16:55:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0bwl-0002KJ-0b
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:55:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330016102!14444645!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25105 invoked from network); 23 Feb 2012 16:55:04 -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;
	23 Feb 2012 16:55:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183154571"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:55:02 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:55:01 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0bwW-0001zO-Eo; Thu, 23 Feb 2012 16:54:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:00:53 +0000
Message-ID: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v4 1/2] arm: support fewer LR registers than
	virtual 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

If the vgic needs to inject a virtual irq into the guest, but no free
LR registers are available, add the irq to a list and return.
Whenever an LR register becomes available we add the queued irq to it
and remove it from the list.
We use the gic lock to protect the list and the bitmask.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c           |   95 ++++++++++++++++++++++++++++++++----------
 xen/include/asm-arm/domain.h |    1 +
 2 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index adc10bb..2ff7bce 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -25,6 +25,7 @@
 #include <xen/sched.h>
 #include <xen/errno.h>
 #include <xen/softirq.h>
+#include <xen/list.h>
 #include <asm/p2m.h>
 #include <asm/domain.h>
 
@@ -45,6 +46,8 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
+    uint64_t lr_mask;
+    struct list_head lr_pending;
 } gic;
 
 irq_desc_t irq_desc[NR_IRQS];
@@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    gic.lr_mask = 0ULL;
+    INIT_LIST_HEAD(&gic.lr_pending);
 }
 
 /* Set up the GIC */
@@ -345,16 +350,50 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
     return rc;
 }
 
-void gic_set_guest_irq(unsigned int virtual_irq,
+static inline void gic_set_lr(int lr, unsigned int virtual_irq,
         unsigned int state, unsigned int priority)
 {
-    BUG_ON(virtual_irq > nr_lrs);
-    GICH[GICH_LR + virtual_irq] = state |
+    BUG_ON(lr > nr_lrs);
+    GICH[GICH_LR + lr] = state |
         GICH_LR_MAINTENANCE_IRQ |
         ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
         ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
 }
 
+void gic_set_guest_irq(unsigned int virtual_irq,
+        unsigned int state, unsigned int priority)
+{
+    int i;
+    struct pending_irq *iter, *n;
+
+    spin_lock(&gic.lock);
+
+    if ( list_empty(&gic.lr_pending) )
+    {
+        i = find_first_zero_bit(&gic.lr_mask, sizeof(uint64_t));
+        if (i < sizeof(uint64_t)) {
+            set_bit(i, &gic.lr_mask);
+            gic_set_lr(i, virtual_irq, state, priority);
+            goto out;
+        }
+    }
+
+    n = irq_to_pending(current, virtual_irq);
+    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
+    {
+        if ( iter->priority < priority )
+        {
+            list_add_tail(&n->lr_link, &iter->lr_link);
+            goto out;
+        }
+    }
+    list_add(&n->lr_link, &gic.lr_pending);
+
+out:
+    spin_unlock(&gic.lock);
+    return;
+}
+
 void gic_inject_irq_start(void)
 {
     uint32_t hcr;
@@ -431,30 +470,42 @@ void gicv_setup(struct domain *d)
 
 static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    int i, virq;
+    int i = 0, virq;
     uint32_t lr;
     uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
 
-    for ( i = 0; i < 64; i++ ) {
-        if ( eisr & ((uint64_t)1 << i) ) {
-            struct pending_irq *p;
-
-            lr = GICH[GICH_LR + i];
-            virq = lr & GICH_LR_VIRTUAL_MASK;
-            GICH[GICH_LR + i] = 0;
-
-            spin_lock(&current->arch.vgic.lock);
-            p = irq_to_pending(current, virq);
-            if ( p->desc != NULL ) {
-                p->desc->status &= ~IRQ_INPROGRESS;
-                GICC[GICC_DIR] = virq;
-            }
+    while ((i = find_next_bit((const long unsigned int *) &eisr,
+                              sizeof(eisr), i)) < sizeof(eisr)) {
+        struct pending_irq *p;
+
+        spin_lock(&gic.lock);
+        lr = GICH[GICH_LR + i];
+        virq = lr & GICH_LR_VIRTUAL_MASK;
+        GICH[GICH_LR + i] = 0;
+        clear_bit(i, &gic.lr_mask);
+
+        if ( !list_empty(gic.lr_pending.next) ) {
+            p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
+            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
+            list_del_init(&p->lr_link);
+            set_bit(i, &gic.lr_mask);
+        } else {
             gic_inject_irq_stop();
-            list_del(&p->link);
-            INIT_LIST_HEAD(&p->link);
-            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
-            spin_unlock(&current->arch.vgic.lock);
         }
+        spin_unlock(&gic.lock);
+
+        spin_lock(&current->arch.vgic.lock);
+        p = irq_to_pending(current, virq);
+        if ( p->desc != NULL ) {
+            p->desc->status &= ~IRQ_INPROGRESS;
+            GICC[GICC_DIR] = virq;
+        }
+        list_del(&p->link);
+        INIT_LIST_HEAD(&p->link);
+        cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
+        spin_unlock(&current->arch.vgic.lock);
+
+        i++;
     }
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3372d14..75095ff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -21,6 +21,7 @@ struct pending_irq
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     uint8_t priority;
     struct list_head link;
+    struct list_head lr_link;
 };
 
 struct arch_domain
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:55:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bwl-0002KS-03; Thu, 23 Feb 2012 16:55:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0bwk-0002KI-45
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:55:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330016102!14444645!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25074 invoked from network); 23 Feb 2012 16:55:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:55:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183154570"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:55:02 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:55:01 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0bwW-0001zO-FP; Thu, 23 Feb 2012 16:54:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:00:54 +0000
Message-ID: <1330016454-19752-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v4 2/2] arm: replace list_del and INIT_LIST_HEAD
	with list_del_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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2ff7bce..397a148 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -500,8 +500,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
-        list_del(&p->link);
-        INIT_LIST_HEAD(&p->link);
+        list_del_init(&p->link);
         cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
         spin_unlock(&current->arch.vgic.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 Thu Feb 23 16:55:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0bwl-0002KS-03; Thu, 23 Feb 2012 16:55:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0bwk-0002KI-45
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:55:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330016102!14444645!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25074 invoked from network); 23 Feb 2012 16:55:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 16:55:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183154570"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 11:55:02 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 11:55:01 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0bwW-0001zO-FP; Thu, 23 Feb 2012 16:54:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:00:54 +0000
Message-ID: <1330016454-19752-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v4 2/2] arm: replace list_del and INIT_LIST_HEAD
	with list_del_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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2ff7bce..397a148 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -500,8 +500,7 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
             p->desc->status &= ~IRQ_INPROGRESS;
             GICC[GICC_DIR] = virq;
         }
-        list_del(&p->link);
-        INIT_LIST_HEAD(&p->link);
+        list_del_init(&p->link);
         cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
         spin_unlock(&current->arch.vgic.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 Thu Feb 23 16:58:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c0C-0002br-3n; Thu, 23 Feb 2012 16:58:44 +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 1S0c0A-0002bb-NQ
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:58:42 +0000
Received: from [85.158.139.83:22925] by server-7.bemta-5.messagelabs.com id
	64/ED-16195-240764F4; Thu, 23 Feb 2012 16:58:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330016320!16370259!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNzcz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22706 invoked from network); 23 Feb 2012 16:58:41 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 16:58:41 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Feb 2012 08:58:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="114072284"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 23 Feb 2012 08:58:38 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 24 Feb 2012 00:58:37 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 24 Feb 2012 00:58:35 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <jbeulich@suse.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AQHM8jr7m4MGy1d3TzK01xgwJYdnxZZKoT+Q
Date: Thu, 23 Feb 2012 16:58:34 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
In-Reply-To: <4F46530B020000780007F751@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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, "lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>    default y
>  >
>> config ACPI_PROCESSOR_AGGREGATOR
>> -    tristate "Processor Aggregator"
>> +    bool "Processor Aggregator"
> 
> There must be ways to address whatever strange problem you see without
> making this piece of code non-modular.
> 

Yes, another approach is x86_init approach, defining acpi_pad_ops at x86_init.c and overwritten when xen_start_kernel.
This patch is just a RFC patch, to evaluate which approch is more reasonable :-)

>>    depends on ACPI_PROCESSOR
>>    depends on EXPERIMENTAL
>>    depends on X86
>> +    default n
> 
> This is pointless.

Elaborate more? just a little curious why Kconfig has so many default n.

> 
>>    help
>>      ACPI 4.0 defines processor Aggregator, which enables OS to
>>      perform specific processor configuration and control that
>> applies to all 
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 16:58:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 16:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c0C-0002br-3n; Thu, 23 Feb 2012 16:58:44 +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 1S0c0A-0002bb-NQ
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 16:58:42 +0000
Received: from [85.158.139.83:22925] by server-7.bemta-5.messagelabs.com id
	64/ED-16195-240764F4; Thu, 23 Feb 2012 16:58:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330016320!16370259!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNzcz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22706 invoked from network); 23 Feb 2012 16:58:41 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	23 Feb 2012 16:58:41 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 23 Feb 2012 08:58:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="114072284"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga002.jf.intel.com with ESMTP; 23 Feb 2012 08:58:38 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 24 Feb 2012 00:58:37 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Fri, 24 Feb 2012 00:58:35 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <jbeulich@suse.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AQHM8jr7m4MGy1d3TzK01xgwJYdnxZZKoT+Q
Date: Thu, 23 Feb 2012 16:58:34 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
In-Reply-To: <4F46530B020000780007F751@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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, "lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>    default y
>  >
>> config ACPI_PROCESSOR_AGGREGATOR
>> -    tristate "Processor Aggregator"
>> +    bool "Processor Aggregator"
> 
> There must be ways to address whatever strange problem you see without
> making this piece of code non-modular.
> 

Yes, another approach is x86_init approach, defining acpi_pad_ops at x86_init.c and overwritten when xen_start_kernel.
This patch is just a RFC patch, to evaluate which approch is more reasonable :-)

>>    depends on ACPI_PROCESSOR
>>    depends on EXPERIMENTAL
>>    depends on X86
>> +    default n
> 
> This is pointless.

Elaborate more? just a little curious why Kconfig has so many default n.

> 
>>    help
>>      ACPI 4.0 defines processor Aggregator, which enables OS to
>>      perform specific processor configuration and control that
>> applies to all 
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0c82-0002zI-Le; Thu, 23 Feb 2012 17:06:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c80-0002ym-Qe
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:06:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330016802!14667806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6288 invoked from network); 23 Feb 2012 17:06:42 -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;
	23 Feb 2012 17:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10903308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:06:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:06:42 +0000
Date: Thu, 23 Feb 2012 17:12:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Tim Deegan <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] xen/arm: event channels and shared_info page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series implements support for injecting event channels into
the guest and enables a wider range of hypercalls for ARM guests.

In order to allow more flexibility I modified the hypercall protocol, in
particular the hypercall number is not passed as imm to hvc anymore,
because we might not always know it at compile time.
The hypercall number is now passed on the r12 register.

With this the corresponding Linux patch series applied to both Linux and
Xen, I am able to boot dom0, start xenstored and run basic xl commands,
like "xl list" and "xl uptime".


Stefano Stabellini (5):
      arm: shared_info page allocation and mapping
      arm: implement vcpu_mark_events_pending
      arm: set the default dom0 max_vcpus value to 1 (currently is 0)
      arm: use r12 to pass the hypercall number
      arm: introduce more hypercalls

 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/domain.c           |   19 ++++++++
 xen/arch/arm/domain_build.c     |    2 +-
 xen/arch/arm/dummy.S            |    1 -
 xen/arch/arm/gic.h              |    3 +
 xen/arch/arm/mm.c               |   98 +++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c              |   15 ++++++-
 xen/arch/arm/physdev.c          |   18 +++++++
 xen/arch/arm/traps.c            |   21 +++++---
 xen/include/asm-arm/hypercall.h |    3 +
 xen/include/asm-arm/mm.h        |    4 ++
 xen/include/asm-arm/p2m.h       |    2 +
 12 files changed, 172 insertions(+), 15 deletions(-)


A git branch based on my previous gic and tools patches is available
here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git events-1

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0c82-0002zI-Le; Thu, 23 Feb 2012 17:06:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c80-0002ym-Qe
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:06:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330016802!14667806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6288 invoked from network); 23 Feb 2012 17:06:42 -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;
	23 Feb 2012 17:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10903308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:06:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:06:42 +0000
Date: Thu, 23 Feb 2012 17:12:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Tim Deegan <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] xen/arm: event channels and shared_info page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series implements support for injecting event channels into
the guest and enables a wider range of hypercalls for ARM guests.

In order to allow more flexibility I modified the hypercall protocol, in
particular the hypercall number is not passed as imm to hvc anymore,
because we might not always know it at compile time.
The hypercall number is now passed on the r12 register.

With this the corresponding Linux patch series applied to both Linux and
Xen, I am able to boot dom0, start xenstored and run basic xl commands,
like "xl list" and "xl uptime".


Stefano Stabellini (5):
      arm: shared_info page allocation and mapping
      arm: implement vcpu_mark_events_pending
      arm: set the default dom0 max_vcpus value to 1 (currently is 0)
      arm: use r12 to pass the hypercall number
      arm: introduce more hypercalls

 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/domain.c           |   19 ++++++++
 xen/arch/arm/domain_build.c     |    2 +-
 xen/arch/arm/dummy.S            |    1 -
 xen/arch/arm/gic.h              |    3 +
 xen/arch/arm/mm.c               |   98 +++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c              |   15 ++++++-
 xen/arch/arm/physdev.c          |   18 +++++++
 xen/arch/arm/traps.c            |   21 +++++---
 xen/include/asm-arm/hypercall.h |    3 +
 xen/include/asm-arm/mm.h        |    4 ++
 xen/include/asm-arm/p2m.h       |    2 +
 12 files changed, 172 insertions(+), 15 deletions(-)


A git branch based on my previous gic and tools patches is available
here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git events-1

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0c8x-00034f-HA; Thu, 23 Feb 2012 17:07:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c8w-00033m-6S
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:07:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330016857!12745610!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14607 invoked from network); 23 Feb 2012 17:07:39 -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;
	23 Feb 2012 17:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22385781"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-Kh; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:29 +0000
Message-ID: <1330017212-20066-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 2/5] arm: implement vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
we reserve for Xen usage.
In the future the interrupt used for event injection might be dynamic
and could be written into the device tree.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |   11 +++++++++++
 xen/arch/arm/dummy.S  |    1 -
 xen/arch/arm/gic.h    |    3 +++
 3 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1e5cca5..46edcc6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -272,6 +272,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
 
+void vcpu_mark_events_pending(struct vcpu *v)
+{
+    int already_pending = test_and_set_bit(
+        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
+
+    if ( already_pending )
+        return;
+
+	vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3f2cc4b..93f6f53 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,7 +31,6 @@ DUMMY(arch_vcpu_reset);
 DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
 DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 81c388d..36fdea1 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+/* XXX: write this into the DT */
+#define VGIC_IRQ_EVTCHN_CALLBACK 63
+
 extern int domain_vgic_init(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0c8x-00034f-HA; Thu, 23 Feb 2012 17:07:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c8w-00033m-6S
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:07:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330016857!12745610!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14607 invoked from network); 23 Feb 2012 17:07:39 -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;
	23 Feb 2012 17:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22385781"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-Kh; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:29 +0000
Message-ID: <1330017212-20066-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 2/5] arm: implement vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
we reserve for Xen usage.
In the future the interrupt used for event injection might be dynamic
and could be written into the device tree.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |   11 +++++++++++
 xen/arch/arm/dummy.S  |    1 -
 xen/arch/arm/gic.h    |    3 +++
 3 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1e5cca5..46edcc6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -272,6 +272,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
 
+void vcpu_mark_events_pending(struct vcpu *v)
+{
+    int already_pending = test_and_set_bit(
+        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
+
+    if ( already_pending )
+        return;
+
+	vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3f2cc4b..93f6f53 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,7 +31,6 @@ DUMMY(arch_vcpu_reset);
 DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
 DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 81c388d..36fdea1 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+/* XXX: write this into the DT */
+#define VGIC_IRQ_EVTCHN_CALLBACK 63
+
 extern int domain_vgic_init(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c8y-00034x-UB; Thu, 23 Feb 2012 17:07:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c8w-00033q-WD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:07:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330016857!12745610!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14658 invoked from network); 23 Feb 2012 17:07:40 -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;
	23 Feb 2012 17:07:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22385782"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-K4; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:28 +0000
Message-ID: <1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 1/5] arm: shared_info page allocation and 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

Allocate the shared_info page at domain creation.

Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
XENMAPSPACE_shared_info, so that the guest can map the shared_info page.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    8 ++++
 xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c        |   15 ++++++-
 xen/include/asm-arm/mm.h  |    4 ++
 xen/include/asm-arm/p2m.h |    2 +
 5 files changed, 122 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..1e5cca5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
+    rc = -ENOMEM;
+	if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
+		goto fail;
+
+	clear_page(d->shared_info);
+	share_xen_page_with_guest(
+			virt_to_page(d->shared_info), d, XENSHARE_writable);
+
     d->max_vcpus = 8;
 
     if ( (rc = domain_vgic_init(d)) != 0 )
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a0f39eb..5f4fd6a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,8 +25,11 @@
 #include <xen/mm.h>
 #include <xen/preempt.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <asm/page.h>
 #include <asm/current.h>
+#include <public/memory.h>
+#include <xen/sched.h>
 
 struct domain *dom_xen, *dom_io;
 
@@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
 {
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
 {
+    ASSERT(0);
     return -ENOSYS;
 }
 
-int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
+void share_xen_page_with_guest(struct page_info *page,
+                          struct domain *d, int readonly)
 {
-    ASSERT(0);
-    return -ENOSYS;
+    if ( page_get_owner(page) == d )
+        return;
+
+    spin_lock(&d->page_alloc_lock);
+
+    /* The incremented type count pins as writable or read-only. */
+    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
+    page->u.inuse.type_info |= PGT_validated | 1;
+
+    page_set_owner(page, d);
+    wmb(); /* install valid domain ptr before updating refcnt. */
+    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
+
+    /* Only add to the allocation list if the domain isn't dying. */
+    if ( !d->is_dying )
+    {
+        page->count_info |= PGC_allocated | 1;
+        if ( unlikely(d->xenheap_pages++ == 0) )
+            get_knownalive_domain(d);
+        page_list_add_tail(page, &d->xenpage_list);
+    }
+
+    spin_unlock(&d->page_alloc_lock);
+}
+
+static int xenmem_add_to_physmap_once(
+    struct domain *d,
+    const struct xen_add_to_physmap *xatp)
+{
+    unsigned long mfn = 0;
+    int rc;
+
+    switch ( xatp->space )
+    {
+        case XENMAPSPACE_shared_info:
+            if ( xatp->idx == 0 )
+                mfn = virt_to_mfn(d->shared_info);
+            break;
+        default:
+			return -ENOSYS;
+    }
+
+    domain_lock(d);
+
+    /* Map at new location. */
+    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
+
+    domain_unlock(d);
+
+    return rc;
+}
+
+static int xenmem_add_to_physmap(struct domain *d,
+                                 struct xen_add_to_physmap *xatp)
+{
+    return xenmem_add_to_physmap_once(d, xatp);
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    int rc;
+
+    switch ( op )
+    {
+    case XENMEM_add_to_physmap:
+    {
+        struct xen_add_to_physmap xatp;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap(d, &xatp);
+
+        rcu_unlock_domain(d);
+
+        return rc;
+    }
+
+    default:
+        return -ENOSYS;
+    }
+
+    return 0;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 14614fd..6ee1b5f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
         }
         /* else: third already valid */
 
-        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+        if ( third[third_table_offset(addr)].p2m.valid )
+		{
+			/* p2m entry already present */
+			free_domheap_page(
+					mfn_to_page(third[third_table_offset(addr)].p2m.base));
+		}
 
         /* Allocate a new RAM page and attach */
         if (alloc)
@@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
     return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
 }
 
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+		unsigned long mfn)
+{
+    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
+			                  (gpfn + 1) << PAGE_SHIFT,
+							  mfn << PAGE_SHIFT);
+}
+
 int p2m_alloc_table(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index bfc0f76..56ab9415 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -78,6 +78,10 @@ struct page_info
 #define _PGT_pinned       PG_shift(5)
 #define PGT_pinned        PG_mask(1, 5)
 
+ /* Has this page been validated for use as its current type? */
+#define _PGT_validated    PG_shift(6)
+#define PGT_validated     PG_mask(1, 6)
+
  /* Count of uses of this frame as its current type. */
 #define PGT_count_width   PG_shift(9)
 #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index aec52f7..b1d42a8 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
  * address maddr. */
 int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
                      paddr_t end_gaddr, paddr_t maddr);
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+		unsigned long mfn);
 
 unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c8y-00034x-UB; Thu, 23 Feb 2012 17:07:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c8w-00033q-WD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:07:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330016857!12745610!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14658 invoked from network); 23 Feb 2012 17:07:40 -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;
	23 Feb 2012 17:07:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22385782"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-K4; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:28 +0000
Message-ID: <1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 1/5] arm: shared_info page allocation and 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

Allocate the shared_info page at domain creation.

Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
XENMAPSPACE_shared_info, so that the guest can map the shared_info page.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    8 ++++
 xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c        |   15 ++++++-
 xen/include/asm-arm/mm.h  |    4 ++
 xen/include/asm-arm/p2m.h |    2 +
 5 files changed, 122 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..1e5cca5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
+    rc = -ENOMEM;
+	if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
+		goto fail;
+
+	clear_page(d->shared_info);
+	share_xen_page_with_guest(
+			virt_to_page(d->shared_info), d, XENSHARE_writable);
+
     d->max_vcpus = 8;
 
     if ( (rc = domain_vgic_init(d)) != 0 )
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a0f39eb..5f4fd6a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,8 +25,11 @@
 #include <xen/mm.h>
 #include <xen/preempt.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <asm/page.h>
 #include <asm/current.h>
+#include <public/memory.h>
+#include <xen/sched.h>
 
 struct domain *dom_xen, *dom_io;
 
@@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
 {
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
 {
+    ASSERT(0);
     return -ENOSYS;
 }
 
-int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
+void share_xen_page_with_guest(struct page_info *page,
+                          struct domain *d, int readonly)
 {
-    ASSERT(0);
-    return -ENOSYS;
+    if ( page_get_owner(page) == d )
+        return;
+
+    spin_lock(&d->page_alloc_lock);
+
+    /* The incremented type count pins as writable or read-only. */
+    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
+    page->u.inuse.type_info |= PGT_validated | 1;
+
+    page_set_owner(page, d);
+    wmb(); /* install valid domain ptr before updating refcnt. */
+    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
+
+    /* Only add to the allocation list if the domain isn't dying. */
+    if ( !d->is_dying )
+    {
+        page->count_info |= PGC_allocated | 1;
+        if ( unlikely(d->xenheap_pages++ == 0) )
+            get_knownalive_domain(d);
+        page_list_add_tail(page, &d->xenpage_list);
+    }
+
+    spin_unlock(&d->page_alloc_lock);
+}
+
+static int xenmem_add_to_physmap_once(
+    struct domain *d,
+    const struct xen_add_to_physmap *xatp)
+{
+    unsigned long mfn = 0;
+    int rc;
+
+    switch ( xatp->space )
+    {
+        case XENMAPSPACE_shared_info:
+            if ( xatp->idx == 0 )
+                mfn = virt_to_mfn(d->shared_info);
+            break;
+        default:
+			return -ENOSYS;
+    }
+
+    domain_lock(d);
+
+    /* Map at new location. */
+    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
+
+    domain_unlock(d);
+
+    return rc;
+}
+
+static int xenmem_add_to_physmap(struct domain *d,
+                                 struct xen_add_to_physmap *xatp)
+{
+    return xenmem_add_to_physmap_once(d, xatp);
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    int rc;
+
+    switch ( op )
+    {
+    case XENMEM_add_to_physmap:
+    {
+        struct xen_add_to_physmap xatp;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap(d, &xatp);
+
+        rcu_unlock_domain(d);
+
+        return rc;
+    }
+
+    default:
+        return -ENOSYS;
+    }
+
+    return 0;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 14614fd..6ee1b5f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
         }
         /* else: third already valid */
 
-        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+        if ( third[third_table_offset(addr)].p2m.valid )
+		{
+			/* p2m entry already present */
+			free_domheap_page(
+					mfn_to_page(third[third_table_offset(addr)].p2m.base));
+		}
 
         /* Allocate a new RAM page and attach */
         if (alloc)
@@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
     return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
 }
 
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+		unsigned long mfn)
+{
+    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
+			                  (gpfn + 1) << PAGE_SHIFT,
+							  mfn << PAGE_SHIFT);
+}
+
 int p2m_alloc_table(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index bfc0f76..56ab9415 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -78,6 +78,10 @@ struct page_info
 #define _PGT_pinned       PG_shift(5)
 #define PGT_pinned        PG_mask(1, 5)
 
+ /* Has this page been validated for use as its current type? */
+#define _PGT_validated    PG_shift(6)
+#define PGT_validated     PG_mask(1, 6)
+
  /* Count of uses of this frame as its current type. */
 #define PGT_count_width   PG_shift(9)
 #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index aec52f7..b1d42a8 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
  * address maddr. */
 int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
                      paddr_t end_gaddr, paddr_t maddr);
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+		unsigned long mfn);
 
 unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c8x-00034U-4Q; Thu, 23 Feb 2012 17:07:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c8v-00033f-I7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:07:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330016857!12745610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14568 invoked from network); 23 Feb 2012 17:07:39 -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;
	23 Feb 2012 17:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22385780"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-LI; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:30 +0000
Message-ID: <1330017212-20066-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 3/5] arm: set the default dom0 max_vcpus value
	to 1 (currently is 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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..06ba285 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,7 +9,7 @@
 #include "gic.h"
 #include "kernel.h"
 
-static unsigned int __initdata opt_dom0_max_vcpus;
+static unsigned int __initdata opt_dom0_max_vcpus = 1;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c8x-00034U-4Q; Thu, 23 Feb 2012 17:07:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0c8v-00033f-I7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:07:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330016857!12745610!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14568 invoked from network); 23 Feb 2012 17:07:39 -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;
	23 Feb 2012 17:07:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22385780"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-LI; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:30 +0000
Message-ID: <1330017212-20066-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 3/5] arm: set the default dom0 max_vcpus value
	to 1 (currently is 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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..06ba285 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,7 +9,7 @@
 #include "gic.h"
 #include "kernel.h"
 
-static unsigned int __initdata opt_dom0_max_vcpus;
+static unsigned int __initdata opt_dom0_max_vcpus = 1;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c9o-0003I7-Cw; Thu, 23 Feb 2012 17:08: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 1S0c9m-0003Hb-O4
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:08:38 +0000
Received: from [85.158.139.83:22755] by server-10.bemta-5.messagelabs.com id
	00/81-06263-692764F4; Thu, 23 Feb 2012 17:08:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330016915!5101151!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7422 invoked from network); 23 Feb 2012 17:08:37 -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;
	23 Feb 2012 17:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183158222"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:38 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-Ov; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:32 +0000
Message-ID: <1330017212-20066-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 5/5] arm: introduce more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement xen_version, event_channel_op, memory_op sysctl and physdev_op
hypercalls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/physdev.c          |   18 ++++++++++++++++++
 xen/arch/arm/traps.c            |    5 +++++
 xen/include/asm-arm/hypercall.h |    1 +
 4 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/physdev.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49b64fe..619430c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -14,6 +14,7 @@ obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
+obj-y += physdev.o
 obj-y += setup.o
 obj-y += time.o
 obj-y += smpboot.o
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
new file mode 100644
index 0000000..93c16d1
--- /dev/null
+++ b/xen/arch/arm/physdev.c
@@ -0,0 +1,18 @@
+/******************************************************************************
+ * Arch-specific physdev.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <asm/hypercall.h>
+
+
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+{
+	printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
+	return -ENOSYS;
+}
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44d19ec..b266c5e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -376,6 +376,11 @@ static arm_hypercall_t *arm_hypercall_table[] = {
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
+    HYPERCALL(xen_version),
+    HYPERCALL(event_channel_op),
+    HYPERCALL(memory_op),
+    HYPERCALL(physdev_op),
+    HYPERCALL(sysctl),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index d517542..b91f8b6 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include <public/domctl.h> /* for arch_do_domctl */
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c9o-0003I7-Cw; Thu, 23 Feb 2012 17:08: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 1S0c9m-0003Hb-O4
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:08:38 +0000
Received: from [85.158.139.83:22755] by server-10.bemta-5.messagelabs.com id
	00/81-06263-692764F4; Thu, 23 Feb 2012 17:08:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330016915!5101151!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7422 invoked from network); 23 Feb 2012 17:08:37 -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;
	23 Feb 2012 17:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183158222"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:38 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-Ov; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:32 +0000
Message-ID: <1330017212-20066-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 5/5] arm: introduce more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement xen_version, event_channel_op, memory_op sysctl and physdev_op
hypercalls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/physdev.c          |   18 ++++++++++++++++++
 xen/arch/arm/traps.c            |    5 +++++
 xen/include/asm-arm/hypercall.h |    1 +
 4 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/physdev.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49b64fe..619430c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -14,6 +14,7 @@ obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
+obj-y += physdev.o
 obj-y += setup.o
 obj-y += time.o
 obj-y += smpboot.o
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
new file mode 100644
index 0000000..93c16d1
--- /dev/null
+++ b/xen/arch/arm/physdev.c
@@ -0,0 +1,18 @@
+/******************************************************************************
+ * Arch-specific physdev.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <asm/hypercall.h>
+
+
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+{
+	printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
+	return -ENOSYS;
+}
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44d19ec..b266c5e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -376,6 +376,11 @@ static arm_hypercall_t *arm_hypercall_table[] = {
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
+    HYPERCALL(xen_version),
+    HYPERCALL(event_channel_op),
+    HYPERCALL(memory_op),
+    HYPERCALL(physdev_op),
+    HYPERCALL(sysctl),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index d517542..b91f8b6 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include <public/domctl.h> /* for arch_do_domctl */
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c9o-0003IL-Q2; Thu, 23 Feb 2012 17:08: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 1S0c9n-0003Hs-Ih
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:08:39 +0000
Received: from [85.158.139.83:22799] by server-1.bemta-5.messagelabs.com id
	50/73-28458-692764F4; Thu, 23 Feb 2012 17:08:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330016915!5101151!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7446 invoked from network); 23 Feb 2012 17:08:37 -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;
	23 Feb 2012 17:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183158221"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-N5; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:31 +0000
Message-ID: <1330017212-20066-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 4/5] arm: use r12 to pass the hypercall 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

Use r12 to pass the hypercall number and r0-r4 for the hypercall
arguments as usual.

Use the ISS to pass an hypervisor specific tag.

Remove passing unused registers to arm_hypercall_table: we don't have 6
arguments hypercalls and we never use 64 bit values as hypercall
arguments, 64 bit values are only contained within structs passed as
arguments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/traps.c            |   16 ++++++++--------
 xen/include/asm-arm/hypercall.h |    2 ++
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 395d0af..44d19ec 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -367,7 +367,6 @@ unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 }
 
 typedef unsigned long arm_hypercall_t(
-    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
     unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
 
 #define HYPERCALL(x)                                        \
@@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     local_irq_enable();
 
-    regs->r0 = arm_hypercall_table[iss](regs->r0,
+    if ( iss != XEN_HYPERCALL_TAG  ) {
+        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
+                __LINE__ , iss);
+        return;
+    }
+
+    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,
                              regs->r1,
                              regs->r2,
                              regs->r3,
-                             regs->r4,
-                             regs->r5,
-                             regs->r6,
-                             regs->r7,
-                             regs->r8,
-                             regs->r9);
+                             regs->r4);
 }
 
 static void do_cp15_32(struct cpu_user_regs *regs,
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index e840507..d517542 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -3,6 +3,8 @@
 
 #include <public/domctl.h> /* for arch_do_domctl */
 
+#define XEN_HYPERCALL_TAG   0XEA1
+
 #endif /* __ASM_ARM_HYPERCALL_H__ */
 /*
  * Local variables:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:08:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0c9o-0003IL-Q2; Thu, 23 Feb 2012 17:08: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 1S0c9n-0003Hs-Ih
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:08:39 +0000
Received: from [85.158.139.83:22799] by server-1.bemta-5.messagelabs.com id
	50/73-28458-692764F4; Thu, 23 Feb 2012 17:08:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330016915!5101151!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7446 invoked from network); 23 Feb 2012 17:08:37 -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;
	23 Feb 2012 17:08:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183158221"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:07:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:07:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0c8h-0002A3-N5; Thu, 23 Feb 2012 17:07:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 17:13:31 +0000
Message-ID: <1330017212-20066-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH 4/5] arm: use r12 to pass the hypercall 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

Use r12 to pass the hypercall number and r0-r4 for the hypercall
arguments as usual.

Use the ISS to pass an hypervisor specific tag.

Remove passing unused registers to arm_hypercall_table: we don't have 6
arguments hypercalls and we never use 64 bit values as hypercall
arguments, 64 bit values are only contained within structs passed as
arguments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/traps.c            |   16 ++++++++--------
 xen/include/asm-arm/hypercall.h |    2 ++
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 395d0af..44d19ec 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -367,7 +367,6 @@ unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 }
 
 typedef unsigned long arm_hypercall_t(
-    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
     unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
 
 #define HYPERCALL(x)                                        \
@@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     local_irq_enable();
 
-    regs->r0 = arm_hypercall_table[iss](regs->r0,
+    if ( iss != XEN_HYPERCALL_TAG  ) {
+        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
+                __LINE__ , iss);
+        return;
+    }
+
+    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,
                              regs->r1,
                              regs->r2,
                              regs->r3,
-                             regs->r4,
-                             regs->r5,
-                             regs->r6,
-                             regs->r7,
-                             regs->r8,
-                             regs->r9);
+                             regs->r4);
 }
 
 static void do_cp15_32(struct cpu_user_regs *regs,
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index e840507..d517542 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -3,6 +3,8 @@
 
 #include <public/domctl.h> /* for arch_do_domctl */
 
+#define XEN_HYPERCALL_TAG   0XEA1
+
 #endif /* __ASM_ARM_HYPERCALL_H__ */
 /*
  * Local variables:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cSN-0004Vy-GW; Thu, 23 Feb 2012 17:27:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0cSM-0004Vm-17
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330018063!9510533!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18159 invoked from network); 23 Feb 2012 17:27:43 -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;
	23 Feb 2012 17:27:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10903900"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:27:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 17:27:43 +0000
Message-ID: <1330018061.8557.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 23 Feb 2012 17:27:41 +0000
In-Reply-To: <1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
	<1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 17:13 +0000, Stefano Stabellini wrote:
> Allocate the shared_info page at domain creation.
> 
> Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c     |    8 ++++
>  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/p2m.c        |   15 ++++++-
>  xen/include/asm-arm/mm.h  |    4 ++
>  xen/include/asm-arm/p2m.h |    2 +
>  5 files changed, 122 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0b55934..1e5cca5 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    rc = -ENOMEM;
> +	if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> +		goto fail;
> +
> +	clear_page(d->shared_info);
> +	share_xen_page_with_guest(
> +			virt_to_page(d->shared_info), d, XENSHARE_writable);

You seem to have some hard tabs here.

> +
>      d->max_vcpus = 8;
>  
>      if ( (rc = domain_vgic_init(d)) != 0 )
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index a0f39eb..5f4fd6a 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -25,8 +25,11 @@
>  #include <xen/mm.h>
>  #include <xen/preempt.h>
>  #include <xen/errno.h>
> +#include <xen/guest_access.h>
>  #include <asm/page.h>
>  #include <asm/current.h>
> +#include <public/memory.h>
> +#include <xen/sched.h>
>  
>  struct domain *dom_xen, *dom_io;
>  
> @@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
>  {
>  }
>  
> -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
>  {
> +    ASSERT(0);
>      return -ENOSYS;
>  }
>  
> -int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
> +void share_xen_page_with_guest(struct page_info *page,
> +                          struct domain *d, int readonly)
>  {
> -    ASSERT(0);
> -    return -ENOSYS;
> +    if ( page_get_owner(page) == d )
> +        return;
> +
> +    spin_lock(&d->page_alloc_lock);
> +
> +    /* The incremented type count pins as writable or read-only. */
> +    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
> +    page->u.inuse.type_info |= PGT_validated | 1;
> +
> +    page_set_owner(page, d);
> +    wmb(); /* install valid domain ptr before updating refcnt. */
> +    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
> +
> +    /* Only add to the allocation list if the domain isn't dying. */
> +    if ( !d->is_dying )
> +    {
> +        page->count_info |= PGC_allocated | 1;
> +        if ( unlikely(d->xenheap_pages++ == 0) )
> +            get_knownalive_domain(d);
> +        page_list_add_tail(page, &d->xenpage_list);
> +    }
> +
> +    spin_unlock(&d->page_alloc_lock);
> +}
> +
> +static int xenmem_add_to_physmap_once(
> +    struct domain *d,
> +    const struct xen_add_to_physmap *xatp)
> +{
> +    unsigned long mfn = 0;
> +    int rc;
> +
> +    switch ( xatp->space )
> +    {
> +        case XENMAPSPACE_shared_info:
> +            if ( xatp->idx == 0 )
> +                mfn = virt_to_mfn(d->shared_info);
> +            break;
> +        default:
> +			return -ENOSYS;

Another w/s snafu.

> +    }
> +
> +    domain_lock(d);
> +
> +    /* Map at new location. */
> +    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
> +
> +    domain_unlock(d);
> +
> +    return rc;
> +}
> +
> +static int xenmem_add_to_physmap(struct domain *d,
> +                                 struct xen_add_to_physmap *xatp)
> +{
> +    return xenmem_add_to_physmap_once(d, xatp);
>  }
>  
> +long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +{
> +    int rc;
> +
> +    switch ( op )
> +    {
> +    case XENMEM_add_to_physmap:
> +    {
> +        struct xen_add_to_physmap xatp;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap(d, &xatp);
> +
> +        rcu_unlock_domain(d);
> +
> +        return rc;
> +    }
> +
> +    default:
> +        return -ENOSYS;
> +    }
> +
> +    return 0;
> +}
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 14614fd..6ee1b5f 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
>          }
>          /* else: third already valid */
>  
> -        BUG_ON(third[third_table_offset(addr)].p2m.valid);
> +        if ( third[third_table_offset(addr)].p2m.valid )
> +		{
> +			/* p2m entry already present */
> +			free_domheap_page(
> +					mfn_to_page(third[third_table_offset(addr)].p2m.base));
> +		}

Guess what ;)

>  
>          /* Allocate a new RAM page and attach */
>          if (alloc)
> @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
>      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
>  }
>  
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +		unsigned long mfn)
> +{
> +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> +			                  (gpfn + 1) << PAGE_SHIFT,
> +							  mfn << PAGE_SHIFT);

Not sure if this is a hardspace issue or just a strange way of laying it
out?

> +}
> +
>  int p2m_alloc_table(struct domain *d)
>  {
>      struct p2m_domain *p2m = &d->arch.p2m;
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index bfc0f76..56ab9415 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -78,6 +78,10 @@ struct page_info
>  #define _PGT_pinned       PG_shift(5)
>  #define PGT_pinned        PG_mask(1, 5)
>  
> + /* Has this page been validated for use as its current type? */
> +#define _PGT_validated    PG_shift(6)
> +#define PGT_validated     PG_mask(1, 6)
> +
>   /* Count of uses of this frame as its current type. */
>  #define PGT_count_width   PG_shift(9)
>  #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index aec52f7..b1d42a8 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>   * address maddr. */
>  int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
>                       paddr_t end_gaddr, paddr_t maddr);
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +		unsigned long mfn);
>  
>  unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:28:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cSN-0004Vy-GW; Thu, 23 Feb 2012 17:27:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0cSM-0004Vm-17
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330018063!9510533!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18159 invoked from network); 23 Feb 2012 17:27:43 -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;
	23 Feb 2012 17:27:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10903900"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:27:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 17:27:43 +0000
Message-ID: <1330018061.8557.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 23 Feb 2012 17:27:41 +0000
In-Reply-To: <1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
	<1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 17:13 +0000, Stefano Stabellini wrote:
> Allocate the shared_info page at domain creation.
> 
> Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c     |    8 ++++
>  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/p2m.c        |   15 ++++++-
>  xen/include/asm-arm/mm.h  |    4 ++
>  xen/include/asm-arm/p2m.h |    2 +
>  5 files changed, 122 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0b55934..1e5cca5 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    rc = -ENOMEM;
> +	if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> +		goto fail;
> +
> +	clear_page(d->shared_info);
> +	share_xen_page_with_guest(
> +			virt_to_page(d->shared_info), d, XENSHARE_writable);

You seem to have some hard tabs here.

> +
>      d->max_vcpus = 8;
>  
>      if ( (rc = domain_vgic_init(d)) != 0 )
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index a0f39eb..5f4fd6a 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -25,8 +25,11 @@
>  #include <xen/mm.h>
>  #include <xen/preempt.h>
>  #include <xen/errno.h>
> +#include <xen/guest_access.h>
>  #include <asm/page.h>
>  #include <asm/current.h>
> +#include <public/memory.h>
> +#include <xen/sched.h>
>  
>  struct domain *dom_xen, *dom_io;
>  
> @@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
>  {
>  }
>  
> -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
>  {
> +    ASSERT(0);
>      return -ENOSYS;
>  }
>  
> -int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
> +void share_xen_page_with_guest(struct page_info *page,
> +                          struct domain *d, int readonly)
>  {
> -    ASSERT(0);
> -    return -ENOSYS;
> +    if ( page_get_owner(page) == d )
> +        return;
> +
> +    spin_lock(&d->page_alloc_lock);
> +
> +    /* The incremented type count pins as writable or read-only. */
> +    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
> +    page->u.inuse.type_info |= PGT_validated | 1;
> +
> +    page_set_owner(page, d);
> +    wmb(); /* install valid domain ptr before updating refcnt. */
> +    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
> +
> +    /* Only add to the allocation list if the domain isn't dying. */
> +    if ( !d->is_dying )
> +    {
> +        page->count_info |= PGC_allocated | 1;
> +        if ( unlikely(d->xenheap_pages++ == 0) )
> +            get_knownalive_domain(d);
> +        page_list_add_tail(page, &d->xenpage_list);
> +    }
> +
> +    spin_unlock(&d->page_alloc_lock);
> +}
> +
> +static int xenmem_add_to_physmap_once(
> +    struct domain *d,
> +    const struct xen_add_to_physmap *xatp)
> +{
> +    unsigned long mfn = 0;
> +    int rc;
> +
> +    switch ( xatp->space )
> +    {
> +        case XENMAPSPACE_shared_info:
> +            if ( xatp->idx == 0 )
> +                mfn = virt_to_mfn(d->shared_info);
> +            break;
> +        default:
> +			return -ENOSYS;

Another w/s snafu.

> +    }
> +
> +    domain_lock(d);
> +
> +    /* Map at new location. */
> +    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
> +
> +    domain_unlock(d);
> +
> +    return rc;
> +}
> +
> +static int xenmem_add_to_physmap(struct domain *d,
> +                                 struct xen_add_to_physmap *xatp)
> +{
> +    return xenmem_add_to_physmap_once(d, xatp);
>  }
>  
> +long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +{
> +    int rc;
> +
> +    switch ( op )
> +    {
> +    case XENMEM_add_to_physmap:
> +    {
> +        struct xen_add_to_physmap xatp;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap(d, &xatp);
> +
> +        rcu_unlock_domain(d);
> +
> +        return rc;
> +    }
> +
> +    default:
> +        return -ENOSYS;
> +    }
> +
> +    return 0;
> +}
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 14614fd..6ee1b5f 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
>          }
>          /* else: third already valid */
>  
> -        BUG_ON(third[third_table_offset(addr)].p2m.valid);
> +        if ( third[third_table_offset(addr)].p2m.valid )
> +		{
> +			/* p2m entry already present */
> +			free_domheap_page(
> +					mfn_to_page(third[third_table_offset(addr)].p2m.base));
> +		}

Guess what ;)

>  
>          /* Allocate a new RAM page and attach */
>          if (alloc)
> @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
>      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
>  }
>  
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +		unsigned long mfn)
> +{
> +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> +			                  (gpfn + 1) << PAGE_SHIFT,
> +							  mfn << PAGE_SHIFT);

Not sure if this is a hardspace issue or just a strange way of laying it
out?

> +}
> +
>  int p2m_alloc_table(struct domain *d)
>  {
>      struct p2m_domain *p2m = &d->arch.p2m;
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index bfc0f76..56ab9415 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -78,6 +78,10 @@ struct page_info
>  #define _PGT_pinned       PG_shift(5)
>  #define PGT_pinned        PG_mask(1, 5)
>  
> + /* Has this page been validated for use as its current type? */
> +#define _PGT_validated    PG_shift(6)
> +#define PGT_validated     PG_mask(1, 6)
> +
>   /* Count of uses of this frame as its current type. */
>  #define PGT_count_width   PG_shift(9)
>  #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index aec52f7..b1d42a8 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>   * address maddr. */
>  int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
>                       paddr_t end_gaddr, paddr_t maddr);
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +		unsigned long mfn);
>  
>  unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cUy-0004go-Qk; Thu, 23 Feb 2012 17:30:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0cUx-0004g9-5W
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:30:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330018223!15536821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16549 invoked from network); 23 Feb 2012 17:30:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387116"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:30:02 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:30:01 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1S0cUT-0002S1-HO;
	Thu, 23 Feb 2012 17:30:01 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
In-Reply-To: <4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org>
Date: Thu, 23 Feb 2012 17:30:02 +0000
Message-ID: <1330018202.19361.82.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 16:22 +0000, Andres Lagar-Cavilla wrote:
> I think it's a lot to process :) I will issue a few statements in no
> particular order.
> 
> How about we have a BoF/powwow on this at the Hackathon?
> 
> For the sake of expediency we need a simple UI, with two/three obvious
> commands doing things, and then a full arsenal of knob-ery as a separate
> entity. I agree with the general sentiment here.
> 
> I actually intended footprint to convey a human-understandable name for
> what paging is doing. I think if we try to combine under 'footprint' all
> possible means of trimming pages from the guest, *in libxl*, we'll end up
> pleasing nobody.
> 
> Taking a few steps back, Olaf's purpose is to be able to control the *one*
> knob xenpaging has with its linear sweep policy via libxl. (I guess you
> have a second knob, throttling how fast you try to page in things back)
> 
> Somebody has to ask this: are you really sure you want to bake policies
> into libxl? What will toolstacks be left with? I think it's great to wire
> some straightforward control of xenpaging into libxl -- as straightforward
> control of the balloon and PoD is already in place. But when the
> conversation starts escalating, the complexity of libxl grows
> exponentially, and I get all kinds of shivers.
> 
> The original stated goal of libxl is to be a common substrate for
> toolstacks. Let toolstacks decide if they want fancier paging or Marxist
> sharing, or what not :)

Just a quick comment for clarification: We're talking now about xl, not
libxl.  Libxl, as you say, will expose all the knobs to the toolstack,
and allow the toolstack to do what it wishes.  But a large number of our
customers will be using xl, which is, in fact, a toolstack built on
libxl. :-)  It's the interface to that toolstack we're discussing.

I'll answer more in a bit.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cUy-0004go-Qk; Thu, 23 Feb 2012 17:30:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1S0cUx-0004g9-5W
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:30:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330018223!15536821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16549 invoked from network); 23 Feb 2012 17:30:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387116"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:30:02 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:30:01 -0500
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@citrix.com>)	id 1S0cUT-0002S1-HO;
	Thu, 23 Feb 2012 17:30:01 +0000
From: George Dunlap <george.dunlap@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
In-Reply-To: <4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org>
Date: Thu, 23 Feb 2012 17:30:02 +0000
Message-ID: <1330018202.19361.82.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 16:22 +0000, Andres Lagar-Cavilla wrote:
> I think it's a lot to process :) I will issue a few statements in no
> particular order.
> 
> How about we have a BoF/powwow on this at the Hackathon?
> 
> For the sake of expediency we need a simple UI, with two/three obvious
> commands doing things, and then a full arsenal of knob-ery as a separate
> entity. I agree with the general sentiment here.
> 
> I actually intended footprint to convey a human-understandable name for
> what paging is doing. I think if we try to combine under 'footprint' all
> possible means of trimming pages from the guest, *in libxl*, we'll end up
> pleasing nobody.
> 
> Taking a few steps back, Olaf's purpose is to be able to control the *one*
> knob xenpaging has with its linear sweep policy via libxl. (I guess you
> have a second knob, throttling how fast you try to page in things back)
> 
> Somebody has to ask this: are you really sure you want to bake policies
> into libxl? What will toolstacks be left with? I think it's great to wire
> some straightforward control of xenpaging into libxl -- as straightforward
> control of the balloon and PoD is already in place. But when the
> conversation starts escalating, the complexity of libxl grows
> exponentially, and I get all kinds of shivers.
> 
> The original stated goal of libxl is to be a common substrate for
> toolstacks. Let toolstacks decide if they want fancier paging or Marxist
> sharing, or what not :)

Just a quick comment for clarification: We're talking now about xl, not
libxl.  Libxl, as you say, will expose all the knobs to the toolstack,
and allow the toolstack to do what it wishes.  But a large number of our
customers will be using xl, which is, in fact, a toolstack built on
libxl. :-)  It's the interface to that toolstack we're discussing.

I'll answer more in a bit.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:33:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cXV-000525-CI; Thu, 23 Feb 2012 17:33:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jljusten@gmail.com>) id 1S0cXU-00051F-4z
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:33:08 +0000
X-Env-Sender: jljusten@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330018380!15590834!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5764 invoked from network); 23 Feb 2012 17:33:02 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:33:02 -0000
Received: by ggnu1 with SMTP id u1so10229975ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 09:33:00 -0800 (PST)
Received-SPF: pass (google.com: domain of jljusten@gmail.com designates
	10.236.77.166 as permitted sender) client-ip=10.236.77.166; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jljusten@gmail.com
	designates 10.236.77.166 as permitted sender)
	smtp.mail=jljusten@gmail.com;
	dkim=pass header.i=jljusten@gmail.com
Received: from mr.google.com ([10.236.77.166])
	by 10.236.77.166 with SMTP id d26mr4646597yhe.19.1330018380841
	(num_hops = 1); Thu, 23 Feb 2012 09:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=3ExSXWtTFEqJqVeF/4/FBS0aou6JiyVF0MOBklrJMqw=;
	b=YoKtxPXfcRRHwVjj1UzESy7ezhxLsUd9j+H/TwaDRUcmxNEsM7p0gLNNirMnBJbSKU
	6yjxXxFqsp2DasbxsliAMJ/dgnQ8aa4N+gRq907ZslfrM22/fY77F+Se8AP0c0o+8HFs
	wsjoDkvI/MQUoBf+CDYA/wyQZcsO9eoAKJ2sQ=
MIME-Version: 1.0
Received: by 10.236.77.166 with SMTP id d26mr3743302yhe.19.1330018380794; Thu,
	23 Feb 2012 09:33:00 -0800 (PST)
Received: by 10.147.38.20 with HTTP; Thu, 23 Feb 2012 09:33:00 -0800 (PST)
In-Reply-To: <1330011462.8557.95.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
Date: Thu, 23 Feb 2012 09:33:00 -0800
Message-ID: <CAFe8ug_daC_dKDTr=g0U8CVw_Y67rKyUEoLLUkczSZgE4VicLA@mail.gmail.com>
From: Jordan Justen <jljusten@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 07:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
>> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>> >On 23/02/12 10:07, Ian Campbell wrote:
>> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> >> Can you confirm that you need an OVMF which matches the OS bit-width you
>> >> are installing. i..e that there is no support for booting a 32 bit EFI
>> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>> >
>> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could
>> >possibly work.
>>
>> Native EFI requires bit-matched OS loaders,
>
> Is that a shortcoming of EFI generally or just this implementation?

This is basically built into the design of UEFI.  The issue is that
the firmware boot/runtime calls are only available for the native
architecture.

If the OS or loader had support for changing to the native
architecture before calling these services, it can run in another
mode.

> Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> of loading a 32 bit OS?

I don't think people often update their firmware to switch modes.  In
fact, I think in most cases they don't have that option.  For example,
most desktop/server systems with UEFI support will likely only support
UEFI X64.

The loader or OS could have special support for running under this
environment.  It would just need to change to the proper CPU mode
before calling the firmware runtime services.

In the case of UEFI Linux and Windows x86, I think they only support
calling UEFI IA32.  In the case of UEFI Linux and Windows x86-64, I
think they only support calling UEFI X64.

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:33:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cXV-000525-CI; Thu, 23 Feb 2012 17:33:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jljusten@gmail.com>) id 1S0cXU-00051F-4z
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:33:08 +0000
X-Env-Sender: jljusten@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330018380!15590834!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5764 invoked from network); 23 Feb 2012 17:33:02 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:33:02 -0000
Received: by ggnu1 with SMTP id u1so10229975ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 09:33:00 -0800 (PST)
Received-SPF: pass (google.com: domain of jljusten@gmail.com designates
	10.236.77.166 as permitted sender) client-ip=10.236.77.166; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of jljusten@gmail.com
	designates 10.236.77.166 as permitted sender)
	smtp.mail=jljusten@gmail.com;
	dkim=pass header.i=jljusten@gmail.com
Received: from mr.google.com ([10.236.77.166])
	by 10.236.77.166 with SMTP id d26mr4646597yhe.19.1330018380841
	(num_hops = 1); Thu, 23 Feb 2012 09:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=3ExSXWtTFEqJqVeF/4/FBS0aou6JiyVF0MOBklrJMqw=;
	b=YoKtxPXfcRRHwVjj1UzESy7ezhxLsUd9j+H/TwaDRUcmxNEsM7p0gLNNirMnBJbSKU
	6yjxXxFqsp2DasbxsliAMJ/dgnQ8aa4N+gRq907ZslfrM22/fY77F+Se8AP0c0o+8HFs
	wsjoDkvI/MQUoBf+CDYA/wyQZcsO9eoAKJ2sQ=
MIME-Version: 1.0
Received: by 10.236.77.166 with SMTP id d26mr3743302yhe.19.1330018380794; Thu,
	23 Feb 2012 09:33:00 -0800 (PST)
Received: by 10.147.38.20 with HTTP; Thu, 23 Feb 2012 09:33:00 -0800 (PST)
In-Reply-To: <1330011462.8557.95.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
Date: Thu, 23 Feb 2012 09:33:00 -0800
Message-ID: <CAFe8ug_daC_dKDTr=g0U8CVw_Y67rKyUEoLLUkczSZgE4VicLA@mail.gmail.com>
From: Jordan Justen <jljusten@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 07:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
>> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>> >On 23/02/12 10:07, Ian Campbell wrote:
>> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> >> Can you confirm that you need an OVMF which matches the OS bit-width you
>> >> are installing. i..e that there is no support for booting a 32 bit EFI
>> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>> >
>> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could
>> >possibly work.
>>
>> Native EFI requires bit-matched OS loaders,
>
> Is that a shortcoming of EFI generally or just this implementation?

This is basically built into the design of UEFI.  The issue is that
the firmware boot/runtime calls are only available for the native
architecture.

If the OS or loader had support for changing to the native
architecture before calling these services, it can run in another
mode.

> Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> of loading a 32 bit OS?

I don't think people often update their firmware to switch modes.  In
fact, I think in most cases they don't have that option.  For example,
most desktop/server systems with UEFI support will likely only support
UEFI X64.

The loader or OS could have special support for running under this
environment.  It would just need to change to the proper CPU mode
before calling the firmware runtime services.

In the case of UEFI Linux and Windows x86, I think they only support
calling UEFI IA32.  In the case of UEFI Linux and Windows x86-64, I
think they only support calling UEFI X64.

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cZa-0005Go-UM; Thu, 23 Feb 2012 17:35: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 1S0cZa-0005GL-14
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:35:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330018438!62650637!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5400 invoked from network); 23 Feb 2012 17:33:59 -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; 23 Feb 2012 17:33:59 -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 q1NHZ8NN011424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 17:35:09 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
	q1NHZ7oe025213
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 17:35:08 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1NHZ7XW014030; Thu, 23 Feb 2012 11:35:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 09:35:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C21814171C; Thu, 23 Feb 2012 12:31:46 -0500 (EST)
Date: Thu, 23 Feb 2012 12:31:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120223173146.GA22922@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120223141827.GC23963@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F4678CD.0102,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
> > Hello,
> > 
> > I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
> > integrated GPU) freezing at resume from S3 sleep... It seems like a
> > Xen-related problems, as a similar kernel to what we use in Dom0
> > (2.6.38+xenlinux), when run on baremetal shows no signs of problems at
> > suspend/resume. Also I cannot find any problems reported on the internet
> > with people having problems here.
> > 
> > Unfortunately the only COM port on ExpressCard I have, presents itself
> > as a USB device, and so I cannot really debug this issue via console.
> > The /var/log/pm-suspend also doesn't reveal anything useful (after I
> > reboot, that is).
> > 
> > Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> > to approach debugging it?
> > 
> > I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
> > patches, and the i915 for the graphics. (Unfortunately I cannot just
> > boot the same Dom0 kernel without Xen, as the GRUB complains about
> > executable being unrecognized -- probably some problem with wrong
> > compression algo).
> > 
> > I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
> > -- in this case it's even worse, as the system hangs at suspend and
> > never enters S3 :/
> 
> Right. You need some patches for that in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
> to make that work.

What I meant to say - please try it out with those patches. It might that you
are hitting on one of the Intel bugs of the video adapter that I think
are mostly fixed in the upstream kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cZa-0005Go-UM; Thu, 23 Feb 2012 17:35: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 1S0cZa-0005GL-14
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:35:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330018438!62650637!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5400 invoked from network); 23 Feb 2012 17:33:59 -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; 23 Feb 2012 17:33:59 -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 q1NHZ8NN011424
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 17:35:09 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
	q1NHZ7oe025213
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 17:35:08 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1NHZ7XW014030; Thu, 23 Feb 2012 11:35:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 09:35:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C21814171C; Thu, 23 Feb 2012 12:31:46 -0500 (EST)
Date: Thu, 23 Feb 2012 12:31:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120223173146.GA22922@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120223141827.GC23963@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F4678CD.0102,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
> > Hello,
> > 
> > I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
> > integrated GPU) freezing at resume from S3 sleep... It seems like a
> > Xen-related problems, as a similar kernel to what we use in Dom0
> > (2.6.38+xenlinux), when run on baremetal shows no signs of problems at
> > suspend/resume. Also I cannot find any problems reported on the internet
> > with people having problems here.
> > 
> > Unfortunately the only COM port on ExpressCard I have, presents itself
> > as a USB device, and so I cannot really debug this issue via console.
> > The /var/log/pm-suspend also doesn't reveal anything useful (after I
> > reboot, that is).
> > 
> > Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> > to approach debugging it?
> > 
> > I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
> > patches, and the i915 for the graphics. (Unfortunately I cannot just
> > boot the same Dom0 kernel without Xen, as the GRUB complains about
> > executable being unrecognized -- probably some problem with wrong
> > compression algo).
> > 
> > I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
> > -- in this case it's even worse, as the system hangs at suspend and
> > never enters S3 :/
> 
> Right. You need some patches for that in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
> to make that work.

What I meant to say - please try it out with those patches. It might that you
are hitting on one of the Intel bugs of the video adapter that I think
are mostly fixed in the upstream kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:35:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:35:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cZq-0005Ih-As; Thu, 23 Feb 2012 17:35: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 1S0cZo-0005I7-CK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:35:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330018395!49994636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28751 invoked from network); 23 Feb 2012 17: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;
	23 Feb 2012 17:33:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10904157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:35:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0cZl-0004pU-Pp;
	Thu, 23 Feb 2012 17:35:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0cZl-00047a-KE;
	Thu, 23 Feb 2012 17:35:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12032-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 17:35:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12032: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12032 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12032/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:35:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:35:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cZq-0005Ih-As; Thu, 23 Feb 2012 17:35: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 1S0cZo-0005I7-CK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:35:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330018395!49994636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28751 invoked from network); 23 Feb 2012 17: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;
	23 Feb 2012 17:33:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10904157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:35:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0cZl-0004pU-Pp;
	Thu, 23 Feb 2012 17:35:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0cZl-00047a-KE;
	Thu, 23 Feb 2012 17:35:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12032-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 17:35:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12032: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12032 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12032/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:37:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cbA-0005Tw-2e; Thu, 23 Feb 2012 17:36:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0cb9-0005TV-4G
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 17:36:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330018607!13017278!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13589 invoked from network); 23 Feb 2012 17:36:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 17:36:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330018607; l=653;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TVo2+OmFyUpD5qT4Zpzp1X8VQUU=;
	b=bV2bKEmJG56pSsxT+FaxdPNQvaZ4yb+2rwv00aEgGUV+oL0dHUnXmltJcb9yggR4n0p
	KItu2lFeQ4U6DypYM7lQwFvAxda/16eQcxfG96SOmXB4jm4MfIt4OBYQUbLw6tPcD69BF
	M9/2xIP9Fzgl9obLlJl1EwQiOpRCWJ+AL3k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo6) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02d53o1NGvdcH ;
	Thu, 23 Feb 2012 18:36:20 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1166E18638; Thu, 23 Feb 2012 18:36:17 +0100 (CET)
Date: Thu, 23 Feb 2012 18:36:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20120223173617.GA19213@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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 Tue, Feb 21, Roger Pau Monne wrote:

> -${PYTHON} -c '
> -import sys
> -sys.exit(sys.version_info[0] < 2 or sys.version_info[1] < 3)
> -' || fail "need python version >= 2.3"

> +`$PYTHON -c 'import sys; exit(eval("sys.version_info < ($1, $2)"))'`


Old python can not handle that new syntax:

 $ python
Python 2.4.2 (#1, Feb 16 2011, 12:49:02)
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> exit(eval("sys.version_info < (2, 3)"))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable
>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:37:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cbA-0005Tw-2e; Thu, 23 Feb 2012 17:36:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0cb9-0005TV-4G
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 17:36:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330018607!13017278!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDUzNjc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13589 invoked from network); 23 Feb 2012 17:36:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 17:36:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330018607; l=653;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TVo2+OmFyUpD5qT4Zpzp1X8VQUU=;
	b=bV2bKEmJG56pSsxT+FaxdPNQvaZ4yb+2rwv00aEgGUV+oL0dHUnXmltJcb9yggR4n0p
	KItu2lFeQ4U6DypYM7lQwFvAxda/16eQcxfG96SOmXB4jm4MfIt4OBYQUbLw6tPcD69BF
	M9/2xIP9Fzgl9obLlJl1EwQiOpRCWJ+AL3k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6g8=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-0.vodafone-net.de [80.226.24.0])
	by smtp.strato.de (jimi mo6) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02d53o1NGvdcH ;
	Thu, 23 Feb 2012 18:36:20 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1166E18638; Thu, 23 Feb 2012 18:36:17 +0100 (CET)
Date: Thu, 23 Feb 2012 18:36:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Message-ID: <20120223173617.GA19213@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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 Tue, Feb 21, Roger Pau Monne wrote:

> -${PYTHON} -c '
> -import sys
> -sys.exit(sys.version_info[0] < 2 or sys.version_info[1] < 3)
> -' || fail "need python version >= 2.3"

> +`$PYTHON -c 'import sys; exit(eval("sys.version_info < ($1, $2)"))'`


Old python can not handle that new syntax:

 $ python
Python 2.4.2 (#1, Feb 16 2011, 12:49:02)
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> exit(eval("sys.version_info < (2, 3)"))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable
>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:39:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cdq-0005km-L4; Thu, 23 Feb 2012 17:39:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1S0cdp-0005kD-8z
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:39:41 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330018774!9512061!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDQyNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19991 invoked from network); 23 Feb 2012 17:39:35 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 17:39:35 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 222B120DE6
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 12:39:34 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute4.internal (MEProxy); Thu, 23 Feb 2012 12:39:34 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=JA
	BTFTc7xVKW50lqaVMa7BFnES0=; b=CAc7am2zfiG8zoHMhYoXUhKBAZyxHu9URD
	7+W4UEGc4ItZnYbEL4tVrRHZeh9giHAH57uzxSLEwB3Ddg9d2I2hJ0wTA8xYRH3E
	kgWAgrEsjjamUAXRhWw1bl+Rh2eKF2yysGShuMJXFfK8GyYN4/Sy4e2NEIXA6rN2
	WK4bBW2uw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=JABT
	FTc7xVKW50lqaVMa7BFnES0=; b=j6j+aYuwvvW8cKDX0sjau9Kpfi5tAudk4JDV
	FxC9Bxz+5B0+qr4UQZJnuNE7d2gysutMEcg5umTJGzjTfhWH42oLNk05rYnZUzyB
	60IcWdEp6xUv40/B7pGxwSI/jvo85hAAX7gyRHoOuVI5WDqXKa+KPuGWR2EcFT3M
	MZpuIh4=
X-Sasl-enc: 2A8J3ntdvm7ptyu+tee/9F8u6envTXR/R50oh9Qwm9+K 1330018773
Received: from [10.137.2.12] (aavp195.neoplus.adsl.tpnet.pl [83.6.49.195])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 5CBE18E0125;
	Thu, 23 Feb 2012 12:39:33 -0500 (EST)
Message-ID: <4F4679D1.3000806@invisiblethingslab.com>
Date: Thu, 23 Feb 2012 18:39:29 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
In-Reply-To: <20120223173146.GA22922@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Marek Marczykowski <marmarek@mimuw.edu.pl>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5388585366799199108=="
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)
--===============5388585366799199108==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig3C35723086FD0948F9E33A51"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3C35723086FD0948F9E33A51
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/23/12 18:31, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
>>> Hello,
>>>
>>> I've been trying to resolve the issue of my T420s (Core i5 2540M, Int=
el
>>> integrated GPU) freezing at resume from S3 sleep... It seems like a
>>> Xen-related problems, as a similar kernel to what we use in Dom0
>>> (2.6.38+xenlinux), when run on baremetal shows no signs of problems a=
t
>>> suspend/resume. Also I cannot find any problems reported on the inter=
net
>>> with people having problems here.
>>>
>>> Unfortunately the only COM port on ExpressCard I have, presents itsel=
f
>>> as a USB device, and so I cannot really debug this issue via console.=

>>> The /var/log/pm-suspend also doesn't reveal anything useful (after I
>>> reboot, that is).
>>>
>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises h=
ow
>>> to approach debugging it?
>>>
>>> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlin=
ux
>>> patches, and the i915 for the graphics. (Unfortunately I cannot just
>>> boot the same Dom0 kernel without Xen, as the GRUB complains about
>>> executable being unrecognized -- probably some problem with wrong
>>> compression algo).
>>>
>>> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kerne=
l)
>>> -- in this case it's even worse, as the system hangs at suspend and
>>> never enters S3 :/
>>
>> Right. You need some patches for that in git://git.kernel.org/pub/scm/=
linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
>> to make that work.
>=20
> What I meant to say - please try it out with those patches. It might th=
at you
> are hitting on one of the Intel bugs of the video adapter that I think
> are mostly fixed in the upstream kernel.

So, you're saying those (presumed) bugs a fixed only in the pvops, and
not in xenlinux?

joanna.


--------------enig3C35723086FD0948F9E33A51
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPRnnRAAoJEDaIqHeRBUM0OrsIAMf9ja4nudRvtdaFFD7Y1ygl
ZYgWN+TEZ9AYcfd8Ry/Dqwp4s+cyMG4EZDSkmBCD1HS/owXO3V4Xmd4sq+GJRTYT
PWU9+BM5sGhwEeuAY7AfAZijFour0bPEfP6k5MAcAS8u5bgcfjZTW0/yBanRK3Sr
RBM3v6iQNMPHUDbRvPT22LwupGPRRHnOPemp/PGmXZF0m/4vsylOTM19vr9Z5AxB
sINEEizaiE2+PFjtH5fDrvpHzgXRtlzO4seqF2W7AEryAgS7C6ampTUqB0VzMbEc
LGXRBYkTJxDkOaMOZ8fG+T+GSqljSAbVAOgsdiuJYcE/Riqrnk3949h6+WRhkNs=
=Fnh9
-----END PGP SIGNATURE-----

--------------enig3C35723086FD0948F9E33A51--


--===============5388585366799199108==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5388585366799199108==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 17:39:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cdq-0005km-L4; Thu, 23 Feb 2012 17:39:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1S0cdp-0005kD-8z
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:39:41 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330018774!9512061!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDQyNTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19991 invoked from network); 23 Feb 2012 17:39:35 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 17:39:35 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 222B120DE6
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 12:39:34 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute4.internal (MEProxy); Thu, 23 Feb 2012 12:39:34 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=JA
	BTFTc7xVKW50lqaVMa7BFnES0=; b=CAc7am2zfiG8zoHMhYoXUhKBAZyxHu9URD
	7+W4UEGc4ItZnYbEL4tVrRHZeh9giHAH57uzxSLEwB3Ddg9d2I2hJ0wTA8xYRH3E
	kgWAgrEsjjamUAXRhWw1bl+Rh2eKF2yysGShuMJXFfK8GyYN4/Sy4e2NEIXA6rN2
	WK4bBW2uw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=JABT
	FTc7xVKW50lqaVMa7BFnES0=; b=j6j+aYuwvvW8cKDX0sjau9Kpfi5tAudk4JDV
	FxC9Bxz+5B0+qr4UQZJnuNE7d2gysutMEcg5umTJGzjTfhWH42oLNk05rYnZUzyB
	60IcWdEp6xUv40/B7pGxwSI/jvo85hAAX7gyRHoOuVI5WDqXKa+KPuGWR2EcFT3M
	MZpuIh4=
X-Sasl-enc: 2A8J3ntdvm7ptyu+tee/9F8u6envTXR/R50oh9Qwm9+K 1330018773
Received: from [10.137.2.12] (aavp195.neoplus.adsl.tpnet.pl [83.6.49.195])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 5CBE18E0125;
	Thu, 23 Feb 2012 12:39:33 -0500 (EST)
Message-ID: <4F4679D1.3000806@invisiblethingslab.com>
Date: Thu, 23 Feb 2012 18:39:29 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
In-Reply-To: <20120223173146.GA22922@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Marek Marczykowski <marmarek@mimuw.edu.pl>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5388585366799199108=="
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)
--===============5388585366799199108==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig3C35723086FD0948F9E33A51"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3C35723086FD0948F9E33A51
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/23/12 18:31, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
>>> Hello,
>>>
>>> I've been trying to resolve the issue of my T420s (Core i5 2540M, Int=
el
>>> integrated GPU) freezing at resume from S3 sleep... It seems like a
>>> Xen-related problems, as a similar kernel to what we use in Dom0
>>> (2.6.38+xenlinux), when run on baremetal shows no signs of problems a=
t
>>> suspend/resume. Also I cannot find any problems reported on the inter=
net
>>> with people having problems here.
>>>
>>> Unfortunately the only COM port on ExpressCard I have, presents itsel=
f
>>> as a USB device, and so I cannot really debug this issue via console.=

>>> The /var/log/pm-suspend also doesn't reveal anything useful (after I
>>> reboot, that is).
>>>
>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises h=
ow
>>> to approach debugging it?
>>>
>>> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlin=
ux
>>> patches, and the i915 for the graphics. (Unfortunately I cannot just
>>> boot the same Dom0 kernel without Xen, as the GRUB complains about
>>> executable being unrecognized -- probably some problem with wrong
>>> compression algo).
>>>
>>> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kerne=
l)
>>> -- in this case it's even worse, as the system hangs at suspend and
>>> never enters S3 :/
>>
>> Right. You need some patches for that in git://git.kernel.org/pub/scm/=
linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
>> to make that work.
>=20
> What I meant to say - please try it out with those patches. It might th=
at you
> are hitting on one of the Intel bugs of the video adapter that I think
> are mostly fixed in the upstream kernel.

So, you're saying those (presumed) bugs a fixed only in the pvops, and
not in xenlinux?

joanna.


--------------enig3C35723086FD0948F9E33A51
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPRnnRAAoJEDaIqHeRBUM0OrsIAMf9ja4nudRvtdaFFD7Y1ygl
ZYgWN+TEZ9AYcfd8Ry/Dqwp4s+cyMG4EZDSkmBCD1HS/owXO3V4Xmd4sq+GJRTYT
PWU9+BM5sGhwEeuAY7AfAZijFour0bPEfP6k5MAcAS8u5bgcfjZTW0/yBanRK3Sr
RBM3v6iQNMPHUDbRvPT22LwupGPRRHnOPemp/PGmXZF0m/4vsylOTM19vr9Z5AxB
sINEEizaiE2+PFjtH5fDrvpHzgXRtlzO4seqF2W7AEryAgS7C6ampTUqB0VzMbEc
LGXRBYkTJxDkOaMOZ8fG+T+GSqljSAbVAOgsdiuJYcE/Riqrnk3949h6+WRhkNs=
=Fnh9
-----END PGP SIGNATURE-----

--------------enig3C35723086FD0948F9E33A51--


--===============5388585366799199108==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5388585366799199108==--


From xen-devel-bounces@lists.xen.org Thu Feb 23 17:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cep-0005rJ-3C; Thu, 23 Feb 2012 17:40:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0cem-0005qz-WE
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:40:41 +0000
Received: from [85.158.139.83:60977] by server-7.bemta-5.messagelabs.com id
	36/D2-16195-81A764F4; Thu, 23 Feb 2012 17:40:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330018838!16376063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29062 invoked from network); 23 Feb 2012 17:40:38 -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;
	23 Feb 2012 17:40:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10904353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:40:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:40:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0cej-0004rw-SO;
	Thu, 23 Feb 2012 17:40:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0cej-0003DJ-Qi;
	Thu, 23 Feb 2012 17:40:37 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12033-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 17:40:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12033: 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 12033 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12033/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  6 leak-check/basis(6)      fail REGR. vs. 11853

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10   fail blocked in 11853
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 11853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           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-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass

version targeted for testing:
 xen                  bf902d6661e3
baseline version:
 xen                  3feb83eed6bd

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@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                                          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                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   21565:bf902d6661e3
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Feb 23 10:41:33 2012 +0000
    
    xen: add missing unlock from gnttab_get_version
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24871:66cc5b67e749
    xen-unstable date:        Thu Feb 23 09:59:35 2012 +0000
    
    
changeset:   21564:2fc9ae7ee752
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Feb 23 10:40:43 2012 +0000
    
    gnttab: miscellaneous fixes
    
    - _GTF_* constants name bit positions, so binary arithmetic on them is
      wrong
    - gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
      clear_bit(), as that may access more than the two bytes that are
      intended to be accessed
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24742:9fc810bb8145
    xen-unstable date:        Thu Feb 09 16:39:16 2012 +0100
    
    
changeset:   21563:3feb83eed6bd
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 02 14:00:32 2012 +0000
    
    Update QEMU_TAG, for CVE-2012-0029
    
    
(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 Feb 23 17:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cep-0005rJ-3C; Thu, 23 Feb 2012 17:40:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0cem-0005qz-WE
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:40:41 +0000
Received: from [85.158.139.83:60977] by server-7.bemta-5.messagelabs.com id
	36/D2-16195-81A764F4; Thu, 23 Feb 2012 17:40:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330018838!16376063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29062 invoked from network); 23 Feb 2012 17:40:38 -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;
	23 Feb 2012 17:40:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10904353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:40:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:40:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0cej-0004rw-SO;
	Thu, 23 Feb 2012 17:40:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0cej-0003DJ-Qi;
	Thu, 23 Feb 2012 17:40:37 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12033-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 17:40:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12033: 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 12033 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12033/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  6 leak-check/basis(6)      fail REGR. vs. 11853

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10   fail blocked in 11853
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 11853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           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-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass

version targeted for testing:
 xen                  bf902d6661e3
baseline version:
 xen                  3feb83eed6bd

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@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                                          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                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   21565:bf902d6661e3
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Feb 23 10:41:33 2012 +0000
    
    xen: add missing unlock from gnttab_get_version
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24871:66cc5b67e749
    xen-unstable date:        Thu Feb 23 09:59:35 2012 +0000
    
    
changeset:   21564:2fc9ae7ee752
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Feb 23 10:40:43 2012 +0000
    
    gnttab: miscellaneous fixes
    
    - _GTF_* constants name bit positions, so binary arithmetic on them is
      wrong
    - gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use
      clear_bit(), as that may access more than the two bytes that are
      intended to be accessed
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24742:9fc810bb8145
    xen-unstable date:        Thu Feb 09 16:39:16 2012 +0100
    
    
changeset:   21563:3feb83eed6bd
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 02 14:00:32 2012 +0000
    
    Update QEMU_TAG, for CVE-2012-0029
    
    
(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 Feb 23 17:42:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cg0-00060S-Id; Thu, 23 Feb 2012 17:41:56 +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 1S0cfz-0005ze-Ht
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:41:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330018855!54039549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14576 invoked from network); 23 Feb 2012 17:40:55 -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;
	23 Feb 2012 17:40:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10904372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:41:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:41:49 +0000
Date: Thu, 23 Feb 2012 17:47:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <linux-kernel@vger.kernel.org>
Message-ID: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	kvm@vger.kernel.org, arnd@arndb.de,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, David Vrabel <david.vrabel@citrix.com>,
	linux-arm-kernel@lists.infradead.org,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH-WIP 00/13] xen/arm: receive Xen events and
 initialize 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

Hi all,
this patch series is part of the work in progress support for Xen on
ARMv7 with virtualization extensions in Linux.

It is obviously NOT ready to be accepted upstream but implements
enough support to allow Linux Dom0 to receive event channel
notifications and initialize xenbus.
With this series applied and the corresponding Xen patch series
(http://marc.info/?l=xen-devel&m=133001696312879) is possible to boot
Linux as Dom0 on Xen on a Versatile Express Cortex A15 emulator and
issue basic xl commands, like "xl list" and "xl uptime".
"xl create" is still not working though but it is the next on the list
:)


Working on this series it became obvious that passing the hypercall
number as IMM parameter to HVC is not flexible enough because we don't
always know the hypercall number at compile time.
As a result I changed the hypercall.h header file to use r12 to pass the
hypercall number instead. r12 was chosen because it is defined as
"intra-procedure call scratch register" so it seems the most appropriate. 

I have CC'ed the KVM list on the first patch because following previous
discussions hypercall.h might become a common header file to issue
hypercalls on different hypervisors on ARM. I haven't disentangled the
Xen specific bits from the generic ones yet, however it should be
straightforward.

I am looking forward to hearing your opinions, especially on the
hypercall calling convention.


The patch series is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git xenarmv7-1

It is based on the vexpress-dt branch of
git://xenbits.xen.org/people/dvrabel/linux.git, that we are currently
using as development tree for Linux on Xen on Cortex A15.  See
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions.


The list of patches with diffstat follows:

Stefano Stabellini (13):
      xen/arm: use r12 to pass the hypercall number to the hypervisor
      xen/arm: introduce privcmp, physdev_op and memory_op hypercalls.
      xen/arm: mmu.h and page.h related definitions
      xen/arm: sync_bitops
      xen/arm: empty implementation of grant_table arch specific functions
      xen/arm: missing includes
      xen/arm: receive xen events on arm
      xen/arm: fix arm xen guest handle definitions
      xen/arm: shared_info and start_info
      xen/arm: empty implementation of xen_remap_domain_mfn_range
      xen/arm: Introduce xen_pfn_t for pfn and mfn types
      xen/arm: compile and run xenbus
      xen/arm: compile grant-table features events and xenbus, do not compile pci

 arch/arm/Kconfig                           |    4 +
 arch/arm/include/asm/sync_bitops.h         |   17 ++++
 arch/arm/include/asm/xen/events.h          |    9 ++
 arch/arm/include/asm/xen/grant_table.h     |    2 +
 arch/arm/include/asm/xen/hypercall.h       |  111 ++++++++++++++++++----------
 arch/arm/include/asm/xen/interface.h       |   12 +--
 arch/arm/include/asm/xen/mmu.h             |   61 +++++++++++++++
 arch/arm/include/asm/xen/page.h            |   14 +++-
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/enlighten.c                   |   71 ++++++++++++++++--
 arch/arm/xen/grant-table.c                 |   47 ++++++++++++
 arch/ia64/include/asm/xen/interface.h      |    3 +-
 arch/x86/include/asm/xen/interface.h       |    3 +
 drivers/xen/Makefile                       |    7 +-
 drivers/xen/events.c                       |   36 +++++++++-
 drivers/xen/grant-table.c                  |    2 +
 drivers/xen/xenbus/xenbus_client.c         |    1 +
 drivers/xen/xenbus/xenbus_comms.c          |    2 +-
 drivers/xen/xenbus/xenbus_probe.c          |   26 ++++---
 drivers/xen/xenbus/xenbus_probe_frontend.c |    1 +
 drivers/xen/xenbus/xenbus_xs.c             |    3 +-
 drivers/xen/xenfs/xenstored.c              |    1 +
 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                      |    3 +-
 include/xen/xen.h                          |    2 +-
 28 files changed, 371 insertions(+), 89 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cg0-00060S-Id; Thu, 23 Feb 2012 17:41:56 +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 1S0cfz-0005ze-Ht
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:41:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330018855!54039549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14576 invoked from network); 23 Feb 2012 17:40:55 -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;
	23 Feb 2012 17:40:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="10904372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 17:41:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 17:41:49 +0000
Date: Thu, 23 Feb 2012 17:47:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <linux-kernel@vger.kernel.org>
Message-ID: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	kvm@vger.kernel.org, arnd@arndb.de,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, David Vrabel <david.vrabel@citrix.com>,
	linux-arm-kernel@lists.infradead.org,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH-WIP 00/13] xen/arm: receive Xen events and
 initialize 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

Hi all,
this patch series is part of the work in progress support for Xen on
ARMv7 with virtualization extensions in Linux.

It is obviously NOT ready to be accepted upstream but implements
enough support to allow Linux Dom0 to receive event channel
notifications and initialize xenbus.
With this series applied and the corresponding Xen patch series
(http://marc.info/?l=xen-devel&m=133001696312879) is possible to boot
Linux as Dom0 on Xen on a Versatile Express Cortex A15 emulator and
issue basic xl commands, like "xl list" and "xl uptime".
"xl create" is still not working though but it is the next on the list
:)


Working on this series it became obvious that passing the hypercall
number as IMM parameter to HVC is not flexible enough because we don't
always know the hypercall number at compile time.
As a result I changed the hypercall.h header file to use r12 to pass the
hypercall number instead. r12 was chosen because it is defined as
"intra-procedure call scratch register" so it seems the most appropriate. 

I have CC'ed the KVM list on the first patch because following previous
discussions hypercall.h might become a common header file to issue
hypercalls on different hypervisors on ARM. I haven't disentangled the
Xen specific bits from the generic ones yet, however it should be
straightforward.

I am looking forward to hearing your opinions, especially on the
hypercall calling convention.


The patch series is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git xenarmv7-1

It is based on the vexpress-dt branch of
git://xenbits.xen.org/people/dvrabel/linux.git, that we are currently
using as development tree for Linux on Xen on Cortex A15.  See
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions.


The list of patches with diffstat follows:

Stefano Stabellini (13):
      xen/arm: use r12 to pass the hypercall number to the hypervisor
      xen/arm: introduce privcmp, physdev_op and memory_op hypercalls.
      xen/arm: mmu.h and page.h related definitions
      xen/arm: sync_bitops
      xen/arm: empty implementation of grant_table arch specific functions
      xen/arm: missing includes
      xen/arm: receive xen events on arm
      xen/arm: fix arm xen guest handle definitions
      xen/arm: shared_info and start_info
      xen/arm: empty implementation of xen_remap_domain_mfn_range
      xen/arm: Introduce xen_pfn_t for pfn and mfn types
      xen/arm: compile and run xenbus
      xen/arm: compile grant-table features events and xenbus, do not compile pci

 arch/arm/Kconfig                           |    4 +
 arch/arm/include/asm/sync_bitops.h         |   17 ++++
 arch/arm/include/asm/xen/events.h          |    9 ++
 arch/arm/include/asm/xen/grant_table.h     |    2 +
 arch/arm/include/asm/xen/hypercall.h       |  111 ++++++++++++++++++----------
 arch/arm/include/asm/xen/interface.h       |   12 +--
 arch/arm/include/asm/xen/mmu.h             |   61 +++++++++++++++
 arch/arm/include/asm/xen/page.h            |   14 +++-
 arch/arm/xen/Makefile                      |    2 +-
 arch/arm/xen/enlighten.c                   |   71 ++++++++++++++++--
 arch/arm/xen/grant-table.c                 |   47 ++++++++++++
 arch/ia64/include/asm/xen/interface.h      |    3 +-
 arch/x86/include/asm/xen/interface.h       |    3 +
 drivers/xen/Makefile                       |    7 +-
 drivers/xen/events.c                       |   36 +++++++++-
 drivers/xen/grant-table.c                  |    2 +
 drivers/xen/xenbus/xenbus_client.c         |    1 +
 drivers/xen/xenbus/xenbus_comms.c          |    2 +-
 drivers/xen/xenbus/xenbus_probe.c          |   26 ++++---
 drivers/xen/xenbus/xenbus_probe_frontend.c |    1 +
 drivers/xen/xenbus/xenbus_xs.c             |    3 +-
 drivers/xen/xenfs/xenstored.c              |    1 +
 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                      |    3 +-
 include/xen/xen.h                          |    2 +-
 28 files changed, 371 insertions(+), 89 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cgk-00065t-0M; Thu, 23 Feb 2012 17:42:42 +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 1S0cgi-00065d-PI
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28300 invoked from network); 23 Feb 2012 17:40:30 -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;
	23 Feb 2012 17:40:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387550"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-3f; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:27 +0000
Message-ID: <1330019314-20865-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 06/13] xen/arm: 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/grant_table.h     |    2 ++
 drivers/xen/grant-table.c                  |    2 ++
 drivers/xen/xenbus/xenbus_client.c         |    1 +
 drivers/xen/xenbus/xenbus_probe_frontend.c |    1 +
 drivers/xen/xenfs/xenstored.c              |    1 +
 include/xen/privcmd.h                      |    1 +
 6 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/grant_table.h b/arch/arm/include/asm/xen/grant_table.h
index 4e3f7b2..43c0d4b 100644
--- a/arch/arm/include/asm/xen/grant_table.h
+++ b/arch/arm/include/asm/xen/grant_table.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_ARM_XEN_GRANT_TABLE_H
 #define _ASM_ARM_XEN_GRANT_TABLE_H
 
+#include <asm/xen/mmu.h>
+
 #define xen_alloc_vm_area(size)	alloc_vm_area(size)
 #define xen_free_vm_area(area)	free_vm_area(area)
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..de77304 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -45,6 +45,8 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <asm/xen/hypercall.h>
+#include <asm/xen/mmu.h>
+#include <asm/xen/interface.h>
 
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..65088964 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -36,6 +36,7 @@
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
+#include <asm/xen/grant_table.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
 #include <xen/events.h>
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index 2f73195..e8d1798 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/drivers/xen/xenfs/xenstored.c b/drivers/xen/xenfs/xenstored.c
index fef20db..ddf2585 100644
--- a/drivers/xen/xenfs/xenstored.c
+++ b/drivers/xen/xenfs/xenstored.c
@@ -4,6 +4,7 @@
 #include <linux/fs.h>
 
 #include <xen/page.h>
+#include <asm/xen/mmu.h>
 
 #include "xenfs.h"
 #include "../xenbus/xenbus_comms.h"
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..4d58881 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>
 
 typedef unsigned long xen_pfn_t;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cgk-00065t-0M; Thu, 23 Feb 2012 17:42:42 +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 1S0cgi-00065d-PI
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28300 invoked from network); 23 Feb 2012 17:40:30 -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;
	23 Feb 2012 17:40:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387550"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-3f; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:27 +0000
Message-ID: <1330019314-20865-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 06/13] xen/arm: 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/grant_table.h     |    2 ++
 drivers/xen/grant-table.c                  |    2 ++
 drivers/xen/xenbus/xenbus_client.c         |    1 +
 drivers/xen/xenbus/xenbus_probe_frontend.c |    1 +
 drivers/xen/xenfs/xenstored.c              |    1 +
 include/xen/privcmd.h                      |    1 +
 6 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/grant_table.h b/arch/arm/include/asm/xen/grant_table.h
index 4e3f7b2..43c0d4b 100644
--- a/arch/arm/include/asm/xen/grant_table.h
+++ b/arch/arm/include/asm/xen/grant_table.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_ARM_XEN_GRANT_TABLE_H
 #define _ASM_ARM_XEN_GRANT_TABLE_H
 
+#include <asm/xen/mmu.h>
+
 #define xen_alloc_vm_area(size)	alloc_vm_area(size)
 #define xen_free_vm_area(area)	free_vm_area(area)
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..de77304 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -45,6 +45,8 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <asm/xen/hypercall.h>
+#include <asm/xen/mmu.h>
+#include <asm/xen/interface.h>
 
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..65088964 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -36,6 +36,7 @@
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
+#include <asm/xen/grant_table.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
 #include <xen/events.h>
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index 2f73195..e8d1798 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/drivers/xen/xenfs/xenstored.c b/drivers/xen/xenfs/xenstored.c
index fef20db..ddf2585 100644
--- a/drivers/xen/xenfs/xenstored.c
+++ b/drivers/xen/xenfs/xenstored.c
@@ -4,6 +4,7 @@
 #include <linux/fs.h>
 
 #include <xen/page.h>
+#include <asm/xen/mmu.h>
 
 #include "xenfs.h"
 #include "../xenbus/xenbus_comms.h"
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..4d58881 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>
 
 typedef unsigned long xen_pfn_t;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgp-00069U-UW; Thu, 23 Feb 2012 17:42:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cgo-00065i-8k
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330018957!14672380!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15252 invoked from network); 23 Feb 2012 17:42:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387551"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-71; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:29 +0000
Message-ID: <1330019314-20865-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 08/13] xen/arm: fix arm xen guest handle
	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

__XEN__ is never defined in Linux: remove non-relevant functions and
macros

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h |    9 +--------
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 93b0139..2ee39e8 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,27 +9,20 @@
 
 #include <linux/types.h>
 
-#ifdef __XEN__
-#define __DEFINE_GUEST_HANDLE(name, type) \
-    typedef struct { type *p; } __guest_handle_ ## name
-#else
 #define __DEFINE_GUEST_HANDLE(name, type) \
     typedef type * __guest_handle_ ## name
-#endif
 
 #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
 
-#ifdef __XEN__
 #define set_xen_guest_handle(hnd, val)			\
 	do {						\
 		if (sizeof(hnd) == 8)			\
 			*(uint64_t *)&(hnd) = 0;	\
-		(hnd).p = val;				\
+		(hnd) = val;				\
 	} while (0)
-#endif
 
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgp-00069U-UW; Thu, 23 Feb 2012 17:42:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cgo-00065i-8k
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330018957!14672380!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15252 invoked from network); 23 Feb 2012 17:42:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387551"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-71; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:29 +0000
Message-ID: <1330019314-20865-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 08/13] xen/arm: fix arm xen guest handle
	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

__XEN__ is never defined in Linux: remove non-relevant functions and
macros

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h |    9 +--------
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 93b0139..2ee39e8 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,27 +9,20 @@
 
 #include <linux/types.h>
 
-#ifdef __XEN__
-#define __DEFINE_GUEST_HANDLE(name, type) \
-    typedef struct { type *p; } __guest_handle_ ## name
-#else
 #define __DEFINE_GUEST_HANDLE(name, type) \
     typedef type * __guest_handle_ ## name
-#endif
 
 #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
 
-#ifdef __XEN__
 #define set_xen_guest_handle(hnd, val)			\
 	do {						\
 		if (sizeof(hnd) == 8)			\
 			*(uint64_t *)&(hnd) = 0;	\
-		(hnd).p = val;				\
+		(hnd) = val;				\
 	} while (0)
-#endif
 
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgn-00067Q-C4; Thu, 23 Feb 2012 17:42:45 +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 1S0cgl-00065L-Mu
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28173 invoked from network); 23 Feb 2012 17:40:28 -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;
	23 Feb 2012 17:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387546"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgb-0002d9-Vy; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:24 +0000
Message-ID: <1330019314-20865-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 03/13] xen/arm: mmu.h and page.h related
	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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/mmu.h  |   61 +++++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/xen/page.h |   14 +++++++--
 2 files changed, 72 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/mmu.h

diff --git a/arch/arm/include/asm/xen/mmu.h b/arch/arm/include/asm/xen/mmu.h
new file mode 100644
index 0000000..23e9962
--- /dev/null
+++ b/arch/arm/include/asm/xen/mmu.h
@@ -0,0 +1,61 @@
+#ifndef _ASM_ARM_XEN_MMU_H
+#define _ASM_ARM_XEN_MMU_H
+
+#include <asm/page.h>
+#include <linux/types.h>
+#include <xen/interface/grant_table.h>
+
+/* 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)
+{
+	/* XXX: assuming it is mapped in the kernel 1:1 */
+	return virt_to_machine(vaddr);
+}
+
+/* XXX: this shouldn't be here */
+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;
+}
+#endif
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 17bfb55..5ee3dbe 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,8 +1,16 @@
 #ifndef _ASM_ARM_XEN_PAGE_H
 #define _ASM_ARM_XEN_PAGE_H
 
-#define mfn_to_virt(m)		(~0)
-#define mfn_to_pfn(m)		(~0)
-#define pfn_to_mfn(m)		(~0)
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <linux/types.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
 
 #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 Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgn-00067Q-C4; Thu, 23 Feb 2012 17:42:45 +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 1S0cgl-00065L-Mu
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28173 invoked from network); 23 Feb 2012 17:40:28 -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;
	23 Feb 2012 17:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387546"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgb-0002d9-Vy; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:24 +0000
Message-ID: <1330019314-20865-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 03/13] xen/arm: mmu.h and page.h related
	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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/mmu.h  |   61 +++++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/xen/page.h |   14 +++++++--
 2 files changed, 72 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/mmu.h

diff --git a/arch/arm/include/asm/xen/mmu.h b/arch/arm/include/asm/xen/mmu.h
new file mode 100644
index 0000000..23e9962
--- /dev/null
+++ b/arch/arm/include/asm/xen/mmu.h
@@ -0,0 +1,61 @@
+#ifndef _ASM_ARM_XEN_MMU_H
+#define _ASM_ARM_XEN_MMU_H
+
+#include <asm/page.h>
+#include <linux/types.h>
+#include <xen/interface/grant_table.h>
+
+/* 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)
+{
+	/* XXX: assuming it is mapped in the kernel 1:1 */
+	return virt_to_machine(vaddr);
+}
+
+/* XXX: this shouldn't be here */
+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;
+}
+#endif
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 17bfb55..5ee3dbe 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,8 +1,16 @@
 #ifndef _ASM_ARM_XEN_PAGE_H
 #define _ASM_ARM_XEN_PAGE_H
 
-#define mfn_to_virt(m)		(~0)
-#define mfn_to_pfn(m)		(~0)
-#define pfn_to_mfn(m)		(~0)
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <linux/types.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
 
 #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 Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgq-00069t-AX; Thu, 23 Feb 2012 17:42:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cgo-00065n-I0
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330018957!14672380!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15263 invoked from network); 23 Feb 2012 17:42:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:42:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387554"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-7Y; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:30 +0000
Message-ID: <1330019314-20865-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 09/13] xen/arm: shared_info and start_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

Allow xen_hvm_domain's to be xen_initial_domain.

Set xen_domain_type to XEN_HVM_DOMAIN.

Set xen_start_info to an empty struct, set flags to SIF_INITDOMAIN and
SIF_PRIVILEGED so that we identify as initial domain by default.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++------
 include/xen/xen.h        |    2 +-
 2 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 39ef68c..d76f3b4e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,24 +1,69 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
+#include <xen/interface/memory.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 = { .flags = (SIF_INITDOMAIN|SIF_PRIVILEGED) };
+struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
 
-enum xen_domain_type xen_domain_type = XEN_NATIVE;
+enum xen_domain_type xen_domain_type = XEN_HVM_DOMAIN;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
-/* TODO: remove these functions below and use the real implementation
- * instead
- */
-void rebind_evtchn_irq(int evtchn, int irq)
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+
+/* XXX: to be removed */
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
+
+/* XXX: to be removed */
+int xen_platform_pci_unplug;
+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+
+void __ref xen_hvm_init_shared_info(void)
 {
+	int cpu;
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+
+	if (!shared_info_page)
+		shared_info_page = (struct shared_info *)
+			get_zeroed_page(GFP_KERNEL);
+	if (!shared_info_page) {
+		printk(KERN_ERR "not enough memory");
+		return;
+	}
+	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.
+	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
+	 * online but xen_hvm_init_shared_info is run at resume time too and
+	 * in that case multiple vcpus might be online. */
+	for_each_online_cpu(cpu) {
+		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
+	}
 }
 
-int bind_evtchn_to_irq(unsigned int evtchn)
+static int __init xen_hvm_guest_init(void)
 {
+	xen_hvm_init_shared_info();
 	return 0;
 }
-EXPORT_SYMBOL_GPL(bind_evtchn_to_irq);
+
+core_initcall(xen_hvm_guest_init);
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 Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgm-00066s-JR; Thu, 23 Feb 2012 17:42:44 +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 1S0cgl-00065Z-3u
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 23 Feb 2012 17:40:29 -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;
	23 Feb 2012 17:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387548"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-1T; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:25 +0000
Message-ID: <1330019314-20865-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 04/13] 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.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/sync_bitops.h |   17 +++++++++++++++++
 1 files changed, 17 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..2b51456
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/system.h>
+
+#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 Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgm-00066s-JR; Thu, 23 Feb 2012 17:42:44 +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 1S0cgl-00065Z-3u
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 23 Feb 2012 17:40:29 -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;
	23 Feb 2012 17:40:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387548"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-1T; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:25 +0000
Message-ID: <1330019314-20865-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 04/13] 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.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/sync_bitops.h |   17 +++++++++++++++++
 1 files changed, 17 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..2b51456
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/system.h>
+
+#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 Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgq-00069t-AX; Thu, 23 Feb 2012 17:42:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cgo-00065n-I0
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330018957!14672380!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15263 invoked from network); 23 Feb 2012 17:42:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:42:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387554"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-7Y; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:30 +0000
Message-ID: <1330019314-20865-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 09/13] xen/arm: shared_info and start_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

Allow xen_hvm_domain's to be xen_initial_domain.

Set xen_domain_type to XEN_HVM_DOMAIN.

Set xen_start_info to an empty struct, set flags to SIF_INITDOMAIN and
SIF_PRIVILEGED so that we identify as initial domain by default.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++------
 include/xen/xen.h        |    2 +-
 2 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 39ef68c..d76f3b4e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,24 +1,69 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
+#include <xen/interface/memory.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 = { .flags = (SIF_INITDOMAIN|SIF_PRIVILEGED) };
+struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
 
-enum xen_domain_type xen_domain_type = XEN_NATIVE;
+enum xen_domain_type xen_domain_type = XEN_HVM_DOMAIN;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
-/* TODO: remove these functions below and use the real implementation
- * instead
- */
-void rebind_evtchn_irq(int evtchn, int irq)
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+
+/* XXX: to be removed */
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
+
+/* XXX: to be removed */
+int xen_platform_pci_unplug;
+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+
+void __ref xen_hvm_init_shared_info(void)
 {
+	int cpu;
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+
+	if (!shared_info_page)
+		shared_info_page = (struct shared_info *)
+			get_zeroed_page(GFP_KERNEL);
+	if (!shared_info_page) {
+		printk(KERN_ERR "not enough memory");
+		return;
+	}
+	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.
+	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
+	 * online but xen_hvm_init_shared_info is run at resume time too and
+	 * in that case multiple vcpus might be online. */
+	for_each_online_cpu(cpu) {
+		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
+	}
 }
 
-int bind_evtchn_to_irq(unsigned int evtchn)
+static int __init xen_hvm_guest_init(void)
 {
+	xen_hvm_init_shared_info();
 	return 0;
 }
-EXPORT_SYMBOL_GPL(bind_evtchn_to_irq);
+
+core_initcall(xen_hvm_guest_init);
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 Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgn-00067i-Oj; Thu, 23 Feb 2012 17:42:45 +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 1S0cgm-00065h-7D
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330018917!53730389!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13195 invoked from network); 23 Feb 2012 17:41:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:41:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387552"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-5L; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:28 +0000
Message-ID: <1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 07/13] 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 and use IRQ 32 to receive events notifications.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/events.h |    9 +++++++++
 drivers/xen/events.c              |   36 +++++++++++++++++++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index efa7c61..94b4e90 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -1,9 +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/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..18139ee 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,13 +31,15 @@
 #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/pci.h>
+#endif
+#include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -49,6 +51,8 @@
 #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>
 
 /*
  * This lock protects updates to the following mapping and reference-count
@@ -801,10 +805,12 @@ EXPORT_SYMBOL_GPL(xen_pirq_from_irq);
 int bind_evtchn_to_irq(unsigned int evtchn)
 {
 	int irq;
+	struct irq_desc *desc;
 
 	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
+	irq_clear_status_flags(irq, IRQ_NOREQUEST);
 
 	if (irq == -1) {
 		irq = xen_allocate_irq_dynamic();
@@ -813,6 +819,8 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 
 		irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
 					      handle_edge_irq, "event");
+		desc = irq_to_desc(irq);
+		irq_clear_status_flags(irq, IRQ_NOREQUEST);
 
 		xen_irq_info_evtchn_init(irq, evtchn);
 	}
@@ -1282,7 +1290,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();
@@ -1707,6 +1717,7 @@ void __init xen_init_IRQ(void)
 	for (i = 0; i < NR_EVENT_CHANNELS; i++)
 		mask_evtchn(i);
 
+#ifdef CONFIG_X86
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1718,4 +1729,27 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 	}
+#endif
 }
+#ifdef CONFIG_ARM
+#define IRQ_EVTCHN_CALLBACK 63
+irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+	__xen_evtchn_do_upcall();
+	return 0;
+}
+
+int __init xen_init_IRQ_arm(void)
+{
+	int rc;
+	xen_init_IRQ();
+	rc = request_irq(IRQ_EVTCHN_CALLBACK, xen_arm_callback,
+			IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
+			"events", "events");	
+	if (rc) {
+		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
+	}
+	return rc;
+}
+core_initcall(xen_init_IRQ_arm);
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgo-000685-3e; Thu, 23 Feb 2012 17:42:46 +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 1S0cgm-00065T-DI
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28213 invoked from network); 23 Feb 2012 17:40:28 -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;
	23 Feb 2012 17:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387547"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-1z; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:26 +0000
Message-ID: <1330019314-20865-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 05/13] 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/Makefile      |    2 +-
 arch/arm/xen/grant-table.c |   47 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 48 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 0bad594..563f22a 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o
+obj-y		:= enlighten.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..b82a799
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,47 @@
+/******************************************************************************
+ * 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,
+			   struct grant_entry **__shared)
+{
+	return -1;
+}
+
+void arch_gnttab_unmap_shared(struct grant_entry *shared,
+			      unsigned long nr_gframes)
+{
+	return;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgn-00067i-Oj; Thu, 23 Feb 2012 17:42:45 +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 1S0cgm-00065h-7D
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330018917!53730389!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13195 invoked from network); 23 Feb 2012 17:41:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:41:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387552"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-5L; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:28 +0000
Message-ID: <1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 07/13] 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 and use IRQ 32 to receive events notifications.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/events.h |    9 +++++++++
 drivers/xen/events.c              |   36 +++++++++++++++++++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index efa7c61..94b4e90 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -1,9 +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/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..18139ee 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,13 +31,15 @@
 #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/pci.h>
+#endif
+#include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -49,6 +51,8 @@
 #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>
 
 /*
  * This lock protects updates to the following mapping and reference-count
@@ -801,10 +805,12 @@ EXPORT_SYMBOL_GPL(xen_pirq_from_irq);
 int bind_evtchn_to_irq(unsigned int evtchn)
 {
 	int irq;
+	struct irq_desc *desc;
 
 	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
+	irq_clear_status_flags(irq, IRQ_NOREQUEST);
 
 	if (irq == -1) {
 		irq = xen_allocate_irq_dynamic();
@@ -813,6 +819,8 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 
 		irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
 					      handle_edge_irq, "event");
+		desc = irq_to_desc(irq);
+		irq_clear_status_flags(irq, IRQ_NOREQUEST);
 
 		xen_irq_info_evtchn_init(irq, evtchn);
 	}
@@ -1282,7 +1290,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();
@@ -1707,6 +1717,7 @@ void __init xen_init_IRQ(void)
 	for (i = 0; i < NR_EVENT_CHANNELS; i++)
 		mask_evtchn(i);
 
+#ifdef CONFIG_X86
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1718,4 +1729,27 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 	}
+#endif
 }
+#ifdef CONFIG_ARM
+#define IRQ_EVTCHN_CALLBACK 63
+irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+	__xen_evtchn_do_upcall();
+	return 0;
+}
+
+int __init xen_init_IRQ_arm(void)
+{
+	int rc;
+	xen_init_IRQ();
+	rc = request_irq(IRQ_EVTCHN_CALLBACK, xen_arm_callback,
+			IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
+			"events", "events");	
+	if (rc) {
+		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
+	}
+	return rc;
+}
+core_initcall(xen_init_IRQ_arm);
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgo-000685-3e; Thu, 23 Feb 2012 17:42:46 +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 1S0cgm-00065T-DI
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28213 invoked from network); 23 Feb 2012 17:40:28 -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;
	23 Feb 2012 17:40:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387547"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-1z; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:26 +0000
Message-ID: <1330019314-20865-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 05/13] 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/Makefile      |    2 +-
 arch/arm/xen/grant-table.c |   47 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 48 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 0bad594..563f22a 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o
+obj-y		:= enlighten.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..b82a799
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,47 @@
+/******************************************************************************
+ * 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,
+			   struct grant_entry **__shared)
+{
+	return -1;
+}
+
+void arch_gnttab_unmap_shared(struct grant_entry *shared,
+			      unsigned long nr_gframes)
+{
+	return;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgm-00067D-VI; Thu, 23 Feb 2012 17:42:44 +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 1S0cgl-00065I-GH
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28155 invoked from network); 23 Feb 2012 17:40:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387545"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:34 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgb-0002d9-V6; Thu, 23 Feb 2012 17:42:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:23 +0000
Message-ID: <1330019314-20865-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 02/13] xen/arm: introduce privcmp,
	physdev_op and memory_op 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 04eba1c..5abba48 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -187,4 +187,28 @@ HYPERVISOR_event_channel_op(int cmd, void *arg)
 	return _hypercall2(int, HYPERCALL(event_channel_op), cmd, arg);
 }
 
+static inline unsigned long HYPERVISOR_hvm_op(int op, void *arg)
+{
+       return -ENOSYS;
+}
+
+static inline int
+HYPERVISOR_memory_op(unsigned int cmd, void *arg)
+{
+	return _hypercall2(int, HYPERCALL(memory_op), cmd, arg);
+}
+
+static inline int HYPERVISOR_physdev_op(int cmd, void *arg)
+{
+	return _hypercall2(int, HYPERCALL(physdev_op), cmd, arg);
+}
+
+static inline long privcmd_call(unsigned call,
+		unsigned long a1, unsigned long a2,
+		unsigned long a3, unsigned long a4,
+		unsigned long a5)
+{
+	return _hypercall5(long, call, a1, a2, a3, a4, a5);
+}
+
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cgm-00067D-VI; Thu, 23 Feb 2012 17:42:44 +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 1S0cgl-00065I-GH
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28155 invoked from network); 23 Feb 2012 17:40:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387545"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:34 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgb-0002d9-V6; Thu, 23 Feb 2012 17:42:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:23 +0000
Message-ID: <1330019314-20865-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 02/13] xen/arm: introduce privcmp,
	physdev_op and memory_op 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 04eba1c..5abba48 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -187,4 +187,28 @@ HYPERVISOR_event_channel_op(int cmd, void *arg)
 	return _hypercall2(int, HYPERCALL(event_channel_op), cmd, arg);
 }
 
+static inline unsigned long HYPERVISOR_hvm_op(int op, void *arg)
+{
+       return -ENOSYS;
+}
+
+static inline int
+HYPERVISOR_memory_op(unsigned int cmd, void *arg)
+{
+	return _hypercall2(int, HYPERCALL(memory_op), cmd, arg);
+}
+
+static inline int HYPERVISOR_physdev_op(int cmd, void *arg)
+{
+	return _hypercall2(int, HYPERCALL(physdev_op), cmd, arg);
+}
+
+static inline long privcmd_call(unsigned call,
+		unsigned long a1, unsigned long a2,
+		unsigned long a3, unsigned long a4,
+		unsigned long a5)
+{
+	return _hypercall5(long, call, a1, a2, a3, a4, a5);
+}
+
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cgq-0006AF-Lt; Thu, 23 Feb 2012 17:42:48 +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 1S0cgo-00065o-Iv
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28316 invoked from network); 23 Feb 2012 17:40:30 -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;
	23 Feb 2012 17:40:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387553"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-87; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:31 +0000
Message-ID: <1330019314-20865-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 10/13] xen/arm: empty implementation of
	xen_remap_domain_mfn_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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d76f3b4e..986bec3 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -25,6 +25,16 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+/* TODO */
+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);
+
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cgq-0006AF-Lt; Thu, 23 Feb 2012 17:42:48 +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 1S0cgo-00065o-Iv
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330018826!60998524!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28316 invoked from network); 23 Feb 2012 17:40:30 -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;
	23 Feb 2012 17:40:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387553"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-87; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:31 +0000
Message-ID: <1330019314-20865-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 10/13] xen/arm: empty implementation of
	xen_remap_domain_mfn_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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d76f3b4e..986bec3 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -25,6 +25,16 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+/* TODO */
+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);
+
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cgp-000699-ID; Thu, 23 Feb 2012 17:42:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cgn-00065c-UE
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330018957!14672380!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15233 invoked from network); 23 Feb 2012 17:42:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387549"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgb-0002d9-UP; Thu, 23 Feb 2012 17:42:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:22 +0000
Message-ID: <1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 01/13] xen/arm: use r12 to pass the
	hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: kvm@vger.kernel.org
---
 arch/arm/include/asm/xen/hypercall.h |   87 +++++++++++++++++++---------------
 1 files changed, 48 insertions(+), 39 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 404e63f0..04eba1c 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -33,13 +33,17 @@
 #ifndef _ASM_ARM_XEN_HYPERCALL_H
 #define _ASM_ARM_XEN_HYPERCALL_H
 
-#define __HVC_IMM(name)	"( " #name " & 0xf) + "	  \
-			    "((" #name " << 4) & 0xfff00)"
+#include <xen/interface/xen.h>
+#include <asm/errno.h>
 
-#define ____HYPERCALL(name) ".word 0xe1400070 + " __HVC_IMM(name)
-#define __HYPERCALL(name) ____HYPERCALL(__HYPERVISOR_##name)
+#define XEN_HYPERCALL_TAG  "0XEA1"
+
+#define __HVC_IMM(tag)	"( " tag " & 0xf) + "	  \
+			    "((" tag " << 4) & 0xfff00)"
+#define __HYPERCALL ".word 0xe1400070 + " __HVC_IMM(XEN_HYPERCALL_TAG)
 
 #define __HYPERCALL_RETREG	"r0"
+#define __HYPERCALL_NUMBER	"r12"
 #define __HYPERCALL_ARG1REG	"r0"
 #define __HYPERCALL_ARG2REG	"r1"
 #define __HYPERCALL_ARG3REG	"r2"
@@ -48,30 +52,32 @@
 
 #define __HYPERCALL_DECLS						\
 	register unsigned long __res  asm(__HYPERCALL_RETREG);		\
+	register unsigned long __num  asm(__HYPERCALL_NUMBER) = __num; \
 	register unsigned long __arg1 asm(__HYPERCALL_ARG1REG) = __arg1; \
 	register unsigned long __arg2 asm(__HYPERCALL_ARG2REG) = __arg2; \
 	register unsigned long __arg3 asm(__HYPERCALL_ARG3REG) = __arg3; \
 	register unsigned long __arg4 asm(__HYPERCALL_ARG4REG) = __arg4; \
 	register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5;
 
-#define __HYPERCALL_0PARAM	"=r" (__res)
+#define __HYPERCALL_0PARAM	"=r" (__res), "+r" (__num)
 #define __HYPERCALL_1PARAM	__HYPERCALL_0PARAM, "+r" (__arg1)
 #define __HYPERCALL_2PARAM	__HYPERCALL_1PARAM, "+r" (__arg2)
 #define __HYPERCALL_3PARAM	__HYPERCALL_2PARAM, "+r" (__arg3)
 #define __HYPERCALL_4PARAM	__HYPERCALL_3PARAM, "+r" (__arg4)
 #define __HYPERCALL_5PARAM	__HYPERCALL_4PARAM, "+r" (__arg5)
 
-#define __HYPERCALL_0ARG()
-#define __HYPERCALL_1ARG(a1)						\
-	__HYPERCALL_0ARG()		__arg1 = (unsigned long)(a1);
-#define __HYPERCALL_2ARG(a1,a2)						\
-	__HYPERCALL_1ARG(a1)		__arg2 = (unsigned long)(a2);
-#define __HYPERCALL_3ARG(a1,a2,a3)					\
-	__HYPERCALL_2ARG(a1,a2)		__arg3 = (unsigned long)(a3);
-#define __HYPERCALL_4ARG(a1,a2,a3,a4)					\
-	__HYPERCALL_3ARG(a1,a2,a3)	__arg4 = (unsigned long)(a4);
-#define __HYPERCALL_5ARG(a1,a2,a3,a4,a5)				\
-	__HYPERCALL_4ARG(a1,a2,a3,a4)	__arg5 = (unsigned long)(a5);
+#define __HYPERCALL_0ARG(hypercall)						\
+	__num = (unsigned long)hypercall;
+#define __HYPERCALL_1ARG(hypercall,a1)						\
+	__HYPERCALL_0ARG(hypercall)		__arg1 = (unsigned long)(a1);
+#define __HYPERCALL_2ARG(hypercall,a1,a2)						\
+	__HYPERCALL_1ARG(hypercall,a1)		__arg2 = (unsigned long)(a2);
+#define __HYPERCALL_3ARG(hypercall,a1,a2,a3)					\
+	__HYPERCALL_2ARG(hypercall,a1,a2)		__arg3 = (unsigned long)(a3);
+#define __HYPERCALL_4ARG(hypercall,a1,a2,a3,a4)					\
+	__HYPERCALL_3ARG(hypercall,a1,a2,a3)	__arg4 = (unsigned long)(a4);
+#define __HYPERCALL_5ARG(hypercall,a1,a2,a3,a4,a5)				\
+	__HYPERCALL_4ARG(hypercall,a1,a2,a3,a4)	__arg5 = (unsigned long)(a5);
 
 #define __HYPERCALL_CLOBBER5	"memory"
 #define __HYPERCALL_CLOBBER4	__HYPERCALL_CLOBBER5, __HYPERCALL_ARG5REG
@@ -80,102 +86,105 @@
 #define __HYPERCALL_CLOBBER1	__HYPERCALL_CLOBBER2, __HYPERCALL_ARG2REG
 #define __HYPERCALL_CLOBBER0	__HYPERCALL_CLOBBER1, __HYPERCALL_ARG1REG
 
-#define _hypercall0(type, name)						\
+#define _hypercall0(type, hypercall)						\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_0ARG();						\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_0ARG(hypercall);						\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_0PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER0);				\
 	(type)__res;							\
 })
 
-#define _hypercall1(type, name, a1)					\
+#define _hypercall1(type, hypercall, a1)					\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_1ARG(a1);						\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_1ARG(hypercall, a1);						\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_1PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER1);				\
 	(type)__res;							\
 })
 
-#define _hypercall2(type, name, a1, a2)					\
+#define _hypercall2(type, hypercall, a1, a2)					\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_2ARG(a1, a2);					\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_2ARG(hypercall, a1, a2);					\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_2PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER2);				\
 	(type)__res;							\
 })
 
-#define _hypercall3(type, name, a1, a2, a3)				\
+#define _hypercall3(type, hypercall, a1, a2, a3)				\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_3ARG(a1, a2, a3);					\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_3ARG(hypercall, a1, a2, a3);					\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_3PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER3);				\
 	(type)__res;							\
 })
 
-#define _hypercall4(type, name, a1, a2, a3, a4)				\
+#define _hypercall4(type, hypercall, a1, a2, a3, a4)				\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_4ARG(a1, a2, a3, a4);				\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_4ARG(hypercall, a1, a2, a3, a4);				\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_4PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER4);				\
 	(type)__res;							\
 })
 
-#define _hypercall5(type, name, a1, a2, a3, a4, a5)			\
+#define _hypercall5(type, hypercall, a1, a2, a3, a4, a5)			\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_5ARG(a1, a2, a3, a4, a5);				\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_5ARG(hypercall, a1, a2, a3, a4, a5);				\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_5PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER5);				\
 	(type)__res;							\
 })
 
+#define HYPERCALL(name) \
+	(__HYPERVISOR_##name)
+
 /* -- Hypercall definitions go below -- */
 
 static inline int
 HYPERVISOR_xen_version(int cmd, void *arg)
 {
-	return _hypercall2(int, xen_version, cmd, arg);
+	return _hypercall2(int, HYPERCALL(xen_version), cmd, arg);
 }
 
 static inline int
 HYPERVISOR_console_io(int cmd, int count, char *str)
 {
-	return _hypercall3(int, console_io, cmd, count, str);
+	return _hypercall3(int, HYPERCALL(console_io), cmd, count, str);
 }
 
 static inline int
 HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
 {
-	return _hypercall3(int, grant_table_op, cmd, uop, count);
+	return _hypercall3(int, HYPERCALL(grant_table_op), cmd, uop, count);
 }
 
 static inline int
 HYPERVISOR_sched_op(int cmd, void *arg)
 {
-	return _hypercall2(int, sched_op, cmd, arg);
+	return _hypercall2(int, HYPERCALL(sched_op), cmd, arg);
 }
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
-	return _hypercall2(int, event_channel_op, cmd, arg);
+	return _hypercall2(int, HYPERCALL(event_channel_op), cmd, arg);
 }
 
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:42:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:42:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cgp-000699-ID; Thu, 23 Feb 2012 17:42:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cgn-00065c-UE
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:42:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330018957!14672380!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15233 invoked from network); 23 Feb 2012 17:42:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387549"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:42:35 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:42:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgb-0002d9-UP; Thu, 23 Feb 2012 17:42:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:22 +0000
Message-ID: <1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 01/13] xen/arm: use r12 to pass the
	hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: kvm@vger.kernel.org
---
 arch/arm/include/asm/xen/hypercall.h |   87 +++++++++++++++++++---------------
 1 files changed, 48 insertions(+), 39 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 404e63f0..04eba1c 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -33,13 +33,17 @@
 #ifndef _ASM_ARM_XEN_HYPERCALL_H
 #define _ASM_ARM_XEN_HYPERCALL_H
 
-#define __HVC_IMM(name)	"( " #name " & 0xf) + "	  \
-			    "((" #name " << 4) & 0xfff00)"
+#include <xen/interface/xen.h>
+#include <asm/errno.h>
 
-#define ____HYPERCALL(name) ".word 0xe1400070 + " __HVC_IMM(name)
-#define __HYPERCALL(name) ____HYPERCALL(__HYPERVISOR_##name)
+#define XEN_HYPERCALL_TAG  "0XEA1"
+
+#define __HVC_IMM(tag)	"( " tag " & 0xf) + "	  \
+			    "((" tag " << 4) & 0xfff00)"
+#define __HYPERCALL ".word 0xe1400070 + " __HVC_IMM(XEN_HYPERCALL_TAG)
 
 #define __HYPERCALL_RETREG	"r0"
+#define __HYPERCALL_NUMBER	"r12"
 #define __HYPERCALL_ARG1REG	"r0"
 #define __HYPERCALL_ARG2REG	"r1"
 #define __HYPERCALL_ARG3REG	"r2"
@@ -48,30 +52,32 @@
 
 #define __HYPERCALL_DECLS						\
 	register unsigned long __res  asm(__HYPERCALL_RETREG);		\
+	register unsigned long __num  asm(__HYPERCALL_NUMBER) = __num; \
 	register unsigned long __arg1 asm(__HYPERCALL_ARG1REG) = __arg1; \
 	register unsigned long __arg2 asm(__HYPERCALL_ARG2REG) = __arg2; \
 	register unsigned long __arg3 asm(__HYPERCALL_ARG3REG) = __arg3; \
 	register unsigned long __arg4 asm(__HYPERCALL_ARG4REG) = __arg4; \
 	register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5;
 
-#define __HYPERCALL_0PARAM	"=r" (__res)
+#define __HYPERCALL_0PARAM	"=r" (__res), "+r" (__num)
 #define __HYPERCALL_1PARAM	__HYPERCALL_0PARAM, "+r" (__arg1)
 #define __HYPERCALL_2PARAM	__HYPERCALL_1PARAM, "+r" (__arg2)
 #define __HYPERCALL_3PARAM	__HYPERCALL_2PARAM, "+r" (__arg3)
 #define __HYPERCALL_4PARAM	__HYPERCALL_3PARAM, "+r" (__arg4)
 #define __HYPERCALL_5PARAM	__HYPERCALL_4PARAM, "+r" (__arg5)
 
-#define __HYPERCALL_0ARG()
-#define __HYPERCALL_1ARG(a1)						\
-	__HYPERCALL_0ARG()		__arg1 = (unsigned long)(a1);
-#define __HYPERCALL_2ARG(a1,a2)						\
-	__HYPERCALL_1ARG(a1)		__arg2 = (unsigned long)(a2);
-#define __HYPERCALL_3ARG(a1,a2,a3)					\
-	__HYPERCALL_2ARG(a1,a2)		__arg3 = (unsigned long)(a3);
-#define __HYPERCALL_4ARG(a1,a2,a3,a4)					\
-	__HYPERCALL_3ARG(a1,a2,a3)	__arg4 = (unsigned long)(a4);
-#define __HYPERCALL_5ARG(a1,a2,a3,a4,a5)				\
-	__HYPERCALL_4ARG(a1,a2,a3,a4)	__arg5 = (unsigned long)(a5);
+#define __HYPERCALL_0ARG(hypercall)						\
+	__num = (unsigned long)hypercall;
+#define __HYPERCALL_1ARG(hypercall,a1)						\
+	__HYPERCALL_0ARG(hypercall)		__arg1 = (unsigned long)(a1);
+#define __HYPERCALL_2ARG(hypercall,a1,a2)						\
+	__HYPERCALL_1ARG(hypercall,a1)		__arg2 = (unsigned long)(a2);
+#define __HYPERCALL_3ARG(hypercall,a1,a2,a3)					\
+	__HYPERCALL_2ARG(hypercall,a1,a2)		__arg3 = (unsigned long)(a3);
+#define __HYPERCALL_4ARG(hypercall,a1,a2,a3,a4)					\
+	__HYPERCALL_3ARG(hypercall,a1,a2,a3)	__arg4 = (unsigned long)(a4);
+#define __HYPERCALL_5ARG(hypercall,a1,a2,a3,a4,a5)				\
+	__HYPERCALL_4ARG(hypercall,a1,a2,a3,a4)	__arg5 = (unsigned long)(a5);
 
 #define __HYPERCALL_CLOBBER5	"memory"
 #define __HYPERCALL_CLOBBER4	__HYPERCALL_CLOBBER5, __HYPERCALL_ARG5REG
@@ -80,102 +86,105 @@
 #define __HYPERCALL_CLOBBER1	__HYPERCALL_CLOBBER2, __HYPERCALL_ARG2REG
 #define __HYPERCALL_CLOBBER0	__HYPERCALL_CLOBBER1, __HYPERCALL_ARG1REG
 
-#define _hypercall0(type, name)						\
+#define _hypercall0(type, hypercall)						\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_0ARG();						\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_0ARG(hypercall);						\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_0PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER0);				\
 	(type)__res;							\
 })
 
-#define _hypercall1(type, name, a1)					\
+#define _hypercall1(type, hypercall, a1)					\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_1ARG(a1);						\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_1ARG(hypercall, a1);						\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_1PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER1);				\
 	(type)__res;							\
 })
 
-#define _hypercall2(type, name, a1, a2)					\
+#define _hypercall2(type, hypercall, a1, a2)					\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_2ARG(a1, a2);					\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_2ARG(hypercall, a1, a2);					\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_2PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER2);				\
 	(type)__res;							\
 })
 
-#define _hypercall3(type, name, a1, a2, a3)				\
+#define _hypercall3(type, hypercall, a1, a2, a3)				\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_3ARG(a1, a2, a3);					\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_3ARG(hypercall, a1, a2, a3);					\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_3PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER3);				\
 	(type)__res;							\
 })
 
-#define _hypercall4(type, name, a1, a2, a3, a4)				\
+#define _hypercall4(type, hypercall, a1, a2, a3, a4)				\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_4ARG(a1, a2, a3, a4);				\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_4ARG(hypercall, a1, a2, a3, a4);				\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_4PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER4);				\
 	(type)__res;							\
 })
 
-#define _hypercall5(type, name, a1, a2, a3, a4, a5)			\
+#define _hypercall5(type, hypercall, a1, a2, a3, a4, a5)			\
 ({									\
 	__HYPERCALL_DECLS;						\
-	__HYPERCALL_5ARG(a1, a2, a3, a4, a5);				\
-	asm volatile (__HYPERCALL(name)					\
+	__HYPERCALL_5ARG(hypercall, a1, a2, a3, a4, a5);				\
+	asm volatile (__HYPERCALL					\
 		      : __HYPERCALL_5PARAM				\
 		      : 						\
 		      : __HYPERCALL_CLOBBER5);				\
 	(type)__res;							\
 })
 
+#define HYPERCALL(name) \
+	(__HYPERVISOR_##name)
+
 /* -- Hypercall definitions go below -- */
 
 static inline int
 HYPERVISOR_xen_version(int cmd, void *arg)
 {
-	return _hypercall2(int, xen_version, cmd, arg);
+	return _hypercall2(int, HYPERCALL(xen_version), cmd, arg);
 }
 
 static inline int
 HYPERVISOR_console_io(int cmd, int count, char *str)
 {
-	return _hypercall3(int, console_io, cmd, count, str);
+	return _hypercall3(int, HYPERCALL(console_io), cmd, count, str);
 }
 
 static inline int
 HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
 {
-	return _hypercall3(int, grant_table_op, cmd, uop, count);
+	return _hypercall3(int, HYPERCALL(grant_table_op), cmd, uop, count);
 }
 
 static inline int
 HYPERVISOR_sched_op(int cmd, void *arg)
 {
-	return _hypercall2(int, sched_op, cmd, arg);
+	return _hypercall2(int, HYPERCALL(sched_op), cmd, arg);
 }
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
-	return _hypercall2(int, event_channel_op, cmd, arg);
+	return _hypercall2(int, HYPERCALL(event_channel_op), cmd, arg);
 }
 
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0ciy-0007HR-Rn; Thu, 23 Feb 2012 17:45:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0ciw-0007G0-Jt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:58 +0000
Received: from [85.158.139.83:21902] by server-12.bemta-5.messagelabs.com id
	DB/31-05100-91B764F4; Thu, 23 Feb 2012 17:44:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330019095!16391455!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31877 invoked from network); 23 Feb 2012 17:44:57 -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;
	23 Feb 2012 17:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165475"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:54 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cis-0002f3-BH; Thu, 23 Feb 2012 17:44:54 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006al-3X;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:47 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 00 of 10] arm: SMP 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

This patch series implements SMP boot for arch/arm, as far as getting
all CPUs up and running the idle loop.

The first few patches are semi-independent cleanups and improvements,
most of which are needed for the SMP patches later.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0ciy-0007HR-Rn; Thu, 23 Feb 2012 17:45:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0ciw-0007G0-Jt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:58 +0000
Received: from [85.158.139.83:21902] by server-12.bemta-5.messagelabs.com id
	DB/31-05100-91B764F4; Thu, 23 Feb 2012 17:44:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330019095!16391455!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31877 invoked from network); 23 Feb 2012 17:44:57 -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;
	23 Feb 2012 17:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165475"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:54 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:54 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cis-0002f3-BH; Thu, 23 Feb 2012 17:44:54 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006al-3X;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:47 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 00 of 10] arm: SMP 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

This patch series implements SMP boot for arch/arm, as far as getting
all CPUs up and running the idle loop.

The first few patches are semi-independent cleanups and improvements,
most of which are needed for the SMP patches later.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cix-0007GP-EE; Thu, 23 Feb 2012 17:44:59 +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 1S0civ-0007Fq-RC
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25668 invoked from network); 23 Feb 2012 17:44:31 -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;
	23 Feb 2012 17:44:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387643"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:54 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cis-0002f6-K8; Thu, 23 Feb 2012 17:44:54 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006ao-Bb;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4a7c1420913135fbeba361cd9603e748c074cdac
Message-ID: <4a7c1420913135fbeba3.1330018848@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:48 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01 of 10] arm: strip xen binary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 4a7c1420913135fbeba361cd9603e748c074cdac
# Parent  0c3d19f40ab145d101de84051c3e00eef17fa1cb
arm: strip xen binary

The symbols in it are wrong anyway and will only confuse people
who ought to be looking at xen-syms.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0c3d19f40ab1 -r 4a7c14209131 xen/arch/arm/Makefile
--- a/xen/arch/arm/Makefile	Mon Feb 20 22:16:32 2012 +0100
+++ b/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
@@ -40,7 +40,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
 	# 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 $< $@
-	# XXX strip it
+	$(STRIP) $@
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
 #	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0ciz-0007Ht-Ou; Thu, 23 Feb 2012 17:45: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 1S0cix-0007GF-B1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25754 invoked from network); 23 Feb 2012 17:44:33 -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;
	23 Feb 2012 17:44:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cit-0002fI-O4; Thu, 23 Feb 2012 17:44:55 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cit-0006b5-FT;
	Thu, 23 Feb 2012 17:44:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
Message-ID: <1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:52 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05 of 10] arm: More SMP bringup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
# Parent  8f322ab538572e1a12c8ed716ddd5cb4c122e9ed
arm: More SMP bringup

Bring non-boot CPUs up as far as running on the relocated pagetables,
one at a time, before the non-relocated copy of Xen gets reused for
general memory pools.

Don't yet bring them up into C; that will happen later when stacks are
allocated.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -248,7 +248,7 @@ static void __cpuinit gic_hyp_init(void)
 }
 
 /* Set up the GIC */
-void gic_init(void)
+int __init gic_init(void)
 {
     /* XXX FIXME get this from devicetree */
     gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
@@ -270,6 +270,8 @@ void gic_init(void)
     gic_hyp_init();
 
     spin_unlock(&gic.lock);
+
+    return gic.cpus;
 }
 
 void gic_route_irqs(void)
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/gic.h
--- a/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
@@ -138,8 +138,8 @@ extern int gic_route_irq_to_guest(struct
 
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
-/* Bring up the interrupt controller */
-extern void gic_init(void);
+/* Bring up the interrupt controller, and report # cpus attached */
+extern int gic_init(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
 #endif
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
@@ -62,22 +62,36 @@ start:
 #endif
 
 	/* Are we the boot CPU? */
+	mov   r12, #0                /* r12 := CPU ID */
 	mrc   CP32(r0, MPIDR)
 	tst   r0, #(1<<31)           /* Multiprocessor extension supported? */
 	beq   boot_cpu
 	tst   r0, #(1<<30)           /* Uniprocessor system? */
 	bne   boot_cpu
-	bics  r0, r0, #(0xff << 24)  /* Ignore flags */
-	beq   boot_cpu               /* If all other fields are 0, we win */
+	bics  r12, r0, #(0xff << 24) /* Mask out flags to get CPU ID */
+	beq   boot_cpu               /* If we're CPU 0, boot now */
 
-1:	wfi
-	b     1b
-	
+	/* Non-boot CPUs wait here to be woken up one at a time.
+	 * This is basically an open-coded spin-lock to serialize. */
+	ldr   r0, =boot_gate         /* VA of gate */
+	add   r0, r0, r10            /* PA of gate */
+	mov   r1, #1                 /* (1 == locked) */
+1:	wfe
+	ldrex r2, [r0]               /* Linked read of current value */
+	teq   r2, #0                 /* (0 == unlocked) */
+	strexeq r2, r1, [r0]         /* Matching update -> locked */
+	teq   r2, #0                 /* (0 == succeeded) */
+	bne   1b
+
 boot_cpu:
 #ifdef EARLY_UART_ADDRESS
-	/* Say hello */
 	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
-	bl    init_uart
+	teq   r12, #0                   /* CPU 0 sets up the UART too */
+	bleq  init_uart
+	PRINT("- CPU ")
+	mov   r0, r12
+	bl    putn
+	PRINT(" booting -\r\n")
 #endif
 
 	/* Check that this CPU has Hyp mode */
@@ -85,7 +99,6 @@ boot_cpu:
 	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
 	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
 	beq   1f
-	bl    putn
 	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
 	b     fail
 1:
@@ -185,6 +198,10 @@ hyp:
 	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
 	mcrr  CP64(r4, r5, HTTBR)
 
+	/* Non-boot CPUs don't need to rebuild the pagetable */
+	teq   r12, #0
+	bne   pt_ready
+	
 	/* Build the baseline idle pagetable's first-level entries */
 	ldr   r1, =xen_second
 	add   r1, r1, r10            /* r1 := paddr (xen_second) */
@@ -226,6 +243,7 @@ hyp:
 	add   r4, r4, #8
 	strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
+pt_ready:
 	PRINT("- Turning on paging -\r\n")
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
@@ -238,7 +256,7 @@ hyp:
 paging:
 
 #ifdef EARLY_UART_ADDRESS
-	/* Recover the UART address in the new address space */
+	/* Recover the UART address in the new address space. */
 	lsl   r11, #11
 	lsr   r11, #11               /* UART base's offset from 2MB base */
 	adr   r0, start
@@ -246,14 +264,57 @@ paging:
 	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
 #endif
 
-	PRINT("- Entering C -\r\n")
+	PRINT("- Ready -\r\n")
 
+	/* The boot CPU should go straight into C now */
+	teq   r12, #0
+	beq   launch
+
+	/* Signal the next non-boot CPU to come and join us here */
+	ldr   r0, =boot_gate         /* VA of gate */
+	add   r0, r0, r10            /* PA of gate */
+	mov   r1, #0                 /* (0 == unlocked) */
+	str   r1, [r0]
+	dsb
+	isb
+	sev
+
+	/* Move on to the relocated pagetables */
+	mov   r0, #0
+	ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
+	add   r4, r4, r10            /* PA of it */
+	ldrd  r4, r5, [r4]           /* Actual value */
+	mcrr  CP64(r4, r5, HTTBR)
+	mcr   CP32(r0, TLBIALLH)     /* Flush hypervisor TLB */
+	mcr   CP32(r0, BPIALL)       /* Flush branch predictor */
+	dsb                          /* Ensure completion of TLB+BP flush */
+	isb
+ 	/* Now, the UART is in its proper fixmap address */
+	ldrne r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+
+	/* Non-boot CPUs report that they've got this far */
+	ldr   r0, =ready_cpus
+	ldr   r1, [r0]               /* Read count of ready CPUs */
+	add   r1, r1, #1             /* ++ */
+	str   r1, [r0]               /* Writeback */
+	dsb
+
+	/* Here, the non-boot CPUs must wait again -- they're now running on
+	 * the boot CPU's pagetables so it's safe for the boot CPU to
+	 * overwrite the non-relocated copy of Xen.  Once it's done that,
+	 * and brought up the memory allocator, non-boot CPUs can get their
+	 * own stacks and enter C. */
+1:	wfe
+	b 1b
+
+launch:	
 	ldr   sp, =init_stack        /* Supply a stack */
 	add   sp, #STACK_SIZE        /* (which grows down from the top). */
 	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
 	mov   r0, r10                /* Marshal args: - phys_offset */
 	mov   r1, r7                 /*               - machine type */
 	mov   r2, r8                 /*               - ATAG address */
+	mov   r3, r12                /*               - CPU ID */
 	b     start_xen              /* and disappear into the land of C */
 
 /* Fail-stop
@@ -288,7 +349,7 @@ puts:
 	tst   r2, #0x8               /* Check BUSY bit */
 	bne   puts                   /* Wait for the UART to be ready */
 	ldrb  r2, [r0], #1           /* Load next char */
-	teq   r2, #0                 /* Exit on nul*/
+	teq   r2, #0                 /* Exit on nul */
 	moveq pc, lr
 	str   r2, [r11]              /* -> UARTDR (Data Register) */
 	b     puts
@@ -308,10 +369,8 @@ 1:	ldr   r2, [r11, #0x18]       /* <- UA
 	lsl   r0, #4                 /* Roll it through one nybble at a time */
 	subs  r3, r3, #1
 	bne   1b
-	adr   r0, crlf               /* Finish with a newline */
-	b     puts
+	mov   pc, lr
 
-crlf:	.asciz "\r\n"
 hex:	.ascii "0123456789abcdef"
 	.align 2
 
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 23 17:39:59 2012 +0000
@@ -36,6 +36,9 @@ lpae_t xen_second[LPAE_ENTRIES*4] __attr
 static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
+/* Non-boot CPUs use this to find the correct pagetables. */
+uint64_t boot_httbr;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -156,14 +159,6 @@ void __init setup_pagetables(unsigned lo
     lpae_t pte, *p;
     int i;
 
-    if ( boot_phys_offset != 0 )
-    {
-        /* Remove the old identity mapping of the boot paddr */
-        pte.bits = 0;
-        dest_va = (unsigned long)_start + boot_phys_offset;
-        write_pte(xen_second + second_linear_offset(dest_va), pte);
-    }
-
     xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
@@ -186,11 +181,19 @@ void __init setup_pagetables(unsigned lo
     for ( i = 0; i < 4; i++)
         p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
     p = (void *) xen_second + dest_va - (unsigned long) _start;
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        p[second_linear_offset(dest_va)] = pte;
+    }
     for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
         if ( p[i].pt.valid )
                 p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
 
     /* Change pagetables to the copy in the relocated Xen */
+    boot_httbr = (unsigned long) xen_pgtable + phys_offset;
     asm volatile (
         STORE_CP64(0, HTTBR)          /* Change translation base */
         "dsb;"                        /* Ensure visibility of HTTBR update */
@@ -198,7 +201,7 @@ void __init setup_pagetables(unsigned lo
         STORE_CP32(0, BPIALL)         /* Flush branch predictor */
         "dsb;"                        /* Ensure completion of TLB+BP flush */
         "isb;"
-        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+        : : "r" (boot_httbr) : "memory");
 
     /* Undo the temporary map */
     pte.bits = 0;
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
@@ -44,7 +44,12 @@ static unsigned int __initdata max_cpus 
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
-extern char __init_begin[], __init_end[], __bss_start[];
+extern const char __init_begin[], __init_end[], __bss_start[];
+
+/* Spinlock for serializing CPU bringup */
+unsigned long __initdata boot_gate = 1;
+/* Number of non-boot CPUs ready to enter C */
+unsigned long __initdata ready_cpus = 0;
 
 static __attribute_used__ void init_done(void)
 {
@@ -151,14 +156,17 @@ static void __init setup_mm(unsigned lon
     end_boot_allocator();
 }
 
+/* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
-                      unsigned long atag_paddr)
-
+                      unsigned long atag_paddr,
+                      unsigned long cpuid)
 {
     void *fdt;
     size_t fdt_size;
-    int i;
+    int cpus, i;
+    paddr_t gate_pa;
+    unsigned long *gate;
 
     fdt = (void *)BOOT_MISC_VIRT_START
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
@@ -174,6 +182,22 @@ void __init start_xen(unsigned long boot
     console_init_preirq();
 #endif
 
+    cpus = gic_init();
+
+    printk("Waiting for %i other CPUs to be ready\n", cpus - 1);
+    /* Bring the other CPUs up to paging before the original
+     * copy of .text gets overwritten.  We need to use the unrelocated
+     * copy of boot_gate as that's the one the others can see. */ 
+    gate_pa = ((unsigned long) &boot_gate) + boot_phys_offset;
+    gate = map_domain_page(gate_pa >> PAGE_SHIFT) + (gate_pa & ~PAGE_MASK); 
+    *gate = 0;
+    unmap_domain_page(gate);
+    /* Now send an event to wake the first non-boot CPU */
+    asm volatile("dsb; isb; sev");
+    /* And wait for them all to be ready. */
+    while ( ready_cpus + 1 < cpus )
+        smp_rmb();
+
     __set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
     set_processor_id(0); /* needed early, for smp_processor_id() */
@@ -208,8 +232,6 @@ void __init start_xen(unsigned long boot
 
     init_IRQ();
 
-    gic_init();
-
     gic_route_irqs();
 
     init_maintenance_interrupt();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0ciz-0007Ht-Ou; Thu, 23 Feb 2012 17:45: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 1S0cix-0007GF-B1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25754 invoked from network); 23 Feb 2012 17:44:33 -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;
	23 Feb 2012 17:44:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cit-0002fI-O4; Thu, 23 Feb 2012 17:44:55 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cit-0006b5-FT;
	Thu, 23 Feb 2012 17:44:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
Message-ID: <1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:52 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05 of 10] arm: More SMP bringup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
# Parent  8f322ab538572e1a12c8ed716ddd5cb4c122e9ed
arm: More SMP bringup

Bring non-boot CPUs up as far as running on the relocated pagetables,
one at a time, before the non-relocated copy of Xen gets reused for
general memory pools.

Don't yet bring them up into C; that will happen later when stacks are
allocated.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -248,7 +248,7 @@ static void __cpuinit gic_hyp_init(void)
 }
 
 /* Set up the GIC */
-void gic_init(void)
+int __init gic_init(void)
 {
     /* XXX FIXME get this from devicetree */
     gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
@@ -270,6 +270,8 @@ void gic_init(void)
     gic_hyp_init();
 
     spin_unlock(&gic.lock);
+
+    return gic.cpus;
 }
 
 void gic_route_irqs(void)
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/gic.h
--- a/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
@@ -138,8 +138,8 @@ extern int gic_route_irq_to_guest(struct
 
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
-/* Bring up the interrupt controller */
-extern void gic_init(void);
+/* Bring up the interrupt controller, and report # cpus attached */
+extern int gic_init(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
 #endif
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
@@ -62,22 +62,36 @@ start:
 #endif
 
 	/* Are we the boot CPU? */
+	mov   r12, #0                /* r12 := CPU ID */
 	mrc   CP32(r0, MPIDR)
 	tst   r0, #(1<<31)           /* Multiprocessor extension supported? */
 	beq   boot_cpu
 	tst   r0, #(1<<30)           /* Uniprocessor system? */
 	bne   boot_cpu
-	bics  r0, r0, #(0xff << 24)  /* Ignore flags */
-	beq   boot_cpu               /* If all other fields are 0, we win */
+	bics  r12, r0, #(0xff << 24) /* Mask out flags to get CPU ID */
+	beq   boot_cpu               /* If we're CPU 0, boot now */
 
-1:	wfi
-	b     1b
-	
+	/* Non-boot CPUs wait here to be woken up one at a time.
+	 * This is basically an open-coded spin-lock to serialize. */
+	ldr   r0, =boot_gate         /* VA of gate */
+	add   r0, r0, r10            /* PA of gate */
+	mov   r1, #1                 /* (1 == locked) */
+1:	wfe
+	ldrex r2, [r0]               /* Linked read of current value */
+	teq   r2, #0                 /* (0 == unlocked) */
+	strexeq r2, r1, [r0]         /* Matching update -> locked */
+	teq   r2, #0                 /* (0 == succeeded) */
+	bne   1b
+
 boot_cpu:
 #ifdef EARLY_UART_ADDRESS
-	/* Say hello */
 	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
-	bl    init_uart
+	teq   r12, #0                   /* CPU 0 sets up the UART too */
+	bleq  init_uart
+	PRINT("- CPU ")
+	mov   r0, r12
+	bl    putn
+	PRINT(" booting -\r\n")
 #endif
 
 	/* Check that this CPU has Hyp mode */
@@ -85,7 +99,6 @@ boot_cpu:
 	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
 	teq   r0, #0x1000            /* Must == 0x1 or may be incompatible */
 	beq   1f
-	bl    putn
 	PRINT("- CPU doesn't support the virtualization extensions -\r\n")
 	b     fail
 1:
@@ -185,6 +198,10 @@ hyp:
 	mov   r5, #0                 /* r4:r5 is paddr (xen_pagetable) */
 	mcrr  CP64(r4, r5, HTTBR)
 
+	/* Non-boot CPUs don't need to rebuild the pagetable */
+	teq   r12, #0
+	bne   pt_ready
+	
 	/* Build the baseline idle pagetable's first-level entries */
 	ldr   r1, =xen_second
 	add   r1, r1, r10            /* r1 := paddr (xen_second) */
@@ -226,6 +243,7 @@ hyp:
 	add   r4, r4, #8
 	strd  r2, r3, [r1, r4]       /* Map it in the early boot slot */
 
+pt_ready:
 	PRINT("- Turning on paging -\r\n")
 
 	ldr   r1, =paging            /* Explicit vaddr, not RIP-relative */
@@ -238,7 +256,7 @@ hyp:
 paging:
 
 #ifdef EARLY_UART_ADDRESS
-	/* Recover the UART address in the new address space */
+	/* Recover the UART address in the new address space. */
 	lsl   r11, #11
 	lsr   r11, #11               /* UART base's offset from 2MB base */
 	adr   r0, start
@@ -246,14 +264,57 @@ paging:
 	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
 #endif
 
-	PRINT("- Entering C -\r\n")
+	PRINT("- Ready -\r\n")
 
+	/* The boot CPU should go straight into C now */
+	teq   r12, #0
+	beq   launch
+
+	/* Signal the next non-boot CPU to come and join us here */
+	ldr   r0, =boot_gate         /* VA of gate */
+	add   r0, r0, r10            /* PA of gate */
+	mov   r1, #0                 /* (0 == unlocked) */
+	str   r1, [r0]
+	dsb
+	isb
+	sev
+
+	/* Move on to the relocated pagetables */
+	mov   r0, #0
+	ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
+	add   r4, r4, r10            /* PA of it */
+	ldrd  r4, r5, [r4]           /* Actual value */
+	mcrr  CP64(r4, r5, HTTBR)
+	mcr   CP32(r0, TLBIALLH)     /* Flush hypervisor TLB */
+	mcr   CP32(r0, BPIALL)       /* Flush branch predictor */
+	dsb                          /* Ensure completion of TLB+BP flush */
+	isb
+ 	/* Now, the UART is in its proper fixmap address */
+	ldrne r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+
+	/* Non-boot CPUs report that they've got this far */
+	ldr   r0, =ready_cpus
+	ldr   r1, [r0]               /* Read count of ready CPUs */
+	add   r1, r1, #1             /* ++ */
+	str   r1, [r0]               /* Writeback */
+	dsb
+
+	/* Here, the non-boot CPUs must wait again -- they're now running on
+	 * the boot CPU's pagetables so it's safe for the boot CPU to
+	 * overwrite the non-relocated copy of Xen.  Once it's done that,
+	 * and brought up the memory allocator, non-boot CPUs can get their
+	 * own stacks and enter C. */
+1:	wfe
+	b 1b
+
+launch:	
 	ldr   sp, =init_stack        /* Supply a stack */
 	add   sp, #STACK_SIZE        /* (which grows down from the top). */
 	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
 	mov   r0, r10                /* Marshal args: - phys_offset */
 	mov   r1, r7                 /*               - machine type */
 	mov   r2, r8                 /*               - ATAG address */
+	mov   r3, r12                /*               - CPU ID */
 	b     start_xen              /* and disappear into the land of C */
 
 /* Fail-stop
@@ -288,7 +349,7 @@ puts:
 	tst   r2, #0x8               /* Check BUSY bit */
 	bne   puts                   /* Wait for the UART to be ready */
 	ldrb  r2, [r0], #1           /* Load next char */
-	teq   r2, #0                 /* Exit on nul*/
+	teq   r2, #0                 /* Exit on nul */
 	moveq pc, lr
 	str   r2, [r11]              /* -> UARTDR (Data Register) */
 	b     puts
@@ -308,10 +369,8 @@ 1:	ldr   r2, [r11, #0x18]       /* <- UA
 	lsl   r0, #4                 /* Roll it through one nybble at a time */
 	subs  r3, r3, #1
 	bne   1b
-	adr   r0, crlf               /* Finish with a newline */
-	b     puts
+	mov   pc, lr
 
-crlf:	.asciz "\r\n"
 hex:	.ascii "0123456789abcdef"
 	.align 2
 
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 23 17:39:59 2012 +0000
@@ -36,6 +36,9 @@ lpae_t xen_second[LPAE_ENTRIES*4] __attr
 static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
+/* Non-boot CPUs use this to find the correct pagetables. */
+uint64_t boot_httbr;
+
 /* Limits of the Xen heap */
 unsigned long xenheap_mfn_start, xenheap_mfn_end;
 unsigned long xenheap_virt_end;
@@ -156,14 +159,6 @@ void __init setup_pagetables(unsigned lo
     lpae_t pte, *p;
     int i;
 
-    if ( boot_phys_offset != 0 )
-    {
-        /* Remove the old identity mapping of the boot paddr */
-        pte.bits = 0;
-        dest_va = (unsigned long)_start + boot_phys_offset;
-        write_pte(xen_second + second_linear_offset(dest_va), pte);
-    }
-
     xen_paddr = device_tree_get_xen_paddr();
 
     /* Map the destination in the boot misc area. */
@@ -186,11 +181,19 @@ void __init setup_pagetables(unsigned lo
     for ( i = 0; i < 4; i++)
         p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
     p = (void *) xen_second + dest_va - (unsigned long) _start;
+    if ( boot_phys_offset != 0 )
+    {
+        /* Remove the old identity mapping of the boot paddr */
+        pte.bits = 0;
+        dest_va = (unsigned long)_start + boot_phys_offset;
+        p[second_linear_offset(dest_va)] = pte;
+    }
     for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
         if ( p[i].pt.valid )
                 p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
 
     /* Change pagetables to the copy in the relocated Xen */
+    boot_httbr = (unsigned long) xen_pgtable + phys_offset;
     asm volatile (
         STORE_CP64(0, HTTBR)          /* Change translation base */
         "dsb;"                        /* Ensure visibility of HTTBR update */
@@ -198,7 +201,7 @@ void __init setup_pagetables(unsigned lo
         STORE_CP32(0, BPIALL)         /* Flush branch predictor */
         "dsb;"                        /* Ensure completion of TLB+BP flush */
         "isb;"
-        : : "r" ((unsigned long) xen_pgtable + phys_offset) : "memory");
+        : : "r" (boot_httbr) : "memory");
 
     /* Undo the temporary map */
     pte.bits = 0;
diff -r 8f322ab53857 -r 1e9c6bd7cc99 xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
@@ -44,7 +44,12 @@ static unsigned int __initdata max_cpus 
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
-extern char __init_begin[], __init_end[], __bss_start[];
+extern const char __init_begin[], __init_end[], __bss_start[];
+
+/* Spinlock for serializing CPU bringup */
+unsigned long __initdata boot_gate = 1;
+/* Number of non-boot CPUs ready to enter C */
+unsigned long __initdata ready_cpus = 0;
 
 static __attribute_used__ void init_done(void)
 {
@@ -151,14 +156,17 @@ static void __init setup_mm(unsigned lon
     end_boot_allocator();
 }
 
+/* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
-                      unsigned long atag_paddr)
-
+                      unsigned long atag_paddr,
+                      unsigned long cpuid)
 {
     void *fdt;
     size_t fdt_size;
-    int i;
+    int cpus, i;
+    paddr_t gate_pa;
+    unsigned long *gate;
 
     fdt = (void *)BOOT_MISC_VIRT_START
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
@@ -174,6 +182,22 @@ void __init start_xen(unsigned long boot
     console_init_preirq();
 #endif
 
+    cpus = gic_init();
+
+    printk("Waiting for %i other CPUs to be ready\n", cpus - 1);
+    /* Bring the other CPUs up to paging before the original
+     * copy of .text gets overwritten.  We need to use the unrelocated
+     * copy of boot_gate as that's the one the others can see. */ 
+    gate_pa = ((unsigned long) &boot_gate) + boot_phys_offset;
+    gate = map_domain_page(gate_pa >> PAGE_SHIFT) + (gate_pa & ~PAGE_MASK); 
+    *gate = 0;
+    unmap_domain_page(gate);
+    /* Now send an event to wake the first non-boot CPU */
+    asm volatile("dsb; isb; sev");
+    /* And wait for them all to be ready. */
+    while ( ready_cpus + 1 < cpus )
+        smp_rmb();
+
     __set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
     set_processor_id(0); /* needed early, for smp_processor_id() */
@@ -208,8 +232,6 @@ void __init start_xen(unsigned long boot
 
     init_IRQ();
 
-    gic_init();
-
     gic_route_irqs();
 
     init_maintenance_interrupt();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cix-0007GP-EE; Thu, 23 Feb 2012 17:44:59 +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 1S0civ-0007Fq-RC
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25668 invoked from network); 23 Feb 2012 17:44:31 -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;
	23 Feb 2012 17:44:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387643"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:54 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cis-0002f6-K8; Thu, 23 Feb 2012 17:44:54 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006ao-Bb;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4a7c1420913135fbeba361cd9603e748c074cdac
Message-ID: <4a7c1420913135fbeba3.1330018848@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:48 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01 of 10] arm: strip xen binary
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 4a7c1420913135fbeba361cd9603e748c074cdac
# Parent  0c3d19f40ab145d101de84051c3e00eef17fa1cb
arm: strip xen binary

The symbols in it are wrong anyway and will only confuse people
who ought to be looking at xen-syms.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 0c3d19f40ab1 -r 4a7c14209131 xen/arch/arm/Makefile
--- a/xen/arch/arm/Makefile	Mon Feb 20 22:16:32 2012 +0100
+++ b/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
@@ -40,7 +40,7 @@ ALL_OBJS := head.o $(ALL_OBJS)
 	# 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 $< $@
-	# XXX strip it
+	$(STRIP) $@
 
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
 #	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cj0-0007IT-JY; Thu, 23 Feb 2012 17:45:02 +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 1S0cix-0007GN-Q1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:21967] by server-10.bemta-5.messagelabs.com id
	67/36-06263-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330019096!16335791!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4600 invoked from network); 23 Feb 2012 17:44:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165478"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cit-0002fF-FC; Thu, 23 Feb 2012 17:44:55 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cit-0006b0-6V;
	Thu, 23 Feb 2012 17:44:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8f322ab538572e1a12c8ed716ddd5cb4c122e9ed
Message-ID: <8f322ab538572e1a12c8.1330018851@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:51 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04 of 10] arm: Handle booting on SMP platforms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 8f322ab538572e1a12c8ed716ddd5cb4c122e9ed
# Parent  437ad1207a175c9ad376871f3f4c075dbcd5b6e6
arm: Handle booting on SMP platforms

Make all non-boot CPUs wait forever instead of trying to boot in parallel.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 437ad1207a17 -r 8f322ab53857 xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
@@ -61,6 +61,19 @@ start:
 	add   r8, r10                /* r8 := paddr(DTB) */
 #endif
 
+	/* Are we the boot CPU? */
+	mrc   CP32(r0, MPIDR)
+	tst   r0, #(1<<31)           /* Multiprocessor extension supported? */
+	beq   boot_cpu
+	tst   r0, #(1<<30)           /* Uniprocessor system? */
+	bne   boot_cpu
+	bics  r0, r0, #(0xff << 24)  /* Ignore flags */
+	beq   boot_cpu               /* If all other fields are 0, we win */
+
+1:	wfi
+	b     1b
+	
+boot_cpu:
 #ifdef EARLY_UART_ADDRESS
 	/* Say hello */
 	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff -r 437ad1207a17 -r 8f322ab53857 xen/include/asm-arm/cpregs.h
--- a/xen/include/asm-arm/cpregs.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/cpregs.h	Thu Feb 23 17:39:59 2012 +0000
@@ -91,6 +91,7 @@
 /* Coprocessor 15 */
 
 /* CP15 CR0: CPUID and Cache Type Registers */
+#define MPIDR           p15,0,c0,c0,5   /* Multiprocessor Affinity Register */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
 #define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cj0-0007IT-JY; Thu, 23 Feb 2012 17:45:02 +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 1S0cix-0007GN-Q1
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:21967] by server-10.bemta-5.messagelabs.com id
	67/36-06263-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330019096!16335791!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4600 invoked from network); 23 Feb 2012 17:44:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165478"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cit-0002fF-FC; Thu, 23 Feb 2012 17:44:55 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cit-0006b0-6V;
	Thu, 23 Feb 2012 17:44:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8f322ab538572e1a12c8ed716ddd5cb4c122e9ed
Message-ID: <8f322ab538572e1a12c8.1330018851@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:51 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04 of 10] arm: Handle booting on SMP platforms
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 8f322ab538572e1a12c8ed716ddd5cb4c122e9ed
# Parent  437ad1207a175c9ad376871f3f4c075dbcd5b6e6
arm: Handle booting on SMP platforms

Make all non-boot CPUs wait forever instead of trying to boot in parallel.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 437ad1207a17 -r 8f322ab53857 xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
@@ -61,6 +61,19 @@ start:
 	add   r8, r10                /* r8 := paddr(DTB) */
 #endif
 
+	/* Are we the boot CPU? */
+	mrc   CP32(r0, MPIDR)
+	tst   r0, #(1<<31)           /* Multiprocessor extension supported? */
+	beq   boot_cpu
+	tst   r0, #(1<<30)           /* Uniprocessor system? */
+	bne   boot_cpu
+	bics  r0, r0, #(0xff << 24)  /* Ignore flags */
+	beq   boot_cpu               /* If all other fields are 0, we win */
+
+1:	wfi
+	b     1b
+	
+boot_cpu:
 #ifdef EARLY_UART_ADDRESS
 	/* Say hello */
 	ldr   r11, =EARLY_UART_ADDRESS  /* r11 := UART base address */
diff -r 437ad1207a17 -r 8f322ab53857 xen/include/asm-arm/cpregs.h
--- a/xen/include/asm-arm/cpregs.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/cpregs.h	Thu Feb 23 17:39:59 2012 +0000
@@ -91,6 +91,7 @@
 /* Coprocessor 15 */
 
 /* CP15 CR0: CPUID and Cache Type Registers */
+#define MPIDR           p15,0,c0,c0,5   /* Multiprocessor Affinity Register */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
 #define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj0-0007Ii-VL; Thu, 23 Feb 2012 17:45:02 +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 1S0cix-0007GO-Vd
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25890 invoked from network); 23 Feb 2012 17:44:34 -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;
	23 Feb 2012 17:44:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387647"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:57 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:57 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0civ-0002fX-5X; Thu, 23 Feb 2012 17:44:57 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bP-TE;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8a2d38ab67ccaf8637e223feb0d0678433974e93
Message-ID: <8a2d38ab67ccaf8637e2.1330018857@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:57 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10 of 10] arm: Shutdown and reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID 8a2d38ab67ccaf8637e223feb0d0678433974e93
# Parent  a78bc9b8421492e0545c6d52c7a32b9de9737d61
arm: Shutdown and reboot

Reboot runes grabbed from linux's SP810 reset function.
Doesn't seem to work on the model, though.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a78bc9b84214 -r 8a2d38ab67cc xen/arch/arm/shutdown.c
--- a/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
@@ -1,18 +1,63 @@
 #include <xen/config.h>
+#include <xen/console.h>
+#include <xen/cpu.h>
+#include <xen/delay.h>
 #include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+
+static void raw_machine_reset(void)
+{
+#ifdef SP810_ADDRESS
+    /* Use the SP810 system controller to force a reset */
+    volatile uint32_t *sp810;
+    set_fixmap(FIXMAP_MISC, SP810_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    sp810 = ((uint32_t *)
+             (FIXMAP_ADDR(FIXMAP_MISC) + (SP810_ADDRESS & ~PAGE_MASK)));
+    sp810[0] = 0x3; /* switch to slow mode */
+    dsb(); isb();
+    sp810[1] = 0x1; /* writing any value to SCSYSSTAT reg will reset system */
+    dsb(); isb();
+    clear_fixmap(FIXMAP_MISC);
+#endif
+}
+
+static void halt_this_cpu(void *arg)
+{
+    __cpu_disable();
+    stop_cpu();
+}
 
 void machine_halt(void)
 {
-        /* TODO: halt */
-        while(1) ;
+    watchdog_disable();
+    console_start_sync();
+    local_irq_enable();
+    smp_call_function(halt_this_cpu, NULL, 0);
+    halt_this_cpu(NULL);
 }
 
 void machine_restart(unsigned int delay_millisecs)
 {
-        /* TODO: restart */
-        printk("Cannot restart yet\n");
-        while(1);
+    int timeout = 10;
+
+    local_irq_enable();
+    smp_call_function(halt_this_cpu, NULL, 0);
+    local_irq_disable();
+
+    mdelay(delay_millisecs);
+
+    /* Wait at most another 10ms for all other CPUs to go offline. */
+    while ( (num_online_cpus() > 1) && (timeout-- > 0) )
+        mdelay(1);
+
+    while ( 1 )
+    {
+        raw_machine_reset();
+        mdelay(100);
+    }
 }
+
 /*
  * Local variables:
  * mode: C
diff -r a78bc9b84214 -r 8a2d38ab67cc xen/include/asm-arm/config.h
--- a/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
@@ -119,6 +119,9 @@ extern unsigned long frametable_virt_end
 #define GIC_CR_OFFSET 0x2000
 #define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
 #define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+/* Board-specific: base address of system controller */
+#define SP810_ADDRESS 0x1C020000
+
 
 #endif /* __ARM_CONFIG_H__ */
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj1-0007JZ-OJ; Thu, 23 Feb 2012 17:45:03 +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 1S0ciy-0007GY-3A
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:62623] by server-8.bemta-5.messagelabs.com id
	B5/B3-09797-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330019097!16312807!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23216 invoked from network); 23 Feb 2012 17:44:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387646"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:56 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fO-9j; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bD-1D;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: fd78d23ba19de4129e21cdc7303848b105057227
Message-ID: <fd78d23ba19de4129e21.1330018854@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:54 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07 of 10] arm: start plumbing in SMP bringup 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

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID fd78d23ba19de4129e21cdc7303848b105057227
# Parent  3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
arm: start plumbing in SMP bringup in C

Still a noop, but no longer just a dummy symbol.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
@@ -7,9 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruc
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(__cpu_die);
-DUMMY(__cpu_disable);
-DUMMY(__cpu_up);
 DUMMY(per_cpu__cpu_core_mask);
 DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
@@ -38,9 +38,6 @@
 #include <asm/setup.h>
 #include "gic.h"
 
-/* maxcpus: maximum number of CPUs to activate. */
-static unsigned int __initdata max_cpus = NR_CPUS;
-
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
@@ -206,7 +203,7 @@ void __init start_xen(unsigned long boot
     cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
     cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
 
-    smp_prepare_cpus(max_cpus);
+    smp_prepare_cpus(cpus);
 
     init_xen_time();
 
@@ -253,7 +250,7 @@ void __init start_xen(unsigned long boot
 
     for_each_present_cpu ( i )
     {
-        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        if ( (num_online_cpus() < cpus) && !cpu_online(i) )
         {
             int ret = cpu_up(i);
             if ( ret != 0 )
diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
@@ -19,6 +19,7 @@
 #include <xen/cpumask.h>
 #include <xen/smp.h>
 #include <xen/init.h>
+#include <xen/errno.h>
 
 cpumask_t cpu_online_map;
 EXPORT_SYMBOL(cpu_online_map);
@@ -30,16 +31,40 @@ EXPORT_SYMBOL(cpu_possible_map);
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
 {
-        set_processor_id(0); /* needed early, for smp_processor_id() */
+    int i;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
 
-        cpumask_clear(&cpu_online_map);
-        cpumask_clear(&cpu_present_map);
-        cpumask_clear(&cpu_possible_map);
-        cpumask_set_cpu(0, &cpu_online_map);
-        cpumask_set_cpu(0, &cpu_present_map);
-        cpumask_set_cpu(0, &cpu_possible_map);
-        return;
+    cpumask_clear(&cpu_online_map);
+    cpumask_set_cpu(0, &cpu_online_map);
+
+    cpumask_clear(&cpu_possible_map);
+    for ( i = 0; i < max_cpus; i++ )
+        cpumask_set_cpu(i, &cpu_possible_map);
+    cpumask_copy(&cpu_present_map, &cpu_possible_map);
 }
+
+/* Bring up a non-boot CPU */
+int __cpu_up(unsigned int cpu)
+{
+    /* Not yet... */
+    return -ENODEV;
+}
+
+/* Shut down the current CPU */
+void __cpu_disable(void)
+{
+    /* TODO: take down timers, GIC, &c. */
+    BUG();
+}
+
+/* Wait for a remote CPU to die */
+void __cpu_die(unsigned int cpu)
+{
+    /* TODO: interlock with __cpu_disable */
+    BUG();
+}
+
+
 /*
  * Local variables:
  * mode: C

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj0-0007Ii-VL; Thu, 23 Feb 2012 17:45:02 +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 1S0cix-0007GO-Vd
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25890 invoked from network); 23 Feb 2012 17:44:34 -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;
	23 Feb 2012 17:44:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387647"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:57 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:57 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0civ-0002fX-5X; Thu, 23 Feb 2012 17:44:57 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bP-TE;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: 8a2d38ab67ccaf8637e223feb0d0678433974e93
Message-ID: <8a2d38ab67ccaf8637e2.1330018857@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:57 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10 of 10] arm: Shutdown and reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID 8a2d38ab67ccaf8637e223feb0d0678433974e93
# Parent  a78bc9b8421492e0545c6d52c7a32b9de9737d61
arm: Shutdown and reboot

Reboot runes grabbed from linux's SP810 reset function.
Doesn't seem to work on the model, though.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a78bc9b84214 -r 8a2d38ab67cc xen/arch/arm/shutdown.c
--- a/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
@@ -1,18 +1,63 @@
 #include <xen/config.h>
+#include <xen/console.h>
+#include <xen/cpu.h>
+#include <xen/delay.h>
 #include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/smp.h>
+
+static void raw_machine_reset(void)
+{
+#ifdef SP810_ADDRESS
+    /* Use the SP810 system controller to force a reset */
+    volatile uint32_t *sp810;
+    set_fixmap(FIXMAP_MISC, SP810_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    sp810 = ((uint32_t *)
+             (FIXMAP_ADDR(FIXMAP_MISC) + (SP810_ADDRESS & ~PAGE_MASK)));
+    sp810[0] = 0x3; /* switch to slow mode */
+    dsb(); isb();
+    sp810[1] = 0x1; /* writing any value to SCSYSSTAT reg will reset system */
+    dsb(); isb();
+    clear_fixmap(FIXMAP_MISC);
+#endif
+}
+
+static void halt_this_cpu(void *arg)
+{
+    __cpu_disable();
+    stop_cpu();
+}
 
 void machine_halt(void)
 {
-        /* TODO: halt */
-        while(1) ;
+    watchdog_disable();
+    console_start_sync();
+    local_irq_enable();
+    smp_call_function(halt_this_cpu, NULL, 0);
+    halt_this_cpu(NULL);
 }
 
 void machine_restart(unsigned int delay_millisecs)
 {
-        /* TODO: restart */
-        printk("Cannot restart yet\n");
-        while(1);
+    int timeout = 10;
+
+    local_irq_enable();
+    smp_call_function(halt_this_cpu, NULL, 0);
+    local_irq_disable();
+
+    mdelay(delay_millisecs);
+
+    /* Wait at most another 10ms for all other CPUs to go offline. */
+    while ( (num_online_cpus() > 1) && (timeout-- > 0) )
+        mdelay(1);
+
+    while ( 1 )
+    {
+        raw_machine_reset();
+        mdelay(100);
+    }
 }
+
 /*
  * Local variables:
  * mode: C
diff -r a78bc9b84214 -r 8a2d38ab67cc xen/include/asm-arm/config.h
--- a/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
@@ -119,6 +119,9 @@ extern unsigned long frametable_virt_end
 #define GIC_CR_OFFSET 0x2000
 #define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
 #define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
+/* Board-specific: base address of system controller */
+#define SP810_ADDRESS 0x1C020000
+
 
 #endif /* __ARM_CONFIG_H__ */
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj1-0007JZ-OJ; Thu, 23 Feb 2012 17:45:03 +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 1S0ciy-0007GY-3A
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:62623] by server-8.bemta-5.messagelabs.com id
	B5/B3-09797-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330019097!16312807!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23216 invoked from network); 23 Feb 2012 17:44:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387646"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:56 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fO-9j; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bD-1D;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: fd78d23ba19de4129e21cdc7303848b105057227
Message-ID: <fd78d23ba19de4129e21.1330018854@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:54 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07 of 10] arm: start plumbing in SMP bringup 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

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID fd78d23ba19de4129e21cdc7303848b105057227
# Parent  3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
arm: start plumbing in SMP bringup in C

Still a noop, but no longer just a dummy symbol.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
@@ -7,9 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruc
 x:	mov pc, lr
 	
 /* SMP support */
-DUMMY(__cpu_die);
-DUMMY(__cpu_disable);
-DUMMY(__cpu_up);
 DUMMY(per_cpu__cpu_core_mask);
 DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
@@ -38,9 +38,6 @@
 #include <asm/setup.h>
 #include "gic.h"
 
-/* maxcpus: maximum number of CPUs to activate. */
-static unsigned int __initdata max_cpus = NR_CPUS;
-
 /* Xen stack for bringing up the first CPU. */
 unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
 
@@ -206,7 +203,7 @@ void __init start_xen(unsigned long boot
     cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
     cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
 
-    smp_prepare_cpus(max_cpus);
+    smp_prepare_cpus(cpus);
 
     init_xen_time();
 
@@ -253,7 +250,7 @@ void __init start_xen(unsigned long boot
 
     for_each_present_cpu ( i )
     {
-        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+        if ( (num_online_cpus() < cpus) && !cpu_online(i) )
         {
             int ret = cpu_up(i);
             if ( ret != 0 )
diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
@@ -19,6 +19,7 @@
 #include <xen/cpumask.h>
 #include <xen/smp.h>
 #include <xen/init.h>
+#include <xen/errno.h>
 
 cpumask_t cpu_online_map;
 EXPORT_SYMBOL(cpu_online_map);
@@ -30,16 +31,40 @@ EXPORT_SYMBOL(cpu_possible_map);
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
 {
-        set_processor_id(0); /* needed early, for smp_processor_id() */
+    int i;
+    set_processor_id(0); /* needed early, for smp_processor_id() */
 
-        cpumask_clear(&cpu_online_map);
-        cpumask_clear(&cpu_present_map);
-        cpumask_clear(&cpu_possible_map);
-        cpumask_set_cpu(0, &cpu_online_map);
-        cpumask_set_cpu(0, &cpu_present_map);
-        cpumask_set_cpu(0, &cpu_possible_map);
-        return;
+    cpumask_clear(&cpu_online_map);
+    cpumask_set_cpu(0, &cpu_online_map);
+
+    cpumask_clear(&cpu_possible_map);
+    for ( i = 0; i < max_cpus; i++ )
+        cpumask_set_cpu(i, &cpu_possible_map);
+    cpumask_copy(&cpu_present_map, &cpu_possible_map);
 }
+
+/* Bring up a non-boot CPU */
+int __cpu_up(unsigned int cpu)
+{
+    /* Not yet... */
+    return -ENODEV;
+}
+
+/* Shut down the current CPU */
+void __cpu_disable(void)
+{
+    /* TODO: take down timers, GIC, &c. */
+    BUG();
+}
+
+/* Wait for a remote CPU to die */
+void __cpu_die(unsigned int cpu)
+{
+    /* TODO: interlock with __cpu_disable */
+    BUG();
+}
+
+
 /*
  * Local variables:
  * mode: C

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj2-0007KZ-L2; Thu, 23 Feb 2012 17:45:04 +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 1S0ciz-0007Ft-B7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25714 invoked from network); 23 Feb 2012 17:44:32 -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;
	23 Feb 2012 17:44:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387644"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cit-0002fC-6Q; Thu, 23 Feb 2012 17:44:55 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006aw-TC;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
Message-ID: <437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:50 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor init
 out of the per-CPU init 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

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
# Parent  ec051056db2b6d37344629e2f01d17240099d5ec
arm: Move some GIC distributor init out of the per-CPU init function

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
     for ( i = 32; i < gic.lines; i += 32 )
         GICD[GICD_ICENABLER + i / 32] = ~0ul;
 
-    /* Turn on the distributor */
-    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
-}
-
-static void __cpuinit gic_cpu_init(void)
-{
-    int i;
-
     /* Disable all PPI and enable all SGI */
     GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
     GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
@@ -231,6 +223,12 @@ static void __cpuinit gic_cpu_init(void)
     for (i = 0; i < 32; i += 4)
         GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
 
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
     /* Local settings: interface controller */
     GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
     GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj2-0007KZ-L2; Thu, 23 Feb 2012 17:45:04 +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 1S0ciz-0007Ft-B7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330019070!54196593!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25714 invoked from network); 23 Feb 2012 17:44:32 -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;
	23 Feb 2012 17:44:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387644"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cit-0002fC-6Q; Thu, 23 Feb 2012 17:44:55 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006aw-TC;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
Message-ID: <437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:50 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor init
 out of the per-CPU init 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

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
# Parent  ec051056db2b6d37344629e2f01d17240099d5ec
arm: Move some GIC distributor init out of the per-CPU init function

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
     for ( i = 32; i < gic.lines; i += 32 )
         GICD[GICD_ICENABLER + i / 32] = ~0ul;
 
-    /* Turn on the distributor */
-    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
-}
-
-static void __cpuinit gic_cpu_init(void)
-{
-    int i;
-
     /* Disable all PPI and enable all SGI */
     GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
     GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
@@ -231,6 +223,12 @@ static void __cpuinit gic_cpu_init(void)
     for (i = 0; i < 32; i += 4)
         GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
 
+    /* Turn on the distributor */
+    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
+}
+
+static void __cpuinit gic_cpu_init(void)
+{
     /* Local settings: interface controller */
     GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
     GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj2-0007Jx-42; Thu, 23 Feb 2012 17:45:04 +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 1S0ciy-0007Gq-FD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:62645] by server-9.bemta-5.messagelabs.com id
	87/FF-30171-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330019096!16335791!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4629 invoked from network); 23 Feb 2012 17:44:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165484"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:57 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:57 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fU-St; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bL-Jk;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: a78bc9b8421492e0545c6d52c7a32b9de9737d61
Message-ID: <a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:56 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09 of 10] arm: SMP CPU 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

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID a78bc9b8421492e0545c6d52c7a32b9de9737d61
# Parent  d35b52e5fde829dfbaf3da73e0716d004faded2f
arm: SMP CPU shutdown

For completeness, also implelent the CPU shutdown path.

Signed-off-by: TIm Deegan <tim@xen.org>

diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/domain.c
--- a/xen/arch/arm/domain.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/domain.c	Thu Feb 23 17:39:59 2012 +0000
@@ -31,12 +31,10 @@ void idle_loop(void)
 {
     for ( ; ; )
     {
-        /* TODO
-           if ( cpu_is_offline(smp_processor_id()) )
-           play_dead();
-           (*pm_idle)();
-           BUG();
-        */
+        if ( cpu_is_offline(smp_processor_id()) )
+            stop_cpu();
+
+        /* TODO: (*pm_idle)(); */
         do_tasklet();
         do_softirq();
     }
diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -235,6 +235,11 @@ static void __cpuinit gic_cpu_init(void)
     GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
 }
 
+static void gic_cpu_disable(void)
+{
+    GICC[GICC_CTLR] = 0;
+}
+
 static void __cpuinit gic_hyp_init(void)
 {
     uint32_t vtr;
@@ -246,6 +251,11 @@ static void __cpuinit gic_hyp_init(void)
     GICH[GICH_MISR] = GICH_MISR_EOI;
 }
 
+static void __cpuinit gic_hyp_disable(void)
+{
+    GICH[GICH_HCR] = 0;
+}
+
 /* Set up the GIC */
 int __init gic_init(void)
 {
@@ -282,6 +292,15 @@ void __cpuinit gic_init_secondary_cpu(vo
     spin_unlock(&gic.lock);
 }
 
+/* Shut down the per-CPU GIC interface */
+void gic_disable_cpu(void)
+{
+    spin_lock(&gic.lock);
+    gic_cpu_disable();
+    gic_hyp_disable();
+    spin_unlock(&gic.lock);
+}
+
 void gic_route_irqs(void)
 {
     /* XXX should get these from DT */
diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/gic.h
--- a/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
@@ -142,6 +142,8 @@ extern void gic_interrupt(struct cpu_use
 extern int gic_init(void);
 /* Bring up a secondary CPU's per-CPU GIC interface */
 extern void gic_init_secondary_cpu(void);
+/* Take down a CPU's per-CPU GIC interface */
+extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
 #endif
diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
@@ -18,6 +18,7 @@
 
 #include <xen/cpu.h>
 #include <xen/cpumask.h>
+#include <xen/delay.h>
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/mm.h>
@@ -58,6 +59,7 @@ smp_prepare_cpus (unsigned int max_cpus)
 
 /* Shared state for coordinating CPU bringup */
 unsigned long smp_up_cpu = 0;
+static bool_t cpu_is_dead = 0;
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
@@ -98,8 +100,35 @@ void __cpuinit start_secondary(unsigned 
 /* Shut down the current CPU */
 void __cpu_disable(void)
 {
-    /* TODO: take down timers, GIC, &c. */
-    BUG();
+    unsigned int cpu = get_processor_id();
+
+    local_irq_disable();
+    gic_disable_cpu();
+    /* Allow any queued timer interrupts to get serviced */
+    local_irq_enable();
+    mdelay(1);
+    local_irq_disable();
+
+    /* It's now safe to remove this processor from the online map */
+    cpumask_clear_cpu(cpu, &cpu_online_map);
+
+    if ( cpu_disable_scheduler(cpu) )
+        BUG();
+    mb();
+
+    /* Return to caller; eventually the IPI mecahnism will unwind and the 
+     * scheduler will drop to the idle loop, which will call stop_cpu(). */
+}
+
+void stop_cpu(void)
+{
+    local_irq_disable();
+    cpu_is_dead = 1;
+    /* Make sure the write happens before we sleep forever */
+    dsb();
+    isb();
+    while ( 1 ) 
+        asm volatile("wfi");
 }
 
 /* Bring up a remote CPU */
@@ -131,8 +160,19 @@ int __cpu_up(unsigned int cpu)
 /* Wait for a remote CPU to die */
 void __cpu_die(unsigned int cpu)
 {
-    /* TODO: interlock with __cpu_disable */
-    BUG();
+    unsigned int i = 0;
+
+    while ( !cpu_is_dead )
+    {
+        mdelay(100);
+        cpu_relax();
+        process_pending_softirqs();
+        if ( (++i % 10) == 0 )
+            printk(KERN_ERR "CPU %u still not dead...\n", cpu);
+        mb();
+    }
+    cpu_is_dead = 0;
+    mb();
 }
 
 
diff -r d35b52e5fde8 -r a78bc9b84214 xen/include/asm-arm/smp.h
--- a/xen/include/asm-arm/smp.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/smp.h	Thu Feb 23 17:39:59 2012 +0000
@@ -14,6 +14,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
 
 #define raw_smp_processor_id() (get_processor_id())
 
+extern void stop_cpu(void);
+
 #endif
 /*
  * Local variables:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj2-0007Jx-42; Thu, 23 Feb 2012 17:45:04 +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 1S0ciy-0007Gq-FD
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:62645] by server-9.bemta-5.messagelabs.com id
	87/FF-30171-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330019096!16335791!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4629 invoked from network); 23 Feb 2012 17:44:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165484"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:57 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:57 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fU-St; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bL-Jk;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: a78bc9b8421492e0545c6d52c7a32b9de9737d61
Message-ID: <a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:56 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09 of 10] arm: SMP CPU 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

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID a78bc9b8421492e0545c6d52c7a32b9de9737d61
# Parent  d35b52e5fde829dfbaf3da73e0716d004faded2f
arm: SMP CPU shutdown

For completeness, also implelent the CPU shutdown path.

Signed-off-by: TIm Deegan <tim@xen.org>

diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/domain.c
--- a/xen/arch/arm/domain.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/domain.c	Thu Feb 23 17:39:59 2012 +0000
@@ -31,12 +31,10 @@ void idle_loop(void)
 {
     for ( ; ; )
     {
-        /* TODO
-           if ( cpu_is_offline(smp_processor_id()) )
-           play_dead();
-           (*pm_idle)();
-           BUG();
-        */
+        if ( cpu_is_offline(smp_processor_id()) )
+            stop_cpu();
+
+        /* TODO: (*pm_idle)(); */
         do_tasklet();
         do_softirq();
     }
diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -235,6 +235,11 @@ static void __cpuinit gic_cpu_init(void)
     GICC[GICC_CTLR] = GICC_CTL_ENABLE|GICC_CTL_EOI;    /* Turn on delivery */
 }
 
+static void gic_cpu_disable(void)
+{
+    GICC[GICC_CTLR] = 0;
+}
+
 static void __cpuinit gic_hyp_init(void)
 {
     uint32_t vtr;
@@ -246,6 +251,11 @@ static void __cpuinit gic_hyp_init(void)
     GICH[GICH_MISR] = GICH_MISR_EOI;
 }
 
+static void __cpuinit gic_hyp_disable(void)
+{
+    GICH[GICH_HCR] = 0;
+}
+
 /* Set up the GIC */
 int __init gic_init(void)
 {
@@ -282,6 +292,15 @@ void __cpuinit gic_init_secondary_cpu(vo
     spin_unlock(&gic.lock);
 }
 
+/* Shut down the per-CPU GIC interface */
+void gic_disable_cpu(void)
+{
+    spin_lock(&gic.lock);
+    gic_cpu_disable();
+    gic_hyp_disable();
+    spin_unlock(&gic.lock);
+}
+
 void gic_route_irqs(void)
 {
     /* XXX should get these from DT */
diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/gic.h
--- a/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
@@ -142,6 +142,8 @@ extern void gic_interrupt(struct cpu_use
 extern int gic_init(void);
 /* Bring up a secondary CPU's per-CPU GIC interface */
 extern void gic_init_secondary_cpu(void);
+/* Take down a CPU's per-CPU GIC interface */
+extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
 #endif
diff -r d35b52e5fde8 -r a78bc9b84214 xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
@@ -18,6 +18,7 @@
 
 #include <xen/cpu.h>
 #include <xen/cpumask.h>
+#include <xen/delay.h>
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/mm.h>
@@ -58,6 +59,7 @@ smp_prepare_cpus (unsigned int max_cpus)
 
 /* Shared state for coordinating CPU bringup */
 unsigned long smp_up_cpu = 0;
+static bool_t cpu_is_dead = 0;
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
@@ -98,8 +100,35 @@ void __cpuinit start_secondary(unsigned 
 /* Shut down the current CPU */
 void __cpu_disable(void)
 {
-    /* TODO: take down timers, GIC, &c. */
-    BUG();
+    unsigned int cpu = get_processor_id();
+
+    local_irq_disable();
+    gic_disable_cpu();
+    /* Allow any queued timer interrupts to get serviced */
+    local_irq_enable();
+    mdelay(1);
+    local_irq_disable();
+
+    /* It's now safe to remove this processor from the online map */
+    cpumask_clear_cpu(cpu, &cpu_online_map);
+
+    if ( cpu_disable_scheduler(cpu) )
+        BUG();
+    mb();
+
+    /* Return to caller; eventually the IPI mecahnism will unwind and the 
+     * scheduler will drop to the idle loop, which will call stop_cpu(). */
+}
+
+void stop_cpu(void)
+{
+    local_irq_disable();
+    cpu_is_dead = 1;
+    /* Make sure the write happens before we sleep forever */
+    dsb();
+    isb();
+    while ( 1 ) 
+        asm volatile("wfi");
 }
 
 /* Bring up a remote CPU */
@@ -131,8 +160,19 @@ int __cpu_up(unsigned int cpu)
 /* Wait for a remote CPU to die */
 void __cpu_die(unsigned int cpu)
 {
-    /* TODO: interlock with __cpu_disable */
-    BUG();
+    unsigned int i = 0;
+
+    while ( !cpu_is_dead )
+    {
+        mdelay(100);
+        cpu_relax();
+        process_pending_softirqs();
+        if ( (++i % 10) == 0 )
+            printk(KERN_ERR "CPU %u still not dead...\n", cpu);
+        mb();
+    }
+    cpu_is_dead = 0;
+    mb();
 }
 
 
diff -r d35b52e5fde8 -r a78bc9b84214 xen/include/asm-arm/smp.h
--- a/xen/include/asm-arm/smp.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/smp.h	Thu Feb 23 17:39:59 2012 +0000
@@ -14,6 +14,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
 
 #define raw_smp_processor_id() (get_processor_id())
 
+extern void stop_cpu(void);
+
 #endif
 /*
  * Local variables:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj0-0007ID-72; Thu, 23 Feb 2012 17:45:02 +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 1S0cix-0007GH-J8
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:59 +0000
Received: from [85.158.139.83:62593] by server-3.bemta-5.messagelabs.com id
	24/B2-06438-A1B764F4; Thu, 23 Feb 2012 17:44:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330019095!16391455!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31903 invoked from network); 23 Feb 2012 17:44:57 -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;
	23 Feb 2012 17:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165477"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cis-0002f9-Sv; Thu, 23 Feb 2012 17:44:54 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006as-KO;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: ec051056db2b6d37344629e2f01d17240099d5ec
Message-ID: <ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:49 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02 of 10] arm: implement udelay()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID ec051056db2b6d37344629e2f01d17240099d5ec
# Parent  4a7c1420913135fbeba361cd9603e748c074cdac
arm: implement udelay()

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
@@ -62,5 +62,4 @@ DUMMY(gmfn_to_mfn);
 DUMMY(hypercall_create_continuation);
 DUMMY(send_timer_event);
 DUMMY(share_xen_page_with_privileged_guests);
-DUMMY(__udelay);
 DUMMY(wallclock_time);
diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/time.c
--- a/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
@@ -171,6 +171,16 @@ void __cpuinit init_timer_interrupt(void
     request_irq(30, timer_interrupt, 0, "phytimer", NULL);
 }
 
+/* Wait a set number of microseconds */
+void udelay(unsigned long usecs)
+{
+    s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
+    do {
+        dsb();
+        isb();
+    } while ( get_s_time() - deadline < 0 );
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 4a7c14209131 -r ec051056db2b xen/include/asm-arm/delay.h
--- a/xen/include/asm-arm/delay.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/delay.h	Thu Feb 23 17:39:59 2012 +0000
@@ -1,8 +1,7 @@
 #ifndef _ARM_DELAY_H
 #define _ARM_DELAY_H
 
-extern void __udelay(unsigned long usecs);
-#define udelay(n) __udelay(n)
+extern void udelay(unsigned long usecs);
 
 #endif /* defined(_ARM_DELAY_H) */
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj0-0007ID-72; Thu, 23 Feb 2012 17:45:02 +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 1S0cix-0007GH-J8
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:44:59 +0000
Received: from [85.158.139.83:62593] by server-3.bemta-5.messagelabs.com id
	24/B2-06438-A1B764F4; Thu, 23 Feb 2012 17:44:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330019095!16391455!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31903 invoked from network); 23 Feb 2012 17:44:57 -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;
	23 Feb 2012 17:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165477"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:55 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0cis-0002f9-Sv; Thu, 23 Feb 2012 17:44:54 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cis-0006as-KO;
	Thu, 23 Feb 2012 17:44:54 +0000
MIME-Version: 1.0
X-Mercurial-Node: ec051056db2b6d37344629e2f01d17240099d5ec
Message-ID: <ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:49 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02 of 10] arm: implement udelay()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID ec051056db2b6d37344629e2f01d17240099d5ec
# Parent  4a7c1420913135fbeba361cd9603e748c074cdac
arm: implement udelay()

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
@@ -62,5 +62,4 @@ DUMMY(gmfn_to_mfn);
 DUMMY(hypercall_create_continuation);
 DUMMY(send_timer_event);
 DUMMY(share_xen_page_with_privileged_guests);
-DUMMY(__udelay);
 DUMMY(wallclock_time);
diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/time.c
--- a/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
@@ -171,6 +171,16 @@ void __cpuinit init_timer_interrupt(void
     request_irq(30, timer_interrupt, 0, "phytimer", NULL);
 }
 
+/* Wait a set number of microseconds */
+void udelay(unsigned long usecs)
+{
+    s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
+    do {
+        dsb();
+        isb();
+    } while ( get_s_time() - deadline < 0 );
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 4a7c14209131 -r ec051056db2b xen/include/asm-arm/delay.h
--- a/xen/include/asm-arm/delay.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/delay.h	Thu Feb 23 17:39:59 2012 +0000
@@ -1,8 +1,7 @@
 #ifndef _ARM_DELAY_H
 #define _ARM_DELAY_H
 
-extern void __udelay(unsigned long usecs);
-#define udelay(n) __udelay(n)
+extern void udelay(unsigned long usecs);
 
 #endif /* defined(_ARM_DELAY_H) */
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj1-0007J3-BR; Thu, 23 Feb 2012 17:45:03 +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 1S0ciy-0007GH-3L
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:62631] by server-3.bemta-5.messagelabs.com id
	D8/B2-06438-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330019095!16391455!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31944 invoked from network); 23 Feb 2012 17:44:58 -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;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165481"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:56 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fL-10; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cit-0006b9-OH;
	Thu, 23 Feb 2012 17:44:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
Message-ID: <3b1d7a91a2596baca178.1330018853@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:53 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06 of 10] arm: per-cpu areas
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
# Parent  1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
arm: per-cpu areas

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/Makefile
--- a/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
@@ -13,6 +13,7 @@ obj-y += irq.o
 obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
+obj-y += percpu.o
 obj-y += guestcopy.o
 obj-y += setup.o
 obj-y += time.o
diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
@@ -14,7 +14,6 @@ DUMMY(per_cpu__cpu_core_mask);
 DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
-DUMMY(__per_cpu_offset);
 
 /* PIRQ support */
 DUMMY(alloc_pirq_struct);
diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/percpu.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/arch/arm/percpu.c	Thu Feb 23 17:39:59 2012 +0000
@@ -0,0 +1,85 @@
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <xen/cpu.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/rcupdate.h>
+
+unsigned long __per_cpu_offset[NR_CPUS];
+#define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
+#define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
+
+void __init percpu_init_areas(void)
+{
+    unsigned int cpu;
+    for ( cpu = 1; cpu < NR_CPUS; cpu++ )
+        __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
+}
+
+static int init_percpu_area(unsigned int cpu)
+{
+    char *p;
+    if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA )
+        return -EBUSY;
+    if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL )
+        return -ENOMEM;
+    memset(p, 0, __per_cpu_data_end - __per_cpu_start);
+    __per_cpu_offset[cpu] = p - __per_cpu_start;
+    return 0;
+}
+
+struct free_info {
+    unsigned int cpu;
+    struct rcu_head rcu;
+};
+static DEFINE_PER_CPU(struct free_info, free_info);
+
+static void _free_percpu_area(struct rcu_head *head)
+{
+    struct free_info *info = container_of(head, struct free_info, rcu);
+    unsigned int cpu = info->cpu;
+    char *p = __per_cpu_start + __per_cpu_offset[cpu];
+    free_xenheap_pages(p, PERCPU_ORDER);
+    __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
+}
+
+static void free_percpu_area(unsigned int cpu)
+{
+    struct free_info *info = &per_cpu(free_info, cpu);
+    info->cpu = cpu;
+    call_rcu(&info->rcu, _free_percpu_area);
+}
+
+static int cpu_percpu_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:
+        rc = init_percpu_area(cpu);
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        free_percpu_area(cpu);
+        break;
+    default:
+        break;
+    }
+
+    return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_percpu_nfb = {
+    .notifier_call = cpu_percpu_callback,
+    .priority = 100 /* highest priority */
+};
+
+static int __init percpu_presmp_init(void)
+{
+    register_cpu_notifier(&cpu_percpu_nfb);
+    return 0;
+}
+presmp_initcall(percpu_presmp_init);
diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/include/asm-arm/percpu.h
--- a/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
@@ -12,8 +12,11 @@ void percpu_init_areas(void);
     __attribute__((__section__(".bss.percpu" #suffix)))         \
     __typeof__(type) per_cpu_##name
 
-#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
-#define __get_cpu_var(var) per_cpu__##var
+
+#define per_cpu(var, cpu)  \
+    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
+#define __get_cpu_var(var) \
+    (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset))
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cj1-0007J3-BR; Thu, 23 Feb 2012 17:45:03 +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 1S0ciy-0007GH-3L
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:00 +0000
Received: from [85.158.139.83:62631] by server-3.bemta-5.messagelabs.com id
	D8/B2-06438-B1B764F4; Thu, 23 Feb 2012 17:44:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330019095!16391455!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31944 invoked from network); 23 Feb 2012 17:44:58 -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;
	23 Feb 2012 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165481"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:56 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:56 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fL-10; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0cit-0006b9-OH;
	Thu, 23 Feb 2012 17:44:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
Message-ID: <3b1d7a91a2596baca178.1330018853@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:53 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06 of 10] arm: per-cpu areas
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330018799 0
# Node ID 3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
# Parent  1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
arm: per-cpu areas

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/Makefile
--- a/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
@@ -13,6 +13,7 @@ obj-y += irq.o
 obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
+obj-y += percpu.o
 obj-y += guestcopy.o
 obj-y += setup.o
 obj-y += time.o
diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/dummy.S
--- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
@@ -14,7 +14,6 @@ DUMMY(per_cpu__cpu_core_mask);
 DUMMY(per_cpu__cpu_sibling_mask);
 DUMMY(node_online_map);
 DUMMY(smp_send_state_dump);
-DUMMY(__per_cpu_offset);
 
 /* PIRQ support */
 DUMMY(alloc_pirq_struct);
diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/percpu.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/arch/arm/percpu.c	Thu Feb 23 17:39:59 2012 +0000
@@ -0,0 +1,85 @@
+#include <xen/config.h>
+#include <xen/percpu.h>
+#include <xen/cpu.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/rcupdate.h>
+
+unsigned long __per_cpu_offset[NR_CPUS];
+#define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
+#define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
+
+void __init percpu_init_areas(void)
+{
+    unsigned int cpu;
+    for ( cpu = 1; cpu < NR_CPUS; cpu++ )
+        __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
+}
+
+static int init_percpu_area(unsigned int cpu)
+{
+    char *p;
+    if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA )
+        return -EBUSY;
+    if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL )
+        return -ENOMEM;
+    memset(p, 0, __per_cpu_data_end - __per_cpu_start);
+    __per_cpu_offset[cpu] = p - __per_cpu_start;
+    return 0;
+}
+
+struct free_info {
+    unsigned int cpu;
+    struct rcu_head rcu;
+};
+static DEFINE_PER_CPU(struct free_info, free_info);
+
+static void _free_percpu_area(struct rcu_head *head)
+{
+    struct free_info *info = container_of(head, struct free_info, rcu);
+    unsigned int cpu = info->cpu;
+    char *p = __per_cpu_start + __per_cpu_offset[cpu];
+    free_xenheap_pages(p, PERCPU_ORDER);
+    __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
+}
+
+static void free_percpu_area(unsigned int cpu)
+{
+    struct free_info *info = &per_cpu(free_info, cpu);
+    info->cpu = cpu;
+    call_rcu(&info->rcu, _free_percpu_area);
+}
+
+static int cpu_percpu_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:
+        rc = init_percpu_area(cpu);
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        free_percpu_area(cpu);
+        break;
+    default:
+        break;
+    }
+
+    return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_percpu_nfb = {
+    .notifier_call = cpu_percpu_callback,
+    .priority = 100 /* highest priority */
+};
+
+static int __init percpu_presmp_init(void)
+{
+    register_cpu_notifier(&cpu_percpu_nfb);
+    return 0;
+}
+presmp_initcall(percpu_presmp_init);
diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/include/asm-arm/percpu.h
--- a/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
@@ -12,8 +12,11 @@ void percpu_init_areas(void);
     __attribute__((__section__(".bss.percpu" #suffix)))         \
     __typeof__(type) per_cpu_##name
 
-#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
-#define __get_cpu_var(var) per_cpu__##var
+
+#define per_cpu(var, cpu)  \
+    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
+#define __get_cpu_var(var) \
+    (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset))
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cj5-0007Ql-9k; Thu, 23 Feb 2012 17:45:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0cj3-0007Go-8n
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330019098!12331858!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5184 invoked from network); 23 Feb 2012 17:44:59 -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;
	23 Feb 2012 17:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165485"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:57 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:56 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fR-JY; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bH-A2;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: d35b52e5fde829dfbaf3da73e0716d004faded2f
Message-ID: <d35b52e5fde829dfbaf3.1330018855@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:55 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08 of 10] arm: Boot secondary CPUs into C
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID d35b52e5fde829dfbaf3da73e0716d004faded2f
# Parent  fd78d23ba19de4129e21cdc7303848b105057227
arm: Boot secondary CPUs into C

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -241,7 +241,6 @@ static void __cpuinit gic_hyp_init(void)
 
     vtr = GICH[GICH_VTR];
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
-    printk("GICH: %d list registers available\n", nr_lrs);
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
@@ -274,6 +273,15 @@ int __init gic_init(void)
     return gic.cpus;
 }
 
+/* Set up the per-CPU parts of the GIC for a secondary CPU */
+void __cpuinit gic_init_secondary_cpu(void)
+{
+    spin_lock(&gic.lock);
+    gic_cpu_init();
+    gic_hyp_init();
+    spin_unlock(&gic.lock);
+}
+
 void gic_route_irqs(void)
 {
     /* XXX should get these from DT */
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/gic.h
--- a/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
@@ -140,6 +140,8 @@ extern int gic_route_irq_to_guest(struct
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
 /* Bring up the interrupt controller, and report # cpus attached */
 extern int gic_init(void);
+/* Bring up a secondary CPU's per-CPU GIC interface */
+extern void gic_init_secondary_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
 #endif
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
@@ -305,17 +305,23 @@ paging:
 	 * and brought up the memory allocator, non-boot CPUs can get their
 	 * own stacks and enter C. */
 1:	wfe
-	b 1b
+	dsb
+	ldr   r0, =smp_up_cpu
+	ldr   r1, [r0]               /* Which CPU is being booted? */
+	teq   r1, r12                /* Is it us? */
+	bne   1b
 
 launch:	
-	ldr   sp, =init_stack        /* Supply a stack */
+	ldr   r0, =init_stacks       /* Find the boot-time stack */
+	ldr   sp, [r0, r12, lsl #2]  /* (the one for this CPU) */
 	add   sp, #STACK_SIZE        /* (which grows down from the top). */
 	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
 	mov   r0, r10                /* Marshal args: - phys_offset */
 	mov   r1, r7                 /*               - machine type */
 	mov   r2, r8                 /*               - ATAG address */
-	mov   r3, r12                /*               - CPU ID */
-	b     start_xen              /* and disappear into the land of C */
+	movs  r3, r12                /*               - CPU ID */
+	beq   start_xen              /* and disappear into the land of C */
+	b     start_secondary        /* (to the appropriate entry point) */
 
 /* Fail-stop
  * r0: string explaining why */
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
@@ -38,9 +38,6 @@
 #include <asm/setup.h>
 #include "gic.h"
 
-/* Xen stack for bringing up the first CPU. */
-unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
-
 extern const char __init_begin[], __init_end[], __bss_start[];
 
 /* Spinlock for serializing CPU bringup */
@@ -179,6 +176,8 @@ void __init start_xen(unsigned long boot
     console_init_preirq();
 #endif
 
+    percpu_init_areas();
+
     cpus = gic_init();
 
     printk("Waiting for %i other CPUs to be ready\n", cpus - 1);
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
@@ -16,10 +16,15 @@
  * GNU General Public License for more details.
  */
 
+#include <xen/cpu.h>
 #include <xen/cpumask.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
-#include <xen/init.h>
-#include <xen/errno.h>
+#include <xen/softirq.h>
+#include "gic.h"
 
 cpumask_t cpu_online_map;
 EXPORT_SYMBOL(cpu_online_map);
@@ -28,6 +33,14 @@ EXPORT_SYMBOL(cpu_online_map);
 cpumask_t cpu_possible_map;
 EXPORT_SYMBOL(cpu_possible_map);
 
+/* Xen stack for bringing up the first CPU. */
+static unsigned char cpu0_stack[STACK_SIZE]
+       __attribute__((__aligned__(STACK_SIZE)));
+
+/* Remember where the boot-time stacks live */
+/* TODO: overhaul this, and get_processor_id(), for per-vcpu stacks */
+unsigned char *init_stacks[NR_CPUS] = { cpu0_stack, 0 };
+
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
 {
@@ -43,11 +56,43 @@ smp_prepare_cpus (unsigned int max_cpus)
     cpumask_copy(&cpu_present_map, &cpu_possible_map);
 }
 
-/* Bring up a non-boot CPU */
-int __cpu_up(unsigned int cpu)
+/* Shared state for coordinating CPU bringup */
+unsigned long smp_up_cpu = 0;
+
+/* Boot the current CPU */
+void __cpuinit start_secondary(unsigned long boot_phys_offset,
+                               unsigned long arm_type,
+                               unsigned long atag_paddr,
+                               unsigned long cpuid)
 {
-    /* Not yet... */
-    return -ENODEV;
+    memset(get_cpu_info(), 0, sizeof (struct cpu_info));
+
+    /* TODO: handle boards where CPUIDs are not contiguous */
+    set_processor_id(cpuid);
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+
+    dprintk(XENLOG_DEBUG, "CPU %li awake.\n", cpuid);
+
+    gic_init_secondary_cpu();
+
+    set_current(idle_vcpu[cpuid]);
+    this_cpu(curr_vcpu) = current;
+
+    /* Run local notifiers */
+    notify_cpu_starting(cpuid);
+    wmb();
+
+    /* Now report this CPU is up */
+    cpumask_set_cpu(cpuid, &cpu_online_map);
+    wmb();
+
+    local_irq_enable();
+
+    dprintk(XENLOG_DEBUG, "CPU %li booted.\n", cpuid);
+
+    startup_cpu_idle_loop();
 }
 
 /* Shut down the current CPU */
@@ -57,6 +102,32 @@ void __cpu_disable(void)
     BUG();
 }
 
+/* Bring up a remote CPU */
+int __cpu_up(unsigned int cpu)
+{
+    unsigned char *stack;
+
+    /* Remote CPU needs a stack to boot on. */
+    stack = alloc_xenheap_pages(STACK_ORDER, 0);
+    if ( !stack )
+        return -ENOMEM;
+    ASSERT(init_stacks[cpu] == NULL);
+    init_stacks[cpu] = stack;
+
+    /* Unblock the CPU.  It should be waiting in the loop in head.S
+     * for an event to arrive when smp_up_cpu matches its cpuid. */
+    smp_up_cpu = cpu;
+    asm volatile("dsb; isb; sev");
+
+    while ( !cpu_online(cpu) )
+    {
+        cpu_relax();
+        process_pending_softirqs();
+    }
+
+    return 0;
+}
+
 /* Wait for a remote CPU to die */
 void __cpu_die(unsigned int cpu)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:45:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17: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 1S0cj5-0007Ql-9k; Thu, 23 Feb 2012 17:45:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S0cj3-0007Go-8n
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:45:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330019098!12331858!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5184 invoked from network); 23 Feb 2012 17:44:59 -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;
	23 Feb 2012 17:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183165485"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:44:57 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:44:56 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tim@xen.org>) id 1S0ciu-0002fR-JY; Thu, 23 Feb 2012 17:44:56 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1S0ciu-0006bH-A2;
	Thu, 23 Feb 2012 17:44:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: d35b52e5fde829dfbaf3da73e0716d004faded2f
Message-ID: <d35b52e5fde829dfbaf3.1330018855@whitby.uk.xensource.com>
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 23 Feb 2012 17:40:55 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08 of 10] arm: Boot secondary CPUs into C
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1330018799 0
# Node ID d35b52e5fde829dfbaf3da73e0716d004faded2f
# Parent  fd78d23ba19de4129e21cdc7303848b105057227
arm: Boot secondary CPUs into C

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
@@ -241,7 +241,6 @@ static void __cpuinit gic_hyp_init(void)
 
     vtr = GICH[GICH_VTR];
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
-    printk("GICH: %d list registers available\n", nr_lrs);
 
     GICH[GICH_HCR] = GICH_HCR_EN;
     GICH[GICH_MISR] = GICH_MISR_EOI;
@@ -274,6 +273,15 @@ int __init gic_init(void)
     return gic.cpus;
 }
 
+/* Set up the per-CPU parts of the GIC for a secondary CPU */
+void __cpuinit gic_init_secondary_cpu(void)
+{
+    spin_lock(&gic.lock);
+    gic_cpu_init();
+    gic_hyp_init();
+    spin_unlock(&gic.lock);
+}
+
 void gic_route_irqs(void)
 {
     /* XXX should get these from DT */
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/gic.h
--- a/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/gic.h	Thu Feb 23 17:39:59 2012 +0000
@@ -140,6 +140,8 @@ extern int gic_route_irq_to_guest(struct
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
 /* Bring up the interrupt controller, and report # cpus attached */
 extern int gic_init(void);
+/* Bring up a secondary CPU's per-CPU GIC interface */
+extern void gic_init_secondary_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern void gicv_setup(struct domain *d);
 #endif
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/head.S
--- a/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/head.S	Thu Feb 23 17:39:59 2012 +0000
@@ -305,17 +305,23 @@ paging:
 	 * and brought up the memory allocator, non-boot CPUs can get their
 	 * own stacks and enter C. */
 1:	wfe
-	b 1b
+	dsb
+	ldr   r0, =smp_up_cpu
+	ldr   r1, [r0]               /* Which CPU is being booted? */
+	teq   r1, r12                /* Is it us? */
+	bne   1b
 
 launch:	
-	ldr   sp, =init_stack        /* Supply a stack */
+	ldr   r0, =init_stacks       /* Find the boot-time stack */
+	ldr   sp, [r0, r12, lsl #2]  /* (the one for this CPU) */
 	add   sp, #STACK_SIZE        /* (which grows down from the top). */
 	sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
 	mov   r0, r10                /* Marshal args: - phys_offset */
 	mov   r1, r7                 /*               - machine type */
 	mov   r2, r8                 /*               - ATAG address */
-	mov   r3, r12                /*               - CPU ID */
-	b     start_xen              /* and disappear into the land of C */
+	movs  r3, r12                /*               - CPU ID */
+	beq   start_xen              /* and disappear into the land of C */
+	b     start_secondary        /* (to the appropriate entry point) */
 
 /* Fail-stop
  * r0: string explaining why */
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
@@ -38,9 +38,6 @@
 #include <asm/setup.h>
 #include "gic.h"
 
-/* Xen stack for bringing up the first CPU. */
-unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
-
 extern const char __init_begin[], __init_end[], __bss_start[];
 
 /* Spinlock for serializing CPU bringup */
@@ -179,6 +176,8 @@ void __init start_xen(unsigned long boot
     console_init_preirq();
 #endif
 
+    percpu_init_areas();
+
     cpus = gic_init();
 
     printk("Waiting for %i other CPUs to be ready\n", cpus - 1);
diff -r fd78d23ba19d -r d35b52e5fde8 xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
@@ -16,10 +16,15 @@
  * GNU General Public License for more details.
  */
 
+#include <xen/cpu.h>
 #include <xen/cpumask.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
-#include <xen/init.h>
-#include <xen/errno.h>
+#include <xen/softirq.h>
+#include "gic.h"
 
 cpumask_t cpu_online_map;
 EXPORT_SYMBOL(cpu_online_map);
@@ -28,6 +33,14 @@ EXPORT_SYMBOL(cpu_online_map);
 cpumask_t cpu_possible_map;
 EXPORT_SYMBOL(cpu_possible_map);
 
+/* Xen stack for bringing up the first CPU. */
+static unsigned char cpu0_stack[STACK_SIZE]
+       __attribute__((__aligned__(STACK_SIZE)));
+
+/* Remember where the boot-time stacks live */
+/* TODO: overhaul this, and get_processor_id(), for per-vcpu stacks */
+unsigned char *init_stacks[NR_CPUS] = { cpu0_stack, 0 };
+
 void __init
 smp_prepare_cpus (unsigned int max_cpus)
 {
@@ -43,11 +56,43 @@ smp_prepare_cpus (unsigned int max_cpus)
     cpumask_copy(&cpu_present_map, &cpu_possible_map);
 }
 
-/* Bring up a non-boot CPU */
-int __cpu_up(unsigned int cpu)
+/* Shared state for coordinating CPU bringup */
+unsigned long smp_up_cpu = 0;
+
+/* Boot the current CPU */
+void __cpuinit start_secondary(unsigned long boot_phys_offset,
+                               unsigned long arm_type,
+                               unsigned long atag_paddr,
+                               unsigned long cpuid)
 {
-    /* Not yet... */
-    return -ENODEV;
+    memset(get_cpu_info(), 0, sizeof (struct cpu_info));
+
+    /* TODO: handle boards where CPUIDs are not contiguous */
+    set_processor_id(cpuid);
+
+    /* Setup Hyp vector base */
+    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+
+    dprintk(XENLOG_DEBUG, "CPU %li awake.\n", cpuid);
+
+    gic_init_secondary_cpu();
+
+    set_current(idle_vcpu[cpuid]);
+    this_cpu(curr_vcpu) = current;
+
+    /* Run local notifiers */
+    notify_cpu_starting(cpuid);
+    wmb();
+
+    /* Now report this CPU is up */
+    cpumask_set_cpu(cpuid, &cpu_online_map);
+    wmb();
+
+    local_irq_enable();
+
+    dprintk(XENLOG_DEBUG, "CPU %li booted.\n", cpuid);
+
+    startup_cpu_idle_loop();
 }
 
 /* Shut down the current CPU */
@@ -57,6 +102,32 @@ void __cpu_disable(void)
     BUG();
 }
 
+/* Bring up a remote CPU */
+int __cpu_up(unsigned int cpu)
+{
+    unsigned char *stack;
+
+    /* Remote CPU needs a stack to boot on. */
+    stack = alloc_xenheap_pages(STACK_ORDER, 0);
+    if ( !stack )
+        return -ENOMEM;
+    ASSERT(init_stacks[cpu] == NULL);
+    init_stacks[cpu] = stack;
+
+    /* Unblock the CPU.  It should be waiting in the loop in head.S
+     * for an event to arrive when smp_up_cpu matches its cpuid. */
+    smp_up_cpu = cpu;
+    asm volatile("dsb; isb; sev");
+
+    while ( !cpu_online(cpu) )
+    {
+        cpu_relax();
+        process_pending_softirqs();
+    }
+
+    return 0;
+}
+
 /* Wait for a remote CPU to die */
 void __cpu_die(unsigned int cpu)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cnU-0000zv-25; Thu, 23 Feb 2012 17:49:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cnS-0000yt-Oa
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:49:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330019371!10435481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6234 invoked from network); 23 Feb 2012 17:49:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183166292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:49:31 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:49:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-B8; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:34 +0000
Message-ID: <1330019314-20865-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 13/13] xen/arm: compile grant-table features
	events and xenbus, do not compile pci
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also select XEN_DOM0 by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/Kconfig     |    4 ++++
 drivers/xen/Makefile |    7 ++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 57b294c..1a95b35 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2201,9 +2201,13 @@ config NEON
 	  Say Y to include support code for NEON, the ARMv7 Advanced SIMD
 	  Extension.
 
+config XEN_DOM0
+	def_bool y
+
 config XEN
 	bool "Xen guest support on ARM"
 	depends on ARM
+	select XEN_DOM0
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index dab8305..e3542e1 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,7 +1,9 @@
 ifeq (CONFIG_X86,y)
-obj-y	+= grant-table.o features.o events.o manage.o balloon.o
-obj-y	+= xenbus/
+obj-y	+= manage.o balloon.o
+obj-$(CONFIG_XEN_DOM0)			+= pci.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)
@@ -21,7 +23,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)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 
 xen-evtchn-y				:= evtchn.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 Thu Feb 23 17:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cnU-0000zv-25; Thu, 23 Feb 2012 17:49:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cnS-0000yt-Oa
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:49:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330019371!10435481!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6234 invoked from network); 23 Feb 2012 17:49:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183166292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:49:31 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:49:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-B8; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:34 +0000
Message-ID: <1330019314-20865-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 13/13] xen/arm: compile grant-table features
	events and xenbus, do not compile pci
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also select XEN_DOM0 by default.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/Kconfig     |    4 ++++
 drivers/xen/Makefile |    7 ++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 57b294c..1a95b35 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2201,9 +2201,13 @@ config NEON
 	  Say Y to include support code for NEON, the ARMv7 Advanced SIMD
 	  Extension.
 
+config XEN_DOM0
+	def_bool y
+
 config XEN
 	bool "Xen guest support on ARM"
 	depends on ARM
+	select XEN_DOM0
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index dab8305..e3542e1 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,7 +1,9 @@
 ifeq (CONFIG_X86,y)
-obj-y	+= grant-table.o features.o events.o manage.o balloon.o
-obj-y	+= xenbus/
+obj-y	+= manage.o balloon.o
+obj-$(CONFIG_XEN_DOM0)			+= pci.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)
@@ -21,7 +23,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)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 
 xen-evtchn-y				:= evtchn.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 Thu Feb 23 17:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cnV-00010b-Rt; Thu, 23 Feb 2012 17:49:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cnT-0000z2-S3
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:49:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330019372!16153151!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23390 invoked from network); 23 Feb 2012 17:49:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387820"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:49:31 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:49:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-8h; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:32 +0000
Message-ID: <1330019314-20865-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 11/13] 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>
---
 arch/arm/include/asm/xen/interface.h  |    3 +++
 arch/ia64/include/asm/xen/interface.h |    3 ++-
 arch/x86/include/asm/xen/interface.h  |    3 +++
 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, 18 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 2ee39e8..65577de 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -24,6 +24,8 @@
 		(hnd) = val;				\
 	} while (0)
 
+typedef uint64_t xen_pfn_t;
+
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
@@ -33,6 +35,7 @@ DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 1d2427d..18904ac 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -66,6 +66,8 @@
 #define GUEST_HANDLE_64(name)		GUEST_HANDLE(name)
 #define set_xen_guest_handle(hnd, val)	do { (hnd).p = val; } while (0)
 
+typedef unsigned long xen_pfn_t;
+
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
@@ -78,7 +80,6 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_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 a1f2db5..59a37ec 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -46,6 +46,8 @@
 #endif
 #endif
 
+typedef unsigned long xen_pfn_t;
+
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
@@ -56,6 +58,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_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 39e5717..1fd3a66 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -254,7 +254,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. */
@@ -291,7 +291,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 c168468..1c172ce 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 19354db..3edc110 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -192,7 +192,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;
@@ -432,11 +432,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 4d58881..45c1aa1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -37,8 +37,6 @@
 #include <linux/compiler.h>
 #include <xen/interface/xen.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 Thu Feb 23 17:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cnV-00010b-Rt; Thu, 23 Feb 2012 17:49:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cnT-0000z2-S3
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:49:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330019372!16153151!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23390 invoked from network); 23 Feb 2012 17:49:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="22387820"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:49:31 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:49:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-8h; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:32 +0000
Message-ID: <1330019314-20865-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 11/13] 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>
---
 arch/arm/include/asm/xen/interface.h  |    3 +++
 arch/ia64/include/asm/xen/interface.h |    3 ++-
 arch/x86/include/asm/xen/interface.h  |    3 +++
 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, 18 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 2ee39e8..65577de 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -24,6 +24,8 @@
 		(hnd) = val;				\
 	} while (0)
 
+typedef uint64_t xen_pfn_t;
+
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
@@ -33,6 +35,7 @@ DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 1d2427d..18904ac 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -66,6 +66,8 @@
 #define GUEST_HANDLE_64(name)		GUEST_HANDLE(name)
 #define set_xen_guest_handle(hnd, val)	do { (hnd).p = val; } while (0)
 
+typedef unsigned long xen_pfn_t;
+
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
@@ -78,7 +80,6 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_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 a1f2db5..59a37ec 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -46,6 +46,8 @@
 #endif
 #endif
 
+typedef unsigned long xen_pfn_t;
+
 #ifndef __ASSEMBLY__
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
@@ -56,6 +58,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_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 39e5717..1fd3a66 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -254,7 +254,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. */
@@ -291,7 +291,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 c168468..1c172ce 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 19354db..3edc110 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -192,7 +192,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;
@@ -432,11 +432,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 4d58881..45c1aa1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -37,8 +37,6 @@
 #include <linux/compiler.h>
 #include <xen/interface/xen.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 Thu Feb 23 17:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cnU-000108-FM; Thu, 23 Feb 2012 17:49:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cnT-0000yy-Ds
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:49:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330019371!10435481!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6249 invoked from network); 23 Feb 2012 17:49:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183166296"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:49:32 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:49:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-9J; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:33 +0000
Message-ID: <1330019314-20865-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 12/13] 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,
and do not call xs_reset_watches at boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/xenbus/xenbus_comms.c |    2 +-
 drivers/xen/xenbus/xenbus_probe.c |   26 ++++++++++++++++----------
 drivers/xen/xenbus/xenbus_xs.c    |    3 ++-
 3 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..57b8230 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 1b178c6..f3d5105 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -731,16 +731,22 @@ static int __init xenbus_init(void)
 		return -ENODEV;
 
 	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);
+		if (xen_initial_domain()) {
+			err = xenstored_local_init();
+			xen_store_interface = phys_to_virt(xen_store_mfn << PAGE_SHIFT);
+		} else {
+			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;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index b3b8f2f..edcef19 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"
@@ -907,7 +908,7 @@ int xs_init(void)
 		return PTR_ERR(task);
 
 	/* shutdown watches for kexec boot */
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() && !xen_initial_domain())
 		xs_reset_watches();
 
 	return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 17:49:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 17:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0cnU-000108-FM; Thu, 23 Feb 2012 17:49:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0cnT-0000yy-Ds
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 17:49:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330019371!10435481!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6249 invoked from network); 23 Feb 2012 17:49:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 17:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,470,1325480400"; d="scan'208";a="183166296"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 12:49:32 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 12:49:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0cgc-0002d9-9J; Thu, 23 Feb 2012 17:42:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 23 Feb 2012 17:48:33 +0000
Message-ID: <1330019314-20865-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	catalin.marinas@arm.com, david.vrabel@citrix.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH-WIP 12/13] 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,
and do not call xs_reset_watches at boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/xenbus/xenbus_comms.c |    2 +-
 drivers/xen/xenbus/xenbus_probe.c |   26 ++++++++++++++++----------
 drivers/xen/xenbus/xenbus_xs.c    |    3 ++-
 3 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..57b8230 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 1b178c6..f3d5105 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -731,16 +731,22 @@ static int __init xenbus_init(void)
 		return -ENODEV;
 
 	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);
+		if (xen_initial_domain()) {
+			err = xenstored_local_init();
+			xen_store_interface = phys_to_virt(xen_store_mfn << PAGE_SHIFT);
+		} else {
+			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;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index b3b8f2f..edcef19 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"
@@ -907,7 +908,7 @@ int xs_init(void)
 		return PTR_ERR(task);
 
 	/* shutdown watches for kexec boot */
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() && !xen_initial_domain())
 		xs_reset_watches();
 
 	return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:07:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0d40-0001gO-V5; Thu, 23 Feb 2012 18:06:44 +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 1S0d3z-0001gJ-EK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:06:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330020348!51335740!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3014 invoked from network); 23 Feb 2012 18:05:50 -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; 23 Feb 2012 18:05:50 -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 q1NI6aUK013781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 18:06:37 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1NI6YMr005899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 18:06: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
	q1NI6Yji016765; Thu, 23 Feb 2012 12:06:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 10:06:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CD6454171C; Thu, 23 Feb 2012 13:03:13 -0500 (EST)
Date: Thu, 23 Feb 2012 13:03:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120223180313.GC22574@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4679D1.3000806@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F46802D.00F5,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Marek Marczykowski <marmarek@mimuw.edu.pl>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 06:39:29PM +0100, Joanna Rutkowska wrote:
> On 02/23/12 18:31, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
> >>> Hello,
> >>>
> >>> I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
> >>> integrated GPU) freezing at resume from S3 sleep... It seems like a
> >>> Xen-related problems, as a similar kernel to what we use in Dom0
> >>> (2.6.38+xenlinux), when run on baremetal shows no signs of problems at
> >>> suspend/resume. Also I cannot find any problems reported on the internet
> >>> with people having problems here.
> >>>
> >>> Unfortunately the only COM port on ExpressCard I have, presents itself
> >>> as a USB device, and so I cannot really debug this issue via console.
> >>> The /var/log/pm-suspend also doesn't reveal anything useful (after I
> >>> reboot, that is).
> >>>
> >>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> >>> to approach debugging it?
> >>>
> >>> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
> >>> patches, and the i915 for the graphics. (Unfortunately I cannot just
> >>> boot the same Dom0 kernel without Xen, as the GRUB complains about
> >>> executable being unrecognized -- probably some problem with wrong
> >>> compression algo).
> >>>
> >>> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
> >>> -- in this case it's even worse, as the system hangs at suspend and
> >>> never enters S3 :/
> >>
> >> Right. You need some patches for that in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
> >> to make that work.
> > 
> > What I meant to say - please try it out with those patches. It might that you
> > are hitting on one of the Intel bugs of the video adapter that I think
> > are mostly fixed in the upstream kernel.
> 
> So, you're saying those (presumed) bugs a fixed only in the pvops, and
> not in xenlinux?

I am saying that they are fixed in 3.x kernels.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:07:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0d40-0001gO-V5; Thu, 23 Feb 2012 18:06:44 +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 1S0d3z-0001gJ-EK
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:06:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330020348!51335740!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3014 invoked from network); 23 Feb 2012 18:05:50 -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; 23 Feb 2012 18:05:50 -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 q1NI6aUK013781
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 18:06:37 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1NI6YMr005899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 18:06: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
	q1NI6Yji016765; Thu, 23 Feb 2012 12:06:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 10:06:34 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CD6454171C; Thu, 23 Feb 2012 13:03:13 -0500 (EST)
Date: Thu, 23 Feb 2012 13:03:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120223180313.GC22574@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4679D1.3000806@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F46802D.00F5,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Marek Marczykowski <marmarek@mimuw.edu.pl>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 06:39:29PM +0100, Joanna Rutkowska wrote:
> On 02/23/12 18:31, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
> >>> Hello,
> >>>
> >>> I've been trying to resolve the issue of my T420s (Core i5 2540M, Intel
> >>> integrated GPU) freezing at resume from S3 sleep... It seems like a
> >>> Xen-related problems, as a similar kernel to what we use in Dom0
> >>> (2.6.38+xenlinux), when run on baremetal shows no signs of problems at
> >>> suspend/resume. Also I cannot find any problems reported on the internet
> >>> with people having problems here.
> >>>
> >>> Unfortunately the only COM port on ExpressCard I have, presents itself
> >>> as a USB device, and so I cannot really debug this issue via console.
> >>> The /var/log/pm-suspend also doesn't reveal anything useful (after I
> >>> reboot, that is).
> >>>
> >>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> >>> to approach debugging it?
> >>>
> >>> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenlinux
> >>> patches, and the i915 for the graphics. (Unfortunately I cannot just
> >>> boot the same Dom0 kernel without Xen, as the GRUB complains about
> >>> executable being unrecognized -- probably some problem with wrong
> >>> compression algo).
> >>>
> >>> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla kernel)
> >>> -- in this case it's even worse, as the system hangs at suspend and
> >>> never enters S3 :/
> >>
> >> Right. You need some patches for that in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
> >> to make that work.
> > 
> > What I meant to say - please try it out with those patches. It might that you
> > are hitting on one of the Intel bugs of the video adapter that I think
> > are mostly fixed in the upstream kernel.
> 
> So, you're saying those (presumed) bugs a fixed only in the pvops, and
> not in xenlinux?

I am saying that they are fixed in 3.x kernels.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:11:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0d8e-00022o-92; Thu, 23 Feb 2012 18:11:32 +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 1S0d8c-00022R-8Q
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:11:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330020662!64799171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1418 invoked from network); 23 Feb 2012 18:11:02 -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;
	23 Feb 2012 18:11:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10904871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 18:11:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 18:11:26 +0000
Date: Thu, 23 Feb 2012 18:17:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330018061.8557.100.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231816490.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
	<1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330018061.8557.100.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm: shared_info page allocation and
	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 Thu, 23 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:13 +0000, Stefano Stabellini wrote:
> > Allocate the shared_info page at domain creation.
> > 
> > Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> > XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/domain.c     |    8 ++++
> >  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
> >  xen/arch/arm/p2m.c        |   15 ++++++-
> >  xen/include/asm-arm/mm.h  |    4 ++
> >  xen/include/asm-arm/p2m.h |    2 +
> >  5 files changed, 122 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 0b55934..1e5cca5 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >      if ( (rc = p2m_init(d)) != 0 )
> >          goto fail;
> >  
> > +    rc = -ENOMEM;
> > +	if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> > +		goto fail;
> > +
> > +	clear_page(d->shared_info);
> > +	share_xen_page_with_guest(
> > +			virt_to_page(d->shared_info), d, XENSHARE_writable);
> 
> You seem to have some hard tabs here.

I realize that there are some tab problems in this series, I'll send it
out again.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:11:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0d8e-00022o-92; Thu, 23 Feb 2012 18:11:32 +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 1S0d8c-00022R-8Q
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:11:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330020662!64799171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1418 invoked from network); 23 Feb 2012 18:11:02 -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;
	23 Feb 2012 18:11:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10904871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 18:11:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 18:11:26 +0000
Date: Thu, 23 Feb 2012 18:17:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330018061.8557.100.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231816490.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231705050.23091@kaball-desktop>
	<1330017212-20066-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330018061.8557.100.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] arm: shared_info page allocation and
	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 Thu, 23 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:13 +0000, Stefano Stabellini wrote:
> > Allocate the shared_info page at domain creation.
> > 
> > Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> > XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/domain.c     |    8 ++++
> >  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
> >  xen/arch/arm/p2m.c        |   15 ++++++-
> >  xen/include/asm-arm/mm.h  |    4 ++
> >  xen/include/asm-arm/p2m.h |    2 +
> >  5 files changed, 122 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 0b55934..1e5cca5 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> >      if ( (rc = p2m_init(d)) != 0 )
> >          goto fail;
> >  
> > +    rc = -ENOMEM;
> > +	if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> > +		goto fail;
> > +
> > +	clear_page(d->shared_info);
> > +	share_xen_page_with_guest(
> > +			virt_to_page(d->shared_info), d, XENSHARE_writable);
> 
> You seem to have some hard tabs here.

I realize that there are some tab problems in this series, I'll send it
out again.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:14:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dBc-0002NR-V3; Thu, 23 Feb 2012 18:14:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dBb-0002Mv-Gt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:14:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330020869!12754433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31814 invoked from network); 23 Feb 2012 18:14:29 -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;
	23 Feb 2012 18:14:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10904923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 18:14:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 18:14:29 +0000
Date: Thu, 23 Feb 2012 18:20:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH v2 0/5] xen/arm: event channels and shared_info
	page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series implements support for injecting event channels into
the guest and enables a wider range of hypercalls for ARM guests.

In order to allow more flexibility I modified the hypercall protocol, in
particular the hypercall number is not passed as imm to hvc anymore,
because we might not always know it at compile time.
The hypercall number is now passed on the r12 register.

With this the corresponding Linux patch series applied to both Linux and
Xen, I am able to boot dom0, start xenstored and run basic xl commands,
like "xl list" and "xl uptime".



Changes in v2:

- fixed tabs/spaces problem.



Stefano Stabellini (5):
      arm: shared_info page allocation and mapping
      arm: implement vcpu_mark_events_pending
      arm: set the default dom0 max_vcpus value to 1 (currently is 0)
      arm: use r12 to pass the hypercall number
      arm: introduce more hypercalls

 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/domain.c           |   19 ++++++++
 xen/arch/arm/domain_build.c     |    2 +-
 xen/arch/arm/dummy.S            |    1 -
 xen/arch/arm/gic.h              |    3 +
 xen/arch/arm/mm.c               |   98 +++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c              |   15 ++++++-
 xen/arch/arm/physdev.c          |   27 +++++++++++
 xen/arch/arm/traps.c            |   21 +++++---
 xen/include/asm-arm/hypercall.h |    3 +
 xen/include/asm-arm/mm.h        |    4 ++
 xen/include/asm-arm/p2m.h       |    2 +
 12 files changed, 181 insertions(+), 15 deletions(-)


A git branch based on my previous gic and tools patches is available
here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git events-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:14:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dBc-0002NR-V3; Thu, 23 Feb 2012 18:14:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dBb-0002Mv-Gt
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:14:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330020869!12754433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31814 invoked from network); 23 Feb 2012 18:14:29 -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;
	23 Feb 2012 18:14:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10904923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 18:14:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 18:14:29 +0000
Date: Thu, 23 Feb 2012 18:20:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH v2 0/5] xen/arm: event channels and shared_info
	page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series implements support for injecting event channels into
the guest and enables a wider range of hypercalls for ARM guests.

In order to allow more flexibility I modified the hypercall protocol, in
particular the hypercall number is not passed as imm to hvc anymore,
because we might not always know it at compile time.
The hypercall number is now passed on the r12 register.

With this the corresponding Linux patch series applied to both Linux and
Xen, I am able to boot dom0, start xenstored and run basic xl commands,
like "xl list" and "xl uptime".



Changes in v2:

- fixed tabs/spaces problem.



Stefano Stabellini (5):
      arm: shared_info page allocation and mapping
      arm: implement vcpu_mark_events_pending
      arm: set the default dom0 max_vcpus value to 1 (currently is 0)
      arm: use r12 to pass the hypercall number
      arm: introduce more hypercalls

 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/domain.c           |   19 ++++++++
 xen/arch/arm/domain_build.c     |    2 +-
 xen/arch/arm/dummy.S            |    1 -
 xen/arch/arm/gic.h              |    3 +
 xen/arch/arm/mm.c               |   98 +++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c              |   15 ++++++-
 xen/arch/arm/physdev.c          |   27 +++++++++++
 xen/arch/arm/traps.c            |   21 +++++---
 xen/include/asm-arm/hypercall.h |    3 +
 xen/include/asm-arm/mm.h        |    4 ++
 xen/include/asm-arm/p2m.h       |    2 +
 12 files changed, 181 insertions(+), 15 deletions(-)


A git branch based on my previous gic and tools patches is available
here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git events-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0dCk-0002Vm-Df; Thu, 23 Feb 2012 18:15:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dCj-0002Up-Fp
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:15:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330020937!12336693!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9343 invoked from network); 23 Feb 2012 18:15:39 -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;
	23 Feb 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="22388842"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-OM; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:30 +0000
Message-ID: <1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 2/5] arm: implement vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
we reserve for Xen usage.
In the future the interrupt used for event injection might be dynamic
and could be written into the device tree.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |   11 +++++++++++
 xen/arch/arm/dummy.S  |    1 -
 xen/arch/arm/gic.h    |    3 +++
 3 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0ee96b9..4752aaa 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -272,6 +272,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
 
+void vcpu_mark_events_pending(struct vcpu *v)
+{
+    int already_pending = test_and_set_bit(
+        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
+
+    if ( already_pending )
+        return;
+
+    vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3f2cc4b..93f6f53 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,7 +31,6 @@ DUMMY(arch_vcpu_reset);
 DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
 DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 81c388d..36fdea1 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+/* XXX: write this into the DT */
+#define VGIC_IRQ_EVTCHN_CALLBACK 63
+
 extern int domain_vgic_init(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 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 1S0dCk-0002Vm-Df; Thu, 23 Feb 2012 18:15:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dCj-0002Up-Fp
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:15:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330020937!12336693!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjIwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9343 invoked from network); 23 Feb 2012 18:15:39 -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;
	23 Feb 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="22388842"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-OM; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:30 +0000
Message-ID: <1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 2/5] arm: implement vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
we reserve for Xen usage.
In the future the interrupt used for event injection might be dynamic
and could be written into the device tree.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |   11 +++++++++++
 xen/arch/arm/dummy.S  |    1 -
 xen/arch/arm/gic.h    |    3 +++
 3 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0ee96b9..4752aaa 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -272,6 +272,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
 
+void vcpu_mark_events_pending(struct vcpu *v)
+{
+    int already_pending = test_and_set_bit(
+        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
+
+    if ( already_pending )
+        return;
+
+    vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3f2cc4b..93f6f53 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,7 +31,6 @@ DUMMY(arch_vcpu_reset);
 DUMMY(free_vcpu_guest_context);
 DUMMY(sync_vcpu_execstate);
 NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
 DUMMY(vcpu_show_execution_state);
 
 /* Page Reference & Type Maintenance */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index 81c388d..36fdea1 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -121,6 +121,9 @@
 #define GICH_LR_CPUID_SHIFT     9
 #define GICH_VTR_NRLRGS         0x3f
 
+/* XXX: write this into the DT */
+#define VGIC_IRQ_EVTCHN_CALLBACK 63
+
 extern int domain_vgic_init(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEJ-0002gV-Te; Thu, 23 Feb 2012 18:17: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 1S0dEI-0002gB-3k
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330020998!53734690!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20381 invoked from network); 23 Feb 2012 18:16:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:16:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171295"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-Ni; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:29 +0000
Message-ID: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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

Allocate the shared_info page at domain creation.

Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
XENMAPSPACE_shared_info, so that the guest can map the shared_info page.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    8 ++++
 xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c        |   15 ++++++-
 xen/include/asm-arm/mm.h  |    4 ++
 xen/include/asm-arm/p2m.h |    2 +
 5 files changed, 122 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..0ee96b9 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
+    rc = -ENOMEM;
+    if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
+        goto fail;
+
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+            virt_to_page(d->shared_info), d, XENSHARE_writable);
+
     d->max_vcpus = 8;
 
     if ( (rc = domain_vgic_init(d)) != 0 )
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a0f39eb..0fe0398 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,8 +25,11 @@
 #include <xen/mm.h>
 #include <xen/preempt.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <asm/page.h>
 #include <asm/current.h>
+#include <public/memory.h>
+#include <xen/sched.h>
 
 struct domain *dom_xen, *dom_io;
 
@@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
 {
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
 {
+    ASSERT(0);
     return -ENOSYS;
 }
 
-int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
+void share_xen_page_with_guest(struct page_info *page,
+                          struct domain *d, int readonly)
 {
-    ASSERT(0);
-    return -ENOSYS;
+    if ( page_get_owner(page) == d )
+        return;
+
+    spin_lock(&d->page_alloc_lock);
+
+    /* The incremented type count pins as writable or read-only. */
+    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
+    page->u.inuse.type_info |= PGT_validated | 1;
+
+    page_set_owner(page, d);
+    wmb(); /* install valid domain ptr before updating refcnt. */
+    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
+
+    /* Only add to the allocation list if the domain isn't dying. */
+    if ( !d->is_dying )
+    {
+        page->count_info |= PGC_allocated | 1;
+        if ( unlikely(d->xenheap_pages++ == 0) )
+            get_knownalive_domain(d);
+        page_list_add_tail(page, &d->xenpage_list);
+    }
+
+    spin_unlock(&d->page_alloc_lock);
+}
+
+static int xenmem_add_to_physmap_once(
+    struct domain *d,
+    const struct xen_add_to_physmap *xatp)
+{
+    unsigned long mfn = 0;
+    int rc;
+
+    switch ( xatp->space )
+    {
+        case XENMAPSPACE_shared_info:
+            if ( xatp->idx == 0 )
+                mfn = virt_to_mfn(d->shared_info);
+            break;
+        default:
+            return -ENOSYS;
+    }
+
+    domain_lock(d);
+
+    /* Map at new location. */
+    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
+
+    domain_unlock(d);
+
+    return rc;
+}
+
+static int xenmem_add_to_physmap(struct domain *d,
+                                 struct xen_add_to_physmap *xatp)
+{
+    return xenmem_add_to_physmap_once(d, xatp);
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    int rc;
+
+    switch ( op )
+    {
+    case XENMEM_add_to_physmap:
+    {
+        struct xen_add_to_physmap xatp;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap(d, &xatp);
+
+        rcu_unlock_domain(d);
+
+        return rc;
+    }
+
+    default:
+        return -ENOSYS;
+    }
+
+    return 0;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 14614fd..1a00a50 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
         }
         /* else: third already valid */
 
-        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+        if ( third[third_table_offset(addr)].p2m.valid )
+        {
+            /* p2m entry already present */
+            free_domheap_page(
+                    mfn_to_page(third[third_table_offset(addr)].p2m.base));
+        }
 
         /* Allocate a new RAM page and attach */
         if (alloc)
@@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
     return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
 }
 
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+        unsigned long mfn)
+{
+    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
+                              (gpfn + 1) << PAGE_SHIFT,
+                              mfn << PAGE_SHIFT);
+}
+
 int p2m_alloc_table(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index bfc0f76..56ab9415 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -78,6 +78,10 @@ struct page_info
 #define _PGT_pinned       PG_shift(5)
 #define PGT_pinned        PG_mask(1, 5)
 
+ /* Has this page been validated for use as its current type? */
+#define _PGT_validated    PG_shift(6)
+#define PGT_validated     PG_mask(1, 6)
+
  /* Count of uses of this frame as its current type. */
 #define PGT_count_width   PG_shift(9)
 #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index aec52f7..c0f2995 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
  * address maddr. */
 int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
                      paddr_t end_gaddr, paddr_t maddr);
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+        unsigned long mfn);
 
 unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEJ-0002gV-Te; Thu, 23 Feb 2012 18:17: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 1S0dEI-0002gB-3k
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330020998!53734690!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20381 invoked from network); 23 Feb 2012 18:16:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:16:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171295"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-Ni; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:29 +0000
Message-ID: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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

Allocate the shared_info page at domain creation.

Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
XENMAPSPACE_shared_info, so that the guest can map the shared_info page.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    8 ++++
 xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/p2m.c        |   15 ++++++-
 xen/include/asm-arm/mm.h  |    4 ++
 xen/include/asm-arm/p2m.h |    2 +
 5 files changed, 122 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0b55934..0ee96b9 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (rc = p2m_init(d)) != 0 )
         goto fail;
 
+    rc = -ENOMEM;
+    if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
+        goto fail;
+
+    clear_page(d->shared_info);
+    share_xen_page_with_guest(
+            virt_to_page(d->shared_info), d, XENSHARE_writable);
+
     d->max_vcpus = 8;
 
     if ( (rc = domain_vgic_init(d)) != 0 )
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a0f39eb..0fe0398 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,8 +25,11 @@
 #include <xen/mm.h>
 #include <xen/preempt.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <asm/page.h>
 #include <asm/current.h>
+#include <public/memory.h>
+#include <xen/sched.h>
 
 struct domain *dom_xen, *dom_io;
 
@@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
 {
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
 {
+    ASSERT(0);
     return -ENOSYS;
 }
 
-int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
+void share_xen_page_with_guest(struct page_info *page,
+                          struct domain *d, int readonly)
 {
-    ASSERT(0);
-    return -ENOSYS;
+    if ( page_get_owner(page) == d )
+        return;
+
+    spin_lock(&d->page_alloc_lock);
+
+    /* The incremented type count pins as writable or read-only. */
+    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
+    page->u.inuse.type_info |= PGT_validated | 1;
+
+    page_set_owner(page, d);
+    wmb(); /* install valid domain ptr before updating refcnt. */
+    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
+
+    /* Only add to the allocation list if the domain isn't dying. */
+    if ( !d->is_dying )
+    {
+        page->count_info |= PGC_allocated | 1;
+        if ( unlikely(d->xenheap_pages++ == 0) )
+            get_knownalive_domain(d);
+        page_list_add_tail(page, &d->xenpage_list);
+    }
+
+    spin_unlock(&d->page_alloc_lock);
+}
+
+static int xenmem_add_to_physmap_once(
+    struct domain *d,
+    const struct xen_add_to_physmap *xatp)
+{
+    unsigned long mfn = 0;
+    int rc;
+
+    switch ( xatp->space )
+    {
+        case XENMAPSPACE_shared_info:
+            if ( xatp->idx == 0 )
+                mfn = virt_to_mfn(d->shared_info);
+            break;
+        default:
+            return -ENOSYS;
+    }
+
+    domain_lock(d);
+
+    /* Map at new location. */
+    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
+
+    domain_unlock(d);
+
+    return rc;
+}
+
+static int xenmem_add_to_physmap(struct domain *d,
+                                 struct xen_add_to_physmap *xatp)
+{
+    return xenmem_add_to_physmap_once(d, xatp);
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    int rc;
+
+    switch ( op )
+    {
+    case XENMEM_add_to_physmap:
+    {
+        struct xen_add_to_physmap xatp;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap(d, &xatp);
+
+        rcu_unlock_domain(d);
+
+        return rc;
+    }
+
+    default:
+        return -ENOSYS;
+    }
+
+    return 0;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 14614fd..1a00a50 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
         }
         /* else: third already valid */
 
-        BUG_ON(third[third_table_offset(addr)].p2m.valid);
+        if ( third[third_table_offset(addr)].p2m.valid )
+        {
+            /* p2m entry already present */
+            free_domheap_page(
+                    mfn_to_page(third[third_table_offset(addr)].p2m.base));
+        }
 
         /* Allocate a new RAM page and attach */
         if (alloc)
@@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
     return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
 }
 
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+        unsigned long mfn)
+{
+    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
+                              (gpfn + 1) << PAGE_SHIFT,
+                              mfn << PAGE_SHIFT);
+}
+
 int p2m_alloc_table(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index bfc0f76..56ab9415 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -78,6 +78,10 @@ struct page_info
 #define _PGT_pinned       PG_shift(5)
 #define PGT_pinned        PG_mask(1, 5)
 
+ /* Has this page been validated for use as its current type? */
+#define _PGT_validated    PG_shift(6)
+#define PGT_validated     PG_mask(1, 6)
+
  /* Count of uses of this frame as its current type. */
 #define PGT_count_width   PG_shift(9)
 #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index aec52f7..c0f2995 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
  * address maddr. */
 int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
                      paddr_t end_gaddr, paddr_t maddr);
+int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
+        unsigned long mfn);
 
 unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEL-0002gy-9V; Thu, 23 Feb 2012 18:17:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dEJ-0002fn-Ra
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330021035!9765442!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9073 invoked from network); 23 Feb 2012 18:17:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:17:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-SW; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:33 +0000
Message-ID: <1330021293-21554-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 5/5] arm: introduce more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement xen_version, event_channel_op, memory_op sysctl and physdev_op
hypercalls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/physdev.c          |   27 +++++++++++++++++++++++++++
 xen/arch/arm/traps.c            |    5 +++++
 xen/include/asm-arm/hypercall.h |    1 +
 4 files changed, 34 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/physdev.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49b64fe..619430c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -14,6 +14,7 @@ obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
+obj-y += physdev.o
 obj-y += setup.o
 obj-y += time.o
 obj-y += smpboot.o
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
new file mode 100644
index 0000000..bcf4337
--- /dev/null
+++ b/xen/arch/arm/physdev.c
@@ -0,0 +1,27 @@
+/******************************************************************************
+ * Arch-specific physdev.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <asm/hypercall.h>
+
+
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+{
+    printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
+    return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44d19ec..b266c5e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -376,6 +376,11 @@ static arm_hypercall_t *arm_hypercall_table[] = {
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
+    HYPERCALL(xen_version),
+    HYPERCALL(event_channel_op),
+    HYPERCALL(memory_op),
+    HYPERCALL(physdev_op),
+    HYPERCALL(sysctl),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index d517542..b91f8b6 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include <public/domctl.h> /* for arch_do_domctl */
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEL-0002gy-9V; Thu, 23 Feb 2012 18:17:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dEJ-0002fn-Ra
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330021035!9765442!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9073 invoked from network); 23 Feb 2012 18:17:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:17:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-SW; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:33 +0000
Message-ID: <1330021293-21554-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 5/5] arm: introduce more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Implement xen_version, event_channel_op, memory_op sysctl and physdev_op
hypercalls.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Makefile           |    1 +
 xen/arch/arm/physdev.c          |   27 +++++++++++++++++++++++++++
 xen/arch/arm/traps.c            |    5 +++++
 xen/include/asm-arm/hypercall.h |    1 +
 4 files changed, 34 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/arm/physdev.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49b64fe..619430c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -14,6 +14,7 @@ obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
+obj-y += physdev.o
 obj-y += setup.o
 obj-y += time.o
 obj-y += smpboot.o
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
new file mode 100644
index 0000000..bcf4337
--- /dev/null
+++ b/xen/arch/arm/physdev.c
@@ -0,0 +1,27 @@
+/******************************************************************************
+ * Arch-specific physdev.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <asm/hypercall.h>
+
+
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+{
+    printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
+    return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44d19ec..b266c5e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -376,6 +376,11 @@ static arm_hypercall_t *arm_hypercall_table[] = {
     HYPERCALL(arch_0),
     HYPERCALL(sched_op),
     HYPERCALL(console_io),
+    HYPERCALL(xen_version),
+    HYPERCALL(event_channel_op),
+    HYPERCALL(memory_op),
+    HYPERCALL(physdev_op),
+    HYPERCALL(sysctl),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index d517542..b91f8b6 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include <public/domctl.h> /* for arch_do_domctl */
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEL-0002hN-QV; Thu, 23 Feb 2012 18:17:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dEK-0002fp-Ee
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330021035!9765442!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9095 invoked from network); 23 Feb 2012 18:17:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-Or; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:31 +0000
Message-ID: <1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 3/5] arm: set the default dom0 max_vcpus
	value to 1 (currently is 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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..06ba285 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,7 +9,7 @@
 #include "gic.h"
 #include "kernel.h"
 
-static unsigned int __initdata opt_dom0_max_vcpus;
+static unsigned int __initdata opt_dom0_max_vcpus = 1;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEL-0002hN-QV; Thu, 23 Feb 2012 18:17:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dEK-0002fp-Ee
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330021035!9765442!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9095 invoked from network); 23 Feb 2012 18:17:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-Or; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:31 +0000
Message-ID: <1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 3/5] arm: set the default dom0 max_vcpus
	value to 1 (currently is 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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cbbc0b9..06ba285 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,7 +9,7 @@
 #include "gic.h"
 #include "kernel.h"
 
-static unsigned int __initdata opt_dom0_max_vcpus;
+static unsigned int __initdata opt_dom0_max_vcpus = 1;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEO-0002iA-6c; Thu, 23 Feb 2012 18:17:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dEN-0002gC-49
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330021039!16156751!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12750 invoked from network); 23 Feb 2012 18:17:20 -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;
	23 Feb 2012 18:17:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171293"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-Qh; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:32 +0000
Message-ID: <1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 4/5] arm: use r12 to pass the hypercall 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

Use r12 to pass the hypercall number and r0-r4 for the hypercall
arguments as usual.

Use the ISS to pass an hypervisor specific tag.

Remove passing unused registers to arm_hypercall_table: we don't have 6
arguments hypercalls and we never use 64 bit values as hypercall
arguments, 64 bit values are only contained within structs passed as
arguments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/traps.c            |   16 ++++++++--------
 xen/include/asm-arm/hypercall.h |    2 ++
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 395d0af..44d19ec 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -367,7 +367,6 @@ unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 }
 
 typedef unsigned long arm_hypercall_t(
-    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
     unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
 
 #define HYPERCALL(x)                                        \
@@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     local_irq_enable();
 
-    regs->r0 = arm_hypercall_table[iss](regs->r0,
+    if ( iss != XEN_HYPERCALL_TAG  ) {
+        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
+                __LINE__ , iss);
+        return;
+    }
+
+    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,
                              regs->r1,
                              regs->r2,
                              regs->r3,
-                             regs->r4,
-                             regs->r5,
-                             regs->r6,
-                             regs->r7,
-                             regs->r8,
-                             regs->r9);
+                             regs->r4);
 }
 
 static void do_cp15_32(struct cpu_user_regs *regs,
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index e840507..d517542 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -3,6 +3,8 @@
 
 #include <public/domctl.h> /* for arch_do_domctl */
 
+#define XEN_HYPERCALL_TAG   0XEA1
+
 #endif /* __ASM_ARM_HYPERCALL_H__ */
 /*
  * Local variables:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:17:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dEO-0002iA-6c; Thu, 23 Feb 2012 18:17:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0dEN-0002gC-49
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:17:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330021039!16156751!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc4MDI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12750 invoked from network); 23 Feb 2012 18:17:20 -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;
	23 Feb 2012 18:17:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183171293"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:15:37 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 13:15:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S0dCV-00039n-Qh; Thu, 23 Feb 2012 18:15:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 23 Feb 2012 18:21:32 +0000
Message-ID: <1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH v2 4/5] arm: use r12 to pass the hypercall 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

Use r12 to pass the hypercall number and r0-r4 for the hypercall
arguments as usual.

Use the ISS to pass an hypervisor specific tag.

Remove passing unused registers to arm_hypercall_table: we don't have 6
arguments hypercalls and we never use 64 bit values as hypercall
arguments, 64 bit values are only contained within structs passed as
arguments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/traps.c            |   16 ++++++++--------
 xen/include/asm-arm/hypercall.h |    2 ++
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 395d0af..44d19ec 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -367,7 +367,6 @@ unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 }
 
 typedef unsigned long arm_hypercall_t(
-    unsigned int, unsigned int, unsigned int, unsigned int, unsigned int,
     unsigned int, unsigned int, unsigned int, unsigned int, unsigned int);
 
 #define HYPERCALL(x)                                        \
@@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 {
     local_irq_enable();
 
-    regs->r0 = arm_hypercall_table[iss](regs->r0,
+    if ( iss != XEN_HYPERCALL_TAG  ) {
+        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
+                __LINE__ , iss);
+        return;
+    }
+
+    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,
                              regs->r1,
                              regs->r2,
                              regs->r3,
-                             regs->r4,
-                             regs->r5,
-                             regs->r6,
-                             regs->r7,
-                             regs->r8,
-                             regs->r9);
+                             regs->r4);
 }
 
 static void do_cp15_32(struct cpu_user_regs *regs,
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index e840507..d517542 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -3,6 +3,8 @@
 
 #include <public/domctl.h> /* for arch_do_domctl */
 
+#define XEN_HYPERCALL_TAG   0XEA1
+
 #endif /* __ASM_ARM_HYPERCALL_H__ */
 /*
  * Local variables:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:45:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ded-0003iD-MZ; Thu, 23 Feb 2012 18:44:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S0ded-0003i8-4n
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:44:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330022666!2351351!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25661 invoked from network); 23 Feb 2012 18:44:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:44:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183176369"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:44:26 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012
	13:44:25 -0500
Message-ID: <4F468908.10908@citrix.com>
Date: Thu, 23 Feb 2012 18:44:24 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [RFC] libxc: xc_hvm_build_with_params() proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I needed to add another parameter to the xc_hvm_build*() family of
functions (the size of the MMIO region) and I has having trouble coming
up with a new name (xc_hvm_build_target_mmio()?) and more parameters
would require even more new names
(xc_hvm_build_target_mem_mmio_colour_wibblyness...) so here's a proposal
for a xc_hvm_build_with_params() call that takes a structure of
parameters for the new HVM domain.

It's a bit clunkly as a bunch of function are added to set parameters in
an opaque structure but this does allow the interface to be backwards
compatible,

Thoughts?  Suggestions on a better pattern?

David

diff -r 2d2825c7ee00 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Thu Feb 09 19:35:11 2012 +0000
+++ b/tools/libxc/xenguest.h	Thu Feb 23 18:26:38 2012 +0000
@@ -164,6 +164,71 @@ int xc_linux_build_mem(xc_interface *xch
                        unsigned int console_evtchn,
                        unsigned long *console_mfn);

+struct xc_hvm_params;
+
+/**
+ * Allocate the HVM parameters for use in a subsequent
+ * xc_hvm_build_from_params() call.
+ * @parm xch libxc context.
+ *
+ * The parameters are all initialized to default values.
+ *
+ * @return the allocated structure or NULL if insufficient memory was
+ * available.
+ */
+struct xc_hvm_params *xc_hvm_params_alloc(xc_interface *xch);
+
+/**
+ * Free the structure previously allocated with xc_hvm_params_alloc().
+ * @parm xch    libxc context.
+ * @parm params the parameters to free.
+ */
+void xc_hvm_params_free(xc_interface *xch, struct xc_hvm_params *params);
+
+/**
+ * Set the memory size parameter.
+ * @parm params   the HVM parameters.
+ * @parm mem_size memory size in \em bytes.
+ */
+void xc_hvm_param_set_mem_size(struct xc_hvm_params *params,
+                               uint64_t mem_size);
+
+/**
+ * Set the memory target parameter.
+ * @parm params    the HVM parameters.
+ * @parm mem_target memory target in \em bytes.
+ */
+void xc_hvm_param_set_mem_target(struct xc_hvm_params *params,
+                                 uint64_t mem_target);
+
+/**
+ * Set the minimum MMIO hole size parameter.
+ * @parm params    the HVM parameters.
+ * @parm mmio_size size of the MMIO hole in \em bytes or 0 to use the
+ *                 default size.
+ */
+void xc_hvm_param_set_mmio_size(struct xc_hvm_params *params,
+                                uint64_t mmio_size);
+
+void xc_hvm_param_set_image(struct xc_hvm_params *params,
+                            void *image, size_t image_size);
+void xc_hvm_param_set_image_file_name(struct xc_hvm_params *params,
+                                      const char *image_file_name);
+
+/**
+ * Build a HVM domain using a set of parameters.
+ * @parm xch    libxc context handle.
+ * @parm domid  domain ID for the new domain.
+ * @parm params parameters for the new domain.
+ *
+ * The memory size and image parameters are required and should be set
+ * with xc_hvm_param_set_mem_size() and xc_hvm_param_set_image() (or
+ * xc_hvm_param_set_image_file()).
+ */
+int xc_hvm_build_with_params(xc_interface *xch,
+                             uint32_t domid,
+                             const struct xc_hvm_params *params);
+
 int xc_hvm_build(xc_interface *xch,
                  uint32_t domid,
                  int memsize,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:45:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ded-0003iD-MZ; Thu, 23 Feb 2012 18:44:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S0ded-0003i8-4n
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:44:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330022666!2351351!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25661 invoked from network); 23 Feb 2012 18:44:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:44:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325480400"; d="scan'208";a="183176369"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 13:44:26 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012
	13:44:25 -0500
Message-ID: <4F468908.10908@citrix.com>
Date: Thu, 23 Feb 2012 18:44:24 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [RFC] libxc: xc_hvm_build_with_params() proposal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I needed to add another parameter to the xc_hvm_build*() family of
functions (the size of the MMIO region) and I has having trouble coming
up with a new name (xc_hvm_build_target_mmio()?) and more parameters
would require even more new names
(xc_hvm_build_target_mem_mmio_colour_wibblyness...) so here's a proposal
for a xc_hvm_build_with_params() call that takes a structure of
parameters for the new HVM domain.

It's a bit clunkly as a bunch of function are added to set parameters in
an opaque structure but this does allow the interface to be backwards
compatible,

Thoughts?  Suggestions on a better pattern?

David

diff -r 2d2825c7ee00 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Thu Feb 09 19:35:11 2012 +0000
+++ b/tools/libxc/xenguest.h	Thu Feb 23 18:26:38 2012 +0000
@@ -164,6 +164,71 @@ int xc_linux_build_mem(xc_interface *xch
                        unsigned int console_evtchn,
                        unsigned long *console_mfn);

+struct xc_hvm_params;
+
+/**
+ * Allocate the HVM parameters for use in a subsequent
+ * xc_hvm_build_from_params() call.
+ * @parm xch libxc context.
+ *
+ * The parameters are all initialized to default values.
+ *
+ * @return the allocated structure or NULL if insufficient memory was
+ * available.
+ */
+struct xc_hvm_params *xc_hvm_params_alloc(xc_interface *xch);
+
+/**
+ * Free the structure previously allocated with xc_hvm_params_alloc().
+ * @parm xch    libxc context.
+ * @parm params the parameters to free.
+ */
+void xc_hvm_params_free(xc_interface *xch, struct xc_hvm_params *params);
+
+/**
+ * Set the memory size parameter.
+ * @parm params   the HVM parameters.
+ * @parm mem_size memory size in \em bytes.
+ */
+void xc_hvm_param_set_mem_size(struct xc_hvm_params *params,
+                               uint64_t mem_size);
+
+/**
+ * Set the memory target parameter.
+ * @parm params    the HVM parameters.
+ * @parm mem_target memory target in \em bytes.
+ */
+void xc_hvm_param_set_mem_target(struct xc_hvm_params *params,
+                                 uint64_t mem_target);
+
+/**
+ * Set the minimum MMIO hole size parameter.
+ * @parm params    the HVM parameters.
+ * @parm mmio_size size of the MMIO hole in \em bytes or 0 to use the
+ *                 default size.
+ */
+void xc_hvm_param_set_mmio_size(struct xc_hvm_params *params,
+                                uint64_t mmio_size);
+
+void xc_hvm_param_set_image(struct xc_hvm_params *params,
+                            void *image, size_t image_size);
+void xc_hvm_param_set_image_file_name(struct xc_hvm_params *params,
+                                      const char *image_file_name);
+
+/**
+ * Build a HVM domain using a set of parameters.
+ * @parm xch    libxc context handle.
+ * @parm domid  domain ID for the new domain.
+ * @parm params parameters for the new domain.
+ *
+ * The memory size and image parameters are required and should be set
+ * with xc_hvm_param_set_mem_size() and xc_hvm_param_set_image() (or
+ * xc_hvm_param_set_image_file()).
+ */
+int xc_hvm_build_with_params(xc_interface *xch,
+                             uint32_t domid,
+                             const struct xc_hvm_params *params);
+
 int xc_hvm_build(xc_interface *xch,
                  uint32_t domid,
                  int memsize,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:54:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:54:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0doA-0003yA-R5; Thu, 23 Feb 2012 18:54:26 +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 1S0do9-0003y3-Fq
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:54:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330023130!61007877!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18814 invoked from network); 23 Feb 2012 18:52:11 -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; 23 Feb 2012 18:52:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1NIsGwx028477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 18:54:17 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
	q1NIsEOj025370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 18:54:15 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
	q1NIsDf5008895; Thu, 23 Feb 2012 12:54:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 10:54:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B05064171C; Thu, 23 Feb 2012 13:50:52 -0500 (EST)
Date: Thu, 23 Feb 2012 13:50:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223185052.GB22922@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
	<20120221213623.GB28154@phenom.dumpdata.com>
	<1329909271.2880.32.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329909271.2880.32.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F468B5A.0052,ss=1,re=0.000,fgs=0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 22, 2012 at 11:14:31AM +0000, Ian Campbell wrote:
> On Tue, 2012-02-21 at 21:36 +0000, Konrad Rzeszutek Wilk wrote:
> [...]
> > > With that in mind, I believe that all of the required information
> > > about discard is still present in blkif.h, but perhaps presented
> > > differently or moved to different sections.  Can you be more
> > > specific about the information that you feel is missing here and
> > > in the other places you noted below?
> > 
> > The original statement about how the backend would determine how
> > to expose this information.
> 
> Please can you quote the actual text of the statements which you think
> are missing and/or should be retained so we know precisely what you are
> talking about.

Ah, it is in the Notes section. However the information that is not present in 4) is

	The discard-alignment parameter indicates how many bytes
	the beginning of the partition is offset from the internal allocation unit's
	natural alignment. Do not confuse this with natural disk alignment offset.

[granted we don't expose the natural disk alignment offset right now, so maybe
that comment is useless]

and 6):
	Devices that support discard functionality may
	internally allocate space using units that are bigger than the logical block
	size.  The discard-granularity parameter indicates the size of the internal
	allocation unit in bytes if reported by the device. Otherwise the
	discard-granularity will be set to match the device's physical block size.
	It is the minimum size you can discard.

[though parts of that comment are there]

> 
> > > The comment block here mirrors the language of all the other feature
> > > flags.  Do you believe they should be changed in some way too?
> > 
> > Well, the desire (mine) is to include as much details (or even more) in the
> > spec so that it can be read as a novel if desired.
> > 
> > But I will defer to Ian - if he is OK then this shouldn't gate
> > the acceptance of this patch which is a step forward.
> 
> Perhaps details which aren't part of the formal spec, e.g.
> implementation tips, details of various OSes implementation choices etc
> could be kept elsewhere, e.g. on the wiki?

On the Document day when I started documenting the PSE != PAT and the page
pinning procedure - I had no idea where to stick that explanation of what goes behind
the scene and how to properly do it so Ian Jackson suggested in the header of
the function. That is an implementation tip of how to properly do it
so you don't shoot yourself in the foot.

Where should something similar for blkback be so it can grow along with the source?

> 
> The problem with including these sorts of things in the spec is that you
> then have to get all pedantic about which statements are normative and
> which are just quirks or details of a particular valid implementation of
> the spec etc.

I cheerish when folks are enthuastic to be pedantic about it so at the end
the result has all t's crossed and i's dotted. Perhaps we should stick
in the document a line saying: "BEWARE: PATCHES TO THIS AREA ARE GOING TO BE
REVIEWED EXTREMELY CLOSE. SO GET YOUR ASBESTOS UNDERWEAR ON!"

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:54:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18:54:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0doA-0003yA-R5; Thu, 23 Feb 2012 18:54:26 +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 1S0do9-0003y3-Fq
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:54:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330023130!61007877!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY0MTk1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18814 invoked from network); 23 Feb 2012 18:52:11 -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; 23 Feb 2012 18:52:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1NIsGwx028477
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 18:54:17 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
	q1NIsEOj025370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 18:54:15 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
	q1NIsDf5008895; Thu, 23 Feb 2012 12:54:14 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 10:54:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B05064171C; Thu, 23 Feb 2012 13:50:52 -0500 (EST)
Date: Thu, 23 Feb 2012 13:50:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120223185052.GB22922@phenom.dumpdata.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
	<20120221213623.GB28154@phenom.dumpdata.com>
	<1329909271.2880.32.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329909271.2880.32.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F468B5A.0052,ss=1,re=0.000,fgs=0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
 documentation of the blkif interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 22, 2012 at 11:14:31AM +0000, Ian Campbell wrote:
> On Tue, 2012-02-21 at 21:36 +0000, Konrad Rzeszutek Wilk wrote:
> [...]
> > > With that in mind, I believe that all of the required information
> > > about discard is still present in blkif.h, but perhaps presented
> > > differently or moved to different sections.  Can you be more
> > > specific about the information that you feel is missing here and
> > > in the other places you noted below?
> > 
> > The original statement about how the backend would determine how
> > to expose this information.
> 
> Please can you quote the actual text of the statements which you think
> are missing and/or should be retained so we know precisely what you are
> talking about.

Ah, it is in the Notes section. However the information that is not present in 4) is

	The discard-alignment parameter indicates how many bytes
	the beginning of the partition is offset from the internal allocation unit's
	natural alignment. Do not confuse this with natural disk alignment offset.

[granted we don't expose the natural disk alignment offset right now, so maybe
that comment is useless]

and 6):
	Devices that support discard functionality may
	internally allocate space using units that are bigger than the logical block
	size.  The discard-granularity parameter indicates the size of the internal
	allocation unit in bytes if reported by the device. Otherwise the
	discard-granularity will be set to match the device's physical block size.
	It is the minimum size you can discard.

[though parts of that comment are there]

> 
> > > The comment block here mirrors the language of all the other feature
> > > flags.  Do you believe they should be changed in some way too?
> > 
> > Well, the desire (mine) is to include as much details (or even more) in the
> > spec so that it can be read as a novel if desired.
> > 
> > But I will defer to Ian - if he is OK then this shouldn't gate
> > the acceptance of this patch which is a step forward.
> 
> Perhaps details which aren't part of the formal spec, e.g.
> implementation tips, details of various OSes implementation choices etc
> could be kept elsewhere, e.g. on the wiki?

On the Document day when I started documenting the PSE != PAT and the page
pinning procedure - I had no idea where to stick that explanation of what goes behind
the scene and how to properly do it so Ian Jackson suggested in the header of
the function. That is an implementation tip of how to properly do it
so you don't shoot yourself in the foot.

Where should something similar for blkback be so it can grow along with the source?

> 
> The problem with including these sorts of things in the spec is that you
> then have to get all pedantic about which statements are normative and
> which are just quirks or details of a particular valid implementation of
> the spec etc.

I cheerish when folks are enthuastic to be pedantic about it so at the end
the result has all t's crossed and i's dotted. Perhaps we should stick
in the document a line saying: "BEWARE: PATCHES TO THIS AREA ARE GOING TO BE
REVIEWED EXTREMELY CLOSE. SO GET YOUR ASBESTOS UNDERWEAR ON!"

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18: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 1S0dp8-000426-9M; Thu, 23 Feb 2012 18:55:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1S0dp6-00041y-I8
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 18:55:24 +0000
Received: from [85.158.139.83:49139] by server-5.bemta-5.messagelabs.com id
	D0/D2-13566-B9B864F4; Thu, 23 Feb 2012 18:55:23 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330023321!5114782!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25857 invoked from network); 23 Feb 2012 18:55:23 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:55:23 -0000
Received: by yenr1 with SMTP id r1so870963yen.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 10:55:21 -0800 (PST)
Received-SPF: pass (google.com: domain of d.vrabel.98@gmail.com designates
	10.236.177.74 as permitted sender) client-ip=10.236.177.74; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of d.vrabel.98@gmail.com
	designates 10.236.177.74 as permitted sender)
	smtp.mail=d.vrabel.98@gmail.com;
	dkim=pass header.i=d.vrabel.98@gmail.com
Received: from mr.google.com ([10.236.177.74])
	by 10.236.177.74 with SMTP id c50mr5149770yhm.130.1330023321782
	(num_hops = 1); Thu, 23 Feb 2012 10:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=4XAsQtpZbHe6hHpToJFwa88qJdrUmVuOGDLmATLvqbw=;
	b=NAIte8EuOENqrmdFfKXFvOZoEn9owHgS/+8Pg8Ckc7OaJdnpsFSoyZh56kEAZ+Wl5r
	W/17DSSm3u0tK+tTE2xBUxzQnOo0j/NhiQlDeQ4/JqtJieBk2+u01BdDVAtdmGhMVLcG
	+9LcduGoJuCYL6FbPQs/FdjrWVOWMdYIqpEhA=
Received: by 10.236.177.74 with SMTP id c50mr4168162yhm.130.1330023321747;
	Thu, 23 Feb 2012 10:55:21 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id k40sm3566812ann.15.2012.02.23.10.55.19
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 10:55:21 -0800 (PST)
Message-ID: <4F468B96.5030703@cantab.net>
Date: Thu, 23 Feb 2012 18:55:18 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Henrik Olsson <henrik@fixme.se>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
In-Reply-To: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/02/12 22:19, Henrik Olsson wrote:
> Hi, i'm having some trouble with assigning memory to my dom0.
> 
> I've added "dom0_mem=8192M" to the xen command line yet "free -m"
> reports only 5686MB total.

[    0.000000] Freeing  6f000-100000 pfn range: 593920 pages freed
[    0.000000] 1-1 mapping on 6f000->100000
[    0.000000] Released 595312 pages of unused memory

This accounts for most of your "missing" memory.  To get it back you
need to adjust the balloon driver's target to the amount of memory you want.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18: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 1S0dp8-000426-9M; Thu, 23 Feb 2012 18:55:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1S0dp6-00041y-I8
	for xen-devel@lists.xen.org; Thu, 23 Feb 2012 18:55:24 +0000
Received: from [85.158.139.83:49139] by server-5.bemta-5.messagelabs.com id
	D0/D2-13566-B9B864F4; Thu, 23 Feb 2012 18:55:23 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330023321!5114782!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25857 invoked from network); 23 Feb 2012 18:55:23 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:55:23 -0000
Received: by yenr1 with SMTP id r1so870963yen.32
	for <xen-devel@lists.xen.org>; Thu, 23 Feb 2012 10:55:21 -0800 (PST)
Received-SPF: pass (google.com: domain of d.vrabel.98@gmail.com designates
	10.236.177.74 as permitted sender) client-ip=10.236.177.74; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of d.vrabel.98@gmail.com
	designates 10.236.177.74 as permitted sender)
	smtp.mail=d.vrabel.98@gmail.com;
	dkim=pass header.i=d.vrabel.98@gmail.com
Received: from mr.google.com ([10.236.177.74])
	by 10.236.177.74 with SMTP id c50mr5149770yhm.130.1330023321782
	(num_hops = 1); Thu, 23 Feb 2012 10:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=4XAsQtpZbHe6hHpToJFwa88qJdrUmVuOGDLmATLvqbw=;
	b=NAIte8EuOENqrmdFfKXFvOZoEn9owHgS/+8Pg8Ckc7OaJdnpsFSoyZh56kEAZ+Wl5r
	W/17DSSm3u0tK+tTE2xBUxzQnOo0j/NhiQlDeQ4/JqtJieBk2+u01BdDVAtdmGhMVLcG
	+9LcduGoJuCYL6FbPQs/FdjrWVOWMdYIqpEhA=
Received: by 10.236.177.74 with SMTP id c50mr4168162yhm.130.1330023321747;
	Thu, 23 Feb 2012 10:55:21 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id k40sm3566812ann.15.2012.02.23.10.55.19
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 10:55:21 -0800 (PST)
Message-ID: <4F468B96.5030703@cantab.net>
Date: Thu, 23 Feb 2012 18:55:18 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Henrik Olsson <henrik@fixme.se>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
In-Reply-To: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/02/12 22:19, Henrik Olsson wrote:
> Hi, i'm having some trouble with assigning memory to my dom0.
> 
> I've added "dom0_mem=8192M" to the xen command line yet "free -m"
> reports only 5686MB total.

[    0.000000] Freeing  6f000-100000 pfn range: 593920 pages freed
[    0.000000] 1-1 mapping on 6f000->100000
[    0.000000] Released 595312 pages of unused memory

This accounts for most of your "missing" memory.  To get it back you
need to adjust the balloon driver's target to the amount of memory you want.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 18:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18: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 1S0dsL-0004Ho-H4; Thu, 23 Feb 2012 18:58:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <harryxiyou@gmail.com>) id 1S0dsJ-0004HM-Ag
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:58:43 +0000
X-Env-Sender: harryxiyou@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330023516!13028703!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5920 invoked from network); 23 Feb 2012 18:58:36 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:58:36 -0000
Received: by bkwq16 with SMTP id q16so598456bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 10:58:36 -0800 (PST)
Received-SPF: pass (google.com: domain of harryxiyou@gmail.com designates
	10.112.102.161 as permitted sender) client-ip=10.112.102.161; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of harryxiyou@gmail.com
	designates 10.112.102.161 as permitted sender)
	smtp.mail=harryxiyou@gmail.com;
	dkim=pass header.i=harryxiyou@gmail.com
Received: from mr.google.com ([10.112.102.161])
	by 10.112.102.161 with SMTP id fp1mr1026118lbb.71.1330023516057
	(num_hops = 1); Thu, 23 Feb 2012 10:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=2sbSVXacb0a+Y0ifHi5J5TsmOHzMtGKlGxhQHFNhNZk=;
	b=B7iEN69lVLWNc7cSs0Jdj/YCZTr17BC+Q+r4Y5+f53ddUwLrZfZN3KGTjKvnMHcw4x
	URK2CiStkkG31ZdkbYM5c3GG/VI76eraBYZImvrm4qjbMr6XmMvxVs/6QbsWg4eeTCc1
	rWbIZ4gFX5IBRMBY22AWzvkuDOUYXYwxTkpe8=
MIME-Version: 1.0
Received: by 10.112.102.161 with SMTP id fp1mr861003lbb.71.1330023515804; Thu,
	23 Feb 2012 10:58:35 -0800 (PST)
Received: by 10.112.81.2 with HTTP; Thu, 23 Feb 2012 10:58:35 -0800 (PST)
Date: Fri, 24 Feb 2012 02:58:35 +0800
Message-ID: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
From: harryxiyou <harryxiyou@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=14dae9d67d3c33d64804b9a63b81
Cc: xen-users@lists.xen.org, cloudxy@googlegroups.com,
	Kang Hua <kanghua151@gmail.com>,
	Harry Wei <harryxiyou@gmail.com>, xen-bugs@lists.xen.org
Subject: [Xen-devel] [XEN]tap-err happens to me
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--14dae9d67d3c33d64804b9a63b81
Content-Type: text/plain; charset=UTF-8

Hi list,

I use xen-4.1.1 for our project. We made a patch for xen-4.1.1 for supporting
our 'HLFS' driver. (The patch is in the attachment, and our project's sources is
located here: http://code.google.com/p/cloudxy/).After adding this patch i do
following  commands with xen (Note, change the drivers/Makefile and
control/Makefile for HLFS directory directing to our hlfs source dir).

# pwd
/root/xen-4.1.1/tools

#make clean
...
#make
...
#make install

And then i restart xencommons and xend.

#/etc/init.d/xencommons restart
#/etc/init.d/xend restart
# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   909     2     r-----    452.4
# xm info
host                   : local00212201021a.zte.com.cn
release                : 2.6.32.39
version                : #1 SMP Sun Feb 19 11:21:09 CST 2012
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 1795
hw_caps                :
bfebfbff:20100800:00000000:00000940:0000e31d:00000000:00000001:00000000
virt_caps              :
total_memory           : 984
free_memory            : 60
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        :
cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
cc_compile_by          : root
cc_compile_domain      : zte.com.cn
cc_compile_date        : Thu Feb 23 23:32:01 CST 2012
xend_config_format     : 4

At last, i do tap-ctl to create our hlfs type device node.

# tap-ctl create -a hlfs:local:///tmp/testenv/testfs
/dev/xen/blktap-2/tapdev0

I see the /var/log/messages like following:

# cat /var/log/messages | tail -10
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Joining mDNS
multicast group on interface peth0.IPv6 with address
fe80::221:22ff:fe01:21a.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Registering new
address record for fe80::221:22ff:fe01:21a on peth0.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: New relevant
interface eth0.IPv6 for mDNS.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Joining mDNS
multicast group on interface eth0.IPv6 with address
fe80::221:22ff:fe01:21a.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Registering new
address record for fe80::221:22ff:fe01:21a on eth0.
Feb 24 02:42:47 local00212201021a dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 24 02:42:47 local00212201021a dhclient: DHCPACK from 192.168.1.1
Feb 24 02:42:47 local00212201021a NET[31575]: /sbin/dhclient-script :
updated /etc/resolv.conf
Feb 24 02:42:47 local00212201021a dhclient: bound to 192.168.1.4 --
renewal in 32898 seconds.
Feb 24 02:52:17 local00212201021a tap-ctl: tap-err:tap_ctl_wait:
tapdisk2[31763] failed, status 127

The log says tapdisk2 happens to an error.

Can anyone give me some suggestions to deal with this problem?




-- 
Thanks
Harry Wei

--14dae9d67d3c33d64804b9a63b81
Content-Type: application/octet-stream; name="cloudxy-0.1.patch"
Content-Disposition: attachment; filename="cloudxy-0.1.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gz05j1lp0

ZGlmZiAtTmF1ciBuZXctcHJqL2Jsa3RhcDIvY29udHJvbC9NYWtlZmlsZSBvbGQtcHJqL2Jsa3Rh
cDIvY29udHJvbC9NYWtlZmlsZQotLS0gbmV3LXByai9ibGt0YXAyL2NvbnRyb2wvTWFrZWZpbGUJ
MjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9sZC1wcmovYmxrdGFwMi9j
b250cm9sL01ha2VmaWxlCTIwMTEtMTEtMjYgMTM6MzQ6MzkuMDAwMDAwMDAwICswODAwCkBAIC01
LDYgKzUsMTAgQEAKIE1JTk9SICAgICAgICAgICAgICA9IDAKIExJQk5BTUUgICAgICAgICAgICA9
IGxpYmJsa3RhcGN0bAogTElCU09OQU1FICAgICAgICAgID0gJChMSUJOQU1FKS5zby4kKE1BSk9S
KQorSExGU19ESVIJCSAgID0gL2hsZnMKK0hMRlNfTE9HIAkJICAgPSAkKEhMRlNfRElSKS8zcGFy
dC9sb2cKK0dMSUJfRElSMSAJCSAgID0gL3Vzci9saWIvZ2xpYi0yLjAvaW5jbHVkZQorR0xJQl9E
SVIyIAkJICAgPSAvdXNyL2luY2x1ZGUvZ2xpYi0yLjAKIAogSUJJTiAgICAgICAgICAgICAgID0g
dGFwLWN0bAogCkBAIC0xMiw4ICsxNiwxMyBAQAogQ0ZMQUdTICAgICAgICAgICAgKz0gLVduby11
bnVzZWQKIENGTEFHUyAgICAgICAgICAgICs9IC1JLi4vaW5jbHVkZSAtSS4uL2RyaXZlcnMKIENG
TEFHUyAgICAgICAgICAgICs9IC1JJChYRU5fSU5DTFVERSkgLUkkKFhFTl9MSUJYQykKK0NGTEFH
UyAgICAgICAgICAgICs9IC1JICQoSExPRykvaW5jbHVkZQogQ0ZMQUdTICAgICAgICAgICAgKz0g
LURfR05VX1NPVVJDRQogQ0ZMQUdTICAgICAgICAgICAgKz0gLURUQVBDVEwKK0NGTEFHUyAgICAJ
CSAgKz0gLUkgJChITEZTX0RJUikvc3JjL2luY2x1ZGUKK0NGTEFHUyAgICAJCSAgKz0gLUkgJChH
TElCX0RJUjEpCitDRkxBR1MgICAgCQkgICs9IC1JICQoR0xJQl9ESVIyKQorQ0ZMQUdTICAgIAkJ
ICArPSAtSSAkKEhMRlNfTE9HKS9pbmNsdWRlCiAKICMgR2V0IGdjYyB0byBnZW5lcmF0ZSB0aGUg
ZGVwZW5kZW5jaWVzIGZvciB1cy4KIENGTEFHUyAgICAgICAgICAgICs9IC1XcCwtTUQsLiQoQEYp
LmQKQEAgLTQ0LDYgKzUzLDkgQEAKIExJQl9TSEFSRUQgPSAkKExJQlNPTkFNRSkuJChNSU5PUikK
IElCSU4gPSB0YXAtY3RsCiAKK0xJQlMgKz0gLUwkKEhMRlNfRElSKS9vdXRwdXQvbGliNjQvIC1s
aGxmcworTElCUyArPSAtTCQoSExGU19MT0cpL2xpYjY0IC1sbG9nNGMKKwogYWxsOiBidWlsZAog
CiBidWlsZDogJChJQklOKSAkKExJQl9TVEFUSUMpICQoTElCX1NIQVJFRCkKQEAgLTU0LDggKzY2
LDggQEAKICQoTElCU09OQU1FKTogJChMSUJfU0hBUkVEKQogCWxuIC1zZiAkPCAkQAogCi10YXAt
Y3RsOiB0YXAtY3RsLm8gJChMSUJOQU1FKS5zbwotCSQoQ0MpICQoQ0ZMQUdTKSAkKExERkxBR1Mp
IC1vICRAICReCit0YXAtY3RsOiB0YXAtY3RsLm8gJChMSUJOQU1FKS5zbyAKKwkkKENDKSAkKENG
TEFHUykgJChMSUJTKSAkKExERkxBR1MpIC1vICRAICReCiAKICQoTElCX1NUQVRJQyk6ICQoQ1RM
X09CSlMpCiAJJChBUikgciAkQCAkXgpkaWZmIC1OYXVyIG5ldy1wcmovYmxrdGFwMi9kcml2ZXJz
L2Jsb2NrLWhsZnMuYyBvbGQtcHJqL2Jsa3RhcDIvZHJpdmVycy9ibG9jay1obGZzLmMKLS0tIG5l
dy1wcmovYmxrdGFwMi9kcml2ZXJzL2Jsb2NrLWhsZnMuYwkxOTcwLTAxLTAxIDA4OjAwOjAwLjAw
MDAwMDAwMCArMDgwMAorKysgb2xkLXByai9ibGt0YXAyL2RyaXZlcnMvYmxvY2staGxmcy5jCTIw
MTEtMTEtMjYgMTQ6MDY6NDQuMDAwMDAwMDAwICswODAwCkBAIC0wLDAgKzEsMjc1IEBACisvKiAK
KyAqIENvcHlyaWdodCAoYykgMjAwNywgWGVuU291cmNlIEluYy4KKyAqIEFsbCByaWdodHMgcmVz
ZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFy
eSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQg
cHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIG1ldDoKKyAqICAgICAq
IFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29w
eXJpZ2h0CisgKiAgICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg
Zm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAgICAgKiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5
IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgICAgbm90aWNl
LCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGlu
IHRoZQorICogICAgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3Zp
ZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqICAgICAqIE5laXRoZXIgdGhlIG5hbWUgb2Yg
WGVuU291cmNlIEluYy4gbm9yIHRoZSBuYW1lcyBvZiBpdHMgY29udHJpYnV0b3JzCisgKiAgICAg
ICBtYXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMgZGVyaXZlZCBmcm9t
IHRoaXMgc29mdHdhcmUKKyAqICAgICAgIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBw
ZXJtaXNzaW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlS
SUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMKKyAqICJBUyBJUyIgQU5EIEFOWSBFWFBSRVNT
IE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UCisgKiBMSU1JVEVEIFRP
LCBUSEUgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBG
T1IKKyAqIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBT
SEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSCisgKiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZP
UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwKKyAqIEVYRU1QTEFS
WSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBU
TywKKyAqIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg
T0YgVVNFLCBEQVRBLCBPUgorICogUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBI
T1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRgorICogTElBQklMSVRZLCBXSEVUSEVS
IElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcKKyAqIE5F
R0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0Ug
T0YgVEhJUworICogU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkg
T0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8ZmNu
dGwuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUg
PHVuaXN0ZC5oPgorI2luY2x1ZGUgPHN5cy9zdGF0dmZzLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQu
aD4KKyNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KKyNpbmNsdWRlIDxzeXMvbW1hbi5oPgorI2luY2x1
ZGUgPHN0cmluZy5oPgorCisjaW5jbHVkZSAiYmxrLmgiCisjaW5jbHVkZSAidGFwZGlzay5oIgor
I2luY2x1ZGUgInRhcGRpc2stZHJpdmVyLmgiCisjaW5jbHVkZSAidGFwZGlzay1pbnRlcmZhY2Uu
aCIKKyNpbmNsdWRlICJhcGkvaGxmcy5oIgorI2luY2x1ZGUgPGdsaWIuaD4KKyNpbmNsdWRlIDxn
bGliL2dzdGRpby5oPgorCisjZGVmaW5lIE1BWF9ITEZTRElTS19TSVpFIDEwMjQwMDAwMDAwIC8q
NTAwRyovCisjaW5jbHVkZSAiaGxmc19sb2cuaCIKKworY2hhciAqaW1nOworbG9uZyBpbnQgICBk
aXNrc2VjdG9yX3NpemU7Citsb25nIGludCAgIGRpc2tzaXplOworbG9uZyBpbnQgICBkaXNraW5m
bzsKK3N0YXRpYyBpbnQgY29ubmVjdGlvbnMgPSAwOworCitzdHJ1Y3QgdGRobGZzX3N0YXRlIHsK
KyAgICAgICBITEZTX0NUUkwgKmhsZnNfY3RybDsKK307CisKKworc3RhdGljIGludCBnZXRfaGxm
c19kaXNrX2luZm8oY29uc3QgY2hhciAqbmFtZSxjaGFyICoqdXJpKXsKKyAgICBpbnQgcmV0ID0g
MDsKKyAgICAqdXJpID0gZ19zdHJkdXAobmFtZSk7CisJRFBSSU5URigidXJpIGlzICVzXG4iLCAq
dXJpKTsKK291dDoKKyAgICByZXR1cm4gcmV0OworfQorCisvKkdldCBJbWFnZSBzaXplLCBzZWNz
aXplKi8KK3N0YXRpYyBpbnQgc2V0X2ltYWdlX2luZm8obG9uZyBpbnQgc2l6ZSx0ZF9kaXNrX2lu
Zm9fdCAqaW5mbykKK3sKKwlpbnQgcmV0OworICAgIGluZm8tPnNpemUgPSh1aW50NjRfdCkgKChz
aXplICogMTAyNCAqIDEwMjQpID4+IFNFQ1RPUl9TSElGVCk7CisgICAgaW5mby0+c2VjdG9yX3Np
emUgPSBERUZBVUxUX1NFQ1RPUl9TSVpFOworCisJRFBSSU5URigiZW50ZXIgZnVuYyAlcyIsIF9f
ZnVuY19fKTsKKwlpbmZvLT5pbmZvID0gMDsKKyAgICAvKlN0b3JlIHZhcmlhYmxlcyBsb2NhbGx5
Ki8KKwlkaXNrc2VjdG9yX3NpemUgPSBpbmZvLT5zZWN0b3Jfc2l6ZTsKKwlkaXNrc2l6ZSAgICAg
ICAgPSBpbmZvLT5zaXplOworCWRpc2tpbmZvICAgICAgICA9IGluZm8tPmluZm87CisJRFBSSU5U
RigiSW1hZ2Ugc2VjdG9yX3NpemU6IFxuXHRbJSJQUkl1NjQiXVxuIiwKKwkJaW5mby0+c2VjdG9y
X3NpemUpOworCURQUklOVEYoImxlYXZlIGZ1bmMgJXMiLCBfX2Z1bmNfXyk7CisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBjaGFyICpidWlsZF9jdHJsX3JlZ2lvbihjb25zdCBjaGFyICp0ZXN0ZnMp
Cit7CisJaW50IGZkLCBvZmZzZXQ7CisJQ1RSTF9SRUdJT05fVCBjdHJsX3JlZ2lvbjsKKwljaGFy
IGN0cmxfcmVnaW9uX2ZpbGVbMTI4XTsKKwljaGFyICphZGRyID0gTlVMTDsKKworCXNwcmludGYo
Y3RybF9yZWdpb25fZmlsZSwgIiVzJXMlcyIsICIvdG1wLyIsIHRlc3RmcywgIi1jdHJsIik7CisJ
Z19yZW1vdmUoY3RybF9yZWdpb25fZmlsZSk7CisJZmQgPSBvcGVuKGN0cmxfcmVnaW9uX2ZpbGUs
IE9fUkRXUiB8IE9fQ1JFQVQsIDA2NjYpOworCWlmIChmZCA9PSAtMSkgeworCQlEUFJJTlRGKCIl
cyAtLSBvcGVuIGZhaWxlZFxuIiwgX19mdW5jX18pOworCQlyZXR1cm4gTlVMTDsKKwl9CisJb2Zm
c2V0ID0gc3lzY29uZihfU0NfUEFHRV9TSVpFKTsKKwlpZiAoLTEgPT0gd3JpdGUoZmQsICZjdHJs
X3JlZ2lvbiwgc2l6ZW9mKENUUkxfUkVHSU9OX1QpKSkgeworCQlEUFJJTlRGKCIlcyAtLSB3cml0
ZSBlcnJvciFcbiIsIF9fZnVuY19fKTsKKwkJcmV0dXJuIE5VTEw7CisJfQorCWFkZHIgPSBtbWFw
KE5VTEwsIHNpemVvZihDVFJMX1JFR0lPTl9UKSwgUFJPVF9XUklURSwgTUFQX1NIQVJFRCwgZmQs
IDApOworCWlmIChhZGRyID09IE5VTEwpIHsKKwkJRFBSSU5URigiJXMgLS0gbW1hcCBmYWlsZWQh
XG4iLCBfX2Z1bmNfXyk7CisJCXJldHVybiBOVUxMOworCX0KKwlyZXR1cm4gYWRkcjsKK30KKwor
LyogIG5hbWUgZm9ybWF0OgorICogIHVyaS9mc25hbWU6c2l6ZShtKQorICogIGVnOiBsb2NhbDov
Ly90bXAvdGVzdGVudi90ZXN0ZnM6MTAyNAorICovCisKKy8qIE9wZW4gdGhlIGRpc2sgZmlsZSBh
bmQgaW5pdGlhbGl6ZSByYW0gc3RhdGUuICovCitpbnQgdGRobGZzX29wZW4gKHRkX2RyaXZlcl90
ICpkcml2ZXIsIGNvbnN0IGNoYXIgKm5hbWUsIHRkX2ZsYWdfdCBmbGFncykKK3sKKwljaGFyICpw
OworCXVpbnQ2NF90IHNpemU7CisgICAgaW50IGhsZnNfZGlza19zaXplOyAvKk0qLworCWludCBp
LCByZXQgPSAwLCBjb3VudCA9IDA7CisJc3RydWN0IHRkaGxmc19zdGF0ZSAqcHJ2ID0gKHN0cnVj
dCB0ZGhsZnNfc3RhdGUgKilkcml2ZXItPmRhdGE7CisgICAgY2hhciAqdXJpID0gTlVMTDsKKwlj
aGFyICpjdHJsX3JlZ2lvbiA9IE5VTEw7CisgICAgSExGU19DVFJMICpjdHJsID0gTlVMTDsKKwlI
TEZTX1NUQVRfVCBzdGF0OworCisJY29ubmVjdGlvbnMrKzsKKwlpZiAoY29ubmVjdGlvbnMgPiAx
KSB7CisJCWRyaXZlci0+aW5mby5zZWN0b3Jfc2l6ZSA9IGRpc2tzZWN0b3Jfc2l6ZTsKKwkJZHJp
dmVyLT5pbmZvLnNpemUgICAgICAgID0gZGlza3NpemU7CisJCWRyaXZlci0+aW5mby5pbmZvICAg
ICAgICA9IGRpc2tpbmZvOyAKKwkJRFBSSU5URigiSW1hZ2UgYWxyZWFkeSBvcGVuLCByZXR1cm5p
bmcgcGFyYW1ldGVyczpcbiIpOworCQlEUFJJTlRGKCJJbWFnZSBzaXplOiBcblx0cHJlIHNlY3Rv
cl9zaGlmdCAgWyVsbHVdXG5cdHBvc3QgIgorCQkJInNlY3Rvcl9zaGlmdCBbJWxsdV1cbiIsCisJ
CQkobG9uZyBsb25nIHVuc2lnbmVkKShkcml2ZXItPmluZm8uc2l6ZSA8PCBTRUNUT1JfU0hJRlQp
LAorCQkJKGxvbmcgbG9uZyB1bnNpZ25lZClkcml2ZXItPmluZm8uc2l6ZSk7CisJCURQUklOVEYo
IkltYWdlIHNlY3Rvcl9zaXplOiBcblx0WyUiUFJJdTY0Il1cbiIsCisJCQlkcml2ZXItPmluZm8u
c2VjdG9yX3NpemUpOworCQlwcmludGYoIkltYWdlIHNpemU6IFxuXHRwcmUgc2VjdG9yX3NoaWZ0
ICBbJWxsdV1cblx0cG9zdCAiCisJCQkic2VjdG9yX3NoaWZ0IFslbGx1XVxuIiwKKwkJCShsb25n
IGxvbmcgdW5zaWduZWQpKGRyaXZlci0+aW5mby5zaXplIDw8IFNFQ1RPUl9TSElGVCksCisJCQko
bG9uZyBsb25nIHVuc2lnbmVkKWRyaXZlci0+aW5mby5zaXplKTsKKwkJcHJpbnRmKCJJbWFnZSBz
ZWN0b3Jfc2l6ZTogXG5cdFslIlBSSXU2NCJdXG4iLAorCQkJZHJpdmVyLT5pbmZvLnNlY3Rvcl9z
aXplKTsKKwkJcHJ2LT5obGZzX2N0cmwgPSBOVUxMOworCQlnb3RvIGRvbmU7CisJfQorICAgIGlm
KDAhPWdldF9obGZzX2Rpc2tfaW5mbyhuYW1lLCZ1cmkpKXsKKyAgICAgICBEUFJJTlRGKCJmYWls
ZWQgdG8gcGFyc2UgaGxmcyBkaXNrIHBhcmFtZXRlcjolcyBcbiIsbmFtZSk7CisgICAgICAgcmV0
ID0gLTE7CisgICAgICAgZ290byBkb25lOworICAgIH0KKwlEUFJJTlRGKCJpbmZvLnNpemUgaXMg
JWxsdSIsIChsb25nIGxvbmcgdW5zaWduZWQpZHJpdmVyLT5pbmZvLnNpemUpOworICAgIERQUklO
VEYoIm5hbWU6JXMsdXJpOiVzXG4iLG5hbWUsdXJpKTsKKwlITE9HX0RFQlVHKCIlcyAtLSB1cmkg
aXMgJXMsIG5hbWUgaXMgJXMiLCBfX2Z1bmNfXywgdXJpLCBuYW1lKTsKKyAgICBjdHJsID0gaW5p
dF9obGZzKHVyaSk7CisJRFBSSU5URigiJXMgLS0gb3ZlciBpbml0IGhsZnMiLCBfX2Z1bmNfXyk7
CisgICAgaWYoY3RybCA9PSBOVUxMKXsKKwkJRFBSSU5URigiVW5hYmxlIHRvIG9wZW4gWyVzXSFc
biIsdXJpKTsKKyAgICAgICAgCXJldCA9IC0xOworICAgICAgICAJZ290byBkb25lOworICAgIH0K
KyAgICBwcnYtPmhsZnNfY3RybCA9IGN0cmw7CisJaWYgKDAgIT0gaGxmc19zdGF0KGN0cmwsICZz
dGF0KSkgeworCQlEUFJJTlRGKCJGYWlsZWQgdG8gZ2V0IGhsZnMncyBzdGF0Iik7CisJCXJldCA9
IC0xOworCQlnb3RvIGRvbmU7CisJfQorCWN0cmxfcmVnaW9uID0gYnVpbGRfY3RybF9yZWdpb24o
c3RhdC5mc25hbWUpOworCURQUklOVEYoIm1tYXAncyBhZGRyIGlzICVwXG4iLCBjdHJsX3JlZ2lv
bik7CisJaWYgKGN0cmxfcmVnaW9uICE9IE5VTEwpIHsKKwkJRFBSSU5URigiJXMgLS0gZW50ZXIg
aGxmc19zZXRfdXNlcl9jdHJsX3JlZ2lvbiIsIF9fZnVuY19fKTsKKwkJaGxmc19zZXRfdXNlcl9j
dHJsX3JlZ2lvbihjdHJsLCAoQ1RSTF9SRUdJT05fVCAqKSBjdHJsX3JlZ2lvbik7CisJCURQUklO
VEYoIiVzIC0tIGlzX3N0YXJ0X2NsZWFuIGlzICVkLCBjb3B5X3dhdGVybGV2ZWwgaXMgJWRcbiIs
IF9fZnVuY19fLCAKKwkJCQlnX2F0b21pY19pbnRfZ2V0KCZjdHJsLT5jdHJsX3JlZ2lvbi0+aXNf
c3RhcnRfY2xlYW4pLCAKKwkJCQkJZ19hdG9taWNfaW50X2dldCgmY3RybC0+Y3RybF9yZWdpb24t
PmNvcHlfd2F0ZXJsZXZlbCkpOworCX0KKwlEUFJJTlRGKCIlcyAtLSBjdHJsX3JlZ2lvbidzIGFk
ZHIgaXMgJXBcbiIsIF9fZnVuY19fLCBjdHJsX3JlZ2lvbik7CisJRFBSSU5URigiJXMgLS0gY3Ry
bC0+Y3RybF9yZWdpb24ncyBhZGRyIGlzICVwXG4iLCBfX2Z1bmNfXywgY3RybC0+Y3RybF9yZWdp
b24pOworCWlmICgwICE9IGhsZnNfb3BlbihjdHJsLCAxKSkgeworCQlEUFJJTlRGKCJVbmFibGUg
dG8gY29ubmVjdCBzdG9yYWdlIVxuIik7CisJCXJldCA9IC0xOworCQlnb3RvIGRvbmU7CisJfQor
CWhsZnNfZGlza19zaXplID0gc3RhdC5tYXhfZnNfc2l6ZTsKKyAgICByZXQgPSBzZXRfaW1hZ2Vf
aW5mbyhobGZzX2Rpc2tfc2l6ZSwmZHJpdmVyLT5pbmZvKTsKKwlpZiAoZHJpdmVyLT5pbmZvLnNp
emUgPiBNQVhfSExGU0RJU0tfU0laRSkgeworCQlEUFJJTlRGKCJEaXNrIGV4Y2VlZHMgbGltaXQs
IG11c3QgYmUgbGVzcyB0aGFuIFslbGRdTUIiLAorCQkJKE1BWF9ITEZTRElTS19TSVpFPDxTRUNU
T1JfU0hJRlQpPj4yMCk7CisJCXJldHVybiAtRU5PTUVNOworCX0KK2RvbmU6CisJcmV0dXJuIHJl
dDsKK30KKwordm9pZCB0ZGhsZnNfcXVldWVfcmVhZCh0ZF9kcml2ZXJfdCAqZHJpdmVyLCB0ZF9y
ZXF1ZXN0X3QgdHJlcSkKK3sKKyAgICBpbnQgcmV0ID0gMDsKKwlzdHJ1Y3QgdGRobGZzX3N0YXRl
ICpwcnYgPSAoc3RydWN0IHRkaGxmc19zdGF0ZSAqKWRyaXZlci0+ZGF0YTsKKwlpbnQgICAgICBz
aXplICAgID0gdHJlcS5zZWNzICogZHJpdmVyLT5pbmZvLnNlY3Rvcl9zaXplOworCXVpbnQ2NF90
IG9mZnNldCAgPSB0cmVxLnNlYyAqICh1aW50NjRfdClkcml2ZXItPmluZm8uc2VjdG9yX3NpemU7
CisgICAgSExGU19DVFJMICpjdHJsID0gcHJ2LT5obGZzX2N0cmw7CisgICAgcmV0ID0gaGxmc19y
ZWFkKGN0cmwsdHJlcS5idWYsc2l6ZSxvZmZzZXQpOworICAgIGlmKHJldCA9PSBzaXplKXsKKwkJ
RFBSSU5URigiJXMgLS0gZW50ZXIgdGRfY29tcGxldGVfcmVxdWVzdCBzZWNvbmQgcGFyYW1ldGVy
IGlzIDAiLCBfX2Z1bmNfXyk7CisJICAgdGRfY29tcGxldGVfcmVxdWVzdCh0cmVxLCAwKTsKKyAg
ICB9ZWxzZXsKKwkJRFBSSU5URigiJXMgLS0gZW50ZXIgdGRfY29tcGxldGVfcmVxdWVzdCBzZWNv
bmQgcGFyYW1ldGVyIGlzIC0xIiwgX19mdW5jX18pOworICAgICAgIHRkX2NvbXBsZXRlX3JlcXVl
c3QodHJlcSwtMSk7IAorICAgIH0KKwlEUFJJTlRGKCIlcyAtLSBpc19zdGFydF9jbGVhbiBpcyAl
ZCwgY29weV93YXRlcmxldmVsIGlzICVkXG4iLCBfX2Z1bmNfXywgCisJCQkJZ19hdG9taWNfaW50
X2dldCgmY3RybC0+Y3RybF9yZWdpb24tPmlzX3N0YXJ0X2NsZWFuKSwgZ19hdG9taWNfaW50X2dl
dCgmY3RybC0+Y3RybF9yZWdpb24tPmNvcHlfd2F0ZXJsZXZlbCkpOworCURQUklOVEYoIiVzIC0t
IGN0cmwtPmN0cmxfcmVnaW9uJ3MgYWRkciBpcyAlcFxuIiwgX19mdW5jX18sIGN0cmwtPmN0cmxf
cmVnaW9uKTsKK30KKwordm9pZCB0ZGhsZnNfcXVldWVfd3JpdGUodGRfZHJpdmVyX3QgKmRyaXZl
ciwgdGRfcmVxdWVzdF90IHRyZXEpCit7CisgICAgaW50IHJldCA9IDA7CisJc3RydWN0IHRkaGxm
c19zdGF0ZSAqcHJ2ID0gKHN0cnVjdCB0ZGhsZnNfc3RhdGUgKilkcml2ZXItPmRhdGE7CisJaW50
ICAgICAgc2l6ZSAgICA9IHRyZXEuc2VjcyAqIGRyaXZlci0+aW5mby5zZWN0b3Jfc2l6ZTsKKwl1
aW50NjRfdCBvZmZzZXQgID0gdHJlcS5zZWMgKiAodWludDY0X3QpZHJpdmVyLT5pbmZvLnNlY3Rv
cl9zaXplOworICAgIEhMRlNfQ1RSTCAqY3RybCA9IHBydi0+aGxmc19jdHJsOworICAgIHJldCA9
IGhsZnNfd3JpdGUoY3RybCx0cmVxLmJ1ZixzaXplLG9mZnNldCk7CisgICAgaWYocmV0ID09IHNp
emUpeworCQlEUFJJTlRGKCIlcyAtLSBlbnRlciB0ZF9jb21wbGV0ZV9yZXF1ZXN0IHNlY29uZCBw
YXJhbWV0ZXIgaXMgMCIsIF9fZnVuY19fKTsKKwkgICB0ZF9jb21wbGV0ZV9yZXF1ZXN0KHRyZXEs
IDApOworICAgIH1lbHNleworCQlEUFJJTlRGKCIlcyAtLSBlbnRlciB0ZF9jb21wbGV0ZV9yZXF1
ZXN0IHNlY29uZCBwYXJhbWV0ZXIgaXMgLTEiLCBfX2Z1bmNfXyk7CisgICAgICAgdGRfY29tcGxl
dGVfcmVxdWVzdCh0cmVxLC0xKTsgCisgICAgfQorCURQUklOVEYoIiVzIC0tIGlzX3N0YXJ0X2Ns
ZWFuIGlzICVkLCBjb3B5X3dhdGVybGV2ZWwgaXMgJWRcbiIsIF9fZnVuY19fLCAKKwkJCQlnX2F0
b21pY19pbnRfZ2V0KCZjdHJsLT5jdHJsX3JlZ2lvbi0+aXNfc3RhcnRfY2xlYW4pLCBnX2F0b21p
Y19pbnRfZ2V0KCZjdHJsLT5jdHJsX3JlZ2lvbi0+Y29weV93YXRlcmxldmVsKSk7CisJRFBSSU5U
RigiJXMgLS0gY3RybC0+Y3RybF9yZWdpb24ncyBhZGRyIGlzICVwXG4iLCBfX2Z1bmNfXywgY3Ry
bC0+Y3RybF9yZWdpb24pOworfQorCitpbnQgdGRobGZzX2Nsb3NlKHRkX2RyaXZlcl90ICpkcml2
ZXIpCit7CisJc3RydWN0IHRkaGxmc19zdGF0ZSAqcHJ2ID0gKHN0cnVjdCB0ZGhsZnNfc3RhdGUg
Kilkcml2ZXItPmRhdGE7CisJSExGU19DVFJMICpjdHJsID0gcHJ2LT5obGZzX2N0cmw7CisJY29u
bmVjdGlvbnMtLTsKKwlobGZzX2Nsb3NlKGN0cmwpOworCWRlaW5pdF9obGZzKGN0cmwpOworCXJl
dHVybiAwOworfQorCitpbnQgdGRobGZzX2dldF9wYXJlbnRfaWQodGRfZHJpdmVyX3QgKmRyaXZl
ciwgdGRfZGlza19pZF90ICppZCkKK3sKKwlyZXR1cm4gVERfTk9fUEFSRU5UOworfQorCitpbnQg
dGRobGZzX3ZhbGlkYXRlX3BhcmVudCh0ZF9kcml2ZXJfdCAqZHJpdmVyLAorCQkJICB0ZF9kcml2
ZXJfdCAqcGRyaXZlciwgdGRfZmxhZ190IGZsYWdzKQoreworCXJldHVybiAtRUlOVkFMOworfQor
CitzdHJ1Y3QgdGFwX2Rpc2sgdGFwZGlza19obGZzID0geworCS5kaXNrX3R5cGUgICAgICAgICAg
PSAidGFwZGlza19obGZzIiwKKwkuZmxhZ3MgICAgICAgICAgICAgID0gMCwKKwkucHJpdmF0ZV9k
YXRhX3NpemUgID0gc2l6ZW9mKHN0cnVjdCB0ZGhsZnNfc3RhdGUpLAorCS50ZF9vcGVuICAgICAg
ICAgICAgPSB0ZGhsZnNfb3BlbiwKKwkudGRfY2xvc2UgICAgICAgICAgID0gdGRobGZzX2Nsb3Nl
LAorCS50ZF9xdWV1ZV9yZWFkICAgICAgPSB0ZGhsZnNfcXVldWVfcmVhZCwKKwkudGRfcXVldWVf
d3JpdGUgICAgID0gdGRobGZzX3F1ZXVlX3dyaXRlLAorCS50ZF9nZXRfcGFyZW50X2lkICAgPSB0
ZGhsZnNfZ2V0X3BhcmVudF9pZCwKKwkudGRfdmFsaWRhdGVfcGFyZW50ID0gdGRobGZzX3ZhbGlk
YXRlX3BhcmVudCwKKwkudGRfZGVidWcgICAgICAgICAgID0gTlVMTCwKK307CmRpZmYgLU5hdXIg
bmV3LXByai9ibGt0YXAyL2RyaXZlcnMvTWFrZWZpbGUgb2xkLXByai9ibGt0YXAyL2RyaXZlcnMv
TWFrZWZpbGUKLS0tIG5ldy1wcmovYmxrdGFwMi9kcml2ZXJzL01ha2VmaWxlCTIwMTEtMTEtMjYg
MTM6MzI6MDYuMDAwMDAwMDAwICswODAwCisrKyBvbGQtcHJqL2Jsa3RhcDIvZHJpdmVycy9NYWtl
ZmlsZQkyMDExLTExLTI2IDEzOjM0OjM5LjAwMDAwMDAwMCArMDgwMApAQCAtMiw2ICsyLDE1IEBA
CiBCTEtUQVBfUk9PVD0gLi4KIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsKIAor
SExGU19ESVIgPSAvaGxmcworSExGU19MT0cgPSAkKEhMRlNfRElSKS8zcGFydC9sb2cKK0hBRE9P
UF9ESVIgPSAkKEhMRlNfRElSKS8zcGFydC9oYWRvb3AKK0dMSUJfRElSMSA9IC91c3IvbGliL2ds
aWItMi4wL2luY2x1ZGUKK0dMSUJfRElSMiA9IC91c3IvaW5jbHVkZS9nbGliLTIuMAorSEFET09Q
X0RJUjEgPSAkKEhBRE9PUF9ESVIpL2luY2x1ZGUKK0hBRE9PUF9ESVIyID0gJChIQURPT1BfRElS
KS9saWI2NAorCisKIExJQlZIRERJUiAgPSAkKEJMS1RBUF9ST09UKS92aGQvbGliCiAKIElCSU4g
ICAgICAgPSB0YXBkaXNrMiB0ZC11dGlsIHRhcGRpc2stY2xpZW50IHRhcGRpc2stc3RyZWFtIHRh
cGRpc2stZGlmZgpAQCAtMTYsMTEgKzI1LDE2IEBACiBDRkxBR1MgICAgKz0gJChDRkxBR1NfbGli
eGVuY3RybCkKIENGTEFHUyAgICArPSAtSSAkKExJQkFJT19ESVIpCiBDRkxBR1MgICAgKz0gLUkg
JChNRU1TSFJfRElSKQorQ0ZMQUdTICAgICs9IC1JICQoSExGU19ESVIpL3NyYy9pbmNsdWRlCitD
RkxBR1MgICAgKz0gLUkgJChHTElCX0RJUjEpCitDRkxBR1MgICAgKz0gLUkgJChHTElCX0RJUjIp
CitDRkxBR1MgICAgKz0gLUkgJChITEZTX0xPRykvaW5jbHVkZQorQ0ZMQUdTICAgICs9IC1JICQo
SEFET09QX0RJUjEpCiBDRkxBR1MgICAgKz0gLURfR05VX1NPVVJDRQogQ0ZMQUdTICAgICs9IC1E
VVNFX05GU19MT0NLUwogCiBpZmVxICgkKENPTkZJR19YODZfNjQpLHkpCi1DRkxBR1MgICAgICAg
ICAgICArPSAtZlBJQworQ0ZMQUdTICAgICs9IC1mUElDCiBlbmRpZgogCiBMSUJTICAgICAgKz0g
LWxydCAtbHoKQEAgLTMzLDYgKzQ3LDEwIEBACiBMSUJTICs9IC1sdXVpZAogZW5kaWYKIAorTElC
UyArPSAtTCQoSExGU19ESVIpL291dHB1dC9saWI2NC8gLWxobGZzCitMSUJTICs9IC1MJChITEZT
X0xPRykvbGliNjQgLWxsb2c0YworTElCUyArPSAtTCQoSEFET09QX0RJUjIpIC1saGRmcworCiBS
RU1VUy1PQkpTICA6PSBibG9jay1yZW11cy5vCiBSRU1VUy1PQkpTICArPSBoYXNodGFibGUubwog
UkVNVVMtT0JKUyAgKz0gaGFzaHRhYmxlX2l0ci5vCkBAIC04MCw2ICs5OCw3IEBACiAKIEJMSy1P
QkpTLXkgIDo9IGJsb2NrLWFpby5vCiBCTEstT0JKUy15ICArPSBibG9jay1yYW0ubworQkxLLU9C
SlMteSAgKz0gYmxvY2staGxmcy5vCiBCTEstT0JKUy15ICArPSBibG9jay1jYWNoZS5vCiBCTEst
T0JKUy15ICArPSBibG9jay12aGQubwogQkxLLU9CSlMteSAgKz0gYmxvY2stbG9nLm8KZGlmZiAt
TmF1ciBuZXctcHJqL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrMi5jIG9sZC1wcmovYmxrdGFwMi9k
cml2ZXJzL3RhcGRpc2syLmMKLS0tIG5ldy1wcmovYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2syLmMJ
MjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9sZC1wcmovYmxrdGFwMi9k
cml2ZXJzL3RhcGRpc2syLmMJMjAxMS0xMS0yNiAxNDowOToxOC4wMDAwMDAwMDAgKzA4MDAKQEAg
LTM4LDYgKzM4LDggQEAKICNpbmNsdWRlICJ0YXBkaXNrLXV0aWxzLmgiCiAjaW5jbHVkZSAidGFw
ZGlzay1zZXJ2ZXIuaCIKICNpbmNsdWRlICJ0YXBkaXNrLWNvbnRyb2wuaCIKKyNpbmNsdWRlICJn
bGliLmgiCisjaW5jbHVkZSAiaGxmc19sb2cuaCIKIAogc3RhdGljIHZvaWQKIHVzYWdlKGNvbnN0
IGNoYXIgKmFwcCwgaW50IGVycikKQEAgLTU0LDcgKzU2LDExIEBACiAKIAljb250cm9sICA9IE5V
TEw7CiAJbm9kYWVtb24gPSAwOwotCisJc2V0ZW52KCJMT0c0Q19SQ1BBVEgiLCAiL3Vzci9zYmlu
LyIsIDEpOworCWlmIChsb2c0Y19pbml0KCkpIHsKKwkJRFBSSU5URigiNzcgbG9nNGMgaW5pdCBm
YWlsZWQhXG4iKTsKKwl9CisJCiAJd2hpbGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJzOkRo
IikpICE9IC0xKSB7CiAJCXN3aXRjaCAoYykgewogCQljYXNlICdEJzoKZGlmZiAtTmF1ciBuZXct
cHJqL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWRpc2t0eXBlLmMgb2xkLXByai9ibGt0YXAyL2Ry
aXZlcnMvdGFwZGlzay1kaXNrdHlwZS5jCi0tLSBuZXctcHJqL2Jsa3RhcDIvZHJpdmVycy90YXBk
aXNrLWRpc2t0eXBlLmMJMjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9s
ZC1wcmovYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2stZGlza3R5cGUuYwkyMDExLTExLTI2IDE0OjEx
OjM2LjAwMDAwMDAwMCArMDgwMApAQCAtMzIsNiArMzIsNyBAQAogCiAjaW5jbHVkZSAidGFwZGlz
ay1kaXNrdHlwZS5oIgogI2luY2x1ZGUgInRhcGRpc2stbWVzc2FnZS5oIgorI2luY2x1ZGUgInRh
cGRpc2suaCIKIAogc3RhdGljIGNvbnN0IGRpc2tfaW5mb190IGFpb19kaXNrID0gewogICAgICAg
ICJhaW8iLApAQCAtODIsMTEgKzgzLDExIEBACiAgICAgICAgMSwKIH07CiAKLXN0YXRpYyBjb25z
dCBkaXNrX2luZm9fdCB2aGRfaW5kZXhfZGlzayA9IHsKKy8qc3RhdGljIGNvbnN0IGRpc2tfaW5m
b190IHZoZF9pbmRleF9kaXNrID0gewogICAgICAgICJ2aGRpIiwKICAgICAgICAidmhkIGluZGV4
IGltYWdlICh2aGRpKSIsCiAgICAgICAgMSwKLX07Cit9OyAqLwogCiBzdGF0aWMgY29uc3QgZGlz
a19pbmZvX3QgbG9nX2Rpc2sgPSB7CiAJImxvZyIsCkBAIC0xMDAsNiArMTAxLDEyIEBACiAgICAg
ICAgMCwKIH07CiAKK3N0YXRpYyBjb25zdCBkaXNrX2luZm9fdCBobGZzX2Rpc2sgPSB7CisgICAg
ICAgImhsZnMiLAorICAgICAgICJobGZzIGRpc2sgcmVwbGljYXRvciAoaGxmcykiLAorICAgICAg
IDAsCit9OworCiBjb25zdCBkaXNrX2luZm9fdCAqdGFwZGlza19kaXNrX3R5cGVzW10gPSB7CiAJ
W0RJU0tfVFlQRV9BSU9dCT0gJmFpb19kaXNrLAogCVtESVNLX1RZUEVfU1lOQ10JPSAmc3luY19k
aXNrLApAQCAtMTEwLDggKzExNyw5IEBACiAJW0RJU0tfVFlQRV9RQ09XXQk9ICZxY293X2Rpc2ss
CiAJW0RJU0tfVFlQRV9CTE9DS19DQUNIRV0gPSAmYmxvY2tfY2FjaGVfZGlzaywKIAlbRElTS19U
WVBFX0xPR10JPSAmbG9nX2Rpc2ssCi0JW0RJU0tfVFlQRV9WSU5ERVhdCT0gJnZoZF9pbmRleF9k
aXNrLAorCS8vW0RJU0tfVFlQRV9WSU5ERVhdCT0gJnZoZF9pbmRleF9kaXNrLAogCVtESVNLX1RZ
UEVfUkVNVVNdCT0gJnJlbXVzX2Rpc2ssCisJW0RJU0tfVFlQRV9ITEZTXQk9ICZobGZzX2Rpc2ss
CiAJMCwKIH07CiAKQEAgLTEyMyw5ICsxMzEsMTAgQEAKIGV4dGVybiBzdHJ1Y3QgdGFwX2Rpc2sg
dGFwZGlza19yYW07CiBleHRlcm4gc3RydWN0IHRhcF9kaXNrIHRhcGRpc2tfcWNvdzsKIGV4dGVy
biBzdHJ1Y3QgdGFwX2Rpc2sgdGFwZGlza19ibG9ja19jYWNoZTsKLWV4dGVybiBzdHJ1Y3QgdGFw
X2Rpc2sgdGFwZGlza192aGRfaW5kZXg7CisvL2V4dGVybiBzdHJ1Y3QgdGFwX2Rpc2sgdGFwZGlz
a192aGRfaW5kZXg7CiBleHRlcm4gc3RydWN0IHRhcF9kaXNrIHRhcGRpc2tfbG9nOwogZXh0ZXJu
IHN0cnVjdCB0YXBfZGlzayB0YXBkaXNrX3JlbXVzOworZXh0ZXJuIHN0cnVjdCB0YXBfZGlzayB0
YXBkaXNrX2hsZnM7CiAKIGNvbnN0IHN0cnVjdCB0YXBfZGlzayAqdGFwZGlza19kaXNrX2RyaXZl
cnNbXSA9IHsKIAlbRElTS19UWVBFX0FJT10gICAgICAgICA9ICZ0YXBkaXNrX2FpbywKQEAgLTEz
Nyw5ICsxNDYsMTAgQEAKIAlbRElTS19UWVBFX1JBTV0gICAgICAgICA9ICZ0YXBkaXNrX3JhbSwK
IAlbRElTS19UWVBFX1FDT1ddICAgICAgICA9ICZ0YXBkaXNrX3Fjb3csCiAJW0RJU0tfVFlQRV9C
TE9DS19DQUNIRV0gPSAmdGFwZGlza19ibG9ja19jYWNoZSwKLQlbRElTS19UWVBFX1ZJTkRFWF0g
ICAgICA9ICZ0YXBkaXNrX3ZoZF9pbmRleCwKKwkvL1tESVNLX1RZUEVfVklOREVYXSAgICAgID0g
JnRhcGRpc2tfdmhkX2luZGV4LAogCVtESVNLX1RZUEVfTE9HXSAgICAgICAgID0gJnRhcGRpc2tf
bG9nLAogCVtESVNLX1RZUEVfUkVNVVNdICAgICAgID0gJnRhcGRpc2tfcmVtdXMsCisJW0RJU0tf
VFlQRV9ITEZTXSAgICAgICA9ICZ0YXBkaXNrX2hsZnMsCiAJMCwKIH07CiAKQEAgLTE0NywxNSAr
MTU3LDI0IEBACiB0YXBkaXNrX2Rpc2t0eXBlX2ZpbmQoY29uc3QgY2hhciAqbmFtZSkKIHsKIAlj
b25zdCBkaXNrX2luZm9fdCAqaW5mbzsKKwljb25zdCBkaXNrX2luZm9fdCAqX2luZm87CiAJaW50
IGk7CiAKIAlmb3IgKGkgPSAwOyBpbmZvID0gdGFwZGlza19kaXNrX3R5cGVzW2ldLCBpbmZvICE9
IE5VTEw7ICsraSkgewotCQlpZiAoc3RyY21wKG5hbWUsIGluZm8tPm5hbWUpKQorCQlEUFJJTlRG
KCI3NyBpIGlzICVkIGluZm8tPm5hbWUgaXMgJXNcbiIsIGksaW5mby0+bmFtZSk7CisJCV9pbmZv
ID0gdGFwZGlza19kaXNrX3R5cGVzWzExXTsKKwkJRFBSSU5URigiNzcgdGFwZGlza19kaXNrX3R5
cGVzWzExXSBpcyAlc1xuIiwgX2luZm8tPm5hbWUpOworCQlpZiAoc3RyY21wKG5hbWUsIGluZm8t
Pm5hbWUpKSB7CisJCQlpZiAoaSA9PSA5KSB7CisJCQkJaSArPSAxOworCQkJfQogCQkJY29udGlu
dWU7CisJCX0KIAorCQlEUFJJTlRGKCI3NyAxIGkgaXMgJWRcbiIsIGkpOwogCQlpZiAoIXRhcGRp
c2tfZGlza19kcml2ZXJzW2ldKQogCQkJcmV0dXJuIC1FTk9TWVM7Ci0KKwkJRFBSSU5URigiNzcg
MiBpIGlzICVkXG4iLCBpKTsKIAkJcmV0dXJuIGk7CiAJfQogCkBAIC0xNjgsMjEgKzE4NywxOSBA
QAogCWNoYXIgbmFtZVtESVNLX1RZUEVfTkFNRV9NQVhdLCAqcHRyOwogCXNpemVfdCBsZW47CiAJ
aW50IHR5cGU7Ci0KKwkKIAlwdHIgPSBzdHJjaHIocGFyYW1zLCAnOicpOwogCWlmICghcHRyKQog
CQlyZXR1cm4gLUVJTlZBTDsKIAogCWxlbiA9IHB0ciAtIHBhcmFtczsKLQogCWlmIChsZW4gPiBz
aXplb2YobmFtZSkgLSAxKQogCQlyZXR1cm4gLUVOQU1FVE9PTE9ORzsKIAogCW1lbXNldChuYW1l
LCAwLCBzaXplb2YobmFtZSkpOwogCXN0cm5jcHkobmFtZSwgcGFyYW1zLCBsZW4pOwotCisJCiAJ
dHlwZSA9IHRhcGRpc2tfZGlza3R5cGVfZmluZChuYW1lKTsKLQogCWlmICh0eXBlID49IDApCiAJ
CSpfcGF0aCA9IHBhcmFtcyArIGxlbiArIDE7CiAKZGlmZiAtTmF1ciBuZXctcHJqL2Jsa3RhcDIv
ZHJpdmVycy90YXBkaXNrLWRpc2t0eXBlLmggb2xkLXByai9ibGt0YXAyL2RyaXZlcnMvdGFwZGlz
ay1kaXNrdHlwZS5oCi0tLSBuZXctcHJqL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWRpc2t0eXBl
LmgJMjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9sZC1wcmovYmxrdGFw
Mi9kcml2ZXJzL3RhcGRpc2stZGlza3R5cGUuaAkyMDExLTExLTI2IDEzOjM0OjM5LjAwMDAwMDAw
MCArMDgwMApAQCAtMzksNyArMzksOCBAQAogI2RlZmluZSBESVNLX1RZUEVfQkxPQ0tfQ0FDSEUg
NwogI2RlZmluZSBESVNLX1RZUEVfTE9HICAgICAgICAgOAogI2RlZmluZSBESVNLX1RZUEVfUkVN
VVMgICAgICAgOQotI2RlZmluZSBESVNLX1RZUEVfVklOREVYICAgICAgMTAKKy8vI2RlZmluZSBE
SVNLX1RZUEVfVklOREVYICAgICAgMTAKKyNkZWZpbmUgRElTS19UWVBFX0hMRlMJICAgICAgMTEK
IAogI2RlZmluZSBESVNLX1RZUEVfTkFNRV9NQVggICAgMzIKIApkaWZmIC1OYXVyIG5ldy1wcmov
cHl0aG9uL3hlbi94ZW5kL3NlcnZlci9CbGt0YXBDb250cm9sbGVyLnB5IG9sZC1wcmovcHl0aG9u
L3hlbi94ZW5kL3NlcnZlci9CbGt0YXBDb250cm9sbGVyLnB5Ci0tLSBuZXctcHJqL3B5dGhvbi94
ZW4veGVuZC9zZXJ2ZXIvQmxrdGFwQ29udHJvbGxlci5weQkyMDExLTExLTI2IDEzOjMyOjA1LjAw
MDAwMDAwMCArMDgwMAorKysgb2xkLXByai9weXRob24veGVuL3hlbmQvc2VydmVyL0Jsa3RhcENv
bnRyb2xsZXIucHkJMjAxMS0xMS0yNiAxMzozMzozMi4wMDAwMDAwMDAgKzA4MDAKQEAgLTI0LDYg
KzI0LDcgQEAKICAgICAncWNvdycsCiAgICAgJ3ZoZCcsCiAgICAgJ3JlbXVzJywKKwknaGxmcycs
CiAgICAgXQogCiBibGt0YXBfZGlza190eXBlcyA9IGJsa3RhcDFfZGlza190eXBlcyArIGJsa3Rh
cDJfZGlza190eXBlcwo=
--14dae9d67d3c33d64804b9a63b81
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--14dae9d67d3c33d64804b9a63b81--


From xen-devel-bounces@lists.xen.org Thu Feb 23 18:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 18: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 1S0dsL-0004Ho-H4; Thu, 23 Feb 2012 18:58:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <harryxiyou@gmail.com>) id 1S0dsJ-0004HM-Ag
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 18:58:43 +0000
X-Env-Sender: harryxiyou@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330023516!13028703!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5920 invoked from network); 23 Feb 2012 18:58:36 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 18:58:36 -0000
Received: by bkwq16 with SMTP id q16so598456bkw.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 10:58:36 -0800 (PST)
Received-SPF: pass (google.com: domain of harryxiyou@gmail.com designates
	10.112.102.161 as permitted sender) client-ip=10.112.102.161; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of harryxiyou@gmail.com
	designates 10.112.102.161 as permitted sender)
	smtp.mail=harryxiyou@gmail.com;
	dkim=pass header.i=harryxiyou@gmail.com
Received: from mr.google.com ([10.112.102.161])
	by 10.112.102.161 with SMTP id fp1mr1026118lbb.71.1330023516057
	(num_hops = 1); Thu, 23 Feb 2012 10:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=2sbSVXacb0a+Y0ifHi5J5TsmOHzMtGKlGxhQHFNhNZk=;
	b=B7iEN69lVLWNc7cSs0Jdj/YCZTr17BC+Q+r4Y5+f53ddUwLrZfZN3KGTjKvnMHcw4x
	URK2CiStkkG31ZdkbYM5c3GG/VI76eraBYZImvrm4qjbMr6XmMvxVs/6QbsWg4eeTCc1
	rWbIZ4gFX5IBRMBY22AWzvkuDOUYXYwxTkpe8=
MIME-Version: 1.0
Received: by 10.112.102.161 with SMTP id fp1mr861003lbb.71.1330023515804; Thu,
	23 Feb 2012 10:58:35 -0800 (PST)
Received: by 10.112.81.2 with HTTP; Thu, 23 Feb 2012 10:58:35 -0800 (PST)
Date: Fri, 24 Feb 2012 02:58:35 +0800
Message-ID: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
From: harryxiyou <harryxiyou@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=14dae9d67d3c33d64804b9a63b81
Cc: xen-users@lists.xen.org, cloudxy@googlegroups.com,
	Kang Hua <kanghua151@gmail.com>,
	Harry Wei <harryxiyou@gmail.com>, xen-bugs@lists.xen.org
Subject: [Xen-devel] [XEN]tap-err happens to me
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--14dae9d67d3c33d64804b9a63b81
Content-Type: text/plain; charset=UTF-8

Hi list,

I use xen-4.1.1 for our project. We made a patch for xen-4.1.1 for supporting
our 'HLFS' driver. (The patch is in the attachment, and our project's sources is
located here: http://code.google.com/p/cloudxy/).After adding this patch i do
following  commands with xen (Note, change the drivers/Makefile and
control/Makefile for HLFS directory directing to our hlfs source dir).

# pwd
/root/xen-4.1.1/tools

#make clean
...
#make
...
#make install

And then i restart xencommons and xend.

#/etc/init.d/xencommons restart
#/etc/init.d/xend restart
# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   909     2     r-----    452.4
# xm info
host                   : local00212201021a.zte.com.cn
release                : 2.6.32.39
version                : #1 SMP Sun Feb 19 11:21:09 CST 2012
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 1795
hw_caps                :
bfebfbff:20100800:00000000:00000940:0000e31d:00000000:00000001:00000000
virt_caps              :
total_memory           : 984
free_memory            : 60
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        :
cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
cc_compile_by          : root
cc_compile_domain      : zte.com.cn
cc_compile_date        : Thu Feb 23 23:32:01 CST 2012
xend_config_format     : 4

At last, i do tap-ctl to create our hlfs type device node.

# tap-ctl create -a hlfs:local:///tmp/testenv/testfs
/dev/xen/blktap-2/tapdev0

I see the /var/log/messages like following:

# cat /var/log/messages | tail -10
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Joining mDNS
multicast group on interface peth0.IPv6 with address
fe80::221:22ff:fe01:21a.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Registering new
address record for fe80::221:22ff:fe01:21a on peth0.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: New relevant
interface eth0.IPv6 for mDNS.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Joining mDNS
multicast group on interface eth0.IPv6 with address
fe80::221:22ff:fe01:21a.
Feb 24 02:42:43 local00212201021a avahi-daemon[4144]: Registering new
address record for fe80::221:22ff:fe01:21a on eth0.
Feb 24 02:42:47 local00212201021a dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 24 02:42:47 local00212201021a dhclient: DHCPACK from 192.168.1.1
Feb 24 02:42:47 local00212201021a NET[31575]: /sbin/dhclient-script :
updated /etc/resolv.conf
Feb 24 02:42:47 local00212201021a dhclient: bound to 192.168.1.4 --
renewal in 32898 seconds.
Feb 24 02:52:17 local00212201021a tap-ctl: tap-err:tap_ctl_wait:
tapdisk2[31763] failed, status 127

The log says tapdisk2 happens to an error.

Can anyone give me some suggestions to deal with this problem?




-- 
Thanks
Harry Wei

--14dae9d67d3c33d64804b9a63b81
Content-Type: application/octet-stream; name="cloudxy-0.1.patch"
Content-Disposition: attachment; filename="cloudxy-0.1.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gz05j1lp0

ZGlmZiAtTmF1ciBuZXctcHJqL2Jsa3RhcDIvY29udHJvbC9NYWtlZmlsZSBvbGQtcHJqL2Jsa3Rh
cDIvY29udHJvbC9NYWtlZmlsZQotLS0gbmV3LXByai9ibGt0YXAyL2NvbnRyb2wvTWFrZWZpbGUJ
MjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9sZC1wcmovYmxrdGFwMi9j
b250cm9sL01ha2VmaWxlCTIwMTEtMTEtMjYgMTM6MzQ6MzkuMDAwMDAwMDAwICswODAwCkBAIC01
LDYgKzUsMTAgQEAKIE1JTk9SICAgICAgICAgICAgICA9IDAKIExJQk5BTUUgICAgICAgICAgICA9
IGxpYmJsa3RhcGN0bAogTElCU09OQU1FICAgICAgICAgID0gJChMSUJOQU1FKS5zby4kKE1BSk9S
KQorSExGU19ESVIJCSAgID0gL2hsZnMKK0hMRlNfTE9HIAkJICAgPSAkKEhMRlNfRElSKS8zcGFy
dC9sb2cKK0dMSUJfRElSMSAJCSAgID0gL3Vzci9saWIvZ2xpYi0yLjAvaW5jbHVkZQorR0xJQl9E
SVIyIAkJICAgPSAvdXNyL2luY2x1ZGUvZ2xpYi0yLjAKIAogSUJJTiAgICAgICAgICAgICAgID0g
dGFwLWN0bAogCkBAIC0xMiw4ICsxNiwxMyBAQAogQ0ZMQUdTICAgICAgICAgICAgKz0gLVduby11
bnVzZWQKIENGTEFHUyAgICAgICAgICAgICs9IC1JLi4vaW5jbHVkZSAtSS4uL2RyaXZlcnMKIENG
TEFHUyAgICAgICAgICAgICs9IC1JJChYRU5fSU5DTFVERSkgLUkkKFhFTl9MSUJYQykKK0NGTEFH
UyAgICAgICAgICAgICs9IC1JICQoSExPRykvaW5jbHVkZQogQ0ZMQUdTICAgICAgICAgICAgKz0g
LURfR05VX1NPVVJDRQogQ0ZMQUdTICAgICAgICAgICAgKz0gLURUQVBDVEwKK0NGTEFHUyAgICAJ
CSAgKz0gLUkgJChITEZTX0RJUikvc3JjL2luY2x1ZGUKK0NGTEFHUyAgICAJCSAgKz0gLUkgJChH
TElCX0RJUjEpCitDRkxBR1MgICAgCQkgICs9IC1JICQoR0xJQl9ESVIyKQorQ0ZMQUdTICAgIAkJ
ICArPSAtSSAkKEhMRlNfTE9HKS9pbmNsdWRlCiAKICMgR2V0IGdjYyB0byBnZW5lcmF0ZSB0aGUg
ZGVwZW5kZW5jaWVzIGZvciB1cy4KIENGTEFHUyAgICAgICAgICAgICs9IC1XcCwtTUQsLiQoQEYp
LmQKQEAgLTQ0LDYgKzUzLDkgQEAKIExJQl9TSEFSRUQgPSAkKExJQlNPTkFNRSkuJChNSU5PUikK
IElCSU4gPSB0YXAtY3RsCiAKK0xJQlMgKz0gLUwkKEhMRlNfRElSKS9vdXRwdXQvbGliNjQvIC1s
aGxmcworTElCUyArPSAtTCQoSExGU19MT0cpL2xpYjY0IC1sbG9nNGMKKwogYWxsOiBidWlsZAog
CiBidWlsZDogJChJQklOKSAkKExJQl9TVEFUSUMpICQoTElCX1NIQVJFRCkKQEAgLTU0LDggKzY2
LDggQEAKICQoTElCU09OQU1FKTogJChMSUJfU0hBUkVEKQogCWxuIC1zZiAkPCAkQAogCi10YXAt
Y3RsOiB0YXAtY3RsLm8gJChMSUJOQU1FKS5zbwotCSQoQ0MpICQoQ0ZMQUdTKSAkKExERkxBR1Mp
IC1vICRAICReCit0YXAtY3RsOiB0YXAtY3RsLm8gJChMSUJOQU1FKS5zbyAKKwkkKENDKSAkKENG
TEFHUykgJChMSUJTKSAkKExERkxBR1MpIC1vICRAICReCiAKICQoTElCX1NUQVRJQyk6ICQoQ1RM
X09CSlMpCiAJJChBUikgciAkQCAkXgpkaWZmIC1OYXVyIG5ldy1wcmovYmxrdGFwMi9kcml2ZXJz
L2Jsb2NrLWhsZnMuYyBvbGQtcHJqL2Jsa3RhcDIvZHJpdmVycy9ibG9jay1obGZzLmMKLS0tIG5l
dy1wcmovYmxrdGFwMi9kcml2ZXJzL2Jsb2NrLWhsZnMuYwkxOTcwLTAxLTAxIDA4OjAwOjAwLjAw
MDAwMDAwMCArMDgwMAorKysgb2xkLXByai9ibGt0YXAyL2RyaXZlcnMvYmxvY2staGxmcy5jCTIw
MTEtMTEtMjYgMTQ6MDY6NDQuMDAwMDAwMDAwICswODAwCkBAIC0wLDAgKzEsMjc1IEBACisvKiAK
KyAqIENvcHlyaWdodCAoYykgMjAwNywgWGVuU291cmNlIEluYy4KKyAqIEFsbCByaWdodHMgcmVz
ZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFy
eSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQg
cHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIG1ldDoKKyAqICAgICAq
IFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29w
eXJpZ2h0CisgKiAgICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg
Zm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAgICAgKiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5
IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgICAgbm90aWNl
LCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGlu
IHRoZQorICogICAgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3Zp
ZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqICAgICAqIE5laXRoZXIgdGhlIG5hbWUgb2Yg
WGVuU291cmNlIEluYy4gbm9yIHRoZSBuYW1lcyBvZiBpdHMgY29udHJpYnV0b3JzCisgKiAgICAg
ICBtYXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMgZGVyaXZlZCBmcm9t
IHRoaXMgc29mdHdhcmUKKyAqICAgICAgIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBw
ZXJtaXNzaW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlS
SUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMKKyAqICJBUyBJUyIgQU5EIEFOWSBFWFBSRVNT
IE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UCisgKiBMSU1JVEVEIFRP
LCBUSEUgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBG
T1IKKyAqIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBT
SEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSCisgKiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZP
UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwKKyAqIEVYRU1QTEFS
WSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBU
TywKKyAqIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg
T0YgVVNFLCBEQVRBLCBPUgorICogUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBI
T1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRgorICogTElBQklMSVRZLCBXSEVUSEVS
IElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcKKyAqIE5F
R0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0Ug
T0YgVEhJUworICogU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkg
T0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8ZmNu
dGwuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUg
PHVuaXN0ZC5oPgorI2luY2x1ZGUgPHN5cy9zdGF0dmZzLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQu
aD4KKyNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KKyNpbmNsdWRlIDxzeXMvbW1hbi5oPgorI2luY2x1
ZGUgPHN0cmluZy5oPgorCisjaW5jbHVkZSAiYmxrLmgiCisjaW5jbHVkZSAidGFwZGlzay5oIgor
I2luY2x1ZGUgInRhcGRpc2stZHJpdmVyLmgiCisjaW5jbHVkZSAidGFwZGlzay1pbnRlcmZhY2Uu
aCIKKyNpbmNsdWRlICJhcGkvaGxmcy5oIgorI2luY2x1ZGUgPGdsaWIuaD4KKyNpbmNsdWRlIDxn
bGliL2dzdGRpby5oPgorCisjZGVmaW5lIE1BWF9ITEZTRElTS19TSVpFIDEwMjQwMDAwMDAwIC8q
NTAwRyovCisjaW5jbHVkZSAiaGxmc19sb2cuaCIKKworY2hhciAqaW1nOworbG9uZyBpbnQgICBk
aXNrc2VjdG9yX3NpemU7Citsb25nIGludCAgIGRpc2tzaXplOworbG9uZyBpbnQgICBkaXNraW5m
bzsKK3N0YXRpYyBpbnQgY29ubmVjdGlvbnMgPSAwOworCitzdHJ1Y3QgdGRobGZzX3N0YXRlIHsK
KyAgICAgICBITEZTX0NUUkwgKmhsZnNfY3RybDsKK307CisKKworc3RhdGljIGludCBnZXRfaGxm
c19kaXNrX2luZm8oY29uc3QgY2hhciAqbmFtZSxjaGFyICoqdXJpKXsKKyAgICBpbnQgcmV0ID0g
MDsKKyAgICAqdXJpID0gZ19zdHJkdXAobmFtZSk7CisJRFBSSU5URigidXJpIGlzICVzXG4iLCAq
dXJpKTsKK291dDoKKyAgICByZXR1cm4gcmV0OworfQorCisvKkdldCBJbWFnZSBzaXplLCBzZWNz
aXplKi8KK3N0YXRpYyBpbnQgc2V0X2ltYWdlX2luZm8obG9uZyBpbnQgc2l6ZSx0ZF9kaXNrX2lu
Zm9fdCAqaW5mbykKK3sKKwlpbnQgcmV0OworICAgIGluZm8tPnNpemUgPSh1aW50NjRfdCkgKChz
aXplICogMTAyNCAqIDEwMjQpID4+IFNFQ1RPUl9TSElGVCk7CisgICAgaW5mby0+c2VjdG9yX3Np
emUgPSBERUZBVUxUX1NFQ1RPUl9TSVpFOworCisJRFBSSU5URigiZW50ZXIgZnVuYyAlcyIsIF9f
ZnVuY19fKTsKKwlpbmZvLT5pbmZvID0gMDsKKyAgICAvKlN0b3JlIHZhcmlhYmxlcyBsb2NhbGx5
Ki8KKwlkaXNrc2VjdG9yX3NpemUgPSBpbmZvLT5zZWN0b3Jfc2l6ZTsKKwlkaXNrc2l6ZSAgICAg
ICAgPSBpbmZvLT5zaXplOworCWRpc2tpbmZvICAgICAgICA9IGluZm8tPmluZm87CisJRFBSSU5U
RigiSW1hZ2Ugc2VjdG9yX3NpemU6IFxuXHRbJSJQUkl1NjQiXVxuIiwKKwkJaW5mby0+c2VjdG9y
X3NpemUpOworCURQUklOVEYoImxlYXZlIGZ1bmMgJXMiLCBfX2Z1bmNfXyk7CisJcmV0dXJuIDA7
Cit9CisKK3N0YXRpYyBjaGFyICpidWlsZF9jdHJsX3JlZ2lvbihjb25zdCBjaGFyICp0ZXN0ZnMp
Cit7CisJaW50IGZkLCBvZmZzZXQ7CisJQ1RSTF9SRUdJT05fVCBjdHJsX3JlZ2lvbjsKKwljaGFy
IGN0cmxfcmVnaW9uX2ZpbGVbMTI4XTsKKwljaGFyICphZGRyID0gTlVMTDsKKworCXNwcmludGYo
Y3RybF9yZWdpb25fZmlsZSwgIiVzJXMlcyIsICIvdG1wLyIsIHRlc3RmcywgIi1jdHJsIik7CisJ
Z19yZW1vdmUoY3RybF9yZWdpb25fZmlsZSk7CisJZmQgPSBvcGVuKGN0cmxfcmVnaW9uX2ZpbGUs
IE9fUkRXUiB8IE9fQ1JFQVQsIDA2NjYpOworCWlmIChmZCA9PSAtMSkgeworCQlEUFJJTlRGKCIl
cyAtLSBvcGVuIGZhaWxlZFxuIiwgX19mdW5jX18pOworCQlyZXR1cm4gTlVMTDsKKwl9CisJb2Zm
c2V0ID0gc3lzY29uZihfU0NfUEFHRV9TSVpFKTsKKwlpZiAoLTEgPT0gd3JpdGUoZmQsICZjdHJs
X3JlZ2lvbiwgc2l6ZW9mKENUUkxfUkVHSU9OX1QpKSkgeworCQlEUFJJTlRGKCIlcyAtLSB3cml0
ZSBlcnJvciFcbiIsIF9fZnVuY19fKTsKKwkJcmV0dXJuIE5VTEw7CisJfQorCWFkZHIgPSBtbWFw
KE5VTEwsIHNpemVvZihDVFJMX1JFR0lPTl9UKSwgUFJPVF9XUklURSwgTUFQX1NIQVJFRCwgZmQs
IDApOworCWlmIChhZGRyID09IE5VTEwpIHsKKwkJRFBSSU5URigiJXMgLS0gbW1hcCBmYWlsZWQh
XG4iLCBfX2Z1bmNfXyk7CisJCXJldHVybiBOVUxMOworCX0KKwlyZXR1cm4gYWRkcjsKK30KKwor
LyogIG5hbWUgZm9ybWF0OgorICogIHVyaS9mc25hbWU6c2l6ZShtKQorICogIGVnOiBsb2NhbDov
Ly90bXAvdGVzdGVudi90ZXN0ZnM6MTAyNAorICovCisKKy8qIE9wZW4gdGhlIGRpc2sgZmlsZSBh
bmQgaW5pdGlhbGl6ZSByYW0gc3RhdGUuICovCitpbnQgdGRobGZzX29wZW4gKHRkX2RyaXZlcl90
ICpkcml2ZXIsIGNvbnN0IGNoYXIgKm5hbWUsIHRkX2ZsYWdfdCBmbGFncykKK3sKKwljaGFyICpw
OworCXVpbnQ2NF90IHNpemU7CisgICAgaW50IGhsZnNfZGlza19zaXplOyAvKk0qLworCWludCBp
LCByZXQgPSAwLCBjb3VudCA9IDA7CisJc3RydWN0IHRkaGxmc19zdGF0ZSAqcHJ2ID0gKHN0cnVj
dCB0ZGhsZnNfc3RhdGUgKilkcml2ZXItPmRhdGE7CisgICAgY2hhciAqdXJpID0gTlVMTDsKKwlj
aGFyICpjdHJsX3JlZ2lvbiA9IE5VTEw7CisgICAgSExGU19DVFJMICpjdHJsID0gTlVMTDsKKwlI
TEZTX1NUQVRfVCBzdGF0OworCisJY29ubmVjdGlvbnMrKzsKKwlpZiAoY29ubmVjdGlvbnMgPiAx
KSB7CisJCWRyaXZlci0+aW5mby5zZWN0b3Jfc2l6ZSA9IGRpc2tzZWN0b3Jfc2l6ZTsKKwkJZHJp
dmVyLT5pbmZvLnNpemUgICAgICAgID0gZGlza3NpemU7CisJCWRyaXZlci0+aW5mby5pbmZvICAg
ICAgICA9IGRpc2tpbmZvOyAKKwkJRFBSSU5URigiSW1hZ2UgYWxyZWFkeSBvcGVuLCByZXR1cm5p
bmcgcGFyYW1ldGVyczpcbiIpOworCQlEUFJJTlRGKCJJbWFnZSBzaXplOiBcblx0cHJlIHNlY3Rv
cl9zaGlmdCAgWyVsbHVdXG5cdHBvc3QgIgorCQkJInNlY3Rvcl9zaGlmdCBbJWxsdV1cbiIsCisJ
CQkobG9uZyBsb25nIHVuc2lnbmVkKShkcml2ZXItPmluZm8uc2l6ZSA8PCBTRUNUT1JfU0hJRlQp
LAorCQkJKGxvbmcgbG9uZyB1bnNpZ25lZClkcml2ZXItPmluZm8uc2l6ZSk7CisJCURQUklOVEYo
IkltYWdlIHNlY3Rvcl9zaXplOiBcblx0WyUiUFJJdTY0Il1cbiIsCisJCQlkcml2ZXItPmluZm8u
c2VjdG9yX3NpemUpOworCQlwcmludGYoIkltYWdlIHNpemU6IFxuXHRwcmUgc2VjdG9yX3NoaWZ0
ICBbJWxsdV1cblx0cG9zdCAiCisJCQkic2VjdG9yX3NoaWZ0IFslbGx1XVxuIiwKKwkJCShsb25n
IGxvbmcgdW5zaWduZWQpKGRyaXZlci0+aW5mby5zaXplIDw8IFNFQ1RPUl9TSElGVCksCisJCQko
bG9uZyBsb25nIHVuc2lnbmVkKWRyaXZlci0+aW5mby5zaXplKTsKKwkJcHJpbnRmKCJJbWFnZSBz
ZWN0b3Jfc2l6ZTogXG5cdFslIlBSSXU2NCJdXG4iLAorCQkJZHJpdmVyLT5pbmZvLnNlY3Rvcl9z
aXplKTsKKwkJcHJ2LT5obGZzX2N0cmwgPSBOVUxMOworCQlnb3RvIGRvbmU7CisJfQorICAgIGlm
KDAhPWdldF9obGZzX2Rpc2tfaW5mbyhuYW1lLCZ1cmkpKXsKKyAgICAgICBEUFJJTlRGKCJmYWls
ZWQgdG8gcGFyc2UgaGxmcyBkaXNrIHBhcmFtZXRlcjolcyBcbiIsbmFtZSk7CisgICAgICAgcmV0
ID0gLTE7CisgICAgICAgZ290byBkb25lOworICAgIH0KKwlEUFJJTlRGKCJpbmZvLnNpemUgaXMg
JWxsdSIsIChsb25nIGxvbmcgdW5zaWduZWQpZHJpdmVyLT5pbmZvLnNpemUpOworICAgIERQUklO
VEYoIm5hbWU6JXMsdXJpOiVzXG4iLG5hbWUsdXJpKTsKKwlITE9HX0RFQlVHKCIlcyAtLSB1cmkg
aXMgJXMsIG5hbWUgaXMgJXMiLCBfX2Z1bmNfXywgdXJpLCBuYW1lKTsKKyAgICBjdHJsID0gaW5p
dF9obGZzKHVyaSk7CisJRFBSSU5URigiJXMgLS0gb3ZlciBpbml0IGhsZnMiLCBfX2Z1bmNfXyk7
CisgICAgaWYoY3RybCA9PSBOVUxMKXsKKwkJRFBSSU5URigiVW5hYmxlIHRvIG9wZW4gWyVzXSFc
biIsdXJpKTsKKyAgICAgICAgCXJldCA9IC0xOworICAgICAgICAJZ290byBkb25lOworICAgIH0K
KyAgICBwcnYtPmhsZnNfY3RybCA9IGN0cmw7CisJaWYgKDAgIT0gaGxmc19zdGF0KGN0cmwsICZz
dGF0KSkgeworCQlEUFJJTlRGKCJGYWlsZWQgdG8gZ2V0IGhsZnMncyBzdGF0Iik7CisJCXJldCA9
IC0xOworCQlnb3RvIGRvbmU7CisJfQorCWN0cmxfcmVnaW9uID0gYnVpbGRfY3RybF9yZWdpb24o
c3RhdC5mc25hbWUpOworCURQUklOVEYoIm1tYXAncyBhZGRyIGlzICVwXG4iLCBjdHJsX3JlZ2lv
bik7CisJaWYgKGN0cmxfcmVnaW9uICE9IE5VTEwpIHsKKwkJRFBSSU5URigiJXMgLS0gZW50ZXIg
aGxmc19zZXRfdXNlcl9jdHJsX3JlZ2lvbiIsIF9fZnVuY19fKTsKKwkJaGxmc19zZXRfdXNlcl9j
dHJsX3JlZ2lvbihjdHJsLCAoQ1RSTF9SRUdJT05fVCAqKSBjdHJsX3JlZ2lvbik7CisJCURQUklO
VEYoIiVzIC0tIGlzX3N0YXJ0X2NsZWFuIGlzICVkLCBjb3B5X3dhdGVybGV2ZWwgaXMgJWRcbiIs
IF9fZnVuY19fLCAKKwkJCQlnX2F0b21pY19pbnRfZ2V0KCZjdHJsLT5jdHJsX3JlZ2lvbi0+aXNf
c3RhcnRfY2xlYW4pLCAKKwkJCQkJZ19hdG9taWNfaW50X2dldCgmY3RybC0+Y3RybF9yZWdpb24t
PmNvcHlfd2F0ZXJsZXZlbCkpOworCX0KKwlEUFJJTlRGKCIlcyAtLSBjdHJsX3JlZ2lvbidzIGFk
ZHIgaXMgJXBcbiIsIF9fZnVuY19fLCBjdHJsX3JlZ2lvbik7CisJRFBSSU5URigiJXMgLS0gY3Ry
bC0+Y3RybF9yZWdpb24ncyBhZGRyIGlzICVwXG4iLCBfX2Z1bmNfXywgY3RybC0+Y3RybF9yZWdp
b24pOworCWlmICgwICE9IGhsZnNfb3BlbihjdHJsLCAxKSkgeworCQlEUFJJTlRGKCJVbmFibGUg
dG8gY29ubmVjdCBzdG9yYWdlIVxuIik7CisJCXJldCA9IC0xOworCQlnb3RvIGRvbmU7CisJfQor
CWhsZnNfZGlza19zaXplID0gc3RhdC5tYXhfZnNfc2l6ZTsKKyAgICByZXQgPSBzZXRfaW1hZ2Vf
aW5mbyhobGZzX2Rpc2tfc2l6ZSwmZHJpdmVyLT5pbmZvKTsKKwlpZiAoZHJpdmVyLT5pbmZvLnNp
emUgPiBNQVhfSExGU0RJU0tfU0laRSkgeworCQlEUFJJTlRGKCJEaXNrIGV4Y2VlZHMgbGltaXQs
IG11c3QgYmUgbGVzcyB0aGFuIFslbGRdTUIiLAorCQkJKE1BWF9ITEZTRElTS19TSVpFPDxTRUNU
T1JfU0hJRlQpPj4yMCk7CisJCXJldHVybiAtRU5PTUVNOworCX0KK2RvbmU6CisJcmV0dXJuIHJl
dDsKK30KKwordm9pZCB0ZGhsZnNfcXVldWVfcmVhZCh0ZF9kcml2ZXJfdCAqZHJpdmVyLCB0ZF9y
ZXF1ZXN0X3QgdHJlcSkKK3sKKyAgICBpbnQgcmV0ID0gMDsKKwlzdHJ1Y3QgdGRobGZzX3N0YXRl
ICpwcnYgPSAoc3RydWN0IHRkaGxmc19zdGF0ZSAqKWRyaXZlci0+ZGF0YTsKKwlpbnQgICAgICBz
aXplICAgID0gdHJlcS5zZWNzICogZHJpdmVyLT5pbmZvLnNlY3Rvcl9zaXplOworCXVpbnQ2NF90
IG9mZnNldCAgPSB0cmVxLnNlYyAqICh1aW50NjRfdClkcml2ZXItPmluZm8uc2VjdG9yX3NpemU7
CisgICAgSExGU19DVFJMICpjdHJsID0gcHJ2LT5obGZzX2N0cmw7CisgICAgcmV0ID0gaGxmc19y
ZWFkKGN0cmwsdHJlcS5idWYsc2l6ZSxvZmZzZXQpOworICAgIGlmKHJldCA9PSBzaXplKXsKKwkJ
RFBSSU5URigiJXMgLS0gZW50ZXIgdGRfY29tcGxldGVfcmVxdWVzdCBzZWNvbmQgcGFyYW1ldGVy
IGlzIDAiLCBfX2Z1bmNfXyk7CisJICAgdGRfY29tcGxldGVfcmVxdWVzdCh0cmVxLCAwKTsKKyAg
ICB9ZWxzZXsKKwkJRFBSSU5URigiJXMgLS0gZW50ZXIgdGRfY29tcGxldGVfcmVxdWVzdCBzZWNv
bmQgcGFyYW1ldGVyIGlzIC0xIiwgX19mdW5jX18pOworICAgICAgIHRkX2NvbXBsZXRlX3JlcXVl
c3QodHJlcSwtMSk7IAorICAgIH0KKwlEUFJJTlRGKCIlcyAtLSBpc19zdGFydF9jbGVhbiBpcyAl
ZCwgY29weV93YXRlcmxldmVsIGlzICVkXG4iLCBfX2Z1bmNfXywgCisJCQkJZ19hdG9taWNfaW50
X2dldCgmY3RybC0+Y3RybF9yZWdpb24tPmlzX3N0YXJ0X2NsZWFuKSwgZ19hdG9taWNfaW50X2dl
dCgmY3RybC0+Y3RybF9yZWdpb24tPmNvcHlfd2F0ZXJsZXZlbCkpOworCURQUklOVEYoIiVzIC0t
IGN0cmwtPmN0cmxfcmVnaW9uJ3MgYWRkciBpcyAlcFxuIiwgX19mdW5jX18sIGN0cmwtPmN0cmxf
cmVnaW9uKTsKK30KKwordm9pZCB0ZGhsZnNfcXVldWVfd3JpdGUodGRfZHJpdmVyX3QgKmRyaXZl
ciwgdGRfcmVxdWVzdF90IHRyZXEpCit7CisgICAgaW50IHJldCA9IDA7CisJc3RydWN0IHRkaGxm
c19zdGF0ZSAqcHJ2ID0gKHN0cnVjdCB0ZGhsZnNfc3RhdGUgKilkcml2ZXItPmRhdGE7CisJaW50
ICAgICAgc2l6ZSAgICA9IHRyZXEuc2VjcyAqIGRyaXZlci0+aW5mby5zZWN0b3Jfc2l6ZTsKKwl1
aW50NjRfdCBvZmZzZXQgID0gdHJlcS5zZWMgKiAodWludDY0X3QpZHJpdmVyLT5pbmZvLnNlY3Rv
cl9zaXplOworICAgIEhMRlNfQ1RSTCAqY3RybCA9IHBydi0+aGxmc19jdHJsOworICAgIHJldCA9
IGhsZnNfd3JpdGUoY3RybCx0cmVxLmJ1ZixzaXplLG9mZnNldCk7CisgICAgaWYocmV0ID09IHNp
emUpeworCQlEUFJJTlRGKCIlcyAtLSBlbnRlciB0ZF9jb21wbGV0ZV9yZXF1ZXN0IHNlY29uZCBw
YXJhbWV0ZXIgaXMgMCIsIF9fZnVuY19fKTsKKwkgICB0ZF9jb21wbGV0ZV9yZXF1ZXN0KHRyZXEs
IDApOworICAgIH1lbHNleworCQlEUFJJTlRGKCIlcyAtLSBlbnRlciB0ZF9jb21wbGV0ZV9yZXF1
ZXN0IHNlY29uZCBwYXJhbWV0ZXIgaXMgLTEiLCBfX2Z1bmNfXyk7CisgICAgICAgdGRfY29tcGxl
dGVfcmVxdWVzdCh0cmVxLC0xKTsgCisgICAgfQorCURQUklOVEYoIiVzIC0tIGlzX3N0YXJ0X2Ns
ZWFuIGlzICVkLCBjb3B5X3dhdGVybGV2ZWwgaXMgJWRcbiIsIF9fZnVuY19fLCAKKwkJCQlnX2F0
b21pY19pbnRfZ2V0KCZjdHJsLT5jdHJsX3JlZ2lvbi0+aXNfc3RhcnRfY2xlYW4pLCBnX2F0b21p
Y19pbnRfZ2V0KCZjdHJsLT5jdHJsX3JlZ2lvbi0+Y29weV93YXRlcmxldmVsKSk7CisJRFBSSU5U
RigiJXMgLS0gY3RybC0+Y3RybF9yZWdpb24ncyBhZGRyIGlzICVwXG4iLCBfX2Z1bmNfXywgY3Ry
bC0+Y3RybF9yZWdpb24pOworfQorCitpbnQgdGRobGZzX2Nsb3NlKHRkX2RyaXZlcl90ICpkcml2
ZXIpCit7CisJc3RydWN0IHRkaGxmc19zdGF0ZSAqcHJ2ID0gKHN0cnVjdCB0ZGhsZnNfc3RhdGUg
Kilkcml2ZXItPmRhdGE7CisJSExGU19DVFJMICpjdHJsID0gcHJ2LT5obGZzX2N0cmw7CisJY29u
bmVjdGlvbnMtLTsKKwlobGZzX2Nsb3NlKGN0cmwpOworCWRlaW5pdF9obGZzKGN0cmwpOworCXJl
dHVybiAwOworfQorCitpbnQgdGRobGZzX2dldF9wYXJlbnRfaWQodGRfZHJpdmVyX3QgKmRyaXZl
ciwgdGRfZGlza19pZF90ICppZCkKK3sKKwlyZXR1cm4gVERfTk9fUEFSRU5UOworfQorCitpbnQg
dGRobGZzX3ZhbGlkYXRlX3BhcmVudCh0ZF9kcml2ZXJfdCAqZHJpdmVyLAorCQkJICB0ZF9kcml2
ZXJfdCAqcGRyaXZlciwgdGRfZmxhZ190IGZsYWdzKQoreworCXJldHVybiAtRUlOVkFMOworfQor
CitzdHJ1Y3QgdGFwX2Rpc2sgdGFwZGlza19obGZzID0geworCS5kaXNrX3R5cGUgICAgICAgICAg
PSAidGFwZGlza19obGZzIiwKKwkuZmxhZ3MgICAgICAgICAgICAgID0gMCwKKwkucHJpdmF0ZV9k
YXRhX3NpemUgID0gc2l6ZW9mKHN0cnVjdCB0ZGhsZnNfc3RhdGUpLAorCS50ZF9vcGVuICAgICAg
ICAgICAgPSB0ZGhsZnNfb3BlbiwKKwkudGRfY2xvc2UgICAgICAgICAgID0gdGRobGZzX2Nsb3Nl
LAorCS50ZF9xdWV1ZV9yZWFkICAgICAgPSB0ZGhsZnNfcXVldWVfcmVhZCwKKwkudGRfcXVldWVf
d3JpdGUgICAgID0gdGRobGZzX3F1ZXVlX3dyaXRlLAorCS50ZF9nZXRfcGFyZW50X2lkICAgPSB0
ZGhsZnNfZ2V0X3BhcmVudF9pZCwKKwkudGRfdmFsaWRhdGVfcGFyZW50ID0gdGRobGZzX3ZhbGlk
YXRlX3BhcmVudCwKKwkudGRfZGVidWcgICAgICAgICAgID0gTlVMTCwKK307CmRpZmYgLU5hdXIg
bmV3LXByai9ibGt0YXAyL2RyaXZlcnMvTWFrZWZpbGUgb2xkLXByai9ibGt0YXAyL2RyaXZlcnMv
TWFrZWZpbGUKLS0tIG5ldy1wcmovYmxrdGFwMi9kcml2ZXJzL01ha2VmaWxlCTIwMTEtMTEtMjYg
MTM6MzI6MDYuMDAwMDAwMDAwICswODAwCisrKyBvbGQtcHJqL2Jsa3RhcDIvZHJpdmVycy9NYWtl
ZmlsZQkyMDExLTExLTI2IDEzOjM0OjM5LjAwMDAwMDAwMCArMDgwMApAQCAtMiw2ICsyLDE1IEBA
CiBCTEtUQVBfUk9PVD0gLi4KIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsKIAor
SExGU19ESVIgPSAvaGxmcworSExGU19MT0cgPSAkKEhMRlNfRElSKS8zcGFydC9sb2cKK0hBRE9P
UF9ESVIgPSAkKEhMRlNfRElSKS8zcGFydC9oYWRvb3AKK0dMSUJfRElSMSA9IC91c3IvbGliL2ds
aWItMi4wL2luY2x1ZGUKK0dMSUJfRElSMiA9IC91c3IvaW5jbHVkZS9nbGliLTIuMAorSEFET09Q
X0RJUjEgPSAkKEhBRE9PUF9ESVIpL2luY2x1ZGUKK0hBRE9PUF9ESVIyID0gJChIQURPT1BfRElS
KS9saWI2NAorCisKIExJQlZIRERJUiAgPSAkKEJMS1RBUF9ST09UKS92aGQvbGliCiAKIElCSU4g
ICAgICAgPSB0YXBkaXNrMiB0ZC11dGlsIHRhcGRpc2stY2xpZW50IHRhcGRpc2stc3RyZWFtIHRh
cGRpc2stZGlmZgpAQCAtMTYsMTEgKzI1LDE2IEBACiBDRkxBR1MgICAgKz0gJChDRkxBR1NfbGli
eGVuY3RybCkKIENGTEFHUyAgICArPSAtSSAkKExJQkFJT19ESVIpCiBDRkxBR1MgICAgKz0gLUkg
JChNRU1TSFJfRElSKQorQ0ZMQUdTICAgICs9IC1JICQoSExGU19ESVIpL3NyYy9pbmNsdWRlCitD
RkxBR1MgICAgKz0gLUkgJChHTElCX0RJUjEpCitDRkxBR1MgICAgKz0gLUkgJChHTElCX0RJUjIp
CitDRkxBR1MgICAgKz0gLUkgJChITEZTX0xPRykvaW5jbHVkZQorQ0ZMQUdTICAgICs9IC1JICQo
SEFET09QX0RJUjEpCiBDRkxBR1MgICAgKz0gLURfR05VX1NPVVJDRQogQ0ZMQUdTICAgICs9IC1E
VVNFX05GU19MT0NLUwogCiBpZmVxICgkKENPTkZJR19YODZfNjQpLHkpCi1DRkxBR1MgICAgICAg
ICAgICArPSAtZlBJQworQ0ZMQUdTICAgICs9IC1mUElDCiBlbmRpZgogCiBMSUJTICAgICAgKz0g
LWxydCAtbHoKQEAgLTMzLDYgKzQ3LDEwIEBACiBMSUJTICs9IC1sdXVpZAogZW5kaWYKIAorTElC
UyArPSAtTCQoSExGU19ESVIpL291dHB1dC9saWI2NC8gLWxobGZzCitMSUJTICs9IC1MJChITEZT
X0xPRykvbGliNjQgLWxsb2c0YworTElCUyArPSAtTCQoSEFET09QX0RJUjIpIC1saGRmcworCiBS
RU1VUy1PQkpTICA6PSBibG9jay1yZW11cy5vCiBSRU1VUy1PQkpTICArPSBoYXNodGFibGUubwog
UkVNVVMtT0JKUyAgKz0gaGFzaHRhYmxlX2l0ci5vCkBAIC04MCw2ICs5OCw3IEBACiAKIEJMSy1P
QkpTLXkgIDo9IGJsb2NrLWFpby5vCiBCTEstT0JKUy15ICArPSBibG9jay1yYW0ubworQkxLLU9C
SlMteSAgKz0gYmxvY2staGxmcy5vCiBCTEstT0JKUy15ICArPSBibG9jay1jYWNoZS5vCiBCTEst
T0JKUy15ICArPSBibG9jay12aGQubwogQkxLLU9CSlMteSAgKz0gYmxvY2stbG9nLm8KZGlmZiAt
TmF1ciBuZXctcHJqL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrMi5jIG9sZC1wcmovYmxrdGFwMi9k
cml2ZXJzL3RhcGRpc2syLmMKLS0tIG5ldy1wcmovYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2syLmMJ
MjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9sZC1wcmovYmxrdGFwMi9k
cml2ZXJzL3RhcGRpc2syLmMJMjAxMS0xMS0yNiAxNDowOToxOC4wMDAwMDAwMDAgKzA4MDAKQEAg
LTM4LDYgKzM4LDggQEAKICNpbmNsdWRlICJ0YXBkaXNrLXV0aWxzLmgiCiAjaW5jbHVkZSAidGFw
ZGlzay1zZXJ2ZXIuaCIKICNpbmNsdWRlICJ0YXBkaXNrLWNvbnRyb2wuaCIKKyNpbmNsdWRlICJn
bGliLmgiCisjaW5jbHVkZSAiaGxmc19sb2cuaCIKIAogc3RhdGljIHZvaWQKIHVzYWdlKGNvbnN0
IGNoYXIgKmFwcCwgaW50IGVycikKQEAgLTU0LDcgKzU2LDExIEBACiAKIAljb250cm9sICA9IE5V
TEw7CiAJbm9kYWVtb24gPSAwOwotCisJc2V0ZW52KCJMT0c0Q19SQ1BBVEgiLCAiL3Vzci9zYmlu
LyIsIDEpOworCWlmIChsb2c0Y19pbml0KCkpIHsKKwkJRFBSSU5URigiNzcgbG9nNGMgaW5pdCBm
YWlsZWQhXG4iKTsKKwl9CisJCiAJd2hpbGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJzOkRo
IikpICE9IC0xKSB7CiAJCXN3aXRjaCAoYykgewogCQljYXNlICdEJzoKZGlmZiAtTmF1ciBuZXct
cHJqL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWRpc2t0eXBlLmMgb2xkLXByai9ibGt0YXAyL2Ry
aXZlcnMvdGFwZGlzay1kaXNrdHlwZS5jCi0tLSBuZXctcHJqL2Jsa3RhcDIvZHJpdmVycy90YXBk
aXNrLWRpc2t0eXBlLmMJMjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9s
ZC1wcmovYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2stZGlza3R5cGUuYwkyMDExLTExLTI2IDE0OjEx
OjM2LjAwMDAwMDAwMCArMDgwMApAQCAtMzIsNiArMzIsNyBAQAogCiAjaW5jbHVkZSAidGFwZGlz
ay1kaXNrdHlwZS5oIgogI2luY2x1ZGUgInRhcGRpc2stbWVzc2FnZS5oIgorI2luY2x1ZGUgInRh
cGRpc2suaCIKIAogc3RhdGljIGNvbnN0IGRpc2tfaW5mb190IGFpb19kaXNrID0gewogICAgICAg
ICJhaW8iLApAQCAtODIsMTEgKzgzLDExIEBACiAgICAgICAgMSwKIH07CiAKLXN0YXRpYyBjb25z
dCBkaXNrX2luZm9fdCB2aGRfaW5kZXhfZGlzayA9IHsKKy8qc3RhdGljIGNvbnN0IGRpc2tfaW5m
b190IHZoZF9pbmRleF9kaXNrID0gewogICAgICAgICJ2aGRpIiwKICAgICAgICAidmhkIGluZGV4
IGltYWdlICh2aGRpKSIsCiAgICAgICAgMSwKLX07Cit9OyAqLwogCiBzdGF0aWMgY29uc3QgZGlz
a19pbmZvX3QgbG9nX2Rpc2sgPSB7CiAJImxvZyIsCkBAIC0xMDAsNiArMTAxLDEyIEBACiAgICAg
ICAgMCwKIH07CiAKK3N0YXRpYyBjb25zdCBkaXNrX2luZm9fdCBobGZzX2Rpc2sgPSB7CisgICAg
ICAgImhsZnMiLAorICAgICAgICJobGZzIGRpc2sgcmVwbGljYXRvciAoaGxmcykiLAorICAgICAg
IDAsCit9OworCiBjb25zdCBkaXNrX2luZm9fdCAqdGFwZGlza19kaXNrX3R5cGVzW10gPSB7CiAJ
W0RJU0tfVFlQRV9BSU9dCT0gJmFpb19kaXNrLAogCVtESVNLX1RZUEVfU1lOQ10JPSAmc3luY19k
aXNrLApAQCAtMTEwLDggKzExNyw5IEBACiAJW0RJU0tfVFlQRV9RQ09XXQk9ICZxY293X2Rpc2ss
CiAJW0RJU0tfVFlQRV9CTE9DS19DQUNIRV0gPSAmYmxvY2tfY2FjaGVfZGlzaywKIAlbRElTS19U
WVBFX0xPR10JPSAmbG9nX2Rpc2ssCi0JW0RJU0tfVFlQRV9WSU5ERVhdCT0gJnZoZF9pbmRleF9k
aXNrLAorCS8vW0RJU0tfVFlQRV9WSU5ERVhdCT0gJnZoZF9pbmRleF9kaXNrLAogCVtESVNLX1RZ
UEVfUkVNVVNdCT0gJnJlbXVzX2Rpc2ssCisJW0RJU0tfVFlQRV9ITEZTXQk9ICZobGZzX2Rpc2ss
CiAJMCwKIH07CiAKQEAgLTEyMyw5ICsxMzEsMTAgQEAKIGV4dGVybiBzdHJ1Y3QgdGFwX2Rpc2sg
dGFwZGlza19yYW07CiBleHRlcm4gc3RydWN0IHRhcF9kaXNrIHRhcGRpc2tfcWNvdzsKIGV4dGVy
biBzdHJ1Y3QgdGFwX2Rpc2sgdGFwZGlza19ibG9ja19jYWNoZTsKLWV4dGVybiBzdHJ1Y3QgdGFw
X2Rpc2sgdGFwZGlza192aGRfaW5kZXg7CisvL2V4dGVybiBzdHJ1Y3QgdGFwX2Rpc2sgdGFwZGlz
a192aGRfaW5kZXg7CiBleHRlcm4gc3RydWN0IHRhcF9kaXNrIHRhcGRpc2tfbG9nOwogZXh0ZXJu
IHN0cnVjdCB0YXBfZGlzayB0YXBkaXNrX3JlbXVzOworZXh0ZXJuIHN0cnVjdCB0YXBfZGlzayB0
YXBkaXNrX2hsZnM7CiAKIGNvbnN0IHN0cnVjdCB0YXBfZGlzayAqdGFwZGlza19kaXNrX2RyaXZl
cnNbXSA9IHsKIAlbRElTS19UWVBFX0FJT10gICAgICAgICA9ICZ0YXBkaXNrX2FpbywKQEAgLTEz
Nyw5ICsxNDYsMTAgQEAKIAlbRElTS19UWVBFX1JBTV0gICAgICAgICA9ICZ0YXBkaXNrX3JhbSwK
IAlbRElTS19UWVBFX1FDT1ddICAgICAgICA9ICZ0YXBkaXNrX3Fjb3csCiAJW0RJU0tfVFlQRV9C
TE9DS19DQUNIRV0gPSAmdGFwZGlza19ibG9ja19jYWNoZSwKLQlbRElTS19UWVBFX1ZJTkRFWF0g
ICAgICA9ICZ0YXBkaXNrX3ZoZF9pbmRleCwKKwkvL1tESVNLX1RZUEVfVklOREVYXSAgICAgID0g
JnRhcGRpc2tfdmhkX2luZGV4LAogCVtESVNLX1RZUEVfTE9HXSAgICAgICAgID0gJnRhcGRpc2tf
bG9nLAogCVtESVNLX1RZUEVfUkVNVVNdICAgICAgID0gJnRhcGRpc2tfcmVtdXMsCisJW0RJU0tf
VFlQRV9ITEZTXSAgICAgICA9ICZ0YXBkaXNrX2hsZnMsCiAJMCwKIH07CiAKQEAgLTE0NywxNSAr
MTU3LDI0IEBACiB0YXBkaXNrX2Rpc2t0eXBlX2ZpbmQoY29uc3QgY2hhciAqbmFtZSkKIHsKIAlj
b25zdCBkaXNrX2luZm9fdCAqaW5mbzsKKwljb25zdCBkaXNrX2luZm9fdCAqX2luZm87CiAJaW50
IGk7CiAKIAlmb3IgKGkgPSAwOyBpbmZvID0gdGFwZGlza19kaXNrX3R5cGVzW2ldLCBpbmZvICE9
IE5VTEw7ICsraSkgewotCQlpZiAoc3RyY21wKG5hbWUsIGluZm8tPm5hbWUpKQorCQlEUFJJTlRG
KCI3NyBpIGlzICVkIGluZm8tPm5hbWUgaXMgJXNcbiIsIGksaW5mby0+bmFtZSk7CisJCV9pbmZv
ID0gdGFwZGlza19kaXNrX3R5cGVzWzExXTsKKwkJRFBSSU5URigiNzcgdGFwZGlza19kaXNrX3R5
cGVzWzExXSBpcyAlc1xuIiwgX2luZm8tPm5hbWUpOworCQlpZiAoc3RyY21wKG5hbWUsIGluZm8t
Pm5hbWUpKSB7CisJCQlpZiAoaSA9PSA5KSB7CisJCQkJaSArPSAxOworCQkJfQogCQkJY29udGlu
dWU7CisJCX0KIAorCQlEUFJJTlRGKCI3NyAxIGkgaXMgJWRcbiIsIGkpOwogCQlpZiAoIXRhcGRp
c2tfZGlza19kcml2ZXJzW2ldKQogCQkJcmV0dXJuIC1FTk9TWVM7Ci0KKwkJRFBSSU5URigiNzcg
MiBpIGlzICVkXG4iLCBpKTsKIAkJcmV0dXJuIGk7CiAJfQogCkBAIC0xNjgsMjEgKzE4NywxOSBA
QAogCWNoYXIgbmFtZVtESVNLX1RZUEVfTkFNRV9NQVhdLCAqcHRyOwogCXNpemVfdCBsZW47CiAJ
aW50IHR5cGU7Ci0KKwkKIAlwdHIgPSBzdHJjaHIocGFyYW1zLCAnOicpOwogCWlmICghcHRyKQog
CQlyZXR1cm4gLUVJTlZBTDsKIAogCWxlbiA9IHB0ciAtIHBhcmFtczsKLQogCWlmIChsZW4gPiBz
aXplb2YobmFtZSkgLSAxKQogCQlyZXR1cm4gLUVOQU1FVE9PTE9ORzsKIAogCW1lbXNldChuYW1l
LCAwLCBzaXplb2YobmFtZSkpOwogCXN0cm5jcHkobmFtZSwgcGFyYW1zLCBsZW4pOwotCisJCiAJ
dHlwZSA9IHRhcGRpc2tfZGlza3R5cGVfZmluZChuYW1lKTsKLQogCWlmICh0eXBlID49IDApCiAJ
CSpfcGF0aCA9IHBhcmFtcyArIGxlbiArIDE7CiAKZGlmZiAtTmF1ciBuZXctcHJqL2Jsa3RhcDIv
ZHJpdmVycy90YXBkaXNrLWRpc2t0eXBlLmggb2xkLXByai9ibGt0YXAyL2RyaXZlcnMvdGFwZGlz
ay1kaXNrdHlwZS5oCi0tLSBuZXctcHJqL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWRpc2t0eXBl
LmgJMjAxMS0xMS0yNiAxMzozMjowNi4wMDAwMDAwMDAgKzA4MDAKKysrIG9sZC1wcmovYmxrdGFw
Mi9kcml2ZXJzL3RhcGRpc2stZGlza3R5cGUuaAkyMDExLTExLTI2IDEzOjM0OjM5LjAwMDAwMDAw
MCArMDgwMApAQCAtMzksNyArMzksOCBAQAogI2RlZmluZSBESVNLX1RZUEVfQkxPQ0tfQ0FDSEUg
NwogI2RlZmluZSBESVNLX1RZUEVfTE9HICAgICAgICAgOAogI2RlZmluZSBESVNLX1RZUEVfUkVN
VVMgICAgICAgOQotI2RlZmluZSBESVNLX1RZUEVfVklOREVYICAgICAgMTAKKy8vI2RlZmluZSBE
SVNLX1RZUEVfVklOREVYICAgICAgMTAKKyNkZWZpbmUgRElTS19UWVBFX0hMRlMJICAgICAgMTEK
IAogI2RlZmluZSBESVNLX1RZUEVfTkFNRV9NQVggICAgMzIKIApkaWZmIC1OYXVyIG5ldy1wcmov
cHl0aG9uL3hlbi94ZW5kL3NlcnZlci9CbGt0YXBDb250cm9sbGVyLnB5IG9sZC1wcmovcHl0aG9u
L3hlbi94ZW5kL3NlcnZlci9CbGt0YXBDb250cm9sbGVyLnB5Ci0tLSBuZXctcHJqL3B5dGhvbi94
ZW4veGVuZC9zZXJ2ZXIvQmxrdGFwQ29udHJvbGxlci5weQkyMDExLTExLTI2IDEzOjMyOjA1LjAw
MDAwMDAwMCArMDgwMAorKysgb2xkLXByai9weXRob24veGVuL3hlbmQvc2VydmVyL0Jsa3RhcENv
bnRyb2xsZXIucHkJMjAxMS0xMS0yNiAxMzozMzozMi4wMDAwMDAwMDAgKzA4MDAKQEAgLTI0LDYg
KzI0LDcgQEAKICAgICAncWNvdycsCiAgICAgJ3ZoZCcsCiAgICAgJ3JlbXVzJywKKwknaGxmcycs
CiAgICAgXQogCiBibGt0YXBfZGlza190eXBlcyA9IGJsa3RhcDFfZGlza190eXBlcyArIGJsa3Rh
cDJfZGlza190eXBlcwo=
--14dae9d67d3c33d64804b9a63b81
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--14dae9d67d3c33d64804b9a63b81--


From xen-devel-bounces@lists.xen.org Thu Feb 23 19:04:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dxV-0004kx-I0; Thu, 23 Feb 2012 19:04:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1S0dxU-0004kc-Ca
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:04:04 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330023837!15254370!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3083 invoked from network); 23 Feb 2012 19:03:58 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 19:03:58 -0000
Received: by yenm7 with SMTP id m7so11079276yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 11:03:57 -0800 (PST)
Received-SPF: pass (google.com: domain of d.vrabel.98@gmail.com designates
	10.236.76.133 as permitted sender) client-ip=10.236.76.133; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of d.vrabel.98@gmail.com
	designates 10.236.76.133 as permitted sender)
	smtp.mail=d.vrabel.98@gmail.com;
	dkim=pass header.i=d.vrabel.98@gmail.com
Received: from mr.google.com ([10.236.76.133])
	by 10.236.76.133 with SMTP id b5mr1732292yhe.0.1330023837215 (num_hops
	= 1); Thu, 23 Feb 2012 11:03:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=vx6bYELs9AFHyru1hZdGt9RZO4dBK1Mqh44eT6m66sY=;
	b=kfmvmMrno8RnjSdrZJ015VSPb7ySQhoGv67UaP4YaUrR6QWf2e79drBSkfvQlupk1m
	L865e/2Ozc9lHm2b3tV45N+51xfmU1SGajNpwab7QqffhDO+vJFGMBcOuvSpqxQNvVOC
	MVdtHQfVpO0lTANp/94zrIFWIh5wNUI5M9Yxs=
Received: by 10.236.76.133 with SMTP id b5mr1409845yhe.0.1330023837177;
	Thu, 23 Feb 2012 11:03:57 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id s10sm3601499anl.17.2012.02.23.11.03.56
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 11:03:56 -0800 (PST)
Message-ID: <4F468D9A.3050000@cantab.net>
Date: Thu, 23 Feb 2012 19:03:54 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
In-Reply-To: <ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02 of 10] arm: implement udelay()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/02/12 17:40, Tim Deegan wrote:
> arm: implement udelay()
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
[...]
> diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/time.c
> --- a/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -171,6 +171,16 @@ void __cpuinit init_timer_interrupt(void
>      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
>  }
>  
> +/* Wait a set number of microseconds */
> +void udelay(unsigned long usecs)
> +{
> +    s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
> +    do {
> +        dsb();
> +        isb();

What are these barriers for?

David

> +    } while ( get_s_time() - deadline < 0 );
> +}
> +
>  /*
>   * Local variables:
>   * mode: C

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:04:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0dxV-0004kx-I0; Thu, 23 Feb 2012 19:04:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1S0dxU-0004kc-Ca
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:04:04 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330023837!15254370!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3083 invoked from network); 23 Feb 2012 19:03:58 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 19:03:58 -0000
Received: by yenm7 with SMTP id m7so11079276yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 11:03:57 -0800 (PST)
Received-SPF: pass (google.com: domain of d.vrabel.98@gmail.com designates
	10.236.76.133 as permitted sender) client-ip=10.236.76.133; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of d.vrabel.98@gmail.com
	designates 10.236.76.133 as permitted sender)
	smtp.mail=d.vrabel.98@gmail.com;
	dkim=pass header.i=d.vrabel.98@gmail.com
Received: from mr.google.com ([10.236.76.133])
	by 10.236.76.133 with SMTP id b5mr1732292yhe.0.1330023837215 (num_hops
	= 1); Thu, 23 Feb 2012 11:03:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=vx6bYELs9AFHyru1hZdGt9RZO4dBK1Mqh44eT6m66sY=;
	b=kfmvmMrno8RnjSdrZJ015VSPb7ySQhoGv67UaP4YaUrR6QWf2e79drBSkfvQlupk1m
	L865e/2Ozc9lHm2b3tV45N+51xfmU1SGajNpwab7QqffhDO+vJFGMBcOuvSpqxQNvVOC
	MVdtHQfVpO0lTANp/94zrIFWIh5wNUI5M9Yxs=
Received: by 10.236.76.133 with SMTP id b5mr1409845yhe.0.1330023837177;
	Thu, 23 Feb 2012 11:03:57 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id s10sm3601499anl.17.2012.02.23.11.03.56
	(version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 11:03:56 -0800 (PST)
Message-ID: <4F468D9A.3050000@cantab.net>
Date: Thu, 23 Feb 2012 19:03:54 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
In-Reply-To: <ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02 of 10] arm: implement udelay()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/02/12 17:40, Tim Deegan wrote:
> arm: implement udelay()
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
[...]
> diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/time.c
> --- a/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -171,6 +171,16 @@ void __cpuinit init_timer_interrupt(void
>      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
>  }
>  
> +/* Wait a set number of microseconds */
> +void udelay(unsigned long usecs)
> +{
> +    s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
> +    do {
> +        dsb();
> +        isb();

What are these barriers for?

David

> +    } while ( get_s_time() - deadline < 0 );
> +}
> +
>  /*
>   * Local variables:
>   * mode: C

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:16:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0e9I-0005Kz-Kd; Thu, 23 Feb 2012 19:16:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0e9G-0005Kq-Le
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:16:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330024568!16637756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25284 invoked from network); 23 Feb 2012 19:16:08 -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;
	23 Feb 2012 19:16:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10905964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 19:16:01 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 19:16:01 +0000
Message-ID: <1330024560.10008.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 23 Feb 2012 19:16:00 +0000
In-Reply-To: <1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10] arm: More SMP bringup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
[...]
> +	/* Signal the next non-boot CPU to come and join us here */
> +	ldr   r0, =boot_gate         /* VA of gate */
> +	add   r0, r0, r10            /* PA of gate */
> +	mov   r1, #0                 /* (0 == unlocked) */
> +	str   r1, [r0]
> +	dsb
> +	isb
> +	sev

Here we have released the next CPU from the holding pen...

[...]
> +	/* Non-boot CPUs report that they've got this far */
> +	ldr   r0, =ready_cpus
> +	ldr   r1, [r0]               /* Read count of ready CPUs */
> +	add   r1, r1, #1             /* ++ */
> +	str   r1, [r0]               /* Writeback */
> +	dsb

... and here we do a non-atomic update of a shared variable.

What prevents the following CPU from catching us up and conflicting
here?

Would we be better signalling the next CPU after the increment instead?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:16:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0e9I-0005Kz-Kd; Thu, 23 Feb 2012 19:16:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0e9G-0005Kq-Le
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:16:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330024568!16637756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25284 invoked from network); 23 Feb 2012 19:16:08 -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;
	23 Feb 2012 19:16:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10905964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 19:16:01 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 19:16:01 +0000
Message-ID: <1330024560.10008.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 23 Feb 2012 19:16:00 +0000
In-Reply-To: <1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10] arm: More SMP bringup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
[...]
> +	/* Signal the next non-boot CPU to come and join us here */
> +	ldr   r0, =boot_gate         /* VA of gate */
> +	add   r0, r0, r10            /* PA of gate */
> +	mov   r1, #0                 /* (0 == unlocked) */
> +	str   r1, [r0]
> +	dsb
> +	isb
> +	sev

Here we have released the next CPU from the holding pen...

[...]
> +	/* Non-boot CPUs report that they've got this far */
> +	ldr   r0, =ready_cpus
> +	ldr   r1, [r0]               /* Read count of ready CPUs */
> +	add   r1, r1, #1             /* ++ */
> +	str   r1, [r0]               /* Writeback */
> +	dsb

... and here we do a non-atomic update of a shared variable.

What prevents the following CPU from catching us up and conflicting
here?

Would we be better signalling the next CPU after the increment instead?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:30:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19: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 1S0eMH-0005iL-2C; Thu, 23 Feb 2012 19:29:41 +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 1S0eMF-0005iG-NA
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:29:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330025308!62370115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17710 invoked from network); 23 Feb 2012 19:28:28 -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;
	23 Feb 2012 19:28:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10906172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 19:29:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 19:29:35 +0000
Message-ID: <1330025374.10008.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 23 Feb 2012 19:29:34 +0000
In-Reply-To: <1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] arm: use r12 to pass the hypercall
	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

On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number and r0-r4 for the hypercall
> arguments as usual.

Strictly speaking "as usual" in the ARM calling convention would be args
in r0-r3 and the fifth (and subsequent) arguments on the stack. However
we are free to implement our own convention for hypercalls and avoiding
arguments on the stack is a good idea.

Please could you add a comment describing the interface. X86 documents
this in xen/include/public/arch-x86/xen-x86_{32,64}.h so I suppose
xen/include/public/arch-arm.h is appropriate

We should define precisely which registers are clobbered by a hypercall.
X86 clobbers exactly those arguments registers which are used for that
hypercall but perhaps we can simplify and always clobber r0..r4,r12
(plus any other caller saved registers in the usual calling convention,
just for sanity). r0..r3,r12 are already clobbered in the normal calling
convention so the only difference would be clobbering r4 which is
normally callee saved (but is also not normally used to pass arguments).

We should explicitly clobber whatever we say we will too in a debug
build.

I've trimmed the quote already so I'll mention it here instead:
XEN_HYPERCALL_TAG should be defined in the public interface too not in
the private asm headers.

> @@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
>  {
>      local_irq_enable();
>  
> -    regs->r0 = arm_hypercall_table[iss](regs->r0,
> +    if ( iss != XEN_HYPERCALL_TAG  ) {
> +        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
> +                __LINE__ , iss);

	regs->r0 = -EINVAL;

here I think.

> +        return;
> +    }
> +
> +    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,

It's an existing issue but we need to check that
arm_hypercall_table[regs->r12] is non-NULL here and return -ENOSYS (by
setting r0) if it is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:30:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19: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 1S0eMH-0005iL-2C; Thu, 23 Feb 2012 19:29:41 +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 1S0eMF-0005iG-NA
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:29:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330025308!62370115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17710 invoked from network); 23 Feb 2012 19:28:28 -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;
	23 Feb 2012 19:28:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10906172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 19:29:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 23 Feb 2012 19:29:35 +0000
Message-ID: <1330025374.10008.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 23 Feb 2012 19:29:34 +0000
In-Reply-To: <1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] arm: use r12 to pass the hypercall
	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

On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number and r0-r4 for the hypercall
> arguments as usual.

Strictly speaking "as usual" in the ARM calling convention would be args
in r0-r3 and the fifth (and subsequent) arguments on the stack. However
we are free to implement our own convention for hypercalls and avoiding
arguments on the stack is a good idea.

Please could you add a comment describing the interface. X86 documents
this in xen/include/public/arch-x86/xen-x86_{32,64}.h so I suppose
xen/include/public/arch-arm.h is appropriate

We should define precisely which registers are clobbered by a hypercall.
X86 clobbers exactly those arguments registers which are used for that
hypercall but perhaps we can simplify and always clobber r0..r4,r12
(plus any other caller saved registers in the usual calling convention,
just for sanity). r0..r3,r12 are already clobbered in the normal calling
convention so the only difference would be clobbering r4 which is
normally callee saved (but is also not normally used to pass arguments).

We should explicitly clobber whatever we say we will too in a debug
build.

I've trimmed the quote already so I'll mention it here instead:
XEN_HYPERCALL_TAG should be defined in the public interface too not in
the private asm headers.

> @@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
>  {
>      local_irq_enable();
>  
> -    regs->r0 = arm_hypercall_table[iss](regs->r0,
> +    if ( iss != XEN_HYPERCALL_TAG  ) {
> +        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
> +                __LINE__ , iss);

	regs->r0 = -EINVAL;

here I think.

> +        return;
> +    }
> +
> +    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,

It's an existing issue but we need to check that
arm_hypercall_table[regs->r12] is non-NULL here and return -ENOSYS (by
setting r0) if it is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19: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 1S0ep7-00066H-K8; Thu, 23 Feb 2012 19:59:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0ep5-00066C-Rr
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:59:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330027115!61425329!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMzc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12418 invoked from network); 23 Feb 2012 19:58:35 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 19:58:35 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id A1880714083;
	Thu, 23 Feb 2012 11:59:20 -0800 (PST)
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=a3uEY6BSHiNdPv0lzmYsiN
	Kt7Gex+7yUcns7gywPkq3/z36aaqmoH80Cp2MPtHZmd7RBjxbPre9a3kCpKuqUMo
	P2zinU2gB4nPLM3M1Gv8TG7hytH8dbelYd2zfGEQ45u+PrMnfVDamTp78+bfXfoG
	5z+FreWxGMb2sRapt3j1I=
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=/bBwFKBAxbdh
	tSlT5WUO9NjVvTM=; b=YQJOlDjlDAajYtESO2GUTqPmo47heIRiywg7F43Ux4og
	ENgsrbXsIPaxIpP5bt8iifantGcxWzkWb9AfjqVzv4EH2X7TpAzC1ZD9UPI51MCC
	6Hof408ifMnnwjDcBSO9dgJkOjLKc5A6UzQGgdopiPi0XJJdgjhzVsNB5z+pI8Q=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id E39FF71406B; 
	Thu, 23 Feb 2012 11:59:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: da02cb8485de698078baa95487db7c17f71c550c
Message-Id: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 14:59:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page_alloc.c  |  88 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h |   1 +
 2 files changed, 89 insertions(+), 0 deletions(-)


When a low memory threshold on the Xen heap is reached, we fire a global dom0
virq. If someone's listening, they can free up some more memory. The low
threshold is configurable via the command line token 'low_mem_virq_limit", and
defaults to 64MiB.

We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
xenballoond, or anything else that can be fired through xencommons.

We error-check the low mem virq against initial available heap (after dom0
allocation), to avoid firing immediately.

Virq issuing is controlled by a hysteresis algorithm: when memory dips below a
threshold, the virq is issued and the next virq will fire when memory shrinks
another order of magnitude. The virq will not fire again in the current "band"
until memory grows over the next higher order of magnitude.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r dd69d9b1aee9 -r da02cb8485de xen/common/page_alloc.c
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/event.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
@@ -300,6 +301,87 @@ static unsigned long init_node_heap(int 
     return needed;
 }
 
+/* Default to 64 MiB */
+#define DEFAULT_LOW_MEM_VIRQ_MIB    64
+#define MAX_LOW_MEM_VIRQ_MIB        1024
+
+static unsigned long long __read_mostly opt_low_mem_virq = 
+                                        (DEFAULT_LOW_MEM_VIRQ_MIB << 20);
+size_param("low_mem_virq_limit", opt_low_mem_virq);
+
+/* Thresholds to control hysteresis. In pages */
+/* When memory grows above this threshold, reset hysteresis.
+ * -1 initially to not reset until at least one virq issued. */
+static unsigned long low_mem_virq_high      = -1UL;
+/* Threshold at which we issue virq */
+static unsigned long low_mem_virq_th        = 0;
+/* Original threshold after all checks completed */
+static unsigned long low_mem_virq_orig      = 0;
+/* Order for current threshold */
+static unsigned int  low_mem_virq_th_order  = 0;
+
+/* Perform bootstrapping checks and set bounds */
+static void setup_low_mem_virq(void)
+{
+    unsigned int order;
+    unsigned long long threshold;
+
+    /* Dom0 has already been allocated by now. So check we won't 
+     * be complaining immediately with whatever's left of the heap. */
+    threshold = min(opt_low_mem_virq, (unsigned long long)
+                          (total_avail_pages << PAGE_SHIFT));
+
+    /* Then, cap to some predefined maximum */
+    threshold = min(threshold, (unsigned long long)
+                          (MAX_LOW_MEM_VIRQ_MIB << 20));
+
+    /* Threshold bytes -> pages */
+    low_mem_virq_th = threshold >> PAGE_SHIFT;
+
+    /* Next, round the threshold down to the next order */
+    order = get_order_from_pages(low_mem_virq_th);
+    if ( (1 << order) > low_mem_virq_th ) 
+        order--;
+
+    /* Set bounds, ready to go */
+    low_mem_virq_th = low_mem_virq_orig = 1 << order;
+    low_mem_virq_th_order = order;
+
+    printk("Current low memory virq threshold set at 0x%lx pages.\n",
+            low_mem_virq_th);
+}
+
+static void check_low_mem_virq(void)
+{
+    if ( total_avail_pages <= low_mem_virq_th )
+    {
+        send_global_virq(VIRQ_ENOMEM);
+
+        /* Update thresholds. Next warning will be when we drop below
+         * next order. However, we wait until we grow beyond one
+         * order above us to complain again at the current order */
+        low_mem_virq_high   = 1 << (low_mem_virq_th_order + 1);
+        if ( low_mem_virq_th_order > 0 )
+            low_mem_virq_th_order--;
+        low_mem_virq_th     = 1 << low_mem_virq_th_order;
+        return;
+    }
+
+    if ( total_avail_pages >= low_mem_virq_high )
+    {
+        /* Reset hysteresis. Bring threshold up one order.
+         * If we are back where originally set, set high
+         * threshold to -1 to avoid further growth of 
+         * virq threshold. */
+        low_mem_virq_th_order++;
+        low_mem_virq_th = 1 << low_mem_virq_th_order;
+        if ( low_mem_virq_th == low_mem_virq_orig )
+            low_mem_virq_high = -1UL;
+        else
+            low_mem_virq_high = 1 << (low_mem_virq_th_order + 2);
+    }
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi,
@@ -420,6 +502,8 @@ static struct page_info *alloc_heap_page
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
+    check_low_mem_virq();
+
     if ( d != NULL )
         d->last_alloc_node = node;
 
@@ -1022,6 +1106,10 @@ void __init scrub_heap_pages(void)
     }
 
     printk("done.\n");
+
+    /* Now that the heap is initialized, run checks and set bounds
+     * for the low mem virq algorithm. */
+    setup_low_mem_virq();
 }
 
 
diff -r dd69d9b1aee9 -r da02cb8485de xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #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) Dangerously low on heap memory       */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 19:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 19: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 1S0ep7-00066H-K8; Thu, 23 Feb 2012 19:59:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0ep5-00066C-Rr
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 19:59:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330027115!61425329!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxMzc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12418 invoked from network); 23 Feb 2012 19:58:35 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-27.messagelabs.com with SMTP;
	23 Feb 2012 19:58:35 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id A1880714083;
	Thu, 23 Feb 2012 11:59:20 -0800 (PST)
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=a3uEY6BSHiNdPv0lzmYsiN
	Kt7Gex+7yUcns7gywPkq3/z36aaqmoH80Cp2MPtHZmd7RBjxbPre9a3kCpKuqUMo
	P2zinU2gB4nPLM3M1Gv8TG7hytH8dbelYd2zfGEQ45u+PrMnfVDamTp78+bfXfoG
	5z+FreWxGMb2sRapt3j1I=
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=/bBwFKBAxbdh
	tSlT5WUO9NjVvTM=; b=YQJOlDjlDAajYtESO2GUTqPmo47heIRiywg7F43Ux4og
	ENgsrbXsIPaxIpP5bt8iifantGcxWzkWb9AfjqVzv4EH2X7TpAzC1ZD9UPI51MCC
	6Hof408ifMnnwjDcBSO9dgJkOjLKc5A6UzQGgdopiPi0XJJdgjhzVsNB5z+pI8Q=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id E39FF71406B; 
	Thu, 23 Feb 2012 11:59:19 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: da02cb8485de698078baa95487db7c17f71c550c
Message-Id: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 23 Feb 2012 14:59:58 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page_alloc.c  |  88 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h |   1 +
 2 files changed, 89 insertions(+), 0 deletions(-)


When a low memory threshold on the Xen heap is reached, we fire a global dom0
virq. If someone's listening, they can free up some more memory. The low
threshold is configurable via the command line token 'low_mem_virq_limit", and
defaults to 64MiB.

We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
xenballoond, or anything else that can be fired through xencommons.

We error-check the low mem virq against initial available heap (after dom0
allocation), to avoid firing immediately.

Virq issuing is controlled by a hysteresis algorithm: when memory dips below a
threshold, the virq is issued and the next virq will fire when memory shrinks
another order of magnitude. The virq will not fire again in the current "band"
until memory grows over the next higher order of magnitude.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r dd69d9b1aee9 -r da02cb8485de xen/common/page_alloc.c
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/event.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
@@ -300,6 +301,87 @@ static unsigned long init_node_heap(int 
     return needed;
 }
 
+/* Default to 64 MiB */
+#define DEFAULT_LOW_MEM_VIRQ_MIB    64
+#define MAX_LOW_MEM_VIRQ_MIB        1024
+
+static unsigned long long __read_mostly opt_low_mem_virq = 
+                                        (DEFAULT_LOW_MEM_VIRQ_MIB << 20);
+size_param("low_mem_virq_limit", opt_low_mem_virq);
+
+/* Thresholds to control hysteresis. In pages */
+/* When memory grows above this threshold, reset hysteresis.
+ * -1 initially to not reset until at least one virq issued. */
+static unsigned long low_mem_virq_high      = -1UL;
+/* Threshold at which we issue virq */
+static unsigned long low_mem_virq_th        = 0;
+/* Original threshold after all checks completed */
+static unsigned long low_mem_virq_orig      = 0;
+/* Order for current threshold */
+static unsigned int  low_mem_virq_th_order  = 0;
+
+/* Perform bootstrapping checks and set bounds */
+static void setup_low_mem_virq(void)
+{
+    unsigned int order;
+    unsigned long long threshold;
+
+    /* Dom0 has already been allocated by now. So check we won't 
+     * be complaining immediately with whatever's left of the heap. */
+    threshold = min(opt_low_mem_virq, (unsigned long long)
+                          (total_avail_pages << PAGE_SHIFT));
+
+    /* Then, cap to some predefined maximum */
+    threshold = min(threshold, (unsigned long long)
+                          (MAX_LOW_MEM_VIRQ_MIB << 20));
+
+    /* Threshold bytes -> pages */
+    low_mem_virq_th = threshold >> PAGE_SHIFT;
+
+    /* Next, round the threshold down to the next order */
+    order = get_order_from_pages(low_mem_virq_th);
+    if ( (1 << order) > low_mem_virq_th ) 
+        order--;
+
+    /* Set bounds, ready to go */
+    low_mem_virq_th = low_mem_virq_orig = 1 << order;
+    low_mem_virq_th_order = order;
+
+    printk("Current low memory virq threshold set at 0x%lx pages.\n",
+            low_mem_virq_th);
+}
+
+static void check_low_mem_virq(void)
+{
+    if ( total_avail_pages <= low_mem_virq_th )
+    {
+        send_global_virq(VIRQ_ENOMEM);
+
+        /* Update thresholds. Next warning will be when we drop below
+         * next order. However, we wait until we grow beyond one
+         * order above us to complain again at the current order */
+        low_mem_virq_high   = 1 << (low_mem_virq_th_order + 1);
+        if ( low_mem_virq_th_order > 0 )
+            low_mem_virq_th_order--;
+        low_mem_virq_th     = 1 << low_mem_virq_th_order;
+        return;
+    }
+
+    if ( total_avail_pages >= low_mem_virq_high )
+    {
+        /* Reset hysteresis. Bring threshold up one order.
+         * If we are back where originally set, set high
+         * threshold to -1 to avoid further growth of 
+         * virq threshold. */
+        low_mem_virq_th_order++;
+        low_mem_virq_th = 1 << low_mem_virq_th_order;
+        if ( low_mem_virq_th == low_mem_virq_orig )
+            low_mem_virq_high = -1UL;
+        else
+            low_mem_virq_high = 1 << (low_mem_virq_th_order + 2);
+    }
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi,
@@ -420,6 +502,8 @@ static struct page_info *alloc_heap_page
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
+    check_low_mem_virq();
+
     if ( d != NULL )
         d->last_alloc_node = node;
 
@@ -1022,6 +1106,10 @@ void __init scrub_heap_pages(void)
     }
 
     printk("done.\n");
+
+    /* Now that the heap is initialized, run checks and set bounds
+     * for the low mem virq algorithm. */
+    setup_low_mem_virq();
 }
 
 
diff -r dd69d9b1aee9 -r da02cb8485de xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #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) Dangerously low on heap memory       */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 20:21:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 20:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0f9m-0006do-5F; Thu, 23 Feb 2012 20:20:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1S0f9k-0006dN-F6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 20:20:48 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330028441!9412446!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQzMjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31094 invoked from network); 23 Feb 2012 20:20:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 20:20:41 -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 q1NKKZvM012388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 15:20:35 -0500
Received: from redhat.com (vpn-200-53.tlv.redhat.com [10.35.200.53])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q1NKKW9e011427; Thu, 23 Feb 2012 15:20:33 -0500
Date: Thu, 23 Feb 2012 22:20:38 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120223202037.GB29136@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 03/11] pci_regs: Add
	PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:37PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Applied, thanks.

> ---
>  hw/pci_regs.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_regs.h b/hw/pci_regs.h
> index 6b42515..56a404b 100644
> --- a/hw/pci_regs.h
> +++ b/hw/pci_regs.h
> @@ -392,6 +392,7 @@
>  #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
>  #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
>  #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
> +#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
>  #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
>  #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
>  #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 20:21:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 20:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0f9m-0006do-5F; Thu, 23 Feb 2012 20:20:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1S0f9k-0006dN-F6
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 20:20:48 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330028441!9412446!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQzMjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31094 invoked from network); 23 Feb 2012 20:20:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	23 Feb 2012 20:20:41 -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 q1NKKZvM012388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 15:20:35 -0500
Received: from redhat.com (vpn-200-53.tlv.redhat.com [10.35.200.53])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id q1NKKW9e011427; Thu, 23 Feb 2012 15:20:33 -0500
Date: Thu, 23 Feb 2012 22:20:38 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120223202037.GB29136@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1329498525-8454-4-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V7 03/11] pci_regs: Add
	PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 17, 2012 at 05:08:37PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Applied, thanks.

> ---
>  hw/pci_regs.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci_regs.h b/hw/pci_regs.h
> index 6b42515..56a404b 100644
> --- a/hw/pci_regs.h
> +++ b/hw/pci_regs.h
> @@ -392,6 +392,7 @@
>  #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
>  #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
>  #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
> +#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
>  #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
>  #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
>  #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 20:22:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 20: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 1S0fBC-0006mP-AQ; Thu, 23 Feb 2012 20:22:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1S0fBA-0006kx-KY
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 20:22:16 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330028528!16644472!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7907 invoked from network); 23 Feb 2012 20:22:09 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 20:22:09 -0000
Received: by yhkk6 with SMTP id k6so11833447yhk.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 12:22:08 -0800 (PST)
Received-SPF: pass (google.com: domain of florian.heigl@gmail.com designates
	10.50.42.134 as permitted sender) client-ip=10.50.42.134; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	florian.heigl@gmail.com designates 10.50.42.134 as permitted
	sender) smtp.mail=florian.heigl@gmail.com;
	dkim=pass header.i=florian.heigl@gmail.com
Received: from mr.google.com ([10.50.42.134])
	by 10.50.42.134 with SMTP id o6mr4459812igl.0.1330028528232 (num_hops =
	1); Thu, 23 Feb 2012 12:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=TA3J5cy7b+xr8kmC0jm3A/v3Xh+sBlmvjtlgpskE+LY=;
	b=ubJSdtC8OICo0SijaTPAxnJZ4YofErtSMA0HSfrNt3c6CXhmpEzJk0YihpMBK1Fg/m
	0wy1sBnBAH0bFVaiyYNaBMSMpqQgJxvUlfnCINm95TbtDEVM/XMnoCM/tA5bWKC8FdSp
	TDkS6HoJYKsi9X9aaUy/Cq1fuAuH/Ms3MU26s=
MIME-Version: 1.0
Received: by 10.50.42.134 with SMTP id o6mr3725178igl.0.1330028528017; Thu, 23
	Feb 2012 12:22:08 -0800 (PST)
Received: by 10.231.60.139 with HTTP; Thu, 23 Feb 2012 12:22:07 -0800 (PST)
In-Reply-To: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
References: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
Date: Thu, 23 Feb 2012 21:22:07 +0100
Message-ID: <CAFivhPmhcwg4=_7VZhfK0_kKp89XTHxxS=3bDv1ebChY7FQDuA@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: harryxiyou <harryxiyou@gmail.com>
Cc: xen-users@lists.xen.org, cloudxy@googlegroups.com,
	xen-devel@lists.xensource.com, Kang Hua <kanghua151@gmail.com>,
	xen-bugs@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] [XEN]tap-err happens to me
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,


2012/2/23 harryxiyou <harryxiyou@gmail.com>:
> Feb 24 02:52:17 local00212201021a tap-ctl: tap-err:tap_ctl_wait:
> tapdisk2[31763] failed, status 127
>
> The log says tapdisk2 happens to an error.

127 is usually a file not found?

Flo

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 20:22:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 20: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 1S0fBC-0006mP-AQ; Thu, 23 Feb 2012 20:22:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1S0fBA-0006kx-KY
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 20:22:16 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330028528!16644472!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7907 invoked from network); 23 Feb 2012 20:22:09 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2012 20:22:09 -0000
Received: by yhkk6 with SMTP id k6so11833447yhk.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 12:22:08 -0800 (PST)
Received-SPF: pass (google.com: domain of florian.heigl@gmail.com designates
	10.50.42.134 as permitted sender) client-ip=10.50.42.134; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	florian.heigl@gmail.com designates 10.50.42.134 as permitted
	sender) smtp.mail=florian.heigl@gmail.com;
	dkim=pass header.i=florian.heigl@gmail.com
Received: from mr.google.com ([10.50.42.134])
	by 10.50.42.134 with SMTP id o6mr4459812igl.0.1330028528232 (num_hops =
	1); Thu, 23 Feb 2012 12:22:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=TA3J5cy7b+xr8kmC0jm3A/v3Xh+sBlmvjtlgpskE+LY=;
	b=ubJSdtC8OICo0SijaTPAxnJZ4YofErtSMA0HSfrNt3c6CXhmpEzJk0YihpMBK1Fg/m
	0wy1sBnBAH0bFVaiyYNaBMSMpqQgJxvUlfnCINm95TbtDEVM/XMnoCM/tA5bWKC8FdSp
	TDkS6HoJYKsi9X9aaUy/Cq1fuAuH/Ms3MU26s=
MIME-Version: 1.0
Received: by 10.50.42.134 with SMTP id o6mr3725178igl.0.1330028528017; Thu, 23
	Feb 2012 12:22:08 -0800 (PST)
Received: by 10.231.60.139 with HTTP; Thu, 23 Feb 2012 12:22:07 -0800 (PST)
In-Reply-To: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
References: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
Date: Thu, 23 Feb 2012 21:22:07 +0100
Message-ID: <CAFivhPmhcwg4=_7VZhfK0_kKp89XTHxxS=3bDv1ebChY7FQDuA@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: harryxiyou <harryxiyou@gmail.com>
Cc: xen-users@lists.xen.org, cloudxy@googlegroups.com,
	xen-devel@lists.xensource.com, Kang Hua <kanghua151@gmail.com>,
	xen-bugs@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] [XEN]tap-err happens to me
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,


2012/2/23 harryxiyou <harryxiyou@gmail.com>:
> Feb 24 02:52:17 local00212201021a tap-ctl: tap-err:tap_ctl_wait:
> tapdisk2[31763] failed, status 127
>
> The log says tapdisk2 happens to an error.

127 is usually a file not found?

Flo

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 20:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 20:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0fPM-0007po-DV; Thu, 23 Feb 2012 20:36:56 +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 1S0fPL-0007ph-CW
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 20:36:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330029388!64814598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19065 invoked from network); 23 Feb 2012 20:36:29 -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;
	23 Feb 2012 20:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10906943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 20:36:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 20:36:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0fPI-0006N9-7V;
	Thu, 23 Feb 2012 20:36:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0fPI-0006oW-1J;
	Thu, 23 Feb 2012 20:36:52 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12034-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 20:36:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12034: 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 12034 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12034/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 11948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  04d72f81775d
baseline version:
 xen                  f2543f449a49

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  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>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Juergen Gross <juergen.gross@ts.fujitsu.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=04d72f81775d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 04d72f81775d
+ branch=xen-4.1-testing
+ revision=04d72f81775d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ . ap-common
++ : 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
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 04d72f81775d 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 6 changesets with 14 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 20:37:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 20:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0fPM-0007po-DV; Thu, 23 Feb 2012 20:36:56 +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 1S0fPL-0007ph-CW
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 20:36:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330029388!64814598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19065 invoked from network); 23 Feb 2012 20:36:29 -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;
	23 Feb 2012 20:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="10906943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2012 20:36:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 23 Feb 2012 20:36:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0fPI-0006N9-7V;
	Thu, 23 Feb 2012 20:36:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0fPI-0006oW-1J;
	Thu, 23 Feb 2012 20:36:52 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12034-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 23 Feb 2012 20:36:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 12034: 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 12034 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12034/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 11948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  04d72f81775d
baseline version:
 xen                  f2543f449a49

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  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>
  John McDermott <john.mcdermott@nrl.navy.mil>
  Juergen Gross <juergen.gross@ts.fujitsu.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=04d72f81775d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 04d72f81775d
+ branch=xen-4.1-testing
+ revision=04d72f81775d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ . ap-common
++ : 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
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 04d72f81775d 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 6 changesets with 14 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFc-0000XA-Mm; Thu, 23 Feb 2012 22:35:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0hFb-0000Wl-DH
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:34:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330036492!16654906!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29350 invoked from network); 23 Feb 2012 22:34: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; 23 Feb 2012 22:34: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 q1NMYlc4010045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1NMYkhx007699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 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
	q1NMYkbg030438; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AF7484172A; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:09 -0500
Message-Id: <1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F46BF08.0092,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and MWAIT_LEAF
	if hypervisor OKs 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

For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset_xen module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.

For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.

The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.

Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".

With this in place, instead of
 C3 ACPI IOPORT 415
we get now
 C3:ACPI FFH INTEL MWAIT 0x20

Note: The cpu_idle which would be calling the mwait variants for idling
never gets set b/c we set the default pm_idle to be the hypercall variant.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c         |   92 +++++++++++++++++++++++++++++++++++++-
 include/xen/interface/platform.h |    4 +-
 2 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..4c82936 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -62,6 +62,14 @@
 #include <asm/reboot.h>
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
+#include <asm/mwait.h>
+
+#ifdef CONFIG_ACPI
+#include <asm/acpi.h>
+#include <acpi/pdc_intel.h>
+#include <acpi/processor.h>
+#include <xen/interface/platform.h>
+#endif
 
 #include "xen-ops.h"
 #include "mmu.h"
@@ -200,13 +208,17 @@ static void __init xen_banner(void)
 static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
 static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
 
+static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask;
+static __read_mostly unsigned int cpuid_leaf5_ecx_val;
+static __read_mostly unsigned int cpuid_leaf5_edx_val;
+
 static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		      unsigned int *cx, unsigned int *dx)
 {
 	unsigned maskebx = ~0;
 	unsigned maskecx = ~0;
 	unsigned maskedx = ~0;
-
+	unsigned setecx = 0;
 	/*
 	 * Mask out inconvenient features, to try and disable as many
 	 * unsupported kernel subsystems as possible.
@@ -214,9 +226,18 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 	switch (*ax) {
 	case 1:
 		maskecx = cpuid_leaf1_ecx_mask;
+		setecx = cpuid_leaf1_ecx_set_mask;
 		maskedx = cpuid_leaf1_edx_mask;
 		break;
 
+	case CPUID_MWAIT_LEAF:
+		/* Synthesize the values.. */
+		*ax = 0;
+		*bx = 0;
+		*cx = cpuid_leaf5_ecx_val;
+		*dx = cpuid_leaf5_edx_val;
+		return;
+
 	case 0xb:
 		/* Suppress extended topology stuff */
 		maskebx = 0;
@@ -232,9 +253,75 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 
 	*bx &= maskebx;
 	*cx &= maskecx;
+	*cx |= setecx;
 	*dx &= maskedx;
+
 }
 
+static bool __init xen_check_mwait(void)
+{
+#if CONFIG_ACPI
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.u.set_pminfo.id	= -1,
+		.u.set_pminfo.type	= XEN_PM_PDC,
+	};
+	uint32_t buf[3];
+	unsigned int ax, bx, cx, dx;
+	unsigned int mwait_mask;
+
+	/* We need to determine whether it is OK to expose the MWAIT
+	 * capability to the kernel to harvest deeper than C3 states from ACPI
+	 * _CST using the processor_harvest_xen.c module. For this to work, we
+	 * need to gather the MWAIT_LEAF values (which the cstate.c code
+	 * checks against). The hypervisor won't expose the MWAIT flag because
+	 * it would break backwards compatibility; so we will find out directly
+	 * from the hardware and hypercall.
+	 */
+	if (!xen_initial_domain())
+		return false;
+
+	ax = 1;
+	cx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	mwait_mask = (1 << (X86_FEATURE_EST % 32)) |
+		     (1 << (X86_FEATURE_MWAIT % 32));
+
+	if ((cx & mwait_mask) != mwait_mask)
+		return false;
+
+	/* We need to emulate the MWAIT_LEAF and for that we need both
+	 * ecx and edx. The hypercall provides only partial information.
+	 */
+
+	ax = CPUID_MWAIT_LEAF;
+	bx = 0;
+	cx = 0;
+	dx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	/* Ask the Hypervisor whether to clear ACPI_PDC_C_C2C3_FFH. If so,
+	 * don't expose MWAIT_LEAF and let ACPI pick the IOPORT version of C3.
+	 */
+	buf[0] = ACPI_PDC_REVISION_ID;
+	buf[1] = 1;
+	buf[2] = (ACPI_PDC_C_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_SWSMP);
+
+	set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
+
+	if ((HYPERVISOR_dom0_op(&op) == 0) &&
+	    (buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
+		cpuid_leaf5_ecx_val = cx;
+		cpuid_leaf5_edx_val = dx;
+	}
+	return true;
+#else
+	return false;
+#endif
+}
 static void __init xen_init_cpuid_mask(void)
 {
 	unsigned int ax, bx, cx, dx;
@@ -261,6 +348,9 @@ static void __init xen_init_cpuid_mask(void)
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 	if ((cx & xsave_mask) != xsave_mask)
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
+
+	if (xen_check_mwait())
+		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
 }
 
 static void xen_set_debugreg(int reg, unsigned long val)
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..6220b98 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -200,7 +200,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PM_CX   0
 #define XEN_PM_PX   1
 #define XEN_PM_TX   2
-
+#define XEN_PM_PDC  3
 /* Px sub info type */
 #define XEN_PX_PCT   1
 #define XEN_PX_PSS   2
@@ -286,6 +286,7 @@ struct xen_processor_performance {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
 
+DEFINE_GUEST_HANDLE(uint32_t);
 struct xenpf_set_processor_pminfo {
 	/* IN variables */
 	uint32_t id;    /* ACPI CPU ID */
@@ -293,6 +294,7 @@ struct xenpf_set_processor_pminfo {
 	union {
 		struct xen_processor_power          power;/* Cx: _CST/_CSD */
 		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
+		GUEST_HANDLE(uint32_t)              pdc;
 	};
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFc-0000XA-Mm; Thu, 23 Feb 2012 22:35:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0hFb-0000Wl-DH
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:34:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330036492!16654906!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2MzQzMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29350 invoked from network); 23 Feb 2012 22:34: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; 23 Feb 2012 22:34: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 q1NMYlc4010045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1NMYkhx007699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 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
	q1NMYkbg030438; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AF7484172A; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:09 -0500
Message-Id: <1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F46BF08.0092,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and MWAIT_LEAF
	if hypervisor OKs 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

For the hypervisor to take advantage of the MWAIT support it needs
to extract from the ACPI _CST the register address. But the
hypervisor does not have the support to parse DSDT so it relies on
the initial domain (dom0) to parse the ACPI Power Management information
and push it up to the hypervisor. The pushing of the data is done
by the processor_harveset_xen module which parses the information that
the ACPI parser has graciously exposed in 'struct acpi_processor'.

For the ACPI parser to also expose the Cx states for MWAIT, we need
to expose the MWAIT capability (leaf 1). Furthermore we also need to
expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
function.

The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
operations, but it can't do it since it needs to be backwards compatible.
Instead we choose to use the native CPUID to figure out if the MWAIT
capability exists and use the XEN_SET_PDC query hypercall to figure out
if the hypervisor wants us to expose the MWAIT_LEAF capability or not.

Note: The XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".

With this in place, instead of
 C3 ACPI IOPORT 415
we get now
 C3:ACPI FFH INTEL MWAIT 0x20

Note: The cpu_idle which would be calling the mwait variants for idling
never gets set b/c we set the default pm_idle to be the hypercall variant.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c         |   92 +++++++++++++++++++++++++++++++++++++-
 include/xen/interface/platform.h |    4 +-
 2 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 12eb07b..4c82936 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -62,6 +62,14 @@
 #include <asm/reboot.h>
 #include <asm/stackprotector.h>
 #include <asm/hypervisor.h>
+#include <asm/mwait.h>
+
+#ifdef CONFIG_ACPI
+#include <asm/acpi.h>
+#include <acpi/pdc_intel.h>
+#include <acpi/processor.h>
+#include <xen/interface/platform.h>
+#endif
 
 #include "xen-ops.h"
 #include "mmu.h"
@@ -200,13 +208,17 @@ static void __init xen_banner(void)
 static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
 static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
 
+static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask;
+static __read_mostly unsigned int cpuid_leaf5_ecx_val;
+static __read_mostly unsigned int cpuid_leaf5_edx_val;
+
 static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		      unsigned int *cx, unsigned int *dx)
 {
 	unsigned maskebx = ~0;
 	unsigned maskecx = ~0;
 	unsigned maskedx = ~0;
-
+	unsigned setecx = 0;
 	/*
 	 * Mask out inconvenient features, to try and disable as many
 	 * unsupported kernel subsystems as possible.
@@ -214,9 +226,18 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 	switch (*ax) {
 	case 1:
 		maskecx = cpuid_leaf1_ecx_mask;
+		setecx = cpuid_leaf1_ecx_set_mask;
 		maskedx = cpuid_leaf1_edx_mask;
 		break;
 
+	case CPUID_MWAIT_LEAF:
+		/* Synthesize the values.. */
+		*ax = 0;
+		*bx = 0;
+		*cx = cpuid_leaf5_ecx_val;
+		*dx = cpuid_leaf5_edx_val;
+		return;
+
 	case 0xb:
 		/* Suppress extended topology stuff */
 		maskebx = 0;
@@ -232,9 +253,75 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 
 	*bx &= maskebx;
 	*cx &= maskecx;
+	*cx |= setecx;
 	*dx &= maskedx;
+
 }
 
+static bool __init xen_check_mwait(void)
+{
+#if CONFIG_ACPI
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.u.set_pminfo.id	= -1,
+		.u.set_pminfo.type	= XEN_PM_PDC,
+	};
+	uint32_t buf[3];
+	unsigned int ax, bx, cx, dx;
+	unsigned int mwait_mask;
+
+	/* We need to determine whether it is OK to expose the MWAIT
+	 * capability to the kernel to harvest deeper than C3 states from ACPI
+	 * _CST using the processor_harvest_xen.c module. For this to work, we
+	 * need to gather the MWAIT_LEAF values (which the cstate.c code
+	 * checks against). The hypervisor won't expose the MWAIT flag because
+	 * it would break backwards compatibility; so we will find out directly
+	 * from the hardware and hypercall.
+	 */
+	if (!xen_initial_domain())
+		return false;
+
+	ax = 1;
+	cx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	mwait_mask = (1 << (X86_FEATURE_EST % 32)) |
+		     (1 << (X86_FEATURE_MWAIT % 32));
+
+	if ((cx & mwait_mask) != mwait_mask)
+		return false;
+
+	/* We need to emulate the MWAIT_LEAF and for that we need both
+	 * ecx and edx. The hypercall provides only partial information.
+	 */
+
+	ax = CPUID_MWAIT_LEAF;
+	bx = 0;
+	cx = 0;
+	dx = 0;
+
+	native_cpuid(&ax, &bx, &cx, &dx);
+
+	/* Ask the Hypervisor whether to clear ACPI_PDC_C_C2C3_FFH. If so,
+	 * don't expose MWAIT_LEAF and let ACPI pick the IOPORT version of C3.
+	 */
+	buf[0] = ACPI_PDC_REVISION_ID;
+	buf[1] = 1;
+	buf[2] = (ACPI_PDC_C_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_SWSMP);
+
+	set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
+
+	if ((HYPERVISOR_dom0_op(&op) == 0) &&
+	    (buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
+		cpuid_leaf5_ecx_val = cx;
+		cpuid_leaf5_edx_val = dx;
+	}
+	return true;
+#else
+	return false;
+#endif
+}
 static void __init xen_init_cpuid_mask(void)
 {
 	unsigned int ax, bx, cx, dx;
@@ -261,6 +348,9 @@ static void __init xen_init_cpuid_mask(void)
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
 	if ((cx & xsave_mask) != xsave_mask)
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
+
+	if (xen_check_mwait())
+		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
 }
 
 static void xen_set_debugreg(int reg, unsigned long val)
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c168468..6220b98 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -200,7 +200,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
 #define XEN_PM_CX   0
 #define XEN_PM_PX   1
 #define XEN_PM_TX   2
-
+#define XEN_PM_PDC  3
 /* Px sub info type */
 #define XEN_PX_PCT   1
 #define XEN_PX_PSS   2
@@ -286,6 +286,7 @@ struct xen_processor_performance {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
 
+DEFINE_GUEST_HANDLE(uint32_t);
 struct xenpf_set_processor_pminfo {
 	/* IN variables */
 	uint32_t id;    /* ACPI CPU ID */
@@ -293,6 +294,7 @@ struct xenpf_set_processor_pminfo {
 	union {
 		struct xen_processor_power          power;/* Cx: _CST/_CSD */
 		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
+		GUEST_HANDLE(uint32_t)              pdc;
 	};
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFe-0000XL-3a; Thu, 23 Feb 2012 22:35:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0hFc-0000Wm-7v
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1330036492!9846601!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NTIzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4008 invoked from network); 23 Feb 2012 22:34:54 -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; 23 Feb 2012 22:34: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 q1NMYlwF010046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:48 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
	q1NMYkhD005541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1NMYkd5010780; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97FC14171C; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:07 -0500
Message-Id: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F46BF08.00AA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx data
	to hypervisor (v5).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The problem these three patches try to solve is to provide ACPI power management
information to the Xen hypervisor. The hypervisor lacks the ACPI DSDT parser so it can't
get that data without some help - and the initial domain can provide that. One
approach (https://lkml.org/lkml/2011/11/30/245) augments the ACPI code to call
an external PM code - but there were no comments about it so I decided to see
if another approach could solve it.

This module (processor-passthru)  collects the information that the cpufreq
drivers and the ACPI processor code save in the 'struct acpi_processor' and
then uploads it to the hypervisor.

The driver can be either an module or compiled in. In either mode the driver
launches a thread that checks whether an cpufreq driver is registered. If so
it reads all the 'struct acpi_processor' data for all online CPUs and sends
it to hypervisor. The driver also register a CPU hotplug component - so if a new
CPU shows up - it would send the data to the hypervisor for it as well.
Furthermore it also verifies whether the ACPI ID count is different than what
the kernel sees (which is possible with dom0_max_vcpus) and if so uploads
the data for the other ACPI IDs.

The patches are available in this git tree:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/processor-passthru.v5


Konrad Rzeszutek Wilk (3):
      xen/setup/pm/acpi: Remove the call to boot_option_idle_override.
      xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
      xen/processor-passthru: Provide an driver that passes struct acpi_processor data to the hypervisor.

 arch/x86/xen/enlighten.c         |   92 +++++++-
 arch/x86/xen/setup.c             |    1 -
 drivers/xen/Kconfig              |   14 +
 drivers/xen/Makefile             |    2 +-
 drivers/xen/processor-passthru.c |  485 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h |    4 +-
 6 files changed, 594 insertions(+), 4 deletions(-)


P.S.
On the hypervisor side, it requires this patch on AMD:
# HG changeset patch
# Parent aea8cfac8cf1afe397f2e1d422a852008d8a83fe
traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

This patch works fine with older classic dom0 (2.6.32) and with
AMD K7 and K8 boxes.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
diff -r aea8cfac8cf1 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Feb 23 13:23:02 2012 -0500
+++ b/xen/arch/x86/traps.c	Thu Feb 23 13:29:00 2012 -0500
@@ -2484,7 +2484,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_PSTATE7:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
             {
                 regs->eax = regs->edx = 0;
                 break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFe-0000XL-3a; Thu, 23 Feb 2012 22:35:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0hFc-0000Wm-7v
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1330036492!9846601!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NTIzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4008 invoked from network); 23 Feb 2012 22:34:54 -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; 23 Feb 2012 22:34: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 q1NMYlwF010046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:48 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
	q1NMYkhD005541
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1NMYkd5010780; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97FC14171C; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:07 -0500
Message-Id: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F46BF08.00AA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx data
	to hypervisor (v5).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The problem these three patches try to solve is to provide ACPI power management
information to the Xen hypervisor. The hypervisor lacks the ACPI DSDT parser so it can't
get that data without some help - and the initial domain can provide that. One
approach (https://lkml.org/lkml/2011/11/30/245) augments the ACPI code to call
an external PM code - but there were no comments about it so I decided to see
if another approach could solve it.

This module (processor-passthru)  collects the information that the cpufreq
drivers and the ACPI processor code save in the 'struct acpi_processor' and
then uploads it to the hypervisor.

The driver can be either an module or compiled in. In either mode the driver
launches a thread that checks whether an cpufreq driver is registered. If so
it reads all the 'struct acpi_processor' data for all online CPUs and sends
it to hypervisor. The driver also register a CPU hotplug component - so if a new
CPU shows up - it would send the data to the hypervisor for it as well.
Furthermore it also verifies whether the ACPI ID count is different than what
the kernel sees (which is possible with dom0_max_vcpus) and if so uploads
the data for the other ACPI IDs.

The patches are available in this git tree:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/processor-passthru.v5


Konrad Rzeszutek Wilk (3):
      xen/setup/pm/acpi: Remove the call to boot_option_idle_override.
      xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it.
      xen/processor-passthru: Provide an driver that passes struct acpi_processor data to the hypervisor.

 arch/x86/xen/enlighten.c         |   92 +++++++-
 arch/x86/xen/setup.c             |    1 -
 drivers/xen/Kconfig              |   14 +
 drivers/xen/Makefile             |    2 +-
 drivers/xen/processor-passthru.c |  485 ++++++++++++++++++++++++++++++++++++++
 include/xen/interface/platform.h |    4 +-
 6 files changed, 594 insertions(+), 4 deletions(-)


P.S.
On the hypervisor side, it requires this patch on AMD:
# HG changeset patch
# Parent aea8cfac8cf1afe397f2e1d422a852008d8a83fe
traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

This patch works fine with older classic dom0 (2.6.32) and with
AMD K7 and K8 boxes.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
diff -r aea8cfac8cf1 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Feb 23 13:23:02 2012 -0500
+++ b/xen/arch/x86/traps.c	Thu Feb 23 13:29:00 2012 -0500
@@ -2484,7 +2484,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_PSTATE7:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
             {
                 regs->eax = regs->edx = 0;
                 break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFf-0000Xd-Ft; Thu, 23 Feb 2012 22:35:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0hFd-0000Ws-LU
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:35:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330036493!16112426!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10320 invoked from network); 23 Feb 2012 22:34:55 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 22:34:55 -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 q1NMYmWs007852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:49 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
	q1NMYl35005551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 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
	q1NMYkpZ030010; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B945E41741; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:10 -0500
Message-Id: <1330036270-20015-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F46BF09.00BF,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/3] xen/processor-passthru: Provide an driver
	that passes struct acpi_processor data to the hypervisor.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIEFDUEkgcHJvY2Vzc29yIHByb2Nlc3NlcyB0aGUgX1B4eCBhbmQgdGhlIF9DeCBzdGF0ZSBp
bmZvcm1hdGlvbgp3aGljaCBhcmUgcG9wdWxhdGVkIGluIHRoZSAnc3RydWN0IGFjcGlfcHJvY2Vz
c29yJyBwZXItY3B1IHN0cnVjdHVyZS4KV2UgcmVhZCB0aGUgY29udGVudHMgb2YgdGhhdCBzdHJ1
Y3R1cmUgYW5kIHBhc3MgaXQgdXAgdGhlIFhlbiBoeXBlcnZpc29yLgoKVGhlIEFDUEkgcHJvY2Vz
c29yIGFsb25nIHdpdGggdGhlIENQVSBmcmVxIGRyaXZlciBkb2VzIGFsbCB0aGUgaGVhdnktbGlm
dGluZwpmb3IgdXMgKGZpbHRlcmluZywgY2FsbGluZyBBQ1BJIGZ1bmN0aW9ucywgZXRjKSBzbyB0
aGF0IHRoZSBjb250ZW50cyBpcyBjb3JyZWN0LgpBZnRlciB3ZSBhcmUgZG9uZSBwYXJzaW5nIHRo
ZSBpbmZvcm1hdGlvbiwgd2Ugd2FpdCBpbiBjYXNlIG9mIGhvdHBsdWcgQ1BVcwpnZXQgbG9hZGVk
IGFuZCB0aGVuIHBhc3MgdGhhdCBpbmZvcm1hdGlvbiB0byB0aGUgaHlwZXJ2aXNvci4KClt2MS12
MjogSW5pdGlhbCBSRkMgaW1wbGVtZW50YXRpb25zIHRoYXQgd2VyZSBwb3N0ZWRdClt2MzogQ2hh
bmdlZCB0aGUgbmFtZSB0byBwYXNzdGhydSBzdWdnZXN0ZWQgYnkgUGFzaSBLw6Rya2vDpGluZW4g
PHBhc2lrQGlraS5maT5dClt2NDogQWRkZWQgdkNQVSAhPSBwQ1BVIHN1cHBvcnQgLSBha2EgZG9t
MF9tYXhfdmNwdXMgc3VwcG9ydF0KW3Y1OiBDbGVhbmVkIHVwIHRoZSBkcml2ZXIsIGZpeCBidWcg
dW5kZXIgQXRobG9uIFhQXQpTaWduZWQtb2ZmLWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtv
bnJhZC53aWxrQG9yYWNsZS5jb20+Ci0tLQogZHJpdmVycy94ZW4vS2NvbmZpZyAgICAgICAgICAg
ICAgfCAgIDE0ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgIHwgICAgMiArLQog
ZHJpdmVycy94ZW4vcHJvY2Vzc29yLXBhc3N0aHJ1LmMgfCAgNDkyICsrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrCiAzIGZpbGVzIGNoYW5nZWQsIDUwNyBpbnNlcnRpb25zKCsp
LCAxIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3Byb2Nlc3Nv
ci1wYXNzdGhydS5jCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vS2NvbmZpZyBiL2RyaXZlcnMv
eGVuL0tjb25maWcKaW5kZXggYTFjZWQ1Mi4uYWY1ZTA2MiAxMDA2NDQKLS0tIGEvZHJpdmVycy94
ZW4vS2NvbmZpZworKysgYi9kcml2ZXJzL3hlbi9LY29uZmlnCkBAIC0xNzgsNCArMTc4LDE4IEBA
IGNvbmZpZyBYRU5fUFJJVkNNRAogCWRlcGVuZHMgb24gWEVOCiAJZGVmYXVsdCBtCiAKK2NvbmZp
ZyBYRU5fUFJPQ0VTU09SX1BBU1NUSFJVCisJdHJpc3RhdGUgIlByb2Nlc3NvciBwYXNzdGhyb3Vn
aCBkcml2ZXIgZm9yIFhlbiIKKwlkZXBlbmRzIG9uIFhFTgorCWRlcGVuZHMgb24gQUNQSV9QUk9D
RVNTT1IKKwlkZXBlbmRzIG9uIFg4NgorCWRlcGVuZHMgb24gQ1BVX0ZSRVEKKwloZWxwCisJICBU
aGlzIGRyaXZlciBwYXJzZXMgdGhlIHByb2Nlc3NvciBzdHJ1Y3R1cmUgYW5kIHBhc3NlcyB0aGUg
aW5mb3JtYXRpb24KKwkgIHRvIHRoZSBYZW4gaHlwZXJ2aXNvci4gSXQgaXMgdXNlZCB0byBhbGxv
dyB0aGUgWGVuIGh5cGVydmlzb3IgdG8gaGF2ZSB0aGUKKwkgIGZ1bGwgcG93ZXIgbWFuYWdlbWVu
dCBkYXRhIGFuZCBiZSBhYmxlIHRvIHNlbGVjdCBwcm9wZXIgQ3ggYW5kIFB4eCBzdGF0ZXMuCisK
KwkgIFRoZSBkcml2ZXIgc2hvdWxkIGJlIGxvYWRlZCBhZnRlciBhY3BpIHByb2Nlc3NvciBhbmQg
Y3B1ZnJlcSBkcml2ZXJzIGhhdmUKKwkgIGJlZW4gbG9hZGVkLiBJZiB5b3UgZG8gbm90IGtub3cg
d2hhdCB0byBjaG9vc2UsIHNlbGVjdCBNIGhlcmUuCisKIGVuZG1lbnUKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggYWEzMTMzNy4u
Y2UyMzVlN2EgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMv
eGVuL01ha2VmaWxlCkBAIC0yMCw3ICsyMCw3IEBAIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJ
CSs9IHN3aW90bGIteGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubwogb2Jq
LSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05G
SUdfWEVOX1BSSVZDTUQpCQkrPSB4ZW4tcHJpdmNtZC5vCi0KK29iai0kKENPTkZJR19YRU5fUFJP
Q0VTU09SX1BBU1NUSFJVKQkrPSBwcm9jZXNzb3ItcGFzc3RocnUubwogeGVuLWV2dGNobi15CQkJ
CTo9IGV2dGNobi5vCiB4ZW4tZ250ZGV2LXkJCQkJOj0gZ250ZGV2Lm8KIHhlbi1nbnRhbGxvYy15
CQkJCTo9IGdudGFsbG9jLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3Byb2Nlc3Nvci1wYXNz
dGhydS5jIGIvZHJpdmVycy94ZW4vcHJvY2Vzc29yLXBhc3N0aHJ1LmMKbmV3IGZpbGUgbW9kZSAx
MDA2NDQKaW5kZXggMDAwMDAwMC4uZTRkZmY0MgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMv
eGVuL3Byb2Nlc3Nvci1wYXNzdGhydS5jCkBAIC0wLDAgKzEsNDkyIEBACisvKgorICogQ29weXJp
Z2h0IDIwMTIgYnkgT3JhY2xlIEluYworICogQXV0aG9yOiBLb25yYWQgUnplc3p1dGVrIFdpbGsg
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CisgKgorICogVGhpcyBjb2RlIGJvcnJvd3MgaWRlYXMg
ZnJvbSBodHRwczovL2xrbWwub3JnL2xrbWwvMjAxMS8xMS8zMC8yNDkKKyAqIHNvIG1hbnkgdGhh
bmtzIGdvIHRvIEtldmluIFRpYW4gPGtldmluLnRpYW5AaW50ZWwuY29tPgorICogYW5kIFl1IEtl
IDxrZS55dUBpbnRlbC5jb20+LgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5IGl0CisgKiB1bmRlciB0aGUg
dGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLAor
ICogdmVyc2lvbiAyLCBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
bi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgaXQgd2ls
bCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IKKyAqIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2NwdW1h
c2suaD4KKyNpbmNsdWRlIDxsaW51eC9jcHVmcmVxLmg+CisjaW5jbHVkZSA8bGludXgva2VybmVs
Lmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4K
KyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgorI2lu
Y2x1ZGUgPGFjcGkvYWNwaV9idXMuaD4KKyNpbmNsdWRlIDxhY3BpL2FjcGlfZHJpdmVycy5oPgor
I2luY2x1ZGUgPGFjcGkvcHJvY2Vzc29yLmg+CisKKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3Bs
YXRmb3JtLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKworI2RlZmluZSBEUlZf
TkFNRSAieGVuLXByb2Nlc3Nvci10aHJ1IgorTU9EVUxFX0FVVEhPUigiS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPiIpOworTU9EVUxFX0RFU0NSSVBUSU9OKCJB
Q1BJIFBvd2VyIE1hbmFnZW1lbnQgZHJpdmVyIHRvIHBhc3MgQ3ggYW5kIFB4eCBkYXRhIHRvIFhl
biBoeXBlcnZpc29yIik7CitNT0RVTEVfTElDRU5TRSgiR1BMIik7CisKKworc3RhdGljIGludCBu
b19oeXBlcmNhbGw7CitNT0RVTEVfUEFSTV9ERVNDKG9mZiwgIkluaGliaXQgdGhlIGh5cGVyY2Fs
bC4iKTsKK21vZHVsZV9wYXJhbV9uYW1lZChvZmYsIG5vX2h5cGVyY2FsbCwgaW50LCAwNDAwKTsK
KworLyoKKyAqIE11dGV4IHRvIHByb3RlY3QgdGhlIGFjcGlfaWRzX2RvbmUuCisgKi8KK3N0YXRp
YyBERUZJTkVfTVVURVgoYWNwaV9pZHNfbXV0ZXgpOworLyoKKyAqIERvbid0IHRoaW5rIGNvbnZl
cnQgdGhpcyB0byBjcHVtYXNrX3Zhcl90IG9yIHVzZSBjcHVtYXNrX2JpdCAtIGFzIHRob3NlCisg
KiBzaHJpbmsgdG8gbnJfY3B1X2JpdHMgKHdoaWNoIGlzIGRlcGVuZGVudCBvbiBwb3NzaWJsZV9j
cHUpLCB3aGljaCBjYW4gYmUKKyAqIGxlc3MgdGhhbiB3aGF0IHdlIHdhbnQgdG8gcHV0IGluLgor
ICovCisjZGVmaW5lIE5SX0FDUElfQ1BVUwlOUl9DUFVTCisjZGVmaW5lIE1BWF9BQ1BJX0JJVFMJ
KEJJVFNfVE9fTE9OR1MoTlJfQUNQSV9DUFVTKSkKK3N0YXRpYyB1bnNpZ25lZCBsb25nICphY3Bp
X2lkc19kb25lOworLyoKKyAqIEFnYWluLCBkb24ndCBjb252ZXJ0IHRvIGNwdW1hc2sgLSBhcyB3
ZSBhcmUgcmVhZGluZyB0aGUgcmF3IEFDUEkgQ1BVIGlkcworICogd2hpY2ggY2FuIGdvIGJleW9u
ZCB3aGF0IHdlIHByZXNlbnRseSBzZWUuCisgKi8KK3N0YXRpYyB1bnNpZ25lZCBsb25nICphY3Bp
X2lkX3ByZXNlbnQ7CisKKworI2RlZmluZSBQT0xMX1RJTUVSCW1zZWNzX3RvX2ppZmZpZXMoNTAw
MCAvKiA1IHNlYyAqLykKK3N0YXRpYyBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnhlbl9wcm9jZXNzb3Jf
dGhyZWFkOworCitzdGF0aWMgaW50IHhlbl9wdXNoX2N4eF90b19oeXBlcnZpc29yKHN0cnVjdCBh
Y3BpX3Byb2Nlc3NvciAqX3ByKQoreworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7CisJ
CS5jbWQJCQk9IFhFTlBGX3NldF9wcm9jZXNzb3JfcG1pbmZvLAorCQkuaW50ZXJmYWNlX3ZlcnNp
b24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuc2V0X3BtaW5mby5pZAk9IF9wci0+
YWNwaV9pZCwKKwkJLnUuc2V0X3BtaW5mby50eXBlCT0gWEVOX1BNX0NYLAorCX07CisJc3RydWN0
IHhlbl9wcm9jZXNzb3JfY3ggKnhlbl9jeCwgKnhlbl9jeF9zdGF0ZXMgPSBOVUxMOworCXN0cnVj
dCBhY3BpX3Byb2Nlc3Nvcl9jeCAqY3g7CisJaW50IGksIG9rLCByZXQgPSAwOworCisJeGVuX2N4
X3N0YXRlcyA9IGtjYWxsb2MoX3ByLT5wb3dlci5jb3VudCwKKwkJCQlzaXplb2Yoc3RydWN0IHhl
bl9wcm9jZXNzb3JfY3gpLCBHRlBfS0VSTkVMKTsKKwlpZiAoIXhlbl9jeF9zdGF0ZXMpCisJCXJl
dHVybiAtRU5PTUVNOworCisJZm9yIChvayA9IDAsIGkgPSAxOyBpIDw9IF9wci0+cG93ZXIuY291
bnQ7IGkrKykgeworCQljeCA9ICZfcHItPnBvd2VyLnN0YXRlc1tpXTsKKwkJaWYgKCFjeC0+dmFs
aWQpCisJCQljb250aW51ZTsKKworCQl4ZW5fY3ggPSAmKHhlbl9jeF9zdGF0ZXNbb2srK10pOwor
CisJCXhlbl9jeC0+cmVnLnNwYWNlX2lkID0gQUNQSV9BRFJfU1BBQ0VfU1lTVEVNX0lPOworCQlp
ZiAoY3gtPmVudHJ5X21ldGhvZCA9PSBBQ1BJX0NTVEFURV9TWVNURU1JTykgeworCQkJeGVuX2N4
LT5yZWcuYml0X3dpZHRoID0gODsKKwkJCXhlbl9jeC0+cmVnLmJpdF9vZmZzZXQgPSAwOworCQkJ
eGVuX2N4LT5yZWcuYWNjZXNzX3NpemUgPSAxOworCQl9IGVsc2UgeworCQkJeGVuX2N4LT5yZWcu
c3BhY2VfaWQgPSBBQ1BJX0FEUl9TUEFDRV9GSVhFRF9IQVJEV0FSRTsKKwkJCWlmIChjeC0+ZW50
cnlfbWV0aG9kID09IEFDUElfQ1NUQVRFX0ZGSCkgeworCQkJCS8qIE5BVElWRV9DU1RBVEVfQkVZ
T05EX0hBTFQgKi8KKwkJCQl4ZW5fY3gtPnJlZy5iaXRfb2Zmc2V0ID0gMjsKKwkJCQl4ZW5fY3gt
PnJlZy5iaXRfd2lkdGggPSAxOyAvKiBWRU5ET1JfSU5URUwgKi8KKwkJCX0KKwkJCXhlbl9jeC0+
cmVnLmFjY2Vzc19zaXplID0gMDsKKwkJfQorCQl4ZW5fY3gtPnJlZy5hZGRyZXNzID0gY3gtPmFk
ZHJlc3M7CisKKwkJeGVuX2N4LT50eXBlID0gY3gtPnR5cGU7CisJCXhlbl9jeC0+bGF0ZW5jeSA9
IGN4LT5sYXRlbmN5OworCQl4ZW5fY3gtPnBvd2VyID0gY3gtPnBvd2VyOworCisJCXhlbl9jeC0+
ZHBjbnQgPSAwOworCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fY3gtPmRwLCBOVUxMKTsKKyNp
ZmRlZiBERUJVRworCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiBDWDogSUQ6JWQgW0MlZDolc10gZW50
cnk6JWRcbiIsIF9wci0+YWNwaV9pZCwKKwkJCSBjeC0+dHlwZSwgY3gtPmRlc2MsIGN4LT5lbnRy
eV9tZXRob2QpOworI2VuZGlmCisJfQorCWlmICghb2spIHsKKwkJcHJfZXJyKERSVl9OQU1FICI6
IE5vIGF2YWlsYWJsZSBDeCBpbmZvIGZvciBjcHUgJWRcbiIsIF9wci0+YWNwaV9pZCk7CisJCWtm
cmVlKHhlbl9jeF9zdGF0ZXMpOworCQlyZXR1cm4gLUVJTlZBTDsKKwl9CisJb3AudS5zZXRfcG1p
bmZvLnBvd2VyLmNvdW50ID0gb2s7CisJb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZsYWdzLmJtX2Nv
bnRyb2wgPSBfcHItPmZsYWdzLmJtX2NvbnRyb2w7CisJb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZs
YWdzLmJtX2NoZWNrID0gX3ByLT5mbGFncy5ibV9jaGVjazsKKwlvcC51LnNldF9wbWluZm8ucG93
ZXIuZmxhZ3MuaGFzX2NzdCA9IF9wci0+ZmxhZ3MuaGFzX2NzdDsKKwlvcC51LnNldF9wbWluZm8u
cG93ZXIuZmxhZ3MucG93ZXJfc2V0dXBfZG9uZSA9CisJCV9wci0+ZmxhZ3MucG93ZXJfc2V0dXBf
ZG9uZTsKKworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG9wLnUuc2V0X3BtaW5mby5wb3dlci5zdGF0
ZXMsIHhlbl9jeF9zdGF0ZXMpOworCisJaWYgKCFub19oeXBlcmNhbGwpCisJCXJldCA9IEhZUEVS
VklTT1JfZG9tMF9vcCgmb3ApOworCisJaWYgKHJldCkKKwkJcHJfZXJyKERSVl9OQU1FICIoQ1gp
OiBIeXBlcnZpc29yIHJldHVybmVkICglZCkgZm9yIEFDUEkgSUQ6ICVkXG4iLAorCQkgICAgICAg
cmV0LCBfcHItPmFjcGlfaWQpOworCisJa2ZyZWUoeGVuX2N4X3N0YXRlcyk7CisKKwlyZXR1cm4g
cmV0OworfQorc3RhdGljIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3B4ICp4ZW5fY29weV9wc3NfZGF0
YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wciwKKwkJCQkJCSAgc3RydWN0IHhlbl9wcm9jZXNz
b3JfcGVyZm9ybWFuY2UgKnhlbl9wZXJmKQoreworCXN0cnVjdCB4ZW5fcHJvY2Vzc29yX3B4ICp4
ZW5fc3RhdGVzID0gTlVMTDsKKwlpbnQgaTsKKworCUJVSUxEX0JVR19PTihzaXplb2Yoc3RydWN0
IHhlbl9wcm9jZXNzb3JfcHgpICE9CisJCSAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
cl9weCkpOworCisJeGVuX3N0YXRlcyA9IGtjYWxsb2MoX3ByLT5wZXJmb3JtYW5jZS0+c3RhdGVf
Y291bnQsCisJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCksIEdGUF9LRVJO
RUwpOworCWlmICgheGVuX3N0YXRlcykKKwkJcmV0dXJuIEVSUl9QVFIoLUVOT01FTSk7CisKKwl4
ZW5fcGVyZi0+c3RhdGVfY291bnQgPSBfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudDsKKwlm
b3IgKGkgPSAwOyBpIDwgX3ByLT5wZXJmb3JtYW5jZS0+c3RhdGVfY291bnQ7IGkrKykgeworCQkv
KiBGb3J0dW5hdGx5IGZvciB1cywgdGhleSBhcmUgYm90aCB0aGUgc2FtZSBzaXplICovCisJCW1l
bWNweSgmKHhlbl9zdGF0ZXNbaV0pLCAmKF9wci0+cGVyZm9ybWFuY2UtPnN0YXRlc1tpXSksCisJ
CSAgICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHJvY2Vzc29yX3B4KSk7CisJfQorCXJldHVybiB4
ZW5fc3RhdGVzOworfQorc3RhdGljIGludCB4ZW5fY29weV9wc2RfZGF0YShzdHJ1Y3QgYWNwaV9w
cm9jZXNzb3IgKl9wciwKKwkJCSAgICAgc3RydWN0IHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2Ug
Knhlbl9wZXJmKQoreworCUJVSUxEX0JVR19PTihzaXplb2Yoc3RydWN0IHhlbl9wc2RfcGFja2Fn
ZSkgIT0KKwkJICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHNkX3BhY2thZ2UpKTsKKworCWlmIChf
cHItPnBlcmZvcm1hbmNlLT5zaGFyZWRfdHlwZSAhPSBDUFVGUkVRX1NIQVJFRF9UWVBFX05PTkUp
IHsKKwkJeGVuX3BlcmYtPnNoYXJlZF90eXBlID0gX3ByLT5wZXJmb3JtYW5jZS0+c2hhcmVkX3R5
cGU7CisKKwkJbWVtY3B5KCYoeGVuX3BlcmYtPmRvbWFpbl9pbmZvKSwgJihfcHItPnBlcmZvcm1h
bmNlLT5kb21haW5faW5mbyksCisJCSAgICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHNkX3BhY2th
Z2UpKTsKKwl9IGVsc2UgeworCQlpZiAoKCZjcHVfZGF0YSgwKSktPng4Nl92ZW5kb3IgIT0gWDg2
X1ZFTkRPUl9BTUQpCisJCQlyZXR1cm4gLUVJTlZBTDsKKworCQkvKiBPbiBBTUQsIHRoZSBwb3dl
cm5vdy1rOCBpcyBsb2FkZWQgYmVmb3JlIGFjcGlfY3B1ZnJlcQorCQkgKiBtZWFuaW5nIHRoYXQg
YWNwaV9wcm9jZXNzb3JfcHJlcmVnaXN0ZXJfcGVyZm9ybWFuY2UgbmV2ZXIKKwkJICogZ2V0cyBj
YWxsZWQgd2hpY2ggd291bGQgcGFyc2UgdGhlIF9QU0QuIFRoZSBvbmx5IHJlbGV2YW50CisJCSAq
IGluZm9ybWF0aW9uIGZyb20gX1BTRCB3ZSBuZWVkIGlzIHdoZXRoZXIgaXQgaXMgSFdfQUxMIG9y
IGFueQorCQkgKiBvdGhlciB0eXBlLiBBTUQgSzggPj0gYXJlIFNXX0FMTCBvciBTV19BTlksIEFN
RCBLNzw9IEhXX0FOWS4KKwkJICogVGhpcyBkcml2ZXIgY2hlY2tzIGF0IHRoZSBzdGFydCB3aGV0
aGVyIGl0IGlzIEs4IHNvIGl0CisJCSAqIGlmIHdlIGdldCBoZXJlIGl0IGNhbiBvbmx5IGJlIEs4
LgorCQkgKi8KKwkJeGVuX3BlcmYtPnNoYXJlZF90eXBlID0gQ1BVRlJFUV9TSEFSRURfVFlQRV9B
Tlk7CisJCXhlbl9wZXJmLT5kb21haW5faW5mby5jb29yZF90eXBlID0gRE9NQUlOX0NPT1JEX1RZ
UEVfU1dfQU5ZOworCQl4ZW5fcGVyZi0+ZG9tYWluX2luZm8ubnVtX3Byb2Nlc3NvcnMgPSBudW1f
b25saW5lX2NwdXMoKTsKKwl9CisJcmV0dXJuIDA7Cit9CitzdGF0aWMgaW50IHhlbl9jb3B5X3Bj
dF9kYXRhKHN0cnVjdCBhY3BpX3BjdF9yZWdpc3RlciAqcGN0LAorCQkJICAgICBzdHJ1Y3QgeGVu
X3BjdF9yZWdpc3RlciAqX3BjdCkKK3sKKwkvKiBJdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3Vs
ZCBqdXN0IGRvICdtZW1jcHkocGN0LCBfcGN0JykgYnV0CisJICogc2FkbHkgdGhlIFhlbiBzdHJ1
Y3R1cmUgZGlkIG5vdCBoYXZlIHRoZSBwcm9wZXIgcGFkZGluZworCSAqIHNvIHRoZSBkZXNjcmlw
dG9yIGZpZWxkIHRha2VzIHR3byAoX3BjdCkgYnl0ZXMgaW5zdGVhZCBvZiBvbmUgKHBjdCkuCisJ
ICovCisJX3BjdC0+ZGVzY3JpcHRvciA9IHBjdC0+ZGVzY3JpcHRvcjsKKwlfcGN0LT5sZW5ndGgg
PSBwY3QtPmxlbmd0aDsKKwlfcGN0LT5zcGFjZV9pZCA9IHBjdC0+c3BhY2VfaWQ7CisJX3BjdC0+
Yml0X3dpZHRoID0gcGN0LT5iaXRfd2lkdGg7CisJX3BjdC0+Yml0X29mZnNldCA9IHBjdC0+Yml0
X29mZnNldDsKKwlfcGN0LT5yZXNlcnZlZCA9IHBjdC0+cmVzZXJ2ZWQ7CisJX3BjdC0+YWRkcmVz
cyA9IHBjdC0+YWRkcmVzczsKKwlyZXR1cm4gMDsKK30KK3N0YXRpYyBpbnQgeGVuX3B1c2hfcHh4
X3RvX2h5cGVydmlzb3Ioc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIpCit7CisJaW50IHJldCA9
IDA7CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZAkJCT0gWEVOUEZfc2V0
X3Byb2Nlc3Nvcl9wbWluZm8sCisJCS5pbnRlcmZhY2VfdmVyc2lvbgk9IFhFTlBGX0lOVEVSRkFD
RV9WRVJTSU9OLAorCQkudS5zZXRfcG1pbmZvLmlkCT0gX3ByLT5hY3BpX2lkLAorCQkudS5zZXRf
cG1pbmZvLnR5cGUJPSBYRU5fUE1fUFgsCisJfTsKKwlzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9wZXJm
b3JtYW5jZSAqeGVuX3BlcmY7CisJc3RydWN0IHhlbl9wcm9jZXNzb3JfcHggKnhlbl9zdGF0ZXMg
PSBOVUxMOworCisJeGVuX3BlcmYgPSAmb3AudS5zZXRfcG1pbmZvLnBlcmY7CisKKwl4ZW5fcGVy
Zi0+cGxhdGZvcm1fbGltaXQgPSBfcHItPnBlcmZvcm1hbmNlX3BsYXRmb3JtX2xpbWl0OworCXhl
bl9wZXJmLT5mbGFncyB8PSBYRU5fUFhfUFBDOworCXhlbl9jb3B5X3BjdF9kYXRhKCYoX3ByLT5w
ZXJmb3JtYW5jZS0+Y29udHJvbF9yZWdpc3RlciksCisJCQkgICZ4ZW5fcGVyZi0+Y29udHJvbF9y
ZWdpc3Rlcik7CisJeGVuX2NvcHlfcGN0X2RhdGEoJihfcHItPnBlcmZvcm1hbmNlLT5zdGF0dXNf
cmVnaXN0ZXIpLAorCQkJICAmeGVuX3BlcmYtPnN0YXR1c19yZWdpc3Rlcik7CisJeGVuX3BlcmYt
PmZsYWdzIHw9IFhFTl9QWF9QQ1Q7CisJeGVuX3N0YXRlcyA9IHhlbl9jb3B5X3Bzc19kYXRhKF9w
ciwgeGVuX3BlcmYpOworCWlmICghSVNfRVJSX09SX05VTEwoeGVuX3N0YXRlcykpIHsKKwkJc2V0
X3hlbl9ndWVzdF9oYW5kbGUoeGVuX3BlcmYtPnN0YXRlcywgeGVuX3N0YXRlcyk7CisJCXhlbl9w
ZXJmLT5mbGFncyB8PSBYRU5fUFhfUFNTOworCX0KKwlpZiAoIXhlbl9jb3B5X3BzZF9kYXRhKF9w
ciwgeGVuX3BlcmYpKQorCQl4ZW5fcGVyZi0+ZmxhZ3MgfD0gWEVOX1BYX1BTRDsKKworCWlmICgh
bm9faHlwZXJjYWxsKQorCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKworCWlmIChy
ZXQpCisJCXByX2VycihEUlZfTkFNRSAiKF9QWFgpOiBIeXBlcnZpc29yIHJldHVybmVkICglZCkg
Zm9yIEFDUEkgSUQgJWRcbiIsCisJCSAgICAgICByZXQsIF9wci0+YWNwaV9pZCk7CisKKwlpZiAo
IUlTX0VSUl9PUl9OVUxMKHhlbl9zdGF0ZXMpKQorCQlrZnJlZSh4ZW5fc3RhdGVzKTsKKworCXJl
dHVybiByZXQ7Cit9CisvKgorICogV2UgcmVhZCBvdXQgdGhlIHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciwgYW5kIHNlcmlhbGl6ZSBhY2Nlc3MKKyAqIHNvIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgY2Fs
bGVyLiBUaGlzIGlzIHNvIHRoYXQgd2Ugd29uJ3QKKyAqIHJhY2Ugd2l0aCB0aGUgQ1BVIGhvdHBs
dWcgY29kZSAoeGVuX2NwdV9zb2Z0X25vdGlmeSkuCisgKi8KK3N0YXRpYyBpbnQgeGVuX3Byb2Nl
c3NfZGF0YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wcikKK3sKKwlpbnQgZXJyID0gMDsKKwor
CW11dGV4X2xvY2soJmFjcGlfaWRzX211dGV4KTsKKwlpZiAoX190ZXN0X2FuZF9zZXRfYml0KF9w
ci0+YWNwaV9pZCwgYWNwaV9pZHNfZG9uZSkpIHsKKwkJbXV0ZXhfdW5sb2NrKCZhY3BpX2lkc19t
dXRleCk7CisJCXJldHVybiAtRUJVU1k7CisJfQorCWlmIChfcHItPmZsYWdzLnBvd2VyKQorCQll
cnIgPSB4ZW5fcHVzaF9jeHhfdG9faHlwZXJ2aXNvcihfcHIpOworCisJaWYgKF9wci0+cGVyZm9y
bWFuY2UgJiYgX3ByLT5wZXJmb3JtYW5jZS0+c3RhdGVzKQorCQllcnIgfD0geGVuX3B1c2hfcHh4
X3RvX2h5cGVydmlzb3IoX3ByKTsKKworCW11dGV4X3VubG9jaygmYWNwaV9pZHNfbXV0ZXgpOwor
CXJldHVybiBlcnI7Cit9CitzdGF0aWMgYWNwaV9zdGF0dXMKK3hlbl9yZWFkX2FjcGlfaWQoYWNw
aV9oYW5kbGUgaGFuZGxlLCB1MzIgbHZsLCB2b2lkICpjb250ZXh0LCB2b2lkICoqcnYpCit7CisJ
dTMyIGFjcGlfaWQ7CisJYWNwaV9zdGF0dXMgc3RhdHVzOworCWFjcGlfb2JqZWN0X3R5cGUgYWNw
aV90eXBlOworCXVuc2lnbmVkIGxvbmcgbG9uZyB0bXA7CisJdW5pb24gYWNwaV9vYmplY3Qgb2Jq
ZWN0ID0geyAwIH07CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgc2l6ZW9mKHVuaW9u
IGFjcGlfb2JqZWN0KSwgJm9iamVjdCB9OworCisJc3RhdHVzID0gYWNwaV9nZXRfdHlwZShoYW5k
bGUsICZhY3BpX3R5cGUpOworCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJcmV0dXJuIEFF
X09LOworCisJc3dpdGNoIChhY3BpX3R5cGUpIHsKKwljYXNlIEFDUElfVFlQRV9QUk9DRVNTT1I6
CisJCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2JqZWN0KGhhbmRsZSwgTlVMTCwgTlVMTCwgJmJ1
ZmZlcik7CisJCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJCXJldHVybiBBRV9PSzsKKwkJ
YWNwaV9pZCA9IG9iamVjdC5wcm9jZXNzb3IucHJvY19pZDsKKwkJYnJlYWs7CisJY2FzZSBBQ1BJ
X1RZUEVfREVWSUNFOgorCQlzdGF0dXMgPSBhY3BpX2V2YWx1YXRlX2ludGVnZXIoaGFuZGxlLCAi
X1VJRCIsIE5VTEwsICZ0bXApOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpCisJCQlyZXR1
cm4gQUVfT0s7CisJCWFjcGlfaWQgPSB0bXA7CisJCWJyZWFrOworCWRlZmF1bHQ6CisJCXJldHVy
biBBRV9PSzsKKwl9CisJaWYgKGFjcGlfaWQgPiBOUl9BQ1BJX0NQVVMpIHsKKwkJV0FSTl9PTkNF
KDEsICJUaGVyZSBhcmUgJWQgQUNQSSBwcm9jZXNzb3JzLCBidXQga2VybmVsIGNhbiBvbmx5IGRv
ICVkIVxuIiwKKwkJICAgICBhY3BpX2lkLCBOUl9BQ1BJX0NQVVMpOworCQlyZXR1cm4gQUVfT0s7
CisJfQorCV9fc2V0X2JpdChhY3BpX2lkLCBhY3BpX2lkX3ByZXNlbnQpOworCisJcmV0dXJuIEFF
X09LOworfQorc3RhdGljIHVuc2lnbmVkIGludCB4ZW5fYWNwaV9pZHNfbW9yZSh2b2lkKQorewor
CXVuc2lnbmVkIGludCBuID0gMDsKKworCWFjcGlfd2Fsa19uYW1lc3BhY2UoQUNQSV9UWVBFX1BS
T0NFU1NPUiwgQUNQSV9ST09UX09CSkVDVCwKKwkJCSAgICBBQ1BJX1VJTlQzMl9NQVgsCisJCQkg
ICAgeGVuX3JlYWRfYWNwaV9pZCwgTlVMTCwgTlVMTCwgTlVMTCk7CisJYWNwaV9nZXRfZGV2aWNl
cygiQUNQSTAwMDciLCB4ZW5fcmVhZF9hY3BpX2lkLCBOVUxMLCBOVUxMKTsKKworCW11dGV4X2xv
Y2soJmFjcGlfaWRzX211dGV4KTsKKwlpZiAoIWJpdG1hcF9lcXVhbChhY3BpX2lkX3ByZXNlbnQs
IGFjcGlfaWRzX2RvbmUsIE1BWF9BQ1BJX0JJVFMpKQorCQluID0gYml0bWFwX3dlaWdodChhY3Bp
X2lkX3ByZXNlbnQsIE1BWF9BQ1BJX0JJVFMpOworCW11dGV4X3VubG9jaygmYWNwaV9pZHNfbXV0
ZXgpOworCisJcmV0dXJuIG47Cit9CisKK3N0YXRpYyBpbnQgeGVuX3Byb2Nlc3Nvcl9jaGVjayh2
b2lkKQoreworCXN0cnVjdCBjcHVmcmVxX3BvbGljeSAqcG9saWN5OworCXN0cnVjdCBhY3BpX3By
b2Nlc3NvciAqcHJfYmFja3VwID0gTlVMTDsKKwlpbnQgY3B1LCBlcnIgPSAwOworCisJY3B1ID0g
Z2V0X2NwdSgpOworCXB1dF9jcHUoKTsKKwlwb2xpY3kgPSBjcHVmcmVxX2NwdV9nZXQoY3B1KTsK
KwlpZiAoIXBvbGljeSkKKwkJcmV0dXJuIC1FQlVTWTsKKworCWdldF9vbmxpbmVfY3B1cygpOwor
CWZvcl9lYWNoX29ubGluZV9jcHUoY3B1KSB7CisJCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3By
OworCisJCV9wciA9IHBlcl9jcHUocHJvY2Vzc29ycywgY3B1IC8qIEFQSUMgSUQgKi8pOworCQlp
ZiAoIV9wcikKKwkJCWNvbnRpbnVlOworCisJCWlmICghcHJfYmFja3VwKSB7CisJCQlwcl9iYWNr
dXAgPSBremFsbG9jKHNpemVvZihzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IpLCBHRlBfS0VSTkVMKTsK
KwkJCW1lbWNweShwcl9iYWNrdXAsIF9wciwgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nlc3Nvcikp
OworCQl9CisJCSh2b2lkKXhlbl9wcm9jZXNzX2RhdGEoX3ByKTsKKwl9CisJcHV0X29ubGluZV9j
cHVzKCk7CisKKwljcHVmcmVxX2NwdV9wdXQocG9saWN5KTsKKworCS8qIEFsbCBvbmxpbmUgQ1BV
cyBoYXZlIGJlZW4gcHJvY2Vzc2VkIGF0IHRoaXMgc3RhZ2UuIE5vdyB2ZXJpZnkKKwkgKiB3aGV0
aGVyIGluIGZhY3QgIm9ubGluZSBDUFVzIiA9PSBwaHlzaWNhbCBDUFVzLgorCSAqLworCWFjcGlf
aWRfcHJlc2VudCA9IGtjYWxsb2MoTUFYX0FDUElfQklUUywgc2l6ZW9mKHVuc2lnbmVkIGxvbmcp
LCBHRlBfS0VSTkVMKTsKKwlpZiAoIWFjcGlfaWRfcHJlc2VudCkgeworCQllcnIgPSAtRU5PTUVN
OworCQlnb3RvIGVycl9vdXQ7CisJfQorCW1lbXNldChhY3BpX2lkX3ByZXNlbnQsIDAsIE1BWF9B
Q1BJX0JJVFMgKiBzaXplb2YodW5zaWduZWQgbG9uZykpOworCisJaWYgKHhlbl9hY3BpX2lkc19t
b3JlKCkgJiYgcHJfYmFja3VwKSB7CisJCWZvcl9lYWNoX3NldF9iaXQoY3B1LCBhY3BpX2lkX3By
ZXNlbnQsIE1BWF9BQ1BJX0JJVFMpIHsKKwkJCXByX2JhY2t1cC0+YWNwaV9pZCA9IGNwdTsKKwkJ
CS8qIFdlIHdpbGwgZ2V0IC1FQlVTWSBpZiBpdCBoYXMgYmVlbiBwcm9ncmFtbWVkIGFscmVhZHku
ICovCisJCQkodm9pZCl4ZW5fcHJvY2Vzc19kYXRhKHByX2JhY2t1cCk7CisJCX0KKwl9CisJa2Zy
ZWUoYWNwaV9pZF9wcmVzZW50KTsKKwlhY3BpX2lkX3ByZXNlbnQgPSBOVUxMOworZXJyX291dDoK
KwlrZnJlZShwcl9iYWNrdXApOworCXByX2JhY2t1cCA9IE5VTEw7CisJcmV0dXJuIGVycjsKK30K
Ky8qCisgKiBUaGUgcHVycG9zZSBvZiB0aGlzIHRpbWVyL3RocmVhZCBpcyB0byB3YWl0IGZvciB0
aGUgQUNQSSBwcm9jZXNzb3IKKyAqIGFuZCBDUFVmcmVxIGRyaXZlcnMgdG8gbG9hZCB1cCBhbmQg
cGFyc2UgdGhlIFB4eCBhbmQgQ3h4IGluZm9ybWF0aW9uCisgKiBiZWZvcmUgd2UgYXR0ZW1wdCB0
byByZWFkIGl0LgorICovCitzdGF0aWMgdm9pZCB4ZW5fcHJvY2Vzc29yX3RpbWVvdXQodW5zaWdu
ZWQgbG9uZyBhcmcpCit7CisJd2FrZV91cF9wcm9jZXNzKChzdHJ1Y3QgdGFza19zdHJ1Y3QgKilh
cmcpOworfQorc3RhdGljIGludCB4ZW5fcHJvY2Vzc29yX3RocmVhZF9mdW5jKHZvaWQgKmR1bW15
KQoreworCXN0cnVjdCB0aW1lcl9saXN0IHRpbWVyOworCWludCBlcnIgPSAwOworCisJc2V0dXBf
ZGVmZXJyYWJsZV90aW1lcl9vbl9zdGFjaygmdGltZXIsIHhlbl9wcm9jZXNzb3JfdGltZW91dCwK
KwkJCQkJKHVuc2lnbmVkIGxvbmcpY3VycmVudCk7CisJZG8geworCQlfX3NldF9jdXJyZW50X3N0
YXRlKFRBU0tfSU5URVJSVVBUSUJMRSk7CisJCW1vZF90aW1lcigmdGltZXIsIGppZmZpZXMgKyBQ
T0xMX1RJTUVSKTsKKwkJc2NoZWR1bGUoKTsKKwkJZXJyID0geGVuX3Byb2Nlc3Nvcl9jaGVjaygp
OworCQlpZiAoZXJyICE9IC1FQlVTWSkKKwkJCWJyZWFrOworCX0gd2hpbGUgKCFrdGhyZWFkX3No
b3VsZF9zdG9wKCkpOworCisJaWYgKGVycikKKwkJcHJfZXJyKERSVl9OQU1FICI6IEZhaWxlZCB0
byB1cGxvYWQgZGF0YSAoJWQpIVxuIiwgZXJyKTsKKwlkZWxfdGltZXJfc3luYygmdGltZXIpOwor
CWRlc3Ryb3lfdGltZXJfb25fc3RhY2soJnRpbWVyKTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGlj
IGludCB4ZW5fY3B1X3NvZnRfbm90aWZ5KHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmZiLAorCQkJ
ICAgICAgIHVuc2lnbmVkIGxvbmcgYWN0aW9uLCB2b2lkICpoY3B1KQoreworCXVuc2lnbmVkIGlu
dCBjcHUgPSAodW5zaWduZWQgbG9uZyloY3B1OworCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3By
ID0gcGVyX2NwdShwcm9jZXNzb3JzLCBjcHUpOworCisJaWYgKGFjdGlvbiA9PSBDUFVfT05MSU5F
ICYmIF9wcikKKwkJKHZvaWQpeGVuX3Byb2Nlc3NfZGF0YShfcHIpOworCisJcmV0dXJuIE5PVElG
WV9PSzsKK30KKworc3RhdGljIHN0cnVjdCBub3RpZmllcl9ibG9jayB4ZW5fY3B1X25vdGlmaWVy
ID0geworCS5ub3RpZmllcl9jYWxsID0geGVuX2NwdV9zb2Z0X25vdGlmeSwKKwkucHJpb3JpdHkg
PSAtMSwgLyogQmUgdGhlIGxhc3Qgb25lICovCit9OworCitzdGF0aWMgaW50IF9faW5pdCBjaGVj
a19wcmVyZXEodm9pZCkKK3sKKwlzdHJ1Y3QgY3B1aW5mb194ODYgKmMgPSAmY3B1X2RhdGEoMCk7
CisKKwlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCWlm
ICghYWNwaV9nYmxfRkFEVC5zbWlfY29tbWFuZCkKKwkJcmV0dXJuIC1FTk9ERVY7CisKKwlpZiAo
Yy0+eDg2X3ZlbmRvciA9PSBYODZfVkVORE9SX0lOVEVMKSB7CisJCWlmICghY3B1X2hhcyhjLCBY
ODZfRkVBVFVSRV9FU1QpKQorCQkJcmV0dXJuIC1FTk9ERVY7CisKKwkJcmV0dXJuIDA7CisJfQor
CWlmIChjLT54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfQU1EKSB7CisJCXUzMiBoaSA9IDAsIGxv
ID0gMDsKKwkJLyogQ29waWVkIGZyb20gcG93ZXJub3ctazguaCwgY2FuJ3QgaW5jbHVkZSAuLi9j
cHVmcmVxL3Bvd2Vybm93CisJCSAqIGFzIHdlIGdldCBjb21waWxlIHdhcm5pbmdzIGZvciB0aGUg
c3RhdGljIGZ1bmN0aW9ucy4KKwkJICovCisjZGVmaW5lIE1TUl9QU1RBVEVfQ1VSX0xJTUlUICAg
IDB4YzAwMTAwNjEgLyogcHN0YXRlIGN1cnJlbnQgbGltaXQgTVNSICovCisJCXJkbXNyKE1TUl9Q
U1RBVEVfQ1VSX0xJTUlULCBsbywgaGkpOworCisJCS8qIElmIHRoZSBNU1IgY2Fubm90IHByb3Zp
ZGUgdGhlIGRhdGEsIHRoZSBwb3dlcm5vdy1rOAorCQkgKiB3b24ndCBwcm9jZXNzIHRoZSBkYXRh
IHByb3Blcmx5IGVpdGhlci4KKwkJICovCisJCWlmIChoaSB8fCBsbykKKwkJCXJldHVybiAwOwor
CX0KKwlyZXR1cm4gLUVOT0RFVjsKK30KKworc3RhdGljIGludCBfX2luaXQgeGVuX3Byb2Nlc3Nv
cl9wYXNzdGhydV9pbml0KHZvaWQpCit7CisJaW50IHJjID0gY2hlY2tfcHJlcmVxKCk7CisKKwlp
ZiAocmMpCisJCXJldHVybiByYzsKKworCWFjcGlfaWRzX2RvbmUgPSBrY2FsbG9jKE1BWF9BQ1BJ
X0JJVFMsIHNpemVvZih1bnNpZ25lZCBsb25nKSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFhY3BpX2lk
c19kb25lKQorCQlyZXR1cm4gLUVOT01FTTsKKwltZW1zZXQoYWNwaV9pZHNfZG9uZSwgMCwgTUFY
X0FDUElfQklUUyAqIHNpemVvZih1bnNpZ25lZCBsb25nKSk7CisJeGVuX3Byb2Nlc3Nvcl90aHJl
YWQgPSBrdGhyZWFkX3J1bih4ZW5fcHJvY2Vzc29yX3RocmVhZF9mdW5jLCBOVUxMLCBEUlZfTkFN
RSk7CisJaWYgKElTX0VSUih4ZW5fcHJvY2Vzc29yX3RocmVhZCkpIHsKKwkJcHJfZXJyKERSVl9O
QU1FICI6IEZhaWxlZCB0byBjcmVhdGUgdGhyZWFkLiBBYm9ydGluZy5cbiIpOworCQlyZXR1cm4g
LUVOT01FTTsKKwl9CisJcmVnaXN0ZXJfaG90Y3B1X25vdGlmaWVyKCZ4ZW5fY3B1X25vdGlmaWVy
KTsKKwlyZXR1cm4gMDsKK30KK3N0YXRpYyB2b2lkIF9fZXhpdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0
aHJ1X2V4aXQodm9pZCkKK3sKKwl1bnJlZ2lzdGVyX2hvdGNwdV9ub3RpZmllcigmeGVuX2NwdV9u
b3RpZmllcik7CisJaWYgKHhlbl9wcm9jZXNzb3JfdGhyZWFkKQorCQlrdGhyZWFkX3N0b3AoeGVu
X3Byb2Nlc3Nvcl90aHJlYWQpOworCWtmcmVlKGFjcGlfaWRzX2RvbmUpOworfQorbGF0ZV9pbml0
Y2FsbCh4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJ1X2luaXQpOworbW9kdWxlX2V4aXQoeGVuX3Byb2Nl
c3Nvcl9wYXNzdGhydV9leGl0KTsKLS0gCjEuNy45LjQ4Lmc4NWRhNGQKCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFf-0000Xd-Ft; Thu, 23 Feb 2012 22:35:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0hFd-0000Ws-LU
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:35:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330036493!16112426!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10320 invoked from network); 23 Feb 2012 22:34:55 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 22:34:55 -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 q1NMYmWs007852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:49 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
	q1NMYl35005551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 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
	q1NMYkpZ030010; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B945E41741; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:10 -0500
Message-Id: <1330036270-20015-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090201.4F46BF09.00BF,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/3] xen/processor-passthru: Provide an driver
	that passes struct acpi_processor data to the hypervisor.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VGhlIEFDUEkgcHJvY2Vzc29yIHByb2Nlc3NlcyB0aGUgX1B4eCBhbmQgdGhlIF9DeCBzdGF0ZSBp
bmZvcm1hdGlvbgp3aGljaCBhcmUgcG9wdWxhdGVkIGluIHRoZSAnc3RydWN0IGFjcGlfcHJvY2Vz
c29yJyBwZXItY3B1IHN0cnVjdHVyZS4KV2UgcmVhZCB0aGUgY29udGVudHMgb2YgdGhhdCBzdHJ1
Y3R1cmUgYW5kIHBhc3MgaXQgdXAgdGhlIFhlbiBoeXBlcnZpc29yLgoKVGhlIEFDUEkgcHJvY2Vz
c29yIGFsb25nIHdpdGggdGhlIENQVSBmcmVxIGRyaXZlciBkb2VzIGFsbCB0aGUgaGVhdnktbGlm
dGluZwpmb3IgdXMgKGZpbHRlcmluZywgY2FsbGluZyBBQ1BJIGZ1bmN0aW9ucywgZXRjKSBzbyB0
aGF0IHRoZSBjb250ZW50cyBpcyBjb3JyZWN0LgpBZnRlciB3ZSBhcmUgZG9uZSBwYXJzaW5nIHRo
ZSBpbmZvcm1hdGlvbiwgd2Ugd2FpdCBpbiBjYXNlIG9mIGhvdHBsdWcgQ1BVcwpnZXQgbG9hZGVk
IGFuZCB0aGVuIHBhc3MgdGhhdCBpbmZvcm1hdGlvbiB0byB0aGUgaHlwZXJ2aXNvci4KClt2MS12
MjogSW5pdGlhbCBSRkMgaW1wbGVtZW50YXRpb25zIHRoYXQgd2VyZSBwb3N0ZWRdClt2MzogQ2hh
bmdlZCB0aGUgbmFtZSB0byBwYXNzdGhydSBzdWdnZXN0ZWQgYnkgUGFzaSBLw6Rya2vDpGluZW4g
PHBhc2lrQGlraS5maT5dClt2NDogQWRkZWQgdkNQVSAhPSBwQ1BVIHN1cHBvcnQgLSBha2EgZG9t
MF9tYXhfdmNwdXMgc3VwcG9ydF0KW3Y1OiBDbGVhbmVkIHVwIHRoZSBkcml2ZXIsIGZpeCBidWcg
dW5kZXIgQXRobG9uIFhQXQpTaWduZWQtb2ZmLWJ5OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtv
bnJhZC53aWxrQG9yYWNsZS5jb20+Ci0tLQogZHJpdmVycy94ZW4vS2NvbmZpZyAgICAgICAgICAg
ICAgfCAgIDE0ICsKIGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgIHwgICAgMiArLQog
ZHJpdmVycy94ZW4vcHJvY2Vzc29yLXBhc3N0aHJ1LmMgfCAgNDkyICsrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrCiAzIGZpbGVzIGNoYW5nZWQsIDUwNyBpbnNlcnRpb25zKCsp
LCAxIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMveGVuL3Byb2Nlc3Nv
ci1wYXNzdGhydS5jCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vS2NvbmZpZyBiL2RyaXZlcnMv
eGVuL0tjb25maWcKaW5kZXggYTFjZWQ1Mi4uYWY1ZTA2MiAxMDA2NDQKLS0tIGEvZHJpdmVycy94
ZW4vS2NvbmZpZworKysgYi9kcml2ZXJzL3hlbi9LY29uZmlnCkBAIC0xNzgsNCArMTc4LDE4IEBA
IGNvbmZpZyBYRU5fUFJJVkNNRAogCWRlcGVuZHMgb24gWEVOCiAJZGVmYXVsdCBtCiAKK2NvbmZp
ZyBYRU5fUFJPQ0VTU09SX1BBU1NUSFJVCisJdHJpc3RhdGUgIlByb2Nlc3NvciBwYXNzdGhyb3Vn
aCBkcml2ZXIgZm9yIFhlbiIKKwlkZXBlbmRzIG9uIFhFTgorCWRlcGVuZHMgb24gQUNQSV9QUk9D
RVNTT1IKKwlkZXBlbmRzIG9uIFg4NgorCWRlcGVuZHMgb24gQ1BVX0ZSRVEKKwloZWxwCisJICBU
aGlzIGRyaXZlciBwYXJzZXMgdGhlIHByb2Nlc3NvciBzdHJ1Y3R1cmUgYW5kIHBhc3NlcyB0aGUg
aW5mb3JtYXRpb24KKwkgIHRvIHRoZSBYZW4gaHlwZXJ2aXNvci4gSXQgaXMgdXNlZCB0byBhbGxv
dyB0aGUgWGVuIGh5cGVydmlzb3IgdG8gaGF2ZSB0aGUKKwkgIGZ1bGwgcG93ZXIgbWFuYWdlbWVu
dCBkYXRhIGFuZCBiZSBhYmxlIHRvIHNlbGVjdCBwcm9wZXIgQ3ggYW5kIFB4eCBzdGF0ZXMuCisK
KwkgIFRoZSBkcml2ZXIgc2hvdWxkIGJlIGxvYWRlZCBhZnRlciBhY3BpIHByb2Nlc3NvciBhbmQg
Y3B1ZnJlcSBkcml2ZXJzIGhhdmUKKwkgIGJlZW4gbG9hZGVkLiBJZiB5b3UgZG8gbm90IGtub3cg
d2hhdCB0byBjaG9vc2UsIHNlbGVjdCBNIGhlcmUuCisKIGVuZG1lbnUKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKaW5kZXggYWEzMTMzNy4u
Y2UyMzVlN2EgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMv
eGVuL01ha2VmaWxlCkBAIC0yMCw3ICsyMCw3IEBAIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJ
CSs9IHN3aW90bGIteGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubwogb2Jq
LSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05G
SUdfWEVOX1BSSVZDTUQpCQkrPSB4ZW4tcHJpdmNtZC5vCi0KK29iai0kKENPTkZJR19YRU5fUFJP
Q0VTU09SX1BBU1NUSFJVKQkrPSBwcm9jZXNzb3ItcGFzc3RocnUubwogeGVuLWV2dGNobi15CQkJ
CTo9IGV2dGNobi5vCiB4ZW4tZ250ZGV2LXkJCQkJOj0gZ250ZGV2Lm8KIHhlbi1nbnRhbGxvYy15
CQkJCTo9IGdudGFsbG9jLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3Byb2Nlc3Nvci1wYXNz
dGhydS5jIGIvZHJpdmVycy94ZW4vcHJvY2Vzc29yLXBhc3N0aHJ1LmMKbmV3IGZpbGUgbW9kZSAx
MDA2NDQKaW5kZXggMDAwMDAwMC4uZTRkZmY0MgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZlcnMv
eGVuL3Byb2Nlc3Nvci1wYXNzdGhydS5jCkBAIC0wLDAgKzEsNDkyIEBACisvKgorICogQ29weXJp
Z2h0IDIwMTIgYnkgT3JhY2xlIEluYworICogQXV0aG9yOiBLb25yYWQgUnplc3p1dGVrIFdpbGsg
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CisgKgorICogVGhpcyBjb2RlIGJvcnJvd3MgaWRlYXMg
ZnJvbSBodHRwczovL2xrbWwub3JnL2xrbWwvMjAxMS8xMS8zMC8yNDkKKyAqIHNvIG1hbnkgdGhh
bmtzIGdvIHRvIEtldmluIFRpYW4gPGtldmluLnRpYW5AaW50ZWwuY29tPgorICogYW5kIFl1IEtl
IDxrZS55dUBpbnRlbC5jb20+LgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5IGl0CisgKiB1bmRlciB0aGUg
dGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLAor
ICogdmVyc2lvbiAyLCBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
bi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgaXQgd2ls
bCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0
aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IKKyAqIEZJVE5FU1MgRk9S
IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSBmb3IKKyAqIG1vcmUgZGV0YWlscy4KKyAqCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2NwdW1h
c2suaD4KKyNpbmNsdWRlIDxsaW51eC9jcHVmcmVxLmg+CisjaW5jbHVkZSA8bGludXgva2VybmVs
Lmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4K
KyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgorI2lu
Y2x1ZGUgPGFjcGkvYWNwaV9idXMuaD4KKyNpbmNsdWRlIDxhY3BpL2FjcGlfZHJpdmVycy5oPgor
I2luY2x1ZGUgPGFjcGkvcHJvY2Vzc29yLmg+CisKKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL3Bs
YXRmb3JtLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKworI2RlZmluZSBEUlZf
TkFNRSAieGVuLXByb2Nlc3Nvci10aHJ1IgorTU9EVUxFX0FVVEhPUigiS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPiIpOworTU9EVUxFX0RFU0NSSVBUSU9OKCJB
Q1BJIFBvd2VyIE1hbmFnZW1lbnQgZHJpdmVyIHRvIHBhc3MgQ3ggYW5kIFB4eCBkYXRhIHRvIFhl
biBoeXBlcnZpc29yIik7CitNT0RVTEVfTElDRU5TRSgiR1BMIik7CisKKworc3RhdGljIGludCBu
b19oeXBlcmNhbGw7CitNT0RVTEVfUEFSTV9ERVNDKG9mZiwgIkluaGliaXQgdGhlIGh5cGVyY2Fs
bC4iKTsKK21vZHVsZV9wYXJhbV9uYW1lZChvZmYsIG5vX2h5cGVyY2FsbCwgaW50LCAwNDAwKTsK
KworLyoKKyAqIE11dGV4IHRvIHByb3RlY3QgdGhlIGFjcGlfaWRzX2RvbmUuCisgKi8KK3N0YXRp
YyBERUZJTkVfTVVURVgoYWNwaV9pZHNfbXV0ZXgpOworLyoKKyAqIERvbid0IHRoaW5rIGNvbnZl
cnQgdGhpcyB0byBjcHVtYXNrX3Zhcl90IG9yIHVzZSBjcHVtYXNrX2JpdCAtIGFzIHRob3NlCisg
KiBzaHJpbmsgdG8gbnJfY3B1X2JpdHMgKHdoaWNoIGlzIGRlcGVuZGVudCBvbiBwb3NzaWJsZV9j
cHUpLCB3aGljaCBjYW4gYmUKKyAqIGxlc3MgdGhhbiB3aGF0IHdlIHdhbnQgdG8gcHV0IGluLgor
ICovCisjZGVmaW5lIE5SX0FDUElfQ1BVUwlOUl9DUFVTCisjZGVmaW5lIE1BWF9BQ1BJX0JJVFMJ
KEJJVFNfVE9fTE9OR1MoTlJfQUNQSV9DUFVTKSkKK3N0YXRpYyB1bnNpZ25lZCBsb25nICphY3Bp
X2lkc19kb25lOworLyoKKyAqIEFnYWluLCBkb24ndCBjb252ZXJ0IHRvIGNwdW1hc2sgLSBhcyB3
ZSBhcmUgcmVhZGluZyB0aGUgcmF3IEFDUEkgQ1BVIGlkcworICogd2hpY2ggY2FuIGdvIGJleW9u
ZCB3aGF0IHdlIHByZXNlbnRseSBzZWUuCisgKi8KK3N0YXRpYyB1bnNpZ25lZCBsb25nICphY3Bp
X2lkX3ByZXNlbnQ7CisKKworI2RlZmluZSBQT0xMX1RJTUVSCW1zZWNzX3RvX2ppZmZpZXMoNTAw
MCAvKiA1IHNlYyAqLykKK3N0YXRpYyBzdHJ1Y3QgdGFza19zdHJ1Y3QgKnhlbl9wcm9jZXNzb3Jf
dGhyZWFkOworCitzdGF0aWMgaW50IHhlbl9wdXNoX2N4eF90b19oeXBlcnZpc29yKHN0cnVjdCBh
Y3BpX3Byb2Nlc3NvciAqX3ByKQoreworCXN0cnVjdCB4ZW5fcGxhdGZvcm1fb3Agb3AgPSB7CisJ
CS5jbWQJCQk9IFhFTlBGX3NldF9wcm9jZXNzb3JfcG1pbmZvLAorCQkuaW50ZXJmYWNlX3ZlcnNp
b24JPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwkJLnUuc2V0X3BtaW5mby5pZAk9IF9wci0+
YWNwaV9pZCwKKwkJLnUuc2V0X3BtaW5mby50eXBlCT0gWEVOX1BNX0NYLAorCX07CisJc3RydWN0
IHhlbl9wcm9jZXNzb3JfY3ggKnhlbl9jeCwgKnhlbl9jeF9zdGF0ZXMgPSBOVUxMOworCXN0cnVj
dCBhY3BpX3Byb2Nlc3Nvcl9jeCAqY3g7CisJaW50IGksIG9rLCByZXQgPSAwOworCisJeGVuX2N4
X3N0YXRlcyA9IGtjYWxsb2MoX3ByLT5wb3dlci5jb3VudCwKKwkJCQlzaXplb2Yoc3RydWN0IHhl
bl9wcm9jZXNzb3JfY3gpLCBHRlBfS0VSTkVMKTsKKwlpZiAoIXhlbl9jeF9zdGF0ZXMpCisJCXJl
dHVybiAtRU5PTUVNOworCisJZm9yIChvayA9IDAsIGkgPSAxOyBpIDw9IF9wci0+cG93ZXIuY291
bnQ7IGkrKykgeworCQljeCA9ICZfcHItPnBvd2VyLnN0YXRlc1tpXTsKKwkJaWYgKCFjeC0+dmFs
aWQpCisJCQljb250aW51ZTsKKworCQl4ZW5fY3ggPSAmKHhlbl9jeF9zdGF0ZXNbb2srK10pOwor
CisJCXhlbl9jeC0+cmVnLnNwYWNlX2lkID0gQUNQSV9BRFJfU1BBQ0VfU1lTVEVNX0lPOworCQlp
ZiAoY3gtPmVudHJ5X21ldGhvZCA9PSBBQ1BJX0NTVEFURV9TWVNURU1JTykgeworCQkJeGVuX2N4
LT5yZWcuYml0X3dpZHRoID0gODsKKwkJCXhlbl9jeC0+cmVnLmJpdF9vZmZzZXQgPSAwOworCQkJ
eGVuX2N4LT5yZWcuYWNjZXNzX3NpemUgPSAxOworCQl9IGVsc2UgeworCQkJeGVuX2N4LT5yZWcu
c3BhY2VfaWQgPSBBQ1BJX0FEUl9TUEFDRV9GSVhFRF9IQVJEV0FSRTsKKwkJCWlmIChjeC0+ZW50
cnlfbWV0aG9kID09IEFDUElfQ1NUQVRFX0ZGSCkgeworCQkJCS8qIE5BVElWRV9DU1RBVEVfQkVZ
T05EX0hBTFQgKi8KKwkJCQl4ZW5fY3gtPnJlZy5iaXRfb2Zmc2V0ID0gMjsKKwkJCQl4ZW5fY3gt
PnJlZy5iaXRfd2lkdGggPSAxOyAvKiBWRU5ET1JfSU5URUwgKi8KKwkJCX0KKwkJCXhlbl9jeC0+
cmVnLmFjY2Vzc19zaXplID0gMDsKKwkJfQorCQl4ZW5fY3gtPnJlZy5hZGRyZXNzID0gY3gtPmFk
ZHJlc3M7CisKKwkJeGVuX2N4LT50eXBlID0gY3gtPnR5cGU7CisJCXhlbl9jeC0+bGF0ZW5jeSA9
IGN4LT5sYXRlbmN5OworCQl4ZW5fY3gtPnBvd2VyID0gY3gtPnBvd2VyOworCisJCXhlbl9jeC0+
ZHBjbnQgPSAwOworCQlzZXRfeGVuX2d1ZXN0X2hhbmRsZSh4ZW5fY3gtPmRwLCBOVUxMKTsKKyNp
ZmRlZiBERUJVRworCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiBDWDogSUQ6JWQgW0MlZDolc10gZW50
cnk6JWRcbiIsIF9wci0+YWNwaV9pZCwKKwkJCSBjeC0+dHlwZSwgY3gtPmRlc2MsIGN4LT5lbnRy
eV9tZXRob2QpOworI2VuZGlmCisJfQorCWlmICghb2spIHsKKwkJcHJfZXJyKERSVl9OQU1FICI6
IE5vIGF2YWlsYWJsZSBDeCBpbmZvIGZvciBjcHUgJWRcbiIsIF9wci0+YWNwaV9pZCk7CisJCWtm
cmVlKHhlbl9jeF9zdGF0ZXMpOworCQlyZXR1cm4gLUVJTlZBTDsKKwl9CisJb3AudS5zZXRfcG1p
bmZvLnBvd2VyLmNvdW50ID0gb2s7CisJb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZsYWdzLmJtX2Nv
bnRyb2wgPSBfcHItPmZsYWdzLmJtX2NvbnRyb2w7CisJb3AudS5zZXRfcG1pbmZvLnBvd2VyLmZs
YWdzLmJtX2NoZWNrID0gX3ByLT5mbGFncy5ibV9jaGVjazsKKwlvcC51LnNldF9wbWluZm8ucG93
ZXIuZmxhZ3MuaGFzX2NzdCA9IF9wci0+ZmxhZ3MuaGFzX2NzdDsKKwlvcC51LnNldF9wbWluZm8u
cG93ZXIuZmxhZ3MucG93ZXJfc2V0dXBfZG9uZSA9CisJCV9wci0+ZmxhZ3MucG93ZXJfc2V0dXBf
ZG9uZTsKKworCXNldF94ZW5fZ3Vlc3RfaGFuZGxlKG9wLnUuc2V0X3BtaW5mby5wb3dlci5zdGF0
ZXMsIHhlbl9jeF9zdGF0ZXMpOworCisJaWYgKCFub19oeXBlcmNhbGwpCisJCXJldCA9IEhZUEVS
VklTT1JfZG9tMF9vcCgmb3ApOworCisJaWYgKHJldCkKKwkJcHJfZXJyKERSVl9OQU1FICIoQ1gp
OiBIeXBlcnZpc29yIHJldHVybmVkICglZCkgZm9yIEFDUEkgSUQ6ICVkXG4iLAorCQkgICAgICAg
cmV0LCBfcHItPmFjcGlfaWQpOworCisJa2ZyZWUoeGVuX2N4X3N0YXRlcyk7CisKKwlyZXR1cm4g
cmV0OworfQorc3RhdGljIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3B4ICp4ZW5fY29weV9wc3NfZGF0
YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wciwKKwkJCQkJCSAgc3RydWN0IHhlbl9wcm9jZXNz
b3JfcGVyZm9ybWFuY2UgKnhlbl9wZXJmKQoreworCXN0cnVjdCB4ZW5fcHJvY2Vzc29yX3B4ICp4
ZW5fc3RhdGVzID0gTlVMTDsKKwlpbnQgaTsKKworCUJVSUxEX0JVR19PTihzaXplb2Yoc3RydWN0
IHhlbl9wcm9jZXNzb3JfcHgpICE9CisJCSAgICAgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
cl9weCkpOworCisJeGVuX3N0YXRlcyA9IGtjYWxsb2MoX3ByLT5wZXJmb3JtYW5jZS0+c3RhdGVf
Y291bnQsCisJCQkgICAgIHNpemVvZihzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9weCksIEdGUF9LRVJO
RUwpOworCWlmICgheGVuX3N0YXRlcykKKwkJcmV0dXJuIEVSUl9QVFIoLUVOT01FTSk7CisKKwl4
ZW5fcGVyZi0+c3RhdGVfY291bnQgPSBfcHItPnBlcmZvcm1hbmNlLT5zdGF0ZV9jb3VudDsKKwlm
b3IgKGkgPSAwOyBpIDwgX3ByLT5wZXJmb3JtYW5jZS0+c3RhdGVfY291bnQ7IGkrKykgeworCQkv
KiBGb3J0dW5hdGx5IGZvciB1cywgdGhleSBhcmUgYm90aCB0aGUgc2FtZSBzaXplICovCisJCW1l
bWNweSgmKHhlbl9zdGF0ZXNbaV0pLCAmKF9wci0+cGVyZm9ybWFuY2UtPnN0YXRlc1tpXSksCisJ
CSAgICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHJvY2Vzc29yX3B4KSk7CisJfQorCXJldHVybiB4
ZW5fc3RhdGVzOworfQorc3RhdGljIGludCB4ZW5fY29weV9wc2RfZGF0YShzdHJ1Y3QgYWNwaV9w
cm9jZXNzb3IgKl9wciwKKwkJCSAgICAgc3RydWN0IHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2Ug
Knhlbl9wZXJmKQoreworCUJVSUxEX0JVR19PTihzaXplb2Yoc3RydWN0IHhlbl9wc2RfcGFja2Fn
ZSkgIT0KKwkJICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHNkX3BhY2thZ2UpKTsKKworCWlmIChf
cHItPnBlcmZvcm1hbmNlLT5zaGFyZWRfdHlwZSAhPSBDUFVGUkVRX1NIQVJFRF9UWVBFX05PTkUp
IHsKKwkJeGVuX3BlcmYtPnNoYXJlZF90eXBlID0gX3ByLT5wZXJmb3JtYW5jZS0+c2hhcmVkX3R5
cGU7CisKKwkJbWVtY3B5KCYoeGVuX3BlcmYtPmRvbWFpbl9pbmZvKSwgJihfcHItPnBlcmZvcm1h
bmNlLT5kb21haW5faW5mbyksCisJCSAgICAgICBzaXplb2Yoc3RydWN0IGFjcGlfcHNkX3BhY2th
Z2UpKTsKKwl9IGVsc2UgeworCQlpZiAoKCZjcHVfZGF0YSgwKSktPng4Nl92ZW5kb3IgIT0gWDg2
X1ZFTkRPUl9BTUQpCisJCQlyZXR1cm4gLUVJTlZBTDsKKworCQkvKiBPbiBBTUQsIHRoZSBwb3dl
cm5vdy1rOCBpcyBsb2FkZWQgYmVmb3JlIGFjcGlfY3B1ZnJlcQorCQkgKiBtZWFuaW5nIHRoYXQg
YWNwaV9wcm9jZXNzb3JfcHJlcmVnaXN0ZXJfcGVyZm9ybWFuY2UgbmV2ZXIKKwkJICogZ2V0cyBj
YWxsZWQgd2hpY2ggd291bGQgcGFyc2UgdGhlIF9QU0QuIFRoZSBvbmx5IHJlbGV2YW50CisJCSAq
IGluZm9ybWF0aW9uIGZyb20gX1BTRCB3ZSBuZWVkIGlzIHdoZXRoZXIgaXQgaXMgSFdfQUxMIG9y
IGFueQorCQkgKiBvdGhlciB0eXBlLiBBTUQgSzggPj0gYXJlIFNXX0FMTCBvciBTV19BTlksIEFN
RCBLNzw9IEhXX0FOWS4KKwkJICogVGhpcyBkcml2ZXIgY2hlY2tzIGF0IHRoZSBzdGFydCB3aGV0
aGVyIGl0IGlzIEs4IHNvIGl0CisJCSAqIGlmIHdlIGdldCBoZXJlIGl0IGNhbiBvbmx5IGJlIEs4
LgorCQkgKi8KKwkJeGVuX3BlcmYtPnNoYXJlZF90eXBlID0gQ1BVRlJFUV9TSEFSRURfVFlQRV9B
Tlk7CisJCXhlbl9wZXJmLT5kb21haW5faW5mby5jb29yZF90eXBlID0gRE9NQUlOX0NPT1JEX1RZ
UEVfU1dfQU5ZOworCQl4ZW5fcGVyZi0+ZG9tYWluX2luZm8ubnVtX3Byb2Nlc3NvcnMgPSBudW1f
b25saW5lX2NwdXMoKTsKKwl9CisJcmV0dXJuIDA7Cit9CitzdGF0aWMgaW50IHhlbl9jb3B5X3Bj
dF9kYXRhKHN0cnVjdCBhY3BpX3BjdF9yZWdpc3RlciAqcGN0LAorCQkJICAgICBzdHJ1Y3QgeGVu
X3BjdF9yZWdpc3RlciAqX3BjdCkKK3sKKwkvKiBJdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3Vs
ZCBqdXN0IGRvICdtZW1jcHkocGN0LCBfcGN0JykgYnV0CisJICogc2FkbHkgdGhlIFhlbiBzdHJ1
Y3R1cmUgZGlkIG5vdCBoYXZlIHRoZSBwcm9wZXIgcGFkZGluZworCSAqIHNvIHRoZSBkZXNjcmlw
dG9yIGZpZWxkIHRha2VzIHR3byAoX3BjdCkgYnl0ZXMgaW5zdGVhZCBvZiBvbmUgKHBjdCkuCisJ
ICovCisJX3BjdC0+ZGVzY3JpcHRvciA9IHBjdC0+ZGVzY3JpcHRvcjsKKwlfcGN0LT5sZW5ndGgg
PSBwY3QtPmxlbmd0aDsKKwlfcGN0LT5zcGFjZV9pZCA9IHBjdC0+c3BhY2VfaWQ7CisJX3BjdC0+
Yml0X3dpZHRoID0gcGN0LT5iaXRfd2lkdGg7CisJX3BjdC0+Yml0X29mZnNldCA9IHBjdC0+Yml0
X29mZnNldDsKKwlfcGN0LT5yZXNlcnZlZCA9IHBjdC0+cmVzZXJ2ZWQ7CisJX3BjdC0+YWRkcmVz
cyA9IHBjdC0+YWRkcmVzczsKKwlyZXR1cm4gMDsKK30KK3N0YXRpYyBpbnQgeGVuX3B1c2hfcHh4
X3RvX2h5cGVydmlzb3Ioc3RydWN0IGFjcGlfcHJvY2Vzc29yICpfcHIpCit7CisJaW50IHJldCA9
IDA7CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZAkJCT0gWEVOUEZfc2V0
X3Byb2Nlc3Nvcl9wbWluZm8sCisJCS5pbnRlcmZhY2VfdmVyc2lvbgk9IFhFTlBGX0lOVEVSRkFD
RV9WRVJTSU9OLAorCQkudS5zZXRfcG1pbmZvLmlkCT0gX3ByLT5hY3BpX2lkLAorCQkudS5zZXRf
cG1pbmZvLnR5cGUJPSBYRU5fUE1fUFgsCisJfTsKKwlzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9wZXJm
b3JtYW5jZSAqeGVuX3BlcmY7CisJc3RydWN0IHhlbl9wcm9jZXNzb3JfcHggKnhlbl9zdGF0ZXMg
PSBOVUxMOworCisJeGVuX3BlcmYgPSAmb3AudS5zZXRfcG1pbmZvLnBlcmY7CisKKwl4ZW5fcGVy
Zi0+cGxhdGZvcm1fbGltaXQgPSBfcHItPnBlcmZvcm1hbmNlX3BsYXRmb3JtX2xpbWl0OworCXhl
bl9wZXJmLT5mbGFncyB8PSBYRU5fUFhfUFBDOworCXhlbl9jb3B5X3BjdF9kYXRhKCYoX3ByLT5w
ZXJmb3JtYW5jZS0+Y29udHJvbF9yZWdpc3RlciksCisJCQkgICZ4ZW5fcGVyZi0+Y29udHJvbF9y
ZWdpc3Rlcik7CisJeGVuX2NvcHlfcGN0X2RhdGEoJihfcHItPnBlcmZvcm1hbmNlLT5zdGF0dXNf
cmVnaXN0ZXIpLAorCQkJICAmeGVuX3BlcmYtPnN0YXR1c19yZWdpc3Rlcik7CisJeGVuX3BlcmYt
PmZsYWdzIHw9IFhFTl9QWF9QQ1Q7CisJeGVuX3N0YXRlcyA9IHhlbl9jb3B5X3Bzc19kYXRhKF9w
ciwgeGVuX3BlcmYpOworCWlmICghSVNfRVJSX09SX05VTEwoeGVuX3N0YXRlcykpIHsKKwkJc2V0
X3hlbl9ndWVzdF9oYW5kbGUoeGVuX3BlcmYtPnN0YXRlcywgeGVuX3N0YXRlcyk7CisJCXhlbl9w
ZXJmLT5mbGFncyB8PSBYRU5fUFhfUFNTOworCX0KKwlpZiAoIXhlbl9jb3B5X3BzZF9kYXRhKF9w
ciwgeGVuX3BlcmYpKQorCQl4ZW5fcGVyZi0+ZmxhZ3MgfD0gWEVOX1BYX1BTRDsKKworCWlmICgh
bm9faHlwZXJjYWxsKQorCQlyZXQgPSBIWVBFUlZJU09SX2RvbTBfb3AoJm9wKTsKKworCWlmIChy
ZXQpCisJCXByX2VycihEUlZfTkFNRSAiKF9QWFgpOiBIeXBlcnZpc29yIHJldHVybmVkICglZCkg
Zm9yIEFDUEkgSUQgJWRcbiIsCisJCSAgICAgICByZXQsIF9wci0+YWNwaV9pZCk7CisKKwlpZiAo
IUlTX0VSUl9PUl9OVUxMKHhlbl9zdGF0ZXMpKQorCQlrZnJlZSh4ZW5fc3RhdGVzKTsKKworCXJl
dHVybiByZXQ7Cit9CisvKgorICogV2UgcmVhZCBvdXQgdGhlIHN0cnVjdCBhY3BpX3Byb2Nlc3Nv
ciwgYW5kIHNlcmlhbGl6ZSBhY2Nlc3MKKyAqIHNvIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgY2Fs
bGVyLiBUaGlzIGlzIHNvIHRoYXQgd2Ugd29uJ3QKKyAqIHJhY2Ugd2l0aCB0aGUgQ1BVIGhvdHBs
dWcgY29kZSAoeGVuX2NwdV9zb2Z0X25vdGlmeSkuCisgKi8KK3N0YXRpYyBpbnQgeGVuX3Byb2Nl
c3NfZGF0YShzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKl9wcikKK3sKKwlpbnQgZXJyID0gMDsKKwor
CW11dGV4X2xvY2soJmFjcGlfaWRzX211dGV4KTsKKwlpZiAoX190ZXN0X2FuZF9zZXRfYml0KF9w
ci0+YWNwaV9pZCwgYWNwaV9pZHNfZG9uZSkpIHsKKwkJbXV0ZXhfdW5sb2NrKCZhY3BpX2lkc19t
dXRleCk7CisJCXJldHVybiAtRUJVU1k7CisJfQorCWlmIChfcHItPmZsYWdzLnBvd2VyKQorCQll
cnIgPSB4ZW5fcHVzaF9jeHhfdG9faHlwZXJ2aXNvcihfcHIpOworCisJaWYgKF9wci0+cGVyZm9y
bWFuY2UgJiYgX3ByLT5wZXJmb3JtYW5jZS0+c3RhdGVzKQorCQllcnIgfD0geGVuX3B1c2hfcHh4
X3RvX2h5cGVydmlzb3IoX3ByKTsKKworCW11dGV4X3VubG9jaygmYWNwaV9pZHNfbXV0ZXgpOwor
CXJldHVybiBlcnI7Cit9CitzdGF0aWMgYWNwaV9zdGF0dXMKK3hlbl9yZWFkX2FjcGlfaWQoYWNw
aV9oYW5kbGUgaGFuZGxlLCB1MzIgbHZsLCB2b2lkICpjb250ZXh0LCB2b2lkICoqcnYpCit7CisJ
dTMyIGFjcGlfaWQ7CisJYWNwaV9zdGF0dXMgc3RhdHVzOworCWFjcGlfb2JqZWN0X3R5cGUgYWNw
aV90eXBlOworCXVuc2lnbmVkIGxvbmcgbG9uZyB0bXA7CisJdW5pb24gYWNwaV9vYmplY3Qgb2Jq
ZWN0ID0geyAwIH07CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1ZmZlciA9IHsgc2l6ZW9mKHVuaW9u
IGFjcGlfb2JqZWN0KSwgJm9iamVjdCB9OworCisJc3RhdHVzID0gYWNwaV9nZXRfdHlwZShoYW5k
bGUsICZhY3BpX3R5cGUpOworCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJcmV0dXJuIEFF
X09LOworCisJc3dpdGNoIChhY3BpX3R5cGUpIHsKKwljYXNlIEFDUElfVFlQRV9QUk9DRVNTT1I6
CisJCXN0YXR1cyA9IGFjcGlfZXZhbHVhdGVfb2JqZWN0KGhhbmRsZSwgTlVMTCwgTlVMTCwgJmJ1
ZmZlcik7CisJCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJCXJldHVybiBBRV9PSzsKKwkJ
YWNwaV9pZCA9IG9iamVjdC5wcm9jZXNzb3IucHJvY19pZDsKKwkJYnJlYWs7CisJY2FzZSBBQ1BJ
X1RZUEVfREVWSUNFOgorCQlzdGF0dXMgPSBhY3BpX2V2YWx1YXRlX2ludGVnZXIoaGFuZGxlLCAi
X1VJRCIsIE5VTEwsICZ0bXApOworCQlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpCisJCQlyZXR1
cm4gQUVfT0s7CisJCWFjcGlfaWQgPSB0bXA7CisJCWJyZWFrOworCWRlZmF1bHQ6CisJCXJldHVy
biBBRV9PSzsKKwl9CisJaWYgKGFjcGlfaWQgPiBOUl9BQ1BJX0NQVVMpIHsKKwkJV0FSTl9PTkNF
KDEsICJUaGVyZSBhcmUgJWQgQUNQSSBwcm9jZXNzb3JzLCBidXQga2VybmVsIGNhbiBvbmx5IGRv
ICVkIVxuIiwKKwkJICAgICBhY3BpX2lkLCBOUl9BQ1BJX0NQVVMpOworCQlyZXR1cm4gQUVfT0s7
CisJfQorCV9fc2V0X2JpdChhY3BpX2lkLCBhY3BpX2lkX3ByZXNlbnQpOworCisJcmV0dXJuIEFF
X09LOworfQorc3RhdGljIHVuc2lnbmVkIGludCB4ZW5fYWNwaV9pZHNfbW9yZSh2b2lkKQorewor
CXVuc2lnbmVkIGludCBuID0gMDsKKworCWFjcGlfd2Fsa19uYW1lc3BhY2UoQUNQSV9UWVBFX1BS
T0NFU1NPUiwgQUNQSV9ST09UX09CSkVDVCwKKwkJCSAgICBBQ1BJX1VJTlQzMl9NQVgsCisJCQkg
ICAgeGVuX3JlYWRfYWNwaV9pZCwgTlVMTCwgTlVMTCwgTlVMTCk7CisJYWNwaV9nZXRfZGV2aWNl
cygiQUNQSTAwMDciLCB4ZW5fcmVhZF9hY3BpX2lkLCBOVUxMLCBOVUxMKTsKKworCW11dGV4X2xv
Y2soJmFjcGlfaWRzX211dGV4KTsKKwlpZiAoIWJpdG1hcF9lcXVhbChhY3BpX2lkX3ByZXNlbnQs
IGFjcGlfaWRzX2RvbmUsIE1BWF9BQ1BJX0JJVFMpKQorCQluID0gYml0bWFwX3dlaWdodChhY3Bp
X2lkX3ByZXNlbnQsIE1BWF9BQ1BJX0JJVFMpOworCW11dGV4X3VubG9jaygmYWNwaV9pZHNfbXV0
ZXgpOworCisJcmV0dXJuIG47Cit9CisKK3N0YXRpYyBpbnQgeGVuX3Byb2Nlc3Nvcl9jaGVjayh2
b2lkKQoreworCXN0cnVjdCBjcHVmcmVxX3BvbGljeSAqcG9saWN5OworCXN0cnVjdCBhY3BpX3By
b2Nlc3NvciAqcHJfYmFja3VwID0gTlVMTDsKKwlpbnQgY3B1LCBlcnIgPSAwOworCisJY3B1ID0g
Z2V0X2NwdSgpOworCXB1dF9jcHUoKTsKKwlwb2xpY3kgPSBjcHVmcmVxX2NwdV9nZXQoY3B1KTsK
KwlpZiAoIXBvbGljeSkKKwkJcmV0dXJuIC1FQlVTWTsKKworCWdldF9vbmxpbmVfY3B1cygpOwor
CWZvcl9lYWNoX29ubGluZV9jcHUoY3B1KSB7CisJCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3By
OworCisJCV9wciA9IHBlcl9jcHUocHJvY2Vzc29ycywgY3B1IC8qIEFQSUMgSUQgKi8pOworCQlp
ZiAoIV9wcikKKwkJCWNvbnRpbnVlOworCisJCWlmICghcHJfYmFja3VwKSB7CisJCQlwcl9iYWNr
dXAgPSBremFsbG9jKHNpemVvZihzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IpLCBHRlBfS0VSTkVMKTsK
KwkJCW1lbWNweShwcl9iYWNrdXAsIF9wciwgc2l6ZW9mKHN0cnVjdCBhY3BpX3Byb2Nlc3Nvcikp
OworCQl9CisJCSh2b2lkKXhlbl9wcm9jZXNzX2RhdGEoX3ByKTsKKwl9CisJcHV0X29ubGluZV9j
cHVzKCk7CisKKwljcHVmcmVxX2NwdV9wdXQocG9saWN5KTsKKworCS8qIEFsbCBvbmxpbmUgQ1BV
cyBoYXZlIGJlZW4gcHJvY2Vzc2VkIGF0IHRoaXMgc3RhZ2UuIE5vdyB2ZXJpZnkKKwkgKiB3aGV0
aGVyIGluIGZhY3QgIm9ubGluZSBDUFVzIiA9PSBwaHlzaWNhbCBDUFVzLgorCSAqLworCWFjcGlf
aWRfcHJlc2VudCA9IGtjYWxsb2MoTUFYX0FDUElfQklUUywgc2l6ZW9mKHVuc2lnbmVkIGxvbmcp
LCBHRlBfS0VSTkVMKTsKKwlpZiAoIWFjcGlfaWRfcHJlc2VudCkgeworCQllcnIgPSAtRU5PTUVN
OworCQlnb3RvIGVycl9vdXQ7CisJfQorCW1lbXNldChhY3BpX2lkX3ByZXNlbnQsIDAsIE1BWF9B
Q1BJX0JJVFMgKiBzaXplb2YodW5zaWduZWQgbG9uZykpOworCisJaWYgKHhlbl9hY3BpX2lkc19t
b3JlKCkgJiYgcHJfYmFja3VwKSB7CisJCWZvcl9lYWNoX3NldF9iaXQoY3B1LCBhY3BpX2lkX3By
ZXNlbnQsIE1BWF9BQ1BJX0JJVFMpIHsKKwkJCXByX2JhY2t1cC0+YWNwaV9pZCA9IGNwdTsKKwkJ
CS8qIFdlIHdpbGwgZ2V0IC1FQlVTWSBpZiBpdCBoYXMgYmVlbiBwcm9ncmFtbWVkIGFscmVhZHku
ICovCisJCQkodm9pZCl4ZW5fcHJvY2Vzc19kYXRhKHByX2JhY2t1cCk7CisJCX0KKwl9CisJa2Zy
ZWUoYWNwaV9pZF9wcmVzZW50KTsKKwlhY3BpX2lkX3ByZXNlbnQgPSBOVUxMOworZXJyX291dDoK
KwlrZnJlZShwcl9iYWNrdXApOworCXByX2JhY2t1cCA9IE5VTEw7CisJcmV0dXJuIGVycjsKK30K
Ky8qCisgKiBUaGUgcHVycG9zZSBvZiB0aGlzIHRpbWVyL3RocmVhZCBpcyB0byB3YWl0IGZvciB0
aGUgQUNQSSBwcm9jZXNzb3IKKyAqIGFuZCBDUFVmcmVxIGRyaXZlcnMgdG8gbG9hZCB1cCBhbmQg
cGFyc2UgdGhlIFB4eCBhbmQgQ3h4IGluZm9ybWF0aW9uCisgKiBiZWZvcmUgd2UgYXR0ZW1wdCB0
byByZWFkIGl0LgorICovCitzdGF0aWMgdm9pZCB4ZW5fcHJvY2Vzc29yX3RpbWVvdXQodW5zaWdu
ZWQgbG9uZyBhcmcpCit7CisJd2FrZV91cF9wcm9jZXNzKChzdHJ1Y3QgdGFza19zdHJ1Y3QgKilh
cmcpOworfQorc3RhdGljIGludCB4ZW5fcHJvY2Vzc29yX3RocmVhZF9mdW5jKHZvaWQgKmR1bW15
KQoreworCXN0cnVjdCB0aW1lcl9saXN0IHRpbWVyOworCWludCBlcnIgPSAwOworCisJc2V0dXBf
ZGVmZXJyYWJsZV90aW1lcl9vbl9zdGFjaygmdGltZXIsIHhlbl9wcm9jZXNzb3JfdGltZW91dCwK
KwkJCQkJKHVuc2lnbmVkIGxvbmcpY3VycmVudCk7CisJZG8geworCQlfX3NldF9jdXJyZW50X3N0
YXRlKFRBU0tfSU5URVJSVVBUSUJMRSk7CisJCW1vZF90aW1lcigmdGltZXIsIGppZmZpZXMgKyBQ
T0xMX1RJTUVSKTsKKwkJc2NoZWR1bGUoKTsKKwkJZXJyID0geGVuX3Byb2Nlc3Nvcl9jaGVjaygp
OworCQlpZiAoZXJyICE9IC1FQlVTWSkKKwkJCWJyZWFrOworCX0gd2hpbGUgKCFrdGhyZWFkX3No
b3VsZF9zdG9wKCkpOworCisJaWYgKGVycikKKwkJcHJfZXJyKERSVl9OQU1FICI6IEZhaWxlZCB0
byB1cGxvYWQgZGF0YSAoJWQpIVxuIiwgZXJyKTsKKwlkZWxfdGltZXJfc3luYygmdGltZXIpOwor
CWRlc3Ryb3lfdGltZXJfb25fc3RhY2soJnRpbWVyKTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGlj
IGludCB4ZW5fY3B1X3NvZnRfbm90aWZ5KHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmZiLAorCQkJ
ICAgICAgIHVuc2lnbmVkIGxvbmcgYWN0aW9uLCB2b2lkICpoY3B1KQoreworCXVuc2lnbmVkIGlu
dCBjcHUgPSAodW5zaWduZWQgbG9uZyloY3B1OworCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqX3By
ID0gcGVyX2NwdShwcm9jZXNzb3JzLCBjcHUpOworCisJaWYgKGFjdGlvbiA9PSBDUFVfT05MSU5F
ICYmIF9wcikKKwkJKHZvaWQpeGVuX3Byb2Nlc3NfZGF0YShfcHIpOworCisJcmV0dXJuIE5PVElG
WV9PSzsKK30KKworc3RhdGljIHN0cnVjdCBub3RpZmllcl9ibG9jayB4ZW5fY3B1X25vdGlmaWVy
ID0geworCS5ub3RpZmllcl9jYWxsID0geGVuX2NwdV9zb2Z0X25vdGlmeSwKKwkucHJpb3JpdHkg
PSAtMSwgLyogQmUgdGhlIGxhc3Qgb25lICovCit9OworCitzdGF0aWMgaW50IF9faW5pdCBjaGVj
a19wcmVyZXEodm9pZCkKK3sKKwlzdHJ1Y3QgY3B1aW5mb194ODYgKmMgPSAmY3B1X2RhdGEoMCk7
CisKKwlpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCWlm
ICghYWNwaV9nYmxfRkFEVC5zbWlfY29tbWFuZCkKKwkJcmV0dXJuIC1FTk9ERVY7CisKKwlpZiAo
Yy0+eDg2X3ZlbmRvciA9PSBYODZfVkVORE9SX0lOVEVMKSB7CisJCWlmICghY3B1X2hhcyhjLCBY
ODZfRkVBVFVSRV9FU1QpKQorCQkJcmV0dXJuIC1FTk9ERVY7CisKKwkJcmV0dXJuIDA7CisJfQor
CWlmIChjLT54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfQU1EKSB7CisJCXUzMiBoaSA9IDAsIGxv
ID0gMDsKKwkJLyogQ29waWVkIGZyb20gcG93ZXJub3ctazguaCwgY2FuJ3QgaW5jbHVkZSAuLi9j
cHVmcmVxL3Bvd2Vybm93CisJCSAqIGFzIHdlIGdldCBjb21waWxlIHdhcm5pbmdzIGZvciB0aGUg
c3RhdGljIGZ1bmN0aW9ucy4KKwkJICovCisjZGVmaW5lIE1TUl9QU1RBVEVfQ1VSX0xJTUlUICAg
IDB4YzAwMTAwNjEgLyogcHN0YXRlIGN1cnJlbnQgbGltaXQgTVNSICovCisJCXJkbXNyKE1TUl9Q
U1RBVEVfQ1VSX0xJTUlULCBsbywgaGkpOworCisJCS8qIElmIHRoZSBNU1IgY2Fubm90IHByb3Zp
ZGUgdGhlIGRhdGEsIHRoZSBwb3dlcm5vdy1rOAorCQkgKiB3b24ndCBwcm9jZXNzIHRoZSBkYXRh
IHByb3Blcmx5IGVpdGhlci4KKwkJICovCisJCWlmIChoaSB8fCBsbykKKwkJCXJldHVybiAwOwor
CX0KKwlyZXR1cm4gLUVOT0RFVjsKK30KKworc3RhdGljIGludCBfX2luaXQgeGVuX3Byb2Nlc3Nv
cl9wYXNzdGhydV9pbml0KHZvaWQpCit7CisJaW50IHJjID0gY2hlY2tfcHJlcmVxKCk7CisKKwlp
ZiAocmMpCisJCXJldHVybiByYzsKKworCWFjcGlfaWRzX2RvbmUgPSBrY2FsbG9jKE1BWF9BQ1BJ
X0JJVFMsIHNpemVvZih1bnNpZ25lZCBsb25nKSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFhY3BpX2lk
c19kb25lKQorCQlyZXR1cm4gLUVOT01FTTsKKwltZW1zZXQoYWNwaV9pZHNfZG9uZSwgMCwgTUFY
X0FDUElfQklUUyAqIHNpemVvZih1bnNpZ25lZCBsb25nKSk7CisJeGVuX3Byb2Nlc3Nvcl90aHJl
YWQgPSBrdGhyZWFkX3J1bih4ZW5fcHJvY2Vzc29yX3RocmVhZF9mdW5jLCBOVUxMLCBEUlZfTkFN
RSk7CisJaWYgKElTX0VSUih4ZW5fcHJvY2Vzc29yX3RocmVhZCkpIHsKKwkJcHJfZXJyKERSVl9O
QU1FICI6IEZhaWxlZCB0byBjcmVhdGUgdGhyZWFkLiBBYm9ydGluZy5cbiIpOworCQlyZXR1cm4g
LUVOT01FTTsKKwl9CisJcmVnaXN0ZXJfaG90Y3B1X25vdGlmaWVyKCZ4ZW5fY3B1X25vdGlmaWVy
KTsKKwlyZXR1cm4gMDsKK30KK3N0YXRpYyB2b2lkIF9fZXhpdCB4ZW5fcHJvY2Vzc29yX3Bhc3N0
aHJ1X2V4aXQodm9pZCkKK3sKKwl1bnJlZ2lzdGVyX2hvdGNwdV9ub3RpZmllcigmeGVuX2NwdV9u
b3RpZmllcik7CisJaWYgKHhlbl9wcm9jZXNzb3JfdGhyZWFkKQorCQlrdGhyZWFkX3N0b3AoeGVu
X3Byb2Nlc3Nvcl90aHJlYWQpOworCWtmcmVlKGFjcGlfaWRzX2RvbmUpOworfQorbGF0ZV9pbml0
Y2FsbCh4ZW5fcHJvY2Vzc29yX3Bhc3N0aHJ1X2luaXQpOworbW9kdWxlX2V4aXQoeGVuX3Byb2Nl
c3Nvcl9wYXNzdGhydV9leGl0KTsKLS0gCjEuNy45LjQ4Lmc4NWRhNGQKCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFY-0000Wt-9g; Thu, 23 Feb 2012 22:34: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 1S0hFX-0000Wn-A7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:34:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330036434!58026339!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19097 invoked from network); 23 Feb 2012 22:33:55 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 22:33:55 -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 q1NMYmus007846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:48 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
	q1NMYlFu024722
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 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
	q1NMYkvK010779; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A33F041727; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:08 -0500
Message-Id: <1330036270-20015-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F46BF09.00A0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/3] xen/setup/pm/acpi: Remove the call to
	boot_option_idle_override.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 needed that call in the past to force the kernel to use
default_idle (which called safe_halt, which called xen_safe_halt).

But set_pm_idle_to_default() does now that, so there is no need
to use this boot option operand.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e03c636..1236623 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -420,7 +420,6 @@ void __init xen_arch_setup(void)
 	boot_cpu_data.hlt_works_ok = 1;
 #endif
 	disable_cpuidle();
-	boot_option_idle_override = IDLE_HALT;
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22: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 1S0hFY-0000Wt-9g; Thu, 23 Feb 2012 22:34: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 1S0hFX-0000Wn-A7
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:34:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330036434!58026339!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19097 invoked from network); 23 Feb 2012 22:33:55 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2012 22:33:55 -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 q1NMYmus007846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 23 Feb 2012 22:34:48 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
	q1NMYlFu024722
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 23 Feb 2012 22:34:47 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
	q1NMYkvK010779; Thu, 23 Feb 2012 16:34:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 14:34:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A33F041727; Thu, 23 Feb 2012 17:31:25 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, JBeulich@novell.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org
Date: Thu, 23 Feb 2012 17:31:08 -0500
Message-Id: <1330036270-20015-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F46BF09.00A0,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/3] xen/setup/pm/acpi: Remove the call to
	boot_option_idle_override.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 needed that call in the past to force the kernel to use
default_idle (which called safe_halt, which called xen_safe_halt).

But set_pm_idle_to_default() does now that, so there is no need
to use this boot option operand.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e03c636..1236623 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -420,7 +420,6 @@ void __init xen_arch_setup(void)
 	boot_cpu_data.hlt_works_ok = 1;
 #endif
 	disable_cpuidle();
-	boot_option_idle_override = IDLE_HALT;
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.9.48.g85da4d


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:41:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0hLy-00016o-Gk; Thu, 23 Feb 2012 22:41:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S0hLx-00016S-1Y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:41:33 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330036884!12817790!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27991 invoked from network); 23 Feb 2012 22:41:26 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 22:41:26 -0000
Received: from perrybergman.sldomain.com (207-225-98-3.dia.static.qwest.net
	[207.225.98.3]) (authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1NMfIMV048147
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 23 Feb 2012 15:41:19 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120223185052.GB22922@phenom.dumpdata.com>
Date: Thu, 23 Feb 2012 15:41:15 -0700
Message-Id: <F771C692-9648-47BB-9D53-B600968FC803@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
	<20120221213623.GB28154@phenom.dumpdata.com>
	<1329909271.2880.32.camel@zakaz.uk.xensource.com>
	<20120223185052.GB22922@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Thu, 23 Feb 2012 15:41:19 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
	documentation of the blkif 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 Feb 23, 2012, at 11:50 AM, Konrad Rzeszutek Wilk wrote:

> On Wed, Feb 22, 2012 at 11:14:31AM +0000, Ian Campbell wrote:
>> On Tue, 2012-02-21 at 21:36 +0000, Konrad Rzeszutek Wilk wrote:
>> [...]
>>>> With that in mind, I believe that all of the required information
>>>> about discard is still present in blkif.h, but perhaps presented
>>>> differently or moved to different sections.  Can you be more
>>>> specific about the information that you feel is missing here and
>>>> in the other places you noted below?
>>> 
>>> The original statement about how the backend would determine how
>>> to expose this information.
>> 
>> Please can you quote the actual text of the statements which you think
>> are missing and/or should be retained so we know precisely what you are
>> talking about.
> 
> Ah, it is in the Notes section. However the information that is not present in 4) is
> 
> 	The discard-alignment parameter indicates how many bytes
> 	the beginning of the partition is offset from the internal allocation unit's
> 	natural alignment. Do not confuse this with natural disk alignment offset.
> 
> [granted we don't expose the natural disk alignment offset right now, so maybe
> that comment is useless]

I removed the old text because it was imprecise (what is "natural
disk alignment" and how is it different from "discard natural
alignment"?) and, even if you understand its intended meaning, there
is no information provided in the interface to allow for this type
of confusion.

I think there would be tremendous value in exporting a XenBus node
to indicate the physical sector size.  I would be happy to propose
this feature in a different patch set and clarify the three different
allocation sizes that are published.

This email did cause me to go review the description for sector-size.
I have now changed it to be:

* sector-size
 *      Values:         <uint32_t>
 *
 *      The size, in bytes, of the individually addressible data blocks
 *      on the backend device.

It used to say "The native sector size, in bytes, of the backend
device." which it isn't.  "sector-size"'d access may be emulated.

> and 6):
> 	Devices that support discard functionality may
> 	internally allocate space using units that are bigger than the logical block
> 	size.  The discard-granularity parameter indicates the size of the internal
> 	allocation unit in bytes if reported by the device. Otherwise the
> 	discard-granularity will be set to match the device's physical block size.
> 	It is the minimum size you can discard.
> 
> [though parts of that comment are there]

Just the last sentence here is not directly replicated in the patch set.
To my mind, the definition of this value is clear and it is up to the
implementor to publish a valid value or not claim support for this
feature.  How this is achieved does not belong in the blkif spec.

>> Perhaps details which aren't part of the formal spec, e.g.
>> implementation tips, details of various OSes implementation choices etc
>> could be kept elsewhere, e.g. on the wiki?
> 
> On the Document day when I started documenting the PSE != PAT and the page
> pinning procedure - I had no idea where to stick that explanation of what goes behind
> the scene and how to properly do it so Ian Jackson suggested in the header of
> the function. That is an implementation tip of how to properly do it
> so you don't shoot yourself in the foot.
> 
> Where should something similar for blkback be so it can grow along with the source?

Now that they are documented, the features aren't an area ripe for
foot shooting.  The state transitions are, and I would support
adding more state diagrams to this header file (e.g.  tool stack
initiated closes, the impact of the "online" attribute, etc.).

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 23 22:41:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 23 Feb 2012 22:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0hLy-00016o-Gk; Thu, 23 Feb 2012 22:41:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S0hLx-00016S-1Y
	for xen-devel@lists.xensource.com; Thu, 23 Feb 2012 22:41:33 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330036884!12817790!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27991 invoked from network); 23 Feb 2012 22:41:26 -0000
Received: from www.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2012 22:41:26 -0000
Received: from perrybergman.sldomain.com (207-225-98-3.dia.static.qwest.net
	[207.225.98.3]) (authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1NMfIMV048147
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 23 Feb 2012 15:41:19 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <20120223185052.GB22922@phenom.dumpdata.com>
Date: Thu, 23 Feb 2012 15:41:15 -0700
Message-Id: <F771C692-9648-47BB-9D53-B600968FC803@spectralogic.com>
References: <patchbomb.1329761241@ns1.eng.sldomain.com>
	<e7990245681961f475fb.1329761243@ns1.eng.sldomain.com>
	<20120221141041.GC11950@phenom.dumpdata.com>
	<D73CB6D0-8D1E-4CD1-AF33-58FDDA77EA28@spectralogic.com>
	<20120221213623.GB28154@phenom.dumpdata.com>
	<1329909271.2880.32.camel@zakaz.uk.xensource.com>
	<20120223185052.GB22922@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [70.89.174.89]);
	Thu, 23 Feb 2012 15:41:19 -0700 (MST)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 4 v3] blkif.h: Provide more complete
	documentation of the blkif 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 Feb 23, 2012, at 11:50 AM, Konrad Rzeszutek Wilk wrote:

> On Wed, Feb 22, 2012 at 11:14:31AM +0000, Ian Campbell wrote:
>> On Tue, 2012-02-21 at 21:36 +0000, Konrad Rzeszutek Wilk wrote:
>> [...]
>>>> With that in mind, I believe that all of the required information
>>>> about discard is still present in blkif.h, but perhaps presented
>>>> differently or moved to different sections.  Can you be more
>>>> specific about the information that you feel is missing here and
>>>> in the other places you noted below?
>>> 
>>> The original statement about how the backend would determine how
>>> to expose this information.
>> 
>> Please can you quote the actual text of the statements which you think
>> are missing and/or should be retained so we know precisely what you are
>> talking about.
> 
> Ah, it is in the Notes section. However the information that is not present in 4) is
> 
> 	The discard-alignment parameter indicates how many bytes
> 	the beginning of the partition is offset from the internal allocation unit's
> 	natural alignment. Do not confuse this with natural disk alignment offset.
> 
> [granted we don't expose the natural disk alignment offset right now, so maybe
> that comment is useless]

I removed the old text because it was imprecise (what is "natural
disk alignment" and how is it different from "discard natural
alignment"?) and, even if you understand its intended meaning, there
is no information provided in the interface to allow for this type
of confusion.

I think there would be tremendous value in exporting a XenBus node
to indicate the physical sector size.  I would be happy to propose
this feature in a different patch set and clarify the three different
allocation sizes that are published.

This email did cause me to go review the description for sector-size.
I have now changed it to be:

* sector-size
 *      Values:         <uint32_t>
 *
 *      The size, in bytes, of the individually addressible data blocks
 *      on the backend device.

It used to say "The native sector size, in bytes, of the backend
device." which it isn't.  "sector-size"'d access may be emulated.

> and 6):
> 	Devices that support discard functionality may
> 	internally allocate space using units that are bigger than the logical block
> 	size.  The discard-granularity parameter indicates the size of the internal
> 	allocation unit in bytes if reported by the device. Otherwise the
> 	discard-granularity will be set to match the device's physical block size.
> 	It is the minimum size you can discard.
> 
> [though parts of that comment are there]

Just the last sentence here is not directly replicated in the patch set.
To my mind, the definition of this value is clear and it is up to the
implementor to publish a valid value or not claim support for this
feature.  How this is achieved does not belong in the blkif spec.

>> Perhaps details which aren't part of the formal spec, e.g.
>> implementation tips, details of various OSes implementation choices etc
>> could be kept elsewhere, e.g. on the wiki?
> 
> On the Document day when I started documenting the PSE != PAT and the page
> pinning procedure - I had no idea where to stick that explanation of what goes behind
> the scene and how to properly do it so Ian Jackson suggested in the header of
> the function. That is an implementation tip of how to properly do it
> so you don't shoot yourself in the foot.
> 
> Where should something similar for blkback be so it can grow along with the source?

Now that they are documented, the features aren't an area ripe for
foot shooting.  The state transitions are, and I would support
adding more state diagrams to this header file (e.g.  tool stack
initiated closes, the impact of the "online" attribute, etc.).

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 00:26:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 00:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0izE-0002dQ-Dw; Fri, 24 Feb 2012 00:26:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1S0izD-0002dH-1O
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 00:26:11 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330043163!16645902!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13439 invoked from network); 24 Feb 2012 00:26:03 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 00:26:03 -0000
Received: by wibhm2 with SMTP id hm2so4249918wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 16:26:03 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.80.226 as permitted sender) client-ip=10.180.80.226; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.80.226 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.80.226])
	by 10.180.80.226 with SMTP id u2mr271662wix.0.1330043163363 (num_hops =
	1); Thu, 23 Feb 2012 16:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=wQIRix5pfyYVisjsZRKCWq5aklEJpINYehBsAHJH/dU=;
	b=Ltac7bkNT8vhqKfdR8Mvv55PUak9oU8/n7ZiiY4bOKyA1OUPdEYnOo8IYcmc37JBJf
	a0cR5Rc9p8FK2YVP/Ku/RVY62qnCsGHrtXehi3En79pJNFYa1clMe+AkvwvzJxybbv99
	/W1890i20yoUK2LTxLdwRzS3UCgo3QN0y4n7o=
MIME-Version: 1.0
Received: by 10.180.80.226 with SMTP id u2mr192327wix.0.1330042740841; Thu, 23
	Feb 2012 16:19:00 -0800 (PST)
Received: by 10.180.106.99 with HTTP; Thu, 23 Feb 2012 16:19:00 -0800 (PST)
In-Reply-To: <20120221145526.GH5652@phenom.dumpdata.com>
References: <4F405CD0.2060002@virtfinity.de>
	<20120221145526.GH5652@phenom.dumpdata.com>
Date: Thu, 23 Feb 2012 17:19:00 -0700
Message-ID: <CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, Thomas Weyergraf <T.Weyergraf@virtfinity.de>
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8954770910005205047=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8954770910005205047==
Content-Type: multipart/alternative; boundary=f46d044288d21a9e5304b9aab5c4

--f46d044288d21a9e5304b9aab5c4
Content-Type: text/plain; charset=ISO-8859-1

I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk
git. I had extracted patch from pvscssi-01 and applied it back to
3.3.0-rc1. I am able to load both xen-scsiback and xen-scsifront modules
but I don't see anything happening.
does xl supports pvscsi or it needs to be patched. I am running 4.2
unstable.


On Tue, Feb 21, 2012 at 7:55 AM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Sun, Feb 19, 2012 at 03:22:08AM +0100, Thomas Weyergraf wrote:
> > Hi, I am working as a system administrator at an internet platform
> > service provider, and I am currently seeking to re-new our Xen
> > virtualization infrastructure for which I am mostly responsible for.
> > Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0
> > with CentOS 5.x pv-guests.
> >
> > Based on my experiments, I am currently looking into Xen 4.1.2 on
> > RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as
> > Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.
>
> Sweet.
> >
> > Our DomU's have their disk-devices on iscsi-storage backends (EMC,
> > netapp, Linux IET), we attach the disks to Dom0 via open-iscsi
> > initiator and pass them as 'phy'-type blockdevices, using
> > blkfront/back.
>
> OK.
> >
> > As this is the time for a major overhaul anyway, I looked at
> > 'pvscsi', which is very attractive to me for a bunch of
> > (administrative) reasons. I have created a working pvscsi-setup with
> > the following steps:
> > 1. Use CentOS 6.2 as base system
> > 2. Add Xen hypervisor from Michael Young's repository [1]. This is
> > stock 4.1.2 with a patch from 4.1-testing pulled-in and various
> > patches fixing compile-time issues, toolchain problems and system
> > service management on RHEL-alike systems. (Nice work, btw!)
> > 3. Use a vanilla 3.2.0 kernel from kernel.org and a .config based on
> > a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,
> > Fedora 16 supports Dom0 operation and the only changes to the config
> > are non-Xen related or add the Xen pvscsi config. I refrained from
> > attaching the config to avoid mailinglist-clutter, but can do so on
> > demand.
>
> Awesome.
> > 4. I pulled and applied the pvscsi-patch found in this post [2] from
> > Konrad Rzeszutek Wilk.
> >
> > Putting it all together yielded a "working setup" in which I am able
> > to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.
> > In DomU context, I could partition the device, create a filesystem
> > on it and copy/read/verify some 10gig of data to it. Very basic
> > testing until now, essentially. However, the whole issue raised some
> > questions:
> >
> > - I pvscsi actively maintained? Is someone working on this or even
> > prepare it for upstream inclusion in the pv-ops framework of the 3.x
> > series?
>
> So nobody has stepped up to do the upstream task and it is on my todo list
> but mostly at the end.
>
> > - Has anybody started on adding the vscsi-semantics to the xl toolstack?
>
> Not that I know of.
>
> > - Using 'xm', I was only able to add a device via its SCSI tupel
> > (HCTL, e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other
> > device-node, such as '/dev/sde' or the
> > '/dev/disk/by-path/<iscsi-iqn>' link. For these invocations, an
> > "Error: Cannot find device <device>" message is given. I have not
> > yet looked at the issue in detail (in
> > /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this
> > a known issue?
>
> First time I hear of it. But then I didn't even think to use /dev/sde
> to pass in a device since SCSI devices aren't neccessarily block ones.
> They can be scanners, medical devices, tape drivers, etc - which
> might not have a /dev/sdX (thought they will have an /dev/sgX).
>
> >
> > Is there any developer(s) working on getting pvscsi ready for
> > kernel.org 3.x upstream inclusion? Should i better retool my efforts
> > using pv-ops xen/stable 2.6.32 series?
>
> For 3.x upstream inclusion - not that I know off.
> Why would you want to retool your effort in using the 2.6.32 series
> as opposed to 3.x? What other items is the 3.x missing compared to 2.6.32?
>
> Now the good news is that I am happy to keep this going (pv-scsi)
> and fixing it, and having incremental updates to make it better.
>
> >
> > If applicable, I'd be more than happy to provide assistance to move
> > forward pvscsi. Maybe, as a start, provide a short, practical howto
> > about what I did above to get pvscsi working and reference it by the
> > Xen PVSCSI wiki page [3]?
>
> Sure. Also, did you use the git tree to pull the patches or just
> the big patch file ? The git tree has fixes to make it work under 3.2 as
> well.
>
> >
> > Regards,
> > Thomas Weyergraf
> >
> > [1] http://xenbits.xen.org/people/mayoung/EL6.xen/
> > [2] http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
> > [3] http://wiki.xen.org/xenwiki/XenPVSCSI
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--f46d044288d21a9e5304b9aab5c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk gi=
t. I had extracted patch from pvscssi-01 and applied it back to  3.3.0-rc1.=
 I am able to load both xen-scsiback and xen-scsifront modules but I don&#3=
9;t see anything happening. <br>
does xl supports pvscsi or it needs to be patched. I am running 4.2 unstabl=
e. <br><br><br><div class=3D"gmail_quote">On Tue, Feb 21, 2012 at 7:55 AM, =
Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@o=
racle.com">konrad.wilk@oracle.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Feb 19, 2012 at 03=
:22:08AM +0100, Thomas Weyergraf wrote:<br>
&gt; Hi, I am working as a system administrator at an internet platform<br>
&gt; service provider, and I am currently seeking to re-new our Xen<br>
&gt; virtualization infrastructure for which I am mostly responsible for.<b=
r>
&gt; Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0<br>
&gt; with CentOS 5.x pv-guests.<br>
&gt;<br>
&gt; Based on my experiments, I am currently looking into Xen 4.1.2 on<br>
&gt; RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as<br>
&gt; Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.<br>
<br>
</div>Sweet.<br>
<div class=3D"im">&gt;<br>
&gt; Our DomU&#39;s have their disk-devices on iscsi-storage backends (EMC,=
<br>
&gt; netapp, Linux IET), we attach the disks to Dom0 via open-iscsi<br>
&gt; initiator and pass them as &#39;phy&#39;-type blockdevices, using<br>
&gt; blkfront/back.<br>
<br>
</div>OK.<br>
<div class=3D"im">&gt;<br>
&gt; As this is the time for a major overhaul anyway, I looked at<br>
&gt; &#39;pvscsi&#39;, which is very attractive to me for a bunch of<br>
&gt; (administrative) reasons. I have created a working pvscsi-setup with<b=
r>
&gt; the following steps:<br>
&gt; 1. Use CentOS 6.2 as base system<br>
&gt; 2. Add Xen hypervisor from Michael Young&#39;s repository [1]. This is=
<br>
&gt; stock 4.1.2 with a patch from 4.1-testing pulled-in and various<br>
&gt; patches fixing compile-time issues, toolchain problems and system<br>
&gt; service management on RHEL-alike systems. (Nice work, btw!)<br>
&gt; 3. Use a vanilla 3.2.0 kernel from <a href=3D"http://kernel.org" targe=
t=3D"_blank">kernel.org</a> and a .config based on<br>
&gt; a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,<b=
r>
&gt; Fedora 16 supports Dom0 operation and the only changes to the config<b=
r>
&gt; are non-Xen related or add the Xen pvscsi config. I refrained from<br>
&gt; attaching the config to avoid mailinglist-clutter, but can do so on<br=
>
&gt; demand.<br>
<br>
</div>Awesome.<br>
<div class=3D"im">&gt; 4. I pulled and applied the pvscsi-patch found in th=
is post [2] from<br>
&gt; Konrad Rzeszutek Wilk.<br>
&gt;<br>
&gt; Putting it all together yielded a &quot;working setup&quot; in which I=
 am able<br>
&gt; to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.<br>
&gt; In DomU context, I could partition the device, create a filesystem<br>
&gt; on it and copy/read/verify some 10gig of data to it. Very basic<br>
&gt; testing until now, essentially. However, the whole issue raised some<b=
r>
&gt; questions:<br>
&gt;<br>
&gt; - I pvscsi actively maintained? Is someone working on this or even<br>
&gt; prepare it for upstream inclusion in the pv-ops framework of the 3.x<b=
r>
&gt; series?<br>
<br>
</div>So nobody has stepped up to do the upstream task and it is on my todo=
 list<br>
but mostly at the end.<br>
<div class=3D"im"><br>
&gt; - Has anybody started on adding the vscsi-semantics to the xl toolstac=
k?<br>
<br>
</div>Not that I know of.<br>
<div class=3D"im"><br>
&gt; - Using &#39;xm&#39;, I was only able to add a device via its SCSI tup=
el<br>
&gt; (HCTL, e.g: vscsi =3D [ &#39;7:0:0:0, 0:0:0:1&#39; ]) but not by any o=
ther<br>
&gt; device-node, such as &#39;/dev/sde&#39; or the<br>
&gt; &#39;/dev/disk/by-path/&lt;iscsi-iqn&gt;&#39; link. For these invocati=
ons, an<br>
&gt; &quot;Error: Cannot find device &lt;device&gt;&quot; message is given.=
 I have not<br>
&gt; yet looked at the issue in detail (in<br>
&gt; /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this<br=
>
&gt; a known issue?<br>
<br>
</div>First time I hear of it. But then I didn&#39;t even think to use /dev=
/sde<br>
to pass in a device since SCSI devices aren&#39;t neccessarily block ones.<=
br>
They can be scanners, medical devices, tape drivers, etc - which<br>
might not have a /dev/sdX (thought they will have an /dev/sgX).<br>
<div class=3D"im"><br>
&gt;<br>
&gt; Is there any developer(s) working on getting pvscsi ready for<br>
&gt; <a href=3D"http://kernel.org" target=3D"_blank">kernel.org</a> 3.x ups=
tream inclusion? Should i better retool my efforts<br>
&gt; using pv-ops xen/stable 2.6.32 series?<br>
<br>
</div>For 3.x upstream inclusion - not that I know off.<br>
Why would you want to retool your effort in using the 2.6.32 series<br>
as opposed to 3.x? What other items is the 3.x missing compared to 2.6.32?<=
br>
<br>
Now the good news is that I am happy to keep this going (pv-scsi)<br>
and fixing it, and having incremental updates to make it better.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; If applicable, I&#39;d be more than happy to provide assistance to mov=
e<br>
&gt; forward pvscsi. Maybe, as a start, provide a short, practical howto<br=
>
&gt; about what I did above to get pvscsi working and reference it by the<b=
r>
&gt; Xen PVSCSI wiki page [3]?<br>
<br>
</div>Sure. Also, did you use the git tree to pull the patches or just<br>
the big patch file ? The git tree has fixes to make it work under 3.2 as we=
ll.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt; Regards,<br>
&gt; Thomas Weyergraf<br>
&gt;<br>
&gt; [1] <a href=3D"http://xenbits.xen.org/people/mayoung/EL6.xen/" target=
=3D"_blank">http://xenbits.xen.org/people/mayoung/EL6.xen/</a><br>
&gt; [2] <a href=3D"http://lists.xen.org/archives/html/xen-devel/2011-11/ms=
g02268.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel=
/2011-11/msg02268.html</a><br>
&gt; [3] <a href=3D"http://wiki.xen.org/xenwiki/XenPVSCSI" target=3D"_blank=
">http://wiki.xen.org/xenwiki/XenPVSCSI</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<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>

--f46d044288d21a9e5304b9aab5c4--


--===============8954770910005205047==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8954770910005205047==--


From xen-devel-bounces@lists.xen.org Fri Feb 24 00:26:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 00:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0izE-0002dQ-Dw; Fri, 24 Feb 2012 00:26:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1S0izD-0002dH-1O
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 00:26:11 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330043163!16645902!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13439 invoked from network); 24 Feb 2012 00:26:03 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 00:26:03 -0000
Received: by wibhm2 with SMTP id hm2so4249918wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 16:26:03 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.80.226 as permitted sender) client-ip=10.180.80.226; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.80.226 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.80.226])
	by 10.180.80.226 with SMTP id u2mr271662wix.0.1330043163363 (num_hops =
	1); Thu, 23 Feb 2012 16:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=wQIRix5pfyYVisjsZRKCWq5aklEJpINYehBsAHJH/dU=;
	b=Ltac7bkNT8vhqKfdR8Mvv55PUak9oU8/n7ZiiY4bOKyA1OUPdEYnOo8IYcmc37JBJf
	a0cR5Rc9p8FK2YVP/Ku/RVY62qnCsGHrtXehi3En79pJNFYa1clMe+AkvwvzJxybbv99
	/W1890i20yoUK2LTxLdwRzS3UCgo3QN0y4n7o=
MIME-Version: 1.0
Received: by 10.180.80.226 with SMTP id u2mr192327wix.0.1330042740841; Thu, 23
	Feb 2012 16:19:00 -0800 (PST)
Received: by 10.180.106.99 with HTTP; Thu, 23 Feb 2012 16:19:00 -0800 (PST)
In-Reply-To: <20120221145526.GH5652@phenom.dumpdata.com>
References: <4F405CD0.2060002@virtfinity.de>
	<20120221145526.GH5652@phenom.dumpdata.com>
Date: Thu, 23 Feb 2012 17:19:00 -0700
Message-ID: <CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, Thomas Weyergraf <T.Weyergraf@virtfinity.de>
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8954770910005205047=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8954770910005205047==
Content-Type: multipart/alternative; boundary=f46d044288d21a9e5304b9aab5c4

--f46d044288d21a9e5304b9aab5c4
Content-Type: text/plain; charset=ISO-8859-1

I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk
git. I had extracted patch from pvscssi-01 and applied it back to
3.3.0-rc1. I am able to load both xen-scsiback and xen-scsifront modules
but I don't see anything happening.
does xl supports pvscsi or it needs to be patched. I am running 4.2
unstable.


On Tue, Feb 21, 2012 at 7:55 AM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Sun, Feb 19, 2012 at 03:22:08AM +0100, Thomas Weyergraf wrote:
> > Hi, I am working as a system administrator at an internet platform
> > service provider, and I am currently seeking to re-new our Xen
> > virtualization infrastructure for which I am mostly responsible for.
> > Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0
> > with CentOS 5.x pv-guests.
> >
> > Based on my experiments, I am currently looking into Xen 4.1.2 on
> > RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as
> > Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.
>
> Sweet.
> >
> > Our DomU's have their disk-devices on iscsi-storage backends (EMC,
> > netapp, Linux IET), we attach the disks to Dom0 via open-iscsi
> > initiator and pass them as 'phy'-type blockdevices, using
> > blkfront/back.
>
> OK.
> >
> > As this is the time for a major overhaul anyway, I looked at
> > 'pvscsi', which is very attractive to me for a bunch of
> > (administrative) reasons. I have created a working pvscsi-setup with
> > the following steps:
> > 1. Use CentOS 6.2 as base system
> > 2. Add Xen hypervisor from Michael Young's repository [1]. This is
> > stock 4.1.2 with a patch from 4.1-testing pulled-in and various
> > patches fixing compile-time issues, toolchain problems and system
> > service management on RHEL-alike systems. (Nice work, btw!)
> > 3. Use a vanilla 3.2.0 kernel from kernel.org and a .config based on
> > a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,
> > Fedora 16 supports Dom0 operation and the only changes to the config
> > are non-Xen related or add the Xen pvscsi config. I refrained from
> > attaching the config to avoid mailinglist-clutter, but can do so on
> > demand.
>
> Awesome.
> > 4. I pulled and applied the pvscsi-patch found in this post [2] from
> > Konrad Rzeszutek Wilk.
> >
> > Putting it all together yielded a "working setup" in which I am able
> > to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.
> > In DomU context, I could partition the device, create a filesystem
> > on it and copy/read/verify some 10gig of data to it. Very basic
> > testing until now, essentially. However, the whole issue raised some
> > questions:
> >
> > - I pvscsi actively maintained? Is someone working on this or even
> > prepare it for upstream inclusion in the pv-ops framework of the 3.x
> > series?
>
> So nobody has stepped up to do the upstream task and it is on my todo list
> but mostly at the end.
>
> > - Has anybody started on adding the vscsi-semantics to the xl toolstack?
>
> Not that I know of.
>
> > - Using 'xm', I was only able to add a device via its SCSI tupel
> > (HCTL, e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other
> > device-node, such as '/dev/sde' or the
> > '/dev/disk/by-path/<iscsi-iqn>' link. For these invocations, an
> > "Error: Cannot find device <device>" message is given. I have not
> > yet looked at the issue in detail (in
> > /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this
> > a known issue?
>
> First time I hear of it. But then I didn't even think to use /dev/sde
> to pass in a device since SCSI devices aren't neccessarily block ones.
> They can be scanners, medical devices, tape drivers, etc - which
> might not have a /dev/sdX (thought they will have an /dev/sgX).
>
> >
> > Is there any developer(s) working on getting pvscsi ready for
> > kernel.org 3.x upstream inclusion? Should i better retool my efforts
> > using pv-ops xen/stable 2.6.32 series?
>
> For 3.x upstream inclusion - not that I know off.
> Why would you want to retool your effort in using the 2.6.32 series
> as opposed to 3.x? What other items is the 3.x missing compared to 2.6.32?
>
> Now the good news is that I am happy to keep this going (pv-scsi)
> and fixing it, and having incremental updates to make it better.
>
> >
> > If applicable, I'd be more than happy to provide assistance to move
> > forward pvscsi. Maybe, as a start, provide a short, practical howto
> > about what I did above to get pvscsi working and reference it by the
> > Xen PVSCSI wiki page [3]?
>
> Sure. Also, did you use the git tree to pull the patches or just
> the big patch file ? The git tree has fixes to make it work under 3.2 as
> well.
>
> >
> > Regards,
> > Thomas Weyergraf
> >
> > [1] http://xenbits.xen.org/people/mayoung/EL6.xen/
> > [2] http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
> > [3] http://wiki.xen.org/xenwiki/XenPVSCSI
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--f46d044288d21a9e5304b9aab5c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk gi=
t. I had extracted patch from pvscssi-01 and applied it back to  3.3.0-rc1.=
 I am able to load both xen-scsiback and xen-scsifront modules but I don&#3=
9;t see anything happening. <br>
does xl supports pvscsi or it needs to be patched. I am running 4.2 unstabl=
e. <br><br><br><div class=3D"gmail_quote">On Tue, Feb 21, 2012 at 7:55 AM, =
Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@o=
racle.com">konrad.wilk@oracle.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Feb 19, 2012 at 03=
:22:08AM +0100, Thomas Weyergraf wrote:<br>
&gt; Hi, I am working as a system administrator at an internet platform<br>
&gt; service provider, and I am currently seeking to re-new our Xen<br>
&gt; virtualization infrastructure for which I am mostly responsible for.<b=
r>
&gt; Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0<br>
&gt; with CentOS 5.x pv-guests.<br>
&gt;<br>
&gt; Based on my experiments, I am currently looking into Xen 4.1.2 on<br>
&gt; RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as<br>
&gt; Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.<br>
<br>
</div>Sweet.<br>
<div class=3D"im">&gt;<br>
&gt; Our DomU&#39;s have their disk-devices on iscsi-storage backends (EMC,=
<br>
&gt; netapp, Linux IET), we attach the disks to Dom0 via open-iscsi<br>
&gt; initiator and pass them as &#39;phy&#39;-type blockdevices, using<br>
&gt; blkfront/back.<br>
<br>
</div>OK.<br>
<div class=3D"im">&gt;<br>
&gt; As this is the time for a major overhaul anyway, I looked at<br>
&gt; &#39;pvscsi&#39;, which is very attractive to me for a bunch of<br>
&gt; (administrative) reasons. I have created a working pvscsi-setup with<b=
r>
&gt; the following steps:<br>
&gt; 1. Use CentOS 6.2 as base system<br>
&gt; 2. Add Xen hypervisor from Michael Young&#39;s repository [1]. This is=
<br>
&gt; stock 4.1.2 with a patch from 4.1-testing pulled-in and various<br>
&gt; patches fixing compile-time issues, toolchain problems and system<br>
&gt; service management on RHEL-alike systems. (Nice work, btw!)<br>
&gt; 3. Use a vanilla 3.2.0 kernel from <a href=3D"http://kernel.org" targe=
t=3D"_blank">kernel.org</a> and a .config based on<br>
&gt; a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,<b=
r>
&gt; Fedora 16 supports Dom0 operation and the only changes to the config<b=
r>
&gt; are non-Xen related or add the Xen pvscsi config. I refrained from<br>
&gt; attaching the config to avoid mailinglist-clutter, but can do so on<br=
>
&gt; demand.<br>
<br>
</div>Awesome.<br>
<div class=3D"im">&gt; 4. I pulled and applied the pvscsi-patch found in th=
is post [2] from<br>
&gt; Konrad Rzeszutek Wilk.<br>
&gt;<br>
&gt; Putting it all together yielded a &quot;working setup&quot; in which I=
 am able<br>
&gt; to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.<br>
&gt; In DomU context, I could partition the device, create a filesystem<br>
&gt; on it and copy/read/verify some 10gig of data to it. Very basic<br>
&gt; testing until now, essentially. However, the whole issue raised some<b=
r>
&gt; questions:<br>
&gt;<br>
&gt; - I pvscsi actively maintained? Is someone working on this or even<br>
&gt; prepare it for upstream inclusion in the pv-ops framework of the 3.x<b=
r>
&gt; series?<br>
<br>
</div>So nobody has stepped up to do the upstream task and it is on my todo=
 list<br>
but mostly at the end.<br>
<div class=3D"im"><br>
&gt; - Has anybody started on adding the vscsi-semantics to the xl toolstac=
k?<br>
<br>
</div>Not that I know of.<br>
<div class=3D"im"><br>
&gt; - Using &#39;xm&#39;, I was only able to add a device via its SCSI tup=
el<br>
&gt; (HCTL, e.g: vscsi =3D [ &#39;7:0:0:0, 0:0:0:1&#39; ]) but not by any o=
ther<br>
&gt; device-node, such as &#39;/dev/sde&#39; or the<br>
&gt; &#39;/dev/disk/by-path/&lt;iscsi-iqn&gt;&#39; link. For these invocati=
ons, an<br>
&gt; &quot;Error: Cannot find device &lt;device&gt;&quot; message is given.=
 I have not<br>
&gt; yet looked at the issue in detail (in<br>
&gt; /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this<br=
>
&gt; a known issue?<br>
<br>
</div>First time I hear of it. But then I didn&#39;t even think to use /dev=
/sde<br>
to pass in a device since SCSI devices aren&#39;t neccessarily block ones.<=
br>
They can be scanners, medical devices, tape drivers, etc - which<br>
might not have a /dev/sdX (thought they will have an /dev/sgX).<br>
<div class=3D"im"><br>
&gt;<br>
&gt; Is there any developer(s) working on getting pvscsi ready for<br>
&gt; <a href=3D"http://kernel.org" target=3D"_blank">kernel.org</a> 3.x ups=
tream inclusion? Should i better retool my efforts<br>
&gt; using pv-ops xen/stable 2.6.32 series?<br>
<br>
</div>For 3.x upstream inclusion - not that I know off.<br>
Why would you want to retool your effort in using the 2.6.32 series<br>
as opposed to 3.x? What other items is the 3.x missing compared to 2.6.32?<=
br>
<br>
Now the good news is that I am happy to keep this going (pv-scsi)<br>
and fixing it, and having incremental updates to make it better.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; If applicable, I&#39;d be more than happy to provide assistance to mov=
e<br>
&gt; forward pvscsi. Maybe, as a start, provide a short, practical howto<br=
>
&gt; about what I did above to get pvscsi working and reference it by the<b=
r>
&gt; Xen PVSCSI wiki page [3]?<br>
<br>
</div>Sure. Also, did you use the git tree to pull the patches or just<br>
the big patch file ? The git tree has fixes to make it work under 3.2 as we=
ll.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt; Regards,<br>
&gt; Thomas Weyergraf<br>
&gt;<br>
&gt; [1] <a href=3D"http://xenbits.xen.org/people/mayoung/EL6.xen/" target=
=3D"_blank">http://xenbits.xen.org/people/mayoung/EL6.xen/</a><br>
&gt; [2] <a href=3D"http://lists.xen.org/archives/html/xen-devel/2011-11/ms=
g02268.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel=
/2011-11/msg02268.html</a><br>
&gt; [3] <a href=3D"http://wiki.xen.org/xenwiki/XenPVSCSI" target=3D"_blank=
">http://wiki.xen.org/xenwiki/XenPVSCSI</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<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>

--f46d044288d21a9e5304b9aab5c4--


--===============8954770910005205047==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8954770910005205047==--


From xen-devel-bounces@lists.xen.org Fri Feb 24 01:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0jXm-0004JR-CW; Fri, 24 Feb 2012 01:01:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1S0jXl-00038K-4K
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 01:01:53 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330045239!62396216!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDUzNDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25202 invoked from network); 24 Feb 2012 01:00:39 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 01:00:39 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C8E6420FC8
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 20:01:45 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Thu, 23 Feb 2012 20:01:45 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=oP
	RfH44vAH9z7pBd8vGL2beEtWo=; b=qF0Hb1gG9woaX29G6/KIM+J7YvyCMRTbnu
	X+nGDAu7Nc7zYNQLMisLWhtm0KecIeo5u8tQ8aX0nrwldfDkdTYL/K55At0ZDDXj
	WH5P0rNq8jhOo0rY3XlpW6IxVH7cicEj7s9EvR8Z7bDZtj4dpFwjes5pLDI2yY3f
	GfhVHbg18=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=oPRf
	H44vAH9z7pBd8vGL2beEtWo=; b=tb6WqgIUpkAkL7/sDan9Z87ojM5RVppm26lS
	HSA3OxHEYwB28oFEGkVMBsPShgE/3ZGlqNzPh4sAGC8v1AwbwDLiWOj00Po0K+aL
	9aYvwaL3uwIORp7KIreo1Yoy9cskTt8/DJitNb2dEsS8leqTW0N9XUxY/GA6P5dA
	PO+080A=
X-Sasl-enc: 4vR5sKVWUeuBiyZyFx+dn6LpAKzzKhkTP/Q4lE64W2zh 1330045305
Received: from [10.137.2.11] (87-207-161-88.dynamic.chello.pl [87.207.161.88])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 08B2B4824B0;
	Thu, 23 Feb 2012 20:01:44 -0500 (EST)
Message-ID: <4F46E174.6040009@invisiblethingslab.com>
Date: Fri, 24 Feb 2012 02:01:40 +0100
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
In-Reply-To: <20120223180313.GC22574@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1048643412374623495=="
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)
--===============1048643412374623495==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig0B75A1C5E85F4DE3A83A9DBD"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0B75A1C5E85F4DE3A83A9DBD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23.02.2012 19:03, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 06:39:29PM +0100, Joanna Rutkowska wrote:
>> On 02/23/12 18:31, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote=
:
>>>> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
>>>>> Hello,
>>>>>
>>>>> I've been trying to resolve the issue of my T420s (Core i5 2540M, I=
ntel
>>>>> integrated GPU) freezing at resume from S3 sleep... It seems like a=

>>>>> Xen-related problems, as a similar kernel to what we use in Dom0
>>>>> (2.6.38+xenlinux), when run on baremetal shows no signs of problems=
 at
>>>>> suspend/resume. Also I cannot find any problems reported on the int=
ernet
>>>>> with people having problems here.
>>>>>
>>>>> Unfortunately the only COM port on ExpressCard I have, presents its=
elf
>>>>> as a USB device, and so I cannot really debug this issue via consol=
e.
>>>>> The /var/log/pm-suspend also doesn't reveal anything useful (after =
I
>>>>> reboot, that is).
>>>>>
>>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises=
 how
>>>>> to approach debugging it?
>>>>>
>>>>> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenl=
inux
>>>>> patches, and the i915 for the graphics. (Unfortunately I cannot jus=
t
>>>>> boot the same Dom0 kernel without Xen, as the GRUB complains about
>>>>> executable being unrecognized -- probably some problem with wrong
>>>>> compression algo).
>>>>>
>>>>> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla ker=
nel)
>>>>> -- in this case it's even worse, as the system hangs at suspend and=

>>>>> never enters S3 :/
>>>>
>>>> Right. You need some patches for that in git://git.kernel.org/pub/sc=
m/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
>>>> to make that work.
>>>
>>> What I meant to say - please try it out with those patches. It might =
that you
>>> are hitting on one of the Intel bugs of the video adapter that I thin=
k
>>> are mostly fixed in the upstream kernel.
>>
>> So, you're saying those (presumed) bugs a fixed only in the pvops, and=

>> not in xenlinux?
>=20
> I am saying that they are fixed in 3.x kernels.

(the same hardware)
On 2.6.38.3 xenlinux kernel after resume there is screen content from bef=
ore
suspend, power led light constantly (as it should), but system is
irresponsible (no capslock led, no reaction to sysrq, network etc).
On 3.x with your patches system goes into S3, but on resume is even worse=
 - no
screen content at all (and no backlight) and also irresponsible, power le=
d
still blinking. As 3.x tried:
 - your devel/acpi-s3.v7 branch directly
 - 3.2.7 merged with devel/acpi-s3.v7
 - 3.3-rc4 with devel/acpi-s3.v7
 - your devel/acpi-s3.v8 branch directly
The same result on all above.

How can I debug this issue?

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig0B75A1C5E85F4DE3A83A9DBD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPRuF1AAoJENuP0xzK19csvXMH/isCx9LxT1zDNn5xVfU4OEte
F7GrfgkL5U7FpJJG1Ve/Dd9zy5l1gzWbfjtHp0KrB3e2rlxFJupGupckGh+p29cn
SMr33edanNTVcpez16Zh8f0wiOiWP2psnnB5R+pwheogqcAu83UrQDmTUsi87qhL
St871/thcUYO63kkZk1vQWqOCpwa3FZ/eDY4zgySc2mhkal+3/i0W7NssX//qLhp
Fd8rWVvG+EkWNyA6KmiCE+lw1pVF9k5i8binoj1QZ/EeYaKAoyqEanNMnSK5hq+8
bEIcfZpCQOL+4OR2z1e1mu/uQxU7w9JvX5PpJ1WHgWkQ6AeZBshKIgprFCA5hGE=
=Q3M3
-----END PGP SIGNATURE-----

--------------enig0B75A1C5E85F4DE3A83A9DBD--


--===============1048643412374623495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1048643412374623495==--


From xen-devel-bounces@lists.xen.org Fri Feb 24 01:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0jXm-0004JR-CW; Fri, 24 Feb 2012 01:01:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1S0jXl-00038K-4K
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 01:01:53 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330045239!62396216!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDUzNDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25202 invoked from network); 24 Feb 2012 01:00:39 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 01:00:39 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C8E6420FC8
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 20:01:45 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Thu, 23 Feb 2012 20:01:45 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=oP
	RfH44vAH9z7pBd8vGL2beEtWo=; b=qF0Hb1gG9woaX29G6/KIM+J7YvyCMRTbnu
	X+nGDAu7Nc7zYNQLMisLWhtm0KecIeo5u8tQ8aX0nrwldfDkdTYL/K55At0ZDDXj
	WH5P0rNq8jhOo0rY3XlpW6IxVH7cicEj7s9EvR8Z7bDZtj4dpFwjes5pLDI2yY3f
	GfhVHbg18=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=oPRf
	H44vAH9z7pBd8vGL2beEtWo=; b=tb6WqgIUpkAkL7/sDan9Z87ojM5RVppm26lS
	HSA3OxHEYwB28oFEGkVMBsPShgE/3ZGlqNzPh4sAGC8v1AwbwDLiWOj00Po0K+aL
	9aYvwaL3uwIORp7KIreo1Yoy9cskTt8/DJitNb2dEsS8leqTW0N9XUxY/GA6P5dA
	PO+080A=
X-Sasl-enc: 4vR5sKVWUeuBiyZyFx+dn6LpAKzzKhkTP/Q4lE64W2zh 1330045305
Received: from [10.137.2.11] (87-207-161-88.dynamic.chello.pl [87.207.161.88])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 08B2B4824B0;
	Thu, 23 Feb 2012 20:01:44 -0500 (EST)
Message-ID: <4F46E174.6040009@invisiblethingslab.com>
Date: Fri, 24 Feb 2012 02:01:40 +0100
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
In-Reply-To: <20120223180313.GC22574@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1048643412374623495=="
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)
--===============1048643412374623495==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig0B75A1C5E85F4DE3A83A9DBD"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0B75A1C5E85F4DE3A83A9DBD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23.02.2012 19:03, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 06:39:29PM +0100, Joanna Rutkowska wrote:
>> On 02/23/12 18:31, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Feb 23, 2012 at 09:18:27AM -0500, Konrad Rzeszutek Wilk wrote=
:
>>>> On Thu, Feb 23, 2012 at 10:13:56AM +0100, Joanna Rutkowska wrote:
>>>>> Hello,
>>>>>
>>>>> I've been trying to resolve the issue of my T420s (Core i5 2540M, I=
ntel
>>>>> integrated GPU) freezing at resume from S3 sleep... It seems like a=

>>>>> Xen-related problems, as a similar kernel to what we use in Dom0
>>>>> (2.6.38+xenlinux), when run on baremetal shows no signs of problems=
 at
>>>>> suspend/resume. Also I cannot find any problems reported on the int=
ernet
>>>>> with people having problems here.
>>>>>
>>>>> Unfortunately the only COM port on ExpressCard I have, presents its=
elf
>>>>> as a USB device, and so I cannot really debug this issue via consol=
e.
>>>>> The /var/log/pm-suspend also doesn't reveal anything useful (after =
I
>>>>> reboot, that is).
>>>>>
>>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises=
 how
>>>>> to approach debugging it?
>>>>>
>>>>> I'm running Xen 4.1.1 with some minor patches, and 2.6.38 with xenl=
inux
>>>>> patches, and the i915 for the graphics. (Unfortunately I cannot jus=
t
>>>>> boot the same Dom0 kernel without Xen, as the GRUB complains about
>>>>> executable being unrecognized -- probably some problem with wrong
>>>>> compression algo).
>>>>>
>>>>> I also tried 3.2.5 pvops kernel for Dom0 (essentially a vanilla ker=
nel)
>>>>> -- in this case it's even worse, as the system hangs at suspend and=

>>>>> never enters S3 :/
>>>>
>>>> Right. You need some patches for that in git://git.kernel.org/pub/sc=
m/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7
>>>> to make that work.
>>>
>>> What I meant to say - please try it out with those patches. It might =
that you
>>> are hitting on one of the Intel bugs of the video adapter that I thin=
k
>>> are mostly fixed in the upstream kernel.
>>
>> So, you're saying those (presumed) bugs a fixed only in the pvops, and=

>> not in xenlinux?
>=20
> I am saying that they are fixed in 3.x kernels.

(the same hardware)
On 2.6.38.3 xenlinux kernel after resume there is screen content from bef=
ore
suspend, power led light constantly (as it should), but system is
irresponsible (no capslock led, no reaction to sysrq, network etc).
On 3.x with your patches system goes into S3, but on resume is even worse=
 - no
screen content at all (and no backlight) and also irresponsible, power le=
d
still blinking. As 3.x tried:
 - your devel/acpi-s3.v7 branch directly
 - 3.2.7 merged with devel/acpi-s3.v7
 - 3.3-rc4 with devel/acpi-s3.v7
 - your devel/acpi-s3.v8 branch directly
The same result on all above.

How can I debug this issue?

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enig0B75A1C5E85F4DE3A83A9DBD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPRuF1AAoJENuP0xzK19csvXMH/isCx9LxT1zDNn5xVfU4OEte
F7GrfgkL5U7FpJJG1Ve/Dd9zy5l1gzWbfjtHp0KrB3e2rlxFJupGupckGh+p29cn
SMr33edanNTVcpez16Zh8f0wiOiWP2psnnB5R+pwheogqcAu83UrQDmTUsi87qhL
St871/thcUYO63kkZk1vQWqOCpwa3FZ/eDY4zgySc2mhkal+3/i0W7NssX//qLhp
Fd8rWVvG+EkWNyA6KmiCE+lw1pVF9k5i8binoj1QZ/EeYaKAoyqEanNMnSK5hq+8
bEIcfZpCQOL+4OR2z1e1mu/uQxU7w9JvX5PpJ1WHgWkQ6AeZBshKIgprFCA5hGE=
=Q3M3
-----END PGP SIGNATURE-----

--------------enig0B75A1C5E85F4DE3A83A9DBD--


--===============1048643412374623495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1048643412374623495==--


From xen-devel-bounces@lists.xen.org Fri Feb 24 02:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 02: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 1S0kdv-0007U0-UE; Fri, 24 Feb 2012 02:12:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1S0kdt-0007Tv-8W
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 02:12:18 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330049530!14679173!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26831 invoked from network); 24 Feb 2012 02:12:10 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 02:12:10 -0000
Received: by wgbdr13 with SMTP id dr13so1475216wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 18:12:10 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.99.7 as permitted sender) client-ip=10.180.99.7; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.99.7 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.99.7])
	by 10.180.99.7 with SMTP id em7mr545789wib.7.1330049530062 (num_hops =
	1); Thu, 23 Feb 2012 18:12:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/Tj+iCmF0uNXmwE046N2qoWat+5Cng/Y9DlpTBIsFdU=;
	b=OojF0PP/e0Fbx2hlOdX7OcVsP+f+SHDUp+0wz0RzPdOC6xyZ+rbpASsKOyamWxeHzP
	FHoyveqOtvwA0fnobjHN8LGwKRBRWj/SIc8AZp4UkBPWFsQU/OIFDcy8e70WbdHtpNpf
	/RZxwKRmoB7OvBVNk9zlmguyiuOBMiAtIwyvM=
MIME-Version: 1.0
Received: by 10.180.99.7 with SMTP id em7mr451573wib.7.1330049529992; Thu, 23
	Feb 2012 18:12:09 -0800 (PST)
Received: by 10.180.106.99 with HTTP; Thu, 23 Feb 2012 18:12:09 -0800 (PST)
Date: Thu, 23 Feb 2012 19:12:09 -0700
Message-ID: <CAHyyzzTxGHVu02sP==Lm2Du2GSCK6Bct=8F98djP0-M4hhx5vQ@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=f46d04182804c4d6b904b9ac494f
Subject: [Xen-devel] pvscsi patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d04182804c4d6b904b9ac494f
Content-Type: multipart/alternative; boundary=f46d04182804c4d6a204b9ac494d

--f46d04182804c4d6a204b9ac494d
Content-Type: text/plain; charset=ISO-8859-1

I had extracted this pvscsi patch to 3.3.0 kernel. from pvscsi git and
patched my kernel. both xenscsi-back front loads fine. If I start vm with
xm domU and hvm can see my blurey drive with it correct name but I get scsi
errors. I wonder if there is patch that gives direct access to scsi device.
esxi gives direct access so makemkv works perfectly.

--f46d04182804c4d6a204b9ac494d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I had extracted this pvscsi patch to 3.3.0 kernel. from pvscsi git and patc=
hed my kernel. both xenscsi-back front loads fine. If I start vm with xm do=
mU and hvm can see my blurey drive with it correct name but I get scsi erro=
rs. I wonder if there is patch that gives direct access to scsi device. esx=
i gives direct access so makemkv works perfectly. <br>

--f46d04182804c4d6a204b9ac494d--
--f46d04182804c4d6b904b9ac494f
Content-Type: application/octet-stream; name="patch-pvscsi.diff"
Content-Disposition: attachment; filename="patch-pvscsi.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gz2tyvqr0

ZGlmZiAtcnVwTiB4ZW4vZHJpdmVycy9zY3NpL0tjb25maWcgeGVuYy9kcml2ZXJzL3Njc2kvS2Nv
bmZpZwotLS0geGVuL2RyaXZlcnMvc2NzaS9LY29uZmlnCTIwMTItMDItMjQgMTU6MTI6MzkuNzIy
MzExNjMzIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2NzaS9LY29uZmlnCTIwMTItMDItMjQgMTU6
MTk6MzUuMzE1NjQ0OTMzIC0wNzAwCkBAIC0xODk3LDYgKzE4OTcsMjIgQEAgY29uZmlnIFNDU0lf
QkZBX0ZDCiAJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBo
ZXJlLiBUaGUgbW9kdWxlIHdpbGwKIAkgIGJlIGNhbGxlZCBiZmEuCiAKK2NvbmZpZyBYRU5fU0NT
SV9GUk9OVEVORAorICAgICAgICB0cmlzdGF0ZSAiWGVuIFBWU0NTSSBmcm9udGVuZCBkcml2ZXIi
CisgICAgICAgIGRlcGVuZHMgb24gWEVOICYmIFNDU0kKKyAgICAgICAgZGVmYXVsdCBtCisgICAg
ICAgIGhlbHAKKyAgICAgICAgICBUaGUgU0NTSSBmcm9udGVuZCBkcml2ZXIgYWxsb3dzIHRoZSBr
ZXJuZWwgdG8gYWNjZXNzIFNDU0kgRGV2aWNlcworICAgICAgICAgIHdpdGhpbiBhbm90aGVyIGd1
ZXN0IE9TLgorCitjb25maWcgWEVOX1NDU0lfQkFDS0VORAorICAgICAgICB0cmlzdGF0ZSAiWGVu
IFBWU0NTSSBiYWNrZW5kIGRyaXZlciIKKyAgICAgICAgZGVwZW5kcyBvbiBYRU5fQkFDS0VORCAm
JiBTQ1NJCisgICAgICAgIGRlZmF1bHQgbQorICAgICAgICBoZWxwCisgICAgICAgICAgVGhlIFBW
U0NTSSBiYWNrZW5kIGRyaXZlciBhbGxvd3MgdGhlIGtlcm5lbCB0byBleHBvcnQgaXRzIFNDU0kg
RGV2aWNlcworICAgICAgICAgIHRvIG90aGVyIFhlbiBndWVzdHMgdmlhIGEgaGlnaC1wZXJmb3Jt
YW5jZSBzaGFyZWQtbWVtb3J5IGludGVyZmFjZS4KKwogZW5kaWYgIyBTQ1NJX0xPV0xFVkVMCiAK
IHNvdXJjZSAiZHJpdmVycy9zY3NpL3BjbWNpYS9LY29uZmlnIgpkaWZmIC1ydXBOIHhlbi9kcml2
ZXJzL3Njc2kvS2NvbmZpZy5vcmlnIHhlbmMvZHJpdmVycy9zY3NpL0tjb25maWcub3JpZwotLS0g
eGVuL2RyaXZlcnMvc2NzaS9LY29uZmlnLm9yaWcJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAw
MDAgLTA3MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL0tjb25maWcub3JpZwkyMDEyLTAyLTI0IDE1
OjEyOjM5LjcyMjMxMTYzMyAtMDcwMApAQCAtMCwwICsxLDE5MDggQEAKK21lbnUgIlNDU0kgZGV2
aWNlIHN1cHBvcnQiCisKK2NvbmZpZyBTQ1NJX01PRAorICAgICAgIHRyaXN0YXRlCisgICAgICAg
ZGVmYXVsdCB5IGlmIFNDU0k9biB8fCBTQ1NJPXkKKyAgICAgICBkZWZhdWx0IG0gaWYgU0NTST1t
CisKK2NvbmZpZyBSQUlEX0FUVFJTCisJdHJpc3RhdGUgIlJBSUQgVHJhbnNwb3J0IENsYXNzIgor
CWRlZmF1bHQgbgorCWRlcGVuZHMgb24gQkxPQ0sKKwlkZXBlbmRzIG9uIFNDU0lfTU9ECisJLS0t
aGVscC0tLQorCSAgUHJvdmlkZXMgUkFJRAorCitjb25maWcgU0NTSQorCXRyaXN0YXRlICJTQ1NJ
IGRldmljZSBzdXBwb3J0IgorCWRlcGVuZHMgb24gQkxPQ0sKKwlzZWxlY3QgU0NTSV9ETUEgaWYg
SEFTX0RNQQorCS0tLWhlbHAtLS0KKwkgIElmIHlvdSB3YW50IHRvIHVzZSBhIFNDU0kgaGFyZCBk
aXNrLCBTQ1NJIHRhcGUgZHJpdmUsIFNDU0kgQ0QtUk9NIG9yCisJICBhbnkgb3RoZXIgU0NTSSBk
ZXZpY2UgdW5kZXIgTGludXgsIHNheSBZIGFuZCBtYWtlIHN1cmUgdGhhdCB5b3Uga25vdworCSAg
dGhlIG5hbWUgb2YgeW91ciBTQ1NJIGhvc3QgYWRhcHRlciAodGhlIGNhcmQgaW5zaWRlIHlvdXIg
Y29tcHV0ZXIKKwkgIHRoYXQgInNwZWFrcyIgdGhlIFNDU0kgcHJvdG9jb2wsIGFsc28gY2FsbGVk
IFNDU0kgY29udHJvbGxlciksCisJICBiZWNhdXNlIHlvdSB3aWxsIGJlIGFza2VkIGZvciBpdC4K
KworCSAgWW91IGFsc28gbmVlZCB0byBzYXkgWSBoZXJlIGlmIHlvdSBoYXZlIGEgZGV2aWNlIHdo
aWNoIHNwZWFrcworCSAgdGhlIFNDU0kgcHJvdG9jb2wuICBFeGFtcGxlcyBvZiB0aGlzIGluY2x1
ZGUgdGhlIHBhcmFsbGVsIHBvcnQKKwkgIHZlcnNpb24gb2YgdGhlIElPTUVHQSBaSVAgZHJpdmUs
IFVTQiBzdG9yYWdlIGRldmljZXMsIEZpYnJlCisJICBDaGFubmVsLCBhbmQgRmlyZVdpcmUgc3Rv
cmFnZS4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g
aGVyZSBhbmQgcmVhZAorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2kudHh0Pi4KKwkg
IFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc2NzaV9tb2QuCisKKwkgIEhvd2V2ZXIsIGRvIG5v
dCBjb21waWxlIHRoaXMgYXMgYSBtb2R1bGUgaWYgeW91ciByb290IGZpbGUgc3lzdGVtCisJICAo
dGhlIG9uZSBjb250YWluaW5nIHRoZSBkaXJlY3RvcnkgLykgaXMgbG9jYXRlZCBvbiBhIFNDU0kg
ZGV2aWNlLgorCitjb25maWcgU0NTSV9ETUEKKwlib29sCisJZGVmYXVsdCBuCisKK2NvbmZpZyBT
Q1NJX1RHVAorCXRyaXN0YXRlICJTQ1NJIHRhcmdldCBzdXBwb3J0IgorCWRlcGVuZHMgb24gU0NT
SSAmJiBFWFBFUklNRU5UQUwKKwktLS1oZWxwLS0tCisJICBJZiB5b3Ugd2FudCB0byB1c2UgU0NT
SSB0YXJnZXQgbW9kZSBkcml2ZXJzIGVuYWJsZSB0aGlzIG9wdGlvbi4KKwkgIElmIHlvdSBjaG9v
c2UgTSwgdGhlIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBzY3NpX3RndC4KKworY29uZmlnIFNDU0lf
TkVUTElOSworCWJvb2wKKwlkZWZhdWx0CW4KKwlzZWxlY3QgTkVUCisKK2NvbmZpZyBTQ1NJX1BS
T0NfRlMKKwlib29sICJsZWdhY3kgL3Byb2Mvc2NzaS8gc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFND
U0kgJiYgUFJPQ19GUworCWRlZmF1bHQgeQorCS0tLWhlbHAtLS0KKwkgIFRoaXMgb3B0aW9uIGVu
YWJsZXMgc3VwcG9ydCBmb3IgdGhlIHZhcmlvdXMgZmlsZXMgaW4KKwkgIC9wcm9jL3Njc2kuICBJ
biBMaW51eCAyLjYgdGhpcyBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5CisJICBmaWxlcyBpbiBzeXNm
cyBidXQgbWFueSBsZWdhY3kgYXBwbGljYXRpb25zIHJlbHkgb24gdGhpcy4KKworCSAgSWYgdW5z
dXJlIHNheSBZLgorCitjb21tZW50ICJTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFwZSwgQ0Qt
Uk9NKSIKKwlkZXBlbmRzIG9uIFNDU0kKKworY29uZmlnIEJMS19ERVZfU0QKKwl0cmlzdGF0ZSAi
U0NTSSBkaXNrIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJCisJc2VsZWN0IENSQ19UMTBESUYg
aWYgQkxLX0RFVl9JTlRFR1JJVFkKKwktLS1oZWxwLS0tCisJICBJZiB5b3Ugd2FudCB0byB1c2Ug
U0NTSSBoYXJkIGRpc2tzLCBGaWJyZSBDaGFubmVsIGRpc2tzLAorCSAgU2VyaWFsIEFUQSAoU0FU
QSkgb3IgUGFyYWxsZWwgQVRBIChQQVRBKSBoYXJkIGRpc2tzLAorCSAgVVNCIHN0b3JhZ2Ugb3Ig
dGhlIFNDU0kgb3IgcGFyYWxsZWwgcG9ydCB2ZXJzaW9uIG9mCisJICB0aGUgSU9NRUdBIFpJUCBk
cml2ZSwgc2F5IFkgYW5kIHJlYWQgdGhlIFNDU0ktSE9XVE8sCisJICB0aGUgRGlzay1IT1dUTyBh
bmQgdGhlIE11bHRpLURpc2stSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0cDovL3d3dy50
bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiBUaGlzIGlzIE5PVCBmb3IgU0NTSQorCSAgQ0QtUk9N
cy4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVy
ZSBhbmQgcmVhZAorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2kudHh0Pi4KKwkgIFRo
ZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc2RfbW9kLgorCisJICBEbyBub3QgY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSBpZiB5b3VyIHJvb3QgZmlsZSBzeXN0ZW0KKwkgICh0aGUgb25l
IGNvbnRhaW5pbmcgdGhlIGRpcmVjdG9yeSAvKSBpcyBsb2NhdGVkIG9uIGEgU0NTSSBkaXNrLgor
CSAgSW4gdGhpcyBjYXNlLCBkbyBub3QgY29tcGlsZSB0aGUgZHJpdmVyIGZvciB5b3VyIFNDU0kg
aG9zdCBhZGFwdGVyCisJICAoYmVsb3cpIGFzIGEgbW9kdWxlIGVpdGhlci4KKworY29uZmlnIENI
Ul9ERVZfU1QKKwl0cmlzdGF0ZSAiU0NTSSB0YXBlIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJ
CisJLS0taGVscC0tLQorCSAgSWYgeW91IHdhbnQgdG8gdXNlIGEgU0NTSSB0YXBlIGRyaXZlIHVu
ZGVyIExpbnV4LCBzYXkgWSBhbmQgcmVhZCB0aGUKKwkgIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBm
cm9tCisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LCBhbmQKKwkgIDxm
aWxlOkRvY3VtZW50YXRpb24vc2NzaS9zdC50eHQ+IGluIHRoZSBrZXJuZWwgc291cmNlLiAgVGhp
cyBpcyBOT1QKKwkgIGZvciBTQ1NJIENELVJPTXMuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2
ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmUgYW5kIHJlYWQKKwkgIDxmaWxlOkRvY3VtZW50
YXRpb24vc2NzaS9zY3NpLnR4dD4uIFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc3QuCisKK2Nv
bmZpZyBDSFJfREVWX09TU1QKKwl0cmlzdGF0ZSAiU0NTSSBPblN0cmVhbSBTQy14MCB0YXBlIHN1
cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJCisJLS0taGVscC0tLQorCSAgVGhlIE9uU3RyZWFtIFND
LXgwIFNDU0kgdGFwZSBkcml2ZXMgY2Fubm90IGJlIGRyaXZlbiBieSB0aGUKKwkgIHN0YW5kYXJk
IHN0IGRyaXZlciwgYnV0IGluc3RlYWQgbmVlZCB0aGlzIHNwZWNpYWwgb3NzdCBkcml2ZXIgYW5k
CisJICB1c2UgdGhlICAvZGV2L29zc3RYIGNoYXIgZGV2aWNlIG5vZGVzIChtYWpvciAyMDYpLiAg
VmlhIHVzYi1zdG9yYWdlLAorCSAgeW91IG1heSBiZSBhYmxlIHRvIGRyaXZlIHRoZSBVU0IteDAg
YW5kIERJLXgwIGRyaXZlcyBhcyB3ZWxsLgorCSAgTm90ZSB0aGF0IHRoZXJlIGlzIGFsc28gYSBz
ZWNvbmQgZ2VuZXJhdGlvbiBvZiBPblN0cmVhbQorCSAgdGFwZSBkcml2ZXMgKEFEUi14MCkgdGhh
dCBzdXBwb3J0cyB0aGUgc3RhbmRhcmQgU0NTSS0yIGNvbW1hbmRzIGZvcgorCSAgdGFwZXMgKFFJ
Qy0xNTcpIGFuZCBjYW4gYmUgZHJpdmVuIGJ5IHRoZSBzdGFuZGFyZCBkcml2ZXIgc3QuCisJICBG
b3IgbW9yZSBpbmZvcm1hdGlvbiwgeW91IG1heSBoYXZlIGEgbG9vayBhdCB0aGUgU0NTSS1IT1dU
TworCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPiAgYW5kCisJICA8Zmls
ZTpEb2N1bWVudGF0aW9uL3Njc2kvb3NzdC50eHQ+ICBpbiB0aGUga2VybmVsIHNvdXJjZS4KKwkg
IE1vcmUgaW5mbyBvbiB0aGUgT25TdHJlYW0gZHJpdmVyIG1heSBiZSBmb3VuZCBvbgorCSAgPGh0
dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvb3NzdC8+CisJICBQbGVhc2UgYWxzbyBoYXZl
IGEgbG9vayBhdCB0aGUgc3RhbmRhcmQgc3QgZG9jdSwgYXMgbW9zdCBvZiBpdAorCSAgYXBwbGll
cyB0byBvc3N0IGFzIHdlbGwuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1
bGUsIGNob29zZSBNIGhlcmUgYW5kIHJlYWQKKwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9z
Y3NpLnR4dD4uIFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgb3NzdC4KKworY29uZmlnIEJMS19E
RVZfU1IKKwl0cmlzdGF0ZSAiU0NTSSBDRFJPTSBzdXBwb3J0IgorCWRlcGVuZHMgb24gU0NTSQor
CS0tLWhlbHAtLS0KKwkgIElmIHlvdSB3YW50IHRvIHVzZSBhIENEIG9yIERWRCBkcml2ZSBhdHRh
Y2hlZCB0byB5b3VyIGNvbXB1dGVyCisJICBieSBTQ1NJLCBGaXJlV2lyZSwgVVNCIG9yIEFUQVBJ
LCBzYXkgWSBhbmQgcmVhZCB0aGUgU0NTSS1IT1dUTworCSAgYW5kIHRoZSBDRFJPTS1IT1dUTyBh
dCA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LgorCisJICBNYWtlIHN1cmUg
dG8gc2F5IFkgb3IgTSB0byAiSVNPIDk2NjAgQ0QtUk9NIGZpbGUgc3lzdGVtIHN1cHBvcnQiLgor
CisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlIGFu
ZCByZWFkCisJICA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvc2NzaS50eHQ+LgorCSAgVGhlIG1v
ZHVsZSB3aWxsIGJlIGNhbGxlZCBzcl9tb2QuCisKK2NvbmZpZyBCTEtfREVWX1NSX1ZFTkRPUgor
CWJvb2wgIkVuYWJsZSB2ZW5kb3Itc3BlY2lmaWMgZXh0ZW5zaW9ucyAoZm9yIFNDU0kgQ0RST00p
IgorCWRlcGVuZHMgb24gQkxLX0RFVl9TUgorCWhlbHAKKwkgIFRoaXMgZW5hYmxlcyB0aGUgdXNh
Z2Ugb2YgdmVuZG9yIHNwZWNpZmljIFNDU0kgY29tbWFuZHMuIFRoaXMgaXMKKwkgIHJlcXVpcmVk
IHRvIHN1cHBvcnQgbXVsdGlzZXNzaW9uIENEcyB3aXRoIG9sZCBORUMvVE9TSElCQSBjZHJvbQor
CSAgZHJpdmVzIChhbmQgSFAgV3JpdGVycykuIElmIHlvdSBoYXZlIHN1Y2ggYSBkcml2ZSBhbmQg
Z2V0IHRoZSBmaXJzdAorCSAgc2Vzc2lvbiBvbmx5LCB0cnkgc2F5aW5nIFkgaGVyZTsgZXZlcnli
b2R5IGVsc2Ugc2F5cyBOLgorCitjb25maWcgQ0hSX0RFVl9TRworCXRyaXN0YXRlICJTQ1NJIGdl
bmVyaWMgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0kKKwktLS1oZWxwLS0tCisJICBJZiB5b3Ug
d2FudCB0byB1c2UgU0NTSSBzY2FubmVycywgc3ludGhlc2l6ZXJzIG9yIENELXdyaXRlcnMgb3Ig
anVzdAorCSAgYWJvdXQgYW55dGhpbmcgaGF2aW5nICJTQ1NJIiBpbiBpdHMgbmFtZSBvdGhlciB0
aGFuIGhhcmQgZGlza3MsCisJICBDRC1ST01zIG9yIHRhcGVzLCBzYXkgWSBoZXJlLiBUaGVzZSB3
b24ndCBiZSBzdXBwb3J0ZWQgYnkgdGhlIGtlcm5lbAorCSAgZGlyZWN0bHksIHNvIHlvdSBuZWVk
IHNvbWUgYWRkaXRpb25hbCBzb2Z0d2FyZSB3aGljaCBrbm93cyBob3cgdG8KKwkgIHRhbGsgdG8g
dGhlc2UgZGV2aWNlcyB1c2luZyB0aGUgU0NTSSBwcm90b2NvbDoKKworCSAgRm9yIHNjYW5uZXJz
LCBsb29rIGF0IFNBTkUgKDxodHRwOi8vd3d3LnNhbmUtcHJvamVjdC5vcmcvPikuIEZvciBDRAor
CSAgd3JpdGVyIHNvZnR3YXJlIGxvb2sgYXQgQ2RydG9vbHMKKwkgICg8aHR0cDovL2NkcmVjb3Jk
LmJlcmxpb3MuZGUvcHJpdmF0ZS9jZHJlY29yZC5odG1sPikKKwkgIGFuZCBmb3IgYnVybmluZyBh
ICJkaXNrIGF0IG9uY2UiOiBDRFJEQU8KKwkgICg8aHR0cDovL2NkcmRhby5zb3VyY2Vmb3JnZS5u
ZXQvPikuIENkcGFyYW5vaWEgaXMgYSBoaWdoCisJICBxdWFsaXR5IGRpZ2l0YWwgcmVhZGVyIG9m
IGF1ZGlvIENEcyAoPGh0dHA6Ly93d3cueGlwaC5vcmcvcGFyYW5vaWEvPikuCisJICBGb3Igb3Ro
ZXIgZGV2aWNlcywgaXQncyBwb3NzaWJsZSB0aGF0IHlvdSdsbCBoYXZlIHRvIHdyaXRlIHRoZQor
CSAgZHJpdmVyIHNvZnR3YXJlIHlvdXJzZWxmLiBQbGVhc2UgcmVhZCB0aGUgZmlsZQorCSAgPGZp
bGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2ktZ2VuZXJpYy50eHQ+IGZvciBtb3JlIGluZm9ybWF0
aW9uLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBo
ZXJlIGFuZCByZWFkCisJICA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvc2NzaS50eHQ+LiBUaGUg
bW9kdWxlIHdpbGwgYmUgY2FsbGVkIHNnLgorCisJICBJZiB1bnN1cmUsIHNheSBOLgorCitjb25m
aWcgQ0hSX0RFVl9TQ0gKKwl0cmlzdGF0ZSAiU0NTSSBtZWRpYSBjaGFuZ2VyIHN1cHBvcnQiCisJ
ZGVwZW5kcyBvbiBTQ1NJCisJLS0taGVscC0tLQorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgU0NT
SSBtZWRpYSBjaGFuZ2Vycy4gIE1vc3QgY29tbW9uIGRldmljZXMgYXJlCisJICB0YXBlIGxpYnJh
cmllcyBhbmQgTU9EL0NEUk9NIGp1a2Vib3hlcy4gICpSZWFsKiBqdWtlYm94ZXMsIHlvdQorCSAg
ZG9uJ3QgbmVlZCB0aGlzIGZvciB0aG9zZSB0aW55IDYtc2xvdCBjZHJvbSBjaGFuZ2Vycy4gIE1l
ZGlhCisJICBjaGFuZ2VycyBhcmUgbGlzdGVkIGFzICJUeXBlOiBNZWRpdW0gQ2hhbmdlciIgaW4g
L3Byb2Mvc2NzaS9zY3NpLgorCSAgSWYgeW91IGhhdmUgc3VjaCBoYXJkd2FyZSBhbmQgd2FudCB0
byB1c2UgaXQgd2l0aCBsaW51eCwgc2F5IFkKKwkgIGhlcmUuICBDaGVjayA8ZmlsZTpEb2N1bWVu
dGF0aW9uL3Njc2kvc2NzaS1jaGFuZ2VyLnR4dD4gZm9yIGRldGFpbHMuCisJCisJICBJZiB5b3Ug
d2FudCB0byBjb21waWxlIHRoaXMgYXMgYSBtb2R1bGUgKCA9IGNvZGUgd2hpY2ggY2FuIGJlCisJ
ICBpbnNlcnRlZCBpbiBhbmQgcmVtb3ZlZCBmcm9tIHRoZSBydW5uaW5nIGtlcm5lbCB3aGVuZXZl
ciB5b3Ugd2FudCksCisJICBzYXkgTSBoZXJlIGFuZCByZWFkIDxmaWxlOkRvY3VtZW50YXRpb24v
a2J1aWxkL21vZHVsZXMudHh0PiBhbmQKKwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9zY3Np
LnR4dD4uIFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgY2guby4KKwkgIElmIHVuc3VyZSwgc2F5
IE4uCisKK2NvbmZpZyBTQ1NJX0VOQ0xPU1VSRQorCXRyaXN0YXRlICJTQ1NJIEVuY2xvc3VyZSBT
dXBwb3J0IgorCWRlcGVuZHMgb24gU0NTSSAmJiBFTkNMT1NVUkVfU0VSVklDRVMKKwloZWxwCisJ
ICBFbmNsb3N1cmVzIGFyZSBkZXZpY2VzIHNpdHRpbmcgb24gb3IgaW4gU0NTSSBiYWNrcGxhbmVz
IHRoYXQKKwkgIG1hbmFnZSBkZXZpY2VzLiAgSWYgeW91IGhhdmUgYSBkaXNrIGNhZ2UsIHRoZSBj
aGFuY2VzIGFyZSB0aGF0CisJICBpdCBoYXMgYW4gZW5jbG9zdXJlIGRldmljZS4gIFNlbGVjdGlu
ZyB0aGlzIG9wdGlvbiB3aWxsIGp1c3QgYWxsb3cKKwkgIGNlcnRhaW4gZW5jbG9zdXJlIGNvbmRp
dGlvbnMgdG8gYmUgcmVwb3J0ZWQgYW5kIGlzIG5vdCByZXF1aXJlZC4KKworY29uZmlnIFNDU0lf
TVVMVElfTFVOCisJYm9vbCAiUHJvYmUgYWxsIExVTnMgb24gZWFjaCBTQ1NJIGRldmljZSIKKwlk
ZXBlbmRzIG9uIFNDU0kKKwloZWxwCisJICBTb21lIGRldmljZXMgc3VwcG9ydCBtb3JlIHRoYW4g
b25lIExVTiAoTG9naWNhbCBVbml0IE51bWJlcikgaW4gb3JkZXIKKwkgIHRvIGFsbG93IGFjY2Vz
cyB0byBzZXZlcmFsIG1lZGlhLCBlLmcuIENEIGp1a2Vib3gsIFVTQiBjYXJkIHJlYWRlciwKKwkg
IG1vYmlsZSBwaG9uZSBpbiBtYXNzIHN0b3JhZ2UgbW9kZS4gVGhpcyBvcHRpb24gZm9yY2VzIHRo
ZSBrZXJuZWwgdG8KKwkgIHByb2JlIGZvciBhbGwgTFVOcyBieSBkZWZhdWx0LiBUaGlzIHNldHRp
bmcgY2FuIGJlIG92ZXJyaWRlbiBieQorCSAgbWF4X2x1bnMgYm9vdC9tb2R1bGUgcGFyYW1ldGVy
LiBOb3RlIHRoYXQgdGhpcyBvcHRpb24gZG9lcyBub3QgYWZmZWN0CisJICBkZXZpY2VzIGNvbmZv
cm1pbmcgdG8gU0NTSS0zIG9yIGhpZ2hlciBhcyB0aGV5IGNhbiBleHBsaWNpdGVseSByZXBvcnQK
KwkgIHRoZWlyIG51bWJlciBvZiBMVU5zLiBJdCBpcyBzYWZlIHRvIHNheSBZIGhlcmUgdW5sZXNz
IHlvdSBoYXZlIG9uZSBvZgorCSAgdGhvc2UgcmFyZSBkZXZpY2VzIHdoaWNoIHJlYWN0cyBpbiBh
biB1bmV4cGVjdGVkIHdheSB3aGVuIHByb2JlZCBmb3IKKwkgIG11bHRpcGxlIExVTnMuCisKK2Nv
bmZpZyBTQ1NJX0NPTlNUQU5UUworCWJvb2wgIlZlcmJvc2UgU0NTSSBlcnJvciByZXBvcnRpbmcg
KGtlcm5lbCBzaXplICs9MTJLKSIKKwlkZXBlbmRzIG9uIFNDU0kKKwloZWxwCisJICBUaGUgZXJy
b3IgbWVzc2FnZXMgcmVnYXJkaW5nIHlvdXIgU0NTSSBoYXJkd2FyZSB3aWxsIGJlIGVhc2llciB0
bworCSAgdW5kZXJzdGFuZCBpZiB5b3Ugc2F5IFkgaGVyZTsgaXQgd2lsbCBlbmxhcmdlIHlvdXIg
a2VybmVsIGJ5IGFib3V0CisJICAxMiBLQi4gSWYgaW4gZG91YnQsIHNheSBZLgorCitjb25maWcg
U0NTSV9MT0dHSU5HCisJYm9vbCAiU0NTSSBsb2dnaW5nIGZhY2lsaXR5IgorCWRlcGVuZHMgb24g
U0NTSQorCS0tLWhlbHAtLS0KKwkgIFRoaXMgdHVybnMgb24gYSBsb2dnaW5nIGZhY2lsaXR5IHRo
YXQgY2FuIGJlIHVzZWQgdG8gZGVidWcgYSBudW1iZXIKKwkgIG9mIFNDU0kgcmVsYXRlZCBwcm9i
bGVtcy4KKworCSAgSWYgeW91IHNheSBZIGhlcmUsIG5vIGxvZ2dpbmcgb3V0cHV0IHdpbGwgYXBw
ZWFyIGJ5IGRlZmF1bHQsIGJ1dCB5b3UKKwkgIGNhbiBlbmFibGUgbG9nZ2luZyBieSBzYXlpbmcg
WSB0byAiL3Byb2MgZmlsZSBzeXN0ZW0gc3VwcG9ydCIgYW5kCisJICAiU3lzY3RsIHN1cHBvcnQi
IGJlbG93IGFuZCBleGVjdXRpbmcgdGhlIGNvbW1hbmQKKworCSAgZWNobyA8Yml0bWFzaz4gPiAv
cHJvYy9zeXMvZGV2L3Njc2kvbG9nZ2luZ19sZXZlbAorCisJICB3aGVyZSA8Yml0bWFzaz4gaXMg
YSBmb3VyIGJ5dGUgdmFsdWUgcmVwcmVzZW50aW5nIHRoZSBsb2dnaW5nIHR5cGUKKwkgIGFuZCBs
b2dnaW5nIGxldmVsIGZvciBlYWNoIHR5cGUgb2YgbG9nZ2luZyBzZWxlY3RlZC4KKworCSAgVGhl
cmUgYXJlIGEgbnVtYmVyIG9mIGxvZ2dpbmcgdHlwZXMgYW5kIHlvdSBjYW4gZmluZCB0aGVtIGlu
IHRoZQorCSAgc291cmNlIGF0IDxmaWxlOmRyaXZlcnMvc2NzaS9zY3NpX2xvZ2dpbmcuaD4uIFRo
ZSBsb2dnaW5nIGxldmVscworCSAgYXJlIGFsc28gZGVzY3JpYmVkIGluIHRoYXQgZmlsZSBhbmQg
dGhleSBkZXRlcm1pbmUgdGhlIHZlcmJvc2l0eSBvZgorCSAgdGhlIGxvZ2dpbmcgZm9yIGVhY2gg
bG9nZ2luZyB0eXBlLgorCisJICBJZiB5b3Ugc2F5IE4gaGVyZSwgaXQgbWF5IGJlIGhhcmRlciB0
byB0cmFjayBkb3duIHNvbWUgdHlwZXMgb2YgU0NTSQorCSAgcHJvYmxlbXMuIElmIHlvdSBzYXkg
WSBoZXJlIHlvdXIga2VybmVsIHdpbGwgYmUgc29tZXdoYXQgbGFyZ2VyLCBidXQKKwkgIHRoZXJl
IHNob3VsZCBiZSBubyBub3RpY2VhYmxlIHBlcmZvcm1hbmNlIGltcGFjdCBhcyBsb25nIGFzIHlv
dSBoYXZlCisJICBsb2dnaW5nIHR1cm5lZCBvZmYuCisKK2NvbmZpZyBTQ1NJX1NDQU5fQVNZTkMK
Kwlib29sICJBc3luY2hyb25vdXMgU0NTSSBzY2FubmluZyIKKwlkZXBlbmRzIG9uIFNDU0kKKwlo
ZWxwCisJICBUaGUgU0NTSSBzdWJzeXN0ZW0gY2FuIHByb2JlIGZvciBkZXZpY2VzIHdoaWxlIHRo
ZSByZXN0IG9mIHRoZQorCSAgc3lzdGVtIGNvbnRpbnVlcyBib290aW5nLCBhbmQgZXZlbiBwcm9i
ZSBkZXZpY2VzIG9uIGRpZmZlcmVudAorCSAgYnVzc2VzIGluIHBhcmFsbGVsLCBsZWFkaW5nIHRv
IGEgc2lnbmlmaWNhbnQgc3BlZWQtdXAuCisKKwkgIElmIHlvdSBoYXZlIGJ1aWx0IFNDU0kgYXMg
bW9kdWxlcywgZW5hYmxpbmcgdGhpcyBvcHRpb24gY2FuCisJICBiZSBhIHByb2JsZW0gYXMgdGhl
IGRldmljZXMgbWF5IG5vdCBoYXZlIGJlZW4gZm91bmQgYnkgdGhlCisJICB0aW1lIHlvdXIgc3lz
dGVtIGV4cGVjdHMgdGhlbSB0byBoYXZlIGJlZW4uICBZb3UgY2FuIGxvYWQgdGhlCisJICBzY3Np
X3dhaXRfc2NhbiBtb2R1bGUgdG8gZW5zdXJlIHRoYXQgYWxsIHNjYW5zIGhhdmUgY29tcGxldGVk
LgorCSAgSWYgeW91IGJ1aWxkIHlvdXIgU0NTSSBkcml2ZXJzIGludG8gdGhlIGtlcm5lbCwgdGhl
biBldmVyeXRoaW5nCisJICB3aWxsIHdvcmsgZmluZSBpZiB5b3Ugc2F5IFkgaGVyZS4KKworCSAg
WW91IGNhbiBvdmVycmlkZSB0aGlzIGNob2ljZSBieSBzcGVjaWZ5aW5nICJzY3NpX21vZC5zY2Fu
PXN5bmMiCisJICBvciBhc3luYyBvbiB0aGUga2VybmVsJ3MgY29tbWFuZCBsaW5lLgorCitjb25m
aWcgU0NTSV9XQUlUX1NDQU4KKwl0cmlzdGF0ZSAgIyBObyBwcm9tcHQgaGVyZSwgdGhpcyBpcyBh
biBpbnZpc2libGUgc3ltYm9sLgorCWRlZmF1bHQgbQorCWRlcGVuZHMgb24gU0NTSQorCWRlcGVu
ZHMgb24gTU9EVUxFUworIyBzY3NpX3dhaXRfc2NhbiBpcyBhIGxvYWRhYmxlIG1vZHVsZSB3aGlj
aCB3YWl0cyB1bnRpbCBhbGwgdGhlIGFzeW5jIHNjYW5zIGFyZQorIyBjb21wbGV0ZS4gIFRoZSBp
ZGVhIGlzIHRvIHVzZSBpdCBpbiBpbml0cmQvIGluaXRyYW1mcyBzY3JpcHRzLiAgWW91IG1vZHBy
b2JlCisjIGl0IGFmdGVyIGFsbCB0aGUgbW9kcHJvYmVzIG9mIHRoZSByb290IFNDU0kgZHJpdmVy
cyBhbmQgaXQgd2lsbCB3YWl0IHVudGlsCisjIHRoZXkgaGF2ZSBhbGwgZmluaXNoZWQgc2Nhbm5p
bmcgdGhlaXIgYnVzZXMgYmVmb3JlIGFsbG93aW5nIHRoZSBib290IHRvCisjIHByb2NlZWQuICAo
VGhpcyBtZXRob2QgaXMgbm90IGFwcGxpY2FibGUgaWYgdGFyZ2V0cyBib290IGluZGVwZW5kZW50
bHkgaW4KKyMgcGFyYWxsZWwgd2l0aCB0aGUgaW5pdGlhdG9yLCBvciB3aXRoIHRyYW5zcG9ydHMg
d2l0aCBub24tZGV0ZXJtaW5pc3RpYyB0YXJnZXQKKyMgZGlzY292ZXJ5IHNjaGVtZXMsIG9yIGlm
IGEgdHJhbnNwb3J0IGRyaXZlciBkb2VzIG5vdCBzdXBwb3J0IHNjc2lfd2FpdF9zY2FuLikKKyMK
KyMgVGhpcyBzeW1ib2wgaXMgbm90IGV4cG9zZWQgYXMgYSBwcm9tcHQgYmVjYXVzZSBsaXR0bGUg
aXMgdG8gYmUgZ2FpbmVkIGJ5CisjIGRpc2FibGluZyBpdCwgd2hlcmVhcyBwZW9wbGUgd2hvIGFj
Y2lkZW50YWxseSBzd2l0Y2ggaXQgb2ZmIG1heSB3b25kZXIgd2h5CisjIHRoZWlyIG1raW5pdHJk
IGdldHMgaW50byB0cm91YmxlLgorCittZW51ICJTQ1NJIFRyYW5zcG9ydHMiCisJZGVwZW5kcyBv
biBTQ1NJCisKK2NvbmZpZyBTQ1NJX1NQSV9BVFRSUworCXRyaXN0YXRlICJQYXJhbGxlbCBTQ1NJ
IChTUEkpIFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSQorCWhlbHAKKwkg
IElmIHlvdSB3aXNoIHRvIGV4cG9ydCB0cmFuc3BvcnQtc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJv
dXQKKwkgIGVhY2ggYXR0YWNoZWQgU0NTSSBkZXZpY2UgdG8gc3lzZnMsIHNheSBZLiAgT3RoZXJ3
aXNlLCBzYXkgTi4KKworY29uZmlnIFNDU0lfRkNfQVRUUlMKKwl0cmlzdGF0ZSAiRmliZXJDaGFu
bmVsIFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSQorCXNlbGVjdCBTQ1NJ
X05FVExJTksKKwloZWxwCisJICBJZiB5b3Ugd2lzaCB0byBleHBvcnQgdHJhbnNwb3J0LXNwZWNp
ZmljIGluZm9ybWF0aW9uIGFib3V0CisJICBlYWNoIGF0dGFjaGVkIEZpYmVyQ2hhbm5lbCBkZXZp
Y2UgdG8gc3lzZnMsIHNheSBZLgorCSAgT3RoZXJ3aXNlLCBzYXkgTi4KKworY29uZmlnIFNDU0lf
RkNfVEdUX0FUVFJTCisJYm9vbCAiU0NTSSB0YXJnZXQgc3VwcG9ydCBmb3IgRmliZXJDaGFubmVs
IFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSV9GQ19BVFRSUworCWRlcGVu
ZHMgb24gU0NTSV9UR1QgPSB5IHx8IFNDU0lfVEdUID0gU0NTSV9GQ19BVFRSUworCWhlbHAKKwkJ
SWYgeW91IHdhbnQgdG8gdXNlIFNDU0kgdGFyZ2V0IG1vZGUgZHJpdmVycyBlbmFibGUgdGhpcyBv
cHRpb24uCisKK2NvbmZpZyBTQ1NJX0lTQ1NJX0FUVFJTCisJdHJpc3RhdGUgImlTQ1NJIFRyYW5z
cG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSSAmJiBORVQKKwlzZWxlY3QgQkxLX0RF
Vl9CU0dMSUIKKwloZWxwCisJICBJZiB5b3Ugd2lzaCB0byBleHBvcnQgdHJhbnNwb3J0LXNwZWNp
ZmljIGluZm9ybWF0aW9uIGFib3V0CisJICBlYWNoIGF0dGFjaGVkIGlTQ1NJIGRldmljZSB0byBz
eXNmcywgc2F5IFkuCisJICBPdGhlcndpc2UsIHNheSBOLgorCitjb25maWcgU0NTSV9TQVNfQVRU
UlMKKwl0cmlzdGF0ZSAiU0FTIFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NT
SQorCXNlbGVjdCBCTEtfREVWX0JTRworCWhlbHAKKwkgIElmIHlvdSB3aXNoIHRvIGV4cG9ydCB0
cmFuc3BvcnQtc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQKKwkgIGVhY2ggYXR0YWNoZWQgU0FT
IGRldmljZSB0byBzeXNmcywgc2F5IFkuCisKK3NvdXJjZSAiZHJpdmVycy9zY3NpL2xpYnNhcy9L
Y29uZmlnIgorCitjb25maWcgU0NTSV9TUlBfQVRUUlMKKwl0cmlzdGF0ZSAiU1JQIFRyYW5zcG9y
dCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSQorCWhlbHAKKwkgIElmIHlvdSB3aXNoIHRv
IGV4cG9ydCB0cmFuc3BvcnQtc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQKKwkgIGVhY2ggYXR0
YWNoZWQgU1JQIGRldmljZSB0byBzeXNmcywgc2F5IFkuCisKK2NvbmZpZyBTQ1NJX1NSUF9UR1Rf
QVRUUlMKKwlib29sICJTQ1NJIHRhcmdldCBzdXBwb3J0IGZvciBTUlAgVHJhbnNwb3J0IEF0dHJp
YnV0ZXMiCisJZGVwZW5kcyBvbiBTQ1NJX1NSUF9BVFRSUworCWRlcGVuZHMgb24gU0NTSV9UR1Qg
PSB5IHx8IFNDU0lfVEdUID0gU0NTSV9TUlBfQVRUUlMKKwloZWxwCisJCUlmIHlvdSB3YW50IHRv
IHVzZSBTQ1NJIHRhcmdldCBtb2RlIGRyaXZlcnMgZW5hYmxlIHRoaXMgb3B0aW9uLgorCitlbmRt
ZW51CisKK21lbnVjb25maWcgU0NTSV9MT1dMRVZFTAorCWJvb2wgIlNDU0kgbG93LWxldmVsIGRy
aXZlcnMiCisJZGVwZW5kcyBvbiBTQ1NJIT1uCisJZGVmYXVsdCB5CisKK2lmIFNDU0lfTE9XTEVW
RUwgJiYgU0NTSQorCitjb25maWcgSVNDU0lfVENQCisJdHJpc3RhdGUgImlTQ1NJIEluaXRpYXRv
ciBvdmVyIFRDUC9JUCIKKwlkZXBlbmRzIG9uIFNDU0kgJiYgSU5FVAorCXNlbGVjdCBDUllQVE8K
KwlzZWxlY3QgQ1JZUFRPX01ENQorCXNlbGVjdCBDUllQVE9fQ1JDMzJDCisJc2VsZWN0IFNDU0lf
SVNDU0lfQVRUUlMKKwloZWxwCisJIFRoZSBpU0NTSSBEcml2ZXIgcHJvdmlkZXMgYSBob3N0IHdp
dGggdGhlIGFiaWxpdHkgdG8gYWNjZXNzIHN0b3JhZ2UKKwkgdGhyb3VnaCBhbiBJUCBuZXR3b3Jr
LiBUaGUgZHJpdmVyIHVzZXMgdGhlIGlTQ1NJIHByb3RvY29sIHRvIHRyYW5zcG9ydAorCSBTQ1NJ
IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgb3ZlciBhIFRDUC9JUCBuZXR3b3JrIGJldHdlZW4gdGhl
IGhvc3QKKwkgKHRoZSAiaW5pdGlhdG9yIikgYW5kICJ0YXJnZXRzIi4gIEFyY2hpdGVjdHVyYWxs
eSwgdGhlIGlTQ1NJIGRyaXZlcgorCSBjb21iaW5lcyB3aXRoIHRoZSBob3N0J3MgVENQL0lQIHN0
YWNrLCBuZXR3b3JrIGRyaXZlcnMsIGFuZCBOZXR3b3JrCisJIEludGVyZmFjZSBDYXJkIChOSUMp
IHRvIHByb3ZpZGUgdGhlIHNhbWUgZnVuY3Rpb25zIGFzIGEgU0NTSSBvciBhCisJIEZpYnJlIENo
YW5uZWwgKEZDKSBhZGFwdGVyIGRyaXZlciB3aXRoIGEgSG9zdCBCdXMgQWRhcHRlciAoSEJBKS4K
KworCSBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0
aGUKKwkgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGlzY3NpX3RjcC4KKworCSBUaGUgdXNlcnNwYWNl
IGNvbXBvbmVudCBuZWVkZWQgdG8gaW5pdGlhbGl6ZSB0aGUgZHJpdmVyLCBkb2N1bWVudGF0aW9u
LAorCSBhbmQgc2FtcGxlIGNvbmZpZ3VyYXRpb24gZmlsZXMgY2FuIGJlIGZvdW5kIGhlcmU6CisK
KwkgaHR0cDovL29wZW4taXNjc2kub3JnCisKK2NvbmZpZyBJU0NTSV9CT09UX1NZU0ZTCisJdHJp
c3RhdGUgImlTQ1NJIEJvb3QgU3lzZnMgSW50ZXJmYWNlIgorCWRlZmF1bHQJbgorCWhlbHAKKwkg
IFRoaXMgb3B0aW9uIGVuYWJsZXMgc3VwcG9ydCBmb3IgZXhwb3NpbmcgaVNDU0kgYm9vdCBpbmZv
cm1hdGlvbgorCSAgdmlhIHN5c2ZzIHRvIHVzZXJzcGFjZS4gSWYgeW91IHdpc2ggdG8gZXhwb3J0
IHRoaXMgaW5mb3JtYXRpb24sCisJICBzYXkgWS4gT3RoZXJ3aXNlLCBzYXkgTi4KKworc291cmNl
ICJkcml2ZXJzL3Njc2kvY3hnYmkvS2NvbmZpZyIKK3NvdXJjZSAiZHJpdmVycy9zY3NpL2JueDJp
L0tjb25maWciCitzb3VyY2UgImRyaXZlcnMvc2NzaS9ibngyZmMvS2NvbmZpZyIKK3NvdXJjZSAi
ZHJpdmVycy9zY3NpL2JlMmlzY3NpL0tjb25maWciCisKK2NvbmZpZyBTR0lXRDkzX1NDU0kKKwl0
cmlzdGF0ZSAiU0dJIFdEOTNDOTMgU0NTSSBEcml2ZXIiCisJZGVwZW5kcyBvbiBTR0lfSEFTX1dE
OTMgJiYgU0NTSQorICAJaGVscAorCSAgSWYgeW91IGhhdmUgYSBXZXN0ZXJuIERpZ2l0YWwgV0Q5
MyBTQ1NJIGNvbnRyb2xsZXIgb24KKwkgIGFuIFNHSSBNSVBTIHN5c3RlbSwgc2F5IFkuICBPdGhl
cndpc2UsIHNheSBOLgorCitjb25maWcgQkxLX0RFVl8zV19YWFhYX1JBSUQKKwl0cmlzdGF0ZSAi
M3dhcmUgNS82LzcvOHh4eCBBVEEtUkFJRCBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFND
U0kKKwloZWxwCisJICAzd2FyZSBpcyB0aGUgb25seSBoYXJkd2FyZSBBVEEtUmFpZCBwcm9kdWN0
IGluIExpbnV4IHRvIGRhdGUuCisJICBUaGlzIGNhcmQgaXMgMiw0LCBvciA4IGNoYW5uZWwgbWFz
dGVyIG1vZGUgc3VwcG9ydCBvbmx5LgorCSAgU0NTSSBzdXBwb3J0IHJlcXVpcmVkISEhCisKKwkg
IDxodHRwOi8vd3d3LjN3YXJlLmNvbS8+CisKKwkgIFBsZWFzZSByZWFkIHRoZSBjb21tZW50cyBh
dCB0aGUgdG9wIG9mCisJICA8ZmlsZTpkcml2ZXJzL3Njc2kvM3cteHh4eC5jPi4KKworY29uZmln
IFNDU0lfSFBTQQorCXRyaXN0YXRlICJIUCBTbWFydCBBcnJheSBTQ1NJIGRyaXZlciIKKwlkZXBl
bmRzIG9uIFBDSSAmJiBTQ1NJCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgSFAgU21h
cnQgQXJyYXkgQ29udHJvbGxlcnMgKGNpcmNhIDIwMDkpLgorCSAgSXQgaXMgYSBTQ1NJIGFsdGVy
bmF0aXZlIHRvIHRoZSBjY2lzcyBkcml2ZXIsIHdoaWNoIGlzIGEgYmxvY2sKKwkgIGRyaXZlci4g
IEFueW9uZSB3aXNoaW5nIHRvIHVzZSBIUCBTbWFydCBBcnJheSBjb250cm9sbGVycyB3aG8KKwkg
IHdvdWxkIHByZWZlciB0aGUgZGV2aWNlcyBiZSBwcmVzZW50ZWQgdG8gbGludXggYXMgU0NTSSBk
ZXZpY2VzLAorCSAgcmF0aGVyIHRoYW4gYXMgZ2VuZXJpYyBibG9jayBkZXZpY2VzIHNob3VsZCBz
YXkgWSBoZXJlLgorCitjb25maWcgU0NTSV8zV185WFhYCisJdHJpc3RhdGUgIjN3YXJlIDl4eHgg
U0FUQS1SQUlEIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhlbHAKKwkgIFRo
aXMgZHJpdmVyIHN1cHBvcnRzIHRoZSA5MDAwIHNlcmllcyAzd2FyZSBTQVRBLVJBSUQgY2FyZHMu
CisKKwkgIDxodHRwOi8vd3d3LmFtY2MuY29tPgorCisJICBQbGVhc2UgcmVhZCB0aGUgY29tbWVu
dHMgYXQgdGhlIHRvcCBvZgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpLzN3LTl4eHguYz4uCisKK2Nv
bmZpZyBTQ1NJXzNXX1NBUworCXRyaXN0YXRlICIzd2FyZSA5N3h4IFNBUy9TQVRBLVJBSUQgc3Vw
cG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3Vw
cG9ydHMgdGhlIExTSSAzd2FyZSA5NzUwIDZHYi9zIFNBUy9TQVRBLVJBSUQgY2FyZHMuCisKKwkg
IDxodHRwOi8vd3d3LmxzaS5jb20+CisKKwkgIFBsZWFzZSByZWFkIHRoZSBjb21tZW50cyBhdCB0
aGUgdG9wIG9mCisJICA8ZmlsZTpkcml2ZXJzL3Njc2kvM3ctc2FzLmM+LgorCitjb25maWcgU0NT
SV83MDAwRkFTU1QKKwl0cmlzdGF0ZSAiNzAwMEZBU1NUIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRz
IG9uIElTQSAmJiBTQ1NJICYmIElTQV9ETUFfQVBJCisJc2VsZWN0IENIRUNLX1NJR05BVFVSRQor
CWhlbHAKKwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIHRoZSBXZXN0ZXJuIERpZ2l0YWwgNzAwMCBT
Q1NJIGhvc3QgYWRhcHRlcgorCSAgZmFtaWx5LiAgU29tZSBpbmZvcm1hdGlvbiBpcyBpbiB0aGUg
c291cmNlOgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpL3dkNzAwMC5jPi4KKworCSAgVG8gY29tcGls
ZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUg
d2lsbCBiZSBjYWxsZWQgd2Q3MDAwLgorCitjb25maWcgU0NTSV9BQ0FSRAorCXRyaXN0YXRlICJB
Q0FSRCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhlbHAKKwkgIFRo
aXMgZHJpdmVyIHN1cHBvcnRzIHRoZSBBQ0FSRCBTQ1NJIGhvc3QgYWRhcHRlci4KKwkgIFN1cHBv
cnQgQ2hpcCA8QVRQODcwIEFUUDg3NiBBVFA4ODAgQVRQODg1PgorCSAgVG8gY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBi
ZSBjYWxsZWQgYXRwODcwdS4KKworY29uZmlnIFNDU0lfQUhBMTUyWAorCXRyaXN0YXRlICJBZGFw
dGVjIEFIQTE1MlgvMjgyNSBzdXBwb3J0IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kgJiYgITY0
QklUCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJc2VsZWN0IENIRUNLX1NJR05BVFVSRQorCS0t
LWhlbHAtLS0KKwkgIFRoaXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBBSEEtMTUxMCwgQUhBLTE1MjAs
IEFIQS0xNTIyLCBhbmQgQUhBLTI4MjUKKwkgIFNDU0kgaG9zdCBhZGFwdGVycy4gSXQgYWxzbyB3
b3JrcyBmb3IgdGhlIEFWQS0xNTA1LCBidXQgdGhlIElSUSBldGMuCisJICBtdXN0IGJlIG1hbnVh
bGx5IHNwZWNpZmllZCBpbiB0aGlzIGNhc2UuCisKKwkgIEl0IGlzIGV4cGxhaW5lZCBpbiBzZWN0
aW9uIDMuMyBvZiB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3
LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4uIFlvdSBtaWdodCBhbHNvIHdhbnQgdG8KKwkgIHJl
YWQgdGhlIGZpbGUgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL2FoYTE1MngudHh0Pi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYWhhMTUyeC4KKworY29uZmlnIFNDU0lfQUhBMTU0Mgor
CXRyaXN0YXRlICJBZGFwdGVjIEFIQTE1NDIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIElTQSAmJiBT
Q1NJICYmIElTQV9ETUFfQVBJCisJLS0taGVscC0tLQorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciBh
IFNDU0kgaG9zdCBhZGFwdGVyLiAgSXQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24KKwkgIDMuNCBv
ZiB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3Jn
L2RvY3MuaHRtbCNob3d0bz4uICBOb3RlIHRoYXQgVHJhbnRvciB3YXMKKwkgIHB1cmNoYXNlZCBi
eSBBZGFwdGVjLCBhbmQgc29tZSBmb3JtZXIgVHJhbnRvciBwcm9kdWN0cyBhcmUgYmVpbmcKKwkg
IHNvbGQgdW5kZXIgdGhlIEFkYXB0ZWMgbmFtZS4gIElmIGl0IGRvZXNuJ3Qgd29yayBvdXQgb2Yg
dGhlIGJveCwgeW91CisJICBtYXkgaGF2ZSB0byBjaGFuZ2Ugc29tZSBzZXR0aW5ncyBpbiA8Zmls
ZTpkcml2ZXJzL3Njc2kvYWhhMTU0Mi5oPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBh
cyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQg
YWhhMTU0Mi4KKworY29uZmlnIFNDU0lfQUhBMTc0MAorCXRyaXN0YXRlICJBZGFwdGVjIEFIQTE3
NDAgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIEVJU0EgJiYgU0NTSQorCS0tLWhlbHAtLS0KKwkgIFRo
aXMgaXMgc3VwcG9ydCBmb3IgYSBTQ1NJIGhvc3QgYWRhcHRlci4gIEl0IGlzIGV4cGxhaW5lZCBp
biBzZWN0aW9uCisJICAzLjUgb2YgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8
aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiAgSWYgaXQgZG9lc24ndCB3b3Jr
IG91dAorCSAgb2YgdGhlIGJveCwgeW91IG1heSBoYXZlIHRvIGNoYW5nZSBzb21lIHNldHRpbmdz
IGluCisJICA8ZmlsZTpkcml2ZXJzL3Njc2kvYWhhMTc0MC5oPi4KKworCSAgVG8gY29tcGlsZSB0
aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2ls
bCBiZSBjYWxsZWQgYWhhMTc0MC4KKworY29uZmlnIFNDU0lfQUFDUkFJRAorCXRyaXN0YXRlICJB
ZGFwdGVjIEFBQ1JBSUQgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0kgJiYgUENJCisJaGVscAor
CSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgYSB2YXJpZXR5IG9mIERlbGwsIEhQLCBBZGFwdGVjLCBJ
Qk0gYW5kCisJICBJQ1Agc3RvcmFnZSBwcm9kdWN0cy4gRm9yIGEgbGlzdCBvZiBzdXBwb3J0ZWQg
cHJvZHVjdHMsIHJlZmVyCisJICB0byA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvYWFjcmFpZC50
eHQ+LgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBo
ZXJlOiB0aGUgbW9kdWxlCisJICB3aWxsIGJlIGNhbGxlZCBhYWNyYWlkLgorCisKK3NvdXJjZSAi
ZHJpdmVycy9zY3NpL2FpYzd4eHgvS2NvbmZpZy5haWM3eHh4IgorCitjb25maWcgU0NTSV9BSUM3
WFhYX09MRAorCXRyaXN0YXRlICJBZGFwdGVjIEFJQzd4eHggc3VwcG9ydCAob2xkIGRyaXZlciki
CisJZGVwZW5kcyBvbiAoSVNBIHx8IEVJU0EgfHwgUENJICkgJiYgU0NTSQorCWhlbHAKKwkgIFdB
Uk5JTkcgVGhpcyBkcml2ZXIgaXMgYW4gb2xkZXIgYWljN3h4eCBkcml2ZXIgYW5kIGlzIG5vIGxv
bmdlcgorCSAgdW5kZXIgYWN0aXZlIGRldmVsb3BtZW50LiAgQWRhcHRlYywgSW5jLiBpcyB3cml0
aW5nIGEgbmV3IGRyaXZlciB0bworCSAgdGFrZSB0aGUgcGxhY2Ugb2YgdGhpcyBvbmUsIGFuZCBp
dCBpcyByZWNvbW1lbmRlZCB0aGF0IHdoZW5ldmVyCisJICBwb3NzaWJsZSwgcGVvcGxlIHNob3Vs
ZCB1c2UgdGhlIG5ldyBBZGFwdGVjIHdyaXR0ZW4gZHJpdmVyIGluc3RlYWQKKwkgIG9mIHRoaXMg
b25lLiAgVGhpcyBkcml2ZXIgd2lsbCBldmVudHVhbGx5IGJlIHBoYXNlZCBvdXQgZW50aXJlbHku
CisKKwkgIFRoaXMgaXMgc3VwcG9ydCBmb3IgdGhlIHZhcmlvdXMgYWljN3h4eCBiYXNlZCBBZGFw
dGVjIFNDU0kKKwkgIGNvbnRyb2xsZXJzLiBUaGVzZSBpbmNsdWRlIHRoZSAyNzR4IEVJU0EgY2Fy
ZHM7IDI4NHggVkxCIGNhcmRzOworCSAgMjkwMiwgMjkxMCwgMjkzeCwgMjk0eCwgMzk0eCwgMzk4
NSBhbmQgc2V2ZXJhbCBvdGhlciBQQ0kgYW5kCisJICBtb3RoZXJib2FyZCBiYXNlZCBTQ1NJIGNv
bnRyb2xsZXJzIGZyb20gQWRhcHRlYy4gSXQgZG9lcyBub3Qgc3VwcG9ydAorCSAgdGhlIEFBQS0x
M3ggUkFJRCBjb250cm9sbGVycyBmcm9tIEFkYXB0ZWMsIG5vciB3aWxsIGl0IGxpa2VseSBldmVy
CisJICBzdXBwb3J0IHRoZW0uIEl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIDI5MjAgY2FyZHMgZnJv
bSBBZGFwdGVjIHRoYXQKKwkgIHVzZSB0aGUgRnV0dXJlIERvbWFpbiBTQ1NJIGNvbnRyb2xsZXIg
Y2hpcC4gRm9yIHRob3NlIGNhcmRzLCB5b3UKKwkgIG5lZWQgdGhlICJGdXR1cmUgRG9tYWluIDE2
eHggU0NTSSBzdXBwb3J0IiBkcml2ZXIuCisKKwkgIEluIGdlbmVyYWwsIGlmIHRoZSBjb250cm9s
bGVyIGlzIGJhc2VkIG9uIGFuIEFkYXB0ZWMgU0NTSSBjb250cm9sbGVyCisJICBjaGlwIGZyb20g
dGhlIGFpYzc3N3ggc2VyaWVzIG9yIHRoZSBhaWM3OHh4IHNlcmllcywgdGhpcyBkcml2ZXIKKwkg
IHNob3VsZCB3b3JrLiBUaGUgb25seSBleGNlcHRpb24gaXMgdGhlIDc4MTAgd2hpY2ggaXMgc3Bl
Y2lmaWNhbGx5CisJICBub3Qgc3VwcG9ydGVkICh0aGF0J3MgdGhlIFJBSUQgY29udHJvbGxlciBj
aGlwIG9uIHRoZSBBQUEtMTN4CisJICBjYXJkcykuCisKKwkgIE5vdGUgdGhhdCB0aGUgQUhBMjky
MCBTQ1NJIGhvc3QgYWRhcHRlciBpcyAqbm90KiBzdXBwb3J0ZWQgYnkgdGhpcworCSAgZHJpdmVy
OyBjaG9vc2UgIkZ1dHVyZSBEb21haW4gMTZ4eCBTQ1NJIHN1cHBvcnQiIGluc3RlYWQgaWYgeW91
IGhhdmUKKwkgIG9uZSBvZiB0aG9zZS4KKworCSAgSW5mb3JtYXRpb24gb24gdGhlIGNvbmZpZ3Vy
YXRpb24gb3B0aW9ucyBmb3IgdGhpcyBjb250cm9sbGVyIGNhbiBiZQorCSAgZm91bmQgYnkgY2hl
Y2tpbmcgdGhlIGhlbHAgZmlsZSBmb3IgZWFjaCBvZiB0aGUgYXZhaWxhYmxlCisJICBjb25maWd1
cmF0aW9uIG9wdGlvbnMuIFlvdSBzaG91bGQgcmVhZAorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9z
Y3NpL2FpYzd4eHhfb2xkLnR4dD4gYXQgYSBtaW5pbXVtIGJlZm9yZQorCSAgY29udGFjdGluZyB0
aGUgbWFpbnRhaW5lciB3aXRoIGFueSBxdWVzdGlvbnMuICBUaGUgU0NTSS1IT1dUTywKKwkgIGF2
YWlsYWJsZSBmcm9tIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4sIGNhbiBh
bHNvCisJICBiZSBvZiBncmVhdCBoZWxwLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFz
IGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBh
aWM3eHh4X29sZC4KKworc291cmNlICJkcml2ZXJzL3Njc2kvYWljN3h4eC9LY29uZmlnLmFpYzc5
eHgiCitzb3VyY2UgImRyaXZlcnMvc2NzaS9haWM5NHh4L0tjb25maWciCitzb3VyY2UgImRyaXZl
cnMvc2NzaS9tdnNhcy9LY29uZmlnIgorCitjb25maWcgU0NTSV9NVlVNSQorCXRyaXN0YXRlICJN
YXJ2ZWxsIFVNSSBkcml2ZXIiCisJZGVwZW5kcyBvbiBTQ1NJICYmIFBDSQorCWhlbHAKKwkgIE1v
ZHVsZSBmb3IgTWFydmVsbCBVbml2ZXJzYWwgTWVzc2FnZSBJbnRlcmZhY2UoVU1JKSBkcml2ZXIK
KworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTog
dGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgbXZ1bWkuCisKK2NvbmZpZyBTQ1NJX0RQVF9J
Mk8KKwl0cmlzdGF0ZSAiQWRhcHRlYyBJMk8gUkFJRCBzdXBwb3J0ICIKKwlkZXBlbmRzIG9uIFND
U0kgJiYgUENJICYmIFZJUlRfVE9fQlVTCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMg
YWxsIG9mIEFkYXB0ZWMncyBJMk8gYmFzZWQgUkFJRCBjb250cm9sbGVycyBhcyAKKwkgIHdlbGwg
YXMgdGhlIERQVCBTbWFydFJhaWQgViBjYXJkcy4gIFRoaXMgaXMgYW4gQWRhcHRlYyBtYWludGFp
bmVkCisJICBkcml2ZXIgYnkgRGVhbm5hIEJvbmRzLiAgU2VlIDxmaWxlOkRvY3VtZW50YXRpb24v
c2NzaS9kcHRpLnR4dD4uCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUs
IGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGRwdF9pMm8uCisK
K2NvbmZpZyBTQ1NJX0FEVkFOU1lTCisJdHJpc3RhdGUgIkFkdmFuU3lzIFNDU0kgc3VwcG9ydCIK
KwlkZXBlbmRzIG9uIFNDU0kgJiYgVklSVF9UT19CVVMKKwlkZXBlbmRzIG9uIElTQSB8fCBFSVNB
IHx8IFBDSQorCWhlbHAKKwkgIFRoaXMgaXMgYSBkcml2ZXIgZm9yIGFsbCBTQ1NJIGhvc3QgYWRh
cHRlcnMgbWFudWZhY3R1cmVkIGJ5CisJICBBZHZhblN5cy4gSXQgaXMgZG9jdW1lbnRlZCBpbiB0
aGUga2VybmVsIHNvdXJjZSBpbgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpL2FkdmFuc3lzLmM+Lgor
CisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0
aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBhZHZhbnN5cy4KKworY29uZmlnIFNDU0lfSU4y
MDAwCisJdHJpc3RhdGUgIkFsd2F5cyBJTjIwMDAgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24g
SVNBICYmIFNDU0kKKwloZWxwCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIGFuIElTQSBidXMgU0NT
SSBob3N0IGFkYXB0ZXIuICBZb3UnbGwgZmluZCBtb3JlCisJICBpbmZvcm1hdGlvbiBpbiA8Zmls
ZTpEb2N1bWVudGF0aW9uL3Njc2kvaW4yMDAwLnR4dD4uIElmIGl0IGRvZXNuJ3Qgd29yaworCSAg
b3V0IG9mIHRoZSBib3gsIHlvdSBtYXkgaGF2ZSB0byBjaGFuZ2UgdGhlIGp1bXBlcnMgZm9yIElS
USBvcgorCSAgYWRkcmVzcyBzZWxlY3Rpb24uCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIg
YXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVk
IGluMjAwMC4KKworY29uZmlnIFNDU0lfQVJDTVNSCisJdHJpc3RhdGUgIkFSRUNBIChBUkMxMXh4
LzEyeHgvMTN4eC8xNnh4KSBTQVRBL1NBUyBSQUlEIEhvc3QgQWRhcHRlciIKKwlkZXBlbmRzIG9u
IFBDSSAmJiBTQ1NJCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgYWxsIG9mIEFSRUNB
J3MgU0FUQS9TQVMgUkFJRCBjb250cm9sbGVyIGNhcmRzLgorCSAgVGhpcyBpcyBhbiBBUkVDQS1t
YWludGFpbmVkIGRyaXZlciBieSBFcmljaCBDaGVuLgorCSAgSWYgeW91IGhhdmUgYW55IHByb2Js
ZW1zLCBwbGVhc2UgbWFpbCB0bzogPGVyaWNoQGFyZWNhLmNvbS50dz4uCisJICBBcmVjYSBzdXBw
b3J0cyBMaW51eCBSQUlEIGNvbmZpZyB0b29scy4KKwkgIFBsZWFzZSBsaW5rIDxodHRwOi8vd3d3
LmFyZWNhLmNvbS50dz4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYXJjbXNyIChtb2Rw
cm9iZSBhcmNtc3IpLgorCitzb3VyY2UgImRyaXZlcnMvc2NzaS9tZWdhcmFpZC9LY29uZmlnLm1l
Z2FyYWlkIgorc291cmNlICJkcml2ZXJzL3Njc2kvbXB0MnNhcy9LY29uZmlnIgorCitjb25maWcg
U0NTSV9IUFRJT1AKKwl0cmlzdGF0ZSAiSGlnaFBvaW50IFJvY2tldFJBSUQgM3h4eC80eHh4IENv
bnRyb2xsZXIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0kgJiYgUENJCisJaGVscAorCSAgVGhp
cyBvcHRpb24gZW5hYmxlcyBzdXBwb3J0IGZvciBIaWdoUG9pbnQgUm9ja2V0UkFJRCAzeHh4LzR4
eHgKKwkgIGNvbnRyb2xsZXJzLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9k
dWxlLCBjaG9vc2UgTSBoZXJlOyB0aGUgbW9kdWxlCisJICB3aWxsIGJlIGNhbGxlZCBocHRpb3Au
IElmIHVuc3VyZSwgc2F5IE4uCisKK2NvbmZpZyBTQ1NJX0JVU0xPR0lDCisJdHJpc3RhdGUgIkJ1
c0xvZ2ljIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIChQQ0kgfHwgSVNBIHx8IE1DQSkgJiYg
U0NTSSAmJiBJU0FfRE1BX0FQSSAmJiBWSVJUX1RPX0JVUworCS0tLWhlbHAtLS0KKwkgIFRoaXMg
aXMgc3VwcG9ydCBmb3IgQnVzTG9naWMgTXVsdGlNYXN0ZXIgYW5kIEZsYXNoUG9pbnQgU0NTSSBI
b3N0CisJICBBZGFwdGVycy4gQ29uc3VsdCB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20K
KwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4sIGFuZCB0aGUgZmlsZXMK
KwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9CdXNMb2dpYy50eHQ+IGFuZAorCSAgPGZpbGU6
RG9jdW1lbnRhdGlvbi9zY3NpL0ZsYXNoUG9pbnQudHh0PiBmb3IgbW9yZSBpbmZvcm1hdGlvbi4K
KwkgIE5vdGUgdGhhdCBzdXBwb3J0IGZvciBGbGFzaFBvaW50IGlzIG9ubHkgYXZhaWxhYmxlIGZv
ciAzMi1iaXQKKwkgIHg4NiBjb25maWd1cmF0aW9ucy4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRy
aXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBj
YWxsZWQgQnVzTG9naWMuCisKK2NvbmZpZyBTQ1NJX0ZMQVNIUE9JTlQKKwlib29sICJGbGFzaFBv
aW50IHN1cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJX0JVU0xPR0lDICYmIFBDSSAmJiBYODZfMzIK
KwloZWxwCisJICBUaGlzIG9wdGlvbiBhbGxvd3MgeW91IHRvIGFkZCBGbGFzaFBvaW50IHN1cHBv
cnQgdG8gdGhlCisJICBCdXNMb2dpYyBTQ1NJIGRyaXZlci4gVGhlIEZsYXNoUG9pbnQgU0NDQiBN
YW5hZ2VyIGNvZGUgaXMKKwkgIHN1YnN0YW50aWFsLCBzbyB1c2VycyBvZiBNdWx0aU1hc3RlciBI
b3N0IEFkYXB0ZXJzIG1heSBub3QKKwkgIHdpc2ggdG8gaW5jbHVkZSBpdC4KKworY29uZmlnIFZN
V0FSRV9QVlNDU0kKKwl0cmlzdGF0ZSAiVk13YXJlIFBWU0NTSSBkcml2ZXIgc3VwcG9ydCIKKwlk
ZXBlbmRzIG9uIFBDSSAmJiBTQ1NJICYmIFg4NgorCWhlbHAKKwkgIFRoaXMgZHJpdmVyIHN1cHBv
cnRzIFZNd2FyZSdzIHBhcmEgdmlydHVhbGl6ZWQgU0NTSSBIQkEuCisJICBUbyBjb21waWxlIHRo
aXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxs
IGJlIGNhbGxlZCB2bXdfcHZzY3NpLgorCitjb25maWcgTElCRkMKKwl0cmlzdGF0ZSAiTGliRkMg
bW9kdWxlIgorCXNlbGVjdCBTQ1NJX0ZDX0FUVFJTCisJc2VsZWN0IENSQzMyCisJLS0taGVscC0t
LQorCSAgRmlicmUgQ2hhbm5lbCBsaWJyYXJ5IG1vZHVsZQorCitjb25maWcgTElCRkNPRQorCXRy
aXN0YXRlICJMaWJGQ29FIG1vZHVsZSIKKwlzZWxlY3QgTElCRkMKKwktLS1oZWxwLS0tCisJICBM
aWJyYXJ5IGZvciBGaWJyZSBDaGFubmVsIG92ZXIgRXRoZXJuZXQgbW9kdWxlCisKK2NvbmZpZyBG
Q09FCisJdHJpc3RhdGUgIkZDb0UgbW9kdWxlIgorCWRlcGVuZHMgb24gUENJCisJc2VsZWN0IExJ
QkZDT0UKKwktLS1oZWxwLS0tCisJICBGaWJyZSBDaGFubmVsIG92ZXIgRXRoZXJuZXQgbW9kdWxl
CisKK2NvbmZpZyBGQ09FX0ZOSUMKKwl0cmlzdGF0ZSAiQ2lzY28gRk5JQyBEcml2ZXIiCisJZGVw
ZW5kcyBvbiBQQ0kgJiYgWDg2CisJc2VsZWN0IExJQkZDT0UKKwloZWxwCisJICBUaGlzIGlzIHN1
cHBvcnQgZm9yIHRoZSBDaXNjbyBQQ0ktRXhwcmVzcyBGQ29FIEhCQS4KKworCSAgVG8gY29tcGls
ZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZSBhbmQgcmVhZAorCSAgPGZp
bGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2kudHh0Pi4KKwkgIFRoZSBtb2R1bGUgd2lsbCBiZSBj
YWxsZWQgZm5pYy4KKworY29uZmlnIFNDU0lfRE1YMzE5MUQKKwl0cmlzdGF0ZSAiRE1YMzE5MUQg
U0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElf
QVRUUlMKKwloZWxwCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIERvbWV4IERNWDMxOTFEIFNDU0kg
SG9zdCBBZGFwdGVycy4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZG14MzE5MWQuCisK
K2NvbmZpZyBTQ1NJX0RUQzMyODAKKwl0cmlzdGF0ZSAiRFRDMzE4MC8zMjgwIFNDU0kgc3VwcG9y
dCIKKwlkZXBlbmRzIG9uIElTQSAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJc2Vs
ZWN0IENIRUNLX1NJR05BVFVSRQorCWhlbHAKKwkgIFRoaXMgaXMgc3VwcG9ydCBmb3IgRFRDIDMx
ODAvMzI4MCBTQ1NJIEhvc3QgQWRhcHRlcnMuICBQbGVhc2UgcmVhZAorCSAgdGhlIFNDU0ktSE9X
VE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93
dG8+LCBhbmQgdGhlIGZpbGUKKwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9kdGMzeDgwLnR4
dD4uCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhl
cmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGR0Yy4KKworY29uZmlnIFNDU0lfRUFU
QQorCXRyaXN0YXRlICJFQVRBIElTQS9FSVNBL1BDSSAoRFBUIGFuZCBnZW5lcmljIEVBVEEvRE1B
LWNvbXBsaWFudCBib2FyZHMpIHN1cHBvcnQiCisJZGVwZW5kcyBvbiAoSVNBIHx8IEVJU0EgfHwg
UENJKSAmJiBTQ1NJICYmIElTQV9ETUFfQVBJCisJLS0taGVscC0tLQorCSAgVGhpcyBkcml2ZXIg
c3VwcG9ydHMgYWxsIEVBVEEvRE1BLWNvbXBsaWFudCBTQ1NJIGhvc3QgYWRhcHRlcnMuICBEUFQK
KwkgIElTQSBhbmQgYWxsIEVJU0EgSS9PIGFkZHJlc3NlcyBhcmUgcHJvYmVkIGxvb2tpbmcgZm9y
IHRoZSAiRUFUQSIKKwkgIHNpZ25hdHVyZS4gVGhlIGFkZHJlc3NlcyBvZiBhbGwgdGhlIFBDSSBT
Q1NJIGNvbnRyb2xsZXJzIHJlcG9ydGVkCisgICAgICAgICAgYnkgdGhlIFBDSSBzdWJzeXN0ZW0g
YXJlIHByb2JlZCBhcyB3ZWxsLgorCisJICBZb3Ugd2FudCB0byByZWFkIHRoZSBzdGFydCBvZiA8
ZmlsZTpkcml2ZXJzL3Njc2kvZWF0YS5jPiBhbmQgdGhlCisJICBTQ1NJLUhPV1RPLCBhdmFpbGFi
bGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZWF0YS4KKworY29uZmlnIFNDU0lfRUFUQV9UQUdHRURf
UVVFVUUKKwlib29sICJlbmFibGUgdGFnZ2VkIGNvbW1hbmQgcXVldWVpbmciCisJZGVwZW5kcyBv
biBTQ1NJX0VBVEEKKwloZWxwCisJICBUaGlzIGlzIGEgZmVhdHVyZSBvZiBTQ1NJLTIgd2hpY2gg
aW1wcm92ZXMgcGVyZm9ybWFuY2U6IHRoZSBob3N0CisJICBhZGFwdGVyIGNhbiBzZW5kIHNldmVy
YWwgU0NTSSBjb21tYW5kcyB0byBhIGRldmljZSdzIHF1ZXVlIGV2ZW4gaWYKKwkgIHByZXZpb3Vz
IGNvbW1hbmRzIGhhdmVuJ3QgZmluaXNoZWQgeWV0LgorCSAgVGhpcyBpcyBlcXVpdmFsZW50IHRv
IHRoZSAiZWF0YT10Yzp5IiBib290IG9wdGlvbi4KKworY29uZmlnIFNDU0lfRUFUQV9MSU5LRURf
Q09NTUFORFMKKwlib29sICJlbmFibGUgZWxldmF0b3Igc29ydGluZyIKKwlkZXBlbmRzIG9uIFND
U0lfRUFUQQorCWhlbHAKKwkgIFRoaXMgb3B0aW9uIGVuYWJsZXMgZWxldmF0b3Igc29ydGluZyBm
b3IgYWxsIHByb2JlZCBTQ1NJIGRpc2tzIGFuZAorCSAgQ0QtUk9Ncy4gSXQgZGVmaW5pdGVseSBy
ZWR1Y2VzIHRoZSBhdmVyYWdlIHNlZWsgZGlzdGFuY2Ugd2hlbiBkb2luZworCSAgcmFuZG9tIHNl
ZWtzLCBidXQgdGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBub3RpY2VhYmxl
CisJICBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudDogeW91ciBtaWxlYWdlIG1heSB2YXJ5Li4uCisJ
ICBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhlICJlYXRhPWxjOnkiIGJvb3Qgb3B0aW9uLgorCitj
b25maWcgU0NTSV9FQVRBX01BWF9UQUdTCisJaW50ICJtYXhpbXVtIG51bWJlciBvZiBxdWV1ZWQg
Y29tbWFuZHMiCisJZGVwZW5kcyBvbiBTQ1NJX0VBVEEKKwlkZWZhdWx0ICIxNiIKKwloZWxwCisJ
ICBUaGlzIHNwZWNpZmllcyBob3cgbWFueSBTQ1NJIGNvbW1hbmRzIGNhbiBiZSBtYXhpbWFsbHkg
cXVldWVkIGZvcgorCSAgZWFjaCBwcm9iZWQgU0NTSSBkZXZpY2UuIFlvdSBzaG91bGQgcmVkdWNl
IHRoZSBkZWZhdWx0IHZhbHVlIG9mIDE2CisJICBvbmx5IGlmIHlvdSBoYXZlIGRpc2tzIHdpdGgg
YnVnZ3kgb3IgbGltaXRlZCB0YWdnZWQgY29tbWFuZCBzdXBwb3J0LgorCSAgTWluaW11bSBpcyAy
IGFuZCBtYXhpbXVtIGlzIDYyLiBUaGlzIHZhbHVlIGlzIGFsc28gdGhlIHdpbmRvdyBzaXplCisJ
ICB1c2VkIGJ5IHRoZSBlbGV2YXRvciBzb3J0aW5nIG9wdGlvbiBhYm92ZS4gVGhlIGVmZmVjdGl2
ZSB2YWx1ZSB1c2VkCisJICBieSB0aGUgZHJpdmVyIGZvciBlYWNoIHByb2JlZCBTQ1NJIGRldmlj
ZSBpcyByZXBvcnRlZCBhdCBib290IHRpbWUuCisJICBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhl
ICJlYXRhPW1xOjgiIGJvb3Qgb3B0aW9uLgorCitjb25maWcgU0NTSV9FQVRBX1BJTworCXRyaXN0
YXRlICJFQVRBLVBJTyAob2xkIERQVCBQTTIwMDEsIFBNMjAxMkEpIHN1cHBvcnQiCisJZGVwZW5k
cyBvbiAoSVNBIHx8IEVJU0EgfHwgUENJKSAmJiBTQ1NJICYmIEJST0tFTgorCS0tLWhlbHAtLS0K
KwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIGFsbCBFQVRBLVBJTyBwcm90b2NvbCBjb21wbGlhbnQg
U0NTSSBIb3N0CisJICBBZGFwdGVycyBsaWtlIHRoZSBEUFQgUE0yMDAxIGFuZCB0aGUgUE0yMDEy
QS4gIEVBVEEtRE1BIGNvbXBsaWFudAorCSAgaG9zdCBhZGFwdGVycyBjb3VsZCBhbHNvIHVzZSB0
aGlzIGRyaXZlciBidXQgYXJlIGRpc2NvdXJhZ2VkIGZyb20KKwkgIGRvaW5nIHNvLCBzaW5jZSB0
aGlzIGRyaXZlciBvbmx5IHN1cHBvcnRzIGhhcmQgZGlza3MgYW5kIGxhY2tzCisJICBudW1lcm91
cyBmZWF0dXJlcy4gIFlvdSBtaWdodCB3YW50IHRvIGhhdmUgYSBsb29rIGF0IHRoZSBTQ1NJLUhP
V1RPLAorCSAgYXZhaWxhYmxlIGZyb20gPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hv
d3RvPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g
aGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZWF0YV9waW8uCisKK2NvbmZpZyBT
Q1NJX0ZVVFVSRV9ET01BSU4KKwl0cmlzdGF0ZSAiRnV0dXJlIERvbWFpbiAxNnh4IFNDU0kvQUhB
LTI5MjBBIHN1cHBvcnQiCisJZGVwZW5kcyBvbiAoSVNBIHx8IFBDSSkgJiYgU0NTSQorCXNlbGVj
dCBDSEVDS19TSUdOQVRVUkUKKwktLS1oZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIEZ1
dHVyZSBEb21haW4ncyAxNi1iaXQgU0NTSSBob3N0IGFkYXB0ZXJzCisJICAoVE1DLTE2NjAvMTY4
MCwgVE1DLTE2NTAvMTY3MCwgVE1DLTMyNjAsIFRNQy0xNjEwTS9NRVIvTUVYKSBhbmQKKwkgIG90
aGVyIGFkYXB0ZXJzIGJhc2VkIG9uIHRoZSBGdXR1cmUgRG9tYWluIGNoaXBzZXRzIChRdWFudHVt
CisJICBJU0EtMjAwUywgSVNBLTI1ME1HOyBBZGFwdGVjIEFIQS0yOTIwQTsgYW5kIGF0IGxlYXN0
IG9uZSBJQk0gYm9hcmQpLgorCSAgSXQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy43IG9mIHRo
ZSBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9j
cy5odG1sI2hvd3RvPi4KKworCSAgTk9URTogTmV3ZXIgQWRhcHRlYyBBSEEtMjkyMEMgYm9hcmRz
IHVzZSB0aGUgQWRhcHRlYyBBSUMtNzg1MCBjaGlwCisJICBhbmQgc2hvdWxkIHVzZSB0aGUgYWlj
N3h4eCBkcml2ZXIgKCJBZGFwdGVjIEFJQzd4eHggY2hpcHNldCBTQ1NJCisJICBjb250cm9sbGVy
IHN1cHBvcnQiKS4gVGhpcyBGdXR1cmUgRG9tYWluIGRyaXZlciB3b3JrcyB3aXRoIHRoZSBvbGRl
cgorCSAgQWRhcHRlYyBBSEEtMjkyMEEgYm9hcmRzIHdpdGggYSBGdXR1cmUgRG9tYWluIGNoaXAg
b24gdGhlbS4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3Nl
IE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZmRvbWFpbi4KKworY29uZmln
IFNDU0lfRkRfTUNTCisJdHJpc3RhdGUgIkZ1dHVyZSBEb21haW4gTUNTLTYwMC83MDAgU0NTSSBz
dXBwb3J0IgorCWRlcGVuZHMgb24gTUNBX0xFR0FDWSAmJiBTQ1NJCisJLS0taGVscC0tLQorCSAg
VGhpcyBpcyBzdXBwb3J0IGZvciBGdXR1cmUgRG9tYWluIE1DUyA2MDAvNzAwIE1DQSBTQ1NJIGFk
YXB0ZXJzLgorCSAgU29tZSBQUy8yIGNvbXB1dGVycyBhcmUgZXF1aXBwZWQgd2l0aCBJQk0gRmFz
dCBTQ1NJIEFkYXB0ZXIvQSB3aGljaAorCSAgaXMgaWRlbnRpY2FsIHRvIHRoZSBNQ1MgNzAwIGFu
ZCBoZW5jZSBhbHNvIHN1cHBvcnRlZCBieSB0aGlzIGRyaXZlci4KKwkgIFRoaXMgZHJpdmVyIGFs
c28gc3VwcG9ydHMgdGhlIFJlcGx5IFNCMTYvU0NTSSBjYXJkICh0aGUgU0NTSSBwYXJ0KS4KKwkg
IEl0IHN1cHBvcnRzIG11bHRpcGxlIGFkYXB0ZXJzIGluIHRoZSBzYW1lIHN5c3RlbS4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZmRfbWNzLgorCitjb25maWcgU0NTSV9HRFRICisJdHJp
c3RhdGUgIkludGVsL0lDUCAoZm9ybWVyIEdEVCBTQ1NJIERpc2sgQXJyYXkpIFJBSUQgQ29udHJv
bGxlciBzdXBwb3J0IgorCWRlcGVuZHMgb24gKElTQSB8fCBFSVNBIHx8IFBDSSkgJiYgU0NTSSAm
JiBJU0FfRE1BX0FQSQorCS0tLWhlbHAtLS0KKwkgIEZvcm1lcmx5IGNhbGxlZCBHRFQgU0NTSSBE
aXNrIEFycmF5IENvbnRyb2xsZXIgU3VwcG9ydC4KKworCSAgVGhpcyBpcyBhIGRyaXZlciBmb3Ig
UkFJRC9TQ1NJIERpc2sgQXJyYXkgQ29udHJvbGxlcnMgKEVJU0EvSVNBL1BDSSkgCisJICBtYW51
ZmFjdHVyZWQgYnkgSW50ZWwgQ29ycG9yYXRpb24vSUNQIHZvcnRleCBHbWJILiBJdCBpcyBkb2N1
bWVudGVkCisJICBpbiB0aGUga2VybmVsIHNvdXJjZSBpbiA8ZmlsZTpkcml2ZXJzL3Njc2kvZ2R0
aC5jPiBhbmQKKwkgIDxmaWxlOmRyaXZlcnMvc2NzaS9nZHRoLmg+LgorCisJICBUbyBjb21waWxl
IHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3
aWxsIGJlIGNhbGxlZCBnZHRoLgorCitjb25maWcgU0NTSV9JU0NJCisJdHJpc3RhdGUgIkludGVs
KFIpIEM2MDAgU2VyaWVzIENoaXBzZXQgU0FTIENvbnRyb2xsZXIiCisJZGVwZW5kcyBvbiBQQ0kg
JiYgU0NTSQorCWRlcGVuZHMgb24gWDg2CisJc2VsZWN0IFNDU0lfU0FTX0xJQlNBUworCS0tLWhl
bHAtLS0KKwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIHRoZSA2R2IvcyBTQVMgY2FwYWJpbGl0aWVz
IG9mIHRoZSBzdG9yYWdlCisJICBjb250cm9sIHVuaXQgZm91bmQgaW4gdGhlIEludGVsKFIpIEM2
MDAgc2VyaWVzIGNoaXBzZXQuCisKK2NvbmZpZyBTQ1NJX0dFTkVSSUNfTkNSNTM4MAorCXRyaXN0
YXRlICJHZW5lcmljIE5DUjUzODAvNTNjNDAwIFNDU0kgUElPIHN1cHBvcnQiCisJZGVwZW5kcyBv
biBJU0EgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCS0tLWhlbHAtLS0KKwkgIFRo
aXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBvbGQgTkNSIDUzYzgwIHNlcmllcyBvZiBTQ1NJIGNvbnRy
b2xsZXJzCisJICBvbiBib2FyZHMgdXNpbmcgUElPLiBNb3N0IGJvYXJkcyBzdWNoIGFzIHRoZSBU
cmFudG9yIFQxMzAgZml0IHRoaXMKKwkgIGNhdGVnb3J5LCBhbG9uZyB3aXRoIGEgbGFyZ2UgbnVt
YmVyIG9mIElTQSA4Yml0IGNvbnRyb2xsZXJzIHNoaXBwZWQKKwkgIGZvciBmcmVlIHdpdGggU0NT
SSBzY2FubmVycy4gSWYgeW91IGhhdmUgYSBQQVMxNiwgVDEyOCBvciBETVgzMTkxCisJICB5b3Ug
c2hvdWxkIHNlbGVjdCB0aGUgc3BlY2lmaWMgZHJpdmVyIGZvciB0aGF0IGNhcmQgcmF0aGVyIHRo
YW4KKwkgIGdlbmVyaWMgNTM4MCBzdXBwb3J0LgorCisJICBJdCBpcyBleHBsYWluZWQgaW4gc2Vj
dGlvbiAzLjggb2YgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0cDovL3d3
dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiAgSWYgaXQgZG9lc24ndCB3b3JrIG91dAorCSAg
b2YgdGhlIGJveCwgeW91IG1heSBoYXZlIHRvIGNoYW5nZSBzb21lIHNldHRpbmdzIGluCisJICA8
ZmlsZTpkcml2ZXJzL3Njc2kvZ19OQ1I1MzgwLmg+LgorCisJICBUbyBjb21waWxlIHRoaXMgZHJp
dmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNh
bGxlZCBnX05DUjUzODAuCisKK2NvbmZpZyBTQ1NJX0dFTkVSSUNfTkNSNTM4MF9NTUlPCisJdHJp
c3RhdGUgIkdlbmVyaWMgTkNSNTM4MC81M2M0MDAgU0NTSSBNTUlPIHN1cHBvcnQiCisJZGVwZW5k
cyBvbiBJU0EgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCS0tLWhlbHAtLS0KKwkg
IFRoaXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBvbGQgTkNSIDUzYzgwIHNlcmllcyBvZiBTQ1NJIGNv
bnRyb2xsZXJzCisJICBvbiBib2FyZHMgdXNpbmcgbWVtb3J5IG1hcHBlZCBJL08uIAorCSAgSXQg
aXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy44IG9mIHRoZSBTQ1NJLUhPV1RPLCBhdmFpbGFibGUg
ZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4gIElmIGl0IGRv
ZXNuJ3Qgd29yayBvdXQKKwkgIG9mIHRoZSBib3gsIHlvdSBtYXkgaGF2ZSB0byBjaGFuZ2Ugc29t
ZSBzZXR0aW5ncyBpbgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpL2dfTkNSNTM4MC5oPi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZ19OQ1I1MzgwX21taW8uCisKK2NvbmZpZyBTQ1NJX0dF
TkVSSUNfTkNSNTNDNDAwCisJYm9vbCAiRW5hYmxlIE5DUjUzYzQwMCBleHRlbnNpb25zIgorCWRl
cGVuZHMgb24gU0NTSV9HRU5FUklDX05DUjUzODAKKwloZWxwCisJICBUaGlzIGVuYWJsZXMgY2Vy
dGFpbiBvcHRpbWl6YXRpb25zIGZvciB0aGUgTkNSNTNjNDAwIFNDU0kgY2FyZHMuCisJICBZb3Ug
bWlnaHQgYXMgd2VsbCB0cnkgaXQgb3V0LiAgTm90ZSB0aGF0IHRoaXMgZHJpdmVyIHdpbGwgb25s
eSBwcm9iZQorCSAgZm9yIHRoZSBUcmFudG9yIFQxMzBCIGluIGl0cyBkZWZhdWx0IGNvbmZpZ3Vy
YXRpb247IHlvdSBtaWdodCBoYXZlCisJICB0byBwYXNzIGEgY29tbWFuZCBsaW5lIG9wdGlvbiB0
byB0aGUga2VybmVsIGF0IGJvb3QgdGltZSBpZiBpdCBkb2VzCisJICBub3QgZGV0ZWN0IHlvdXIg
Y2FyZC4gIFNlZSB0aGUgZmlsZQorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL2dfTkNSNTM4
MC50eHQ+IGZvciBkZXRhaWxzLgorCitjb25maWcgU0NTSV9JQk1NQ0EKKwl0cmlzdGF0ZSAiSUJN
TUNBIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIE1DQSAmJiBTQ1NJCisJLS0taGVscC0tLQor
CSAgVGhpcyBpcyBzdXBwb3J0IGZvciB0aGUgSUJNIFNDU0kgYWRhcHRlciBmb3VuZCBpbiBtYW55
IG9mIHRoZSBQUy8yCisJICBzZXJpZXMgY29tcHV0ZXJzLiAgVGhlc2UgbWFjaGluZXMgaGF2ZSBh
biBNQ0EgYnVzLCBzbyB5b3UgbmVlZCB0bworCSAgYW5zd2VyIFkgdG8gIk1DQSBzdXBwb3J0IiBh
cyB3ZWxsIGFuZCByZWFkCisJICA8ZmlsZTpEb2N1bWVudGF0aW9uL21jYS50eHQ+LgorCisJICBJ
ZiB0aGUgYWRhcHRlciBpc24ndCBmb3VuZCBkdXJpbmcgYm9vdCAoYSBjb21tb24gcHJvYmxlbSBm
b3IgbW9kZWxzCisJICA1NiwgNTcsIDc2LCBhbmQgNzcpIHlvdSdsbCBuZWVkIHRvIHVzZSB0aGUg
J2libW1jYXNjc2k9PHB1bj4nIGtlcm5lbAorCSAgb3B0aW9uLCB3aGVyZSA8cHVuPiBpcyB0aGUg
aWQgb2YgdGhlIFNDU0kgc3Vic3lzdGVtICh1c3VhbGx5IDcsIGJ1dAorCSAgaWYgdGhhdCBkb2Vz
bid0IHdvcmsgY2hlY2sgeW91ciByZWZlcmVuY2UgZGlza2V0dGUpLiAgT3duZXJzIG9mCisJICBt
b2RlbCA5NSB3aXRoIGEgTEVELW1hdHJpeC1kaXNwbGF5IGNhbiBpbiBhZGRpdGlvbiBhY3RpdmF0
ZSBzb21lCisJICBhY3Rpdml0eSBpbmZvIGxpa2UgdW5kZXIgT1MvMiwgYnV0IG1vcmUgaW5mb3Jt
YXRpdmUsIGJ5IHNldHRpbmcKKwkgICdpYm1tY2FzY3NpPWRpc3BsYXknIGFzIGFuIGFkZGl0aW9u
YWwga2VybmVsIHBhcmFtZXRlci4gIFRyeSAibWFuCisJICBib290cGFyYW0iIG9yIHNlZSB0aGUg
ZG9jdW1lbnRhdGlvbiBvZiB5b3VyIGJvb3QgbG9hZGVyIGFib3V0IGhvdyB0bworCSAgcGFzcyBv
cHRpb25zIHRvIHRoZSBrZXJuZWwuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBt
b2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGlibW1j
YS4KKworY29uZmlnIElCTU1DQV9TQ1NJX09SREVSX1NUQU5EQVJECisJYm9vbCAiU3RhbmRhcmQg
U0NTSS1vcmRlciIKKwlkZXBlbmRzIG9uIFNDU0lfSUJNTUNBCisJLS0taGVscC0tLQorCSAgSW4g
dGhlIFBDLXdvcmxkIGFuZCBpbiBtb3N0IG1vZGVybiBTQ1NJLUJJT1Mtc2V0dXBzLCBTQ1NJLWhh
cmQgZGlza3MKKwkgIGFyZSBhc3NpZ25lZCB0byB0aGUgZHJpdmUgbGV0dGVycywgc3RhcnRpbmcg
d2l0aCB0aGUgbG93ZXN0IFNDU0ktaWQKKwkgIChwaHlzaWNhbCBudW1iZXIgLS0gcHVuKSB0byBi
ZSBkcml2ZSBDOiwgYXMgc2VlbiBmcm9tIERPUyBhbmQKKwkgIHNpbWlsYXIgb3BlcmF0aW5nIHN5
c3RlbXMuIFdoZW4gbG9va2luZyBpbnRvIHBhcGVycyBkZXNjcmliaW5nIHRoZQorCSAgQU5TSS1T
Q1NJLXN0YW5kYXJkLCB0aGlzIGFzc2lnbm1lbnQgb2YgZHJpdmVzIGFwcGVhcnMgdG8gYmUgd3Jv
bmcuCisJICBUaGUgU0NTSS1zdGFuZGFyZCBmb2xsb3dzIGEgaGFyZHdhcmUtaGllcmFyY2h5IHdo
aWNoIHNheXMgdGhhdCBpZCA3CisJICBoYXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgYW5kIGlkIDAg
dGhlIGxvd2VzdC4gVGhlcmVmb3JlLCB0aGUgaG9zdAorCSAgYWRhcHRlcnMgYXJlIHN0aWxsIHRv
ZGF5IGV2ZXJ5d2hlcmUgcGxhY2VkIGFzIFNDU0ktaWQgNyBieSBkZWZhdWx0LgorCSAgSW4gdGhl
IFNDU0ktc3RhbmRhcmQsIHRoZSBkcml2ZSBsZXR0ZXJzIGV4cHJlc3MgdGhlIHByaW9yaXR5IG9m
IHRoZQorCSAgZGlzay4gQzogc2hvdWxkIGJlIHRoZSBoYXJkIGRpc2ssIG9yIGEgcGFydGl0aW9u
IG9uIGl0LCB3aXRoIHRoZQorCSAgaGlnaGVzdCBwcmlvcml0eS4gVGhpcyBtdXN0IHRoZXJlZm9y
ZSBiZSB0aGUgZGlzayB3aXRoIHRoZSBoaWdoZXN0CisJICBTQ1NJLWlkIChlLmcuIDYpIGFuZCBu
b3QgdGhlIG9uZSB3aXRoIHRoZSBsb3dlc3QhIElCTS1CSU9TIGtlcHQgdGhlCisJICBvcmlnaW5h
bCBkZWZpbml0aW9uIG9mIHRoZSBTQ1NJLXN0YW5kYXJkIGFzIGFsc28gaW5kdXN0cmlhbC0gYW5k
CisJICBwcm9jZXNzLWNvbnRyb2wtbWFjaGluZXMsIGxpa2UgVk1FLUNQVXMgcnVubmluZyB1bmRl
ciByZWFsdGltZS1PU2VzCisJICAoZS5nLiBMeW54T1MsIE9TOSkgZG8uCisKKwkgIElmIHlvdSBs
aWtlIHRvIHJ1biBMaW51eCBvbiB5b3VyIE1DQS1tYWNoaW5lIHdpdGggdGhlIHNhbWUKKwkgIGFz
c2lnbm1lbnQgb2YgaGFyZCBkaXNrcyBhcyBzZWVuIGZyb20gZS5nLiBET1Mgb3IgT1MvMiBvbiB5
b3VyCisJICBtYWNoaW5lLCB3aGljaCBpcyBpbiBhZGRpdGlvbiBjb25mb3JtYW50IHRvIHRoZSBT
Q1NJLXN0YW5kYXJkLCB5b3UKKwkgIG11c3Qgc2F5IFkgaGVyZS4gVGhpcyBpcyBhbHNvIG5lY2Vz
c2FyeSBmb3IgTUNBLUxpbnV4IHVzZXJzIHdobyB3YW50CisJICB0byBrZWVwIGRvd253YXJkIGNv
bXBhdGliaWxpdHkgdG8gb2xkZXIgcmVsZWFzZXMgb2YgdGhlCisJICBJQk0tTUNBLVNDU0ktZHJp
dmVyIChvbGRlciB0aGFuIGRyaXZlci1yZWxlYXNlIDIuMDAgYW5kIG9sZGVyIHRoYW4KKwkgIEp1
bmUgMTk5NykuCisKKwkgIElmIHlvdSBsaWtlIHRvIGhhdmUgdGhlIGxvd2VzdCBTQ1NJLWlkIGFz
c2lnbmVkIGFzIGRyaXZlIEM6LCBhcworCSAgbW9kZXJuIFNDU0ktQklPU2VzIGRvLCB3aGljaCBk
b2VzIG5vdCBjb25mb3JtIHRvIHRoZSBzdGFuZGFyZCwgYnV0CisJICBpcyB3aWRlc3ByZWFkIGFu
ZCBjb21tb24gaW4gdGhlIFBDLXdvcmxkIG9mIHRvZGF5LCB5b3UgbXVzdCBzYXkgTgorCSAgaGVy
ZS4gSWYgdW5zdXJlLCBzYXkgWS4KKworY29uZmlnIElCTU1DQV9TQ1NJX0RFVl9SRVNFVAorCWJv
b2wgIlJlc2V0IFNDU0ktZGV2aWNlcyBhdCBib290dGltZSIKKwlkZXBlbmRzIG9uIFNDU0lfSUJN
TUNBCisJLS0taGVscC0tLQorCSAgQnkgZGVmYXVsdCwgU0NTSS1kZXZpY2VzIGFyZSByZXNldCB3
aGVuIHRoZSBtYWNoaW5lIGlzIHBvd2VyZWQgb24uCisJICBIb3dldmVyLCBzb21lIGRldmljZXMg
ZXhpc3QsIGxpa2Ugc3BlY2lhbC1jb250cm9sLWRldmljZXMsCisJICBTQ1NJLUNOQy1tYWNoaW5l
cywgU0NTSS1wcmludGVyIG9yIHNjYW5uZXJzIG9mIG9sZGVyIHR5cGUsIHRoYXQgZG8KKwkgIG5v
dCByZXNldCB3aGVuIHN3aXRjaGVkIG9uLiBJZiB5b3Ugc2F5IFkgaGVyZSwgZWFjaCBkZXZpY2Ug
Y29ubmVjdGVkCisJICB0byB5b3VyIFNDU0ktYnVzIHdpbGwgYmUgaXNzdWVkIGEgcmVzZXQtY29t
bWFuZCBhZnRlciBpdCBoYXMgYmVlbgorCSAgcHJvYmVkLCB3aGlsZSB0aGUga2VybmVsIGlzIGJv
b3RpbmcuIFRoaXMgbWF5IGNhdXNlIHByb2JsZW1zIHdpdGgKKwkgIG1vcmUgbW9kZXJuIGRldmlj
ZXMsIGxpa2UgaGFyZCBkaXNrcywgd2hpY2ggZG8gbm90IGFwcHJlY2lhdGUgdGhlc2UKKwkgIHJl
c2V0IGNvbW1hbmRzLCBhbmQgY2FuIGNhdXNlIHlvdXIgc3lzdGVtIHRvIGhhbmcuIFNvIHNheSBZ
IG9ubHkgaWYKKwkgIHlvdSBrbm93IHRoYXQgb25lIG9mIHlvdXIgb2xkZXIgZGV2aWNlcyBuZWVk
cyBpdDsgTiBpcyB0aGUgc2FmZQorCSAgYW5zd2VyLgorCitjb25maWcgU0NTSV9JUFMKKwl0cmlz
dGF0ZSAiSUJNIFNlcnZlUkFJRCBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kKKwkt
LS1oZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRoZSBJQk0gU2VydmVSQUlEIGhhcmR3
YXJlIFJBSUQgY29udHJvbGxlcnMuCisJICBTZWUgPGh0dHA6Ly93d3cuZGV2ZWxvcGVyLmlibS5j
b20vd2VsY29tZS9uZXRmaW5pdHkvc2VydmVyYWlkLmh0bWw+CisJICBhbmQgPGh0dHA6Ly93d3ct
OTQ3LmlibS5jb20vc3VwcG9ydC9lbnRyeS9wb3J0YWwvZG9jZGlzcGxheT9icmFuZD01MDAwMDA4
JmxuZG9jaWQ9U0VSVi1SQUlEPgorCSAgZm9yIG1vcmUgaW5mb3JtYXRpb24uICBJZiB0aGlzIGRy
aXZlciBkb2VzIG5vdCB3b3JrIGNvcnJlY3RseQorCSAgd2l0aG91dCBtb2RpZmljYXRpb24gcGxl
YXNlIGNvbnRhY3QgdGhlIGF1dGhvciBieSBlbWFpbCBhdAorCSAgPGlwc2xpbnV4QGFkYXB0ZWMu
Y29tPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g
aGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgaXBzLgorCitjb25maWcgU0NTSV9J
Qk1WU0NTSQorCXRyaXN0YXRlICJJQk0gVmlydHVhbCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBv
biBQUENfUFNFUklFUyB8fCBQUENfSVNFUklFUworCXNlbGVjdCBTQ1NJX1NSUF9BVFRSUworCXNl
bGVjdCBWSU9QQVRIIGlmIFBQQ19JU0VSSUVTCisJaGVscAorCSAgVGhpcyBpcyB0aGUgSUJNIFBP
V0VSIFZpcnR1YWwgU0NTSSBDbGllbnQKKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBh
IG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgaWJt
dnNjc2ljLgorCitjb25maWcgU0NTSV9JQk1WU0NTSVMKKwl0cmlzdGF0ZSAiSUJNIFZpcnR1YWwg
U0NTSSBTZXJ2ZXIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBQQ19QU0VSSUVTICYmIFNDU0lfU1JQ
ICYmIFNDU0lfU1JQX1RHVF9BVFRSUworCWhlbHAKKwkgIFRoaXMgaXMgdGhlIFNSUCB0YXJnZXQg
ZHJpdmVyIGZvciBJQk0gcFNlcmllcyB2aXJ0dWFsIGVudmlyb25tZW50cy4KKworCSAgVGhlIHVz
ZXJzcGFjZSBjb21wb25lbnQgbmVlZGVkIHRvIGluaXRpYWxpemUgdGhlIGRyaXZlciBhbmQKKwkg
IGRvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kOgorCisJICBodHRwOi8vc3RndC5iZXJsaW9zLmRl
LworCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJl
OiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBpYm12c3RndC4KKworY29uZmlnIFNDU0lf
SUJNVkZDCisJdHJpc3RhdGUgIklCTSBWaXJ0dWFsIEZDIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQ
UENfUFNFUklFUyAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfRkNfQVRUUlMKKwloZWxwCisJICBUaGlz
IGlzIHRoZSBJQk0gUE9XRVIgVmlydHVhbCBGQyBDbGllbnQKKworCSAgVG8gY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBi
ZSBjYWxsZWQgaWJtdmZjLgorCitjb25maWcgU0NTSV9JQk1WRkNfVFJBQ0UKKwlib29sICJlbmFi
bGUgZHJpdmVyIGludGVybmFsIHRyYWNlIgorCWRlcGVuZHMgb24gU0NTSV9JQk1WRkMKKwlkZWZh
dWx0IHkKKwloZWxwCisJICBJZiB5b3Ugc2F5IFkgaGVyZSwgdGhlIGRyaXZlciB3aWxsIHRyYWNl
IGFsbCBjb21tYW5kcyBpc3N1ZWQKKwkgIHRvIHRoZSBhZGFwdGVyLiBQZXJmb3JtYW5jZSBpbXBh
Y3QgaXMgbWluaW1hbC4gVHJhY2UgY2FuIGJlCisJICBkdW1wZWQgdXNpbmcgL3N5cy9jbGFzcy9z
Y3NpX2hvc3QvaG9zdFhYL3RyYWNlLgorCitjb25maWcgU0NTSV9JTklUSU8KKwl0cmlzdGF0ZSAi
SW5pdGlvIDkxMDBVKFcpIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhlbHAK
KwkgIFRoaXMgaXMgc3VwcG9ydCBmb3IgdGhlIEluaXRpbyA5MVhYVShXKSBTQ1NJIGhvc3QgYWRh
cHRlci4gIFBsZWFzZQorCSAgcmVhZCB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkg
IDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4uCisKKwkgIFRvIGNvbXBpbGUg
dGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdp
bGwgYmUgY2FsbGVkIGluaXRpby4KKworY29uZmlnIFNDU0lfSU5JQTEwMAorCXRyaXN0YXRlICJJ
bml0aW8gSU5JLUExMDBVMlcgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJCisJaGVs
cAorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciB0aGUgSW5pdGlvIElOSS1BMTAwVTJXIFNDU0kgaG9z
dCBhZGFwdGVyLgorCSAgUGxlYXNlIHJlYWQgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9t
CisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LgorCisJICBUbyBjb21w
aWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVs
ZSB3aWxsIGJlIGNhbGxlZCBhMTAwdTJ3LgorCitjb25maWcgU0NTSV9QUEEKKwl0cmlzdGF0ZSAi
SU9NRUdBIHBhcmFsbGVsIHBvcnQgKHBwYSAtIG9sZGVyIGRyaXZlcykiCisJZGVwZW5kcyBvbiBT
Q1NJICYmIFBBUlBPUlRfUEMKKwktLS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyBv
bGRlciB2ZXJzaW9ucyBvZiBJT01FR0EncyBwYXJhbGxlbCBwb3J0IFpJUAorCSAgZHJpdmUgKGEg
MTAwIE1CIHJlbW92YWJsZSBtZWRpYSBkZXZpY2UpLgorCisJICBOb3RlIHRoYXQgeW91IGNhbiBz
YXkgTiBoZXJlIGlmIHlvdSBoYXZlIHRoZSBTQ1NJIHZlcnNpb24gb2YgdGhlIFpJUAorCSAgZHJp
dmU6IGl0IHdpbGwgYmUgc3VwcG9ydGVkIGF1dG9tYXRpY2FsbHkgaWYgeW91IHNhaWQgWSB0byB0
aGUKKwkgIGdlbmVyaWMgIlNDU0kgZGlzayBzdXBwb3J0IiwgYWJvdmUuCisKKwkgIElmIHlvdSBo
YXZlIHRoZSBaSVAgUGx1cyBkcml2ZSBvciBhIG1vcmUgcmVjZW50IHBhcmFsbGVsIHBvcnQgWklQ
CisJICBkcml2ZSAoaWYgdGhlIHN1cHBsaWVkIGNhYmxlIHdpdGggdGhlIGRyaXZlIGlzIGxhYmVs
ZWQgIkF1dG9EZXRlY3QiKQorCSAgdGhlbiB5b3Ugc2hvdWxkIHNheSBOIGhlcmUgYW5kIFkgdG8g
IklPTUVHQSBwYXJhbGxlbCBwb3J0IChpbW0gLQorCSAgbmV3ZXIgZHJpdmVzKSIsIGJlbG93Lgor
CisJICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIGRyaXZlciBhbmQgaG93IHRvIHVz
ZSBpdCB5b3Ugc2hvdWxkCisJICByZWFkIHRoZSBmaWxlIDxmaWxlOkRvY3VtZW50YXRpb24vc2Nz
aS9wcGEudHh0Pi4gIFlvdSBzaG91bGQgYWxzbyByZWFkCisJICB0aGUgU0NTSS1IT1dUTywgd2hp
Y2ggaXMgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNo
b3d0bz4uICBJZiB5b3UgdXNlIHRoaXMgZHJpdmVyLAorCSAgeW91IHdpbGwgc3RpbGwgYmUgYWJs
ZSB0byB1c2UgdGhlIHBhcmFsbGVsIHBvcnQgZm9yIG90aGVyIHRhc2tzLAorCSAgc3VjaCBhcyBh
IHByaW50ZXI7IGl0IGlzIHNhZmUgdG8gY29tcGlsZSBib3RoIGRyaXZlcnMgaW50byB0aGUKKwkg
IGtlcm5lbC4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3Nl
IE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcHBhLgorCitjb25maWcgU0NT
SV9JTU0KKwl0cmlzdGF0ZSAiSU9NRUdBIHBhcmFsbGVsIHBvcnQgKGltbSAtIG5ld2VyIGRyaXZl
cykiCisJZGVwZW5kcyBvbiBTQ1NJICYmIFBBUlBPUlRfUEMKKwktLS1oZWxwLS0tCisJICBUaGlz
IGRyaXZlciBzdXBwb3J0cyBuZXdlciB2ZXJzaW9ucyBvZiBJT01FR0EncyBwYXJhbGxlbCBwb3J0
IFpJUAorCSAgZHJpdmUgKGEgMTAwIE1CIHJlbW92YWJsZSBtZWRpYSBkZXZpY2UpLgorCisJICBO
b3RlIHRoYXQgeW91IGNhbiBzYXkgTiBoZXJlIGlmIHlvdSBoYXZlIHRoZSBTQ1NJIHZlcnNpb24g
b2YgdGhlIFpJUAorCSAgZHJpdmU6IGl0IHdpbGwgYmUgc3VwcG9ydGVkIGF1dG9tYXRpY2FsbHkg
aWYgeW91IHNhaWQgWSB0byB0aGUKKwkgIGdlbmVyaWMgIlNDU0kgZGlzayBzdXBwb3J0IiwgYWJv
dmUuCisKKwkgIElmIHlvdSBoYXZlIHRoZSBaSVAgUGx1cyBkcml2ZSBvciBhIG1vcmUgcmVjZW50
IHBhcmFsbGVsIHBvcnQgWklQCisJICBkcml2ZSAoaWYgdGhlIHN1cHBsaWVkIGNhYmxlIHdpdGgg
dGhlIGRyaXZlIGlzIGxhYmVsZWQgIkF1dG9EZXRlY3QiKQorCSAgdGhlbiB5b3Ugc2hvdWxkIHNh
eSBZIGhlcmU7IGlmIHlvdSBoYXZlIGFuIG9sZGVyIFpJUCBkcml2ZSwgc2F5IE4KKwkgIGhlcmUg
YW5kIFkgdG8gIklPTUVHQSBQYXJhbGxlbCBQb3J0IChwcGEgLSBvbGRlciBkcml2ZXMpIiwgYWJv
dmUuCisKKwkgIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgZHJpdmVyIGFuZCBob3cg
dG8gdXNlIGl0IHlvdSBzaG91bGQKKwkgIHJlYWQgdGhlIGZpbGUgPGZpbGU6RG9jdW1lbnRhdGlv
bi9zY3NpL3BwYS50eHQ+LiAgWW91IHNob3VsZCBhbHNvIHJlYWQKKwkgIHRoZSBTQ1NJLUhPV1RP
LCB3aGljaCBpcyBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5o
dG1sI2hvd3RvPi4gIElmIHlvdSB1c2UgdGhpcyBkcml2ZXIsCisJICB5b3Ugd2lsbCBzdGlsbCBi
ZSBhYmxlIHRvIHVzZSB0aGUgcGFyYWxsZWwgcG9ydCBmb3Igb3RoZXIgdGFza3MsCisJICBzdWNo
IGFzIGEgcHJpbnRlcjsgaXQgaXMgc2FmZSB0byBjb21waWxlIGJvdGggZHJpdmVycyBpbnRvIHRo
ZQorCSAga2VybmVsLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBj
aG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBpbW0uCisKK2NvbmZp
ZyBTQ1NJX0laSVBfRVBQMTYKKwlib29sICJwcGEvaW1tIG9wdGlvbiAtIFVzZSBzbG93IChidXQg
c2FmZSkgRVBQLTE2IgorCWRlcGVuZHMgb24gU0NTSV9QUEEgfHwgU0NTSV9JTU0KKwktLS1oZWxw
LS0tCisJICBFUFAgKEVuaGFuY2VkIFBhcmFsbGVsIFBvcnQpIGlzIGEgc3RhbmRhcmQgZm9yIHBh
cmFsbGVsIHBvcnRzIHdoaWNoCisJICBhbGxvd3MgdGhlbSB0byBhY3QgYXMgZXhwYW5zaW9uIGJ1
c2VzIHRoYXQgY2FuIGhhbmRsZSB1cCB0byA2NAorCSAgcGVyaXBoZXJhbCBkZXZpY2VzLgorCisJ
ICBTb21lIHBhcmFsbGVsIHBvcnQgY2hpcHNldHMgYXJlIHNsb3dlciB0aGFuIHRoZWlyIG1vdGhl
cmJvYXJkLCBhbmQKKwkgIHNvIHdlIGhhdmUgdG8gY29udHJvbCB0aGUgc3RhdGUgb2YgdGhlIGNo
aXBzZXQncyBGSUZPIHF1ZXVlIGV2ZXJ5CisJICBub3cgYW5kIHRoZW4gdG8gYXZvaWQgZGF0YSBs
b3NzLiBUaGlzIHdpbGwgYmUgZG9uZSBpZiB5b3Ugc2F5IFkKKwkgIGhlcmUuCisKKwkgIEdlbmVy
YWxseSwgc2F5aW5nIFkgaXMgdGhlIHNhZmUgb3B0aW9uIGFuZCBzbG93cyB0aGluZ3MgZG93biBh
IGJpdC4KKworY29uZmlnIFNDU0lfSVpJUF9TTE9XX0NUUgorCWJvb2wgInBwYS9pbW0gb3B0aW9u
IC0gQXNzdW1lIHNsb3cgcGFycG9ydCBjb250cm9sIHJlZ2lzdGVyIgorCWRlcGVuZHMgb24gU0NT
SV9QUEEgfHwgU0NTSV9JTU0KKwloZWxwCisJICBTb21lIHBhcmFsbGVsIHBvcnRzIGFyZSBrbm93
biB0byBoYXZlIGV4Y2Vzc2l2ZSBkZWxheXMgYmV0d2VlbgorCSAgY2hhbmdpbmcgdGhlIHBhcmFs
bGVsIHBvcnQgY29udHJvbCByZWdpc3RlciBhbmQgZ29vZCBkYXRhIGJlaW5nCisJICBhdmFpbGFi
bGUgb24gdGhlIHBhcmFsbGVsIHBvcnQgZGF0YS9zdGF0dXMgcmVnaXN0ZXIuIFRoaXMgb3B0aW9u
CisJICBmb3JjZXMgYSBzbWFsbCBkZWxheSAoMS4wIHVzZWMgdG8gYmUgZXhhY3QpIGFmdGVyIGNo
YW5naW5nIHRoZQorCSAgY29udHJvbCByZWdpc3RlciB0byBsZXQgdGhpbmdzIHNldHRsZSBvdXQu
IEVuYWJsaW5nIHRoaXMgb3B0aW9uIG1heQorCSAgcmVzdWx0IGluIGEgYmlnIGRyb3AgaW4gcGVy
Zm9ybWFuY2UgYnV0IHNvbWUgdmVyeSBvbGQgcGFyYWxsZWwgcG9ydHMKKwkgIChmb3VuZCBpbiAz
ODYgdmludGFnZSBtYWNoaW5lcykgd2lsbCBub3Qgd29yayBwcm9wZXJseS4KKworCSAgR2VuZXJh
bGx5LCBzYXlpbmcgTiBpcyBmaW5lLgorCitjb25maWcgU0NTSV9OQ1I1M0M0MDZBCisJdHJpc3Rh
dGUgIk5DUjUzYzQwNmEgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kKKwlo
ZWxwCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRoZSBOQ1I1M2M0MDZhIFNDU0kgaG9zdCBhZGFw
dGVyLiAgRm9yIHVzZXIKKwkgIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXJzLCBjaGVjayBvdXQgPGZp
bGU6ZHJpdmVycy9zY3NpL05DUjUzYzQwNmEuYz4KKwkgIGluIHRoZSBrZXJuZWwgc291cmNlLiAg
QWxzbyByZWFkIHRoZSBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cu
dGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBh
cyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQg
TkNSNTNjNDA2LgorCitjb25maWcgU0NTSV9OQ1JfRDcwMAorCXRyaXN0YXRlICJOQ1IgRHVhbCA3
MDAgTUNBIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIE1DQSAmJiBTQ1NJCisJc2VsZWN0IFND
U0lfU1BJX0FUVFJTCisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIE1pY3JvQ2hh
bm5lbCBEdWFsIDcwMCBjYXJkIHByb2R1Y2VkIGJ5CisJICBOQ1IgYW5kIGNvbW1vbmx5IHVzZWQg
aW4gMzQ1eC8zNXh4LzQxMDAgY2xhc3MgbWFjaGluZXMuICBJdCBhbHdheXMKKwkgIHRyaWVzIHRv
IG5lZ290aWF0ZSBzeW5jIGFuZCB1c2VzIHRhZyBjb21tYW5kIHF1ZXVlaW5nLgorCisJICBVbmxl
c3MgeW91IGhhdmUgYW4gTkNSIG1hbnVmYWN0dXJlZCBtYWNoaW5lLCB0aGUgY2hhbmNlcyBhcmUg
dGhhdAorCSAgeW91IGRvIG5vdCBoYXZlIHRoaXMgU0NTSSBjYXJkLCBzbyBzYXkgTi4KKworY29u
ZmlnIFNDU0lfTEFTSTcwMAorCXRyaXN0YXRlICJIUCBMYXNpIFNDU0kgc3VwcG9ydCBmb3IgNTNj
NzAwLzcxMCIKKwlkZXBlbmRzIG9uIEdTQyAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJT
CisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIFNDU0kgY29udHJvbGxlciBpbiB0
aGUgTGFzaSBjaGlwIGZvdW5kIGluCisJICBtYW55IFBBLVJJU0Mgd29ya3N0YXRpb25zICYgc2Vy
dmVycy4gIElmIHlvdSBkbyBub3Qga25vdyB3aGV0aGVyIHlvdQorCSAgaGF2ZSBhIExhc2kgY2hp
cCwgaXQgaXMgc2FmZSB0byBzYXkgIlkiIGhlcmUuCisKK2NvbmZpZyBTQ1NJX1NOSV81M0M3MTAK
Kwl0cmlzdGF0ZSAiU05JIFJNIFNDU0kgc3VwcG9ydCBmb3IgNTNjNzEwIgorCWRlcGVuZHMgb24g
U05JX1JNICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwlzZWxlY3QgNTNDNzAwX0xF
X09OX0JFCisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIG9uYm9hcmQgU0NTSSBj
b250cm9sbGVyIGZvdW5kIGluIG9sZGVyCisJICBTTkkgUk0gd29ya3N0YXRpb25zICYgc2VydmVy
cy4KKworY29uZmlnIDUzQzcwMF9MRV9PTl9CRQorCWJvb2wKKwlkZXBlbmRzIG9uIFNDU0lfTEFT
STcwMAorCWRlZmF1bHQgeQorCitjb25maWcgU0NTSV9TVEVYCisJdHJpc3RhdGUgIlByb21pc2Ug
U3VwZXJUcmFrIEVYIFNlcmllcyBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kKKwkt
LS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyBQcm9taXNlIFN1cGVyVHJhayBFWCBz
ZXJpZXMgc3RvcmFnZSBjb250cm9sbGVycy4KKworCSAgUHJvbWlzZSBwcm92aWRlcyBMaW51eCBS
QUlEIGNvbmZpZ3VyYXRpb24gdXRpbGl0eSBmb3IgdGhlc2UKKwkgIGNvbnRyb2xsZXJzLiBQbGVh
c2UgdmlzaXQgPGh0dHA6Ly93d3cucHJvbWlzZS5jb20+IHRvIGRvd25sb2FkLgorCisJICBUbyBj
b21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1v
ZHVsZSB3aWxsIGJlIGNhbGxlZCBzdGV4LgorCitjb25maWcgNTNDNzAwX0JFX0JVUworCWJvb2wK
KwlkZXBlbmRzIG9uIFNDU0lfQTQwMDBUIHx8IFNDU0lfWk9SUk83WFggfHwgTVZNRTE2eF9TQ1NJ
IHx8IEJWTUU2MDAwX1NDU0kKKwlkZWZhdWx0IHkKKworY29uZmlnIFNDU0lfU1lNNTNDOFhYXzIK
Kwl0cmlzdGF0ZSAiU1lNNTNDOFhYIFZlcnNpb24gMiBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBv
biBQQ0kgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCS0tLWhlbHAtLS0KKwkgIFRo
aXMgZHJpdmVyIHN1cHBvcnRzIHRoZSB3aG9sZSBOQ1I1M0M4WFgvU1lNNTNDOFhYIGZhbWlseSBv
ZgorCSAgUENJLVNDU0kgY29udHJvbGxlcnMuICBJdCBhbHNvIHN1cHBvcnRzIHRoZSBzdWJzZXQg
b2YgTFNJNTNDMTBYWAorCSAgVWx0cmEtMTYwIGNvbnRyb2xsZXJzIHRoYXQgYXJlIGJhc2VkIG9u
IHRoZSBTWU01M0M4WFggU0NSSVBUUworCSAgbGFuZ3VhZ2UuICBJdCBkb2VzIG5vdCBzdXBwb3J0
IExTSTUzQzEwWFggVWx0cmEtMzIwIFBDSS1YIFNDU0kKKwkgIGNvbnRyb2xsZXJzOyB5b3UgbmVl
ZCB0byB1c2UgdGhlIEZ1c2lvbiBNUFQgZHJpdmVyIGZvciB0aGF0LgorCisJICBQbGVhc2UgcmVh
ZCA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvc3ltNTNjOHh4XzIudHh0PiBmb3IgbW9yZQorCSAg
aW5mb3JtYXRpb24uCisKK2NvbmZpZyBTQ1NJX1NZTTUzQzhYWF9ETUFfQUREUkVTU0lOR19NT0RF
CisJaW50ICJETUEgYWRkcmVzc2luZyBtb2RlIgorCWRlcGVuZHMgb24gU0NTSV9TWU01M0M4WFhf
MgorCWRlZmF1bHQgIjEiCisJLS0taGVscC0tLQorCSAgVGhpcyBvcHRpb24gb25seSBhcHBsaWVz
IHRvIFBDSS1TQ1NJIGNoaXBzIHRoYXQgYXJlIFBDSSBEQUMKKwkgIGNhcGFibGUgKDg3NUEsIDg5
NUEsIDg5NiwgMTAxMC0zMywgMTAxMC02NiwgMTAwMCkuCisKKwkgIFdoZW4gc2V0IHRvIDAsIHRo
ZSBkcml2ZXIgd2lsbCBwcm9ncmFtIHRoZSBjaGlwIHRvIG9ubHkgcGVyZm9ybQorCSAgMzItYml0
IERNQS4gIFdoZW4gc2V0IHRvIDEsIHRoZSBjaGlwIHdpbGwgYmUgYWJsZSB0byBwZXJmb3JtIERN
QQorCSAgdG8gYWRkcmVzc2VzIHVwIHRvIDFUQi4gIFdoZW4gc2V0IHRvIDIsIHRoZSBkcml2ZXIg
c3VwcG9ydHMgdGhlCisJICBmdWxsIDY0LWJpdCBETUEgYWRkcmVzcyByYW5nZSwgYnV0IGNhbiBv
bmx5IGFkZHJlc3MgMTYgc2VnbWVudHMKKwkgIG9mIDQgR0IgZWFjaC4gIFRoaXMgbGltaXRzIHRo
ZSB0b3RhbCBhZGRyZXNzYWJsZSByYW5nZSB0byA2NCBHQi4KKworCSAgTW9zdCBtYWNoaW5lcyB3
aXRoIGxlc3MgdGhhbiA0R0Igb2YgbWVtb3J5IHNob3VsZCB1c2UgYSBzZXR0aW5nCisJICBvZiAw
IGZvciBiZXN0IHBlcmZvcm1hbmNlLiAgSWYgeW91ciBtYWNoaW5lIGhhcyA0R0Igb2YgbWVtb3J5
CisJICBvciBtb3JlLCB5b3Ugc2hvdWxkIHNldCB0aGlzIG9wdGlvbiB0byAxICh0aGUgZGVmYXVs
dCkuCisKKwkgIFRoZSBzdGlsbCBleHBlcmltZW50YWwgdmFsdWUgMiAoNjQgYml0IERNQSBhZGRy
ZXNzaW5nIHdpdGggMTYKKwkgIHggNEdCIHNlZ21lbnRzIGxpbWl0YXRpb24pIGNhbiBiZSB1c2Vk
IG9uIHN5c3RlbXMgdGhhdCByZXF1aXJlCisJICBQQ0kgYWRkcmVzcyBiaXRzIHBhc3QgYml0IDM5
IHRvIGJlIHNldCBmb3IgdGhlIGFkZHJlc3Npbmcgb2YKKwkgIG1lbW9yeSB1c2luZyBQQ0kgREFD
IGN5Y2xlcy4KKworY29uZmlnIFNDU0lfU1lNNTNDOFhYX0RFRkFVTFRfVEFHUworCWludCAiRGVm
YXVsdCB0YWdnZWQgY29tbWFuZCBxdWV1ZSBkZXB0aCIKKwlkZXBlbmRzIG9uIFNDU0lfU1lNNTND
OFhYXzIKKwlkZWZhdWx0ICIxNiIKKwloZWxwCisJICBUaGlzIGlzIHRoZSBkZWZhdWx0IHZhbHVl
IG9mIHRoZSBjb21tYW5kIHF1ZXVlIGRlcHRoIHRoZQorCSAgZHJpdmVyIHdpbGwgYW5ub3VuY2Ug
dG8gdGhlIGdlbmVyaWMgU0NTSSBsYXllciBmb3IgZGV2aWNlcworCSAgdGhhdCBzdXBwb3J0IHRh
Z2dlZCBjb21tYW5kIHF1ZXVlaW5nLiBUaGlzIHZhbHVlIGNhbiBiZSBjaGFuZ2VkCisJICBmcm9t
IHRoZSBib290IGNvbW1hbmQgbGluZS4gIFRoaXMgaXMgYSBzb2Z0IGxpbWl0IHRoYXQgY2Fubm90
CisJICBleGNlZWQgQ09ORklHX1NDU0lfU1lNNTNDOFhYX01BWF9UQUdTLgorCitjb25maWcgU0NT
SV9TWU01M0M4WFhfTUFYX1RBR1MKKwlpbnQgIk1heGltdW0gbnVtYmVyIG9mIHF1ZXVlZCBjb21t
YW5kcyIKKwlkZXBlbmRzIG9uIFNDU0lfU1lNNTNDOFhYXzIKKwlkZWZhdWx0ICI2NCIKKwloZWxw
CisJICBUaGlzIG9wdGlvbiBhbGxvd3MgeW91IHRvIHNwZWNpZnkgdGhlIG1heGltdW0gbnVtYmVy
IG9mIGNvbW1hbmRzCisJICB0aGF0IGNhbiBiZSBxdWV1ZWQgdG8gYW55IGRldmljZSwgd2hlbiB0
YWdnZWQgY29tbWFuZCBxdWV1aW5nIGlzCisJICBwb3NzaWJsZS4gVGhlIGRyaXZlciBzdXBwb3J0
cyB1cCB0byAyNTYgcXVldWVkIGNvbW1hbmRzIHBlciBkZXZpY2UuCisJICBUaGlzIHZhbHVlIGlz
IHVzZWQgYXMgYSBjb21waWxlZC1pbiBoYXJkIGxpbWl0LgorCitjb25maWcgU0NTSV9TWU01M0M4
WFhfTU1JTworCWJvb2wgIlVzZSBtZW1vcnkgbWFwcGVkIElPIgorCWRlcGVuZHMgb24gU0NTSV9T
WU01M0M4WFhfMgorCWRlZmF1bHQgeQorCWhlbHAKKwkgIE1lbW9yeSBtYXBwZWQgSU8gaXMgZmFz
dGVyIHRoYW4gUG9ydCBJTy4gIE1vc3QgcGVvcGxlIHNob3VsZAorCSAgYW5zd2VyIFkgaGVyZSwg
YnV0IHNvbWUgbWFjaGluZXMgbWF5IGhhdmUgcHJvYmxlbXMuICBJZiB5b3UgaGF2ZQorCSAgdG8g
YW5zd2VyIE4gaGVyZSwgcGxlYXNlIHJlcG9ydCB0aGUgcHJvYmxlbSB0byB0aGUgbWFpbnRhaW5l
ci4KKworY29uZmlnIFNDU0lfSVBSCisJdHJpc3RhdGUgIklCTSBQb3dlciBMaW51eCBSQUlEIGFk
YXB0ZXIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJICYmIEFUQQorCXNlbGVjdCBG
V19MT0FERVIKKwktLS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyB0aGUgSUJNIFBv
d2VyIExpbnV4IGZhbWlseSBSQUlEIGFkYXB0ZXJzLgorCSAgVGhpcyBpbmNsdWRlcyBJQk0gcFNl
cmllcyA1NzEyLCA1NzAzLCA1NzA5LCBhbmQgNTcwQSwgYXMgd2VsbAorCSAgYXMgSUJNIGlTZXJp
ZXMgNTcwMiwgNTcwMywgNTcwOSwgYW5kIDU3MEEuCisKK2NvbmZpZyBTQ1NJX0lQUl9UUkFDRQor
CWJvb2wgImVuYWJsZSBkcml2ZXIgaW50ZXJuYWwgdHJhY2UiCisJZGVwZW5kcyBvbiBTQ1NJX0lQ
UgorCWRlZmF1bHQgeQorCWhlbHAKKwkgIElmIHlvdSBzYXkgWSBoZXJlLCB0aGUgZHJpdmVyIHdp
bGwgdHJhY2UgYWxsIGNvbW1hbmRzIGlzc3VlZAorCSAgdG8gdGhlIGFkYXB0ZXIuIFBlcmZvcm1h
bmNlIGltcGFjdCBpcyBtaW5pbWFsLiBUcmFjZSBjYW4gYmUKKwkgIGR1bXBlZCB1c2luZyAvc3lz
L2J1cy9jbGFzcy9zY3NpX2hvc3QvaG9zdFhYL3RyYWNlLgorCitjb25maWcgU0NTSV9JUFJfRFVN
UAorCWJvb2wgImVuYWJsZSBhZGFwdGVyIGR1bXAgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0lf
SVBSCisJZGVmYXVsdCB5CisJaGVscAorCSAgSWYgeW91IHNheSBZIGhlcmUsIHRoZSBkcml2ZXIg
d2lsbCBzdXBwb3J0IGFkYXB0ZXIgY3Jhc2ggZHVtcC4KKwkgIElmIHlvdSBlbmFibGUgdGhpcyBz
dXBwb3J0LCB0aGUgaXByZHVtcCBkYWVtb24gY2FuIGJlIHVzZWQKKwkgIHRvIGNhcHR1cmUgYWRh
cHRlciBmYWlsdXJlIGFuYWx5c2lzIGluZm9ybWF0aW9uLgorCitjb25maWcgU0NTSV9aQUxPTgor
CXRyaXN0YXRlICJaYWxvbiBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBHU0MgJiYgU0NTSQor
CXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoZSBaYWxvbiBpcyBhIEdTQy9IU0Mg
YnVzIGludGVyZmFjZSBjaGlwIHRoYXQgc2l0cyBiZXR3ZWVuIHRoZQorCSAgUEEtUklTQyBwcm9j
ZXNzb3IgYW5kIHRoZSBOQ1IgNTNjNzIwIFNDU0kgY29udHJvbGxlciBvbiBDMTAwLAorCSAgQzEx
MCwgSjIwMCwgSjIxMCBhbmQgc29tZSBELCBLICYgUi1jbGFzcyBtYWNoaW5lcy4gIEl0J3MgYWxz
bworCSAgdXNlZCBvbiB0aGUgYWRkLWluIEJsdWVmaXNoLCBCYXJyYWN1ZGEgJiBTaHJpa2UgU0NT
SSBjYXJkcy4KKwkgIFNheSBZIGhlcmUgaWYgeW91IGhhdmUgb25lIG9mIHRoZXNlIG1hY2hpbmVz
IG9yIGNhcmRzLgorCitjb25maWcgU0NTSV9OQ1JfUTcyMAorCXRyaXN0YXRlICJOQ1IgUXVhZCA3
MjAgTUNBIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIE1DQSAmJiBTQ1NJCisJc2VsZWN0IFND
U0lfU1BJX0FUVFJTCisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIE1pY3JvQ2hh
bm5lbCBRdWFkIDcyMCBjYXJkIHByb2R1Y2VkIGJ5CisJICBOQ1IgYW5kIGNvbW1vbmx5IHVzZWQg
aW4gMzQ1eC8zNXh4LzQxMDAgY2xhc3MgbWFjaGluZXMuICBJdCBhbHdheXMKKwkgIHRyaWVzIHRv
IG5lZ290aWF0ZSBzeW5jIGFuZCB1c2VzIHRhZyBjb21tYW5kIHF1ZXVlaW5nLgorCisJICBVbmxl
c3MgeW91IGhhdmUgYW4gTkNSIG1hbnVmYWN0dXJlZCBtYWNoaW5lLCB0aGUgY2hhbmNlcyBhcmUg
dGhhdAorCSAgeW91IGRvIG5vdCBoYXZlIHRoaXMgU0NTSSBjYXJkLCBzbyBzYXkgTi4KKworY29u
ZmlnIFNDU0lfTkNSNTNDOFhYX0RFRkFVTFRfVEFHUworCWludCAiZGVmYXVsdCB0YWdnZWQgY29t
bWFuZCBxdWV1ZSBkZXB0aCIKKwlkZXBlbmRzIG9uIFNDU0lfWkFMT04gfHwgU0NTSV9OQ1JfUTcy
MAorCWRlZmF1bHQgIjgiCisJLS0taGVscC0tLQorCSAgIlRhZ2dlZCBjb21tYW5kIHF1ZXVpbmci
IGlzIGEgZmVhdHVyZSBvZiBTQ1NJLTIgd2hpY2ggaW1wcm92ZXMKKwkgIHBlcmZvcm1hbmNlOiB0
aGUgaG9zdCBhZGFwdGVyIGNhbiBzZW5kIHNldmVyYWwgU0NTSSBjb21tYW5kcyB0byBhCisJICBk
ZXZpY2UncyBxdWV1ZSBldmVuIGlmIHByZXZpb3VzIGNvbW1hbmRzIGhhdmVuJ3QgZmluaXNoZWQg
eWV0LgorCSAgQmVjYXVzZSB0aGUgZGV2aWNlIGlzIGludGVsbGlnZW50LCBpdCBjYW4gb3B0aW1p
emUgaXRzIG9wZXJhdGlvbnMKKwkgIChsaWtlIGhlYWQgcG9zaXRpb25pbmcpIGJhc2VkIG9uIGl0
cyBvd24gcmVxdWVzdCBxdWV1ZS4gU29tZSBTQ1NJCisJICBkZXZpY2VzIGRvbid0IGltcGxlbWVu
dCB0aGlzIHByb3Blcmx5OyBpZiB5b3Ugd2FudCB0byBkaXNhYmxlIHRoaXMKKwkgIGZlYXR1cmUs
IGVudGVyIDAgb3IgMSBoZXJlIChpdCBkb2Vzbid0IG1hdHRlciB3aGljaCkuCisKKwkgIFRoZSBk
ZWZhdWx0IHZhbHVlIGlzIDggYW5kIHNob3VsZCBiZSBzdXBwb3J0ZWQgYnkgbW9zdCBoYXJkIGRp
c2tzLgorCSAgVGhpcyB2YWx1ZSBjYW4gYmUgb3ZlcnJpZGRlbiBmcm9tIHRoZSBib290IGNvbW1h
bmQgbGluZSB1c2luZyB0aGUKKwkgICd0YWdzJyBvcHRpb24gYXMgZm9sbG93cyAoZXhhbXBsZSk6
CisJICAnbmNyNTNjOHh4PXRhZ3M6NC90MnQzcTE2L3QwdTJxMTAnIHdpbGwgc2V0IGRlZmF1bHQg
cXVldWUgZGVwdGggdG8KKwkgIDQsIHNldCBxdWV1ZSBkZXB0aCB0byAxNiBmb3IgdGFyZ2V0IDIg
YW5kIHRhcmdldCAzIG9uIGNvbnRyb2xsZXIgMAorCSAgYW5kIHNldCBxdWV1ZSBkZXB0aCB0byAx
MCBmb3IgdGFyZ2V0IDAgLyBsdW4gMiBvbiBjb250cm9sbGVyIDEuCisKKwkgIFRoZSBub3JtYWwg
YW5zd2VyIHRoZXJlZm9yZSBpcyB0byBnbyB3aXRoIHRoZSBkZWZhdWx0IDggYW5kIHRvIHVzZQor
CSAgYSBib290IGNvbW1hbmQgbGluZSBvcHRpb24gZm9yIGRldmljZXMgdGhhdCBuZWVkIHRvIHVz
ZSBhIGRpZmZlcmVudAorCSAgY29tbWFuZCBxdWV1ZSBkZXB0aC4KKworCSAgVGhlcmUgaXMgbm8g
c2FmZSBvcHRpb24gb3RoZXIgdGhhbiB1c2luZyBnb29kIFNDU0kgZGV2aWNlcy4KKworY29uZmln
IFNDU0lfTkNSNTNDOFhYX01BWF9UQUdTCisJaW50ICJtYXhpbXVtIG51bWJlciBvZiBxdWV1ZWQg
Y29tbWFuZHMiCisJZGVwZW5kcyBvbiBTQ1NJX1pBTE9OIHx8IFNDU0lfTkNSX1E3MjAKKwlkZWZh
dWx0ICIzMiIKKwktLS1oZWxwLS0tCisJICBUaGlzIG9wdGlvbiBhbGxvd3MgeW91IHRvIHNwZWNp
ZnkgdGhlIG1heGltdW0gbnVtYmVyIG9mIGNvbW1hbmRzCisJICB0aGF0IGNhbiBiZSBxdWV1ZWQg
dG8gYW55IGRldmljZSwgd2hlbiB0YWdnZWQgY29tbWFuZCBxdWV1aW5nIGlzCisJICBwb3NzaWJs
ZS4gVGhlIGRlZmF1bHQgdmFsdWUgaXMgMzIuIE1pbmltdW0gaXMgMiwgbWF4aW11bSBpcyA2NC4K
KwkgIE1vZGVybiBoYXJkIGRpc2tzIGFyZSBhYmxlIHRvIHN1cHBvcnQgNjQgdGFncyBhbmQgZXZl
biBtb3JlLCBidXQKKwkgIGRvIG5vdCBzZWVtIHRvIGJlIGZhc3RlciB3aGVuIG1vcmUgdGhhbiAz
MiB0YWdzIGFyZSBiZWluZyB1c2VkLgorCisJICBTbywgdGhlIG5vcm1hbCBhbnN3ZXIgaGVyZSBp
cyB0byBnbyB3aXRoIHRoZSBkZWZhdWx0IHZhbHVlIDMyIHVubGVzcworCSAgeW91IGFyZSB1c2lu
ZyB2ZXJ5IGxhcmdlIGhhcmQgZGlza3Mgd2l0aCBsYXJnZSBjYWNoZSAoPj0gMSBNQikgdGhhdAor
CSAgYXJlIGFibGUgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgbW9yZSB0aGFuIDMyIHRhZ2dlZCBjb21t
YW5kcy4KKworCSAgVGhlcmUgaXMgbm8gc2FmZSBvcHRpb24gYW5kIHRoZSBkZWZhdWx0IGFuc3dl
ciBpcyByZWNvbW1lbmRlZC4KKworY29uZmlnIFNDU0lfTkNSNTNDOFhYX1NZTkMKKwlpbnQgInN5
bmNocm9ub3VzIHRyYW5zZmVycyBmcmVxdWVuY3kgaW4gTUh6IgorCWRlcGVuZHMgb24gU0NTSV9a
QUxPTiB8fCBTQ1NJX05DUl9RNzIwCisJZGVmYXVsdCAiMjAiCisJLS0taGVscC0tLQorCSAgVGhl
IFNDU0kgUGFyYWxsZWwgSW50ZXJmYWNlLTIgU3RhbmRhcmQgZGVmaW5lcyA1IGNsYXNzZXMgb2Yg
dHJhbnNmZXIKKwkgIHJhdGVzOiBGQVNULTUsIEZBU1QtMTAsIEZBU1QtMjAsIEZBU1QtNDAgYW5k
IEZBU1QtODAuICBUaGUgbnVtYmVycworCSAgYXJlIHJlc3BlY3RpdmVseSB0aGUgbWF4aW11bSBk
YXRhIHRyYW5zZmVyIHJhdGVzIGluIG1lZ2EtdHJhbnNmZXJzCisJICBwZXIgc2Vjb25kIGZvciBl
YWNoIGNsYXNzLiAgRm9yIGV4YW1wbGUsIGEgRkFTVC0yMCBXaWRlIDE2IGRldmljZSBpcworCSAg
YWJsZSB0byB0cmFuc2ZlciBkYXRhIGF0IDIwIG1pbGxpb24gMTYgYml0IHBhY2tldHMgcGVyIHNl
Y29uZCBmb3IgYQorCSAgdG90YWwgcmF0ZSBvZiA0MCBNQi9zLgorCisJICBZb3UgbWF5IHNwZWNp
ZnkgMCBpZiB5b3Ugd2FudCB0byBvbmx5IHVzZSBhc3luY2hyb25vdXMgZGF0YQorCSAgdHJhbnNm
ZXJzLiBUaGlzIGlzIHRoZSBzYWZlc3QgYW5kIHNsb3dlc3Qgb3B0aW9uLiBPdGhlcndpc2UsIHNw
ZWNpZnkKKwkgIGEgdmFsdWUgYmV0d2VlbiA1IGFuZCA4MCwgZGVwZW5kaW5nIG9uIHRoZSBjYXBh
YmlsaXR5IG9mIHlvdXIgU0NTSQorCSAgY29udHJvbGxlci4gIFRoZSBoaWdoZXIgdGhlIG51bWJl
ciwgdGhlIGZhc3RlciB0aGUgZGF0YSB0cmFuc2Zlci4KKwkgIE5vdGUgdGhhdCA4MCBzaG91bGQg
bm9ybWFsbHkgYmUgb2sgc2luY2UgdGhlIGRyaXZlciBkZWNyZWFzZXMgdGhlCisJICB2YWx1ZSBh
dXRvbWF0aWNhbGx5IGFjY29yZGluZyB0byB0aGUgY29udHJvbGxlcidzIGNhcGFiaWxpdGllcy4K
KworCSAgWW91ciBhbnN3ZXIgdG8gdGhpcyBxdWVzdGlvbiBpcyBpZ25vcmVkIGZvciBjb250cm9s
bGVycyB3aXRoIE5WUkFNLAorCSAgc2luY2UgdGhlIGRyaXZlciB3aWxsIGdldCB0aGlzIGluZm9y
bWF0aW9uIGZyb20gdGhlIHVzZXIgc2V0LXVwLiAgSXQKKwkgIGFsc28gY2FuIGJlIG92ZXJyaWRk
ZW4gdXNpbmcgYSBib290IHNldHVwIG9wdGlvbiwgYXMgZm9sbG93cworCSAgKGV4YW1wbGUpOiAn
bmNyNTNjOHh4PXN5bmM6MTInIHdpbGwgYWxsb3cgdGhlIGRyaXZlciB0byBuZWdvdGlhdGUKKwkg
IGZvciBGQVNULTIwIHN5bmNocm9ub3VzIGRhdGEgdHJhbnNmZXIgKDIwIG1lZ2EtdHJhbnNmZXJz
IHBlcgorCSAgc2Vjb25kKS4KKworCSAgVGhlIG5vcm1hbCBhbnN3ZXIgdGhlcmVmb3JlIGlzIG5v
dCB0byBnbyB3aXRoIHRoZSBkZWZhdWx0IGJ1dCB0bworCSAgc2VsZWN0IHRoZSBtYXhpbXVtIHZh
bHVlIDgwIGFsbG93aW5nIHRoZSBkcml2ZXIgdG8gdXNlIHRoZSBtYXhpbXVtCisJICB2YWx1ZSBz
dXBwb3J0ZWQgYnkgZWFjaCBjb250cm9sbGVyLiBJZiB0aGlzIGNhdXNlcyBwcm9ibGVtcyB3aXRo
CisJICB5b3VyIFNDU0kgZGV2aWNlcywgeW91IHNob3VsZCBjb21lIGJhY2sgYW5kIGRlY3JlYXNl
IHRoZSB2YWx1ZS4KKworCSAgVGhlcmUgaXMgbm8gc2FmZSBvcHRpb24gb3RoZXIgdGhhbiB1c2lu
ZyBnb29kIGNhYmxpbmcsIHJpZ2h0CisJICB0ZXJtaW5hdGlvbnMgYW5kIFNDU0kgY29uZm9ybWFu
dCBkZXZpY2VzLgorCitjb25maWcgU0NTSV9OQ1I1M0M4WFhfTk9fRElTQ09OTkVDVAorCWJvb2wg
Im5vdCBhbGxvdyB0YXJnZXRzIHRvIGRpc2Nvbm5lY3QiCisJZGVwZW5kcyBvbiAoU0NTSV9aQUxP
TiB8fCBTQ1NJX05DUl9RNzIwKSAmJiBTQ1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9MAorCWhl
bHAKKwkgIFRoaXMgb3B0aW9uIGlzIG9ubHkgcHJvdmlkZWQgZm9yIHNhZmV0eSBpZiB5b3Ugc3Vz
cGVjdCBzb21lIFNDU0kKKwkgIGRldmljZSBvZiB5b3VycyB0byBub3Qgc3VwcG9ydCBwcm9wZXJs
eSB0aGUgdGFyZ2V0LWRpc2Nvbm5lY3QKKwkgIGZlYXR1cmUuIEluIHRoYXQgY2FzZSwgeW91IHdv
dWxkIHNheSBZIGhlcmUuIEluIGdlbmVyYWwgaG93ZXZlciwgdG8KKwkgIG5vdCBhbGxvdyB0YXJn
ZXRzIHRvIGRpc2Nvbm5lY3QgaXMgbm90IHJlYXNvbmFibGUgaWYgdGhlcmUgaXMgbW9yZQorCSAg
dGhhbiAxIGRldmljZSBvbiBhIFNDU0kgYnVzLiBUaGUgbm9ybWFsIGFuc3dlciB0aGVyZWZvcmUg
aXMgTi4KKworY29uZmlnIFNDU0lfUEFTMTYKKwl0cmlzdGF0ZSAiUEFTMTYgU0NTSSBzdXBwb3J0
IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwktLS1o
ZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIGEgU0NTSSBob3N0IGFkYXB0ZXIuICBJdCBp
cyBleHBsYWluZWQgaW4gc2VjdGlvbgorCSAgMy4xMCBvZiB0aGUgU0NTSS1IT1dUTywgYXZhaWxh
YmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4uICBJZiBp
dCBkb2Vzbid0IHdvcmsgb3V0CisJICBvZiB0aGUgYm94LCB5b3UgbWF5IGhhdmUgdG8gY2hhbmdl
IHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOmRyaXZlcnMvc2NzaS9wYXMxNi5oPi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcGFzMTYuCisKK2NvbmZpZyBTQ1NJX1FMT0dJQ19GQVMK
Kwl0cmlzdGF0ZSAiUWxvZ2ljIEZBUyBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBJU0EgJiYg
U0NTSQorCS0tLWhlbHAtLS0KKwkgIFRoaXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBJU0EsIFZMQiwg
YW5kIFBDTUNJQSB2ZXJzaW9ucyBvZiB0aGUgUWxvZ2ljCisJICBGYXN0U0NTSSEgY2FyZHMgYXMg
d2VsbCBhcyBhbnkgb3RoZXIgY2FyZCBiYXNlZCBvbiB0aGUgRkFTWFggY2hpcAorCSAgKGluY2x1
ZGluZyB0aGUgQ29udHJvbCBDb25jZXB0cyBTQ1NJL0lERS9TSU8vUElPL0ZEQyBjYXJkcykuCisK
KwkgIFRoaXMgZHJpdmVyIGRvZXMgTk9UIHN1cHBvcnQgdGhlIFBDSSB2ZXJzaW9ucyBvZiB0aGVz
ZSBjYXJkcy4gVGhlCisJICBQQ0kgdmVyc2lvbnMgYXJlIHN1cHBvcnRlZCBieSB0aGUgUWxvZ2lj
IElTUCBkcml2ZXIgKCJRbG9naWMgSVNQCisJICBTQ1NJIHN1cHBvcnQiKSwgYmVsb3cuCisKKwkg
IEluZm9ybWF0aW9uIGFib3V0IHRoaXMgZHJpdmVyIGlzIGNvbnRhaW5lZCBpbgorCSAgPGZpbGU6
RG9jdW1lbnRhdGlvbi9zY3NpL3Fsb2dpY2Zhcy50eHQ+LiAgWW91IHNob3VsZCBhbHNvIHJlYWQg
dGhlCisJICBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5v
cmcvZG9jcy5odG1sI2hvd3RvPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1v
ZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcWxvZ2lj
ZmFzLgorCitjb25maWcgU0NTSV9RTE9HSUNfMTI4MAorCXRyaXN0YXRlICJRbG9naWMgUUxBIDEy
NDAvMXg4MC8xeDE2MCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhl
bHAKKwkgIFNheSBZIGlmIHlvdSBoYXZlIGEgUUxvZ2ljIElTUDEyNDAvMXg4MC8xeDE2MCBTQ1NJ
IGhvc3QgYWRhcHRlci4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcWxhMTI4MC4KKwor
Y29uZmlnIFNDU0lfUUxPR0lDUFRJCisJdHJpc3RhdGUgIlBUSSBRbG9naWMsIElTUCBEcml2ZXIi
CisJZGVwZW5kcyBvbiBTQlVTICYmIFNDU0kKKwloZWxwCisJICBUaGlzIGRyaXZlciBzdXBwb3J0
cyBTQlVTIFNDU0kgY29udHJvbGxlcnMgZnJvbSBQVEkgb3IgUUxvZ2ljLiBUaGVzZQorCSAgY29u
dHJvbGxlcnMgYXJlIGtub3duIHVuZGVyIFNvbGFyaXMgYXMgcXB0aSBhbmQgaW4gdGhlIG9wZW5w
cm9tIGFzCisJICBQVEkscHRpc3Agb3IgUUxHQyxpc3AuIE5vdGUgdGhhdCBQQ0kgUUxvZ2ljIFND
U0kgY29udHJvbGxlcnMgYXJlCisJICBkcml2ZW4gYnkgYSBkaWZmZXJlbnQgZHJpdmVyLgorCisJ
ICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUK
KwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBxbG9naWNwdGkuCisKK3NvdXJjZSAiZHJpdmVycy9z
Y3NpL3FsYTJ4eHgvS2NvbmZpZyIKK3NvdXJjZSAiZHJpdmVycy9zY3NpL3FsYTR4eHgvS2NvbmZp
ZyIKKworY29uZmlnIFNDU0lfTFBGQworCXRyaXN0YXRlICJFbXVsZXggTGlnaHRQdWxzZSBGaWJy
ZSBDaGFubmVsIFN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCXNlbGVjdCBTQ1NJ
X0ZDX0FUVFJTCisJaGVscAorICAgICAgICAgIFRoaXMgbHBmYyBkcml2ZXIgc3VwcG9ydHMgdGhl
IEVtdWxleCBMaWdodFB1bHNlCisgICAgICAgICAgRmFtaWx5IG9mIEZpYnJlIENoYW5uZWwgUENJ
IGhvc3QgYWRhcHRlcnMuCisKK2NvbmZpZyBTQ1NJX0xQRkNfREVCVUdfRlMKKwlib29sICJFbXVs
ZXggTGlnaHRQdWxzZSBGaWJyZSBDaGFubmVsIGRlYnVnZnMgU3VwcG9ydCIKKwlkZXBlbmRzIG9u
IFNDU0lfTFBGQyAmJiBERUJVR19GUworCWhlbHAKKwkgIFRoaXMgbWFrZXMgZGVidWdnaW5nIGlu
Zm9ybWF0aW9uIGZyb20gdGhlIGxwZmMgZHJpdmVyCisJICBhdmFpbGFibGUgdmlhIHRoZSBkZWJ1
Z2ZzIGZpbGVzeXN0ZW0uCisKK2NvbmZpZyBTQ1NJX1NJTTcxMAorCXRyaXN0YXRlICJTaW1wbGUg
NTNjNzEwIFNDU0kgc3VwcG9ydCAoQ29tcGFxLCBOQ1IgbWFjaGluZXMpIgorCWRlcGVuZHMgb24g
KEVJU0EgfHwgTUNBKSAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJLS0taGVscC0t
LQorCSAgVGhpcyBkcml2ZXIgaXMgZm9yIE5DUjUzYzcxMCBiYXNlZCBTQ1NJIGhvc3QgYWRhcHRl
cnMuCisKKwkgIEl0IGN1cnJlbnRseSBzdXBwb3J0cyBDb21wYXEgRUlTQSBjYXJkcyBhbmQgTkNS
IE1DQSBjYXJkcworCitjb25maWcgU0NTSV9TWU01M0M0MTYKKwl0cmlzdGF0ZSAiU3ltYmlvcyA1
M2M0MTYgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kKKwktLS1oZWxwLS0t
CisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRoZSBzeW01M2M0MTYgU0NTSSBob3N0IGFkYXB0ZXIs
IHRoZSBTQ1NJCisJICBhZGFwdGVyIHRoYXQgY29tZXMgd2l0aCBzb21lIEhQIHNjYW5uZXJzLiBU
aGlzIGRyaXZlciByZXF1aXJlcyB0aGF0CisJICB0aGUgc3ltNTNjNDE2IGlzIGNvbmZpZ3VyZWQg
Zmlyc3QgdXNpbmcgc29tZSBzb3J0IG9mIFBuUAorCSAgY29uZmlndXJhdGlvbiBwcm9ncmFtIChl
LmcuIGlzYXBucCkgb3IgYnkgYSBQblAgYXdhcmUgQklPUy4gSWYgeW91CisJICBhcmUgdXNpbmcg
aXNhcG5wIHRoZW4geW91IG5lZWQgdG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZQor
CSAgYW5kIHRoZW4gbG9hZCBpdCB1c2luZyBpbnNtb2QgYWZ0ZXIgaXNhcG5wIGhhcyBydW4uIFRo
ZSBwYXJhbWV0ZXJzCisJICBvZiB0aGUgY29uZmlndXJlZCBjYXJkKHMpIHNob3VsZCBiZSBwYXNz
ZWQgdG8gdGhlIGRyaXZlci4gVGhlIGZvcm1hdAorCSAgaXM6CisKKwkgIGluc21vZCBzeW01M2M0
MTYgc3ltNTNjNDE2PTxiYXNlPiw8aXJxPiBbc3ltNTNjNDE2XzE9PGJhc2U+LDxpcnE+XQorCisJ
ICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUK
KwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBzeW01M2M0MTYuCisKK2NvbmZpZyBTQ1NJX0RDMzk1
eAorCXRyaXN0YXRlICJUZWtyYW0gREMzOTUoVS9VVy9GKSBhbmQgREMzMTUoVSkgU0NTSSBzdXBw
b3J0IChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kgJiYgRVhQRVJJTUVO
VEFMCisJLS0taGVscC0tLQorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgUENJIFNDU0kgaG9zdCBh
ZGFwdGVycyBiYXNlZCBvbiB0aGUgQVNJQworCSAgVFJNLVMxMDQwIGNoaXAsIGUuZyBUZWtyYW0g
REMzOTUoVS9VVy9GKSBhbmQgREMzMTUoVSkgdmFyaWFudHMuCisKKwkgIFRoaXMgZHJpdmVyIHdv
cmtzLCBidXQgaXMgc3RpbGwgaW4gZXhwZXJpbWVudGFsIHN0YXR1cy4gU28gYmV0dGVyCisJICBo
YXZlIGEgYm9vdGFibGUgZGlzayBhbmQgYSBiYWNrdXAgaW4gY2FzZSBvZiBlbWVyZ2VuY3kuCisK
KwkgIERvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kIGluIDxmaWxlOkRvY3VtZW50YXRpb24vc2Nz
aS9kYzM5NXgudHh0Pi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZGMzOTV4LgorCitj
b25maWcgU0NTSV9EQzM5MFQKKwl0cmlzdGF0ZSAiVGVrcmFtIERDMzkwKFQpIGFuZCBBbTUzLzc5
Qzk3NCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCS0tLWhlbHAtLS0K
KwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIFBDSSBTQ1NJIGhvc3QgYWRhcHRlcnMgYmFzZWQgb24g
dGhlIEFtNTNDOTc0QQorCSAgY2hpcCwgZS5nLiBUZWtyYW0gREMzOTAoVCksIERhd2lDb250cm9s
IDI5NzQgYW5kIHNvbWUgb25ib2FyZAorCSAgUENzY3NpL1BDbmV0IChBbTUzLzc5Qzk3NCkgc29s
dXRpb25zLgorCisJICBEb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiA8ZmlsZTpEb2N1bWVu
dGF0aW9uL3Njc2kvdG1zY3NpbS50eHQ+LgorCisJICBOb3RlIHRoYXQgdGhpcyBkcml2ZXIgZG9l
cyBOT1Qgc3VwcG9ydCBUZWtyYW0gREMzOTBXL1UvRiwgd2hpY2ggYXJlCisJICBiYXNlZCBvbiBO
Q1IvU3ltYmlvcyBjaGlwcy4gVXNlICJOQ1I1M0M4WFggU0NTSSBzdXBwb3J0IiBmb3IgdGhvc2Uu
CisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmU6
IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHRtc2NzaW0uCisKK2NvbmZpZyBTQ1NJX1Qx
MjgKKwl0cmlzdGF0ZSAiVHJhbnRvciBUMTI4L1QxMjhGL1QyMjggU0NTSSBzdXBwb3J0IgorCWRl
cGVuZHMgb24gSVNBICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwlzZWxlY3QgQ0hF
Q0tfU0lHTkFUVVJFCisJLS0taGVscC0tLQorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciBhIFNDU0kg
aG9zdCBhZGFwdGVyLiBJdCBpcyBleHBsYWluZWQgaW4gc2VjdGlvbgorCSAgMy4xMSBvZiB0aGUg
U0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3Mu
aHRtbCNob3d0bz4uICBJZiBpdCBkb2Vzbid0IHdvcmsgb3V0CisJICBvZiB0aGUgYm94LCB5b3Ug
bWF5IGhhdmUgdG8gY2hhbmdlIHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOmRyaXZlcnMvc2Nz
aS90MTI4Lmg+LiAgTm90ZSB0aGF0IFRyYW50b3Igd2FzIHB1cmNoYXNlZCBieQorCSAgQWRhcHRl
YywgYW5kIHNvbWUgZm9ybWVyIFRyYW50b3IgcHJvZHVjdHMgYXJlIGJlaW5nIHNvbGQgdW5kZXIg
dGhlCisJICBBZGFwdGVjIG5hbWUuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBt
b2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHQxMjgu
CisKK2NvbmZpZyBTQ1NJX1UxNF8zNEYKKwl0cmlzdGF0ZSAiVWx0cmFTdG9yIDE0Ri8zNEYgc3Vw
cG9ydCIKKwlkZXBlbmRzIG9uIElTQSAmJiBTQ1NJICYmIElTQV9ETUFfQVBJCisJLS0taGVscC0t
LQorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciB0aGUgVWx0cmFTdG9yIDE0RiBhbmQgMzRGIFNDU0kt
MiBob3N0IGFkYXB0ZXJzLgorCSAgVGhlIHNvdXJjZSBhdCA8ZmlsZTpkcml2ZXJzL3Njc2kvdTE0
LTM0Zi5jPiBjb250YWlucyBzb21lCisJICBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIGhhcmR3YXJl
LiAgSWYgdGhlIGRyaXZlciBkb2Vzbid0IHdvcmsgb3V0IG9mCisJICB0aGUgYm94LCB5b3UgbWF5
IGhhdmUgdG8gY2hhbmdlIHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOiBkcml2ZXJzL3Njc2kv
dTE0LTM0Zi5jPi4gIFJlYWQgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0
cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiAgTm90ZSB0aGF0IHRoZXJlIGlzIGFs
c28KKwkgIGFub3RoZXIgZHJpdmVyIGZvciB0aGUgc2FtZSBoYXJkd2FyZTogIlVsdHJhU3RvciBT
Q1NJIHN1cHBvcnQiLAorCSAgYmVsb3cuICBZb3Ugc2hvdWxkIHNheSBZIHRvIGJvdGggb25seSBp
ZiB5b3Ugd2FudCAyNEYgc3VwcG9ydCBhcworCSAgd2VsbC4KKworCSAgVG8gY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBi
ZSBjYWxsZWQgdTE0LTM0Zi4KKworY29uZmlnIFNDU0lfVTE0XzM0Rl9UQUdHRURfUVVFVUUKKwli
b29sICJlbmFibGUgdGFnZ2VkIGNvbW1hbmQgcXVldWVpbmciCisJZGVwZW5kcyBvbiBTQ1NJX1Ux
NF8zNEYKKwloZWxwCisJICBUaGlzIGlzIGEgZmVhdHVyZSBvZiBTQ1NJLTIgd2hpY2ggaW1wcm92
ZXMgcGVyZm9ybWFuY2U6IHRoZSBob3N0CisJICBhZGFwdGVyIGNhbiBzZW5kIHNldmVyYWwgU0NT
SSBjb21tYW5kcyB0byBhIGRldmljZSdzIHF1ZXVlIGV2ZW4gaWYKKwkgIHByZXZpb3VzIGNvbW1h
bmRzIGhhdmVuJ3QgZmluaXNoZWQgeWV0LgorCSAgVGhpcyBpcyBlcXVpdmFsZW50IHRvIHRoZSAi
dTE0LTM0Zj10Yzp5IiBib290IG9wdGlvbi4KKworY29uZmlnIFNDU0lfVTE0XzM0Rl9MSU5LRURf
Q09NTUFORFMKKwlib29sICJlbmFibGUgZWxldmF0b3Igc29ydGluZyIKKwlkZXBlbmRzIG9uIFND
U0lfVTE0XzM0RgorCWhlbHAKKwkgIFRoaXMgb3B0aW9uIGVuYWJsZXMgZWxldmF0b3Igc29ydGlu
ZyBmb3IgYWxsIHByb2JlZCBTQ1NJIGRpc2tzIGFuZAorCSAgQ0QtUk9Ncy4gSXQgZGVmaW5pdGVs
eSByZWR1Y2VzIHRoZSBhdmVyYWdlIHNlZWsgZGlzdGFuY2Ugd2hlbiBkb2luZworCSAgcmFuZG9t
IHNlZWtzLCBidXQgdGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBub3RpY2Vh
YmxlCisJICBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudDogeW91ciBtaWxlYWdlIG1heSB2YXJ5Li4u
CisJICBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhlICJ1MTQtMzRmPWxjOnkiIGJvb3Qgb3B0aW9u
LgorCitjb25maWcgU0NTSV9VMTRfMzRGX01BWF9UQUdTCisJaW50ICJtYXhpbXVtIG51bWJlciBv
ZiBxdWV1ZWQgY29tbWFuZHMiCisJZGVwZW5kcyBvbiBTQ1NJX1UxNF8zNEYKKwlkZWZhdWx0ICI4
IgorCWhlbHAKKwkgIFRoaXMgc3BlY2lmaWVzIGhvdyBtYW55IFNDU0kgY29tbWFuZHMgY2FuIGJl
IG1heGltYWxseSBxdWV1ZWQgZm9yCisJICBlYWNoIHByb2JlZCBTQ1NJIGRldmljZS4gWW91IHNo
b3VsZCByZWR1Y2UgdGhlIGRlZmF1bHQgdmFsdWUgb2YgOAorCSAgb25seSBpZiB5b3UgaGF2ZSBk
aXNrcyB3aXRoIGJ1Z2d5IG9yIGxpbWl0ZWQgdGFnZ2VkIGNvbW1hbmQgc3VwcG9ydC4KKwkgIE1p
bmltdW0gaXMgMiBhbmQgbWF4aW11bSBpcyAxNC4gVGhpcyB2YWx1ZSBpcyBhbHNvIHRoZSB3aW5k
b3cgc2l6ZQorCSAgdXNlZCBieSB0aGUgZWxldmF0b3Igc29ydGluZyBvcHRpb24gYWJvdmUuIFRo
ZSBlZmZlY3RpdmUgdmFsdWUgdXNlZAorCSAgYnkgdGhlIGRyaXZlciBmb3IgZWFjaCBwcm9iZWQg
U0NTSSBkZXZpY2UgaXMgcmVwb3J0ZWQgYXQgYm9vdCB0aW1lLgorCSAgVGhpcyBpcyBlcXVpdmFs
ZW50IHRvIHRoZSAidTE0LTM0Zj1tcTo4IiBib290IG9wdGlvbi4KKworY29uZmlnIFNDU0lfVUxU
UkFTVE9SCisJdHJpc3RhdGUgIlVsdHJhU3RvciBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBY
ODYgJiYgSVNBICYmIFNDU0kKKwktLS1oZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRo
ZSBVbHRyYVN0b3IgMTRGLCAyNEYgYW5kIDM0RiBTQ1NJLTIgaG9zdAorCSAgYWRhcHRlciBmYW1p
bHkuICBUaGlzIGRyaXZlciBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiAzLjEyIG9mIHRoZQorCSAg
U0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3Mu
aHRtbCNob3d0bz4uICBJZiBpdCBkb2Vzbid0IHdvcmsgb3V0CisJICBvZiB0aGUgYm94LCB5b3Ug
bWF5IGhhdmUgdG8gY2hhbmdlIHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOmRyaXZlcnMvc2Nz
aS91bHRyYXN0b3IuaD4uCisKKwkgIE5vdGUgdGhhdCB0aGVyZSBpcyBhbHNvIGFub3RoZXIgZHJp
dmVyIGZvciB0aGUgc2FtZSBoYXJkd2FyZToKKwkgICJVbHRyYVN0b3IgMTRGLzM0RiBzdXBwb3J0
IiwgYWJvdmUuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29z
ZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHVsdHJhc3Rvci4KKworY29u
ZmlnIFNDU0lfTlNQMzIKKwl0cmlzdGF0ZSAiV29ya2JpdCBOaW5qYVNDU0ktMzJCaS9VREUgc3Vw
cG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJICYmICE2NEJJVAorCWhlbHAKKwkgIFRoaXMg
aXMgc3VwcG9ydCBmb3IgdGhlIFdvcmtiaXQgTmluamFTQ1NJLTMyQmkvVURFIFBDSS9DYXJkYnVz
CisJICBTQ1NJIGhvc3QgYWRhcHRlci4gUGxlYXNlIHJlYWQgdGhlIFNDU0ktSE9XVE8sIGF2YWls
YWJsZSBmcm9tCisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LgorCisJ
ICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUK
KwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBuc3AzMi4KKworY29uZmlnIFNDU0lfREVCVUcKKwl0
cmlzdGF0ZSAiU0NTSSBkZWJ1Z2dpbmcgaG9zdCBzaW11bGF0b3IiCisJZGVwZW5kcyBvbiBTQ1NJ
CisJc2VsZWN0IENSQ19UMTBESUYKKwloZWxwCisJICBUaGlzIGlzIGEgaG9zdCBhZGFwdGVyIHNp
bXVsYXRvciB0aGF0IGNhbiBzaW11bGF0ZSBtdWx0aXBsZSBob3N0cworCSAgZWFjaCB3aXRoIG11
bHRpcGxlIGR1bW15IFNDU0kgZGV2aWNlcyAoZGlza3MpLiBJdCBkZWZhdWx0cyB0byBvbmUKKwkg
IGhvc3QgYWRhcHRlciB3aXRoIG9uZSBkdW1teSBTQ1NJIGRpc2suIEVhY2ggZHVtbXkgZGlzayB1
c2VzIGtlcm5lbAorCSAgUkFNIGFzIHN0b3JhZ2UgKGkuZS4gaXQgaXMgYSByYW1kaXNrKS4gVG8g
c2F2ZSBzcGFjZSB3aGVuIG11bHRpcGxlCisJICBkdW1teSBkaXNrcyBhcmUgc2ltdWxhdGVkLCB0
aGV5IHNoYXJlIHRoZSBzYW1lIGtlcm5lbCBSQU0gZm9yIAorCSAgdGhlaXIgc3RvcmFnZS4gU2Vl
IDxodHRwOi8vc2cuZGFubnkuY3ovc2cvc2RlYnVnMjYuaHRtbD4gZm9yIG1vcmUKKwkgIGluZm9y
bWF0aW9uLiBUaGlzIGRyaXZlciBpcyBwcmltYXJpbHkgb2YgdXNlIHRvIHRob3NlIHRlc3Rpbmcg
dGhlCisJICBTQ1NJIGFuZCBibG9jayBzdWJzeXN0ZW1zLiBJZiB1bnN1cmUsIHNheSBOLgorCitj
b25maWcgU0NTSV9NRVNICisJdHJpc3RhdGUgIk1FU0ggKFBvd2VyIE1hYyBpbnRlcm5hbCBTQ1NJ
KSBzdXBwb3J0IgorCWRlcGVuZHMgb24gUFBDMzIgJiYgUFBDX1BNQUMgJiYgU0NTSQorCWhlbHAK
KwkgIE1hbnkgUG93ZXIgTWFjaW50b3NoZXMgYW5kIGNsb25lcyBoYXZlIGEgTUVTSCAoTWFjaW50
b3NoIEVuaGFuY2VkCisJICBTQ1NJIEhhcmR3YXJlKSBTQ1NJIGJ1cyBhZGFwdG9yICh0aGUgNzIw
MCBkb2Vzbid0LCBidXQgYWxsIG9mIHRoZQorCSAgb3RoZXIgUG93ZXIgTWFjaW50b3NoZXMgZG8p
LiBTYXkgWSB0byBpbmNsdWRlIHN1cHBvcnQgZm9yIHRoaXMgU0NTSQorCSAgYWRhcHRvci4KKwor
CSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhl
CisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgbWVzaC4KKworY29uZmlnIFNDU0lfTUVTSF9TWU5D
X1JBVEUKKwlpbnQgIm1heGltdW0gc3luY2hyb25vdXMgdHJhbnNmZXIgcmF0ZSAoTUIvcykgKDAg
PSBhc3luYykiCisJZGVwZW5kcyBvbiBTQ1NJX01FU0gKKwlkZWZhdWx0ICI1IgorCWhlbHAKKwkg
IE9uIFBvd2VyIE1hY2ludG9zaGVzIChhbmQgY2xvbmVzKSB3aGVyZSB0aGUgTUVTSCBTQ1NJIGJ1
cyBhZGFwdG9yCisJICBkcml2ZXMgYSBidXMgd2hpY2ggaXMgZW50aXJlbHkgaW50ZXJuYWwgdG8g
dGhlIG1hY2hpbmUgKHN1Y2ggYXMgdGhlCisJICA3NTAwLCA3NjAwLCA4NTAwLCBldGMuKSwgdGhl
IE1FU0ggaXMgY2FwYWJsZSBvZiBzeW5jaHJvbm91cworCSAgb3BlcmF0aW9uIGF0IHVwIHRvIDEw
IE1CL3MuIE9uIG1hY2hpbmVzIHdoZXJlIHRoZSBTQ1NJIGJ1cworCSAgY29udHJvbGxlZCBieSB0
aGUgTUVTSCBjYW4gaGF2ZSBleHRlcm5hbCBkZXZpY2VzIGNvbm5lY3RlZCwgaXQgaXMKKwkgIHVz
dWFsbHkgcmF0ZWQgYXQgNSBNQi9zLiA1IGlzIGEgc2FmZSB2YWx1ZSBoZXJlIHVubGVzcyB5b3Ug
a25vdyB0aGUKKwkgIE1FU0ggU0NTSSBidXMgaXMgaW50ZXJuYWwgb25seTsgaW4gdGhhdCBjYXNl
IHlvdSBjYW4gc2F5IDEwLiBTYXkgMAorCSAgdG8gZGlzYWJsZSBzeW5jaHJvbm91cyBvcGVyYXRp
b24uCisKK2NvbmZpZyBTQ1NJX01FU0hfUkVTRVRfREVMQVlfTVMKKwlpbnQgImluaXRpYWwgYnVz
IHJlc2V0IGRlbGF5IChtcykgKDAgPSBubyByZXNldCkiCisJZGVwZW5kcyBvbiBTQ1NJX01FU0gK
KwlkZWZhdWx0ICI0MDAwIgorCitjb25maWcgU0NTSV9NQUM1M0M5NAorCXRyaXN0YXRlICI1M0M5
NCAoUG93ZXIgTWFjIGV4dGVybmFsIFNDU0kpIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQUEMzMiAm
JiBQUENfUE1BQyAmJiBTQ1NJCisJaGVscAorCSAgT24gUG93ZXIgTWFjaW50b3NoZXMgKGFuZCBj
bG9uZXMpIHdpdGggdHdvIFNDU0kgYnVzZXMsIHRoZSBleHRlcm5hbAorCSAgU0NTSSBidXMgaXMg
dXN1YWxseSBjb250cm9sbGVkIGJ5IGEgNTNDOTQgU0NTSSBidXMgYWRhcHRvci4gT2xkZXIKKwkg
IG1hY2hpbmVzIHdoaWNoIG9ubHkgaGF2ZSBvbmUgU0NTSSBidXMsIHN1Y2ggYXMgdGhlIDcyMDAs
IGFsc28gdXNlCisJICB0aGUgNTNDOTQuIFNheSBZIHRvIGluY2x1ZGUgc3VwcG9ydCBmb3IgdGhl
IDUzQzk0LgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2Ug
TSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBtYWM1M2M5NC4KKworc291cmNl
ICJkcml2ZXJzL3Njc2kvYXJtL0tjb25maWciCisKK2NvbmZpZyBKQVpaX0VTUAorCWJvb2wgIk1J
UFMgSkFaWiBGQVMyMTYgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gTUFDSF9KQVpaICYmIFND
U0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJICBUaGlzIGlzIHRoZSBkcml2ZXIg
Zm9yIHRoZSBvbmJvYXJkIFNDU0kgaG9zdCBhZGFwdGVyIG9mIE1JUFMgTWFnbnVtCisJICA0MDAw
LCBBY2VyIFBJQ0EsIE9saXZldHRpIE03MDAtMTAgYW5kIGEgZmV3IG90aGVyIGlkZW50aWNhbCBP
RU0KKwkgIHN5c3RlbXMuCisKK2NvbmZpZyBBMzAwMF9TQ1NJCisJdHJpc3RhdGUgIkEzMDAwIFdE
MzNDOTNBIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBBTUlHQSAmJiBTQ1NJCisJaGVscAorCSAgSWYg
eW91IGhhdmUgYW4gQW1pZ2EgMzAwMCBhbmQgaGF2ZSBTQ1NJIGRldmljZXMgY29ubmVjdGVkIHRv
IHRoZQorCSAgYnVpbHQtaW4gU0NTSSBjb250cm9sbGVyLCBzYXkgWS4gT3RoZXJ3aXNlLCBzYXkg
Ti4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVy
ZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYTMwMDAuCisKK2NvbmZpZyBBMjA5MV9T
Q1NJCisJdHJpc3RhdGUgIkEyMDkxL0E1OTAgV0QzM0M5M0Egc3VwcG9ydCIKKwlkZXBlbmRzIG9u
IFpPUlJPICYmIFNDU0kKKwloZWxwCisJICBJZiB5b3UgaGF2ZSBhIENvbW1vZG9yZSBBMjA5MSBT
Q1NJIGNvbnRyb2xsZXIsIHNheSBZLiBPdGhlcndpc2UsCisJICBzYXkgTi4KKworCSAgVG8gY29t
cGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1
bGUgd2lsbCBiZSBjYWxsZWQgYTIwOTEuCisKK2NvbmZpZyBHVlAxMV9TQ1NJCisJdHJpc3RhdGUg
IkdWUCBTZXJpZXMgSUkgV0QzM0M5M0Egc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFpPUlJPICYmIFND
U0kKKwktLS1oZWxwLS0tCisJICBJZiB5b3UgaGF2ZSBhIEdyZWF0IFZhbGxleSBQcm9kdWN0cyBT
ZXJpZXMgSUkgU0NTSSBjb250cm9sbGVyLAorCSAgYW5zd2VyIFkuIEFsc28gc2F5IFkgaWYgeW91
IGhhdmUgYSBsYXRlciBtb2RlbCBvZiBHVlAgU0NTSQorCSAgY29udHJvbGxlciAoc3VjaCBhcyB0
aGUgR1ZQIEE0MDA4IG9yIGEgQ29tYm8gYm9hcmQpLiBPdGhlcndpc2UsCisJICBhbnN3ZXIgTi4g
VGhpcyBkcml2ZXIgZG9lcyBOT1Qgd29yayBmb3IgdGhlIFQtUmV4IHNlcmllcyBvZgorCSAgYWNj
ZWxlcmF0b3JzIGZyb20gVGVrTWFnaWMgYW5kIEdWUC1NLgorCisJICBUbyBjb21waWxlIHRoaXMg
ZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJl
IGNhbGxlZCBndnAxMS4KKworY29uZmlnIFNDU0lfQTQwMDBUCisJdHJpc3RhdGUgIkE0MDAwVCBO
Q1I1M2M3MTAgU0NTSSBzdXBwb3J0IChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gQU1JR0Eg
JiYgU0NTSSAmJiBFWFBFUklNRU5UQUwKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJ
ICBJZiB5b3UgaGF2ZSBhbiBBbWlnYSA0MDAwVCBhbmQgaGF2ZSBTQ1NJIGRldmljZXMgY29ubmVj
dGVkIHRvIHRoZQorCSAgYnVpbHQtaW4gU0NTSSBjb250cm9sbGVyLCBzYXkgWS4gT3RoZXJ3aXNl
LCBzYXkgTi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3Nl
IE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYTQwMDB0LgorCitjb25maWcg
U0NTSV9aT1JSTzdYWAorCXRyaXN0YXRlICJab3JybyBOQ1I1M2M3MTAgU0NTSSBzdXBwb3J0IChF
WFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gWk9SUk8gJiYgU0NTSSAmJiBFWFBFUklNRU5UQUwK
KwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJICBTdXBwb3J0IGZvciB2YXJpb3VzIE5D
UjUzYzcxMC1iYXNlZCBTQ1NJIGNvbnRyb2xsZXJzIG9uIFpvcnJvCisJICBleHBhbnNpb24gYm9h
cmRzIGZvciB0aGUgQW1pZ2EuCisJICBUaGlzIGluY2x1ZGVzOgorCSAgICAtIHRoZSBBbWlnYSA0
MDkxIFpvcnJvIElJSSBTQ1NJLTIgY29udHJvbGxlciwKKwkgICAgLSB0aGUgTWFjcm9TeXN0ZW0g
RGV2ZWxvcG1lbnQncyBXYXJwRW5naW5lIEFtaWdhIFNDU0ktMiBjb250cm9sbGVyCisJICAgICAg
KGluZm8gYXQKKwkgICAgICA8aHR0cDovL3d3dy5seXNhdG9yLmxpdS5zZS9hbWlnYS9hci9ndWlk
ZS9hcjMxMC5ndWlkZT9GRUFUVVJFNT4pLAorCSAgICAtIHRoZSBTQ1NJIGNvbnRyb2xsZXIgb24g
dGhlIFBoYXNlNSBCbGl6emFyZCBQb3dlclVQIDYwM2UrCisJICAgICAgYWNjZWxlcmF0b3IgY2Fy
ZCBmb3IgdGhlIEFtaWdhIDEyMDAsCisJICAgIC0gdGhlIFNDU0kgY29udHJvbGxlciBvbiB0aGUg
R1ZQIFR1cmJvIDA0MC8wNjAgYWNjZWxlcmF0b3IuCisKK2NvbmZpZyBBVEFSSV9TQ1NJCisJdHJp
c3RhdGUgIkF0YXJpIG5hdGl2ZSBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBBVEFSSSAmJiBT
Q1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJc2VsZWN0IE5WUkFNCisJLS0taGVscC0tLQor
CSAgSWYgeW91IGhhdmUgYW4gQXRhcmkgd2l0aCBidWlsdC1pbiBOQ1I1MzgwIFNDU0kgY29udHJv
bGxlciAoVFQsCisJICBGYWxjb24sIC4uLikgc2F5IFkgdG8gZ2V0IGl0IHN1cHBvcnRlZC4gT2Yg
Y291cnNlIGFsc28sIGlmIHlvdSBoYXZlCisJICBhIGNvbXBhdGlibGUgU0NTSSBjb250cm9sbGVy
IChlLmcuIGZvciBNZWR1c2EpLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9k
dWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBhdGFyaV9z
Y3NpLgorCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyBib3RoIHN0eWxlcyBvZiBOQ1IgaW50ZWdy
YXRpb24gaW50byB0aGUKKwkgIHN5c3RlbTogdGhlIFRUIHN0eWxlIChzZXBhcmF0ZSBETUEpLCBh
bmQgdGhlIEZhbGNvbiBzdHlsZSAodmlhCisJICBTVC1ETUEsIHJlcGxhY2luZyBBQ1NJKS4gIEl0
IGRvZXMgTk9UIHN1cHBvcnQgb3RoZXIgc2NoZW1lcywgbGlrZQorCSAgaW4gdGhlIEhhZGVzICh3
aXRob3V0IERNQSkuCisKK2NvbmZpZyBBVEFSSV9TQ1NJX1RPU0hJQkFfREVMQVkKKwlib29sICJM
b25nIGRlbGF5cyBmb3IgVG9zaGliYSBDRC1ST01zIgorCWRlcGVuZHMgb24gQVRBUklfU0NTSQor
CWhlbHAKKwkgIFRoaXMgb3B0aW9uIGluY3JlYXNlcyB0aGUgZGVsYXkgYWZ0ZXIgYSBTQ1NJIGFy
Yml0cmF0aW9uIHRvCisJICBhY2NvbW1vZGF0ZSBzb21lIGZsYWt5IFRvc2hpYmEgQ0QtUk9NIGRy
aXZlcy4gU2F5IFkgaWYgeW91IGludGVuZCB0bworCSAgdXNlIGEgVG9zaGliYSBDRC1ST00gZHJp
dmU7IG90aGVyd2lzZSwgdGhlIG9wdGlvbiBpcyBub3QgbmVlZGVkIGFuZAorCSAgd291bGQgaW1w
YWN0IHBlcmZvcm1hbmNlIGEgYml0LCBzbyBzYXkgTi4KKworY29uZmlnIEFUQVJJX1NDU0lfUkVT
RVRfQk9PVAorCWJvb2wgIlJlc2V0IFNDU0ktZGV2aWNlcyBhdCBib290dGltZSIKKwlkZXBlbmRz
IG9uIEFUQVJJX1NDU0kKKwloZWxwCisJICBSZXNldCB0aGUgZGV2aWNlcyBvbiB5b3VyIEF0YXJp
IHdoZW5ldmVyIGl0IGJvb3RzLiAgVGhpcyBtYWtlcyB0aGUKKwkgIGJvb3QgcHJvY2VzcyBmcmFj
dGlvbmFsbHkgbG9uZ2VyIGJ1dCBtYXkgYXNzaXN0IHJlY292ZXJ5IGZyb20gZXJyb3JzCisJICB0
aGF0IGxlYXZlIHRoZSBkZXZpY2VzIHdpdGggU0NTSSBvcGVyYXRpb25zIHBhcnR3YXkgY29tcGxl
dGVkLgorCitjb25maWcgTUFDX1NDU0kKKwlib29sICJNYWNpbnRvc2ggTkNSNTM4MCBTQ1NJIgor
CWRlcGVuZHMgb24gTUFDICYmIFNDU0k9eQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAK
KwkgIFRoaXMgaXMgdGhlIE5DUiA1MzgwIFNDU0kgY29udHJvbGxlciBpbmNsdWRlZCBvbiBtb3N0
IG9mIHRoZSA2ODAzMAorCSAgYmFzZWQgTWFjaW50b3NoZXMuICBJZiB5b3UgaGF2ZSBvbmUgb2Yg
dGhlc2Ugc2F5IFkgYW5kIHJlYWQgdGhlCisJICBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQor
CSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4KKworY29uZmlnIFNDU0lf
TUFDX0VTUAorCXRyaXN0YXRlICJNYWNpbnRvc2ggTkNSNTNjOVs0Nl0gU0NTSSIKKwlkZXBlbmRz
IG9uIE1BQyAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJaGVscAorCSAgVGhpcyBp
cyB0aGUgTkNSIDUzYzl4IFNDU0kgY29udHJvbGxlciBmb3VuZCBvbiBtb3N0IG9mIHRoZSA2ODA0
MAorCSAgYmFzZWQgTWFjaW50b3NoZXMuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMg
YSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZSBtb2R1bGUKKwkgIHdpbGwgYmUgY2FsbGVkIG1h
Y19lc3AuCisKK2NvbmZpZyBNVk1FMTQ3X1NDU0kKKwlib29sICJXRDMzQzkzIFNDU0kgZHJpdmVy
IGZvciBNVk1FMTQ3IgorCWRlcGVuZHMgb24gTVZNRTE0NyAmJiBTQ1NJPXkKKwlzZWxlY3QgU0NT
SV9TUElfQVRUUlMKKwloZWxwCisJICBTdXBwb3J0IGZvciB0aGUgb24tYm9hcmQgU0NTSSBjb250
cm9sbGVyIG9uIHRoZSBNb3Rvcm9sYSBNVk1FMTQ3CisJICBzaW5nbGUtYm9hcmQgY29tcHV0ZXIu
CisKK2NvbmZpZyBNVk1FMTZ4X1NDU0kKKwl0cmlzdGF0ZSAiTkNSNTNDNzEwIFNDU0kgZHJpdmVy
IGZvciBNVk1FMTZ4IgorCWRlcGVuZHMgb24gTVZNRTE2eCAmJiBTQ1NJCisJc2VsZWN0IFNDU0lf
U1BJX0FUVFJTCisJaGVscAorCSAgVGhlIE1vdG9yb2xhIE1WTUUxNjIsIDE2NiwgMTY3LCAxNzIg
YW5kIDE3NyBib2FyZHMgdXNlIHRoZSBOQ1I1M0M3MTAKKwkgIFNDU0kgY29udHJvbGxlciBjaGlw
LiAgQWxtb3N0IGV2ZXJ5b25lIHVzaW5nIG9uZSBvZiB0aGVzZSBib2FyZHMKKwkgIHdpbGwgd2Fu
dCB0byBzYXkgWSB0byB0aGlzIHF1ZXN0aW9uLgorCitjb25maWcgQlZNRTYwMDBfU0NTSQorCXRy
aXN0YXRlICJOQ1I1M0M3MTAgU0NTSSBkcml2ZXIgZm9yIEJWTUU2MDAwIgorCWRlcGVuZHMgb24g
QlZNRTYwMDAgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoZSBC
Vk1FNDAwMCBhbmQgQlZNRTYwMDAgYm9hcmRzIGZyb20gQlZNIEx0ZCB1c2UgdGhlIE5DUjUzQzcx
MAorCSAgU0NTSSBjb250cm9sbGVyIGNoaXAuICBBbG1vc3QgZXZlcnlvbmUgdXNpbmcgb25lIG9m
IHRoZXNlIGJvYXJkcworCSAgd2lsbCB3YW50IHRvIHNheSBZIHRvIHRoaXMgcXVlc3Rpb24uCisK
K2NvbmZpZyBTVU4zX1NDU0kKKwl0cmlzdGF0ZSAiU3VuMyBOQ1I1MzgwIFNDU0kiCisJZGVwZW5k
cyBvbiBTVU4zICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJICBUaGlz
IG9wdGlvbiB3aWxsIGVuYWJsZSBzdXBwb3J0IGZvciB0aGUgT0JJTyAob25ib2FyZCBpbykgTkNS
NTM4MAorCSAgU0NTSSBjb250cm9sbGVyIGZvdW5kIGluIHRoZSBTdW4gMy81MCBhbmQgMy82MCwg
YXMgd2VsbCBhcyBmb3IKKwkgICJTdW4zIiB0eXBlIFZNRSBzY3NpIGNvbnRyb2xsZXJzIGFsc28g
YmFzZWQgb24gdGhlIE5DUjUzODAuCisJICBHZW5lcmFsIExpbnV4IGluZm9ybWF0aW9uIG9uIHRo
ZSBTdW4gMyBzZXJpZXMgKG5vdyBkaXNjb250aW51ZWQpCisJICBpcyBhdCA8aHR0cDovL3d3dy5h
bmdlbGZpcmUuY29tL2NhMi90ZWNoNjhrL3N1bjMuaHRtbD4uCisKK2NvbmZpZyBTVU4zWF9FU1AK
Kwlib29sICJTdW4zeCBFU1AgU0NTSSIKKwlkZXBlbmRzIG9uIFNVTjNYICYmIFNDU0k9eQorCXNl
bGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoZSBFU1Agd2FzIGFuIG9uLWJvYXJkIFND
U0kgY29udHJvbGxlciB1c2VkIG9uIFN1biAzLzgwCisJICBtYWNoaW5lcy4gIFNheSBZIGhlcmUg
dG8gY29tcGlsZSBpbiBzdXBwb3J0IGZvciBpdC4KKworY29uZmlnIFNDU0lfU1VORVNQCisJdHJp
c3RhdGUgIlNwYXJjIEVTUCBTY3NpIERyaXZlciIKKwlkZXBlbmRzIG9uIFNCVVMgJiYgU0NTSQor
CXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoaXMgaXMgdGhlIGRyaXZlciBmb3Ig
dGhlIFN1biBFU1AgU0NTSSBob3N0IGFkYXB0ZXIuIFRoZSBFU1AKKwkgIGNoaXBzZXQgaXMgcHJl
c2VudCBpbiBtb3N0IFNQQVJDIFNCVVMtYmFzZWQgY29tcHV0ZXJzIGFuZAorCSAgc3VwcG9ydHMg
dGhlIEVtdWxleCBmYW1pbHkgb2YgRVNQIFNDU0kgY2hpcHMgKGVzcDEwMCwgZXNwMTAwQSwKKwkg
IGVzcDIzNiwgZmFzMTAxLCBmYXMyMzYpIGFzIHdlbGwgYXMgdGhlIFFsb2dpYyBmYXMzNjYgU0NT
SSBjaGlwLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2Ug
TSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBzdW5fZXNwLgorCitjb25maWcg
WkZDUAorCXRyaXN0YXRlICJGQ1AgaG9zdCBidXMgYWRhcHRlciBkcml2ZXIgZm9yIElCTSBlU2Vy
dmVyIHpTZXJpZXMiCisJZGVwZW5kcyBvbiBTMzkwICYmIFFESU8gJiYgU0NTSQorCXNlbGVjdCBT
Q1NJX0ZDX0FUVFJTCisJaGVscAorICAgICAgICAgIElmIHlvdSB3YW50IHRvIGFjY2VzcyBTQ1NJ
IGRldmljZXMgYXR0YWNoZWQgdG8geW91ciBJQk0gZVNlcnZlcgorICAgICAgICAgIHpTZXJpZXMg
YnkgbWVhbnMgb2YgRmlicmUgQ2hhbm5lbCBpbnRlcmZhY2VzIHNheSBZLgorICAgICAgICAgIEZv
ciBkZXRhaWxzIHBsZWFzZSByZWZlciB0byB0aGUgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBieSBJ
Qk0gYXQKKyAgICAgICAgICA8aHR0cDovL29zcy5zb2Z0d2FyZS5pYm0uY29tL2RldmVsb3Blcndv
cmtzL29wZW5zb3VyY2UvbGludXgzOTA+CisKKyAgICAgICAgICBUaGlzIGRyaXZlciBpcyBhbHNv
IGF2YWlsYWJsZSBhcyBhIG1vZHVsZS4gVGhpcyBtb2R1bGUgd2lsbCBiZQorICAgICAgICAgIGNh
bGxlZCB6ZmNwLiBJZiB5b3Ugd2FudCB0byBjb21waWxlIGl0IGFzIGEgbW9kdWxlLCBzYXkgTSBo
ZXJlCisgICAgICAgICAgYW5kIHJlYWQgPGZpbGU6RG9jdW1lbnRhdGlvbi9rYnVpbGQvbW9kdWxl
cy50eHQ+LgorCitjb25maWcgU0NTSV9QTUNSQUlECisJdHJpc3RhdGUgIlBNQyBTSUVSUkEgTGlu
dXggTWF4UkFJRCBhZGFwdGVyIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSSAmJiBO
RVQKKwktLS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyB0aGUgUE1DIFNJRVJSQSBN
YXhSQUlEIGFkYXB0ZXJzLgorCitjb25maWcgU0NTSV9QTTgwMDEKKwl0cmlzdGF0ZSAiUE1DLVNp
ZXJyYSBTUEMgODAwMSBTQVMvU0FUQSBCYXNlZCBIb3N0IEFkYXB0ZXIgZHJpdmVyIgorCWRlcGVu
ZHMgb24gUENJICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TQVNfTElCU0FTCisJaGVscAorCSAgVGhp
cyBkcml2ZXIgc3VwcG9ydHMgUE1DLVNpZXJyYSBQQ0lFIFNBUy9TQVRBIDh4NkcgU1BDIDgwMDEg
Y2hpcAorCSAgYmFzZWQgaG9zdCBhZGFwdGVycy4KKworY29uZmlnIFNDU0lfU1JQCisJdHJpc3Rh
dGUgIlNDU0kgUkRNQSBQcm90b2NvbCBoZWxwZXIgbGlicmFyeSIKKwlkZXBlbmRzIG9uIFNDU0kg
JiYgUENJCisJc2VsZWN0IFNDU0lfVEdUCisJaGVscAorCSAgSWYgeW91IHdpc2ggdG8gdXNlIFNS
UCB0YXJnZXQgZHJpdmVycywgc2F5IFkuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMg
YSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGxp
YnNycC4KKworY29uZmlnIFNDU0lfQkZBX0ZDCisJdHJpc3RhdGUgIkJyb2NhZGUgQkZBIEZpYnJl
IENoYW5uZWwgU3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJCisJc2VsZWN0IFNDU0lf
RkNfQVRUUlMKKwloZWxwCisJICBUaGlzIGJmYSBkcml2ZXIgc3VwcG9ydHMgYWxsIEJyb2NhZGUg
UENJZSBGQy9GQ09FIGhvc3QgYWRhcHRlcnMuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIg
YXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmUuIFRoZSBtb2R1bGUgd2lsbAorCSAgYmUgY2FsbGVk
IGJmYS4KKworZW5kaWYgIyBTQ1NJX0xPV0xFVkVMCisKK3NvdXJjZSAiZHJpdmVycy9zY3NpL3Bj
bWNpYS9LY29uZmlnIgorCitzb3VyY2UgImRyaXZlcnMvc2NzaS9kZXZpY2VfaGFuZGxlci9LY29u
ZmlnIgorCitzb3VyY2UgImRyaXZlcnMvc2NzaS9vc2QvS2NvbmZpZyIKKworZW5kbWVudQpkaWZm
IC1ydXBOIHhlbi9kcml2ZXJzL3Njc2kvTWFrZWZpbGUgeGVuYy9kcml2ZXJzL3Njc2kvTWFrZWZp
bGUKLS0tIHhlbi9kcml2ZXJzL3Njc2kvTWFrZWZpbGUJMjAxMi0wMi0yNCAxNToxMjozOS43MjU2
NDQ5NjYgLTA3MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL01ha2VmaWxlCTIwMTItMDItMjQgMTU6
MTk6MzUuMzE1NjQ0OTMzIC0wNzAwCkBAIC0xNDEsNiArMTQxLDggQEAgb2JqLSQoQ09ORklHX1ND
U0lfQ1hHQjRfSVNDU0kpCSs9IGxpYmlzYwogb2JqLSQoQ09ORklHX1NDU0lfQk5YMl9JU0NTSSkJ
Kz0gbGliaXNjc2kubyBibngyaS8KIG9iai0kKENPTkZJR19CRTJJU0NTSSkJCSs9IGxpYmlzY3Np
Lm8gYmUyaXNjc2kvCiBvYmotJChDT05GSUdfU0NTSV9QTUNSQUlEKQkrPSBwbWNyYWlkLm8KK29i
ai0kKENPTkZJR19YRU5fU0NTSV9GUk9OVEVORCkJKz0geGVuLXNjc2lmcm9udC8KK29iai0kKENP
TkZJR19YRU5fU0NTSV9CQUNLRU5EKQkrPSB4ZW4tc2NzaWJhY2svCiBvYmotJChDT05GSUdfVk1X
QVJFX1BWU0NTSSkJKz0gdm13X3B2c2NzaS5vCiAKIG9iai0kKENPTkZJR19BUk0pCQkrPSBhcm0v
CmRpZmYgLXJ1cE4geGVuL2RyaXZlcnMvc2NzaS9NYWtlZmlsZS5vcmlnIHhlbmMvZHJpdmVycy9z
Y3NpL01ha2VmaWxlLm9yaWcKLS0tIHhlbi9kcml2ZXJzL3Njc2kvTWFrZWZpbGUub3JpZwkxOTY5
LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVuYy9kcml2ZXJzL3Njc2kvTWFr
ZWZpbGUub3JpZwkyMDEyLTAyLTI0IDE1OjEyOjM5LjcyNTY0NDk2NiAtMDcwMApAQCAtMCwwICsx
LDIwMCBAQAorIworIyBNYWtlZmlsZSBmb3IgbGludXgvZHJpdmVycy9zY3NpCisjCisjIDMwIE1h
eSAyMDAwLCBDaHJpc3RvcGggSGVsbHdpZyA8aGNoQGluZnJhZGVhZC5vcmc+CisjIFJld3JpdHRl
biB0byB1c2UgbGlzdHMgaW5zdGVhZCBvZiBpZi1zdGF0ZW1lbnRzLgorIworIyAyMCBTZXAgMjAw
MCwgVG9yYmVuIE1hdGhpYXNlbiA8dG1tQGltYWdlLmRrPgorIyBDaGFuZ2VkIGxpbmsgb3JkZXIg
dG8gcmVmbGVjdCBuZXcgc2NzaSBpbml0aWFsaXphdGlvbi4KKyMKKyMgKiEqISohKiEqISohKiEq
ISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqIQorIyBUaGUg
bGluayBvcmRlciBtdXN0IGJlLCBTQ1NJIENvcmUsIFNDU0kgSEJBIGRyaXZlcnMsIGFuZAorIyBs
YXN0bHkgU0NTSSBwZXJpcGhlcmFsIGRyaXZlcnMgKGRpc2svdGFwZS9jZHJvbS9ldGMuKSB0bwor
IyBzYXRpc2Z5IGNlcnRhaW4gaW5pdGlhbGl6YXRpb24gYXNzdW1wdGlvbnMgaW4gdGhlIFNDU0kg
bGF5ZXIuCisjICohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEq
ISohKiEqISohKiEqISohKiEKKworCitDRkxBR1NfYWhhMTUyeC5vID0gICAtREFIQTE1MlhfU1RB
VCAtREFVVE9DT05GCitDRkxBR1NfZ2R0aC5vICAgID0gIyAtRERFQlVHX0dEVEg9MiAtRF9fU0VS
SUFMX18gLURfX0NPTTJfXyAtREdEVEhfU1RBVElTVElDUworCitvYmotJChDT05GSUdfUENNQ0lB
KQkJKz0gcGNtY2lhLworCitvYmotJChDT05GSUdfU0NTSSkJCSs9IHNjc2lfbW9kLm8KK29iai0k
KENPTkZJR19TQ1NJX1RHVCkJCSs9IHNjc2lfdGd0Lm8KKworb2JqLSQoQ09ORklHX1JBSURfQVRU
UlMpCSs9IHJhaWRfY2xhc3MubworCisjIC0tLSBOT1RFIE9SREVSSU5HIEhFUkUgLS0tCisjIEZv
ciBrZXJuZWwgbm9uLW1vZHVsYXIgbGluaywgdHJhbnNwb3J0IGF0dHJpYnV0ZXMgbmVlZCB0bwor
IyBiZSBpbml0aWFsaXNlZCBiZWZvcmUgZHJpdmVycworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQorb2JqLSQoQ09ORklHX1NDU0lfU1BJX0FUVFJTKQkrPSBzY3NpX3RyYW5zcG9ydF9zcGku
bworb2JqLSQoQ09ORklHX1NDU0lfRkNfQVRUUlMpIAkrPSBzY3NpX3RyYW5zcG9ydF9mYy5vCitv
YmotJChDT05GSUdfU0NTSV9JU0NTSV9BVFRSUykJKz0gc2NzaV90cmFuc3BvcnRfaXNjc2kubwor
b2JqLSQoQ09ORklHX1NDU0lfU0FTX0FUVFJTKQkrPSBzY3NpX3RyYW5zcG9ydF9zYXMubworb2Jq
LSQoQ09ORklHX1NDU0lfU0FTX0xJQlNBUykJKz0gbGlic2FzLworb2JqLSQoQ09ORklHX1NDU0lf
U1JQX0FUVFJTKQkrPSBzY3NpX3RyYW5zcG9ydF9zcnAubworb2JqLSQoQ09ORklHX1NDU0lfREgp
CQkrPSBkZXZpY2VfaGFuZGxlci8KKworb2JqLSQoQ09ORklHX0xJQkZDKQkJKz0gbGliZmMvCitv
YmotJChDT05GSUdfTElCRkNPRSkJCSs9IGZjb2UvCitvYmotJChDT05GSUdfRkNPRSkJCSs9IGZj
b2UvCitvYmotJChDT05GSUdfRkNPRV9GTklDKQkJKz0gZm5pYy8KK29iai0kKENPTkZJR19TQ1NJ
X0JOWDJYX0ZDT0UpCSs9IGxpYmZjLyBmY29lLyBibngyZmMvCitvYmotJChDT05GSUdfSVNDU0lf
VENQKSAJKz0gbGliaXNjc2kubwlsaWJpc2NzaV90Y3AubyBpc2NzaV90Y3Aubworb2JqLSQoQ09O
RklHX0lORklOSUJBTkRfSVNFUikgCSs9IGxpYmlzY3NpLm8KK29iai0kKENPTkZJR19JU0NTSV9C
T09UX1NZU0ZTKQkrPSBpc2NzaV9ib290X3N5c2ZzLm8KK29iai0kKENPTkZJR19TQ1NJX0E0MDAw
VCkJKz0gNTNjNzAwLm8JYTQwMDB0Lm8KK29iai0kKENPTkZJR19TQ1NJX1pPUlJPN1hYKQkrPSA1
M2M3MDAubwl6b3Jybzd4eC5vCitvYmotJChDT05GSUdfQTMwMDBfU0NTSSkJKz0gYTMwMDAubwl3
ZDMzYzkzLm8KK29iai0kKENPTkZJR19BMjA5MV9TQ1NJKQkrPSBhMjA5MS5vCXdkMzNjOTMubwor
b2JqLSQoQ09ORklHX0dWUDExX1NDU0kpCSs9IGd2cDExLm8Jd2QzM2M5My5vCitvYmotJChDT05G
SUdfTVZNRTE0N19TQ1NJKQkrPSBtdm1lMTQ3Lm8Jd2QzM2M5My5vCitvYmotJChDT05GSUdfU0dJ
V0Q5M19TQ1NJKQkrPSBzZ2l3ZDkzLm8Jd2QzM2M5My5vCitvYmotJChDT05GSUdfQVRBUklfU0NT
SSkJKz0gYXRhcmlfc2NzaS5vCitvYmotJChDT05GSUdfTUFDX1NDU0kpCQkrPSBtYWNfc2NzaS5v
CitvYmotJChDT05GSUdfU0NTSV9NQUNfRVNQKQkrPSBlc3Bfc2NzaS5vCW1hY19lc3Aubworb2Jq
LSQoQ09ORklHX1NVTjNfU0NTSSkJCSs9IHN1bjNfc2NzaS5vICBzdW4zX3Njc2lfdm1lLm8KK29i
ai0kKENPTkZJR19NVk1FMTZ4X1NDU0kpCSs9IDUzYzcwMC5vCW12bWUxNnhfc2NzaS5vCitvYmot
JChDT05GSUdfQlZNRTYwMDBfU0NTSSkJKz0gNTNjNzAwLm8JYnZtZTYwMDBfc2NzaS5vCitvYmot
JChDT05GSUdfU0NTSV9TSU03MTApCSs9IDUzYzcwMC5vCXNpbTcxMC5vCitvYmotJChDT05GSUdf
U0NTSV9BRFZBTlNZUykJKz0gYWR2YW5zeXMubworb2JqLSQoQ09ORklHX1NDU0lfQlVTTE9HSUMp
CSs9IEJ1c0xvZ2ljLm8KK29iai0kKENPTkZJR19TQ1NJX0RQVF9JMk8pCSs9IGRwdF9pMm8ubwor
b2JqLSQoQ09ORklHX1NDU0lfVTE0XzM0RikJKz0gdTE0LTM0Zi5vCitvYmotJChDT05GSUdfU0NT
SV9BUkNNU1IpCSs9IGFyY21zci8KK29iai0kKENPTkZJR19TQ1NJX1VMVFJBU1RPUikJKz0gdWx0
cmFzdG9yLm8KK29iai0kKENPTkZJR19TQ1NJX0FIQTE1MlgpCSs9IGFoYTE1Mngubworb2JqLSQo
Q09ORklHX1NDU0lfQUhBMTU0MikJKz0gYWhhMTU0Mi5vCitvYmotJChDT05GSUdfU0NTSV9BSEEx
NzQwKQkrPSBhaGExNzQwLm8KK29iai0kKENPTkZJR19TQ1NJX0FJQzdYWFgpCSs9IGFpYzd4eHgv
CitvYmotJChDT05GSUdfU0NTSV9BSUM3OVhYKQkrPSBhaWM3eHh4Lworb2JqLSQoQ09ORklHX1ND
U0lfQUFDUkFJRCkJKz0gYWFjcmFpZC8KK29iai0kKENPTkZJR19TQ1NJX0FJQzdYWFhfT0xEKQkr
PSBhaWM3eHh4X29sZC5vCitvYmotJChDT05GSUdfU0NTSV9BSUM5NFhYKQkrPSBhaWM5NHh4Lwor
b2JqLSQoQ09ORklHX1NDU0lfUE04MDAxKQkrPSBwbTgwMDEvCitvYmotJChDT05GSUdfU0NTSV9J
U0NJKQkJKz0gaXNjaS8KK29iai0kKENPTkZJR19TQ1NJX0lQUykJCSs9IGlwcy5vCitvYmotJChD
T05GSUdfU0NTSV9GRF9NQ1MpCSs9IGZkX21jcy5vCitvYmotJChDT05GSUdfU0NTSV9GVVRVUkVf
RE9NQUlOKSs9IGZkb21haW4ubworb2JqLSQoQ09ORklHX1NDU0lfSU4yMDAwKQkrPSBpbjIwMDAu
bworb2JqLSQoQ09ORklHX1NDU0lfR0VORVJJQ19OQ1I1MzgwKSArPSBnX05DUjUzODAubworb2Jq
LSQoQ09ORklHX1NDU0lfR0VORVJJQ19OQ1I1MzgwX01NSU8pICs9IGdfTkNSNTM4MF9tbWlvLm8K
K29iai0kKENPTkZJR19TQ1NJX05DUjUzQzQwNkEpCSs9IE5DUjUzYzQwNmEubworb2JqLSQoQ09O
RklHX1NDU0lfTkNSX0Q3MDApCSs9IDUzYzcwMC5vIE5DUl9ENzAwLm8KK29iai0kKENPTkZJR19T
Q1NJX05DUl9RNzIwKQkrPSBOQ1JfUTcyMF9tb2Qubworb2JqLSQoQ09ORklHX1NDU0lfU1lNNTND
NDE2KQkrPSBzeW01M2M0MTYubworb2JqLSQoQ09ORklHX1NDU0lfUUxPR0lDX0ZBUykJKz0gcWxv
Z2ljZmFzNDA4Lm8JcWxvZ2ljZmFzLm8KK29iai0kKENPTkZJR19QQ01DSUFfUUxPR0lDKQkrPSBx
bG9naWNmYXM0MDgubworb2JqLSQoQ09ORklHX1NDU0lfUUxPR0lDXzEyODApCSs9IHFsYTEyODAu
byAKK29iai0kKENPTkZJR19TQ1NJX1FMQV9GQykJKz0gcWxhMnh4eC8KK29iai0kKENPTkZJR19T
Q1NJX1FMQV9JU0NTSSkJKz0gbGliaXNjc2kubyBxbGE0eHh4Lworb2JqLSQoQ09ORklHX1NDU0lf
TFBGQykJCSs9IGxwZmMvCitvYmotJChDT05GSUdfU0NTSV9CRkFfRkMpCSs9IGJmYS8KK29iai0k
KENPTkZJR19TQ1NJX1BBUzE2KQkrPSBwYXMxNi5vCitvYmotJChDT05GSUdfU0NTSV9UMTI4KQkJ
Kz0gdDEyOC5vCitvYmotJChDT05GSUdfU0NTSV9ETVgzMTkxRCkJKz0gZG14MzE5MWQubworb2Jq
LSQoQ09ORklHX1NDU0lfSFBTQSkJCSs9IGhwc2Eubworb2JqLSQoQ09ORklHX1NDU0lfRFRDMzI4
MCkJKz0gZHRjLm8KK29iai0kKENPTkZJR19TQ1NJX1NZTTUzQzhYWF8yKQkrPSBzeW01M2M4eHhf
Mi8KK29iai0kKENPTkZJR19TQ1NJX1pBTE9OKQkrPSB6YWxvbjd4eC5vCitvYmotJChDT05GSUdf
U0NTSV9FQVRBX1BJTykJKz0gZWF0YV9waW8ubworb2JqLSQoQ09ORklHX1NDU0lfNzAwMEZBU1NU
KQkrPSB3ZDcwMDAubworb2JqLSQoQ09ORklHX1NDU0lfSUJNTUNBKQkrPSBpYm1tY2Eubworb2Jq
LSQoQ09ORklHX1NDU0lfRUFUQSkJCSs9IGVhdGEubworb2JqLSQoQ09ORklHX1NDU0lfREMzOTV4
KQkrPSBkYzM5NXgubworb2JqLSQoQ09ORklHX1NDU0lfREMzOTBUKQkrPSB0bXNjc2ltLm8KK29i
ai0kKENPTkZJR19NRUdBUkFJRF9MRUdBQ1kpCSs9IG1lZ2FyYWlkLm8KK29iai0kKENPTkZJR19N
RUdBUkFJRF9ORVdHRU4pCSs9IG1lZ2FyYWlkLworb2JqLSQoQ09ORklHX01FR0FSQUlEX1NBUykJ
Kz0gbWVnYXJhaWQvCitvYmotJChDT05GSUdfU0NTSV9NUFQyU0FTKQkrPSBtcHQyc2FzLworb2Jq
LSQoQ09ORklHX1NDU0lfQUNBUkQpCSs9IGF0cDg3MHUubworb2JqLSQoQ09ORklHX1NDU0lfU1VO
RVNQKQkrPSBlc3Bfc2NzaS5vCXN1bl9lc3Aubworb2JqLSQoQ09ORklHX1NDU0lfR0RUSCkJCSs9
IGdkdGgubworb2JqLSQoQ09ORklHX1NDU0lfSU5JVElPKQkrPSBpbml0aW8ubworb2JqLSQoQ09O
RklHX1NDU0lfSU5JQTEwMCkJKz0gYTEwMHUydy5vCitvYmotJChDT05GSUdfU0NTSV9RTE9HSUNQ
VEkpCSs9IHFsb2dpY3B0aS5vCitvYmotJChDT05GSUdfU0NTSV9NRVNIKQkJKz0gbWVzaC5vCitv
YmotJChDT05GSUdfU0NTSV9NQUM1M0M5NCkJKz0gbWFjNTNjOTQubworb2JqLSQoQ09ORklHX0JM
S19ERVZfM1dfWFhYWF9SQUlEKSArPSAzdy14eHh4Lm8KK29iai0kKENPTkZJR19TQ1NJXzNXXzlY
WFgpCSs9IDN3LTl4eHgubworb2JqLSQoQ09ORklHX1NDU0lfM1dfU0FTKQkrPSAzdy1zYXMubwor
b2JqLSQoQ09ORklHX1NDU0lfUFBBKQkJKz0gcHBhLm8KK29iai0kKENPTkZJR19TQ1NJX0lNTSkJ
CSs9IGltbS5vCitvYmotJChDT05GSUdfSkFaWl9FU1ApCQkrPSBlc3Bfc2NzaS5vCWphenpfZXNw
Lm8KK29iai0kKENPTkZJR19TVU4zWF9FU1ApCQkrPSBlc3Bfc2NzaS5vCXN1bjN4X2VzcC5vCitv
YmotJChDT05GSUdfU0NTSV9MQVNJNzAwKQkrPSA1M2M3MDAubyBsYXNpNzAwLm8KK29iai0kKENP
TkZJR19TQ1NJX1NOSV81M0M3MTApCSs9IDUzYzcwMC5vIHNuaV81M2M3MTAubworb2JqLSQoQ09O
RklHX1NDU0lfTlNQMzIpCSs9IG5zcDMyLm8KK29iai0kKENPTkZJR19TQ1NJX0lQUikJCSs9IGlw
ci5vCitvYmotJChDT05GSUdfU0NTSV9TUlApCQkrPSBsaWJzcnAubworb2JqLSQoQ09ORklHX1ND
U0lfSUJNVlNDU0kpCSs9IGlibXZzY3NpLworb2JqLSQoQ09ORklHX1NDU0lfSUJNVlNDU0lTKQkr
PSBpYm12c2NzaS8KK29iai0kKENPTkZJR19TQ1NJX0lCTVZGQykJKz0gaWJtdnNjc2kvCitvYmot
JChDT05GSUdfU0NTSV9IUFRJT1ApCSs9IGhwdGlvcC5vCitvYmotJChDT05GSUdfU0NTSV9TVEVY
KQkJKz0gc3RleC5vCitvYmotJChDT05GSUdfU0NTSV9NVlNBUykJKz0gbXZzYXMvCitvYmotJChD
T05GSUdfU0NTSV9NVlVNSSkJKz0gbXZ1bWkubworb2JqLSQoQ09ORklHX1BTM19ST00pCQkrPSBw
czNyb20ubworb2JqLSQoQ09ORklHX1NDU0lfQ1hHQjNfSVNDU0kpCSs9IGxpYmlzY3NpLm8gbGli
aXNjc2lfdGNwLm8gY3hnYmkvCitvYmotJChDT05GSUdfU0NTSV9DWEdCNF9JU0NTSSkJKz0gbGli
aXNjc2kubyBsaWJpc2NzaV90Y3AubyBjeGdiaS8KK29iai0kKENPTkZJR19TQ1NJX0JOWDJfSVND
U0kpCSs9IGxpYmlzY3NpLm8gYm54MmkvCitvYmotJChDT05GSUdfQkUySVNDU0kpCQkrPSBsaWJp
c2NzaS5vIGJlMmlzY3NpLworb2JqLSQoQ09ORklHX1NDU0lfUE1DUkFJRCkJKz0gcG1jcmFpZC5v
CitvYmotJChDT05GSUdfVk1XQVJFX1BWU0NTSSkJKz0gdm13X3B2c2NzaS5vCisKK29iai0kKENP
TkZJR19BUk0pCQkrPSBhcm0vCisKK29iai0kKENPTkZJR19DSFJfREVWX1NUKQkrPSBzdC5vCitv
YmotJChDT05GSUdfQ0hSX0RFVl9PU1NUKQkrPSBvc3N0Lm8KK29iai0kKENPTkZJR19CTEtfREVW
X1NEKQkrPSBzZF9tb2Qubworb2JqLSQoQ09ORklHX0JMS19ERVZfU1IpCSs9IHNyX21vZC5vCitv
YmotJChDT05GSUdfQ0hSX0RFVl9TRykJKz0gc2cubworb2JqLSQoQ09ORklHX0NIUl9ERVZfU0NI
KQkrPSBjaC5vCitvYmotJChDT05GSUdfU0NTSV9FTkNMT1NVUkUpCSs9IHNlcy5vCisKK29iai0k
KENPTkZJR19TQ1NJX09TRF9JTklUSUFUT1IpICs9IG9zZC8KKworIyBUaGlzIGdvZXMgbGFzdCwg
c28gdGhhdCAicmVhbCIgc2NzaSBkZXZpY2VzIHByb2JlIGVhcmxpZXIKK29iai0kKENPTkZJR19T
Q1NJX0RFQlVHKQkrPSBzY3NpX2RlYnVnLm8KKworb2JqLSQoQ09ORklHX1NDU0lfV0FJVF9TQ0FO
KQkrPSBzY3NpX3dhaXRfc2Nhbi5vCisKK3Njc2lfbW9kLXkJCQkrPSBzY3NpLm8gaG9zdHMubyBz
Y3NpX2lvY3RsLm8gY29uc3RhbnRzLm8gXAorCQkJCSAgIHNjc2ljYW0ubyBzY3NpX2Vycm9yLm8g
c2NzaV9saWIubworc2NzaV9tb2QtJChDT05GSUdfU0NTSV9ETUEpCSs9IHNjc2lfbGliX2RtYS5v
CitzY3NpX21vZC15CQkJKz0gc2NzaV9zY2FuLm8gc2NzaV9zeXNmcy5vIHNjc2lfZGV2aW5mby5v
CitzY3NpX21vZC0kKENPTkZJR19TQ1NJX05FVExJTkspCSs9IHNjc2lfbmV0bGluay5vCitzY3Np
X21vZC0kKENPTkZJR19TWVNDVEwpCSs9IHNjc2lfc3lzY3RsLm8KK3Njc2lfbW9kLSQoQ09ORklH
X1NDU0lfUFJPQ19GUykJKz0gc2NzaV9wcm9jLm8KK3Njc2lfbW9kLXkJCQkrPSBzY3NpX3RyYWNl
Lm8KK3Njc2lfbW9kLSQoQ09ORklHX1BNKQkJKz0gc2NzaV9wbS5vCisKK3Njc2lfdGd0LXkJCQkr
PSBzY3NpX3RndF9saWIubyBzY3NpX3RndF9pZi5vCisKK3NkX21vZC1vYmpzCTo9IHNkLm8KK3Nk
X21vZC0kKENPTkZJR19CTEtfREVWX0lOVEVHUklUWSkgKz0gc2RfZGlmLm8KKworc3JfbW9kLW9i
anMJOj0gc3IubyBzcl9pb2N0bC5vIHNyX3ZlbmRvci5vCituY3I1M2M4eHgtZmxhZ3MtJChDT05G
SUdfU0NTSV9aQUxPTikgXAorCQk6PSAtRENPTkZJR19OQ1I1M0M4WFhfUFJFRkVUQ0ggLURTQ1NJ
X05DUl9CSUdfRU5ESUFOIFwKKwkJCS1EQ09ORklHX1NDU0lfTkNSNTNDOFhYX05PX1dPUkRfVFJB
TlNGRVJTCitDRkxBR1NfbmNyNTNjOHh4Lm8JOj0gJChuY3I1M2M4eHgtZmxhZ3MteSkgJChuY3I1
M2M4eHgtZmxhZ3MtbSkKK3phbG9uN3h4LW9ianMJOj0gemFsb24ubyBuY3I1M2M4eHgubworTkNS
X1E3MjBfbW9kLW9ianMJOj0gTkNSX1E3MjAubyBuY3I1M2M4eHgubworb2t0YWdvbl9lc3BfbW9k
LW9ianMJOj0gb2t0YWdvbl9lc3AubyBva3RhZ29uX2lvLm8KKworIyBGaWxlcyBnZW5lcmF0ZWQg
dGhhdCBzaGFsbCBiZSByZW1vdmVkIHVwb24gbWFrZSBjbGVhbgorY2xlYW4tZmlsZXMgOj0JNTNj
NzAwX2QuaCA1M2M3MDBfdS5oCisKKyQob2JqKS81M2M3MDAubyAkKE1PRFZFUkRJUikvJChvYmop
LzUzYzcwMC52ZXI6ICQob2JqKS81M2M3MDBfZC5oCisKKyMgSWYgeW91IHdhbnQgdG8gcGxheSB3
aXRoIHRoZSBmaXJtd2FyZSwgdW5jb21tZW50CisjIEdFTkVSQVRFX0ZJUk1XQVJFIDo9IDEKKwor
aWZkZWYgR0VORVJBVEVfRklSTVdBUkUKKworJChvYmopLzUzYzcwMF9kLmg6ICQoc3JjKS81M2M3
MDAuc2NyICQoc3JjKS9zY3JpcHRfYXNtLnBsCisJJChQRVJMKSAtcyAkKHNyYykvc2NyaXB0X2Fz
bS5wbCAtbmNyN3gwX2ZhbWlseSAkQCAkKEA6X2QuaD1fdS5oKSA8ICQ8CisKK2VuZGlmCmRpZmYg
LXJ1cE4geGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWJhY2svTWFrZWZpbGUgeGVuYy9kcml2ZXJz
L3Njc2kveGVuLXNjc2liYWNrL01ha2VmaWxlCi0tLSB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3Np
YmFjay9NYWtlZmlsZQkxOTY5LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVu
Yy9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL01ha2VmaWxlCTIwMTItMDItMjQgMTQ6NTY6MTMu
NTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNCBAQAorb2JqLSQoQ09ORklHX1hFTl9TQ1NJX0JB
Q0tFTkQpIDo9IHhlbi1zY3NpYmFjay5vCisKK3hlbi1zY3NpYmFjay15CTo9IGludGVyZmFjZS5v
IHNjc2liYWNrLm8geGVuYnVzLm8gdHJhbnNsYXRlLm8gZW11bGF0ZS5vCisKZGlmZiAtcnVwTiB4
ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFjay9jb21tb24uaCB4ZW5jL2RyaXZlcnMvc2NzaS94
ZW4tc2NzaWJhY2svY29tbW9uLmgKLS0tIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL2Nv
bW1vbi5oCTE5NjktMTItMzEgMTc6MDA6MDAuMDAwMDAwMDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZl
cnMvc2NzaS94ZW4tc2NzaWJhY2svY29tbW9uLmgJMjAxMi0wMi0yNCAxNDo1NjoxMy41Mzg5Nzgz
MDAgLTA3MDAKQEAgLTAsMCArMSwxODcgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZV
SklUU1UgTGltaXRlZAorICoKKyAqIEJhc2VkIG9uIHRoZSBibGtiYWNrIGRyaXZlciBjb2RlLgor
ICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisgKiBzZXBhcmF0ZWx5
IGZyb20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBvdGhlcgorICogc29m
dHdhcmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNlbnNlOgorICoKKyAq
IFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVy
c29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUgKHRoZSAiU29mdHdh
cmUiKSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVzdHJpY3Rpb24sIGlu
Y2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlm
eSwKKyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3Igc2Vs
bCBjb3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdo
b20gdGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0bworICogdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNl
IGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwg
Y29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBU
SEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkg
S0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBU
TyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBB
UlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBU
SEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xB
SU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04g
T0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0Yg
T1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERF
QUxJTkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2lmbmRlZiBfX1NDU0lJRl9fQkFD
S0VORF9fQ09NTU9OX0hfXworI2RlZmluZSBfX1NDU0lJRl9fQkFDS0VORF9fQ09NTU9OX0hfXwor
CisjaW5jbHVkZSA8bGludXgvdmVyc2lvbi5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgor
I2luY2x1ZGUgPGxpbnV4L2ludGVycnVwdC5oPgorI2luY2x1ZGUgPGxpbnV4L3NsYWIuaD4KKyNp
bmNsdWRlIDxsaW51eC92bWFsbG9jLmg+CisjaW5jbHVkZSA8bGludXgvd2FpdC5oPgorI2luY2x1
ZGUgPGxpbnV4L3NjaGVkLmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2luY2x1ZGUg
PGxpbnV4L2Jsa2Rldi5oPgorI2luY2x1ZGUgPGxpbnV4L2xpc3QuaD4KKyNpbmNsdWRlIDxsaW51
eC9rdGhyZWFkLmg+CisjaW5jbHVkZSA8c2NzaS9zY3NpLmg+CisjaW5jbHVkZSA8c2NzaS9zY3Np
X2NtbmQuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfaG9zdC5oPgorI2luY2x1ZGUgPHNjc2kvc2Nz
aV9kZXZpY2UuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfZGJnLmg+CisjaW5jbHVkZSA8c2NzaS9z
Y3NpX2VoLmg+CisjaW5jbHVkZSA8YXNtL2lvLmg+CisjaW5jbHVkZSA8YXNtL3NldHVwLmg+Cisj
aW5jbHVkZSA8YXNtL3BnYWxsb2MuaD4KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4KKyNpbmNsdWRl
IDx4ZW4vZXZ0Y2huLmg+CisjaW5jbHVkZSA8YXNtL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDx4
ZW4veGVuLmg+CisjaW5jbHVkZSA8eGVuL2V2ZW50cy5oPgorI2luY2x1ZGUgPHhlbi9ncmFudF90
YWJsZS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4vcGFnZS5oPgor
I2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UveGVuLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9p
by9yaW5nLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9ncmFudF90YWJsZS5oPgorI2luY2x1
ZGUgPHhlbi9pbnRlcmZhY2UvaW8vdnNjc2lpZi5oPgorCisKKyNkZWZpbmUgRFBSSU5USyhfZiwg
X2EuLi4pCQkJXAorCXByX2RlYnVnKCIoZmlsZT0lcywgbGluZT0lZCkgIiBfZiwJXAorCQkgX19G
SUxFX18gLCBfX0xJTkVfXyAsICMjIF9hICkKKworc3RydWN0IGlkc190dXBsZSB7CisJdW5zaWdu
ZWQgaW50IGhzdDsJCS8qIGhvc3QgICAgKi8KKwl1bnNpZ25lZCBpbnQgY2huOwkJLyogY2hhbm5l
bCAqLworCXVuc2lnbmVkIGludCB0Z3Q7CQkvKiB0YXJnZXQgICovCisJdW5zaWduZWQgaW50IGx1
bjsJCS8qIExVTiAgICAgKi8KK307CisKK3N0cnVjdCB2MnBfZW50cnkgeworCXN0cnVjdCBpZHNf
dHVwbGUgdjsJCS8qIHRyYW5zbGF0ZSBmcm9tICovCisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2
OwkvKiB0cmFuc2xhdGUgdG8gICAqLworCXN0cnVjdCBsaXN0X2hlYWQgbDsKK307CisKK3N0cnVj
dCB2c2NzaWJrX2luZm8geworCXN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXY7CisKKwlkb21pZF90
IGRvbWlkOworCXVuc2lnbmVkIGludCBldnRjaG47CisJdW5zaWduZWQgaW50IGlycTsKKworCWlu
dCBmZWF0dXJlOworCisJc3RydWN0IHZzY3NpaWZfYmFja19yaW5nICByaW5nOworCXZvaWQgICpy
aW5nX2FyZWE7CisKKwlzcGlubG9ja190IHJpbmdfbG9jazsKKwlhdG9taWNfdCBucl91bnJlcGxp
ZWRfcmVxczsKKworCXNwaW5sb2NrX3QgdjJwX2xvY2s7CisJc3RydWN0IGxpc3RfaGVhZCB2MnBf
ZW50cnlfbGlzdHM7CisKKwlzdHJ1Y3QgdGFza19zdHJ1Y3QgKmt0aHJlYWQ7CisJd2FpdF9xdWV1
ZV9oZWFkX3Qgd2FpdGluZ190b19mcmVlOworCXdhaXRfcXVldWVfaGVhZF90IHdxOworCXVuc2ln
bmVkIGludCB3YWl0aW5nX3JlcXM7CisJc3RydWN0IHBhZ2UgKiptbWFwX3BhZ2VzOworCit9Owor
Cit0eXBlZGVmIHN0cnVjdCB7CisJdW5zaWduZWQgY2hhciBhY3Q7CisJc3RydWN0IHZzY3NpYmtf
aW5mbyAqaW5mbzsKKwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXY7CisKKwl1aW50MTZfdCBycWlk
OworCisJdWludDE2X3Qgdl9jaG4sIHZfdGd0OworCisJdWludDhfdCBucl9zZWdtZW50czsKKwl1
aW50OF90IGNtbmRbVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFXTsKKwl1aW50OF90IGNtZF9sZW47
CisKKwl1aW50OF90IHNjX2RhdGFfZGlyZWN0aW9uOworCXVpbnQxNl90IHRpbWVvdXRfcGVyX2Nv
bW1hbmQ7CisKKwl1aW50MzJfdCByZXF1ZXN0X2J1ZmZsZW47CisJc3RydWN0IHNjYXR0ZXJsaXN0
ICpzZ2w7CisJZ3JhbnRfcmVmX3QgZ3JlZltWU0NTSUlGX1NHX1RBQkxFU0laRV07CisKKwlpbnQz
Ml90IHJzbHQ7CisJdWludDMyX3QgcmVzaWQ7CisJdWludDhfdCBzZW5zZV9idWZmZXJbVlNDU0lJ
Rl9TRU5TRV9CVUZGRVJTSVpFXTsKKworCXN0cnVjdCBsaXN0X2hlYWQgZnJlZV9saXN0OworfSBw
ZW5kaW5nX3JlcV90OworCisKKworI2RlZmluZSBzY3NpYmFja19nZXQoX2IpIChhdG9taWNfaW5j
KCYoX2IpLT5ucl91bnJlcGxpZWRfcmVxcykpCisjZGVmaW5lIHNjc2liYWNrX3B1dChfYikJCQkJ
XAorCWRvIHsJCQkJCQlcCisJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCYoX2IpLT5ucl91bnJl
cGxpZWRfcmVxcykpCVwKKwkJCXdha2VfdXAoJihfYiktPndhaXRpbmdfdG9fZnJlZSk7XAorCX0g
d2hpbGUgKDApCisKKyNkZWZpbmUgVlNDU0lJRl9USU1FT1VUCQkoOTAwKkhaKQorCisjZGVmaW5l
IFZTQ1NJX1RZUEVfSE9TVAkJMQorCitpcnFyZXR1cm5fdCBzY3NpYmFja19pbnRyKGludCwgdm9p
ZCAqKTsKK2ludCBzY3NpYmFja19pbml0X3NyaW5nKHN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm8s
CisJCXVuc2lnbmVkIGxvbmcgcmluZ19yZWYsIHVuc2lnbmVkIGludCBldnRjaG4pOworaW50IHNj
c2liYWNrX3NjaGVkdWxlKHZvaWQgKmRhdGEpOworCisKK3N0cnVjdCB2c2NzaWJrX2luZm8gKnZz
Y3NpYmtfaW5mb19hbGxvYyhkb21pZF90IGRvbWlkKTsKK3ZvaWQgc2NzaWJhY2tfZnJlZShzdHJ1
Y3QgdnNjc2lia19pbmZvICppbmZvKTsKK3ZvaWQgc2NzaWJhY2tfZGlzY29ubmVjdChzdHJ1Y3Qg
dnNjc2lia19pbmZvICppbmZvKTsKK2ludCBfX2luaXQgc2NzaWJhY2tfaW50ZXJmYWNlX2luaXQo
dm9pZCk7Cit2b2lkIHNjc2liYWNrX2ludGVyZmFjZV9leGl0KHZvaWQpOworaW50IHNjc2liYWNr
X3hlbmJ1c19pbml0KHZvaWQpOwordm9pZCBzY3NpYmFja194ZW5idXNfdW5yZWdpc3Rlcih2b2lk
KTsKKwordm9pZCBzY3NpYmFja19pbml0X3RyYW5zbGF0aW9uX3RhYmxlKHN0cnVjdCB2c2NzaWJr
X2luZm8gKmluZm8pOworCitpbnQgc2NzaWJhY2tfYWRkX3RyYW5zbGF0aW9uX2VudHJ5KHN0cnVj
dCB2c2NzaWJrX2luZm8gKmluZm8sCisJCQlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXYsIHN0cnVj
dCBpZHNfdHVwbGUgKnYpOworCitpbnQgc2NzaWJhY2tfZGVsX3RyYW5zbGF0aW9uX2VudHJ5KHN0
cnVjdCB2c2NzaWJrX2luZm8gKmluZm8sCisJCQkJc3RydWN0IGlkc190dXBsZSAqdik7CitzdHJ1
Y3Qgc2NzaV9kZXZpY2UgKnNjc2liYWNrX2RvX3RyYW5zbGF0aW9uKHN0cnVjdCB2c2NzaWJrX2lu
Zm8gKmluZm8sCisJCQlzdHJ1Y3QgaWRzX3R1cGxlICp2KTsKK3ZvaWQgc2NzaWJhY2tfcmVsZWFz
ZV90cmFuc2xhdGlvbl9lbnRyeShzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvKTsKKworCit2b2lk
IHNjc2liYWNrX2NtZF9leGVjKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdfcmVxKTsKK3ZvaWQgc2Nz
aWJhY2tfZG9fcmVzcF93aXRoX3NlbnNlKGNoYXIgKnNlbnNlX2J1ZmZlciwgaW50MzJfdCByZXN1
bHQsCisJCQl1aW50MzJfdCByZXNpZCwgcGVuZGluZ19yZXFfdCAqcGVuZGluZ19yZXEpOwordm9p
ZCBzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVuZGluZ19yZXFfdCAqcmVxKTsKKwordm9pZCBz
Y3NpYmFja19yc3BfZW11bGF0aW9uKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdfcmVxKTsKK3ZvaWQg
c2NzaWJhY2tfcmVxX2VtdWxhdGlvbl9vcl9jbWRleGVjKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdf
cmVxKTsKK3ZvaWQgc2NzaWJhY2tfZW11bGF0aW9uX2luaXQodm9pZCk7CisKKworI2VuZGlmIC8q
IF9fU0NTSUlGX19CQUNLRU5EX19DT01NT05fSF9fICovCmRpZmYgLXJ1cE4geGVuL2RyaXZlcnMv
c2NzaS94ZW4tc2NzaWJhY2svZW11bGF0ZS5jIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFj
ay9lbXVsYXRlLmMKLS0tIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL2VtdWxhdGUuYwkx
OTY5LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVuYy9kcml2ZXJzL3Njc2kv
eGVuLXNjc2liYWNrL2VtdWxhdGUuYwkyMDEyLTAyLTI0IDE0OjU2OjEzLjUzODk3ODMwMCAtMDcw
MApAQCAtMCwwICsxLDQ3OCBAQAorLyoKKyAqIFhlbiBTQ1NJIGJhY2tlbmQgZHJpdmVyCisgKgor
ICogQ29weXJpZ2h0IChjKSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQKKyAqCisgKiBUaGlzIHByb2dy
YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBt
b2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSB2ZXJzaW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uOyBvciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBr
ZXJuZWwgb3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBz
dWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhl
cmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBj
b3B5CisgKiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4g
dGhlIFNvZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBs
aW1pdGF0aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVi
bGlzaCwgZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBT
b2Z0d2FyZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBp
cyBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0
aW9uczoKKyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNz
aW9uIG5vdGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFu
dGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBS
T1ZJREVEICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IK
KyAqIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMg
T0YgTUVSQ0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Ug
QU5EIE5PTklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9S
IENPUFlSSUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9U
SEVSCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JU
IE9SIE9USEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04g
V0lUSCBUSEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhF
IFNPRlRXQVJFLgorICovCisKKy8qCisqIFBhdGNoZWQgdG8gc3VwcG9ydCA+MlRCIGRyaXZlcyAr
IGFsbG93IHRhcGUgJiBhdXRvbG9hZGVyIG9wZXJhdGlvbnMKKyogMjAxMCwgU2FtdWVsIEt2YXNu
aWNhLCBJTVMgTmFub2ZhYnJpY2F0aW9uIEFHCisqLworCisjaW5jbHVkZSA8c2NzaS9zY3NpLmg+
CisjaW5jbHVkZSA8c2NzaS9zY3NpX2NtbmQuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfZGV2aWNl
Lmg+CisjaW5jbHVkZSAiY29tbW9uLmgiCisKKy8qIEZvbGxvd2luZyBTQ1NJIGNvbW1hbmRzIGFy
ZSBub3QgZGVmaW5lZCBpbiBzY3NpL3Njc2kuaCAqLworI2RlZmluZSBFWFRFTkRFRF9DT1BZCQkw
eDgzCS8qIEVYVEVOREVEIENPUFkgY29tbWFuZCAgICAgICAgKi8KKyNkZWZpbmUgUkVQT1JUX0FM
SUFTRVMJCTB4YTMJLyogUkVQT1JUIEFMSUFTRVMgY29tbWFuZCAgICAgICAqLworI2RlZmluZSBD
SEFOR0VfQUxJQVNFUwkJMHhhNAkvKiBDSEFOR0UgQUxJQVNFUyBjb21tYW5kICAgICAgICovCisj
ZGVmaW5lIFNFVF9QUklPUklUWQkJMHhhNAkvKiBTRVQgUFJJT1JJVFkgY29tbWFuZCAgICAgICAg
ICovCisKKworLyoKKyAgVGhlIGJpdG1hcCBpbiBvcmRlciB0byBjb250cm9sIGVtdWxhdGlvbi4K
KyAgKEJpdCAzIHRvIDcgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLikKKyovCisjZGVmaW5l
IFZTQ1NJSUZfTkVFRF9DTURfRVhFQwkJMHgwMQkvKiBJZiB0aGlzIGJpdCBpcyBzZXQsIGNtZCBl
eGVjCSovCisJCQkJCQkvKiBpcyByZXF1aXJlZC4JCQkqLworI2RlZmluZSBWU0NTSUlGX05FRURf
RU1VTEFURV9SRVFCVUYJMHgwMgkvKiBJZiB0aGlzIGJpdCBpcyBzZXQsIG5lZWQJKi8KKwkJCQkJ
CS8qIGVtdWxhdGlvbiByZXFlc3QgYnVmZiBiZWZvcmUJKi8KKwkJCQkJCS8qIGNtZCBleGVjLgkJ
CSovCisjZGVmaW5lIFZTQ1NJSUZfTkVFRF9FTVVMQVRFX1JTUEJVRgkweDA0CS8qIElmIHRoaXMg
Yml0IGlzIHNldCwgbmVlZAkqLworCQkJCQkJLyogZW11bGF0aW9uIHJlc3AgYnVmZiBhZnRlcgkq
LworCQkJCQkJLyogY21kIGV4ZWMuCQkJKi8KKworLyogQWRkaXRpb25hbCBTZW5zZSBDb2RlIChB
U0MpIHVzZWQgKi8KKyNkZWZpbmUgTk9fQURESVRJT05BTF9TRU5TRQkJMHgwCisjZGVmaW5lIExP
R0lDQUxfVU5JVF9OT1RfUkVBRFkJCTB4NAorI2RlZmluZSBVTlJFQ09WRVJFRF9SRUFEX0VSUgkJ
MHgxMQorI2RlZmluZSBQQVJBTUVURVJfTElTVF9MRU5HVEhfRVJSCTB4MWEKKyNkZWZpbmUgSU5W
QUxJRF9PUENPREUJCQkweDIwCisjZGVmaW5lIEFERFJfT1VUX09GX1JBTkdFCQkweDIxCisjZGVm
aW5lIElOVkFMSURfRklFTERfSU5fQ0RCCQkweDI0CisjZGVmaW5lIElOVkFMSURfRklFTERfSU5f
UEFSQU1fTElTVAkweDI2CisjZGVmaW5lIFBPV0VST05fUkVTRVQJCQkweDI5CisjZGVmaW5lIFNB
VklOR19QQVJBTVNfVU5TVVAJCTB4MzkKKyNkZWZpbmUgVEhSRVNIT0xEX0VYQ0VFREVECQkweDVk
CisjZGVmaW5lIExPV19QT1dFUl9DT05EX09OCQkweDVlCisKKworCisvKiBOdW1iZXIgb3MgU0NT
SSBvcF9jb2RlCSovCisjZGVmaW5lIFZTQ1NJX01BWF9TQ1NJX09QX0NPREUJCTI1Ngorc3RhdGlj
IHVuc2lnbmVkIGNoYXIgYml0bWFwW1ZTQ1NJX01BWF9TQ1NJX09QX0NPREVdOworCisjZGVmaW5l
IE5PX0VNVUxBVEUoY21kKSBcCisJYml0bWFwW2NtZF0gPSBWU0NTSUlGX05FRURfQ01EX0VYRUM7
IFwKKwlwcmVfZnVuY3Rpb25bY21kXSA9IE5VTEw7IFwKKwlwb3N0X2Z1bmN0aW9uW2NtZF0gPSBO
VUxMCisKKworCisvKgorICBFbXVsYXRpb24gcm91dGluZXMgZm9yIGVhY2ggU0NTSSBvcF9jb2Rl
LgorKi8KK3N0YXRpYyB2b2lkICgqcHJlX2Z1bmN0aW9uW1ZTQ1NJX01BWF9TQ1NJX09QX0NPREVd
KShwZW5kaW5nX3JlcV90ICosIHZvaWQgKik7CitzdGF0aWMgdm9pZCAoKnBvc3RfZnVuY3Rpb25b
VlNDU0lfTUFYX1NDU0lfT1BfQ09ERV0pKHBlbmRpbmdfcmVxX3QgKiwgdm9pZCAqKTsKKworCitz
dGF0aWMgY29uc3QgaW50IGNoZWNrX2NvbmRpdGlvbl9yZXN1bHQgPQorCQkoRFJJVkVSX1NFTlNF
IDw8IDI0KSB8IFNBTV9TVEFUX0NIRUNLX0NPTkRJVElPTjsKKworc3RhdGljIHZvaWQgc2NzaWJh
Y2tfbWtfc2Vuc2VfYnVmZmVyKHVpbnQ4X3QgKmRhdGEsIHVpbnQ4X3Qga2V5LAorCQkJdWludDhf
dCBhc2MsIHVpbnQ4X3QgYXNxKQoreworCWRhdGFbMF0gPSAweDcwOyAgLyogZml4ZWQsIGN1cnJl
bnQgKi8KKwlkYXRhWzJdID0ga2V5OworCWRhdGFbN10gPSAweGE7CSAgLyogaW1wbGllcyAxOCBi
eXRlIHNlbnNlIGJ1ZmZlciAqLworCWRhdGFbMTJdID0gYXNjOworCWRhdGFbMTNdID0gYXNxOwor
fQorCitzdGF0aWMgdm9pZCByZXNwX25vdF9zdXBwb3J0ZWRfY21kKHBlbmRpbmdfcmVxX3QgKnBl
bmRpbmdfcmVxLCB2b2lkICpkYXRhKQoreworCXNjc2liYWNrX21rX3NlbnNlX2J1ZmZlcihwZW5k
aW5nX3JlcS0+c2Vuc2VfYnVmZmVyLCBJTExFR0FMX1JFUVVFU1QsCisJCUlOVkFMSURfT1BDT0RF
LCAwKTsKKwlwZW5kaW5nX3JlcS0+cmVzaWQgPSAwOworCXBlbmRpbmdfcmVxLT5yc2x0ICA9IGNo
ZWNrX2NvbmRpdGlvbl9yZXN1bHQ7Cit9CisKKworc3RhdGljIGludCBfX2NvcHlfdG9fc2coc3Ry
dWN0IHNjYXR0ZXJsaXN0ICpzZ2wsIHVuc2lnbmVkIGludCBucl9zZywKKwkgICAgICAgdm9pZCAq
YnVmLCB1bnNpZ25lZCBpbnQgYnVmbGVuKQoreworCXN0cnVjdCBzY2F0dGVybGlzdCAqc2c7CisJ
dm9pZCAqZnJvbSA9IGJ1ZjsKKwl2b2lkICp0bzsKKwl1bnNpZ25lZCBpbnQgZnJvbV9yZXN0ID0g
YnVmbGVuOworCXVuc2lnbmVkIGludCB0b19jYXBhOworCXVuc2lnbmVkIGludCBjb3B5X3NpemUg
PSAwOworCXVuc2lnbmVkIGludCBpOworCXVuc2lnbmVkIGxvbmcgcGZuOworCisJZm9yX2VhY2hf
c2cgKHNnbCwgc2csIG5yX3NnLCBpKSB7CisJCWlmIChzZ19wYWdlKHNnKSA9PSBOVUxMKSB7CisJ
CQlwcmludGsoS0VSTl9XQVJOSU5HICIlczogaW5jb25zaXN0ZW50IGxlbmd0aCBmaWVsZCBpbiAi
CisJCQkgICAgICAgInNjYXR0ZXJsaXN0XG4iLCBfX0ZVTkNUSU9OX18pOworCQkJcmV0dXJuIC1F
Tk9NRU07CisJCX0KKworCQl0b19jYXBhICA9IHNnLT5sZW5ndGg7CisJCWNvcHlfc2l6ZSA9IG1p
bl90KHVuc2lnbmVkIGludCwgdG9fY2FwYSwgZnJvbV9yZXN0KTsKKworCQlwZm4gPSBwYWdlX3Rv
X3BmbihzZ19wYWdlKHNnKSk7CisJCXRvID0gcGZuX3RvX2thZGRyKHBmbikgKyAoc2ctPm9mZnNl
dCk7CisJCW1lbWNweSh0bywgZnJvbSwgY29weV9zaXplKTsKKworCQlmcm9tX3Jlc3QgIC09IGNv
cHlfc2l6ZTsKKwkJaWYgKGZyb21fcmVzdCA9PSAwKSB7CisJCQlyZXR1cm4gMDsKKwkJfQorCisJ
CWZyb20gKz0gY29weV9zaXplOworCX0KKworCXByaW50ayhLRVJOX1dBUk5JTkcgIiVzOiBubyBz
cGFjZSBpbiBzY2F0dGVybGlzdFxuIiwKKwkgICAgICAgX19GVU5DVElPTl9fKTsKKwlyZXR1cm4g
LUVOT01FTTsKK30KKyNpZiAwCitzdGF0aWMgaW50IF9fY29weV9mcm9tX3NnKHN0cnVjdCBzY2F0
dGVybGlzdCAqc2dsLCB1bnNpZ25lZCBpbnQgbnJfc2csCisJCSB2b2lkICpidWYsIHVuc2lnbmVk
IGludCBidWZsZW4pCit7CisJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsKKwl2b2lkICpmcm9tOwor
CXZvaWQgKnRvID0gYnVmOworCXVuc2lnbmVkIGludCBmcm9tX3Jlc3Q7CisJdW5zaWduZWQgaW50
IHRvX2NhcGEgPSBidWZsZW47CisJdW5zaWduZWQgaW50IGNvcHlfc2l6ZTsKKwl1bnNpZ25lZCBp
bnQgaTsKKwl1bnNpZ25lZCBsb25nIHBmbjsKKworCWZvcl9lYWNoX3NnIChzZ2wsIHNnLCBucl9z
ZywgaSkgeworCQlpZiAoc2dfcGFnZShzZykgPT0gTlVMTCkgeworCQkJcHJpbnRrKEtFUk5fV0FS
TklORyAiJXM6IGluY29uc2lzdGVudCBsZW5ndGggZmllbGQgaW4gIgorCQkJICAgICAgICJzY2F0
dGVybGlzdFxuIiwgX19GVU5DVElPTl9fKTsKKwkJCXJldHVybiAtRU5PTUVNOworCQl9CisKKwkJ
ZnJvbV9yZXN0ID0gc2ctPmxlbmd0aDsKKwkJaWYgKChmcm9tX3Jlc3QgPiAwKSAmJiAodG9fY2Fw
YSA8IGZyb21fcmVzdCkpIHsKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcKKwkJCSAgICAgICAiJXM6
IG5vIHNwYWNlIGluIGRlc3RpbmF0aW9uIGJ1ZmZlclxuIiwKKwkJCSAgICAgICBfX0ZVTkNUSU9O
X18pOworCQkJcmV0dXJuIC1FTk9NRU07CisJCX0KKwkJY29weV9zaXplID0gZnJvbV9yZXN0Owor
CisJCXBmbiA9IHBhZ2VfdG9fcGZuKHNnX3BhZ2Uoc2cpKTsKKwkJZnJvbSA9IHBmbl90b19rYWRk
cihwZm4pICsgKHNnLT5vZmZzZXQpOworCQltZW1jcHkodG8sIGZyb20sIGNvcHlfc2l6ZSk7CisK
KwkJdG9fY2FwYSAgLT0gY29weV9zaXplOworCQl0byArPSBjb3B5X3NpemU7CisJfQorCisJcmV0
dXJuIDA7Cit9CisjZW5kaWYKK3N0YXRpYyBpbnQgX19ucl9sdW5zX3VuZGVyX2hvc3Qoc3RydWN0
IHZzY3NpYmtfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgdjJwX2VudHJ5ICplbnRyeTsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICpoZWFkID0gJihpbmZvLT52MnBfZW50cnlfbGlzdHMpOworCXVuc2lnbmVk
IGxvbmcgZmxhZ3M7CisJaW50IGx1bl9jbnQgPSAwOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmlu
Zm8tPnYycF9sb2NrLCBmbGFncyk7CisJbGlzdF9mb3JfZWFjaF9lbnRyeShlbnRyeSwgaGVhZCwg
bCkgeworCQkJbHVuX2NudCsrOworCX0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpbmZvLT52
MnBfbG9jaywgZmxhZ3MpOworCisJcmV0dXJuIChsdW5fY250KTsKK30KKworCisvKiBSRVBPUlQg
TFVOUyBEZWZpbmUqLworI2RlZmluZSBWU0NTSV9SRVBPUlRfTFVOU19IRUFERVIJOAorI2RlZmlu
ZSBWU0NTSV9SRVBPUlRfTFVOU19SRVRSWQkJMworCisvKiBxdW90ZWQgc2NzaV9kZWJ1Zy5jL3Jl
c3BfcmVwb3J0X2x1bnMoKSAqLworc3RhdGljIHZvaWQgX19yZXBvcnRfbHVucyhwZW5kaW5nX3Jl
cV90ICpwZW5kaW5nX3JlcSwgdm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgdnNjc2lia19pbmZvICpp
bmZvICAgPSBwZW5kaW5nX3JlcS0+aW5mbzsKKwl1bnNpZ25lZCBpbnQgICAgICAgIGNoYW5uZWwg
PSBwZW5kaW5nX3JlcS0+dl9jaG47CisJdW5zaWduZWQgaW50ICAgICAgICB0YXJnZXQgID0gcGVu
ZGluZ19yZXEtPnZfdGd0OworCXVuc2lnbmVkIGludCAgICAgICAgbnJfc2VnICA9IHBlbmRpbmdf
cmVxLT5ucl9zZWdtZW50czsKKwl1bnNpZ25lZCBjaGFyICpjbWQgPSAodW5zaWduZWQgY2hhciAq
KXBlbmRpbmdfcmVxLT5jbW5kOworCisJdW5zaWduZWQgY2hhciAqYnVmZiA9IE5VTEw7CisJdW5z
aWduZWQgY2hhciBhbGxvY19sZW47CisJdW5zaWduZWQgaW50IGFsbG9jX2x1bnMgPSAwOworCXVu
c2lnbmVkIGludCByZXFfYnVmZmxlbiA9IDA7CisJdW5zaWduZWQgaW50IGFjdHVhbF9sZW4gPSAw
OworCXVuc2lnbmVkIGludCByZXRyeV9jbnQgPSAwOworCWludCBzZWxlY3RfcmVwb3J0ID0gKGlu
dCljbWRbMl07CisJaW50IGksIGx1bl9jbnQgPSAwLCBsdW4sIHVwcGVyLCBlcnIgPSAwOworCisJ
c3RydWN0IHYycF9lbnRyeSAqZW50cnk7CisJc3RydWN0IGxpc3RfaGVhZCAqaGVhZCA9ICYoaW5m
by0+djJwX2VudHJ5X2xpc3RzKTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCisJc3RydWN0IHNj
c2lfbHVuICpvbmVfbHVuOworCisJcmVxX2J1ZmZsZW4gPSBjbWRbOV0gKyAoY21kWzhdIDw8IDgp
ICsgKGNtZFs3XSA8PCAxNikgKyAoY21kWzZdIDw8IDI0KTsKKwlpZiAoKHJlcV9idWZmbGVuIDwg
NCkgfHwgKHNlbGVjdF9yZXBvcnQgIT0gMCkpCisJCWdvdG8gZmFpbDsKKworCWFsbG9jX2x1bnMg
PSBfX25yX2x1bnNfdW5kZXJfaG9zdChpbmZvKTsKKwlhbGxvY19sZW4gID0gc2l6ZW9mKHN0cnVj
dCBzY3NpX2x1bikgKiBhbGxvY19sdW5zCisJCQkJKyBWU0NTSV9SRVBPUlRfTFVOU19IRUFERVI7
CityZXRyeToKKwlpZiAoKGJ1ZmYgPSBremFsbG9jKGFsbG9jX2xlbiwgR0ZQX0tFUk5FTCkpID09
IE5VTEwpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazolcyBrbWFsbG9jIGVyclxuIiwg
X19GVU5DVElPTl9fKTsKKwkJZ290byBmYWlsOworCX0KKworCW9uZV9sdW4gPSAoc3RydWN0IHNj
c2lfbHVuICopICZidWZmWzhdOworCXNwaW5fbG9ja19pcnFzYXZlKCZpbmZvLT52MnBfbG9jaywg
ZmxhZ3MpOworCWxpc3RfZm9yX2VhY2hfZW50cnkoZW50cnksIGhlYWQsIGwpIHsKKwkJaWYgKChl
bnRyeS0+di5jaG4gPT0gY2hhbm5lbCkgJiYKKwkJICAgIChlbnRyeS0+di50Z3QgPT0gdGFyZ2V0
KSkgeworCQkJLyogY2hlY2sgb3ZlcmZsb3cgKi8KKwkJCWlmIChsdW5fY250ID49IGFsbG9jX2x1
bnMpIHsKKwkJCQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpbmZvLT52MnBfbG9jaywKKwkJCQkJ
CQlmbGFncyk7CisKKwkJCQlpZiAocmV0cnlfY250IDwgVlNDU0lfUkVQT1JUX0xVTlNfUkVUUlkp
IHsKKwkJCQkJcmV0cnlfY250Kys7CisJCQkJCWlmIChidWZmKQorCQkJCQkJa2ZyZWUoYnVmZik7
CisJCQkJCWdvdG8gcmV0cnk7CisJCQkJfQorCisJCQkJZ290byBmYWlsOworCQkJfQorCisJCQls
dW4gPSBlbnRyeS0+di5sdW47CisJCQl1cHBlciA9IChsdW4gPj4gOCkgJiAweDNmOworCQkJaWYg
KHVwcGVyKQorCQkJCW9uZV9sdW5bbHVuX2NudF0uc2NzaV9sdW5bMF0gPSB1cHBlcjsKKwkJCW9u
ZV9sdW5bbHVuX2NudF0uc2NzaV9sdW5bMV0gPSBsdW4gJiAweGZmOworCQkJbHVuX2NudCsrOwor
CQl9CisJfQorCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+djJwX2xvY2ssIGZsYWdz
KTsKKworCWJ1ZmZbMl0gPSAoKHNpemVvZihzdHJ1Y3Qgc2NzaV9sdW4pICogbHVuX2NudCkgPj4g
OCkgJiAweGZmOworCWJ1ZmZbM10gPSAoc2l6ZW9mKHN0cnVjdCBzY3NpX2x1bikgKiBsdW5fY250
KSAmIDB4ZmY7CisKKwlhY3R1YWxfbGVuID0gbHVuX2NudCAqIHNpemVvZihzdHJ1Y3Qgc2NzaV9s
dW4pCisJCQkJKyBWU0NTSV9SRVBPUlRfTFVOU19IRUFERVI7CisJcmVxX2J1ZmZsZW4gPSAwOwor
CWZvciAoaSA9IDA7IGkgPCBucl9zZWc7IGkrKykKKwkJcmVxX2J1ZmZsZW4gKz0gcGVuZGluZ19y
ZXEtPnNnbFtpXS5sZW5ndGg7CisKKwllcnIgPSBfX2NvcHlfdG9fc2cocGVuZGluZ19yZXEtPnNn
bCwgbnJfc2VnLCBidWZmLAorCQkJCW1pbihyZXFfYnVmZmxlbiwgYWN0dWFsX2xlbikpOworCWlm
IChlcnIpCisJCWdvdG8gZmFpbDsKKworCW1lbXNldChwZW5kaW5nX3JlcS0+c2Vuc2VfYnVmZmVy
LCAwLCBWU0NTSUlGX1NFTlNFX0JVRkZFUlNJWkUpOworCXBlbmRpbmdfcmVxLT5yc2x0ID0gMHgw
MDsKKwlwZW5kaW5nX3JlcS0+cmVzaWQgPSByZXFfYnVmZmxlbiAtIG1pbihyZXFfYnVmZmxlbiwg
YWN0dWFsX2xlbik7CisKKwlrZnJlZShidWZmKTsKKwlyZXR1cm47CisKK2ZhaWw6CisJc2NzaWJh
Y2tfbWtfc2Vuc2VfYnVmZmVyKHBlbmRpbmdfcmVxLT5zZW5zZV9idWZmZXIsIElMTEVHQUxfUkVR
VUVTVCwKKwkJSU5WQUxJRF9GSUVMRF9JTl9DREIsIDApOworCXBlbmRpbmdfcmVxLT5yc2x0ICA9
IGNoZWNrX2NvbmRpdGlvbl9yZXN1bHQ7CisJcGVuZGluZ19yZXEtPnJlc2lkID0gMDsKKwlpZiAo
YnVmZikKKwkJa2ZyZWUoYnVmZik7CisJcmV0dXJuOworfQorCisKKworaW50IF9fcHJlX2RvX2Vt
dWxhdGlvbihwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcSwgdm9pZCAqZGF0YSkKK3sKKwl1aW50
OF90IG9wX2NvZGUgPSBwZW5kaW5nX3JlcS0+Y21uZFswXTsKKworCWlmICgoYml0bWFwW29wX2Nv
ZGVdICYgVlNDU0lJRl9ORUVEX0VNVUxBVEVfUkVRQlVGKSAmJgorCSAgICBwcmVfZnVuY3Rpb25b
b3BfY29kZV0gIT0gTlVMTCkgeworCQlwcmVfZnVuY3Rpb25bb3BfY29kZV0ocGVuZGluZ19yZXEs
IGRhdGEpOworCX0KKworCS8qCisJICAgIDA6IG5vIG5lZWQgZm9yIG5hdGl2ZSBkcml2ZXIgY2Fs
bCwgc28gc2hvdWxkIHJldHVybiBpbW1lZGlhdGVseS4KKwkgICAgMTogbm9uIGVtdWxhdGlvbiBv
ciBzaG91bGQgY2FsbCBuYXRpdmUgZHJpdmVyCisJICAgICAgIGFmdGVyIG1vZGlmaW5nIHRoZSBy
ZXF1ZXN0IGJ1ZmZlci4KKwkqLworCXJldHVybiAhIShiaXRtYXBbb3BfY29kZV0gJiBWU0NTSUlG
X05FRURfQ01EX0VYRUMpOworfQorCit2b2lkIHNjc2liYWNrX3JzcF9lbXVsYXRpb24ocGVuZGlu
Z19yZXFfdCAqcGVuZGluZ19yZXEpCit7CisJdWludDhfdCBvcF9jb2RlID0gcGVuZGluZ19yZXEt
PmNtbmRbMF07CisKKwlpZiAoKGJpdG1hcFtvcF9jb2RlXSAmIFZTQ1NJSUZfTkVFRF9FTVVMQVRF
X1JTUEJVRikgJiYKKwkgICAgcG9zdF9mdW5jdGlvbltvcF9jb2RlXSAhPSBOVUxMKSB7CisJCXBv
c3RfZnVuY3Rpb25bb3BfY29kZV0ocGVuZGluZ19yZXEsIE5VTEwpOworCX0KKworCXJldHVybjsK
K30KKworCit2b2lkIHNjc2liYWNrX3JlcV9lbXVsYXRpb25fb3JfY21kZXhlYyhwZW5kaW5nX3Jl
cV90ICpwZW5kaW5nX3JlcSkKK3sKKwlpZiAoX19wcmVfZG9fZW11bGF0aW9uKHBlbmRpbmdfcmVx
LCBOVUxMKSkgeworCQlzY3NpYmFja19jbWRfZXhlYyhwZW5kaW5nX3JlcSk7CisJfQorCWVsc2Ug
eworCQlzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVuZGluZ19yZXEpOworCQlzY3NpYmFja19k
b19yZXNwX3dpdGhfc2Vuc2UocGVuZGluZ19yZXEtPnNlbnNlX2J1ZmZlciwKKwkJICBwZW5kaW5n
X3JlcS0+cnNsdCwgcGVuZGluZ19yZXEtPnJlc2lkLCBwZW5kaW5nX3JlcSk7CisJfQorfQorCisK
Ky8qCisgIEZvbGxvd2luZyBhcmUgbm90IGN1c3RvbWl6YWJsZSBmdW5jdGlvbnMuCisqLwordm9p
ZCBzY3NpYmFja19lbXVsYXRpb25faW5pdCh2b2lkKQoreworCWludCBpOworCisJLyogSW5pdGlh
bGl6ZSB0byBkZWZhdWx0IHN0YXRlICovCisJZm9yIChpID0gMDsgaSA8IFZTQ1NJX01BWF9TQ1NJ
X09QX0NPREU7IGkrKykgeworCQliaXRtYXBbaV0gICAgICAgID0gKFZTQ1NJSUZfTkVFRF9FTVVM
QVRFX1JFUUJVRiB8CisJCQkJCVZTQ1NJSUZfTkVFRF9FTVVMQVRFX1JTUEJVRik7CisJCXByZV9m
dW5jdGlvbltpXSAgPSByZXNwX25vdF9zdXBwb3J0ZWRfY21kOworCQlwb3N0X2Z1bmN0aW9uW2ld
ID0gTlVMTDsKKwkJLyogbWVhbnMsCisJCSAgIC0gbm8gbmVlZCBmb3IgcHJlLWVtdWxhdGlvbgor
CQkgICAtIG5vIG5lZWQgZm9yIHBvc3QtZW11bGF0aW9uCisJCSAgIC0gY2FsbCBuYXRpdmUgZHJp
dmVyCisJCSovCisJfQorCisJLyoKKwkgIFJlZ2lzdGVyIGFwcHJvcHJpYXRlIGZ1bmN0aW9ucyBi
ZWxvdyBhcyB5b3UgbmVlZC4KKwkgIChTZWUgc2NzaS9zY3NpLmggZm9yIGRlZmluaXRpb24gb2Yg
U0NTSSBvcF9jb2RlLikKKwkqLworCisJLyoKKwkgIEZvbGxvd2luZyBjb21tYW5kcyBkbyBub3Qg
cmVxdWlyZSBlbXVsYXRpb24uCisJKi8KKwlOT19FTVVMQVRFKFRFU1RfVU5JVF9SRUFEWSk7ICAg
ICAgIC8qMHgwMCovIC8qIHNkLHN0ICovCisJTk9fRU1VTEFURShSRVpFUk9fVU5JVCk7ICAgICAg
ICAgICAvKjB4MDEqLyAvKiBzdCAqLworCU5PX0VNVUxBVEUoUkVRVUVTVF9TRU5TRSk7ICAgICAg
ICAgLyoweDAzKi8KKwlOT19FTVVMQVRFKEZPUk1BVF9VTklUKTsgICAgICAgICAgIC8qMHgwNCov
CisJTk9fRU1VTEFURShSRUFEX0JMT0NLX0xJTUlUUyk7ICAgICAvKjB4MDUqLyAvKiBzdCAqLwor
CS8qTk9fRU1VTEFURShSRUFTU0lHTl9CTE9DS1MpOyAgICAgICAqLy8qMHgwNyovCisJTk9fRU1V
TEFURShJTklUSUFMSVpFX0VMRU1FTlRfU1RBVFVTKTsgLyoweDA3Ki8gLyogY2ggKi8KKwlOT19F
TVVMQVRFKFJFQURfNik7ICAgICAgICAgICAgICAgIC8qMHgwOCovIC8qIHNkLHN0ICovCisJTk9f
RU1VTEFURShXUklURV82KTsgICAgICAgICAgICAgICAvKjB4MGEqLyAvKiBzZCxzdCAqLworCU5P
X0VNVUxBVEUoU0VFS182KTsgICAgICAgICAgICAgICAgLyoweDBiKi8KKwkvKk5PX0VNVUxBVEUo
UkVBRF9SRVZFUlNFKTsgICAgICAgICAgKi8vKjB4MGYqLworCU5PX0VNVUxBVEUoV1JJVEVfRklM
RU1BUktTKTsgICAgICAgLyoweDEwKi8gLyogc3QgKi8KKwlOT19FTVVMQVRFKFNQQUNFKTsgICAg
ICAgICAgICAgICAgIC8qMHgxMSovIC8qIHN0ICovCisJTk9fRU1VTEFURShJTlFVSVJZKTsgICAg
ICAgICAgICAgICAvKjB4MTIqLworCS8qTk9fRU1VTEFURShSRUNPVkVSX0JVRkZFUkVEX0RBVEEp
OyAqLy8qMHgxNCovCisJTk9fRU1VTEFURShNT0RFX1NFTEVDVCk7ICAgICAgICAgICAvKjB4MTUq
LyAvKiBzdCAqLworCU5PX0VNVUxBVEUoUkVTRVJWRSk7ICAgICAgICAgICAgICAgLyoweDE2Ki8K
KwlOT19FTVVMQVRFKFJFTEVBU0UpOyAgICAgICAgICAgICAgIC8qMHgxNyovCisJLypOT19FTVVM
QVRFKENPUFkpOyAgICAgICAgICAgICAgICAgICovLyoweDE4Ki8KKwlOT19FTVVMQVRFKEVSQVNF
KTsgICAgICAgICAgICAgICAgIC8qMHgxOSovIC8qIHN0ICovCisJTk9fRU1VTEFURShNT0RFX1NF
TlNFKTsgICAgICAgICAgICAvKjB4MWEqLyAvKiBzdCAqLworCU5PX0VNVUxBVEUoU1RBUlRfU1RP
UCk7ICAgICAgICAgICAgLyoweDFiKi8gLyogc2Qsc3QgKi8KKwlOT19FTVVMQVRFKFJFQ0VJVkVf
RElBR05PU1RJQyk7ICAgIC8qMHgxYyovCisJTk9fRU1VTEFURShTRU5EX0RJQUdOT1NUSUMpOyAg
ICAgICAvKjB4MWQqLworCU5PX0VNVUxBVEUoQUxMT1dfTUVESVVNX1JFTU9WQUwpOyAgLyoweDFl
Ki8KKworCS8qTk9fRU1VTEFURShTRVRfV0lORE9XKTsgICAgICAgICAgICAqLy8qMHgyNCovCisJ
Tk9fRU1VTEFURShSRUFEX0NBUEFDSVRZKTsgICAgICAgICAvKjB4MjUqLyAvKiBzZCAqLworCU5P
X0VNVUxBVEUoUkVBRF8xMCk7ICAgICAgICAgICAgICAgLyoweDI4Ki8gLyogc2QgKi8KKwlOT19F
TVVMQVRFKFdSSVRFXzEwKTsgICAgICAgICAgICAgIC8qMHgyYSovIC8qIHNkICovCisJTk9fRU1V
TEFURShTRUVLXzEwKTsgICAgICAgICAgICAgICAvKjB4MmIqLyAvKiBzdCAqLworCU5PX0VNVUxB
VEUoUE9TSVRJT05fVE9fRUxFTUVOVCk7ICAgLyoweDJiKi8gLyogY2ggKi8KKwkvKk5PX0VNVUxB
VEUoV1JJVEVfVkVSSUZZKTsgICAgICAgICAgKi8vKjB4MmUqLworCS8qTk9fRU1VTEFURShWRVJJ
RlkpOyAgICAgICAgICAgICAgICAqLy8qMHgyZiovCisJLypOT19FTVVMQVRFKFNFQVJDSF9ISUdI
KTsgICAgICAgICAgICovLyoweDMwKi8KKwkvKk5PX0VNVUxBVEUoU0VBUkNIX0VRVUFMKTsgICAg
ICAgICAgKi8vKjB4MzEqLworCS8qTk9fRU1VTEFURShTRUFSQ0hfTE9XKTsgICAgICAgICAgICAq
Ly8qMHgzMiovCisJTk9fRU1VTEFURShTRVRfTElNSVRTKTsgICAgICAgICAgICAvKjB4MzMqLwor
CU5PX0VNVUxBVEUoUFJFX0ZFVENIKTsgICAgICAgICAgICAgLyoweDM0Ki8gLyogc3QhICovCisJ
Tk9fRU1VTEFURShSRUFEX1BPU0lUSU9OKTsgICAgICAgICAgLyoweDM0Ki8gLyogc3QgKi8KKwlO
T19FTVVMQVRFKFNZTkNIUk9OSVpFX0NBQ0hFKTsgICAgICAvKjB4MzUqLyAvKiBzZCAqLworCU5P
X0VNVUxBVEUoTE9DS19VTkxPQ0tfQ0FDSEUpOyAgICAgLyoweDM2Ki8KKwlOT19FTVVMQVRFKFJF
QURfREVGRUNUX0RBVEEpOyAgICAgIC8qMHgzNyovCisJTk9fRU1VTEFURShNRURJVU1fU0NBTik7
ICAgICAgICAgICAvKjB4MzgqLworCS8qTk9fRU1VTEFURShDT01QQVJFKTsgICAgICAgICAgICAg
ICAqLy8qMHgzOSovCisJLypOT19FTVVMQVRFKENPUFlfVkVSSUZZKTsgICAgICAgICAgICovLyow
eDNhKi8KKwlOT19FTVVMQVRFKFdSSVRFX0JVRkZFUik7ICAgICAgICAgIC8qMHgzYiovCisJTk9f
RU1VTEFURShSRUFEX0JVRkZFUik7ICAgICAgICAgICAvKjB4M2MqLyAvKiBvc3N0ICovCisJLypO
T19FTVVMQVRFKFVQREFURV9CTE9DSyk7ICAgICAgICAgICovLyoweDNkKi8KKwkvKk5PX0VNVUxB
VEUoUkVBRF9MT05HKTsgICAgICAgICAgICAgKi8vKjB4M2UqLworCS8qTk9fRU1VTEFURShXUklU
RV9MT05HKTsgICAgICAgICAgICAqLy8qMHgzZiovCisJLypOT19FTVVMQVRFKENIQU5HRV9ERUZJ
TklUSU9OKTsgICAgICovLyoweDQwKi8KKwkvKk5PX0VNVUxBVEUoV1JJVEVfU0FNRSk7ICAgICAg
ICAgICAgKi8vKjB4NDEqLworCU5PX0VNVUxBVEUoUkVBRF9UT0MpOyAgICAgICAgICAgICAgLyow
eDQzKi8gLyogc3IgKi8KKwlOT19FTVVMQVRFKExPR19TRUxFQ1QpOyAgICAgICAgICAgIC8qMHg0
YyovCisJTk9fRU1VTEFURShMT0dfU0VOU0UpOyAgICAgICAgICAgICAvKjB4NGQqLyAvKiBzdCEg
Ki8KKwkvKk5PX0VNVUxBVEUoTU9ERV9TRUxFQ1RfMTApOyAgICAgICAgKi8vKjB4NTUqLworCS8q
Tk9fRU1VTEFURShSRVNFUlZFXzEwKTsgICAgICAgICAgICAqLy8qMHg1NiovCisJLypOT19FTVVM
QVRFKFJFTEVBU0VfMTApOyAgICAgICAgICAgICovLyoweDU3Ki8KKwlOT19FTVVMQVRFKE1PREVf
U0VOU0VfMTApOyAgICAgICAgIC8qMHg1YSovIC8qIHNjc2lfbGliICovCisJLypOT19FTVVMQVRF
KFBFUlNJU1RFTlRfUkVTRVJWRV9JTik7ICovLyoweDVlKi8KKwkvKk5PX0VNVUxBVEUoUEVSU0lT
VEVOVF9SRVNFUlZFX09VVCk7ICovLyoweDVmKi8KKwkvKiAgICAgICAgICAgUkVQT1JUX0xVTlMg
ICAgICAgICAgICAgKi8vKjB4YTAqLy8qRnVsbCBlbXVsYWl0b24qLworCU5PX0VNVUxBVEUoTUFJ
TlRFTkFOQ0VfSU4pOyAgICAgICAgICAgLyoweGEzKi8gLyogSUZUIGFsdWEgKi8KKwlOT19FTVVM
QVRFKE1BSU5URU5BTkNFX09VVCk7ICAgICAgIC8qMHhhNCovIC8qIElGVCBhbHVhICovCisJTk9f
RU1VTEFURShNT1ZFX01FRElVTSk7ICAgICAgICAgICAvKjB4YTUqLyAvKiBjaCAqLworCU5PX0VN
VUxBVEUoRVhDSEFOR0VfTUVESVVNKTsgICAgICAgLyoweGE2Ki8gLyogY2ggKi8KKwkvKk5PX0VN
VUxBVEUoUkVBRF8xMik7ICAgICAgICAgICAgICAgKi8vKjB4YTgqLworCS8qTk9fRU1VTEFURShX
UklURV8xMik7ICAgICAgICAgICAgICAqLy8qMHhhYSovCisJLypOT19FTVVMQVRFKFdSSVRFX1ZF
UklGWV8xMik7ICAgICAgICovLyoweGFlKi8KKwkvKk5PX0VNVUxBVEUoU0VBUkNIX0hJR0hfMTIp
OyAgICAgICAgKi8vKjB4YjAqLworCS8qTk9fRU1VTEFURShTRUFSQ0hfRVFVQUxfMTIpOyAgICAg
ICAqLy8qMHhiMSovCisJLypOT19FTVVMQVRFKFNFQVJDSF9MT1dfMTIpOyAgICAgICAgICovLyow
eGIyKi8KKwlOT19FTVVMQVRFKFJFQURfRUxFTUVOVF9TVEFUVVMpOyAgIC8qMHhiOCovIC8qIGNo
ICovCisJTk9fRU1VTEFURShTRU5EX1ZPTFVNRV9UQUcpOyAgICAgICAvKjB4YjYqLyAvKiBjaCAq
LworCS8qTk9fRU1VTEFURShXUklURV9MT05HXzIpOyAgICAgICAgICAqLy8qMHhlYSovCisJTk9f
RU1VTEFURShSRUFEXzE2KTsgICAgICAgICAgICAgICAvKjB4ODgqLyAvKiBzZCA+MlRCICovCisJ
Tk9fRU1VTEFURShXUklURV8xNik7ICAgICAgICAgICAgICAvKjB4OGEqLyAvKiBzZCA+MlRCICov
CisJTk9fRU1VTEFURShWRVJJRllfMTYpOwkgICAgICAgICAgIC8qMHg4ZiovCisJTk9fRU1VTEFU
RShTRVJWSUNFX0FDVElPTl9JTik7ICAgICAvKjB4OWUqLyAvKiBzZCA+MlRCICovCisKKy8qIHN0
OiBRRkFfUkVRVUVTVF9CTE9DSywgUUZBX1NFRUtfQkxPQ0sgbWlnaHQgYmUgbmVlZGVkID8gKi8K
KwkvKgorCSAgRm9sbG93aW5nIGNvbW1hbmRzIHJlcXVpcmUgZW11bGF0aW9uLgorCSovCisJcHJl
X2Z1bmN0aW9uW1JFUE9SVF9MVU5TXSA9IF9fcmVwb3J0X2x1bnM7CisJYml0bWFwW1JFUE9SVF9M
VU5TXSA9IChWU0NTSUlGX05FRURfRU1VTEFURV9SRVFCVUYgfAorCQkJCQlWU0NTSUlGX05FRURf
RU1VTEFURV9SU1BCVUYpOworCisJcmV0dXJuOworfQpkaWZmIC1ydXBOIHhlbi9kcml2ZXJzL3Nj
c2kveGVuLXNjc2liYWNrL2ludGVyZmFjZS5jIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFj
ay9pbnRlcmZhY2UuYwotLS0geGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWJhY2svaW50ZXJmYWNl
LmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3MDAKKysrIHhlbmMvZHJpdmVycy9z
Y3NpL3hlbi1zY3NpYmFjay9pbnRlcmZhY2UuYwkyMDEyLTAyLTI0IDE0OjU2OjEzLjUzODk3ODMw
MCAtMDcwMApAQCAtMCwwICsxLDE0MSBAQAorLyoKKyAqIGludGVyZmFjZSBtYW5hZ2VtZW50Lgor
ICoKKyAqIENvcHlyaWdodCAoYykgMjAwOCwgRlVKSVRTVSBMaW1pdGVkCisgKgorICogQmFzZWQg
b24gdGhlIGJsa2JhY2sgZHJpdmVyIGNvZGUuCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUg
c29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAy
CisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgb3IsIHdo
ZW4gZGlzdHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgga2VybmVsIG9yIGlu
Y29ycG9yYXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywgc3ViamVjdCB0byB0
aGUgZm9sbG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRl
ZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2Yg
dGhpcyBzb3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRoZSBTb2Z0d2Fy
ZSB3aXRob3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiB0
aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1Ymxpc2gsIGRpc3Ry
aWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUsCisg
KiBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUgaXMgZnVybmlzaGVk
IHRvIGRvIHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6CisgKgor
ICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ug
c2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3RhbnRpYWwgcG9ydGlv
bnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMg
SVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9SCisgKiBJTVBMSUVE
LCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GIE1FUkNIQU5U
QUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZS
SU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBPUiBDT1BZUklHSFQg
SE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBPVEhFUgorICogTElB
QklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJ
U0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNP
RlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRIRSBTT0ZUV0FSRS4K
KyAqLworCisjaW5jbHVkZSA8c2NzaS9zY3NpLmg+CisjaW5jbHVkZSA8c2NzaS9zY3NpX2hvc3Qu
aD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfZGV2aWNlLmg+CisjaW5jbHVkZSAiY29tbW9uLmgiCisK
KyNpbmNsdWRlIDx4ZW4vZXZ0Y2huLmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2lu
Y2x1ZGUgPGxpbnV4L2RlbGF5Lmg+CisKKworc3RhdGljIHN0cnVjdCBrbWVtX2NhY2hlICpzY3Np
YmFja19jYWNoZXA7CisKK3N0cnVjdCB2c2NzaWJrX2luZm8gKnZzY3NpYmtfaW5mb19hbGxvYyhk
b21pZF90IGRvbWlkKQoreworCXN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm87CisKKwlpbmZvID0g
a21lbV9jYWNoZV96YWxsb2Moc2NzaWJhY2tfY2FjaGVwLCBHRlBfS0VSTkVMKTsKKwlpZiAoIWlu
Zm8pCisJCXJldHVybiBFUlJfUFRSKC1FTk9NRU0pOworCisJaW5mby0+ZG9taWQgPSBkb21pZDsK
KwlzcGluX2xvY2tfaW5pdCgmaW5mby0+cmluZ19sb2NrKTsKKwlhdG9taWNfc2V0KCZpbmZvLT5u
cl91bnJlcGxpZWRfcmVxcywgMCk7CisJaW5pdF93YWl0cXVldWVfaGVhZCgmaW5mby0+d3EpOwor
CWluaXRfd2FpdHF1ZXVlX2hlYWQoJmluZm8tPndhaXRpbmdfdG9fZnJlZSk7CisKKwlyZXR1cm4g
aW5mbzsKK30KKworaW50IHNjc2liYWNrX2luaXRfc3Jpbmcoc3RydWN0IHZzY3NpYmtfaW5mbyAq
aW5mbywKKwkJdW5zaWduZWQgbG9uZyByaW5nX3JlZiwgdW5zaWduZWQgaW50IGV2dGNobikKK3sK
KwlzdHJ1Y3QgdnNjc2lpZl9zcmluZyAqc3Jpbmc7CisJaW50IGVycjsKKworCWlmICghaW5mbykK
KwkJcmV0dXJuIC1FTk9ERVY7CisKKwlpZiAoaW5mby0+aXJxKSB7CisJCXByaW50ayhLRVJOX0VS
UiAic2NzaWJhY2s6IEFscmVhZHkgY29ubmVjdGVkIHRocm91Z2g/XG4iKTsKKwkJcmV0dXJuIC0x
OworCX0KKworCWVyciA9IHhlbmJ1c19tYXBfcmluZ192YWxsb2MoaW5mby0+ZGV2LCByaW5nX3Jl
ZiwgJmluZm8tPnJpbmdfYXJlYSk7CisJaWYgKGVyciA8IDApCisJCXJldHVybiAtRU5PTUVNOwor
CisJc3JpbmcgPSAoc3RydWN0IHZzY3NpaWZfc3JpbmcgKikgaW5mby0+cmluZ19hcmVhOworCUJB
Q0tfUklOR19JTklUKCZpbmZvLT5yaW5nLCBzcmluZywgUEFHRV9TSVpFKTsKKworCWVyciA9IGJp
bmRfaW50ZXJkb21haW5fZXZ0Y2huX3RvX2lycWhhbmRsZXIoCisJCQlpbmZvLT5kb21pZCwgZXZ0
Y2huLAorCQkJc2NzaWJhY2tfaW50ciwgMCwgInZzY3NpaWYtYmFja2VuZCIsIGluZm8pOworCWlm
IChlcnIgPCAwKQorCQlnb3RvIHVubWFwX3BhZ2U7CisKKwlpbmZvLT5pcnEgPSBlcnI7CisKKwly
ZXR1cm4gMDsKKwordW5tYXBfcGFnZToKKwl4ZW5idXNfdW5tYXBfcmluZ192ZnJlZShpbmZvLT5k
ZXYsIGluZm8tPnJpbmdfYXJlYSk7CisKKwlyZXR1cm4gZXJyOworfQorCit2b2lkIHNjc2liYWNr
X2Rpc2Nvbm5lY3Qoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbykKK3sKKwlpZiAoaW5mby0+a3Ro
cmVhZCkgeworCQlrdGhyZWFkX3N0b3AoaW5mby0+a3RocmVhZCk7CisJCWluZm8tPmt0aHJlYWQg
PSBOVUxMOworCX0KKworCXdhaXRfZXZlbnQoaW5mby0+d2FpdGluZ190b19mcmVlLAorCQlhdG9t
aWNfcmVhZCgmaW5mby0+bnJfdW5yZXBsaWVkX3JlcXMpID09IDApOworCisJaWYgKGluZm8tPmly
cSkgeworCQl1bmJpbmRfZnJvbV9pcnFoYW5kbGVyKGluZm8tPmlycSwgaW5mbyk7CisJCWluZm8t
PmlycSA9IDA7CisJfQorCisJaWYgKGluZm8tPnJpbmcuc3JpbmcgfHwgaW5mby0+cmluZ19hcmVh
KSB7CisJCXhlbmJ1c191bm1hcF9yaW5nX3ZmcmVlKGluZm8tPmRldiwgaW5mby0+cmluZ19hcmVh
KTsKKwkJaW5mby0+cmluZy5zcmluZyA9IE5VTEw7CisJCWluZm8tPnJpbmdfYXJlYSA9IE5VTEw7
CisJfQorfQorCit2b2lkIHNjc2liYWNrX2ZyZWUoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbykK
K3sKKwlrbWVtX2NhY2hlX2ZyZWUoc2NzaWJhY2tfY2FjaGVwLCBpbmZvKTsKK30KKworaW50IF9f
aW5pdCBzY3NpYmFja19pbnRlcmZhY2VfaW5pdCh2b2lkKQoreworCXNjc2liYWNrX2NhY2hlcCA9
IGttZW1fY2FjaGVfY3JlYXRlKCJ2c2NzaWlmX2NhY2hlIiwKKwkJc2l6ZW9mKHN0cnVjdCB2c2Nz
aWJrX2luZm8pLCAwLCAwLCBOVUxMKTsKKwlpZiAoIXNjc2liYWNrX2NhY2hlcCkgeworCQlwcmlu
dGsoS0VSTl9FUlIgInNjc2liYWNrOiBjYW4ndCBpbml0IHNjc2kgY2FjaGVcbiIpOworCQlyZXR1
cm4gLUVOT01FTTsKKwl9CisKKwlyZXR1cm4gMDsKK30KKwordm9pZCBzY3NpYmFja19pbnRlcmZh
Y2VfZXhpdCh2b2lkKQoreworCWttZW1fY2FjaGVfZGVzdHJveShzY3NpYmFja19jYWNoZXApOwor
fQpkaWZmIC1ydXBOIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3Njc2liYWNrLmMgeGVu
Yy9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3Njc2liYWNrLmMKLS0tIHhlbi9kcml2ZXJzL3Nj
c2kveGVuLXNjc2liYWNrL3Njc2liYWNrLmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAg
LTA3MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFjay9zY3NpYmFjay5jCTIwMTIt
MDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNzU3IEBACisvKgorICog
WGVuIFNDU0kgYmFja2VuZCBkcml2ZXIKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZVSklU
U1UgTGltaXRlZAorICoKKyAqIEJhc2VkIG9uIHRoZSBibGtiYWNrIGRyaXZlciBjb2RlLgorICoK
KyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBp
dCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisgKiBzZXBhcmF0ZWx5IGZy
b20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBvdGhlcgorICogc29mdHdh
cmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNlbnNlOgorICoKKyAqIFBl
cm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVyc29u
IG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUgKHRoZSAiU29mdHdhcmUi
KSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVzdHJpY3Rpb24sIGluY2x1
ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlmeSwK
KyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3Igc2VsbCBj
b3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdob20g
dGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0bworICogdGhlIGZv
bGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFu
ZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwgY29w
aWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUg
U09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lO
RCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBU
SEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJ
Q1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUK
KyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0s
IERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04gT0Yg
Q09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0YgT1Ig
SU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERFQUxJ
TkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L3NwaW5sb2Nr
Lmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2luY2x1ZGUgPGxpbnV4L2xpc3QuaD4K
KyNpbmNsdWRlIDxsaW51eC9kZWxheS5oPgorI2luY2x1ZGUgPHhlbi9iYWxsb29uLmg+CisjaW5j
bHVkZSA8YXNtL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2kuaD4KKyNpbmNsdWRl
IDxzY3NpL3Njc2lfY21uZC5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaV9ob3N0Lmg+CisjaW5jbHVk
ZSA8c2NzaS9zY3NpX2RldmljZS5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaV9kYmcuaD4KKyNpbmNs
dWRlIDxzY3NpL3Njc2lfZWguaD4KKworI2luY2x1ZGUgImNvbW1vbi5oIgorCisKK3N0cnVjdCBs
aXN0X2hlYWQgcGVuZGluZ19mcmVlOworREVGSU5FX1NQSU5MT0NLKHBlbmRpbmdfZnJlZV9sb2Nr
KTsKK0RFQ0xBUkVfV0FJVF9RVUVVRV9IRUFEKHBlbmRpbmdfZnJlZV93cSk7CisKK2ludCB2c2Nz
aWlmX3JlcXMgPSBWU0NTSUlGX0JBQ0tfTUFYX1BFTkRJTkdfUkVRUzsKK21vZHVsZV9wYXJhbV9u
YW1lZChyZXFzLCB2c2NzaWlmX3JlcXMsIGludCwgMCk7CitNT0RVTEVfUEFSTV9ERVNDKHJlcXMs
ICJOdW1iZXIgb2Ygc2NzaWJhY2sgcmVxdWVzdHMgdG8gYWxsb2NhdGUiKTsKKworc3RhdGljIHVu
c2lnbmVkIGludCBsb2dfcHJpbnRfc3RhdDsKK21vZHVsZV9wYXJhbShsb2dfcHJpbnRfc3RhdCwg
aW50LCAwNjQ0KTsKKworI2RlZmluZSBTQ1NJQkFDS19JTlZBTElEX0hBTkRMRSAofjApCisKK3N0
YXRpYyBwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcXM7CitzdGF0aWMgc3RydWN0IHBhZ2UgKipw
ZW5kaW5nX3BhZ2VzOworc3RhdGljIGdyYW50X2hhbmRsZV90ICpwZW5kaW5nX2dyYW50X2hhbmRs
ZXM7CisKK3N0YXRpYyBpbnQgdmFkZHJfcGFnZW5yKHBlbmRpbmdfcmVxX3QgKnJlcSwgaW50IHNl
ZykKK3sKKwlyZXR1cm4gKHJlcSAtIHBlbmRpbmdfcmVxcykgKiBWU0NTSUlGX1NHX1RBQkxFU0la
RSArIHNlZzsKK30KKworc3RhdGljIHVuc2lnbmVkIGxvbmcgdmFkZHIocGVuZGluZ19yZXFfdCAq
cmVxLCBpbnQgc2VnKQoreworCXVuc2lnbmVkIGxvbmcgcGZuID0gcGFnZV90b19wZm4ocGVuZGlu
Z19wYWdlc1t2YWRkcl9wYWdlbnIocmVxLCBzZWcpXSk7CisJcmV0dXJuICh1bnNpZ25lZCBsb25n
KXBmbl90b19rYWRkcihwZm4pOworfQorCisjZGVmaW5lIHBlbmRpbmdfaGFuZGxlKF9yZXEsIF9z
ZWcpIFwKKwkocGVuZGluZ19ncmFudF9oYW5kbGVzW3ZhZGRyX3BhZ2VucihfcmVxLCBfc2VnKV0p
CisKKwordm9pZCBzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVuZGluZ19yZXFfdCAqcmVxKQor
eworCXN0cnVjdCBnbnR0YWJfdW5tYXBfZ3JhbnRfcmVmIHVubWFwW1ZTQ1NJSUZfU0dfVEFCTEVT
SVpFXTsKKwl1bnNpZ25lZCBpbnQgaSwgaW52Y291bnQgPSAwOworCWdyYW50X2hhbmRsZV90IGhh
bmRsZTsKKwlpbnQgZXJyOworCisJaWYgKHJlcS0+bnJfc2VnbWVudHMpIHsKKwkJZm9yIChpID0g
MDsgaSA8IHJlcS0+bnJfc2VnbWVudHM7IGkrKykgeworCQkJaGFuZGxlID0gcGVuZGluZ19oYW5k
bGUocmVxLCBpKTsKKwkJCWlmIChoYW5kbGUgPT0gU0NTSUJBQ0tfSU5WQUxJRF9IQU5ETEUpCisJ
CQkJY29udGludWU7CisJCQlnbnR0YWJfc2V0X3VubWFwX29wKCZ1bm1hcFtpXSwgdmFkZHIocmVx
LCBpKSwKKwkJCQkJCUdOVE1BUF9ob3N0X21hcCwgaGFuZGxlKTsKKwkJCXBlbmRpbmdfaGFuZGxl
KHJlcSwgaSkgPSBTQ1NJQkFDS19JTlZBTElEX0hBTkRMRTsKKwkJCWludmNvdW50Kys7CisJCX0K
KworCQllcnIgPSBIWVBFUlZJU09SX2dyYW50X3RhYmxlX29wKAorCQkJR05UVEFCT1BfdW5tYXBf
Z3JhbnRfcmVmLCB1bm1hcCwgaW52Y291bnQpOworCQlCVUdfT04oZXJyKTsKKwkJZm9yIChpID0g
MDsgaSA8aW52Y291bnQ7IGkrKykgeworCQkJZXJyID0gbTJwX3JlbW92ZV9vdmVycmlkZSgKKwkJ
CQl2aXJ0X3RvX3BhZ2UodW5tYXBbaV0uaG9zdF9hZGRyKSwgZmFsc2UpOworCQkJV0FSTl9PTihl
cnIpOworCQl9CisJCWtmcmVlKHJlcS0+c2dsKTsKKwl9CisKKwlyZXR1cm47Cit9CisKKworc3Rh
dGljIHBlbmRpbmdfcmVxX3QgKiBhbGxvY19yZXEoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbykK
K3sKKwlwZW5kaW5nX3JlcV90ICpyZXEgPSBOVUxMOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisK
KwlzcGluX2xvY2tfaXJxc2F2ZSgmcGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwlpZiAoIWxp
c3RfZW1wdHkoJnBlbmRpbmdfZnJlZSkpIHsKKwkJcmVxID0gbGlzdF9lbnRyeShwZW5kaW5nX2Zy
ZWUubmV4dCwgcGVuZGluZ19yZXFfdCwgZnJlZV9saXN0KTsKKwkJbGlzdF9kZWwoJnJlcS0+ZnJl
ZV9saXN0KTsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcGVuZGluZ19mcmVlX2xvY2ss
IGZsYWdzKTsKKwlyZXR1cm4gcmVxOworfQorCisKK3N0YXRpYyB2b2lkIGZyZWVfcmVxKHBlbmRp
bmdfcmVxX3QgKnJlcSkKK3sKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCB3YXNfZW1wdHk7
CisKKwlzcGluX2xvY2tfaXJxc2F2ZSgmcGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwl3YXNf
ZW1wdHkgPSBsaXN0X2VtcHR5KCZwZW5kaW5nX2ZyZWUpOworCWxpc3RfYWRkKCZyZXEtPmZyZWVf
bGlzdCwgJnBlbmRpbmdfZnJlZSk7CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcGVuZGluZ19m
cmVlX2xvY2ssIGZsYWdzKTsKKwlpZiAod2FzX2VtcHR5KQorCQl3YWtlX3VwKCZwZW5kaW5nX2Zy
ZWVfd3EpOworfQorCisKK3N0YXRpYyB2b2lkIHNjc2liYWNrX25vdGlmeV93b3JrKHN0cnVjdCB2
c2NzaWJrX2luZm8gKmluZm8pCit7CisJaW5mby0+d2FpdGluZ19yZXFzID0gMTsKKwl3YWtlX3Vw
KCZpbmZvLT53cSk7Cit9CisKK3ZvaWQgc2NzaWJhY2tfZG9fcmVzcF93aXRoX3NlbnNlKGNoYXIg
KnNlbnNlX2J1ZmZlciwgaW50MzJfdCByZXN1bHQsCisJCQl1aW50MzJfdCByZXNpZCwgcGVuZGlu
Z19yZXFfdCAqcGVuZGluZ19yZXEpCit7CisJdnNjc2lpZl9yZXNwb25zZV90ICpyaW5nX3JlczsK
KwlzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvID0gcGVuZGluZ19yZXEtPmluZm87CisJaW50IG5v
dGlmeTsKKwlpbnQgbW9yZV90b19kbyA9IDE7CisJc3RydWN0IHNjc2lfc2Vuc2VfaGRyIHNzaGRy
OworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisKKwlEUFJJTlRLKCIlc1xuIixfX0ZVTkNUSU9OX18p
OworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmluZm8tPnJpbmdfbG9jaywgZmxhZ3MpOworCisJcmlu
Z19yZXMgPSBSSU5HX0dFVF9SRVNQT05TRSgmaW5mby0+cmluZywgaW5mby0+cmluZy5yc3BfcHJv
ZF9wdnQpOworCWluZm8tPnJpbmcucnNwX3Byb2RfcHZ0Kys7CisKKwlyaW5nX3Jlcy0+cnNsdCAg
ID0gcmVzdWx0OworCXJpbmdfcmVzLT5ycWlkICAgPSBwZW5kaW5nX3JlcS0+cnFpZDsKKworCWlm
IChzZW5zZV9idWZmZXIgIT0gTlVMTCkgeworCQlpZiAoc2NzaV9ub3JtYWxpemVfc2Vuc2Uoc2Vu
c2VfYnVmZmVyLAorCQkJc2l6ZW9mKHNlbnNlX2J1ZmZlciksICZzc2hkcikpIHsKKworCQkJaW50
IGxlbiA9IDggKyBzZW5zZV9idWZmZXJbN107CisKKwkJCWlmIChsZW4gPiBWU0NTSUlGX1NFTlNF
X0JVRkZFUlNJWkUpCisJCQkJbGVuID0gVlNDU0lJRl9TRU5TRV9CVUZGRVJTSVpFOworCisJCQlt
ZW1jcHkocmluZ19yZXMtPnNlbnNlX2J1ZmZlciwgc2Vuc2VfYnVmZmVyLCBsZW4pOworCQkJcmlu
Z19yZXMtPnNlbnNlX2xlbiA9IGxlbjsKKwkJfQorCX0gZWxzZSB7CisJCXJpbmdfcmVzLT5zZW5z
ZV9sZW4gPSAwOworCX0KKworCXJpbmdfcmVzLT5yZXNpZHVhbF9sZW4gPSByZXNpZDsKKworCVJJ
TkdfUFVTSF9SRVNQT05TRVNfQU5EX0NIRUNLX05PVElGWSgmaW5mby0+cmluZywgbm90aWZ5KTsK
KwlpZiAoaW5mby0+cmluZy5yc3BfcHJvZF9wdnQgPT0gaW5mby0+cmluZy5yZXFfY29ucykgewor
CQlSSU5HX0ZJTkFMX0NIRUNLX0ZPUl9SRVFVRVNUUygmaW5mby0+cmluZywgbW9yZV90b19kbyk7
CisJfSBlbHNlIGlmIChSSU5HX0hBU19VTkNPTlNVTUVEX1JFUVVFU1RTKCZpbmZvLT5yaW5nKSkg
eworCQltb3JlX3RvX2RvID0gMTsKKwl9CisKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpbmZv
LT5yaW5nX2xvY2ssIGZsYWdzKTsKKworCWlmIChtb3JlX3RvX2RvKQorCQlzY3NpYmFja19ub3Rp
Znlfd29yayhpbmZvKTsKKworCWlmIChub3RpZnkpCisJCW5vdGlmeV9yZW1vdGVfdmlhX2lycShp
bmZvLT5pcnEpOworCisJZnJlZV9yZXEocGVuZGluZ19yZXEpOworfQorCitzdGF0aWMgdm9pZCBz
Y3NpYmFja19wcmludF9zdGF0dXMoY2hhciAqc2Vuc2VfYnVmZmVyLCBpbnQgZXJyb3JzLAorCQkJ
CQlwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcSkKK3sKKwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNk
ZXYgPSBwZW5kaW5nX3JlcS0+c2RldjsKKworCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6ICVk
OiVkOiVkOiVkICIsc2Rldi0+aG9zdC0+aG9zdF9ubywKKwkJCXNkZXYtPmNoYW5uZWwsIHNkZXYt
PmlkLCBzZGV2LT5sdW4pOworCXByaW50ayhLRVJOX0VSUiAic3RhdHVzID0gMHglMDJ4LCBtZXNz
YWdlID0gMHglMDJ4LCBob3N0ID0gMHglMDJ4LCBkcml2ZXIgPSAweCUwMnhcbiIsCisJCQlzdGF0
dXNfYnl0ZShlcnJvcnMpLCBtc2dfYnl0ZShlcnJvcnMpLAorCQkJaG9zdF9ieXRlKGVycm9ycyks
IGRyaXZlcl9ieXRlKGVycm9ycykpOworCisJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogY21u
ZFswXT0weCUwMlhcbiIsCisJCQlwZW5kaW5nX3JlcS0+Y21uZFswXSk7CisKKwlpZiAoQ0hFQ0tf
Q09ORElUSU9OICYgc3RhdHVzX2J5dGUoZXJyb3JzKSkKKwkJX19zY3NpX3ByaW50X3NlbnNlKCJz
Y3NpYmFjayIsIHNlbnNlX2J1ZmZlciwgU0NTSV9TRU5TRV9CVUZGRVJTSVpFKTsKK30KKworCitz
dGF0aWMgdm9pZCBzY3NpYmFja19jbWRfZG9uZShzdHJ1Y3QgcmVxdWVzdCAqcmVxLCBpbnQgdXB0
b2RhdGUpCit7CisJcGVuZGluZ19yZXFfdCAqcGVuZGluZ19yZXEgPSByZXEtPmVuZF9pb19kYXRh
OworCXVuc2lnbmVkIGNoYXIgKnNlbnNlX2J1ZmZlcjsKKwl1bnNpZ25lZCBpbnQgcmVzaWQ7CisJ
aW50IGVycm9yczsKKworCXNlbnNlX2J1ZmZlciA9IHJlcS0+c2Vuc2U7CisJcmVzaWQgICAgICAg
ID0gYmxrX3JxX2J5dGVzKHJlcSk7CisJZXJyb3JzICAgICAgID0gcmVxLT5lcnJvcnM7CisKKwlp
ZiAoZXJyb3JzICE9IDApIHsKKwkJaWYgKGxvZ19wcmludF9zdGF0KQorCQkJc2NzaWJhY2tfcHJp
bnRfc3RhdHVzKHNlbnNlX2J1ZmZlciwgZXJyb3JzLCBwZW5kaW5nX3JlcSk7CisJfQorCisJLyog
VGhlIEhvc3QgbW9kZSBpcyB0aHJvdWdoIGFzIGZvciBFbXVsYXRpb24uICovCisJaWYgKHBlbmRp
bmdfcmVxLT5pbmZvLT5mZWF0dXJlICE9IFZTQ1NJX1RZUEVfSE9TVCkKKwkJc2NzaWJhY2tfcnNw
X2VtdWxhdGlvbihwZW5kaW5nX3JlcSk7CisKKwlzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVu
ZGluZ19yZXEpOworCXNjc2liYWNrX2RvX3Jlc3Bfd2l0aF9zZW5zZShzZW5zZV9idWZmZXIsIGVy
cm9ycywgcmVzaWQsIHBlbmRpbmdfcmVxKTsKKwlzY3NpYmFja19wdXQocGVuZGluZ19yZXEtPmlu
Zm8pOworCisJX19ibGtfcHV0X3JlcXVlc3QocmVxLT5xLCByZXEpOworfQorCisKK3N0YXRpYyBp
bnQgc2NzaWJhY2tfZ250dGFiX2RhdGFfbWFwKHZzY3NpaWZfcmVxdWVzdF90ICpyaW5nX3JlcSwK
KwkJCQkJcGVuZGluZ19yZXFfdCAqcGVuZGluZ19yZXEpCit7CisJdTMyIGZsYWdzOworCWludCB3
cml0ZTsKKwlpbnQgaSwgZXJyID0gMDsKKwl1bnNpZ25lZCBpbnQgZGF0YV9sZW4gPSAwOworCXN0
cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiBtYXBbVlNDU0lJRl9TR19UQUJMRVNJWkVdOworCXN0
cnVjdCB2c2NzaWJrX2luZm8gKmluZm8gICA9IHBlbmRpbmdfcmVxLT5pbmZvOworCisJaW50IGRh
dGFfZGlyID0gcGVuZGluZ19yZXEtPnNjX2RhdGFfZGlyZWN0aW9uOworCXVuc2lnbmVkIGludCBu
cl9zZWdtZW50cyA9ICh1bnNpZ25lZCBpbnQpcGVuZGluZ19yZXEtPm5yX3NlZ21lbnRzOworCisJ
d3JpdGUgPSAoZGF0YV9kaXIgPT0gRE1BX1RPX0RFVklDRSk7CisKKwlpZiAobnJfc2VnbWVudHMp
IHsKKwkJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsKKworCQkvKiBmcmVlIG9mIChzZ2wpIGluIGZh
c3RfZmx1c2hfYXJlYSgpKi8KKwkJcGVuZGluZ19yZXEtPnNnbCA9IGttYWxsb2Moc2l6ZW9mKHN0
cnVjdCBzY2F0dGVybGlzdCkgKiBucl9zZWdtZW50cywKKwkJCQkJCUdGUF9LRVJORUwpOworCQlp
ZiAoIXBlbmRpbmdfcmVxLT5zZ2wpIHsKKwkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6ICVz
OiBrbWFsbG9jKCkgZXJyb3IuXG4iLCBfX0ZVTkNUSU9OX18pOworCQkJcmV0dXJuIC1FTk9NRU07
CisJCX0KKworCQlzZ19pbml0X3RhYmxlKHBlbmRpbmdfcmVxLT5zZ2wsIG5yX3NlZ21lbnRzKTsK
KworCQlmb3IgKGkgPSAwOyBpIDwgbnJfc2VnbWVudHM7IGkrKykgeworCQkJZmxhZ3MgPSBHTlRN
QVBfaG9zdF9tYXA7CisJCQlpZiAod3JpdGUpCisJCQkJZmxhZ3MgfD0gR05UTUFQX3JlYWRvbmx5
OworCisJCQlnbnR0YWJfc2V0X21hcF9vcCgmbWFwW2ldLCB2YWRkcihwZW5kaW5nX3JlcSwgaSks
IGZsYWdzLAorCQkJCQkJcmluZ19yZXEtPnNlZ1tpXS5ncmVmLAorCQkJCQkJaW5mby0+ZG9taWQp
OworCQl9CisKKwkJZXJyID0gSFlQRVJWSVNPUl9ncmFudF90YWJsZV9vcChHTlRUQUJPUF9tYXBf
Z3JhbnRfcmVmLCBtYXAsIG5yX3NlZ21lbnRzKTsKKwkJQlVHX09OKGVycik7CisKKwkJLyogUmV0
cnkgbWFwcyB3aXRoIEdOVFNUX2VhZ2FpbiAqLworCQlmb3IoaT0wOyBpIDwgbnJfc2VnbWVudHM7
IGkrKykgeworCQkgICAgd2hpbGUodW5saWtlbHkobWFwW2ldLnN0YXR1cyA9PSBHTlRTVF9lYWdh
aW4pKQorCQkgICAgeworCQkJCW1zbGVlcCgxMCk7CisJCQkJZXJyID0gSFlQRVJWSVNPUl9ncmFu
dF90YWJsZV9vcChHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmLAorCQkJCQkJCSZtYXBbaV0sCisJCQkJ
CQkJMSk7CisJCQkJQlVHX09OKGVycik7CisJCSAgICB9CisJCX0KKworCQlmb3JfZWFjaF9zZyAo
cGVuZGluZ19yZXEtPnNnbCwgc2csIG5yX3NlZ21lbnRzLCBpKSB7CisJCQlzdHJ1Y3QgcGFnZSAq
cGc7CisKKwkJCWlmICh1bmxpa2VseShtYXBbaV0uc3RhdHVzICE9IDApKSB7CisJCQkJcHJpbnRr
KEtFUk5fRVJSICJzY3NpYmFjazogaW52YWxpZCBidWZmZXIgLS0gY291bGQgbm90IHJlbWFwIGl0
OiAiIFwKKwkJCQkJIiVkLyVkLCBlcnI6JWRcbiIsIGksIG5yX3NlZ21lbnRzLCBtYXBbaV0uc3Rh
dHVzKTsKKwkJCQltYXBbaV0uaGFuZGxlID0gU0NTSUJBQ0tfSU5WQUxJRF9IQU5ETEU7CisJCQkJ
ZXJyIHw9IDE7CisJCQl9CisKKwkJCXBlbmRpbmdfaGFuZGxlKHBlbmRpbmdfcmVxLCBpKSA9IG1h
cFtpXS5oYW5kbGU7CisKKwkJCWlmIChlcnIpCisJCQkJY29udGludWU7CisKKwkJCXBnID0gcGVu
ZGluZ19wYWdlc1t2YWRkcl9wYWdlbnIocGVuZGluZ19yZXEsIGkpXTsKKworCQkJbTJwX2FkZF9v
dmVycmlkZShQRk5fRE9XTihtYXBbaV0uZGV2X2J1c19hZGRyKSwgcGcsIGZhbHNlKTsKKwkJCXNn
X3NldF9wYWdlKHNnLCBwZywgcmluZ19yZXEtPnNlZ1tpXS5sZW5ndGgsCisJCQkJICAgIHJpbmdf
cmVxLT5zZWdbaV0ub2Zmc2V0KTsKKwkJCWRhdGFfbGVuICs9IHNnLT5sZW5ndGg7CisKKwkJCWJh
cnJpZXIoKTsKKwkJCWlmIChzZy0+b2Zmc2V0ID49IFBBR0VfU0laRSB8fAorCQkJICAgIHNnLT5s
ZW5ndGggPiBQQUdFX1NJWkUgfHwKKwkJCSAgICBzZy0+b2Zmc2V0ICsgc2ctPmxlbmd0aCA+IFBB
R0VfU0laRSkKKwkJCQllcnIgfD0gMTsKKworCQl9CisKKwkJaWYgKGVycikKKwkJCWdvdG8gZmFp
bF9mbHVzaDsKKwl9CisKKwlwZW5kaW5nX3JlcS0+cmVxdWVzdF9idWZmbGVuID0gZGF0YV9sZW47
CisKKwlyZXR1cm4gMDsKKworZmFpbF9mbHVzaDoKKwlzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEo
cGVuZGluZ19yZXEpOworCXJldHVybiAtRU5PTUVNOworfQorCisvKiBxdW90ZWQgc2NzaV9saWIu
Yy9zY3NpX2JpX2VuZGlvICovCitzdGF0aWMgdm9pZCBzY3NpYmFja19iaV9lbmRpbyhzdHJ1Y3Qg
YmlvICpiaW8sIGludCBlcnJvcikKK3sKKwliaW9fcHV0KGJpbyk7Cit9CisKKworCisvKiBxdW90
ZWQgc2NzaV9saWIuYy9zY3NpX3JlcV9tYXBfc2cgLiAqLworc3RhdGljIHN0cnVjdCBiaW8gKnJl
cXVlc3RfbWFwX3NnKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdfcmVxKQoreworCXN0cnVjdCByZXF1
ZXN0X3F1ZXVlICpxID0gcGVuZGluZ19yZXEtPnNkZXYtPnJlcXVlc3RfcXVldWU7CisJdW5zaWdu
ZWQgaW50IG5zZWdzID0gKHVuc2lnbmVkIGludClwZW5kaW5nX3JlcS0+bnJfc2VnbWVudHM7CisJ
dW5zaWduZWQgaW50IGksIGxlbiwgYnl0ZXMsIG9mZiwgbnJfcGFnZXMsIG5yX3ZlY3MgPSAwOwor
CXN0cnVjdCBzY2F0dGVybGlzdCAqc2c7CisJc3RydWN0IHBhZ2UgKnBhZ2U7CisJc3RydWN0IGJp
byAqYmlvID0gTlVMTCwgKmJpb19maXJzdCA9IE5VTEwsICpiaW9fbGFzdCA9IE5VTEw7CisJaW50
IGVycjsKKworCWZvcl9lYWNoX3NnIChwZW5kaW5nX3JlcS0+c2dsLCBzZywgbnNlZ3MsIGkpIHsK
KwkJcGFnZSA9IHNnX3BhZ2Uoc2cpOworCQlvZmYgPSBzZy0+b2Zmc2V0OworCQlsZW4gPSBzZy0+
bGVuZ3RoOworCisJCW5yX3BhZ2VzID0gKGxlbiArIG9mZiArIFBBR0VfU0laRSAtIDEpID4+IFBB
R0VfU0hJRlQ7CisJCXdoaWxlIChsZW4gPiAwKSB7CisJCQlieXRlcyA9IG1pbl90KHVuc2lnbmVk
IGludCwgbGVuLCBQQUdFX1NJWkUgLSBvZmYpOworCisJCQlpZiAoIWJpbykgeworCQkJCW5yX3Zl
Y3MgPSBtaW5fdCh1bnNpZ25lZCBpbnQsIEJJT19NQVhfUEFHRVMsCisJCQkJCSAJbnJfcGFnZXMp
OworCQkJCW5yX3BhZ2VzIC09IG5yX3ZlY3M7CisJCQkJYmlvID0gYmlvX2FsbG9jKEdGUF9LRVJO
RUwsIG5yX3ZlY3MpOworCQkJCWlmICghYmlvKSB7CisJCQkJCWVyciA9IC1FTk9NRU07CisJCQkJ
CWdvdG8gZnJlZV9iaW9zOworCQkJCX0KKwkJCQliaW8tPmJpX2VuZF9pbyA9IHNjc2liYWNrX2Jp
X2VuZGlvOworCQkJCWlmIChiaW9fbGFzdCkKKwkJCQkJYmlvX2xhc3QtPmJpX25leHQgPSBiaW87
CisJCQkJZWxzZQorCQkJCQliaW9fZmlyc3QgPSBiaW87CisJCQkJYmlvX2xhc3QgPSBiaW87CisJ
CQl9CisKKwkJCWlmIChiaW9fYWRkX3BjX3BhZ2UocSwgYmlvLCBwYWdlLCBieXRlcywgb2ZmKSAh
PQorCQkJCQkJYnl0ZXMpIHsKKwkJCQliaW9fcHV0KGJpbyk7CisJCQkJZXJyID0gLUVJTlZBTDsK
KwkJCQlnb3RvIGZyZWVfYmlvczsKKwkJCX0KKworCQkJaWYgKGJpby0+YmlfdmNudCA+PSBucl92
ZWNzKSB7CisJCQkJYmlvLT5iaV9mbGFncyAmPSB+KDEgPDwgQklPX1NFR19WQUxJRCk7CisJCQkJ
aWYgKHBlbmRpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiA9PSBXUklURSkKKwkJCQkJYmlvLT5i
aV9ydyB8PSBSRVFfV1JJVEU7CisJCQkJYmlvID0gTlVMTDsKKwkJCX0KKworCQkJcGFnZSsrOwor
CQkJbGVuIC09IGJ5dGVzOworCQkJb2ZmID0gMDsKKwkJfQorCX0KKworCXJldHVybiBiaW9fZmly
c3Q7CisKK2ZyZWVfYmlvczoKKwl3aGlsZSAoKGJpbyA9IGJpb19maXJzdCkgIT0gTlVMTCkgewor
CQliaW9fZmlyc3QgPSBiaW8tPmJpX25leHQ7CisJCWJpb19wdXQoYmlvKTsKKwl9CisKKwlyZXR1
cm4gRVJSX1BUUihlcnIpOworfQorCisKK3ZvaWQgc2NzaWJhY2tfY21kX2V4ZWMocGVuZGluZ19y
ZXFfdCAqcGVuZGluZ19yZXEpCit7CisJaW50IGNtZF9sZW4gID0gKGludClwZW5kaW5nX3JlcS0+
Y21kX2xlbjsKKwlpbnQgZGF0YV9kaXIgPSAoaW50KXBlbmRpbmdfcmVxLT5zY19kYXRhX2RpcmVj
dGlvbjsKKwl1bnNpZ25lZCBpbnQgdGltZW91dDsKKwlzdHJ1Y3QgcmVxdWVzdCAqcnE7CisJaW50
IHdyaXRlOworCisJRFBSSU5USygiJXNcbiIsX19GVU5DVElPTl9fKTsKKworCS8qIGJlY2F1c2Ug
aXQgZG9lc24ndCB0aW1lb3V0IGJhY2tlbmQgZWFybGllciB0aGFuIGZyb250ZW5kLiovCisJaWYg
KHBlbmRpbmdfcmVxLT50aW1lb3V0X3Blcl9jb21tYW5kKQorCQl0aW1lb3V0ID0gcGVuZGluZ19y
ZXEtPnRpbWVvdXRfcGVyX2NvbW1hbmQgKiBIWjsKKwllbHNlCisJCXRpbWVvdXQgPSBWU0NTSUlG
X1RJTUVPVVQ7CisKKwl3cml0ZSA9IChkYXRhX2RpciA9PSBETUFfVE9fREVWSUNFKTsKKwlpZiAo
cGVuZGluZ19yZXEtPm5yX3NlZ21lbnRzKSB7CisJCXN0cnVjdCBiaW8gKmJpbyA9IHJlcXVlc3Rf
bWFwX3NnKHBlbmRpbmdfcmVxKTsKKworCQlpZiAoSVNfRVJSKGJpbykpIHsKKwkJCXByaW50ayhL
RVJOX0VSUiAic2NzaWJhY2s6IFNHIFJlcXVlc3QgTWFwIEVycm9yXG4iKTsKKwkJCXJldHVybjsK
KwkJfQorCisJCXJxID0gYmxrX21ha2VfcmVxdWVzdChwZW5kaW5nX3JlcS0+c2Rldi0+cmVxdWVz
dF9xdWV1ZSwgYmlvLAorCQkJCSAgICAgIEdGUF9LRVJORUwpOworCQlpZiAoSVNfRVJSKHJxKSkg
eworCQkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogTWFrZSBSZXF1ZXN0IEVycm9yXG4iKTsK
KwkJCXJldHVybjsKKwkJfQorCisJCXJxLT5idWZmZXIgPSBOVUxMOworCX0gZWxzZSB7CisJCXJx
ID0gYmxrX2dldF9yZXF1ZXN0KHBlbmRpbmdfcmVxLT5zZGV2LT5yZXF1ZXN0X3F1ZXVlLCB3cml0
ZSwKKwkJCQkgICAgIEdGUF9LRVJORUwpOworCQlpZiAodW5saWtlbHkoIXJxKSkgeworCQkJcHJp
bnRrKEtFUk5fRVJSICJzY3NpYmFjazogR2V0IFJlcXVlc3QgRXJyb3JcbiIpOworCQkJcmV0dXJu
OworCQl9CisJfQorCisJcnEtPmNtZF90eXBlID0gUkVRX1RZUEVfQkxPQ0tfUEM7CisJcnEtPmNt
ZF9sZW4gPSBjbWRfbGVuOworCW1lbWNweShycS0+Y21kLCBwZW5kaW5nX3JlcS0+Y21uZCwgY21k
X2xlbik7CisKKwltZW1zZXQocGVuZGluZ19yZXEtPnNlbnNlX2J1ZmZlciwgMCwgVlNDU0lJRl9T
RU5TRV9CVUZGRVJTSVpFKTsKKwlycS0+c2Vuc2UgICAgICAgPSBwZW5kaW5nX3JlcS0+c2Vuc2Vf
YnVmZmVyOworCXJxLT5zZW5zZV9sZW4gPSAwOworCisJLyogbm90IGFsbG93ZWQgdG8gcmV0cnkg
aW4gYmFja2VuZC4gICAgICAgICAgICAgICAgICAgKi8KKwlycS0+cmV0cmllcyAgID0gMDsKKwly
cS0+dGltZW91dCAgID0gdGltZW91dDsKKwlycS0+ZW5kX2lvX2RhdGEgPSBwZW5kaW5nX3JlcTsK
KworCXNjc2liYWNrX2dldChwZW5kaW5nX3JlcS0+aW5mbyk7CisJYmxrX2V4ZWN1dGVfcnFfbm93
YWl0KHJxLT5xLCBOVUxMLCBycSwgMSwgc2NzaWJhY2tfY21kX2RvbmUpOworCisJcmV0dXJuIDsK
K30KKworCitzdGF0aWMgdm9pZCBzY3NpYmFja19kZXZpY2VfcmVzZXRfZXhlYyhwZW5kaW5nX3Jl
cV90ICpwZW5kaW5nX3JlcSkKK3sKKwlzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvID0gcGVuZGlu
Z19yZXEtPmluZm87CisJaW50IGVycjsKKwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXYgPSBwZW5k
aW5nX3JlcS0+c2RldjsKKworCXNjc2liYWNrX2dldChpbmZvKTsKKwllcnIgPSBzY3NpX3Jlc2V0
X3Byb3ZpZGVyKHNkZXYsIFNDU0lfVFJZX1JFU0VUX0RFVklDRSk7CisKKwlzY3NpYmFja19kb19y
ZXNwX3dpdGhfc2Vuc2UoTlVMTCwgZXJyLCAwLCBwZW5kaW5nX3JlcSk7CisJc2NzaWJhY2tfcHV0
KGluZm8pOworCisJcmV0dXJuOworfQorCisKK2lycXJldHVybl90IHNjc2liYWNrX2ludHIoaW50
IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjc2liYWNrX25vdGlmeV93b3JrKChzdHJ1Y3QgdnNj
c2lia19pbmZvICopZGV2X2lkKTsKKwlyZXR1cm4gSVJRX0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBp
bnQgcHJlcGFyZV9wZW5kaW5nX3JlcXMoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbywKKwkJdnNj
c2lpZl9yZXF1ZXN0X3QgKnJpbmdfcmVxLCBwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcSkKK3sK
KwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXY7CisJc3RydWN0IGlkc190dXBsZSB2aXI7CisJaW50
IGVyciA9IC1FSU5WQUw7CisKKwlEUFJJTlRLKCIlc1xuIixfX0ZVTkNUSU9OX18pOworCisJcGVu
ZGluZ19yZXEtPnJxaWQgICAgICAgPSByaW5nX3JlcS0+cnFpZDsKKwlwZW5kaW5nX3JlcS0+YWN0
ICAgICAgICA9IHJpbmdfcmVxLT5hY3Q7CisKKwlwZW5kaW5nX3JlcS0+aW5mbyAgICAgICA9IGlu
Zm87CisKKwlwZW5kaW5nX3JlcS0+dl9jaG4gPSB2aXIuY2huID0gcmluZ19yZXEtPmNoYW5uZWw7
CisJcGVuZGluZ19yZXEtPnZfdGd0ID0gdmlyLnRndCA9IHJpbmdfcmVxLT5pZDsKKwl2aXIubHVu
ID0gcmluZ19yZXEtPmx1bjsKKworCXJtYigpOworCXNkZXYgPSBzY3NpYmFja19kb190cmFuc2xh
dGlvbihpbmZvLCAmdmlyKTsKKwlpZiAoIXNkZXYpIHsKKwkJcGVuZGluZ19yZXEtPnNkZXYgPSBO
VUxMOworCQlEUFJJTlRLKCJzY3NpYmFjazogZG9lc24ndCBleGlzdC5cbiIpOworCQllcnIgPSAt
RU5PREVWOworCQlnb3RvIGludmFsaWRfdmFsdWU7CisJfQorCXBlbmRpbmdfcmVxLT5zZGV2ID0g
c2RldjsKKworCS8qIHJlcXVlc3QgcmFuZ2UgY2hlY2sgZnJvbSBmcm9udGVuZCAqLworCXBlbmRp
bmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiA9IHJpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbjsK
KwliYXJyaWVyKCk7CisJaWYgKChwZW5kaW5nX3JlcS0+c2NfZGF0YV9kaXJlY3Rpb24gIT0gRE1B
X0JJRElSRUNUSU9OQUwpICYmCisJCShwZW5kaW5nX3JlcS0+c2NfZGF0YV9kaXJlY3Rpb24gIT0g
RE1BX1RPX0RFVklDRSkgJiYKKwkJKHBlbmRpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiAhPSBE
TUFfRlJPTV9ERVZJQ0UpICYmCisJCShwZW5kaW5nX3JlcS0+c2NfZGF0YV9kaXJlY3Rpb24gIT0g
RE1BX05PTkUpKSB7CisJCURQUklOVEsoInNjc2liYWNrOiBpbnZhbGlkIHBhcmFtZXRlciBkYXRh
X2RpciA9ICVkXG4iLAorCQkJcGVuZGluZ19yZXEtPnNjX2RhdGFfZGlyZWN0aW9uKTsKKwkJZXJy
ID0gLUVJTlZBTDsKKwkJZ290byBpbnZhbGlkX3ZhbHVlOworCX0KKworCXBlbmRpbmdfcmVxLT5u
cl9zZWdtZW50cyA9IHJpbmdfcmVxLT5ucl9zZWdtZW50czsKKwliYXJyaWVyKCk7CisJaWYgKHBl
bmRpbmdfcmVxLT5ucl9zZWdtZW50cyA+IFZTQ1NJSUZfU0dfVEFCTEVTSVpFKSB7CisJCURQUklO
VEsoInNjc2liYWNrOiBpbnZhbGlkIHBhcmFtZXRlciBucl9zZWcgPSAlZFxuIiwKKwkJCXBlbmRp
bmdfcmVxLT5ucl9zZWdtZW50cyk7CisJCWVyciA9IC1FSU5WQUw7CisJCWdvdG8gaW52YWxpZF92
YWx1ZTsKKwl9CisKKwlwZW5kaW5nX3JlcS0+Y21kX2xlbiA9IHJpbmdfcmVxLT5jbWRfbGVuOwor
CWJhcnJpZXIoKTsKKwlpZiAocGVuZGluZ19yZXEtPmNtZF9sZW4gPiBWU0NTSUlGX01BWF9DT01N
QU5EX1NJWkUpIHsKKwkJRFBSSU5USygic2NzaWJhY2s6IGludmFsaWQgcGFyYW1ldGVyIGNtZF9s
ZW4gPSAlZFxuIiwKKwkJCXBlbmRpbmdfcmVxLT5jbWRfbGVuKTsKKwkJZXJyID0gLUVJTlZBTDsK
KwkJZ290byBpbnZhbGlkX3ZhbHVlOworCX0KKwltZW1jcHkocGVuZGluZ19yZXEtPmNtbmQsIHJp
bmdfcmVxLT5jbW5kLCBwZW5kaW5nX3JlcS0+Y21kX2xlbik7CisKKwlwZW5kaW5nX3JlcS0+dGlt
ZW91dF9wZXJfY29tbWFuZCA9IHJpbmdfcmVxLT50aW1lb3V0X3Blcl9jb21tYW5kOworCisJaWYo
c2NzaWJhY2tfZ250dGFiX2RhdGFfbWFwKHJpbmdfcmVxLCBwZW5kaW5nX3JlcSkpIHsKKwkJRFBS
SU5USygic2NzaWJhY2s6IGludmFsaWQgYnVmZmVyXG4iKTsKKwkJZXJyID0gLUVJTlZBTDsKKwkJ
Z290byBpbnZhbGlkX3ZhbHVlOworCX0KKworCXJldHVybiAwOworCitpbnZhbGlkX3ZhbHVlOgor
CXJldHVybiBlcnI7Cit9CisKKworc3RhdGljIGludCBzY3NpYmFja19kb19jbWRfZm4oc3RydWN0
IHZzY3NpYmtfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgdnNjc2lpZl9iYWNrX3JpbmcgKnJpbmcg
PSAmaW5mby0+cmluZzsKKwl2c2NzaWlmX3JlcXVlc3RfdCAgKnJpbmdfcmVxOworCisJcGVuZGlu
Z19yZXFfdCAqcGVuZGluZ19yZXE7CisJUklOR19JRFggcmMsIHJwOworCWludCBlcnIsIG1vcmVf
dG9fZG8gPSAwOworCisJRFBSSU5USygiJXNcbiIsX19GVU5DVElPTl9fKTsKKworCXJjID0gcmlu
Zy0+cmVxX2NvbnM7CisJcnAgPSByaW5nLT5zcmluZy0+cmVxX3Byb2Q7CisJcm1iKCk7CisKKwl3
aGlsZSAoKHJjICE9IHJwKSkgeworCQlpZiAoUklOR19SRVFVRVNUX0NPTlNfT1ZFUkZMT1cocmlu
ZywgcmMpKQorCQkJYnJlYWs7CisJCXBlbmRpbmdfcmVxID0gYWxsb2NfcmVxKGluZm8pOworCQlp
ZiAoTlVMTCA9PSBwZW5kaW5nX3JlcSkgeworCQkJbW9yZV90b19kbyA9IDE7CisJCQlicmVhazsK
KwkJfQorCisJCXJpbmdfcmVxID0gUklOR19HRVRfUkVRVUVTVChyaW5nLCByYyk7CisJCXJpbmct
PnJlcV9jb25zID0gKytyYzsKKworCQllcnIgPSBwcmVwYXJlX3BlbmRpbmdfcmVxcyhpbmZvLCBy
aW5nX3JlcSwKKwkJCQkJCXBlbmRpbmdfcmVxKTsKKwkJaWYgKGVyciA9PSAtRUlOVkFMKSB7CisJ
CQlzY3NpYmFja19kb19yZXNwX3dpdGhfc2Vuc2UoTlVMTCwgKERSSVZFUl9FUlJPUiA8PCAyNCks
CisJCQkJMCwgcGVuZGluZ19yZXEpOworCQkJY29udGludWU7CisJCX0gZWxzZSBpZiAoZXJyID09
IC1FTk9ERVYpIHsKKwkJCXNjc2liYWNrX2RvX3Jlc3Bfd2l0aF9zZW5zZShOVUxMLCAoRElEX05P
X0NPTk5FQ1QgPDwgMTYpLAorCQkJCTAsIHBlbmRpbmdfcmVxKTsKKwkJCWNvbnRpbnVlOworCQl9
CisKKwkJaWYgKHBlbmRpbmdfcmVxLT5hY3QgPT0gVlNDU0lJRl9BQ1RfU0NTSV9DREIpIHsKKwor
CQkJLyogVGhlIEhvc3QgbW9kZSBpcyB0aHJvdWdoIGFzIGZvciBFbXVsYXRpb24uICovCisJCQlp
ZiAoaW5mby0+ZmVhdHVyZSA9PSBWU0NTSV9UWVBFX0hPU1QpCisJCQkJc2NzaWJhY2tfY21kX2V4
ZWMocGVuZGluZ19yZXEpOworCQkJZWxzZQorCQkJCXNjc2liYWNrX3JlcV9lbXVsYXRpb25fb3Jf
Y21kZXhlYyhwZW5kaW5nX3JlcSk7CisKKwkJfSBlbHNlIGlmIChwZW5kaW5nX3JlcS0+YWN0ID09
IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQpIHsKKwkJCXNjc2liYWNrX2RldmljZV9yZXNldF9leGVj
KHBlbmRpbmdfcmVxKTsKKwkJfSBlbHNlIHsKKwkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6
IGludmFsaWQgcGFyYW1ldGVyIGZvciByZXF1ZXN0XG4iKTsKKwkJCXNjc2liYWNrX2RvX3Jlc3Bf
d2l0aF9zZW5zZShOVUxMLCAoRFJJVkVSX0VSUk9SIDw8IDI0KSwKKwkJCQkwLCBwZW5kaW5nX3Jl
cSk7CisJCQljb250aW51ZTsKKwkJfQorCX0KKworCWlmIChSSU5HX0hBU19VTkNPTlNVTUVEX1JF
UVVFU1RTKHJpbmcpKQorCQltb3JlX3RvX2RvID0gMTsKKworCS8qIFlpZWxkIHBvaW50IGZvciB0
aGlzIHVuYm91bmRlZCBsb29wLiAqLworCWNvbmRfcmVzY2hlZCgpOworCisJcmV0dXJuIG1vcmVf
dG9fZG87Cit9CisKKworaW50IHNjc2liYWNrX3NjaGVkdWxlKHZvaWQgKmRhdGEpCit7CisJc3Ry
dWN0IHZzY3NpYmtfaW5mbyAqaW5mbyA9IChzdHJ1Y3QgdnNjc2lia19pbmZvICopZGF0YTsKKwor
CURQUklOVEsoIiVzXG4iLF9fRlVOQ1RJT05fXyk7CisKKwl3aGlsZSAoIWt0aHJlYWRfc2hvdWxk
X3N0b3AoKSkgeworCQl3YWl0X2V2ZW50X2ludGVycnVwdGlibGUoCisJCQlpbmZvLT53cSwKKwkJ
CWluZm8tPndhaXRpbmdfcmVxcyB8fCBrdGhyZWFkX3Nob3VsZF9zdG9wKCkpOworCQl3YWl0X2V2
ZW50X2ludGVycnVwdGlibGUoCisJCQlwZW5kaW5nX2ZyZWVfd3EsCisJCQkhbGlzdF9lbXB0eSgm
cGVuZGluZ19mcmVlKSB8fCBrdGhyZWFkX3Nob3VsZF9zdG9wKCkpOworCisJCWluZm8tPndhaXRp
bmdfcmVxcyA9IDA7CisJCXNtcF9tYigpOworCisJCWlmIChzY3NpYmFja19kb19jbWRfZm4oaW5m
bykpCisJCQlpbmZvLT53YWl0aW5nX3JlcXMgPSAxOworCX0KKworCXJldHVybiAwOworfQorCisK
K3N0YXRpYyBpbnQgX19pbml0IHNjc2liYWNrX2luaXQodm9pZCkKK3sKKwlpbnQgaSwgbW1hcF9w
YWdlczsKKworCWlmICgheGVuX2RvbWFpbigpKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCW1tYXBf
cGFnZXMgPSB2c2NzaWlmX3JlcXMgKiBWU0NTSUlGX1NHX1RBQkxFU0laRTsKKworCXBlbmRpbmdf
cmVxcyAgICAgICAgICA9IGt6YWxsb2Moc2l6ZW9mKHBlbmRpbmdfcmVxc1swXSkgKgorCQkJCQl2
c2NzaWlmX3JlcXMsIEdGUF9LRVJORUwpOworCXBlbmRpbmdfZ3JhbnRfaGFuZGxlcyA9IGttYWxs
b2Moc2l6ZW9mKHBlbmRpbmdfZ3JhbnRfaGFuZGxlc1swXSkgKgorCQkJCQltbWFwX3BhZ2VzLCBH
RlBfS0VSTkVMKTsKKwlwZW5kaW5nX3BhZ2VzICAgICAgICAgPSBremFsbG9jKHNpemVvZihwZW5k
aW5nX3BhZ2VzWzBdKSAqCisJCQkJCW1tYXBfcGFnZXMsIEdGUF9LRVJORUwpOworCisJaWYgKCFw
ZW5kaW5nX3JlcXMgfHwgIXBlbmRpbmdfZ3JhbnRfaGFuZGxlcyB8fCAhcGVuZGluZ19wYWdlcykK
KwkJZ290byBvdXRfb2ZfbWVtb3J5OworCisJZm9yIChpID0gMDsgaSA8IG1tYXBfcGFnZXM7IGkr
KykgeworCQlwZW5kaW5nX2dyYW50X2hhbmRsZXNbaV0gPSBTQ1NJQkFDS19JTlZBTElEX0hBTkRM
RTsKKwkJcGVuZGluZ19wYWdlc1tpXSA9IGFsbG9jX3BhZ2UoR0ZQX0tFUk5FTCk7CisJCWlmIChw
ZW5kaW5nX3BhZ2VzW2ldID09IE5VTEwpCisJCQlnb3RvIG91dF9vZl9tZW1vcnk7CisJfQorCWlm
IChzY3NpYmFja19pbnRlcmZhY2VfaW5pdCgpIDwgMCkKKwkJZ290byBvdXRfb2Zfa21lbTsKKwor
CW1lbXNldChwZW5kaW5nX3JlcXMsIDAsIHNpemVvZihwZW5kaW5nX3JlcXMpKTsKKwlJTklUX0xJ
U1RfSEVBRCgmcGVuZGluZ19mcmVlKTsKKworCWZvciAoaSA9IDA7IGkgPCB2c2NzaWlmX3JlcXM7
IGkrKykKKwkJbGlzdF9hZGRfdGFpbCgmcGVuZGluZ19yZXFzW2ldLmZyZWVfbGlzdCwgJnBlbmRp
bmdfZnJlZSk7CisKKwlpZiAoc2NzaWJhY2tfeGVuYnVzX2luaXQoKSkKKwkJZ290byBvdXRfb2Zf
eGVuYnVzOworCisJc2NzaWJhY2tfZW11bGF0aW9uX2luaXQoKTsKKworCXJldHVybiAwOworCitv
dXRfb2ZfeGVuYnVzOgorCXNjc2liYWNrX3hlbmJ1c191bnJlZ2lzdGVyKCk7CitvdXRfb2Zfa21l
bToKKwlzY3NpYmFja19pbnRlcmZhY2VfZXhpdCgpOworb3V0X29mX21lbW9yeToKKwlpZiAocGVu
ZGluZ19wYWdlcykgeworCQlmb3IgKGkgPSAwOyBpIDwgbW1hcF9wYWdlczsgaSsrKSB7CisJCQlp
ZiAocGVuZGluZ19wYWdlc1tpXSkKKwkJCQlfX2ZyZWVfcGFnZShwZW5kaW5nX3BhZ2VzW2ldKTsK
KwkJfQorCQlrZnJlZShwZW5kaW5nX3BhZ2VzKTsKKwl9CisJa2ZyZWUocGVuZGluZ19yZXFzKTsK
KwlrZnJlZShwZW5kaW5nX2dyYW50X2hhbmRsZXMpOworCXByaW50ayhLRVJOX0VSUiAic2NzaWJh
Y2s6ICVzOiBvdXQgb2YgbWVtb3J5XG4iLCBfX0ZVTkNUSU9OX18pOworCXJldHVybiAtRU5PTUVN
OworfQorCisKK3N0YXRpYyB2b2lkIF9fZXhpdCBzY3NpYmFja19leGl0KHZvaWQpCit7CisJc2Nz
aWJhY2tfeGVuYnVzX3VucmVnaXN0ZXIoKTsKKwlzY3NpYmFja19pbnRlcmZhY2VfZXhpdCgpOwor
CWtmcmVlKHBlbmRpbmdfcmVxcyk7CisJa2ZyZWUocGVuZGluZ19ncmFudF9oYW5kbGVzKTsKKwlp
ZiAocGVuZGluZ19wYWdlcykgeworCQl1bnNpZ25lZCBpbnQgaTsKKwkJdW5zaWduZWQgaW50IG1t
YXBfcGFnZXMgPSB2c2NzaWlmX3JlcXMgKiBWU0NTSUlGX1NHX1RBQkxFU0laRTsKKwkJZm9yIChp
ID0gMDsgaSA8IG1tYXBfcGFnZXM7IGkrKykgeworCQkJaWYgKHBlbmRpbmdfcGFnZXNbaV0pCisJ
CQkJX19mcmVlX3BhZ2UocGVuZGluZ19wYWdlc1tpXSk7CisJCX0KKwkJa2ZyZWUocGVuZGluZ19w
YWdlcyk7CisJfQorfQorCittb2R1bGVfaW5pdChzY3NpYmFja19pbml0KTsKK21vZHVsZV9leGl0
KHNjc2liYWNrX2V4aXQpOworCitNT0RVTEVfREVTQ1JJUFRJT04oIlhlbiBTQ1NJIGJhY2tlbmQg
ZHJpdmVyIik7CitNT0RVTEVfTElDRU5TRSgiRHVhbCBCU0QvR1BMIik7CmRpZmYgLXJ1cE4geGVu
L2RyaXZlcnMvc2NzaS94ZW4tc2NzaWJhY2svdHJhbnNsYXRlLmMgeGVuYy9kcml2ZXJzL3Njc2kv
eGVuLXNjc2liYWNrL3RyYW5zbGF0ZS5jCi0tLSB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFj
ay90cmFuc2xhdGUuYwkxOTY5LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVu
Yy9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3RyYW5zbGF0ZS5jCTIwMTItMDItMjQgMTQ6NTY6
MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsMTY4IEBACisvKgorICogWGVuIFNDU0kgYmFj
a2VuZCBkcml2ZXIKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZVSklUU1UgTGltaXRlZAor
ICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisgKiBzZXBhcmF0ZWx5
IGZyb20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBvdGhlcgorICogc29m
dHdhcmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNlbnNlOgorICoKKyAq
IFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVy
c29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUgKHRoZSAiU29mdHdh
cmUiKSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVzdHJpY3Rpb24sIGlu
Y2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlm
eSwKKyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3Igc2Vs
bCBjb3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdo
b20gdGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0bworICogdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNl
IGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwg
Y29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBU
SEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkg
S0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBU
TyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBB
UlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBU
SEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xB
SU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04g
T0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0Yg
T1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERF
QUxJTkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2xpc3Qu
aD4KKyNpbmNsdWRlIDxsaW51eC9nZnAuaD4KKworI2luY2x1ZGUgImNvbW1vbi5oIgorCisvKgor
ICBJbml0aWFsaXplIHRoZSB0cmFuc2xhdGlvbiBlbnRyeSBsaXN0CisqLwordm9pZCBzY3NpYmFj
a19pbml0X3RyYW5zbGF0aW9uX3RhYmxlKHN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm8pCit7CisJ
SU5JVF9MSVNUX0hFQUQoJmluZm8tPnYycF9lbnRyeV9saXN0cyk7CisJc3Bpbl9sb2NrX2luaXQo
JmluZm8tPnYycF9sb2NrKTsKK30KKworCisvKgorICBBZGQgYSBuZXcgdHJhbnNsYXRpb24gZW50
cnkKKyovCitpbnQgc2NzaWJhY2tfYWRkX3RyYW5zbGF0aW9uX2VudHJ5KHN0cnVjdCB2c2NzaWJr
X2luZm8gKmluZm8sCisJCQlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXYsIHN0cnVjdCBpZHNfdHVw
bGUgKnYpCit7CisJaW50IGVyciA9IDA7CisJc3RydWN0IHYycF9lbnRyeSAqZW50cnk7CisJc3Ry
dWN0IHYycF9lbnRyeSAqbmV3OworCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmKGluZm8tPnYy
cF9lbnRyeV9saXN0cyk7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19pcnFz
YXZlKCZpbmZvLT52MnBfbG9jaywgZmxhZ3MpOworCisJLyogQ2hlY2sgZG91YmxlIGFzc2lnbm1l
bnQgdG8gaWRlbnRpY2FsIHZpcnR1YWwgSUQgKi8KKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KGVudHJ5
LCBoZWFkLCBsKSB7CisJCWlmICgoZW50cnktPnYuY2huID09IHYtPmNobikgJiYKKwkJICAgIChl
bnRyeS0+di50Z3QgPT0gdi0+dGd0KSAmJgorCQkgICAgKGVudHJ5LT52Lmx1biA9PSB2LT5sdW4p
KSB7CisJCQlwcmludGsoS0VSTl9XQVJOSU5HICJzY3NpYmFjazogVmlydHVhbCBJRCBpcyBhbHJl
YWR5IHVzZWQuICIKKwkJCSAgICAgICAiQXNzaWdubWVudCB3YXMgbm90IHBlcmZvcm1lZC5cbiIp
OworCQkJZXJyID0gLUVFWElTVDsKKwkJCWdvdG8gb3V0OworCQl9CisKKwl9CisKKwkvKiBDcmVh
dGUgYSBuZXcgdHJhbnNsYXRpb24gZW50cnkgYW5kIGFkZCB0byB0aGUgbGlzdCAqLworCWlmICgo
bmV3ID0ga21hbGxvYyhzaXplb2Yoc3RydWN0IHYycF9lbnRyeSksIEdGUF9BVE9NSUMpKSA9PSBO
VUxMKSB7CisJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6ICVzOiBrbWFsbG9jKCkgZXJyb3Iu
XG4iLCBfX0ZVTkNUSU9OX18pOworCQllcnIgPSAtRU5PTUVNOworCQlnb3RvIG91dDsKKwl9CisJ
bmV3LT52ID0gKnY7CisJbmV3LT5zZGV2ID0gc2RldjsKKwlsaXN0X2FkZF90YWlsKCZuZXctPmws
IGhlYWQpOworCitvdXQ6CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+djJwX2xvY2ss
IGZsYWdzKTsKKwlyZXR1cm4gZXJyOworfQorCisKKy8qCisgIERlbGV0ZSB0aGUgdHJhbnNsYXRp
b24gZW50cnkgc3BlY2ZpZWQKKyovCitpbnQgc2NzaWJhY2tfZGVsX3RyYW5zbGF0aW9uX2VudHJ5
KHN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm8sCisJCQkJc3RydWN0IGlkc190dXBsZSAqdikKK3sK
KwlzdHJ1Y3QgdjJwX2VudHJ5ICplbnRyeTsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpoZWFkID0gJihp
bmZvLT52MnBfZW50cnlfbGlzdHMpOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisKKwlzcGluX2xv
Y2tfaXJxc2F2ZSgmaW5mby0+djJwX2xvY2ssIGZsYWdzKTsKKwkvKiBGaW5kIG91dCB0aGUgdHJh
bnNsYXRpb24gZW50cnkgc3BlY2lmaWVkICovCisJbGlzdF9mb3JfZWFjaF9lbnRyeShlbnRyeSwg
aGVhZCwgbCkgeworCQlpZiAoKGVudHJ5LT52LmNobiA9PSB2LT5jaG4pICYmCisJCSAgICAoZW50
cnktPnYudGd0ID09IHYtPnRndCkgJiYKKwkJICAgIChlbnRyeS0+di5sdW4gPT0gdi0+bHVuKSkg
eworCQkJZ290byBmb3VuZDsKKwkJfQorCX0KKworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmlu
Zm8tPnYycF9sb2NrLCBmbGFncyk7CisJcmV0dXJuIDE7CisKK2ZvdW5kOgorCS8qIERlbGV0ZSB0
aGUgdHJhbnNsYXRpb24gZW50cnkgc3BlY2ZpZWQgKi8KKwlzY3NpX2RldmljZV9wdXQoZW50cnkt
PnNkZXYpOworCWxpc3RfZGVsKCZlbnRyeS0+bCk7CisJa2ZyZWUoZW50cnkpOworCisJc3Bpbl91
bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+djJwX2xvY2ssIGZsYWdzKTsKKwlyZXR1cm4gMDsKK30K
KworCisvKgorICBQZXJmb3JtIHZpcnR1YWwgdG8gcGh5c2ljYWwgdHJhbnNsYXRpb24KKyovCitz
dHJ1Y3Qgc2NzaV9kZXZpY2UgKnNjc2liYWNrX2RvX3RyYW5zbGF0aW9uKHN0cnVjdCB2c2NzaWJr
X2luZm8gKmluZm8sCisJCQlzdHJ1Y3QgaWRzX3R1cGxlICp2KQoreworCXN0cnVjdCB2MnBfZW50
cnkgKmVudHJ5OworCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmKGluZm8tPnYycF9lbnRyeV9s
aXN0cyk7CisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2ID0gTlVMTDsKKwl1bnNpZ25lZCBsb25n
IGZsYWdzOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmluZm8tPnYycF9sb2NrLCBmbGFncyk7CisJ
bGlzdF9mb3JfZWFjaF9lbnRyeShlbnRyeSwgaGVhZCwgbCkgeworCQlpZiAoKGVudHJ5LT52LmNo
biA9PSB2LT5jaG4pICYmCisJCSAgICAoZW50cnktPnYudGd0ID09IHYtPnRndCkgJiYKKwkJICAg
IChlbnRyeS0+di5sdW4gPT0gdi0+bHVuKSkgeworCQkJc2RldiA9IGVudHJ5LT5zZGV2OworCQkJ
Z290byBvdXQ7CisJCX0KKwl9CitvdXQ6CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+
djJwX2xvY2ssIGZsYWdzKTsKKwlyZXR1cm4gc2RldjsKK30KKworCisvKgorICBSZWxlYXNlIHRo
ZSB0cmFuc2xhdGlvbiBlbnRyeSBzcGVjZmllZAorKi8KK3ZvaWQgc2NzaWJhY2tfcmVsZWFzZV90
cmFuc2xhdGlvbl9lbnRyeShzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvKQoreworCXN0cnVjdCB2
MnBfZW50cnkgKmVudHJ5LCAqdG1wOworCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmKGluZm8t
PnYycF9lbnRyeV9saXN0cyk7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19p
cnFzYXZlKCZpbmZvLT52MnBfbG9jaywgZmxhZ3MpOworCWxpc3RfZm9yX2VhY2hfZW50cnlfc2Fm
ZShlbnRyeSwgdG1wLCBoZWFkLCBsKSB7CisJCXNjc2lfZGV2aWNlX3B1dChlbnRyeS0+c2Rldik7
CisJCWxpc3RfZGVsKCZlbnRyeS0+bCk7CisJCWtmcmVlKGVudHJ5KTsKKwl9CisKKwlzcGluX3Vu
bG9ja19pcnFyZXN0b3JlKCZpbmZvLT52MnBfbG9jaywgZmxhZ3MpOworCXJldHVybjsKKworfQpk
aWZmIC1ydXBOIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3hlbmJ1cy5jIHhlbmMvZHJp
dmVycy9zY3NpL3hlbi1zY3NpYmFjay94ZW5idXMuYwotLS0geGVuL2RyaXZlcnMvc2NzaS94ZW4t
c2NzaWJhY2sveGVuYnVzLmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3MDAKKysr
IHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFjay94ZW5idXMuYwkyMDEyLTAyLTI0IDE0OjU2
OjEzLjUzODk3ODMwMCAtMDcwMApAQCAtMCwwICsxLDM3MSBAQAorLyoKKyAqIFhlbiBTQ1NJIGJh
Y2tlbmQgZHJpdmVyCisgKgorICogQ29weXJpZ2h0IChjKSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQK
KyAqCisgKiBCYXNlZCBvbiB0aGUgYmxrYmFjayBkcml2ZXIgY29kZS4KKyAqCisgKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisg
KiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSB2ZXJzaW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uOyBvciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51
eCBrZXJuZWwgb3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2Vz
LCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlz
IGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcg
YSBjb3B5CisgKiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwg
aW4gdGhlIFNvZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91
dCBsaW1pdGF0aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwg
cHVibGlzaCwgZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRo
ZSBTb2Z0d2FyZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2Fy
ZSBpcyBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29u
ZGl0aW9uczoKKyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJt
aXNzaW9uIG5vdGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJz
dGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElT
IFBST1ZJREVEICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1Mg
T1IKKyAqIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UgQU5EIE5PTklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JT
IE9SIENPUFlSSUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9S
IE9USEVSCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBU
T1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJ
T04gV0lUSCBUSEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4g
VEhFIFNPRlRXQVJFLgorICovCisKKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxsaW51
eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9rdGhyZWFkLmg+CisjaW5jbHVkZSA8c2NzaS9z
Y3NpLmg+CisjaW5jbHVkZSA8c2NzaS9zY3NpX2hvc3QuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lf
ZGV2aWNlLmg+CisKKyNpbmNsdWRlICJjb21tb24uaCIKKworc3RydWN0IGJhY2tlbmRfaW5mbwor
eworCXN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXY7CisJc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5m
bzsKK307CisKKworc3RhdGljIGludCBfX3ZzY3NpaWZfbmFtZShzdHJ1Y3QgYmFja2VuZF9pbmZv
ICpiZSwgY2hhciAqYnVmKQoreworCXN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYgPSBiZS0+ZGV2
OworCXVuc2lnbmVkIGludCBkb21pZCwgaWQ7CisKKwlzc2NhbmYoZGV2LT5ub2RlbmFtZSwgImJh
Y2tlbmQvdnNjc2kvJXUvJXUiLCAmZG9taWQsICZpZCk7CisJc25wcmludGYoYnVmLCBUQVNLX0NP
TU1fTEVOLCAidnNjc2kuJXUuJXUiLCBiZS0+aW5mby0+ZG9taWQsIGlkKTsKKworCXJldHVybiAw
OworfQorCitzdGF0aWMgaW50IHNjc2liYWNrX21hcChzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSkK
K3sKKwlzdHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2ID0gYmUtPmRldjsKKwl1bnNpZ25lZCBsb25n
IHJpbmdfcmVmID0gMDsKKwl1bnNpZ25lZCBpbnQgZXZ0Y2huID0gMDsKKwlpbnQgZXJyOworCWNo
YXIgbmFtZVtUQVNLX0NPTU1fTEVOXTsKKworCWVyciA9IHhlbmJ1c19nYXRoZXIoWEJUX05JTCwg
ZGV2LT5vdGhlcmVuZCwKKwkJCSJyaW5nLXJlZiIsICIlbHUiLCAmcmluZ19yZWYsCisJCQkiZXZl
bnQtY2hhbm5lbCIsICIldSIsICZldnRjaG4sIE5VTEwpOworCWlmIChlcnIpIHsKKwkJeGVuYnVz
X2Rldl9mYXRhbChkZXYsIGVyciwgInJlYWRpbmcgJXMgcmluZyIsIGRldi0+b3RoZXJlbmQpOwor
CQlyZXR1cm4gZXJyOworCX0KKwllcnIgPSBzY3NpYmFja19pbml0X3NyaW5nKGJlLT5pbmZvLCBy
aW5nX3JlZiwgZXZ0Y2huKTsKKwlpZiAoZXJyKQorCQlyZXR1cm4gZXJyOworCisJZXJyID0gX192
c2NzaWlmX25hbWUoYmUsIG5hbWUpOworCWlmIChlcnIpIHsKKwkJeGVuYnVzX2Rldl9lcnJvcihk
ZXYsIGVyciwgImdldCBzY3NpYmFjayBkZXYgbmFtZSIpOworCQlyZXR1cm4gZXJyOworCX0KKwor
CWJlLT5pbmZvLT5rdGhyZWFkID0ga3RocmVhZF9ydW4oc2NzaWJhY2tfc2NoZWR1bGUsIGJlLT5p
bmZvLCBuYW1lKTsKKwlpZiAoSVNfRVJSKGJlLT5pbmZvLT5rdGhyZWFkKSkgeworCQllcnIgPSBQ
VFJfRVJSKGJlLT5pbmZvLT5rdGhyZWFkKTsKKwkJYmUtPmluZm8tPmt0aHJlYWQgPSBOVUxMOwor
CQl4ZW5idXNfZGV2X2Vycm9yKGJlLT5kZXYsIGVyciwgInN0YXJ0IHZzY3NpaWYiKTsKKwkJcmV0
dXJuIGVycjsKKwl9CisKKwlyZXR1cm4gMDsKK30KKworCitzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNj
c2liYWNrX2dldF9zY3NpX2RldmljZShzdHJ1Y3QgaWRzX3R1cGxlICpwaHkpCit7CisJc3RydWN0
IFNjc2lfSG9zdCAqc2hvc3Q7CisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2ID0gTlVMTDsKKwor
CXNob3N0ID0gc2NzaV9ob3N0X2xvb2t1cChwaHktPmhzdCk7CisJaWYgKElTX0VSUihzaG9zdCkp
IHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogaG9zdCVkIGRvZXNuJ3QgZXhpc3QuXG4i
LAorCQkJcGh5LT5oc3QpOworCQlyZXR1cm4gTlVMTDsKKwl9CisJc2RldiAgID0gc2NzaV9kZXZp
Y2VfbG9va3VwKHNob3N0LCBwaHktPmNobiwgcGh5LT50Z3QsIHBoeS0+bHVuKTsKKwlpZiAoIXNk
ZXYpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogJWQ6JWQ6JWQ6JWQgZG9lc24ndCBl
eGlzdC5cbiIsCisJCQlwaHktPmhzdCwgcGh5LT5jaG4sIHBoeS0+dGd0LCBwaHktPmx1bik7CisJ
CXNjc2lfaG9zdF9wdXQoc2hvc3QpOworCQlyZXR1cm4gTlVMTDsKKwl9CisKKwlzY3NpX2hvc3Rf
cHV0KHNob3N0KTsKKwlyZXR1cm4gKHNkZXYpOworfQorCisjZGVmaW5lIFZTQ1NJQkFDS19PUF9B
RERfT1JfREVMX0xVTgkxCisjZGVmaW5lIFZTQ1NJQkFDS19PUF9VUERBVEVERVZfU1RBVEUJMgor
CisKK3N0YXRpYyB2b2lkIHNjc2liYWNrX2RvX2x1bl9ob3RwbHVnKHN0cnVjdCBiYWNrZW5kX2lu
Zm8gKmJlLCBpbnQgb3ApCit7CisJaW50IGksIGVyciA9IDA7CisJc3RydWN0IGlkc190dXBsZSBw
aHksIHZpcjsKKwlpbnQgZGV2aWNlX3N0YXRlOworCWNoYXIgc3RyWzY0XSwgc3RhdGVfc3RyWzY0
XTsKKwljaGFyICoqZGlyOworCXVuc2lnbmVkIGludCBkaXJfbiA9IDA7CisJc3RydWN0IHhlbmJ1
c19kZXZpY2UgKmRldiA9IGJlLT5kZXY7CisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2OworCisJ
ZGlyID0geGVuYnVzX2RpcmVjdG9yeShYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCAidnNjc2ktZGV2
cyIsICZkaXJfbik7CisJaWYgKElTX0VSUihkaXIpKQorCQlyZXR1cm47CisKKwlmb3IgKGkgPSAw
OyBpIDwgZGlyX247IGkrKykgeworCQkvKiByZWFkIHN0YXR1cyAqLworCQlzbnByaW50ZihzdGF0
ZV9zdHIsIHNpemVvZihzdGF0ZV9zdHIpLCAidnNjc2ktZGV2cy8lcy9zdGF0ZSIsIGRpcltpXSk7
CisJCWVyciA9IHhlbmJ1c19zY2FuZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCBzdGF0ZV9zdHIs
ICIldSIsCisJCQkmZGV2aWNlX3N0YXRlKTsKKwkJaWYgKFhFTkJVU19FWElTVF9FUlIoZXJyKSkK
KwkJCWNvbnRpbnVlOworCisJCS8qIHBoeXNpY2FsIFNDU0kgZGV2aWNlICovCisJCXNucHJpbnRm
KHN0ciwgc2l6ZW9mKHN0ciksICJ2c2NzaS1kZXZzLyVzL3AtZGV2IiwgZGlyW2ldKTsKKwkJZXJy
ID0geGVuYnVzX3NjYW5mKFhCVF9OSUwsIGRldi0+bm9kZW5hbWUsIHN0ciwKKwkJCSIldToldTol
dToldSIsICZwaHkuaHN0LCAmcGh5LmNobiwgJnBoeS50Z3QsICZwaHkubHVuKTsKKwkJaWYgKFhF
TkJVU19FWElTVF9FUlIoZXJyKSkgeworCQkJeGVuYnVzX3ByaW50ZihYQlRfTklMLCBkZXYtPm5v
ZGVuYW1lLCBzdGF0ZV9zdHIsCisJCQkJCSIlZCIsIFhlbmJ1c1N0YXRlQ2xvc2VkKTsKKwkJCWNv
bnRpbnVlOworCQl9CisKKwkJLyogdmlydHVhbCBTQ1NJIGRldmljZSAqLworCQlzbnByaW50Zihz
dHIsIHNpemVvZihzdHIpLCAidnNjc2ktZGV2cy8lcy92LWRldiIsIGRpcltpXSk7CisJCWVyciA9
IHhlbmJ1c19zY2FuZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCBzdHIsCisJCQkiJXU6JXU6JXU6
JXUiLCAmdmlyLmhzdCwgJnZpci5jaG4sICZ2aXIudGd0LCAmdmlyLmx1bik7CisJCWlmIChYRU5C
VVNfRVhJU1RfRVJSKGVycikpIHsKKwkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2Rl
bmFtZSwgc3RhdGVfc3RyLAorCQkJCQkiJWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQljb250
aW51ZTsKKwkJfQorCisJCXN3aXRjaCAob3ApIHsKKwkJY2FzZSBWU0NTSUJBQ0tfT1BfQUREX09S
X0RFTF9MVU46CisJCQlpZiAoZGV2aWNlX3N0YXRlID09IFhlbmJ1c1N0YXRlSW5pdGlhbGlzaW5n
KSB7CisJCQkJc2RldiA9IHNjc2liYWNrX2dldF9zY3NpX2RldmljZSgmcGh5KTsKKwkJCQlpZiAo
IXNkZXYpCisJCQkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2RlbmFtZSwgc3RhdGVf
c3RyLAorCQkJCQkJCSAgICAiJWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQkJZWxzZSB7CisJ
CQkJCWVyciA9IHNjc2liYWNrX2FkZF90cmFuc2xhdGlvbl9lbnRyeShiZS0+aW5mbywgc2Rldiwg
JnZpcik7CisJCQkJCWlmICghZXJyKSB7CisJCQkJCQlpZiAoeGVuYnVzX3ByaW50ZihYQlRfTklM
LCBkZXYtPm5vZGVuYW1lLCBzdGF0ZV9zdHIsCisJCQkJCQkJCSAgICAiJWQiLCBYZW5idXNTdGF0
ZUluaXRpYWxpc2VkKSkgeworCQkJCQkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6IHhlbmJ1
c19wcmludGYgZXJyb3IgJXNcbiIsIHN0YXRlX3N0cik7CisJCQkJCQkJc2NzaWJhY2tfZGVsX3Ry
YW5zbGF0aW9uX2VudHJ5KGJlLT5pbmZvLCAmdmlyKTsKKwkJCQkJCX0KKwkJCQkJfSBlbHNlIHsK
KwkJCQkJCXNjc2lfZGV2aWNlX3B1dChzZGV2KTsKKwkJCQkJCXhlbmJ1c19wcmludGYoWEJUX05J
TCwgZGV2LT5ub2RlbmFtZSwgc3RhdGVfc3RyLAorCQkJCQkJCQkgICAgIiVkIiwgWGVuYnVzU3Rh
dGVDbG9zZWQpOworCQkJCQl9CisJCQkJfQorCQkJfQorCisJCQlpZiAoZGV2aWNlX3N0YXRlID09
IFhlbmJ1c1N0YXRlQ2xvc2luZykgeworCQkJCWlmICghc2NzaWJhY2tfZGVsX3RyYW5zbGF0aW9u
X2VudHJ5KGJlLT5pbmZvLCAmdmlyKSkgeworCQkJCQlpZiAoeGVuYnVzX3ByaW50ZihYQlRfTklM
LCBkZXYtPm5vZGVuYW1lLCBzdGF0ZV9zdHIsCisJCQkJCQkJICAgICIlZCIsIFhlbmJ1c1N0YXRl
Q2xvc2VkKSkKKwkJCQkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6IHhlbmJ1c19wcmludGYg
ZXJyb3IgJXNcbiIsIHN0YXRlX3N0cik7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisKKwkJY2Fz
ZSBWU0NTSUJBQ0tfT1BfVVBEQVRFREVWX1NUQVRFOgorCQkJaWYgKGRldmljZV9zdGF0ZSA9PSBY
ZW5idXNTdGF0ZUluaXRpYWxpc2VkKSB7CisJCQkJLyogbW9kaWZ5IHZzY3NpLWRldnMvZGV2LXgv
c3RhdGUgKi8KKwkJCQlpZiAoeGVuYnVzX3ByaW50ZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCBz
dGF0ZV9zdHIsCisJCQkJCQkgICAgIiVkIiwgWGVuYnVzU3RhdGVDb25uZWN0ZWQpKSB7CisJCQkJ
CXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6IHhlbmJ1c19wcmludGYgZXJyb3IgJXNcbiIsIHN0
YXRlX3N0cik7CisJCQkJCXNjc2liYWNrX2RlbF90cmFuc2xhdGlvbl9lbnRyeShiZS0+aW5mbywg
JnZpcik7CisJCQkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2RlbmFtZSwgc3RhdGVf
c3RyLAorCQkJCQkJCSAgICAiJWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQkJfQorCQkJfQor
CQkJYnJlYWs7CisJCS8qV2hlbiBpdCBpcyBuZWNlc3NhcnksIHByb2Nlc3NpbmcgaXMgYWRkZWQg
aGVyZS4qLworCQlkZWZhdWx0OgorCQkJYnJlYWs7CisJCX0KKwl9CisKKwlrZnJlZShkaXIpOwor
CXJldHVybiA7Cit9CisKKworc3RhdGljIHZvaWQgc2NzaWJhY2tfZnJvbnRlbmRfY2hhbmdlZChz
dHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2LAorCQkJCQllbnVtIHhlbmJ1c19zdGF0ZSBmcm9udGVu
ZF9zdGF0ZSkKK3sKKwlzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSA9IGRldl9nZXRfZHJ2ZGF0YSgm
ZGV2LT5kZXYpOworCWludCBlcnI7CisKKwlzd2l0Y2ggKGZyb250ZW5kX3N0YXRlKSB7CisJY2Fz
ZSBYZW5idXNTdGF0ZUluaXRpYWxpc2luZzoKKwkJYnJlYWs7CisJY2FzZSBYZW5idXNTdGF0ZUlu
aXRpYWxpc2VkOgorCQllcnIgPSBzY3NpYmFja19tYXAoYmUpOworCQlpZiAoZXJyKQorCQkJYnJl
YWs7CisKKwkJc2NzaWJhY2tfZG9fbHVuX2hvdHBsdWcoYmUsIFZTQ1NJQkFDS19PUF9BRERfT1Jf
REVMX0xVTik7CisJCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2LCBYZW5idXNTdGF0ZUNvbm5lY3Rl
ZCk7CisKKwkJYnJlYWs7CisJY2FzZSBYZW5idXNTdGF0ZUNvbm5lY3RlZDoKKworCQlzY3NpYmFj
a19kb19sdW5faG90cGx1ZyhiZSwgVlNDU0lCQUNLX09QX1VQREFURURFVl9TVEFURSk7CisKKwkJ
aWYgKGRldi0+c3RhdGUgPT0gWGVuYnVzU3RhdGVDb25uZWN0ZWQpCisJCQlicmVhazsKKworCQl4
ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVDb25uZWN0ZWQpOworCisJCWJyZWFr
OworCisJY2FzZSBYZW5idXNTdGF0ZUNsb3Npbmc6CisJCXNjc2liYWNrX2Rpc2Nvbm5lY3QoYmUt
PmluZm8pOworCQl4ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVDbG9zaW5nKTsK
KwkJYnJlYWs7CisKKwljYXNlIFhlbmJ1c1N0YXRlQ2xvc2VkOgorCQl4ZW5idXNfc3dpdGNoX3N0
YXRlKGRldiwgWGVuYnVzU3RhdGVDbG9zZWQpOworCQlpZiAoeGVuYnVzX2Rldl9pc19vbmxpbmUo
ZGV2KSkKKwkJCWJyZWFrOworCQkvKiBmYWxsIHRocm91Z2ggaWYgbm90IG9ubGluZSAqLworCWNh
c2UgWGVuYnVzU3RhdGVVbmtub3duOgorCQlkZXZpY2VfdW5yZWdpc3RlcigmZGV2LT5kZXYpOwor
CQlicmVhazsKKworCWNhc2UgWGVuYnVzU3RhdGVSZWNvbmZpZ3VyaW5nOgorCQlzY3NpYmFja19k
b19sdW5faG90cGx1ZyhiZSwgVlNDU0lCQUNLX09QX0FERF9PUl9ERUxfTFVOKTsKKworCQl4ZW5i
dXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVSZWNvbmZpZ3VyZWQpOworCisJCWJyZWFr
OworCisJZGVmYXVsdDoKKwkJeGVuYnVzX2Rldl9mYXRhbChkZXYsIC1FSU5WQUwsICJzYXcgc3Rh
dGUgJWQgYXQgZnJvbnRlbmQiLAorCQkJCQlmcm9udGVuZF9zdGF0ZSk7CisJCWJyZWFrOworCX0K
K30KKworCitzdGF0aWMgaW50IHNjc2liYWNrX3JlbW92ZShzdHJ1Y3QgeGVuYnVzX2RldmljZSAq
ZGV2KQoreworCXN0cnVjdCBiYWNrZW5kX2luZm8gKmJlID0gZGV2X2dldF9kcnZkYXRhKCZkZXYt
PmRldik7CisKKwlpZiAoYmUtPmluZm8pIHsKKwkJc2NzaWJhY2tfZGlzY29ubmVjdChiZS0+aW5m
byk7CisJCXNjc2liYWNrX3JlbGVhc2VfdHJhbnNsYXRpb25fZW50cnkoYmUtPmluZm8pOworCQlz
Y3NpYmFja19mcmVlKGJlLT5pbmZvKTsKKwkJYmUtPmluZm8gPSBOVUxMOworCX0KKworCWtmcmVl
KGJlKTsKKwlkZXZfc2V0X2RydmRhdGEoJmRldi0+ZGV2LCBOVUxMKTsKKworCXJldHVybiAwOwor
fQorCisKK3N0YXRpYyBpbnQgc2NzaWJhY2tfcHJvYmUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRl
diwKKwkJCSAgIGNvbnN0IHN0cnVjdCB4ZW5idXNfZGV2aWNlX2lkICppZCkKK3sKKwlpbnQgZXJy
OworCXVuc2lnbmVkIHZhbCA9IDA7CisKKwlzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSA9IGt6YWxs
b2Moc2l6ZW9mKHN0cnVjdCBiYWNrZW5kX2luZm8pLAorCQkJCQkgIEdGUF9LRVJORUwpOworCisJ
aWYgKCFiZSkgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgLUVOT01FTSwKKwkJCQkgImFsbG9j
YXRpbmcgYmFja2VuZCBzdHJ1Y3R1cmUiKTsKKwkJcmV0dXJuIC1FTk9NRU07CisJfQorCWJlLT5k
ZXYgPSBkZXY7CisJZGV2X3NldF9kcnZkYXRhKCZkZXYtPmRldiwgYmUpOworCisJYmUtPmluZm8g
PSB2c2NzaWJrX2luZm9fYWxsb2MoZGV2LT5vdGhlcmVuZF9pZCk7CisJaWYgKElTX0VSUihiZS0+
aW5mbykpIHsKKwkJZXJyID0gUFRSX0VSUihiZS0+aW5mbyk7CisJCWJlLT5pbmZvID0gTlVMTDsK
KwkJeGVuYnVzX2Rldl9mYXRhbChkZXYsIGVyciwgImNyZWF0aW5nIHNjc2lob3N0IGludGVyZmFj
ZSIpOworCQlnb3RvIGZhaWw7CisJfQorCisJYmUtPmluZm8tPmRldiA9IGRldjsKKwliZS0+aW5m
by0+aXJxID0gMDsKKwliZS0+aW5mby0+ZmVhdHVyZSA9IDA7CS8qZGVmYXVsdCBub3QgSE9TVE1P
REUuKi8KKworCXNjc2liYWNrX2luaXRfdHJhbnNsYXRpb25fdGFibGUoYmUtPmluZm8pOworCisJ
ZXJyID0geGVuYnVzX3NjYW5mKFhCVF9OSUwsIGRldi0+bm9kZW5hbWUsCisJCQkJImZlYXR1cmUt
aG9zdCIsICIlZCIsICZ2YWwpOworCWlmIChYRU5CVVNfRVhJU1RfRVJSKGVycikpCisJCXZhbCA9
IDA7CisKKwlpZiAodmFsKQorCQliZS0+aW5mby0+ZmVhdHVyZSA9IFZTQ1NJX1RZUEVfSE9TVDsK
KworCWVyciA9IHhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2LCBYZW5idXNTdGF0ZUluaXRXYWl0KTsK
KwlpZiAoZXJyKQorCQlnb3RvIGZhaWw7CisKKwlyZXR1cm4gMDsKKworCitmYWlsOgorCXByaW50
ayhLRVJOX1dBUk5JTkcgInNjc2liYWNrOiAlcyBmYWlsZWRcbiIsX19mdW5jX18pOworCXNjc2li
YWNrX3JlbW92ZShkZXYpOworCisJcmV0dXJuIGVycjsKK30KKworCitzdGF0aWMgY29uc3Qgc3Ry
dWN0IHhlbmJ1c19kZXZpY2VfaWQgc2NzaWJhY2tfaWRzW10gPSB7CisJeyAidnNjc2kiIH0sCisJ
eyAiIiB9Cit9OworCitzdGF0aWMgREVGSU5FX1hFTkJVU19EUklWRVIoc2NzaWJhY2ssICwKKwku
cHJvYmUJCQk9IHNjc2liYWNrX3Byb2JlLAorCS5yZW1vdmUJCQk9IHNjc2liYWNrX3JlbW92ZSwK
Kwkub3RoZXJlbmRfY2hhbmdlZAk9IHNjc2liYWNrX2Zyb250ZW5kX2NoYW5nZWQKKyk7CisKK2lu
dCBzY3NpYmFja194ZW5idXNfaW5pdCh2b2lkKQoreworCXJldHVybiB4ZW5idXNfcmVnaXN0ZXJf
YmFja2VuZCgmc2NzaWJhY2tfZHJpdmVyKTsKK30KKwordm9pZCBzY3NpYmFja194ZW5idXNfdW5y
ZWdpc3Rlcih2b2lkKQoreworCXhlbmJ1c191bnJlZ2lzdGVyX2RyaXZlcigmc2NzaWJhY2tfZHJp
dmVyKTsKK30KZGlmZiAtcnVwTiB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpZnJvbnQvTWFrZWZp
bGUgeGVuYy9kcml2ZXJzL3Njc2kveGVuLXNjc2lmcm9udC9NYWtlZmlsZQotLS0geGVuL2RyaXZl
cnMvc2NzaS94ZW4tc2NzaWZyb250L01ha2VmaWxlCTE5NjktMTItMzEgMTc6MDA6MDAuMDAwMDAw
MDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L01ha2VmaWxlCTIw
MTItMDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNCBAQAorCitvYmot
JChDT05GSUdfWEVOX1NDU0lfRlJPTlRFTkQpCTo9IHhlbi1zY3NpZnJvbnQubworeGVuLXNjc2lm
cm9udC1vYmpzIDo9IHNjc2lmcm9udC5vIHhlbmJ1cy5vCisKZGlmZiAtcnVwTiB4ZW4vZHJpdmVy
cy9zY3NpL3hlbi1zY3NpZnJvbnQvY29tbW9uLmggeGVuYy9kcml2ZXJzL3Njc2kveGVuLXNjc2lm
cm9udC9jb21tb24uaAotLS0geGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L2NvbW1vbi5o
CTE5NjktMTItMzEgMTc6MDA6MDAuMDAwMDAwMDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2Nz
aS94ZW4tc2NzaWZyb250L2NvbW1vbi5oCTIwMTItMDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0w
NzAwCkBAIC0wLDAgKzEsMTM3IEBACisvKgorICogWGVuIFNDU0kgZnJvbnRlbmQgZHJpdmVyCisg
KgorICogQ29weXJpZ2h0IChjKSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQKKyAqCisgKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisg
KiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSB2ZXJzaW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uOyBvciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51
eCBrZXJuZWwgb3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2Vz
LCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlz
IGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcg
YSBjb3B5CisgKiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwg
aW4gdGhlIFNvZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91
dCBsaW1pdGF0aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwg
cHVibGlzaCwgZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRo
ZSBTb2Z0d2FyZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2Fy
ZSBpcyBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29u
ZGl0aW9uczoKKyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJt
aXNzaW9uIG5vdGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJz
dGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElT
IFBST1ZJREVEICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1Mg
T1IKKyAqIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UgQU5EIE5PTklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JT
IE9SIENPUFlSSUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9S
IE9USEVSCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBU
T1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJ
T04gV0lUSCBUSEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4g
VEhFIFNPRlRXQVJFLgorICovCisKKyNpZm5kZWYgX19YRU5fRFJJVkVSU19TQ1NJRlJPTlRfSF9f
CisjZGVmaW5lIF9fWEVOX0RSSVZFUlNfU0NTSUZST05UX0hfXworCisjaW5jbHVkZSA8bGludXgv
dmVyc2lvbi5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgorI2luY2x1ZGUgPGxpbnV4L2tl
cm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L2RldmljZS5oPgorI2luY2x1ZGUgPGxpbnV4L2t0aHJl
YWQuaD4KKyNpbmNsdWRlIDxsaW51eC93YWl0Lmg+CisjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0
Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxsaW51eC9zY2hlZC5o
PgorI2luY2x1ZGUgPGxpbnV4L2Jsa2Rldi5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaV9jbW5kLmg+
CisjaW5jbHVkZSA8c2NzaS9zY3NpX2RldmljZS5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaS5oPgor
I2luY2x1ZGUgPHNjc2kvc2NzaV9ob3N0Lmg+CisjaW5jbHVkZSA8YXNtL3hlbi9wYWdlLmg+Cisj
aW5jbHVkZSA8eGVuL3hlbmJ1cy5oPgorI2luY2x1ZGUgPHhlbi9ncmFudF90YWJsZS5oPgorI2lu
Y2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vZXZ0Y2huLmg+CisjaW5jbHVkZSA8
eGVuL2ludGVyZmFjZS94ZW4uaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL2lvL3JpbmcuaD4K
KyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL2lvL3ZzY3NpaWYuaD4KKyNpbmNsdWRlIDx4ZW4vaW50
ZXJmYWNlL2dyYW50X3RhYmxlLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9pby9wcm90b2Nv
bHMuaD4KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4KKyNpbmNsdWRlIDxhc20vaHlwZXJ2aXNvci5o
PgorLyojaW5jbHVkZSA8YXNtL21hZGRyLmg+Ki8KKworI2lmZGVmIEhBVkVfWEVOX1BMQVRGT1JN
X0NPTVBBVF9ICisjaW5jbHVkZSA8eGVuL3BsYXRmb3JtLWNvbXBhdC5oPgorI2VuZGlmCisKKyNk
ZWZpbmUgR1JBTlRfSU5WQUxJRF9SRUYJMAorI2RlZmluZSBWU0NTSV9JTl9BQk9SVAkJMQorI2Rl
ZmluZSBWU0NTSV9JTl9SRVNFVAkJMgorCisvKiB0dW5pbmcgcG9pbnQqLworI2RlZmluZSBWU0NT
SUlGX0RFRkFVTFRfQ01EX1BFUl9MVU4gMTAKKyNkZWZpbmUgVlNDU0lJRl9NQVhfVEFSR0VUICAg
ICAgICAgIDY0CisjZGVmaW5lIFZTQ1NJSUZfTUFYX0xVTiAgICAgICAgICAgICAyNTUKKworI2Rl
ZmluZSBWU0NTSUlGX1JJTkdfU0laRQlfX0NPTlNUX1JJTkdfU0laRSh2c2NzaWlmLCBQQUdFX1NJ
WkUpCisjZGVmaW5lIFZTQ1NJSUZfTUFYX1JFUVMJVlNDU0lJRl9SSU5HX1NJWkUKKworc3RydWN0
IHZzY3NpZnJudF9zaGFkb3cgeworCXVpbnQxNl90IG5leHRfZnJlZTsKKworCS8qIGNvbW1hbmQg
YmV0d2VlbiBiYWNrZW5kIGFuZCBmcm9udGVuZAorCSAqIFZTQ1NJSUZfQUNUX1NDU0lfQ0RCIG9y
IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQgKi8KKwl1bnNpZ25lZCBjaGFyIGFjdDsKKworCS8qIGRv
IHJlc2V0IGZ1bmN0aW9uICovCisJd2FpdF9xdWV1ZV9oZWFkX3Qgd3FfcmVzZXQ7CS8qIHJlc2V0
IHdvcmsgcXVldWUgICAgICAgICAgICovCisJaW50IHdhaXRfcmVzZXQ7CQkJLyogcmVzZXQgd29y
ayBxdWV1ZSBjb25kaXRpb24gKi8KKwlpbnQzMl90IHJzbHRfcmVzZXQ7CQkvKiByZXNldCByZXNw
b25zZSBzdGF0dXMgICAgICAqLworCQkJCQkvKiAoU1VDRVNTIG9yIEZBSUxFRCkgICAgICAgICAq
LworCisJLyogZm9yIERNQV9UT19ERVZJQ0UoMSksIERNQV9GUk9NX0RFVklDRSgyKSwgRE1BX05P
TkUoMykKKwkgICByZXF1ZXN0cyAqLworCXVuc2lnbmVkIGludCBzY19kYXRhX2RpcmVjdGlvbjsK
KworCS8qIE51bWJlciBvZiBwaWVjZXMgb2Ygc2NhdHRlci1nYXRoZXIgKi8KKwl1bnNpZ25lZCBp
bnQgbnJfc2VnbWVudHM7CisKKwkvKiByZXF1ZXN0ZWQgc3RydWN0IHNjc2lfY21uZCBpcyBzdG9y
ZWQgZnJvbSBrZXJuZWwgKi8KKwl1bnNpZ25lZCBsb25nIHJlcV9zY3NpX2NtbmQ7CisJaW50IGdy
ZWZbVlNDU0lJRl9TR19UQUJMRVNJWkVdOworfTsKKworc3RydWN0IHZzY3NpZnJudF9pbmZvIHsK
KwlzdHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2OworCisJc3RydWN0IFNjc2lfSG9zdCAqaG9zdDsK
KworCXNwaW5sb2NrX3QgaW9fbG9jazsKKwlzcGlubG9ja190IHNoYWRvd19sb2NrOworCXVuc2ln
bmVkIGludCBldnRjaG47CisJdW5zaWduZWQgaW50IGlycTsKKworCWdyYW50X3JlZl90IHJpbmdf
cmVmOworCXN0cnVjdCB2c2NzaWlmX2Zyb250X3JpbmcgcmluZzsKKwlzdHJ1Y3QgdnNjc2lpZl9y
ZXNwb25zZQlyaW5nX3JlczsKKworCXN0cnVjdCB2c2NzaWZybnRfc2hhZG93IHNoYWRvd1tWU0NT
SUlGX01BWF9SRVFTXTsKKwl1aW50MzJfdCBzaGFkb3dfZnJlZTsKKworCXN0cnVjdCB0YXNrX3N0
cnVjdCAqa3RocmVhZDsKKwl3YWl0X3F1ZXVlX2hlYWRfdCB3cTsKKwl1bnNpZ25lZCBpbnQgd2Fp
dGluZ19yZXNwOworCit9OworCisjZGVmaW5lIERQUklOVEsoX2YsIF9hLi4uKQkJCQlcCisJcHJf
ZGVidWcoIihmaWxlPSVzLCBsaW5lPSVkKSAiIF9mLAlcCisJCSBfX0ZJTEVfXyAsIF9fTElORV9f
ICwgIyMgX2EgKQorCitpbnQgc2NzaWZyb250X3hlbmJ1c19pbml0KHZvaWQpOwordm9pZCBzY3Np
ZnJvbnRfeGVuYnVzX3VucmVnaXN0ZXIodm9pZCk7CitpbnQgc2NzaWZyb250X3NjaGVkdWxlKHZv
aWQgKmRhdGEpOworaXJxcmV0dXJuX3Qgc2NzaWZyb250X2ludHIoaW50IGlycSwgdm9pZCAqZGV2
X2lkKTsKK2ludCBzY3NpZnJvbnRfY21kX2RvbmUoc3RydWN0IHZzY3NpZnJudF9pbmZvICppbmZv
KTsKKworCisjZW5kaWYgLyogX19YRU5fRFJJVkVSU19TQ1NJRlJPTlRfSF9fICAqLwpkaWZmIC1y
dXBOIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2lmcm9udC9zY3NpZnJvbnQuYyB4ZW5jL2RyaXZl
cnMvc2NzaS94ZW4tc2NzaWZyb250L3Njc2lmcm9udC5jCi0tLSB4ZW4vZHJpdmVycy9zY3NpL3hl
bi1zY3NpZnJvbnQvc2NzaWZyb250LmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3
MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpZnJvbnQvc2NzaWZyb250LmMJMjAxMi0w
Mi0yNCAxNDo1NjoxMy41Mzg5NzgzMDAgLTA3MDAKQEAgLTAsMCArMSw0NjkgQEAKKy8qCisgKiBY
ZW4gU0NTSSBmcm9udGVuZCBkcml2ZXIKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZVSklU
U1UgTGltaXRlZAorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVk
IGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisg
KiBzZXBhcmF0ZWx5IGZyb20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBv
dGhlcgorICogc29mdHdhcmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNl
bnNlOgorICoKKyAqIFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdl
LCB0byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUg
KHRoZSAiU29mdHdhcmUiKSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVz
dHJpY3Rpb24sIGluY2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2Us
IGNvcHksIG1vZGlmeSwKKyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNl
LCBhbmQvb3Igc2VsbCBjb3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBw
ZXJzb25zIHRvIHdob20gdGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVj
dCB0bworICogdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5
cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVk
IGluCisgKiBhbGwgY29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2Fy
ZS4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJS
QU5UWSBPRiBBTlkgS0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBO
T1QgTElNSVRFRCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBF
VkVOVCBTSEFMTCBUSEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxF
IEZPUiBBTlkgQ0xBSU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJ
TiBBTiBBQ1RJT04gT0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBG
Uk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNF
IE9SIE9USEVSIERFQUxJTkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2luY2x1ZGUg
PGxpbnV4L3ZlcnNpb24uaD4KKyNpbmNsdWRlICJjb21tb24uaCIKKworc3RhdGljIGludCBnZXRf
aWRfZnJvbV9mcmVlbGlzdChzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8pCit7CisJdW5zaWdu
ZWQgbG9uZyBmbGFnczsKKwl1aW50MzJfdCBmcmVlOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmlu
Zm8tPnNoYWRvd19sb2NrLCBmbGFncyk7CisKKwlmcmVlID0gaW5mby0+c2hhZG93X2ZyZWU7CisJ
QlVHX09OKGZyZWUgPiBWU0NTSUlGX01BWF9SRVFTKTsKKwlpbmZvLT5zaGFkb3dfZnJlZSA9IGlu
Zm8tPnNoYWRvd1tmcmVlXS5uZXh0X2ZyZWU7CisJaW5mby0+c2hhZG93W2ZyZWVdLm5leHRfZnJl
ZSA9IDB4MGZmZjsKKworCWluZm8tPnNoYWRvd1tmcmVlXS53YWl0X3Jlc2V0ID0gMDsKKworCXNw
aW5fdW5sb2NrX2lycXJlc3RvcmUoJmluZm8tPnNoYWRvd19sb2NrLCBmbGFncyk7CisKKwlyZXR1
cm4gZnJlZTsKK30KKworc3RhdGljIHZvaWQgYWRkX2lkX3RvX2ZyZWVsaXN0KHN0cnVjdCB2c2Nz
aWZybnRfaW5mbyAqaW5mbywgdWludDMyX3QgaWQpCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsK
KworCXNwaW5fbG9ja19pcnFzYXZlKCZpbmZvLT5zaGFkb3dfbG9jaywgZmxhZ3MpOworCisJaW5m
by0+c2hhZG93W2lkXS5uZXh0X2ZyZWUgID0gaW5mby0+c2hhZG93X2ZyZWU7CisJaW5mby0+c2hh
ZG93W2lkXS5yZXFfc2NzaV9jbW5kID0gMDsKKwlpbmZvLT5zaGFkb3dfZnJlZSA9IGlkOworCisJ
c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+c2hhZG93X2xvY2ssIGZsYWdzKTsKK30KKwor
CitzdHJ1Y3QgdnNjc2lpZl9yZXF1ZXN0ICogc2NzaWZyb250X3ByZV9yZXF1ZXN0KHN0cnVjdCB2
c2NzaWZybnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgdnNjc2lpZl9mcm9udF9yaW5nICpyaW5n
ID0gJihpbmZvLT5yaW5nKTsKKwl2c2NzaWlmX3JlcXVlc3RfdCAqcmluZ19yZXE7CisJdWludDMy
X3QgaWQ7CisKKwlyaW5nX3JlcSA9IFJJTkdfR0VUX1JFUVVFU1QoJihpbmZvLT5yaW5nKSwgcmlu
Zy0+cmVxX3Byb2RfcHZ0KTsKKworCXJpbmctPnJlcV9wcm9kX3B2dCsrOworCisJaWQgPSBnZXRf
aWRfZnJvbV9mcmVlbGlzdChpbmZvKTsJLyogdXNlIGlkIGJ5IHJlc3BvbnNlICovCisJcmluZ19y
ZXEtPnJxaWQgPSAodWludDE2X3QpaWQ7CisKKwlyZXR1cm4gcmluZ19yZXE7Cit9CisKKworc3Rh
dGljIHZvaWQgc2NzaWZyb250X25vdGlmeV93b3JrKHN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5m
bykKK3sKKwlpbmZvLT53YWl0aW5nX3Jlc3AgPSAxOworCXdha2VfdXAoJmluZm8tPndxKTsKK30K
KworCitzdGF0aWMgdm9pZCBzY3NpZnJvbnRfZG9fcmVxdWVzdChzdHJ1Y3QgdnNjc2lmcm50X2lu
Zm8gKmluZm8pCit7CisJc3RydWN0IHZzY3NpaWZfZnJvbnRfcmluZyAqcmluZyA9ICYoaW5mby0+
cmluZyk7CisJdW5zaWduZWQgaW50IGlycSA9IGluZm8tPmlycTsKKwlpbnQgbm90aWZ5OworCisJ
UklOR19QVVNIX1JFUVVFU1RTX0FORF9DSEVDS19OT1RJRlkocmluZywgbm90aWZ5KTsKKwlpZiAo
bm90aWZ5KQorCQlub3RpZnlfcmVtb3RlX3ZpYV9pcnEoaXJxKTsKK30KKworaXJxcmV0dXJuX3Qg
c2NzaWZyb250X2ludHIoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjc2lmcm9udF9ub3Rp
Znlfd29yaygoc3RydWN0IHZzY3NpZnJudF9pbmZvICopZGV2X2lkKTsKKwlyZXR1cm4gSVJRX0hB
TkRMRUQ7Cit9CisKKworc3RhdGljIHZvaWQgc2NzaWZyb250X2dudHRhYl9kb25lKHN0cnVjdCB2
c2NzaWZybnRfc2hhZG93ICpzLCB1aW50MzJfdCBpZCkKK3sKKwlpbnQgaTsKKworCWlmIChzLT5z
Y19kYXRhX2RpcmVjdGlvbiA9PSBETUFfTk9ORSkKKwkJcmV0dXJuOworCisJaWYgKHMtPm5yX3Nl
Z21lbnRzKSB7CisJCWZvciAoaSA9IDA7IGkgPCBzLT5ucl9zZWdtZW50czsgaSsrKSB7CisJCQlp
ZiAodW5saWtlbHkoZ250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNzKAorCQkJCXMtPmdyZWZbaV0p
ICE9IDApKSB7CisJCQkJcHJpbnRrKEtFUk5fQUxFUlQgInNjc2lmcm9udDogIgorCQkJCQkiZ3Jh
bnQgc3RpbGwgaW4gdXNlIGJ5IGJhY2tlbmQuXG4iKTsKKwkJCQlCVUcoKTsKKwkJCX0KKwkJCWdu
dHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3Mocy0+Z3JlZltpXSwgMCwgMFVMKTsKKwkJfQorCX0KKwor
CXJldHVybjsKK30KKworCitzdGF0aWMgdm9pZCBzY3NpZnJvbnRfY2RiX2NtZF9kb25lKHN0cnVj
dCB2c2NzaWZybnRfaW5mbyAqaW5mbywKKwkJICAgICAgIHZzY3NpaWZfcmVzcG9uc2VfdCAqcmlu
Z19yZXMpCit7CisJc3RydWN0IHNjc2lfY21uZCAqc2M7CisJdWludDMyX3QgaWQ7CisJdWludDhf
dCBzZW5zZV9sZW47CisKKwlpZCA9IHJpbmdfcmVzLT5ycWlkOworCXNjID0gKHN0cnVjdCBzY3Np
X2NtbmQgKilpbmZvLT5zaGFkb3dbaWRdLnJlcV9zY3NpX2NtbmQ7CisKKwlpZiAoc2MgPT0gTlVM
TCkKKwkJQlVHKCk7CisKKwlzY3NpZnJvbnRfZ250dGFiX2RvbmUoJmluZm8tPnNoYWRvd1tpZF0s
IGlkKTsKKwlhZGRfaWRfdG9fZnJlZWxpc3QoaW5mbywgaWQpOworCisJc2MtPnJlc3VsdCA9IHJp
bmdfcmVzLT5yc2x0OworCXNjc2lfc2V0X3Jlc2lkKHNjLCByaW5nX3Jlcy0+cmVzaWR1YWxfbGVu
KTsKKworCWlmIChyaW5nX3Jlcy0+c2Vuc2VfbGVuID4gVlNDU0lJRl9TRU5TRV9CVUZGRVJTSVpF
KQorCQlzZW5zZV9sZW4gPSBWU0NTSUlGX1NFTlNFX0JVRkZFUlNJWkU7CisJZWxzZQorCQlzZW5z
ZV9sZW4gPSByaW5nX3Jlcy0+c2Vuc2VfbGVuOworCisJaWYgKHNlbnNlX2xlbikKKwkJbWVtY3B5
KHNjLT5zZW5zZV9idWZmZXIsIHJpbmdfcmVzLT5zZW5zZV9idWZmZXIsIHNlbnNlX2xlbik7CisK
KwlzYy0+c2NzaV9kb25lKHNjKTsKKworCXJldHVybjsKK30KKworCitzdGF0aWMgdm9pZCBzY3Np
ZnJvbnRfc3luY19jbWRfZG9uZShzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8sCisJCQkJdnNj
c2lpZl9yZXNwb25zZV90ICpyaW5nX3JlcykKK3sKKwl1aW50MTZfdCBpZCA9IHJpbmdfcmVzLT5y
cWlkOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisKKwlzcGluX2xvY2tfaXJxc2F2ZSgmaW5mby0+
c2hhZG93X2xvY2ssIGZsYWdzKTsKKwlpbmZvLT5zaGFkb3dbaWRdLndhaXRfcmVzZXQgPSAxOwor
CWluZm8tPnNoYWRvd1tpZF0ucnNsdF9yZXNldCA9IHJpbmdfcmVzLT5yc2x0OworCXNwaW5fdW5s
b2NrX2lycXJlc3RvcmUoJmluZm8tPnNoYWRvd19sb2NrLCBmbGFncyk7CisKKwl3YWtlX3VwKCYo
aW5mby0+c2hhZG93W2lkXS53cV9yZXNldCkpOworfQorCisKK2ludCBzY3NpZnJvbnRfY21kX2Rv
bmUoc3RydWN0IHZzY3NpZnJudF9pbmZvICppbmZvKQoreworCXZzY3NpaWZfcmVzcG9uc2VfdCAq
cmluZ19yZXM7CisKKwlSSU5HX0lEWCBpLCBycDsKKwlpbnQgbW9yZV90b19kbyA9IDA7CisJdW5z
aWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19pcnFzYXZlKCZpbmZvLT5pb19sb2NrLCBm
bGFncyk7CisKKwlycCA9IGluZm8tPnJpbmcuc3JpbmctPnJzcF9wcm9kOworCXJtYigpOworCWZv
ciAoaSA9IGluZm8tPnJpbmcucnNwX2NvbnM7IGkgIT0gcnA7IGkrKykgeworCisJCXJpbmdfcmVz
ID0gUklOR19HRVRfUkVTUE9OU0UoJmluZm8tPnJpbmcsIGkpOworCisJCWlmIChpbmZvLT5zaGFk
b3dbcmluZ19yZXMtPnJxaWRdLmFjdCA9PSBWU0NTSUlGX0FDVF9TQ1NJX0NEQikKKwkJCXNjc2lm
cm9udF9jZGJfY21kX2RvbmUoaW5mbywgcmluZ19yZXMpOworCQllbHNlCisJCQlzY3NpZnJvbnRf
c3luY19jbWRfZG9uZShpbmZvLCByaW5nX3Jlcyk7CisJfQorCisJaW5mby0+cmluZy5yc3BfY29u
cyA9IGk7CisKKwlpZiAoaSAhPSBpbmZvLT5yaW5nLnJlcV9wcm9kX3B2dCkgeworCQlSSU5HX0ZJ
TkFMX0NIRUNLX0ZPUl9SRVNQT05TRVMoJmluZm8tPnJpbmcsIG1vcmVfdG9fZG8pOworCX0gZWxz
ZSB7CisJCWluZm8tPnJpbmcuc3JpbmctPnJzcF9ldmVudCA9IGkgKyAxOworCX0KKworCXNwaW5f
dW5sb2NrX2lycXJlc3RvcmUoJmluZm8tPmlvX2xvY2ssIGZsYWdzKTsKKworCisJLyogWWllbGQg
cG9pbnQgZm9yIHRoaXMgdW5ib3VuZGVkIGxvb3AuICovCisJY29uZF9yZXNjaGVkKCk7CisKKwly
ZXR1cm4gbW9yZV90b19kbzsKK30KKworCisKKworaW50IHNjc2lmcm9udF9zY2hlZHVsZSh2b2lk
ICpkYXRhKQoreworCXN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbyA9IChzdHJ1Y3QgdnNjc2lm
cm50X2luZm8gKilkYXRhOworCisJd2hpbGUgKCFrdGhyZWFkX3Nob3VsZF9zdG9wKCkpIHsKKwkJ
d2FpdF9ldmVudF9pbnRlcnJ1cHRpYmxlKAorCQkJaW5mby0+d3EsCisJCQlpbmZvLT53YWl0aW5n
X3Jlc3AgfHwga3RocmVhZF9zaG91bGRfc3RvcCgpKTsKKworCQlpbmZvLT53YWl0aW5nX3Jlc3Ag
PSAwOworCQlzbXBfbWIoKTsKKworCQlpZiAoc2NzaWZyb250X2NtZF9kb25lKGluZm8pKQorCQkJ
aW5mby0+d2FpdGluZ19yZXNwID0gMTsKKwl9CisKKwlyZXR1cm4gMDsKK30KKworCisKK3N0YXRp
YyBpbnQgbWFwX2RhdGFfZm9yX3JlcXVlc3Qoc3RydWN0IHZzY3NpZnJudF9pbmZvICppbmZvLAor
CQlzdHJ1Y3Qgc2NzaV9jbW5kICpzYywgdnNjc2lpZl9yZXF1ZXN0X3QgKnJpbmdfcmVxLCB1aW50
MzJfdCBpZCkKK3sKKwlncmFudF9yZWZfdCBncmVmX2hlYWQ7CisJaW50IGVyciwgcmVmLCByZWZf
Y250ID0gMDsKKwlpbnQgd3JpdGUgPSAoc2MtPnNjX2RhdGFfZGlyZWN0aW9uID09IERNQV9UT19E
RVZJQ0UpOworCXVuc2lnbmVkIGludCBpLCBucl9wYWdlcywgb2ZmLCBsZW4sIGJ5dGVzOworCXVu
c2lnbmVkIGxvbmcgYnVmZmVyX21mbiwgYnVmZmVyX3BmbjsKKworCWlmIChzYy0+c2NfZGF0YV9k
aXJlY3Rpb24gPT0gRE1BX05PTkUpCisJCXJldHVybiAwOworCisJZXJyID0gZ250dGFiX2FsbG9j
X2dyYW50X3JlZmVyZW5jZXMoVlNDU0lJRl9TR19UQUJMRVNJWkUsICZncmVmX2hlYWQpOworCWlm
IChlcnIpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpZnJvbnQ6IGdudHRhYl9hbGxvY19ncmFu
dF9yZWZlcmVuY2VzKCkgZXJyb3JcbiIpOworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisKKwlpZiAo
c2NzaV9idWZmbGVuKHNjKSkgeworCQkvKiBxdW90ZWQgc2NzaV9saWIuYy9zY3NpX3JlcV9tYXBf
c2cgLiAqLworCQlzdHJ1Y3Qgc2NhdHRlcmxpc3QgKnNnLCAqc2dsID0gc2NzaV9zZ2xpc3Qoc2Mp
OworCQl1bnNpZ25lZCBpbnQgZGF0YV9sZW4gPSBzY3NpX2J1ZmZsZW4oc2MpOworCisJCW5yX3Bh
Z2VzID0gKGRhdGFfbGVuICsgc2dsLT5vZmZzZXQgKyBQQUdFX1NJWkUgLSAxKSA+PiBQQUdFX1NI
SUZUOworCQlpZiAobnJfcGFnZXMgPiBWU0NTSUlGX1NHX1RBQkxFU0laRSkgeworCQkJcHJpbnRr
KEtFUk5fRVJSICJzY3NpZnJvbnQ6IFVuYWJsZSB0byBtYXAgcmVxdWVzdF9idWZmZXIgZm9yIGNv
bW1hbmQhXG4iKTsKKwkJCXJlZl9jbnQgPSAoLUUyQklHKTsKKwkJCWdvdG8gYmlnX3RvX3NnOwor
CQl9CisKKwkJZm9yX2VhY2hfc2cgKHNnbCwgc2csIHNjc2lfc2dfY291bnQoc2MpLCBpKSB7CisJ
CQlvZmYgPSBzZy0+b2Zmc2V0OworCQkJbGVuID0gc2ctPmxlbmd0aDsKKworCQkJYnVmZmVyX3Bm
biA9IHBhZ2VfdG9fcGZuKHNnX3BhZ2Uoc2cpKTsKKwkJCXdoaWxlIChsZW4gPiAwICYmIGRhdGFf
bGVuID4gMCkgeworCQkJCS8qCisJCQkJICogc2cgc2VuZHMgYSBzY2F0dGVybGlzdCB0aGF0IGlz
IGxhcmdlciB0aGFuCisJCQkJICogdGhlIGRhdGFfbGVuIGl0IHdhbnRzIHRyYW5zZmVycmVkIGZv
ciBjZXJ0YWluCisJCQkJICogSU8gc2l6ZXMKKwkJCQkgKi8KKwkJCQlieXRlcyA9IG1pbl90KHVu
c2lnbmVkIGludCwgbGVuLCBQQUdFX1NJWkUgLSBvZmYpOworCQkJCWJ5dGVzID0gbWluKGJ5dGVz
LCBkYXRhX2xlbik7CisKKwkJCQlyZWYgPSBnbnR0YWJfY2xhaW1fZ3JhbnRfcmVmZXJlbmNlKCZn
cmVmX2hlYWQpOworCQkJCUJVR19PTihyZWYgPT0gLUVOT1NQQyk7CisKKwkJCQlidWZmZXJfbWZu
ID0gcGZuX3RvX21mbihidWZmZXJfcGZuKTsKKwkJCQlnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nl
c3NfcmVmKHJlZiwgaW5mby0+ZGV2LT5vdGhlcmVuZF9pZCwKKwkJCQkJYnVmZmVyX21mbiwgd3Jp
dGUpOworCisJCQkJaW5mby0+c2hhZG93W2lkXS5ncmVmW3JlZl9jbnRdICA9IHJlZjsKKwkJCQly
aW5nX3JlcS0+c2VnW3JlZl9jbnRdLmdyZWYgICAgID0gcmVmOworCQkJCXJpbmdfcmVxLT5zZWdb
cmVmX2NudF0ub2Zmc2V0ICAgPSAodWludDE2X3Qpb2ZmOworCQkJCXJpbmdfcmVxLT5zZWdbcmVm
X2NudF0ubGVuZ3RoICAgPSAodWludDE2X3QpYnl0ZXM7CisKKwkJCQlidWZmZXJfcGZuICsrOwor
CQkJCWxlbiAtPSBieXRlczsKKwkJCQlkYXRhX2xlbiAtPSBieXRlczsKKwkJCQlvZmYgPSAwOwor
CQkJCXJlZl9jbnQrKzsKKwkJCX0KKwkJfQorCX0KKworYmlnX3RvX3NnOgorCisJZ250dGFiX2Zy
ZWVfZ3JhbnRfcmVmZXJlbmNlcyhncmVmX2hlYWQpOworCisJcmV0dXJuIHJlZl9jbnQ7Cit9CisK
K3N0YXRpYyBpbnQgc2NzaWZyb250X3F1ZXVlY29tbWFuZChzdHJ1Y3QgU2NzaV9Ib3N0ICpoLCBz
dHJ1Y3Qgc2NzaV9jbW5kICpzYykKK3sKKwlzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPQor
CQkoc3RydWN0IHZzY3NpZnJudF9pbmZvICopIHNjLT5kZXZpY2UtPmhvc3QtPmhvc3RkYXRhOwor
CXZzY3NpaWZfcmVxdWVzdF90ICpyaW5nX3JlcTsKKwlpbnQgcmVmX2NudDsKKwl1aW50MTZfdCBy
cWlkOworCisJaWYgKFJJTkdfRlVMTCgmaW5mby0+cmluZykpIHsKKwkJZ290byBvdXRfaG9zdF9i
dXN5OworCX0KKworCXNjLT5yZXN1bHQgICAgPSAwOworCisJcmluZ19yZXEgICAgICAgICAgPSBz
Y3NpZnJvbnRfcHJlX3JlcXVlc3QoaW5mbyk7CisJcnFpZCAgICAgICAgICAgICAgPSByaW5nX3Jl
cS0+cnFpZDsKKwlyaW5nX3JlcS0+YWN0ICAgICA9IFZTQ1NJSUZfQUNUX1NDU0lfQ0RCOworCisJ
cmluZ19yZXEtPmlkICAgICAgPSBzYy0+ZGV2aWNlLT5pZDsKKwlyaW5nX3JlcS0+bHVuICAgICA9
IHNjLT5kZXZpY2UtPmx1bjsKKwlyaW5nX3JlcS0+Y2hhbm5lbCA9IHNjLT5kZXZpY2UtPmNoYW5u
ZWw7CisJcmluZ19yZXEtPmNtZF9sZW4gPSBzYy0+Y21kX2xlbjsKKworCUJVR19PTihzYy0+Y21k
X2xlbiA+IFZTQ1NJSUZfTUFYX0NPTU1BTkRfU0laRSk7CisKKwlpZiAoc2MtPmNtZF9sZW4pCisJ
CW1lbWNweShyaW5nX3JlcS0+Y21uZCwgc2MtPmNtbmQsIHNjLT5jbWRfbGVuKTsKKwllbHNlCisJ
CW1lbXNldChyaW5nX3JlcS0+Y21uZCwgMCwgVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFKTsKKwor
CXJpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiAgID0gKHVpbnQ4X3Qpc2MtPnNjX2RhdGFfZGly
ZWN0aW9uOworCXJpbmdfcmVxLT50aW1lb3V0X3Blcl9jb21tYW5kID0gKHNjLT5yZXF1ZXN0LT50
aW1lb3V0IC8gSFopOworCisJaW5mby0+c2hhZG93W3JxaWRdLnJlcV9zY3NpX2NtbmQgICAgID0g
KHVuc2lnbmVkIGxvbmcpc2M7CisJaW5mby0+c2hhZG93W3JxaWRdLnNjX2RhdGFfZGlyZWN0aW9u
ID0gc2MtPnNjX2RhdGFfZGlyZWN0aW9uOworCWluZm8tPnNoYWRvd1tycWlkXS5hY3QgICAgICAg
ICAgICAgICA9IHJpbmdfcmVxLT5hY3Q7CisKKwlyZWZfY250ID0gbWFwX2RhdGFfZm9yX3JlcXVl
c3QoaW5mbywgc2MsIHJpbmdfcmVxLCBycWlkKTsKKwlpZiAocmVmX2NudCA8IDApIHsKKwkJYWRk
X2lkX3RvX2ZyZWVsaXN0KGluZm8sIHJxaWQpOworCQlpZiAocmVmX2NudCA9PSAoLUVOT01FTSkp
CisJCQlnb3RvIG91dF9ob3N0X2J1c3k7CisJCWVsc2UgeworCQkJc2MtPnJlc3VsdCA9IChESURf
RVJST1IgPDwgMTYpOworCQkJZ290byBvdXRfZmFpbF9jb21tYW5kOworCQl9CisJfQorCisJcmlu
Z19yZXEtPm5yX3NlZ21lbnRzICAgICAgICAgID0gKHVpbnQ4X3QpcmVmX2NudDsKKwlpbmZvLT5z
aGFkb3dbcnFpZF0ubnJfc2VnbWVudHMgPSByZWZfY250OworCisJc2NzaWZyb250X2RvX3JlcXVl
c3QoaW5mbyk7CisKKwlyZXR1cm4gMDsKKworb3V0X2hvc3RfYnVzeToKKwlyZXR1cm4gU0NTSV9N
TFFVRVVFX0hPU1RfQlVTWTsKKworb3V0X2ZhaWxfY29tbWFuZDoKKwlzYy0+c2NzaV9kb25lKHNj
KTsKKwlyZXR1cm4gMDsKK30KKworCitzdGF0aWMgaW50IHNjc2lmcm9udF9laF9hYm9ydF9oYW5k
bGVyKHN0cnVjdCBzY3NpX2NtbmQgKnNjKQoreworCXJldHVybiAoRkFJTEVEKTsKK30KKworLyog
dnNjc2kgc3VwcG9ydHMgb25seSBkZXZpY2VfcmVzZXQsIGJlY2F1c2UgaXQgaXMgZWFjaCBvZiBM
VU5zICovCitzdGF0aWMgaW50IHNjc2lmcm9udF9kZXZfcmVzZXRfaGFuZGxlcihzdHJ1Y3Qgc2Nz
aV9jbW5kICpzYykKK3sKKwlzdHJ1Y3QgU2NzaV9Ib3N0ICpob3N0ID0gc2MtPmRldmljZS0+aG9z
dDsKKwlzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPQorCQkoc3RydWN0IHZzY3NpZnJudF9p
bmZvICopIHNjLT5kZXZpY2UtPmhvc3QtPmhvc3RkYXRhOworCisJdnNjc2lpZl9yZXF1ZXN0X3Qg
KnJpbmdfcmVxOworCXVpbnQxNl90IHJxaWQ7CisJaW50IGVycjsKKworCXNwaW5fbG9ja19pcnEo
aG9zdC0+aG9zdF9sb2NrKTsKKworCXJpbmdfcmVxICAgICAgPSBzY3NpZnJvbnRfcHJlX3JlcXVl
c3QoaW5mbyk7CisJcmluZ19yZXEtPmFjdCA9IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQ7CisKKwly
cWlkICAgICAgICAgID0gcmluZ19yZXEtPnJxaWQ7CisJaW5mby0+c2hhZG93W3JxaWRdLmFjdCA9
IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQ7CisKKwlyaW5nX3JlcS0+Y2hhbm5lbCA9IHNjLT5kZXZp
Y2UtPmNoYW5uZWw7CisJcmluZ19yZXEtPmlkICAgICAgPSBzYy0+ZGV2aWNlLT5pZDsKKwlyaW5n
X3JlcS0+bHVuICAgICA9IHNjLT5kZXZpY2UtPmx1bjsKKwlyaW5nX3JlcS0+Y21kX2xlbiA9IHNj
LT5jbWRfbGVuOworCisJaWYgKCBzYy0+Y21kX2xlbiApCisJCW1lbWNweShyaW5nX3JlcS0+Y21u
ZCwgc2MtPmNtbmQsIHNjLT5jbWRfbGVuKTsKKwllbHNlCisJCW1lbXNldChyaW5nX3JlcS0+Y21u
ZCwgMCwgVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFKTsKKworCXJpbmdfcmVxLT5zY19kYXRhX2Rp
cmVjdGlvbiAgID0gKHVpbnQ4X3Qpc2MtPnNjX2RhdGFfZGlyZWN0aW9uOworCXJpbmdfcmVxLT50
aW1lb3V0X3Blcl9jb21tYW5kID0gKHNjLT5yZXF1ZXN0LT50aW1lb3V0IC8gSFopOworCXJpbmdf
cmVxLT5ucl9zZWdtZW50cyAgICAgICAgID0gMDsKKworCXNjc2lmcm9udF9kb19yZXF1ZXN0KGlu
Zm8pOworCisJc3Bpbl91bmxvY2tfaXJxKGhvc3QtPmhvc3RfbG9jayk7CisJd2FpdF9ldmVudF9p
bnRlcnJ1cHRpYmxlKGluZm8tPnNoYWRvd1tycWlkXS53cV9yZXNldCwKKwkJCSBpbmZvLT5zaGFk
b3dbcnFpZF0ud2FpdF9yZXNldCk7CisJc3Bpbl9sb2NrX2lycShob3N0LT5ob3N0X2xvY2spOwor
CisJZXJyID0gaW5mby0+c2hhZG93W3JxaWRdLnJzbHRfcmVzZXQ7CisKKwlhZGRfaWRfdG9fZnJl
ZWxpc3QoaW5mbywgcnFpZCk7CisKKwlzcGluX3VubG9ja19pcnEoaG9zdC0+aG9zdF9sb2NrKTsK
KwlyZXR1cm4gKGVycik7Cit9CisKKworc3RydWN0IHNjc2lfaG9zdF90ZW1wbGF0ZSBzY3NpZnJv
bnRfc2h0ID0geworCS5tb2R1bGUJCQk9IFRISVNfTU9EVUxFLAorCS5uYW1lCQkJPSAiWGVuIFND
U0kgZnJvbnRlbmQgZHJpdmVyIiwKKwkucXVldWVjb21tYW5kCQk9IHNjc2lmcm9udF9xdWV1ZWNv
bW1hbmQsCisJLmVoX2Fib3J0X2hhbmRsZXIJPSBzY3NpZnJvbnRfZWhfYWJvcnRfaGFuZGxlciwK
KwkuZWhfZGV2aWNlX3Jlc2V0X2hhbmRsZXI9IHNjc2lmcm9udF9kZXZfcmVzZXRfaGFuZGxlciwK
KwkuY21kX3Blcl9sdW4JCT0gVlNDU0lJRl9ERUZBVUxUX0NNRF9QRVJfTFVOLAorCS5jYW5fcXVl
dWUJCT0gVlNDU0lJRl9NQVhfUkVRUywKKwkudGhpc19pZCAJCT0gLTEsCisJLnNnX3RhYmxlc2l6
ZQkJPSBWU0NTSUlGX1NHX1RBQkxFU0laRSwKKwkudXNlX2NsdXN0ZXJpbmcJCT0gRElTQUJMRV9D
TFVTVEVSSU5HLAorCS5wcm9jX25hbWUJCT0gInNjc2lmcm9udCIsCit9OworCisKK3N0YXRpYyBp
bnQgX19pbml0IHNjc2lmcm9udF9pbml0KHZvaWQpCit7CisJaW50IGVycjsKKworCWlmICgheGVu
X2RvbWFpbigpKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCWVyciA9IHNjc2lmcm9udF94ZW5idXNf
aW5pdCgpOworCisJcmV0dXJuIGVycjsKK30KKworc3RhdGljIHZvaWQgX19leGl0IHNjc2lmcm9u
dF9leGl0KHZvaWQpCit7CisJc2NzaWZyb250X3hlbmJ1c191bnJlZ2lzdGVyKCk7Cit9CisKK21v
ZHVsZV9pbml0KHNjc2lmcm9udF9pbml0KTsKK21vZHVsZV9leGl0KHNjc2lmcm9udF9leGl0KTsK
KworTU9EVUxFX0RFU0NSSVBUSU9OKCJYZW4gU0NTSSBmcm9udGVuZCBkcml2ZXIiKTsKK01PRFVM
RV9MSUNFTlNFKCJHUEwiKTsKZGlmZiAtcnVwTiB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpZnJv
bnQveGVuYnVzLmMgeGVuYy9kcml2ZXJzL3Njc2kveGVuLXNjc2lmcm9udC94ZW5idXMuYwotLS0g
eGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L3hlbmJ1cy5jCTE5NjktMTItMzEgMTc6MDA6
MDAuMDAwMDAwMDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L3hl
bmJ1cy5jCTIwMTItMDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNDEx
IEBACisvKgorICogWGVuIFNDU0kgZnJvbnRlbmQgZHJpdmVyCisgKgorICogQ29weXJpZ2h0IChj
KSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQKKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0
d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkgaXQgdW5kZXIg
dGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIKKyAq
IGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBvciwgd2hlbiBk
aXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwgb3IgaW5jb3Jw
b3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0IHRvIHRoZSBm
b2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBncmFudGVkLCBm
cmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0aGlz
IHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNvZnR3YXJlIHdp
dGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0aW9uIHRoZSBy
aWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwgZGlzdHJpYnV0
ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwKKyAqIGFu
ZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQgdG8g
ZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKKyAqCisgKiBU
aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBzaGFs
bCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9ucyBv
ZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIs
IFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElNUExJRUQsIElO
Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklM
SVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5PTklORlJJTkdF
TUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlSSUdIVCBIT0xE
RVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisgKiBMSUFCSUxJ
VFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9USEVSV0lTRSwg
QVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUgU09GVFdB
UkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRXQVJFLgorICov
CisKKyNpbmNsdWRlIDxsaW51eC92ZXJzaW9uLmg+CisjaW5jbHVkZSAiY29tbW9uLmgiCisKK2V4
dGVybiBzdHJ1Y3Qgc2NzaV9ob3N0X3RlbXBsYXRlIHNjc2lmcm9udF9zaHQ7CisKK3N0YXRpYyB2
b2lkIHNjc2lmcm9udF9mcmVlKHN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1
Y3QgU2NzaV9Ib3N0ICpob3N0ID0gaW5mby0+aG9zdDsKKworCWlmIChob3N0LT5zaG9zdF9zdGF0
ZSAhPSBTSE9TVF9ERUwpCisJCXNjc2lfcmVtb3ZlX2hvc3QoaW5mby0+aG9zdCk7CisKKwlpZiAo
aW5mby0+cmluZ19yZWYgIT0gR1JBTlRfSU5WQUxJRF9SRUYpIHsKKwkJZ250dGFiX2VuZF9mb3Jl
aWduX2FjY2VzcyhpbmZvLT5yaW5nX3JlZiwKKwkJCQkJMCwgKHVuc2lnbmVkIGxvbmcpaW5mby0+
cmluZy5zcmluZyk7CisJCWluZm8tPnJpbmdfcmVmID0gR1JBTlRfSU5WQUxJRF9SRUY7CisJCWlu
Zm8tPnJpbmcuc3JpbmcgPSBOVUxMOworCX0KKworCWlmIChpbmZvLT5pcnEpCisJCXVuYmluZF9m
cm9tX2lycWhhbmRsZXIoaW5mby0+aXJxLCBpbmZvKTsKKwlpbmZvLT5pcnEgPSAwOworCisJc2Nz
aV9ob3N0X3B1dChpbmZvLT5ob3N0KTsKK30KKworCitzdGF0aWMgaW50IHNjc2lmcm9udF9hbGxv
Y19yaW5nKHN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgeGVuYnVzX2Rl
dmljZSAqZGV2ID0gaW5mby0+ZGV2OworCXN0cnVjdCB2c2NzaWlmX3NyaW5nICpzcmluZzsKKwlp
bnQgZXJyID0gLUVOT01FTTsKKworCisJaW5mby0+cmluZ19yZWYgPSBHUkFOVF9JTlZBTElEX1JF
RjsKKworCS8qKioqKiBGcm9udGVuZCB0byBCYWNrZW5kIHJpbmcgc3RhcnQgKioqKiovCisJc3Jp
bmcgPSAoc3RydWN0IHZzY3NpaWZfc3JpbmcgKikgX19nZXRfZnJlZV9wYWdlKEdGUF9LRVJORUwp
OworCWlmICghc3JpbmcpIHsKKwkJeGVuYnVzX2Rldl9mYXRhbChkZXYsIGVyciwgImZhaWwgdG8g
YWxsb2NhdGUgc2hhcmVkIHJpbmcgKEZyb250IHRvIEJhY2spIik7CisJCXJldHVybiBlcnI7CisJ
fQorCVNIQVJFRF9SSU5HX0lOSVQoc3JpbmcpOworCUZST05UX1JJTkdfSU5JVCgmaW5mby0+cmlu
Zywgc3JpbmcsIFBBR0VfU0laRSk7CisKKwllcnIgPSB4ZW5idXNfZ3JhbnRfcmluZyhkZXYsIHZp
cnRfdG9fbWZuKHNyaW5nKSk7CisJaWYgKGVyciA8IDApIHsKKwkJZnJlZV9wYWdlKCh1bnNpZ25l
ZCBsb25nKSBzcmluZyk7CisJCWluZm8tPnJpbmcuc3JpbmcgPSBOVUxMOworCQl4ZW5idXNfZGV2
X2ZhdGFsKGRldiwgZXJyLCAiZmFpbCB0byBncmFudCBzaGFyZWQgcmluZyAoRnJvbnQgdG8gQmFj
aykiKTsKKwkJZ290byBmcmVlX3NyaW5nOworCX0KKwlpbmZvLT5yaW5nX3JlZiA9IGVycjsKKwor
CWVyciA9IHhlbmJ1c19hbGxvY19ldnRjaG4oZGV2LCAmaW5mby0+ZXZ0Y2huKTsKKwlpZiAoZXJy
KQorCQlnb3RvIGZyZWVfc3Jpbmc7CisKKwllcnIgPSBiaW5kX2V2dGNobl90b19pcnFoYW5kbGVy
KAorCQkJaW5mby0+ZXZ0Y2huLCBzY3NpZnJvbnRfaW50ciwKKwkJCUlSUUZfU0FNUExFX1JBTkRP
TSwgInNjc2lmcm9udCIsIGluZm8pOworCisJaWYgKGVyciA8PSAwKSB7CisJCXhlbmJ1c19kZXZf
ZmF0YWwoZGV2LCBlcnIsICJiaW5kX2V2dGNobl90b19pcnFoYW5kbGVyIik7CisJCWdvdG8gZnJl
ZV9zcmluZzsKKwl9CisJaW5mby0+aXJxID0gZXJyOworCisJcmV0dXJuIDA7CisKKy8qIGZyZWUg
cmVzb3VyY2UgKi8KK2ZyZWVfc3Jpbmc6CisJc2NzaWZyb250X2ZyZWUoaW5mbyk7CisKKwlyZXR1
cm4gZXJyOworfQorCisKK3N0YXRpYyBpbnQgc2NzaWZyb250X2luaXRfcmluZyhzdHJ1Y3QgdnNj
c2lmcm50X2luZm8gKmluZm8pCit7CisJc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiA9IGluZm8t
PmRldjsKKwlzdHJ1Y3QgeGVuYnVzX3RyYW5zYWN0aW9uIHhidDsKKwlpbnQgZXJyOworCisJRFBS
SU5USygiJXNcbiIsX19GVU5DVElPTl9fKTsKKworCWVyciA9IHNjc2lmcm9udF9hbGxvY19yaW5n
KGluZm8pOworCWlmIChlcnIpCisJCXJldHVybiBlcnI7CisJRFBSSU5USygiJXUgJXVcbiIsIGlu
Zm8tPnJpbmdfcmVmLCBpbmZvLT5ldnRjaG4pOworCithZ2FpbjoKKwllcnIgPSB4ZW5idXNfdHJh
bnNhY3Rpb25fc3RhcnQoJnhidCk7CisJaWYgKGVycikgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRl
diwgZXJyLCAic3RhcnRpbmcgdHJhbnNhY3Rpb24iKTsKKwl9CisKKwllcnIgPSB4ZW5idXNfcHJp
bnRmKHhidCwgZGV2LT5ub2RlbmFtZSwgInJpbmctcmVmIiwgIiV1IiwKKwkJCQlpbmZvLT5yaW5n
X3JlZik7CisJaWYgKGVycikgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJyLCAiJXMiLCAi
d3JpdGluZyByaW5nLXJlZiIpOworCQlnb3RvIGZhaWw7CisJfQorCisJZXJyID0geGVuYnVzX3By
aW50Zih4YnQsIGRldi0+bm9kZW5hbWUsICJldmVudC1jaGFubmVsIiwgIiV1IiwKKwkJCQlpbmZv
LT5ldnRjaG4pOworCisJaWYgKGVycikgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJyLCAi
JXMiLCAid3JpdGluZyBldmVudC1jaGFubmVsIik7CisJCWdvdG8gZmFpbDsKKwl9CisKKwllcnIg
PSB4ZW5idXNfdHJhbnNhY3Rpb25fZW5kKHhidCwgMCk7CisJaWYgKGVycikgeworCQlpZiAoZXJy
ID09IC1FQUdBSU4pCisJCQlnb3RvIGFnYWluOworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJy
LCAiY29tcGxldGluZyB0cmFuc2FjdGlvbiIpOworCQlnb3RvIGZyZWVfc3Jpbmc7CisJfQorCisJ
cmV0dXJuIDA7CisKK2ZhaWw6CisJeGVuYnVzX3RyYW5zYWN0aW9uX2VuZCh4YnQsIDEpOworZnJl
ZV9zcmluZzoKKwkvKiBmcmVlIHJlc291cmNlICovCisJc2NzaWZyb250X2ZyZWUoaW5mbyk7CisK
KwlyZXR1cm4gZXJyOworfQorCisKK3N0YXRpYyBpbnQgc2NzaWZyb250X3Byb2JlKHN0cnVjdCB4
ZW5idXNfZGV2aWNlICpkZXYsCisJCQkJY29uc3Qgc3RydWN0IHhlbmJ1c19kZXZpY2VfaWQgKmlk
KQoreworCXN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbzsKKwlzdHJ1Y3QgU2NzaV9Ib3N0ICpo
b3N0OworCWludCBpLCBlcnIgPSAtRU5PTUVNOworCWNoYXIgbmFtZVtUQVNLX0NPTU1fTEVOXTsK
KworCWhvc3QgPSBzY3NpX2hvc3RfYWxsb2MoJnNjc2lmcm9udF9zaHQsIHNpemVvZigqaW5mbykp
OworCWlmICghaG9zdCkgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJyLCAiZmFpbCB0byBh
bGxvY2F0ZSBzY3NpIGhvc3QiKTsKKwkJcmV0dXJuIGVycjsKKwl9CisJaW5mbyA9IChzdHJ1Y3Qg
dnNjc2lmcm50X2luZm8gKikgaG9zdC0+aG9zdGRhdGE7CisJaW5mby0+aG9zdCA9IGhvc3Q7CisK
KworCWRldl9zZXRfZHJ2ZGF0YSgmZGV2LT5kZXYsIGluZm8pOworCWluZm8tPmRldiAgPSBkZXY7
CisKKwlmb3IgKGkgPSAwOyBpIDwgVlNDU0lJRl9NQVhfUkVRUzsgaSsrKSB7CisJCWluZm8tPnNo
YWRvd1tpXS5uZXh0X2ZyZWUgPSBpICsgMTsKKwkJaW5pdF93YWl0cXVldWVfaGVhZCgmKGluZm8t
PnNoYWRvd1tpXS53cV9yZXNldCkpOworCQlpbmZvLT5zaGFkb3dbaV0ud2FpdF9yZXNldCA9IDA7
CisJfQorCWluZm8tPnNoYWRvd1tWU0NTSUlGX01BWF9SRVFTIC0gMV0ubmV4dF9mcmVlID0gMHgw
ZmZmOworCisJZXJyID0gc2NzaWZyb250X2luaXRfcmluZyhpbmZvKTsKKwlpZiAoZXJyKSB7CisJ
CXNjc2lfaG9zdF9wdXQoaG9zdCk7CisJCXJldHVybiBlcnI7CisJfQorCisJaW5pdF93YWl0cXVl
dWVfaGVhZCgmaW5mby0+d3EpOworCXNwaW5fbG9ja19pbml0KCZpbmZvLT5pb19sb2NrKTsKKwlz
cGluX2xvY2tfaW5pdCgmaW5mby0+c2hhZG93X2xvY2spOworCisJc25wcmludGYobmFtZSwgVEFT
S19DT01NX0xFTiwgInZzY3NpaWYuJWQiLCBpbmZvLT5ob3N0LT5ob3N0X25vKTsKKworCWluZm8t
Pmt0aHJlYWQgPSBrdGhyZWFkX3J1bihzY3NpZnJvbnRfc2NoZWR1bGUsIGluZm8sIG5hbWUpOwor
CWlmIChJU19FUlIoaW5mby0+a3RocmVhZCkpIHsKKwkJZXJyID0gUFRSX0VSUihpbmZvLT5rdGhy
ZWFkKTsKKwkJaW5mby0+a3RocmVhZCA9IE5VTEw7CisJCXByaW50ayhLRVJOX0VSUiAic2NzaWZy
b250OiBrdGhyZWFkIHN0YXJ0IGVyciAlZFxuIiwgZXJyKTsKKwkJZ290byBmcmVlX3NyaW5nOwor
CX0KKworCWhvc3QtPm1heF9pZCAgICAgID0gVlNDU0lJRl9NQVhfVEFSR0VUOworCWhvc3QtPm1h
eF9jaGFubmVsID0gMDsKKwlob3N0LT5tYXhfbHVuICAgICA9IFZTQ1NJSUZfTUFYX0xVTjsKKwlo
b3N0LT5tYXhfc2VjdG9ycyA9IChWU0NTSUlGX1NHX1RBQkxFU0laRSAtIDEpICogUEFHRV9TSVpF
IC8gNTEyOworCWhvc3QtPm1heF9jbWRfbGVuID0gVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFOwor
CisJZXJyID0gc2NzaV9hZGRfaG9zdChob3N0LCAmZGV2LT5kZXYpOworCWlmIChlcnIpIHsKKwkJ
cHJpbnRrKEtFUk5fRVJSICJzY3NpZnJvbnQ6IGZhaWwgdG8gYWRkIHNjc2kgaG9zdCAlZFxuIiwg
ZXJyKTsKKwkJZ290byBmcmVlX3NyaW5nOworCX0KKworCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2
LCBYZW5idXNTdGF0ZUluaXRpYWxpc2VkKTsKKworCXJldHVybiAwOworCitmcmVlX3NyaW5nOgor
CS8qIGZyZWUgcmVzb3VyY2UgKi8KKwlzY3NpZnJvbnRfZnJlZShpbmZvKTsKKwlyZXR1cm4gZXJy
OworfQorCitzdGF0aWMgaW50IHNjc2lmcm9udF9yZW1vdmUoc3RydWN0IHhlbmJ1c19kZXZpY2Ug
KmRldikKK3sKKwlzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPSBkZXZfZ2V0X2RydmRhdGEo
JmRldi0+ZGV2KTsKKworCURQUklOVEsoIiVzOiAlcyByZW1vdmVkXG4iLF9fRlVOQ1RJT05fXyAs
ZGV2LT5ub2RlbmFtZSk7CisKKwlpZiAoaW5mby0+a3RocmVhZCkgeworCQlrdGhyZWFkX3N0b3Ao
aW5mby0+a3RocmVhZCk7CisJCWluZm8tPmt0aHJlYWQgPSBOVUxMOworCX0KKworCXNjc2lmcm9u
dF9mcmVlKGluZm8pOworCisJcmV0dXJuIDA7Cit9CisKKworc3RhdGljIGludCBzY3NpZnJvbnRf
ZGlzY29ubmVjdChzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8pCit7CisJc3RydWN0IHhlbmJ1
c19kZXZpY2UgKmRldiA9IGluZm8tPmRldjsKKwlzdHJ1Y3QgU2NzaV9Ib3N0ICpob3N0ID0gaW5m
by0+aG9zdDsKKworCURQUklOVEsoIiVzOiAlcyBkaXNjb25uZWN0XG4iLF9fRlVOQ1RJT05fXyAs
ZGV2LT5ub2RlbmFtZSk7CisKKwkvKgorCSAgV2hlbiB0aGlzIGZ1bmN0aW9uIGlzIGV4ZWN1dGVk
LCAgYWxsIGRldmljZXMgb2YKKwkgIEZyb250ZW5kIGhhdmUgYmVlbiBkZWxldGVkLgorCSAgVGhl
cmVmb3JlLCBpdCBuZWVkIG5vdCBibG9jayBJL08gYmVmb3JlIHJlbW92ZV9ob3N0LgorCSovCisK
KwlzY3NpX3JlbW92ZV9ob3N0KGhvc3QpOworCXhlbmJ1c19mcm9udGVuZF9jbG9zZWQoZGV2KTsK
KworCXJldHVybiAwOworfQorCisjZGVmaW5lIFZTQ1NJRlJPTlRfT1BfQUREX0xVTgkxCisjZGVm
aW5lIFZTQ1NJRlJPTlRfT1BfREVMX0xVTgkyCisKK3N0YXRpYyB2b2lkIHNjc2lmcm9udF9kb19s
dW5faG90cGx1ZyhzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8sIGludCBvcCkKK3sKKwlzdHJ1
Y3QgeGVuYnVzX2RldmljZSAqZGV2ID0gaW5mby0+ZGV2OworCWludCBpLCBlcnIgPSAwOworCWNo
YXIgc3RyWzY0XSwgc3RhdGVfc3RyWzY0XTsKKwljaGFyICoqZGlyOworCXVuc2lnbmVkIGludCBk
aXJfbiA9IDA7CisJdW5zaWduZWQgaW50IGRldmljZV9zdGF0ZTsKKwl1bnNpZ25lZCBpbnQgaHN0
LCBjaG4sIHRndCwgbHVuOworCXN0cnVjdCBzY3NpX2RldmljZSAqc2RldjsKKworCWRpciA9IHhl
bmJ1c19kaXJlY3RvcnkoWEJUX05JTCwgZGV2LT5vdGhlcmVuZCwgInZzY3NpLWRldnMiLCAmZGly
X24pOworCWlmIChJU19FUlIoZGlyKSkKKwkJcmV0dXJuOworCisJZm9yIChpID0gMDsgaSA8IGRp
cl9uOyBpKyspIHsKKwkJLyogcmVhZCBzdGF0dXMgKi8KKwkJc25wcmludGYoc3RyLCBzaXplb2Yo
c3RyKSwgInZzY3NpLWRldnMvJXMvc3RhdGUiLCBkaXJbaV0pOworCQllcnIgPSB4ZW5idXNfc2Nh
bmYoWEJUX05JTCwgZGV2LT5vdGhlcmVuZCwgc3RyLCAiJXUiLAorCQkJJmRldmljZV9zdGF0ZSk7
CisJCWlmIChYRU5CVVNfRVhJU1RfRVJSKGVycikpCisJCQljb250aW51ZTsKKworCQkvKiB2aXJ0
dWFsIFNDU0kgZGV2aWNlICovCisJCXNucHJpbnRmKHN0ciwgc2l6ZW9mKHN0ciksICJ2c2NzaS1k
ZXZzLyVzL3YtZGV2IiwgZGlyW2ldKTsKKwkJZXJyID0geGVuYnVzX3NjYW5mKFhCVF9OSUwsIGRl
di0+b3RoZXJlbmQsIHN0ciwKKwkJCSIldToldToldToldSIsICZoc3QsICZjaG4sICZ0Z3QsICZs
dW4pOworCQlpZiAoWEVOQlVTX0VYSVNUX0VSUihlcnIpKQorCQkJY29udGludWU7CisKKwkJLyog
ZnJvbnQgZGV2aWNlIHN0YXRlIHBhdGggKi8KKwkJc25wcmludGYoc3RhdGVfc3RyLCBzaXplb2Yo
c3RhdGVfc3RyKSwgInZzY3NpLWRldnMvJXMvc3RhdGUiLCBkaXJbaV0pOworCisJCXN3aXRjaCAo
b3ApIHsKKwkJY2FzZSBWU0NTSUZST05UX09QX0FERF9MVU46CisJCQlpZiAoZGV2aWNlX3N0YXRl
ID09IFhlbmJ1c1N0YXRlSW5pdGlhbGlzZWQpIHsKKwkJCQlzZGV2ID0gc2NzaV9kZXZpY2VfbG9v
a3VwKGluZm8tPmhvc3QsIGNobiwgdGd0LCBsdW4pOworCQkJCWlmIChzZGV2KSB7CisJCQkJCXBy
aW50ayhLRVJOX0VSUiAic2NzaWZyb250OiBEZXZpY2UgYWxyZWFkeSBpbiB1c2UuXG4iKTsKKwkJ
CQkJc2NzaV9kZXZpY2VfcHV0KHNkZXYpOworCQkJCQl4ZW5idXNfcHJpbnRmKFhCVF9OSUwsIGRl
di0+bm9kZW5hbWUsCisJCQkJCQlzdGF0ZV9zdHIsICIlZCIsIFhlbmJ1c1N0YXRlQ2xvc2VkKTsK
KwkJCQl9IGVsc2UgeworCQkJCQlzY3NpX2FkZF9kZXZpY2UoaW5mby0+aG9zdCwgY2huLCB0Z3Qs
IGx1bik7CisJCQkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2RlbmFtZSwKKwkJCQkJ
CXN0YXRlX3N0ciwgIiVkIiwgWGVuYnVzU3RhdGVDb25uZWN0ZWQpOworCQkJCX0KKwkJCX0KKwkJ
CWJyZWFrOworCQljYXNlIFZTQ1NJRlJPTlRfT1BfREVMX0xVTjoKKwkJCWlmIChkZXZpY2Vfc3Rh
dGUgPT0gWGVuYnVzU3RhdGVDbG9zaW5nKSB7CisJCQkJc2RldiA9IHNjc2lfZGV2aWNlX2xvb2t1
cChpbmZvLT5ob3N0LCBjaG4sIHRndCwgbHVuKTsKKwkJCQlpZiAoc2RldikgeworCQkJCQlzY3Np
X3JlbW92ZV9kZXZpY2Uoc2Rldik7CisJCQkJCXNjc2lfZGV2aWNlX3B1dChzZGV2KTsKKwkJCQkJ
eGVuYnVzX3ByaW50ZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLAorCQkJCQkJc3RhdGVfc3RyLCAi
JWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisJCWRlZmF1
bHQ6CisJCQlicmVhazsKKwkJfQorCX0KKworCWtmcmVlKGRpcik7CisJcmV0dXJuOworfQorCisK
KworCitzdGF0aWMgdm9pZCBzY3NpZnJvbnRfYmFja2VuZF9jaGFuZ2VkKHN0cnVjdCB4ZW5idXNf
ZGV2aWNlICpkZXYsCisJCQkJZW51bSB4ZW5idXNfc3RhdGUgYmFja2VuZF9zdGF0ZSkKK3sKKwlz
dHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPSBkZXZfZ2V0X2RydmRhdGEoJmRldi0+ZGV2KTsK
KworCURQUklOVEsoIiVwICV1ICV1XG4iLCBkZXYsIGRldi0+c3RhdGUsIGJhY2tlbmRfc3RhdGUp
OworCisJc3dpdGNoIChiYWNrZW5kX3N0YXRlKSB7CisJY2FzZSBYZW5idXNTdGF0ZVVua25vd246
CisJY2FzZSBYZW5idXNTdGF0ZUluaXRpYWxpc2luZzoKKwljYXNlIFhlbmJ1c1N0YXRlSW5pdFdh
aXQ6CisJY2FzZSBYZW5idXNTdGF0ZUNsb3NlZDoKKwkJYnJlYWs7CisKKwljYXNlIFhlbmJ1c1N0
YXRlSW5pdGlhbGlzZWQ6CisJCWJyZWFrOworCisJY2FzZSBYZW5idXNTdGF0ZUNvbm5lY3RlZDoK
KwkJaWYgKHhlbmJ1c19yZWFkX2RyaXZlcl9zdGF0ZShkZXYtPm5vZGVuYW1lKSA9PQorCQkJWGVu
YnVzU3RhdGVJbml0aWFsaXNlZCkgeworCQkJc2NzaWZyb250X2RvX2x1bl9ob3RwbHVnKGluZm8s
IFZTQ1NJRlJPTlRfT1BfQUREX0xVTik7CisJCX0KKworCQlpZiAoZGV2LT5zdGF0ZSA9PSBYZW5i
dXNTdGF0ZUNvbm5lY3RlZCkKKwkJCWJyZWFrOworCisJCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2
LCBYZW5idXNTdGF0ZUNvbm5lY3RlZCk7CisJCWJyZWFrOworCisJY2FzZSBYZW5idXNTdGF0ZUNs
b3Npbmc6CisJCXNjc2lmcm9udF9kaXNjb25uZWN0KGluZm8pOworCQlicmVhazsKKworCWNhc2Ug
WGVuYnVzU3RhdGVSZWNvbmZpZ3VyaW5nOgorCQlzY3NpZnJvbnRfZG9fbHVuX2hvdHBsdWcoaW5m
bywgVlNDU0lGUk9OVF9PUF9ERUxfTFVOKTsKKwkJeGVuYnVzX3N3aXRjaF9zdGF0ZShkZXYsIFhl
bmJ1c1N0YXRlUmVjb25maWd1cmluZyk7CisJCWJyZWFrOworCisJY2FzZSBYZW5idXNTdGF0ZVJl
Y29uZmlndXJlZDoKKwkJc2NzaWZyb250X2RvX2x1bl9ob3RwbHVnKGluZm8sIFZTQ1NJRlJPTlRf
T1BfQUREX0xVTik7CisJCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2LCBYZW5idXNTdGF0ZUNvbm5l
Y3RlZCk7CisJCWJyZWFrOworCX0KK30KKworCitzdGF0aWMgY29uc3Qgc3RydWN0IHhlbmJ1c19k
ZXZpY2VfaWQgc2NzaWZyb250X2lkc1tdID0geworCXsgInZzY3NpIiB9LAorCXsgIiIgfQorfTsK
K01PRFVMRV9BTElBUygieGVuOnZzY3NpIik7CisKK3N0YXRpYyBERUZJTkVfWEVOQlVTX0RSSVZF
UihzY3NpZnJvbnQsICwKKwkucHJvYmUJCQk9IHNjc2lmcm9udF9wcm9iZSwKKwkucmVtb3ZlCQkJ
PSBzY3NpZnJvbnRfcmVtb3ZlLAorLyogCS5yZXN1bWUJCQk9IHNjc2lmcm9udF9yZXN1bWUsICov
CisJLm90aGVyZW5kX2NoYW5nZWQJPSBzY3NpZnJvbnRfYmFja2VuZF9jaGFuZ2VkLAorKTsKKwor
aW50IHNjc2lmcm9udF94ZW5idXNfaW5pdCh2b2lkKQoreworCXJldHVybiB4ZW5idXNfcmVnaXN0
ZXJfZnJvbnRlbmQoJnNjc2lmcm9udF9kcml2ZXIpOworfQorCit2b2lkIHNjc2lmcm9udF94ZW5i
dXNfdW5yZWdpc3Rlcih2b2lkKQoreworCXhlbmJ1c191bnJlZ2lzdGVyX2RyaXZlcigmc2NzaWZy
b250X2RyaXZlcik7Cit9CisKZGlmZiAtcnVwTiB4ZW4vaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2dy
YW50X3RhYmxlLmggeGVuYy9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaAotLS0g
eGVuL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJsZS5oCTIwMTItMDItMjQgMTU6MTI6
NDYuNTQ1NjQ0OTY2IC0wNzAwCisrKyB4ZW5jL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90
YWJsZS5oCTIwMTItMDItMjQgMTU6MTk6MzUuMzM4OTc4Mjg1IC0wNzAwCkBAIC01MjAsNiArNTIw
LDggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2dldF92ZQogI2RlZmluZSBH
TlRTVF9wZXJtaXNzaW9uX2RlbmllZCAoLTgpIC8qIE5vdCBlbm91Z2ggcHJpdmlsZWdlIGZvciBv
cGVyYXRpb24uICAqLwogI2RlZmluZSBHTlRTVF9iYWRfcGFnZSAgICAgICAgICgtOSkgLyogU3Bl
Y2lmaWVkIHBhZ2Ugd2FzIGludmFsaWQgZm9yIG9wLiAgICAqLwogI2RlZmluZSBHTlRTVF9iYWRf
Y29weV9hcmcgICAgKC0xMCkgLyogY29weSBhcmd1bWVudHMgY3Jvc3MgcGFnZSBib3VuZGFyeSAq
LworI2RlZmluZSBHTlRTVF9hZGRyZXNzX3Rvb19iaWcgKC0xMSkgLyogdHJhbnNmZXIgcGFnZSBh
ZGRyZXNzIHRvbyBsYXJnZS4gICAgICAqLworI2RlZmluZSBHTlRTVF9lYWdhaW4gICAgICAgICAg
KC0xMikgLyogQ291bGQgbm90IG1hcCBhdCB0aGUgbW9tZW50LiBSZXRyeS4gICAqLwogCiAjZGVm
aW5lIEdOVFRBQk9QX2Vycm9yX21zZ3MgeyAgICAgICAgICAgICAgICAgICBcCiAgICAgIm9rYXki
LCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCkBAIC01MzMsNiArNTM1LDgg
QEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2dldF92ZQogICAgICJwZXJtaXNz
aW9uIGRlbmllZCIsICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICJiYWQgcGFnZSIsICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICJjb3B5IGFyZ3VtZW50cyBjcm9z
cyBwYWdlIGJvdW5kYXJ5IiAgICAgICAgXAorICAgICJwYWdlIGFkZHJlc3Mgc2l6ZSB0b28gbGFy
Z2UiLCAgICAgICAgICAgICAgXAorICAgICJjb3VsZCBub3QgbWFwIGF0IHRoZSBtb21lbnQsIHJl
dHJ5IiAgICAgICAgXAogfQogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX0dSQU5UX1RBQkxFX0hf
XyAqLwpkaWZmIC1ydXBOIHhlbi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaC5v
cmlnIHhlbmMvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2dyYW50X3RhYmxlLmgub3JpZwotLS0geGVu
L2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJsZS5oLm9yaWcJMTk2OS0xMi0zMSAxNzow
MDowMC4wMDAwMDAwMDAgLTA3MDAKKysrIHhlbmMvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2dyYW50
X3RhYmxlLmgub3JpZwkyMDEyLTAyLTI0IDE1OjEyOjQ2LjU0NTY0NDk2NiAtMDcwMApAQCAtMCww
ICsxLDUzOCBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogZ3JhbnRfdGFibGUuaAorICoK
KyAqIEludGVyZmFjZSBmb3IgZ3JhbnRpbmcgZm9yZWlnbiBhY2Nlc3MgdG8gcGFnZSBmcmFtZXMs
IGFuZCByZWNlaXZpbmcKKyAqIHBhZ2Utb3duZXJzaGlwIHRyYW5zZmVycy4KKyAqCisgKiBQZXJt
aXNzaW9uIGlzIGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBv
YnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0aGlzIHNvZnR3YXJlIGFuZCBhc3NvY2lhdGVkIGRvY3Vt
ZW50YXRpb24gZmlsZXMgKHRoZSAiU29mdHdhcmUiKSwgdG8KKyAqIGRlYWwgaW4gdGhlIFNvZnR3
YXJlIHdpdGhvdXQgcmVzdHJpY3Rpb24sIGluY2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhl
CisgKiByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmli
dXRlLCBzdWJsaWNlbnNlLCBhbmQvb3IKKyAqIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwg
YW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdob20gdGhlIFNvZnR3YXJlIGlzCisgKiBmdXJuaXNo
ZWQgdG8gZG8gc28sIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAq
IFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNo
YWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwgY29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25z
IG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElT
IiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwg
SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFC
SUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklO
R0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhP
TERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJ
TElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04gT0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNF
LCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZU
V0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSCisgKiBERUFMSU5HUyBJTiBUSEUgU09GVFdBUkUuCisg
KgorICogQ29weXJpZ2h0IChjKSAyMDA0LCBLIEEgRnJhc2VyCisgKi8KKworI2lmbmRlZiBfX1hF
Tl9QVUJMSUNfR1JBTlRfVEFCTEVfSF9fCisjZGVmaW5lIF9fWEVOX1BVQkxJQ19HUkFOVF9UQUJM
RV9IX18KKworI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UveGVuLmg+CisKKy8qKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKgorICogR1JBTlQgVEFCTEUgUkVQUkVTRU5UQVRJT04KKyAq
LworCisvKiBTb21lIHJvdWdoIGd1aWRlbGluZXMgb24gYWNjZXNzaW5nIGFuZCB1cGRhdGluZyBn
cmFudC10YWJsZSBlbnRyaWVzCisgKiBpbiBhIGNvbmN1cnJlbmN5LXNhZmUgbWFubmVyLiBGb3Ig
bW9yZSBpbmZvcm1hdGlvbiwgTGludXggY29udGFpbnMgYQorICogcmVmZXJlbmNlIGltcGxlbWVu
dGF0aW9uIGZvciBndWVzdCBPU2VzIChhcmNoL3hlbi9rZXJuZWwvZ3JhbnRfdGFibGUuYykuCisg
KgorICogTkIuIFdNQiBpcyBhIG5vLW9wIG9uIGN1cnJlbnQtZ2VuZXJhdGlvbiB4ODYgcHJvY2Vz
c29ycy4gSG93ZXZlciwgYQorICogICAgIGNvbXBpbGVyIGJhcnJpZXIgd2lsbCBzdGlsbCBiZSBy
ZXF1aXJlZC4KKyAqCisgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50
IHRhYmxlOgorICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCisgKiAgMi4gV3JpdGUgZW50LT5mcmFt
ZToKKyAqICAgICAgR1RGX3Blcm1pdF9hY2Nlc3M6ICAgRnJhbWUgdG8gd2hpY2ggYWNjZXNzIGlz
IHBlcm1pdHRlZC4KKyAqICAgICAgR1RGX2FjY2VwdF90cmFuc2ZlcjogUHNldWRvLXBoeXMgZnJh
bWUgc2xvdCBiZWluZyBmaWxsZWQgYnkgbmV3CisgKiAgICAgICAgICAgICAgICAgICAgICAgICAg
IGZyYW1lLCBvciB6ZXJvIGlmIG5vbmUuCisgKiAgMy4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdN
QikuCisgKiAgNC4gV3JpdGUgZW50LT5mbGFncywgaW5jLiB2YWxpZCB0eXBlLgorICoKKyAqIElu
dmFsaWRhdGluZyBhbiB1bnVzZWQgR1RGX3Blcm1pdF9hY2Nlc3MgZW50cnk6CisgKiAgMS4gZmxh
Z3MgPSBlbnQtPmZsYWdzLgorICogIDIuIE9ic2VydmUgdGhhdCAhKGZsYWdzICYgKEdURl9yZWFk
aW5nfEdURl93cml0aW5nKSkuCisgKiAgMy4gQ2hlY2sgcmVzdWx0IG9mIFNNUC1zYWZlIENNUFhD
SEcoJmVudC0+ZmxhZ3MsIGZsYWdzLCAwKS4KKyAqICBOQi4gTm8gbmVlZCBmb3IgV01CIGFzIHJl
dXNlIG9mIGVudHJ5IGlzIGNvbnRyb2wtZGVwZW5kZW50IG9uIHN1Y2Nlc3Mgb2YKKyAqICAgICAg
c3RlcCAzLCBhbmQgYWxsIGFyY2hpdGVjdHVyZXMgZ3VhcmFudGVlIG9yZGVyaW5nIG9mIGN0cmwt
ZGVwIHdyaXRlcy4KKyAqCisgKiBJbnZhbGlkYXRpbmcgYW4gaW4tdXNlIEdURl9wZXJtaXRfYWNj
ZXNzIGVudHJ5OgorICogIFRoaXMgY2Fubm90IGJlIGRvbmUgZGlyZWN0bHkuIFJlcXVlc3QgYXNz
aXN0YW5jZSBmcm9tIHRoZSBkb21haW4gY29udHJvbGxlcgorICogIHdoaWNoIGNhbiBzZXQgYSB0
aW1lb3V0IG9uIHRoZSB1c2Ugb2YgYSBncmFudCBlbnRyeSBhbmQgdGFrZSBuZWNlc3NhcnkKKyAq
ICBhY3Rpb24uIChOQi4gVGhpcyBpcyBub3QgeWV0IGltcGxlbWVudGVkISkuCisgKgorICogSW52
YWxpZGF0aW5nIGFuIHVudXNlZCBHVEZfYWNjZXB0X3RyYW5zZmVyIGVudHJ5OgorICogIDEuIGZs
YWdzID0gZW50LT5mbGFncy4KKyAqICAyLiBPYnNlcnZlIHRoYXQgIShmbGFncyAmIEdURl90cmFu
c2Zlcl9jb21taXR0ZWQpLiBbKl0KKyAqICAzLiBDaGVjayByZXN1bHQgb2YgU01QLXNhZmUgQ01Q
WENIRygmZW50LT5mbGFncywgZmxhZ3MsIDApLgorICogIE5CLiBObyBuZWVkIGZvciBXTUIgYXMg
cmV1c2Ugb2YgZW50cnkgaXMgY29udHJvbC1kZXBlbmRlbnQgb24gc3VjY2VzcyBvZgorICogICAg
ICBzdGVwIDMsIGFuZCBhbGwgYXJjaGl0ZWN0dXJlcyBndWFyYW50ZWUgb3JkZXJpbmcgb2YgY3Ry
bC1kZXAgd3JpdGVzLgorICogIFsqXSBJZiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkIGlzIHNldCB0
aGVuIHRoZSBncmFudCBlbnRyeSBpcyAnY29tbWl0dGVkJy4KKyAqICAgICAgVGhlIGd1ZXN0IG11
c3QgL25vdC8gbW9kaWZ5IHRoZSBncmFudCBlbnRyeSB1bnRpbCB0aGUgYWRkcmVzcyBvZiB0aGUK
KyAqICAgICAgdHJhbnNmZXJyZWQgZnJhbWUgaXMgd3JpdHRlbi4gSXQgaXMgc2FmZSBmb3IgdGhl
IGd1ZXN0IHRvIHNwaW4gd2FpdGluZworICogICAgICBmb3IgdGhpcyB0byBvY2N1ciAoZGV0ZWN0
IGJ5IG9ic2VydmluZyBHVEZfdHJhbnNmZXJfY29tcGxldGVkIGluCisgKiAgICAgIGVudC0+Zmxh
Z3MpLgorICoKKyAqIEludmFsaWRhdGluZyBhIGNvbW1pdHRlZCBHVEZfYWNjZXB0X3RyYW5zZmVy
IGVudHJ5OgorICogIDEuIFdhaXQgZm9yIChlbnQtPmZsYWdzICYgR1RGX3RyYW5zZmVyX2NvbXBs
ZXRlZCkuCisgKgorICogQ2hhbmdpbmcgYSBHVEZfcGVybWl0X2FjY2VzcyBmcm9tIHdyaXRhYmxl
IHRvIHJlYWQtb25seToKKyAqICBVc2UgU01QLXNhZmUgQ01QWENIRyB0byBzZXQgR1RGX3JlYWRv
bmx5LCB3aGlsZSBjaGVja2luZyAhR1RGX3dyaXRpbmcuCisgKgorICogQ2hhbmdpbmcgYSBHVEZf
cGVybWl0X2FjY2VzcyBmcm9tIHJlYWQtb25seSB0byB3cml0YWJsZToKKyAqICBVc2UgU01QLXNh
ZmUgYml0LXNldHRpbmcgaW5zdHJ1Y3Rpb24uCisgKi8KKworLyoKKyAqIFJlZmVyZW5jZSB0byBh
IGdyYW50IGVudHJ5IGluIGEgc3BlY2lmaWVkIGRvbWFpbidzIGdyYW50IHRhYmxlLgorICovCit0
eXBlZGVmIHVpbnQzMl90IGdyYW50X3JlZl90OworCisvKgorICogQSBncmFudCB0YWJsZSBjb21w
cmlzZXMgYSBwYWNrZWQgYXJyYXkgb2YgZ3JhbnQgZW50cmllcyBpbiBvbmUgb3IgbW9yZQorICog
cGFnZSBmcmFtZXMgc2hhcmVkIGJldHdlZW4gWGVuIGFuZCBhIGd1ZXN0LgorICogW1hFTl06IFRo
aXMgZmllbGQgaXMgd3JpdHRlbiBieSBYZW4gYW5kIHJlYWQgYnkgdGhlIHNoYXJpbmcgZ3Vlc3Qu
CisgKiBbR1NUXTogVGhpcyBmaWVsZCBpcyB3cml0dGVuIGJ5IHRoZSBndWVzdCBhbmQgcmVhZCBi
eSBYZW4uCisgKi8KKworLyoKKyAqIFZlcnNpb24gMSBvZiB0aGUgZ3JhbnQgdGFibGUgZW50cnkg
c3RydWN0dXJlIGlzIG1haW50YWluZWQgcHVyZWx5CisgKiBmb3IgYmFja3dhcmRzIGNvbXBhdGli
aWxpdHkuICBOZXcgZ3Vlc3RzIHNob3VsZCB1c2UgdmVyc2lvbiAyLgorICovCitzdHJ1Y3QgZ3Jh
bnRfZW50cnlfdjEgeworICAgIC8qIEdURl94eHg6IHZhcmlvdXMgdHlwZSBhbmQgZmxhZyBpbmZv
cm1hdGlvbi4gIFtYRU4sR1NUXSAqLworICAgIHVpbnQxNl90IGZsYWdzOworICAgIC8qIFRoZSBk
b21haW4gYmVpbmcgZ3JhbnRlZCBmb3JlaWduIHByaXZpbGVnZXMuIFtHU1RdICovCisgICAgZG9t
aWRfdCAgZG9taWQ7CisgICAgLyoKKyAgICAgKiBHVEZfcGVybWl0X2FjY2VzczogRnJhbWUgdGhh
dCBAZG9taWQgaXMgYWxsb3dlZCB0byBtYXAgYW5kIGFjY2Vzcy4gW0dTVF0KKyAgICAgKiBHVEZf
YWNjZXB0X3RyYW5zZmVyOiBGcmFtZSB3aG9zZSBvd25lcnNoaXAgdHJhbnNmZXJyZWQgYnkgQGRv
bWlkLiBbWEVOXQorICAgICAqLworICAgIHVpbnQzMl90IGZyYW1lOworfTsKKworLyoKKyAqIFR5
cGUgb2YgZ3JhbnQgZW50cnkuCisgKiAgR1RGX2ludmFsaWQ6IFRoaXMgZ3JhbnQgZW50cnkgZ3Jh
bnRzIG5vIHByaXZpbGVnZXMuCisgKiAgR1RGX3Blcm1pdF9hY2Nlc3M6IEFsbG93IEBkb21pZCB0
byBtYXAvYWNjZXNzIEBmcmFtZS4KKyAqICBHVEZfYWNjZXB0X3RyYW5zZmVyOiBBbGxvdyBAZG9t
aWQgdG8gdHJhbnNmZXIgb3duZXJzaGlwIG9mIG9uZSBwYWdlIGZyYW1lCisgKiAgICAgICAgICAg
ICAgICAgICAgICAgdG8gdGhpcyBndWVzdC4gWGVuIHdyaXRlcyB0aGUgcGFnZSBudW1iZXIgdG8g
QGZyYW1lLgorICogIEdURl90cmFuc2l0aXZlOiBBbGxvdyBAZG9taWQgdG8gdHJhbnNpdGl2ZWx5
IGFjY2VzcyBhIHN1YnJhbmdlIG9mCisgKiAgICAgICAgICAgICAgICAgIEB0cmFuc19ncmFudCBp
biBAdHJhbnNfZG9taWQuICBObyBtYXBwaW5ncyBhcmUgYWxsb3dlZC4KKyAqLworI2RlZmluZSBH
VEZfaW52YWxpZCAgICAgICAgICgwVTw8MCkKKyNkZWZpbmUgR1RGX3Blcm1pdF9hY2Nlc3MgICAo
MVU8PDApCisjZGVmaW5lIEdURl9hY2NlcHRfdHJhbnNmZXIgKDJVPDwwKQorI2RlZmluZSBHVEZf
dHJhbnNpdGl2ZSAgICAgICgzVTw8MCkKKyNkZWZpbmUgR1RGX3R5cGVfbWFzayAgICAgICAoM1U8
PDApCisKKy8qCisgKiBTdWJmbGFncyBmb3IgR1RGX3Blcm1pdF9hY2Nlc3MuCisgKiAgR1RGX3Jl
YWRvbmx5OiBSZXN0cmljdCBAZG9taWQgdG8gcmVhZC1vbmx5IG1hcHBpbmdzIGFuZCBhY2Nlc3Nl
cy4gW0dTVF0KKyAqICBHVEZfcmVhZGluZzogR3JhbnQgZW50cnkgaXMgY3VycmVudGx5IG1hcHBl
ZCBmb3IgcmVhZGluZyBieSBAZG9taWQuIFtYRU5dCisgKiAgR1RGX3dyaXRpbmc6IEdyYW50IGVu
dHJ5IGlzIGN1cnJlbnRseSBtYXBwZWQgZm9yIHdyaXRpbmcgYnkgQGRvbWlkLiBbWEVOXQorICog
IEdURl9zdWJfcGFnZTogR3JhbnQgYWNjZXNzIHRvIG9ubHkgYSBzdWJyYW5nZSBvZiB0aGUgcGFn
ZS4gIEBkb21pZAorICogICAgICAgICAgICAgICAgd2lsbCBvbmx5IGJlIGFsbG93ZWQgdG8gY29w
eSBmcm9tIHRoZSBncmFudCwgYW5kIG5vdAorICogICAgICAgICAgICAgICAgbWFwIGl0LiBbR1NU
XQorICovCisjZGVmaW5lIF9HVEZfcmVhZG9ubHkgICAgICAgKDIpCisjZGVmaW5lIEdURl9yZWFk
b25seSAgICAgICAgKDFVPDxfR1RGX3JlYWRvbmx5KQorI2RlZmluZSBfR1RGX3JlYWRpbmcgICAg
ICAgICgzKQorI2RlZmluZSBHVEZfcmVhZGluZyAgICAgICAgICgxVTw8X0dURl9yZWFkaW5nKQor
I2RlZmluZSBfR1RGX3dyaXRpbmcgICAgICAgICg0KQorI2RlZmluZSBHVEZfd3JpdGluZyAgICAg
ICAgICgxVTw8X0dURl93cml0aW5nKQorI2RlZmluZSBfR1RGX3N1Yl9wYWdlICAgICAgICg4KQor
I2RlZmluZSBHVEZfc3ViX3BhZ2UgICAgICAgICgxVTw8X0dURl9zdWJfcGFnZSkKKworLyoKKyAq
IFN1YmZsYWdzIGZvciBHVEZfYWNjZXB0X3RyYW5zZmVyOgorICogIEdURl90cmFuc2Zlcl9jb21t
aXR0ZWQ6IFhlbiBzZXRzIHRoaXMgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIGNvbW1pdHRl
ZAorICogICAgICB0byB0cmFuc2ZlcnJpbmcgb3duZXJzaGlwIG9mIGEgcGFnZSBmcmFtZS4gV2hl
biBhIGd1ZXN0IHNlZXMgdGhpcyBmbGFnCisgKiAgICAgIGl0IG11c3QgL25vdC8gbW9kaWZ5IHRo
ZSBncmFudCBlbnRyeSB1bnRpbCBHVEZfdHJhbnNmZXJfY29tcGxldGVkIGlzCisgKiAgICAgIHNl
dCBieSBYZW4uCisgKiAgR1RGX3RyYW5zZmVyX2NvbXBsZXRlZDogSXQgaXMgc2FmZSBmb3IgdGhl
IGd1ZXN0IHRvIHNwaW4td2FpdCBvbiB0aGlzIGZsYWcKKyAqICAgICAgYWZ0ZXIgcmVhZGluZyBH
VEZfdHJhbnNmZXJfY29tbWl0dGVkLiBYZW4gd2lsbCBhbHdheXMgd3JpdGUgdGhlIGZyYW1lCisg
KiAgICAgIGFkZHJlc3MsIGZvbGxvd2VkIGJ5IE9SaW5nIHRoaXMgZmxhZywgaW4gYSB0aW1lbHkg
bWFubmVyLgorICovCisjZGVmaW5lIF9HVEZfdHJhbnNmZXJfY29tbWl0dGVkICgyKQorI2RlZmlu
ZSBHVEZfdHJhbnNmZXJfY29tbWl0dGVkICAoMVU8PF9HVEZfdHJhbnNmZXJfY29tbWl0dGVkKQor
I2RlZmluZSBfR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCAoMykKKyNkZWZpbmUgR1RGX3RyYW5zZmVy
X2NvbXBsZXRlZCAgKDFVPDxfR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCkKKworLyoKKyAqIFZlcnNp
b24gMiBncmFudCB0YWJsZSBlbnRyaWVzLiAgVGhlc2UgZnVsZmlsIHRoZSBzYW1lIHJvbGUgYXMK
KyAqIHZlcnNpb24gMSBlbnRyaWVzLCBidXQgY2FuIHJlcHJlc2VudCBtb3JlIGNvbXBsaWNhdGVk
IG9wZXJhdGlvbnMuCisgKiBBbnkgZ2l2ZW4gZG9tYWluIHdpbGwgaGF2ZSBlaXRoZXIgYSB2ZXJz
aW9uIDEgb3IgYSB2ZXJzaW9uIDIgdGFibGUsCisgKiBhbmQgZXZlcnkgZW50cnkgaW4gdGhlIHRh
YmxlIHdpbGwgYmUgdGhlIHNhbWUgdmVyc2lvbi4KKyAqCisgKiBUaGUgaW50ZXJmYWNlIGJ5IHdo
aWNoIGRvbWFpbnMgdXNlIGdyYW50IHJlZmVyZW5jZXMgZG9lcyBub3QgZGVwZW5kCisgKiBvbiB0
aGUgZ3JhbnQgdGFibGUgdmVyc2lvbiBpbiB1c2UgYnkgdGhlIG90aGVyIGRvbWFpbi4KKyAqLwor
CisvKgorICogVmVyc2lvbiAxIGFuZCB2ZXJzaW9uIDIgZ3JhbnQgZW50cmllcyBzaGFyZSBhIGNv
bW1vbiBwcmVmaXguICBUaGUKKyAqIGZpZWxkcyBvZiB0aGUgcHJlZml4IGFyZSBkb2N1bWVudGVk
IGFzIHBhcnQgb2Ygc3RydWN0CisgKiBncmFudF9lbnRyeV92MS4KKyAqLworc3RydWN0IGdyYW50
X2VudHJ5X2hlYWRlciB7CisgICAgdWludDE2X3QgZmxhZ3M7CisgICAgZG9taWRfdCAgZG9taWQ7
Cit9OworCisvKgorICogVmVyc2lvbiAyIG9mIHRoZSBncmFudCBlbnRyeSBzdHJ1Y3R1cmUsIGhl
cmUgaXMgYW4gdW5pb24gYmVjYXVzZSB0aHJlZQorICogZGlmZmVyZW50IHR5cGVzIGFyZSBzdXBw
b3R0ZWQ6IGZ1bGxfcGFnZSwgc3ViX3BhZ2UgYW5kIHRyYW5zaXRpdmUuCisgKi8KK3VuaW9uIGdy
YW50X2VudHJ5X3YyIHsKKyAgICBzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIGhkcjsKKworICAg
IC8qCisgICAgICogVGhpcyBtZW1iZXIgaXMgdXNlZCBmb3IgVjEtc3R5bGUgZnVsbCBwYWdlIGdy
YW50cywgd2hlcmUgZWl0aGVyOgorICAgICAqCisgICAgICogLS0gaGRyLnR5cGUgaXMgR1RGX2Fj
Y2VwdF90cmFuc2Zlciwgb3IKKyAgICAgKiAtLSBoZHIudHlwZSBpcyBHVEZfcGVybWl0X2FjY2Vz
cyBhbmQgR1RGX3N1Yl9wYWdlIGlzIG5vdCBzZXQuCisgICAgICoKKyAgICAgKiBJbiB0aGF0IGNh
c2UsIHRoZSBmcmFtZSBmaWVsZCBoYXMgdGhlIHNhbWUgc2VtYW50aWNzIGFzIHRoZQorICAgICAq
IGZpZWxkIG9mIHRoZSBzYW1lIG5hbWUgaW4gdGhlIFYxIGVudHJ5IHN0cnVjdHVyZS4KKyAgICAg
Ki8KKyAgICBzdHJ1Y3QgeworCXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCXVpbnQz
Ml90IHBhZDA7CisJdWludDY0X3QgZnJhbWU7CisgICAgfSBmdWxsX3BhZ2U7CisKKyAgICAvKgor
ICAgICAqIElmIHRoZSBncmFudCB0eXBlIGlzIEdURl9ncmFudF9hY2Nlc3MgYW5kIEdURl9zdWJf
cGFnZSBpcyBzZXQsCisgICAgICogQGRvbWlkIGlzIGFsbG93ZWQgdG8gYWNjZXNzIGJ5dGVzIFtA
cGFnZV9vZmYsQHBhZ2Vfb2ZmK0BsZW5ndGgpCisgICAgICogaW4gZnJhbWUgQGZyYW1lLgorICAg
ICAqLworICAgIHN0cnVjdCB7CisJc3RydWN0IGdyYW50X2VudHJ5X2hlYWRlciBoZHI7CisJdWlu
dDE2X3QgcGFnZV9vZmY7CisJdWludDE2X3QgbGVuZ3RoOworCXVpbnQ2NF90IGZyYW1lOworICAg
IH0gc3ViX3BhZ2U7CisKKyAgICAvKgorICAgICAqIElmIHRoZSBncmFudCBpcyBHVEZfdHJhbnNp
dGl2ZSwgQGRvbWlkIGlzIGFsbG93ZWQgdG8gdXNlIHRoZQorICAgICAqIGdyYW50IEBncmVmIGlu
IGRvbWFpbiBAdHJhbnNfZG9taWQsIGFzIGlmIGl0IHdhcyB0aGUgbG9jYWwKKyAgICAgKiBkb21h
aW4uICBPYnZpb3VzbHksIHRoZSB0cmFuc2l0aXZlIGFjY2VzcyBtdXN0IGJlIGNvbXBhdGlibGUK
KyAgICAgKiB3aXRoIHRoZSBvcmlnaW5hbCBncmFudC4KKyAgICAgKi8KKyAgICBzdHJ1Y3Qgewor
CXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCWRvbWlkX3QgdHJhbnNfZG9taWQ7CisJ
dWludDE2X3QgcGFkMDsKKwlncmFudF9yZWZfdCBncmVmOworICAgIH0gdHJhbnNpdGl2ZTsKKwor
ICAgIHVpbnQzMl90IF9fc3BhY2VyWzRdOyAvKiBQYWQgdG8gYSBwb3dlciBvZiB0d28gKi8KK307
CisKK3R5cGVkZWYgdWludDE2X3QgZ3JhbnRfc3RhdHVzX3Q7CisKKy8qKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKgorICogR1JBTlQgVEFCTEUgUVVFUklFUyBBTkQgVVNFUworICov
CisKKy8qCisgKiBIYW5kbGUgdG8gdHJhY2sgYSBtYXBwaW5nIGNyZWF0ZWQgdmlhIGEgZ3JhbnQg
cmVmZXJlbmNlLgorICovCit0eXBlZGVmIHVpbnQzMl90IGdyYW50X2hhbmRsZV90OworCisvKgor
ICogR05UVEFCT1BfbWFwX2dyYW50X3JlZjogTWFwIHRoZSBncmFudCBlbnRyeSAoPGRvbT4sPHJl
Zj4pIGZvciBhY2Nlc3MKKyAqIGJ5IGRldmljZXMgYW5kL29yIGhvc3QgQ1BVcy4gSWYgc3VjY2Vz
c2Z1bCwgPGhhbmRsZT4gaXMgYSB0cmFja2luZyBudW1iZXIKKyAqIHRoYXQgbXVzdCBiZSBwcmVz
ZW50ZWQgbGF0ZXIgdG8gZGVzdHJveSB0aGUgbWFwcGluZyhzKS4gT24gZXJyb3IsIDxoYW5kbGU+
CisgKiBpcyBhIG5lZ2F0aXZlIHN0YXR1cyBjb2RlLgorICogTk9URVM6CisgKiAgMS4gSWYgR05U
TUFQX2RldmljZV9tYXAgaXMgc3BlY2lmaWVkIHRoZW4gPGRldl9idXNfYWRkcj4gaXMgdGhlIGFk
ZHJlc3MKKyAqICAgICB2aWEgd2hpY2ggSS9PIGRldmljZXMgbWF5IGFjY2VzcyB0aGUgZ3JhbnRl
ZCBmcmFtZS4KKyAqICAyLiBJZiBHTlRNQVBfaG9zdF9tYXAgaXMgc3BlY2lmaWVkIHRoZW4gYSBt
YXBwaW5nIHdpbGwgYmUgYWRkZWQgYXQKKyAqICAgICBlaXRoZXIgYSBob3N0IHZpcnR1YWwgYWRk
cmVzcyBpbiB0aGUgY3VycmVudCBhZGRyZXNzIHNwYWNlLCBvciBhdAorICogICAgIGEgUFRFIGF0
IHRoZSBzcGVjaWZpZWQgbWFjaGluZSBhZGRyZXNzLiAgVGhlIHR5cGUgb2YgbWFwcGluZyB0bwor
ICogICAgIHBlcmZvcm0gaXMgc2VsZWN0ZWQgdGhyb3VnaCB0aGUgR05UTUFQX2NvbnRhaW5zX3B0
ZSBmbGFnLCBhbmQgdGhlCisgKiAgICAgYWRkcmVzcyBpcyBzcGVjaWZpZWQgaW4gPGhvc3RfYWRk
cj4uCisgKiAgMy4gTWFwcGluZ3Mgc2hvdWxkIG9ubHkgYmUgZGVzdHJveWVkIHZpYSBHTlRUQUJP
UF91bm1hcF9ncmFudF9yZWYuIElmIGEKKyAqICAgICBob3N0IG1hcHBpbmcgaXMgZGVzdHJveWVk
IGJ5IG90aGVyIG1lYW5zIHRoZW4gaXQgaXMgKk5PVCogZ3VhcmFudGVlZAorICogICAgIHRvIGJl
IGFjY291bnRlZCB0byB0aGUgY29ycmVjdCBncmFudCByZWZlcmVuY2UhCisgKi8KKyNkZWZpbmUg
R05UVEFCT1BfbWFwX2dyYW50X3JlZiAgICAgICAgMAorc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRf
cmVmIHsKKyAgICAvKiBJTiBwYXJhbWV0ZXJzLiAqLworICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsK
KyAgICB1aW50MzJfdCBmbGFnczsgICAgICAgICAgICAgICAvKiBHTlRNQVBfKiAqLworICAgIGdy
YW50X3JlZl90IHJlZjsKKyAgICBkb21pZF90ICBkb207CisgICAgLyogT1VUIHBhcmFtZXRlcnMu
ICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLworICAg
IGdyYW50X2hhbmRsZV90IGhhbmRsZTsKKyAgICB1aW50NjRfdCBkZXZfYnVzX2FkZHI7Cit9Owor
REVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX21hcF9ncmFudF9yZWYpOworCisvKgor
ICogR05UVEFCT1BfdW5tYXBfZ3JhbnRfcmVmOiBEZXN0cm95IG9uZSBvciBtb3JlIGdyYW50LXJl
ZmVyZW5jZSBtYXBwaW5ncworICogdHJhY2tlZCBieSA8aGFuZGxlPi4gSWYgPGhvc3RfYWRkcj4g
b3IgPGRldl9idXNfYWRkcj4gaXMgemVybywgdGhhdAorICogZmllbGQgaXMgaWdub3JlZC4gSWYg
bm9uLXplcm8sIHRoZXkgbXVzdCByZWZlciB0byBhIGRldmljZS9ob3N0IG1hcHBpbmcKKyAqIHRo
YXQgaXMgdHJhY2tlZCBieSA8aGFuZGxlPgorICogTk9URVM6CisgKiAgMS4gVGhlIGNhbGwgbWF5
IGZhaWwgaW4gYW4gdW5kZWZpbmVkIG1hbm5lciBpZiBlaXRoZXIgbWFwcGluZyBpcyBub3QKKyAq
ICAgICB0cmFja2VkIGJ5IDxoYW5kbGU+LgorICogIDMuIEFmdGVyIGV4ZWN1dGluZyBhIGJhdGNo
IG9mIHVubWFwcywgaXQgaXMgZ3VhcmFudGVlZCB0aGF0IG5vIHN0YWxlCisgKiAgICAgbWFwcGlu
Z3Mgd2lsbCByZW1haW4gaW4gdGhlIGRldmljZSBvciBob3N0IFRMQnMuCisgKi8KKyNkZWZpbmUg
R05UVEFCT1BfdW5tYXBfZ3JhbnRfcmVmICAgICAgMQorc3RydWN0IGdudHRhYl91bm1hcF9ncmFu
dF9yZWYgeworICAgIC8qIElOIHBhcmFtZXRlcnMuICovCisgICAgdWludDY0X3QgaG9zdF9hZGRy
OworICAgIHVpbnQ2NF90IGRldl9idXNfYWRkcjsKKyAgICBncmFudF9oYW5kbGVfdCBoYW5kbGU7
CisgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAg
ICAgICAgLyogR05UU1RfKiAqLworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRh
Yl91bm1hcF9ncmFudF9yZWYpOworCisvKgorICogR05UVEFCT1Bfc2V0dXBfdGFibGU6IFNldCB1
cCBhIGdyYW50IHRhYmxlIGZvciA8ZG9tPiBjb21wcmlzaW5nIGF0IGxlYXN0CisgKiA8bnJfZnJh
bWVzPiBwYWdlcy4gVGhlIGZyYW1lIGFkZHJlc3NlcyBhcmUgd3JpdHRlbiB0byB0aGUgPGZyYW1l
X2xpc3Q+LgorICogT25seSA8bnJfZnJhbWVzPiBhZGRyZXNzZXMgYXJlIHdyaXR0ZW4sIGV2ZW4g
aWYgdGhlIHRhYmxlIGlzIGxhcmdlci4KKyAqIE5PVEVTOgorICogIDEuIDxkb20+IG1heSBiZSBz
cGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KKyAqICAyLiBPbmx5IGEgc3VmZmljaWVudGx5LXByaXZp
bGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NFTEYuCisgKiAgMy4gWGVu
IG1heSBub3Qgc3VwcG9ydCBtb3JlIHRoYW4gYSBzaW5nbGUgZ3JhbnQtdGFibGUgcGFnZSBwZXIg
ZG9tYWluLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3NldHVwX3RhYmxlICAgICAgICAgIDIKK3N0
cnVjdCBnbnR0YWJfc2V0dXBfdGFibGUgeworICAgIC8qIElOIHBhcmFtZXRlcnMuICovCisgICAg
ZG9taWRfdCAgZG9tOworICAgIHVpbnQzMl90IG5yX2ZyYW1lczsKKyAgICAvKiBPVVQgcGFyYW1l
dGVycy4gKi8KKyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAgICAvKiBHTlRTVF8qICov
CisgICAgR1VFU1RfSEFORExFKHVsb25nKSBmcmFtZV9saXN0OworfTsKK0RFRklORV9HVUVTVF9I
QU5ETEVfU1RSVUNUKGdudHRhYl9zZXR1cF90YWJsZSk7CisKKy8qCisgKiBHTlRUQUJPUF9kdW1w
X3RhYmxlOiBEdW1wIHRoZSBjb250ZW50cyBvZiB0aGUgZ3JhbnQgdGFibGUgdG8gdGhlCisgKiB4
ZW4gY29uc29sZS4gRGVidWdnaW5nIHVzZSBvbmx5LgorICovCisjZGVmaW5lIEdOVFRBQk9QX2R1
bXBfdGFibGUgICAgICAgICAgIDMKK3N0cnVjdCBnbnR0YWJfZHVtcF90YWJsZSB7CisgICAgLyog
SU4gcGFyYW1ldGVycy4gKi8KKyAgICBkb21pZF90IGRvbTsKKyAgICAvKiBPVVQgcGFyYW1ldGVy
cy4gKi8KKyAgICBpbnQxNl90IHN0YXR1czsgICAgICAgICAgICAgICAvKiBHTlRTVF8qICovCit9
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2R1bXBfdGFibGUpOworCisvKgor
ICogR05UVEFCT1BfdHJhbnNmZXJfZ3JhbnRfcmVmOiBUcmFuc2ZlciA8ZnJhbWU+IHRvIGEgZm9y
ZWlnbiBkb21haW4uIFRoZQorICogZm9yZWlnbiBkb21haW4gaGFzIHByZXZpb3VzbHkgcmVnaXN0
ZXJlZCBpdHMgaW50ZXJlc3QgaW4gdGhlIHRyYW5zZmVyIHZpYQorICogPGRvbWlkLCByZWY+Lgor
ICoKKyAqIE5vdGUgdGhhdCwgZXZlbiBpZiB0aGUgdHJhbnNmZXIgZmFpbHMsIHRoZSBzcGVjaWZp
ZWQgcGFnZSBubyBsb25nZXIgYmVsb25ncworICogdG8gdGhlIGNhbGxpbmcgZG9tYWluICp1bmxl
c3MqIHRoZSBlcnJvciBpcyBHTlRTVF9iYWRfcGFnZS4KKyAqLworI2RlZmluZSBHTlRUQUJPUF90
cmFuc2ZlciAgICAgICAgICAgICAgICA0CitzdHJ1Y3QgZ250dGFiX3RyYW5zZmVyIHsKKyAgICAv
KiBJTiBwYXJhbWV0ZXJzLiAqLworICAgIHVuc2lnbmVkIGxvbmcgbWZuOworICAgIGRvbWlkX3Qg
ICAgICAgZG9taWQ7CisgICAgZ3JhbnRfcmVmX3QgICByZWY7CisgICAgLyogT1VUIHBhcmFtZXRl
cnMuICovCisgICAgaW50MTZfdCAgICAgICBzdGF0dXM7Cit9OworREVGSU5FX0dVRVNUX0hBTkRM
RV9TVFJVQ1QoZ250dGFiX3RyYW5zZmVyKTsKKworLyoKKyAqIEdOVFRBQk9QX2NvcHk6IEh5cGVy
dmlzb3IgYmFzZWQgY29weQorICogc291cmNlIGFuZCBkZXN0aW5hdGlvbnMgY2FuIGJlIGVpdGhl
cnMgTUZOcyBvciwgZm9yIGZvcmVpZ24gZG9tYWlucywKKyAqIGdyYW50IHJlZmVyZW5jZXMuIHRo
ZSBmb3JlaWduIGRvbWFpbiBoYXMgdG8gZ3JhbnQgcmVhZC93cml0ZSBhY2Nlc3MKKyAqIGluIGl0
cyBncmFudCB0YWJsZS4KKyAqCisgKiBUaGUgZmxhZ3Mgc3BlY2lmeSB3aGF0IHR5cGUgc291cmNl
IGFuZCBkZXN0aW5hdGlvbnMgYXJlIChlaXRoZXIgTUZOCisgKiBvciBncmFudCByZWZlcmVuY2Up
LgorICoKKyAqIE5vdGUgdGhhdCB0aGlzIGNhbiBhbHNvIGJlIHVzZWQgdG8gY29weSBkYXRhIGJl
dHdlZW4gdHdvIGRvbWFpbnMKKyAqIHZpYSBhIHRoaXJkIHBhcnR5IGlmIHRoZSBzb3VyY2UgYW5k
IGRlc3RpbmF0aW9uIGRvbWFpbnMgaGFkIHByZXZpb3VzbHkKKyAqIGdyYW50IGFwcHJvcHJpYXRl
IGFjY2VzcyB0byB0aGVpciBwYWdlcyB0byB0aGUgdGhpcmQgcGFydHkuCisgKgorICogc291cmNl
X29mZnNldCBzcGVjaWZpZXMgYW4gb2Zmc2V0IGluIHRoZSBzb3VyY2UgZnJhbWUsIGRlc3Rfb2Zm
c2V0CisgKiB0aGUgb2Zmc2V0IGluIHRoZSB0YXJnZXQgZnJhbWUgYW5kICBsZW4gc3BlY2lmaWVz
IHRoZSBudW1iZXIgb2YKKyAqIGJ5dGVzIHRvIGJlIGNvcGllZC4KKyAqLworCisjZGVmaW5lIF9H
TlRDT1BZX3NvdXJjZV9ncmVmICAgICAgKDApCisjZGVmaW5lIEdOVENPUFlfc291cmNlX2dyZWYg
ICAgICAgKDE8PF9HTlRDT1BZX3NvdXJjZV9ncmVmKQorI2RlZmluZSBfR05UQ09QWV9kZXN0X2dy
ZWYgICAgICAgICgxKQorI2RlZmluZSBHTlRDT1BZX2Rlc3RfZ3JlZiAgICAgICAgICgxPDxfR05U
Q09QWV9kZXN0X2dyZWYpCisKKyNkZWZpbmUgR05UVEFCT1BfY29weSAgICAgICAgICAgICAgICAg
NQorc3RydWN0IGdudHRhYl9jb3B5IHsKKwkvKiBJTiBwYXJhbWV0ZXJzLiAqLworCXN0cnVjdCB7
CisJCXVuaW9uIHsKKwkJCWdyYW50X3JlZl90IHJlZjsKKwkJCXVuc2lnbmVkIGxvbmcgICBnbWZu
OworCQl9IHU7CisJCWRvbWlkX3QgIGRvbWlkOworCQl1aW50MTZfdCBvZmZzZXQ7CisJfSBzb3Vy
Y2UsIGRlc3Q7CisJdWludDE2X3QgICAgICBsZW47CisJdWludDE2X3QgICAgICBmbGFnczsgICAg
ICAgICAgLyogR05UQ09QWV8qICovCisJLyogT1VUIHBhcmFtZXRlcnMuICovCisJaW50MTZfdCAg
ICAgICBzdGF0dXM7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2NvcHkp
OworCisvKgorICogR05UVEFCT1BfcXVlcnlfc2l6ZTogUXVlcnkgdGhlIGN1cnJlbnQgYW5kIG1h
eGltdW0gc2l6ZXMgb2YgdGhlIHNoYXJlZAorICogZ3JhbnQgdGFibGUuCisgKiBOT1RFUzoKKyAq
ICAxLiA8ZG9tPiBtYXkgYmUgc3BlY2lmaWVkIGFzIERPTUlEX1NFTEYuCisgKiAgMi4gT25seSBh
IHN1ZmZpY2llbnRseS1wcml2aWxlZ2VkIGRvbWFpbiBtYXkgc3BlY2lmeSA8ZG9tPiAhPSBET01J
RF9TRUxGLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3F1ZXJ5X3NpemUgICAgICAgICAgIDYKK3N0
cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSB7CisgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICBk
b21pZF90ICBkb207CisgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCisgICAgdWludDMyX3QgbnJf
ZnJhbWVzOworICAgIHVpbnQzMl90IG1heF9ucl9mcmFtZXM7CisgICAgaW50MTZfdCAgc3RhdHVz
OyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RS
VUNUKGdudHRhYl9xdWVyeV9zaXplKTsKKworLyoKKyAqIEdOVFRBQk9QX3VubWFwX2FuZF9yZXBs
YWNlOiBEZXN0cm95IG9uZSBvciBtb3JlIGdyYW50LXJlZmVyZW5jZSBtYXBwaW5ncworICogdHJh
Y2tlZCBieSA8aGFuZGxlPiBidXQgYXRvbWljYWxseSByZXBsYWNlIHRoZSBwYWdlIHRhYmxlIGVu
dHJ5IHdpdGggb25lCisgKiBwb2ludGluZyB0byB0aGUgbWFjaGluZSBhZGRyZXNzIHVuZGVyIDxu
ZXdfYWRkcj4uICA8bmV3X2FkZHI+IHdpbGwgYmUKKyAqIHJlZGlyZWN0ZWQgdG8gdGhlIG51bGwg
ZW50cnkuCisgKiBOT1RFUzoKKyAqICAxLiBUaGUgY2FsbCBtYXkgZmFpbCBpbiBhbiB1bmRlZmlu
ZWQgbWFubmVyIGlmIGVpdGhlciBtYXBwaW5nIGlzIG5vdAorICogICAgIHRyYWNrZWQgYnkgPGhh
bmRsZT4uCisgKiAgMi4gQWZ0ZXIgZXhlY3V0aW5nIGEgYmF0Y2ggb2YgdW5tYXBzLCBpdCBpcyBn
dWFyYW50ZWVkIHRoYXQgbm8gc3RhbGUKKyAqICAgICBtYXBwaW5ncyB3aWxsIHJlbWFpbiBpbiB0
aGUgZGV2aWNlIG9yIGhvc3QgVExCcy4KKyAqLworI2RlZmluZSBHTlRUQUJPUF91bm1hcF9hbmRf
cmVwbGFjZSAgICA3CitzdHJ1Y3QgZ250dGFiX3VubWFwX2FuZF9yZXBsYWNlIHsKKyAgICAvKiBJ
TiBwYXJhbWV0ZXJzLiAqLworICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsKKyAgICB1aW50NjRfdCBu
ZXdfYWRkcjsKKyAgICBncmFudF9oYW5kbGVfdCBoYW5kbGU7CisgICAgLyogT1VUIHBhcmFtZXRl
cnMuICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLwor
fTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl91bm1hcF9hbmRfcmVwbGFjZSk7
CisKKy8qCisgKiBHTlRUQUJPUF9zZXRfdmVyc2lvbjogUmVxdWVzdCBhIHBhcnRpY3VsYXIgdmVy
c2lvbiBvZiB0aGUgZ3JhbnQKKyAqIHRhYmxlIHNoYXJlZCB0YWJsZSBzdHJ1Y3R1cmUuICBUaGlz
IG9wZXJhdGlvbiBjYW4gb25seSBiZSBwZXJmb3JtZWQKKyAqIG9uY2UgaW4gYW55IGdpdmVuIGRv
bWFpbi4gIEl0IG11c3QgYmUgcGVyZm9ybWVkIGJlZm9yZSBhbnkgZ3JhbnRzCisgKiBhcmUgYWN0
aXZhdGVkOyBvdGhlcndpc2UsIHRoZSBkb21haW4gd2lsbCBiZSBzdHVjayB3aXRoIHZlcnNpb24g
MS4KKyAqIFRoZSBvbmx5IGRlZmluZWQgdmVyc2lvbnMgYXJlIDEgYW5kIDIuCisgKi8KKyNkZWZp
bmUgR05UVEFCT1Bfc2V0X3ZlcnNpb24gICAgICAgICAgOAorc3RydWN0IGdudHRhYl9zZXRfdmVy
c2lvbiB7CisgICAgLyogSU4gcGFyYW1ldGVycyAqLworICAgIHVpbnQzMl90IHZlcnNpb247Cit9
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX3NldF92ZXJzaW9uKTsKKworLyoK
KyAqIEdOVFRBQk9QX2dldF9zdGF0dXNfZnJhbWVzOiBHZXQgdGhlIGxpc3Qgb2YgZnJhbWVzIHVz
ZWQgdG8gc3RvcmUgZ3JhbnQKKyAqIHN0YXR1cyBmb3IgPGRvbT4uIEluIGdyYW50IGZvcm1hdCB2
ZXJzaW9uIDIsIHRoZSBzdGF0dXMgaXMgc2VwYXJhdGVkCisgKiBmcm9tIHRoZSBvdGhlciBzaGFy
ZWQgZ3JhbnQgZmllbGRzIHRvIGFsbG93IG1vcmUgZWZmaWNpZW50IHN5bmNocm9uaXphdGlvbgor
ICogdXNpbmcgYmFycmllcnMgaW5zdGVhZCBvZiBhdG9taWMgY21wZXhjaCBvcGVyYXRpb25zLgor
ICogPG5yX2ZyYW1lcz4gc3BlY2lmeSB0aGUgc2l6ZSBvZiB2ZWN0b3IgPGZyYW1lX2xpc3Q+Lgor
ICogVGhlIGZyYW1lIGFkZHJlc3NlcyBhcmUgcmV0dXJuZWQgaW4gdGhlIDxmcmFtZV9saXN0Pi4K
KyAqIE9ubHkgPG5yX2ZyYW1lcz4gYWRkcmVzc2VzIGFyZSByZXR1cm5lZCwgZXZlbiBpZiB0aGUg
dGFibGUgaXMgbGFyZ2VyLgorICogTk9URVM6CisgKiAgMS4gPGRvbT4gbWF5IGJlIHNwZWNpZmll
ZCBhcyBET01JRF9TRUxGLgorICogIDIuIE9ubHkgYSBzdWZmaWNpZW50bHktcHJpdmlsZWdlZCBk
b21haW4gbWF5IHNwZWNpZnkgPGRvbT4gIT0gRE9NSURfU0VMRi4KKyAqLworI2RlZmluZSBHTlRU
QUJPUF9nZXRfc3RhdHVzX2ZyYW1lcyAgICAgOQorc3RydWN0IGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lcyB7CisgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICB1aW50MzJfdCBucl9mcmFtZXM7
CisgICAgZG9taWRfdCAgZG9tOworICAgIC8qIE9VVCBwYXJhbWV0ZXJzLiAqLworICAgIGludDE2
X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8qIEdOVFNUXyogKi8KKyAgICBHVUVTVF9IQU5ETEUo
dWludDY0X3QpIGZyYW1lX2xpc3Q7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250
dGFiX2dldF9zdGF0dXNfZnJhbWVzKTsKKworLyoKKyAqIEdOVFRBQk9QX2dldF92ZXJzaW9uOiBH
ZXQgdGhlIGdyYW50IHRhYmxlIHZlcnNpb24gd2hpY2ggaXMgaW4KKyAqIGVmZmVjdCBmb3IgZG9t
YWluIDxkb20+LgorICovCisjZGVmaW5lIEdOVFRBQk9QX2dldF92ZXJzaW9uICAgICAgICAgIDEw
CitzdHJ1Y3QgZ250dGFiX2dldF92ZXJzaW9uIHsKKyAgICAvKiBJTiBwYXJhbWV0ZXJzICovCisg
ICAgZG9taWRfdCBkb207CisgICAgdWludDE2X3QgcGFkOworICAgIC8qIE9VVCBwYXJhbWV0ZXJz
ICovCisgICAgdWludDMyX3QgdmVyc2lvbjsKK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVD
VChnbnR0YWJfZ2V0X3ZlcnNpb24pOworCisvKgorICogQml0ZmllbGQgdmFsdWVzIGZvciB1cGRh
dGVfcGluX3N0YXR1cy5mbGFncy4KKyAqLworIC8qIE1hcCB0aGUgZ3JhbnQgZW50cnkgZm9yIGFj
Y2VzcyBieSBJL08gZGV2aWNlcy4gKi8KKyNkZWZpbmUgX0dOVE1BUF9kZXZpY2VfbWFwICAgICAg
KDApCisjZGVmaW5lIEdOVE1BUF9kZXZpY2VfbWFwICAgICAgICgxPDxfR05UTUFQX2RldmljZV9t
YXApCisgLyogTWFwIHRoZSBncmFudCBlbnRyeSBmb3IgYWNjZXNzIGJ5IGhvc3QgQ1BVcy4gKi8K
KyNkZWZpbmUgX0dOVE1BUF9ob3N0X21hcCAgICAgICAgKDEpCisjZGVmaW5lIEdOVE1BUF9ob3N0
X21hcCAgICAgICAgICgxPDxfR05UTUFQX2hvc3RfbWFwKQorIC8qIEFjY2Vzc2VzIHRvIHRoZSBn
cmFudGVkIGZyYW1lIHdpbGwgYmUgcmVzdHJpY3RlZCB0byByZWFkLW9ubHkgYWNjZXNzLiAqLwor
I2RlZmluZSBfR05UTUFQX3JlYWRvbmx5ICAgICAgICAoMikKKyNkZWZpbmUgR05UTUFQX3JlYWRv
bmx5ICAgICAgICAgKDE8PF9HTlRNQVBfcmVhZG9ubHkpCisgLyoKKyAgKiBHTlRNQVBfaG9zdF9t
YXAgc3ViZmxhZzoKKyAgKiAgMCA9PiBUaGUgaG9zdCBtYXBwaW5nIGlzIHVzYWJsZSBvbmx5IGJ5
IHRoZSBndWVzdCBPUy4KKyAgKiAgMSA9PiBUaGUgaG9zdCBtYXBwaW5nIGlzIHVzYWJsZSBieSBn
dWVzdCBPUyArIGN1cnJlbnQgYXBwbGljYXRpb24uCisgICovCisjZGVmaW5lIF9HTlRNQVBfYXBw
bGljYXRpb25fbWFwICgzKQorI2RlZmluZSBHTlRNQVBfYXBwbGljYXRpb25fbWFwICAoMTw8X0dO
VE1BUF9hcHBsaWNhdGlvbl9tYXApCisKKyAvKgorICAqIEdOVE1BUF9jb250YWluc19wdGUgc3Vi
ZmxhZzoKKyAgKiAgMCA9PiBUaGlzIG1hcCByZXF1ZXN0IGNvbnRhaW5zIGEgaG9zdCB2aXJ0dWFs
IGFkZHJlc3MuCisgICogIDEgPT4gVGhpcyBtYXAgcmVxdWVzdCBjb250YWlucyB0aGUgbWFjaGlu
ZSBhZGRlc3Mgb2YgdGhlIFBURSB0byB1cGRhdGUuCisgICovCisjZGVmaW5lIF9HTlRNQVBfY29u
dGFpbnNfcHRlICAgICg0KQorI2RlZmluZSBHTlRNQVBfY29udGFpbnNfcHRlICAgICAoMTw8X0dO
VE1BUF9jb250YWluc19wdGUpCisKKy8qCisgKiBWYWx1ZXMgZm9yIGVycm9yIHN0YXR1cyByZXR1
cm5zLiBBbGwgZXJyb3JzIGFyZSAtdmUuCisgKi8KKyNkZWZpbmUgR05UU1Rfb2theSAgICAgICAg
ICAgICAoMCkgIC8qIE5vcm1hbCByZXR1cm4uICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNk
ZWZpbmUgR05UU1RfZ2VuZXJhbF9lcnJvciAgICAoLTEpIC8qIEdlbmVyYWwgdW5kZWZpbmVkIGVy
cm9yLiAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgR05UU1RfYmFkX2RvbWFpbiAgICAgICAoLTIp
IC8qIFVucmVjb2duc2VkIGRvbWFpbiBpZC4gICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgR05U
U1RfYmFkX2dudHJlZiAgICAgICAoLTMpIC8qIFVucmVjb2duaXNlZCBvciBpbmFwcHJvcHJpYXRl
IGdudHJlZi4gKi8KKyNkZWZpbmUgR05UU1RfYmFkX2hhbmRsZSAgICAgICAoLTQpIC8qIFVucmVj
b2duaXNlZCBvciBpbmFwcHJvcHJpYXRlIGhhbmRsZS4gKi8KKyNkZWZpbmUgR05UU1RfYmFkX3Zp
cnRfYWRkciAgICAoLTUpIC8qIEluYXBwcm9wcmlhdGUgdmlydHVhbCBhZGRyZXNzIHRvIG1hcC4g
Ki8KKyNkZWZpbmUgR05UU1RfYmFkX2Rldl9hZGRyICAgICAoLTYpIC8qIEluYXBwcm9wcmlhdGUg
ZGV2aWNlIGFkZHJlc3MgdG8gdW5tYXAuKi8KKyNkZWZpbmUgR05UU1Rfbm9fZGV2aWNlX3NwYWNl
ICAoLTcpIC8qIE91dCBvZiBzcGFjZSBpbiBJL08gTU1VLiAgICAgICAgICAgICAgKi8KKyNkZWZp
bmUgR05UU1RfcGVybWlzc2lvbl9kZW5pZWQgKC04KSAvKiBOb3QgZW5vdWdoIHByaXZpbGVnZSBm
b3Igb3BlcmF0aW9uLiAgKi8KKyNkZWZpbmUgR05UU1RfYmFkX3BhZ2UgICAgICAgICAoLTkpIC8q
IFNwZWNpZmllZCBwYWdlIHdhcyBpbnZhbGlkIGZvciBvcC4gICAgKi8KKyNkZWZpbmUgR05UU1Rf
YmFkX2NvcHlfYXJnICAgICgtMTApIC8qIGNvcHkgYXJndW1lbnRzIGNyb3NzIHBhZ2UgYm91bmRh
cnkgKi8KKworI2RlZmluZSBHTlRUQUJPUF9lcnJvcl9tc2dzIHsgICAgICAgICAgICAgICAgICAg
XAorICAgICJva2F5IiwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICJ1bmRlZmluZWQgZXJyb3IiLCAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICJ1bnJl
Y29nbmlzZWQgZG9tYWluIGlkIiwgICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIGdy
YW50IHJlZmVyZW5jZSIsICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIG1hcHBpbmcg
aGFuZGxlIiwgICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIHZpcnR1YWwgYWRkcmVz
cyIsICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIGRldmljZSBhZGRyZXNzIiwgICAg
ICAgICAgICAgICAgICAgXAorICAgICJubyBzcGFyZSB0cmFuc2xhdGlvbiBzbG90IGluIHRoZSBJ
L08gTU1VIiwgXAorICAgICJwZXJtaXNzaW9uIGRlbmllZCIsICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgICJiYWQgcGFnZSIsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICJjb3B5IGFyZ3VtZW50cyBjcm9zcyBwYWdlIGJvdW5kYXJ5IiAgICAgICAgXAorfQorCisj
ZW5kaWYgLyogX19YRU5fUFVCTElDX0dSQU5UX1RBQkxFX0hfXyAqLwpkaWZmIC1ydXBOIHhlbi9p
bmNsdWRlL3hlbi9pbnRlcmZhY2UvaW8vdnNjc2lpZi5oIHhlbmMvaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL2lvL3ZzY3NpaWYuaAotLS0geGVuL2luY2x1ZGUveGVuL2ludGVyZmFjZS9pby92c2NzaWlm
LmgJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3MDAKKysrIHhlbmMvaW5jbHVkZS94
ZW4vaW50ZXJmYWNlL2lvL3ZzY3NpaWYuaAkyMDEyLTAyLTI0IDE1OjE5OjM1LjMzODk3ODI4NSAt
MDcwMApAQCAtMCwwICsxLDEwNSBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogdnNjc2lp
Zi5oCisgKgorICogQmFzZWQgb24gdGhlIGJsa2lmLmggY29kZS4KKyAqCisgKiBQZXJtaXNzaW9u
IGlzIGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5p
bmcgYSBjb3B5CisgKiBvZiB0aGlzIHNvZnR3YXJlIGFuZCBhc3NvY2lhdGVkIGRvY3VtZW50YXRp
b24gZmlsZXMgKHRoZSAiU29mdHdhcmUiKSwgdG8KKyAqIGRlYWwgaW4gdGhlIFNvZnR3YXJlIHdp
dGhvdXQgcmVzdHJpY3Rpb24sIGluY2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlCisgKiBy
aWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBz
dWJsaWNlbnNlLCBhbmQvb3IKKyAqIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwgYW5kIHRv
IHBlcm1pdCBwZXJzb25zIHRvIHdob20gdGhlIFNvZnR3YXJlIGlzCisgKiBmdXJuaXNoZWQgdG8g
ZG8gc28sIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBh
Ym92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJl
IGluY2x1ZGVkIGluCisgKiBhbGwgY29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRo
ZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lU
SE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVE
SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFks
CisgKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5U
LiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMg
QkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwg
V0hFVEhFUiBJTiBBTiBBQ1RJT04gT0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklT
SU5HCisgKiBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBP
UiBUSEUgVVNFIE9SIE9USEVSCisgKiBERUFMSU5HUyBJTiBUSEUgU09GVFdBUkUuCisgKgorICog
Q29weXJpZ2h0KGMpIEZVSklUU1UgTGltaXRlZCAyMDA4LgorICovCisKKyNpZm5kZWYgX19YRU5f
X1BVQkxJQ19JT19TQ1NJX0hfXworI2RlZmluZSBfX1hFTl9fUFVCTElDX0lPX1NDU0lfSF9fCisK
KyNpbmNsdWRlICJyaW5nLmgiCisjaW5jbHVkZSAiLi4vZ3JhbnRfdGFibGUuaCIKKworLyogY29t
bWFuZCBiZXR3ZWVuIGJhY2tlbmQgYW5kIGZyb250ZW5kICovCisjZGVmaW5lIFZTQ1NJSUZfQUNU
X1NDU0lfQ0RCICAgICAgICAgMSAgICAvKiBTQ1NJIENEQiBjb21tYW5kICovCisjZGVmaW5lIFZT
Q1NJSUZfQUNUX1NDU0lfQUJPUlQgICAgICAgMiAgICAvKiBTQ1NJIERldmljZShMdW4pIEFib3J0
Ki8KKyNkZWZpbmUgVlNDU0lJRl9BQ1RfU0NTSV9SRVNFVCAgICAgICAzICAgIC8qIFNDU0kgRGV2
aWNlKEx1bikgUmVzZXQqLworCisKKyNkZWZpbmUgVlNDU0lJRl9CQUNLX01BWF9QRU5ESU5HX1JF
UVMgICAgMTI4CisKKy8qCisgKiBNYXhpbXVtIHNjYXR0ZXIvZ2F0aGVyIHNlZ21lbnRzIHBlciBy
ZXF1ZXN0LgorICoKKyAqIENvbnNpZGVyaW5nIGJhbGFuY2UgYmV0d2VlbiBhbGxvY2F0aW5nIGFs
IGxlYXN0IDE2ICJ2c2NzaWlmX3JlcXVlc3QiCisgKiBzdHJ1Y3R1cmVzIG9uIG9uZSBwYWdlICg0
MDk2Ynl0ZXMpIGFuZCBudW1iZXIgb2Ygc2NhdHRlciBnYXRoZXIKKyAqIG5lZWRlZCwgd2UgZGVj
aWRlZCB0byB1c2UgMjYgYXMgYSBtYWdpYyBudW1iZXIuCisgKi8KKyNkZWZpbmUgVlNDU0lJRl9T
R19UQUJMRVNJWkUgICAgICAgICAgICAgMjYKKworLyoKKyAqIGJhc2Ugb24gbGludXgga2VybmVs
IDIuNi4xOAorICovCisjZGVmaW5lIFZTQ1NJSUZfTUFYX0NPTU1BTkRfU0laRSAgICAgICAgIDE2
CisjZGVmaW5lIFZTQ1NJSUZfU0VOU0VfQlVGRkVSU0laRSAgICAgICAgIDk2CisKKworc3RydWN0
IHZzY3NpaWZfcmVxdWVzdCB7CisgICAgdWludDE2X3QgcnFpZDsgICAgICAgICAgLyogcHJpdmF0
ZSBndWVzdCB2YWx1ZSwgZWNob2VkIGluIHJlc3AgICovCisgICAgdWludDhfdCBhY3Q7ICAgICAg
ICAgICAgLyogY29tbWFuZCBiZXR3ZWVuIGJhY2tlbmQgYW5kIGZyb250ZW5kICovCisgICAgdWlu
dDhfdCBjbWRfbGVuOworCisgICAgdWludDhfdCBjbW5kW1ZTQ1NJSUZfTUFYX0NPTU1BTkRfU0la
RV07CisgICAgdWludDE2X3QgdGltZW91dF9wZXJfY29tbWFuZDsgICAgIC8qIFRoZSBjb21tYW5k
IGlzIGlzc3VlZCBieSB0d2ljZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0aGUgdmFsdWUgaW4gQmFja2VuZC4gKi8KKyAgICB1aW50MTZfdCBjaGFubmVsLCBpZCwg
bHVuOworICAgIHVpbnQxNl90IHBhZGRpbmc7CisgICAgdWludDhfdCBzY19kYXRhX2RpcmVjdGlv
bjsgICAgICAgIC8qIGZvciBETUFfVE9fREVWSUNFKDEpCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIERNQV9GUk9NX0RFVklDRSgyKQorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBETUFfTk9ORSgzKSByZXF1ZXN0cyAgKi8KKyAgICB1aW50
OF90IG5yX3NlZ21lbnRzOyAgICAgICAgICAgICAgLyogTnVtYmVyIG9mIHBpZWNlcyBvZiBzY2F0
dGVyLWdhdGhlciAqLworCisgICAgc3RydWN0IHNjc2lpZl9yZXF1ZXN0X3NlZ21lbnQgeworICAg
ICAgICBncmFudF9yZWZfdCBncmVmOworICAgICAgICB1aW50MTZfdCBvZmZzZXQ7CisgICAgICAg
IHVpbnQxNl90IGxlbmd0aDsKKyAgICB9IHNlZ1tWU0NTSUlGX1NHX1RBQkxFU0laRV07CisgICAg
dWludDMyX3QgcmVzZXJ2ZWRbM107Cit9OwordHlwZWRlZiBzdHJ1Y3QgdnNjc2lpZl9yZXF1ZXN0
IHZzY3NpaWZfcmVxdWVzdF90OworCitzdHJ1Y3QgdnNjc2lpZl9yZXNwb25zZSB7CisgICAgdWlu
dDE2X3QgcnFpZDsKKyAgICB1aW50OF90IHBhZGRpbmc7CisgICAgdWludDhfdCBzZW5zZV9sZW47
CisgICAgdWludDhfdCBzZW5zZV9idWZmZXJbVlNDU0lJRl9TRU5TRV9CVUZGRVJTSVpFXTsKKyAg
ICBpbnQzMl90IHJzbHQ7CisgICAgdWludDMyX3QgcmVzaWR1YWxfbGVuOyAgICAgLyogcmVxdWVz
dCBidWZmbGVuIC0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gdGhl
IHZhbHVlIGZyb20gcGh5c2ljYWwgZGV2aWNlICovCisgICAgdWludDMyX3QgcmVzZXJ2ZWRbMzZd
OworfTsKK3R5cGVkZWYgc3RydWN0IHZzY3NpaWZfcmVzcG9uc2UgdnNjc2lpZl9yZXNwb25zZV90
OworCitERUZJTkVfUklOR19UWVBFUyh2c2NzaWlmLCBzdHJ1Y3QgdnNjc2lpZl9yZXF1ZXN0LCBz
dHJ1Y3QgdnNjc2lpZl9yZXNwb25zZSk7CisKKworI2VuZGlmICAvKl9fWEVOX19QVUJMSUNfSU9f
U0NTSV9IX18qLworLyoKKyAqIExvY2FsIHZhcmlhYmxlczoKKyAqIG1vZGU6IEMKKyAqIGMtc2V0
LXN0eWxlOiAiQlNEIgorICogYy1iYXNpYy1vZmZzZXQ6IDQKKyAqIHRhYi13aWR0aDogNAorICog
aW5kZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8K
--f46d04182804c4d6b904b9ac494f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d04182804c4d6b904b9ac494f--


From xen-devel-bounces@lists.xen.org Fri Feb 24 02:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 02: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 1S0kdv-0007U0-UE; Fri, 24 Feb 2012 02:12:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1S0kdt-0007Tv-8W
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 02:12:18 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330049530!14679173!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26831 invoked from network); 24 Feb 2012 02:12:10 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 02:12:10 -0000
Received: by wgbdr13 with SMTP id dr13so1475216wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 23 Feb 2012 18:12:10 -0800 (PST)
Received-SPF: pass (google.com: domain of jaceksburghardt@gmail.com designates
	10.180.99.7 as permitted sender) client-ip=10.180.99.7; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	jaceksburghardt@gmail.com designates 10.180.99.7 as permitted
	sender) smtp.mail=jaceksburghardt@gmail.com;
	dkim=pass header.i=jaceksburghardt@gmail.com
Received: from mr.google.com ([10.180.99.7])
	by 10.180.99.7 with SMTP id em7mr545789wib.7.1330049530062 (num_hops =
	1); Thu, 23 Feb 2012 18:12:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/Tj+iCmF0uNXmwE046N2qoWat+5Cng/Y9DlpTBIsFdU=;
	b=OojF0PP/e0Fbx2hlOdX7OcVsP+f+SHDUp+0wz0RzPdOC6xyZ+rbpASsKOyamWxeHzP
	FHoyveqOtvwA0fnobjHN8LGwKRBRWj/SIc8AZp4UkBPWFsQU/OIFDcy8e70WbdHtpNpf
	/RZxwKRmoB7OvBVNk9zlmguyiuOBMiAtIwyvM=
MIME-Version: 1.0
Received: by 10.180.99.7 with SMTP id em7mr451573wib.7.1330049529992; Thu, 23
	Feb 2012 18:12:09 -0800 (PST)
Received: by 10.180.106.99 with HTTP; Thu, 23 Feb 2012 18:12:09 -0800 (PST)
Date: Thu, 23 Feb 2012 19:12:09 -0700
Message-ID: <CAHyyzzTxGHVu02sP==Lm2Du2GSCK6Bct=8F98djP0-M4hhx5vQ@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=f46d04182804c4d6b904b9ac494f
Subject: [Xen-devel] pvscsi patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d04182804c4d6b904b9ac494f
Content-Type: multipart/alternative; boundary=f46d04182804c4d6a204b9ac494d

--f46d04182804c4d6a204b9ac494d
Content-Type: text/plain; charset=ISO-8859-1

I had extracted this pvscsi patch to 3.3.0 kernel. from pvscsi git and
patched my kernel. both xenscsi-back front loads fine. If I start vm with
xm domU and hvm can see my blurey drive with it correct name but I get scsi
errors. I wonder if there is patch that gives direct access to scsi device.
esxi gives direct access so makemkv works perfectly.

--f46d04182804c4d6a204b9ac494d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I had extracted this pvscsi patch to 3.3.0 kernel. from pvscsi git and patc=
hed my kernel. both xenscsi-back front loads fine. If I start vm with xm do=
mU and hvm can see my blurey drive with it correct name but I get scsi erro=
rs. I wonder if there is patch that gives direct access to scsi device. esx=
i gives direct access so makemkv works perfectly. <br>

--f46d04182804c4d6a204b9ac494d--
--f46d04182804c4d6b904b9ac494f
Content-Type: application/octet-stream; name="patch-pvscsi.diff"
Content-Disposition: attachment; filename="patch-pvscsi.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gz2tyvqr0

ZGlmZiAtcnVwTiB4ZW4vZHJpdmVycy9zY3NpL0tjb25maWcgeGVuYy9kcml2ZXJzL3Njc2kvS2Nv
bmZpZwotLS0geGVuL2RyaXZlcnMvc2NzaS9LY29uZmlnCTIwMTItMDItMjQgMTU6MTI6MzkuNzIy
MzExNjMzIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2NzaS9LY29uZmlnCTIwMTItMDItMjQgMTU6
MTk6MzUuMzE1NjQ0OTMzIC0wNzAwCkBAIC0xODk3LDYgKzE4OTcsMjIgQEAgY29uZmlnIFNDU0lf
QkZBX0ZDCiAJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBo
ZXJlLiBUaGUgbW9kdWxlIHdpbGwKIAkgIGJlIGNhbGxlZCBiZmEuCiAKK2NvbmZpZyBYRU5fU0NT
SV9GUk9OVEVORAorICAgICAgICB0cmlzdGF0ZSAiWGVuIFBWU0NTSSBmcm9udGVuZCBkcml2ZXIi
CisgICAgICAgIGRlcGVuZHMgb24gWEVOICYmIFNDU0kKKyAgICAgICAgZGVmYXVsdCBtCisgICAg
ICAgIGhlbHAKKyAgICAgICAgICBUaGUgU0NTSSBmcm9udGVuZCBkcml2ZXIgYWxsb3dzIHRoZSBr
ZXJuZWwgdG8gYWNjZXNzIFNDU0kgRGV2aWNlcworICAgICAgICAgIHdpdGhpbiBhbm90aGVyIGd1
ZXN0IE9TLgorCitjb25maWcgWEVOX1NDU0lfQkFDS0VORAorICAgICAgICB0cmlzdGF0ZSAiWGVu
IFBWU0NTSSBiYWNrZW5kIGRyaXZlciIKKyAgICAgICAgZGVwZW5kcyBvbiBYRU5fQkFDS0VORCAm
JiBTQ1NJCisgICAgICAgIGRlZmF1bHQgbQorICAgICAgICBoZWxwCisgICAgICAgICAgVGhlIFBW
U0NTSSBiYWNrZW5kIGRyaXZlciBhbGxvd3MgdGhlIGtlcm5lbCB0byBleHBvcnQgaXRzIFNDU0kg
RGV2aWNlcworICAgICAgICAgIHRvIG90aGVyIFhlbiBndWVzdHMgdmlhIGEgaGlnaC1wZXJmb3Jt
YW5jZSBzaGFyZWQtbWVtb3J5IGludGVyZmFjZS4KKwogZW5kaWYgIyBTQ1NJX0xPV0xFVkVMCiAK
IHNvdXJjZSAiZHJpdmVycy9zY3NpL3BjbWNpYS9LY29uZmlnIgpkaWZmIC1ydXBOIHhlbi9kcml2
ZXJzL3Njc2kvS2NvbmZpZy5vcmlnIHhlbmMvZHJpdmVycy9zY3NpL0tjb25maWcub3JpZwotLS0g
eGVuL2RyaXZlcnMvc2NzaS9LY29uZmlnLm9yaWcJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAw
MDAgLTA3MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL0tjb25maWcub3JpZwkyMDEyLTAyLTI0IDE1
OjEyOjM5LjcyMjMxMTYzMyAtMDcwMApAQCAtMCwwICsxLDE5MDggQEAKK21lbnUgIlNDU0kgZGV2
aWNlIHN1cHBvcnQiCisKK2NvbmZpZyBTQ1NJX01PRAorICAgICAgIHRyaXN0YXRlCisgICAgICAg
ZGVmYXVsdCB5IGlmIFNDU0k9biB8fCBTQ1NJPXkKKyAgICAgICBkZWZhdWx0IG0gaWYgU0NTST1t
CisKK2NvbmZpZyBSQUlEX0FUVFJTCisJdHJpc3RhdGUgIlJBSUQgVHJhbnNwb3J0IENsYXNzIgor
CWRlZmF1bHQgbgorCWRlcGVuZHMgb24gQkxPQ0sKKwlkZXBlbmRzIG9uIFNDU0lfTU9ECisJLS0t
aGVscC0tLQorCSAgUHJvdmlkZXMgUkFJRAorCitjb25maWcgU0NTSQorCXRyaXN0YXRlICJTQ1NJ
IGRldmljZSBzdXBwb3J0IgorCWRlcGVuZHMgb24gQkxPQ0sKKwlzZWxlY3QgU0NTSV9ETUEgaWYg
SEFTX0RNQQorCS0tLWhlbHAtLS0KKwkgIElmIHlvdSB3YW50IHRvIHVzZSBhIFNDU0kgaGFyZCBk
aXNrLCBTQ1NJIHRhcGUgZHJpdmUsIFNDU0kgQ0QtUk9NIG9yCisJICBhbnkgb3RoZXIgU0NTSSBk
ZXZpY2UgdW5kZXIgTGludXgsIHNheSBZIGFuZCBtYWtlIHN1cmUgdGhhdCB5b3Uga25vdworCSAg
dGhlIG5hbWUgb2YgeW91ciBTQ1NJIGhvc3QgYWRhcHRlciAodGhlIGNhcmQgaW5zaWRlIHlvdXIg
Y29tcHV0ZXIKKwkgIHRoYXQgInNwZWFrcyIgdGhlIFNDU0kgcHJvdG9jb2wsIGFsc28gY2FsbGVk
IFNDU0kgY29udHJvbGxlciksCisJICBiZWNhdXNlIHlvdSB3aWxsIGJlIGFza2VkIGZvciBpdC4K
KworCSAgWW91IGFsc28gbmVlZCB0byBzYXkgWSBoZXJlIGlmIHlvdSBoYXZlIGEgZGV2aWNlIHdo
aWNoIHNwZWFrcworCSAgdGhlIFNDU0kgcHJvdG9jb2wuICBFeGFtcGxlcyBvZiB0aGlzIGluY2x1
ZGUgdGhlIHBhcmFsbGVsIHBvcnQKKwkgIHZlcnNpb24gb2YgdGhlIElPTUVHQSBaSVAgZHJpdmUs
IFVTQiBzdG9yYWdlIGRldmljZXMsIEZpYnJlCisJICBDaGFubmVsLCBhbmQgRmlyZVdpcmUgc3Rv
cmFnZS4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g
aGVyZSBhbmQgcmVhZAorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2kudHh0Pi4KKwkg
IFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc2NzaV9tb2QuCisKKwkgIEhvd2V2ZXIsIGRvIG5v
dCBjb21waWxlIHRoaXMgYXMgYSBtb2R1bGUgaWYgeW91ciByb290IGZpbGUgc3lzdGVtCisJICAo
dGhlIG9uZSBjb250YWluaW5nIHRoZSBkaXJlY3RvcnkgLykgaXMgbG9jYXRlZCBvbiBhIFNDU0kg
ZGV2aWNlLgorCitjb25maWcgU0NTSV9ETUEKKwlib29sCisJZGVmYXVsdCBuCisKK2NvbmZpZyBT
Q1NJX1RHVAorCXRyaXN0YXRlICJTQ1NJIHRhcmdldCBzdXBwb3J0IgorCWRlcGVuZHMgb24gU0NT
SSAmJiBFWFBFUklNRU5UQUwKKwktLS1oZWxwLS0tCisJICBJZiB5b3Ugd2FudCB0byB1c2UgU0NT
SSB0YXJnZXQgbW9kZSBkcml2ZXJzIGVuYWJsZSB0aGlzIG9wdGlvbi4KKwkgIElmIHlvdSBjaG9v
c2UgTSwgdGhlIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBzY3NpX3RndC4KKworY29uZmlnIFNDU0lf
TkVUTElOSworCWJvb2wKKwlkZWZhdWx0CW4KKwlzZWxlY3QgTkVUCisKK2NvbmZpZyBTQ1NJX1BS
T0NfRlMKKwlib29sICJsZWdhY3kgL3Byb2Mvc2NzaS8gc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFND
U0kgJiYgUFJPQ19GUworCWRlZmF1bHQgeQorCS0tLWhlbHAtLS0KKwkgIFRoaXMgb3B0aW9uIGVu
YWJsZXMgc3VwcG9ydCBmb3IgdGhlIHZhcmlvdXMgZmlsZXMgaW4KKwkgIC9wcm9jL3Njc2kuICBJ
biBMaW51eCAyLjYgdGhpcyBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5CisJICBmaWxlcyBpbiBzeXNm
cyBidXQgbWFueSBsZWdhY3kgYXBwbGljYXRpb25zIHJlbHkgb24gdGhpcy4KKworCSAgSWYgdW5z
dXJlIHNheSBZLgorCitjb21tZW50ICJTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFwZSwgQ0Qt
Uk9NKSIKKwlkZXBlbmRzIG9uIFNDU0kKKworY29uZmlnIEJMS19ERVZfU0QKKwl0cmlzdGF0ZSAi
U0NTSSBkaXNrIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJCisJc2VsZWN0IENSQ19UMTBESUYg
aWYgQkxLX0RFVl9JTlRFR1JJVFkKKwktLS1oZWxwLS0tCisJICBJZiB5b3Ugd2FudCB0byB1c2Ug
U0NTSSBoYXJkIGRpc2tzLCBGaWJyZSBDaGFubmVsIGRpc2tzLAorCSAgU2VyaWFsIEFUQSAoU0FU
QSkgb3IgUGFyYWxsZWwgQVRBIChQQVRBKSBoYXJkIGRpc2tzLAorCSAgVVNCIHN0b3JhZ2Ugb3Ig
dGhlIFNDU0kgb3IgcGFyYWxsZWwgcG9ydCB2ZXJzaW9uIG9mCisJICB0aGUgSU9NRUdBIFpJUCBk
cml2ZSwgc2F5IFkgYW5kIHJlYWQgdGhlIFNDU0ktSE9XVE8sCisJICB0aGUgRGlzay1IT1dUTyBh
bmQgdGhlIE11bHRpLURpc2stSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0cDovL3d3dy50
bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiBUaGlzIGlzIE5PVCBmb3IgU0NTSQorCSAgQ0QtUk9N
cy4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVy
ZSBhbmQgcmVhZAorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2kudHh0Pi4KKwkgIFRo
ZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc2RfbW9kLgorCisJICBEbyBub3QgY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSBpZiB5b3VyIHJvb3QgZmlsZSBzeXN0ZW0KKwkgICh0aGUgb25l
IGNvbnRhaW5pbmcgdGhlIGRpcmVjdG9yeSAvKSBpcyBsb2NhdGVkIG9uIGEgU0NTSSBkaXNrLgor
CSAgSW4gdGhpcyBjYXNlLCBkbyBub3QgY29tcGlsZSB0aGUgZHJpdmVyIGZvciB5b3VyIFNDU0kg
aG9zdCBhZGFwdGVyCisJICAoYmVsb3cpIGFzIGEgbW9kdWxlIGVpdGhlci4KKworY29uZmlnIENI
Ul9ERVZfU1QKKwl0cmlzdGF0ZSAiU0NTSSB0YXBlIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJ
CisJLS0taGVscC0tLQorCSAgSWYgeW91IHdhbnQgdG8gdXNlIGEgU0NTSSB0YXBlIGRyaXZlIHVu
ZGVyIExpbnV4LCBzYXkgWSBhbmQgcmVhZCB0aGUKKwkgIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBm
cm9tCisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LCBhbmQKKwkgIDxm
aWxlOkRvY3VtZW50YXRpb24vc2NzaS9zdC50eHQ+IGluIHRoZSBrZXJuZWwgc291cmNlLiAgVGhp
cyBpcyBOT1QKKwkgIGZvciBTQ1NJIENELVJPTXMuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2
ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmUgYW5kIHJlYWQKKwkgIDxmaWxlOkRvY3VtZW50
YXRpb24vc2NzaS9zY3NpLnR4dD4uIFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgc3QuCisKK2Nv
bmZpZyBDSFJfREVWX09TU1QKKwl0cmlzdGF0ZSAiU0NTSSBPblN0cmVhbSBTQy14MCB0YXBlIHN1
cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJCisJLS0taGVscC0tLQorCSAgVGhlIE9uU3RyZWFtIFND
LXgwIFNDU0kgdGFwZSBkcml2ZXMgY2Fubm90IGJlIGRyaXZlbiBieSB0aGUKKwkgIHN0YW5kYXJk
IHN0IGRyaXZlciwgYnV0IGluc3RlYWQgbmVlZCB0aGlzIHNwZWNpYWwgb3NzdCBkcml2ZXIgYW5k
CisJICB1c2UgdGhlICAvZGV2L29zc3RYIGNoYXIgZGV2aWNlIG5vZGVzIChtYWpvciAyMDYpLiAg
VmlhIHVzYi1zdG9yYWdlLAorCSAgeW91IG1heSBiZSBhYmxlIHRvIGRyaXZlIHRoZSBVU0IteDAg
YW5kIERJLXgwIGRyaXZlcyBhcyB3ZWxsLgorCSAgTm90ZSB0aGF0IHRoZXJlIGlzIGFsc28gYSBz
ZWNvbmQgZ2VuZXJhdGlvbiBvZiBPblN0cmVhbQorCSAgdGFwZSBkcml2ZXMgKEFEUi14MCkgdGhh
dCBzdXBwb3J0cyB0aGUgc3RhbmRhcmQgU0NTSS0yIGNvbW1hbmRzIGZvcgorCSAgdGFwZXMgKFFJ
Qy0xNTcpIGFuZCBjYW4gYmUgZHJpdmVuIGJ5IHRoZSBzdGFuZGFyZCBkcml2ZXIgc3QuCisJICBG
b3IgbW9yZSBpbmZvcm1hdGlvbiwgeW91IG1heSBoYXZlIGEgbG9vayBhdCB0aGUgU0NTSS1IT1dU
TworCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPiAgYW5kCisJICA8Zmls
ZTpEb2N1bWVudGF0aW9uL3Njc2kvb3NzdC50eHQ+ICBpbiB0aGUga2VybmVsIHNvdXJjZS4KKwkg
IE1vcmUgaW5mbyBvbiB0aGUgT25TdHJlYW0gZHJpdmVyIG1heSBiZSBmb3VuZCBvbgorCSAgPGh0
dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvb3NzdC8+CisJICBQbGVhc2UgYWxzbyBoYXZl
IGEgbG9vayBhdCB0aGUgc3RhbmRhcmQgc3QgZG9jdSwgYXMgbW9zdCBvZiBpdAorCSAgYXBwbGll
cyB0byBvc3N0IGFzIHdlbGwuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1
bGUsIGNob29zZSBNIGhlcmUgYW5kIHJlYWQKKwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9z
Y3NpLnR4dD4uIFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgb3NzdC4KKworY29uZmlnIEJMS19E
RVZfU1IKKwl0cmlzdGF0ZSAiU0NTSSBDRFJPTSBzdXBwb3J0IgorCWRlcGVuZHMgb24gU0NTSQor
CS0tLWhlbHAtLS0KKwkgIElmIHlvdSB3YW50IHRvIHVzZSBhIENEIG9yIERWRCBkcml2ZSBhdHRh
Y2hlZCB0byB5b3VyIGNvbXB1dGVyCisJICBieSBTQ1NJLCBGaXJlV2lyZSwgVVNCIG9yIEFUQVBJ
LCBzYXkgWSBhbmQgcmVhZCB0aGUgU0NTSS1IT1dUTworCSAgYW5kIHRoZSBDRFJPTS1IT1dUTyBh
dCA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LgorCisJICBNYWtlIHN1cmUg
dG8gc2F5IFkgb3IgTSB0byAiSVNPIDk2NjAgQ0QtUk9NIGZpbGUgc3lzdGVtIHN1cHBvcnQiLgor
CisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlIGFu
ZCByZWFkCisJICA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvc2NzaS50eHQ+LgorCSAgVGhlIG1v
ZHVsZSB3aWxsIGJlIGNhbGxlZCBzcl9tb2QuCisKK2NvbmZpZyBCTEtfREVWX1NSX1ZFTkRPUgor
CWJvb2wgIkVuYWJsZSB2ZW5kb3Itc3BlY2lmaWMgZXh0ZW5zaW9ucyAoZm9yIFNDU0kgQ0RST00p
IgorCWRlcGVuZHMgb24gQkxLX0RFVl9TUgorCWhlbHAKKwkgIFRoaXMgZW5hYmxlcyB0aGUgdXNh
Z2Ugb2YgdmVuZG9yIHNwZWNpZmljIFNDU0kgY29tbWFuZHMuIFRoaXMgaXMKKwkgIHJlcXVpcmVk
IHRvIHN1cHBvcnQgbXVsdGlzZXNzaW9uIENEcyB3aXRoIG9sZCBORUMvVE9TSElCQSBjZHJvbQor
CSAgZHJpdmVzIChhbmQgSFAgV3JpdGVycykuIElmIHlvdSBoYXZlIHN1Y2ggYSBkcml2ZSBhbmQg
Z2V0IHRoZSBmaXJzdAorCSAgc2Vzc2lvbiBvbmx5LCB0cnkgc2F5aW5nIFkgaGVyZTsgZXZlcnli
b2R5IGVsc2Ugc2F5cyBOLgorCitjb25maWcgQ0hSX0RFVl9TRworCXRyaXN0YXRlICJTQ1NJIGdl
bmVyaWMgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0kKKwktLS1oZWxwLS0tCisJICBJZiB5b3Ug
d2FudCB0byB1c2UgU0NTSSBzY2FubmVycywgc3ludGhlc2l6ZXJzIG9yIENELXdyaXRlcnMgb3Ig
anVzdAorCSAgYWJvdXQgYW55dGhpbmcgaGF2aW5nICJTQ1NJIiBpbiBpdHMgbmFtZSBvdGhlciB0
aGFuIGhhcmQgZGlza3MsCisJICBDRC1ST01zIG9yIHRhcGVzLCBzYXkgWSBoZXJlLiBUaGVzZSB3
b24ndCBiZSBzdXBwb3J0ZWQgYnkgdGhlIGtlcm5lbAorCSAgZGlyZWN0bHksIHNvIHlvdSBuZWVk
IHNvbWUgYWRkaXRpb25hbCBzb2Z0d2FyZSB3aGljaCBrbm93cyBob3cgdG8KKwkgIHRhbGsgdG8g
dGhlc2UgZGV2aWNlcyB1c2luZyB0aGUgU0NTSSBwcm90b2NvbDoKKworCSAgRm9yIHNjYW5uZXJz
LCBsb29rIGF0IFNBTkUgKDxodHRwOi8vd3d3LnNhbmUtcHJvamVjdC5vcmcvPikuIEZvciBDRAor
CSAgd3JpdGVyIHNvZnR3YXJlIGxvb2sgYXQgQ2RydG9vbHMKKwkgICg8aHR0cDovL2NkcmVjb3Jk
LmJlcmxpb3MuZGUvcHJpdmF0ZS9jZHJlY29yZC5odG1sPikKKwkgIGFuZCBmb3IgYnVybmluZyBh
ICJkaXNrIGF0IG9uY2UiOiBDRFJEQU8KKwkgICg8aHR0cDovL2NkcmRhby5zb3VyY2Vmb3JnZS5u
ZXQvPikuIENkcGFyYW5vaWEgaXMgYSBoaWdoCisJICBxdWFsaXR5IGRpZ2l0YWwgcmVhZGVyIG9m
IGF1ZGlvIENEcyAoPGh0dHA6Ly93d3cueGlwaC5vcmcvcGFyYW5vaWEvPikuCisJICBGb3Igb3Ro
ZXIgZGV2aWNlcywgaXQncyBwb3NzaWJsZSB0aGF0IHlvdSdsbCBoYXZlIHRvIHdyaXRlIHRoZQor
CSAgZHJpdmVyIHNvZnR3YXJlIHlvdXJzZWxmLiBQbGVhc2UgcmVhZCB0aGUgZmlsZQorCSAgPGZp
bGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2ktZ2VuZXJpYy50eHQ+IGZvciBtb3JlIGluZm9ybWF0
aW9uLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBo
ZXJlIGFuZCByZWFkCisJICA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvc2NzaS50eHQ+LiBUaGUg
bW9kdWxlIHdpbGwgYmUgY2FsbGVkIHNnLgorCisJICBJZiB1bnN1cmUsIHNheSBOLgorCitjb25m
aWcgQ0hSX0RFVl9TQ0gKKwl0cmlzdGF0ZSAiU0NTSSBtZWRpYSBjaGFuZ2VyIHN1cHBvcnQiCisJ
ZGVwZW5kcyBvbiBTQ1NJCisJLS0taGVscC0tLQorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgU0NT
SSBtZWRpYSBjaGFuZ2Vycy4gIE1vc3QgY29tbW9uIGRldmljZXMgYXJlCisJICB0YXBlIGxpYnJh
cmllcyBhbmQgTU9EL0NEUk9NIGp1a2Vib3hlcy4gICpSZWFsKiBqdWtlYm94ZXMsIHlvdQorCSAg
ZG9uJ3QgbmVlZCB0aGlzIGZvciB0aG9zZSB0aW55IDYtc2xvdCBjZHJvbSBjaGFuZ2Vycy4gIE1l
ZGlhCisJICBjaGFuZ2VycyBhcmUgbGlzdGVkIGFzICJUeXBlOiBNZWRpdW0gQ2hhbmdlciIgaW4g
L3Byb2Mvc2NzaS9zY3NpLgorCSAgSWYgeW91IGhhdmUgc3VjaCBoYXJkd2FyZSBhbmQgd2FudCB0
byB1c2UgaXQgd2l0aCBsaW51eCwgc2F5IFkKKwkgIGhlcmUuICBDaGVjayA8ZmlsZTpEb2N1bWVu
dGF0aW9uL3Njc2kvc2NzaS1jaGFuZ2VyLnR4dD4gZm9yIGRldGFpbHMuCisJCisJICBJZiB5b3Ug
d2FudCB0byBjb21waWxlIHRoaXMgYXMgYSBtb2R1bGUgKCA9IGNvZGUgd2hpY2ggY2FuIGJlCisJ
ICBpbnNlcnRlZCBpbiBhbmQgcmVtb3ZlZCBmcm9tIHRoZSBydW5uaW5nIGtlcm5lbCB3aGVuZXZl
ciB5b3Ugd2FudCksCisJICBzYXkgTSBoZXJlIGFuZCByZWFkIDxmaWxlOkRvY3VtZW50YXRpb24v
a2J1aWxkL21vZHVsZXMudHh0PiBhbmQKKwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9zY3Np
LnR4dD4uIFRoZSBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgY2guby4KKwkgIElmIHVuc3VyZSwgc2F5
IE4uCisKK2NvbmZpZyBTQ1NJX0VOQ0xPU1VSRQorCXRyaXN0YXRlICJTQ1NJIEVuY2xvc3VyZSBT
dXBwb3J0IgorCWRlcGVuZHMgb24gU0NTSSAmJiBFTkNMT1NVUkVfU0VSVklDRVMKKwloZWxwCisJ
ICBFbmNsb3N1cmVzIGFyZSBkZXZpY2VzIHNpdHRpbmcgb24gb3IgaW4gU0NTSSBiYWNrcGxhbmVz
IHRoYXQKKwkgIG1hbmFnZSBkZXZpY2VzLiAgSWYgeW91IGhhdmUgYSBkaXNrIGNhZ2UsIHRoZSBj
aGFuY2VzIGFyZSB0aGF0CisJICBpdCBoYXMgYW4gZW5jbG9zdXJlIGRldmljZS4gIFNlbGVjdGlu
ZyB0aGlzIG9wdGlvbiB3aWxsIGp1c3QgYWxsb3cKKwkgIGNlcnRhaW4gZW5jbG9zdXJlIGNvbmRp
dGlvbnMgdG8gYmUgcmVwb3J0ZWQgYW5kIGlzIG5vdCByZXF1aXJlZC4KKworY29uZmlnIFNDU0lf
TVVMVElfTFVOCisJYm9vbCAiUHJvYmUgYWxsIExVTnMgb24gZWFjaCBTQ1NJIGRldmljZSIKKwlk
ZXBlbmRzIG9uIFNDU0kKKwloZWxwCisJICBTb21lIGRldmljZXMgc3VwcG9ydCBtb3JlIHRoYW4g
b25lIExVTiAoTG9naWNhbCBVbml0IE51bWJlcikgaW4gb3JkZXIKKwkgIHRvIGFsbG93IGFjY2Vz
cyB0byBzZXZlcmFsIG1lZGlhLCBlLmcuIENEIGp1a2Vib3gsIFVTQiBjYXJkIHJlYWRlciwKKwkg
IG1vYmlsZSBwaG9uZSBpbiBtYXNzIHN0b3JhZ2UgbW9kZS4gVGhpcyBvcHRpb24gZm9yY2VzIHRo
ZSBrZXJuZWwgdG8KKwkgIHByb2JlIGZvciBhbGwgTFVOcyBieSBkZWZhdWx0LiBUaGlzIHNldHRp
bmcgY2FuIGJlIG92ZXJyaWRlbiBieQorCSAgbWF4X2x1bnMgYm9vdC9tb2R1bGUgcGFyYW1ldGVy
LiBOb3RlIHRoYXQgdGhpcyBvcHRpb24gZG9lcyBub3QgYWZmZWN0CisJICBkZXZpY2VzIGNvbmZv
cm1pbmcgdG8gU0NTSS0zIG9yIGhpZ2hlciBhcyB0aGV5IGNhbiBleHBsaWNpdGVseSByZXBvcnQK
KwkgIHRoZWlyIG51bWJlciBvZiBMVU5zLiBJdCBpcyBzYWZlIHRvIHNheSBZIGhlcmUgdW5sZXNz
IHlvdSBoYXZlIG9uZSBvZgorCSAgdGhvc2UgcmFyZSBkZXZpY2VzIHdoaWNoIHJlYWN0cyBpbiBh
biB1bmV4cGVjdGVkIHdheSB3aGVuIHByb2JlZCBmb3IKKwkgIG11bHRpcGxlIExVTnMuCisKK2Nv
bmZpZyBTQ1NJX0NPTlNUQU5UUworCWJvb2wgIlZlcmJvc2UgU0NTSSBlcnJvciByZXBvcnRpbmcg
KGtlcm5lbCBzaXplICs9MTJLKSIKKwlkZXBlbmRzIG9uIFNDU0kKKwloZWxwCisJICBUaGUgZXJy
b3IgbWVzc2FnZXMgcmVnYXJkaW5nIHlvdXIgU0NTSSBoYXJkd2FyZSB3aWxsIGJlIGVhc2llciB0
bworCSAgdW5kZXJzdGFuZCBpZiB5b3Ugc2F5IFkgaGVyZTsgaXQgd2lsbCBlbmxhcmdlIHlvdXIg
a2VybmVsIGJ5IGFib3V0CisJICAxMiBLQi4gSWYgaW4gZG91YnQsIHNheSBZLgorCitjb25maWcg
U0NTSV9MT0dHSU5HCisJYm9vbCAiU0NTSSBsb2dnaW5nIGZhY2lsaXR5IgorCWRlcGVuZHMgb24g
U0NTSQorCS0tLWhlbHAtLS0KKwkgIFRoaXMgdHVybnMgb24gYSBsb2dnaW5nIGZhY2lsaXR5IHRo
YXQgY2FuIGJlIHVzZWQgdG8gZGVidWcgYSBudW1iZXIKKwkgIG9mIFNDU0kgcmVsYXRlZCBwcm9i
bGVtcy4KKworCSAgSWYgeW91IHNheSBZIGhlcmUsIG5vIGxvZ2dpbmcgb3V0cHV0IHdpbGwgYXBw
ZWFyIGJ5IGRlZmF1bHQsIGJ1dCB5b3UKKwkgIGNhbiBlbmFibGUgbG9nZ2luZyBieSBzYXlpbmcg
WSB0byAiL3Byb2MgZmlsZSBzeXN0ZW0gc3VwcG9ydCIgYW5kCisJICAiU3lzY3RsIHN1cHBvcnQi
IGJlbG93IGFuZCBleGVjdXRpbmcgdGhlIGNvbW1hbmQKKworCSAgZWNobyA8Yml0bWFzaz4gPiAv
cHJvYy9zeXMvZGV2L3Njc2kvbG9nZ2luZ19sZXZlbAorCisJICB3aGVyZSA8Yml0bWFzaz4gaXMg
YSBmb3VyIGJ5dGUgdmFsdWUgcmVwcmVzZW50aW5nIHRoZSBsb2dnaW5nIHR5cGUKKwkgIGFuZCBs
b2dnaW5nIGxldmVsIGZvciBlYWNoIHR5cGUgb2YgbG9nZ2luZyBzZWxlY3RlZC4KKworCSAgVGhl
cmUgYXJlIGEgbnVtYmVyIG9mIGxvZ2dpbmcgdHlwZXMgYW5kIHlvdSBjYW4gZmluZCB0aGVtIGlu
IHRoZQorCSAgc291cmNlIGF0IDxmaWxlOmRyaXZlcnMvc2NzaS9zY3NpX2xvZ2dpbmcuaD4uIFRo
ZSBsb2dnaW5nIGxldmVscworCSAgYXJlIGFsc28gZGVzY3JpYmVkIGluIHRoYXQgZmlsZSBhbmQg
dGhleSBkZXRlcm1pbmUgdGhlIHZlcmJvc2l0eSBvZgorCSAgdGhlIGxvZ2dpbmcgZm9yIGVhY2gg
bG9nZ2luZyB0eXBlLgorCisJICBJZiB5b3Ugc2F5IE4gaGVyZSwgaXQgbWF5IGJlIGhhcmRlciB0
byB0cmFjayBkb3duIHNvbWUgdHlwZXMgb2YgU0NTSQorCSAgcHJvYmxlbXMuIElmIHlvdSBzYXkg
WSBoZXJlIHlvdXIga2VybmVsIHdpbGwgYmUgc29tZXdoYXQgbGFyZ2VyLCBidXQKKwkgIHRoZXJl
IHNob3VsZCBiZSBubyBub3RpY2VhYmxlIHBlcmZvcm1hbmNlIGltcGFjdCBhcyBsb25nIGFzIHlv
dSBoYXZlCisJICBsb2dnaW5nIHR1cm5lZCBvZmYuCisKK2NvbmZpZyBTQ1NJX1NDQU5fQVNZTkMK
Kwlib29sICJBc3luY2hyb25vdXMgU0NTSSBzY2FubmluZyIKKwlkZXBlbmRzIG9uIFNDU0kKKwlo
ZWxwCisJICBUaGUgU0NTSSBzdWJzeXN0ZW0gY2FuIHByb2JlIGZvciBkZXZpY2VzIHdoaWxlIHRo
ZSByZXN0IG9mIHRoZQorCSAgc3lzdGVtIGNvbnRpbnVlcyBib290aW5nLCBhbmQgZXZlbiBwcm9i
ZSBkZXZpY2VzIG9uIGRpZmZlcmVudAorCSAgYnVzc2VzIGluIHBhcmFsbGVsLCBsZWFkaW5nIHRv
IGEgc2lnbmlmaWNhbnQgc3BlZWQtdXAuCisKKwkgIElmIHlvdSBoYXZlIGJ1aWx0IFNDU0kgYXMg
bW9kdWxlcywgZW5hYmxpbmcgdGhpcyBvcHRpb24gY2FuCisJICBiZSBhIHByb2JsZW0gYXMgdGhl
IGRldmljZXMgbWF5IG5vdCBoYXZlIGJlZW4gZm91bmQgYnkgdGhlCisJICB0aW1lIHlvdXIgc3lz
dGVtIGV4cGVjdHMgdGhlbSB0byBoYXZlIGJlZW4uICBZb3UgY2FuIGxvYWQgdGhlCisJICBzY3Np
X3dhaXRfc2NhbiBtb2R1bGUgdG8gZW5zdXJlIHRoYXQgYWxsIHNjYW5zIGhhdmUgY29tcGxldGVk
LgorCSAgSWYgeW91IGJ1aWxkIHlvdXIgU0NTSSBkcml2ZXJzIGludG8gdGhlIGtlcm5lbCwgdGhl
biBldmVyeXRoaW5nCisJICB3aWxsIHdvcmsgZmluZSBpZiB5b3Ugc2F5IFkgaGVyZS4KKworCSAg
WW91IGNhbiBvdmVycmlkZSB0aGlzIGNob2ljZSBieSBzcGVjaWZ5aW5nICJzY3NpX21vZC5zY2Fu
PXN5bmMiCisJICBvciBhc3luYyBvbiB0aGUga2VybmVsJ3MgY29tbWFuZCBsaW5lLgorCitjb25m
aWcgU0NTSV9XQUlUX1NDQU4KKwl0cmlzdGF0ZSAgIyBObyBwcm9tcHQgaGVyZSwgdGhpcyBpcyBh
biBpbnZpc2libGUgc3ltYm9sLgorCWRlZmF1bHQgbQorCWRlcGVuZHMgb24gU0NTSQorCWRlcGVu
ZHMgb24gTU9EVUxFUworIyBzY3NpX3dhaXRfc2NhbiBpcyBhIGxvYWRhYmxlIG1vZHVsZSB3aGlj
aCB3YWl0cyB1bnRpbCBhbGwgdGhlIGFzeW5jIHNjYW5zIGFyZQorIyBjb21wbGV0ZS4gIFRoZSBp
ZGVhIGlzIHRvIHVzZSBpdCBpbiBpbml0cmQvIGluaXRyYW1mcyBzY3JpcHRzLiAgWW91IG1vZHBy
b2JlCisjIGl0IGFmdGVyIGFsbCB0aGUgbW9kcHJvYmVzIG9mIHRoZSByb290IFNDU0kgZHJpdmVy
cyBhbmQgaXQgd2lsbCB3YWl0IHVudGlsCisjIHRoZXkgaGF2ZSBhbGwgZmluaXNoZWQgc2Nhbm5p
bmcgdGhlaXIgYnVzZXMgYmVmb3JlIGFsbG93aW5nIHRoZSBib290IHRvCisjIHByb2NlZWQuICAo
VGhpcyBtZXRob2QgaXMgbm90IGFwcGxpY2FibGUgaWYgdGFyZ2V0cyBib290IGluZGVwZW5kZW50
bHkgaW4KKyMgcGFyYWxsZWwgd2l0aCB0aGUgaW5pdGlhdG9yLCBvciB3aXRoIHRyYW5zcG9ydHMg
d2l0aCBub24tZGV0ZXJtaW5pc3RpYyB0YXJnZXQKKyMgZGlzY292ZXJ5IHNjaGVtZXMsIG9yIGlm
IGEgdHJhbnNwb3J0IGRyaXZlciBkb2VzIG5vdCBzdXBwb3J0IHNjc2lfd2FpdF9zY2FuLikKKyMK
KyMgVGhpcyBzeW1ib2wgaXMgbm90IGV4cG9zZWQgYXMgYSBwcm9tcHQgYmVjYXVzZSBsaXR0bGUg
aXMgdG8gYmUgZ2FpbmVkIGJ5CisjIGRpc2FibGluZyBpdCwgd2hlcmVhcyBwZW9wbGUgd2hvIGFj
Y2lkZW50YWxseSBzd2l0Y2ggaXQgb2ZmIG1heSB3b25kZXIgd2h5CisjIHRoZWlyIG1raW5pdHJk
IGdldHMgaW50byB0cm91YmxlLgorCittZW51ICJTQ1NJIFRyYW5zcG9ydHMiCisJZGVwZW5kcyBv
biBTQ1NJCisKK2NvbmZpZyBTQ1NJX1NQSV9BVFRSUworCXRyaXN0YXRlICJQYXJhbGxlbCBTQ1NJ
IChTUEkpIFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSQorCWhlbHAKKwkg
IElmIHlvdSB3aXNoIHRvIGV4cG9ydCB0cmFuc3BvcnQtc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJv
dXQKKwkgIGVhY2ggYXR0YWNoZWQgU0NTSSBkZXZpY2UgdG8gc3lzZnMsIHNheSBZLiAgT3RoZXJ3
aXNlLCBzYXkgTi4KKworY29uZmlnIFNDU0lfRkNfQVRUUlMKKwl0cmlzdGF0ZSAiRmliZXJDaGFu
bmVsIFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSQorCXNlbGVjdCBTQ1NJ
X05FVExJTksKKwloZWxwCisJICBJZiB5b3Ugd2lzaCB0byBleHBvcnQgdHJhbnNwb3J0LXNwZWNp
ZmljIGluZm9ybWF0aW9uIGFib3V0CisJICBlYWNoIGF0dGFjaGVkIEZpYmVyQ2hhbm5lbCBkZXZp
Y2UgdG8gc3lzZnMsIHNheSBZLgorCSAgT3RoZXJ3aXNlLCBzYXkgTi4KKworY29uZmlnIFNDU0lf
RkNfVEdUX0FUVFJTCisJYm9vbCAiU0NTSSB0YXJnZXQgc3VwcG9ydCBmb3IgRmliZXJDaGFubmVs
IFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSV9GQ19BVFRSUworCWRlcGVu
ZHMgb24gU0NTSV9UR1QgPSB5IHx8IFNDU0lfVEdUID0gU0NTSV9GQ19BVFRSUworCWhlbHAKKwkJ
SWYgeW91IHdhbnQgdG8gdXNlIFNDU0kgdGFyZ2V0IG1vZGUgZHJpdmVycyBlbmFibGUgdGhpcyBv
cHRpb24uCisKK2NvbmZpZyBTQ1NJX0lTQ1NJX0FUVFJTCisJdHJpc3RhdGUgImlTQ1NJIFRyYW5z
cG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSSAmJiBORVQKKwlzZWxlY3QgQkxLX0RF
Vl9CU0dMSUIKKwloZWxwCisJICBJZiB5b3Ugd2lzaCB0byBleHBvcnQgdHJhbnNwb3J0LXNwZWNp
ZmljIGluZm9ybWF0aW9uIGFib3V0CisJICBlYWNoIGF0dGFjaGVkIGlTQ1NJIGRldmljZSB0byBz
eXNmcywgc2F5IFkuCisJICBPdGhlcndpc2UsIHNheSBOLgorCitjb25maWcgU0NTSV9TQVNfQVRU
UlMKKwl0cmlzdGF0ZSAiU0FTIFRyYW5zcG9ydCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NT
SQorCXNlbGVjdCBCTEtfREVWX0JTRworCWhlbHAKKwkgIElmIHlvdSB3aXNoIHRvIGV4cG9ydCB0
cmFuc3BvcnQtc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQKKwkgIGVhY2ggYXR0YWNoZWQgU0FT
IGRldmljZSB0byBzeXNmcywgc2F5IFkuCisKK3NvdXJjZSAiZHJpdmVycy9zY3NpL2xpYnNhcy9L
Y29uZmlnIgorCitjb25maWcgU0NTSV9TUlBfQVRUUlMKKwl0cmlzdGF0ZSAiU1JQIFRyYW5zcG9y
dCBBdHRyaWJ1dGVzIgorCWRlcGVuZHMgb24gU0NTSQorCWhlbHAKKwkgIElmIHlvdSB3aXNoIHRv
IGV4cG9ydCB0cmFuc3BvcnQtc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQKKwkgIGVhY2ggYXR0
YWNoZWQgU1JQIGRldmljZSB0byBzeXNmcywgc2F5IFkuCisKK2NvbmZpZyBTQ1NJX1NSUF9UR1Rf
QVRUUlMKKwlib29sICJTQ1NJIHRhcmdldCBzdXBwb3J0IGZvciBTUlAgVHJhbnNwb3J0IEF0dHJp
YnV0ZXMiCisJZGVwZW5kcyBvbiBTQ1NJX1NSUF9BVFRSUworCWRlcGVuZHMgb24gU0NTSV9UR1Qg
PSB5IHx8IFNDU0lfVEdUID0gU0NTSV9TUlBfQVRUUlMKKwloZWxwCisJCUlmIHlvdSB3YW50IHRv
IHVzZSBTQ1NJIHRhcmdldCBtb2RlIGRyaXZlcnMgZW5hYmxlIHRoaXMgb3B0aW9uLgorCitlbmRt
ZW51CisKK21lbnVjb25maWcgU0NTSV9MT1dMRVZFTAorCWJvb2wgIlNDU0kgbG93LWxldmVsIGRy
aXZlcnMiCisJZGVwZW5kcyBvbiBTQ1NJIT1uCisJZGVmYXVsdCB5CisKK2lmIFNDU0lfTE9XTEVW
RUwgJiYgU0NTSQorCitjb25maWcgSVNDU0lfVENQCisJdHJpc3RhdGUgImlTQ1NJIEluaXRpYXRv
ciBvdmVyIFRDUC9JUCIKKwlkZXBlbmRzIG9uIFNDU0kgJiYgSU5FVAorCXNlbGVjdCBDUllQVE8K
KwlzZWxlY3QgQ1JZUFRPX01ENQorCXNlbGVjdCBDUllQVE9fQ1JDMzJDCisJc2VsZWN0IFNDU0lf
SVNDU0lfQVRUUlMKKwloZWxwCisJIFRoZSBpU0NTSSBEcml2ZXIgcHJvdmlkZXMgYSBob3N0IHdp
dGggdGhlIGFiaWxpdHkgdG8gYWNjZXNzIHN0b3JhZ2UKKwkgdGhyb3VnaCBhbiBJUCBuZXR3b3Jr
LiBUaGUgZHJpdmVyIHVzZXMgdGhlIGlTQ1NJIHByb3RvY29sIHRvIHRyYW5zcG9ydAorCSBTQ1NJ
IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgb3ZlciBhIFRDUC9JUCBuZXR3b3JrIGJldHdlZW4gdGhl
IGhvc3QKKwkgKHRoZSAiaW5pdGlhdG9yIikgYW5kICJ0YXJnZXRzIi4gIEFyY2hpdGVjdHVyYWxs
eSwgdGhlIGlTQ1NJIGRyaXZlcgorCSBjb21iaW5lcyB3aXRoIHRoZSBob3N0J3MgVENQL0lQIHN0
YWNrLCBuZXR3b3JrIGRyaXZlcnMsIGFuZCBOZXR3b3JrCisJIEludGVyZmFjZSBDYXJkIChOSUMp
IHRvIHByb3ZpZGUgdGhlIHNhbWUgZnVuY3Rpb25zIGFzIGEgU0NTSSBvciBhCisJIEZpYnJlIENo
YW5uZWwgKEZDKSBhZGFwdGVyIGRyaXZlciB3aXRoIGEgSG9zdCBCdXMgQWRhcHRlciAoSEJBKS4K
KworCSBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0
aGUKKwkgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGlzY3NpX3RjcC4KKworCSBUaGUgdXNlcnNwYWNl
IGNvbXBvbmVudCBuZWVkZWQgdG8gaW5pdGlhbGl6ZSB0aGUgZHJpdmVyLCBkb2N1bWVudGF0aW9u
LAorCSBhbmQgc2FtcGxlIGNvbmZpZ3VyYXRpb24gZmlsZXMgY2FuIGJlIGZvdW5kIGhlcmU6CisK
KwkgaHR0cDovL29wZW4taXNjc2kub3JnCisKK2NvbmZpZyBJU0NTSV9CT09UX1NZU0ZTCisJdHJp
c3RhdGUgImlTQ1NJIEJvb3QgU3lzZnMgSW50ZXJmYWNlIgorCWRlZmF1bHQJbgorCWhlbHAKKwkg
IFRoaXMgb3B0aW9uIGVuYWJsZXMgc3VwcG9ydCBmb3IgZXhwb3NpbmcgaVNDU0kgYm9vdCBpbmZv
cm1hdGlvbgorCSAgdmlhIHN5c2ZzIHRvIHVzZXJzcGFjZS4gSWYgeW91IHdpc2ggdG8gZXhwb3J0
IHRoaXMgaW5mb3JtYXRpb24sCisJICBzYXkgWS4gT3RoZXJ3aXNlLCBzYXkgTi4KKworc291cmNl
ICJkcml2ZXJzL3Njc2kvY3hnYmkvS2NvbmZpZyIKK3NvdXJjZSAiZHJpdmVycy9zY3NpL2JueDJp
L0tjb25maWciCitzb3VyY2UgImRyaXZlcnMvc2NzaS9ibngyZmMvS2NvbmZpZyIKK3NvdXJjZSAi
ZHJpdmVycy9zY3NpL2JlMmlzY3NpL0tjb25maWciCisKK2NvbmZpZyBTR0lXRDkzX1NDU0kKKwl0
cmlzdGF0ZSAiU0dJIFdEOTNDOTMgU0NTSSBEcml2ZXIiCisJZGVwZW5kcyBvbiBTR0lfSEFTX1dE
OTMgJiYgU0NTSQorICAJaGVscAorCSAgSWYgeW91IGhhdmUgYSBXZXN0ZXJuIERpZ2l0YWwgV0Q5
MyBTQ1NJIGNvbnRyb2xsZXIgb24KKwkgIGFuIFNHSSBNSVBTIHN5c3RlbSwgc2F5IFkuICBPdGhl
cndpc2UsIHNheSBOLgorCitjb25maWcgQkxLX0RFVl8zV19YWFhYX1JBSUQKKwl0cmlzdGF0ZSAi
M3dhcmUgNS82LzcvOHh4eCBBVEEtUkFJRCBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFND
U0kKKwloZWxwCisJICAzd2FyZSBpcyB0aGUgb25seSBoYXJkd2FyZSBBVEEtUmFpZCBwcm9kdWN0
IGluIExpbnV4IHRvIGRhdGUuCisJICBUaGlzIGNhcmQgaXMgMiw0LCBvciA4IGNoYW5uZWwgbWFz
dGVyIG1vZGUgc3VwcG9ydCBvbmx5LgorCSAgU0NTSSBzdXBwb3J0IHJlcXVpcmVkISEhCisKKwkg
IDxodHRwOi8vd3d3LjN3YXJlLmNvbS8+CisKKwkgIFBsZWFzZSByZWFkIHRoZSBjb21tZW50cyBh
dCB0aGUgdG9wIG9mCisJICA8ZmlsZTpkcml2ZXJzL3Njc2kvM3cteHh4eC5jPi4KKworY29uZmln
IFNDU0lfSFBTQQorCXRyaXN0YXRlICJIUCBTbWFydCBBcnJheSBTQ1NJIGRyaXZlciIKKwlkZXBl
bmRzIG9uIFBDSSAmJiBTQ1NJCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgSFAgU21h
cnQgQXJyYXkgQ29udHJvbGxlcnMgKGNpcmNhIDIwMDkpLgorCSAgSXQgaXMgYSBTQ1NJIGFsdGVy
bmF0aXZlIHRvIHRoZSBjY2lzcyBkcml2ZXIsIHdoaWNoIGlzIGEgYmxvY2sKKwkgIGRyaXZlci4g
IEFueW9uZSB3aXNoaW5nIHRvIHVzZSBIUCBTbWFydCBBcnJheSBjb250cm9sbGVycyB3aG8KKwkg
IHdvdWxkIHByZWZlciB0aGUgZGV2aWNlcyBiZSBwcmVzZW50ZWQgdG8gbGludXggYXMgU0NTSSBk
ZXZpY2VzLAorCSAgcmF0aGVyIHRoYW4gYXMgZ2VuZXJpYyBibG9jayBkZXZpY2VzIHNob3VsZCBz
YXkgWSBoZXJlLgorCitjb25maWcgU0NTSV8zV185WFhYCisJdHJpc3RhdGUgIjN3YXJlIDl4eHgg
U0FUQS1SQUlEIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhlbHAKKwkgIFRo
aXMgZHJpdmVyIHN1cHBvcnRzIHRoZSA5MDAwIHNlcmllcyAzd2FyZSBTQVRBLVJBSUQgY2FyZHMu
CisKKwkgIDxodHRwOi8vd3d3LmFtY2MuY29tPgorCisJICBQbGVhc2UgcmVhZCB0aGUgY29tbWVu
dHMgYXQgdGhlIHRvcCBvZgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpLzN3LTl4eHguYz4uCisKK2Nv
bmZpZyBTQ1NJXzNXX1NBUworCXRyaXN0YXRlICIzd2FyZSA5N3h4IFNBUy9TQVRBLVJBSUQgc3Vw
cG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3Vw
cG9ydHMgdGhlIExTSSAzd2FyZSA5NzUwIDZHYi9zIFNBUy9TQVRBLVJBSUQgY2FyZHMuCisKKwkg
IDxodHRwOi8vd3d3LmxzaS5jb20+CisKKwkgIFBsZWFzZSByZWFkIHRoZSBjb21tZW50cyBhdCB0
aGUgdG9wIG9mCisJICA8ZmlsZTpkcml2ZXJzL3Njc2kvM3ctc2FzLmM+LgorCitjb25maWcgU0NT
SV83MDAwRkFTU1QKKwl0cmlzdGF0ZSAiNzAwMEZBU1NUIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRz
IG9uIElTQSAmJiBTQ1NJICYmIElTQV9ETUFfQVBJCisJc2VsZWN0IENIRUNLX1NJR05BVFVSRQor
CWhlbHAKKwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIHRoZSBXZXN0ZXJuIERpZ2l0YWwgNzAwMCBT
Q1NJIGhvc3QgYWRhcHRlcgorCSAgZmFtaWx5LiAgU29tZSBpbmZvcm1hdGlvbiBpcyBpbiB0aGUg
c291cmNlOgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpL3dkNzAwMC5jPi4KKworCSAgVG8gY29tcGls
ZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUg
d2lsbCBiZSBjYWxsZWQgd2Q3MDAwLgorCitjb25maWcgU0NTSV9BQ0FSRAorCXRyaXN0YXRlICJB
Q0FSRCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhlbHAKKwkgIFRo
aXMgZHJpdmVyIHN1cHBvcnRzIHRoZSBBQ0FSRCBTQ1NJIGhvc3QgYWRhcHRlci4KKwkgIFN1cHBv
cnQgQ2hpcCA8QVRQODcwIEFUUDg3NiBBVFA4ODAgQVRQODg1PgorCSAgVG8gY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBi
ZSBjYWxsZWQgYXRwODcwdS4KKworY29uZmlnIFNDU0lfQUhBMTUyWAorCXRyaXN0YXRlICJBZGFw
dGVjIEFIQTE1MlgvMjgyNSBzdXBwb3J0IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kgJiYgITY0
QklUCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJc2VsZWN0IENIRUNLX1NJR05BVFVSRQorCS0t
LWhlbHAtLS0KKwkgIFRoaXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBBSEEtMTUxMCwgQUhBLTE1MjAs
IEFIQS0xNTIyLCBhbmQgQUhBLTI4MjUKKwkgIFNDU0kgaG9zdCBhZGFwdGVycy4gSXQgYWxzbyB3
b3JrcyBmb3IgdGhlIEFWQS0xNTA1LCBidXQgdGhlIElSUSBldGMuCisJICBtdXN0IGJlIG1hbnVh
bGx5IHNwZWNpZmllZCBpbiB0aGlzIGNhc2UuCisKKwkgIEl0IGlzIGV4cGxhaW5lZCBpbiBzZWN0
aW9uIDMuMyBvZiB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3
LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4uIFlvdSBtaWdodCBhbHNvIHdhbnQgdG8KKwkgIHJl
YWQgdGhlIGZpbGUgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL2FoYTE1MngudHh0Pi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYWhhMTUyeC4KKworY29uZmlnIFNDU0lfQUhBMTU0Mgor
CXRyaXN0YXRlICJBZGFwdGVjIEFIQTE1NDIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIElTQSAmJiBT
Q1NJICYmIElTQV9ETUFfQVBJCisJLS0taGVscC0tLQorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciBh
IFNDU0kgaG9zdCBhZGFwdGVyLiAgSXQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24KKwkgIDMuNCBv
ZiB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3Jn
L2RvY3MuaHRtbCNob3d0bz4uICBOb3RlIHRoYXQgVHJhbnRvciB3YXMKKwkgIHB1cmNoYXNlZCBi
eSBBZGFwdGVjLCBhbmQgc29tZSBmb3JtZXIgVHJhbnRvciBwcm9kdWN0cyBhcmUgYmVpbmcKKwkg
IHNvbGQgdW5kZXIgdGhlIEFkYXB0ZWMgbmFtZS4gIElmIGl0IGRvZXNuJ3Qgd29yayBvdXQgb2Yg
dGhlIGJveCwgeW91CisJICBtYXkgaGF2ZSB0byBjaGFuZ2Ugc29tZSBzZXR0aW5ncyBpbiA8Zmls
ZTpkcml2ZXJzL3Njc2kvYWhhMTU0Mi5oPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBh
cyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQg
YWhhMTU0Mi4KKworY29uZmlnIFNDU0lfQUhBMTc0MAorCXRyaXN0YXRlICJBZGFwdGVjIEFIQTE3
NDAgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIEVJU0EgJiYgU0NTSQorCS0tLWhlbHAtLS0KKwkgIFRo
aXMgaXMgc3VwcG9ydCBmb3IgYSBTQ1NJIGhvc3QgYWRhcHRlci4gIEl0IGlzIGV4cGxhaW5lZCBp
biBzZWN0aW9uCisJICAzLjUgb2YgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8
aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiAgSWYgaXQgZG9lc24ndCB3b3Jr
IG91dAorCSAgb2YgdGhlIGJveCwgeW91IG1heSBoYXZlIHRvIGNoYW5nZSBzb21lIHNldHRpbmdz
IGluCisJICA8ZmlsZTpkcml2ZXJzL3Njc2kvYWhhMTc0MC5oPi4KKworCSAgVG8gY29tcGlsZSB0
aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2ls
bCBiZSBjYWxsZWQgYWhhMTc0MC4KKworY29uZmlnIFNDU0lfQUFDUkFJRAorCXRyaXN0YXRlICJB
ZGFwdGVjIEFBQ1JBSUQgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0kgJiYgUENJCisJaGVscAor
CSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgYSB2YXJpZXR5IG9mIERlbGwsIEhQLCBBZGFwdGVjLCBJ
Qk0gYW5kCisJICBJQ1Agc3RvcmFnZSBwcm9kdWN0cy4gRm9yIGEgbGlzdCBvZiBzdXBwb3J0ZWQg
cHJvZHVjdHMsIHJlZmVyCisJICB0byA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvYWFjcmFpZC50
eHQ+LgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBo
ZXJlOiB0aGUgbW9kdWxlCisJICB3aWxsIGJlIGNhbGxlZCBhYWNyYWlkLgorCisKK3NvdXJjZSAi
ZHJpdmVycy9zY3NpL2FpYzd4eHgvS2NvbmZpZy5haWM3eHh4IgorCitjb25maWcgU0NTSV9BSUM3
WFhYX09MRAorCXRyaXN0YXRlICJBZGFwdGVjIEFJQzd4eHggc3VwcG9ydCAob2xkIGRyaXZlciki
CisJZGVwZW5kcyBvbiAoSVNBIHx8IEVJU0EgfHwgUENJICkgJiYgU0NTSQorCWhlbHAKKwkgIFdB
Uk5JTkcgVGhpcyBkcml2ZXIgaXMgYW4gb2xkZXIgYWljN3h4eCBkcml2ZXIgYW5kIGlzIG5vIGxv
bmdlcgorCSAgdW5kZXIgYWN0aXZlIGRldmVsb3BtZW50LiAgQWRhcHRlYywgSW5jLiBpcyB3cml0
aW5nIGEgbmV3IGRyaXZlciB0bworCSAgdGFrZSB0aGUgcGxhY2Ugb2YgdGhpcyBvbmUsIGFuZCBp
dCBpcyByZWNvbW1lbmRlZCB0aGF0IHdoZW5ldmVyCisJICBwb3NzaWJsZSwgcGVvcGxlIHNob3Vs
ZCB1c2UgdGhlIG5ldyBBZGFwdGVjIHdyaXR0ZW4gZHJpdmVyIGluc3RlYWQKKwkgIG9mIHRoaXMg
b25lLiAgVGhpcyBkcml2ZXIgd2lsbCBldmVudHVhbGx5IGJlIHBoYXNlZCBvdXQgZW50aXJlbHku
CisKKwkgIFRoaXMgaXMgc3VwcG9ydCBmb3IgdGhlIHZhcmlvdXMgYWljN3h4eCBiYXNlZCBBZGFw
dGVjIFNDU0kKKwkgIGNvbnRyb2xsZXJzLiBUaGVzZSBpbmNsdWRlIHRoZSAyNzR4IEVJU0EgY2Fy
ZHM7IDI4NHggVkxCIGNhcmRzOworCSAgMjkwMiwgMjkxMCwgMjkzeCwgMjk0eCwgMzk0eCwgMzk4
NSBhbmQgc2V2ZXJhbCBvdGhlciBQQ0kgYW5kCisJICBtb3RoZXJib2FyZCBiYXNlZCBTQ1NJIGNv
bnRyb2xsZXJzIGZyb20gQWRhcHRlYy4gSXQgZG9lcyBub3Qgc3VwcG9ydAorCSAgdGhlIEFBQS0x
M3ggUkFJRCBjb250cm9sbGVycyBmcm9tIEFkYXB0ZWMsIG5vciB3aWxsIGl0IGxpa2VseSBldmVy
CisJICBzdXBwb3J0IHRoZW0uIEl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIDI5MjAgY2FyZHMgZnJv
bSBBZGFwdGVjIHRoYXQKKwkgIHVzZSB0aGUgRnV0dXJlIERvbWFpbiBTQ1NJIGNvbnRyb2xsZXIg
Y2hpcC4gRm9yIHRob3NlIGNhcmRzLCB5b3UKKwkgIG5lZWQgdGhlICJGdXR1cmUgRG9tYWluIDE2
eHggU0NTSSBzdXBwb3J0IiBkcml2ZXIuCisKKwkgIEluIGdlbmVyYWwsIGlmIHRoZSBjb250cm9s
bGVyIGlzIGJhc2VkIG9uIGFuIEFkYXB0ZWMgU0NTSSBjb250cm9sbGVyCisJICBjaGlwIGZyb20g
dGhlIGFpYzc3N3ggc2VyaWVzIG9yIHRoZSBhaWM3OHh4IHNlcmllcywgdGhpcyBkcml2ZXIKKwkg
IHNob3VsZCB3b3JrLiBUaGUgb25seSBleGNlcHRpb24gaXMgdGhlIDc4MTAgd2hpY2ggaXMgc3Bl
Y2lmaWNhbGx5CisJICBub3Qgc3VwcG9ydGVkICh0aGF0J3MgdGhlIFJBSUQgY29udHJvbGxlciBj
aGlwIG9uIHRoZSBBQUEtMTN4CisJICBjYXJkcykuCisKKwkgIE5vdGUgdGhhdCB0aGUgQUhBMjky
MCBTQ1NJIGhvc3QgYWRhcHRlciBpcyAqbm90KiBzdXBwb3J0ZWQgYnkgdGhpcworCSAgZHJpdmVy
OyBjaG9vc2UgIkZ1dHVyZSBEb21haW4gMTZ4eCBTQ1NJIHN1cHBvcnQiIGluc3RlYWQgaWYgeW91
IGhhdmUKKwkgIG9uZSBvZiB0aG9zZS4KKworCSAgSW5mb3JtYXRpb24gb24gdGhlIGNvbmZpZ3Vy
YXRpb24gb3B0aW9ucyBmb3IgdGhpcyBjb250cm9sbGVyIGNhbiBiZQorCSAgZm91bmQgYnkgY2hl
Y2tpbmcgdGhlIGhlbHAgZmlsZSBmb3IgZWFjaCBvZiB0aGUgYXZhaWxhYmxlCisJICBjb25maWd1
cmF0aW9uIG9wdGlvbnMuIFlvdSBzaG91bGQgcmVhZAorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9z
Y3NpL2FpYzd4eHhfb2xkLnR4dD4gYXQgYSBtaW5pbXVtIGJlZm9yZQorCSAgY29udGFjdGluZyB0
aGUgbWFpbnRhaW5lciB3aXRoIGFueSBxdWVzdGlvbnMuICBUaGUgU0NTSS1IT1dUTywKKwkgIGF2
YWlsYWJsZSBmcm9tIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4sIGNhbiBh
bHNvCisJICBiZSBvZiBncmVhdCBoZWxwLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFz
IGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBh
aWM3eHh4X29sZC4KKworc291cmNlICJkcml2ZXJzL3Njc2kvYWljN3h4eC9LY29uZmlnLmFpYzc5
eHgiCitzb3VyY2UgImRyaXZlcnMvc2NzaS9haWM5NHh4L0tjb25maWciCitzb3VyY2UgImRyaXZl
cnMvc2NzaS9tdnNhcy9LY29uZmlnIgorCitjb25maWcgU0NTSV9NVlVNSQorCXRyaXN0YXRlICJN
YXJ2ZWxsIFVNSSBkcml2ZXIiCisJZGVwZW5kcyBvbiBTQ1NJICYmIFBDSQorCWhlbHAKKwkgIE1v
ZHVsZSBmb3IgTWFydmVsbCBVbml2ZXJzYWwgTWVzc2FnZSBJbnRlcmZhY2UoVU1JKSBkcml2ZXIK
KworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTog
dGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgbXZ1bWkuCisKK2NvbmZpZyBTQ1NJX0RQVF9J
Mk8KKwl0cmlzdGF0ZSAiQWRhcHRlYyBJMk8gUkFJRCBzdXBwb3J0ICIKKwlkZXBlbmRzIG9uIFND
U0kgJiYgUENJICYmIFZJUlRfVE9fQlVTCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMg
YWxsIG9mIEFkYXB0ZWMncyBJMk8gYmFzZWQgUkFJRCBjb250cm9sbGVycyBhcyAKKwkgIHdlbGwg
YXMgdGhlIERQVCBTbWFydFJhaWQgViBjYXJkcy4gIFRoaXMgaXMgYW4gQWRhcHRlYyBtYWludGFp
bmVkCisJICBkcml2ZXIgYnkgRGVhbm5hIEJvbmRzLiAgU2VlIDxmaWxlOkRvY3VtZW50YXRpb24v
c2NzaS9kcHRpLnR4dD4uCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUs
IGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGRwdF9pMm8uCisK
K2NvbmZpZyBTQ1NJX0FEVkFOU1lTCisJdHJpc3RhdGUgIkFkdmFuU3lzIFNDU0kgc3VwcG9ydCIK
KwlkZXBlbmRzIG9uIFNDU0kgJiYgVklSVF9UT19CVVMKKwlkZXBlbmRzIG9uIElTQSB8fCBFSVNB
IHx8IFBDSQorCWhlbHAKKwkgIFRoaXMgaXMgYSBkcml2ZXIgZm9yIGFsbCBTQ1NJIGhvc3QgYWRh
cHRlcnMgbWFudWZhY3R1cmVkIGJ5CisJICBBZHZhblN5cy4gSXQgaXMgZG9jdW1lbnRlZCBpbiB0
aGUga2VybmVsIHNvdXJjZSBpbgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpL2FkdmFuc3lzLmM+Lgor
CisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0
aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBhZHZhbnN5cy4KKworY29uZmlnIFNDU0lfSU4y
MDAwCisJdHJpc3RhdGUgIkFsd2F5cyBJTjIwMDAgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24g
SVNBICYmIFNDU0kKKwloZWxwCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIGFuIElTQSBidXMgU0NT
SSBob3N0IGFkYXB0ZXIuICBZb3UnbGwgZmluZCBtb3JlCisJICBpbmZvcm1hdGlvbiBpbiA8Zmls
ZTpEb2N1bWVudGF0aW9uL3Njc2kvaW4yMDAwLnR4dD4uIElmIGl0IGRvZXNuJ3Qgd29yaworCSAg
b3V0IG9mIHRoZSBib3gsIHlvdSBtYXkgaGF2ZSB0byBjaGFuZ2UgdGhlIGp1bXBlcnMgZm9yIElS
USBvcgorCSAgYWRkcmVzcyBzZWxlY3Rpb24uCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIg
YXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVk
IGluMjAwMC4KKworY29uZmlnIFNDU0lfQVJDTVNSCisJdHJpc3RhdGUgIkFSRUNBIChBUkMxMXh4
LzEyeHgvMTN4eC8xNnh4KSBTQVRBL1NBUyBSQUlEIEhvc3QgQWRhcHRlciIKKwlkZXBlbmRzIG9u
IFBDSSAmJiBTQ1NJCisJaGVscAorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgYWxsIG9mIEFSRUNB
J3MgU0FUQS9TQVMgUkFJRCBjb250cm9sbGVyIGNhcmRzLgorCSAgVGhpcyBpcyBhbiBBUkVDQS1t
YWludGFpbmVkIGRyaXZlciBieSBFcmljaCBDaGVuLgorCSAgSWYgeW91IGhhdmUgYW55IHByb2Js
ZW1zLCBwbGVhc2UgbWFpbCB0bzogPGVyaWNoQGFyZWNhLmNvbS50dz4uCisJICBBcmVjYSBzdXBw
b3J0cyBMaW51eCBSQUlEIGNvbmZpZyB0b29scy4KKwkgIFBsZWFzZSBsaW5rIDxodHRwOi8vd3d3
LmFyZWNhLmNvbS50dz4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYXJjbXNyIChtb2Rw
cm9iZSBhcmNtc3IpLgorCitzb3VyY2UgImRyaXZlcnMvc2NzaS9tZWdhcmFpZC9LY29uZmlnLm1l
Z2FyYWlkIgorc291cmNlICJkcml2ZXJzL3Njc2kvbXB0MnNhcy9LY29uZmlnIgorCitjb25maWcg
U0NTSV9IUFRJT1AKKwl0cmlzdGF0ZSAiSGlnaFBvaW50IFJvY2tldFJBSUQgM3h4eC80eHh4IENv
bnRyb2xsZXIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0kgJiYgUENJCisJaGVscAorCSAgVGhp
cyBvcHRpb24gZW5hYmxlcyBzdXBwb3J0IGZvciBIaWdoUG9pbnQgUm9ja2V0UkFJRCAzeHh4LzR4
eHgKKwkgIGNvbnRyb2xsZXJzLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9k
dWxlLCBjaG9vc2UgTSBoZXJlOyB0aGUgbW9kdWxlCisJICB3aWxsIGJlIGNhbGxlZCBocHRpb3Au
IElmIHVuc3VyZSwgc2F5IE4uCisKK2NvbmZpZyBTQ1NJX0JVU0xPR0lDCisJdHJpc3RhdGUgIkJ1
c0xvZ2ljIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIChQQ0kgfHwgSVNBIHx8IE1DQSkgJiYg
U0NTSSAmJiBJU0FfRE1BX0FQSSAmJiBWSVJUX1RPX0JVUworCS0tLWhlbHAtLS0KKwkgIFRoaXMg
aXMgc3VwcG9ydCBmb3IgQnVzTG9naWMgTXVsdGlNYXN0ZXIgYW5kIEZsYXNoUG9pbnQgU0NTSSBI
b3N0CisJICBBZGFwdGVycy4gQ29uc3VsdCB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20K
KwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4sIGFuZCB0aGUgZmlsZXMK
KwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9CdXNMb2dpYy50eHQ+IGFuZAorCSAgPGZpbGU6
RG9jdW1lbnRhdGlvbi9zY3NpL0ZsYXNoUG9pbnQudHh0PiBmb3IgbW9yZSBpbmZvcm1hdGlvbi4K
KwkgIE5vdGUgdGhhdCBzdXBwb3J0IGZvciBGbGFzaFBvaW50IGlzIG9ubHkgYXZhaWxhYmxlIGZv
ciAzMi1iaXQKKwkgIHg4NiBjb25maWd1cmF0aW9ucy4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRy
aXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBj
YWxsZWQgQnVzTG9naWMuCisKK2NvbmZpZyBTQ1NJX0ZMQVNIUE9JTlQKKwlib29sICJGbGFzaFBv
aW50IHN1cHBvcnQiCisJZGVwZW5kcyBvbiBTQ1NJX0JVU0xPR0lDICYmIFBDSSAmJiBYODZfMzIK
KwloZWxwCisJICBUaGlzIG9wdGlvbiBhbGxvd3MgeW91IHRvIGFkZCBGbGFzaFBvaW50IHN1cHBv
cnQgdG8gdGhlCisJICBCdXNMb2dpYyBTQ1NJIGRyaXZlci4gVGhlIEZsYXNoUG9pbnQgU0NDQiBN
YW5hZ2VyIGNvZGUgaXMKKwkgIHN1YnN0YW50aWFsLCBzbyB1c2VycyBvZiBNdWx0aU1hc3RlciBI
b3N0IEFkYXB0ZXJzIG1heSBub3QKKwkgIHdpc2ggdG8gaW5jbHVkZSBpdC4KKworY29uZmlnIFZN
V0FSRV9QVlNDU0kKKwl0cmlzdGF0ZSAiVk13YXJlIFBWU0NTSSBkcml2ZXIgc3VwcG9ydCIKKwlk
ZXBlbmRzIG9uIFBDSSAmJiBTQ1NJICYmIFg4NgorCWhlbHAKKwkgIFRoaXMgZHJpdmVyIHN1cHBv
cnRzIFZNd2FyZSdzIHBhcmEgdmlydHVhbGl6ZWQgU0NTSSBIQkEuCisJICBUbyBjb21waWxlIHRo
aXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxs
IGJlIGNhbGxlZCB2bXdfcHZzY3NpLgorCitjb25maWcgTElCRkMKKwl0cmlzdGF0ZSAiTGliRkMg
bW9kdWxlIgorCXNlbGVjdCBTQ1NJX0ZDX0FUVFJTCisJc2VsZWN0IENSQzMyCisJLS0taGVscC0t
LQorCSAgRmlicmUgQ2hhbm5lbCBsaWJyYXJ5IG1vZHVsZQorCitjb25maWcgTElCRkNPRQorCXRy
aXN0YXRlICJMaWJGQ29FIG1vZHVsZSIKKwlzZWxlY3QgTElCRkMKKwktLS1oZWxwLS0tCisJICBM
aWJyYXJ5IGZvciBGaWJyZSBDaGFubmVsIG92ZXIgRXRoZXJuZXQgbW9kdWxlCisKK2NvbmZpZyBG
Q09FCisJdHJpc3RhdGUgIkZDb0UgbW9kdWxlIgorCWRlcGVuZHMgb24gUENJCisJc2VsZWN0IExJ
QkZDT0UKKwktLS1oZWxwLS0tCisJICBGaWJyZSBDaGFubmVsIG92ZXIgRXRoZXJuZXQgbW9kdWxl
CisKK2NvbmZpZyBGQ09FX0ZOSUMKKwl0cmlzdGF0ZSAiQ2lzY28gRk5JQyBEcml2ZXIiCisJZGVw
ZW5kcyBvbiBQQ0kgJiYgWDg2CisJc2VsZWN0IExJQkZDT0UKKwloZWxwCisJICBUaGlzIGlzIHN1
cHBvcnQgZm9yIHRoZSBDaXNjbyBQQ0ktRXhwcmVzcyBGQ29FIEhCQS4KKworCSAgVG8gY29tcGls
ZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZSBhbmQgcmVhZAorCSAgPGZp
bGU6RG9jdW1lbnRhdGlvbi9zY3NpL3Njc2kudHh0Pi4KKwkgIFRoZSBtb2R1bGUgd2lsbCBiZSBj
YWxsZWQgZm5pYy4KKworY29uZmlnIFNDU0lfRE1YMzE5MUQKKwl0cmlzdGF0ZSAiRE1YMzE5MUQg
U0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElf
QVRUUlMKKwloZWxwCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIERvbWV4IERNWDMxOTFEIFNDU0kg
SG9zdCBBZGFwdGVycy4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZG14MzE5MWQuCisK
K2NvbmZpZyBTQ1NJX0RUQzMyODAKKwl0cmlzdGF0ZSAiRFRDMzE4MC8zMjgwIFNDU0kgc3VwcG9y
dCIKKwlkZXBlbmRzIG9uIElTQSAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJc2Vs
ZWN0IENIRUNLX1NJR05BVFVSRQorCWhlbHAKKwkgIFRoaXMgaXMgc3VwcG9ydCBmb3IgRFRDIDMx
ODAvMzI4MCBTQ1NJIEhvc3QgQWRhcHRlcnMuICBQbGVhc2UgcmVhZAorCSAgdGhlIFNDU0ktSE9X
VE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93
dG8+LCBhbmQgdGhlIGZpbGUKKwkgIDxmaWxlOkRvY3VtZW50YXRpb24vc2NzaS9kdGMzeDgwLnR4
dD4uCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhl
cmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGR0Yy4KKworY29uZmlnIFNDU0lfRUFU
QQorCXRyaXN0YXRlICJFQVRBIElTQS9FSVNBL1BDSSAoRFBUIGFuZCBnZW5lcmljIEVBVEEvRE1B
LWNvbXBsaWFudCBib2FyZHMpIHN1cHBvcnQiCisJZGVwZW5kcyBvbiAoSVNBIHx8IEVJU0EgfHwg
UENJKSAmJiBTQ1NJICYmIElTQV9ETUFfQVBJCisJLS0taGVscC0tLQorCSAgVGhpcyBkcml2ZXIg
c3VwcG9ydHMgYWxsIEVBVEEvRE1BLWNvbXBsaWFudCBTQ1NJIGhvc3QgYWRhcHRlcnMuICBEUFQK
KwkgIElTQSBhbmQgYWxsIEVJU0EgSS9PIGFkZHJlc3NlcyBhcmUgcHJvYmVkIGxvb2tpbmcgZm9y
IHRoZSAiRUFUQSIKKwkgIHNpZ25hdHVyZS4gVGhlIGFkZHJlc3NlcyBvZiBhbGwgdGhlIFBDSSBT
Q1NJIGNvbnRyb2xsZXJzIHJlcG9ydGVkCisgICAgICAgICAgYnkgdGhlIFBDSSBzdWJzeXN0ZW0g
YXJlIHByb2JlZCBhcyB3ZWxsLgorCisJICBZb3Ugd2FudCB0byByZWFkIHRoZSBzdGFydCBvZiA8
ZmlsZTpkcml2ZXJzL3Njc2kvZWF0YS5jPiBhbmQgdGhlCisJICBTQ1NJLUhPV1RPLCBhdmFpbGFi
bGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZWF0YS4KKworY29uZmlnIFNDU0lfRUFUQV9UQUdHRURf
UVVFVUUKKwlib29sICJlbmFibGUgdGFnZ2VkIGNvbW1hbmQgcXVldWVpbmciCisJZGVwZW5kcyBv
biBTQ1NJX0VBVEEKKwloZWxwCisJICBUaGlzIGlzIGEgZmVhdHVyZSBvZiBTQ1NJLTIgd2hpY2gg
aW1wcm92ZXMgcGVyZm9ybWFuY2U6IHRoZSBob3N0CisJICBhZGFwdGVyIGNhbiBzZW5kIHNldmVy
YWwgU0NTSSBjb21tYW5kcyB0byBhIGRldmljZSdzIHF1ZXVlIGV2ZW4gaWYKKwkgIHByZXZpb3Vz
IGNvbW1hbmRzIGhhdmVuJ3QgZmluaXNoZWQgeWV0LgorCSAgVGhpcyBpcyBlcXVpdmFsZW50IHRv
IHRoZSAiZWF0YT10Yzp5IiBib290IG9wdGlvbi4KKworY29uZmlnIFNDU0lfRUFUQV9MSU5LRURf
Q09NTUFORFMKKwlib29sICJlbmFibGUgZWxldmF0b3Igc29ydGluZyIKKwlkZXBlbmRzIG9uIFND
U0lfRUFUQQorCWhlbHAKKwkgIFRoaXMgb3B0aW9uIGVuYWJsZXMgZWxldmF0b3Igc29ydGluZyBm
b3IgYWxsIHByb2JlZCBTQ1NJIGRpc2tzIGFuZAorCSAgQ0QtUk9Ncy4gSXQgZGVmaW5pdGVseSBy
ZWR1Y2VzIHRoZSBhdmVyYWdlIHNlZWsgZGlzdGFuY2Ugd2hlbiBkb2luZworCSAgcmFuZG9tIHNl
ZWtzLCBidXQgdGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBub3RpY2VhYmxl
CisJICBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudDogeW91ciBtaWxlYWdlIG1heSB2YXJ5Li4uCisJ
ICBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhlICJlYXRhPWxjOnkiIGJvb3Qgb3B0aW9uLgorCitj
b25maWcgU0NTSV9FQVRBX01BWF9UQUdTCisJaW50ICJtYXhpbXVtIG51bWJlciBvZiBxdWV1ZWQg
Y29tbWFuZHMiCisJZGVwZW5kcyBvbiBTQ1NJX0VBVEEKKwlkZWZhdWx0ICIxNiIKKwloZWxwCisJ
ICBUaGlzIHNwZWNpZmllcyBob3cgbWFueSBTQ1NJIGNvbW1hbmRzIGNhbiBiZSBtYXhpbWFsbHkg
cXVldWVkIGZvcgorCSAgZWFjaCBwcm9iZWQgU0NTSSBkZXZpY2UuIFlvdSBzaG91bGQgcmVkdWNl
IHRoZSBkZWZhdWx0IHZhbHVlIG9mIDE2CisJICBvbmx5IGlmIHlvdSBoYXZlIGRpc2tzIHdpdGgg
YnVnZ3kgb3IgbGltaXRlZCB0YWdnZWQgY29tbWFuZCBzdXBwb3J0LgorCSAgTWluaW11bSBpcyAy
IGFuZCBtYXhpbXVtIGlzIDYyLiBUaGlzIHZhbHVlIGlzIGFsc28gdGhlIHdpbmRvdyBzaXplCisJ
ICB1c2VkIGJ5IHRoZSBlbGV2YXRvciBzb3J0aW5nIG9wdGlvbiBhYm92ZS4gVGhlIGVmZmVjdGl2
ZSB2YWx1ZSB1c2VkCisJICBieSB0aGUgZHJpdmVyIGZvciBlYWNoIHByb2JlZCBTQ1NJIGRldmlj
ZSBpcyByZXBvcnRlZCBhdCBib290IHRpbWUuCisJICBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhl
ICJlYXRhPW1xOjgiIGJvb3Qgb3B0aW9uLgorCitjb25maWcgU0NTSV9FQVRBX1BJTworCXRyaXN0
YXRlICJFQVRBLVBJTyAob2xkIERQVCBQTTIwMDEsIFBNMjAxMkEpIHN1cHBvcnQiCisJZGVwZW5k
cyBvbiAoSVNBIHx8IEVJU0EgfHwgUENJKSAmJiBTQ1NJICYmIEJST0tFTgorCS0tLWhlbHAtLS0K
KwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIGFsbCBFQVRBLVBJTyBwcm90b2NvbCBjb21wbGlhbnQg
U0NTSSBIb3N0CisJICBBZGFwdGVycyBsaWtlIHRoZSBEUFQgUE0yMDAxIGFuZCB0aGUgUE0yMDEy
QS4gIEVBVEEtRE1BIGNvbXBsaWFudAorCSAgaG9zdCBhZGFwdGVycyBjb3VsZCBhbHNvIHVzZSB0
aGlzIGRyaXZlciBidXQgYXJlIGRpc2NvdXJhZ2VkIGZyb20KKwkgIGRvaW5nIHNvLCBzaW5jZSB0
aGlzIGRyaXZlciBvbmx5IHN1cHBvcnRzIGhhcmQgZGlza3MgYW5kIGxhY2tzCisJICBudW1lcm91
cyBmZWF0dXJlcy4gIFlvdSBtaWdodCB3YW50IHRvIGhhdmUgYSBsb29rIGF0IHRoZSBTQ1NJLUhP
V1RPLAorCSAgYXZhaWxhYmxlIGZyb20gPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hv
d3RvPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g
aGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZWF0YV9waW8uCisKK2NvbmZpZyBT
Q1NJX0ZVVFVSRV9ET01BSU4KKwl0cmlzdGF0ZSAiRnV0dXJlIERvbWFpbiAxNnh4IFNDU0kvQUhB
LTI5MjBBIHN1cHBvcnQiCisJZGVwZW5kcyBvbiAoSVNBIHx8IFBDSSkgJiYgU0NTSQorCXNlbGVj
dCBDSEVDS19TSUdOQVRVUkUKKwktLS1oZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIEZ1
dHVyZSBEb21haW4ncyAxNi1iaXQgU0NTSSBob3N0IGFkYXB0ZXJzCisJICAoVE1DLTE2NjAvMTY4
MCwgVE1DLTE2NTAvMTY3MCwgVE1DLTMyNjAsIFRNQy0xNjEwTS9NRVIvTUVYKSBhbmQKKwkgIG90
aGVyIGFkYXB0ZXJzIGJhc2VkIG9uIHRoZSBGdXR1cmUgRG9tYWluIGNoaXBzZXRzIChRdWFudHVt
CisJICBJU0EtMjAwUywgSVNBLTI1ME1HOyBBZGFwdGVjIEFIQS0yOTIwQTsgYW5kIGF0IGxlYXN0
IG9uZSBJQk0gYm9hcmQpLgorCSAgSXQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy43IG9mIHRo
ZSBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9j
cy5odG1sI2hvd3RvPi4KKworCSAgTk9URTogTmV3ZXIgQWRhcHRlYyBBSEEtMjkyMEMgYm9hcmRz
IHVzZSB0aGUgQWRhcHRlYyBBSUMtNzg1MCBjaGlwCisJICBhbmQgc2hvdWxkIHVzZSB0aGUgYWlj
N3h4eCBkcml2ZXIgKCJBZGFwdGVjIEFJQzd4eHggY2hpcHNldCBTQ1NJCisJICBjb250cm9sbGVy
IHN1cHBvcnQiKS4gVGhpcyBGdXR1cmUgRG9tYWluIGRyaXZlciB3b3JrcyB3aXRoIHRoZSBvbGRl
cgorCSAgQWRhcHRlYyBBSEEtMjkyMEEgYm9hcmRzIHdpdGggYSBGdXR1cmUgRG9tYWluIGNoaXAg
b24gdGhlbS4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3Nl
IE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZmRvbWFpbi4KKworY29uZmln
IFNDU0lfRkRfTUNTCisJdHJpc3RhdGUgIkZ1dHVyZSBEb21haW4gTUNTLTYwMC83MDAgU0NTSSBz
dXBwb3J0IgorCWRlcGVuZHMgb24gTUNBX0xFR0FDWSAmJiBTQ1NJCisJLS0taGVscC0tLQorCSAg
VGhpcyBpcyBzdXBwb3J0IGZvciBGdXR1cmUgRG9tYWluIE1DUyA2MDAvNzAwIE1DQSBTQ1NJIGFk
YXB0ZXJzLgorCSAgU29tZSBQUy8yIGNvbXB1dGVycyBhcmUgZXF1aXBwZWQgd2l0aCBJQk0gRmFz
dCBTQ1NJIEFkYXB0ZXIvQSB3aGljaAorCSAgaXMgaWRlbnRpY2FsIHRvIHRoZSBNQ1MgNzAwIGFu
ZCBoZW5jZSBhbHNvIHN1cHBvcnRlZCBieSB0aGlzIGRyaXZlci4KKwkgIFRoaXMgZHJpdmVyIGFs
c28gc3VwcG9ydHMgdGhlIFJlcGx5IFNCMTYvU0NTSSBjYXJkICh0aGUgU0NTSSBwYXJ0KS4KKwkg
IEl0IHN1cHBvcnRzIG11bHRpcGxlIGFkYXB0ZXJzIGluIHRoZSBzYW1lIHN5c3RlbS4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZmRfbWNzLgorCitjb25maWcgU0NTSV9HRFRICisJdHJp
c3RhdGUgIkludGVsL0lDUCAoZm9ybWVyIEdEVCBTQ1NJIERpc2sgQXJyYXkpIFJBSUQgQ29udHJv
bGxlciBzdXBwb3J0IgorCWRlcGVuZHMgb24gKElTQSB8fCBFSVNBIHx8IFBDSSkgJiYgU0NTSSAm
JiBJU0FfRE1BX0FQSQorCS0tLWhlbHAtLS0KKwkgIEZvcm1lcmx5IGNhbGxlZCBHRFQgU0NTSSBE
aXNrIEFycmF5IENvbnRyb2xsZXIgU3VwcG9ydC4KKworCSAgVGhpcyBpcyBhIGRyaXZlciBmb3Ig
UkFJRC9TQ1NJIERpc2sgQXJyYXkgQ29udHJvbGxlcnMgKEVJU0EvSVNBL1BDSSkgCisJICBtYW51
ZmFjdHVyZWQgYnkgSW50ZWwgQ29ycG9yYXRpb24vSUNQIHZvcnRleCBHbWJILiBJdCBpcyBkb2N1
bWVudGVkCisJICBpbiB0aGUga2VybmVsIHNvdXJjZSBpbiA8ZmlsZTpkcml2ZXJzL3Njc2kvZ2R0
aC5jPiBhbmQKKwkgIDxmaWxlOmRyaXZlcnMvc2NzaS9nZHRoLmg+LgorCisJICBUbyBjb21waWxl
IHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3
aWxsIGJlIGNhbGxlZCBnZHRoLgorCitjb25maWcgU0NTSV9JU0NJCisJdHJpc3RhdGUgIkludGVs
KFIpIEM2MDAgU2VyaWVzIENoaXBzZXQgU0FTIENvbnRyb2xsZXIiCisJZGVwZW5kcyBvbiBQQ0kg
JiYgU0NTSQorCWRlcGVuZHMgb24gWDg2CisJc2VsZWN0IFNDU0lfU0FTX0xJQlNBUworCS0tLWhl
bHAtLS0KKwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIHRoZSA2R2IvcyBTQVMgY2FwYWJpbGl0aWVz
IG9mIHRoZSBzdG9yYWdlCisJICBjb250cm9sIHVuaXQgZm91bmQgaW4gdGhlIEludGVsKFIpIEM2
MDAgc2VyaWVzIGNoaXBzZXQuCisKK2NvbmZpZyBTQ1NJX0dFTkVSSUNfTkNSNTM4MAorCXRyaXN0
YXRlICJHZW5lcmljIE5DUjUzODAvNTNjNDAwIFNDU0kgUElPIHN1cHBvcnQiCisJZGVwZW5kcyBv
biBJU0EgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCS0tLWhlbHAtLS0KKwkgIFRo
aXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBvbGQgTkNSIDUzYzgwIHNlcmllcyBvZiBTQ1NJIGNvbnRy
b2xsZXJzCisJICBvbiBib2FyZHMgdXNpbmcgUElPLiBNb3N0IGJvYXJkcyBzdWNoIGFzIHRoZSBU
cmFudG9yIFQxMzAgZml0IHRoaXMKKwkgIGNhdGVnb3J5LCBhbG9uZyB3aXRoIGEgbGFyZ2UgbnVt
YmVyIG9mIElTQSA4Yml0IGNvbnRyb2xsZXJzIHNoaXBwZWQKKwkgIGZvciBmcmVlIHdpdGggU0NT
SSBzY2FubmVycy4gSWYgeW91IGhhdmUgYSBQQVMxNiwgVDEyOCBvciBETVgzMTkxCisJICB5b3Ug
c2hvdWxkIHNlbGVjdCB0aGUgc3BlY2lmaWMgZHJpdmVyIGZvciB0aGF0IGNhcmQgcmF0aGVyIHRo
YW4KKwkgIGdlbmVyaWMgNTM4MCBzdXBwb3J0LgorCisJICBJdCBpcyBleHBsYWluZWQgaW4gc2Vj
dGlvbiAzLjggb2YgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0cDovL3d3
dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiAgSWYgaXQgZG9lc24ndCB3b3JrIG91dAorCSAg
b2YgdGhlIGJveCwgeW91IG1heSBoYXZlIHRvIGNoYW5nZSBzb21lIHNldHRpbmdzIGluCisJICA8
ZmlsZTpkcml2ZXJzL3Njc2kvZ19OQ1I1MzgwLmg+LgorCisJICBUbyBjb21waWxlIHRoaXMgZHJp
dmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNh
bGxlZCBnX05DUjUzODAuCisKK2NvbmZpZyBTQ1NJX0dFTkVSSUNfTkNSNTM4MF9NTUlPCisJdHJp
c3RhdGUgIkdlbmVyaWMgTkNSNTM4MC81M2M0MDAgU0NTSSBNTUlPIHN1cHBvcnQiCisJZGVwZW5k
cyBvbiBJU0EgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCS0tLWhlbHAtLS0KKwkg
IFRoaXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBvbGQgTkNSIDUzYzgwIHNlcmllcyBvZiBTQ1NJIGNv
bnRyb2xsZXJzCisJICBvbiBib2FyZHMgdXNpbmcgbWVtb3J5IG1hcHBlZCBJL08uIAorCSAgSXQg
aXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy44IG9mIHRoZSBTQ1NJLUhPV1RPLCBhdmFpbGFibGUg
ZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4gIElmIGl0IGRv
ZXNuJ3Qgd29yayBvdXQKKwkgIG9mIHRoZSBib3gsIHlvdSBtYXkgaGF2ZSB0byBjaGFuZ2Ugc29t
ZSBzZXR0aW5ncyBpbgorCSAgPGZpbGU6ZHJpdmVycy9zY3NpL2dfTkNSNTM4MC5oPi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZ19OQ1I1MzgwX21taW8uCisKK2NvbmZpZyBTQ1NJX0dF
TkVSSUNfTkNSNTNDNDAwCisJYm9vbCAiRW5hYmxlIE5DUjUzYzQwMCBleHRlbnNpb25zIgorCWRl
cGVuZHMgb24gU0NTSV9HRU5FUklDX05DUjUzODAKKwloZWxwCisJICBUaGlzIGVuYWJsZXMgY2Vy
dGFpbiBvcHRpbWl6YXRpb25zIGZvciB0aGUgTkNSNTNjNDAwIFNDU0kgY2FyZHMuCisJICBZb3Ug
bWlnaHQgYXMgd2VsbCB0cnkgaXQgb3V0LiAgTm90ZSB0aGF0IHRoaXMgZHJpdmVyIHdpbGwgb25s
eSBwcm9iZQorCSAgZm9yIHRoZSBUcmFudG9yIFQxMzBCIGluIGl0cyBkZWZhdWx0IGNvbmZpZ3Vy
YXRpb247IHlvdSBtaWdodCBoYXZlCisJICB0byBwYXNzIGEgY29tbWFuZCBsaW5lIG9wdGlvbiB0
byB0aGUga2VybmVsIGF0IGJvb3QgdGltZSBpZiBpdCBkb2VzCisJICBub3QgZGV0ZWN0IHlvdXIg
Y2FyZC4gIFNlZSB0aGUgZmlsZQorCSAgPGZpbGU6RG9jdW1lbnRhdGlvbi9zY3NpL2dfTkNSNTM4
MC50eHQ+IGZvciBkZXRhaWxzLgorCitjb25maWcgU0NTSV9JQk1NQ0EKKwl0cmlzdGF0ZSAiSUJN
TUNBIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIE1DQSAmJiBTQ1NJCisJLS0taGVscC0tLQor
CSAgVGhpcyBpcyBzdXBwb3J0IGZvciB0aGUgSUJNIFNDU0kgYWRhcHRlciBmb3VuZCBpbiBtYW55
IG9mIHRoZSBQUy8yCisJICBzZXJpZXMgY29tcHV0ZXJzLiAgVGhlc2UgbWFjaGluZXMgaGF2ZSBh
biBNQ0EgYnVzLCBzbyB5b3UgbmVlZCB0bworCSAgYW5zd2VyIFkgdG8gIk1DQSBzdXBwb3J0IiBh
cyB3ZWxsIGFuZCByZWFkCisJICA8ZmlsZTpEb2N1bWVudGF0aW9uL21jYS50eHQ+LgorCisJICBJ
ZiB0aGUgYWRhcHRlciBpc24ndCBmb3VuZCBkdXJpbmcgYm9vdCAoYSBjb21tb24gcHJvYmxlbSBm
b3IgbW9kZWxzCisJICA1NiwgNTcsIDc2LCBhbmQgNzcpIHlvdSdsbCBuZWVkIHRvIHVzZSB0aGUg
J2libW1jYXNjc2k9PHB1bj4nIGtlcm5lbAorCSAgb3B0aW9uLCB3aGVyZSA8cHVuPiBpcyB0aGUg
aWQgb2YgdGhlIFNDU0kgc3Vic3lzdGVtICh1c3VhbGx5IDcsIGJ1dAorCSAgaWYgdGhhdCBkb2Vz
bid0IHdvcmsgY2hlY2sgeW91ciByZWZlcmVuY2UgZGlza2V0dGUpLiAgT3duZXJzIG9mCisJICBt
b2RlbCA5NSB3aXRoIGEgTEVELW1hdHJpeC1kaXNwbGF5IGNhbiBpbiBhZGRpdGlvbiBhY3RpdmF0
ZSBzb21lCisJICBhY3Rpdml0eSBpbmZvIGxpa2UgdW5kZXIgT1MvMiwgYnV0IG1vcmUgaW5mb3Jt
YXRpdmUsIGJ5IHNldHRpbmcKKwkgICdpYm1tY2FzY3NpPWRpc3BsYXknIGFzIGFuIGFkZGl0aW9u
YWwga2VybmVsIHBhcmFtZXRlci4gIFRyeSAibWFuCisJICBib290cGFyYW0iIG9yIHNlZSB0aGUg
ZG9jdW1lbnRhdGlvbiBvZiB5b3VyIGJvb3QgbG9hZGVyIGFib3V0IGhvdyB0bworCSAgcGFzcyBv
cHRpb25zIHRvIHRoZSBrZXJuZWwuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBt
b2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGlibW1j
YS4KKworY29uZmlnIElCTU1DQV9TQ1NJX09SREVSX1NUQU5EQVJECisJYm9vbCAiU3RhbmRhcmQg
U0NTSS1vcmRlciIKKwlkZXBlbmRzIG9uIFNDU0lfSUJNTUNBCisJLS0taGVscC0tLQorCSAgSW4g
dGhlIFBDLXdvcmxkIGFuZCBpbiBtb3N0IG1vZGVybiBTQ1NJLUJJT1Mtc2V0dXBzLCBTQ1NJLWhh
cmQgZGlza3MKKwkgIGFyZSBhc3NpZ25lZCB0byB0aGUgZHJpdmUgbGV0dGVycywgc3RhcnRpbmcg
d2l0aCB0aGUgbG93ZXN0IFNDU0ktaWQKKwkgIChwaHlzaWNhbCBudW1iZXIgLS0gcHVuKSB0byBi
ZSBkcml2ZSBDOiwgYXMgc2VlbiBmcm9tIERPUyBhbmQKKwkgIHNpbWlsYXIgb3BlcmF0aW5nIHN5
c3RlbXMuIFdoZW4gbG9va2luZyBpbnRvIHBhcGVycyBkZXNjcmliaW5nIHRoZQorCSAgQU5TSS1T
Q1NJLXN0YW5kYXJkLCB0aGlzIGFzc2lnbm1lbnQgb2YgZHJpdmVzIGFwcGVhcnMgdG8gYmUgd3Jv
bmcuCisJICBUaGUgU0NTSS1zdGFuZGFyZCBmb2xsb3dzIGEgaGFyZHdhcmUtaGllcmFyY2h5IHdo
aWNoIHNheXMgdGhhdCBpZCA3CisJICBoYXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgYW5kIGlkIDAg
dGhlIGxvd2VzdC4gVGhlcmVmb3JlLCB0aGUgaG9zdAorCSAgYWRhcHRlcnMgYXJlIHN0aWxsIHRv
ZGF5IGV2ZXJ5d2hlcmUgcGxhY2VkIGFzIFNDU0ktaWQgNyBieSBkZWZhdWx0LgorCSAgSW4gdGhl
IFNDU0ktc3RhbmRhcmQsIHRoZSBkcml2ZSBsZXR0ZXJzIGV4cHJlc3MgdGhlIHByaW9yaXR5IG9m
IHRoZQorCSAgZGlzay4gQzogc2hvdWxkIGJlIHRoZSBoYXJkIGRpc2ssIG9yIGEgcGFydGl0aW9u
IG9uIGl0LCB3aXRoIHRoZQorCSAgaGlnaGVzdCBwcmlvcml0eS4gVGhpcyBtdXN0IHRoZXJlZm9y
ZSBiZSB0aGUgZGlzayB3aXRoIHRoZSBoaWdoZXN0CisJICBTQ1NJLWlkIChlLmcuIDYpIGFuZCBu
b3QgdGhlIG9uZSB3aXRoIHRoZSBsb3dlc3QhIElCTS1CSU9TIGtlcHQgdGhlCisJICBvcmlnaW5h
bCBkZWZpbml0aW9uIG9mIHRoZSBTQ1NJLXN0YW5kYXJkIGFzIGFsc28gaW5kdXN0cmlhbC0gYW5k
CisJICBwcm9jZXNzLWNvbnRyb2wtbWFjaGluZXMsIGxpa2UgVk1FLUNQVXMgcnVubmluZyB1bmRl
ciByZWFsdGltZS1PU2VzCisJICAoZS5nLiBMeW54T1MsIE9TOSkgZG8uCisKKwkgIElmIHlvdSBs
aWtlIHRvIHJ1biBMaW51eCBvbiB5b3VyIE1DQS1tYWNoaW5lIHdpdGggdGhlIHNhbWUKKwkgIGFz
c2lnbm1lbnQgb2YgaGFyZCBkaXNrcyBhcyBzZWVuIGZyb20gZS5nLiBET1Mgb3IgT1MvMiBvbiB5
b3VyCisJICBtYWNoaW5lLCB3aGljaCBpcyBpbiBhZGRpdGlvbiBjb25mb3JtYW50IHRvIHRoZSBT
Q1NJLXN0YW5kYXJkLCB5b3UKKwkgIG11c3Qgc2F5IFkgaGVyZS4gVGhpcyBpcyBhbHNvIG5lY2Vz
c2FyeSBmb3IgTUNBLUxpbnV4IHVzZXJzIHdobyB3YW50CisJICB0byBrZWVwIGRvd253YXJkIGNv
bXBhdGliaWxpdHkgdG8gb2xkZXIgcmVsZWFzZXMgb2YgdGhlCisJICBJQk0tTUNBLVNDU0ktZHJp
dmVyIChvbGRlciB0aGFuIGRyaXZlci1yZWxlYXNlIDIuMDAgYW5kIG9sZGVyIHRoYW4KKwkgIEp1
bmUgMTk5NykuCisKKwkgIElmIHlvdSBsaWtlIHRvIGhhdmUgdGhlIGxvd2VzdCBTQ1NJLWlkIGFz
c2lnbmVkIGFzIGRyaXZlIEM6LCBhcworCSAgbW9kZXJuIFNDU0ktQklPU2VzIGRvLCB3aGljaCBk
b2VzIG5vdCBjb25mb3JtIHRvIHRoZSBzdGFuZGFyZCwgYnV0CisJICBpcyB3aWRlc3ByZWFkIGFu
ZCBjb21tb24gaW4gdGhlIFBDLXdvcmxkIG9mIHRvZGF5LCB5b3UgbXVzdCBzYXkgTgorCSAgaGVy
ZS4gSWYgdW5zdXJlLCBzYXkgWS4KKworY29uZmlnIElCTU1DQV9TQ1NJX0RFVl9SRVNFVAorCWJv
b2wgIlJlc2V0IFNDU0ktZGV2aWNlcyBhdCBib290dGltZSIKKwlkZXBlbmRzIG9uIFNDU0lfSUJN
TUNBCisJLS0taGVscC0tLQorCSAgQnkgZGVmYXVsdCwgU0NTSS1kZXZpY2VzIGFyZSByZXNldCB3
aGVuIHRoZSBtYWNoaW5lIGlzIHBvd2VyZWQgb24uCisJICBIb3dldmVyLCBzb21lIGRldmljZXMg
ZXhpc3QsIGxpa2Ugc3BlY2lhbC1jb250cm9sLWRldmljZXMsCisJICBTQ1NJLUNOQy1tYWNoaW5l
cywgU0NTSS1wcmludGVyIG9yIHNjYW5uZXJzIG9mIG9sZGVyIHR5cGUsIHRoYXQgZG8KKwkgIG5v
dCByZXNldCB3aGVuIHN3aXRjaGVkIG9uLiBJZiB5b3Ugc2F5IFkgaGVyZSwgZWFjaCBkZXZpY2Ug
Y29ubmVjdGVkCisJICB0byB5b3VyIFNDU0ktYnVzIHdpbGwgYmUgaXNzdWVkIGEgcmVzZXQtY29t
bWFuZCBhZnRlciBpdCBoYXMgYmVlbgorCSAgcHJvYmVkLCB3aGlsZSB0aGUga2VybmVsIGlzIGJv
b3RpbmcuIFRoaXMgbWF5IGNhdXNlIHByb2JsZW1zIHdpdGgKKwkgIG1vcmUgbW9kZXJuIGRldmlj
ZXMsIGxpa2UgaGFyZCBkaXNrcywgd2hpY2ggZG8gbm90IGFwcHJlY2lhdGUgdGhlc2UKKwkgIHJl
c2V0IGNvbW1hbmRzLCBhbmQgY2FuIGNhdXNlIHlvdXIgc3lzdGVtIHRvIGhhbmcuIFNvIHNheSBZ
IG9ubHkgaWYKKwkgIHlvdSBrbm93IHRoYXQgb25lIG9mIHlvdXIgb2xkZXIgZGV2aWNlcyBuZWVk
cyBpdDsgTiBpcyB0aGUgc2FmZQorCSAgYW5zd2VyLgorCitjb25maWcgU0NTSV9JUFMKKwl0cmlz
dGF0ZSAiSUJNIFNlcnZlUkFJRCBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kKKwkt
LS1oZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRoZSBJQk0gU2VydmVSQUlEIGhhcmR3
YXJlIFJBSUQgY29udHJvbGxlcnMuCisJICBTZWUgPGh0dHA6Ly93d3cuZGV2ZWxvcGVyLmlibS5j
b20vd2VsY29tZS9uZXRmaW5pdHkvc2VydmVyYWlkLmh0bWw+CisJICBhbmQgPGh0dHA6Ly93d3ct
OTQ3LmlibS5jb20vc3VwcG9ydC9lbnRyeS9wb3J0YWwvZG9jZGlzcGxheT9icmFuZD01MDAwMDA4
JmxuZG9jaWQ9U0VSVi1SQUlEPgorCSAgZm9yIG1vcmUgaW5mb3JtYXRpb24uICBJZiB0aGlzIGRy
aXZlciBkb2VzIG5vdCB3b3JrIGNvcnJlY3RseQorCSAgd2l0aG91dCBtb2RpZmljYXRpb24gcGxl
YXNlIGNvbnRhY3QgdGhlIGF1dGhvciBieSBlbWFpbCBhdAorCSAgPGlwc2xpbnV4QGFkYXB0ZWMu
Y29tPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0g
aGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgaXBzLgorCitjb25maWcgU0NTSV9J
Qk1WU0NTSQorCXRyaXN0YXRlICJJQk0gVmlydHVhbCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBv
biBQUENfUFNFUklFUyB8fCBQUENfSVNFUklFUworCXNlbGVjdCBTQ1NJX1NSUF9BVFRSUworCXNl
bGVjdCBWSU9QQVRIIGlmIFBQQ19JU0VSSUVTCisJaGVscAorCSAgVGhpcyBpcyB0aGUgSUJNIFBP
V0VSIFZpcnR1YWwgU0NTSSBDbGllbnQKKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBh
IG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgaWJt
dnNjc2ljLgorCitjb25maWcgU0NTSV9JQk1WU0NTSVMKKwl0cmlzdGF0ZSAiSUJNIFZpcnR1YWwg
U0NTSSBTZXJ2ZXIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBQQ19QU0VSSUVTICYmIFNDU0lfU1JQ
ICYmIFNDU0lfU1JQX1RHVF9BVFRSUworCWhlbHAKKwkgIFRoaXMgaXMgdGhlIFNSUCB0YXJnZXQg
ZHJpdmVyIGZvciBJQk0gcFNlcmllcyB2aXJ0dWFsIGVudmlyb25tZW50cy4KKworCSAgVGhlIHVz
ZXJzcGFjZSBjb21wb25lbnQgbmVlZGVkIHRvIGluaXRpYWxpemUgdGhlIGRyaXZlciBhbmQKKwkg
IGRvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kOgorCisJICBodHRwOi8vc3RndC5iZXJsaW9zLmRl
LworCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJl
OiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBpYm12c3RndC4KKworY29uZmlnIFNDU0lf
SUJNVkZDCisJdHJpc3RhdGUgIklCTSBWaXJ0dWFsIEZDIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQ
UENfUFNFUklFUyAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfRkNfQVRUUlMKKwloZWxwCisJICBUaGlz
IGlzIHRoZSBJQk0gUE9XRVIgVmlydHVhbCBGQyBDbGllbnQKKworCSAgVG8gY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBi
ZSBjYWxsZWQgaWJtdmZjLgorCitjb25maWcgU0NTSV9JQk1WRkNfVFJBQ0UKKwlib29sICJlbmFi
bGUgZHJpdmVyIGludGVybmFsIHRyYWNlIgorCWRlcGVuZHMgb24gU0NTSV9JQk1WRkMKKwlkZWZh
dWx0IHkKKwloZWxwCisJICBJZiB5b3Ugc2F5IFkgaGVyZSwgdGhlIGRyaXZlciB3aWxsIHRyYWNl
IGFsbCBjb21tYW5kcyBpc3N1ZWQKKwkgIHRvIHRoZSBhZGFwdGVyLiBQZXJmb3JtYW5jZSBpbXBh
Y3QgaXMgbWluaW1hbC4gVHJhY2UgY2FuIGJlCisJICBkdW1wZWQgdXNpbmcgL3N5cy9jbGFzcy9z
Y3NpX2hvc3QvaG9zdFhYL3RyYWNlLgorCitjb25maWcgU0NTSV9JTklUSU8KKwl0cmlzdGF0ZSAi
SW5pdGlvIDkxMDBVKFcpIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhlbHAK
KwkgIFRoaXMgaXMgc3VwcG9ydCBmb3IgdGhlIEluaXRpbyA5MVhYVShXKSBTQ1NJIGhvc3QgYWRh
cHRlci4gIFBsZWFzZQorCSAgcmVhZCB0aGUgU0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkg
IDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4uCisKKwkgIFRvIGNvbXBpbGUg
dGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdp
bGwgYmUgY2FsbGVkIGluaXRpby4KKworY29uZmlnIFNDU0lfSU5JQTEwMAorCXRyaXN0YXRlICJJ
bml0aW8gSU5JLUExMDBVMlcgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJCisJaGVs
cAorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciB0aGUgSW5pdGlvIElOSS1BMTAwVTJXIFNDU0kgaG9z
dCBhZGFwdGVyLgorCSAgUGxlYXNlIHJlYWQgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9t
CisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LgorCisJICBUbyBjb21w
aWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVs
ZSB3aWxsIGJlIGNhbGxlZCBhMTAwdTJ3LgorCitjb25maWcgU0NTSV9QUEEKKwl0cmlzdGF0ZSAi
SU9NRUdBIHBhcmFsbGVsIHBvcnQgKHBwYSAtIG9sZGVyIGRyaXZlcykiCisJZGVwZW5kcyBvbiBT
Q1NJICYmIFBBUlBPUlRfUEMKKwktLS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyBv
bGRlciB2ZXJzaW9ucyBvZiBJT01FR0EncyBwYXJhbGxlbCBwb3J0IFpJUAorCSAgZHJpdmUgKGEg
MTAwIE1CIHJlbW92YWJsZSBtZWRpYSBkZXZpY2UpLgorCisJICBOb3RlIHRoYXQgeW91IGNhbiBz
YXkgTiBoZXJlIGlmIHlvdSBoYXZlIHRoZSBTQ1NJIHZlcnNpb24gb2YgdGhlIFpJUAorCSAgZHJp
dmU6IGl0IHdpbGwgYmUgc3VwcG9ydGVkIGF1dG9tYXRpY2FsbHkgaWYgeW91IHNhaWQgWSB0byB0
aGUKKwkgIGdlbmVyaWMgIlNDU0kgZGlzayBzdXBwb3J0IiwgYWJvdmUuCisKKwkgIElmIHlvdSBo
YXZlIHRoZSBaSVAgUGx1cyBkcml2ZSBvciBhIG1vcmUgcmVjZW50IHBhcmFsbGVsIHBvcnQgWklQ
CisJICBkcml2ZSAoaWYgdGhlIHN1cHBsaWVkIGNhYmxlIHdpdGggdGhlIGRyaXZlIGlzIGxhYmVs
ZWQgIkF1dG9EZXRlY3QiKQorCSAgdGhlbiB5b3Ugc2hvdWxkIHNheSBOIGhlcmUgYW5kIFkgdG8g
IklPTUVHQSBwYXJhbGxlbCBwb3J0IChpbW0gLQorCSAgbmV3ZXIgZHJpdmVzKSIsIGJlbG93Lgor
CisJICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIGRyaXZlciBhbmQgaG93IHRvIHVz
ZSBpdCB5b3Ugc2hvdWxkCisJICByZWFkIHRoZSBmaWxlIDxmaWxlOkRvY3VtZW50YXRpb24vc2Nz
aS9wcGEudHh0Pi4gIFlvdSBzaG91bGQgYWxzbyByZWFkCisJICB0aGUgU0NTSS1IT1dUTywgd2hp
Y2ggaXMgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNo
b3d0bz4uICBJZiB5b3UgdXNlIHRoaXMgZHJpdmVyLAorCSAgeW91IHdpbGwgc3RpbGwgYmUgYWJs
ZSB0byB1c2UgdGhlIHBhcmFsbGVsIHBvcnQgZm9yIG90aGVyIHRhc2tzLAorCSAgc3VjaCBhcyBh
IHByaW50ZXI7IGl0IGlzIHNhZmUgdG8gY29tcGlsZSBib3RoIGRyaXZlcnMgaW50byB0aGUKKwkg
IGtlcm5lbC4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3Nl
IE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcHBhLgorCitjb25maWcgU0NT
SV9JTU0KKwl0cmlzdGF0ZSAiSU9NRUdBIHBhcmFsbGVsIHBvcnQgKGltbSAtIG5ld2VyIGRyaXZl
cykiCisJZGVwZW5kcyBvbiBTQ1NJICYmIFBBUlBPUlRfUEMKKwktLS1oZWxwLS0tCisJICBUaGlz
IGRyaXZlciBzdXBwb3J0cyBuZXdlciB2ZXJzaW9ucyBvZiBJT01FR0EncyBwYXJhbGxlbCBwb3J0
IFpJUAorCSAgZHJpdmUgKGEgMTAwIE1CIHJlbW92YWJsZSBtZWRpYSBkZXZpY2UpLgorCisJICBO
b3RlIHRoYXQgeW91IGNhbiBzYXkgTiBoZXJlIGlmIHlvdSBoYXZlIHRoZSBTQ1NJIHZlcnNpb24g
b2YgdGhlIFpJUAorCSAgZHJpdmU6IGl0IHdpbGwgYmUgc3VwcG9ydGVkIGF1dG9tYXRpY2FsbHkg
aWYgeW91IHNhaWQgWSB0byB0aGUKKwkgIGdlbmVyaWMgIlNDU0kgZGlzayBzdXBwb3J0IiwgYWJv
dmUuCisKKwkgIElmIHlvdSBoYXZlIHRoZSBaSVAgUGx1cyBkcml2ZSBvciBhIG1vcmUgcmVjZW50
IHBhcmFsbGVsIHBvcnQgWklQCisJICBkcml2ZSAoaWYgdGhlIHN1cHBsaWVkIGNhYmxlIHdpdGgg
dGhlIGRyaXZlIGlzIGxhYmVsZWQgIkF1dG9EZXRlY3QiKQorCSAgdGhlbiB5b3Ugc2hvdWxkIHNh
eSBZIGhlcmU7IGlmIHlvdSBoYXZlIGFuIG9sZGVyIFpJUCBkcml2ZSwgc2F5IE4KKwkgIGhlcmUg
YW5kIFkgdG8gIklPTUVHQSBQYXJhbGxlbCBQb3J0IChwcGEgLSBvbGRlciBkcml2ZXMpIiwgYWJv
dmUuCisKKwkgIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgZHJpdmVyIGFuZCBob3cg
dG8gdXNlIGl0IHlvdSBzaG91bGQKKwkgIHJlYWQgdGhlIGZpbGUgPGZpbGU6RG9jdW1lbnRhdGlv
bi9zY3NpL3BwYS50eHQ+LiAgWW91IHNob3VsZCBhbHNvIHJlYWQKKwkgIHRoZSBTQ1NJLUhPV1RP
LCB3aGljaCBpcyBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5o
dG1sI2hvd3RvPi4gIElmIHlvdSB1c2UgdGhpcyBkcml2ZXIsCisJICB5b3Ugd2lsbCBzdGlsbCBi
ZSBhYmxlIHRvIHVzZSB0aGUgcGFyYWxsZWwgcG9ydCBmb3Igb3RoZXIgdGFza3MsCisJICBzdWNo
IGFzIGEgcHJpbnRlcjsgaXQgaXMgc2FmZSB0byBjb21waWxlIGJvdGggZHJpdmVycyBpbnRvIHRo
ZQorCSAga2VybmVsLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBj
aG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBpbW0uCisKK2NvbmZp
ZyBTQ1NJX0laSVBfRVBQMTYKKwlib29sICJwcGEvaW1tIG9wdGlvbiAtIFVzZSBzbG93IChidXQg
c2FmZSkgRVBQLTE2IgorCWRlcGVuZHMgb24gU0NTSV9QUEEgfHwgU0NTSV9JTU0KKwktLS1oZWxw
LS0tCisJICBFUFAgKEVuaGFuY2VkIFBhcmFsbGVsIFBvcnQpIGlzIGEgc3RhbmRhcmQgZm9yIHBh
cmFsbGVsIHBvcnRzIHdoaWNoCisJICBhbGxvd3MgdGhlbSB0byBhY3QgYXMgZXhwYW5zaW9uIGJ1
c2VzIHRoYXQgY2FuIGhhbmRsZSB1cCB0byA2NAorCSAgcGVyaXBoZXJhbCBkZXZpY2VzLgorCisJ
ICBTb21lIHBhcmFsbGVsIHBvcnQgY2hpcHNldHMgYXJlIHNsb3dlciB0aGFuIHRoZWlyIG1vdGhl
cmJvYXJkLCBhbmQKKwkgIHNvIHdlIGhhdmUgdG8gY29udHJvbCB0aGUgc3RhdGUgb2YgdGhlIGNo
aXBzZXQncyBGSUZPIHF1ZXVlIGV2ZXJ5CisJICBub3cgYW5kIHRoZW4gdG8gYXZvaWQgZGF0YSBs
b3NzLiBUaGlzIHdpbGwgYmUgZG9uZSBpZiB5b3Ugc2F5IFkKKwkgIGhlcmUuCisKKwkgIEdlbmVy
YWxseSwgc2F5aW5nIFkgaXMgdGhlIHNhZmUgb3B0aW9uIGFuZCBzbG93cyB0aGluZ3MgZG93biBh
IGJpdC4KKworY29uZmlnIFNDU0lfSVpJUF9TTE9XX0NUUgorCWJvb2wgInBwYS9pbW0gb3B0aW9u
IC0gQXNzdW1lIHNsb3cgcGFycG9ydCBjb250cm9sIHJlZ2lzdGVyIgorCWRlcGVuZHMgb24gU0NT
SV9QUEEgfHwgU0NTSV9JTU0KKwloZWxwCisJICBTb21lIHBhcmFsbGVsIHBvcnRzIGFyZSBrbm93
biB0byBoYXZlIGV4Y2Vzc2l2ZSBkZWxheXMgYmV0d2VlbgorCSAgY2hhbmdpbmcgdGhlIHBhcmFs
bGVsIHBvcnQgY29udHJvbCByZWdpc3RlciBhbmQgZ29vZCBkYXRhIGJlaW5nCisJICBhdmFpbGFi
bGUgb24gdGhlIHBhcmFsbGVsIHBvcnQgZGF0YS9zdGF0dXMgcmVnaXN0ZXIuIFRoaXMgb3B0aW9u
CisJICBmb3JjZXMgYSBzbWFsbCBkZWxheSAoMS4wIHVzZWMgdG8gYmUgZXhhY3QpIGFmdGVyIGNo
YW5naW5nIHRoZQorCSAgY29udHJvbCByZWdpc3RlciB0byBsZXQgdGhpbmdzIHNldHRsZSBvdXQu
IEVuYWJsaW5nIHRoaXMgb3B0aW9uIG1heQorCSAgcmVzdWx0IGluIGEgYmlnIGRyb3AgaW4gcGVy
Zm9ybWFuY2UgYnV0IHNvbWUgdmVyeSBvbGQgcGFyYWxsZWwgcG9ydHMKKwkgIChmb3VuZCBpbiAz
ODYgdmludGFnZSBtYWNoaW5lcykgd2lsbCBub3Qgd29yayBwcm9wZXJseS4KKworCSAgR2VuZXJh
bGx5LCBzYXlpbmcgTiBpcyBmaW5lLgorCitjb25maWcgU0NTSV9OQ1I1M0M0MDZBCisJdHJpc3Rh
dGUgIk5DUjUzYzQwNmEgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kKKwlo
ZWxwCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRoZSBOQ1I1M2M0MDZhIFNDU0kgaG9zdCBhZGFw
dGVyLiAgRm9yIHVzZXIKKwkgIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXJzLCBjaGVjayBvdXQgPGZp
bGU6ZHJpdmVycy9zY3NpL05DUjUzYzQwNmEuYz4KKwkgIGluIHRoZSBrZXJuZWwgc291cmNlLiAg
QWxzbyByZWFkIHRoZSBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cu
dGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBh
cyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQg
TkNSNTNjNDA2LgorCitjb25maWcgU0NTSV9OQ1JfRDcwMAorCXRyaXN0YXRlICJOQ1IgRHVhbCA3
MDAgTUNBIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIE1DQSAmJiBTQ1NJCisJc2VsZWN0IFND
U0lfU1BJX0FUVFJTCisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIE1pY3JvQ2hh
bm5lbCBEdWFsIDcwMCBjYXJkIHByb2R1Y2VkIGJ5CisJICBOQ1IgYW5kIGNvbW1vbmx5IHVzZWQg
aW4gMzQ1eC8zNXh4LzQxMDAgY2xhc3MgbWFjaGluZXMuICBJdCBhbHdheXMKKwkgIHRyaWVzIHRv
IG5lZ290aWF0ZSBzeW5jIGFuZCB1c2VzIHRhZyBjb21tYW5kIHF1ZXVlaW5nLgorCisJICBVbmxl
c3MgeW91IGhhdmUgYW4gTkNSIG1hbnVmYWN0dXJlZCBtYWNoaW5lLCB0aGUgY2hhbmNlcyBhcmUg
dGhhdAorCSAgeW91IGRvIG5vdCBoYXZlIHRoaXMgU0NTSSBjYXJkLCBzbyBzYXkgTi4KKworY29u
ZmlnIFNDU0lfTEFTSTcwMAorCXRyaXN0YXRlICJIUCBMYXNpIFNDU0kgc3VwcG9ydCBmb3IgNTNj
NzAwLzcxMCIKKwlkZXBlbmRzIG9uIEdTQyAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJT
CisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIFNDU0kgY29udHJvbGxlciBpbiB0
aGUgTGFzaSBjaGlwIGZvdW5kIGluCisJICBtYW55IFBBLVJJU0Mgd29ya3N0YXRpb25zICYgc2Vy
dmVycy4gIElmIHlvdSBkbyBub3Qga25vdyB3aGV0aGVyIHlvdQorCSAgaGF2ZSBhIExhc2kgY2hp
cCwgaXQgaXMgc2FmZSB0byBzYXkgIlkiIGhlcmUuCisKK2NvbmZpZyBTQ1NJX1NOSV81M0M3MTAK
Kwl0cmlzdGF0ZSAiU05JIFJNIFNDU0kgc3VwcG9ydCBmb3IgNTNjNzEwIgorCWRlcGVuZHMgb24g
U05JX1JNICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwlzZWxlY3QgNTNDNzAwX0xF
X09OX0JFCisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIG9uYm9hcmQgU0NTSSBj
b250cm9sbGVyIGZvdW5kIGluIG9sZGVyCisJICBTTkkgUk0gd29ya3N0YXRpb25zICYgc2VydmVy
cy4KKworY29uZmlnIDUzQzcwMF9MRV9PTl9CRQorCWJvb2wKKwlkZXBlbmRzIG9uIFNDU0lfTEFT
STcwMAorCWRlZmF1bHQgeQorCitjb25maWcgU0NTSV9TVEVYCisJdHJpc3RhdGUgIlByb21pc2Ug
U3VwZXJUcmFrIEVYIFNlcmllcyBzdXBwb3J0IgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kKKwkt
LS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyBQcm9taXNlIFN1cGVyVHJhayBFWCBz
ZXJpZXMgc3RvcmFnZSBjb250cm9sbGVycy4KKworCSAgUHJvbWlzZSBwcm92aWRlcyBMaW51eCBS
QUlEIGNvbmZpZ3VyYXRpb24gdXRpbGl0eSBmb3IgdGhlc2UKKwkgIGNvbnRyb2xsZXJzLiBQbGVh
c2UgdmlzaXQgPGh0dHA6Ly93d3cucHJvbWlzZS5jb20+IHRvIGRvd25sb2FkLgorCisJICBUbyBj
b21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1v
ZHVsZSB3aWxsIGJlIGNhbGxlZCBzdGV4LgorCitjb25maWcgNTNDNzAwX0JFX0JVUworCWJvb2wK
KwlkZXBlbmRzIG9uIFNDU0lfQTQwMDBUIHx8IFNDU0lfWk9SUk83WFggfHwgTVZNRTE2eF9TQ1NJ
IHx8IEJWTUU2MDAwX1NDU0kKKwlkZWZhdWx0IHkKKworY29uZmlnIFNDU0lfU1lNNTNDOFhYXzIK
Kwl0cmlzdGF0ZSAiU1lNNTNDOFhYIFZlcnNpb24gMiBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBv
biBQQ0kgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCS0tLWhlbHAtLS0KKwkgIFRo
aXMgZHJpdmVyIHN1cHBvcnRzIHRoZSB3aG9sZSBOQ1I1M0M4WFgvU1lNNTNDOFhYIGZhbWlseSBv
ZgorCSAgUENJLVNDU0kgY29udHJvbGxlcnMuICBJdCBhbHNvIHN1cHBvcnRzIHRoZSBzdWJzZXQg
b2YgTFNJNTNDMTBYWAorCSAgVWx0cmEtMTYwIGNvbnRyb2xsZXJzIHRoYXQgYXJlIGJhc2VkIG9u
IHRoZSBTWU01M0M4WFggU0NSSVBUUworCSAgbGFuZ3VhZ2UuICBJdCBkb2VzIG5vdCBzdXBwb3J0
IExTSTUzQzEwWFggVWx0cmEtMzIwIFBDSS1YIFNDU0kKKwkgIGNvbnRyb2xsZXJzOyB5b3UgbmVl
ZCB0byB1c2UgdGhlIEZ1c2lvbiBNUFQgZHJpdmVyIGZvciB0aGF0LgorCisJICBQbGVhc2UgcmVh
ZCA8ZmlsZTpEb2N1bWVudGF0aW9uL3Njc2kvc3ltNTNjOHh4XzIudHh0PiBmb3IgbW9yZQorCSAg
aW5mb3JtYXRpb24uCisKK2NvbmZpZyBTQ1NJX1NZTTUzQzhYWF9ETUFfQUREUkVTU0lOR19NT0RF
CisJaW50ICJETUEgYWRkcmVzc2luZyBtb2RlIgorCWRlcGVuZHMgb24gU0NTSV9TWU01M0M4WFhf
MgorCWRlZmF1bHQgIjEiCisJLS0taGVscC0tLQorCSAgVGhpcyBvcHRpb24gb25seSBhcHBsaWVz
IHRvIFBDSS1TQ1NJIGNoaXBzIHRoYXQgYXJlIFBDSSBEQUMKKwkgIGNhcGFibGUgKDg3NUEsIDg5
NUEsIDg5NiwgMTAxMC0zMywgMTAxMC02NiwgMTAwMCkuCisKKwkgIFdoZW4gc2V0IHRvIDAsIHRo
ZSBkcml2ZXIgd2lsbCBwcm9ncmFtIHRoZSBjaGlwIHRvIG9ubHkgcGVyZm9ybQorCSAgMzItYml0
IERNQS4gIFdoZW4gc2V0IHRvIDEsIHRoZSBjaGlwIHdpbGwgYmUgYWJsZSB0byBwZXJmb3JtIERN
QQorCSAgdG8gYWRkcmVzc2VzIHVwIHRvIDFUQi4gIFdoZW4gc2V0IHRvIDIsIHRoZSBkcml2ZXIg
c3VwcG9ydHMgdGhlCisJICBmdWxsIDY0LWJpdCBETUEgYWRkcmVzcyByYW5nZSwgYnV0IGNhbiBv
bmx5IGFkZHJlc3MgMTYgc2VnbWVudHMKKwkgIG9mIDQgR0IgZWFjaC4gIFRoaXMgbGltaXRzIHRo
ZSB0b3RhbCBhZGRyZXNzYWJsZSByYW5nZSB0byA2NCBHQi4KKworCSAgTW9zdCBtYWNoaW5lcyB3
aXRoIGxlc3MgdGhhbiA0R0Igb2YgbWVtb3J5IHNob3VsZCB1c2UgYSBzZXR0aW5nCisJICBvZiAw
IGZvciBiZXN0IHBlcmZvcm1hbmNlLiAgSWYgeW91ciBtYWNoaW5lIGhhcyA0R0Igb2YgbWVtb3J5
CisJICBvciBtb3JlLCB5b3Ugc2hvdWxkIHNldCB0aGlzIG9wdGlvbiB0byAxICh0aGUgZGVmYXVs
dCkuCisKKwkgIFRoZSBzdGlsbCBleHBlcmltZW50YWwgdmFsdWUgMiAoNjQgYml0IERNQSBhZGRy
ZXNzaW5nIHdpdGggMTYKKwkgIHggNEdCIHNlZ21lbnRzIGxpbWl0YXRpb24pIGNhbiBiZSB1c2Vk
IG9uIHN5c3RlbXMgdGhhdCByZXF1aXJlCisJICBQQ0kgYWRkcmVzcyBiaXRzIHBhc3QgYml0IDM5
IHRvIGJlIHNldCBmb3IgdGhlIGFkZHJlc3Npbmcgb2YKKwkgIG1lbW9yeSB1c2luZyBQQ0kgREFD
IGN5Y2xlcy4KKworY29uZmlnIFNDU0lfU1lNNTNDOFhYX0RFRkFVTFRfVEFHUworCWludCAiRGVm
YXVsdCB0YWdnZWQgY29tbWFuZCBxdWV1ZSBkZXB0aCIKKwlkZXBlbmRzIG9uIFNDU0lfU1lNNTND
OFhYXzIKKwlkZWZhdWx0ICIxNiIKKwloZWxwCisJICBUaGlzIGlzIHRoZSBkZWZhdWx0IHZhbHVl
IG9mIHRoZSBjb21tYW5kIHF1ZXVlIGRlcHRoIHRoZQorCSAgZHJpdmVyIHdpbGwgYW5ub3VuY2Ug
dG8gdGhlIGdlbmVyaWMgU0NTSSBsYXllciBmb3IgZGV2aWNlcworCSAgdGhhdCBzdXBwb3J0IHRh
Z2dlZCBjb21tYW5kIHF1ZXVlaW5nLiBUaGlzIHZhbHVlIGNhbiBiZSBjaGFuZ2VkCisJICBmcm9t
IHRoZSBib290IGNvbW1hbmQgbGluZS4gIFRoaXMgaXMgYSBzb2Z0IGxpbWl0IHRoYXQgY2Fubm90
CisJICBleGNlZWQgQ09ORklHX1NDU0lfU1lNNTNDOFhYX01BWF9UQUdTLgorCitjb25maWcgU0NT
SV9TWU01M0M4WFhfTUFYX1RBR1MKKwlpbnQgIk1heGltdW0gbnVtYmVyIG9mIHF1ZXVlZCBjb21t
YW5kcyIKKwlkZXBlbmRzIG9uIFNDU0lfU1lNNTNDOFhYXzIKKwlkZWZhdWx0ICI2NCIKKwloZWxw
CisJICBUaGlzIG9wdGlvbiBhbGxvd3MgeW91IHRvIHNwZWNpZnkgdGhlIG1heGltdW0gbnVtYmVy
IG9mIGNvbW1hbmRzCisJICB0aGF0IGNhbiBiZSBxdWV1ZWQgdG8gYW55IGRldmljZSwgd2hlbiB0
YWdnZWQgY29tbWFuZCBxdWV1aW5nIGlzCisJICBwb3NzaWJsZS4gVGhlIGRyaXZlciBzdXBwb3J0
cyB1cCB0byAyNTYgcXVldWVkIGNvbW1hbmRzIHBlciBkZXZpY2UuCisJICBUaGlzIHZhbHVlIGlz
IHVzZWQgYXMgYSBjb21waWxlZC1pbiBoYXJkIGxpbWl0LgorCitjb25maWcgU0NTSV9TWU01M0M4
WFhfTU1JTworCWJvb2wgIlVzZSBtZW1vcnkgbWFwcGVkIElPIgorCWRlcGVuZHMgb24gU0NTSV9T
WU01M0M4WFhfMgorCWRlZmF1bHQgeQorCWhlbHAKKwkgIE1lbW9yeSBtYXBwZWQgSU8gaXMgZmFz
dGVyIHRoYW4gUG9ydCBJTy4gIE1vc3QgcGVvcGxlIHNob3VsZAorCSAgYW5zd2VyIFkgaGVyZSwg
YnV0IHNvbWUgbWFjaGluZXMgbWF5IGhhdmUgcHJvYmxlbXMuICBJZiB5b3UgaGF2ZQorCSAgdG8g
YW5zd2VyIE4gaGVyZSwgcGxlYXNlIHJlcG9ydCB0aGUgcHJvYmxlbSB0byB0aGUgbWFpbnRhaW5l
ci4KKworY29uZmlnIFNDU0lfSVBSCisJdHJpc3RhdGUgIklCTSBQb3dlciBMaW51eCBSQUlEIGFk
YXB0ZXIgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJICYmIEFUQQorCXNlbGVjdCBG
V19MT0FERVIKKwktLS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyB0aGUgSUJNIFBv
d2VyIExpbnV4IGZhbWlseSBSQUlEIGFkYXB0ZXJzLgorCSAgVGhpcyBpbmNsdWRlcyBJQk0gcFNl
cmllcyA1NzEyLCA1NzAzLCA1NzA5LCBhbmQgNTcwQSwgYXMgd2VsbAorCSAgYXMgSUJNIGlTZXJp
ZXMgNTcwMiwgNTcwMywgNTcwOSwgYW5kIDU3MEEuCisKK2NvbmZpZyBTQ1NJX0lQUl9UUkFDRQor
CWJvb2wgImVuYWJsZSBkcml2ZXIgaW50ZXJuYWwgdHJhY2UiCisJZGVwZW5kcyBvbiBTQ1NJX0lQ
UgorCWRlZmF1bHQgeQorCWhlbHAKKwkgIElmIHlvdSBzYXkgWSBoZXJlLCB0aGUgZHJpdmVyIHdp
bGwgdHJhY2UgYWxsIGNvbW1hbmRzIGlzc3VlZAorCSAgdG8gdGhlIGFkYXB0ZXIuIFBlcmZvcm1h
bmNlIGltcGFjdCBpcyBtaW5pbWFsLiBUcmFjZSBjYW4gYmUKKwkgIGR1bXBlZCB1c2luZyAvc3lz
L2J1cy9jbGFzcy9zY3NpX2hvc3QvaG9zdFhYL3RyYWNlLgorCitjb25maWcgU0NTSV9JUFJfRFVN
UAorCWJvb2wgImVuYWJsZSBhZGFwdGVyIGR1bXAgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFNDU0lf
SVBSCisJZGVmYXVsdCB5CisJaGVscAorCSAgSWYgeW91IHNheSBZIGhlcmUsIHRoZSBkcml2ZXIg
d2lsbCBzdXBwb3J0IGFkYXB0ZXIgY3Jhc2ggZHVtcC4KKwkgIElmIHlvdSBlbmFibGUgdGhpcyBz
dXBwb3J0LCB0aGUgaXByZHVtcCBkYWVtb24gY2FuIGJlIHVzZWQKKwkgIHRvIGNhcHR1cmUgYWRh
cHRlciBmYWlsdXJlIGFuYWx5c2lzIGluZm9ybWF0aW9uLgorCitjb25maWcgU0NTSV9aQUxPTgor
CXRyaXN0YXRlICJaYWxvbiBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBHU0MgJiYgU0NTSQor
CXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoZSBaYWxvbiBpcyBhIEdTQy9IU0Mg
YnVzIGludGVyZmFjZSBjaGlwIHRoYXQgc2l0cyBiZXR3ZWVuIHRoZQorCSAgUEEtUklTQyBwcm9j
ZXNzb3IgYW5kIHRoZSBOQ1IgNTNjNzIwIFNDU0kgY29udHJvbGxlciBvbiBDMTAwLAorCSAgQzEx
MCwgSjIwMCwgSjIxMCBhbmQgc29tZSBELCBLICYgUi1jbGFzcyBtYWNoaW5lcy4gIEl0J3MgYWxz
bworCSAgdXNlZCBvbiB0aGUgYWRkLWluIEJsdWVmaXNoLCBCYXJyYWN1ZGEgJiBTaHJpa2UgU0NT
SSBjYXJkcy4KKwkgIFNheSBZIGhlcmUgaWYgeW91IGhhdmUgb25lIG9mIHRoZXNlIG1hY2hpbmVz
IG9yIGNhcmRzLgorCitjb25maWcgU0NTSV9OQ1JfUTcyMAorCXRyaXN0YXRlICJOQ1IgUXVhZCA3
MjAgTUNBIFNDU0kgc3VwcG9ydCIKKwlkZXBlbmRzIG9uIE1DQSAmJiBTQ1NJCisJc2VsZWN0IFND
U0lfU1BJX0FUVFJTCisJaGVscAorCSAgVGhpcyBpcyBhIGRyaXZlciBmb3IgdGhlIE1pY3JvQ2hh
bm5lbCBRdWFkIDcyMCBjYXJkIHByb2R1Y2VkIGJ5CisJICBOQ1IgYW5kIGNvbW1vbmx5IHVzZWQg
aW4gMzQ1eC8zNXh4LzQxMDAgY2xhc3MgbWFjaGluZXMuICBJdCBhbHdheXMKKwkgIHRyaWVzIHRv
IG5lZ290aWF0ZSBzeW5jIGFuZCB1c2VzIHRhZyBjb21tYW5kIHF1ZXVlaW5nLgorCisJICBVbmxl
c3MgeW91IGhhdmUgYW4gTkNSIG1hbnVmYWN0dXJlZCBtYWNoaW5lLCB0aGUgY2hhbmNlcyBhcmUg
dGhhdAorCSAgeW91IGRvIG5vdCBoYXZlIHRoaXMgU0NTSSBjYXJkLCBzbyBzYXkgTi4KKworY29u
ZmlnIFNDU0lfTkNSNTNDOFhYX0RFRkFVTFRfVEFHUworCWludCAiZGVmYXVsdCB0YWdnZWQgY29t
bWFuZCBxdWV1ZSBkZXB0aCIKKwlkZXBlbmRzIG9uIFNDU0lfWkFMT04gfHwgU0NTSV9OQ1JfUTcy
MAorCWRlZmF1bHQgIjgiCisJLS0taGVscC0tLQorCSAgIlRhZ2dlZCBjb21tYW5kIHF1ZXVpbmci
IGlzIGEgZmVhdHVyZSBvZiBTQ1NJLTIgd2hpY2ggaW1wcm92ZXMKKwkgIHBlcmZvcm1hbmNlOiB0
aGUgaG9zdCBhZGFwdGVyIGNhbiBzZW5kIHNldmVyYWwgU0NTSSBjb21tYW5kcyB0byBhCisJICBk
ZXZpY2UncyBxdWV1ZSBldmVuIGlmIHByZXZpb3VzIGNvbW1hbmRzIGhhdmVuJ3QgZmluaXNoZWQg
eWV0LgorCSAgQmVjYXVzZSB0aGUgZGV2aWNlIGlzIGludGVsbGlnZW50LCBpdCBjYW4gb3B0aW1p
emUgaXRzIG9wZXJhdGlvbnMKKwkgIChsaWtlIGhlYWQgcG9zaXRpb25pbmcpIGJhc2VkIG9uIGl0
cyBvd24gcmVxdWVzdCBxdWV1ZS4gU29tZSBTQ1NJCisJICBkZXZpY2VzIGRvbid0IGltcGxlbWVu
dCB0aGlzIHByb3Blcmx5OyBpZiB5b3Ugd2FudCB0byBkaXNhYmxlIHRoaXMKKwkgIGZlYXR1cmUs
IGVudGVyIDAgb3IgMSBoZXJlIChpdCBkb2Vzbid0IG1hdHRlciB3aGljaCkuCisKKwkgIFRoZSBk
ZWZhdWx0IHZhbHVlIGlzIDggYW5kIHNob3VsZCBiZSBzdXBwb3J0ZWQgYnkgbW9zdCBoYXJkIGRp
c2tzLgorCSAgVGhpcyB2YWx1ZSBjYW4gYmUgb3ZlcnJpZGRlbiBmcm9tIHRoZSBib290IGNvbW1h
bmQgbGluZSB1c2luZyB0aGUKKwkgICd0YWdzJyBvcHRpb24gYXMgZm9sbG93cyAoZXhhbXBsZSk6
CisJICAnbmNyNTNjOHh4PXRhZ3M6NC90MnQzcTE2L3QwdTJxMTAnIHdpbGwgc2V0IGRlZmF1bHQg
cXVldWUgZGVwdGggdG8KKwkgIDQsIHNldCBxdWV1ZSBkZXB0aCB0byAxNiBmb3IgdGFyZ2V0IDIg
YW5kIHRhcmdldCAzIG9uIGNvbnRyb2xsZXIgMAorCSAgYW5kIHNldCBxdWV1ZSBkZXB0aCB0byAx
MCBmb3IgdGFyZ2V0IDAgLyBsdW4gMiBvbiBjb250cm9sbGVyIDEuCisKKwkgIFRoZSBub3JtYWwg
YW5zd2VyIHRoZXJlZm9yZSBpcyB0byBnbyB3aXRoIHRoZSBkZWZhdWx0IDggYW5kIHRvIHVzZQor
CSAgYSBib290IGNvbW1hbmQgbGluZSBvcHRpb24gZm9yIGRldmljZXMgdGhhdCBuZWVkIHRvIHVz
ZSBhIGRpZmZlcmVudAorCSAgY29tbWFuZCBxdWV1ZSBkZXB0aC4KKworCSAgVGhlcmUgaXMgbm8g
c2FmZSBvcHRpb24gb3RoZXIgdGhhbiB1c2luZyBnb29kIFNDU0kgZGV2aWNlcy4KKworY29uZmln
IFNDU0lfTkNSNTNDOFhYX01BWF9UQUdTCisJaW50ICJtYXhpbXVtIG51bWJlciBvZiBxdWV1ZWQg
Y29tbWFuZHMiCisJZGVwZW5kcyBvbiBTQ1NJX1pBTE9OIHx8IFNDU0lfTkNSX1E3MjAKKwlkZWZh
dWx0ICIzMiIKKwktLS1oZWxwLS0tCisJICBUaGlzIG9wdGlvbiBhbGxvd3MgeW91IHRvIHNwZWNp
ZnkgdGhlIG1heGltdW0gbnVtYmVyIG9mIGNvbW1hbmRzCisJICB0aGF0IGNhbiBiZSBxdWV1ZWQg
dG8gYW55IGRldmljZSwgd2hlbiB0YWdnZWQgY29tbWFuZCBxdWV1aW5nIGlzCisJICBwb3NzaWJs
ZS4gVGhlIGRlZmF1bHQgdmFsdWUgaXMgMzIuIE1pbmltdW0gaXMgMiwgbWF4aW11bSBpcyA2NC4K
KwkgIE1vZGVybiBoYXJkIGRpc2tzIGFyZSBhYmxlIHRvIHN1cHBvcnQgNjQgdGFncyBhbmQgZXZl
biBtb3JlLCBidXQKKwkgIGRvIG5vdCBzZWVtIHRvIGJlIGZhc3RlciB3aGVuIG1vcmUgdGhhbiAz
MiB0YWdzIGFyZSBiZWluZyB1c2VkLgorCisJICBTbywgdGhlIG5vcm1hbCBhbnN3ZXIgaGVyZSBp
cyB0byBnbyB3aXRoIHRoZSBkZWZhdWx0IHZhbHVlIDMyIHVubGVzcworCSAgeW91IGFyZSB1c2lu
ZyB2ZXJ5IGxhcmdlIGhhcmQgZGlza3Mgd2l0aCBsYXJnZSBjYWNoZSAoPj0gMSBNQikgdGhhdAor
CSAgYXJlIGFibGUgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgbW9yZSB0aGFuIDMyIHRhZ2dlZCBjb21t
YW5kcy4KKworCSAgVGhlcmUgaXMgbm8gc2FmZSBvcHRpb24gYW5kIHRoZSBkZWZhdWx0IGFuc3dl
ciBpcyByZWNvbW1lbmRlZC4KKworY29uZmlnIFNDU0lfTkNSNTNDOFhYX1NZTkMKKwlpbnQgInN5
bmNocm9ub3VzIHRyYW5zZmVycyBmcmVxdWVuY3kgaW4gTUh6IgorCWRlcGVuZHMgb24gU0NTSV9a
QUxPTiB8fCBTQ1NJX05DUl9RNzIwCisJZGVmYXVsdCAiMjAiCisJLS0taGVscC0tLQorCSAgVGhl
IFNDU0kgUGFyYWxsZWwgSW50ZXJmYWNlLTIgU3RhbmRhcmQgZGVmaW5lcyA1IGNsYXNzZXMgb2Yg
dHJhbnNmZXIKKwkgIHJhdGVzOiBGQVNULTUsIEZBU1QtMTAsIEZBU1QtMjAsIEZBU1QtNDAgYW5k
IEZBU1QtODAuICBUaGUgbnVtYmVycworCSAgYXJlIHJlc3BlY3RpdmVseSB0aGUgbWF4aW11bSBk
YXRhIHRyYW5zZmVyIHJhdGVzIGluIG1lZ2EtdHJhbnNmZXJzCisJICBwZXIgc2Vjb25kIGZvciBl
YWNoIGNsYXNzLiAgRm9yIGV4YW1wbGUsIGEgRkFTVC0yMCBXaWRlIDE2IGRldmljZSBpcworCSAg
YWJsZSB0byB0cmFuc2ZlciBkYXRhIGF0IDIwIG1pbGxpb24gMTYgYml0IHBhY2tldHMgcGVyIHNl
Y29uZCBmb3IgYQorCSAgdG90YWwgcmF0ZSBvZiA0MCBNQi9zLgorCisJICBZb3UgbWF5IHNwZWNp
ZnkgMCBpZiB5b3Ugd2FudCB0byBvbmx5IHVzZSBhc3luY2hyb25vdXMgZGF0YQorCSAgdHJhbnNm
ZXJzLiBUaGlzIGlzIHRoZSBzYWZlc3QgYW5kIHNsb3dlc3Qgb3B0aW9uLiBPdGhlcndpc2UsIHNw
ZWNpZnkKKwkgIGEgdmFsdWUgYmV0d2VlbiA1IGFuZCA4MCwgZGVwZW5kaW5nIG9uIHRoZSBjYXBh
YmlsaXR5IG9mIHlvdXIgU0NTSQorCSAgY29udHJvbGxlci4gIFRoZSBoaWdoZXIgdGhlIG51bWJl
ciwgdGhlIGZhc3RlciB0aGUgZGF0YSB0cmFuc2Zlci4KKwkgIE5vdGUgdGhhdCA4MCBzaG91bGQg
bm9ybWFsbHkgYmUgb2sgc2luY2UgdGhlIGRyaXZlciBkZWNyZWFzZXMgdGhlCisJICB2YWx1ZSBh
dXRvbWF0aWNhbGx5IGFjY29yZGluZyB0byB0aGUgY29udHJvbGxlcidzIGNhcGFiaWxpdGllcy4K
KworCSAgWW91ciBhbnN3ZXIgdG8gdGhpcyBxdWVzdGlvbiBpcyBpZ25vcmVkIGZvciBjb250cm9s
bGVycyB3aXRoIE5WUkFNLAorCSAgc2luY2UgdGhlIGRyaXZlciB3aWxsIGdldCB0aGlzIGluZm9y
bWF0aW9uIGZyb20gdGhlIHVzZXIgc2V0LXVwLiAgSXQKKwkgIGFsc28gY2FuIGJlIG92ZXJyaWRk
ZW4gdXNpbmcgYSBib290IHNldHVwIG9wdGlvbiwgYXMgZm9sbG93cworCSAgKGV4YW1wbGUpOiAn
bmNyNTNjOHh4PXN5bmM6MTInIHdpbGwgYWxsb3cgdGhlIGRyaXZlciB0byBuZWdvdGlhdGUKKwkg
IGZvciBGQVNULTIwIHN5bmNocm9ub3VzIGRhdGEgdHJhbnNmZXIgKDIwIG1lZ2EtdHJhbnNmZXJz
IHBlcgorCSAgc2Vjb25kKS4KKworCSAgVGhlIG5vcm1hbCBhbnN3ZXIgdGhlcmVmb3JlIGlzIG5v
dCB0byBnbyB3aXRoIHRoZSBkZWZhdWx0IGJ1dCB0bworCSAgc2VsZWN0IHRoZSBtYXhpbXVtIHZh
bHVlIDgwIGFsbG93aW5nIHRoZSBkcml2ZXIgdG8gdXNlIHRoZSBtYXhpbXVtCisJICB2YWx1ZSBz
dXBwb3J0ZWQgYnkgZWFjaCBjb250cm9sbGVyLiBJZiB0aGlzIGNhdXNlcyBwcm9ibGVtcyB3aXRo
CisJICB5b3VyIFNDU0kgZGV2aWNlcywgeW91IHNob3VsZCBjb21lIGJhY2sgYW5kIGRlY3JlYXNl
IHRoZSB2YWx1ZS4KKworCSAgVGhlcmUgaXMgbm8gc2FmZSBvcHRpb24gb3RoZXIgdGhhbiB1c2lu
ZyBnb29kIGNhYmxpbmcsIHJpZ2h0CisJICB0ZXJtaW5hdGlvbnMgYW5kIFNDU0kgY29uZm9ybWFu
dCBkZXZpY2VzLgorCitjb25maWcgU0NTSV9OQ1I1M0M4WFhfTk9fRElTQ09OTkVDVAorCWJvb2wg
Im5vdCBhbGxvdyB0YXJnZXRzIHRvIGRpc2Nvbm5lY3QiCisJZGVwZW5kcyBvbiAoU0NTSV9aQUxP
TiB8fCBTQ1NJX05DUl9RNzIwKSAmJiBTQ1NJX05DUjUzQzhYWF9ERUZBVUxUX1RBR1M9MAorCWhl
bHAKKwkgIFRoaXMgb3B0aW9uIGlzIG9ubHkgcHJvdmlkZWQgZm9yIHNhZmV0eSBpZiB5b3Ugc3Vz
cGVjdCBzb21lIFNDU0kKKwkgIGRldmljZSBvZiB5b3VycyB0byBub3Qgc3VwcG9ydCBwcm9wZXJs
eSB0aGUgdGFyZ2V0LWRpc2Nvbm5lY3QKKwkgIGZlYXR1cmUuIEluIHRoYXQgY2FzZSwgeW91IHdv
dWxkIHNheSBZIGhlcmUuIEluIGdlbmVyYWwgaG93ZXZlciwgdG8KKwkgIG5vdCBhbGxvdyB0YXJn
ZXRzIHRvIGRpc2Nvbm5lY3QgaXMgbm90IHJlYXNvbmFibGUgaWYgdGhlcmUgaXMgbW9yZQorCSAg
dGhhbiAxIGRldmljZSBvbiBhIFNDU0kgYnVzLiBUaGUgbm9ybWFsIGFuc3dlciB0aGVyZWZvcmUg
aXMgTi4KKworY29uZmlnIFNDU0lfUEFTMTYKKwl0cmlzdGF0ZSAiUEFTMTYgU0NTSSBzdXBwb3J0
IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwktLS1o
ZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIGEgU0NTSSBob3N0IGFkYXB0ZXIuICBJdCBp
cyBleHBsYWluZWQgaW4gc2VjdGlvbgorCSAgMy4xMCBvZiB0aGUgU0NTSS1IT1dUTywgYXZhaWxh
YmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3MuaHRtbCNob3d0bz4uICBJZiBp
dCBkb2Vzbid0IHdvcmsgb3V0CisJICBvZiB0aGUgYm94LCB5b3UgbWF5IGhhdmUgdG8gY2hhbmdl
IHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOmRyaXZlcnMvc2NzaS9wYXMxNi5oPi4KKworCSAg
VG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJ
ICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcGFzMTYuCisKK2NvbmZpZyBTQ1NJX1FMT0dJQ19GQVMK
Kwl0cmlzdGF0ZSAiUWxvZ2ljIEZBUyBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBJU0EgJiYg
U0NTSQorCS0tLWhlbHAtLS0KKwkgIFRoaXMgaXMgYSBkcml2ZXIgZm9yIHRoZSBJU0EsIFZMQiwg
YW5kIFBDTUNJQSB2ZXJzaW9ucyBvZiB0aGUgUWxvZ2ljCisJICBGYXN0U0NTSSEgY2FyZHMgYXMg
d2VsbCBhcyBhbnkgb3RoZXIgY2FyZCBiYXNlZCBvbiB0aGUgRkFTWFggY2hpcAorCSAgKGluY2x1
ZGluZyB0aGUgQ29udHJvbCBDb25jZXB0cyBTQ1NJL0lERS9TSU8vUElPL0ZEQyBjYXJkcykuCisK
KwkgIFRoaXMgZHJpdmVyIGRvZXMgTk9UIHN1cHBvcnQgdGhlIFBDSSB2ZXJzaW9ucyBvZiB0aGVz
ZSBjYXJkcy4gVGhlCisJICBQQ0kgdmVyc2lvbnMgYXJlIHN1cHBvcnRlZCBieSB0aGUgUWxvZ2lj
IElTUCBkcml2ZXIgKCJRbG9naWMgSVNQCisJICBTQ1NJIHN1cHBvcnQiKSwgYmVsb3cuCisKKwkg
IEluZm9ybWF0aW9uIGFib3V0IHRoaXMgZHJpdmVyIGlzIGNvbnRhaW5lZCBpbgorCSAgPGZpbGU6
RG9jdW1lbnRhdGlvbi9zY3NpL3Fsb2dpY2Zhcy50eHQ+LiAgWW91IHNob3VsZCBhbHNvIHJlYWQg
dGhlCisJICBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQorCSAgPGh0dHA6Ly93d3cudGxkcC5v
cmcvZG9jcy5odG1sI2hvd3RvPi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1v
ZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcWxvZ2lj
ZmFzLgorCitjb25maWcgU0NTSV9RTE9HSUNfMTI4MAorCXRyaXN0YXRlICJRbG9naWMgUUxBIDEy
NDAvMXg4MC8xeDE2MCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCWhl
bHAKKwkgIFNheSBZIGlmIHlvdSBoYXZlIGEgUUxvZ2ljIElTUDEyNDAvMXg4MC8xeDE2MCBTQ1NJ
IGhvc3QgYWRhcHRlci4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgcWxhMTI4MC4KKwor
Y29uZmlnIFNDU0lfUUxPR0lDUFRJCisJdHJpc3RhdGUgIlBUSSBRbG9naWMsIElTUCBEcml2ZXIi
CisJZGVwZW5kcyBvbiBTQlVTICYmIFNDU0kKKwloZWxwCisJICBUaGlzIGRyaXZlciBzdXBwb3J0
cyBTQlVTIFNDU0kgY29udHJvbGxlcnMgZnJvbSBQVEkgb3IgUUxvZ2ljLiBUaGVzZQorCSAgY29u
dHJvbGxlcnMgYXJlIGtub3duIHVuZGVyIFNvbGFyaXMgYXMgcXB0aSBhbmQgaW4gdGhlIG9wZW5w
cm9tIGFzCisJICBQVEkscHRpc3Agb3IgUUxHQyxpc3AuIE5vdGUgdGhhdCBQQ0kgUUxvZ2ljIFND
U0kgY29udHJvbGxlcnMgYXJlCisJICBkcml2ZW4gYnkgYSBkaWZmZXJlbnQgZHJpdmVyLgorCisJ
ICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUK
KwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBxbG9naWNwdGkuCisKK3NvdXJjZSAiZHJpdmVycy9z
Y3NpL3FsYTJ4eHgvS2NvbmZpZyIKK3NvdXJjZSAiZHJpdmVycy9zY3NpL3FsYTR4eHgvS2NvbmZp
ZyIKKworY29uZmlnIFNDU0lfTFBGQworCXRyaXN0YXRlICJFbXVsZXggTGlnaHRQdWxzZSBGaWJy
ZSBDaGFubmVsIFN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCXNlbGVjdCBTQ1NJ
X0ZDX0FUVFJTCisJaGVscAorICAgICAgICAgIFRoaXMgbHBmYyBkcml2ZXIgc3VwcG9ydHMgdGhl
IEVtdWxleCBMaWdodFB1bHNlCisgICAgICAgICAgRmFtaWx5IG9mIEZpYnJlIENoYW5uZWwgUENJ
IGhvc3QgYWRhcHRlcnMuCisKK2NvbmZpZyBTQ1NJX0xQRkNfREVCVUdfRlMKKwlib29sICJFbXVs
ZXggTGlnaHRQdWxzZSBGaWJyZSBDaGFubmVsIGRlYnVnZnMgU3VwcG9ydCIKKwlkZXBlbmRzIG9u
IFNDU0lfTFBGQyAmJiBERUJVR19GUworCWhlbHAKKwkgIFRoaXMgbWFrZXMgZGVidWdnaW5nIGlu
Zm9ybWF0aW9uIGZyb20gdGhlIGxwZmMgZHJpdmVyCisJICBhdmFpbGFibGUgdmlhIHRoZSBkZWJ1
Z2ZzIGZpbGVzeXN0ZW0uCisKK2NvbmZpZyBTQ1NJX1NJTTcxMAorCXRyaXN0YXRlICJTaW1wbGUg
NTNjNzEwIFNDU0kgc3VwcG9ydCAoQ29tcGFxLCBOQ1IgbWFjaGluZXMpIgorCWRlcGVuZHMgb24g
KEVJU0EgfHwgTUNBKSAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJLS0taGVscC0t
LQorCSAgVGhpcyBkcml2ZXIgaXMgZm9yIE5DUjUzYzcxMCBiYXNlZCBTQ1NJIGhvc3QgYWRhcHRl
cnMuCisKKwkgIEl0IGN1cnJlbnRseSBzdXBwb3J0cyBDb21wYXEgRUlTQSBjYXJkcyBhbmQgTkNS
IE1DQSBjYXJkcworCitjb25maWcgU0NTSV9TWU01M0M0MTYKKwl0cmlzdGF0ZSAiU3ltYmlvcyA1
M2M0MTYgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gSVNBICYmIFNDU0kKKwktLS1oZWxwLS0t
CisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRoZSBzeW01M2M0MTYgU0NTSSBob3N0IGFkYXB0ZXIs
IHRoZSBTQ1NJCisJICBhZGFwdGVyIHRoYXQgY29tZXMgd2l0aCBzb21lIEhQIHNjYW5uZXJzLiBU
aGlzIGRyaXZlciByZXF1aXJlcyB0aGF0CisJICB0aGUgc3ltNTNjNDE2IGlzIGNvbmZpZ3VyZWQg
Zmlyc3QgdXNpbmcgc29tZSBzb3J0IG9mIFBuUAorCSAgY29uZmlndXJhdGlvbiBwcm9ncmFtIChl
LmcuIGlzYXBucCkgb3IgYnkgYSBQblAgYXdhcmUgQklPUy4gSWYgeW91CisJICBhcmUgdXNpbmcg
aXNhcG5wIHRoZW4geW91IG5lZWQgdG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZQor
CSAgYW5kIHRoZW4gbG9hZCBpdCB1c2luZyBpbnNtb2QgYWZ0ZXIgaXNhcG5wIGhhcyBydW4uIFRo
ZSBwYXJhbWV0ZXJzCisJICBvZiB0aGUgY29uZmlndXJlZCBjYXJkKHMpIHNob3VsZCBiZSBwYXNz
ZWQgdG8gdGhlIGRyaXZlci4gVGhlIGZvcm1hdAorCSAgaXM6CisKKwkgIGluc21vZCBzeW01M2M0
MTYgc3ltNTNjNDE2PTxiYXNlPiw8aXJxPiBbc3ltNTNjNDE2XzE9PGJhc2U+LDxpcnE+XQorCisJ
ICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUK
KwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBzeW01M2M0MTYuCisKK2NvbmZpZyBTQ1NJX0RDMzk1
eAorCXRyaXN0YXRlICJUZWtyYW0gREMzOTUoVS9VVy9GKSBhbmQgREMzMTUoVSkgU0NTSSBzdXBw
b3J0IChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gUENJICYmIFNDU0kgJiYgRVhQRVJJTUVO
VEFMCisJLS0taGVscC0tLQorCSAgVGhpcyBkcml2ZXIgc3VwcG9ydHMgUENJIFNDU0kgaG9zdCBh
ZGFwdGVycyBiYXNlZCBvbiB0aGUgQVNJQworCSAgVFJNLVMxMDQwIGNoaXAsIGUuZyBUZWtyYW0g
REMzOTUoVS9VVy9GKSBhbmQgREMzMTUoVSkgdmFyaWFudHMuCisKKwkgIFRoaXMgZHJpdmVyIHdv
cmtzLCBidXQgaXMgc3RpbGwgaW4gZXhwZXJpbWVudGFsIHN0YXR1cy4gU28gYmV0dGVyCisJICBo
YXZlIGEgYm9vdGFibGUgZGlzayBhbmQgYSBiYWNrdXAgaW4gY2FzZSBvZiBlbWVyZ2VuY3kuCisK
KwkgIERvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kIGluIDxmaWxlOkRvY3VtZW50YXRpb24vc2Nz
aS9kYzM5NXgudHh0Pi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwg
Y2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgZGMzOTV4LgorCitj
b25maWcgU0NTSV9EQzM5MFQKKwl0cmlzdGF0ZSAiVGVrcmFtIERDMzkwKFQpIGFuZCBBbTUzLzc5
Qzk3NCBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSQorCS0tLWhlbHAtLS0K
KwkgIFRoaXMgZHJpdmVyIHN1cHBvcnRzIFBDSSBTQ1NJIGhvc3QgYWRhcHRlcnMgYmFzZWQgb24g
dGhlIEFtNTNDOTc0QQorCSAgY2hpcCwgZS5nLiBUZWtyYW0gREMzOTAoVCksIERhd2lDb250cm9s
IDI5NzQgYW5kIHNvbWUgb25ib2FyZAorCSAgUENzY3NpL1BDbmV0IChBbTUzLzc5Qzk3NCkgc29s
dXRpb25zLgorCisJICBEb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiA8ZmlsZTpEb2N1bWVu
dGF0aW9uL3Njc2kvdG1zY3NpbS50eHQ+LgorCisJICBOb3RlIHRoYXQgdGhpcyBkcml2ZXIgZG9l
cyBOT1Qgc3VwcG9ydCBUZWtyYW0gREMzOTBXL1UvRiwgd2hpY2ggYXJlCisJICBiYXNlZCBvbiBO
Q1IvU3ltYmlvcyBjaGlwcy4gVXNlICJOQ1I1M0M4WFggU0NTSSBzdXBwb3J0IiBmb3IgdGhvc2Uu
CisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmU6
IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHRtc2NzaW0uCisKK2NvbmZpZyBTQ1NJX1Qx
MjgKKwl0cmlzdGF0ZSAiVHJhbnRvciBUMTI4L1QxMjhGL1QyMjggU0NTSSBzdXBwb3J0IgorCWRl
cGVuZHMgb24gSVNBICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwlzZWxlY3QgQ0hF
Q0tfU0lHTkFUVVJFCisJLS0taGVscC0tLQorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciBhIFNDU0kg
aG9zdCBhZGFwdGVyLiBJdCBpcyBleHBsYWluZWQgaW4gc2VjdGlvbgorCSAgMy4xMSBvZiB0aGUg
U0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3Mu
aHRtbCNob3d0bz4uICBJZiBpdCBkb2Vzbid0IHdvcmsgb3V0CisJICBvZiB0aGUgYm94LCB5b3Ug
bWF5IGhhdmUgdG8gY2hhbmdlIHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOmRyaXZlcnMvc2Nz
aS90MTI4Lmg+LiAgTm90ZSB0aGF0IFRyYW50b3Igd2FzIHB1cmNoYXNlZCBieQorCSAgQWRhcHRl
YywgYW5kIHNvbWUgZm9ybWVyIFRyYW50b3IgcHJvZHVjdHMgYXJlIGJlaW5nIHNvbGQgdW5kZXIg
dGhlCisJICBBZGFwdGVjIG5hbWUuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBt
b2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHQxMjgu
CisKK2NvbmZpZyBTQ1NJX1UxNF8zNEYKKwl0cmlzdGF0ZSAiVWx0cmFTdG9yIDE0Ri8zNEYgc3Vw
cG9ydCIKKwlkZXBlbmRzIG9uIElTQSAmJiBTQ1NJICYmIElTQV9ETUFfQVBJCisJLS0taGVscC0t
LQorCSAgVGhpcyBpcyBzdXBwb3J0IGZvciB0aGUgVWx0cmFTdG9yIDE0RiBhbmQgMzRGIFNDU0kt
MiBob3N0IGFkYXB0ZXJzLgorCSAgVGhlIHNvdXJjZSBhdCA8ZmlsZTpkcml2ZXJzL3Njc2kvdTE0
LTM0Zi5jPiBjb250YWlucyBzb21lCisJICBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIGhhcmR3YXJl
LiAgSWYgdGhlIGRyaXZlciBkb2Vzbid0IHdvcmsgb3V0IG9mCisJICB0aGUgYm94LCB5b3UgbWF5
IGhhdmUgdG8gY2hhbmdlIHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOiBkcml2ZXJzL3Njc2kv
dTE0LTM0Zi5jPi4gIFJlYWQgdGhlIFNDU0ktSE9XVE8sIGF2YWlsYWJsZSBmcm9tCisJICA8aHR0
cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LiAgTm90ZSB0aGF0IHRoZXJlIGlzIGFs
c28KKwkgIGFub3RoZXIgZHJpdmVyIGZvciB0aGUgc2FtZSBoYXJkd2FyZTogIlVsdHJhU3RvciBT
Q1NJIHN1cHBvcnQiLAorCSAgYmVsb3cuICBZb3Ugc2hvdWxkIHNheSBZIHRvIGJvdGggb25seSBp
ZiB5b3Ugd2FudCAyNEYgc3VwcG9ydCBhcworCSAgd2VsbC4KKworCSAgVG8gY29tcGlsZSB0aGlz
IGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBi
ZSBjYWxsZWQgdTE0LTM0Zi4KKworY29uZmlnIFNDU0lfVTE0XzM0Rl9UQUdHRURfUVVFVUUKKwli
b29sICJlbmFibGUgdGFnZ2VkIGNvbW1hbmQgcXVldWVpbmciCisJZGVwZW5kcyBvbiBTQ1NJX1Ux
NF8zNEYKKwloZWxwCisJICBUaGlzIGlzIGEgZmVhdHVyZSBvZiBTQ1NJLTIgd2hpY2ggaW1wcm92
ZXMgcGVyZm9ybWFuY2U6IHRoZSBob3N0CisJICBhZGFwdGVyIGNhbiBzZW5kIHNldmVyYWwgU0NT
SSBjb21tYW5kcyB0byBhIGRldmljZSdzIHF1ZXVlIGV2ZW4gaWYKKwkgIHByZXZpb3VzIGNvbW1h
bmRzIGhhdmVuJ3QgZmluaXNoZWQgeWV0LgorCSAgVGhpcyBpcyBlcXVpdmFsZW50IHRvIHRoZSAi
dTE0LTM0Zj10Yzp5IiBib290IG9wdGlvbi4KKworY29uZmlnIFNDU0lfVTE0XzM0Rl9MSU5LRURf
Q09NTUFORFMKKwlib29sICJlbmFibGUgZWxldmF0b3Igc29ydGluZyIKKwlkZXBlbmRzIG9uIFND
U0lfVTE0XzM0RgorCWhlbHAKKwkgIFRoaXMgb3B0aW9uIGVuYWJsZXMgZWxldmF0b3Igc29ydGlu
ZyBmb3IgYWxsIHByb2JlZCBTQ1NJIGRpc2tzIGFuZAorCSAgQ0QtUk9Ncy4gSXQgZGVmaW5pdGVs
eSByZWR1Y2VzIHRoZSBhdmVyYWdlIHNlZWsgZGlzdGFuY2Ugd2hlbiBkb2luZworCSAgcmFuZG9t
IHNlZWtzLCBidXQgdGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBub3RpY2Vh
YmxlCisJICBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudDogeW91ciBtaWxlYWdlIG1heSB2YXJ5Li4u
CisJICBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhlICJ1MTQtMzRmPWxjOnkiIGJvb3Qgb3B0aW9u
LgorCitjb25maWcgU0NTSV9VMTRfMzRGX01BWF9UQUdTCisJaW50ICJtYXhpbXVtIG51bWJlciBv
ZiBxdWV1ZWQgY29tbWFuZHMiCisJZGVwZW5kcyBvbiBTQ1NJX1UxNF8zNEYKKwlkZWZhdWx0ICI4
IgorCWhlbHAKKwkgIFRoaXMgc3BlY2lmaWVzIGhvdyBtYW55IFNDU0kgY29tbWFuZHMgY2FuIGJl
IG1heGltYWxseSBxdWV1ZWQgZm9yCisJICBlYWNoIHByb2JlZCBTQ1NJIGRldmljZS4gWW91IHNo
b3VsZCByZWR1Y2UgdGhlIGRlZmF1bHQgdmFsdWUgb2YgOAorCSAgb25seSBpZiB5b3UgaGF2ZSBk
aXNrcyB3aXRoIGJ1Z2d5IG9yIGxpbWl0ZWQgdGFnZ2VkIGNvbW1hbmQgc3VwcG9ydC4KKwkgIE1p
bmltdW0gaXMgMiBhbmQgbWF4aW11bSBpcyAxNC4gVGhpcyB2YWx1ZSBpcyBhbHNvIHRoZSB3aW5k
b3cgc2l6ZQorCSAgdXNlZCBieSB0aGUgZWxldmF0b3Igc29ydGluZyBvcHRpb24gYWJvdmUuIFRo
ZSBlZmZlY3RpdmUgdmFsdWUgdXNlZAorCSAgYnkgdGhlIGRyaXZlciBmb3IgZWFjaCBwcm9iZWQg
U0NTSSBkZXZpY2UgaXMgcmVwb3J0ZWQgYXQgYm9vdCB0aW1lLgorCSAgVGhpcyBpcyBlcXVpdmFs
ZW50IHRvIHRoZSAidTE0LTM0Zj1tcTo4IiBib290IG9wdGlvbi4KKworY29uZmlnIFNDU0lfVUxU
UkFTVE9SCisJdHJpc3RhdGUgIlVsdHJhU3RvciBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBY
ODYgJiYgSVNBICYmIFNDU0kKKwktLS1oZWxwLS0tCisJICBUaGlzIGlzIHN1cHBvcnQgZm9yIHRo
ZSBVbHRyYVN0b3IgMTRGLCAyNEYgYW5kIDM0RiBTQ1NJLTIgaG9zdAorCSAgYWRhcHRlciBmYW1p
bHkuICBUaGlzIGRyaXZlciBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiAzLjEyIG9mIHRoZQorCSAg
U0NTSS1IT1dUTywgYXZhaWxhYmxlIGZyb20KKwkgIDxodHRwOi8vd3d3LnRsZHAub3JnL2RvY3Mu
aHRtbCNob3d0bz4uICBJZiBpdCBkb2Vzbid0IHdvcmsgb3V0CisJICBvZiB0aGUgYm94LCB5b3Ug
bWF5IGhhdmUgdG8gY2hhbmdlIHNvbWUgc2V0dGluZ3MgaW4KKwkgIDxmaWxlOmRyaXZlcnMvc2Nz
aS91bHRyYXN0b3IuaD4uCisKKwkgIE5vdGUgdGhhdCB0aGVyZSBpcyBhbHNvIGFub3RoZXIgZHJp
dmVyIGZvciB0aGUgc2FtZSBoYXJkd2FyZToKKwkgICJVbHRyYVN0b3IgMTRGLzM0RiBzdXBwb3J0
IiwgYWJvdmUuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMgYSBtb2R1bGUsIGNob29z
ZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIHVsdHJhc3Rvci4KKworY29u
ZmlnIFNDU0lfTlNQMzIKKwl0cmlzdGF0ZSAiV29ya2JpdCBOaW5qYVNDU0ktMzJCaS9VREUgc3Vw
cG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJICYmICE2NEJJVAorCWhlbHAKKwkgIFRoaXMg
aXMgc3VwcG9ydCBmb3IgdGhlIFdvcmtiaXQgTmluamFTQ1NJLTMyQmkvVURFIFBDSS9DYXJkYnVz
CisJICBTQ1NJIGhvc3QgYWRhcHRlci4gUGxlYXNlIHJlYWQgdGhlIFNDU0ktSE9XVE8sIGF2YWls
YWJsZSBmcm9tCisJICA8aHR0cDovL3d3dy50bGRwLm9yZy9kb2NzLmh0bWwjaG93dG8+LgorCisJ
ICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUK
KwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBuc3AzMi4KKworY29uZmlnIFNDU0lfREVCVUcKKwl0
cmlzdGF0ZSAiU0NTSSBkZWJ1Z2dpbmcgaG9zdCBzaW11bGF0b3IiCisJZGVwZW5kcyBvbiBTQ1NJ
CisJc2VsZWN0IENSQ19UMTBESUYKKwloZWxwCisJICBUaGlzIGlzIGEgaG9zdCBhZGFwdGVyIHNp
bXVsYXRvciB0aGF0IGNhbiBzaW11bGF0ZSBtdWx0aXBsZSBob3N0cworCSAgZWFjaCB3aXRoIG11
bHRpcGxlIGR1bW15IFNDU0kgZGV2aWNlcyAoZGlza3MpLiBJdCBkZWZhdWx0cyB0byBvbmUKKwkg
IGhvc3QgYWRhcHRlciB3aXRoIG9uZSBkdW1teSBTQ1NJIGRpc2suIEVhY2ggZHVtbXkgZGlzayB1
c2VzIGtlcm5lbAorCSAgUkFNIGFzIHN0b3JhZ2UgKGkuZS4gaXQgaXMgYSByYW1kaXNrKS4gVG8g
c2F2ZSBzcGFjZSB3aGVuIG11bHRpcGxlCisJICBkdW1teSBkaXNrcyBhcmUgc2ltdWxhdGVkLCB0
aGV5IHNoYXJlIHRoZSBzYW1lIGtlcm5lbCBSQU0gZm9yIAorCSAgdGhlaXIgc3RvcmFnZS4gU2Vl
IDxodHRwOi8vc2cuZGFubnkuY3ovc2cvc2RlYnVnMjYuaHRtbD4gZm9yIG1vcmUKKwkgIGluZm9y
bWF0aW9uLiBUaGlzIGRyaXZlciBpcyBwcmltYXJpbHkgb2YgdXNlIHRvIHRob3NlIHRlc3Rpbmcg
dGhlCisJICBTQ1NJIGFuZCBibG9jayBzdWJzeXN0ZW1zLiBJZiB1bnN1cmUsIHNheSBOLgorCitj
b25maWcgU0NTSV9NRVNICisJdHJpc3RhdGUgIk1FU0ggKFBvd2VyIE1hYyBpbnRlcm5hbCBTQ1NJ
KSBzdXBwb3J0IgorCWRlcGVuZHMgb24gUFBDMzIgJiYgUFBDX1BNQUMgJiYgU0NTSQorCWhlbHAK
KwkgIE1hbnkgUG93ZXIgTWFjaW50b3NoZXMgYW5kIGNsb25lcyBoYXZlIGEgTUVTSCAoTWFjaW50
b3NoIEVuaGFuY2VkCisJICBTQ1NJIEhhcmR3YXJlKSBTQ1NJIGJ1cyBhZGFwdG9yICh0aGUgNzIw
MCBkb2Vzbid0LCBidXQgYWxsIG9mIHRoZQorCSAgb3RoZXIgUG93ZXIgTWFjaW50b3NoZXMgZG8p
LiBTYXkgWSB0byBpbmNsdWRlIHN1cHBvcnQgZm9yIHRoaXMgU0NTSQorCSAgYWRhcHRvci4KKwor
CSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhl
CisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgbWVzaC4KKworY29uZmlnIFNDU0lfTUVTSF9TWU5D
X1JBVEUKKwlpbnQgIm1heGltdW0gc3luY2hyb25vdXMgdHJhbnNmZXIgcmF0ZSAoTUIvcykgKDAg
PSBhc3luYykiCisJZGVwZW5kcyBvbiBTQ1NJX01FU0gKKwlkZWZhdWx0ICI1IgorCWhlbHAKKwkg
IE9uIFBvd2VyIE1hY2ludG9zaGVzIChhbmQgY2xvbmVzKSB3aGVyZSB0aGUgTUVTSCBTQ1NJIGJ1
cyBhZGFwdG9yCisJICBkcml2ZXMgYSBidXMgd2hpY2ggaXMgZW50aXJlbHkgaW50ZXJuYWwgdG8g
dGhlIG1hY2hpbmUgKHN1Y2ggYXMgdGhlCisJICA3NTAwLCA3NjAwLCA4NTAwLCBldGMuKSwgdGhl
IE1FU0ggaXMgY2FwYWJsZSBvZiBzeW5jaHJvbm91cworCSAgb3BlcmF0aW9uIGF0IHVwIHRvIDEw
IE1CL3MuIE9uIG1hY2hpbmVzIHdoZXJlIHRoZSBTQ1NJIGJ1cworCSAgY29udHJvbGxlZCBieSB0
aGUgTUVTSCBjYW4gaGF2ZSBleHRlcm5hbCBkZXZpY2VzIGNvbm5lY3RlZCwgaXQgaXMKKwkgIHVz
dWFsbHkgcmF0ZWQgYXQgNSBNQi9zLiA1IGlzIGEgc2FmZSB2YWx1ZSBoZXJlIHVubGVzcyB5b3Ug
a25vdyB0aGUKKwkgIE1FU0ggU0NTSSBidXMgaXMgaW50ZXJuYWwgb25seTsgaW4gdGhhdCBjYXNl
IHlvdSBjYW4gc2F5IDEwLiBTYXkgMAorCSAgdG8gZGlzYWJsZSBzeW5jaHJvbm91cyBvcGVyYXRp
b24uCisKK2NvbmZpZyBTQ1NJX01FU0hfUkVTRVRfREVMQVlfTVMKKwlpbnQgImluaXRpYWwgYnVz
IHJlc2V0IGRlbGF5IChtcykgKDAgPSBubyByZXNldCkiCisJZGVwZW5kcyBvbiBTQ1NJX01FU0gK
KwlkZWZhdWx0ICI0MDAwIgorCitjb25maWcgU0NTSV9NQUM1M0M5NAorCXRyaXN0YXRlICI1M0M5
NCAoUG93ZXIgTWFjIGV4dGVybmFsIFNDU0kpIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQUEMzMiAm
JiBQUENfUE1BQyAmJiBTQ1NJCisJaGVscAorCSAgT24gUG93ZXIgTWFjaW50b3NoZXMgKGFuZCBj
bG9uZXMpIHdpdGggdHdvIFNDU0kgYnVzZXMsIHRoZSBleHRlcm5hbAorCSAgU0NTSSBidXMgaXMg
dXN1YWxseSBjb250cm9sbGVkIGJ5IGEgNTNDOTQgU0NTSSBidXMgYWRhcHRvci4gT2xkZXIKKwkg
IG1hY2hpbmVzIHdoaWNoIG9ubHkgaGF2ZSBvbmUgU0NTSSBidXMsIHN1Y2ggYXMgdGhlIDcyMDAs
IGFsc28gdXNlCisJICB0aGUgNTNDOTQuIFNheSBZIHRvIGluY2x1ZGUgc3VwcG9ydCBmb3IgdGhl
IDUzQzk0LgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2Ug
TSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBtYWM1M2M5NC4KKworc291cmNl
ICJkcml2ZXJzL3Njc2kvYXJtL0tjb25maWciCisKK2NvbmZpZyBKQVpaX0VTUAorCWJvb2wgIk1J
UFMgSkFaWiBGQVMyMTYgU0NTSSBzdXBwb3J0IgorCWRlcGVuZHMgb24gTUFDSF9KQVpaICYmIFND
U0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJICBUaGlzIGlzIHRoZSBkcml2ZXIg
Zm9yIHRoZSBvbmJvYXJkIFNDU0kgaG9zdCBhZGFwdGVyIG9mIE1JUFMgTWFnbnVtCisJICA0MDAw
LCBBY2VyIFBJQ0EsIE9saXZldHRpIE03MDAtMTAgYW5kIGEgZmV3IG90aGVyIGlkZW50aWNhbCBP
RU0KKwkgIHN5c3RlbXMuCisKK2NvbmZpZyBBMzAwMF9TQ1NJCisJdHJpc3RhdGUgIkEzMDAwIFdE
MzNDOTNBIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBBTUlHQSAmJiBTQ1NJCisJaGVscAorCSAgSWYg
eW91IGhhdmUgYW4gQW1pZ2EgMzAwMCBhbmQgaGF2ZSBTQ1NJIGRldmljZXMgY29ubmVjdGVkIHRv
IHRoZQorCSAgYnVpbHQtaW4gU0NTSSBjb250cm9sbGVyLCBzYXkgWS4gT3RoZXJ3aXNlLCBzYXkg
Ti4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVy
ZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYTMwMDAuCisKK2NvbmZpZyBBMjA5MV9T
Q1NJCisJdHJpc3RhdGUgIkEyMDkxL0E1OTAgV0QzM0M5M0Egc3VwcG9ydCIKKwlkZXBlbmRzIG9u
IFpPUlJPICYmIFNDU0kKKwloZWxwCisJICBJZiB5b3UgaGF2ZSBhIENvbW1vZG9yZSBBMjA5MSBT
Q1NJIGNvbnRyb2xsZXIsIHNheSBZLiBPdGhlcndpc2UsCisJICBzYXkgTi4KKworCSAgVG8gY29t
cGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlCisJICBtb2R1
bGUgd2lsbCBiZSBjYWxsZWQgYTIwOTEuCisKK2NvbmZpZyBHVlAxMV9TQ1NJCisJdHJpc3RhdGUg
IkdWUCBTZXJpZXMgSUkgV0QzM0M5M0Egc3VwcG9ydCIKKwlkZXBlbmRzIG9uIFpPUlJPICYmIFND
U0kKKwktLS1oZWxwLS0tCisJICBJZiB5b3UgaGF2ZSBhIEdyZWF0IFZhbGxleSBQcm9kdWN0cyBT
ZXJpZXMgSUkgU0NTSSBjb250cm9sbGVyLAorCSAgYW5zd2VyIFkuIEFsc28gc2F5IFkgaWYgeW91
IGhhdmUgYSBsYXRlciBtb2RlbCBvZiBHVlAgU0NTSQorCSAgY29udHJvbGxlciAoc3VjaCBhcyB0
aGUgR1ZQIEE0MDA4IG9yIGEgQ29tYm8gYm9hcmQpLiBPdGhlcndpc2UsCisJICBhbnN3ZXIgTi4g
VGhpcyBkcml2ZXIgZG9lcyBOT1Qgd29yayBmb3IgdGhlIFQtUmV4IHNlcmllcyBvZgorCSAgYWNj
ZWxlcmF0b3JzIGZyb20gVGVrTWFnaWMgYW5kIEdWUC1NLgorCisJICBUbyBjb21waWxlIHRoaXMg
ZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJl
IGNhbGxlZCBndnAxMS4KKworY29uZmlnIFNDU0lfQTQwMDBUCisJdHJpc3RhdGUgIkE0MDAwVCBO
Q1I1M2M3MTAgU0NTSSBzdXBwb3J0IChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gQU1JR0Eg
JiYgU0NTSSAmJiBFWFBFUklNRU5UQUwKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJ
ICBJZiB5b3UgaGF2ZSBhbiBBbWlnYSA0MDAwVCBhbmQgaGF2ZSBTQ1NJIGRldmljZXMgY29ubmVj
dGVkIHRvIHRoZQorCSAgYnVpbHQtaW4gU0NTSSBjb250cm9sbGVyLCBzYXkgWS4gT3RoZXJ3aXNl
LCBzYXkgTi4KKworCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1vZHVsZSwgY2hvb3Nl
IE0gaGVyZTogdGhlCisJICBtb2R1bGUgd2lsbCBiZSBjYWxsZWQgYTQwMDB0LgorCitjb25maWcg
U0NTSV9aT1JSTzdYWAorCXRyaXN0YXRlICJab3JybyBOQ1I1M2M3MTAgU0NTSSBzdXBwb3J0IChF
WFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gWk9SUk8gJiYgU0NTSSAmJiBFWFBFUklNRU5UQUwK
KwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJICBTdXBwb3J0IGZvciB2YXJpb3VzIE5D
UjUzYzcxMC1iYXNlZCBTQ1NJIGNvbnRyb2xsZXJzIG9uIFpvcnJvCisJICBleHBhbnNpb24gYm9h
cmRzIGZvciB0aGUgQW1pZ2EuCisJICBUaGlzIGluY2x1ZGVzOgorCSAgICAtIHRoZSBBbWlnYSA0
MDkxIFpvcnJvIElJSSBTQ1NJLTIgY29udHJvbGxlciwKKwkgICAgLSB0aGUgTWFjcm9TeXN0ZW0g
RGV2ZWxvcG1lbnQncyBXYXJwRW5naW5lIEFtaWdhIFNDU0ktMiBjb250cm9sbGVyCisJICAgICAg
KGluZm8gYXQKKwkgICAgICA8aHR0cDovL3d3dy5seXNhdG9yLmxpdS5zZS9hbWlnYS9hci9ndWlk
ZS9hcjMxMC5ndWlkZT9GRUFUVVJFNT4pLAorCSAgICAtIHRoZSBTQ1NJIGNvbnRyb2xsZXIgb24g
dGhlIFBoYXNlNSBCbGl6emFyZCBQb3dlclVQIDYwM2UrCisJICAgICAgYWNjZWxlcmF0b3IgY2Fy
ZCBmb3IgdGhlIEFtaWdhIDEyMDAsCisJICAgIC0gdGhlIFNDU0kgY29udHJvbGxlciBvbiB0aGUg
R1ZQIFR1cmJvIDA0MC8wNjAgYWNjZWxlcmF0b3IuCisKK2NvbmZpZyBBVEFSSV9TQ1NJCisJdHJp
c3RhdGUgIkF0YXJpIG5hdGl2ZSBTQ1NJIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBBVEFSSSAmJiBT
Q1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJc2VsZWN0IE5WUkFNCisJLS0taGVscC0tLQor
CSAgSWYgeW91IGhhdmUgYW4gQXRhcmkgd2l0aCBidWlsdC1pbiBOQ1I1MzgwIFNDU0kgY29udHJv
bGxlciAoVFQsCisJICBGYWxjb24sIC4uLikgc2F5IFkgdG8gZ2V0IGl0IHN1cHBvcnRlZC4gT2Yg
Y291cnNlIGFsc28sIGlmIHlvdSBoYXZlCisJICBhIGNvbXBhdGlibGUgU0NTSSBjb250cm9sbGVy
IChlLmcuIGZvciBNZWR1c2EpLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9k
dWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBhdGFyaV9z
Y3NpLgorCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyBib3RoIHN0eWxlcyBvZiBOQ1IgaW50ZWdy
YXRpb24gaW50byB0aGUKKwkgIHN5c3RlbTogdGhlIFRUIHN0eWxlIChzZXBhcmF0ZSBETUEpLCBh
bmQgdGhlIEZhbGNvbiBzdHlsZSAodmlhCisJICBTVC1ETUEsIHJlcGxhY2luZyBBQ1NJKS4gIEl0
IGRvZXMgTk9UIHN1cHBvcnQgb3RoZXIgc2NoZW1lcywgbGlrZQorCSAgaW4gdGhlIEhhZGVzICh3
aXRob3V0IERNQSkuCisKK2NvbmZpZyBBVEFSSV9TQ1NJX1RPU0hJQkFfREVMQVkKKwlib29sICJM
b25nIGRlbGF5cyBmb3IgVG9zaGliYSBDRC1ST01zIgorCWRlcGVuZHMgb24gQVRBUklfU0NTSQor
CWhlbHAKKwkgIFRoaXMgb3B0aW9uIGluY3JlYXNlcyB0aGUgZGVsYXkgYWZ0ZXIgYSBTQ1NJIGFy
Yml0cmF0aW9uIHRvCisJICBhY2NvbW1vZGF0ZSBzb21lIGZsYWt5IFRvc2hpYmEgQ0QtUk9NIGRy
aXZlcy4gU2F5IFkgaWYgeW91IGludGVuZCB0bworCSAgdXNlIGEgVG9zaGliYSBDRC1ST00gZHJp
dmU7IG90aGVyd2lzZSwgdGhlIG9wdGlvbiBpcyBub3QgbmVlZGVkIGFuZAorCSAgd291bGQgaW1w
YWN0IHBlcmZvcm1hbmNlIGEgYml0LCBzbyBzYXkgTi4KKworY29uZmlnIEFUQVJJX1NDU0lfUkVT
RVRfQk9PVAorCWJvb2wgIlJlc2V0IFNDU0ktZGV2aWNlcyBhdCBib290dGltZSIKKwlkZXBlbmRz
IG9uIEFUQVJJX1NDU0kKKwloZWxwCisJICBSZXNldCB0aGUgZGV2aWNlcyBvbiB5b3VyIEF0YXJp
IHdoZW5ldmVyIGl0IGJvb3RzLiAgVGhpcyBtYWtlcyB0aGUKKwkgIGJvb3QgcHJvY2VzcyBmcmFj
dGlvbmFsbHkgbG9uZ2VyIGJ1dCBtYXkgYXNzaXN0IHJlY292ZXJ5IGZyb20gZXJyb3JzCisJICB0
aGF0IGxlYXZlIHRoZSBkZXZpY2VzIHdpdGggU0NTSSBvcGVyYXRpb25zIHBhcnR3YXkgY29tcGxl
dGVkLgorCitjb25maWcgTUFDX1NDU0kKKwlib29sICJNYWNpbnRvc2ggTkNSNTM4MCBTQ1NJIgor
CWRlcGVuZHMgb24gTUFDICYmIFNDU0k9eQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAK
KwkgIFRoaXMgaXMgdGhlIE5DUiA1MzgwIFNDU0kgY29udHJvbGxlciBpbmNsdWRlZCBvbiBtb3N0
IG9mIHRoZSA2ODAzMAorCSAgYmFzZWQgTWFjaW50b3NoZXMuICBJZiB5b3UgaGF2ZSBvbmUgb2Yg
dGhlc2Ugc2F5IFkgYW5kIHJlYWQgdGhlCisJICBTQ1NJLUhPV1RPLCBhdmFpbGFibGUgZnJvbQor
CSAgPGh0dHA6Ly93d3cudGxkcC5vcmcvZG9jcy5odG1sI2hvd3RvPi4KKworY29uZmlnIFNDU0lf
TUFDX0VTUAorCXRyaXN0YXRlICJNYWNpbnRvc2ggTkNSNTNjOVs0Nl0gU0NTSSIKKwlkZXBlbmRz
IG9uIE1BQyAmJiBTQ1NJCisJc2VsZWN0IFNDU0lfU1BJX0FUVFJTCisJaGVscAorCSAgVGhpcyBp
cyB0aGUgTkNSIDUzYzl4IFNDU0kgY29udHJvbGxlciBmb3VuZCBvbiBtb3N0IG9mIHRoZSA2ODA0
MAorCSAgYmFzZWQgTWFjaW50b3NoZXMuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMg
YSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZSBtb2R1bGUKKwkgIHdpbGwgYmUgY2FsbGVkIG1h
Y19lc3AuCisKK2NvbmZpZyBNVk1FMTQ3X1NDU0kKKwlib29sICJXRDMzQzkzIFNDU0kgZHJpdmVy
IGZvciBNVk1FMTQ3IgorCWRlcGVuZHMgb24gTVZNRTE0NyAmJiBTQ1NJPXkKKwlzZWxlY3QgU0NT
SV9TUElfQVRUUlMKKwloZWxwCisJICBTdXBwb3J0IGZvciB0aGUgb24tYm9hcmQgU0NTSSBjb250
cm9sbGVyIG9uIHRoZSBNb3Rvcm9sYSBNVk1FMTQ3CisJICBzaW5nbGUtYm9hcmQgY29tcHV0ZXIu
CisKK2NvbmZpZyBNVk1FMTZ4X1NDU0kKKwl0cmlzdGF0ZSAiTkNSNTNDNzEwIFNDU0kgZHJpdmVy
IGZvciBNVk1FMTZ4IgorCWRlcGVuZHMgb24gTVZNRTE2eCAmJiBTQ1NJCisJc2VsZWN0IFNDU0lf
U1BJX0FUVFJTCisJaGVscAorCSAgVGhlIE1vdG9yb2xhIE1WTUUxNjIsIDE2NiwgMTY3LCAxNzIg
YW5kIDE3NyBib2FyZHMgdXNlIHRoZSBOQ1I1M0M3MTAKKwkgIFNDU0kgY29udHJvbGxlciBjaGlw
LiAgQWxtb3N0IGV2ZXJ5b25lIHVzaW5nIG9uZSBvZiB0aGVzZSBib2FyZHMKKwkgIHdpbGwgd2Fu
dCB0byBzYXkgWSB0byB0aGlzIHF1ZXN0aW9uLgorCitjb25maWcgQlZNRTYwMDBfU0NTSQorCXRy
aXN0YXRlICJOQ1I1M0M3MTAgU0NTSSBkcml2ZXIgZm9yIEJWTUU2MDAwIgorCWRlcGVuZHMgb24g
QlZNRTYwMDAgJiYgU0NTSQorCXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoZSBC
Vk1FNDAwMCBhbmQgQlZNRTYwMDAgYm9hcmRzIGZyb20gQlZNIEx0ZCB1c2UgdGhlIE5DUjUzQzcx
MAorCSAgU0NTSSBjb250cm9sbGVyIGNoaXAuICBBbG1vc3QgZXZlcnlvbmUgdXNpbmcgb25lIG9m
IHRoZXNlIGJvYXJkcworCSAgd2lsbCB3YW50IHRvIHNheSBZIHRvIHRoaXMgcXVlc3Rpb24uCisK
K2NvbmZpZyBTVU4zX1NDU0kKKwl0cmlzdGF0ZSAiU3VuMyBOQ1I1MzgwIFNDU0kiCisJZGVwZW5k
cyBvbiBTVU4zICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TUElfQVRUUlMKKwloZWxwCisJICBUaGlz
IG9wdGlvbiB3aWxsIGVuYWJsZSBzdXBwb3J0IGZvciB0aGUgT0JJTyAob25ib2FyZCBpbykgTkNS
NTM4MAorCSAgU0NTSSBjb250cm9sbGVyIGZvdW5kIGluIHRoZSBTdW4gMy81MCBhbmQgMy82MCwg
YXMgd2VsbCBhcyBmb3IKKwkgICJTdW4zIiB0eXBlIFZNRSBzY3NpIGNvbnRyb2xsZXJzIGFsc28g
YmFzZWQgb24gdGhlIE5DUjUzODAuCisJICBHZW5lcmFsIExpbnV4IGluZm9ybWF0aW9uIG9uIHRo
ZSBTdW4gMyBzZXJpZXMgKG5vdyBkaXNjb250aW51ZWQpCisJICBpcyBhdCA8aHR0cDovL3d3dy5h
bmdlbGZpcmUuY29tL2NhMi90ZWNoNjhrL3N1bjMuaHRtbD4uCisKK2NvbmZpZyBTVU4zWF9FU1AK
Kwlib29sICJTdW4zeCBFU1AgU0NTSSIKKwlkZXBlbmRzIG9uIFNVTjNYICYmIFNDU0k9eQorCXNl
bGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoZSBFU1Agd2FzIGFuIG9uLWJvYXJkIFND
U0kgY29udHJvbGxlciB1c2VkIG9uIFN1biAzLzgwCisJICBtYWNoaW5lcy4gIFNheSBZIGhlcmUg
dG8gY29tcGlsZSBpbiBzdXBwb3J0IGZvciBpdC4KKworY29uZmlnIFNDU0lfU1VORVNQCisJdHJp
c3RhdGUgIlNwYXJjIEVTUCBTY3NpIERyaXZlciIKKwlkZXBlbmRzIG9uIFNCVVMgJiYgU0NTSQor
CXNlbGVjdCBTQ1NJX1NQSV9BVFRSUworCWhlbHAKKwkgIFRoaXMgaXMgdGhlIGRyaXZlciBmb3Ig
dGhlIFN1biBFU1AgU0NTSSBob3N0IGFkYXB0ZXIuIFRoZSBFU1AKKwkgIGNoaXBzZXQgaXMgcHJl
c2VudCBpbiBtb3N0IFNQQVJDIFNCVVMtYmFzZWQgY29tcHV0ZXJzIGFuZAorCSAgc3VwcG9ydHMg
dGhlIEVtdWxleCBmYW1pbHkgb2YgRVNQIFNDU0kgY2hpcHMgKGVzcDEwMCwgZXNwMTAwQSwKKwkg
IGVzcDIzNiwgZmFzMTAxLCBmYXMyMzYpIGFzIHdlbGwgYXMgdGhlIFFsb2dpYyBmYXMzNjYgU0NT
SSBjaGlwLgorCisJICBUbyBjb21waWxlIHRoaXMgZHJpdmVyIGFzIGEgbW9kdWxlLCBjaG9vc2Ug
TSBoZXJlOiB0aGUKKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxlZCBzdW5fZXNwLgorCitjb25maWcg
WkZDUAorCXRyaXN0YXRlICJGQ1AgaG9zdCBidXMgYWRhcHRlciBkcml2ZXIgZm9yIElCTSBlU2Vy
dmVyIHpTZXJpZXMiCisJZGVwZW5kcyBvbiBTMzkwICYmIFFESU8gJiYgU0NTSQorCXNlbGVjdCBT
Q1NJX0ZDX0FUVFJTCisJaGVscAorICAgICAgICAgIElmIHlvdSB3YW50IHRvIGFjY2VzcyBTQ1NJ
IGRldmljZXMgYXR0YWNoZWQgdG8geW91ciBJQk0gZVNlcnZlcgorICAgICAgICAgIHpTZXJpZXMg
YnkgbWVhbnMgb2YgRmlicmUgQ2hhbm5lbCBpbnRlcmZhY2VzIHNheSBZLgorICAgICAgICAgIEZv
ciBkZXRhaWxzIHBsZWFzZSByZWZlciB0byB0aGUgZG9jdW1lbnRhdGlvbiBwcm92aWRlZCBieSBJ
Qk0gYXQKKyAgICAgICAgICA8aHR0cDovL29zcy5zb2Z0d2FyZS5pYm0uY29tL2RldmVsb3Blcndv
cmtzL29wZW5zb3VyY2UvbGludXgzOTA+CisKKyAgICAgICAgICBUaGlzIGRyaXZlciBpcyBhbHNv
IGF2YWlsYWJsZSBhcyBhIG1vZHVsZS4gVGhpcyBtb2R1bGUgd2lsbCBiZQorICAgICAgICAgIGNh
bGxlZCB6ZmNwLiBJZiB5b3Ugd2FudCB0byBjb21waWxlIGl0IGFzIGEgbW9kdWxlLCBzYXkgTSBo
ZXJlCisgICAgICAgICAgYW5kIHJlYWQgPGZpbGU6RG9jdW1lbnRhdGlvbi9rYnVpbGQvbW9kdWxl
cy50eHQ+LgorCitjb25maWcgU0NTSV9QTUNSQUlECisJdHJpc3RhdGUgIlBNQyBTSUVSUkEgTGlu
dXggTWF4UkFJRCBhZGFwdGVyIHN1cHBvcnQiCisJZGVwZW5kcyBvbiBQQ0kgJiYgU0NTSSAmJiBO
RVQKKwktLS1oZWxwLS0tCisJICBUaGlzIGRyaXZlciBzdXBwb3J0cyB0aGUgUE1DIFNJRVJSQSBN
YXhSQUlEIGFkYXB0ZXJzLgorCitjb25maWcgU0NTSV9QTTgwMDEKKwl0cmlzdGF0ZSAiUE1DLVNp
ZXJyYSBTUEMgODAwMSBTQVMvU0FUQSBCYXNlZCBIb3N0IEFkYXB0ZXIgZHJpdmVyIgorCWRlcGVu
ZHMgb24gUENJICYmIFNDU0kKKwlzZWxlY3QgU0NTSV9TQVNfTElCU0FTCisJaGVscAorCSAgVGhp
cyBkcml2ZXIgc3VwcG9ydHMgUE1DLVNpZXJyYSBQQ0lFIFNBUy9TQVRBIDh4NkcgU1BDIDgwMDEg
Y2hpcAorCSAgYmFzZWQgaG9zdCBhZGFwdGVycy4KKworY29uZmlnIFNDU0lfU1JQCisJdHJpc3Rh
dGUgIlNDU0kgUkRNQSBQcm90b2NvbCBoZWxwZXIgbGlicmFyeSIKKwlkZXBlbmRzIG9uIFNDU0kg
JiYgUENJCisJc2VsZWN0IFNDU0lfVEdUCisJaGVscAorCSAgSWYgeW91IHdpc2ggdG8gdXNlIFNS
UCB0YXJnZXQgZHJpdmVycywgc2F5IFkuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgYXMg
YSBtb2R1bGUsIGNob29zZSBNIGhlcmU6IHRoZQorCSAgbW9kdWxlIHdpbGwgYmUgY2FsbGVkIGxp
YnNycC4KKworY29uZmlnIFNDU0lfQkZBX0ZDCisJdHJpc3RhdGUgIkJyb2NhZGUgQkZBIEZpYnJl
IENoYW5uZWwgU3VwcG9ydCIKKwlkZXBlbmRzIG9uIFBDSSAmJiBTQ1NJCisJc2VsZWN0IFNDU0lf
RkNfQVRUUlMKKwloZWxwCisJICBUaGlzIGJmYSBkcml2ZXIgc3VwcG9ydHMgYWxsIEJyb2NhZGUg
UENJZSBGQy9GQ09FIGhvc3QgYWRhcHRlcnMuCisKKwkgIFRvIGNvbXBpbGUgdGhpcyBkcml2ZXIg
YXMgYSBtb2R1bGUsIGNob29zZSBNIGhlcmUuIFRoZSBtb2R1bGUgd2lsbAorCSAgYmUgY2FsbGVk
IGJmYS4KKworZW5kaWYgIyBTQ1NJX0xPV0xFVkVMCisKK3NvdXJjZSAiZHJpdmVycy9zY3NpL3Bj
bWNpYS9LY29uZmlnIgorCitzb3VyY2UgImRyaXZlcnMvc2NzaS9kZXZpY2VfaGFuZGxlci9LY29u
ZmlnIgorCitzb3VyY2UgImRyaXZlcnMvc2NzaS9vc2QvS2NvbmZpZyIKKworZW5kbWVudQpkaWZm
IC1ydXBOIHhlbi9kcml2ZXJzL3Njc2kvTWFrZWZpbGUgeGVuYy9kcml2ZXJzL3Njc2kvTWFrZWZp
bGUKLS0tIHhlbi9kcml2ZXJzL3Njc2kvTWFrZWZpbGUJMjAxMi0wMi0yNCAxNToxMjozOS43MjU2
NDQ5NjYgLTA3MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL01ha2VmaWxlCTIwMTItMDItMjQgMTU6
MTk6MzUuMzE1NjQ0OTMzIC0wNzAwCkBAIC0xNDEsNiArMTQxLDggQEAgb2JqLSQoQ09ORklHX1ND
U0lfQ1hHQjRfSVNDU0kpCSs9IGxpYmlzYwogb2JqLSQoQ09ORklHX1NDU0lfQk5YMl9JU0NTSSkJ
Kz0gbGliaXNjc2kubyBibngyaS8KIG9iai0kKENPTkZJR19CRTJJU0NTSSkJCSs9IGxpYmlzY3Np
Lm8gYmUyaXNjc2kvCiBvYmotJChDT05GSUdfU0NTSV9QTUNSQUlEKQkrPSBwbWNyYWlkLm8KK29i
ai0kKENPTkZJR19YRU5fU0NTSV9GUk9OVEVORCkJKz0geGVuLXNjc2lmcm9udC8KK29iai0kKENP
TkZJR19YRU5fU0NTSV9CQUNLRU5EKQkrPSB4ZW4tc2NzaWJhY2svCiBvYmotJChDT05GSUdfVk1X
QVJFX1BWU0NTSSkJKz0gdm13X3B2c2NzaS5vCiAKIG9iai0kKENPTkZJR19BUk0pCQkrPSBhcm0v
CmRpZmYgLXJ1cE4geGVuL2RyaXZlcnMvc2NzaS9NYWtlZmlsZS5vcmlnIHhlbmMvZHJpdmVycy9z
Y3NpL01ha2VmaWxlLm9yaWcKLS0tIHhlbi9kcml2ZXJzL3Njc2kvTWFrZWZpbGUub3JpZwkxOTY5
LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVuYy9kcml2ZXJzL3Njc2kvTWFr
ZWZpbGUub3JpZwkyMDEyLTAyLTI0IDE1OjEyOjM5LjcyNTY0NDk2NiAtMDcwMApAQCAtMCwwICsx
LDIwMCBAQAorIworIyBNYWtlZmlsZSBmb3IgbGludXgvZHJpdmVycy9zY3NpCisjCisjIDMwIE1h
eSAyMDAwLCBDaHJpc3RvcGggSGVsbHdpZyA8aGNoQGluZnJhZGVhZC5vcmc+CisjIFJld3JpdHRl
biB0byB1c2UgbGlzdHMgaW5zdGVhZCBvZiBpZi1zdGF0ZW1lbnRzLgorIworIyAyMCBTZXAgMjAw
MCwgVG9yYmVuIE1hdGhpYXNlbiA8dG1tQGltYWdlLmRrPgorIyBDaGFuZ2VkIGxpbmsgb3JkZXIg
dG8gcmVmbGVjdCBuZXcgc2NzaSBpbml0aWFsaXphdGlvbi4KKyMKKyMgKiEqISohKiEqISohKiEq
ISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqIQorIyBUaGUg
bGluayBvcmRlciBtdXN0IGJlLCBTQ1NJIENvcmUsIFNDU0kgSEJBIGRyaXZlcnMsIGFuZAorIyBs
YXN0bHkgU0NTSSBwZXJpcGhlcmFsIGRyaXZlcnMgKGRpc2svdGFwZS9jZHJvbS9ldGMuKSB0bwor
IyBzYXRpc2Z5IGNlcnRhaW4gaW5pdGlhbGl6YXRpb24gYXNzdW1wdGlvbnMgaW4gdGhlIFNDU0kg
bGF5ZXIuCisjICohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEqISohKiEq
ISohKiEqISohKiEqISohKiEKKworCitDRkxBR1NfYWhhMTUyeC5vID0gICAtREFIQTE1MlhfU1RB
VCAtREFVVE9DT05GCitDRkxBR1NfZ2R0aC5vICAgID0gIyAtRERFQlVHX0dEVEg9MiAtRF9fU0VS
SUFMX18gLURfX0NPTTJfXyAtREdEVEhfU1RBVElTVElDUworCitvYmotJChDT05GSUdfUENNQ0lB
KQkJKz0gcGNtY2lhLworCitvYmotJChDT05GSUdfU0NTSSkJCSs9IHNjc2lfbW9kLm8KK29iai0k
KENPTkZJR19TQ1NJX1RHVCkJCSs9IHNjc2lfdGd0Lm8KKworb2JqLSQoQ09ORklHX1JBSURfQVRU
UlMpCSs9IHJhaWRfY2xhc3MubworCisjIC0tLSBOT1RFIE9SREVSSU5HIEhFUkUgLS0tCisjIEZv
ciBrZXJuZWwgbm9uLW1vZHVsYXIgbGluaywgdHJhbnNwb3J0IGF0dHJpYnV0ZXMgbmVlZCB0bwor
IyBiZSBpbml0aWFsaXNlZCBiZWZvcmUgZHJpdmVycworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQorb2JqLSQoQ09ORklHX1NDU0lfU1BJX0FUVFJTKQkrPSBzY3NpX3RyYW5zcG9ydF9zcGku
bworb2JqLSQoQ09ORklHX1NDU0lfRkNfQVRUUlMpIAkrPSBzY3NpX3RyYW5zcG9ydF9mYy5vCitv
YmotJChDT05GSUdfU0NTSV9JU0NTSV9BVFRSUykJKz0gc2NzaV90cmFuc3BvcnRfaXNjc2kubwor
b2JqLSQoQ09ORklHX1NDU0lfU0FTX0FUVFJTKQkrPSBzY3NpX3RyYW5zcG9ydF9zYXMubworb2Jq
LSQoQ09ORklHX1NDU0lfU0FTX0xJQlNBUykJKz0gbGlic2FzLworb2JqLSQoQ09ORklHX1NDU0lf
U1JQX0FUVFJTKQkrPSBzY3NpX3RyYW5zcG9ydF9zcnAubworb2JqLSQoQ09ORklHX1NDU0lfREgp
CQkrPSBkZXZpY2VfaGFuZGxlci8KKworb2JqLSQoQ09ORklHX0xJQkZDKQkJKz0gbGliZmMvCitv
YmotJChDT05GSUdfTElCRkNPRSkJCSs9IGZjb2UvCitvYmotJChDT05GSUdfRkNPRSkJCSs9IGZj
b2UvCitvYmotJChDT05GSUdfRkNPRV9GTklDKQkJKz0gZm5pYy8KK29iai0kKENPTkZJR19TQ1NJ
X0JOWDJYX0ZDT0UpCSs9IGxpYmZjLyBmY29lLyBibngyZmMvCitvYmotJChDT05GSUdfSVNDU0lf
VENQKSAJKz0gbGliaXNjc2kubwlsaWJpc2NzaV90Y3AubyBpc2NzaV90Y3Aubworb2JqLSQoQ09O
RklHX0lORklOSUJBTkRfSVNFUikgCSs9IGxpYmlzY3NpLm8KK29iai0kKENPTkZJR19JU0NTSV9C
T09UX1NZU0ZTKQkrPSBpc2NzaV9ib290X3N5c2ZzLm8KK29iai0kKENPTkZJR19TQ1NJX0E0MDAw
VCkJKz0gNTNjNzAwLm8JYTQwMDB0Lm8KK29iai0kKENPTkZJR19TQ1NJX1pPUlJPN1hYKQkrPSA1
M2M3MDAubwl6b3Jybzd4eC5vCitvYmotJChDT05GSUdfQTMwMDBfU0NTSSkJKz0gYTMwMDAubwl3
ZDMzYzkzLm8KK29iai0kKENPTkZJR19BMjA5MV9TQ1NJKQkrPSBhMjA5MS5vCXdkMzNjOTMubwor
b2JqLSQoQ09ORklHX0dWUDExX1NDU0kpCSs9IGd2cDExLm8Jd2QzM2M5My5vCitvYmotJChDT05G
SUdfTVZNRTE0N19TQ1NJKQkrPSBtdm1lMTQ3Lm8Jd2QzM2M5My5vCitvYmotJChDT05GSUdfU0dJ
V0Q5M19TQ1NJKQkrPSBzZ2l3ZDkzLm8Jd2QzM2M5My5vCitvYmotJChDT05GSUdfQVRBUklfU0NT
SSkJKz0gYXRhcmlfc2NzaS5vCitvYmotJChDT05GSUdfTUFDX1NDU0kpCQkrPSBtYWNfc2NzaS5v
CitvYmotJChDT05GSUdfU0NTSV9NQUNfRVNQKQkrPSBlc3Bfc2NzaS5vCW1hY19lc3Aubworb2Jq
LSQoQ09ORklHX1NVTjNfU0NTSSkJCSs9IHN1bjNfc2NzaS5vICBzdW4zX3Njc2lfdm1lLm8KK29i
ai0kKENPTkZJR19NVk1FMTZ4X1NDU0kpCSs9IDUzYzcwMC5vCW12bWUxNnhfc2NzaS5vCitvYmot
JChDT05GSUdfQlZNRTYwMDBfU0NTSSkJKz0gNTNjNzAwLm8JYnZtZTYwMDBfc2NzaS5vCitvYmot
JChDT05GSUdfU0NTSV9TSU03MTApCSs9IDUzYzcwMC5vCXNpbTcxMC5vCitvYmotJChDT05GSUdf
U0NTSV9BRFZBTlNZUykJKz0gYWR2YW5zeXMubworb2JqLSQoQ09ORklHX1NDU0lfQlVTTE9HSUMp
CSs9IEJ1c0xvZ2ljLm8KK29iai0kKENPTkZJR19TQ1NJX0RQVF9JMk8pCSs9IGRwdF9pMm8ubwor
b2JqLSQoQ09ORklHX1NDU0lfVTE0XzM0RikJKz0gdTE0LTM0Zi5vCitvYmotJChDT05GSUdfU0NT
SV9BUkNNU1IpCSs9IGFyY21zci8KK29iai0kKENPTkZJR19TQ1NJX1VMVFJBU1RPUikJKz0gdWx0
cmFzdG9yLm8KK29iai0kKENPTkZJR19TQ1NJX0FIQTE1MlgpCSs9IGFoYTE1Mngubworb2JqLSQo
Q09ORklHX1NDU0lfQUhBMTU0MikJKz0gYWhhMTU0Mi5vCitvYmotJChDT05GSUdfU0NTSV9BSEEx
NzQwKQkrPSBhaGExNzQwLm8KK29iai0kKENPTkZJR19TQ1NJX0FJQzdYWFgpCSs9IGFpYzd4eHgv
CitvYmotJChDT05GSUdfU0NTSV9BSUM3OVhYKQkrPSBhaWM3eHh4Lworb2JqLSQoQ09ORklHX1ND
U0lfQUFDUkFJRCkJKz0gYWFjcmFpZC8KK29iai0kKENPTkZJR19TQ1NJX0FJQzdYWFhfT0xEKQkr
PSBhaWM3eHh4X29sZC5vCitvYmotJChDT05GSUdfU0NTSV9BSUM5NFhYKQkrPSBhaWM5NHh4Lwor
b2JqLSQoQ09ORklHX1NDU0lfUE04MDAxKQkrPSBwbTgwMDEvCitvYmotJChDT05GSUdfU0NTSV9J
U0NJKQkJKz0gaXNjaS8KK29iai0kKENPTkZJR19TQ1NJX0lQUykJCSs9IGlwcy5vCitvYmotJChD
T05GSUdfU0NTSV9GRF9NQ1MpCSs9IGZkX21jcy5vCitvYmotJChDT05GSUdfU0NTSV9GVVRVUkVf
RE9NQUlOKSs9IGZkb21haW4ubworb2JqLSQoQ09ORklHX1NDU0lfSU4yMDAwKQkrPSBpbjIwMDAu
bworb2JqLSQoQ09ORklHX1NDU0lfR0VORVJJQ19OQ1I1MzgwKSArPSBnX05DUjUzODAubworb2Jq
LSQoQ09ORklHX1NDU0lfR0VORVJJQ19OQ1I1MzgwX01NSU8pICs9IGdfTkNSNTM4MF9tbWlvLm8K
K29iai0kKENPTkZJR19TQ1NJX05DUjUzQzQwNkEpCSs9IE5DUjUzYzQwNmEubworb2JqLSQoQ09O
RklHX1NDU0lfTkNSX0Q3MDApCSs9IDUzYzcwMC5vIE5DUl9ENzAwLm8KK29iai0kKENPTkZJR19T
Q1NJX05DUl9RNzIwKQkrPSBOQ1JfUTcyMF9tb2Qubworb2JqLSQoQ09ORklHX1NDU0lfU1lNNTND
NDE2KQkrPSBzeW01M2M0MTYubworb2JqLSQoQ09ORklHX1NDU0lfUUxPR0lDX0ZBUykJKz0gcWxv
Z2ljZmFzNDA4Lm8JcWxvZ2ljZmFzLm8KK29iai0kKENPTkZJR19QQ01DSUFfUUxPR0lDKQkrPSBx
bG9naWNmYXM0MDgubworb2JqLSQoQ09ORklHX1NDU0lfUUxPR0lDXzEyODApCSs9IHFsYTEyODAu
byAKK29iai0kKENPTkZJR19TQ1NJX1FMQV9GQykJKz0gcWxhMnh4eC8KK29iai0kKENPTkZJR19T
Q1NJX1FMQV9JU0NTSSkJKz0gbGliaXNjc2kubyBxbGE0eHh4Lworb2JqLSQoQ09ORklHX1NDU0lf
TFBGQykJCSs9IGxwZmMvCitvYmotJChDT05GSUdfU0NTSV9CRkFfRkMpCSs9IGJmYS8KK29iai0k
KENPTkZJR19TQ1NJX1BBUzE2KQkrPSBwYXMxNi5vCitvYmotJChDT05GSUdfU0NTSV9UMTI4KQkJ
Kz0gdDEyOC5vCitvYmotJChDT05GSUdfU0NTSV9ETVgzMTkxRCkJKz0gZG14MzE5MWQubworb2Jq
LSQoQ09ORklHX1NDU0lfSFBTQSkJCSs9IGhwc2Eubworb2JqLSQoQ09ORklHX1NDU0lfRFRDMzI4
MCkJKz0gZHRjLm8KK29iai0kKENPTkZJR19TQ1NJX1NZTTUzQzhYWF8yKQkrPSBzeW01M2M4eHhf
Mi8KK29iai0kKENPTkZJR19TQ1NJX1pBTE9OKQkrPSB6YWxvbjd4eC5vCitvYmotJChDT05GSUdf
U0NTSV9FQVRBX1BJTykJKz0gZWF0YV9waW8ubworb2JqLSQoQ09ORklHX1NDU0lfNzAwMEZBU1NU
KQkrPSB3ZDcwMDAubworb2JqLSQoQ09ORklHX1NDU0lfSUJNTUNBKQkrPSBpYm1tY2Eubworb2Jq
LSQoQ09ORklHX1NDU0lfRUFUQSkJCSs9IGVhdGEubworb2JqLSQoQ09ORklHX1NDU0lfREMzOTV4
KQkrPSBkYzM5NXgubworb2JqLSQoQ09ORklHX1NDU0lfREMzOTBUKQkrPSB0bXNjc2ltLm8KK29i
ai0kKENPTkZJR19NRUdBUkFJRF9MRUdBQ1kpCSs9IG1lZ2FyYWlkLm8KK29iai0kKENPTkZJR19N
RUdBUkFJRF9ORVdHRU4pCSs9IG1lZ2FyYWlkLworb2JqLSQoQ09ORklHX01FR0FSQUlEX1NBUykJ
Kz0gbWVnYXJhaWQvCitvYmotJChDT05GSUdfU0NTSV9NUFQyU0FTKQkrPSBtcHQyc2FzLworb2Jq
LSQoQ09ORklHX1NDU0lfQUNBUkQpCSs9IGF0cDg3MHUubworb2JqLSQoQ09ORklHX1NDU0lfU1VO
RVNQKQkrPSBlc3Bfc2NzaS5vCXN1bl9lc3Aubworb2JqLSQoQ09ORklHX1NDU0lfR0RUSCkJCSs9
IGdkdGgubworb2JqLSQoQ09ORklHX1NDU0lfSU5JVElPKQkrPSBpbml0aW8ubworb2JqLSQoQ09O
RklHX1NDU0lfSU5JQTEwMCkJKz0gYTEwMHUydy5vCitvYmotJChDT05GSUdfU0NTSV9RTE9HSUNQ
VEkpCSs9IHFsb2dpY3B0aS5vCitvYmotJChDT05GSUdfU0NTSV9NRVNIKQkJKz0gbWVzaC5vCitv
YmotJChDT05GSUdfU0NTSV9NQUM1M0M5NCkJKz0gbWFjNTNjOTQubworb2JqLSQoQ09ORklHX0JM
S19ERVZfM1dfWFhYWF9SQUlEKSArPSAzdy14eHh4Lm8KK29iai0kKENPTkZJR19TQ1NJXzNXXzlY
WFgpCSs9IDN3LTl4eHgubworb2JqLSQoQ09ORklHX1NDU0lfM1dfU0FTKQkrPSAzdy1zYXMubwor
b2JqLSQoQ09ORklHX1NDU0lfUFBBKQkJKz0gcHBhLm8KK29iai0kKENPTkZJR19TQ1NJX0lNTSkJ
CSs9IGltbS5vCitvYmotJChDT05GSUdfSkFaWl9FU1ApCQkrPSBlc3Bfc2NzaS5vCWphenpfZXNw
Lm8KK29iai0kKENPTkZJR19TVU4zWF9FU1ApCQkrPSBlc3Bfc2NzaS5vCXN1bjN4X2VzcC5vCitv
YmotJChDT05GSUdfU0NTSV9MQVNJNzAwKQkrPSA1M2M3MDAubyBsYXNpNzAwLm8KK29iai0kKENP
TkZJR19TQ1NJX1NOSV81M0M3MTApCSs9IDUzYzcwMC5vIHNuaV81M2M3MTAubworb2JqLSQoQ09O
RklHX1NDU0lfTlNQMzIpCSs9IG5zcDMyLm8KK29iai0kKENPTkZJR19TQ1NJX0lQUikJCSs9IGlw
ci5vCitvYmotJChDT05GSUdfU0NTSV9TUlApCQkrPSBsaWJzcnAubworb2JqLSQoQ09ORklHX1ND
U0lfSUJNVlNDU0kpCSs9IGlibXZzY3NpLworb2JqLSQoQ09ORklHX1NDU0lfSUJNVlNDU0lTKQkr
PSBpYm12c2NzaS8KK29iai0kKENPTkZJR19TQ1NJX0lCTVZGQykJKz0gaWJtdnNjc2kvCitvYmot
JChDT05GSUdfU0NTSV9IUFRJT1ApCSs9IGhwdGlvcC5vCitvYmotJChDT05GSUdfU0NTSV9TVEVY
KQkJKz0gc3RleC5vCitvYmotJChDT05GSUdfU0NTSV9NVlNBUykJKz0gbXZzYXMvCitvYmotJChD
T05GSUdfU0NTSV9NVlVNSSkJKz0gbXZ1bWkubworb2JqLSQoQ09ORklHX1BTM19ST00pCQkrPSBw
czNyb20ubworb2JqLSQoQ09ORklHX1NDU0lfQ1hHQjNfSVNDU0kpCSs9IGxpYmlzY3NpLm8gbGli
aXNjc2lfdGNwLm8gY3hnYmkvCitvYmotJChDT05GSUdfU0NTSV9DWEdCNF9JU0NTSSkJKz0gbGli
aXNjc2kubyBsaWJpc2NzaV90Y3AubyBjeGdiaS8KK29iai0kKENPTkZJR19TQ1NJX0JOWDJfSVND
U0kpCSs9IGxpYmlzY3NpLm8gYm54MmkvCitvYmotJChDT05GSUdfQkUySVNDU0kpCQkrPSBsaWJp
c2NzaS5vIGJlMmlzY3NpLworb2JqLSQoQ09ORklHX1NDU0lfUE1DUkFJRCkJKz0gcG1jcmFpZC5v
CitvYmotJChDT05GSUdfVk1XQVJFX1BWU0NTSSkJKz0gdm13X3B2c2NzaS5vCisKK29iai0kKENP
TkZJR19BUk0pCQkrPSBhcm0vCisKK29iai0kKENPTkZJR19DSFJfREVWX1NUKQkrPSBzdC5vCitv
YmotJChDT05GSUdfQ0hSX0RFVl9PU1NUKQkrPSBvc3N0Lm8KK29iai0kKENPTkZJR19CTEtfREVW
X1NEKQkrPSBzZF9tb2Qubworb2JqLSQoQ09ORklHX0JMS19ERVZfU1IpCSs9IHNyX21vZC5vCitv
YmotJChDT05GSUdfQ0hSX0RFVl9TRykJKz0gc2cubworb2JqLSQoQ09ORklHX0NIUl9ERVZfU0NI
KQkrPSBjaC5vCitvYmotJChDT05GSUdfU0NTSV9FTkNMT1NVUkUpCSs9IHNlcy5vCisKK29iai0k
KENPTkZJR19TQ1NJX09TRF9JTklUSUFUT1IpICs9IG9zZC8KKworIyBUaGlzIGdvZXMgbGFzdCwg
c28gdGhhdCAicmVhbCIgc2NzaSBkZXZpY2VzIHByb2JlIGVhcmxpZXIKK29iai0kKENPTkZJR19T
Q1NJX0RFQlVHKQkrPSBzY3NpX2RlYnVnLm8KKworb2JqLSQoQ09ORklHX1NDU0lfV0FJVF9TQ0FO
KQkrPSBzY3NpX3dhaXRfc2Nhbi5vCisKK3Njc2lfbW9kLXkJCQkrPSBzY3NpLm8gaG9zdHMubyBz
Y3NpX2lvY3RsLm8gY29uc3RhbnRzLm8gXAorCQkJCSAgIHNjc2ljYW0ubyBzY3NpX2Vycm9yLm8g
c2NzaV9saWIubworc2NzaV9tb2QtJChDT05GSUdfU0NTSV9ETUEpCSs9IHNjc2lfbGliX2RtYS5v
CitzY3NpX21vZC15CQkJKz0gc2NzaV9zY2FuLm8gc2NzaV9zeXNmcy5vIHNjc2lfZGV2aW5mby5v
CitzY3NpX21vZC0kKENPTkZJR19TQ1NJX05FVExJTkspCSs9IHNjc2lfbmV0bGluay5vCitzY3Np
X21vZC0kKENPTkZJR19TWVNDVEwpCSs9IHNjc2lfc3lzY3RsLm8KK3Njc2lfbW9kLSQoQ09ORklH
X1NDU0lfUFJPQ19GUykJKz0gc2NzaV9wcm9jLm8KK3Njc2lfbW9kLXkJCQkrPSBzY3NpX3RyYWNl
Lm8KK3Njc2lfbW9kLSQoQ09ORklHX1BNKQkJKz0gc2NzaV9wbS5vCisKK3Njc2lfdGd0LXkJCQkr
PSBzY3NpX3RndF9saWIubyBzY3NpX3RndF9pZi5vCisKK3NkX21vZC1vYmpzCTo9IHNkLm8KK3Nk
X21vZC0kKENPTkZJR19CTEtfREVWX0lOVEVHUklUWSkgKz0gc2RfZGlmLm8KKworc3JfbW9kLW9i
anMJOj0gc3IubyBzcl9pb2N0bC5vIHNyX3ZlbmRvci5vCituY3I1M2M4eHgtZmxhZ3MtJChDT05G
SUdfU0NTSV9aQUxPTikgXAorCQk6PSAtRENPTkZJR19OQ1I1M0M4WFhfUFJFRkVUQ0ggLURTQ1NJ
X05DUl9CSUdfRU5ESUFOIFwKKwkJCS1EQ09ORklHX1NDU0lfTkNSNTNDOFhYX05PX1dPUkRfVFJB
TlNGRVJTCitDRkxBR1NfbmNyNTNjOHh4Lm8JOj0gJChuY3I1M2M4eHgtZmxhZ3MteSkgJChuY3I1
M2M4eHgtZmxhZ3MtbSkKK3phbG9uN3h4LW9ianMJOj0gemFsb24ubyBuY3I1M2M4eHgubworTkNS
X1E3MjBfbW9kLW9ianMJOj0gTkNSX1E3MjAubyBuY3I1M2M4eHgubworb2t0YWdvbl9lc3BfbW9k
LW9ianMJOj0gb2t0YWdvbl9lc3AubyBva3RhZ29uX2lvLm8KKworIyBGaWxlcyBnZW5lcmF0ZWQg
dGhhdCBzaGFsbCBiZSByZW1vdmVkIHVwb24gbWFrZSBjbGVhbgorY2xlYW4tZmlsZXMgOj0JNTNj
NzAwX2QuaCA1M2M3MDBfdS5oCisKKyQob2JqKS81M2M3MDAubyAkKE1PRFZFUkRJUikvJChvYmop
LzUzYzcwMC52ZXI6ICQob2JqKS81M2M3MDBfZC5oCisKKyMgSWYgeW91IHdhbnQgdG8gcGxheSB3
aXRoIHRoZSBmaXJtd2FyZSwgdW5jb21tZW50CisjIEdFTkVSQVRFX0ZJUk1XQVJFIDo9IDEKKwor
aWZkZWYgR0VORVJBVEVfRklSTVdBUkUKKworJChvYmopLzUzYzcwMF9kLmg6ICQoc3JjKS81M2M3
MDAuc2NyICQoc3JjKS9zY3JpcHRfYXNtLnBsCisJJChQRVJMKSAtcyAkKHNyYykvc2NyaXB0X2Fz
bS5wbCAtbmNyN3gwX2ZhbWlseSAkQCAkKEA6X2QuaD1fdS5oKSA8ICQ8CisKK2VuZGlmCmRpZmYg
LXJ1cE4geGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWJhY2svTWFrZWZpbGUgeGVuYy9kcml2ZXJz
L3Njc2kveGVuLXNjc2liYWNrL01ha2VmaWxlCi0tLSB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3Np
YmFjay9NYWtlZmlsZQkxOTY5LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVu
Yy9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL01ha2VmaWxlCTIwMTItMDItMjQgMTQ6NTY6MTMu
NTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNCBAQAorb2JqLSQoQ09ORklHX1hFTl9TQ1NJX0JB
Q0tFTkQpIDo9IHhlbi1zY3NpYmFjay5vCisKK3hlbi1zY3NpYmFjay15CTo9IGludGVyZmFjZS5v
IHNjc2liYWNrLm8geGVuYnVzLm8gdHJhbnNsYXRlLm8gZW11bGF0ZS5vCisKZGlmZiAtcnVwTiB4
ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFjay9jb21tb24uaCB4ZW5jL2RyaXZlcnMvc2NzaS94
ZW4tc2NzaWJhY2svY29tbW9uLmgKLS0tIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL2Nv
bW1vbi5oCTE5NjktMTItMzEgMTc6MDA6MDAuMDAwMDAwMDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZl
cnMvc2NzaS94ZW4tc2NzaWJhY2svY29tbW9uLmgJMjAxMi0wMi0yNCAxNDo1NjoxMy41Mzg5Nzgz
MDAgLTA3MDAKQEAgLTAsMCArMSwxODcgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZV
SklUU1UgTGltaXRlZAorICoKKyAqIEJhc2VkIG9uIHRoZSBibGtiYWNrIGRyaXZlciBjb2RlLgor
ICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisgKiBzZXBhcmF0ZWx5
IGZyb20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBvdGhlcgorICogc29m
dHdhcmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNlbnNlOgorICoKKyAq
IFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVy
c29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUgKHRoZSAiU29mdHdh
cmUiKSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVzdHJpY3Rpb24sIGlu
Y2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlm
eSwKKyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3Igc2Vs
bCBjb3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdo
b20gdGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0bworICogdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNl
IGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwg
Y29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBU
SEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkg
S0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBU
TyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBB
UlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBU
SEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xB
SU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04g
T0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0Yg
T1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERF
QUxJTkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2lmbmRlZiBfX1NDU0lJRl9fQkFD
S0VORF9fQ09NTU9OX0hfXworI2RlZmluZSBfX1NDU0lJRl9fQkFDS0VORF9fQ09NTU9OX0hfXwor
CisjaW5jbHVkZSA8bGludXgvdmVyc2lvbi5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgor
I2luY2x1ZGUgPGxpbnV4L2ludGVycnVwdC5oPgorI2luY2x1ZGUgPGxpbnV4L3NsYWIuaD4KKyNp
bmNsdWRlIDxsaW51eC92bWFsbG9jLmg+CisjaW5jbHVkZSA8bGludXgvd2FpdC5oPgorI2luY2x1
ZGUgPGxpbnV4L3NjaGVkLmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2luY2x1ZGUg
PGxpbnV4L2Jsa2Rldi5oPgorI2luY2x1ZGUgPGxpbnV4L2xpc3QuaD4KKyNpbmNsdWRlIDxsaW51
eC9rdGhyZWFkLmg+CisjaW5jbHVkZSA8c2NzaS9zY3NpLmg+CisjaW5jbHVkZSA8c2NzaS9zY3Np
X2NtbmQuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfaG9zdC5oPgorI2luY2x1ZGUgPHNjc2kvc2Nz
aV9kZXZpY2UuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfZGJnLmg+CisjaW5jbHVkZSA8c2NzaS9z
Y3NpX2VoLmg+CisjaW5jbHVkZSA8YXNtL2lvLmg+CisjaW5jbHVkZSA8YXNtL3NldHVwLmg+Cisj
aW5jbHVkZSA8YXNtL3BnYWxsb2MuaD4KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4KKyNpbmNsdWRl
IDx4ZW4vZXZ0Y2huLmg+CisjaW5jbHVkZSA8YXNtL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDx4
ZW4veGVuLmg+CisjaW5jbHVkZSA8eGVuL2V2ZW50cy5oPgorI2luY2x1ZGUgPHhlbi9ncmFudF90
YWJsZS5oPgorI2luY2x1ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4vcGFnZS5oPgor
I2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UveGVuLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9p
by9yaW5nLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9ncmFudF90YWJsZS5oPgorI2luY2x1
ZGUgPHhlbi9pbnRlcmZhY2UvaW8vdnNjc2lpZi5oPgorCisKKyNkZWZpbmUgRFBSSU5USyhfZiwg
X2EuLi4pCQkJXAorCXByX2RlYnVnKCIoZmlsZT0lcywgbGluZT0lZCkgIiBfZiwJXAorCQkgX19G
SUxFX18gLCBfX0xJTkVfXyAsICMjIF9hICkKKworc3RydWN0IGlkc190dXBsZSB7CisJdW5zaWdu
ZWQgaW50IGhzdDsJCS8qIGhvc3QgICAgKi8KKwl1bnNpZ25lZCBpbnQgY2huOwkJLyogY2hhbm5l
bCAqLworCXVuc2lnbmVkIGludCB0Z3Q7CQkvKiB0YXJnZXQgICovCisJdW5zaWduZWQgaW50IGx1
bjsJCS8qIExVTiAgICAgKi8KK307CisKK3N0cnVjdCB2MnBfZW50cnkgeworCXN0cnVjdCBpZHNf
dHVwbGUgdjsJCS8qIHRyYW5zbGF0ZSBmcm9tICovCisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2
OwkvKiB0cmFuc2xhdGUgdG8gICAqLworCXN0cnVjdCBsaXN0X2hlYWQgbDsKK307CisKK3N0cnVj
dCB2c2NzaWJrX2luZm8geworCXN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXY7CisKKwlkb21pZF90
IGRvbWlkOworCXVuc2lnbmVkIGludCBldnRjaG47CisJdW5zaWduZWQgaW50IGlycTsKKworCWlu
dCBmZWF0dXJlOworCisJc3RydWN0IHZzY3NpaWZfYmFja19yaW5nICByaW5nOworCXZvaWQgICpy
aW5nX2FyZWE7CisKKwlzcGlubG9ja190IHJpbmdfbG9jazsKKwlhdG9taWNfdCBucl91bnJlcGxp
ZWRfcmVxczsKKworCXNwaW5sb2NrX3QgdjJwX2xvY2s7CisJc3RydWN0IGxpc3RfaGVhZCB2MnBf
ZW50cnlfbGlzdHM7CisKKwlzdHJ1Y3QgdGFza19zdHJ1Y3QgKmt0aHJlYWQ7CisJd2FpdF9xdWV1
ZV9oZWFkX3Qgd2FpdGluZ190b19mcmVlOworCXdhaXRfcXVldWVfaGVhZF90IHdxOworCXVuc2ln
bmVkIGludCB3YWl0aW5nX3JlcXM7CisJc3RydWN0IHBhZ2UgKiptbWFwX3BhZ2VzOworCit9Owor
Cit0eXBlZGVmIHN0cnVjdCB7CisJdW5zaWduZWQgY2hhciBhY3Q7CisJc3RydWN0IHZzY3NpYmtf
aW5mbyAqaW5mbzsKKwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXY7CisKKwl1aW50MTZfdCBycWlk
OworCisJdWludDE2X3Qgdl9jaG4sIHZfdGd0OworCisJdWludDhfdCBucl9zZWdtZW50czsKKwl1
aW50OF90IGNtbmRbVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFXTsKKwl1aW50OF90IGNtZF9sZW47
CisKKwl1aW50OF90IHNjX2RhdGFfZGlyZWN0aW9uOworCXVpbnQxNl90IHRpbWVvdXRfcGVyX2Nv
bW1hbmQ7CisKKwl1aW50MzJfdCByZXF1ZXN0X2J1ZmZsZW47CisJc3RydWN0IHNjYXR0ZXJsaXN0
ICpzZ2w7CisJZ3JhbnRfcmVmX3QgZ3JlZltWU0NTSUlGX1NHX1RBQkxFU0laRV07CisKKwlpbnQz
Ml90IHJzbHQ7CisJdWludDMyX3QgcmVzaWQ7CisJdWludDhfdCBzZW5zZV9idWZmZXJbVlNDU0lJ
Rl9TRU5TRV9CVUZGRVJTSVpFXTsKKworCXN0cnVjdCBsaXN0X2hlYWQgZnJlZV9saXN0OworfSBw
ZW5kaW5nX3JlcV90OworCisKKworI2RlZmluZSBzY3NpYmFja19nZXQoX2IpIChhdG9taWNfaW5j
KCYoX2IpLT5ucl91bnJlcGxpZWRfcmVxcykpCisjZGVmaW5lIHNjc2liYWNrX3B1dChfYikJCQkJ
XAorCWRvIHsJCQkJCQlcCisJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCYoX2IpLT5ucl91bnJl
cGxpZWRfcmVxcykpCVwKKwkJCXdha2VfdXAoJihfYiktPndhaXRpbmdfdG9fZnJlZSk7XAorCX0g
d2hpbGUgKDApCisKKyNkZWZpbmUgVlNDU0lJRl9USU1FT1VUCQkoOTAwKkhaKQorCisjZGVmaW5l
IFZTQ1NJX1RZUEVfSE9TVAkJMQorCitpcnFyZXR1cm5fdCBzY3NpYmFja19pbnRyKGludCwgdm9p
ZCAqKTsKK2ludCBzY3NpYmFja19pbml0X3NyaW5nKHN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm8s
CisJCXVuc2lnbmVkIGxvbmcgcmluZ19yZWYsIHVuc2lnbmVkIGludCBldnRjaG4pOworaW50IHNj
c2liYWNrX3NjaGVkdWxlKHZvaWQgKmRhdGEpOworCisKK3N0cnVjdCB2c2NzaWJrX2luZm8gKnZz
Y3NpYmtfaW5mb19hbGxvYyhkb21pZF90IGRvbWlkKTsKK3ZvaWQgc2NzaWJhY2tfZnJlZShzdHJ1
Y3QgdnNjc2lia19pbmZvICppbmZvKTsKK3ZvaWQgc2NzaWJhY2tfZGlzY29ubmVjdChzdHJ1Y3Qg
dnNjc2lia19pbmZvICppbmZvKTsKK2ludCBfX2luaXQgc2NzaWJhY2tfaW50ZXJmYWNlX2luaXQo
dm9pZCk7Cit2b2lkIHNjc2liYWNrX2ludGVyZmFjZV9leGl0KHZvaWQpOworaW50IHNjc2liYWNr
X3hlbmJ1c19pbml0KHZvaWQpOwordm9pZCBzY3NpYmFja194ZW5idXNfdW5yZWdpc3Rlcih2b2lk
KTsKKwordm9pZCBzY3NpYmFja19pbml0X3RyYW5zbGF0aW9uX3RhYmxlKHN0cnVjdCB2c2NzaWJr
X2luZm8gKmluZm8pOworCitpbnQgc2NzaWJhY2tfYWRkX3RyYW5zbGF0aW9uX2VudHJ5KHN0cnVj
dCB2c2NzaWJrX2luZm8gKmluZm8sCisJCQlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXYsIHN0cnVj
dCBpZHNfdHVwbGUgKnYpOworCitpbnQgc2NzaWJhY2tfZGVsX3RyYW5zbGF0aW9uX2VudHJ5KHN0
cnVjdCB2c2NzaWJrX2luZm8gKmluZm8sCisJCQkJc3RydWN0IGlkc190dXBsZSAqdik7CitzdHJ1
Y3Qgc2NzaV9kZXZpY2UgKnNjc2liYWNrX2RvX3RyYW5zbGF0aW9uKHN0cnVjdCB2c2NzaWJrX2lu
Zm8gKmluZm8sCisJCQlzdHJ1Y3QgaWRzX3R1cGxlICp2KTsKK3ZvaWQgc2NzaWJhY2tfcmVsZWFz
ZV90cmFuc2xhdGlvbl9lbnRyeShzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvKTsKKworCit2b2lk
IHNjc2liYWNrX2NtZF9leGVjKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdfcmVxKTsKK3ZvaWQgc2Nz
aWJhY2tfZG9fcmVzcF93aXRoX3NlbnNlKGNoYXIgKnNlbnNlX2J1ZmZlciwgaW50MzJfdCByZXN1
bHQsCisJCQl1aW50MzJfdCByZXNpZCwgcGVuZGluZ19yZXFfdCAqcGVuZGluZ19yZXEpOwordm9p
ZCBzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVuZGluZ19yZXFfdCAqcmVxKTsKKwordm9pZCBz
Y3NpYmFja19yc3BfZW11bGF0aW9uKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdfcmVxKTsKK3ZvaWQg
c2NzaWJhY2tfcmVxX2VtdWxhdGlvbl9vcl9jbWRleGVjKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdf
cmVxKTsKK3ZvaWQgc2NzaWJhY2tfZW11bGF0aW9uX2luaXQodm9pZCk7CisKKworI2VuZGlmIC8q
IF9fU0NTSUlGX19CQUNLRU5EX19DT01NT05fSF9fICovCmRpZmYgLXJ1cE4geGVuL2RyaXZlcnMv
c2NzaS94ZW4tc2NzaWJhY2svZW11bGF0ZS5jIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFj
ay9lbXVsYXRlLmMKLS0tIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL2VtdWxhdGUuYwkx
OTY5LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVuYy9kcml2ZXJzL3Njc2kv
eGVuLXNjc2liYWNrL2VtdWxhdGUuYwkyMDEyLTAyLTI0IDE0OjU2OjEzLjUzODk3ODMwMCAtMDcw
MApAQCAtMCwwICsxLDQ3OCBAQAorLyoKKyAqIFhlbiBTQ1NJIGJhY2tlbmQgZHJpdmVyCisgKgor
ICogQ29weXJpZ2h0IChjKSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQKKyAqCisgKiBUaGlzIHByb2dy
YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBt
b2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z
ZSB2ZXJzaW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0
aW9uOyBvciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBr
ZXJuZWwgb3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBz
dWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhl
cmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBj
b3B5CisgKiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4g
dGhlIFNvZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBs
aW1pdGF0aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVi
bGlzaCwgZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBT
b2Z0d2FyZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBp
cyBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0
aW9uczoKKyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNz
aW9uIG5vdGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFu
dGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBS
T1ZJREVEICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IK
KyAqIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMg
T0YgTUVSQ0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0Ug
QU5EIE5PTklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9S
IENPUFlSSUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9U
SEVSCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JU
IE9SIE9USEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04g
V0lUSCBUSEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhF
IFNPRlRXQVJFLgorICovCisKKy8qCisqIFBhdGNoZWQgdG8gc3VwcG9ydCA+MlRCIGRyaXZlcyAr
IGFsbG93IHRhcGUgJiBhdXRvbG9hZGVyIG9wZXJhdGlvbnMKKyogMjAxMCwgU2FtdWVsIEt2YXNu
aWNhLCBJTVMgTmFub2ZhYnJpY2F0aW9uIEFHCisqLworCisjaW5jbHVkZSA8c2NzaS9zY3NpLmg+
CisjaW5jbHVkZSA8c2NzaS9zY3NpX2NtbmQuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfZGV2aWNl
Lmg+CisjaW5jbHVkZSAiY29tbW9uLmgiCisKKy8qIEZvbGxvd2luZyBTQ1NJIGNvbW1hbmRzIGFy
ZSBub3QgZGVmaW5lZCBpbiBzY3NpL3Njc2kuaCAqLworI2RlZmluZSBFWFRFTkRFRF9DT1BZCQkw
eDgzCS8qIEVYVEVOREVEIENPUFkgY29tbWFuZCAgICAgICAgKi8KKyNkZWZpbmUgUkVQT1JUX0FM
SUFTRVMJCTB4YTMJLyogUkVQT1JUIEFMSUFTRVMgY29tbWFuZCAgICAgICAqLworI2RlZmluZSBD
SEFOR0VfQUxJQVNFUwkJMHhhNAkvKiBDSEFOR0UgQUxJQVNFUyBjb21tYW5kICAgICAgICovCisj
ZGVmaW5lIFNFVF9QUklPUklUWQkJMHhhNAkvKiBTRVQgUFJJT1JJVFkgY29tbWFuZCAgICAgICAg
ICovCisKKworLyoKKyAgVGhlIGJpdG1hcCBpbiBvcmRlciB0byBjb250cm9sIGVtdWxhdGlvbi4K
KyAgKEJpdCAzIHRvIDcgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLikKKyovCisjZGVmaW5l
IFZTQ1NJSUZfTkVFRF9DTURfRVhFQwkJMHgwMQkvKiBJZiB0aGlzIGJpdCBpcyBzZXQsIGNtZCBl
eGVjCSovCisJCQkJCQkvKiBpcyByZXF1aXJlZC4JCQkqLworI2RlZmluZSBWU0NTSUlGX05FRURf
RU1VTEFURV9SRVFCVUYJMHgwMgkvKiBJZiB0aGlzIGJpdCBpcyBzZXQsIG5lZWQJKi8KKwkJCQkJ
CS8qIGVtdWxhdGlvbiByZXFlc3QgYnVmZiBiZWZvcmUJKi8KKwkJCQkJCS8qIGNtZCBleGVjLgkJ
CSovCisjZGVmaW5lIFZTQ1NJSUZfTkVFRF9FTVVMQVRFX1JTUEJVRgkweDA0CS8qIElmIHRoaXMg
Yml0IGlzIHNldCwgbmVlZAkqLworCQkJCQkJLyogZW11bGF0aW9uIHJlc3AgYnVmZiBhZnRlcgkq
LworCQkJCQkJLyogY21kIGV4ZWMuCQkJKi8KKworLyogQWRkaXRpb25hbCBTZW5zZSBDb2RlIChB
U0MpIHVzZWQgKi8KKyNkZWZpbmUgTk9fQURESVRJT05BTF9TRU5TRQkJMHgwCisjZGVmaW5lIExP
R0lDQUxfVU5JVF9OT1RfUkVBRFkJCTB4NAorI2RlZmluZSBVTlJFQ09WRVJFRF9SRUFEX0VSUgkJ
MHgxMQorI2RlZmluZSBQQVJBTUVURVJfTElTVF9MRU5HVEhfRVJSCTB4MWEKKyNkZWZpbmUgSU5W
QUxJRF9PUENPREUJCQkweDIwCisjZGVmaW5lIEFERFJfT1VUX09GX1JBTkdFCQkweDIxCisjZGVm
aW5lIElOVkFMSURfRklFTERfSU5fQ0RCCQkweDI0CisjZGVmaW5lIElOVkFMSURfRklFTERfSU5f
UEFSQU1fTElTVAkweDI2CisjZGVmaW5lIFBPV0VST05fUkVTRVQJCQkweDI5CisjZGVmaW5lIFNB
VklOR19QQVJBTVNfVU5TVVAJCTB4MzkKKyNkZWZpbmUgVEhSRVNIT0xEX0VYQ0VFREVECQkweDVk
CisjZGVmaW5lIExPV19QT1dFUl9DT05EX09OCQkweDVlCisKKworCisvKiBOdW1iZXIgb3MgU0NT
SSBvcF9jb2RlCSovCisjZGVmaW5lIFZTQ1NJX01BWF9TQ1NJX09QX0NPREUJCTI1Ngorc3RhdGlj
IHVuc2lnbmVkIGNoYXIgYml0bWFwW1ZTQ1NJX01BWF9TQ1NJX09QX0NPREVdOworCisjZGVmaW5l
IE5PX0VNVUxBVEUoY21kKSBcCisJYml0bWFwW2NtZF0gPSBWU0NTSUlGX05FRURfQ01EX0VYRUM7
IFwKKwlwcmVfZnVuY3Rpb25bY21kXSA9IE5VTEw7IFwKKwlwb3N0X2Z1bmN0aW9uW2NtZF0gPSBO
VUxMCisKKworCisvKgorICBFbXVsYXRpb24gcm91dGluZXMgZm9yIGVhY2ggU0NTSSBvcF9jb2Rl
LgorKi8KK3N0YXRpYyB2b2lkICgqcHJlX2Z1bmN0aW9uW1ZTQ1NJX01BWF9TQ1NJX09QX0NPREVd
KShwZW5kaW5nX3JlcV90ICosIHZvaWQgKik7CitzdGF0aWMgdm9pZCAoKnBvc3RfZnVuY3Rpb25b
VlNDU0lfTUFYX1NDU0lfT1BfQ09ERV0pKHBlbmRpbmdfcmVxX3QgKiwgdm9pZCAqKTsKKworCitz
dGF0aWMgY29uc3QgaW50IGNoZWNrX2NvbmRpdGlvbl9yZXN1bHQgPQorCQkoRFJJVkVSX1NFTlNF
IDw8IDI0KSB8IFNBTV9TVEFUX0NIRUNLX0NPTkRJVElPTjsKKworc3RhdGljIHZvaWQgc2NzaWJh
Y2tfbWtfc2Vuc2VfYnVmZmVyKHVpbnQ4X3QgKmRhdGEsIHVpbnQ4X3Qga2V5LAorCQkJdWludDhf
dCBhc2MsIHVpbnQ4X3QgYXNxKQoreworCWRhdGFbMF0gPSAweDcwOyAgLyogZml4ZWQsIGN1cnJl
bnQgKi8KKwlkYXRhWzJdID0ga2V5OworCWRhdGFbN10gPSAweGE7CSAgLyogaW1wbGllcyAxOCBi
eXRlIHNlbnNlIGJ1ZmZlciAqLworCWRhdGFbMTJdID0gYXNjOworCWRhdGFbMTNdID0gYXNxOwor
fQorCitzdGF0aWMgdm9pZCByZXNwX25vdF9zdXBwb3J0ZWRfY21kKHBlbmRpbmdfcmVxX3QgKnBl
bmRpbmdfcmVxLCB2b2lkICpkYXRhKQoreworCXNjc2liYWNrX21rX3NlbnNlX2J1ZmZlcihwZW5k
aW5nX3JlcS0+c2Vuc2VfYnVmZmVyLCBJTExFR0FMX1JFUVVFU1QsCisJCUlOVkFMSURfT1BDT0RF
LCAwKTsKKwlwZW5kaW5nX3JlcS0+cmVzaWQgPSAwOworCXBlbmRpbmdfcmVxLT5yc2x0ICA9IGNo
ZWNrX2NvbmRpdGlvbl9yZXN1bHQ7Cit9CisKKworc3RhdGljIGludCBfX2NvcHlfdG9fc2coc3Ry
dWN0IHNjYXR0ZXJsaXN0ICpzZ2wsIHVuc2lnbmVkIGludCBucl9zZywKKwkgICAgICAgdm9pZCAq
YnVmLCB1bnNpZ25lZCBpbnQgYnVmbGVuKQoreworCXN0cnVjdCBzY2F0dGVybGlzdCAqc2c7CisJ
dm9pZCAqZnJvbSA9IGJ1ZjsKKwl2b2lkICp0bzsKKwl1bnNpZ25lZCBpbnQgZnJvbV9yZXN0ID0g
YnVmbGVuOworCXVuc2lnbmVkIGludCB0b19jYXBhOworCXVuc2lnbmVkIGludCBjb3B5X3NpemUg
PSAwOworCXVuc2lnbmVkIGludCBpOworCXVuc2lnbmVkIGxvbmcgcGZuOworCisJZm9yX2VhY2hf
c2cgKHNnbCwgc2csIG5yX3NnLCBpKSB7CisJCWlmIChzZ19wYWdlKHNnKSA9PSBOVUxMKSB7CisJ
CQlwcmludGsoS0VSTl9XQVJOSU5HICIlczogaW5jb25zaXN0ZW50IGxlbmd0aCBmaWVsZCBpbiAi
CisJCQkgICAgICAgInNjYXR0ZXJsaXN0XG4iLCBfX0ZVTkNUSU9OX18pOworCQkJcmV0dXJuIC1F
Tk9NRU07CisJCX0KKworCQl0b19jYXBhICA9IHNnLT5sZW5ndGg7CisJCWNvcHlfc2l6ZSA9IG1p
bl90KHVuc2lnbmVkIGludCwgdG9fY2FwYSwgZnJvbV9yZXN0KTsKKworCQlwZm4gPSBwYWdlX3Rv
X3BmbihzZ19wYWdlKHNnKSk7CisJCXRvID0gcGZuX3RvX2thZGRyKHBmbikgKyAoc2ctPm9mZnNl
dCk7CisJCW1lbWNweSh0bywgZnJvbSwgY29weV9zaXplKTsKKworCQlmcm9tX3Jlc3QgIC09IGNv
cHlfc2l6ZTsKKwkJaWYgKGZyb21fcmVzdCA9PSAwKSB7CisJCQlyZXR1cm4gMDsKKwkJfQorCisJ
CWZyb20gKz0gY29weV9zaXplOworCX0KKworCXByaW50ayhLRVJOX1dBUk5JTkcgIiVzOiBubyBz
cGFjZSBpbiBzY2F0dGVybGlzdFxuIiwKKwkgICAgICAgX19GVU5DVElPTl9fKTsKKwlyZXR1cm4g
LUVOT01FTTsKK30KKyNpZiAwCitzdGF0aWMgaW50IF9fY29weV9mcm9tX3NnKHN0cnVjdCBzY2F0
dGVybGlzdCAqc2dsLCB1bnNpZ25lZCBpbnQgbnJfc2csCisJCSB2b2lkICpidWYsIHVuc2lnbmVk
IGludCBidWZsZW4pCit7CisJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsKKwl2b2lkICpmcm9tOwor
CXZvaWQgKnRvID0gYnVmOworCXVuc2lnbmVkIGludCBmcm9tX3Jlc3Q7CisJdW5zaWduZWQgaW50
IHRvX2NhcGEgPSBidWZsZW47CisJdW5zaWduZWQgaW50IGNvcHlfc2l6ZTsKKwl1bnNpZ25lZCBp
bnQgaTsKKwl1bnNpZ25lZCBsb25nIHBmbjsKKworCWZvcl9lYWNoX3NnIChzZ2wsIHNnLCBucl9z
ZywgaSkgeworCQlpZiAoc2dfcGFnZShzZykgPT0gTlVMTCkgeworCQkJcHJpbnRrKEtFUk5fV0FS
TklORyAiJXM6IGluY29uc2lzdGVudCBsZW5ndGggZmllbGQgaW4gIgorCQkJICAgICAgICJzY2F0
dGVybGlzdFxuIiwgX19GVU5DVElPTl9fKTsKKwkJCXJldHVybiAtRU5PTUVNOworCQl9CisKKwkJ
ZnJvbV9yZXN0ID0gc2ctPmxlbmd0aDsKKwkJaWYgKChmcm9tX3Jlc3QgPiAwKSAmJiAodG9fY2Fw
YSA8IGZyb21fcmVzdCkpIHsKKwkJCXByaW50ayhLRVJOX1dBUk5JTkcKKwkJCSAgICAgICAiJXM6
IG5vIHNwYWNlIGluIGRlc3RpbmF0aW9uIGJ1ZmZlclxuIiwKKwkJCSAgICAgICBfX0ZVTkNUSU9O
X18pOworCQkJcmV0dXJuIC1FTk9NRU07CisJCX0KKwkJY29weV9zaXplID0gZnJvbV9yZXN0Owor
CisJCXBmbiA9IHBhZ2VfdG9fcGZuKHNnX3BhZ2Uoc2cpKTsKKwkJZnJvbSA9IHBmbl90b19rYWRk
cihwZm4pICsgKHNnLT5vZmZzZXQpOworCQltZW1jcHkodG8sIGZyb20sIGNvcHlfc2l6ZSk7CisK
KwkJdG9fY2FwYSAgLT0gY29weV9zaXplOworCQl0byArPSBjb3B5X3NpemU7CisJfQorCisJcmV0
dXJuIDA7Cit9CisjZW5kaWYKK3N0YXRpYyBpbnQgX19ucl9sdW5zX3VuZGVyX2hvc3Qoc3RydWN0
IHZzY3NpYmtfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgdjJwX2VudHJ5ICplbnRyeTsKKwlzdHJ1
Y3QgbGlzdF9oZWFkICpoZWFkID0gJihpbmZvLT52MnBfZW50cnlfbGlzdHMpOworCXVuc2lnbmVk
IGxvbmcgZmxhZ3M7CisJaW50IGx1bl9jbnQgPSAwOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmlu
Zm8tPnYycF9sb2NrLCBmbGFncyk7CisJbGlzdF9mb3JfZWFjaF9lbnRyeShlbnRyeSwgaGVhZCwg
bCkgeworCQkJbHVuX2NudCsrOworCX0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpbmZvLT52
MnBfbG9jaywgZmxhZ3MpOworCisJcmV0dXJuIChsdW5fY250KTsKK30KKworCisvKiBSRVBPUlQg
TFVOUyBEZWZpbmUqLworI2RlZmluZSBWU0NTSV9SRVBPUlRfTFVOU19IRUFERVIJOAorI2RlZmlu
ZSBWU0NTSV9SRVBPUlRfTFVOU19SRVRSWQkJMworCisvKiBxdW90ZWQgc2NzaV9kZWJ1Zy5jL3Jl
c3BfcmVwb3J0X2x1bnMoKSAqLworc3RhdGljIHZvaWQgX19yZXBvcnRfbHVucyhwZW5kaW5nX3Jl
cV90ICpwZW5kaW5nX3JlcSwgdm9pZCAqZGF0YSkKK3sKKwlzdHJ1Y3QgdnNjc2lia19pbmZvICpp
bmZvICAgPSBwZW5kaW5nX3JlcS0+aW5mbzsKKwl1bnNpZ25lZCBpbnQgICAgICAgIGNoYW5uZWwg
PSBwZW5kaW5nX3JlcS0+dl9jaG47CisJdW5zaWduZWQgaW50ICAgICAgICB0YXJnZXQgID0gcGVu
ZGluZ19yZXEtPnZfdGd0OworCXVuc2lnbmVkIGludCAgICAgICAgbnJfc2VnICA9IHBlbmRpbmdf
cmVxLT5ucl9zZWdtZW50czsKKwl1bnNpZ25lZCBjaGFyICpjbWQgPSAodW5zaWduZWQgY2hhciAq
KXBlbmRpbmdfcmVxLT5jbW5kOworCisJdW5zaWduZWQgY2hhciAqYnVmZiA9IE5VTEw7CisJdW5z
aWduZWQgY2hhciBhbGxvY19sZW47CisJdW5zaWduZWQgaW50IGFsbG9jX2x1bnMgPSAwOworCXVu
c2lnbmVkIGludCByZXFfYnVmZmxlbiA9IDA7CisJdW5zaWduZWQgaW50IGFjdHVhbF9sZW4gPSAw
OworCXVuc2lnbmVkIGludCByZXRyeV9jbnQgPSAwOworCWludCBzZWxlY3RfcmVwb3J0ID0gKGlu
dCljbWRbMl07CisJaW50IGksIGx1bl9jbnQgPSAwLCBsdW4sIHVwcGVyLCBlcnIgPSAwOworCisJ
c3RydWN0IHYycF9lbnRyeSAqZW50cnk7CisJc3RydWN0IGxpc3RfaGVhZCAqaGVhZCA9ICYoaW5m
by0+djJwX2VudHJ5X2xpc3RzKTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCisJc3RydWN0IHNj
c2lfbHVuICpvbmVfbHVuOworCisJcmVxX2J1ZmZsZW4gPSBjbWRbOV0gKyAoY21kWzhdIDw8IDgp
ICsgKGNtZFs3XSA8PCAxNikgKyAoY21kWzZdIDw8IDI0KTsKKwlpZiAoKHJlcV9idWZmbGVuIDwg
NCkgfHwgKHNlbGVjdF9yZXBvcnQgIT0gMCkpCisJCWdvdG8gZmFpbDsKKworCWFsbG9jX2x1bnMg
PSBfX25yX2x1bnNfdW5kZXJfaG9zdChpbmZvKTsKKwlhbGxvY19sZW4gID0gc2l6ZW9mKHN0cnVj
dCBzY3NpX2x1bikgKiBhbGxvY19sdW5zCisJCQkJKyBWU0NTSV9SRVBPUlRfTFVOU19IRUFERVI7
CityZXRyeToKKwlpZiAoKGJ1ZmYgPSBremFsbG9jKGFsbG9jX2xlbiwgR0ZQX0tFUk5FTCkpID09
IE5VTEwpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazolcyBrbWFsbG9jIGVyclxuIiwg
X19GVU5DVElPTl9fKTsKKwkJZ290byBmYWlsOworCX0KKworCW9uZV9sdW4gPSAoc3RydWN0IHNj
c2lfbHVuICopICZidWZmWzhdOworCXNwaW5fbG9ja19pcnFzYXZlKCZpbmZvLT52MnBfbG9jaywg
ZmxhZ3MpOworCWxpc3RfZm9yX2VhY2hfZW50cnkoZW50cnksIGhlYWQsIGwpIHsKKwkJaWYgKChl
bnRyeS0+di5jaG4gPT0gY2hhbm5lbCkgJiYKKwkJICAgIChlbnRyeS0+di50Z3QgPT0gdGFyZ2V0
KSkgeworCQkJLyogY2hlY2sgb3ZlcmZsb3cgKi8KKwkJCWlmIChsdW5fY250ID49IGFsbG9jX2x1
bnMpIHsKKwkJCQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpbmZvLT52MnBfbG9jaywKKwkJCQkJ
CQlmbGFncyk7CisKKwkJCQlpZiAocmV0cnlfY250IDwgVlNDU0lfUkVQT1JUX0xVTlNfUkVUUlkp
IHsKKwkJCQkJcmV0cnlfY250Kys7CisJCQkJCWlmIChidWZmKQorCQkJCQkJa2ZyZWUoYnVmZik7
CisJCQkJCWdvdG8gcmV0cnk7CisJCQkJfQorCisJCQkJZ290byBmYWlsOworCQkJfQorCisJCQls
dW4gPSBlbnRyeS0+di5sdW47CisJCQl1cHBlciA9IChsdW4gPj4gOCkgJiAweDNmOworCQkJaWYg
KHVwcGVyKQorCQkJCW9uZV9sdW5bbHVuX2NudF0uc2NzaV9sdW5bMF0gPSB1cHBlcjsKKwkJCW9u
ZV9sdW5bbHVuX2NudF0uc2NzaV9sdW5bMV0gPSBsdW4gJiAweGZmOworCQkJbHVuX2NudCsrOwor
CQl9CisJfQorCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+djJwX2xvY2ssIGZsYWdz
KTsKKworCWJ1ZmZbMl0gPSAoKHNpemVvZihzdHJ1Y3Qgc2NzaV9sdW4pICogbHVuX2NudCkgPj4g
OCkgJiAweGZmOworCWJ1ZmZbM10gPSAoc2l6ZW9mKHN0cnVjdCBzY3NpX2x1bikgKiBsdW5fY250
KSAmIDB4ZmY7CisKKwlhY3R1YWxfbGVuID0gbHVuX2NudCAqIHNpemVvZihzdHJ1Y3Qgc2NzaV9s
dW4pCisJCQkJKyBWU0NTSV9SRVBPUlRfTFVOU19IRUFERVI7CisJcmVxX2J1ZmZsZW4gPSAwOwor
CWZvciAoaSA9IDA7IGkgPCBucl9zZWc7IGkrKykKKwkJcmVxX2J1ZmZsZW4gKz0gcGVuZGluZ19y
ZXEtPnNnbFtpXS5sZW5ndGg7CisKKwllcnIgPSBfX2NvcHlfdG9fc2cocGVuZGluZ19yZXEtPnNn
bCwgbnJfc2VnLCBidWZmLAorCQkJCW1pbihyZXFfYnVmZmxlbiwgYWN0dWFsX2xlbikpOworCWlm
IChlcnIpCisJCWdvdG8gZmFpbDsKKworCW1lbXNldChwZW5kaW5nX3JlcS0+c2Vuc2VfYnVmZmVy
LCAwLCBWU0NTSUlGX1NFTlNFX0JVRkZFUlNJWkUpOworCXBlbmRpbmdfcmVxLT5yc2x0ID0gMHgw
MDsKKwlwZW5kaW5nX3JlcS0+cmVzaWQgPSByZXFfYnVmZmxlbiAtIG1pbihyZXFfYnVmZmxlbiwg
YWN0dWFsX2xlbik7CisKKwlrZnJlZShidWZmKTsKKwlyZXR1cm47CisKK2ZhaWw6CisJc2NzaWJh
Y2tfbWtfc2Vuc2VfYnVmZmVyKHBlbmRpbmdfcmVxLT5zZW5zZV9idWZmZXIsIElMTEVHQUxfUkVR
VUVTVCwKKwkJSU5WQUxJRF9GSUVMRF9JTl9DREIsIDApOworCXBlbmRpbmdfcmVxLT5yc2x0ICA9
IGNoZWNrX2NvbmRpdGlvbl9yZXN1bHQ7CisJcGVuZGluZ19yZXEtPnJlc2lkID0gMDsKKwlpZiAo
YnVmZikKKwkJa2ZyZWUoYnVmZik7CisJcmV0dXJuOworfQorCisKKworaW50IF9fcHJlX2RvX2Vt
dWxhdGlvbihwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcSwgdm9pZCAqZGF0YSkKK3sKKwl1aW50
OF90IG9wX2NvZGUgPSBwZW5kaW5nX3JlcS0+Y21uZFswXTsKKworCWlmICgoYml0bWFwW29wX2Nv
ZGVdICYgVlNDU0lJRl9ORUVEX0VNVUxBVEVfUkVRQlVGKSAmJgorCSAgICBwcmVfZnVuY3Rpb25b
b3BfY29kZV0gIT0gTlVMTCkgeworCQlwcmVfZnVuY3Rpb25bb3BfY29kZV0ocGVuZGluZ19yZXEs
IGRhdGEpOworCX0KKworCS8qCisJICAgIDA6IG5vIG5lZWQgZm9yIG5hdGl2ZSBkcml2ZXIgY2Fs
bCwgc28gc2hvdWxkIHJldHVybiBpbW1lZGlhdGVseS4KKwkgICAgMTogbm9uIGVtdWxhdGlvbiBv
ciBzaG91bGQgY2FsbCBuYXRpdmUgZHJpdmVyCisJICAgICAgIGFmdGVyIG1vZGlmaW5nIHRoZSBy
ZXF1ZXN0IGJ1ZmZlci4KKwkqLworCXJldHVybiAhIShiaXRtYXBbb3BfY29kZV0gJiBWU0NTSUlG
X05FRURfQ01EX0VYRUMpOworfQorCit2b2lkIHNjc2liYWNrX3JzcF9lbXVsYXRpb24ocGVuZGlu
Z19yZXFfdCAqcGVuZGluZ19yZXEpCit7CisJdWludDhfdCBvcF9jb2RlID0gcGVuZGluZ19yZXEt
PmNtbmRbMF07CisKKwlpZiAoKGJpdG1hcFtvcF9jb2RlXSAmIFZTQ1NJSUZfTkVFRF9FTVVMQVRF
X1JTUEJVRikgJiYKKwkgICAgcG9zdF9mdW5jdGlvbltvcF9jb2RlXSAhPSBOVUxMKSB7CisJCXBv
c3RfZnVuY3Rpb25bb3BfY29kZV0ocGVuZGluZ19yZXEsIE5VTEwpOworCX0KKworCXJldHVybjsK
K30KKworCit2b2lkIHNjc2liYWNrX3JlcV9lbXVsYXRpb25fb3JfY21kZXhlYyhwZW5kaW5nX3Jl
cV90ICpwZW5kaW5nX3JlcSkKK3sKKwlpZiAoX19wcmVfZG9fZW11bGF0aW9uKHBlbmRpbmdfcmVx
LCBOVUxMKSkgeworCQlzY3NpYmFja19jbWRfZXhlYyhwZW5kaW5nX3JlcSk7CisJfQorCWVsc2Ug
eworCQlzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVuZGluZ19yZXEpOworCQlzY3NpYmFja19k
b19yZXNwX3dpdGhfc2Vuc2UocGVuZGluZ19yZXEtPnNlbnNlX2J1ZmZlciwKKwkJICBwZW5kaW5n
X3JlcS0+cnNsdCwgcGVuZGluZ19yZXEtPnJlc2lkLCBwZW5kaW5nX3JlcSk7CisJfQorfQorCisK
Ky8qCisgIEZvbGxvd2luZyBhcmUgbm90IGN1c3RvbWl6YWJsZSBmdW5jdGlvbnMuCisqLwordm9p
ZCBzY3NpYmFja19lbXVsYXRpb25faW5pdCh2b2lkKQoreworCWludCBpOworCisJLyogSW5pdGlh
bGl6ZSB0byBkZWZhdWx0IHN0YXRlICovCisJZm9yIChpID0gMDsgaSA8IFZTQ1NJX01BWF9TQ1NJ
X09QX0NPREU7IGkrKykgeworCQliaXRtYXBbaV0gICAgICAgID0gKFZTQ1NJSUZfTkVFRF9FTVVM
QVRFX1JFUUJVRiB8CisJCQkJCVZTQ1NJSUZfTkVFRF9FTVVMQVRFX1JTUEJVRik7CisJCXByZV9m
dW5jdGlvbltpXSAgPSByZXNwX25vdF9zdXBwb3J0ZWRfY21kOworCQlwb3N0X2Z1bmN0aW9uW2ld
ID0gTlVMTDsKKwkJLyogbWVhbnMsCisJCSAgIC0gbm8gbmVlZCBmb3IgcHJlLWVtdWxhdGlvbgor
CQkgICAtIG5vIG5lZWQgZm9yIHBvc3QtZW11bGF0aW9uCisJCSAgIC0gY2FsbCBuYXRpdmUgZHJp
dmVyCisJCSovCisJfQorCisJLyoKKwkgIFJlZ2lzdGVyIGFwcHJvcHJpYXRlIGZ1bmN0aW9ucyBi
ZWxvdyBhcyB5b3UgbmVlZC4KKwkgIChTZWUgc2NzaS9zY3NpLmggZm9yIGRlZmluaXRpb24gb2Yg
U0NTSSBvcF9jb2RlLikKKwkqLworCisJLyoKKwkgIEZvbGxvd2luZyBjb21tYW5kcyBkbyBub3Qg
cmVxdWlyZSBlbXVsYXRpb24uCisJKi8KKwlOT19FTVVMQVRFKFRFU1RfVU5JVF9SRUFEWSk7ICAg
ICAgIC8qMHgwMCovIC8qIHNkLHN0ICovCisJTk9fRU1VTEFURShSRVpFUk9fVU5JVCk7ICAgICAg
ICAgICAvKjB4MDEqLyAvKiBzdCAqLworCU5PX0VNVUxBVEUoUkVRVUVTVF9TRU5TRSk7ICAgICAg
ICAgLyoweDAzKi8KKwlOT19FTVVMQVRFKEZPUk1BVF9VTklUKTsgICAgICAgICAgIC8qMHgwNCov
CisJTk9fRU1VTEFURShSRUFEX0JMT0NLX0xJTUlUUyk7ICAgICAvKjB4MDUqLyAvKiBzdCAqLwor
CS8qTk9fRU1VTEFURShSRUFTU0lHTl9CTE9DS1MpOyAgICAgICAqLy8qMHgwNyovCisJTk9fRU1V
TEFURShJTklUSUFMSVpFX0VMRU1FTlRfU1RBVFVTKTsgLyoweDA3Ki8gLyogY2ggKi8KKwlOT19F
TVVMQVRFKFJFQURfNik7ICAgICAgICAgICAgICAgIC8qMHgwOCovIC8qIHNkLHN0ICovCisJTk9f
RU1VTEFURShXUklURV82KTsgICAgICAgICAgICAgICAvKjB4MGEqLyAvKiBzZCxzdCAqLworCU5P
X0VNVUxBVEUoU0VFS182KTsgICAgICAgICAgICAgICAgLyoweDBiKi8KKwkvKk5PX0VNVUxBVEUo
UkVBRF9SRVZFUlNFKTsgICAgICAgICAgKi8vKjB4MGYqLworCU5PX0VNVUxBVEUoV1JJVEVfRklM
RU1BUktTKTsgICAgICAgLyoweDEwKi8gLyogc3QgKi8KKwlOT19FTVVMQVRFKFNQQUNFKTsgICAg
ICAgICAgICAgICAgIC8qMHgxMSovIC8qIHN0ICovCisJTk9fRU1VTEFURShJTlFVSVJZKTsgICAg
ICAgICAgICAgICAvKjB4MTIqLworCS8qTk9fRU1VTEFURShSRUNPVkVSX0JVRkZFUkVEX0RBVEEp
OyAqLy8qMHgxNCovCisJTk9fRU1VTEFURShNT0RFX1NFTEVDVCk7ICAgICAgICAgICAvKjB4MTUq
LyAvKiBzdCAqLworCU5PX0VNVUxBVEUoUkVTRVJWRSk7ICAgICAgICAgICAgICAgLyoweDE2Ki8K
KwlOT19FTVVMQVRFKFJFTEVBU0UpOyAgICAgICAgICAgICAgIC8qMHgxNyovCisJLypOT19FTVVM
QVRFKENPUFkpOyAgICAgICAgICAgICAgICAgICovLyoweDE4Ki8KKwlOT19FTVVMQVRFKEVSQVNF
KTsgICAgICAgICAgICAgICAgIC8qMHgxOSovIC8qIHN0ICovCisJTk9fRU1VTEFURShNT0RFX1NF
TlNFKTsgICAgICAgICAgICAvKjB4MWEqLyAvKiBzdCAqLworCU5PX0VNVUxBVEUoU1RBUlRfU1RP
UCk7ICAgICAgICAgICAgLyoweDFiKi8gLyogc2Qsc3QgKi8KKwlOT19FTVVMQVRFKFJFQ0VJVkVf
RElBR05PU1RJQyk7ICAgIC8qMHgxYyovCisJTk9fRU1VTEFURShTRU5EX0RJQUdOT1NUSUMpOyAg
ICAgICAvKjB4MWQqLworCU5PX0VNVUxBVEUoQUxMT1dfTUVESVVNX1JFTU9WQUwpOyAgLyoweDFl
Ki8KKworCS8qTk9fRU1VTEFURShTRVRfV0lORE9XKTsgICAgICAgICAgICAqLy8qMHgyNCovCisJ
Tk9fRU1VTEFURShSRUFEX0NBUEFDSVRZKTsgICAgICAgICAvKjB4MjUqLyAvKiBzZCAqLworCU5P
X0VNVUxBVEUoUkVBRF8xMCk7ICAgICAgICAgICAgICAgLyoweDI4Ki8gLyogc2QgKi8KKwlOT19F
TVVMQVRFKFdSSVRFXzEwKTsgICAgICAgICAgICAgIC8qMHgyYSovIC8qIHNkICovCisJTk9fRU1V
TEFURShTRUVLXzEwKTsgICAgICAgICAgICAgICAvKjB4MmIqLyAvKiBzdCAqLworCU5PX0VNVUxB
VEUoUE9TSVRJT05fVE9fRUxFTUVOVCk7ICAgLyoweDJiKi8gLyogY2ggKi8KKwkvKk5PX0VNVUxB
VEUoV1JJVEVfVkVSSUZZKTsgICAgICAgICAgKi8vKjB4MmUqLworCS8qTk9fRU1VTEFURShWRVJJ
RlkpOyAgICAgICAgICAgICAgICAqLy8qMHgyZiovCisJLypOT19FTVVMQVRFKFNFQVJDSF9ISUdI
KTsgICAgICAgICAgICovLyoweDMwKi8KKwkvKk5PX0VNVUxBVEUoU0VBUkNIX0VRVUFMKTsgICAg
ICAgICAgKi8vKjB4MzEqLworCS8qTk9fRU1VTEFURShTRUFSQ0hfTE9XKTsgICAgICAgICAgICAq
Ly8qMHgzMiovCisJTk9fRU1VTEFURShTRVRfTElNSVRTKTsgICAgICAgICAgICAvKjB4MzMqLwor
CU5PX0VNVUxBVEUoUFJFX0ZFVENIKTsgICAgICAgICAgICAgLyoweDM0Ki8gLyogc3QhICovCisJ
Tk9fRU1VTEFURShSRUFEX1BPU0lUSU9OKTsgICAgICAgICAgLyoweDM0Ki8gLyogc3QgKi8KKwlO
T19FTVVMQVRFKFNZTkNIUk9OSVpFX0NBQ0hFKTsgICAgICAvKjB4MzUqLyAvKiBzZCAqLworCU5P
X0VNVUxBVEUoTE9DS19VTkxPQ0tfQ0FDSEUpOyAgICAgLyoweDM2Ki8KKwlOT19FTVVMQVRFKFJF
QURfREVGRUNUX0RBVEEpOyAgICAgIC8qMHgzNyovCisJTk9fRU1VTEFURShNRURJVU1fU0NBTik7
ICAgICAgICAgICAvKjB4MzgqLworCS8qTk9fRU1VTEFURShDT01QQVJFKTsgICAgICAgICAgICAg
ICAqLy8qMHgzOSovCisJLypOT19FTVVMQVRFKENPUFlfVkVSSUZZKTsgICAgICAgICAgICovLyow
eDNhKi8KKwlOT19FTVVMQVRFKFdSSVRFX0JVRkZFUik7ICAgICAgICAgIC8qMHgzYiovCisJTk9f
RU1VTEFURShSRUFEX0JVRkZFUik7ICAgICAgICAgICAvKjB4M2MqLyAvKiBvc3N0ICovCisJLypO
T19FTVVMQVRFKFVQREFURV9CTE9DSyk7ICAgICAgICAgICovLyoweDNkKi8KKwkvKk5PX0VNVUxB
VEUoUkVBRF9MT05HKTsgICAgICAgICAgICAgKi8vKjB4M2UqLworCS8qTk9fRU1VTEFURShXUklU
RV9MT05HKTsgICAgICAgICAgICAqLy8qMHgzZiovCisJLypOT19FTVVMQVRFKENIQU5HRV9ERUZJ
TklUSU9OKTsgICAgICovLyoweDQwKi8KKwkvKk5PX0VNVUxBVEUoV1JJVEVfU0FNRSk7ICAgICAg
ICAgICAgKi8vKjB4NDEqLworCU5PX0VNVUxBVEUoUkVBRF9UT0MpOyAgICAgICAgICAgICAgLyow
eDQzKi8gLyogc3IgKi8KKwlOT19FTVVMQVRFKExPR19TRUxFQ1QpOyAgICAgICAgICAgIC8qMHg0
YyovCisJTk9fRU1VTEFURShMT0dfU0VOU0UpOyAgICAgICAgICAgICAvKjB4NGQqLyAvKiBzdCEg
Ki8KKwkvKk5PX0VNVUxBVEUoTU9ERV9TRUxFQ1RfMTApOyAgICAgICAgKi8vKjB4NTUqLworCS8q
Tk9fRU1VTEFURShSRVNFUlZFXzEwKTsgICAgICAgICAgICAqLy8qMHg1NiovCisJLypOT19FTVVM
QVRFKFJFTEVBU0VfMTApOyAgICAgICAgICAgICovLyoweDU3Ki8KKwlOT19FTVVMQVRFKE1PREVf
U0VOU0VfMTApOyAgICAgICAgIC8qMHg1YSovIC8qIHNjc2lfbGliICovCisJLypOT19FTVVMQVRF
KFBFUlNJU1RFTlRfUkVTRVJWRV9JTik7ICovLyoweDVlKi8KKwkvKk5PX0VNVUxBVEUoUEVSU0lT
VEVOVF9SRVNFUlZFX09VVCk7ICovLyoweDVmKi8KKwkvKiAgICAgICAgICAgUkVQT1JUX0xVTlMg
ICAgICAgICAgICAgKi8vKjB4YTAqLy8qRnVsbCBlbXVsYWl0b24qLworCU5PX0VNVUxBVEUoTUFJ
TlRFTkFOQ0VfSU4pOyAgICAgICAgICAgLyoweGEzKi8gLyogSUZUIGFsdWEgKi8KKwlOT19FTVVM
QVRFKE1BSU5URU5BTkNFX09VVCk7ICAgICAgIC8qMHhhNCovIC8qIElGVCBhbHVhICovCisJTk9f
RU1VTEFURShNT1ZFX01FRElVTSk7ICAgICAgICAgICAvKjB4YTUqLyAvKiBjaCAqLworCU5PX0VN
VUxBVEUoRVhDSEFOR0VfTUVESVVNKTsgICAgICAgLyoweGE2Ki8gLyogY2ggKi8KKwkvKk5PX0VN
VUxBVEUoUkVBRF8xMik7ICAgICAgICAgICAgICAgKi8vKjB4YTgqLworCS8qTk9fRU1VTEFURShX
UklURV8xMik7ICAgICAgICAgICAgICAqLy8qMHhhYSovCisJLypOT19FTVVMQVRFKFdSSVRFX1ZF
UklGWV8xMik7ICAgICAgICovLyoweGFlKi8KKwkvKk5PX0VNVUxBVEUoU0VBUkNIX0hJR0hfMTIp
OyAgICAgICAgKi8vKjB4YjAqLworCS8qTk9fRU1VTEFURShTRUFSQ0hfRVFVQUxfMTIpOyAgICAg
ICAqLy8qMHhiMSovCisJLypOT19FTVVMQVRFKFNFQVJDSF9MT1dfMTIpOyAgICAgICAgICovLyow
eGIyKi8KKwlOT19FTVVMQVRFKFJFQURfRUxFTUVOVF9TVEFUVVMpOyAgIC8qMHhiOCovIC8qIGNo
ICovCisJTk9fRU1VTEFURShTRU5EX1ZPTFVNRV9UQUcpOyAgICAgICAvKjB4YjYqLyAvKiBjaCAq
LworCS8qTk9fRU1VTEFURShXUklURV9MT05HXzIpOyAgICAgICAgICAqLy8qMHhlYSovCisJTk9f
RU1VTEFURShSRUFEXzE2KTsgICAgICAgICAgICAgICAvKjB4ODgqLyAvKiBzZCA+MlRCICovCisJ
Tk9fRU1VTEFURShXUklURV8xNik7ICAgICAgICAgICAgICAvKjB4OGEqLyAvKiBzZCA+MlRCICov
CisJTk9fRU1VTEFURShWRVJJRllfMTYpOwkgICAgICAgICAgIC8qMHg4ZiovCisJTk9fRU1VTEFU
RShTRVJWSUNFX0FDVElPTl9JTik7ICAgICAvKjB4OWUqLyAvKiBzZCA+MlRCICovCisKKy8qIHN0
OiBRRkFfUkVRVUVTVF9CTE9DSywgUUZBX1NFRUtfQkxPQ0sgbWlnaHQgYmUgbmVlZGVkID8gKi8K
KwkvKgorCSAgRm9sbG93aW5nIGNvbW1hbmRzIHJlcXVpcmUgZW11bGF0aW9uLgorCSovCisJcHJl
X2Z1bmN0aW9uW1JFUE9SVF9MVU5TXSA9IF9fcmVwb3J0X2x1bnM7CisJYml0bWFwW1JFUE9SVF9M
VU5TXSA9IChWU0NTSUlGX05FRURfRU1VTEFURV9SRVFCVUYgfAorCQkJCQlWU0NTSUlGX05FRURf
RU1VTEFURV9SU1BCVUYpOworCisJcmV0dXJuOworfQpkaWZmIC1ydXBOIHhlbi9kcml2ZXJzL3Nj
c2kveGVuLXNjc2liYWNrL2ludGVyZmFjZS5jIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFj
ay9pbnRlcmZhY2UuYwotLS0geGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWJhY2svaW50ZXJmYWNl
LmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3MDAKKysrIHhlbmMvZHJpdmVycy9z
Y3NpL3hlbi1zY3NpYmFjay9pbnRlcmZhY2UuYwkyMDEyLTAyLTI0IDE0OjU2OjEzLjUzODk3ODMw
MCAtMDcwMApAQCAtMCwwICsxLDE0MSBAQAorLyoKKyAqIGludGVyZmFjZSBtYW5hZ2VtZW50Lgor
ICoKKyAqIENvcHlyaWdodCAoYykgMjAwOCwgRlVKSVRTVSBMaW1pdGVkCisgKgorICogQmFzZWQg
b24gdGhlIGJsa2JhY2sgZHJpdmVyIGNvZGUuCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUg
c29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAy
CisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgb3IsIHdo
ZW4gZGlzdHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgga2VybmVsIG9yIGlu
Y29ycG9yYXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywgc3ViamVjdCB0byB0
aGUgZm9sbG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRl
ZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2Yg
dGhpcyBzb3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRoZSBTb2Z0d2Fy
ZSB3aXRob3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiB0
aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1Ymxpc2gsIGRpc3Ry
aWJ1dGUsIHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUsCisg
KiBhbmQgdG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUgaXMgZnVybmlzaGVk
IHRvIGRvIHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6CisgKgor
ICogVGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ug
c2hhbGwgYmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3RhbnRpYWwgcG9ydGlv
bnMgb2YgdGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMg
SVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9SCisgKiBJTVBMSUVE
LCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GIE1FUkNIQU5U
QUJJTElUWSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZS
SU5HRU1FTlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBPUiBDT1BZUklHSFQg
SE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBPVEhFUgorICogTElB
QklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJ
U0UsIEFSSVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNP
RlRXQVJFIE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRIRSBTT0ZUV0FSRS4K
KyAqLworCisjaW5jbHVkZSA8c2NzaS9zY3NpLmg+CisjaW5jbHVkZSA8c2NzaS9zY3NpX2hvc3Qu
aD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lfZGV2aWNlLmg+CisjaW5jbHVkZSAiY29tbW9uLmgiCisK
KyNpbmNsdWRlIDx4ZW4vZXZ0Y2huLmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2lu
Y2x1ZGUgPGxpbnV4L2RlbGF5Lmg+CisKKworc3RhdGljIHN0cnVjdCBrbWVtX2NhY2hlICpzY3Np
YmFja19jYWNoZXA7CisKK3N0cnVjdCB2c2NzaWJrX2luZm8gKnZzY3NpYmtfaW5mb19hbGxvYyhk
b21pZF90IGRvbWlkKQoreworCXN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm87CisKKwlpbmZvID0g
a21lbV9jYWNoZV96YWxsb2Moc2NzaWJhY2tfY2FjaGVwLCBHRlBfS0VSTkVMKTsKKwlpZiAoIWlu
Zm8pCisJCXJldHVybiBFUlJfUFRSKC1FTk9NRU0pOworCisJaW5mby0+ZG9taWQgPSBkb21pZDsK
KwlzcGluX2xvY2tfaW5pdCgmaW5mby0+cmluZ19sb2NrKTsKKwlhdG9taWNfc2V0KCZpbmZvLT5u
cl91bnJlcGxpZWRfcmVxcywgMCk7CisJaW5pdF93YWl0cXVldWVfaGVhZCgmaW5mby0+d3EpOwor
CWluaXRfd2FpdHF1ZXVlX2hlYWQoJmluZm8tPndhaXRpbmdfdG9fZnJlZSk7CisKKwlyZXR1cm4g
aW5mbzsKK30KKworaW50IHNjc2liYWNrX2luaXRfc3Jpbmcoc3RydWN0IHZzY3NpYmtfaW5mbyAq
aW5mbywKKwkJdW5zaWduZWQgbG9uZyByaW5nX3JlZiwgdW5zaWduZWQgaW50IGV2dGNobikKK3sK
KwlzdHJ1Y3QgdnNjc2lpZl9zcmluZyAqc3Jpbmc7CisJaW50IGVycjsKKworCWlmICghaW5mbykK
KwkJcmV0dXJuIC1FTk9ERVY7CisKKwlpZiAoaW5mby0+aXJxKSB7CisJCXByaW50ayhLRVJOX0VS
UiAic2NzaWJhY2s6IEFscmVhZHkgY29ubmVjdGVkIHRocm91Z2g/XG4iKTsKKwkJcmV0dXJuIC0x
OworCX0KKworCWVyciA9IHhlbmJ1c19tYXBfcmluZ192YWxsb2MoaW5mby0+ZGV2LCByaW5nX3Jl
ZiwgJmluZm8tPnJpbmdfYXJlYSk7CisJaWYgKGVyciA8IDApCisJCXJldHVybiAtRU5PTUVNOwor
CisJc3JpbmcgPSAoc3RydWN0IHZzY3NpaWZfc3JpbmcgKikgaW5mby0+cmluZ19hcmVhOworCUJB
Q0tfUklOR19JTklUKCZpbmZvLT5yaW5nLCBzcmluZywgUEFHRV9TSVpFKTsKKworCWVyciA9IGJp
bmRfaW50ZXJkb21haW5fZXZ0Y2huX3RvX2lycWhhbmRsZXIoCisJCQlpbmZvLT5kb21pZCwgZXZ0
Y2huLAorCQkJc2NzaWJhY2tfaW50ciwgMCwgInZzY3NpaWYtYmFja2VuZCIsIGluZm8pOworCWlm
IChlcnIgPCAwKQorCQlnb3RvIHVubWFwX3BhZ2U7CisKKwlpbmZvLT5pcnEgPSBlcnI7CisKKwly
ZXR1cm4gMDsKKwordW5tYXBfcGFnZToKKwl4ZW5idXNfdW5tYXBfcmluZ192ZnJlZShpbmZvLT5k
ZXYsIGluZm8tPnJpbmdfYXJlYSk7CisKKwlyZXR1cm4gZXJyOworfQorCit2b2lkIHNjc2liYWNr
X2Rpc2Nvbm5lY3Qoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbykKK3sKKwlpZiAoaW5mby0+a3Ro
cmVhZCkgeworCQlrdGhyZWFkX3N0b3AoaW5mby0+a3RocmVhZCk7CisJCWluZm8tPmt0aHJlYWQg
PSBOVUxMOworCX0KKworCXdhaXRfZXZlbnQoaW5mby0+d2FpdGluZ190b19mcmVlLAorCQlhdG9t
aWNfcmVhZCgmaW5mby0+bnJfdW5yZXBsaWVkX3JlcXMpID09IDApOworCisJaWYgKGluZm8tPmly
cSkgeworCQl1bmJpbmRfZnJvbV9pcnFoYW5kbGVyKGluZm8tPmlycSwgaW5mbyk7CisJCWluZm8t
PmlycSA9IDA7CisJfQorCisJaWYgKGluZm8tPnJpbmcuc3JpbmcgfHwgaW5mby0+cmluZ19hcmVh
KSB7CisJCXhlbmJ1c191bm1hcF9yaW5nX3ZmcmVlKGluZm8tPmRldiwgaW5mby0+cmluZ19hcmVh
KTsKKwkJaW5mby0+cmluZy5zcmluZyA9IE5VTEw7CisJCWluZm8tPnJpbmdfYXJlYSA9IE5VTEw7
CisJfQorfQorCit2b2lkIHNjc2liYWNrX2ZyZWUoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbykK
K3sKKwlrbWVtX2NhY2hlX2ZyZWUoc2NzaWJhY2tfY2FjaGVwLCBpbmZvKTsKK30KKworaW50IF9f
aW5pdCBzY3NpYmFja19pbnRlcmZhY2VfaW5pdCh2b2lkKQoreworCXNjc2liYWNrX2NhY2hlcCA9
IGttZW1fY2FjaGVfY3JlYXRlKCJ2c2NzaWlmX2NhY2hlIiwKKwkJc2l6ZW9mKHN0cnVjdCB2c2Nz
aWJrX2luZm8pLCAwLCAwLCBOVUxMKTsKKwlpZiAoIXNjc2liYWNrX2NhY2hlcCkgeworCQlwcmlu
dGsoS0VSTl9FUlIgInNjc2liYWNrOiBjYW4ndCBpbml0IHNjc2kgY2FjaGVcbiIpOworCQlyZXR1
cm4gLUVOT01FTTsKKwl9CisKKwlyZXR1cm4gMDsKK30KKwordm9pZCBzY3NpYmFja19pbnRlcmZh
Y2VfZXhpdCh2b2lkKQoreworCWttZW1fY2FjaGVfZGVzdHJveShzY3NpYmFja19jYWNoZXApOwor
fQpkaWZmIC1ydXBOIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3Njc2liYWNrLmMgeGVu
Yy9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3Njc2liYWNrLmMKLS0tIHhlbi9kcml2ZXJzL3Nj
c2kveGVuLXNjc2liYWNrL3Njc2liYWNrLmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAg
LTA3MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFjay9zY3NpYmFjay5jCTIwMTIt
MDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNzU3IEBACisvKgorICog
WGVuIFNDU0kgYmFja2VuZCBkcml2ZXIKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZVSklU
U1UgTGltaXRlZAorICoKKyAqIEJhc2VkIG9uIHRoZSBibGtiYWNrIGRyaXZlciBjb2RlLgorICoK
KyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBp
dCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFs
IFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisgKiBzZXBhcmF0ZWx5IGZy
b20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBvdGhlcgorICogc29mdHdh
cmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNlbnNlOgorICoKKyAqIFBl
cm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVyc29u
IG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUgKHRoZSAiU29mdHdhcmUi
KSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVzdHJpY3Rpb24sIGluY2x1
ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlmeSwK
KyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3Igc2VsbCBj
b3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdob20g
dGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0bworICogdGhlIGZv
bGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFu
ZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwgY29w
aWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUg
U09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lO
RCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBU
SEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJ
Q1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUK
KyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0s
IERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04gT0Yg
Q09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0YgT1Ig
SU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERFQUxJ
TkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L3NwaW5sb2Nr
Lmg+CisjaW5jbHVkZSA8bGludXgva3RocmVhZC5oPgorI2luY2x1ZGUgPGxpbnV4L2xpc3QuaD4K
KyNpbmNsdWRlIDxsaW51eC9kZWxheS5oPgorI2luY2x1ZGUgPHhlbi9iYWxsb29uLmg+CisjaW5j
bHVkZSA8YXNtL2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2kuaD4KKyNpbmNsdWRl
IDxzY3NpL3Njc2lfY21uZC5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaV9ob3N0Lmg+CisjaW5jbHVk
ZSA8c2NzaS9zY3NpX2RldmljZS5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaV9kYmcuaD4KKyNpbmNs
dWRlIDxzY3NpL3Njc2lfZWguaD4KKworI2luY2x1ZGUgImNvbW1vbi5oIgorCisKK3N0cnVjdCBs
aXN0X2hlYWQgcGVuZGluZ19mcmVlOworREVGSU5FX1NQSU5MT0NLKHBlbmRpbmdfZnJlZV9sb2Nr
KTsKK0RFQ0xBUkVfV0FJVF9RVUVVRV9IRUFEKHBlbmRpbmdfZnJlZV93cSk7CisKK2ludCB2c2Nz
aWlmX3JlcXMgPSBWU0NTSUlGX0JBQ0tfTUFYX1BFTkRJTkdfUkVRUzsKK21vZHVsZV9wYXJhbV9u
YW1lZChyZXFzLCB2c2NzaWlmX3JlcXMsIGludCwgMCk7CitNT0RVTEVfUEFSTV9ERVNDKHJlcXMs
ICJOdW1iZXIgb2Ygc2NzaWJhY2sgcmVxdWVzdHMgdG8gYWxsb2NhdGUiKTsKKworc3RhdGljIHVu
c2lnbmVkIGludCBsb2dfcHJpbnRfc3RhdDsKK21vZHVsZV9wYXJhbShsb2dfcHJpbnRfc3RhdCwg
aW50LCAwNjQ0KTsKKworI2RlZmluZSBTQ1NJQkFDS19JTlZBTElEX0hBTkRMRSAofjApCisKK3N0
YXRpYyBwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcXM7CitzdGF0aWMgc3RydWN0IHBhZ2UgKipw
ZW5kaW5nX3BhZ2VzOworc3RhdGljIGdyYW50X2hhbmRsZV90ICpwZW5kaW5nX2dyYW50X2hhbmRs
ZXM7CisKK3N0YXRpYyBpbnQgdmFkZHJfcGFnZW5yKHBlbmRpbmdfcmVxX3QgKnJlcSwgaW50IHNl
ZykKK3sKKwlyZXR1cm4gKHJlcSAtIHBlbmRpbmdfcmVxcykgKiBWU0NTSUlGX1NHX1RBQkxFU0la
RSArIHNlZzsKK30KKworc3RhdGljIHVuc2lnbmVkIGxvbmcgdmFkZHIocGVuZGluZ19yZXFfdCAq
cmVxLCBpbnQgc2VnKQoreworCXVuc2lnbmVkIGxvbmcgcGZuID0gcGFnZV90b19wZm4ocGVuZGlu
Z19wYWdlc1t2YWRkcl9wYWdlbnIocmVxLCBzZWcpXSk7CisJcmV0dXJuICh1bnNpZ25lZCBsb25n
KXBmbl90b19rYWRkcihwZm4pOworfQorCisjZGVmaW5lIHBlbmRpbmdfaGFuZGxlKF9yZXEsIF9z
ZWcpIFwKKwkocGVuZGluZ19ncmFudF9oYW5kbGVzW3ZhZGRyX3BhZ2VucihfcmVxLCBfc2VnKV0p
CisKKwordm9pZCBzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVuZGluZ19yZXFfdCAqcmVxKQor
eworCXN0cnVjdCBnbnR0YWJfdW5tYXBfZ3JhbnRfcmVmIHVubWFwW1ZTQ1NJSUZfU0dfVEFCTEVT
SVpFXTsKKwl1bnNpZ25lZCBpbnQgaSwgaW52Y291bnQgPSAwOworCWdyYW50X2hhbmRsZV90IGhh
bmRsZTsKKwlpbnQgZXJyOworCisJaWYgKHJlcS0+bnJfc2VnbWVudHMpIHsKKwkJZm9yIChpID0g
MDsgaSA8IHJlcS0+bnJfc2VnbWVudHM7IGkrKykgeworCQkJaGFuZGxlID0gcGVuZGluZ19oYW5k
bGUocmVxLCBpKTsKKwkJCWlmIChoYW5kbGUgPT0gU0NTSUJBQ0tfSU5WQUxJRF9IQU5ETEUpCisJ
CQkJY29udGludWU7CisJCQlnbnR0YWJfc2V0X3VubWFwX29wKCZ1bm1hcFtpXSwgdmFkZHIocmVx
LCBpKSwKKwkJCQkJCUdOVE1BUF9ob3N0X21hcCwgaGFuZGxlKTsKKwkJCXBlbmRpbmdfaGFuZGxl
KHJlcSwgaSkgPSBTQ1NJQkFDS19JTlZBTElEX0hBTkRMRTsKKwkJCWludmNvdW50Kys7CisJCX0K
KworCQllcnIgPSBIWVBFUlZJU09SX2dyYW50X3RhYmxlX29wKAorCQkJR05UVEFCT1BfdW5tYXBf
Z3JhbnRfcmVmLCB1bm1hcCwgaW52Y291bnQpOworCQlCVUdfT04oZXJyKTsKKwkJZm9yIChpID0g
MDsgaSA8aW52Y291bnQ7IGkrKykgeworCQkJZXJyID0gbTJwX3JlbW92ZV9vdmVycmlkZSgKKwkJ
CQl2aXJ0X3RvX3BhZ2UodW5tYXBbaV0uaG9zdF9hZGRyKSwgZmFsc2UpOworCQkJV0FSTl9PTihl
cnIpOworCQl9CisJCWtmcmVlKHJlcS0+c2dsKTsKKwl9CisKKwlyZXR1cm47Cit9CisKKworc3Rh
dGljIHBlbmRpbmdfcmVxX3QgKiBhbGxvY19yZXEoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbykK
K3sKKwlwZW5kaW5nX3JlcV90ICpyZXEgPSBOVUxMOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisK
KwlzcGluX2xvY2tfaXJxc2F2ZSgmcGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwlpZiAoIWxp
c3RfZW1wdHkoJnBlbmRpbmdfZnJlZSkpIHsKKwkJcmVxID0gbGlzdF9lbnRyeShwZW5kaW5nX2Zy
ZWUubmV4dCwgcGVuZGluZ19yZXFfdCwgZnJlZV9saXN0KTsKKwkJbGlzdF9kZWwoJnJlcS0+ZnJl
ZV9saXN0KTsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcGVuZGluZ19mcmVlX2xvY2ss
IGZsYWdzKTsKKwlyZXR1cm4gcmVxOworfQorCisKK3N0YXRpYyB2b2lkIGZyZWVfcmVxKHBlbmRp
bmdfcmVxX3QgKnJlcSkKK3sKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCB3YXNfZW1wdHk7
CisKKwlzcGluX2xvY2tfaXJxc2F2ZSgmcGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwl3YXNf
ZW1wdHkgPSBsaXN0X2VtcHR5KCZwZW5kaW5nX2ZyZWUpOworCWxpc3RfYWRkKCZyZXEtPmZyZWVf
bGlzdCwgJnBlbmRpbmdfZnJlZSk7CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcGVuZGluZ19m
cmVlX2xvY2ssIGZsYWdzKTsKKwlpZiAod2FzX2VtcHR5KQorCQl3YWtlX3VwKCZwZW5kaW5nX2Zy
ZWVfd3EpOworfQorCisKK3N0YXRpYyB2b2lkIHNjc2liYWNrX25vdGlmeV93b3JrKHN0cnVjdCB2
c2NzaWJrX2luZm8gKmluZm8pCit7CisJaW5mby0+d2FpdGluZ19yZXFzID0gMTsKKwl3YWtlX3Vw
KCZpbmZvLT53cSk7Cit9CisKK3ZvaWQgc2NzaWJhY2tfZG9fcmVzcF93aXRoX3NlbnNlKGNoYXIg
KnNlbnNlX2J1ZmZlciwgaW50MzJfdCByZXN1bHQsCisJCQl1aW50MzJfdCByZXNpZCwgcGVuZGlu
Z19yZXFfdCAqcGVuZGluZ19yZXEpCit7CisJdnNjc2lpZl9yZXNwb25zZV90ICpyaW5nX3JlczsK
KwlzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvID0gcGVuZGluZ19yZXEtPmluZm87CisJaW50IG5v
dGlmeTsKKwlpbnQgbW9yZV90b19kbyA9IDE7CisJc3RydWN0IHNjc2lfc2Vuc2VfaGRyIHNzaGRy
OworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisKKwlEUFJJTlRLKCIlc1xuIixfX0ZVTkNUSU9OX18p
OworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmluZm8tPnJpbmdfbG9jaywgZmxhZ3MpOworCisJcmlu
Z19yZXMgPSBSSU5HX0dFVF9SRVNQT05TRSgmaW5mby0+cmluZywgaW5mby0+cmluZy5yc3BfcHJv
ZF9wdnQpOworCWluZm8tPnJpbmcucnNwX3Byb2RfcHZ0Kys7CisKKwlyaW5nX3Jlcy0+cnNsdCAg
ID0gcmVzdWx0OworCXJpbmdfcmVzLT5ycWlkICAgPSBwZW5kaW5nX3JlcS0+cnFpZDsKKworCWlm
IChzZW5zZV9idWZmZXIgIT0gTlVMTCkgeworCQlpZiAoc2NzaV9ub3JtYWxpemVfc2Vuc2Uoc2Vu
c2VfYnVmZmVyLAorCQkJc2l6ZW9mKHNlbnNlX2J1ZmZlciksICZzc2hkcikpIHsKKworCQkJaW50
IGxlbiA9IDggKyBzZW5zZV9idWZmZXJbN107CisKKwkJCWlmIChsZW4gPiBWU0NTSUlGX1NFTlNF
X0JVRkZFUlNJWkUpCisJCQkJbGVuID0gVlNDU0lJRl9TRU5TRV9CVUZGRVJTSVpFOworCisJCQlt
ZW1jcHkocmluZ19yZXMtPnNlbnNlX2J1ZmZlciwgc2Vuc2VfYnVmZmVyLCBsZW4pOworCQkJcmlu
Z19yZXMtPnNlbnNlX2xlbiA9IGxlbjsKKwkJfQorCX0gZWxzZSB7CisJCXJpbmdfcmVzLT5zZW5z
ZV9sZW4gPSAwOworCX0KKworCXJpbmdfcmVzLT5yZXNpZHVhbF9sZW4gPSByZXNpZDsKKworCVJJ
TkdfUFVTSF9SRVNQT05TRVNfQU5EX0NIRUNLX05PVElGWSgmaW5mby0+cmluZywgbm90aWZ5KTsK
KwlpZiAoaW5mby0+cmluZy5yc3BfcHJvZF9wdnQgPT0gaW5mby0+cmluZy5yZXFfY29ucykgewor
CQlSSU5HX0ZJTkFMX0NIRUNLX0ZPUl9SRVFVRVNUUygmaW5mby0+cmluZywgbW9yZV90b19kbyk7
CisJfSBlbHNlIGlmIChSSU5HX0hBU19VTkNPTlNVTUVEX1JFUVVFU1RTKCZpbmZvLT5yaW5nKSkg
eworCQltb3JlX3RvX2RvID0gMTsKKwl9CisKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpbmZv
LT5yaW5nX2xvY2ssIGZsYWdzKTsKKworCWlmIChtb3JlX3RvX2RvKQorCQlzY3NpYmFja19ub3Rp
Znlfd29yayhpbmZvKTsKKworCWlmIChub3RpZnkpCisJCW5vdGlmeV9yZW1vdGVfdmlhX2lycShp
bmZvLT5pcnEpOworCisJZnJlZV9yZXEocGVuZGluZ19yZXEpOworfQorCitzdGF0aWMgdm9pZCBz
Y3NpYmFja19wcmludF9zdGF0dXMoY2hhciAqc2Vuc2VfYnVmZmVyLCBpbnQgZXJyb3JzLAorCQkJ
CQlwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcSkKK3sKKwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNk
ZXYgPSBwZW5kaW5nX3JlcS0+c2RldjsKKworCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6ICVk
OiVkOiVkOiVkICIsc2Rldi0+aG9zdC0+aG9zdF9ubywKKwkJCXNkZXYtPmNoYW5uZWwsIHNkZXYt
PmlkLCBzZGV2LT5sdW4pOworCXByaW50ayhLRVJOX0VSUiAic3RhdHVzID0gMHglMDJ4LCBtZXNz
YWdlID0gMHglMDJ4LCBob3N0ID0gMHglMDJ4LCBkcml2ZXIgPSAweCUwMnhcbiIsCisJCQlzdGF0
dXNfYnl0ZShlcnJvcnMpLCBtc2dfYnl0ZShlcnJvcnMpLAorCQkJaG9zdF9ieXRlKGVycm9ycyks
IGRyaXZlcl9ieXRlKGVycm9ycykpOworCisJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogY21u
ZFswXT0weCUwMlhcbiIsCisJCQlwZW5kaW5nX3JlcS0+Y21uZFswXSk7CisKKwlpZiAoQ0hFQ0tf
Q09ORElUSU9OICYgc3RhdHVzX2J5dGUoZXJyb3JzKSkKKwkJX19zY3NpX3ByaW50X3NlbnNlKCJz
Y3NpYmFjayIsIHNlbnNlX2J1ZmZlciwgU0NTSV9TRU5TRV9CVUZGRVJTSVpFKTsKK30KKworCitz
dGF0aWMgdm9pZCBzY3NpYmFja19jbWRfZG9uZShzdHJ1Y3QgcmVxdWVzdCAqcmVxLCBpbnQgdXB0
b2RhdGUpCit7CisJcGVuZGluZ19yZXFfdCAqcGVuZGluZ19yZXEgPSByZXEtPmVuZF9pb19kYXRh
OworCXVuc2lnbmVkIGNoYXIgKnNlbnNlX2J1ZmZlcjsKKwl1bnNpZ25lZCBpbnQgcmVzaWQ7CisJ
aW50IGVycm9yczsKKworCXNlbnNlX2J1ZmZlciA9IHJlcS0+c2Vuc2U7CisJcmVzaWQgICAgICAg
ID0gYmxrX3JxX2J5dGVzKHJlcSk7CisJZXJyb3JzICAgICAgID0gcmVxLT5lcnJvcnM7CisKKwlp
ZiAoZXJyb3JzICE9IDApIHsKKwkJaWYgKGxvZ19wcmludF9zdGF0KQorCQkJc2NzaWJhY2tfcHJp
bnRfc3RhdHVzKHNlbnNlX2J1ZmZlciwgZXJyb3JzLCBwZW5kaW5nX3JlcSk7CisJfQorCisJLyog
VGhlIEhvc3QgbW9kZSBpcyB0aHJvdWdoIGFzIGZvciBFbXVsYXRpb24uICovCisJaWYgKHBlbmRp
bmdfcmVxLT5pbmZvLT5mZWF0dXJlICE9IFZTQ1NJX1RZUEVfSE9TVCkKKwkJc2NzaWJhY2tfcnNw
X2VtdWxhdGlvbihwZW5kaW5nX3JlcSk7CisKKwlzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEocGVu
ZGluZ19yZXEpOworCXNjc2liYWNrX2RvX3Jlc3Bfd2l0aF9zZW5zZShzZW5zZV9idWZmZXIsIGVy
cm9ycywgcmVzaWQsIHBlbmRpbmdfcmVxKTsKKwlzY3NpYmFja19wdXQocGVuZGluZ19yZXEtPmlu
Zm8pOworCisJX19ibGtfcHV0X3JlcXVlc3QocmVxLT5xLCByZXEpOworfQorCisKK3N0YXRpYyBp
bnQgc2NzaWJhY2tfZ250dGFiX2RhdGFfbWFwKHZzY3NpaWZfcmVxdWVzdF90ICpyaW5nX3JlcSwK
KwkJCQkJcGVuZGluZ19yZXFfdCAqcGVuZGluZ19yZXEpCit7CisJdTMyIGZsYWdzOworCWludCB3
cml0ZTsKKwlpbnQgaSwgZXJyID0gMDsKKwl1bnNpZ25lZCBpbnQgZGF0YV9sZW4gPSAwOworCXN0
cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiBtYXBbVlNDU0lJRl9TR19UQUJMRVNJWkVdOworCXN0
cnVjdCB2c2NzaWJrX2luZm8gKmluZm8gICA9IHBlbmRpbmdfcmVxLT5pbmZvOworCisJaW50IGRh
dGFfZGlyID0gcGVuZGluZ19yZXEtPnNjX2RhdGFfZGlyZWN0aW9uOworCXVuc2lnbmVkIGludCBu
cl9zZWdtZW50cyA9ICh1bnNpZ25lZCBpbnQpcGVuZGluZ19yZXEtPm5yX3NlZ21lbnRzOworCisJ
d3JpdGUgPSAoZGF0YV9kaXIgPT0gRE1BX1RPX0RFVklDRSk7CisKKwlpZiAobnJfc2VnbWVudHMp
IHsKKwkJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsKKworCQkvKiBmcmVlIG9mIChzZ2wpIGluIGZh
c3RfZmx1c2hfYXJlYSgpKi8KKwkJcGVuZGluZ19yZXEtPnNnbCA9IGttYWxsb2Moc2l6ZW9mKHN0
cnVjdCBzY2F0dGVybGlzdCkgKiBucl9zZWdtZW50cywKKwkJCQkJCUdGUF9LRVJORUwpOworCQlp
ZiAoIXBlbmRpbmdfcmVxLT5zZ2wpIHsKKwkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6ICVz
OiBrbWFsbG9jKCkgZXJyb3IuXG4iLCBfX0ZVTkNUSU9OX18pOworCQkJcmV0dXJuIC1FTk9NRU07
CisJCX0KKworCQlzZ19pbml0X3RhYmxlKHBlbmRpbmdfcmVxLT5zZ2wsIG5yX3NlZ21lbnRzKTsK
KworCQlmb3IgKGkgPSAwOyBpIDwgbnJfc2VnbWVudHM7IGkrKykgeworCQkJZmxhZ3MgPSBHTlRN
QVBfaG9zdF9tYXA7CisJCQlpZiAod3JpdGUpCisJCQkJZmxhZ3MgfD0gR05UTUFQX3JlYWRvbmx5
OworCisJCQlnbnR0YWJfc2V0X21hcF9vcCgmbWFwW2ldLCB2YWRkcihwZW5kaW5nX3JlcSwgaSks
IGZsYWdzLAorCQkJCQkJcmluZ19yZXEtPnNlZ1tpXS5ncmVmLAorCQkJCQkJaW5mby0+ZG9taWQp
OworCQl9CisKKwkJZXJyID0gSFlQRVJWSVNPUl9ncmFudF90YWJsZV9vcChHTlRUQUJPUF9tYXBf
Z3JhbnRfcmVmLCBtYXAsIG5yX3NlZ21lbnRzKTsKKwkJQlVHX09OKGVycik7CisKKwkJLyogUmV0
cnkgbWFwcyB3aXRoIEdOVFNUX2VhZ2FpbiAqLworCQlmb3IoaT0wOyBpIDwgbnJfc2VnbWVudHM7
IGkrKykgeworCQkgICAgd2hpbGUodW5saWtlbHkobWFwW2ldLnN0YXR1cyA9PSBHTlRTVF9lYWdh
aW4pKQorCQkgICAgeworCQkJCW1zbGVlcCgxMCk7CisJCQkJZXJyID0gSFlQRVJWSVNPUl9ncmFu
dF90YWJsZV9vcChHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmLAorCQkJCQkJCSZtYXBbaV0sCisJCQkJ
CQkJMSk7CisJCQkJQlVHX09OKGVycik7CisJCSAgICB9CisJCX0KKworCQlmb3JfZWFjaF9zZyAo
cGVuZGluZ19yZXEtPnNnbCwgc2csIG5yX3NlZ21lbnRzLCBpKSB7CisJCQlzdHJ1Y3QgcGFnZSAq
cGc7CisKKwkJCWlmICh1bmxpa2VseShtYXBbaV0uc3RhdHVzICE9IDApKSB7CisJCQkJcHJpbnRr
KEtFUk5fRVJSICJzY3NpYmFjazogaW52YWxpZCBidWZmZXIgLS0gY291bGQgbm90IHJlbWFwIGl0
OiAiIFwKKwkJCQkJIiVkLyVkLCBlcnI6JWRcbiIsIGksIG5yX3NlZ21lbnRzLCBtYXBbaV0uc3Rh
dHVzKTsKKwkJCQltYXBbaV0uaGFuZGxlID0gU0NTSUJBQ0tfSU5WQUxJRF9IQU5ETEU7CisJCQkJ
ZXJyIHw9IDE7CisJCQl9CisKKwkJCXBlbmRpbmdfaGFuZGxlKHBlbmRpbmdfcmVxLCBpKSA9IG1h
cFtpXS5oYW5kbGU7CisKKwkJCWlmIChlcnIpCisJCQkJY29udGludWU7CisKKwkJCXBnID0gcGVu
ZGluZ19wYWdlc1t2YWRkcl9wYWdlbnIocGVuZGluZ19yZXEsIGkpXTsKKworCQkJbTJwX2FkZF9v
dmVycmlkZShQRk5fRE9XTihtYXBbaV0uZGV2X2J1c19hZGRyKSwgcGcsIGZhbHNlKTsKKwkJCXNn
X3NldF9wYWdlKHNnLCBwZywgcmluZ19yZXEtPnNlZ1tpXS5sZW5ndGgsCisJCQkJICAgIHJpbmdf
cmVxLT5zZWdbaV0ub2Zmc2V0KTsKKwkJCWRhdGFfbGVuICs9IHNnLT5sZW5ndGg7CisKKwkJCWJh
cnJpZXIoKTsKKwkJCWlmIChzZy0+b2Zmc2V0ID49IFBBR0VfU0laRSB8fAorCQkJICAgIHNnLT5s
ZW5ndGggPiBQQUdFX1NJWkUgfHwKKwkJCSAgICBzZy0+b2Zmc2V0ICsgc2ctPmxlbmd0aCA+IFBB
R0VfU0laRSkKKwkJCQllcnIgfD0gMTsKKworCQl9CisKKwkJaWYgKGVycikKKwkJCWdvdG8gZmFp
bF9mbHVzaDsKKwl9CisKKwlwZW5kaW5nX3JlcS0+cmVxdWVzdF9idWZmbGVuID0gZGF0YV9sZW47
CisKKwlyZXR1cm4gMDsKKworZmFpbF9mbHVzaDoKKwlzY3NpYmFja19mYXN0X2ZsdXNoX2FyZWEo
cGVuZGluZ19yZXEpOworCXJldHVybiAtRU5PTUVNOworfQorCisvKiBxdW90ZWQgc2NzaV9saWIu
Yy9zY3NpX2JpX2VuZGlvICovCitzdGF0aWMgdm9pZCBzY3NpYmFja19iaV9lbmRpbyhzdHJ1Y3Qg
YmlvICpiaW8sIGludCBlcnJvcikKK3sKKwliaW9fcHV0KGJpbyk7Cit9CisKKworCisvKiBxdW90
ZWQgc2NzaV9saWIuYy9zY3NpX3JlcV9tYXBfc2cgLiAqLworc3RhdGljIHN0cnVjdCBiaW8gKnJl
cXVlc3RfbWFwX3NnKHBlbmRpbmdfcmVxX3QgKnBlbmRpbmdfcmVxKQoreworCXN0cnVjdCByZXF1
ZXN0X3F1ZXVlICpxID0gcGVuZGluZ19yZXEtPnNkZXYtPnJlcXVlc3RfcXVldWU7CisJdW5zaWdu
ZWQgaW50IG5zZWdzID0gKHVuc2lnbmVkIGludClwZW5kaW5nX3JlcS0+bnJfc2VnbWVudHM7CisJ
dW5zaWduZWQgaW50IGksIGxlbiwgYnl0ZXMsIG9mZiwgbnJfcGFnZXMsIG5yX3ZlY3MgPSAwOwor
CXN0cnVjdCBzY2F0dGVybGlzdCAqc2c7CisJc3RydWN0IHBhZ2UgKnBhZ2U7CisJc3RydWN0IGJp
byAqYmlvID0gTlVMTCwgKmJpb19maXJzdCA9IE5VTEwsICpiaW9fbGFzdCA9IE5VTEw7CisJaW50
IGVycjsKKworCWZvcl9lYWNoX3NnIChwZW5kaW5nX3JlcS0+c2dsLCBzZywgbnNlZ3MsIGkpIHsK
KwkJcGFnZSA9IHNnX3BhZ2Uoc2cpOworCQlvZmYgPSBzZy0+b2Zmc2V0OworCQlsZW4gPSBzZy0+
bGVuZ3RoOworCisJCW5yX3BhZ2VzID0gKGxlbiArIG9mZiArIFBBR0VfU0laRSAtIDEpID4+IFBB
R0VfU0hJRlQ7CisJCXdoaWxlIChsZW4gPiAwKSB7CisJCQlieXRlcyA9IG1pbl90KHVuc2lnbmVk
IGludCwgbGVuLCBQQUdFX1NJWkUgLSBvZmYpOworCisJCQlpZiAoIWJpbykgeworCQkJCW5yX3Zl
Y3MgPSBtaW5fdCh1bnNpZ25lZCBpbnQsIEJJT19NQVhfUEFHRVMsCisJCQkJCSAJbnJfcGFnZXMp
OworCQkJCW5yX3BhZ2VzIC09IG5yX3ZlY3M7CisJCQkJYmlvID0gYmlvX2FsbG9jKEdGUF9LRVJO
RUwsIG5yX3ZlY3MpOworCQkJCWlmICghYmlvKSB7CisJCQkJCWVyciA9IC1FTk9NRU07CisJCQkJ
CWdvdG8gZnJlZV9iaW9zOworCQkJCX0KKwkJCQliaW8tPmJpX2VuZF9pbyA9IHNjc2liYWNrX2Jp
X2VuZGlvOworCQkJCWlmIChiaW9fbGFzdCkKKwkJCQkJYmlvX2xhc3QtPmJpX25leHQgPSBiaW87
CisJCQkJZWxzZQorCQkJCQliaW9fZmlyc3QgPSBiaW87CisJCQkJYmlvX2xhc3QgPSBiaW87CisJ
CQl9CisKKwkJCWlmIChiaW9fYWRkX3BjX3BhZ2UocSwgYmlvLCBwYWdlLCBieXRlcywgb2ZmKSAh
PQorCQkJCQkJYnl0ZXMpIHsKKwkJCQliaW9fcHV0KGJpbyk7CisJCQkJZXJyID0gLUVJTlZBTDsK
KwkJCQlnb3RvIGZyZWVfYmlvczsKKwkJCX0KKworCQkJaWYgKGJpby0+YmlfdmNudCA+PSBucl92
ZWNzKSB7CisJCQkJYmlvLT5iaV9mbGFncyAmPSB+KDEgPDwgQklPX1NFR19WQUxJRCk7CisJCQkJ
aWYgKHBlbmRpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiA9PSBXUklURSkKKwkJCQkJYmlvLT5i
aV9ydyB8PSBSRVFfV1JJVEU7CisJCQkJYmlvID0gTlVMTDsKKwkJCX0KKworCQkJcGFnZSsrOwor
CQkJbGVuIC09IGJ5dGVzOworCQkJb2ZmID0gMDsKKwkJfQorCX0KKworCXJldHVybiBiaW9fZmly
c3Q7CisKK2ZyZWVfYmlvczoKKwl3aGlsZSAoKGJpbyA9IGJpb19maXJzdCkgIT0gTlVMTCkgewor
CQliaW9fZmlyc3QgPSBiaW8tPmJpX25leHQ7CisJCWJpb19wdXQoYmlvKTsKKwl9CisKKwlyZXR1
cm4gRVJSX1BUUihlcnIpOworfQorCisKK3ZvaWQgc2NzaWJhY2tfY21kX2V4ZWMocGVuZGluZ19y
ZXFfdCAqcGVuZGluZ19yZXEpCit7CisJaW50IGNtZF9sZW4gID0gKGludClwZW5kaW5nX3JlcS0+
Y21kX2xlbjsKKwlpbnQgZGF0YV9kaXIgPSAoaW50KXBlbmRpbmdfcmVxLT5zY19kYXRhX2RpcmVj
dGlvbjsKKwl1bnNpZ25lZCBpbnQgdGltZW91dDsKKwlzdHJ1Y3QgcmVxdWVzdCAqcnE7CisJaW50
IHdyaXRlOworCisJRFBSSU5USygiJXNcbiIsX19GVU5DVElPTl9fKTsKKworCS8qIGJlY2F1c2Ug
aXQgZG9lc24ndCB0aW1lb3V0IGJhY2tlbmQgZWFybGllciB0aGFuIGZyb250ZW5kLiovCisJaWYg
KHBlbmRpbmdfcmVxLT50aW1lb3V0X3Blcl9jb21tYW5kKQorCQl0aW1lb3V0ID0gcGVuZGluZ19y
ZXEtPnRpbWVvdXRfcGVyX2NvbW1hbmQgKiBIWjsKKwllbHNlCisJCXRpbWVvdXQgPSBWU0NTSUlG
X1RJTUVPVVQ7CisKKwl3cml0ZSA9IChkYXRhX2RpciA9PSBETUFfVE9fREVWSUNFKTsKKwlpZiAo
cGVuZGluZ19yZXEtPm5yX3NlZ21lbnRzKSB7CisJCXN0cnVjdCBiaW8gKmJpbyA9IHJlcXVlc3Rf
bWFwX3NnKHBlbmRpbmdfcmVxKTsKKworCQlpZiAoSVNfRVJSKGJpbykpIHsKKwkJCXByaW50ayhL
RVJOX0VSUiAic2NzaWJhY2s6IFNHIFJlcXVlc3QgTWFwIEVycm9yXG4iKTsKKwkJCXJldHVybjsK
KwkJfQorCisJCXJxID0gYmxrX21ha2VfcmVxdWVzdChwZW5kaW5nX3JlcS0+c2Rldi0+cmVxdWVz
dF9xdWV1ZSwgYmlvLAorCQkJCSAgICAgIEdGUF9LRVJORUwpOworCQlpZiAoSVNfRVJSKHJxKSkg
eworCQkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogTWFrZSBSZXF1ZXN0IEVycm9yXG4iKTsK
KwkJCXJldHVybjsKKwkJfQorCisJCXJxLT5idWZmZXIgPSBOVUxMOworCX0gZWxzZSB7CisJCXJx
ID0gYmxrX2dldF9yZXF1ZXN0KHBlbmRpbmdfcmVxLT5zZGV2LT5yZXF1ZXN0X3F1ZXVlLCB3cml0
ZSwKKwkJCQkgICAgIEdGUF9LRVJORUwpOworCQlpZiAodW5saWtlbHkoIXJxKSkgeworCQkJcHJp
bnRrKEtFUk5fRVJSICJzY3NpYmFjazogR2V0IFJlcXVlc3QgRXJyb3JcbiIpOworCQkJcmV0dXJu
OworCQl9CisJfQorCisJcnEtPmNtZF90eXBlID0gUkVRX1RZUEVfQkxPQ0tfUEM7CisJcnEtPmNt
ZF9sZW4gPSBjbWRfbGVuOworCW1lbWNweShycS0+Y21kLCBwZW5kaW5nX3JlcS0+Y21uZCwgY21k
X2xlbik7CisKKwltZW1zZXQocGVuZGluZ19yZXEtPnNlbnNlX2J1ZmZlciwgMCwgVlNDU0lJRl9T
RU5TRV9CVUZGRVJTSVpFKTsKKwlycS0+c2Vuc2UgICAgICAgPSBwZW5kaW5nX3JlcS0+c2Vuc2Vf
YnVmZmVyOworCXJxLT5zZW5zZV9sZW4gPSAwOworCisJLyogbm90IGFsbG93ZWQgdG8gcmV0cnkg
aW4gYmFja2VuZC4gICAgICAgICAgICAgICAgICAgKi8KKwlycS0+cmV0cmllcyAgID0gMDsKKwly
cS0+dGltZW91dCAgID0gdGltZW91dDsKKwlycS0+ZW5kX2lvX2RhdGEgPSBwZW5kaW5nX3JlcTsK
KworCXNjc2liYWNrX2dldChwZW5kaW5nX3JlcS0+aW5mbyk7CisJYmxrX2V4ZWN1dGVfcnFfbm93
YWl0KHJxLT5xLCBOVUxMLCBycSwgMSwgc2NzaWJhY2tfY21kX2RvbmUpOworCisJcmV0dXJuIDsK
K30KKworCitzdGF0aWMgdm9pZCBzY3NpYmFja19kZXZpY2VfcmVzZXRfZXhlYyhwZW5kaW5nX3Jl
cV90ICpwZW5kaW5nX3JlcSkKK3sKKwlzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvID0gcGVuZGlu
Z19yZXEtPmluZm87CisJaW50IGVycjsKKwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXYgPSBwZW5k
aW5nX3JlcS0+c2RldjsKKworCXNjc2liYWNrX2dldChpbmZvKTsKKwllcnIgPSBzY3NpX3Jlc2V0
X3Byb3ZpZGVyKHNkZXYsIFNDU0lfVFJZX1JFU0VUX0RFVklDRSk7CisKKwlzY3NpYmFja19kb19y
ZXNwX3dpdGhfc2Vuc2UoTlVMTCwgZXJyLCAwLCBwZW5kaW5nX3JlcSk7CisJc2NzaWJhY2tfcHV0
KGluZm8pOworCisJcmV0dXJuOworfQorCisKK2lycXJldHVybl90IHNjc2liYWNrX2ludHIoaW50
IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjc2liYWNrX25vdGlmeV93b3JrKChzdHJ1Y3QgdnNj
c2lia19pbmZvICopZGV2X2lkKTsKKwlyZXR1cm4gSVJRX0hBTkRMRUQ7Cit9CisKK3N0YXRpYyBp
bnQgcHJlcGFyZV9wZW5kaW5nX3JlcXMoc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5mbywKKwkJdnNj
c2lpZl9yZXF1ZXN0X3QgKnJpbmdfcmVxLCBwZW5kaW5nX3JlcV90ICpwZW5kaW5nX3JlcSkKK3sK
KwlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXY7CisJc3RydWN0IGlkc190dXBsZSB2aXI7CisJaW50
IGVyciA9IC1FSU5WQUw7CisKKwlEUFJJTlRLKCIlc1xuIixfX0ZVTkNUSU9OX18pOworCisJcGVu
ZGluZ19yZXEtPnJxaWQgICAgICAgPSByaW5nX3JlcS0+cnFpZDsKKwlwZW5kaW5nX3JlcS0+YWN0
ICAgICAgICA9IHJpbmdfcmVxLT5hY3Q7CisKKwlwZW5kaW5nX3JlcS0+aW5mbyAgICAgICA9IGlu
Zm87CisKKwlwZW5kaW5nX3JlcS0+dl9jaG4gPSB2aXIuY2huID0gcmluZ19yZXEtPmNoYW5uZWw7
CisJcGVuZGluZ19yZXEtPnZfdGd0ID0gdmlyLnRndCA9IHJpbmdfcmVxLT5pZDsKKwl2aXIubHVu
ID0gcmluZ19yZXEtPmx1bjsKKworCXJtYigpOworCXNkZXYgPSBzY3NpYmFja19kb190cmFuc2xh
dGlvbihpbmZvLCAmdmlyKTsKKwlpZiAoIXNkZXYpIHsKKwkJcGVuZGluZ19yZXEtPnNkZXYgPSBO
VUxMOworCQlEUFJJTlRLKCJzY3NpYmFjazogZG9lc24ndCBleGlzdC5cbiIpOworCQllcnIgPSAt
RU5PREVWOworCQlnb3RvIGludmFsaWRfdmFsdWU7CisJfQorCXBlbmRpbmdfcmVxLT5zZGV2ID0g
c2RldjsKKworCS8qIHJlcXVlc3QgcmFuZ2UgY2hlY2sgZnJvbSBmcm9udGVuZCAqLworCXBlbmRp
bmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiA9IHJpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbjsK
KwliYXJyaWVyKCk7CisJaWYgKChwZW5kaW5nX3JlcS0+c2NfZGF0YV9kaXJlY3Rpb24gIT0gRE1B
X0JJRElSRUNUSU9OQUwpICYmCisJCShwZW5kaW5nX3JlcS0+c2NfZGF0YV9kaXJlY3Rpb24gIT0g
RE1BX1RPX0RFVklDRSkgJiYKKwkJKHBlbmRpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiAhPSBE
TUFfRlJPTV9ERVZJQ0UpICYmCisJCShwZW5kaW5nX3JlcS0+c2NfZGF0YV9kaXJlY3Rpb24gIT0g
RE1BX05PTkUpKSB7CisJCURQUklOVEsoInNjc2liYWNrOiBpbnZhbGlkIHBhcmFtZXRlciBkYXRh
X2RpciA9ICVkXG4iLAorCQkJcGVuZGluZ19yZXEtPnNjX2RhdGFfZGlyZWN0aW9uKTsKKwkJZXJy
ID0gLUVJTlZBTDsKKwkJZ290byBpbnZhbGlkX3ZhbHVlOworCX0KKworCXBlbmRpbmdfcmVxLT5u
cl9zZWdtZW50cyA9IHJpbmdfcmVxLT5ucl9zZWdtZW50czsKKwliYXJyaWVyKCk7CisJaWYgKHBl
bmRpbmdfcmVxLT5ucl9zZWdtZW50cyA+IFZTQ1NJSUZfU0dfVEFCTEVTSVpFKSB7CisJCURQUklO
VEsoInNjc2liYWNrOiBpbnZhbGlkIHBhcmFtZXRlciBucl9zZWcgPSAlZFxuIiwKKwkJCXBlbmRp
bmdfcmVxLT5ucl9zZWdtZW50cyk7CisJCWVyciA9IC1FSU5WQUw7CisJCWdvdG8gaW52YWxpZF92
YWx1ZTsKKwl9CisKKwlwZW5kaW5nX3JlcS0+Y21kX2xlbiA9IHJpbmdfcmVxLT5jbWRfbGVuOwor
CWJhcnJpZXIoKTsKKwlpZiAocGVuZGluZ19yZXEtPmNtZF9sZW4gPiBWU0NTSUlGX01BWF9DT01N
QU5EX1NJWkUpIHsKKwkJRFBSSU5USygic2NzaWJhY2s6IGludmFsaWQgcGFyYW1ldGVyIGNtZF9s
ZW4gPSAlZFxuIiwKKwkJCXBlbmRpbmdfcmVxLT5jbWRfbGVuKTsKKwkJZXJyID0gLUVJTlZBTDsK
KwkJZ290byBpbnZhbGlkX3ZhbHVlOworCX0KKwltZW1jcHkocGVuZGluZ19yZXEtPmNtbmQsIHJp
bmdfcmVxLT5jbW5kLCBwZW5kaW5nX3JlcS0+Y21kX2xlbik7CisKKwlwZW5kaW5nX3JlcS0+dGlt
ZW91dF9wZXJfY29tbWFuZCA9IHJpbmdfcmVxLT50aW1lb3V0X3Blcl9jb21tYW5kOworCisJaWYo
c2NzaWJhY2tfZ250dGFiX2RhdGFfbWFwKHJpbmdfcmVxLCBwZW5kaW5nX3JlcSkpIHsKKwkJRFBS
SU5USygic2NzaWJhY2s6IGludmFsaWQgYnVmZmVyXG4iKTsKKwkJZXJyID0gLUVJTlZBTDsKKwkJ
Z290byBpbnZhbGlkX3ZhbHVlOworCX0KKworCXJldHVybiAwOworCitpbnZhbGlkX3ZhbHVlOgor
CXJldHVybiBlcnI7Cit9CisKKworc3RhdGljIGludCBzY3NpYmFja19kb19jbWRfZm4oc3RydWN0
IHZzY3NpYmtfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgdnNjc2lpZl9iYWNrX3JpbmcgKnJpbmcg
PSAmaW5mby0+cmluZzsKKwl2c2NzaWlmX3JlcXVlc3RfdCAgKnJpbmdfcmVxOworCisJcGVuZGlu
Z19yZXFfdCAqcGVuZGluZ19yZXE7CisJUklOR19JRFggcmMsIHJwOworCWludCBlcnIsIG1vcmVf
dG9fZG8gPSAwOworCisJRFBSSU5USygiJXNcbiIsX19GVU5DVElPTl9fKTsKKworCXJjID0gcmlu
Zy0+cmVxX2NvbnM7CisJcnAgPSByaW5nLT5zcmluZy0+cmVxX3Byb2Q7CisJcm1iKCk7CisKKwl3
aGlsZSAoKHJjICE9IHJwKSkgeworCQlpZiAoUklOR19SRVFVRVNUX0NPTlNfT1ZFUkZMT1cocmlu
ZywgcmMpKQorCQkJYnJlYWs7CisJCXBlbmRpbmdfcmVxID0gYWxsb2NfcmVxKGluZm8pOworCQlp
ZiAoTlVMTCA9PSBwZW5kaW5nX3JlcSkgeworCQkJbW9yZV90b19kbyA9IDE7CisJCQlicmVhazsK
KwkJfQorCisJCXJpbmdfcmVxID0gUklOR19HRVRfUkVRVUVTVChyaW5nLCByYyk7CisJCXJpbmct
PnJlcV9jb25zID0gKytyYzsKKworCQllcnIgPSBwcmVwYXJlX3BlbmRpbmdfcmVxcyhpbmZvLCBy
aW5nX3JlcSwKKwkJCQkJCXBlbmRpbmdfcmVxKTsKKwkJaWYgKGVyciA9PSAtRUlOVkFMKSB7CisJ
CQlzY3NpYmFja19kb19yZXNwX3dpdGhfc2Vuc2UoTlVMTCwgKERSSVZFUl9FUlJPUiA8PCAyNCks
CisJCQkJMCwgcGVuZGluZ19yZXEpOworCQkJY29udGludWU7CisJCX0gZWxzZSBpZiAoZXJyID09
IC1FTk9ERVYpIHsKKwkJCXNjc2liYWNrX2RvX3Jlc3Bfd2l0aF9zZW5zZShOVUxMLCAoRElEX05P
X0NPTk5FQ1QgPDwgMTYpLAorCQkJCTAsIHBlbmRpbmdfcmVxKTsKKwkJCWNvbnRpbnVlOworCQl9
CisKKwkJaWYgKHBlbmRpbmdfcmVxLT5hY3QgPT0gVlNDU0lJRl9BQ1RfU0NTSV9DREIpIHsKKwor
CQkJLyogVGhlIEhvc3QgbW9kZSBpcyB0aHJvdWdoIGFzIGZvciBFbXVsYXRpb24uICovCisJCQlp
ZiAoaW5mby0+ZmVhdHVyZSA9PSBWU0NTSV9UWVBFX0hPU1QpCisJCQkJc2NzaWJhY2tfY21kX2V4
ZWMocGVuZGluZ19yZXEpOworCQkJZWxzZQorCQkJCXNjc2liYWNrX3JlcV9lbXVsYXRpb25fb3Jf
Y21kZXhlYyhwZW5kaW5nX3JlcSk7CisKKwkJfSBlbHNlIGlmIChwZW5kaW5nX3JlcS0+YWN0ID09
IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQpIHsKKwkJCXNjc2liYWNrX2RldmljZV9yZXNldF9leGVj
KHBlbmRpbmdfcmVxKTsKKwkJfSBlbHNlIHsKKwkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6
IGludmFsaWQgcGFyYW1ldGVyIGZvciByZXF1ZXN0XG4iKTsKKwkJCXNjc2liYWNrX2RvX3Jlc3Bf
d2l0aF9zZW5zZShOVUxMLCAoRFJJVkVSX0VSUk9SIDw8IDI0KSwKKwkJCQkwLCBwZW5kaW5nX3Jl
cSk7CisJCQljb250aW51ZTsKKwkJfQorCX0KKworCWlmIChSSU5HX0hBU19VTkNPTlNVTUVEX1JF
UVVFU1RTKHJpbmcpKQorCQltb3JlX3RvX2RvID0gMTsKKworCS8qIFlpZWxkIHBvaW50IGZvciB0
aGlzIHVuYm91bmRlZCBsb29wLiAqLworCWNvbmRfcmVzY2hlZCgpOworCisJcmV0dXJuIG1vcmVf
dG9fZG87Cit9CisKKworaW50IHNjc2liYWNrX3NjaGVkdWxlKHZvaWQgKmRhdGEpCit7CisJc3Ry
dWN0IHZzY3NpYmtfaW5mbyAqaW5mbyA9IChzdHJ1Y3QgdnNjc2lia19pbmZvICopZGF0YTsKKwor
CURQUklOVEsoIiVzXG4iLF9fRlVOQ1RJT05fXyk7CisKKwl3aGlsZSAoIWt0aHJlYWRfc2hvdWxk
X3N0b3AoKSkgeworCQl3YWl0X2V2ZW50X2ludGVycnVwdGlibGUoCisJCQlpbmZvLT53cSwKKwkJ
CWluZm8tPndhaXRpbmdfcmVxcyB8fCBrdGhyZWFkX3Nob3VsZF9zdG9wKCkpOworCQl3YWl0X2V2
ZW50X2ludGVycnVwdGlibGUoCisJCQlwZW5kaW5nX2ZyZWVfd3EsCisJCQkhbGlzdF9lbXB0eSgm
cGVuZGluZ19mcmVlKSB8fCBrdGhyZWFkX3Nob3VsZF9zdG9wKCkpOworCisJCWluZm8tPndhaXRp
bmdfcmVxcyA9IDA7CisJCXNtcF9tYigpOworCisJCWlmIChzY3NpYmFja19kb19jbWRfZm4oaW5m
bykpCisJCQlpbmZvLT53YWl0aW5nX3JlcXMgPSAxOworCX0KKworCXJldHVybiAwOworfQorCisK
K3N0YXRpYyBpbnQgX19pbml0IHNjc2liYWNrX2luaXQodm9pZCkKK3sKKwlpbnQgaSwgbW1hcF9w
YWdlczsKKworCWlmICgheGVuX2RvbWFpbigpKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCW1tYXBf
cGFnZXMgPSB2c2NzaWlmX3JlcXMgKiBWU0NTSUlGX1NHX1RBQkxFU0laRTsKKworCXBlbmRpbmdf
cmVxcyAgICAgICAgICA9IGt6YWxsb2Moc2l6ZW9mKHBlbmRpbmdfcmVxc1swXSkgKgorCQkJCQl2
c2NzaWlmX3JlcXMsIEdGUF9LRVJORUwpOworCXBlbmRpbmdfZ3JhbnRfaGFuZGxlcyA9IGttYWxs
b2Moc2l6ZW9mKHBlbmRpbmdfZ3JhbnRfaGFuZGxlc1swXSkgKgorCQkJCQltbWFwX3BhZ2VzLCBH
RlBfS0VSTkVMKTsKKwlwZW5kaW5nX3BhZ2VzICAgICAgICAgPSBremFsbG9jKHNpemVvZihwZW5k
aW5nX3BhZ2VzWzBdKSAqCisJCQkJCW1tYXBfcGFnZXMsIEdGUF9LRVJORUwpOworCisJaWYgKCFw
ZW5kaW5nX3JlcXMgfHwgIXBlbmRpbmdfZ3JhbnRfaGFuZGxlcyB8fCAhcGVuZGluZ19wYWdlcykK
KwkJZ290byBvdXRfb2ZfbWVtb3J5OworCisJZm9yIChpID0gMDsgaSA8IG1tYXBfcGFnZXM7IGkr
KykgeworCQlwZW5kaW5nX2dyYW50X2hhbmRsZXNbaV0gPSBTQ1NJQkFDS19JTlZBTElEX0hBTkRM
RTsKKwkJcGVuZGluZ19wYWdlc1tpXSA9IGFsbG9jX3BhZ2UoR0ZQX0tFUk5FTCk7CisJCWlmIChw
ZW5kaW5nX3BhZ2VzW2ldID09IE5VTEwpCisJCQlnb3RvIG91dF9vZl9tZW1vcnk7CisJfQorCWlm
IChzY3NpYmFja19pbnRlcmZhY2VfaW5pdCgpIDwgMCkKKwkJZ290byBvdXRfb2Zfa21lbTsKKwor
CW1lbXNldChwZW5kaW5nX3JlcXMsIDAsIHNpemVvZihwZW5kaW5nX3JlcXMpKTsKKwlJTklUX0xJ
U1RfSEVBRCgmcGVuZGluZ19mcmVlKTsKKworCWZvciAoaSA9IDA7IGkgPCB2c2NzaWlmX3JlcXM7
IGkrKykKKwkJbGlzdF9hZGRfdGFpbCgmcGVuZGluZ19yZXFzW2ldLmZyZWVfbGlzdCwgJnBlbmRp
bmdfZnJlZSk7CisKKwlpZiAoc2NzaWJhY2tfeGVuYnVzX2luaXQoKSkKKwkJZ290byBvdXRfb2Zf
eGVuYnVzOworCisJc2NzaWJhY2tfZW11bGF0aW9uX2luaXQoKTsKKworCXJldHVybiAwOworCitv
dXRfb2ZfeGVuYnVzOgorCXNjc2liYWNrX3hlbmJ1c191bnJlZ2lzdGVyKCk7CitvdXRfb2Zfa21l
bToKKwlzY3NpYmFja19pbnRlcmZhY2VfZXhpdCgpOworb3V0X29mX21lbW9yeToKKwlpZiAocGVu
ZGluZ19wYWdlcykgeworCQlmb3IgKGkgPSAwOyBpIDwgbW1hcF9wYWdlczsgaSsrKSB7CisJCQlp
ZiAocGVuZGluZ19wYWdlc1tpXSkKKwkJCQlfX2ZyZWVfcGFnZShwZW5kaW5nX3BhZ2VzW2ldKTsK
KwkJfQorCQlrZnJlZShwZW5kaW5nX3BhZ2VzKTsKKwl9CisJa2ZyZWUocGVuZGluZ19yZXFzKTsK
KwlrZnJlZShwZW5kaW5nX2dyYW50X2hhbmRsZXMpOworCXByaW50ayhLRVJOX0VSUiAic2NzaWJh
Y2s6ICVzOiBvdXQgb2YgbWVtb3J5XG4iLCBfX0ZVTkNUSU9OX18pOworCXJldHVybiAtRU5PTUVN
OworfQorCisKK3N0YXRpYyB2b2lkIF9fZXhpdCBzY3NpYmFja19leGl0KHZvaWQpCit7CisJc2Nz
aWJhY2tfeGVuYnVzX3VucmVnaXN0ZXIoKTsKKwlzY3NpYmFja19pbnRlcmZhY2VfZXhpdCgpOwor
CWtmcmVlKHBlbmRpbmdfcmVxcyk7CisJa2ZyZWUocGVuZGluZ19ncmFudF9oYW5kbGVzKTsKKwlp
ZiAocGVuZGluZ19wYWdlcykgeworCQl1bnNpZ25lZCBpbnQgaTsKKwkJdW5zaWduZWQgaW50IG1t
YXBfcGFnZXMgPSB2c2NzaWlmX3JlcXMgKiBWU0NTSUlGX1NHX1RBQkxFU0laRTsKKwkJZm9yIChp
ID0gMDsgaSA8IG1tYXBfcGFnZXM7IGkrKykgeworCQkJaWYgKHBlbmRpbmdfcGFnZXNbaV0pCisJ
CQkJX19mcmVlX3BhZ2UocGVuZGluZ19wYWdlc1tpXSk7CisJCX0KKwkJa2ZyZWUocGVuZGluZ19w
YWdlcyk7CisJfQorfQorCittb2R1bGVfaW5pdChzY3NpYmFja19pbml0KTsKK21vZHVsZV9leGl0
KHNjc2liYWNrX2V4aXQpOworCitNT0RVTEVfREVTQ1JJUFRJT04oIlhlbiBTQ1NJIGJhY2tlbmQg
ZHJpdmVyIik7CitNT0RVTEVfTElDRU5TRSgiRHVhbCBCU0QvR1BMIik7CmRpZmYgLXJ1cE4geGVu
L2RyaXZlcnMvc2NzaS94ZW4tc2NzaWJhY2svdHJhbnNsYXRlLmMgeGVuYy9kcml2ZXJzL3Njc2kv
eGVuLXNjc2liYWNrL3RyYW5zbGF0ZS5jCi0tLSB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFj
ay90cmFuc2xhdGUuYwkxOTY5LTEyLTMxIDE3OjAwOjAwLjAwMDAwMDAwMCAtMDcwMAorKysgeGVu
Yy9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3RyYW5zbGF0ZS5jCTIwMTItMDItMjQgMTQ6NTY6
MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsMTY4IEBACisvKgorICogWGVuIFNDU0kgYmFj
a2VuZCBkcml2ZXIKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZVSklUU1UgTGltaXRlZAor
ICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0
ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisgKiBzZXBhcmF0ZWx5
IGZyb20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBvdGhlcgorICogc29m
dHdhcmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNlbnNlOgorICoKKyAq
IFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0byBhbnkgcGVy
c29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUgKHRoZSAiU29mdHdh
cmUiKSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVzdHJpY3Rpb24sIGlu
Y2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2UsIGNvcHksIG1vZGlm
eSwKKyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNlLCBhbmQvb3Igc2Vs
bCBjb3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdo
b20gdGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVjdCB0bworICogdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNl
IGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwg
Y29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBU
SEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkg
S0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBU
TyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBB
UlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBU
SEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xB
SU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04g
T0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0Yg
T1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERF
QUxJTkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2xpc3Qu
aD4KKyNpbmNsdWRlIDxsaW51eC9nZnAuaD4KKworI2luY2x1ZGUgImNvbW1vbi5oIgorCisvKgor
ICBJbml0aWFsaXplIHRoZSB0cmFuc2xhdGlvbiBlbnRyeSBsaXN0CisqLwordm9pZCBzY3NpYmFj
a19pbml0X3RyYW5zbGF0aW9uX3RhYmxlKHN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm8pCit7CisJ
SU5JVF9MSVNUX0hFQUQoJmluZm8tPnYycF9lbnRyeV9saXN0cyk7CisJc3Bpbl9sb2NrX2luaXQo
JmluZm8tPnYycF9sb2NrKTsKK30KKworCisvKgorICBBZGQgYSBuZXcgdHJhbnNsYXRpb24gZW50
cnkKKyovCitpbnQgc2NzaWJhY2tfYWRkX3RyYW5zbGF0aW9uX2VudHJ5KHN0cnVjdCB2c2NzaWJr
X2luZm8gKmluZm8sCisJCQlzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNkZXYsIHN0cnVjdCBpZHNfdHVw
bGUgKnYpCit7CisJaW50IGVyciA9IDA7CisJc3RydWN0IHYycF9lbnRyeSAqZW50cnk7CisJc3Ry
dWN0IHYycF9lbnRyeSAqbmV3OworCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmKGluZm8tPnYy
cF9lbnRyeV9saXN0cyk7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19pcnFz
YXZlKCZpbmZvLT52MnBfbG9jaywgZmxhZ3MpOworCisJLyogQ2hlY2sgZG91YmxlIGFzc2lnbm1l
bnQgdG8gaWRlbnRpY2FsIHZpcnR1YWwgSUQgKi8KKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KGVudHJ5
LCBoZWFkLCBsKSB7CisJCWlmICgoZW50cnktPnYuY2huID09IHYtPmNobikgJiYKKwkJICAgIChl
bnRyeS0+di50Z3QgPT0gdi0+dGd0KSAmJgorCQkgICAgKGVudHJ5LT52Lmx1biA9PSB2LT5sdW4p
KSB7CisJCQlwcmludGsoS0VSTl9XQVJOSU5HICJzY3NpYmFjazogVmlydHVhbCBJRCBpcyBhbHJl
YWR5IHVzZWQuICIKKwkJCSAgICAgICAiQXNzaWdubWVudCB3YXMgbm90IHBlcmZvcm1lZC5cbiIp
OworCQkJZXJyID0gLUVFWElTVDsKKwkJCWdvdG8gb3V0OworCQl9CisKKwl9CisKKwkvKiBDcmVh
dGUgYSBuZXcgdHJhbnNsYXRpb24gZW50cnkgYW5kIGFkZCB0byB0aGUgbGlzdCAqLworCWlmICgo
bmV3ID0ga21hbGxvYyhzaXplb2Yoc3RydWN0IHYycF9lbnRyeSksIEdGUF9BVE9NSUMpKSA9PSBO
VUxMKSB7CisJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6ICVzOiBrbWFsbG9jKCkgZXJyb3Iu
XG4iLCBfX0ZVTkNUSU9OX18pOworCQllcnIgPSAtRU5PTUVNOworCQlnb3RvIG91dDsKKwl9CisJ
bmV3LT52ID0gKnY7CisJbmV3LT5zZGV2ID0gc2RldjsKKwlsaXN0X2FkZF90YWlsKCZuZXctPmws
IGhlYWQpOworCitvdXQ6CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+djJwX2xvY2ss
IGZsYWdzKTsKKwlyZXR1cm4gZXJyOworfQorCisKKy8qCisgIERlbGV0ZSB0aGUgdHJhbnNsYXRp
b24gZW50cnkgc3BlY2ZpZWQKKyovCitpbnQgc2NzaWJhY2tfZGVsX3RyYW5zbGF0aW9uX2VudHJ5
KHN0cnVjdCB2c2NzaWJrX2luZm8gKmluZm8sCisJCQkJc3RydWN0IGlkc190dXBsZSAqdikKK3sK
KwlzdHJ1Y3QgdjJwX2VudHJ5ICplbnRyeTsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpoZWFkID0gJihp
bmZvLT52MnBfZW50cnlfbGlzdHMpOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisKKwlzcGluX2xv
Y2tfaXJxc2F2ZSgmaW5mby0+djJwX2xvY2ssIGZsYWdzKTsKKwkvKiBGaW5kIG91dCB0aGUgdHJh
bnNsYXRpb24gZW50cnkgc3BlY2lmaWVkICovCisJbGlzdF9mb3JfZWFjaF9lbnRyeShlbnRyeSwg
aGVhZCwgbCkgeworCQlpZiAoKGVudHJ5LT52LmNobiA9PSB2LT5jaG4pICYmCisJCSAgICAoZW50
cnktPnYudGd0ID09IHYtPnRndCkgJiYKKwkJICAgIChlbnRyeS0+di5sdW4gPT0gdi0+bHVuKSkg
eworCQkJZ290byBmb3VuZDsKKwkJfQorCX0KKworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmlu
Zm8tPnYycF9sb2NrLCBmbGFncyk7CisJcmV0dXJuIDE7CisKK2ZvdW5kOgorCS8qIERlbGV0ZSB0
aGUgdHJhbnNsYXRpb24gZW50cnkgc3BlY2ZpZWQgKi8KKwlzY3NpX2RldmljZV9wdXQoZW50cnkt
PnNkZXYpOworCWxpc3RfZGVsKCZlbnRyeS0+bCk7CisJa2ZyZWUoZW50cnkpOworCisJc3Bpbl91
bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+djJwX2xvY2ssIGZsYWdzKTsKKwlyZXR1cm4gMDsKK30K
KworCisvKgorICBQZXJmb3JtIHZpcnR1YWwgdG8gcGh5c2ljYWwgdHJhbnNsYXRpb24KKyovCitz
dHJ1Y3Qgc2NzaV9kZXZpY2UgKnNjc2liYWNrX2RvX3RyYW5zbGF0aW9uKHN0cnVjdCB2c2NzaWJr
X2luZm8gKmluZm8sCisJCQlzdHJ1Y3QgaWRzX3R1cGxlICp2KQoreworCXN0cnVjdCB2MnBfZW50
cnkgKmVudHJ5OworCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmKGluZm8tPnYycF9lbnRyeV9s
aXN0cyk7CisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2ID0gTlVMTDsKKwl1bnNpZ25lZCBsb25n
IGZsYWdzOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmluZm8tPnYycF9sb2NrLCBmbGFncyk7CisJ
bGlzdF9mb3JfZWFjaF9lbnRyeShlbnRyeSwgaGVhZCwgbCkgeworCQlpZiAoKGVudHJ5LT52LmNo
biA9PSB2LT5jaG4pICYmCisJCSAgICAoZW50cnktPnYudGd0ID09IHYtPnRndCkgJiYKKwkJICAg
IChlbnRyeS0+di5sdW4gPT0gdi0+bHVuKSkgeworCQkJc2RldiA9IGVudHJ5LT5zZGV2OworCQkJ
Z290byBvdXQ7CisJCX0KKwl9CitvdXQ6CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+
djJwX2xvY2ssIGZsYWdzKTsKKwlyZXR1cm4gc2RldjsKK30KKworCisvKgorICBSZWxlYXNlIHRo
ZSB0cmFuc2xhdGlvbiBlbnRyeSBzcGVjZmllZAorKi8KK3ZvaWQgc2NzaWJhY2tfcmVsZWFzZV90
cmFuc2xhdGlvbl9lbnRyeShzdHJ1Y3QgdnNjc2lia19pbmZvICppbmZvKQoreworCXN0cnVjdCB2
MnBfZW50cnkgKmVudHJ5LCAqdG1wOworCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmKGluZm8t
PnYycF9lbnRyeV9saXN0cyk7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19p
cnFzYXZlKCZpbmZvLT52MnBfbG9jaywgZmxhZ3MpOworCWxpc3RfZm9yX2VhY2hfZW50cnlfc2Fm
ZShlbnRyeSwgdG1wLCBoZWFkLCBsKSB7CisJCXNjc2lfZGV2aWNlX3B1dChlbnRyeS0+c2Rldik7
CisJCWxpc3RfZGVsKCZlbnRyeS0+bCk7CisJCWtmcmVlKGVudHJ5KTsKKwl9CisKKwlzcGluX3Vu
bG9ja19pcnFyZXN0b3JlKCZpbmZvLT52MnBfbG9jaywgZmxhZ3MpOworCXJldHVybjsKKworfQpk
aWZmIC1ydXBOIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2liYWNrL3hlbmJ1cy5jIHhlbmMvZHJp
dmVycy9zY3NpL3hlbi1zY3NpYmFjay94ZW5idXMuYwotLS0geGVuL2RyaXZlcnMvc2NzaS94ZW4t
c2NzaWJhY2sveGVuYnVzLmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3MDAKKysr
IHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpYmFjay94ZW5idXMuYwkyMDEyLTAyLTI0IDE0OjU2
OjEzLjUzODk3ODMwMCAtMDcwMApAQCAtMCwwICsxLDM3MSBAQAorLyoKKyAqIFhlbiBTQ1NJIGJh
Y2tlbmQgZHJpdmVyCisgKgorICogQ29weXJpZ2h0IChjKSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQK
KyAqCisgKiBCYXNlZCBvbiB0aGUgYmxrYmFjayBkcml2ZXIgY29kZS4KKyAqCisgKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisg
KiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSB2ZXJzaW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uOyBvciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51
eCBrZXJuZWwgb3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2Vz
LCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlz
IGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcg
YSBjb3B5CisgKiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwg
aW4gdGhlIFNvZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91
dCBsaW1pdGF0aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwg
cHVibGlzaCwgZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRo
ZSBTb2Z0d2FyZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2Fy
ZSBpcyBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29u
ZGl0aW9uczoKKyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJt
aXNzaW9uIG5vdGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJz
dGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElT
IFBST1ZJREVEICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1Mg
T1IKKyAqIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UgQU5EIE5PTklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JT
IE9SIENPUFlSSUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9S
IE9USEVSCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBU
T1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJ
T04gV0lUSCBUSEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4g
VEhFIFNPRlRXQVJFLgorICovCisKKyNpbmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxsaW51
eC9tb2R1bGUuaD4KKyNpbmNsdWRlIDxsaW51eC9rdGhyZWFkLmg+CisjaW5jbHVkZSA8c2NzaS9z
Y3NpLmg+CisjaW5jbHVkZSA8c2NzaS9zY3NpX2hvc3QuaD4KKyNpbmNsdWRlIDxzY3NpL3Njc2lf
ZGV2aWNlLmg+CisKKyNpbmNsdWRlICJjb21tb24uaCIKKworc3RydWN0IGJhY2tlbmRfaW5mbwor
eworCXN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXY7CisJc3RydWN0IHZzY3NpYmtfaW5mbyAqaW5m
bzsKK307CisKKworc3RhdGljIGludCBfX3ZzY3NpaWZfbmFtZShzdHJ1Y3QgYmFja2VuZF9pbmZv
ICpiZSwgY2hhciAqYnVmKQoreworCXN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYgPSBiZS0+ZGV2
OworCXVuc2lnbmVkIGludCBkb21pZCwgaWQ7CisKKwlzc2NhbmYoZGV2LT5ub2RlbmFtZSwgImJh
Y2tlbmQvdnNjc2kvJXUvJXUiLCAmZG9taWQsICZpZCk7CisJc25wcmludGYoYnVmLCBUQVNLX0NP
TU1fTEVOLCAidnNjc2kuJXUuJXUiLCBiZS0+aW5mby0+ZG9taWQsIGlkKTsKKworCXJldHVybiAw
OworfQorCitzdGF0aWMgaW50IHNjc2liYWNrX21hcChzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSkK
K3sKKwlzdHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2ID0gYmUtPmRldjsKKwl1bnNpZ25lZCBsb25n
IHJpbmdfcmVmID0gMDsKKwl1bnNpZ25lZCBpbnQgZXZ0Y2huID0gMDsKKwlpbnQgZXJyOworCWNo
YXIgbmFtZVtUQVNLX0NPTU1fTEVOXTsKKworCWVyciA9IHhlbmJ1c19nYXRoZXIoWEJUX05JTCwg
ZGV2LT5vdGhlcmVuZCwKKwkJCSJyaW5nLXJlZiIsICIlbHUiLCAmcmluZ19yZWYsCisJCQkiZXZl
bnQtY2hhbm5lbCIsICIldSIsICZldnRjaG4sIE5VTEwpOworCWlmIChlcnIpIHsKKwkJeGVuYnVz
X2Rldl9mYXRhbChkZXYsIGVyciwgInJlYWRpbmcgJXMgcmluZyIsIGRldi0+b3RoZXJlbmQpOwor
CQlyZXR1cm4gZXJyOworCX0KKwllcnIgPSBzY3NpYmFja19pbml0X3NyaW5nKGJlLT5pbmZvLCBy
aW5nX3JlZiwgZXZ0Y2huKTsKKwlpZiAoZXJyKQorCQlyZXR1cm4gZXJyOworCisJZXJyID0gX192
c2NzaWlmX25hbWUoYmUsIG5hbWUpOworCWlmIChlcnIpIHsKKwkJeGVuYnVzX2Rldl9lcnJvcihk
ZXYsIGVyciwgImdldCBzY3NpYmFjayBkZXYgbmFtZSIpOworCQlyZXR1cm4gZXJyOworCX0KKwor
CWJlLT5pbmZvLT5rdGhyZWFkID0ga3RocmVhZF9ydW4oc2NzaWJhY2tfc2NoZWR1bGUsIGJlLT5p
bmZvLCBuYW1lKTsKKwlpZiAoSVNfRVJSKGJlLT5pbmZvLT5rdGhyZWFkKSkgeworCQllcnIgPSBQ
VFJfRVJSKGJlLT5pbmZvLT5rdGhyZWFkKTsKKwkJYmUtPmluZm8tPmt0aHJlYWQgPSBOVUxMOwor
CQl4ZW5idXNfZGV2X2Vycm9yKGJlLT5kZXYsIGVyciwgInN0YXJ0IHZzY3NpaWYiKTsKKwkJcmV0
dXJuIGVycjsKKwl9CisKKwlyZXR1cm4gMDsKK30KKworCitzdHJ1Y3Qgc2NzaV9kZXZpY2UgKnNj
c2liYWNrX2dldF9zY3NpX2RldmljZShzdHJ1Y3QgaWRzX3R1cGxlICpwaHkpCit7CisJc3RydWN0
IFNjc2lfSG9zdCAqc2hvc3Q7CisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2ID0gTlVMTDsKKwor
CXNob3N0ID0gc2NzaV9ob3N0X2xvb2t1cChwaHktPmhzdCk7CisJaWYgKElTX0VSUihzaG9zdCkp
IHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogaG9zdCVkIGRvZXNuJ3QgZXhpc3QuXG4i
LAorCQkJcGh5LT5oc3QpOworCQlyZXR1cm4gTlVMTDsKKwl9CisJc2RldiAgID0gc2NzaV9kZXZp
Y2VfbG9va3VwKHNob3N0LCBwaHktPmNobiwgcGh5LT50Z3QsIHBoeS0+bHVuKTsKKwlpZiAoIXNk
ZXYpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpYmFjazogJWQ6JWQ6JWQ6JWQgZG9lc24ndCBl
eGlzdC5cbiIsCisJCQlwaHktPmhzdCwgcGh5LT5jaG4sIHBoeS0+dGd0LCBwaHktPmx1bik7CisJ
CXNjc2lfaG9zdF9wdXQoc2hvc3QpOworCQlyZXR1cm4gTlVMTDsKKwl9CisKKwlzY3NpX2hvc3Rf
cHV0KHNob3N0KTsKKwlyZXR1cm4gKHNkZXYpOworfQorCisjZGVmaW5lIFZTQ1NJQkFDS19PUF9B
RERfT1JfREVMX0xVTgkxCisjZGVmaW5lIFZTQ1NJQkFDS19PUF9VUERBVEVERVZfU1RBVEUJMgor
CisKK3N0YXRpYyB2b2lkIHNjc2liYWNrX2RvX2x1bl9ob3RwbHVnKHN0cnVjdCBiYWNrZW5kX2lu
Zm8gKmJlLCBpbnQgb3ApCit7CisJaW50IGksIGVyciA9IDA7CisJc3RydWN0IGlkc190dXBsZSBw
aHksIHZpcjsKKwlpbnQgZGV2aWNlX3N0YXRlOworCWNoYXIgc3RyWzY0XSwgc3RhdGVfc3RyWzY0
XTsKKwljaGFyICoqZGlyOworCXVuc2lnbmVkIGludCBkaXJfbiA9IDA7CisJc3RydWN0IHhlbmJ1
c19kZXZpY2UgKmRldiA9IGJlLT5kZXY7CisJc3RydWN0IHNjc2lfZGV2aWNlICpzZGV2OworCisJ
ZGlyID0geGVuYnVzX2RpcmVjdG9yeShYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCAidnNjc2ktZGV2
cyIsICZkaXJfbik7CisJaWYgKElTX0VSUihkaXIpKQorCQlyZXR1cm47CisKKwlmb3IgKGkgPSAw
OyBpIDwgZGlyX247IGkrKykgeworCQkvKiByZWFkIHN0YXR1cyAqLworCQlzbnByaW50ZihzdGF0
ZV9zdHIsIHNpemVvZihzdGF0ZV9zdHIpLCAidnNjc2ktZGV2cy8lcy9zdGF0ZSIsIGRpcltpXSk7
CisJCWVyciA9IHhlbmJ1c19zY2FuZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCBzdGF0ZV9zdHIs
ICIldSIsCisJCQkmZGV2aWNlX3N0YXRlKTsKKwkJaWYgKFhFTkJVU19FWElTVF9FUlIoZXJyKSkK
KwkJCWNvbnRpbnVlOworCisJCS8qIHBoeXNpY2FsIFNDU0kgZGV2aWNlICovCisJCXNucHJpbnRm
KHN0ciwgc2l6ZW9mKHN0ciksICJ2c2NzaS1kZXZzLyVzL3AtZGV2IiwgZGlyW2ldKTsKKwkJZXJy
ID0geGVuYnVzX3NjYW5mKFhCVF9OSUwsIGRldi0+bm9kZW5hbWUsIHN0ciwKKwkJCSIldToldTol
dToldSIsICZwaHkuaHN0LCAmcGh5LmNobiwgJnBoeS50Z3QsICZwaHkubHVuKTsKKwkJaWYgKFhF
TkJVU19FWElTVF9FUlIoZXJyKSkgeworCQkJeGVuYnVzX3ByaW50ZihYQlRfTklMLCBkZXYtPm5v
ZGVuYW1lLCBzdGF0ZV9zdHIsCisJCQkJCSIlZCIsIFhlbmJ1c1N0YXRlQ2xvc2VkKTsKKwkJCWNv
bnRpbnVlOworCQl9CisKKwkJLyogdmlydHVhbCBTQ1NJIGRldmljZSAqLworCQlzbnByaW50Zihz
dHIsIHNpemVvZihzdHIpLCAidnNjc2ktZGV2cy8lcy92LWRldiIsIGRpcltpXSk7CisJCWVyciA9
IHhlbmJ1c19zY2FuZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCBzdHIsCisJCQkiJXU6JXU6JXU6
JXUiLCAmdmlyLmhzdCwgJnZpci5jaG4sICZ2aXIudGd0LCAmdmlyLmx1bik7CisJCWlmIChYRU5C
VVNfRVhJU1RfRVJSKGVycikpIHsKKwkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2Rl
bmFtZSwgc3RhdGVfc3RyLAorCQkJCQkiJWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQljb250
aW51ZTsKKwkJfQorCisJCXN3aXRjaCAob3ApIHsKKwkJY2FzZSBWU0NTSUJBQ0tfT1BfQUREX09S
X0RFTF9MVU46CisJCQlpZiAoZGV2aWNlX3N0YXRlID09IFhlbmJ1c1N0YXRlSW5pdGlhbGlzaW5n
KSB7CisJCQkJc2RldiA9IHNjc2liYWNrX2dldF9zY3NpX2RldmljZSgmcGh5KTsKKwkJCQlpZiAo
IXNkZXYpCisJCQkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2RlbmFtZSwgc3RhdGVf
c3RyLAorCQkJCQkJCSAgICAiJWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQkJZWxzZSB7CisJ
CQkJCWVyciA9IHNjc2liYWNrX2FkZF90cmFuc2xhdGlvbl9lbnRyeShiZS0+aW5mbywgc2Rldiwg
JnZpcik7CisJCQkJCWlmICghZXJyKSB7CisJCQkJCQlpZiAoeGVuYnVzX3ByaW50ZihYQlRfTklM
LCBkZXYtPm5vZGVuYW1lLCBzdGF0ZV9zdHIsCisJCQkJCQkJCSAgICAiJWQiLCBYZW5idXNTdGF0
ZUluaXRpYWxpc2VkKSkgeworCQkJCQkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6IHhlbmJ1
c19wcmludGYgZXJyb3IgJXNcbiIsIHN0YXRlX3N0cik7CisJCQkJCQkJc2NzaWJhY2tfZGVsX3Ry
YW5zbGF0aW9uX2VudHJ5KGJlLT5pbmZvLCAmdmlyKTsKKwkJCQkJCX0KKwkJCQkJfSBlbHNlIHsK
KwkJCQkJCXNjc2lfZGV2aWNlX3B1dChzZGV2KTsKKwkJCQkJCXhlbmJ1c19wcmludGYoWEJUX05J
TCwgZGV2LT5ub2RlbmFtZSwgc3RhdGVfc3RyLAorCQkJCQkJCQkgICAgIiVkIiwgWGVuYnVzU3Rh
dGVDbG9zZWQpOworCQkJCQl9CisJCQkJfQorCQkJfQorCisJCQlpZiAoZGV2aWNlX3N0YXRlID09
IFhlbmJ1c1N0YXRlQ2xvc2luZykgeworCQkJCWlmICghc2NzaWJhY2tfZGVsX3RyYW5zbGF0aW9u
X2VudHJ5KGJlLT5pbmZvLCAmdmlyKSkgeworCQkJCQlpZiAoeGVuYnVzX3ByaW50ZihYQlRfTklM
LCBkZXYtPm5vZGVuYW1lLCBzdGF0ZV9zdHIsCisJCQkJCQkJICAgICIlZCIsIFhlbmJ1c1N0YXRl
Q2xvc2VkKSkKKwkJCQkJCXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6IHhlbmJ1c19wcmludGYg
ZXJyb3IgJXNcbiIsIHN0YXRlX3N0cik7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisKKwkJY2Fz
ZSBWU0NTSUJBQ0tfT1BfVVBEQVRFREVWX1NUQVRFOgorCQkJaWYgKGRldmljZV9zdGF0ZSA9PSBY
ZW5idXNTdGF0ZUluaXRpYWxpc2VkKSB7CisJCQkJLyogbW9kaWZ5IHZzY3NpLWRldnMvZGV2LXgv
c3RhdGUgKi8KKwkJCQlpZiAoeGVuYnVzX3ByaW50ZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLCBz
dGF0ZV9zdHIsCisJCQkJCQkgICAgIiVkIiwgWGVuYnVzU3RhdGVDb25uZWN0ZWQpKSB7CisJCQkJ
CXByaW50ayhLRVJOX0VSUiAic2NzaWJhY2s6IHhlbmJ1c19wcmludGYgZXJyb3IgJXNcbiIsIHN0
YXRlX3N0cik7CisJCQkJCXNjc2liYWNrX2RlbF90cmFuc2xhdGlvbl9lbnRyeShiZS0+aW5mbywg
JnZpcik7CisJCQkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2RlbmFtZSwgc3RhdGVf
c3RyLAorCQkJCQkJCSAgICAiJWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQkJfQorCQkJfQor
CQkJYnJlYWs7CisJCS8qV2hlbiBpdCBpcyBuZWNlc3NhcnksIHByb2Nlc3NpbmcgaXMgYWRkZWQg
aGVyZS4qLworCQlkZWZhdWx0OgorCQkJYnJlYWs7CisJCX0KKwl9CisKKwlrZnJlZShkaXIpOwor
CXJldHVybiA7Cit9CisKKworc3RhdGljIHZvaWQgc2NzaWJhY2tfZnJvbnRlbmRfY2hhbmdlZChz
dHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2LAorCQkJCQllbnVtIHhlbmJ1c19zdGF0ZSBmcm9udGVu
ZF9zdGF0ZSkKK3sKKwlzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSA9IGRldl9nZXRfZHJ2ZGF0YSgm
ZGV2LT5kZXYpOworCWludCBlcnI7CisKKwlzd2l0Y2ggKGZyb250ZW5kX3N0YXRlKSB7CisJY2Fz
ZSBYZW5idXNTdGF0ZUluaXRpYWxpc2luZzoKKwkJYnJlYWs7CisJY2FzZSBYZW5idXNTdGF0ZUlu
aXRpYWxpc2VkOgorCQllcnIgPSBzY3NpYmFja19tYXAoYmUpOworCQlpZiAoZXJyKQorCQkJYnJl
YWs7CisKKwkJc2NzaWJhY2tfZG9fbHVuX2hvdHBsdWcoYmUsIFZTQ1NJQkFDS19PUF9BRERfT1Jf
REVMX0xVTik7CisJCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2LCBYZW5idXNTdGF0ZUNvbm5lY3Rl
ZCk7CisKKwkJYnJlYWs7CisJY2FzZSBYZW5idXNTdGF0ZUNvbm5lY3RlZDoKKworCQlzY3NpYmFj
a19kb19sdW5faG90cGx1ZyhiZSwgVlNDU0lCQUNLX09QX1VQREFURURFVl9TVEFURSk7CisKKwkJ
aWYgKGRldi0+c3RhdGUgPT0gWGVuYnVzU3RhdGVDb25uZWN0ZWQpCisJCQlicmVhazsKKworCQl4
ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVDb25uZWN0ZWQpOworCisJCWJyZWFr
OworCisJY2FzZSBYZW5idXNTdGF0ZUNsb3Npbmc6CisJCXNjc2liYWNrX2Rpc2Nvbm5lY3QoYmUt
PmluZm8pOworCQl4ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVDbG9zaW5nKTsK
KwkJYnJlYWs7CisKKwljYXNlIFhlbmJ1c1N0YXRlQ2xvc2VkOgorCQl4ZW5idXNfc3dpdGNoX3N0
YXRlKGRldiwgWGVuYnVzU3RhdGVDbG9zZWQpOworCQlpZiAoeGVuYnVzX2Rldl9pc19vbmxpbmUo
ZGV2KSkKKwkJCWJyZWFrOworCQkvKiBmYWxsIHRocm91Z2ggaWYgbm90IG9ubGluZSAqLworCWNh
c2UgWGVuYnVzU3RhdGVVbmtub3duOgorCQlkZXZpY2VfdW5yZWdpc3RlcigmZGV2LT5kZXYpOwor
CQlicmVhazsKKworCWNhc2UgWGVuYnVzU3RhdGVSZWNvbmZpZ3VyaW5nOgorCQlzY3NpYmFja19k
b19sdW5faG90cGx1ZyhiZSwgVlNDU0lCQUNLX09QX0FERF9PUl9ERUxfTFVOKTsKKworCQl4ZW5i
dXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVSZWNvbmZpZ3VyZWQpOworCisJCWJyZWFr
OworCisJZGVmYXVsdDoKKwkJeGVuYnVzX2Rldl9mYXRhbChkZXYsIC1FSU5WQUwsICJzYXcgc3Rh
dGUgJWQgYXQgZnJvbnRlbmQiLAorCQkJCQlmcm9udGVuZF9zdGF0ZSk7CisJCWJyZWFrOworCX0K
K30KKworCitzdGF0aWMgaW50IHNjc2liYWNrX3JlbW92ZShzdHJ1Y3QgeGVuYnVzX2RldmljZSAq
ZGV2KQoreworCXN0cnVjdCBiYWNrZW5kX2luZm8gKmJlID0gZGV2X2dldF9kcnZkYXRhKCZkZXYt
PmRldik7CisKKwlpZiAoYmUtPmluZm8pIHsKKwkJc2NzaWJhY2tfZGlzY29ubmVjdChiZS0+aW5m
byk7CisJCXNjc2liYWNrX3JlbGVhc2VfdHJhbnNsYXRpb25fZW50cnkoYmUtPmluZm8pOworCQlz
Y3NpYmFja19mcmVlKGJlLT5pbmZvKTsKKwkJYmUtPmluZm8gPSBOVUxMOworCX0KKworCWtmcmVl
KGJlKTsKKwlkZXZfc2V0X2RydmRhdGEoJmRldi0+ZGV2LCBOVUxMKTsKKworCXJldHVybiAwOwor
fQorCisKK3N0YXRpYyBpbnQgc2NzaWJhY2tfcHJvYmUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRl
diwKKwkJCSAgIGNvbnN0IHN0cnVjdCB4ZW5idXNfZGV2aWNlX2lkICppZCkKK3sKKwlpbnQgZXJy
OworCXVuc2lnbmVkIHZhbCA9IDA7CisKKwlzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSA9IGt6YWxs
b2Moc2l6ZW9mKHN0cnVjdCBiYWNrZW5kX2luZm8pLAorCQkJCQkgIEdGUF9LRVJORUwpOworCisJ
aWYgKCFiZSkgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgLUVOT01FTSwKKwkJCQkgImFsbG9j
YXRpbmcgYmFja2VuZCBzdHJ1Y3R1cmUiKTsKKwkJcmV0dXJuIC1FTk9NRU07CisJfQorCWJlLT5k
ZXYgPSBkZXY7CisJZGV2X3NldF9kcnZkYXRhKCZkZXYtPmRldiwgYmUpOworCisJYmUtPmluZm8g
PSB2c2NzaWJrX2luZm9fYWxsb2MoZGV2LT5vdGhlcmVuZF9pZCk7CisJaWYgKElTX0VSUihiZS0+
aW5mbykpIHsKKwkJZXJyID0gUFRSX0VSUihiZS0+aW5mbyk7CisJCWJlLT5pbmZvID0gTlVMTDsK
KwkJeGVuYnVzX2Rldl9mYXRhbChkZXYsIGVyciwgImNyZWF0aW5nIHNjc2lob3N0IGludGVyZmFj
ZSIpOworCQlnb3RvIGZhaWw7CisJfQorCisJYmUtPmluZm8tPmRldiA9IGRldjsKKwliZS0+aW5m
by0+aXJxID0gMDsKKwliZS0+aW5mby0+ZmVhdHVyZSA9IDA7CS8qZGVmYXVsdCBub3QgSE9TVE1P
REUuKi8KKworCXNjc2liYWNrX2luaXRfdHJhbnNsYXRpb25fdGFibGUoYmUtPmluZm8pOworCisJ
ZXJyID0geGVuYnVzX3NjYW5mKFhCVF9OSUwsIGRldi0+bm9kZW5hbWUsCisJCQkJImZlYXR1cmUt
aG9zdCIsICIlZCIsICZ2YWwpOworCWlmIChYRU5CVVNfRVhJU1RfRVJSKGVycikpCisJCXZhbCA9
IDA7CisKKwlpZiAodmFsKQorCQliZS0+aW5mby0+ZmVhdHVyZSA9IFZTQ1NJX1RZUEVfSE9TVDsK
KworCWVyciA9IHhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2LCBYZW5idXNTdGF0ZUluaXRXYWl0KTsK
KwlpZiAoZXJyKQorCQlnb3RvIGZhaWw7CisKKwlyZXR1cm4gMDsKKworCitmYWlsOgorCXByaW50
ayhLRVJOX1dBUk5JTkcgInNjc2liYWNrOiAlcyBmYWlsZWRcbiIsX19mdW5jX18pOworCXNjc2li
YWNrX3JlbW92ZShkZXYpOworCisJcmV0dXJuIGVycjsKK30KKworCitzdGF0aWMgY29uc3Qgc3Ry
dWN0IHhlbmJ1c19kZXZpY2VfaWQgc2NzaWJhY2tfaWRzW10gPSB7CisJeyAidnNjc2kiIH0sCisJ
eyAiIiB9Cit9OworCitzdGF0aWMgREVGSU5FX1hFTkJVU19EUklWRVIoc2NzaWJhY2ssICwKKwku
cHJvYmUJCQk9IHNjc2liYWNrX3Byb2JlLAorCS5yZW1vdmUJCQk9IHNjc2liYWNrX3JlbW92ZSwK
Kwkub3RoZXJlbmRfY2hhbmdlZAk9IHNjc2liYWNrX2Zyb250ZW5kX2NoYW5nZWQKKyk7CisKK2lu
dCBzY3NpYmFja194ZW5idXNfaW5pdCh2b2lkKQoreworCXJldHVybiB4ZW5idXNfcmVnaXN0ZXJf
YmFja2VuZCgmc2NzaWJhY2tfZHJpdmVyKTsKK30KKwordm9pZCBzY3NpYmFja194ZW5idXNfdW5y
ZWdpc3Rlcih2b2lkKQoreworCXhlbmJ1c191bnJlZ2lzdGVyX2RyaXZlcigmc2NzaWJhY2tfZHJp
dmVyKTsKK30KZGlmZiAtcnVwTiB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpZnJvbnQvTWFrZWZp
bGUgeGVuYy9kcml2ZXJzL3Njc2kveGVuLXNjc2lmcm9udC9NYWtlZmlsZQotLS0geGVuL2RyaXZl
cnMvc2NzaS94ZW4tc2NzaWZyb250L01ha2VmaWxlCTE5NjktMTItMzEgMTc6MDA6MDAuMDAwMDAw
MDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L01ha2VmaWxlCTIw
MTItMDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNCBAQAorCitvYmot
JChDT05GSUdfWEVOX1NDU0lfRlJPTlRFTkQpCTo9IHhlbi1zY3NpZnJvbnQubworeGVuLXNjc2lm
cm9udC1vYmpzIDo9IHNjc2lmcm9udC5vIHhlbmJ1cy5vCisKZGlmZiAtcnVwTiB4ZW4vZHJpdmVy
cy9zY3NpL3hlbi1zY3NpZnJvbnQvY29tbW9uLmggeGVuYy9kcml2ZXJzL3Njc2kveGVuLXNjc2lm
cm9udC9jb21tb24uaAotLS0geGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L2NvbW1vbi5o
CTE5NjktMTItMzEgMTc6MDA6MDAuMDAwMDAwMDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2Nz
aS94ZW4tc2NzaWZyb250L2NvbW1vbi5oCTIwMTItMDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0w
NzAwCkBAIC0wLDAgKzEsMTM3IEBACisvKgorICogWGVuIFNDU0kgZnJvbnRlbmQgZHJpdmVyCisg
KgorICogQ29weXJpZ2h0IChjKSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQKKyAqCisgKiBUaGlzIHBy
b2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisg
KiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSB2ZXJzaW9uIDIKKyAqIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uOyBvciwgd2hlbiBkaXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51
eCBrZXJuZWwgb3IgaW5jb3Jwb3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2Vz
LCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlz
IGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcg
YSBjb3B5CisgKiBvZiB0aGlzIHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwg
aW4gdGhlIFNvZnR3YXJlIHdpdGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91
dCBsaW1pdGF0aW9uIHRoZSByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwg
cHVibGlzaCwgZGlzdHJpYnV0ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRo
ZSBTb2Z0d2FyZSwKKyAqIGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2Fy
ZSBpcyBmdXJuaXNoZWQgdG8gZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29u
ZGl0aW9uczoKKyAqCisgKiBUaGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJt
aXNzaW9uIG5vdGljZSBzaGFsbCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJz
dGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElT
IFBST1ZJREVEICJBUyBJUyIsIFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1Mg
T1IKKyAqIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP
U0UgQU5EIE5PTklORlJJTkdFTUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JT
IE9SIENPUFlSSUdIVCBIT0xERVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9S
IE9USEVSCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBU
T1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJ
T04gV0lUSCBUSEUgU09GVFdBUkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4g
VEhFIFNPRlRXQVJFLgorICovCisKKyNpZm5kZWYgX19YRU5fRFJJVkVSU19TQ1NJRlJPTlRfSF9f
CisjZGVmaW5lIF9fWEVOX0RSSVZFUlNfU0NTSUZST05UX0hfXworCisjaW5jbHVkZSA8bGludXgv
dmVyc2lvbi5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgorI2luY2x1ZGUgPGxpbnV4L2tl
cm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L2RldmljZS5oPgorI2luY2x1ZGUgPGxpbnV4L2t0aHJl
YWQuaD4KKyNpbmNsdWRlIDxsaW51eC93YWl0Lmg+CisjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0
Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4KKyNpbmNsdWRlIDxsaW51eC9zY2hlZC5o
PgorI2luY2x1ZGUgPGxpbnV4L2Jsa2Rldi5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaV9jbW5kLmg+
CisjaW5jbHVkZSA8c2NzaS9zY3NpX2RldmljZS5oPgorI2luY2x1ZGUgPHNjc2kvc2NzaS5oPgor
I2luY2x1ZGUgPHNjc2kvc2NzaV9ob3N0Lmg+CisjaW5jbHVkZSA8YXNtL3hlbi9wYWdlLmg+Cisj
aW5jbHVkZSA8eGVuL3hlbmJ1cy5oPgorI2luY2x1ZGUgPHhlbi9ncmFudF90YWJsZS5oPgorI2lu
Y2x1ZGUgPHhlbi9ldmVudHMuaD4KKyNpbmNsdWRlIDx4ZW4vZXZ0Y2huLmg+CisjaW5jbHVkZSA8
eGVuL2ludGVyZmFjZS94ZW4uaD4KKyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL2lvL3JpbmcuaD4K
KyNpbmNsdWRlIDx4ZW4vaW50ZXJmYWNlL2lvL3ZzY3NpaWYuaD4KKyNpbmNsdWRlIDx4ZW4vaW50
ZXJmYWNlL2dyYW50X3RhYmxlLmg+CisjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS9pby9wcm90b2Nv
bHMuaD4KKyNpbmNsdWRlIDxhc20vZGVsYXkuaD4KKyNpbmNsdWRlIDxhc20vaHlwZXJ2aXNvci5o
PgorLyojaW5jbHVkZSA8YXNtL21hZGRyLmg+Ki8KKworI2lmZGVmIEhBVkVfWEVOX1BMQVRGT1JN
X0NPTVBBVF9ICisjaW5jbHVkZSA8eGVuL3BsYXRmb3JtLWNvbXBhdC5oPgorI2VuZGlmCisKKyNk
ZWZpbmUgR1JBTlRfSU5WQUxJRF9SRUYJMAorI2RlZmluZSBWU0NTSV9JTl9BQk9SVAkJMQorI2Rl
ZmluZSBWU0NTSV9JTl9SRVNFVAkJMgorCisvKiB0dW5pbmcgcG9pbnQqLworI2RlZmluZSBWU0NT
SUlGX0RFRkFVTFRfQ01EX1BFUl9MVU4gMTAKKyNkZWZpbmUgVlNDU0lJRl9NQVhfVEFSR0VUICAg
ICAgICAgIDY0CisjZGVmaW5lIFZTQ1NJSUZfTUFYX0xVTiAgICAgICAgICAgICAyNTUKKworI2Rl
ZmluZSBWU0NTSUlGX1JJTkdfU0laRQlfX0NPTlNUX1JJTkdfU0laRSh2c2NzaWlmLCBQQUdFX1NJ
WkUpCisjZGVmaW5lIFZTQ1NJSUZfTUFYX1JFUVMJVlNDU0lJRl9SSU5HX1NJWkUKKworc3RydWN0
IHZzY3NpZnJudF9zaGFkb3cgeworCXVpbnQxNl90IG5leHRfZnJlZTsKKworCS8qIGNvbW1hbmQg
YmV0d2VlbiBiYWNrZW5kIGFuZCBmcm9udGVuZAorCSAqIFZTQ1NJSUZfQUNUX1NDU0lfQ0RCIG9y
IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQgKi8KKwl1bnNpZ25lZCBjaGFyIGFjdDsKKworCS8qIGRv
IHJlc2V0IGZ1bmN0aW9uICovCisJd2FpdF9xdWV1ZV9oZWFkX3Qgd3FfcmVzZXQ7CS8qIHJlc2V0
IHdvcmsgcXVldWUgICAgICAgICAgICovCisJaW50IHdhaXRfcmVzZXQ7CQkJLyogcmVzZXQgd29y
ayBxdWV1ZSBjb25kaXRpb24gKi8KKwlpbnQzMl90IHJzbHRfcmVzZXQ7CQkvKiByZXNldCByZXNw
b25zZSBzdGF0dXMgICAgICAqLworCQkJCQkvKiAoU1VDRVNTIG9yIEZBSUxFRCkgICAgICAgICAq
LworCisJLyogZm9yIERNQV9UT19ERVZJQ0UoMSksIERNQV9GUk9NX0RFVklDRSgyKSwgRE1BX05P
TkUoMykKKwkgICByZXF1ZXN0cyAqLworCXVuc2lnbmVkIGludCBzY19kYXRhX2RpcmVjdGlvbjsK
KworCS8qIE51bWJlciBvZiBwaWVjZXMgb2Ygc2NhdHRlci1nYXRoZXIgKi8KKwl1bnNpZ25lZCBp
bnQgbnJfc2VnbWVudHM7CisKKwkvKiByZXF1ZXN0ZWQgc3RydWN0IHNjc2lfY21uZCBpcyBzdG9y
ZWQgZnJvbSBrZXJuZWwgKi8KKwl1bnNpZ25lZCBsb25nIHJlcV9zY3NpX2NtbmQ7CisJaW50IGdy
ZWZbVlNDU0lJRl9TR19UQUJMRVNJWkVdOworfTsKKworc3RydWN0IHZzY3NpZnJudF9pbmZvIHsK
KwlzdHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2OworCisJc3RydWN0IFNjc2lfSG9zdCAqaG9zdDsK
KworCXNwaW5sb2NrX3QgaW9fbG9jazsKKwlzcGlubG9ja190IHNoYWRvd19sb2NrOworCXVuc2ln
bmVkIGludCBldnRjaG47CisJdW5zaWduZWQgaW50IGlycTsKKworCWdyYW50X3JlZl90IHJpbmdf
cmVmOworCXN0cnVjdCB2c2NzaWlmX2Zyb250X3JpbmcgcmluZzsKKwlzdHJ1Y3QgdnNjc2lpZl9y
ZXNwb25zZQlyaW5nX3JlczsKKworCXN0cnVjdCB2c2NzaWZybnRfc2hhZG93IHNoYWRvd1tWU0NT
SUlGX01BWF9SRVFTXTsKKwl1aW50MzJfdCBzaGFkb3dfZnJlZTsKKworCXN0cnVjdCB0YXNrX3N0
cnVjdCAqa3RocmVhZDsKKwl3YWl0X3F1ZXVlX2hlYWRfdCB3cTsKKwl1bnNpZ25lZCBpbnQgd2Fp
dGluZ19yZXNwOworCit9OworCisjZGVmaW5lIERQUklOVEsoX2YsIF9hLi4uKQkJCQlcCisJcHJf
ZGVidWcoIihmaWxlPSVzLCBsaW5lPSVkKSAiIF9mLAlcCisJCSBfX0ZJTEVfXyAsIF9fTElORV9f
ICwgIyMgX2EgKQorCitpbnQgc2NzaWZyb250X3hlbmJ1c19pbml0KHZvaWQpOwordm9pZCBzY3Np
ZnJvbnRfeGVuYnVzX3VucmVnaXN0ZXIodm9pZCk7CitpbnQgc2NzaWZyb250X3NjaGVkdWxlKHZv
aWQgKmRhdGEpOworaXJxcmV0dXJuX3Qgc2NzaWZyb250X2ludHIoaW50IGlycSwgdm9pZCAqZGV2
X2lkKTsKK2ludCBzY3NpZnJvbnRfY21kX2RvbmUoc3RydWN0IHZzY3NpZnJudF9pbmZvICppbmZv
KTsKKworCisjZW5kaWYgLyogX19YRU5fRFJJVkVSU19TQ1NJRlJPTlRfSF9fICAqLwpkaWZmIC1y
dXBOIHhlbi9kcml2ZXJzL3Njc2kveGVuLXNjc2lmcm9udC9zY3NpZnJvbnQuYyB4ZW5jL2RyaXZl
cnMvc2NzaS94ZW4tc2NzaWZyb250L3Njc2lmcm9udC5jCi0tLSB4ZW4vZHJpdmVycy9zY3NpL3hl
bi1zY3NpZnJvbnQvc2NzaWZyb250LmMJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3
MDAKKysrIHhlbmMvZHJpdmVycy9zY3NpL3hlbi1zY3NpZnJvbnQvc2NzaWZyb250LmMJMjAxMi0w
Mi0yNCAxNDo1NjoxMy41Mzg5NzgzMDAgLTA3MDAKQEAgLTAsMCArMSw0NjkgQEAKKy8qCisgKiBY
ZW4gU0NTSSBmcm9udGVuZCBkcml2ZXIKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMDgsIEZVSklU
U1UgTGltaXRlZAorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IKKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2Yg
dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIHZlcnNpb24gMgorICogYXMgcHVibGlzaGVk
IGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IG9yLCB3aGVuIGRpc3RyaWJ1dGVkCisg
KiBzZXBhcmF0ZWx5IGZyb20gdGhlIExpbnV4IGtlcm5lbCBvciBpbmNvcnBvcmF0ZWQgaW50byBv
dGhlcgorICogc29mdHdhcmUgcGFja2FnZXMsIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBsaWNl
bnNlOgorICoKKyAqIFBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdl
LCB0byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkKKyAqIG9mIHRoaXMgc291cmNlIGZpbGUg
KHRoZSAiU29mdHdhcmUiKSwgdG8gZGVhbCBpbiB0aGUgU29mdHdhcmUgd2l0aG91dAorICogcmVz
dHJpY3Rpb24sIGluY2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlIHJpZ2h0cyB0byB1c2Us
IGNvcHksIG1vZGlmeSwKKyAqIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBzdWJsaWNlbnNl
LCBhbmQvb3Igc2VsbCBjb3BpZXMgb2YgdGhlIFNvZnR3YXJlLAorICogYW5kIHRvIHBlcm1pdCBw
ZXJzb25zIHRvIHdob20gdGhlIFNvZnR3YXJlIGlzIGZ1cm5pc2hlZCB0byBkbyBzbywgc3ViamVj
dCB0bworICogdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBhYm92ZSBjb3B5
cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJlIGluY2x1ZGVk
IGluCisgKiBhbGwgY29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRoZSBTb2Z0d2Fy
ZS4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lUSE9VVCBXQVJS
QU5UWSBPRiBBTlkgS0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVESU5HIEJVVCBO
T1QgTElNSVRFRCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksCisgKiBGSVRO
RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBF
VkVOVCBTSEFMTCBUSEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMgQkUgTElBQkxF
IEZPUiBBTlkgQ0xBSU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwgV0hFVEhFUiBJ
TiBBTiBBQ1RJT04gT0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklTSU5HCisgKiBG
Uk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNF
IE9SIE9USEVSIERFQUxJTkdTCisgKiBJTiBUSEUgU09GVFdBUkUuCisgKi8KKworI2luY2x1ZGUg
PGxpbnV4L3ZlcnNpb24uaD4KKyNpbmNsdWRlICJjb21tb24uaCIKKworc3RhdGljIGludCBnZXRf
aWRfZnJvbV9mcmVlbGlzdChzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8pCit7CisJdW5zaWdu
ZWQgbG9uZyBmbGFnczsKKwl1aW50MzJfdCBmcmVlOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmlu
Zm8tPnNoYWRvd19sb2NrLCBmbGFncyk7CisKKwlmcmVlID0gaW5mby0+c2hhZG93X2ZyZWU7CisJ
QlVHX09OKGZyZWUgPiBWU0NTSUlGX01BWF9SRVFTKTsKKwlpbmZvLT5zaGFkb3dfZnJlZSA9IGlu
Zm8tPnNoYWRvd1tmcmVlXS5uZXh0X2ZyZWU7CisJaW5mby0+c2hhZG93W2ZyZWVdLm5leHRfZnJl
ZSA9IDB4MGZmZjsKKworCWluZm8tPnNoYWRvd1tmcmVlXS53YWl0X3Jlc2V0ID0gMDsKKworCXNw
aW5fdW5sb2NrX2lycXJlc3RvcmUoJmluZm8tPnNoYWRvd19sb2NrLCBmbGFncyk7CisKKwlyZXR1
cm4gZnJlZTsKK30KKworc3RhdGljIHZvaWQgYWRkX2lkX3RvX2ZyZWVsaXN0KHN0cnVjdCB2c2Nz
aWZybnRfaW5mbyAqaW5mbywgdWludDMyX3QgaWQpCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsK
KworCXNwaW5fbG9ja19pcnFzYXZlKCZpbmZvLT5zaGFkb3dfbG9jaywgZmxhZ3MpOworCisJaW5m
by0+c2hhZG93W2lkXS5uZXh0X2ZyZWUgID0gaW5mby0+c2hhZG93X2ZyZWU7CisJaW5mby0+c2hh
ZG93W2lkXS5yZXFfc2NzaV9jbW5kID0gMDsKKwlpbmZvLT5zaGFkb3dfZnJlZSA9IGlkOworCisJ
c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW5mby0+c2hhZG93X2xvY2ssIGZsYWdzKTsKK30KKwor
CitzdHJ1Y3QgdnNjc2lpZl9yZXF1ZXN0ICogc2NzaWZyb250X3ByZV9yZXF1ZXN0KHN0cnVjdCB2
c2NzaWZybnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgdnNjc2lpZl9mcm9udF9yaW5nICpyaW5n
ID0gJihpbmZvLT5yaW5nKTsKKwl2c2NzaWlmX3JlcXVlc3RfdCAqcmluZ19yZXE7CisJdWludDMy
X3QgaWQ7CisKKwlyaW5nX3JlcSA9IFJJTkdfR0VUX1JFUVVFU1QoJihpbmZvLT5yaW5nKSwgcmlu
Zy0+cmVxX3Byb2RfcHZ0KTsKKworCXJpbmctPnJlcV9wcm9kX3B2dCsrOworCisJaWQgPSBnZXRf
aWRfZnJvbV9mcmVlbGlzdChpbmZvKTsJLyogdXNlIGlkIGJ5IHJlc3BvbnNlICovCisJcmluZ19y
ZXEtPnJxaWQgPSAodWludDE2X3QpaWQ7CisKKwlyZXR1cm4gcmluZ19yZXE7Cit9CisKKworc3Rh
dGljIHZvaWQgc2NzaWZyb250X25vdGlmeV93b3JrKHN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5m
bykKK3sKKwlpbmZvLT53YWl0aW5nX3Jlc3AgPSAxOworCXdha2VfdXAoJmluZm8tPndxKTsKK30K
KworCitzdGF0aWMgdm9pZCBzY3NpZnJvbnRfZG9fcmVxdWVzdChzdHJ1Y3QgdnNjc2lmcm50X2lu
Zm8gKmluZm8pCit7CisJc3RydWN0IHZzY3NpaWZfZnJvbnRfcmluZyAqcmluZyA9ICYoaW5mby0+
cmluZyk7CisJdW5zaWduZWQgaW50IGlycSA9IGluZm8tPmlycTsKKwlpbnQgbm90aWZ5OworCisJ
UklOR19QVVNIX1JFUVVFU1RTX0FORF9DSEVDS19OT1RJRlkocmluZywgbm90aWZ5KTsKKwlpZiAo
bm90aWZ5KQorCQlub3RpZnlfcmVtb3RlX3ZpYV9pcnEoaXJxKTsKK30KKworaXJxcmV0dXJuX3Qg
c2NzaWZyb250X2ludHIoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjc2lmcm9udF9ub3Rp
Znlfd29yaygoc3RydWN0IHZzY3NpZnJudF9pbmZvICopZGV2X2lkKTsKKwlyZXR1cm4gSVJRX0hB
TkRMRUQ7Cit9CisKKworc3RhdGljIHZvaWQgc2NzaWZyb250X2dudHRhYl9kb25lKHN0cnVjdCB2
c2NzaWZybnRfc2hhZG93ICpzLCB1aW50MzJfdCBpZCkKK3sKKwlpbnQgaTsKKworCWlmIChzLT5z
Y19kYXRhX2RpcmVjdGlvbiA9PSBETUFfTk9ORSkKKwkJcmV0dXJuOworCisJaWYgKHMtPm5yX3Nl
Z21lbnRzKSB7CisJCWZvciAoaSA9IDA7IGkgPCBzLT5ucl9zZWdtZW50czsgaSsrKSB7CisJCQlp
ZiAodW5saWtlbHkoZ250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNzKAorCQkJCXMtPmdyZWZbaV0p
ICE9IDApKSB7CisJCQkJcHJpbnRrKEtFUk5fQUxFUlQgInNjc2lmcm9udDogIgorCQkJCQkiZ3Jh
bnQgc3RpbGwgaW4gdXNlIGJ5IGJhY2tlbmQuXG4iKTsKKwkJCQlCVUcoKTsKKwkJCX0KKwkJCWdu
dHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3Mocy0+Z3JlZltpXSwgMCwgMFVMKTsKKwkJfQorCX0KKwor
CXJldHVybjsKK30KKworCitzdGF0aWMgdm9pZCBzY3NpZnJvbnRfY2RiX2NtZF9kb25lKHN0cnVj
dCB2c2NzaWZybnRfaW5mbyAqaW5mbywKKwkJICAgICAgIHZzY3NpaWZfcmVzcG9uc2VfdCAqcmlu
Z19yZXMpCit7CisJc3RydWN0IHNjc2lfY21uZCAqc2M7CisJdWludDMyX3QgaWQ7CisJdWludDhf
dCBzZW5zZV9sZW47CisKKwlpZCA9IHJpbmdfcmVzLT5ycWlkOworCXNjID0gKHN0cnVjdCBzY3Np
X2NtbmQgKilpbmZvLT5zaGFkb3dbaWRdLnJlcV9zY3NpX2NtbmQ7CisKKwlpZiAoc2MgPT0gTlVM
TCkKKwkJQlVHKCk7CisKKwlzY3NpZnJvbnRfZ250dGFiX2RvbmUoJmluZm8tPnNoYWRvd1tpZF0s
IGlkKTsKKwlhZGRfaWRfdG9fZnJlZWxpc3QoaW5mbywgaWQpOworCisJc2MtPnJlc3VsdCA9IHJp
bmdfcmVzLT5yc2x0OworCXNjc2lfc2V0X3Jlc2lkKHNjLCByaW5nX3Jlcy0+cmVzaWR1YWxfbGVu
KTsKKworCWlmIChyaW5nX3Jlcy0+c2Vuc2VfbGVuID4gVlNDU0lJRl9TRU5TRV9CVUZGRVJTSVpF
KQorCQlzZW5zZV9sZW4gPSBWU0NTSUlGX1NFTlNFX0JVRkZFUlNJWkU7CisJZWxzZQorCQlzZW5z
ZV9sZW4gPSByaW5nX3Jlcy0+c2Vuc2VfbGVuOworCisJaWYgKHNlbnNlX2xlbikKKwkJbWVtY3B5
KHNjLT5zZW5zZV9idWZmZXIsIHJpbmdfcmVzLT5zZW5zZV9idWZmZXIsIHNlbnNlX2xlbik7CisK
KwlzYy0+c2NzaV9kb25lKHNjKTsKKworCXJldHVybjsKK30KKworCitzdGF0aWMgdm9pZCBzY3Np
ZnJvbnRfc3luY19jbWRfZG9uZShzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8sCisJCQkJdnNj
c2lpZl9yZXNwb25zZV90ICpyaW5nX3JlcykKK3sKKwl1aW50MTZfdCBpZCA9IHJpbmdfcmVzLT5y
cWlkOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisKKwlzcGluX2xvY2tfaXJxc2F2ZSgmaW5mby0+
c2hhZG93X2xvY2ssIGZsYWdzKTsKKwlpbmZvLT5zaGFkb3dbaWRdLndhaXRfcmVzZXQgPSAxOwor
CWluZm8tPnNoYWRvd1tpZF0ucnNsdF9yZXNldCA9IHJpbmdfcmVzLT5yc2x0OworCXNwaW5fdW5s
b2NrX2lycXJlc3RvcmUoJmluZm8tPnNoYWRvd19sb2NrLCBmbGFncyk7CisKKwl3YWtlX3VwKCYo
aW5mby0+c2hhZG93W2lkXS53cV9yZXNldCkpOworfQorCisKK2ludCBzY3NpZnJvbnRfY21kX2Rv
bmUoc3RydWN0IHZzY3NpZnJudF9pbmZvICppbmZvKQoreworCXZzY3NpaWZfcmVzcG9uc2VfdCAq
cmluZ19yZXM7CisKKwlSSU5HX0lEWCBpLCBycDsKKwlpbnQgbW9yZV90b19kbyA9IDA7CisJdW5z
aWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19pcnFzYXZlKCZpbmZvLT5pb19sb2NrLCBm
bGFncyk7CisKKwlycCA9IGluZm8tPnJpbmcuc3JpbmctPnJzcF9wcm9kOworCXJtYigpOworCWZv
ciAoaSA9IGluZm8tPnJpbmcucnNwX2NvbnM7IGkgIT0gcnA7IGkrKykgeworCisJCXJpbmdfcmVz
ID0gUklOR19HRVRfUkVTUE9OU0UoJmluZm8tPnJpbmcsIGkpOworCisJCWlmIChpbmZvLT5zaGFk
b3dbcmluZ19yZXMtPnJxaWRdLmFjdCA9PSBWU0NTSUlGX0FDVF9TQ1NJX0NEQikKKwkJCXNjc2lm
cm9udF9jZGJfY21kX2RvbmUoaW5mbywgcmluZ19yZXMpOworCQllbHNlCisJCQlzY3NpZnJvbnRf
c3luY19jbWRfZG9uZShpbmZvLCByaW5nX3Jlcyk7CisJfQorCisJaW5mby0+cmluZy5yc3BfY29u
cyA9IGk7CisKKwlpZiAoaSAhPSBpbmZvLT5yaW5nLnJlcV9wcm9kX3B2dCkgeworCQlSSU5HX0ZJ
TkFMX0NIRUNLX0ZPUl9SRVNQT05TRVMoJmluZm8tPnJpbmcsIG1vcmVfdG9fZG8pOworCX0gZWxz
ZSB7CisJCWluZm8tPnJpbmcuc3JpbmctPnJzcF9ldmVudCA9IGkgKyAxOworCX0KKworCXNwaW5f
dW5sb2NrX2lycXJlc3RvcmUoJmluZm8tPmlvX2xvY2ssIGZsYWdzKTsKKworCisJLyogWWllbGQg
cG9pbnQgZm9yIHRoaXMgdW5ib3VuZGVkIGxvb3AuICovCisJY29uZF9yZXNjaGVkKCk7CisKKwly
ZXR1cm4gbW9yZV90b19kbzsKK30KKworCisKKworaW50IHNjc2lmcm9udF9zY2hlZHVsZSh2b2lk
ICpkYXRhKQoreworCXN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbyA9IChzdHJ1Y3QgdnNjc2lm
cm50X2luZm8gKilkYXRhOworCisJd2hpbGUgKCFrdGhyZWFkX3Nob3VsZF9zdG9wKCkpIHsKKwkJ
d2FpdF9ldmVudF9pbnRlcnJ1cHRpYmxlKAorCQkJaW5mby0+d3EsCisJCQlpbmZvLT53YWl0aW5n
X3Jlc3AgfHwga3RocmVhZF9zaG91bGRfc3RvcCgpKTsKKworCQlpbmZvLT53YWl0aW5nX3Jlc3Ag
PSAwOworCQlzbXBfbWIoKTsKKworCQlpZiAoc2NzaWZyb250X2NtZF9kb25lKGluZm8pKQorCQkJ
aW5mby0+d2FpdGluZ19yZXNwID0gMTsKKwl9CisKKwlyZXR1cm4gMDsKK30KKworCisKK3N0YXRp
YyBpbnQgbWFwX2RhdGFfZm9yX3JlcXVlc3Qoc3RydWN0IHZzY3NpZnJudF9pbmZvICppbmZvLAor
CQlzdHJ1Y3Qgc2NzaV9jbW5kICpzYywgdnNjc2lpZl9yZXF1ZXN0X3QgKnJpbmdfcmVxLCB1aW50
MzJfdCBpZCkKK3sKKwlncmFudF9yZWZfdCBncmVmX2hlYWQ7CisJaW50IGVyciwgcmVmLCByZWZf
Y250ID0gMDsKKwlpbnQgd3JpdGUgPSAoc2MtPnNjX2RhdGFfZGlyZWN0aW9uID09IERNQV9UT19E
RVZJQ0UpOworCXVuc2lnbmVkIGludCBpLCBucl9wYWdlcywgb2ZmLCBsZW4sIGJ5dGVzOworCXVu
c2lnbmVkIGxvbmcgYnVmZmVyX21mbiwgYnVmZmVyX3BmbjsKKworCWlmIChzYy0+c2NfZGF0YV9k
aXJlY3Rpb24gPT0gRE1BX05PTkUpCisJCXJldHVybiAwOworCisJZXJyID0gZ250dGFiX2FsbG9j
X2dyYW50X3JlZmVyZW5jZXMoVlNDU0lJRl9TR19UQUJMRVNJWkUsICZncmVmX2hlYWQpOworCWlm
IChlcnIpIHsKKwkJcHJpbnRrKEtFUk5fRVJSICJzY3NpZnJvbnQ6IGdudHRhYl9hbGxvY19ncmFu
dF9yZWZlcmVuY2VzKCkgZXJyb3JcbiIpOworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisKKwlpZiAo
c2NzaV9idWZmbGVuKHNjKSkgeworCQkvKiBxdW90ZWQgc2NzaV9saWIuYy9zY3NpX3JlcV9tYXBf
c2cgLiAqLworCQlzdHJ1Y3Qgc2NhdHRlcmxpc3QgKnNnLCAqc2dsID0gc2NzaV9zZ2xpc3Qoc2Mp
OworCQl1bnNpZ25lZCBpbnQgZGF0YV9sZW4gPSBzY3NpX2J1ZmZsZW4oc2MpOworCisJCW5yX3Bh
Z2VzID0gKGRhdGFfbGVuICsgc2dsLT5vZmZzZXQgKyBQQUdFX1NJWkUgLSAxKSA+PiBQQUdFX1NI
SUZUOworCQlpZiAobnJfcGFnZXMgPiBWU0NTSUlGX1NHX1RBQkxFU0laRSkgeworCQkJcHJpbnRr
KEtFUk5fRVJSICJzY3NpZnJvbnQ6IFVuYWJsZSB0byBtYXAgcmVxdWVzdF9idWZmZXIgZm9yIGNv
bW1hbmQhXG4iKTsKKwkJCXJlZl9jbnQgPSAoLUUyQklHKTsKKwkJCWdvdG8gYmlnX3RvX3NnOwor
CQl9CisKKwkJZm9yX2VhY2hfc2cgKHNnbCwgc2csIHNjc2lfc2dfY291bnQoc2MpLCBpKSB7CisJ
CQlvZmYgPSBzZy0+b2Zmc2V0OworCQkJbGVuID0gc2ctPmxlbmd0aDsKKworCQkJYnVmZmVyX3Bm
biA9IHBhZ2VfdG9fcGZuKHNnX3BhZ2Uoc2cpKTsKKwkJCXdoaWxlIChsZW4gPiAwICYmIGRhdGFf
bGVuID4gMCkgeworCQkJCS8qCisJCQkJICogc2cgc2VuZHMgYSBzY2F0dGVybGlzdCB0aGF0IGlz
IGxhcmdlciB0aGFuCisJCQkJICogdGhlIGRhdGFfbGVuIGl0IHdhbnRzIHRyYW5zZmVycmVkIGZv
ciBjZXJ0YWluCisJCQkJICogSU8gc2l6ZXMKKwkJCQkgKi8KKwkJCQlieXRlcyA9IG1pbl90KHVu
c2lnbmVkIGludCwgbGVuLCBQQUdFX1NJWkUgLSBvZmYpOworCQkJCWJ5dGVzID0gbWluKGJ5dGVz
LCBkYXRhX2xlbik7CisKKwkJCQlyZWYgPSBnbnR0YWJfY2xhaW1fZ3JhbnRfcmVmZXJlbmNlKCZn
cmVmX2hlYWQpOworCQkJCUJVR19PTihyZWYgPT0gLUVOT1NQQyk7CisKKwkJCQlidWZmZXJfbWZu
ID0gcGZuX3RvX21mbihidWZmZXJfcGZuKTsKKwkJCQlnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nl
c3NfcmVmKHJlZiwgaW5mby0+ZGV2LT5vdGhlcmVuZF9pZCwKKwkJCQkJYnVmZmVyX21mbiwgd3Jp
dGUpOworCisJCQkJaW5mby0+c2hhZG93W2lkXS5ncmVmW3JlZl9jbnRdICA9IHJlZjsKKwkJCQly
aW5nX3JlcS0+c2VnW3JlZl9jbnRdLmdyZWYgICAgID0gcmVmOworCQkJCXJpbmdfcmVxLT5zZWdb
cmVmX2NudF0ub2Zmc2V0ICAgPSAodWludDE2X3Qpb2ZmOworCQkJCXJpbmdfcmVxLT5zZWdbcmVm
X2NudF0ubGVuZ3RoICAgPSAodWludDE2X3QpYnl0ZXM7CisKKwkJCQlidWZmZXJfcGZuICsrOwor
CQkJCWxlbiAtPSBieXRlczsKKwkJCQlkYXRhX2xlbiAtPSBieXRlczsKKwkJCQlvZmYgPSAwOwor
CQkJCXJlZl9jbnQrKzsKKwkJCX0KKwkJfQorCX0KKworYmlnX3RvX3NnOgorCisJZ250dGFiX2Zy
ZWVfZ3JhbnRfcmVmZXJlbmNlcyhncmVmX2hlYWQpOworCisJcmV0dXJuIHJlZl9jbnQ7Cit9CisK
K3N0YXRpYyBpbnQgc2NzaWZyb250X3F1ZXVlY29tbWFuZChzdHJ1Y3QgU2NzaV9Ib3N0ICpoLCBz
dHJ1Y3Qgc2NzaV9jbW5kICpzYykKK3sKKwlzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPQor
CQkoc3RydWN0IHZzY3NpZnJudF9pbmZvICopIHNjLT5kZXZpY2UtPmhvc3QtPmhvc3RkYXRhOwor
CXZzY3NpaWZfcmVxdWVzdF90ICpyaW5nX3JlcTsKKwlpbnQgcmVmX2NudDsKKwl1aW50MTZfdCBy
cWlkOworCisJaWYgKFJJTkdfRlVMTCgmaW5mby0+cmluZykpIHsKKwkJZ290byBvdXRfaG9zdF9i
dXN5OworCX0KKworCXNjLT5yZXN1bHQgICAgPSAwOworCisJcmluZ19yZXEgICAgICAgICAgPSBz
Y3NpZnJvbnRfcHJlX3JlcXVlc3QoaW5mbyk7CisJcnFpZCAgICAgICAgICAgICAgPSByaW5nX3Jl
cS0+cnFpZDsKKwlyaW5nX3JlcS0+YWN0ICAgICA9IFZTQ1NJSUZfQUNUX1NDU0lfQ0RCOworCisJ
cmluZ19yZXEtPmlkICAgICAgPSBzYy0+ZGV2aWNlLT5pZDsKKwlyaW5nX3JlcS0+bHVuICAgICA9
IHNjLT5kZXZpY2UtPmx1bjsKKwlyaW5nX3JlcS0+Y2hhbm5lbCA9IHNjLT5kZXZpY2UtPmNoYW5u
ZWw7CisJcmluZ19yZXEtPmNtZF9sZW4gPSBzYy0+Y21kX2xlbjsKKworCUJVR19PTihzYy0+Y21k
X2xlbiA+IFZTQ1NJSUZfTUFYX0NPTU1BTkRfU0laRSk7CisKKwlpZiAoc2MtPmNtZF9sZW4pCisJ
CW1lbWNweShyaW5nX3JlcS0+Y21uZCwgc2MtPmNtbmQsIHNjLT5jbWRfbGVuKTsKKwllbHNlCisJ
CW1lbXNldChyaW5nX3JlcS0+Y21uZCwgMCwgVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFKTsKKwor
CXJpbmdfcmVxLT5zY19kYXRhX2RpcmVjdGlvbiAgID0gKHVpbnQ4X3Qpc2MtPnNjX2RhdGFfZGly
ZWN0aW9uOworCXJpbmdfcmVxLT50aW1lb3V0X3Blcl9jb21tYW5kID0gKHNjLT5yZXF1ZXN0LT50
aW1lb3V0IC8gSFopOworCisJaW5mby0+c2hhZG93W3JxaWRdLnJlcV9zY3NpX2NtbmQgICAgID0g
KHVuc2lnbmVkIGxvbmcpc2M7CisJaW5mby0+c2hhZG93W3JxaWRdLnNjX2RhdGFfZGlyZWN0aW9u
ID0gc2MtPnNjX2RhdGFfZGlyZWN0aW9uOworCWluZm8tPnNoYWRvd1tycWlkXS5hY3QgICAgICAg
ICAgICAgICA9IHJpbmdfcmVxLT5hY3Q7CisKKwlyZWZfY250ID0gbWFwX2RhdGFfZm9yX3JlcXVl
c3QoaW5mbywgc2MsIHJpbmdfcmVxLCBycWlkKTsKKwlpZiAocmVmX2NudCA8IDApIHsKKwkJYWRk
X2lkX3RvX2ZyZWVsaXN0KGluZm8sIHJxaWQpOworCQlpZiAocmVmX2NudCA9PSAoLUVOT01FTSkp
CisJCQlnb3RvIG91dF9ob3N0X2J1c3k7CisJCWVsc2UgeworCQkJc2MtPnJlc3VsdCA9IChESURf
RVJST1IgPDwgMTYpOworCQkJZ290byBvdXRfZmFpbF9jb21tYW5kOworCQl9CisJfQorCisJcmlu
Z19yZXEtPm5yX3NlZ21lbnRzICAgICAgICAgID0gKHVpbnQ4X3QpcmVmX2NudDsKKwlpbmZvLT5z
aGFkb3dbcnFpZF0ubnJfc2VnbWVudHMgPSByZWZfY250OworCisJc2NzaWZyb250X2RvX3JlcXVl
c3QoaW5mbyk7CisKKwlyZXR1cm4gMDsKKworb3V0X2hvc3RfYnVzeToKKwlyZXR1cm4gU0NTSV9N
TFFVRVVFX0hPU1RfQlVTWTsKKworb3V0X2ZhaWxfY29tbWFuZDoKKwlzYy0+c2NzaV9kb25lKHNj
KTsKKwlyZXR1cm4gMDsKK30KKworCitzdGF0aWMgaW50IHNjc2lmcm9udF9laF9hYm9ydF9oYW5k
bGVyKHN0cnVjdCBzY3NpX2NtbmQgKnNjKQoreworCXJldHVybiAoRkFJTEVEKTsKK30KKworLyog
dnNjc2kgc3VwcG9ydHMgb25seSBkZXZpY2VfcmVzZXQsIGJlY2F1c2UgaXQgaXMgZWFjaCBvZiBM
VU5zICovCitzdGF0aWMgaW50IHNjc2lmcm9udF9kZXZfcmVzZXRfaGFuZGxlcihzdHJ1Y3Qgc2Nz
aV9jbW5kICpzYykKK3sKKwlzdHJ1Y3QgU2NzaV9Ib3N0ICpob3N0ID0gc2MtPmRldmljZS0+aG9z
dDsKKwlzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPQorCQkoc3RydWN0IHZzY3NpZnJudF9p
bmZvICopIHNjLT5kZXZpY2UtPmhvc3QtPmhvc3RkYXRhOworCisJdnNjc2lpZl9yZXF1ZXN0X3Qg
KnJpbmdfcmVxOworCXVpbnQxNl90IHJxaWQ7CisJaW50IGVycjsKKworCXNwaW5fbG9ja19pcnEo
aG9zdC0+aG9zdF9sb2NrKTsKKworCXJpbmdfcmVxICAgICAgPSBzY3NpZnJvbnRfcHJlX3JlcXVl
c3QoaW5mbyk7CisJcmluZ19yZXEtPmFjdCA9IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQ7CisKKwly
cWlkICAgICAgICAgID0gcmluZ19yZXEtPnJxaWQ7CisJaW5mby0+c2hhZG93W3JxaWRdLmFjdCA9
IFZTQ1NJSUZfQUNUX1NDU0lfUkVTRVQ7CisKKwlyaW5nX3JlcS0+Y2hhbm5lbCA9IHNjLT5kZXZp
Y2UtPmNoYW5uZWw7CisJcmluZ19yZXEtPmlkICAgICAgPSBzYy0+ZGV2aWNlLT5pZDsKKwlyaW5n
X3JlcS0+bHVuICAgICA9IHNjLT5kZXZpY2UtPmx1bjsKKwlyaW5nX3JlcS0+Y21kX2xlbiA9IHNj
LT5jbWRfbGVuOworCisJaWYgKCBzYy0+Y21kX2xlbiApCisJCW1lbWNweShyaW5nX3JlcS0+Y21u
ZCwgc2MtPmNtbmQsIHNjLT5jbWRfbGVuKTsKKwllbHNlCisJCW1lbXNldChyaW5nX3JlcS0+Y21u
ZCwgMCwgVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFKTsKKworCXJpbmdfcmVxLT5zY19kYXRhX2Rp
cmVjdGlvbiAgID0gKHVpbnQ4X3Qpc2MtPnNjX2RhdGFfZGlyZWN0aW9uOworCXJpbmdfcmVxLT50
aW1lb3V0X3Blcl9jb21tYW5kID0gKHNjLT5yZXF1ZXN0LT50aW1lb3V0IC8gSFopOworCXJpbmdf
cmVxLT5ucl9zZWdtZW50cyAgICAgICAgID0gMDsKKworCXNjc2lmcm9udF9kb19yZXF1ZXN0KGlu
Zm8pOworCisJc3Bpbl91bmxvY2tfaXJxKGhvc3QtPmhvc3RfbG9jayk7CisJd2FpdF9ldmVudF9p
bnRlcnJ1cHRpYmxlKGluZm8tPnNoYWRvd1tycWlkXS53cV9yZXNldCwKKwkJCSBpbmZvLT5zaGFk
b3dbcnFpZF0ud2FpdF9yZXNldCk7CisJc3Bpbl9sb2NrX2lycShob3N0LT5ob3N0X2xvY2spOwor
CisJZXJyID0gaW5mby0+c2hhZG93W3JxaWRdLnJzbHRfcmVzZXQ7CisKKwlhZGRfaWRfdG9fZnJl
ZWxpc3QoaW5mbywgcnFpZCk7CisKKwlzcGluX3VubG9ja19pcnEoaG9zdC0+aG9zdF9sb2NrKTsK
KwlyZXR1cm4gKGVycik7Cit9CisKKworc3RydWN0IHNjc2lfaG9zdF90ZW1wbGF0ZSBzY3NpZnJv
bnRfc2h0ID0geworCS5tb2R1bGUJCQk9IFRISVNfTU9EVUxFLAorCS5uYW1lCQkJPSAiWGVuIFND
U0kgZnJvbnRlbmQgZHJpdmVyIiwKKwkucXVldWVjb21tYW5kCQk9IHNjc2lmcm9udF9xdWV1ZWNv
bW1hbmQsCisJLmVoX2Fib3J0X2hhbmRsZXIJPSBzY3NpZnJvbnRfZWhfYWJvcnRfaGFuZGxlciwK
KwkuZWhfZGV2aWNlX3Jlc2V0X2hhbmRsZXI9IHNjc2lmcm9udF9kZXZfcmVzZXRfaGFuZGxlciwK
KwkuY21kX3Blcl9sdW4JCT0gVlNDU0lJRl9ERUZBVUxUX0NNRF9QRVJfTFVOLAorCS5jYW5fcXVl
dWUJCT0gVlNDU0lJRl9NQVhfUkVRUywKKwkudGhpc19pZCAJCT0gLTEsCisJLnNnX3RhYmxlc2l6
ZQkJPSBWU0NTSUlGX1NHX1RBQkxFU0laRSwKKwkudXNlX2NsdXN0ZXJpbmcJCT0gRElTQUJMRV9D
TFVTVEVSSU5HLAorCS5wcm9jX25hbWUJCT0gInNjc2lmcm9udCIsCit9OworCisKK3N0YXRpYyBp
bnQgX19pbml0IHNjc2lmcm9udF9pbml0KHZvaWQpCit7CisJaW50IGVycjsKKworCWlmICgheGVu
X2RvbWFpbigpKQorCQlyZXR1cm4gLUVOT0RFVjsKKworCWVyciA9IHNjc2lmcm9udF94ZW5idXNf
aW5pdCgpOworCisJcmV0dXJuIGVycjsKK30KKworc3RhdGljIHZvaWQgX19leGl0IHNjc2lmcm9u
dF9leGl0KHZvaWQpCit7CisJc2NzaWZyb250X3hlbmJ1c191bnJlZ2lzdGVyKCk7Cit9CisKK21v
ZHVsZV9pbml0KHNjc2lmcm9udF9pbml0KTsKK21vZHVsZV9leGl0KHNjc2lmcm9udF9leGl0KTsK
KworTU9EVUxFX0RFU0NSSVBUSU9OKCJYZW4gU0NTSSBmcm9udGVuZCBkcml2ZXIiKTsKK01PRFVM
RV9MSUNFTlNFKCJHUEwiKTsKZGlmZiAtcnVwTiB4ZW4vZHJpdmVycy9zY3NpL3hlbi1zY3NpZnJv
bnQveGVuYnVzLmMgeGVuYy9kcml2ZXJzL3Njc2kveGVuLXNjc2lmcm9udC94ZW5idXMuYwotLS0g
eGVuL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L3hlbmJ1cy5jCTE5NjktMTItMzEgMTc6MDA6
MDAuMDAwMDAwMDAwIC0wNzAwCisrKyB4ZW5jL2RyaXZlcnMvc2NzaS94ZW4tc2NzaWZyb250L3hl
bmJ1cy5jCTIwMTItMDItMjQgMTQ6NTY6MTMuNTM4OTc4MzAwIC0wNzAwCkBAIC0wLDAgKzEsNDEx
IEBACisvKgorICogWGVuIFNDU0kgZnJvbnRlbmQgZHJpdmVyCisgKgorICogQ29weXJpZ2h0IChj
KSAyMDA4LCBGVUpJVFNVIExpbWl0ZWQKKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0
d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkgaXQgdW5kZXIg
dGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIKKyAq
IGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBvciwgd2hlbiBk
aXN0cmlidXRlZAorICogc2VwYXJhdGVseSBmcm9tIHRoZSBMaW51eCBrZXJuZWwgb3IgaW5jb3Jw
b3JhdGVkIGludG8gb3RoZXIKKyAqIHNvZnR3YXJlIHBhY2thZ2VzLCBzdWJqZWN0IHRvIHRoZSBm
b2xsb3dpbmcgbGljZW5zZToKKyAqCisgKiBQZXJtaXNzaW9uIGlzIGhlcmVieSBncmFudGVkLCBm
cmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0aGlz
IHNvdXJjZSBmaWxlICh0aGUgIlNvZnR3YXJlIiksIHRvIGRlYWwgaW4gdGhlIFNvZnR3YXJlIHdp
dGhvdXQKKyAqIHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0aW9uIHRoZSBy
aWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksCisgKiBtZXJnZSwgcHVibGlzaCwgZGlzdHJpYnV0
ZSwgc3VibGljZW5zZSwgYW5kL29yIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwKKyAqIGFu
ZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQgdG8g
ZG8gc28sIHN1YmplY3QgdG8KKyAqIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKKyAqCisgKiBU
aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBzaGFs
bCBiZSBpbmNsdWRlZCBpbgorICogYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9ucyBv
ZiB0aGUgU29mdHdhcmUuCisgKgorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIs
IFdJVEhPVVQgV0FSUkFOVFkgT0YgQU5ZIEtJTkQsIEVYUFJFU1MgT1IKKyAqIElNUExJRUQsIElO
Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklM
SVRZLAorICogRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5PTklORlJJTkdF
TUVOVC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFCisgKiBBVVRIT1JTIE9SIENPUFlSSUdIVCBIT0xE
RVJTIEJFIExJQUJMRSBGT1IgQU5ZIENMQUlNLCBEQU1BR0VTIE9SIE9USEVSCisgKiBMSUFCSUxJ
VFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNULCBUT1JUIE9SIE9USEVSV0lTRSwg
QVJJU0lORworICogRlJPTSwgT1VUIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUgU09GVFdB
UkUgT1IgVEhFIFVTRSBPUiBPVEhFUiBERUFMSU5HUworICogSU4gVEhFIFNPRlRXQVJFLgorICov
CisKKyNpbmNsdWRlIDxsaW51eC92ZXJzaW9uLmg+CisjaW5jbHVkZSAiY29tbW9uLmgiCisKK2V4
dGVybiBzdHJ1Y3Qgc2NzaV9ob3N0X3RlbXBsYXRlIHNjc2lmcm9udF9zaHQ7CisKK3N0YXRpYyB2
b2lkIHNjc2lmcm9udF9mcmVlKHN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1
Y3QgU2NzaV9Ib3N0ICpob3N0ID0gaW5mby0+aG9zdDsKKworCWlmIChob3N0LT5zaG9zdF9zdGF0
ZSAhPSBTSE9TVF9ERUwpCisJCXNjc2lfcmVtb3ZlX2hvc3QoaW5mby0+aG9zdCk7CisKKwlpZiAo
aW5mby0+cmluZ19yZWYgIT0gR1JBTlRfSU5WQUxJRF9SRUYpIHsKKwkJZ250dGFiX2VuZF9mb3Jl
aWduX2FjY2VzcyhpbmZvLT5yaW5nX3JlZiwKKwkJCQkJMCwgKHVuc2lnbmVkIGxvbmcpaW5mby0+
cmluZy5zcmluZyk7CisJCWluZm8tPnJpbmdfcmVmID0gR1JBTlRfSU5WQUxJRF9SRUY7CisJCWlu
Zm8tPnJpbmcuc3JpbmcgPSBOVUxMOworCX0KKworCWlmIChpbmZvLT5pcnEpCisJCXVuYmluZF9m
cm9tX2lycWhhbmRsZXIoaW5mby0+aXJxLCBpbmZvKTsKKwlpbmZvLT5pcnEgPSAwOworCisJc2Nz
aV9ob3N0X3B1dChpbmZvLT5ob3N0KTsKK30KKworCitzdGF0aWMgaW50IHNjc2lmcm9udF9hbGxv
Y19yaW5nKHN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgeGVuYnVzX2Rl
dmljZSAqZGV2ID0gaW5mby0+ZGV2OworCXN0cnVjdCB2c2NzaWlmX3NyaW5nICpzcmluZzsKKwlp
bnQgZXJyID0gLUVOT01FTTsKKworCisJaW5mby0+cmluZ19yZWYgPSBHUkFOVF9JTlZBTElEX1JF
RjsKKworCS8qKioqKiBGcm9udGVuZCB0byBCYWNrZW5kIHJpbmcgc3RhcnQgKioqKiovCisJc3Jp
bmcgPSAoc3RydWN0IHZzY3NpaWZfc3JpbmcgKikgX19nZXRfZnJlZV9wYWdlKEdGUF9LRVJORUwp
OworCWlmICghc3JpbmcpIHsKKwkJeGVuYnVzX2Rldl9mYXRhbChkZXYsIGVyciwgImZhaWwgdG8g
YWxsb2NhdGUgc2hhcmVkIHJpbmcgKEZyb250IHRvIEJhY2spIik7CisJCXJldHVybiBlcnI7CisJ
fQorCVNIQVJFRF9SSU5HX0lOSVQoc3JpbmcpOworCUZST05UX1JJTkdfSU5JVCgmaW5mby0+cmlu
Zywgc3JpbmcsIFBBR0VfU0laRSk7CisKKwllcnIgPSB4ZW5idXNfZ3JhbnRfcmluZyhkZXYsIHZp
cnRfdG9fbWZuKHNyaW5nKSk7CisJaWYgKGVyciA8IDApIHsKKwkJZnJlZV9wYWdlKCh1bnNpZ25l
ZCBsb25nKSBzcmluZyk7CisJCWluZm8tPnJpbmcuc3JpbmcgPSBOVUxMOworCQl4ZW5idXNfZGV2
X2ZhdGFsKGRldiwgZXJyLCAiZmFpbCB0byBncmFudCBzaGFyZWQgcmluZyAoRnJvbnQgdG8gQmFj
aykiKTsKKwkJZ290byBmcmVlX3NyaW5nOworCX0KKwlpbmZvLT5yaW5nX3JlZiA9IGVycjsKKwor
CWVyciA9IHhlbmJ1c19hbGxvY19ldnRjaG4oZGV2LCAmaW5mby0+ZXZ0Y2huKTsKKwlpZiAoZXJy
KQorCQlnb3RvIGZyZWVfc3Jpbmc7CisKKwllcnIgPSBiaW5kX2V2dGNobl90b19pcnFoYW5kbGVy
KAorCQkJaW5mby0+ZXZ0Y2huLCBzY3NpZnJvbnRfaW50ciwKKwkJCUlSUUZfU0FNUExFX1JBTkRP
TSwgInNjc2lmcm9udCIsIGluZm8pOworCisJaWYgKGVyciA8PSAwKSB7CisJCXhlbmJ1c19kZXZf
ZmF0YWwoZGV2LCBlcnIsICJiaW5kX2V2dGNobl90b19pcnFoYW5kbGVyIik7CisJCWdvdG8gZnJl
ZV9zcmluZzsKKwl9CisJaW5mby0+aXJxID0gZXJyOworCisJcmV0dXJuIDA7CisKKy8qIGZyZWUg
cmVzb3VyY2UgKi8KK2ZyZWVfc3Jpbmc6CisJc2NzaWZyb250X2ZyZWUoaW5mbyk7CisKKwlyZXR1
cm4gZXJyOworfQorCisKK3N0YXRpYyBpbnQgc2NzaWZyb250X2luaXRfcmluZyhzdHJ1Y3QgdnNj
c2lmcm50X2luZm8gKmluZm8pCit7CisJc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiA9IGluZm8t
PmRldjsKKwlzdHJ1Y3QgeGVuYnVzX3RyYW5zYWN0aW9uIHhidDsKKwlpbnQgZXJyOworCisJRFBS
SU5USygiJXNcbiIsX19GVU5DVElPTl9fKTsKKworCWVyciA9IHNjc2lmcm9udF9hbGxvY19yaW5n
KGluZm8pOworCWlmIChlcnIpCisJCXJldHVybiBlcnI7CisJRFBSSU5USygiJXUgJXVcbiIsIGlu
Zm8tPnJpbmdfcmVmLCBpbmZvLT5ldnRjaG4pOworCithZ2FpbjoKKwllcnIgPSB4ZW5idXNfdHJh
bnNhY3Rpb25fc3RhcnQoJnhidCk7CisJaWYgKGVycikgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRl
diwgZXJyLCAic3RhcnRpbmcgdHJhbnNhY3Rpb24iKTsKKwl9CisKKwllcnIgPSB4ZW5idXNfcHJp
bnRmKHhidCwgZGV2LT5ub2RlbmFtZSwgInJpbmctcmVmIiwgIiV1IiwKKwkJCQlpbmZvLT5yaW5n
X3JlZik7CisJaWYgKGVycikgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJyLCAiJXMiLCAi
d3JpdGluZyByaW5nLXJlZiIpOworCQlnb3RvIGZhaWw7CisJfQorCisJZXJyID0geGVuYnVzX3By
aW50Zih4YnQsIGRldi0+bm9kZW5hbWUsICJldmVudC1jaGFubmVsIiwgIiV1IiwKKwkJCQlpbmZv
LT5ldnRjaG4pOworCisJaWYgKGVycikgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJyLCAi
JXMiLCAid3JpdGluZyBldmVudC1jaGFubmVsIik7CisJCWdvdG8gZmFpbDsKKwl9CisKKwllcnIg
PSB4ZW5idXNfdHJhbnNhY3Rpb25fZW5kKHhidCwgMCk7CisJaWYgKGVycikgeworCQlpZiAoZXJy
ID09IC1FQUdBSU4pCisJCQlnb3RvIGFnYWluOworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJy
LCAiY29tcGxldGluZyB0cmFuc2FjdGlvbiIpOworCQlnb3RvIGZyZWVfc3Jpbmc7CisJfQorCisJ
cmV0dXJuIDA7CisKK2ZhaWw6CisJeGVuYnVzX3RyYW5zYWN0aW9uX2VuZCh4YnQsIDEpOworZnJl
ZV9zcmluZzoKKwkvKiBmcmVlIHJlc291cmNlICovCisJc2NzaWZyb250X2ZyZWUoaW5mbyk7CisK
KwlyZXR1cm4gZXJyOworfQorCisKK3N0YXRpYyBpbnQgc2NzaWZyb250X3Byb2JlKHN0cnVjdCB4
ZW5idXNfZGV2aWNlICpkZXYsCisJCQkJY29uc3Qgc3RydWN0IHhlbmJ1c19kZXZpY2VfaWQgKmlk
KQoreworCXN0cnVjdCB2c2NzaWZybnRfaW5mbyAqaW5mbzsKKwlzdHJ1Y3QgU2NzaV9Ib3N0ICpo
b3N0OworCWludCBpLCBlcnIgPSAtRU5PTUVNOworCWNoYXIgbmFtZVtUQVNLX0NPTU1fTEVOXTsK
KworCWhvc3QgPSBzY3NpX2hvc3RfYWxsb2MoJnNjc2lmcm9udF9zaHQsIHNpemVvZigqaW5mbykp
OworCWlmICghaG9zdCkgeworCQl4ZW5idXNfZGV2X2ZhdGFsKGRldiwgZXJyLCAiZmFpbCB0byBh
bGxvY2F0ZSBzY3NpIGhvc3QiKTsKKwkJcmV0dXJuIGVycjsKKwl9CisJaW5mbyA9IChzdHJ1Y3Qg
dnNjc2lmcm50X2luZm8gKikgaG9zdC0+aG9zdGRhdGE7CisJaW5mby0+aG9zdCA9IGhvc3Q7CisK
KworCWRldl9zZXRfZHJ2ZGF0YSgmZGV2LT5kZXYsIGluZm8pOworCWluZm8tPmRldiAgPSBkZXY7
CisKKwlmb3IgKGkgPSAwOyBpIDwgVlNDU0lJRl9NQVhfUkVRUzsgaSsrKSB7CisJCWluZm8tPnNo
YWRvd1tpXS5uZXh0X2ZyZWUgPSBpICsgMTsKKwkJaW5pdF93YWl0cXVldWVfaGVhZCgmKGluZm8t
PnNoYWRvd1tpXS53cV9yZXNldCkpOworCQlpbmZvLT5zaGFkb3dbaV0ud2FpdF9yZXNldCA9IDA7
CisJfQorCWluZm8tPnNoYWRvd1tWU0NTSUlGX01BWF9SRVFTIC0gMV0ubmV4dF9mcmVlID0gMHgw
ZmZmOworCisJZXJyID0gc2NzaWZyb250X2luaXRfcmluZyhpbmZvKTsKKwlpZiAoZXJyKSB7CisJ
CXNjc2lfaG9zdF9wdXQoaG9zdCk7CisJCXJldHVybiBlcnI7CisJfQorCisJaW5pdF93YWl0cXVl
dWVfaGVhZCgmaW5mby0+d3EpOworCXNwaW5fbG9ja19pbml0KCZpbmZvLT5pb19sb2NrKTsKKwlz
cGluX2xvY2tfaW5pdCgmaW5mby0+c2hhZG93X2xvY2spOworCisJc25wcmludGYobmFtZSwgVEFT
S19DT01NX0xFTiwgInZzY3NpaWYuJWQiLCBpbmZvLT5ob3N0LT5ob3N0X25vKTsKKworCWluZm8t
Pmt0aHJlYWQgPSBrdGhyZWFkX3J1bihzY3NpZnJvbnRfc2NoZWR1bGUsIGluZm8sIG5hbWUpOwor
CWlmIChJU19FUlIoaW5mby0+a3RocmVhZCkpIHsKKwkJZXJyID0gUFRSX0VSUihpbmZvLT5rdGhy
ZWFkKTsKKwkJaW5mby0+a3RocmVhZCA9IE5VTEw7CisJCXByaW50ayhLRVJOX0VSUiAic2NzaWZy
b250OiBrdGhyZWFkIHN0YXJ0IGVyciAlZFxuIiwgZXJyKTsKKwkJZ290byBmcmVlX3NyaW5nOwor
CX0KKworCWhvc3QtPm1heF9pZCAgICAgID0gVlNDU0lJRl9NQVhfVEFSR0VUOworCWhvc3QtPm1h
eF9jaGFubmVsID0gMDsKKwlob3N0LT5tYXhfbHVuICAgICA9IFZTQ1NJSUZfTUFYX0xVTjsKKwlo
b3N0LT5tYXhfc2VjdG9ycyA9IChWU0NTSUlGX1NHX1RBQkxFU0laRSAtIDEpICogUEFHRV9TSVpF
IC8gNTEyOworCWhvc3QtPm1heF9jbWRfbGVuID0gVlNDU0lJRl9NQVhfQ09NTUFORF9TSVpFOwor
CisJZXJyID0gc2NzaV9hZGRfaG9zdChob3N0LCAmZGV2LT5kZXYpOworCWlmIChlcnIpIHsKKwkJ
cHJpbnRrKEtFUk5fRVJSICJzY3NpZnJvbnQ6IGZhaWwgdG8gYWRkIHNjc2kgaG9zdCAlZFxuIiwg
ZXJyKTsKKwkJZ290byBmcmVlX3NyaW5nOworCX0KKworCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2
LCBYZW5idXNTdGF0ZUluaXRpYWxpc2VkKTsKKworCXJldHVybiAwOworCitmcmVlX3NyaW5nOgor
CS8qIGZyZWUgcmVzb3VyY2UgKi8KKwlzY3NpZnJvbnRfZnJlZShpbmZvKTsKKwlyZXR1cm4gZXJy
OworfQorCitzdGF0aWMgaW50IHNjc2lmcm9udF9yZW1vdmUoc3RydWN0IHhlbmJ1c19kZXZpY2Ug
KmRldikKK3sKKwlzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPSBkZXZfZ2V0X2RydmRhdGEo
JmRldi0+ZGV2KTsKKworCURQUklOVEsoIiVzOiAlcyByZW1vdmVkXG4iLF9fRlVOQ1RJT05fXyAs
ZGV2LT5ub2RlbmFtZSk7CisKKwlpZiAoaW5mby0+a3RocmVhZCkgeworCQlrdGhyZWFkX3N0b3Ao
aW5mby0+a3RocmVhZCk7CisJCWluZm8tPmt0aHJlYWQgPSBOVUxMOworCX0KKworCXNjc2lmcm9u
dF9mcmVlKGluZm8pOworCisJcmV0dXJuIDA7Cit9CisKKworc3RhdGljIGludCBzY3NpZnJvbnRf
ZGlzY29ubmVjdChzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8pCit7CisJc3RydWN0IHhlbmJ1
c19kZXZpY2UgKmRldiA9IGluZm8tPmRldjsKKwlzdHJ1Y3QgU2NzaV9Ib3N0ICpob3N0ID0gaW5m
by0+aG9zdDsKKworCURQUklOVEsoIiVzOiAlcyBkaXNjb25uZWN0XG4iLF9fRlVOQ1RJT05fXyAs
ZGV2LT5ub2RlbmFtZSk7CisKKwkvKgorCSAgV2hlbiB0aGlzIGZ1bmN0aW9uIGlzIGV4ZWN1dGVk
LCAgYWxsIGRldmljZXMgb2YKKwkgIEZyb250ZW5kIGhhdmUgYmVlbiBkZWxldGVkLgorCSAgVGhl
cmVmb3JlLCBpdCBuZWVkIG5vdCBibG9jayBJL08gYmVmb3JlIHJlbW92ZV9ob3N0LgorCSovCisK
KwlzY3NpX3JlbW92ZV9ob3N0KGhvc3QpOworCXhlbmJ1c19mcm9udGVuZF9jbG9zZWQoZGV2KTsK
KworCXJldHVybiAwOworfQorCisjZGVmaW5lIFZTQ1NJRlJPTlRfT1BfQUREX0xVTgkxCisjZGVm
aW5lIFZTQ1NJRlJPTlRfT1BfREVMX0xVTgkyCisKK3N0YXRpYyB2b2lkIHNjc2lmcm9udF9kb19s
dW5faG90cGx1ZyhzdHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8sIGludCBvcCkKK3sKKwlzdHJ1
Y3QgeGVuYnVzX2RldmljZSAqZGV2ID0gaW5mby0+ZGV2OworCWludCBpLCBlcnIgPSAwOworCWNo
YXIgc3RyWzY0XSwgc3RhdGVfc3RyWzY0XTsKKwljaGFyICoqZGlyOworCXVuc2lnbmVkIGludCBk
aXJfbiA9IDA7CisJdW5zaWduZWQgaW50IGRldmljZV9zdGF0ZTsKKwl1bnNpZ25lZCBpbnQgaHN0
LCBjaG4sIHRndCwgbHVuOworCXN0cnVjdCBzY3NpX2RldmljZSAqc2RldjsKKworCWRpciA9IHhl
bmJ1c19kaXJlY3RvcnkoWEJUX05JTCwgZGV2LT5vdGhlcmVuZCwgInZzY3NpLWRldnMiLCAmZGly
X24pOworCWlmIChJU19FUlIoZGlyKSkKKwkJcmV0dXJuOworCisJZm9yIChpID0gMDsgaSA8IGRp
cl9uOyBpKyspIHsKKwkJLyogcmVhZCBzdGF0dXMgKi8KKwkJc25wcmludGYoc3RyLCBzaXplb2Yo
c3RyKSwgInZzY3NpLWRldnMvJXMvc3RhdGUiLCBkaXJbaV0pOworCQllcnIgPSB4ZW5idXNfc2Nh
bmYoWEJUX05JTCwgZGV2LT5vdGhlcmVuZCwgc3RyLCAiJXUiLAorCQkJJmRldmljZV9zdGF0ZSk7
CisJCWlmIChYRU5CVVNfRVhJU1RfRVJSKGVycikpCisJCQljb250aW51ZTsKKworCQkvKiB2aXJ0
dWFsIFNDU0kgZGV2aWNlICovCisJCXNucHJpbnRmKHN0ciwgc2l6ZW9mKHN0ciksICJ2c2NzaS1k
ZXZzLyVzL3YtZGV2IiwgZGlyW2ldKTsKKwkJZXJyID0geGVuYnVzX3NjYW5mKFhCVF9OSUwsIGRl
di0+b3RoZXJlbmQsIHN0ciwKKwkJCSIldToldToldToldSIsICZoc3QsICZjaG4sICZ0Z3QsICZs
dW4pOworCQlpZiAoWEVOQlVTX0VYSVNUX0VSUihlcnIpKQorCQkJY29udGludWU7CisKKwkJLyog
ZnJvbnQgZGV2aWNlIHN0YXRlIHBhdGggKi8KKwkJc25wcmludGYoc3RhdGVfc3RyLCBzaXplb2Yo
c3RhdGVfc3RyKSwgInZzY3NpLWRldnMvJXMvc3RhdGUiLCBkaXJbaV0pOworCisJCXN3aXRjaCAo
b3ApIHsKKwkJY2FzZSBWU0NTSUZST05UX09QX0FERF9MVU46CisJCQlpZiAoZGV2aWNlX3N0YXRl
ID09IFhlbmJ1c1N0YXRlSW5pdGlhbGlzZWQpIHsKKwkJCQlzZGV2ID0gc2NzaV9kZXZpY2VfbG9v
a3VwKGluZm8tPmhvc3QsIGNobiwgdGd0LCBsdW4pOworCQkJCWlmIChzZGV2KSB7CisJCQkJCXBy
aW50ayhLRVJOX0VSUiAic2NzaWZyb250OiBEZXZpY2UgYWxyZWFkeSBpbiB1c2UuXG4iKTsKKwkJ
CQkJc2NzaV9kZXZpY2VfcHV0KHNkZXYpOworCQkJCQl4ZW5idXNfcHJpbnRmKFhCVF9OSUwsIGRl
di0+bm9kZW5hbWUsCisJCQkJCQlzdGF0ZV9zdHIsICIlZCIsIFhlbmJ1c1N0YXRlQ2xvc2VkKTsK
KwkJCQl9IGVsc2UgeworCQkJCQlzY3NpX2FkZF9kZXZpY2UoaW5mby0+aG9zdCwgY2huLCB0Z3Qs
IGx1bik7CisJCQkJCXhlbmJ1c19wcmludGYoWEJUX05JTCwgZGV2LT5ub2RlbmFtZSwKKwkJCQkJ
CXN0YXRlX3N0ciwgIiVkIiwgWGVuYnVzU3RhdGVDb25uZWN0ZWQpOworCQkJCX0KKwkJCX0KKwkJ
CWJyZWFrOworCQljYXNlIFZTQ1NJRlJPTlRfT1BfREVMX0xVTjoKKwkJCWlmIChkZXZpY2Vfc3Rh
dGUgPT0gWGVuYnVzU3RhdGVDbG9zaW5nKSB7CisJCQkJc2RldiA9IHNjc2lfZGV2aWNlX2xvb2t1
cChpbmZvLT5ob3N0LCBjaG4sIHRndCwgbHVuKTsKKwkJCQlpZiAoc2RldikgeworCQkJCQlzY3Np
X3JlbW92ZV9kZXZpY2Uoc2Rldik7CisJCQkJCXNjc2lfZGV2aWNlX3B1dChzZGV2KTsKKwkJCQkJ
eGVuYnVzX3ByaW50ZihYQlRfTklMLCBkZXYtPm5vZGVuYW1lLAorCQkJCQkJc3RhdGVfc3RyLCAi
JWQiLCBYZW5idXNTdGF0ZUNsb3NlZCk7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisJCWRlZmF1
bHQ6CisJCQlicmVhazsKKwkJfQorCX0KKworCWtmcmVlKGRpcik7CisJcmV0dXJuOworfQorCisK
KworCitzdGF0aWMgdm9pZCBzY3NpZnJvbnRfYmFja2VuZF9jaGFuZ2VkKHN0cnVjdCB4ZW5idXNf
ZGV2aWNlICpkZXYsCisJCQkJZW51bSB4ZW5idXNfc3RhdGUgYmFja2VuZF9zdGF0ZSkKK3sKKwlz
dHJ1Y3QgdnNjc2lmcm50X2luZm8gKmluZm8gPSBkZXZfZ2V0X2RydmRhdGEoJmRldi0+ZGV2KTsK
KworCURQUklOVEsoIiVwICV1ICV1XG4iLCBkZXYsIGRldi0+c3RhdGUsIGJhY2tlbmRfc3RhdGUp
OworCisJc3dpdGNoIChiYWNrZW5kX3N0YXRlKSB7CisJY2FzZSBYZW5idXNTdGF0ZVVua25vd246
CisJY2FzZSBYZW5idXNTdGF0ZUluaXRpYWxpc2luZzoKKwljYXNlIFhlbmJ1c1N0YXRlSW5pdFdh
aXQ6CisJY2FzZSBYZW5idXNTdGF0ZUNsb3NlZDoKKwkJYnJlYWs7CisKKwljYXNlIFhlbmJ1c1N0
YXRlSW5pdGlhbGlzZWQ6CisJCWJyZWFrOworCisJY2FzZSBYZW5idXNTdGF0ZUNvbm5lY3RlZDoK
KwkJaWYgKHhlbmJ1c19yZWFkX2RyaXZlcl9zdGF0ZShkZXYtPm5vZGVuYW1lKSA9PQorCQkJWGVu
YnVzU3RhdGVJbml0aWFsaXNlZCkgeworCQkJc2NzaWZyb250X2RvX2x1bl9ob3RwbHVnKGluZm8s
IFZTQ1NJRlJPTlRfT1BfQUREX0xVTik7CisJCX0KKworCQlpZiAoZGV2LT5zdGF0ZSA9PSBYZW5i
dXNTdGF0ZUNvbm5lY3RlZCkKKwkJCWJyZWFrOworCisJCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2
LCBYZW5idXNTdGF0ZUNvbm5lY3RlZCk7CisJCWJyZWFrOworCisJY2FzZSBYZW5idXNTdGF0ZUNs
b3Npbmc6CisJCXNjc2lmcm9udF9kaXNjb25uZWN0KGluZm8pOworCQlicmVhazsKKworCWNhc2Ug
WGVuYnVzU3RhdGVSZWNvbmZpZ3VyaW5nOgorCQlzY3NpZnJvbnRfZG9fbHVuX2hvdHBsdWcoaW5m
bywgVlNDU0lGUk9OVF9PUF9ERUxfTFVOKTsKKwkJeGVuYnVzX3N3aXRjaF9zdGF0ZShkZXYsIFhl
bmJ1c1N0YXRlUmVjb25maWd1cmluZyk7CisJCWJyZWFrOworCisJY2FzZSBYZW5idXNTdGF0ZVJl
Y29uZmlndXJlZDoKKwkJc2NzaWZyb250X2RvX2x1bl9ob3RwbHVnKGluZm8sIFZTQ1NJRlJPTlRf
T1BfQUREX0xVTik7CisJCXhlbmJ1c19zd2l0Y2hfc3RhdGUoZGV2LCBYZW5idXNTdGF0ZUNvbm5l
Y3RlZCk7CisJCWJyZWFrOworCX0KK30KKworCitzdGF0aWMgY29uc3Qgc3RydWN0IHhlbmJ1c19k
ZXZpY2VfaWQgc2NzaWZyb250X2lkc1tdID0geworCXsgInZzY3NpIiB9LAorCXsgIiIgfQorfTsK
K01PRFVMRV9BTElBUygieGVuOnZzY3NpIik7CisKK3N0YXRpYyBERUZJTkVfWEVOQlVTX0RSSVZF
UihzY3NpZnJvbnQsICwKKwkucHJvYmUJCQk9IHNjc2lmcm9udF9wcm9iZSwKKwkucmVtb3ZlCQkJ
PSBzY3NpZnJvbnRfcmVtb3ZlLAorLyogCS5yZXN1bWUJCQk9IHNjc2lmcm9udF9yZXN1bWUsICov
CisJLm90aGVyZW5kX2NoYW5nZWQJPSBzY3NpZnJvbnRfYmFja2VuZF9jaGFuZ2VkLAorKTsKKwor
aW50IHNjc2lmcm9udF94ZW5idXNfaW5pdCh2b2lkKQoreworCXJldHVybiB4ZW5idXNfcmVnaXN0
ZXJfZnJvbnRlbmQoJnNjc2lmcm9udF9kcml2ZXIpOworfQorCit2b2lkIHNjc2lmcm9udF94ZW5i
dXNfdW5yZWdpc3Rlcih2b2lkKQoreworCXhlbmJ1c191bnJlZ2lzdGVyX2RyaXZlcigmc2NzaWZy
b250X2RyaXZlcik7Cit9CisKZGlmZiAtcnVwTiB4ZW4vaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2dy
YW50X3RhYmxlLmggeGVuYy9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaAotLS0g
eGVuL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJsZS5oCTIwMTItMDItMjQgMTU6MTI6
NDYuNTQ1NjQ0OTY2IC0wNzAwCisrKyB4ZW5jL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90
YWJsZS5oCTIwMTItMDItMjQgMTU6MTk6MzUuMzM4OTc4Mjg1IC0wNzAwCkBAIC01MjAsNiArNTIw
LDggQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2dldF92ZQogI2RlZmluZSBH
TlRTVF9wZXJtaXNzaW9uX2RlbmllZCAoLTgpIC8qIE5vdCBlbm91Z2ggcHJpdmlsZWdlIGZvciBv
cGVyYXRpb24uICAqLwogI2RlZmluZSBHTlRTVF9iYWRfcGFnZSAgICAgICAgICgtOSkgLyogU3Bl
Y2lmaWVkIHBhZ2Ugd2FzIGludmFsaWQgZm9yIG9wLiAgICAqLwogI2RlZmluZSBHTlRTVF9iYWRf
Y29weV9hcmcgICAgKC0xMCkgLyogY29weSBhcmd1bWVudHMgY3Jvc3MgcGFnZSBib3VuZGFyeSAq
LworI2RlZmluZSBHTlRTVF9hZGRyZXNzX3Rvb19iaWcgKC0xMSkgLyogdHJhbnNmZXIgcGFnZSBh
ZGRyZXNzIHRvbyBsYXJnZS4gICAgICAqLworI2RlZmluZSBHTlRTVF9lYWdhaW4gICAgICAgICAg
KC0xMikgLyogQ291bGQgbm90IG1hcCBhdCB0aGUgbW9tZW50LiBSZXRyeS4gICAqLwogCiAjZGVm
aW5lIEdOVFRBQk9QX2Vycm9yX21zZ3MgeyAgICAgICAgICAgICAgICAgICBcCiAgICAgIm9rYXki
LCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCkBAIC01MzMsNiArNTM1LDgg
QEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2dldF92ZQogICAgICJwZXJtaXNz
aW9uIGRlbmllZCIsICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICJiYWQgcGFnZSIsICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICJjb3B5IGFyZ3VtZW50cyBjcm9z
cyBwYWdlIGJvdW5kYXJ5IiAgICAgICAgXAorICAgICJwYWdlIGFkZHJlc3Mgc2l6ZSB0b28gbGFy
Z2UiLCAgICAgICAgICAgICAgXAorICAgICJjb3VsZCBub3QgbWFwIGF0IHRoZSBtb21lbnQsIHJl
dHJ5IiAgICAgICAgXAogfQogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX0dSQU5UX1RBQkxFX0hf
XyAqLwpkaWZmIC1ydXBOIHhlbi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaC5v
cmlnIHhlbmMvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2dyYW50X3RhYmxlLmgub3JpZwotLS0geGVu
L2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJsZS5oLm9yaWcJMTk2OS0xMi0zMSAxNzow
MDowMC4wMDAwMDAwMDAgLTA3MDAKKysrIHhlbmMvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2dyYW50
X3RhYmxlLmgub3JpZwkyMDEyLTAyLTI0IDE1OjEyOjQ2LjU0NTY0NDk2NiAtMDcwMApAQCAtMCww
ICsxLDUzOCBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogZ3JhbnRfdGFibGUuaAorICoK
KyAqIEludGVyZmFjZSBmb3IgZ3JhbnRpbmcgZm9yZWlnbiBhY2Nlc3MgdG8gcGFnZSBmcmFtZXMs
IGFuZCByZWNlaXZpbmcKKyAqIHBhZ2Utb3duZXJzaGlwIHRyYW5zZmVycy4KKyAqCisgKiBQZXJt
aXNzaW9uIGlzIGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBv
YnRhaW5pbmcgYSBjb3B5CisgKiBvZiB0aGlzIHNvZnR3YXJlIGFuZCBhc3NvY2lhdGVkIGRvY3Vt
ZW50YXRpb24gZmlsZXMgKHRoZSAiU29mdHdhcmUiKSwgdG8KKyAqIGRlYWwgaW4gdGhlIFNvZnR3
YXJlIHdpdGhvdXQgcmVzdHJpY3Rpb24sIGluY2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhl
CisgKiByaWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmli
dXRlLCBzdWJsaWNlbnNlLCBhbmQvb3IKKyAqIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwg
YW5kIHRvIHBlcm1pdCBwZXJzb25zIHRvIHdob20gdGhlIFNvZnR3YXJlIGlzCisgKiBmdXJuaXNo
ZWQgdG8gZG8gc28sIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAq
IFRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNo
YWxsIGJlIGluY2x1ZGVkIGluCisgKiBhbGwgY29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25z
IG9mIHRoZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElT
IiwgV0lUSE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwg
SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFC
SUxJVFksCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklO
R0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhP
TERFUlMgQkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJ
TElUWSwgV0hFVEhFUiBJTiBBTiBBQ1RJT04gT0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNF
LCBBUklTSU5HCisgKiBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZU
V0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSCisgKiBERUFMSU5HUyBJTiBUSEUgU09GVFdBUkUuCisg
KgorICogQ29weXJpZ2h0IChjKSAyMDA0LCBLIEEgRnJhc2VyCisgKi8KKworI2lmbmRlZiBfX1hF
Tl9QVUJMSUNfR1JBTlRfVEFCTEVfSF9fCisjZGVmaW5lIF9fWEVOX1BVQkxJQ19HUkFOVF9UQUJM
RV9IX18KKworI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UveGVuLmg+CisKKy8qKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKgorICogR1JBTlQgVEFCTEUgUkVQUkVTRU5UQVRJT04KKyAq
LworCisvKiBTb21lIHJvdWdoIGd1aWRlbGluZXMgb24gYWNjZXNzaW5nIGFuZCB1cGRhdGluZyBn
cmFudC10YWJsZSBlbnRyaWVzCisgKiBpbiBhIGNvbmN1cnJlbmN5LXNhZmUgbWFubmVyLiBGb3Ig
bW9yZSBpbmZvcm1hdGlvbiwgTGludXggY29udGFpbnMgYQorICogcmVmZXJlbmNlIGltcGxlbWVu
dGF0aW9uIGZvciBndWVzdCBPU2VzIChhcmNoL3hlbi9rZXJuZWwvZ3JhbnRfdGFibGUuYykuCisg
KgorICogTkIuIFdNQiBpcyBhIG5vLW9wIG9uIGN1cnJlbnQtZ2VuZXJhdGlvbiB4ODYgcHJvY2Vz
c29ycy4gSG93ZXZlciwgYQorICogICAgIGNvbXBpbGVyIGJhcnJpZXIgd2lsbCBzdGlsbCBiZSBy
ZXF1aXJlZC4KKyAqCisgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50
IHRhYmxlOgorICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCisgKiAgMi4gV3JpdGUgZW50LT5mcmFt
ZToKKyAqICAgICAgR1RGX3Blcm1pdF9hY2Nlc3M6ICAgRnJhbWUgdG8gd2hpY2ggYWNjZXNzIGlz
IHBlcm1pdHRlZC4KKyAqICAgICAgR1RGX2FjY2VwdF90cmFuc2ZlcjogUHNldWRvLXBoeXMgZnJh
bWUgc2xvdCBiZWluZyBmaWxsZWQgYnkgbmV3CisgKiAgICAgICAgICAgICAgICAgICAgICAgICAg
IGZyYW1lLCBvciB6ZXJvIGlmIG5vbmUuCisgKiAgMy4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdN
QikuCisgKiAgNC4gV3JpdGUgZW50LT5mbGFncywgaW5jLiB2YWxpZCB0eXBlLgorICoKKyAqIElu
dmFsaWRhdGluZyBhbiB1bnVzZWQgR1RGX3Blcm1pdF9hY2Nlc3MgZW50cnk6CisgKiAgMS4gZmxh
Z3MgPSBlbnQtPmZsYWdzLgorICogIDIuIE9ic2VydmUgdGhhdCAhKGZsYWdzICYgKEdURl9yZWFk
aW5nfEdURl93cml0aW5nKSkuCisgKiAgMy4gQ2hlY2sgcmVzdWx0IG9mIFNNUC1zYWZlIENNUFhD
SEcoJmVudC0+ZmxhZ3MsIGZsYWdzLCAwKS4KKyAqICBOQi4gTm8gbmVlZCBmb3IgV01CIGFzIHJl
dXNlIG9mIGVudHJ5IGlzIGNvbnRyb2wtZGVwZW5kZW50IG9uIHN1Y2Nlc3Mgb2YKKyAqICAgICAg
c3RlcCAzLCBhbmQgYWxsIGFyY2hpdGVjdHVyZXMgZ3VhcmFudGVlIG9yZGVyaW5nIG9mIGN0cmwt
ZGVwIHdyaXRlcy4KKyAqCisgKiBJbnZhbGlkYXRpbmcgYW4gaW4tdXNlIEdURl9wZXJtaXRfYWNj
ZXNzIGVudHJ5OgorICogIFRoaXMgY2Fubm90IGJlIGRvbmUgZGlyZWN0bHkuIFJlcXVlc3QgYXNz
aXN0YW5jZSBmcm9tIHRoZSBkb21haW4gY29udHJvbGxlcgorICogIHdoaWNoIGNhbiBzZXQgYSB0
aW1lb3V0IG9uIHRoZSB1c2Ugb2YgYSBncmFudCBlbnRyeSBhbmQgdGFrZSBuZWNlc3NhcnkKKyAq
ICBhY3Rpb24uIChOQi4gVGhpcyBpcyBub3QgeWV0IGltcGxlbWVudGVkISkuCisgKgorICogSW52
YWxpZGF0aW5nIGFuIHVudXNlZCBHVEZfYWNjZXB0X3RyYW5zZmVyIGVudHJ5OgorICogIDEuIGZs
YWdzID0gZW50LT5mbGFncy4KKyAqICAyLiBPYnNlcnZlIHRoYXQgIShmbGFncyAmIEdURl90cmFu
c2Zlcl9jb21taXR0ZWQpLiBbKl0KKyAqICAzLiBDaGVjayByZXN1bHQgb2YgU01QLXNhZmUgQ01Q
WENIRygmZW50LT5mbGFncywgZmxhZ3MsIDApLgorICogIE5CLiBObyBuZWVkIGZvciBXTUIgYXMg
cmV1c2Ugb2YgZW50cnkgaXMgY29udHJvbC1kZXBlbmRlbnQgb24gc3VjY2VzcyBvZgorICogICAg
ICBzdGVwIDMsIGFuZCBhbGwgYXJjaGl0ZWN0dXJlcyBndWFyYW50ZWUgb3JkZXJpbmcgb2YgY3Ry
bC1kZXAgd3JpdGVzLgorICogIFsqXSBJZiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkIGlzIHNldCB0
aGVuIHRoZSBncmFudCBlbnRyeSBpcyAnY29tbWl0dGVkJy4KKyAqICAgICAgVGhlIGd1ZXN0IG11
c3QgL25vdC8gbW9kaWZ5IHRoZSBncmFudCBlbnRyeSB1bnRpbCB0aGUgYWRkcmVzcyBvZiB0aGUK
KyAqICAgICAgdHJhbnNmZXJyZWQgZnJhbWUgaXMgd3JpdHRlbi4gSXQgaXMgc2FmZSBmb3IgdGhl
IGd1ZXN0IHRvIHNwaW4gd2FpdGluZworICogICAgICBmb3IgdGhpcyB0byBvY2N1ciAoZGV0ZWN0
IGJ5IG9ic2VydmluZyBHVEZfdHJhbnNmZXJfY29tcGxldGVkIGluCisgKiAgICAgIGVudC0+Zmxh
Z3MpLgorICoKKyAqIEludmFsaWRhdGluZyBhIGNvbW1pdHRlZCBHVEZfYWNjZXB0X3RyYW5zZmVy
IGVudHJ5OgorICogIDEuIFdhaXQgZm9yIChlbnQtPmZsYWdzICYgR1RGX3RyYW5zZmVyX2NvbXBs
ZXRlZCkuCisgKgorICogQ2hhbmdpbmcgYSBHVEZfcGVybWl0X2FjY2VzcyBmcm9tIHdyaXRhYmxl
IHRvIHJlYWQtb25seToKKyAqICBVc2UgU01QLXNhZmUgQ01QWENIRyB0byBzZXQgR1RGX3JlYWRv
bmx5LCB3aGlsZSBjaGVja2luZyAhR1RGX3dyaXRpbmcuCisgKgorICogQ2hhbmdpbmcgYSBHVEZf
cGVybWl0X2FjY2VzcyBmcm9tIHJlYWQtb25seSB0byB3cml0YWJsZToKKyAqICBVc2UgU01QLXNh
ZmUgYml0LXNldHRpbmcgaW5zdHJ1Y3Rpb24uCisgKi8KKworLyoKKyAqIFJlZmVyZW5jZSB0byBh
IGdyYW50IGVudHJ5IGluIGEgc3BlY2lmaWVkIGRvbWFpbidzIGdyYW50IHRhYmxlLgorICovCit0
eXBlZGVmIHVpbnQzMl90IGdyYW50X3JlZl90OworCisvKgorICogQSBncmFudCB0YWJsZSBjb21w
cmlzZXMgYSBwYWNrZWQgYXJyYXkgb2YgZ3JhbnQgZW50cmllcyBpbiBvbmUgb3IgbW9yZQorICog
cGFnZSBmcmFtZXMgc2hhcmVkIGJldHdlZW4gWGVuIGFuZCBhIGd1ZXN0LgorICogW1hFTl06IFRo
aXMgZmllbGQgaXMgd3JpdHRlbiBieSBYZW4gYW5kIHJlYWQgYnkgdGhlIHNoYXJpbmcgZ3Vlc3Qu
CisgKiBbR1NUXTogVGhpcyBmaWVsZCBpcyB3cml0dGVuIGJ5IHRoZSBndWVzdCBhbmQgcmVhZCBi
eSBYZW4uCisgKi8KKworLyoKKyAqIFZlcnNpb24gMSBvZiB0aGUgZ3JhbnQgdGFibGUgZW50cnkg
c3RydWN0dXJlIGlzIG1haW50YWluZWQgcHVyZWx5CisgKiBmb3IgYmFja3dhcmRzIGNvbXBhdGli
aWxpdHkuICBOZXcgZ3Vlc3RzIHNob3VsZCB1c2UgdmVyc2lvbiAyLgorICovCitzdHJ1Y3QgZ3Jh
bnRfZW50cnlfdjEgeworICAgIC8qIEdURl94eHg6IHZhcmlvdXMgdHlwZSBhbmQgZmxhZyBpbmZv
cm1hdGlvbi4gIFtYRU4sR1NUXSAqLworICAgIHVpbnQxNl90IGZsYWdzOworICAgIC8qIFRoZSBk
b21haW4gYmVpbmcgZ3JhbnRlZCBmb3JlaWduIHByaXZpbGVnZXMuIFtHU1RdICovCisgICAgZG9t
aWRfdCAgZG9taWQ7CisgICAgLyoKKyAgICAgKiBHVEZfcGVybWl0X2FjY2VzczogRnJhbWUgdGhh
dCBAZG9taWQgaXMgYWxsb3dlZCB0byBtYXAgYW5kIGFjY2Vzcy4gW0dTVF0KKyAgICAgKiBHVEZf
YWNjZXB0X3RyYW5zZmVyOiBGcmFtZSB3aG9zZSBvd25lcnNoaXAgdHJhbnNmZXJyZWQgYnkgQGRv
bWlkLiBbWEVOXQorICAgICAqLworICAgIHVpbnQzMl90IGZyYW1lOworfTsKKworLyoKKyAqIFR5
cGUgb2YgZ3JhbnQgZW50cnkuCisgKiAgR1RGX2ludmFsaWQ6IFRoaXMgZ3JhbnQgZW50cnkgZ3Jh
bnRzIG5vIHByaXZpbGVnZXMuCisgKiAgR1RGX3Blcm1pdF9hY2Nlc3M6IEFsbG93IEBkb21pZCB0
byBtYXAvYWNjZXNzIEBmcmFtZS4KKyAqICBHVEZfYWNjZXB0X3RyYW5zZmVyOiBBbGxvdyBAZG9t
aWQgdG8gdHJhbnNmZXIgb3duZXJzaGlwIG9mIG9uZSBwYWdlIGZyYW1lCisgKiAgICAgICAgICAg
ICAgICAgICAgICAgdG8gdGhpcyBndWVzdC4gWGVuIHdyaXRlcyB0aGUgcGFnZSBudW1iZXIgdG8g
QGZyYW1lLgorICogIEdURl90cmFuc2l0aXZlOiBBbGxvdyBAZG9taWQgdG8gdHJhbnNpdGl2ZWx5
IGFjY2VzcyBhIHN1YnJhbmdlIG9mCisgKiAgICAgICAgICAgICAgICAgIEB0cmFuc19ncmFudCBp
biBAdHJhbnNfZG9taWQuICBObyBtYXBwaW5ncyBhcmUgYWxsb3dlZC4KKyAqLworI2RlZmluZSBH
VEZfaW52YWxpZCAgICAgICAgICgwVTw8MCkKKyNkZWZpbmUgR1RGX3Blcm1pdF9hY2Nlc3MgICAo
MVU8PDApCisjZGVmaW5lIEdURl9hY2NlcHRfdHJhbnNmZXIgKDJVPDwwKQorI2RlZmluZSBHVEZf
dHJhbnNpdGl2ZSAgICAgICgzVTw8MCkKKyNkZWZpbmUgR1RGX3R5cGVfbWFzayAgICAgICAoM1U8
PDApCisKKy8qCisgKiBTdWJmbGFncyBmb3IgR1RGX3Blcm1pdF9hY2Nlc3MuCisgKiAgR1RGX3Jl
YWRvbmx5OiBSZXN0cmljdCBAZG9taWQgdG8gcmVhZC1vbmx5IG1hcHBpbmdzIGFuZCBhY2Nlc3Nl
cy4gW0dTVF0KKyAqICBHVEZfcmVhZGluZzogR3JhbnQgZW50cnkgaXMgY3VycmVudGx5IG1hcHBl
ZCBmb3IgcmVhZGluZyBieSBAZG9taWQuIFtYRU5dCisgKiAgR1RGX3dyaXRpbmc6IEdyYW50IGVu
dHJ5IGlzIGN1cnJlbnRseSBtYXBwZWQgZm9yIHdyaXRpbmcgYnkgQGRvbWlkLiBbWEVOXQorICog
IEdURl9zdWJfcGFnZTogR3JhbnQgYWNjZXNzIHRvIG9ubHkgYSBzdWJyYW5nZSBvZiB0aGUgcGFn
ZS4gIEBkb21pZAorICogICAgICAgICAgICAgICAgd2lsbCBvbmx5IGJlIGFsbG93ZWQgdG8gY29w
eSBmcm9tIHRoZSBncmFudCwgYW5kIG5vdAorICogICAgICAgICAgICAgICAgbWFwIGl0LiBbR1NU
XQorICovCisjZGVmaW5lIF9HVEZfcmVhZG9ubHkgICAgICAgKDIpCisjZGVmaW5lIEdURl9yZWFk
b25seSAgICAgICAgKDFVPDxfR1RGX3JlYWRvbmx5KQorI2RlZmluZSBfR1RGX3JlYWRpbmcgICAg
ICAgICgzKQorI2RlZmluZSBHVEZfcmVhZGluZyAgICAgICAgICgxVTw8X0dURl9yZWFkaW5nKQor
I2RlZmluZSBfR1RGX3dyaXRpbmcgICAgICAgICg0KQorI2RlZmluZSBHVEZfd3JpdGluZyAgICAg
ICAgICgxVTw8X0dURl93cml0aW5nKQorI2RlZmluZSBfR1RGX3N1Yl9wYWdlICAgICAgICg4KQor
I2RlZmluZSBHVEZfc3ViX3BhZ2UgICAgICAgICgxVTw8X0dURl9zdWJfcGFnZSkKKworLyoKKyAq
IFN1YmZsYWdzIGZvciBHVEZfYWNjZXB0X3RyYW5zZmVyOgorICogIEdURl90cmFuc2Zlcl9jb21t
aXR0ZWQ6IFhlbiBzZXRzIHRoaXMgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIGNvbW1pdHRl
ZAorICogICAgICB0byB0cmFuc2ZlcnJpbmcgb3duZXJzaGlwIG9mIGEgcGFnZSBmcmFtZS4gV2hl
biBhIGd1ZXN0IHNlZXMgdGhpcyBmbGFnCisgKiAgICAgIGl0IG11c3QgL25vdC8gbW9kaWZ5IHRo
ZSBncmFudCBlbnRyeSB1bnRpbCBHVEZfdHJhbnNmZXJfY29tcGxldGVkIGlzCisgKiAgICAgIHNl
dCBieSBYZW4uCisgKiAgR1RGX3RyYW5zZmVyX2NvbXBsZXRlZDogSXQgaXMgc2FmZSBmb3IgdGhl
IGd1ZXN0IHRvIHNwaW4td2FpdCBvbiB0aGlzIGZsYWcKKyAqICAgICAgYWZ0ZXIgcmVhZGluZyBH
VEZfdHJhbnNmZXJfY29tbWl0dGVkLiBYZW4gd2lsbCBhbHdheXMgd3JpdGUgdGhlIGZyYW1lCisg
KiAgICAgIGFkZHJlc3MsIGZvbGxvd2VkIGJ5IE9SaW5nIHRoaXMgZmxhZywgaW4gYSB0aW1lbHkg
bWFubmVyLgorICovCisjZGVmaW5lIF9HVEZfdHJhbnNmZXJfY29tbWl0dGVkICgyKQorI2RlZmlu
ZSBHVEZfdHJhbnNmZXJfY29tbWl0dGVkICAoMVU8PF9HVEZfdHJhbnNmZXJfY29tbWl0dGVkKQor
I2RlZmluZSBfR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCAoMykKKyNkZWZpbmUgR1RGX3RyYW5zZmVy
X2NvbXBsZXRlZCAgKDFVPDxfR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCkKKworLyoKKyAqIFZlcnNp
b24gMiBncmFudCB0YWJsZSBlbnRyaWVzLiAgVGhlc2UgZnVsZmlsIHRoZSBzYW1lIHJvbGUgYXMK
KyAqIHZlcnNpb24gMSBlbnRyaWVzLCBidXQgY2FuIHJlcHJlc2VudCBtb3JlIGNvbXBsaWNhdGVk
IG9wZXJhdGlvbnMuCisgKiBBbnkgZ2l2ZW4gZG9tYWluIHdpbGwgaGF2ZSBlaXRoZXIgYSB2ZXJz
aW9uIDEgb3IgYSB2ZXJzaW9uIDIgdGFibGUsCisgKiBhbmQgZXZlcnkgZW50cnkgaW4gdGhlIHRh
YmxlIHdpbGwgYmUgdGhlIHNhbWUgdmVyc2lvbi4KKyAqCisgKiBUaGUgaW50ZXJmYWNlIGJ5IHdo
aWNoIGRvbWFpbnMgdXNlIGdyYW50IHJlZmVyZW5jZXMgZG9lcyBub3QgZGVwZW5kCisgKiBvbiB0
aGUgZ3JhbnQgdGFibGUgdmVyc2lvbiBpbiB1c2UgYnkgdGhlIG90aGVyIGRvbWFpbi4KKyAqLwor
CisvKgorICogVmVyc2lvbiAxIGFuZCB2ZXJzaW9uIDIgZ3JhbnQgZW50cmllcyBzaGFyZSBhIGNv
bW1vbiBwcmVmaXguICBUaGUKKyAqIGZpZWxkcyBvZiB0aGUgcHJlZml4IGFyZSBkb2N1bWVudGVk
IGFzIHBhcnQgb2Ygc3RydWN0CisgKiBncmFudF9lbnRyeV92MS4KKyAqLworc3RydWN0IGdyYW50
X2VudHJ5X2hlYWRlciB7CisgICAgdWludDE2X3QgZmxhZ3M7CisgICAgZG9taWRfdCAgZG9taWQ7
Cit9OworCisvKgorICogVmVyc2lvbiAyIG9mIHRoZSBncmFudCBlbnRyeSBzdHJ1Y3R1cmUsIGhl
cmUgaXMgYW4gdW5pb24gYmVjYXVzZSB0aHJlZQorICogZGlmZmVyZW50IHR5cGVzIGFyZSBzdXBw
b3R0ZWQ6IGZ1bGxfcGFnZSwgc3ViX3BhZ2UgYW5kIHRyYW5zaXRpdmUuCisgKi8KK3VuaW9uIGdy
YW50X2VudHJ5X3YyIHsKKyAgICBzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIGhkcjsKKworICAg
IC8qCisgICAgICogVGhpcyBtZW1iZXIgaXMgdXNlZCBmb3IgVjEtc3R5bGUgZnVsbCBwYWdlIGdy
YW50cywgd2hlcmUgZWl0aGVyOgorICAgICAqCisgICAgICogLS0gaGRyLnR5cGUgaXMgR1RGX2Fj
Y2VwdF90cmFuc2Zlciwgb3IKKyAgICAgKiAtLSBoZHIudHlwZSBpcyBHVEZfcGVybWl0X2FjY2Vz
cyBhbmQgR1RGX3N1Yl9wYWdlIGlzIG5vdCBzZXQuCisgICAgICoKKyAgICAgKiBJbiB0aGF0IGNh
c2UsIHRoZSBmcmFtZSBmaWVsZCBoYXMgdGhlIHNhbWUgc2VtYW50aWNzIGFzIHRoZQorICAgICAq
IGZpZWxkIG9mIHRoZSBzYW1lIG5hbWUgaW4gdGhlIFYxIGVudHJ5IHN0cnVjdHVyZS4KKyAgICAg
Ki8KKyAgICBzdHJ1Y3QgeworCXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCXVpbnQz
Ml90IHBhZDA7CisJdWludDY0X3QgZnJhbWU7CisgICAgfSBmdWxsX3BhZ2U7CisKKyAgICAvKgor
ICAgICAqIElmIHRoZSBncmFudCB0eXBlIGlzIEdURl9ncmFudF9hY2Nlc3MgYW5kIEdURl9zdWJf
cGFnZSBpcyBzZXQsCisgICAgICogQGRvbWlkIGlzIGFsbG93ZWQgdG8gYWNjZXNzIGJ5dGVzIFtA
cGFnZV9vZmYsQHBhZ2Vfb2ZmK0BsZW5ndGgpCisgICAgICogaW4gZnJhbWUgQGZyYW1lLgorICAg
ICAqLworICAgIHN0cnVjdCB7CisJc3RydWN0IGdyYW50X2VudHJ5X2hlYWRlciBoZHI7CisJdWlu
dDE2X3QgcGFnZV9vZmY7CisJdWludDE2X3QgbGVuZ3RoOworCXVpbnQ2NF90IGZyYW1lOworICAg
IH0gc3ViX3BhZ2U7CisKKyAgICAvKgorICAgICAqIElmIHRoZSBncmFudCBpcyBHVEZfdHJhbnNp
dGl2ZSwgQGRvbWlkIGlzIGFsbG93ZWQgdG8gdXNlIHRoZQorICAgICAqIGdyYW50IEBncmVmIGlu
IGRvbWFpbiBAdHJhbnNfZG9taWQsIGFzIGlmIGl0IHdhcyB0aGUgbG9jYWwKKyAgICAgKiBkb21h
aW4uICBPYnZpb3VzbHksIHRoZSB0cmFuc2l0aXZlIGFjY2VzcyBtdXN0IGJlIGNvbXBhdGlibGUK
KyAgICAgKiB3aXRoIHRoZSBvcmlnaW5hbCBncmFudC4KKyAgICAgKi8KKyAgICBzdHJ1Y3Qgewor
CXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCWRvbWlkX3QgdHJhbnNfZG9taWQ7CisJ
dWludDE2X3QgcGFkMDsKKwlncmFudF9yZWZfdCBncmVmOworICAgIH0gdHJhbnNpdGl2ZTsKKwor
ICAgIHVpbnQzMl90IF9fc3BhY2VyWzRdOyAvKiBQYWQgdG8gYSBwb3dlciBvZiB0d28gKi8KK307
CisKK3R5cGVkZWYgdWludDE2X3QgZ3JhbnRfc3RhdHVzX3Q7CisKKy8qKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKgorICogR1JBTlQgVEFCTEUgUVVFUklFUyBBTkQgVVNFUworICov
CisKKy8qCisgKiBIYW5kbGUgdG8gdHJhY2sgYSBtYXBwaW5nIGNyZWF0ZWQgdmlhIGEgZ3JhbnQg
cmVmZXJlbmNlLgorICovCit0eXBlZGVmIHVpbnQzMl90IGdyYW50X2hhbmRsZV90OworCisvKgor
ICogR05UVEFCT1BfbWFwX2dyYW50X3JlZjogTWFwIHRoZSBncmFudCBlbnRyeSAoPGRvbT4sPHJl
Zj4pIGZvciBhY2Nlc3MKKyAqIGJ5IGRldmljZXMgYW5kL29yIGhvc3QgQ1BVcy4gSWYgc3VjY2Vz
c2Z1bCwgPGhhbmRsZT4gaXMgYSB0cmFja2luZyBudW1iZXIKKyAqIHRoYXQgbXVzdCBiZSBwcmVz
ZW50ZWQgbGF0ZXIgdG8gZGVzdHJveSB0aGUgbWFwcGluZyhzKS4gT24gZXJyb3IsIDxoYW5kbGU+
CisgKiBpcyBhIG5lZ2F0aXZlIHN0YXR1cyBjb2RlLgorICogTk9URVM6CisgKiAgMS4gSWYgR05U
TUFQX2RldmljZV9tYXAgaXMgc3BlY2lmaWVkIHRoZW4gPGRldl9idXNfYWRkcj4gaXMgdGhlIGFk
ZHJlc3MKKyAqICAgICB2aWEgd2hpY2ggSS9PIGRldmljZXMgbWF5IGFjY2VzcyB0aGUgZ3JhbnRl
ZCBmcmFtZS4KKyAqICAyLiBJZiBHTlRNQVBfaG9zdF9tYXAgaXMgc3BlY2lmaWVkIHRoZW4gYSBt
YXBwaW5nIHdpbGwgYmUgYWRkZWQgYXQKKyAqICAgICBlaXRoZXIgYSBob3N0IHZpcnR1YWwgYWRk
cmVzcyBpbiB0aGUgY3VycmVudCBhZGRyZXNzIHNwYWNlLCBvciBhdAorICogICAgIGEgUFRFIGF0
IHRoZSBzcGVjaWZpZWQgbWFjaGluZSBhZGRyZXNzLiAgVGhlIHR5cGUgb2YgbWFwcGluZyB0bwor
ICogICAgIHBlcmZvcm0gaXMgc2VsZWN0ZWQgdGhyb3VnaCB0aGUgR05UTUFQX2NvbnRhaW5zX3B0
ZSBmbGFnLCBhbmQgdGhlCisgKiAgICAgYWRkcmVzcyBpcyBzcGVjaWZpZWQgaW4gPGhvc3RfYWRk
cj4uCisgKiAgMy4gTWFwcGluZ3Mgc2hvdWxkIG9ubHkgYmUgZGVzdHJveWVkIHZpYSBHTlRUQUJP
UF91bm1hcF9ncmFudF9yZWYuIElmIGEKKyAqICAgICBob3N0IG1hcHBpbmcgaXMgZGVzdHJveWVk
IGJ5IG90aGVyIG1lYW5zIHRoZW4gaXQgaXMgKk5PVCogZ3VhcmFudGVlZAorICogICAgIHRvIGJl
IGFjY291bnRlZCB0byB0aGUgY29ycmVjdCBncmFudCByZWZlcmVuY2UhCisgKi8KKyNkZWZpbmUg
R05UVEFCT1BfbWFwX2dyYW50X3JlZiAgICAgICAgMAorc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRf
cmVmIHsKKyAgICAvKiBJTiBwYXJhbWV0ZXJzLiAqLworICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsK
KyAgICB1aW50MzJfdCBmbGFnczsgICAgICAgICAgICAgICAvKiBHTlRNQVBfKiAqLworICAgIGdy
YW50X3JlZl90IHJlZjsKKyAgICBkb21pZF90ICBkb207CisgICAgLyogT1VUIHBhcmFtZXRlcnMu
ICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLworICAg
IGdyYW50X2hhbmRsZV90IGhhbmRsZTsKKyAgICB1aW50NjRfdCBkZXZfYnVzX2FkZHI7Cit9Owor
REVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX21hcF9ncmFudF9yZWYpOworCisvKgor
ICogR05UVEFCT1BfdW5tYXBfZ3JhbnRfcmVmOiBEZXN0cm95IG9uZSBvciBtb3JlIGdyYW50LXJl
ZmVyZW5jZSBtYXBwaW5ncworICogdHJhY2tlZCBieSA8aGFuZGxlPi4gSWYgPGhvc3RfYWRkcj4g
b3IgPGRldl9idXNfYWRkcj4gaXMgemVybywgdGhhdAorICogZmllbGQgaXMgaWdub3JlZC4gSWYg
bm9uLXplcm8sIHRoZXkgbXVzdCByZWZlciB0byBhIGRldmljZS9ob3N0IG1hcHBpbmcKKyAqIHRo
YXQgaXMgdHJhY2tlZCBieSA8aGFuZGxlPgorICogTk9URVM6CisgKiAgMS4gVGhlIGNhbGwgbWF5
IGZhaWwgaW4gYW4gdW5kZWZpbmVkIG1hbm5lciBpZiBlaXRoZXIgbWFwcGluZyBpcyBub3QKKyAq
ICAgICB0cmFja2VkIGJ5IDxoYW5kbGU+LgorICogIDMuIEFmdGVyIGV4ZWN1dGluZyBhIGJhdGNo
IG9mIHVubWFwcywgaXQgaXMgZ3VhcmFudGVlZCB0aGF0IG5vIHN0YWxlCisgKiAgICAgbWFwcGlu
Z3Mgd2lsbCByZW1haW4gaW4gdGhlIGRldmljZSBvciBob3N0IFRMQnMuCisgKi8KKyNkZWZpbmUg
R05UVEFCT1BfdW5tYXBfZ3JhbnRfcmVmICAgICAgMQorc3RydWN0IGdudHRhYl91bm1hcF9ncmFu
dF9yZWYgeworICAgIC8qIElOIHBhcmFtZXRlcnMuICovCisgICAgdWludDY0X3QgaG9zdF9hZGRy
OworICAgIHVpbnQ2NF90IGRldl9idXNfYWRkcjsKKyAgICBncmFudF9oYW5kbGVfdCBoYW5kbGU7
CisgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAg
ICAgICAgLyogR05UU1RfKiAqLworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRh
Yl91bm1hcF9ncmFudF9yZWYpOworCisvKgorICogR05UVEFCT1Bfc2V0dXBfdGFibGU6IFNldCB1
cCBhIGdyYW50IHRhYmxlIGZvciA8ZG9tPiBjb21wcmlzaW5nIGF0IGxlYXN0CisgKiA8bnJfZnJh
bWVzPiBwYWdlcy4gVGhlIGZyYW1lIGFkZHJlc3NlcyBhcmUgd3JpdHRlbiB0byB0aGUgPGZyYW1l
X2xpc3Q+LgorICogT25seSA8bnJfZnJhbWVzPiBhZGRyZXNzZXMgYXJlIHdyaXR0ZW4sIGV2ZW4g
aWYgdGhlIHRhYmxlIGlzIGxhcmdlci4KKyAqIE5PVEVTOgorICogIDEuIDxkb20+IG1heSBiZSBz
cGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KKyAqICAyLiBPbmx5IGEgc3VmZmljaWVudGx5LXByaXZp
bGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NFTEYuCisgKiAgMy4gWGVu
IG1heSBub3Qgc3VwcG9ydCBtb3JlIHRoYW4gYSBzaW5nbGUgZ3JhbnQtdGFibGUgcGFnZSBwZXIg
ZG9tYWluLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3NldHVwX3RhYmxlICAgICAgICAgIDIKK3N0
cnVjdCBnbnR0YWJfc2V0dXBfdGFibGUgeworICAgIC8qIElOIHBhcmFtZXRlcnMuICovCisgICAg
ZG9taWRfdCAgZG9tOworICAgIHVpbnQzMl90IG5yX2ZyYW1lczsKKyAgICAvKiBPVVQgcGFyYW1l
dGVycy4gKi8KKyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAgICAvKiBHTlRTVF8qICov
CisgICAgR1VFU1RfSEFORExFKHVsb25nKSBmcmFtZV9saXN0OworfTsKK0RFRklORV9HVUVTVF9I
QU5ETEVfU1RSVUNUKGdudHRhYl9zZXR1cF90YWJsZSk7CisKKy8qCisgKiBHTlRUQUJPUF9kdW1w
X3RhYmxlOiBEdW1wIHRoZSBjb250ZW50cyBvZiB0aGUgZ3JhbnQgdGFibGUgdG8gdGhlCisgKiB4
ZW4gY29uc29sZS4gRGVidWdnaW5nIHVzZSBvbmx5LgorICovCisjZGVmaW5lIEdOVFRBQk9QX2R1
bXBfdGFibGUgICAgICAgICAgIDMKK3N0cnVjdCBnbnR0YWJfZHVtcF90YWJsZSB7CisgICAgLyog
SU4gcGFyYW1ldGVycy4gKi8KKyAgICBkb21pZF90IGRvbTsKKyAgICAvKiBPVVQgcGFyYW1ldGVy
cy4gKi8KKyAgICBpbnQxNl90IHN0YXR1czsgICAgICAgICAgICAgICAvKiBHTlRTVF8qICovCit9
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2R1bXBfdGFibGUpOworCisvKgor
ICogR05UVEFCT1BfdHJhbnNmZXJfZ3JhbnRfcmVmOiBUcmFuc2ZlciA8ZnJhbWU+IHRvIGEgZm9y
ZWlnbiBkb21haW4uIFRoZQorICogZm9yZWlnbiBkb21haW4gaGFzIHByZXZpb3VzbHkgcmVnaXN0
ZXJlZCBpdHMgaW50ZXJlc3QgaW4gdGhlIHRyYW5zZmVyIHZpYQorICogPGRvbWlkLCByZWY+Lgor
ICoKKyAqIE5vdGUgdGhhdCwgZXZlbiBpZiB0aGUgdHJhbnNmZXIgZmFpbHMsIHRoZSBzcGVjaWZp
ZWQgcGFnZSBubyBsb25nZXIgYmVsb25ncworICogdG8gdGhlIGNhbGxpbmcgZG9tYWluICp1bmxl
c3MqIHRoZSBlcnJvciBpcyBHTlRTVF9iYWRfcGFnZS4KKyAqLworI2RlZmluZSBHTlRUQUJPUF90
cmFuc2ZlciAgICAgICAgICAgICAgICA0CitzdHJ1Y3QgZ250dGFiX3RyYW5zZmVyIHsKKyAgICAv
KiBJTiBwYXJhbWV0ZXJzLiAqLworICAgIHVuc2lnbmVkIGxvbmcgbWZuOworICAgIGRvbWlkX3Qg
ICAgICAgZG9taWQ7CisgICAgZ3JhbnRfcmVmX3QgICByZWY7CisgICAgLyogT1VUIHBhcmFtZXRl
cnMuICovCisgICAgaW50MTZfdCAgICAgICBzdGF0dXM7Cit9OworREVGSU5FX0dVRVNUX0hBTkRM
RV9TVFJVQ1QoZ250dGFiX3RyYW5zZmVyKTsKKworLyoKKyAqIEdOVFRBQk9QX2NvcHk6IEh5cGVy
dmlzb3IgYmFzZWQgY29weQorICogc291cmNlIGFuZCBkZXN0aW5hdGlvbnMgY2FuIGJlIGVpdGhl
cnMgTUZOcyBvciwgZm9yIGZvcmVpZ24gZG9tYWlucywKKyAqIGdyYW50IHJlZmVyZW5jZXMuIHRo
ZSBmb3JlaWduIGRvbWFpbiBoYXMgdG8gZ3JhbnQgcmVhZC93cml0ZSBhY2Nlc3MKKyAqIGluIGl0
cyBncmFudCB0YWJsZS4KKyAqCisgKiBUaGUgZmxhZ3Mgc3BlY2lmeSB3aGF0IHR5cGUgc291cmNl
IGFuZCBkZXN0aW5hdGlvbnMgYXJlIChlaXRoZXIgTUZOCisgKiBvciBncmFudCByZWZlcmVuY2Up
LgorICoKKyAqIE5vdGUgdGhhdCB0aGlzIGNhbiBhbHNvIGJlIHVzZWQgdG8gY29weSBkYXRhIGJl
dHdlZW4gdHdvIGRvbWFpbnMKKyAqIHZpYSBhIHRoaXJkIHBhcnR5IGlmIHRoZSBzb3VyY2UgYW5k
IGRlc3RpbmF0aW9uIGRvbWFpbnMgaGFkIHByZXZpb3VzbHkKKyAqIGdyYW50IGFwcHJvcHJpYXRl
IGFjY2VzcyB0byB0aGVpciBwYWdlcyB0byB0aGUgdGhpcmQgcGFydHkuCisgKgorICogc291cmNl
X29mZnNldCBzcGVjaWZpZXMgYW4gb2Zmc2V0IGluIHRoZSBzb3VyY2UgZnJhbWUsIGRlc3Rfb2Zm
c2V0CisgKiB0aGUgb2Zmc2V0IGluIHRoZSB0YXJnZXQgZnJhbWUgYW5kICBsZW4gc3BlY2lmaWVz
IHRoZSBudW1iZXIgb2YKKyAqIGJ5dGVzIHRvIGJlIGNvcGllZC4KKyAqLworCisjZGVmaW5lIF9H
TlRDT1BZX3NvdXJjZV9ncmVmICAgICAgKDApCisjZGVmaW5lIEdOVENPUFlfc291cmNlX2dyZWYg
ICAgICAgKDE8PF9HTlRDT1BZX3NvdXJjZV9ncmVmKQorI2RlZmluZSBfR05UQ09QWV9kZXN0X2dy
ZWYgICAgICAgICgxKQorI2RlZmluZSBHTlRDT1BZX2Rlc3RfZ3JlZiAgICAgICAgICgxPDxfR05U
Q09QWV9kZXN0X2dyZWYpCisKKyNkZWZpbmUgR05UVEFCT1BfY29weSAgICAgICAgICAgICAgICAg
NQorc3RydWN0IGdudHRhYl9jb3B5IHsKKwkvKiBJTiBwYXJhbWV0ZXJzLiAqLworCXN0cnVjdCB7
CisJCXVuaW9uIHsKKwkJCWdyYW50X3JlZl90IHJlZjsKKwkJCXVuc2lnbmVkIGxvbmcgICBnbWZu
OworCQl9IHU7CisJCWRvbWlkX3QgIGRvbWlkOworCQl1aW50MTZfdCBvZmZzZXQ7CisJfSBzb3Vy
Y2UsIGRlc3Q7CisJdWludDE2X3QgICAgICBsZW47CisJdWludDE2X3QgICAgICBmbGFnczsgICAg
ICAgICAgLyogR05UQ09QWV8qICovCisJLyogT1VUIHBhcmFtZXRlcnMuICovCisJaW50MTZfdCAg
ICAgICBzdGF0dXM7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX2NvcHkp
OworCisvKgorICogR05UVEFCT1BfcXVlcnlfc2l6ZTogUXVlcnkgdGhlIGN1cnJlbnQgYW5kIG1h
eGltdW0gc2l6ZXMgb2YgdGhlIHNoYXJlZAorICogZ3JhbnQgdGFibGUuCisgKiBOT1RFUzoKKyAq
ICAxLiA8ZG9tPiBtYXkgYmUgc3BlY2lmaWVkIGFzIERPTUlEX1NFTEYuCisgKiAgMi4gT25seSBh
IHN1ZmZpY2llbnRseS1wcml2aWxlZ2VkIGRvbWFpbiBtYXkgc3BlY2lmeSA8ZG9tPiAhPSBET01J
RF9TRUxGLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3F1ZXJ5X3NpemUgICAgICAgICAgIDYKK3N0
cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSB7CisgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICBk
b21pZF90ICBkb207CisgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCisgICAgdWludDMyX3QgbnJf
ZnJhbWVzOworICAgIHVpbnQzMl90IG1heF9ucl9mcmFtZXM7CisgICAgaW50MTZfdCAgc3RhdHVz
OyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RS
VUNUKGdudHRhYl9xdWVyeV9zaXplKTsKKworLyoKKyAqIEdOVFRBQk9QX3VubWFwX2FuZF9yZXBs
YWNlOiBEZXN0cm95IG9uZSBvciBtb3JlIGdyYW50LXJlZmVyZW5jZSBtYXBwaW5ncworICogdHJh
Y2tlZCBieSA8aGFuZGxlPiBidXQgYXRvbWljYWxseSByZXBsYWNlIHRoZSBwYWdlIHRhYmxlIGVu
dHJ5IHdpdGggb25lCisgKiBwb2ludGluZyB0byB0aGUgbWFjaGluZSBhZGRyZXNzIHVuZGVyIDxu
ZXdfYWRkcj4uICA8bmV3X2FkZHI+IHdpbGwgYmUKKyAqIHJlZGlyZWN0ZWQgdG8gdGhlIG51bGwg
ZW50cnkuCisgKiBOT1RFUzoKKyAqICAxLiBUaGUgY2FsbCBtYXkgZmFpbCBpbiBhbiB1bmRlZmlu
ZWQgbWFubmVyIGlmIGVpdGhlciBtYXBwaW5nIGlzIG5vdAorICogICAgIHRyYWNrZWQgYnkgPGhh
bmRsZT4uCisgKiAgMi4gQWZ0ZXIgZXhlY3V0aW5nIGEgYmF0Y2ggb2YgdW5tYXBzLCBpdCBpcyBn
dWFyYW50ZWVkIHRoYXQgbm8gc3RhbGUKKyAqICAgICBtYXBwaW5ncyB3aWxsIHJlbWFpbiBpbiB0
aGUgZGV2aWNlIG9yIGhvc3QgVExCcy4KKyAqLworI2RlZmluZSBHTlRUQUJPUF91bm1hcF9hbmRf
cmVwbGFjZSAgICA3CitzdHJ1Y3QgZ250dGFiX3VubWFwX2FuZF9yZXBsYWNlIHsKKyAgICAvKiBJ
TiBwYXJhbWV0ZXJzLiAqLworICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsKKyAgICB1aW50NjRfdCBu
ZXdfYWRkcjsKKyAgICBncmFudF9oYW5kbGVfdCBoYW5kbGU7CisgICAgLyogT1VUIHBhcmFtZXRl
cnMuICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLwor
fTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl91bm1hcF9hbmRfcmVwbGFjZSk7
CisKKy8qCisgKiBHTlRUQUJPUF9zZXRfdmVyc2lvbjogUmVxdWVzdCBhIHBhcnRpY3VsYXIgdmVy
c2lvbiBvZiB0aGUgZ3JhbnQKKyAqIHRhYmxlIHNoYXJlZCB0YWJsZSBzdHJ1Y3R1cmUuICBUaGlz
IG9wZXJhdGlvbiBjYW4gb25seSBiZSBwZXJmb3JtZWQKKyAqIG9uY2UgaW4gYW55IGdpdmVuIGRv
bWFpbi4gIEl0IG11c3QgYmUgcGVyZm9ybWVkIGJlZm9yZSBhbnkgZ3JhbnRzCisgKiBhcmUgYWN0
aXZhdGVkOyBvdGhlcndpc2UsIHRoZSBkb21haW4gd2lsbCBiZSBzdHVjayB3aXRoIHZlcnNpb24g
MS4KKyAqIFRoZSBvbmx5IGRlZmluZWQgdmVyc2lvbnMgYXJlIDEgYW5kIDIuCisgKi8KKyNkZWZp
bmUgR05UVEFCT1Bfc2V0X3ZlcnNpb24gICAgICAgICAgOAorc3RydWN0IGdudHRhYl9zZXRfdmVy
c2lvbiB7CisgICAgLyogSU4gcGFyYW1ldGVycyAqLworICAgIHVpbnQzMl90IHZlcnNpb247Cit9
OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250dGFiX3NldF92ZXJzaW9uKTsKKworLyoK
KyAqIEdOVFRBQk9QX2dldF9zdGF0dXNfZnJhbWVzOiBHZXQgdGhlIGxpc3Qgb2YgZnJhbWVzIHVz
ZWQgdG8gc3RvcmUgZ3JhbnQKKyAqIHN0YXR1cyBmb3IgPGRvbT4uIEluIGdyYW50IGZvcm1hdCB2
ZXJzaW9uIDIsIHRoZSBzdGF0dXMgaXMgc2VwYXJhdGVkCisgKiBmcm9tIHRoZSBvdGhlciBzaGFy
ZWQgZ3JhbnQgZmllbGRzIHRvIGFsbG93IG1vcmUgZWZmaWNpZW50IHN5bmNocm9uaXphdGlvbgor
ICogdXNpbmcgYmFycmllcnMgaW5zdGVhZCBvZiBhdG9taWMgY21wZXhjaCBvcGVyYXRpb25zLgor
ICogPG5yX2ZyYW1lcz4gc3BlY2lmeSB0aGUgc2l6ZSBvZiB2ZWN0b3IgPGZyYW1lX2xpc3Q+Lgor
ICogVGhlIGZyYW1lIGFkZHJlc3NlcyBhcmUgcmV0dXJuZWQgaW4gdGhlIDxmcmFtZV9saXN0Pi4K
KyAqIE9ubHkgPG5yX2ZyYW1lcz4gYWRkcmVzc2VzIGFyZSByZXR1cm5lZCwgZXZlbiBpZiB0aGUg
dGFibGUgaXMgbGFyZ2VyLgorICogTk9URVM6CisgKiAgMS4gPGRvbT4gbWF5IGJlIHNwZWNpZmll
ZCBhcyBET01JRF9TRUxGLgorICogIDIuIE9ubHkgYSBzdWZmaWNpZW50bHktcHJpdmlsZWdlZCBk
b21haW4gbWF5IHNwZWNpZnkgPGRvbT4gIT0gRE9NSURfU0VMRi4KKyAqLworI2RlZmluZSBHTlRU
QUJPUF9nZXRfc3RhdHVzX2ZyYW1lcyAgICAgOQorc3RydWN0IGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lcyB7CisgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICB1aW50MzJfdCBucl9mcmFtZXM7
CisgICAgZG9taWRfdCAgZG9tOworICAgIC8qIE9VVCBwYXJhbWV0ZXJzLiAqLworICAgIGludDE2
X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8qIEdOVFNUXyogKi8KKyAgICBHVUVTVF9IQU5ETEUo
dWludDY0X3QpIGZyYW1lX2xpc3Q7Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoZ250
dGFiX2dldF9zdGF0dXNfZnJhbWVzKTsKKworLyoKKyAqIEdOVFRBQk9QX2dldF92ZXJzaW9uOiBH
ZXQgdGhlIGdyYW50IHRhYmxlIHZlcnNpb24gd2hpY2ggaXMgaW4KKyAqIGVmZmVjdCBmb3IgZG9t
YWluIDxkb20+LgorICovCisjZGVmaW5lIEdOVFRBQk9QX2dldF92ZXJzaW9uICAgICAgICAgIDEw
CitzdHJ1Y3QgZ250dGFiX2dldF92ZXJzaW9uIHsKKyAgICAvKiBJTiBwYXJhbWV0ZXJzICovCisg
ICAgZG9taWRfdCBkb207CisgICAgdWludDE2X3QgcGFkOworICAgIC8qIE9VVCBwYXJhbWV0ZXJz
ICovCisgICAgdWludDMyX3QgdmVyc2lvbjsKK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVD
VChnbnR0YWJfZ2V0X3ZlcnNpb24pOworCisvKgorICogQml0ZmllbGQgdmFsdWVzIGZvciB1cGRh
dGVfcGluX3N0YXR1cy5mbGFncy4KKyAqLworIC8qIE1hcCB0aGUgZ3JhbnQgZW50cnkgZm9yIGFj
Y2VzcyBieSBJL08gZGV2aWNlcy4gKi8KKyNkZWZpbmUgX0dOVE1BUF9kZXZpY2VfbWFwICAgICAg
KDApCisjZGVmaW5lIEdOVE1BUF9kZXZpY2VfbWFwICAgICAgICgxPDxfR05UTUFQX2RldmljZV9t
YXApCisgLyogTWFwIHRoZSBncmFudCBlbnRyeSBmb3IgYWNjZXNzIGJ5IGhvc3QgQ1BVcy4gKi8K
KyNkZWZpbmUgX0dOVE1BUF9ob3N0X21hcCAgICAgICAgKDEpCisjZGVmaW5lIEdOVE1BUF9ob3N0
X21hcCAgICAgICAgICgxPDxfR05UTUFQX2hvc3RfbWFwKQorIC8qIEFjY2Vzc2VzIHRvIHRoZSBn
cmFudGVkIGZyYW1lIHdpbGwgYmUgcmVzdHJpY3RlZCB0byByZWFkLW9ubHkgYWNjZXNzLiAqLwor
I2RlZmluZSBfR05UTUFQX3JlYWRvbmx5ICAgICAgICAoMikKKyNkZWZpbmUgR05UTUFQX3JlYWRv
bmx5ICAgICAgICAgKDE8PF9HTlRNQVBfcmVhZG9ubHkpCisgLyoKKyAgKiBHTlRNQVBfaG9zdF9t
YXAgc3ViZmxhZzoKKyAgKiAgMCA9PiBUaGUgaG9zdCBtYXBwaW5nIGlzIHVzYWJsZSBvbmx5IGJ5
IHRoZSBndWVzdCBPUy4KKyAgKiAgMSA9PiBUaGUgaG9zdCBtYXBwaW5nIGlzIHVzYWJsZSBieSBn
dWVzdCBPUyArIGN1cnJlbnQgYXBwbGljYXRpb24uCisgICovCisjZGVmaW5lIF9HTlRNQVBfYXBw
bGljYXRpb25fbWFwICgzKQorI2RlZmluZSBHTlRNQVBfYXBwbGljYXRpb25fbWFwICAoMTw8X0dO
VE1BUF9hcHBsaWNhdGlvbl9tYXApCisKKyAvKgorICAqIEdOVE1BUF9jb250YWluc19wdGUgc3Vi
ZmxhZzoKKyAgKiAgMCA9PiBUaGlzIG1hcCByZXF1ZXN0IGNvbnRhaW5zIGEgaG9zdCB2aXJ0dWFs
IGFkZHJlc3MuCisgICogIDEgPT4gVGhpcyBtYXAgcmVxdWVzdCBjb250YWlucyB0aGUgbWFjaGlu
ZSBhZGRlc3Mgb2YgdGhlIFBURSB0byB1cGRhdGUuCisgICovCisjZGVmaW5lIF9HTlRNQVBfY29u
dGFpbnNfcHRlICAgICg0KQorI2RlZmluZSBHTlRNQVBfY29udGFpbnNfcHRlICAgICAoMTw8X0dO
VE1BUF9jb250YWluc19wdGUpCisKKy8qCisgKiBWYWx1ZXMgZm9yIGVycm9yIHN0YXR1cyByZXR1
cm5zLiBBbGwgZXJyb3JzIGFyZSAtdmUuCisgKi8KKyNkZWZpbmUgR05UU1Rfb2theSAgICAgICAg
ICAgICAoMCkgIC8qIE5vcm1hbCByZXR1cm4uICAgICAgICAgICAgICAgICAgICAgICAgKi8KKyNk
ZWZpbmUgR05UU1RfZ2VuZXJhbF9lcnJvciAgICAoLTEpIC8qIEdlbmVyYWwgdW5kZWZpbmVkIGVy
cm9yLiAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgR05UU1RfYmFkX2RvbWFpbiAgICAgICAoLTIp
IC8qIFVucmVjb2duc2VkIGRvbWFpbiBpZC4gICAgICAgICAgICAgICAgKi8KKyNkZWZpbmUgR05U
U1RfYmFkX2dudHJlZiAgICAgICAoLTMpIC8qIFVucmVjb2duaXNlZCBvciBpbmFwcHJvcHJpYXRl
IGdudHJlZi4gKi8KKyNkZWZpbmUgR05UU1RfYmFkX2hhbmRsZSAgICAgICAoLTQpIC8qIFVucmVj
b2duaXNlZCBvciBpbmFwcHJvcHJpYXRlIGhhbmRsZS4gKi8KKyNkZWZpbmUgR05UU1RfYmFkX3Zp
cnRfYWRkciAgICAoLTUpIC8qIEluYXBwcm9wcmlhdGUgdmlydHVhbCBhZGRyZXNzIHRvIG1hcC4g
Ki8KKyNkZWZpbmUgR05UU1RfYmFkX2Rldl9hZGRyICAgICAoLTYpIC8qIEluYXBwcm9wcmlhdGUg
ZGV2aWNlIGFkZHJlc3MgdG8gdW5tYXAuKi8KKyNkZWZpbmUgR05UU1Rfbm9fZGV2aWNlX3NwYWNl
ICAoLTcpIC8qIE91dCBvZiBzcGFjZSBpbiBJL08gTU1VLiAgICAgICAgICAgICAgKi8KKyNkZWZp
bmUgR05UU1RfcGVybWlzc2lvbl9kZW5pZWQgKC04KSAvKiBOb3QgZW5vdWdoIHByaXZpbGVnZSBm
b3Igb3BlcmF0aW9uLiAgKi8KKyNkZWZpbmUgR05UU1RfYmFkX3BhZ2UgICAgICAgICAoLTkpIC8q
IFNwZWNpZmllZCBwYWdlIHdhcyBpbnZhbGlkIGZvciBvcC4gICAgKi8KKyNkZWZpbmUgR05UU1Rf
YmFkX2NvcHlfYXJnICAgICgtMTApIC8qIGNvcHkgYXJndW1lbnRzIGNyb3NzIHBhZ2UgYm91bmRh
cnkgKi8KKworI2RlZmluZSBHTlRUQUJPUF9lcnJvcl9tc2dzIHsgICAgICAgICAgICAgICAgICAg
XAorICAgICJva2F5IiwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICJ1bmRlZmluZWQgZXJyb3IiLCAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICJ1bnJl
Y29nbmlzZWQgZG9tYWluIGlkIiwgICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIGdy
YW50IHJlZmVyZW5jZSIsICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIG1hcHBpbmcg
aGFuZGxlIiwgICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIHZpcnR1YWwgYWRkcmVz
cyIsICAgICAgICAgICAgICAgICAgXAorICAgICJpbnZhbGlkIGRldmljZSBhZGRyZXNzIiwgICAg
ICAgICAgICAgICAgICAgXAorICAgICJubyBzcGFyZSB0cmFuc2xhdGlvbiBzbG90IGluIHRoZSBJ
L08gTU1VIiwgXAorICAgICJwZXJtaXNzaW9uIGRlbmllZCIsICAgICAgICAgICAgICAgICAgICAg
ICAgXAorICAgICJiYWQgcGFnZSIsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICJjb3B5IGFyZ3VtZW50cyBjcm9zcyBwYWdlIGJvdW5kYXJ5IiAgICAgICAgXAorfQorCisj
ZW5kaWYgLyogX19YRU5fUFVCTElDX0dSQU5UX1RBQkxFX0hfXyAqLwpkaWZmIC1ydXBOIHhlbi9p
bmNsdWRlL3hlbi9pbnRlcmZhY2UvaW8vdnNjc2lpZi5oIHhlbmMvaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL2lvL3ZzY3NpaWYuaAotLS0geGVuL2luY2x1ZGUveGVuL2ludGVyZmFjZS9pby92c2NzaWlm
LmgJMTk2OS0xMi0zMSAxNzowMDowMC4wMDAwMDAwMDAgLTA3MDAKKysrIHhlbmMvaW5jbHVkZS94
ZW4vaW50ZXJmYWNlL2lvL3ZzY3NpaWYuaAkyMDEyLTAyLTI0IDE1OjE5OjM1LjMzODk3ODI4NSAt
MDcwMApAQCAtMCwwICsxLDEwNSBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogdnNjc2lp
Zi5oCisgKgorICogQmFzZWQgb24gdGhlIGJsa2lmLmggY29kZS4KKyAqCisgKiBQZXJtaXNzaW9u
IGlzIGhlcmVieSBncmFudGVkLCBmcmVlIG9mIGNoYXJnZSwgdG8gYW55IHBlcnNvbiBvYnRhaW5p
bmcgYSBjb3B5CisgKiBvZiB0aGlzIHNvZnR3YXJlIGFuZCBhc3NvY2lhdGVkIGRvY3VtZW50YXRp
b24gZmlsZXMgKHRoZSAiU29mdHdhcmUiKSwgdG8KKyAqIGRlYWwgaW4gdGhlIFNvZnR3YXJlIHdp
dGhvdXQgcmVzdHJpY3Rpb24sIGluY2x1ZGluZyB3aXRob3V0IGxpbWl0YXRpb24gdGhlCisgKiBy
aWdodHMgdG8gdXNlLCBjb3B5LCBtb2RpZnksIG1lcmdlLCBwdWJsaXNoLCBkaXN0cmlidXRlLCBz
dWJsaWNlbnNlLCBhbmQvb3IKKyAqIHNlbGwgY29waWVzIG9mIHRoZSBTb2Z0d2FyZSwgYW5kIHRv
IHBlcm1pdCBwZXJzb25zIHRvIHdob20gdGhlIFNvZnR3YXJlIGlzCisgKiBmdXJuaXNoZWQgdG8g
ZG8gc28sIHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOgorICoKKyAqIFRoZSBh
Ym92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIHNoYWxsIGJl
IGluY2x1ZGVkIGluCisgKiBhbGwgY29waWVzIG9yIHN1YnN0YW50aWFsIHBvcnRpb25zIG9mIHRo
ZSBTb2Z0d2FyZS4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiwgV0lU
SE9VVCBXQVJSQU5UWSBPRiBBTlkgS0lORCwgRVhQUkVTUyBPUgorICogSU1QTElFRCwgSU5DTFVE
SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFks
CisgKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5U
LiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUKKyAqIEFVVEhPUlMgT1IgQ09QWVJJR0hUIEhPTERFUlMg
QkUgTElBQkxFIEZPUiBBTlkgQ0xBSU0sIERBTUFHRVMgT1IgT1RIRVIKKyAqIExJQUJJTElUWSwg
V0hFVEhFUiBJTiBBTiBBQ1RJT04gT0YgQ09OVFJBQ1QsIFRPUlQgT1IgT1RIRVJXSVNFLCBBUklT
SU5HCisgKiBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBTT0ZUV0FSRSBP
UiBUSEUgVVNFIE9SIE9USEVSCisgKiBERUFMSU5HUyBJTiBUSEUgU09GVFdBUkUuCisgKgorICog
Q29weXJpZ2h0KGMpIEZVSklUU1UgTGltaXRlZCAyMDA4LgorICovCisKKyNpZm5kZWYgX19YRU5f
X1BVQkxJQ19JT19TQ1NJX0hfXworI2RlZmluZSBfX1hFTl9fUFVCTElDX0lPX1NDU0lfSF9fCisK
KyNpbmNsdWRlICJyaW5nLmgiCisjaW5jbHVkZSAiLi4vZ3JhbnRfdGFibGUuaCIKKworLyogY29t
bWFuZCBiZXR3ZWVuIGJhY2tlbmQgYW5kIGZyb250ZW5kICovCisjZGVmaW5lIFZTQ1NJSUZfQUNU
X1NDU0lfQ0RCICAgICAgICAgMSAgICAvKiBTQ1NJIENEQiBjb21tYW5kICovCisjZGVmaW5lIFZT
Q1NJSUZfQUNUX1NDU0lfQUJPUlQgICAgICAgMiAgICAvKiBTQ1NJIERldmljZShMdW4pIEFib3J0
Ki8KKyNkZWZpbmUgVlNDU0lJRl9BQ1RfU0NTSV9SRVNFVCAgICAgICAzICAgIC8qIFNDU0kgRGV2
aWNlKEx1bikgUmVzZXQqLworCisKKyNkZWZpbmUgVlNDU0lJRl9CQUNLX01BWF9QRU5ESU5HX1JF
UVMgICAgMTI4CisKKy8qCisgKiBNYXhpbXVtIHNjYXR0ZXIvZ2F0aGVyIHNlZ21lbnRzIHBlciBy
ZXF1ZXN0LgorICoKKyAqIENvbnNpZGVyaW5nIGJhbGFuY2UgYmV0d2VlbiBhbGxvY2F0aW5nIGFs
IGxlYXN0IDE2ICJ2c2NzaWlmX3JlcXVlc3QiCisgKiBzdHJ1Y3R1cmVzIG9uIG9uZSBwYWdlICg0
MDk2Ynl0ZXMpIGFuZCBudW1iZXIgb2Ygc2NhdHRlciBnYXRoZXIKKyAqIG5lZWRlZCwgd2UgZGVj
aWRlZCB0byB1c2UgMjYgYXMgYSBtYWdpYyBudW1iZXIuCisgKi8KKyNkZWZpbmUgVlNDU0lJRl9T
R19UQUJMRVNJWkUgICAgICAgICAgICAgMjYKKworLyoKKyAqIGJhc2Ugb24gbGludXgga2VybmVs
IDIuNi4xOAorICovCisjZGVmaW5lIFZTQ1NJSUZfTUFYX0NPTU1BTkRfU0laRSAgICAgICAgIDE2
CisjZGVmaW5lIFZTQ1NJSUZfU0VOU0VfQlVGRkVSU0laRSAgICAgICAgIDk2CisKKworc3RydWN0
IHZzY3NpaWZfcmVxdWVzdCB7CisgICAgdWludDE2X3QgcnFpZDsgICAgICAgICAgLyogcHJpdmF0
ZSBndWVzdCB2YWx1ZSwgZWNob2VkIGluIHJlc3AgICovCisgICAgdWludDhfdCBhY3Q7ICAgICAg
ICAgICAgLyogY29tbWFuZCBiZXR3ZWVuIGJhY2tlbmQgYW5kIGZyb250ZW5kICovCisgICAgdWlu
dDhfdCBjbWRfbGVuOworCisgICAgdWludDhfdCBjbW5kW1ZTQ1NJSUZfTUFYX0NPTU1BTkRfU0la
RV07CisgICAgdWludDE2X3QgdGltZW91dF9wZXJfY29tbWFuZDsgICAgIC8qIFRoZSBjb21tYW5k
IGlzIGlzc3VlZCBieSB0d2ljZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0aGUgdmFsdWUgaW4gQmFja2VuZC4gKi8KKyAgICB1aW50MTZfdCBjaGFubmVsLCBpZCwg
bHVuOworICAgIHVpbnQxNl90IHBhZGRpbmc7CisgICAgdWludDhfdCBzY19kYXRhX2RpcmVjdGlv
bjsgICAgICAgIC8qIGZvciBETUFfVE9fREVWSUNFKDEpCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIERNQV9GUk9NX0RFVklDRSgyKQorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBETUFfTk9ORSgzKSByZXF1ZXN0cyAgKi8KKyAgICB1aW50
OF90IG5yX3NlZ21lbnRzOyAgICAgICAgICAgICAgLyogTnVtYmVyIG9mIHBpZWNlcyBvZiBzY2F0
dGVyLWdhdGhlciAqLworCisgICAgc3RydWN0IHNjc2lpZl9yZXF1ZXN0X3NlZ21lbnQgeworICAg
ICAgICBncmFudF9yZWZfdCBncmVmOworICAgICAgICB1aW50MTZfdCBvZmZzZXQ7CisgICAgICAg
IHVpbnQxNl90IGxlbmd0aDsKKyAgICB9IHNlZ1tWU0NTSUlGX1NHX1RBQkxFU0laRV07CisgICAg
dWludDMyX3QgcmVzZXJ2ZWRbM107Cit9OwordHlwZWRlZiBzdHJ1Y3QgdnNjc2lpZl9yZXF1ZXN0
IHZzY3NpaWZfcmVxdWVzdF90OworCitzdHJ1Y3QgdnNjc2lpZl9yZXNwb25zZSB7CisgICAgdWlu
dDE2X3QgcnFpZDsKKyAgICB1aW50OF90IHBhZGRpbmc7CisgICAgdWludDhfdCBzZW5zZV9sZW47
CisgICAgdWludDhfdCBzZW5zZV9idWZmZXJbVlNDU0lJRl9TRU5TRV9CVUZGRVJTSVpFXTsKKyAg
ICBpbnQzMl90IHJzbHQ7CisgICAgdWludDMyX3QgcmVzaWR1YWxfbGVuOyAgICAgLyogcmVxdWVz
dCBidWZmbGVuIC0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gdGhl
IHZhbHVlIGZyb20gcGh5c2ljYWwgZGV2aWNlICovCisgICAgdWludDMyX3QgcmVzZXJ2ZWRbMzZd
OworfTsKK3R5cGVkZWYgc3RydWN0IHZzY3NpaWZfcmVzcG9uc2UgdnNjc2lpZl9yZXNwb25zZV90
OworCitERUZJTkVfUklOR19UWVBFUyh2c2NzaWlmLCBzdHJ1Y3QgdnNjc2lpZl9yZXF1ZXN0LCBz
dHJ1Y3QgdnNjc2lpZl9yZXNwb25zZSk7CisKKworI2VuZGlmICAvKl9fWEVOX19QVUJMSUNfSU9f
U0NTSV9IX18qLworLyoKKyAqIExvY2FsIHZhcmlhYmxlczoKKyAqIG1vZGU6IEMKKyAqIGMtc2V0
LXN0eWxlOiAiQlNEIgorICogYy1iYXNpYy1vZmZzZXQ6IDQKKyAqIHRhYi13aWR0aDogNAorICog
aW5kZW50LXRhYnMtbW9kZTogbmlsCisgKiBFbmQ6CisgKi8K
--f46d04182804c4d6b904b9ac494f
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d04182804c4d6b904b9ac494f--


From xen-devel-bounces@lists.xen.org Fri Feb 24 02:21:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 02: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 1S0kmU-0007eq-LG; Fri, 24 Feb 2012 02:21:10 +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 1S0kmT-0007ee-2b
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 02:21:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330049928!50039519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8562 invoked from network); 24 Feb 2012 02:18:48 -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;
	24 Feb 2012 02:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,473,1325462400"; d="scan'208";a="10909284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 02:20:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 02:20:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0kls-00015G-5b;
	Fri, 24 Feb 2012 02:20:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0klr-0001KZ-Ur;
	Fri, 24 Feb 2012 02:20:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12035-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 02:20:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12035: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12035 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12035/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  adcd6ab160fa
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24883:adcd6ab160fa
tag:         tip
user:        Tim Deegan <tim@xen.org>
date:        Thu Feb 23 10:29:27 2012 +0000
    
    x86/mm: Don't check for invalid bits in non-present PTEs.
    
    If _PAGE_PRESENT is clean in a pagetable entry, any pattern of bits
    is valid in the rest of the entry.  OSes that special-case
    PFEC_invalid_bits (since it should never happen) will be confused
    by our setting it in this way.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24882:3d4955cbcb67
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:19:57 2012 +0000
    
    libxl: Rename libxl_sched_* to include _domain
    
    In preparation for introducing a schedule parameter-based structure,
    rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
    
    No functional changes.
    
    v2: Wrap long lines while I'm at it
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24881:5b9d4bd3addf
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:50 2012 +0000
    
    libxc: Implement SCHEDOP sysctl for credit scheduler
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24880:dd9e8f1ebed1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:21 2012 +0000
    
    scheduler: Implement SCHEDOP sysctl for credit scheduler
    
    Allow tslice_ms and ratelimit_us to be modified.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24879:c4bddb3422dd
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:16:10 2012 +0000
    
    scheduler: Print ratelimit in scheduler debug key
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24878:8e672cd04864
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:15:40 2012 +0000
    
    scheduler: Add a #define for the default ratelimit
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24877:0c91a375f480
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:14:55 2012 +0000
    
    cleanup: Remove dependency files in efi directory during a make clean
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24876:7cf234b198a3
user:        Attilio Rao <attilio.rao@citrix.com>
date:        Thu Feb 23 10:11:58 2012 +0000
    
    hvmloader: Add OVMF UEFI support and directly use it
    ...when specified in the guest configuration file.
    
    This work is somewhat based on Bei Guan effort during the SoC 2011 and
    relies on upstream edk2/ovmf Tianocore ROM to be built separately and
    manually copied as:
    Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->
    tools/firmware/ovmf/ovmf-x64.bin
    Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd ->
    toolf/firmware/ovmf/ovmf-ia32.bin
    
    A way to integrate OVMF build directly into XEN has still be discussed
    on the mailing list appropriately.
    
    Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
    
    Disable CONFIG_OVMF by default as ovmf is not integrated into the
    build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24875:a59c1dcfe968
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:03:07 2012 +0000
    
    blkif.h: Define and document the request number/size/segments extension
    
    Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
          BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
          updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
          before being recompiled with a __XEN_INTERFACE_VERSION greater
          than or equal to this value.
    
    This extension first appeared in the FreeBSD Operating System.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24874:f9789db96c39
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:02:30 2012 +0000
    
    blkif.h: Document the Red Hat and Citrix blkif multi-page ring extensions
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24873:037537eff0c1
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:59 2012 +0000
    
    blkif.h: Provide more complete documentation of the blkif interface
    
      o Document the XenBus nodes used in this protocol.
      o Add a state diagram illustrating the roles and responsibilities
        of both the front and backend during startup.
      o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a
        comment.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24872:4e1460cd2227
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:26 2012 +0000
    
    blkif.h: Miscelaneous style fixes
    
      o Remove trailing whitespace.
      o Remove a blank line so that a comment block is adjacent to the
        code it documents.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24871:66cc5b67e749
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Feb 23 09:59:35 2012 +0000
    
    xen: add missing unlock from gnttab_get_version
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24870:9bf3ec036bef
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Thu Feb 23 09:58:47 2012 +0000
    
    IO-APIC: Prevent using EOI broadcast suppression if user specified ioapic_ack=new on the command line.
    
    Currently, if EOI broadcast suppression is advertised on the BSP
    LAPIC, Xen will discard any user specified option regarding IO-APIC
    ack mode.
    
    This patch introduces a check which prevents EOI Broadcast suppression
    from forcing the IO-APIC ack mode to old if the user has explicitly
    asked for the new ack mode on the command line.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24869:a4d93d0e0df2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Feb 22 14:33:24 2012 +0000
    
    arm: lr register in hyp mode is really LR_usr.
    
    Save and restore it in the same way for both hypervisor and user stack frames
    rather than saving both individually in the user stack frame.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 02:21:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 02: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 1S0kmU-0007eq-LG; Fri, 24 Feb 2012 02:21:10 +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 1S0kmT-0007ee-2b
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 02:21:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330049928!50039519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8562 invoked from network); 24 Feb 2012 02:18:48 -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;
	24 Feb 2012 02:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,473,1325462400"; d="scan'208";a="10909284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 02:20:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 02:20:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0kls-00015G-5b;
	Fri, 24 Feb 2012 02:20:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0klr-0001KZ-Ur;
	Fri, 24 Feb 2012 02:20:32 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12035-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 02:20:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12035: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12035 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12035/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  adcd6ab160fa
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24883:adcd6ab160fa
tag:         tip
user:        Tim Deegan <tim@xen.org>
date:        Thu Feb 23 10:29:27 2012 +0000
    
    x86/mm: Don't check for invalid bits in non-present PTEs.
    
    If _PAGE_PRESENT is clean in a pagetable entry, any pattern of bits
    is valid in the rest of the entry.  OSes that special-case
    PFEC_invalid_bits (since it should never happen) will be confused
    by our setting it in this way.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24882:3d4955cbcb67
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:19:57 2012 +0000
    
    libxl: Rename libxl_sched_* to include _domain
    
    In preparation for introducing a schedule parameter-based structure,
    rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
    
    No functional changes.
    
    v2: Wrap long lines while I'm at it
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24881:5b9d4bd3addf
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:50 2012 +0000
    
    libxc: Implement SCHEDOP sysctl for credit scheduler
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24880:dd9e8f1ebed1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:21 2012 +0000
    
    scheduler: Implement SCHEDOP sysctl for credit scheduler
    
    Allow tslice_ms and ratelimit_us to be modified.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24879:c4bddb3422dd
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:16:10 2012 +0000
    
    scheduler: Print ratelimit in scheduler debug key
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24878:8e672cd04864
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:15:40 2012 +0000
    
    scheduler: Add a #define for the default ratelimit
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24877:0c91a375f480
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:14:55 2012 +0000
    
    cleanup: Remove dependency files in efi directory during a make clean
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24876:7cf234b198a3
user:        Attilio Rao <attilio.rao@citrix.com>
date:        Thu Feb 23 10:11:58 2012 +0000
    
    hvmloader: Add OVMF UEFI support and directly use it
    ...when specified in the guest configuration file.
    
    This work is somewhat based on Bei Guan effort during the SoC 2011 and
    relies on upstream edk2/ovmf Tianocore ROM to be built separately and
    manually copied as:
    Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->
    tools/firmware/ovmf/ovmf-x64.bin
    Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd ->
    toolf/firmware/ovmf/ovmf-ia32.bin
    
    A way to integrate OVMF build directly into XEN has still be discussed
    on the mailing list appropriately.
    
    Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
    
    Disable CONFIG_OVMF by default as ovmf is not integrated into the
    build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24875:a59c1dcfe968
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:03:07 2012 +0000
    
    blkif.h: Define and document the request number/size/segments extension
    
    Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
          BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
          updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
          before being recompiled with a __XEN_INTERFACE_VERSION greater
          than or equal to this value.
    
    This extension first appeared in the FreeBSD Operating System.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24874:f9789db96c39
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:02:30 2012 +0000
    
    blkif.h: Document the Red Hat and Citrix blkif multi-page ring extensions
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24873:037537eff0c1
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:59 2012 +0000
    
    blkif.h: Provide more complete documentation of the blkif interface
    
      o Document the XenBus nodes used in this protocol.
      o Add a state diagram illustrating the roles and responsibilities
        of both the front and backend during startup.
      o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a
        comment.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24872:4e1460cd2227
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:26 2012 +0000
    
    blkif.h: Miscelaneous style fixes
    
      o Remove trailing whitespace.
      o Remove a blank line so that a comment block is adjacent to the
        code it documents.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24871:66cc5b67e749
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Feb 23 09:59:35 2012 +0000
    
    xen: add missing unlock from gnttab_get_version
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24870:9bf3ec036bef
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Thu Feb 23 09:58:47 2012 +0000
    
    IO-APIC: Prevent using EOI broadcast suppression if user specified ioapic_ack=new on the command line.
    
    Currently, if EOI broadcast suppression is advertised on the BSP
    LAPIC, Xen will discard any user specified option regarding IO-APIC
    ack mode.
    
    This patch introduces a check which prevents EOI Broadcast suppression
    from forcing the IO-APIC ack mode to old if the user has explicitly
    asked for the new ack mode on the command line.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24869:a4d93d0e0df2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Feb 22 14:33:24 2012 +0000
    
    arm: lr register in hyp mode is really LR_usr.
    
    Save and restore it in the same way for both hypervisor and user stack frames
    rather than saving both individually in the user stack frame.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 03:08:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 03:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0lVg-00088O-Hf; Fri, 24 Feb 2012 03:07:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1S0lVf-00088J-0u
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 03:07:51 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330052863!14664411!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25811 invoked from network); 24 Feb 2012 03:07:44 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-8.tower-174.messagelabs.com with SMTP;
	24 Feb 2012 03:07:44 -0000
Received: from [164.99.195.39] ([::ffff:164.99.195.39])
	by mail.novell.com with ESMTP; Thu, 23 Feb 2012 20:07:29 -0700
Message-ID: <4F46FE89.3050209@suse.com>
Date: Thu, 23 Feb 2012 20:05:45 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>	
	<20291.56383.499378.463797@mariner.uk.xensource.com>	
	<4F456136.7070904@suse.com>
	<1329987543.8557.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329987543.8557.24.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error	of
	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
> On Wed, 2012-02-22 at 21:42 +0000, Jim Fehlig wrote:
>   
>> Ian Jackson wrote:
>>     
>>> Note that the API for libxl has changed in xen-unstable.hg compared to
>>> 4.1, and further changes are forthcoming.  So there will have to be
>>> changes in libvirt.
>>>   
>>>       
>> I suppose libvirt is the only out-of-tree libxl app feeling this pain :-(.
>>     
>
> We're sorry about this, we felt it was necessary to break the API
> between 4.1 and 4.2 in order that we can support a stable API from 4.2
> onwards (I think we discussed this at the time?).

Yes we did, and I need to stop whining about it :-).

>  From 4.2 onwards we
> will make changes in a compatible way or provide compatibility shims etc
> or in extreme circumstances do things in a way which is easily
> detectable e.g. via configure tests.
>   

That would be much appreciated.  Maybe we'll start seeing more libxl apps...

> I was wondering the other day if "libxl v2" support for libvirt might
> make a nice GSoC project, what do you think? Would you be interested in
> mentoring such a project?
>   

I agree that it would make a nice GSoC project, but I had encouraged
Bamvor to take on the task.  It's a good project for becoming familiar
with xen and libvirt.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 03:08:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 03:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0lVg-00088O-Hf; Fri, 24 Feb 2012 03:07:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1S0lVf-00088J-0u
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 03:07:51 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330052863!14664411!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25811 invoked from network); 24 Feb 2012 03:07:44 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-8.tower-174.messagelabs.com with SMTP;
	24 Feb 2012 03:07:44 -0000
Received: from [164.99.195.39] ([::ffff:164.99.195.39])
	by mail.novell.com with ESMTP; Thu, 23 Feb 2012 20:07:29 -0700
Message-ID: <4F46FE89.3050209@suse.com>
Date: Thu, 23 Feb 2012 20:05:45 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>	
	<20291.56383.499378.463797@mariner.uk.xensource.com>	
	<4F456136.7070904@suse.com>
	<1329987543.8557.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1329987543.8557.24.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error	of
	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
> On Wed, 2012-02-22 at 21:42 +0000, Jim Fehlig wrote:
>   
>> Ian Jackson wrote:
>>     
>>> Note that the API for libxl has changed in xen-unstable.hg compared to
>>> 4.1, and further changes are forthcoming.  So there will have to be
>>> changes in libvirt.
>>>   
>>>       
>> I suppose libvirt is the only out-of-tree libxl app feeling this pain :-(.
>>     
>
> We're sorry about this, we felt it was necessary to break the API
> between 4.1 and 4.2 in order that we can support a stable API from 4.2
> onwards (I think we discussed this at the time?).

Yes we did, and I need to stop whining about it :-).

>  From 4.2 onwards we
> will make changes in a compatible way or provide compatibility shims etc
> or in extreme circumstances do things in a way which is easily
> detectable e.g. via configure tests.
>   

That would be much appreciated.  Maybe we'll start seeing more libxl apps...

> I was wondering the other day if "libxl v2" support for libvirt might
> make a nice GSoC project, what do you think? Would you be interested in
> mentoring such a project?
>   

I agree that it would make a nice GSoC project, but I had encouraged
Bamvor to take on the task.  It's a good project for becoming familiar
with xen and libvirt.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 04:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 04:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0muw-0001Av-6T; Fri, 24 Feb 2012 04:38:02 +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 1S0muu-0001Ak-Q4
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 04:38:01 +0000
Received: from [85.158.139.83:10883] by server-9.bemta-5.messagelabs.com id
	63/A7-30171-724174F4; Fri, 24 Feb 2012 04:37:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330058277!16440242!1
X-Originating-IP: [148.87.113.126]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7235 invoked from network); 24 Feb 2012 04:37:58 -0000
Received: from rcsinet14.oracle.com (HELO rcsinet14.oracle.com)
	(148.87.113.126)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 04:37:58 -0000
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117])
	by rcsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1O4bJk1022719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 24 Feb 2012 04:37:19 GMT
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 q1O4bpgi022395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 04:37: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
	q1O4bnYH014444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 04:37:50 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
	q1O4bm0h003292; Thu, 23 Feb 2012 22:37:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 20:37:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 798174171C; Thu, 23 Feb 2012 23:34:26 -0500 (EST)
Date: Thu, 23 Feb 2012 23:34:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Message-ID: <20120224043426.GC23568@phenom.dumpdata.com>
References: <4F405CD0.2060002@virtfinity.de>
	<20120221145526.GH5652@phenom.dumpdata.com>
	<CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F471420.006F,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Thomas Weyergraf <T.Weyergraf@virtfinity.de>
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 05:19:00PM -0700, jacek burghardt wrote:
> I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk
> git. I had extracted patch from pvscssi-01 and applied it back to
> 3.3.0-rc1. I am able to load both xen-scsiback and xen-scsifront modules
> but I don't see anything happening.
> does xl supports pvscsi or it needs to be patched. I am running 4.2
> unstable.


Did you try to use xm?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 04:38:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 04:38:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0muw-0001Av-6T; Fri, 24 Feb 2012 04:38:02 +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 1S0muu-0001Ak-Q4
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 04:38:01 +0000
Received: from [85.158.139.83:10883] by server-9.bemta-5.messagelabs.com id
	63/A7-30171-724174F4; Fri, 24 Feb 2012 04:37:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330058277!16440242!1
X-Originating-IP: [148.87.113.126]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7235 invoked from network); 24 Feb 2012 04:37:58 -0000
Received: from rcsinet14.oracle.com (HELO rcsinet14.oracle.com)
	(148.87.113.126)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 04:37:58 -0000
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117])
	by rcsinet14.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1O4bJk1022719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 24 Feb 2012 04:37:19 GMT
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 q1O4bpgi022395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 04:37: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
	q1O4bnYH014444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 04:37:50 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
	q1O4bm0h003292; Thu, 23 Feb 2012 22:37:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 20:37:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 798174171C; Thu, 23 Feb 2012 23:34:26 -0500 (EST)
Date: Thu, 23 Feb 2012 23:34:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jacek burghardt <jaceksburghardt@gmail.com>
Message-ID: <20120224043426.GC23568@phenom.dumpdata.com>
References: <4F405CD0.2060002@virtfinity.de>
	<20120221145526.GH5652@phenom.dumpdata.com>
	<CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F471420.006F,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Thomas Weyergraf <T.Weyergraf@virtfinity.de>
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 05:19:00PM -0700, jacek burghardt wrote:
> I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk
> git. I had extracted patch from pvscssi-01 and applied it back to
> 3.3.0-rc1. I am able to load both xen-scsiback and xen-scsifront modules
> but I don't see anything happening.
> does xl supports pvscsi or it needs to be patched. I am running 4.2
> unstable.


Did you try to use xm?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 05:58:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 05:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0oAG-00027I-DZ; Fri, 24 Feb 2012 05:57:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0oAE-00027D-0o
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 05:57:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330063066!16668158!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6879 invoked from network); 24 Feb 2012 05:57:47 -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; 24 Feb 2012 05:57:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1O5vfrL010987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 05:57:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1O5vf3M013534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 05:57:41 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
	q1O5veVR029819; Thu, 23 Feb 2012 23:57:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 21:57:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CE78B4171C; Fri, 24 Feb 2012 00:54:18 -0500 (EST)
Date: Fri, 24 Feb 2012 00:54:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Message-ID: <20120224055418.GA11780@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
	<4F46E174.6040009@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F46E174.6040009@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090203.4F4726D7.002C,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 anybody have a similar problem on 2nd Gen Core i5? Any advises how
> >>>>> to approach debugging it?
> >>>>>
.. snip..
> (the same hardware)
> On 2.6.38.3 xenlinux kernel after resume there is screen content from before
> suspend, power led light constantly (as it should), but system is
> irresponsible (no capslock led, no reaction to sysrq, network etc).
> On 3.x with your patches system goes into S3, but on resume is even worse - no
> screen content at all (and no backlight) and also irresponsible, power led
> still blinking. As 3.x tried:
>  - your devel/acpi-s3.v7 branch directly
>  - 3.2.7 merged with devel/acpi-s3.v7
>  - 3.3-rc4 with devel/acpi-s3.v7

OK. That is weird - it worked for me last time. One thing at at time then -
try doing this from text-mode, so no graphic mode involved. For that you might
need to disable your i915 driver altogether. Then just run 'pm-suspend' and
see where it stops.

The next part is... Wait a minute, this reminds me of something I encountered
with a SandyBrige i2100 - the suspend would work, but resume would get stuck.

The issue was with the hypervisor and if I had the acpi-cpufreq drivers loaded
it resumed just fine. If I didn't - so hypervisor had no idea about C states or
P states, it would be stuck in the default_idle and never come back.

So you might want for fun try also using the stable/processor-passthru.v5 and
build it with CONFIG_XEN_PROCESSOR_PASSTHRU=y.

But the other issue could be with your ExpressCard. I don't know if you are using
the serial console output on it, but there might be a bug in the hypervisor where
it ends up looping forver if you are using a serial console). So try _not_ using
it and seeing what happens.

>  - your devel/acpi-s3.v8 branch directly
> The same result on all above.
> 
> How can I debug this issue?

Try those things. Then start ramping up the debug options to get an idea of what
is not working. Also, flash your BIOS just in case.
> 
> -- 
> Best Regards / Pozdrawiam,
> Marek Marczykowski
> Invisible Things Lab
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 05:58:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 05:58:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0oAG-00027I-DZ; Fri, 24 Feb 2012 05:57:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0oAE-00027D-0o
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 05:57:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330063066!16668158!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6879 invoked from network); 24 Feb 2012 05:57:47 -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; 24 Feb 2012 05:57:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1O5vfrL010987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 05:57:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1O5vf3M013534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 05:57:41 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
	q1O5veVR029819; Thu, 23 Feb 2012 23:57:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 21:57:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CE78B4171C; Fri, 24 Feb 2012 00:54:18 -0500 (EST)
Date: Fri, 24 Feb 2012 00:54:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Message-ID: <20120224055418.GA11780@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
	<4F46E174.6040009@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F46E174.6040009@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090203.4F4726D7.002C,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 anybody have a similar problem on 2nd Gen Core i5? Any advises how
> >>>>> to approach debugging it?
> >>>>>
.. snip..
> (the same hardware)
> On 2.6.38.3 xenlinux kernel after resume there is screen content from before
> suspend, power led light constantly (as it should), but system is
> irresponsible (no capslock led, no reaction to sysrq, network etc).
> On 3.x with your patches system goes into S3, but on resume is even worse - no
> screen content at all (and no backlight) and also irresponsible, power led
> still blinking. As 3.x tried:
>  - your devel/acpi-s3.v7 branch directly
>  - 3.2.7 merged with devel/acpi-s3.v7
>  - 3.3-rc4 with devel/acpi-s3.v7

OK. That is weird - it worked for me last time. One thing at at time then -
try doing this from text-mode, so no graphic mode involved. For that you might
need to disable your i915 driver altogether. Then just run 'pm-suspend' and
see where it stops.

The next part is... Wait a minute, this reminds me of something I encountered
with a SandyBrige i2100 - the suspend would work, but resume would get stuck.

The issue was with the hypervisor and if I had the acpi-cpufreq drivers loaded
it resumed just fine. If I didn't - so hypervisor had no idea about C states or
P states, it would be stuck in the default_idle and never come back.

So you might want for fun try also using the stable/processor-passthru.v5 and
build it with CONFIG_XEN_PROCESSOR_PASSTHRU=y.

But the other issue could be with your ExpressCard. I don't know if you are using
the serial console output on it, but there might be a bug in the hypervisor where
it ends up looping forver if you are using a serial console). So try _not_ using
it and seeing what happens.

>  - your devel/acpi-s3.v8 branch directly
> The same result on all above.
> 
> How can I debug this issue?

Try those things. Then start ramping up the debug options to get an idea of what
is not working. Also, flash your BIOS just in case.
> 
> -- 
> Best Regards / Pozdrawiam,
> Marek Marczykowski
> Invisible Things Lab
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:48:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ox5-0003Bq-Jz; Fri, 24 Feb 2012 06:48:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ox4-0003Bb-E8
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:48:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330066094!14697966!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15881 invoked from network); 24 Feb 2012 06:48:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 06:48: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 q1O6m9f1012407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 06:48:10 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
	q1O6m8h5006284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 06:48:09 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1O6m7fX024308; Fri, 24 Feb 2012 00:48:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 22:48:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EB3734172A; Fri, 24 Feb 2012 01:44:45 -0500 (EST)
MIME-Version: 1.0
X-Mercurial-Node: aa3a294327ed075bafbe3c070b39e3dbacbc49cd
Message-Id: <aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1330065832@phenom.dumpdata.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 24 Feb 2012 01:43:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 25
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090205.4F4732AA.0060,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1330065828 18000
# Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
# Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
linux-xencommons: Load processor-passthru

The processor-passthru module is used in the upstream kernels
to upload power management information to the hypervisor. We
need to load it to work first.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a34b652afb0c -r aa3a294327ed tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
@@ -58,6 +58,7 @@ do_start () {
 	modprobe xen-gntdev 2>/dev/null
 	modprobe evtchn 2>/dev/null
 	modprobe gntdev 2>/dev/null
+	modprobe processor-passthru 2>/dev/null
 
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:48:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ox5-0003Bq-Jz; Fri, 24 Feb 2012 06:48:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ox4-0003Bb-E8
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:48:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330066094!14697966!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15881 invoked from network); 24 Feb 2012 06:48:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 06:48: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 q1O6m9f1012407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 06:48:10 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
	q1O6m8h5006284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 06:48:09 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1O6m7fX024308; Fri, 24 Feb 2012 00:48:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 22:48:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EB3734172A; Fri, 24 Feb 2012 01:44:45 -0500 (EST)
MIME-Version: 1.0
X-Mercurial-Node: aa3a294327ed075bafbe3c070b39e3dbacbc49cd
Message-Id: <aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1330065832@phenom.dumpdata.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 24 Feb 2012 01:43:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 25
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090205.4F4732AA.0060,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1330065828 18000
# Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
# Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
linux-xencommons: Load processor-passthru

The processor-passthru module is used in the upstream kernels
to upload power management information to the hypervisor. We
need to load it to work first.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a34b652afb0c -r aa3a294327ed tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
@@ -58,6 +58,7 @@ do_start () {
 	modprobe xen-gntdev 2>/dev/null
 	modprobe evtchn 2>/dev/null
 	modprobe gntdev 2>/dev/null
+	modprobe processor-passthru 2>/dev/null
 
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:48:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ox5-0003Bx-VM; Fri, 24 Feb 2012 06:48:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ox4-0003Bc-GF
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:48:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330066094!14698201!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12588 invoked from network); 24 Feb 2012 06:48:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 06:48: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 q1O6m9he012410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 06:48:10 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1O6m8Rf024515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 06:48:09 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
	q1O6m7ph004715; Fri, 24 Feb 2012 00:48:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 22:48:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DDBB04171C; Fri, 24 Feb 2012 01:44:45 -0500 (EST)
MIME-Version: 1.0
Message-Id: <patchbomb.1330065832@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 24 Feb 2012 01:43:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 12
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F4732AA.004C,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 2] [RFC] Patches to work with
 processor-passthru driver (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


These two patches provide the neccessary infrastructure changes
for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html]
to properly function.

The first one is quite easy - we just modprobe the processor-passthru driver.

The second allows it to work under AMD machines by exposing the PM RDMSR
to dom0. It has been tested with 2.6.32 kernel as well to make sure it does
not negativly impact them and it does not. 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:48:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06:48:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ox5-0003Bx-VM; Fri, 24 Feb 2012 06:48:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ox4-0003Bc-GF
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:48:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330066094!14698201!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY1OTU1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12588 invoked from network); 24 Feb 2012 06:48:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 06:48: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 q1O6m9he012410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 06:48:10 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1O6m8Rf024515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 06:48:09 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
	q1O6m7ph004715; Fri, 24 Feb 2012 00:48:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 22:48:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DDBB04171C; Fri, 24 Feb 2012 01:44:45 -0500 (EST)
MIME-Version: 1.0
Message-Id: <patchbomb.1330065832@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 24 Feb 2012 01:43:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 12
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F4732AA.004C,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 2] [RFC] Patches to work with
 processor-passthru driver (v1).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


These two patches provide the neccessary infrastructure changes
for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html]
to properly function.

The first one is quite easy - we just modprobe the processor-passthru driver.

The second allows it to work under AMD machines by exposing the PM RDMSR
to dom0. It has been tested with 2.6.32 kernel as well to make sure it does
not negativly impact them and it does not. 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:48:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ox6-0003C4-Bd; Fri, 24 Feb 2012 06:48:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ox4-0003Bd-SX
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:48:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330066094!14707320!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NTIzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9867 invoked from network); 24 Feb 2012 06:48:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 06:48:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1O6m9SE015070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 06:48:09 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
	q1O6m82I011474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 06:48:09 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
	q1O6m7nu023980; Fri, 24 Feb 2012 00:48:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 22:48:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E49C541727; Fri, 24 Feb 2012 01:44:45 -0500 (EST)
MIME-Version: 1.0
X-Mercurial-Node: a34b652afb0ca484b7416008c95fd36ffbbea334
Message-Id: <a34b652afb0ca484b741.1330065833@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1330065832@phenom.dumpdata.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 24 Feb 2012 01:43:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 28
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F4732AA.0035,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 2] traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL,
	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

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1330065828 18000
# Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/arch/x86/traps.c	Fri Feb 24 01:43:48 2012 -0500
@@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_PSTATE7:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
             {
                 regs->eax = regs->edx = 0;
                 break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:48:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0ox6-0003C4-Bd; Fri, 24 Feb 2012 06:48:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0ox4-0003Bd-SX
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:48:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330066094!14707320!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NTIzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9867 invoked from network); 24 Feb 2012 06:48:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 06:48:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1O6m9SE015070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 06:48:09 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
	q1O6m82I011474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 06:48:09 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
	q1O6m7nu023980; Fri, 24 Feb 2012 00:48:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 23 Feb 2012 22:48:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E49C541727; Fri, 24 Feb 2012 01:44:45 -0500 (EST)
MIME-Version: 1.0
X-Mercurial-Node: a34b652afb0ca484b7416008c95fd36ffbbea334
Message-Id: <a34b652afb0ca484b741.1330065833@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1330065832@phenom.dumpdata.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 24 Feb 2012 01:43:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 28
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F4732AA.0035,ss=1,re=0.000,fgs=0
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 2] traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL,
	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

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1330065828 18000
# Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)

The restriction to read and write the AMD power management MSRs is gated if the
domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
relax this restriction and allow the privileged domain to read the MSRs
(but not write). This allows the priviliged domain to harvest the power
management information (ACPI _PSS states) and send it to the hypervisor.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/arch/x86/traps.c	Fri Feb 24 01:43:48 2012 -0500
@@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct 
         case MSR_K8_PSTATE7:
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
                 goto fail;
-            if ( !is_cpufreq_controller(v->domain) )
+            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
             {
                 regs->eax = regs->edx = 0;
                 break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 06:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06: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 1S0p6u-0003eB-Ik; Fri, 24 Feb 2012 06:58: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 1S0p6t-0003e6-6s
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:58:31 +0000
Received: from [85.158.139.83:14261] by server-2.bemta-5.messagelabs.com id
	2F/03-20263-615374F4; Fri, 24 Feb 2012 06:58:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330066709!15591029!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23676 invoked from network); 24 Feb 2012 06:58:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 06:58:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,474,1325462400"; d="scan'208";a="10910848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 06:58:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 06:58:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0p6r-0003XT-0F;
	Fri, 24 Feb 2012 06:58:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0p6q-0008Sr-S9;
	Fri, 24 Feb 2012 06:58:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12038-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 06:58:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12038: 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 12038 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12038/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore        fail blocked in 11853
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 11853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd  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-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  bf902d6661e3
baseline version:
 xen                  3feb83eed6bd

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@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                                          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=bf902d6661e3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 bf902d6661e3
+ branch=xen-4.0-testing
+ revision=bf902d6661e3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ . ap-common
++ : 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
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r bf902d6661e3 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 4 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 Fri Feb 24 06:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 06: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 1S0p6u-0003eB-Ik; Fri, 24 Feb 2012 06:58: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 1S0p6t-0003e6-6s
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 06:58:31 +0000
Received: from [85.158.139.83:14261] by server-2.bemta-5.messagelabs.com id
	2F/03-20263-615374F4; Fri, 24 Feb 2012 06:58:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330066709!15591029!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23676 invoked from network); 24 Feb 2012 06:58:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 06:58:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,474,1325462400"; d="scan'208";a="10910848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 06:58:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 06:58:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0p6r-0003XT-0F;
	Fri, 24 Feb 2012 06:58:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0p6q-0008Sr-S9;
	Fri, 24 Feb 2012 06:58:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12038-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 06:58:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 12038: 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 12038 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12038/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore        fail blocked in 11853
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 11853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd  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-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  bf902d6661e3
baseline version:
 xen                  3feb83eed6bd

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@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                                          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=bf902d6661e3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 bf902d6661e3
+ branch=xen-4.0-testing
+ revision=bf902d6661e3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
+ . ap-common
++ : 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
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git
++ : daily-cron.xen-4.0-testing
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.0-testing.hg
+ hg push -r bf902d6661e3 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 4 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 Fri Feb 24 07:01:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 07:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0p8y-0003n3-Aa; Fri, 24 Feb 2012 07:00:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1S0p8w-0003mJ-W7
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 07:00:39 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330066830!13097453!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDA5MTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23079 invoked from network); 24 Feb 2012 07:00:31 -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; 24 Feb 2012 07:00:31 -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 650A01089;
	Fri, 24 Feb 2012 09:00:29 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A723220056; Fri, 24 Feb 2012 09:00:28 +0200 (EET)
Date: Fri, 24 Feb 2012 09:00:28 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: jacek burghardt <jaceksburghardt@gmail.com>
Message-ID: <20120224070028.GS12984@reaktio.net>
References: <4F405CD0.2060002@virtfinity.de>
	<20120221145526.GH5652@phenom.dumpdata.com>
	<CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Thomas Weyergraf <T.Weyergraf@virtfinity.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 05:19:00PM -0700, jacek burghardt wrote:
>    I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk
>    git. I had extracted patch from pvscssi-01 and applied it back to
>    3.3.0-rc1. I am able to load both xen-scsiback and xen-scsifront modules
>    but I don't see anything happening.
>    does xl supports pvscsi or it needs to be patched. I am running 4.2
>    unstable.

I don't think there is currently any PVSCSI support in xl/libxl.

-- Pasi

> 
>    On Tue, Feb 21, 2012 at 7:55 AM, Konrad Rzeszutek Wilk
>    <[1]konrad.wilk@oracle.com> wrote:
> 
>      On Sun, Feb 19, 2012 at 03:22:08AM +0100, Thomas Weyergraf wrote:
>      > Hi, I am working as a system administrator at an internet platform
>      > service provider, and I am currently seeking to re-new our Xen
>      > virtualization infrastructure for which I am mostly responsible for.
>      > Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0
>      > with CentOS 5.x pv-guests.
>      >
>      > Based on my experiments, I am currently looking into Xen 4.1.2 on
>      > RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as
>      > Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.
> 
>      Sweet.
>      >
>      > Our DomU's have their disk-devices on iscsi-storage backends (EMC,
>      > netapp, Linux IET), we attach the disks to Dom0 via open-iscsi
>      > initiator and pass them as 'phy'-type blockdevices, using
>      > blkfront/back.
> 
>      OK.
>      >
>      > As this is the time for a major overhaul anyway, I looked at
>      > 'pvscsi', which is very attractive to me for a bunch of
>      > (administrative) reasons. I have created a working pvscsi-setup with
>      > the following steps:
>      > 1. Use CentOS 6.2 as base system
>      > 2. Add Xen hypervisor from Michael Young's repository [1]. This is
>      > stock 4.1.2 with a patch from 4.1-testing pulled-in and various
>      > patches fixing compile-time issues, toolchain problems and system
>      > service management on RHEL-alike systems. (Nice work, btw!)
>      > 3. Use a vanilla 3.2.0 kernel from [2]kernel.org and a .config based
>      on
>      > a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,
>      > Fedora 16 supports Dom0 operation and the only changes to the config
>      > are non-Xen related or add the Xen pvscsi config. I refrained from
>      > attaching the config to avoid mailinglist-clutter, but can do so on
>      > demand.
> 
>      Awesome.
>      > 4. I pulled and applied the pvscsi-patch found in this post [2] from
>      > Konrad Rzeszutek Wilk.
>      >
>      > Putting it all together yielded a "working setup" in which I am able
>      > to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.
>      > In DomU context, I could partition the device, create a filesystem
>      > on it and copy/read/verify some 10gig of data to it. Very basic
>      > testing until now, essentially. However, the whole issue raised some
>      > questions:
>      >
>      > - I pvscsi actively maintained? Is someone working on this or even
>      > prepare it for upstream inclusion in the pv-ops framework of the 3.x
>      > series?
> 
>      So nobody has stepped up to do the upstream task and it is on my todo
>      list
>      but mostly at the end.
>      > - Has anybody started on adding the vscsi-semantics to the xl
>      toolstack?
> 
>      Not that I know of.
>      > - Using 'xm', I was only able to add a device via its SCSI tupel
>      > (HCTL, e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other
>      > device-node, such as '/dev/sde' or the
>      > '/dev/disk/by-path/<iscsi-iqn>' link. For these invocations, an
>      > "Error: Cannot find device <device>" message is given. I have not
>      > yet looked at the issue in detail (in
>      > /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this
>      > a known issue?
> 
>      First time I hear of it. But then I didn't even think to use /dev/sde
>      to pass in a device since SCSI devices aren't neccessarily block ones.
>      They can be scanners, medical devices, tape drivers, etc - which
>      might not have a /dev/sdX (thought they will have an /dev/sgX).
>      >
>      > Is there any developer(s) working on getting pvscsi ready for
>      > [3]kernel.org 3.x upstream inclusion? Should i better retool my
>      efforts
>      > using pv-ops xen/stable 2.6.32 series?
> 
>      For 3.x upstream inclusion - not that I know off.
>      Why would you want to retool your effort in using the 2.6.32 series
>      as opposed to 3.x? What other items is the 3.x missing compared to
>      2.6.32?
> 
>      Now the good news is that I am happy to keep this going (pv-scsi)
>      and fixing it, and having incremental updates to make it better.
>      >
>      > If applicable, I'd be more than happy to provide assistance to move
>      > forward pvscsi. Maybe, as a start, provide a short, practical howto
>      > about what I did above to get pvscsi working and reference it by the
>      > Xen PVSCSI wiki page [3]?
> 
>      Sure. Also, did you use the git tree to pull the patches or just
>      the big patch file ? The git tree has fixes to make it work under 3.2 as
>      well.
>      >
>      > Regards,
>      > Thomas Weyergraf
>      >
>      > [1] [4]http://xenbits.xen.org/people/mayoung/EL6.xen/
>      > [2]
>      [5]http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
>      > [3] [6]http://wiki.xen.org/xenwiki/XenPVSCSI
>      >
>      >
>      >
>      > _______________________________________________
>      > Xen-devel mailing list
>      > [7]Xen-devel@lists.xen.org
>      > [8]http://lists.xen.org/xen-devel
> 
>      _______________________________________________
>      Xen-devel mailing list
>      [9]Xen-devel@lists.xen.org
>      [10]http://lists.xen.org/xen-devel
> 
> References
> 
>    Visible links
>    1. mailto:konrad.wilk@oracle.com
>    2. http://kernel.org/
>    3. http://kernel.org/
>    4. http://xenbits.xen.org/people/mayoung/EL6.xen/
>    5. http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
>    6. http://wiki.xen.org/xenwiki/XenPVSCSI
>    7. mailto:Xen-devel@lists.xen.org
>    8. http://lists.xen.org/xen-devel
>    9. mailto:Xen-devel@lists.xen.org
>   10. http://lists.xen.org/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 07:01:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 07:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0p8y-0003n3-Aa; Fri, 24 Feb 2012 07:00:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1S0p8w-0003mJ-W7
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 07:00:39 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330066830!13097453!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDA5MTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23079 invoked from network); 24 Feb 2012 07:00:31 -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; 24 Feb 2012 07:00:31 -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 650A01089;
	Fri, 24 Feb 2012 09:00:29 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A723220056; Fri, 24 Feb 2012 09:00:28 +0200 (EET)
Date: Fri, 24 Feb 2012 09:00:28 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: jacek burghardt <jaceksburghardt@gmail.com>
Message-ID: <20120224070028.GS12984@reaktio.net>
References: <4F405CD0.2060002@virtfinity.de>
	<20120221145526.GH5652@phenom.dumpdata.com>
	<CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAHyyzzTiy-nrdiXbChJz49cpxGTM0yf=tD+OyGeUALT5GvhLcw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Thomas Weyergraf <T.Weyergraf@virtfinity.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen PVSCSI: status, issues and some tests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 05:19:00PM -0700, jacek burghardt wrote:
>    I had just compiled pvscsi into 3.3.0-rc1 based on Konrad Rzeszutek Wilk
>    git. I had extracted patch from pvscssi-01 and applied it back to
>    3.3.0-rc1. I am able to load both xen-scsiback and xen-scsifront modules
>    but I don't see anything happening.
>    does xl supports pvscsi or it needs to be patched. I am running 4.2
>    unstable.

I don't think there is currently any PVSCSI support in xl/libxl.

-- Pasi

> 
>    On Tue, Feb 21, 2012 at 7:55 AM, Konrad Rzeszutek Wilk
>    <[1]konrad.wilk@oracle.com> wrote:
> 
>      On Sun, Feb 19, 2012 at 03:22:08AM +0100, Thomas Weyergraf wrote:
>      > Hi, I am working as a system administrator at an internet platform
>      > service provider, and I am currently seeking to re-new our Xen
>      > virtualization infrastructure for which I am mostly responsible for.
>      > Currently, we run Xen 3.4.2/3.4.3 on RHEL/CentOS 5.x (5.7) as Dom0
>      > with CentOS 5.x pv-guests.
>      >
>      > Based on my experiments, I am currently looking into Xen 4.1.2 on
>      > RHEL/CentOS 6.x (6.2), with a vanilla 3.2 (3.2.0/3.2.6) kernel as
>      > Dom0 and stock RHEL/CentOS 6.x guests as HVM/pv-ops DomUs.
> 
>      Sweet.
>      >
>      > Our DomU's have their disk-devices on iscsi-storage backends (EMC,
>      > netapp, Linux IET), we attach the disks to Dom0 via open-iscsi
>      > initiator and pass them as 'phy'-type blockdevices, using
>      > blkfront/back.
> 
>      OK.
>      >
>      > As this is the time for a major overhaul anyway, I looked at
>      > 'pvscsi', which is very attractive to me for a bunch of
>      > (administrative) reasons. I have created a working pvscsi-setup with
>      > the following steps:
>      > 1. Use CentOS 6.2 as base system
>      > 2. Add Xen hypervisor from Michael Young's repository [1]. This is
>      > stock 4.1.2 with a patch from 4.1-testing pulled-in and various
>      > patches fixing compile-time issues, toolchain problems and system
>      > service management on RHEL-alike systems. (Nice work, btw!)
>      > 3. Use a vanilla 3.2.0 kernel from [2]kernel.org and a .config based
>      on
>      > a Fedora 16 stock-kernel config, tweaked to use pvscsi. As you know,
>      > Fedora 16 supports Dom0 operation and the only changes to the config
>      > are non-Xen related or add the Xen pvscsi config. I refrained from
>      > attaching the config to avoid mailinglist-clutter, but can do so on
>      > demand.
> 
>      Awesome.
>      > 4. I pulled and applied the pvscsi-patch found in this post [2] from
>      > Konrad Rzeszutek Wilk.
>      >
>      > Putting it all together yielded a "working setup" in which I am able
>      > to pass an Dom0-attached iscsi target to a DomU as a vscsi-device.
>      > In DomU context, I could partition the device, create a filesystem
>      > on it and copy/read/verify some 10gig of data to it. Very basic
>      > testing until now, essentially. However, the whole issue raised some
>      > questions:
>      >
>      > - I pvscsi actively maintained? Is someone working on this or even
>      > prepare it for upstream inclusion in the pv-ops framework of the 3.x
>      > series?
> 
>      So nobody has stepped up to do the upstream task and it is on my todo
>      list
>      but mostly at the end.
>      > - Has anybody started on adding the vscsi-semantics to the xl
>      toolstack?
> 
>      Not that I know of.
>      > - Using 'xm', I was only able to add a device via its SCSI tupel
>      > (HCTL, e.g: vscsi = [ '7:0:0:0, 0:0:0:1' ]) but not by any other
>      > device-node, such as '/dev/sde' or the
>      > '/dev/disk/by-path/<iscsi-iqn>' link. For these invocations, an
>      > "Error: Cannot find device <device>" message is given. I have not
>      > yet looked at the issue in detail (in
>      > /usr/lib64/python2.6/site-packages/xen/util/vscsi_util.py). Is this
>      > a known issue?
> 
>      First time I hear of it. But then I didn't even think to use /dev/sde
>      to pass in a device since SCSI devices aren't neccessarily block ones.
>      They can be scanners, medical devices, tape drivers, etc - which
>      might not have a /dev/sdX (thought they will have an /dev/sgX).
>      >
>      > Is there any developer(s) working on getting pvscsi ready for
>      > [3]kernel.org 3.x upstream inclusion? Should i better retool my
>      efforts
>      > using pv-ops xen/stable 2.6.32 series?
> 
>      For 3.x upstream inclusion - not that I know off.
>      Why would you want to retool your effort in using the 2.6.32 series
>      as opposed to 3.x? What other items is the 3.x missing compared to
>      2.6.32?
> 
>      Now the good news is that I am happy to keep this going (pv-scsi)
>      and fixing it, and having incremental updates to make it better.
>      >
>      > If applicable, I'd be more than happy to provide assistance to move
>      > forward pvscsi. Maybe, as a start, provide a short, practical howto
>      > about what I did above to get pvscsi working and reference it by the
>      > Xen PVSCSI wiki page [3]?
> 
>      Sure. Also, did you use the git tree to pull the patches or just
>      the big patch file ? The git tree has fixes to make it work under 3.2 as
>      well.
>      >
>      > Regards,
>      > Thomas Weyergraf
>      >
>      > [1] [4]http://xenbits.xen.org/people/mayoung/EL6.xen/
>      > [2]
>      [5]http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
>      > [3] [6]http://wiki.xen.org/xenwiki/XenPVSCSI
>      >
>      >
>      >
>      > _______________________________________________
>      > Xen-devel mailing list
>      > [7]Xen-devel@lists.xen.org
>      > [8]http://lists.xen.org/xen-devel
> 
>      _______________________________________________
>      Xen-devel mailing list
>      [9]Xen-devel@lists.xen.org
>      [10]http://lists.xen.org/xen-devel
> 
> References
> 
>    Visible links
>    1. mailto:konrad.wilk@oracle.com
>    2. http://kernel.org/
>    3. http://kernel.org/
>    4. http://xenbits.xen.org/people/mayoung/EL6.xen/
>    5. http://lists.xen.org/archives/html/xen-devel/2011-11/msg02268.html
>    6. http://wiki.xen.org/xenwiki/XenPVSCSI
>    7. mailto:Xen-devel@lists.xen.org
>    8. http://lists.xen.org/xen-devel
>    9. mailto:Xen-devel@lists.xen.org
>   10. http://lists.xen.org/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qVl-00071w-Nt; Fri, 24 Feb 2012 08:28:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0qVk-00071l-5U
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 08:28:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330072088!15614473!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25531 invoked from network); 24 Feb 2012 08:28:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:28:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:28:07 +0000
Message-Id: <4F47582502000078000748B8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:28:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2F012A05.0__="
Cc: espen.skoglund@netronome.com
Subject: [Xen-devel] [PATCH] passthrough: release assigned PCI devices
 earlier during domain 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2F012A05.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

At least with xend, where there's not even a tool stack side attempt to
de-assign devices during domain shutdown, this allows immediate re-
starts of a domain to work reliably. (There's no apparent reason why
c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of
domain destruction).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -673,10 +673,8 @@ void arch_domain_destroy(struct domain *
 		free_xenheap_pages(d->shared_info,
 				   get_order_from_shift(XSI_SHIFT));
=20
-	if ( iommu_enabled && need_iommu(d) )	{
-		pci_release_devices(d);
+	if ( iommu_enabled && need_iommu(d) )
 		iommu_domain_destroy(d);
-	}
=20
 	tlb_track_destroy(d);
=20
@@ -1721,6 +1719,8 @@ int domain_relinquish_resources(struct d
=20
 	switch (d->arch.relres) {
 	case RELRES_not_started:
+		pci_release_devices(d);
+
 		/* Relinquish guest resources for VT-i domain. */
 		if (is_hvm_domain(d))
 			vmx_relinquish_guest_resources(d);
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -657,7 +657,6 @@ void arch_domain_destroy(struct domain *
         xfree(d->arch.pv_domain.e820);
=20
     vmce_destroy_msr(d);
-    pci_release_devices(d);
     free_domain_pirqs(d);
     if ( !is_idle_domain(d) )
         iommu_domain_destroy(d);
@@ -2101,6 +2100,8 @@ int domain_relinquish_resources(struct d
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
+        pci_release_devices(d);
+
         /* Tear down paging-assistance stuff. */
         paging_teardown(d);
=20
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -574,7 +574,8 @@ int iommu_do_domctl(
         break;
=20
     case XEN_DOMCTL_assign_device:
-        if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) )
+        if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) ||
+             unlikely(d->is_dying) )
         {
             printk(XENLOG_G_ERR
                    "XEN_DOMCTL_assign_device: get_domain_by_id() =
failed\n");




--=__Part2F012A05.0__=
Content-Type: text/plain; name="pci-release-devices.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-release-devices.patch"

passthrough: release assigned PCI devices earlier during domain shutdown=0A=
=0AAt least with xend, where there's not even a tool stack side attempt =
to=0Ade-assign devices during domain shutdown, this allows immediate =
re-=0Astarts of a domain to work reliably. (There's no apparent reason =
why=0Ac/s 18010:c1577f094ae4 chose to put this in the asynchronous part =
of=0Adomain destruction).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.co=
m>=0A=0A--- a/xen/arch/ia64/xen/domain.c=0A+++ b/xen/arch/ia64/xen/domain.c=
=0A@@ -673,10 +673,8 @@ void arch_domain_destroy(struct domain *=0A 		=
free_xenheap_pages(d->shared_info,=0A 				   =
get_order_from_shift(XSI_SHIFT));=0A =0A-	if ( iommu_enabled && =
need_iommu(d) )	{=0A-		pci_release_devices(d);=0A+	if ( =
iommu_enabled && need_iommu(d) )=0A 		iommu_domain_destroy(d);=0A=
-	}=0A =0A 	tlb_track_destroy(d);=0A =0A@@ -1721,6 +1719,8 @@ =
int domain_relinquish_resources(struct d=0A =0A 	switch (d->arch.rel=
res) {=0A 	case RELRES_not_started:=0A+		pci_release_devices=
(d);=0A+=0A 		/* Relinquish guest resources for VT-i domain. =
*/=0A 		if (is_hvm_domain(d))=0A 			vmx_relinqu=
ish_guest_resources(d);=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/=
domain.c=0A@@ -657,7 +657,6 @@ void arch_domain_destroy(struct domain *=0A =
        xfree(d->arch.pv_domain.e820);=0A =0A     vmce_destroy_msr(d);=0A- =
   pci_release_devices(d);=0A     free_domain_pirqs(d);=0A     if ( =
!is_idle_domain(d) )=0A         iommu_domain_destroy(d);=0A@@ -2101,6 =
+2100,8 @@ int domain_relinquish_resources(struct d=0A     switch ( =
d->arch.relmem )=0A     {=0A     case RELMEM_not_started:=0A+        =
pci_release_devices(d);=0A+=0A         /* Tear down paging-assistance =
stuff. */=0A         paging_teardown(d);=0A =0A--- a/xen/drivers/passthroug=
h/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -574,7 +574,8 @@ =
int iommu_do_domctl(=0A         break;=0A =0A     case XEN_DOMCTL_assign_de=
vice:=0A-        if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =
=3D=3D NULL) )=0A+        if ( unlikely((d =3D get_domain_by_id(domctl->dom=
ain)) =3D=3D NULL) ||=0A+             unlikely(d->is_dying) )=0A         =
{=0A             printk(XENLOG_G_ERR=0A                    "XEN_DOMCTL_assi=
gn_device: get_domain_by_id() failed\n");=0A
--=__Part2F012A05.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

--=__Part2F012A05.0__=--


From xen-devel-bounces@lists.xen.org Fri Feb 24 08:28:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:28:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qVl-00071w-Nt; Fri, 24 Feb 2012 08:28:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0qVk-00071l-5U
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 08:28:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330072088!15614473!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25531 invoked from network); 24 Feb 2012 08:28:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:28:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:28:07 +0000
Message-Id: <4F47582502000078000748B8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:28:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2F012A05.0__="
Cc: espen.skoglund@netronome.com
Subject: [Xen-devel] [PATCH] passthrough: release assigned PCI devices
 earlier during domain 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2F012A05.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

At least with xend, where there's not even a tool stack side attempt to
de-assign devices during domain shutdown, this allows immediate re-
starts of a domain to work reliably. (There's no apparent reason why
c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of
domain destruction).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -673,10 +673,8 @@ void arch_domain_destroy(struct domain *
 		free_xenheap_pages(d->shared_info,
 				   get_order_from_shift(XSI_SHIFT));
=20
-	if ( iommu_enabled && need_iommu(d) )	{
-		pci_release_devices(d);
+	if ( iommu_enabled && need_iommu(d) )
 		iommu_domain_destroy(d);
-	}
=20
 	tlb_track_destroy(d);
=20
@@ -1721,6 +1719,8 @@ int domain_relinquish_resources(struct d
=20
 	switch (d->arch.relres) {
 	case RELRES_not_started:
+		pci_release_devices(d);
+
 		/* Relinquish guest resources for VT-i domain. */
 		if (is_hvm_domain(d))
 			vmx_relinquish_guest_resources(d);
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -657,7 +657,6 @@ void arch_domain_destroy(struct domain *
         xfree(d->arch.pv_domain.e820);
=20
     vmce_destroy_msr(d);
-    pci_release_devices(d);
     free_domain_pirqs(d);
     if ( !is_idle_domain(d) )
         iommu_domain_destroy(d);
@@ -2101,6 +2100,8 @@ int domain_relinquish_resources(struct d
     switch ( d->arch.relmem )
     {
     case RELMEM_not_started:
+        pci_release_devices(d);
+
         /* Tear down paging-assistance stuff. */
         paging_teardown(d);
=20
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -574,7 +574,8 @@ int iommu_do_domctl(
         break;
=20
     case XEN_DOMCTL_assign_device:
-        if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) )
+        if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =3D=3D =
NULL) ||
+             unlikely(d->is_dying) )
         {
             printk(XENLOG_G_ERR
                    "XEN_DOMCTL_assign_device: get_domain_by_id() =
failed\n");




--=__Part2F012A05.0__=
Content-Type: text/plain; name="pci-release-devices.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-release-devices.patch"

passthrough: release assigned PCI devices earlier during domain shutdown=0A=
=0AAt least with xend, where there's not even a tool stack side attempt =
to=0Ade-assign devices during domain shutdown, this allows immediate =
re-=0Astarts of a domain to work reliably. (There's no apparent reason =
why=0Ac/s 18010:c1577f094ae4 chose to put this in the asynchronous part =
of=0Adomain destruction).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.co=
m>=0A=0A--- a/xen/arch/ia64/xen/domain.c=0A+++ b/xen/arch/ia64/xen/domain.c=
=0A@@ -673,10 +673,8 @@ void arch_domain_destroy(struct domain *=0A 		=
free_xenheap_pages(d->shared_info,=0A 				   =
get_order_from_shift(XSI_SHIFT));=0A =0A-	if ( iommu_enabled && =
need_iommu(d) )	{=0A-		pci_release_devices(d);=0A+	if ( =
iommu_enabled && need_iommu(d) )=0A 		iommu_domain_destroy(d);=0A=
-	}=0A =0A 	tlb_track_destroy(d);=0A =0A@@ -1721,6 +1719,8 @@ =
int domain_relinquish_resources(struct d=0A =0A 	switch (d->arch.rel=
res) {=0A 	case RELRES_not_started:=0A+		pci_release_devices=
(d);=0A+=0A 		/* Relinquish guest resources for VT-i domain. =
*/=0A 		if (is_hvm_domain(d))=0A 			vmx_relinqu=
ish_guest_resources(d);=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/=
domain.c=0A@@ -657,7 +657,6 @@ void arch_domain_destroy(struct domain *=0A =
        xfree(d->arch.pv_domain.e820);=0A =0A     vmce_destroy_msr(d);=0A- =
   pci_release_devices(d);=0A     free_domain_pirqs(d);=0A     if ( =
!is_idle_domain(d) )=0A         iommu_domain_destroy(d);=0A@@ -2101,6 =
+2100,8 @@ int domain_relinquish_resources(struct d=0A     switch ( =
d->arch.relmem )=0A     {=0A     case RELMEM_not_started:=0A+        =
pci_release_devices(d);=0A+=0A         /* Tear down paging-assistance =
stuff. */=0A         paging_teardown(d);=0A =0A--- a/xen/drivers/passthroug=
h/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -574,7 +574,8 @@ =
int iommu_do_domctl(=0A         break;=0A =0A     case XEN_DOMCTL_assign_de=
vice:=0A-        if ( unlikely((d =3D get_domain_by_id(domctl->domain)) =
=3D=3D NULL) )=0A+        if ( unlikely((d =3D get_domain_by_id(domctl->dom=
ain)) =3D=3D NULL) ||=0A+             unlikely(d->is_dying) )=0A         =
{=0A             printk(XENLOG_G_ERR=0A                    "XEN_DOMCTL_assi=
gn_device: get_domain_by_id() failed\n");=0A
--=__Part2F012A05.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

--=__Part2F012A05.0__=--


From xen-devel-bounces@lists.xen.org Fri Feb 24 08:35:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08: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 1S0qck-0007IR-Sp; Fri, 24 Feb 2012 08:35:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0qck-0007IM-74
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:35:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330072523!16687033!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16603 invoked from network); 24 Feb 2012 08:35:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:35:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:35:22 +0000
Message-Id: <4F4759D902000078000748C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:35:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330011462.8557.95.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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 23.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
>> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>> >On 23/02/12 10:07, Ian Campbell wrote:
>> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> >> Can you confirm that you need an OVMF which matches the OS bit-width you
>> >> are installing. i..e that there is no support for booting a 32 bit EFI
>> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>> >
>> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
>> >possibly work.
>> 
>> Native EFI requires bit-matched OS loaders,
> 
> Is that a shortcoming of EFI generally or just this implementation?

I'd assume more the former.

> Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> of loading a 32 bit OS?

When I asked the same question, I was told that the assumption is that
on modern (read: UEFI) systems people aren't expected to run 32-bit
OSes.

And no, I don't think any 32-bit OS comes with a 64-bit bootloader.
Furthermore, to make EFI really work, such an OS would also need
64-bit stubs to call the EFI services - not something that's realistically
going to happen I would think.

If anything, I would have expected that things could work out the
other way around: A 64-bit OS having a 32-bit loader and 32-bit
stubs (which is how we implemented this when, on x86, there was
no 64-bit EFI yet).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:35:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08: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 1S0qck-0007IR-Sp; Fri, 24 Feb 2012 08:35:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0qck-0007IM-74
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:35:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330072523!16687033!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16603 invoked from network); 24 Feb 2012 08:35:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:35:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:35:22 +0000
Message-Id: <4F4759D902000078000748C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:35:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330011462.8557.95.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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 23.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
>> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>> >On 23/02/12 10:07, Ian Campbell wrote:
>> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> >> Can you confirm that you need an OVMF which matches the OS bit-width you
>> >> are installing. i..e that there is no support for booting a 32 bit EFI
>> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>> >
>> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
>> >possibly work.
>> 
>> Native EFI requires bit-matched OS loaders,
> 
> Is that a shortcoming of EFI generally or just this implementation?

I'd assume more the former.

> Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> of loading a 32 bit OS?

When I asked the same question, I was told that the assumption is that
on modern (read: UEFI) systems people aren't expected to run 32-bit
OSes.

And no, I don't think any 32-bit OS comes with a 64-bit bootloader.
Furthermore, to make EFI really work, such an OS would also need
64-bit stubs to call the EFI services - not something that's realistically
going to happen I would think.

If anything, I would have expected that things could work out the
other way around: A 64-bit OS having a 32-bit loader and 32-bit
stubs (which is how we implemented this when, on x86, there was
no 64-bit EFI yet).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qfC-0007O1-FU; Fri, 24 Feb 2012 08:38:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0qfA-0007Nh-P5
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:38:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330072674!15915098!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1790 invoked from network); 24 Feb 2012 08:37:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:37:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:37:54 +0000
Message-Id: <4F475A7002000078000748C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:37:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Len Brown <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Shaohua Li <shaohua.li@intel.com>, "lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.02.12 at 17:58, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>>    depends on ACPI_PROCESSOR
>>>    depends on EXPERIMENTAL
>>>    depends on X86
>>> +    default n
>> 
>> This is pointless.
> 
> Elaborate more? just a little curious why Kconfig has so many default n.

Which are all pointless afaict (and I did already get a couple of
patches merged to remove some of them) - the tool defaults
them to 'n' 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 Feb 24 08:38:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:38:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qfC-0007O1-FU; Fri, 24 Feb 2012 08:38:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0qfA-0007Nh-P5
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:38:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330072674!15915098!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1790 invoked from network); 24 Feb 2012 08:37:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:37:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:37:54 +0000
Message-Id: <4F475A7002000078000748C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:37:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Len Brown <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Shaohua Li <shaohua.li@intel.com>, "lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.02.12 at 17:58, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>>    depends on ACPI_PROCESSOR
>>>    depends on EXPERIMENTAL
>>>    depends on X86
>>> +    default n
>> 
>> This is pointless.
> 
> Elaborate more? just a little curious why Kconfig has so many default n.

Which are all pointless afaict (and I did already get a couple of
patches merged to remove some of them) - the tool defaults
them to 'n' 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 Feb 24 08:44:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qkm-0007av-9Q; Fri, 24 Feb 2012 08:43:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0qkk-0007an-7R
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:43:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330073020!2001513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10836 invoked from network); 24 Feb 2012 08:43:40 -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;
	24 Feb 2012 08:43:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:43:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 08:43:40 +0000
Message-ID: <1330073018.8557.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 24 Feb 2012 08:43:38 +0000
In-Reply-To: <4F4759D902000078000748C4@nat28.tlf.novell.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
	<4F4759D902000078000748C4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 08:35 +0000, Jan Beulich wrote:
> >>> On 23.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
> >> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
> >> >On 23/02/12 10:07, Ian Campbell wrote:
> >> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> >> Can you confirm that you need an OVMF which matches the OS bit-width you
> >> >> are installing. i..e that there is no support for booting a 32 bit EFI
> >> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >> >
> >> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
> >> >possibly work.
> >> 
> >> Native EFI requires bit-matched OS loaders,
> > 
> > Is that a shortcoming of EFI generally or just this implementation?
> 
> I'd assume more the former.
> 
> > Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> > bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> > of loading a 32 bit OS?
> 
> When I asked the same question, I was told that the assumption is that
> on modern (read: UEFI) systems people aren't expected to run 32-bit
> OSes.

Doesn't that apply to running those OSes under Xen to some extent as
well? Can we get away with only supporting 64 bit EFI?

> And no, I don't think any 32-bit OS comes with a 64-bit bootloader.
> Furthermore, to make EFI really work, such an OS would also need
> 64-bit stubs to call the EFI services - not something that's realistically
> going to happen I would think.
> 
> If anything, I would have expected that things could work out the
> other way around: A 64-bit OS having a 32-bit loader and 32-bit
> stubs (which is how we implemented this when, on x86, there was
> no 64-bit EFI yet).

Yes, that does sound more plausible. Does anyone still do that though?
What about in a situation where they could just as easily run a
traditional BIOS (like in a Xen HVM guest)? Why would anyone insist on
being able to use 32 bit EFI if they could just use SeaBIOS? I suppose
the underlying question is: are there any OSes which _only_ support 32
bit EFI and don't support a traditional BIOS?

Ian.
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:44:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qkm-0007av-9Q; Fri, 24 Feb 2012 08:43:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0qkk-0007an-7R
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:43:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330073020!2001513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10836 invoked from network); 24 Feb 2012 08:43:40 -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;
	24 Feb 2012 08:43:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:43:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 08:43:40 +0000
Message-ID: <1330073018.8557.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 24 Feb 2012 08:43:38 +0000
In-Reply-To: <4F4759D902000078000748C4@nat28.tlf.novell.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
	<4F4759D902000078000748C4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 08:35 +0000, Jan Beulich wrote:
> >>> On 23.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
> >> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
> >> >On 23/02/12 10:07, Ian Campbell wrote:
> >> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> >> Can you confirm that you need an OVMF which matches the OS bit-width you
> >> >> are installing. i..e that there is no support for booting a 32 bit EFI
> >> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >> >
> >> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
> >> >possibly work.
> >> 
> >> Native EFI requires bit-matched OS loaders,
> > 
> > Is that a shortcoming of EFI generally or just this implementation?
> 
> I'd assume more the former.
> 
> > Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> > bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> > of loading a 32 bit OS?
> 
> When I asked the same question, I was told that the assumption is that
> on modern (read: UEFI) systems people aren't expected to run 32-bit
> OSes.

Doesn't that apply to running those OSes under Xen to some extent as
well? Can we get away with only supporting 64 bit EFI?

> And no, I don't think any 32-bit OS comes with a 64-bit bootloader.
> Furthermore, to make EFI really work, such an OS would also need
> 64-bit stubs to call the EFI services - not something that's realistically
> going to happen I would think.
> 
> If anything, I would have expected that things could work out the
> other way around: A 64-bit OS having a 32-bit loader and 32-bit
> stubs (which is how we implemented this when, on x86, there was
> no 64-bit EFI yet).

Yes, that does sound more plausible. Does anyone still do that though?
What about in a situation where they could just as easily run a
traditional BIOS (like in a Xen HVM guest)? Why would anyone insist on
being able to use 32 bit EFI if they could just use SeaBIOS? I suppose
the underlying question is: are there any OSes which _only_ support 32
bit EFI and don't support a traditional BIOS?

Ian.
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08: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 1S0qmH-0007fP-Pk; Fri, 24 Feb 2012 08:45:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0qmG-0007ey-OC
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:45:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330073113!9573498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7018 invoked from network); 24 Feb 2012 08:45:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 08:45:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:45:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 08:45:13 +0000
Message-ID: <1330073112.8557.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jordan Justen <jljusten@gmail.com>
Date: Fri, 24 Feb 2012 08:45:12 +0000
In-Reply-To: <CAFe8ug_daC_dKDTr=g0U8CVw_Y67rKyUEoLLUkczSZgE4VicLA@mail.gmail.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
	<CAFe8ug_daC_dKDTr=g0U8CVw_Y67rKyUEoLLUkczSZgE4VicLA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:33 +0000, Jordan Justen wrote:
> On Thu, Feb 23, 2012 at 07:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
> >> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
> >> >On 23/02/12 10:07, Ian Campbell wrote:
> >> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> >> Can you confirm that you need an OVMF which matches the OS bit-width you
> >> >> are installing. i..e that there is no support for booting a 32 bit EFI
> >> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >> >
> >> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could
> >> >possibly work.
> >>
> >> Native EFI requires bit-matched OS loaders,
> >
> > Is that a shortcoming of EFI generally or just this implementation?
> 
> This is basically built into the design of UEFI.  The issue is that
> the firmware boot/runtime calls are only available for the native
> architecture.

Thanks for confirming. I suppose in principal there could be some sort
of compat layer (such as we use for running 32 bit guests on a 64 bit
h/v) but from what you say below it doesn't sound like it would be worth
the time to implement.

> If the OS or loader had support for changing to the native
> architecture before calling these services, it can run in another
> mode.
> 
> > Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> > bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> > of loading a 32 bit OS?
> 
> I don't think people often update their firmware to switch modes.  In
> fact, I think in most cases they don't have that option.  For example,
> most desktop/server systems with UEFI support will likely only support
> UEFI X64.
> 
> The loader or OS could have special support for running under this
> environment.  It would just need to change to the proper CPU mode
> before calling the firmware runtime services.
> 
> In the case of UEFI Linux and Windows x86, I think they only support
> calling UEFI IA32.  In the case of UEFI Linux and Windows x86-64, I
> think they only support calling UEFI X64.

Out of interest do you know any OSes which have good support for 32 bit
UEFI?

Win7 and Ubuntu have support for 64 bit but the 32 bit equivalents don't
appear to.

I'm tempted to suggest that we only support 64 bit UEFI, at least
initially and defer 32 bit support until we have an actual user request
and rationale for that feature.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08: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 1S0qmH-0007fP-Pk; Fri, 24 Feb 2012 08:45:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0qmG-0007ey-OC
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:45:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330073113!9573498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7018 invoked from network); 24 Feb 2012 08:45:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 08:45:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:45:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 08:45:13 +0000
Message-ID: <1330073112.8557.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jordan Justen <jljusten@gmail.com>
Date: Fri, 24 Feb 2012 08:45:12 +0000
In-Reply-To: <CAFe8ug_daC_dKDTr=g0U8CVw_Y67rKyUEoLLUkczSZgE4VicLA@mail.gmail.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
	<CAFe8ug_daC_dKDTr=g0U8CVw_Y67rKyUEoLLUkczSZgE4VicLA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use it
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:33 +0000, Jordan Justen wrote:
> On Thu, Feb 23, 2012 at 07:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
> >> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
> >> >On 23/02/12 10:07, Ian Campbell wrote:
> >> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
> >> >> Can you confirm that you need an OVMF which matches the OS bit-width you
> >> >> are installing. i..e that there is no support for booting a 32 bit EFI
> >> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
> >> >
> >> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could
> >> >possibly work.
> >>
> >> Native EFI requires bit-matched OS loaders,
> >
> > Is that a shortcoming of EFI generally or just this implementation?
> 
> This is basically built into the design of UEFI.  The issue is that
> the firmware boot/runtime calls are only available for the native
> architecture.

Thanks for confirming. I suppose in principal there could be some sort
of compat layer (such as we use for running 32 bit guests on a 64 bit
h/v) but from what you say below it doesn't sound like it would be worth
the time to implement.

> If the OS or loader had support for changing to the native
> architecture before calling these services, it can run in another
> mode.
> 
> > Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
> > bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
> > of loading a 32 bit OS?
> 
> I don't think people often update their firmware to switch modes.  In
> fact, I think in most cases they don't have that option.  For example,
> most desktop/server systems with UEFI support will likely only support
> UEFI X64.
> 
> The loader or OS could have special support for running under this
> environment.  It would just need to change to the proper CPU mode
> before calling the firmware runtime services.
> 
> In the case of UEFI Linux and Windows x86, I think they only support
> calling UEFI IA32.  In the case of UEFI Linux and Windows x86-64, I
> think they only support calling UEFI X64.

Out of interest do you know any OSes which have good support for 32 bit
UEFI?

Win7 and Ubuntu have support for 64 bit but the 32 bit equivalents don't
appear to.

I'm tempted to suggest that we only support 64 bit UEFI, at least
initially and defer 32 bit support until we have an actual user request
and rationale for that feature.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:50:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qqy-0007tn-GS; Fri, 24 Feb 2012 08:50: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 1S0qqx-0007td-1h
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:50:11 +0000
Received: from [85.158.139.83:52326] by server-7.bemta-5.messagelabs.com id
	32/5F-16195-24F474F4; Fri, 24 Feb 2012 08:50:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330073408!9126160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21464 invoked from network); 24 Feb 2012 08:50:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:50:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:50:04 +0000
Message-Id: <4F475D4B02000078000748F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:50:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
	<4F4759D902000078000748C4@nat28.tlf.novell.com>
	<1330073018.8557.109.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330073018.8557.109.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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 24.02.12 at 09:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-02-24 at 08:35 +0000, Jan Beulich wrote:
>> >>> On 23.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
>> >> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>> >> >On 23/02/12 10:07, Ian Campbell wrote:
>> >> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> >> >> Can you confirm that you need an OVMF which matches the OS bit-width you
>> >> >> are installing. i..e that there is no support for booting a 32 bit EFI
>> >> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>> >> >
>> >> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
>> >> >possibly work.
>> >> 
>> >> Native EFI requires bit-matched OS loaders,
>> > 
>> > Is that a shortcoming of EFI generally or just this implementation?
>> 
>> I'd assume more the former.
>> 
>> > Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
>> > bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
>> > of loading a 32 bit OS?
>> 
>> When I asked the same question, I was told that the assumption is that
>> on modern (read: UEFI) systems people aren't expected to run 32-bit
>> OSes.
> 
> Doesn't that apply to running those OSes under Xen to some extent as
> well? Can we get away with only supporting 64 bit EFI?

If we don't care about 32-bit OSes using EFI, yes.

>> And no, I don't think any 32-bit OS comes with a 64-bit bootloader.
>> Furthermore, to make EFI really work, such an OS would also need
>> 64-bit stubs to call the EFI services - not something that's realistically
>> going to happen I would think.
>> 
>> If anything, I would have expected that things could work out the
>> other way around: A 64-bit OS having a 32-bit loader and 32-bit
>> stubs (which is how we implemented this when, on x86, there was
>> no 64-bit EFI yet).
> 
> Yes, that does sound more plausible. Does anyone still do that though?

I don't think so (and what we did never got released in any form).

> What about in a situation where they could just as easily run a
> traditional BIOS (like in a Xen HVM guest)? Why would anyone insist on
> being able to use 32 bit EFI if they could just use SeaBIOS? I suppose
> the underlying question is: are there any OSes which _only_ support 32
> bit EFI and don't support a traditional BIOS?

I'm unaware of such OSes (and it would make pretty little sense to me
for the next couple of years). But it is clear that without legacy BIOS
support (which the ultimate goal of UEFI is), there's not going to be
a legacy (BIOS) boot method, and hence 32-bit OSes will be impossible
to run on such systems.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:50:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qqy-0007tn-GS; Fri, 24 Feb 2012 08:50: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 1S0qqx-0007td-1h
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:50:11 +0000
Received: from [85.158.139.83:52326] by server-7.bemta-5.messagelabs.com id
	32/5F-16195-24F474F4; Fri, 24 Feb 2012 08:50:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330073408!9126160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21464 invoked from network); 24 Feb 2012 08:50:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 08:50:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 08:50:04 +0000
Message-Id: <4F475D4B02000078000748F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 08:50:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <patchbomb.1329938232@dhcp-3-145.uk.xensource.com>
	<032fea10f8d121fe7db0.1329938233@dhcp-3-145.uk.xensource.com>
	<1329991630.8557.52.camel@zakaz.uk.xensource.com>
	<4F461276.1030108@citrix.com>
	<4F4651A7020000780007F749@nat28.tlf.novell.com>
	<1330011462.8557.95.camel@zakaz.uk.xensource.com>
	<4F4759D902000078000748C4@nat28.tlf.novell.com>
	<1330073018.8557.109.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330073018.8557.109.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gbtju85@gmail.com" <gbtju85@gmail.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Add the support for Xen to include
 OVMF UEFI support and directly use 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 24.02.12 at 09:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-02-24 at 08:35 +0000, Jan Beulich wrote:
>> >>> On 23.02.12 at 16:37, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Thu, 2012-02-23 at 14:48 +0000, Jan Beulich wrote:
>> >> >>> Attilio Rao <attilio.rao@citrix.com> 02/23/12 11:18 AM >>>
>> >> >On 23/02/12 10:07, Ian Campbell wrote:
>> >> >> On Wed, 2012-02-22 at 19:17 +0000, Attilio Rao wrote:
>> >> >> Can you confirm that you need an OVMF which matches the OS bit-width you
>> >> >> are installing. i..e that there is no support for booting a 32 bit EFI
>> >> >> OS (or bootloader, shell, whatever it is called) on a 64 bit OVMF?
>> >> >
>> >> >I didn't test this case, really, but I would think OVMF-64 / OS-32 could 
>> >> >possibly work.
>> >> 
>> >> Native EFI requires bit-matched OS loaders,
>> > 
>> > Is that a shortcoming of EFI generally or just this implementation?
>> 
>> I'd assume more the former.
>> 
>> > Surely people don't reflash their "BIOS" to be able to run a 32 vs 64
>> > bit OS? Or do most OSes (even 32 bit ones) have a 64 bit loader capable
>> > of loading a 32 bit OS?
>> 
>> When I asked the same question, I was told that the assumption is that
>> on modern (read: UEFI) systems people aren't expected to run 32-bit
>> OSes.
> 
> Doesn't that apply to running those OSes under Xen to some extent as
> well? Can we get away with only supporting 64 bit EFI?

If we don't care about 32-bit OSes using EFI, yes.

>> And no, I don't think any 32-bit OS comes with a 64-bit bootloader.
>> Furthermore, to make EFI really work, such an OS would also need
>> 64-bit stubs to call the EFI services - not something that's realistically
>> going to happen I would think.
>> 
>> If anything, I would have expected that things could work out the
>> other way around: A 64-bit OS having a 32-bit loader and 32-bit
>> stubs (which is how we implemented this when, on x86, there was
>> no 64-bit EFI yet).
> 
> Yes, that does sound more plausible. Does anyone still do that though?

I don't think so (and what we did never got released in any form).

> What about in a situation where they could just as easily run a
> traditional BIOS (like in a Xen HVM guest)? Why would anyone insist on
> being able to use 32 bit EFI if they could just use SeaBIOS? I suppose
> the underlying question is: are there any OSes which _only_ support 32
> bit EFI and don't support a traditional BIOS?

I'm unaware of such OSes (and it would make pretty little sense to me
for the next couple of years). But it is clear that without legacy BIOS
support (which the ultimate goal of UEFI is), there's not going to be
a legacy (BIOS) boot method, and hence 32-bit OSes will be impossible
to run on such systems.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:55:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0qvV-00086i-7Q; Fri, 24 Feb 2012 08:54:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0qvT-00086O-HC
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:54:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330073685!2437431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15139 invoked from network); 24 Feb 2012 08:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 08:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:54:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 08:54:45 +0000
Message-ID: <1330073683.8557.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Fri, 24 Feb 2012 08:54:43 +0000
In-Reply-To: <4F46FE89.3050209@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F456136.7070904@suse.com>
	<1329987543.8557.24.camel@zakaz.uk.xensource.com>
	<4F46FE89.3050209@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error	of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 03:05 +0000, Jim Fehlig wrote:
> > I was wondering the other day if "libxl v2" support for libvirt might
> > make a nice GSoC project, what do you think? Would you be interested in
> > mentoring such a project?
> >   
> 
> I agree that it would make a nice GSoC project, but I had encouraged
> Bamvor to take on the task.  It's a good project for becoming familiar
> with xen and libvirt.
> 

Absolutely, good to see Bamvor will be working on it!

Are there any related subprojects or features relating to libvirt+libxl
which might make a good GSoC 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 Feb 24 08:55:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0qvV-00086i-7Q; Fri, 24 Feb 2012 08:54:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0qvT-00086O-HC
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:54:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330073685!2437431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15139 invoked from network); 24 Feb 2012 08:54:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 08:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:54:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 08:54:45 +0000
Message-ID: <1330073683.8557.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Fri, 24 Feb 2012 08:54:43 +0000
In-Reply-To: <4F46FE89.3050209@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F456136.7070904@suse.com>
	<1329987543.8557.24.camel@zakaz.uk.xensource.com>
	<4F46FE89.3050209@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error	of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 03:05 +0000, Jim Fehlig wrote:
> > I was wondering the other day if "libxl v2" support for libvirt might
> > make a nice GSoC project, what do you think? Would you be interested in
> > mentoring such a project?
> >   
> 
> I agree that it would make a nice GSoC project, but I had encouraged
> Bamvor to take on the task.  It's a good project for becoming familiar
> with xen and libvirt.
> 

Absolutely, good to see Bamvor will be working on it!

Are there any related subprojects or features relating to libvirt+libxl
which might make a good GSoC 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 Feb 24 08:56:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qxL-0008D2-7N; Fri, 24 Feb 2012 08:56:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1S0qxJ-0008Bz-Lt
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:56:46 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330073797!15918006!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDkwMTk=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDkwMTk=\n,HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1377 invoked from network); 24 Feb 2012 08:56:38 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-5.tower-216.messagelabs.com with SMTP;
	24 Feb 2012 08:56:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=5fgTHIBe4ch8oRA0PIOt0iFeNjrIAOfz1c
	bVmo6t+/E=; b=X2osnK0lbfTNWYr++Kxg0XWDXR9Biy/e7338vC9rDaY7pzF61p
	w8jbRU0d95MO1Zj6iBXzNP50UnDvQ/6SO+LoqSXLlSIhpm/gnrKYoATftIa7WA8c
	C6sBRSvZl7PSNU7Kfa9M8+hCiGQ7y7FNwREtapi75VEzTgi1Ydsab2UNo=
Received: from hxkhust ( [115.156.232.62] ) by ajax-webmail-wmsvr25
	(Coremail) ; Fri, 24 Feb 2012 16:56:34 +0800 (CST)
Date: Fri, 24 Feb 2012 16:56:34 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <4af547bc.27d91.135ae937975.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [115.156.232.62]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: YGXjQGZvb3Rlcl9odG09MzcyOjgx
X-CM-TRANSID: GcqowGCJMUPDUEdPDlArAA--.253W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiaRdeBU1rxRi09gACse
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] the impeimentation details of I/O virtualization under
 fully-virtualized condition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3479768100246964667=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3479768100246964667==
Content-Type: multipart/alternative; 
	boundary="----=_Part_431432_2112520421.1330073794932"

------=_Part_431432_2112520421.1330073794932
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

HI,
 
If I would like to know about the implementation details of I/O virtualization under fully-virtualized condition of xen,which paper or which web site shall I refer to first?
Thank you.
 
hxk
 
------=_Part_431432_2112520421.1330073794932
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>HI,</DIV>
<DIV>&nbsp;</DIV>
<DIV>If I would like to know about the implementation details of I/O virtualization under fully-virtualized condition of xen,which paper or which web site shall I refer to first?</DIV>
<DIV>Thank you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>hxk</DIV>
<DIV>&nbsp;</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_431432_2112520421.1330073794932--



--===============3479768100246964667==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3479768100246964667==--



From xen-devel-bounces@lists.xen.org Fri Feb 24 08:56:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0qxL-0008D2-7N; Fri, 24 Feb 2012 08:56:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1S0qxJ-0008Bz-Lt
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:56:46 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330073797!15918006!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDkwMTk=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDkwMTk=\n,HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1377 invoked from network); 24 Feb 2012 08:56:38 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-5.tower-216.messagelabs.com with SMTP;
	24 Feb 2012 08:56:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Message-ID:Subject:
	MIME-Version:Content-Type; bh=5fgTHIBe4ch8oRA0PIOt0iFeNjrIAOfz1c
	bVmo6t+/E=; b=X2osnK0lbfTNWYr++Kxg0XWDXR9Biy/e7338vC9rDaY7pzF61p
	w8jbRU0d95MO1Zj6iBXzNP50UnDvQ/6SO+LoqSXLlSIhpm/gnrKYoATftIa7WA8c
	C6sBRSvZl7PSNU7Kfa9M8+hCiGQ7y7FNwREtapi75VEzTgi1Ydsab2UNo=
Received: from hxkhust ( [115.156.232.62] ) by ajax-webmail-wmsvr25
	(Coremail) ; Fri, 24 Feb 2012 16:56:34 +0800 (CST)
Date: Fri, 24 Feb 2012 16:56:34 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <4af547bc.27d91.135ae937975.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [115.156.232.62]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: YGXjQGZvb3Rlcl9odG09MzcyOjgx
X-CM-TRANSID: GcqowGCJMUPDUEdPDlArAA--.253W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiaRdeBU1rxRi09gACse
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] the impeimentation details of I/O virtualization under
 fully-virtualized condition
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3479768100246964667=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3479768100246964667==
Content-Type: multipart/alternative; 
	boundary="----=_Part_431432_2112520421.1330073794932"

------=_Part_431432_2112520421.1330073794932
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

HI,
 
If I would like to know about the implementation details of I/O virtualization under fully-virtualized condition of xen,which paper or which web site shall I refer to first?
Thank you.
 
hxk
 
------=_Part_431432_2112520421.1330073794932
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>HI,</DIV>
<DIV>&nbsp;</DIV>
<DIV>If I would like to know about the implementation details of I/O virtualization under fully-virtualized condition of xen,which paper or which web site shall I refer to first?</DIV>
<DIV>Thank you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>hxk</DIV>
<DIV>&nbsp;</DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_431432_2112520421.1330073794932--



--===============3479768100246964667==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3479768100246964667==--



From xen-devel-bounces@lists.xen.org Fri Feb 24 08:57:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08: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 1S0qxH-0008CF-Mw; Fri, 24 Feb 2012 08:56:43 +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 1S0qxF-0008C3-As
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:56:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330073663!50077178!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7423 invoked from network); 24 Feb 2012 08:54:23 -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;
	24 Feb 2012 08:54:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:56:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 08:56:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0qxD-0004Mr-5h;
	Fri, 24 Feb 2012 08:56:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0qxC-0006Si-EP;
	Fri, 24 Feb 2012 08:56:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12036-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 08:56:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12036: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12036 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12036/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 08:57:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 08: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 1S0qxH-0008CF-Mw; Fri, 24 Feb 2012 08:56:43 +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 1S0qxF-0008C3-As
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 08:56:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330073663!50077178!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7423 invoked from network); 24 Feb 2012 08:54:23 -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;
	24 Feb 2012 08:54:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 08:56:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 08:56:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0qxD-0004Mr-5h;
	Fri, 24 Feb 2012 08:56:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0qxC-0006Si-EP;
	Fri, 24 Feb 2012 08:56:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12036-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 08:56:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12036: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12036 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12036/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 09:01:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 09:01:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0r1r-00008Q-2r; Fri, 24 Feb 2012 09:01:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0r1p-000088-CF
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 09:01:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330074078!14697061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15798 invoked from network); 24 Feb 2012 09:01:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 09:01:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 09:01:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 09:01:18 +0000
Message-ID: <1330074077.8557.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 09:01:17 +0000
In-Reply-To: <1330008712-17715-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
	<1330008712-17715-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 14:51 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_dom_arm.c.
> Provide empty implementations of xc_domain_save and xc_domain_restore
> when CONFIG_MIGRATE is not set.
> Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
> x86 specific, introduce xc_hvm_build_arm.c with empty stubs.
> 
> 
> Changes in v3:
> 
> - rename xc_hvm_build.c to xc_hvm_build_x86.c;
> 
> - remove xc_nohvm, introduce xc_hvm_build_arm.c instead;
> 
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

If you happen to repost then updating the copyright lines to say 2012
instead of 2011 might be useful. I'd also encourage the use of
"format-patch -M" in the future -- it makes renames much easier to
review.

> ---
>  tools/libxc/Makefile           |   12 +-
>  tools/libxc/xc_dom_arm.c       |   50 ++++
>  tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
>  tools/libxc/xc_hvm_build_arm.c |   61 +++++
>  tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_nomigrate.c     |   53 ++++
>  6 files changed, 684 insertions(+), 514 deletions(-)
>  create mode 100644 tools/libxc/xc_dom_arm.c
>  delete mode 100644 tools/libxc/xc_hvm_build.c
>  create mode 100644 tools/libxc/xc_hvm_build_arm.c
>  create mode 100644 tools/libxc/xc_hvm_build_x86.c
>  create mode 100644 tools/libxc/xc_nomigrate.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index f2e1ba7..02d39a3 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
> 
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
> -GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
> +ifeq ($(CONFIG_MIGRATE),y)
> +GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
> +GUEST_SRCS-y += xc_offline_page.c xc_compression.c
> +else
> +GUEST_SRCS-y += xc_nomigrate.c
> +endif
> 
>  vpath %.c ../../xen/common/libelf
>  CFLAGS += -I../../xen/common/libelf
> @@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
> 
>  GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
> +GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
>  GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
> +GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
> +GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
> 
>  OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
> 
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> new file mode 100644
> index 0000000..122d0e8
> --- /dev/null
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -0,0 +1,50 @@
> +/*
> + * Xen domain builder -- ARM
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +#include <inttypes.h>
> +#include <xen/xen.h>
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +
> +int arch_setup_meminit(struct xc_dom_image *dom)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int arch_setup_bootearly(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +
> +int arch_setup_bootlate(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
> deleted file mode 100644
> index 1fa5658..0000000
> --- a/tools/libxc/xc_hvm_build.c
> +++ /dev/null
> @@ -1,511 +0,0 @@
> -/******************************************************************************
> - * xc_hvm_build.c
> - *
> - * This library is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation;
> - * version 2.1 of the License.
> - *
> - * This library is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with this library; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> - */
> -
> -#include <stddef.h>
> -#include <inttypes.h>
> -#include <stdlib.h>
> -#include <unistd.h>
> -#include <zlib.h>
> -
> -#include "xg_private.h"
> -#include "xc_private.h"
> -
> -#include <xen/foreign/x86_32.h>
> -#include <xen/foreign/x86_64.h>
> -#include <xen/hvm/hvm_info_table.h>
> -#include <xen/hvm/params.h>
> -#include <xen/hvm/e820.h>
> -
> -#include <xen/libelf/libelf.h>
> -
> -#define SUPERPAGE_2MB_SHIFT   9
> -#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
> -#define SUPERPAGE_1GB_SHIFT   18
> -#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> -
> -#define SPECIALPAGE_BUFIOREQ 0
> -#define SPECIALPAGE_XENSTORE 1
> -#define SPECIALPAGE_IOREQ    2
> -#define SPECIALPAGE_IDENT_PT 3
> -#define SPECIALPAGE_CONSOLE  4
> -#define NR_SPECIAL_PAGES     5
> -#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
> -
> -static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
> -{
> -    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
> -        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> -    uint64_t lowmem_end = mem_size, highmem_end = 0;
> -    uint8_t sum;
> -    int i;
> -
> -    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
> -    {
> -        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
> -        lowmem_end = HVM_BELOW_4G_RAM_END;
> -    }
> -
> -    memset(hvm_info_page, 0, PAGE_SIZE);
> -
> -    /* Fill in the header. */
> -    strncpy(hvm_info->signature, "HVM INFO", 8);
> -    hvm_info->length = sizeof(struct hvm_info_table);
> -
> -    /* Sensible defaults: these can be overridden by the caller. */
> -    hvm_info->apic_mode = 1;
> -    hvm_info->nr_vcpus = 1;
> -    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
> -
> -    /* Memory parameters. */
> -    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
> -    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
> -    hvm_info->reserved_mem_pgstart = special_pfn(0);
> -
> -    /* Finish with the checksum. */
> -    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
> -        sum += ((uint8_t *)hvm_info)[i];
> -    hvm_info->checksum = -sum;
> -}
> -
> -static int loadelfimage(
> -    xc_interface *xch,
> -    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
> -{
> -    privcmd_mmap_entry_t *entries = NULL;
> -    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
> -    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
> -    size_t pages = pfn_end - pfn_start;
> -    int i, rc = -1;
> -
> -    /* Map address space for initial elf image. */
> -    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
> -    if ( entries == NULL )
> -        goto err;
> -
> -    for ( i = 0; i < pages; i++ )
> -        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
> -
> -    elf->dest = xc_map_foreign_ranges(
> -        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
> -        entries, pages);
> -    if ( elf->dest == NULL )
> -        goto err;
> -
> -    elf->dest += elf->pstart & (PAGE_SIZE - 1);
> -
> -    /* Load the initial elf image. */
> -    rc = elf_load_binary(elf);
> -    if ( rc < 0 )
> -        PERROR("Failed to load elf binary\n");
> -
> -    munmap(elf->dest, pages << PAGE_SHIFT);
> -    elf->dest = NULL;
> -
> - err:
> -    free(entries);
> -
> -    return rc;
> -}
> -
> -/*
> - * Check whether there exists mmio hole in the specified memory range.
> - * Returns 1 if exists, else returns 0.
> - */
> -static int check_mmio_hole(uint64_t start, uint64_t memsize)
> -{
> -    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
> -         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
> -        return 0;
> -    else
> -        return 1;
> -}
> -
> -static int setup_guest(xc_interface *xch,
> -                       uint32_t dom, int memsize, int target,
> -                       char *image, unsigned long image_size)
> -{
> -    xen_pfn_t *page_array = NULL;
> -    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
> -    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
> -    unsigned long entry_eip, cur_pages, cur_pfn;
> -    void *hvm_info_page;
> -    uint32_t *ident_pt;
> -    struct elf_binary elf;
> -    uint64_t v_start, v_end;
> -    int rc;
> -    xen_capabilities_info_t caps;
> -    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
> -        stat_1gb_pages = 0;
> -    int pod_mode = 0;
> -
> -    /* An HVM guest must be initialised with at least 2MB memory. */
> -    if ( memsize < 2 || target < 2 )
> -        goto error_out;
> -
> -    if ( memsize > target )
> -        pod_mode = 1;
> -
> -    memset(&elf, 0, sizeof(elf));
> -    if ( elf_init(&elf, image, image_size) != 0 )
> -        goto error_out;
> -
> -    xc_elf_set_logfile(xch, &elf, 1);
> -
> -    elf_parse_binary(&elf);
> -    v_start = 0;
> -    v_end = (unsigned long long)memsize << 20;
> -
> -    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
> -    {
> -        PERROR("Could not get Xen capabilities");
> -        goto error_out;
> -    }
> -
> -    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
> -            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
> -            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
> -            "  ENTRY ADDRESS: %016"PRIx64"\n",
> -            elf.pstart, elf.pend,
> -            v_start, v_end,
> -            elf_uval(&elf, elf.ehdr, e_entry));
> -
> -    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
> -    {
> -        PERROR("Could not allocate memory.");
> -        goto error_out;
> -    }
> -
> -    for ( i = 0; i < nr_pages; i++ )
> -        page_array[i] = i;
> -    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
> -        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
> -
> -    /*
> -     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
> -     *
> -     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
> -     * pages if 1GB allocation fails. 4KB pages will be used eventually if
> -     * both fail.
> -     *
> -     * Under 2MB mode, we allocate pages in batches of no more than 8MB to
> -     * ensure that we can be preempted and hence dom0 remains responsive.
> -     */
> -    rc = xc_domain_populate_physmap_exact(
> -        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
> -    cur_pages = 0xc0;
> -    stat_normal_pages = 0xc0;
> -    while ( (rc == 0) && (nr_pages > cur_pages) )
> -    {
> -        /* Clip count to maximum 1GB extent. */
> -        unsigned long count = nr_pages - cur_pages;
> -        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
> -
> -        if ( count > max_pages )
> -            count = max_pages;
> -
> -        cur_pfn = page_array[cur_pages];
> -
> -        /* Take care the corner cases of super page tails */
> -        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> -             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
> -            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
> -        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> -                  (count > SUPERPAGE_1GB_NR_PFNS) )
> -            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
> -
> -        /* Attemp to allocate 1GB super page. Because in each pass we only
> -         * allocate at most 1GB, we don't have to clip super page boundaries.
> -         */
> -        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
> -             /* Check if there exists MMIO hole in the 1GB memory range */
> -             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
> -                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
> -        {
> -            long done;
> -            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
> -            xen_pfn_t sp_extents[nr_extents];
> -
> -            for ( i = 0; i < nr_extents; i++ )
> -                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
> -
> -            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
> -                                              pod_mode ? XENMEMF_populate_on_demand : 0,
> -                                              sp_extents);
> -
> -            if ( done > 0 )
> -            {
> -                stat_1gb_pages += done;
> -                done <<= SUPERPAGE_1GB_SHIFT;
> -                cur_pages += done;
> -                count -= done;
> -            }
> -        }
> -
> -        if ( count != 0 )
> -        {
> -            /* Clip count to maximum 8MB extent. */
> -            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
> -            if ( count > max_pages )
> -                count = max_pages;
> -
> -            /* Clip partial superpage extents to superpage boundaries. */
> -            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> -                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
> -                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
> -            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> -                      (count > SUPERPAGE_2MB_NR_PFNS) )
> -                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
> -
> -            /* Attempt to allocate superpage extents. */
> -            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
> -            {
> -                long done;
> -                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
> -                xen_pfn_t sp_extents[nr_extents];
> -
> -                for ( i = 0; i < nr_extents; i++ )
> -                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
> -
> -                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
> -                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
> -                                                  sp_extents);
> -
> -                if ( done > 0 )
> -                {
> -                    stat_2mb_pages += done;
> -                    done <<= SUPERPAGE_2MB_SHIFT;
> -                    cur_pages += done;
> -                    count -= done;
> -                }
> -            }
> -        }
> -
> -        /* Fall back to 4kB extents. */
> -        if ( count != 0 )
> -        {
> -            rc = xc_domain_populate_physmap_exact(
> -                xch, dom, count, 0, 0, &page_array[cur_pages]);
> -            cur_pages += count;
> -            stat_normal_pages += count;
> -        }
> -    }
> -
> -    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
> -     * adjust the PoD cache size so that domain tot_pages will be
> -     * target_pages - 0x20 after this call. */
> -    if ( pod_mode )
> -        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
> -                                      NULL, NULL, NULL);
> -
> -    if ( rc != 0 )
> -    {
> -        PERROR("Could not allocate memory for HVM guest.");
> -        goto error_out;
> -    }
> -
> -    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
> -            "  4KB PAGES: 0x%016lx\n"
> -            "  2MB PAGES: 0x%016lx\n"
> -            "  1GB PAGES: 0x%016lx\n",
> -            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
> -
> -    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
> -        goto error_out;
> -
> -    if ( (hvm_info_page = xc_map_foreign_range(
> -              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> -              HVM_INFO_PFN)) == NULL )
> -        goto error_out;
> -    build_hvm_info(hvm_info_page, v_end);
> -    munmap(hvm_info_page, PAGE_SIZE);
> -
> -    /* Allocate and clear special pages. */
> -    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
> -    {
> -        xen_pfn_t pfn = special_pfn(i);
> -        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
> -        if ( rc != 0 )
> -        {
> -            PERROR("Could not allocate %d'th special page.", i);
> -            goto error_out;
> -        }
> -        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
> -            goto error_out;
> -    }
> -
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
> -                     special_pfn(SPECIALPAGE_XENSTORE));
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
> -                     special_pfn(SPECIALPAGE_BUFIOREQ));
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
> -                     special_pfn(SPECIALPAGE_IOREQ));
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
> -                     special_pfn(SPECIALPAGE_CONSOLE));
> -
> -    /*
> -     * Identity-map page table is required for running with CR0.PG=0 when
> -     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
> -     */
> -    if ( (ident_pt = xc_map_foreign_range(
> -              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> -              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
> -        goto error_out;
> -    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
> -        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
> -                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
> -    munmap(ident_pt, PAGE_SIZE);
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> -                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
> -
> -    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
> -    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
> -    if ( entry_eip != 0 )
> -    {
> -        char *page0 = xc_map_foreign_range(
> -            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
> -        if ( page0 == NULL )
> -            goto error_out;
> -        page0[0] = 0xe9;
> -        *(uint32_t *)&page0[1] = entry_eip - 5;
> -        munmap(page0, PAGE_SIZE);
> -    }
> -
> -    free(page_array);
> -    return 0;
> -
> - error_out:
> -    free(page_array);
> -    return -1;
> -}
> -
> -static int xc_hvm_build_internal(xc_interface *xch,
> -                                 uint32_t domid,
> -                                 int memsize,
> -                                 int target,
> -                                 char *image,
> -                                 unsigned long image_size)
> -{
> -    if ( (image == NULL) || (image_size == 0) )
> -    {
> -        ERROR("Image required");
> -        return -1;
> -    }
> -
> -    return setup_guest(xch, domid, memsize, target, image, image_size);
> -}
> -
> -/* xc_hvm_build:
> - * Create a domain for a virtualized Linux, using files/filenames.
> - */
> -int xc_hvm_build(xc_interface *xch,
> -                 uint32_t domid,
> -                 int memsize,
> -                 const char *image_name)
> -{
> -    char *image;
> -    int  sts;
> -    unsigned long image_size;
> -
> -    if ( (image_name == NULL) ||
> -         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> -        return -1;
> -
> -    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
> -
> -    free(image);
> -
> -    return sts;
> -}
> -
> -/* xc_hvm_build_target_mem:
> - * Create a domain for a pre-ballooned virtualized Linux, using
> - * files/filenames.  If target < memsize, domain is created with
> - * memsize pages marked populate-on-demand,
> - * calculating pod cache size based on target.
> - * If target == memsize, pages are populated normally.
> - */
> -int xc_hvm_build_target_mem(xc_interface *xch,
> -                           uint32_t domid,
> -                           int memsize,
> -                           int target,
> -                           const char *image_name)
> -{
> -    char *image;
> -    int  sts;
> -    unsigned long image_size;
> -
> -    if ( (image_name == NULL) ||
> -         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> -        return -1;
> -
> -    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
> -
> -    free(image);
> -
> -    return sts;
> -}
> -
> -/* xc_hvm_build_mem:
> - * Create a domain for a virtualized Linux, using memory buffers.
> - */
> -int xc_hvm_build_mem(xc_interface *xch,
> -                     uint32_t domid,
> -                     int memsize,
> -                     const char *image_buffer,
> -                     unsigned long image_size)
> -{
> -    int           sts;
> -    unsigned long img_len;
> -    char         *img;
> -
> -    /* Validate that there is a kernel buffer */
> -
> -    if ( (image_buffer == NULL) || (image_size == 0) )
> -    {
> -        ERROR("kernel image buffer not present");
> -        return -1;
> -    }
> -
> -    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
> -    if ( img == NULL )
> -    {
> -        ERROR("unable to inflate ram disk buffer");
> -        return -1;
> -    }
> -
> -    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
> -                                img, img_len);
> -
> -    /* xc_inflate_buffer may return the original buffer pointer (for
> -       for already inflated buffers), so exercise some care in freeing */
> -
> -    if ( (img != NULL) && (img != image_buffer) )
> -        free(img);
> -
> -    return sts;
> -}
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-set-style: "BSD"
> - * c-basic-offset: 4
> - * tab-width: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
> new file mode 100644
> index 0000000..010ebdb
> --- /dev/null
> +++ b/tools/libxc/xc_hvm_build_arm.c
> @@ -0,0 +1,61 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_hvm_build(xc_interface *xch,
> +                 uint32_t domid,
> +                 int memsize,
> +                 const char *image_name)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int xc_hvm_build_target_mem(xc_interface *xch,
> +                           uint32_t domid,
> +                           int memsize,
> +                           int target,
> +                           const char *image_name)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int xc_hvm_build_mem(xc_interface *xch,
> +                     uint32_t domid,
> +                     int memsize,
> +                     const char *image_buffer,
> +                     unsigned long image_size)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> new file mode 100644
> index 0000000..1fa5658
> --- /dev/null
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -0,0 +1,511 @@
> +/******************************************************************************
> + * xc_hvm_build.c
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +#include <stddef.h>
> +#include <inttypes.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <zlib.h>
> +
> +#include "xg_private.h"
> +#include "xc_private.h"
> +
> +#include <xen/foreign/x86_32.h>
> +#include <xen/foreign/x86_64.h>
> +#include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/params.h>
> +#include <xen/hvm/e820.h>
> +
> +#include <xen/libelf/libelf.h>
> +
> +#define SUPERPAGE_2MB_SHIFT   9
> +#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
> +#define SUPERPAGE_1GB_SHIFT   18
> +#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> +
> +#define SPECIALPAGE_BUFIOREQ 0
> +#define SPECIALPAGE_XENSTORE 1
> +#define SPECIALPAGE_IOREQ    2
> +#define SPECIALPAGE_IDENT_PT 3
> +#define SPECIALPAGE_CONSOLE  4
> +#define NR_SPECIAL_PAGES     5
> +#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
> +
> +static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
> +{
> +    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
> +        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> +    uint64_t lowmem_end = mem_size, highmem_end = 0;
> +    uint8_t sum;
> +    int i;
> +
> +    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
> +    {
> +        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
> +        lowmem_end = HVM_BELOW_4G_RAM_END;
> +    }
> +
> +    memset(hvm_info_page, 0, PAGE_SIZE);
> +
> +    /* Fill in the header. */
> +    strncpy(hvm_info->signature, "HVM INFO", 8);
> +    hvm_info->length = sizeof(struct hvm_info_table);
> +
> +    /* Sensible defaults: these can be overridden by the caller. */
> +    hvm_info->apic_mode = 1;
> +    hvm_info->nr_vcpus = 1;
> +    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
> +
> +    /* Memory parameters. */
> +    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
> +    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
> +    hvm_info->reserved_mem_pgstart = special_pfn(0);
> +
> +    /* Finish with the checksum. */
> +    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
> +        sum += ((uint8_t *)hvm_info)[i];
> +    hvm_info->checksum = -sum;
> +}
> +
> +static int loadelfimage(
> +    xc_interface *xch,
> +    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
> +{
> +    privcmd_mmap_entry_t *entries = NULL;
> +    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
> +    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +    size_t pages = pfn_end - pfn_start;
> +    int i, rc = -1;
> +
> +    /* Map address space for initial elf image. */
> +    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
> +    if ( entries == NULL )
> +        goto err;
> +
> +    for ( i = 0; i < pages; i++ )
> +        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
> +
> +    elf->dest = xc_map_foreign_ranges(
> +        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
> +        entries, pages);
> +    if ( elf->dest == NULL )
> +        goto err;
> +
> +    elf->dest += elf->pstart & (PAGE_SIZE - 1);
> +
> +    /* Load the initial elf image. */
> +    rc = elf_load_binary(elf);
> +    if ( rc < 0 )
> +        PERROR("Failed to load elf binary\n");
> +
> +    munmap(elf->dest, pages << PAGE_SHIFT);
> +    elf->dest = NULL;
> +
> + err:
> +    free(entries);
> +
> +    return rc;
> +}
> +
> +/*
> + * Check whether there exists mmio hole in the specified memory range.
> + * Returns 1 if exists, else returns 0.
> + */
> +static int check_mmio_hole(uint64_t start, uint64_t memsize)
> +{
> +    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
> +         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
> +static int setup_guest(xc_interface *xch,
> +                       uint32_t dom, int memsize, int target,
> +                       char *image, unsigned long image_size)
> +{
> +    xen_pfn_t *page_array = NULL;
> +    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
> +    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
> +    unsigned long entry_eip, cur_pages, cur_pfn;
> +    void *hvm_info_page;
> +    uint32_t *ident_pt;
> +    struct elf_binary elf;
> +    uint64_t v_start, v_end;
> +    int rc;
> +    xen_capabilities_info_t caps;
> +    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
> +        stat_1gb_pages = 0;
> +    int pod_mode = 0;
> +
> +    /* An HVM guest must be initialised with at least 2MB memory. */
> +    if ( memsize < 2 || target < 2 )
> +        goto error_out;
> +
> +    if ( memsize > target )
> +        pod_mode = 1;
> +
> +    memset(&elf, 0, sizeof(elf));
> +    if ( elf_init(&elf, image, image_size) != 0 )
> +        goto error_out;
> +
> +    xc_elf_set_logfile(xch, &elf, 1);
> +
> +    elf_parse_binary(&elf);
> +    v_start = 0;
> +    v_end = (unsigned long long)memsize << 20;
> +
> +    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
> +    {
> +        PERROR("Could not get Xen capabilities");
> +        goto error_out;
> +    }
> +
> +    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
> +            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
> +            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
> +            "  ENTRY ADDRESS: %016"PRIx64"\n",
> +            elf.pstart, elf.pend,
> +            v_start, v_end,
> +            elf_uval(&elf, elf.ehdr, e_entry));
> +
> +    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
> +    {
> +        PERROR("Could not allocate memory.");
> +        goto error_out;
> +    }
> +
> +    for ( i = 0; i < nr_pages; i++ )
> +        page_array[i] = i;
> +    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
> +        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
> +
> +    /*
> +     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
> +     *
> +     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
> +     * pages if 1GB allocation fails. 4KB pages will be used eventually if
> +     * both fail.
> +     *
> +     * Under 2MB mode, we allocate pages in batches of no more than 8MB to
> +     * ensure that we can be preempted and hence dom0 remains responsive.
> +     */
> +    rc = xc_domain_populate_physmap_exact(
> +        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
> +    cur_pages = 0xc0;
> +    stat_normal_pages = 0xc0;
> +    while ( (rc == 0) && (nr_pages > cur_pages) )
> +    {
> +        /* Clip count to maximum 1GB extent. */
> +        unsigned long count = nr_pages - cur_pages;
> +        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
> +
> +        if ( count > max_pages )
> +            count = max_pages;
> +
> +        cur_pfn = page_array[cur_pages];
> +
> +        /* Take care the corner cases of super page tails */
> +        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> +             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
> +            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
> +        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> +                  (count > SUPERPAGE_1GB_NR_PFNS) )
> +            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
> +
> +        /* Attemp to allocate 1GB super page. Because in each pass we only
> +         * allocate at most 1GB, we don't have to clip super page boundaries.
> +         */
> +        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
> +             /* Check if there exists MMIO hole in the 1GB memory range */
> +             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
> +                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
> +        {
> +            long done;
> +            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
> +            xen_pfn_t sp_extents[nr_extents];
> +
> +            for ( i = 0; i < nr_extents; i++ )
> +                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
> +
> +            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
> +                                              pod_mode ? XENMEMF_populate_on_demand : 0,
> +                                              sp_extents);
> +
> +            if ( done > 0 )
> +            {
> +                stat_1gb_pages += done;
> +                done <<= SUPERPAGE_1GB_SHIFT;
> +                cur_pages += done;
> +                count -= done;
> +            }
> +        }
> +
> +        if ( count != 0 )
> +        {
> +            /* Clip count to maximum 8MB extent. */
> +            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
> +            if ( count > max_pages )
> +                count = max_pages;
> +
> +            /* Clip partial superpage extents to superpage boundaries. */
> +            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> +                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
> +                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
> +            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> +                      (count > SUPERPAGE_2MB_NR_PFNS) )
> +                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
> +
> +            /* Attempt to allocate superpage extents. */
> +            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
> +            {
> +                long done;
> +                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
> +                xen_pfn_t sp_extents[nr_extents];
> +
> +                for ( i = 0; i < nr_extents; i++ )
> +                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
> +
> +                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
> +                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
> +                                                  sp_extents);
> +
> +                if ( done > 0 )
> +                {
> +                    stat_2mb_pages += done;
> +                    done <<= SUPERPAGE_2MB_SHIFT;
> +                    cur_pages += done;
> +                    count -= done;
> +                }
> +            }
> +        }
> +
> +        /* Fall back to 4kB extents. */
> +        if ( count != 0 )
> +        {
> +            rc = xc_domain_populate_physmap_exact(
> +                xch, dom, count, 0, 0, &page_array[cur_pages]);
> +            cur_pages += count;
> +            stat_normal_pages += count;
> +        }
> +    }
> +
> +    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
> +     * adjust the PoD cache size so that domain tot_pages will be
> +     * target_pages - 0x20 after this call. */
> +    if ( pod_mode )
> +        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
> +                                      NULL, NULL, NULL);
> +
> +    if ( rc != 0 )
> +    {
> +        PERROR("Could not allocate memory for HVM guest.");
> +        goto error_out;
> +    }
> +
> +    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
> +            "  4KB PAGES: 0x%016lx\n"
> +            "  2MB PAGES: 0x%016lx\n"
> +            "  1GB PAGES: 0x%016lx\n",
> +            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
> +
> +    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
> +        goto error_out;
> +
> +    if ( (hvm_info_page = xc_map_foreign_range(
> +              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> +              HVM_INFO_PFN)) == NULL )
> +        goto error_out;
> +    build_hvm_info(hvm_info_page, v_end);
> +    munmap(hvm_info_page, PAGE_SIZE);
> +
> +    /* Allocate and clear special pages. */
> +    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
> +    {
> +        xen_pfn_t pfn = special_pfn(i);
> +        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
> +        if ( rc != 0 )
> +        {
> +            PERROR("Could not allocate %d'th special page.", i);
> +            goto error_out;
> +        }
> +        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
> +            goto error_out;
> +    }
> +
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
> +                     special_pfn(SPECIALPAGE_XENSTORE));
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
> +                     special_pfn(SPECIALPAGE_BUFIOREQ));
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
> +                     special_pfn(SPECIALPAGE_IOREQ));
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
> +                     special_pfn(SPECIALPAGE_CONSOLE));
> +
> +    /*
> +     * Identity-map page table is required for running with CR0.PG=0 when
> +     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
> +     */
> +    if ( (ident_pt = xc_map_foreign_range(
> +              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> +              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
> +        goto error_out;
> +    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
> +        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
> +                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
> +    munmap(ident_pt, PAGE_SIZE);
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> +                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
> +
> +    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
> +    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
> +    if ( entry_eip != 0 )
> +    {
> +        char *page0 = xc_map_foreign_range(
> +            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
> +        if ( page0 == NULL )
> +            goto error_out;
> +        page0[0] = 0xe9;
> +        *(uint32_t *)&page0[1] = entry_eip - 5;
> +        munmap(page0, PAGE_SIZE);
> +    }
> +
> +    free(page_array);
> +    return 0;
> +
> + error_out:
> +    free(page_array);
> +    return -1;
> +}
> +
> +static int xc_hvm_build_internal(xc_interface *xch,
> +                                 uint32_t domid,
> +                                 int memsize,
> +                                 int target,
> +                                 char *image,
> +                                 unsigned long image_size)
> +{
> +    if ( (image == NULL) || (image_size == 0) )
> +    {
> +        ERROR("Image required");
> +        return -1;
> +    }
> +
> +    return setup_guest(xch, domid, memsize, target, image, image_size);
> +}
> +
> +/* xc_hvm_build:
> + * Create a domain for a virtualized Linux, using files/filenames.
> + */
> +int xc_hvm_build(xc_interface *xch,
> +                 uint32_t domid,
> +                 int memsize,
> +                 const char *image_name)
> +{
> +    char *image;
> +    int  sts;
> +    unsigned long image_size;
> +
> +    if ( (image_name == NULL) ||
> +         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> +        return -1;
> +
> +    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
> +
> +    free(image);
> +
> +    return sts;
> +}
> +
> +/* xc_hvm_build_target_mem:
> + * Create a domain for a pre-ballooned virtualized Linux, using
> + * files/filenames.  If target < memsize, domain is created with
> + * memsize pages marked populate-on-demand,
> + * calculating pod cache size based on target.
> + * If target == memsize, pages are populated normally.
> + */
> +int xc_hvm_build_target_mem(xc_interface *xch,
> +                           uint32_t domid,
> +                           int memsize,
> +                           int target,
> +                           const char *image_name)
> +{
> +    char *image;
> +    int  sts;
> +    unsigned long image_size;
> +
> +    if ( (image_name == NULL) ||
> +         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> +        return -1;
> +
> +    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
> +
> +    free(image);
> +
> +    return sts;
> +}
> +
> +/* xc_hvm_build_mem:
> + * Create a domain for a virtualized Linux, using memory buffers.
> + */
> +int xc_hvm_build_mem(xc_interface *xch,
> +                     uint32_t domid,
> +                     int memsize,
> +                     const char *image_buffer,
> +                     unsigned long image_size)
> +{
> +    int           sts;
> +    unsigned long img_len;
> +    char         *img;
> +
> +    /* Validate that there is a kernel buffer */
> +
> +    if ( (image_buffer == NULL) || (image_size == 0) )
> +    {
> +        ERROR("kernel image buffer not present");
> +        return -1;
> +    }
> +
> +    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
> +    if ( img == NULL )
> +    {
> +        ERROR("unable to inflate ram disk buffer");
> +        return -1;
> +    }
> +
> +    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
> +                                img, img_len);
> +
> +    /* xc_inflate_buffer may return the original buffer pointer (for
> +       for already inflated buffers), so exercise some care in freeing */
> +
> +    if ( (img != NULL) && (img != image_buffer) )
> +        free(img);
> +
> +    return sts;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
> new file mode 100644
> index 0000000..e734d73
> --- /dev/null
> +++ b/tools/libxc/xc_nomigrate.c
> @@ -0,0 +1,53 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
> +                   uint32_t max_factor, uint32_t flags,
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_generationid_addr)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> +                      unsigned int store_evtchn, unsigned long *store_mfn,
> +                      domid_t store_domid, unsigned int console_evtchn,
> +                      unsigned long *console_mfn, domid_t console_domid,
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int no_incr_generationid,
> +                      unsigned long *vm_generationid_addr)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 1.7.2.5
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 09:01:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 09:01:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0r1r-00008Q-2r; Fri, 24 Feb 2012 09:01:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0r1p-000088-CF
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 09:01:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330074078!14697061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDc4NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15798 invoked from network); 24 Feb 2012 09:01:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 09:01:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10912662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 09:01:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 09:01:18 +0000
Message-ID: <1330074077.8557.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 09:01:17 +0000
In-Reply-To: <1330008712-17715-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
	<1330008712-17715-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 3/7] arm: compile libxenguest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 14:51 +0000, Stefano Stabellini wrote:
> Introduce an empty implementation of the arch specific ARM functions in
> xc_dom_arm.c.
> Provide empty implementations of xc_domain_save and xc_domain_restore
> when CONFIG_MIGRATE is not set.
> Move xc_hvm_build.c to xc_hvm_build_x86.c because the implementation is
> x86 specific, introduce xc_hvm_build_arm.c with empty stubs.
> 
> 
> Changes in v3:
> 
> - rename xc_hvm_build.c to xc_hvm_build_x86.c;
> 
> - remove xc_nohvm, introduce xc_hvm_build_arm.c instead;
> 
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

If you happen to repost then updating the copyright lines to say 2012
instead of 2011 might be useful. I'd also encourage the use of
"format-patch -M" in the future -- it makes renames much easier to
review.

> ---
>  tools/libxc/Makefile           |   12 +-
>  tools/libxc/xc_dom_arm.c       |   50 ++++
>  tools/libxc/xc_hvm_build.c     |  511 ----------------------------------------
>  tools/libxc/xc_hvm_build_arm.c |   61 +++++
>  tools/libxc/xc_hvm_build_x86.c |  511 ++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_nomigrate.c     |   53 ++++
>  6 files changed, 684 insertions(+), 514 deletions(-)
>  create mode 100644 tools/libxc/xc_dom_arm.c
>  delete mode 100644 tools/libxc/xc_hvm_build.c
>  create mode 100644 tools/libxc/xc_hvm_build_arm.c
>  create mode 100644 tools/libxc/xc_hvm_build_x86.c
>  create mode 100644 tools/libxc/xc_nomigrate.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index f2e1ba7..02d39a3 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -42,9 +42,12 @@ CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
> 
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_domain_restore.c xc_domain_save.c
> -GUEST_SRCS-$(CONFIG_MIGRATE) += xc_offline_page.c xc_compression.c
> -GUEST_SRCS-$(CONFIG_HVM) += xc_hvm_build.c
> +ifeq ($(CONFIG_MIGRATE),y)
> +GUEST_SRCS-y += xc_domain_restore.c xc_domain_save.c
> +GUEST_SRCS-y += xc_offline_page.c xc_compression.c
> +else
> +GUEST_SRCS-y += xc_nomigrate.c
> +endif
> 
>  vpath %.c ../../xen/common/libelf
>  CFLAGS += -I../../xen/common/libelf
> @@ -61,7 +64,10 @@ GUEST_SRCS-y                 += xc_dom_compat_linux.c
> 
>  GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
> +GUEST_SRCS-$(CONFIG_X86)     += xc_hvm_build_x86.c
>  GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_ia64.c
> +GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
> +GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
> 
>  OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
> 
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> new file mode 100644
> index 0000000..122d0e8
> --- /dev/null
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -0,0 +1,50 @@
> +/*
> + * Xen domain builder -- ARM
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +#include <inttypes.h>
> +#include <xen/xen.h>
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +
> +int arch_setup_meminit(struct xc_dom_image *dom)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int arch_setup_bootearly(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +
> +int arch_setup_bootlate(struct xc_dom_image *dom)
> +{
> +    DOMPRINTF("%s: doing nothing", __FUNCTION__);
> +    return 0;
> +}
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
> deleted file mode 100644
> index 1fa5658..0000000
> --- a/tools/libxc/xc_hvm_build.c
> +++ /dev/null
> @@ -1,511 +0,0 @@
> -/******************************************************************************
> - * xc_hvm_build.c
> - *
> - * This library is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation;
> - * version 2.1 of the License.
> - *
> - * This library is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with this library; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> - */
> -
> -#include <stddef.h>
> -#include <inttypes.h>
> -#include <stdlib.h>
> -#include <unistd.h>
> -#include <zlib.h>
> -
> -#include "xg_private.h"
> -#include "xc_private.h"
> -
> -#include <xen/foreign/x86_32.h>
> -#include <xen/foreign/x86_64.h>
> -#include <xen/hvm/hvm_info_table.h>
> -#include <xen/hvm/params.h>
> -#include <xen/hvm/e820.h>
> -
> -#include <xen/libelf/libelf.h>
> -
> -#define SUPERPAGE_2MB_SHIFT   9
> -#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
> -#define SUPERPAGE_1GB_SHIFT   18
> -#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> -
> -#define SPECIALPAGE_BUFIOREQ 0
> -#define SPECIALPAGE_XENSTORE 1
> -#define SPECIALPAGE_IOREQ    2
> -#define SPECIALPAGE_IDENT_PT 3
> -#define SPECIALPAGE_CONSOLE  4
> -#define NR_SPECIAL_PAGES     5
> -#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
> -
> -static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
> -{
> -    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
> -        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> -    uint64_t lowmem_end = mem_size, highmem_end = 0;
> -    uint8_t sum;
> -    int i;
> -
> -    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
> -    {
> -        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
> -        lowmem_end = HVM_BELOW_4G_RAM_END;
> -    }
> -
> -    memset(hvm_info_page, 0, PAGE_SIZE);
> -
> -    /* Fill in the header. */
> -    strncpy(hvm_info->signature, "HVM INFO", 8);
> -    hvm_info->length = sizeof(struct hvm_info_table);
> -
> -    /* Sensible defaults: these can be overridden by the caller. */
> -    hvm_info->apic_mode = 1;
> -    hvm_info->nr_vcpus = 1;
> -    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
> -
> -    /* Memory parameters. */
> -    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
> -    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
> -    hvm_info->reserved_mem_pgstart = special_pfn(0);
> -
> -    /* Finish with the checksum. */
> -    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
> -        sum += ((uint8_t *)hvm_info)[i];
> -    hvm_info->checksum = -sum;
> -}
> -
> -static int loadelfimage(
> -    xc_interface *xch,
> -    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
> -{
> -    privcmd_mmap_entry_t *entries = NULL;
> -    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
> -    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
> -    size_t pages = pfn_end - pfn_start;
> -    int i, rc = -1;
> -
> -    /* Map address space for initial elf image. */
> -    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
> -    if ( entries == NULL )
> -        goto err;
> -
> -    for ( i = 0; i < pages; i++ )
> -        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
> -
> -    elf->dest = xc_map_foreign_ranges(
> -        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
> -        entries, pages);
> -    if ( elf->dest == NULL )
> -        goto err;
> -
> -    elf->dest += elf->pstart & (PAGE_SIZE - 1);
> -
> -    /* Load the initial elf image. */
> -    rc = elf_load_binary(elf);
> -    if ( rc < 0 )
> -        PERROR("Failed to load elf binary\n");
> -
> -    munmap(elf->dest, pages << PAGE_SHIFT);
> -    elf->dest = NULL;
> -
> - err:
> -    free(entries);
> -
> -    return rc;
> -}
> -
> -/*
> - * Check whether there exists mmio hole in the specified memory range.
> - * Returns 1 if exists, else returns 0.
> - */
> -static int check_mmio_hole(uint64_t start, uint64_t memsize)
> -{
> -    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
> -         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
> -        return 0;
> -    else
> -        return 1;
> -}
> -
> -static int setup_guest(xc_interface *xch,
> -                       uint32_t dom, int memsize, int target,
> -                       char *image, unsigned long image_size)
> -{
> -    xen_pfn_t *page_array = NULL;
> -    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
> -    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
> -    unsigned long entry_eip, cur_pages, cur_pfn;
> -    void *hvm_info_page;
> -    uint32_t *ident_pt;
> -    struct elf_binary elf;
> -    uint64_t v_start, v_end;
> -    int rc;
> -    xen_capabilities_info_t caps;
> -    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
> -        stat_1gb_pages = 0;
> -    int pod_mode = 0;
> -
> -    /* An HVM guest must be initialised with at least 2MB memory. */
> -    if ( memsize < 2 || target < 2 )
> -        goto error_out;
> -
> -    if ( memsize > target )
> -        pod_mode = 1;
> -
> -    memset(&elf, 0, sizeof(elf));
> -    if ( elf_init(&elf, image, image_size) != 0 )
> -        goto error_out;
> -
> -    xc_elf_set_logfile(xch, &elf, 1);
> -
> -    elf_parse_binary(&elf);
> -    v_start = 0;
> -    v_end = (unsigned long long)memsize << 20;
> -
> -    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
> -    {
> -        PERROR("Could not get Xen capabilities");
> -        goto error_out;
> -    }
> -
> -    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
> -            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
> -            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
> -            "  ENTRY ADDRESS: %016"PRIx64"\n",
> -            elf.pstart, elf.pend,
> -            v_start, v_end,
> -            elf_uval(&elf, elf.ehdr, e_entry));
> -
> -    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
> -    {
> -        PERROR("Could not allocate memory.");
> -        goto error_out;
> -    }
> -
> -    for ( i = 0; i < nr_pages; i++ )
> -        page_array[i] = i;
> -    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
> -        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
> -
> -    /*
> -     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
> -     *
> -     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
> -     * pages if 1GB allocation fails. 4KB pages will be used eventually if
> -     * both fail.
> -     *
> -     * Under 2MB mode, we allocate pages in batches of no more than 8MB to
> -     * ensure that we can be preempted and hence dom0 remains responsive.
> -     */
> -    rc = xc_domain_populate_physmap_exact(
> -        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
> -    cur_pages = 0xc0;
> -    stat_normal_pages = 0xc0;
> -    while ( (rc == 0) && (nr_pages > cur_pages) )
> -    {
> -        /* Clip count to maximum 1GB extent. */
> -        unsigned long count = nr_pages - cur_pages;
> -        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
> -
> -        if ( count > max_pages )
> -            count = max_pages;
> -
> -        cur_pfn = page_array[cur_pages];
> -
> -        /* Take care the corner cases of super page tails */
> -        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> -             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
> -            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
> -        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> -                  (count > SUPERPAGE_1GB_NR_PFNS) )
> -            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
> -
> -        /* Attemp to allocate 1GB super page. Because in each pass we only
> -         * allocate at most 1GB, we don't have to clip super page boundaries.
> -         */
> -        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
> -             /* Check if there exists MMIO hole in the 1GB memory range */
> -             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
> -                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
> -        {
> -            long done;
> -            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
> -            xen_pfn_t sp_extents[nr_extents];
> -
> -            for ( i = 0; i < nr_extents; i++ )
> -                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
> -
> -            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
> -                                              pod_mode ? XENMEMF_populate_on_demand : 0,
> -                                              sp_extents);
> -
> -            if ( done > 0 )
> -            {
> -                stat_1gb_pages += done;
> -                done <<= SUPERPAGE_1GB_SHIFT;
> -                cur_pages += done;
> -                count -= done;
> -            }
> -        }
> -
> -        if ( count != 0 )
> -        {
> -            /* Clip count to maximum 8MB extent. */
> -            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
> -            if ( count > max_pages )
> -                count = max_pages;
> -
> -            /* Clip partial superpage extents to superpage boundaries. */
> -            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> -                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
> -                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
> -            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> -                      (count > SUPERPAGE_2MB_NR_PFNS) )
> -                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
> -
> -            /* Attempt to allocate superpage extents. */
> -            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
> -            {
> -                long done;
> -                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
> -                xen_pfn_t sp_extents[nr_extents];
> -
> -                for ( i = 0; i < nr_extents; i++ )
> -                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
> -
> -                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
> -                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
> -                                                  sp_extents);
> -
> -                if ( done > 0 )
> -                {
> -                    stat_2mb_pages += done;
> -                    done <<= SUPERPAGE_2MB_SHIFT;
> -                    cur_pages += done;
> -                    count -= done;
> -                }
> -            }
> -        }
> -
> -        /* Fall back to 4kB extents. */
> -        if ( count != 0 )
> -        {
> -            rc = xc_domain_populate_physmap_exact(
> -                xch, dom, count, 0, 0, &page_array[cur_pages]);
> -            cur_pages += count;
> -            stat_normal_pages += count;
> -        }
> -    }
> -
> -    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
> -     * adjust the PoD cache size so that domain tot_pages will be
> -     * target_pages - 0x20 after this call. */
> -    if ( pod_mode )
> -        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
> -                                      NULL, NULL, NULL);
> -
> -    if ( rc != 0 )
> -    {
> -        PERROR("Could not allocate memory for HVM guest.");
> -        goto error_out;
> -    }
> -
> -    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
> -            "  4KB PAGES: 0x%016lx\n"
> -            "  2MB PAGES: 0x%016lx\n"
> -            "  1GB PAGES: 0x%016lx\n",
> -            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
> -
> -    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
> -        goto error_out;
> -
> -    if ( (hvm_info_page = xc_map_foreign_range(
> -              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> -              HVM_INFO_PFN)) == NULL )
> -        goto error_out;
> -    build_hvm_info(hvm_info_page, v_end);
> -    munmap(hvm_info_page, PAGE_SIZE);
> -
> -    /* Allocate and clear special pages. */
> -    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
> -    {
> -        xen_pfn_t pfn = special_pfn(i);
> -        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
> -        if ( rc != 0 )
> -        {
> -            PERROR("Could not allocate %d'th special page.", i);
> -            goto error_out;
> -        }
> -        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
> -            goto error_out;
> -    }
> -
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
> -                     special_pfn(SPECIALPAGE_XENSTORE));
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
> -                     special_pfn(SPECIALPAGE_BUFIOREQ));
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
> -                     special_pfn(SPECIALPAGE_IOREQ));
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
> -                     special_pfn(SPECIALPAGE_CONSOLE));
> -
> -    /*
> -     * Identity-map page table is required for running with CR0.PG=0 when
> -     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
> -     */
> -    if ( (ident_pt = xc_map_foreign_range(
> -              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> -              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
> -        goto error_out;
> -    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
> -        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
> -                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
> -    munmap(ident_pt, PAGE_SIZE);
> -    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> -                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
> -
> -    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
> -    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
> -    if ( entry_eip != 0 )
> -    {
> -        char *page0 = xc_map_foreign_range(
> -            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
> -        if ( page0 == NULL )
> -            goto error_out;
> -        page0[0] = 0xe9;
> -        *(uint32_t *)&page0[1] = entry_eip - 5;
> -        munmap(page0, PAGE_SIZE);
> -    }
> -
> -    free(page_array);
> -    return 0;
> -
> - error_out:
> -    free(page_array);
> -    return -1;
> -}
> -
> -static int xc_hvm_build_internal(xc_interface *xch,
> -                                 uint32_t domid,
> -                                 int memsize,
> -                                 int target,
> -                                 char *image,
> -                                 unsigned long image_size)
> -{
> -    if ( (image == NULL) || (image_size == 0) )
> -    {
> -        ERROR("Image required");
> -        return -1;
> -    }
> -
> -    return setup_guest(xch, domid, memsize, target, image, image_size);
> -}
> -
> -/* xc_hvm_build:
> - * Create a domain for a virtualized Linux, using files/filenames.
> - */
> -int xc_hvm_build(xc_interface *xch,
> -                 uint32_t domid,
> -                 int memsize,
> -                 const char *image_name)
> -{
> -    char *image;
> -    int  sts;
> -    unsigned long image_size;
> -
> -    if ( (image_name == NULL) ||
> -         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> -        return -1;
> -
> -    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
> -
> -    free(image);
> -
> -    return sts;
> -}
> -
> -/* xc_hvm_build_target_mem:
> - * Create a domain for a pre-ballooned virtualized Linux, using
> - * files/filenames.  If target < memsize, domain is created with
> - * memsize pages marked populate-on-demand,
> - * calculating pod cache size based on target.
> - * If target == memsize, pages are populated normally.
> - */
> -int xc_hvm_build_target_mem(xc_interface *xch,
> -                           uint32_t domid,
> -                           int memsize,
> -                           int target,
> -                           const char *image_name)
> -{
> -    char *image;
> -    int  sts;
> -    unsigned long image_size;
> -
> -    if ( (image_name == NULL) ||
> -         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> -        return -1;
> -
> -    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
> -
> -    free(image);
> -
> -    return sts;
> -}
> -
> -/* xc_hvm_build_mem:
> - * Create a domain for a virtualized Linux, using memory buffers.
> - */
> -int xc_hvm_build_mem(xc_interface *xch,
> -                     uint32_t domid,
> -                     int memsize,
> -                     const char *image_buffer,
> -                     unsigned long image_size)
> -{
> -    int           sts;
> -    unsigned long img_len;
> -    char         *img;
> -
> -    /* Validate that there is a kernel buffer */
> -
> -    if ( (image_buffer == NULL) || (image_size == 0) )
> -    {
> -        ERROR("kernel image buffer not present");
> -        return -1;
> -    }
> -
> -    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
> -    if ( img == NULL )
> -    {
> -        ERROR("unable to inflate ram disk buffer");
> -        return -1;
> -    }
> -
> -    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
> -                                img, img_len);
> -
> -    /* xc_inflate_buffer may return the original buffer pointer (for
> -       for already inflated buffers), so exercise some care in freeing */
> -
> -    if ( (img != NULL) && (img != image_buffer) )
> -        free(img);
> -
> -    return sts;
> -}
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-set-style: "BSD"
> - * c-basic-offset: 4
> - * tab-width: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/tools/libxc/xc_hvm_build_arm.c b/tools/libxc/xc_hvm_build_arm.c
> new file mode 100644
> index 0000000..010ebdb
> --- /dev/null
> +++ b/tools/libxc/xc_hvm_build_arm.c
> @@ -0,0 +1,61 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_hvm_build(xc_interface *xch,
> +                 uint32_t domid,
> +                 int memsize,
> +                 const char *image_name)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int xc_hvm_build_target_mem(xc_interface *xch,
> +                           uint32_t domid,
> +                           int memsize,
> +                           int target,
> +                           const char *image_name)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int xc_hvm_build_mem(xc_interface *xch,
> +                     uint32_t domid,
> +                     int memsize,
> +                     const char *image_buffer,
> +                     unsigned long image_size)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
> new file mode 100644
> index 0000000..1fa5658
> --- /dev/null
> +++ b/tools/libxc/xc_hvm_build_x86.c
> @@ -0,0 +1,511 @@
> +/******************************************************************************
> + * xc_hvm_build.c
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +#include <stddef.h>
> +#include <inttypes.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <zlib.h>
> +
> +#include "xg_private.h"
> +#include "xc_private.h"
> +
> +#include <xen/foreign/x86_32.h>
> +#include <xen/foreign/x86_64.h>
> +#include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/params.h>
> +#include <xen/hvm/e820.h>
> +
> +#include <xen/libelf/libelf.h>
> +
> +#define SUPERPAGE_2MB_SHIFT   9
> +#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
> +#define SUPERPAGE_1GB_SHIFT   18
> +#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> +
> +#define SPECIALPAGE_BUFIOREQ 0
> +#define SPECIALPAGE_XENSTORE 1
> +#define SPECIALPAGE_IOREQ    2
> +#define SPECIALPAGE_IDENT_PT 3
> +#define SPECIALPAGE_CONSOLE  4
> +#define NR_SPECIAL_PAGES     5
> +#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
> +
> +static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
> +{
> +    struct hvm_info_table *hvm_info = (struct hvm_info_table *)
> +        (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> +    uint64_t lowmem_end = mem_size, highmem_end = 0;
> +    uint8_t sum;
> +    int i;
> +
> +    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
> +    {
> +        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
> +        lowmem_end = HVM_BELOW_4G_RAM_END;
> +    }
> +
> +    memset(hvm_info_page, 0, PAGE_SIZE);
> +
> +    /* Fill in the header. */
> +    strncpy(hvm_info->signature, "HVM INFO", 8);
> +    hvm_info->length = sizeof(struct hvm_info_table);
> +
> +    /* Sensible defaults: these can be overridden by the caller. */
> +    hvm_info->apic_mode = 1;
> +    hvm_info->nr_vcpus = 1;
> +    memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
> +
> +    /* Memory parameters. */
> +    hvm_info->low_mem_pgend = lowmem_end >> PAGE_SHIFT;
> +    hvm_info->high_mem_pgend = highmem_end >> PAGE_SHIFT;
> +    hvm_info->reserved_mem_pgstart = special_pfn(0);
> +
> +    /* Finish with the checksum. */
> +    for ( i = 0, sum = 0; i < hvm_info->length; i++ )
> +        sum += ((uint8_t *)hvm_info)[i];
> +    hvm_info->checksum = -sum;
> +}
> +
> +static int loadelfimage(
> +    xc_interface *xch,
> +    struct elf_binary *elf, uint32_t dom, unsigned long *parray)
> +{
> +    privcmd_mmap_entry_t *entries = NULL;
> +    unsigned long pfn_start = elf->pstart >> PAGE_SHIFT;
> +    unsigned long pfn_end = (elf->pend + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +    size_t pages = pfn_end - pfn_start;
> +    int i, rc = -1;
> +
> +    /* Map address space for initial elf image. */
> +    entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
> +    if ( entries == NULL )
> +        goto err;
> +
> +    for ( i = 0; i < pages; i++ )
> +        entries[i].mfn = parray[(elf->pstart >> PAGE_SHIFT) + i];
> +
> +    elf->dest = xc_map_foreign_ranges(
> +        xch, dom, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << PAGE_SHIFT,
> +        entries, pages);
> +    if ( elf->dest == NULL )
> +        goto err;
> +
> +    elf->dest += elf->pstart & (PAGE_SIZE - 1);
> +
> +    /* Load the initial elf image. */
> +    rc = elf_load_binary(elf);
> +    if ( rc < 0 )
> +        PERROR("Failed to load elf binary\n");
> +
> +    munmap(elf->dest, pages << PAGE_SHIFT);
> +    elf->dest = NULL;
> +
> + err:
> +    free(entries);
> +
> +    return rc;
> +}
> +
> +/*
> + * Check whether there exists mmio hole in the specified memory range.
> + * Returns 1 if exists, else returns 0.
> + */
> +static int check_mmio_hole(uint64_t start, uint64_t memsize)
> +{
> +    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
> +         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
> +        return 0;
> +    else
> +        return 1;
> +}
> +
> +static int setup_guest(xc_interface *xch,
> +                       uint32_t dom, int memsize, int target,
> +                       char *image, unsigned long image_size)
> +{
> +    xen_pfn_t *page_array = NULL;
> +    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
> +    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
> +    unsigned long entry_eip, cur_pages, cur_pfn;
> +    void *hvm_info_page;
> +    uint32_t *ident_pt;
> +    struct elf_binary elf;
> +    uint64_t v_start, v_end;
> +    int rc;
> +    xen_capabilities_info_t caps;
> +    unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
> +        stat_1gb_pages = 0;
> +    int pod_mode = 0;
> +
> +    /* An HVM guest must be initialised with at least 2MB memory. */
> +    if ( memsize < 2 || target < 2 )
> +        goto error_out;
> +
> +    if ( memsize > target )
> +        pod_mode = 1;
> +
> +    memset(&elf, 0, sizeof(elf));
> +    if ( elf_init(&elf, image, image_size) != 0 )
> +        goto error_out;
> +
> +    xc_elf_set_logfile(xch, &elf, 1);
> +
> +    elf_parse_binary(&elf);
> +    v_start = 0;
> +    v_end = (unsigned long long)memsize << 20;
> +
> +    if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
> +    {
> +        PERROR("Could not get Xen capabilities");
> +        goto error_out;
> +    }
> +
> +    IPRINTF("VIRTUAL MEMORY ARRANGEMENT:\n"
> +            "  Loader:        %016"PRIx64"->%016"PRIx64"\n"
> +            "  TOTAL:         %016"PRIx64"->%016"PRIx64"\n"
> +            "  ENTRY ADDRESS: %016"PRIx64"\n",
> +            elf.pstart, elf.pend,
> +            v_start, v_end,
> +            elf_uval(&elf, elf.ehdr, e_entry));
> +
> +    if ( (page_array = malloc(nr_pages * sizeof(xen_pfn_t))) == NULL )
> +    {
> +        PERROR("Could not allocate memory.");
> +        goto error_out;
> +    }
> +
> +    for ( i = 0; i < nr_pages; i++ )
> +        page_array[i] = i;
> +    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
> +        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
> +
> +    /*
> +     * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
> +     *
> +     * We attempt to allocate 1GB pages if possible. It falls back on 2MB
> +     * pages if 1GB allocation fails. 4KB pages will be used eventually if
> +     * both fail.
> +     *
> +     * Under 2MB mode, we allocate pages in batches of no more than 8MB to
> +     * ensure that we can be preempted and hence dom0 remains responsive.
> +     */
> +    rc = xc_domain_populate_physmap_exact(
> +        xch, dom, 0xa0, 0, 0, &page_array[0x00]);
> +    cur_pages = 0xc0;
> +    stat_normal_pages = 0xc0;
> +    while ( (rc == 0) && (nr_pages > cur_pages) )
> +    {
> +        /* Clip count to maximum 1GB extent. */
> +        unsigned long count = nr_pages - cur_pages;
> +        unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
> +
> +        if ( count > max_pages )
> +            count = max_pages;
> +
> +        cur_pfn = page_array[cur_pages];
> +
> +        /* Take care the corner cases of super page tails */
> +        if ( ((cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> +             (count > (-cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1))) )
> +            count = -cur_pfn & (SUPERPAGE_1GB_NR_PFNS-1);
> +        else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
> +                  (count > SUPERPAGE_1GB_NR_PFNS) )
> +            count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
> +
> +        /* Attemp to allocate 1GB super page. Because in each pass we only
> +         * allocate at most 1GB, we don't have to clip super page boundaries.
> +         */
> +        if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
> +             /* Check if there exists MMIO hole in the 1GB memory range */
> +             !check_mmio_hole(cur_pfn << PAGE_SHIFT,
> +                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
> +        {
> +            long done;
> +            unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
> +            xen_pfn_t sp_extents[nr_extents];
> +
> +            for ( i = 0; i < nr_extents; i++ )
> +                sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
> +
> +            done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_1GB_SHIFT,
> +                                              pod_mode ? XENMEMF_populate_on_demand : 0,
> +                                              sp_extents);
> +
> +            if ( done > 0 )
> +            {
> +                stat_1gb_pages += done;
> +                done <<= SUPERPAGE_1GB_SHIFT;
> +                cur_pages += done;
> +                count -= done;
> +            }
> +        }
> +
> +        if ( count != 0 )
> +        {
> +            /* Clip count to maximum 8MB extent. */
> +            max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
> +            if ( count > max_pages )
> +                count = max_pages;
> +
> +            /* Clip partial superpage extents to superpage boundaries. */
> +            if ( ((cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> +                 (count > (-cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1))) )
> +                count = -cur_pfn & (SUPERPAGE_2MB_NR_PFNS-1);
> +            else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
> +                      (count > SUPERPAGE_2MB_NR_PFNS) )
> +                count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
> +
> +            /* Attempt to allocate superpage extents. */
> +            if ( ((count | cur_pfn) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
> +            {
> +                long done;
> +                unsigned long nr_extents = count >> SUPERPAGE_2MB_SHIFT;
> +                xen_pfn_t sp_extents[nr_extents];
> +
> +                for ( i = 0; i < nr_extents; i++ )
> +                    sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
> +
> +                done = xc_domain_populate_physmap(xch, dom, nr_extents, SUPERPAGE_2MB_SHIFT,
> +                                                  pod_mode ? XENMEMF_populate_on_demand : 0,
> +                                                  sp_extents);
> +
> +                if ( done > 0 )
> +                {
> +                    stat_2mb_pages += done;
> +                    done <<= SUPERPAGE_2MB_SHIFT;
> +                    cur_pages += done;
> +                    count -= done;
> +                }
> +            }
> +        }
> +
> +        /* Fall back to 4kB extents. */
> +        if ( count != 0 )
> +        {
> +            rc = xc_domain_populate_physmap_exact(
> +                xch, dom, count, 0, 0, &page_array[cur_pages]);
> +            cur_pages += count;
> +            stat_normal_pages += count;
> +        }
> +    }
> +
> +    /* Subtract 0x20 from target_pages for the VGA "hole".  Xen will
> +     * adjust the PoD cache size so that domain tot_pages will be
> +     * target_pages - 0x20 after this call. */
> +    if ( pod_mode )
> +        rc = xc_domain_set_pod_target(xch, dom, target_pages - 0x20,
> +                                      NULL, NULL, NULL);
> +
> +    if ( rc != 0 )
> +    {
> +        PERROR("Could not allocate memory for HVM guest.");
> +        goto error_out;
> +    }
> +
> +    IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
> +            "  4KB PAGES: 0x%016lx\n"
> +            "  2MB PAGES: 0x%016lx\n"
> +            "  1GB PAGES: 0x%016lx\n",
> +            stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
> +
> +    if ( loadelfimage(xch, &elf, dom, page_array) != 0 )
> +        goto error_out;
> +
> +    if ( (hvm_info_page = xc_map_foreign_range(
> +              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> +              HVM_INFO_PFN)) == NULL )
> +        goto error_out;
> +    build_hvm_info(hvm_info_page, v_end);
> +    munmap(hvm_info_page, PAGE_SIZE);
> +
> +    /* Allocate and clear special pages. */
> +    for ( i = 0; i < NR_SPECIAL_PAGES; i++ )
> +    {
> +        xen_pfn_t pfn = special_pfn(i);
> +        rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, &pfn);
> +        if ( rc != 0 )
> +        {
> +            PERROR("Could not allocate %d'th special page.", i);
> +            goto error_out;
> +        }
> +        if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
> +            goto error_out;
> +    }
> +
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
> +                     special_pfn(SPECIALPAGE_XENSTORE));
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
> +                     special_pfn(SPECIALPAGE_BUFIOREQ));
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
> +                     special_pfn(SPECIALPAGE_IOREQ));
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
> +                     special_pfn(SPECIALPAGE_CONSOLE));
> +
> +    /*
> +     * Identity-map page table is required for running with CR0.PG=0 when
> +     * using Intel EPT. Create a 32-bit non-PAE page directory of superpages.
> +     */
> +    if ( (ident_pt = xc_map_foreign_range(
> +              xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> +              special_pfn(SPECIALPAGE_IDENT_PT))) == NULL )
> +        goto error_out;
> +    for ( i = 0; i < PAGE_SIZE / sizeof(*ident_pt); i++ )
> +        ident_pt[i] = ((i << 22) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
> +                       _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
> +    munmap(ident_pt, PAGE_SIZE);
> +    xc_set_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> +                     special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
> +
> +    /* Insert JMP <rel32> instruction at address 0x0 to reach entry point. */
> +    entry_eip = elf_uval(&elf, elf.ehdr, e_entry);
> +    if ( entry_eip != 0 )
> +    {
> +        char *page0 = xc_map_foreign_range(
> +            xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE, 0);
> +        if ( page0 == NULL )
> +            goto error_out;
> +        page0[0] = 0xe9;
> +        *(uint32_t *)&page0[1] = entry_eip - 5;
> +        munmap(page0, PAGE_SIZE);
> +    }
> +
> +    free(page_array);
> +    return 0;
> +
> + error_out:
> +    free(page_array);
> +    return -1;
> +}
> +
> +static int xc_hvm_build_internal(xc_interface *xch,
> +                                 uint32_t domid,
> +                                 int memsize,
> +                                 int target,
> +                                 char *image,
> +                                 unsigned long image_size)
> +{
> +    if ( (image == NULL) || (image_size == 0) )
> +    {
> +        ERROR("Image required");
> +        return -1;
> +    }
> +
> +    return setup_guest(xch, domid, memsize, target, image, image_size);
> +}
> +
> +/* xc_hvm_build:
> + * Create a domain for a virtualized Linux, using files/filenames.
> + */
> +int xc_hvm_build(xc_interface *xch,
> +                 uint32_t domid,
> +                 int memsize,
> +                 const char *image_name)
> +{
> +    char *image;
> +    int  sts;
> +    unsigned long image_size;
> +
> +    if ( (image_name == NULL) ||
> +         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> +        return -1;
> +
> +    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
> +
> +    free(image);
> +
> +    return sts;
> +}
> +
> +/* xc_hvm_build_target_mem:
> + * Create a domain for a pre-ballooned virtualized Linux, using
> + * files/filenames.  If target < memsize, domain is created with
> + * memsize pages marked populate-on-demand,
> + * calculating pod cache size based on target.
> + * If target == memsize, pages are populated normally.
> + */
> +int xc_hvm_build_target_mem(xc_interface *xch,
> +                           uint32_t domid,
> +                           int memsize,
> +                           int target,
> +                           const char *image_name)
> +{
> +    char *image;
> +    int  sts;
> +    unsigned long image_size;
> +
> +    if ( (image_name == NULL) ||
> +         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
> +        return -1;
> +
> +    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
> +
> +    free(image);
> +
> +    return sts;
> +}
> +
> +/* xc_hvm_build_mem:
> + * Create a domain for a virtualized Linux, using memory buffers.
> + */
> +int xc_hvm_build_mem(xc_interface *xch,
> +                     uint32_t domid,
> +                     int memsize,
> +                     const char *image_buffer,
> +                     unsigned long image_size)
> +{
> +    int           sts;
> +    unsigned long img_len;
> +    char         *img;
> +
> +    /* Validate that there is a kernel buffer */
> +
> +    if ( (image_buffer == NULL) || (image_size == 0) )
> +    {
> +        ERROR("kernel image buffer not present");
> +        return -1;
> +    }
> +
> +    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
> +    if ( img == NULL )
> +    {
> +        ERROR("unable to inflate ram disk buffer");
> +        return -1;
> +    }
> +
> +    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
> +                                img, img_len);
> +
> +    /* xc_inflate_buffer may return the original buffer pointer (for
> +       for already inflated buffers), so exercise some care in freeing */
> +
> +    if ( (img != NULL) && (img != image_buffer) )
> +        free(img);
> +
> +    return sts;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
> new file mode 100644
> index 0000000..e734d73
> --- /dev/null
> +++ b/tools/libxc/xc_nomigrate.c
> @@ -0,0 +1,53 @@
> +/******************************************************************************
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2011, Citrix Systems
> + */
> +
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <xenctrl.h>
> +#include <xenguest.h>
> +
> +int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
> +                   uint32_t max_factor, uint32_t flags,
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_generationid_addr)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> +                      unsigned int store_evtchn, unsigned long *store_mfn,
> +                      domid_t store_domid, unsigned int console_evtchn,
> +                      unsigned long *console_mfn, domid_t console_domid,
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      int no_incr_generationid,
> +                      unsigned long *vm_generationid_addr)
> +{
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 1.7.2.5
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 09:26:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 09:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0rPq-0000Tt-HA; Fri, 24 Feb 2012 09:26: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 1S0rPp-0000To-9M
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 09:26:13 +0000
Received: from [85.158.139.83:24846] by server-5.bemta-5.messagelabs.com id
	05/B9-13566-4B7574F4; Fri, 24 Feb 2012 09:26:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330075571!9133297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17190 invoked from network); 24 Feb 2012 09:26:11 -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 Feb 2012 09:26:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10913238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 09:25:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 09:25:50 +0000
Message-ID: <1330075549.8557.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 09:25:49 +0000
In-Reply-To: <1330008712-17715-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
	<1330008712-17715-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 14:51 +0000, Stefano Stabellini wrote:
> Introduce an arch specific internal domain creation function. At the
> moment only x86 provides an implementation.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(I thought I acked this last time)

> ---
>  tools/libxl/Makefile         |    6 +-
>  tools/libxl/libxl_arch.h     |   22 ++++
>  tools/libxl/libxl_create.c   |   12 +--
>  tools/libxl/libxl_internal.h |    2 -
>  tools/libxl/libxl_noarch.c   |    8 ++
>  tools/libxl/libxl_pci.c      |  242 ---------------------------------------
>  tools/libxl/libxl_x86.c      |  259 ++++++++++++++++++++++++++++++++++++++++++
>  7 files changed, 294 insertions(+), 257 deletions(-)
>  create mode 100644 tools/libxl/libxl_arch.h
>  create mode 100644 tools/libxl/libxl_noarch.c
>  create mode 100644 tools/libxl/libxl_x86.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 41b6ac4..ba5852b 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
>  else
>  LIBXL_OBJS-y += libxl_noblktap2.o
>  endif
> -LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
> -LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
> +LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
> +LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
> 
>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_netbsd.o
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> new file mode 100644
> index 0000000..d1bbdf7
> --- /dev/null
> +++ b/tools/libxl/libxl_arch.h
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#ifndef LIBXL_ARCH_H
> +#define LIBXL_ARCH_H
> +
> +/* arch specific internal domain creation function */
> +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> +               uint32_t domid);
> +
> +#endif
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f28d814..ff589a8 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -18,6 +18,7 @@
>  #include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> +#include "libxl_arch.h"
> 
>  #include <xc_dom.h>
>  #include <xenguest.h>
> @@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>              goto error_out;
>          }
>      }
> -
> -    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
> -        d_config->b_info.u.pv.e820_host) {
> -        int rc;
> -        rc = libxl__e820_alloc(gc, domid, d_config);
> -        if (rc)
> -            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> -                      "Failed while collecting E820 with: %d (errno:%d)\n",
> -                      rc, errno);
> -    }
> +    libxl__arch_domain_create(gc, d_config, domid);
>      if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
>                  (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
>                   d_config->b_info.u.pv.bootloader ))) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8846c68..bd384e2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -975,8 +975,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
>  _hidden int libxl__file_reference_map(libxl_file_reference *f);
>  _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
> 
> -_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
> -
>  /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
>  _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
>  /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
> diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
> new file mode 100644
> index 0000000..7893535
> --- /dev/null
> +++ b/tools/libxl/libxl_noarch.c
> @@ -0,0 +1,8 @@
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> +                              uint32_t domid)
> +{
> +    return 0;
> +}
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 33425f5..d960f4b 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
>      return 0;
>  }
> 
> -static const char *e820_names(int type)
> -{
> -    switch (type) {
> -        case E820_RAM: return "RAM";
> -        case E820_RESERVED: return "Reserved";
> -        case E820_ACPI: return "ACPI";
> -        case E820_NVS: return "ACPI NVS";
> -        case E820_UNUSABLE: return "Unusable";
> -        default: break;
> -    }
> -    return "Unknown";
> -}
> -
> -static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
> -                         uint32_t *nr_entries,
> -                         unsigned long map_limitkb,
> -                         unsigned long balloon_kb)
> -{
> -    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
> -    uint32_t i, idx = 0, nr;
> -    struct e820entry e820[E820MAX];
> -
> -    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
> -        return ERROR_INVAL;
> -
> -    nr = *nr_entries;
> -    if (!nr)
> -        return ERROR_INVAL;
> -
> -    if (nr > E820MAX)
> -        return ERROR_NOMEM;
> -
> -    /* Weed out anything under 1MB */
> -    for (i = 0; i < nr; i++) {
> -        if (src[i].addr > 0x100000)
> -            continue;
> -
> -        src[i].type = 0;
> -        src[i].size = 0;
> -        src[i].addr = -1ULL;
> -    }
> -
> -    /* Find the lowest and highest entry in E820, skipping over
> -     * undesired entries. */
> -    start = -1ULL;
> -    last = 0;
> -    for (i = 0; i < nr; i++) {
> -        if ((src[i].type == E820_RAM) ||
> -            (src[i].type == E820_UNUSABLE) ||
> -            (src[i].type == 0))
> -            continue;
> -
> -        start = src[i].addr < start ? src[i].addr : start;
> -        last = src[i].addr + src[i].size > last ?
> -               src[i].addr + src[i].size > last : last;
> -    }
> -    if (start > 1024)
> -        start_kb = start >> 10;
> -
> -    /* Add the memory RAM region for the guest */
> -    e820[idx].addr = 0;
> -    e820[idx].size = (uint64_t)map_limitkb << 10;
> -    e820[idx].type = E820_RAM;
> -
> -    /* .. and trim if neccessary */
> -    if (start_kb && map_limitkb > start_kb) {
> -        delta_kb = map_limitkb - start_kb;
> -        if (delta_kb)
> -            e820[idx].size -= (uint64_t)(delta_kb << 10);
> -    }
> -    /* Note: We don't touch balloon_kb here. Will add it at the end. */
> -    ram_end = e820[idx].addr + e820[idx].size;
> -    idx ++;
> -
> -    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
> -               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
> -               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
> -               ram_end >> 12, delta_kb, start_kb ,start >> 12,
> -               (uint64_t)balloon_kb);
> -
> -
> -    /* This whole code below is to guard against if the Intel IGD is passed into
> -     * the guest. If we don't pass in IGD, this whole code can be ignored.
> -     *
> -     * The reason for this code is that Intel boxes fill their E820 with
> -     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
> -     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
> -     * Linux and it would be utilized by the Intel IGD as I/O space while
> -     * in reality it was an RAM region.
> -     *
> -     * What this means is that we have to walk the E820 and for any region
> -     * that is RAM and below 4GB and above ram_end, needs to change its type
> -     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
> -     * the overlap with ram_end. */
> -    for (i = 0; i < nr; i++) {
> -        uint64_t end = src[i].addr + src[i].size;
> -
> -        /* We don't care about E820_UNUSABLE, but we need to
> -         * change the type to zero b/c the loop after this
> -         * sticks E820_UNUSABLE on the guest's E820 but ignores
> -         * the ones with type zero. */
> -        if ((src[i].type == E820_UNUSABLE) ||
> -            /* Any region that is within the "RAM region" can
> -             * be safely ditched. */
> -            (end < ram_end)) {
> -                src[i].type = 0;
> -                continue;
> -        }
> -
> -        /* Look only at RAM regions. */
> -        if (src[i].type != E820_RAM)
> -            continue;
> -
> -        /* We only care about RAM regions below 4GB. */
> -        if (src[i].addr >= (1ULL<<32))
> -            continue;
> -
> -        /* E820_RAM overlaps with our RAM region. Move it */
> -        if (src[i].addr < ram_end) {
> -            uint64_t delta;
> -
> -            src[i].type = E820_UNUSABLE;
> -            delta = ram_end - src[i].addr;
> -            /* The end < ram_end should weed this out */
> -            if (src[i].size - delta < 0)
> -                src[i].type = 0;
> -            else {
> -                src[i].size -= delta;
> -                src[i].addr = ram_end;
> -            }
> -            if (src[i].addr + src[i].size != end) {
> -                /* We messed up somewhere */
> -                src[i].type = 0;
> -                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
> -            }
> -        }
> -        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
> -           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
> -            "xen/setup: Inhibit resource API from using System RAM E820
> -           gaps as PCI mem gaps" for full explanation. */
> -        if (end > ram_end)
> -            src[i].type = E820_UNUSABLE;
> -    }
> -
> -    /* Check if there is a region between ram_end and start. */
> -    if (start > ram_end) {
> -        int add_unusable = 1;
> -        for (i = 0; i < nr && add_unusable; i++) {
> -            if (src[i].type != E820_UNUSABLE)
> -                continue;
> -            if (ram_end != src[i].addr)
> -                continue;
> -            if (start != src[i].addr + src[i].size) {
> -                /* there is one, adjust it */
> -                src[i].size = start - src[i].addr;
> -            }
> -            add_unusable = 0;
> -        }
> -        /* .. and if not present, add it in. This is to guard against
> -           the Linux guest assuming that the gap between the end of
> -           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
> -           is PCI I/O space. Which it certainly is _not_. */
> -        if (add_unusable) {
> -            e820[idx].type = E820_UNUSABLE;
> -            e820[idx].addr = ram_end;
> -            e820[idx].size = start - ram_end;
> -            idx++;
> -        }
> -    }
> -    /* Almost done: copy them over, ignoring the undesireable ones */
> -    for (i = 0; i < nr; i++) {
> -        if ((src[i].type == E820_RAM) ||
> -            (src[i].type == 0))
> -            continue;
> -
> -        e820[idx].type = src[i].type;
> -        e820[idx].addr = src[i].addr;
> -        e820[idx].size = src[i].size;
> -        idx++;
> -    }
> -    /* At this point we have the mapped RAM + E820 entries from src. */
> -    if (balloon_kb) {
> -        /* and if we truncated the RAM region, then add it to the end. */
> -        e820[idx].type = E820_RAM;
> -        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
> -                         (uint64_t)(1ULL << 32) : last;
> -        /* also add the balloon memory to the end. */
> -        e820[idx].size = (uint64_t)(delta_kb << 10) +
> -                         (uint64_t)(balloon_kb << 10);
> -        idx++;
> -
> -    }
> -    nr = idx;
> -
> -    for (i = 0; i < nr; i++) {
> -      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
> -                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
> -                 e820_names(e820[i].type));
> -    }
> -
> -    /* Done: copy the sanitized version. */
> -    *nr_entries = nr;
> -    memcpy(src, e820, nr * sizeof(struct e820entry));
> -    return 0;
> -}
> -
> -int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> -{
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int rc;
> -    uint32_t nr;
> -    struct e820entry map[E820MAX];
> -    libxl_domain_build_info *b_info;
> -
> -    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
> -        return ERROR_INVAL;
> -
> -    b_info = &d_config->b_info;
> -    if (!b_info->u.pv.e820_host)
> -        return ERROR_INVAL;
> -
> -    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
> -    if (rc < 0) {
> -        errno = rc;
> -        return ERROR_FAIL;
> -    }
> -    nr = rc;
> -    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
> -                       (b_info->max_memkb - b_info->target_memkb) +
> -                       b_info->u.pv.slack_memkb);
> -    if (rc)
> -        return ERROR_FAIL;
> -
> -    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
> -
> -    if (rc < 0) {
> -        errno  = rc;
> -        return ERROR_FAIL;
> -    }
> -    return 0;
> -}
> -
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> new file mode 100644
> index 0000000..7e11f2d
> --- /dev/null
> +++ b/tools/libxl/libxl_x86.c
> @@ -0,0 +1,259 @@
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +static const char *e820_names(int type)
> +{
> +    switch (type) {
> +        case E820_RAM: return "RAM";
> +        case E820_RESERVED: return "Reserved";
> +        case E820_ACPI: return "ACPI";
> +        case E820_NVS: return "ACPI NVS";
> +        case E820_UNUSABLE: return "Unusable";
> +        default: break;
> +    }
> +    return "Unknown";
> +}
> +
> +static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
> +                         uint32_t *nr_entries,
> +                         unsigned long map_limitkb,
> +                         unsigned long balloon_kb)
> +{
> +    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
> +    uint32_t i, idx = 0, nr;
> +    struct e820entry e820[E820MAX];
> +
> +    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
> +        return ERROR_INVAL;
> +
> +    nr = *nr_entries;
> +    if (!nr)
> +        return ERROR_INVAL;
> +
> +    if (nr > E820MAX)
> +        return ERROR_NOMEM;
> +
> +    /* Weed out anything under 1MB */
> +    for (i = 0; i < nr; i++) {
> +        if (src[i].addr > 0x100000)
> +            continue;
> +
> +        src[i].type = 0;
> +        src[i].size = 0;
> +        src[i].addr = -1ULL;
> +    }
> +
> +    /* Find the lowest and highest entry in E820, skipping over
> +     * undesired entries. */
> +    start = -1ULL;
> +    last = 0;
> +    for (i = 0; i < nr; i++) {
> +        if ((src[i].type == E820_RAM) ||
> +            (src[i].type == E820_UNUSABLE) ||
> +            (src[i].type == 0))
> +            continue;
> +
> +        start = src[i].addr < start ? src[i].addr : start;
> +        last = src[i].addr + src[i].size > last ?
> +               src[i].addr + src[i].size > last : last;
> +    }
> +    if (start > 1024)
> +        start_kb = start >> 10;
> +
> +    /* Add the memory RAM region for the guest */
> +    e820[idx].addr = 0;
> +    e820[idx].size = (uint64_t)map_limitkb << 10;
> +    e820[idx].type = E820_RAM;
> +
> +    /* .. and trim if neccessary */
> +    if (start_kb && map_limitkb > start_kb) {
> +        delta_kb = map_limitkb - start_kb;
> +        if (delta_kb)
> +            e820[idx].size -= (uint64_t)(delta_kb << 10);
> +    }
> +    /* Note: We don't touch balloon_kb here. Will add it at the end. */
> +    ram_end = e820[idx].addr + e820[idx].size;
> +    idx ++;
> +
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
> +               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
> +               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
> +               ram_end >> 12, delta_kb, start_kb ,start >> 12,
> +               (uint64_t)balloon_kb);
> +
> +
> +    /* This whole code below is to guard against if the Intel IGD is passed into
> +     * the guest. If we don't pass in IGD, this whole code can be ignored.
> +     *
> +     * The reason for this code is that Intel boxes fill their E820 with
> +     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
> +     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
> +     * Linux and it would be utilized by the Intel IGD as I/O space while
> +     * in reality it was an RAM region.
> +     *
> +     * What this means is that we have to walk the E820 and for any region
> +     * that is RAM and below 4GB and above ram_end, needs to change its type
> +     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
> +     * the overlap with ram_end. */
> +    for (i = 0; i < nr; i++) {
> +        uint64_t end = src[i].addr + src[i].size;
> +
> +        /* We don't care about E820_UNUSABLE, but we need to
> +         * change the type to zero b/c the loop after this
> +         * sticks E820_UNUSABLE on the guest's E820 but ignores
> +         * the ones with type zero. */
> +        if ((src[i].type == E820_UNUSABLE) ||
> +            /* Any region that is within the "RAM region" can
> +             * be safely ditched. */
> +            (end < ram_end)) {
> +                src[i].type = 0;
> +                continue;
> +        }
> +
> +        /* Look only at RAM regions. */
> +        if (src[i].type != E820_RAM)
> +            continue;
> +
> +        /* We only care about RAM regions below 4GB. */
> +        if (src[i].addr >= (1ULL<<32))
> +            continue;
> +
> +        /* E820_RAM overlaps with our RAM region. Move it */
> +        if (src[i].addr < ram_end) {
> +            uint64_t delta;
> +
> +            src[i].type = E820_UNUSABLE;
> +            delta = ram_end - src[i].addr;
> +            /* The end < ram_end should weed this out */
> +            if (src[i].size - delta < 0)
> +                src[i].type = 0;
> +            else {
> +                src[i].size -= delta;
> +                src[i].addr = ram_end;
> +            }
> +            if (src[i].addr + src[i].size != end) {
> +                /* We messed up somewhere */
> +                src[i].type = 0;
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
> +            }
> +        }
> +        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
> +           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
> +            "xen/setup: Inhibit resource API from using System RAM E820
> +           gaps as PCI mem gaps" for full explanation. */
> +        if (end > ram_end)
> +            src[i].type = E820_UNUSABLE;
> +    }
> +
> +    /* Check if there is a region between ram_end and start. */
> +    if (start > ram_end) {
> +        int add_unusable = 1;
> +        for (i = 0; i < nr && add_unusable; i++) {
> +            if (src[i].type != E820_UNUSABLE)
> +                continue;
> +            if (ram_end != src[i].addr)
> +                continue;
> +            if (start != src[i].addr + src[i].size) {
> +                /* there is one, adjust it */
> +                src[i].size = start - src[i].addr;
> +            }
> +            add_unusable = 0;
> +        }
> +        /* .. and if not present, add it in. This is to guard against
> +           the Linux guest assuming that the gap between the end of
> +           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
> +           is PCI I/O space. Which it certainly is _not_. */
> +        if (add_unusable) {
> +            e820[idx].type = E820_UNUSABLE;
> +            e820[idx].addr = ram_end;
> +            e820[idx].size = start - ram_end;
> +            idx++;
> +        }
> +    }
> +    /* Almost done: copy them over, ignoring the undesireable ones */
> +    for (i = 0; i < nr; i++) {
> +        if ((src[i].type == E820_RAM) ||
> +            (src[i].type == 0))
> +            continue;
> +
> +        e820[idx].type = src[i].type;
> +        e820[idx].addr = src[i].addr;
> +        e820[idx].size = src[i].size;
> +        idx++;
> +    }
> +    /* At this point we have the mapped RAM + E820 entries from src. */
> +    if (balloon_kb) {
> +        /* and if we truncated the RAM region, then add it to the end. */
> +        e820[idx].type = E820_RAM;
> +        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
> +                         (uint64_t)(1ULL << 32) : last;
> +        /* also add the balloon memory to the end. */
> +        e820[idx].size = (uint64_t)(delta_kb << 10) +
> +                         (uint64_t)(balloon_kb << 10);
> +        idx++;
> +
> +    }
> +    nr = idx;
> +
> +    for (i = 0; i < nr; i++) {
> +      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
> +                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
> +                 e820_names(e820[i].type));
> +    }
> +
> +    /* Done: copy the sanitized version. */
> +    *nr_entries = nr;
> +    memcpy(src, e820, nr * sizeof(struct e820entry));
> +    return 0;
> +}
> +
> +static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int rc;
> +    uint32_t nr;
> +    struct e820entry map[E820MAX];
> +    libxl_domain_build_info *b_info;
> +
> +    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
> +        return ERROR_INVAL;
> +
> +    b_info = &d_config->b_info;
> +    if (!b_info->u.pv.e820_host)
> +        return ERROR_INVAL;
> +
> +    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
> +    if (rc < 0) {
> +        errno = rc;
> +        return ERROR_FAIL;
> +    }
> +    nr = rc;
> +    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
> +                       (b_info->max_memkb - b_info->target_memkb) +
> +                       b_info->u.pv.slack_memkb);
> +    if (rc)
> +        return ERROR_FAIL;
> +
> +    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
> +
> +    if (rc < 0) {
> +        errno  = rc;
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
> +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> +        uint32_t domid)
> +{
> +    int rc = 0;
> +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
> +        d_config->b_info.u.pv.e820_host) {
> +        rc = libxl__e820_alloc(gc, domid, d_config);
> +        if (rc)
> +            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
> +                      "Failed while collecting E820 with: %d (errno:%d)\n",
> +                      rc, errno);
> +    }
> +    return rc;
> +}
> --
> 1.7.2.5
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 09:26:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 09:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0rPq-0000Tt-HA; Fri, 24 Feb 2012 09:26: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 1S0rPp-0000To-9M
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 09:26:13 +0000
Received: from [85.158.139.83:24846] by server-5.bemta-5.messagelabs.com id
	05/B9-13566-4B7574F4; Fri, 24 Feb 2012 09:26:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330075571!9133297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17190 invoked from network); 24 Feb 2012 09:26:11 -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 Feb 2012 09:26:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10913238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 09:25:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 09:25:50 +0000
Message-ID: <1330075549.8557.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 09:25:49 +0000
In-Reply-To: <1330008712-17715-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231445500.23091@kaball-desktop>
	<1330008712-17715-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 7/7] libxl: Introduce
	libxl__arch_domain_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 14:51 +0000, Stefano Stabellini wrote:
> Introduce an arch specific internal domain creation function. At the
> moment only x86 provides an implementation.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(I thought I acked this last time)

> ---
>  tools/libxl/Makefile         |    6 +-
>  tools/libxl/libxl_arch.h     |   22 ++++
>  tools/libxl/libxl_create.c   |   12 +--
>  tools/libxl/libxl_internal.h |    2 -
>  tools/libxl/libxl_noarch.c   |    8 ++
>  tools/libxl/libxl_pci.c      |  242 ---------------------------------------
>  tools/libxl/libxl_x86.c      |  259 ++++++++++++++++++++++++++++++++++++++++++
>  7 files changed, 294 insertions(+), 257 deletions(-)
>  create mode 100644 tools/libxl/libxl_arch.h
>  create mode 100644 tools/libxl/libxl_noarch.c
>  create mode 100644 tools/libxl/libxl_x86.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 41b6ac4..ba5852b 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -34,9 +34,9 @@ LIBXL_OBJS-y += libxl_blktap2.o
>  else
>  LIBXL_OBJS-y += libxl_noblktap2.o
>  endif
> -LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
> -LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o
> +LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
> +LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_noarch.o
> 
>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_netbsd.o
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> new file mode 100644
> index 0000000..d1bbdf7
> --- /dev/null
> +++ b/tools/libxl/libxl_arch.h
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012      Citrix Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#ifndef LIBXL_ARCH_H
> +#define LIBXL_ARCH_H
> +
> +/* arch specific internal domain creation function */
> +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> +               uint32_t domid);
> +
> +#endif
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f28d814..ff589a8 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -18,6 +18,7 @@
>  #include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> +#include "libxl_arch.h"
> 
>  #include <xc_dom.h>
>  #include <xenguest.h>
> @@ -616,16 +617,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
>              goto error_out;
>          }
>      }
> -
> -    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
> -        d_config->b_info.u.pv.e820_host) {
> -        int rc;
> -        rc = libxl__e820_alloc(gc, domid, d_config);
> -        if (rc)
> -            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> -                      "Failed while collecting E820 with: %d (errno:%d)\n",
> -                      rc, errno);
> -    }
> +    libxl__arch_domain_create(gc, d_config, domid);
>      if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
>                  (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
>                   d_config->b_info.u.pv.bootloader ))) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8846c68..bd384e2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -975,8 +975,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
>  _hidden int libxl__file_reference_map(libxl_file_reference *f);
>  _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
> 
> -_hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
> -
>  /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */
>  _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
>  /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
> diff --git a/tools/libxl/libxl_noarch.c b/tools/libxl/libxl_noarch.c
> new file mode 100644
> index 0000000..7893535
> --- /dev/null
> +++ b/tools/libxl/libxl_noarch.c
> @@ -0,0 +1,8 @@
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> +                              uint32_t domid)
> +{
> +    return 0;
> +}
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 33425f5..d960f4b 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -1147,248 +1147,6 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
>      return 0;
>  }
> 
> -static const char *e820_names(int type)
> -{
> -    switch (type) {
> -        case E820_RAM: return "RAM";
> -        case E820_RESERVED: return "Reserved";
> -        case E820_ACPI: return "ACPI";
> -        case E820_NVS: return "ACPI NVS";
> -        case E820_UNUSABLE: return "Unusable";
> -        default: break;
> -    }
> -    return "Unknown";
> -}
> -
> -static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
> -                         uint32_t *nr_entries,
> -                         unsigned long map_limitkb,
> -                         unsigned long balloon_kb)
> -{
> -    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
> -    uint32_t i, idx = 0, nr;
> -    struct e820entry e820[E820MAX];
> -
> -    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
> -        return ERROR_INVAL;
> -
> -    nr = *nr_entries;
> -    if (!nr)
> -        return ERROR_INVAL;
> -
> -    if (nr > E820MAX)
> -        return ERROR_NOMEM;
> -
> -    /* Weed out anything under 1MB */
> -    for (i = 0; i < nr; i++) {
> -        if (src[i].addr > 0x100000)
> -            continue;
> -
> -        src[i].type = 0;
> -        src[i].size = 0;
> -        src[i].addr = -1ULL;
> -    }
> -
> -    /* Find the lowest and highest entry in E820, skipping over
> -     * undesired entries. */
> -    start = -1ULL;
> -    last = 0;
> -    for (i = 0; i < nr; i++) {
> -        if ((src[i].type == E820_RAM) ||
> -            (src[i].type == E820_UNUSABLE) ||
> -            (src[i].type == 0))
> -            continue;
> -
> -        start = src[i].addr < start ? src[i].addr : start;
> -        last = src[i].addr + src[i].size > last ?
> -               src[i].addr + src[i].size > last : last;
> -    }
> -    if (start > 1024)
> -        start_kb = start >> 10;
> -
> -    /* Add the memory RAM region for the guest */
> -    e820[idx].addr = 0;
> -    e820[idx].size = (uint64_t)map_limitkb << 10;
> -    e820[idx].type = E820_RAM;
> -
> -    /* .. and trim if neccessary */
> -    if (start_kb && map_limitkb > start_kb) {
> -        delta_kb = map_limitkb - start_kb;
> -        if (delta_kb)
> -            e820[idx].size -= (uint64_t)(delta_kb << 10);
> -    }
> -    /* Note: We don't touch balloon_kb here. Will add it at the end. */
> -    ram_end = e820[idx].addr + e820[idx].size;
> -    idx ++;
> -
> -    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
> -               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
> -               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
> -               ram_end >> 12, delta_kb, start_kb ,start >> 12,
> -               (uint64_t)balloon_kb);
> -
> -
> -    /* This whole code below is to guard against if the Intel IGD is passed into
> -     * the guest. If we don't pass in IGD, this whole code can be ignored.
> -     *
> -     * The reason for this code is that Intel boxes fill their E820 with
> -     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
> -     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
> -     * Linux and it would be utilized by the Intel IGD as I/O space while
> -     * in reality it was an RAM region.
> -     *
> -     * What this means is that we have to walk the E820 and for any region
> -     * that is RAM and below 4GB and above ram_end, needs to change its type
> -     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
> -     * the overlap with ram_end. */
> -    for (i = 0; i < nr; i++) {
> -        uint64_t end = src[i].addr + src[i].size;
> -
> -        /* We don't care about E820_UNUSABLE, but we need to
> -         * change the type to zero b/c the loop after this
> -         * sticks E820_UNUSABLE on the guest's E820 but ignores
> -         * the ones with type zero. */
> -        if ((src[i].type == E820_UNUSABLE) ||
> -            /* Any region that is within the "RAM region" can
> -             * be safely ditched. */
> -            (end < ram_end)) {
> -                src[i].type = 0;
> -                continue;
> -        }
> -
> -        /* Look only at RAM regions. */
> -        if (src[i].type != E820_RAM)
> -            continue;
> -
> -        /* We only care about RAM regions below 4GB. */
> -        if (src[i].addr >= (1ULL<<32))
> -            continue;
> -
> -        /* E820_RAM overlaps with our RAM region. Move it */
> -        if (src[i].addr < ram_end) {
> -            uint64_t delta;
> -
> -            src[i].type = E820_UNUSABLE;
> -            delta = ram_end - src[i].addr;
> -            /* The end < ram_end should weed this out */
> -            if (src[i].size - delta < 0)
> -                src[i].type = 0;
> -            else {
> -                src[i].size -= delta;
> -                src[i].addr = ram_end;
> -            }
> -            if (src[i].addr + src[i].size != end) {
> -                /* We messed up somewhere */
> -                src[i].type = 0;
> -                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
> -            }
> -        }
> -        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
> -           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
> -            "xen/setup: Inhibit resource API from using System RAM E820
> -           gaps as PCI mem gaps" for full explanation. */
> -        if (end > ram_end)
> -            src[i].type = E820_UNUSABLE;
> -    }
> -
> -    /* Check if there is a region between ram_end and start. */
> -    if (start > ram_end) {
> -        int add_unusable = 1;
> -        for (i = 0; i < nr && add_unusable; i++) {
> -            if (src[i].type != E820_UNUSABLE)
> -                continue;
> -            if (ram_end != src[i].addr)
> -                continue;
> -            if (start != src[i].addr + src[i].size) {
> -                /* there is one, adjust it */
> -                src[i].size = start - src[i].addr;
> -            }
> -            add_unusable = 0;
> -        }
> -        /* .. and if not present, add it in. This is to guard against
> -           the Linux guest assuming that the gap between the end of
> -           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
> -           is PCI I/O space. Which it certainly is _not_. */
> -        if (add_unusable) {
> -            e820[idx].type = E820_UNUSABLE;
> -            e820[idx].addr = ram_end;
> -            e820[idx].size = start - ram_end;
> -            idx++;
> -        }
> -    }
> -    /* Almost done: copy them over, ignoring the undesireable ones */
> -    for (i = 0; i < nr; i++) {
> -        if ((src[i].type == E820_RAM) ||
> -            (src[i].type == 0))
> -            continue;
> -
> -        e820[idx].type = src[i].type;
> -        e820[idx].addr = src[i].addr;
> -        e820[idx].size = src[i].size;
> -        idx++;
> -    }
> -    /* At this point we have the mapped RAM + E820 entries from src. */
> -    if (balloon_kb) {
> -        /* and if we truncated the RAM region, then add it to the end. */
> -        e820[idx].type = E820_RAM;
> -        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
> -                         (uint64_t)(1ULL << 32) : last;
> -        /* also add the balloon memory to the end. */
> -        e820[idx].size = (uint64_t)(delta_kb << 10) +
> -                         (uint64_t)(balloon_kb << 10);
> -        idx++;
> -
> -    }
> -    nr = idx;
> -
> -    for (i = 0; i < nr; i++) {
> -      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
> -                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
> -                 e820_names(e820[i].type));
> -    }
> -
> -    /* Done: copy the sanitized version. */
> -    *nr_entries = nr;
> -    memcpy(src, e820, nr * sizeof(struct e820entry));
> -    return 0;
> -}
> -
> -int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> -{
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int rc;
> -    uint32_t nr;
> -    struct e820entry map[E820MAX];
> -    libxl_domain_build_info *b_info;
> -
> -    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
> -        return ERROR_INVAL;
> -
> -    b_info = &d_config->b_info;
> -    if (!b_info->u.pv.e820_host)
> -        return ERROR_INVAL;
> -
> -    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
> -    if (rc < 0) {
> -        errno = rc;
> -        return ERROR_FAIL;
> -    }
> -    nr = rc;
> -    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
> -                       (b_info->max_memkb - b_info->target_memkb) +
> -                       b_info->u.pv.slack_memkb);
> -    if (rc)
> -        return ERROR_FAIL;
> -
> -    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
> -
> -    if (rc < 0) {
> -        errno  = rc;
> -        return ERROR_FAIL;
> -    }
> -    return 0;
> -}
> -
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> new file mode 100644
> index 0000000..7e11f2d
> --- /dev/null
> +++ b/tools/libxl/libxl_x86.c
> @@ -0,0 +1,259 @@
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +static const char *e820_names(int type)
> +{
> +    switch (type) {
> +        case E820_RAM: return "RAM";
> +        case E820_RESERVED: return "Reserved";
> +        case E820_ACPI: return "ACPI";
> +        case E820_NVS: return "ACPI NVS";
> +        case E820_UNUSABLE: return "Unusable";
> +        default: break;
> +    }
> +    return "Unknown";
> +}
> +
> +static int e820_sanitize(libxl_ctx *ctx, struct e820entry src[],
> +                         uint32_t *nr_entries,
> +                         unsigned long map_limitkb,
> +                         unsigned long balloon_kb)
> +{
> +    uint64_t delta_kb = 0, start = 0, start_kb = 0, last = 0, ram_end;
> +    uint32_t i, idx = 0, nr;
> +    struct e820entry e820[E820MAX];
> +
> +    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
> +        return ERROR_INVAL;
> +
> +    nr = *nr_entries;
> +    if (!nr)
> +        return ERROR_INVAL;
> +
> +    if (nr > E820MAX)
> +        return ERROR_NOMEM;
> +
> +    /* Weed out anything under 1MB */
> +    for (i = 0; i < nr; i++) {
> +        if (src[i].addr > 0x100000)
> +            continue;
> +
> +        src[i].type = 0;
> +        src[i].size = 0;
> +        src[i].addr = -1ULL;
> +    }
> +
> +    /* Find the lowest and highest entry in E820, skipping over
> +     * undesired entries. */
> +    start = -1ULL;
> +    last = 0;
> +    for (i = 0; i < nr; i++) {
> +        if ((src[i].type == E820_RAM) ||
> +            (src[i].type == E820_UNUSABLE) ||
> +            (src[i].type == 0))
> +            continue;
> +
> +        start = src[i].addr < start ? src[i].addr : start;
> +        last = src[i].addr + src[i].size > last ?
> +               src[i].addr + src[i].size > last : last;
> +    }
> +    if (start > 1024)
> +        start_kb = start >> 10;
> +
> +    /* Add the memory RAM region for the guest */
> +    e820[idx].addr = 0;
> +    e820[idx].size = (uint64_t)map_limitkb << 10;
> +    e820[idx].type = E820_RAM;
> +
> +    /* .. and trim if neccessary */
> +    if (start_kb && map_limitkb > start_kb) {
> +        delta_kb = map_limitkb - start_kb;
> +        if (delta_kb)
> +            e820[idx].size -= (uint64_t)(delta_kb << 10);
> +    }
> +    /* Note: We don't touch balloon_kb here. Will add it at the end. */
> +    ram_end = e820[idx].addr + e820[idx].size;
> +    idx ++;
> +
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Memory: %"PRIu64"kB End of RAM: " \
> +               "0x%"PRIx64" (PFN) Delta: %"PRIu64"kB, PCI start: %"PRIu64"kB " \
> +               "(0x%"PRIx64" PFN), Balloon %"PRIu64"kB\n", (uint64_t)map_limitkb,
> +               ram_end >> 12, delta_kb, start_kb ,start >> 12,
> +               (uint64_t)balloon_kb);
> +
> +
> +    /* This whole code below is to guard against if the Intel IGD is passed into
> +     * the guest. If we don't pass in IGD, this whole code can be ignored.
> +     *
> +     * The reason for this code is that Intel boxes fill their E820 with
> +     * E820_RAM amongst E820_RESERVED and we can't just ditch those E820_RAM.
> +     * That is b/c any "gaps" in the E820 is considered PCI I/O space by
> +     * Linux and it would be utilized by the Intel IGD as I/O space while
> +     * in reality it was an RAM region.
> +     *
> +     * What this means is that we have to walk the E820 and for any region
> +     * that is RAM and below 4GB and above ram_end, needs to change its type
> +     * to E820_UNUSED. We also need to move some of the E820_RAM regions if
> +     * the overlap with ram_end. */
> +    for (i = 0; i < nr; i++) {
> +        uint64_t end = src[i].addr + src[i].size;
> +
> +        /* We don't care about E820_UNUSABLE, but we need to
> +         * change the type to zero b/c the loop after this
> +         * sticks E820_UNUSABLE on the guest's E820 but ignores
> +         * the ones with type zero. */
> +        if ((src[i].type == E820_UNUSABLE) ||
> +            /* Any region that is within the "RAM region" can
> +             * be safely ditched. */
> +            (end < ram_end)) {
> +                src[i].type = 0;
> +                continue;
> +        }
> +
> +        /* Look only at RAM regions. */
> +        if (src[i].type != E820_RAM)
> +            continue;
> +
> +        /* We only care about RAM regions below 4GB. */
> +        if (src[i].addr >= (1ULL<<32))
> +            continue;
> +
> +        /* E820_RAM overlaps with our RAM region. Move it */
> +        if (src[i].addr < ram_end) {
> +            uint64_t delta;
> +
> +            src[i].type = E820_UNUSABLE;
> +            delta = ram_end - src[i].addr;
> +            /* The end < ram_end should weed this out */
> +            if (src[i].size - delta < 0)
> +                src[i].type = 0;
> +            else {
> +                src[i].size -= delta;
> +                src[i].addr = ram_end;
> +            }
> +            if (src[i].addr + src[i].size != end) {
> +                /* We messed up somewhere */
> +                src[i].type = 0;
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Computed E820 wrongly. Continuing on.");
> +            }
> +        }
> +        /* Lastly, convert the RAM to UNSUABLE. Look in the Linux kernel
> +           at git commit 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
> +            "xen/setup: Inhibit resource API from using System RAM E820
> +           gaps as PCI mem gaps" for full explanation. */
> +        if (end > ram_end)
> +            src[i].type = E820_UNUSABLE;
> +    }
> +
> +    /* Check if there is a region between ram_end and start. */
> +    if (start > ram_end) {
> +        int add_unusable = 1;
> +        for (i = 0; i < nr && add_unusable; i++) {
> +            if (src[i].type != E820_UNUSABLE)
> +                continue;
> +            if (ram_end != src[i].addr)
> +                continue;
> +            if (start != src[i].addr + src[i].size) {
> +                /* there is one, adjust it */
> +                src[i].size = start - src[i].addr;
> +            }
> +            add_unusable = 0;
> +        }
> +        /* .. and if not present, add it in. This is to guard against
> +           the Linux guest assuming that the gap between the end of
> +           RAM region and the start of the E820_[ACPI,NVS,RESERVED]
> +           is PCI I/O space. Which it certainly is _not_. */
> +        if (add_unusable) {
> +            e820[idx].type = E820_UNUSABLE;
> +            e820[idx].addr = ram_end;
> +            e820[idx].size = start - ram_end;
> +            idx++;
> +        }
> +    }
> +    /* Almost done: copy them over, ignoring the undesireable ones */
> +    for (i = 0; i < nr; i++) {
> +        if ((src[i].type == E820_RAM) ||
> +            (src[i].type == 0))
> +            continue;
> +
> +        e820[idx].type = src[i].type;
> +        e820[idx].addr = src[i].addr;
> +        e820[idx].size = src[i].size;
> +        idx++;
> +    }
> +    /* At this point we have the mapped RAM + E820 entries from src. */
> +    if (balloon_kb) {
> +        /* and if we truncated the RAM region, then add it to the end. */
> +        e820[idx].type = E820_RAM;
> +        e820[idx].addr = (uint64_t)(1ULL << 32) > last ?
> +                         (uint64_t)(1ULL << 32) : last;
> +        /* also add the balloon memory to the end. */
> +        e820[idx].size = (uint64_t)(delta_kb << 10) +
> +                         (uint64_t)(balloon_kb << 10);
> +        idx++;
> +
> +    }
> +    nr = idx;
> +
> +    for (i = 0; i < nr; i++) {
> +      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, ":\t[%"PRIx64" -> %"PRIx64"] %s",
> +                 e820[i].addr >> 12, (e820[i].addr + e820[i].size) >> 12,
> +                 e820_names(e820[i].type));
> +    }
> +
> +    /* Done: copy the sanitized version. */
> +    *nr_entries = nr;
> +    memcpy(src, e820, nr * sizeof(struct e820entry));
> +    return 0;
> +}
> +
> +static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int rc;
> +    uint32_t nr;
> +    struct e820entry map[E820MAX];
> +    libxl_domain_build_info *b_info;
> +
> +    if (d_config == NULL || d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM)
> +        return ERROR_INVAL;
> +
> +    b_info = &d_config->b_info;
> +    if (!b_info->u.pv.e820_host)
> +        return ERROR_INVAL;
> +
> +    rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
> +    if (rc < 0) {
> +        errno = rc;
> +        return ERROR_FAIL;
> +    }
> +    nr = rc;
> +    rc = e820_sanitize(ctx, map, &nr, b_info->target_memkb,
> +                       (b_info->max_memkb - b_info->target_memkb) +
> +                       b_info->u.pv.slack_memkb);
> +    if (rc)
> +        return ERROR_FAIL;
> +
> +    rc = xc_domain_set_memory_map(ctx->xch, domid, map, nr);
> +
> +    if (rc < 0) {
> +        errno  = rc;
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
> +int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
> +        uint32_t domid)
> +{
> +    int rc = 0;
> +    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
> +        d_config->b_info.u.pv.e820_host) {
> +        rc = libxl__e820_alloc(gc, domid, d_config);
> +        if (rc)
> +            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
> +                      "Failed while collecting E820 with: %d (errno:%d)\n",
> +                      rc, errno);
> +    }
> +    return rc;
> +}
> --
> 1.7.2.5
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 09:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 09:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0rsR-0001ek-MR; Fri, 24 Feb 2012 09:55:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0rsQ-0001dz-HJ
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 09:55:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330077265!62749835!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24137 invoked from network); 24 Feb 2012 09:54:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 09:54:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 09:55:39 +0000
Message-Id: <4F476CA10200007800074942@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 09:55:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
In-Reply-To: <4F4679D1.3000806@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Marek Marczykowski <marmarek@mimuw.edu.pl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.02.12 at 18:39, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> So, you're saying those (presumed) bugs a fixed only in the pvops, and
> not in xenlinux?

Certainly not in this old a version that you're using.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 09:56:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 09:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0rsR-0001ek-MR; Fri, 24 Feb 2012 09:55:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0rsQ-0001dz-HJ
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 09:55:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330077265!62749835!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24137 invoked from network); 24 Feb 2012 09:54:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 09:54:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 09:55:39 +0000
Message-Id: <4F476CA10200007800074942@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 09:55:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Joanna Rutkowska" <joanna@invisiblethingslab.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
In-Reply-To: <4F4679D1.3000806@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Marek Marczykowski <marmarek@mimuw.edu.pl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.02.12 at 18:39, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> So, you're saying those (presumed) bugs a fixed only in the pvops, and
> not in xenlinux?

Certainly not in this old a version that you're using.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:12:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0s8L-0002vu-Nz; Fri, 24 Feb 2012 10:12:13 +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 1S0s8J-0002vf-DH
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:12:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330078272!54137903!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20648 invoked from network); 24 Feb 2012 10:11:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-27.messagelabs.com with SMTP;
	24 Feb 2012 10:11:12 -0000
Received: from [62.94.180.152] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75825014; Fri, 24 Feb 2012 11:12:05 +0100
Message-ID: <1330078323.5034.73.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 11:12:03 +0100
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8092110940503748202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8092110940503748202==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xhm0RlRfe6wv4g887RBW"


--=-xhm0RlRfe6wv4g887RBW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi guys,

As some of you know I'm working on putting some kind of NUMA-aware
placement of the various VMs within Xen. This means I'm investigating
deeply how memory allocation works, which isn't an easy task for me (I
started completely from scratch), so forgive me if I say something
wrong! :-P

The status is I'm dealing for a while with a "design issue" I'd be very
glad to discuss with someone, as I'm not sure which path to go for...

To keep it short, what I need is a place --ideally during VM creation--
where I can check how much memory a VM wants against how much memory is
available in the various NUMA-nodes, and use this as the basis of my
decision. The question is, where is this place?

I traced memory related calls (e.g., for HVMs) from libxl__build_hvm to
xc_hvm_build_target_mem to setup_guest to xc_domain_populate_physmap and
alloc_domheap_pages. The last twos have been my target for a while, but
I'm not so sure they would be the right choice, mainly because both of
them are called for allocating _only_part_ of the VM's memory, i.e.,
some extents of it at each call (am I right?).

Basically, given alloc_domheap_pages uses d->node_affinity for deciding
from which node(s) to actually take memory from, I was planning to
either use the same mask or build a new one with similar purposes, the
problem being _where_ to populate it with the proper nodes.
I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
although I think it's too early, and I'd end up guessing wrt a lot of
aspects... But considering xm/xend was doing the same even earlier (at
least I think)...

Sorry fro writing so much... Any help/ideas you feel comfortable with
sharing would be very appreciated! :-)

Thanks a lot 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)



--=-xhm0RlRfe6wv4g887RBW
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)

iEYEABECAAYFAk9HYnMACgkQk4XaBE3IOsTYjQCeO9xkoyIuKP5nvrcIFs3ivUqh
RL4AoKSl4JqhEAsQXM/cHp9C0DEbHEvH
=sQGs
-----END PGP SIGNATURE-----

--=-xhm0RlRfe6wv4g887RBW--



--===============8092110940503748202==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8092110940503748202==--



From xen-devel-bounces@lists.xen.org Fri Feb 24 10:12:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0s8L-0002vu-Nz; Fri, 24 Feb 2012 10:12:13 +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 1S0s8J-0002vf-DH
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:12:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330078272!54137903!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20648 invoked from network); 24 Feb 2012 10:11:12 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-27.messagelabs.com with SMTP;
	24 Feb 2012 10:11:12 -0000
Received: from [62.94.180.152] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75825014; Fri, 24 Feb 2012 11:12:05 +0100
Message-ID: <1330078323.5034.73.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 11:12:03 +0100
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8092110940503748202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8092110940503748202==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-xhm0RlRfe6wv4g887RBW"


--=-xhm0RlRfe6wv4g887RBW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi guys,

As some of you know I'm working on putting some kind of NUMA-aware
placement of the various VMs within Xen. This means I'm investigating
deeply how memory allocation works, which isn't an easy task for me (I
started completely from scratch), so forgive me if I say something
wrong! :-P

The status is I'm dealing for a while with a "design issue" I'd be very
glad to discuss with someone, as I'm not sure which path to go for...

To keep it short, what I need is a place --ideally during VM creation--
where I can check how much memory a VM wants against how much memory is
available in the various NUMA-nodes, and use this as the basis of my
decision. The question is, where is this place?

I traced memory related calls (e.g., for HVMs) from libxl__build_hvm to
xc_hvm_build_target_mem to setup_guest to xc_domain_populate_physmap and
alloc_domheap_pages. The last twos have been my target for a while, but
I'm not so sure they would be the right choice, mainly because both of
them are called for allocating _only_part_ of the VM's memory, i.e.,
some extents of it at each call (am I right?).

Basically, given alloc_domheap_pages uses d->node_affinity for deciding
from which node(s) to actually take memory from, I was planning to
either use the same mask or build a new one with similar purposes, the
problem being _where_ to populate it with the proper nodes.
I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
although I think it's too early, and I'd end up guessing wrt a lot of
aspects... But considering xm/xend was doing the same even earlier (at
least I think)...

Sorry fro writing so much... Any help/ideas you feel comfortable with
sharing would be very appreciated! :-)

Thanks a lot 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)



--=-xhm0RlRfe6wv4g887RBW
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)

iEYEABECAAYFAk9HYnMACgkQk4XaBE3IOsTYjQCeO9xkoyIuKP5nvrcIFs3ivUqh
RL4AoKSl4JqhEAsQXM/cHp9C0DEbHEvH
=sQGs
-----END PGP SIGNATURE-----

--=-xhm0RlRfe6wv4g887RBW--



--===============8092110940503748202==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8092110940503748202==--



From xen-devel-bounces@lists.xen.org Fri Feb 24 10:13:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0s92-0002ze-AM; Fri, 24 Feb 2012 10:12:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0s91-0002yy-6k
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:12:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330078368!16705077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 830 invoked from network); 24 Feb 2012 10:12:48 -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 Feb 2012 10:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10914517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:11:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:11:45 +0000
Message-ID: <1330078304.8557.157.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 24 Feb 2012 10:11:44 +0000
In-Reply-To: <1329999531.19361.74.camel@elijah>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 12:18 +0000, George Dunlap wrote:
> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
> > What if you switch back without making sure you are in such a state? I
> > think switching between the two is where the potential for unexpected
> > behaviour is most likely.
> 
> Yeah, correctly predicting what would happen requires understanding what
> mem-set does under the hood.
> 
> > I like that you have to explicitly ask for the safety wheels to come off
> > and explicitly put them back on again. It avoids the corner cases I
> > alluded to above (at least I hope so).
> 
> Yes, I think your suggestion sounds more like driving a car with a
> proper hood, and less like driving a go-kart with the engine
> exposed. :-)

yeah, I'm way past "live fast die young" ;-)

> 
> > Without wishing to put words in Andres' mouth I expect that he intended
> > "footprint" to cover other technical means than paging too --
> > specifically I expect he was thinking of page sharing. (I suppose it
> > also covers PoD to some extent too, although that is something of a
> > special case)
> > 
> > While I don't expect there will be a knob to control number of shared
> > pages (either you can share some pages or not, the settings would be
> > more about how aggressively you search for sharable pages) it might be
> > useful to consider the interaction between paging and sharing, I expect
> > that most sharing configurations would want to have paging on at the
> > same time (for safety). It seems valid to me to want to say "make the
> > guest use this amount of actual RAM" and to achieve that by sharing what
> > you can and then paging the rest.
> 
> Yes, it's worth thinking about; as long as it doesn't stall the paging
> UI too long. :-)

Right. I think the only issue here is whether we make the control called
"paging-foo" or "footprint-foo".

I think your point that this control doesn't actually control sharing is
a good one. In reality it control's paging and if sharing is enabled
then it is a best effort thing which simply alleviates the need to do
some amount of paging to reach the paging target.

> The thing is, you can't actually control how much sharing happens.  That
> depends largely on whether the guests create and maintain pages which
> are share-able, and whether the sharing detection algorithm can find
> such pages.  Even if two guests are sharing 95% of their pages, at any
> point one of the guests may simply go wild and change them all.  So it
> seems to me that shared pages need to be treated like sunny days in the
> UK: Enjoy them while they're there, but don't count on them. :-)
> 
> Given that, I think that each VM should have a "guaranteed minimum
> memory footprint", which would be the amount of actual host ram it will
> have if suddenly no shared pages become available.  After that, there
> should be a policy of how to use the "windfall" or "bonus" pages
> generated by sharing.

> One sensible default policy would be "givers gain": Every guest which
> creates a page which happens to be shared by another VM gets a share of
> the pages freed up by the sharing.  Another policy might be "communism",
> where the freed up pages are shared among all VMs, regardless of whose
> pages made the benefit possible.  (In fact, if shared pages come from
> zero pages, they should probably be given to VMs with no zero pages,
> regardless of the policy.)

An easily policy to implement initially would be "do nothing and use
tmem".

> However, I'd say the main public "knobs" should be just consist of two
> things: 
> * xl mem-set memory-target.  This is the minimum amount of physical RAM
> a guest can get; we make sure that the sum of these for all VMs does not
> exceed the host capacity.

Isn't this what we've previously called mem-paging-set? We defined
mem-set earlier as controlling the amount of RAM the guest _thinks_ it
has, which is different.

> * xl sharing-policy [policy].  This tells the sharing system how to use
> the "windfall" pages gathered from page sharing.  
> 
> Then internally, the sharing system should combine the "minimum
> footprint" with the number of extra pages and the policy to set the
> amount of memory actually used (via balloon driver or paging).

This is an argument in favour of mem-footprint-set rather than
mem-paging set?

Here is an updated version of my proposed interface which includes
sharing, I think as you described (modulo the use of mem-paging-set
where you said mem-set above).

I also included "mem-paging-set manual" as an explicit thing with an
error on "mem-paging-set N" if you don't switch to manual mode. This
might be too draconian -- I'm not wedded to it.

maxmem=X                        # maximum RAM the domain can ever see
memory=M                        # current amount of RAM seen by the
				# domain
paging=[off|on]                 # allow the amount of memory a guest 
                                # thinks it has to differ from the
                                # amount actually available to it (its
                                # "footprint")
pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
                                # "footprint" for guests which do not
                                # voluntarily obey changes to memory=M 
pagingdelay=60                  # amount of time to give a guest to 
                                # voluntarily comply before enforcing a 
                                # footprint
pagesharing=[off|on]		# cause this guest to share pages with
				# other similarly enabled guests where
				# possible. Requires paging=on.
pageextrapolocy=...		# controls what happens to extra pages 
				# gain via sharing (could be combined 
				# with pagesharing option:
				#	[off|policy|...])

        Open question -- does pagesharing=on require paging=on? I've
        tried to specify things below such that it does not, but it
        might simplify things to require this.

xl mem-set domain M
        Sets the amount of RAM which the guest believes it has available
        to M. The guest should arrange to use only that much RAM and
        return the rest to the hypervisor (e.g. by using a balloon
        driver). If the guest does not do so then the host may use
        technical means to enforce the guest's footprint of M. The guest
        may suffer a performance penalty for this enforcement.

        paging off:     set balloon target to M.
        paging on:      set balloon target to M.
                        if pagingauto:
                                wait delay IFF new target < old
                                set paging target to M
                                support -t <delay> to override default?

        Open question -- if a domain balloons to M as requested should
        it still be subject to sharing? There is a performance hit
        associated with sharing (far less than paging though?) but
        presumably the admin would not have enabled sharing if they
        didn't want this, therefore I think it is right for sharing on
        to allow the guest to actually have <M assigned to it. Might be
        a function of the individual sharing policy?

xl mem-paging-set domain manual
	Enables manual control of paging target.

	paging off:	error
	paging on:	set pagingauto=off
	sharing on:	same as paging on.

xl mem-paging-set domain N
        Overrides the amount of RAM which the guest actually has
        available (its "footprint") to N. The host will use technical
        means to continue to provide the illusion to the guest that it
        has memory=M (as adjusted by mem-set). There may be a
        performance penalty for this.
        
        paging off:     error
        paging on:      if pagingauto=on:
				error
			set paging target
                        set pagingauto=off

xl mem-paging-set domain auto
        Automatically manage paging. Request that the guest uses
        memory=M (current value of memory, as adjusted by mem-set)
        enforced when the guest is uncooperative (as described in
        "mem-set")
        
        paging off:     error
        paging on:      set paging target to M
                        set pagingauto=on

xl mem-sharing-policy-set domain [policy]
	Configures policy for use of extra pages.

	if !paging || pagingauto:
		If guest's actual usage drops below M due to sharing 
		then extra pages are distributed per the sharing policy.
	else:
		If If guest's actual usage drops below N due to sharing
		then extra pages are distributed per the sharing policy.

	TBD potential policies.

        NB: shared pages reduce a domain's actual usage. Therefore it is
        possible that sharing reduces the usage to less than the paging
        target. In this case no pages will be paged out.
        
We should ensure that the sum over for all domains of:
	pagingauto(D)? M : N
does not exceed the amount of host memory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:13:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0s92-0002ze-AM; Fri, 24 Feb 2012 10:12:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0s91-0002yy-6k
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:12:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330078368!16705077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 830 invoked from network); 24 Feb 2012 10:12:48 -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 Feb 2012 10:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10914517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:11:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:11:45 +0000
Message-ID: <1330078304.8557.157.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 24 Feb 2012 10:11:44 +0000
In-Reply-To: <1329999531.19361.74.camel@elijah>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 12:18 +0000, George Dunlap wrote:
> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
> > What if you switch back without making sure you are in such a state? I
> > think switching between the two is where the potential for unexpected
> > behaviour is most likely.
> 
> Yeah, correctly predicting what would happen requires understanding what
> mem-set does under the hood.
> 
> > I like that you have to explicitly ask for the safety wheels to come off
> > and explicitly put them back on again. It avoids the corner cases I
> > alluded to above (at least I hope so).
> 
> Yes, I think your suggestion sounds more like driving a car with a
> proper hood, and less like driving a go-kart with the engine
> exposed. :-)

yeah, I'm way past "live fast die young" ;-)

> 
> > Without wishing to put words in Andres' mouth I expect that he intended
> > "footprint" to cover other technical means than paging too --
> > specifically I expect he was thinking of page sharing. (I suppose it
> > also covers PoD to some extent too, although that is something of a
> > special case)
> > 
> > While I don't expect there will be a knob to control number of shared
> > pages (either you can share some pages or not, the settings would be
> > more about how aggressively you search for sharable pages) it might be
> > useful to consider the interaction between paging and sharing, I expect
> > that most sharing configurations would want to have paging on at the
> > same time (for safety). It seems valid to me to want to say "make the
> > guest use this amount of actual RAM" and to achieve that by sharing what
> > you can and then paging the rest.
> 
> Yes, it's worth thinking about; as long as it doesn't stall the paging
> UI too long. :-)

Right. I think the only issue here is whether we make the control called
"paging-foo" or "footprint-foo".

I think your point that this control doesn't actually control sharing is
a good one. In reality it control's paging and if sharing is enabled
then it is a best effort thing which simply alleviates the need to do
some amount of paging to reach the paging target.

> The thing is, you can't actually control how much sharing happens.  That
> depends largely on whether the guests create and maintain pages which
> are share-able, and whether the sharing detection algorithm can find
> such pages.  Even if two guests are sharing 95% of their pages, at any
> point one of the guests may simply go wild and change them all.  So it
> seems to me that shared pages need to be treated like sunny days in the
> UK: Enjoy them while they're there, but don't count on them. :-)
> 
> Given that, I think that each VM should have a "guaranteed minimum
> memory footprint", which would be the amount of actual host ram it will
> have if suddenly no shared pages become available.  After that, there
> should be a policy of how to use the "windfall" or "bonus" pages
> generated by sharing.

> One sensible default policy would be "givers gain": Every guest which
> creates a page which happens to be shared by another VM gets a share of
> the pages freed up by the sharing.  Another policy might be "communism",
> where the freed up pages are shared among all VMs, regardless of whose
> pages made the benefit possible.  (In fact, if shared pages come from
> zero pages, they should probably be given to VMs with no zero pages,
> regardless of the policy.)

An easily policy to implement initially would be "do nothing and use
tmem".

> However, I'd say the main public "knobs" should be just consist of two
> things: 
> * xl mem-set memory-target.  This is the minimum amount of physical RAM
> a guest can get; we make sure that the sum of these for all VMs does not
> exceed the host capacity.

Isn't this what we've previously called mem-paging-set? We defined
mem-set earlier as controlling the amount of RAM the guest _thinks_ it
has, which is different.

> * xl sharing-policy [policy].  This tells the sharing system how to use
> the "windfall" pages gathered from page sharing.  
> 
> Then internally, the sharing system should combine the "minimum
> footprint" with the number of extra pages and the policy to set the
> amount of memory actually used (via balloon driver or paging).

This is an argument in favour of mem-footprint-set rather than
mem-paging set?

Here is an updated version of my proposed interface which includes
sharing, I think as you described (modulo the use of mem-paging-set
where you said mem-set above).

I also included "mem-paging-set manual" as an explicit thing with an
error on "mem-paging-set N" if you don't switch to manual mode. This
might be too draconian -- I'm not wedded to it.

maxmem=X                        # maximum RAM the domain can ever see
memory=M                        # current amount of RAM seen by the
				# domain
paging=[off|on]                 # allow the amount of memory a guest 
                                # thinks it has to differ from the
                                # amount actually available to it (its
                                # "footprint")
pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
                                # "footprint" for guests which do not
                                # voluntarily obey changes to memory=M 
pagingdelay=60                  # amount of time to give a guest to 
                                # voluntarily comply before enforcing a 
                                # footprint
pagesharing=[off|on]		# cause this guest to share pages with
				# other similarly enabled guests where
				# possible. Requires paging=on.
pageextrapolocy=...		# controls what happens to extra pages 
				# gain via sharing (could be combined 
				# with pagesharing option:
				#	[off|policy|...])

        Open question -- does pagesharing=on require paging=on? I've
        tried to specify things below such that it does not, but it
        might simplify things to require this.

xl mem-set domain M
        Sets the amount of RAM which the guest believes it has available
        to M. The guest should arrange to use only that much RAM and
        return the rest to the hypervisor (e.g. by using a balloon
        driver). If the guest does not do so then the host may use
        technical means to enforce the guest's footprint of M. The guest
        may suffer a performance penalty for this enforcement.

        paging off:     set balloon target to M.
        paging on:      set balloon target to M.
                        if pagingauto:
                                wait delay IFF new target < old
                                set paging target to M
                                support -t <delay> to override default?

        Open question -- if a domain balloons to M as requested should
        it still be subject to sharing? There is a performance hit
        associated with sharing (far less than paging though?) but
        presumably the admin would not have enabled sharing if they
        didn't want this, therefore I think it is right for sharing on
        to allow the guest to actually have <M assigned to it. Might be
        a function of the individual sharing policy?

xl mem-paging-set domain manual
	Enables manual control of paging target.

	paging off:	error
	paging on:	set pagingauto=off
	sharing on:	same as paging on.

xl mem-paging-set domain N
        Overrides the amount of RAM which the guest actually has
        available (its "footprint") to N. The host will use technical
        means to continue to provide the illusion to the guest that it
        has memory=M (as adjusted by mem-set). There may be a
        performance penalty for this.
        
        paging off:     error
        paging on:      if pagingauto=on:
				error
			set paging target
                        set pagingauto=off

xl mem-paging-set domain auto
        Automatically manage paging. Request that the guest uses
        memory=M (current value of memory, as adjusted by mem-set)
        enforced when the guest is uncooperative (as described in
        "mem-set")
        
        paging off:     error
        paging on:      set paging target to M
                        set pagingauto=on

xl mem-sharing-policy-set domain [policy]
	Configures policy for use of extra pages.

	if !paging || pagingauto:
		If guest's actual usage drops below M due to sharing 
		then extra pages are distributed per the sharing policy.
	else:
		If If guest's actual usage drops below N due to sharing
		then extra pages are distributed per the sharing policy.

	TBD potential policies.

        NB: shared pages reduce a domain's actual usage. Therefore it is
        possible that sharing reduces the usage to less than the paging
        target. In this case no pages will be paged out.
        
We should ensure that the sum over for all domains of:
	pagingauto(D)? M : N
does not exceed the amount of host memory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0s9H-00031v-Nz; Fri, 24 Feb 2012 10:13:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1S0s9F-00031P-So; Fri, 24 Feb 2012 10:13:10 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330078347!53828416!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_16,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 523 invoked from network); 24 Feb 2012 10:12:27 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-12.tower-27.messagelabs.com with SMTP;
	24 Feb 2012 10:12:27 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 4C926D347C1;
	Fri, 24 Feb 2012 11:13:08 +0100 (CET)
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 62eDO21ZKctc; Fri, 24 Feb 2012 11:13:01 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id E2DC2D3471A;
	Fri, 24 Feb 2012 11:13:00 +0100 (CET)
To: xen-users@lists.xen.org
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
Date: Fri, 24 Feb 2012 11:12:59 +0100
MIME-Version: 1.0
Message-Id: <201202241112.59801.tobias.geiger@vido.info>
Cc: ray@aarden.us, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] GPU Pass Through Comment - DomU GPU
	Performance Regression after Reboot - Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi!

after the first disappointment about the FirePro-Driver not solving my issue, i 
fiddled around with this problem and finally found a solution which solves the 
Performance-Regression i'm experiencing in my setup;

The Problem is: GPU Performance degrades to about 10% after a DomU Reboot (GPU 
is ATI, but this also happend with a NVIDIA iirc , so no ATI-specific Problem).

The Workaround: too easy :) Simply "Eject" the GPU after Windows has booted - 
the screen goes black, it re-initializes the Card and re-attaches after a few 
seconds. From then on Performance is back to normal.
Ejecting is done via the little Device-Manager Icon in the Taskbar (this one: 
http://www.technipages.com/wp-content/uploads/2011/01/Windows-7-Remove-
Hardware-option.pngwww.technipages.com/wp-content/uploads/2011/01/Windows-7-
Remove-Hardware-option.png )

To Automate this, i used a little tool called "DevEject" from heise.de - it's 
"OpenSource" Licensed and works even in Win7-64:
ftp://ftp.heise.de/pub/ct/listings/0316-208.zip
There may be other Tools/Scripting solutions via WSH/Powershell/VBS/CMD/...

Greetings!
Tobias

Am Donnerstag, 23. Februar 2012, 01:39:08 schrieb ray@aarden.us:
> After reading many posts on GPU pass through failing on reboot of the domU, 
>I questioned AMD and they responded with:
> 
>This is the known and documented issue with hypervisor - Resolved issues 
>(release notes) with driver  8.83.5.4 and above - May see system hang on 
>restart with some hypervisors.  Consider using a more recent firepro driver at 
>support.amd.com. 
>
>
>ray

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0s9H-00031v-Nz; Fri, 24 Feb 2012 10:13:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1S0s9F-00031P-So; Fri, 24 Feb 2012 10:13:10 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330078347!53828416!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_16,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 523 invoked from network); 24 Feb 2012 10:12:27 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-12.tower-27.messagelabs.com with SMTP;
	24 Feb 2012 10:12:27 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 4C926D347C1;
	Fri, 24 Feb 2012 11:13:08 +0100 (CET)
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 62eDO21ZKctc; Fri, 24 Feb 2012 11:13:01 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id E2DC2D3471A;
	Fri, 24 Feb 2012 11:13:00 +0100 (CET)
To: xen-users@lists.xen.org
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
Date: Fri, 24 Feb 2012 11:12:59 +0100
MIME-Version: 1.0
Message-Id: <201202241112.59801.tobias.geiger@vido.info>
Cc: ray@aarden.us, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] GPU Pass Through Comment - DomU GPU
	Performance Regression after Reboot - Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi!

after the first disappointment about the FirePro-Driver not solving my issue, i 
fiddled around with this problem and finally found a solution which solves the 
Performance-Regression i'm experiencing in my setup;

The Problem is: GPU Performance degrades to about 10% after a DomU Reboot (GPU 
is ATI, but this also happend with a NVIDIA iirc , so no ATI-specific Problem).

The Workaround: too easy :) Simply "Eject" the GPU after Windows has booted - 
the screen goes black, it re-initializes the Card and re-attaches after a few 
seconds. From then on Performance is back to normal.
Ejecting is done via the little Device-Manager Icon in the Taskbar (this one: 
http://www.technipages.com/wp-content/uploads/2011/01/Windows-7-Remove-
Hardware-option.pngwww.technipages.com/wp-content/uploads/2011/01/Windows-7-
Remove-Hardware-option.png )

To Automate this, i used a little tool called "DevEject" from heise.de - it's 
"OpenSource" Licensed and works even in Win7-64:
ftp://ftp.heise.de/pub/ct/listings/0316-208.zip
There may be other Tools/Scripting solutions via WSH/Powershell/VBS/CMD/...

Greetings!
Tobias

Am Donnerstag, 23. Februar 2012, 01:39:08 schrieb ray@aarden.us:
> After reading many posts on GPU pass through failing on reboot of the domU, 
>I questioned AMD and they responded with:
> 
>This is the known and documented issue with hypervisor - Resolved issues 
>(release notes) with driver  8.83.5.4 and above - May see system hang on 
>restart with some hypervisors.  Consider using a more recent firepro driver at 
>support.amd.com. 
>
>
>ray

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:17:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sCy-0003dR-49; Fri, 24 Feb 2012 10:17:00 +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 1S0sCw-0003co-CM
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:16:58 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330078574!53829288!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16603 invoked from network); 24 Feb 2012 10:16:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325480400"; d="scan'208";a="22409495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 05:16:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 05:16:55 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0sCs-0008AW-Qu;
	Fri, 24 Feb 2012 10:16:55 +0000
Message-ID: <4F476396.60802@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:16:54 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <1330078323.5034.73.camel@Abyss>
In-Reply-To: <1330078323.5034.73.camel@Abyss>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/02/12 10:12, Dario Faggioli wrote:
> Hi guys,
>
> As some of you know I'm working on putting some kind of NUMA-aware
> placement of the various VMs within Xen. This means I'm investigating
> deeply how memory allocation works, which isn't an easy task for me (I
> started completely from scratch), so forgive me if I say something
> wrong! :-P
>
> The status is I'm dealing for a while with a "design issue" I'd be very
> glad to discuss with someone, as I'm not sure which path to go for...
>
> To keep it short, what I need is a place --ideally during VM creation--
> where I can check how much memory a VM wants against how much memory is
> available in the various NUMA-nodes, and use this as the basis of my
> decision. The question is, where is this place?
>
> I traced memory related calls (e.g., for HVMs) from libxl__build_hvm to
> xc_hvm_build_target_mem to setup_guest to xc_domain_populate_physmap and
> alloc_domheap_pages. The last twos have been my target for a while, but
> I'm not so sure they would be the right choice, mainly because both of
> them are called for allocating _only_part_ of the VM's memory, i.e.,
> some extents of it at each call (am I right?).
>
> Basically, given alloc_domheap_pages uses d->node_affinity for deciding
> from which node(s) to actually take memory from, I was planning to
> either use the same mask or build a new one with similar purposes, the
> problem being _where_ to populate it with the proper nodes.
> I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
> although I think it's too early, and I'd end up guessing wrt a lot of
> aspects... But considering xm/xend was doing the same even earlier (at
> least I think)...
So the first question is, where should the decision about NUMA placement 
be made, and the second is how that level should implement it.

Doing it at the libxc level I think is not right.  It seems to me we 
have two options:
* Have libxl do the NUMA placement on behalf of the toolstack.  In that 
case, the libxl_domain_create_new function should look at the available 
memory, the NUMA layout, &c, and then set d->node_affinity before 
calling xc_hvm_build.
* Have the toolstack do it.  In this case, you'd be modifying xl to set 
d->node_affinity before calling libxl's domain creation function.

Do those options work?  Let me know if I've misunderstood anything.

Any thoughts one way or the other from anyone?

I'd be tempted to have it be optional -- you can set "numa=auto" and the 
domain creation function will do the simple thing; or you can set 
"numa=manual" and have the toolstack / config file set the nodes 
manually.  That would translate pretty well to config files as well -- 
more "set the knobs" administrators could set the numa layout in the 
config file manually if they wanted.

Thoughts?

  -George

>
> Sorry fro writing so much... Any help/ideas you feel comfortable with
> sharing would be very appreciated! :-)
>
> Thanks a lot and regards,
> Dario
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:17:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:17:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sCy-0003dR-49; Fri, 24 Feb 2012 10:17:00 +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 1S0sCw-0003co-CM
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:16:58 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330078574!53829288!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16603 invoked from network); 24 Feb 2012 10:16:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325480400"; d="scan'208";a="22409495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 05:16:55 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 05:16:55 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1S0sCs-0008AW-Qu;
	Fri, 24 Feb 2012 10:16:55 +0000
Message-ID: <4F476396.60802@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:16:54 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <1330078323.5034.73.camel@Abyss>
In-Reply-To: <1330078323.5034.73.camel@Abyss>
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/02/12 10:12, Dario Faggioli wrote:
> Hi guys,
>
> As some of you know I'm working on putting some kind of NUMA-aware
> placement of the various VMs within Xen. This means I'm investigating
> deeply how memory allocation works, which isn't an easy task for me (I
> started completely from scratch), so forgive me if I say something
> wrong! :-P
>
> The status is I'm dealing for a while with a "design issue" I'd be very
> glad to discuss with someone, as I'm not sure which path to go for...
>
> To keep it short, what I need is a place --ideally during VM creation--
> where I can check how much memory a VM wants against how much memory is
> available in the various NUMA-nodes, and use this as the basis of my
> decision. The question is, where is this place?
>
> I traced memory related calls (e.g., for HVMs) from libxl__build_hvm to
> xc_hvm_build_target_mem to setup_guest to xc_domain_populate_physmap and
> alloc_domheap_pages. The last twos have been my target for a while, but
> I'm not so sure they would be the right choice, mainly because both of
> them are called for allocating _only_part_ of the VM's memory, i.e.,
> some extents of it at each call (am I right?).
>
> Basically, given alloc_domheap_pages uses d->node_affinity for deciding
> from which node(s) to actually take memory from, I was planning to
> either use the same mask or build a new one with similar purposes, the
> problem being _where_ to populate it with the proper nodes.
> I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
> although I think it's too early, and I'd end up guessing wrt a lot of
> aspects... But considering xm/xend was doing the same even earlier (at
> least I think)...
So the first question is, where should the decision about NUMA placement 
be made, and the second is how that level should implement it.

Doing it at the libxc level I think is not right.  It seems to me we 
have two options:
* Have libxl do the NUMA placement on behalf of the toolstack.  In that 
case, the libxl_domain_create_new function should look at the available 
memory, the NUMA layout, &c, and then set d->node_affinity before 
calling xc_hvm_build.
* Have the toolstack do it.  In this case, you'd be modifying xl to set 
d->node_affinity before calling libxl's domain creation function.

Do those options work?  Let me know if I've misunderstood anything.

Any thoughts one way or the other from anyone?

I'd be tempted to have it be optional -- you can set "numa=auto" and the 
domain creation function will do the simple thing; or you can set 
"numa=manual" and have the toolstack / config file set the nodes 
manually.  That would translate pretty well to config files as well -- 
more "set the knobs" administrators could set the numa layout in the 
config file manually if they wanted.

Thoughts?

  -George

>
> Sorry fro writing so much... Any help/ideas you feel comfortable with
> sharing would be very appreciated! :-)
>
> Thanks a lot and regards,
> Dario
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sEB-0003sB-KH; Fri, 24 Feb 2012 10:18:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sEA-0003rN-9u
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:18:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1330078687!16181494!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 592 invoked from network); 24 Feb 2012 10:18:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:18:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:18:06 +0000
Message-Id: <4F4771EE020000780007496D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:18:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
In-Reply-To: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.02.12 at 20:59, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> @@ -300,6 +301,87 @@ static unsigned long init_node_heap(int 
>      return needed;
>  }
>  
> +/* Default to 64 MiB */
> +#define DEFAULT_LOW_MEM_VIRQ_MIB    64
> +#define MAX_LOW_MEM_VIRQ_MIB        1024
> +
> +static unsigned long long __read_mostly opt_low_mem_virq = 
> +                                        (DEFAULT_LOW_MEM_VIRQ_MIB << 20);
> +size_param("low_mem_virq_limit", opt_low_mem_virq);
> +
> +/* Thresholds to control hysteresis. In pages */
> +/* When memory grows above this threshold, reset hysteresis.
> + * -1 initially to not reset until at least one virq issued. */
> +static unsigned long low_mem_virq_high      = -1UL;
> +/* Threshold at which we issue virq */
> +static unsigned long low_mem_virq_th        = 0;
> +/* Original threshold after all checks completed */
> +static unsigned long low_mem_virq_orig      = 0;
> +/* Order for current threshold */
> +static unsigned int  low_mem_virq_th_order  = 0;
> +
> +/* Perform bootstrapping checks and set bounds */
> +static void setup_low_mem_virq(void)

__init

> +{
> +    unsigned int order;
> +    unsigned long long threshold;
> +
> +    /* Dom0 has already been allocated by now. So check we won't 
> +     * be complaining immediately with whatever's left of the heap. */
> +    threshold = min(opt_low_mem_virq, (unsigned long long)
> +                          (total_avail_pages << PAGE_SHIFT));

The cast needs to be on total_avail_pages, not the result of the
shift. Also, unsigned long long is the wrong type (paddr_t was
invented for this very purpose).

Further, the initial threshold should clearly be *below* the currently
available amount (e.g. at half of it).

> +
> +    /* Then, cap to some predefined maximum */
> +    threshold = min(threshold, (unsigned long long)
> +                          (MAX_LOW_MEM_VIRQ_MIB << 20));

Same here wrt the cast.

> +
> +    /* Threshold bytes -> pages */
> +    low_mem_virq_th = threshold >> PAGE_SHIFT;
> +
> +    /* Next, round the threshold down to the next order */
> +    order = get_order_from_pages(low_mem_virq_th);
> +    if ( (1 << order) > low_mem_virq_th ) 
> +        order--;
> +
> +    /* Set bounds, ready to go */
> +    low_mem_virq_th = low_mem_virq_orig = 1 << order;

1UL << ...

> +    low_mem_virq_th_order = order;
> +
> +    printk("Current low memory virq threshold set at 0x%lx pages.\n",

"Initial ..."

> +            low_mem_virq_th);
> +}
> +
> +static void check_low_mem_virq(void)
> +{
> +    if ( total_avail_pages <= low_mem_virq_th )
> +    {
> +        send_global_virq(VIRQ_ENOMEM);
> +
> +        /* Update thresholds. Next warning will be when we drop below
> +         * next order. However, we wait until we grow beyond one
> +         * order above us to complain again at the current order */
> +        low_mem_virq_high   = 1 << (low_mem_virq_th_order + 1);

1UL << ...

> +        if ( low_mem_virq_th_order > 0 )
> +            low_mem_virq_th_order--;
> +        low_mem_virq_th     = 1 << low_mem_virq_th_order;

Same here.

> +        return;
> +    }
> +
> +    if ( total_avail_pages >= low_mem_virq_high )
> +    {
> +        /* Reset hysteresis. Bring threshold up one order.
> +         * If we are back where originally set, set high
> +         * threshold to -1 to avoid further growth of 
> +         * virq threshold. */
> +        low_mem_virq_th_order++;
> +        low_mem_virq_th = 1 << low_mem_virq_th_order;

And here.

> +        if ( low_mem_virq_th == low_mem_virq_orig )
> +            low_mem_virq_high = -1UL;
> +        else
> +            low_mem_virq_high = 1 << (low_mem_virq_th_order + 2);

And here.

> +    }
> +}
> +
>  /* Allocate 2^@order contiguous pages. */
>  static struct page_info *alloc_heap_pages(
>      unsigned int zone_lo, unsigned int zone_hi,
> @@ -420,6 +502,8 @@ static struct page_info *alloc_heap_page
>      total_avail_pages -= request;
>      ASSERT(total_avail_pages >= 0);
>  
> +    check_low_mem_virq();
> +
>      if ( d != NULL )
>          d->last_alloc_node = node;
>  
> @@ -1022,6 +1106,10 @@ void __init scrub_heap_pages(void)
>      }
>  
>      printk("done.\n");
> +
> +    /* Now that the heap is initialized, run checks and set bounds
> +     * for the low mem virq algorithm. */
> +    setup_low_mem_virq();
>  }
>  
>  
> diff -r dd69d9b1aee9 -r da02cb8485de xen/include/public/xen.h
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #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) Dangerously low on heap memory       */

Either the default threshold ought to be *much* lower (say 64k), or
the "dangerously" here is completely misleading.

>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16

Given that this new vIRQ ought to be handled in user space, do you
have an implementation ready to contribute as well?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sEB-0003sB-KH; Fri, 24 Feb 2012 10:18:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sEA-0003rN-9u
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:18:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1330078687!16181494!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 592 invoked from network); 24 Feb 2012 10:18:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:18:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:18:06 +0000
Message-Id: <4F4771EE020000780007496D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:18:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
In-Reply-To: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.02.12 at 20:59, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> @@ -300,6 +301,87 @@ static unsigned long init_node_heap(int 
>      return needed;
>  }
>  
> +/* Default to 64 MiB */
> +#define DEFAULT_LOW_MEM_VIRQ_MIB    64
> +#define MAX_LOW_MEM_VIRQ_MIB        1024
> +
> +static unsigned long long __read_mostly opt_low_mem_virq = 
> +                                        (DEFAULT_LOW_MEM_VIRQ_MIB << 20);
> +size_param("low_mem_virq_limit", opt_low_mem_virq);
> +
> +/* Thresholds to control hysteresis. In pages */
> +/* When memory grows above this threshold, reset hysteresis.
> + * -1 initially to not reset until at least one virq issued. */
> +static unsigned long low_mem_virq_high      = -1UL;
> +/* Threshold at which we issue virq */
> +static unsigned long low_mem_virq_th        = 0;
> +/* Original threshold after all checks completed */
> +static unsigned long low_mem_virq_orig      = 0;
> +/* Order for current threshold */
> +static unsigned int  low_mem_virq_th_order  = 0;
> +
> +/* Perform bootstrapping checks and set bounds */
> +static void setup_low_mem_virq(void)

__init

> +{
> +    unsigned int order;
> +    unsigned long long threshold;
> +
> +    /* Dom0 has already been allocated by now. So check we won't 
> +     * be complaining immediately with whatever's left of the heap. */
> +    threshold = min(opt_low_mem_virq, (unsigned long long)
> +                          (total_avail_pages << PAGE_SHIFT));

The cast needs to be on total_avail_pages, not the result of the
shift. Also, unsigned long long is the wrong type (paddr_t was
invented for this very purpose).

Further, the initial threshold should clearly be *below* the currently
available amount (e.g. at half of it).

> +
> +    /* Then, cap to some predefined maximum */
> +    threshold = min(threshold, (unsigned long long)
> +                          (MAX_LOW_MEM_VIRQ_MIB << 20));

Same here wrt the cast.

> +
> +    /* Threshold bytes -> pages */
> +    low_mem_virq_th = threshold >> PAGE_SHIFT;
> +
> +    /* Next, round the threshold down to the next order */
> +    order = get_order_from_pages(low_mem_virq_th);
> +    if ( (1 << order) > low_mem_virq_th ) 
> +        order--;
> +
> +    /* Set bounds, ready to go */
> +    low_mem_virq_th = low_mem_virq_orig = 1 << order;

1UL << ...

> +    low_mem_virq_th_order = order;
> +
> +    printk("Current low memory virq threshold set at 0x%lx pages.\n",

"Initial ..."

> +            low_mem_virq_th);
> +}
> +
> +static void check_low_mem_virq(void)
> +{
> +    if ( total_avail_pages <= low_mem_virq_th )
> +    {
> +        send_global_virq(VIRQ_ENOMEM);
> +
> +        /* Update thresholds. Next warning will be when we drop below
> +         * next order. However, we wait until we grow beyond one
> +         * order above us to complain again at the current order */
> +        low_mem_virq_high   = 1 << (low_mem_virq_th_order + 1);

1UL << ...

> +        if ( low_mem_virq_th_order > 0 )
> +            low_mem_virq_th_order--;
> +        low_mem_virq_th     = 1 << low_mem_virq_th_order;

Same here.

> +        return;
> +    }
> +
> +    if ( total_avail_pages >= low_mem_virq_high )
> +    {
> +        /* Reset hysteresis. Bring threshold up one order.
> +         * If we are back where originally set, set high
> +         * threshold to -1 to avoid further growth of 
> +         * virq threshold. */
> +        low_mem_virq_th_order++;
> +        low_mem_virq_th = 1 << low_mem_virq_th_order;

And here.

> +        if ( low_mem_virq_th == low_mem_virq_orig )
> +            low_mem_virq_high = -1UL;
> +        else
> +            low_mem_virq_high = 1 << (low_mem_virq_th_order + 2);

And here.

> +    }
> +}
> +
>  /* Allocate 2^@order contiguous pages. */
>  static struct page_info *alloc_heap_pages(
>      unsigned int zone_lo, unsigned int zone_hi,
> @@ -420,6 +502,8 @@ static struct page_info *alloc_heap_page
>      total_avail_pages -= request;
>      ASSERT(total_avail_pages >= 0);
>  
> +    check_low_mem_virq();
> +
>      if ( d != NULL )
>          d->last_alloc_node = node;
>  
> @@ -1022,6 +1106,10 @@ void __init scrub_heap_pages(void)
>      }
>  
>      printk("done.\n");
> +
> +    /* Now that the heap is initialized, run checks and set bounds
> +     * for the low mem virq algorithm. */
> +    setup_low_mem_virq();
>  }
>  
>  
> diff -r dd69d9b1aee9 -r da02cb8485de xen/include/public/xen.h
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #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) Dangerously low on heap memory       */

Either the default threshold ought to be *much* lower (say 64k), or
the "dangerously" here is completely misleading.

>  
>  /* Architecture-specific VIRQ definitions. */
>  #define VIRQ_ARCH_0    16

Given that this new vIRQ ought to be handled in user space, do you
have an implementation ready to contribute as well?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:22:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sIQ-0004AF-9x; Fri, 24 Feb 2012 10:22:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sIO-0004A4-6q
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:22:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330078950!14707212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6894 invoked from network); 24 Feb 2012 10:22:30 -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;
	24 Feb 2012 10:22:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10914908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:22:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:22:29 +0000
Message-ID: <1330078948.8557.158.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:22:28 +0000
In-Reply-To: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Allocate the shared_info page at domain creation.
> 
> Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/domain.c     |    8 ++++
>  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/p2m.c        |   15 ++++++-
>  xen/include/asm-arm/mm.h  |    4 ++
>  xen/include/asm-arm/p2m.h |    2 +
>  5 files changed, 122 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0b55934..0ee96b9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    rc = -ENOMEM;
> +    if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> +        goto fail;
> +
> +    clear_page(d->shared_info);
> +    share_xen_page_with_guest(
> +            virt_to_page(d->shared_info), d, XENSHARE_writable);
> +
>      d->max_vcpus = 8;
>  
>      if ( (rc = domain_vgic_init(d)) != 0 )
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index a0f39eb..0fe0398 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -25,8 +25,11 @@
>  #include <xen/mm.h>
>  #include <xen/preempt.h>
>  #include <xen/errno.h>
> +#include <xen/guest_access.h>
>  #include <asm/page.h>
>  #include <asm/current.h>
> +#include <public/memory.h>
> +#include <xen/sched.h>
>  
>  struct domain *dom_xen, *dom_io;
>  
> @@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
>  {
>  }
>  
> -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
>  {
> +    ASSERT(0);
>      return -ENOSYS;
>  }
>  
> -int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
> +void share_xen_page_with_guest(struct page_info *page,
> +                          struct domain *d, int readonly)
>  {
> -    ASSERT(0);
> -    return -ENOSYS;
> +    if ( page_get_owner(page) == d )
> +        return;
> +
> +    spin_lock(&d->page_alloc_lock);
> +
> +    /* The incremented type count pins as writable or read-only. */
> +    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
> +    page->u.inuse.type_info |= PGT_validated | 1;
> +
> +    page_set_owner(page, d);
> +    wmb(); /* install valid domain ptr before updating refcnt. */
> +    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
> +
> +    /* Only add to the allocation list if the domain isn't dying. */
> +    if ( !d->is_dying )
> +    {
> +        page->count_info |= PGC_allocated | 1;
> +        if ( unlikely(d->xenheap_pages++ == 0) )
> +            get_knownalive_domain(d);
> +        page_list_add_tail(page, &d->xenpage_list);
> +    }
> +
> +    spin_unlock(&d->page_alloc_lock);
> +}
> +
> +static int xenmem_add_to_physmap_once(
> +    struct domain *d,
> +    const struct xen_add_to_physmap *xatp)
> +{
> +    unsigned long mfn = 0;
> +    int rc;
> +
> +    switch ( xatp->space )
> +    {
> +        case XENMAPSPACE_shared_info:
> +            if ( xatp->idx == 0 )
> +                mfn = virt_to_mfn(d->shared_info);
> +            break;
> +        default:
> +            return -ENOSYS;
> +    }
> +
> +    domain_lock(d);
> +
> +    /* Map at new location. */
> +    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
> +
> +    domain_unlock(d);
> +
> +    return rc;
> +}
> +
> +static int xenmem_add_to_physmap(struct domain *d,
> +                                 struct xen_add_to_physmap *xatp)
> +{
> +    return xenmem_add_to_physmap_once(d, xatp);
>  }
>  
> +long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +{
> +    int rc;
> +
> +    switch ( op )
> +    {
> +    case XENMEM_add_to_physmap:
> +    {
> +        struct xen_add_to_physmap xatp;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap(d, &xatp);
> +
> +        rcu_unlock_domain(d);
> +
> +        return rc;
> +    }
> +
> +    default:
> +        return -ENOSYS;
> +    }
> +
> +    return 0;
> +}
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 14614fd..1a00a50 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
>          }
>          /* else: third already valid */
>  
> -        BUG_ON(third[third_table_offset(addr)].p2m.valid);
> +        if ( third[third_table_offset(addr)].p2m.valid )
> +        {
> +            /* p2m entry already present */
> +            free_domheap_page(
> +                    mfn_to_page(third[third_table_offset(addr)].p2m.base));
> +        }
>  
>          /* Allocate a new RAM page and attach */
>          if (alloc)
> @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
>      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
>  }
>  
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +        unsigned long mfn)
> +{
> +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> +                              (gpfn + 1) << PAGE_SHIFT,
> +                              mfn << PAGE_SHIFT);
> +}
> +
>  int p2m_alloc_table(struct domain *d)
>  {
>      struct p2m_domain *p2m = &d->arch.p2m;
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index bfc0f76..56ab9415 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -78,6 +78,10 @@ struct page_info
>  #define _PGT_pinned       PG_shift(5)
>  #define PGT_pinned        PG_mask(1, 5)
>  
> + /* Has this page been validated for use as its current type? */
> +#define _PGT_validated    PG_shift(6)
> +#define PGT_validated     PG_mask(1, 6)
> +
>   /* Count of uses of this frame as its current type. */
>  #define PGT_count_width   PG_shift(9)
>  #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index aec52f7..c0f2995 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>   * address maddr. */
>  int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
>                       paddr_t end_gaddr, paddr_t maddr);
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +        unsigned long mfn);
>  
>  unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:22:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sIQ-0004AF-9x; Fri, 24 Feb 2012 10:22:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sIO-0004A4-6q
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:22:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330078950!14707212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6894 invoked from network); 24 Feb 2012 10:22:30 -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;
	24 Feb 2012 10:22:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10914908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:22:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:22:29 +0000
Message-ID: <1330078948.8557.158.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:22:28 +0000
In-Reply-To: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Allocate the shared_info page at domain creation.
> 
> Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/domain.c     |    8 ++++
>  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/p2m.c        |   15 ++++++-
>  xen/include/asm-arm/mm.h  |    4 ++
>  xen/include/asm-arm/p2m.h |    2 +
>  5 files changed, 122 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0b55934..0ee96b9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    rc = -ENOMEM;
> +    if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> +        goto fail;
> +
> +    clear_page(d->shared_info);
> +    share_xen_page_with_guest(
> +            virt_to_page(d->shared_info), d, XENSHARE_writable);
> +
>      d->max_vcpus = 8;
>  
>      if ( (rc = domain_vgic_init(d)) != 0 )
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index a0f39eb..0fe0398 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -25,8 +25,11 @@
>  #include <xen/mm.h>
>  #include <xen/preempt.h>
>  #include <xen/errno.h>
> +#include <xen/guest_access.h>
>  #include <asm/page.h>
>  #include <asm/current.h>
> +#include <public/memory.h>
> +#include <xen/sched.h>
>  
>  struct domain *dom_xen, *dom_io;
>  
> @@ -323,17 +326,104 @@ void arch_dump_shared_mem_info(void)
>  {
>  }
>  
> -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
>  {
> +    ASSERT(0);
>      return -ENOSYS;
>  }
>  
> -int donate_page(struct domain *d, struct page_info *page, unsigned int memflags)
> +void share_xen_page_with_guest(struct page_info *page,
> +                          struct domain *d, int readonly)
>  {
> -    ASSERT(0);
> -    return -ENOSYS;
> +    if ( page_get_owner(page) == d )
> +        return;
> +
> +    spin_lock(&d->page_alloc_lock);
> +
> +    /* The incremented type count pins as writable or read-only. */
> +    page->u.inuse.type_info  = (readonly ? PGT_none : PGT_writable_page);
> +    page->u.inuse.type_info |= PGT_validated | 1;
> +
> +    page_set_owner(page, d);
> +    wmb(); /* install valid domain ptr before updating refcnt. */
> +    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
> +
> +    /* Only add to the allocation list if the domain isn't dying. */
> +    if ( !d->is_dying )
> +    {
> +        page->count_info |= PGC_allocated | 1;
> +        if ( unlikely(d->xenheap_pages++ == 0) )
> +            get_knownalive_domain(d);
> +        page_list_add_tail(page, &d->xenpage_list);
> +    }
> +
> +    spin_unlock(&d->page_alloc_lock);
> +}
> +
> +static int xenmem_add_to_physmap_once(
> +    struct domain *d,
> +    const struct xen_add_to_physmap *xatp)
> +{
> +    unsigned long mfn = 0;
> +    int rc;
> +
> +    switch ( xatp->space )
> +    {
> +        case XENMAPSPACE_shared_info:
> +            if ( xatp->idx == 0 )
> +                mfn = virt_to_mfn(d->shared_info);
> +            break;
> +        default:
> +            return -ENOSYS;
> +    }
> +
> +    domain_lock(d);
> +
> +    /* Map at new location. */
> +    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
> +
> +    domain_unlock(d);
> +
> +    return rc;
> +}
> +
> +static int xenmem_add_to_physmap(struct domain *d,
> +                                 struct xen_add_to_physmap *xatp)
> +{
> +    return xenmem_add_to_physmap_once(d, xatp);
>  }
>  
> +long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> +{
> +    int rc;
> +
> +    switch ( op )
> +    {
> +    case XENMEM_add_to_physmap:
> +    {
> +        struct xen_add_to_physmap xatp;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap(d, &xatp);
> +
> +        rcu_unlock_domain(d);
> +
> +        return rc;
> +    }
> +
> +    default:
> +        return -ENOSYS;
> +    }
> +
> +    return 0;
> +}
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 14614fd..1a00a50 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -118,7 +118,12 @@ static int create_p2m_entries(struct domain *d,
>          }
>          /* else: third already valid */
>  
> -        BUG_ON(third[third_table_offset(addr)].p2m.valid);
> +        if ( third[third_table_offset(addr)].p2m.valid )
> +        {
> +            /* p2m entry already present */
> +            free_domheap_page(
> +                    mfn_to_page(third[third_table_offset(addr)].p2m.base));
> +        }
>  
>          /* Allocate a new RAM page and attach */
>          if (alloc)
> @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
>      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
>  }
>  
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +        unsigned long mfn)
> +{
> +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> +                              (gpfn + 1) << PAGE_SHIFT,
> +                              mfn << PAGE_SHIFT);
> +}
> +
>  int p2m_alloc_table(struct domain *d)
>  {
>      struct p2m_domain *p2m = &d->arch.p2m;
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index bfc0f76..56ab9415 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -78,6 +78,10 @@ struct page_info
>  #define _PGT_pinned       PG_shift(5)
>  #define PGT_pinned        PG_mask(1, 5)
>  
> + /* Has this page been validated for use as its current type? */
> +#define _PGT_validated    PG_shift(6)
> +#define PGT_validated     PG_mask(1, 6)
> +
>   /* Count of uses of this frame as its current type. */
>  #define PGT_count_width   PG_shift(9)
>  #define PGT_count_mask    ((1UL<<PGT_count_width)-1)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index aec52f7..c0f2995 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -39,6 +39,8 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>   * address maddr. */
>  int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
>                       paddr_t end_gaddr, paddr_t maddr);
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +        unsigned long mfn);
>  
>  unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:24:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sJZ-0004H4-TP; Fri, 24 Feb 2012 10:23:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sJY-0004Gk-Fz
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:23:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330078890!50096619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30388 invoked from network); 24 Feb 2012 10:21:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:21:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:23:46 +0000
Message-Id: <4F47733E020000780007497D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:23:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> This module (processor-passthru)  collects the information that the cpufreq
> drivers and the ACPI processor code save in the 'struct acpi_processor' and
> then uploads it to the hypervisor.

Thus looks conceptually wrong to me - there shouldn't be a need for a
CPUFreq driver to be loaded in Dom0 (or your module should masquerade
as the one and only suitable one).

> On the hypervisor side, it requires this patch on AMD:
> # HG changeset patch
> # Parent aea8cfac8cf1afe397f2e1d422a852008d8a83fe
> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> 
> The restriction to read and write the AMD power management MSRs is gated if 
> the
> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> relax this restriction and allow the privileged domain to read the MSRs
> (but not write). This allows the priviliged domain to harvest the power
> management information (ACPI _PSS states) and send it to the hypervisor.

Why would accessing these MSRs be necessary here, when it isn't
for non-pvops? Perhaps only because you want a CPUFreq driver
loaded?

Jan

> This patch works fine with older classic dom0 (2.6.32) and with
> AMD K7 and K8 boxes.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> diff -r aea8cfac8cf1 xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Thu Feb 23 13:23:02 2012 -0500
> +++ b/xen/arch/x86/traps.c	Thu Feb 23 13:29:00 2012 -0500
> @@ -2484,7 +2484,7 @@ static int emulate_privileged_op(struct 
>          case MSR_K8_PSTATE7:
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
>                  goto fail;
> -            if ( !is_cpufreq_controller(v->domain) )
> +            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
>              {
>                  regs->eax = regs->edx = 0;
>                  break;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:24:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sJZ-0004H4-TP; Fri, 24 Feb 2012 10:23:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sJY-0004Gk-Fz
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:23:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330078890!50096619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30388 invoked from network); 24 Feb 2012 10:21:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:21:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:23:46 +0000
Message-Id: <4F47733E020000780007497D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:23:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> This module (processor-passthru)  collects the information that the cpufreq
> drivers and the ACPI processor code save in the 'struct acpi_processor' and
> then uploads it to the hypervisor.

Thus looks conceptually wrong to me - there shouldn't be a need for a
CPUFreq driver to be loaded in Dom0 (or your module should masquerade
as the one and only suitable one).

> On the hypervisor side, it requires this patch on AMD:
> # HG changeset patch
> # Parent aea8cfac8cf1afe397f2e1d422a852008d8a83fe
> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> 
> The restriction to read and write the AMD power management MSRs is gated if 
> the
> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> relax this restriction and allow the privileged domain to read the MSRs
> (but not write). This allows the priviliged domain to harvest the power
> management information (ACPI _PSS states) and send it to the hypervisor.

Why would accessing these MSRs be necessary here, when it isn't
for non-pvops? Perhaps only because you want a CPUFreq driver
loaded?

Jan

> This patch works fine with older classic dom0 (2.6.32) and with
> AMD K7 and K8 boxes.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> diff -r aea8cfac8cf1 xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Thu Feb 23 13:23:02 2012 -0500
> +++ b/xen/arch/x86/traps.c	Thu Feb 23 13:29:00 2012 -0500
> @@ -2484,7 +2484,7 @@ static int emulate_privileged_op(struct 
>          case MSR_K8_PSTATE7:
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
>                  goto fail;
> -            if ( !is_cpufreq_controller(v->domain) )
> +            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
>              {
>                  regs->eax = regs->edx = 0;
>                  break;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sRq-0004Yj-1C; Fri, 24 Feb 2012 10:32:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sRo-0004Ye-3o
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:32:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330079492!61514311!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10236 invoked from network); 24 Feb 2012 10:31:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:31:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:32:17 +0000
Message-Id: <4F4775410200007800074992@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:32:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and
 MWAIT_LEAF if hypervisor OKs 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 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> For the hypervisor to take advantage of the MWAIT support it needs
> to extract from the ACPI _CST the register address. But the
> hypervisor does not have the support to parse DSDT so it relies on
> the initial domain (dom0) to parse the ACPI Power Management information
> and push it up to the hypervisor. The pushing of the data is done
> by the processor_harveset_xen module which parses the information that
> the ACPI parser has graciously exposed in 'struct acpi_processor'.
> 
> For the ACPI parser to also expose the Cx states for MWAIT, we need
> to expose the MWAIT capability (leaf 1). Furthermore we also need to
> expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
> function.
> 
> The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
> operations, but it can't do it since it needs to be backwards compatible.
> Instead we choose to use the native CPUID to figure out if the MWAIT
> capability exists and use the XEN_SET_PDC query hypercall to figure out
> if the hypervisor wants us to expose the MWAIT_LEAF capability or not.
> 
> Note: The XEN_SET_PDC query was implemented in c/s 23783:
> "ACPI: add _PDC input override mechanism".
> 
> With this in place, instead of
>  C3 ACPI IOPORT 415
> we get now
>  C3:ACPI FFH INTEL MWAIT 0x20
> 
> Note: The cpu_idle which would be calling the mwait variants for idling
> never gets set b/c we set the default pm_idle to be the hypercall variant.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/enlighten.c         |   92 
> +++++++++++++++++++++++++++++++++++++-
>  include/xen/interface/platform.h |    4 +-
>  2 files changed, 94 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 12eb07b..4c82936 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -62,6 +62,14 @@
>  #include <asm/reboot.h>
>  #include <asm/stackprotector.h>
>  #include <asm/hypervisor.h>
> +#include <asm/mwait.h>
> +
> +#ifdef CONFIG_ACPI
> +#include <asm/acpi.h>
> +#include <acpi/pdc_intel.h>
> +#include <acpi/processor.h>
> +#include <xen/interface/platform.h>
> +#endif
>  
>  #include "xen-ops.h"
>  #include "mmu.h"
> @@ -200,13 +208,17 @@ static void __init xen_banner(void)
>  static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
>  static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
>  
> +static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask;
> +static __read_mostly unsigned int cpuid_leaf5_ecx_val;
> +static __read_mostly unsigned int cpuid_leaf5_edx_val;
> +
>  static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  		      unsigned int *cx, unsigned int *dx)
>  {
>  	unsigned maskebx = ~0;
>  	unsigned maskecx = ~0;
>  	unsigned maskedx = ~0;
> -
> +	unsigned setecx = 0;
>  	/*
>  	 * Mask out inconvenient features, to try and disable as many
>  	 * unsupported kernel subsystems as possible.
> @@ -214,9 +226,18 @@ static void xen_cpuid(unsigned int *ax, unsigned int 
> *bx,
>  	switch (*ax) {
>  	case 1:
>  		maskecx = cpuid_leaf1_ecx_mask;
> +		setecx = cpuid_leaf1_ecx_set_mask;
>  		maskedx = cpuid_leaf1_edx_mask;
>  		break;
>  
> +	case CPUID_MWAIT_LEAF:
> +		/* Synthesize the values.. */
> +		*ax = 0;
> +		*bx = 0;
> +		*cx = cpuid_leaf5_ecx_val;
> +		*dx = cpuid_leaf5_edx_val;
> +		return;
> +
>  	case 0xb:
>  		/* Suppress extended topology stuff */
>  		maskebx = 0;
> @@ -232,9 +253,75 @@ static void xen_cpuid(unsigned int *ax, unsigned int 
> *bx,
>  
>  	*bx &= maskebx;
>  	*cx &= maskecx;
> +	*cx |= setecx;
>  	*dx &= maskedx;
> +
>  }
>  
> +static bool __init xen_check_mwait(void)
> +{
> +#if CONFIG_ACPI

#ifdef

> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_set_processor_pminfo,
> +		.u.set_pminfo.id	= -1,
> +		.u.set_pminfo.type	= XEN_PM_PDC,
> +	};
> +	uint32_t buf[3];
> +	unsigned int ax, bx, cx, dx;
> +	unsigned int mwait_mask;
> +
> +	/* We need to determine whether it is OK to expose the MWAIT
> +	 * capability to the kernel to harvest deeper than C3 states from ACPI
> +	 * _CST using the processor_harvest_xen.c module. For this to work, we
> +	 * need to gather the MWAIT_LEAF values (which the cstate.c code
> +	 * checks against). The hypervisor won't expose the MWAIT flag because
> +	 * it would break backwards compatibility; so we will find out directly
> +	 * from the hardware and hypercall.
> +	 */
> +	if (!xen_initial_domain())
> +		return false;
> +
> +	ax = 1;
> +	cx = 0;
> +
> +	native_cpuid(&ax, &bx, &cx, &dx);
> +
> +	mwait_mask = (1 << (X86_FEATURE_EST % 32)) |
> +		     (1 << (X86_FEATURE_MWAIT % 32));
> +
> +	if ((cx & mwait_mask) != mwait_mask)
> +		return false;
> +
> +	/* We need to emulate the MWAIT_LEAF and for that we need both
> +	 * ecx and edx. The hypercall provides only partial information.
> +	 */
> +
> +	ax = CPUID_MWAIT_LEAF;
> +	bx = 0;
> +	cx = 0;
> +	dx = 0;
> +
> +	native_cpuid(&ax, &bx, &cx, &dx);
> +
> +	/* Ask the Hypervisor whether to clear ACPI_PDC_C_C2C3_FFH. If so,
> +	 * don't expose MWAIT_LEAF and let ACPI pick the IOPORT version of C3.
> +	 */
> +	buf[0] = ACPI_PDC_REVISION_ID;
> +	buf[1] = 1;
> +	buf[2] = (ACPI_PDC_C_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_SWSMP);
> +
> +	set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
> +
> +	if ((HYPERVISOR_dom0_op(&op) == 0) &&
> +	    (buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
> +		cpuid_leaf5_ecx_val = cx;
> +		cpuid_leaf5_edx_val = dx;
> +	}
> +	return true;
> +#else
> +	return false;
> +#endif
> +}
>  static void __init xen_init_cpuid_mask(void)
>  {
>  	unsigned int ax, bx, cx, dx;
> @@ -261,6 +348,9 @@ static void __init xen_init_cpuid_mask(void)
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
>  	if ((cx & xsave_mask) != xsave_mask)
>  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
> +
> +	if (xen_check_mwait())
> +		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
>  }
>  
>  static void xen_set_debugreg(int reg, unsigned long val)
> diff --git a/include/xen/interface/platform.h 
> b/include/xen/interface/platform.h
> index c168468..6220b98 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -200,7 +200,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>  #define XEN_PM_CX   0
>  #define XEN_PM_PX   1
>  #define XEN_PM_TX   2
> -
> +#define XEN_PM_PDC  3
>  /* Px sub info type */
>  #define XEN_PX_PCT   1
>  #define XEN_PX_PSS   2
> @@ -286,6 +286,7 @@ struct xen_processor_performance {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
>  
> +DEFINE_GUEST_HANDLE(uint32_t);

Do you really need to introduce (step by step) handles for all those
uintNN_t types in a way different from Xen's
(__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t))?

Looks good to me otherwise.

Jan

>  struct xenpf_set_processor_pminfo {
>  	/* IN variables */
>  	uint32_t id;    /* ACPI CPU ID */
> @@ -293,6 +294,7 @@ struct xenpf_set_processor_pminfo {
>  	union {
>  		struct xen_processor_power          power;/* Cx: _CST/_CSD */
>  		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
> +		GUEST_HANDLE(uint32_t)              pdc;
>  	};
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
> -- 
> 1.7.9.48.g85da4d



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sRq-0004Yj-1C; Fri, 24 Feb 2012 10:32:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sRo-0004Ye-3o
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:32:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330079492!61514311!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10236 invoked from network); 24 Feb 2012 10:31:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:31:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:32:17 +0000
Message-Id: <4F4775410200007800074992@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:32:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and
 MWAIT_LEAF if hypervisor OKs 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 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> For the hypervisor to take advantage of the MWAIT support it needs
> to extract from the ACPI _CST the register address. But the
> hypervisor does not have the support to parse DSDT so it relies on
> the initial domain (dom0) to parse the ACPI Power Management information
> and push it up to the hypervisor. The pushing of the data is done
> by the processor_harveset_xen module which parses the information that
> the ACPI parser has graciously exposed in 'struct acpi_processor'.
> 
> For the ACPI parser to also expose the Cx states for MWAIT, we need
> to expose the MWAIT capability (leaf 1). Furthermore we also need to
> expose the MWAIT_LEAF capability (leaf 5) for cstate.c to properly
> function.
> 
> The hypervisor could expose these flags when it traps the XEN_EMULATE_PREFIX
> operations, but it can't do it since it needs to be backwards compatible.
> Instead we choose to use the native CPUID to figure out if the MWAIT
> capability exists and use the XEN_SET_PDC query hypercall to figure out
> if the hypervisor wants us to expose the MWAIT_LEAF capability or not.
> 
> Note: The XEN_SET_PDC query was implemented in c/s 23783:
> "ACPI: add _PDC input override mechanism".
> 
> With this in place, instead of
>  C3 ACPI IOPORT 415
> we get now
>  C3:ACPI FFH INTEL MWAIT 0x20
> 
> Note: The cpu_idle which would be calling the mwait variants for idling
> never gets set b/c we set the default pm_idle to be the hypercall variant.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/enlighten.c         |   92 
> +++++++++++++++++++++++++++++++++++++-
>  include/xen/interface/platform.h |    4 +-
>  2 files changed, 94 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 12eb07b..4c82936 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -62,6 +62,14 @@
>  #include <asm/reboot.h>
>  #include <asm/stackprotector.h>
>  #include <asm/hypervisor.h>
> +#include <asm/mwait.h>
> +
> +#ifdef CONFIG_ACPI
> +#include <asm/acpi.h>
> +#include <acpi/pdc_intel.h>
> +#include <acpi/processor.h>
> +#include <xen/interface/platform.h>
> +#endif
>  
>  #include "xen-ops.h"
>  #include "mmu.h"
> @@ -200,13 +208,17 @@ static void __init xen_banner(void)
>  static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
>  static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
>  
> +static __read_mostly unsigned int cpuid_leaf1_ecx_set_mask;
> +static __read_mostly unsigned int cpuid_leaf5_ecx_val;
> +static __read_mostly unsigned int cpuid_leaf5_edx_val;
> +
>  static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  		      unsigned int *cx, unsigned int *dx)
>  {
>  	unsigned maskebx = ~0;
>  	unsigned maskecx = ~0;
>  	unsigned maskedx = ~0;
> -
> +	unsigned setecx = 0;
>  	/*
>  	 * Mask out inconvenient features, to try and disable as many
>  	 * unsupported kernel subsystems as possible.
> @@ -214,9 +226,18 @@ static void xen_cpuid(unsigned int *ax, unsigned int 
> *bx,
>  	switch (*ax) {
>  	case 1:
>  		maskecx = cpuid_leaf1_ecx_mask;
> +		setecx = cpuid_leaf1_ecx_set_mask;
>  		maskedx = cpuid_leaf1_edx_mask;
>  		break;
>  
> +	case CPUID_MWAIT_LEAF:
> +		/* Synthesize the values.. */
> +		*ax = 0;
> +		*bx = 0;
> +		*cx = cpuid_leaf5_ecx_val;
> +		*dx = cpuid_leaf5_edx_val;
> +		return;
> +
>  	case 0xb:
>  		/* Suppress extended topology stuff */
>  		maskebx = 0;
> @@ -232,9 +253,75 @@ static void xen_cpuid(unsigned int *ax, unsigned int 
> *bx,
>  
>  	*bx &= maskebx;
>  	*cx &= maskecx;
> +	*cx |= setecx;
>  	*dx &= maskedx;
> +
>  }
>  
> +static bool __init xen_check_mwait(void)
> +{
> +#if CONFIG_ACPI

#ifdef

> +	struct xen_platform_op op = {
> +		.cmd			= XENPF_set_processor_pminfo,
> +		.u.set_pminfo.id	= -1,
> +		.u.set_pminfo.type	= XEN_PM_PDC,
> +	};
> +	uint32_t buf[3];
> +	unsigned int ax, bx, cx, dx;
> +	unsigned int mwait_mask;
> +
> +	/* We need to determine whether it is OK to expose the MWAIT
> +	 * capability to the kernel to harvest deeper than C3 states from ACPI
> +	 * _CST using the processor_harvest_xen.c module. For this to work, we
> +	 * need to gather the MWAIT_LEAF values (which the cstate.c code
> +	 * checks against). The hypervisor won't expose the MWAIT flag because
> +	 * it would break backwards compatibility; so we will find out directly
> +	 * from the hardware and hypercall.
> +	 */
> +	if (!xen_initial_domain())
> +		return false;
> +
> +	ax = 1;
> +	cx = 0;
> +
> +	native_cpuid(&ax, &bx, &cx, &dx);
> +
> +	mwait_mask = (1 << (X86_FEATURE_EST % 32)) |
> +		     (1 << (X86_FEATURE_MWAIT % 32));
> +
> +	if ((cx & mwait_mask) != mwait_mask)
> +		return false;
> +
> +	/* We need to emulate the MWAIT_LEAF and for that we need both
> +	 * ecx and edx. The hypercall provides only partial information.
> +	 */
> +
> +	ax = CPUID_MWAIT_LEAF;
> +	bx = 0;
> +	cx = 0;
> +	dx = 0;
> +
> +	native_cpuid(&ax, &bx, &cx, &dx);
> +
> +	/* Ask the Hypervisor whether to clear ACPI_PDC_C_C2C3_FFH. If so,
> +	 * don't expose MWAIT_LEAF and let ACPI pick the IOPORT version of C3.
> +	 */
> +	buf[0] = ACPI_PDC_REVISION_ID;
> +	buf[1] = 1;
> +	buf[2] = (ACPI_PDC_C_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_SWSMP);
> +
> +	set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
> +
> +	if ((HYPERVISOR_dom0_op(&op) == 0) &&
> +	    (buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
> +		cpuid_leaf5_ecx_val = cx;
> +		cpuid_leaf5_edx_val = dx;
> +	}
> +	return true;
> +#else
> +	return false;
> +#endif
> +}
>  static void __init xen_init_cpuid_mask(void)
>  {
>  	unsigned int ax, bx, cx, dx;
> @@ -261,6 +348,9 @@ static void __init xen_init_cpuid_mask(void)
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
>  	if ((cx & xsave_mask) != xsave_mask)
>  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
> +
> +	if (xen_check_mwait())
> +		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
>  }
>  
>  static void xen_set_debugreg(int reg, unsigned long val)
> diff --git a/include/xen/interface/platform.h 
> b/include/xen/interface/platform.h
> index c168468..6220b98 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -200,7 +200,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
>  #define XEN_PM_CX   0
>  #define XEN_PM_PX   1
>  #define XEN_PM_TX   2
> -
> +#define XEN_PM_PDC  3
>  /* Px sub info type */
>  #define XEN_PX_PCT   1
>  #define XEN_PX_PSS   2
> @@ -286,6 +286,7 @@ struct xen_processor_performance {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
>  
> +DEFINE_GUEST_HANDLE(uint32_t);

Do you really need to introduce (step by step) handles for all those
uintNN_t types in a way different from Xen's
(__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t))?

Looks good to me otherwise.

Jan

>  struct xenpf_set_processor_pminfo {
>  	/* IN variables */
>  	uint32_t id;    /* ACPI CPU ID */
> @@ -293,6 +294,7 @@ struct xenpf_set_processor_pminfo {
>  	union {
>  		struct xen_processor_power          power;/* Cx: _CST/_CSD */
>  		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
> +		GUEST_HANDLE(uint32_t)              pdc;
>  	};
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
> -- 
> 1.7.9.48.g85da4d



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sT0-0004dm-Fo; Fri, 24 Feb 2012 10:33: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 1S0sSz-0004dV-5B
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:33:33 +0000
Received: from [85.158.139.83:2198] by server-7.bemta-5.messagelabs.com id
	84/C7-16195-C77674F4; Fri, 24 Feb 2012 10:33:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330079611!16481083!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4055 invoked from network); 24 Feb 2012 10:33: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;
	24 Feb 2012 10:33:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10915229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:33:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:33:31 +0000
Message-ID: <1330079609.8557.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:33:29 +0000
In-Reply-To: <1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> we reserve for Xen usage.

Does this require a trap when the guest acks or EOIs this interrupt?
What about maintenance interrupts arising from injecting this?

Might we want to instead inject this interrupt as an SGI, so that it
appears as a per-VCPU interrupt?

> In the future the interrupt used for event injection might be dynamic
> and could be written into the device tree.

I think this is required, isn't it? At least for the privileged domain
which also sees physical interrupts, unless we want to get into playing
tricks with non 1:1 interrupts.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c |   11 +++++++++++
>  xen/arch/arm/dummy.S  |    1 -
>  xen/arch/arm/gic.h    |    3 +++
>  3 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0ee96b9..4752aaa 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -272,6 +272,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
>  {
>  }
>  
> +void vcpu_mark_events_pending(struct vcpu *v)
> +{
> +    int already_pending = test_and_set_bit(
> +        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> +
> +    if ( already_pending )
> +        return;
> +
> +    vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 3f2cc4b..93f6f53 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -31,7 +31,6 @@ DUMMY(arch_vcpu_reset);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_mark_events_pending);
>  DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
> diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
> index 81c388d..36fdea1 100644
> --- a/xen/arch/arm/gic.h
> +++ b/xen/arch/arm/gic.h
> @@ -121,6 +121,9 @@
>  #define GICH_LR_CPUID_SHIFT     9
>  #define GICH_VTR_NRLRGS         0x3f
>  
> +/* XXX: write this into the DT */
> +#define VGIC_IRQ_EVTCHN_CALLBACK 63
> +
>  extern int domain_vgic_init(struct domain *d);
>  extern int vcpu_vgic_init(struct vcpu *v);
>  extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sT0-0004dm-Fo; Fri, 24 Feb 2012 10:33: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 1S0sSz-0004dV-5B
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:33:33 +0000
Received: from [85.158.139.83:2198] by server-7.bemta-5.messagelabs.com id
	84/C7-16195-C77674F4; Fri, 24 Feb 2012 10:33:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330079611!16481083!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4055 invoked from network); 24 Feb 2012 10:33: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;
	24 Feb 2012 10:33:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10915229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:33:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:33:31 +0000
Message-ID: <1330079609.8557.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:33:29 +0000
In-Reply-To: <1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> we reserve for Xen usage.

Does this require a trap when the guest acks or EOIs this interrupt?
What about maintenance interrupts arising from injecting this?

Might we want to instead inject this interrupt as an SGI, so that it
appears as a per-VCPU interrupt?

> In the future the interrupt used for event injection might be dynamic
> and could be written into the device tree.

I think this is required, isn't it? At least for the privileged domain
which also sees physical interrupts, unless we want to get into playing
tricks with non 1:1 interrupts.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c |   11 +++++++++++
>  xen/arch/arm/dummy.S  |    1 -
>  xen/arch/arm/gic.h    |    3 +++
>  3 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0ee96b9..4752aaa 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -272,6 +272,17 @@ void arch_dump_vcpu_info(struct vcpu *v)
>  {
>  }
>  
> +void vcpu_mark_events_pending(struct vcpu *v)
> +{
> +    int already_pending = test_and_set_bit(
> +        0, (unsigned long *)&vcpu_info(v, evtchn_upcall_pending));
> +
> +    if ( already_pending )
> +        return;
> +
> +    vgic_vcpu_inject_irq(v, VGIC_IRQ_EVTCHN_CALLBACK, 1);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 3f2cc4b..93f6f53 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -31,7 +31,6 @@ DUMMY(arch_vcpu_reset);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(sync_vcpu_execstate);
>  NOP(update_vcpu_system_time);
> -DUMMY(vcpu_mark_events_pending);
>  DUMMY(vcpu_show_execution_state);
>  
>  /* Page Reference & Type Maintenance */
> diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
> index 81c388d..36fdea1 100644
> --- a/xen/arch/arm/gic.h
> +++ b/xen/arch/arm/gic.h
> @@ -121,6 +121,9 @@
>  #define GICH_LR_CPUID_SHIFT     9
>  #define GICH_VTR_NRLRGS         0x3f
>  
> +/* XXX: write this into the DT */
> +#define VGIC_IRQ_EVTCHN_CALLBACK 63
> +
>  extern int domain_vgic_init(struct domain *d);
>  extern int vcpu_vgic_init(struct vcpu *v);
>  extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:37:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:37:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sX3-0004s5-5v; Fri, 24 Feb 2012 10:37:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0sX2-0004rs-5c
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 10:37:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330079857!15637885!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7078 invoked from network); 24 Feb 2012 10:37:37 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:37:37 -0000
Received: by wibhi20 with SMTP id hi20so1773312wib.32
	for <xen-devel@lists.xen.org>; Fri, 24 Feb 2012 02:37:37 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.80.40 as permitted sender) client-ip=10.180.80.40; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.80.40 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.80.40])
	by 10.180.80.40 with SMTP id o8mr3066518wix.10.1330079857343 (num_hops
	= 1); Fri, 24 Feb 2012 02:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=T9jBLzSDBCFDTCUppeDAdZPTN9Q1ri6Vh6DzSRH6fu8=;
	b=IERnBQPySPEwpk+MwsiWmQKOjmo3kXIBqRsH2EySTtqIJ8DMaESnwMA8sUKb+qazkz
	OuwAdlMVyP+afoSZWPDgU/RldNfNExzgBjef6SeBGLLQkyKKvdLfTCwt731jP79r6R/A
	g9eeC1QmJXowN7yNecofc13ZjwVLnX05EjJSM=
Received: by 10.180.80.40 with SMTP id o8mr2434410wix.10.1330079857211;
	Fri, 24 Feb 2012 02:37:37 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id bg3sm2557463wib.10.2012.02.24.02.37.35
	(version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 02:37:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 24 Feb 2012 10:37:34 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CB6D18EE.2C35A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] passthrough: release assigned PCI devices
	earlier during domain shutdown
Thread-Index: Aczy4FFzfWfccli5lUWw90qIIxLmyw==
In-Reply-To: <4F47582502000078000748B8@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: espen.skoglund@netronome.com
Subject: Re: [Xen-devel] [PATCH] passthrough: release assigned PCI devices
 earlier during domain 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

On 24/02/2012 08:28, "Jan Beulich" <JBeulich@suse.com> wrote:

> At least with xend, where there's not even a tool stack side attempt to
> de-assign devices during domain shutdown, this allows immediate re-
> starts of a domain to work reliably. (There's no apparent reason why
> c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of
> domain destruction).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/domain.c
> +++ b/xen/arch/ia64/xen/domain.c
> @@ -673,10 +673,8 @@ void arch_domain_destroy(struct domain *
> free_xenheap_pages(d->shared_info,
>   get_order_from_shift(XSI_SHIFT));
>  
> - if ( iommu_enabled && need_iommu(d) ) {
> -  pci_release_devices(d);
> + if ( iommu_enabled && need_iommu(d) )
> iommu_domain_destroy(d);
> - }
>  
> tlb_track_destroy(d);
>  
> @@ -1721,6 +1719,8 @@ int domain_relinquish_resources(struct d
>  
> switch (d->arch.relres) {
> case RELRES_not_started:
> +  pci_release_devices(d);
> +
> /* Relinquish guest resources for VT-i domain. */
> if (is_hvm_domain(d))
> vmx_relinquish_guest_resources(d);
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -657,7 +657,6 @@ void arch_domain_destroy(struct domain *
>          xfree(d->arch.pv_domain.e820);
>  
>      vmce_destroy_msr(d);
> -    pci_release_devices(d);
>      free_domain_pirqs(d);
>      if ( !is_idle_domain(d) )
>          iommu_domain_destroy(d);
> @@ -2101,6 +2100,8 @@ int domain_relinquish_resources(struct d
>      switch ( d->arch.relmem )
>      {
>      case RELMEM_not_started:
> +        pci_release_devices(d);
> +
>          /* Tear down paging-assistance stuff. */
>          paging_teardown(d);
>  
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -574,7 +574,8 @@ int iommu_do_domctl(
>          break;
>  
>      case XEN_DOMCTL_assign_device:
> -        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
> +        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ||
> +             unlikely(d->is_dying) )
>          {
>              printk(XENLOG_G_ERR
>                     "XEN_DOMCTL_assign_device: get_domain_by_id() failed\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 Fri Feb 24 10:37:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:37:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sX3-0004s5-5v; Fri, 24 Feb 2012 10:37:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S0sX2-0004rs-5c
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 10:37:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330079857!15637885!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7078 invoked from network); 24 Feb 2012 10:37:37 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:37:37 -0000
Received: by wibhi20 with SMTP id hi20so1773312wib.32
	for <xen-devel@lists.xen.org>; Fri, 24 Feb 2012 02:37:37 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.80.40 as permitted sender) client-ip=10.180.80.40; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.80.40 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.80.40])
	by 10.180.80.40 with SMTP id o8mr3066518wix.10.1330079857343 (num_hops
	= 1); Fri, 24 Feb 2012 02:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=T9jBLzSDBCFDTCUppeDAdZPTN9Q1ri6Vh6DzSRH6fu8=;
	b=IERnBQPySPEwpk+MwsiWmQKOjmo3kXIBqRsH2EySTtqIJ8DMaESnwMA8sUKb+qazkz
	OuwAdlMVyP+afoSZWPDgU/RldNfNExzgBjef6SeBGLLQkyKKvdLfTCwt731jP79r6R/A
	g9eeC1QmJXowN7yNecofc13ZjwVLnX05EjJSM=
Received: by 10.180.80.40 with SMTP id o8mr2434410wix.10.1330079857211;
	Fri, 24 Feb 2012 02:37:37 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id bg3sm2557463wib.10.2012.02.24.02.37.35
	(version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 02:37:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 24 Feb 2012 10:37:34 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CB6D18EE.2C35A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] passthrough: release assigned PCI devices
	earlier during domain shutdown
Thread-Index: Aczy4FFzfWfccli5lUWw90qIIxLmyw==
In-Reply-To: <4F47582502000078000748B8@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: espen.skoglund@netronome.com
Subject: Re: [Xen-devel] [PATCH] passthrough: release assigned PCI devices
 earlier during domain 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

On 24/02/2012 08:28, "Jan Beulich" <JBeulich@suse.com> wrote:

> At least with xend, where there's not even a tool stack side attempt to
> de-assign devices during domain shutdown, this allows immediate re-
> starts of a domain to work reliably. (There's no apparent reason why
> c/s 18010:c1577f094ae4 chose to put this in the asynchronous part of
> domain destruction).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/domain.c
> +++ b/xen/arch/ia64/xen/domain.c
> @@ -673,10 +673,8 @@ void arch_domain_destroy(struct domain *
> free_xenheap_pages(d->shared_info,
>   get_order_from_shift(XSI_SHIFT));
>  
> - if ( iommu_enabled && need_iommu(d) ) {
> -  pci_release_devices(d);
> + if ( iommu_enabled && need_iommu(d) )
> iommu_domain_destroy(d);
> - }
>  
> tlb_track_destroy(d);
>  
> @@ -1721,6 +1719,8 @@ int domain_relinquish_resources(struct d
>  
> switch (d->arch.relres) {
> case RELRES_not_started:
> +  pci_release_devices(d);
> +
> /* Relinquish guest resources for VT-i domain. */
> if (is_hvm_domain(d))
> vmx_relinquish_guest_resources(d);
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -657,7 +657,6 @@ void arch_domain_destroy(struct domain *
>          xfree(d->arch.pv_domain.e820);
>  
>      vmce_destroy_msr(d);
> -    pci_release_devices(d);
>      free_domain_pirqs(d);
>      if ( !is_idle_domain(d) )
>          iommu_domain_destroy(d);
> @@ -2101,6 +2100,8 @@ int domain_relinquish_resources(struct d
>      switch ( d->arch.relmem )
>      {
>      case RELMEM_not_started:
> +        pci_release_devices(d);
> +
>          /* Tear down paging-assistance stuff. */
>          paging_teardown(d);
>  
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -574,7 +574,8 @@ int iommu_do_domctl(
>          break;
>  
>      case XEN_DOMCTL_assign_device:
> -        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
> +        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ||
> +             unlikely(d->is_dying) )
>          {
>              printk(XENLOG_G_ERR
>                     "XEN_DOMCTL_assign_device: get_domain_by_id() failed\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 Fri Feb 24 10:39:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sY9-0004we-Kl; Fri, 24 Feb 2012 10:38:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sY8-0004wI-LB
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:38:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330079926!10777881!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7055 invoked from network); 24 Feb 2012 10:38:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:38:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:38:45 +0000
Message-Id: <4F4776C402000078000749AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:38:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<a34b652afb0ca484b741.1330065833@phenom.dumpdata.com>
In-Reply-To: <a34b652afb0ca484b741.1330065833@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] traps: AMD PM RDMSRs
 (MSR_K8_PSTATE_CTRL, 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 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1330065828 18000
> # Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
> # Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> 
> The restriction to read and write the AMD power management MSRs is gated if 
> the
> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> relax this restriction and allow the privileged domain to read the MSRs
> (but not write). This allows the priviliged domain to harvest the power
> management information (ACPI _PSS states) and send it to the hypervisor.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Wed Feb 22 14:33:24 2012 +0000
> +++ b/xen/arch/x86/traps.c	Fri Feb 24 01:43:48 2012 -0500
> @@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct 
>          case MSR_K8_PSTATE7:
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
>                  goto fail;
> -            if ( !is_cpufreq_controller(v->domain) )
> +            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )

As said already in response to your Linux side overview mail, while
I don't view this as having potential to cause any problems, I also
don't see the need.

And then if this indeed is wanted, replacing is_cpufreq_controller()
by IS_PRIV() rather than adding the latter would seem preferable
(because of being more strait forward).

Jan

>              {
>                  regs->eax = regs->edx = 0;
>                  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 Fri Feb 24 10:39:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sY9-0004we-Kl; Fri, 24 Feb 2012 10:38:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0sY8-0004wI-LB
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:38:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330079926!10777881!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7055 invoked from network); 24 Feb 2012 10:38:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:38:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:38:45 +0000
Message-Id: <4F4776C402000078000749AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:38:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<a34b652afb0ca484b741.1330065833@phenom.dumpdata.com>
In-Reply-To: <a34b652afb0ca484b741.1330065833@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 2] traps: AMD PM RDMSRs
 (MSR_K8_PSTATE_CTRL, 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 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1330065828 18000
> # Node ID a34b652afb0ca484b7416008c95fd36ffbbea334
> # Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
> traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> 
> The restriction to read and write the AMD power management MSRs is gated if 
> the
> domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> relax this restriction and allow the privileged domain to read the MSRs
> (but not write). This allows the priviliged domain to harvest the power
> management information (ACPI _PSS states) and send it to the hypervisor.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r a4d93d0e0df2 -r a34b652afb0c xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Wed Feb 22 14:33:24 2012 +0000
> +++ b/xen/arch/x86/traps.c	Fri Feb 24 01:43:48 2012 -0500
> @@ -2610,7 +2610,7 @@ static int emulate_privileged_op(struct 
>          case MSR_K8_PSTATE7:
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
>                  goto fail;
> -            if ( !is_cpufreq_controller(v->domain) )
> +            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )

As said already in response to your Linux side overview mail, while
I don't view this as having potential to cause any problems, I also
don't see the need.

And then if this indeed is wanted, replacing is_cpufreq_controller()
by IS_PRIV() rather than adding the latter would seem preferable
(because of being more strait forward).

Jan

>              {
>                  regs->eax = regs->edx = 0;
>                  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 Fri Feb 24 10:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sae-0005EM-Up; Fri, 24 Feb 2012 10:41:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sad-0005Dc-I6
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:41:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330080081!16185155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24331 invoked from network); 24 Feb 2012 10:41:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:41:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10915460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:40:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:40:49 +0000
Message-ID: <1330080047.8557.167.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:40:47 +0000
In-Reply-To: <1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 3/5] arm: set the default dom0 max_vcpus
 value to 1 (currently is 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-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Why is this needed? It makes it impossible to distinguish the "use all
CPUs" default from the "only use 1 CPU" case.

I think we want this instead, it's approx what x86 does, modulo not
using cpupool0:

8<----------------------------------------------

>From 7c66c893c5fbf485bc9071b9ef14680475b91670 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 24 Feb 2012 10:36:42 +0000
Subject: [PATCH] arm: handle dom0_max_vcpus=0 case properly

Also use xzalloc_array.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ec5a9f3..4efe07d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -15,13 +15,14 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
-    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( opt_dom0_max_vcpus == 0 )
+        opt_dom0_max_vcpus = num_online_cpus();
+    if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
+        opt_dom0_max_vcpus = MAX_VIRT_CPUS;
+
+    dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
     if ( !dom0->vcpu )
-    {
-            printk("failed to alloc dom0->vccpu\n");
         return NULL;
-    }
-    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
     dom0->max_vcpus = opt_dom0_max_vcpus;
 
     return alloc_vcpu(dom0, 0, 0);
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sae-0005EM-Up; Fri, 24 Feb 2012 10:41:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sad-0005Dc-I6
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:41:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330080081!16185155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24331 invoked from network); 24 Feb 2012 10:41:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:41:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10915460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:40:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:40:49 +0000
Message-ID: <1330080047.8557.167.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:40:47 +0000
In-Reply-To: <1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 3/5] arm: set the default dom0 max_vcpus
 value to 1 (currently is 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-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Why is this needed? It makes it impossible to distinguish the "use all
CPUs" default from the "only use 1 CPU" case.

I think we want this instead, it's approx what x86 does, modulo not
using cpupool0:

8<----------------------------------------------

>From 7c66c893c5fbf485bc9071b9ef14680475b91670 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 24 Feb 2012 10:36:42 +0000
Subject: [PATCH] arm: handle dom0_max_vcpus=0 case properly

Also use xzalloc_array.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ec5a9f3..4efe07d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -15,13 +15,14 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
-    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    if ( opt_dom0_max_vcpus == 0 )
+        opt_dom0_max_vcpus = num_online_cpus();
+    if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
+        opt_dom0_max_vcpus = MAX_VIRT_CPUS;
+
+    dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
     if ( !dom0->vcpu )
-    {
-            printk("failed to alloc dom0->vccpu\n");
         return NULL;
-    }
-    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
     dom0->max_vcpus = opt_dom0_max_vcpus;
 
     return alloc_vcpu(dom0, 0, 0);
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:43:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sc7-0005Rb-LK; Fri, 24 Feb 2012 10:42:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sc5-0005R0-SL
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:42:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330080171!14715814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4554 invoked from network); 24 Feb 2012 10:42:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:42:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10915477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:41:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:41:48 +0000
Message-ID: <1330080107.8557.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:41:47 +0000
In-Reply-To: <1330021293-21554-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 5/5] arm: introduce more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Implement xen_version, event_channel_op, memory_op sysctl and physdev_op
> hypercalls.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/Makefile           |    1 +
>  xen/arch/arm/physdev.c          |   27 +++++++++++++++++++++++++++
>  xen/arch/arm/traps.c            |    5 +++++
>  xen/include/asm-arm/hypercall.h |    1 +
>  4 files changed, 34 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/physdev.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 49b64fe..619430c 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -14,6 +14,7 @@ obj-y += kernel.o
>  obj-y += mm.o
>  obj-y += p2m.o
>  obj-y += guestcopy.o
> +obj-y += physdev.o
>  obj-y += setup.o
>  obj-y += time.o
>  obj-y += smpboot.o
> diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
> new file mode 100644
> index 0000000..bcf4337
> --- /dev/null
> +++ b/xen/arch/arm/physdev.c
> @@ -0,0 +1,27 @@
> +/******************************************************************************
> + * Arch-specific physdev.c
> + *
> + * Copyright (c) 2012, Citrix Systems
> + */
> +
> +#include <xen/config.h>
> +#include <xen/types.h>
> +#include <xen/lib.h>
> +#include <xen/errno.h>
> +#include <asm/hypercall.h>
> +
> +
> +int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
> +{
> +    printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
> +    return -ENOSYS;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 44d19ec..b266c5e 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -376,6 +376,11 @@ static arm_hypercall_t *arm_hypercall_table[] = {
>      HYPERCALL(arch_0),
>      HYPERCALL(sched_op),
>      HYPERCALL(console_io),
> +    HYPERCALL(xen_version),
> +    HYPERCALL(event_channel_op),
> +    HYPERCALL(memory_op),
> +    HYPERCALL(physdev_op),
> +    HYPERCALL(sysctl),
>  };
>  
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
> index d517542..b91f8b6 100644
> --- a/xen/include/asm-arm/hypercall.h
> +++ b/xen/include/asm-arm/hypercall.h
> @@ -2,6 +2,7 @@
>  #define __ASM_ARM_HYPERCALL_H__
>  
>  #include <public/domctl.h> /* for arch_do_domctl */
> +int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
>  
>  #define XEN_HYPERCALL_TAG   0XEA1
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:43:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sc7-0005Rb-LK; Fri, 24 Feb 2012 10:42:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sc5-0005R0-SL
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:42:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330080171!14715814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4554 invoked from network); 24 Feb 2012 10:42:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:42:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10915477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 10:41:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 10:41:48 +0000
Message-ID: <1330080107.8557.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 10:41:47 +0000
In-Reply-To: <1330021293-21554-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 5/5] arm: introduce more hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Implement xen_version, event_channel_op, memory_op sysctl and physdev_op
> hypercalls.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/Makefile           |    1 +
>  xen/arch/arm/physdev.c          |   27 +++++++++++++++++++++++++++
>  xen/arch/arm/traps.c            |    5 +++++
>  xen/include/asm-arm/hypercall.h |    1 +
>  4 files changed, 34 insertions(+), 0 deletions(-)
>  create mode 100644 xen/arch/arm/physdev.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 49b64fe..619430c 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -14,6 +14,7 @@ obj-y += kernel.o
>  obj-y += mm.o
>  obj-y += p2m.o
>  obj-y += guestcopy.o
> +obj-y += physdev.o
>  obj-y += setup.o
>  obj-y += time.o
>  obj-y += smpboot.o
> diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
> new file mode 100644
> index 0000000..bcf4337
> --- /dev/null
> +++ b/xen/arch/arm/physdev.c
> @@ -0,0 +1,27 @@
> +/******************************************************************************
> + * Arch-specific physdev.c
> + *
> + * Copyright (c) 2012, Citrix Systems
> + */
> +
> +#include <xen/config.h>
> +#include <xen/types.h>
> +#include <xen/lib.h>
> +#include <xen/errno.h>
> +#include <asm/hypercall.h>
> +
> +
> +int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
> +{
> +    printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
> +    return -ENOSYS;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 44d19ec..b266c5e 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -376,6 +376,11 @@ static arm_hypercall_t *arm_hypercall_table[] = {
>      HYPERCALL(arch_0),
>      HYPERCALL(sched_op),
>      HYPERCALL(console_io),
> +    HYPERCALL(xen_version),
> +    HYPERCALL(event_channel_op),
> +    HYPERCALL(memory_op),
> +    HYPERCALL(physdev_op),
> +    HYPERCALL(sysctl),
>  };
>  
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
> index d517542..b91f8b6 100644
> --- a/xen/include/asm-arm/hypercall.h
> +++ b/xen/include/asm-arm/hypercall.h
> @@ -2,6 +2,7 @@
>  #define __ASM_ARM_HYPERCALL_H__
>  
>  #include <public/domctl.h> /* for arch_do_domctl */
> +int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
>  
>  #define XEN_HYPERCALL_TAG   0XEA1
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:45:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0seB-0005jK-8R; Fri, 24 Feb 2012 10:45:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0se9-0005ic-FK
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:45:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330080267!58115160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14006 invoked from network); 24 Feb 2012 10:44:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:44:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:44:58 +0000
Message-Id: <4F47783602000078000749C0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:44:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
In-Reply-To: <aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load
 processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1330065828 18000
> # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
> # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
> linux-xencommons: Load processor-passthru
> 
> The processor-passthru module is used in the upstream kernels
> to upload power management information to the hypervisor. We
> need to load it to work first.

Hmm, I don't really like this (and prior) pvops-specific additions here,
even if stderr gets directed into nowhere. I don't think this (and any
other) script intended to target Linux in general should target just
a specific implementation.

Furthermore, given the purpose of the driver, I'm thinking that this
is too late in the boot process anyway, and the driver should rather
be loaded at the point where other CPUFreq drivers would normally
be by a particular distro (which would still be later than when the
respective code gets run on traditional Xenified Linux).

Jan

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r a34b652afb0c -r aa3a294327ed tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
> @@ -58,6 +58,7 @@ do_start () {
>  	modprobe xen-gntdev 2>/dev/null
>  	modprobe evtchn 2>/dev/null
>  	modprobe gntdev 2>/dev/null
> +	modprobe processor-passthru 2>/dev/null
>  
>  	if ! `xenstore-read -s / >/dev/null 2>&1`
>  	then
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:45:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0seB-0005jK-8R; Fri, 24 Feb 2012 10:45:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0se9-0005ic-FK
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:45:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330080267!58115160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14006 invoked from network); 24 Feb 2012 10:44:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 10:44:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 10:44:58 +0000
Message-Id: <4F47783602000078000749C0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 10:44:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad.wilk@oracle.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
In-Reply-To: <aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load
 processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> # HG changeset patch
> # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> # Date 1330065828 18000
> # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
> # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
> linux-xencommons: Load processor-passthru
> 
> The processor-passthru module is used in the upstream kernels
> to upload power management information to the hypervisor. We
> need to load it to work first.

Hmm, I don't really like this (and prior) pvops-specific additions here,
even if stderr gets directed into nowhere. I don't think this (and any
other) script intended to target Linux in general should target just
a specific implementation.

Furthermore, given the purpose of the driver, I'm thinking that this
is too late in the boot process anyway, and the driver should rather
be loaded at the point where other CPUFreq drivers would normally
be by a particular distro (which would still be later than when the
respective code gets run on traditional Xenified Linux).

Jan

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff -r a34b652afb0c -r aa3a294327ed tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 01:43:48 2012 -0500
> @@ -58,6 +58,7 @@ do_start () {
>  	modprobe xen-gntdev 2>/dev/null
>  	modprobe evtchn 2>/dev/null
>  	modprobe gntdev 2>/dev/null
> +	modprobe processor-passthru 2>/dev/null
>  
>  	if ! `xenstore-read -s / >/dev/null 2>&1`
>  	then
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:50:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sjb-00064D-BN; Fri, 24 Feb 2012 10:50:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0sja-000646-G3
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:50:42 +0000
Received: from [85.158.139.83:26727] by server-3.bemta-5.messagelabs.com id
	03/47-06438-18B674F4; Fri, 24 Feb 2012 10:50:41 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330080613!15936510!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13280 invoked from network); 24 Feb 2012 10:50:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Feb 2012 10:50:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0sj2-0004pV-BK
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 02:50:08 -0800
Date: Fri, 24 Feb 2012 02:50:08 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330080608338-5512352.post@n5.nabble.com>
In-Reply-To: <1329987975739-5507438.post@n5.nabble.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
	<1329987975739-5507438.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen and all of its parts (include qemu upstream) has debug on build-time
enabled by default or must be enabled?

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5512352.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:50:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10:50:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sjb-00064D-BN; Fri, 24 Feb 2012 10:50:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0sja-000646-G3
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:50:42 +0000
Received: from [85.158.139.83:26727] by server-3.bemta-5.messagelabs.com id
	03/47-06438-18B674F4; Fri, 24 Feb 2012 10:50:41 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330080613!15936510!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13280 invoked from network); 24 Feb 2012 10:50:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Feb 2012 10:50:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S0sj2-0004pV-BK
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 02:50:08 -0800
Date: Fri, 24 Feb 2012 02:50:08 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330080608338-5512352.post@n5.nabble.com>
In-Reply-To: <1329987975739-5507438.post@n5.nabble.com>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
	<1329987975739-5507438.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
	Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen and all of its parts (include qemu upstream) has debug on build-time
enabled by default or must be enabled?

--
View this message in context: http://xen.1045712.n5.nabble.com/xen-unstable-Qemu-upstream-domUs-not-start-on-Wheezy-tp5505409p5512352.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:51:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sji-00064y-NE; Fri, 24 Feb 2012 10:50:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1S0sjh-00064m-Gv
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:50:49 +0000
Received: from [85.158.139.83:31820] by server-8.bemta-5.messagelabs.com id
	EC/C4-09797-88B674F4; Fri, 24 Feb 2012 10:50:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330080646!16491828!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24479 invoked from network); 24 Feb 2012 10:50:47 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-182.messagelabs.com with SMTP;
	24 Feb 2012 10:50:47 -0000
Received: from [62.94.180.152] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75826644; Fri, 24 Feb 2012 11:50:46 +0100
Message-ID: <1330080645.5034.96.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 24 Feb 2012 11:50:45 +0100
In-Reply-To: <4F476396.60802@eu.citrix.com>
References: <1330078323.5034.73.camel@Abyss> <4F476396.60802@eu.citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3677443251419548882=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3677443251419548882==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-z0pT82/1ZuQr7ZRP+kMt"


--=-z0pT82/1ZuQr7ZRP+kMt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-02-24 at 10:16 +0000, George Dunlap wrote:=20
> > Basically, given alloc_domheap_pages uses d->node_affinity for deciding
> > from which node(s) to actually take memory from, I was planning to
> > either use the same mask or build a new one with similar purposes, the
> > problem being _where_ to populate it with the proper nodes.
> > I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
> > although I think it's too early, and I'd end up guessing wrt a lot of
> > aspects... But considering xm/xend was doing the same even earlier (at
> > least I think)...
> So the first question is, where should the decision about NUMA placement=
=20
> be made, and the second is how that level should implement it.
>=20
Yes, indeed.

> Doing it at the libxc level I think is not right. =20
>
Ok, same here. Just to be sure I understood what you're saying, if you
refer to xc_domain_setmaxmem, as I'll end up doing it in do_domctl, it'd
be in Xen, but anyway it still won't look like the way I wanted it to be
(see below). :-(

> It seems to me we=20
> have two options:
> * Have libxl do the NUMA placement on behalf of the toolstack.  In that=
=20
> case, the libxl_domain_create_new function should look at the available=
=20
> memory, the NUMA layout, &c, and then set d->node_affinity before=20
> calling xc_hvm_build.
>
This can be done. If I got it correctly it is more or less what xm/xend
already does.

> * Have the toolstack do it.  In this case, you'd be modifying xl to set=
=20
> d->node_affinity before calling libxl's domain creation function.
>=20
I'm not sure I'm getting this right... It seems very similar to the one
above.

> Do those options work?  Let me know if I've misunderstood anything.
>=20
I think they can be implemented. "work", it depends on how we define
"work". :-D

That's why I was struggling for putting this in the hypervisor and not
in the toolstack because I really think it should live there if
possible. For example it would be nice for the decision to be protected
by the proper locking. I mean, what's the point in checking the amount
of free memory in a node somewhere in (lib)xl, if when the actual
allocation will happen (in Xen) that might be a completely different
value (due to concurrent domain creation, destruction, etc.)?

> Any thoughts one way or the other from anyone?
>=20
Any ideas on how to put that thing _in_ Xen?

> I'd be tempted to have it be optional -- you can set "numa=3Dauto" and th=
e=20
> domain creation function will do the simple thing; or you can set=20
> "numa=3Dmanual" and have the toolstack / config file set the nodes=20
> manually.  That would translate pretty well to config files as well --=
=20
> more "set the knobs" administrators could set the numa layout in the=20
> config file manually if they wanted.
>=20
I agree and that was already my plan: configurable and per-domain.

I think the config file, supporting cpupools and vcpu-pinning, already
offer almost all the facilities for manually deploying a VM reflecting a
specific NUMA-layout. What I was thinking adding was the "numa=3Dauto" or
whatever switch, so that if one does not (want to) specify cpupools or
pinning, VM still gets NUMA-sensible placement.

But anyway, no problem adding other knobs if considered worthwhile, the
problem is the other part! :-P

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-z0pT82/1ZuQr7ZRP+kMt
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)

iEYEABECAAYFAk9Ha4UACgkQk4XaBE3IOsT2KQCdHiBtJ0/JMpwGq+Xuobtw+JiA
agUAn1+DnFkQn8v0O+1fLvh3QHYGCQoN
=VZst
-----END PGP SIGNATURE-----

--=-z0pT82/1ZuQr7ZRP+kMt--



--===============3677443251419548882==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3677443251419548882==--



From xen-devel-bounces@lists.xen.org Fri Feb 24 10:51:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 10: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 1S0sji-00064y-NE; Fri, 24 Feb 2012 10:50:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1S0sjh-00064m-Gv
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:50:49 +0000
Received: from [85.158.139.83:31820] by server-8.bemta-5.messagelabs.com id
	EC/C4-09797-88B674F4; Fri, 24 Feb 2012 10:50:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330080646!16491828!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24479 invoked from network); 24 Feb 2012 10:50:47 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-182.messagelabs.com with SMTP;
	24 Feb 2012 10:50:47 -0000
Received: from [62.94.180.152] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75826644; Fri, 24 Feb 2012 11:50:46 +0100
Message-ID: <1330080645.5034.96.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 24 Feb 2012 11:50:45 +0100
In-Reply-To: <4F476396.60802@eu.citrix.com>
References: <1330078323.5034.73.camel@Abyss> <4F476396.60802@eu.citrix.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) 
Mime-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3677443251419548882=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3677443251419548882==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-z0pT82/1ZuQr7ZRP+kMt"


--=-z0pT82/1ZuQr7ZRP+kMt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-02-24 at 10:16 +0000, George Dunlap wrote:=20
> > Basically, given alloc_domheap_pages uses d->node_affinity for deciding
> > from which node(s) to actually take memory from, I was planning to
> > either use the same mask or build a new one with similar purposes, the
> > problem being _where_ to populate it with the proper nodes.
> > I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
> > although I think it's too early, and I'd end up guessing wrt a lot of
> > aspects... But considering xm/xend was doing the same even earlier (at
> > least I think)...
> So the first question is, where should the decision about NUMA placement=
=20
> be made, and the second is how that level should implement it.
>=20
Yes, indeed.

> Doing it at the libxc level I think is not right. =20
>
Ok, same here. Just to be sure I understood what you're saying, if you
refer to xc_domain_setmaxmem, as I'll end up doing it in do_domctl, it'd
be in Xen, but anyway it still won't look like the way I wanted it to be
(see below). :-(

> It seems to me we=20
> have two options:
> * Have libxl do the NUMA placement on behalf of the toolstack.  In that=
=20
> case, the libxl_domain_create_new function should look at the available=
=20
> memory, the NUMA layout, &c, and then set d->node_affinity before=20
> calling xc_hvm_build.
>
This can be done. If I got it correctly it is more or less what xm/xend
already does.

> * Have the toolstack do it.  In this case, you'd be modifying xl to set=
=20
> d->node_affinity before calling libxl's domain creation function.
>=20
I'm not sure I'm getting this right... It seems very similar to the one
above.

> Do those options work?  Let me know if I've misunderstood anything.
>=20
I think they can be implemented. "work", it depends on how we define
"work". :-D

That's why I was struggling for putting this in the hypervisor and not
in the toolstack because I really think it should live there if
possible. For example it would be nice for the decision to be protected
by the proper locking. I mean, what's the point in checking the amount
of free memory in a node somewhere in (lib)xl, if when the actual
allocation will happen (in Xen) that might be a completely different
value (due to concurrent domain creation, destruction, etc.)?

> Any thoughts one way or the other from anyone?
>=20
Any ideas on how to put that thing _in_ Xen?

> I'd be tempted to have it be optional -- you can set "numa=3Dauto" and th=
e=20
> domain creation function will do the simple thing; or you can set=20
> "numa=3Dmanual" and have the toolstack / config file set the nodes=20
> manually.  That would translate pretty well to config files as well --=
=20
> more "set the knobs" administrators could set the numa layout in the=20
> config file manually if they wanted.
>=20
I agree and that was already my plan: configurable and per-domain.

I think the config file, supporting cpupools and vcpu-pinning, already
offer almost all the facilities for manually deploying a VM reflecting a
specific NUMA-layout. What I was thinking adding was the "numa=3Dauto" or
whatever switch, so that if one does not (want to) specify cpupools or
pinning, VM still gets NUMA-sensible placement.

But anyway, no problem adding other knobs if considered worthwhile, the
problem is the other part! :-P

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-z0pT82/1ZuQr7ZRP+kMt
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)

iEYEABECAAYFAk9Ha4UACgkQk4XaBE3IOsT2KQCdHiBtJ0/JMpwGq+Xuobtw+JiA
agUAn1+DnFkQn8v0O+1fLvh3QHYGCQoN
=VZst
-----END PGP SIGNATURE-----

--=-z0pT82/1ZuQr7ZRP+kMt--



--===============3677443251419548882==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3677443251419548882==--



From xen-devel-bounces@lists.xen.org Fri Feb 24 10:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0sm2-0006GX-9H; Fri, 24 Feb 2012 10:53:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S0sm0-0006GF-9w
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:53:12 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330080784!9596716!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9885 invoked from network); 24 Feb 2012 10:53:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325480400"; d="scan'208";a="22410242"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 05:53:04 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012
	05:53:04 -0500
Message-ID: <4F476C0E.2010107@citrix.com>
Date: Fri, 24 Feb 2012 10:53:02 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>	
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330079609.8557.165.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/02/12 10:33, Ian Campbell wrote:
> On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
>> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
>> we reserve for Xen usage.
> 
> Does this require a trap when the guest acks or EOIs this interrupt?
> What about maintenance interrupts arising from injecting this?
> 
> Might we want to instead inject this interrupt as an SGI, so that it
> appears as a per-VCPU interrupt?

I don't think it's possible to register a SGI handler in Linux
currently.  The mapping of IRQ numbers to GIC interrupts skips over the
SGIs.  This would be easy to fix I think.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 10:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0sm2-0006GX-9H; Fri, 24 Feb 2012 10:53:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S0sm0-0006GF-9w
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 10:53:12 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330080784!9596716!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjI1NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9885 invoked from network); 24 Feb 2012 10:53:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 10:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325480400"; d="scan'208";a="22410242"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 05:53:04 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012
	05:53:04 -0500
Message-ID: <4F476C0E.2010107@citrix.com>
Date: Fri, 24 Feb 2012 10:53:02 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>	
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330079609.8557.165.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/02/12 10:33, Ian Campbell wrote:
> On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
>> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
>> we reserve for Xen usage.
> 
> Does this require a trap when the guest acks or EOIs this interrupt?
> What about maintenance interrupts arising from injecting this?
> 
> Might we want to instead inject this interrupt as an SGI, so that it
> appears as a per-VCPU interrupt?

I don't think it's possible to register a SGI handler in Linux
currently.  The mapping of IRQ numbers to GIC interrupts skips over the
SGIs.  This would be easy to fix I think.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:04:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11:04:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sx5-0006cZ-H9; Fri, 24 Feb 2012 11:04:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sx3-0006cU-Em
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 11:04:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330081470!14751001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23709 invoked from network); 24 Feb 2012 11:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 11:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10916042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 11:04:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 11:04:30 +0000
Message-ID: <1330081468.8557.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Fri, 24 Feb 2012 11:04:28 +0000
In-Reply-To: <6770476b814532bb36a3.1329919602@zhigang.us.oracle.com>
References: <6770476b814532bb36a3.1329919602@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] add new bootloader xenpvnetboot for pv guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 14:06 +0000, Zhigang Wang wrote:
> tools/misc/Makefile     |    2 +-
>  tools/misc/xenpvnetboot |  293 ++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 294 insertions(+), 1 deletions(-)
> 
> 
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1329919344 18000
> # Node ID 6770476b814532bb36a3b00cba16e5cd8a6b4585
> # Parent  ca80eca9cfa39d1b60d1216948dac5711d550b83
> add new bootloader xenpvnetboot for pv guest
> 
> `xenpvnetboot` supports getting boot images from following locations:

I think this is a really nice idea -- it's been floating around the
bottom of my TODO list for ages now.

Would it be possible to add a man page by adding
docs/man/xenpvnetboot.1.pod using the Perl POD syntax (there's a bunch
of existing docs you could take inspiration from) and perhaps to update
docs/man/xl.cfg.5.pod to reference this new bootloader (you might need
to add a list of possible options, since pyrub was previously the only
thing)

Since you have, I guess, reverse engineered the PV bootloader protocol
from pygrub in order to implement this I wonder if you would consider
writing up a specification for the required interface or such
bootloaders? e.g. docs/misc/pvbootloader.markdown.

By happy coincidence there is a Xen documentation day on Monday ;-)
http://lists.xen.org/archives/html/xen-devel/2012-02/msg01468.html and
http://wiki.xen.org/wiki/Xen_Document_Days
http://blog.xen.org/index.php/2012/02/24/next-xen-document-day-feb-27/

Do you have any further plans for this bootloader? e.g. I think it would
be really cool if it could present a curses based wizard, e.g.
	* Select your distro
	* Provide a URL
	* Tweak command line options
	* Go!

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:04:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11:04:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0sx5-0006cZ-H9; Fri, 24 Feb 2012 11:04:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0sx3-0006cU-Em
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 11:04:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330081470!14751001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23709 invoked from network); 24 Feb 2012 11:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 11:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10916042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 11:04:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 11:04:30 +0000
Message-ID: <1330081468.8557.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Fri, 24 Feb 2012 11:04:28 +0000
In-Reply-To: <6770476b814532bb36a3.1329919602@zhigang.us.oracle.com>
References: <6770476b814532bb36a3.1329919602@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] add new bootloader xenpvnetboot for pv guest
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 14:06 +0000, Zhigang Wang wrote:
> tools/misc/Makefile     |    2 +-
>  tools/misc/xenpvnetboot |  293 ++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 294 insertions(+), 1 deletions(-)
> 
> 
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1329919344 18000
> # Node ID 6770476b814532bb36a3b00cba16e5cd8a6b4585
> # Parent  ca80eca9cfa39d1b60d1216948dac5711d550b83
> add new bootloader xenpvnetboot for pv guest
> 
> `xenpvnetboot` supports getting boot images from following locations:

I think this is a really nice idea -- it's been floating around the
bottom of my TODO list for ages now.

Would it be possible to add a man page by adding
docs/man/xenpvnetboot.1.pod using the Perl POD syntax (there's a bunch
of existing docs you could take inspiration from) and perhaps to update
docs/man/xl.cfg.5.pod to reference this new bootloader (you might need
to add a list of possible options, since pyrub was previously the only
thing)

Since you have, I guess, reverse engineered the PV bootloader protocol
from pygrub in order to implement this I wonder if you would consider
writing up a specification for the required interface or such
bootloaders? e.g. docs/misc/pvbootloader.markdown.

By happy coincidence there is a Xen documentation day on Monday ;-)
http://lists.xen.org/archives/html/xen-devel/2012-02/msg01468.html and
http://wiki.xen.org/wiki/Xen_Document_Days
http://blog.xen.org/index.php/2012/02/24/next-xen-document-day-feb-27/

Do you have any further plans for this bootloader? e.g. I think it would
be really cool if it could present a curses based wizard, e.g.
	* Select your distro
	* Provide a URL
	* Tweak command line options
	* Go!

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11: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 1S0t56-0006ov-T7; Fri, 24 Feb 2012 11:12:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S0t55-0006oq-KP
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 11:12:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330081967!14716633!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30937 invoked from network); 24 Feb 2012 11:12:49 -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;
	24 Feb 2012 11:12:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325480400"; d="scan'208";a="183271516"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 06:12:47 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012
	06:12:47 -0500
Message-ID: <4F4770AD.6040703@citrix.com>
Date: Fri, 24 Feb 2012 11:12:45 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.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>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 07/13] 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 23/02/12 17:48, Stefano Stabellini wrote:
> Compile events.c and use IRQ 32 to receive events notifications.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> +#ifdef CONFIG_ARM
> +#define IRQ_EVTCHN_CALLBACK 63
> +irqreturn_t xen_arm_callback(int irq, void *arg)
> +{
> +	__xen_evtchn_do_upcall();
> +	return 0;
> +}
> +
> +int __init xen_init_IRQ_arm(void)
> +{
> +	int rc;
> +	xen_init_IRQ();
> +	rc = request_irq(IRQ_EVTCHN_CALLBACK, xen_arm_callback,
> +			IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
> +			"events", "events");	
> +	if (rc) {
> +		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
> +	}
> +	return rc;
> +}
> +core_initcall(xen_init_IRQ_arm);
> +#endif

You should (eventually) have a device tree binding for the event channel
and use a OF (device tree) device driver instead of this core_initcall()
to register the handler etc.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11: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 1S0t56-0006ov-T7; Fri, 24 Feb 2012 11:12:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S0t55-0006oq-KP
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 11:12:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330081967!14716633!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjgzNTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30937 invoked from network); 24 Feb 2012 11:12:49 -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;
	24 Feb 2012 11:12:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325480400"; d="scan'208";a="183271516"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 06:12:47 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012
	06:12:47 -0500
Message-ID: <4F4770AD.6040703@citrix.com>
Date: Fri, 24 Feb 2012 11:12:45 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.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>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 07/13] 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 23/02/12 17:48, Stefano Stabellini wrote:
> Compile events.c and use IRQ 32 to receive events notifications.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> +#ifdef CONFIG_ARM
> +#define IRQ_EVTCHN_CALLBACK 63
> +irqreturn_t xen_arm_callback(int irq, void *arg)
> +{
> +	__xen_evtchn_do_upcall();
> +	return 0;
> +}
> +
> +int __init xen_init_IRQ_arm(void)
> +{
> +	int rc;
> +	xen_init_IRQ();
> +	rc = request_irq(IRQ_EVTCHN_CALLBACK, xen_arm_callback,
> +			IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
> +			"events", "events");	
> +	if (rc) {
> +		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
> +	}
> +	return rc;
> +}
> +core_initcall(xen_init_IRQ_arm);
> +#endif

You should (eventually) have a device tree binding for the event channel
and use a OF (device tree) device driver instead of this core_initcall()
to register the handler etc.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:47:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0tbg-0007AA-LL; Fri, 24 Feb 2012 11:46:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0tbf-00079y-7V
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 11:46:35 +0000
Received: from [85.158.139.83:56121] by server-2.bemta-5.messagelabs.com id
	98/F6-20263-A98774F4; Fri, 24 Feb 2012 11:46:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330083993!12621548!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13743 invoked from network); 24 Feb 2012 11:46:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 11:46:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 11:46:32 +0000
Message-Id: <4F4786A802000078000749FD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 11:46:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xenbus: address compiler warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- casting pointers to integer types of different size is being warned on
- an uninitialized variable warning occurred on certain gcc versions

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xenbus/xenbus_client.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- 3.3-rc4/drivers/xen/xenbus/xenbus_client.c
+++ 3.3-rc4-xenbus-warnings/drivers/xen/xenbus/xenbus_client.c
@@ -569,7 +569,7 @@ int xenbus_map_ring(struct xenbus_device
 {
 	struct gnttab_map_grant_ref op;
 
-	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
+	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map, gnt_ref,
 			  dev->otherend_id);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
@@ -662,7 +662,7 @@ static int xenbus_unmap_ring_vfree_hvm(s
 			goto found;
 		}
 	}
-	node = NULL;
+	node = addr = NULL;
  found:
 	spin_unlock(&xenbus_valloc_lock);
 
@@ -698,7 +698,7 @@ int xenbus_unmap_ring(struct xenbus_devi
 {
 	struct gnttab_unmap_grant_ref op;
 
-	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
+	gnttab_set_unmap_op(&op, (unsigned long)vaddr, GNTMAP_host_map, handle);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
 		BUG();




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:47:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0tbg-0007AA-LL; Fri, 24 Feb 2012 11:46:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0tbf-00079y-7V
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 11:46:35 +0000
Received: from [85.158.139.83:56121] by server-2.bemta-5.messagelabs.com id
	98/F6-20263-A98774F4; Fri, 24 Feb 2012 11:46:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330083993!12621548!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13743 invoked from network); 24 Feb 2012 11:46:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 11:46:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 11:46:32 +0000
Message-Id: <4F4786A802000078000749FD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 11:46:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xenbus: address compiler warnings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- casting pointers to integer types of different size is being warned on
- an uninitialized variable warning occurred on certain gcc versions

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xenbus/xenbus_client.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- 3.3-rc4/drivers/xen/xenbus/xenbus_client.c
+++ 3.3-rc4-xenbus-warnings/drivers/xen/xenbus/xenbus_client.c
@@ -569,7 +569,7 @@ int xenbus_map_ring(struct xenbus_device
 {
 	struct gnttab_map_grant_ref op;
 
-	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
+	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map, gnt_ref,
 			  dev->otherend_id);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
@@ -662,7 +662,7 @@ static int xenbus_unmap_ring_vfree_hvm(s
 			goto found;
 		}
 	}
-	node = NULL;
+	node = addr = NULL;
  found:
 	spin_unlock(&xenbus_valloc_lock);
 
@@ -698,7 +698,7 @@ int xenbus_unmap_ring(struct xenbus_devi
 {
 	struct gnttab_unmap_grant_ref op;
 
-	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
+	gnttab_set_unmap_op(&op, (unsigned long)vaddr, GNTMAP_host_map, handle);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
 		BUG();




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11: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 1S0td3-0007Hx-3w; Fri, 24 Feb 2012 11:48:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0td1-0007Ho-5Z
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 11:47:59 +0000
Received: from [85.158.139.83:65294] by server-8.bemta-5.messagelabs.com id
	B4/42-09797-EE8774F4; Fri, 24 Feb 2012 11:47:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330084077!15851679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18625 invoked from network); 24 Feb 2012 11:47:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 11:47:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 11:47:56 +0000
Message-Id: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 11:47:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen: constify all instances of "struct
 attribute_group"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 functions these get passed to have been taking pointers to const
since at least 2.6.16.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/sys-hypervisor.c  |    6 +++---
 drivers/xen/xen-balloon.c     |    2 +-
 drivers/xen/xen-selfballoon.c |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

--- 3.3-rc4/drivers/xen/sys-hypervisor.c
+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c
@@ -97,7 +97,7 @@ static struct attribute *version_attrs[]
 	NULL
 };
 
-static struct attribute_group version_group = {
+static const struct attribute_group version_group = {
 	.name = "version",
 	.attrs = version_attrs,
 };
@@ -210,7 +210,7 @@ static struct attribute *xen_compile_att
 	NULL
 };
 
-static struct attribute_group xen_compilation_group = {
+static const struct attribute_group xen_compilation_group = {
 	.name = "compilation",
 	.attrs = xen_compile_attrs,
 };
@@ -340,7 +340,7 @@ static struct attribute *xen_properties_
 	NULL
 };
 
-static struct attribute_group xen_properties_group = {
+static const struct attribute_group xen_properties_group = {
 	.name = "properties",
 	.attrs = xen_properties_attrs,
 };
--- 3.3-rc4/drivers/xen/xen-balloon.c
+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon.c
@@ -207,7 +207,7 @@ static struct attribute *balloon_info_at
 	NULL
 };
 
-static struct attribute_group balloon_info_group = {
+static const struct attribute_group balloon_info_group = {
 	.name = "info",
 	.attrs = balloon_info_attrs
 };
--- 3.3-rc4/drivers/xen/xen-selfballoon.c
+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-selfballoon.c
@@ -488,7 +488,7 @@ static struct attribute *selfballoon_att
 	NULL
 };
 
-static struct attribute_group selfballoon_group = {
+static const struct attribute_group selfballoon_group = {
 	.name = "selfballoon",
 	.attrs = selfballoon_attrs
 };




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 11:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 11: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 1S0td3-0007Hx-3w; Fri, 24 Feb 2012 11:48:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S0td1-0007Ho-5Z
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 11:47:59 +0000
Received: from [85.158.139.83:65294] by server-8.bemta-5.messagelabs.com id
	B4/42-09797-EE8774F4; Fri, 24 Feb 2012 11:47:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330084077!15851679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18625 invoked from network); 24 Feb 2012 11:47:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2012 11:47:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 24 Feb 2012 11:47:56 +0000
Message-Id: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 24 Feb 2012 11:47:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen: constify all instances of "struct
 attribute_group"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 functions these get passed to have been taking pointers to const
since at least 2.6.16.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/sys-hypervisor.c  |    6 +++---
 drivers/xen/xen-balloon.c     |    2 +-
 drivers/xen/xen-selfballoon.c |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

--- 3.3-rc4/drivers/xen/sys-hypervisor.c
+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c
@@ -97,7 +97,7 @@ static struct attribute *version_attrs[]
 	NULL
 };
 
-static struct attribute_group version_group = {
+static const struct attribute_group version_group = {
 	.name = "version",
 	.attrs = version_attrs,
 };
@@ -210,7 +210,7 @@ static struct attribute *xen_compile_att
 	NULL
 };
 
-static struct attribute_group xen_compilation_group = {
+static const struct attribute_group xen_compilation_group = {
 	.name = "compilation",
 	.attrs = xen_compile_attrs,
 };
@@ -340,7 +340,7 @@ static struct attribute *xen_properties_
 	NULL
 };
 
-static struct attribute_group xen_properties_group = {
+static const struct attribute_group xen_properties_group = {
 	.name = "properties",
 	.attrs = xen_properties_attrs,
 };
--- 3.3-rc4/drivers/xen/xen-balloon.c
+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon.c
@@ -207,7 +207,7 @@ static struct attribute *balloon_info_at
 	NULL
 };
 
-static struct attribute_group balloon_info_group = {
+static const struct attribute_group balloon_info_group = {
 	.name = "info",
 	.attrs = balloon_info_attrs
 };
--- 3.3-rc4/drivers/xen/xen-selfballoon.c
+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-selfballoon.c
@@ -488,7 +488,7 @@ static struct attribute *selfballoon_att
 	NULL
 };
 
-static struct attribute_group selfballoon_group = {
+static const struct attribute_group selfballoon_group = {
 	.name = "selfballoon",
 	.attrs = selfballoon_attrs
 };




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0tvX-00082z-4Z; Fri, 24 Feb 2012 12:07:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0tvV-00082e-Hy
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 12:07:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330085219!14726294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2735 invoked from network); 24 Feb 2012 12:06:59 -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;
	24 Feb 2012 12:06:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:06:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:06:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0tvO-0006OC-M5; Fri, 24 Feb 2012 12:06:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0tvO-0001Es-Jn;
	Fri, 24 Feb 2012 12:06:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.32098.602480.91456@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 12:06:58 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <40f8487cacc807bb6f9d.1329815953@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
	<40f8487cacc807bb6f9d.1329815953@build.localdomain>
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 1 of 2] Linux/init: check for brctl at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH 1 of 2] Linux/init: check for brctl at xencommons"):
> Linux/init: check for brctl at xencommons
...
> +# Check if brctl is present
> +hash brctl > /dev/null 2>&1 || echo "Warning: brctl not found"

I using think "type" would be more idomatic than "hash".

I think the warning message should go to stderr and mention
xencommons.  I was going to suggest that you should use the lsb init
function "log_warning_msg" but I see that xencommons does not
currently source /lib/lsb/init-functions.  But perhaps it should.

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:07:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0tvX-00082z-4Z; Fri, 24 Feb 2012 12:07:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0tvV-00082e-Hy
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 12:07:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330085219!14726294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2735 invoked from network); 24 Feb 2012 12:06:59 -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;
	24 Feb 2012 12:06:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:06:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:06:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0tvO-0006OC-M5; Fri, 24 Feb 2012 12:06:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0tvO-0001Es-Jn;
	Fri, 24 Feb 2012 12:06:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.32098.602480.91456@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 12:06:58 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <40f8487cacc807bb6f9d.1329815953@build.localdomain>
References: <patchbomb.1329815952@build.localdomain>
	<40f8487cacc807bb6f9d.1329815953@build.localdomain>
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 1 of 2] Linux/init: check for brctl at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[PATCH 1 of 2] Linux/init: check for brctl at xencommons"):
> Linux/init: check for brctl at xencommons
...
> +# Check if brctl is present
> +hash brctl > /dev/null 2>&1 || echo "Warning: brctl not found"

I using think "type" would be more idomatic than "hash".

I think the warning message should go to stderr and mention
xencommons.  I was going to suggest that you should use the lsb init
function "log_warning_msg" but I see that xencommons does not
currently source /lib/lsb/init-functions.  But perhaps it should.

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0u4U-0008VQ-6E; Fri, 24 Feb 2012 12:16: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 1S0u4S-0008Uw-EZ
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:16:20 +0000
Received: from [85.158.139.83:5185] by server-1.bemta-5.messagelabs.com id
	86/A1-28458-39F774F4; Fri, 24 Feb 2012 12:16:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330085778!16458376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27449 invoked from network); 24 Feb 2012 12:16:18 -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;
	24 Feb 2012 12:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:15:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:15:15 +0000
Date: Fri, 24 Feb 2012 12:21:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330025374.10008.18.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1202241218230.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330025374.10008.18.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] arm: use r12 to pass the hypercall
	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

On Thu, 23 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > Use r12 to pass the hypercall number and r0-r4 for the hypercall
> > arguments as usual.
> 
> Strictly speaking "as usual" in the ARM calling convention would be args
> in r0-r3 and the fifth (and subsequent) arguments on the stack. However
> we are free to implement our own convention for hypercalls and avoiding
> arguments on the stack is a good idea.

Yes, you are right. I meant "as before" here.


> Please could you add a comment describing the interface. X86 documents
> this in xen/include/public/arch-x86/xen-x86_{32,64}.h so I suppose
> xen/include/public/arch-arm.h is appropriate

Good idea.


> We should define precisely which registers are clobbered by a hypercall.
> X86 clobbers exactly those arguments registers which are used for that
> hypercall but perhaps we can simplify and always clobber r0..r4,r12
> (plus any other caller saved registers in the usual calling convention,
> just for sanity). r0..r3,r12 are already clobbered in the normal calling
> convention so the only difference would be clobbering r4 which is
> normally callee saved (but is also not normally used to pass arguments).
> 
> We should explicitly clobber whatever we say we will too in a debug
> build.

OK

> I've trimmed the quote already so I'll mention it here instead:
> XEN_HYPERCALL_TAG should be defined in the public interface too not in
> the private asm headers.

Sure


> > @@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
> >  {
> >      local_irq_enable();
> >  
> > -    regs->r0 = arm_hypercall_table[iss](regs->r0,
> > +    if ( iss != XEN_HYPERCALL_TAG  ) {
> > +        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
> > +                __LINE__ , iss);
> 
> 	regs->r0 = -EINVAL;
> 
> here I think.

yes, we need that


> > +        return;
> > +    }
> > +
> > +    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,
> 
> It's an existing issue but we need to check that
> arm_hypercall_table[regs->r12] is non-NULL here and return -ENOSYS (by
> setting r0) if it is.

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 Fri Feb 24 12:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0u4U-0008VQ-6E; Fri, 24 Feb 2012 12:16: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 1S0u4S-0008Uw-EZ
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:16:20 +0000
Received: from [85.158.139.83:5185] by server-1.bemta-5.messagelabs.com id
	86/A1-28458-39F774F4; Fri, 24 Feb 2012 12:16:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330085778!16458376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27449 invoked from network); 24 Feb 2012 12:16:18 -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;
	24 Feb 2012 12:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:15:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:15:15 +0000
Date: Fri, 24 Feb 2012 12:21:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330025374.10008.18.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1202241218230.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330025374.10008.18.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] arm: use r12 to pass the hypercall
	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

On Thu, 23 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > Use r12 to pass the hypercall number and r0-r4 for the hypercall
> > arguments as usual.
> 
> Strictly speaking "as usual" in the ARM calling convention would be args
> in r0-r3 and the fifth (and subsequent) arguments on the stack. However
> we are free to implement our own convention for hypercalls and avoiding
> arguments on the stack is a good idea.

Yes, you are right. I meant "as before" here.


> Please could you add a comment describing the interface. X86 documents
> this in xen/include/public/arch-x86/xen-x86_{32,64}.h so I suppose
> xen/include/public/arch-arm.h is appropriate

Good idea.


> We should define precisely which registers are clobbered by a hypercall.
> X86 clobbers exactly those arguments registers which are used for that
> hypercall but perhaps we can simplify and always clobber r0..r4,r12
> (plus any other caller saved registers in the usual calling convention,
> just for sanity). r0..r3,r12 are already clobbered in the normal calling
> convention so the only difference would be clobbering r4 which is
> normally callee saved (but is also not normally used to pass arguments).
> 
> We should explicitly clobber whatever we say we will too in a debug
> build.

OK

> I've trimmed the quote already so I'll mention it here instead:
> XEN_HYPERCALL_TAG should be defined in the public interface too not in
> the private asm headers.

Sure


> > @@ -409,16 +408,17 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
> >  {
> >      local_irq_enable();
> >  
> > -    regs->r0 = arm_hypercall_table[iss](regs->r0,
> > +    if ( iss != XEN_HYPERCALL_TAG  ) {
> > +        printk("%s %d: received an alien hypercall iss=%lx\n", __func__ ,
> > +                __LINE__ , iss);
> 
> 	regs->r0 = -EINVAL;
> 
> here I think.

yes, we need that


> > +        return;
> > +    }
> > +
> > +    regs->r0 = arm_hypercall_table[regs->r12](regs->r0,
> 
> It's an existing issue but we need to check that
> arm_hypercall_table[regs->r12] is non-NULL here and return -ENOSYS (by
> setting r0) if it is.

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 Fri Feb 24 12:18:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0u5r-00008o-LS; Fri, 24 Feb 2012 12:17:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0u5q-00008O-Iu
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:17:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330085859!15707703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27902 invoked from network); 24 Feb 2012 12:17: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;
	24 Feb 2012 12:17:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:17:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:17:38 +0000
Date: Fri, 24 Feb 2012 12:23:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F4770AD.6040703@citrix.com>
Message-ID: <alpine.DEB.2.00.1202241221440.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F4770AD.6040703@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"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>,
	"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-WIP 07/13] 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, 24 Feb 2012, David Vrabel wrote:
> On 23/02/12 17:48, Stefano Stabellini wrote:
> > Compile events.c and use IRQ 32 to receive events notifications.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> > +#ifdef CONFIG_ARM
> > +#define IRQ_EVTCHN_CALLBACK 63
> > +irqreturn_t xen_arm_callback(int irq, void *arg)
> > +{
> > +	__xen_evtchn_do_upcall();
> > +	return 0;
> > +}
> > +
> > +int __init xen_init_IRQ_arm(void)
> > +{
> > +	int rc;
> > +	xen_init_IRQ();
> > +	rc = request_irq(IRQ_EVTCHN_CALLBACK, xen_arm_callback,
> > +			IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
> > +			"events", "events");	
> > +	if (rc) {
> > +		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
> > +	}
> > +	return rc;
> > +}
> > +core_initcall(xen_init_IRQ_arm);
> > +#endif
> 
> You should (eventually) have a device tree binding for the event channel
> and use a OF (device tree) device driver instead of this core_initcall()
> to register the handler etc.
 
Yes, that is the idea, once we have better device tree support in Xen.
We should also pass the IRQ number to be used as event injection
mechanism through the device tree.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:18:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0u5r-00008o-LS; Fri, 24 Feb 2012 12:17:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0u5q-00008O-Iu
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:17:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330085859!15707703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27902 invoked from network); 24 Feb 2012 12:17: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;
	24 Feb 2012 12:17:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:17:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:17:38 +0000
Date: Fri, 24 Feb 2012 12:23:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F4770AD.6040703@citrix.com>
Message-ID: <alpine.DEB.2.00.1202241221440.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F4770AD.6040703@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"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>,
	"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-WIP 07/13] 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, 24 Feb 2012, David Vrabel wrote:
> On 23/02/12 17:48, Stefano Stabellini wrote:
> > Compile events.c and use IRQ 32 to receive events notifications.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> > +#ifdef CONFIG_ARM
> > +#define IRQ_EVTCHN_CALLBACK 63
> > +irqreturn_t xen_arm_callback(int irq, void *arg)
> > +{
> > +	__xen_evtchn_do_upcall();
> > +	return 0;
> > +}
> > +
> > +int __init xen_init_IRQ_arm(void)
> > +{
> > +	int rc;
> > +	xen_init_IRQ();
> > +	rc = request_irq(IRQ_EVTCHN_CALLBACK, xen_arm_callback,
> > +			IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
> > +			"events", "events");	
> > +	if (rc) {
> > +		printk(KERN_ERR "Error requesting IRQ %d\n", IRQ_EVTCHN_CALLBACK);
> > +	}
> > +	return rc;
> > +}
> > +core_initcall(xen_init_IRQ_arm);
> > +#endif
> 
> You should (eventually) have a device tree binding for the event channel
> and use a OF (device tree) device driver instead of this core_initcall()
> to register the handler etc.
 
Yes, that is the idea, once we have better device tree support in Xen.
We should also pass the IRQ number to be used as event injection
mechanism through the device tree.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:19:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:19:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0u6l-0000E1-3J; Fri, 24 Feb 2012 12:18: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 1S0u6j-0000Dr-G6
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:18:41 +0000
Received: from [85.158.139.83:16196] by server-9.bemta-5.messagelabs.com id
	2D/0F-30171-020874F4; Fri, 24 Feb 2012 12:18:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330085919!12627910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 528 invoked from network); 24 Feb 2012 12:18:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:18:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:18:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:18:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0u6h-0006XO-Bb; Fri, 24 Feb 2012 12:18:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0u6h-0001fQ-Ai;
	Fri, 24 Feb 2012 12:18:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.32799.308331.653289@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 12:18:39 +0000
To: Jim Fehlig <jfehlig@suse.com>,
    Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <4F4560BC.30002@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.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>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jim Fehlig writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> is that libxl.h includes <xen/sysctl.h>, which has this
> 
> #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> #error "sysctl operations are intended for use by node control tools only"
> #endif
> 
> Without the defines, Bamvor is hitting the #error directive.

I see.  Hmm.  I have investigated further and:

xl.c contained #include <xenctrl.h> which is definitely very wrong.
when I
 (a) #undef __XEN_TOOLS__ at the top of xl.c
 (b) remove that
I can reproduce the error in-tree.

I'm unsure as to whether we should expect libxl callers include
<xen/sysctl.h>.  I think my view is that including these Xen public
headers for things like Xen sysctl numbers, scheduler parameter
numbers, etc., is fine.  Ian, what do you think ?

But we definitely need to do something to stop libxl callers,
including xl, including xenctrl.h.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:19:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:19:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0u6l-0000E1-3J; Fri, 24 Feb 2012 12:18: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 1S0u6j-0000Dr-G6
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:18:41 +0000
Received: from [85.158.139.83:16196] by server-9.bemta-5.messagelabs.com id
	2D/0F-30171-020874F4; Fri, 24 Feb 2012 12:18:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330085919!12627910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 528 invoked from network); 24 Feb 2012 12:18:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:18:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:18:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:18:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0u6h-0006XO-Bb; Fri, 24 Feb 2012 12:18:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0u6h-0001fQ-Ai;
	Fri, 24 Feb 2012 12:18:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.32799.308331.653289@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 12:18:39 +0000
To: Jim Fehlig <jfehlig@suse.com>,
    Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <4F4560BC.30002@suse.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.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>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jim Fehlig writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> is that libxl.h includes <xen/sysctl.h>, which has this
> 
> #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> #error "sysctl operations are intended for use by node control tools only"
> #endif
> 
> Without the defines, Bamvor is hitting the #error directive.

I see.  Hmm.  I have investigated further and:

xl.c contained #include <xenctrl.h> which is definitely very wrong.
when I
 (a) #undef __XEN_TOOLS__ at the top of xl.c
 (b) remove that
I can reproduce the error in-tree.

I'm unsure as to whether we should expect libxl callers include
<xen/sysctl.h>.  I think my view is that including these Xen public
headers for things like Xen sysctl numbers, scheduler parameter
numbers, etc., is fine.  Ian, what do you think ?

But we definitely need to do something to stop libxl callers,
including xl, including xenctrl.h.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0uHw-0000cj-Gj; Fri, 24 Feb 2012 12:30:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0uHu-0000ce-VR
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:30:15 +0000
Received: from [85.158.139.83:43281] by server-4.bemta-5.messagelabs.com id
	BB/D5-10788-6D2874F4; Fri, 24 Feb 2012 12:30:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330086611!16517724!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13090 invoked from network); 24 Feb 2012 12:30:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:30:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:30:08 +0000
Date: Fri, 24 Feb 2012 12:36:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330080047.8557.167.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202241225290.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330080047.8557.167.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 3/5] arm: set the default dom0 max_vcpus
 value to 1 (currently is 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 Fri, 24 Feb 2012, Ian Campbell wrote:
> From 7c66c893c5fbf485bc9071b9ef14680475b91670 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 24 Feb 2012 10:36:42 +0000
> Subject: [PATCH] arm: handle dom0_max_vcpus=0 case properly
> 
> Also use xzalloc_array.

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index ec5a9f3..4efe07d 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -15,13 +15,14 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>  
>  struct vcpu *__init alloc_dom0_vcpu0(void)
>  {
> -    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
> +    if ( opt_dom0_max_vcpus == 0 )
> +        opt_dom0_max_vcpus = num_online_cpus();
> +    if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
> +        opt_dom0_max_vcpus = MAX_VIRT_CPUS;
> +
> +    dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
>      if ( !dom0->vcpu )
> -    {
> -            printk("failed to alloc dom0->vccpu\n");
>          return NULL;
> -    }
> -    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
>      dom0->max_vcpus = opt_dom0_max_vcpus;
>  
>      return alloc_vcpu(dom0, 0, 0);
> -- 
> 1.7.2.5
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0uHw-0000cj-Gj; Fri, 24 Feb 2012 12:30:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0uHu-0000ce-VR
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:30:15 +0000
Received: from [85.158.139.83:43281] by server-4.bemta-5.messagelabs.com id
	BB/D5-10788-6D2874F4; Fri, 24 Feb 2012 12:30:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330086611!16517724!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13090 invoked from network); 24 Feb 2012 12:30:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10917984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:30:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:30:08 +0000
Date: Fri, 24 Feb 2012 12:36:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330080047.8557.167.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202241225290.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330080047.8557.167.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 3/5] arm: set the default dom0 max_vcpus
 value to 1 (currently is 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 Fri, 24 Feb 2012, Ian Campbell wrote:
> From 7c66c893c5fbf485bc9071b9ef14680475b91670 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 24 Feb 2012 10:36:42 +0000
> Subject: [PATCH] arm: handle dom0_max_vcpus=0 case properly
> 
> Also use xzalloc_array.

ack

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index ec5a9f3..4efe07d 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -15,13 +15,14 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>  
>  struct vcpu *__init alloc_dom0_vcpu0(void)
>  {
> -    dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
> +    if ( opt_dom0_max_vcpus == 0 )
> +        opt_dom0_max_vcpus = num_online_cpus();
> +    if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
> +        opt_dom0_max_vcpus = MAX_VIRT_CPUS;
> +
> +    dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
>      if ( !dom0->vcpu )
> -    {
> -            printk("failed to alloc dom0->vccpu\n");
>          return NULL;
> -    }
> -    memset(dom0->vcpu, 0, opt_dom0_max_vcpus * sizeof(*dom0->vcpu));
>      dom0->max_vcpus = opt_dom0_max_vcpus;
>  
>      return alloc_vcpu(dom0, 0, 0);
> -- 
> 1.7.2.5
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:40:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0uR3-0000me-HB; Fri, 24 Feb 2012 12:39:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0uR1-0000mZ-CX
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:39:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330087173!9974551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23516 invoked from network); 24 Feb 2012 12:39:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:39:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:39:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:39:33 +0000
Date: Fri, 24 Feb 2012 12:45:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1330080608338-5512352.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202241243550.23091@kaball-desktop>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
	<1329987975739-5507438.post@n5.nabble.com>
	<1330080608338-5512352.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
 Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 24 Feb 2012, Fantu wrote:
> Does Xen and all of its parts (include qemu upstream) has debug on build-time
> enabled by default or must be enabled?

Yes, they are enabled by default.
Unfortunately from the log you posted in the previous email I am not
sure what could cause QEMU to fail opening the unix socket in
/var/run/xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:40:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0uR3-0000me-HB; Fri, 24 Feb 2012 12:39:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0uR1-0000mZ-CX
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:39:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330087173!9974551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23516 invoked from network); 24 Feb 2012 12:39:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:39:33 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:39:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 12:39:33 +0000
Date: Fri, 24 Feb 2012 12:45:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1330080608338-5512352.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202241243550.23091@kaball-desktop>
References: <1329924493728-5505409.post@n5.nabble.com>
	<alpine.DEB.2.00.1202221700220.23091@kaball-desktop>
	<1329986957327-5507375.post@n5.nabble.com>
	<1329987508.8557.23.camel@zakaz.uk.xensource.com>
	<1329987975739-5507438.post@n5.nabble.com>
	<1330080608338-5512352.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen-unstable: Qemu upstream domUs not start on
 Wheezy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 24 Feb 2012, Fantu wrote:
> Does Xen and all of its parts (include qemu upstream) has debug on build-time
> enabled by default or must be enabled?

Yes, they are enabled by default.
Unfortunately from the log you posted in the previous email I am not
sure what could cause QEMU to fail opening the unix socket in
/var/run/xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0uTU-0000sU-2d; Fri, 24 Feb 2012 12:42:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0uTT-0000sF-9t
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:42:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330087324!9531452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1634 invoked from network); 24 Feb 2012 12:42:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:42:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:42:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 12:42:04 +0000
Message-ID: <1330087322.8557.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 12:42:02 +0000
In-Reply-To: <20295.32799.308331.653289@mariner.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<20295.32799.308331.653289@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 12:18 +0000, Ian Jackson wrote:
> Jim Fehlig writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > is that libxl.h includes <xen/sysctl.h>, which has this
> > 
> > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > #error "sysctl operations are intended for use by node control tools only"
> > #endif
> > 
> > Without the defines, Bamvor is hitting the #error directive.
> 
> I see.  Hmm.  I have investigated further and:
> 
> xl.c contained #include <xenctrl.h> which is definitely very wrong.
> when I
>  (a) #undef __XEN_TOOLS__ at the top of xl.c
>  (b) remove that
> I can reproduce the error in-tree.

Doing this with the two patches I sent yesterday works. (I resewnt them
at the head of my repost of the "libxl: improved handling for default
values in API" series.

We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.

-D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?

> I'm unsure as to whether we should expect libxl callers include
> <xen/sysctl.h>.  I think my view is that including these Xen public
> headers for things like Xen sysctl numbers, scheduler parameter
> numbers, etc., is fine.  Ian, what do you think ?
> 
> But we definitely need to do something to stop libxl callers,
> including xl, including xenctrl.h.

We can stop xl by just not doing it (TM), for other callers of libxl --
well, we say you shouldn't need it for toolstack operations and that
libxl should provide all the functionality but if they _really_ want to
ignore that...

Also a toolstack may have functionality which is not considered
"toolstack functionality" per the remit of libxl and for which they wish
to use xenctrl directly. e.g. perhaps they communicate with a guest
agent using their own shared ring protocol for which they require the
ability to map domain memory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0uTU-0000sU-2d; Fri, 24 Feb 2012 12:42:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0uTT-0000sF-9t
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:42:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330087324!9531452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1634 invoked from network); 24 Feb 2012 12:42:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:42:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:42:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 12:42:04 +0000
Message-ID: <1330087322.8557.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 12:42:02 +0000
In-Reply-To: <20295.32799.308331.653289@mariner.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<20295.32799.308331.653289@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 12:18 +0000, Ian Jackson wrote:
> Jim Fehlig writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > The libvirt libxl driver doesn't use libxc directly. AFAICT, the problem
> > is that libxl.h includes <xen/sysctl.h>, which has this
> > 
> > #if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > #error "sysctl operations are intended for use by node control tools only"
> > #endif
> > 
> > Without the defines, Bamvor is hitting the #error directive.
> 
> I see.  Hmm.  I have investigated further and:
> 
> xl.c contained #include <xenctrl.h> which is definitely very wrong.
> when I
>  (a) #undef __XEN_TOOLS__ at the top of xl.c
>  (b) remove that
> I can reproduce the error in-tree.

Doing this with the two patches I sent yesterday works. (I resewnt them
at the head of my repost of the "libxl: improved handling for default
values in API" series.

We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.

-D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?

> I'm unsure as to whether we should expect libxl callers include
> <xen/sysctl.h>.  I think my view is that including these Xen public
> headers for things like Xen sysctl numbers, scheduler parameter
> numbers, etc., is fine.  Ian, what do you think ?
> 
> But we definitely need to do something to stop libxl callers,
> including xl, including xenctrl.h.

We can stop xl by just not doing it (TM), for other callers of libxl --
well, we say you shouldn't need it for toolstack operations and that
libxl should provide all the functionality but if they _really_ want to
ignore that...

Also a toolstack may have functionality which is not considered
"toolstack functionality" per the remit of libxl and for which they wish
to use xenctrl directly. e.g. perhaps they communicate with a guest
agent using their own shared ring protocol for which they require the
ability to map domain memory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:47:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0uYH-0001Fp-PN; Fri, 24 Feb 2012 12:47:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0uYG-0001F6-2W
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:47:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330087621!2485801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6606 invoked from network); 24 Feb 2012 12:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:47:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 12:47:01 +0000
Message-ID: <1330087619.8557.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 12:46:59 +0000
In-Reply-To: <1330078948.8557.158.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330078948.8557.158.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
 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

> > @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
> >      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> >  }
> >  
> > +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> > +        unsigned long mfn)

Should these be either paddr_t or xen_pfn_t?

> > +{
> > +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> > +                              (gpfn + 1) << PAGE_SHIFT,
> > +                              mfn << PAGE_SHIFT);

As it stands you need to cast to paddr_t first so the shift won't
overflow.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 12:47:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 12: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 1S0uYH-0001Fp-PN; Fri, 24 Feb 2012 12:47:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0uYG-0001F6-2W
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 12:47:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330087621!2485801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6606 invoked from network); 24 Feb 2012 12:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 12:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 12:47:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 12:47:01 +0000
Message-ID: <1330087619.8557.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 12:46:59 +0000
In-Reply-To: <1330078948.8557.158.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330078948.8557.158.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
 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

> > @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
> >      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> >  }
> >  
> > +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> > +        unsigned long mfn)

Should these be either paddr_t or xen_pfn_t?

> > +{
> > +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> > +                              (gpfn + 1) << PAGE_SHIFT,
> > +                              mfn << PAGE_SHIFT);

As it stands you need to cast to paddr_t first so the shift won't
overflow.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 13:04:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0up1-0001VB-ME; Fri, 24 Feb 2012 13:04:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0uoz-0001V6-Og
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 13:04:26 +0000
Received: from [85.158.139.83:62847] by server-7.bemta-5.messagelabs.com id
	4A/9C-16195-9DA874F4; Fri, 24 Feb 2012 13:04:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330088664!12636231!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26462 invoked from network); 24 Feb 2012 13:04:24 -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;
	24 Feb 2012 13:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 13:04:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 13:04:23 +0000
Message-ID: <1330088662.8557.201.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 13:04:22 +0000
In-Reply-To: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Allocate the shared_info page at domain creation.
> 
> Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c     |    8 ++++
>  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/p2m.c        |   15 ++++++-
>  xen/include/asm-arm/mm.h  |    4 ++
>  xen/include/asm-arm/p2m.h |    2 +
>  5 files changed, 122 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0b55934..0ee96b9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    rc = -ENOMEM;
> +    if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> +        goto fail;

No reason to limit this to 32 bit (I think).

Also you can avoid it in the idle domain case.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 13:04:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 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 1S0up1-0001VB-ME; Fri, 24 Feb 2012 13:04:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0uoz-0001V6-Og
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 13:04:26 +0000
Received: from [85.158.139.83:62847] by server-7.bemta-5.messagelabs.com id
	4A/9C-16195-9DA874F4; Fri, 24 Feb 2012 13:04:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330088664!12636231!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26462 invoked from network); 24 Feb 2012 13:04:24 -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;
	24 Feb 2012 13:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="10918799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 13:04:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 13:04:23 +0000
Message-ID: <1330088662.8557.201.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 13:04:22 +0000
In-Reply-To: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> Allocate the shared_info page at domain creation.
> 
> Implement arch_memory_op, only for XENMEM_add_to_physmap with space ==
> XENMAPSPACE_shared_info, so that the guest can map the shared_info page.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/domain.c     |    8 ++++
>  xen/arch/arm/mm.c         |   98 +++++++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/p2m.c        |   15 ++++++-
>  xen/include/asm-arm/mm.h  |    4 ++
>  xen/include/asm-arm/p2m.h |    2 +
>  5 files changed, 122 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 0b55934..0ee96b9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -235,6 +235,14 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
>      if ( (rc = p2m_init(d)) != 0 )
>          goto fail;
>  
> +    rc = -ENOMEM;
> +    if ( (d->shared_info = alloc_xenheap_pages(0, MEMF_bits(32))) == NULL )
> +        goto fail;

No reason to limit this to 32 bit (I think).

Also you can avoid it in the idle domain case.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 13:10:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 13:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0uuN-0001cx-HB; Fri, 24 Feb 2012 13:09:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0uuM-0001co-2p
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 13:09:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330088991!10544253!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4087 invoked from network); 24 Feb 2012 13:09:52 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 13:09:52 -0000
Received: by lahi5 with SMTP id i5so3583421lah.32
	for <xen-devel@lists.xen.org>; Fri, 24 Feb 2012 05:09:51 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.152.108.49 as permitted sender) client-ip=10.152.108.49; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.152.108.49 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.152.108.49])
	by 10.152.108.49 with SMTP id hh17mr1839093lab.0.1330088991337
	(num_hops = 1); Fri, 24 Feb 2012 05:09:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=UN2W/2v0tRNhDgDBHmE+q/meMKeEa+HSA90JgR28l8I=;
	b=nj8b4Y+S7YalyIhPOxXC3cNKJaEghuVuIScKoynuwe0fY0Sna2N9zta2tLvWMLsXbe
	rgWoSXKbf8MCpGNvSitVRX4K0H+VXqbrKgS51a+W1wkVgbM9481JoV0yfCCd6efIeYvG
	Ozy+ZTcqeBbjHHkXxDIMr0pXgZU4iJCBOi0wk=
MIME-Version: 1.0
Received: by 10.152.108.49 with SMTP id hh17mr1525937lab.0.1330088991276; Fri,
	24 Feb 2012 05:09:51 -0800 (PST)
Received: by 10.152.129.133 with HTTP; Fri, 24 Feb 2012 05:09:51 -0800 (PST)
In-Reply-To: <20295.32098.602480.91456@mariner.uk.xensource.com>
References: <patchbomb.1329815952@build.localdomain>
	<40f8487cacc807bb6f9d.1329815953@build.localdomain>
	<20295.32098.602480.91456@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 14:09:51 +0100
X-Google-Sender-Auth: 4f86qMYPhzjS9ZmGhFsvbZtOxJI
Message-ID: <CAPLaKK5tgick2FHOp1EvLnz8u5F=DNNPwg3t1B1ds6JOfiBRmQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Linux/init: check for brctl at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI0IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIDEgb2YgMl0gTGludXgvaW5pdDogY2hlY2sgZm9y
IGJyY3RsIGF0IHhlbmNvbW1vbnMiKToKPj4gTGludXgvaW5pdDogY2hlY2sgZm9yIGJyY3RsIGF0
IHhlbmNvbW1vbnMKPiAuLi4KPj4gKyMgQ2hlY2sgaWYgYnJjdGwgaXMgcHJlc2VudAo+PiAraGFz
aCBicmN0bCA+IC9kZXYvbnVsbCAyPiYxIHx8IGVjaG8gIldhcm5pbmc6IGJyY3RsIG5vdCBmb3Vu
ZCIKCih0aGlzIGlzIGEgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGUgcGF0Y2gsIHNlZQpodHRwOi8v
bGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAyL21zZzAyMTA4Lmh0
bWwgZm9yCnRoZSBuZXcgc2VyaWVzKQoKPiBJIHVzaW5nIHRoaW5rICJ0eXBlIiB3b3VsZCBiZSBt
b3JlIGlkb21hdGljIHRoYW4gImhhc2giLgoKT2ssIEkgd2lsbCByZXBsYWNlIGhhc2ggd2l0aCB0
eXBlCgo+IEkgdGhpbmsgdGhlIHdhcm5pbmcgbWVzc2FnZSBzaG91bGQgZ28gdG8gc3RkZXJyIGFu
ZCBtZW50aW9uCj4geGVuY29tbW9ucy4gwqBJIHdhcyBnb2luZyB0byBzdWdnZXN0IHRoYXQgeW91
IHNob3VsZCB1c2UgdGhlIGxzYiBpbml0Cj4gZnVuY3Rpb24gImxvZ193YXJuaW5nX21zZyIgYnV0
IEkgc2VlIHRoYXQgeGVuY29tbW9ucyBkb2VzIG5vdAo+IGN1cnJlbnRseSBzb3VyY2UgL2xpYi9s
c2IvaW5pdC1mdW5jdGlvbnMuIMKgQnV0IHBlcmhhcHMgaXQgc2hvdWxkLgoKSSB1c3VhbGx5IHVz
ZSBPcGVuUkMgdW5kZXIgTGludXgsIGFuZCBzaW5jZSBpdCBkb2Vzbid0IGxpa2UgdGhlIHN0b2Nr
CnhlbmNvbW1vbnMgZmlsZSBJIHVzZSBhIGN1c3RvbSBvbmUuIElmIHlvdSB0aGluayBpdCBpcyBv
ayB0byBpbmNsdWRlCi9saWIvbHNiL2luaXQtZnVuY3Rpb25zIEkgY2FuIHVwZGF0ZSB0aGUgc2Vy
aWVzIHRvIGluY2x1ZGUgdGhhdCBhbmQKbWFrZSB1c2Ugb2YgbG9nX3dhcm5pbmdfbXNnLgoKPiBo
dHRwOi8vcmVmc3BlY3MubGludXhmb3VuZGF0aW9uLm9yZy9MU0JfNC4xLjAvTFNCLUNvcmUtZ2Vu
ZXJpYy9MU0ItQ29yZS1nZW5lcmljL2luaXNjcnB0ZnVuYy5odG1sCj4KPiBJYW4uCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Feb 24 13:10:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 13:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0uuN-0001cx-HB; Fri, 24 Feb 2012 13:09:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S0uuM-0001co-2p
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 13:09:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330088991!10544253!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4087 invoked from network); 24 Feb 2012 13:09:52 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 13:09:52 -0000
Received: by lahi5 with SMTP id i5so3583421lah.32
	for <xen-devel@lists.xen.org>; Fri, 24 Feb 2012 05:09:51 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.152.108.49 as permitted sender) client-ip=10.152.108.49; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.152.108.49 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.152.108.49])
	by 10.152.108.49 with SMTP id hh17mr1839093lab.0.1330088991337
	(num_hops = 1); Fri, 24 Feb 2012 05:09:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=UN2W/2v0tRNhDgDBHmE+q/meMKeEa+HSA90JgR28l8I=;
	b=nj8b4Y+S7YalyIhPOxXC3cNKJaEghuVuIScKoynuwe0fY0Sna2N9zta2tLvWMLsXbe
	rgWoSXKbf8MCpGNvSitVRX4K0H+VXqbrKgS51a+W1wkVgbM9481JoV0yfCCd6efIeYvG
	Ozy+ZTcqeBbjHHkXxDIMr0pXgZU4iJCBOi0wk=
MIME-Version: 1.0
Received: by 10.152.108.49 with SMTP id hh17mr1525937lab.0.1330088991276; Fri,
	24 Feb 2012 05:09:51 -0800 (PST)
Received: by 10.152.129.133 with HTTP; Fri, 24 Feb 2012 05:09:51 -0800 (PST)
In-Reply-To: <20295.32098.602480.91456@mariner.uk.xensource.com>
References: <patchbomb.1329815952@build.localdomain>
	<40f8487cacc807bb6f9d.1329815953@build.localdomain>
	<20295.32098.602480.91456@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 14:09:51 +0100
X-Google-Sender-Auth: 4f86qMYPhzjS9ZmGhFsvbZtOxJI
Message-ID: <CAPLaKK5tgick2FHOp1EvLnz8u5F=DNNPwg3t1B1ds6JOfiBRmQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] Linux/init: check for brctl at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI0IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1BBVENIIDEgb2YgMl0gTGludXgvaW5pdDogY2hlY2sgZm9y
IGJyY3RsIGF0IHhlbmNvbW1vbnMiKToKPj4gTGludXgvaW5pdDogY2hlY2sgZm9yIGJyY3RsIGF0
IHhlbmNvbW1vbnMKPiAuLi4KPj4gKyMgQ2hlY2sgaWYgYnJjdGwgaXMgcHJlc2VudAo+PiAraGFz
aCBicmN0bCA+IC9kZXYvbnVsbCAyPiYxIHx8IGVjaG8gIldhcm5pbmc6IGJyY3RsIG5vdCBmb3Vu
ZCIKCih0aGlzIGlzIGEgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGUgcGF0Y2gsIHNlZQpodHRwOi8v
bGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDEyLTAyL21zZzAyMTA4Lmh0
bWwgZm9yCnRoZSBuZXcgc2VyaWVzKQoKPiBJIHVzaW5nIHRoaW5rICJ0eXBlIiB3b3VsZCBiZSBt
b3JlIGlkb21hdGljIHRoYW4gImhhc2giLgoKT2ssIEkgd2lsbCByZXBsYWNlIGhhc2ggd2l0aCB0
eXBlCgo+IEkgdGhpbmsgdGhlIHdhcm5pbmcgbWVzc2FnZSBzaG91bGQgZ28gdG8gc3RkZXJyIGFu
ZCBtZW50aW9uCj4geGVuY29tbW9ucy4gwqBJIHdhcyBnb2luZyB0byBzdWdnZXN0IHRoYXQgeW91
IHNob3VsZCB1c2UgdGhlIGxzYiBpbml0Cj4gZnVuY3Rpb24gImxvZ193YXJuaW5nX21zZyIgYnV0
IEkgc2VlIHRoYXQgeGVuY29tbW9ucyBkb2VzIG5vdAo+IGN1cnJlbnRseSBzb3VyY2UgL2xpYi9s
c2IvaW5pdC1mdW5jdGlvbnMuIMKgQnV0IHBlcmhhcHMgaXQgc2hvdWxkLgoKSSB1c3VhbGx5IHVz
ZSBPcGVuUkMgdW5kZXIgTGludXgsIGFuZCBzaW5jZSBpdCBkb2Vzbid0IGxpa2UgdGhlIHN0b2Nr
CnhlbmNvbW1vbnMgZmlsZSBJIHVzZSBhIGN1c3RvbSBvbmUuIElmIHlvdSB0aGluayBpdCBpcyBv
ayB0byBpbmNsdWRlCi9saWIvbHNiL2luaXQtZnVuY3Rpb25zIEkgY2FuIHVwZGF0ZSB0aGUgc2Vy
aWVzIHRvIGluY2x1ZGUgdGhhdCBhbmQKbWFrZSB1c2Ugb2YgbG9nX3dhcm5pbmdfbXNnLgoKPiBo
dHRwOi8vcmVmc3BlY3MubGludXhmb3VuZGF0aW9uLm9yZy9MU0JfNC4xLjAvTFNCLUNvcmUtZ2Vu
ZXJpYy9MU0ItQ29yZS1nZW5lcmljL2luaXNjcnB0ZnVuYy5odG1sCj4KPiBJYW4uCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Feb 24 13:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 13:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0vTM-0001xh-MY; Fri, 24 Feb 2012 13:46:08 +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 1S0vTK-0001xc-Ny
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 13:46:07 +0000
Received: from [85.158.139.83:11977] by server-11.bemta-5.messagelabs.com id
	63/60-14397-E94974F4; Fri, 24 Feb 2012 13:46:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330091164!16531284!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30716 invoked from network); 24 Feb 2012 13:46:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Feb 2012 13:46:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330091164; l=5371;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=SkDfj/y2Nts9MnJZzUcz3RVSDQc=;
	b=fYjCf0dmtdTv4EfAqxzSW91AnPFUtaoGrahCgIQVQaqrrJGLu0aHij118PxRuIBFKrd
	LdhBVH6lVUYM2W853BepQrwN0U8fe1q5HFrm4ab/V1yoNvEqx4369EFlBw1d0GOgrm7n1
	7TPEr0oLLicFBXaVDAShpkH2/GHJSC7vTMw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69n6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-11.vodafone-net.de [80.226.24.11])
	by smtp.strato.de (fruni mo50) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z031beo1ODKfD3 ;
	Fri, 24 Feb 2012 14:45:47 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E46EF18638; Fri, 24 Feb 2012 14:45:44 +0100 (CET)
Date: Fri, 24 Feb 2012 14:45:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120224134544.GA13134@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Tim Deegan wrote:

> This is based on an earlier RFC patch by Olaf Hering, but heavily
> simplified (removing a per-gfn queue of waiting vcpus in favour of
> a scan of all vcpus on page-in).

Tim, thanks for that work. From just reading the change it looks ok.

A few comments below:

> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:09 2012 +0000
> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
>      }
>  
>      /* For now only perform locking on hap domains */
> -    if ( locked && (hap_enabled(p2m->domain)) )
> +    locked = locked && hap_enabled(p2m->domain);
> +
> +#ifdef __x86_64__
> +again:
> +#endif
> +    if ( locked )
>          /* Grab the lock here, don't release until put_gfn */
>          gfn_lock(p2m, gfn, 0);
>  
>      mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>  
>  #ifdef __x86_64__
> +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> +         && p2m->domain == current->domain ) 
> +    {
> +        if ( locked )
> +            gfn_unlock(p2m, gfn, 0);
> +
> +        /* Ping the pager */
> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> +            p2m_mem_paging_populate(p2m->domain, gfn);
> +
> +        /* Wait until the pager finishes paging it in */
> +        current->arch.mem_paging_gfn = gfn;
> +        wait_event(current->arch.mem_paging_wq, ({
> +                    int done;
> +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> +                    done = (*t != p2m_ram_paging_in);

I assume p2m_mem_paging_populate() will not return until the state is
forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
more obvious what this check is supposed to do.

> +                    /* Safety catch: it _should_ be safe to wait here
> +                     * but if it's not, crash the VM, not the host */
> +                    if ( in_atomic() )
> +                    {
> +                        WARN();
> +                        domain_crash(p2m->domain);
> +                        done = 1;
> +                    }
> +                    done;
> +                }));
> +        goto again;
> +    }
> +#endif
> +
> +#ifdef __x86_64__
>      if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
> @@ -946,17 +982,17 @@ void p2m_mem_paging_drop_page(struct dom
>   * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
>   * paging types because the gfn may not be backed by a mfn.
>   *
> - * The gfn can be in any of the paging states, but the pager needs only be
> - * notified when the gfn is in the paging-out path (paging_out or paged).  This
> - * function may be called more than once from several vcpus. If the vcpu belongs
> - * to the guest, the vcpu must be stopped and the pager notified that the vcpu
> - * was stopped. The pager needs to handle several requests for the same gfn.
> + * The gfn can be in any of the paging states, but the pager needs only
> + * be notified when the gfn is in the paging-out path (paging_out or
> + * paged).  This function may be called more than once from several
> + * vcpus.  The pager needs to handle several requests for the same gfn.
>   *
> - * If the gfn is not in the paging-out path and the vcpu does not belong to the
> - * guest, nothing needs to be done and the function assumes that a request was
> - * already sent to the pager. In this case the caller has to try again until the
> - * gfn is fully paged in again.
> + * If the gfn is not in the paging-out path nothing needs to be done and
> + * the function assumes that a request was already sent to the pager.
> + * In this case the caller has to try again until the gfn is fully paged
> + * in again.
>   */
> +
>  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
> @@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int send_request = 0;

Is that variable supposed to be used?
Perhaps the feature to fast-forward (or rollback) from
p2m_ram_paging_out to p2m_ram_rw could be a separate patch. My initial
version of this patch did not have a strict requirement for this
feature, if I remember correctly.

>      /* We're paging. There should be a ring */
>      int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> @@ -987,19 +1024,22 @@ void p2m_mem_paging_populate(struct doma
>          /* Evict will fail now, tag this request for pager */
>          if ( p2mt == p2m_ram_paging_out )
>              req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
> -
> -        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> +        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain == d )
> +            /* Short-cut back to paged-in state (but not for foreign 
> +             * mappings, or the pager couldn't map it to page it out) */
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> +                          paging_mode_log_dirty(d) 
> +                          ? p2m_ram_logdirty : p2m_ram_rw, a);
> +        else
> +        {
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> +            send_request = 1;
> +        }
>      }
>      gfn_unlock(p2m, gfn, 0);
>  
> -    /* Pause domain if request came from guest and gfn has paging type */
> -    if ( p2m_is_paging(p2mt) && v->domain == d )
> -    {
> -        vcpu_pause_nosync(v);
> -        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> -    }
>      /* No need to inform pager if the gfn is not in the page-out path */
> -    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
> +    if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
>          mem_event_cancel_slot(d, &d->mem_event->paging);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 13:46:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 13:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0vTM-0001xh-MY; Fri, 24 Feb 2012 13:46:08 +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 1S0vTK-0001xc-Ny
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 13:46:07 +0000
Received: from [85.158.139.83:11977] by server-11.bemta-5.messagelabs.com id
	63/60-14397-E94974F4; Fri, 24 Feb 2012 13:46:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330091164!16531284!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30716 invoked from network); 24 Feb 2012 13:46:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Feb 2012 13:46:05 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330091164; l=5371;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=SkDfj/y2Nts9MnJZzUcz3RVSDQc=;
	b=fYjCf0dmtdTv4EfAqxzSW91AnPFUtaoGrahCgIQVQaqrrJGLu0aHij118PxRuIBFKrd
	LdhBVH6lVUYM2W853BepQrwN0U8fe1q5HFrm4ab/V1yoNvEqx4369EFlBw1d0GOgrm7n1
	7TPEr0oLLicFBXaVDAShpkH2/GHJSC7vTMw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69n6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-11.vodafone-net.de [80.226.24.11])
	by smtp.strato.de (fruni mo50) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z031beo1ODKfD3 ;
	Fri, 24 Feb 2012 14:45:47 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E46EF18638; Fri, 24 Feb 2012 14:45:44 +0100 (CET)
Date: Fri, 24 Feb 2012 14:45:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120224134544.GA13134@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Tim Deegan wrote:

> This is based on an earlier RFC patch by Olaf Hering, but heavily
> simplified (removing a per-gfn queue of waiting vcpus in favour of
> a scan of all vcpus on page-in).

Tim, thanks for that work. From just reading the change it looks ok.

A few comments below:

> +++ b/xen/arch/x86/mm/p2m.c	Thu Feb 23 16:18:09 2012 +0000
> @@ -160,13 +160,49 @@ mfn_t __get_gfn_type_access(struct p2m_d
>      }
>  
>      /* For now only perform locking on hap domains */
> -    if ( locked && (hap_enabled(p2m->domain)) )
> +    locked = locked && hap_enabled(p2m->domain);
> +
> +#ifdef __x86_64__
> +again:
> +#endif
> +    if ( locked )
>          /* Grab the lock here, don't release until put_gfn */
>          gfn_lock(p2m, gfn, 0);
>  
>      mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order);
>  
>  #ifdef __x86_64__
> +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> +         && p2m->domain == current->domain ) 
> +    {
> +        if ( locked )
> +            gfn_unlock(p2m, gfn, 0);
> +
> +        /* Ping the pager */
> +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> +            p2m_mem_paging_populate(p2m->domain, gfn);
> +
> +        /* Wait until the pager finishes paging it in */
> +        current->arch.mem_paging_gfn = gfn;
> +        wait_event(current->arch.mem_paging_wq, ({
> +                    int done;
> +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> +                    done = (*t != p2m_ram_paging_in);

I assume p2m_mem_paging_populate() will not return until the state is
forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
more obvious what this check is supposed to do.

> +                    /* Safety catch: it _should_ be safe to wait here
> +                     * but if it's not, crash the VM, not the host */
> +                    if ( in_atomic() )
> +                    {
> +                        WARN();
> +                        domain_crash(p2m->domain);
> +                        done = 1;
> +                    }
> +                    done;
> +                }));
> +        goto again;
> +    }
> +#endif
> +
> +#ifdef __x86_64__
>      if ( (q & P2M_UNSHARE) && p2m_is_shared(*t) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
> @@ -946,17 +982,17 @@ void p2m_mem_paging_drop_page(struct dom
>   * This function needs to be called whenever gfn_to_mfn() returns any of the p2m
>   * paging types because the gfn may not be backed by a mfn.
>   *
> - * The gfn can be in any of the paging states, but the pager needs only be
> - * notified when the gfn is in the paging-out path (paging_out or paged).  This
> - * function may be called more than once from several vcpus. If the vcpu belongs
> - * to the guest, the vcpu must be stopped and the pager notified that the vcpu
> - * was stopped. The pager needs to handle several requests for the same gfn.
> + * The gfn can be in any of the paging states, but the pager needs only
> + * be notified when the gfn is in the paging-out path (paging_out or
> + * paged).  This function may be called more than once from several
> + * vcpus.  The pager needs to handle several requests for the same gfn.
>   *
> - * If the gfn is not in the paging-out path and the vcpu does not belong to the
> - * guest, nothing needs to be done and the function assumes that a request was
> - * already sent to the pager. In this case the caller has to try again until the
> - * gfn is fully paged in again.
> + * If the gfn is not in the paging-out path nothing needs to be done and
> + * the function assumes that a request was already sent to the pager.
> + * In this case the caller has to try again until the gfn is fully paged
> + * in again.
>   */
> +
>  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
> @@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int send_request = 0;

Is that variable supposed to be used?
Perhaps the feature to fast-forward (or rollback) from
p2m_ram_paging_out to p2m_ram_rw could be a separate patch. My initial
version of this patch did not have a strict requirement for this
feature, if I remember correctly.

>      /* We're paging. There should be a ring */
>      int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> @@ -987,19 +1024,22 @@ void p2m_mem_paging_populate(struct doma
>          /* Evict will fail now, tag this request for pager */
>          if ( p2mt == p2m_ram_paging_out )
>              req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
> -
> -        set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> +        if ( p2mt == p2m_ram_paging_out && mfn_valid(mfn) && v->domain == d )
> +            /* Short-cut back to paged-in state (but not for foreign 
> +             * mappings, or the pager couldn't map it to page it out) */
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
> +                          paging_mode_log_dirty(d) 
> +                          ? p2m_ram_logdirty : p2m_ram_rw, a);
> +        else
> +        {
> +            set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> +            send_request = 1;
> +        }
>      }
>      gfn_unlock(p2m, gfn, 0);
>  
> -    /* Pause domain if request came from guest and gfn has paging type */
> -    if ( p2m_is_paging(p2mt) && v->domain == d )
> -    {
> -        vcpu_pause_nosync(v);
> -        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> -    }
>      /* No need to inform pager if the gfn is not in the page-out path */
> -    else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
> +    if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
>          mem_event_cancel_slot(d, &d->mem_event->paging);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 14:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 14:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0vpi-0002HT-L5; Fri, 24 Feb 2012 14:09:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0vph-0002HL-BR
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 14:09:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330092547!3983794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22686 invoked from network); 24 Feb 2012 14:09: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;
	24 Feb 2012 14:09:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10921009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 14:09:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 14:09:07 +0000
Date: Fri, 24 Feb 2012 14:15:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F476C0E.2010107@citrix.com>
Message-ID: <alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
	<4F476C0E.2010107@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"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 v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 24 Feb 2012, David Vrabel wrote:
> On 24/02/12 10:33, Ian Campbell wrote:
> > On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> >> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> >> we reserve for Xen usage.
> > 
> > Does this require a trap when the guest acks or EOIs this interrupt?
> > What about maintenance interrupts arising from injecting this?

Yes, we would get a maintenance interrupt in the hypervisor every time
the guest EOI's it.


> > Might we want to instead inject this interrupt as an SGI, so that it
> > appears as a per-VCPU interrupt?
> 
> I don't think it's possible to register a SGI handler in Linux
> currently.  The mapping of IRQ numbers to GIC interrupts skips over the
> SGIs.  This would be easy to fix I think.

A per-vcpu interrupt that doesn't require an EOI would be ideal, however
like David wrote, it is not possible to register an SGI handler in Linux
at the moment. I'll give it a look though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 14:09:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 14:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0vpi-0002HT-L5; Fri, 24 Feb 2012 14:09:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S0vph-0002HL-BR
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 14:09:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330092547!3983794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22686 invoked from network); 24 Feb 2012 14:09: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;
	24 Feb 2012 14:09:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10921009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 14:09:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 14:09:07 +0000
Date: Fri, 24 Feb 2012 14:15:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F476C0E.2010107@citrix.com>
Message-ID: <alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
	<4F476C0E.2010107@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"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 v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 24 Feb 2012, David Vrabel wrote:
> On 24/02/12 10:33, Ian Campbell wrote:
> > On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> >> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> >> we reserve for Xen usage.
> > 
> > Does this require a trap when the guest acks or EOIs this interrupt?
> > What about maintenance interrupts arising from injecting this?

Yes, we would get a maintenance interrupt in the hypervisor every time
the guest EOI's it.


> > Might we want to instead inject this interrupt as an SGI, so that it
> > appears as a per-VCPU interrupt?
> 
> I don't think it's possible to register a SGI handler in Linux
> currently.  The mapping of IRQ numbers to GIC interrupts skips over the
> SGIs.  This would be easy to fix I think.

A per-vcpu interrupt that doesn't require an EOI would be ideal, however
like David wrote, it is not possible to register an SGI handler in Linux
at the moment. I'll give it a look though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 14:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 14: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 1S0wFv-0003Gz-Bk; Fri, 24 Feb 2012 14:36:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S0wFu-0003Gn-FB
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 14:36:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330094170!10824944!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18763 invoked from network); 24 Feb 2012 14:36:11 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 14:36:11 -0000
Received: by iaeh11 with SMTP id h11so11035423iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 24 Feb 2012 06:36:10 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.155.202 as permitted sender) client-ip=10.50.155.202; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.155.202 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.155.202])
	by 10.50.155.202 with SMTP id vy10mr2810526igb.8.1330094170060
	(num_hops = 1); Fri, 24 Feb 2012 06:36:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=MDGrppjykOSf4qoZr3KG2s/8Miv+Zblgku0hvmqMl7Y=;
	b=r1qo/LrZ5u5l7+4xonItG7RsI+RgwlSMU956yuf2F2DJ4lOHoG5bV3tT6O3Bc1lOPK
	M0WfNQneuZ+gwMLwQl4Z4kadeIE7DBJm6JmxZSl2SqM5oASnDONJ/DX3C0uH60E9YxM/
	0vfdggzJtxX13aiHw2O6IhRQaoLa1OyplOisI=
MIME-Version: 1.0
Received: by 10.50.155.202 with SMTP id vy10mr2222077igb.8.1330094170021; Fri,
	24 Feb 2012 06:36:10 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Fri, 24 Feb 2012 06:36:09 -0800 (PST)
In-Reply-To: <1330080645.5034.96.camel@Abyss>
References: <1330078323.5034.73.camel@Abyss> <4F476396.60802@eu.citrix.com>
	<1330080645.5034.96.camel@Abyss>
Date: Fri, 24 Feb 2012 14:36:09 +0000
X-Google-Sender-Auth: wipuFAtRcHloSQ-WOQ7v5ptQOrg
Message-ID: <CAFLBxZYwuNKfBZJKJQQkaq4NEZDj7x6JrQ484sKsTB7L7p8B1w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 10:50 AM, Dario Faggioli <raistlin@linux.it> wrote:
>> It seems to me we
>> have two options:
>> * Have libxl do the NUMA placement on behalf of the toolstack. =A0In that
>> case, the libxl_domain_create_new function should look at the available
>> memory, the NUMA layout, &c, and then set d->node_affinity before
>> calling xc_hvm_build.
>>
> This can be done. If I got it correctly it is more or less what xm/xend
> already does.
>
>> * Have the toolstack do it. =A0In this case, you'd be modifying xl to set
>> d->node_affinity before calling libxl's domain creation function.
>>
> I'm not sure I'm getting this right... It seems very similar to the one
> above.

>From Xen's perspective, yes.  But from the libxl perspective, no.
libxl is meant to be the interface we give to other external
toolstacks, so the interface there is important.

>> Do those options work? =A0Let me know if I've misunderstood anything.
>>
> I think they can be implemented. "work", it depends on how we define
> "work". :-D
>
> That's why I was struggling for putting this in the hypervisor and not
> in the toolstack because I really think it should live there if
> possible. For example it would be nice for the decision to be protected
> by the proper locking. I mean, what's the point in checking the amount
> of free memory in a node somewhere in (lib)xl, if when the actual
> allocation will happen (in Xen) that might be a completely different
> value (due to concurrent domain creation, destruction, etc.)?

At the moment, pages for a VM are not allocated in one big chunk
anyway -- xc_hvm_build.c:setup_guest() calls
xc_domain_populate_physmap() in a loop.  So Xen is in less of a
position to avoid the TOCTTOU race than the toolstack is.  The
toolstack in theory, at least, can refrain from starting a second VM
until the first is completely allocated.

I don't think there's any reason to do it in Xen -- it's not
time-critical, it doesn't require any information that the toolstack
and/or domain builder wouldn't have available to it.

> I think the config file, supporting cpupools and vcpu-pinning, already
> offer almost all the facilities for manually deploying a VM reflecting a
> specific NUMA-layout. What I was thinking adding was the "numa=3Dauto" or
> whatever switch, so that if one does not (want to) specify cpupools or
> pinning, VM still gets NUMA-sensible placement.

Do we have a way to specify the NUMA layout?  That should be a
separate config option than vcpu pinning.  But yes, I think adding
"numa=3Dauto" (on by default) is the big feature we need; and I think
that's probably best implemented in either the toolstack or libxl.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 14:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 14: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 1S0wFv-0003Gz-Bk; Fri, 24 Feb 2012 14:36:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S0wFu-0003Gn-FB
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 14:36:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330094170!10824944!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18763 invoked from network); 24 Feb 2012 14:36:11 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 14:36:11 -0000
Received: by iaeh11 with SMTP id h11so11035423iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 24 Feb 2012 06:36:10 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.155.202 as permitted sender) client-ip=10.50.155.202; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.155.202 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.155.202])
	by 10.50.155.202 with SMTP id vy10mr2810526igb.8.1330094170060
	(num_hops = 1); Fri, 24 Feb 2012 06:36:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=MDGrppjykOSf4qoZr3KG2s/8Miv+Zblgku0hvmqMl7Y=;
	b=r1qo/LrZ5u5l7+4xonItG7RsI+RgwlSMU956yuf2F2DJ4lOHoG5bV3tT6O3Bc1lOPK
	M0WfNQneuZ+gwMLwQl4Z4kadeIE7DBJm6JmxZSl2SqM5oASnDONJ/DX3C0uH60E9YxM/
	0vfdggzJtxX13aiHw2O6IhRQaoLa1OyplOisI=
MIME-Version: 1.0
Received: by 10.50.155.202 with SMTP id vy10mr2222077igb.8.1330094170021; Fri,
	24 Feb 2012 06:36:10 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Fri, 24 Feb 2012 06:36:09 -0800 (PST)
In-Reply-To: <1330080645.5034.96.camel@Abyss>
References: <1330078323.5034.73.camel@Abyss> <4F476396.60802@eu.citrix.com>
	<1330080645.5034.96.camel@Abyss>
Date: Fri, 24 Feb 2012 14:36:09 +0000
X-Google-Sender-Auth: wipuFAtRcHloSQ-WOQ7v5ptQOrg
Message-ID: <CAFLBxZYwuNKfBZJKJQQkaq4NEZDj7x6JrQ484sKsTB7L7p8B1w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] NUMA-aware VM placement in Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 10:50 AM, Dario Faggioli <raistlin@linux.it> wrote:
>> It seems to me we
>> have two options:
>> * Have libxl do the NUMA placement on behalf of the toolstack. =A0In that
>> case, the libxl_domain_create_new function should look at the available
>> memory, the NUMA layout, &c, and then set d->node_affinity before
>> calling xc_hvm_build.
>>
> This can be done. If I got it correctly it is more or less what xm/xend
> already does.
>
>> * Have the toolstack do it. =A0In this case, you'd be modifying xl to set
>> d->node_affinity before calling libxl's domain creation function.
>>
> I'm not sure I'm getting this right... It seems very similar to the one
> above.

>From Xen's perspective, yes.  But from the libxl perspective, no.
libxl is meant to be the interface we give to other external
toolstacks, so the interface there is important.

>> Do those options work? =A0Let me know if I've misunderstood anything.
>>
> I think they can be implemented. "work", it depends on how we define
> "work". :-D
>
> That's why I was struggling for putting this in the hypervisor and not
> in the toolstack because I really think it should live there if
> possible. For example it would be nice for the decision to be protected
> by the proper locking. I mean, what's the point in checking the amount
> of free memory in a node somewhere in (lib)xl, if when the actual
> allocation will happen (in Xen) that might be a completely different
> value (due to concurrent domain creation, destruction, etc.)?

At the moment, pages for a VM are not allocated in one big chunk
anyway -- xc_hvm_build.c:setup_guest() calls
xc_domain_populate_physmap() in a loop.  So Xen is in less of a
position to avoid the TOCTTOU race than the toolstack is.  The
toolstack in theory, at least, can refrain from starting a second VM
until the first is completely allocated.

I don't think there's any reason to do it in Xen -- it's not
time-critical, it doesn't require any information that the toolstack
and/or domain builder wouldn't have available to it.

> I think the config file, supporting cpupools and vcpu-pinning, already
> offer almost all the facilities for manually deploying a VM reflecting a
> specific NUMA-layout. What I was thinking adding was the "numa=3Dauto" or
> whatever switch, so that if one does not (want to) specify cpupools or
> pinning, VM still gets NUMA-sensible placement.

Do we have a way to specify the NUMA layout?  That should be a
separate config option than vcpu pinning.  But yes, I think adding
"numa=3Dauto" (on by default) is the big feature we need; and I think
that's probably best implemented in either the toolstack or libxl.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 15:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 15: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 1S0woU-0003tf-2K; Fri, 24 Feb 2012 15:12:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0woT-0003tL-7y
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 15:12:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330096298!10831853!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NzA5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2399 invoked from network); 24 Feb 2012 15:11:40 -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; 24 Feb 2012 15:11:40 -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 q1OFBX82030952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 15:11: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
	q1OFBWYG018096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 15:11:32 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
	q1OFBVrd021430; Fri, 24 Feb 2012 09:11:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 07:11:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C8EE44171C; Fri, 24 Feb 2012 10:08:07 -0500 (EST)
Date: Fri, 24 Feb 2012 10:08:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120224150807.GA17879@phenom.dumpdata.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<4F47733E020000780007497D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F47733E020000780007497D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F47A8A7.004F,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 Fri, Feb 24, 2012 at 10:23:42AM +0000, Jan Beulich wrote:
> >>> On 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > This module (processor-passthru)  collects the information that the cpufreq
> > drivers and the ACPI processor code save in the 'struct acpi_processor' and
> > then uploads it to the hypervisor.
> 
> Thus looks conceptually wrong to me - there shouldn't be a need for a
> CPUFreq driver to be loaded in Dom0 (or your module should masquerade
> as the one and only suitable one).

I piggyback on the generic cpufreq drivers to collect the information they
have evaluated.

I can make the driver a cpufreq one but there does not seem to be a way
from the kernel to force a specific driver to say "use me". I could write
it naturally, but not sure what the usage case is except for the driver
I wrote. But perhaps there is also for the cpufreq powernow-k8 and acpi-processor
so that they can function without the need for strict compile order
(where powernow-k8 MUST be loaded before acpi-processor).

> 
> > On the hypervisor side, it requires this patch on AMD:
> > # HG changeset patch
> > # Parent aea8cfac8cf1afe397f2e1d422a852008d8a83fe
> > traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> > 
> > The restriction to read and write the AMD power management MSRs is gated if 
> > the
> > domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> > relax this restriction and allow the privileged domain to read the MSRs
> > (but not write). This allows the priviliged domain to harvest the power
> > management information (ACPI _PSS states) and send it to the hypervisor.
> 
> Why would accessing these MSRs be necessary here, when it isn't
> for non-pvops? Perhaps only because you want a CPUFreq driver
> loaded?

Correct. The powernow-k8
> 
> Jan
> 
> > This patch works fine with older classic dom0 (2.6.32) and with
> > AMD K7 and K8 boxes.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > diff -r aea8cfac8cf1 xen/arch/x86/traps.c
> > --- a/xen/arch/x86/traps.c	Thu Feb 23 13:23:02 2012 -0500
> > +++ b/xen/arch/x86/traps.c	Thu Feb 23 13:29:00 2012 -0500
> > @@ -2484,7 +2484,7 @@ static int emulate_privileged_op(struct 
> >          case MSR_K8_PSTATE7:
> >              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> >                  goto fail;
> > -            if ( !is_cpufreq_controller(v->domain) )
> > +            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
> >              {
> >                  regs->eax = regs->edx = 0;
> >                  break;
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 15:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 15: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 1S0woU-0003tf-2K; Fri, 24 Feb 2012 15:12:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S0woT-0003tL-7y
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 15:12:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330096298!10831853!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NzA5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2399 invoked from network); 24 Feb 2012 15:11:40 -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; 24 Feb 2012 15:11:40 -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 q1OFBX82030952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 15:11: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
	q1OFBWYG018096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 15:11:32 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
	q1OFBVrd021430; Fri, 24 Feb 2012 09:11:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 07:11:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C8EE44171C; Fri, 24 Feb 2012 10:08:07 -0500 (EST)
Date: Fri, 24 Feb 2012 10:08:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120224150807.GA17879@phenom.dumpdata.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<4F47733E020000780007497D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F47733E020000780007497D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F47A8A7.004F,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 Fri, Feb 24, 2012 at 10:23:42AM +0000, Jan Beulich wrote:
> >>> On 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > This module (processor-passthru)  collects the information that the cpufreq
> > drivers and the ACPI processor code save in the 'struct acpi_processor' and
> > then uploads it to the hypervisor.
> 
> Thus looks conceptually wrong to me - there shouldn't be a need for a
> CPUFreq driver to be loaded in Dom0 (or your module should masquerade
> as the one and only suitable one).

I piggyback on the generic cpufreq drivers to collect the information they
have evaluated.

I can make the driver a cpufreq one but there does not seem to be a way
from the kernel to force a specific driver to say "use me". I could write
it naturally, but not sure what the usage case is except for the driver
I wrote. But perhaps there is also for the cpufreq powernow-k8 and acpi-processor
so that they can function without the need for strict compile order
(where powernow-k8 MUST be loaded before acpi-processor).

> 
> > On the hypervisor side, it requires this patch on AMD:
> > # HG changeset patch
> > # Parent aea8cfac8cf1afe397f2e1d422a852008d8a83fe
> > traps: AMD PM RDMSRs (MSR_K8_PSTATE_CTRL, etc)
> > 
> > The restriction to read and write the AMD power management MSRs is gated if 
> > the
> > domain 0 is the PM domain (so FREQCTL_dom0_kernel is set). But we can
> > relax this restriction and allow the privileged domain to read the MSRs
> > (but not write). This allows the priviliged domain to harvest the power
> > management information (ACPI _PSS states) and send it to the hypervisor.
> 
> Why would accessing these MSRs be necessary here, when it isn't
> for non-pvops? Perhaps only because you want a CPUFreq driver
> loaded?

Correct. The powernow-k8
> 
> Jan
> 
> > This patch works fine with older classic dom0 (2.6.32) and with
> > AMD K7 and K8 boxes.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > diff -r aea8cfac8cf1 xen/arch/x86/traps.c
> > --- a/xen/arch/x86/traps.c	Thu Feb 23 13:23:02 2012 -0500
> > +++ b/xen/arch/x86/traps.c	Thu Feb 23 13:29:00 2012 -0500
> > @@ -2484,7 +2484,7 @@ static int emulate_privileged_op(struct 
> >          case MSR_K8_PSTATE7:
> >              if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
> >                  goto fail;
> > -            if ( !is_cpufreq_controller(v->domain) )
> > +            if ( !is_cpufreq_controller(v->domain) && !IS_PRIV(v->domain) )
> >              {
> >                  regs->eax = regs->edx = 0;
> >                  break;
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 15:39:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 15: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 1S0xEF-0004XH-5W; Fri, 24 Feb 2012 15:38:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0xED-0004XA-MS
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 15:38:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330097911!14761874!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMTI2MDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMTI2MDI=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25199 invoked from network); 24 Feb 2012 15:38:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 15:38:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330097911; l=3308;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=rY/Nvl1RskJpBd0mJBkLqNAxicM=;
	b=G7vCSAdkooMjRtviNiZp6QmN6QiOC9Df1TIdZ+uvJaasKT/3L2y7UD/tUHKgYar+ZAW
	w5vwCgGHuLcWE9wsfXiHJIPZ7v4iniy7u8QUD2IFrS3l6iOuWhrwfvuY7PUpe7DcaGDKp
	Sd+IbG1/pEePixjIMfS0lG0LK6A3EU38m6U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69n6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-11.vodafone-net.de [80.226.24.11])
	by smtp.strato.de (cohen mo63) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 205202o1OEqiV5 ;
	Fri, 24 Feb 2012 16:38:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 42C9518638; Fri, 24 Feb 2012 16:38:22 +0100 (CET)
Date: Fri, 24 Feb 2012 16:38:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120224153822.GA29117@aepfle.de>
References: <20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330078304.8557.157.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, Ian Campbell wrote:

> Here is an updated version of my proposed interface which includes
> sharing, I think as you described (modulo the use of mem-paging-set
> where you said mem-set above).
> 
> I also included "mem-paging-set manual" as an explicit thing with an
> error on "mem-paging-set N" if you don't switch to manual mode. This
> might be too draconian -- I'm not wedded to it.
> 
> maxmem=X                        # maximum RAM the domain can ever see
> memory=M                        # current amount of RAM seen by the
> 				# domain
> paging=[off|on]                 # allow the amount of memory a guest 
>                                 # thinks it has to differ from the
>                                 # amount actually available to it (its
>                                 # "footprint")
> pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
>                                 # "footprint" for guests which do not
>                                 # voluntarily obey changes to memory=M 
> pagingdelay=60                  # amount of time to give a guest to 
>                                 # voluntarily comply before enforcing a 
>                                 # footprint
> pagesharing=[off|on]		# cause this guest to share pages with
> 				# other similarly enabled guests where
> 				# possible. Requires paging=on.
> pageextrapolocy=...		# controls what happens to extra pages 
> 				# gain via sharing (could be combined 
> 				# with pagesharing option:
> 				#	[off|policy|...])
> 
>         Open question -- does pagesharing=on require paging=on? I've
>         tried to specify things below such that it does not, but it
>         might simplify things to require this.
> 
> xl mem-set domain M
>         Sets the amount of RAM which the guest believes it has available
>         to M. The guest should arrange to use only that much RAM and
>         return the rest to the hypervisor (e.g. by using a balloon
>         driver). If the guest does not do so then the host may use
>         technical means to enforce the guest's footprint of M. The guest
>         may suffer a performance penalty for this enforcement.
> 
>         paging off:     set balloon target to M.
>         paging on:      set balloon target to M.
>                         if pagingauto:
>                                 wait delay IFF new target < old
>                                 set paging target to M
>                                 support -t <delay> to override default?

Instead of having two now config options pagingauto= and pagingdelay=,
what about 'xl mem-set -t <seconds>' to adjust the fixed internal value
pagingdelay=? Then '-t 0' could mean pagingauto=off, which means use
both ballooning and paging to reach the "footprint" M.

>         Open question -- if a domain balloons to M as requested should
>         it still be subject to sharing? There is a performance hit
>         associated with sharing (far less than paging though?) but
>         presumably the admin would not have enabled sharing if they
>         didn't want this, therefore I think it is right for sharing on
>         to allow the guest to actually have <M assigned to it. Might be
>         a function of the individual sharing policy?
> 
> xl mem-paging-set domain manual
> 	Enables manual control of paging target.
> 
> 	paging off:	error
> 	paging on:	set pagingauto=off
> 	sharing on:	same as paging on.
> 
> xl mem-paging-set domain N
>         Overrides the amount of RAM which the guest actually has
>         available (its "footprint") to N. The host will use technical
>         means to continue to provide the illusion to the guest that it
>         has memory=M (as adjusted by mem-set). There may be a
>         performance penalty for this.
>         
>         paging off:     error

Could this be the time to start the pager and give it target N?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 15:39:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 15: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 1S0xEF-0004XH-5W; Fri, 24 Feb 2012 15:38:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S0xED-0004XA-MS
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 15:38:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330097911!14761874!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMTI2MDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMTI2MDI=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25199 invoked from network); 24 Feb 2012 15:38:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 15:38:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330097911; l=3308;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=rY/Nvl1RskJpBd0mJBkLqNAxicM=;
	b=G7vCSAdkooMjRtviNiZp6QmN6QiOC9Df1TIdZ+uvJaasKT/3L2y7UD/tUHKgYar+ZAW
	w5vwCgGHuLcWE9wsfXiHJIPZ7v4iniy7u8QUD2IFrS3l6iOuWhrwfvuY7PUpe7DcaGDKp
	Sd+IbG1/pEePixjIMfS0lG0LK6A3EU38m6U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69n6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-11.vodafone-net.de [80.226.24.11])
	by smtp.strato.de (cohen mo63) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 205202o1OEqiV5 ;
	Fri, 24 Feb 2012 16:38:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 42C9518638; Fri, 24 Feb 2012 16:38:22 +0100 (CET)
Date: Fri, 24 Feb 2012 16:38:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120224153822.GA29117@aepfle.de>
References: <20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330078304.8557.157.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, Ian Campbell wrote:

> Here is an updated version of my proposed interface which includes
> sharing, I think as you described (modulo the use of mem-paging-set
> where you said mem-set above).
> 
> I also included "mem-paging-set manual" as an explicit thing with an
> error on "mem-paging-set N" if you don't switch to manual mode. This
> might be too draconian -- I'm not wedded to it.
> 
> maxmem=X                        # maximum RAM the domain can ever see
> memory=M                        # current amount of RAM seen by the
> 				# domain
> paging=[off|on]                 # allow the amount of memory a guest 
>                                 # thinks it has to differ from the
>                                 # amount actually available to it (its
>                                 # "footprint")
> pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
>                                 # "footprint" for guests which do not
>                                 # voluntarily obey changes to memory=M 
> pagingdelay=60                  # amount of time to give a guest to 
>                                 # voluntarily comply before enforcing a 
>                                 # footprint
> pagesharing=[off|on]		# cause this guest to share pages with
> 				# other similarly enabled guests where
> 				# possible. Requires paging=on.
> pageextrapolocy=...		# controls what happens to extra pages 
> 				# gain via sharing (could be combined 
> 				# with pagesharing option:
> 				#	[off|policy|...])
> 
>         Open question -- does pagesharing=on require paging=on? I've
>         tried to specify things below such that it does not, but it
>         might simplify things to require this.
> 
> xl mem-set domain M
>         Sets the amount of RAM which the guest believes it has available
>         to M. The guest should arrange to use only that much RAM and
>         return the rest to the hypervisor (e.g. by using a balloon
>         driver). If the guest does not do so then the host may use
>         technical means to enforce the guest's footprint of M. The guest
>         may suffer a performance penalty for this enforcement.
> 
>         paging off:     set balloon target to M.
>         paging on:      set balloon target to M.
>                         if pagingauto:
>                                 wait delay IFF new target < old
>                                 set paging target to M
>                                 support -t <delay> to override default?

Instead of having two now config options pagingauto= and pagingdelay=,
what about 'xl mem-set -t <seconds>' to adjust the fixed internal value
pagingdelay=? Then '-t 0' could mean pagingauto=off, which means use
both ballooning and paging to reach the "footprint" M.

>         Open question -- if a domain balloons to M as requested should
>         it still be subject to sharing? There is a performance hit
>         associated with sharing (far less than paging though?) but
>         presumably the admin would not have enabled sharing if they
>         didn't want this, therefore I think it is right for sharing on
>         to allow the guest to actually have <M assigned to it. Might be
>         a function of the individual sharing policy?
> 
> xl mem-paging-set domain manual
> 	Enables manual control of paging target.
> 
> 	paging off:	error
> 	paging on:	set pagingauto=off
> 	sharing on:	same as paging on.
> 
> xl mem-paging-set domain N
>         Overrides the amount of RAM which the guest actually has
>         available (its "footprint") to N. The host will use technical
>         means to continue to provide the illusion to the guest that it
>         has memory=M (as adjusted by mem-set). There may be a
>         performance penalty for this.
>         
>         paging off:     error

Could this be the time to start the pager and give it target N?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 15:43:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 15:43:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0xI7-0004fr-QF; Fri, 24 Feb 2012 15:42:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0xI5-0004fe-RU
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 15:42:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330098151!14767547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13207 invoked from network); 24 Feb 2012 15:42:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 15:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10923647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 15:42:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 15:42:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0xHy-0000Mb-TI; Fri, 24 Feb 2012 15:42:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0xHy-0006FN-SR;
	Fri, 24 Feb 2012 15:42:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.45030.867821.388716@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 15:42:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330087322.8557.195.camel@zakaz.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<20295.32799.308331.653289@mariner.uk.xensource.com>
	<1330087322.8557.195.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.
> 
> -D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
> perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?

That would be a possibility but if we define it in libxl.h that will
fix the problem, if we are happy for libxl callers to be using
hypervisor public headers.

> We can stop xl by just not doing it (TM), for other callers of libxl --
> well, we say you shouldn't need it for toolstack operations and that
> libxl should provide all the functionality but if they _really_ want to
> ignore that...
> 
> Also a toolstack may have functionality which is not considered
> "toolstack functionality" per the remit of libxl and for which they wish
> to use xenctrl directly. e.g. perhaps they communicate with a guest
> agent using their own shared ring protocol for which they require the
> ability to map domain memory.

How about the patch below.  This would be an alternative to your
version which buries all the hypervisor public headers.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Forbid <xenctrl.h>, allow Xen public headers

Rationalise and enforce the header-inclusion policy for libxl.

libxl applications are allowed to use symbols (mostly #defines) from
the Xen public headers, where these are useful (for example, where
they are the numeric arguments to libxl calls).  This avoids us having
to veneer the whole of the Xen public API.  For this to work without
special measures on the part of the application, libxl.h should define
__XEN_TOOLS__.

However libxl applications are not normally expected to want to use
libxc directly, so take steps to prevent them including <xenctrl.h>
unless they declare (as libxl itself does) that doing so is OK by
defining LIBXL_ALLOW_XENCTRL.  (We have to add a hook at the end of
xenctrl.h so that we can spot the case where xenctrl.h is included
second.)

Make xc.c comply with the policy: remove the redundant inclusion of
xenctrl.h.

This patch should make life easier for out-of-tree libxl callers and
hopefully prevent future mistakes relating to api visibility.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxc/xenctrl.h        |    4 ++++
 tools/libxl/libxl.h          |   10 ++++++++++
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/xl.c             |    1 -
 4 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..8441b62 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2047,4 +2047,8 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
 				   unsigned long compbuf_size,
 				   unsigned long *compbuf_pos, char *dest);
 
+#ifdef XENCTRL_DO_INCLUDE
+#include XENCTRL_DO_INCLUDE
+#endif
+
 #endif /* XENCTRL_H */
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bffa03..86a308d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -124,9 +124,19 @@
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
  */
+
+#if !defined(LIBXL_ALLOW_XENCTRL)
+#ifdef XENCTRL_H
+#error applications which use libxl should not normally use xenctrl.h too
+#endif
+#define XENCTRL_DO_INCLUDE <libxl.h> /* spot if xenctrl.h came second */
+#endif /* !defined(LIBXL_ALLOW_XENCTRL) */
+
 #ifndef LIBXL_H
 #define LIBXL_H
 
+#define __XEN_TOOLS__ 1
+
 #include <stdbool.h>
 #include <stdint.h>
 #include <stdarg.h>
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 46e131a..478de48 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,6 +17,8 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#define LIBXL_ALLOW_XENCTRL
+
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <assert.h>
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..2b14814 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -26,7 +26,6 @@
 #include <fcntl.h>
 #include <ctype.h>
 #include <inttypes.h>
-#include <xenctrl.h>
 
 #include "libxl.h"
 #include "libxl_utils.h"
-- 
tg: (fa6fc38..) t/xen/xl.xenctrl.forbid (depends on: t/xen/gitignore)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 15:43:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 15:43:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0xI7-0004fr-QF; Fri, 24 Feb 2012 15:42:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0xI5-0004fe-RU
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 15:42:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330098151!14767547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13207 invoked from network); 24 Feb 2012 15:42:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 15:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10923647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 15:42:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 15:42:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S0xHy-0000Mb-TI; Fri, 24 Feb 2012 15:42:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S0xHy-0006FN-SR;
	Fri, 24 Feb 2012 15:42:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.45030.867821.388716@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 15:42:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330087322.8557.195.camel@zakaz.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<20295.32799.308331.653289@mariner.uk.xensource.com>
	<1330087322.8557.195.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.
> 
> -D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
> perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?

That would be a possibility but if we define it in libxl.h that will
fix the problem, if we are happy for libxl callers to be using
hypervisor public headers.

> We can stop xl by just not doing it (TM), for other callers of libxl --
> well, we say you shouldn't need it for toolstack operations and that
> libxl should provide all the functionality but if they _really_ want to
> ignore that...
> 
> Also a toolstack may have functionality which is not considered
> "toolstack functionality" per the remit of libxl and for which they wish
> to use xenctrl directly. e.g. perhaps they communicate with a guest
> agent using their own shared ring protocol for which they require the
> ability to map domain memory.

How about the patch below.  This would be an alternative to your
version which buries all the hypervisor public headers.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Forbid <xenctrl.h>, allow Xen public headers

Rationalise and enforce the header-inclusion policy for libxl.

libxl applications are allowed to use symbols (mostly #defines) from
the Xen public headers, where these are useful (for example, where
they are the numeric arguments to libxl calls).  This avoids us having
to veneer the whole of the Xen public API.  For this to work without
special measures on the part of the application, libxl.h should define
__XEN_TOOLS__.

However libxl applications are not normally expected to want to use
libxc directly, so take steps to prevent them including <xenctrl.h>
unless they declare (as libxl itself does) that doing so is OK by
defining LIBXL_ALLOW_XENCTRL.  (We have to add a hook at the end of
xenctrl.h so that we can spot the case where xenctrl.h is included
second.)

Make xc.c comply with the policy: remove the redundant inclusion of
xenctrl.h.

This patch should make life easier for out-of-tree libxl callers and
hopefully prevent future mistakes relating to api visibility.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxc/xenctrl.h        |    4 ++++
 tools/libxl/libxl.h          |   10 ++++++++++
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/xl.c             |    1 -
 4 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 73d24e5..8441b62 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2047,4 +2047,8 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
 				   unsigned long compbuf_size,
 				   unsigned long *compbuf_pos, char *dest);
 
+#ifdef XENCTRL_DO_INCLUDE
+#include XENCTRL_DO_INCLUDE
+#endif
+
 #endif /* XENCTRL_H */
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bffa03..86a308d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -124,9 +124,19 @@
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
  */
+
+#if !defined(LIBXL_ALLOW_XENCTRL)
+#ifdef XENCTRL_H
+#error applications which use libxl should not normally use xenctrl.h too
+#endif
+#define XENCTRL_DO_INCLUDE <libxl.h> /* spot if xenctrl.h came second */
+#endif /* !defined(LIBXL_ALLOW_XENCTRL) */
+
 #ifndef LIBXL_H
 #define LIBXL_H
 
+#define __XEN_TOOLS__ 1
+
 #include <stdbool.h>
 #include <stdint.h>
 #include <stdarg.h>
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 46e131a..478de48 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,6 +17,8 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#define LIBXL_ALLOW_XENCTRL
+
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <assert.h>
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..2b14814 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -26,7 +26,6 @@
 #include <fcntl.h>
 #include <ctype.h>
 #include <inttypes.h>
-#include <xenctrl.h>
 
 #include "libxl.h"
 #include "libxl_utils.h"
-- 
tg: (fa6fc38..) t/xen/xl.xenctrl.forbid (depends on: t/xen/gitignore)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:04:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0xcS-0005SN-SL; Fri, 24 Feb 2012 16:03:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1S0xcS-0005SI-2q
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:03:40 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330099413!18125179!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDY0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20001 invoked from network); 24 Feb 2012 16:03:33 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 16:03:33 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BC41521008
	for <xen-devel@lists.xensource.com>;
	Fri, 24 Feb 2012 11:03:32 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Fri, 24 Feb 2012 11:03:32 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=Dw
	zfjApJZ+m57zebtsKxSAUvu9o=; b=P9YBvUOAe5G/DuhnDIVOgTz1/Q9N+6RlLp
	Ta2HZDf1MyiG/nP/3fs82Yqj+oF3Prm50kFFCgEHXCVLz+s2qrV1oy9shmECBStQ
	LkEoTb6oII+5v4D8jaPGlEe+NHUrblMg7RS2lWRnfDR36wYvE2sLefm9hWrfpF2O
	EbKiEK1N4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=Dwzf
	jApJZ+m57zebtsKxSAUvu9o=; b=D6JpEeueapG5S66r/mC7JtcEgUe7lvuoms6w
	R0CHxl/kI+smqFLA7OcznwF+VyCwLDO5cvfTOAUscVyNtUhhf1+jSa2ngfkZmEw5
	oT7GebhVjotTZY89OvPKyX4jzdXHnbjGKMit9j/STL13a/ZoNgxZr9sOS6XTfXFN
	8NywdqE=
X-Sasl-enc: +yWRoVzpkGUX0pgr5X+oPMcq5EVwfxPJyF54Tpoo4uBO 1330099412
Received: from [10.137.2.11] (87-207-161-88.dynamic.chello.pl [87.207.161.88])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 19167482619;
	Fri, 24 Feb 2012 11:03:31 -0500 (EST)
Message-ID: <4F47B4D0.2030806@invisiblethingslab.com>
Date: Fri, 24 Feb 2012 17:03:28 +0100
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
	<4F46E174.6040009@invisiblethingslab.com>
	<20120224055418.GA11780@phenom.dumpdata.com>
In-Reply-To: <20120224055418.GA11780@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4182788666694627997=="
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)
--===============4182788666694627997==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigDDFFD85ADBBE993ECF8F2F5E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDDFFD85ADBBE993ECF8F2F5E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24.02.2012 06:54, Konrad Rzeszutek Wilk wrote:
>>>>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advis=
es how
>>>>>>> to approach debugging it?
>>>>>>>
> .. snip..
>> (the same hardware)
>> On 2.6.38.3 xenlinux kernel after resume there is screen content from =
before
>> suspend, power led light constantly (as it should), but system is
>> irresponsible (no capslock led, no reaction to sysrq, network etc).
>> On 3.x with your patches system goes into S3, but on resume is even wo=
rse - no
>> screen content at all (and no backlight) and also irresponsible, power=
 led
>> still blinking. As 3.x tried:
>>  - your devel/acpi-s3.v7 branch directly
>>  - 3.2.7 merged with devel/acpi-s3.v7
>>  - 3.3-rc4 with devel/acpi-s3.v7
>=20
> OK. That is weird - it worked for me last time. One thing at at time th=
en -
> try doing this from text-mode, so no graphic mode involved. For that yo=
u might
> need to disable your i915 driver altogether. Then just run 'pm-suspend'=
 and
> see where it stops.
>=20
> The next part is... Wait a minute, this reminds me of something I encou=
ntered
> with a SandyBrige i2100 - the suspend would work, but resume would get =
stuck.
>=20
> The issue was with the hypervisor and if I had the acpi-cpufreq drivers=
 loaded
> it resumed just fine. If I didn't - so hypervisor had no idea about C s=
tates or
> P states, it would be stuck in the default_idle and never come back.
>=20
> So you might want for fun try also using the stable/processor-passthru.=
v5 and
> build it with CONFIG_XEN_PROCESSOR_PASSTHRU=3Dy.

Looks much better. At least for few suspend/resume it works. Thanks!
And: when is it planned to upstream above patches (acpi-s3 and
processor-passthru)?

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigDDFFD85ADBBE993ECF8F2F5E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPR7TQAAoJENuP0xzK19csTj0H/1TRJ7Kd5I/2aUiCLP4okVuL
xGde7Zw/vorQS7Z7B7O/IBtqdUaPiXXHpE1BvNkRE/463LilLvJ/7PWWXJUns2co
AKHUIuxacC0HuekGV+reU7m/cdvoP/dqiAOMj8r4F4UXQiYLh1/OVqqvW8cURCHd
9b1UeDDmWphn/r1MSc+tPaQjm+if8pRC76eWzuGk3YnQkPOPwrBwZFChArvbSo46
bmSFdH3Of20mr01I8fY5v4LXue2S8GIMLsy8L+fiyscfh3u8SO5Kguil1eXAk5xU
++hNLYgaI/tchDym9vSW2htOqAJp/DiDsC3dXDqu3WD9tFJ0l/YnepOXsGpW82Y=
=7+Jb
-----END PGP SIGNATURE-----

--------------enigDDFFD85ADBBE993ECF8F2F5E--


--===============4182788666694627997==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4182788666694627997==--


From xen-devel-bounces@lists.xen.org Fri Feb 24 16:04:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0xcS-0005SN-SL; Fri, 24 Feb 2012 16:03:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@invisiblethingslab.com>) id 1S0xcS-0005SI-2q
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:03:40 +0000
X-Env-Sender: marmarek@invisiblethingslab.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330099413!18125179!1
X-Originating-IP: [66.111.4.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjkgPT4gNDY0NTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20001 invoked from network); 24 Feb 2012 16:03:33 -0000
Received: from out5-smtp.messagingengine.com (HELO
	out5-smtp.messagingengine.com) (66.111.4.29)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2012 16:03:33 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BC41521008
	for <xen-devel@lists.xensource.com>;
	Fri, 24 Feb 2012 11:03:32 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Fri, 24 Feb 2012 11:03:32 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=Dw
	zfjApJZ+m57zebtsKxSAUvu9o=; b=P9YBvUOAe5G/DuhnDIVOgTz1/Q9N+6RlLp
	Ta2HZDf1MyiG/nP/3fs82Yqj+oF3Prm50kFFCgEHXCVLz+s2qrV1oy9shmECBStQ
	LkEoTb6oII+5v4D8jaPGlEe+NHUrblMg7RS2lWRnfDR36wYvE2sLefm9hWrfpF2O
	EbKiEK1N4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=Dwzf
	jApJZ+m57zebtsKxSAUvu9o=; b=D6JpEeueapG5S66r/mC7JtcEgUe7lvuoms6w
	R0CHxl/kI+smqFLA7OcznwF+VyCwLDO5cvfTOAUscVyNtUhhf1+jSa2ngfkZmEw5
	oT7GebhVjotTZY89OvPKyX4jzdXHnbjGKMit9j/STL13a/ZoNgxZr9sOS6XTfXFN
	8NywdqE=
X-Sasl-enc: +yWRoVzpkGUX0pgr5X+oPMcq5EVwfxPJyF54Tpoo4uBO 1330099412
Received: from [10.137.2.11] (87-207-161-88.dynamic.chello.pl [87.207.161.88])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 19167482619;
	Fri, 24 Feb 2012 11:03:31 -0500 (EST)
Message-ID: <4F47B4D0.2030806@invisiblethingslab.com>
Date: Fri, 24 Feb 2012 17:03:28 +0100
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0) Gecko/20120131 Thunderbird/10.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
	<4F46E174.6040009@invisiblethingslab.com>
	<20120224055418.GA11780@phenom.dumpdata.com>
In-Reply-To: <20120224055418.GA11780@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4182788666694627997=="
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)
--===============4182788666694627997==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigDDFFD85ADBBE993ECF8F2F5E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDDFFD85ADBBE993ECF8F2F5E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24.02.2012 06:54, Konrad Rzeszutek Wilk wrote:
>>>>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advis=
es how
>>>>>>> to approach debugging it?
>>>>>>>
> .. snip..
>> (the same hardware)
>> On 2.6.38.3 xenlinux kernel after resume there is screen content from =
before
>> suspend, power led light constantly (as it should), but system is
>> irresponsible (no capslock led, no reaction to sysrq, network etc).
>> On 3.x with your patches system goes into S3, but on resume is even wo=
rse - no
>> screen content at all (and no backlight) and also irresponsible, power=
 led
>> still blinking. As 3.x tried:
>>  - your devel/acpi-s3.v7 branch directly
>>  - 3.2.7 merged with devel/acpi-s3.v7
>>  - 3.3-rc4 with devel/acpi-s3.v7
>=20
> OK. That is weird - it worked for me last time. One thing at at time th=
en -
> try doing this from text-mode, so no graphic mode involved. For that yo=
u might
> need to disable your i915 driver altogether. Then just run 'pm-suspend'=
 and
> see where it stops.
>=20
> The next part is... Wait a minute, this reminds me of something I encou=
ntered
> with a SandyBrige i2100 - the suspend would work, but resume would get =
stuck.
>=20
> The issue was with the hypervisor and if I had the acpi-cpufreq drivers=
 loaded
> it resumed just fine. If I didn't - so hypervisor had no idea about C s=
tates or
> P states, it would be stuck in the default_idle and never come back.
>=20
> So you might want for fun try also using the stable/processor-passthru.=
v5 and
> build it with CONFIG_XEN_PROCESSOR_PASSTHRU=3Dy.

Looks much better. At least for few suspend/resume it works. Thanks!
And: when is it planned to upstream above patches (acpi-s3 and
processor-passthru)?

--=20
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab


--------------enigDDFFD85ADBBE993ECF8F2F5E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPR7TQAAoJENuP0xzK19csTj0H/1TRJ7Kd5I/2aUiCLP4okVuL
xGde7Zw/vorQS7Z7B7O/IBtqdUaPiXXHpE1BvNkRE/463LilLvJ/7PWWXJUns2co
AKHUIuxacC0HuekGV+reU7m/cdvoP/dqiAOMj8r4F4UXQiYLh1/OVqqvW8cURCHd
9b1UeDDmWphn/r1MSc+tPaQjm+if8pRC76eWzuGk3YnQkPOPwrBwZFChArvbSo46
bmSFdH3Of20mr01I8fY5v4LXue2S8GIMLsy8L+fiyscfh3u8SO5Kguil1eXAk5xU
++hNLYgaI/tchDym9vSW2htOqAJp/DiDsC3dXDqu3WD9tFJ0l/YnepOXsGpW82Y=
=7+Jb
-----END PGP SIGNATURE-----

--------------enigDDFFD85ADBBE993ECF8F2F5E--


--===============4182788666694627997==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4182788666694627997==--


From xen-devel-bounces@lists.xen.org Fri Feb 24 16:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16: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 1S0xv7-0005yr-74; Fri, 24 Feb 2012 16:22:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0xv5-0005yf-Aq
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:22:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330100568!2526221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16608 invoked from network); 24 Feb 2012 16:22:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 16:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:22:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 16:22:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0xuy-0000nI-4S;
	Fri, 24 Feb 2012 16:22:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0xuy-0005Zb-3c;
	Fri, 24 Feb 2012 16:22:48 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12043-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 16:22:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12043: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12043 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12043/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  0c3d19f40ab1
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24885:0c3d19f40ab1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 22:16:32 2012 +0100
    
    mem_event: use C99 initializers for mem_event_request_t users
    
    Use C99 initializers for mem_event_request_t users to make sure req is
    always cleared, even with local debug patches that shuffle code around
    to have a single exit point.
    The common case is to use and send req, so it does not add significant
    overhead to always clear req.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24884:626fa29dc04d
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 22:09:40 2012 +0100
    
    mem_event: remove type member
    
    When mem_event was added the type flag should indicate who the consumer
    is. But the concept of a single ring buffer for multiple event types can
    not work for two reasons. One is that no multiplexer exists which
    provides individual event types to the final consumer, and second is
    that even if such multiplexer can not work reliable because a request
    needs to be answered with a response. The response should be sent
    roughly in the order of received events. But with multiple consumers one
    of them can so stall all the others.
    
    For that reason the single mem_event buffer for all types of events was
    split into individual ring buffers with commit 23842:483c5f8319ad. This
    commit made the type member already obsolete because the meaning of each
    buffer is now obvious.
    
    This change removes the type member and increases the flags field.
    
    Even though this is an ABI incompatible change, it will have no practical
    impact on existing binaries because the changeset referenced above already
    bumped the SONAME. So these binaries have to be recompiled anyway for the
    upcoming major release.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24883:adcd6ab160fa
user:        Tim Deegan <tim@xen.org>
date:        Thu Feb 23 10:29:27 2012 +0000
    
    x86/mm: Don't check for invalid bits in non-present PTEs.
    
    If _PAGE_PRESENT is clean in a pagetable entry, any pattern of bits
    is valid in the rest of the entry.  OSes that special-case
    PFEC_invalid_bits (since it should never happen) will be confused
    by our setting it in this way.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24882:3d4955cbcb67
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:19:57 2012 +0000
    
    libxl: Rename libxl_sched_* to include _domain
    
    In preparation for introducing a schedule parameter-based structure,
    rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
    
    No functional changes.
    
    v2: Wrap long lines while I'm at it
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24881:5b9d4bd3addf
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:50 2012 +0000
    
    libxc: Implement SCHEDOP sysctl for credit scheduler
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24880:dd9e8f1ebed1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:21 2012 +0000
    
    scheduler: Implement SCHEDOP sysctl for credit scheduler
    
    Allow tslice_ms and ratelimit_us to be modified.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24879:c4bddb3422dd
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:16:10 2012 +0000
    
    scheduler: Print ratelimit in scheduler debug key
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24878:8e672cd04864
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:15:40 2012 +0000
    
    scheduler: Add a #define for the default ratelimit
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24877:0c91a375f480
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:14:55 2012 +0000
    
    cleanup: Remove dependency files in efi directory during a make clean
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24876:7cf234b198a3
user:        Attilio Rao <attilio.rao@citrix.com>
date:        Thu Feb 23 10:11:58 2012 +0000
    
    hvmloader: Add OVMF UEFI support and directly use it
    ...when specified in the guest configuration file.
    
    This work is somewhat based on Bei Guan effort during the SoC 2011 and
    relies on upstream edk2/ovmf Tianocore ROM to be built separately and
    manually copied as:
    Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->
    tools/firmware/ovmf/ovmf-x64.bin
    Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd ->
    toolf/firmware/ovmf/ovmf-ia32.bin
    
    A way to integrate OVMF build directly into XEN has still be discussed
    on the mailing list appropriately.
    
    Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
    
    Disable CONFIG_OVMF by default as ovmf is not integrated into the
    build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24875:a59c1dcfe968
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:03:07 2012 +0000
    
    blkif.h: Define and document the request number/size/segments extension
    
    Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
          BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
          updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
          before being recompiled with a __XEN_INTERFACE_VERSION greater
          than or equal to this value.
    
    This extension first appeared in the FreeBSD Operating System.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24874:f9789db96c39
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:02:30 2012 +0000
    
    blkif.h: Document the Red Hat and Citrix blkif multi-page ring extensions
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24873:037537eff0c1
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:59 2012 +0000
    
    blkif.h: Provide more complete documentation of the blkif interface
    
      o Document the XenBus nodes used in this protocol.
      o Add a state diagram illustrating the roles and responsibilities
        of both the front and backend during startup.
      o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a
        comment.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24872:4e1460cd2227
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:26 2012 +0000
    
    blkif.h: Miscelaneous style fixes
    
      o Remove trailing whitespace.
      o Remove a blank line so that a comment block is adjacent to the
        code it documents.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24871:66cc5b67e749
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Feb 23 09:59:35 2012 +0000
    
    xen: add missing unlock from gnttab_get_version
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24870:9bf3ec036bef
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Thu Feb 23 09:58:47 2012 +0000
    
    IO-APIC: Prevent using EOI broadcast suppression if user specified ioapic_ack=new on the command line.
    
    Currently, if EOI broadcast suppression is advertised on the BSP
    LAPIC, Xen will discard any user specified option regarding IO-APIC
    ack mode.
    
    This patch introduces a check which prevents EOI Broadcast suppression
    from forcing the IO-APIC ack mode to old if the user has explicitly
    asked for the new ack mode on the command line.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24869:a4d93d0e0df2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Feb 22 14:33:24 2012 +0000
    
    arm: lr register in hyp mode is really LR_usr.
    
    Save and restore it in the same way for both hypervisor and user stack frames
    rather than saving both individually in the user stack frame.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16: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 1S0xv7-0005yr-74; Fri, 24 Feb 2012 16:22:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S0xv5-0005yf-Aq
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:22:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330100568!2526221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16608 invoked from network); 24 Feb 2012 16:22:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 16:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:22:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 16:22:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S0xuy-0000nI-4S;
	Fri, 24 Feb 2012 16:22:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S0xuy-0005Zb-3c;
	Fri, 24 Feb 2012 16:22:48 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12043-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 16:22:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12043: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12043 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12043/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  0c3d19f40ab1
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24885:0c3d19f40ab1
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 22:16:32 2012 +0100
    
    mem_event: use C99 initializers for mem_event_request_t users
    
    Use C99 initializers for mem_event_request_t users to make sure req is
    always cleared, even with local debug patches that shuffle code around
    to have a single exit point.
    The common case is to use and send req, so it does not add significant
    overhead to always clear req.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24884:626fa29dc04d
user:        Olaf Hering <olaf@aepfle.de>
date:        Mon Feb 20 22:09:40 2012 +0100
    
    mem_event: remove type member
    
    When mem_event was added the type flag should indicate who the consumer
    is. But the concept of a single ring buffer for multiple event types can
    not work for two reasons. One is that no multiplexer exists which
    provides individual event types to the final consumer, and second is
    that even if such multiplexer can not work reliable because a request
    needs to be answered with a response. The response should be sent
    roughly in the order of received events. But with multiple consumers one
    of them can so stall all the others.
    
    For that reason the single mem_event buffer for all types of events was
    split into individual ring buffers with commit 23842:483c5f8319ad. This
    commit made the type member already obsolete because the meaning of each
    buffer is now obvious.
    
    This change removes the type member and increases the flags field.
    
    Even though this is an ABI incompatible change, it will have no practical
    impact on existing binaries because the changeset referenced above already
    bumped the SONAME. So these binaries have to be recompiled anyway for the
    upcoming major release.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24883:adcd6ab160fa
user:        Tim Deegan <tim@xen.org>
date:        Thu Feb 23 10:29:27 2012 +0000
    
    x86/mm: Don't check for invalid bits in non-present PTEs.
    
    If _PAGE_PRESENT is clean in a pagetable entry, any pattern of bits
    is valid in the rest of the entry.  OSes that special-case
    PFEC_invalid_bits (since it should never happen) will be confused
    by our setting it in this way.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24882:3d4955cbcb67
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:19:57 2012 +0000
    
    libxl: Rename libxl_sched_* to include _domain
    
    In preparation for introducing a schedule parameter-based structure,
    rename libxl_sched_{credit,credit2,sedf} to libxl_sched_{}_domain.
    
    No functional changes.
    
    v2: Wrap long lines while I'm at it
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24881:5b9d4bd3addf
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:50 2012 +0000
    
    libxc: Implement SCHEDOP sysctl for credit scheduler
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24880:dd9e8f1ebed1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:17:21 2012 +0000
    
    scheduler: Implement SCHEDOP sysctl for credit scheduler
    
    Allow tslice_ms and ratelimit_us to be modified.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24879:c4bddb3422dd
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:16:10 2012 +0000
    
    scheduler: Print ratelimit in scheduler debug key
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24878:8e672cd04864
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:15:40 2012 +0000
    
    scheduler: Add a #define for the default ratelimit
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24877:0c91a375f480
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Feb 23 10:14:55 2012 +0000
    
    cleanup: Remove dependency files in efi directory during a make clean
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24876:7cf234b198a3
user:        Attilio Rao <attilio.rao@citrix.com>
date:        Thu Feb 23 10:11:58 2012 +0000
    
    hvmloader: Add OVMF UEFI support and directly use it
    ...when specified in the guest configuration file.
    
    This work is somewhat based on Bei Guan effort during the SoC 2011 and
    relies on upstream edk2/ovmf Tianocore ROM to be built separately and
    manually copied as:
    Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->
    tools/firmware/ovmf/ovmf-x64.bin
    Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd ->
    toolf/firmware/ovmf/ovmf-ia32.bin
    
    A way to integrate OVMF build directly into XEN has still be discussed
    on the mailing list appropriately.
    
    Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
    
    Disable CONFIG_OVMF by default as ovmf is not integrated into the
    build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24875:a59c1dcfe968
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:03:07 2012 +0000
    
    blkif.h: Define and document the request number/size/segments extension
    
    Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
          BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
          updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
          before being recompiled with a __XEN_INTERFACE_VERSION greater
          than or equal to this value.
    
    This extension first appeared in the FreeBSD Operating System.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24874:f9789db96c39
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:02:30 2012 +0000
    
    blkif.h: Document the Red Hat and Citrix blkif multi-page ring extensions
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24873:037537eff0c1
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:59 2012 +0000
    
    blkif.h: Provide more complete documentation of the blkif interface
    
      o Document the XenBus nodes used in this protocol.
      o Add a state diagram illustrating the roles and responsibilities
        of both the front and backend during startup.
      o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a
        comment.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24872:4e1460cd2227
user:        Justin T. Gibbs <justing@spectralogic.com>
date:        Thu Feb 23 10:01:26 2012 +0000
    
    blkif.h: Miscelaneous style fixes
    
      o Remove trailing whitespace.
      o Remove a blank line so that a comment block is adjacent to the
        code it documents.
    
    No functional changes.
    
    Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24871:66cc5b67e749
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Feb 23 09:59:35 2012 +0000
    
    xen: add missing unlock from gnttab_get_version
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24870:9bf3ec036bef
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Thu Feb 23 09:58:47 2012 +0000
    
    IO-APIC: Prevent using EOI broadcast suppression if user specified ioapic_ack=new on the command line.
    
    Currently, if EOI broadcast suppression is advertised on the BSP
    LAPIC, Xen will discard any user specified option regarding IO-APIC
    ack mode.
    
    This patch introduces a check which prevents EOI Broadcast suppression
    from forcing the IO-APIC ack mode to old if the user has explicitly
    asked for the new ack mode on the command line.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24869:a4d93d0e0df2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Feb 22 14:33:24 2012 +0000
    
    arm: lr register in hyp mode is really LR_usr.
    
    Save and restore it in the same way for both hypervisor and user stack frames
    rather than saving both individually in the user stack frame.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16: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 1S0y4n-0006Gi-11; Fri, 24 Feb 2012 16:32:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <harryxiyou@gmail.com>) id 1S0y4l-0006GN-8z
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:32:55 +0000
X-Env-Sender: harryxiyou@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330101168!14633638!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29943 invoked from network); 24 Feb 2012 16:32:48 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 16:32:48 -0000
Received: by lagr15 with SMTP id r15so1272495lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 24 Feb 2012 08:32:47 -0800 (PST)
Received-SPF: pass (google.com: domain of harryxiyou@gmail.com designates
	10.112.44.232 as permitted sender) client-ip=10.112.44.232; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of harryxiyou@gmail.com
	designates 10.112.44.232 as permitted sender)
	smtp.mail=harryxiyou@gmail.com;
	dkim=pass header.i=harryxiyou@gmail.com
Received: from mr.google.com ([10.112.44.232])
	by 10.112.44.232 with SMTP id h8mr1183965lbm.85.1330101167958 (num_hops
	= 1); Fri, 24 Feb 2012 08:32:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=wq6OsQ2IG1x7AcOnclUP1XjgmjQjWKs+G10bLlpbXBE=;
	b=QeoWiPHXhq/jKkt1yWXuBRZ++80m4D5jsxTb4iGavtkdxdNqfGj3rm1xh1g5wHg4OR
	aMXfnxIqAmztUjjHpOQFh33dKxD5QaFdrIs1gGEc13n6RziHmn9HSHpcGXsUo8uhjvsM
	MkUVlpkWDDmVSgnA/CDBDfctilVUf9GHbEwhQ=
MIME-Version: 1.0
Received: by 10.112.44.232 with SMTP id h8mr979641lbm.85.1330101167893; Fri,
	24 Feb 2012 08:32:47 -0800 (PST)
Received: by 10.112.81.2 with HTTP; Fri, 24 Feb 2012 08:32:47 -0800 (PST)
In-Reply-To: <CAFivhPmhcwg4=_7VZhfK0_kKp89XTHxxS=3bDv1ebChY7FQDuA@mail.gmail.com>
References: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
	<CAFivhPmhcwg4=_7VZhfK0_kKp89XTHxxS=3bDv1ebChY7FQDuA@mail.gmail.com>
Date: Sat, 25 Feb 2012 00:32:47 +0800
Message-ID: <CAD+1EGOzmtmnwv1UcXOq02z7RkLTDKGd=_EBeUTvChKvd36psg@mail.gmail.com>
From: harryxiyou <harryxiyou@gmail.com>
To: Florian Heigl <florian.heigl@gmail.com>
Cc: xen-users@lists.xen.org, cloudxy@googlegroups.com,
	xen-devel@lists.xensource.com, Kang Hua <kanghua151@gmail.com>,
	xen-bugs@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] [XEN]tap-err happens to me
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 4:22 AM, Florian Heigl <florian.heigl@gmail.com> wrote:
> Hi,

Hi Florian,

>
>
> 2012/2/23 harryxiyou <harryxiyou@gmail.com>:
>> Feb 24 02:52:17 local00212201021a tap-ctl: tap-err:tap_ctl_wait:
>> tapdisk2[31763] failed, status 127
>>
>> The log says tapdisk2 happens to an error.
>
> 127 is usually a file not found?
>

Yeah, you are right. We missed a dynamic shared lib file. I should think
more for this matter but a common sense. Anyway, it is solved now.
Thanks for your help ;-)


-- 
Thanks
Harry Wei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16: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 1S0y4n-0006Gi-11; Fri, 24 Feb 2012 16:32:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <harryxiyou@gmail.com>) id 1S0y4l-0006GN-8z
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:32:55 +0000
X-Env-Sender: harryxiyou@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330101168!14633638!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29943 invoked from network); 24 Feb 2012 16:32:48 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 16:32:48 -0000
Received: by lagr15 with SMTP id r15so1272495lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 24 Feb 2012 08:32:47 -0800 (PST)
Received-SPF: pass (google.com: domain of harryxiyou@gmail.com designates
	10.112.44.232 as permitted sender) client-ip=10.112.44.232; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of harryxiyou@gmail.com
	designates 10.112.44.232 as permitted sender)
	smtp.mail=harryxiyou@gmail.com;
	dkim=pass header.i=harryxiyou@gmail.com
Received: from mr.google.com ([10.112.44.232])
	by 10.112.44.232 with SMTP id h8mr1183965lbm.85.1330101167958 (num_hops
	= 1); Fri, 24 Feb 2012 08:32:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=wq6OsQ2IG1x7AcOnclUP1XjgmjQjWKs+G10bLlpbXBE=;
	b=QeoWiPHXhq/jKkt1yWXuBRZ++80m4D5jsxTb4iGavtkdxdNqfGj3rm1xh1g5wHg4OR
	aMXfnxIqAmztUjjHpOQFh33dKxD5QaFdrIs1gGEc13n6RziHmn9HSHpcGXsUo8uhjvsM
	MkUVlpkWDDmVSgnA/CDBDfctilVUf9GHbEwhQ=
MIME-Version: 1.0
Received: by 10.112.44.232 with SMTP id h8mr979641lbm.85.1330101167893; Fri,
	24 Feb 2012 08:32:47 -0800 (PST)
Received: by 10.112.81.2 with HTTP; Fri, 24 Feb 2012 08:32:47 -0800 (PST)
In-Reply-To: <CAFivhPmhcwg4=_7VZhfK0_kKp89XTHxxS=3bDv1ebChY7FQDuA@mail.gmail.com>
References: <CAD+1EGMdj5SfAPhDDN_NDBczQQb8eb4Pq+PJb_eCiEz+xh=4Ug@mail.gmail.com>
	<CAFivhPmhcwg4=_7VZhfK0_kKp89XTHxxS=3bDv1ebChY7FQDuA@mail.gmail.com>
Date: Sat, 25 Feb 2012 00:32:47 +0800
Message-ID: <CAD+1EGOzmtmnwv1UcXOq02z7RkLTDKGd=_EBeUTvChKvd36psg@mail.gmail.com>
From: harryxiyou <harryxiyou@gmail.com>
To: Florian Heigl <florian.heigl@gmail.com>
Cc: xen-users@lists.xen.org, cloudxy@googlegroups.com,
	xen-devel@lists.xensource.com, Kang Hua <kanghua151@gmail.com>,
	xen-bugs@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] [XEN]tap-err happens to me
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 4:22 AM, Florian Heigl <florian.heigl@gmail.com> wrote:
> Hi,

Hi Florian,

>
>
> 2012/2/23 harryxiyou <harryxiyou@gmail.com>:
>> Feb 24 02:52:17 local00212201021a tap-ctl: tap-err:tap_ctl_wait:
>> tapdisk2[31763] failed, status 127
>>
>> The log says tapdisk2 happens to an error.
>
> 127 is usually a file not found?
>

Yeah, you are right. We missed a dynamic shared lib file. I should think
more for this matter but a common sense. Anyway, it is solved now.
Thanks for your help ;-)


-- 
Thanks
Harry Wei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:40:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16: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 1S0yBg-0006eY-2m; Fri, 24 Feb 2012 16:40:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0yBe-0006eH-VR
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:40:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330101596!9654835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28635 invoked from network); 24 Feb 2012 16:39:56 -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;
	24 Feb 2012 16:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:39:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 16:39:56 +0000
Message-ID: <1330101594.8557.222.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 24 Feb 2012 16:39:54 +0000
In-Reply-To: <20120224153822.GA29117@aepfle.de>
References: <20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<20120224153822.GA29117@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 15:38 +0000, Olaf Hering wrote:
> On Fri, Feb 24, Ian Campbell wrote:
> 
> > Here is an updated version of my proposed interface which includes
> > sharing, I think as you described (modulo the use of mem-paging-set
> > where you said mem-set above).
> > 
> > I also included "mem-paging-set manual" as an explicit thing with an
> > error on "mem-paging-set N" if you don't switch to manual mode. This
> > might be too draconian -- I'm not wedded to it.
> > 
> > maxmem=X                        # maximum RAM the domain can ever see
> > memory=M                        # current amount of RAM seen by the
> > 				# domain
> > paging=[off|on]                 # allow the amount of memory a guest 
> >                                 # thinks it has to differ from the
> >                                 # amount actually available to it (its
> >                                 # "footprint")
> > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> >                                 # "footprint" for guests which do not
> >                                 # voluntarily obey changes to memory=M 
> > pagingdelay=60                  # amount of time to give a guest to 
> >                                 # voluntarily comply before enforcing a 
> >                                 # footprint
> > pagesharing=[off|on]		# cause this guest to share pages with
> > 				# other similarly enabled guests where
> > 				# possible. Requires paging=on.
> > pageextrapolocy=...		# controls what happens to extra pages 
> > 				# gain via sharing (could be combined 
> > 				# with pagesharing option:
> > 				#	[off|policy|...])
> > 
> >         Open question -- does pagesharing=on require paging=on? I've
> >         tried to specify things below such that it does not, but it
> >         might simplify things to require this.
> > 
> > xl mem-set domain M
> >         Sets the amount of RAM which the guest believes it has available
> >         to M. The guest should arrange to use only that much RAM and
> >         return the rest to the hypervisor (e.g. by using a balloon
> >         driver). If the guest does not do so then the host may use
> >         technical means to enforce the guest's footprint of M. The guest
> >         may suffer a performance penalty for this enforcement.
> > 
> >         paging off:     set balloon target to M.
> >         paging on:      set balloon target to M.
> >                         if pagingauto:
> >                                 wait delay IFF new target < old
> >                                 set paging target to M
> >                                 support -t <delay> to override default?
> 
> Instead of having two now config options pagingauto= and pagingdelay=,
> what about 'xl mem-set -t <seconds>' to adjust the fixed internal value
> pagingdelay=? Then '-t 0' could mean pagingauto=off, which means use
> both ballooning and paging to reach the "footprint" M.

So you mean:

	paging on:	set balloon target to M.
			if pagingdelay > 0:
				wait delay IFF new target < old
			else:
				pagingauto=off
			set paging target to M

or

	paging on:	set balloon target to M.
			if pagingdelay > 0:
				wait delay IFF new target < old
				set paging target to M
			else:
				pagingauto=off

? (the difference being whether or not we set the paging at all if delay
== 0). 

I don't think I like overloading "-t 0" to also turn off auto mode like
that. It makes it less explicit when you are disabling auto mode and
entering "you have to know what you are doing" territory.

With my original proposal you can do
	xl mem-set -t 0 D N
and that will do both paging and ballooning enabled but will stay in
auto mode, if that's what you want.

If you really want to also turn off auto mode then with my N-1th
proposal you would do:
	xl mem-set -t 0 D N && xl mem-paging-set D N
but that is more explicit about turning off auto mode. In my most recent
proposal you'd have to do :
	xl mem-set -t 0 D N && xl mem-paging-set D manual && xl mem-paging-set D N
which is a little _too_ explicit perhaps. I suspect the previous
proposal was preferable in this regard?

> 
> >         Open question -- if a domain balloons to M as requested should
> >         it still be subject to sharing? There is a performance hit
> >         associated with sharing (far less than paging though?) but
> >         presumably the admin would not have enabled sharing if they
> >         didn't want this, therefore I think it is right for sharing on
> >         to allow the guest to actually have <M assigned to it. Might be
> >         a function of the individual sharing policy?
> > 
> > xl mem-paging-set domain manual
> > 	Enables manual control of paging target.
> > 
> > 	paging off:	error
> > 	paging on:	set pagingauto=off
> > 	sharing on:	same as paging on.
> > 
> > xl mem-paging-set domain N
> >         Overrides the amount of RAM which the guest actually has
> >         available (its "footprint") to N. The host will use technical
> >         means to continue to provide the illusion to the guest that it
> >         has memory=M (as adjusted by mem-set). There may be a
> >         performance penalty for this.
> >         
> >         paging off:     error
> 
> Could this be the time to start the pager and give it target N?

Here and at the appropriate time when auto=true.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:40:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16: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 1S0yBg-0006eY-2m; Fri, 24 Feb 2012 16:40:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0yBe-0006eH-VR
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:40:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330101596!9654835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28635 invoked from network); 24 Feb 2012 16:39:56 -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;
	24 Feb 2012 16:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:39:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 16:39:56 +0000
Message-ID: <1330101594.8557.222.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 24 Feb 2012 16:39:54 +0000
In-Reply-To: <20120224153822.GA29117@aepfle.de>
References: <20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<20120224153822.GA29117@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Andres
	Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 15:38 +0000, Olaf Hering wrote:
> On Fri, Feb 24, Ian Campbell wrote:
> 
> > Here is an updated version of my proposed interface which includes
> > sharing, I think as you described (modulo the use of mem-paging-set
> > where you said mem-set above).
> > 
> > I also included "mem-paging-set manual" as an explicit thing with an
> > error on "mem-paging-set N" if you don't switch to manual mode. This
> > might be too draconian -- I'm not wedded to it.
> > 
> > maxmem=X                        # maximum RAM the domain can ever see
> > memory=M                        # current amount of RAM seen by the
> > 				# domain
> > paging=[off|on]                 # allow the amount of memory a guest 
> >                                 # thinks it has to differ from the
> >                                 # amount actually available to it (its
> >                                 # "footprint")
> > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> >                                 # "footprint" for guests which do not
> >                                 # voluntarily obey changes to memory=M 
> > pagingdelay=60                  # amount of time to give a guest to 
> >                                 # voluntarily comply before enforcing a 
> >                                 # footprint
> > pagesharing=[off|on]		# cause this guest to share pages with
> > 				# other similarly enabled guests where
> > 				# possible. Requires paging=on.
> > pageextrapolocy=...		# controls what happens to extra pages 
> > 				# gain via sharing (could be combined 
> > 				# with pagesharing option:
> > 				#	[off|policy|...])
> > 
> >         Open question -- does pagesharing=on require paging=on? I've
> >         tried to specify things below such that it does not, but it
> >         might simplify things to require this.
> > 
> > xl mem-set domain M
> >         Sets the amount of RAM which the guest believes it has available
> >         to M. The guest should arrange to use only that much RAM and
> >         return the rest to the hypervisor (e.g. by using a balloon
> >         driver). If the guest does not do so then the host may use
> >         technical means to enforce the guest's footprint of M. The guest
> >         may suffer a performance penalty for this enforcement.
> > 
> >         paging off:     set balloon target to M.
> >         paging on:      set balloon target to M.
> >                         if pagingauto:
> >                                 wait delay IFF new target < old
> >                                 set paging target to M
> >                                 support -t <delay> to override default?
> 
> Instead of having two now config options pagingauto= and pagingdelay=,
> what about 'xl mem-set -t <seconds>' to adjust the fixed internal value
> pagingdelay=? Then '-t 0' could mean pagingauto=off, which means use
> both ballooning and paging to reach the "footprint" M.

So you mean:

	paging on:	set balloon target to M.
			if pagingdelay > 0:
				wait delay IFF new target < old
			else:
				pagingauto=off
			set paging target to M

or

	paging on:	set balloon target to M.
			if pagingdelay > 0:
				wait delay IFF new target < old
				set paging target to M
			else:
				pagingauto=off

? (the difference being whether or not we set the paging at all if delay
== 0). 

I don't think I like overloading "-t 0" to also turn off auto mode like
that. It makes it less explicit when you are disabling auto mode and
entering "you have to know what you are doing" territory.

With my original proposal you can do
	xl mem-set -t 0 D N
and that will do both paging and ballooning enabled but will stay in
auto mode, if that's what you want.

If you really want to also turn off auto mode then with my N-1th
proposal you would do:
	xl mem-set -t 0 D N && xl mem-paging-set D N
but that is more explicit about turning off auto mode. In my most recent
proposal you'd have to do :
	xl mem-set -t 0 D N && xl mem-paging-set D manual && xl mem-paging-set D N
which is a little _too_ explicit perhaps. I suspect the previous
proposal was preferable in this regard?

> 
> >         Open question -- if a domain balloons to M as requested should
> >         it still be subject to sharing? There is a performance hit
> >         associated with sharing (far less than paging though?) but
> >         presumably the admin would not have enabled sharing if they
> >         didn't want this, therefore I think it is right for sharing on
> >         to allow the guest to actually have <M assigned to it. Might be
> >         a function of the individual sharing policy?
> > 
> > xl mem-paging-set domain manual
> > 	Enables manual control of paging target.
> > 
> > 	paging off:	error
> > 	paging on:	set pagingauto=off
> > 	sharing on:	same as paging on.
> > 
> > xl mem-paging-set domain N
> >         Overrides the amount of RAM which the guest actually has
> >         available (its "footprint") to N. The host will use technical
> >         means to continue to provide the illusion to the guest that it
> >         has memory=M (as adjusted by mem-set). There may be a
> >         performance penalty for this.
> >         
> >         paging off:     error
> 
> Could this be the time to start the pager and give it target N?

Here and at the appropriate time when auto=true.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:40:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yBx-0006g6-Ff; Fri, 24 Feb 2012 16:40:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1S0yBv-0006fR-Ec
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 16:40:19 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330101611!16315954!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NjQ4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17316 invoked from network); 24 Feb 2012 16:40:12 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-216.messagelabs.com with SMTP;
	24 Feb 2012 16:40:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2012 08:39:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="111587488"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 24 Feb 2012 08:38:55 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 00:38:54 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 00:38:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sat, 25 Feb 2012 00:38:53 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH] tools: fix python version checking issue in configuration
Thread-Index: AczzEsFxFaVasOuPRgurzqJpZDOUDg==
Date: Fri, 24 Feb 2012 16:38:52 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>
Subject: [Xen-devel] [PATCH] tools: fix python version checking issue in
	configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Even if python version is 2.4.3 which is newer than the required version 2.3, the configure script still raises a version issue.
I tested my patch with python 2.6.6 and 2.4.3. It will fix a syntax error like the following.
checking for python version >= 2.3 ... Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: 'str' object is not callable
no
configure: error: Python 2.4.3 is too old, minimum required version is 2.3

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
--

tools/configure |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -r a4d93d0e0df2 tools/configure
--- a/tools/configure   Wed Feb 22 14:33:24 2012 +0000
+++ b/tools/configure   Fri Feb 24 21:18:31 2012 +0800
@@ -6293,7 +6293,7 @@
 fi
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python version >= 2.3 " >&5
 $as_echo_n "checking for python version >= 2.3 ... " >&6; }
-`$PYTHON -c 'import sys; exit(eval("sys.version_info < (2, 3)"))'`
+`$PYTHON -c 'import sys; sys.exit(eval("sys.version_info < (2, 3)"))'`
 if test "$?" != "0"
 then
     python_version=`$PYTHON -V 2>&1`



Best Regards,
     Yongjie Ren  (Jay)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:40:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yBx-0006g6-Ff; Fri, 24 Feb 2012 16:40:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1S0yBv-0006fR-Ec
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 16:40:19 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330101611!16315954!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5NjQ4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17316 invoked from network); 24 Feb 2012 16:40:12 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-216.messagelabs.com with SMTP;
	24 Feb 2012 16:40:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2012 08:39:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="111587488"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 24 Feb 2012 08:38:55 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 00:38:54 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 00:38:54 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sat, 25 Feb 2012 00:38:53 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH] tools: fix python version checking issue in configuration
Thread-Index: AczzEsFxFaVasOuPRgurzqJpZDOUDg==
Date: Fri, 24 Feb 2012 16:38:52 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>
Subject: [Xen-devel] [PATCH] tools: fix python version checking issue in
	configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Even if python version is 2.4.3 which is newer than the required version 2.3, the configure script still raises a version issue.
I tested my patch with python 2.6.6 and 2.4.3. It will fix a syntax error like the following.
checking for python version >= 2.3 ... Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: 'str' object is not callable
no
configure: error: Python 2.4.3 is too old, minimum required version is 2.3

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
--

tools/configure |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -r a4d93d0e0df2 tools/configure
--- a/tools/configure   Wed Feb 22 14:33:24 2012 +0000
+++ b/tools/configure   Fri Feb 24 21:18:31 2012 +0800
@@ -6293,7 +6293,7 @@
 fi
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python version >= 2.3 " >&5
 $as_echo_n "checking for python version >= 2.3 ... " >&6; }
-`$PYTHON -c 'import sys; exit(eval("sys.version_info < (2, 3)"))'`
+`$PYTHON -c 'import sys; sys.exit(eval("sys.version_info < (2, 3)"))'`
 if test "$?" != "0"
 then
     python_version=`$PYTHON -V 2>&1`



Best Regards,
     Yongjie Ren  (Jay)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:50:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yLb-00074K-IT; Fri, 24 Feb 2012 16:50:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0yLa-00074F-5o
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330102211!9575667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13493 invoked from network); 24 Feb 2012 16:50:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 16:50:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:50:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 16:50:10 +0000
Message-ID: <1330102209.8557.224.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 16:50:09 +0000
In-Reply-To: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
>      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
>  }
>  
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +        unsigned long mfn)
> +{
> +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> +                              (gpfn + 1) << PAGE_SHIFT,
> +                              mfn << PAGE_SHIFT);
> +} 

This doesn't actually end up getting called from the common code bits
which should call it. Think we need this on top.

You can fold into your patch if you prefer.

8<--------------------------------------------

>From 7d26c508e3ef52dcddf562ba506b384a77423919 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 24 Feb 2012 16:43:11 +0000
Subject: [PATCH] arm: define CONFIG_PAGING_ASSISTANCE

This is needed for common code (e.g. XENMEM_populate_physmap) to actually call
guest_phys_map. Adjust the API to match what the common code expects.
Implement a dummy guest_physmap_remove_page.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c            |    2 +-
 xen/arch/arm/p2m.c           |   15 ++++++++++++---
 xen/include/asm-arm/config.h |    2 ++
 xen/include/asm-arm/p2m.h    |   11 +++++++++--
 xen/include/asm-arm/paging.h |    3 +++
 5 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0fe0398..cf3de8a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -380,7 +380,7 @@ static int xenmem_add_to_physmap_once(
     domain_lock(d);
 
     /* Map at new location. */
-    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
+    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
 
     domain_unlock(d);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1a00a50..4c94ef0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -177,14 +177,23 @@ int map_mmio_regions(struct domain *d,
     return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
 }
 
-int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
-        unsigned long mfn)
+int guest_physmap_add_page(struct domain *d,
+                           unsigned long gpfn,
+                           unsigned long mfn,
+                           unsigned int page_order)
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
-                              (gpfn + 1) << PAGE_SHIFT,
+                              (gpfn + (1<<page_order)) << PAGE_SHIFT,
                               mfn << PAGE_SHIFT);
 }
 
+void guest_physmap_remove_page(struct domain *d,
+                               unsigned long gpfn,
+                               unsigned long mfn, unsigned int page_order)
+{
+    ASSERT(0);
+}
+
 int p2m_alloc_table(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index c2ab0a2..63fb48e 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -7,6 +7,8 @@
 #ifndef __ARM_CONFIG_H__
 #define __ARM_CONFIG_H__
 
+#define CONFIG_PAGING_ASSISTANCE 1
+
 #define CONFIG_PAGING_LEVELS 3
 
 #define CONFIG_ARM 1
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index c0f2995..d8e8dc8 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -39,8 +39,15 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
  * address maddr. */
 int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
                      paddr_t end_gaddr, paddr_t maddr);
-int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
-        unsigned long mfn);
+
+/* Untyped version for RAM only, for compatibility */
+int guest_physmap_add_page(struct domain *d,
+                           unsigned long gfn,
+                           unsigned long mfn,
+                           unsigned int page_order);
+void guest_physmap_remove_page(struct domain *d,
+                               unsigned long gpfn,
+                               unsigned long mfn, unsigned int page_order);
 
 unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
index 4dc340f..3d7dd95 100644
--- a/xen/include/asm-arm/paging.h
+++ b/xen/include/asm-arm/paging.h
@@ -1,6 +1,9 @@
 #ifndef _XEN_PAGING_H
 #define _XEN_PAGING_H
 
+#define paging_mode_translate(d)              (0)
+#define paging_mode_external(d)               (0)
+
 #endif /* XEN_PAGING_H */
 
 /*
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:50:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yLb-00074K-IT; Fri, 24 Feb 2012 16:50:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0yLa-00074F-5o
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330102211!9575667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13493 invoked from network); 24 Feb 2012 16:50:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 16:50:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:50:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 16:50:10 +0000
Message-ID: <1330102209.8557.224.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 16:50:09 +0000
In-Reply-To: <1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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 Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
>      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
>  }
>  
> +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> +        unsigned long mfn)
> +{
> +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> +                              (gpfn + 1) << PAGE_SHIFT,
> +                              mfn << PAGE_SHIFT);
> +} 

This doesn't actually end up getting called from the common code bits
which should call it. Think we need this on top.

You can fold into your patch if you prefer.

8<--------------------------------------------

>From 7d26c508e3ef52dcddf562ba506b384a77423919 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 24 Feb 2012 16:43:11 +0000
Subject: [PATCH] arm: define CONFIG_PAGING_ASSISTANCE

This is needed for common code (e.g. XENMEM_populate_physmap) to actually call
guest_phys_map. Adjust the API to match what the common code expects.
Implement a dummy guest_physmap_remove_page.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c            |    2 +-
 xen/arch/arm/p2m.c           |   15 ++++++++++++---
 xen/include/asm-arm/config.h |    2 ++
 xen/include/asm-arm/p2m.h    |   11 +++++++++--
 xen/include/asm-arm/paging.h |    3 +++
 5 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0fe0398..cf3de8a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -380,7 +380,7 @@ static int xenmem_add_to_physmap_once(
     domain_lock(d);
 
     /* Map at new location. */
-    rc = guest_physmap_add_page(d, xatp->gpfn, mfn);
+    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
 
     domain_unlock(d);
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1a00a50..4c94ef0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -177,14 +177,23 @@ int map_mmio_regions(struct domain *d,
     return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
 }
 
-int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
-        unsigned long mfn)
+int guest_physmap_add_page(struct domain *d,
+                           unsigned long gpfn,
+                           unsigned long mfn,
+                           unsigned int page_order)
 {
     return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
-                              (gpfn + 1) << PAGE_SHIFT,
+                              (gpfn + (1<<page_order)) << PAGE_SHIFT,
                               mfn << PAGE_SHIFT);
 }
 
+void guest_physmap_remove_page(struct domain *d,
+                               unsigned long gpfn,
+                               unsigned long mfn, unsigned int page_order)
+{
+    ASSERT(0);
+}
+
 int p2m_alloc_table(struct domain *d)
 {
     struct p2m_domain *p2m = &d->arch.p2m;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index c2ab0a2..63fb48e 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -7,6 +7,8 @@
 #ifndef __ARM_CONFIG_H__
 #define __ARM_CONFIG_H__
 
+#define CONFIG_PAGING_ASSISTANCE 1
+
 #define CONFIG_PAGING_LEVELS 3
 
 #define CONFIG_ARM 1
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index c0f2995..d8e8dc8 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -39,8 +39,15 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
  * address maddr. */
 int map_mmio_regions(struct domain *d, paddr_t start_gaddr,
                      paddr_t end_gaddr, paddr_t maddr);
-int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
-        unsigned long mfn);
+
+/* Untyped version for RAM only, for compatibility */
+int guest_physmap_add_page(struct domain *d,
+                           unsigned long gfn,
+                           unsigned long mfn,
+                           unsigned int page_order);
+void guest_physmap_remove_page(struct domain *d,
+                               unsigned long gpfn,
+                               unsigned long mfn, unsigned int page_order);
 
 unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
diff --git a/xen/include/asm-arm/paging.h b/xen/include/asm-arm/paging.h
index 4dc340f..3d7dd95 100644
--- a/xen/include/asm-arm/paging.h
+++ b/xen/include/asm-arm/paging.h
@@ -1,6 +1,9 @@
 #ifndef _XEN_PAGING_H
 #define _XEN_PAGING_H
 
+#define paging_mode_translate(d)              (0)
+#define paging_mode_external(d)               (0)
+
 #endif /* XEN_PAGING_H */
 
 /*
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:51:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:51:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yMp-00077b-13; Fri, 24 Feb 2012 16:51: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 1S0yMn-00077U-FJ
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:51:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330102246!61582780!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26323 invoked from network); 24 Feb 2012 16:50:46 -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 Feb 2012 16:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:51:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 16:51:32 +0000
Message-ID: <1330102290.8557.225.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 16:51:30 +0000
In-Reply-To: <20295.45030.867821.388716@mariner.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<20295.32799.308331.653289@mariner.uk.xensource.com>
	<1330087322.8557.195.camel@zakaz.uk.xensource.com>
	<20295.45030.867821.388716@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(I could have sworn I hit send on this. apologies if you get it twice
somehow)

On Fri, 2012-02-24 at 15:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.
> > 
> > -D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
> > perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?
> 
> That would be a possibility but if we define it in libxl.h that will
> fix the problem, if we are happy for libxl callers to be using
> hypervisor public headers.
> 
> > We can stop xl by just not doing it (TM), for other callers of libxl --
> > well, we say you shouldn't need it for toolstack operations and that
> > libxl should provide all the functionality but if they _really_ want to
> > ignore that...
> > 
> > Also a toolstack may have functionality which is not considered
> > "toolstack functionality" per the remit of libxl and for which they wish
> > to use xenctrl directly. e.g. perhaps they communicate with a guest
> > agent using their own shared ring protocol for which they require the
> > ability to map domain memory.
> 
> How about the patch below.  This would be an alternative to your
> version which buries all the hypervisor public headers.

It's clever, some might say too clever ;-)

I'm a bit concerned about the use of domctl and sysctl in the libxl API
anyway -- I'm not convinced those are guaranteed to be stable ABIs by
the hypervisor (in fact, I'm reasonably sure they are not -- hence the
#error), in which case we mustn't expose them to libxl's users.

sched.h concerns me less -- that one is guest visible API IIRC and
therefore stable. But sched.h doesn't have a #error in it so isn't a
problem.

So I think we have to take the first of my patches. At which point we
can avoid the twisty maze of your patch using -U... as necessary.

Ian.

> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: Forbid <xenctrl.h>, allow Xen public headers
> 
> Rationalise and enforce the header-inclusion policy for libxl.
> 
> libxl applications are allowed to use symbols (mostly #defines) from
> the Xen public headers, where these are useful (for example, where
> they are the numeric arguments to libxl calls).  This avoids us having
> to veneer the whole of the Xen public API.  For this to work without
> special measures on the part of the application, libxl.h should define
> __XEN_TOOLS__.
> 
> However libxl applications are not normally expected to want to use
> libxc directly, so take steps to prevent them including <xenctrl.h>
> unless they declare (as libxl itself does) that doing so is OK by
> defining LIBXL_ALLOW_XENCTRL.  (We have to add a hook at the end of
> xenctrl.h so that we can spot the case where xenctrl.h is included
> second.)
> 
> Make xc.c comply with the policy: remove the redundant inclusion of
> xenctrl.h.
> 
> This patch should make life easier for out-of-tree libxl callers and
> hopefully prevent future mistakes relating to api visibility.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> ---
>  tools/libxc/xenctrl.h        |    4 ++++
>  tools/libxl/libxl.h          |   10 ++++++++++
>  tools/libxl/libxl_internal.h |    2 ++
>  tools/libxl/xl.c             |    1 -
>  4 files changed, 16 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> index 73d24e5..8441b62 100644
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -2047,4 +2047,8 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
>  				   unsigned long compbuf_size,
>  				   unsigned long *compbuf_pos, char *dest);
>  
> +#ifdef XENCTRL_DO_INCLUDE
> +#include XENCTRL_DO_INCLUDE
> +#endif
> +
>  #endif /* XENCTRL_H */
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 1bffa03..86a308d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -124,9 +124,19 @@
>   * Therefore public functions which initialize a libxl__gc MUST call
>   * libxl__free_all() before returning.
>   */
> +
> +#if !defined(LIBXL_ALLOW_XENCTRL)
> +#ifdef XENCTRL_H
> +#error applications which use libxl should not normally use xenctrl.h too
> +#endif
> +#define XENCTRL_DO_INCLUDE <libxl.h> /* spot if xenctrl.h came second */
> +#endif /* !defined(LIBXL_ALLOW_XENCTRL) */
> +
>  #ifndef LIBXL_H
>  #define LIBXL_H
>  
> +#define __XEN_TOOLS__ 1
> +
>  #include <stdbool.h>
>  #include <stdint.h>
>  #include <stdarg.h>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 46e131a..478de48 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -17,6 +17,8 @@
>  #ifndef LIBXL_INTERNAL_H
>  #define LIBXL_INTERNAL_H
>  
> +#define LIBXL_ALLOW_XENCTRL
> +
>  #include "libxl_osdeps.h" /* must come before any other headers */
>  
>  #include <assert.h>
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index df9b1e7..2b14814 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -26,7 +26,6 @@
>  #include <fcntl.h>
>  #include <ctype.h>
>  #include <inttypes.h>
> -#include <xenctrl.h>
>  
>  #include "libxl.h"
>  #include "libxl_utils.h"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 16:51:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 16:51:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yMp-00077b-13; Fri, 24 Feb 2012 16:51: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 1S0yMn-00077U-FJ
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 16:51:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330102246!61582780!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26323 invoked from network); 24 Feb 2012 16:50:46 -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 Feb 2012 16:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10925919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 16:51:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 16:51:32 +0000
Message-ID: <1330102290.8557.225.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 16:51:30 +0000
In-Reply-To: <20295.45030.867821.388716@mariner.uk.xensource.com>
References: <4F427C2B0200003000000BDD@novprvlin0050.provo.novell.com>
	<20291.56383.499378.463797@mariner.uk.xensource.com>
	<4F45109C02000030000011FC@novprvlin0050.provo.novell.com>
	<20292.55062.209546.961330@mariner.uk.xensource.com>
	<4F4560BC.30002@suse.com>
	<20295.32799.308331.653289@mariner.uk.xensource.com>
	<1330087322.8557.195.camel@zakaz.uk.xensource.com>
	<20295.45030.867821.388716@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of
 libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(I could have sworn I hit send on this. apologies if you get it twice
somehow)

On Fri, 2012-02-24 at 15:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-devel] [PATCH] libxl: fix compile error of libvirt"):
> > We should arrange for xl*.c to not have __XEN_TOOLS__ defined though.
> > 
> > -D__XEN_TOOLS__ is part of the base CFLAGS defined in tools/Rules.mk but
> > perhaps we could add -U__XEN_TOOLS__ to the xl specific cflags?
> 
> That would be a possibility but if we define it in libxl.h that will
> fix the problem, if we are happy for libxl callers to be using
> hypervisor public headers.
> 
> > We can stop xl by just not doing it (TM), for other callers of libxl --
> > well, we say you shouldn't need it for toolstack operations and that
> > libxl should provide all the functionality but if they _really_ want to
> > ignore that...
> > 
> > Also a toolstack may have functionality which is not considered
> > "toolstack functionality" per the remit of libxl and for which they wish
> > to use xenctrl directly. e.g. perhaps they communicate with a guest
> > agent using their own shared ring protocol for which they require the
> > ability to map domain memory.
> 
> How about the patch below.  This would be an alternative to your
> version which buries all the hypervisor public headers.

It's clever, some might say too clever ;-)

I'm a bit concerned about the use of domctl and sysctl in the libxl API
anyway -- I'm not convinced those are guaranteed to be stable ABIs by
the hypervisor (in fact, I'm reasonably sure they are not -- hence the
#error), in which case we mustn't expose them to libxl's users.

sched.h concerns me less -- that one is guest visible API IIRC and
therefore stable. But sched.h doesn't have a #error in it so isn't a
problem.

So I think we have to take the first of my patches. At which point we
can avoid the twisty maze of your patch using -U... as necessary.

Ian.

> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: Forbid <xenctrl.h>, allow Xen public headers
> 
> Rationalise and enforce the header-inclusion policy for libxl.
> 
> libxl applications are allowed to use symbols (mostly #defines) from
> the Xen public headers, where these are useful (for example, where
> they are the numeric arguments to libxl calls).  This avoids us having
> to veneer the whole of the Xen public API.  For this to work without
> special measures on the part of the application, libxl.h should define
> __XEN_TOOLS__.
> 
> However libxl applications are not normally expected to want to use
> libxc directly, so take steps to prevent them including <xenctrl.h>
> unless they declare (as libxl itself does) that doing so is OK by
> defining LIBXL_ALLOW_XENCTRL.  (We have to add a hook at the end of
> xenctrl.h so that we can spot the case where xenctrl.h is included
> second.)
> 
> Make xc.c comply with the policy: remove the redundant inclusion of
> xenctrl.h.
> 
> This patch should make life easier for out-of-tree libxl callers and
> hopefully prevent future mistakes relating to api visibility.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> ---
>  tools/libxc/xenctrl.h        |    4 ++++
>  tools/libxl/libxl.h          |   10 ++++++++++
>  tools/libxl/libxl_internal.h |    2 ++
>  tools/libxl/xl.c             |    1 -
>  4 files changed, 16 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> index 73d24e5..8441b62 100644
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -2047,4 +2047,8 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
>  				   unsigned long compbuf_size,
>  				   unsigned long *compbuf_pos, char *dest);
>  
> +#ifdef XENCTRL_DO_INCLUDE
> +#include XENCTRL_DO_INCLUDE
> +#endif
> +
>  #endif /* XENCTRL_H */
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 1bffa03..86a308d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -124,9 +124,19 @@
>   * Therefore public functions which initialize a libxl__gc MUST call
>   * libxl__free_all() before returning.
>   */
> +
> +#if !defined(LIBXL_ALLOW_XENCTRL)
> +#ifdef XENCTRL_H
> +#error applications which use libxl should not normally use xenctrl.h too
> +#endif
> +#define XENCTRL_DO_INCLUDE <libxl.h> /* spot if xenctrl.h came second */
> +#endif /* !defined(LIBXL_ALLOW_XENCTRL) */
> +
>  #ifndef LIBXL_H
>  #define LIBXL_H
>  
> +#define __XEN_TOOLS__ 1
> +
>  #include <stdbool.h>
>  #include <stdint.h>
>  #include <stdarg.h>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 46e131a..478de48 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -17,6 +17,8 @@
>  #ifndef LIBXL_INTERNAL_H
>  #define LIBXL_INTERNAL_H
>  
> +#define LIBXL_ALLOW_XENCTRL
> +
>  #include "libxl_osdeps.h" /* must come before any other headers */
>  
>  #include <assert.h>
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index df9b1e7..2b14814 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -26,7 +26,6 @@
>  #include <fcntl.h>
>  #include <ctype.h>
>  #include <inttypes.h>
> -#include <xenctrl.h>
>  
>  #include "libxl.h"
>  #include "libxl_utils.h"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 17:03:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 17:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yYM-0007Vv-Fr; Fri, 24 Feb 2012 17:03:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0yYK-0007Vq-Bs
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 17:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1330103002!16251517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12881 invoked from network); 24 Feb 2012 17:03:22 -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;
	24 Feb 2012 17:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10926186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 17:03:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 17:03:21 +0000
Message-ID: <1330103000.8557.227.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 17:03:20 +0000
In-Reply-To: <alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
	<4F476C0E.2010107@citrix.com>
	<alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 14:15 +0000, Stefano Stabellini wrote:
> On Fri, 24 Feb 2012, David Vrabel wrote:
> > On 24/02/12 10:33, Ian Campbell wrote:
> > > On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > >> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> > >> we reserve for Xen usage.
> > > 
> > > Does this require a trap when the guest acks or EOIs this interrupt?
> > > What about maintenance interrupts arising from injecting this?
> 
> Yes, we would get a maintenance interrupt in the hypervisor every time
> the guest EOI's it.

We really want to avoid those.

> > > Might we want to instead inject this interrupt as an SGI, so that it
> > > appears as a per-VCPU interrupt?
> > 
> > I don't think it's possible to register a SGI handler in Linux
> > currently.  The mapping of IRQ numbers to GIC interrupts skips over the
> > SGIs.  This would be easy to fix I think.
> 
> A per-vcpu interrupt that doesn't require an EOI would be ideal, however
> like David wrote, it is not possible to register an SGI handler in Linux
> at the moment. I'll give it a look though.

Do SGIs avoid the EOI and maintenance interrupt issues though?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 17:03:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 17:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0yYM-0007Vv-Fr; Fri, 24 Feb 2012 17:03:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S0yYK-0007Vq-Bs
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 17:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1330103002!16251517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12881 invoked from network); 24 Feb 2012 17:03:22 -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;
	24 Feb 2012 17:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="10926186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 17:03:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 17:03:21 +0000
Message-ID: <1330103000.8557.227.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 24 Feb 2012 17:03:20 +0000
In-Reply-To: <alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
	<4F476C0E.2010107@citrix.com>
	<alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 14:15 +0000, Stefano Stabellini wrote:
> On Fri, 24 Feb 2012, David Vrabel wrote:
> > On 24/02/12 10:33, Ian Campbell wrote:
> > > On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > >> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> > >> we reserve for Xen usage.
> > > 
> > > Does this require a trap when the guest acks or EOIs this interrupt?
> > > What about maintenance interrupts arising from injecting this?
> 
> Yes, we would get a maintenance interrupt in the hypervisor every time
> the guest EOI's it.

We really want to avoid those.

> > > Might we want to instead inject this interrupt as an SGI, so that it
> > > appears as a per-VCPU interrupt?
> > 
> > I don't think it's possible to register a SGI handler in Linux
> > currently.  The mapping of IRQ numbers to GIC interrupts skips over the
> > SGIs.  This would be easy to fix I think.
> 
> A per-vcpu interrupt that doesn't require an EOI would be ideal, however
> like David wrote, it is not possible to register an SGI handler in Linux
> at the moment. I'll give it a look though.

Do SGIs avoid the EOI and maintenance interrupt issues though?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 17:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 17: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 1S0yhW-0007fj-I5; Fri, 24 Feb 2012 17:12:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0yhU-0007fe-2U
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 17:12:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330103568!9954390!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk0MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6069 invoked from network); 24 Feb 2012 17:12:49 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	24 Feb 2012 17:12:49 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 1A6CF5EC07C;
	Fri, 24 Feb 2012 09:12:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=jEcgCJqoKLdIHwo6R0dKbdSIXRfw8t8Ks1i/zFtSXiHK
	NFKqjyHrJHkKHLldFvzewRRrPGEDn+cxEz9LKE3vmyMUstdW4+uYPa0ljHiRJP5B
	+c4YNKYc4WQZeFFbEkkOoW/bEk02j2o/Dn5sj+0Ae0mDx/PoHyXt+6yPR6Zs1lk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=UDuPo9gSB49VMlOKOae29//dtC4=; b=Ju0ELQQN
	1Z88FEZrDcvj1w9Q5gI2gA/qhRtTi5I0oFLRdMKuh2K4Du2z1z2ZNLR1Uk5hH2DG
	i9P3y4p7pfPph9TDilWE+7aZS4kddaZn4kRGlSibYz1D5mdZjTYgp83yeGcMcq4N
	Zvas2esitNkXtpEOmAQieFwTutKeyYazXvc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 776875EC072; 
	Fri, 24 Feb 2012 09:12:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 24 Feb 2012 09:12:48 -0800
Message-ID: <c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330078304.8557.157.camel@zakaz.uk.xensource.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
Date: Fri, 24 Feb 2012 09:12:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 12:18 +0000, George Dunlap wrote:
>> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
>> > What if you switch back without making sure you are in such a state? I
>> > think switching between the two is where the potential for unexpected
>> > behaviour is most likely.
>>
>> Yeah, correctly predicting what would happen requires understanding what
>> mem-set does under the hood.
>>
>> > I like that you have to explicitly ask for the safety wheels to come
>> off
>> > and explicitly put them back on again. It avoids the corner cases I
>> > alluded to above (at least I hope so).
>>
>> Yes, I think your suggestion sounds more like driving a car with a
>> proper hood, and less like driving a go-kart with the engine
>> exposed. :-)
>
> yeah, I'm way past "live fast die young" ;-)
>
>>
>> > Without wishing to put words in Andres' mouth I expect that he
>> intended
>> > "footprint" to cover other technical means than paging too --
>> > specifically I expect he was thinking of page sharing. (I suppose it
>> > also covers PoD to some extent too, although that is something of a
>> > special case)
>> >
>> > While I don't expect there will be a knob to control number of shared
>> > pages (either you can share some pages or not, the settings would be
>> > more about how aggressively you search for sharable pages) it might be
>> > useful to consider the interaction between paging and sharing, I
>> expect
>> > that most sharing configurations would want to have paging on at the
>> > same time (for safety). It seems valid to me to want to say "make the
>> > guest use this amount of actual RAM" and to achieve that by sharing
>> what
>> > you can and then paging the rest.
>>
>> Yes, it's worth thinking about; as long as it doesn't stall the paging
>> UI too long. :-)
>
> Right. I think the only issue here is whether we make the control called
> "paging-foo" or "footprint-foo".
>
> I think your point that this control doesn't actually control sharing is
> a good one. In reality it control's paging and if sharing is enabled
> then it is a best effort thing which simply alleviates the need to do
> some amount of paging to reach the paging target.
>
>> The thing is, you can't actually control how much sharing happens.  That
>> depends largely on whether the guests create and maintain pages which
>> are share-able, and whether the sharing detection algorithm can find
>> such pages.  Even if two guests are sharing 95% of their pages, at any
>> point one of the guests may simply go wild and change them all.  So it
>> seems to me that shared pages need to be treated like sunny days in the
>> UK: Enjoy them while they're there, but don't count on them. :-)
>>
>> Given that, I think that each VM should have a "guaranteed minimum
>> memory footprint", which would be the amount of actual host ram it will
>> have if suddenly no shared pages become available.  After that, there
>> should be a policy of how to use the "windfall" or "bonus" pages
>> generated by sharing.
>
>> One sensible default policy would be "givers gain": Every guest which
>> creates a page which happens to be shared by another VM gets a share of
>> the pages freed up by the sharing.  Another policy might be "communism",
>> where the freed up pages are shared among all VMs, regardless of whose
>> pages made the benefit possible.  (In fact, if shared pages come from
>> zero pages, they should probably be given to VMs with no zero pages,
>> regardless of the policy.)
>
> An easily policy to implement initially would be "do nothing and use
> tmem".
>
>> However, I'd say the main public "knobs" should be just consist of two
>> things:
>> * xl mem-set memory-target.  This is the minimum amount of physical RAM
>> a guest can get; we make sure that the sum of these for all VMs does not
>> exceed the host capacity.
>
> Isn't this what we've previously called mem-paging-set? We defined
> mem-set earlier as controlling the amount of RAM the guest _thinks_ it
> has, which is different.
>
>> * xl sharing-policy [policy].  This tells the sharing system how to use
>> the "windfall" pages gathered from page sharing.
>>
>> Then internally, the sharing system should combine the "minimum
>> footprint" with the number of extra pages and the policy to set the
>> amount of memory actually used (via balloon driver or paging).
>
> This is an argument in favour of mem-footprint-set rather than
> mem-paging set?
>
> Here is an updated version of my proposed interface which includes
> sharing, I think as you described (modulo the use of mem-paging-set
> where you said mem-set above).
>
> I also included "mem-paging-set manual" as an explicit thing with an
> error on "mem-paging-set N" if you don't switch to manual mode. This
> might be too draconian -- I'm not wedded to it.
>
> maxmem=X                        # maximum RAM the domain can ever see
> memory=M                        # current amount of RAM seen by the
> 				# domain
> paging=[off|on]                 # allow the amount of memory a guest
>                                 # thinks it has to differ from the
>                                 # amount actually available to it (its
>                                 # "footprint")
> pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of
>                                 # "footprint" for guests which do not
>                                 # voluntarily obey changes to memory=M
> pagingdelay=60                  # amount of time to give a guest to
>                                 # voluntarily comply before enforcing a
>                                 # footprint
> pagesharing=[off|on]		# cause this guest to share pages with
> 				# other similarly enabled guests where
> 				# possible. Requires paging=on.
> pageextrapolocy=...		# controls what happens to extra pages
> 				# gain via sharing (could be combined
> 				# with pagesharing option:
> 				#	[off|policy|...])
>
>         Open question -- does pagesharing=on require paging=on? I've
>         tried to specify things below such that it does not, but it
>         might simplify things to require this.

No it doesn't, from the point of view of the hypervisor & libxc. It would
be strictly an xl constraint. Note that the pager won't be able to evict
shared pages, so it will choose a non-shared victim.

Word of caution. It is not easy to account for shared pages per domain.
Right now the dominfo struct does not report back the count of "shared"
pages for the domain -- although that's trivially fixable.

Even then, the problem is that a page counting as shared does not strictly
mean "gone from the domain footprint". A shared page with two references
(from dom A and dom B), that cow-breaks due to a write from dom A, will
still be a shared page with a single reference from dom B, and count as a
shared page for dom B. Also, all shared pages, whether they are referenced
by one, two, or more domains, belong to dom_cow.

What you could do is xc_sharing_freed_pages(), and split the result into
all domains, for a rough estimate of how much each domain is saving in
terms of sharing (divide in equal parts, or prorated by the domain shared
count). Another tool is xc_memshr_debug_gfn, which will tell you how many
refs to the shared page backing the gfn there are (if the gfn is indeed
shared).

Or, we could also have a "sharing_saved" count per domain to mean exactly
what you're looking for here.

>
> xl mem-set domain M
>         Sets the amount of RAM which the guest believes it has available
>         to M. The guest should arrange to use only that much RAM and
>         return the rest to the hypervisor (e.g. by using a balloon
>         driver). If the guest does not do so then the host may use
>         technical means to enforce the guest's footprint of M. The guest
>         may suffer a performance penalty for this enforcement.
>
>         paging off:     set balloon target to M.
>         paging on:      set balloon target to M.
>                         if pagingauto:
>                                 wait delay IFF new target < old
>                                 set paging target to M
>                                 support -t <delay> to override default?
>
>         Open question -- if a domain balloons to M as requested should
>         it still be subject to sharing? There is a performance hit
>         associated with sharing (far less than paging though?) but
>         presumably the admin would not have enabled sharing if they
>         didn't want this, therefore I think it is right for sharing on
>         to allow the guest to actually have <M assigned to it. Might be
>         a function of the individual sharing policy?

Sharing + balloon is mostly a bad idea. It's not forbidden or broken from
the hypervisor angle, but it's a lose-lose game. Ballooning a shared page
gains you nothing. The ballooner can't know what is shared and what isn't,
in order to make an educated decision. And the sharer can't foresee what
the balloon will victimize.

I would make those two mutually exclusive in xl.

>
> xl mem-paging-set domain manual
> 	Enables manual control of paging target.
>
> 	paging off:	error
> 	paging on:	set pagingauto=off
> 	sharing on:	same as paging on.
>
> xl mem-paging-set domain N
>         Overrides the amount of RAM which the guest actually has
>         available (its "footprint") to N. The host will use technical
>         means to continue to provide the illusion to the guest that it
>         has memory=M (as adjusted by mem-set). There may be a
>         performance penalty for this.
>
>         paging off:     error
>         paging on:      if pagingauto=on:
> 				error
> 			set paging target
>                         set pagingauto=off
>
> xl mem-paging-set domain auto
>         Automatically manage paging. Request that the guest uses
>         memory=M (current value of memory, as adjusted by mem-set)
>         enforced when the guest is uncooperative (as described in
>         "mem-set")
>
>         paging off:     error
>         paging on:      set paging target to M
>                         set pagingauto=on
>
> xl mem-sharing-policy-set domain [policy]
> 	Configures policy for use of extra pages.
>
> 	if !paging || pagingauto:
> 		If guest's actual usage drops below M due to sharing
> 		then extra pages are distributed per the sharing policy.
> 	else:
> 		If If guest's actual usage drops below N due to sharing
> 		then extra pages are distributed per the sharing policy.

See above note on determining shared pages per domain.
Andres

>
> 	TBD potential policies.
>
>         NB: shared pages reduce a domain's actual usage. Therefore it is
>         possible that sharing reduces the usage to less than the paging
>         target. In this case no pages will be paged out.
>
> We should ensure that the sum over for all domains of:
> 	pagingauto(D)? M : N
> does not exceed the amount of host memory.
>
> Ian.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 17:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 17: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 1S0yhW-0007fj-I5; Fri, 24 Feb 2012 17:12:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0yhU-0007fe-2U
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 17:12:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330103568!9954390!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk0MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6069 invoked from network); 24 Feb 2012 17:12:49 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	24 Feb 2012 17:12:49 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 1A6CF5EC07C;
	Fri, 24 Feb 2012 09:12:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=jEcgCJqoKLdIHwo6R0dKbdSIXRfw8t8Ks1i/zFtSXiHK
	NFKqjyHrJHkKHLldFvzewRRrPGEDn+cxEz9LKE3vmyMUstdW4+uYPa0ljHiRJP5B
	+c4YNKYc4WQZeFFbEkkOoW/bEk02j2o/Dn5sj+0Ae0mDx/PoHyXt+6yPR6Zs1lk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=UDuPo9gSB49VMlOKOae29//dtC4=; b=Ju0ELQQN
	1Z88FEZrDcvj1w9Q5gI2gA/qhRtTi5I0oFLRdMKuh2K4Du2z1z2ZNLR1Uk5hH2DG
	i9P3y4p7pfPph9TDilWE+7aZS4kddaZn4kRGlSibYz1D5mdZjTYgp83yeGcMcq4N
	Zvas2esitNkXtpEOmAQieFwTutKeyYazXvc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 776875EC072; 
	Fri, 24 Feb 2012 09:12:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 24 Feb 2012 09:12:48 -0800
Message-ID: <c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330078304.8557.157.camel@zakaz.uk.xensource.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
Date: Fri, 24 Feb 2012 09:12:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 12:18 +0000, George Dunlap wrote:
>> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
>> > What if you switch back without making sure you are in such a state? I
>> > think switching between the two is where the potential for unexpected
>> > behaviour is most likely.
>>
>> Yeah, correctly predicting what would happen requires understanding what
>> mem-set does under the hood.
>>
>> > I like that you have to explicitly ask for the safety wheels to come
>> off
>> > and explicitly put them back on again. It avoids the corner cases I
>> > alluded to above (at least I hope so).
>>
>> Yes, I think your suggestion sounds more like driving a car with a
>> proper hood, and less like driving a go-kart with the engine
>> exposed. :-)
>
> yeah, I'm way past "live fast die young" ;-)
>
>>
>> > Without wishing to put words in Andres' mouth I expect that he
>> intended
>> > "footprint" to cover other technical means than paging too --
>> > specifically I expect he was thinking of page sharing. (I suppose it
>> > also covers PoD to some extent too, although that is something of a
>> > special case)
>> >
>> > While I don't expect there will be a knob to control number of shared
>> > pages (either you can share some pages or not, the settings would be
>> > more about how aggressively you search for sharable pages) it might be
>> > useful to consider the interaction between paging and sharing, I
>> expect
>> > that most sharing configurations would want to have paging on at the
>> > same time (for safety). It seems valid to me to want to say "make the
>> > guest use this amount of actual RAM" and to achieve that by sharing
>> what
>> > you can and then paging the rest.
>>
>> Yes, it's worth thinking about; as long as it doesn't stall the paging
>> UI too long. :-)
>
> Right. I think the only issue here is whether we make the control called
> "paging-foo" or "footprint-foo".
>
> I think your point that this control doesn't actually control sharing is
> a good one. In reality it control's paging and if sharing is enabled
> then it is a best effort thing which simply alleviates the need to do
> some amount of paging to reach the paging target.
>
>> The thing is, you can't actually control how much sharing happens.  That
>> depends largely on whether the guests create and maintain pages which
>> are share-able, and whether the sharing detection algorithm can find
>> such pages.  Even if two guests are sharing 95% of their pages, at any
>> point one of the guests may simply go wild and change them all.  So it
>> seems to me that shared pages need to be treated like sunny days in the
>> UK: Enjoy them while they're there, but don't count on them. :-)
>>
>> Given that, I think that each VM should have a "guaranteed minimum
>> memory footprint", which would be the amount of actual host ram it will
>> have if suddenly no shared pages become available.  After that, there
>> should be a policy of how to use the "windfall" or "bonus" pages
>> generated by sharing.
>
>> One sensible default policy would be "givers gain": Every guest which
>> creates a page which happens to be shared by another VM gets a share of
>> the pages freed up by the sharing.  Another policy might be "communism",
>> where the freed up pages are shared among all VMs, regardless of whose
>> pages made the benefit possible.  (In fact, if shared pages come from
>> zero pages, they should probably be given to VMs with no zero pages,
>> regardless of the policy.)
>
> An easily policy to implement initially would be "do nothing and use
> tmem".
>
>> However, I'd say the main public "knobs" should be just consist of two
>> things:
>> * xl mem-set memory-target.  This is the minimum amount of physical RAM
>> a guest can get; we make sure that the sum of these for all VMs does not
>> exceed the host capacity.
>
> Isn't this what we've previously called mem-paging-set? We defined
> mem-set earlier as controlling the amount of RAM the guest _thinks_ it
> has, which is different.
>
>> * xl sharing-policy [policy].  This tells the sharing system how to use
>> the "windfall" pages gathered from page sharing.
>>
>> Then internally, the sharing system should combine the "minimum
>> footprint" with the number of extra pages and the policy to set the
>> amount of memory actually used (via balloon driver or paging).
>
> This is an argument in favour of mem-footprint-set rather than
> mem-paging set?
>
> Here is an updated version of my proposed interface which includes
> sharing, I think as you described (modulo the use of mem-paging-set
> where you said mem-set above).
>
> I also included "mem-paging-set manual" as an explicit thing with an
> error on "mem-paging-set N" if you don't switch to manual mode. This
> might be too draconian -- I'm not wedded to it.
>
> maxmem=X                        # maximum RAM the domain can ever see
> memory=M                        # current amount of RAM seen by the
> 				# domain
> paging=[off|on]                 # allow the amount of memory a guest
>                                 # thinks it has to differ from the
>                                 # amount actually available to it (its
>                                 # "footprint")
> pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of
>                                 # "footprint" for guests which do not
>                                 # voluntarily obey changes to memory=M
> pagingdelay=60                  # amount of time to give a guest to
>                                 # voluntarily comply before enforcing a
>                                 # footprint
> pagesharing=[off|on]		# cause this guest to share pages with
> 				# other similarly enabled guests where
> 				# possible. Requires paging=on.
> pageextrapolocy=...		# controls what happens to extra pages
> 				# gain via sharing (could be combined
> 				# with pagesharing option:
> 				#	[off|policy|...])
>
>         Open question -- does pagesharing=on require paging=on? I've
>         tried to specify things below such that it does not, but it
>         might simplify things to require this.

No it doesn't, from the point of view of the hypervisor & libxc. It would
be strictly an xl constraint. Note that the pager won't be able to evict
shared pages, so it will choose a non-shared victim.

Word of caution. It is not easy to account for shared pages per domain.
Right now the dominfo struct does not report back the count of "shared"
pages for the domain -- although that's trivially fixable.

Even then, the problem is that a page counting as shared does not strictly
mean "gone from the domain footprint". A shared page with two references
(from dom A and dom B), that cow-breaks due to a write from dom A, will
still be a shared page with a single reference from dom B, and count as a
shared page for dom B. Also, all shared pages, whether they are referenced
by one, two, or more domains, belong to dom_cow.

What you could do is xc_sharing_freed_pages(), and split the result into
all domains, for a rough estimate of how much each domain is saving in
terms of sharing (divide in equal parts, or prorated by the domain shared
count). Another tool is xc_memshr_debug_gfn, which will tell you how many
refs to the shared page backing the gfn there are (if the gfn is indeed
shared).

Or, we could also have a "sharing_saved" count per domain to mean exactly
what you're looking for here.

>
> xl mem-set domain M
>         Sets the amount of RAM which the guest believes it has available
>         to M. The guest should arrange to use only that much RAM and
>         return the rest to the hypervisor (e.g. by using a balloon
>         driver). If the guest does not do so then the host may use
>         technical means to enforce the guest's footprint of M. The guest
>         may suffer a performance penalty for this enforcement.
>
>         paging off:     set balloon target to M.
>         paging on:      set balloon target to M.
>                         if pagingauto:
>                                 wait delay IFF new target < old
>                                 set paging target to M
>                                 support -t <delay> to override default?
>
>         Open question -- if a domain balloons to M as requested should
>         it still be subject to sharing? There is a performance hit
>         associated with sharing (far less than paging though?) but
>         presumably the admin would not have enabled sharing if they
>         didn't want this, therefore I think it is right for sharing on
>         to allow the guest to actually have <M assigned to it. Might be
>         a function of the individual sharing policy?

Sharing + balloon is mostly a bad idea. It's not forbidden or broken from
the hypervisor angle, but it's a lose-lose game. Ballooning a shared page
gains you nothing. The ballooner can't know what is shared and what isn't,
in order to make an educated decision. And the sharer can't foresee what
the balloon will victimize.

I would make those two mutually exclusive in xl.

>
> xl mem-paging-set domain manual
> 	Enables manual control of paging target.
>
> 	paging off:	error
> 	paging on:	set pagingauto=off
> 	sharing on:	same as paging on.
>
> xl mem-paging-set domain N
>         Overrides the amount of RAM which the guest actually has
>         available (its "footprint") to N. The host will use technical
>         means to continue to provide the illusion to the guest that it
>         has memory=M (as adjusted by mem-set). There may be a
>         performance penalty for this.
>
>         paging off:     error
>         paging on:      if pagingauto=on:
> 				error
> 			set paging target
>                         set pagingauto=off
>
> xl mem-paging-set domain auto
>         Automatically manage paging. Request that the guest uses
>         memory=M (current value of memory, as adjusted by mem-set)
>         enforced when the guest is uncooperative (as described in
>         "mem-set")
>
>         paging off:     error
>         paging on:      set paging target to M
>                         set pagingauto=on
>
> xl mem-sharing-policy-set domain [policy]
> 	Configures policy for use of extra pages.
>
> 	if !paging || pagingauto:
> 		If guest's actual usage drops below M due to sharing
> 		then extra pages are distributed per the sharing policy.
> 	else:
> 		If If guest's actual usage drops below N due to sharing
> 		then extra pages are distributed per the sharing policy.

See above note on determining shared pages per domain.
Andres

>
> 	TBD potential policies.
>
>         NB: shared pages reduce a domain's actual usage. Therefore it is
>         possible that sharing reduces the usage to less than the paging
>         target. In this case no pages will be paged out.
>
> We should ensure that the sum over for all domains of:
> 	pagingauto(D)? M : N
> does not exceed the amount of host memory.
>
> Ian.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 17:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 17: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 1S0ynB-0007pP-DG; Fri, 24 Feb 2012 17:18:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0ynA-0007pF-2K
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 17:18:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330103919!16251122!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Njgw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Njgw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7883 invoked from network); 24 Feb 2012 17:18:40 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-216.messagelabs.com with SMTP;
	24 Feb 2012 17:18:40 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id A79807EC074;
	Fri, 24 Feb 2012 09:18:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=G9edbiF3wAluMx8Tx1HG3kBJTL1+KQd/CBxwQGAguR5C
	ktnKV/1aifSloP8X3nd2pVToHKCRtFDS0hDsOow0aoHN4RUftqBDhTQ0fj9WRqgB
	1zuyXg/4fx/bi4Z9QKQ9dlu4Aq+XRM44E1yTFsGIBra90nBpUN+3DEgbF/cAuCM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jaW0Jgjt8BhUaCjKmYiFOk8Edbw=; b=Ho+6TenT
	g/lM6POdR5pnLWgNGleBS2uTMEaaNSyuiWdn0Yf1sanIZ3H/+9unV/xoeIWvhcAR
	XXx+9sMpKREom7ujgAXgFr97zzrOFtpRb3sre6qgSn0U/ZXQ3S7wOQqVO5Y/sJnU
	CsRlQybXgAhZpfaEVjRATcmhcRTto9TgXeA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 317957EC072; 
	Fri, 24 Feb 2012 09:18:32 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 24 Feb 2012 09:18:32 -0800
Message-ID: <952274bf3102b962f2edada5f7daa724.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F4771EE020000780007496D@nat28.tlf.novell.com>
References: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
	<4F4771EE020000780007496D@nat28.tlf.novell.com>
Date: Fri, 24 Feb 2012 09:18:32 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>>> On 23.02.12 at 20:59, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> wrote:
>> @@ -300,6 +301,87 @@ static unsigned long init_node_heap(int
>>      return needed;
>>  }
>>
>> +/* Default to 64 MiB */
>> +#define DEFAULT_LOW_MEM_VIRQ_MIB    64
>> +#define MAX_LOW_MEM_VIRQ_MIB        1024
>> +
>> +static unsigned long long __read_mostly opt_low_mem_virq =
>> +                                        (DEFAULT_LOW_MEM_VIRQ_MIB <<
>> 20);
>> +size_param("low_mem_virq_limit", opt_low_mem_virq);
>> +
>> +/* Thresholds to control hysteresis. In pages */
>> +/* When memory grows above this threshold, reset hysteresis.
>> + * -1 initially to not reset until at least one virq issued. */
>> +static unsigned long low_mem_virq_high      = -1UL;
>> +/* Threshold at which we issue virq */
>> +static unsigned long low_mem_virq_th        = 0;
>> +/* Original threshold after all checks completed */
>> +static unsigned long low_mem_virq_orig      = 0;
>> +/* Order for current threshold */
>> +static unsigned int  low_mem_virq_th_order  = 0;
>> +
>> +/* Perform bootstrapping checks and set bounds */
>> +static void setup_low_mem_virq(void)
>
> __init
>
>> +{
>> +    unsigned int order;
>> +    unsigned long long threshold;
>> +
>> +    /* Dom0 has already been allocated by now. So check we won't
>> +     * be complaining immediately with whatever's left of the heap. */
>> +    threshold = min(opt_low_mem_virq, (unsigned long long)
>> +                          (total_avail_pages << PAGE_SHIFT));
>
> The cast needs to be on total_avail_pages, not the result of the
> shift. Also, unsigned long long is the wrong type (paddr_t was
> invented for this very purpose).
>
> Further, the initial threshold should clearly be *below* the currently
> available amount (e.g. at half of it).

That's debatable. Let's set aside the semantics of what is "really" or
"dangerously" low, and assume the admin knows what he/she is doing when
setting the threshold in the command line. If the amount of available
memory is below that threshold, then the moment an allocation happens we
need to warn.

>
>> +
>> +    /* Then, cap to some predefined maximum */
>> +    threshold = min(threshold, (unsigned long long)
>> +                          (MAX_LOW_MEM_VIRQ_MIB << 20));
>
> Same here wrt the cast.
>
>> +
>> +    /* Threshold bytes -> pages */
>> +    low_mem_virq_th = threshold >> PAGE_SHIFT;
>> +
>> +    /* Next, round the threshold down to the next order */
>> +    order = get_order_from_pages(low_mem_virq_th);
>> +    if ( (1 << order) > low_mem_virq_th )
>> +        order--;
>> +
>> +    /* Set bounds, ready to go */
>> +    low_mem_virq_th = low_mem_virq_orig = 1 << order;
>
> 1UL << ...
>
>> +    low_mem_virq_th_order = order;
>> +
>> +    printk("Current low memory virq threshold set at 0x%lx pages.\n",
>
> "Initial ..."
>
>> +            low_mem_virq_th);
>> +}
>> +
>> +static void check_low_mem_virq(void)
>> +{
>> +    if ( total_avail_pages <= low_mem_virq_th )
>> +    {
>> +        send_global_virq(VIRQ_ENOMEM);
>> +
>> +        /* Update thresholds. Next warning will be when we drop below
>> +         * next order. However, we wait until we grow beyond one
>> +         * order above us to complain again at the current order */
>> +        low_mem_virq_high   = 1 << (low_mem_virq_th_order + 1);
>
> 1UL << ...
>
>> +        if ( low_mem_virq_th_order > 0 )
>> +            low_mem_virq_th_order--;
>> +        low_mem_virq_th     = 1 << low_mem_virq_th_order;
>
> Same here.
>
>> +        return;
>> +    }
>> +
>> +    if ( total_avail_pages >= low_mem_virq_high )
>> +    {
>> +        /* Reset hysteresis. Bring threshold up one order.
>> +         * If we are back where originally set, set high
>> +         * threshold to -1 to avoid further growth of
>> +         * virq threshold. */
>> +        low_mem_virq_th_order++;
>> +        low_mem_virq_th = 1 << low_mem_virq_th_order;
>
> And here.
>
>> +        if ( low_mem_virq_th == low_mem_virq_orig )
>> +            low_mem_virq_high = -1UL;
>> +        else
>> +            low_mem_virq_high = 1 << (low_mem_virq_th_order + 2);
>
> And here.
All of these I'll do, thanks Jan.

>
>> +    }
>> +}
>> +
>>  /* Allocate 2^@order contiguous pages. */
>>  static struct page_info *alloc_heap_pages(
>>      unsigned int zone_lo, unsigned int zone_hi,
>> @@ -420,6 +502,8 @@ static struct page_info *alloc_heap_page
>>      total_avail_pages -= request;
>>      ASSERT(total_avail_pages >= 0);
>>
>> +    check_low_mem_virq();
>> +
>>      if ( d != NULL )
>>          d->last_alloc_node = node;
>>
>> @@ -1022,6 +1106,10 @@ void __init scrub_heap_pages(void)
>>      }
>>
>>      printk("done.\n");
>> +
>> +    /* Now that the heap is initialized, run checks and set bounds
>> +     * for the low mem virq algorithm. */
>> +    setup_low_mem_virq();
>>  }
>>
>>
>> diff -r dd69d9b1aee9 -r da02cb8485de xen/include/public/xen.h
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>>  #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) Dangerously low on heap memory
>>      */
>
> Either the default threshold ought to be *much* lower (say 64k), or
> the "dangerously" here is completely misleading.
>
>>
>>  /* Architecture-specific VIRQ definitions. */
>>  #define VIRQ_ARCH_0    16
>
> Given that this new vIRQ ought to be handled in user space, do you
> have an implementation ready to contribute as well?

I have my little daemon that I use for this. It's nothing you would not
expect: listen for the virq, balloon dom0 down a bit. I can throw it into
the tree, although I don't know where. Or I can post it to the list for
posterity. Ideally all "memory management daemons" out there that find it
useful would pick it up -- certainly the hope is for squeezed to do that,
but I view that as a separate effort.

Andres
>
> Jan
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 17:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 17: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 1S0ynB-0007pP-DG; Fri, 24 Feb 2012 17:18:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S0ynA-0007pF-2K
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 17:18:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330103919!16251122!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Njgw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Njgw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7883 invoked from network); 24 Feb 2012 17:18:40 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-216.messagelabs.com with SMTP;
	24 Feb 2012 17:18:40 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id A79807EC074;
	Fri, 24 Feb 2012 09:18:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=G9edbiF3wAluMx8Tx1HG3kBJTL1+KQd/CBxwQGAguR5C
	ktnKV/1aifSloP8X3nd2pVToHKCRtFDS0hDsOow0aoHN4RUftqBDhTQ0fj9WRqgB
	1zuyXg/4fx/bi4Z9QKQ9dlu4Aq+XRM44E1yTFsGIBra90nBpUN+3DEgbF/cAuCM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=jaW0Jgjt8BhUaCjKmYiFOk8Edbw=; b=Ho+6TenT
	g/lM6POdR5pnLWgNGleBS2uTMEaaNSyuiWdn0Yf1sanIZ3H/+9unV/xoeIWvhcAR
	XXx+9sMpKREom7ujgAXgFr97zzrOFtpRb3sre6qgSn0U/ZXQ3S7wOQqVO5Y/sJnU
	CsRlQybXgAhZpfaEVjRATcmhcRTto9TgXeA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 317957EC072; 
	Fri, 24 Feb 2012 09:18:32 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 24 Feb 2012 09:18:32 -0800
Message-ID: <952274bf3102b962f2edada5f7daa724.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4F4771EE020000780007496D@nat28.tlf.novell.com>
References: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
	<4F4771EE020000780007496D@nat28.tlf.novell.com>
Date: Fri, 24 Feb 2012 09:18:32 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>>> On 23.02.12 at 20:59, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> wrote:
>> @@ -300,6 +301,87 @@ static unsigned long init_node_heap(int
>>      return needed;
>>  }
>>
>> +/* Default to 64 MiB */
>> +#define DEFAULT_LOW_MEM_VIRQ_MIB    64
>> +#define MAX_LOW_MEM_VIRQ_MIB        1024
>> +
>> +static unsigned long long __read_mostly opt_low_mem_virq =
>> +                                        (DEFAULT_LOW_MEM_VIRQ_MIB <<
>> 20);
>> +size_param("low_mem_virq_limit", opt_low_mem_virq);
>> +
>> +/* Thresholds to control hysteresis. In pages */
>> +/* When memory grows above this threshold, reset hysteresis.
>> + * -1 initially to not reset until at least one virq issued. */
>> +static unsigned long low_mem_virq_high      = -1UL;
>> +/* Threshold at which we issue virq */
>> +static unsigned long low_mem_virq_th        = 0;
>> +/* Original threshold after all checks completed */
>> +static unsigned long low_mem_virq_orig      = 0;
>> +/* Order for current threshold */
>> +static unsigned int  low_mem_virq_th_order  = 0;
>> +
>> +/* Perform bootstrapping checks and set bounds */
>> +static void setup_low_mem_virq(void)
>
> __init
>
>> +{
>> +    unsigned int order;
>> +    unsigned long long threshold;
>> +
>> +    /* Dom0 has already been allocated by now. So check we won't
>> +     * be complaining immediately with whatever's left of the heap. */
>> +    threshold = min(opt_low_mem_virq, (unsigned long long)
>> +                          (total_avail_pages << PAGE_SHIFT));
>
> The cast needs to be on total_avail_pages, not the result of the
> shift. Also, unsigned long long is the wrong type (paddr_t was
> invented for this very purpose).
>
> Further, the initial threshold should clearly be *below* the currently
> available amount (e.g. at half of it).

That's debatable. Let's set aside the semantics of what is "really" or
"dangerously" low, and assume the admin knows what he/she is doing when
setting the threshold in the command line. If the amount of available
memory is below that threshold, then the moment an allocation happens we
need to warn.

>
>> +
>> +    /* Then, cap to some predefined maximum */
>> +    threshold = min(threshold, (unsigned long long)
>> +                          (MAX_LOW_MEM_VIRQ_MIB << 20));
>
> Same here wrt the cast.
>
>> +
>> +    /* Threshold bytes -> pages */
>> +    low_mem_virq_th = threshold >> PAGE_SHIFT;
>> +
>> +    /* Next, round the threshold down to the next order */
>> +    order = get_order_from_pages(low_mem_virq_th);
>> +    if ( (1 << order) > low_mem_virq_th )
>> +        order--;
>> +
>> +    /* Set bounds, ready to go */
>> +    low_mem_virq_th = low_mem_virq_orig = 1 << order;
>
> 1UL << ...
>
>> +    low_mem_virq_th_order = order;
>> +
>> +    printk("Current low memory virq threshold set at 0x%lx pages.\n",
>
> "Initial ..."
>
>> +            low_mem_virq_th);
>> +}
>> +
>> +static void check_low_mem_virq(void)
>> +{
>> +    if ( total_avail_pages <= low_mem_virq_th )
>> +    {
>> +        send_global_virq(VIRQ_ENOMEM);
>> +
>> +        /* Update thresholds. Next warning will be when we drop below
>> +         * next order. However, we wait until we grow beyond one
>> +         * order above us to complain again at the current order */
>> +        low_mem_virq_high   = 1 << (low_mem_virq_th_order + 1);
>
> 1UL << ...
>
>> +        if ( low_mem_virq_th_order > 0 )
>> +            low_mem_virq_th_order--;
>> +        low_mem_virq_th     = 1 << low_mem_virq_th_order;
>
> Same here.
>
>> +        return;
>> +    }
>> +
>> +    if ( total_avail_pages >= low_mem_virq_high )
>> +    {
>> +        /* Reset hysteresis. Bring threshold up one order.
>> +         * If we are back where originally set, set high
>> +         * threshold to -1 to avoid further growth of
>> +         * virq threshold. */
>> +        low_mem_virq_th_order++;
>> +        low_mem_virq_th = 1 << low_mem_virq_th_order;
>
> And here.
>
>> +        if ( low_mem_virq_th == low_mem_virq_orig )
>> +            low_mem_virq_high = -1UL;
>> +        else
>> +            low_mem_virq_high = 1 << (low_mem_virq_th_order + 2);
>
> And here.
All of these I'll do, thanks Jan.

>
>> +    }
>> +}
>> +
>>  /* Allocate 2^@order contiguous pages. */
>>  static struct page_info *alloc_heap_pages(
>>      unsigned int zone_lo, unsigned int zone_hi,
>> @@ -420,6 +502,8 @@ static struct page_info *alloc_heap_page
>>      total_avail_pages -= request;
>>      ASSERT(total_avail_pages >= 0);
>>
>> +    check_low_mem_virq();
>> +
>>      if ( d != NULL )
>>          d->last_alloc_node = node;
>>
>> @@ -1022,6 +1106,10 @@ void __init scrub_heap_pages(void)
>>      }
>>
>>      printk("done.\n");
>> +
>> +    /* Now that the heap is initialized, run checks and set bounds
>> +     * for the low mem virq algorithm. */
>> +    setup_low_mem_virq();
>>  }
>>
>>
>> diff -r dd69d9b1aee9 -r da02cb8485de xen/include/public/xen.h
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>>  #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) Dangerously low on heap memory
>>      */
>
> Either the default threshold ought to be *much* lower (say 64k), or
> the "dangerously" here is completely misleading.
>
>>
>>  /* Architecture-specific VIRQ definitions. */
>>  #define VIRQ_ARCH_0    16
>
> Given that this new vIRQ ought to be handled in user space, do you
> have an implementation ready to contribute as well?

I have my little daemon that I use for this. It's nothing you would not
expect: listen for the virq, balloon dom0 down a bit. I can throw it into
the tree, although I don't know where. Or I can post it to the list for
posterity. Ideally all "memory management daemons" out there that find it
useful would pick it up -- certainly the hope is for squeezed to do that,
but I view that as a separate effort.

Andres
>
> Jan
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S0znd-0000G2-2U; Fri, 24 Feb 2012 18:23:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0znc-0000Fw-2J
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:23:20 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330107739!58178472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30529 invoked from network); 24 Feb 2012 18:22:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:23:18 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:23:18 +0000
MIME-Version: 1.0
X-Mercurial-Node: 20ea6f881776a8912dbe02679ace2648f8d8951d
Message-ID: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 24 Feb 2012 18:24:17 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] [PATCH v2] Add the bios 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

diff -r adcd6ab160fa -r 20ea6f881776 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Feb 24 18:19:56 2012 +0000
@@ -430,6 +430,12 @@ accept the defaults for these options wh
 
 =over 4
 
+=item B<bios="STRING">
+
+Load the specified BIOS in HVMLOADER. By default, HVMLOADER will try
+to do a guess about the BIOS to run, but sometimes it may be useful
+to force a different one, like OVMF UEFI.
+
 =item B<pae=BOOLEAN>
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Feb 24 18:19:56 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = 0;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Feb 24 18:19:56 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return libxl_bios_types_to_string(info->u.hvm.bios);
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Feb 24 18:19:56 2012 +0000
@@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+libxl_bios_types = Enumeration("bios_types", [
+    (1, "rombios"),
+    (2, "seabios"),
+    (3, "ovmf"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", libxl_bios_types),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 24 18:19:56 2012 +0000
@@ -704,6 +704,12 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
+            libxl_bios_types_from_string(buf, &b_info->u.hvm.bios)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
+                    buf);
+                exit (1);
+        }
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S0znd-0000G2-2U; Fri, 24 Feb 2012 18:23:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0znc-0000Fw-2J
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:23:20 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330107739!58178472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30529 invoked from network); 24 Feb 2012 18:22:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:23:18 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:23:18 +0000
MIME-Version: 1.0
X-Mercurial-Node: 20ea6f881776a8912dbe02679ace2648f8d8951d
Message-ID: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 24 Feb 2012 18:24:17 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] [PATCH v2] Add the bios 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

diff -r adcd6ab160fa -r 20ea6f881776 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Feb 24 18:19:56 2012 +0000
@@ -430,6 +430,12 @@ accept the defaults for these options wh
 
 =over 4
 
+=item B<bios="STRING">
+
+Load the specified BIOS in HVMLOADER. By default, HVMLOADER will try
+to do a guess about the BIOS to run, but sometimes it may be useful
+to force a different one, like OVMF UEFI.
+
 =item B<pae=BOOLEAN>
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Feb 24 18:19:56 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = 0;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Feb 24 18:19:56 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return libxl_bios_types_to_string(info->u.hvm.bios);
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Feb 24 18:19:56 2012 +0000
@@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+libxl_bios_types = Enumeration("bios_types", [
+    (1, "rombios"),
+    (2, "seabios"),
+    (3, "ovmf"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", libxl_bios_types),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 24 18:19:56 2012 +0000
@@ -704,6 +704,12 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
+            libxl_bios_types_from_string(buf, &b_info->u.hvm.bios)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
+                    buf);
+                exit (1);
+        }
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:31:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0zvF-0000Wx-Cc; Fri, 24 Feb 2012 18:31:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0zvD-0000Wf-Kx
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:31:11 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330108265!16335075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24014 invoked from network); 24 Feb 2012 18:31:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:31:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:31:03 +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.213.0;
	Fri, 24 Feb 2012 18:31:03 +0000
Message-ID: <4F47D7A2.2020709@citrix.com>
Date: Fri, 24 Feb 2012 18:32:02 +0000
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>
References: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
In-Reply-To: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v2] Add the bios 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It seems I have still to learn using the patchbomb extension properly 
with mercurial :)

[Patch v2] Add the bios option to specify the bios to load.

Please note 2 things:
- I've used the name of 'OVMF' rather than adding the arch postfix 
because we are going to make this code arch-size agnostic (in another patch)
- Other seems missing in xl.cfg.pod5, like firmware_override

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
---

Differences wih previous patch:
- Renamed bios_override option into bios
- Made internally the bios value as an enumeration
- Added the documentation for the bios option in xl.cfg.pod.5

On 24/02/12 18:24, Attilio Rao wrote:
> diff -r adcd6ab160fa -r 20ea6f881776 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 24 18:19:56 2012 +0000
> @@ -430,6 +430,12 @@ accept the defaults for these options wh
>
>   =over 4
>
> +=item B<bios="STRING">
> +
> +Load the specified BIOS in HVMLOADER. By default, HVMLOADER will try
> +to do a guess about the BIOS to run, but sometimes it may be useful
> +to force a different one, like OVMF UEFI.
> +
>   =item B<pae=BOOLEAN>
>
>   Hide or expose the IA32 Physical Address Extensions. These extensions
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>       case LIBXL_DOMAIN_TYPE_HVM:
>           b_info->video_memkb = 8 * 1024;
>           b_info->u.hvm.firmware = NULL;
> +        b_info->u.hvm.bios = 0;
>           b_info->u.hvm.pae = 1;
>           b_info->u.hvm.apic = 1;
>           b_info->u.hvm.acpi = 1;
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>   static const char *libxl__domain_bios(libxl__gc *gc,
>                                   const libxl_domain_build_info *info)
>   {
> +    if (info->u.hvm.bios)
> +       return libxl_bios_types_to_string(info->u.hvm.bios);
>       switch (info->device_model_version) {
>       case 1: return "rombios";
>       case 2: return "seabios";
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Fri Feb 24 18:19:56 2012 +0000
> @@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
>       (3, "one_missed_tick_pending"),
>       ])
>
> +libxl_bios_types = Enumeration("bios_types", [
> +    (1, "rombios"),
> +    (2, "seabios"),
> +    (3, "ovmf"),
> +    ])
> +
>   #
>   # Complex libxl types
>   #
> @@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
>
>       ("u", KeyedUnion(None, libxl_domain_type, "type",
>                   [("hvm", Struct(None, [("firmware", string),
> +                                       ("bios", libxl_bios_types),
>                                          ("pae", bool),
>                                          ("apic", bool),
>                                          ("acpi", bool),
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -704,6 +704,12 @@ static void parse_config_data(const char
>
>           xlu_cfg_replace_string (config, "firmware_override",
>                                   &b_info->u.hvm.firmware, 0);
> +        if (!xlu_cfg_get_string(config, "bios",&buf, 0)&&
> +            libxl_bios_types_from_string(buf,&b_info->u.hvm.bios)) {
> +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
> +                    buf);
> +                exit (1);
> +        }
>           if (!xlu_cfg_get_long (config, "pae",&l, 0))
>               b_info->u.hvm.pae = l;
>           if (!xlu_cfg_get_long (config, "apic",&l, 0))
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>    


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:31:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0zvF-0000Wx-Cc; Fri, 24 Feb 2012 18:31:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0zvD-0000Wf-Kx
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:31:11 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330108265!16335075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24014 invoked from network); 24 Feb 2012 18:31:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:31:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:31:03 +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.213.0;
	Fri, 24 Feb 2012 18:31:03 +0000
Message-ID: <4F47D7A2.2020709@citrix.com>
Date: Fri, 24 Feb 2012 18:32:02 +0000
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>
References: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
In-Reply-To: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v2] Add the bios 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It seems I have still to learn using the patchbomb extension properly 
with mercurial :)

[Patch v2] Add the bios option to specify the bios to load.

Please note 2 things:
- I've used the name of 'OVMF' rather than adding the arch postfix 
because we are going to make this code arch-size agnostic (in another patch)
- Other seems missing in xl.cfg.pod5, like firmware_override

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
---

Differences wih previous patch:
- Renamed bios_override option into bios
- Made internally the bios value as an enumeration
- Added the documentation for the bios option in xl.cfg.pod.5

On 24/02/12 18:24, Attilio Rao wrote:
> diff -r adcd6ab160fa -r 20ea6f881776 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 24 18:19:56 2012 +0000
> @@ -430,6 +430,12 @@ accept the defaults for these options wh
>
>   =over 4
>
> +=item B<bios="STRING">
> +
> +Load the specified BIOS in HVMLOADER. By default, HVMLOADER will try
> +to do a guess about the BIOS to run, but sometimes it may be useful
> +to force a different one, like OVMF UEFI.
> +
>   =item B<pae=BOOLEAN>
>
>   Hide or expose the IA32 Physical Address Extensions. These extensions
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>       case LIBXL_DOMAIN_TYPE_HVM:
>           b_info->video_memkb = 8 * 1024;
>           b_info->u.hvm.firmware = NULL;
> +        b_info->u.hvm.bios = 0;
>           b_info->u.hvm.pae = 1;
>           b_info->u.hvm.apic = 1;
>           b_info->u.hvm.acpi = 1;
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>   static const char *libxl__domain_bios(libxl__gc *gc,
>                                   const libxl_domain_build_info *info)
>   {
> +    if (info->u.hvm.bios)
> +       return libxl_bios_types_to_string(info->u.hvm.bios);
>       switch (info->device_model_version) {
>       case 1: return "rombios";
>       case 2: return "seabios";
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Fri Feb 24 18:19:56 2012 +0000
> @@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
>       (3, "one_missed_tick_pending"),
>       ])
>
> +libxl_bios_types = Enumeration("bios_types", [
> +    (1, "rombios"),
> +    (2, "seabios"),
> +    (3, "ovmf"),
> +    ])
> +
>   #
>   # Complex libxl types
>   #
> @@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
>
>       ("u", KeyedUnion(None, libxl_domain_type, "type",
>                   [("hvm", Struct(None, [("firmware", string),
> +                                       ("bios", libxl_bios_types),
>                                          ("pae", bool),
>                                          ("apic", bool),
>                                          ("acpi", bool),
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -704,6 +704,12 @@ static void parse_config_data(const char
>
>           xlu_cfg_replace_string (config, "firmware_override",
>                                   &b_info->u.hvm.firmware, 0);
> +        if (!xlu_cfg_get_string(config, "bios",&buf, 0)&&
> +            libxl_bios_types_from_string(buf,&b_info->u.hvm.bios)) {
> +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
> +                    buf);
> +                exit (1);
> +        }
>           if (!xlu_cfg_get_long (config, "pae",&l, 0))
>               b_info->u.hvm.pae = l;
>           if (!xlu_cfg_get_long (config, "apic",&l, 0))
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>    


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0zyu-0000fy-0y; Fri, 24 Feb 2012 18:35:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0zyr-0000fm-Qp
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:34:58 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330108437!58179357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18762 invoked from network); 24 Feb 2012 18:33:58 -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 Feb 2012 18:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:34:56 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:34:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: eb51dd646ce097b54a588fc5e5e246e46111fc85
Message-ID: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 24 Feb 2012 18:35:55 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Signed-off-by: Attilio Rao
	<attilio.rao@citrix.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

diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/Makefile	Fri Feb 24 18:35:37 2012 +0000
@@ -55,10 +55,9 @@ ROMS :=
 
 ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
-CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
-OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
-OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
-ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
+CFLAGS += -DENABLE_OVMF
+OVMF_ROM := $(OVMF_DIR)/ovmf.bin
+ROMS += $(OVMF_ROM)
 endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -102,15 +101,9 @@ ifneq ($(SEABIOS_ROM),)
 	echo "#endif" >> $@.new
 endif
 
-ifneq ($(OVMF32_ROM),)
-	echo "#ifdef ROM_INCLUDE_OVMF32" >> $@.new
-	sh ./mkhex ovmf32 $(OVMF32_ROM) >> $@.new
-	echo "#endif" >> $@.new	
-endif 
-
-ifneq ($(OVMF64_ROM),)
-	echo "#ifdef ROM_INCLUDE_OVMF64" >> $@.new
-	sh ./mkhex ovmf64 $(OVMF64_ROM) >> $@.new
+ifneq ($(OVMF_ROM),)
+	echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
+	sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
 	echo "#endif" >> $@.new	
 endif 
 
diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/config.h	Fri Feb 24 18:35:37 2012 +0000
@@ -35,8 +35,7 @@ struct bios_config {
 
 extern struct bios_config rombios_config;
 extern struct bios_config seabios_config;
-extern struct bios_config ovmf32_config;
-extern struct bios_config ovmf64_config;
+extern struct bios_config ovmf_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Feb 24 18:35:37 2012 +0000
@@ -212,11 +212,8 @@ struct bios_info {
 #ifdef ENABLE_SEABIOS
     { "seabios", &seabios_config, },
 #endif
-#ifdef ENABLE_OVMF32
-    { "ovmf-ia32", &ovmf32_config, },
-#endif
-#ifdef ENABLE_OVMF64
-    { "ovmf-x64", &ovmf64_config, },
+#ifdef ENABLE_OVMF
+    { "ovmf", &ovmf_config, },
 #endif
     { NULL, NULL }
 };
diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/ovmf.c
--- a/tools/firmware/hvmloader/ovmf.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/ovmf.c	Fri Feb 24 18:35:37 2012 +0000
@@ -35,8 +35,7 @@
 #include <xen/hvm/ioreq.h>
 #include <xen/memory.h>
 
-#define ROM_INCLUDE_OVMF32
-#define ROM_INCLUDE_OVMF64
+#define ROM_INCLUDE_OVMF
 #include "roms.inc"
 
 #define OVMF_BEGIN              0xFFF00000ULL
@@ -48,8 +47,8 @@
 #define LOWCHUNK_MAXOFFSET      0x0000FFFF
 #define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
 
-extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
-extern int dsdt_anycpu_len, dsdt_15cpu_len;
+extern unsigned char dsdt_anycpu[];
+extern int dsdt_anycpu_len;
 
 static void ovmf_load(const struct bios_config *config)
 {
@@ -79,8 +78,8 @@ static void ovmf_acpi_build_tables(void)
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
-        .dsdt_15cpu = dsdt_15cpu,
-        .dsdt_15cpu_len = dsdt_15cpu_len,
+        .dsdt_15cpu = NULL, 
+        .dsdt_15cpu_len = 0
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
@@ -94,33 +93,11 @@ static void ovmf_create_smbios_tables(vo
         SMBIOS_PHYSICAL_END);
 }
 
-struct bios_config ovmf32_config =  {
-    .name = "OVMF-IA32",
+struct bios_config ovmf_config =  {
+    .name = "OVMF",
 
-    .image = ovmf32,
-    .image_size = sizeof(ovmf32),
-
-    .bios_address = 0,
-    .bios_load = ovmf_load,
-
-    .load_roms = 0,
-
-    .bios_info_setup = NULL,
-    .bios_info_finish = NULL,
-
-    .e820_setup = NULL,
-
-    .acpi_build_tables = ovmf_acpi_build_tables,
-    .create_mp_tables = NULL,
-    .create_smbios_tables = ovmf_create_smbios_tables,
-    .create_pir_tables = NULL,
-};
-
-struct bios_config ovmf64_config =  {
-    .name = "OVMF-X64",
-
-    .image = ovmf64,
-    .image_size = sizeof(ovmf64),
+    .image = ovmf,
+    .image_size = sizeof(ovmf),
 
     .bios_address = 0,
     .bios_load = ovmf_load,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:35:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S0zyu-0000fy-0y; Fri, 24 Feb 2012 18:35:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S0zyr-0000fm-Qp
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:34:58 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330108437!58179357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18762 invoked from network); 24 Feb 2012 18:33:58 -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 Feb 2012 18:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:34:56 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:34:56 +0000
MIME-Version: 1.0
X-Mercurial-Node: eb51dd646ce097b54a588fc5e5e246e46111fc85
Message-ID: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 24 Feb 2012 18:35:55 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Signed-off-by: Attilio Rao
	<attilio.rao@citrix.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

diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/Makefile	Fri Feb 24 18:35:37 2012 +0000
@@ -55,10 +55,9 @@ ROMS :=
 
 ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
-CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
-OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
-OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
-ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
+CFLAGS += -DENABLE_OVMF
+OVMF_ROM := $(OVMF_DIR)/ovmf.bin
+ROMS += $(OVMF_ROM)
 endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -102,15 +101,9 @@ ifneq ($(SEABIOS_ROM),)
 	echo "#endif" >> $@.new
 endif
 
-ifneq ($(OVMF32_ROM),)
-	echo "#ifdef ROM_INCLUDE_OVMF32" >> $@.new
-	sh ./mkhex ovmf32 $(OVMF32_ROM) >> $@.new
-	echo "#endif" >> $@.new	
-endif 
-
-ifneq ($(OVMF64_ROM),)
-	echo "#ifdef ROM_INCLUDE_OVMF64" >> $@.new
-	sh ./mkhex ovmf64 $(OVMF64_ROM) >> $@.new
+ifneq ($(OVMF_ROM),)
+	echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
+	sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
 	echo "#endif" >> $@.new	
 endif 
 
diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/config.h	Fri Feb 24 18:35:37 2012 +0000
@@ -35,8 +35,7 @@ struct bios_config {
 
 extern struct bios_config rombios_config;
 extern struct bios_config seabios_config;
-extern struct bios_config ovmf32_config;
-extern struct bios_config ovmf64_config;
+extern struct bios_config ovmf_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Feb 24 18:35:37 2012 +0000
@@ -212,11 +212,8 @@ struct bios_info {
 #ifdef ENABLE_SEABIOS
     { "seabios", &seabios_config, },
 #endif
-#ifdef ENABLE_OVMF32
-    { "ovmf-ia32", &ovmf32_config, },
-#endif
-#ifdef ENABLE_OVMF64
-    { "ovmf-x64", &ovmf64_config, },
+#ifdef ENABLE_OVMF
+    { "ovmf", &ovmf_config, },
 #endif
     { NULL, NULL }
 };
diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/ovmf.c
--- a/tools/firmware/hvmloader/ovmf.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/firmware/hvmloader/ovmf.c	Fri Feb 24 18:35:37 2012 +0000
@@ -35,8 +35,7 @@
 #include <xen/hvm/ioreq.h>
 #include <xen/memory.h>
 
-#define ROM_INCLUDE_OVMF32
-#define ROM_INCLUDE_OVMF64
+#define ROM_INCLUDE_OVMF
 #include "roms.inc"
 
 #define OVMF_BEGIN              0xFFF00000ULL
@@ -48,8 +47,8 @@
 #define LOWCHUNK_MAXOFFSET      0x0000FFFF
 #define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
 
-extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
-extern int dsdt_anycpu_len, dsdt_15cpu_len;
+extern unsigned char dsdt_anycpu[];
+extern int dsdt_anycpu_len;
 
 static void ovmf_load(const struct bios_config *config)
 {
@@ -79,8 +78,8 @@ static void ovmf_acpi_build_tables(void)
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
-        .dsdt_15cpu = dsdt_15cpu,
-        .dsdt_15cpu_len = dsdt_15cpu_len,
+        .dsdt_15cpu = NULL, 
+        .dsdt_15cpu_len = 0
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
@@ -94,33 +93,11 @@ static void ovmf_create_smbios_tables(vo
         SMBIOS_PHYSICAL_END);
 }
 
-struct bios_config ovmf32_config =  {
-    .name = "OVMF-IA32",
+struct bios_config ovmf_config =  {
+    .name = "OVMF",
 
-    .image = ovmf32,
-    .image_size = sizeof(ovmf32),
-
-    .bios_address = 0,
-    .bios_load = ovmf_load,
-
-    .load_roms = 0,
-
-    .bios_info_setup = NULL,
-    .bios_info_finish = NULL,
-
-    .e820_setup = NULL,
-
-    .acpi_build_tables = ovmf_acpi_build_tables,
-    .create_mp_tables = NULL,
-    .create_smbios_tables = ovmf_create_smbios_tables,
-    .create_pir_tables = NULL,
-};
-
-struct bios_config ovmf64_config =  {
-    .name = "OVMF-X64",
-
-    .image = ovmf64,
-    .image_size = sizeof(ovmf64),
+    .image = ovmf,
+    .image_size = sizeof(ovmf),
 
     .bios_address = 0,
     .bios_load = ovmf_load,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:46:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S109j-0000rc-72; Fri, 24 Feb 2012 18:46:11 +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 1S109h-0000rX-M2
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:46:09 +0000
Received: from [85.158.139.83:40177] by server-11.bemta-5.messagelabs.com id
	0D/D3-14397-0FAD74F4; Fri, 24 Feb 2012 18:46:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330109167!12686888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23808 invoked from network); 24 Feb 2012 18:46:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927783"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:45:56 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 18:45:56 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:45:53 +0000
Message-ID: <1330109153-5531-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: fix unaligned memcpy() and memmove()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

If memcpy() and memmove() were used with source and destination of
different alignment then the result would be all jumbled.

When their implementations were imported from Linux some macros for
big-endian platforms were taken instead of the correct little-endian
ones (specifically, the push and pull macros in assembler.h).

Fix this by taking Linux's arch/include/asm/assembler.h as-is and
making only the minimum changes necessary for Xen.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/lib/assembler.h |  324 ++++++++++++++++++++++++++++++++++++++---
 1 files changed, 300 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
index f8f0961..f8d4b3a 100644
--- a/xen/arch/arm/lib/assembler.h
+++ b/xen/arch/arm/lib/assembler.h
@@ -1,11 +1,72 @@
-#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
-#define __ARCH_ARM_LIB_ASSEMBLER_H__
-
 /* From Linux arch/arm/include/asm/assembler.h */
 /*
+ *  arch/arm/include/asm/assembler.h
+ *
+ *  Copyright (C) 1996-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  This file contains arm architecture specific defines
+ *  for the different processors.
+ *
+ *  Do not include any C declarations in this file - it is included by
+ *  assembler source.
+ */
+#ifndef __ASM_ASSEMBLER_H__
+#define __ASM_ASSEMBLER_H__
+
+#ifndef __ASSEMBLY__
+#error "Only include this from assembly code"
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+/*
+ * Endian independent macros for shifting bytes within registers.
+ */
+#ifndef __ARMEB__
+#define pull            lsr
+#define push            lsl
+#define get_byte_0      lsl #0
+#define get_byte_1	lsr #8
+#define get_byte_2	lsr #16
+#define get_byte_3	lsr #24
+#define put_byte_0      lsl #0
+#define put_byte_1	lsl #8
+#define put_byte_2	lsl #16
+#define put_byte_3	lsl #24
+#else
+#define pull            lsl
+#define push            lsr
+#define get_byte_0	lsr #24
+#define get_byte_1	lsr #16
+#define get_byte_2	lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0	lsl #24
+#define put_byte_1	lsl #16
+#define put_byte_2	lsl #8
+#define put_byte_3      lsl #0
+#endif
+
+/*
  * Data preload for architectures that support it
  */
-#define PLD(code...)    code
+#if __LINUX_ARM_ARCH__ >= 5
+#define PLD(code...)	code
+#else
+#define PLD(code...)
+#endif
 
 /*
  * This can be used to enable code to cacheline align the destination
@@ -16,34 +77,249 @@
  *
  * On Feroceon there is much to gain however, regardless of cache mode.
  */
-#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#ifdef CONFIG_CPU_FEROCEON
 #define CALGN(code...) code
 #else
 #define CALGN(code...)
 #endif
 
-// No Thumb, hence:
-#define W(instr)        instr
-#define ARM(instr...)   instr
-#define THUMB(instr...)
+/*
+ * Enable and disable interrupts
+ */
+#if __LINUX_ARM_ARCH__ >= 6
+	.macro	disable_irq_notrace
+	cpsid	i
+	.endm
 
-#ifdef CONFIG_ARM_UNWIND
-#define UNWIND(code...)         code
+	.macro	enable_irq_notrace
+	cpsie	i
+	.endm
 #else
-#define UNWIND(code...)
+	.macro	disable_irq_notrace
+	msr	cpsr_c, #PSR_I_BIT | SVC_MODE
+	.endm
+
+	.macro	enable_irq_notrace
+	msr	cpsr_c, #SVC_MODE
+	.endm
 #endif
 
-#define pull            lsl
-#define push            lsr
-#define get_byte_0      lsr #24
-#define get_byte_1      lsr #16
-#define get_byte_2      lsr #8
-#define get_byte_3      lsl #0
-#define put_byte_0      lsl #24
-#define put_byte_1      lsl #16
-#define put_byte_2      lsl #8
-#define put_byte_3      lsl #0
+	.macro asm_trace_hardirqs_off
+#if defined(CONFIG_TRACE_IRQFLAGS)
+	stmdb   sp!, {r0-r3, ip, lr}
+	bl	trace_hardirqs_off
+	ldmia	sp!, {r0-r3, ip, lr}
+#endif
+	.endm
+
+	.macro asm_trace_hardirqs_on_cond, cond
+#if defined(CONFIG_TRACE_IRQFLAGS)
+	/*
+	 * actually the registers should be pushed and pop'd conditionally, but
+	 * after bl the flags are certainly clobbered
+	 */
+	stmdb   sp!, {r0-r3, ip, lr}
+	bl\cond	trace_hardirqs_on
+	ldmia	sp!, {r0-r3, ip, lr}
+#endif
+	.endm
+
+	.macro asm_trace_hardirqs_on
+	asm_trace_hardirqs_on_cond al
+	.endm
+
+	.macro disable_irq
+	disable_irq_notrace
+	asm_trace_hardirqs_off
+	.endm
+
+	.macro enable_irq
+	asm_trace_hardirqs_on
+	enable_irq_notrace
+	.endm
+/*
+ * Save the current IRQ state and disable IRQs.  Note that this macro
+ * assumes FIQs are enabled, and that the processor is in SVC mode.
+ */
+	.macro	save_and_disable_irqs, oldcpsr
+	mrs	\oldcpsr, cpsr
+	disable_irq
+	.endm
+
+/*
+ * Restore interrupt state previously stored in a register.  We don't
+ * guarantee that this will preserve the flags.
+ */
+	.macro	restore_irqs_notrace, oldcpsr
+	msr	cpsr_c, \oldcpsr
+	.endm
+
+	.macro restore_irqs, oldcpsr
+	tst	\oldcpsr, #PSR_I_BIT
+	asm_trace_hardirqs_on_cond eq
+	restore_irqs_notrace \oldcpsr
+	.endm
+
+#define USER(x...)				\
+9999:	x;					\
+	.pushsection __ex_table,"a";		\
+	.align	3;				\
+	.long	9999b,9001f;			\
+	.popsection
+
+#ifdef CONFIG_SMP
+#define ALT_SMP(instr...)					\
+9998:	instr
+/*
+ * Note: if you get assembler errors from ALT_UP() when building with
+ * CONFIG_THUMB2_KERNEL, you almost certainly need to use
+ * ALT_SMP( W(instr) ... )
+ */
+#define ALT_UP(instr...)					\
+	.pushsection ".alt.smp.init", "a"			;\
+	.long	9998b						;\
+9997:	instr							;\
+	.if . - 9997b != 4					;\
+		.error "ALT_UP() content must assemble to exactly 4 bytes";\
+	.endif							;\
+	.popsection
+#define ALT_UP_B(label)					\
+	.equ	up_b_offset, label - 9998b			;\
+	.pushsection ".alt.smp.init", "a"			;\
+	.long	9998b						;\
+	W(b)	. + up_b_offset					;\
+	.popsection
+#else
+#define ALT_SMP(instr...)
+#define ALT_UP(instr...) instr
+#define ALT_UP_B(label) b label
+#endif
+
+/*
+ * Instruction barrier
+ */
+	.macro	instr_sync
+#if __LINUX_ARM_ARCH__ >= 7
+	isb
+#elif __LINUX_ARM_ARCH__ == 6
+	mcr	p15, 0, r0, c7, c5, 4
+#endif
+	.endm
+
+/*
+ * SMP data memory barrier
+ */
+	.macro	smp_dmb mode
+#ifdef CONFIG_SMP
+#if __LINUX_ARM_ARCH__ >= 7
+	.ifeqs "\mode","arm"
+	ALT_SMP(dmb)
+	.else
+	ALT_SMP(W(dmb))
+	.endif
+#elif __LINUX_ARM_ARCH__ == 6
+	ALT_SMP(mcr	p15, 0, r0, c7, c10, 5)	@ dmb
+#else
+#error Incompatible SMP platform
+#endif
+	.ifeqs "\mode","arm"
+	ALT_UP(nop)
+	.else
+	ALT_UP(W(nop))
+	.endif
+#endif
+	.endm
+
+#ifdef CONFIG_THUMB2_KERNEL
+	.macro	setmode, mode, reg
+	mov	\reg, #\mode
+	msr	cpsr_c, \reg
+	.endm
+#else
+	.macro	setmode, mode, reg
+	msr	cpsr_c, #\mode
+	.endm
+#endif
+
+/*
+ * STRT/LDRT access macros with ARM and Thumb-2 variants
+ */
+#ifdef CONFIG_THUMB2_KERNEL
+
+	.macro	usraccoff, instr, reg, ptr, inc, off, cond, abort, t=T()
+9999:
+	.if	\inc == 1
+	\instr\cond\()b\()\t\().w \reg, [\ptr, #\off]
+	.elseif	\inc == 4
+	\instr\cond\()\t\().w \reg, [\ptr, #\off]
+	.else
+	.error	"Unsupported inc macro argument"
+	.endif
+
+	.pushsection __ex_table,"a"
+	.align	3
+	.long	9999b, \abort
+	.popsection
+	.endm
+
+	.macro	usracc, instr, reg, ptr, inc, cond, rept, abort
+	@ explicit IT instruction needed because of the label
+	@ introduced by the USER macro
+	.ifnc	\cond,al
+	.if	\rept == 1
+	itt	\cond
+	.elseif	\rept == 2
+	ittt	\cond
+	.else
+	.error	"Unsupported rept macro argument"
+	.endif
+	.endif
+
+	@ Slightly optimised to avoid incrementing the pointer twice
+	usraccoff \instr, \reg, \ptr, \inc, 0, \cond, \abort
+	.if	\rept == 2
+	usraccoff \instr, \reg, \ptr, \inc, \inc, \cond, \abort
+	.endif
+
+	add\cond \ptr, #\rept * \inc
+	.endm
+
+#else	/* !CONFIG_THUMB2_KERNEL */
+
+	.macro	usracc, instr, reg, ptr, inc, cond, rept, abort, t=T()
+	.rept	\rept
+9999:
+	.if	\inc == 1
+	\instr\cond\()b\()\t \reg, [\ptr], #\inc
+	.elseif	\inc == 4
+	\instr\cond\()\t \reg, [\ptr], #\inc
+	.else
+	.error	"Unsupported inc macro argument"
+	.endif
+
+	.pushsection __ex_table,"a"
+	.align	3
+	.long	9999b, \abort
+	.popsection
+	.endr
+	.endm
+
+#endif	/* CONFIG_THUMB2_KERNEL */
+
+	.macro	strusr, reg, ptr, inc, cond=al, rept=1, abort=9001f
+	usracc	str, \reg, \ptr, \inc, \cond, \rept, \abort
+	.endm
+
+	.macro	ldrusr, reg, ptr, inc, cond=al, rept=1, abort=9001f
+	usracc	ldr, \reg, \ptr, \inc, \cond, \rept, \abort
+	.endm
 
-#define smp_dmb dmb
+/* Utility macro for declaring string literals */
+	.macro	string name:req, string
+	.type \name , #object
+\name:
+	.asciz "\string"
+	.size \name , . - \name
+	.endm
 
-#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
+#endif /* __ASM_ASSEMBLER_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:46:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S109j-0000rc-72; Fri, 24 Feb 2012 18:46:11 +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 1S109h-0000rX-M2
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:46:09 +0000
Received: from [85.158.139.83:40177] by server-11.bemta-5.messagelabs.com id
	0D/D3-14397-0FAD74F4; Fri, 24 Feb 2012 18:46:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330109167!12686888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23808 invoked from network); 24 Feb 2012 18:46:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927783"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:45:56 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 24 Feb 2012 18:45:56 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:45:53 +0000
Message-ID: <1330109153-5531-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: fix unaligned memcpy() and memmove()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

If memcpy() and memmove() were used with source and destination of
different alignment then the result would be all jumbled.

When their implementations were imported from Linux some macros for
big-endian platforms were taken instead of the correct little-endian
ones (specifically, the push and pull macros in assembler.h).

Fix this by taking Linux's arch/include/asm/assembler.h as-is and
making only the minimum changes necessary for Xen.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/lib/assembler.h |  324 ++++++++++++++++++++++++++++++++++++++---
 1 files changed, 300 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/lib/assembler.h b/xen/arch/arm/lib/assembler.h
index f8f0961..f8d4b3a 100644
--- a/xen/arch/arm/lib/assembler.h
+++ b/xen/arch/arm/lib/assembler.h
@@ -1,11 +1,72 @@
-#ifndef __ARCH_ARM_LIB_ASSEMBLER_H__
-#define __ARCH_ARM_LIB_ASSEMBLER_H__
-
 /* From Linux arch/arm/include/asm/assembler.h */
 /*
+ *  arch/arm/include/asm/assembler.h
+ *
+ *  Copyright (C) 1996-2000 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  This file contains arm architecture specific defines
+ *  for the different processors.
+ *
+ *  Do not include any C declarations in this file - it is included by
+ *  assembler source.
+ */
+#ifndef __ASM_ASSEMBLER_H__
+#define __ASM_ASSEMBLER_H__
+
+#ifndef __ASSEMBLY__
+#error "Only include this from assembly code"
+#endif
+
+// No Thumb, hence:
+#define W(instr)        instr
+#define ARM(instr...)   instr
+#define THUMB(instr...)
+
+#ifdef CONFIG_ARM_UNWIND
+#define UNWIND(code...)         code
+#else
+#define UNWIND(code...)
+#endif
+
+/*
+ * Endian independent macros for shifting bytes within registers.
+ */
+#ifndef __ARMEB__
+#define pull            lsr
+#define push            lsl
+#define get_byte_0      lsl #0
+#define get_byte_1	lsr #8
+#define get_byte_2	lsr #16
+#define get_byte_3	lsr #24
+#define put_byte_0      lsl #0
+#define put_byte_1	lsl #8
+#define put_byte_2	lsl #16
+#define put_byte_3	lsl #24
+#else
+#define pull            lsl
+#define push            lsr
+#define get_byte_0	lsr #24
+#define get_byte_1	lsr #16
+#define get_byte_2	lsr #8
+#define get_byte_3      lsl #0
+#define put_byte_0	lsl #24
+#define put_byte_1	lsl #16
+#define put_byte_2	lsl #8
+#define put_byte_3      lsl #0
+#endif
+
+/*
  * Data preload for architectures that support it
  */
-#define PLD(code...)    code
+#if __LINUX_ARM_ARCH__ >= 5
+#define PLD(code...)	code
+#else
+#define PLD(code...)
+#endif
 
 /*
  * This can be used to enable code to cacheline align the destination
@@ -16,34 +77,249 @@
  *
  * On Feroceon there is much to gain however, regardless of cache mode.
  */
-#ifdef CONFIG_CPU_FEROCEON /* Not in Xen... */
+#ifdef CONFIG_CPU_FEROCEON
 #define CALGN(code...) code
 #else
 #define CALGN(code...)
 #endif
 
-// No Thumb, hence:
-#define W(instr)        instr
-#define ARM(instr...)   instr
-#define THUMB(instr...)
+/*
+ * Enable and disable interrupts
+ */
+#if __LINUX_ARM_ARCH__ >= 6
+	.macro	disable_irq_notrace
+	cpsid	i
+	.endm
 
-#ifdef CONFIG_ARM_UNWIND
-#define UNWIND(code...)         code
+	.macro	enable_irq_notrace
+	cpsie	i
+	.endm
 #else
-#define UNWIND(code...)
+	.macro	disable_irq_notrace
+	msr	cpsr_c, #PSR_I_BIT | SVC_MODE
+	.endm
+
+	.macro	enable_irq_notrace
+	msr	cpsr_c, #SVC_MODE
+	.endm
 #endif
 
-#define pull            lsl
-#define push            lsr
-#define get_byte_0      lsr #24
-#define get_byte_1      lsr #16
-#define get_byte_2      lsr #8
-#define get_byte_3      lsl #0
-#define put_byte_0      lsl #24
-#define put_byte_1      lsl #16
-#define put_byte_2      lsl #8
-#define put_byte_3      lsl #0
+	.macro asm_trace_hardirqs_off
+#if defined(CONFIG_TRACE_IRQFLAGS)
+	stmdb   sp!, {r0-r3, ip, lr}
+	bl	trace_hardirqs_off
+	ldmia	sp!, {r0-r3, ip, lr}
+#endif
+	.endm
+
+	.macro asm_trace_hardirqs_on_cond, cond
+#if defined(CONFIG_TRACE_IRQFLAGS)
+	/*
+	 * actually the registers should be pushed and pop'd conditionally, but
+	 * after bl the flags are certainly clobbered
+	 */
+	stmdb   sp!, {r0-r3, ip, lr}
+	bl\cond	trace_hardirqs_on
+	ldmia	sp!, {r0-r3, ip, lr}
+#endif
+	.endm
+
+	.macro asm_trace_hardirqs_on
+	asm_trace_hardirqs_on_cond al
+	.endm
+
+	.macro disable_irq
+	disable_irq_notrace
+	asm_trace_hardirqs_off
+	.endm
+
+	.macro enable_irq
+	asm_trace_hardirqs_on
+	enable_irq_notrace
+	.endm
+/*
+ * Save the current IRQ state and disable IRQs.  Note that this macro
+ * assumes FIQs are enabled, and that the processor is in SVC mode.
+ */
+	.macro	save_and_disable_irqs, oldcpsr
+	mrs	\oldcpsr, cpsr
+	disable_irq
+	.endm
+
+/*
+ * Restore interrupt state previously stored in a register.  We don't
+ * guarantee that this will preserve the flags.
+ */
+	.macro	restore_irqs_notrace, oldcpsr
+	msr	cpsr_c, \oldcpsr
+	.endm
+
+	.macro restore_irqs, oldcpsr
+	tst	\oldcpsr, #PSR_I_BIT
+	asm_trace_hardirqs_on_cond eq
+	restore_irqs_notrace \oldcpsr
+	.endm
+
+#define USER(x...)				\
+9999:	x;					\
+	.pushsection __ex_table,"a";		\
+	.align	3;				\
+	.long	9999b,9001f;			\
+	.popsection
+
+#ifdef CONFIG_SMP
+#define ALT_SMP(instr...)					\
+9998:	instr
+/*
+ * Note: if you get assembler errors from ALT_UP() when building with
+ * CONFIG_THUMB2_KERNEL, you almost certainly need to use
+ * ALT_SMP( W(instr) ... )
+ */
+#define ALT_UP(instr...)					\
+	.pushsection ".alt.smp.init", "a"			;\
+	.long	9998b						;\
+9997:	instr							;\
+	.if . - 9997b != 4					;\
+		.error "ALT_UP() content must assemble to exactly 4 bytes";\
+	.endif							;\
+	.popsection
+#define ALT_UP_B(label)					\
+	.equ	up_b_offset, label - 9998b			;\
+	.pushsection ".alt.smp.init", "a"			;\
+	.long	9998b						;\
+	W(b)	. + up_b_offset					;\
+	.popsection
+#else
+#define ALT_SMP(instr...)
+#define ALT_UP(instr...) instr
+#define ALT_UP_B(label) b label
+#endif
+
+/*
+ * Instruction barrier
+ */
+	.macro	instr_sync
+#if __LINUX_ARM_ARCH__ >= 7
+	isb
+#elif __LINUX_ARM_ARCH__ == 6
+	mcr	p15, 0, r0, c7, c5, 4
+#endif
+	.endm
+
+/*
+ * SMP data memory barrier
+ */
+	.macro	smp_dmb mode
+#ifdef CONFIG_SMP
+#if __LINUX_ARM_ARCH__ >= 7
+	.ifeqs "\mode","arm"
+	ALT_SMP(dmb)
+	.else
+	ALT_SMP(W(dmb))
+	.endif
+#elif __LINUX_ARM_ARCH__ == 6
+	ALT_SMP(mcr	p15, 0, r0, c7, c10, 5)	@ dmb
+#else
+#error Incompatible SMP platform
+#endif
+	.ifeqs "\mode","arm"
+	ALT_UP(nop)
+	.else
+	ALT_UP(W(nop))
+	.endif
+#endif
+	.endm
+
+#ifdef CONFIG_THUMB2_KERNEL
+	.macro	setmode, mode, reg
+	mov	\reg, #\mode
+	msr	cpsr_c, \reg
+	.endm
+#else
+	.macro	setmode, mode, reg
+	msr	cpsr_c, #\mode
+	.endm
+#endif
+
+/*
+ * STRT/LDRT access macros with ARM and Thumb-2 variants
+ */
+#ifdef CONFIG_THUMB2_KERNEL
+
+	.macro	usraccoff, instr, reg, ptr, inc, off, cond, abort, t=T()
+9999:
+	.if	\inc == 1
+	\instr\cond\()b\()\t\().w \reg, [\ptr, #\off]
+	.elseif	\inc == 4
+	\instr\cond\()\t\().w \reg, [\ptr, #\off]
+	.else
+	.error	"Unsupported inc macro argument"
+	.endif
+
+	.pushsection __ex_table,"a"
+	.align	3
+	.long	9999b, \abort
+	.popsection
+	.endm
+
+	.macro	usracc, instr, reg, ptr, inc, cond, rept, abort
+	@ explicit IT instruction needed because of the label
+	@ introduced by the USER macro
+	.ifnc	\cond,al
+	.if	\rept == 1
+	itt	\cond
+	.elseif	\rept == 2
+	ittt	\cond
+	.else
+	.error	"Unsupported rept macro argument"
+	.endif
+	.endif
+
+	@ Slightly optimised to avoid incrementing the pointer twice
+	usraccoff \instr, \reg, \ptr, \inc, 0, \cond, \abort
+	.if	\rept == 2
+	usraccoff \instr, \reg, \ptr, \inc, \inc, \cond, \abort
+	.endif
+
+	add\cond \ptr, #\rept * \inc
+	.endm
+
+#else	/* !CONFIG_THUMB2_KERNEL */
+
+	.macro	usracc, instr, reg, ptr, inc, cond, rept, abort, t=T()
+	.rept	\rept
+9999:
+	.if	\inc == 1
+	\instr\cond\()b\()\t \reg, [\ptr], #\inc
+	.elseif	\inc == 4
+	\instr\cond\()\t \reg, [\ptr], #\inc
+	.else
+	.error	"Unsupported inc macro argument"
+	.endif
+
+	.pushsection __ex_table,"a"
+	.align	3
+	.long	9999b, \abort
+	.popsection
+	.endr
+	.endm
+
+#endif	/* CONFIG_THUMB2_KERNEL */
+
+	.macro	strusr, reg, ptr, inc, cond=al, rept=1, abort=9001f
+	usracc	str, \reg, \ptr, \inc, \cond, \rept, \abort
+	.endm
+
+	.macro	ldrusr, reg, ptr, inc, cond=al, rept=1, abort=9001f
+	usracc	ldr, \reg, \ptr, \inc, \cond, \rept, \abort
+	.endm
 
-#define smp_dmb dmb
+/* Utility macro for declaring string literals */
+	.macro	string name:req, string
+	.type \name , #object
+\name:
+	.asciz "\string"
+	.size \name , . - \name
+	.endm
 
-#endif /*  __ARCH_ARM_LIB_ASSEMBLER_H__ */
+#endif /* __ASM_ASSEMBLER_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:52:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10FN-00011m-W1; Fri, 24 Feb 2012 18:52:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S10FM-00011c-96
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:52:00 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330109513!14800148!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6386 invoked from network); 24 Feb 2012 18:51:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:51:53 +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.213.0;
	Fri, 24 Feb 2012 18:51:53 +0000
Message-ID: <4F47DC84.2020000@citrix.com>
Date: Fri, 24 Feb 2012 18:52:52 +0000
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>
References: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
In-Reply-To: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Signed-off-by: Attilio
	Rao	<attilio.rao@citrix.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Per discussion on the mailing list, drop the ovmf32 support and rename 
ovmf64 as the more generic name ovmf which becames the official 
supported one. Now the ROM has to be copied like that:

Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->  tools/firmware/ovmf/ovmf.bin

- Remove the 15cpus hack from ovmf because it should be unnecessary on 
nowadays windows/EFI supported.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

On 24/02/12 18:35, Attilio Rao wrote:
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/Makefile
> --- a/tools/firmware/hvmloader/Makefile	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/Makefile	Fri Feb 24 18:35:37 2012 +0000
> @@ -55,10 +55,9 @@ ROMS :=
>
>   ifeq ($(CONFIG_OVMF),y)
>   OBJS += ovmf.o
> -CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
> -OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
> -OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
> -ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
> +CFLAGS += -DENABLE_OVMF
> +OVMF_ROM := $(OVMF_DIR)/ovmf.bin
> +ROMS += $(OVMF_ROM)
>   endif
>
>   ifeq ($(CONFIG_ROMBIOS),y)
> @@ -102,15 +101,9 @@ ifneq ($(SEABIOS_ROM),)
>   	echo "#endif">>  $@.new
>   endif
>
> -ifneq ($(OVMF32_ROM),)
> -	echo "#ifdef ROM_INCLUDE_OVMF32">>  $@.new
> -	sh ./mkhex ovmf32 $(OVMF32_ROM)>>  $@.new
> -	echo "#endif">>  $@.new	
> -endif
> -
> -ifneq ($(OVMF64_ROM),)
> -	echo "#ifdef ROM_INCLUDE_OVMF64">>  $@.new
> -	sh ./mkhex ovmf64 $(OVMF64_ROM)>>  $@.new
> +ifneq ($(OVMF_ROM),)
> +	echo "#ifdef ROM_INCLUDE_OVMF">>  $@.new
> +	sh ./mkhex ovmf $(OVMF_ROM)>>  $@.new
>   	echo "#endif">>  $@.new	
>   endif
>
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/config.h	Fri Feb 24 18:35:37 2012 +0000
> @@ -35,8 +35,7 @@ struct bios_config {
>
>   extern struct bios_config rombios_config;
>   extern struct bios_config seabios_config;
> -extern struct bios_config ovmf32_config;
> -extern struct bios_config ovmf64_config;
> +extern struct bios_config ovmf_config;
>
>   #define PAGE_SHIFT 12
>   #define PAGE_SIZE  (1ul<<  PAGE_SHIFT)
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c	Fri Feb 24 18:35:37 2012 +0000
> @@ -212,11 +212,8 @@ struct bios_info {
>   #ifdef ENABLE_SEABIOS
>       { "seabios",&seabios_config, },
>   #endif
> -#ifdef ENABLE_OVMF32
> -    { "ovmf-ia32",&ovmf32_config, },
> -#endif
> -#ifdef ENABLE_OVMF64
> -    { "ovmf-x64",&ovmf64_config, },
> +#ifdef ENABLE_OVMF
> +    { "ovmf",&ovmf_config, },
>   #endif
>       { NULL, NULL }
>   };
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/ovmf.c
> --- a/tools/firmware/hvmloader/ovmf.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/ovmf.c	Fri Feb 24 18:35:37 2012 +0000
> @@ -35,8 +35,7 @@
>   #include<xen/hvm/ioreq.h>
>   #include<xen/memory.h>
>
> -#define ROM_INCLUDE_OVMF32
> -#define ROM_INCLUDE_OVMF64
> +#define ROM_INCLUDE_OVMF
>   #include "roms.inc"
>
>   #define OVMF_BEGIN              0xFFF00000ULL
> @@ -48,8 +47,8 @@
>   #define LOWCHUNK_MAXOFFSET      0x0000FFFF
>   #define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
>
> -extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
> -extern int dsdt_anycpu_len, dsdt_15cpu_len;
> +extern unsigned char dsdt_anycpu[];
> +extern int dsdt_anycpu_len;
>
>   static void ovmf_load(const struct bios_config *config)
>   {
> @@ -79,8 +78,8 @@ static void ovmf_acpi_build_tables(void)
>       struct acpi_config config = {
>           .dsdt_anycpu = dsdt_anycpu,
>           .dsdt_anycpu_len = dsdt_anycpu_len,
> -        .dsdt_15cpu = dsdt_15cpu,
> -        .dsdt_15cpu_len = dsdt_15cpu_len,
> +        .dsdt_15cpu = NULL,
> +        .dsdt_15cpu_len = 0
>       };
>
>       acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> @@ -94,33 +93,11 @@ static void ovmf_create_smbios_tables(vo
>           SMBIOS_PHYSICAL_END);
>   }
>
> -struct bios_config ovmf32_config =  {
> -    .name = "OVMF-IA32",
> +struct bios_config ovmf_config =  {
> +    .name = "OVMF",
>
> -    .image = ovmf32,
> -    .image_size = sizeof(ovmf32),
> -
> -    .bios_address = 0,
> -    .bios_load = ovmf_load,
> -
> -    .load_roms = 0,
> -
> -    .bios_info_setup = NULL,
> -    .bios_info_finish = NULL,
> -
> -    .e820_setup = NULL,
> -
> -    .acpi_build_tables = ovmf_acpi_build_tables,
> -    .create_mp_tables = NULL,
> -    .create_smbios_tables = ovmf_create_smbios_tables,
> -    .create_pir_tables = NULL,
> -};
> -
> -struct bios_config ovmf64_config =  {
> -    .name = "OVMF-X64",
> -
> -    .image = ovmf64,
> -    .image_size = sizeof(ovmf64),
> +    .image = ovmf,
> +    .image_size = sizeof(ovmf),
>
>       .bios_address = 0,
>       .bios_load = ovmf_load,
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>    


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:52:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10FN-00011m-W1; Fri, 24 Feb 2012 18:52:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S10FM-00011c-96
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:52:00 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330109513!14800148!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6386 invoked from network); 24 Feb 2012 18:51:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:51:53 +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.213.0;
	Fri, 24 Feb 2012 18:51:53 +0000
Message-ID: <4F47DC84.2020000@citrix.com>
Date: Fri, 24 Feb 2012 18:52:52 +0000
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>
References: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
In-Reply-To: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Signed-off-by: Attilio
	Rao	<attilio.rao@citrix.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- Per discussion on the mailing list, drop the ovmf32 support and rename 
ovmf64 as the more generic name ovmf which becames the official 
supported one. Now the ROM has to be copied like that:

Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->  tools/firmware/ovmf/ovmf.bin

- Remove the 15cpus hack from ovmf because it should be unnecessary on 
nowadays windows/EFI supported.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

On 24/02/12 18:35, Attilio Rao wrote:
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/Makefile
> --- a/tools/firmware/hvmloader/Makefile	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/Makefile	Fri Feb 24 18:35:37 2012 +0000
> @@ -55,10 +55,9 @@ ROMS :=
>
>   ifeq ($(CONFIG_OVMF),y)
>   OBJS += ovmf.o
> -CFLAGS += -DENABLE_OVMF32 -DENABLE_OVMF64
> -OVMF32_ROM := $(OVMF_DIR)/ovmf-ia32.bin
> -OVMF64_ROM := $(OVMF_DIR)/ovmf-x64.bin
> -ROMS += $(OVMF32_ROM) $(OVMF64_ROM)
> +CFLAGS += -DENABLE_OVMF
> +OVMF_ROM := $(OVMF_DIR)/ovmf.bin
> +ROMS += $(OVMF_ROM)
>   endif
>
>   ifeq ($(CONFIG_ROMBIOS),y)
> @@ -102,15 +101,9 @@ ifneq ($(SEABIOS_ROM),)
>   	echo "#endif">>  $@.new
>   endif
>
> -ifneq ($(OVMF32_ROM),)
> -	echo "#ifdef ROM_INCLUDE_OVMF32">>  $@.new
> -	sh ./mkhex ovmf32 $(OVMF32_ROM)>>  $@.new
> -	echo "#endif">>  $@.new	
> -endif
> -
> -ifneq ($(OVMF64_ROM),)
> -	echo "#ifdef ROM_INCLUDE_OVMF64">>  $@.new
> -	sh ./mkhex ovmf64 $(OVMF64_ROM)>>  $@.new
> +ifneq ($(OVMF_ROM),)
> +	echo "#ifdef ROM_INCLUDE_OVMF">>  $@.new
> +	sh ./mkhex ovmf $(OVMF_ROM)>>  $@.new
>   	echo "#endif">>  $@.new	
>   endif
>
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/config.h	Fri Feb 24 18:35:37 2012 +0000
> @@ -35,8 +35,7 @@ struct bios_config {
>
>   extern struct bios_config rombios_config;
>   extern struct bios_config seabios_config;
> -extern struct bios_config ovmf32_config;
> -extern struct bios_config ovmf64_config;
> +extern struct bios_config ovmf_config;
>
>   #define PAGE_SHIFT 12
>   #define PAGE_SIZE  (1ul<<  PAGE_SHIFT)
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c	Fri Feb 24 18:35:37 2012 +0000
> @@ -212,11 +212,8 @@ struct bios_info {
>   #ifdef ENABLE_SEABIOS
>       { "seabios",&seabios_config, },
>   #endif
> -#ifdef ENABLE_OVMF32
> -    { "ovmf-ia32",&ovmf32_config, },
> -#endif
> -#ifdef ENABLE_OVMF64
> -    { "ovmf-x64",&ovmf64_config, },
> +#ifdef ENABLE_OVMF
> +    { "ovmf",&ovmf_config, },
>   #endif
>       { NULL, NULL }
>   };
> diff -r adcd6ab160fa -r eb51dd646ce0 tools/firmware/hvmloader/ovmf.c
> --- a/tools/firmware/hvmloader/ovmf.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/firmware/hvmloader/ovmf.c	Fri Feb 24 18:35:37 2012 +0000
> @@ -35,8 +35,7 @@
>   #include<xen/hvm/ioreq.h>
>   #include<xen/memory.h>
>
> -#define ROM_INCLUDE_OVMF32
> -#define ROM_INCLUDE_OVMF64
> +#define ROM_INCLUDE_OVMF
>   #include "roms.inc"
>
>   #define OVMF_BEGIN              0xFFF00000ULL
> @@ -48,8 +47,8 @@
>   #define LOWCHUNK_MAXOFFSET      0x0000FFFF
>   #define LOWCHUNK_END            (OVMF_BEGIN + OVMF_SIZE)
>
> -extern unsigned char dsdt_anycpu[], dsdt_15cpu[];
> -extern int dsdt_anycpu_len, dsdt_15cpu_len;
> +extern unsigned char dsdt_anycpu[];
> +extern int dsdt_anycpu_len;
>
>   static void ovmf_load(const struct bios_config *config)
>   {
> @@ -79,8 +78,8 @@ static void ovmf_acpi_build_tables(void)
>       struct acpi_config config = {
>           .dsdt_anycpu = dsdt_anycpu,
>           .dsdt_anycpu_len = dsdt_anycpu_len,
> -        .dsdt_15cpu = dsdt_15cpu,
> -        .dsdt_15cpu_len = dsdt_15cpu_len,
> +        .dsdt_15cpu = NULL,
> +        .dsdt_15cpu_len = 0
>       };
>
>       acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> @@ -94,33 +93,11 @@ static void ovmf_create_smbios_tables(vo
>           SMBIOS_PHYSICAL_END);
>   }
>
> -struct bios_config ovmf32_config =  {
> -    .name = "OVMF-IA32",
> +struct bios_config ovmf_config =  {
> +    .name = "OVMF",
>
> -    .image = ovmf32,
> -    .image_size = sizeof(ovmf32),
> -
> -    .bios_address = 0,
> -    .bios_load = ovmf_load,
> -
> -    .load_roms = 0,
> -
> -    .bios_info_setup = NULL,
> -    .bios_info_finish = NULL,
> -
> -    .e820_setup = NULL,
> -
> -    .acpi_build_tables = ovmf_acpi_build_tables,
> -    .create_mp_tables = NULL,
> -    .create_smbios_tables = ovmf_create_smbios_tables,
> -    .create_pir_tables = NULL,
> -};
> -
> -struct bios_config ovmf64_config =  {
> -    .name = "OVMF-X64",
> -
> -    .image = ovmf64,
> -    .image_size = sizeof(ovmf64),
> +    .image = ovmf,
> +    .image_size = sizeof(ovmf),
>
>       .bios_address = 0,
>       .bios_load = ovmf_load,
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>    


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10IW-0001Ca-8Y; Fri, 24 Feb 2012 18:55:16 +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 1S10IU-0001Ag-Hb
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23588 invoked from network); 24 Feb 2012 18:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IO-00023K-9H; Fri, 24 Feb 2012 18:55:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IO-0001iT-8Q;
	Fri, 24 Feb 2012 18:55:08 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:50 +0000
Message-ID: <1330109703-6536-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/15] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 68bba8f..7735223 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1362,7 +1362,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1815,7 +1815,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2159,7 +2159,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2286,7 +2286,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2dc820c..0536f8c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -669,7 +669,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10IW-0001Ca-8Y; Fri, 24 Feb 2012 18:55:16 +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 1S10IU-0001Ag-Hb
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23588 invoked from network); 24 Feb 2012 18:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IO-00023K-9H; Fri, 24 Feb 2012 18:55:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IO-0001iT-8Q;
	Fri, 24 Feb 2012 18:55:08 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:50 +0000
Message-ID: <1330109703-6536-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/15] libxl: fix hang due to
	libxl__initiate_device_remove
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl__initiate_device_remove might discover that the operation was
complete, immediately (typically, if the device is already removed).

Previously, in this situation, it would return 0 to the caller but
never call libxl__ao_complete.  Fix this.  This necessitates passing
the egc in from the functions which are the ao initiators.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    8 ++++----
 tools/libxl/libxl_device.c   |   18 ++++++++++++------
 tools/libxl/libxl_internal.h |    3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 68bba8f..7735223 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1362,7 +1362,7 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -1815,7 +1815,7 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2159,7 +2159,7 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
@@ -2286,7 +2286,7 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__initiate_device_remove(ao, &device);
+    rc = libxl__initiate_device_remove(egc, ao, &device);
     if (rc) goto out;
 
     return AO_INPROGRESS;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c2880e0..c7e057d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -376,7 +376,8 @@ static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     device_remove_cleanup(gc, aorm);
 }
 
-int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
+int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao,
+                                  libxl__device *dev)
 {
     AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -388,11 +389,11 @@ int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
     libxl__ao_device_remove *aorm = 0;
 
     if (!state)
-        goto out;
+        goto out_ok;
     if (atoi(state) != 4) {
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
-        goto out;
+        goto out_ok;
     }
 
 retry_transaction:
@@ -404,7 +405,7 @@ retry_transaction:
             goto retry_transaction;
         else {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_fail;
         }
     }
 
@@ -417,13 +418,18 @@ retry_transaction:
     rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
                                  state_path, XenbusStateClosed,
                                  LIBXL_DESTROY_TIMEOUT * 1000);
-    if (rc) goto out;
+    if (rc) goto out_fail;
 
     return 0;
 
- out:
+ out_fail:
+    assert(rc);
     device_remove_cleanup(gc, aorm);
     return rc;
+
+ out_ok:
+    libxl__ao_complete(egc, ao, 0);
+    return 0;
 }
 
 int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2dc820c..0536f8c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -669,7 +669,8 @@ _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
  * this is done, the ao will be completed.  An error
  * return from libxl__initiate_device_remove means that the ao
  * will _not_ be completed and the caller must do so. */
-_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+_hidden int libxl__initiate_device_remove(libxl__egc*, libxl__ao*,
+                                          libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IV-0001Bx-2P; Fri, 24 Feb 2012 18:55: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 1S10IT-0001B9-26
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23672 invoked from network); 24 Feb 2012 18:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IR-00023Q-3W; Fri, 24 Feb 2012 18:55:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IR-0001ib-1z;
	Fri, 24 Feb 2012 18:55:11 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:52 +0000
Message-ID: <1330109703-6536-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/15] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7735223..fd890cf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IV-0001Bx-2P; Fri, 24 Feb 2012 18:55: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 1S10IT-0001B9-26
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23672 invoked from network); 24 Feb 2012 18:54:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IR-00023Q-3W; Fri, 24 Feb 2012 18:55:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IR-0001ib-1z;
	Fri, 24 Feb 2012 18:55:11 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:52 +0000
Message-ID: <1330109703-6536-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/15] libxl: Fix leak of ctx->lock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A mutex created with pthread_mutex_init, like ctx->lock, may need to
be destroyed with pthread_mutex_destroy.

Also, previously, if libxl__init_recursive_mutex failed, the nascent
ctx would be leaked.  Add some comments which will hopefully make
these kind of mistakes less likely in future.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7735223..fd890cf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,10 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
-        return ERROR_FAIL;
-    }
+    /* First initialise pointers (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -61,6 +58,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    /* The mutex is special because we can't idempotently destroy it */
+
+    if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        free(ctx);
+        ctx = 0;
+    }
+
+    /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
@@ -150,6 +157,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    pthread_mutex_destroy(&ctx->lock);
+
     GC_FREE;
     free(ctx);
     return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IW-0001D1-Q4; Fri, 24 Feb 2012 18:55:16 +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 1S10IV-0001Bw-Di
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23769 invoked from network); 24 Feb 2012 18:54:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IU-00023Z-7L; Fri, 24 Feb 2012 18:55:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IU-0001ip-6c;
	Fri, 24 Feb 2012 18:55:14 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:55 +0000
Message-ID: <1330109703-6536-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/15] libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be needed for pthread_atfork.  It is a mystery why it
hasn't been needed before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..347f192 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -26,6 +26,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IW-0001D1-Q4; Fri, 24 Feb 2012 18:55:16 +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 1S10IV-0001Bw-Di
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23769 invoked from network); 24 Feb 2012 18:54:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IU-00023Z-7L; Fri, 24 Feb 2012 18:55:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IU-0001ip-6c;
	Fri, 24 Feb 2012 18:55:14 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:55 +0000
Message-ID: <1330109703-6536-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/15] libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is going to be needed for pthread_atfork.  It is a mystery why it
hasn't been needed before.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 06764f2..347f192 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -26,6 +26,10 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+LIBXL_LIBS += $(PTHREAD_LIBS)
+
 LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IV-0001CM-RF; Fri, 24 Feb 2012 18:55: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 1S10IU-0001BV-7q
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23744 invoked from network); 24 Feb 2012 18:54:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IS-00023W-Pe; Fri, 24 Feb 2012 18:55:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IS-0001ij-Ow;
	Fri, 24 Feb 2012 18:55:12 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:54 +0000
Message-ID: <1330109703-6536-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/15] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

So abolish PTHREAD_LIBS in StdGNU.mk, and add PTHREAD_CFLAGS and
PTHREAD_LDFLAGS instead.  Fix the one user (libxc).

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later version of this patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/StdGNU.mk     |    4 +++-
 tools/libxc/Makefile |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 2af2841..97445a7 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -68,10 +68,12 @@ XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
 CURSES_LIBS = -lncurses
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
+PTHREAD_CFLAGS = -pthread
+PTHREAD_LDFLAGS = -pthread
+
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..09e2f5f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -72,6 +72,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -156,7 +158,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IV-0001CM-RF; Fri, 24 Feb 2012 18:55: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 1S10IU-0001BV-7q
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23744 invoked from network); 24 Feb 2012 18:54:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IS-00023W-Pe; Fri, 24 Feb 2012 18:55:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IS-0001ij-Ow;
	Fri, 24 Feb 2012 18:55:12 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:54 +0000
Message-ID: <1330109703-6536-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/15] tools: Correct PTHREAD options in
	config/StdGNU.mk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is not correct to say -lpthread.  The correct option is -pthread,
which may have sundry other effects on code generation etc.  It needs
to be passed both to compilation and linking.

So abolish PTHREAD_LIBS in StdGNU.mk, and add PTHREAD_CFLAGS and
PTHREAD_LDFLAGS instead.  Fix the one user (libxc).

There are still some other users in tree which pass -pthread or
-lpthread by adding it as a literal to their own compiler options.
These will be fixed in a later version of this patch.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 config/StdGNU.mk     |    4 +++-
 tools/libxc/Makefile |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 2af2841..97445a7 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -68,10 +68,12 @@ XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
 CURSES_LIBS = -lncurses
-PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl
 
+PTHREAD_CFLAGS = -pthread
+PTHREAD_LDFLAGS = -pthread
+
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..09e2f5f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -72,6 +72,8 @@ CFLAGS   += -I. $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS	+= $(PTHREAD_CFLAGS)
+
 # Define this to make it possible to run valgrind on code linked with these
 # libraries.
 #CFLAGS   += -DVALGRIND -O0 -ggdb3
@@ -156,7 +158,7 @@ libxenctrl.so.$(MAJOR): libxenctrl.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
 libxenctrl.so.$(MAJOR).$(MINOR): $(CTRL_PIC_OBJS)
-	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
+	$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenctrl.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(DLOPEN_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
 
 # libxenguest
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IS-0001B4-8C; Fri, 24 Feb 2012 18:55: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 1S10IR-0001An-6H
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23635 invoked from network); 24 Feb 2012 18:54:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IP-00023N-S6; Fri, 24 Feb 2012 18:55:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IP-0001iX-RJ;
	Fri, 24 Feb 2012 18:55:09 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:51 +0000
Message-ID: <1330109703-6536-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/15] libxl: Fix eventloop_iteration
	over-locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c89add8..5ac6334 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0536f8c..ac892ae 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1168,7 +1168,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1264,7 +1264,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IS-0001B4-8C; Fri, 24 Feb 2012 18:55: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 1S10IR-0001An-6H
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23635 invoked from network); 24 Feb 2012 18:54:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IP-00023N-S6; Fri, 24 Feb 2012 18:55:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IP-0001iX-RJ;
	Fri, 24 Feb 2012 18:55:09 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:51 +0000
Message-ID: <1330109703-6536-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/15] libxl: Fix eventloop_iteration
	over-locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

eventloop_iteration's head comment says that it must be called with
the ctx locked exactly once, and this is indeed true, and it's done
correctly at both the call sites.

However, it takes out the lock an additional time itself.  This is
wrong because it prevents the unlocks around poll from being
effective.  This would mean that a multithreaded event-loop using
program might suffer from undesired blocking, as one thread trying to
enter libxl might end up stalled by another thread waiting for a slow
event.  So remove those two lock calls.

Also add a couple of comments documenting the locking behaviour of
libxl__ao_inprogress and libxl__egc_cleanup.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    4 ----
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c89add8..5ac6334 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1058,8 +1058,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     int rc;
     struct timeval now;
     
-    CTX_LOCK;
-
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
@@ -1102,8 +1100,6 @@ static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
     afterpoll_internal(egc, poller,
                        poller->fd_polls_allocd, poller->fd_polls, now);
 
-    CTX_UNLOCK;
-
     rc = 0;
  out:
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0536f8c..ac892ae 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1168,7 +1168,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
   /* Frees memory allocated within this egc's gc, and and report all
    * occurred events via callback, if applicable.  May reenter the
-   * application; see restrictions above. */
+   * application; see restrictions above.  The ctx must be UNLOCKED. */
 
 /* convenience macros: */
 
@@ -1264,7 +1264,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
 _hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
                                     const libxl_asyncop_how*);
-_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */
 _hidden void libxl__ao_abort(libxl__ao *ao);
 _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IV-0001C5-F3; Fri, 24 Feb 2012 18:55: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 1S10IT-0001BJ-N8
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23729 invoked from network); 24 Feb 2012 18:54:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IS-00023T-0X; Fri, 24 Feb 2012 18:55:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IR-0001if-Vv;
	Fri, 24 Feb 2012 18:55:11 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:53 +0000
Message-ID: <1330109703-6536-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/15] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bffa03..19ef1de 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -312,7 +312,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index cd819c8..9f9f91d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -399,13 +399,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..9fd67b4 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -95,6 +95,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 702b208..394a128 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c58e9f3..2018153 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1422,7 +1422,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1709,11 +1709,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10IV-0001C5-F3; Fri, 24 Feb 2012 18:55: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 1S10IT-0001BJ-N8
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23729 invoked from network); 24 Feb 2012 18:54:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IS-00023T-0X; Fri, 24 Feb 2012 18:55:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IR-0001if-Vv;
	Fri, 24 Feb 2012 18:55:11 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:53 +0000
Message-ID: <1330109703-6536-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/15] libxl: abolish libxl_ctx_postfork
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

libxl's task has become too complicated (particularly in the presence
of both forking and multithreading) to support reuse of the same
libxl_ctx after fork.

So abolish libxl_ctx_fork.  xl instead simply initialises a new
libxl_ctx.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.h       |    1 -
 tools/libxl/libxl_utils.c |    7 -------
 tools/libxl/xl.c          |    8 ++++++++
 tools/libxl/xl.h          |    1 +
 tools/libxl/xl_cmdimpl.c  |    8 ++------
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 1bffa03..19ef1de 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -312,7 +312,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags /* none currently defined */,
                     xentoollog_logger *lg);
 int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */);
-int libxl_ctx_postfork(libxl_ctx *ctx);
 
 /* domain related functions */
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index cd819c8..9f9f91d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -399,13 +399,6 @@ READ_WRITE_EXACTLY(read, 1, /* */)
 READ_WRITE_EXACTLY(write, 0, const)
 
 
-int libxl_ctx_postfork(libxl_ctx *ctx) {
-    if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh);
-    ctx->xsh = xs_daemon_open();
-    if (!ctx->xsh) return ERROR_FAIL;
-    return 0;
-}
-
 pid_t libxl_fork(libxl_ctx *ctx)
 {
     pid_t pid;
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index df9b1e7..9fd67b4 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -95,6 +95,14 @@ static void parse_global_config(const char *configfile,
     xlu_cfg_destroy(config);
 }
 
+void postfork(void)
+{
+    if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
+        fprintf(stderr, "cannot reinit xl context after fork\n");
+        exit(-1);
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 702b208..394a128 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s);
 
 extern libxl_ctx *ctx;
 extern xentoollog_logger_stdiostream *logger;
+void postfork(void);
 
 /* global options */
 extern int autoballoon;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c58e9f3..2018153 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1422,7 +1422,7 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     } else if (*pid > 0)
         return 0;
 
-    libxl_ctx_postfork(ctx);
+    postfork();
 
     sleep(1);
     libxl_primary_console_exec(ctx, domid);
@@ -1709,11 +1709,7 @@ start:
             goto out;
         }
 
-        rc = libxl_ctx_postfork(ctx);
-        if (rc) {
-            LOG("failed to reinitialise context after fork");
-            exit(-1);
-        }
+        postfork();
 
         if (asprintf(&name, "xl-%s", d_config.c_info.name) < 0) {
             LOG("Failed to allocate memory in asprintf");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10IQ-0001Ao-SU; Fri, 24 Feb 2012 18:55:10 +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 1S10IP-0001Ae-4P
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23565 invoked from network); 24 Feb 2012 18:54:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18: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.213.0; Fri, 24 Feb 2012 18:55:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IL-00023A-EY; Fri, 24 Feb 2012 18:55:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IL-0001iC-Cv;
	Fri, 24 Feb 2012 18:55:05 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:48 +0000
Message-ID: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once again, I have not executed the code in this series!

These three are intended to be bugfixes to sort out
the deadlock problem that Roger Pau Monne reported:
 01/15 libxl: ao: allow immediate completion
 02/15 libxl: fix hang due to libxl__initiate_device_remove

These are other bugfixes:
 03/15 libxl: Fix eventloop_iteration over-locking
 04/15 libxl: Fix leak of ctx->lock
 05/15 libxl: abolish libxl_ctx_postfork
 06/15 tools: Correct PTHREAD options in config/StdGNU.mk
 07/15 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 08/15 libxl: Crash (more sensibly) on malloc failure

These are handy new bits for internal libxl users:
 09/15 libxl: Make libxl__zalloc et al tolerate a NULL gc
 10/15 libxl: Introduce some convenience macros
 11/15 libxl: Protect fds with CLOEXEC even with forking threads
 12/15 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 14/15 libxl: Provide libxl_string_list_length
 15/15 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

This is the new child-handling machinery:
 13/15 libxl: event API: new facilities for waiting for subprocesses

There are not any users for much of this code in this series.  I have
a half-written rework of libxl_bootloader.c to make it event-driven,
but it's not suitable for review at this stage.  It doesn't even
compile.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10IQ-0001Ao-SU; Fri, 24 Feb 2012 18:55:10 +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 1S10IP-0001Ae-4P
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23565 invoked from network); 24 Feb 2012 18:54:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18: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.213.0; Fri, 24 Feb 2012 18:55:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IL-00023A-EY; Fri, 24 Feb 2012 18:55:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IL-0001iC-Cv;
	Fri, 24 Feb 2012 18:55:05 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:48 +0000
Message-ID: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once again, I have not executed the code in this series!

These three are intended to be bugfixes to sort out
the deadlock problem that Roger Pau Monne reported:
 01/15 libxl: ao: allow immediate completion
 02/15 libxl: fix hang due to libxl__initiate_device_remove

These are other bugfixes:
 03/15 libxl: Fix eventloop_iteration over-locking
 04/15 libxl: Fix leak of ctx->lock
 05/15 libxl: abolish libxl_ctx_postfork
 06/15 tools: Correct PTHREAD options in config/StdGNU.mk
 07/15 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 08/15 libxl: Crash (more sensibly) on malloc failure

These are handy new bits for internal libxl users:
 09/15 libxl: Make libxl__zalloc et al tolerate a NULL gc
 10/15 libxl: Introduce some convenience macros
 11/15 libxl: Protect fds with CLOEXEC even with forking threads
 12/15 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 14/15 libxl: Provide libxl_string_list_length
 15/15 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

This is the new child-handling machinery:
 13/15 libxl: event API: new facilities for waiting for subprocesses

There are not any users for much of this code in this series.  I have
a half-written rework of libxl_bootloader.c to make it event-driven,
but it's not suitable for review at this stage.  It doesn't even
compile.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10Ic-0001GM-6G; Fri, 24 Feb 2012 18:55:22 +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 1S10Ia-0001EW-80
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23845 invoked from network); 24 Feb 2012 18:54:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927882"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18: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.213.0; Fri, 24 Feb 2012 18:55:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IX-00023i-BT; Fri, 24 Feb 2012 18:55:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IX-0001j0-Ak;
	Fri, 24 Feb 2012 18:55:17 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:57 +0000
Message-ID: <1330109703-6536-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/15] libxl: Make libxl__zalloc et al tolerate
	a NULL gc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Arrange that if we pass NULL as a gc, we simply don't register the
pointer.  This instantly gives us non-gc'ing but error-checking
versions of malloc, realloc, vasprintf, etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |    5 ++++-
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index dfa2153..de7c3a8 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -29,6 +29,9 @@ void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
+    if (!gc)
+        return;
+
     if (!ptr)
         return;
 
@@ -96,7 +99,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr) {
+    } else if (new_ptr != ptr && gc != NULL) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ab2898e..33b588a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -371,30 +371,35 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  *
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
+ *
+ * However, where the argument is stated to be "gc_opt", NULL may be
+ * passed instead, in which case no garbage collection will occur; the
+ * pointer must later be freed with free().  This is for memory
+ * allocations of types (b) and (c).
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10Ic-0001GM-6G; Fri, 24 Feb 2012 18:55:22 +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 1S10Ia-0001EW-80
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23845 invoked from network); 24 Feb 2012 18:54:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927882"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18: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.213.0; Fri, 24 Feb 2012 18:55:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IX-00023i-BT; Fri, 24 Feb 2012 18:55:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IX-0001j0-Ak;
	Fri, 24 Feb 2012 18:55:17 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:57 +0000
Message-ID: <1330109703-6536-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/15] libxl: Make libxl__zalloc et al tolerate
	a NULL gc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Arrange that if we pass NULL as a gc, we simply don't register the
pointer.  This instantly gives us non-gc'ing but error-checking
versions of malloc, realloc, vasprintf, etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |    5 ++++-
 tools/libxl/libxl_internal.h |   21 +++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index dfa2153..de7c3a8 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -29,6 +29,9 @@ void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
 
+    if (!gc)
+        return;
+
     if (!ptr)
         return;
 
@@ -96,7 +99,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
-    } else if (new_ptr != ptr) {
+    } else if (new_ptr != ptr && gc != NULL) {
         for (i = 0; i < gc->alloc_maxsize; i++) {
             if (gc->alloc_ptrs[i] == ptr) {
                 gc->alloc_ptrs[i] = new_ptr;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ab2898e..33b588a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -371,30 +371,35 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  *
  * All pointers returned by these functions are registered for garbage
  * collection on exit from the outermost libxl callframe.
+ *
+ * However, where the argument is stated to be "gc_opt", NULL may be
+ * passed instead, in which case no garbage collection will occur; the
+ * pointer must later be freed with free().  This is for memory
+ * allocations of types (b) and (c).
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-_hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
+_hidden void *libxl__zalloc(libxl__gc *gc_opt, int bytes);
 /* allocate and zero memory for an array of @nmemb members of @size each.
  * (similar to a gc'd calloc(3)). */
-_hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
+_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t size);
 /* change the size of the memory block pointed to by @ptr to @new_size bytes.
  * unlike other allocation functions here any additional space between the
  * oldsize and @new_size is not initialised (similar to a gc'd realloc(3)). */
-_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
+_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t new_size);
 /* print @fmt into an allocated string large enoughto contain the result.
  * (similar to gc'd asprintf(3)). */
-_hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
+_hidden char *libxl__sprintf(libxl__gc *gc_opt, const char *fmt, ...) PRINTF_ATTRIBUTE(2, 3);
 /* duplicate the string @c (similar to a gc'd strdup(3)). */
-_hidden char *libxl__strdup(libxl__gc *gc, const char *c);
+_hidden char *libxl__strdup(libxl__gc *gc_opt, const char *c);
 /* duplicate at most @n bytes of string @c (similar to a gc'd strndup(3)). */
-_hidden char *libxl__strndup(libxl__gc *gc, const char *c, size_t n);
+_hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n);
 /* strip the last path component from @s and return as a newly allocated
  * string. (similar to a gc'd dirname(3)). */
-_hidden char *libxl__dirname(libxl__gc *gc, const char *s);
+_hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s);
 
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10Ie-0001I0-KW; Fri, 24 Feb 2012 18:55:24 +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 1S10Ic-0001E9-Kl
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23817 invoked from network); 24 Feb 2012 18:54:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IV-00023f-SG; Fri, 24 Feb 2012 18:55:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IV-0001iw-RW;
	Fri, 24 Feb 2012 18:55:15 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:56 +0000
Message-ID: <1330109703-6536-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/15] libxl: Crash (more sensibly) on malloc
	failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Formally change the libxl memory allocation failure policy to "crash".

Previously we had a very uneven approach; much code assumed that
libxl__sprintf (for example) would never return NULL, but some code
was written more carefully.

We think it is unlikely that we will be able to make the library
actually robust against allocation failure (since that would be an
awful lot of never-tested error paths) and few calling environments
will be able to cope anyway.  So, instead, adopt the alternative
approach: provide allocation functions which never return null, but
will crash the whole process instead.

Consequently,
 - New noreturn function libxl__alloc_failed which may be used for
   printing a vaguely-useful error message, rather than simply
   dereferencing a null pointer.
 - libxl__ptr_add now returns void as it crashes on failure.
 - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
   libxl__alloc_failed.  So all the code that uses these can no longer
   dereference null on malloc failure.

While we're at it, make libxl__ptr_add use realloc rather than
emulating it with calloc and free, and make it grow the array
exponentially rather than linearly.

Things left to do:
 - Provide versions of malloc, realloc and free which do the
   checking but which do not enroll the pointer in the gc.
 - Remove a lot of now-spurious error handling.
 - Remove the ERROR_NOMEM error code.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |    4 ++
 tools/libxl/libxl_internal.c |   79 ++++++++++++++++++------------------------
 tools/libxl/libxl_internal.h |    5 ++-
 3 files changed, 42 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 19ef1de..65961d2 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -123,6 +123,10 @@
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
+ *
+ * Memory allocation failures are not handled gracefully.  If malloc
+ * (or realloc) fails, libxl will cause the entire process to print
+ * a message to stderr and exit with status 255.
  */
 #ifndef LIBXL_H
 #define LIBXL_H
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..dfa2153 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -17,40 +17,40 @@
 
 #include "libxl_internal.h"
 
-int libxl__error_set(libxl__gc *gc, int code)
-{
-    return 0;
+void libxl__alloc_failed(const char *func, size_t nmemb, size_t size) {
+    fprintf(stderr,
+            "libxl: FATAL ERROR: memory allocation failure (%s, %lu x %lu)\n",
+            func, (unsigned long)nmemb, (unsigned long)size);
+    fflush(stderr);
+    _exit(-1);
 }
 
-int libxl__ptr_add(libxl__gc *gc, void *ptr)
+void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
-    void **re;
 
     if (!ptr)
-        return 0;
+        return;
 
     /* fast case: we have space in the array for storing the pointer */
     for (i = 0; i < gc->alloc_maxsize; i++) {
         if (!gc->alloc_ptrs[i]) {
             gc->alloc_ptrs[i] = ptr;
-            return 0;
+            return;
         }
     }
-    /* realloc alloc_ptrs manually with calloc/free/replace */
-    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
-    if (!re)
-        return -1;
-    for (i = 0; i < gc->alloc_maxsize; i++)
-        re[i] = gc->alloc_ptrs[i];
-    /* assign the next pointer */
-    re[i] = ptr;
+    int new_maxsize = gc->alloc_maxsize * 2 + 25;
+    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
+    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
+    if (!gc->alloc_ptrs)
+        libxl__alloc_failed(__func__, sizeof(void*), new_maxsize);
 
-    /* replace the old alloc_ptr */
-    free(gc->alloc_ptrs);
-    gc->alloc_ptrs = re;
-    gc->alloc_maxsize += 25;
-    return 0;
+    gc->alloc_ptrs[gc->alloc_maxsize++] = ptr;
+
+    while (gc->alloc_maxsize < new_maxsize)
+        gc->alloc_ptrs[gc->alloc_maxsize++] = 0;
+
+    return;
 }
 
 void libxl__free_all(libxl__gc *gc)
@@ -71,10 +71,7 @@ void libxl__free_all(libxl__gc *gc)
 void *libxl__zalloc(libxl__gc *gc, int bytes)
 {
     void *ptr = calloc(bytes, 1);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(__func__, bytes, 1);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -83,10 +80,7 @@ void *libxl__zalloc(libxl__gc *gc, int bytes)
 void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size)
 {
     void *ptr = calloc(nmemb, size);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(__func__, nmemb, size);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -97,9 +91,8 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
     void *new_ptr = realloc(ptr, new_size);
     int i = 0;
 
-    if (new_ptr == NULL && new_size != 0) {
-        return NULL;
-    }
+    if (new_ptr == NULL && new_size != 0)
+        libxl__alloc_failed(__func__, new_size, 1);
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
@@ -112,7 +105,6 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
         }
     }
 
-
     return new_ptr;
 }
 
@@ -126,16 +118,13 @@ char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
     ret = vsnprintf(NULL, 0, fmt, ap);
     va_end(ap);
 
-    if (ret < 0) {
-        return NULL;
-    }
+    assert(ret >= 0);
 
     s = libxl__zalloc(gc, ret + 1);
-    if (s) {
-        va_start(ap, fmt);
-        ret = vsnprintf(s, ret + 1, fmt, ap);
-        va_end(ap);
-    }
+    va_start(ap, fmt);
+    ret = vsnprintf(s, ret + 1, fmt, ap);
+    va_end(ap);
+
     return s;
 }
 
@@ -143,8 +132,9 @@ char *libxl__strdup(libxl__gc *gc, const char *c)
 {
     char *s = strdup(c);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(__func__, strlen(c), 1);
+
+    libxl__ptr_add(gc, s);
 
     return s;
 }
@@ -153,8 +143,7 @@ char *libxl__strndup(libxl__gc *gc, const char *c, size_t n)
 {
     char *s = strndup(c, n);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(__func__, n, 1);
 
     return s;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ac892ae..ab2898e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -116,6 +116,9 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
+void libxl__alloc_failed(const char *func, size_t nmemb, size_t size)
+    __attribute__((noreturn));
+
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
@@ -370,7 +373,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * collection on exit from the outermost libxl callframe.
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10Ie-0001I0-KW; Fri, 24 Feb 2012 18:55:24 +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 1S10Ic-0001E9-Kl
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23817 invoked from network); 24 Feb 2012 18:54:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:24 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IV-00023f-SG; Fri, 24 Feb 2012 18:55:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IV-0001iw-RW;
	Fri, 24 Feb 2012 18:55:15 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:56 +0000
Message-ID: <1330109703-6536-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/15] libxl: Crash (more sensibly) on malloc
	failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Formally change the libxl memory allocation failure policy to "crash".

Previously we had a very uneven approach; much code assumed that
libxl__sprintf (for example) would never return NULL, but some code
was written more carefully.

We think it is unlikely that we will be able to make the library
actually robust against allocation failure (since that would be an
awful lot of never-tested error paths) and few calling environments
will be able to cope anyway.  So, instead, adopt the alternative
approach: provide allocation functions which never return null, but
will crash the whole process instead.

Consequently,
 - New noreturn function libxl__alloc_failed which may be used for
   printing a vaguely-useful error message, rather than simply
   dereferencing a null pointer.
 - libxl__ptr_add now returns void as it crashes on failure.
 - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
   libxl__alloc_failed.  So all the code that uses these can no longer
   dereference null on malloc failure.

While we're at it, make libxl__ptr_add use realloc rather than
emulating it with calloc and free, and make it grow the array
exponentially rather than linearly.

Things left to do:
 - Provide versions of malloc, realloc and free which do the
   checking but which do not enroll the pointer in the gc.
 - Remove a lot of now-spurious error handling.
 - Remove the ERROR_NOMEM error code.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |    4 ++
 tools/libxl/libxl_internal.c |   79 ++++++++++++++++++------------------------
 tools/libxl/libxl_internal.h |    5 ++-
 3 files changed, 42 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 19ef1de..65961d2 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -123,6 +123,10 @@
  * No temporary objects allocated from the pool may be explicitly freed.
  * Therefore public functions which initialize a libxl__gc MUST call
  * libxl__free_all() before returning.
+ *
+ * Memory allocation failures are not handled gracefully.  If malloc
+ * (or realloc) fails, libxl will cause the entire process to print
+ * a message to stderr and exit with status 255.
  */
 #ifndef LIBXL_H
 #define LIBXL_H
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 12c32dc..dfa2153 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -17,40 +17,40 @@
 
 #include "libxl_internal.h"
 
-int libxl__error_set(libxl__gc *gc, int code)
-{
-    return 0;
+void libxl__alloc_failed(const char *func, size_t nmemb, size_t size) {
+    fprintf(stderr,
+            "libxl: FATAL ERROR: memory allocation failure (%s, %lu x %lu)\n",
+            func, (unsigned long)nmemb, (unsigned long)size);
+    fflush(stderr);
+    _exit(-1);
 }
 
-int libxl__ptr_add(libxl__gc *gc, void *ptr)
+void libxl__ptr_add(libxl__gc *gc, void *ptr)
 {
     int i;
-    void **re;
 
     if (!ptr)
-        return 0;
+        return;
 
     /* fast case: we have space in the array for storing the pointer */
     for (i = 0; i < gc->alloc_maxsize; i++) {
         if (!gc->alloc_ptrs[i]) {
             gc->alloc_ptrs[i] = ptr;
-            return 0;
+            return;
         }
     }
-    /* realloc alloc_ptrs manually with calloc/free/replace */
-    re = calloc(gc->alloc_maxsize + 25, sizeof(void *));
-    if (!re)
-        return -1;
-    for (i = 0; i < gc->alloc_maxsize; i++)
-        re[i] = gc->alloc_ptrs[i];
-    /* assign the next pointer */
-    re[i] = ptr;
+    int new_maxsize = gc->alloc_maxsize * 2 + 25;
+    assert(new_maxsize < INT_MAX / sizeof(void*) / 2);
+    gc->alloc_ptrs = realloc(gc->alloc_ptrs, new_maxsize * sizeof(void *));
+    if (!gc->alloc_ptrs)
+        libxl__alloc_failed(__func__, sizeof(void*), new_maxsize);
 
-    /* replace the old alloc_ptr */
-    free(gc->alloc_ptrs);
-    gc->alloc_ptrs = re;
-    gc->alloc_maxsize += 25;
-    return 0;
+    gc->alloc_ptrs[gc->alloc_maxsize++] = ptr;
+
+    while (gc->alloc_maxsize < new_maxsize)
+        gc->alloc_ptrs[gc->alloc_maxsize++] = 0;
+
+    return;
 }
 
 void libxl__free_all(libxl__gc *gc)
@@ -71,10 +71,7 @@ void libxl__free_all(libxl__gc *gc)
 void *libxl__zalloc(libxl__gc *gc, int bytes)
 {
     void *ptr = calloc(bytes, 1);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(__func__, bytes, 1);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -83,10 +80,7 @@ void *libxl__zalloc(libxl__gc *gc, int bytes)
 void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size)
 {
     void *ptr = calloc(nmemb, size);
-    if (!ptr) {
-        libxl__error_set(gc, ENOMEM);
-        return NULL;
-    }
+    if (!ptr) libxl__alloc_failed(__func__, nmemb, size);
 
     libxl__ptr_add(gc, ptr);
     return ptr;
@@ -97,9 +91,8 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
     void *new_ptr = realloc(ptr, new_size);
     int i = 0;
 
-    if (new_ptr == NULL && new_size != 0) {
-        return NULL;
-    }
+    if (new_ptr == NULL && new_size != 0)
+        libxl__alloc_failed(__func__, new_size, 1);
 
     if (ptr == NULL) {
         libxl__ptr_add(gc, new_ptr);
@@ -112,7 +105,6 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
         }
     }
 
-
     return new_ptr;
 }
 
@@ -126,16 +118,13 @@ char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
     ret = vsnprintf(NULL, 0, fmt, ap);
     va_end(ap);
 
-    if (ret < 0) {
-        return NULL;
-    }
+    assert(ret >= 0);
 
     s = libxl__zalloc(gc, ret + 1);
-    if (s) {
-        va_start(ap, fmt);
-        ret = vsnprintf(s, ret + 1, fmt, ap);
-        va_end(ap);
-    }
+    va_start(ap, fmt);
+    ret = vsnprintf(s, ret + 1, fmt, ap);
+    va_end(ap);
+
     return s;
 }
 
@@ -143,8 +132,9 @@ char *libxl__strdup(libxl__gc *gc, const char *c)
 {
     char *s = strdup(c);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(__func__, strlen(c), 1);
+
+    libxl__ptr_add(gc, s);
 
     return s;
 }
@@ -153,8 +143,7 @@ char *libxl__strndup(libxl__gc *gc, const char *c, size_t n)
 {
     char *s = strndup(c, n);
 
-    if (s)
-        libxl__ptr_add(gc, s);
+    if (!s) libxl__alloc_failed(__func__, n, 1);
 
     return s;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ac892ae..ab2898e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -116,6 +116,9 @@ typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
 typedef struct libxl__ao libxl__ao;
 
+void libxl__alloc_failed(const char *func, size_t nmemb, size_t size)
+    __attribute__((noreturn));
+
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
                                    int fd, short events, short revents);
@@ -370,7 +373,7 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  * collection on exit from the outermost libxl callframe.
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
-_hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
+_hidden void libxl__ptr_add(libxl__gc *gc, void *ptr);
 /* if this is the outermost libxl callframe then free all pointers in @gc */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10IT-0001BR-LC; Fri, 24 Feb 2012 18:55:13 +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 1S10IS-0001Af-61
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23570 invoked from network); 24 Feb 2012 18:54:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18: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.213.0; Fri, 24 Feb 2012 18:55:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IM-00023G-Rx; Fri, 24 Feb 2012 18:55:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IM-0001iO-RH;
	Fri, 24 Feb 2012 18:55:06 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:49 +0000
Message-ID: <1330109703-6536-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/15] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Also fix the wording in the libxl_internal.h comment forbidding use of
ao_how-taking functions from within libxl.  (There are sadly currently
some such functions.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..c89add8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,9 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->constructing);
     assert(ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 46e131a..2dc820c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -337,7 +337,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1186,7 +1186,11 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * operation ("ao") machinery.  The function should take a parameter
  * const libxl_asyncop_how *ao_how and must start with a call to
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * outside libxl, because they can cause reentrancy callbacks.
+ * inside libxl, because they can cause reentrancy callbacks.
+ *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
  *
  * Lifecycle of an ao:
  *
@@ -1217,8 +1221,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1232,12 +1235,14 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
     AO_GC;
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1246,6 +1251,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10IT-0001BR-LC; Fri, 24 Feb 2012 18:55:13 +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 1S10IS-0001Af-61
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23570 invoked from network); 24 Feb 2012 18:54:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18: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.213.0; Fri, 24 Feb 2012 18:55:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IM-00023G-Rx; Fri, 24 Feb 2012 18:55:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IM-0001iO-RH;
	Fri, 24 Feb 2012 18:55:06 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:49 +0000
Message-ID: <1330109703-6536-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/15] libxl: ao: allow immediate completion
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make it possible to complete an ao during its initating function.

Previously this was not generally possible because initiators did not
have an egc.  But there is no reason why an ao initiator should not
have an egc, so make the standard macros provide one.

Change the internal documentation comments accordingly.  (This change,
which means that an initiator function may call a completion callback
directly, is already consistent with the documented external API.)

We also invent of a new state flag "constructing" which indicates
whether we are between ao__create and ao__inprogress.  This is a
slightly optimisation which allows ao_complete to not bother poking
the wakeup pipe, since the logic in ao__inprogress will not run the
event loop if the ao is complete on entry.

Also fix the wording in the libxl_internal.h comment forbidding use of
ao_how-taking functions from within libxl.  (There are sadly currently
some such functions.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |    7 ++++++-
 tools/libxl/libxl_internal.h |   14 ++++++++++----
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 271949a..c89add8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1225,7 +1225,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
 
     if (ao->poller) {
         assert(ao->in_initiator);
-        libxl__poller_wakeup(egc, ao->poller);
+        if (!ao->constructing)
+            /* don't bother with this if we're not in the event loop */
+            libxl__poller_wakeup(egc, ao->poller);
     } else if (ao->how.callback) {
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
@@ -1251,6 +1253,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
     if (!ao) goto out;
 
     ao->magic = LIBXL__AO_MAGIC;
+    ao->constructing = 1;
     ao->in_initiator = 1;
     ao->poller = 0;
     ao->domid = domid;
@@ -1275,7 +1278,9 @@ int libxl__ao_inprogress(libxl__ao *ao)
     int rc;
 
     assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->constructing);
     assert(ao->in_initiator);
+    ao->constructing = 0;
 
     if (ao->poller) {
         /* Caller wants it done synchronously. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 46e131a..2dc820c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -337,7 +337,7 @@ struct libxl__egc {
 
 struct libxl__ao {
     uint32_t magic;
-    unsigned in_initiator:1, complete:1, notified:1;
+    unsigned constructing:1, in_initiator:1, complete:1, notified:1;
     int rc;
     libxl__gc gc;
     libxl_asyncop_how how;
@@ -1186,7 +1186,11 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  * operation ("ao") machinery.  The function should take a parameter
  * const libxl_asyncop_how *ao_how and must start with a call to
  * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
- * outside libxl, because they can cause reentrancy callbacks.
+ * inside libxl, because they can cause reentrancy callbacks.
+ *
+ * For the same reason functions taking an ao_how may make themselves
+ * an egc with EGC_INIT (and they will generally want to, to be able
+ * to immediately complete an ao during its setup).
  *
  * Lifecycle of an ao:
  *
@@ -1217,8 +1221,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  *   directly or indirectly, should call libxl__ao_complete (with the
  *   ctx locked, as it will generally already be in any event callback
  *   function).  This must happen exactly once for each ao (and not if
- *   the ao has been destroyed, obviously), and it may not happen
- *   until libxl__ao_inprogress has been called on the ao.
+ *   the ao has been destroyed, obviously).
  *
  * - Note that during callback functions, two gcs are available:
  *    - The one in egc, whose lifetime is only this callback
@@ -1232,12 +1235,14 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
     libxl__ctx_lock(ctx);                                       \
     libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
     if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);              \
     AO_GC;
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
         int ao__rc = libxl__ao_inprogress(ao);                  \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 
@@ -1246,6 +1251,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
         assert(rc);                                             \
         libxl__ao_abort(ao);                                    \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        EGC_FREE;                                               \
         (rc);                                                   \
     })
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10If-0001IJ-1I; Fri, 24 Feb 2012 18:55: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 1S10Ie-0001HE-0s
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23877 invoked from network); 24 Feb 2012 18:54:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IZ-00023l-0h; Fri, 24 Feb 2012 18:55:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IY-0001j4-WA;
	Fri, 24 Feb 2012 18:55:18 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:58 +0000
Message-ID: <1330109703-6536-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/15] libxl: Introduce some convenience macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce:
   <type> *GCNEW(<type> *var);
   <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
   <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
   char *GCSPRINTF(const char *fmt, ...);
   void LOG(<xtl_level_suffix>, const char *fmt, ...);
   void LOGE(<xtl_level_suffix>, const char *fmt, ...);
   void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
all of which expect, in the calling context,
   libxl__gc *gc;

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   72 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 33b588a..b2f9092 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1323,6 +1323,78 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
+/* Allocation macros all of which use the gc. */
+
+#define ARRAY_SIZE_OK(ptr, nmemb) ((nmemb) < INT_MAX / (sizeof(*(ptr)) * 2))
+
+/*
+ * Expression statement  <type> *GCNEW(<type> *var);
+ * Uses                  libxl__gc *gc;
+ *
+ * Allocates a new object of type <type> from the gc and zeroes it
+ * with memset.  Sets var to point to the new object or zero (setting
+ * errno).  Returns the new value of var.
+ */
+#define GCNEW(var)                                      \
+    (((var) = libxl__zalloc((gc),sizeof(*(var)))))
+
+/*
+ * Expression statement  <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Like GCNEW but allocates an array of nmemb elements, as if from
+ * calloc.  Does check for integer overflow due to large nmemb.  If
+ * nmemb is 0 may succeed by returning 0.
+ */
+#define GCNEW_ARRAY(var, nmemb)                                 \
+    ((var) = libxl__calloc((gc), (nmemb), sizeof(*(var))))
+    
+/*
+ * Expression statement  <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Reallocates the array var to be of size nmemb elements.  Updates
+ * var and returns the new value of var.  Does check for integer
+ * overflow due to large nmemb.
+ *
+ * Do not pass nmemb==0.  old may be 0 on entry.
+ */
+#define GCREALLOC_ARRAY(var, nmemb)                                     \
+    (assert(nmemb > 0),                                                 \
+     assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+
+
+/*
+ * Expression            char *GCSPRINTF(const char *fmt, ...);
+ * Uses                  libxl__gc *gc;
+ *
+ * Trivial convenience wrapper for libxl__sprintf.
+ */
+#define GCSPRINTF(fmt, ...) (libxl__sprintf((gc), (fmt), __VA_ARGS__)
+
+
+/*
+ * Expression statements
+ *    void LOG(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGE(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
+ * Use
+ *    libxl__gc *gc;
+ *
+ * Trivial convenience wrappers for LIBXL__LOG, LIBXL__LOG_ERRNO and
+ * LIBXL__LOG_ERRNOVAL, respectively (and thus for libxl__log).
+ *
+ * XTL_<xtl_level_suffix> should exist and be an xentoollog.h log level
+ * So <xtl_level_suffix> should be one of
+ *   DEBUG VERBOSE DETAIL PROGRESS INFO NOTICE WARN ERROR ERROR CRITICAL
+ * Of these, most of libxl uses
+ *   DEBUG INFO WARN ERROR
+ */
+#define LOG(l,f, ...)     LIBXL__LOG(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGE(l,f, ...)    LIBXL__LOG_ERRNO(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGEV(l,e,f, ...) LIBXL__LOG_ERRNOVAL(CTX,XTL_##l,(e),(f),##__VA_ARGS__)
+
 
 /* Locking functions.  See comment for "lock" member of libxl__ctx. */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18: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 1S10If-0001IJ-1I; Fri, 24 Feb 2012 18:55: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 1S10Ie-0001HE-0s
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23877 invoked from network); 24 Feb 2012 18:54:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10IZ-00023l-0h; Fri, 24 Feb 2012 18:55:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10IY-0001j4-WA;
	Fri, 24 Feb 2012 18:55:18 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:54:58 +0000
Message-ID: <1330109703-6536-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/15] libxl: Introduce some convenience macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce:
   <type> *GCNEW(<type> *var);
   <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
   <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
   char *GCSPRINTF(const char *fmt, ...);
   void LOG(<xtl_level_suffix>, const char *fmt, ...);
   void LOGE(<xtl_level_suffix>, const char *fmt, ...);
   void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
all of which expect, in the calling context,
   libxl__gc *gc;

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   72 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 33b588a..b2f9092 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1323,6 +1323,78 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 #define GC_FREE       libxl__free_all(gc)
 #define CTX           libxl__gc_owner(gc)
 
+/* Allocation macros all of which use the gc. */
+
+#define ARRAY_SIZE_OK(ptr, nmemb) ((nmemb) < INT_MAX / (sizeof(*(ptr)) * 2))
+
+/*
+ * Expression statement  <type> *GCNEW(<type> *var);
+ * Uses                  libxl__gc *gc;
+ *
+ * Allocates a new object of type <type> from the gc and zeroes it
+ * with memset.  Sets var to point to the new object or zero (setting
+ * errno).  Returns the new value of var.
+ */
+#define GCNEW(var)                                      \
+    (((var) = libxl__zalloc((gc),sizeof(*(var)))))
+
+/*
+ * Expression statement  <type> *GCNEW_ARRAY(<type> *var, ssize_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Like GCNEW but allocates an array of nmemb elements, as if from
+ * calloc.  Does check for integer overflow due to large nmemb.  If
+ * nmemb is 0 may succeed by returning 0.
+ */
+#define GCNEW_ARRAY(var, nmemb)                                 \
+    ((var) = libxl__calloc((gc), (nmemb), sizeof(*(var))))
+    
+/*
+ * Expression statement  <type> *GCREALLOC_ARRAY(<type> *var, size_t nmemb);
+ * Uses                  libxl__gc *gc;
+ *
+ * Reallocates the array var to be of size nmemb elements.  Updates
+ * var and returns the new value of var.  Does check for integer
+ * overflow due to large nmemb.
+ *
+ * Do not pass nmemb==0.  old may be 0 on entry.
+ */
+#define GCREALLOC_ARRAY(var, nmemb)                                     \
+    (assert(nmemb > 0),                                                 \
+     assert(ARRAY_SIZE_OK((var), (nmemb))),                             \
+     (var) = libxl__realloc((gc), (var), (nmemb)*sizeof(*(var)))))
+
+
+/*
+ * Expression            char *GCSPRINTF(const char *fmt, ...);
+ * Uses                  libxl__gc *gc;
+ *
+ * Trivial convenience wrapper for libxl__sprintf.
+ */
+#define GCSPRINTF(fmt, ...) (libxl__sprintf((gc), (fmt), __VA_ARGS__)
+
+
+/*
+ * Expression statements
+ *    void LOG(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGE(<xtl_level_suffix>, const char *fmt, ...);
+ *    void LOGEV(<xtl_level_suffix>, int errnoval, const char *fmt, ...);
+ * Use
+ *    libxl__gc *gc;
+ *
+ * Trivial convenience wrappers for LIBXL__LOG, LIBXL__LOG_ERRNO and
+ * LIBXL__LOG_ERRNOVAL, respectively (and thus for libxl__log).
+ *
+ * XTL_<xtl_level_suffix> should exist and be an xentoollog.h log level
+ * So <xtl_level_suffix> should be one of
+ *   DEBUG VERBOSE DETAIL PROGRESS INFO NOTICE WARN ERROR ERROR CRITICAL
+ * Of these, most of libxl uses
+ *   DEBUG INFO WARN ERROR
+ */
+#define LOG(l,f, ...)     LIBXL__LOG(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGE(l,f, ...)    LIBXL__LOG_ERRNO(CTX,XTL_##l,(f),##__VA_ARGS__)
+#define LOGEV(l,e,f, ...) LIBXL__LOG_ERRNOVAL(CTX,XTL_##l,(e),(f),##__VA_ARGS__)
+
 
 /* Locking functions.  See comment for "lock" member of libxl__ctx. */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ip-0001Sx-26; Fri, 24 Feb 2012 18:55:35 +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 1S10Im-0001O3-Pk
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!15
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24034 invoked from network); 24 Feb 2012 18:54:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ie-00023y-W0; Fri, 24 Feb 2012 18:55:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ie-0001jN-V9;
	Fri, 24 Feb 2012 18:55:24 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:55:02 +0000
Message-ID: <1330109703-6536-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/15] libxl: Provide libxl_string_list_length
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    8 ++++++++
 tools/libxl/libxl.h |    1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 06ac064..42bc7fc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -195,6 +195,14 @@ void libxl_string_list_dispose(libxl_string_list *psl)
     free(sl);
 }
 
+int libxl_string_list_length(libxl_string_list *psl)
+{
+    if (!psl) return 0;
+    int i = 0;
+    while (*psl++) i++;
+    return i;
+}
+
 void libxl_key_value_list_dispose(libxl_key_value_list *pkvl)
 {
     int i;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 65961d2..dcfbd32 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -154,6 +154,7 @@ typedef uint8_t libxl_mac[6];
 
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
+int libxl_string_list_length(libxl_string_list *sl);
 
 typedef char **libxl_key_value_list;
 void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ip-0001Sx-26; Fri, 24 Feb 2012 18:55:35 +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 1S10Im-0001O3-Pk
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!15
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24034 invoked from network); 24 Feb 2012 18:54:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ie-00023y-W0; Fri, 24 Feb 2012 18:55:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ie-0001jN-V9;
	Fri, 24 Feb 2012 18:55:24 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:55:02 +0000
Message-ID: <1330109703-6536-15-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/15] libxl: Provide libxl_string_list_length
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |    8 ++++++++
 tools/libxl/libxl.h |    1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 06ac064..42bc7fc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -195,6 +195,14 @@ void libxl_string_list_dispose(libxl_string_list *psl)
     free(sl);
 }
 
+int libxl_string_list_length(libxl_string_list *psl)
+{
+    if (!psl) return 0;
+    int i = 0;
+    while (*psl++) i++;
+    return i;
+}
+
 void libxl_key_value_list_dispose(libxl_key_value_list *pkvl)
 {
     int i;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 65961d2..dcfbd32 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -154,6 +154,7 @@ typedef uint8_t libxl_mac[6];
 
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
+int libxl_string_list_length(libxl_string_list *sl);
 
 typedef char **libxl_key_value_list;
 void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Il-0001Q9-Lm; Fri, 24 Feb 2012 18:55: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 1S10Ij-0001Jc-NH
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23917 invoked from network); 24 Feb 2012 18:54:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ia-00023o-Ja; Fri, 24 Feb 2012 18:55:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ia-0001j8-Il;
	Fri, 24 Feb 2012 18:55:20 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:59 +0000
Message-ID: <1330109703-6536-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/15] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywhere in libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   12 ++++
 tools/libxl/libxl_fork.c     |  146 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 228 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 347f192..a041294 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -57,7 +57,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fd890cf..716163a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f889115..f8bc22f 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -369,6 +369,18 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl__postfork_child_noexec in the child.  One call
+ * on any existing (or specially made) ctx is sufficient; after
+ * this all previously existing libxl_ctx's are invalidated and
+ * must not be used - or even freed.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..4aaa0b5
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered) { rc = 0; goto out; }
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "pthread_atfork failed");
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    libxl_fd_set_cloexec(ctx, fd, 1);
+    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    cf = libxl__carefd_record(ctx, fd);
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, "failed to close fd=%d"
+                             " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    LIBXL_LIST_REMOVE(cf, entry);
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b2f9092..3d0379e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -596,6 +596,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1279,6 +1282,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  Cannot fail. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  Cannot fail. */
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9fd67b4..d806077 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -97,6 +97,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Il-0001Q9-Lm; Fri, 24 Feb 2012 18:55: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 1S10Ij-0001Jc-NH
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!12
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23917 invoked from network); 24 Feb 2012 18:54:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ia-00023o-Ja; Fri, 24 Feb 2012 18:55:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ia-0001j8-Il;
	Fri, 24 Feb 2012 18:55:20 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:54:59 +0000
Message-ID: <1330109703-6536-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/15] libxl: Protect fds with CLOEXEC even with
	forking threads
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We introduce a new "carefd" concept, which relates to fds that we care
about not being inherited by long-lived children.

As yet we do not use this anywhere in libxl.  Until all locations in
libxl which make such fds are converted, libxl__postfork may not work
entirely properly.  If these locations do not use O_CLOEXEC (or use
calls for which there is no O_CLOEXEC) then multithreaded programs may
not work properly.

This introduces a new API call libxl_postfork_child_noexec which must
be called by applications which make long-running non-execing
children.  Add the appropriate call to xl's postfork function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |    3 +
 tools/libxl/libxl_event.h    |   12 ++++
 tools/libxl/libxl_fork.c     |  146 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   63 ++++++++++++++++++
 tools/libxl/xl.c             |    3 +
 6 files changed, 228 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxl/libxl_fork.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 347f192..a041294 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -57,7 +57,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fd890cf..716163a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -68,6 +68,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     /* Now ctx is safe for ctx_free; failures simply set rc and "goto out" */
 
+    rc = libxl__atfork_init(ctx);
+    if (rc) goto out;
+
     rc = libxl__poller_init(ctx, &ctx->poller_app);
     if (rc) goto out;
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f889115..f8bc22f 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -369,6 +369,18 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*
+ * An application which initialises a libxl_ctx in a parent process
+ * and then forks a child which does not quickly exec, must
+ * instead libxl__postfork_child_noexec in the child.  One call
+ * on any existing (or specially made) ctx is sufficient; after
+ * this all previously existing libxl_ctx's are invalidated and
+ * must not be used - or even freed.
+ */
+void libxl_postfork_child_noexec(libxl_ctx *ctx);
+
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
new file mode 100644
index 0000000..4aaa0b5
--- /dev/null
+++ b/tools/libxl/libxl_fork.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal child process machinery for use by other parts of libxl
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/*
+ * carefd arrangements
+ *
+ * carefd_begin and _unlock take out the no_forking lock, which we
+ * also take and release in our pthread_atfork handlers.  So when this
+ * lock is held the whole process cannot fork.  We therefore protect
+ * our fds from leaking into children made by other threads.
+ *
+ * We maintain a list of all the carefds, so that if the application
+ * wants to fork a long-running but non-execing child, we can close
+ * them all.
+ *
+ * So the record function sets CLOEXEC for the benefit of execing
+ * children, and makes a note of the fd for the benefit of non-execing
+ * ones.
+ */
+
+struct libxl__carefd {
+    LIBXL_LIST_ENTRY(libxl__carefd) entry;
+    int fd;
+};
+
+static pthread_mutex_t no_forking = PTHREAD_MUTEX_INITIALIZER;
+static int atfork_registered;
+static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
+    LIBXL_LIST_HEAD_INITIALIZER(carefds);
+
+static void atfork_lock(void)
+{
+    int r = pthread_mutex_lock(&no_forking);
+    assert(!r);
+}
+
+static void atfork_unlock(void)
+{
+    int r = pthread_mutex_unlock(&no_forking);
+    assert(!r);
+}
+
+int libxl__atfork_init(libxl_ctx *ctx)
+{
+    int r, rc;
+    
+    atfork_lock();
+    if (atfork_registered) { rc = 0; goto out; }
+
+    r = pthread_atfork(atfork_lock, atfork_unlock, atfork_unlock);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "pthread_atfork failed");
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    atfork_registered = 1;
+    rc = 0;
+ out:
+    atfork_unlock();
+    return rc;
+}
+
+void libxl__carefd_begin(void) { atfork_lock(); }
+void libxl__carefd_unlock(void) { atfork_unlock(); }
+
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    libxl_fd_set_cloexec(ctx, fd, 1);
+    cf = libxl__zalloc(NULL, sizeof(*cf));
+    cf->fd = fd;
+    LIBXL_LIST_INSERT_HEAD(&carefds, cf, entry);
+    return cf;
+}
+
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd)
+{
+    libxl__carefd *cf = 0;
+
+    cf = libxl__carefd_record(ctx, fd);
+    libxl__carefd_unlock();
+    return cf;
+}
+
+void libxl_postfork_child_noexec(libxl_ctx *ctx)
+{
+    libxl__carefd *cf, *cf_tmp;
+    int r;
+
+    atfork_lock();
+    LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
+        if (cf->fd >= 0) {
+            r = close(cf->fd);
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, "failed to close fd=%d"
+                             " (perhaps of another libxl ctx)", cf->fd);
+        }
+        free(cf);
+    }
+    LIBXL_LIST_INIT(&carefds);
+    atfork_unlock();
+}
+
+int libxl__carefd_close(libxl__carefd *cf)
+{
+    if (!cf) return 0;
+    int r = cf->fd < 0 ? 0 : close(cf->fd);
+    int esave = errno;
+    LIBXL_LIST_REMOVE(cf, entry);
+    free(cf);
+    errno = esave;
+    return r;
+}
+
+int libxl__carefd_fd(const libxl__carefd *cf)
+{
+    if (!cf) return -1;
+    return cf->fd;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b2f9092..3d0379e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -596,6 +596,9 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
 
+int libxl__atfork_init(libxl_ctx *ctx);
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -1279,6 +1282,66 @@ _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
 /* For use by ao machinery ONLY */
 _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
 
+
+/*
+ * File descriptors and CLOEXEC
+ */
+
+/*
+ * For libxl functions which create file descriptors, at least one
+ * of the following must be true:
+ *  (a) libxl does not care if copies of this open-file are inherited
+ *      by random children and might remain open indefinitely
+ *  (b) libxl must take extra care for the fd (the actual descriptor,
+ *      not the open-file) as below.  We call this a "carefd".
+ *
+ * The rules for opening a carefd are:
+ *  (i)   Before bringing any carefds into existence,
+ *        libxl code must call libxl__carefd_begin.
+ *  (ii)  Then for each carefd brought into existence,
+ *        libxl code must call libxl__carefd_record
+ *        and remember the libxl__carefd_record*.
+ *  (iii) Then it must call libxl__carefd_unlock.
+ *  (iv)  When in a child process the fd is to be passed across
+ *        exec by libxl, the libxl code must unset FD_CLOEXEC
+ *        on the fd eg by using libxl_fd_set_cloexec.
+ *  (v)   Later, when the fd is to be closed in the same process,
+ *        libxl code must not call close.  Instead, it must call
+ *        libxl__carefd_close.
+ * Steps (ii) and (iii) can be combined by calling the convenience
+ * function libxl__carefd_opened.
+ */
+/* libxl__carefd_begin and _unlock (or _opened) must be called always
+ * in pairs.  They may be called with the CTX lock held.  In between
+ * _begin and _unlock, the following are prohibited:
+ *   - anything which might block
+ *   - any callbacks to the application
+ *   - nested calls to libxl__carefd_begin
+ *   - fork (libxl__fork)
+ * In general nothing should be done before _unlock that could be done
+ * afterwards.
+ */
+typedef struct libxl__carefd libxl__carefd;
+
+void libxl__carefd_begin(void);
+void libxl__carefd_unlock(void);
+
+/* fd may be -1, in which case this returns a dummy libxl__fd_record
+ * on which it _carefd_close is a no-op.  Cannot fail. */
+libxl__carefd *libxl__carefd_record(libxl_ctx *ctx, int fd);
+
+/* Combines _record and _unlock in a single call.  If fd==-1,
+ * still does the unlock, but returns 0.  Cannot fail. */
+libxl__carefd *libxl__carefd_opened(libxl_ctx *ctx, int fd);
+
+/* Works just like close(2).  You may pass NULL, in which case it's
+ * a successful no-op. */
+int libxl__carefd_close(libxl__carefd*);
+
+/* You may pass NULL in which case the answer is -1. */
+int libxl__carefd_fd(const libxl__carefd*);
+
+
 /*
  * Convenience macros.
  */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 9fd67b4..d806077 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -97,6 +97,9 @@ static void parse_global_config(const char *configfile,
 
 void postfork(void)
 {
+    libxl_postfork_child_noexec(ctx); /* in case we don't exit/exec */
+    ctx = 0;
+
     if (libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, (xentoollog_logger*)logger)) {
         fprintf(stderr, "cannot reinit xl context after fork\n");
         exit(-1);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ip-0001TG-Fa; Fri, 24 Feb 2012 18:55:35 +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 1S10In-0001N3-Tu
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23952 invoked from network); 24 Feb 2012 18:54:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ic-00023r-Bi; Fri, 24 Feb 2012 18:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ic-0001jF-B0;
	Fri, 24 Feb 2012 18:55:22 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:55:00 +0000
Message-ID: <1330109703-6536-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/15] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5ac6334..5405299 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ip-0001TG-Fa; Fri, 24 Feb 2012 18:55:35 +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 1S10In-0001N3-Tu
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!13
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23952 invoked from network); 24 Feb 2012 18:54:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ic-00023r-Bi; Fri, 24 Feb 2012 18:55:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ic-0001jF-B0;
	Fri, 24 Feb 2012 18:55:22 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:55:00 +0000
Message-ID: <1330109703-6536-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/15] libxl: libxl_event.c:beforepoll_internal,
	REQUIRE_FDS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce definition and use of a new function-local macro REQUIRE_FDS
to avoid repeatedly spelling out which fds we are interested in.

We are going to introduce a new fd for the SIGCHLD self-pipe.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c |   82 ++++++++++++++++++++++++++++++--------------
 1 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5ac6334..5405299 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -593,6 +593,45 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
     int rc;
 
     /*
+     * We need to look at the fds we want twice: firstly, to count
+     * them so we can make the rindex array big enough, and secondly
+     * to actually fill the arrays in.
+     *
+     * To ensure correctness and avoid repeating the logic for
+     * deciding which fds are relevant, we define a macro
+     *    REQUIRE_FDS( BODY )
+     * which calls
+     *    do{
+     *        int req_fd;
+     *        int req_events;
+     *        BODY;
+     *    }while(0)
+     * for each fd with a nonzero events.  This is invoked twice.
+     *
+     * The definition of REQUIRE_FDS is simplified with the helper
+     * macro
+     *    void REQUIRE_FD(int req_fd, int req_events, BODY);
+     */
+
+#define REQUIRE_FDS(BODY) do{                                          \
+                                                                       \
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)                     \
+            REQUIRE_FD(efd->fd, efd->events, BODY);                    \
+                                                                       \
+        REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
+                                                                       \
+    }while(0)
+
+#define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
+        int req_events = (req_events_);                 \
+        int req_fd = (req_fd_);                         \
+        if (req_events) {                               \
+            BODY;                                       \
+        }                                               \
+    }while(0)
+
+
+    /*
      * In order to be able to efficiently find the libxl__ev_fd
      * for a struct poll during _afterpoll, we maintain a shadow
      * data structure in CTX->fd_beforepolled: each slot in
@@ -609,13 +648,13 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = poller->wakeup_pipe[0] + 1;
-        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-            if (!efd->events)
-                continue;
-            if (efd->fd >= maxfd)
-                maxfd = efd->fd + 1;
-        }
+        int maxfd = 0;
+
+        REQUIRE_FDS({
+            if (req_fd >= maxfd)
+                maxfd = req_fd + 1;
+        });
+
         /* make sure our array is as big as *nfds_io */
         if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
@@ -630,25 +669,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
 
     int used = 0;
 
-#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
-        if ((req_events)) {                                     \
-            if (used < *nfds_io) {                              \
-                fds[used].fd = (req_fd);                        \
-                fds[used].events = (req_events);                \
-                fds[used].revents = 0;                          \
-                assert((req_fd) < poller->fd_rindex_allocd);    \
-                poller->fd_rindex[(req_fd)] = used;             \
-            }                                                   \
-            used++;                                             \
-        }                                                       \
-    }while(0)
-
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
-        REQUIRE_FD(efd->fd, efd->events, efd);
-
-    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
-
-#undef REQUIRE_FD
+    REQUIRE_FDS({
+        if (used < *nfds_io) {
+            fds[used].fd = req_fd;
+            fds[used].events = req_events;
+            fds[used].revents = 0;
+            assert(req_fd < poller->fd_rindex_allocd);
+            poller->fd_rindex[req_fd] = used;
+        }
+        used++;
+    });
 
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ip-0001Tb-SI; Fri, 24 Feb 2012 18:55:35 +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 1S10Io-0001PC-2S
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!16
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24117 invoked from network); 24 Feb 2012 18:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ig-000242-QW; Fri, 24 Feb 2012 18:55:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ig-0001jR-Pi;
	Fri, 24 Feb 2012 18:55:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:55:03 +0000
Message-ID: <1330109703-6536-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/15] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 09bfd27..1762bf8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1083,6 +1083,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 43fd134..e346e05 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 9f9f91d..d2efa5c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -534,6 +534,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ip-0001Tb-SI; Fri, 24 Feb 2012 18:55:35 +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 1S10Io-0001PC-2S
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!16
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24117 invoked from network); 24 Feb 2012 18:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Ig-000242-QW; Fri, 24 Feb 2012 18:55:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Ig-0001jR-Pi;
	Fri, 24 Feb 2012 18:55:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 24 Feb 2012 18:55:03 +0000
Message-ID: <1330109703-6536-16-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/15] libxl: Introduce libxl__sendmsg_fds and
	libxl__recvmsg_fds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We will want to reuse the fd-sending code, so break it out into its
own function, and provide the corresponding sending function.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   11 ++++
 tools/libxl/libxl_qmp.c      |   31 ++-----------
 tools/libxl/libxl_utils.c    |  104 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+), 27 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 09bfd27..1762bf8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1083,6 +1083,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                        const libxl_domain_config *guest_config);
 
+/* on failure, logs */
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what);
+
+/* Insists on receiving exactly nfds and datalen.  On failure, logs
+ * and leaves *fds untouched. */
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what);
+
 /* from libxl_json */
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 43fd134..e346e05 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -544,38 +544,15 @@ static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
                        qmp_request_context *context,
                        int fd)
 {
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
     char *buf = NULL;
+    int rc;
 
     buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
 
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
+    rc = libxl__sendmsg_fds(gc, qmp->qmp_fd, buf, strlen(buf), 1, &fd,
+                            "QMP message to QEMU");
+    if (rc) return rc;
 
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket")) {
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 9f9f91d..d2efa5c 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -534,6 +534,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
     free(list);
 }
 
+int libxl__sendmsg_fds(libxl__gc *gc, int carrier,
+                       const void *data, size_t datalen,
+                       int nfds, const int fds[], const char *what) {
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = (void*)data;
+    iov.iov_len  = datalen;
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(spaceneeded);
+    memcpy(CMSG_DATA(cmsg), fds, spaceneeded);
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    r = sendmsg(carrier, &msg, 0);
+    if (r < 0) {
+        LOGE(ERROR, "failed to send fd-carrying message (%s)", what);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+int libxl__recvmsg_fds(libxl__gc *gc, int carrier,
+                       void *databuf, size_t datalen,
+                       int nfds, int fds[], const char *what)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    size_t spaceneeded = nfds * sizeof(fds[0]);
+    char control[CMSG_SPACE(spaceneeded)];
+    struct iovec iov;
+    int r;
+
+    iov.iov_base = databuf;
+    iov.iov_len  = datalen;
+
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof(control);
+
+    for (;;) {
+        r = recvmsg(carrier, &msg, 0);
+        if (r < 0) {
+            if (errno == EINTR) continue;
+            if (errno == EWOULDBLOCK) return -1;
+            LOGE(ERROR,"recvmsg failed (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (r == 0) {
+            LOG(ERROR,"recvmsg got EOF (%s)", what);
+            return ERROR_FAIL;
+        }
+        cmsg = CMSG_FIRSTHDR(&msg);
+        if (cmsg->cmsg_len <= CMSG_LEN(0)) {
+            LOG(ERROR,"recvmsg got no control msg"
+                " when expecting fds (%s)", what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)",
+                cmsg->cmsg_level, SOL_SOCKET,
+                cmsg->cmsg_type, SCM_RIGHTS,
+                what);
+            return ERROR_FAIL;
+        }
+        if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) ||
+            msg.msg_controllen != cmsg->cmsg_len) {
+            LOG(ERROR, "recvmsg got unexpected"
+                " number of fds or extra control data"
+                " (%ld bytes' worth, expected %ld) (%s)",
+                (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len,
+                what);
+            int i, fd;
+            unsigned char *p;
+            for (i=0, p=CMSG_DATA(cmsg);
+                 CMSG_SPACE(i * sizeof(fds[0]));
+                 i++, i+=sizeof(fd)) {
+                memcpy(&fd, p, sizeof(fd));
+                close(fd);
+            }
+            return ERROR_FAIL;
+        }
+        memcpy(fds, CMSG_DATA(cmsg), spaceneeded);
+        return 0;
+    }
+}         
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ir-0001Vg-J4; Fri, 24 Feb 2012 18:55: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 1S10Iq-0001PQ-At
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23985 invoked from network); 24 Feb 2012 18:54:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Id-00023u-MP; Fri, 24 Feb 2012 18:55:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Id-0001jJ-La;
	Fri, 24 Feb 2012 18:55:23 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:55:01 +0000
Message-ID: <1330109703-6536-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/15] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl_event.c    |   52 +++++++--
 tools/libxl/libxl_event.h    |  142 ++++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  243 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   61 ++++++++++-
 5 files changed, 495 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 716163a..06ac064 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5405299..dcd5802 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -620,6 +620,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -749,10 +753,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -763,11 +768,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1063,16 +1073,36 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f8bc22f..01e970a 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -161,11 +161,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -370,6 +365,142 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     The application must install a SIGCHLD handler and reap (at
+ *     least) all of libxl's children and pass their exit status
+ *     to libxl by calling libxl_childproc_exited.
+ *
+ *     An application which does this must call
+ *     libxl_childproc_setmode.
+ * 
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_NOT_READY if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_NOT_READY.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
@@ -381,6 +512,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 void libxl_postfork_child_noexec(libxl_ctx *ctx);
 
 
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 4aaa0b5..ee62b61 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -108,6 +114,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -117,6 +124,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -138,6 +149,238 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_NOT_READY;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc) {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                CTX->childproc_hooks->reaped_callback
+                    (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+            } else {
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+            }
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3d0379e..09bfd27 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -182,6 +182,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -251,6 +264,8 @@ struct libxl__ctx {
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
 
+    LIBXL_LIST_ENTRY(struct libxl__ctx);
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -291,10 +306,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -542,6 +561,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon, and should not make
+ * any further libxl event calls in the meantime.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  Either death or cldstop may be
+ * NULL in which case that kind of event is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -595,6 +641,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:55:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10Ir-0001Vg-J4; Fri, 24 Feb 2012 18:55: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 1S10Iq-0001PQ-At
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:55:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330109655!62028600!14
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23985 invoked from network); 24 Feb 2012 18:54:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:54:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:55:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:55:23 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10Id-00023u-MP; Fri, 24 Feb 2012 18:55:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10Id-0001jJ-La;
	Fri, 24 Feb 2012 18:55:23 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 24 Feb 2012 18:55:01 +0000
Message-ID: <1330109703-6536-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/15] libxl: event API: new facilities for
	waiting for subprocesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The current arrangements in libxl for spawning subprocesses have two
key problems: (i) they make unwarranted (and largely undocumented)
assumptions about the caller's use of subprocesses, (ii) they aren't
integrated into the event system and can't be made asynchronous etc.

So replace them with a new set of facilities.

Primarily, from the point of view of code inside libxl, this is
libxl__ev_child_fork which is both (a) a version of fork() and (b) an
event source which generates a callback when the child dies.

>From the point of view of the application, we fully document our use
of SIGCHLD.  The application can tell us whether it wants to own
SIGCHLD or not; if it does, it has to tell us about deaths of our
children.

Currently there are no callers in libxl which use these facilities.
All code in libxl which forks needs to be converted and libxl_fork
needse to be be abolished.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   17 +++-
 tools/libxl/libxl_event.c    |   52 +++++++--
 tools/libxl/libxl_event.h    |  142 ++++++++++++++++++++++++-
 tools/libxl/libxl_fork.c     |  243 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   61 ++++++++++-
 5 files changed, 495 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 716163a..06ac064 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
-    /* First initialise pointers (cannot fail) */
+    /* First initialise pointers etc. (cannot fail) */
 
     LIBXL_TAILQ_INIT(&ctx->occurred);
 
@@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    ctx->childproc_hooks = &libxl__childproc_default_hooks;
+    ctx->childproc_user = 0;
+        
+    ctx->sigchld_selfpipe[0] = -1;
+
     /* The mutex is special because we can't idempotently destroy it */
 
     if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     discard_events(&ctx->occurred);
 
+    /* If we have outstanding children, then the application inherits
+     * them; we wish the application good luck with understanding
+     * this if and when it reaps them. */
+    libxl__sigchld_removehandler(ctx);
+
+    if (ctx->sigchld_selfpipe[0] >= 0) {
+        close(ctx->sigchld_selfpipe[0]);
+        close(ctx->sigchld_selfpipe[1]);
+    }
+
     pthread_mutex_destroy(&ctx->lock);
 
     GC_FREE;
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 5405299..dcd5802 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -620,6 +620,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
                                                                        \
         REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY);              \
                                                                        \
+        int selfpipe = libxl__fork_selfpipe_active(CTX);               \
+        if (selfpipe >= 0)                                             \
+            REQUIRE_FD(selfpipe, POLLIN, BODY);                        \
+                                                                       \
     }while(0)
 
 #define REQUIRE_FD(req_fd_, req_events_, BODY) do{      \
@@ -749,10 +753,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked exactly once */
     EGC_GC;
     libxl__ev_fd *efd;
 
-
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
@@ -763,11 +768,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
     }
 
     if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
-        char buf[256];
-        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
-        if (r < 0)
-            if (errno != EINTR && errno != EWOULDBLOCK)
-                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+        int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0);
+    }
+
+    int selfpipe = libxl__fork_selfpipe_active(CTX);
+    if (selfpipe >= 0 &&
+        afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) {
+        int e = libxl__self_pipe_eatall(selfpipe);
+        if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0);
+        libxl__fork_selfpipe_woken(egc);
     }
 
     for (;;) {
@@ -1063,16 +1073,36 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
 
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
 {
+    int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]);
+    if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0);
+}
+
+int libxl__self_pipe_wakeup(int fd)
+{
     static const char buf[1] = "";
 
     for (;;) {
-        int r = write(p->wakeup_pipe[1], buf, 1);
-        if (r==1) return;
+        int r = write(fd, buf, 1);
+        if (r==1) return 0;
         assert(r==-1);
         if (errno == EINTR) continue;
-        if (errno == EWOULDBLOCK) return;
-        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
-        return;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
+    }
+}
+
+int libxl__self_pipe_eatall(int fd)
+{
+    char buf[256];
+    for (;;) {
+        int r = read(fd, buf, sizeof(buf));
+        if (r >= 0) return 0;
+        assert(r == -1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return 0;
+        assert(errno);
+        return errno;
     }
 }
 
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f8bc22f..01e970a 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -161,11 +161,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx,
  * After libxl_ctx_free, all corresponding evgen handles become
  * invalid and must no longer be passed to evdisable.
  *
- * Events enabled with evenable prior to a fork and libxl_ctx_postfork
- * are no longer generated after the fork/postfork; however the evgen
- * structures are still valid and must be passed to evdisable if the
- * memory they use should not be leaked.
- *
  * Applications should ensure that they eventually retrieve every
  * event using libxl_event_check or libxl_event_wait, since events
  * which occur but are not retreived by the application will be queued
@@ -370,6 +365,142 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
 
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     logged warnings if no callback is provided or the callback
+ *     denies responsibility for the child).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ *     A multithreaded application which is naive in this sense may
+ *     block SIGCHLD on some of its threads, but there must be at
+ *     least one thread that has SIGCHLD unblocked.  libxl will not
+ *     modify the blocking flag for SIGCHLD (except that it may create
+ *     internal service threads with all signals blocked).
+ *
+ *     A naive program must only have at any one time only
+ *     one libxl context which might have children.
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     The application must install a SIGCHLD handler and reap (at
+ *     least) all of libxl's children and pass their exit status
+ *     to libxl by calling libxl_childproc_exited.
+ *
+ *     An application which does this must call
+ *     libxl_childproc_setmode.
+ * 
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, while it uses any libxl operation which might
+ * create or use child processes (see above):
+ *   - Must not have any child processes running.
+ *   - Must not install a SIGCHLD handler.
+ *   - Must not reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child. */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but NOT
+     * from within a signal handler.  libxl will not itself arrange to
+     * (un)block or catch SIGCHLD. */
+    libxl_sigchld_owner_mainloop,
+
+    /* libxl owns SIGCHLD all the time, and the application is
+     * relying on libxl's event loop for reaping its own children. */
+    libxl_sigchld_owner_libxl_always,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_mainloop.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_NOT_READY if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*reaped_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/*
+ * This function is for an application which owns SIGCHLD and which
+ * therefore reaps all of the process's children.
+ *
+ * May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_NOT_READY.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status);
+
+
 /*
  * An application which initialises a libxl_ctx in a parent process
  * and then forks a child which does not quickly exec, must
@@ -381,6 +512,7 @@ void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 void libxl_postfork_child_noexec(libxl_ctx *ctx);
 
 
+
 #endif
 
 /*
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index 4aaa0b5..ee62b61 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -46,6 +46,12 @@ static int atfork_registered;
 static LIBXL_LIST_HEAD(, libxl__carefd) carefds =
     LIBXL_LIST_HEAD_INITIALIZER(carefds);
 
+/* non-null iff installed, protected by no_forking */
+static libxl_ctx *sigchld_owner;
+static struct sigaction sigchld_saved_action;
+
+static void sigchld_removehandler_core(void);
+
 static void atfork_lock(void)
 {
     int r = pthread_mutex_lock(&no_forking);
@@ -108,6 +114,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
     int r;
 
     atfork_lock();
+
     LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) {
         if (cf->fd >= 0) {
             r = close(cf->fd);
@@ -117,6 +124,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx)
         free(cf);
     }
     LIBXL_LIST_INIT(&carefds);
+
+    if (sigchld_owner)
+        sigchld_removehandler_core();
+
     atfork_unlock();
 }
 
@@ -138,6 +149,238 @@ int libxl__carefd_fd(const libxl__carefd *cf)
 }
 
 /*
+ * Actual child process handling
+ */
+
+static void sigchld_handler(int signo)
+{
+    int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]);
+    assert(!e); /* errors are probably EBADF, very bad */
+}
+
+static void sigchld_removehandler_core(void)
+{
+    struct sigaction was;
+    int r;
+    
+    r = sigaction(SIGCHLD, &sigchld_saved_action, &was);
+    assert(!r);
+    assert(!(was.sa_flags & SA_SIGINFO));
+    assert(was.sa_handler == sigchld_handler);
+    sigchld_owner = 0;
+}
+
+void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    atfork_lock();
+    if (sigchld_owner == ctx)
+        sigchld_removehandler_core();
+    atfork_unlock();
+}
+
+int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */
+{
+    int r, rc;
+
+    if (ctx->sigchld_selfpipe[0] < 0) {
+        r = pipe(ctx->sigchld_selfpipe);
+        if (r) {
+            ctx->sigchld_selfpipe[0] = -1;
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "failed to create sigchld pipe");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    atfork_lock();
+    if (sigchld_owner != ctx) {
+        struct sigaction ours;
+
+        assert(!sigchld_owner);
+        sigchld_owner = ctx;
+
+        memset(&ours,0,sizeof(ours));
+        ours.sa_handler = sigchld_handler;
+        sigemptyset(&ours.sa_mask);
+        ours.sa_flags = SA_NOCLDSTOP | SA_RESTART;
+        r = sigaction(SIGCHLD, &ours, &sigchld_saved_action);
+        assert(!r);
+
+        assert(((void)"application must negotiate with libxl about SIGCHLD",
+                !(sigchld_saved_action.sa_flags & SA_SIGINFO) &&
+                (sigchld_saved_action.sa_handler == SIG_DFL ||
+                 sigchld_saved_action.sa_handler == SIG_IGN)));
+    }
+    atfork_unlock();
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static int chldmode_ours(libxl_ctx *ctx)
+{
+    return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl;
+}
+
+int libxl__fork_selfpipe_active(libxl_ctx *ctx)
+{
+    /* Returns the fd to read, or -1 */
+    if (!chldmode_ours(ctx))
+        return -1;
+
+    if (LIBXL_LIST_EMPTY(&ctx->children))
+        return -1;
+
+    return ctx->sigchld_selfpipe[0];
+}
+
+static void perhaps_removehandler(libxl_ctx *ctx)
+{
+    if (LIBXL_LIST_EMPTY(&ctx->children) &&
+        ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always)
+        libxl__sigchld_removehandler(ctx);
+}
+
+static int childproc_reaped(libxl__egc *egc, pid_t pid, int status)
+{
+    EGC_GC;
+    libxl__ev_child *ch;
+
+    LIBXL_LIST_FOREACH(ch, &CTX->children, entry)
+        if (ch->pid == pid)
+            goto found;
+
+    /* not found */
+    return ERROR_NOT_READY;
+
+ found:
+    LIBXL_LIST_REMOVE(ch, entry);
+    ch->pid = -1;
+    ch->callback(egc, ch, pid, status);
+
+    perhaps_removehandler(CTX);
+
+    return 0;
+}
+
+int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = childproc_reaped(egc, pid, status);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+void libxl__fork_selfpipe_woken(libxl__egc *egc) {
+    /* May make callbacks into the appliction for child processes.
+     * ctx must be locked EXACTLY ONCE */
+    EGC_GC;
+
+    while (chldmode_ours(CTX) /* in case the app changes the mode */) {
+        int status;
+        pid_t pid = waitpid(-1, &status, WNOHANG);
+
+        if (pid == 0) return;
+
+        if (pid == -1) {
+            if (errno == ECHILD) return;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0);
+            return;
+        }
+
+        int rc = childproc_reaped(egc, pid, status);
+
+        if (rc) {
+            if (CTX->childproc_hooks->reaped_callback) {
+                CTX_UNLOCK;
+                CTX->childproc_hooks->reaped_callback
+                    (pid, status, CTX->childproc_user);
+                CTX_LOCK;
+            } else {
+                libxl_report_child_exitstatus(CTX, XTL_WARN,
+                                "unknown child", (long)pid, status);
+            }
+        }
+    }
+}
+
+pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch,
+                           libxl__ev_child_callback *death)
+{
+    CTX_LOCK;
+    int rc;
+
+    if (chldmode_ours(CTX)) {
+        rc = libxl__sigchld_installhandler(CTX);
+        if (rc) goto out;
+    }
+
+    pid_t pid =
+        CTX->childproc_hooks->fork_replacement
+        ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user)
+        : fork();
+    if (pid == -1) {
+        LOGE(ERROR, "fork failed");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    if (!pid) {
+        /* woohoo! */
+        return 0; /* Yes, CTX is left locked in the child. */
+    }
+
+    ch->pid = pid;
+    ch->callback = death;
+    LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry);
+    rc = pid;
+
+ out:
+    perhaps_removehandler(CTX);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user)
+{
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(LIBXL_LIST_EMPTY(&CTX->children));
+
+    if (!hooks)
+        hooks = &libxl__childproc_default_hooks;
+
+    ctx->childproc_hooks = hooks;
+    ctx->childproc_user = user;
+
+    switch (ctx->childproc_hooks->chldowner) {
+    case libxl_sigchld_owner_mainloop:
+    case libxl_sigchld_owner_libxl:
+        libxl__sigchld_removehandler(ctx);
+        break;
+    case libxl_sigchld_owner_libxl_always:
+        libxl__sigchld_installhandler(ctx);
+        break;
+    default:
+        abort();
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+const libxl_childproc_hooks libxl__childproc_default_hooks = {
+    libxl_sigchld_owner_libxl, 0, 0
+};
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3d0379e..09bfd27 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -182,6 +182,19 @@ typedef struct libxl__ev_watch_slot {
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
 
+typedef struct libxl__ev_child libxl__ev_child;
+typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*,
+                                      pid_t pid, int status);
+struct libxl__ev_child {
+    /* caller should include this in their own struct */
+    /* read-only for caller: */
+    pid_t pid; /* -1 means unused ("unregistered", ie Idle) */
+    libxl__ev_child_callback *callback;
+    /* remainder is private for libxl__ev_... */
+    LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
+};
+
+
 /*
  * evgen structures, which are the state we use for generating
  * events for the caller.
@@ -251,6 +264,8 @@ struct libxl__ctx {
     const libxl_event_hooks *event_hooks;
     void *event_hooks_user;
 
+    LIBXL_LIST_ENTRY(struct libxl__ctx);
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -291,10 +306,14 @@ struct libxl__ctx {
     
     LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens;
 
-    /* for callers who reap children willy-nilly; caller must only
-     * set this after libxl_init and before any other call - or
-     * may leave them untouched */
+    const libxl_childproc_hooks *childproc_hooks;
+    void *childproc_user;
+    int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */
+    LIBXL_LIST_HEAD(, libxl__ev_child) children;
+
+    /* This is obsolete and must be removed: */
     int (*waitpid_instead)(pid_t pid, int *status, int flags);
+
     libxl_version_info version_info;
 };
 
@@ -542,6 +561,33 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 /*
+ * For making subprocesses.  This is the only permitted mechanism for
+ * code in libxl to do so.
+ *
+ * In the parent, returns the pid, filling in childw_out.
+ * In the child, returns 0.
+ * If it fails, returns a libxl error (all of which are -ve).
+ *
+ * The child should go on to exec (or exit) soon, and should not make
+ * any further libxl event calls in the meantime.
+ *
+ * The parent may signal the child but it must not reap it.  That will
+ * be done by the event machinery.  Either death or cldstop may be
+ * NULL in which case that kind of event is ignored.
+ *
+ * It is not possible to "deregister" the child death event source.
+ * It will generate exactly one event callback; until then the childw
+ * is Active and may not be reused.
+ */
+_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out,
+                                 libxl__ev_child_callback *death);
+static inline void libxl__ev_child_init(libxl__ev_child *childw_out)
+                { childw_out->pid = -1; }
+static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
+                { return childw_out->pid >= 0; }
+
+
+/*
  * Other event-handling support provided by the libxl event core to
  * the rest of libxl.
  */
@@ -595,6 +641,15 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
  * ctx must be locked. */
 void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
 
+/* Internal to fork and child reaping machinery */
+extern const libxl_childproc_hooks libxl__childproc_default_hooks;
+int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */
+void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */
+int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */
+void libxl__fork_selfpipe_woken(libxl__egc *egc);
+int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */
+int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */
+
 
 int libxl__atfork_init(libxl_ctx *ctx);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10KW-0002cy-9O; Fri, 24 Feb 2012 18:57:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S10KU-0002Zc-P2
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:57:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330109831!10592945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31939 invoked from network); 24 Feb 2012 18:57:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:57:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:57:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10KM-0002AC-Vk	for xen-devel@lists.xensource.com;
	Fri, 24 Feb 2012 18:57:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10KM-0001k4-Uy	for
	xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:57:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.56710.946028.68075@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 18:57:10 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [PATCH v2 00/15] libxl: child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes (""):
> Once again, I have not executed the code in this series!

The subject line in my original 00/15 mail seems to have been lost.
Sorry.

Also, it seems that a glitch in my patch management system has lost
some acks that I believe may have been posted.  Sorry; I didn't
intentionally remove any acks due to code change, so you can feel
confident just to re-ack without re-reading.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 18:57:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 18:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S10KW-0002cy-9O; Fri, 24 Feb 2012 18:57:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S10KU-0002Zc-P2
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:57:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330109831!10592945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31939 invoked from network); 24 Feb 2012 18:57:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 18:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10927947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 18:57:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 18:57:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S10KM-0002AC-Vk	for xen-devel@lists.xensource.com;
	Fri, 24 Feb 2012 18:57:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S10KM-0001k4-Uy	for
	xen-devel@lists.xensource.com; Fri, 24 Feb 2012 18:57:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20295.56710.946028.68075@mariner.uk.xensource.com>
Date: Fri, 24 Feb 2012 18:57:10 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1330109703-6536-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [PATCH v2 00/15] libxl: child process handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes (""):
> Once again, I have not executed the code in this series!

The subject line in my original 00/15 mail seems to have been lost.
Sorry.

Also, it seems that a glitch in my patch management system has lost
some acks that I believe may have been posted.  Sorry; I didn't
intentionally remove any acks due to code change, so you can feel
confident just to re-ack without re-reading.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 20:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 20:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S11SS-0004Pv-1K; Fri, 24 Feb 2012 20:09:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S11SP-0004Pq-LP
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 20:09:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330114167!16343365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15148 invoked from network); 24 Feb 2012 20:09:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 20:09:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10928470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 20:09:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 20:09:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S11S8-0003MZ-MB;
	Fri, 24 Feb 2012 20:09:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S11S8-0003pd-Li;
	Fri, 24 Feb 2012 20:09:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12048-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 20:09:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12048: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12048 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12048/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-win         7 windows-install             fail pass in 12036

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12036 like 11891
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12036 like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12036 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 20:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 20:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S11SS-0004Pv-1K; Fri, 24 Feb 2012 20:09:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S11SP-0004Pq-LP
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 20:09:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330114167!16343365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDk1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15148 invoked from network); 24 Feb 2012 20:09:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 20:09:27 -0000
X-IronPort-AV: E=Sophos;i="4.73,477,1325462400"; d="scan'208";a="10928470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2012 20:09:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 24 Feb 2012 20:09:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S11S8-0003MZ-MB;
	Fri, 24 Feb 2012 20:09:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S11S8-0003pd-Li;
	Fri, 24 Feb 2012 20:09:16 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12048-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 24 Feb 2012 20:09:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12048: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12048 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12048/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-win         7 windows-install             fail pass in 12036

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail in 12036 like 11891
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12036 like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12036 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 20:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 20: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 1S11eL-0004sb-Bx; Fri, 24 Feb 2012 20:21:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S11eJ-0004sK-O2
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 20:21:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330114768!50185677!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29794 invoked from network); 24 Feb 2012 20:19:29 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 20:19:29 -0000
Received: by wgbdt11 with SMTP id dt11so776955wgb.2
	for <xen-devel@lists.xen.org>; Fri, 24 Feb 2012 12:21:45 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr10089561wib.3.1330114905308 (num_hops
	= 1); Fri, 24 Feb 2012 12:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=4nWl+ZooDd1bqVgHuGBFZx9W0vixDV+vd7MghADKV/w=;
	b=JiXGWFwxgMaBENWhHspMSFG/NEmB7WKCGwDfaSkcuxP4VPyOVU3lz0deLfujofkJiQ
	YvKz7fAWzeEVVp+8wdbi989dKRWGHBru5JpFqYeUdvTz2se10/60CYPg8eEOp9SvCDmx
	XzTNz4fwr1rDLOW2LGPu272UTF1e4sscUGZSE=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr8157367wib.3.1330114905171; Fri,
	24 Feb 2012 12:21:45 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Fri, 24 Feb 2012 12:21:45 -0800 (PST)
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
Date: Fri, 24 Feb 2012 21:21:45 +0100
X-Google-Sender-Auth: tzU7KvJkg2_oAkwX33DcPTKh2HY
Message-ID: <CAPLaKK7HLJsiDq=UmW+_f-ea9ZfzaG_y0vtFcRuH5F4GvQWejg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: fix python version checking issue in
	configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI0IFJlbiwgWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50ZWwuY29tPjoKPiBFdmVuIGlm
IHB5dGhvbiB2ZXJzaW9uIGlzIDIuNC4zIHdoaWNoIGlzIG5ld2VyIHRoYW4gdGhlIHJlcXVpcmVk
IHZlcnNpb24gMi4zLCB0aGUgY29uZmlndXJlIHNjcmlwdCBzdGlsbCByYWlzZXMgYSB2ZXJzaW9u
IGlzc3VlLgo+IEkgdGVzdGVkIG15IHBhdGNoIHdpdGggcHl0aG9uIDIuNi42IGFuZCAyLjQuMy4g
SXQgd2lsbCBmaXggYSBzeW50YXggZXJyb3IgbGlrZSB0aGUgZm9sbG93aW5nLgo+IGNoZWNraW5n
IGZvciBweXRob24gdmVyc2lvbiA+PSAyLjMgLi4uIFRyYWNlYmFjayAobW9zdCByZWNlbnQgY2Fs
bCBsYXN0KToKPiDCoEZpbGUgIjxzdHJpbmc+IiwgbGluZSAxLCBpbiA/Cj4gVHlwZUVycm9yOiAn
c3RyJyBvYmplY3QgaXMgbm90IGNhbGxhYmxlCj4gbm8KPiBjb25maWd1cmU6IGVycm9yOiBQeXRo
b24gMi40LjMgaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMwo+Cj4g
U2lnbmVkLW9mZi1ieTogWW9uZ2ppZSBSZW4gPHlvbmdqaWUucmVuQGludGVsLmNvbT4KPiAtLQo+
Cj4gdG9vbHMvY29uZmlndXJlIHwgwqAgwqAyICstCj4gwqAxIGZpbGUgY2hhbmdlZCwgMSBpbnNl
cnRpb24oKyksIDEgZGVsZXRpb24oLSkKPgo+IGRpZmYgLXIgYTRkOTNkMGUwZGYyIHRvb2xzL2Nv
bmZpZ3VyZQo+IC0tLSBhL3Rvb2xzL2NvbmZpZ3VyZSDCoCBXZWQgRmViIDIyIDE0OjMzOjI0IDIw
MTIgKzAwMDAKPiArKysgYi90b29scy9jb25maWd1cmUgwqAgRnJpIEZlYiAyNCAyMToxODozMSAy
MDEyICswODAwCj4gQEAgLTYyOTMsNyArNjI5Myw3IEBACj4gwqBmaQo+IMKgIMKgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJz
aW9uID49IDIuMyAiID4mNQo+IMKgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJz
aW9uID49IDIuMyAuLi4gIiA+JjY7IH0KPiAtYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7IGV4aXQo
ZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgyLCAzKSIpKSdgCj4gK2AkUFlUSE9OIC1jICdpbXBv
cnQgc3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKClRo
aXMgaXMgd3JvbmcsIHRvb2xzL2NvbmZpZ3VyZSBzaG91bGQgbmV2ZXIgYmUgbW9kaWZpZWQgZGly
ZWN0bHkuCkluc3RlYWQgdG9vbHMvY29uZmlndXJlLmFjIHNob3VsZCBiZSBtb2RpZmllZCBhbmQg
YXV0b2dlbi5zaCByZXJ1biB0bwpnZW5lcmF0ZSBhIG5ldyBjb25maWd1cmUgc2NyaXB0LgoKPiDC
oGlmIHRlc3QgIiQ/IiAhPSAiMCIKPiDCoHRoZW4KPiDCoCDCoCBweXRob25fdmVyc2lvbj1gJFBZ
VEhPTiAtViAyPiYxYAo+Cj4KPgo+IEJlc3QgUmVnYXJkcywKPiDCoCDCoCBZb25namllIFJlbiDC
oChKYXkpCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4g
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Feb 24 20:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 20: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 1S11eL-0004sb-Bx; Fri, 24 Feb 2012 20:21:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S11eJ-0004sK-O2
	for xen-devel@lists.xen.org; Fri, 24 Feb 2012 20:21:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330114768!50185677!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29794 invoked from network); 24 Feb 2012 20:19:29 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2012 20:19:29 -0000
Received: by wgbdt11 with SMTP id dt11so776955wgb.2
	for <xen-devel@lists.xen.org>; Fri, 24 Feb 2012 12:21:45 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr10089561wib.3.1330114905308 (num_hops
	= 1); Fri, 24 Feb 2012 12:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=4nWl+ZooDd1bqVgHuGBFZx9W0vixDV+vd7MghADKV/w=;
	b=JiXGWFwxgMaBENWhHspMSFG/NEmB7WKCGwDfaSkcuxP4VPyOVU3lz0deLfujofkJiQ
	YvKz7fAWzeEVVp+8wdbi989dKRWGHBru5JpFqYeUdvTz2se10/60CYPg8eEOp9SvCDmx
	XzTNz4fwr1rDLOW2LGPu272UTF1e4sscUGZSE=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr8157367wib.3.1330114905171; Fri,
	24 Feb 2012 12:21:45 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Fri, 24 Feb 2012 12:21:45 -0800 (PST)
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
Date: Fri, 24 Feb 2012 21:21:45 +0100
X-Google-Sender-Auth: tzU7KvJkg2_oAkwX33DcPTKh2HY
Message-ID: <CAPLaKK7HLJsiDq=UmW+_f-ea9ZfzaG_y0vtFcRuH5F4GvQWejg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: fix python version checking issue in
	configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI0IFJlbiwgWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50ZWwuY29tPjoKPiBFdmVuIGlm
IHB5dGhvbiB2ZXJzaW9uIGlzIDIuNC4zIHdoaWNoIGlzIG5ld2VyIHRoYW4gdGhlIHJlcXVpcmVk
IHZlcnNpb24gMi4zLCB0aGUgY29uZmlndXJlIHNjcmlwdCBzdGlsbCByYWlzZXMgYSB2ZXJzaW9u
IGlzc3VlLgo+IEkgdGVzdGVkIG15IHBhdGNoIHdpdGggcHl0aG9uIDIuNi42IGFuZCAyLjQuMy4g
SXQgd2lsbCBmaXggYSBzeW50YXggZXJyb3IgbGlrZSB0aGUgZm9sbG93aW5nLgo+IGNoZWNraW5n
IGZvciBweXRob24gdmVyc2lvbiA+PSAyLjMgLi4uIFRyYWNlYmFjayAobW9zdCByZWNlbnQgY2Fs
bCBsYXN0KToKPiDCoEZpbGUgIjxzdHJpbmc+IiwgbGluZSAxLCBpbiA/Cj4gVHlwZUVycm9yOiAn
c3RyJyBvYmplY3QgaXMgbm90IGNhbGxhYmxlCj4gbm8KPiBjb25maWd1cmU6IGVycm9yOiBQeXRo
b24gMi40LjMgaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMwo+Cj4g
U2lnbmVkLW9mZi1ieTogWW9uZ2ppZSBSZW4gPHlvbmdqaWUucmVuQGludGVsLmNvbT4KPiAtLQo+
Cj4gdG9vbHMvY29uZmlndXJlIHwgwqAgwqAyICstCj4gwqAxIGZpbGUgY2hhbmdlZCwgMSBpbnNl
cnRpb24oKyksIDEgZGVsZXRpb24oLSkKPgo+IGRpZmYgLXIgYTRkOTNkMGUwZGYyIHRvb2xzL2Nv
bmZpZ3VyZQo+IC0tLSBhL3Rvb2xzL2NvbmZpZ3VyZSDCoCBXZWQgRmViIDIyIDE0OjMzOjI0IDIw
MTIgKzAwMDAKPiArKysgYi90b29scy9jb25maWd1cmUgwqAgRnJpIEZlYiAyNCAyMToxODozMSAy
MDEyICswODAwCj4gQEAgLTYyOTMsNyArNjI5Myw3IEBACj4gwqBmaQo+IMKgIMKgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJz
aW9uID49IDIuMyAiID4mNQo+IMKgJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJz
aW9uID49IDIuMyAuLi4gIiA+JjY7IH0KPiAtYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7IGV4aXQo
ZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgyLCAzKSIpKSdgCj4gK2AkUFlUSE9OIC1jICdpbXBv
cnQgc3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2AKClRo
aXMgaXMgd3JvbmcsIHRvb2xzL2NvbmZpZ3VyZSBzaG91bGQgbmV2ZXIgYmUgbW9kaWZpZWQgZGly
ZWN0bHkuCkluc3RlYWQgdG9vbHMvY29uZmlndXJlLmFjIHNob3VsZCBiZSBtb2RpZmllZCBhbmQg
YXV0b2dlbi5zaCByZXJ1biB0bwpnZW5lcmF0ZSBhIG5ldyBjb25maWd1cmUgc2NyaXB0LgoKPiDC
oGlmIHRlc3QgIiQ/IiAhPSAiMCIKPiDCoHRoZW4KPiDCoCDCoCBweXRob25fdmVyc2lvbj1gJFBZ
VEhPTiAtViAyPiYxYAo+Cj4KPgo+IEJlc3QgUmVnYXJkcywKPiDCoCDCoCBZb25namllIFJlbiDC
oChKYXkpCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4g
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Feb 24 20:54:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 20:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S129a-0005CL-1g; Fri, 24 Feb 2012 20:54:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S129Y-0005CG-8I
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 20:54:08 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330116840!14617224!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY3ODM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17764 invoked from network); 24 Feb 2012 20:54:02 -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; 24 Feb 2012 20:54: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 q1OKrsOZ017893
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 20:53:55 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
	q1OKrqCJ024090
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 20:53:53 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
	q1OKrpor032490; Fri, 24 Feb 2012 14:53:51 -0600
MIME-Version: 1.0
Message-ID: <f8264e57-9326-4794-8025-db8ff0f07380@default>
Date: Fri, 24 Feb 2012 12:53:40 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Olaf Hering
	<olaf@aepfle.de>, Tim Deegan <tim@xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F47F8E4.0017,ss=1,re=0.000,fgs=0
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, Kurt Hackel <kurt.hackel@oracle.com>,
	xen-devel@lists.xensource.com, Konrad Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the Xen memory overcommit (Satori and xenpaging) work getting
closer to the real world (and indeed one gating factor for a major
Xen release), I wonder if it is time to ask some very pointed
questions:

1) How is the capability and implementation similar or different
from VMware's?  And specifically I'm asking for hard information
relating to:

http://lwn.net/Articles/309155/ 
http://lwn.net/Articles/330589/ 

I am not a lawyer and my employer forbids me from reading the
related patent claims or speculating on any related issues, but
I will be strongly recommending a thorough legal review before
Oracle ships this code in any form that customers can enable.
(I'm hoping for an answer that would render a review moot.)

2) Assuming no legal issues, how is Xen memory overcommit different
or better than VMware's, which is known to have lots of issues
in the real world, such that few customers (outside of a handful
of domains such as VDI) enable it?  Or is this effort largely to
remove an item from the VMware sales team's differentiation list?
And a comparison vs Hyper-V and KVM would be interesting also.

3) Is there new evidence that a host-based-policy-driven memory
balancer works sufficiently well on one system, or for
multiple hosts, or for a data center?  It would be nice for
all Xen developers/vendors to understand the intended customer
(e.g. is it the desktop user running a handful of VMs running
known workloads?)

Perhaps this would be a better topic for the Xen Hack-a-thon...
sadly I won't be there and, anyway, I don't know if there will
be a quorum present of the Xen developers specifically working
on memory overcommit technology, so I thought it should be
brought up on-list beforehand.

Dan

Thanks... for the memory!
I really could use more / my throughput's on the floor
The balloon is flat / my swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to Bob Hope)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 20:54:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 20:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S129a-0005CL-1g; Fri, 24 Feb 2012 20:54:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S129Y-0005CG-8I
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 20:54:08 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330116840!14617224!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY3ODM1\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17764 invoked from network); 24 Feb 2012 20:54:02 -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; 24 Feb 2012 20:54: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 q1OKrsOZ017893
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 20:53:55 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
	q1OKrqCJ024090
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 20:53:53 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
	q1OKrpor032490; Fri, 24 Feb 2012 14:53:51 -0600
MIME-Version: 1.0
Message-ID: <f8264e57-9326-4794-8025-db8ff0f07380@default>
Date: Fri, 24 Feb 2012 12:53:40 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Olaf Hering
	<olaf@aepfle.de>, Tim Deegan <tim@xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090206.4F47F8E4.0017,ss=1,re=0.000,fgs=0
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, Kurt Hackel <kurt.hackel@oracle.com>,
	xen-devel@lists.xensource.com, Konrad Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the Xen memory overcommit (Satori and xenpaging) work getting
closer to the real world (and indeed one gating factor for a major
Xen release), I wonder if it is time to ask some very pointed
questions:

1) How is the capability and implementation similar or different
from VMware's?  And specifically I'm asking for hard information
relating to:

http://lwn.net/Articles/309155/ 
http://lwn.net/Articles/330589/ 

I am not a lawyer and my employer forbids me from reading the
related patent claims or speculating on any related issues, but
I will be strongly recommending a thorough legal review before
Oracle ships this code in any form that customers can enable.
(I'm hoping for an answer that would render a review moot.)

2) Assuming no legal issues, how is Xen memory overcommit different
or better than VMware's, which is known to have lots of issues
in the real world, such that few customers (outside of a handful
of domains such as VDI) enable it?  Or is this effort largely to
remove an item from the VMware sales team's differentiation list?
And a comparison vs Hyper-V and KVM would be interesting also.

3) Is there new evidence that a host-based-policy-driven memory
balancer works sufficiently well on one system, or for
multiple hosts, or for a data center?  It would be nice for
all Xen developers/vendors to understand the intended customer
(e.g. is it the desktop user running a handful of VMs running
known workloads?)

Perhaps this would be a better topic for the Xen Hack-a-thon...
sadly I won't be there and, anyway, I don't know if there will
be a quorum present of the Xen developers specifically working
on memory overcommit technology, so I thought it should be
brought up on-list beforehand.

Dan

Thanks... for the memory!
I really could use more / my throughput's on the floor
The balloon is flat / my swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to Bob Hope)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 21:43:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 21:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S12ui-00068u-Mu; Fri, 24 Feb 2012 21:42:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S12uh-00068Z-Bk
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 21:42:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330119764!16026921!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzU5NzM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzU5NzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5186 invoked from network); 24 Feb 2012 21:42:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Feb 2012 21:42:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330119764; l=2246;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=E43+nOMO6eAwlQMi8AUMiKRc0KU=;
	b=Ar15WiwdOy+BpzL+TmzanGwPKKRfcqvFy8IyoeR1dU9ZTqQK+iol/Tm8bO55dXji6N4
	djFNQBOLA2g2r9fU8m0UKd7MAMhXG95+WRKLPefOnnspCjZ19twsVY3gS7+DI75AAkoWj
	Hjec/h/czEm+uuIOI1wj5mY3JH2Nhpf+ppc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by post.strato.de (mrclete mo26) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t0555fo1OJllGi ;
	Fri, 24 Feb 2012 22:42:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2E96D18638; Fri, 24 Feb 2012 22:42:29 +0100 (CET)
Date: Fri, 24 Feb 2012 22:42:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120224214228.GA23473@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f8264e57-9326-4794-8025-db8ff0f07380@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, Dan Magenheimer wrote:

> With the Xen memory overcommit (Satori and xenpaging) work getting
> closer to the real world (and indeed one gating factor for a major
> Xen release), I wonder if it is time to ask some very pointed
> questions:

A few comments from me below. I just learned about Satori now, its not
clear to me how it is related to memory overcommit.

To me memory overcommit means swapping, which is what xenpaging does:
turn the whole guest gfn range into some sort of virtual memory,
transparent to the guest.

> 1) How is the capability and implementation similar or different
> from VMware's?  And specifically I'm asking for hard information
> relating to:
> 
> http://lwn.net/Articles/309155/ 
> http://lwn.net/Articles/330589/ 

KSM looks more like page sharing which also Xen can do to some degree.
I'm not familiar with the sharing code in Xen or Linux Kernel.

> 2) Assuming no legal issues, how is Xen memory overcommit different
> or better than VMware's, which is known to have lots of issues
> in the real world, such that few customers (outside of a handful
> of domains such as VDI) enable it?  Or is this effort largely to
> remove an item from the VMware sales team's differentiation list?
> And a comparison vs Hyper-V and KVM would be interesting also.

I have no idea what VMware provides to fill the memory overcommit
checkbox.

The Win8 preview I tested recently offers some sort of memory handling
for guests. So far I have not looked into that feature.

Since KVM guests are ordinary processes AFAIK they are most likely
victims of the Linux kernel process swapping (unless KVM mlocks the
gfns?). So KVM gets memory overcommit in the way xenpaging does it for
free.

> 3) Is there new evidence that a host-based-policy-driven memory
> balancer works sufficiently well on one system, or for
> multiple hosts, or for a data center?  It would be nice for
> all Xen developers/vendors to understand the intended customer
> (e.g. is it the desktop user running a handful of VMs running
> known workloads?)

xenpaging is the red emergency knob to free some host memory without
caring about the actual memory constraints within the paged guests.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 21:43:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 21:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S12ui-00068u-Mu; Fri, 24 Feb 2012 21:42:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S12uh-00068Z-Bk
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 21:42:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330119764!16026921!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzU5NzM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzU5NzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5186 invoked from network); 24 Feb 2012 21:42:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Feb 2012 21:42:44 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330119764; l=2246;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=E43+nOMO6eAwlQMi8AUMiKRc0KU=;
	b=Ar15WiwdOy+BpzL+TmzanGwPKKRfcqvFy8IyoeR1dU9ZTqQK+iol/Tm8bO55dXji6N4
	djFNQBOLA2g2r9fU8m0UKd7MAMhXG95+WRKLPefOnnspCjZ19twsVY3gS7+DI75AAkoWj
	Hjec/h/czEm+uuIOI1wj5mY3JH2Nhpf+ppc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by post.strato.de (mrclete mo26) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t0555fo1OJllGi ;
	Fri, 24 Feb 2012 22:42:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2E96D18638; Fri, 24 Feb 2012 22:42:29 +0100 (CET)
Date: Fri, 24 Feb 2012 22:42:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120224214228.GA23473@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f8264e57-9326-4794-8025-db8ff0f07380@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, Dan Magenheimer wrote:

> With the Xen memory overcommit (Satori and xenpaging) work getting
> closer to the real world (and indeed one gating factor for a major
> Xen release), I wonder if it is time to ask some very pointed
> questions:

A few comments from me below. I just learned about Satori now, its not
clear to me how it is related to memory overcommit.

To me memory overcommit means swapping, which is what xenpaging does:
turn the whole guest gfn range into some sort of virtual memory,
transparent to the guest.

> 1) How is the capability and implementation similar or different
> from VMware's?  And specifically I'm asking for hard information
> relating to:
> 
> http://lwn.net/Articles/309155/ 
> http://lwn.net/Articles/330589/ 

KSM looks more like page sharing which also Xen can do to some degree.
I'm not familiar with the sharing code in Xen or Linux Kernel.

> 2) Assuming no legal issues, how is Xen memory overcommit different
> or better than VMware's, which is known to have lots of issues
> in the real world, such that few customers (outside of a handful
> of domains such as VDI) enable it?  Or is this effort largely to
> remove an item from the VMware sales team's differentiation list?
> And a comparison vs Hyper-V and KVM would be interesting also.

I have no idea what VMware provides to fill the memory overcommit
checkbox.

The Win8 preview I tested recently offers some sort of memory handling
for guests. So far I have not looked into that feature.

Since KVM guests are ordinary processes AFAIK they are most likely
victims of the Linux kernel process swapping (unless KVM mlocks the
gfns?). So KVM gets memory overcommit in the way xenpaging does it for
free.

> 3) Is there new evidence that a host-based-policy-driven memory
> balancer works sufficiently well on one system, or for
> multiple hosts, or for a data center?  It would be nice for
> all Xen developers/vendors to understand the intended customer
> (e.g. is it the desktop user running a handful of VMs running
> known workloads?)

xenpaging is the red emergency knob to free some host memory without
caring about the actual memory constraints within the paged guests.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 22:20:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 22: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 1S13Ur-0007jF-Rm; Fri, 24 Feb 2012 22:20:13 +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 1S13Uq-0007j7-Rm
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 22:20:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330121979!58211032!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7448 invoked from network); 24 Feb 2012 22:19:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Feb 2012 22:19:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330122011; l=5190;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CI+LI92pfQvmCnXpQDE3ScPIa5A=;
	b=AG25D0RIHYYXE4+4QEtH1gx8Fbrk3tW8+V8bOz2MwB3e2LQsry3ll4lG5ZtzJVK9B1Q
	+f5vMHL1Y+SKlVyk0ev3FTkajuxD18AL+AvhPsHk1Bw1UIsVKlkOmzwH7AGvWNCPhwNg6
	S3K6V7iAUWarpAY3CbF2rT2PHEfzoYq+JEU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by smtp.strato.de (fruni mo49) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y0311fo1OJOd4W ;
	Fri, 24 Feb 2012 23:19:56 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 460F818638; Fri, 24 Feb 2012 23:19:54 +0100 (CET)
Date: Fri, 24 Feb 2012 23:19:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120224221954.GA23882@aepfle.de>
References: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<20120224153822.GA29117@aepfle.de>
	<1330101594.8557.222.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330101594.8557.222.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, Ian Campbell wrote:

> On Fri, 2012-02-24 at 15:38 +0000, Olaf Hering wrote:
> > On Fri, Feb 24, Ian Campbell wrote:
> > 
> > > Here is an updated version of my proposed interface which includes
> > > sharing, I think as you described (modulo the use of mem-paging-set
> > > where you said mem-set above).
> > > 
> > > I also included "mem-paging-set manual" as an explicit thing with an
> > > error on "mem-paging-set N" if you don't switch to manual mode. This
> > > might be too draconian -- I'm not wedded to it.
> > > 
> > > maxmem=X                        # maximum RAM the domain can ever see
> > > memory=M                        # current amount of RAM seen by the
> > > 				# domain
> > > paging=[off|on]                 # allow the amount of memory a guest 
> > >                                 # thinks it has to differ from the
> > >                                 # amount actually available to it (its
> > >                                 # "footprint")
> > > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> > >                                 # "footprint" for guests which do not
> > >                                 # voluntarily obey changes to memory=M 
> > > pagingdelay=60                  # amount of time to give a guest to 
> > >                                 # voluntarily comply before enforcing a 
> > >                                 # footprint
> > > pagesharing=[off|on]		# cause this guest to share pages with
> > > 				# other similarly enabled guests where
> > > 				# possible. Requires paging=on.
> > > pageextrapolocy=...		# controls what happens to extra pages 
> > > 				# gain via sharing (could be combined 
> > > 				# with pagesharing option:
> > > 				#	[off|policy|...])
> > > 
> > >         Open question -- does pagesharing=on require paging=on? I've
> > >         tried to specify things below such that it does not, but it
> > >         might simplify things to require this.
> > > 
> > > xl mem-set domain M
> > >         Sets the amount of RAM which the guest believes it has available
> > >         to M. The guest should arrange to use only that much RAM and
> > >         return the rest to the hypervisor (e.g. by using a balloon
> > >         driver). If the guest does not do so then the host may use
> > >         technical means to enforce the guest's footprint of M. The guest
> > >         may suffer a performance penalty for this enforcement.
> > > 
> > >         paging off:     set balloon target to M.
> > >         paging on:      set balloon target to M.
> > >                         if pagingauto:
> > >                                 wait delay IFF new target < old
> > >                                 set paging target to M
> > >                                 support -t <delay> to override default?
> > 
> > Instead of having two now config options pagingauto= and pagingdelay=,
> > what about 'xl mem-set -t <seconds>' to adjust the fixed internal value
> > pagingdelay=? Then '-t 0' could mean pagingauto=off, which means use
> > both ballooning and paging to reach the "footprint" M.
> 
> So you mean:
> 
> 	paging on:	set balloon target to M.
> 			if pagingdelay > 0:
> 				wait delay IFF new target < old
> 			else:
> 				pagingauto=off
> 			set paging target to M
> 
> or
> 
> 	paging on:	set balloon target to M.
> 			if pagingdelay > 0:
> 				wait delay IFF new target < old
> 				set paging target to M
> 			else:
> 				pagingauto=off
> 
> ? (the difference being whether or not we set the paging at all if delay
> == 0). 
> 
> I don't think I like overloading "-t 0" to also turn off auto mode like
> that. It makes it less explicit when you are disabling auto mode and
> entering "you have to know what you are doing" territory.

I misunderstood what pagingauto= is supposed to do.

So 'xl mem-set -t <sec> D N' could be:
        set balloon target to N
        if paging && pagingauto:
                if pagingdelay > 0:
                        wait pagingdelay
                set paging target to N

And -t 0 would just set the paging target right away so that the
footprint is reached fast, at the expense of concurent
ballooning+paging.

Is an extra pagingdelay= .cfg option is really helpful if the -t option
exists? I think it would be part of libxl then, and other libxl users
like libvirt may need to implement a knob similar to -t <sec> in their
mem-set implementation? Or should the actual waiting of <sec> be done in
libxl itself? Perhaps the pagingdelay= could be some sort of
recommendation for those who implement the "mem-set" function.
I'm just wondering where the actual waiting should be done, its not yet
part of the proposal. I think the actual memory change is an asynchron
event, so the xl monitoring process could do the actual work and the
mem-set command is just the trigger. Other libxl users would need their
own monitoring.

> With my original proposal you can do
> 	xl mem-set -t 0 D N
> and that will do both paging and ballooning enabled but will stay in
> auto mode, if that's what you want.
> 
> If you really want to also turn off auto mode then with my N-1th
> proposal you would do:
> 	xl mem-set -t 0 D N && xl mem-paging-set D N
> but that is more explicit about turning off auto mode. In my most recent
> proposal you'd have to do :
> 	xl mem-set -t 0 D N && xl mem-paging-set D manual && xl mem-paging-set D N
> which is a little _too_ explicit perhaps. I suspect the previous
> proposal was preferable in this regard?

About the 'xl mem-paging-set D manual' part I'm not sure yet.

Should 'xl mem-paging-set D N && xl mem-set D M' undo the paging target
from mem-paging-set? If yes, the manual mode is not needed. If no, then
a manual/auto mode is needed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 22:20:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 22: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 1S13Ur-0007jF-Rm; Fri, 24 Feb 2012 22:20:13 +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 1S13Uq-0007j7-Rm
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 22:20:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330121979!58211032!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjg5NTc=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7448 invoked from network); 24 Feb 2012 22:19:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Feb 2012 22:19:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330122011; l=5190;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=CI+LI92pfQvmCnXpQDE3ScPIa5A=;
	b=AG25D0RIHYYXE4+4QEtH1gx8Fbrk3tW8+V8bOz2MwB3e2LQsry3ll4lG5ZtzJVK9B1Q
	+f5vMHL1Y+SKlVyk0ev3FTkajuxD18AL+AvhPsHk1Bw1UIsVKlkOmzwH7AGvWNCPhwNg6
	S3K6V7iAUWarpAY3CbF2rT2PHEfzoYq+JEU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by smtp.strato.de (fruni mo49) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y0311fo1OJOd4W ;
	Fri, 24 Feb 2012 23:19:56 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 460F818638; Fri, 24 Feb 2012 23:19:54 +0100 (CET)
Date: Fri, 24 Feb 2012 23:19:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120224221954.GA23882@aepfle.de>
References: <CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<20120224153822.GA29117@aepfle.de>
	<1330101594.8557.222.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330101594.8557.222.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andres Lagarcavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, Ian Campbell wrote:

> On Fri, 2012-02-24 at 15:38 +0000, Olaf Hering wrote:
> > On Fri, Feb 24, Ian Campbell wrote:
> > 
> > > Here is an updated version of my proposed interface which includes
> > > sharing, I think as you described (modulo the use of mem-paging-set
> > > where you said mem-set above).
> > > 
> > > I also included "mem-paging-set manual" as an explicit thing with an
> > > error on "mem-paging-set N" if you don't switch to manual mode. This
> > > might be too draconian -- I'm not wedded to it.
> > > 
> > > maxmem=X                        # maximum RAM the domain can ever see
> > > memory=M                        # current amount of RAM seen by the
> > > 				# domain
> > > paging=[off|on]                 # allow the amount of memory a guest 
> > >                                 # thinks it has to differ from the
> > >                                 # amount actually available to it (its
> > >                                 # "footprint")
> > > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> > >                                 # "footprint" for guests which do not
> > >                                 # voluntarily obey changes to memory=M 
> > > pagingdelay=60                  # amount of time to give a guest to 
> > >                                 # voluntarily comply before enforcing a 
> > >                                 # footprint
> > > pagesharing=[off|on]		# cause this guest to share pages with
> > > 				# other similarly enabled guests where
> > > 				# possible. Requires paging=on.
> > > pageextrapolocy=...		# controls what happens to extra pages 
> > > 				# gain via sharing (could be combined 
> > > 				# with pagesharing option:
> > > 				#	[off|policy|...])
> > > 
> > >         Open question -- does pagesharing=on require paging=on? I've
> > >         tried to specify things below such that it does not, but it
> > >         might simplify things to require this.
> > > 
> > > xl mem-set domain M
> > >         Sets the amount of RAM which the guest believes it has available
> > >         to M. The guest should arrange to use only that much RAM and
> > >         return the rest to the hypervisor (e.g. by using a balloon
> > >         driver). If the guest does not do so then the host may use
> > >         technical means to enforce the guest's footprint of M. The guest
> > >         may suffer a performance penalty for this enforcement.
> > > 
> > >         paging off:     set balloon target to M.
> > >         paging on:      set balloon target to M.
> > >                         if pagingauto:
> > >                                 wait delay IFF new target < old
> > >                                 set paging target to M
> > >                                 support -t <delay> to override default?
> > 
> > Instead of having two now config options pagingauto= and pagingdelay=,
> > what about 'xl mem-set -t <seconds>' to adjust the fixed internal value
> > pagingdelay=? Then '-t 0' could mean pagingauto=off, which means use
> > both ballooning and paging to reach the "footprint" M.
> 
> So you mean:
> 
> 	paging on:	set balloon target to M.
> 			if pagingdelay > 0:
> 				wait delay IFF new target < old
> 			else:
> 				pagingauto=off
> 			set paging target to M
> 
> or
> 
> 	paging on:	set balloon target to M.
> 			if pagingdelay > 0:
> 				wait delay IFF new target < old
> 				set paging target to M
> 			else:
> 				pagingauto=off
> 
> ? (the difference being whether or not we set the paging at all if delay
> == 0). 
> 
> I don't think I like overloading "-t 0" to also turn off auto mode like
> that. It makes it less explicit when you are disabling auto mode and
> entering "you have to know what you are doing" territory.

I misunderstood what pagingauto= is supposed to do.

So 'xl mem-set -t <sec> D N' could be:
        set balloon target to N
        if paging && pagingauto:
                if pagingdelay > 0:
                        wait pagingdelay
                set paging target to N

And -t 0 would just set the paging target right away so that the
footprint is reached fast, at the expense of concurent
ballooning+paging.

Is an extra pagingdelay= .cfg option is really helpful if the -t option
exists? I think it would be part of libxl then, and other libxl users
like libvirt may need to implement a knob similar to -t <sec> in their
mem-set implementation? Or should the actual waiting of <sec> be done in
libxl itself? Perhaps the pagingdelay= could be some sort of
recommendation for those who implement the "mem-set" function.
I'm just wondering where the actual waiting should be done, its not yet
part of the proposal. I think the actual memory change is an asynchron
event, so the xl monitoring process could do the actual work and the
mem-set command is just the trigger. Other libxl users would need their
own monitoring.

> With my original proposal you can do
> 	xl mem-set -t 0 D N
> and that will do both paging and ballooning enabled but will stay in
> auto mode, if that's what you want.
> 
> If you really want to also turn off auto mode then with my N-1th
> proposal you would do:
> 	xl mem-set -t 0 D N && xl mem-paging-set D N
> but that is more explicit about turning off auto mode. In my most recent
> proposal you'd have to do :
> 	xl mem-set -t 0 D N && xl mem-paging-set D manual && xl mem-paging-set D N
> which is a little _too_ explicit perhaps. I suspect the previous
> proposal was preferable in this regard?

About the 'xl mem-paging-set D manual' part I'm not sure yet.

Should 'xl mem-paging-set D N && xl mem-set D M' undo the paging target
from mem-paging-set? If yes, the manual mode is not needed. If no, then
a manual/auto mode is needed.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 23:13:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 23:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S14Jn-0008MH-Tf; Fri, 24 Feb 2012 23:12: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 1S14Jm-0008MC-T6
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 23:12:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330125035!61201493!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY3MzU2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30880 invoked from network); 24 Feb 2012 23:10:36 -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 Feb 2012 23:10:36 -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 q1ONCfsN025076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 23:12: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
	q1ONCdoX009319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 23:12:40 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
	q1ONCdHx015930; Fri, 24 Feb 2012 17:12:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 15:12:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9C5FE4035E; Fri, 24 Feb 2012 18:09:16 -0500 (EST)
Date: Fri, 24 Feb 2012 18:09:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Message-ID: <20120224230916.GA26132@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
	<4F46E174.6040009@invisiblethingslab.com>
	<20120224055418.GA11780@phenom.dumpdata.com>
	<4F47B4D0.2030806@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F47B4D0.2030806@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F48196A.00BA,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 05:03:28PM +0100, Marek Marczykowski wrote:
> On 24.02.2012 06:54, Konrad Rzeszutek Wilk wrote:
> >>>>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> >>>>>>> to approach debugging it?
> >>>>>>>
> > .. snip..
> >> (the same hardware)
> >> On 2.6.38.3 xenlinux kernel after resume there is screen content from before
> >> suspend, power led light constantly (as it should), but system is
> >> irresponsible (no capslock led, no reaction to sysrq, network etc).
> >> On 3.x with your patches system goes into S3, but on resume is even worse - no
> >> screen content at all (and no backlight) and also irresponsible, power led
> >> still blinking. As 3.x tried:
> >>  - your devel/acpi-s3.v7 branch directly
> >>  - 3.2.7 merged with devel/acpi-s3.v7
> >>  - 3.3-rc4 with devel/acpi-s3.v7
> > 
> > OK. That is weird - it worked for me last time. One thing at at time then -
> > try doing this from text-mode, so no graphic mode involved. For that you might
> > need to disable your i915 driver altogether. Then just run 'pm-suspend' and
> > see where it stops.
> > 
> > The next part is... Wait a minute, this reminds me of something I encountered
> > with a SandyBrige i2100 - the suspend would work, but resume would get stuck.
> > 
> > The issue was with the hypervisor and if I had the acpi-cpufreq drivers loaded
> > it resumed just fine. If I didn't - so hypervisor had no idea about C states or
> > P states, it would be stuck in the default_idle and never come back.
> > 
> > So you might want for fun try also using the stable/processor-passthru.v5 and
> > build it with CONFIG_XEN_PROCESSOR_PASSTHRU=y.
> 
> Looks much better. At least for few suspend/resume it works. Thanks!
> And: when is it planned to upstream above patches (acpi-s3 and
> processor-passthru)?

Been doing it, but haven't gotten the required Acks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 23:13:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 23:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S14Jn-0008MH-Tf; Fri, 24 Feb 2012 23:12: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 1S14Jm-0008MC-T6
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 23:12:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330125035!61201493!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY3MzU2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30880 invoked from network); 24 Feb 2012 23:10:36 -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 Feb 2012 23:10:36 -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 q1ONCfsN025076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 23:12: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
	q1ONCdoX009319
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 23:12:40 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
	q1ONCdHx015930; Fri, 24 Feb 2012 17:12:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 15:12:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9C5FE4035E; Fri, 24 Feb 2012 18:09:16 -0500 (EST)
Date: Fri, 24 Feb 2012 18:09:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Message-ID: <20120224230916.GA26132@phenom.dumpdata.com>
References: <4F460354.7080907@invisiblethingslab.com>
	<20120223141827.GC23963@phenom.dumpdata.com>
	<20120223173146.GA22922@phenom.dumpdata.com>
	<4F4679D1.3000806@invisiblethingslab.com>
	<20120223180313.GC22574@phenom.dumpdata.com>
	<4F46E174.6040009@invisiblethingslab.com>
	<20120224055418.GA11780@phenom.dumpdata.com>
	<4F47B4D0.2030806@invisiblethingslab.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F47B4D0.2030806@invisiblethingslab.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F48196A.00BA,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] Resume not working on 2nd gen Core i5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 05:03:28PM +0100, Marek Marczykowski wrote:
> On 24.02.2012 06:54, Konrad Rzeszutek Wilk wrote:
> >>>>>>> Does anybody have a similar problem on 2nd Gen Core i5? Any advises how
> >>>>>>> to approach debugging it?
> >>>>>>>
> > .. snip..
> >> (the same hardware)
> >> On 2.6.38.3 xenlinux kernel after resume there is screen content from before
> >> suspend, power led light constantly (as it should), but system is
> >> irresponsible (no capslock led, no reaction to sysrq, network etc).
> >> On 3.x with your patches system goes into S3, but on resume is even worse - no
> >> screen content at all (and no backlight) and also irresponsible, power led
> >> still blinking. As 3.x tried:
> >>  - your devel/acpi-s3.v7 branch directly
> >>  - 3.2.7 merged with devel/acpi-s3.v7
> >>  - 3.3-rc4 with devel/acpi-s3.v7
> > 
> > OK. That is weird - it worked for me last time. One thing at at time then -
> > try doing this from text-mode, so no graphic mode involved. For that you might
> > need to disable your i915 driver altogether. Then just run 'pm-suspend' and
> > see where it stops.
> > 
> > The next part is... Wait a minute, this reminds me of something I encountered
> > with a SandyBrige i2100 - the suspend would work, but resume would get stuck.
> > 
> > The issue was with the hypervisor and if I had the acpi-cpufreq drivers loaded
> > it resumed just fine. If I didn't - so hypervisor had no idea about C states or
> > P states, it would be stuck in the default_idle and never come back.
> > 
> > So you might want for fun try also using the stable/processor-passthru.v5 and
> > build it with CONFIG_XEN_PROCESSOR_PASSTHRU=y.
> 
> Looks much better. At least for few suspend/resume it works. Thanks!
> And: when is it planned to upstream above patches (acpi-s3 and
> processor-passthru)?

Been doing it, but haven't gotten the required Acks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 23:57:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 23: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 1S150e-0000AW-C8; Fri, 24 Feb 2012 23:57:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S150c-0000AR-H2
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 23:57:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330127818!13249455!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY3MzU2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29640 invoked from network); 24 Feb 2012 23:57:00 -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; 24 Feb 2012 23:57: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 q1ONtrmc016423
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 23: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
	q1ONtpfu015198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 23:55:52 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
	q1ONtpi3001915; Fri, 24 Feb 2012 17:55:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 15:55:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7FE634035E; Fri, 24 Feb 2012 18:52:28 -0500 (EST)
Date: Fri, 24 Feb 2012 18:52:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120224235228.GA26913@phenom.dumpdata.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
	<4F4775410200007800074992@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4775410200007800074992@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F48238A.0077,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and
 MWAIT_LEAF if hypervisor OKs 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

> > +DEFINE_GUEST_HANDLE(uint32_t);
> 
> Do you really need to introduce (step by step) handles for all those
> uintNN_t types in a way different from Xen's
> (__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t))?

Oh, no. Good eye - I will change it be uint32.

> 
> Looks good to me otherwise.

Thank you for time!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 24 23:57:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 24 Feb 2012 23: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 1S150e-0000AW-C8; Fri, 24 Feb 2012 23:57:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S150c-0000AR-H2
	for xen-devel@lists.xensource.com; Fri, 24 Feb 2012 23:57:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330127818!13249455!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY3MzU2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29640 invoked from network); 24 Feb 2012 23:57:00 -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; 24 Feb 2012 23:57: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 q1ONtrmc016423
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 24 Feb 2012 23: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
	q1ONtpfu015198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Feb 2012 23:55:52 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
	q1ONtpi3001915; Fri, 24 Feb 2012 17:55:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 15:55:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7FE634035E; Fri, 24 Feb 2012 18:52:28 -0500 (EST)
Date: Fri, 24 Feb 2012 18:52:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120224235228.GA26913@phenom.dumpdata.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
	<4F4775410200007800074992@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4775410200007800074992@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F48238A.0077,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and
 MWAIT_LEAF if hypervisor OKs 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

> > +DEFINE_GUEST_HANDLE(uint32_t);
> 
> Do you really need to introduce (step by step) handles for all those
> uintNN_t types in a way different from Xen's
> (__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t))?

Oh, no. Good eye - I will change it be uint32.

> 
> Looks good to me otherwise.

Thank you for time!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 00:25:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 00:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S15Ro-0000r4-Rj; Sat, 25 Feb 2012 00:25:12 +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 1S15Rn-0000qw-G4
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 00:25:11 +0000
Received: from [85.158.139.83:31938] by server-5.bemta-5.messagelabs.com id
	8D/E5-13566-66A284F4; Sat, 25 Feb 2012 00:25:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330129508!5312679!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NjY0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10884 invoked from network); 25 Feb 2012 00:25:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2012 00:25:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1P0P2hm001070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 25 Feb 2012 00:25:03 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
	q1P0P0AT009879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 25 Feb 2012 00:25:01 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1P0OxX9017046; Fri, 24 Feb 2012 18:24:59 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 16:24:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 277D34035E; Fri, 24 Feb 2012 19:21:36 -0500 (EST)
Date: Fri, 24 Feb 2012 19:21:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, davej@redhat.com, cpufreq@vger.kernel.org
Message-ID: <20120225002136.GB26913@phenom.dumpdata.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<4F47733E020000780007497D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F47733E020000780007497D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F482A60.009F,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 Fri, Feb 24, 2012 at 10:23:42AM +0000, Jan Beulich wrote:
> >>> On 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > This module (processor-passthru)  collects the information that the cpufreq
> > drivers and the ACPI processor code save in the 'struct acpi_processor' and
> > then uploads it to the hypervisor.
> 
> Thus looks conceptually wrong to me - there shouldn't be a need for a
> CPUFreq driver to be loaded in Dom0 (or your module should masquerade
> as the one and only suitable one).

So before your email I had been thinking that b/c of the cpuidle rework
by Len it meant that when the cpufreq drivers are active - they would be started
from the cpu_idle call - and since  cpu_idle call ends up being default_idle on
pvops (which calls safe_halt) that would be fine. This is the work that Len did
"cpuidle: replace xen access to x86 pm_idle and default_idle" and
"cpuidle: stop depending on pm_idle" 

But cpufreq != cpuidle != cpufreq governor, and they all are run by different rules.
The ondemand cpufreq governor for example runs a timer and calls the appropiate cpufreq
driver. So with these patches I posted we end up with a cpufreq driver in the kernel
and in Xen hypervisor - both of them trying to change Pstates. Not good (to be fair,
if powernow-k8/acpi-cpufreq would try it via WRMSR -  those would up being trapped and
ignored by the hypervisor. I am not sure about the outw though).

The pre-RFC version of this posted driver implemented a cpufreq governor that was
nop and for future work was going to make a hypercall to get the true cpufreq value
to report properly in /proc/cpuinfo - but I hadn't figured out a way to make it be
the default one dynamically.

Perhaps having xencommons do 
echo "xen" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

And s/processor-passthru/cpufreq-xen/ would do it? That would eliminate the [performance,
ondemand,powersave,etc] cpufreq governors from calling into the cpufreq drivers to alter P-states.

Let me CC Dave Jones and the cpufreq mailing list - perhaps they might have
some ideas?
[The patch is http://lwn.net/Articles/483668/]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 00:25:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 00:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S15Ro-0000r4-Rj; Sat, 25 Feb 2012 00:25:12 +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 1S15Rn-0000qw-G4
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 00:25:11 +0000
Received: from [85.158.139.83:31938] by server-5.bemta-5.messagelabs.com id
	8D/E5-13566-66A284F4; Sat, 25 Feb 2012 00:25:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330129508!5312679!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2NjY0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10884 invoked from network); 25 Feb 2012 00:25:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2012 00:25:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1P0P2hm001070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 25 Feb 2012 00:25:03 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
	q1P0P0AT009879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 25 Feb 2012 00:25:01 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1P0OxX9017046; Fri, 24 Feb 2012 18:24:59 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 24 Feb 2012 16:24:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 277D34035E; Fri, 24 Feb 2012 19:21:36 -0500 (EST)
Date: Fri, 24 Feb 2012 19:21:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, davej@redhat.com, cpufreq@vger.kernel.org
Message-ID: <20120225002136.GB26913@phenom.dumpdata.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<4F47733E020000780007497D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F47733E020000780007497D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F482A60.009F,ss=1,re=0.000,fgs=0
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 Fri, Feb 24, 2012 at 10:23:42AM +0000, Jan Beulich wrote:
> >>> On 23.02.12 at 23:31, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > This module (processor-passthru)  collects the information that the cpufreq
> > drivers and the ACPI processor code save in the 'struct acpi_processor' and
> > then uploads it to the hypervisor.
> 
> Thus looks conceptually wrong to me - there shouldn't be a need for a
> CPUFreq driver to be loaded in Dom0 (or your module should masquerade
> as the one and only suitable one).

So before your email I had been thinking that b/c of the cpuidle rework
by Len it meant that when the cpufreq drivers are active - they would be started
from the cpu_idle call - and since  cpu_idle call ends up being default_idle on
pvops (which calls safe_halt) that would be fine. This is the work that Len did
"cpuidle: replace xen access to x86 pm_idle and default_idle" and
"cpuidle: stop depending on pm_idle" 

But cpufreq != cpuidle != cpufreq governor, and they all are run by different rules.
The ondemand cpufreq governor for example runs a timer and calls the appropiate cpufreq
driver. So with these patches I posted we end up with a cpufreq driver in the kernel
and in Xen hypervisor - both of them trying to change Pstates. Not good (to be fair,
if powernow-k8/acpi-cpufreq would try it via WRMSR -  those would up being trapped and
ignored by the hypervisor. I am not sure about the outw though).

The pre-RFC version of this posted driver implemented a cpufreq governor that was
nop and for future work was going to make a hypercall to get the true cpufreq value
to report properly in /proc/cpuinfo - but I hadn't figured out a way to make it be
the default one dynamically.

Perhaps having xencommons do 
echo "xen" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

And s/processor-passthru/cpufreq-xen/ would do it? That would eliminate the [performance,
ondemand,powersave,etc] cpufreq governors from calling into the cpufreq drivers to alter P-states.

Let me CC Dave Jones and the cpufreq mailing list - perhaps they might have
some ideas?
[The patch is http://lwn.net/Articles/483668/]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 00:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 00:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S15wE-00014K-DI; Sat, 25 Feb 2012 00:56: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 1S15wC-00014F-K7
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 00:56:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330131343!62051814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5335 invoked from network); 25 Feb 2012 00:55: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;
	25 Feb 2012 00:55:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,479,1325462400"; d="scan'208";a="10931242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 00:56:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 00:56:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S15wA-0005v0-Oo;
	Sat, 25 Feb 2012 00:56:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S15wA-00053m-NU;
	Sat, 25 Feb 2012 00:56:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S15wA-00053m-NU@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 00:56:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-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

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12043 fail [host=potato-beetle] / 12031 ok.
Failure / basis pass flights: 12043 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1
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 59 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12043 (fail), for basis failure
 Repro found: flight 12044 (pass), for basis pass
 Repro found: flight 12054 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12051 (pass), for last pass
 Result found: flight 12052 (fail), for first failure
 Repro found: flight 12055 (pass), for last pass
 Repro found: flight 12057 (fail), for first failure
 Repro found: flight 12059 (pass), for last pass
 Repro found: flight 12060 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
12060: ALL FAIL

flight 12060 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Feb 25 00:57:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 00:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S15wE-00014K-DI; Sat, 25 Feb 2012 00:56: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 1S15wC-00014F-K7
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 00:56:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330131343!62051814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5335 invoked from network); 25 Feb 2012 00:55: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;
	25 Feb 2012 00:55:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,479,1325462400"; d="scan'208";a="10931242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 00:56:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 00:56:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S15wA-0005v0-Oo;
	Sat, 25 Feb 2012 00:56:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S15wA-00053m-NU;
	Sat, 25 Feb 2012 00:56:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S15wA-00053m-NU@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 00:56:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-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

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12043 fail [host=potato-beetle] / 12031 ok.
Failure / basis pass flights: 12043 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1
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 59 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12043 (fail), for basis failure
 Repro found: flight 12044 (pass), for basis pass
 Repro found: flight 12054 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12051 (pass), for last pass
 Result found: flight 12052 (fail), for first failure
 Repro found: flight 12055 (pass), for last pass
 Repro found: flight 12057 (fail), for first failure
 Repro found: flight 12059 (pass), for last pass
 Repro found: flight 12060 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
12060: ALL FAIL

flight 12060 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Feb 25 01:20:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 01:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S16Ii-0005Gk-0t; Sat, 25 Feb 2012 01:19: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 1S16Ig-0005Gf-B5
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 01:19:50 +0000
Received: from [85.158.139.83:47252] by server-6.bemta-5.messagelabs.com id
	CC/74-27305-537384F4; Sat, 25 Feb 2012 01:19:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330132788!16587595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25736 invoked from network); 25 Feb 2012 01:19:48 -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;
	25 Feb 2012 01:19:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,479,1325462400"; d="scan'208";a="10931313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 01:19:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 01:19:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S16Id-0006DO-JL;
	Sat, 25 Feb 2012 01:19:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S16Id-0000KJ-Ec;
	Sat, 25 Feb 2012 01:19:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12053-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 01:19:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12053: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12053 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12053/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 01:20:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 01:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S16Ii-0005Gk-0t; Sat, 25 Feb 2012 01:19: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 1S16Ig-0005Gf-B5
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 01:19:50 +0000
Received: from [85.158.139.83:47252] by server-6.bemta-5.messagelabs.com id
	CC/74-27305-537384F4; Sat, 25 Feb 2012 01:19:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330132788!16587595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25736 invoked from network); 25 Feb 2012 01:19:48 -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;
	25 Feb 2012 01:19:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,479,1325462400"; d="scan'208";a="10931313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 01:19:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 01:19:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S16Id-0006DO-JL;
	Sat, 25 Feb 2012 01:19:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S16Id-0000KJ-Ec;
	Sat, 25 Feb 2012 01:19:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12053-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 01:19:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12053: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12053 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12053/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         5 xen-boot                  fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 03:07:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S17yE-00067X-4T; Sat, 25 Feb 2012 03:06:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1S17yC-00067P-UU
	for xen-devel@lists.xen.org; Sat, 25 Feb 2012 03:06:49 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330139201!16834431!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM3Mzkw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18060 invoked from network); 25 Feb 2012 03:06:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-216.messagelabs.com with SMTP;
	25 Feb 2012 03:06:42 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Feb 2012 19:06:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110621104"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 24 Feb 2012 19:06:39 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sat, 25 Feb 2012 11:06:38 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 11:06:38 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sat, 25 Feb 2012 11:06:36 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
Thread-Topic: [Xen-devel] [PATCH] tools: fix python version checking issue
	in configuration
Thread-Index: AczzEsFxFaVasOuPRgurzqJpZDOUDv//uDuA//8JQGA=
Date: Sat, 25 Feb 2012 03:06:36 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100510A7@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
	<CAPLaKK7HLJsiDq=UmW+_f-ea9ZfzaG_y0vtFcRuH5F4GvQWejg@mail.gmail.com>
In-Reply-To: <CAPLaKK7HLJsiDq=UmW+_f-ea9ZfzaG_y0vtFcRuH5F4GvQWejg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: fix python version checking issue in
 configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiByb3lnZXJAZ21haWwuY29tIFtt
YWlsdG86cm95Z2VyQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvZ2VyDQo+IFBhdSBNb25uw6kN
Cj4gU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDI1LCAyMDEyIDQ6MjIgQU0NCj4gVG86IFJlbiwg
WW9uZ2ppZQ0KPiBDYzogeGVuLWRldmVsQGxpc3RzLnhlbi5vcmc7IGlhbi5qYWNrc29uQGNpdHJp
eC5jb20NCj4gU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIFtQQVRDSF0gdG9vbHM6IGZpeCBweXRo
b24gdmVyc2lvbiBjaGVja2luZyBpc3N1ZSBpbg0KPiBjb25maWd1cmF0aW9uDQo+IA0KPiAyMDEy
LzIvMjQgUmVuLCBZb25namllIDx5b25namllLnJlbkBpbnRlbC5jb20+Og0KPiA+IEV2ZW4gaWYg
cHl0aG9uIHZlcnNpb24gaXMgMi40LjMgd2hpY2ggaXMgbmV3ZXIgdGhhbiB0aGUgcmVxdWlyZWQg
dmVyc2lvbg0KPiAyLjMsIHRoZSBjb25maWd1cmUgc2NyaXB0IHN0aWxsIHJhaXNlcyBhIHZlcnNp
b24gaXNzdWUuDQo+ID4gSSB0ZXN0ZWQgbXkgcGF0Y2ggd2l0aCBweXRob24gMi42LjYgYW5kIDIu
NC4zLiBJdCB3aWxsIGZpeCBhIHN5bnRheCBlcnJvcg0KPiBsaWtlIHRoZSBmb2xsb3dpbmcuDQo+
ID4gY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gVHJhY2ViYWNrIChtb3N0
IHJlY2VudCBjYWxsIGxhc3QpOg0KPiA+IMKgRmlsZSAiPHN0cmluZz4iLCBsaW5lIDEsIGluID8N
Cj4gPiBUeXBlRXJyb3I6ICdzdHInIG9iamVjdCBpcyBub3QgY2FsbGFibGUNCj4gPiBubw0KPiA+
IGNvbmZpZ3VyZTogZXJyb3I6IFB5dGhvbiAyLjQuMyBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVp
cmVkIHZlcnNpb24gaXMgMi4zDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBZb25namllIFJlbiA8
eW9uZ2ppZS5yZW5AaW50ZWwuY29tPg0KPiA+IC0tDQo+ID4NCj4gPiB0b29scy9jb25maWd1cmUg
fCDCoCDCoDIgKy0NCj4gPiDCoDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxl
dGlvbigtKQ0KPiA+DQo+ID4gZGlmZiAtciBhNGQ5M2QwZTBkZjIgdG9vbHMvY29uZmlndXJlDQo+
ID4gLS0tIGEvdG9vbHMvY29uZmlndXJlIMKgIFdlZCBGZWIgMjIgMTQ6MzM6MjQgMjAxMiArMDAw
MA0KPiA+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZSDCoCBGcmkgRmViIDI0IDIxOjE4OjMxIDIwMTIg
KzA4MDANCj4gPiBAQCAtNjI5Myw3ICs2MjkzLDcgQEANCj4gPiDCoGZpDQo+ID4gwqAgwqAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgcHl0aG9u
DQo+IHZlcnNpb24gPj0gMi4zICIgPiY1DQo+ID4gwqAkYXNfZWNob19uICJjaGVja2luZyBmb3Ig
cHl0aG9uIHZlcnNpb24gPj0gMi4zIC4uLiAiID4mNjsgfQ0KPiA+IC1gJFBZVEhPTiAtYyAnaW1w
b3J0IHN5czsgZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2ANCj4gPiAr
YCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7IHN5cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8g
PCAoMiwgMykiKSknYA0KPiANCj4gVGhpcyBpcyB3cm9uZywgdG9vbHMvY29uZmlndXJlIHNob3Vs
ZCBuZXZlciBiZSBtb2RpZmllZCBkaXJlY3RseS4NCj4gSW5zdGVhZCB0b29scy9jb25maWd1cmUu
YWMgc2hvdWxkIGJlIG1vZGlmaWVkIGFuZCBhdXRvZ2VuLnNoIHJlcnVuIHRvDQo+IGdlbmVyYXRl
IGEgbmV3IGNvbmZpZ3VyZSBzY3JpcHQuDQo+IA0KVGhhbmtzIGZvciB5b3VyIHBvaW50LiBJJ2xs
IHJlLXNlbmQgYW5vdGhlciBwYXRjaC4NCj4gPiDCoGlmIHRlc3QgIiQ/IiAhPSAiMCINCj4gPiDC
oHRoZW4NCj4gPiDCoCDCoCBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYA0KPiA+DQo+
ID4NCj4gPg0KPiA+IEJlc3QgUmVnYXJkcywNCj4gPiDCoCDCoCBZb25namllIFJlbiDCoChKYXkp
DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gWGVuLWRldmVsIG1haWxpbmcgbGlzdA0KPiA+IFhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnDQo+ID4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sat Feb 25 03:07:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 03:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S17yE-00067X-4T; Sat, 25 Feb 2012 03:06:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1S17yC-00067P-UU
	for xen-devel@lists.xen.org; Sat, 25 Feb 2012 03:06:49 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330139201!16834431!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM3Mzkw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18060 invoked from network); 25 Feb 2012 03:06:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-216.messagelabs.com with SMTP;
	25 Feb 2012 03:06:42 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Feb 2012 19:06:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110621104"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 24 Feb 2012 19:06:39 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sat, 25 Feb 2012 11:06:38 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 11:06:38 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Sat, 25 Feb 2012 11:06:36 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
Thread-Topic: [Xen-devel] [PATCH] tools: fix python version checking issue
	in configuration
Thread-Index: AczzEsFxFaVasOuPRgurzqJpZDOUDv//uDuA//8JQGA=
Date: Sat, 25 Feb 2012 03:06:36 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100510A7@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A10050F11@SHSMSX101.ccr.corp.intel.com>
	<CAPLaKK7HLJsiDq=UmW+_f-ea9ZfzaG_y0vtFcRuH5F4GvQWejg@mail.gmail.com>
In-Reply-To: <CAPLaKK7HLJsiDq=UmW+_f-ea9ZfzaG_y0vtFcRuH5F4GvQWejg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: fix python version checking issue in
 configuration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiByb3lnZXJAZ21haWwuY29tIFtt
YWlsdG86cm95Z2VyQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvZ2VyDQo+IFBhdSBNb25uw6kN
Cj4gU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDI1LCAyMDEyIDQ6MjIgQU0NCj4gVG86IFJlbiwg
WW9uZ2ppZQ0KPiBDYzogeGVuLWRldmVsQGxpc3RzLnhlbi5vcmc7IGlhbi5qYWNrc29uQGNpdHJp
eC5jb20NCj4gU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIFtQQVRDSF0gdG9vbHM6IGZpeCBweXRo
b24gdmVyc2lvbiBjaGVja2luZyBpc3N1ZSBpbg0KPiBjb25maWd1cmF0aW9uDQo+IA0KPiAyMDEy
LzIvMjQgUmVuLCBZb25namllIDx5b25namllLnJlbkBpbnRlbC5jb20+Og0KPiA+IEV2ZW4gaWYg
cHl0aG9uIHZlcnNpb24gaXMgMi40LjMgd2hpY2ggaXMgbmV3ZXIgdGhhbiB0aGUgcmVxdWlyZWQg
dmVyc2lvbg0KPiAyLjMsIHRoZSBjb25maWd1cmUgc2NyaXB0IHN0aWxsIHJhaXNlcyBhIHZlcnNp
b24gaXNzdWUuDQo+ID4gSSB0ZXN0ZWQgbXkgcGF0Y2ggd2l0aCBweXRob24gMi42LjYgYW5kIDIu
NC4zLiBJdCB3aWxsIGZpeCBhIHN5bnRheCBlcnJvcg0KPiBsaWtlIHRoZSBmb2xsb3dpbmcuDQo+
ID4gY2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gVHJhY2ViYWNrIChtb3N0
IHJlY2VudCBjYWxsIGxhc3QpOg0KPiA+IMKgRmlsZSAiPHN0cmluZz4iLCBsaW5lIDEsIGluID8N
Cj4gPiBUeXBlRXJyb3I6ICdzdHInIG9iamVjdCBpcyBub3QgY2FsbGFibGUNCj4gPiBubw0KPiA+
IGNvbmZpZ3VyZTogZXJyb3I6IFB5dGhvbiAyLjQuMyBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVp
cmVkIHZlcnNpb24gaXMgMi4zDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBZb25namllIFJlbiA8
eW9uZ2ppZS5yZW5AaW50ZWwuY29tPg0KPiA+IC0tDQo+ID4NCj4gPiB0b29scy9jb25maWd1cmUg
fCDCoCDCoDIgKy0NCj4gPiDCoDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxl
dGlvbigtKQ0KPiA+DQo+ID4gZGlmZiAtciBhNGQ5M2QwZTBkZjIgdG9vbHMvY29uZmlndXJlDQo+
ID4gLS0tIGEvdG9vbHMvY29uZmlndXJlIMKgIFdlZCBGZWIgMjIgMTQ6MzM6MjQgMjAxMiArMDAw
MA0KPiA+ICsrKyBiL3Rvb2xzL2NvbmZpZ3VyZSDCoCBGcmkgRmViIDI0IDIxOjE4OjMxIDIwMTIg
KzA4MDANCj4gPiBAQCAtNjI5Myw3ICs2MjkzLDcgQEANCj4gPiDCoGZpDQo+ID4gwqAgwqAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgcHl0aG9u
DQo+IHZlcnNpb24gPj0gMi4zICIgPiY1DQo+ID4gwqAkYXNfZWNob19uICJjaGVja2luZyBmb3Ig
cHl0aG9uIHZlcnNpb24gPj0gMi4zIC4uLiAiID4mNjsgfQ0KPiA+IC1gJFBZVEhPTiAtYyAnaW1w
b3J0IHN5czsgZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikpJ2ANCj4gPiAr
YCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7IHN5cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8g
PCAoMiwgMykiKSknYA0KPiANCj4gVGhpcyBpcyB3cm9uZywgdG9vbHMvY29uZmlndXJlIHNob3Vs
ZCBuZXZlciBiZSBtb2RpZmllZCBkaXJlY3RseS4NCj4gSW5zdGVhZCB0b29scy9jb25maWd1cmUu
YWMgc2hvdWxkIGJlIG1vZGlmaWVkIGFuZCBhdXRvZ2VuLnNoIHJlcnVuIHRvDQo+IGdlbmVyYXRl
IGEgbmV3IGNvbmZpZ3VyZSBzY3JpcHQuDQo+IA0KVGhhbmtzIGZvciB5b3VyIHBvaW50LiBJJ2xs
IHJlLXNlbmQgYW5vdGhlciBwYXRjaC4NCj4gPiDCoGlmIHRlc3QgIiQ/IiAhPSAiMCINCj4gPiDC
oHRoZW4NCj4gPiDCoCDCoCBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYA0KPiA+DQo+
ID4NCj4gPg0KPiA+IEJlc3QgUmVnYXJkcywNCj4gPiDCoCDCoCBZb25namllIFJlbiDCoChKYXkp
DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gWGVuLWRldmVsIG1haWxpbmcgbGlzdA0KPiA+IFhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnDQo+ID4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sat Feb 25 03:21:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 03:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S18Ba-0006KY-Md; Sat, 25 Feb 2012 03:20:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1S18BY-0006KT-ND
	for xen-devel@lists.xen.org; Sat, 25 Feb 2012 03:20:36 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330140029!9633961!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5Mzk5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17795 invoked from network); 25 Feb 2012 03:20:30 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-21.messagelabs.com with SMTP;
	25 Feb 2012 03:20:30 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2012 19:20:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="114762876"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by orsmga002.jf.intel.com with ESMTP; 24 Feb 2012 19:19:27 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 11:19:26 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 11:19:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sat, 25 Feb 2012 11:19:25 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH] tools: fix python version checking issue
Thread-Index: AczzbDMU3sd0cq9YTNqg+XVM/s7p0w==
Date: Sat, 25 Feb 2012 03:19:25 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100510C6@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: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	"ian.jackson@citrix.com" <ian.jackson@citrix.com>
Subject: [Xen-devel] [PATCH] tools: fix python version checking 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

Even if python version is 2.4.3 which is newer than the required version 2.3, the configure script still raises a version issue.
I tested my patch with python 2.6.6 and 2.4.3. It will fix a syntax error like the following.
checking for python version >= 2.3 ... Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: 'str' object is not callable
no
configure: error: Python 2.4.3 is too old, minimum required version is 2.3

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
--

tools/m4/python_version.m4 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -r a4d93d0e0df2 tools/m4/python_version.m4
--- a/tools/m4/python_version.m4        Wed Feb 22 14:33:24 2012 +0000
+++ b/tools/m4/python_version.m4        Fri Feb 24 22:08:53 2012 -0500
@@ -1,6 +1,6 @@
 AC_DEFUN([AX_CHECK_PYTHON_VERSION],
 [AC_MSG_CHECKING([for python version >= $1.$2 ])
-`$PYTHON -c 'import sys; exit(eval("sys.version_info < ($1, $2)"))'`
+`$PYTHON -c 'import sys; sys.exit(eval("sys.version_info < ($1, $2)"))'`
 if test "$?" != "0"
 then
     python_version=`$PYTHON -V 2>&1`


Best Regards,
     Yongjie Ren  (Jay)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 03:21:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 03:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S18Ba-0006KY-Md; Sat, 25 Feb 2012 03:20:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1S18BY-0006KT-ND
	for xen-devel@lists.xen.org; Sat, 25 Feb 2012 03:20:36 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330140029!9633961!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE5Mzk5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17795 invoked from network); 25 Feb 2012 03:20:30 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-21.messagelabs.com with SMTP;
	25 Feb 2012 03:20:30 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2012 19:20:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="114762876"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by orsmga002.jf.intel.com with ESMTP; 24 Feb 2012 19:19:27 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 11:19:26 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 25 Feb 2012 11:19:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sat, 25 Feb 2012 11:19:25 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [PATCH] tools: fix python version checking issue
Thread-Index: AczzbDMU3sd0cq9YTNqg+XVM/s7p0w==
Date: Sat, 25 Feb 2012 03:19:25 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100510C6@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: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	"ian.jackson@citrix.com" <ian.jackson@citrix.com>
Subject: [Xen-devel] [PATCH] tools: fix python version checking 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

Even if python version is 2.4.3 which is newer than the required version 2.3, the configure script still raises a version issue.
I tested my patch with python 2.6.6 and 2.4.3. It will fix a syntax error like the following.
checking for python version >= 2.3 ... Traceback (most recent call last):
  File "<string>", line 1, in ?
TypeError: 'str' object is not callable
no
configure: error: Python 2.4.3 is too old, minimum required version is 2.3

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
--

tools/m4/python_version.m4 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -r a4d93d0e0df2 tools/m4/python_version.m4
--- a/tools/m4/python_version.m4        Wed Feb 22 14:33:24 2012 +0000
+++ b/tools/m4/python_version.m4        Fri Feb 24 22:08:53 2012 -0500
@@ -1,6 +1,6 @@
 AC_DEFUN([AX_CHECK_PYTHON_VERSION],
 [AC_MSG_CHECKING([for python version >= $1.$2 ])
-`$PYTHON -c 'import sys; exit(eval("sys.version_info < ($1, $2)"))'`
+`$PYTHON -c 'import sys; sys.exit(eval("sys.version_info < ($1, $2)"))'`
 if test "$?" != "0"
 then
     python_version=`$PYTHON -V 2>&1`


Best Regards,
     Yongjie Ren  (Jay)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 06:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 06:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1Af0-00077V-CC; Sat, 25 Feb 2012 05:59:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1Aey-00077Q-Ml
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 05:59:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330149542!10918879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11141 invoked from network); 25 Feb 2012 05:59:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 05:59:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,480,1325462400"; d="scan'208";a="10932081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 05:59:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 05:59:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1Aer-000806-RC;
	Sat, 25 Feb 2012 05:59:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1Aer-0005k7-PV;
	Sat, 25 Feb 2012 05:59:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12058-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 05:59:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12058: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12058 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12058/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 06:00:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 06:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1Af0-00077V-CC; Sat, 25 Feb 2012 05:59:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1Aey-00077Q-Ml
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 05:59:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330149542!10918879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11141 invoked from network); 25 Feb 2012 05:59:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 05:59:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,480,1325462400"; d="scan'208";a="10932081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 05:59:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 05:59:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1Aer-000806-RC;
	Sat, 25 Feb 2012 05:59:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1Aer-0005k7-PV;
	Sat, 25 Feb 2012 05:59:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12058-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 05:59:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12058: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12058 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12058/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 07:46:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 07: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 1S1CKX-0007gu-5Y; Sat, 25 Feb 2012 07:46:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1S1CKV-0007gp-HA
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 07:46:07 +0000
Received: from [85.158.139.83:12915] by server-12.bemta-5.messagelabs.com id
	63/DB-05100-EB1984F4; Sat, 25 Feb 2012 07:46:06 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330155964!15970375!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11093 invoked from network); 25 Feb 2012 07:46:05 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2012 07:46:05 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 2046EFE0F2;
	Sat, 25 Feb 2012 07:46:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=postfix; bh=rgRLcxBey
	5DAmyAHHIgrI418JwY=; b=j1dRdu+OQCyHPr8LHVCuCVrU25H5DrTJ7/uIH7Fdh
	J/Z4NdW8ki7AvvBTFUmVnmlvpZ437ityipnmYKibJvW/H7jHUwRR0+K3APVinV3Z
	j6LB4O6VdBlJ0+2gP00ORC1tP5kPEuXXecAzDneE2ftuCoQQgqAPgAhYp9SJWhQm
	DM=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=postfix; b=GAF
	4TIvfAdKZRTGoHvGT6dHOveV/ocw0g9aijHCn4HvyMNo2MRD5h+zaN6O0FTk2ReU
	70NoCiVuRgco15zaIK3jrAaNj+3Pxx1cW3LnBOCpbr1PMGMJPtV0FrzJnfb/9MMG
	Mfalzoe1ORgZ4jx5jXfZOB7OPTNmSQItciSHydK0=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id BE1C2FE0D1;
	Sat, 25 Feb 2012 07:46:21 +0000 (UTC)
Message-ID: <4F4891B8.9050008@goirand.fr>
Date: Sat, 25 Feb 2012 15:46:00 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120207 Icedove/3.0.11
MIME-Version: 1.0
To: Jonathan Nieder <jrnieder@gmail.com>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>	<20120127144737.GA27750@andromeda.dapyr.net>	<20120219223125.GA820@burratino>
	<20120220181618.GD17566@burratino>
In-Reply-To: <20120220181618.GD17566@burratino>
X-Enigmail-Version: 1.0.1
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	William Dauchy <wdauchy@gmail.com>
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/21/2012 02:16 AM, Jonathan Nieder wrote:
>> I just tried with the amd64 kernel and Xen, and I didn't see any issue.
>>
>> However, it is important that Xen 4.1 + Linux 3.2 works with a 32 bits
>> kernel, because that is the most optimized configuration (eg: 64 bits
>> hypervisor, 32 bits kernel and 32 bits userland).
>>     
> Maybe Andres's patches are relevant.
>
> Hope that helps,
> Jonathan
>
> [1] http://bugs.debian.org/660554#25
>   
Hi,

Which patch are you referring to? Is there anything I can do to help
testing/investigating this? Should this be reported in the LKML? How
can I find who's the author of this driver?

Thomas Goirand (zigo)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 07:46:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 07: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 1S1CKX-0007gu-5Y; Sat, 25 Feb 2012 07:46:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1S1CKV-0007gp-HA
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 07:46:07 +0000
Received: from [85.158.139.83:12915] by server-12.bemta-5.messagelabs.com id
	63/DB-05100-EB1984F4; Sat, 25 Feb 2012 07:46:06 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330155964!15970375!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11093 invoked from network); 25 Feb 2012 07:46:05 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2012 07:46:05 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 2046EFE0F2;
	Sat, 25 Feb 2012 07:46:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; s=postfix; bh=rgRLcxBey
	5DAmyAHHIgrI418JwY=; b=j1dRdu+OQCyHPr8LHVCuCVrU25H5DrTJ7/uIH7Fdh
	J/Z4NdW8ki7AvvBTFUmVnmlvpZ437ityipnmYKibJvW/H7jHUwRR0+K3APVinV3Z
	j6LB4O6VdBlJ0+2gP00ORC1tP5kPEuXXecAzDneE2ftuCoQQgqAPgAhYp9SJWhQm
	DM=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=postfix; b=GAF
	4TIvfAdKZRTGoHvGT6dHOveV/ocw0g9aijHCn4HvyMNo2MRD5h+zaN6O0FTk2ReU
	70NoCiVuRgco15zaIK3jrAaNj+3Pxx1cW3LnBOCpbr1PMGMJPtV0FrzJnfb/9MMG
	Mfalzoe1ORgZ4jx5jXfZOB7OPTNmSQItciSHydK0=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id BE1C2FE0D1;
	Sat, 25 Feb 2012 07:46:21 +0000 (UTC)
Message-ID: <4F4891B8.9050008@goirand.fr>
Date: Sat, 25 Feb 2012 15:46:00 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120207 Icedove/3.0.11
MIME-Version: 1.0
To: Jonathan Nieder <jrnieder@gmail.com>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>	<20120127144737.GA27750@andromeda.dapyr.net>	<20120219223125.GA820@burratino>
	<20120220181618.GD17566@burratino>
In-Reply-To: <20120220181618.GD17566@burratino>
X-Enigmail-Version: 1.0.1
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	William Dauchy <wdauchy@gmail.com>
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/21/2012 02:16 AM, Jonathan Nieder wrote:
>> I just tried with the amd64 kernel and Xen, and I didn't see any issue.
>>
>> However, it is important that Xen 4.1 + Linux 3.2 works with a 32 bits
>> kernel, because that is the most optimized configuration (eg: 64 bits
>> hypervisor, 32 bits kernel and 32 bits userland).
>>     
> Maybe Andres's patches are relevant.
>
> Hope that helps,
> Jonathan
>
> [1] http://bugs.debian.org/660554#25
>   
Hi,

Which patch are you referring to? Is there anything I can do to help
testing/investigating this? Should this be reported in the LKML? How
can I find who's the author of this driver?

Thomas Goirand (zigo)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 09:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 09: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 1S1EPR-0000Xs-Mq; Sat, 25 Feb 2012 09:59:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S1EPQ-0000Xn-EK
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 09:59:20 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330163952!15482010!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29055 invoked from network); 25 Feb 2012 09:59:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2012 09:59:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S1EPH-0002gZ-Ov
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 01:59:11 -0800
Date: Sat, 25 Feb 2012 01:59:11 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1330163951764-5514885.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 found that the time wasted on calling `sendto` system call is nearly five
times than native kenrel.
After reading some paper and code, I understand that xen seems deal with
system call as follows:

    xen's subarch_percpu_traps_init installs syscall handler
`syscall_enter`.
    dom0 excutes syscall_init, which installs `system_call`, but
`wrmsrl(MSR_LSTAR, system_call);` does nonting in dom0.
    when userland application call sendto system call, xen's syscall_enter
handler excutes, which calls toggle_guest_mode to switch to pseudo-kernel
mode.
    create_bounce_frame call guest os's sys_sendto handler.
    guest os finaly call iret hypercall return to xen, which calls
toggle_guest_mode again to switch back to userland.

Are these correct?

If that's true, it means that the efficiency of system call in dom0 is very
terrible, because of long call path and two toggle_guest_mode calls which
will invalidates all tlbs.

Is there any optimization ways to deal with x86_64's system call?

Thanks in advence.

--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-system-call-efficiency-on-x86-64-tp5514885p5514885.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 09:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 09: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 1S1EPR-0000Xs-Mq; Sat, 25 Feb 2012 09:59:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S1EPQ-0000Xn-EK
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 09:59:20 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330163952!15482010!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29055 invoked from network); 25 Feb 2012 09:59:13 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2012 09:59:13 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S1EPH-0002gZ-Ov
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 01:59:11 -0800
Date: Sat, 25 Feb 2012 01:59:11 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1330163951764-5514885.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 found that the time wasted on calling `sendto` system call is nearly five
times than native kenrel.
After reading some paper and code, I understand that xen seems deal with
system call as follows:

    xen's subarch_percpu_traps_init installs syscall handler
`syscall_enter`.
    dom0 excutes syscall_init, which installs `system_call`, but
`wrmsrl(MSR_LSTAR, system_call);` does nonting in dom0.
    when userland application call sendto system call, xen's syscall_enter
handler excutes, which calls toggle_guest_mode to switch to pseudo-kernel
mode.
    create_bounce_frame call guest os's sys_sendto handler.
    guest os finaly call iret hypercall return to xen, which calls
toggle_guest_mode again to switch back to userland.

Are these correct?

If that's true, it means that the efficiency of system call in dom0 is very
terrible, because of long call path and two toggle_guest_mode calls which
will invalidates all tlbs.

Is there any optimization ways to deal with x86_64's system call?

Thanks in advence.

--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-system-call-efficiency-on-x86-64-tp5514885p5514885.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 11:14:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 11:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1FZK-0000x7-8y; Sat, 25 Feb 2012 11:13: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 1S1FZJ-0000x2-Bu
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 11:13:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330168341!62903671!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17451 invoked from network); 25 Feb 2012 11:12:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 11:12:21 -0000
Received: by wibhm2 with SMTP id hm2so8580441wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 03:13:35 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.101.37 as permitted sender) client-ip=10.180.101.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.101.37 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.101.37])
	by 10.180.101.37 with SMTP id fd5mr3841350wib.1.1330168415830 (num_hops
	= 1); Sat, 25 Feb 2012 03:13:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5omdpToC3RogtRE9zyOoBkMpSrMI8PdScZ/7TJ3yiI8=;
	b=NxjEJBaYqjpHfeEvum71S3Lq/DOMhAaRsrY28uKDh62jGVhbLHYozRvlurMeTlNqGk
	dOUJR0SYs8yJdje9zH9VGZz02NuvH0TghRXx/6zwV1ZIx+moX7vGf3aSJDASrgYMmeqO
	pH5gckgq/f/bJAbYcn2lZFC8iH+MoVVj+p9bU=
Received: by 10.180.101.37 with SMTP id fd5mr3003790wib.1.1330168415635;
	Sat, 25 Feb 2012 03:13:35 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id df3sm9053102wib.1.2012.02.25.03.13.33
	(version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 03:13:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 25 Feb 2012 11:13:31 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Liu.yi" <liu.yi24@zte.com.cn>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB6E72DB.2C43B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] dom0 system call efficiency on x86_64
Thread-Index: AczzroGI5NbkFiDAk0S8y/wqxwfA2g==
In-Reply-To: <1330163951764-5514885.post@n5.nabble.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/02/2012 09:59, "Liu.yi" <liu.yi24@zte.com.cn> wrote:

> hi,all
> I found that the time wasted on calling `sendto` system call is nearly five
> times than native kenrel.
> After reading some paper and code, I understand that xen seems deal with
> system call as follows:
> 
>     xen's subarch_percpu_traps_init installs syscall handler
> `syscall_enter`.
>     dom0 excutes syscall_init, which installs `system_call`, but
> `wrmsrl(MSR_LSTAR, system_call);` does nonting in dom0.
>     when userland application call sendto system call, xen's syscall_enter
> handler excutes, which calls toggle_guest_mode to switch to pseudo-kernel
> mode.
>     create_bounce_frame call guest os's sys_sendto handler.
>     guest os finaly call iret hypercall return to xen, which calls
> toggle_guest_mode again to switch back to userland.
> 
> Are these correct?
> 
> If that's true, it means that the efficiency of system call in dom0 is very
> terrible, because of long call path and two toggle_guest_mode calls which
> will invalidates all tlbs.

Unfortunately true.

> Is there any optimization ways to deal with x86_64's system call?

Run PV guest in an HVM container, which provides sufficient protection to
allow us to have guest applications syscall directly into guest OS. Mukes
Rathor at Oracle (cc'ed) is working on this.

 -- Keir

> Thanks in advence.
> 
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/dom0-system-call-efficiency-on-x86-64-tp55148
> 85p5514885.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 Sat Feb 25 11:14:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 11:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1FZK-0000x7-8y; Sat, 25 Feb 2012 11:13: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 1S1FZJ-0000x2-Bu
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 11:13:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330168341!62903671!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17451 invoked from network); 25 Feb 2012 11:12:21 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 11:12:21 -0000
Received: by wibhm2 with SMTP id hm2so8580441wib.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 03:13:35 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.101.37 as permitted sender) client-ip=10.180.101.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.101.37 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.101.37])
	by 10.180.101.37 with SMTP id fd5mr3841350wib.1.1330168415830 (num_hops
	= 1); Sat, 25 Feb 2012 03:13:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5omdpToC3RogtRE9zyOoBkMpSrMI8PdScZ/7TJ3yiI8=;
	b=NxjEJBaYqjpHfeEvum71S3Lq/DOMhAaRsrY28uKDh62jGVhbLHYozRvlurMeTlNqGk
	dOUJR0SYs8yJdje9zH9VGZz02NuvH0TghRXx/6zwV1ZIx+moX7vGf3aSJDASrgYMmeqO
	pH5gckgq/f/bJAbYcn2lZFC8iH+MoVVj+p9bU=
Received: by 10.180.101.37 with SMTP id fd5mr3003790wib.1.1330168415635;
	Sat, 25 Feb 2012 03:13:35 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id df3sm9053102wib.1.2012.02.25.03.13.33
	(version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 03:13:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 25 Feb 2012 11:13:31 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Liu.yi" <liu.yi24@zte.com.cn>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB6E72DB.2C43B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] dom0 system call efficiency on x86_64
Thread-Index: AczzroGI5NbkFiDAk0S8y/wqxwfA2g==
In-Reply-To: <1330163951764-5514885.post@n5.nabble.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/02/2012 09:59, "Liu.yi" <liu.yi24@zte.com.cn> wrote:

> hi,all
> I found that the time wasted on calling `sendto` system call is nearly five
> times than native kenrel.
> After reading some paper and code, I understand that xen seems deal with
> system call as follows:
> 
>     xen's subarch_percpu_traps_init installs syscall handler
> `syscall_enter`.
>     dom0 excutes syscall_init, which installs `system_call`, but
> `wrmsrl(MSR_LSTAR, system_call);` does nonting in dom0.
>     when userland application call sendto system call, xen's syscall_enter
> handler excutes, which calls toggle_guest_mode to switch to pseudo-kernel
> mode.
>     create_bounce_frame call guest os's sys_sendto handler.
>     guest os finaly call iret hypercall return to xen, which calls
> toggle_guest_mode again to switch back to userland.
> 
> Are these correct?
> 
> If that's true, it means that the efficiency of system call in dom0 is very
> terrible, because of long call path and two toggle_guest_mode calls which
> will invalidates all tlbs.

Unfortunately true.

> Is there any optimization ways to deal with x86_64's system call?

Run PV guest in an HVM container, which provides sufficient protection to
allow us to have guest applications syscall directly into guest OS. Mukes
Rathor at Oracle (cc'ed) is working on this.

 -- Keir

> Thanks in advence.
> 
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/dom0-system-call-efficiency-on-x86-64-tp55148
> 85p5514885.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 Sat Feb 25 15:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 15: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 1S1Jpe-00021K-B4; Sat, 25 Feb 2012 15:46:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.chander@gmail.com>) id 1S1Jpc-00020i-SF
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 15:46:45 +0000
X-Env-Sender: vijay.chander@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330184796!3551386!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10336 invoked from network); 25 Feb 2012 15:46:38 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 15:46:38 -0000
Received: by iaeh11 with SMTP id h11so14788654iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 07:46:36 -0800 (PST)
Received-SPF: pass (google.com: domain of vijay.chander@gmail.com designates
	10.42.169.198 as permitted sender) client-ip=10.42.169.198; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	vijay.chander@gmail.com designates 10.42.169.198 as permitted
	sender) smtp.mail=vijay.chander@gmail.com;
	dkim=pass header.i=vijay.chander@gmail.com
Received: from mr.google.com ([10.42.169.198])
	by 10.42.169.198 with SMTP id c6mr7341669icz.31.1330184796433 (num_hops
	= 1); Sat, 25 Feb 2012 07:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=vBbeQGPkEmfEHPezD55GNXfrnmkiwPpo8v+yP3Xjucs=;
	b=prYJfkdfWGS3E8GrBJPopLHXo6I5Sew3hCapt3CJFLBPXPLxxzPm0y8SwbkJuEeZn8
	Yo+5Lg2jxVsc1oEbDmolrNj9Dg8K/+BF8BHM7+juT2Q2Tun52NhPfBfQVkFRcCER7/7J
	xbO0yXav0lOAbyQMn1ZhfJYj8UKM4z/3ThM+A=
MIME-Version: 1.0
Received: by 10.42.169.198 with SMTP id c6mr5882980icz.31.1330184796376; Sat,
	25 Feb 2012 07:46:36 -0800 (PST)
Received: by 10.231.167.132 with HTTP; Sat, 25 Feb 2012 07:46:36 -0800 (PST)
In-Reply-To: <CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
Date: Sat, 25 Feb 2012 07:46:36 -0800
Message-ID: <CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
From: Vijay Chander <vijay.chander@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
	appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2373223144650978188=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2373223144650978188==
Content-Type: multipart/alternative; boundary=90e6ba6e8406460e6104b9cbc877

--90e6ba6e8406460e6104b9cbc877
Content-Type: text/plain; charset=ISO-8859-1

If anybody encountered a similar situation as below where the netfront TX
ring is stuck ,
can you pls provide some pointers on how to get around this problem ?

This typically happens after about 2days of overnight traffic tests.

Thanks,
-vijay

On Thu, Feb 23, 2012 at 8:29 AM, Vijay Chander <vijay.chander@gmail.com>wrote:

>
>
> Hi,
>
>     We are running into a situation where rsp_prod index in the shared
> ring is not getting updated
> for the netfront tx ring by the netback.
>
>     We see that rsp_cons is the same value as rsp_prod, with req_prod 236
> slots away(tx ring is full).
> From looking at the netfront driver code, it looks as if xennet_tx_buf_gc
> processing only happens if rsp_prod is more
> than rsp_cons.
>
>    Our understanding is that netfront sets rsp_cons to tell the netback to
> start processing transmits
> from rsp_cons index onwards till req_prod. Once netback is done process X
> requests, it will increment rsp_prod
> by X. This will cause netfront to look at the status of each of individual
> responses for the slots starting
> from rsp_cons till rsp_prod (with rsp_prod  - rsp_cons = X in this case).
>
>    Is there anyway to workaround this ? Will xennet_disconnect_backend(),
> xennet_connect()
> on the netfront cause us to recover from this stuck situation. We are ok
> with pending TX packets getting dropped
> since we have TCP running on top.
>
>    Thanks,
> -vijay
>
>

--90e6ba6e8406460e6104b9cbc877
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If anybody encountered a similar situation as below where the netfront TX r=
ing is stuck ,<div>can you pls provide some pointers on how to get around t=
his problem ?</div><div><br></div><div>This typically happens after about 2=
days of overnight traffic tests.</div>
<div><br></div><div>Thanks,</div><div>-vijay<br><br><div class=3D"gmail_quo=
te">On Thu, Feb 23, 2012 at 8:29 AM, Vijay Chander <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:vijay.chander@gmail.com">vijay.chander@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div class=3D"im"=
><br><br>Hi, =A0<div>=A0<br><div>=A0 =A0 We are running into a situation wh=
ere rsp_prod index in the shared ring is not getting updated</div>
</div><div>for the netfront tx ring by the netback.</div><div><br>
</div><div>=A0 =A0 We see that rsp_cons is the same value as rsp_prod, with=
 req_prod 236 slots away(tx ring is full).=A0</div>
<div>From looking=A0at the netfront driver code, it looks as if xennet_tx_b=
uf_gc processing only happens if rsp_prod is more=A0</div><div>than rsp_con=
s.</div><div><br></div><div>=A0 =A0Our understanding is that netfront sets =
rsp_cons to tell the netback to start processing transmits</div>


<div>from rsp_cons index onwards till req_prod. Once netback is done proces=
s X requests, it will increment rsp_prod</div><div>by X. This will cause ne=
tfront to look at the status of each of individual responses for the slots =
starting</div>


<div>from rsp_cons till rsp_prod (with rsp_prod =A0- rsp_cons =3D X in this=
 case).</div><div><br></div></div><div class=3D"im"><div>=A0 =A0Is there an=
yway to workaround this ? Will xennet_disconnect_backend(), xennet_connect(=
)</div>
<div>on the netfront cause us to recover from this stuck situation. We are =
ok with pending TX packets getting dropped</div>

<div>since we have TCP running on top.</div><div><br></div><div>=A0 =A0Than=
ks,</div><div>-vijay</div>
</div></div><br>
</blockquote></div><br></div>

--90e6ba6e8406460e6104b9cbc877--


--===============2373223144650978188==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2373223144650978188==--


From xen-devel-bounces@lists.xen.org Sat Feb 25 15:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 15: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 1S1Jpe-00021K-B4; Sat, 25 Feb 2012 15:46:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.chander@gmail.com>) id 1S1Jpc-00020i-SF
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 15:46:45 +0000
X-Env-Sender: vijay.chander@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330184796!3551386!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10336 invoked from network); 25 Feb 2012 15:46:38 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 15:46:38 -0000
Received: by iaeh11 with SMTP id h11so14788654iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 07:46:36 -0800 (PST)
Received-SPF: pass (google.com: domain of vijay.chander@gmail.com designates
	10.42.169.198 as permitted sender) client-ip=10.42.169.198; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	vijay.chander@gmail.com designates 10.42.169.198 as permitted
	sender) smtp.mail=vijay.chander@gmail.com;
	dkim=pass header.i=vijay.chander@gmail.com
Received: from mr.google.com ([10.42.169.198])
	by 10.42.169.198 with SMTP id c6mr7341669icz.31.1330184796433 (num_hops
	= 1); Sat, 25 Feb 2012 07:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=vBbeQGPkEmfEHPezD55GNXfrnmkiwPpo8v+yP3Xjucs=;
	b=prYJfkdfWGS3E8GrBJPopLHXo6I5Sew3hCapt3CJFLBPXPLxxzPm0y8SwbkJuEeZn8
	Yo+5Lg2jxVsc1oEbDmolrNj9Dg8K/+BF8BHM7+juT2Q2Tun52NhPfBfQVkFRcCER7/7J
	xbO0yXav0lOAbyQMn1ZhfJYj8UKM4z/3ThM+A=
MIME-Version: 1.0
Received: by 10.42.169.198 with SMTP id c6mr5882980icz.31.1330184796376; Sat,
	25 Feb 2012 07:46:36 -0800 (PST)
Received: by 10.231.167.132 with HTTP; Sat, 25 Feb 2012 07:46:36 -0800 (PST)
In-Reply-To: <CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
References: <CAJNqtuqZo5VKvGtYnGxp543dQ1FNk2Lz-8jzt5QnDYjR+XiS6w@mail.gmail.com>
	<CAJNqtuqN=gCQ4FSNhAqO=tKLfK=rnumNVU_45FJawEFU59C_uw@mail.gmail.com>
Date: Sat, 25 Feb 2012 07:46:36 -0800
Message-ID: <CAJNqtuqTP8LzcOHjH8VeoArHDDb_R-opq6-CY5_f0rJYpnUhBA@mail.gmail.com>
From: Vijay Chander <vijay.chander@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Pls help: netfront tx ring frozen (any clues
	appreciated)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2373223144650978188=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2373223144650978188==
Content-Type: multipart/alternative; boundary=90e6ba6e8406460e6104b9cbc877

--90e6ba6e8406460e6104b9cbc877
Content-Type: text/plain; charset=ISO-8859-1

If anybody encountered a similar situation as below where the netfront TX
ring is stuck ,
can you pls provide some pointers on how to get around this problem ?

This typically happens after about 2days of overnight traffic tests.

Thanks,
-vijay

On Thu, Feb 23, 2012 at 8:29 AM, Vijay Chander <vijay.chander@gmail.com>wrote:

>
>
> Hi,
>
>     We are running into a situation where rsp_prod index in the shared
> ring is not getting updated
> for the netfront tx ring by the netback.
>
>     We see that rsp_cons is the same value as rsp_prod, with req_prod 236
> slots away(tx ring is full).
> From looking at the netfront driver code, it looks as if xennet_tx_buf_gc
> processing only happens if rsp_prod is more
> than rsp_cons.
>
>    Our understanding is that netfront sets rsp_cons to tell the netback to
> start processing transmits
> from rsp_cons index onwards till req_prod. Once netback is done process X
> requests, it will increment rsp_prod
> by X. This will cause netfront to look at the status of each of individual
> responses for the slots starting
> from rsp_cons till rsp_prod (with rsp_prod  - rsp_cons = X in this case).
>
>    Is there anyway to workaround this ? Will xennet_disconnect_backend(),
> xennet_connect()
> on the netfront cause us to recover from this stuck situation. We are ok
> with pending TX packets getting dropped
> since we have TCP running on top.
>
>    Thanks,
> -vijay
>
>

--90e6ba6e8406460e6104b9cbc877
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If anybody encountered a similar situation as below where the netfront TX r=
ing is stuck ,<div>can you pls provide some pointers on how to get around t=
his problem ?</div><div><br></div><div>This typically happens after about 2=
days of overnight traffic tests.</div>
<div><br></div><div>Thanks,</div><div>-vijay<br><br><div class=3D"gmail_quo=
te">On Thu, Feb 23, 2012 at 8:29 AM, Vijay Chander <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:vijay.chander@gmail.com">vijay.chander@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div class=3D"im"=
><br><br>Hi, =A0<div>=A0<br><div>=A0 =A0 We are running into a situation wh=
ere rsp_prod index in the shared ring is not getting updated</div>
</div><div>for the netfront tx ring by the netback.</div><div><br>
</div><div>=A0 =A0 We see that rsp_cons is the same value as rsp_prod, with=
 req_prod 236 slots away(tx ring is full).=A0</div>
<div>From looking=A0at the netfront driver code, it looks as if xennet_tx_b=
uf_gc processing only happens if rsp_prod is more=A0</div><div>than rsp_con=
s.</div><div><br></div><div>=A0 =A0Our understanding is that netfront sets =
rsp_cons to tell the netback to start processing transmits</div>


<div>from rsp_cons index onwards till req_prod. Once netback is done proces=
s X requests, it will increment rsp_prod</div><div>by X. This will cause ne=
tfront to look at the status of each of individual responses for the slots =
starting</div>


<div>from rsp_cons till rsp_prod (with rsp_prod =A0- rsp_cons =3D X in this=
 case).</div><div><br></div></div><div class=3D"im"><div>=A0 =A0Is there an=
yway to workaround this ? Will xennet_disconnect_backend(), xennet_connect(=
)</div>
<div>on the netfront cause us to recover from this stuck situation. We are =
ok with pending TX packets getting dropped</div>

<div>since we have TCP running on top.</div><div><br></div><div>=A0 =A0Than=
ks,</div><div>-vijay</div>
</div></div><br>
</blockquote></div><br></div>

--90e6ba6e8406460e6104b9cbc877--


--===============2373223144650978188==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2373223144650978188==--


From xen-devel-bounces@lists.xen.org Sat Feb 25 15:59:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 15: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 1S1K1S-0002Qn-61; Sat, 25 Feb 2012 15:58:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1K1Q-0002Qi-4s
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 15:58:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330185529!13046470!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31419 invoked from network); 25 Feb 2012 15:58:49 -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;
	25 Feb 2012 15:58:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,481,1325462400"; d="scan'208";a="10934505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 15:58:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 15:58:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1K1J-0003Wf-1a;
	Sat, 25 Feb 2012 15:58:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1K1J-0005sJ-0S;
	Sat, 25 Feb 2012 15:58:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12062-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 15:58:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12062: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12062 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12062/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12053
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12053
 test-i386-i386-xl-win         5 xen-boot           fail in 12053 pass in 12062

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12031
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12053 like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 15:59:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 15: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 1S1K1S-0002Qn-61; Sat, 25 Feb 2012 15:58:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1K1Q-0002Qi-4s
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 15:58:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330185529!13046470!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTE3NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31419 invoked from network); 25 Feb 2012 15:58:49 -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;
	25 Feb 2012 15:58:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,481,1325462400"; d="scan'208";a="10934505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 15:58:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 15:58:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1K1J-0003Wf-1a;
	Sat, 25 Feb 2012 15:58:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1K1J-0005sJ-0S;
	Sat, 25 Feb 2012 15:58:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12062-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 15:58:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12062: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12062 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12062/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 12053
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12053
 test-i386-i386-xl-win         5 xen-boot           fail in 12053 pass in 12062

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12031
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12053 like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 16:34:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 16: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 1S1KYq-00038J-V0; Sat, 25 Feb 2012 16:33:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1S1KYp-00038E-8z
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 16:33:27 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330187598!16419166!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9082 invoked from network); 25 Feb 2012 16:33:20 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 16:33:20 -0000
Received: by pbbro2 with SMTP id ro2so22161828pbb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 08:33:18 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@gmail.com designates
	10.68.129.166 as permitted sender) client-ip=10.68.129.166; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@gmail.com
	designates 10.68.129.166 as permitted sender)
	smtp.mail=rshriram@gmail.com
Received: from mr.google.com ([10.68.129.166])
	by 10.68.129.166 with SMTP id nx6mr20638900pbb.153.1330187598569
	(num_hops = 1); Sat, 25 Feb 2012 08:33:18 -0800 (PST)
Received: by 10.68.129.166 with SMTP id nx6mr17274445pbb.153.1330187598486;
	Sat, 25 Feb 2012 08:33:18 -0800 (PST)
Received: from [172.16.0.15] (d205-250-160-181.bchsia.telus.net.
	[205.250.160.181])
	by mx.google.com with ESMTPS id l1sm7540453pbe.54.2012.02.25.08.33.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 25 Feb 2012 08:33:16 -0800 (PST)
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
	<alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <2D6E03AA-493E-4BF0-9DF0-E233A5B597C4@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Sat, 25 Feb 2012 08:33:13 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-02-17, at 3:45 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 17 Feb 2012, Shriram Rajagopalan wrote:
>> 
>> On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>>      Introduce a new save_id to save/restore toolstack specific extra
>>      information.
>> 
>>      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> 
>> 
>> cc-ing Ian Jackson.
>> These patches (and other follow ups including mine) have been acked.
>> Ian, are there any issues blocking these patches ?
> 
> The issue are the QEMU side acks. Let me ask them again for feedback.
> 

Any update yet ?
 Or should I respin my patches without the qemu_save part?

Shriram
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 16:34:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 16: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 1S1KYq-00038J-V0; Sat, 25 Feb 2012 16:33:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1S1KYp-00038E-8z
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 16:33:27 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330187598!16419166!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9082 invoked from network); 25 Feb 2012 16:33:20 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 16:33:20 -0000
Received: by pbbro2 with SMTP id ro2so22161828pbb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 08:33:18 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@gmail.com designates
	10.68.129.166 as permitted sender) client-ip=10.68.129.166; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@gmail.com
	designates 10.68.129.166 as permitted sender)
	smtp.mail=rshriram@gmail.com
Received: from mr.google.com ([10.68.129.166])
	by 10.68.129.166 with SMTP id nx6mr20638900pbb.153.1330187598569
	(num_hops = 1); Sat, 25 Feb 2012 08:33:18 -0800 (PST)
Received: by 10.68.129.166 with SMTP id nx6mr17274445pbb.153.1330187598486;
	Sat, 25 Feb 2012 08:33:18 -0800 (PST)
Received: from [172.16.0.15] (d205-250-160-181.bchsia.telus.net.
	[205.250.160.181])
	by mx.google.com with ESMTPS id l1sm7540453pbe.54.2012.02.25.08.33.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 25 Feb 2012 08:33:16 -0800 (PST)
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
	<alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <2D6E03AA-493E-4BF0-9DF0-E233A5B597C4@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Sat, 25 Feb 2012 08:33:13 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-02-17, at 3:45 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 17 Feb 2012, Shriram Rajagopalan wrote:
>> 
>> On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>>      Introduce a new save_id to save/restore toolstack specific extra
>>      information.
>> 
>>      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> 
>> 
>> cc-ing Ian Jackson.
>> These patches (and other follow ups including mine) have been acked.
>> Ian, are there any issues blocking these patches ?
> 
> The issue are the QEMU side acks. Let me ask them again for feedback.
> 

Any update yet ?
 Or should I respin my patches without the qemu_save part?

Shriram
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 16:49:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 16: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 1S1Knj-0003Iu-F5; Sat, 25 Feb 2012 16:48:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1Knh-0003Im-4w
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 16:48:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330188522!16424779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3330 invoked from network); 25 Feb 2012 16:48:42 -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;
	25 Feb 2012 16:48:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,481,1325462400"; d="scan'208";a="10934663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 16:48:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 16:48:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1Kna-0003pW-F7;
	Sat, 25 Feb 2012 16:48:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1Kna-0003qa-Ae;
	Sat, 25 Feb 2012 16:48:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S1Kna-0003qa-Ae@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 16:48:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-intel
test redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12062 fail [host=bush-cricket] / 12031 ok.
Failure / basis pass flights: 12062 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-71159fb049f2
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 62 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12053 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12061 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12063 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12064 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12066 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12067 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12068 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12069 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12070 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12071 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12062 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12072 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12053 (fail), for basis failure
 Repro found: flight 12061 (pass), for basis pass
 Repro found: flight 12062 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12067 (pass), for last pass
 Result found: flight 12068 (fail), for first failure
 Repro found: flight 12069 (pass), for last pass
 Repro found: flight 12070 (fail), for first failure
 Repro found: flight 12071 (pass), for last pass
 Repro found: flight 12072 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
12072: ALL FAIL

flight 12072 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12072/


jobs:
 test-amd64-i386-rhel6hvm-intel                               fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 16:49:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 16: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 1S1Knj-0003Iu-F5; Sat, 25 Feb 2012 16:48:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1Knh-0003Im-4w
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 16:48:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330188522!16424779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3330 invoked from network); 25 Feb 2012 16:48:42 -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;
	25 Feb 2012 16:48:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,481,1325462400"; d="scan'208";a="10934663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 16:48:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 16:48:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1Kna-0003pW-F7;
	Sat, 25 Feb 2012 16:48:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1Kna-0003qa-Ae;
	Sat, 25 Feb 2012 16:48:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S1Kna-0003qa-Ae@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 16:48:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-intel
test redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12062 fail [host=bush-cricket] / 12031 ok.
Failure / basis pass flights: 12062 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-71159fb049f2
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 62 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12053 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12061 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12063 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12064 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12066 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12067 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12068 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12069 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12070 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12071 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12062 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12072 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12053 (fail), for basis failure
 Repro found: flight 12061 (pass), for basis pass
 Repro found: flight 12062 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12067 (pass), for last pass
 Result found: flight 12068 (fail), for first failure
 Repro found: flight 12069 (pass), for last pass
 Repro found: flight 12070 (fail), for first failure
 Repro found: flight 12071 (pass), for last pass
 Repro found: flight 12072 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
12072: ALL FAIL

flight 12072 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12072/


jobs:
 test-amd64-i386-rhel6hvm-intel                               fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 17:39:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 17:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1LaR-0003bE-11; Sat, 25 Feb 2012 17:39:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <harryxiyou@gmail.com>) id 1S1LaP-0003au-CF
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 17:39:09 +0000
X-Env-Sender: harryxiyou@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330191541!13017983!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19084 invoked from network); 25 Feb 2012 17:39:02 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 17:39:02 -0000
Received: by lagr15 with SMTP id r15so2576325lag.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 09:39:01 -0800 (PST)
Received-SPF: pass (google.com: domain of harryxiyou@gmail.com designates
	10.112.103.228 as permitted sender) client-ip=10.112.103.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of harryxiyou@gmail.com
	designates 10.112.103.228 as permitted sender)
	smtp.mail=harryxiyou@gmail.com;
	dkim=pass header.i=harryxiyou@gmail.com
Received: from mr.google.com ([10.112.103.228])
	by 10.112.103.228 with SMTP id fz4mr2706257lbb.99.1330191541543
	(num_hops = 1); Sat, 25 Feb 2012 09:39:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=KDNBadCKKNhSaplm4cBHvNs2Gcxd1N5qJb+ZX08+SOM=;
	b=shQDw0lJITjy3D6g2XeSbWDwu7Y1+/hhjQA1bO+F3durIxuy7YhYEMT2BH+MXQJS2K
	l8/2no7zp3ksCs71R7zDZnVoR7Jf+cWDcAVc0kfTtsC2cZJnUF++Xct6lmpYMbC3Fy+Y
	q0dN1Jg4m9PYDpSulVlZi+hCYLsX6MXrr0+50=
MIME-Version: 1.0
Received: by 10.112.103.228 with SMTP id fz4mr2243507lbb.99.1330191541274;
	Sat, 25 Feb 2012 09:39:01 -0800 (PST)
Received: by 10.112.81.2 with HTTP; Sat, 25 Feb 2012 09:39:01 -0800 (PST)
Date: Sun, 26 Feb 2012 01:39:01 +0800
Message-ID: <CAD+1EGNSnxVvrqbZm3ddVur3kpT_hsxR74OCZW7z3y=93K6T=w@mail.gmail.com>
From: harryxiyou <harryxiyou@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xensource.com
Cc: cloudxy@googlegroups.com, Kang Hua <kanghua151@gmail.com>,
	=?UTF-8?B?55Sw5bq35aWH?= <kangqi1988@gmail.com>
Subject: [Xen-devel] [RFC]Some questions about xen-4.1.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgbGlzdCwKCk1heWJlIGkgc2hvdWxkIG5vdCBhc2sgcXVlc3Rpb25zIGhlcmUuIElmIHRydWUs
IHBsZWFzZSBmb3JnaXZlIG1lIDstKQoKCkkgYnVpbGQgeGVuIGVudmlyb25tZW50IHVuZGVyIENl
bnRvcy01LjQuTXkgZW52IGlzIGxpa2UgdGhpcy4KClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODld
IElORk8gKFhlbmREb21haW5JbmZvOjMyNjkpIE1vdW50aW5nCi9ob21lL2ppYXdlaS93b3Jrc2hv
cDEvMS5zeXMuaW1nIG9uIC9kZXYveHZkcC4KWzIwMTItMDItMjUgMjM6NTE6MTkgNDc4OV0gREVC
VUcgKERldkNvbnRyb2xsZXI6OTUpIERldkNvbnRyb2xsZXI6CndyaXRpbmcgeydiYWNrZW5kLWlk
JzogJzAnLCAndmlydHVhbC1kZXZpY2UnOiAnNTE5NTInLAonZGV2aWNlLXR5cGUnOiAnZGlzaycs
ICdzdGF0ZSc6ICcxJywgJ2JhY2tlbmQnOgonL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzAv
NTE5NTInfSB0bwovbG9jYWwvZG9tYWluLzAvZGV2aWNlL3ZiZC81MTk1Mi4KTGludXggbG9jYWww
MDIxMjIwMTAyMWEuenRlLmNvbS5jbiAyLjYuMzIuMzkgIzEgU01QIFN1biBGZWIgMTkKMTE6MjE6
MDkgQ1NUIDIwMTIgeDg2XzY0IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4CiMgeG0gaW5mbwpob3N0
ICAgICAgICAgICAgICAgICAgIDogbG9jYWwwMDIxMjIwMTAyMWEuenRlLmNvbS5jbgpyZWxlYXNl
ICAgICAgICAgICAgICAgIDogMi42LjMyLjM5CnZlcnNpb24gICAgICAgICAgICAgICAgOiAjMSBT
TVAgU3VuIEZlYiAxOSAxMToyMTowOSBDU1QgMjAxMgptYWNoaW5lICAgICAgICAgICAgICAgIDog
eDg2XzY0Cm5yX2NwdXMgICAgICAgICAgICAgICAgOiAyCm5yX25vZGVzICAgICAgICAgICAgICAg
OiAxCmNvcmVzX3Blcl9zb2NrZXQgICAgICAgOiAyCnRocmVhZHNfcGVyX2NvcmUgICAgICAgOiAx
CmNwdV9taHogICAgICAgICAgICAgICAgOiAxNzk1Cmh3X2NhcHMgICAgICAgICAgICAgICAgOgpi
ZmViZmJmZjoyMDEwMDgwMDowMDAwMDAwMDowMDAwMDk0MDowMDAwZTMxZDowMDAwMDAwMDowMDAw
MDAwMTowMDAwMDAwMAp2aXJ0X2NhcHMgICAgICAgICAgICAgIDoKdG90YWxfbWVtb3J5ICAgICAg
ICAgICA6IDk4NApmcmVlX21lbW9yeSAgICAgICAgICAgIDogNjY1CmZyZWVfY3B1cyAgICAgICAg
ICAgICAgOiAwCnhlbl9tYWpvciAgICAgICAgICAgICAgOiA0Cnhlbl9taW5vciAgICAgICAgICAg
ICAgOiAxCnhlbl9leHRyYSAgICAgICAgICAgICAgOiAuMQp4ZW5fY2FwcyAgICAgICAgICAgICAg
IDogeGVuLTMuMC14ODZfNjQgeGVuLTMuMC14ODZfMzJwCnhlbl9zY2hlZHVsZXIgICAgICAgICAg
OiBjcmVkaXQKeGVuX3BhZ2VzaXplICAgICAgICAgICA6IDQwOTYKcGxhdGZvcm1fcGFyYW1zICAg
ICAgICA6IHZpcnRfc3RhcnQ9MHhmZmZmODAwMDAwMDAwMDAwCnhlbl9jaGFuZ2VzZXQgICAgICAg
ICAgOiB1bmF2YWlsYWJsZQp4ZW5fY29tbWFuZGxpbmUgICAgICAgIDoKY2NfY29tcGlsZXIgICAg
ICAgICAgICA6IGdjYyB2ZXJzaW9uIDQuMS4yIDIwMDgwNzA0IChSZWQgSGF0IDQuMS4yLTUxKQpj
Y19jb21waWxlX2J5ICAgICAgICAgIDogcm9vdApjY19jb21waWxlX2RvbWFpbiAgICAgIDogenRl
LmNvbS5jbgpjY19jb21waWxlX2RhdGUgICAgICAgIDogVGh1IEZlYiAyMyAyMzozMjowMSBDU1Qg
MjAxMgp4ZW5kX2NvbmZpZ19mb3JtYXQgICAgIDogNAoKCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09ClthXSBXZSBnZXQgYW4gZXJyb3IgYnkgcnVubmluZyBmb2xsb3dpbmcgc3RlcHMu
Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CjEsIE1ha2luZyBhIGRlbHRhIHBsYXRl
IGJ5IHZoZC11dGlsCiMgdmhkLXV0aWwgc25hcHNob3QgLW4gL2hvbWUvamlhd2VpL3dvcmtzaG9w
MS8xLnN5cy5pbWcgLXAKL2hvbWUvamlhd2VpL3dvcmtzaG9wMS9kb21VLXg4Nl82NC1GUy5pbWcg
LW0KCjLvvIxzdGFydCBhIGRvbXUKIyB4bSBjciBweWdydWIuY29uZgpVc2luZyBjb25maWcgZmls
ZSAiLi9weWdydWIuY29uZiIuCkVycm9yOiBEaXNrIGlzbid0IGFjY2Vzc2libGUKCiMgY2F0IHB5
Z3J1Yi5jb25mCm5hbWUgPSAidHR5bGludXgiCm1lbW9yeSA9IDUxMgp2Y3B1cyA9IDEKdmlmID0g
WyAnYnJpZGdlPXZpcmJyMCcgXQpvbl9yZWJvb3QgPSAncmVzdGFydCcKb25fY3Jhc2ggPSAncmVz
dGFydCcKYm9vdGxvYWRlciA9ICIvdXNyL2Jpbi9weWdydWIiCmRpc2sgPSBbJ3RhcDI6dmhkOi9o
b21lL2ppYXdlaS93b3Jrc2hvcDEvMS5pbWcsc2RhLHcnXQoKQmUgc3VyZSB3ZSBoYXZlIGEgY29y
cmVjdCByYXcgaW1hZ2UKL2hvbWUvamlhd2VpL3dvcmtzaG9wMS9kb21VLXg4Nl82NC1GUy5pbWcg
YmVjYXN1ZQp3ZSBoYXZlIHRlc3RlZCBpdC4gQnV0IGluIHRoaXMgY29uZGl0aW9uIHdlIGNhbiBn
ZXQgYSB0YXBkaXNrIGRldmljZS4KRGV0YWlscyBhcmUgaGVyZS4KCltyb290QGxvY2FsMDAyMTIy
MDEwMjFhIHdvcmtzaG9wMV0jIHRhcC1jdGwgY3JlYXRlIC1hCnZoZDovaG9tZS9qaWF3ZWkvd29y
a3Nob3AxLzEuaW1nCi9kZXYveGVuL2Jsa3RhcC0yL3RhcGRldjAKW3Jvb3RAbG9jYWwwMDIxMjIw
MTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBsaXN0CiAgICA1ODM1ICAwICAgIDAgICAgICAgIHZo
ZCAvaG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEuaW1nCgoKQXQgbGFzdCB3ZSB0YWtlIHNvbWUgeGVu
IGxvZ3MgZnJvbSBkaXJlY3RvcnkgL3Zhci9sb2cveGVuL3hlbi5sb2cgbGlrZSB0aGlzLgoKLi4u
ClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChYZW5kRG9tYWluSW5mbzoxMDMpClhl
bmREb21haW5JbmZvLmNyZWF0ZShbJ3ZtJywgWyduYW1lJywgJ3R0eWxpbnV4J10sIFsnbWVtb3J5
JywgNTEyXSwKWydvbl9yZWJvb3QnLCAncmVzdGFydCddLCBbJ29uX2NyYXNoJywgJ3Jlc3RhcnQn
XSwgWydvbl94ZW5kX3N0YXJ0JywKJ2lnbm9yZSddLCBbJ29uX3hlbmRfc3RvcCcsICdpZ25vcmUn
XSwgWyd2Y3B1cycsIDFdLCBbJ29vcycsIDFdLApbJ2Jvb3Rsb2FkZXInLCAnL3Vzci9iaW4vcHln
cnViJ10sIFsnYm9vdGxvYWRlcl9hcmdzJywgJy1xJ10sClsnaW1hZ2UnLCBbJ2xpbnV4JywgWyd2
aWRlb3JhbScsIDRdLCBbJ3RzY19tb2RlJywgMF0sIFsnbm9taWdyYXRlJywKMF1dXSwgWydzM19p
bnRlZ3JpdHknLCAxXSwgWydkZXZpY2UnLCBbJ3RhcDInLCBbJ3VuYW1lJywKJ3RhcDI6dmhkOi9o
b21lL2ppYXdlaS93b3Jrc2hvcDEvMS5zeXMuaW1nJ10sIFsnZGV2JywgJ3h2ZGEnXSwKWydtb2Rl
JywgJ3cnXV1dLCBbJ2RldmljZScsIFsndmlmJywgWydicmlkZ2UnLCAndmlyYnIwJ11dXV0pClsy
MDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChYZW5kRG9tYWluSW5mbzoyNDk4KQpYZW5k
RG9tYWluSW5mby5jb25zdHJ1Y3REb21haW4KWzIwMTItMDItMjUgMjM6NTE6MTkgNDc4OV0gREVC
VUcgKGJhbGxvb246MTg3KSBCYWxsb29uOiA1NDE4MzYgS2lCCmZyZWU7IG5lZWQgMTYzODQ7IGRv
bmUuClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChYZW5kRG9tYWluOjQ3NikgQWRk
aW5nIERvbWFpbjogMzQKWzIwMTItMDItMjUgMjM6NTE6MTkgNDc4OV0gREVCVUcgKFhlbmREb21h
aW5JbmZvOjI4MzYpClhlbmREb21haW5JbmZvLmluaXREb21haW46IDM0IDI1NgpbMjAxMi0wMi0y
NSAyMzo1MToxOSA0Nzg5XSBJTkZPIChYZW5kRG9tYWluSW5mbzozMjY5KSBNb3VudGluZwovaG9t
ZS9qaWF3ZWkvd29ya3Nob3AxLzEuc3lzLmltZyBvbiAvZGV2L3h2ZHAuClsyMDEyLTAyLTI1IDIz
OjUxOjE5IDQ3ODldIERFQlVHIChEZXZDb250cm9sbGVyOjk1KSBEZXZDb250cm9sbGVyOgp3cml0
aW5nIHsnYmFja2VuZC1pZCc6ICcwJywgJ3ZpcnR1YWwtZGV2aWNlJzogJzUxOTUyJywgJ2Rldmlj
ZS10eXBlJzoKJ2Rpc2snLCAnc3RhdGUnOiAnMScsICdiYWNrZW5kJzoKJy9sb2NhbC9kb21haW4v
MC9iYWNrZW5kL3ZiZC8wLzUxOTUyJ30gdG8KL2xvY2FsL2RvbWFpbi8wL2RldmljZS92YmQvNTE5
NTIuClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChEZXZDb250cm9sbGVyOjk3KSBE
ZXZDb250cm9sbGVyOgp3cml0aW5nIHsnZG9tYWluJzogJ0RvbWFpbi0wJywgJ2Zyb250ZW5kJzoK
Jy9sb2NhbC9kb21haW4vMC9kZXZpY2UvdmJkLzUxOTUyJywgJ3V1aWQnOgonNjc3MmY3NmQtMTFi
MC0yNDZlLWI0ODMtZTlmYzEwNTZkZjEzJywgJ2Jvb3RhYmxlJzogJzAnLCAnZGV2JzoKJy9kZXYv
eHZkcCcsICdzdGF0ZSc6ICcxJywgJ3BhcmFtcyc6ICcvZGV2L3hlbi9ibGt0YXAtMi90YXBkZXYx
JywKJ21vZGUnOiAncicsICdvbmxpbmUnOiAnMScsICdmcm9udGVuZC1pZCc6ICcwJywgJ3R5cGUn
OiAncGh5JywKJ3RhcGRpc2stcGFyYW1zJzogJ3ZoZDovaG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEu
c3lzLmltZyd9IHRvCi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8wLzUxOTUyLgpbMjAxMi0w
Mi0yNSAyMzo1MToxOSA0Nzg5XSBERUJVRyAoRGV2Q29udHJvbGxlcjoxNDQpIFdhaXRpbmcgZm9y
IDUxOTUyLgpbMjAxMi0wMi0yNSAyMzo1MToxOSA0Nzg5XSBERUJVRyAoRGV2Q29udHJvbGxlcjo2
MjgpCmhvdHBsdWdTdGF0dXNDYWxsYmFjawovbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMC81
MTk1Mi9ob3RwbHVnLXN0YXR1cy4KWzIwMTItMDItMjUgMjM6NTE6MjAgNDc4OV0gREVCVUcgKERl
dkNvbnRyb2xsZXI6NjI4KQpob3RwbHVnU3RhdHVzQ2FsbGJhY2sKL2xvY2FsL2RvbWFpbi8wL2Jh
Y2tlbmQvdmJkLzAvNTE5NTIvaG90cGx1Zy1zdGF0dXMuClsyMDEyLTAyLTI1IDIzOjUxOjIwIDQ3
ODldIERFQlVHIChEZXZDb250cm9sbGVyOjY0MikgaG90cGx1Z1N0YXR1c0NhbGxiYWNrIDEuClsy
MDEyLTAyLTI1IDIzOjUxOjIwIDQ3ODldIERFQlVHIChEZXZDb250cm9sbGVyOjE0NCkgV2FpdGlu
ZyBmb3IgNTE5NTIuClsyMDEyLTAyLTI1IDIzOjUxOjIwIDQ3ODldIERFQlVHIChEZXZDb250cm9s
bGVyOjYyOCkKaG90cGx1Z1N0YXR1c0NhbGxiYWNrCi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3Zi
ZC8wLzUxOTUyL2hvdHBsdWctc3RhdHVzLgpbMjAxMi0wMi0yNSAyMzo1MToyMCA0Nzg5XSBERUJV
RyAoRGV2Q29udHJvbGxlcjo2NDIpIGhvdHBsdWdTdGF0dXNDYWxsYmFjayAxLgpbMjAxMi0wMi0y
NSAyMzo1MToyMCA0Nzg5XSBFUlJPUiAoWGVuZEJvb3Rsb2FkZXI6NDMpIERpc2sgaXNuJ3QgYWNj
ZXNzaWJsZQouLi4KCldlIHRoaW5rIHRoYXQgdGhlcmUgYXJlIHNvbWV0aGluZyB3cm9uZyB3aXRo
IHRoZSBkZXZpY2UgL2Rldi94dmRwLiBBbmQKaXRzICpEZXZDb250cm9sbGVyKiBwcm9jZXNzCjUx
OTUyIGNhbiBub3QgZ2V0IGl0cyBjb3JyZWN0aXZlIHN0YXR1cyBmb3IgaG90cGx1Zy4gU28gZXJy
b3IgaGFwcGVucwp0byB1cy4gUmlnaHQ/CgoKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQpbYl1CdXQgd2UgY2FuIGxhdW5jaCBhIGRvbXUgbGlrZSBmb2xs
b3dpbmcgc3RlcHMgc3VjY2Vzc2Z1bGx5Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT0KCjEsIFRhcC1jdGwgY3JlYXRlIGEgZGV2aWNlCiMgdGFwLWN0bCBj
cmVhdGUgLWEgdmhkOi9ob21lL2ppYXdlaS93b3Jrc2hvcDEvMS5pbWcKL2Rldi94ZW4vYmxrdGFw
LTIvdGFwZGV2MAojIHRhcC1jdGwgbGlzdAo1ODM1ICAwICAgIDAgICAgICAgIHZoZCAvaG9tZS9q
aWF3ZWkvd29ya3Nob3AxLzEuaW1nCgoyLCBTdGFydCBkb211CiMgeG0gY3IgcHlncnViMS5jb25m
ClVzaW5nIGNvbmZpZyBmaWxlICIuL3B5Z3J1YjEuY29uZiIuClN0YXJ0ZWQgZG9tYWluIHR0eWxp
bnV4IChpZD00NCkKIyBjYXQgcHlncnViMS5jb25mCm1lbW9yeSA9IDUxMgpuYW1lID0gInR0eWxp
bnV4Igpib290bG9hZGVyID0gIi91c3IvYmluL3B5Z3J1YiIKZGlzayA9IFsncGh5Oi9kZXYveGVu
L2Jsa3RhcC0yL3RhcGRldjAseHZkYTEsdyddCgpCeSB1cCBzdGVwcywgd2UgZG8gZ2V0IGEgZG9t
dS4gQ291bGQgYW55b25lIHRlbGwgbWUgdGhlIGRldGFpbApkaWZmZXJlbmNlcyBiZXR3ZWVuClth
XSBhbmQgW2JdPyBXaHkgZG9lcyBbYV0gbGVhZCB0byBhbiBlcnJvcj8gQW5kIFtiXSBpcyBhbHdh
eXMgcmlnaHQgZm9yIHVzPwoKCj09PT09PT09PT09PT09PT09PT09PT09PT09PQpbY10gU29tZSBv
dGhlciBjb25mdXNpb25zCj09PT09PT09PT09PT09PT09PT09PT09PT09PQpTb21ldGltZXMgaSBj
YW4gbm90IGdldCBhIGRldmljZSBieSAndGFwLWN0bCBjcmVhdGUgIC1hIGFyZ3MnLiBJdCBzYXlz
CmkgaGFwcGVuIHRvIHNvbWUKZXJyb3JzLiBBZnRlciBpIGRvIHNlcGFyYXRlIHN0ZXBzIG9mICd0
YXAtY3RsIGNyZWF0ZScsIGl0IGxvb2tzIHdlbGwKZm9yIG1lLiBJIHdpbGwgc2hvdyB5b3UKYSBj
b25jcmV0ZSBleGFtcGxlLgoKdGhlIHdyb25nIHdheQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
IyB0YXAtY3RsIGNyZWF0ZSAtYSB0YXAyOnZoZDovaG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEuc3lz
LmltZwojIHRhcC1jdGwgbGlzdAojIHRhcC1jdGwgY3JlYXRlIC1hIHRhcGRpc2s6dmhkOi9ob21l
L2ppYXdlaS93b3Jrc2hvcDEvMS5zeXMuaW1nCiMgY2F0IC92YXIvbG9nL21lc3NhZ2VzIHwgdGFp
bCAtMjAKLi4uCkZlYiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIxYSB0YXBkaXNrMlsxMTcx
XTogSS9PIHF1ZXVlIGRyaXZlcjogbGlvCkZlYiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIx
YSB0YXBkaXNrMlsxMTcxXTogcmVjZWl2ZWQgJ2F0dGFjaCcKbWVzc2FnZSAodXVpZCA9IDApCkZl
YiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIxYSB0YXBkaXNrMlsxMTcxXTogc2VuZGluZyAn
YXR0YWNoCnJlc3BvbnNlJyBtZXNzYWdlICh1dWlkID0gMCkKRmViIDI1IDIyOjUwOjIwIGxvY2Fs
MDAyMTIyMDEwMjFhIHRhcGRpc2syWzExNzFdOiByZWNlaXZlZCAnb3BlbicKbWVzc2FnZSAodXVp
ZCA9IDApCkZlYiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIxYSB0YXBkaXNrMlsxMTcxXTog
c2VuZGluZyAnZXJyb3InCm1lc3NhZ2UgKHV1aWQgPSAwKQpGZWIgMjUgMjI6NTA6MjAgbG9jYWww
MDIxMjIwMTAyMWEgdGFwLWN0bDogdGFwLWVycjp0YXBfY3RsX29wZW46IG9wZW4KZmFpbGVkLCBl
cnIgLTIKRmViIDI1IDIyOjUwOjIwIGxvY2FsMDAyMTIyMDEwMjFhIHRhcGRpc2syWzExNzFdOiBy
ZWNlaXZlZCAnZGV0YWNoJwptZXNzYWdlICh1dWlkID0gMCkKRmViIDI1IDIyOjUwOjIwIGxvY2Fs
MDAyMTIyMDEwMjFhIHRhcGRpc2syWzExNzFdOiBzZW5kaW5nICdkZXRhY2gKcmVzcG9uc2UnIG1l
c3NhZ2UgKHV1aWQgPSAwKQouLi4uLgoKCnRoZSByaWdodCB3YXkKLS0tLS0tLS0tLS0tLS0tLS0t
LS0KW3Jvb3RAbG9jYWwwMDIxMjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBhdHRhY2gKdXNh
Z2U6IGF0dGFjaCA8LXAgcGlkPiA8LW0gbWlub3I+Cltyb290QGxvY2FsMDAyMTIyMDEwMjFhIHdv
cmtzaG9wMV0jIHRhcC1jdGwgbGlzdAogICAgMTE5NCAgLSAgICAtICAgICAgICAgIC0gLQpbcm9v
dEBsb2NhbDAwMjEyMjAxMDIxYSB3b3Jrc2hvcDFdIyB0YXAtY3RsIGF0dGFjaCAtcCAxMTk0IC1t
IDAKW3Jvb3RAbG9jYWwwMDIxMjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBsaXN0CiAgICAx
MTk0ICAtICAgIC0gICAgICAgICAgLSAtCltyb290QGxvY2FsMDAyMTIyMDEwMjFhIHdvcmtzaG9w
MV0jIHRhcC1jdGwgYWxsb2NhdGUKL2Rldi94ZW4vYmxrdGFwLTIvdGFwZGV2MApbcm9vdEBsb2Nh
bDAwMjEyMjAxMDIxYSB3b3Jrc2hvcDFdIyB0YXAtY3RsIGxpc3QKICAgIDExOTQgIC0gICAgLSAg
ICAgICAgICAtIC0KICAgICAgIC0gIDAgICAgLSAgICAgICAgICAtIC0KW3Jvb3RAbG9jYWwwMDIx
MjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBhdHRhY2ggLXAgMTE5NCAtbSAwCltyb290QGxv
Y2FsMDAyMTIyMDEwMjFhIHdvcmtzaG9wMV0jIHRhcC1jdGwgbGlzdAogICAgMTE5NCAgMCAgICAw
ICAgICAgICAgIC0gLQpbcm9vdEBsb2NhbDAwMjEyMjAxMDIxYSB3b3Jrc2hvcDFdIyB0YXAtY3Rs
IG9wZW4KdXNhZ2U6IG9wZW4gPC1wIHBpZD4gPC1tIG1pbm9yPiA8LWEgYXJncz4KW3Jvb3RAbG9j
YWwwMDIxMjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBvcGVuIC1wIDExOTQgLW0gMCAtYQp2
aGQ6L2hvbWUvamlhd2VpL3dvcmtzaG9wMS8xLnN5cy5pbWcKW3Jvb3RAbG9jYWwwMDIxMjIwMTAy
MWEgd29ya3Nob3AxXSMgdGFwLWN0bCBsaXN0CiAgICAxMTk0ICAwICAgIDAgICAgICAgIHZoZCAv
aG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEuc3lzLmltZwoKCkFmdGVyICd0aGUgd3Jvbmcgd2F5JyBh
bmQgJ3RoZSByaWdodCB3YXknLCBpIHRoaW5rIHRoZSB0d28gd2F5cyBoYXZlCmRpZmZlcmVudCBt
ZWNoYW5pc21zLiBCdXQgaQpkb24ndCB1bmRlcnN0YW5kIHRoZW0gY2xlYXJseS4gQ2xvdWQgYW55
b25lIHRlbGwgbWUgdGhlIG9uZXMgPwoKLS0gClRoYW5rcwpIYXJyeSBXZWkKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Sat Feb 25 17:39:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 17:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1LaR-0003bE-11; Sat, 25 Feb 2012 17:39:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <harryxiyou@gmail.com>) id 1S1LaP-0003au-CF
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 17:39:09 +0000
X-Env-Sender: harryxiyou@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330191541!13017983!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19084 invoked from network); 25 Feb 2012 17:39:02 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 17:39:02 -0000
Received: by lagr15 with SMTP id r15so2576325lag.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 09:39:01 -0800 (PST)
Received-SPF: pass (google.com: domain of harryxiyou@gmail.com designates
	10.112.103.228 as permitted sender) client-ip=10.112.103.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of harryxiyou@gmail.com
	designates 10.112.103.228 as permitted sender)
	smtp.mail=harryxiyou@gmail.com;
	dkim=pass header.i=harryxiyou@gmail.com
Received: from mr.google.com ([10.112.103.228])
	by 10.112.103.228 with SMTP id fz4mr2706257lbb.99.1330191541543
	(num_hops = 1); Sat, 25 Feb 2012 09:39:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=KDNBadCKKNhSaplm4cBHvNs2Gcxd1N5qJb+ZX08+SOM=;
	b=shQDw0lJITjy3D6g2XeSbWDwu7Y1+/hhjQA1bO+F3durIxuy7YhYEMT2BH+MXQJS2K
	l8/2no7zp3ksCs71R7zDZnVoR7Jf+cWDcAVc0kfTtsC2cZJnUF++Xct6lmpYMbC3Fy+Y
	q0dN1Jg4m9PYDpSulVlZi+hCYLsX6MXrr0+50=
MIME-Version: 1.0
Received: by 10.112.103.228 with SMTP id fz4mr2243507lbb.99.1330191541274;
	Sat, 25 Feb 2012 09:39:01 -0800 (PST)
Received: by 10.112.81.2 with HTTP; Sat, 25 Feb 2012 09:39:01 -0800 (PST)
Date: Sun, 26 Feb 2012 01:39:01 +0800
Message-ID: <CAD+1EGNSnxVvrqbZm3ddVur3kpT_hsxR74OCZW7z3y=93K6T=w@mail.gmail.com>
From: harryxiyou <harryxiyou@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xensource.com
Cc: cloudxy@googlegroups.com, Kang Hua <kanghua151@gmail.com>,
	=?UTF-8?B?55Sw5bq35aWH?= <kangqi1988@gmail.com>
Subject: [Xen-devel] [RFC]Some questions about xen-4.1.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgbGlzdCwKCk1heWJlIGkgc2hvdWxkIG5vdCBhc2sgcXVlc3Rpb25zIGhlcmUuIElmIHRydWUs
IHBsZWFzZSBmb3JnaXZlIG1lIDstKQoKCkkgYnVpbGQgeGVuIGVudmlyb25tZW50IHVuZGVyIENl
bnRvcy01LjQuTXkgZW52IGlzIGxpa2UgdGhpcy4KClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODld
IElORk8gKFhlbmREb21haW5JbmZvOjMyNjkpIE1vdW50aW5nCi9ob21lL2ppYXdlaS93b3Jrc2hv
cDEvMS5zeXMuaW1nIG9uIC9kZXYveHZkcC4KWzIwMTItMDItMjUgMjM6NTE6MTkgNDc4OV0gREVC
VUcgKERldkNvbnRyb2xsZXI6OTUpIERldkNvbnRyb2xsZXI6CndyaXRpbmcgeydiYWNrZW5kLWlk
JzogJzAnLCAndmlydHVhbC1kZXZpY2UnOiAnNTE5NTInLAonZGV2aWNlLXR5cGUnOiAnZGlzaycs
ICdzdGF0ZSc6ICcxJywgJ2JhY2tlbmQnOgonL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzAv
NTE5NTInfSB0bwovbG9jYWwvZG9tYWluLzAvZGV2aWNlL3ZiZC81MTk1Mi4KTGludXggbG9jYWww
MDIxMjIwMTAyMWEuenRlLmNvbS5jbiAyLjYuMzIuMzkgIzEgU01QIFN1biBGZWIgMTkKMTE6MjE6
MDkgQ1NUIDIwMTIgeDg2XzY0IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4CiMgeG0gaW5mbwpob3N0
ICAgICAgICAgICAgICAgICAgIDogbG9jYWwwMDIxMjIwMTAyMWEuenRlLmNvbS5jbgpyZWxlYXNl
ICAgICAgICAgICAgICAgIDogMi42LjMyLjM5CnZlcnNpb24gICAgICAgICAgICAgICAgOiAjMSBT
TVAgU3VuIEZlYiAxOSAxMToyMTowOSBDU1QgMjAxMgptYWNoaW5lICAgICAgICAgICAgICAgIDog
eDg2XzY0Cm5yX2NwdXMgICAgICAgICAgICAgICAgOiAyCm5yX25vZGVzICAgICAgICAgICAgICAg
OiAxCmNvcmVzX3Blcl9zb2NrZXQgICAgICAgOiAyCnRocmVhZHNfcGVyX2NvcmUgICAgICAgOiAx
CmNwdV9taHogICAgICAgICAgICAgICAgOiAxNzk1Cmh3X2NhcHMgICAgICAgICAgICAgICAgOgpi
ZmViZmJmZjoyMDEwMDgwMDowMDAwMDAwMDowMDAwMDk0MDowMDAwZTMxZDowMDAwMDAwMDowMDAw
MDAwMTowMDAwMDAwMAp2aXJ0X2NhcHMgICAgICAgICAgICAgIDoKdG90YWxfbWVtb3J5ICAgICAg
ICAgICA6IDk4NApmcmVlX21lbW9yeSAgICAgICAgICAgIDogNjY1CmZyZWVfY3B1cyAgICAgICAg
ICAgICAgOiAwCnhlbl9tYWpvciAgICAgICAgICAgICAgOiA0Cnhlbl9taW5vciAgICAgICAgICAg
ICAgOiAxCnhlbl9leHRyYSAgICAgICAgICAgICAgOiAuMQp4ZW5fY2FwcyAgICAgICAgICAgICAg
IDogeGVuLTMuMC14ODZfNjQgeGVuLTMuMC14ODZfMzJwCnhlbl9zY2hlZHVsZXIgICAgICAgICAg
OiBjcmVkaXQKeGVuX3BhZ2VzaXplICAgICAgICAgICA6IDQwOTYKcGxhdGZvcm1fcGFyYW1zICAg
ICAgICA6IHZpcnRfc3RhcnQ9MHhmZmZmODAwMDAwMDAwMDAwCnhlbl9jaGFuZ2VzZXQgICAgICAg
ICAgOiB1bmF2YWlsYWJsZQp4ZW5fY29tbWFuZGxpbmUgICAgICAgIDoKY2NfY29tcGlsZXIgICAg
ICAgICAgICA6IGdjYyB2ZXJzaW9uIDQuMS4yIDIwMDgwNzA0IChSZWQgSGF0IDQuMS4yLTUxKQpj
Y19jb21waWxlX2J5ICAgICAgICAgIDogcm9vdApjY19jb21waWxlX2RvbWFpbiAgICAgIDogenRl
LmNvbS5jbgpjY19jb21waWxlX2RhdGUgICAgICAgIDogVGh1IEZlYiAyMyAyMzozMjowMSBDU1Qg
MjAxMgp4ZW5kX2NvbmZpZ19mb3JtYXQgICAgIDogNAoKCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09ClthXSBXZSBnZXQgYW4gZXJyb3IgYnkgcnVubmluZyBmb2xsb3dpbmcgc3RlcHMu
Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CjEsIE1ha2luZyBhIGRlbHRhIHBsYXRl
IGJ5IHZoZC11dGlsCiMgdmhkLXV0aWwgc25hcHNob3QgLW4gL2hvbWUvamlhd2VpL3dvcmtzaG9w
MS8xLnN5cy5pbWcgLXAKL2hvbWUvamlhd2VpL3dvcmtzaG9wMS9kb21VLXg4Nl82NC1GUy5pbWcg
LW0KCjLvvIxzdGFydCBhIGRvbXUKIyB4bSBjciBweWdydWIuY29uZgpVc2luZyBjb25maWcgZmls
ZSAiLi9weWdydWIuY29uZiIuCkVycm9yOiBEaXNrIGlzbid0IGFjY2Vzc2libGUKCiMgY2F0IHB5
Z3J1Yi5jb25mCm5hbWUgPSAidHR5bGludXgiCm1lbW9yeSA9IDUxMgp2Y3B1cyA9IDEKdmlmID0g
WyAnYnJpZGdlPXZpcmJyMCcgXQpvbl9yZWJvb3QgPSAncmVzdGFydCcKb25fY3Jhc2ggPSAncmVz
dGFydCcKYm9vdGxvYWRlciA9ICIvdXNyL2Jpbi9weWdydWIiCmRpc2sgPSBbJ3RhcDI6dmhkOi9o
b21lL2ppYXdlaS93b3Jrc2hvcDEvMS5pbWcsc2RhLHcnXQoKQmUgc3VyZSB3ZSBoYXZlIGEgY29y
cmVjdCByYXcgaW1hZ2UKL2hvbWUvamlhd2VpL3dvcmtzaG9wMS9kb21VLXg4Nl82NC1GUy5pbWcg
YmVjYXN1ZQp3ZSBoYXZlIHRlc3RlZCBpdC4gQnV0IGluIHRoaXMgY29uZGl0aW9uIHdlIGNhbiBn
ZXQgYSB0YXBkaXNrIGRldmljZS4KRGV0YWlscyBhcmUgaGVyZS4KCltyb290QGxvY2FsMDAyMTIy
MDEwMjFhIHdvcmtzaG9wMV0jIHRhcC1jdGwgY3JlYXRlIC1hCnZoZDovaG9tZS9qaWF3ZWkvd29y
a3Nob3AxLzEuaW1nCi9kZXYveGVuL2Jsa3RhcC0yL3RhcGRldjAKW3Jvb3RAbG9jYWwwMDIxMjIw
MTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBsaXN0CiAgICA1ODM1ICAwICAgIDAgICAgICAgIHZo
ZCAvaG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEuaW1nCgoKQXQgbGFzdCB3ZSB0YWtlIHNvbWUgeGVu
IGxvZ3MgZnJvbSBkaXJlY3RvcnkgL3Zhci9sb2cveGVuL3hlbi5sb2cgbGlrZSB0aGlzLgoKLi4u
ClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChYZW5kRG9tYWluSW5mbzoxMDMpClhl
bmREb21haW5JbmZvLmNyZWF0ZShbJ3ZtJywgWyduYW1lJywgJ3R0eWxpbnV4J10sIFsnbWVtb3J5
JywgNTEyXSwKWydvbl9yZWJvb3QnLCAncmVzdGFydCddLCBbJ29uX2NyYXNoJywgJ3Jlc3RhcnQn
XSwgWydvbl94ZW5kX3N0YXJ0JywKJ2lnbm9yZSddLCBbJ29uX3hlbmRfc3RvcCcsICdpZ25vcmUn
XSwgWyd2Y3B1cycsIDFdLCBbJ29vcycsIDFdLApbJ2Jvb3Rsb2FkZXInLCAnL3Vzci9iaW4vcHln
cnViJ10sIFsnYm9vdGxvYWRlcl9hcmdzJywgJy1xJ10sClsnaW1hZ2UnLCBbJ2xpbnV4JywgWyd2
aWRlb3JhbScsIDRdLCBbJ3RzY19tb2RlJywgMF0sIFsnbm9taWdyYXRlJywKMF1dXSwgWydzM19p
bnRlZ3JpdHknLCAxXSwgWydkZXZpY2UnLCBbJ3RhcDInLCBbJ3VuYW1lJywKJ3RhcDI6dmhkOi9o
b21lL2ppYXdlaS93b3Jrc2hvcDEvMS5zeXMuaW1nJ10sIFsnZGV2JywgJ3h2ZGEnXSwKWydtb2Rl
JywgJ3cnXV1dLCBbJ2RldmljZScsIFsndmlmJywgWydicmlkZ2UnLCAndmlyYnIwJ11dXV0pClsy
MDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChYZW5kRG9tYWluSW5mbzoyNDk4KQpYZW5k
RG9tYWluSW5mby5jb25zdHJ1Y3REb21haW4KWzIwMTItMDItMjUgMjM6NTE6MTkgNDc4OV0gREVC
VUcgKGJhbGxvb246MTg3KSBCYWxsb29uOiA1NDE4MzYgS2lCCmZyZWU7IG5lZWQgMTYzODQ7IGRv
bmUuClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChYZW5kRG9tYWluOjQ3NikgQWRk
aW5nIERvbWFpbjogMzQKWzIwMTItMDItMjUgMjM6NTE6MTkgNDc4OV0gREVCVUcgKFhlbmREb21h
aW5JbmZvOjI4MzYpClhlbmREb21haW5JbmZvLmluaXREb21haW46IDM0IDI1NgpbMjAxMi0wMi0y
NSAyMzo1MToxOSA0Nzg5XSBJTkZPIChYZW5kRG9tYWluSW5mbzozMjY5KSBNb3VudGluZwovaG9t
ZS9qaWF3ZWkvd29ya3Nob3AxLzEuc3lzLmltZyBvbiAvZGV2L3h2ZHAuClsyMDEyLTAyLTI1IDIz
OjUxOjE5IDQ3ODldIERFQlVHIChEZXZDb250cm9sbGVyOjk1KSBEZXZDb250cm9sbGVyOgp3cml0
aW5nIHsnYmFja2VuZC1pZCc6ICcwJywgJ3ZpcnR1YWwtZGV2aWNlJzogJzUxOTUyJywgJ2Rldmlj
ZS10eXBlJzoKJ2Rpc2snLCAnc3RhdGUnOiAnMScsICdiYWNrZW5kJzoKJy9sb2NhbC9kb21haW4v
MC9iYWNrZW5kL3ZiZC8wLzUxOTUyJ30gdG8KL2xvY2FsL2RvbWFpbi8wL2RldmljZS92YmQvNTE5
NTIuClsyMDEyLTAyLTI1IDIzOjUxOjE5IDQ3ODldIERFQlVHIChEZXZDb250cm9sbGVyOjk3KSBE
ZXZDb250cm9sbGVyOgp3cml0aW5nIHsnZG9tYWluJzogJ0RvbWFpbi0wJywgJ2Zyb250ZW5kJzoK
Jy9sb2NhbC9kb21haW4vMC9kZXZpY2UvdmJkLzUxOTUyJywgJ3V1aWQnOgonNjc3MmY3NmQtMTFi
MC0yNDZlLWI0ODMtZTlmYzEwNTZkZjEzJywgJ2Jvb3RhYmxlJzogJzAnLCAnZGV2JzoKJy9kZXYv
eHZkcCcsICdzdGF0ZSc6ICcxJywgJ3BhcmFtcyc6ICcvZGV2L3hlbi9ibGt0YXAtMi90YXBkZXYx
JywKJ21vZGUnOiAncicsICdvbmxpbmUnOiAnMScsICdmcm9udGVuZC1pZCc6ICcwJywgJ3R5cGUn
OiAncGh5JywKJ3RhcGRpc2stcGFyYW1zJzogJ3ZoZDovaG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEu
c3lzLmltZyd9IHRvCi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8wLzUxOTUyLgpbMjAxMi0w
Mi0yNSAyMzo1MToxOSA0Nzg5XSBERUJVRyAoRGV2Q29udHJvbGxlcjoxNDQpIFdhaXRpbmcgZm9y
IDUxOTUyLgpbMjAxMi0wMi0yNSAyMzo1MToxOSA0Nzg5XSBERUJVRyAoRGV2Q29udHJvbGxlcjo2
MjgpCmhvdHBsdWdTdGF0dXNDYWxsYmFjawovbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMC81
MTk1Mi9ob3RwbHVnLXN0YXR1cy4KWzIwMTItMDItMjUgMjM6NTE6MjAgNDc4OV0gREVCVUcgKERl
dkNvbnRyb2xsZXI6NjI4KQpob3RwbHVnU3RhdHVzQ2FsbGJhY2sKL2xvY2FsL2RvbWFpbi8wL2Jh
Y2tlbmQvdmJkLzAvNTE5NTIvaG90cGx1Zy1zdGF0dXMuClsyMDEyLTAyLTI1IDIzOjUxOjIwIDQ3
ODldIERFQlVHIChEZXZDb250cm9sbGVyOjY0MikgaG90cGx1Z1N0YXR1c0NhbGxiYWNrIDEuClsy
MDEyLTAyLTI1IDIzOjUxOjIwIDQ3ODldIERFQlVHIChEZXZDb250cm9sbGVyOjE0NCkgV2FpdGlu
ZyBmb3IgNTE5NTIuClsyMDEyLTAyLTI1IDIzOjUxOjIwIDQ3ODldIERFQlVHIChEZXZDb250cm9s
bGVyOjYyOCkKaG90cGx1Z1N0YXR1c0NhbGxiYWNrCi9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3Zi
ZC8wLzUxOTUyL2hvdHBsdWctc3RhdHVzLgpbMjAxMi0wMi0yNSAyMzo1MToyMCA0Nzg5XSBERUJV
RyAoRGV2Q29udHJvbGxlcjo2NDIpIGhvdHBsdWdTdGF0dXNDYWxsYmFjayAxLgpbMjAxMi0wMi0y
NSAyMzo1MToyMCA0Nzg5XSBFUlJPUiAoWGVuZEJvb3Rsb2FkZXI6NDMpIERpc2sgaXNuJ3QgYWNj
ZXNzaWJsZQouLi4KCldlIHRoaW5rIHRoYXQgdGhlcmUgYXJlIHNvbWV0aGluZyB3cm9uZyB3aXRo
IHRoZSBkZXZpY2UgL2Rldi94dmRwLiBBbmQKaXRzICpEZXZDb250cm9sbGVyKiBwcm9jZXNzCjUx
OTUyIGNhbiBub3QgZ2V0IGl0cyBjb3JyZWN0aXZlIHN0YXR1cyBmb3IgaG90cGx1Zy4gU28gZXJy
b3IgaGFwcGVucwp0byB1cy4gUmlnaHQ/CgoKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQpbYl1CdXQgd2UgY2FuIGxhdW5jaCBhIGRvbXUgbGlrZSBmb2xs
b3dpbmcgc3RlcHMgc3VjY2Vzc2Z1bGx5Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT0KCjEsIFRhcC1jdGwgY3JlYXRlIGEgZGV2aWNlCiMgdGFwLWN0bCBj
cmVhdGUgLWEgdmhkOi9ob21lL2ppYXdlaS93b3Jrc2hvcDEvMS5pbWcKL2Rldi94ZW4vYmxrdGFw
LTIvdGFwZGV2MAojIHRhcC1jdGwgbGlzdAo1ODM1ICAwICAgIDAgICAgICAgIHZoZCAvaG9tZS9q
aWF3ZWkvd29ya3Nob3AxLzEuaW1nCgoyLCBTdGFydCBkb211CiMgeG0gY3IgcHlncnViMS5jb25m
ClVzaW5nIGNvbmZpZyBmaWxlICIuL3B5Z3J1YjEuY29uZiIuClN0YXJ0ZWQgZG9tYWluIHR0eWxp
bnV4IChpZD00NCkKIyBjYXQgcHlncnViMS5jb25mCm1lbW9yeSA9IDUxMgpuYW1lID0gInR0eWxp
bnV4Igpib290bG9hZGVyID0gIi91c3IvYmluL3B5Z3J1YiIKZGlzayA9IFsncGh5Oi9kZXYveGVu
L2Jsa3RhcC0yL3RhcGRldjAseHZkYTEsdyddCgpCeSB1cCBzdGVwcywgd2UgZG8gZ2V0IGEgZG9t
dS4gQ291bGQgYW55b25lIHRlbGwgbWUgdGhlIGRldGFpbApkaWZmZXJlbmNlcyBiZXR3ZWVuClth
XSBhbmQgW2JdPyBXaHkgZG9lcyBbYV0gbGVhZCB0byBhbiBlcnJvcj8gQW5kIFtiXSBpcyBhbHdh
eXMgcmlnaHQgZm9yIHVzPwoKCj09PT09PT09PT09PT09PT09PT09PT09PT09PQpbY10gU29tZSBv
dGhlciBjb25mdXNpb25zCj09PT09PT09PT09PT09PT09PT09PT09PT09PQpTb21ldGltZXMgaSBj
YW4gbm90IGdldCBhIGRldmljZSBieSAndGFwLWN0bCBjcmVhdGUgIC1hIGFyZ3MnLiBJdCBzYXlz
CmkgaGFwcGVuIHRvIHNvbWUKZXJyb3JzLiBBZnRlciBpIGRvIHNlcGFyYXRlIHN0ZXBzIG9mICd0
YXAtY3RsIGNyZWF0ZScsIGl0IGxvb2tzIHdlbGwKZm9yIG1lLiBJIHdpbGwgc2hvdyB5b3UKYSBj
b25jcmV0ZSBleGFtcGxlLgoKdGhlIHdyb25nIHdheQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
IyB0YXAtY3RsIGNyZWF0ZSAtYSB0YXAyOnZoZDovaG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEuc3lz
LmltZwojIHRhcC1jdGwgbGlzdAojIHRhcC1jdGwgY3JlYXRlIC1hIHRhcGRpc2s6dmhkOi9ob21l
L2ppYXdlaS93b3Jrc2hvcDEvMS5zeXMuaW1nCiMgY2F0IC92YXIvbG9nL21lc3NhZ2VzIHwgdGFp
bCAtMjAKLi4uCkZlYiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIxYSB0YXBkaXNrMlsxMTcx
XTogSS9PIHF1ZXVlIGRyaXZlcjogbGlvCkZlYiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIx
YSB0YXBkaXNrMlsxMTcxXTogcmVjZWl2ZWQgJ2F0dGFjaCcKbWVzc2FnZSAodXVpZCA9IDApCkZl
YiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIxYSB0YXBkaXNrMlsxMTcxXTogc2VuZGluZyAn
YXR0YWNoCnJlc3BvbnNlJyBtZXNzYWdlICh1dWlkID0gMCkKRmViIDI1IDIyOjUwOjIwIGxvY2Fs
MDAyMTIyMDEwMjFhIHRhcGRpc2syWzExNzFdOiByZWNlaXZlZCAnb3BlbicKbWVzc2FnZSAodXVp
ZCA9IDApCkZlYiAyNSAyMjo1MDoyMCBsb2NhbDAwMjEyMjAxMDIxYSB0YXBkaXNrMlsxMTcxXTog
c2VuZGluZyAnZXJyb3InCm1lc3NhZ2UgKHV1aWQgPSAwKQpGZWIgMjUgMjI6NTA6MjAgbG9jYWww
MDIxMjIwMTAyMWEgdGFwLWN0bDogdGFwLWVycjp0YXBfY3RsX29wZW46IG9wZW4KZmFpbGVkLCBl
cnIgLTIKRmViIDI1IDIyOjUwOjIwIGxvY2FsMDAyMTIyMDEwMjFhIHRhcGRpc2syWzExNzFdOiBy
ZWNlaXZlZCAnZGV0YWNoJwptZXNzYWdlICh1dWlkID0gMCkKRmViIDI1IDIyOjUwOjIwIGxvY2Fs
MDAyMTIyMDEwMjFhIHRhcGRpc2syWzExNzFdOiBzZW5kaW5nICdkZXRhY2gKcmVzcG9uc2UnIG1l
c3NhZ2UgKHV1aWQgPSAwKQouLi4uLgoKCnRoZSByaWdodCB3YXkKLS0tLS0tLS0tLS0tLS0tLS0t
LS0KW3Jvb3RAbG9jYWwwMDIxMjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBhdHRhY2gKdXNh
Z2U6IGF0dGFjaCA8LXAgcGlkPiA8LW0gbWlub3I+Cltyb290QGxvY2FsMDAyMTIyMDEwMjFhIHdv
cmtzaG9wMV0jIHRhcC1jdGwgbGlzdAogICAgMTE5NCAgLSAgICAtICAgICAgICAgIC0gLQpbcm9v
dEBsb2NhbDAwMjEyMjAxMDIxYSB3b3Jrc2hvcDFdIyB0YXAtY3RsIGF0dGFjaCAtcCAxMTk0IC1t
IDAKW3Jvb3RAbG9jYWwwMDIxMjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBsaXN0CiAgICAx
MTk0ICAtICAgIC0gICAgICAgICAgLSAtCltyb290QGxvY2FsMDAyMTIyMDEwMjFhIHdvcmtzaG9w
MV0jIHRhcC1jdGwgYWxsb2NhdGUKL2Rldi94ZW4vYmxrdGFwLTIvdGFwZGV2MApbcm9vdEBsb2Nh
bDAwMjEyMjAxMDIxYSB3b3Jrc2hvcDFdIyB0YXAtY3RsIGxpc3QKICAgIDExOTQgIC0gICAgLSAg
ICAgICAgICAtIC0KICAgICAgIC0gIDAgICAgLSAgICAgICAgICAtIC0KW3Jvb3RAbG9jYWwwMDIx
MjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBhdHRhY2ggLXAgMTE5NCAtbSAwCltyb290QGxv
Y2FsMDAyMTIyMDEwMjFhIHdvcmtzaG9wMV0jIHRhcC1jdGwgbGlzdAogICAgMTE5NCAgMCAgICAw
ICAgICAgICAgIC0gLQpbcm9vdEBsb2NhbDAwMjEyMjAxMDIxYSB3b3Jrc2hvcDFdIyB0YXAtY3Rs
IG9wZW4KdXNhZ2U6IG9wZW4gPC1wIHBpZD4gPC1tIG1pbm9yPiA8LWEgYXJncz4KW3Jvb3RAbG9j
YWwwMDIxMjIwMTAyMWEgd29ya3Nob3AxXSMgdGFwLWN0bCBvcGVuIC1wIDExOTQgLW0gMCAtYQp2
aGQ6L2hvbWUvamlhd2VpL3dvcmtzaG9wMS8xLnN5cy5pbWcKW3Jvb3RAbG9jYWwwMDIxMjIwMTAy
MWEgd29ya3Nob3AxXSMgdGFwLWN0bCBsaXN0CiAgICAxMTk0ICAwICAgIDAgICAgICAgIHZoZCAv
aG9tZS9qaWF3ZWkvd29ya3Nob3AxLzEuc3lzLmltZwoKCkFmdGVyICd0aGUgd3Jvbmcgd2F5JyBh
bmQgJ3RoZSByaWdodCB3YXknLCBpIHRoaW5rIHRoZSB0d28gd2F5cyBoYXZlCmRpZmZlcmVudCBt
ZWNoYW5pc21zLiBCdXQgaQpkb24ndCB1bmRlcnN0YW5kIHRoZW0gY2xlYXJseS4gQ2xvdWQgYW55
b25lIHRlbGwgbWUgdGhlIG9uZXMgPwoKLS0gClRoYW5rcwpIYXJyeSBXZWkKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Sat Feb 25 19:22:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 19:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1NBy-0004Sg-W3; Sat, 25 Feb 2012 19:22:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1NBx-0004Sb-Cs
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 19:22:01 +0000
Received: from [85.158.139.83:4327] by server-8.bemta-5.messagelabs.com id
	DB/9E-09797-8D4394F4; Sat, 25 Feb 2012 19:22:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330197719!16616476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21294 invoked from network); 25 Feb 2012 19:22:00 -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;
	25 Feb 2012 19:22:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,482,1325462400"; d="scan'208";a="10935108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 19:21:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 19:21:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1NBv-0004l3-4P;
	Sat, 25 Feb 2012 19:21:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1NBu-0007gz-Nb;
	Sat, 25 Feb 2012 19:21:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12065-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 19:21:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12065: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12065 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12065/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 19:22:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 19:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1NBy-0004Sg-W3; Sat, 25 Feb 2012 19:22:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1NBx-0004Sb-Cs
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 19:22:01 +0000
Received: from [85.158.139.83:4327] by server-8.bemta-5.messagelabs.com id
	DB/9E-09797-8D4394F4; Sat, 25 Feb 2012 19:22:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330197719!16616476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21294 invoked from network); 25 Feb 2012 19:22:00 -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;
	25 Feb 2012 19:22:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,482,1325462400"; d="scan'208";a="10935108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2012 19:21:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 25 Feb 2012 19:21:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1NBv-0004l3-4P;
	Sat, 25 Feb 2012 19:21:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1NBu-0007gz-Nb;
	Sat, 25 Feb 2012 19:21:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12065-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 25 Feb 2012 19:21:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12065: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12065 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12065/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 20:39:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 20: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 1S1OO2-0004q9-LN; Sat, 25 Feb 2012 20:38:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qi.zhezhi@gmail.com>) id 1S1OO1-0004q4-5U
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 20:38:33 +0000
X-Env-Sender: qi.zhezhi@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330202305!14921573!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16534 invoked from network); 25 Feb 2012 20:38:26 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 20:38:26 -0000
Received: by iaeh11 with SMTP id h11so15407158iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 12:38:24 -0800 (PST)
Received-SPF: pass (google.com: domain of qi.zhezhi@gmail.com designates
	10.42.156.7 as permitted sender) client-ip=10.42.156.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of qi.zhezhi@gmail.com
	designates 10.42.156.7 as permitted sender)
	smtp.mail=qi.zhezhi@gmail.com;
	dkim=pass header.i=qi.zhezhi@gmail.com
Received: from mr.google.com ([10.42.156.7])
	by 10.42.156.7 with SMTP id x7mr8033974icw.56.1330202304952 (num_hops =
	1); Sat, 25 Feb 2012 12:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=LB6mbt2awjxV7b0H88sMJc2qVoIrjCEJ/Ih0KrsjRDQ=;
	b=hnse7sTVyHjopkuZiQ1dUqdGlbbpA/uolCsXmQ7npZr4nqeeeSuq3wBu7+ME1EOSu2
	wiSQ8iqOm8VvcS4pVygKMHNEeiOWWT88bHngvA/PiKkX7BZDDEOTzd8Nof6mk9h5O2K3
	GXxm+9C3pAyVNoZH4rNQuAxItjRMUf2s7rWUY=
MIME-Version: 1.0
Received: by 10.42.156.7 with SMTP id x7mr6418256icw.56.1330202304849; Sat, 25
	Feb 2012 12:38:24 -0800 (PST)
Received: by 10.42.168.201 with HTTP; Sat, 25 Feb 2012 12:38:24 -0800 (PST)
Date: Sun, 26 Feb 2012 04:38:24 +0800
Message-ID: <CAPL=jHdbVg5=8rkxG8YW30NWn3RXw28enhNgNyJEM9=iC3h0yQ@mail.gmail.com>
From: =?GB2312?B?xuvV3Nau?= <qi.zhezhi@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] problems about the drives 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="===============5611888875044521863=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5611888875044521863==
Content-Type: multipart/alternative; boundary=90e6ba6e85d4dc25dc04b9cfdb39

--90e6ba6e85d4dc25dc04b9cfdb39
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

These days,we've updated many Broadcom NetXtreme II 5709 Drives to 2.0.8e
on xen kernel.
In order to making the  updates successful,we have no idea but to reboot
the system.

As on the physical system,we update the drives in this way successfully:
updates,rmmod,depmod,modprobe
it may just a few seconds cut off the net.
But on a xen,if we rmmod,the net won't recover until rebooting the physical
server.

*But we have many inportant services on the xen kernel system.
If we reboot the xen server,it will take a few minutes,and one physical
server has many xens on it.
It will cost so much.
How can I avoid rebooting the server,at the same time,make the drives
update successful on xen kernel?
*
Best Regards,
Jasonqi

--90e6ba6e85d4dc25dc04b9cfdb39
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br>
<br>
These days,we&#39;ve updated many Broadcom NetXtreme II 5709 Drives to 2.0.=
8e on xen kernel.<br>
In order to making the=A0 updates successful,we have no idea but to reboot =
the system.<br>
<br>
As on the physical system,we update the drives in this way successfully:<br=
>
updates,rmmod,depmod,modprobe<br>
it may just a few seconds cut off the net.<br>But on a xen,if we rmmod,the =
net won&#39;t recover until rebooting the physical server.<br>
<br>
<b>But we have many inportant services on the xen kernel system.<br>
If we reboot the xen server,it will take a few minutes,and one physical ser=
ver has many xens on it.<br>It will cost so much.<br>
How can I avoid rebooting the server,at the same time,make the drives updat=
e successful on xen kernel?<br>
</b><br>
Best Regards,<br>
Jasonqi

--90e6ba6e85d4dc25dc04b9cfdb39--


--===============5611888875044521863==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5611888875044521863==--


From xen-devel-bounces@lists.xen.org Sat Feb 25 20:39:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 20: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 1S1OO2-0004q9-LN; Sat, 25 Feb 2012 20:38:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qi.zhezhi@gmail.com>) id 1S1OO1-0004q4-5U
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 20:38:33 +0000
X-Env-Sender: qi.zhezhi@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330202305!14921573!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16534 invoked from network); 25 Feb 2012 20:38:26 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 20:38:26 -0000
Received: by iaeh11 with SMTP id h11so15407158iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 12:38:24 -0800 (PST)
Received-SPF: pass (google.com: domain of qi.zhezhi@gmail.com designates
	10.42.156.7 as permitted sender) client-ip=10.42.156.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of qi.zhezhi@gmail.com
	designates 10.42.156.7 as permitted sender)
	smtp.mail=qi.zhezhi@gmail.com;
	dkim=pass header.i=qi.zhezhi@gmail.com
Received: from mr.google.com ([10.42.156.7])
	by 10.42.156.7 with SMTP id x7mr8033974icw.56.1330202304952 (num_hops =
	1); Sat, 25 Feb 2012 12:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=LB6mbt2awjxV7b0H88sMJc2qVoIrjCEJ/Ih0KrsjRDQ=;
	b=hnse7sTVyHjopkuZiQ1dUqdGlbbpA/uolCsXmQ7npZr4nqeeeSuq3wBu7+ME1EOSu2
	wiSQ8iqOm8VvcS4pVygKMHNEeiOWWT88bHngvA/PiKkX7BZDDEOTzd8Nof6mk9h5O2K3
	GXxm+9C3pAyVNoZH4rNQuAxItjRMUf2s7rWUY=
MIME-Version: 1.0
Received: by 10.42.156.7 with SMTP id x7mr6418256icw.56.1330202304849; Sat, 25
	Feb 2012 12:38:24 -0800 (PST)
Received: by 10.42.168.201 with HTTP; Sat, 25 Feb 2012 12:38:24 -0800 (PST)
Date: Sun, 26 Feb 2012 04:38:24 +0800
Message-ID: <CAPL=jHdbVg5=8rkxG8YW30NWn3RXw28enhNgNyJEM9=iC3h0yQ@mail.gmail.com>
From: =?GB2312?B?xuvV3Nau?= <qi.zhezhi@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] problems about the drives 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="===============5611888875044521863=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5611888875044521863==
Content-Type: multipart/alternative; boundary=90e6ba6e85d4dc25dc04b9cfdb39

--90e6ba6e85d4dc25dc04b9cfdb39
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

These days,we've updated many Broadcom NetXtreme II 5709 Drives to 2.0.8e
on xen kernel.
In order to making the  updates successful,we have no idea but to reboot
the system.

As on the physical system,we update the drives in this way successfully:
updates,rmmod,depmod,modprobe
it may just a few seconds cut off the net.
But on a xen,if we rmmod,the net won't recover until rebooting the physical
server.

*But we have many inportant services on the xen kernel system.
If we reboot the xen server,it will take a few minutes,and one physical
server has many xens on it.
It will cost so much.
How can I avoid rebooting the server,at the same time,make the drives
update successful on xen kernel?
*
Best Regards,
Jasonqi

--90e6ba6e85d4dc25dc04b9cfdb39
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br>
<br>
These days,we&#39;ve updated many Broadcom NetXtreme II 5709 Drives to 2.0.=
8e on xen kernel.<br>
In order to making the=A0 updates successful,we have no idea but to reboot =
the system.<br>
<br>
As on the physical system,we update the drives in this way successfully:<br=
>
updates,rmmod,depmod,modprobe<br>
it may just a few seconds cut off the net.<br>But on a xen,if we rmmod,the =
net won&#39;t recover until rebooting the physical server.<br>
<br>
<b>But we have many inportant services on the xen kernel system.<br>
If we reboot the xen server,it will take a few minutes,and one physical ser=
ver has many xens on it.<br>It will cost so much.<br>
How can I avoid rebooting the server,at the same time,make the drives updat=
e successful on xen kernel?<br>
</b><br>
Best Regards,<br>
Jasonqi

--90e6ba6e85d4dc25dc04b9cfdb39--


--===============5611888875044521863==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5611888875044521863==--


From xen-devel-bounces@lists.xen.org Sat Feb 25 20:41:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 20:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1OQG-0004ul-76; Sat, 25 Feb 2012 20:40:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qi.zhezhi@gmail.com>) id 1S1OQE-0004ud-Rz
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 20:40:51 +0000
Received: from [85.158.139.83:56255] by server-12.bemta-5.messagelabs.com id
	95/CB-05100-157494F4; Sat, 25 Feb 2012 20:40:49 +0000
X-Env-Sender: qi.zhezhi@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330202447!16018181!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31329 invoked from network); 25 Feb 2012 20:40:48 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 20:40:48 -0000
Received: by iaeh11 with SMTP id h11so15411378iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 12:40:47 -0800 (PST)
Received-SPF: pass (google.com: domain of qi.zhezhi@gmail.com designates
	10.50.161.170 as permitted sender) client-ip=10.50.161.170; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of qi.zhezhi@gmail.com
	designates 10.50.161.170 as permitted sender)
	smtp.mail=qi.zhezhi@gmail.com;
	dkim=pass header.i=qi.zhezhi@gmail.com
Received: from mr.google.com ([10.50.161.170])
	by 10.50.161.170 with SMTP id xt10mr3897240igb.8.1330202447015
	(num_hops = 1); Sat, 25 Feb 2012 12:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=TH1ohXUlQ2UTHsgx0HylCWSyN0VusUUDmjRfuWGSsGs=;
	b=bX5kW0AVjS4pmd6WQsltpG/t3vn0qNCSvUrqMWguczsrXOYEyzb+f20rXKFthy7ksI
	HQ8DeClo3xFGExdszFZ9TbfddlIC2b+GaVhW/nh/tWuhiwPt7z0xlFO7lYvMGBhSQgbX
	pCqaEEk320e2uYK1BuVn5Tc1mXiVfAU8HQxJQ=
MIME-Version: 1.0
Received: by 10.50.161.170 with SMTP id xt10mr3169844igb.8.1330202446971; Sat,
	25 Feb 2012 12:40:46 -0800 (PST)
Received: by 10.42.168.201 with HTTP; Sat, 25 Feb 2012 12:40:46 -0800 (PST)
Date: Sun, 26 Feb 2012 04:40:46 +0800
Message-ID: <CAPL=jHcuPNTvxKv1Y1p_kY1RYFg6j+QDzBjOJut10watnqd-=w@mail.gmail.com>
From: =?GB2312?B?xuvV3Nau?= <qi.zhezhi@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Problems about xen installation by cobbler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5391492925185444556=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5391492925185444556==
Content-Type: multipart/alternative; boundary=14dae9340f1354c52204b9cfe4c0

--14dae9340f1354c52204b9cfe4c0
Content-Type: text/plain; charset=ISO-8859-1

*I've installed many xen vm with virt-install and ftp.

I'm trying to do the xen installation by cobbler.
Unfortunately,there are some problems.*

[root@xen1 xen]# koan  koan --server=192.168.70.205 --system=xen --virt
--virt-name=D5
- reading URL: http://127.0.0.1/cblr/svc/op/ks/system/xen
libvirtd (pid  4507) is running...
downloading initrd initrd.img to /var/lib/xen/initrd.img
url=http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/initrd.img
- reading URL:
http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/initrd.img
downloading kernel vmlinuz to /var/lib/xen/vmlinuz
url=http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/vmlinuz
- reading URL:
http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/vmlinuz
*libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByUUID
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName*
use virt-manager or reconnect with virsh console D5

xm console D5

md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
XENBUS: Device with no driver: device/vbd/51712
XENBUS: Device with no driver: device/vif/0
Initalizing network drop monitor service
Write protecting the kernel read-only data: 478k

then the installration is* STOP.*

*What's the problem maybe? What can I do?*

Thanks
Best Regards,
Jasonqi

--14dae9340f1354c52204b9cfe4c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b>I&#39;ve installed many xen vm with virt-install and ftp.<br><br>I&#39;m=
 trying to do the xen installation by cobbler.<br>Unfortunately,there are s=
ome problems.</b><br><br>[root@xen1 xen]# koan=A0 koan --server=3D192.168.7=
0.205 --system=3Dxen --virt --virt-name=3DD5<br>

- reading URL: <a href=3D"http://127.0.0.1/cblr/svc/op/ks/system/xen" targe=
t=3D"_blank">http://127.0.0.1/cblr/svc/op/ks/system/xen</a><br>libvirtd (pi=
d=A0 4507) is running...<br>downloading initrd initrd.img to /var/lib/xen/i=
nitrd.img<br>
url=3D<a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/ini=
trd.img" target=3D"_blank">http://192.168.70.205/cobbler/images/rh_5.4-xen-=
x86_64/initrd.img</a><br>
- reading URL: <a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x=
86_64/initrd.img" target=3D"_blank">http://192.168.70.205/cobbler/images/rh=
_5.4-xen-x86_64/initrd.img</a><br>downloading kernel vmlinuz to /var/lib/xe=
n/vmlinuz<br>
url=3D<a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/vml=
inuz" target=3D"_blank">http://192.168.70.205/cobbler/images/rh_5.4-xen-x86=
_64/vmlinuz</a><br>
- reading URL: <a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x=
86_64/vmlinuz" target=3D"_blank">http://192.168.70.205/cobbler/images/rh_5.=
4-xen-x86_64/vmlinuz</a><br><b>libvir: Xen error : Domain not found: xenUni=
fiedDomainLookupByName<br>

libvir: Xen error : Domain not found: xenUnifiedDomainLookupByUUID<br>libvi=
r: Xen error : Domain not found: xenUnifiedDomainLookupByName</b><br>use vi=
rt-manager or reconnect with virsh console D5<br><br>xm console D5<br>
<br>
md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27<br>md: bitmap vers=
ion 4.39<br>TCP bic registered<br>Initializing IPsec netlink socket<br>NET:=
 Registered protocol family 1<br>NET: Registered protocol family 17<br>XENB=
US: Device with no driver: device/vbd/51712<br>

XENBUS: Device with no driver: device/vif/0<br>Initalizing network drop mon=
itor service<br>Write protecting the kernel read-only data: 478k<br><br>the=
n the installration is<b> STOP.</b><br><br><b>What&#39;s the problem maybe?=
 What can I do?</b><br>

<br>Thanks<br>Best Regards,<br>Jasonqi

--14dae9340f1354c52204b9cfe4c0--


--===============5391492925185444556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5391492925185444556==--


From xen-devel-bounces@lists.xen.org Sat Feb 25 20:41:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 20:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1OQG-0004ul-76; Sat, 25 Feb 2012 20:40:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qi.zhezhi@gmail.com>) id 1S1OQE-0004ud-Rz
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 20:40:51 +0000
Received: from [85.158.139.83:56255] by server-12.bemta-5.messagelabs.com id
	95/CB-05100-157494F4; Sat, 25 Feb 2012 20:40:49 +0000
X-Env-Sender: qi.zhezhi@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330202447!16018181!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31329 invoked from network); 25 Feb 2012 20:40:48 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 20:40:48 -0000
Received: by iaeh11 with SMTP id h11so15411378iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 12:40:47 -0800 (PST)
Received-SPF: pass (google.com: domain of qi.zhezhi@gmail.com designates
	10.50.161.170 as permitted sender) client-ip=10.50.161.170; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of qi.zhezhi@gmail.com
	designates 10.50.161.170 as permitted sender)
	smtp.mail=qi.zhezhi@gmail.com;
	dkim=pass header.i=qi.zhezhi@gmail.com
Received: from mr.google.com ([10.50.161.170])
	by 10.50.161.170 with SMTP id xt10mr3897240igb.8.1330202447015
	(num_hops = 1); Sat, 25 Feb 2012 12:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=TH1ohXUlQ2UTHsgx0HylCWSyN0VusUUDmjRfuWGSsGs=;
	b=bX5kW0AVjS4pmd6WQsltpG/t3vn0qNCSvUrqMWguczsrXOYEyzb+f20rXKFthy7ksI
	HQ8DeClo3xFGExdszFZ9TbfddlIC2b+GaVhW/nh/tWuhiwPt7z0xlFO7lYvMGBhSQgbX
	pCqaEEk320e2uYK1BuVn5Tc1mXiVfAU8HQxJQ=
MIME-Version: 1.0
Received: by 10.50.161.170 with SMTP id xt10mr3169844igb.8.1330202446971; Sat,
	25 Feb 2012 12:40:46 -0800 (PST)
Received: by 10.42.168.201 with HTTP; Sat, 25 Feb 2012 12:40:46 -0800 (PST)
Date: Sun, 26 Feb 2012 04:40:46 +0800
Message-ID: <CAPL=jHcuPNTvxKv1Y1p_kY1RYFg6j+QDzBjOJut10watnqd-=w@mail.gmail.com>
From: =?GB2312?B?xuvV3Nau?= <qi.zhezhi@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Problems about xen installation by cobbler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5391492925185444556=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5391492925185444556==
Content-Type: multipart/alternative; boundary=14dae9340f1354c52204b9cfe4c0

--14dae9340f1354c52204b9cfe4c0
Content-Type: text/plain; charset=ISO-8859-1

*I've installed many xen vm with virt-install and ftp.

I'm trying to do the xen installation by cobbler.
Unfortunately,there are some problems.*

[root@xen1 xen]# koan  koan --server=192.168.70.205 --system=xen --virt
--virt-name=D5
- reading URL: http://127.0.0.1/cblr/svc/op/ks/system/xen
libvirtd (pid  4507) is running...
downloading initrd initrd.img to /var/lib/xen/initrd.img
url=http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/initrd.img
- reading URL:
http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/initrd.img
downloading kernel vmlinuz to /var/lib/xen/vmlinuz
url=http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/vmlinuz
- reading URL:
http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/vmlinuz
*libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByUUID
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName*
use virt-manager or reconnect with virsh console D5

xm console D5

md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
XENBUS: Device with no driver: device/vbd/51712
XENBUS: Device with no driver: device/vif/0
Initalizing network drop monitor service
Write protecting the kernel read-only data: 478k

then the installration is* STOP.*

*What's the problem maybe? What can I do?*

Thanks
Best Regards,
Jasonqi

--14dae9340f1354c52204b9cfe4c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<b>I&#39;ve installed many xen vm with virt-install and ftp.<br><br>I&#39;m=
 trying to do the xen installation by cobbler.<br>Unfortunately,there are s=
ome problems.</b><br><br>[root@xen1 xen]# koan=A0 koan --server=3D192.168.7=
0.205 --system=3Dxen --virt --virt-name=3DD5<br>

- reading URL: <a href=3D"http://127.0.0.1/cblr/svc/op/ks/system/xen" targe=
t=3D"_blank">http://127.0.0.1/cblr/svc/op/ks/system/xen</a><br>libvirtd (pi=
d=A0 4507) is running...<br>downloading initrd initrd.img to /var/lib/xen/i=
nitrd.img<br>
url=3D<a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/ini=
trd.img" target=3D"_blank">http://192.168.70.205/cobbler/images/rh_5.4-xen-=
x86_64/initrd.img</a><br>
- reading URL: <a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x=
86_64/initrd.img" target=3D"_blank">http://192.168.70.205/cobbler/images/rh=
_5.4-xen-x86_64/initrd.img</a><br>downloading kernel vmlinuz to /var/lib/xe=
n/vmlinuz<br>
url=3D<a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x86_64/vml=
inuz" target=3D"_blank">http://192.168.70.205/cobbler/images/rh_5.4-xen-x86=
_64/vmlinuz</a><br>
- reading URL: <a href=3D"http://192.168.70.205/cobbler/images/rh_5.4-xen-x=
86_64/vmlinuz" target=3D"_blank">http://192.168.70.205/cobbler/images/rh_5.=
4-xen-x86_64/vmlinuz</a><br><b>libvir: Xen error : Domain not found: xenUni=
fiedDomainLookupByName<br>

libvir: Xen error : Domain not found: xenUnifiedDomainLookupByUUID<br>libvi=
r: Xen error : Domain not found: xenUnifiedDomainLookupByName</b><br>use vi=
rt-manager or reconnect with virsh console D5<br><br>xm console D5<br>
<br>
md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27<br>md: bitmap vers=
ion 4.39<br>TCP bic registered<br>Initializing IPsec netlink socket<br>NET:=
 Registered protocol family 1<br>NET: Registered protocol family 17<br>XENB=
US: Device with no driver: device/vbd/51712<br>

XENBUS: Device with no driver: device/vif/0<br>Initalizing network drop mon=
itor service<br>Write protecting the kernel read-only data: 478k<br><br>the=
n the installration is<b> STOP.</b><br><br><b>What&#39;s the problem maybe?=
 What can I do?</b><br>

<br>Thanks<br>Best Regards,<br>Jasonqi

--14dae9340f1354c52204b9cfe4c0--


--===============5391492925185444556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5391492925185444556==--


From xen-devel-bounces@lists.xen.org Sat Feb 25 21:14:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 21:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1OwL-0005Fh-Tf; Sat, 25 Feb 2012 21:14:01 +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 1S1OwK-0005Fc-2k
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 21:14:00 +0000
Received: from [85.158.139.83:18875] by server-5.bemta-5.messagelabs.com id
	28/E0-13566-71F494F4; Sat, 25 Feb 2012 21:13:59 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330204437!12791947!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19018 invoked from network); 25 Feb 2012 21:13:58 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 21:13:58 -0000
Received: by iaeh11 with SMTP id h11so15477167iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 13:13:57 -0800 (PST)
Received-SPF: pass (google.com: domain of wdauchy@gmail.com designates
	10.50.42.134 as permitted sender) client-ip=10.50.42.134; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of wdauchy@gmail.com
	designates 10.50.42.134 as permitted sender)
	smtp.mail=wdauchy@gmail.com;
	dkim=pass header.i=wdauchy@gmail.com
Received: from mr.google.com ([10.50.42.134])
	by 10.50.42.134 with SMTP id o6mr4055698igl.0.1330204437258 (num_hops =
	1); Sat, 25 Feb 2012 13:13:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=kZ49V7PE1vVaLuA8R5VXuQdVAZuyG2aa+BwYJSuRXpk=;
	b=o0hvTFlOV1CBlz1bzSDcZStnb+KJafsl0YbTNmRz5Z49xCOAB142nlB87B73wYC+fs
	7Nd4v/QyX1Yzkh0r22oJYmZGSBlJGXEeHyHiHrlfOTjRnOhROALdULQaXlTfXt3l58kb
	GxPpR6suYv4n2XoLjrEK+awjxYITTFHwpLkiA=
Received: by 10.50.42.134 with SMTP id o6mr3292998igl.0.1330204437214; Sat, 25
	Feb 2012 13:13:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.112.35 with HTTP; Sat, 25 Feb 2012 13:13:37 -0800 (PST)
In-Reply-To: <4F4891B8.9050008@goirand.fr>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
	<20120219223125.GA820@burratino>
	<20120220181618.GD17566@burratino> <4F4891B8.9050008@goirand.fr>
From: William Dauchy <wdauchy@gmail.com>
Date: Sat, 25 Feb 2012 22:13:37 +0100
Message-ID: <CAJ75kXZeYFthSUtsErZrcbO-cAELv5C+XV2hywY63NN5QR_Peg@mail.gmail.com>
To: Thomas Goirand <thomas@goirand.fr>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Thomas,

On Sat, Feb 25, 2012 at 8:46 AM, Thomas Goirand <thomas@goirand.fr> wrote:
> How can I find who's the author of this driver?

I don't think the problem is related to the driver itself, because it
is working without xen.
I'm also looking for hints to fix the problem.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 25 21:14:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 25 Feb 2012 21:14:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1OwL-0005Fh-Tf; Sat, 25 Feb 2012 21:14:01 +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 1S1OwK-0005Fc-2k
	for xen-devel@lists.xensource.com; Sat, 25 Feb 2012 21:14:00 +0000
Received: from [85.158.139.83:18875] by server-5.bemta-5.messagelabs.com id
	28/E0-13566-71F494F4; Sat, 25 Feb 2012 21:13:59 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330204437!12791947!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19018 invoked from network); 25 Feb 2012 21:13:58 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2012 21:13:58 -0000
Received: by iaeh11 with SMTP id h11so15477167iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 25 Feb 2012 13:13:57 -0800 (PST)
Received-SPF: pass (google.com: domain of wdauchy@gmail.com designates
	10.50.42.134 as permitted sender) client-ip=10.50.42.134; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of wdauchy@gmail.com
	designates 10.50.42.134 as permitted sender)
	smtp.mail=wdauchy@gmail.com;
	dkim=pass header.i=wdauchy@gmail.com
Received: from mr.google.com ([10.50.42.134])
	by 10.50.42.134 with SMTP id o6mr4055698igl.0.1330204437258 (num_hops =
	1); Sat, 25 Feb 2012 13:13:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=kZ49V7PE1vVaLuA8R5VXuQdVAZuyG2aa+BwYJSuRXpk=;
	b=o0hvTFlOV1CBlz1bzSDcZStnb+KJafsl0YbTNmRz5Z49xCOAB142nlB87B73wYC+fs
	7Nd4v/QyX1Yzkh0r22oJYmZGSBlJGXEeHyHiHrlfOTjRnOhROALdULQaXlTfXt3l58kb
	GxPpR6suYv4n2XoLjrEK+awjxYITTFHwpLkiA=
Received: by 10.50.42.134 with SMTP id o6mr3292998igl.0.1330204437214; Sat, 25
	Feb 2012 13:13:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.112.35 with HTTP; Sat, 25 Feb 2012 13:13:37 -0800 (PST)
In-Reply-To: <4F4891B8.9050008@goirand.fr>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
	<20120219223125.GA820@burratino>
	<20120220181618.GD17566@burratino> <4F4891B8.9050008@goirand.fr>
From: William Dauchy <wdauchy@gmail.com>
Date: Sat, 25 Feb 2012 22:13:37 +0100
Message-ID: <CAJ75kXZeYFthSUtsErZrcbO-cAELv5C+XV2hywY63NN5QR_Peg@mail.gmail.com>
To: Thomas Goirand <thomas@goirand.fr>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Thomas,

On Sat, Feb 25, 2012 at 8:46 AM, Thomas Goirand <thomas@goirand.fr> wrote:
> How can I find who's the author of this driver?

I don't think the problem is related to the driver itself, because it
is working without xen.
I'm also looking for hints to fix the problem.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 01:48:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 01: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 1S1TCz-0001tU-MG; Sun, 26 Feb 2012 01:47:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1TCw-0001tP-Tw
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 01:47:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330220840!16902162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5522 invoked from network); 26 Feb 2012 01:47:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 01:47:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,483,1325462400"; d="scan'208";a="10936295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 01:47:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 01:47:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1TCo-000768-Re;
	Sun, 26 Feb 2012 01:47:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1TCm-0000M8-3W;
	Sun, 26 Feb 2012 01:47:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12073-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 01:47:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12073: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12073 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12073/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12062
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 12062 pass in 12073
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12062 pass in 12073

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12062 never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 01:48:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 01: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 1S1TCz-0001tU-MG; Sun, 26 Feb 2012 01:47:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1TCw-0001tP-Tw
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 01:47:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330220840!16902162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5522 invoked from network); 26 Feb 2012 01:47:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 01:47:20 -0000
X-IronPort-AV: E=Sophos;i="4.73,483,1325462400"; d="scan'208";a="10936295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 01:47:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 01:47:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1TCo-000768-Re;
	Sun, 26 Feb 2012 01:47:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1TCm-0000M8-3W;
	Sun, 26 Feb 2012 01:47:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12073-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 01:47:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12073: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12073 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12073/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12062
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 12062 pass in 12073
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12062 pass in 12073

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12062 never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 05:01:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 05:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1WDe-000387-PI; Sun, 26 Feb 2012 05:00:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1WDd-000381-Fs
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 05:00:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330232414!16929480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8855 invoked from network); 26 Feb 2012 05:00:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 05:00:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,483,1325462400"; d="scan'208";a="10936654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 05:00:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 05:00:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1WDV-0008Rs-4E;
	Sun, 26 Feb 2012 05:00:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1WDV-000629-3h;
	Sun, 26 Feb 2012 05:00:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12076-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 05:00:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12076: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12076 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12076/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 05:01:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 05:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1WDe-000387-PI; Sun, 26 Feb 2012 05:00:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1WDd-000381-Fs
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 05:00:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330232414!16929480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8855 invoked from network); 26 Feb 2012 05:00:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 05:00:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,483,1325462400"; d="scan'208";a="10936654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 05:00:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 05:00:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1WDV-0008Rs-4E;
	Sun, 26 Feb 2012 05:00:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1WDV-000629-3h;
	Sun, 26 Feb 2012 05:00:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12076-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 05:00:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12076: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12076 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12076/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 08:27:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 08:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1ZRF-0004pn-Bq; Sun, 26 Feb 2012 08:26: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 1S1ZRE-0004ph-8B
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 08:26:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330244737!54347498!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwMDI0\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29473 invoked from network); 26 Feb 2012 08:25:37 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Feb 2012 08:25:37 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 26 Feb 2012 00:26:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="114967015"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by orsmga002.jf.intel.com with ESMTP; 26 Feb 2012 00:26:28 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 26 Feb 2012 16:25:43 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sun, 26 Feb 2012 16:25:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <jbeulich@suse.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AQHM8jr7m4MGy1d3TzK01xgwJYdnxZZKoT+QgAQ1PPA=
Date: Sun, 26 Feb 2012 08:25:41 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, "lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>    default y
>>  >
>>> config ACPI_PROCESSOR_AGGREGATOR
>>> -    tristate "Processor Aggregator"
>>> +    bool "Processor Aggregator"
>> 
>> There must be ways to address whatever strange problem you see
>> without making this piece of code non-modular.
>> 
> 
> Yes, another approach is x86_init approach, defining acpi_pad_ops at
> x86_init.c and overwritten when xen_start_kernel. This patch is just
> a RFC patch, to evaluate which approch is more reasonable :-) 
> 

Have a more think about it, x86_init approach still need to disable acpi_pad module.
Seems we have to set acpi_pad as bool, as long as it need to hook to native acpi_pad fucs/variables.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 08:27:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 08:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1ZRF-0004pn-Bq; Sun, 26 Feb 2012 08:26: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 1S1ZRE-0004ph-8B
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 08:26:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330244737!54347498!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwMDI0\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29473 invoked from network); 26 Feb 2012 08:25:37 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Feb 2012 08:25:37 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 26 Feb 2012 00:26:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="114967015"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by orsmga002.jf.intel.com with ESMTP; 26 Feb 2012 00:26:28 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 26 Feb 2012 16:25:43 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Sun, 26 Feb 2012 16:25:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <jbeulich@suse.com>, "konrad.wilk@oracle.com"
	<konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AQHM8jr7m4MGy1d3TzK01xgwJYdnxZZKoT+QgAQ1PPA=
Date: Sun, 26 Feb 2012 08:25:41 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>, "Li,
	Shaohua" <shaohua.li@intel.com>, "lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>    default y
>>  >
>>> config ACPI_PROCESSOR_AGGREGATOR
>>> -    tristate "Processor Aggregator"
>>> +    bool "Processor Aggregator"
>> 
>> There must be ways to address whatever strange problem you see
>> without making this piece of code non-modular.
>> 
> 
> Yes, another approach is x86_init approach, defining acpi_pad_ops at
> x86_init.c and overwritten when xen_start_kernel. This patch is just
> a RFC patch, to evaluate which approch is more reasonable :-) 
> 

Have a more think about it, x86_init approach still need to disable acpi_pad module.
Seems we have to set acpi_pad as bool, as long as it need to hook to native acpi_pad fucs/variables.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 10:47:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 10:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1bcW-0005TJ-Sm; Sun, 26 Feb 2012 10:46:24 +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 1S1bcW-0005S9-04
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 10:46:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330253148!58328225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27320 invoked from network); 26 Feb 2012 10:45:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 10:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,485,1325462400"; d="scan'208";a="10939158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 10:46:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 10:46:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1bcD-0002C3-2m;
	Sun, 26 Feb 2012 10:46:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1bcD-0006pw-1O;
	Sun, 26 Feb 2012 10:46:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12079-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 10:46:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12079: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12079 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12079/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12062
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12073
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 12062 pass in 12079
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12062 pass in 12079

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12062 never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 10:47:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 10:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1bcW-0005TJ-Sm; Sun, 26 Feb 2012 10:46:24 +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 1S1bcW-0005S9-04
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 10:46:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330253148!58328225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27320 invoked from network); 26 Feb 2012 10:45:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 10:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,485,1325462400"; d="scan'208";a="10939158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 10:46:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 10:46:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1bcD-0002C3-2m;
	Sun, 26 Feb 2012 10:46:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1bcD-0006pw-1O;
	Sun, 26 Feb 2012 10:46:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12079-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 10:46:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12079: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12079 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12079/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install      fail pass in 12062
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12073
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 12062 pass in 12079
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12062 pass in 12079

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12062 never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 14:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 14: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 1S1eiy-0006RN-8m; Sun, 26 Feb 2012 14:05:16 +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 1S1eiw-0006RI-T3
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 14:05:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330265060!51412821!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27900 invoked from network); 26 Feb 2012 14:04:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Feb 2012 14:04:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330265113; l=3728;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=07wSbcanzhxOaoPJ7eS+FDGuuDE=;
	b=LtZmU/I9zQlxgA8ZqDB2FZUq36rUgNpK9CO0o6+K8QFYwGG6v1rPziUNno6SClfcqJc
	yNHpntR6qbLQACJOYVTecjpKmJe+lfADHQMEVvwy1YSgbLlZDmk8OaJvqdtWhCfwBY9Kl
	9bRQsHcOV0j7bJXGAlZNmHVah+tVD2dgwPQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69v6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-13.vodafone-net.de [80.226.24.13])
	by smtp.strato.de (fruni mo10) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 90149ao1QDftrN
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 15:05:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5AA4818635
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 15:05:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
Message-Id: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 26 Feb 2012 15:05:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: remove obsolete
	XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330265060 -3600
# Node ID 3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
# Parent  6fb2fee7c1833529cee81ca79994b0b132febdea
xenpaging: remove obsolete XENMEM_paging_op_resume

With changeset 24364:0964341efd65 an event channel based notification of
new responses in the ringbuffer is implemented. This makes the memevent
interface obsolete. Currently a call to p2m_mem_paging_resume() is
triggered twice by xenpaging, once per memevent and once per even
channel. In practice this double call does not lead to issues because
p2m_mem_paging_resume() processes only available events.

xenpaging used the event channel notification since the beginning, but
it was a no-op until changeset mentioned above. This change removes the
unneeded XENMEM_paging_op_resume functionality. Pagers are notified via
an event channel of new requests, and now they are required to notify
the hypervisor about their responses also with an event channel.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6fb2fee7c183 -r 3ace34b89ebe tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -93,14 +93,6 @@ int xc_mem_paging_load(xc_interface *xch
     return rc;
 }
 
-int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
-{
-    return xc_mem_event_memop(xch, domain_id,
-                                XENMEM_paging_op_resume,
-                                XENMEM_paging_op,
-                                gfn, NULL);
-}
-
 
 /*
  * Local variables:
diff -r 6fb2fee7c183 -r 3ace34b89ebe tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1902,8 +1902,6 @@ int xc_mem_paging_evict(xc_interface *xc
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                         unsigned long gfn, void *buffer);
-int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
-                         unsigned long gfn);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 6fb2fee7c183 -r 3ace34b89ebe tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -658,8 +658,6 @@ static int xenpaging_evict_page(struct x
 
 static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t *rsp, int notify_policy)
 {
-    int ret;
-
     /* Put the page info on the ring */
     put_response(&paging->mem_event, rsp);
 
@@ -680,14 +678,7 @@ static int xenpaging_resume_page(struct 
     }
 
     /* Tell Xen page is ready */
-    ret = xc_mem_paging_resume(paging->xc_handle, paging->mem_event.domain_id,
-                               rsp->gfn);
-    if ( ret == 0 ) 
-        ret = xc_evtchn_notify(paging->mem_event.xce_handle,
-                               paging->mem_event.port);
-
- out:
-    return ret;
+    return xc_evtchn_notify(paging->mem_event.xce_handle, paging->mem_event.port);
 }
 
 static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -53,13 +53,6 @@ int mem_paging_memop(struct domain *d, x
     }
     break;
 
-    case XENMEM_paging_op_resume:
-    {
-        p2m_mem_paging_resume(d);
-        return 0;
-    }
-    break;
-
     default:
         return -ENOSYS;
         break;
diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_paging_op_nominate           0
 #define XENMEM_paging_op_evict              1
 #define XENMEM_paging_op_prep               2
-#define XENMEM_paging_op_resume             3
 
 #define XENMEM_access_op                    21
 #define XENMEM_access_op_resume             0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 14:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 14: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 1S1eiy-0006RN-8m; Sun, 26 Feb 2012 14:05:16 +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 1S1eiw-0006RI-T3
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 14:05:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330265060!51412821!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27900 invoked from network); 26 Feb 2012 14:04:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Feb 2012 14:04:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330265113; l=3728;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=07wSbcanzhxOaoPJ7eS+FDGuuDE=;
	b=LtZmU/I9zQlxgA8ZqDB2FZUq36rUgNpK9CO0o6+K8QFYwGG6v1rPziUNno6SClfcqJc
	yNHpntR6qbLQACJOYVTecjpKmJe+lfADHQMEVvwy1YSgbLlZDmk8OaJvqdtWhCfwBY9Kl
	9bRQsHcOV0j7bJXGAlZNmHVah+tVD2dgwPQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69v6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-13.vodafone-net.de [80.226.24.13])
	by smtp.strato.de (fruni mo10) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 90149ao1QDftrN
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 15:05:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5AA4818635
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 15:05:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
Message-Id: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 26 Feb 2012 15:05:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: remove obsolete
	XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330265060 -3600
# Node ID 3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
# Parent  6fb2fee7c1833529cee81ca79994b0b132febdea
xenpaging: remove obsolete XENMEM_paging_op_resume

With changeset 24364:0964341efd65 an event channel based notification of
new responses in the ringbuffer is implemented. This makes the memevent
interface obsolete. Currently a call to p2m_mem_paging_resume() is
triggered twice by xenpaging, once per memevent and once per even
channel. In practice this double call does not lead to issues because
p2m_mem_paging_resume() processes only available events.

xenpaging used the event channel notification since the beginning, but
it was a no-op until changeset mentioned above. This change removes the
unneeded XENMEM_paging_op_resume functionality. Pagers are notified via
an event channel of new requests, and now they are required to notify
the hypervisor about their responses also with an event channel.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6fb2fee7c183 -r 3ace34b89ebe tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -93,14 +93,6 @@ int xc_mem_paging_load(xc_interface *xch
     return rc;
 }
 
-int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
-{
-    return xc_mem_event_memop(xch, domain_id,
-                                XENMEM_paging_op_resume,
-                                XENMEM_paging_op,
-                                gfn, NULL);
-}
-
 
 /*
  * Local variables:
diff -r 6fb2fee7c183 -r 3ace34b89ebe tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1902,8 +1902,6 @@ int xc_mem_paging_evict(xc_interface *xc
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                         unsigned long gfn, void *buffer);
-int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
-                         unsigned long gfn);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 6fb2fee7c183 -r 3ace34b89ebe tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -658,8 +658,6 @@ static int xenpaging_evict_page(struct x
 
 static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t *rsp, int notify_policy)
 {
-    int ret;
-
     /* Put the page info on the ring */
     put_response(&paging->mem_event, rsp);
 
@@ -680,14 +678,7 @@ static int xenpaging_resume_page(struct 
     }
 
     /* Tell Xen page is ready */
-    ret = xc_mem_paging_resume(paging->xc_handle, paging->mem_event.domain_id,
-                               rsp->gfn);
-    if ( ret == 0 ) 
-        ret = xc_evtchn_notify(paging->mem_event.xce_handle,
-                               paging->mem_event.port);
-
- out:
-    return ret;
+    return xc_evtchn_notify(paging->mem_event.xce_handle, paging->mem_event.port);
 }
 
 static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -53,13 +53,6 @@ int mem_paging_memop(struct domain *d, x
     }
     break;
 
-    case XENMEM_paging_op_resume:
-    {
-        p2m_mem_paging_resume(d);
-        return 0;
-    }
-    break;
-
     default:
         return -ENOSYS;
         break;
diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_paging_op_nominate           0
 #define XENMEM_paging_op_evict              1
 #define XENMEM_paging_op_prep               2
-#define XENMEM_paging_op_resume             3
 
 #define XENMEM_access_op                    21
 #define XENMEM_access_op_resume             0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 15:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 15:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1fkK-00077T-TB; Sun, 26 Feb 2012 15:10:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1fkI-00077O-Vs
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 15:10:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330269035!11073433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9445 invoked from network); 26 Feb 2012 15:10: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;
	26 Feb 2012 15:10:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,485,1325462400"; d="scan'208";a="10940895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 15:10:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 15:10:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1fk9-0003uc-SF;
	Sun, 26 Feb 2012 15:10:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1fk9-0005o7-Q2;
	Sun, 26 Feb 2012 15:10:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12082-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 15:10:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12082: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12082 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12082/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl             9 guest-start                 fail pass in 12076
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2               fail pass in 12076

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12076 like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12076 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 15:11:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 15:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1fkK-00077T-TB; Sun, 26 Feb 2012 15:10:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1fkI-00077O-Vs
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 15:10:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330269035!11073433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9445 invoked from network); 26 Feb 2012 15:10: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;
	26 Feb 2012 15:10:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,485,1325462400"; d="scan'208";a="10940895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 15:10:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 15:10:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1fk9-0003uc-SF;
	Sun, 26 Feb 2012 15:10:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1fk9-0005o7-Q2;
	Sun, 26 Feb 2012 15:10:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12082-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 15:10:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12082: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12082 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12082/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl             9 guest-start                 fail pass in 12076
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2               fail pass in 12076

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12076 like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12076 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 16:06:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 16:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1gc3-00086B-SU; Sun, 26 Feb 2012 16:06:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S1gc2-00085z-Uc
	for xen-devel@lists.xen.org; Sun, 26 Feb 2012 16:06:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330272367!14953585!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2ODYzMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7158 invoked from network); 26 Feb 2012 16:06:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2012 16:06:08 -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 q1QG639P002101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 26 Feb 2012 16:06:03 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
	q1QG60uO000542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 26 Feb 2012 16:06:02 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
	q1QG5vQL027748; Sun, 26 Feb 2012 10:05:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 08:05:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9901C4035E; Sun, 26 Feb 2012 11:02:30 -0500 (EST)
Date: Sun, 26 Feb 2012 11:02:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120226160230.GA2274@phenom.dumpdata.com>
References: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F4A586D.0052,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: constify all instances of "struct
	attribute_group"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 11:47:57AM +0000, Jan Beulich wrote:
> The functions these get passed to have been taking pointers to const
> since at least 2.6.16.

What is this based on? I get:

HEAD is now at b01543d... Linux 3.3-rc4
konrad@phenom:~/ssd/linux$ patch -p1 < /tmp/jan-1
patching file drivers/xen/sys-hypervisor.c
Hunk #1 FAILED at 97.
Hunk #2 FAILED at 210.
Hunk #3 FAILED at 340.
3 out of 3 hunks FAILED -- saving rejects to file drivers/xen/sys-hypervisor.c.rej
patching file drivers/xen/xen-balloon.c
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED -- saving rejects to file drivers/xen/xen-balloon.c.rej
patching file drivers/xen/xen-selfballoon.c
Hunk #1 FAILED at 488.
1 out of 1 hunk FAILED -- saving rejects to file drivers/xen/xen-selfballoon.c.rej


> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  drivers/xen/sys-hypervisor.c  |    6 +++---
>  drivers/xen/xen-balloon.c     |    2 +-
>  drivers/xen/xen-selfballoon.c |    2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> --- 3.3-rc4/drivers/xen/sys-hypervisor.c
> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c
> @@ -97,7 +97,7 @@ static struct attribute *version_attrs[]
>  	NULL
>  };
>  
> -static struct attribute_group version_group = {
> +static const struct attribute_group version_group = {
>  	.name = "version",
>  	.attrs = version_attrs,
>  };
> @@ -210,7 +210,7 @@ static struct attribute *xen_compile_att
>  	NULL
>  };
>  
> -static struct attribute_group xen_compilation_group = {
> +static const struct attribute_group xen_compilation_group = {
>  	.name = "compilation",
>  	.attrs = xen_compile_attrs,
>  };
> @@ -340,7 +340,7 @@ static struct attribute *xen_properties_
>  	NULL
>  };
>  
> -static struct attribute_group xen_properties_group = {
> +static const struct attribute_group xen_properties_group = {
>  	.name = "properties",
>  	.attrs = xen_properties_attrs,
>  };
> --- 3.3-rc4/drivers/xen/xen-balloon.c
> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon.c
> @@ -207,7 +207,7 @@ static struct attribute *balloon_info_at
>  	NULL
>  };
>  
> -static struct attribute_group balloon_info_group = {
> +static const struct attribute_group balloon_info_group = {
>  	.name = "info",
>  	.attrs = balloon_info_attrs
>  };
> --- 3.3-rc4/drivers/xen/xen-selfballoon.c
> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-selfballoon.c
> @@ -488,7 +488,7 @@ static struct attribute *selfballoon_att
>  	NULL
>  };
>  
> -static struct attribute_group selfballoon_group = {
> +static const struct attribute_group selfballoon_group = {
>  	.name = "selfballoon",
>  	.attrs = selfballoon_attrs
>  };
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 16:06:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 16:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1gc3-00086B-SU; Sun, 26 Feb 2012 16:06:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S1gc2-00085z-Uc
	for xen-devel@lists.xen.org; Sun, 26 Feb 2012 16:06:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330272367!14953585!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2ODYzMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7158 invoked from network); 26 Feb 2012 16:06:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2012 16:06:08 -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 q1QG639P002101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 26 Feb 2012 16:06:03 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
	q1QG60uO000542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 26 Feb 2012 16:06:02 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
	q1QG5vQL027748; Sun, 26 Feb 2012 10:05:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 08:05:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9901C4035E; Sun, 26 Feb 2012 11:02:30 -0500 (EST)
Date: Sun, 26 Feb 2012 11:02:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120226160230.GA2274@phenom.dumpdata.com>
References: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F4A586D.0052,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: constify all instances of "struct
	attribute_group"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Feb 24, 2012 at 11:47:57AM +0000, Jan Beulich wrote:
> The functions these get passed to have been taking pointers to const
> since at least 2.6.16.

What is this based on? I get:

HEAD is now at b01543d... Linux 3.3-rc4
konrad@phenom:~/ssd/linux$ patch -p1 < /tmp/jan-1
patching file drivers/xen/sys-hypervisor.c
Hunk #1 FAILED at 97.
Hunk #2 FAILED at 210.
Hunk #3 FAILED at 340.
3 out of 3 hunks FAILED -- saving rejects to file drivers/xen/sys-hypervisor.c.rej
patching file drivers/xen/xen-balloon.c
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED -- saving rejects to file drivers/xen/xen-balloon.c.rej
patching file drivers/xen/xen-selfballoon.c
Hunk #1 FAILED at 488.
1 out of 1 hunk FAILED -- saving rejects to file drivers/xen/xen-selfballoon.c.rej


> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  drivers/xen/sys-hypervisor.c  |    6 +++---
>  drivers/xen/xen-balloon.c     |    2 +-
>  drivers/xen/xen-selfballoon.c |    2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> --- 3.3-rc4/drivers/xen/sys-hypervisor.c
> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c
> @@ -97,7 +97,7 @@ static struct attribute *version_attrs[]
>  	NULL
>  };
>  
> -static struct attribute_group version_group = {
> +static const struct attribute_group version_group = {
>  	.name = "version",
>  	.attrs = version_attrs,
>  };
> @@ -210,7 +210,7 @@ static struct attribute *xen_compile_att
>  	NULL
>  };
>  
> -static struct attribute_group xen_compilation_group = {
> +static const struct attribute_group xen_compilation_group = {
>  	.name = "compilation",
>  	.attrs = xen_compile_attrs,
>  };
> @@ -340,7 +340,7 @@ static struct attribute *xen_properties_
>  	NULL
>  };
>  
> -static struct attribute_group xen_properties_group = {
> +static const struct attribute_group xen_properties_group = {
>  	.name = "properties",
>  	.attrs = xen_properties_attrs,
>  };
> --- 3.3-rc4/drivers/xen/xen-balloon.c
> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon.c
> @@ -207,7 +207,7 @@ static struct attribute *balloon_info_at
>  	NULL
>  };
>  
> -static struct attribute_group balloon_info_group = {
> +static const struct attribute_group balloon_info_group = {
>  	.name = "info",
>  	.attrs = balloon_info_attrs
>  };
> --- 3.3-rc4/drivers/xen/xen-selfballoon.c
> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-selfballoon.c
> @@ -488,7 +488,7 @@ static struct attribute *selfballoon_att
>  	NULL
>  };
>  
> -static struct attribute_group selfballoon_group = {
> +static const struct attribute_group selfballoon_group = {
>  	.name = "selfballoon",
>  	.attrs = selfballoon_attrs
>  };
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 16:16:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 16: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 1S1glA-0008J0-SU; Sun, 26 Feb 2012 16:15:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S1gl8-0008Io-Gh
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 16:15:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330272930!2324458!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24838 invoked from network); 26 Feb 2012 16:15:31 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Feb 2012 16:15:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330272930; l=7995;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BX48OOINbl9GXrDt0UpW/LrVv3g=;
	b=qT42GmGoQCBmTjSD11o8aifVUtm7AeglKf7mlBfiRlSMYbl7WyghgmWNzxOdykBdhDn
	E5umTkZu/WEqloU4ayZbKPRum61zOvcswi0bID098HdngUzLguy2/U/zVItN+ZiAAB/MD
	riEr1oXIhaWdCvezN0aO9rh6wMLfR6T7HIc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69v6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-13.vodafone-net.de [80.226.24.13])
	by post.strato.de (mrclete mo21) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 60530ao1QG3eiT
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 17:15:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0974718635
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 17:15:14 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e17afed13a35989bdf422b75d44843bfd2fda0f4
Message-Id: <e17afed13a35989bdf42.1330272912@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 26 Feb 2012 17:15:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] [RFC]: xenpaging: add command to to flush qemu
 buffer cache via VMCALL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330272880 -3600
# Node ID e17afed13a35989bdf422b75d44843bfd2fda0f4
# Parent  3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
[RFC]: xenpaging: add command to to flush qemu buffer cache via VMCALL

Is the approach taken in this patch ok?
With the debug output in my patch I get output like pasted below. It
means that xenpaging set qemu_mapcache_invalidate very often before a
VMCALL occoured.

What triggers a VMCALL anyway? It looks like its not something one can
depend on. From xenpagings PoV its not required that the command reaches
qemu right away, but it should be processed "soon".
Could send_invalidate_req() be called from another exit reason (or from
another place perhaps)?

Olaf


....
(XEN) irq.c:350: Dom1 callback via changed to PCI INTx Dev 0x03 IntA
(XEN) hvm_do_hypercall: 0 1 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 0 1 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 3049 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 4562 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 6 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 6 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 14 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 598 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 1 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 3 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 161 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 1 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 4860 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 1 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 799 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 5 0 0
(XEN) io.c:155:d1 send_invalidate_req
....



....
qemu will just keep mapping pages and not release them, which causes
problems for the memory pager (since the page is mapped, it won't get
paged out).  When the pager has trouble finding a page to page out, it
asks qemu to flush its buffer, which releases all the page mappings.
This makes it possible to find  pages to swap out agian.

This change removes the code which writes "flush-cache" to xenstore
because the corresponding change for qemu-xen-traditional was never
applied, and it also will not work with qemu-xen-upstream.

Instead of sending commands via xenstore, use the existing
IOREQ_TYPE_INVALIDATE command for HVM guests. A simple memory_op just
sets qemu_mapcache_invalidate flag which in turn causes the hypervisor
to send the actual IOREQ_TYPE_INVALIDATE during next VMEXIT_VMCALL.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -93,6 +93,14 @@ int xc_mem_paging_load(xc_interface *xch
     return rc;
 }
 
+int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id)
+{
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_ioemu_flush,
+                                XENMEM_paging_op,
+                                0, NULL);
+}
+
 
 /*
  * Local variables:
diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1902,6 +1902,7 @@ int xc_mem_paging_evict(xc_interface *xc
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                         unsigned long gfn, void *buffer);
+int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 3ace34b89ebe -r e17afed13a35 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -62,15 +62,11 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
+static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
-    struct xs_handle *xsh = paging->xs_handle;
+    xc_interface *xch = paging->xc_handle;
     domid_t domain_id = paging->mem_event.domain_id;
-    char path[80];
-
-    sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
-
-    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
+    return xc_mem_paging_flush(xch, domain_id);
 }
 
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
@@ -768,7 +764,12 @@ static int evict_victim(struct xenpaging
             if ( num_paged_out != paging->num_paged_out )
             {
                 DPRINTF("Flushing qemu cache\n");
-                xenpaging_mem_paging_flush_ioemu_cache(paging);
+                ret = xenpaging_mem_paging_flush_ioemu_cache(paging);
+                if ( ret < 0 )
+                {
+                    PERROR("Flushing qemu cache\n");
+                    goto out;
+                }
                 num_paged_out = paging->num_paged_out;
             }
             ret = ENOSPC;
diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2997,6 +2997,7 @@ static long hvm_memory_op(int cmd, XEN_G
         return -ENOSYS;
     case XENMEM_decrease_reservation:
         rc = do_memory_op(cmd, arg);
+        current->domain->arch.hvm_domain.inv_hvm++;
         current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
         return rc;
     }
@@ -3088,6 +3089,7 @@ static long hvm_memory_op_compat32(int c
         return -ENOSYS;
     case XENMEM_decrease_reservation:
         rc = compat_memory_op(cmd, arg);
+        current->domain->arch.hvm_domain.inv_hvm32++;
         current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
         return rc;
     }
@@ -3246,7 +3248,17 @@ int hvm_do_hypercall(struct cpu_user_reg
     if ( unlikely(curr->domain->arch.hvm_domain.qemu_mapcache_invalidate) &&
          test_and_clear_bool(curr->domain->arch.hvm_domain.
                              qemu_mapcache_invalidate) )
+    {
+        printk("%s: %u %u %u\n",
+            __func__,
+            curr->domain->arch.hvm_domain.inv_paging,
+            curr->domain->arch.hvm_domain.inv_hvm,
+            curr->domain->arch.hvm_domain.inv_hvm32);
+        curr->domain->arch.hvm_domain.inv_paging = 
+        curr->domain->arch.hvm_domain.inv_hvm = 
+        curr->domain->arch.hvm_domain.inv_hvm32 = 0;
         return HVM_HCALL_invalidate;
+    }
 
     return HVM_HCALL_completed;
 }
diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/io.c
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -152,6 +152,7 @@ void send_invalidate_req(void)
     struct vcpu *v = current;
     ioreq_t *p = get_ioreq(v);
 
+    gdprintk(XENLOG_DEBUG,"%s\n", __func__);
     if ( p->state != STATE_IOREQ_NONE )
     {
         gdprintk(XENLOG_ERR, "WARNING: send invalidate req with something "
diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -53,6 +53,15 @@ int mem_paging_memop(struct domain *d, x
     }
     break;
 
+    case XENMEM_paging_op_ioemu_flush:
+    {
+        /* Flush qemu cache on next VMEXIT_VMCALL */
+        d->arch.hvm_domain.inv_paging++;
+        d->arch.hvm_domain.qemu_mapcache_invalidate = 1;
+        return 0;
+    }
+    break;
+
     default:
         return -ENOSYS;
         break;
diff -r 3ace34b89ebe -r e17afed13a35 xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -95,6 +95,9 @@ struct hvm_domain {
     bool_t                 mem_sharing_enabled;
     bool_t                 qemu_mapcache_invalidate;
     bool_t                 is_s3_suspended;
+    unsigned int inv_paging;
+    unsigned int inv_hvm;
+    unsigned int inv_hvm32;
 
     union {
         struct vmx_domain vmx;
diff -r 3ace34b89ebe -r e17afed13a35 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -322,6 +322,7 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_paging_op_nominate           0
 #define XENMEM_paging_op_evict              1
 #define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_ioemu_flush        3
 
 #define XENMEM_access_op                    21
 #define XENMEM_access_op_resume             0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 16:16:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 16: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 1S1glA-0008J0-SU; Sun, 26 Feb 2012 16:15:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S1gl8-0008Io-Gh
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 16:15:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330272930!2324458!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM3MTA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24838 invoked from network); 26 Feb 2012 16:15:31 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Feb 2012 16:15:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330272930; l=7995;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BX48OOINbl9GXrDt0UpW/LrVv3g=;
	b=qT42GmGoQCBmTjSD11o8aifVUtm7AeglKf7mlBfiRlSMYbl7WyghgmWNzxOdykBdhDn
	E5umTkZu/WEqloU4ayZbKPRum61zOvcswi0bID098HdngUzLguy2/U/zVItN+ZiAAB/MD
	riEr1oXIhaWdCvezN0aO9rh6wMLfR6T7HIc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV69v6
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-13.vodafone-net.de [80.226.24.13])
	by post.strato.de (mrclete mo21) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 60530ao1QG3eiT
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 17:15:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0974718635
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 17:15:14 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e17afed13a35989bdf422b75d44843bfd2fda0f4
Message-Id: <e17afed13a35989bdf42.1330272912@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 26 Feb 2012 17:15:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] [RFC]: xenpaging: add command to to flush qemu
 buffer cache via VMCALL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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 1330272880 -3600
# Node ID e17afed13a35989bdf422b75d44843bfd2fda0f4
# Parent  3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
[RFC]: xenpaging: add command to to flush qemu buffer cache via VMCALL

Is the approach taken in this patch ok?
With the debug output in my patch I get output like pasted below. It
means that xenpaging set qemu_mapcache_invalidate very often before a
VMCALL occoured.

What triggers a VMCALL anyway? It looks like its not something one can
depend on. From xenpagings PoV its not required that the command reaches
qemu right away, but it should be processed "soon".
Could send_invalidate_req() be called from another exit reason (or from
another place perhaps)?

Olaf


....
(XEN) irq.c:350: Dom1 callback via changed to PCI INTx Dev 0x03 IntA
(XEN) hvm_do_hypercall: 0 1 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 0 1 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 3049 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 4562 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 6 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 6 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 14 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 598 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 1 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 3 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 161 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 1 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 4860 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 1 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 799 0 0
(XEN) io.c:155:d1 send_invalidate_req
(XEN) hvm_do_hypercall: 5 0 0
(XEN) io.c:155:d1 send_invalidate_req
....



....
qemu will just keep mapping pages and not release them, which causes
problems for the memory pager (since the page is mapped, it won't get
paged out).  When the pager has trouble finding a page to page out, it
asks qemu to flush its buffer, which releases all the page mappings.
This makes it possible to find  pages to swap out agian.

This change removes the code which writes "flush-cache" to xenstore
because the corresponding change for qemu-xen-traditional was never
applied, and it also will not work with qemu-xen-upstream.

Instead of sending commands via xenstore, use the existing
IOREQ_TYPE_INVALIDATE command for HVM guests. A simple memory_op just
sets qemu_mapcache_invalidate flag which in turn causes the hypervisor
to send the actual IOREQ_TYPE_INVALIDATE during next VMEXIT_VMCALL.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -93,6 +93,14 @@ int xc_mem_paging_load(xc_interface *xch
     return rc;
 }
 
+int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id)
+{
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_ioemu_flush,
+                                XENMEM_paging_op,
+                                0, NULL);
+}
+
 
 /*
  * Local variables:
diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1902,6 +1902,7 @@ int xc_mem_paging_evict(xc_interface *xc
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                         unsigned long gfn, void *buffer);
+int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id);
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 3ace34b89ebe -r e17afed13a35 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -62,15 +62,11 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
+static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
-    struct xs_handle *xsh = paging->xs_handle;
+    xc_interface *xch = paging->xc_handle;
     domid_t domain_id = paging->mem_event.domain_id;
-    char path[80];
-
-    sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
-
-    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
+    return xc_mem_paging_flush(xch, domain_id);
 }
 
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
@@ -768,7 +764,12 @@ static int evict_victim(struct xenpaging
             if ( num_paged_out != paging->num_paged_out )
             {
                 DPRINTF("Flushing qemu cache\n");
-                xenpaging_mem_paging_flush_ioemu_cache(paging);
+                ret = xenpaging_mem_paging_flush_ioemu_cache(paging);
+                if ( ret < 0 )
+                {
+                    PERROR("Flushing qemu cache\n");
+                    goto out;
+                }
                 num_paged_out = paging->num_paged_out;
             }
             ret = ENOSPC;
diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2997,6 +2997,7 @@ static long hvm_memory_op(int cmd, XEN_G
         return -ENOSYS;
     case XENMEM_decrease_reservation:
         rc = do_memory_op(cmd, arg);
+        current->domain->arch.hvm_domain.inv_hvm++;
         current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
         return rc;
     }
@@ -3088,6 +3089,7 @@ static long hvm_memory_op_compat32(int c
         return -ENOSYS;
     case XENMEM_decrease_reservation:
         rc = compat_memory_op(cmd, arg);
+        current->domain->arch.hvm_domain.inv_hvm32++;
         current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
         return rc;
     }
@@ -3246,7 +3248,17 @@ int hvm_do_hypercall(struct cpu_user_reg
     if ( unlikely(curr->domain->arch.hvm_domain.qemu_mapcache_invalidate) &&
          test_and_clear_bool(curr->domain->arch.hvm_domain.
                              qemu_mapcache_invalidate) )
+    {
+        printk("%s: %u %u %u\n",
+            __func__,
+            curr->domain->arch.hvm_domain.inv_paging,
+            curr->domain->arch.hvm_domain.inv_hvm,
+            curr->domain->arch.hvm_domain.inv_hvm32);
+        curr->domain->arch.hvm_domain.inv_paging = 
+        curr->domain->arch.hvm_domain.inv_hvm = 
+        curr->domain->arch.hvm_domain.inv_hvm32 = 0;
         return HVM_HCALL_invalidate;
+    }
 
     return HVM_HCALL_completed;
 }
diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/io.c
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -152,6 +152,7 @@ void send_invalidate_req(void)
     struct vcpu *v = current;
     ioreq_t *p = get_ioreq(v);
 
+    gdprintk(XENLOG_DEBUG,"%s\n", __func__);
     if ( p->state != STATE_IOREQ_NONE )
     {
         gdprintk(XENLOG_ERR, "WARNING: send invalidate req with something "
diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -53,6 +53,15 @@ int mem_paging_memop(struct domain *d, x
     }
     break;
 
+    case XENMEM_paging_op_ioemu_flush:
+    {
+        /* Flush qemu cache on next VMEXIT_VMCALL */
+        d->arch.hvm_domain.inv_paging++;
+        d->arch.hvm_domain.qemu_mapcache_invalidate = 1;
+        return 0;
+    }
+    break;
+
     default:
         return -ENOSYS;
         break;
diff -r 3ace34b89ebe -r e17afed13a35 xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -95,6 +95,9 @@ struct hvm_domain {
     bool_t                 mem_sharing_enabled;
     bool_t                 qemu_mapcache_invalidate;
     bool_t                 is_s3_suspended;
+    unsigned int inv_paging;
+    unsigned int inv_hvm;
+    unsigned int inv_hvm32;
 
     union {
         struct vmx_domain vmx;
diff -r 3ace34b89ebe -r e17afed13a35 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -322,6 +322,7 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_paging_op_nominate           0
 #define XENMEM_paging_op_evict              1
 #define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_ioemu_flush        3
 
 #define XENMEM_access_op                    21
 #define XENMEM_access_op_resume             0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 17:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 17:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1i3X-0000H2-98; Sun, 26 Feb 2012 17:38:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S1i3V-0000Gx-CW
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 17:38:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330277913!8438282!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2ODYzMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18414 invoked from network); 26 Feb 2012 17:38:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2012 17:38:34 -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 q1QHcRSG006313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 26 Feb 2012 17:38:28 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
	q1QHcQWv028559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 26 Feb 2012 17:38:26 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
	q1QHcP6D026355; Sun, 26 Feb 2012 11:38:25 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 09:38:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C35C4035E; Sun, 26 Feb 2012 12:34:58 -0500 (EST)
Date: Sun, 26 Feb 2012 12:34:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120226173458.GB18098@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F4A6E14.00B1,ss=1,re=0.000,fgs=0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
> Liu, Jinsong wrote:
> > Jan Beulich wrote:
> >>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
> >>> --- a/drivers/acpi/Kconfig
> >>> +++ b/drivers/acpi/Kconfig
> >>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
> >>>    default y
> >>  >
> >>> config ACPI_PROCESSOR_AGGREGATOR
> >>> -    tristate "Processor Aggregator"
> >>> +    bool "Processor Aggregator"
> >> 
> >> There must be ways to address whatever strange problem you see
> >> without making this piece of code non-modular.
> >> 
> > 
> > Yes, another approach is x86_init approach, defining acpi_pad_ops at
> > x86_init.c and overwritten when xen_start_kernel. This patch is just
> > a RFC patch, to evaluate which approch is more reasonable :-) 
> > 
> 
> Have a more think about it, x86_init approach still need to disable acpi_pad module.
> Seems we have to set acpi_pad as bool, as long as it need to hook to native acpi_pad fucs/variables.

What about the other approach I suggested where there are some function
overrides in osl.c? Something similar to https://lkml.org/lkml/2012/1/17/401,
specifically https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
the modules into being built in, but intead have the function table already in
the kernel (as some form of EXPORT_SYMBOL_GPL or a registration function).

Instead of just one function being over-ridden it could have some more. However
I am not sure if the osl.c is the place for this either. Perhaps Len might
have some better ideas?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 17:39:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 17:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1i3X-0000H2-98; Sun, 26 Feb 2012 17:38:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S1i3V-0000Gx-CW
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 17:38:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330277913!8438282!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2ODYzMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18414 invoked from network); 26 Feb 2012 17:38:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2012 17:38:34 -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 q1QHcRSG006313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 26 Feb 2012 17:38:28 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
	q1QHcQWv028559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 26 Feb 2012 17:38:26 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
	q1QHcP6D026355; Sun, 26 Feb 2012 11:38:25 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 09:38:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C35C4035E; Sun, 26 Feb 2012 12:34:58 -0500 (EST)
Date: Sun, 26 Feb 2012 12:34:58 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20120226173458.GB18098@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F4A6E14.00B1,ss=1,re=0.000,fgs=0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
> Liu, Jinsong wrote:
> > Jan Beulich wrote:
> >>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
> >>> --- a/drivers/acpi/Kconfig
> >>> +++ b/drivers/acpi/Kconfig
> >>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
> >>>    default y
> >>  >
> >>> config ACPI_PROCESSOR_AGGREGATOR
> >>> -    tristate "Processor Aggregator"
> >>> +    bool "Processor Aggregator"
> >> 
> >> There must be ways to address whatever strange problem you see
> >> without making this piece of code non-modular.
> >> 
> > 
> > Yes, another approach is x86_init approach, defining acpi_pad_ops at
> > x86_init.c and overwritten when xen_start_kernel. This patch is just
> > a RFC patch, to evaluate which approch is more reasonable :-) 
> > 
> 
> Have a more think about it, x86_init approach still need to disable acpi_pad module.
> Seems we have to set acpi_pad as bool, as long as it need to hook to native acpi_pad fucs/variables.

What about the other approach I suggested where there are some function
overrides in osl.c? Something similar to https://lkml.org/lkml/2012/1/17/401,
specifically https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
the modules into being built in, but intead have the function table already in
the kernel (as some form of EXPORT_SYMBOL_GPL or a registration function).

Instead of just one function being over-ridden it could have some more. However
I am not sure if the osl.c is the place for this either. Perhaps Len might
have some better ideas?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 17:55:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 17:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1iIy-0000SP-TR; Sun, 26 Feb 2012 17:54: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 1S1iIx-0000SK-P2
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 17:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330278824!54379549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7336 invoked from network); 26 Feb 2012 17:53:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 17:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,486,1325462400"; d="scan'208";a="10941560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 17:54:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 17:54:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1iIv-0004vg-Px;
	Sun, 26 Feb 2012 17:54:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1iIv-0000j4-H9;
	Sun, 26 Feb 2012 17:54:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S1iIv-0000j4-H9@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 17:54:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-winxpsp3-vcpus1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-winxpsp3-vcpus1
test windows-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-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-winxpsp3-vcpus1.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12079 fail [host=field-cricket] / 12031 ok.
Failure / basis pass flights: 12079 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-71159fb049f2
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 62 nodes in revision graph
Searching for test results:
 12030 pass irrelevant
 12026 pass irrelevant
 12029 blocked irrelevant
 12027 pass irrelevant
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12028 blocked irrelevant
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12077 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12073 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12078 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12080 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12081 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12083 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12053 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12079 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12084 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12086 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12087 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12062 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12074 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12075 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12053 (fail), for basis failure
 Repro found: flight 12074 (pass), for basis pass
 Repro found: flight 12075 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12080 (pass), for last pass
 Result found: flight 12081 (fail), for first failure
 Repro found: flight 12083 (pass), for last pass
 Repro found: flight 12084 (fail), for first failure
 Repro found: flight 12086 (pass), for last pass
 Repro found: flight 12087 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-winxpsp3-vcpus1.windows-install.{dot,ps,png,html}.
----------------------------------------
12087: ALL FAIL

flight 12087 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12087/


jobs:
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 17:55:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 17:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1iIy-0000SP-TR; Sun, 26 Feb 2012 17:54: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 1S1iIx-0000SK-P2
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 17:54:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330278824!54379549!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7336 invoked from network); 26 Feb 2012 17:53:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2012 17:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,486,1325462400"; d="scan'208";a="10941560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 17:54:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 17:54:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1iIv-0004vg-Px;
	Sun, 26 Feb 2012 17:54:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1iIv-0000j4-H9;
	Sun, 26 Feb 2012 17:54:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S1iIv-0000j4-H9@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 17:54:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-winxpsp3-vcpus1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-winxpsp3-vcpus1
test windows-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-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-winxpsp3-vcpus1.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12079 fail [host=field-cricket] / 12031 ok.
Failure / basis pass flights: 12079 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-71159fb049f2
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 62 nodes in revision graph
Searching for test results:
 12030 pass irrelevant
 12026 pass irrelevant
 12029 blocked irrelevant
 12027 pass irrelevant
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12028 blocked irrelevant
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12077 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12073 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12078 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12080 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12081 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12083 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12053 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12079 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12084 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12086 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12087 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12062 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12074 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12075 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12053 (fail), for basis failure
 Repro found: flight 12074 (pass), for basis pass
 Repro found: flight 12075 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12080 (pass), for last pass
 Result found: flight 12081 (fail), for first failure
 Repro found: flight 12083 (pass), for last pass
 Repro found: flight 12084 (fail), for first failure
 Repro found: flight 12086 (pass), for last pass
 Repro found: flight 12087 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-winxpsp3-vcpus1.windows-install.{dot,ps,png,html}.
----------------------------------------
12087: ALL FAIL

flight 12087 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12087/


jobs:
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 20:13:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 20: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 1S1kS7-0001iL-SP; Sun, 26 Feb 2012 20:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1kS5-0001iD-GZ
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 20:12:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330287127!14793102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19389 invoked from network); 26 Feb 2012 20:12:07 -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;
	26 Feb 2012 20:12:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,487,1325462400"; d="scan'208";a="10943069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 20:12:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 20:12:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1kRy-0005mu-1c;
	Sun, 26 Feb 2012 20:12:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1kRx-00028F-MW;
	Sun, 26 Feb 2012 20:12:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12085-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 20:12:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12085: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12085 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12085/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12079
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12079 pass in 12085
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12079 pass in 12085

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12031
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12079 like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 20:13:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 20: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 1S1kS7-0001iL-SP; Sun, 26 Feb 2012 20:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S1kS5-0001iD-GZ
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 20:12:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330287127!14793102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19389 invoked from network); 26 Feb 2012 20:12:07 -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;
	26 Feb 2012 20:12:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,487,1325462400"; d="scan'208";a="10943069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2012 20:12:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 26 Feb 2012 20:12:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1kRy-0005mu-1c;
	Sun, 26 Feb 2012 20:12:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1kRx-00028F-MW;
	Sun, 26 Feb 2012 20:12:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12085-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 26 Feb 2012 20:12:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12085: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12085 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12085/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 12079
 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12079 pass in 12085
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12079 pass in 12085

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 12031
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2   fail in 12079 like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 22:15:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 22:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1mMX-0002BF-Nx; Sun, 26 Feb 2012 22:14:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S1mMW-0002BA-QD
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 22:14:37 +0000
Received: from [85.158.139.83:44767] by server-2.bemta-5.messagelabs.com id
	36/0C-20263-BCEAA4F4; Sun, 26 Feb 2012 22:14:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330294475!16206343!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDgxMDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDgxMDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23567 invoked from network); 26 Feb 2012 22:14:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Feb 2012 22:14:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330294474; l=259;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=NiUASlgOCepPOOzugpn3co12dDM=;
	b=KBBb0oU9cz2WCf9vnpxsNUQ1DyNdZytQvKZiLZuNGCNY49H2FbNKbch8+l7dVYgcYb5
	tCHPm8Bs4PaZL+m6BnJYPq/BJP4ow+jMQ7luuhazRUscj+pKuXH24vkxU8tgWGdsKcE+9
	nhwGczN//EJSQWgiF0v6qW+UREshd0NB5Hs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7aQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-7.vodafone-net.de [80.226.24.7])
	by smtp.strato.de (fruni mo41) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i02b86o1QKSJX9 ;
	Sun, 26 Feb 2012 23:14:09 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A7D0418638; Sun, 26 Feb 2012 23:14:07 +0100 (CET)
Date: Sun, 26 Feb 2012 23:14:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120226221407.GA6385@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Tim Deegan wrote:

> This is v2 of the patch I posted last week, after feedback from Andres. 

Tried this series, but processes in dom0 started to hang in D state
when a paged guest is started. I will see if I can spot the error.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 26 22:15:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 26 Feb 2012 22:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1mMX-0002BF-Nx; Sun, 26 Feb 2012 22:14:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S1mMW-0002BA-QD
	for xen-devel@lists.xensource.com; Sun, 26 Feb 2012 22:14:37 +0000
Received: from [85.158.139.83:44767] by server-2.bemta-5.messagelabs.com id
	36/0C-20263-BCEAA4F4; Sun, 26 Feb 2012 22:14:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330294475!16206343!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDgxMDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDgxMDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23567 invoked from network); 26 Feb 2012 22:14:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Feb 2012 22:14:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330294474; l=259;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=NiUASlgOCepPOOzugpn3co12dDM=;
	b=KBBb0oU9cz2WCf9vnpxsNUQ1DyNdZytQvKZiLZuNGCNY49H2FbNKbch8+l7dVYgcYb5
	tCHPm8Bs4PaZL+m6BnJYPq/BJP4ow+jMQ7luuhazRUscj+pKuXH24vkxU8tgWGdsKcE+9
	nhwGczN//EJSQWgiF0v6qW+UREshd0NB5Hs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7aQ=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-7.vodafone-net.de [80.226.24.7])
	by smtp.strato.de (fruni mo41) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id i02b86o1QKSJX9 ;
	Sun, 26 Feb 2012 23:14:09 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A7D0418638; Sun, 26 Feb 2012 23:14:07 +0100 (CET)
Date: Sun, 26 Feb 2012 23:14:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120226221407.GA6385@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1330014862@whitby.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, Tim Deegan wrote:

> This is v2 of the patch I posted last week, after feedback from Andres. 

Tried this series, but processes in dom0 started to hang in D state
when a paged guest is started. I will see if I can spot the error.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 00:25:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 00:25:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1oOP-00032e-BA; Mon, 27 Feb 2012 00:24: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 1S1oON-00032Z-FO
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 00:24:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330302250!54566472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23856 invoked from network); 27 Feb 2012 00:24:10 -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;
	27 Feb 2012 00:24:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,488,1325462400"; d="scan'208";a="10943801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 00:24:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 00:24:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1oOI-0007LA-I5;
	Mon, 27 Feb 2012 00:24:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1oOI-0000ki-Gz;
	Mon, 27 Feb 2012 00:24:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12088-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 27 Feb 2012 00:24:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12088: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12088 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12088/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12082
 test-i386-i386-xl             9 guest-start        fail in 12082 pass in 12088
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2      fail in 12082 pass in 12088

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 00:25:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 00:25:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1oOP-00032e-BA; Mon, 27 Feb 2012 00:24: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 1S1oON-00032Z-FO
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 00:24:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330302250!54566472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23856 invoked from network); 27 Feb 2012 00:24:10 -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;
	27 Feb 2012 00:24:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,488,1325462400"; d="scan'208";a="10943801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 00:24:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 00:24:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S1oOI-0007LA-I5;
	Mon, 27 Feb 2012 00:24:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S1oOI-0000ki-Gz;
	Mon, 27 Feb 2012 00:24:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12088-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 27 Feb 2012 00:24:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12088: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12088 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12088/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12082
 test-i386-i386-xl             9 guest-start        fail in 12082 pass in 12088
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2      fail in 12082 pass in 12088

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 01:35:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 01:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1pUG-00076o-TQ; Mon, 27 Feb 2012 01:34:48 +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 1S1pUF-00076h-DJ
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 01:34:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330306438!61784483!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2ODg0NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32672 invoked from network); 27 Feb 2012 01:33:59 -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; 27 Feb 2012 01:33: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 q1R1XtFL012673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 01:33:56 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
	q1R1XtpN021504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 01:33:55 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
	q1R1Xsv5030002; Sun, 26 Feb 2012 19:33:54 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 17:33:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 63EBF4031E; Sun, 26 Feb 2012 20:30:27 -0500 (EST)
Date: Sun, 26 Feb 2012 20:30:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, konrad@darnok.org
Message-ID: <20120227013027.GA16501@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]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F4ADD85.001A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) tag stable/for-linus-fixes-3.3-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

Hey Linus,

Please git pull the following tag:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-fixes-3.3-rc5

which has two fixes to fix a memory corruption bug when WC pages never get
converted back to WB but end up being recycled in the general memory
pool as WC.

There is a better way of fixing this, but there is not enough time to do the
full benchmarking to pick one of the right options - so picking the one that
favors stability for right now.

Please pull!

 arch/x86/xen/enlighten.c |    6 ++----
 arch/x86/xen/mmu.c       |    8 ++++----
 2 files changed, 6 insertions(+), 8 deletions(-)

Konrad Rzeszutek Wilk (2):
      xen/setup: Remove redundant filtering of PTE masks.
      xen/pat: Disable PAT support for now.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 01:35:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 01:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1pUG-00076o-TQ; Mon, 27 Feb 2012 01:34:48 +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 1S1pUF-00076h-DJ
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 01:34:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330306438!61784483!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU2ODg0NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32672 invoked from network); 27 Feb 2012 01:33:59 -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; 27 Feb 2012 01:33: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 q1R1XtFL012673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 01:33:56 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
	q1R1XtpN021504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 01:33:55 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
	q1R1Xsv5030002; Sun, 26 Feb 2012 19:33:54 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 17:33:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 63EBF4031E; Sun, 26 Feb 2012 20:30:27 -0500 (EST)
Date: Sun, 26 Feb 2012 20:30:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, konrad@darnok.org
Message-ID: <20120227013027.GA16501@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]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F4ADD85.001A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) tag stable/for-linus-fixes-3.3-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

Hey Linus,

Please git pull the following tag:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-fixes-3.3-rc5

which has two fixes to fix a memory corruption bug when WC pages never get
converted back to WB but end up being recycled in the general memory
pool as WC.

There is a better way of fixing this, but there is not enough time to do the
full benchmarking to pick one of the right options - so picking the one that
favors stability for right now.

Please pull!

 arch/x86/xen/enlighten.c |    6 ++----
 arch/x86/xen/mmu.c       |    8 ++++----
 2 files changed, 6 insertions(+), 8 deletions(-)

Konrad Rzeszutek Wilk (2):
      xen/setup: Remove redundant filtering of PTE masks.
      xen/pat: Disable PAT support for now.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 01:50:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 01:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1piy-0007HH-Ez; Mon, 27 Feb 2012 01:50:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S1piv-0007HC-Uj
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 01:49:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330307388!14813679!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY5MzEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32668 invoked from network); 27 Feb 2012 01:49:49 -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; 27 Feb 2012 01:49:49 -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 q1R1neYN004136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 01:49:41 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
	q1R1ndNI001993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 01:49:39 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
	q1R1ncgD031011; Sun, 26 Feb 2012 19:49:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 17:49:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9441F4031E; Sun, 26 Feb 2012 20:46:11 -0500 (EST)
Date: Sun, 26 Feb 2012 20:46:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120227014611.GA16888@phenom.dumpdata.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
	<4F47783602000078000749C0@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <4F47783602000078000749C0@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090205.4F4AE136.0064,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load
 processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich wrote:
> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > # HG changeset patch
> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > # Date 1330065828 18000
> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
> > linux-xencommons: Load processor-passthru
> > 
> > The processor-passthru module is used in the upstream kernels
> > to upload power management information to the hypervisor. We
> > need to load it to work first.
> 
> Hmm, I don't really like this (and prior) pvops-specific additions here,
> even if stderr gets directed into nowhere. I don't think this (and any
> other) script intended to target Linux in general should target just
> a specific implementation.
> 
> Furthermore, given the purpose of the driver, I'm thinking that this
> is too late in the boot process anyway, and the driver should rather
> be loaded at the point where other CPUFreq drivers would normally
> be by a particular distro (which would still be later than when the
> respective code gets run on traditional Xenified Linux).

My thinking is to keep the amount of changes to be within the Xen-ecosystem.

Doing the changes in the old-fashioned way in drivers/acpi has not been
very productive - so I've been looking at just some form of uploading
the PM information to the hypervisor. And I've been piggybacking on
top of the cpufreq scaling drivers collecting the information. So with that 
in mind, the next idea I had was to provide a cpufreq governor, called 'xen'
which would inhibit the cpufreq scaling drivers from changing anything in dom0
(so that the hypervisor can do it instead). Also it would be responsible
for uploading the PM information to the hypervisor. See attached.

The fix to the tool-stack would be something along:
# HG changeset patch
# Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8

diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 13:29:00 2012 -0500
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 21:42:20 2012 -0500
@@ -58,7 +58,7 @@ do_start () {
 	modprobe xen-gntdev 2>/dev/null
 	modprobe evtchn 2>/dev/null
 	modprobe gntdev 2>/dev/null
-
+	for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo xen > $file; done 2>/dev/null
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"

--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="0001-CPUFREQ-xen-governor-for-Xen-hypervisor-frequency-sc.patch"
Content-Transfer-Encoding: quoted-printable

>From 20e7a07fa0f8a0dbe30a0f732686d78849d29d96 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 3 Feb 2012 16:03:20 -0500
Subject: [PATCH] [CPUFREQ] xen: governor for Xen hypervisor frequency
 scaling.
MIME-Version: 1.0
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 8bit

This CPU freq governor leaves the frequency decision to the Xen hyperviso=
r.

To do that the driver parses the Power Management data and uploads said
information to the Xen hypervisor. Then the Xen hypervisor can select the
proper Cx and Pxx states for the initial domain and all other domains.

To upload the information, this CPU frequency driver reads Power Manageme=
nt (PM)
(_Pxx and _Cx) which are populated in the 'struct acpi_processor' structu=
re.
It simply reads the contents of that structure and pass it up the Xen hyp=
ervisor.
For that to work we depend on the appropriate CPU frequency scaling drive=
r
to do the heavy-lifting - so that the contents is correct.

The CPU frequency governor it has been loaded also sets up a timer
to check if the ACPI IDs count is different from the APIC ID count - whic=
h
can happen if the user choose to use dom0_max_vcpu argument. In such a ca=
se
a backup of the PM structure is used and uploaded to the hypervisor.

[v1-v2: Initial RFC implementations that were posted]
[v3: Changed the name to passthru suggested by Pasi K=E4rkk=E4inen <pasik=
@iki.fi>]
[v4: Added vCPU !=3D pCPU support - aka dom0_max_vcpus support]
[v5: Cleaned up the driver, fix bug under Athlon XP]
[v6: Changed the driver to a CPU frequency governor]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig       |   15 ++
 drivers/xen/Makefile      |    2 +-
 drivers/xen/cpufreq_xen.c |  445 +++++++++++++++++++++++++++++++++++++++=
++++++
 3 files changed, 461 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/cpufreq_xen.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..28ba371 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,19 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
=20
+config CPU_FREQ_GOV_XEN
+	tristate "'xen' governor for hypervisor scaling"
+	depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ
+	default m
+	help
+          This cpufreq governor leaves the frequency decision to the Xen=
 hypervisor.
+
+	  To do that the driver parses the Power Management data and uploads sa=
id
+	  information to the Xen hypervisor. Then the Xen hypervisor can select=
 the
+          proper Cx and Pxx states.
+
+          To compile this driver as a module, choose M here: the
+          module will be called cpufreq_xen.  If you do not know what to=
 choose,
+          select M here.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..5802220 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
-
+obj-$(CONFIG_CPU_FREQ_GOV_XEN)		+=3D cpufreq_xen.o
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
 xen-gntalloc-y				:=3D gntalloc.o
diff --git a/drivers/xen/cpufreq_xen.c b/drivers/xen/cpufreq_xen.c
new file mode 100644
index 0000000..1b709bfc
--- /dev/null
+++ b/drivers/xen/cpufreq_xen.c
@@ -0,0 +1,445 @@
+/*
+ * Copyright 2012 by Oracle Inc
+ * Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+ *
+ * This code borrows ideas from https://lkml.org/lkml/2011/11/30/249
+ * so many thanks go to Kevin Tian <kevin.tian@intel.com>
+ * and Yu Ke <ke.yu@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 WITHOU=
T
+ * 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/cpumask.h>
+#include <linux/cpufreq.h>
+#include <linux/freezer.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME "cpufreq-xen"
+
+static int no_hypercall;
+MODULE_PARM_DESC(off, "Inhibit the hypercall.");
+module_param_named(off, no_hypercall, int, 0400);
+
+/*
+ * Mutex to protect the acpi_ids_done.
+ */
+static DEFINE_MUTEX(acpi_ids_mutex);
+/*
+ * Don't think convert this to cpumask_var_t or use cpumask_bit - as tho=
se
+ * shrink to nr_cpu_bits (which is dependent on possible_cpu), which can=
 be
+ * less than what we want to put in.
+ */
+#define NR_ACPI_CPUS	NR_CPUS
+#define MAX_ACPI_BITS	(BITS_TO_LONGS(NR_ACPI_CPUS))
+static unsigned long *acpi_ids_done;
+/*
+ * Again, don't convert to cpumask - as we are reading the raw ACPI CPU =
ids
+ * which can go beyond what we presently see.
+ */
+static unsigned long *acpi_id_present;
+
+/*
+ * Pertient data for the timer to be launched to check if the # of
+ * ACPI CPU ids is different from the one we have processed.
+ */
+#define DELAY_TIMER	msecs_to_jiffies(5000 /* 5 sec */)
+static struct acpi_processor *pr_backup;
+static struct delayed_work work;
+
+static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_set_processor_pminfo,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	=3D _pr->acpi_id,
+		.u.set_pminfo.type	=3D XEN_PM_CX,
+	};
+	struct xen_processor_cx *dst_cx, *dst_cx_states =3D NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret =3D 0;
+
+	dst_cx_states =3D kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!dst_cx_states)
+		return -ENOMEM;
+
+	for (ok =3D 0, i =3D 1; i <=3D _pr->power.count; i++) {
+		cx =3D &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		dst_cx =3D &(dst_cx_states[ok++]);
+
+		dst_cx->reg.space_id =3D ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method =3D=3D ACPI_CSTATE_SYSTEMIO) {
+			dst_cx->reg.bit_width =3D 8;
+			dst_cx->reg.bit_offset =3D 0;
+			dst_cx->reg.access_size =3D 1;
+		} else {
+			dst_cx->reg.space_id =3D ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method =3D=3D ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				dst_cx->reg.bit_offset =3D 2;
+				dst_cx->reg.bit_width =3D 1; /* VENDOR_INTEL */
+			}
+			dst_cx->reg.access_size =3D 0;
+		}
+		dst_cx->reg.address =3D cx->address;
+
+		dst_cx->type =3D cx->type;
+		dst_cx->latency =3D cx->latency;
+		dst_cx->power =3D cx->power;
+
+		dst_cx->dpcnt =3D 0;
+		set_xen_guest_handle(dst_cx->dp, NULL);
+#ifdef DEBUG
+		pr_debug(DRV_NAME ": CX: ID:%d [C%d:%s] entry:%d\n",
+			_pr->acpi_id, cx->type, cx->desc, cx->entry_method);
+#endif
+	}
+	if (!ok) {
+		pr_err(DRV_NAME ": No _Cx for CPU %d\n", _pr->acpi_id);
+		kfree(dst_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count =3D ok;
+	op.u.set_pminfo.power.flags.bm_control =3D _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check =3D _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst =3D _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =3D
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, dst_cx_states);
+
+	if (!no_hypercall)
+		ret =3D HYPERVISOR_dom0_op(&op);
+
+	if (ret)
+		pr_err(DRV_NAME "(CX): Hypervisor error (%d) for ACPI ID: %d\n",
+		       ret, _pr->acpi_id);
+
+	kfree(dst_cx_states);
+
+	return ret;
+}
+static struct xen_processor_px *
+xen_copy_pss_data(struct acpi_processor *_pr,
+		  struct xen_processor_performance *dst_perf)
+{
+	struct xen_processor_px *dst_states =3D NULL;
+	int i;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=3D
+		     sizeof(struct acpi_processor_px));
+
+	dst_states =3D kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!dst_states)
+		return ERR_PTR(-ENOMEM);
+
+	dst_perf->state_count =3D _pr->performance->state_count;
+	for (i =3D 0; i < _pr->performance->state_count; i++) {
+		/* Fortunatly for us, they are both the same size */
+		memcpy(&(dst_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+	}
+	return dst_states;
+}
+static int xen_copy_psd_data(struct acpi_processor *_pr,
+			     struct xen_processor_performance *dst)
+{
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=3D
+		     sizeof(struct acpi_psd_package));
+
+	if (_pr->performance->shared_type !=3D CPUFREQ_SHARED_TYPE_NONE) {
+		dst->shared_type =3D _pr->performance->shared_type;
+
+		memcpy(&(dst->domain_info), &(_pr->performance->domain_info),
+		       sizeof(struct acpi_psd_package));
+	} else {
+		if ((&cpu_data(0))->x86_vendor !=3D X86_VENDOR_AMD)
+			return -EINVAL;
+
+		/* On AMD, the powernow-k8 is loaded before acpi_cpufreq
+		 * meaning that acpi_processor_preregister_performance never
+		 * gets called which would parse the _PSD. The only relevant
+		 * information from _PSD we need is whether it is HW_ALL or any
+		 * other type. AMD K8 >=3D are SW_ALL or SW_ANY, AMD K7<=3D HW_ANY.
+		 * This driver checks at the start whether it is K8 so it
+		 * if we get here it can only be K8.
+		 */
+		dst->shared_type =3D CPUFREQ_SHARED_TYPE_ANY;
+		dst->domain_info.coord_type =3D DOMAIN_COORD_TYPE_SW_ANY;
+		dst->domain_info.num_processors =3D num_online_cpus();
+	}
+	return 0;
+}
+static int xen_copy_pct_data(struct acpi_pct_register *pct,
+			     struct xen_pct_register *dst_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, dst_pct') but
+	 * sadly the Xen structure did not have the proper padding so the
+	 * descriptor field takes two (dst_pct) bytes instead of one (pct).
+	 */
+	dst_pct->descriptor =3D pct->descriptor;
+	dst_pct->length =3D pct->length;
+	dst_pct->space_id =3D pct->space_id;
+	dst_pct->bit_width =3D pct->bit_width;
+	dst_pct->bit_offset =3D pct->bit_offset;
+	dst_pct->reserved =3D pct->reserved;
+	dst_pct->address =3D pct->address;
+	return 0;
+}
+static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret =3D 0;
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_set_processor_pminfo,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	=3D _pr->acpi_id,
+		.u.set_pminfo.type	=3D XEN_PM_PX,
+	};
+	struct xen_processor_performance *dst_perf;
+	struct xen_processor_px *dst_states =3D NULL;
+
+	dst_perf =3D &op.u.set_pminfo.perf;
+
+	dst_perf->platform_limit =3D _pr->performance_platform_limit;
+	dst_perf->flags |=3D XEN_PX_PPC;
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &dst_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &dst_perf->status_register);
+	dst_perf->flags |=3D XEN_PX_PCT;
+	dst_states =3D xen_copy_pss_data(_pr, dst_perf);
+	if (!IS_ERR_OR_NULL(dst_states)) {
+		set_xen_guest_handle(dst_perf->states, dst_states);
+		dst_perf->flags |=3D XEN_PX_PSS;
+	}
+	if (!xen_copy_psd_data(_pr, dst_perf))
+		dst_perf->flags |=3D XEN_PX_PSD;
+
+	if (!no_hypercall)
+		ret =3D HYPERVISOR_dom0_op(&op);
+
+	if (ret)
+		pr_err(DRV_NAME "(_PXX): Hypervisor error (%d) for ACPI ID %d\n",
+		       ret, _pr->acpi_id);
+
+	if (!IS_ERR_OR_NULL(dst_states))
+		kfree(dst_states);
+
+	return ret;
+}
+static int upload_pm_data(struct acpi_processor *_pr)
+{
+	int err =3D 0;
+
+	if (__test_and_set_bit(_pr->acpi_id, acpi_ids_done))
+		return -EBUSY;
+
+	if (_pr->flags.power)
+		err =3D push_cxx_to_hypervisor(_pr);
+
+	if (_pr->performance && _pr->performance->states)
+		err |=3D push_pxx_to_hypervisor(_pr);
+
+	return err;
+}
+static acpi_status
+read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	u32 acpi_id;
+	acpi_status status;
+	acpi_object_type acpi_type;
+	unsigned long long tmp;
+	union acpi_object object =3D { 0 };
+	struct acpi_buffer buffer =3D { sizeof(union acpi_object), &object };
+
+	status =3D acpi_get_type(handle, &acpi_type);
+	if (ACPI_FAILURE(status))
+		return AE_OK;
+
+	switch (acpi_type) {
+	case ACPI_TYPE_PROCESSOR:
+		status =3D acpi_evaluate_object(handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id =3D object.processor.proc_id;
+		break;
+	case ACPI_TYPE_DEVICE:
+		status =3D acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id =3D tmp;
+		break;
+	default:
+		return AE_OK;
+	}
+	if (acpi_id > NR_ACPI_CPUS) {
+		WARN_ONCE(1, "There are %d ACPI processors, but kernel can only do %d!=
\n",
+		     acpi_id, NR_ACPI_CPUS);
+		return AE_OK;
+	}
+	__set_bit(acpi_id, acpi_id_present);
+
+	return AE_OK;
+}
+static unsigned int more_acpi_ids(void)
+{
+	unsigned int n =3D 0;
+
+	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+			    ACPI_UINT32_MAX,
+			    read_acpi_id, NULL, NULL, NULL);
+	acpi_get_devices("ACPI0007", read_acpi_id, NULL, NULL);
+
+	mutex_lock(&acpi_ids_mutex);
+	if (!bitmap_equal(acpi_id_present, acpi_ids_done, MAX_ACPI_BITS))
+		n =3D bitmap_weight(acpi_id_present, MAX_ACPI_BITS);
+	mutex_unlock(&acpi_ids_mutex);
+
+	return n;
+}
+static void do_check_acpi_id_timer(struct work_struct *_work)
+{
+	/* All online CPUs have been processed at this stage. Now verify
+	 * whether in fact "online CPUs" =3D=3D physical CPUs.
+	 */
+	acpi_id_present =3D kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_K=
ERNEL);
+	if (!acpi_id_present)
+		return;
+	memset(acpi_id_present, 0, MAX_ACPI_BITS * sizeof(unsigned long));
+
+	if (more_acpi_ids()) {
+		int cpu;
+		if (!pr_backup) {
+			schedule_delayed_work(&work, DELAY_TIMER);
+			return;
+		}
+		for_each_set_bit(cpu, acpi_id_present, MAX_ACPI_BITS) {
+			pr_backup->acpi_id =3D cpu;
+			mutex_lock(&acpi_ids_mutex);
+			(void)upload_pm_data(pr_backup);
+			mutex_unlock(&acpi_ids_mutex);
+		}
+	}
+	kfree(acpi_id_present);
+	acpi_id_present =3D NULL;
+}
+
+static int cpufreq_governor_xen(struct cpufreq_policy *policy,
+				unsigned int event)
+{
+	struct acpi_processor *_pr;
+
+	switch (event) {
+	case CPUFREQ_GOV_START:
+	case CPUFREQ_GOV_LIMITS:
+		/* Set it to max and let the hypervisor take over */
+		__cpufreq_driver_target(policy, policy->max, CPUFREQ_RELATION_H);
+
+		_pr =3D per_cpu(processors, policy->cpu /* APIC ID */);
+		if (!_pr)
+			break;
+
+		mutex_lock(&acpi_ids_mutex);
+		if (!pr_backup) {
+			pr_backup =3D kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+			memcpy(pr_backup, _pr, sizeof(struct acpi_processor));
+
+			INIT_DELAYED_WORK_DEFERRABLE(&work, do_check_acpi_id_timer);
+			schedule_delayed_work(&work, DELAY_TIMER);
+		}
+		(void)upload_pm_data(_pr);
+		mutex_unlock(&acpi_ids_mutex);
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+static struct cpufreq_governor cpufreq_gov_xen =3D {
+	.name		=3D "xen",
+	.governor	=3D cpufreq_governor_xen,
+	.owner		=3D THIS_MODULE,
+};
+static int __init check_prereq(void)
+{
+	struct cpuinfo_x86 *c =3D &cpu_data(0);
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	if (!acpi_gbl_FADT.smi_command)
+		return -ENODEV;
+
+	if (c->x86_vendor =3D=3D X86_VENDOR_INTEL) {
+		if (!cpu_has(c, X86_FEATURE_EST))
+			return -ENODEV;
+
+		return 0;
+	}
+	if (c->x86_vendor =3D=3D X86_VENDOR_AMD) {
+		u32 hi =3D 0, lo =3D 0;
+		/* Copied from powernow-k8.h, can't include ../cpufreq/powernow
+		 * as we get compile warnings for the static functions.
+		 */
+#define MSR_PSTATE_CUR_LIMIT    0xc0010061 /* pstate current limit MSR *=
/
+		rdmsr(MSR_PSTATE_CUR_LIMIT, lo, hi);
+
+		/* If the MSR cannot provide the data, the powernow-k8
+		 * won't process the data properly either.
+		 */
+		if (hi || lo)
+			return 0;
+	}
+	return -ENODEV;
+}
+
+static int __init xen_processor_passthru_init(void)
+{
+	int rc =3D check_prereq();
+
+	if (rc)
+		return rc;
+
+	acpi_ids_done =3D kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_KER=
NEL);
+	if (!acpi_ids_done)
+		return -ENOMEM;
+	memset(acpi_ids_done, 0, MAX_ACPI_BITS * sizeof(unsigned long));
+
+	return cpufreq_register_governor(&cpufreq_gov_xen);
+}
+static void __exit xen_processor_passthru_exit(void)
+{
+	cpufreq_unregister_governor(&cpufreq_gov_xen);
+	cancel_delayed_work_sync(&work);
+	kfree(acpi_ids_done);
+	kfree(pr_backup);
+}
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
+MODULE_DESCRIPTION("CPUfreq policy governor 'xen' which uploads PM data =
to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+late_initcall(xen_processor_passthru_init);
+module_exit(xen_processor_passthru_exit);
--=20
1.7.9.48.g85da4d


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--cWoXeonUoKmBZSoM--


From xen-devel-bounces@lists.xen.org Mon Feb 27 01:50:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 01:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1piy-0007HH-Ez; Mon, 27 Feb 2012 01:50:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1S1piv-0007HC-Uj
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 01:49:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330307388!14813679!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY5MzEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32668 invoked from network); 27 Feb 2012 01:49:49 -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; 27 Feb 2012 01:49:49 -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 q1R1neYN004136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 01:49:41 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
	q1R1ndNI001993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 01:49:39 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
	q1R1ncgD031011; Sun, 26 Feb 2012 19:49:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 26 Feb 2012 17:49:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9441F4031E; Sun, 26 Feb 2012 20:46:11 -0500 (EST)
Date: Sun, 26 Feb 2012 20:46:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120227014611.GA16888@phenom.dumpdata.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
	<4F47783602000078000749C0@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <4F47783602000078000749C0@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090205.4F4AE136.0064,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load
 processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich wrote:
> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > # HG changeset patch
> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > # Date 1330065828 18000
> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
> > linux-xencommons: Load processor-passthru
> > 
> > The processor-passthru module is used in the upstream kernels
> > to upload power management information to the hypervisor. We
> > need to load it to work first.
> 
> Hmm, I don't really like this (and prior) pvops-specific additions here,
> even if stderr gets directed into nowhere. I don't think this (and any
> other) script intended to target Linux in general should target just
> a specific implementation.
> 
> Furthermore, given the purpose of the driver, I'm thinking that this
> is too late in the boot process anyway, and the driver should rather
> be loaded at the point where other CPUFreq drivers would normally
> be by a particular distro (which would still be later than when the
> respective code gets run on traditional Xenified Linux).

My thinking is to keep the amount of changes to be within the Xen-ecosystem.

Doing the changes in the old-fashioned way in drivers/acpi has not been
very productive - so I've been looking at just some form of uploading
the PM information to the hypervisor. And I've been piggybacking on
top of the cpufreq scaling drivers collecting the information. So with that 
in mind, the next idea I had was to provide a cpufreq governor, called 'xen'
which would inhibit the cpufreq scaling drivers from changing anything in dom0
(so that the hypervisor can do it instead). Also it would be responsible
for uploading the PM information to the hypervisor. See attached.

The fix to the tool-stack would be something along:
# HG changeset patch
# Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8

diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 13:29:00 2012 -0500
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 21:42:20 2012 -0500
@@ -58,7 +58,7 @@ do_start () {
 	modprobe xen-gntdev 2>/dev/null
 	modprobe evtchn 2>/dev/null
 	modprobe gntdev 2>/dev/null
-
+	for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo xen > $file; done 2>/dev/null
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"

--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="0001-CPUFREQ-xen-governor-for-Xen-hypervisor-frequency-sc.patch"
Content-Transfer-Encoding: quoted-printable

>From 20e7a07fa0f8a0dbe30a0f732686d78849d29d96 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 3 Feb 2012 16:03:20 -0500
Subject: [PATCH] [CPUFREQ] xen: governor for Xen hypervisor frequency
 scaling.
MIME-Version: 1.0
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 8bit

This CPU freq governor leaves the frequency decision to the Xen hyperviso=
r.

To do that the driver parses the Power Management data and uploads said
information to the Xen hypervisor. Then the Xen hypervisor can select the
proper Cx and Pxx states for the initial domain and all other domains.

To upload the information, this CPU frequency driver reads Power Manageme=
nt (PM)
(_Pxx and _Cx) which are populated in the 'struct acpi_processor' structu=
re.
It simply reads the contents of that structure and pass it up the Xen hyp=
ervisor.
For that to work we depend on the appropriate CPU frequency scaling drive=
r
to do the heavy-lifting - so that the contents is correct.

The CPU frequency governor it has been loaded also sets up a timer
to check if the ACPI IDs count is different from the APIC ID count - whic=
h
can happen if the user choose to use dom0_max_vcpu argument. In such a ca=
se
a backup of the PM structure is used and uploaded to the hypervisor.

[v1-v2: Initial RFC implementations that were posted]
[v3: Changed the name to passthru suggested by Pasi K=E4rkk=E4inen <pasik=
@iki.fi>]
[v4: Added vCPU !=3D pCPU support - aka dom0_max_vcpus support]
[v5: Cleaned up the driver, fix bug under Athlon XP]
[v6: Changed the driver to a CPU frequency governor]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig       |   15 ++
 drivers/xen/Makefile      |    2 +-
 drivers/xen/cpufreq_xen.c |  445 +++++++++++++++++++++++++++++++++++++++=
++++++
 3 files changed, 461 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/cpufreq_xen.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..28ba371 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,19 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
=20
+config CPU_FREQ_GOV_XEN
+	tristate "'xen' governor for hypervisor scaling"
+	depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ
+	default m
+	help
+          This cpufreq governor leaves the frequency decision to the Xen=
 hypervisor.
+
+	  To do that the driver parses the Power Management data and uploads sa=
id
+	  information to the Xen hypervisor. Then the Xen hypervisor can select=
 the
+          proper Cx and Pxx states.
+
+          To compile this driver as a module, choose M here: the
+          module will be called cpufreq_xen.  If you do not know what to=
 choose,
+          select M here.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..5802220 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+=3D swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+=3D pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
-
+obj-$(CONFIG_CPU_FREQ_GOV_XEN)		+=3D cpufreq_xen.o
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
 xen-gntalloc-y				:=3D gntalloc.o
diff --git a/drivers/xen/cpufreq_xen.c b/drivers/xen/cpufreq_xen.c
new file mode 100644
index 0000000..1b709bfc
--- /dev/null
+++ b/drivers/xen/cpufreq_xen.c
@@ -0,0 +1,445 @@
+/*
+ * Copyright 2012 by Oracle Inc
+ * Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+ *
+ * This code borrows ideas from https://lkml.org/lkml/2011/11/30/249
+ * so many thanks go to Kevin Tian <kevin.tian@intel.com>
+ * and Yu Ke <ke.yu@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 WITHOU=
T
+ * 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/cpumask.h>
+#include <linux/cpufreq.h>
+#include <linux/freezer.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME "cpufreq-xen"
+
+static int no_hypercall;
+MODULE_PARM_DESC(off, "Inhibit the hypercall.");
+module_param_named(off, no_hypercall, int, 0400);
+
+/*
+ * Mutex to protect the acpi_ids_done.
+ */
+static DEFINE_MUTEX(acpi_ids_mutex);
+/*
+ * Don't think convert this to cpumask_var_t or use cpumask_bit - as tho=
se
+ * shrink to nr_cpu_bits (which is dependent on possible_cpu), which can=
 be
+ * less than what we want to put in.
+ */
+#define NR_ACPI_CPUS	NR_CPUS
+#define MAX_ACPI_BITS	(BITS_TO_LONGS(NR_ACPI_CPUS))
+static unsigned long *acpi_ids_done;
+/*
+ * Again, don't convert to cpumask - as we are reading the raw ACPI CPU =
ids
+ * which can go beyond what we presently see.
+ */
+static unsigned long *acpi_id_present;
+
+/*
+ * Pertient data for the timer to be launched to check if the # of
+ * ACPI CPU ids is different from the one we have processed.
+ */
+#define DELAY_TIMER	msecs_to_jiffies(5000 /* 5 sec */)
+static struct acpi_processor *pr_backup;
+static struct delayed_work work;
+
+static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_set_processor_pminfo,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	=3D _pr->acpi_id,
+		.u.set_pminfo.type	=3D XEN_PM_CX,
+	};
+	struct xen_processor_cx *dst_cx, *dst_cx_states =3D NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret =3D 0;
+
+	dst_cx_states =3D kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!dst_cx_states)
+		return -ENOMEM;
+
+	for (ok =3D 0, i =3D 1; i <=3D _pr->power.count; i++) {
+		cx =3D &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		dst_cx =3D &(dst_cx_states[ok++]);
+
+		dst_cx->reg.space_id =3D ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method =3D=3D ACPI_CSTATE_SYSTEMIO) {
+			dst_cx->reg.bit_width =3D 8;
+			dst_cx->reg.bit_offset =3D 0;
+			dst_cx->reg.access_size =3D 1;
+		} else {
+			dst_cx->reg.space_id =3D ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method =3D=3D ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				dst_cx->reg.bit_offset =3D 2;
+				dst_cx->reg.bit_width =3D 1; /* VENDOR_INTEL */
+			}
+			dst_cx->reg.access_size =3D 0;
+		}
+		dst_cx->reg.address =3D cx->address;
+
+		dst_cx->type =3D cx->type;
+		dst_cx->latency =3D cx->latency;
+		dst_cx->power =3D cx->power;
+
+		dst_cx->dpcnt =3D 0;
+		set_xen_guest_handle(dst_cx->dp, NULL);
+#ifdef DEBUG
+		pr_debug(DRV_NAME ": CX: ID:%d [C%d:%s] entry:%d\n",
+			_pr->acpi_id, cx->type, cx->desc, cx->entry_method);
+#endif
+	}
+	if (!ok) {
+		pr_err(DRV_NAME ": No _Cx for CPU %d\n", _pr->acpi_id);
+		kfree(dst_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count =3D ok;
+	op.u.set_pminfo.power.flags.bm_control =3D _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check =3D _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst =3D _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =3D
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, dst_cx_states);
+
+	if (!no_hypercall)
+		ret =3D HYPERVISOR_dom0_op(&op);
+
+	if (ret)
+		pr_err(DRV_NAME "(CX): Hypervisor error (%d) for ACPI ID: %d\n",
+		       ret, _pr->acpi_id);
+
+	kfree(dst_cx_states);
+
+	return ret;
+}
+static struct xen_processor_px *
+xen_copy_pss_data(struct acpi_processor *_pr,
+		  struct xen_processor_performance *dst_perf)
+{
+	struct xen_processor_px *dst_states =3D NULL;
+	int i;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=3D
+		     sizeof(struct acpi_processor_px));
+
+	dst_states =3D kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!dst_states)
+		return ERR_PTR(-ENOMEM);
+
+	dst_perf->state_count =3D _pr->performance->state_count;
+	for (i =3D 0; i < _pr->performance->state_count; i++) {
+		/* Fortunatly for us, they are both the same size */
+		memcpy(&(dst_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+	}
+	return dst_states;
+}
+static int xen_copy_psd_data(struct acpi_processor *_pr,
+			     struct xen_processor_performance *dst)
+{
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=3D
+		     sizeof(struct acpi_psd_package));
+
+	if (_pr->performance->shared_type !=3D CPUFREQ_SHARED_TYPE_NONE) {
+		dst->shared_type =3D _pr->performance->shared_type;
+
+		memcpy(&(dst->domain_info), &(_pr->performance->domain_info),
+		       sizeof(struct acpi_psd_package));
+	} else {
+		if ((&cpu_data(0))->x86_vendor !=3D X86_VENDOR_AMD)
+			return -EINVAL;
+
+		/* On AMD, the powernow-k8 is loaded before acpi_cpufreq
+		 * meaning that acpi_processor_preregister_performance never
+		 * gets called which would parse the _PSD. The only relevant
+		 * information from _PSD we need is whether it is HW_ALL or any
+		 * other type. AMD K8 >=3D are SW_ALL or SW_ANY, AMD K7<=3D HW_ANY.
+		 * This driver checks at the start whether it is K8 so it
+		 * if we get here it can only be K8.
+		 */
+		dst->shared_type =3D CPUFREQ_SHARED_TYPE_ANY;
+		dst->domain_info.coord_type =3D DOMAIN_COORD_TYPE_SW_ANY;
+		dst->domain_info.num_processors =3D num_online_cpus();
+	}
+	return 0;
+}
+static int xen_copy_pct_data(struct acpi_pct_register *pct,
+			     struct xen_pct_register *dst_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, dst_pct') but
+	 * sadly the Xen structure did not have the proper padding so the
+	 * descriptor field takes two (dst_pct) bytes instead of one (pct).
+	 */
+	dst_pct->descriptor =3D pct->descriptor;
+	dst_pct->length =3D pct->length;
+	dst_pct->space_id =3D pct->space_id;
+	dst_pct->bit_width =3D pct->bit_width;
+	dst_pct->bit_offset =3D pct->bit_offset;
+	dst_pct->reserved =3D pct->reserved;
+	dst_pct->address =3D pct->address;
+	return 0;
+}
+static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret =3D 0;
+	struct xen_platform_op op =3D {
+		.cmd			=3D XENPF_set_processor_pminfo,
+		.interface_version	=3D XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	=3D _pr->acpi_id,
+		.u.set_pminfo.type	=3D XEN_PM_PX,
+	};
+	struct xen_processor_performance *dst_perf;
+	struct xen_processor_px *dst_states =3D NULL;
+
+	dst_perf =3D &op.u.set_pminfo.perf;
+
+	dst_perf->platform_limit =3D _pr->performance_platform_limit;
+	dst_perf->flags |=3D XEN_PX_PPC;
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &dst_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &dst_perf->status_register);
+	dst_perf->flags |=3D XEN_PX_PCT;
+	dst_states =3D xen_copy_pss_data(_pr, dst_perf);
+	if (!IS_ERR_OR_NULL(dst_states)) {
+		set_xen_guest_handle(dst_perf->states, dst_states);
+		dst_perf->flags |=3D XEN_PX_PSS;
+	}
+	if (!xen_copy_psd_data(_pr, dst_perf))
+		dst_perf->flags |=3D XEN_PX_PSD;
+
+	if (!no_hypercall)
+		ret =3D HYPERVISOR_dom0_op(&op);
+
+	if (ret)
+		pr_err(DRV_NAME "(_PXX): Hypervisor error (%d) for ACPI ID %d\n",
+		       ret, _pr->acpi_id);
+
+	if (!IS_ERR_OR_NULL(dst_states))
+		kfree(dst_states);
+
+	return ret;
+}
+static int upload_pm_data(struct acpi_processor *_pr)
+{
+	int err =3D 0;
+
+	if (__test_and_set_bit(_pr->acpi_id, acpi_ids_done))
+		return -EBUSY;
+
+	if (_pr->flags.power)
+		err =3D push_cxx_to_hypervisor(_pr);
+
+	if (_pr->performance && _pr->performance->states)
+		err |=3D push_pxx_to_hypervisor(_pr);
+
+	return err;
+}
+static acpi_status
+read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	u32 acpi_id;
+	acpi_status status;
+	acpi_object_type acpi_type;
+	unsigned long long tmp;
+	union acpi_object object =3D { 0 };
+	struct acpi_buffer buffer =3D { sizeof(union acpi_object), &object };
+
+	status =3D acpi_get_type(handle, &acpi_type);
+	if (ACPI_FAILURE(status))
+		return AE_OK;
+
+	switch (acpi_type) {
+	case ACPI_TYPE_PROCESSOR:
+		status =3D acpi_evaluate_object(handle, NULL, NULL, &buffer);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id =3D object.processor.proc_id;
+		break;
+	case ACPI_TYPE_DEVICE:
+		status =3D acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+		if (ACPI_FAILURE(status))
+			return AE_OK;
+		acpi_id =3D tmp;
+		break;
+	default:
+		return AE_OK;
+	}
+	if (acpi_id > NR_ACPI_CPUS) {
+		WARN_ONCE(1, "There are %d ACPI processors, but kernel can only do %d!=
\n",
+		     acpi_id, NR_ACPI_CPUS);
+		return AE_OK;
+	}
+	__set_bit(acpi_id, acpi_id_present);
+
+	return AE_OK;
+}
+static unsigned int more_acpi_ids(void)
+{
+	unsigned int n =3D 0;
+
+	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+			    ACPI_UINT32_MAX,
+			    read_acpi_id, NULL, NULL, NULL);
+	acpi_get_devices("ACPI0007", read_acpi_id, NULL, NULL);
+
+	mutex_lock(&acpi_ids_mutex);
+	if (!bitmap_equal(acpi_id_present, acpi_ids_done, MAX_ACPI_BITS))
+		n =3D bitmap_weight(acpi_id_present, MAX_ACPI_BITS);
+	mutex_unlock(&acpi_ids_mutex);
+
+	return n;
+}
+static void do_check_acpi_id_timer(struct work_struct *_work)
+{
+	/* All online CPUs have been processed at this stage. Now verify
+	 * whether in fact "online CPUs" =3D=3D physical CPUs.
+	 */
+	acpi_id_present =3D kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_K=
ERNEL);
+	if (!acpi_id_present)
+		return;
+	memset(acpi_id_present, 0, MAX_ACPI_BITS * sizeof(unsigned long));
+
+	if (more_acpi_ids()) {
+		int cpu;
+		if (!pr_backup) {
+			schedule_delayed_work(&work, DELAY_TIMER);
+			return;
+		}
+		for_each_set_bit(cpu, acpi_id_present, MAX_ACPI_BITS) {
+			pr_backup->acpi_id =3D cpu;
+			mutex_lock(&acpi_ids_mutex);
+			(void)upload_pm_data(pr_backup);
+			mutex_unlock(&acpi_ids_mutex);
+		}
+	}
+	kfree(acpi_id_present);
+	acpi_id_present =3D NULL;
+}
+
+static int cpufreq_governor_xen(struct cpufreq_policy *policy,
+				unsigned int event)
+{
+	struct acpi_processor *_pr;
+
+	switch (event) {
+	case CPUFREQ_GOV_START:
+	case CPUFREQ_GOV_LIMITS:
+		/* Set it to max and let the hypervisor take over */
+		__cpufreq_driver_target(policy, policy->max, CPUFREQ_RELATION_H);
+
+		_pr =3D per_cpu(processors, policy->cpu /* APIC ID */);
+		if (!_pr)
+			break;
+
+		mutex_lock(&acpi_ids_mutex);
+		if (!pr_backup) {
+			pr_backup =3D kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
+			memcpy(pr_backup, _pr, sizeof(struct acpi_processor));
+
+			INIT_DELAYED_WORK_DEFERRABLE(&work, do_check_acpi_id_timer);
+			schedule_delayed_work(&work, DELAY_TIMER);
+		}
+		(void)upload_pm_data(_pr);
+		mutex_unlock(&acpi_ids_mutex);
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+static struct cpufreq_governor cpufreq_gov_xen =3D {
+	.name		=3D "xen",
+	.governor	=3D cpufreq_governor_xen,
+	.owner		=3D THIS_MODULE,
+};
+static int __init check_prereq(void)
+{
+	struct cpuinfo_x86 *c =3D &cpu_data(0);
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	if (!acpi_gbl_FADT.smi_command)
+		return -ENODEV;
+
+	if (c->x86_vendor =3D=3D X86_VENDOR_INTEL) {
+		if (!cpu_has(c, X86_FEATURE_EST))
+			return -ENODEV;
+
+		return 0;
+	}
+	if (c->x86_vendor =3D=3D X86_VENDOR_AMD) {
+		u32 hi =3D 0, lo =3D 0;
+		/* Copied from powernow-k8.h, can't include ../cpufreq/powernow
+		 * as we get compile warnings for the static functions.
+		 */
+#define MSR_PSTATE_CUR_LIMIT    0xc0010061 /* pstate current limit MSR *=
/
+		rdmsr(MSR_PSTATE_CUR_LIMIT, lo, hi);
+
+		/* If the MSR cannot provide the data, the powernow-k8
+		 * won't process the data properly either.
+		 */
+		if (hi || lo)
+			return 0;
+	}
+	return -ENODEV;
+}
+
+static int __init xen_processor_passthru_init(void)
+{
+	int rc =3D check_prereq();
+
+	if (rc)
+		return rc;
+
+	acpi_ids_done =3D kcalloc(MAX_ACPI_BITS, sizeof(unsigned long), GFP_KER=
NEL);
+	if (!acpi_ids_done)
+		return -ENOMEM;
+	memset(acpi_ids_done, 0, MAX_ACPI_BITS * sizeof(unsigned long));
+
+	return cpufreq_register_governor(&cpufreq_gov_xen);
+}
+static void __exit xen_processor_passthru_exit(void)
+{
+	cpufreq_unregister_governor(&cpufreq_gov_xen);
+	cancel_delayed_work_sync(&work);
+	kfree(acpi_ids_done);
+	kfree(pr_backup);
+}
+
+MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
+MODULE_DESCRIPTION("CPUfreq policy governor 'xen' which uploads PM data =
to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+late_initcall(xen_processor_passthru_init);
+module_exit(xen_processor_passthru_exit);
--=20
1.7.9.48.g85da4d


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--cWoXeonUoKmBZSoM--


From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uKV-0000cm-I9; Mon, 27 Feb 2012 06:45:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKT-0000cP-Li
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:01 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16513 invoked from network); 27 Feb 2012 06:44:55 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:55 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCY085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: ce4ab89a357866208e146bbe076ddd9f73129ab1
Message-Id: <ce4ab89a357866208e14.1330324035@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:15 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0849 (UTC)
	FILETIME=[4FCA6C90:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 4 v4] blkif.h: Miscelaneous style 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

  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a4d93d0e0df2 -r ce4ab89a3578 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uKV-0000cm-I9; Mon, 27 Feb 2012 06:45:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKT-0000cP-Li
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:01 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!2
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16513 invoked from network); 27 Feb 2012 06:44:55 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:55 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCY085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: ce4ab89a357866208e146bbe076ddd9f73129ab1
Message-Id: <ce4ab89a357866208e14.1330324035@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:15 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0849 (UTC)
	FILETIME=[4FCA6C90:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 4 v4] blkif.h: Miscelaneous style 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

  o Remove trailing whitespace.
  o Remove a blank line so that a comment block is adjacent to the
    code it documents.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a4d93d0e0df2 -r ce4ab89a3578 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Wed Feb 22 14:33:24 2012 +0000
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
@@ -1,8 +1,8 @@
 /******************************************************************************
  * blkif.h
- * 
+ *
  * Unified block-device I/O interface for Xen guest OSes.
- * 
+ *
  * 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
@@ -35,7 +35,7 @@
  * notification can be made conditional on req_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Backends must set
  * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
- * 
+ *
  * Back->front notifications: When enqueuing a new response, sending a
  * notification can be made conditional on rsp_event (i.e., the generic
  * hold-off mechanism provided by the ring macros). Frontends must set
@@ -133,7 +133,7 @@
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
-/* 
+/*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
  * sector_number in blkif_request, are always expressed in 512-byte units.
  * However they must be properly aligned to the real sector size of the
@@ -192,7 +192,6 @@ typedef struct blkif_response blkif_resp
 /*
  * Generate blkif ring structures and types.
  */
-
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
 #define VDISK_CDROM        0x1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uKX-0000dI-Fn; Mon, 27 Feb 2012 06:45:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKV-0000cR-Ob
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:04 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16572 invoked from network); 27 Feb 2012 06:44:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCZ085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 162cce84d405447e076d352d2bee8830cc70b6de
Message-Id: <162cce84d405447e076d.1330324036@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:16 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0864 (UTC)
	FILETIME=[4FCCB680:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 4 v4] blkif.h: Provide more complete
 documentation of the blkif 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

  o Document the XenBus nodes used in this protocol.
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r ce4ab89a3578 -r 162cce84d405 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,253 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formatted node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------ Backend Device Identification (PRIVATE) ------------------
+ *
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      Data used by the backend driver to locate and configure the backing
+ *      device.  The format and semantics of this data vary according to the
+ *      backing device in use and are outside the scope of this specification.
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-alignment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The size, in bytes, of the individually addressible data blocks
+ *      on the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of "sector-size".
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint32_t>
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ *      See docs/misc/vbd-interface.txt for details on the format of this
+ *      value.
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +304,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA), or unmap (SCSI)
+ * command on a physical device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +346,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +360,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uKX-0000dI-Fn; Mon, 27 Feb 2012 06:45:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKV-0000cR-Ob
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:04 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!4
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16572 invoked from network); 27 Feb 2012 06:44:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCZ085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 162cce84d405447e076d352d2bee8830cc70b6de
Message-Id: <162cce84d405447e076d.1330324036@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:16 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0864 (UTC)
	FILETIME=[4FCCB680:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 2 of 4 v4] blkif.h: Provide more complete
 documentation of the blkif 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

  o Document the XenBus nodes used in this protocol.
  o Add a state diagram illustrating the roles and responsibilities
    of both the front and backend during startup.
  o Correct missed BLKIF_OP_TRIM => BLKIF_OP_DISCARD conversion in a comment.

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r ce4ab89a3578 -r 162cce84d405 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
@@ -22,6 +22,7 @@
  * DEALINGS IN THE SOFTWARE.
  *
  * Copyright (c) 2003-2004, Keir Fraser
+ * Copyright (c) 2012, Spectra Logic Corporation
  */
 
 #ifndef __XEN_PUBLIC_IO_BLKIF_H__
@@ -48,32 +49,253 @@
 #define blkif_sector_t uint64_t
 
 /*
+ * Feature and Parameter Negotiation
+ * =================================
+ * The two halves of a Xen block driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * All data in the XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal.  Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formatted node string, without loss of information.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ * See the XenBus state transition diagram below for details on when XenBus
+ * nodes must be published and when they can be queried.
+ *
+ *****************************************************************************
+ *                            Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------ Backend Device Identification (PRIVATE) ------------------
+ *
+ * mode
+ *      Values:         "r" (read only), "w" (writable)
+ *
+ *      The read or write access permissions to the backing store to be
+ *      granted to the frontend.
+ *
+ * params
+ *      Values:         string
+ *
+ *      Data used by the backend driver to locate and configure the backing
+ *      device.  The format and semantics of this data vary according to the
+ *      backing device in use and are outside the scope of this specification.
+ *
+ * type
+ *      Values:         "file", "phy", "tap"
+ *
+ *      The type of the backing device/object.
+ *
+ *--------------------------------- Features ---------------------------------
+ *
+ * feature-barrier
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_WRITE_BARRIER request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-flush-cache
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_FLUSH_DISKCACHE request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ * feature-discard
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DISCARD request opcode.  Requests
+ *      of this type may still be returned at any time with the
+ *      BLKIF_RSP_EOPNOTSUPP result code.
+ *
+ *------------------------- Backend Device Properties -------------------------
+ *
+ * discard-alignment
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 2
+ *
+ *      The offset, in bytes from the beginning of the virtual block device,
+ *      to the first, addressable, discard extent on the underlying device.
+ *
+ * discard-granularity
+ *      Values:         <uint32_t>
+ *      Default Value:  <"sector-size">
+ *      Notes:          1
+ *
+ *      The size, in bytes, of the individually addressable discard extents
+ *      of the underlying device.
+ *
+ * discard-secure
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process BLKIF_OP_DISCARD
+ *      requests with the BLKIF_DISCARD_SECURE flag set.
+ *
+ * info
+ *      Values:         <uint32_t> (bitmap)
+ *
+ *      A collection of bit flags describing attributes of the backing
+ *      device.  The VDISK_* macros define the meaning of each bit
+ *      location.
+ *
+ * sector-size
+ *      Values:         <uint32_t>
+ *
+ *      The size, in bytes, of the individually addressible data blocks
+ *      on the backend device.
+ *
+ * sectors
+ *      Values:         <uint64_t>
+ *
+ *      The size of the backend device, expressed in units of "sector-size".
+ *
+ *****************************************************************************
+ *                            Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ *      Values:         <uint32_t>
+ *
+ *      The identifier of the Xen event channel used to signal activity
+ *      in the ring buffer.
+ *
+ * ring-ref
+ *      Values:         <uint32_t>
+ *
+ *      The Xen grant reference granting permission for the backend to map
+ *      the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *      Values:         string (XEN_IO_PROTO_ABI_*)
+ *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *      The machine ABI rules governing the format of all ring request and
+ *      response structures.
+ *
+ *------------------------- Virtual Device Properties -------------------------
+ *
+ * device-type
+ *      Values:         "disk", "cdrom", "floppy", etc.
+ *
+ * virtual-device
+ *      Values:         <uint32_t>
+ *
+ *      A value indicating the physical device to virtualize within the
+ *      frontend's domain.  (e.g. "The first ATA disk", "The third SCSI
+ *      disk", etc.)
+ *
+ *      See docs/misc/vbd-interface.txt for details on the format of this
+ *      value.
+ *
+ * Notes
+ * -----
+ * (1) Devices that support discard functionality may internally allocate
+ *     space (discardable extents) in units that are larger than the
+ *     exported logical block size.
+ * (2) The discard-alignment parameter allows a physical device to be
+ *     partitioned into virtual devices that do not necessarily begin or
+ *     end on a discardable extent boundary.
+ */
+
+/*
+ * STATE DIAGRAMS
+ *
+ *****************************************************************************
+ *                                   Startup                                 *
+ *****************************************************************************
+ *
+ * Tool stack creates front and back nodes with state XenbusStateInitialising.
+ *
+ * Front                                Back
+ * =================================    =====================================
+ * XenbusStateInitialising              XenbusStateInitialising
+ *  o Query virtual device               o Query backend device identification
+ *    properties.                          data.
+ *  o Setup OS device instance.          o Open and validate backend device.
+ *                                       o Publish backend features.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateInitWait
+ *
+ * o Query backend features.
+ * o Allocate and initialize the
+ *   request ring.
+ *              |
+ *              |
+ *              V
+ * XenbusStateInitialised
+ *
+ *                                       o Connect to the request ring and
+ *                                         event channel.
+ *                                       o Publish backend device properties.
+ *                                                      |
+ *                                                      |
+ *                                                      V
+ *                                      XenbusStateConnected
+ *
+ *  o Query backend device properties.
+ *  o Finalize OS virtual device
+ *    instance.
+ *              |
+ *              |
+ *              V
+ * XenbusStateConnected
+ *
+ * Note: Drivers that do not support any optional features can skip certain
+ *       states in the state machine:
+ *
+ *       o A frontend may transition to XenbusStateInitialised without
+ *         waiting for the backend to enter XenbusStateInitWait.
+ *
+ *       o A backend may transition to XenbusStateInitialised, bypassing
+ *         XenbusStateInitWait, without waiting for the frontend to first
+ *         enter the XenbusStateInitialised state.
+ *
+ *       Drivers that support optional features must tolerate these additional
+ *       state transition paths.  In general this means performing the work of
+ *       any skipped state transition, if it has not already been performed,
+ *       in addition to the work associated with entry into the current state.
+ */
+
+/*
  * REQUEST CODES.
  */
 #define BLKIF_OP_READ              0
 #define BLKIF_OP_WRITE             1
 /*
- * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature-barrier" node contains a boolean indicating whether barrier
- * requests are likely to succeed or fail. Either way, a barrier request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt barrier requests.
- * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not*
- * create the "feature-barrier" node!
+ * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER
+ * operation code ("barrier request") must be completed prior to the
+ * execution of the barrier request.  All writes issued after the barrier
+ * request must not execute until after the completion of the barrier request.
+ *
+ * Optional.  See "feature-barrier" XenBus node documentation above.
  */
 #define BLKIF_OP_WRITE_BARRIER     2
 /*
- * Recognised if "feature-flush-cache" is present in backend xenbus
- * info.  A flush will ask the underlying storage hardware to flush its
- * non-volatile caches as appropriate.  The "feature-flush-cache" node
- * contains a boolean indicating whether flush requests are likely to
- * succeed or fail. Either way, a flush request may fail at any time
- * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
- * block-device hardware. The boolean simply indicates whether or not it
- * is worthwhile for the frontend to attempt flushes.  If a backend does
- * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
- * "feature-flush-cache" node!
+ * Commit any uncommitted contents of the backing device's volatile cache
+ * to stable storage.
+ *
+ * Optional.  See "feature-flush-cache" XenBus node documentation above.
  */
 #define BLKIF_OP_FLUSH_DISKCACHE   3
 /*
@@ -82,47 +304,24 @@
  */
 #define BLKIF_OP_RESERVED_1        4
 /*
- * Recognised only if "feature-discard" is present in backend xenbus info.
- * The "feature-discard" node contains a boolean indicating whether trim
- * (ATA) or unmap (SCSI) - conviently called discard requests are likely
- * to succeed or fail. Either way, a discard request
- * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
- * the underlying block-device hardware. The boolean simply indicates whether
- * or not it is worthwhile for the frontend to attempt discard requests.
- * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
- * create the "feature-discard" node!
+ * Indicate to the backend device that a region of storage is no longer in
+ * use, and may be discarded at any time without impact to the client.  If
+ * the BLKIF_DISCARD_SECURE flag is set on the request, all copies of the
+ * discarded region on the device must be rendered unrecoverable before the
+ * command returns.
  *
- * Discard operation is a request for the underlying block device to mark
- * extents to be erased. However, discard does not guarantee that the blocks
- * will be erased from the device - it is just a hint to the device
- * controller that these blocks are no longer in use. What the device
- * controller does with that information is left to the controller.
- * Discard operations are passed with sector_number as the
- * sector index to begin discard operations at and nr_sectors as the number of
- * sectors to be discarded. The specified sectors should be discarded if the
- * underlying block device supports trim (ATA) or unmap (SCSI) operations,
- * or a BLKIF_RSP_EOPNOTSUPP  should be returned.
- * More information about trim/unmap operations at:
+ * This operation is analogous to performing a trim (ATA), or unmap (SCSI)
+ * command on a physical device.
+ *
+ * More information about trim/unmap operations can be found at:
  * http://t13.org/Documents/UploadedDocuments/docs2008/
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
- * The backend can optionally provide these extra XenBus attributes to
- * further optimize the discard functionality:
- * 'discard-aligment' - Devices that support discard functionality may
- * internally allocate space in units that are bigger than the exported
- * logical block size. The discard-alignment parameter indicates how many bytes
- * the beginning of the partition is offset from the internal allocation unit's
- * natural alignment. Do not confuse this with natural disk alignment offset.
- * 'discard-granularity'  - Devices that support discard functionality may
- * internally allocate space using units that are bigger than the logical block
- * size. The discard-granularity parameter indicates the size of the internal
- * allocation unit in bytes if reported by the device. Otherwise the
- * discard-granularity will be set to match the device's physical block size.
- * It is the minimum size you can discard.
- * 'discard-secure' - All copies of the discarded sectors (potentially created
- * by garbage collection) must also be erased.  To use this feature, the flag
- * BLKIF_DISCARD_SECURE must be set in the blkif_request_discard.
+ *
+ * Optional.  See "feature-discard", "discard-alignment",
+ * "discard-granularity", and "discard-secure" in the XenBus node
+ * documentation above.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -147,6 +346,9 @@ struct blkif_request_segment {
     uint8_t     first_sect, last_sect;
 };
 
+/*
+ * Starting ring element for any I/O request.
+ */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
     uint8_t        nr_segments;  /* number of segments                   */
@@ -158,7 +360,7 @@ struct blkif_request {
 typedef struct blkif_request blkif_request_t;
 
 /*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
 struct blkif_request_discard {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uKX-0000dP-Ra; Mon, 27 Feb 2012 06:45:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKV-0000cS-Vb
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:04 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16593 invoked from network); 27 Feb 2012 06:44:57 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:57 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCb085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 4ea2c09af16c91aa8fa66f98daadff56ae9d6f96
Message-Id: <4ea2c09af16c91aa8fa6.1330324038@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:18 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0896 (UTC)
	FILETIME=[4FD19880:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 4 v4] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
      this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r f725780a51e3 -r 4ea2c09af16c xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:27 2012 -0700
@@ -145,6 +145,32 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests supported by
+ *      the backend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-alignment
@@ -242,6 +268,33 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the frontend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -403,11 +456,28 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00040201
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
+#else
+/*
+ * Maximum scatter/gather segments per request (header block only).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#endif
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -422,9 +492,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -432,11 +518,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
diff -r f725780a51e3 -r 4ea2c09af16c xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/xen-compat.h	Sun Feb 26 23:24:27 2012 -0700
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:45:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uKX-0000dP-Ra; Mon, 27 Feb 2012 06:45:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKV-0000cS-Vb
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:04 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!5
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16593 invoked from network); 27 Feb 2012 06:44:57 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:57 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCb085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 4ea2c09af16c91aa8fa66f98daadff56ae9d6f96
Message-Id: <4ea2c09af16c91aa8fa6.1330324038@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:18 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0896 (UTC)
	FILETIME=[4FD19880:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 4 of 4 v4] blkif.h: Define and document the
 request number/size/segments extension
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
      BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be updated
      to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
      recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
      this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r f725780a51e3 -r 4ea2c09af16c xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:27 2012 -0700
@@ -145,6 +145,32 @@
  *      The maximum supported size of the request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests supported by
+ *      the backend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST
+ *
+ *      The maximum value of blkif_request.nr_segments supported by
+ *      the backend.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by a
+ *      request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-alignment
@@ -242,6 +268,33 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * max-requests
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
+ *      Maximum Value:  BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
+ *
+ *      The maximum number of concurrent, logical requests that will be
+ *      issued by the frontend.
+ *
+ *      Note: A logical request may span multiple ring entries.
+ *
+ * max-request-segments
+ *      Values:         <uint8_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+ *      Maximum Value:  MIN(255, backend/max-request-segments)
+ *
+ *      The maximum value the frontend will set in the
+ *      blkif_request.nr_segments field.
+ *
+ * max-request-size
+ *      Values:         <uint32_t>
+ *      Default Value:  BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
+ *      Maximum Value:  max-request-segments * PAGE_SIZE
+ *
+ *      The maximum amount of data, in bytes, that can be referenced by
+ *      a request type that accesses frontend memory (currently BLKIF_OP_READ,
+ *      BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -403,11 +456,28 @@
 #define BLKIF_OP_DISCARD           5
 
 /*
- * Maximum scatter/gather segments per request.
+ * Maximum scatter/gather segments associated with a request header block.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
  */
-#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK  11
+
+/*
+ * Maximum scatter/gather segments associated with a segment block.
+ */
+#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00040201
+/*
+ * Maximum scatter/gather segments per request (header + segment blocks).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
+#else
+/*
+ * Maximum scatter/gather segments per request (header block only).
+ */
+#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#endif
 
 /*
  * NB. first_sect and last_sect in blkif_request_segment, as well as
@@ -422,9 +492,25 @@ struct blkif_request_segment {
     /* @last_sect: last sector in frame to transfer (inclusive).     */
     uint8_t     first_sect, last_sect;
 };
+typedef struct blkif_request_segment blkif_request_segment_t;
 
 /*
  * Starting ring element for any I/O request.
+ *
+ * One or more segment blocks can be inserted into the request ring
+ * just after a blkif_request_t, allowing requests to operate on
+ * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
+ *
+ * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
+ * to determine the number of contiguous ring entries associated
+ * with this request.
+ *
+ * Note:  Due to the way Xen request rings operate, the producer and
+ *        consumer indices of the ring must be incremented by the
+ *        BLKIF_SEGS_TO_BLOCKS() value of the associated request.
+ *        (e.g. a response to a 3 ring entry request must also consume
+ *        3 entries in the ring, even though only the first ring entry
+ *        in the response has any data.)
  */
 struct blkif_request {
     uint8_t        operation;    /* BLKIF_OP_???                         */
@@ -432,11 +518,22 @@ struct blkif_request {
     blkif_vdev_t   handle;       /* only for read/write requests         */
     uint64_t       id;           /* private guest value, echoed in resp  */
     blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-    struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 typedef struct blkif_request blkif_request_t;
 
 /*
+ * A segment block is a ring request structure that contains only
+ * segment data.
+ *
+ * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
+ */
+struct blkif_segment_block {
+    blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
+};
+typedef struct blkif_segment_block blkif_segment_block_t;
+
+/*
  * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
  * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
  */
@@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
  */
 DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
 
+/*
+ * Index to, and treat as a segment block, an entry in the ring.
+ */
+#define BLKRING_GET_SEG_BLOCK(_r, _idx)                                 \
+    (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
+
+/*
+ * The number of ring request blocks required to handle an I/O
+ * request containing _segs segments.
+ */
+#define BLKIF_SEGS_TO_BLOCKS(_segs)                                     \
+    ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)                    \
+     + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1))                      \
+    / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
+
 #define VDISK_CDROM        0x1
 #define VDISK_REMOVABLE    0x2
 #define VDISK_READONLY     0x4
diff -r f725780a51e3 -r 4ea2c09af16c xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/xen-compat.h	Sun Feb 26 23:24:27 2012 -0700
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06: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 1S1uKW-0000d3-3R; Mon, 27 Feb 2012 06:45:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKU-0000cQ-Kz
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:02 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16553 invoked from network); 27 Feb 2012 06:44:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCa085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: f725780a51e37e321c1ebe90c16c23e419e6f28f
Message-Id: <f725780a51e37e321c1e.1330324037@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:17 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0880 (UTC)
	FILETIME=[4FCF2780:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 4 v4] blkif.h: Document the Red Hat and
 Citrix blkif multi-page ring 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

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 162cce84d405 -r f725780a51e3 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
@@ -67,6 +67,9 @@
  * XenStore nodes in sections marked "PRIVATE" are solely for use by the
  * driver side whose XenBus tree contains them.
  *
+ * XenStore nodes marked "DEPRECATED" in their notes section should only be
+ * used to provide interoperability with legacy implementations.
+ *
  * See the XenBus state transition diagram below for details on when XenBus
  * nodes must be published and when they can be queried.
  *
@@ -123,12 +126,31 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-alignment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -136,7 +158,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -180,10 +202,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "number of ring pages"
+ *      sized list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -191,6 +223,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * num-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -208,12 +259,26 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some Red Hat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and Red Hat/Amazon.
+ *     For full interoperability, block front and backends should publish
+ *     identical ring parameters, adjusted for unit differences, to the
+ *     XenStore nodes used in both schemes.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -231,20 +296,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -261,20 +332,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06: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 1S1uKW-0000d3-3R; Mon, 27 Feb 2012 06:45:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKU-0000cQ-Kz
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:02 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!3
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16553 invoked from network); 27 Feb 2012 06:44:56 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:56 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCa085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: f725780a51e37e321c1ebe90c16c23e419e6f28f
Message-Id: <f725780a51e37e321c1e.1330324037@ns1.eng.sldomain.com>
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
References: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:17 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0880 (UTC)
	FILETIME=[4FCF2780:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 3 of 4 v4] blkif.h: Document the Red Hat and
 Citrix blkif multi-page ring 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

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r 162cce84d405 -r f725780a51e3 xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
+++ b/xen/include/public/io/blkif.h	Sun Feb 26 23:24:01 2012 -0700
@@ -67,6 +67,9 @@
  * XenStore nodes in sections marked "PRIVATE" are solely for use by the
  * driver side whose XenBus tree contains them.
  *
+ * XenStore nodes marked "DEPRECATED" in their notes section should only be
+ * used to provide interoperability with legacy implementations.
+ *
  * See the XenBus state transition diagram below for details on when XenBus
  * nodes must be published and when they can be queried.
  *
@@ -123,12 +126,31 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ *----------------------- Request Transport Parameters ------------------------
+ *
+ * max-ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Notes:          1, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      lb(machine pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * max-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The maximum supported size of the request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Backend Device Properties -------------------------
  *
  * discard-alignment
  *      Values:         <uint32_t>
  *      Default Value:  0
- *      Notes:          1, 2
+ *      Notes:          4, 5
  *
  *      The offset, in bytes from the beginning of the virtual block device,
  *      to the first, addressable, discard extent on the underlying device.
@@ -136,7 +158,7 @@
  * discard-granularity
  *      Values:         <uint32_t>
  *      Default Value:  <"sector-size">
- *      Notes:          1
+ *      Notes:          4
  *
  *      The size, in bytes, of the individually addressable discard extents
  *      of the underlying device.
@@ -180,10 +202,20 @@
  *
  * ring-ref
  *      Values:         <uint32_t>
+ *      Notes:          6
  *
  *      The Xen grant reference granting permission for the backend to map
  *      the sole page in a single page sized ring buffer.
  *
+ * ring-ref%u
+ *      Values:         <uint32_t>
+ *      Notes:          6
+ *
+ *      For a frontend providing a multi-page ring, a "number of ring pages"
+ *      sized list of nodes, each containing a Xen grant reference granting
+ *      permission for the backend to map the page of the ring located
+ *      at page index "%u".  Page indexes are zero based.
+ *
  * protocol
  *      Values:         string (XEN_IO_PROTO_ABI_*)
  *      Default Value:  XEN_IO_PROTO_ABI_NATIVE
@@ -191,6 +223,25 @@
  *      The machine ABI rules governing the format of all ring request and
  *      response structures.
  *
+ * ring-page-order
+ *      Values:         <uint32_t>
+ *      Default Value:  0
+ *      Maximum Value:  MAX(ffs(max-ring-pages) - 1, max-ring-page-order)
+ *      Notes:          1, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units
+ *      of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages,
+ *      etc.).
+ *
+ * num-ring-pages
+ *      Values:         <uint32_t>
+ *      Default Value:  1
+ *      Maximum Value:  MAX(max-ring-pages,(0x1 << max-ring-page-order))
+ *      Notes:          DEPRECATED, 2, 3
+ *
+ *      The size of the frontend allocated request ring buffer in units of
+ *      machine pages.  The value must be a power of 2.
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -208,12 +259,26 @@
  *
  * Notes
  * -----
- * (1) Devices that support discard functionality may internally allocate
+ * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
+ *     PV drivers.
+ * (2) Multi-page ring buffer scheme first used in some Red Hat distributions
+ *     including a distribution deployed on certain nodes of the Amazon
+ *     EC2 cluster.
+ * (3) Support for multi-page ring buffers was implemented independently,
+ *     in slightly different forms, by both Citrix and Red Hat/Amazon.
+ *     For full interoperability, block front and backends should publish
+ *     identical ring parameters, adjusted for unit differences, to the
+ *     XenStore nodes used in both schemes.
+ * (4) Devices that support discard functionality may internally allocate
  *     space (discardable extents) in units that are larger than the
  *     exported logical block size.
- * (2) The discard-alignment parameter allows a physical device to be
+ * (5) The discard-alignment parameter allows a physical device to be
  *     partitioned into virtual devices that do not necessarily begin or
  *     end on a discardable extent boundary.
+ * (6) When there is only a single page allocated to the request ring,
+ *     'ring-ref' is used to communicate the grant reference for this
+ *     page to the backend.  When using a multi-page ring, the 'ring-ref'
+ *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
  */
 
 /*
@@ -231,20 +296,26 @@
  *  o Query virtual device               o Query backend device identification
  *    properties.                          data.
  *  o Setup OS device instance.          o Open and validate backend device.
- *                                       o Publish backend features.
+ *                                       o Publish backend features and
+ *                                         transport parameters.
  *                                                      |
  *                                                      |
  *                                                      V
  *                                      XenbusStateInitWait
  *
- * o Query backend features.
+ * o Query backend features and
+ *   transport parameters.
  * o Allocate and initialize the
  *   request ring.
+ * o Publish transport parameters
+ *   that will be in effect during
+ *   this connection.
  *              |
  *              |
  *              V
  * XenbusStateInitialised
  *
+ *                                       o Query frontend transport parameters.
  *                                       o Connect to the request ring and
  *                                         event channel.
  *                                       o Publish backend device properties.
@@ -261,20 +332,26 @@
  *              V
  * XenbusStateConnected
  *
- * Note: Drivers that do not support any optional features can skip certain
- *       states in the state machine:
+ * Note: Drivers that do not support any optional features, or the negotiation
+ *       of transport parameters, can skip certain states in the state machine:
  *
  *       o A frontend may transition to XenbusStateInitialised without
- *         waiting for the backend to enter XenbusStateInitWait.
+ *         waiting for the backend to enter XenbusStateInitWait.  In this
+ *         case, default transport parameters are in effect and any
+ *         transport parameters published by the frontend must contain
+ *         their default values.
  *
  *       o A backend may transition to XenbusStateInitialised, bypassing
  *         XenbusStateInitWait, without waiting for the frontend to first
- *         enter the XenbusStateInitialised state.
+ *         enter the XenbusStateInitialised state.  In this case, default
+ *         transport parameters are in effect and any transport parameters
+ *         published by the backend must contain their default values.
  *
- *       Drivers that support optional features must tolerate these additional
- *       state transition paths.  In general this means performing the work of
- *       any skipped state transition, if it has not already been performed,
- *       in addition to the work associated with entry into the current state.
+ *       Drivers that support optional features and/or transport parameter
+ *       negotiation must tolerate these additional state transition paths.
+ *       In general this means performing the work of any skipped state
+ *       transition, if it has not already been performed, in addition to the
+ *       work associated with entry into the current state.
  */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06: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 1S1uKV-0000cf-3q; Mon, 27 Feb 2012 06:45:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKT-0000cO-69
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:01 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16484 invoked from network); 27 Feb 2012 06:44:54 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:54 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCX085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:14 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0833 (UTC)
	FILETIME=[4FC7FB90:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
	existing 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

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.

Changes in v4:

patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
  o Fix typo "discard-aligment" -> "discard-alignment"
  o Fix typo "unamp" -> "unmap"
  o Fix typo "formated" -> "formatted"
  o Clarify the text for "params".
  o Clarify the text for "sector-size".

patch 4 (blkif.h: Define and document the request number/size/segments
        extension.)
  o Insert space in "Red Hat".
  o Clarify the text for "max-requests" in the backend section.

Changes in v3:

patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
        ring extensions.):
 o Mark the Red Hat/Amazon EC2 ring extension nodes as deprecated.  While
   there is nothing fundamentally wrong with the method used there, it
   was not publicly documented (not even in patch form), and differs from
   the "page-order" large ring XenBus node convention used for other
   drivers.

patch 4 (blkif.h: Define and document the request number/size/segments
        extension.)
  o Fix typo "max-ring_pages" -> "max-ring-pages".

Changes in v2:

patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
 o Mark backend device identification section as private to the
   backend driver.
 o Refer to docs/misc/vbd-interface.txt for the format of the
   virtual-device front-end node.
 o Correct field size for the virtual-device front-end node.

patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
        ring extensions.):
 o Correct node names for the Red Hat/Amazon multi-ring extension.  The
   previous patch mistakenly documented the now defunct FreeBSD extension.
 o Clarify the note on multi-page ring interoperability to indicate that
   identical ring parameters should be published to the XenStore for
   all supported schemes.

v1 patch 4 (Deleted):
 o Remove patch that added the XEN_*_MAJOR definitions.

patch 4 (blkif.h: Define and document the request number/size/segments
        extension.)
 o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
   to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06: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 1S1uKV-0000cf-3q; Mon, 27 Feb 2012 06:45:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S1uKT-0000cO-69
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:45:01 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330325094!16566579!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16484 invoked from network); 27 Feb 2012 06:44:54 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-9.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 06:44:54 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 26 Feb 2012 23:44:53 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1R6irCX085248;
	Sun, 26 Feb 2012 23:44:53 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
Message-Id: <patchbomb.1330324034@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Sun, 26 Feb 2012 23:27:14 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 27 Feb 2012 06:44:53.0833 (UTC)
	FILETIME=[4FC7FB90:01CCF51B]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
	existing 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

This patch series attempts to document the blkif PV interface and
the various extensions to it that are out in the wild.

Changes in v4:

patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
  o Fix typo "discard-aligment" -> "discard-alignment"
  o Fix typo "unamp" -> "unmap"
  o Fix typo "formated" -> "formatted"
  o Clarify the text for "params".
  o Clarify the text for "sector-size".

patch 4 (blkif.h: Define and document the request number/size/segments
        extension.)
  o Insert space in "Red Hat".
  o Clarify the text for "max-requests" in the backend section.

Changes in v3:

patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
        ring extensions.):
 o Mark the Red Hat/Amazon EC2 ring extension nodes as deprecated.  While
   there is nothing fundamentally wrong with the method used there, it
   was not publicly documented (not even in patch form), and differs from
   the "page-order" large ring XenBus node convention used for other
   drivers.

patch 4 (blkif.h: Define and document the request number/size/segments
        extension.)
  o Fix typo "max-ring_pages" -> "max-ring-pages".

Changes in v2:

patch 2 (blkif.h: Provide more complete documentation of the blkif interface.):
 o Mark backend device identification section as private to the
   backend driver.
 o Refer to docs/misc/vbd-interface.txt for the format of the
   virtual-device front-end node.
 o Correct field size for the virtual-device front-end node.

patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
        ring extensions.):
 o Correct node names for the Red Hat/Amazon multi-ring extension.  The
   previous patch mistakenly documented the now defunct FreeBSD extension.
 o Clarify the note on multi-page ring interoperability to indicate that
   identical ring parameters should be published to the XenStore for
   all supported schemes.

v1 patch 4 (Deleted):
 o Remove patch that added the XEN_*_MAJOR definitions.

patch 4 (blkif.h: Define and document the request number/size/segments
        extension.)
 o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
   to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:51:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:51:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uPs-0001J0-Ts; Mon, 27 Feb 2012 06:50:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S1uPr-0001It-N9
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:50:35 +0000
Received: from [85.158.139.83:26591] by server-10.bemta-5.messagelabs.com id
	F8/A2-06263-AB72B4F4; Mon, 27 Feb 2012 06:50:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330325433!16801121!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2351 invoked from network); 27 Feb 2012 06:50:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 06:50:34 -0000
Received: by wgbdr12 with SMTP id dr12so1333952wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 22:50:33 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.78.6 as permitted sender) client-ip=10.180.78.6; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.78.6 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.78.6])
	by 10.180.78.6 with SMTP id x6mr15513893wiw.18.1330325433547 (num_hops
	= 1); Sun, 26 Feb 2012 22:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oBDfInjPqTSqv32VYNQqyMYdY99P4qte+si8i7LZGkA=;
	b=wghsUMvY7Qs8w8yk9qMR/xpOkzxkVFmdyhwNjtgWebLV7t74OC4fwaPJk04YVoQh1A
	J0mmEnGptMJhF0CfmTn/9Qymrp5iTQ7QBRphs3K79VWdMQ5im7xfr/gVocZitznoF6Gf
	hTRTOkgJ+NMMHkX6vRl4EHQW0HP8lnszSMkIo=
Received: by 10.180.78.6 with SMTP id x6mr12244409wiw.18.1330325433402;
	Sun, 26 Feb 2012 22:50:33 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id s2sm50794672wix.3.2012.02.26.22.50.30
	(version=SSLv3 cipher=OTHER); Sun, 26 Feb 2012 22:50:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 06:50:29 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB70D835.2C505%keir.xen@gmail.com>
Thread-Topic: [PATCH 0 of 4 v4] blkif.h: Document protocol and existing
	extensions
Thread-Index: Acz1HBeO2lzspvGiEEC5JcqWg8WMdg==
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
 existing 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 27/02/2012 06:27, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.

The previous round of these patches was already applied. They are sitting in
the staging tree currently (http://xenbits.xen.org/staging/xen-unstable.hg).

 -- Keir

> Changes in v4:
> 
> patch 2 (blkif.h: Provide more complete documentation of the blkif
> interface.):
>   o Fix typo "discard-aligment" -> "discard-alignment"
>   o Fix typo "unamp" -> "unmap"
>   o Fix typo "formated" -> "formatted"
>   o Clarify the text for "params".
>   o Clarify the text for "sector-size".
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>         extension.)
>   o Insert space in "Red Hat".
>   o Clarify the text for "max-requests" in the backend section.
> 
> Changes in v3:
> 
> patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
>         ring extensions.):
>  o Mark the Red Hat/Amazon EC2 ring extension nodes as deprecated.  While
>    there is nothing fundamentally wrong with the method used there, it
>    was not publicly documented (not even in patch form), and differs from
>    the "page-order" large ring XenBus node convention used for other
>    drivers.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>         extension.)
>   o Fix typo "max-ring_pages" -> "max-ring-pages".
> 
> Changes in v2:
> 
> patch 2 (blkif.h: Provide more complete documentation of the blkif
> interface.):
>  o Mark backend device identification section as private to the
>    backend driver.
>  o Refer to docs/misc/vbd-interface.txt for the format of the
>    virtual-device front-end node.
>  o Correct field size for the virtual-device front-end node.
> 
> patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
>         ring extensions.):
>  o Correct node names for the Red Hat/Amazon multi-ring extension.  The
>    previous patch mistakenly documented the now defunct FreeBSD extension.
>  o Clarify the note on multi-page ring interoperability to indicate that
>    identical ring parameters should be published to the XenStore for
>    all supported schemes.
> 
> v1 patch 4 (Deleted):
>  o Remove patch that added the XEN_*_MAJOR definitions.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>         extension.)
>  o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
>    to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> 
> --
> Justin
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 06:51:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 06:51:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1uPs-0001J0-Ts; Mon, 27 Feb 2012 06:50:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S1uPr-0001It-N9
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 06:50:35 +0000
Received: from [85.158.139.83:26591] by server-10.bemta-5.messagelabs.com id
	F8/A2-06263-AB72B4F4; Mon, 27 Feb 2012 06:50:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330325433!16801121!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2351 invoked from network); 27 Feb 2012 06:50:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 06:50:34 -0000
Received: by wgbdr12 with SMTP id dr12so1333952wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 26 Feb 2012 22:50:33 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.78.6 as permitted sender) client-ip=10.180.78.6; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.78.6 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.78.6])
	by 10.180.78.6 with SMTP id x6mr15513893wiw.18.1330325433547 (num_hops
	= 1); Sun, 26 Feb 2012 22:50:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oBDfInjPqTSqv32VYNQqyMYdY99P4qte+si8i7LZGkA=;
	b=wghsUMvY7Qs8w8yk9qMR/xpOkzxkVFmdyhwNjtgWebLV7t74OC4fwaPJk04YVoQh1A
	J0mmEnGptMJhF0CfmTn/9Qymrp5iTQ7QBRphs3K79VWdMQ5im7xfr/gVocZitznoF6Gf
	hTRTOkgJ+NMMHkX6vRl4EHQW0HP8lnszSMkIo=
Received: by 10.180.78.6 with SMTP id x6mr12244409wiw.18.1330325433402;
	Sun, 26 Feb 2012 22:50:33 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id s2sm50794672wix.3.2012.02.26.22.50.30
	(version=SSLv3 cipher=OTHER); Sun, 26 Feb 2012 22:50:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 06:50:29 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB70D835.2C505%keir.xen@gmail.com>
Thread-Topic: [PATCH 0 of 4 v4] blkif.h: Document protocol and existing
	extensions
Thread-Index: Acz1HBeO2lzspvGiEEC5JcqWg8WMdg==
In-Reply-To: <patchbomb.1330324034@ns1.eng.sldomain.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
 existing 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 27/02/2012 06:27, "Justin T. Gibbs" <justing@spectralogic.com> wrote:

> This patch series attempts to document the blkif PV interface and
> the various extensions to it that are out in the wild.

The previous round of these patches was already applied. They are sitting in
the staging tree currently (http://xenbits.xen.org/staging/xen-unstable.hg).

 -- Keir

> Changes in v4:
> 
> patch 2 (blkif.h: Provide more complete documentation of the blkif
> interface.):
>   o Fix typo "discard-aligment" -> "discard-alignment"
>   o Fix typo "unamp" -> "unmap"
>   o Fix typo "formated" -> "formatted"
>   o Clarify the text for "params".
>   o Clarify the text for "sector-size".
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>         extension.)
>   o Insert space in "Red Hat".
>   o Clarify the text for "max-requests" in the backend section.
> 
> Changes in v3:
> 
> patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
>         ring extensions.):
>  o Mark the Red Hat/Amazon EC2 ring extension nodes as deprecated.  While
>    there is nothing fundamentally wrong with the method used there, it
>    was not publicly documented (not even in patch form), and differs from
>    the "page-order" large ring XenBus node convention used for other
>    drivers.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>         extension.)
>   o Fix typo "max-ring_pages" -> "max-ring-pages".
> 
> Changes in v2:
> 
> patch 2 (blkif.h: Provide more complete documentation of the blkif
> interface.):
>  o Mark backend device identification section as private to the
>    backend driver.
>  o Refer to docs/misc/vbd-interface.txt for the format of the
>    virtual-device front-end node.
>  o Correct field size for the virtual-device front-end node.
> 
> patch 3 (blkif.h: Document the Red Hat and Citrix blkif multi-page
>         ring extensions.):
>  o Correct node names for the Red Hat/Amazon multi-ring extension.  The
>    previous patch mistakenly documented the now defunct FreeBSD extension.
>  o Clarify the note on multi-page ring interoperability to indicate that
>    identical ring parameters should be published to the XenStore for
>    all supported schemes.
> 
> v1 patch 4 (Deleted):
>  o Remove patch that added the XEN_*_MAJOR definitions.
> 
> patch 4 (blkif.h: Define and document the request number/size/segments
>         extension.)
>  o Bump __XEN_LATEST_INTERFACE_VERSION to 0x00040201 and use this version
>    to guard the change to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> 
> --
> Justin
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 08:15:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1vjQ-0002IV-GV; Mon, 27 Feb 2012 08:14:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vjO-0002IN-HP
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:14:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330330483!9890106!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27528 invoked from network); 27 Feb 2012 08:14:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:14:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:14:43 +0000
Message-Id: <4F4B497B0200007800074DE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:14:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
	<4F4775410200007800074992@nat28.tlf.novell.com>
	<20120224235228.GA26913@phenom.dumpdata.com>
In-Reply-To: <20120224235228.GA26913@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and
 MWAIT_LEAF if hypervisor OKs 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 25.02.12 at 00:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > +DEFINE_GUEST_HANDLE(uint32_t);
>> 
>> Do you really need to introduce (step by step) handles for all those
>> uintNN_t types in a way different from Xen's
>> (__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t))?
> 
> Oh, no. Good eye - I will change it be uint32.

Might be worth converting the recently added counterpart of uint64_t
then 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 Feb 27 08:15:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1vjQ-0002IV-GV; Mon, 27 Feb 2012 08:14:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vjO-0002IN-HP
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:14:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330330483!9890106!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27528 invoked from network); 27 Feb 2012 08:14:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:14:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:14:43 +0000
Message-Id: <4F4B497B0200007800074DE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:14:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<1330036270-20015-3-git-send-email-konrad.wilk@oracle.com>
	<4F4775410200007800074992@nat28.tlf.novell.com>
	<20120224235228.GA26913@phenom.dumpdata.com>
In-Reply-To: <20120224235228.GA26913@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	ke.yu@intel.com, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen/enlighten: Expose MWAIT and
 MWAIT_LEAF if hypervisor OKs 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 25.02.12 at 00:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > +DEFINE_GUEST_HANDLE(uint32_t);
>> 
>> Do you really need to introduce (step by step) handles for all those
>> uintNN_t types in a way different from Xen's
>> (__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t))?
> 
> Oh, no. Good eye - I will change it be uint32.

Might be worth converting the recently added counterpart of uint64_t
then 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 Feb 27 08:20:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1vo1-0002QZ-6N; Mon, 27 Feb 2012 08:19:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vnz-0002QQ-F5
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:19:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330330769!9891025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18398 invoked from network); 27 Feb 2012 08:19:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:19:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:19:28 +0000
Message-Id: <4F4B4A9C0200007800074DE4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:19:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<4F47733E020000780007497D@nat28.tlf.novell.com>
	<20120225002136.GB26913@phenom.dumpdata.com>
In-Reply-To: <20120225002136.GB26913@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
	linux-acpi@vger.kernel.org, ke.yu@intel.com, davej@redhat.com,
	lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 25.02.12 at 01:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> But cpufreq != cpuidle != cpufreq governor, and they all are run by 
> different rules.
> The ondemand cpufreq governor for example runs a timer and calls the 
> appropiate cpufreq
> driver. So with these patches I posted we end up with a cpufreq driver in 
> the kernel
> and in Xen hypervisor - both of them trying to change Pstates. Not good (to 
> be fair,
> if powernow-k8/acpi-cpufreq would try it via WRMSR -  those would up being 
> trapped and
> ignored by the hypervisor. I am not sure about the outw though).

I'm not aware of any trapping that would be done on the I/O port here;
it could be added, though (i.e. the ports removed from the list of
allowed ports of Dom0 once they become known to the hypervisor).

> The pre-RFC version of this posted driver implemented a cpufreq governor that 
> was
> nop and for future work was going to make a hypercall to get the true 
> cpufreq value
> to report properly in /proc/cpuinfo - but I hadn't figured out a way to make 
> it be
> the default one dynamically.
> 
> Perhaps having xencommons do 
> echo "xen" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
> 
> And s/processor-passthru/cpufreq-xen/ would do it? That would eliminate the 
> [performance,
> ondemand,powersave,etc] cpufreq governors from calling into the cpufreq 
> drivers to alter P-states.

Except that you want this to be a cpufreq driver, not a governor.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 08:20:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1vo1-0002QZ-6N; Mon, 27 Feb 2012 08:19:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vnz-0002QQ-F5
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:19:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330330769!9891025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18398 invoked from network); 27 Feb 2012 08:19:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:19:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:19:28 +0000
Message-Id: <4F4B4A9C0200007800074DE4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:19:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1330036270-20015-1-git-send-email-konrad.wilk@oracle.com>
	<4F47733E020000780007497D@nat28.tlf.novell.com>
	<20120225002136.GB26913@phenom.dumpdata.com>
In-Reply-To: <20120225002136.GB26913@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
	linux-acpi@vger.kernel.org, ke.yu@intel.com, davej@redhat.com,
	lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] processor passthru - upload _Cx and _Pxx
 data to hypervisor (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 25.02.12 at 01:21, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> But cpufreq != cpuidle != cpufreq governor, and they all are run by 
> different rules.
> The ondemand cpufreq governor for example runs a timer and calls the 
> appropiate cpufreq
> driver. So with these patches I posted we end up with a cpufreq driver in 
> the kernel
> and in Xen hypervisor - both of them trying to change Pstates. Not good (to 
> be fair,
> if powernow-k8/acpi-cpufreq would try it via WRMSR -  those would up being 
> trapped and
> ignored by the hypervisor. I am not sure about the outw though).

I'm not aware of any trapping that would be done on the I/O port here;
it could be added, though (i.e. the ports removed from the list of
allowed ports of Dom0 once they become known to the hypervisor).

> The pre-RFC version of this posted driver implemented a cpufreq governor that 
> was
> nop and for future work was going to make a hypercall to get the true 
> cpufreq value
> to report properly in /proc/cpuinfo - but I hadn't figured out a way to make 
> it be
> the default one dynamically.
> 
> Perhaps having xencommons do 
> echo "xen" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
> 
> And s/processor-passthru/cpufreq-xen/ would do it? That would eliminate the 
> [performance,
> ondemand,powersave,etc] cpufreq governors from calling into the cpufreq 
> drivers to alter P-states.

Except that you want this to be a cpufreq driver, not a governor.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 08:28:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1vwH-0002bq-5z; Mon, 27 Feb 2012 08:28:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vwF-0002bl-Rk
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 08:28:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330331281!9892603!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17739 invoked from network); 27 Feb 2012 08:28:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:28:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:28:01 +0000
Message-Id: <4F4B4C9D0200007800074E09@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:27:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
	<20120226160230.GA2274@phenom.dumpdata.com>
In-Reply-To: <20120226160230.GA2274@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCFE1C69D.1__="
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: constify all instances of "struct
 attribute_group"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartCFE1C69D.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 26.02.12 at 17:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> =
wrote:
> On Fri, Feb 24, 2012 at 11:47:57AM +0000, Jan Beulich wrote:
>> The functions these get passed to have been taking pointers to const
>> since at least 2.6.16.
>=20
> What is this based on? I get:

Plain 3.3-rc4.

> HEAD is now at b01543d... Linux 3.3-rc4
> konrad@phenom:~/ssd/linux$ patch -p1 < /tmp/jan-1
> patching file drivers/xen/sys-hypervisor.c
> Hunk #1 FAILED at 97.
> Hunk #2 FAILED at 210.
> Hunk #3 FAILED at 340.
> 3 out of 3 hunks FAILED -- saving rejects to file=20
> drivers/xen/sys-hypervisor.c.rej
> patching file drivers/xen/xen-balloon.c
> Hunk #1 FAILED at 207.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/xen/xen-balloon.=
c.rej
> patching file drivers/xen/xen-selfballoon.c
> Hunk #1 FAILED at 488.
> 1 out of 1 hunk FAILED -- saving rejects to file=20
> drivers/xen/xen-selfballoon.c.rej

Is /tmp/jan-1 perhaps suffering whitespace corruption (which would
have happened at your end, as I can take the tail of your response,
remove the reply quotation, and apply it successfully), even though
I don't think we had problems of this kind in the past? I'll attach the
patch here, just in case.

Jan

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>=20
>> ---
>>  drivers/xen/sys-hypervisor.c  |    6 +++---
>>  drivers/xen/xen-balloon.c     |    2 +-
>>  drivers/xen/xen-selfballoon.c |    2 +-
>>  3 files changed, 5 insertions(+), 5 deletions(-)
>>=20
>> --- 3.3-rc4/drivers/xen/sys-hypervisor.c
>> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c
>> @@ -97,7 +97,7 @@ static struct attribute *version_attrs[]
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group version_group =3D {
>> +static const struct attribute_group version_group =3D {
>>  	.name =3D "version",
>>  	.attrs =3D version_attrs,
>>  };
>> @@ -210,7 +210,7 @@ static struct attribute *xen_compile_att
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group xen_compilation_group =3D {
>> +static const struct attribute_group xen_compilation_group =3D {
>>  	.name =3D "compilation",
>>  	.attrs =3D xen_compile_attrs,
>>  };
>> @@ -340,7 +340,7 @@ static struct attribute *xen_properties_
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group xen_properties_group =3D {
>> +static const struct attribute_group xen_properties_group =3D {
>>  	.name =3D "properties",
>>  	.attrs =3D xen_properties_attrs,
>>  };
>> --- 3.3-rc4/drivers/xen/xen-balloon.c
>> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon.c
>> @@ -207,7 +207,7 @@ static struct attribute *balloon_info_at
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group balloon_info_group =3D {
>> +static const struct attribute_group balloon_info_group =3D {
>>  	.name =3D "info",
>>  	.attrs =3D balloon_info_attrs
>>  };
>> --- 3.3-rc4/drivers/xen/xen-selfballoon.c
>> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-selfballoon.c
>> @@ -488,7 +488,7 @@ static struct attribute *selfballoon_att
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group selfballoon_group =3D {
>> +static const struct attribute_group selfballoon_group =3D {
>>  	.name =3D "selfballoon",
>>  	.attrs =3D selfballoon_attrs
>>  };
>>=20
>>=20




--=__PartCFE1C69D.1__=
Content-Type: text/plain; name="linux-3.3-rc4-xen-const-attribute_group.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.3-rc4-xen-const-attribute_group.patch"

xen: constify all instances of "struct attribute_group"=0A=0AThe functions =
these get passed to have been taking pointers to const=0Asince at least =
2.6.16.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A---=0A =
drivers/xen/sys-hypervisor.c  |    6 +++---=0A drivers/xen/xen-balloon.c   =
  |    2 +-=0A drivers/xen/xen-selfballoon.c |    2 +-=0A 3 files changed, =
5 insertions(+), 5 deletions(-)=0A=0A--- 3.3-rc4/drivers/xen/sys-hypervisor=
.c=0A+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c=0A@=
@ -97,7 +97,7 @@ static struct attribute *version_attrs[]=0A 	NULL=0A =
};=0A =0A-static struct attribute_group version_group =3D {=0A+static =
const struct attribute_group version_group =3D {=0A 	.name =3D =
"version",=0A 	.attrs =3D version_attrs,=0A };=0A@@ -210,7 +210,7 @@ =
static struct attribute *xen_compile_att=0A 	NULL=0A };=0A =0A-static =
struct attribute_group xen_compilation_group =3D {=0A+static const struct =
attribute_group xen_compilation_group =3D {=0A 	.name =3D "compilation",=0A=
 	.attrs =3D xen_compile_attrs,=0A };=0A@@ -340,7 +340,7 @@ static =
struct attribute *xen_properties_=0A 	NULL=0A };=0A =0A-static struct =
attribute_group xen_properties_group =3D {=0A+static const struct =
attribute_group xen_properties_group =3D {=0A 	.name =3D "properties",=0A =
	.attrs =3D xen_properties_attrs,=0A };=0A--- 3.3-rc4/drivers/xen/xe=
n-balloon.c=0A+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon=
.c=0A@@ -207,7 +207,7 @@ static struct attribute *balloon_info_at=0A 	=
NULL=0A };=0A =0A-static struct attribute_group balloon_info_group =3D =
{=0A+static const struct attribute_group balloon_info_group =3D {=0A 	=
.name =3D "info",=0A 	.attrs =3D balloon_info_attrs=0A };=0A--- =
3.3-rc4/drivers/xen/xen-selfballoon.c=0A+++ 3.3-rc4-xen-const-attribute_gro=
up/drivers/xen/xen-selfballoon.c=0A@@ -488,7 +488,7 @@ static struct =
attribute *selfballoon_att=0A 	NULL=0A };=0A =0A-static struct attribute_g=
roup selfballoon_group =3D {=0A+static const struct attribute_group =
selfballoon_group =3D {=0A 	.name =3D "selfballoon",=0A 	.attrs =3D =
selfballoon_attrs=0A };=0A
--=__PartCFE1C69D.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

--=__PartCFE1C69D.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 27 08:28:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1vwH-0002bq-5z; Mon, 27 Feb 2012 08:28:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vwF-0002bl-Rk
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 08:28:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330331281!9892603!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17739 invoked from network); 27 Feb 2012 08:28:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:28:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:28:01 +0000
Message-Id: <4F4B4C9D0200007800074E09@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:27:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <4F4786FD0200007800074A0C@nat28.tlf.novell.com>
	<20120226160230.GA2274@phenom.dumpdata.com>
In-Reply-To: <20120226160230.GA2274@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCFE1C69D.1__="
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: constify all instances of "struct
 attribute_group"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartCFE1C69D.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 26.02.12 at 17:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> =
wrote:
> On Fri, Feb 24, 2012 at 11:47:57AM +0000, Jan Beulich wrote:
>> The functions these get passed to have been taking pointers to const
>> since at least 2.6.16.
>=20
> What is this based on? I get:

Plain 3.3-rc4.

> HEAD is now at b01543d... Linux 3.3-rc4
> konrad@phenom:~/ssd/linux$ patch -p1 < /tmp/jan-1
> patching file drivers/xen/sys-hypervisor.c
> Hunk #1 FAILED at 97.
> Hunk #2 FAILED at 210.
> Hunk #3 FAILED at 340.
> 3 out of 3 hunks FAILED -- saving rejects to file=20
> drivers/xen/sys-hypervisor.c.rej
> patching file drivers/xen/xen-balloon.c
> Hunk #1 FAILED at 207.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/xen/xen-balloon.=
c.rej
> patching file drivers/xen/xen-selfballoon.c
> Hunk #1 FAILED at 488.
> 1 out of 1 hunk FAILED -- saving rejects to file=20
> drivers/xen/xen-selfballoon.c.rej

Is /tmp/jan-1 perhaps suffering whitespace corruption (which would
have happened at your end, as I can take the tail of your response,
remove the reply quotation, and apply it successfully), even though
I don't think we had problems of this kind in the past? I'll attach the
patch here, just in case.

Jan

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>=20
>> ---
>>  drivers/xen/sys-hypervisor.c  |    6 +++---
>>  drivers/xen/xen-balloon.c     |    2 +-
>>  drivers/xen/xen-selfballoon.c |    2 +-
>>  3 files changed, 5 insertions(+), 5 deletions(-)
>>=20
>> --- 3.3-rc4/drivers/xen/sys-hypervisor.c
>> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c
>> @@ -97,7 +97,7 @@ static struct attribute *version_attrs[]
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group version_group =3D {
>> +static const struct attribute_group version_group =3D {
>>  	.name =3D "version",
>>  	.attrs =3D version_attrs,
>>  };
>> @@ -210,7 +210,7 @@ static struct attribute *xen_compile_att
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group xen_compilation_group =3D {
>> +static const struct attribute_group xen_compilation_group =3D {
>>  	.name =3D "compilation",
>>  	.attrs =3D xen_compile_attrs,
>>  };
>> @@ -340,7 +340,7 @@ static struct attribute *xen_properties_
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group xen_properties_group =3D {
>> +static const struct attribute_group xen_properties_group =3D {
>>  	.name =3D "properties",
>>  	.attrs =3D xen_properties_attrs,
>>  };
>> --- 3.3-rc4/drivers/xen/xen-balloon.c
>> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon.c
>> @@ -207,7 +207,7 @@ static struct attribute *balloon_info_at
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group balloon_info_group =3D {
>> +static const struct attribute_group balloon_info_group =3D {
>>  	.name =3D "info",
>>  	.attrs =3D balloon_info_attrs
>>  };
>> --- 3.3-rc4/drivers/xen/xen-selfballoon.c
>> +++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-selfballoon.c
>> @@ -488,7 +488,7 @@ static struct attribute *selfballoon_att
>>  	NULL
>>  };
>> =20
>> -static struct attribute_group selfballoon_group =3D {
>> +static const struct attribute_group selfballoon_group =3D {
>>  	.name =3D "selfballoon",
>>  	.attrs =3D selfballoon_attrs
>>  };
>>=20
>>=20




--=__PartCFE1C69D.1__=
Content-Type: text/plain; name="linux-3.3-rc4-xen-const-attribute_group.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.3-rc4-xen-const-attribute_group.patch"

xen: constify all instances of "struct attribute_group"=0A=0AThe functions =
these get passed to have been taking pointers to const=0Asince at least =
2.6.16.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A---=0A =
drivers/xen/sys-hypervisor.c  |    6 +++---=0A drivers/xen/xen-balloon.c   =
  |    2 +-=0A drivers/xen/xen-selfballoon.c |    2 +-=0A 3 files changed, =
5 insertions(+), 5 deletions(-)=0A=0A--- 3.3-rc4/drivers/xen/sys-hypervisor=
.c=0A+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/sys-hypervisor.c=0A@=
@ -97,7 +97,7 @@ static struct attribute *version_attrs[]=0A 	NULL=0A =
};=0A =0A-static struct attribute_group version_group =3D {=0A+static =
const struct attribute_group version_group =3D {=0A 	.name =3D =
"version",=0A 	.attrs =3D version_attrs,=0A };=0A@@ -210,7 +210,7 @@ =
static struct attribute *xen_compile_att=0A 	NULL=0A };=0A =0A-static =
struct attribute_group xen_compilation_group =3D {=0A+static const struct =
attribute_group xen_compilation_group =3D {=0A 	.name =3D "compilation",=0A=
 	.attrs =3D xen_compile_attrs,=0A };=0A@@ -340,7 +340,7 @@ static =
struct attribute *xen_properties_=0A 	NULL=0A };=0A =0A-static struct =
attribute_group xen_properties_group =3D {=0A+static const struct =
attribute_group xen_properties_group =3D {=0A 	.name =3D "properties",=0A =
	.attrs =3D xen_properties_attrs,=0A };=0A--- 3.3-rc4/drivers/xen/xe=
n-balloon.c=0A+++ 3.3-rc4-xen-const-attribute_group/drivers/xen/xen-balloon=
.c=0A@@ -207,7 +207,7 @@ static struct attribute *balloon_info_at=0A 	=
NULL=0A };=0A =0A-static struct attribute_group balloon_info_group =3D =
{=0A+static const struct attribute_group balloon_info_group =3D {=0A 	=
.name =3D "info",=0A 	.attrs =3D balloon_info_attrs=0A };=0A--- =
3.3-rc4/drivers/xen/xen-selfballoon.c=0A+++ 3.3-rc4-xen-const-attribute_gro=
up/drivers/xen/xen-selfballoon.c=0A@@ -488,7 +488,7 @@ static struct =
attribute *selfballoon_att=0A 	NULL=0A };=0A =0A-static struct attribute_g=
roup selfballoon_group =3D {=0A+static const struct attribute_group =
selfballoon_group =3D {=0A 	.name =3D "selfballoon",=0A 	.attrs =3D =
selfballoon_attrs=0A };=0A
--=__PartCFE1C69D.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

--=__PartCFE1C69D.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 27 08:32:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1w00-0002ka-3f; Mon, 27 Feb 2012 08:32:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vzz-0002kU-7Z
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:31:59 +0000
Received: from [85.158.139.83:21240] by server-7.bemta-5.messagelabs.com id
	D4/F1-16195-E7F3B4F4; Mon, 27 Feb 2012 08:31:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330331517!9469194!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25988 invoked from network); 27 Feb 2012 08:31:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:31:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:31:57 +0000
Message-Id: <4F4B4D880200007800074E12@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:31:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
	<4F47783602000078000749C0@nat28.tlf.novell.com>
	<20120227014611.GA16888@phenom.dumpdata.com>
In-Reply-To: <20120227014611.GA16888@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load
 processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.02.12 at 02:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich wrote:
>> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > # HG changeset patch
>> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> > # Date 1330065828 18000
>> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
>> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
>> > linux-xencommons: Load processor-passthru
>> > 
>> > The processor-passthru module is used in the upstream kernels
>> > to upload power management information to the hypervisor. We
>> > need to load it to work first.
>> 
>> Hmm, I don't really like this (and prior) pvops-specific additions here,
>> even if stderr gets directed into nowhere. I don't think this (and any
>> other) script intended to target Linux in general should target just
>> a specific implementation.
>> 
>> Furthermore, given the purpose of the driver, I'm thinking that this
>> is too late in the boot process anyway, and the driver should rather
>> be loaded at the point where other CPUFreq drivers would normally
>> be by a particular distro (which would still be later than when the
>> respective code gets run on traditional Xenified Linux).
> 
> My thinking is to keep the amount of changes to be within the Xen-ecosystem.
> 
> Doing the changes in the old-fashioned way in drivers/acpi has not been
> very productive - so I've been looking at just some form of uploading
> the PM information to the hypervisor. And I've been piggybacking on
> top of the cpufreq scaling drivers collecting the information. So with that 
> in mind, the next idea I had was to provide a cpufreq governor, called 'xen'
> which would inhibit the cpufreq scaling drivers from changing anything in 
> dom0
> (so that the hypervisor can do it instead). Also it would be responsible
> for uploading the PM information to the hypervisor. See attached.
> 
> The fix to the tool-stack would be something along:
> # HG changeset patch
> # Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8
> 
> diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 13:29:00 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 21:42:20 2012 -0500
> @@ -58,7 +58,7 @@ do_start () {
>  	modprobe xen-gntdev 2>/dev/null
>  	modprobe evtchn 2>/dev/null
>  	modprobe gntdev 2>/dev/null
> -
> +	for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo xen > $file; done 2>/dev/null

While not an unreasonable idea (yes, I sort of contradict my other mail
from a few minutes ago, given your explanation above), this won't work
with subsequently onlined vCPU-s (and hence, consistent with my other
mail, having the thing be a governor is likely the wrong choice - it ought
to be a driver).

Jan

>  	if ! `xenstore-read -s / >/dev/null 2>&1`
>  	then
>  		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 08:32:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1w00-0002ka-3f; Mon, 27 Feb 2012 08:32:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1vzz-0002kU-7Z
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:31:59 +0000
Received: from [85.158.139.83:21240] by server-7.bemta-5.messagelabs.com id
	D4/F1-16195-E7F3B4F4; Mon, 27 Feb 2012 08:31:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330331517!9469194!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25988 invoked from network); 27 Feb 2012 08:31:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:31:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:31:57 +0000
Message-Id: <4F4B4D880200007800074E12@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:31:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <patchbomb.1330065832@phenom.dumpdata.com>
	<aa3a294327ed075bafbe.1330065834@phenom.dumpdata.com>
	<4F47783602000078000749C0@nat28.tlf.novell.com>
	<20120227014611.GA16888@phenom.dumpdata.com>
In-Reply-To: <20120227014611.GA16888@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load
 processor-passthru
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.02.12 at 02:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich wrote:
>> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > # HG changeset patch
>> > # User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> > # Date 1330065828 18000
>> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
>> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
>> > linux-xencommons: Load processor-passthru
>> > 
>> > The processor-passthru module is used in the upstream kernels
>> > to upload power management information to the hypervisor. We
>> > need to load it to work first.
>> 
>> Hmm, I don't really like this (and prior) pvops-specific additions here,
>> even if stderr gets directed into nowhere. I don't think this (and any
>> other) script intended to target Linux in general should target just
>> a specific implementation.
>> 
>> Furthermore, given the purpose of the driver, I'm thinking that this
>> is too late in the boot process anyway, and the driver should rather
>> be loaded at the point where other CPUFreq drivers would normally
>> be by a particular distro (which would still be later than when the
>> respective code gets run on traditional Xenified Linux).
> 
> My thinking is to keep the amount of changes to be within the Xen-ecosystem.
> 
> Doing the changes in the old-fashioned way in drivers/acpi has not been
> very productive - so I've been looking at just some form of uploading
> the PM information to the hypervisor. And I've been piggybacking on
> top of the cpufreq scaling drivers collecting the information. So with that 
> in mind, the next idea I had was to provide a cpufreq governor, called 'xen'
> which would inhibit the cpufreq scaling drivers from changing anything in 
> dom0
> (so that the hypervisor can do it instead). Also it would be responsible
> for uploading the PM information to the hypervisor. See attached.
> 
> The fix to the tool-stack would be something along:
> # HG changeset patch
> # Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8
> 
> diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 13:29:00 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons	Fri Feb 24 21:42:20 2012 -0500
> @@ -58,7 +58,7 @@ do_start () {
>  	modprobe xen-gntdev 2>/dev/null
>  	modprobe evtchn 2>/dev/null
>  	modprobe gntdev 2>/dev/null
> -
> +	for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo xen > $file; done 2>/dev/null

While not an unreasonable idea (yes, I sort of contradict my other mail
from a few minutes ago, given your explanation above), this won't work
with subsequently onlined vCPU-s (and hence, consistent with my other
mail, having the thing be a governor is likely the wrong choice - it ought
to be a driver).

Jan

>  	if ! `xenstore-read -s / >/dev/null 2>&1`
>  	then
>  		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 08:37:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1w5J-0002vY-TL; Mon, 27 Feb 2012 08:37:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1w5J-0002vN-09
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:37:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330331842!15057413!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10994 invoked from network); 27 Feb 2012 08:37:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:37:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:37:22 +0000
Message-Id: <4F4B4ECE0200007800074E2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:37:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
	<4F4771EE020000780007496D@nat28.tlf.novell.com>
	<952274bf3102b962f2edada5f7daa724.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <952274bf3102b962f2edada5f7daa724.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.02.12 at 18:18, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 23.02.12 at 20:59, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>>> +{
>>> +    unsigned int order;
>>> +    unsigned long long threshold;
>>> +
>>> +    /* Dom0 has already been allocated by now. So check we won't
>>> +     * be complaining immediately with whatever's left of the heap. */
>>> +    threshold = min(opt_low_mem_virq, (unsigned long long)
>>> +                          (total_avail_pages << PAGE_SHIFT));
>>
>> The cast needs to be on total_avail_pages, not the result of the
>> shift. Also, unsigned long long is the wrong type (paddr_t was
>> invented for this very purpose).
>>
>> Further, the initial threshold should clearly be *below* the currently
>> available amount (e.g. at half of it).
> 
> That's debatable. Let's set aside the semantics of what is "really" or
> "dangerously" low, and assume the admin knows what he/she is doing when
> setting the threshold in the command line. If the amount of available
> memory is below that threshold, then the moment an allocation happens we
> need to warn.

My comment wasn't about command line specified values - those
certainly should be obeyed to. But the threshold chosen when there
was nothing said on the command line should imo not result in an
immediate warning.

>>>  /* Architecture-specific VIRQ definitions. */
>>>  #define VIRQ_ARCH_0    16
>>
>> Given that this new vIRQ ought to be handled in user space, do you
>> have an implementation ready to contribute as well?
> 
> I have my little daemon that I use for this. It's nothing you would not
> expect: listen for the virq, balloon dom0 down a bit. I can throw it into
> the tree, although I don't know where. Or I can post it to the list for
> posterity. Ideally all "memory management daemons" out there that find it
> useful would pick it up -- certainly the hope is for squeezed to do that,
> but I view that as a separate effort.

At least posting it would be nice, so people could make suggestions
as to where it might go in the tree, and in what shape.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 08:37:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 08:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1w5J-0002vY-TL; Mon, 27 Feb 2012 08:37:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1w5J-0002vN-09
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 08:37:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330331842!15057413!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10994 invoked from network); 27 Feb 2012 08:37:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 08:37:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 08:37:22 +0000
Message-Id: <4F4B4ECE0200007800074E2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 08:37:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <da02cb8485de698078ba.1330027198@xdev.gridcentric.ca>
	<4F4771EE020000780007496D@nat28.tlf.novell.com>
	<952274bf3102b962f2edada5f7daa724.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <952274bf3102b962f2edada5f7daa724.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.02.12 at 18:18, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>>>> On 23.02.12 at 20:59, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>>> +{
>>> +    unsigned int order;
>>> +    unsigned long long threshold;
>>> +
>>> +    /* Dom0 has already been allocated by now. So check we won't
>>> +     * be complaining immediately with whatever's left of the heap. */
>>> +    threshold = min(opt_low_mem_virq, (unsigned long long)
>>> +                          (total_avail_pages << PAGE_SHIFT));
>>
>> The cast needs to be on total_avail_pages, not the result of the
>> shift. Also, unsigned long long is the wrong type (paddr_t was
>> invented for this very purpose).
>>
>> Further, the initial threshold should clearly be *below* the currently
>> available amount (e.g. at half of it).
> 
> That's debatable. Let's set aside the semantics of what is "really" or
> "dangerously" low, and assume the admin knows what he/she is doing when
> setting the threshold in the command line. If the amount of available
> memory is below that threshold, then the moment an allocation happens we
> need to warn.

My comment wasn't about command line specified values - those
certainly should be obeyed to. But the threshold chosen when there
was nothing said on the command line should imo not result in an
immediate warning.

>>>  /* Architecture-specific VIRQ definitions. */
>>>  #define VIRQ_ARCH_0    16
>>
>> Given that this new vIRQ ought to be handled in user space, do you
>> have an implementation ready to contribute as well?
> 
> I have my little daemon that I use for this. It's nothing you would not
> expect: listen for the virq, balloon dom0 down a bit. I can throw it into
> the tree, although I don't know where. Or I can post it to the list for
> posterity. Ideally all "memory management daemons" out there that find it
> useful would pick it up -- certainly the hope is for squeezed to do that,
> but I view that as a separate effort.

At least posting it would be nice, so people could make suggestions
as to where it might go in the tree, and in what shape.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1wTB-0003SL-Sm; Mon, 27 Feb 2012 09:02:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1wTA-0003SG-Ob
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 09:02:08 +0000
Received: from [85.158.139.83:49034] by server-10.bemta-5.messagelabs.com id
	F4/A0-06263-0964B4F4; Mon, 27 Feb 2012 09:02:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330333327!9474464!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17361 invoked from network); 27 Feb 2012 09:02:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:02:07 -0000
Received: by wibhr2 with SMTP id hr2so617183wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 01:02:07 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr20372750wia.3.1330333327178 (num_hops
	= 1); Mon, 27 Feb 2012 01:02:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=a5DmMdMJRuDGBA8/I3E9Gc+8wDW1YslX5WhNknrksbE=;
	b=AQPJzzIBue5HtrXaN8muhpz0/t92OUGdywV1owNrxbhyIy17DoKnGMMbuctkWvv61G
	sgYDfLfwczmZsZn5ymrQojsjaC+ipNbLVHlp2F1I/t9OiOGB6+wlQkwU8naj1+N/c5Yc
	mEuTomUxjMBRZdzPmphY25vf+zecQZbOAAJuA=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr16305009wia.3.1330333327128; Mon,
	27 Feb 2012 01:02:07 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Mon, 27 Feb 2012 01:02:07 -0800 (PST)
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100510C6@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100510C6@SHSMSX101.ccr.corp.intel.com>
Date: Mon, 27 Feb 2012 10:02:07 +0100
X-Google-Sender-Auth: ywf8P8VG3H6VR8fc4JafhwH1hKk
Message-ID: <CAPLaKK6aGjYrfAbzy6qHZgar9LiQ8GsOkdekTJm0AwnHF9Pcog@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: fix python version checking 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI1IFJlbiwgWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50ZWwuY29tPjoKPiBFdmVuIGlm
IHB5dGhvbiB2ZXJzaW9uIGlzIDIuNC4zIHdoaWNoIGlzIG5ld2VyIHRoYW4gdGhlIHJlcXVpcmVk
IHZlcnNpb24gMi4zLCB0aGUgY29uZmlndXJlIHNjcmlwdCBzdGlsbCByYWlzZXMgYSB2ZXJzaW9u
IGlzc3VlLgo+IEkgdGVzdGVkIG15IHBhdGNoIHdpdGggcHl0aG9uIDIuNi42IGFuZCAyLjQuMy4g
SXQgd2lsbCBmaXggYSBzeW50YXggZXJyb3IgbGlrZSB0aGUgZm9sbG93aW5nLgo+IGNoZWNraW5n
IGZvciBweXRob24gdmVyc2lvbiA+PSAyLjMgLi4uIFRyYWNlYmFjayAobW9zdCByZWNlbnQgY2Fs
bCBsYXN0KToKPiDCoEZpbGUgIjxzdHJpbmc+IiwgbGluZSAxLCBpbiA/Cj4gVHlwZUVycm9yOiAn
c3RyJyBvYmplY3QgaXMgbm90IGNhbGxhYmxlCj4gbm8KPiBjb25maWd1cmU6IGVycm9yOiBQeXRo
b24gMi40LjMgaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMwo+Cj4g
U2lnbmVkLW9mZi1ieTogWW9uZ2ppZSBSZW4gPHlvbmdqaWUucmVuQGludGVsLmNvbT4KCkFja2Vk
LWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PgoKUHJvdmlkZWQg
dGhhdCB0aGUgZm9sbG93aW5nIGlzIGFwcGxpZWQgYWZ0ZXIsIG91dHB1dCBmcm9tIGF1dG9jb25m
OgoKODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKYXV0b2Nv
bmY6IHJlcnVuIGF1dG9jb25mCgpSZXJ1biBhdXRvY29uZiB0byBnZW5lcmF0ZSBuZXcgY29uZmln
dXJlIHNjcmlwdCB3aXRoIHB5dGhvbiB2ZXJzaW9uCmNoZWNraW5nIGZpeC4KClNpZ25lZC1vZmYt
Ynk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIDg5
MTZkNzgyYmEyNyB0b29scy9jb25maWd1cmUKLS0tIGEvdG9vbHMvY29uZmlndXJlCVR1ZSBGZWIg
MjEgMjI6Mjg6MDMgMjAxMiArMDEwMAorKysgYi90b29scy9jb25maWd1cmUJVHVlIEZlYiAyMSAy
MjozMDowMyAyMDEyICswMTAwCkBAIC02MjkzLDcgKzYyOTMsNyBAQCB0aGVuCiBmaQogICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhv
bgp2ZXJzaW9uID49IDIuMyAiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2
ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KLWAkUFlUSE9OIC1jICdpbXBvcnQgc3lzOyBleGl0
KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAorYCRQWVRIT04gLWMgJ2ltcG9y
dCBzeXM7IHN5cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAogaWYg
dGVzdCAiJD8iICE9ICIwIgogdGhlbgogICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+
JjFgCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1wTB-0003SL-Sm; Mon, 27 Feb 2012 09:02:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1wTA-0003SG-Ob
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 09:02:08 +0000
Received: from [85.158.139.83:49034] by server-10.bemta-5.messagelabs.com id
	F4/A0-06263-0964B4F4; Mon, 27 Feb 2012 09:02:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330333327!9474464!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17361 invoked from network); 27 Feb 2012 09:02:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:02:07 -0000
Received: by wibhr2 with SMTP id hr2so617183wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 01:02:07 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr20372750wia.3.1330333327178 (num_hops
	= 1); Mon, 27 Feb 2012 01:02:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=a5DmMdMJRuDGBA8/I3E9Gc+8wDW1YslX5WhNknrksbE=;
	b=AQPJzzIBue5HtrXaN8muhpz0/t92OUGdywV1owNrxbhyIy17DoKnGMMbuctkWvv61G
	sgYDfLfwczmZsZn5ymrQojsjaC+ipNbLVHlp2F1I/t9OiOGB6+wlQkwU8naj1+N/c5Yc
	mEuTomUxjMBRZdzPmphY25vf+zecQZbOAAJuA=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr16305009wia.3.1330333327128; Mon,
	27 Feb 2012 01:02:07 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Mon, 27 Feb 2012 01:02:07 -0800 (PST)
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100510C6@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A100510C6@SHSMSX101.ccr.corp.intel.com>
Date: Mon, 27 Feb 2012 10:02:07 +0100
X-Google-Sender-Auth: ywf8P8VG3H6VR8fc4JafhwH1hKk
Message-ID: <CAPLaKK6aGjYrfAbzy6qHZgar9LiQ8GsOkdekTJm0AwnHF9Pcog@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Cc: "ian.jackson@citrix.com" <ian.jackson@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: fix python version checking 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI1IFJlbiwgWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50ZWwuY29tPjoKPiBFdmVuIGlm
IHB5dGhvbiB2ZXJzaW9uIGlzIDIuNC4zIHdoaWNoIGlzIG5ld2VyIHRoYW4gdGhlIHJlcXVpcmVk
IHZlcnNpb24gMi4zLCB0aGUgY29uZmlndXJlIHNjcmlwdCBzdGlsbCByYWlzZXMgYSB2ZXJzaW9u
IGlzc3VlLgo+IEkgdGVzdGVkIG15IHBhdGNoIHdpdGggcHl0aG9uIDIuNi42IGFuZCAyLjQuMy4g
SXQgd2lsbCBmaXggYSBzeW50YXggZXJyb3IgbGlrZSB0aGUgZm9sbG93aW5nLgo+IGNoZWNraW5n
IGZvciBweXRob24gdmVyc2lvbiA+PSAyLjMgLi4uIFRyYWNlYmFjayAobW9zdCByZWNlbnQgY2Fs
bCBsYXN0KToKPiDCoEZpbGUgIjxzdHJpbmc+IiwgbGluZSAxLCBpbiA/Cj4gVHlwZUVycm9yOiAn
c3RyJyBvYmplY3QgaXMgbm90IGNhbGxhYmxlCj4gbm8KPiBjb25maWd1cmU6IGVycm9yOiBQeXRo
b24gMi40LjMgaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzIDIuMwo+Cj4g
U2lnbmVkLW9mZi1ieTogWW9uZ2ppZSBSZW4gPHlvbmdqaWUucmVuQGludGVsLmNvbT4KCkFja2Vk
LWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PgoKUHJvdmlkZWQg
dGhhdCB0aGUgZm9sbG93aW5nIGlzIGFwcGxpZWQgYWZ0ZXIsIG91dHB1dCBmcm9tIGF1dG9jb25m
OgoKODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKYXV0b2Nv
bmY6IHJlcnVuIGF1dG9jb25mCgpSZXJ1biBhdXRvY29uZiB0byBnZW5lcmF0ZSBuZXcgY29uZmln
dXJlIHNjcmlwdCB3aXRoIHB5dGhvbiB2ZXJzaW9uCmNoZWNraW5nIGZpeC4KClNpZ25lZC1vZmYt
Ynk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIDg5
MTZkNzgyYmEyNyB0b29scy9jb25maWd1cmUKLS0tIGEvdG9vbHMvY29uZmlndXJlCVR1ZSBGZWIg
MjEgMjI6Mjg6MDMgMjAxMiArMDEwMAorKysgYi90b29scy9jb25maWd1cmUJVHVlIEZlYiAyMSAy
MjozMDowMyAyMDEyICswMTAwCkBAIC02MjkzLDcgKzYyOTMsNyBAQCB0aGVuCiBmaQogICAgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhv
bgp2ZXJzaW9uID49IDIuMyAiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB2
ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KLWAkUFlUSE9OIC1jICdpbXBvcnQgc3lzOyBleGl0
KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAorYCRQWVRIT04gLWMgJ2ltcG9y
dCBzeXM7IHN5cy5leGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAogaWYg
dGVzdCAiJD8iICE9ICIwIgogdGhlbgogICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+
JjFgCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:03:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:03:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1wUc-0003Wk-Be; Mon, 27 Feb 2012 09:03: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 1S1wUZ-0003WU-MQ
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:03:37 +0000
Received: from [85.158.139.83:37840] by server-12.bemta-5.messagelabs.com id
	E4/97-05100-6E64B4F4; Mon, 27 Feb 2012 09:03:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330333412!5541686!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14119 invoked from network); 27 Feb 2012 09:03: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 09:03:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 09:03:32 +0000
Message-Id: <4F4B54F00200007800074E3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 09:03:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>,<keir@xen.org>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
In-Reply-To: <E1S15wA-00053m-NU@woking.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com> wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-amd
> test redhat-install
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> 
> *** Found and reproduced problem changeset ***

I had warned a number of times that a change like this should not be
done: Afaict, this broke qemu-xen (and upstream qemu as well), which
use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
specific __XEN_INTERFACE_VERSION__ (the tools generally just use
'latest').

The same would go for tools/blktap*/.

So either all uses within tools land get properly fixed (which is going to
be particularly hard to synchronize with upstream qemu), or (my
preference) the change gets reverted and done backward
compatibly without involving __XEN_INTERFACE_VERSION__.

Jan

>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  a59c1dcfe968
>   Bug not present: f9789db96c39
> 
> 
>   changeset:   24875:a59c1dcfe968
>   user:        Justin T. Gibbs <justing@spectralogic.com>
>   date:        Thu Feb 23 10:03:07 2012 +0000
>       
>       blkif.h: Define and document the request number/size/segments 
> extension
>       
>       Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>             BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
>             updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
>             before being recompiled with a __XEN_INTERFACE_VERSION greater
>             than or equal to this value.
>       
>       This extension first appeared in the FreeBSD Operating System.
>       
>       Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>       Committed-by: Keir Fraser <keir@xen.org>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test- 
> amd64-i386-rhel6hvm-amd.redhat-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  12043 fail [host=potato-beetle] / 12031 ok.
> Failure / basis pass flights: 12043 / 12031
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
> Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> Generating revisions with ./adhoc-revtuple-generator  
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71
> d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e
> 46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a 
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b9
> 5c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc 
> http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1 
> 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 59 nodes in revision graph
> Searching for test results:
>  12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
>  12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
>  12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
>  12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
>  12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
>  12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
>  12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> Searching for interesting versions
>  Result found: flight 12024 (pass), for basis pass
>  Result found: flight 12043 (fail), for basis failure
>  Repro found: flight 12044 (pass), for basis pass
>  Repro found: flight 12054 (fail), for basis failure
>  0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> No revisions left to test, checking graph state.
>  Result found: flight 12051 (pass), for last pass
>  Result found: flight 12052 (fail), for first failure
>  Repro found: flight 12055 (pass), for last pass
>  Repro found: flight 12057 (fail), for first failure
>  Repro found: flight 12059 (pass), for last pass
>  Repro found: flight 12060 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  a59c1dcfe968
>   Bug not present: f9789db96c39
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24875:a59c1dcfe968
>   user:        Justin T. Gibbs <justing@spectralogic.com>
>   date:        Thu Feb 23 10:03:07 2012 +0000
>       
>       blkif.h: Define and document the request number/size/segments 
> extension
>       
>       Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>             BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
>             updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
>             before being recompiled with a __XEN_INTERFACE_VERSION greater
>             than or equal to this value.
>       
>       This extension first appeared in the FreeBSD Operating System.
>       
>       Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>       Committed-by: Keir Fraser <keir@xen.org>
>       
>       
> 
> Revision graph left in 
> /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.re
> dhat-install.{dot,ps,png,html}.
> ----------------------------------------
> 12060: ALL FAIL
> 
> flight 12060 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/ 
> 
> 
> jobs:
>  test-amd64-i386-rhel6hvm-amd                                 fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs 
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:03:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:03:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1wUc-0003Wk-Be; Mon, 27 Feb 2012 09:03: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 1S1wUZ-0003WU-MQ
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:03:37 +0000
Received: from [85.158.139.83:37840] by server-12.bemta-5.messagelabs.com id
	E4/97-05100-6E64B4F4; Mon, 27 Feb 2012 09:03:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330333412!5541686!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14119 invoked from network); 27 Feb 2012 09:03: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 DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 09:03:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 09:03:32 +0000
Message-Id: <4F4B54F00200007800074E3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 09:03:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>,<keir@xen.org>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
In-Reply-To: <E1S15wA-00053m-NU@woking.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com> wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-amd
> test redhat-install
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> 
> *** Found and reproduced problem changeset ***

I had warned a number of times that a change like this should not be
done: Afaict, this broke qemu-xen (and upstream qemu as well), which
use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
specific __XEN_INTERFACE_VERSION__ (the tools generally just use
'latest').

The same would go for tools/blktap*/.

So either all uses within tools land get properly fixed (which is going to
be particularly hard to synchronize with upstream qemu), or (my
preference) the change gets reverted and done backward
compatibly without involving __XEN_INTERFACE_VERSION__.

Jan

>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  a59c1dcfe968
>   Bug not present: f9789db96c39
> 
> 
>   changeset:   24875:a59c1dcfe968
>   user:        Justin T. Gibbs <justing@spectralogic.com>
>   date:        Thu Feb 23 10:03:07 2012 +0000
>       
>       blkif.h: Define and document the request number/size/segments 
> extension
>       
>       Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>             BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
>             updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
>             before being recompiled with a __XEN_INTERFACE_VERSION greater
>             than or equal to this value.
>       
>       This extension first appeared in the FreeBSD Operating System.
>       
>       Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>       Committed-by: Keir Fraser <keir@xen.org>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test- 
> amd64-i386-rhel6hvm-amd.redhat-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  12043 fail [host=potato-beetle] / 12031 ok.
> Failure / basis pass flights: 12043 / 12031
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
> Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> Generating revisions with ./adhoc-revtuple-generator  
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71
> d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e
> 46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a 
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b9
> 5c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc 
> http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1 
> 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 59 nodes in revision graph
> Searching for test results:
>  12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
>  12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
>  12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
>  12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
>  12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
>  12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
>  12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
>  12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
>  12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
>  12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> Searching for interesting versions
>  Result found: flight 12024 (pass), for basis pass
>  Result found: flight 12043 (fail), for basis failure
>  Repro found: flight 12044 (pass), for basis pass
>  Repro found: flight 12054 (fail), for basis failure
>  0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 
> 128de2549c5f24e4a437b86bd2e46f023976d50a 
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> No revisions left to test, checking graph state.
>  Result found: flight 12051 (pass), for last pass
>  Result found: flight 12052 (fail), for first failure
>  Repro found: flight 12055 (pass), for last pass
>  Repro found: flight 12057 (fail), for first failure
>  Repro found: flight 12059 (pass), for last pass
>  Repro found: flight 12060 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg 
>   Bug introduced:  a59c1dcfe968
>   Bug not present: f9789db96c39
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24875:a59c1dcfe968
>   user:        Justin T. Gibbs <justing@spectralogic.com>
>   date:        Thu Feb 23 10:03:07 2012 +0000
>       
>       blkif.h: Define and document the request number/size/segments 
> extension
>       
>       Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
>             BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
>             updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
>             before being recompiled with a __XEN_INTERFACE_VERSION greater
>             than or equal to this value.
>       
>       This extension first appeared in the FreeBSD Operating System.
>       
>       Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>       Committed-by: Keir Fraser <keir@xen.org>
>       
>       
> 
> Revision graph left in 
> /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.re
> dhat-install.{dot,ps,png,html}.
> ----------------------------------------
> 12060: ALL FAIL
> 
> flight 12060 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/ 
> 
> 
> jobs:
>  test-amd64-i386-rhel6hvm-amd                                 fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs 
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:32:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1wwM-0004Bn-IT; Mon, 27 Feb 2012 09:32:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1wwL-0004Bf-16
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:32:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330335130!9919593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28209 invoked from network); 27 Feb 2012 09:32:11 -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;
	27 Feb 2012 09:32:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:32:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:32:10 +0000
Message-ID: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:32:09 +0000
In-Reply-To: <4F4B54F00200007800074E3D@nat28.tlf.novell.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
> >>> On 25.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-rhel6hvm-amd
> > test redhat-install
> > 
> > Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> > 
> > *** Found and reproduced problem changeset ***
> 
> I had warned a number of times that a change like this should not be
> done: Afaict, this broke qemu-xen (and upstream qemu as well), which
> use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
> specific __XEN_INTERFACE_VERSION__ (the tools generally just use
> 'latest').

Yes, we should have better foreseen this, especially given that you were
trying to tell us what we should see!

AFAICT the places which needed changing are:
      * mini-os
      * qemu-xen-traditional
      * qemu-xen (upstream)

A patch (untested, but mostly done via sed) for mini-os follows. This
one really ought to have been forseen.

I was surprised that qemu (particularly upstream qemu) is building
against the Xen headers using __XEN_INTERFACE_VERSION__.

I think it is not worth fixing this for qemu-xen-traditional, so I will
follow up with the

> The same would go for tools/blktap*/.

That one never occurred to me, even after I grepped for the symbol.

> So either all uses within tools land get properly fixed (which is going to
> be particularly hard to synchronize with upstream qemu),

IMHO upstream qemu should either include it's own copy of the i/o
interface headers that it uses or it should use a specific
__XEN_INTERFACE_VERSION__. Is this something which is wrong with the
qemu tree or is it the Xen build system integration which is at fault?

I'll followup with a quick fix but IMHO it could be done better.

>  or (my
> preference) the change gets reverted and done backward
> compatibly without involving __XEN_INTERFACE_VERSION__.

Given that it is blocking the test gate I think reverting it should be
strongly considered. As for how best to do this properly I have less of
an opinion.

That mini-os fix:

8<----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335066 0
# Node ID f351fec6d3960d537dde2cb35374982f6ea13e16
# Parent  a4ef50b6313066d953314969494654f4f393558a
mini-os: Fix breakage causes by blkif.h interface change.

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting in mini-os.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c	Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/blkfront.c	Mon Feb 27 09:31:06 2012 +0000
@@ -352,7 +352,7 @@ void blkfront_aio(struct blkfront_aiocb 
 
     /* qemu's IDE max multsect is 16 (8KB) and SCSI max DMA was set to 32KB,
      * so max 44KB can't happen */
-    ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_REQUEST);
+    ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
 
     blkfront_wait_slot(dev);
     i = dev->ring.req_prod_pvt;
diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/include/blkfront.h
--- a/extras/mini-os/include/blkfront.h	Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/include/blkfront.h	Mon Feb 27 09:31:06 2012 +0000
@@ -12,7 +12,7 @@ struct blkfront_aiocb
     uint8_t is_write;
     void *data;
 
-    grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int n;
 
     void (*aio_cb)(struct blkfront_aiocb *aiocb, int ret);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:32:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1wwM-0004Bn-IT; Mon, 27 Feb 2012 09:32:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1wwL-0004Bf-16
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:32:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330335130!9919593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28209 invoked from network); 27 Feb 2012 09:32:11 -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;
	27 Feb 2012 09:32:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948566"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:32:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:32:10 +0000
Message-ID: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:32:09 +0000
In-Reply-To: <4F4B54F00200007800074E3D@nat28.tlf.novell.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
> >>> On 25.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-rhel6hvm-amd
> > test redhat-install
> > 
> > Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg 
> > 
> > *** Found and reproduced problem changeset ***
> 
> I had warned a number of times that a change like this should not be
> done: Afaict, this broke qemu-xen (and upstream qemu as well), which
> use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
> specific __XEN_INTERFACE_VERSION__ (the tools generally just use
> 'latest').

Yes, we should have better foreseen this, especially given that you were
trying to tell us what we should see!

AFAICT the places which needed changing are:
      * mini-os
      * qemu-xen-traditional
      * qemu-xen (upstream)

A patch (untested, but mostly done via sed) for mini-os follows. This
one really ought to have been forseen.

I was surprised that qemu (particularly upstream qemu) is building
against the Xen headers using __XEN_INTERFACE_VERSION__.

I think it is not worth fixing this for qemu-xen-traditional, so I will
follow up with the

> The same would go for tools/blktap*/.

That one never occurred to me, even after I grepped for the symbol.

> So either all uses within tools land get properly fixed (which is going to
> be particularly hard to synchronize with upstream qemu),

IMHO upstream qemu should either include it's own copy of the i/o
interface headers that it uses or it should use a specific
__XEN_INTERFACE_VERSION__. Is this something which is wrong with the
qemu tree or is it the Xen build system integration which is at fault?

I'll followup with a quick fix but IMHO it could be done better.

>  or (my
> preference) the change gets reverted and done backward
> compatibly without involving __XEN_INTERFACE_VERSION__.

Given that it is blocking the test gate I think reverting it should be
strongly considered. As for how best to do this properly I have less of
an opinion.

That mini-os fix:

8<----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335066 0
# Node ID f351fec6d3960d537dde2cb35374982f6ea13e16
# Parent  a4ef50b6313066d953314969494654f4f393558a
mini-os: Fix breakage causes by blkif.h interface change.

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting in mini-os.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c	Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/blkfront.c	Mon Feb 27 09:31:06 2012 +0000
@@ -352,7 +352,7 @@ void blkfront_aio(struct blkfront_aiocb 
 
     /* qemu's IDE max multsect is 16 (8KB) and SCSI max DMA was set to 32KB,
      * so max 44KB can't happen */
-    ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_REQUEST);
+    ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
 
     blkfront_wait_slot(dev);
     i = dev->ring.req_prod_pvt;
diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/include/blkfront.h
--- a/extras/mini-os/include/blkfront.h	Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/include/blkfront.h	Mon Feb 27 09:31:06 2012 +0000
@@ -12,7 +12,7 @@ struct blkfront_aiocb
     uint8_t is_write;
     void *data;
 
-    grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int n;
 
     void (*aio_cb)(struct blkfront_aiocb *aiocb, int ret);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:35:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1wyc-0004Ic-7T; Mon, 27 Feb 2012 09:34:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1wya-0004IM-2i
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:34:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330335269!17041421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18279 invoked from network); 27 Feb 2012 09:34:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:34:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:34:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:34:29 +0000
Message-ID: <1330335268.8557.249.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:34:28 +0000
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH qemu-xen-traditional] Fix after blkif.h 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

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 block-vbd.c    |    2 +-
 hw/e1000.c     |    3 +++
 hw/ide.c       |    2 +-
 hw/scsi-disk.c |    2 +-
 hw/xen_blkif.h |    8 ++++----
 hw/xen_disk.c  |   12 ++++++------
 6 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/block-vbd.c b/block-vbd.c
index 71f1731..2a80f09 100644
--- a/block-vbd.c
+++ b/block-vbd.c
@@ -33,7 +33,7 @@
 
 #include <xen/io/blkif.h>
 #define IDE_DMA_BUF_SECTORS \
-	(((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+	(((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
 #define IDE_DMA_BUF_BYTES (IDE_DMA_BUF_SECTORS * 512)
 #define SECTOR_SIZE 512
 
diff --git a/hw/e1000.c b/hw/e1000.c
index bb3689e..97104ed 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
             bytes = split_size;
             if (tp->size + bytes > msh)
                 bytes = msh - tp->size;
+
+            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
             cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
             if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
                 memmove(tp->header, tp->data, hdr);
@@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
         // context descriptor TSE is not set, while data descriptor TSE is set
         DBGOUT(TXERR, "TCP segmentaion Error\n");
     } else {
+        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
         cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
         tp->size += split_size;
     }
diff --git a/hw/ide.c b/hw/ide.c
index 791666b..c3d3d60 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -209,7 +209,7 @@
 #ifdef CONFIG_STUBDOM
 #include <xen/io/blkif.h>
 #define IDE_DMA_BUF_SECTORS \
-	(((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+	(((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
 #else
 #define IDE_DMA_BUF_SECTORS 256
 #endif
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 520009e..99c2cdf 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -42,7 +42,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); } while (0)
 
 #ifdef CONFIG_STUBDOM
 #include <xen/io/blkif.h>
-#define SCSI_DMA_BUF_SIZE    ((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1) * TARGET_PAGE_SIZE)
+#define SCSI_DMA_BUF_SIZE    ((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1) * TARGET_PAGE_SIZE)
 #else
 #define SCSI_DMA_BUF_SIZE    131072
 #endif
diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index ca3a65b..485a166 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -24,7 +24,7 @@ struct blkif_x86_32_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
@@ -42,7 +42,7 @@ struct blkif_x86_64_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       __attribute__((__aligned__(8))) id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
@@ -72,7 +72,7 @@ enum blkif_protocol {
 
 static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
@@ -87,7 +87,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_reque
 
 static inline void blkif_get_x86_64_req(blkif_request_t *dst, blkif_x86_64_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 6aebb77..092def8 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -55,7 +55,7 @@ static int use_aio      = 0;
 /* ------------------------------------------------------------- */
 
 #define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
 
 struct ioreq {
     blkif_request_t     req;
@@ -68,10 +68,10 @@ struct ioreq {
     int                 postsync;
 
     /* grant mapping */
-    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int                 prot;
-    void                *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    void                *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     void                *pages;
 
     /* aio status */
@@ -127,7 +127,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 	ioreq = qemu_mallocz(sizeof(*ioreq));
 	ioreq->blkdev = blkdev;
 	blkdev->requests_total++;
-        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
     } else {
 	/* get one from freelist */
 	ioreq = LIST_FIRST(&blkdev->freelist);
@@ -207,7 +207,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 
     ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
     for (i = 0; i < ioreq->req.nr_segments; i++) {
-	if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+	if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
 	    xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n");
 	    goto err;
 	}
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:35:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1wyc-0004Ic-7T; Mon, 27 Feb 2012 09:34:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1wya-0004IM-2i
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:34:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330335269!17041421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18279 invoked from network); 27 Feb 2012 09:34:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:34:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:34:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:34:29 +0000
Message-ID: <1330335268.8557.249.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:34:28 +0000
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH qemu-xen-traditional] Fix after blkif.h 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

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 block-vbd.c    |    2 +-
 hw/e1000.c     |    3 +++
 hw/ide.c       |    2 +-
 hw/scsi-disk.c |    2 +-
 hw/xen_blkif.h |    8 ++++----
 hw/xen_disk.c  |   12 ++++++------
 6 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/block-vbd.c b/block-vbd.c
index 71f1731..2a80f09 100644
--- a/block-vbd.c
+++ b/block-vbd.c
@@ -33,7 +33,7 @@
 
 #include <xen/io/blkif.h>
 #define IDE_DMA_BUF_SECTORS \
-	(((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+	(((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
 #define IDE_DMA_BUF_BYTES (IDE_DMA_BUF_SECTORS * 512)
 #define SECTOR_SIZE 512
 
diff --git a/hw/e1000.c b/hw/e1000.c
index bb3689e..97104ed 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
             bytes = split_size;
             if (tp->size + bytes > msh)
                 bytes = msh - tp->size;
+
+            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
             cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
             if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
                 memmove(tp->header, tp->data, hdr);
@@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
         // context descriptor TSE is not set, while data descriptor TSE is set
         DBGOUT(TXERR, "TCP segmentaion Error\n");
     } else {
+        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
         cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
         tp->size += split_size;
     }
diff --git a/hw/ide.c b/hw/ide.c
index 791666b..c3d3d60 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -209,7 +209,7 @@
 #ifdef CONFIG_STUBDOM
 #include <xen/io/blkif.h>
 #define IDE_DMA_BUF_SECTORS \
-	(((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+	(((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
 #else
 #define IDE_DMA_BUF_SECTORS 256
 #endif
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 520009e..99c2cdf 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -42,7 +42,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); } while (0)
 
 #ifdef CONFIG_STUBDOM
 #include <xen/io/blkif.h>
-#define SCSI_DMA_BUF_SIZE    ((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1) * TARGET_PAGE_SIZE)
+#define SCSI_DMA_BUF_SIZE    ((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1) * TARGET_PAGE_SIZE)
 #else
 #define SCSI_DMA_BUF_SIZE    131072
 #endif
diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index ca3a65b..485a166 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -24,7 +24,7 @@ struct blkif_x86_32_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
@@ -42,7 +42,7 @@ struct blkif_x86_64_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       __attribute__((__aligned__(8))) id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
@@ -72,7 +72,7 @@ enum blkif_protocol {
 
 static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
@@ -87,7 +87,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_reque
 
 static inline void blkif_get_x86_64_req(blkif_request_t *dst, blkif_x86_64_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 6aebb77..092def8 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -55,7 +55,7 @@ static int use_aio      = 0;
 /* ------------------------------------------------------------- */
 
 #define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
 
 struct ioreq {
     blkif_request_t     req;
@@ -68,10 +68,10 @@ struct ioreq {
     int                 postsync;
 
     /* grant mapping */
-    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int                 prot;
-    void                *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    void                *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     void                *pages;
 
     /* aio status */
@@ -127,7 +127,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 	ioreq = qemu_mallocz(sizeof(*ioreq));
 	ioreq->blkdev = blkdev;
 	blkdev->requests_total++;
-        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
     } else {
 	/* get one from freelist */
 	ioreq = LIST_FIRST(&blkdev->freelist);
@@ -207,7 +207,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 
     ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
     for (i = 0; i < ioreq->req.nr_segments; i++) {
-	if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+	if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
 	    xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n");
 	    goto err;
 	}
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:37:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:37:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1x0t-0004Qc-O1; Mon, 27 Feb 2012 09:36:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1x0s-0004QL-UX
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:36:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330335411!2865157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27800 invoked from network); 27 Feb 2012 09:36:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948700"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:36:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:36:50 +0000
Message-ID: <1330335409.8557.250.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:36:49 +0000
In-Reply-To: <1330335268.8557.249.camel@zakaz.uk.xensource.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
	<1330335268.8557.249.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Justin T. Gibbs" <justing@spectralogic.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH qemu-xen] Fix after blkif.h 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

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting here. A compatibility definition is included in order to keep
building with older versions of the headers.

IMHO qemu should contain a copy of the interface headers of its own so that it
can update at its own pace (like most guest OSes do).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 hw/xen_blkif.h |   13 +++++++++----
 hw/xen_disk.c  |   12 ++++++------
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index c0f4136..5db8319 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -5,6 +5,11 @@
 #include <xen/io/blkif.h>
 #include <xen/io/protocols.h>
 
+/* Compatibility with older blkif headers */
+#ifndef BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK BLKIF_MAX_SEGMENTS_PER_REQUEST
+#endif
+
 /* Not a real protocol.  Used to generate ring structs which contain
  * the elements common to all protocols only.  This way we get a
  * compiler-checkable way to use common struct elements, so we can
@@ -24,7 +29,7 @@ struct blkif_x86_32_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
@@ -42,7 +47,7 @@ struct blkif_x86_64_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       __attribute__((__aligned__(8))) id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
@@ -72,7 +77,7 @@ enum blkif_protocol {
 
 static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
@@ -87,7 +92,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_reque
 
 static inline void blkif_get_x86_64_req(blkif_request_t *dst, blkif_x86_64_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 286bbac..0f22bc6 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -54,7 +54,7 @@ static int use_aio      = 1;
 /* ------------------------------------------------------------- */
 
 #define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
 
 struct ioreq {
     blkif_request_t     req;
@@ -67,10 +67,10 @@ struct ioreq {
     int                 postsync;
 
     /* grant mapping */
-    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int                 prot;
-    void                *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    void                *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     void                *pages;
 
     /* aio status */
@@ -128,7 +128,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
         ioreq = g_malloc0(sizeof(*ioreq));
         ioreq->blkdev = blkdev;
         blkdev->requests_total++;
-        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
     } else {
         /* get one from freelist */
         ioreq = QLIST_FIRST(&blkdev->freelist);
@@ -210,7 +210,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 
     ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
     for (i = 0; i < ioreq->req.nr_segments; i++) {
-        if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+        if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
             xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n");
             goto err;
         }
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:37:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:37:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1x0t-0004Qc-O1; Mon, 27 Feb 2012 09:36:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1x0s-0004QL-UX
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:36:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330335411!2865157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27800 invoked from network); 27 Feb 2012 09:36:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948700"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:36:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:36:50 +0000
Message-ID: <1330335409.8557.250.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:36:49 +0000
In-Reply-To: <1330335268.8557.249.camel@zakaz.uk.xensource.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
	<1330335268.8557.249.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Justin T. Gibbs" <justing@spectralogic.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH qemu-xen] Fix after blkif.h 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

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting here. A compatibility definition is included in order to keep
building with older versions of the headers.

IMHO qemu should contain a copy of the interface headers of its own so that it
can update at its own pace (like most guest OSes do).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 hw/xen_blkif.h |   13 +++++++++----
 hw/xen_disk.c  |   12 ++++++------
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index c0f4136..5db8319 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -5,6 +5,11 @@
 #include <xen/io/blkif.h>
 #include <xen/io/protocols.h>
 
+/* Compatibility with older blkif headers */
+#ifndef BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK BLKIF_MAX_SEGMENTS_PER_REQUEST
+#endif
+
 /* Not a real protocol.  Used to generate ring structs which contain
  * the elements common to all protocols only.  This way we get a
  * compiler-checkable way to use common struct elements, so we can
@@ -24,7 +29,7 @@ struct blkif_x86_32_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
@@ -42,7 +47,7 @@ struct blkif_x86_64_request {
 	blkif_vdev_t   handle;       /* only for read/write requests         */
 	uint64_t       __attribute__((__aligned__(8))) id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
 };
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
@@ -72,7 +77,7 @@ enum blkif_protocol {
 
 static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
@@ -87,7 +92,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_reque
 
 static inline void blkif_get_x86_64_req(blkif_request_t *dst, blkif_x86_64_request_t *src)
 {
-	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
 
 	dst->operation = src->operation;
 	dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 286bbac..0f22bc6 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -54,7 +54,7 @@ static int use_aio      = 1;
 /* ------------------------------------------------------------- */
 
 #define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
 
 struct ioreq {
     blkif_request_t     req;
@@ -67,10 +67,10 @@ struct ioreq {
     int                 postsync;
 
     /* grant mapping */
-    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    uint32_t            domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+    uint32_t            refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     int                 prot;
-    void                *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+    void                *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
     void                *pages;
 
     /* aio status */
@@ -128,7 +128,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
         ioreq = g_malloc0(sizeof(*ioreq));
         ioreq->blkdev = blkdev;
         blkdev->requests_total++;
-        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+        qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
     } else {
         /* get one from freelist */
         ioreq = QLIST_FIRST(&blkdev->freelist);
@@ -210,7 +210,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 
     ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
     for (i = 0; i < ioreq->req.nr_segments; i++) {
-        if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+        if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
             xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n");
             goto err;
         }
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:44:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1x7R-0004ec-Ip; Mon, 27 Feb 2012 09:43:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1x7Q-0004eW-KL
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:43:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330335818!9908317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1743 invoked from network); 27 Feb 2012 09:43:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:43:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:43:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:43:38 +0000
Message-ID: <1330335816.8557.252.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:43:36 +0000
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
> > The same would go for tools/blktap*/.
> 
> That one never occurred to me, even after I grepped for the symbol.

I guess the following ought to fix it...

8<---------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335804 0
# Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
# Parent  0bb45a06c1a8b049dba322cfb91c86c253068f0e
blktap: Fix after blkif.h update

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here Fix after blkif.h update

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
--- a/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
@@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
 
 /* Accessing attached data page mappings */
 #define MMAP_PAGES                                              \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
 #define MMAP_VADDR(_vstart,_req,_seg)                                   \
     ((_vstart) +                                              \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
+     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +    \
      ((_seg) * getpagesize()))
 
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
--- a/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:43:24 2012 +0000
@@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
 		breq->sector_number = sreq->sec;
 		breq->operation     = BLKIF_OP_READ;
 
-		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
 			uint32_t secs;
 			struct blkif_request_segment *seg = breq->seg + i;
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
--- a/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:43:24 2012 +0000
@@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
 		breq->sector_number = sreq->sec;
 		breq->operation     = BLKIF_OP_READ;
 
-		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
 			uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
 			struct blkif_request_segment *seg = breq->seg + i;
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
--- a/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
@@ -222,10 +222,10 @@ typedef struct msg_lock {
 
 /* Accessing attached data page mappings */
 #define MMAP_PAGES                                                    \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
 #define MMAP_VADDR(_vstart,_req,_seg)                                 \
     ((_vstart) +                                                      \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
+     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +      \
      ((_seg) * getpagesize()))
 
 /* Defines that are only used by library clients */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:44:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1x7R-0004ec-Ip; Mon, 27 Feb 2012 09:43:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1x7Q-0004eW-KL
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:43:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330335818!9908317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1743 invoked from network); 27 Feb 2012 09:43:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:43:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:43:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:43:38 +0000
Message-ID: <1330335816.8557.252.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 27 Feb 2012 09:43:36 +0000
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
> > The same would go for tools/blktap*/.
> 
> That one never occurred to me, even after I grepped for the symbol.

I guess the following ought to fix it...

8<---------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335804 0
# Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
# Parent  0bb45a06c1a8b049dba322cfb91c86c253068f0e
blktap: Fix after blkif.h update

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here Fix after blkif.h update

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
--- a/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
@@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
 
 /* Accessing attached data page mappings */
 #define MMAP_PAGES                                              \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
 #define MMAP_VADDR(_vstart,_req,_seg)                                   \
     ((_vstart) +                                              \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
+     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +    \
      ((_seg) * getpagesize()))
 
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
--- a/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:43:24 2012 +0000
@@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
 		breq->sector_number = sreq->sec;
 		breq->operation     = BLKIF_OP_READ;
 
-		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
 			uint32_t secs;
 			struct blkif_request_segment *seg = breq->seg + i;
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
--- a/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:43:24 2012 +0000
@@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
 		breq->sector_number = sreq->sec;
 		breq->operation     = BLKIF_OP_READ;
 
-		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
 			uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
 			struct blkif_request_segment *seg = breq->seg + i;
 
diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
--- a/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
@@ -222,10 +222,10 @@ typedef struct msg_lock {
 
 /* Accessing attached data page mappings */
 #define MMAP_PAGES                                                    \
-    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
 #define MMAP_VADDR(_vstart,_req,_seg)                                 \
     ((_vstart) +                                                      \
-     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
+     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +      \
      ((_seg) * getpagesize()))
 
 /* Defines that are only used by library clients */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:45:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1x8R-0004hc-0o; Mon, 27 Feb 2012 09:44:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1x8P-0004hB-4l
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330335879!2867138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32391 invoked from network); 27 Feb 2012 09:44:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:44:38 +0000
Message-ID: <1330335877.8557.253.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Mon, 27 Feb 2012 09:44:37 +0000
In-Reply-To: <c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
> from the hypervisor angle, but it's a lose-lose game. Ballooning a
> shared page gains you nothing. The ballooner can't know what is shared
> and what isn't, in order to make an educated decision. And the sharer
> can't foresee what the balloon will victimize. 

Doesn't ballooning generally evict unused pages, because it allocates
new _free_ pages, even if they were shared is there any benefit to doing
so?

Or is it more of a second order effect, e.g. ballooning can cause the
guest to swap out stuff which could have been shared?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:45:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1x8R-0004hc-0o; Mon, 27 Feb 2012 09:44:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1x8P-0004hB-4l
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330335879!2867138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32391 invoked from network); 27 Feb 2012 09:44:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10948899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:44:38 +0000
Message-ID: <1330335877.8557.253.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
Date: Mon, 27 Feb 2012 09:44:37 +0000
In-Reply-To: <c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
> from the hypervisor angle, but it's a lose-lose game. Ballooning a
> shared page gains you nothing. The ballooner can't know what is shared
> and what isn't, in order to make an educated decision. And the sharer
> can't foresee what the balloon will victimize. 

Doesn't ballooning generally evict unused pages, because it allocates
new _free_ pages, even if they were shared is there any benefit to doing
so?

Or is it more of a second order effect, e.g. ballooning can cause the
guest to swap out stuff which could have been shared?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:52:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1xFq-0004yv-0X; Mon, 27 Feb 2012 09:52:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1xFn-0004yq-TF
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 09:52:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330336337!9910486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10956 invoked from network); 27 Feb 2012 09:52:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:52:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10949104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:52:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:52:16 +0000
Message-ID: <1330336335.8557.259.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 27 Feb 2012 09:52:15 +0000
In-Reply-To: <CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
	<CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTAyLTIzIGF0IDEzOjM0ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yMiBBbnRob255IExpZ3VvcmkgPGFudGhvbnlAY29kZW1vbmtleS53cz46Cj4g
PiBPbiAwMi8yMC8yMDEyIDA2OjExIEFNLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4KPiA+
PiBSZXBsYWNlIGNsb2NrX2dldHRpbWUgd2l0aCB0aW1lcl9nZXR0aW1lLCBzaW5jZSBhdCBsZWFz
dCB1bmRlcgo+ID4+IHVjbGliYyAwLjkuMzMgdGhlIGNsb2NrX2dldHR0aW1lIGZ1bmN0aW9uIGNh
biBiZSB1c2VkIHdpdGhvdXQgbGlua2luZwo+ID4+IGFnYWluc3QgbGlicnQgKGFsdGhvdWdoIHRo
ZSBtYW51YWwgcGFnZSBzdGF0ZXMgdGhlIG9wcG9zaXRlKS4KPiA+Pgo+ID4+IFNpZ25lZC1vZmYt
Ynk6IFJvZ2VyIFBhdSBNb25uZTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+Cj4gPgo+ID4g
SSBkb24ndCB0aGluayB0aGlzIGlzIGFnYWluc3QgcWVtdS5naXQuICBQbGVhc2UgZG8gbm90IHNl
bmQgcGF0Y2hlcyB0bwo+ID4gcWVtdS1kZXZlbCB0aGF0IGFyZSBub3QgYWdhaW5zdCBxZW11Lmdp
dCB3aXRob3V0IGNsZWFybHkgaW5kaWNhdGluZyB0aGlzLgo+IAo+IFNvcnJ5LCB0aGlzIGlzIGFn
YWluc3QgcWVtdS14ZW4tdXBzdHJlYW0sIHNob3VsZCBJIGFkZCBhIHRhZyB0byBteQo+IHBhdGNo
ZXMgYW5kIHJlc2VuZCB0aGVtIHRvIHFlbXUtZGV2ZWw/CgpxZW11LXhlbi11cHN0cmVhbSBpcyBi
YXNlZCB1cG9uIHRoZSB1cHN0cmVhbSBxZW11IHN0YWJsZSBicmFuY2gsIG5vdCB0aGUKZGV2ZWxv
cG1lbnQgYnJhbmNoLgoKSG93ZXZlciBwYXRjaGVzIGZvciBxZW11LXhlbi11cHN0cmVhbSBzaG91
bGQgaGF2ZSBhbHJlYWR5IGJlZW4gYXBwbGllZAp1cHN0cmVhbS4gVGhpcyBtZWFucyB0aGF0IHBh
dGNoZXMgc2hvdWxkIGJlIGFnYWluc3QgdGhlIG1haW5saW5lIChlLmcuCmRldmVsb3BtZW50IGJy
YW5jaCkgdmVyc2lvbiBvZiBxZW11IGFuZCBzZW50IHRvIHFlbXUtZGV2ZWwuIE9uY2UKY29tbWl0
dGVkIHRoZXJlIHRoZXkgd2lsbCBiZSBiYWNrcG9ydGVkIGFzIHJlcXVpcmVkIHRvIHRoZSBzdGFi
bGUgYnJhbmNoCm1haW50YWluZWQgYnkgWGVuLm9yZyBhcyBxZW11LXhlbi11cHN0cmVhbS4KCihT
dGVmYW5vLCBpcyB0aGF0IGNvcnJlY3Q/IElzIHRoZXJlIHNvbWV3aGVyZSB3ZSBjYW4gKG9yIGRv
ISkgZG9jdW1lbnQKdGhpcz8gUGVyaGFwcyBodHRwOi8vd2lraS54ZW4ub3JnL3hlbndpa2kvUUVN
VVVwc3RyZWFtIGxpbmtlZCB0byBmcm9tClN1Ym1pdHRpbmdfWGVuX1BhdGNoZXM/IFRoZSBiYWNr
cG9ydCBwb2xpY3kgc2hvdWxkIGFsc28gYmUgY292ZXJlZCwgZS5nLgpodHRwOi8vbWFyYy5pbmZv
Lz9sPXhlbi1kZXZlbCZtPTEzMjg3MjAwMTIxODcyNCApCgpJYW4uCgo+IAo+IFRoYW5rcywgUm9n
ZXIuCj4gCj4gPiBSZWdhcmRzLAo+ID4KPiA+IEFudGhvbnkgTGlndW9yaQo+ID4KPiA+Cj4gPj4g
LS0tCj4gPj4gIGNvbmZpZ3VyZSB8ICAgIDMgKystCj4gPj4gIDEgZmlsZXMgY2hhbmdlZCwgMiBp
bnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQo+ID4+Cj4gPj4gZGlmZiAtLWdpdCBhL2NvbmZp
Z3VyZSBiL2NvbmZpZ3VyZQo+ID4+IGluZGV4IDdiY2Q1NDcuLmZiOTk2MzIgMTAwNzU1Cj4gPj4g
LS0tIGEvY29uZmlndXJlCj4gPj4gKysrIGIvY29uZmlndXJlCj4gPj4gQEAgLTI0MzgsNyArMjQz
OCw4IEBAIGZpCj4gPj4gIGNhdD4gICRUTVBDPDxFT0YKPiA+PiAgI2luY2x1ZGU8c2lnbmFsLmg+
Cj4gPj4gICNpbmNsdWRlPHRpbWUuaD4KPiA+PiAtaW50IG1haW4odm9pZCkgeyBjbG9ja2lkX3Qg
aWQ7IHJldHVybiBjbG9ja19nZXR0aW1lKGlkLCBOVUxMKTsgfQo+ID4+ICtpbnQgbWFpbih2b2lk
KSB7IHRpbWVyX3QgdGlkOyBzdHJ1Y3QgaXRpbWVyc3BlYyBpdDsgXAo+ID4+ICsgICAgICAgICAg
ICAgICAgIHJldHVybiB0aW1lcl9nZXR0aW1lKHRpZCwmaXQpOyB9Cj4gPj4gIEVPRgo+ID4+Cj4g
Pj4gIGlmIGNvbXBpbGVfcHJvZyAiIiAiIiA7IHRoZW4KPiA+Cj4gPgo+IAo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcg
bGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:52:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1xFq-0004yv-0X; Mon, 27 Feb 2012 09:52:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1xFn-0004yq-TF
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 09:52:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330336337!9910486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10956 invoked from network); 27 Feb 2012 09:52:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:52:17 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10949104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:52:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:52:16 +0000
Message-ID: <1330336335.8557.259.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 27 Feb 2012 09:52:15 +0000
In-Reply-To: <CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
	<CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTAyLTIzIGF0IDEzOjM0ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yMiBBbnRob255IExpZ3VvcmkgPGFudGhvbnlAY29kZW1vbmtleS53cz46Cj4g
PiBPbiAwMi8yMC8yMDEyIDA2OjExIEFNLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4gPj4KPiA+
PiBSZXBsYWNlIGNsb2NrX2dldHRpbWUgd2l0aCB0aW1lcl9nZXR0aW1lLCBzaW5jZSBhdCBsZWFz
dCB1bmRlcgo+ID4+IHVjbGliYyAwLjkuMzMgdGhlIGNsb2NrX2dldHR0aW1lIGZ1bmN0aW9uIGNh
biBiZSB1c2VkIHdpdGhvdXQgbGlua2luZwo+ID4+IGFnYWluc3QgbGlicnQgKGFsdGhvdWdoIHRo
ZSBtYW51YWwgcGFnZSBzdGF0ZXMgdGhlIG9wcG9zaXRlKS4KPiA+Pgo+ID4+IFNpZ25lZC1vZmYt
Ynk6IFJvZ2VyIFBhdSBNb25uZTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+Cj4gPgo+ID4g
SSBkb24ndCB0aGluayB0aGlzIGlzIGFnYWluc3QgcWVtdS5naXQuICBQbGVhc2UgZG8gbm90IHNl
bmQgcGF0Y2hlcyB0bwo+ID4gcWVtdS1kZXZlbCB0aGF0IGFyZSBub3QgYWdhaW5zdCBxZW11Lmdp
dCB3aXRob3V0IGNsZWFybHkgaW5kaWNhdGluZyB0aGlzLgo+IAo+IFNvcnJ5LCB0aGlzIGlzIGFn
YWluc3QgcWVtdS14ZW4tdXBzdHJlYW0sIHNob3VsZCBJIGFkZCBhIHRhZyB0byBteQo+IHBhdGNo
ZXMgYW5kIHJlc2VuZCB0aGVtIHRvIHFlbXUtZGV2ZWw/CgpxZW11LXhlbi11cHN0cmVhbSBpcyBi
YXNlZCB1cG9uIHRoZSB1cHN0cmVhbSBxZW11IHN0YWJsZSBicmFuY2gsIG5vdCB0aGUKZGV2ZWxv
cG1lbnQgYnJhbmNoLgoKSG93ZXZlciBwYXRjaGVzIGZvciBxZW11LXhlbi11cHN0cmVhbSBzaG91
bGQgaGF2ZSBhbHJlYWR5IGJlZW4gYXBwbGllZAp1cHN0cmVhbS4gVGhpcyBtZWFucyB0aGF0IHBh
dGNoZXMgc2hvdWxkIGJlIGFnYWluc3QgdGhlIG1haW5saW5lIChlLmcuCmRldmVsb3BtZW50IGJy
YW5jaCkgdmVyc2lvbiBvZiBxZW11IGFuZCBzZW50IHRvIHFlbXUtZGV2ZWwuIE9uY2UKY29tbWl0
dGVkIHRoZXJlIHRoZXkgd2lsbCBiZSBiYWNrcG9ydGVkIGFzIHJlcXVpcmVkIHRvIHRoZSBzdGFi
bGUgYnJhbmNoCm1haW50YWluZWQgYnkgWGVuLm9yZyBhcyBxZW11LXhlbi11cHN0cmVhbS4KCihT
dGVmYW5vLCBpcyB0aGF0IGNvcnJlY3Q/IElzIHRoZXJlIHNvbWV3aGVyZSB3ZSBjYW4gKG9yIGRv
ISkgZG9jdW1lbnQKdGhpcz8gUGVyaGFwcyBodHRwOi8vd2lraS54ZW4ub3JnL3hlbndpa2kvUUVN
VVVwc3RyZWFtIGxpbmtlZCB0byBmcm9tClN1Ym1pdHRpbmdfWGVuX1BhdGNoZXM/IFRoZSBiYWNr
cG9ydCBwb2xpY3kgc2hvdWxkIGFsc28gYmUgY292ZXJlZCwgZS5nLgpodHRwOi8vbWFyYy5pbmZv
Lz9sPXhlbi1kZXZlbCZtPTEzMjg3MjAwMTIxODcyNCApCgpJYW4uCgo+IAo+IFRoYW5rcywgUm9n
ZXIuCj4gCj4gPiBSZWdhcmRzLAo+ID4KPiA+IEFudGhvbnkgTGlndW9yaQo+ID4KPiA+Cj4gPj4g
LS0tCj4gPj4gIGNvbmZpZ3VyZSB8ICAgIDMgKystCj4gPj4gIDEgZmlsZXMgY2hhbmdlZCwgMiBp
bnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQo+ID4+Cj4gPj4gZGlmZiAtLWdpdCBhL2NvbmZp
Z3VyZSBiL2NvbmZpZ3VyZQo+ID4+IGluZGV4IDdiY2Q1NDcuLmZiOTk2MzIgMTAwNzU1Cj4gPj4g
LS0tIGEvY29uZmlndXJlCj4gPj4gKysrIGIvY29uZmlndXJlCj4gPj4gQEAgLTI0MzgsNyArMjQz
OCw4IEBAIGZpCj4gPj4gIGNhdD4gICRUTVBDPDxFT0YKPiA+PiAgI2luY2x1ZGU8c2lnbmFsLmg+
Cj4gPj4gICNpbmNsdWRlPHRpbWUuaD4KPiA+PiAtaW50IG1haW4odm9pZCkgeyBjbG9ja2lkX3Qg
aWQ7IHJldHVybiBjbG9ja19nZXR0aW1lKGlkLCBOVUxMKTsgfQo+ID4+ICtpbnQgbWFpbih2b2lk
KSB7IHRpbWVyX3QgdGlkOyBzdHJ1Y3QgaXRpbWVyc3BlYyBpdDsgXAo+ID4+ICsgICAgICAgICAg
ICAgICAgIHJldHVybiB0aW1lcl9nZXR0aW1lKHRpZCwmaXQpOyB9Cj4gPj4gIEVPRgo+ID4+Cj4g
Pj4gIGlmIGNvbXBpbGVfcHJvZyAiIiAiIiA7IHRoZW4KPiA+Cj4gPgo+IAo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcg
bGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1xGU-000524-J7; Mon, 27 Feb 2012 09:53:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1xGT-00051M-01
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:53:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330336377!10847871!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4239 invoked from network); 27 Feb 2012 09:52:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 09:52:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 09:52:57 +0000
Message-Id: <4F4B60850200007800074E83@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 09:52:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
	<1330335268.8557.249.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330335268.8557.249.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"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 qemu-xen-traditional] Fix after blkif.h
	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 27.02.12 at 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> diff --git a/hw/e1000.c b/hw/e1000.c
> index bb3689e..97104ed 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
>              bytes = split_size;
>              if (tp->size + bytes > msh)
>                  bytes = msh - tp->size;
> +
> +            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
>              cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
>              if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
>                  memmove(tp->header, tp->data, hdr);
> @@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
>          // context descriptor TSE is not set, while data descriptor TSE is set
>          DBGOUT(TXERR, "TCP segmentaion Error\n");
>      } else {
> +        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
>          cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
>          tp->size += split_size;
>      }

What are these two changes doing here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1xGU-000524-J7; Mon, 27 Feb 2012 09:53:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1xGT-00051M-01
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:53:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330336377!10847871!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4239 invoked from network); 27 Feb 2012 09:52:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 09:52:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 09:52:57 +0000
Message-Id: <4F4B60850200007800074E83@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 09:52:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
	<1330335268.8557.249.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330335268.8557.249.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"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 qemu-xen-traditional] Fix after blkif.h
	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 27.02.12 at 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> diff --git a/hw/e1000.c b/hw/e1000.c
> index bb3689e..97104ed 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
>              bytes = split_size;
>              if (tp->size + bytes > msh)
>                  bytes = msh - tp->size;
> +
> +            bytes = MIN(sizeof(tp->data) - tp->size, bytes);
>              cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
>              if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
>                  memmove(tp->header, tp->data, hdr);
> @@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
>          // context descriptor TSE is not set, while data descriptor TSE is set
>          DBGOUT(TXERR, "TCP segmentaion Error\n");
>      } else {
> +        split_size = MIN(sizeof(tp->data) - tp->size, split_size);
>          cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
>          tp->size += split_size;
>      }

What are these two changes doing here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:53:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1xGo-00054H-0Y; Mon, 27 Feb 2012 09:53:26 +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 1S1xGm-00053q-GO
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:53:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330336266!50420065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21840 invoked from network); 27 Feb 2012 09:51:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10949146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:53:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:53:23 +0000
Message-ID: <1330336401.8557.260.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 27 Feb 2012 09:53:21 +0000
In-Reply-To: <CB70D835.2C505%keir.xen@gmail.com>
References: <CB70D835.2C505%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
 existing 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 Mon, 2012-02-27 at 06:50 +0000, Keir Fraser wrote:
> On 27/02/2012 06:27, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
> > This patch series attempts to document the blkif PV interface and
> > the various extensions to it that are out in the wild.
> 
> The previous round of these patches was already applied. They are sitting in
> the staging tree currently (http://xenbits.xen.org/staging/xen-unstable.hg).

Note that they are stuck there because they broke the tests. See the
"[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd" thread.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 09:53:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 09: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 1S1xGo-00054H-0Y; Mon, 27 Feb 2012 09:53:26 +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 1S1xGm-00053q-GO
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 09:53:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1330336266!50420065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21840 invoked from network); 27 Feb 2012 09:51:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 09:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10949146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 09:53:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 09:53:23 +0000
Message-ID: <1330336401.8557.260.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 27 Feb 2012 09:53:21 +0000
In-Reply-To: <CB70D835.2C505%keir.xen@gmail.com>
References: <CB70D835.2C505%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
 existing 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 Mon, 2012-02-27 at 06:50 +0000, Keir Fraser wrote:
> On 27/02/2012 06:27, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
> 
> > This patch series attempts to document the blkif PV interface and
> > the various extensions to it that are out in the wild.
> 
> The previous round of these patches was already applied. They are sitting in
> the staging tree currently (http://xenbits.xen.org/staging/xen-unstable.hg).

Note that they are stuck there because they broke the tests. See the
"[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd" thread.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 10:08:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 10:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1xUc-0005WY-K4; Mon, 27 Feb 2012 10:07:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1xUa-0005WO-DF
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 10:07:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330337252!17048598!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12947 invoked from network); 27 Feb 2012 10:07:32 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 10:07:32 -0000
Received: by wibhr2 with SMTP id hr2so666900wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 02:07:31 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr6585800wei.42.1330337251585
	(num_hops = 1); Mon, 27 Feb 2012 02:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=re13Dkh9SiBsQvdtIn+M3CtIwf0vNILgg1ChSjtzMpA=;
	b=XF/aev7euCtAnRwvE9t/6mKjS+LCEVu29uXMqhmLjs98MVZICgTG7jwTbUMqo5NZ62
	xXhc3O9ME7lGwjxrown4eggxgADSJPAe+1SVlvCL7sMxbaC23axKrt3f8q79BtXLSEl2
	w3CA/pBxwBckwHpOedBjRdEVm0hvtIgxkvjvs=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr5229394wei.42.1330337251508; Mon,
	27 Feb 2012 02:07:31 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Mon, 27 Feb 2012 02:07:31 -0800 (PST)
In-Reply-To: <1330336335.8557.259.camel@zakaz.uk.xensource.com>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
	<CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
	<1330336335.8557.259.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 11:07:31 +0100
X-Google-Sender-Auth: qHaHJtDhmuZn7NLLgTaG6wiX0bQ
Message-ID: <CAPLaKK4MoS4ZB_=+2EYxPV8CcYtcM7hrfbHxMKwOqHsL6+4WvA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFRo
dSwgMjAxMi0wMi0yMyBhdCAxMzozNCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8yLzIyIEFudGhvbnkgTGlndW9yaSA8YW50aG9ueUBjb2RlbW9ua2V5LndzPjoKPj4gPiBP
biAwMi8yMC8yMDEyIDA2OjExIEFNLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ID4+Cj4+ID4+
IFJlcGxhY2UgY2xvY2tfZ2V0dGltZSB3aXRoIHRpbWVyX2dldHRpbWUsIHNpbmNlIGF0IGxlYXN0
IHVuZGVyCj4+ID4+IHVjbGliYyAwLjkuMzMgdGhlIGNsb2NrX2dldHR0aW1lIGZ1bmN0aW9uIGNh
biBiZSB1c2VkIHdpdGhvdXQgbGlua2luZwo+PiA+PiBhZ2FpbnN0IGxpYnJ0IChhbHRob3VnaCB0
aGUgbWFudWFsIHBhZ2Ugc3RhdGVzIHRoZSBvcHBvc2l0ZSkuCj4+ID4+Cj4+ID4+IFNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uZTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPgo+PiA+
Cj4+ID4gSSBkb24ndCB0aGluayB0aGlzIGlzIGFnYWluc3QgcWVtdS5naXQuIMKgUGxlYXNlIGRv
IG5vdCBzZW5kIHBhdGNoZXMgdG8KPj4gPiBxZW11LWRldmVsIHRoYXQgYXJlIG5vdCBhZ2FpbnN0
IHFlbXUuZ2l0IHdpdGhvdXQgY2xlYXJseSBpbmRpY2F0aW5nIHRoaXMuCj4+Cj4+IFNvcnJ5LCB0
aGlzIGlzIGFnYWluc3QgcWVtdS14ZW4tdXBzdHJlYW0sIHNob3VsZCBJIGFkZCBhIHRhZyB0byBt
eQo+PiBwYXRjaGVzIGFuZCByZXNlbmQgdGhlbSB0byBxZW11LWRldmVsPwo+Cj4gcWVtdS14ZW4t
dXBzdHJlYW0gaXMgYmFzZWQgdXBvbiB0aGUgdXBzdHJlYW0gcWVtdSBzdGFibGUgYnJhbmNoLCBu
b3QgdGhlCj4gZGV2ZWxvcG1lbnQgYnJhbmNoLgo+Cj4gSG93ZXZlciBwYXRjaGVzIGZvciBxZW11
LXhlbi11cHN0cmVhbSBzaG91bGQgaGF2ZSBhbHJlYWR5IGJlZW4gYXBwbGllZAo+IHVwc3RyZWFt
LiBUaGlzIG1lYW5zIHRoYXQgcGF0Y2hlcyBzaG91bGQgYmUgYWdhaW5zdCB0aGUgbWFpbmxpbmUg
KGUuZy4KPiBkZXZlbG9wbWVudCBicmFuY2gpIHZlcnNpb24gb2YgcWVtdSBhbmQgc2VudCB0byBx
ZW11LWRldmVsLiBPbmNlCj4gY29tbWl0dGVkIHRoZXJlIHRoZXkgd2lsbCBiZSBiYWNrcG9ydGVk
IGFzIHJlcXVpcmVkIHRvIHRoZSBzdGFibGUgYnJhbmNoCj4gbWFpbnRhaW5lZCBieSBYZW4ub3Jn
IGFzIHFlbXUteGVuLXVwc3RyZWFtLgoKT2ssIEknbSBnb2luZyB0byByZXdvcmsgdGhpcyBhZ2Fp
bnN0IHFlbXUgZGV2ZWxvcG1lbnQgYnJhbmNoLCB0aGFua3MKZm9yIHRoZSB0aXAuCgo+IChTdGVm
YW5vLCBpcyB0aGF0IGNvcnJlY3Q/IElzIHRoZXJlIHNvbWV3aGVyZSB3ZSBjYW4gKG9yIGRvISkg
ZG9jdW1lbnQKPiB0aGlzPyBQZXJoYXBzIGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9RRU1V
VXBzdHJlYW0gbGlua2VkIHRvIGZyb20KPiBTdWJtaXR0aW5nX1hlbl9QYXRjaGVzPyBUaGUgYmFj
a3BvcnQgcG9saWN5IHNob3VsZCBhbHNvIGJlIGNvdmVyZWQsIGUuZy4KPiBodHRwOi8vbWFyYy5p
bmZvLz9sPXhlbi1kZXZlbCZtPTEzMjg3MjAwMTIxODcyNCApCj4KPiBJYW4uCj4KPj4KPj4gVGhh
bmtzLCBSb2dlci4KPj4KPj4gPiBSZWdhcmRzLAo+PiA+Cj4+ID4gQW50aG9ueSBMaWd1b3JpCj4+
ID4KPj4gPgo+PiA+PiAtLS0KPj4gPj4gwqBjb25maWd1cmUgfCDCoCDCoDMgKystCj4+ID4+IMKg
MSBmaWxlcyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCj4+ID4+Cj4+
ID4+IGRpZmYgLS1naXQgYS9jb25maWd1cmUgYi9jb25maWd1cmUKPj4gPj4gaW5kZXggN2JjZDU0
Ny4uZmI5OTYzMiAxMDA3NTUKPj4gPj4gLS0tIGEvY29uZmlndXJlCj4+ID4+ICsrKyBiL2NvbmZp
Z3VyZQo+PiA+PiBAQCAtMjQzOCw3ICsyNDM4LDggQEAgZmkKPj4gPj4gwqBjYXQ+IMKgJFRNUEM8
PEVPRgo+PiA+PiDCoCNpbmNsdWRlPHNpZ25hbC5oPgo+PiA+PiDCoCNpbmNsdWRlPHRpbWUuaD4K
Pj4gPj4gLWludCBtYWluKHZvaWQpIHsgY2xvY2tpZF90IGlkOyByZXR1cm4gY2xvY2tfZ2V0dGlt
ZShpZCwgTlVMTCk7IH0KPj4gPj4gK2ludCBtYWluKHZvaWQpIHsgdGltZXJfdCB0aWQ7IHN0cnVj
dCBpdGltZXJzcGVjIGl0OyBcCj4+ID4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0dXJu
IHRpbWVyX2dldHRpbWUodGlkLCZpdCk7IH0KPj4gPj4gwqBFT0YKPj4gPj4KPj4gPj4gwqBpZiBj
b21waWxlX3Byb2cgIiIgIiIgOyB0aGVuCj4+ID4KPj4gPgo+Pgo+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Cj4+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo+Cj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 27 10:08:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 10:08:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1xUc-0005WY-K4; Mon, 27 Feb 2012 10:07:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1xUa-0005WO-DF
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 10:07:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330337252!17048598!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12947 invoked from network); 27 Feb 2012 10:07:32 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 10:07:32 -0000
Received: by wibhr2 with SMTP id hr2so666900wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 02:07:31 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.30 as permitted sender) client-ip=10.216.134.30; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.30 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.30])
	by 10.216.134.30 with SMTP id r30mr6585800wei.42.1330337251585
	(num_hops = 1); Mon, 27 Feb 2012 02:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=re13Dkh9SiBsQvdtIn+M3CtIwf0vNILgg1ChSjtzMpA=;
	b=XF/aev7euCtAnRwvE9t/6mKjS+LCEVu29uXMqhmLjs98MVZICgTG7jwTbUMqo5NZ62
	xXhc3O9ME7lGwjxrown4eggxgADSJPAe+1SVlvCL7sMxbaC23axKrt3f8q79BtXLSEl2
	w3CA/pBxwBckwHpOedBjRdEVm0hvtIgxkvjvs=
MIME-Version: 1.0
Received: by 10.216.134.30 with SMTP id r30mr5229394wei.42.1330337251508; Mon,
	27 Feb 2012 02:07:31 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Mon, 27 Feb 2012 02:07:31 -0800 (PST)
In-Reply-To: <1330336335.8557.259.camel@zakaz.uk.xensource.com>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
	<CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
	<1330336335.8557.259.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 11:07:31 +0100
X-Google-Sender-Auth: qHaHJtDhmuZn7NLLgTaG6wiX0bQ
Message-ID: <CAPLaKK4MoS4ZB_=+2EYxPV8CcYtcM7hrfbHxMKwOqHsL6+4WvA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFRo
dSwgMjAxMi0wMi0yMyBhdCAxMzozNCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8yLzIyIEFudGhvbnkgTGlndW9yaSA8YW50aG9ueUBjb2RlbW9ua2V5LndzPjoKPj4gPiBP
biAwMi8yMC8yMDEyIDA2OjExIEFNLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ID4+Cj4+ID4+
IFJlcGxhY2UgY2xvY2tfZ2V0dGltZSB3aXRoIHRpbWVyX2dldHRpbWUsIHNpbmNlIGF0IGxlYXN0
IHVuZGVyCj4+ID4+IHVjbGliYyAwLjkuMzMgdGhlIGNsb2NrX2dldHR0aW1lIGZ1bmN0aW9uIGNh
biBiZSB1c2VkIHdpdGhvdXQgbGlua2luZwo+PiA+PiBhZ2FpbnN0IGxpYnJ0IChhbHRob3VnaCB0
aGUgbWFudWFsIHBhZ2Ugc3RhdGVzIHRoZSBvcHBvc2l0ZSkuCj4+ID4+Cj4+ID4+IFNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uZTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPgo+PiA+
Cj4+ID4gSSBkb24ndCB0aGluayB0aGlzIGlzIGFnYWluc3QgcWVtdS5naXQuIMKgUGxlYXNlIGRv
IG5vdCBzZW5kIHBhdGNoZXMgdG8KPj4gPiBxZW11LWRldmVsIHRoYXQgYXJlIG5vdCBhZ2FpbnN0
IHFlbXUuZ2l0IHdpdGhvdXQgY2xlYXJseSBpbmRpY2F0aW5nIHRoaXMuCj4+Cj4+IFNvcnJ5LCB0
aGlzIGlzIGFnYWluc3QgcWVtdS14ZW4tdXBzdHJlYW0sIHNob3VsZCBJIGFkZCBhIHRhZyB0byBt
eQo+PiBwYXRjaGVzIGFuZCByZXNlbmQgdGhlbSB0byBxZW11LWRldmVsPwo+Cj4gcWVtdS14ZW4t
dXBzdHJlYW0gaXMgYmFzZWQgdXBvbiB0aGUgdXBzdHJlYW0gcWVtdSBzdGFibGUgYnJhbmNoLCBu
b3QgdGhlCj4gZGV2ZWxvcG1lbnQgYnJhbmNoLgo+Cj4gSG93ZXZlciBwYXRjaGVzIGZvciBxZW11
LXhlbi11cHN0cmVhbSBzaG91bGQgaGF2ZSBhbHJlYWR5IGJlZW4gYXBwbGllZAo+IHVwc3RyZWFt
LiBUaGlzIG1lYW5zIHRoYXQgcGF0Y2hlcyBzaG91bGQgYmUgYWdhaW5zdCB0aGUgbWFpbmxpbmUg
KGUuZy4KPiBkZXZlbG9wbWVudCBicmFuY2gpIHZlcnNpb24gb2YgcWVtdSBhbmQgc2VudCB0byBx
ZW11LWRldmVsLiBPbmNlCj4gY29tbWl0dGVkIHRoZXJlIHRoZXkgd2lsbCBiZSBiYWNrcG9ydGVk
IGFzIHJlcXVpcmVkIHRvIHRoZSBzdGFibGUgYnJhbmNoCj4gbWFpbnRhaW5lZCBieSBYZW4ub3Jn
IGFzIHFlbXUteGVuLXVwc3RyZWFtLgoKT2ssIEknbSBnb2luZyB0byByZXdvcmsgdGhpcyBhZ2Fp
bnN0IHFlbXUgZGV2ZWxvcG1lbnQgYnJhbmNoLCB0aGFua3MKZm9yIHRoZSB0aXAuCgo+IChTdGVm
YW5vLCBpcyB0aGF0IGNvcnJlY3Q/IElzIHRoZXJlIHNvbWV3aGVyZSB3ZSBjYW4gKG9yIGRvISkg
ZG9jdW1lbnQKPiB0aGlzPyBQZXJoYXBzIGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9RRU1V
VXBzdHJlYW0gbGlua2VkIHRvIGZyb20KPiBTdWJtaXR0aW5nX1hlbl9QYXRjaGVzPyBUaGUgYmFj
a3BvcnQgcG9saWN5IHNob3VsZCBhbHNvIGJlIGNvdmVyZWQsIGUuZy4KPiBodHRwOi8vbWFyYy5p
bmZvLz9sPXhlbi1kZXZlbCZtPTEzMjg3MjAwMTIxODcyNCApCj4KPiBJYW4uCj4KPj4KPj4gVGhh
bmtzLCBSb2dlci4KPj4KPj4gPiBSZWdhcmRzLAo+PiA+Cj4+ID4gQW50aG9ueSBMaWd1b3JpCj4+
ID4KPj4gPgo+PiA+PiAtLS0KPj4gPj4gwqBjb25maWd1cmUgfCDCoCDCoDMgKystCj4+ID4+IMKg
MSBmaWxlcyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCj4+ID4+Cj4+
ID4+IGRpZmYgLS1naXQgYS9jb25maWd1cmUgYi9jb25maWd1cmUKPj4gPj4gaW5kZXggN2JjZDU0
Ny4uZmI5OTYzMiAxMDA3NTUKPj4gPj4gLS0tIGEvY29uZmlndXJlCj4+ID4+ICsrKyBiL2NvbmZp
Z3VyZQo+PiA+PiBAQCAtMjQzOCw3ICsyNDM4LDggQEAgZmkKPj4gPj4gwqBjYXQ+IMKgJFRNUEM8
PEVPRgo+PiA+PiDCoCNpbmNsdWRlPHNpZ25hbC5oPgo+PiA+PiDCoCNpbmNsdWRlPHRpbWUuaD4K
Pj4gPj4gLWludCBtYWluKHZvaWQpIHsgY2xvY2tpZF90IGlkOyByZXR1cm4gY2xvY2tfZ2V0dGlt
ZShpZCwgTlVMTCk7IH0KPj4gPj4gK2ludCBtYWluKHZvaWQpIHsgdGltZXJfdCB0aWQ7IHN0cnVj
dCBpdGltZXJzcGVjIGl0OyBcCj4+ID4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0dXJu
IHRpbWVyX2dldHRpbWUodGlkLCZpdCk7IH0KPj4gPj4gwqBFT0YKPj4gPj4KPj4gPj4gwqBpZiBj
b21waWxlX3Byb2cgIiIgIiIgOyB0aGVuCj4+ID4KPj4gPgo+Pgo+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Cj4+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo+Cj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 27 10:26:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 10:26:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1xmb-0005iD-F0; Mon, 27 Feb 2012 10:26:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1xmZ-0005i5-Ae
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 10:26:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330338366!15985823!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29124 invoked from network); 27 Feb 2012 10:26:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 10:26:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 10:00:50 +0000
Message-Id: <4F4B62600200007800074E98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 10:00:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 27.02.12 at 10:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
>>  or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
> 
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.

It's not only the blocking of the test gate: The kind of (unforeseen)
fallout we're having in our own tree should make us ask ourselves
again whether risking to break other people's code (who may have
just followed what we're doing) is worth it. This includes the (bogus
imo, as pointed out before) tying of io/* definitions to particular
__XEN_INTERFACE_VERSION__ values - each I/O interface should
be completely standalone.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 10:26:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 10:26:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1xmb-0005iD-F0; Mon, 27 Feb 2012 10:26:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S1xmZ-0005i5-Ae
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 10:26:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330338366!15985823!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29124 invoked from network); 27 Feb 2012 10:26:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 10:26:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 27 Feb 2012 10:00:50 +0000
Message-Id: <4F4B62600200007800074E98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 27 Feb 2012 10:00:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 27.02.12 at 10:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
>>  or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
> 
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.

It's not only the blocking of the test gate: The kind of (unforeseen)
fallout we're having in our own tree should make us ask ourselves
again whether risking to break other people's code (who may have
just followed what we're doing) is worth it. This includes the (bogus
imo, as pointed out before) tying of io/* definitions to particular
__XEN_INTERFACE_VERSION__ values - each I/O interface should
be completely standalone.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 11:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 11: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 1S1yvw-000653-WD; Mon, 27 Feb 2012 11:40:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S1yvw-00064u-5Y
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 11:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1330342793!8683808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8004 invoked from network); 27 Feb 2012 11:39:54 -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;
	27 Feb 2012 11:39:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10952754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 11:39:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 11:39:53 +0000
Date: Mon, 27 Feb 2012 11:46:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <2D6E03AA-493E-4BF0-9DF0-E233A5B597C4@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202271145380.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
	<alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
	<2D6E03AA-493E-4BF0-9DF0-E233A5B597C4@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 25 Feb 2012, Shriram Rajagopalan wrote:
> On 2012-02-17, at 3:45 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 17 Feb 2012, Shriram Rajagopalan wrote:
> >> 
> >> On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >>      Introduce a new save_id to save/restore toolstack specific extra
> >>      information.
> >> 
> >>      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >> 
> >> 
> >> cc-ing Ian Jackson.
> >> These patches (and other follow ups including mine) have been acked.
> >> Ian, are there any issues blocking these patches ?
> > 
> > The issue are the QEMU side acks. Let me ask them again for feedback.
> > 
> 
> Any update yet ?
>  Or should I respin my patches without the qemu_save part?

I was promised a review last Friday, give few more days please.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 11:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 11: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 1S1yvw-000653-WD; Mon, 27 Feb 2012 11:40:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S1yvw-00064u-5Y
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 11:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1330342793!8683808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8004 invoked from network); 27 Feb 2012 11:39:54 -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;
	27 Feb 2012 11:39:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10952754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 11:39:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 11:39:53 +0000
Date: Mon, 27 Feb 2012 11:46:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <2D6E03AA-493E-4BF0-9DF0-E233A5B597C4@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1202271145380.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202011745320.3196@kaball-desktop>
	<1328119839-1168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPNjA5m-M7M=BLEsJrs2UnFnL-YBiwtbLxrZ2E0PF7ysKQ@mail.gmail.com>
	<alpine.DEB.2.00.1202171144400.7456@kaball-desktop>
	<2D6E03AA-493E-4BF0-9DF0-E233A5B597C4@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/3] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 25 Feb 2012, Shriram Rajagopalan wrote:
> On 2012-02-17, at 3:45 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 17 Feb 2012, Shriram Rajagopalan wrote:
> >> 
> >> On Wed, Feb 1, 2012 at 10:10 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >>      Introduce a new save_id to save/restore toolstack specific extra
> >>      information.
> >> 
> >>      Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >> 
> >> 
> >> cc-ing Ian Jackson.
> >> These patches (and other follow ups including mine) have been acked.
> >> Ian, are there any issues blocking these patches ?
> > 
> > The issue are the QEMU side acks. Let me ask them again for feedback.
> > 
> 
> Any update yet ?
>  Or should I respin my patches without the qemu_save part?

I was promised a review last Friday, give few more days please.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zFc-0006UG-C6; Mon, 27 Feb 2012 12:00:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S1zFa-0006Tv-TY
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:00:19 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330344012!15033482!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29755 invoked from network); 27 Feb 2012 12:00:12 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-3.tower-174.messagelabs.com with SMTP;
	27 Feb 2012 12:00:12 -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 BF34516296
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 12:00:11 +0000 (GMT)
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 XK2lTCDV9i3a for <xen-devel@lists.xen.org>;
	Mon, 27 Feb 2012 12:00:07 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id 72C9016295
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 12:00:07 +0000 (GMT)
Message-ID: <4F4B7047.1080106@abpni.co.uk>
Date: Mon, 27 Feb 2012 12:00:07 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 3.4.4 security 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: multipart/mixed; boundary="===============4860115347204750838=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4860115347204750838==
Content-Type: multipart/alternative;
 boundary="------------080408020202020908060104"

This is a multi-part message in MIME format.
--------------080408020202020908060104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Everyone,

I note that Xen 3.4.4 has been released

http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/

There is something that I am confused about though. In the release 
announcement, it mentions one of the features of the update being:

" Security enhancements includingCVE-2011-1583 
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1583>"

However, the aforementioned CVE seems to only apply to other versions of 
Xen (3.4.x is missing in the list of venerable software)

While I'm obviously happy that the latest release is free of this bug, 
can someone please shed some light on how this bug was fixed in 3.4.4, 
when it wasn't supposed to be present in the first place in 3.4.3?

Also, what other security-related bugs have been fixed? It there a list 
somewhere?

I think it's great that there are members out there willing to maintain 
the 3.4.x branch. It's very stable. Good job folks!

Cheers

--------------080408020202020908060104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Everyone,<br>
    <br>
    I note that Xen 3.4.4 has been released<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/">http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/</a><br>
    <br>
    There is something that I am confused about though. In the release
    announcement, it mentions one of the features of the update being:<br>
    <br>
    "
    <meta charset="utf-8">
    Security enhancements including<span class="Apple-converted-space">&nbsp;</span><a
href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1583"
      style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px;
      margin-left: 0px; padding-top: 0px; padding-right: 0px;
      padding-bottom: 0px; padding-left: 0px; border-top-width: 0px;
      border-right-width: 0px; border-bottom-width: 0px;
      border-left-width: 0px; border-style: initial; border-color:
      initial; border-image: initial; outline-width: 0px; outline-style:
      initial; outline-color: initial; font-size: 12px; vertical-align:
      baseline; background-image: initial; background-attachment:
      initial; background-origin: initial; background-clip: initial;
      background-color: transparent; color: rgb(160, 0, 4);
      text-decoration: none; background-position: initial initial;
      background-repeat: initial initial; ">CVE-2011-1583</a>"<br>
    <br>
    However, the aforementioned CVE seems to only apply to other
    versions of Xen (3.4.x is missing in the list of venerable software)<br>
    <br>
    While I'm obviously happy that the latest release is free of this
    bug, can someone please shed some light on how this bug was fixed in
    3.4.4, when it wasn't supposed to be present in the first place in
    3.4.3?<br>
    <br>
    Also, what other security-related bugs have been fixed? It there a
    list somewhere?<br>
    <br>
    I think it's great that there are members out there willing to
    maintain the 3.4.x branch. It's very stable. Good job folks!<br>
    <br>
    Cheers<br class="Apple-interchange-newline">
  </body>
</html>

--------------080408020202020908060104--


--===============4860115347204750838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4860115347204750838==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 12:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zFc-0006UG-C6; Mon, 27 Feb 2012 12:00:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S1zFa-0006Tv-TY
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:00:19 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330344012!15033482!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29755 invoked from network); 27 Feb 2012 12:00:12 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-3.tower-174.messagelabs.com with SMTP;
	27 Feb 2012 12:00:12 -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 BF34516296
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 12:00:11 +0000 (GMT)
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 XK2lTCDV9i3a for <xen-devel@lists.xen.org>;
	Mon, 27 Feb 2012 12:00:07 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id 72C9016295
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 12:00:07 +0000 (GMT)
Message-ID: <4F4B7047.1080106@abpni.co.uk>
Date: Mon, 27 Feb 2012 12:00:07 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 3.4.4 security 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: multipart/mixed; boundary="===============4860115347204750838=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4860115347204750838==
Content-Type: multipart/alternative;
 boundary="------------080408020202020908060104"

This is a multi-part message in MIME format.
--------------080408020202020908060104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Everyone,

I note that Xen 3.4.4 has been released

http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/

There is something that I am confused about though. In the release 
announcement, it mentions one of the features of the update being:

" Security enhancements includingCVE-2011-1583 
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1583>"

However, the aforementioned CVE seems to only apply to other versions of 
Xen (3.4.x is missing in the list of venerable software)

While I'm obviously happy that the latest release is free of this bug, 
can someone please shed some light on how this bug was fixed in 3.4.4, 
when it wasn't supposed to be present in the first place in 3.4.3?

Also, what other security-related bugs have been fixed? It there a list 
somewhere?

I think it's great that there are members out there willing to maintain 
the 3.4.x branch. It's very stable. Good job folks!

Cheers

--------------080408020202020908060104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Everyone,<br>
    <br>
    I note that Xen 3.4.4 has been released<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/">http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/</a><br>
    <br>
    There is something that I am confused about though. In the release
    announcement, it mentions one of the features of the update being:<br>
    <br>
    "
    <meta charset="utf-8">
    Security enhancements including<span class="Apple-converted-space">&nbsp;</span><a
href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1583"
      style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px;
      margin-left: 0px; padding-top: 0px; padding-right: 0px;
      padding-bottom: 0px; padding-left: 0px; border-top-width: 0px;
      border-right-width: 0px; border-bottom-width: 0px;
      border-left-width: 0px; border-style: initial; border-color:
      initial; border-image: initial; outline-width: 0px; outline-style:
      initial; outline-color: initial; font-size: 12px; vertical-align:
      baseline; background-image: initial; background-attachment:
      initial; background-origin: initial; background-clip: initial;
      background-color: transparent; color: rgb(160, 0, 4);
      text-decoration: none; background-position: initial initial;
      background-repeat: initial initial; ">CVE-2011-1583</a>"<br>
    <br>
    However, the aforementioned CVE seems to only apply to other
    versions of Xen (3.4.x is missing in the list of venerable software)<br>
    <br>
    While I'm obviously happy that the latest release is free of this
    bug, can someone please shed some light on how this bug was fixed in
    3.4.4, when it wasn't supposed to be present in the first place in
    3.4.3?<br>
    <br>
    Also, what other security-related bugs have been fixed? It there a
    list somewhere?<br>
    <br>
    I think it's great that there are members out there willing to
    maintain the 3.4.x branch. It's very stable. Good job folks!<br>
    <br>
    Cheers<br class="Apple-interchange-newline">
  </body>
</html>

--------------080408020202020908060104--


--===============4860115347204750838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4860115347204750838==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 12:07:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zMQ-0006lq-DI; Mon, 27 Feb 2012 12:07:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1zMP-0006lb-0H
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:07:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330344433!16548001!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 890 invoked from network); 27 Feb 2012 12:07:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:07:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325480400"; d="scan'208";a="183508588"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 07:07:12 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 07:07:11 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S1zMF-0001SJ-IF;
	Mon, 27 Feb 2012 12:07:11 +0000
MIME-Version: 1.0
X-Mercurial-Node: 31eb9ee09b726bfab1df49580f024693f4f307ae
Message-ID: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 27 Feb 2012 12:07:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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 1330344234 0
# Node ID 31eb9ee09b726bfab1df49580f024693f4f307ae
# Parent  71159fb049f253030c3820c260d092d4aec6b166
hcall: markup the event channel hypercalls to improve generated docs

As part of this I looked through the relevant chapter from interfaces.tex (from
4.1, deleted in unstable) to ensure no critical information was missing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 71159fb049f2 -r 31eb9ee09b72 xen/include/public/event_channel.h
--- a/xen/include/public/event_channel.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/event_channel.h	Mon Feb 27 12:03:54 2012 +0000
@@ -1,8 +1,8 @@
 /******************************************************************************
  * event_channel.h
- * 
+ *
  * Event channels between domains.
- * 
+ *
  * 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,12 +30,27 @@
 #include "xen.h"
 
 /*
- * Prototype for this hypercall is:
- *  int event_channel_op(int cmd, void *args)
- * @cmd  == EVTCHNOP_??? (event-channel operation).
- * @args == Operation-specific extra arguments (NULL if none).
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
+ * `
+ * @cmd  == EVTCHNOP_* (event-channel operation).
+ * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
  */
 
+/* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
+#define EVTCHNOP_bind_interdomain 0
+#define EVTCHNOP_bind_virq        1
+#define EVTCHNOP_bind_pirq        2
+#define EVTCHNOP_close            3
+#define EVTCHNOP_send             4
+#define EVTCHNOP_status           5
+#define EVTCHNOP_alloc_unbound    6
+#define EVTCHNOP_bind_ipi         7
+#define EVTCHNOP_bind_vcpu        8
+#define EVTCHNOP_unmask           9
+#define EVTCHNOP_reset           10
+/* ` } */
+
 typedef uint32_t evtchn_port_t;
 DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
 
@@ -47,7 +62,6 @@ DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
  *  1. If the caller is unprivileged then <dom> must be DOMID_SELF.
  *  2. <rdom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_alloc_unbound    6
 struct evtchn_alloc_unbound {
     /* IN parameters */
     domid_t dom, remote_dom;
@@ -63,9 +77,8 @@ typedef struct evtchn_alloc_unbound evtc
  * domain. A fresh port is allocated in the calling domain and returned as
  * <local_port>.
  * NOTES:
- *  2. <remote_dom> may be DOMID_SELF, allowing loopback connections.
+ *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_bind_interdomain 0
 struct evtchn_bind_interdomain {
     /* IN parameters. */
     domid_t remote_dom;
@@ -87,10 +100,9 @@ typedef struct evtchn_bind_interdomain e
  *     The allocated event channel is bound to the specified vcpu and the
  *     binding cannot be changed.
  */
-#define EVTCHNOP_bind_virq        1
 struct evtchn_bind_virq {
     /* IN parameters. */
-    uint32_t virq;
+    uint32_t virq; /* enum virq */
     uint32_t vcpu;
     /* OUT parameters. */
     evtchn_port_t port;
@@ -98,12 +110,11 @@ struct evtchn_bind_virq {
 typedef struct evtchn_bind_virq evtchn_bind_virq_t;
 
 /*
- * EVTCHNOP_bind_pirq: Bind a local event channel to PIRQ <irq>.
+ * EVTCHNOP_bind_pirq: Bind a local event channel to a real IRQ (PIRQ <irq>).
  * NOTES:
  *  1. A physical IRQ may be bound to at most one event channel per domain.
  *  2. Only a sufficiently-privileged domain may bind to a physical IRQ.
  */
-#define EVTCHNOP_bind_pirq        2
 struct evtchn_bind_pirq {
     /* IN parameters. */
     uint32_t pirq;
@@ -120,7 +131,6 @@ typedef struct evtchn_bind_pirq evtchn_b
  *  1. The allocated event channel is bound to the specified vcpu. The binding
  *     may not be changed.
  */
-#define EVTCHNOP_bind_ipi         7
 struct evtchn_bind_ipi {
     uint32_t vcpu;
     /* OUT parameters. */
@@ -133,7 +143,6 @@ typedef struct evtchn_bind_ipi evtchn_bi
  * interdomain then the remote end is placed in the unbound state
  * (EVTCHNSTAT_unbound), awaiting a new connection.
  */
-#define EVTCHNOP_close            3
 struct evtchn_close {
     /* IN parameters. */
     evtchn_port_t port;
@@ -144,7 +153,6 @@ typedef struct evtchn_close evtchn_close
  * EVTCHNOP_send: Send an event to the remote end of the channel whose local
  * endpoint is <port>.
  */
-#define EVTCHNOP_send             4
 struct evtchn_send {
     /* IN parameters. */
     evtchn_port_t port;
@@ -159,7 +167,6 @@ typedef struct evtchn_send evtchn_send_t
  *  2. Only a sufficiently-privileged domain may obtain the status of an event
  *     channel for which <dom> is not DOMID_SELF.
  */
-#define EVTCHNOP_status           5
 struct evtchn_status {
     /* IN parameters */
     domid_t  dom;
@@ -176,13 +183,13 @@ struct evtchn_status {
     union {
         struct {
             domid_t dom;
-        } unbound; /* EVTCHNSTAT_unbound */
+        } unbound;                 /* EVTCHNSTAT_unbound */
         struct {
             domid_t dom;
             evtchn_port_t port;
-        } interdomain; /* EVTCHNSTAT_interdomain */
-        uint32_t pirq;      /* EVTCHNSTAT_pirq        */
-        uint32_t virq;      /* EVTCHNSTAT_virq        */
+        } interdomain;             /* EVTCHNSTAT_interdomain */
+        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
+        uint32_t virq;             /* EVTCHNSTAT_virq        */
     } u;
 };
 typedef struct evtchn_status evtchn_status_t;
@@ -199,7 +206,6 @@ typedef struct evtchn_status evtchn_stat
  *     the channel is allocated (a port that is freed and subsequently reused
  *     has its binding reset to vcpu0).
  */
-#define EVTCHNOP_bind_vcpu        8
 struct evtchn_bind_vcpu {
     /* IN parameters. */
     evtchn_port_t port;
@@ -211,7 +217,6 @@ typedef struct evtchn_bind_vcpu evtchn_b
  * EVTCHNOP_unmask: Unmask the specified local event-channel port and deliver
  * a notification to the appropriate VCPU if an event is pending.
  */
-#define EVTCHNOP_unmask           9
 struct evtchn_unmask {
     /* IN parameters. */
     evtchn_port_t port;
@@ -224,7 +229,6 @@ typedef struct evtchn_unmask evtchn_unma
  *  1. <dom> may be specified as DOMID_SELF.
  *  2. Only a sufficiently-privileged domain may specify other than DOMID_SELF.
  */
-#define EVTCHNOP_reset           10
 struct evtchn_reset {
     /* IN parameters. */
     domid_t dom;
@@ -232,11 +236,13 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
- * Argument to event_channel_op_compat() hypercall. Superceded by new
- * event_channel_op() hypercall since 0x00030202.
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
+ * `
+ * Superceded by new event_channel_op() hypercall since 0x00030202.
  */
 struct evtchn_op {
-    uint32_t cmd; /* EVTCHNOP_* */
+    uint32_t cmd; /* enum event_channel_op */
     union {
         struct evtchn_alloc_unbound    alloc_unbound;
         struct evtchn_bind_interdomain bind_interdomain;
diff -r 71159fb049f2 -r 31eb9ee09b72 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/xen.h	Mon Feb 27 12:03:54 2012 +0000
@@ -146,6 +146,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * The latter can be allocated only once per guest: they must initially be
  * allocated to VCPU0 but can subsequently be re-bound.
  */
+/* ` enum virq { */
 #define VIRQ_TIMER      0  /* V. Timebase update, and/or requested timeout.  */
 #define VIRQ_DEBUG      1  /* V. Request guest to dump debug info.           */
 #define VIRQ_CONSOLE    2  /* G. (DOM0) Bytes received on emergency console. */
@@ -167,6 +168,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_ARCH_5    21
 #define VIRQ_ARCH_6    22
 #define VIRQ_ARCH_7    23
+/* ` } */
 
 #define NR_VIRQS       24
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:07:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zMQ-0006lq-DI; Mon, 27 Feb 2012 12:07:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1zMP-0006lb-0H
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:07:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330344433!16548001!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 890 invoked from network); 27 Feb 2012 12:07:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:07:14 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325480400"; d="scan'208";a="183508588"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 07:07:12 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 07:07:11 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S1zMF-0001SJ-IF;
	Mon, 27 Feb 2012 12:07:11 +0000
MIME-Version: 1.0
X-Mercurial-Node: 31eb9ee09b726bfab1df49580f024693f4f307ae
Message-ID: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 27 Feb 2012 12:07:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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 1330344234 0
# Node ID 31eb9ee09b726bfab1df49580f024693f4f307ae
# Parent  71159fb049f253030c3820c260d092d4aec6b166
hcall: markup the event channel hypercalls to improve generated docs

As part of this I looked through the relevant chapter from interfaces.tex (from
4.1, deleted in unstable) to ensure no critical information was missing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 71159fb049f2 -r 31eb9ee09b72 xen/include/public/event_channel.h
--- a/xen/include/public/event_channel.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/event_channel.h	Mon Feb 27 12:03:54 2012 +0000
@@ -1,8 +1,8 @@
 /******************************************************************************
  * event_channel.h
- * 
+ *
  * Event channels between domains.
- * 
+ *
  * 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,12 +30,27 @@
 #include "xen.h"
 
 /*
- * Prototype for this hypercall is:
- *  int event_channel_op(int cmd, void *args)
- * @cmd  == EVTCHNOP_??? (event-channel operation).
- * @args == Operation-specific extra arguments (NULL if none).
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
+ * `
+ * @cmd  == EVTCHNOP_* (event-channel operation).
+ * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
  */
 
+/* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
+#define EVTCHNOP_bind_interdomain 0
+#define EVTCHNOP_bind_virq        1
+#define EVTCHNOP_bind_pirq        2
+#define EVTCHNOP_close            3
+#define EVTCHNOP_send             4
+#define EVTCHNOP_status           5
+#define EVTCHNOP_alloc_unbound    6
+#define EVTCHNOP_bind_ipi         7
+#define EVTCHNOP_bind_vcpu        8
+#define EVTCHNOP_unmask           9
+#define EVTCHNOP_reset           10
+/* ` } */
+
 typedef uint32_t evtchn_port_t;
 DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
 
@@ -47,7 +62,6 @@ DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
  *  1. If the caller is unprivileged then <dom> must be DOMID_SELF.
  *  2. <rdom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_alloc_unbound    6
 struct evtchn_alloc_unbound {
     /* IN parameters */
     domid_t dom, remote_dom;
@@ -63,9 +77,8 @@ typedef struct evtchn_alloc_unbound evtc
  * domain. A fresh port is allocated in the calling domain and returned as
  * <local_port>.
  * NOTES:
- *  2. <remote_dom> may be DOMID_SELF, allowing loopback connections.
+ *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_bind_interdomain 0
 struct evtchn_bind_interdomain {
     /* IN parameters. */
     domid_t remote_dom;
@@ -87,10 +100,9 @@ typedef struct evtchn_bind_interdomain e
  *     The allocated event channel is bound to the specified vcpu and the
  *     binding cannot be changed.
  */
-#define EVTCHNOP_bind_virq        1
 struct evtchn_bind_virq {
     /* IN parameters. */
-    uint32_t virq;
+    uint32_t virq; /* enum virq */
     uint32_t vcpu;
     /* OUT parameters. */
     evtchn_port_t port;
@@ -98,12 +110,11 @@ struct evtchn_bind_virq {
 typedef struct evtchn_bind_virq evtchn_bind_virq_t;
 
 /*
- * EVTCHNOP_bind_pirq: Bind a local event channel to PIRQ <irq>.
+ * EVTCHNOP_bind_pirq: Bind a local event channel to a real IRQ (PIRQ <irq>).
  * NOTES:
  *  1. A physical IRQ may be bound to at most one event channel per domain.
  *  2. Only a sufficiently-privileged domain may bind to a physical IRQ.
  */
-#define EVTCHNOP_bind_pirq        2
 struct evtchn_bind_pirq {
     /* IN parameters. */
     uint32_t pirq;
@@ -120,7 +131,6 @@ typedef struct evtchn_bind_pirq evtchn_b
  *  1. The allocated event channel is bound to the specified vcpu. The binding
  *     may not be changed.
  */
-#define EVTCHNOP_bind_ipi         7
 struct evtchn_bind_ipi {
     uint32_t vcpu;
     /* OUT parameters. */
@@ -133,7 +143,6 @@ typedef struct evtchn_bind_ipi evtchn_bi
  * interdomain then the remote end is placed in the unbound state
  * (EVTCHNSTAT_unbound), awaiting a new connection.
  */
-#define EVTCHNOP_close            3
 struct evtchn_close {
     /* IN parameters. */
     evtchn_port_t port;
@@ -144,7 +153,6 @@ typedef struct evtchn_close evtchn_close
  * EVTCHNOP_send: Send an event to the remote end of the channel whose local
  * endpoint is <port>.
  */
-#define EVTCHNOP_send             4
 struct evtchn_send {
     /* IN parameters. */
     evtchn_port_t port;
@@ -159,7 +167,6 @@ typedef struct evtchn_send evtchn_send_t
  *  2. Only a sufficiently-privileged domain may obtain the status of an event
  *     channel for which <dom> is not DOMID_SELF.
  */
-#define EVTCHNOP_status           5
 struct evtchn_status {
     /* IN parameters */
     domid_t  dom;
@@ -176,13 +183,13 @@ struct evtchn_status {
     union {
         struct {
             domid_t dom;
-        } unbound; /* EVTCHNSTAT_unbound */
+        } unbound;                 /* EVTCHNSTAT_unbound */
         struct {
             domid_t dom;
             evtchn_port_t port;
-        } interdomain; /* EVTCHNSTAT_interdomain */
-        uint32_t pirq;      /* EVTCHNSTAT_pirq        */
-        uint32_t virq;      /* EVTCHNSTAT_virq        */
+        } interdomain;             /* EVTCHNSTAT_interdomain */
+        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
+        uint32_t virq;             /* EVTCHNSTAT_virq        */
     } u;
 };
 typedef struct evtchn_status evtchn_status_t;
@@ -199,7 +206,6 @@ typedef struct evtchn_status evtchn_stat
  *     the channel is allocated (a port that is freed and subsequently reused
  *     has its binding reset to vcpu0).
  */
-#define EVTCHNOP_bind_vcpu        8
 struct evtchn_bind_vcpu {
     /* IN parameters. */
     evtchn_port_t port;
@@ -211,7 +217,6 @@ typedef struct evtchn_bind_vcpu evtchn_b
  * EVTCHNOP_unmask: Unmask the specified local event-channel port and deliver
  * a notification to the appropriate VCPU if an event is pending.
  */
-#define EVTCHNOP_unmask           9
 struct evtchn_unmask {
     /* IN parameters. */
     evtchn_port_t port;
@@ -224,7 +229,6 @@ typedef struct evtchn_unmask evtchn_unma
  *  1. <dom> may be specified as DOMID_SELF.
  *  2. Only a sufficiently-privileged domain may specify other than DOMID_SELF.
  */
-#define EVTCHNOP_reset           10
 struct evtchn_reset {
     /* IN parameters. */
     domid_t dom;
@@ -232,11 +236,13 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
- * Argument to event_channel_op_compat() hypercall. Superceded by new
- * event_channel_op() hypercall since 0x00030202.
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
+ * `
+ * Superceded by new event_channel_op() hypercall since 0x00030202.
  */
 struct evtchn_op {
-    uint32_t cmd; /* EVTCHNOP_* */
+    uint32_t cmd; /* enum event_channel_op */
     union {
         struct evtchn_alloc_unbound    alloc_unbound;
         struct evtchn_bind_interdomain bind_interdomain;
diff -r 71159fb049f2 -r 31eb9ee09b72 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/xen.h	Mon Feb 27 12:03:54 2012 +0000
@@ -146,6 +146,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * The latter can be allocated only once per guest: they must initially be
  * allocated to VCPU0 but can subsequently be re-bound.
  */
+/* ` enum virq { */
 #define VIRQ_TIMER      0  /* V. Timebase update, and/or requested timeout.  */
 #define VIRQ_DEBUG      1  /* V. Request guest to dump debug info.           */
 #define VIRQ_CONSOLE    2  /* G. (DOM0) Bytes received on emergency console. */
@@ -167,6 +168,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_ARCH_5    21
 #define VIRQ_ARCH_6    22
 #define VIRQ_ARCH_7    23
+/* ` } */
 
 #define NR_VIRQS       24
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zO2-0006s1-TI; Mon, 27 Feb 2012 12:09:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1zO1-0006rr-OW
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:09:01 +0000
Received: from [85.158.139.83:7747] by server-3.bemta-5.messagelabs.com id
	5F/56-06438-C527B4F4; Mon, 27 Feb 2012 12:09:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1330344540!14144207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25388 invoked from network); 27 Feb 2012 12:09:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:09:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10953482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 12:09:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 12:09:00 +0000
Message-ID: <1330344538.8557.280.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Date: Mon, 27 Feb 2012 12:08:58 +0000
In-Reply-To: <4F4B7047.1080106@abpni.co.uk>
References: <4F4B7047.1080106@abpni.co.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.4 security 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, 2012-02-27 at 12:00 +0000, Jonathan Tripathy wrote:
> " Security enhancements including CVE-2011-1583"
> 
> However, the aforementioned CVE seems to only apply to other versions
> of Xen (3.4.x is missing in the list of venerable software)
> 
> While I'm obviously happy that the latest release is free of this bug,
> can someone please shed some light on how this bug was fixed in 3.4.4,
> when it wasn't supposed to be present in the first place in 3.4.3?

Given that 3.3 and 4.0 were vulnerable I think this is simply a case of
3.4 being accidentally omitted from the list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zO2-0006s1-TI; Mon, 27 Feb 2012 12:09:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S1zO1-0006rr-OW
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:09:01 +0000
Received: from [85.158.139.83:7747] by server-3.bemta-5.messagelabs.com id
	5F/56-06438-C527B4F4; Mon, 27 Feb 2012 12:09:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1330344540!14144207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25388 invoked from network); 27 Feb 2012 12:09:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:09:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10953482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 12:09:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 12:09:00 +0000
Message-ID: <1330344538.8557.280.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Date: Mon, 27 Feb 2012 12:08:58 +0000
In-Reply-To: <4F4B7047.1080106@abpni.co.uk>
References: <4F4B7047.1080106@abpni.co.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.4 security 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, 2012-02-27 at 12:00 +0000, Jonathan Tripathy wrote:
> " Security enhancements including CVE-2011-1583"
> 
> However, the aforementioned CVE seems to only apply to other versions
> of Xen (3.4.x is missing in the list of venerable software)
> 
> While I'm obviously happy that the latest release is free of this bug,
> can someone please shed some light on how this bug was fixed in 3.4.4,
> when it wasn't supposed to be present in the first place in 3.4.3?

Given that 3.3 and 4.0 were vulnerable I think this is simply a case of
3.4 being accidentally omitted from the list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:12:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1zQq-00072E-Gm; Mon, 27 Feb 2012 12:11:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S1zQp-00071x-4V
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:11:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330344706!10859223!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10575 invoked from network); 27 Feb 2012 12:11:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:11:47 -0000
Received: by werm1 with SMTP id m1so499158wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 04:11:46 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.97.130 as permitted sender) client-ip=10.180.97.130; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.97.130 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.97.130])
	by 10.180.97.130 with SMTP id ea2mr27114690wib.20.1330344706606
	(num_hops = 1); Mon, 27 Feb 2012 04:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=uK8evDk1+NO7SM3BCHGmvoI1uXTYPiKEUt+4DHIe3TA=;
	b=DiMRcmeYZPACbMRDXsRg1tzRYWCcq9VSXVSMCSKeEB6NZAsgK62RHMfgncNMU7/Eh2
	tv7GgkwQeXV66adfDy9pkSY8dNvZK8QeW5XN7VLEo6z04UBIyOmfz88ZP82H3uOXLsoF
	GEw5OzZjkT+ZBf8hnGWovqV5PqL47E4qNPY2M=
Received: by 10.180.97.130 with SMTP id ea2mr21528618wib.20.1330344706425;
	Mon, 27 Feb 2012 04:11:46 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id bg3sm21493101wib.10.2012.02.27.04.11.43
	(version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 04:11:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 12:11:39 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB71237B.2C5A0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-amd
Thread-Index: Acz1SPVfdqNH84L5lkyjzu/lATUTFw==
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 27/02/2012 09:32, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>  or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
> 
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.

I reverted it for now at least. Perhaps it makes sense to do this with a new
macro name, as Jan suggested.

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:12:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1zQq-00072E-Gm; Mon, 27 Feb 2012 12:11:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S1zQp-00071x-4V
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:11:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330344706!10859223!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10575 invoked from network); 27 Feb 2012 12:11:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:11:47 -0000
Received: by werm1 with SMTP id m1so499158wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 04:11:46 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.97.130 as permitted sender) client-ip=10.180.97.130; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.97.130 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.97.130])
	by 10.180.97.130 with SMTP id ea2mr27114690wib.20.1330344706606
	(num_hops = 1); Mon, 27 Feb 2012 04:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=uK8evDk1+NO7SM3BCHGmvoI1uXTYPiKEUt+4DHIe3TA=;
	b=DiMRcmeYZPACbMRDXsRg1tzRYWCcq9VSXVSMCSKeEB6NZAsgK62RHMfgncNMU7/Eh2
	tv7GgkwQeXV66adfDy9pkSY8dNvZK8QeW5XN7VLEo6z04UBIyOmfz88ZP82H3uOXLsoF
	GEw5OzZjkT+ZBf8hnGWovqV5PqL47E4qNPY2M=
Received: by 10.180.97.130 with SMTP id ea2mr21528618wib.20.1330344706425;
	Mon, 27 Feb 2012 04:11:46 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id bg3sm21493101wib.10.2012.02.27.04.11.43
	(version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 04:11:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 12:11:39 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB71237B.2C5A0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-amd
Thread-Index: Acz1SPVfdqNH84L5lkyjzu/lATUTFw==
In-Reply-To: <1330335129.8557.247.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "Justin T. Gibbs" <justing@spectralogic.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-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 27/02/2012 09:32, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>  or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
> 
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.

I reverted it for now at least. Perhaps it makes sense to do this with a new
macro name, as Jan suggested.

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zY5-0007aa-9U; Mon, 27 Feb 2012 12:19:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1zY3-0007aL-Ng
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:19:23 +0000
Received: from [85.158.139.83:37726] by server-11.bemta-5.messagelabs.com id
	FB/55-14397-BC47B4F4; Mon, 27 Feb 2012 12:19:23 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330345162!16785290!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29513 invoked from network); 27 Feb 2012 12:19:22 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:19:22 -0000
Received: by wibhr2 with SMTP id hr2so765629wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 04:19:22 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.109.193 as permitted sender) client-ip=10.180.109.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.109.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.109.193])
	by 10.180.109.193 with SMTP id hu1mr18454058wib.17.1330345162255
	(num_hops = 1); Mon, 27 Feb 2012 04:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=am4eXW16lnBB9FmHBwur6DPJw8OM+jMGal5RT4qtFsQ=;
	b=q3ibBRwoR8gSPmgikHUIxY+fnMiKcOAIehYQkMQx86P7EDjWw0ld+a6uZYS9kVC17M
	2FJoewVGg63SQsv7WxTQllGs5HqmcRvpmCnSeEW/1+irfmi2B0nxGKrov6N46/ktrrF+
	x0jeA5mZ7xARhvGaI9BMR0A15DaKvq4miezFQ=
Received: by 10.180.109.193 with SMTP id hu1mr14570670wib.17.1330345162211;
	Mon, 27 Feb 2012 04:19:22 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54328096wib.10.2012.02.27.04.19.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 04:19:21 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org, qemu-devel@nongnu.org,
	stefano.stabellini@citrix.com
Date: Tue, 21 Feb 2012 20:14:38 +0100
Message-Id: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 1/3] build: replace librt check 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

Replace clock_gettime with timer_gettime, since at least under
uclibc 0.9.33 the clock_getttime function can be used without linking
against librt (although the manual page states the opposite).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 configure |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index f9d5330..68eb3fa 100755
--- a/configure
+++ b/configure
@@ -2513,7 +2513,8 @@ fi
 cat > $TMPC <<EOF
 #include <signal.h>
 #include <time.h>
-int main(void) { return clock_gettime(CLOCK_REALTIME, NULL); }
+int main(void) { timer_t tid; struct itimerspec it; \
+                 return timer_gettime(tid, &it); }
 EOF
 
 if compile_prog "" "" ; then
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zY5-0007aa-9U; Mon, 27 Feb 2012 12:19:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1zY3-0007aL-Ng
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:19:23 +0000
Received: from [85.158.139.83:37726] by server-11.bemta-5.messagelabs.com id
	FB/55-14397-BC47B4F4; Mon, 27 Feb 2012 12:19:23 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330345162!16785290!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29513 invoked from network); 27 Feb 2012 12:19:22 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:19:22 -0000
Received: by wibhr2 with SMTP id hr2so765629wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 04:19:22 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.109.193 as permitted sender) client-ip=10.180.109.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.109.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.109.193])
	by 10.180.109.193 with SMTP id hu1mr18454058wib.17.1330345162255
	(num_hops = 1); Mon, 27 Feb 2012 04:19:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=am4eXW16lnBB9FmHBwur6DPJw8OM+jMGal5RT4qtFsQ=;
	b=q3ibBRwoR8gSPmgikHUIxY+fnMiKcOAIehYQkMQx86P7EDjWw0ld+a6uZYS9kVC17M
	2FJoewVGg63SQsv7WxTQllGs5HqmcRvpmCnSeEW/1+irfmi2B0nxGKrov6N46/ktrrF+
	x0jeA5mZ7xARhvGaI9BMR0A15DaKvq4miezFQ=
Received: by 10.180.109.193 with SMTP id hu1mr14570670wib.17.1330345162211;
	Mon, 27 Feb 2012 04:19:22 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54328096wib.10.2012.02.27.04.19.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 04:19:21 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org, qemu-devel@nongnu.org,
	stefano.stabellini@citrix.com
Date: Tue, 21 Feb 2012 20:14:38 +0100
Message-Id: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 1/3] build: replace librt check 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

Replace clock_gettime with timer_gettime, since at least under
uclibc 0.9.33 the clock_getttime function can be used without linking
against librt (although the manual page states the opposite).

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 configure |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index f9d5330..68eb3fa 100755
--- a/configure
+++ b/configure
@@ -2513,7 +2513,8 @@ fi
 cat > $TMPC <<EOF
 #include <signal.h>
 #include <time.h>
-int main(void) { return clock_gettime(CLOCK_REALTIME, NULL); }
+int main(void) { timer_t tid; struct itimerspec it; \
+                 return timer_gettime(tid, &it); }
 EOF
 
 if compile_prog "" "" ; then
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zYA-0007bJ-Mk; Mon, 27 Feb 2012 12:19:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1zY9-0007aP-C3
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330345163!15106443!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=4.0 required=7.0 tests=DATE_IN_PAST_96_XX,
	RCVD_BY_IP,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24069 invoked from network); 27 Feb 2012 12:19:23 -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;
	27 Feb 2012 12:19:23 -0000
Received: by werp12 with SMTP id p12so1184649wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.80.8 as permitted sender) client-ip=10.180.80.8; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.80.8 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.80.8])
	by 10.180.80.8 with SMTP id n8mr27529643wix.14.1330345163105 (num_hops
	= 1); Mon, 27 Feb 2012 04:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=lwEPFNlC8mqpt0vwaPmWpdmVpB6fi04HEIjDOjNESos=;
	b=e7UCHpTQp7sGxhL2OBKPPQYcC+M0U6lD2vDdIskmNBaMRmEsHKvaf8kfbCBFlHFHbB
	crQlyEfVNA4XCN5CacEwQwlSH+IXNRqTgCWA1KSWkSBm4CJNcvxLSLQ5yyFhw50CGwgR
	sFP64SXdLS+gQME/yzRuE7TerC14sOLnJfSX8=
Received: by 10.180.80.8 with SMTP id n8mr21901804wix.14.1330345163018;
	Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54328096wib.10.2012.02.27.04.19.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 04:19:22 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org, qemu-devel@nongnu.org,
	stefano.stabellini@citrix.com
Date: Tue, 21 Feb 2012 20:14:39 +0100
Message-Id: <1329851680-3421-2-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
In-Reply-To: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
References: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 2/3] build: add librt to libs_qga
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

librt is needed to link qemu-ga.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 configure |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 68eb3fa..790d495 100755
--- a/configure
+++ b/configure
@@ -2521,6 +2521,7 @@ if compile_prog "" "" ; then
   :
 elif compile_prog "" "-lrt" ; then
   LIBS="-lrt $LIBS"
+  libs_qga="-lrt $libs_qga"
 fi
 
 if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zYA-0007bJ-Mk; Mon, 27 Feb 2012 12:19:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1zY9-0007aP-C3
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330345163!15106443!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=4.0 required=7.0 tests=DATE_IN_PAST_96_XX,
	RCVD_BY_IP,SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24069 invoked from network); 27 Feb 2012 12:19:23 -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;
	27 Feb 2012 12:19:23 -0000
Received: by werp12 with SMTP id p12so1184649wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.80.8 as permitted sender) client-ip=10.180.80.8; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.80.8 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.80.8])
	by 10.180.80.8 with SMTP id n8mr27529643wix.14.1330345163105 (num_hops
	= 1); Mon, 27 Feb 2012 04:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=lwEPFNlC8mqpt0vwaPmWpdmVpB6fi04HEIjDOjNESos=;
	b=e7UCHpTQp7sGxhL2OBKPPQYcC+M0U6lD2vDdIskmNBaMRmEsHKvaf8kfbCBFlHFHbB
	crQlyEfVNA4XCN5CacEwQwlSH+IXNRqTgCWA1KSWkSBm4CJNcvxLSLQ5yyFhw50CGwgR
	sFP64SXdLS+gQME/yzRuE7TerC14sOLnJfSX8=
Received: by 10.180.80.8 with SMTP id n8mr21901804wix.14.1330345163018;
	Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54328096wib.10.2012.02.27.04.19.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 04:19:22 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org, qemu-devel@nongnu.org,
	stefano.stabellini@citrix.com
Date: Tue, 21 Feb 2012 20:14:39 +0100
Message-Id: <1329851680-3421-2-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
In-Reply-To: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
References: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 2/3] build: add librt to libs_qga
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

librt is needed to link qemu-ga.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 configure |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 68eb3fa..790d495 100755
--- a/configure
+++ b/configure
@@ -2521,6 +2521,7 @@ if compile_prog "" "" ; then
   :
 elif compile_prog "" "-lrt" ; then
   LIBS="-lrt $LIBS"
+  libs_qga="-lrt $libs_qga"
 fi
 
 if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:19:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1zYB-0007bc-9M; Mon, 27 Feb 2012 12:19:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1zYA-0007aX-44
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:19:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330345163!15106443!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24115 invoked from network); 27 Feb 2012 12:19:24 -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;
	27 Feb 2012 12:19:24 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so1184649wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.138.131 as permitted sender) client-ip=10.216.138.131; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.138.131 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.138.131])
	by 10.216.138.131 with SMTP id a3mr6874880wej.43.1330345163959
	(num_hops = 1); Mon, 27 Feb 2012 04:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=sXegCzlFXsLUVxsiQo86unPKMzKFZv2NCAK4O7OkiHo=;
	b=Su7o4bAiNHrDJO5UzZdR7dVGtEzcZy8Js25vRNULG4c0RytldEic2bqdp/8K4ffaot
	Zjv3JvWLhgq8jNExAVKbZE9N3LIRUS8UCR1oUeLtA53o4bcgaryo0WGxcee6F4JQCMkg
	PEy2X28kuACjaztQ1LlzOf7j2y/1scFtVYgDw=
Received: by 10.216.138.131 with SMTP id a3mr5450292wej.43.1330345163830;
	Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54328096wib.10.2012.02.27.04.19.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 04:19:23 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org, qemu-devel@nongnu.org,
	stefano.stabellini@citrix.com
Date: Tue, 21 Feb 2012 20:14:40 +0100
Message-Id: <1329851680-3421-3-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
In-Reply-To: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
References: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 3/3] build: check if libm is needed in configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the hardcoded use of libm and instead rely on configure to
check for it. It is needed at least for qemu-ga and qemu-system.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 Makefile.target |    4 ----
 configure       |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 68a5641..c230aff 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -42,10 +42,6 @@ PROGS+=$(QEMU_PROGW)
 endif
 STPFILES=
 
-ifndef CONFIG_HAIKU
-LIBS+=-lm
-endif
-
 config-target.h: config-target.h-timestamp
 config-target.h-timestamp: config-target.mak
 
diff --git a/configure b/configure
index 790d495..b0cb175 100755
--- a/configure
+++ b/configure
@@ -2524,6 +2524,20 @@ elif compile_prog "" "-lrt" ; then
   libs_qga="-lrt $libs_qga"
 fi
 
+##########################################
+# Do we need libm
+cat > $TMPC <<EOF
+#include <math.h>
+int main(void) { double a, b; return modf(a, &b);}
+EOF
+
+if compile_prog "" "" ; then
+  :
+elif compile_prog "" "-lm" ; then
+  LIBS="-lm $LIBS"
+  libs_qga="-lm $libs_qga"
+fi
+
 if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
         "$aix" != "yes" -a "$haiku" != "yes" ; then
     libs_softmmu="-lutil $libs_softmmu"
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:19:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1zYB-0007bc-9M; Mon, 27 Feb 2012 12:19:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S1zYA-0007aX-44
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:19:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330345163!15106443!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24115 invoked from network); 27 Feb 2012 12:19:24 -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;
	27 Feb 2012 12:19:24 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so1184649wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.138.131 as permitted sender) client-ip=10.216.138.131; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.138.131 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.138.131])
	by 10.216.138.131 with SMTP id a3mr6874880wej.43.1330345163959
	(num_hops = 1); Mon, 27 Feb 2012 04:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=sXegCzlFXsLUVxsiQo86unPKMzKFZv2NCAK4O7OkiHo=;
	b=Su7o4bAiNHrDJO5UzZdR7dVGtEzcZy8Js25vRNULG4c0RytldEic2bqdp/8K4ffaot
	Zjv3JvWLhgq8jNExAVKbZE9N3LIRUS8UCR1oUeLtA53o4bcgaryo0WGxcee6F4JQCMkg
	PEy2X28kuACjaztQ1LlzOf7j2y/1scFtVYgDw=
Received: by 10.216.138.131 with SMTP id a3mr5450292wej.43.1330345163830;
	Mon, 27 Feb 2012 04:19:23 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id
	hb10sm54328096wib.10.2012.02.27.04.19.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 04:19:23 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org, qemu-devel@nongnu.org,
	stefano.stabellini@citrix.com
Date: Tue, 21 Feb 2012 20:14:40 +0100
Message-Id: <1329851680-3421-3-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.9
In-Reply-To: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
References: <1329851680-3421-1-git-send-email-roger.pau@entel.upc.edu>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH 3/3] build: check if libm is needed in configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove the hardcoded use of libm and instead rely on configure to
check for it. It is needed at least for qemu-ga and qemu-system.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 Makefile.target |    4 ----
 configure       |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 68a5641..c230aff 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -42,10 +42,6 @@ PROGS+=$(QEMU_PROGW)
 endif
 STPFILES=
 
-ifndef CONFIG_HAIKU
-LIBS+=-lm
-endif
-
 config-target.h: config-target.h-timestamp
 config-target.h-timestamp: config-target.mak
 
diff --git a/configure b/configure
index 790d495..b0cb175 100755
--- a/configure
+++ b/configure
@@ -2524,6 +2524,20 @@ elif compile_prog "" "-lrt" ; then
   libs_qga="-lrt $libs_qga"
 fi
 
+##########################################
+# Do we need libm
+cat > $TMPC <<EOF
+#include <math.h>
+int main(void) { double a, b; return modf(a, &b);}
+EOF
+
+if compile_prog "" "" ; then
+  :
+elif compile_prog "" "-lm" ; then
+  LIBS="-lm $LIBS"
+  libs_qga="-lm $libs_qga"
+fi
+
 if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
         "$aix" != "yes" -a "$haiku" != "yes" ; then
     libs_softmmu="-lutil $libs_softmmu"
-- 
1.7.9


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1zfS-00089v-9Q; Mon, 27 Feb 2012 12:27:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S1zfQ-00089c-Oq
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:27:00 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330345614!13249376!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31452 invoked from network); 27 Feb 2012 12:26:54 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-15.tower-174.messagelabs.com with SMTP;
	27 Feb 2012 12:26:54 -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 2AF3D16297
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 12:26:54 +0000 (GMT)
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 IlwjLRPm5L35 for <xen-devel@lists.xen.org>;
	Mon, 27 Feb 2012 12:26:53 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id 802C516295;
	Mon, 27 Feb 2012 12:26:52 +0000 (GMT)
Message-ID: <4F4B768C.40607@abpni.co.uk>
Date: Mon, 27 Feb 2012 12:26:52 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F4B7047.1080106@abpni.co.uk>
	<1330344538.8557.280.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330344538.8557.280.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.4 security 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 27/02/2012 12:08, Ian Campbell wrote:
> On Mon, 2012-02-27 at 12:00 +0000, Jonathan Tripathy wrote:
>> " Security enhancements including CVE-2011-1583"
>>
>> However, the aforementioned CVE seems to only apply to other versions
>> of Xen (3.4.x is missing in the list of venerable software)
>>
>> While I'm obviously happy that the latest release is free of this bug,
>> can someone please shed some light on how this bug was fixed in 3.4.4,
>> when it wasn't supposed to be present in the first place in 3.4.3?
> Given that 3.3 and 4.0 were vulnerable I think this is simply a case of
> 3.4 being accidentally omitted from the list.
>
> Ian.
>
>
Thanks for the reply, Ian.

Any ideas on what other security issues were fixed?

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:27:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S1zfS-00089v-9Q; Mon, 27 Feb 2012 12:27:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S1zfQ-00089c-Oq
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:27:00 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330345614!13249376!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31452 invoked from network); 27 Feb 2012 12:26:54 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-15.tower-174.messagelabs.com with SMTP;
	27 Feb 2012 12:26:54 -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 2AF3D16297
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 12:26:54 +0000 (GMT)
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 IlwjLRPm5L35 for <xen-devel@lists.xen.org>;
	Mon, 27 Feb 2012 12:26:53 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id 802C516295;
	Mon, 27 Feb 2012 12:26:52 +0000 (GMT)
Message-ID: <4F4B768C.40607@abpni.co.uk>
Date: Mon, 27 Feb 2012 12:26:52 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F4B7047.1080106@abpni.co.uk>
	<1330344538.8557.280.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330344538.8557.280.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.4 security 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 27/02/2012 12:08, Ian Campbell wrote:
> On Mon, 2012-02-27 at 12:00 +0000, Jonathan Tripathy wrote:
>> " Security enhancements including CVE-2011-1583"
>>
>> However, the aforementioned CVE seems to only apply to other versions
>> of Xen (3.4.x is missing in the list of venerable software)
>>
>> While I'm obviously happy that the latest release is free of this bug,
>> can someone please shed some light on how this bug was fixed in 3.4.4,
>> when it wasn't supposed to be present in the first place in 3.4.3?
> Given that 3.3 and 4.0 were vulnerable I think this is simply a case of
> 3.4 being accidentally omitted from the list.
>
> Ian.
>
>
Thanks for the reply, Ian.

Any ideas on what other security issues were fixed?

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:38:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zq0-0008Vx-EZ; Mon, 27 Feb 2012 12:37: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 1S1zpy-0008Vo-Bp
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:37:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330346200!58348346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 27 Feb 2012 12:36:40 -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;
	27 Feb 2012 12:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10954087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 12: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.213.0;
	Mon, 27 Feb 2012 12:37:48 +0000
Message-ID: <1330346266.8557.282.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 27 Feb 2012 12:37:46 +0000
In-Reply-To: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
References: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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-02-27 at 12:07 +0000, Ian Campbell wrote:
> As part of this I looked through the relevant chapter from interfaces.tex (from
> 4.1, deleted in unstable) to ensure no critical information was missing.

Actually, the intro from that chapter is interesting/useful and I missed
it. Here's a new version with it included.

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330346207 0
# Node ID b6a3a0d68c91ce8fa6023aee3046efd3866942df
# Parent  71159fb049f253030c3820c260d092d4aec6b166
hcall: markup the event channel hypercalls to improve generated docs

As part of this I looked through the relevant chapter from interfaces.tex (from
4.1, deleted in unstable) to ensure no critical information was missing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/event_channel.h
--- a/xen/include/public/event_channel.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/event_channel.h	Mon Feb 27 12:36:47 2012 +0000
@@ -1,8 +1,8 @@
 /******************************************************************************
  * event_channel.h
- * 
+ *
  * Event channels between domains.
- * 
+ *
  * 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,12 +30,49 @@
 #include "xen.h"
 
 /*
- * Prototype for this hypercall is:
- *  int event_channel_op(int cmd, void *args)
- * @cmd  == EVTCHNOP_??? (event-channel operation).
- * @args == Operation-specific extra arguments (NULL if none).
+ * `incontents 150 evtchn Event Channels
+ *
+ * Event channels are the basic primitive provided by Xen for event
+ * notifications. An event is the Xen equivalent of a hardware
+ * interrupt. They essentially store one bit of information, the event
+ * of interest is signalled by transitioning this bit from 0 to 1.
+ *
+ * Notifications are received by a guest via an upcall from Xen,
+ * indicating when an event arrives (setting the bit). Further
+ * notifications are masked until the bit is cleared again (therefore,
+ * guests must check the value of the bit after re-enabling event
+ * delivery to ensure no missed notifications).
+ *
+ * Event notifications can be masked by setting a flag; this is
+ * equivalent to disabling interrupts and can be used to ensure
+ * atomicity of certain operations in the guest kernel.
+ *
+ * Event channels are represented by the evtchn_* fields in
+ * struct shared_info and struct vcpu_info.
  */
 
+/*
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
+ * `
+ * @cmd  == EVTCHNOP_* (event-channel operation).
+ * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
+ */
+
+/* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
+#define EVTCHNOP_bind_interdomain 0
+#define EVTCHNOP_bind_virq        1
+#define EVTCHNOP_bind_pirq        2
+#define EVTCHNOP_close            3
+#define EVTCHNOP_send             4
+#define EVTCHNOP_status           5
+#define EVTCHNOP_alloc_unbound    6
+#define EVTCHNOP_bind_ipi         7
+#define EVTCHNOP_bind_vcpu        8
+#define EVTCHNOP_unmask           9
+#define EVTCHNOP_reset           10
+/* ` } */
+
 typedef uint32_t evtchn_port_t;
 DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
 
@@ -47,7 +84,6 @@ DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
  *  1. If the caller is unprivileged then <dom> must be DOMID_SELF.
  *  2. <rdom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_alloc_unbound    6
 struct evtchn_alloc_unbound {
     /* IN parameters */
     domid_t dom, remote_dom;
@@ -63,9 +99,8 @@ typedef struct evtchn_alloc_unbound evtc
  * domain. A fresh port is allocated in the calling domain and returned as
  * <local_port>.
  * NOTES:
- *  2. <remote_dom> may be DOMID_SELF, allowing loopback connections.
+ *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_bind_interdomain 0
 struct evtchn_bind_interdomain {
     /* IN parameters. */
     domid_t remote_dom;
@@ -87,10 +122,9 @@ typedef struct evtchn_bind_interdomain e
  *     The allocated event channel is bound to the specified vcpu and the
  *     binding cannot be changed.
  */
-#define EVTCHNOP_bind_virq        1
 struct evtchn_bind_virq {
     /* IN parameters. */
-    uint32_t virq;
+    uint32_t virq; /* enum virq */
     uint32_t vcpu;
     /* OUT parameters. */
     evtchn_port_t port;
@@ -98,12 +132,11 @@ struct evtchn_bind_virq {
 typedef struct evtchn_bind_virq evtchn_bind_virq_t;
 
 /*
- * EVTCHNOP_bind_pirq: Bind a local event channel to PIRQ <irq>.
+ * EVTCHNOP_bind_pirq: Bind a local event channel to a real IRQ (PIRQ <irq>).
  * NOTES:
  *  1. A physical IRQ may be bound to at most one event channel per domain.
  *  2. Only a sufficiently-privileged domain may bind to a physical IRQ.
  */
-#define EVTCHNOP_bind_pirq        2
 struct evtchn_bind_pirq {
     /* IN parameters. */
     uint32_t pirq;
@@ -120,7 +153,6 @@ typedef struct evtchn_bind_pirq evtchn_b
  *  1. The allocated event channel is bound to the specified vcpu. The binding
  *     may not be changed.
  */
-#define EVTCHNOP_bind_ipi         7
 struct evtchn_bind_ipi {
     uint32_t vcpu;
     /* OUT parameters. */
@@ -133,7 +165,6 @@ typedef struct evtchn_bind_ipi evtchn_bi
  * interdomain then the remote end is placed in the unbound state
  * (EVTCHNSTAT_unbound), awaiting a new connection.
  */
-#define EVTCHNOP_close            3
 struct evtchn_close {
     /* IN parameters. */
     evtchn_port_t port;
@@ -144,7 +175,6 @@ typedef struct evtchn_close evtchn_close
  * EVTCHNOP_send: Send an event to the remote end of the channel whose local
  * endpoint is <port>.
  */
-#define EVTCHNOP_send             4
 struct evtchn_send {
     /* IN parameters. */
     evtchn_port_t port;
@@ -159,7 +189,6 @@ typedef struct evtchn_send evtchn_send_t
  *  2. Only a sufficiently-privileged domain may obtain the status of an event
  *     channel for which <dom> is not DOMID_SELF.
  */
-#define EVTCHNOP_status           5
 struct evtchn_status {
     /* IN parameters */
     domid_t  dom;
@@ -176,13 +205,13 @@ struct evtchn_status {
     union {
         struct {
             domid_t dom;
-        } unbound; /* EVTCHNSTAT_unbound */
+        } unbound;                 /* EVTCHNSTAT_unbound */
         struct {
             domid_t dom;
             evtchn_port_t port;
-        } interdomain; /* EVTCHNSTAT_interdomain */
-        uint32_t pirq;      /* EVTCHNSTAT_pirq        */
-        uint32_t virq;      /* EVTCHNSTAT_virq        */
+        } interdomain;             /* EVTCHNSTAT_interdomain */
+        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
+        uint32_t virq;             /* EVTCHNSTAT_virq        */
     } u;
 };
 typedef struct evtchn_status evtchn_status_t;
@@ -199,7 +228,6 @@ typedef struct evtchn_status evtchn_stat
  *     the channel is allocated (a port that is freed and subsequently reused
  *     has its binding reset to vcpu0).
  */
-#define EVTCHNOP_bind_vcpu        8
 struct evtchn_bind_vcpu {
     /* IN parameters. */
     evtchn_port_t port;
@@ -211,7 +239,6 @@ typedef struct evtchn_bind_vcpu evtchn_b
  * EVTCHNOP_unmask: Unmask the specified local event-channel port and deliver
  * a notification to the appropriate VCPU if an event is pending.
  */
-#define EVTCHNOP_unmask           9
 struct evtchn_unmask {
     /* IN parameters. */
     evtchn_port_t port;
@@ -224,7 +251,6 @@ typedef struct evtchn_unmask evtchn_unma
  *  1. <dom> may be specified as DOMID_SELF.
  *  2. Only a sufficiently-privileged domain may specify other than DOMID_SELF.
  */
-#define EVTCHNOP_reset           10
 struct evtchn_reset {
     /* IN parameters. */
     domid_t dom;
@@ -232,11 +258,13 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
- * Argument to event_channel_op_compat() hypercall. Superceded by new
- * event_channel_op() hypercall since 0x00030202.
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
+ * `
+ * Superceded by new event_channel_op() hypercall since 0x00030202.
  */
 struct evtchn_op {
-    uint32_t cmd; /* EVTCHNOP_* */
+    uint32_t cmd; /* enum event_channel_op */
     union {
         struct evtchn_alloc_unbound    alloc_unbound;
         struct evtchn_bind_interdomain bind_interdomain;
diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/xen.h	Mon Feb 27 12:36:47 2012 +0000
@@ -146,6 +146,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * The latter can be allocated only once per guest: they must initially be
  * allocated to VCPU0 but can subsequently be re-bound.
  */
+/* ` enum virq { */
 #define VIRQ_TIMER      0  /* V. Timebase update, and/or requested timeout.  */
 #define VIRQ_DEBUG      1  /* V. Request guest to dump debug info.           */
 #define VIRQ_CONSOLE    2  /* G. (DOM0) Bytes received on emergency console. */
@@ -167,6 +168,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_ARCH_5    21
 #define VIRQ_ARCH_6    22
 #define VIRQ_ARCH_7    23
+/* ` } */
 
 #define NR_VIRQS       24
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:38:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zq0-0008Vx-EZ; Mon, 27 Feb 2012 12:37: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 1S1zpy-0008Vo-Bp
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:37:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330346200!58348346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 27 Feb 2012 12:36:40 -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;
	27 Feb 2012 12:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10954087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 12: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.213.0;
	Mon, 27 Feb 2012 12:37:48 +0000
Message-ID: <1330346266.8557.282.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 27 Feb 2012 12:37:46 +0000
In-Reply-To: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
References: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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-02-27 at 12:07 +0000, Ian Campbell wrote:
> As part of this I looked through the relevant chapter from interfaces.tex (from
> 4.1, deleted in unstable) to ensure no critical information was missing.

Actually, the intro from that chapter is interesting/useful and I missed
it. Here's a new version with it included.

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330346207 0
# Node ID b6a3a0d68c91ce8fa6023aee3046efd3866942df
# Parent  71159fb049f253030c3820c260d092d4aec6b166
hcall: markup the event channel hypercalls to improve generated docs

As part of this I looked through the relevant chapter from interfaces.tex (from
4.1, deleted in unstable) to ensure no critical information was missing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/event_channel.h
--- a/xen/include/public/event_channel.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/event_channel.h	Mon Feb 27 12:36:47 2012 +0000
@@ -1,8 +1,8 @@
 /******************************************************************************
  * event_channel.h
- * 
+ *
  * Event channels between domains.
- * 
+ *
  * 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,12 +30,49 @@
 #include "xen.h"
 
 /*
- * Prototype for this hypercall is:
- *  int event_channel_op(int cmd, void *args)
- * @cmd  == EVTCHNOP_??? (event-channel operation).
- * @args == Operation-specific extra arguments (NULL if none).
+ * `incontents 150 evtchn Event Channels
+ *
+ * Event channels are the basic primitive provided by Xen for event
+ * notifications. An event is the Xen equivalent of a hardware
+ * interrupt. They essentially store one bit of information, the event
+ * of interest is signalled by transitioning this bit from 0 to 1.
+ *
+ * Notifications are received by a guest via an upcall from Xen,
+ * indicating when an event arrives (setting the bit). Further
+ * notifications are masked until the bit is cleared again (therefore,
+ * guests must check the value of the bit after re-enabling event
+ * delivery to ensure no missed notifications).
+ *
+ * Event notifications can be masked by setting a flag; this is
+ * equivalent to disabling interrupts and can be used to ensure
+ * atomicity of certain operations in the guest kernel.
+ *
+ * Event channels are represented by the evtchn_* fields in
+ * struct shared_info and struct vcpu_info.
  */
 
+/*
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
+ * `
+ * @cmd  == EVTCHNOP_* (event-channel operation).
+ * @args == struct evtchn_* Operation-specific extra arguments (NULL if none).
+ */
+
+/* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
+#define EVTCHNOP_bind_interdomain 0
+#define EVTCHNOP_bind_virq        1
+#define EVTCHNOP_bind_pirq        2
+#define EVTCHNOP_close            3
+#define EVTCHNOP_send             4
+#define EVTCHNOP_status           5
+#define EVTCHNOP_alloc_unbound    6
+#define EVTCHNOP_bind_ipi         7
+#define EVTCHNOP_bind_vcpu        8
+#define EVTCHNOP_unmask           9
+#define EVTCHNOP_reset           10
+/* ` } */
+
 typedef uint32_t evtchn_port_t;
 DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
 
@@ -47,7 +84,6 @@ DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
  *  1. If the caller is unprivileged then <dom> must be DOMID_SELF.
  *  2. <rdom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_alloc_unbound    6
 struct evtchn_alloc_unbound {
     /* IN parameters */
     domid_t dom, remote_dom;
@@ -63,9 +99,8 @@ typedef struct evtchn_alloc_unbound evtc
  * domain. A fresh port is allocated in the calling domain and returned as
  * <local_port>.
  * NOTES:
- *  2. <remote_dom> may be DOMID_SELF, allowing loopback connections.
+ *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
  */
-#define EVTCHNOP_bind_interdomain 0
 struct evtchn_bind_interdomain {
     /* IN parameters. */
     domid_t remote_dom;
@@ -87,10 +122,9 @@ typedef struct evtchn_bind_interdomain e
  *     The allocated event channel is bound to the specified vcpu and the
  *     binding cannot be changed.
  */
-#define EVTCHNOP_bind_virq        1
 struct evtchn_bind_virq {
     /* IN parameters. */
-    uint32_t virq;
+    uint32_t virq; /* enum virq */
     uint32_t vcpu;
     /* OUT parameters. */
     evtchn_port_t port;
@@ -98,12 +132,11 @@ struct evtchn_bind_virq {
 typedef struct evtchn_bind_virq evtchn_bind_virq_t;
 
 /*
- * EVTCHNOP_bind_pirq: Bind a local event channel to PIRQ <irq>.
+ * EVTCHNOP_bind_pirq: Bind a local event channel to a real IRQ (PIRQ <irq>).
  * NOTES:
  *  1. A physical IRQ may be bound to at most one event channel per domain.
  *  2. Only a sufficiently-privileged domain may bind to a physical IRQ.
  */
-#define EVTCHNOP_bind_pirq        2
 struct evtchn_bind_pirq {
     /* IN parameters. */
     uint32_t pirq;
@@ -120,7 +153,6 @@ typedef struct evtchn_bind_pirq evtchn_b
  *  1. The allocated event channel is bound to the specified vcpu. The binding
  *     may not be changed.
  */
-#define EVTCHNOP_bind_ipi         7
 struct evtchn_bind_ipi {
     uint32_t vcpu;
     /* OUT parameters. */
@@ -133,7 +165,6 @@ typedef struct evtchn_bind_ipi evtchn_bi
  * interdomain then the remote end is placed in the unbound state
  * (EVTCHNSTAT_unbound), awaiting a new connection.
  */
-#define EVTCHNOP_close            3
 struct evtchn_close {
     /* IN parameters. */
     evtchn_port_t port;
@@ -144,7 +175,6 @@ typedef struct evtchn_close evtchn_close
  * EVTCHNOP_send: Send an event to the remote end of the channel whose local
  * endpoint is <port>.
  */
-#define EVTCHNOP_send             4
 struct evtchn_send {
     /* IN parameters. */
     evtchn_port_t port;
@@ -159,7 +189,6 @@ typedef struct evtchn_send evtchn_send_t
  *  2. Only a sufficiently-privileged domain may obtain the status of an event
  *     channel for which <dom> is not DOMID_SELF.
  */
-#define EVTCHNOP_status           5
 struct evtchn_status {
     /* IN parameters */
     domid_t  dom;
@@ -176,13 +205,13 @@ struct evtchn_status {
     union {
         struct {
             domid_t dom;
-        } unbound; /* EVTCHNSTAT_unbound */
+        } unbound;                 /* EVTCHNSTAT_unbound */
         struct {
             domid_t dom;
             evtchn_port_t port;
-        } interdomain; /* EVTCHNSTAT_interdomain */
-        uint32_t pirq;      /* EVTCHNSTAT_pirq        */
-        uint32_t virq;      /* EVTCHNSTAT_virq        */
+        } interdomain;             /* EVTCHNSTAT_interdomain */
+        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
+        uint32_t virq;             /* EVTCHNSTAT_virq        */
     } u;
 };
 typedef struct evtchn_status evtchn_status_t;
@@ -199,7 +228,6 @@ typedef struct evtchn_status evtchn_stat
  *     the channel is allocated (a port that is freed and subsequently reused
  *     has its binding reset to vcpu0).
  */
-#define EVTCHNOP_bind_vcpu        8
 struct evtchn_bind_vcpu {
     /* IN parameters. */
     evtchn_port_t port;
@@ -211,7 +239,6 @@ typedef struct evtchn_bind_vcpu evtchn_b
  * EVTCHNOP_unmask: Unmask the specified local event-channel port and deliver
  * a notification to the appropriate VCPU if an event is pending.
  */
-#define EVTCHNOP_unmask           9
 struct evtchn_unmask {
     /* IN parameters. */
     evtchn_port_t port;
@@ -224,7 +251,6 @@ typedef struct evtchn_unmask evtchn_unma
  *  1. <dom> may be specified as DOMID_SELF.
  *  2. Only a sufficiently-privileged domain may specify other than DOMID_SELF.
  */
-#define EVTCHNOP_reset           10
 struct evtchn_reset {
     /* IN parameters. */
     domid_t dom;
@@ -232,11 +258,13 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
- * Argument to event_channel_op_compat() hypercall. Superceded by new
- * event_channel_op() hypercall since 0x00030202.
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
+ * `
+ * Superceded by new event_channel_op() hypercall since 0x00030202.
  */
 struct evtchn_op {
-    uint32_t cmd; /* EVTCHNOP_* */
+    uint32_t cmd; /* enum event_channel_op */
     union {
         struct evtchn_alloc_unbound    alloc_unbound;
         struct evtchn_bind_interdomain bind_interdomain;
diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Fri Feb 24 11:46:32 2012 +0100
+++ b/xen/include/public/xen.h	Mon Feb 27 12:36:47 2012 +0000
@@ -146,6 +146,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * The latter can be allocated only once per guest: they must initially be
  * allocated to VCPU0 but can subsequently be re-bound.
  */
+/* ` enum virq { */
 #define VIRQ_TIMER      0  /* V. Timebase update, and/or requested timeout.  */
 #define VIRQ_DEBUG      1  /* V. Request guest to dump debug info.           */
 #define VIRQ_CONSOLE    2  /* G. (DOM0) Bytes received on emergency console. */
@@ -167,6 +168,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define VIRQ_ARCH_5    21
 #define VIRQ_ARCH_6    22
 #define VIRQ_ARCH_7    23
+/* ` } */
 
 #define NR_VIRQS       24
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zvK-0000RG-Qs; Mon, 27 Feb 2012 12:43:26 +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 1S1zvJ-0000R3-VC
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:43:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330346576!65254866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7047 invoked from network); 27 Feb 2012 12:42:56 -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;
	27 Feb 2012 12:42:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10954214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 12:43:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 12:43:20 +0000
Date: Mon, 27 Feb 2012 12:49:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330336335.8557.259.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202271209340.23091@kaball-desktop>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
	<CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
	<1330336335.8557.259.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-336599356-1330344840=:23091"
Content-ID: <alpine.DEB.2.00.1202271220060.23091@kaball-desktop>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-336599356-1330344840=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1202271220061.23091@kaball-desktop>

On Mon, 27 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 13:34 +0000, Roger Pau Monné wrote:
> > 2012/2/22 Anthony Liguori <anthony@codemonkey.ws>:
> > > On 02/20/2012 06:11 AM, Roger Pau Monne wrote:
> > >>
> > >> Replace clock_gettime with timer_gettime, since at least under
> > >> uclibc 0.9.33 the clock_getttime function can be used without linking
> > >> against librt (although the manual page states the opposite).
> > >>
> > >> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu>
> > >
> > >
> > > I don't think this is against qemu.git.  Please do not send patches to
> > > qemu-devel that are not against qemu.git without clearly indicating this.
> > 
> > Sorry, this is against qemu-xen-upstream, should I add a tag to my
> > patches and resend them to qemu-devel?
> 
> qemu-xen-upstream is based upon the upstream qemu stable branch, not the
> development branch.
> 
> However patches for qemu-xen-upstream should have already been applied
> upstream. This means that patches should be against the mainline (e.g.
> development branch) version of qemu and sent to qemu-devel. Once
> committed there they will be backported as required to the stable branch
> maintained by Xen.org as qemu-xen-upstream.
> 
> (Stefano, is that correct? Is there somewhere we can (or do!) document
> this? Perhaps http://wiki.xen.org/xenwiki/QEMUUpstream linked to from
> Submitting_Xen_Patches? The backport policy should also be covered, e.g.
> http://marc.info/?l=xen-devel&m=132872001218724 )

Yes, it is correct.

I added few lines to
http://wiki.xen.org/wiki?title=Submitting_Xen_Patches to explain this
concept. I have also linked http://wiki.qemu.org/Contribute/SubmitAPatch
that is the reference on how to submit patches to qemu-devel.
--8323329-336599356-1330344840=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-336599356-1330344840=:23091--


From xen-devel-bounces@lists.xen.org Mon Feb 27 12:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12: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 1S1zvK-0000RG-Qs; Mon, 27 Feb 2012 12:43:26 +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 1S1zvJ-0000R3-VC
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 12:43:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330346576!65254866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7047 invoked from network); 27 Feb 2012 12:42:56 -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;
	27 Feb 2012 12:42:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10954214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 12:43:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 12:43:20 +0000
Date: Mon, 27 Feb 2012 12:49:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330336335.8557.259.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202271209340.23091@kaball-desktop>
References: <1329739880-18752-1-git-send-email-roger.pau@entel.upc.edu>
	<1329739880-18752-2-git-send-email-roger.pau@entel.upc.edu>
	<4F454146.1050007@codemonkey.ws>
	<CAPLaKK5rnfYZ9XDKhtHHQ4Rswn6DgcWqeZdbanLA_ggwFTSV8A@mail.gmail.com>
	<1330336335.8557.259.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-336599356-1330344840=:23091"
Content-ID: <alpine.DEB.2.00.1202271220060.23091@kaball-desktop>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] build: replace librt check
 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-336599356-1330344840=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1202271220061.23091@kaball-desktop>

On Mon, 27 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 13:34 +0000, Roger Pau Monné wrote:
> > 2012/2/22 Anthony Liguori <anthony@codemonkey.ws>:
> > > On 02/20/2012 06:11 AM, Roger Pau Monne wrote:
> > >>
> > >> Replace clock_gettime with timer_gettime, since at least under
> > >> uclibc 0.9.33 the clock_getttime function can be used without linking
> > >> against librt (although the manual page states the opposite).
> > >>
> > >> Signed-off-by: Roger Pau Monne<roger.pau@entel.upc.edu>
> > >
> > >
> > > I don't think this is against qemu.git.  Please do not send patches to
> > > qemu-devel that are not against qemu.git without clearly indicating this.
> > 
> > Sorry, this is against qemu-xen-upstream, should I add a tag to my
> > patches and resend them to qemu-devel?
> 
> qemu-xen-upstream is based upon the upstream qemu stable branch, not the
> development branch.
> 
> However patches for qemu-xen-upstream should have already been applied
> upstream. This means that patches should be against the mainline (e.g.
> development branch) version of qemu and sent to qemu-devel. Once
> committed there they will be backported as required to the stable branch
> maintained by Xen.org as qemu-xen-upstream.
> 
> (Stefano, is that correct? Is there somewhere we can (or do!) document
> this? Perhaps http://wiki.xen.org/xenwiki/QEMUUpstream linked to from
> Submitting_Xen_Patches? The backport policy should also be covered, e.g.
> http://marc.info/?l=xen-devel&m=132872001218724 )

Yes, it is correct.

I added few lines to
http://wiki.xen.org/wiki?title=Submitting_Xen_Patches to explain this
concept. I have also linked http://wiki.qemu.org/Contribute/SubmitAPatch
that is the reference on how to submit patches to qemu-devel.
--8323329-336599356-1330344840=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-336599356-1330344840=:23091--


From xen-devel-bounces@lists.xen.org Mon Feb 27 12:50:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S201g-0000mz-N0; Mon, 27 Feb 2012 12:50:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1S201f-0000mt-9q
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:49:59 +0000
Received: from [85.158.139.83:61602] by server-11.bemta-5.messagelabs.com id
	17/45-14397-6FB7B4F4; Mon, 27 Feb 2012 12:49:58 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330346996!16816944!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13210 invoked from network); 27 Feb 2012 12:49:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:49:57 -0000
Received: by iadj38 with SMTP id j38so4057944iad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 04:49:56 -0800 (PST)
Received-SPF: pass (google.com: domain of todd.deshane.xen@gmail.com
	designates 10.50.155.202 as permitted sender)
	client-ip=10.50.155.202; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	todd.deshane.xen@gmail.com designates 10.50.155.202 as
	permitted sender) smtp.mail=todd.deshane.xen@gmail.com;
	dkim=pass header.i=todd.deshane.xen@gmail.com
Received: from mr.google.com ([10.50.155.202])
	by 10.50.155.202 with SMTP id vy10mr16560826igb.8.1330346996293
	(num_hops = 1); Mon, 27 Feb 2012 04:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:content-type
	:content-transfer-encoding;
	bh=qrKjyswK2Kn/327wN0pKpjiz44ZYXcFXAt9Gs477V10=;
	b=KR3MS+F1VFPkuCw2PRPOn5cAapwPQ6Y0cRRHkMyannq39jH8bX2nVVCww73cLO1kE9
	oR7WSHL68vvQh8IT9X9YDySp4HwBpqASFN8Mbq4QzS4ip2Ve63Uq71KcXFW/cw+EIwDm
	aRfj2BNN5ZGec1a+eZis2/EGlVqw7jUrMcXRM=
Received: by 10.50.155.202 with SMTP id vy10mr13448570igb.8.1330346996144;
	Mon, 27 Feb 2012 04:49:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.38.5 with HTTP; Mon, 27 Feb 2012 04:49:36 -0800 (PST)
In-Reply-To: <CAMrPLWLk6-qk-Kk2gtwf+snmXXwRSz2_YBs8s0oqZQx+DbDk4A@mail.gmail.com>
References: <CAMrPLWLk6-qk-Kk2gtwf+snmXXwRSz2_YBs8s0oqZQx+DbDk4A@mail.gmail.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Mon, 27 Feb 2012 07:49:36 -0500
X-Google-Sender-Auth: u7jEgNavtbpqMsGMtolTx-VuPtY
Message-ID: <CAMrPLWJjBBt4S74vSQWm1qmNWgt7vB63ZheHEDsDomWYydAKRw@mail.gmail.com>
To: xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Virtual Build a Cloud Day Tomorrow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Just a reminder...

On February 28th and 29th CloudStack.org be holding a two day session
focusing on the open source technologies you can use to build, manage
and deploy an open source cloud compute environment as well as DevOps
presentation on operational methodologies for managing "cloudy"
infrastructure. =A0The program will feature speakers from CloudStack,
Citrix,=A0Xen.org, Red Hat, Gluster, PuppetLabs, Opscode, Zenoss and
enStratus.

Even if you can't attend all the sessions feel free to sign-up and
we'll make our best effort to get you links to recordings and slide
decks after the event.

Day 1 Agenda

Day 1 of Build an Open Source Cloud Day will focus on the
infrastructure that compromises an infrastructure-as-a-service (IaaS)
cloud computing environment. The speakers will outline options for
virtualization, storage and orchestration that provide the foundation
for an open source cloud compute environment.

To register for=A0Day 1=A0of this virtual event you must sign-up via the
GoToMeeting Registration.=A0=A0(All times are EST).

10:00 a.m. -11:00 a.m. -=A0Welcome & Introduction to Open Source Cloud
Computing=A0-=A0Mark Hinkle, Director, Cloud Computing Community,
CloudStack.org
11:00 a.m. - 12:30 p.m. -=A0Cloud Computing with Xen Cloud Platform=A0-
Todd Deshane, Technology Evangelist ,=A0Xen.org
1:00 p.m. - 2:00 p.m. -=A0Distributed Pedabyte Scale Cloud Storage with
Gluster=A0-=A0John Mark Walker, Director of Communities, Red Hat/Gluster
2:30 p.m. - 4:00 p.m. -=A0Deploying Infrastructure-as-a-Service with
CloudStack=A0-=A0David Nalley, Community Manager,=A0CloudStack.org

Full details for Day 1 are available on CloudStack.org

Day 2 Agenda

Build a Cloud=A0Day 2=A0will focus on the tools you can use to manage and
deploy cloud computing infrastructure. Find out how to rapidly
provision and configure infrastructure using tools that automate your
management tasks then learn about methodologies for deploying

To register for this live event via the=A0GoToMeeting Registration. (All
times are EST).

10:00 a.m.- 11:30 a.m. -=A0Introduction to Puppet, Configuration
Management and IT Automation Software, Luke Kanies, Founder PuppetLabs
11:30 a.m. - 1:00 p.m. -=A0Automating your Cloud Deployments with
Opscode Chef, Matt Ray, Senior Technical Evangelist, Opscode
1:30 p.m. - 3:00 p.m. -=A0Monitoring the Cloud with Zenoss Core, Simon
Jakesch, Principal Engineer Zenoss
3:00 p.m. - 4:30 p.m.=A0 -=A0DevOps Your Competitive Advantage in the
Cloud, John M. Willis, enStratus

Full details for Day 2 are available on CloudStack.org



--
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 12:50:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 12:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S201g-0000mz-N0; Mon, 27 Feb 2012 12:50:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1S201f-0000mt-9q
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 12:49:59 +0000
Received: from [85.158.139.83:61602] by server-11.bemta-5.messagelabs.com id
	17/45-14397-6FB7B4F4; Mon, 27 Feb 2012 12:49:58 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1330346996!16816944!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13210 invoked from network); 27 Feb 2012 12:49:57 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 12:49:57 -0000
Received: by iadj38 with SMTP id j38so4057944iad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 04:49:56 -0800 (PST)
Received-SPF: pass (google.com: domain of todd.deshane.xen@gmail.com
	designates 10.50.155.202 as permitted sender)
	client-ip=10.50.155.202; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	todd.deshane.xen@gmail.com designates 10.50.155.202 as
	permitted sender) smtp.mail=todd.deshane.xen@gmail.com;
	dkim=pass header.i=todd.deshane.xen@gmail.com
Received: from mr.google.com ([10.50.155.202])
	by 10.50.155.202 with SMTP id vy10mr16560826igb.8.1330346996293
	(num_hops = 1); Mon, 27 Feb 2012 04:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:content-type
	:content-transfer-encoding;
	bh=qrKjyswK2Kn/327wN0pKpjiz44ZYXcFXAt9Gs477V10=;
	b=KR3MS+F1VFPkuCw2PRPOn5cAapwPQ6Y0cRRHkMyannq39jH8bX2nVVCww73cLO1kE9
	oR7WSHL68vvQh8IT9X9YDySp4HwBpqASFN8Mbq4QzS4ip2Ve63Uq71KcXFW/cw+EIwDm
	aRfj2BNN5ZGec1a+eZis2/EGlVqw7jUrMcXRM=
Received: by 10.50.155.202 with SMTP id vy10mr13448570igb.8.1330346996144;
	Mon, 27 Feb 2012 04:49:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.38.5 with HTTP; Mon, 27 Feb 2012 04:49:36 -0800 (PST)
In-Reply-To: <CAMrPLWLk6-qk-Kk2gtwf+snmXXwRSz2_YBs8s0oqZQx+DbDk4A@mail.gmail.com>
References: <CAMrPLWLk6-qk-Kk2gtwf+snmXXwRSz2_YBs8s0oqZQx+DbDk4A@mail.gmail.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Mon, 27 Feb 2012 07:49:36 -0500
X-Google-Sender-Auth: u7jEgNavtbpqMsGMtolTx-VuPtY
Message-ID: <CAMrPLWJjBBt4S74vSQWm1qmNWgt7vB63ZheHEDsDomWYydAKRw@mail.gmail.com>
To: xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Virtual Build a Cloud Day Tomorrow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Just a reminder...

On February 28th and 29th CloudStack.org be holding a two day session
focusing on the open source technologies you can use to build, manage
and deploy an open source cloud compute environment as well as DevOps
presentation on operational methodologies for managing "cloudy"
infrastructure. =A0The program will feature speakers from CloudStack,
Citrix,=A0Xen.org, Red Hat, Gluster, PuppetLabs, Opscode, Zenoss and
enStratus.

Even if you can't attend all the sessions feel free to sign-up and
we'll make our best effort to get you links to recordings and slide
decks after the event.

Day 1 Agenda

Day 1 of Build an Open Source Cloud Day will focus on the
infrastructure that compromises an infrastructure-as-a-service (IaaS)
cloud computing environment. The speakers will outline options for
virtualization, storage and orchestration that provide the foundation
for an open source cloud compute environment.

To register for=A0Day 1=A0of this virtual event you must sign-up via the
GoToMeeting Registration.=A0=A0(All times are EST).

10:00 a.m. -11:00 a.m. -=A0Welcome & Introduction to Open Source Cloud
Computing=A0-=A0Mark Hinkle, Director, Cloud Computing Community,
CloudStack.org
11:00 a.m. - 12:30 p.m. -=A0Cloud Computing with Xen Cloud Platform=A0-
Todd Deshane, Technology Evangelist ,=A0Xen.org
1:00 p.m. - 2:00 p.m. -=A0Distributed Pedabyte Scale Cloud Storage with
Gluster=A0-=A0John Mark Walker, Director of Communities, Red Hat/Gluster
2:30 p.m. - 4:00 p.m. -=A0Deploying Infrastructure-as-a-Service with
CloudStack=A0-=A0David Nalley, Community Manager,=A0CloudStack.org

Full details for Day 1 are available on CloudStack.org

Day 2 Agenda

Build a Cloud=A0Day 2=A0will focus on the tools you can use to manage and
deploy cloud computing infrastructure. Find out how to rapidly
provision and configure infrastructure using tools that automate your
management tasks then learn about methodologies for deploying

To register for this live event via the=A0GoToMeeting Registration. (All
times are EST).

10:00 a.m.- 11:30 a.m. -=A0Introduction to Puppet, Configuration
Management and IT Automation Software, Luke Kanies, Founder PuppetLabs
11:30 a.m. - 1:00 p.m. -=A0Automating your Cloud Deployments with
Opscode Chef, Matt Ray, Senior Technical Evangelist, Opscode
1:30 p.m. - 3:00 p.m. -=A0Monitoring the Cloud with Zenoss Core, Simon
Jakesch, Principal Engineer Zenoss
3:00 p.m. - 4:30 p.m.=A0 -=A0DevOps Your Competitive Advantage in the
Cloud, John M. Willis, enStratus

Full details for Day 2 are available on CloudStack.org



--
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.org/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21Jw-0003mv-7M; Mon, 27 Feb 2012 14:12:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S21Jv-0003mV-81
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 14:12:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330351968!2933200!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29399 invoked from network); 27 Feb 2012 14:12:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10956473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 14:12:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 14:12:46 +0000
Date: Mon, 27 Feb 2012 14:19:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330102209.8557.224.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202271418300.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330102209.8557.224.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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, 24 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
> >      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> >  }
> >  
> > +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> > +        unsigned long mfn)
> > +{
> > +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> > +                              (gpfn + 1) << PAGE_SHIFT,
> > +                              mfn << PAGE_SHIFT);
> > +} 
> 
> This doesn't actually end up getting called from the common code bits
> which should call it. Think we need this on top.
> 
> You can fold into your patch if you prefer.

I'll fold it into my patch.
Thanks!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21Jw-0003mv-7M; Mon, 27 Feb 2012 14:12:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S21Jv-0003mV-81
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 14:12:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330351968!2933200!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29399 invoked from network); 27 Feb 2012 14:12:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="10956473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 14:12:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 14:12:46 +0000
Date: Mon, 27 Feb 2012 14:19:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330102209.8557.224.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202271418300.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330102209.8557.224.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/5] arm: shared_info page allocation and
	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, 24 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > @@ -172,6 +177,14 @@ int map_mmio_regions(struct domain *d,
> >      return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr);
> >  }
> >  
> > +int guest_physmap_add_page(struct domain *d, unsigned long gpfn,
> > +        unsigned long mfn)
> > +{
> > +    return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT,
> > +                              (gpfn + 1) << PAGE_SHIFT,
> > +                              mfn << PAGE_SHIFT);
> > +} 
> 
> This doesn't actually end up getting called from the common code bits
> which should call it. Think we need this on top.
> 
> You can fold into your patch if you prefer.

I'll fold it into my patch.
Thanks!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:41:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21kl-0004pI-Hj; Mon, 27 Feb 2012 14:40:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S21kk-0004pB-Bc
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 14:40:38 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330353630!15103217!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32633 invoked from network); 27 Feb 2012 14:40:31 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 14:40:31 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1REeOQD080912
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 27 Feb 2012 07:40:24 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1330336401.8557.260.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 07:40:25 -0700
Message-Id: <FCEB562C-7F9A-4CA4-91ED-C47917EA74B0@spectralogic.com>
References: <CB70D835.2C505%keir.xen@gmail.com>
	<1330336401.8557.260.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Mon, 27 Feb 2012 07:40:25 -0700 (MST)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
	existing 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 Feb 27, 2012, at 2:53 AM, Ian Campbell wrote:

> On Mon, 2012-02-27 at 06:50 +0000, Keir Fraser wrote:
>> On 27/02/2012 06:27, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> 
>>> This patch series attempts to document the blkif PV interface and
>>> the various extensions to it that are out in the wild.
>> 
>> The previous round of these patches was already applied. They are sitting in
>> the staging tree currently (http://xenbits.xen.org/staging/xen-unstable.hg).
> 
> Note that they are stuck there because they broke the tests. See the
> "[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd" thread.
> 
> Ian.

Thanks for the pointer.

It seems I've made quite a mess of it. :-(

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:41:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21kl-0004pI-Hj; Mon, 27 Feb 2012 14:40:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S21kk-0004pB-Bc
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 14:40:38 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330353630!15103217!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32633 invoked from network); 27 Feb 2012 14:40:31 -0000
Received: from aslan.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 14:40:31 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1REeOQD080912
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 27 Feb 2012 07:40:24 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1330336401.8557.260.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 07:40:25 -0700
Message-Id: <FCEB562C-7F9A-4CA4-91ED-C47917EA74B0@spectralogic.com>
References: <CB70D835.2C505%keir.xen@gmail.com>
	<1330336401.8557.260.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Mon, 27 Feb 2012 07:40:25 -0700 (MST)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 4 v4] blkif.h: Document protocol and
	existing 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 Feb 27, 2012, at 2:53 AM, Ian Campbell wrote:

> On Mon, 2012-02-27 at 06:50 +0000, Keir Fraser wrote:
>> On 27/02/2012 06:27, "Justin T. Gibbs" <justing@spectralogic.com> wrote:
>> 
>>> This patch series attempts to document the blkif PV interface and
>>> the various extensions to it that are out in the wild.
>> 
>> The previous round of these patches was already applied. They are sitting in
>> the staging tree currently (http://xenbits.xen.org/staging/xen-unstable.hg).
> 
> Note that they are stuck there because they broke the tests. See the
> "[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd" thread.
> 
> Ian.

Thanks for the pointer.

It seems I've made quite a mess of it. :-(

--
Justin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:43:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:43:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21nV-0004yC-5i; Mon, 27 Feb 2012 14:43: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 1S21nT-0004xo-Ss
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:43:27 +0000
Received: from [85.158.139.83:10322] by server-9.bemta-5.messagelabs.com id
	F6/87-30171-E869B4F4; Mon, 27 Feb 2012 14:43:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330353805!16237472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24395 invoked from network); 27 Feb 2012 14:43:26 -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;
	27 Feb 2012 14:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10957439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 14:43:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 14:43:25 +0000
Message-ID: <1330353804.8557.290.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 27 Feb 2012 14:43:24 +0000
References: <4F3D393A.7070500@gmail.com>
In-Reply-To: <4F3D393A.7070500@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] TODAY: Xen Document 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

Today is a Xen Document Day!

Apologies for not announcing this sooner, my previous attempt this
morning was caught in the spam trap due to a reference to the etherpad
page.

Please join us on IRC: freenode channel #xendocday to coordinate (avoid
duplication of effort) and chat with the others who are taking part etc.

See http://wiki.xen.org/wiki/Xen_Document_Days for more information.
There is also an etherpad linked to from that page. This contains a
todo list etc.

Xen Document Days are now a regular event on the last Monday of the
month. The next one will be March 26.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:43:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:43:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21nV-0004yC-5i; Mon, 27 Feb 2012 14:43: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 1S21nT-0004xo-Ss
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:43:27 +0000
Received: from [85.158.139.83:10322] by server-9.bemta-5.messagelabs.com id
	F6/87-30171-E869B4F4; Mon, 27 Feb 2012 14:43:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330353805!16237472!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24395 invoked from network); 27 Feb 2012 14:43:26 -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;
	27 Feb 2012 14:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10957439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 14:43:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 14:43:25 +0000
Message-ID: <1330353804.8557.290.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Date: Mon, 27 Feb 2012 14:43:24 +0000
References: <4F3D393A.7070500@gmail.com>
In-Reply-To: <4F3D393A.7070500@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-arm@lists.xen.org" <xen-arm@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] TODAY: Xen Document 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

Today is a Xen Document Day!

Apologies for not announcing this sooner, my previous attempt this
morning was caught in the spam trap due to a reference to the etherpad
page.

Please join us on IRC: freenode channel #xendocday to coordinate (avoid
duplication of effort) and chat with the others who are taking part etc.

See http://wiki.xen.org/wiki/Xen_Document_Days for more information.
There is also an etherpad linked to from that page. This contains a
todo list etc.

Xen Document Days are now a regular event on the last Monday of the
month. The next one will be March 26.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21pj-0005Cz-B2; Mon, 27 Feb 2012 14:45:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S21ph-0005CQ-VY
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 14:45:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330353907!58498585!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI3\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4867 invoked from network); 27 Feb 2012 14:45:07 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-27.messagelabs.com with SMTP;
	27 Feb 2012 14:45:07 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id BCD385EC082;
	Mon, 27 Feb 2012 06:45:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=L5xDE+wYUu2xhb6BuZvvyIyGKlAAQtBQrsegMgLTbdcG
	EFOTHpX8h0yHHetlBcaavgNNOYrLgJKpS75Aby4lbCNTN4iVwQTTYmAmYoAoEhJ4
	MYoYhusRqmVtvdOn6yI1ruo8feHjkY0MEjNva3ZPPy0V8zUCD+KvASOWZF+0LBc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=oWQki8qxaUJYQysYX0wjGitsFVY=; b=tEGElMHG
	xFs46Qx1De2lvv7wOoPFg/KkJOf3mW4wZ7DLhpFfoIsKW3o56HdNbspnTIqIiSgy
	GIq41/rPwyl5Equwmoh5hIXU9WvQSeZLbNvcUo/sU0rj5hiZmlbR5TszSfdn0cb7
	YDR4vaTK5CamLcSGipe8PIP5HMSULsAb78Y=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 65F815EC072; 
	Mon, 27 Feb 2012 06:45:38 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 27 Feb 2012 06:45:38 -0800
Message-ID: <9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330335877.8557.253.camel@zakaz.uk.xensource.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 06:45:38 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>> shared page gains you nothing. The ballooner can't know what is shared
>> and what isn't, in order to make an educated decision. And the sharer
>> can't foresee what the balloon will victimize.
>
> Doesn't ballooning generally evict unused pages, because it allocates
> new _free_ pages, even if they were shared is there any benefit to doing
> so?

Certainly the balloon will pick free pages. The sharing daemon should not
have shared those, but it's not unlikely that it will have.

It's a classic semantic gap problem, and we were discussing this in the
context of paging ("the pager should not have paged out page table pages")

Beyond free pages, a prime target for sharing are read-only disk buffers
in the page cache. Those are victim #2 for the balloon.

>
> Or is it more of a second order effect, e.g. ballooning can cause the
> guest to swap out stuff which could have been shared?
>

Absolutely.

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 Feb 27 14:46:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21pj-0005Cz-B2; Mon, 27 Feb 2012 14:45:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S21ph-0005CQ-VY
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 14:45:46 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330353907!58498585!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI3\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3ODI3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4867 invoked from network); 27 Feb 2012 14:45:07 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-13.tower-27.messagelabs.com with SMTP;
	27 Feb 2012 14:45:07 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id BCD385EC082;
	Mon, 27 Feb 2012 06:45:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=L5xDE+wYUu2xhb6BuZvvyIyGKlAAQtBQrsegMgLTbdcG
	EFOTHpX8h0yHHetlBcaavgNNOYrLgJKpS75Aby4lbCNTN4iVwQTTYmAmYoAoEhJ4
	MYoYhusRqmVtvdOn6yI1ruo8feHjkY0MEjNva3ZPPy0V8zUCD+KvASOWZF+0LBc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=oWQki8qxaUJYQysYX0wjGitsFVY=; b=tEGElMHG
	xFs46Qx1De2lvv7wOoPFg/KkJOf3mW4wZ7DLhpFfoIsKW3o56HdNbspnTIqIiSgy
	GIq41/rPwyl5Equwmoh5hIXU9WvQSeZLbNvcUo/sU0rj5hiZmlbR5TszSfdn0cb7
	YDR4vaTK5CamLcSGipe8PIP5HMSULsAb78Y=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 65F815EC072; 
	Mon, 27 Feb 2012 06:45:38 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 27 Feb 2012 06:45:38 -0800
Message-ID: <9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330335877.8557.253.camel@zakaz.uk.xensource.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 06:45:38 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>> shared page gains you nothing. The ballooner can't know what is shared
>> and what isn't, in order to make an educated decision. And the sharer
>> can't foresee what the balloon will victimize.
>
> Doesn't ballooning generally evict unused pages, because it allocates
> new _free_ pages, even if they were shared is there any benefit to doing
> so?

Certainly the balloon will pick free pages. The sharing daemon should not
have shared those, but it's not unlikely that it will have.

It's a classic semantic gap problem, and we were discussing this in the
context of paging ("the pager should not have paged out page table pages")

Beyond free pages, a prime target for sharing are read-only disk buffers
in the page cache. Those are victim #2 for the balloon.

>
> Or is it more of a second order effect, e.g. ballooning can cause the
> guest to swap out stuff which could have been shared?
>

Absolutely.

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 Feb 27 14:47:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21qq-0005La-PQ; Mon, 27 Feb 2012 14:46:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qp-0005LB-55
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:46:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353961!51570924!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31764 invoked from network); 27 Feb 2012 14:46:01 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:01 -0000
Received: by wgbed3 with SMTP id ed3so1024333wgb.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:53 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.99.100 as permitted sender) client-ip=10.180.99.100; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.99.100 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.99.100])
	by 10.180.99.100 with SMTP id ep4mr28834267wib.7.1330354013896
	(num_hops = 1); Mon, 27 Feb 2012 06:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=/3WPEQ63zVRx7asyVTQPPgFrU+yPxgfMsz1rqNANCxE=;
	b=G0bhzzN9B/6uYeCFdBI4IkGQ63x40CsPSYUuCToyAmGNWnypjY1uzn2r0ZgeyvpUvB
	JRuKQ8QKK5P5furpRRsB1ar8POFfb0MlgcA5IfqKi7PztYpP/a4ao0rC81VDVG9WRDCs
	NALFtjgQ7dq8YAF9M720U6Uu38QM3dvILxyLM=
Received: by 10.180.99.100 with SMTP id ep4mr22873621wib.7.1330354013810;
	Mon, 27 Feb 2012 06:46:53 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:53 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:53 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 8 v2] Several fixes for autoconf and Linux
	init 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

Fix autoconf under NetBSD and add some tests to Linux xencommons to
check for the necessary tools to run hotplug scripts.

Changes since v1:

 * included /lib/lsb/init-functions in xencommons and xend.

 * Changed `hash` with `type`.

 * Move python xml check to xend init script.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21qq-0005La-PQ; Mon, 27 Feb 2012 14:46:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qp-0005LB-55
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:46:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353961!51570924!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31764 invoked from network); 27 Feb 2012 14:46:01 -0000
Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com)
	(74.125.82.51)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:01 -0000
Received: by wgbed3 with SMTP id ed3so1024333wgb.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:53 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.99.100 as permitted sender) client-ip=10.180.99.100; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.99.100 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.99.100])
	by 10.180.99.100 with SMTP id ep4mr28834267wib.7.1330354013896
	(num_hops = 1); Mon, 27 Feb 2012 06:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=/3WPEQ63zVRx7asyVTQPPgFrU+yPxgfMsz1rqNANCxE=;
	b=G0bhzzN9B/6uYeCFdBI4IkGQ63x40CsPSYUuCToyAmGNWnypjY1uzn2r0ZgeyvpUvB
	JRuKQ8QKK5P5furpRRsB1ar8POFfb0MlgcA5IfqKi7PztYpP/a4ao0rC81VDVG9WRDCs
	NALFtjgQ7dq8YAF9M720U6Uu38QM3dvILxyLM=
Received: by 10.180.99.100 with SMTP id ep4mr22873621wib.7.1330354013810;
	Mon, 27 Feb 2012 06:46:53 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:53 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:53 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 8 v2] Several fixes for autoconf and Linux
	init 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

Fix autoconf under NetBSD and add some tests to Linux xencommons to
check for the necessary tools to run hotplug scripts.

Changes since v1:

 * included /lib/lsb/init-functions in xencommons and xend.

 * Changed `hash` with `type`.

 * Move python xml check to xend init script.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qu-0005MR-6E; Mon, 27 Feb 2012 14:47:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qs-0005Lu-Fj
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:46:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353964!51570935!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31927 invoked from network); 27 Feb 2012 14:46:04 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:04 -0000
Received: by werp12 with SMTP id p12so1308780wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:56 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.86.134 as permitted sender) client-ip=10.180.86.134; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.86.134 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.86.134])
	by 10.180.86.134 with SMTP id p6mr28648279wiz.0.1330354016663 (num_hops
	= 1); Mon, 27 Feb 2012 06:46:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zTEy/xkCV5jKballN6W96o2gvPo8z3PjSt5xVSoEo7E=;
	b=XReJjFQDVOHShMAimV2MO6r+wsLhKWOliRMLQHMG4inPpZgz5lin6HA/QZajLDFbLv
	gtlLaMUu7SuXrMgZhl4lXy/8LQS9Tu8/405MHCvnvl1tsuaCy4a3RFSE5u3SyMOtgR5v
	pCEeSw6d7I34hj9Ga1+wYwy4EBH2CBgvJAOfE=
Received: by 10.180.86.134 with SMTP id p6mr22734944wiz.0.1330354016612;
	Mon, 27 Feb 2012 06:46:56 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3aafecc004fd5339e88363615e7e9de727d2a5b9
Message-Id: <3aafecc004fd5339e883.1329880735@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:55 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 8 v2] autoconf: remove ip 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330003783 -3600
# Node ID 3aafecc004fd5339e88363615e7e9de727d2a5b9
# Parent  4081a567e9767efc5460010d71dd07a42ea86666
autoconf: remove ip check

ip is a run-time dependency, and it is not needed to build Xen tools.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 4081a567e976 -r 3aafecc004fd config/Tools.mk.in
--- a/config/Tools.mk.in	Wed Feb 22 02:53:42 2012 +0100
+++ b/config/Tools.mk.in	Thu Feb 23 14:29:43 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@
 BASH                := @BASH@
diff -r 4081a567e976 -r 3aafecc004fd tools/configure
--- a/tools/configure	Wed Feb 22 02:53:42 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:29:43 2012 +0100
@@ -637,7 +637,6 @@ XML
 CURL
 FLEX
 BISON
-IP
 PERL
 PYTHON
 APPEND_LIB
@@ -739,7 +738,6 @@ APPEND_INCLUDES
 APPEND_LIB
 PYTHON
 PERL
-IP
 BISON
 FLEX
 CURL
@@ -1394,7 +1392,6 @@ Some influential environment variables:
   APPEND_LIB  List of library folders to append to LDFLAGS (without -L)
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
-  IP          Path to ip tool
   BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
   CURL        Path to curl-config tool
@@ -4158,7 +4155,6 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPE
 
 
 
-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
@@ -4949,51 +4945,6 @@ if test x"${PERL}" == x"no"
 then
     as_fn_error $? "Unable to find perl, please install perl" "$LINENO" 5
 fi
-# Extract the first word of "ip", so it can be a program name with args.
-set dummy ip; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_IP+set}" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $IP in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_IP="$IP" # Let the user override the test with a path.
-  ;;
-  *)
-  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
-    ac_cv_path_IP="$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=$as_save_IFS
-
-  test -z "$ac_cv_path_IP" && ac_cv_path_IP="no"
-  ;;
-esac
-fi
-IP=$ac_cv_path_IP
-if test -n "$IP"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $IP" >&5
-$as_echo "$IP" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-if test x"${IP}" == x"no"
-then
-    as_fn_error $? "Unable to find ip, please install ip" "$LINENO" 5
-fi
 # Extract the first word of "bison", so it can be a program name with args.
 set dummy bison; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
diff -r 4081a567e976 -r 3aafecc004fd tools/configure.ac
--- a/tools/configure.ac	Wed Feb 22 02:53:42 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
@@ -62,7 +62,6 @@ AX_SET_FLAGS
 
 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
-AC_ARG_VAR([IP], [Path to ip tool])
 AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
 AC_ARG_VAR([CURL], [Path to curl-config tool])
@@ -77,7 +76,6 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
-AX_PATH_PROG_OR_FAIL([IP], [ip])
 AX_PATH_PROG_OR_FAIL([BISON], [bison])
 AX_PATH_PROG_OR_FAIL([FLEX], [flex])
 AS_IF([test "x$xapi" = "xy"], [

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qu-0005MR-6E; Mon, 27 Feb 2012 14:47:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qs-0005Lu-Fj
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:46:58 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353964!51570935!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31927 invoked from network); 27 Feb 2012 14:46:04 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:04 -0000
Received: by werp12 with SMTP id p12so1308780wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:56 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.86.134 as permitted sender) client-ip=10.180.86.134; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.86.134 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.86.134])
	by 10.180.86.134 with SMTP id p6mr28648279wiz.0.1330354016663 (num_hops
	= 1); Mon, 27 Feb 2012 06:46:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=zTEy/xkCV5jKballN6W96o2gvPo8z3PjSt5xVSoEo7E=;
	b=XReJjFQDVOHShMAimV2MO6r+wsLhKWOliRMLQHMG4inPpZgz5lin6HA/QZajLDFbLv
	gtlLaMUu7SuXrMgZhl4lXy/8LQS9Tu8/405MHCvnvl1tsuaCy4a3RFSE5u3SyMOtgR5v
	pCEeSw6d7I34hj9Ga1+wYwy4EBH2CBgvJAOfE=
Received: by 10.180.86.134 with SMTP id p6mr22734944wiz.0.1330354016612;
	Mon, 27 Feb 2012 06:46:56 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3aafecc004fd5339e88363615e7e9de727d2a5b9
Message-Id: <3aafecc004fd5339e883.1329880735@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:55 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 8 v2] autoconf: remove ip 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330003783 -3600
# Node ID 3aafecc004fd5339e88363615e7e9de727d2a5b9
# Parent  4081a567e9767efc5460010d71dd07a42ea86666
autoconf: remove ip check

ip is a run-time dependency, and it is not needed to build Xen tools.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 4081a567e976 -r 3aafecc004fd config/Tools.mk.in
--- a/config/Tools.mk.in	Wed Feb 22 02:53:42 2012 +0100
+++ b/config/Tools.mk.in	Thu Feb 23 14:29:43 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@
 BASH                := @BASH@
diff -r 4081a567e976 -r 3aafecc004fd tools/configure
--- a/tools/configure	Wed Feb 22 02:53:42 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:29:43 2012 +0100
@@ -637,7 +637,6 @@ XML
 CURL
 FLEX
 BISON
-IP
 PERL
 PYTHON
 APPEND_LIB
@@ -739,7 +738,6 @@ APPEND_INCLUDES
 APPEND_LIB
 PYTHON
 PERL
-IP
 BISON
 FLEX
 CURL
@@ -1394,7 +1392,6 @@ Some influential environment variables:
   APPEND_LIB  List of library folders to append to LDFLAGS (without -L)
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
-  IP          Path to ip tool
   BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
   CURL        Path to curl-config tool
@@ -4158,7 +4155,6 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPE
 
 
 
-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
@@ -4949,51 +4945,6 @@ if test x"${PERL}" == x"no"
 then
     as_fn_error $? "Unable to find perl, please install perl" "$LINENO" 5
 fi
-# Extract the first word of "ip", so it can be a program name with args.
-set dummy ip; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if test "${ac_cv_path_IP+set}" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  case $IP in
-  [\\/]* | ?:[\\/]*)
-  ac_cv_path_IP="$IP" # Let the user override the test with a path.
-  ;;
-  *)
-  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-    for ac_exec_ext in '' $ac_executable_extensions; do
-  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
-    ac_cv_path_IP="$as_dir/$ac_word$ac_exec_ext"
-    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
-    break 2
-  fi
-done
-  done
-IFS=$as_save_IFS
-
-  test -z "$ac_cv_path_IP" && ac_cv_path_IP="no"
-  ;;
-esac
-fi
-IP=$ac_cv_path_IP
-if test -n "$IP"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $IP" >&5
-$as_echo "$IP" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
-if test x"${IP}" == x"no"
-then
-    as_fn_error $? "Unable to find ip, please install ip" "$LINENO" 5
-fi
 # Extract the first word of "bison", so it can be a program name with args.
 set dummy bison; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
diff -r 4081a567e976 -r 3aafecc004fd tools/configure.ac
--- a/tools/configure.ac	Wed Feb 22 02:53:42 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
@@ -62,7 +62,6 @@ AX_SET_FLAGS
 
 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
-AC_ARG_VAR([IP], [Path to ip tool])
 AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
 AC_ARG_VAR([CURL], [Path to curl-config tool])
@@ -77,7 +76,6 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_INSTALL
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
-AX_PATH_PROG_OR_FAIL([IP], [ip])
 AX_PATH_PROG_OR_FAIL([BISON], [bison])
 AX_PATH_PROG_OR_FAIL([FLEX], [flex])
 AS_IF([test "x$xapi" = "xy"], [

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qy-0005OG-TB; Mon, 27 Feb 2012 14:47:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qx-0005Lt-Af
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21553 invoked from network); 27 Feb 2012 14:46:57 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:57 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:57 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.5 as permitted sender) client-ip=10.216.134.5; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.5 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.5])
	by 10.216.134.5 with SMTP id r5mr7208735wei.39.1330354017335 (num_hops
	= 1); Mon, 27 Feb 2012 06:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=WuROqMBjrFxru44qmjzwdsjRng1JdNzurobbFN2iWIU=;
	b=RzMKh/2YTZgy7TV43cQJ5jbmrxn+/wuzvIvGBibod4ToRb1HBFsdFE1PRHMpb7iV9Q
	hdl74sYMnFN/AZ1b4V2MKb+aH83+o6Rdil8YgLsDDvrVzgGQquMyxreWfrvo46Xm7TT2
	DIP5Ot21/cUj1RazpuwX93cvJa0iXE6+26Dog=
Received: by 10.216.134.5 with SMTP id r5mr5721030wei.39.1330354017284;
	Mon, 27 Feb 2012 06:46:57 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:56 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a41d13f080d9fad38fd05ed87696502fe18c281c
Message-Id: <a41d13f080d9fad38fd0.1329880736@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:56 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 8 v2] autoconf: remove python xml 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329880533 -3600
# Node ID a41d13f080d9fad38fd05ed87696502fe18c281c
# Parent  3aafecc004fd5339e88363615e7e9de727d2a5b9
autoconf: remove python xml check

Remove the xml module check from autoconf and move it to xend init
script (in a later patch), since it's a run time dependency.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3aafecc004fd -r a41d13f080d9 tools/configure
--- a/tools/configure	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure	Wed Feb 22 04:15:33 2012 +0100
@@ -3846,8 +3846,6 @@ case $host_os in *\ *) host_os=`echo "$h
 
 
 
-
-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -6255,18 +6253,6 @@ else
     { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
 fi
-    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python xml.dom.minidom" >&5
-$as_echo_n "checking for python xml.dom.minidom... " >&6; }
-`$PYTHON -c 'import xml.dom.minidom'`
-if test "$?" != "0"
-then
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-    as_fn_error $? "Unable to find xml.dom.minidom module" "$LINENO" 5
-else
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
-$as_echo "yes" >&6; }
-fi
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python devel" >&5
 $as_echo_n "checking for python devel... " >&6; }
 
diff -r 3aafecc004fd -r a41d13f080d9 tools/configure.ac
--- a/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure.ac	Wed Feb 22 04:15:33 2012 +0100
@@ -26,7 +26,6 @@ AC_CANONICAL_HOST
 m4_include([m4/enable_feature.m4])
 m4_include([m4/disable_feature.m4])
 m4_include([m4/path_or_fail.m4])
-m4_include([m4/python_xml.m4])
 m4_include([m4/python_version.m4])
 m4_include([m4/python_devel.m4])
 m4_include([m4/ocaml.m4])
@@ -99,7 +98,6 @@ AS_IF([test "x$pythontools" = "xy"], [
     [AC_MSG_ERROR([PYTHON specified, but is not an absolute path])])
     AX_PATH_PROG_OR_FAIL([PYTHONPATH], [$PYTHON])
     AX_CHECK_PYTHON_VERSION([2], [3])
-    AX_CHECK_PYTHON_XML()
     AX_CHECK_PYTHON_DEVEL()
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
diff -r 3aafecc004fd -r a41d13f080d9 tools/m4/python_xml.m4
--- a/tools/m4/python_xml.m4	Thu Feb 23 14:29:43 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,10 +0,0 @@
-AC_DEFUN([AX_CHECK_PYTHON_XML],
-[AC_MSG_CHECKING([for python xml.dom.minidom])
-`$PYTHON -c 'import xml.dom.minidom'`
-if test "$?" != "0"
-then
-    AC_MSG_RESULT([no])
-    AC_MSG_ERROR([Unable to find xml.dom.minidom module])
-else
-    AC_MSG_RESULT([yes])
-fi])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qy-0005OG-TB; Mon, 27 Feb 2012 14:47:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qx-0005Lt-Af
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!2
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21553 invoked from network); 27 Feb 2012 14:46:57 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:57 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:57 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.5 as permitted sender) client-ip=10.216.134.5; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.5 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.5])
	by 10.216.134.5 with SMTP id r5mr7208735wei.39.1330354017335 (num_hops
	= 1); Mon, 27 Feb 2012 06:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=WuROqMBjrFxru44qmjzwdsjRng1JdNzurobbFN2iWIU=;
	b=RzMKh/2YTZgy7TV43cQJ5jbmrxn+/wuzvIvGBibod4ToRb1HBFsdFE1PRHMpb7iV9Q
	hdl74sYMnFN/AZ1b4V2MKb+aH83+o6Rdil8YgLsDDvrVzgGQquMyxreWfrvo46Xm7TT2
	DIP5Ot21/cUj1RazpuwX93cvJa0iXE6+26Dog=
Received: by 10.216.134.5 with SMTP id r5mr5721030wei.39.1330354017284;
	Mon, 27 Feb 2012 06:46:57 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:56 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a41d13f080d9fad38fd05ed87696502fe18c281c
Message-Id: <a41d13f080d9fad38fd0.1329880736@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:56 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 8 v2] autoconf: remove python xml 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329880533 -3600
# Node ID a41d13f080d9fad38fd05ed87696502fe18c281c
# Parent  3aafecc004fd5339e88363615e7e9de727d2a5b9
autoconf: remove python xml check

Remove the xml module check from autoconf and move it to xend init
script (in a later patch), since it's a run time dependency.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3aafecc004fd -r a41d13f080d9 tools/configure
--- a/tools/configure	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure	Wed Feb 22 04:15:33 2012 +0100
@@ -3846,8 +3846,6 @@ case $host_os in *\ *) host_os=`echo "$h
 
 
 
-
-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -6255,18 +6253,6 @@ else
     { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
 fi
-    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python xml.dom.minidom" >&5
-$as_echo_n "checking for python xml.dom.minidom... " >&6; }
-`$PYTHON -c 'import xml.dom.minidom'`
-if test "$?" != "0"
-then
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-    as_fn_error $? "Unable to find xml.dom.minidom module" "$LINENO" 5
-else
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
-$as_echo "yes" >&6; }
-fi
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python devel" >&5
 $as_echo_n "checking for python devel... " >&6; }
 
diff -r 3aafecc004fd -r a41d13f080d9 tools/configure.ac
--- a/tools/configure.ac	Thu Feb 23 14:29:43 2012 +0100
+++ b/tools/configure.ac	Wed Feb 22 04:15:33 2012 +0100
@@ -26,7 +26,6 @@ AC_CANONICAL_HOST
 m4_include([m4/enable_feature.m4])
 m4_include([m4/disable_feature.m4])
 m4_include([m4/path_or_fail.m4])
-m4_include([m4/python_xml.m4])
 m4_include([m4/python_version.m4])
 m4_include([m4/python_devel.m4])
 m4_include([m4/ocaml.m4])
@@ -99,7 +98,6 @@ AS_IF([test "x$pythontools" = "xy"], [
     [AC_MSG_ERROR([PYTHON specified, but is not an absolute path])])
     AX_PATH_PROG_OR_FAIL([PYTHONPATH], [$PYTHON])
     AX_CHECK_PYTHON_VERSION([2], [3])
-    AX_CHECK_PYTHON_XML()
     AX_CHECK_PYTHON_DEVEL()
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
diff -r 3aafecc004fd -r a41d13f080d9 tools/m4/python_xml.m4
--- a/tools/m4/python_xml.m4	Thu Feb 23 14:29:43 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,10 +0,0 @@
-AC_DEFUN([AX_CHECK_PYTHON_XML],
-[AC_MSG_CHECKING([for python xml.dom.minidom])
-`$PYTHON -c 'import xml.dom.minidom'`
-if test "$?" != "0"
-then
-    AC_MSG_RESULT([no])
-    AC_MSG_ERROR([Unable to find xml.dom.minidom module])
-else
-    AC_MSG_RESULT([yes])
-fi])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qu-0005Mf-Hv; Mon, 27 Feb 2012 14:47:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qt-0005MB-KA
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:46:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353964!51570935!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32105 invoked from network); 27 Feb 2012 14:46:05 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:05 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so1308780wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:58 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.181.11.227 as permitted sender) client-ip=10.181.11.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.181.11.227 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.181.11.227])
	by 10.181.11.227 with SMTP id el3mr28666554wid.18.1330354018418
	(num_hops = 1); Mon, 27 Feb 2012 06:46:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Lo5VQdOJ8qbLkzJORtfQg63tEvZPRO+5SL3ze5FTALw=;
	b=fHOJ1O83IxdjGUSSz64sNkMoQEx8HVQQId00tGUUCz7u+LvpDB2x+ZBsMAI1hey2Ow
	zSzGA3x+9iuBzGK6iaMn5Lo4uyNlTqEWIflHwWlt58mDw53UF+pgOutSx23gGKwmaRtn
	JG11pil5TDjqWrdmjglaOXGU12Gs8M6IH+WOU=
Received: by 10.181.11.227 with SMTP id el3mr22686712wid.18.1330354018358;
	Mon, 27 Feb 2012 06:46:58 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 493ca332d663c3c5ac12fd199d279188642089e6
Message-Id: <493ca332d663c3c5ac12.1329880737@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:57 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 8 v2] autoconf: run libuuid test under
	Linux 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330004063 -3600
# Node ID 493ca332d663c3c5ac12fd199d279188642089e6
# Parent  a41d13f080d9fad38fd05ed87696502fe18c281c
autoconf: run libuuid test under Linux only

libuuid is only required to compile Xen tools under Linux.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a41d13f080d9 -r 493ca332d663 tools/configure
--- a/tools/configure	Wed Feb 22 04:15:33 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:34:23 2012 +0100
@@ -6826,7 +6826,9 @@ if test "x$ac_cv_lib_rt_clock_gettime" =
 
 fi
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
+if test "x$host_os" == "xlinux-gnu"; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
 if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
   $as_echo_n "(cached) " >&6
@@ -6873,6 +6875,8 @@ else
   as_fn_error $? "Could not find libuuid" "$LINENO" 5
 fi
 
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff -r a41d13f080d9 -r 493ca332d663 tools/configure.ac
--- a/tools/configure.ac	Wed Feb 22 04:15:33 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:34:23 2012 +0100
@@ -118,8 +118,10 @@ AC_SUBST(libgcrypt)
 AC_CHECK_LIB([pthread], [pthread_create], [] ,
     [AC_MSG_ERROR([Could not find libpthread])])
 AC_CHECK_LIB([rt], [clock_gettime])
-AC_CHECK_LIB([uuid], [uuid_clear], [],
-    [AC_MSG_ERROR([Could not find libuuid])])
+AS_IF([test "x$host_os" == "xlinux-gnu"], [
+    AC_CHECK_LIB([uuid], [uuid_clear], [],
+        [AC_MSG_ERROR([Could not find libuuid])])
+])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qu-0005Mf-Hv; Mon, 27 Feb 2012 14:47:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qt-0005MB-KA
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:46:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353964!51570935!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32105 invoked from network); 27 Feb 2012 14:46:05 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:05 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so1308780wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:58 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.181.11.227 as permitted sender) client-ip=10.181.11.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.181.11.227 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.181.11.227])
	by 10.181.11.227 with SMTP id el3mr28666554wid.18.1330354018418
	(num_hops = 1); Mon, 27 Feb 2012 06:46:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=Lo5VQdOJ8qbLkzJORtfQg63tEvZPRO+5SL3ze5FTALw=;
	b=fHOJ1O83IxdjGUSSz64sNkMoQEx8HVQQId00tGUUCz7u+LvpDB2x+ZBsMAI1hey2Ow
	zSzGA3x+9iuBzGK6iaMn5Lo4uyNlTqEWIflHwWlt58mDw53UF+pgOutSx23gGKwmaRtn
	JG11pil5TDjqWrdmjglaOXGU12Gs8M6IH+WOU=
Received: by 10.181.11.227 with SMTP id el3mr22686712wid.18.1330354018358;
	Mon, 27 Feb 2012 06:46:58 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 493ca332d663c3c5ac12fd199d279188642089e6
Message-Id: <493ca332d663c3c5ac12.1329880737@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:57 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 8 v2] autoconf: run libuuid test under
	Linux 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1330004063 -3600
# Node ID 493ca332d663c3c5ac12fd199d279188642089e6
# Parent  a41d13f080d9fad38fd05ed87696502fe18c281c
autoconf: run libuuid test under Linux only

libuuid is only required to compile Xen tools under Linux.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a41d13f080d9 -r 493ca332d663 tools/configure
--- a/tools/configure	Wed Feb 22 04:15:33 2012 +0100
+++ b/tools/configure	Thu Feb 23 14:34:23 2012 +0100
@@ -6826,7 +6826,9 @@ if test "x$ac_cv_lib_rt_clock_gettime" =
 
 fi
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
+if test "x$host_os" == "xlinux-gnu"; then :
+
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
 if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
   $as_echo_n "(cached) " >&6
@@ -6873,6 +6875,8 @@ else
   as_fn_error $? "Could not find libuuid" "$LINENO" 5
 fi
 
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
 if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
diff -r a41d13f080d9 -r 493ca332d663 tools/configure.ac
--- a/tools/configure.ac	Wed Feb 22 04:15:33 2012 +0100
+++ b/tools/configure.ac	Thu Feb 23 14:34:23 2012 +0100
@@ -118,8 +118,10 @@ AC_SUBST(libgcrypt)
 AC_CHECK_LIB([pthread], [pthread_create], [] ,
     [AC_MSG_ERROR([Could not find libpthread])])
 AC_CHECK_LIB([rt], [clock_gettime])
-AC_CHECK_LIB([uuid], [uuid_clear], [],
-    [AC_MSG_ERROR([Could not find libuuid])])
+AS_IF([test "x$host_os" == "xlinux-gnu"], [
+    AC_CHECK_LIB([uuid], [uuid_clear], [],
+        [AC_MSG_ERROR([Could not find libuuid])])
+])
 AC_CHECK_LIB([yajl], [yajl_alloc], [],
     [AC_MSG_ERROR([Could not find yajl])])
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qx-0005NS-BE; Mon, 27 Feb 2012 14:47:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qv-0005Mz-PB
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353964!51570935!3
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32204 invoked from network); 27 Feb 2012 14:46:08 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:08 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so1308780wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:47:00 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.80.35 as permitted sender) client-ip=10.180.80.35; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.80.35 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.80.35])
	by 10.180.80.35 with SMTP id o3mr29081519wix.5.1330354020677 (num_hops
	= 1); Mon, 27 Feb 2012 06:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=i63IPEAKczkc4iGXajVZhuSV7XkDAygatlN3iGiD/2g=;
	b=TD3BSjYF6yLlDIgG6X6P7EX9VxrjVEHHHfWcPpR2hW/JrzogiRSoBRXEqBy00GEMBO
	uB1j6TLKsNb2u5pVM9HKyX7vLxHXZ2jUocsbNYHdOBRZ96/zba6VMgLYCCvUZcU9nXxg
	a8vhHyuGr0djJAF8Si34rQf6LXZnKYh4YrjIE=
Received: by 10.180.80.35 with SMTP id o3mr23048118wix.5.1330354020614;
	Mon, 27 Feb 2012 06:47:00 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:47:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a26c5eadc56fe15af5e40600a3851b4d64be6389
Message-Id: <a26c5eadc56fe15af5e4.1329880740@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:19:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 8 v2] Linux/init: check for udev >= 59 at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329814249 -3600
# Node ID a26c5eadc56fe15af5e40600a3851b4d64be6389
# Parent  417702b27ab78ad554062a065fa3f51af091b3b3
Linux/init: check for udev >= 59 at xencommons

Check for udev at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 417702b27ab7 -r a26c5eadc56f tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:50:49 2012 +0100
@@ -70,6 +70,28 @@ do
 		log_warning_msg "$servicename: $tool not found"
 done
 
+# Check for udev >= 59
+if ! type udevadm > /dev/null 2>&1
+then
+	if ! type udevinfo > /dev/null 2>&1
+	then
+		log_warning_msg "$servicename: unable to find" \
+				" udevadm or udevinfo"
+	else
+		udevver=`udevinfo -V | awk '{print $NF}'`
+	fi
+else
+	udevver=`udevadm info -V | awk '{print $NF}'`
+fi
+if test -z "${udevver}" || test "${udevver}" -lt 59
+then
+	if ! type hotplug > /dev/null 2>&1
+	then
+		log_warning_msg "$servicename: udev is too old," \
+				" upgrade to version 59"
+	fi
+fi
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14: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 1S21qx-0005NS-BE; Mon, 27 Feb 2012 14:47:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qv-0005Mz-PB
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330353964!51570935!3
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32204 invoked from network); 27 Feb 2012 14:46:08 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:08 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so1308780wer.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:47:00 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.80.35 as permitted sender) client-ip=10.180.80.35; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.80.35 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.80.35])
	by 10.180.80.35 with SMTP id o3mr29081519wix.5.1330354020677 (num_hops
	= 1); Mon, 27 Feb 2012 06:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=i63IPEAKczkc4iGXajVZhuSV7XkDAygatlN3iGiD/2g=;
	b=TD3BSjYF6yLlDIgG6X6P7EX9VxrjVEHHHfWcPpR2hW/JrzogiRSoBRXEqBy00GEMBO
	uB1j6TLKsNb2u5pVM9HKyX7vLxHXZ2jUocsbNYHdOBRZ96/zba6VMgLYCCvUZcU9nXxg
	a8vhHyuGr0djJAF8Si34rQf6LXZnKYh4YrjIE=
Received: by 10.180.80.35 with SMTP id o3mr23048118wix.5.1330354020614;
	Mon, 27 Feb 2012 06:47:00 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:47:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a26c5eadc56fe15af5e40600a3851b4d64be6389
Message-Id: <a26c5eadc56fe15af5e4.1329880740@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:19:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 8 v2] Linux/init: check for udev >= 59 at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329814249 -3600
# Node ID a26c5eadc56fe15af5e40600a3851b4d64be6389
# Parent  417702b27ab78ad554062a065fa3f51af091b3b3
Linux/init: check for udev >= 59 at xencommons

Check for udev at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 417702b27ab7 -r a26c5eadc56f tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:50:49 2012 +0100
@@ -70,6 +70,28 @@ do
 		log_warning_msg "$servicename: $tool not found"
 done
 
+# Check for udev >= 59
+if ! type udevadm > /dev/null 2>&1
+then
+	if ! type udevinfo > /dev/null 2>&1
+	then
+		log_warning_msg "$servicename: unable to find" \
+				" udevadm or udevinfo"
+	else
+		udevver=`udevinfo -V | awk '{print $NF}'`
+	fi
+else
+	udevver=`udevadm info -V | awk '{print $NF}'`
+fi
+if test -z "${udevver}" || test "${udevver}" -lt 59
+then
+	if ! type hotplug > /dev/null 2>&1
+	then
+		log_warning_msg "$servicename: udev is too old," \
+				" upgrade to version 59"
+	fi
+fi
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21r1-0005Pn-NQ; Mon, 27 Feb 2012 14:47:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qz-0005Mc-Tw
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!4
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21694 invoked from network); 27 Feb 2012 14:46:59 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:59 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.37 as permitted sender) client-ip=10.216.134.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.37 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.37])
	by 10.216.134.37 with SMTP id r37mr7198813wei.38.1330354019904
	(num_hops = 1); Mon, 27 Feb 2012 06:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=YuDt+W8n7v/15KrbbDCsXml6oPpZI8ps7Xe7bsBspf4=;
	b=WyczBMKqhJtavp48t6kNTEdXcLCtQ+wxN5kcF7S2wp2Xt7W2iwNMuryfhwsTiREWzy
	BSarS9MJFJWaRkzouRiISAAkGe/tk8RMcyEB4MkOdoDA3Fgn1V4OU1ODdWC1k/rnKqvZ
	Vh3PlTkusGBc59+nzi1cN/CHebyljxyViudG4=
Received: by 10.216.134.37 with SMTP id r37mr5721273wei.38.1330354019858;
	Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 417702b27ab78ad554062a065fa3f51af091b3b3
Message-Id: <417702b27ab78ad55406.1329880739@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 8 v2] Linux/init: check for brctl and ip at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329811412 -3600
# Node ID 417702b27ab78ad554062a065fa3f51af091b3b3
# Parent  a74480347d40266afc2f192aeea21819557a483c
Linux/init: check for brctl and ip at xencommons

Check for brctl and ip at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a74480347d40 -r 417702b27ab7 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Wed Feb 22 04:15:34 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
@@ -27,6 +27,8 @@ else
 	exit 0
 fi
 
+servicename="xencommons"
+
 if [ -d /etc/sysconfig ]; then
 	xencommons_config=/etc/sysconfig
 else
@@ -59,6 +61,15 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# List of tools needed by xen (hotplug scripts)
+REQ_TOOLS="brctl ip"
+
+for tool in $REQ_TOOLS
+do
+	type $tool > /dev/null 2>&1 || \
+		log_warning_msg "$servicename: $tool not found"
+done
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21r1-0005Pn-NQ; Mon, 27 Feb 2012 14:47:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qz-0005Mc-Tw
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!4
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21694 invoked from network); 27 Feb 2012 14:46:59 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:59 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.37 as permitted sender) client-ip=10.216.134.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.37 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.37])
	by 10.216.134.37 with SMTP id r37mr7198813wei.38.1330354019904
	(num_hops = 1); Mon, 27 Feb 2012 06:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=YuDt+W8n7v/15KrbbDCsXml6oPpZI8ps7Xe7bsBspf4=;
	b=WyczBMKqhJtavp48t6kNTEdXcLCtQ+wxN5kcF7S2wp2Xt7W2iwNMuryfhwsTiREWzy
	BSarS9MJFJWaRkzouRiISAAkGe/tk8RMcyEB4MkOdoDA3Fgn1V4OU1ODdWC1k/rnKqvZ
	Vh3PlTkusGBc59+nzi1cN/CHebyljxyViudG4=
Received: by 10.216.134.37 with SMTP id r37mr5721273wei.38.1330354019858;
	Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 417702b27ab78ad554062a065fa3f51af091b3b3
Message-Id: <417702b27ab78ad55406.1329880739@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 8 v2] Linux/init: check for brctl and ip at
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329811412 -3600
# Node ID 417702b27ab78ad554062a065fa3f51af091b3b3
# Parent  a74480347d40266afc2f192aeea21819557a483c
Linux/init: check for brctl and ip at xencommons

Check for brctl and ip at xencommons, since hotplug scripts use it.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a74480347d40 -r 417702b27ab7 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Wed Feb 22 04:15:34 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Tue Feb 21 09:03:32 2012 +0100
@@ -27,6 +27,8 @@ else
 	exit 0
 fi
 
+servicename="xencommons"
+
 if [ -d /etc/sysconfig ]; then
 	xencommons_config=/etc/sysconfig
 else
@@ -59,6 +61,15 @@ if test -f /proc/xen/capabilities && \
 	exit 0
 fi
 
+# List of tools needed by xen (hotplug scripts)
+REQ_TOOLS="brctl ip"
+
+for tool in $REQ_TOOLS
+do
+	type $tool > /dev/null 2>&1 || \
+		log_warning_msg "$servicename: $tool not found"
+done
+
 do_start () {
         local time=0
 	local timeout=30

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21r0-0005P7-9p; Mon, 27 Feb 2012 14:47:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qz-0005MJ-6h
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!3
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21651 invoked from network); 27 Feb 2012 14:46:59 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:59 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.94.68 as permitted sender) client-ip=10.180.94.68; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.94.68 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.94.68])
	by 10.180.94.68 with SMTP id da4mr28671874wib.22.1330354019113
	(num_hops = 1); Mon, 27 Feb 2012 06:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JWl6bwXjOhKLZw7F2GR6lPrlTa93wAO39th1xAGM8yo=;
	b=O/uu0qJMe9PVfi3Kqz56/HK1Nn08hyHvMtmHuj70A/2YP2S6lXqoX4TEf+HGYGXJni
	nEVoRKGPOgMn9NOREdnd+QE7unOYTsXwOyy6tCPH0042WvwaxmlwHIPyyO1avawytQhg
	caGQPDtblmWbWsOLWHykQxVm8fXgmBkTKAQqk=
Received: by 10.180.94.68 with SMTP id da4mr22723312wib.22.1330354019068;
	Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a74480347d40266afc2f192aeea21819557a483c
Message-Id: <a74480347d40266afc2f.1329880738@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:58 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 8 v2] Linux/init: include init-functions on
 xencommons and xend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329880534 -3600
# Node ID a74480347d40266afc2f192aeea21819557a483c
# Parent  493ca332d663c3c5ac12fd199d279188642089e6
Linux/init: include init-functions on xencommons and xend

Try to include /lib/lsb/init-functions on xencommons and xend or fail
with and error message. Later patches make use of the functions
present on this file.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 493ca332d663 -r a74480347d40 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 14:34:23 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Wed Feb 22 04:15:34 2012 +0100
@@ -18,6 +18,15 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
+# Include init script functions
+if test -f /lib/lsb/init-functions
+then
+	. /lib/lsb/init-functions
+else
+	echo "Unable to load /lib/lsb/init-functions"
+	exit 0
+fi
+
 if [ -d /etc/sysconfig ]; then
 	xencommons_config=/etc/sysconfig
 else
diff -r 493ca332d663 -r a74480347d40 tools/hotplug/Linux/init.d/xend
--- a/tools/hotplug/Linux/init.d/xend	Thu Feb 23 14:34:23 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xend	Wed Feb 22 04:15:34 2012 +0100
@@ -18,6 +18,15 @@
 # Description:       Starts and stops the Xen control daemon.
 ### END INIT INFO
 
+# Include init script functions
+if test -f /lib/lsb/init-functions
+then
+	. /lib/lsb/init-functions
+else
+	echo "Unable to load /lib/lsb/init-functions"
+	exit 0
+fi
+
 shopt -s extglob
 
 # Wait for Xend to be up

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21qw-0005NK-Uh; Mon, 27 Feb 2012 14:47:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qv-0005LQ-6Q
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21385 invoked from network); 27 Feb 2012 14:46:55 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:55 -0000
Received: by wibhr2 with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:55 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.85.105 as permitted sender) client-ip=10.180.85.105; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.85.105 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.85.105])
	by 10.180.85.105 with SMTP id g9mr19563831wiz.12.1330354015161
	(num_hops = 1); Mon, 27 Feb 2012 06:46:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=997ZzJ/QsO2ijVYtTwtKsdrVHE/DZ5eQR+SQ7HcB16c=;
	b=NAOiajIEic+AbV4xz9P8xZuc4amcpHjiSgbhEfVAOHTl3DyeB57Z2T/bbm75ysKV02
	/NyJjrayOQgMXM6DpAAiRlLAhrtvknrgHLYRBS7cvK3zcDGj31VDRvuhVhOeEzuw5whc
	tv4nIIPG49aUHFPepYVCs6irHa60zV3IwUYS0=
Received: by 10.180.85.105 with SMTP id g9mr15446922wiz.12.1330354015119;
	Mon, 27 Feb 2012 06:46:55 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4081a567e9767efc5460010d71dd07a42ea86666
Message-Id: <4081a567e9767efc5460.1329880734@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:54 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 8 v2] autoconf: remove (yet another) brctl
	leftover
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329875622 -3600
# Node ID 4081a567e9767efc5460010d71dd07a42ea86666
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
autoconf: remove (yet another) brctl leftover

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a4d93d0e0df2 -r 4081a567e976 config/Tools.mk.in
--- a/config/Tools.mk.in	Wed Feb 22 14:33:24 2012 +0000
+++ b/config/Tools.mk.in	Wed Feb 22 02:53:42 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-BRCTL               := @BRCTL@
 IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21r0-0005P7-9p; Mon, 27 Feb 2012 14:47:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qz-0005MJ-6h
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!3
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21651 invoked from network); 27 Feb 2012 14:46:59 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:59 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.94.68 as permitted sender) client-ip=10.180.94.68; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.94.68 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.94.68])
	by 10.180.94.68 with SMTP id da4mr28671874wib.22.1330354019113
	(num_hops = 1); Mon, 27 Feb 2012 06:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JWl6bwXjOhKLZw7F2GR6lPrlTa93wAO39th1xAGM8yo=;
	b=O/uu0qJMe9PVfi3Kqz56/HK1Nn08hyHvMtmHuj70A/2YP2S6lXqoX4TEf+HGYGXJni
	nEVoRKGPOgMn9NOREdnd+QE7unOYTsXwOyy6tCPH0042WvwaxmlwHIPyyO1avawytQhg
	caGQPDtblmWbWsOLWHykQxVm8fXgmBkTKAQqk=
Received: by 10.180.94.68 with SMTP id da4mr22723312wib.22.1330354019068;
	Mon, 27 Feb 2012 06:46:59 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a74480347d40266afc2f192aeea21819557a483c
Message-Id: <a74480347d40266afc2f.1329880738@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:58 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 8 v2] Linux/init: include init-functions on
 xencommons and xend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329880534 -3600
# Node ID a74480347d40266afc2f192aeea21819557a483c
# Parent  493ca332d663c3c5ac12fd199d279188642089e6
Linux/init: include init-functions on xencommons and xend

Try to include /lib/lsb/init-functions on xencommons and xend or fail
with and error message. Later patches make use of the functions
present on this file.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 493ca332d663 -r a74480347d40 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Thu Feb 23 14:34:23 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Wed Feb 22 04:15:34 2012 +0100
@@ -18,6 +18,15 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
+# Include init script functions
+if test -f /lib/lsb/init-functions
+then
+	. /lib/lsb/init-functions
+else
+	echo "Unable to load /lib/lsb/init-functions"
+	exit 0
+fi
+
 if [ -d /etc/sysconfig ]; then
 	xencommons_config=/etc/sysconfig
 else
diff -r 493ca332d663 -r a74480347d40 tools/hotplug/Linux/init.d/xend
--- a/tools/hotplug/Linux/init.d/xend	Thu Feb 23 14:34:23 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xend	Wed Feb 22 04:15:34 2012 +0100
@@ -18,6 +18,15 @@
 # Description:       Starts and stops the Xen control daemon.
 ### END INIT INFO
 
+# Include init script functions
+if test -f /lib/lsb/init-functions
+then
+	. /lib/lsb/init-functions
+else
+	echo "Unable to load /lib/lsb/init-functions"
+	exit 0
+fi
+
 shopt -s extglob
 
 # Wait for Xend to be up

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21qw-0005NK-Uh; Mon, 27 Feb 2012 14:47:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21qv-0005LQ-6Q
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21385 invoked from network); 27 Feb 2012 14:46:55 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:46:55 -0000
Received: by wibhr2 with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:46:55 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.85.105 as permitted sender) client-ip=10.180.85.105; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.85.105 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.85.105])
	by 10.180.85.105 with SMTP id g9mr19563831wiz.12.1330354015161
	(num_hops = 1); Mon, 27 Feb 2012 06:46:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=997ZzJ/QsO2ijVYtTwtKsdrVHE/DZ5eQR+SQ7HcB16c=;
	b=NAOiajIEic+AbV4xz9P8xZuc4amcpHjiSgbhEfVAOHTl3DyeB57Z2T/bbm75ysKV02
	/NyJjrayOQgMXM6DpAAiRlLAhrtvknrgHLYRBS7cvK3zcDGj31VDRvuhVhOeEzuw5whc
	tv4nIIPG49aUHFPepYVCs6irHa60zV3IwUYS0=
Received: by 10.180.85.105 with SMTP id g9mr15446922wiz.12.1330354015119;
	Mon, 27 Feb 2012 06:46:55 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.46.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:46:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4081a567e9767efc5460010d71dd07a42ea86666
Message-Id: <4081a567e9767efc5460.1329880734@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:18:54 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 8 v2] autoconf: remove (yet another) brctl
	leftover
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329875622 -3600
# Node ID 4081a567e9767efc5460010d71dd07a42ea86666
# Parent  a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
autoconf: remove (yet another) brctl leftover

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a4d93d0e0df2 -r 4081a567e976 config/Tools.mk.in
--- a/config/Tools.mk.in	Wed Feb 22 14:33:24 2012 +0000
+++ b/config/Tools.mk.in	Wed Feb 22 02:53:42 2012 +0100
@@ -11,7 +11,6 @@ FLEX                := @FLEX@
 PYTHON              := @PYTHON@
 PYTHON_PATH         := @PYTHONPATH@
 PERL                := @PERL@
-BRCTL               := @BRCTL@
 IP                  := @IP@
 CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21r4-0005RM-4k; Mon, 27 Feb 2012 14:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21r1-0005NI-Sk
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!5
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21845 invoked from network); 27 Feb 2012 14:47:01 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:47:01 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:47:01 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.14.37 as permitted sender) client-ip=10.180.14.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.14.37 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.14.37])
	by 10.180.14.37 with SMTP id m5mr17525727wic.19.1330354021945 (num_hops
	= 1); Mon, 27 Feb 2012 06:47:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JkpZG74ls3Fkoc3LeNlnl64tEoT/4sShx0sw9XpSD+8=;
	b=teaa9ffe0XMx1vk4OU6YsvHrcyBUmucENvFAgy9GfEPlQ9tEgySAkTnC3zx0h7H2Bl
	QYWS6o4CkrUZEtK/Gt1sdz/IOaulCfg0mpNC7G5/L5TovhkAXqn3d/BqJXD0qtgRXKxc
	qpPOPIHs1a1k6VKpuR6vO0caWSP4TR+vnOoQ8=
Received: by 10.180.14.37 with SMTP id m5mr13777662wic.19.1330354021905;
	Mon, 27 Feb 2012 06:47:01 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.47.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:47:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e1fdc5509bb4775bb5e35921274103d4ee120d95
Message-Id: <e1fdc5509bb4775bb5e3.1329880741@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:19:01 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 8 of 8 v2] Linux/init: check for xml.dom.minidom
 at xend init 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329880534 -3600
# Node ID e1fdc5509bb4775bb5e35921274103d4ee120d95
# Parent  a26c5eadc56fe15af5e40600a3851b4d64be6389
Linux/init: check for xml.dom.minidom at xend init script

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a26c5eadc56f -r e1fdc5509bb4 tools/hotplug/Linux/init.d/xend
--- a/tools/hotplug/Linux/init.d/xend	Tue Feb 21 09:50:49 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xend	Wed Feb 22 04:15:34 2012 +0100
@@ -27,8 +27,16 @@ else
 	exit 0
 fi
 
+servicename="xend"
+
 shopt -s extglob
 
+# Check for python xml
+if ! python -c 'import xml.dom.minidom' > /dev/null 2>&1
+then
+	log_warning_msg "$servicename: unable to find xml.dom.minidom"
+fi
+
 # Wait for Xend to be up
 function await_daemons_up
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 14:47:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 14:47:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S21r4-0005RM-4k; Mon, 27 Feb 2012 14:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S21r1-0005NI-Sk
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 14:47:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330354015!17123427!5
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21845 invoked from network); 27 Feb 2012 14:47:01 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 14:47:01 -0000
Received: by mail-wi0-f173.google.com with SMTP id hr2so887911wib.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 06:47:01 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.14.37 as permitted sender) client-ip=10.180.14.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.14.37 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.14.37])
	by 10.180.14.37 with SMTP id m5mr17525727wic.19.1330354021945 (num_hops
	= 1); Mon, 27 Feb 2012 06:47:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=JkpZG74ls3Fkoc3LeNlnl64tEoT/4sShx0sw9XpSD+8=;
	b=teaa9ffe0XMx1vk4OU6YsvHrcyBUmucENvFAgy9GfEPlQ9tEgySAkTnC3zx0h7H2Bl
	QYWS6o4CkrUZEtK/Gt1sdz/IOaulCfg0mpNC7G5/L5TovhkAXqn3d/BqJXD0qtgRXKxc
	qpPOPIHs1a1k6VKpuR6vO0caWSP4TR+vnOoQ8=
Received: by 10.180.14.37 with SMTP id m5mr13777662wic.19.1330354021905;
	Mon, 27 Feb 2012 06:47:01 -0800 (PST)
Received: from debian.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id gp8sm22348215wib.5.2012.02.27.06.47.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 27 Feb 2012 06:47:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e1fdc5509bb4775bb5e35921274103d4ee120d95
Message-Id: <e1fdc5509bb4775bb5e3.1329880741@debian.localdomain>
In-Reply-To: <patchbomb.1329880733@debian.localdomain>
References: <patchbomb.1329880733@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 22 Feb 2012 04:19:01 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 8 of 8 v2] Linux/init: check for xml.dom.minidom
 at xend init 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1329880534 -3600
# Node ID e1fdc5509bb4775bb5e35921274103d4ee120d95
# Parent  a26c5eadc56fe15af5e40600a3851b4d64be6389
Linux/init: check for xml.dom.minidom at xend init script

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r a26c5eadc56f -r e1fdc5509bb4 tools/hotplug/Linux/init.d/xend
--- a/tools/hotplug/Linux/init.d/xend	Tue Feb 21 09:50:49 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xend	Wed Feb 22 04:15:34 2012 +0100
@@ -27,8 +27,16 @@ else
 	exit 0
 fi
 
+servicename="xend"
+
 shopt -s extglob
 
+# Check for python xml
+if ! python -c 'import xml.dom.minidom' > /dev/null 2>&1
+then
+	log_warning_msg "$servicename: unable to find xml.dom.minidom"
+fi
+
 # Wait for Xend to be up
 function await_daemons_up
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 15:22:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 15: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 1S22PK-0007QK-QP; Mon, 27 Feb 2012 15:22:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S22PI-0007QF-Vk
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 15:22:33 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330356144!13283615!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23682 invoked from network); 27 Feb 2012 15:22:26 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 15:22:26 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1RFMFXc081168
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 27 Feb 2012 08:22:15 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1330335816.8557.252.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 08:22:17 -0700
Message-Id: <4769A567-2EDF-49E3-87DB-13A1E8643C43@spectralogic.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
	<1330335816.8557.252.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Mon, 27 Feb 2012 08:22:17 -0700 (MST)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-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

I think there is more to cleanup here.  These drivers have their
own constant, MAX_SEGMENTS_PER_REQ.  If this is the real driver
limit, it should be used consistently everywhere, but also tied to
blkif.h via a MIN() instead of directly hardcoded to 11.

I'm working on patches for this and the other isues within the
xen-unstable tree now, and will submit them for review once I
think they are ready.

--
Justin

On Feb 27, 2012, at 2:43 AM, Ian Campbell wrote:

> On Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
>>> The same would go for tools/blktap*/.
>> 
>> That one never occurred to me, even after I grepped for the symbol.
> 
> I guess the following ought to fix it...
> 
> 8<---------------------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1330335804 0
> # Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
> # Parent  0bb45a06c1a8b049dba322cfb91c86c253068f0e
> blktap: Fix after blkif.h update
> 
> 24875:a59c1dcfe968 made an incompatible change to the interface headers which
> needs to be reflected here Fix after blkif.h update
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
> --- a/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
> @@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
> 
> /* Accessing attached data page mappings */
> #define MMAP_PAGES                                              \
> -    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> +    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg)                                   \
>     ((_vstart) +                                              \
> -     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
> +     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +    \
>      ((_seg) * getpagesize()))
> 
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
> --- a/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:43:24 2012 +0000
> @@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
> 		breq->sector_number = sreq->sec;
> 		breq->operation     = BLKIF_OP_READ;
> 
> -		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> +		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> 			uint32_t secs;
> 			struct blkif_request_segment *seg = breq->seg + i;
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
> --- a/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:43:24 2012 +0000
> @@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
> 		breq->sector_number = sreq->sec;
> 		breq->operation     = BLKIF_OP_READ;
> kk
> -		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> +		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> 			uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
> 			struct blkif_request_segment *seg = breq->seg + i;
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
> --- a/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
> @@ -222,10 +222,10 @@ typedef struct msg_lock {
> 
> /* Accessing attached data page mappings */
> #define MMAP_PAGES                                                    \
> -    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> +    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg)                                 \
>     ((_vstart) +                                                      \
> -     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
> +     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +      \
>      ((_seg) * getpagesize()))
> 
> /* Defines that are only used by library clients */
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 15:22:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 15: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 1S22PK-0007QK-QP; Mon, 27 Feb 2012 15:22:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S22PI-0007QF-Vk
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 15:22:33 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330356144!13283615!1
X-Originating-IP: [70.89.174.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23682 invoked from network); 27 Feb 2012 15:22:26 -0000
Received: from mail.scsiguy.com (HELO aslan.scsiguy.com) (70.89.174.89)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 15:22:26 -0000
Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99])
	(authenticated bits=0)
	by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q1RFMFXc081168
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 27 Feb 2012 08:22:15 -0700 (MST)
	(envelope-from justing@spectralogic.com)
Mime-Version: 1.0 (Apple Message framework v1257)
From: "Justin T. Gibbs" <justing@spectralogic.com>
In-Reply-To: <1330335816.8557.252.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 08:22:17 -0700
Message-Id: <4769A567-2EDF-49E3-87DB-13A1E8643C43@spectralogic.com>
References: <E1S15wA-00053m-NU@woking.xci-test.com>
	<4F4B54F00200007800074E3D@nat28.tlf.novell.com>
	<1330335129.8557.247.camel@zakaz.uk.xensource.com>
	<1330335816.8557.252.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1257)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(aslan.scsiguy.com [192.168.0.4]);
	Mon, 27 Feb 2012 08:22:17 -0700 (MST)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-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

I think there is more to cleanup here.  These drivers have their
own constant, MAX_SEGMENTS_PER_REQ.  If this is the real driver
limit, it should be used consistently everywhere, but also tied to
blkif.h via a MIN() instead of directly hardcoded to 11.

I'm working on patches for this and the other isues within the
xen-unstable tree now, and will submit them for review once I
think they are ready.

--
Justin

On Feb 27, 2012, at 2:43 AM, Ian Campbell wrote:

> On Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
>>> The same would go for tools/blktap*/.
>> 
>> That one never occurred to me, even after I grepped for the symbol.
> 
> I guess the following ought to fix it...
> 
> 8<---------------------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1330335804 0
> # Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
> # Parent  0bb45a06c1a8b049dba322cfb91c86c253068f0e
> blktap: Fix after blkif.h update
> 
> 24875:a59c1dcfe968 made an incompatible change to the interface headers which
> needs to be reflected here Fix after blkif.h update
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
> --- a/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap/lib/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
> @@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
> 
> /* Accessing attached data page mappings */
> #define MMAP_PAGES                                              \
> -    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> +    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg)                                   \
>     ((_vstart) +                                              \
> -     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +    \
> +     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +    \
>      ((_seg) * getpagesize()))
> 
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
> --- a/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-diff.c	Mon Feb 27 09:43:24 2012 +0000
> @@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
> 		breq->sector_number = sreq->sec;
> 		breq->operation     = BLKIF_OP_READ;
> 
> -		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> +		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> 			uint32_t secs;
> 			struct blkif_request_segment *seg = breq->seg + i;
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
> --- a/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-stream.c	Mon Feb 27 09:43:24 2012 +0000
> @@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
> 		breq->sector_number = sreq->sec;
> 		breq->operation     = BLKIF_OP_READ;
> kk
> -		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> +		for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> 			uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
> 			struct blkif_request_segment *seg = breq->seg + i;
> 
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
> --- a/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/include/blktaplib.h	Mon Feb 27 09:43:24 2012 +0000
> @@ -222,10 +222,10 @@ typedef struct msg_lock {
> 
> /* Accessing attached data page mappings */
> #define MMAP_PAGES                                                    \
> -    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> +    (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg)                                 \
>     ((_vstart) +                                                      \
> -     ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) +      \
> +     ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) +      \
>      ((_seg) * getpagesize()))
> 
> /* Defines that are only used by library clients */
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 15:47:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 15:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S22mg-00082q-5Z; Mon, 27 Feb 2012 15:46:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S22md-00082j-UY
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 15:46:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330357590!15115714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32244 invoked from network); 27 Feb 2012 15:46:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 15:46:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325480400"; d="scan'208";a="183544141"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 10:46:09 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 10:46:09 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S22m8-0004sc-K5;
	Mon, 27 Feb 2012 15:46:08 +0000
MIME-Version: 1.0
X-Mercurial-Node: da2738f5050d9487313f29f4a069a8a2bacb6b55
Message-ID: <da2738f5050d9487313f.1330357568@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 27 Feb 2012 15:46:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH DOCDAY] hcall: markup the grant table hypercalls
 to improve generated 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+CiMgRGF0ZSAxMzMwMzU3NTU0IDAKIyBOb2RlIElEIGRhMjczOGY1MDUwZDk0ODcz
MTNmMjlmNGEwNjlhOGEyYmFjYjZiNTUKIyBQYXJlbnQgIGI2YTNhMGQ2OGM5MWNlOGZhNjAyM2Fl
ZTMwNDZlZmQzODY2OTQyZGYKaGNhbGw6IG1hcmt1cCB0aGUgZ3JhbnQgdGFibGUgaHlwZXJjYWxs
cyB0byBpbXByb3ZlIGdlbmVyYXRlZCBkb2NzCgpBcyBwYXJ0IG9mIHRoaXMgSSBsb29rZWQgdGhy
b3VnaCB0aGUgcmVsZXZhbnQgY2hhcHRlciBmcm9tIGludGVyZmFjZXMudGV4IChmcm9tCjQuMSwg
ZGVsZXRlZCBpbiB1bnN0YWJsZSkgdG8gZW5zdXJlIG5vIGNyaXRpY2FsIGluZm9ybWF0aW9uIHdh
cyBtaXNzaW5nLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCmRpZmYgLXIgYjZhM2EwZDY4YzkxIC1yIGRhMjczOGY1MDUwZCB4ZW4vaW5jbHVk
ZS9wdWJsaWMvZ3JhbnRfdGFibGUuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvZ3JhbnRfdGFi
bGUuaAlNb24gRmViIDI3IDEyOjM2OjQ3IDIwMTIgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvcHVi
bGljL2dyYW50X3RhYmxlLmgJTW9uIEZlYiAyNyAxNTo0NTo1NCAyMDEyICswMDAwCkBAIC0xLDkg
KzEsOSBAQAogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICogZ3JhbnRfdGFibGUuaAotICogCisg
KgogICogSW50ZXJmYWNlIGZvciBncmFudGluZyBmb3JlaWduIGFjY2VzcyB0byBwYWdlIGZyYW1l
cywgYW5kIHJlY2VpdmluZwogICogcGFnZS1vd25lcnNoaXAgdHJhbnNmZXJzLgotICogCisgKgog
ICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBw
ZXJzb24gb2J0YWluaW5nIGEgY29weQogICogb2YgdGhpcyBzb2Z0d2FyZSBhbmQgYXNzb2NpYXRl
ZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJlIiksIHRvCiAgKiBkZWFsIGluIHRo
ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZQpAQCAtMzAsMTcgKzMwLDQxIEBACiAKICNpbmNsdWRlICJ4ZW4uaCIKIAorLyoKKyAq
IGBpbmNvbnRlbnRzIDE1MCBnbnR0YWIgR3JhbnQgVGFibGVzCisgKgorICogWGVuJ3MgZ3JhbnQg
dGFibGVzIHByb3ZpZGUgYSBnZW5lcmljIG1lY2hhbmlzbSB0byBtZW1vcnkgc2hhcmluZworICog
YmV0d2VlbiBkb21haW5zLiBUaGlzIHNoYXJlZCBtZW1vcnkgaW50ZXJmYWNlIHVuZGVycGlucyB0
aGUgc3BsaXQKKyAqIGRldmljZSBkcml2ZXJzIGZvciBibG9jayBhbmQgbmV0d29yayBJTy4KKyAq
CisgKiBFYWNoIGRvbWFpbiBoYXMgaXRzIG93biBncmFudCB0YWJsZS4gVGhpcyBpcyBhIGRhdGEg
c3RydWN0dXJlIHRoYXQKKyAqIGlzIHNoYXJlZCB3aXRoIFhlbjsgaXQgYWxsb3dzIHRoZSBkb21h
aW4gdG8gdGVsbCBYZW4gd2hhdCBraW5kIG9mCisgKiBwZXJtaXNzaW9ucyBvdGhlciBkb21haW5z
IGhhdmUgb24gaXRzIHBhZ2VzLiBFbnRyaWVzIGluIHRoZSBncmFudAorICogdGFibGUgYXJlIGlk
ZW50aWZpZWQgYnkgZ3JhbnQgcmVmZXJlbmNlcy4gQSBncmFudCByZWZlcmVuY2UgaXMgYW4KKyAq
IGludGVnZXIsIHdoaWNoIGluZGV4ZXMgaW50byB0aGUgZ3JhbnQgdGFibGUuIEl0IGFjdHMgYXMg
YQorICogY2FwYWJpbGl0eSB3aGljaCB0aGUgZ3JhbnRlZSBjYW4gdXNlIHRvIHBlcmZvcm0gb3Bl
cmF0aW9ucyBvbiB0aGUKKyAqIGdyYW50ZXLigJlzIG1lbW9yeS4KKyAqCisgKiBUaGlzIGNhcGFi
aWxpdHktYmFzZWQgc3lzdGVtIGFsbG93cyBzaGFyZWQtbWVtb3J5IGNvbW11bmljYXRpb25zCisg
KiBiZXR3ZWVuIHVucHJpdmlsZWdlZCBkb21haW5zLiBBIGdyYW50IHJlZmVyZW5jZSBhbHNvIGVu
Y2Fwc3VsYXRlcworICogdGhlIGRldGFpbHMgb2YgYSBzaGFyZWQgcGFnZSwgcmVtb3ZpbmcgdGhl
IG5lZWQgZm9yIGEgZG9tYWluIHRvCisgKiBrbm93IHRoZSByZWFsIG1hY2hpbmUgYWRkcmVzcyBv
ZiBhIHBhZ2UgaXQgaXMgc2hhcmluZy4gVGhpcyBtYWtlcworICogaXQgcG9zc2libGUgdG8gc2hh
cmUgbWVtb3J5IGNvcnJlY3RseSB3aXRoIGRvbWFpbnMgcnVubmluZyBpbgorICogZnVsbHkgdmly
dHVhbGlzZWQgbWVtb3J5LgorICovCisKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKgogICogR1JBTlQgVEFCTEUgUkVQUkVTRU5UQVRJT04KICAqLwogCiAvKiBTb21lIHJvdWdo
IGd1aWRlbGluZXMgb24gYWNjZXNzaW5nIGFuZCB1cGRhdGluZyBncmFudC10YWJsZSBlbnRyaWVz
CiAgKiBpbiBhIGNvbmN1cnJlbmN5LXNhZmUgbWFubmVyLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwg
TGludXggY29udGFpbnMgYQotICogcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGZvciBndWVzdCBP
U2VzIChhcmNoL3hlbi9rZXJuZWwvZ3JhbnRfdGFibGUuYykuCi0gKiAKKyAqIHJlZmVyZW5jZSBp
bXBsZW1lbnRhdGlvbiBmb3IgZ3Vlc3QgT1NlcyAoZHJpdmVycy94ZW4vZ3JhbnRfdGFibGUuYywg
c2VlCisgKiBodHRwOi8vZ2l0Lmtlcm5lbC5vcmcvP3A9bGludXgva2VybmVsL2dpdC90b3J2YWxk
cy9saW51eC5naXQ7YT1ibG9iO2Y9ZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYztoYj1IRUFECisg
KgogICogTkIuIFdNQiBpcyBhIG5vLW9wIG9uIGN1cnJlbnQtZ2VuZXJhdGlvbiB4ODYgcHJvY2Vz
c29ycy4gSG93ZXZlciwgYQogICogICAgIGNvbXBpbGVyIGJhcnJpZXIgd2lsbCBzdGlsbCBiZSBy
ZXF1aXJlZC4KLSAqIAorICoKICAqIEludHJvZHVjaW5nIGEgdmFsaWQgZW50cnkgaW50byB0aGUg
Z3JhbnQgdGFibGU6CiAgKiAgMS4gV3JpdGUgZW50LT5kb21pZC4KICAqICAyLiBXcml0ZSBlbnQt
PmZyYW1lOgpAQCAtNDksNyArNzMsNyBAQAogICogICAgICAgICAgICAgICAgICAgICAgICAgICBm
cmFtZSwgb3IgemVybyBpZiBub25lLgogICogIDMuIFdyaXRlIG1lbW9yeSBiYXJyaWVyIChXTUIp
LgogICogIDQuIFdyaXRlIGVudC0+ZmxhZ3MsIGluYy4gdmFsaWQgdHlwZS4KLSAqIAorICoKICAq
IEludmFsaWRhdGluZyBhbiB1bnVzZWQgR1RGX3Blcm1pdF9hY2Nlc3MgZW50cnk6CiAgKiAgMS4g
ZmxhZ3MgPSBlbnQtPmZsYWdzLgogICogIDIuIE9ic2VydmUgdGhhdCAhKGZsYWdzICYgKEdURl9y
ZWFkaW5nfEdURl93cml0aW5nKSkuCkBAIC02MSw3ICs4NSw3IEBACiAgKiAgVGhpcyBjYW5ub3Qg
YmUgZG9uZSBkaXJlY3RseS4gUmVxdWVzdCBhc3Npc3RhbmNlIGZyb20gdGhlIGRvbWFpbiBjb250
cm9sbGVyCiAgKiAgd2hpY2ggY2FuIHNldCBhIHRpbWVvdXQgb24gdGhlIHVzZSBvZiBhIGdyYW50
IGVudHJ5IGFuZCB0YWtlIG5lY2Vzc2FyeQogICogIGFjdGlvbi4gKE5CLiBUaGlzIGlzIG5vdCB5
ZXQgaW1wbGVtZW50ZWQhKS4KLSAqIAorICoKICAqIEludmFsaWRhdGluZyBhbiB1bnVzZWQgR1RG
X2FjY2VwdF90cmFuc2ZlciBlbnRyeToKICAqICAxLiBmbGFncyA9IGVudC0+ZmxhZ3MuCiAgKiAg
Mi4gT2JzZXJ2ZSB0aGF0ICEoZmxhZ3MgJiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkKS4gWypdCkBA
IC03OSw3ICsxMDMsNyBAQAogICoKICAqIENoYW5naW5nIGEgR1RGX3Blcm1pdF9hY2Nlc3MgZnJv
bSB3cml0YWJsZSB0byByZWFkLW9ubHk6CiAgKiAgVXNlIFNNUC1zYWZlIENNUFhDSEcgdG8gc2V0
IEdURl9yZWFkb25seSwgd2hpbGUgY2hlY2tpbmcgIUdURl93cml0aW5nLgotICogCisgKgogICog
Q2hhbmdpbmcgYSBHVEZfcGVybWl0X2FjY2VzcyBmcm9tIHJlYWQtb25seSB0byB3cml0YWJsZToK
ICAqICBVc2UgU01QLXNhZmUgYml0LXNldHRpbmcgaW5zdHJ1Y3Rpb24uCiAgKi8KQEAgLTI2MSw2
ICsyODUsMzMgQEAgdHlwZWRlZiB1aW50MTZfdCBncmFudF9zdGF0dXNfdDsKICAqIEdSQU5UIFRB
QkxFIFFVRVJJRVMgQU5EIFVTRVMKICAqLwogCisvKiBgIGVudW0gbmVnX2Vycm5vdmFsCisgKiBg
IEhZUEVSVklTT1JfZ3JhbnRfdGFibGVfb3AoZW51bSBncmFudF90YWJsZV9vcCBjbWQsCisgKiBg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqYXJncywKKyAqIGAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgY291bnQpCisgKiBgCisgKgorICogQGFyZ3MgcG9p
bnRzIHRvIGFuIGFycmF5IG9mIGEgcGVyLWNvbW1hbmQgZGF0YSBzdHJ1Y3R1cmUuIFRoZSBhcnJh
eQorICogaGFzIEBjb3VudCBtZW1iZXJzICovCisgKi8KKworLyogYCBlbnVtIGdyYW50X3RhYmxl
X29wIHsgLy8gR05UVEFCT1BfKiA9PiBzdHJ1Y3QgZ250dGFiXyogKi8KKyNkZWZpbmUgR05UVEFC
T1BfbWFwX2dyYW50X3JlZiAgICAgICAgMAorI2RlZmluZSBHTlRUQUJPUF91bm1hcF9ncmFudF9y
ZWYgICAgICAxCisjZGVmaW5lIEdOVFRBQk9QX3NldHVwX3RhYmxlICAgICAgICAgIDIKKyNkZWZp
bmUgR05UVEFCT1BfZHVtcF90YWJsZSAgICAgICAgICAgMworI2RlZmluZSBHTlRUQUJPUF90cmFu
c2ZlciAgICAgICAgICAgICA0CisjZGVmaW5lIEdOVFRBQk9QX2NvcHkgICAgICAgICAgICAgICAg
IDUKKyNkZWZpbmUgR05UVEFCT1BfcXVlcnlfc2l6ZSAgICAgICAgICAgNgorI2RlZmluZSBHTlRU
QUJPUF91bm1hcF9hbmRfcmVwbGFjZSAgICA3CisjaWYgX19YRU5fSU5URVJGQUNFX1ZFUlNJT05f
XyA+PSAweDAwMDMwMjBhCisjZGVmaW5lIEdOVFRBQk9QX3NldF92ZXJzaW9uICAgICAgICAgIDgK
KyNkZWZpbmUgR05UVEFCT1BfZ2V0X3N0YXR1c19mcmFtZXMgICAgOQorI2RlZmluZSBHTlRUQUJP
UF9nZXRfdmVyc2lvbiAgICAgICAgICAxMAorI2RlZmluZSBHTlRUQUJPUF9zd2FwX2dyYW50X3Jl
ZgkgICAgICAxMQorI2VuZGlmIC8qIF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gKi8KKy8qIGAg
fSAqLworCiAvKgogICogSGFuZGxlIHRvIHRyYWNrIGEgbWFwcGluZyBjcmVhdGVkIHZpYSBhIGdy
YW50IHJlZmVyZW5jZS4KICAqLwpAQCAtMjc3LDEzICszMjgsMTIgQEAgdHlwZWRlZiB1aW50MzJf
dCBncmFudF9oYW5kbGVfdDsKICAqICAyLiBJZiBHTlRNQVBfaG9zdF9tYXAgaXMgc3BlY2lmaWVk
IHRoZW4gYSBtYXBwaW5nIHdpbGwgYmUgYWRkZWQgYXQKICAqICAgICBlaXRoZXIgYSBob3N0IHZp
cnR1YWwgYWRkcmVzcyBpbiB0aGUgY3VycmVudCBhZGRyZXNzIHNwYWNlLCBvciBhdAogICogICAg
IGEgUFRFIGF0IHRoZSBzcGVjaWZpZWQgbWFjaGluZSBhZGRyZXNzLiAgVGhlIHR5cGUgb2YgbWFw
cGluZyB0bwotICogICAgIHBlcmZvcm0gaXMgc2VsZWN0ZWQgdGhyb3VnaCB0aGUgR05UTUFQX2Nv
bnRhaW5zX3B0ZSBmbGFnLCBhbmQgdGhlIAorICogICAgIHBlcmZvcm0gaXMgc2VsZWN0ZWQgdGhy
b3VnaCB0aGUgR05UTUFQX2NvbnRhaW5zX3B0ZSBmbGFnLCBhbmQgdGhlCiAgKiAgICAgYWRkcmVz
cyBpcyBzcGVjaWZpZWQgaW4gPGhvc3RfYWRkcj4uCiAgKiAgMy4gTWFwcGluZ3Mgc2hvdWxkIG9u
bHkgYmUgZGVzdHJveWVkIHZpYSBHTlRUQUJPUF91bm1hcF9ncmFudF9yZWYuIElmIGEKICAqICAg
ICBob3N0IG1hcHBpbmcgaXMgZGVzdHJveWVkIGJ5IG90aGVyIG1lYW5zIHRoZW4gaXQgaXMgKk5P
VCogZ3VhcmFudGVlZAogICogICAgIHRvIGJlIGFjY291bnRlZCB0byB0aGUgY29ycmVjdCBncmFu
dCByZWZlcmVuY2UhCiAgKi8KLSNkZWZpbmUgR05UVEFCT1BfbWFwX2dyYW50X3JlZiAgICAgICAg
MAogc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzLiAq
LwogICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsKQEAgLTI5MSw3ICszNDEsNyBAQCBzdHJ1Y3QgZ250
dGFiX21hcF9ncmFudF9yZWYgewogICAgIGdyYW50X3JlZl90IHJlZjsKICAgICBkb21pZF90ICBk
b207CiAgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCi0gICAgaW50MTZfdCAgc3RhdHVzOyAgICAg
ICAgICAgICAgLyogR05UU1RfKiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAg
IC8qID0+IGVudW0gZ3JhbnRfc3RhdHVzICovCiAgICAgZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOwog
ICAgIHVpbnQ2NF90IGRldl9idXNfYWRkcjsKIH07CkBAIC0zMDksMTQgKzM1OSwxMyBAQCBERUZJ
TkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfbWFwX2dyYW50CiAgKiAgMy4gQWZ0ZXIgZXhlY3V0
aW5nIGEgYmF0Y2ggb2YgdW5tYXBzLCBpdCBpcyBndWFyYW50ZWVkIHRoYXQgbm8gc3RhbGUKICAq
ICAgICBtYXBwaW5ncyB3aWxsIHJlbWFpbiBpbiB0aGUgZGV2aWNlIG9yIGhvc3QgVExCcy4KICAq
LwotI2RlZmluZSBHTlRUQUJPUF91bm1hcF9ncmFudF9yZWYgICAgICAxCiBzdHJ1Y3QgZ250dGFi
X3VubWFwX2dyYW50X3JlZiB7CiAgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KICAgICB1aW50NjRf
dCBob3N0X2FkZHI7CiAgICAgdWludDY0X3QgZGV2X2J1c19hZGRyOwogICAgIGdyYW50X2hhbmRs
ZV90IGhhbmRsZTsKICAgICAvKiBPVVQgcGFyYW1ldGVycy4gKi8KLSAgICBpbnQxNl90ICBzdGF0
dXM7ICAgICAgICAgICAgICAvKiBHTlRTVF8qICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAg
ICAgICAgICAgLyogPT4gZW51bSBncmFudF9zdGF0dXMgKi8KIH07CiB0eXBlZGVmIHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmIGdudHRhYl91bm1hcF9ncmFudF9yZWZfdDsKIERFRklORV9Y
RU5fR1VFU1RfSEFORExFKGdudHRhYl91bm1hcF9ncmFudF9yZWZfdCk7CkBAIC0zMzAsMTMgKzM3
OSwxMiBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfdW5tYXBfZ3JhCiAgKiAgMi4g
T25seSBhIHN1ZmZpY2llbnRseS1wcml2aWxlZ2VkIGRvbWFpbiBtYXkgc3BlY2lmeSA8ZG9tPiAh
PSBET01JRF9TRUxGLgogICogIDMuIFhlbiBtYXkgbm90IHN1cHBvcnQgbW9yZSB0aGFuIGEgc2lu
Z2xlIGdyYW50LXRhYmxlIHBhZ2UgcGVyIGRvbWFpbi4KICAqLwotI2RlZmluZSBHTlRUQUJPUF9z
ZXR1cF90YWJsZSAgICAgICAgICAyCiBzdHJ1Y3QgZ250dGFiX3NldHVwX3RhYmxlIHsKICAgICAv
KiBJTiBwYXJhbWV0ZXJzLiAqLwogICAgIGRvbWlkX3QgIGRvbTsKICAgICB1aW50MzJfdCBucl9m
cmFtZXM7CiAgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCi0gICAgaW50MTZfdCAgc3RhdHVzOyAg
ICAgICAgICAgICAgLyogR05UU1RfKiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAg
ICAgIC8qID0+IGVudW0gZ3JhbnRfc3RhdHVzICovCiAgICAgWEVOX0dVRVNUX0hBTkRMRSh1bG9u
ZykgZnJhbWVfbGlzdDsKIH07CiB0eXBlZGVmIHN0cnVjdCBnbnR0YWJfc2V0dXBfdGFibGUgZ250
dGFiX3NldHVwX3RhYmxlX3Q7CkBAIC0zNDYsMTIgKzM5NCwxMSBAQCBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShnbnR0YWJfc2V0dXBfdGFiCiAgKiBHTlRUQUJPUF9kdW1wX3RhYmxlOiBEdW1wIHRo
ZSBjb250ZW50cyBvZiB0aGUgZ3JhbnQgdGFibGUgdG8gdGhlCiAgKiB4ZW4gY29uc29sZS4gRGVi
dWdnaW5nIHVzZSBvbmx5LgogICovCi0jZGVmaW5lIEdOVFRBQk9QX2R1bXBfdGFibGUgICAgICAg
ICAgIDMKIHN0cnVjdCBnbnR0YWJfZHVtcF90YWJsZSB7CiAgICAgLyogSU4gcGFyYW1ldGVycy4g
Ki8KICAgICBkb21pZF90IGRvbTsKICAgICAvKiBPVVQgcGFyYW1ldGVycy4gKi8KLSAgICBpbnQx
Nl90IHN0YXR1czsgICAgICAgICAgICAgICAvKiBHTlRTVF8qICovCisgICAgaW50MTZfdCBzdGF0
dXM7ICAgICAgICAgICAgICAgLyogPT4gZW51bSBncmFudF9zdGF0dXMgKi8KIH07CiB0eXBlZGVm
IHN0cnVjdCBnbnR0YWJfZHVtcF90YWJsZSBnbnR0YWJfZHVtcF90YWJsZV90OwogREVGSU5FX1hF
Tl9HVUVTVF9IQU5ETEUoZ250dGFiX2R1bXBfdGFibGVfdCk7CkBAIC0zNjAsMTEgKzQwNywxMCBA
QCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfZHVtcF90YWJsCiAgKiBHTlRUQUJPUF90
cmFuc2Zlcl9ncmFudF9yZWY6IFRyYW5zZmVyIDxmcmFtZT4gdG8gYSBmb3JlaWduIGRvbWFpbi4g
VGhlCiAgKiBmb3JlaWduIGRvbWFpbiBoYXMgcHJldmlvdXNseSByZWdpc3RlcmVkIGl0cyBpbnRl
cmVzdCBpbiB0aGUgdHJhbnNmZXIgdmlhCiAgKiA8ZG9taWQsIHJlZj4uCi0gKiAKKyAqCiAgKiBO
b3RlIHRoYXQsIGV2ZW4gaWYgdGhlIHRyYW5zZmVyIGZhaWxzLCB0aGUgc3BlY2lmaWVkIHBhZ2Ug
bm8gbG9uZ2VyIGJlbG9uZ3MKICAqIHRvIHRoZSBjYWxsaW5nIGRvbWFpbiAqdW5sZXNzKiB0aGUg
ZXJyb3IgaXMgR05UU1RfYmFkX3BhZ2UuCiAgKi8KLSNkZWZpbmUgR05UVEFCT1BfdHJhbnNmZXIg
ICAgICAgICAgICAgICAgNAogc3RydWN0IGdudHRhYl90cmFuc2ZlciB7CiAgICAgLyogSU4gcGFy
YW1ldGVycy4gKi8KICAgICB4ZW5fcGZuX3QgICAgIG1mbjsKQEAgLTQwMCwxMCArNDQ2LDkgQEAg
REVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoZ250dGFiX3RyYW5zZmVyXwogI2RlZmluZSBfR05UQ09Q
WV9kZXN0X2dyZWYgICAgICAgICgxKQogI2RlZmluZSBHTlRDT1BZX2Rlc3RfZ3JlZiAgICAgICAg
ICgxPDxfR05UQ09QWV9kZXN0X2dyZWYpCiAjZGVmaW5lIF9HTlRDT1BZX2Nhbl9mYWlsICAgICAg
ICAgKDIpCi0jZGVmaW5lIEdOVENPUFlfY2FuX2ZhaWwgICAgICAgICAgKDE8PF9HTlRDT1BZX2Nh
bl9mYWlsKSAKKyNkZWZpbmUgR05UQ09QWV9jYW5fZmFpbCAgICAgICAgICAoMTw8X0dOVENPUFlf
Y2FuX2ZhaWwpCiAKLSNkZWZpbmUgR05UVEFCT1BfY29weSAgICAgICAgICAgICAgICAgNQotdHlw
ZWRlZiBzdHJ1Y3QgZ250dGFiX2NvcHkgeworc3RydWN0IGdudHRhYl9jb3B5IHsKICAgICAvKiBJ
TiBwYXJhbWV0ZXJzLiAqLwogICAgIHN0cnVjdCB7CiAgICAgICAgIHVuaW9uIHsKQEAgLTQxNyw3
ICs0NjIsOCBAQCB0eXBlZGVmIHN0cnVjdCBnbnR0YWJfY29weSB7CiAgICAgdWludDE2X3QgICAg
ICBmbGFnczsgICAgICAgICAgLyogR05UQ09QWV8qICovCiAgICAgLyogT1VUIHBhcmFtZXRlcnMu
ICovCiAgICAgaW50MTZfdCAgICAgICBzdGF0dXM7Ci19IGdudHRhYl9jb3B5X3Q7Cit9OwordHlw
ZWRlZiBzdHJ1Y3QgZ250dGFiX2NvcHkgIGdudHRhYl9jb3B5X3Q7CiBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShnbnR0YWJfY29weV90KTsKIAogLyoKQEAgLTQyNywxNCArNDczLDEzIEBAIERFRklO
RV9YRU5fR1VFU1RfSEFORExFKGdudHRhYl9jb3B5X3QpOwogICogIDEuIDxkb20+IG1heSBiZSBz
cGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KICAqICAyLiBPbmx5IGEgc3VmZmljaWVudGx5LXByaXZp
bGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NFTEYuCiAgKi8KLSNkZWZp
bmUgR05UVEFCT1BfcXVlcnlfc2l6ZSAgICAgICAgICAgNgogc3RydWN0IGdudHRhYl9xdWVyeV9z
aXplIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzLiAqLwogICAgIGRvbWlkX3QgIGRvbTsKICAgICAv
KiBPVVQgcGFyYW1ldGVycy4gKi8KICAgICB1aW50MzJfdCBucl9mcmFtZXM7CiAgICAgdWludDMy
X3QgbWF4X25yX2ZyYW1lczsKLSAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAgICAvKiBH
TlRTVF8qICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogPT4gZW51bSBn
cmFudF9zdGF0dXMgKi8KIH07CiB0eXBlZGVmIHN0cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSBnbnR0
YWJfcXVlcnlfc2l6ZV90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoZ250dGFiX3F1ZXJ5X3Np
emVfdCk7CkBAIC00NTAsMTQgKzQ5NSwxMyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0
YWJfcXVlcnlfc2l6CiAgKiAgMi4gQWZ0ZXIgZXhlY3V0aW5nIGEgYmF0Y2ggb2YgdW5tYXBzLCBp
dCBpcyBndWFyYW50ZWVkIHRoYXQgbm8gc3RhbGUKICAqICAgICBtYXBwaW5ncyB3aWxsIHJlbWFp
biBpbiB0aGUgZGV2aWNlIG9yIGhvc3QgVExCcy4KICAqLwotI2RlZmluZSBHTlRUQUJPUF91bm1h
cF9hbmRfcmVwbGFjZSAgICA3CiBzdHJ1Y3QgZ250dGFiX3VubWFwX2FuZF9yZXBsYWNlIHsKICAg
ICAvKiBJTiBwYXJhbWV0ZXJzLiAqLwogICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsKICAgICB1aW50
NjRfdCBuZXdfYWRkcjsKICAgICBncmFudF9oYW5kbGVfdCBoYW5kbGU7CiAgICAgLyogT1VUIHBh
cmFtZXRlcnMuICovCi0gICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1Rf
KiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8qID0+IGVudW0gZ3JhbnRf
c3RhdHVzICovCiB9OwogdHlwZWRlZiBzdHJ1Y3QgZ250dGFiX3VubWFwX2FuZF9yZXBsYWNlIGdu
dHRhYl91bm1hcF9hbmRfcmVwbGFjZV90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoZ250dGFi
X3VubWFwX2FuZF9yZXBsYWNlX3QpOwpAQCAtNDcwLDcgKzUxNCw2IEBAIERFRklORV9YRU5fR1VF
U1RfSEFORExFKGdudHRhYl91bm1hcF9hbmQKICAqIGFyZSBhY3RpdmF0ZWQ7IG90aGVyd2lzZSwg
dGhlIGRvbWFpbiB3aWxsIGJlIHN0dWNrIHdpdGggdmVyc2lvbiAxLgogICogVGhlIG9ubHkgZGVm
aW5lZCB2ZXJzaW9ucyBhcmUgMSBhbmQgMi4KICAqLwotI2RlZmluZSBHTlRUQUJPUF9zZXRfdmVy
c2lvbiAgICAgICAgICA4CiBzdHJ1Y3QgZ250dGFiX3NldF92ZXJzaW9uIHsKICAgICAvKiBJTi9P
VVQgcGFyYW1ldGVycyAqLwogICAgIHVpbnQzMl90IHZlcnNpb247CkBAIC00OTEsMTMgKzUzNCwx
MiBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfc2V0X3ZlcnNpCiAgKiAgMS4gPGRv
bT4gbWF5IGJlIHNwZWNpZmllZCBhcyBET01JRF9TRUxGLgogICogIDIuIE9ubHkgYSBzdWZmaWNp
ZW50bHktcHJpdmlsZWdlZCBkb21haW4gbWF5IHNwZWNpZnkgPGRvbT4gIT0gRE9NSURfU0VMRi4K
ICAqLwotI2RlZmluZSBHTlRUQUJPUF9nZXRfc3RhdHVzX2ZyYW1lcyAgICAgOQogc3RydWN0IGdu
dHRhYl9nZXRfc3RhdHVzX2ZyYW1lcyB7CiAgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KICAgICB1
aW50MzJfdCBucl9mcmFtZXM7CiAgICAgZG9taWRfdCAgZG9tOwogICAgIC8qIE9VVCBwYXJhbWV0
ZXJzLiAqLwotICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8qIEdOVFNUXyogKi8K
KyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAgICAvKiA9PiBlbnVtIGdyYW50X3N0YXR1
cyAqLwogICAgIFhFTl9HVUVTVF9IQU5ETEUodWludDY0X3QpIGZyYW1lX2xpc3Q7CiB9OwogdHlw
ZWRlZiBzdHJ1Y3QgZ250dGFiX2dldF9zdGF0dXNfZnJhbWVzIGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lc190OwpAQCAtNTA3LDcgKzU0OSw2IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExFKGdudHRh
Yl9nZXRfc3RhdHUKICAqIEdOVFRBQk9QX2dldF92ZXJzaW9uOiBHZXQgdGhlIGdyYW50IHRhYmxl
IHZlcnNpb24gd2hpY2ggaXMgaW4KICAqIGVmZmVjdCBmb3IgZG9tYWluIDxkb20+LgogICovCi0j
ZGVmaW5lIEdOVFRBQk9QX2dldF92ZXJzaW9uICAgICAgICAgIDEwCiBzdHJ1Y3QgZ250dGFiX2dl
dF92ZXJzaW9uIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzICovCiAgICAgZG9taWRfdCBkb207CkBA
IC01MTgsMTYgKzU1OSwxNSBAQCBzdHJ1Y3QgZ250dGFiX2dldF92ZXJzaW9uIHsKIHR5cGVkZWYg
c3RydWN0IGdudHRhYl9nZXRfdmVyc2lvbiBnbnR0YWJfZ2V0X3ZlcnNpb25fdDsKIERFRklORV9Y
RU5fR1VFU1RfSEFORExFKGdudHRhYl9nZXRfdmVyc2lvbl90KTsKIAotLyogCisvKgogICogR05U
VEFCT1Bfc3dhcF9ncmFudF9yZWY6IFN3YXAgdGhlIGNvbnRlbnRzIG9mIHR3byBncmFudCBlbnRy
aWVzLgogICovCi0jZGVmaW5lIEdOVFRBQk9QX3N3YXBfZ3JhbnRfcmVmCSAgICAgIDExCiBzdHJ1
Y3QgZ250dGFiX3N3YXBfZ3JhbnRfcmVmIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzICovCiAgICAg
Z3JhbnRfcmVmX3QgcmVmX2E7CiAgICAgZ3JhbnRfcmVmX3QgcmVmX2I7CiAgICAgLyogT1VUIHBh
cmFtZXRlcnMgKi8KLSAgICBpbnQxNl90IHN0YXR1czsgICAgICAgICAgICAgLyogR05UU1RfKiAq
LworICAgIGludDE2X3Qgc3RhdHVzOyAgICAgICAgICAgICAvKiA9PiBlbnVtIGdyYW50X3N0YXR1
cyAqLwogfTsKIHR5cGVkZWYgc3RydWN0IGdudHRhYl9zd2FwX2dyYW50X3JlZiBnbnR0YWJfc3dh
cF9ncmFudF9yZWZfdDsKIERFRklORV9YRU5fR1VFU1RfSEFORExFKGdudHRhYl9zd2FwX2dyYW50
X3JlZl90KTsKQEAgLTU3NSw2ICs2MTUsNyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0
YWJfc3dhcF9ncmFuCiAvKgogICogVmFsdWVzIGZvciBlcnJvciBzdGF0dXMgcmV0dXJucy4gQWxs
IGVycm9ycyBhcmUgLXZlLgogICovCisvKiBgIGVudW0gZ3JhbnRfc3RhdHVzIHsgKi8KICNkZWZp
bmUgR05UU1Rfb2theSAgICAgICAgICAgICAoMCkgIC8qIE5vcm1hbCByZXR1cm4uICAgICAgICAg
ICAgICAgICAgICAgICAgKi8KICNkZWZpbmUgR05UU1RfZ2VuZXJhbF9lcnJvciAgICAoLTEpIC8q
IEdlbmVyYWwgdW5kZWZpbmVkIGVycm9yLiAgICAgICAgICAgICAgKi8KICNkZWZpbmUgR05UU1Rf
YmFkX2RvbWFpbiAgICAgICAoLTIpIC8qIFVucmVjb2duc2VkIGRvbWFpbiBpZC4gICAgICAgICAg
ICAgICAgKi8KQEAgLTU4OCw2ICs2MjksNyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0
YWJfc3dhcF9ncmFuCiAjZGVmaW5lIEdOVFNUX2JhZF9jb3B5X2FyZyAgICAoLTEwKSAvKiBjb3B5
IGFyZ3VtZW50cyBjcm9zcyBwYWdlIGJvdW5kYXJ5LiAgICovCiAjZGVmaW5lIEdOVFNUX2FkZHJl
c3NfdG9vX2JpZyAoLTExKSAvKiB0cmFuc2ZlciBwYWdlIGFkZHJlc3MgdG9vIGxhcmdlLiAgICAg
ICovCiAjZGVmaW5lIEdOVFNUX2VhZ2FpbiAgICAgICAgICAoLTEyKSAvKiBPcGVyYXRpb24gbm90
IGRvbmU7IHRyeSBhZ2Fpbi4gICAgICAgICovCisvKiBgIH0gKi8KIAogI2RlZmluZSBHTlRUQUJP
UF9lcnJvcl9tc2dzIHsgICAgICAgICAgICAgICAgICAgXAogICAgICJva2F5IiwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXApfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 27 15:47:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 15:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S22mg-00082q-5Z; Mon, 27 Feb 2012 15:46:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S22md-00082j-UY
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 15:46:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330357590!15115714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32244 invoked from network); 27 Feb 2012 15:46:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 15:46:32 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325480400"; d="scan'208";a="183544141"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 10:46:09 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 10:46:09 -0500
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S22m8-0004sc-K5;
	Mon, 27 Feb 2012 15:46:08 +0000
MIME-Version: 1.0
X-Mercurial-Node: da2738f5050d9487313f29f4a069a8a2bacb6b55
Message-ID: <da2738f5050d9487313f.1330357568@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 27 Feb 2012 15:46:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH DOCDAY] hcall: markup the grant table hypercalls
 to improve generated 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+CiMgRGF0ZSAxMzMwMzU3NTU0IDAKIyBOb2RlIElEIGRhMjczOGY1MDUwZDk0ODcz
MTNmMjlmNGEwNjlhOGEyYmFjYjZiNTUKIyBQYXJlbnQgIGI2YTNhMGQ2OGM5MWNlOGZhNjAyM2Fl
ZTMwNDZlZmQzODY2OTQyZGYKaGNhbGw6IG1hcmt1cCB0aGUgZ3JhbnQgdGFibGUgaHlwZXJjYWxs
cyB0byBpbXByb3ZlIGdlbmVyYXRlZCBkb2NzCgpBcyBwYXJ0IG9mIHRoaXMgSSBsb29rZWQgdGhy
b3VnaCB0aGUgcmVsZXZhbnQgY2hhcHRlciBmcm9tIGludGVyZmFjZXMudGV4IChmcm9tCjQuMSwg
ZGVsZXRlZCBpbiB1bnN0YWJsZSkgdG8gZW5zdXJlIG5vIGNyaXRpY2FsIGluZm9ybWF0aW9uIHdh
cyBtaXNzaW5nLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0
cml4LmNvbT4KCmRpZmYgLXIgYjZhM2EwZDY4YzkxIC1yIGRhMjczOGY1MDUwZCB4ZW4vaW5jbHVk
ZS9wdWJsaWMvZ3JhbnRfdGFibGUuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvZ3JhbnRfdGFi
bGUuaAlNb24gRmViIDI3IDEyOjM2OjQ3IDIwMTIgKzAwMDAKKysrIGIveGVuL2luY2x1ZGUvcHVi
bGljL2dyYW50X3RhYmxlLmgJTW9uIEZlYiAyNyAxNTo0NTo1NCAyMDEyICswMDAwCkBAIC0xLDkg
KzEsOSBAQAogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICogZ3JhbnRfdGFibGUuaAotICogCisg
KgogICogSW50ZXJmYWNlIGZvciBncmFudGluZyBmb3JlaWduIGFjY2VzcyB0byBwYWdlIGZyYW1l
cywgYW5kIHJlY2VpdmluZwogICogcGFnZS1vd25lcnNoaXAgdHJhbnNmZXJzLgotICogCisgKgog
ICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJlZSBvZiBjaGFyZ2UsIHRvIGFueSBw
ZXJzb24gb2J0YWluaW5nIGEgY29weQogICogb2YgdGhpcyBzb2Z0d2FyZSBhbmQgYXNzb2NpYXRl
ZCBkb2N1bWVudGF0aW9uIGZpbGVzICh0aGUgIlNvZnR3YXJlIiksIHRvCiAgKiBkZWFsIGluIHRo
ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0
aW9uIHRoZQpAQCAtMzAsMTcgKzMwLDQxIEBACiAKICNpbmNsdWRlICJ4ZW4uaCIKIAorLyoKKyAq
IGBpbmNvbnRlbnRzIDE1MCBnbnR0YWIgR3JhbnQgVGFibGVzCisgKgorICogWGVuJ3MgZ3JhbnQg
dGFibGVzIHByb3ZpZGUgYSBnZW5lcmljIG1lY2hhbmlzbSB0byBtZW1vcnkgc2hhcmluZworICog
YmV0d2VlbiBkb21haW5zLiBUaGlzIHNoYXJlZCBtZW1vcnkgaW50ZXJmYWNlIHVuZGVycGlucyB0
aGUgc3BsaXQKKyAqIGRldmljZSBkcml2ZXJzIGZvciBibG9jayBhbmQgbmV0d29yayBJTy4KKyAq
CisgKiBFYWNoIGRvbWFpbiBoYXMgaXRzIG93biBncmFudCB0YWJsZS4gVGhpcyBpcyBhIGRhdGEg
c3RydWN0dXJlIHRoYXQKKyAqIGlzIHNoYXJlZCB3aXRoIFhlbjsgaXQgYWxsb3dzIHRoZSBkb21h
aW4gdG8gdGVsbCBYZW4gd2hhdCBraW5kIG9mCisgKiBwZXJtaXNzaW9ucyBvdGhlciBkb21haW5z
IGhhdmUgb24gaXRzIHBhZ2VzLiBFbnRyaWVzIGluIHRoZSBncmFudAorICogdGFibGUgYXJlIGlk
ZW50aWZpZWQgYnkgZ3JhbnQgcmVmZXJlbmNlcy4gQSBncmFudCByZWZlcmVuY2UgaXMgYW4KKyAq
IGludGVnZXIsIHdoaWNoIGluZGV4ZXMgaW50byB0aGUgZ3JhbnQgdGFibGUuIEl0IGFjdHMgYXMg
YQorICogY2FwYWJpbGl0eSB3aGljaCB0aGUgZ3JhbnRlZSBjYW4gdXNlIHRvIHBlcmZvcm0gb3Bl
cmF0aW9ucyBvbiB0aGUKKyAqIGdyYW50ZXLigJlzIG1lbW9yeS4KKyAqCisgKiBUaGlzIGNhcGFi
aWxpdHktYmFzZWQgc3lzdGVtIGFsbG93cyBzaGFyZWQtbWVtb3J5IGNvbW11bmljYXRpb25zCisg
KiBiZXR3ZWVuIHVucHJpdmlsZWdlZCBkb21haW5zLiBBIGdyYW50IHJlZmVyZW5jZSBhbHNvIGVu
Y2Fwc3VsYXRlcworICogdGhlIGRldGFpbHMgb2YgYSBzaGFyZWQgcGFnZSwgcmVtb3ZpbmcgdGhl
IG5lZWQgZm9yIGEgZG9tYWluIHRvCisgKiBrbm93IHRoZSByZWFsIG1hY2hpbmUgYWRkcmVzcyBv
ZiBhIHBhZ2UgaXQgaXMgc2hhcmluZy4gVGhpcyBtYWtlcworICogaXQgcG9zc2libGUgdG8gc2hh
cmUgbWVtb3J5IGNvcnJlY3RseSB3aXRoIGRvbWFpbnMgcnVubmluZyBpbgorICogZnVsbHkgdmly
dHVhbGlzZWQgbWVtb3J5LgorICovCisKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKgogICogR1JBTlQgVEFCTEUgUkVQUkVTRU5UQVRJT04KICAqLwogCiAvKiBTb21lIHJvdWdo
IGd1aWRlbGluZXMgb24gYWNjZXNzaW5nIGFuZCB1cGRhdGluZyBncmFudC10YWJsZSBlbnRyaWVz
CiAgKiBpbiBhIGNvbmN1cnJlbmN5LXNhZmUgbWFubmVyLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwg
TGludXggY29udGFpbnMgYQotICogcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIGZvciBndWVzdCBP
U2VzIChhcmNoL3hlbi9rZXJuZWwvZ3JhbnRfdGFibGUuYykuCi0gKiAKKyAqIHJlZmVyZW5jZSBp
bXBsZW1lbnRhdGlvbiBmb3IgZ3Vlc3QgT1NlcyAoZHJpdmVycy94ZW4vZ3JhbnRfdGFibGUuYywg
c2VlCisgKiBodHRwOi8vZ2l0Lmtlcm5lbC5vcmcvP3A9bGludXgva2VybmVsL2dpdC90b3J2YWxk
cy9saW51eC5naXQ7YT1ibG9iO2Y9ZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYztoYj1IRUFECisg
KgogICogTkIuIFdNQiBpcyBhIG5vLW9wIG9uIGN1cnJlbnQtZ2VuZXJhdGlvbiB4ODYgcHJvY2Vz
c29ycy4gSG93ZXZlciwgYQogICogICAgIGNvbXBpbGVyIGJhcnJpZXIgd2lsbCBzdGlsbCBiZSBy
ZXF1aXJlZC4KLSAqIAorICoKICAqIEludHJvZHVjaW5nIGEgdmFsaWQgZW50cnkgaW50byB0aGUg
Z3JhbnQgdGFibGU6CiAgKiAgMS4gV3JpdGUgZW50LT5kb21pZC4KICAqICAyLiBXcml0ZSBlbnQt
PmZyYW1lOgpAQCAtNDksNyArNzMsNyBAQAogICogICAgICAgICAgICAgICAgICAgICAgICAgICBm
cmFtZSwgb3IgemVybyBpZiBub25lLgogICogIDMuIFdyaXRlIG1lbW9yeSBiYXJyaWVyIChXTUIp
LgogICogIDQuIFdyaXRlIGVudC0+ZmxhZ3MsIGluYy4gdmFsaWQgdHlwZS4KLSAqIAorICoKICAq
IEludmFsaWRhdGluZyBhbiB1bnVzZWQgR1RGX3Blcm1pdF9hY2Nlc3MgZW50cnk6CiAgKiAgMS4g
ZmxhZ3MgPSBlbnQtPmZsYWdzLgogICogIDIuIE9ic2VydmUgdGhhdCAhKGZsYWdzICYgKEdURl9y
ZWFkaW5nfEdURl93cml0aW5nKSkuCkBAIC02MSw3ICs4NSw3IEBACiAgKiAgVGhpcyBjYW5ub3Qg
YmUgZG9uZSBkaXJlY3RseS4gUmVxdWVzdCBhc3Npc3RhbmNlIGZyb20gdGhlIGRvbWFpbiBjb250
cm9sbGVyCiAgKiAgd2hpY2ggY2FuIHNldCBhIHRpbWVvdXQgb24gdGhlIHVzZSBvZiBhIGdyYW50
IGVudHJ5IGFuZCB0YWtlIG5lY2Vzc2FyeQogICogIGFjdGlvbi4gKE5CLiBUaGlzIGlzIG5vdCB5
ZXQgaW1wbGVtZW50ZWQhKS4KLSAqIAorICoKICAqIEludmFsaWRhdGluZyBhbiB1bnVzZWQgR1RG
X2FjY2VwdF90cmFuc2ZlciBlbnRyeToKICAqICAxLiBmbGFncyA9IGVudC0+ZmxhZ3MuCiAgKiAg
Mi4gT2JzZXJ2ZSB0aGF0ICEoZmxhZ3MgJiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkKS4gWypdCkBA
IC03OSw3ICsxMDMsNyBAQAogICoKICAqIENoYW5naW5nIGEgR1RGX3Blcm1pdF9hY2Nlc3MgZnJv
bSB3cml0YWJsZSB0byByZWFkLW9ubHk6CiAgKiAgVXNlIFNNUC1zYWZlIENNUFhDSEcgdG8gc2V0
IEdURl9yZWFkb25seSwgd2hpbGUgY2hlY2tpbmcgIUdURl93cml0aW5nLgotICogCisgKgogICog
Q2hhbmdpbmcgYSBHVEZfcGVybWl0X2FjY2VzcyBmcm9tIHJlYWQtb25seSB0byB3cml0YWJsZToK
ICAqICBVc2UgU01QLXNhZmUgYml0LXNldHRpbmcgaW5zdHJ1Y3Rpb24uCiAgKi8KQEAgLTI2MSw2
ICsyODUsMzMgQEAgdHlwZWRlZiB1aW50MTZfdCBncmFudF9zdGF0dXNfdDsKICAqIEdSQU5UIFRB
QkxFIFFVRVJJRVMgQU5EIFVTRVMKICAqLwogCisvKiBgIGVudW0gbmVnX2Vycm5vdmFsCisgKiBg
IEhZUEVSVklTT1JfZ3JhbnRfdGFibGVfb3AoZW51bSBncmFudF90YWJsZV9vcCBjbWQsCisgKiBg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqYXJncywKKyAqIGAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgY291bnQpCisgKiBgCisgKgorICogQGFyZ3MgcG9p
bnRzIHRvIGFuIGFycmF5IG9mIGEgcGVyLWNvbW1hbmQgZGF0YSBzdHJ1Y3R1cmUuIFRoZSBhcnJh
eQorICogaGFzIEBjb3VudCBtZW1iZXJzICovCisgKi8KKworLyogYCBlbnVtIGdyYW50X3RhYmxl
X29wIHsgLy8gR05UVEFCT1BfKiA9PiBzdHJ1Y3QgZ250dGFiXyogKi8KKyNkZWZpbmUgR05UVEFC
T1BfbWFwX2dyYW50X3JlZiAgICAgICAgMAorI2RlZmluZSBHTlRUQUJPUF91bm1hcF9ncmFudF9y
ZWYgICAgICAxCisjZGVmaW5lIEdOVFRBQk9QX3NldHVwX3RhYmxlICAgICAgICAgIDIKKyNkZWZp
bmUgR05UVEFCT1BfZHVtcF90YWJsZSAgICAgICAgICAgMworI2RlZmluZSBHTlRUQUJPUF90cmFu
c2ZlciAgICAgICAgICAgICA0CisjZGVmaW5lIEdOVFRBQk9QX2NvcHkgICAgICAgICAgICAgICAg
IDUKKyNkZWZpbmUgR05UVEFCT1BfcXVlcnlfc2l6ZSAgICAgICAgICAgNgorI2RlZmluZSBHTlRU
QUJPUF91bm1hcF9hbmRfcmVwbGFjZSAgICA3CisjaWYgX19YRU5fSU5URVJGQUNFX1ZFUlNJT05f
XyA+PSAweDAwMDMwMjBhCisjZGVmaW5lIEdOVFRBQk9QX3NldF92ZXJzaW9uICAgICAgICAgIDgK
KyNkZWZpbmUgR05UVEFCT1BfZ2V0X3N0YXR1c19mcmFtZXMgICAgOQorI2RlZmluZSBHTlRUQUJP
UF9nZXRfdmVyc2lvbiAgICAgICAgICAxMAorI2RlZmluZSBHTlRUQUJPUF9zd2FwX2dyYW50X3Jl
ZgkgICAgICAxMQorI2VuZGlmIC8qIF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gKi8KKy8qIGAg
fSAqLworCiAvKgogICogSGFuZGxlIHRvIHRyYWNrIGEgbWFwcGluZyBjcmVhdGVkIHZpYSBhIGdy
YW50IHJlZmVyZW5jZS4KICAqLwpAQCAtMjc3LDEzICszMjgsMTIgQEAgdHlwZWRlZiB1aW50MzJf
dCBncmFudF9oYW5kbGVfdDsKICAqICAyLiBJZiBHTlRNQVBfaG9zdF9tYXAgaXMgc3BlY2lmaWVk
IHRoZW4gYSBtYXBwaW5nIHdpbGwgYmUgYWRkZWQgYXQKICAqICAgICBlaXRoZXIgYSBob3N0IHZp
cnR1YWwgYWRkcmVzcyBpbiB0aGUgY3VycmVudCBhZGRyZXNzIHNwYWNlLCBvciBhdAogICogICAg
IGEgUFRFIGF0IHRoZSBzcGVjaWZpZWQgbWFjaGluZSBhZGRyZXNzLiAgVGhlIHR5cGUgb2YgbWFw
cGluZyB0bwotICogICAgIHBlcmZvcm0gaXMgc2VsZWN0ZWQgdGhyb3VnaCB0aGUgR05UTUFQX2Nv
bnRhaW5zX3B0ZSBmbGFnLCBhbmQgdGhlIAorICogICAgIHBlcmZvcm0gaXMgc2VsZWN0ZWQgdGhy
b3VnaCB0aGUgR05UTUFQX2NvbnRhaW5zX3B0ZSBmbGFnLCBhbmQgdGhlCiAgKiAgICAgYWRkcmVz
cyBpcyBzcGVjaWZpZWQgaW4gPGhvc3RfYWRkcj4uCiAgKiAgMy4gTWFwcGluZ3Mgc2hvdWxkIG9u
bHkgYmUgZGVzdHJveWVkIHZpYSBHTlRUQUJPUF91bm1hcF9ncmFudF9yZWYuIElmIGEKICAqICAg
ICBob3N0IG1hcHBpbmcgaXMgZGVzdHJveWVkIGJ5IG90aGVyIG1lYW5zIHRoZW4gaXQgaXMgKk5P
VCogZ3VhcmFudGVlZAogICogICAgIHRvIGJlIGFjY291bnRlZCB0byB0aGUgY29ycmVjdCBncmFu
dCByZWZlcmVuY2UhCiAgKi8KLSNkZWZpbmUgR05UVEFCT1BfbWFwX2dyYW50X3JlZiAgICAgICAg
MAogc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzLiAq
LwogICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsKQEAgLTI5MSw3ICszNDEsNyBAQCBzdHJ1Y3QgZ250
dGFiX21hcF9ncmFudF9yZWYgewogICAgIGdyYW50X3JlZl90IHJlZjsKICAgICBkb21pZF90ICBk
b207CiAgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCi0gICAgaW50MTZfdCAgc3RhdHVzOyAgICAg
ICAgICAgICAgLyogR05UU1RfKiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAg
IC8qID0+IGVudW0gZ3JhbnRfc3RhdHVzICovCiAgICAgZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOwog
ICAgIHVpbnQ2NF90IGRldl9idXNfYWRkcjsKIH07CkBAIC0zMDksMTQgKzM1OSwxMyBAQCBERUZJ
TkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfbWFwX2dyYW50CiAgKiAgMy4gQWZ0ZXIgZXhlY3V0
aW5nIGEgYmF0Y2ggb2YgdW5tYXBzLCBpdCBpcyBndWFyYW50ZWVkIHRoYXQgbm8gc3RhbGUKICAq
ICAgICBtYXBwaW5ncyB3aWxsIHJlbWFpbiBpbiB0aGUgZGV2aWNlIG9yIGhvc3QgVExCcy4KICAq
LwotI2RlZmluZSBHTlRUQUJPUF91bm1hcF9ncmFudF9yZWYgICAgICAxCiBzdHJ1Y3QgZ250dGFi
X3VubWFwX2dyYW50X3JlZiB7CiAgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KICAgICB1aW50NjRf
dCBob3N0X2FkZHI7CiAgICAgdWludDY0X3QgZGV2X2J1c19hZGRyOwogICAgIGdyYW50X2hhbmRs
ZV90IGhhbmRsZTsKICAgICAvKiBPVVQgcGFyYW1ldGVycy4gKi8KLSAgICBpbnQxNl90ICBzdGF0
dXM7ICAgICAgICAgICAgICAvKiBHTlRTVF8qICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAg
ICAgICAgICAgLyogPT4gZW51bSBncmFudF9zdGF0dXMgKi8KIH07CiB0eXBlZGVmIHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmIGdudHRhYl91bm1hcF9ncmFudF9yZWZfdDsKIERFRklORV9Y
RU5fR1VFU1RfSEFORExFKGdudHRhYl91bm1hcF9ncmFudF9yZWZfdCk7CkBAIC0zMzAsMTMgKzM3
OSwxMiBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfdW5tYXBfZ3JhCiAgKiAgMi4g
T25seSBhIHN1ZmZpY2llbnRseS1wcml2aWxlZ2VkIGRvbWFpbiBtYXkgc3BlY2lmeSA8ZG9tPiAh
PSBET01JRF9TRUxGLgogICogIDMuIFhlbiBtYXkgbm90IHN1cHBvcnQgbW9yZSB0aGFuIGEgc2lu
Z2xlIGdyYW50LXRhYmxlIHBhZ2UgcGVyIGRvbWFpbi4KICAqLwotI2RlZmluZSBHTlRUQUJPUF9z
ZXR1cF90YWJsZSAgICAgICAgICAyCiBzdHJ1Y3QgZ250dGFiX3NldHVwX3RhYmxlIHsKICAgICAv
KiBJTiBwYXJhbWV0ZXJzLiAqLwogICAgIGRvbWlkX3QgIGRvbTsKICAgICB1aW50MzJfdCBucl9m
cmFtZXM7CiAgICAgLyogT1VUIHBhcmFtZXRlcnMuICovCi0gICAgaW50MTZfdCAgc3RhdHVzOyAg
ICAgICAgICAgICAgLyogR05UU1RfKiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAg
ICAgIC8qID0+IGVudW0gZ3JhbnRfc3RhdHVzICovCiAgICAgWEVOX0dVRVNUX0hBTkRMRSh1bG9u
ZykgZnJhbWVfbGlzdDsKIH07CiB0eXBlZGVmIHN0cnVjdCBnbnR0YWJfc2V0dXBfdGFibGUgZ250
dGFiX3NldHVwX3RhYmxlX3Q7CkBAIC0zNDYsMTIgKzM5NCwxMSBAQCBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShnbnR0YWJfc2V0dXBfdGFiCiAgKiBHTlRUQUJPUF9kdW1wX3RhYmxlOiBEdW1wIHRo
ZSBjb250ZW50cyBvZiB0aGUgZ3JhbnQgdGFibGUgdG8gdGhlCiAgKiB4ZW4gY29uc29sZS4gRGVi
dWdnaW5nIHVzZSBvbmx5LgogICovCi0jZGVmaW5lIEdOVFRBQk9QX2R1bXBfdGFibGUgICAgICAg
ICAgIDMKIHN0cnVjdCBnbnR0YWJfZHVtcF90YWJsZSB7CiAgICAgLyogSU4gcGFyYW1ldGVycy4g
Ki8KICAgICBkb21pZF90IGRvbTsKICAgICAvKiBPVVQgcGFyYW1ldGVycy4gKi8KLSAgICBpbnQx
Nl90IHN0YXR1czsgICAgICAgICAgICAgICAvKiBHTlRTVF8qICovCisgICAgaW50MTZfdCBzdGF0
dXM7ICAgICAgICAgICAgICAgLyogPT4gZW51bSBncmFudF9zdGF0dXMgKi8KIH07CiB0eXBlZGVm
IHN0cnVjdCBnbnR0YWJfZHVtcF90YWJsZSBnbnR0YWJfZHVtcF90YWJsZV90OwogREVGSU5FX1hF
Tl9HVUVTVF9IQU5ETEUoZ250dGFiX2R1bXBfdGFibGVfdCk7CkBAIC0zNjAsMTEgKzQwNywxMCBA
QCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfZHVtcF90YWJsCiAgKiBHTlRUQUJPUF90
cmFuc2Zlcl9ncmFudF9yZWY6IFRyYW5zZmVyIDxmcmFtZT4gdG8gYSBmb3JlaWduIGRvbWFpbi4g
VGhlCiAgKiBmb3JlaWduIGRvbWFpbiBoYXMgcHJldmlvdXNseSByZWdpc3RlcmVkIGl0cyBpbnRl
cmVzdCBpbiB0aGUgdHJhbnNmZXIgdmlhCiAgKiA8ZG9taWQsIHJlZj4uCi0gKiAKKyAqCiAgKiBO
b3RlIHRoYXQsIGV2ZW4gaWYgdGhlIHRyYW5zZmVyIGZhaWxzLCB0aGUgc3BlY2lmaWVkIHBhZ2Ug
bm8gbG9uZ2VyIGJlbG9uZ3MKICAqIHRvIHRoZSBjYWxsaW5nIGRvbWFpbiAqdW5sZXNzKiB0aGUg
ZXJyb3IgaXMgR05UU1RfYmFkX3BhZ2UuCiAgKi8KLSNkZWZpbmUgR05UVEFCT1BfdHJhbnNmZXIg
ICAgICAgICAgICAgICAgNAogc3RydWN0IGdudHRhYl90cmFuc2ZlciB7CiAgICAgLyogSU4gcGFy
YW1ldGVycy4gKi8KICAgICB4ZW5fcGZuX3QgICAgIG1mbjsKQEAgLTQwMCwxMCArNDQ2LDkgQEAg
REVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoZ250dGFiX3RyYW5zZmVyXwogI2RlZmluZSBfR05UQ09Q
WV9kZXN0X2dyZWYgICAgICAgICgxKQogI2RlZmluZSBHTlRDT1BZX2Rlc3RfZ3JlZiAgICAgICAg
ICgxPDxfR05UQ09QWV9kZXN0X2dyZWYpCiAjZGVmaW5lIF9HTlRDT1BZX2Nhbl9mYWlsICAgICAg
ICAgKDIpCi0jZGVmaW5lIEdOVENPUFlfY2FuX2ZhaWwgICAgICAgICAgKDE8PF9HTlRDT1BZX2Nh
bl9mYWlsKSAKKyNkZWZpbmUgR05UQ09QWV9jYW5fZmFpbCAgICAgICAgICAoMTw8X0dOVENPUFlf
Y2FuX2ZhaWwpCiAKLSNkZWZpbmUgR05UVEFCT1BfY29weSAgICAgICAgICAgICAgICAgNQotdHlw
ZWRlZiBzdHJ1Y3QgZ250dGFiX2NvcHkgeworc3RydWN0IGdudHRhYl9jb3B5IHsKICAgICAvKiBJ
TiBwYXJhbWV0ZXJzLiAqLwogICAgIHN0cnVjdCB7CiAgICAgICAgIHVuaW9uIHsKQEAgLTQxNyw3
ICs0NjIsOCBAQCB0eXBlZGVmIHN0cnVjdCBnbnR0YWJfY29weSB7CiAgICAgdWludDE2X3QgICAg
ICBmbGFnczsgICAgICAgICAgLyogR05UQ09QWV8qICovCiAgICAgLyogT1VUIHBhcmFtZXRlcnMu
ICovCiAgICAgaW50MTZfdCAgICAgICBzdGF0dXM7Ci19IGdudHRhYl9jb3B5X3Q7Cit9OwordHlw
ZWRlZiBzdHJ1Y3QgZ250dGFiX2NvcHkgIGdudHRhYl9jb3B5X3Q7CiBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShnbnR0YWJfY29weV90KTsKIAogLyoKQEAgLTQyNywxNCArNDczLDEzIEBAIERFRklO
RV9YRU5fR1VFU1RfSEFORExFKGdudHRhYl9jb3B5X3QpOwogICogIDEuIDxkb20+IG1heSBiZSBz
cGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KICAqICAyLiBPbmx5IGEgc3VmZmljaWVudGx5LXByaXZp
bGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NFTEYuCiAgKi8KLSNkZWZp
bmUgR05UVEFCT1BfcXVlcnlfc2l6ZSAgICAgICAgICAgNgogc3RydWN0IGdudHRhYl9xdWVyeV9z
aXplIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzLiAqLwogICAgIGRvbWlkX3QgIGRvbTsKICAgICAv
KiBPVVQgcGFyYW1ldGVycy4gKi8KICAgICB1aW50MzJfdCBucl9mcmFtZXM7CiAgICAgdWludDMy
X3QgbWF4X25yX2ZyYW1lczsKLSAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAgICAvKiBH
TlRTVF8qICovCisgICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogPT4gZW51bSBn
cmFudF9zdGF0dXMgKi8KIH07CiB0eXBlZGVmIHN0cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSBnbnR0
YWJfcXVlcnlfc2l6ZV90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoZ250dGFiX3F1ZXJ5X3Np
emVfdCk7CkBAIC00NTAsMTQgKzQ5NSwxMyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0
YWJfcXVlcnlfc2l6CiAgKiAgMi4gQWZ0ZXIgZXhlY3V0aW5nIGEgYmF0Y2ggb2YgdW5tYXBzLCBp
dCBpcyBndWFyYW50ZWVkIHRoYXQgbm8gc3RhbGUKICAqICAgICBtYXBwaW5ncyB3aWxsIHJlbWFp
biBpbiB0aGUgZGV2aWNlIG9yIGhvc3QgVExCcy4KICAqLwotI2RlZmluZSBHTlRUQUJPUF91bm1h
cF9hbmRfcmVwbGFjZSAgICA3CiBzdHJ1Y3QgZ250dGFiX3VubWFwX2FuZF9yZXBsYWNlIHsKICAg
ICAvKiBJTiBwYXJhbWV0ZXJzLiAqLwogICAgIHVpbnQ2NF90IGhvc3RfYWRkcjsKICAgICB1aW50
NjRfdCBuZXdfYWRkcjsKICAgICBncmFudF9oYW5kbGVfdCBoYW5kbGU7CiAgICAgLyogT1VUIHBh
cmFtZXRlcnMuICovCi0gICAgaW50MTZfdCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1Rf
KiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8qID0+IGVudW0gZ3JhbnRf
c3RhdHVzICovCiB9OwogdHlwZWRlZiBzdHJ1Y3QgZ250dGFiX3VubWFwX2FuZF9yZXBsYWNlIGdu
dHRhYl91bm1hcF9hbmRfcmVwbGFjZV90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoZ250dGFi
X3VubWFwX2FuZF9yZXBsYWNlX3QpOwpAQCAtNDcwLDcgKzUxNCw2IEBAIERFRklORV9YRU5fR1VF
U1RfSEFORExFKGdudHRhYl91bm1hcF9hbmQKICAqIGFyZSBhY3RpdmF0ZWQ7IG90aGVyd2lzZSwg
dGhlIGRvbWFpbiB3aWxsIGJlIHN0dWNrIHdpdGggdmVyc2lvbiAxLgogICogVGhlIG9ubHkgZGVm
aW5lZCB2ZXJzaW9ucyBhcmUgMSBhbmQgMi4KICAqLwotI2RlZmluZSBHTlRUQUJPUF9zZXRfdmVy
c2lvbiAgICAgICAgICA4CiBzdHJ1Y3QgZ250dGFiX3NldF92ZXJzaW9uIHsKICAgICAvKiBJTi9P
VVQgcGFyYW1ldGVycyAqLwogICAgIHVpbnQzMl90IHZlcnNpb247CkBAIC00OTEsMTMgKzUzNCwx
MiBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0YWJfc2V0X3ZlcnNpCiAgKiAgMS4gPGRv
bT4gbWF5IGJlIHNwZWNpZmllZCBhcyBET01JRF9TRUxGLgogICogIDIuIE9ubHkgYSBzdWZmaWNp
ZW50bHktcHJpdmlsZWdlZCBkb21haW4gbWF5IHNwZWNpZnkgPGRvbT4gIT0gRE9NSURfU0VMRi4K
ICAqLwotI2RlZmluZSBHTlRUQUJPUF9nZXRfc3RhdHVzX2ZyYW1lcyAgICAgOQogc3RydWN0IGdu
dHRhYl9nZXRfc3RhdHVzX2ZyYW1lcyB7CiAgICAgLyogSU4gcGFyYW1ldGVycy4gKi8KICAgICB1
aW50MzJfdCBucl9mcmFtZXM7CiAgICAgZG9taWRfdCAgZG9tOwogICAgIC8qIE9VVCBwYXJhbWV0
ZXJzLiAqLwotICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8qIEdOVFNUXyogKi8K
KyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAgICAvKiA9PiBlbnVtIGdyYW50X3N0YXR1
cyAqLwogICAgIFhFTl9HVUVTVF9IQU5ETEUodWludDY0X3QpIGZyYW1lX2xpc3Q7CiB9OwogdHlw
ZWRlZiBzdHJ1Y3QgZ250dGFiX2dldF9zdGF0dXNfZnJhbWVzIGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lc190OwpAQCAtNTA3LDcgKzU0OSw2IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExFKGdudHRh
Yl9nZXRfc3RhdHUKICAqIEdOVFRBQk9QX2dldF92ZXJzaW9uOiBHZXQgdGhlIGdyYW50IHRhYmxl
IHZlcnNpb24gd2hpY2ggaXMgaW4KICAqIGVmZmVjdCBmb3IgZG9tYWluIDxkb20+LgogICovCi0j
ZGVmaW5lIEdOVFRBQk9QX2dldF92ZXJzaW9uICAgICAgICAgIDEwCiBzdHJ1Y3QgZ250dGFiX2dl
dF92ZXJzaW9uIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzICovCiAgICAgZG9taWRfdCBkb207CkBA
IC01MTgsMTYgKzU1OSwxNSBAQCBzdHJ1Y3QgZ250dGFiX2dldF92ZXJzaW9uIHsKIHR5cGVkZWYg
c3RydWN0IGdudHRhYl9nZXRfdmVyc2lvbiBnbnR0YWJfZ2V0X3ZlcnNpb25fdDsKIERFRklORV9Y
RU5fR1VFU1RfSEFORExFKGdudHRhYl9nZXRfdmVyc2lvbl90KTsKIAotLyogCisvKgogICogR05U
VEFCT1Bfc3dhcF9ncmFudF9yZWY6IFN3YXAgdGhlIGNvbnRlbnRzIG9mIHR3byBncmFudCBlbnRy
aWVzLgogICovCi0jZGVmaW5lIEdOVFRBQk9QX3N3YXBfZ3JhbnRfcmVmCSAgICAgIDExCiBzdHJ1
Y3QgZ250dGFiX3N3YXBfZ3JhbnRfcmVmIHsKICAgICAvKiBJTiBwYXJhbWV0ZXJzICovCiAgICAg
Z3JhbnRfcmVmX3QgcmVmX2E7CiAgICAgZ3JhbnRfcmVmX3QgcmVmX2I7CiAgICAgLyogT1VUIHBh
cmFtZXRlcnMgKi8KLSAgICBpbnQxNl90IHN0YXR1czsgICAgICAgICAgICAgLyogR05UU1RfKiAq
LworICAgIGludDE2X3Qgc3RhdHVzOyAgICAgICAgICAgICAvKiA9PiBlbnVtIGdyYW50X3N0YXR1
cyAqLwogfTsKIHR5cGVkZWYgc3RydWN0IGdudHRhYl9zd2FwX2dyYW50X3JlZiBnbnR0YWJfc3dh
cF9ncmFudF9yZWZfdDsKIERFRklORV9YRU5fR1VFU1RfSEFORExFKGdudHRhYl9zd2FwX2dyYW50
X3JlZl90KTsKQEAgLTU3NSw2ICs2MTUsNyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0
YWJfc3dhcF9ncmFuCiAvKgogICogVmFsdWVzIGZvciBlcnJvciBzdGF0dXMgcmV0dXJucy4gQWxs
IGVycm9ycyBhcmUgLXZlLgogICovCisvKiBgIGVudW0gZ3JhbnRfc3RhdHVzIHsgKi8KICNkZWZp
bmUgR05UU1Rfb2theSAgICAgICAgICAgICAoMCkgIC8qIE5vcm1hbCByZXR1cm4uICAgICAgICAg
ICAgICAgICAgICAgICAgKi8KICNkZWZpbmUgR05UU1RfZ2VuZXJhbF9lcnJvciAgICAoLTEpIC8q
IEdlbmVyYWwgdW5kZWZpbmVkIGVycm9yLiAgICAgICAgICAgICAgKi8KICNkZWZpbmUgR05UU1Rf
YmFkX2RvbWFpbiAgICAgICAoLTIpIC8qIFVucmVjb2duc2VkIGRvbWFpbiBpZC4gICAgICAgICAg
ICAgICAgKi8KQEAgLTU4OCw2ICs2MjksNyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShnbnR0
YWJfc3dhcF9ncmFuCiAjZGVmaW5lIEdOVFNUX2JhZF9jb3B5X2FyZyAgICAoLTEwKSAvKiBjb3B5
IGFyZ3VtZW50cyBjcm9zcyBwYWdlIGJvdW5kYXJ5LiAgICovCiAjZGVmaW5lIEdOVFNUX2FkZHJl
c3NfdG9vX2JpZyAoLTExKSAvKiB0cmFuc2ZlciBwYWdlIGFkZHJlc3MgdG9vIGxhcmdlLiAgICAg
ICovCiAjZGVmaW5lIEdOVFNUX2VhZ2FpbiAgICAgICAgICAoLTEyKSAvKiBPcGVyYXRpb24gbm90
IGRvbmU7IHRyeSBhZ2Fpbi4gICAgICAgICovCisvKiBgIH0gKi8KIAogI2RlZmluZSBHTlRUQUJP
UF9lcnJvcl9tc2dzIHsgICAgICAgICAgICAgICAgICAgXAogICAgICJva2F5IiwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXApfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 27 15:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 15:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S22q5-0008CL-PF; Mon, 27 Feb 2012 15:50:13 +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 1S22q4-0008CF-Iv
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 15:50:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330357751!58498871!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23747 invoked from network); 27 Feb 2012 15:49:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 15:49:11 -0000
Received: by werm1 with SMTP id m1so873029wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 07:50:10 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.90.212 as permitted sender) client-ip=10.180.90.212; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.90.212 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.90.212])
	by 10.180.90.212 with SMTP id by20mr29410134wib.12.1330357810706
	(num_hops = 1); Mon, 27 Feb 2012 07:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lWCjm1IYLZwWJk74Lt+igAisQfuLp9r4OyPrmCC09aE=;
	b=KhyzQRxuFlwkB/SFIHqgVB4uVxz0lIwWJCV+ez/Bzsk9M4W68Qu6p70dhXduDZH41X
	Hr+EzXlj4vQEtcp60/6PhMRFwMDrd1dxB6FOVZ99lbY+ykARcPKq12CRpZKMSvw+Dpb3
	G7aOB4xyo+PRchx986xfs7J8hFdg+PINeVTqQ=
Received: by 10.180.90.212 with SMTP id by20mr23342351wib.12.1330357810612;
	Mon, 27 Feb 2012 07:50:10 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id k6sm7815274wiy.7.2012.02.27.07.50.09
	(version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 07:50:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 15:50:06 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB7156AE.2C5D6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
	hypercalls to improve generated docs
Thread-Index: Acz1Z3nAMzPOloTpdkCZ5hwsB++8Qg==
In-Reply-To: <1330346266.8557.282.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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 27/02/2012 12:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-02-27 at 12:07 +0000, Ian Campbell wrote:
>> As part of this I looked through the relevant chapter from interfaces.tex
>> (from
>> 4.1, deleted in unstable) to ensure no critical information was missing.
> 
> Actually, the intro from that chapter is interesting/useful and I missed
> it. Here's a new version with it included.
> 
> 8<-------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1330346207 0
> # Node ID b6a3a0d68c91ce8fa6023aee3046efd3866942df
> # Parent  71159fb049f253030c3820c260d092d4aec6b166
> hcall: markup the event channel hypercalls to improve generated docs
> 
> As part of this I looked through the relevant chapter from interfaces.tex
> (from
> 4.1, deleted in unstable) to ensure no critical information was missing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

(Implicit in this Ack is that you can apply this to xen-unstable yourself,
even though your commit rights are generally limited to arch/arm).

 -- Keir

> diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/event_channel.h
> --- a/xen/include/public/event_channel.h Fri Feb 24 11:46:32 2012 +0100
> +++ b/xen/include/public/event_channel.h Mon Feb 27 12:36:47 2012 +0000
> @@ -1,8 +1,8 @@
>  
> 
/*****************************************************************************>
*
>   * event_channel.h
> - * 
> + *
>   * Event channels between domains.
> - * 
> + *
>   * 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,12 +30,49 @@
>  #include "xen.h"
>  
>  /*
> - * Prototype for this hypercall is:
> - *  int event_channel_op(int cmd, void *args)
> - * @cmd  == EVTCHNOP_??? (event-channel operation).
> - * @args == Operation-specific extra arguments (NULL if none).
> + * `incontents 150 evtchn Event Channels
> + *
> + * Event channels are the basic primitive provided by Xen for event
> + * notifications. An event is the Xen equivalent of a hardware
> + * interrupt. They essentially store one bit of information, the event
> + * of interest is signalled by transitioning this bit from 0 to 1.
> + *
> + * Notifications are received by a guest via an upcall from Xen,
> + * indicating when an event arrives (setting the bit). Further
> + * notifications are masked until the bit is cleared again (therefore,
> + * guests must check the value of the bit after re-enabling event
> + * delivery to ensure no missed notifications).
> + *
> + * Event notifications can be masked by setting a flag; this is
> + * equivalent to disabling interrupts and can be used to ensure
> + * atomicity of certain operations in the guest kernel.
> + *
> + * Event channels are represented by the evtchn_* fields in
> + * struct shared_info and struct vcpu_info.
>   */
>  
> +/*
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
> + * `
> + * @cmd  == EVTCHNOP_* (event-channel operation).
> + * @args == struct evtchn_* Operation-specific extra arguments (NULL if
> none).
> + */
> +
> +/* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
> +#define EVTCHNOP_bind_interdomain 0
> +#define EVTCHNOP_bind_virq        1
> +#define EVTCHNOP_bind_pirq        2
> +#define EVTCHNOP_close            3
> +#define EVTCHNOP_send             4
> +#define EVTCHNOP_status           5
> +#define EVTCHNOP_alloc_unbound    6
> +#define EVTCHNOP_bind_ipi         7
> +#define EVTCHNOP_bind_vcpu        8
> +#define EVTCHNOP_unmask           9
> +#define EVTCHNOP_reset           10
> +/* ` } */
> +
>  typedef uint32_t evtchn_port_t;
>  DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
>  
> @@ -47,7 +84,6 @@ DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
>   *  1. If the caller is unprivileged then <dom> must be DOMID_SELF.
>   *  2. <rdom> may be DOMID_SELF, allowing loopback connections.
>   */
> -#define EVTCHNOP_alloc_unbound    6
>  struct evtchn_alloc_unbound {
>      /* IN parameters */
>      domid_t dom, remote_dom;
> @@ -63,9 +99,8 @@ typedef struct evtchn_alloc_unbound evtc
>   * domain. A fresh port is allocated in the calling domain and returned as
>   * <local_port>.
>   * NOTES:
> - *  2. <remote_dom> may be DOMID_SELF, allowing loopback connections.
> + *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
>   */
> -#define EVTCHNOP_bind_interdomain 0
>  struct evtchn_bind_interdomain {
>      /* IN parameters. */
>      domid_t remote_dom;
> @@ -87,10 +122,9 @@ typedef struct evtchn_bind_interdomain e
>   *     The allocated event channel is bound to the specified vcpu and the
>   *     binding cannot be changed.
>   */
> -#define EVTCHNOP_bind_virq        1
>  struct evtchn_bind_virq {
>      /* IN parameters. */
> -    uint32_t virq;
> +    uint32_t virq; /* enum virq */
>      uint32_t vcpu;
>      /* OUT parameters. */
>      evtchn_port_t port;
> @@ -98,12 +132,11 @@ struct evtchn_bind_virq {
>  typedef struct evtchn_bind_virq evtchn_bind_virq_t;
>  
>  /*
> - * EVTCHNOP_bind_pirq: Bind a local event channel to PIRQ <irq>.
> + * EVTCHNOP_bind_pirq: Bind a local event channel to a real IRQ (PIRQ <irq>).
>   * NOTES:
>   *  1. A physical IRQ may be bound to at most one event channel per domain.
>   *  2. Only a sufficiently-privileged domain may bind to a physical IRQ.
>   */
> -#define EVTCHNOP_bind_pirq        2
>  struct evtchn_bind_pirq {
>      /* IN parameters. */
>      uint32_t pirq;
> @@ -120,7 +153,6 @@ typedef struct evtchn_bind_pirq evtchn_b
>   *  1. The allocated event channel is bound to the specified vcpu. The
> binding
>   *     may not be changed.
>   */
> -#define EVTCHNOP_bind_ipi         7
>  struct evtchn_bind_ipi {
>      uint32_t vcpu;
>      /* OUT parameters. */
> @@ -133,7 +165,6 @@ typedef struct evtchn_bind_ipi evtchn_bi
>   * interdomain then the remote end is placed in the unbound state
>   * (EVTCHNSTAT_unbound), awaiting a new connection.
>   */
> -#define EVTCHNOP_close            3
>  struct evtchn_close {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -144,7 +175,6 @@ typedef struct evtchn_close evtchn_close
>   * EVTCHNOP_send: Send an event to the remote end of the channel whose local
>   * endpoint is <port>.
>   */
> -#define EVTCHNOP_send             4
>  struct evtchn_send {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -159,7 +189,6 @@ typedef struct evtchn_send evtchn_send_t
>   *  2. Only a sufficiently-privileged domain may obtain the status of an
> event
>   *     channel for which <dom> is not DOMID_SELF.
>   */
> -#define EVTCHNOP_status           5
>  struct evtchn_status {
>      /* IN parameters */
>      domid_t  dom;
> @@ -176,13 +205,13 @@ struct evtchn_status {
>      union {
>          struct {
>              domid_t dom;
> -        } unbound; /* EVTCHNSTAT_unbound */
> +        } unbound;                 /* EVTCHNSTAT_unbound */
>          struct {
>              domid_t dom;
>              evtchn_port_t port;
> -        } interdomain; /* EVTCHNSTAT_interdomain */
> -        uint32_t pirq;      /* EVTCHNSTAT_pirq        */
> -        uint32_t virq;      /* EVTCHNSTAT_virq        */
> +        } interdomain;             /* EVTCHNSTAT_interdomain */
> +        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
> +        uint32_t virq;             /* EVTCHNSTAT_virq        */
>      } u;
>  };
>  typedef struct evtchn_status evtchn_status_t;
> @@ -199,7 +228,6 @@ typedef struct evtchn_status evtchn_stat
>   *     the channel is allocated (a port that is freed and subsequently reused
>   *     has its binding reset to vcpu0).
>   */
> -#define EVTCHNOP_bind_vcpu        8
>  struct evtchn_bind_vcpu {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -211,7 +239,6 @@ typedef struct evtchn_bind_vcpu evtchn_b
>   * EVTCHNOP_unmask: Unmask the specified local event-channel port and deliver
>   * a notification to the appropriate VCPU if an event is pending.
>   */
> -#define EVTCHNOP_unmask           9
>  struct evtchn_unmask {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -224,7 +251,6 @@ typedef struct evtchn_unmask evtchn_unma
>   *  1. <dom> may be specified as DOMID_SELF.
>   *  2. Only a sufficiently-privileged domain may specify other than
> DOMID_SELF.
>   */
> -#define EVTCHNOP_reset           10
>  struct evtchn_reset {
>      /* IN parameters. */
>      domid_t dom;
> @@ -232,11 +258,13 @@ struct evtchn_reset {
>  typedef struct evtchn_reset evtchn_reset_t;
>  
>  /*
> - * Argument to event_channel_op_compat() hypercall. Superceded by new
> - * event_channel_op() hypercall since 0x00030202.
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
> + * `
> + * Superceded by new event_channel_op() hypercall since 0x00030202.
>   */
>  struct evtchn_op {
> -    uint32_t cmd; /* EVTCHNOP_* */
> +    uint32_t cmd; /* enum event_channel_op */
>      union {
>          struct evtchn_alloc_unbound    alloc_unbound;
>          struct evtchn_bind_interdomain bind_interdomain;
> diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/xen.h
> --- a/xen/include/public/xen.h Fri Feb 24 11:46:32 2012 +0100
> +++ b/xen/include/public/xen.h Mon Feb 27 12:36:47 2012 +0000
> @@ -146,6 +146,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>   * The latter can be allocated only once per guest: they must initially be
>   * allocated to VCPU0 but can subsequently be re-bound.
>   */
> +/* ` enum virq { */
>  #define VIRQ_TIMER      0  /* V. Timebase update, and/or requested timeout.
> */
>  #define VIRQ_DEBUG      1  /* V. Request guest to dump debug info.
> */
>  #define VIRQ_CONSOLE    2  /* G. (DOM0) Bytes received on emergency console.
> */
> @@ -167,6 +168,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #define VIRQ_ARCH_5    21
>  #define VIRQ_ARCH_6    22
>  #define VIRQ_ARCH_7    23
> +/* ` } */
>  
>  #define NR_VIRQS       24
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 15:50:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 15:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S22q5-0008CL-PF; Mon, 27 Feb 2012 15:50:13 +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 1S22q4-0008CF-Iv
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 15:50:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330357751!58498871!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23747 invoked from network); 27 Feb 2012 15:49:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 15:49:11 -0000
Received: by werm1 with SMTP id m1so873029wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 07:50:10 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.90.212 as permitted sender) client-ip=10.180.90.212; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.90.212 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.90.212])
	by 10.180.90.212 with SMTP id by20mr29410134wib.12.1330357810706
	(num_hops = 1); Mon, 27 Feb 2012 07:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lWCjm1IYLZwWJk74Lt+igAisQfuLp9r4OyPrmCC09aE=;
	b=KhyzQRxuFlwkB/SFIHqgVB4uVxz0lIwWJCV+ez/Bzsk9M4W68Qu6p70dhXduDZH41X
	Hr+EzXlj4vQEtcp60/6PhMRFwMDrd1dxB6FOVZ99lbY+ykARcPKq12CRpZKMSvw+Dpb3
	G7aOB4xyo+PRchx986xfs7J8hFdg+PINeVTqQ=
Received: by 10.180.90.212 with SMTP id by20mr23342351wib.12.1330357810612;
	Mon, 27 Feb 2012 07:50:10 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id k6sm7815274wiy.7.2012.02.27.07.50.09
	(version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 07:50:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 15:50:06 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB7156AE.2C5D6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
	hypercalls to improve generated docs
Thread-Index: Acz1Z3nAMzPOloTpdkCZ5hwsB++8Qg==
In-Reply-To: <1330346266.8557.282.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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 27/02/2012 12:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-02-27 at 12:07 +0000, Ian Campbell wrote:
>> As part of this I looked through the relevant chapter from interfaces.tex
>> (from
>> 4.1, deleted in unstable) to ensure no critical information was missing.
> 
> Actually, the intro from that chapter is interesting/useful and I missed
> it. Here's a new version with it included.
> 
> 8<-------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1330346207 0
> # Node ID b6a3a0d68c91ce8fa6023aee3046efd3866942df
> # Parent  71159fb049f253030c3820c260d092d4aec6b166
> hcall: markup the event channel hypercalls to improve generated docs
> 
> As part of this I looked through the relevant chapter from interfaces.tex
> (from
> 4.1, deleted in unstable) to ensure no critical information was missing.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

(Implicit in this Ack is that you can apply this to xen-unstable yourself,
even though your commit rights are generally limited to arch/arm).

 -- Keir

> diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/event_channel.h
> --- a/xen/include/public/event_channel.h Fri Feb 24 11:46:32 2012 +0100
> +++ b/xen/include/public/event_channel.h Mon Feb 27 12:36:47 2012 +0000
> @@ -1,8 +1,8 @@
>  
> 
/*****************************************************************************>
*
>   * event_channel.h
> - * 
> + *
>   * Event channels between domains.
> - * 
> + *
>   * 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,12 +30,49 @@
>  #include "xen.h"
>  
>  /*
> - * Prototype for this hypercall is:
> - *  int event_channel_op(int cmd, void *args)
> - * @cmd  == EVTCHNOP_??? (event-channel operation).
> - * @args == Operation-specific extra arguments (NULL if none).
> + * `incontents 150 evtchn Event Channels
> + *
> + * Event channels are the basic primitive provided by Xen for event
> + * notifications. An event is the Xen equivalent of a hardware
> + * interrupt. They essentially store one bit of information, the event
> + * of interest is signalled by transitioning this bit from 0 to 1.
> + *
> + * Notifications are received by a guest via an upcall from Xen,
> + * indicating when an event arrives (setting the bit). Further
> + * notifications are masked until the bit is cleared again (therefore,
> + * guests must check the value of the bit after re-enabling event
> + * delivery to ensure no missed notifications).
> + *
> + * Event notifications can be masked by setting a flag; this is
> + * equivalent to disabling interrupts and can be used to ensure
> + * atomicity of certain operations in the guest kernel.
> + *
> + * Event channels are represented by the evtchn_* fields in
> + * struct shared_info and struct vcpu_info.
>   */
>  
> +/*
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_event_channel_op(enum event_channel_op cmd, void *args)
> + * `
> + * @cmd  == EVTCHNOP_* (event-channel operation).
> + * @args == struct evtchn_* Operation-specific extra arguments (NULL if
> none).
> + */
> +
> +/* ` enum event_channel_op { // EVTCHNOP_* => struct evtchn_* */
> +#define EVTCHNOP_bind_interdomain 0
> +#define EVTCHNOP_bind_virq        1
> +#define EVTCHNOP_bind_pirq        2
> +#define EVTCHNOP_close            3
> +#define EVTCHNOP_send             4
> +#define EVTCHNOP_status           5
> +#define EVTCHNOP_alloc_unbound    6
> +#define EVTCHNOP_bind_ipi         7
> +#define EVTCHNOP_bind_vcpu        8
> +#define EVTCHNOP_unmask           9
> +#define EVTCHNOP_reset           10
> +/* ` } */
> +
>  typedef uint32_t evtchn_port_t;
>  DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
>  
> @@ -47,7 +84,6 @@ DEFINE_XEN_GUEST_HANDLE(evtchn_port_t);
>   *  1. If the caller is unprivileged then <dom> must be DOMID_SELF.
>   *  2. <rdom> may be DOMID_SELF, allowing loopback connections.
>   */
> -#define EVTCHNOP_alloc_unbound    6
>  struct evtchn_alloc_unbound {
>      /* IN parameters */
>      domid_t dom, remote_dom;
> @@ -63,9 +99,8 @@ typedef struct evtchn_alloc_unbound evtc
>   * domain. A fresh port is allocated in the calling domain and returned as
>   * <local_port>.
>   * NOTES:
> - *  2. <remote_dom> may be DOMID_SELF, allowing loopback connections.
> + *  1. <remote_dom> may be DOMID_SELF, allowing loopback connections.
>   */
> -#define EVTCHNOP_bind_interdomain 0
>  struct evtchn_bind_interdomain {
>      /* IN parameters. */
>      domid_t remote_dom;
> @@ -87,10 +122,9 @@ typedef struct evtchn_bind_interdomain e
>   *     The allocated event channel is bound to the specified vcpu and the
>   *     binding cannot be changed.
>   */
> -#define EVTCHNOP_bind_virq        1
>  struct evtchn_bind_virq {
>      /* IN parameters. */
> -    uint32_t virq;
> +    uint32_t virq; /* enum virq */
>      uint32_t vcpu;
>      /* OUT parameters. */
>      evtchn_port_t port;
> @@ -98,12 +132,11 @@ struct evtchn_bind_virq {
>  typedef struct evtchn_bind_virq evtchn_bind_virq_t;
>  
>  /*
> - * EVTCHNOP_bind_pirq: Bind a local event channel to PIRQ <irq>.
> + * EVTCHNOP_bind_pirq: Bind a local event channel to a real IRQ (PIRQ <irq>).
>   * NOTES:
>   *  1. A physical IRQ may be bound to at most one event channel per domain.
>   *  2. Only a sufficiently-privileged domain may bind to a physical IRQ.
>   */
> -#define EVTCHNOP_bind_pirq        2
>  struct evtchn_bind_pirq {
>      /* IN parameters. */
>      uint32_t pirq;
> @@ -120,7 +153,6 @@ typedef struct evtchn_bind_pirq evtchn_b
>   *  1. The allocated event channel is bound to the specified vcpu. The
> binding
>   *     may not be changed.
>   */
> -#define EVTCHNOP_bind_ipi         7
>  struct evtchn_bind_ipi {
>      uint32_t vcpu;
>      /* OUT parameters. */
> @@ -133,7 +165,6 @@ typedef struct evtchn_bind_ipi evtchn_bi
>   * interdomain then the remote end is placed in the unbound state
>   * (EVTCHNSTAT_unbound), awaiting a new connection.
>   */
> -#define EVTCHNOP_close            3
>  struct evtchn_close {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -144,7 +175,6 @@ typedef struct evtchn_close evtchn_close
>   * EVTCHNOP_send: Send an event to the remote end of the channel whose local
>   * endpoint is <port>.
>   */
> -#define EVTCHNOP_send             4
>  struct evtchn_send {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -159,7 +189,6 @@ typedef struct evtchn_send evtchn_send_t
>   *  2. Only a sufficiently-privileged domain may obtain the status of an
> event
>   *     channel for which <dom> is not DOMID_SELF.
>   */
> -#define EVTCHNOP_status           5
>  struct evtchn_status {
>      /* IN parameters */
>      domid_t  dom;
> @@ -176,13 +205,13 @@ struct evtchn_status {
>      union {
>          struct {
>              domid_t dom;
> -        } unbound; /* EVTCHNSTAT_unbound */
> +        } unbound;                 /* EVTCHNSTAT_unbound */
>          struct {
>              domid_t dom;
>              evtchn_port_t port;
> -        } interdomain; /* EVTCHNSTAT_interdomain */
> -        uint32_t pirq;      /* EVTCHNSTAT_pirq        */
> -        uint32_t virq;      /* EVTCHNSTAT_virq        */
> +        } interdomain;             /* EVTCHNSTAT_interdomain */
> +        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
> +        uint32_t virq;             /* EVTCHNSTAT_virq        */
>      } u;
>  };
>  typedef struct evtchn_status evtchn_status_t;
> @@ -199,7 +228,6 @@ typedef struct evtchn_status evtchn_stat
>   *     the channel is allocated (a port that is freed and subsequently reused
>   *     has its binding reset to vcpu0).
>   */
> -#define EVTCHNOP_bind_vcpu        8
>  struct evtchn_bind_vcpu {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -211,7 +239,6 @@ typedef struct evtchn_bind_vcpu evtchn_b
>   * EVTCHNOP_unmask: Unmask the specified local event-channel port and deliver
>   * a notification to the appropriate VCPU if an event is pending.
>   */
> -#define EVTCHNOP_unmask           9
>  struct evtchn_unmask {
>      /* IN parameters. */
>      evtchn_port_t port;
> @@ -224,7 +251,6 @@ typedef struct evtchn_unmask evtchn_unma
>   *  1. <dom> may be specified as DOMID_SELF.
>   *  2. Only a sufficiently-privileged domain may specify other than
> DOMID_SELF.
>   */
> -#define EVTCHNOP_reset           10
>  struct evtchn_reset {
>      /* IN parameters. */
>      domid_t dom;
> @@ -232,11 +258,13 @@ struct evtchn_reset {
>  typedef struct evtchn_reset evtchn_reset_t;
>  
>  /*
> - * Argument to event_channel_op_compat() hypercall. Superceded by new
> - * event_channel_op() hypercall since 0x00030202.
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
> + * `
> + * Superceded by new event_channel_op() hypercall since 0x00030202.
>   */
>  struct evtchn_op {
> -    uint32_t cmd; /* EVTCHNOP_* */
> +    uint32_t cmd; /* enum event_channel_op */
>      union {
>          struct evtchn_alloc_unbound    alloc_unbound;
>          struct evtchn_bind_interdomain bind_interdomain;
> diff -r 71159fb049f2 -r b6a3a0d68c91 xen/include/public/xen.h
> --- a/xen/include/public/xen.h Fri Feb 24 11:46:32 2012 +0100
> +++ b/xen/include/public/xen.h Mon Feb 27 12:36:47 2012 +0000
> @@ -146,6 +146,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>   * The latter can be allocated only once per guest: they must initially be
>   * allocated to VCPU0 but can subsequently be re-bound.
>   */
> +/* ` enum virq { */
>  #define VIRQ_TIMER      0  /* V. Timebase update, and/or requested timeout.
> */
>  #define VIRQ_DEBUG      1  /* V. Request guest to dump debug info.
> */
>  #define VIRQ_CONSOLE    2  /* G. (DOM0) Bytes received on emergency console.
> */
> @@ -167,6 +168,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #define VIRQ_ARCH_5    21
>  #define VIRQ_ARCH_6    22
>  #define VIRQ_ARCH_7    23
> +/* ` } */
>  
>  #define NR_VIRQS       24
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 16:14:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 16:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S23DU-0000nH-Nb; Mon, 27 Feb 2012 16:14: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 1S23DT-0000nC-Eb
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:14:23 +0000
Received: from [85.158.139.83:38401] by server-8.bemta-5.messagelabs.com id
	B3/29-09797-EDBAB4F4; Mon, 27 Feb 2012 16:14:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330359262!16831267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 27 Feb 2012 16:14:22 -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;
	27 Feb 2012 16:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10960512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 16:14:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 16:14:21 +0000
Message-ID: <1330359260.8557.296.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Mon, 27 Feb 2012 16:14:20 +0000
In-Reply-To: <4F44E0B0.8010007@amd.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
	<4F44E0B0.8010007@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 12:33 +0000, Christoph Egger wrote:
> On 02/22/12 12:53, Ian Campbell wrote:
> > IanJ -- when you are ready to push the xen-unstable.hg side please
> > include an update of SEABIOS_UPSTREAM_TAG to
> > 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> > is currently).
> 
> There is still one fix missing from upstream, namely: 
> 805ede2bd35243a4298bc64bd81be6db7cf57f58

I've applied this one as well and updated SEABIOS_UPSTREAM_TAG to pull
in both.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 16:14:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 16:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S23DU-0000nH-Nb; Mon, 27 Feb 2012 16:14: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 1S23DT-0000nC-Eb
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:14:23 +0000
Received: from [85.158.139.83:38401] by server-8.bemta-5.messagelabs.com id
	B3/29-09797-EDBAB4F4; Mon, 27 Feb 2012 16:14:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330359262!16831267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 27 Feb 2012 16:14:22 -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;
	27 Feb 2012 16:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10960512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 16:14:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 16:14:21 +0000
Message-ID: <1330359260.8557.296.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Mon, 27 Feb 2012 16:14:20 +0000
In-Reply-To: <4F44E0B0.8010007@amd.com>
References: <4F33ADBD.5080502@amd.com>
	<1328788790.6133.148.camel@zakaz.uk.xensource.com>
	<4F42227D.8090801@amd.com>
	<1329824022.25232.103.camel@dagon.hellion.org.uk>
	<20291.36697.376087.225279@mariner.uk.xensource.com>
	<1329831808.3990.83.camel@zakaz.uk.xensource.com>
	<20291.46269.502471.996774@mariner.uk.xensource.com>
	<1329837485.3990.111.camel@zakaz.uk.xensource.com>
	<20291.47326.624920.309995@mariner.uk.xensource.com>
	<1329841075.3990.119.camel@zakaz.uk.xensource.com>
	<1329911626.2880.42.camel@zakaz.uk.xensource.com>
	<4F44E0B0.8010007@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/seabios: override $(PYTHON)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-22 at 12:33 +0000, Christoph Egger wrote:
> On 02/22/12 12:53, Ian Campbell wrote:
> > IanJ -- when you are ready to push the xen-unstable.hg side please
> > include an update of SEABIOS_UPSTREAM_TAG to
> > 002d30b5f4f48ee203be3bad9d68dc8b538ee35b (instead of rel-1.6.3.1 as it
> > is currently).
> 
> There is still one fix missing from upstream, namely: 
> 805ede2bd35243a4298bc64bd81be6db7cf57f58

I've applied this one as well and updated SEABIOS_UPSTREAM_TAG to pull
in both.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 16:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 16:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S23QC-00012X-12; Mon, 27 Feb 2012 16:27:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S23QB-00012S-4D
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:27:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330360044!15153454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25712 invoked from network); 27 Feb 2012 16:27: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;
	27 Feb 2012 16:27:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10961077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 16:27:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 16:27:25 +0000
Message-ID: <1330360043.8557.302.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 27 Feb 2012 16:27:23 +0000
In-Reply-To: <1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:48 +0000, Stefano Stabellini wrote:
> 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".

R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
immediate (which can only target r0..r7).

Since we support only ARMv7+ there are "T2" and "T3" encodings available
which do allow direct mov of an immediate into R12, but are 32 bit Thumb
instructions.

Should we use r7 instead to maximise instruction density for Thumb code?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 16:27:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 16:27:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S23QC-00012X-12; Mon, 27 Feb 2012 16:27:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S23QB-00012S-4D
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:27:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330360044!15153454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25712 invoked from network); 27 Feb 2012 16:27: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;
	27 Feb 2012 16:27:25 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10961077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 16:27:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 16:27:25 +0000
Message-ID: <1330360043.8557.302.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 27 Feb 2012 16:27:23 +0000
In-Reply-To: <1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:48 +0000, Stefano Stabellini wrote:
> 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".

R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
immediate (which can only target r0..r7).

Since we support only ARMv7+ there are "T2" and "T3" encodings available
which do allow direct mov of an immediate into R12, but are 32 bit Thumb
instructions.

Should we use r7 instead to maximise instruction density for Thumb code?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 16:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 16: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 1S23op-00028R-0K; Mon, 27 Feb 2012 16:52:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S23om-00028C-Ug
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:52:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330361535!9031230!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5NDE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5NDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5743 invoked from network); 27 Feb 2012 16:52:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Feb 2012 16:52:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330361532; l=2634;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Dk7MWuC9+QR60XfCSby7wm8r62M=;
	b=abD3GjlqAbsha/RQE6RIfXLPBvSIKKRtSZBfgtOSkg3egFR4D/G2bAyO2o2N98+L/hR
	XoLTI21jmqz6sFAOC2DDtT0OMkGtdgFmRRZkOhfWsxvInsNukZaOMmjc3hT7JqSk2ikf9
	JnaS6bkLYNR5xxEP5+AxRGbHokzOpmuV590=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by smtp.strato.de (klopstock mo58) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p019e4o1RG8i0O ;
	Mon, 27 Feb 2012 17:51:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1F29B18638; Mon, 27 Feb 2012 17:51:53 +0100 (CET)
Date: Mon, 27 Feb 2012 17:51:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120227165152.GA32471@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120226221407.GA6385@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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 Sun, Feb 26, Olaf Hering wrote:

> On Thu, Feb 23, Tim Deegan wrote:
> 
> > This is v2 of the patch I posted last week, after feedback from Andres. 
> 
> Tried this series, but processes in dom0 started to hang in D state
> when a paged guest is started. I will see if I can spot the error.

This change for patch #5 is needed, especially the first part.
Now it appears to work.

Olaf


# HG changeset patch
# Parent c3738598897f5239a72cabde676f5e86fd4c8241

diff -r c3738598897f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -999,6 +999,10 @@ int hvm_vcpu_initialise(struct vcpu *v)
 
     v->arch.hvm_vcpu.inject_trap = -1;
 
+#ifdef CONFIG_X86_64
+    init_waitqueue_head(&v->arch.hvm_vcpu.mem_paging_wq);
+#endif
+
 #ifdef CONFIG_COMPAT
     rc = setup_compat_arg_xlat(v);
     if ( rc != 0 )
diff -r c3738598897f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -183,8 +183,8 @@ again:
             p2m_mem_paging_populate(p2m->domain, gfn);
 
         /* Wait until the pager finishes paging it in */
-        current->arch.mem_paging_gfn = gfn;
-        wait_event(current->arch.mem_paging_wq, ({
+        current->arch.hvm_vcpu.mem_paging_gfn = gfn;
+        wait_event(current->arch.hvm_vcpu.mem_paging_wq, ({
                     int done;
                     mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
                     done = (*t != p2m_ram_paging_in);
@@ -1190,8 +1190,8 @@ void p2m_mem_paging_resume(struct domain
         }
         /* Wake any vcpus that were waiting for this GFN */
         for_each_vcpu ( d, v )
-            if ( v->arch.mem_paging_gfn == rsp.gfn )
-                wake_up_all(&v->arch.mem_paging_wq);
+            if ( v->arch.hvm_vcpu.mem_paging_gfn == rsp.gfn )
+                wake_up_all(&v->arch.hvm_vcpu.mem_paging_wq);
     }
 }
 
diff -r c3738598897f xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -494,12 +494,6 @@ struct arch_vcpu
     
     struct paging_vcpu paging;
 
-#ifdef CONFIG_X86_64
-    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
-    struct waitqueue_head mem_paging_wq;
-    unsigned long mem_paging_gfn;
-#endif
-
 #ifdef CONFIG_X86_32
     /* map_domain_page() mapping cache. */
     struct mapcache_vcpu mapcache;
diff -r c3738598897f xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -170,6 +170,13 @@ struct hvm_vcpu {
     unsigned long inject_cr2;
 
     struct viridian_vcpu viridian;
+
+#ifdef CONFIG_X86_64
+    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
+    struct waitqueue_head mem_paging_wq;
+    unsigned long mem_paging_gfn;
+#endif
+
 };
 
 #endif /* __ASM_X86_HVM_VCPU_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 16:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 16: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 1S23op-00028R-0K; Mon, 27 Feb 2012 16:52:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S23om-00028C-Ug
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:52:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330361535!9031230!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5NDE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5NDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5743 invoked from network); 27 Feb 2012 16:52:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Feb 2012 16:52:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330361532; l=2634;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Dk7MWuC9+QR60XfCSby7wm8r62M=;
	b=abD3GjlqAbsha/RQE6RIfXLPBvSIKKRtSZBfgtOSkg3egFR4D/G2bAyO2o2N98+L/hR
	XoLTI21jmqz6sFAOC2DDtT0OMkGtdgFmRRZkOhfWsxvInsNukZaOMmjc3hT7JqSk2ikf9
	JnaS6bkLYNR5xxEP5+AxRGbHokzOpmuV590=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by smtp.strato.de (klopstock mo58) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p019e4o1RG8i0O ;
	Mon, 27 Feb 2012 17:51:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1F29B18638; Mon, 27 Feb 2012 17:51:53 +0100 (CET)
Date: Mon, 27 Feb 2012 17:51:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120227165152.GA32471@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120226221407.GA6385@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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 Sun, Feb 26, Olaf Hering wrote:

> On Thu, Feb 23, Tim Deegan wrote:
> 
> > This is v2 of the patch I posted last week, after feedback from Andres. 
> 
> Tried this series, but processes in dom0 started to hang in D state
> when a paged guest is started. I will see if I can spot the error.

This change for patch #5 is needed, especially the first part.
Now it appears to work.

Olaf


# HG changeset patch
# Parent c3738598897f5239a72cabde676f5e86fd4c8241

diff -r c3738598897f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -999,6 +999,10 @@ int hvm_vcpu_initialise(struct vcpu *v)
 
     v->arch.hvm_vcpu.inject_trap = -1;
 
+#ifdef CONFIG_X86_64
+    init_waitqueue_head(&v->arch.hvm_vcpu.mem_paging_wq);
+#endif
+
 #ifdef CONFIG_COMPAT
     rc = setup_compat_arg_xlat(v);
     if ( rc != 0 )
diff -r c3738598897f xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -183,8 +183,8 @@ again:
             p2m_mem_paging_populate(p2m->domain, gfn);
 
         /* Wait until the pager finishes paging it in */
-        current->arch.mem_paging_gfn = gfn;
-        wait_event(current->arch.mem_paging_wq, ({
+        current->arch.hvm_vcpu.mem_paging_gfn = gfn;
+        wait_event(current->arch.hvm_vcpu.mem_paging_wq, ({
                     int done;
                     mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
                     done = (*t != p2m_ram_paging_in);
@@ -1190,8 +1190,8 @@ void p2m_mem_paging_resume(struct domain
         }
         /* Wake any vcpus that were waiting for this GFN */
         for_each_vcpu ( d, v )
-            if ( v->arch.mem_paging_gfn == rsp.gfn )
-                wake_up_all(&v->arch.mem_paging_wq);
+            if ( v->arch.hvm_vcpu.mem_paging_gfn == rsp.gfn )
+                wake_up_all(&v->arch.hvm_vcpu.mem_paging_wq);
     }
 }
 
diff -r c3738598897f xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -494,12 +494,6 @@ struct arch_vcpu
     
     struct paging_vcpu paging;
 
-#ifdef CONFIG_X86_64
-    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
-    struct waitqueue_head mem_paging_wq;
-    unsigned long mem_paging_gfn;
-#endif
-
 #ifdef CONFIG_X86_32
     /* map_domain_page() mapping cache. */
     struct mapcache_vcpu mapcache;
diff -r c3738598897f xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -170,6 +170,13 @@ struct hvm_vcpu {
     unsigned long inject_cr2;
 
     struct viridian_vcpu viridian;
+
+#ifdef CONFIG_X86_64
+    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
+    struct waitqueue_head mem_paging_wq;
+    unsigned long mem_paging_gfn;
+#endif
+
 };
 
 #endif /* __ASM_X86_HVM_VCPU_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S241U-00030T-LC; Mon, 27 Feb 2012 17:06:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S241T-00030H-Im
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 17:06:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330362356!11289153!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17675 invoked from network); 27 Feb 2012 17:05:56 -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;
	27 Feb 2012 17:05:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10962617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 17:05:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 17:05:56 +0000
Message-ID: <1330362354.8557.306.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 27 Feb 2012 17:05:54 +0000
In-Reply-To: <1330109153-5531-1-git-send-email-david.vrabel@citrix.com>
References: <1330109153-5531-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: fix unaligned memcpy() and memmove()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 18:45 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If memcpy() and memmove() were used with source and destination of
> different alignment then the result would be all jumbled.
> 
> When their implementations were imported from Linux some macros for
> big-endian platforms were taken instead of the correct little-endian
> ones (specifically, the push and pull macros in assembler.h).
> 
> Fix this by taking Linux's arch/include/asm/assembler.h as-is and
> making only the minimum changes necessary for Xen.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>

Committed, thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17:06:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S241U-00030T-LC; Mon, 27 Feb 2012 17:06:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S241T-00030H-Im
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 17:06:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330362356!11289153!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17675 invoked from network); 27 Feb 2012 17:05:56 -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;
	27 Feb 2012 17:05:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10962617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 17:05:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 17:05:56 +0000
Message-ID: <1330362354.8557.306.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 27 Feb 2012 17:05:54 +0000
In-Reply-To: <1330109153-5531-1-git-send-email-david.vrabel@citrix.com>
References: <1330109153-5531-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] arm: fix unaligned memcpy() and memmove()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-02-24 at 18:45 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If memcpy() and memmove() were used with source and destination of
> different alignment then the result would be all jumbled.
> 
> When their implementations were imported from Linux some macros for
> big-endian platforms were taken instead of the correct little-endian
> ones (specifically, the push and pull macros in assembler.h).
> 
> Fix this by taking Linux's arch/include/asm/assembler.h as-is and
> making only the minimum changes necessary for Xen.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>

Committed, thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:22:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S24H8-0003dZ-Rg; Mon, 27 Feb 2012 17:22: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 1S24H7-0003dU-IA
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 17:22:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330363308!65311365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19769 invoked from network); 27 Feb 2012 17:21: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;
	27 Feb 2012 17:21:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10963074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 17:22:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 17:22:12 +0000
Message-ID: <1330363330.8557.314.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 27 Feb 2012 17:22:10 +0000
In-Reply-To: <alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329482789.3131.71.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual 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 Thu, 2012-02-23 at 15:45 +0000, Stefano Stabellini wrote:
> On Fri, 17 Feb 2012, Ian Campbell wrote:
> > If there's only going to be one active LR then we can jut always use LR0
> > and do away with the bitmap for the time being.
> 
> We have two lists: one list, inflight_irqs, is kept by the vgic to keep
> track of which irqs the vgic has injected and have not been eoi'd by the
> guest yet.

This means "currently live in an LR" ?

> The second list, gic.lr_pending, is a list of irqs that from the vgic
> POV have been already injected (they have been added to
> inflight_irqs already) but because of hardware limitations
> (limited availability of LR registers) the gic hasn't been able to
> inject them yet.

This means "would be in an LR if there was space" ?

Is lr_pending list a superset of the inflight_irqs ones? Or are they
always disjoint? If they are disjoint then doesn't a single list next
pointer in struct pending_irq suffice?

It would be really nice to have a comment somewhere which describes the
purpose of these lists and what the invariants are for an entry on them.

> Here we are going through the second list, gic.lr_pending, that is
> ordered by priority, and we are inserting this last guest irq in the
> right spot so that as soon as an LR register is available we can
> actually inject it into the guest.
> 
> The vgic is not actually aware that the gic hasn't managed to inject the
> irq yet.

I was just looking at applying v4 and it has:

> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;

I think two list fields named link and lr_link need something to
describe and/or distinguish them, their purpose etc.

The use of the name "pending" as the field in the struct is a little
confusing, because there are multiple ways in which an interrupt can be
pending, both in and out of an LR.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:22:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S24H8-0003dZ-Rg; Mon, 27 Feb 2012 17:22: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 1S24H7-0003dU-IA
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 17:22:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330363308!65311365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19769 invoked from network); 27 Feb 2012 17:21: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;
	27 Feb 2012 17:21:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10963074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 17:22:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 17:22:12 +0000
Message-ID: <1330363330.8557.314.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 27 Feb 2012 17:22:10 +0000
In-Reply-To: <alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329482789.3131.71.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual 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 Thu, 2012-02-23 at 15:45 +0000, Stefano Stabellini wrote:
> On Fri, 17 Feb 2012, Ian Campbell wrote:
> > If there's only going to be one active LR then we can jut always use LR0
> > and do away with the bitmap for the time being.
> 
> We have two lists: one list, inflight_irqs, is kept by the vgic to keep
> track of which irqs the vgic has injected and have not been eoi'd by the
> guest yet.

This means "currently live in an LR" ?

> The second list, gic.lr_pending, is a list of irqs that from the vgic
> POV have been already injected (they have been added to
> inflight_irqs already) but because of hardware limitations
> (limited availability of LR registers) the gic hasn't been able to
> inject them yet.

This means "would be in an LR if there was space" ?

Is lr_pending list a superset of the inflight_irqs ones? Or are they
always disjoint? If they are disjoint then doesn't a single list next
pointer in struct pending_irq suffice?

It would be really nice to have a comment somewhere which describes the
purpose of these lists and what the invariants are for an entry on them.

> Here we are going through the second list, gic.lr_pending, that is
> ordered by priority, and we are inserting this last guest irq in the
> right spot so that as soon as an LR register is available we can
> actually inject it into the guest.
> 
> The vgic is not actually aware that the gic hasn't managed to inject the
> irq yet.

I was just looking at applying v4 and it has:

> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;

I think two list fields named link and lr_link need something to
describe and/or distinguish them, their purpose etc.

The use of the name "pending" as the field in the struct is a little
confusing, because there are multiple ways in which an interrupt can be
pending, both in and out of an LR.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:32:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S24Qw-0003qO-U4; Mon, 27 Feb 2012 17:32:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S24Qv-0003qF-8I
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 17:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330363935!15142144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13787 invoked from network); 27 Feb 2012 17:32:15 -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;
	27 Feb 2012 17:32:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10963516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 17:32:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 17:32:15 +0000
Message-ID: <1330363933.8557.317.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 27 Feb 2012 17:32:13 +0000
In-Reply-To: <437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor
 init out of the per-CPU init function
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
> # Parent  ec051056db2b6d37344629e2f01d17240099d5ec
> arm: Move some GIC distributor init out of the per-CPU init function
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
> --- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
>      for ( i = 32; i < gic.lines; i += 32 )
>          GICD[GICD_ICENABLER + i / 32] = ~0ul;
>  
> -    /* Turn on the distributor */
> -    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> -}
> -
> -static void __cpuinit gic_cpu_init(void)
> -{
> -    int i;
> -
>      /* Disable all PPI and enable all SGI */
>      GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
>      GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */

PPIs and SGIs are per physical-CPU and therefore, I think, the GICD
registers of various sorts which refer to the first 32 interrupts are
per physical-CPU as well. IOW moving these from gic_cpu_init to
gic_dist_init is wrong?


> @@ -231,6 +223,12 @@ static void __cpuinit gic_cpu_init(void)
>      for (i = 0; i < 32; i += 4)
>          GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
>  
> +    /* Turn on the distributor */
> +    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> +}
> +
> +static void __cpuinit gic_cpu_init(void)
> +{
>      /* Local settings: interface controller */
>      GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
>      GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:32:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17:32:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S24Qw-0003qO-U4; Mon, 27 Feb 2012 17:32:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S24Qv-0003qF-8I
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 17:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330363935!15142144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13787 invoked from network); 27 Feb 2012 17:32:15 -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;
	27 Feb 2012 17:32:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="10963516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 17:32:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 17:32:15 +0000
Message-ID: <1330363933.8557.317.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 27 Feb 2012 17:32:13 +0000
In-Reply-To: <437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor
 init out of the per-CPU init function
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
> # Parent  ec051056db2b6d37344629e2f01d17240099d5ec
> arm: Move some GIC distributor init out of the per-CPU init function
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
> --- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
>      for ( i = 32; i < gic.lines; i += 32 )
>          GICD[GICD_ICENABLER + i / 32] = ~0ul;
>  
> -    /* Turn on the distributor */
> -    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> -}
> -
> -static void __cpuinit gic_cpu_init(void)
> -{
> -    int i;
> -
>      /* Disable all PPI and enable all SGI */
>      GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
>      GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */

PPIs and SGIs are per physical-CPU and therefore, I think, the GICD
registers of various sorts which refer to the first 32 interrupts are
per physical-CPU as well. IOW moving these from gic_cpu_init to
gic_dist_init is wrong?


> @@ -231,6 +223,12 @@ static void __cpuinit gic_cpu_init(void)
>      for (i = 0; i < 32; i += 4)
>          GICD[GICD_IPRIORITYR + i / 4] = 0xa0a0a0a0;
>  
> +    /* Turn on the distributor */
> +    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> +}
> +
> +static void __cpuinit gic_cpu_init(void)
> +{
>      /* Local settings: interface controller */
>      GICC[GICC_PMR] = 0xff;                /* Don't mask by priority */
>      GICC[GICC_BPR] = 0;                   /* Finest granularity of priority */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17: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 1S24TU-0003w0-FR; Mon, 27 Feb 2012 17:35:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henrik@fixme.se>) id 1S24TT-0003vv-6Y
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 17:34:59 +0000
X-Env-Sender: henrik@fixme.se
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330364092!15152124!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11338 invoked from network); 27 Feb 2012 17:34:53 -0000
Received: from mail-vw0-f45.google.com (HELO mail-vw0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 17:34:53 -0000
Received: by vbbfs19 with SMTP id fs19so734246vbb.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 09:34:51 -0800 (PST)
Received-SPF: pass (google.com: domain of henrik@fixme.se designates
	10.52.95.78 as permitted sender) client-ip=10.52.95.78; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of henrik@fixme.se
	designates 10.52.95.78 as permitted sender)
	smtp.mail=henrik@fixme.se
Received: from mr.google.com ([10.52.95.78])
	by 10.52.95.78 with SMTP id di14mr7838008vdb.56.1330364091916 (num_hops
	= 1); Mon, 27 Feb 2012 09:34:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.95.78 with SMTP id di14mr6387328vdb.56.1330364091597; Mon,
	27 Feb 2012 09:34:51 -0800 (PST)
Received: by 10.220.198.133 with HTTP; Mon, 27 Feb 2012 09:34:51 -0800 (PST)
In-Reply-To: <4F468B96.5030703@cantab.net>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
	<4F468B96.5030703@cantab.net>
Date: Mon, 27 Feb 2012 18:34:51 +0100
Message-ID: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
From: Henrik Olsson <henrik@fixme.se>
To: David Vrabel <dvrabel@cantab.net>
X-Gm-Message-State: ALoCoQkYB3CbM3B85BoHNwc0m138EzsUQCmCZpEM04noNF9WKdhFZGhT+jUuehII5kukp1+c+aJl
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 19:55, David Vrabel <dvrabel@cantab.net> wrote:
> On 22/02/12 22:19, Henrik Olsson wrote:
>> Hi, i'm having some trouble with assigning memory to my dom0.
>>
>> I've added "dom0_mem=3D8192M" to the xen command line yet "free -m"
>> reports only 5686MB total.
>
> [ =A0 =A00.000000] Freeing =A06f000-100000 pfn range: 593920 pages freed
> [ =A0 =A00.000000] 1-1 mapping on 6f000->100000
> [ =A0 =A00.000000] Released 595312 pages of unused memory
>
> This accounts for most of your "missing" memory. =A0To get it back you
> need to adjust the balloon driver's target to the amount of memory you wa=
nt.
>
> David

Hi, i'm not sure i understand..

I've configured /etc/xen/xend-config.sxp with:
(dom0-min-mem 8192)
(enable-dom0-ballooning no)

Shouldn't this disable ballooning? Or do i need to pass some parameter
somewhere?

Regards,
Henrik

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 17:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 17: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 1S24TU-0003w0-FR; Mon, 27 Feb 2012 17:35:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <henrik@fixme.se>) id 1S24TT-0003vv-6Y
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 17:34:59 +0000
X-Env-Sender: henrik@fixme.se
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330364092!15152124!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11338 invoked from network); 27 Feb 2012 17:34:53 -0000
Received: from mail-vw0-f45.google.com (HELO mail-vw0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 17:34:53 -0000
Received: by vbbfs19 with SMTP id fs19so734246vbb.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 09:34:51 -0800 (PST)
Received-SPF: pass (google.com: domain of henrik@fixme.se designates
	10.52.95.78 as permitted sender) client-ip=10.52.95.78; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of henrik@fixme.se
	designates 10.52.95.78 as permitted sender)
	smtp.mail=henrik@fixme.se
Received: from mr.google.com ([10.52.95.78])
	by 10.52.95.78 with SMTP id di14mr7838008vdb.56.1330364091916 (num_hops
	= 1); Mon, 27 Feb 2012 09:34:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.95.78 with SMTP id di14mr6387328vdb.56.1330364091597; Mon,
	27 Feb 2012 09:34:51 -0800 (PST)
Received: by 10.220.198.133 with HTTP; Mon, 27 Feb 2012 09:34:51 -0800 (PST)
In-Reply-To: <4F468B96.5030703@cantab.net>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
	<4F468B96.5030703@cantab.net>
Date: Mon, 27 Feb 2012 18:34:51 +0100
Message-ID: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
From: Henrik Olsson <henrik@fixme.se>
To: David Vrabel <dvrabel@cantab.net>
X-Gm-Message-State: ALoCoQkYB3CbM3B85BoHNwc0m138EzsUQCmCZpEM04noNF9WKdhFZGhT+jUuehII5kukp1+c+aJl
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Feb 23, 2012 at 19:55, David Vrabel <dvrabel@cantab.net> wrote:
> On 22/02/12 22:19, Henrik Olsson wrote:
>> Hi, i'm having some trouble with assigning memory to my dom0.
>>
>> I've added "dom0_mem=3D8192M" to the xen command line yet "free -m"
>> reports only 5686MB total.
>
> [ =A0 =A00.000000] Freeing =A06f000-100000 pfn range: 593920 pages freed
> [ =A0 =A00.000000] 1-1 mapping on 6f000->100000
> [ =A0 =A00.000000] Released 595312 pages of unused memory
>
> This accounts for most of your "missing" memory. =A0To get it back you
> need to adjust the balloon driver's target to the amount of memory you wa=
nt.
>
> David

Hi, i'm not sure i understand..

I've configured /etc/xen/xend-config.sxp with:
(dom0-min-mem 8192)
(enable-dom0-ballooning no)

Shouldn't this disable ballooning? Or do i need to pass some parameter
somewhere?

Regards,
Henrik

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 18:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 18:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S25Yh-0005P1-KI; Mon, 27 Feb 2012 18:44:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1S25Yf-0005Ow-Kd
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 18:44:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330368257!17160461!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32446 invoked from network); 27 Feb 2012 18:44:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 18:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325480400"; d="scan'208";a="183580191"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 13:43:12 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 27 Feb 2012
	13:43:11 -0500
Message-ID: <4F4BCEBE.6010608@citrix.com>
Date: Mon, 27 Feb 2012 18:43:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@eu.citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050908050506060600090503"
Subject: [Xen-devel] DOC-DAY: WIP for command line options 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050908050506060600090503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Attached is an attempt to document all the Xen command line parameters.

Because of other tasks, (and choosing to document the rather twisty
'acpi' option first), It is far less complete than I was hoping.

However, I am submitting it so other people may benefit (and contribute)
going forward.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050908050506060600090503
Content-Type: text/x-patch; name="xen-cmdline-docs.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen-cmdline-docs.patch"

# HG changeset patch
# Parent a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
DOCS: Initial document regarding Xen's command line parameters

Still a work in progress, but submitted as a start.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a4d93d0e0df2 docs/misc/xen-command-line.markdown
--- /dev/null
+++ b/docs/misc/xen-command-line.markdown
@@ -0,0 +1,222 @@
+# 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 coveres the command line options which the Xen Hypervisor.
+
+## Types of parameter
+
+Most parameters take the form `option=value`.  Different options on the command line should be space delimited.
+
+### Boolean
+
+All boolean option may be explicitly enabled using a `value` of
+> `yes`, `on`, `true`, `enable` or `1`
+
+They may be explicitly disabled using a `value` of
+> `no`, `off`, `false`, `disable` or `0`
+
+In addition, a boolean option may be enabled by simply stating its name, and may be disabled by prefixing its name with `no-`.
+
+####Examples
+
+Enable noreboot mode
+> `noreboot=true`
+
+Disable x2apic support (if present)
+> `x2apic=off`
+
+Enable synchronous console mode
+> `sync_console`
+
+### Integer
+
+An integer parameter will default to decimal and may be prefixed with a `-` for negative numbers.  Alternativly, a hexidecimal number may be used by prefixing the number with `0x`, or an octal number may be used if a leading `0` is present.
+
+### Size
+
+A size parameter may be any integer, with a size suffix
+
+* `G` or `g`: Giga (2^30)
+* `M` or `m`: Mega (2^20)
+* `K` or `k`: Kilo (2^10)
+* `B` or `b`: Bytes
+
+Without a size suffix, the default will be kilo.
+
+### String
+
+Many parameters are more complicated and require more intricate configuration.  The detailed description of each individual paramter specify which values are valid.
+
+### Combination
+
+Some parameters act as combinations of the above, most commonly a mix of Boolean and String.  These are noted in the relevant sections.
+
+## Parameter details
+
+### acpi
+> `= force | ht | noirq | <boolean>`
+
+**String**, or **Boolean** to disable.
+
+The `acpi` option is used to control a set of four related boolean flags; `acpi_force`, `acpi_ht`, `acpi_noirq` and `acpi_disabled`.
+
+By default, Xen will scan the DMI data and blacklist certain systems which are known to have broken ACPI setups.  Providing `acpi=force` will cause Xen to ignore the blacklist and attempt to use all ACPI features.
+
+Using `acpi=ht` causes Xen to parse the ACPI tables enough to enumerate all CPUs, but will not use other ACPI features.  This is not common, and only has an effect if your system is blacklisted.
+
+The `acpi=noirq` option causes Xen to not parse the ACPI MADT table looking for IO-APIC entries.  This is also not common, and any system which requries this option to function should be blacklisted.  Additionally, this will not prevent Xen from finding IO-APIC entries from the MP tables.
+
+Finally, any of the boolean false options can be used to disable ACPI usage entirely.
+
+### acpi\_apic\_instance
+> `= <integer>`
+
+Specify which ACPI MADT table to parse for APIC information, if more than one is present.
+
+### acpi\_pstate\_strict
+### acpi\_skip\_timer\_override
+### acpi\_sleep
+### additional\_cpus
+### allowsuperpage
+### apic
+> `= summit | bigsmp | default`
+
+Override Xen's logic for choosing the APIC driver.  By default, if there are more than 8 CPUs, Xen will switch to `bigsmp` over `default`.
+
+### apic\_verbosity
+> `= verbose | debug`
+
+Increase the verbosity of the APIC code from the default value.
+
+### ats
+### availmem
+### badpage
+### bootscrub
+### cachesize
+### clocksource
+### com1
+### com2
+### conring\_size
+### console
+### console\_timestamps
+### console\_to\_ring
+### conswitch
+### contig\_mem
+### cpu\_type
+### cpufreq
+### cpuid\_mask\_cpu
+### cpuid\_mask\_ecx
+### cpuid\_mask\_edx
+### cpuid\_mask\_ext\_ecx
+### cpuid\_mask\_ext\_edx
+### cpuid\_mask\_xsave\_eax
+### cpuidle
+### cpuinfo
+### crashkernel
+### credit2\_balance\_over
+### credit2\_balance\_under
+### credit2\_load\_window\_shift
+### debug\_stack\_lines
+### debug\_stack\_lines
+### debugtrace
+### dma\_bits
+### dom0\_ioports\_disable
+### dom0\_max\_vcpus
+### dom0\_max\_vcpus
+### dom0\_max\_vcpus
+### dom0\_mem
+### dom0\_mem
+### dom0\_shadow
+### dom0\_vcpus\_pin
+### dom0\_vhpt\_size\_log2
+### dom\_rid\_bits
+### e820-mtrr-clip
+### e820-verbose
+### efi\_print
+### extra\_guest\_irqs
+### flask\_enabled
+### flask\_enforcing
+### font
+### gdb
+### gnttab\_max\_nr\_frames
+### guest\_loglvl
+### hap\_1gb
+### hap\_2mb
+### hpetbroadcast
+### hvm\_debug
+### hvm\_port80
+### idle\_latency\_factor
+### ioapic\_ack
+### iommu
+### iommu\_inclusive\_mapping
+### irq\_ratelimit
+### irq\_vector\_map
+### lapic
+### lapic\_timer\_c2\_ok
+### ler
+### loglvl
+### max\_cstate
+### max\_gsi\_irqs
+### maxcpus
+### maxcpus
+### mce
+### mce\_fb
+### mce\_verbosity
+### mem
+### mmcfg
+### nmi
+### noapic
+### nofxsr
+### noirqbalance
+### nolapic
+### noreboot
+### noserialnumber
+### nosmp
+### nosmp
+### nr\_irqs
+### numa
+### pervcpu\_vhpt
+### ple\_gap
+### ple\_window
+### reboot
+### sched
+### sched\_credit2\_migrate\_resist
+### sched\_credit\_default\_yield
+### sched\_credit\_tslice\_ms
+### sched\_ratelimit\_us
+### sched\_smt\_power\_savings
+### serial\_tx\_buffer
+### smep
+### snb\_igd\_quirk
+### sync\_console
+### tboot
+### tbuf\_size
+### tdt
+### tevt\_mask
+### tickle\_one\_idle\_cpu
+### timer\_slop
+### tmem
+### tmem\_compress
+### tmem\_dedup
+### tmem\_lock
+### tmem\_shared\_auth
+### tmem\_tze
+### tsc
+### ucode
+### unrestricted\_guest
+### vcpu\_migration\_delay
+### vesa-map
+### vesa-mtrr
+### vesa-ram
+### vga
+### vpid
+### vpmu
+### vti\_vhpt\_size
+### vti\_vtlb\_size
+### watchdog
+### x2apic
+### x2apic\_phys
+### xencons
+### xencons\_poll
+### xsave

--------------050908050506060600090503
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050908050506060600090503--


From xen-devel-bounces@lists.xen.org Mon Feb 27 18:45:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 18:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S25Yh-0005P1-KI; Mon, 27 Feb 2012 18:44:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1S25Yf-0005Ow-Kd
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 18:44:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1330368257!17160461!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg1NzU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32446 invoked from network); 27 Feb 2012 18:44:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 18:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325480400"; d="scan'208";a="183580191"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 13:43:12 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Mon, 27 Feb 2012
	13:43:11 -0500
Message-ID: <4F4BCEBE.6010608@citrix.com>
Date: Mon, 27 Feb 2012 18:43:10 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@eu.citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------050908050506060600090503"
Subject: [Xen-devel] DOC-DAY: WIP for command line options 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050908050506060600090503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Attached is an attempt to document all the Xen command line parameters.

Because of other tasks, (and choosing to document the rather twisty
'acpi' option first), It is far less complete than I was hoping.

However, I am submitting it so other people may benefit (and contribute)
going forward.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050908050506060600090503
Content-Type: text/x-patch; name="xen-cmdline-docs.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen-cmdline-docs.patch"

# HG changeset patch
# Parent a4d93d0e0df2fafe5b3e2dab3e34799498a875e2
DOCS: Initial document regarding Xen's command line parameters

Still a work in progress, but submitted as a start.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a4d93d0e0df2 docs/misc/xen-command-line.markdown
--- /dev/null
+++ b/docs/misc/xen-command-line.markdown
@@ -0,0 +1,222 @@
+# 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 coveres the command line options which the Xen Hypervisor.
+
+## Types of parameter
+
+Most parameters take the form `option=value`.  Different options on the command line should be space delimited.
+
+### Boolean
+
+All boolean option may be explicitly enabled using a `value` of
+> `yes`, `on`, `true`, `enable` or `1`
+
+They may be explicitly disabled using a `value` of
+> `no`, `off`, `false`, `disable` or `0`
+
+In addition, a boolean option may be enabled by simply stating its name, and may be disabled by prefixing its name with `no-`.
+
+####Examples
+
+Enable noreboot mode
+> `noreboot=true`
+
+Disable x2apic support (if present)
+> `x2apic=off`
+
+Enable synchronous console mode
+> `sync_console`
+
+### Integer
+
+An integer parameter will default to decimal and may be prefixed with a `-` for negative numbers.  Alternativly, a hexidecimal number may be used by prefixing the number with `0x`, or an octal number may be used if a leading `0` is present.
+
+### Size
+
+A size parameter may be any integer, with a size suffix
+
+* `G` or `g`: Giga (2^30)
+* `M` or `m`: Mega (2^20)
+* `K` or `k`: Kilo (2^10)
+* `B` or `b`: Bytes
+
+Without a size suffix, the default will be kilo.
+
+### String
+
+Many parameters are more complicated and require more intricate configuration.  The detailed description of each individual paramter specify which values are valid.
+
+### Combination
+
+Some parameters act as combinations of the above, most commonly a mix of Boolean and String.  These are noted in the relevant sections.
+
+## Parameter details
+
+### acpi
+> `= force | ht | noirq | <boolean>`
+
+**String**, or **Boolean** to disable.
+
+The `acpi` option is used to control a set of four related boolean flags; `acpi_force`, `acpi_ht`, `acpi_noirq` and `acpi_disabled`.
+
+By default, Xen will scan the DMI data and blacklist certain systems which are known to have broken ACPI setups.  Providing `acpi=force` will cause Xen to ignore the blacklist and attempt to use all ACPI features.
+
+Using `acpi=ht` causes Xen to parse the ACPI tables enough to enumerate all CPUs, but will not use other ACPI features.  This is not common, and only has an effect if your system is blacklisted.
+
+The `acpi=noirq` option causes Xen to not parse the ACPI MADT table looking for IO-APIC entries.  This is also not common, and any system which requries this option to function should be blacklisted.  Additionally, this will not prevent Xen from finding IO-APIC entries from the MP tables.
+
+Finally, any of the boolean false options can be used to disable ACPI usage entirely.
+
+### acpi\_apic\_instance
+> `= <integer>`
+
+Specify which ACPI MADT table to parse for APIC information, if more than one is present.
+
+### acpi\_pstate\_strict
+### acpi\_skip\_timer\_override
+### acpi\_sleep
+### additional\_cpus
+### allowsuperpage
+### apic
+> `= summit | bigsmp | default`
+
+Override Xen's logic for choosing the APIC driver.  By default, if there are more than 8 CPUs, Xen will switch to `bigsmp` over `default`.
+
+### apic\_verbosity
+> `= verbose | debug`
+
+Increase the verbosity of the APIC code from the default value.
+
+### ats
+### availmem
+### badpage
+### bootscrub
+### cachesize
+### clocksource
+### com1
+### com2
+### conring\_size
+### console
+### console\_timestamps
+### console\_to\_ring
+### conswitch
+### contig\_mem
+### cpu\_type
+### cpufreq
+### cpuid\_mask\_cpu
+### cpuid\_mask\_ecx
+### cpuid\_mask\_edx
+### cpuid\_mask\_ext\_ecx
+### cpuid\_mask\_ext\_edx
+### cpuid\_mask\_xsave\_eax
+### cpuidle
+### cpuinfo
+### crashkernel
+### credit2\_balance\_over
+### credit2\_balance\_under
+### credit2\_load\_window\_shift
+### debug\_stack\_lines
+### debug\_stack\_lines
+### debugtrace
+### dma\_bits
+### dom0\_ioports\_disable
+### dom0\_max\_vcpus
+### dom0\_max\_vcpus
+### dom0\_max\_vcpus
+### dom0\_mem
+### dom0\_mem
+### dom0\_shadow
+### dom0\_vcpus\_pin
+### dom0\_vhpt\_size\_log2
+### dom\_rid\_bits
+### e820-mtrr-clip
+### e820-verbose
+### efi\_print
+### extra\_guest\_irqs
+### flask\_enabled
+### flask\_enforcing
+### font
+### gdb
+### gnttab\_max\_nr\_frames
+### guest\_loglvl
+### hap\_1gb
+### hap\_2mb
+### hpetbroadcast
+### hvm\_debug
+### hvm\_port80
+### idle\_latency\_factor
+### ioapic\_ack
+### iommu
+### iommu\_inclusive\_mapping
+### irq\_ratelimit
+### irq\_vector\_map
+### lapic
+### lapic\_timer\_c2\_ok
+### ler
+### loglvl
+### max\_cstate
+### max\_gsi\_irqs
+### maxcpus
+### maxcpus
+### mce
+### mce\_fb
+### mce\_verbosity
+### mem
+### mmcfg
+### nmi
+### noapic
+### nofxsr
+### noirqbalance
+### nolapic
+### noreboot
+### noserialnumber
+### nosmp
+### nosmp
+### nr\_irqs
+### numa
+### pervcpu\_vhpt
+### ple\_gap
+### ple\_window
+### reboot
+### sched
+### sched\_credit2\_migrate\_resist
+### sched\_credit\_default\_yield
+### sched\_credit\_tslice\_ms
+### sched\_ratelimit\_us
+### sched\_smt\_power\_savings
+### serial\_tx\_buffer
+### smep
+### snb\_igd\_quirk
+### sync\_console
+### tboot
+### tbuf\_size
+### tdt
+### tevt\_mask
+### tickle\_one\_idle\_cpu
+### timer\_slop
+### tmem
+### tmem\_compress
+### tmem\_dedup
+### tmem\_lock
+### tmem\_shared\_auth
+### tmem\_tze
+### tsc
+### ucode
+### unrestricted\_guest
+### vcpu\_migration\_delay
+### vesa-map
+### vesa-mtrr
+### vesa-ram
+### vga
+### vpid
+### vpmu
+### vti\_vhpt\_size
+### vti\_vtlb\_size
+### watchdog
+### x2apic
+### x2apic\_phys
+### xencons
+### xencons\_poll
+### xsave

--------------050908050506060600090503
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050908050506060600090503--


From xen-devel-bounces@lists.xen.org Mon Feb 27 18:45:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 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 1S25Zj-0005Se-6s; Mon, 27 Feb 2012 18:45: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 1S25Zh-0005SS-Q1
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 18:45:30 +0000
Received: from [85.158.139.83:6024] by server-11.bemta-5.messagelabs.com id
	E5/D2-14397-84FCB4F4; Mon, 27 Feb 2012 18:45:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1330368328!16911686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22289 invoked from network); 27 Feb 2012 18:45:28 -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;
	27 Feb 2012 18:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="10964665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 18:45:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 18:45:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S25Zf-0007DZ-EU;
	Mon, 27 Feb 2012 18:45:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S25Zf-00035T-8y;
	Mon, 27 Feb 2012 18:45:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12090-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 27 Feb 2012 18:45:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12090: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12090 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12090/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 12085
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12085 pass in 12090

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 18:45:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 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 1S25Zj-0005Se-6s; Mon, 27 Feb 2012 18:45: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 1S25Zh-0005SS-Q1
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 18:45:30 +0000
Received: from [85.158.139.83:6024] by server-11.bemta-5.messagelabs.com id
	E5/D2-14397-84FCB4F4; Mon, 27 Feb 2012 18:45:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1330368328!16911686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22289 invoked from network); 27 Feb 2012 18:45:28 -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;
	27 Feb 2012 18:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="10964665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 18:45:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 18:45:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S25Zf-0007DZ-EU;
	Mon, 27 Feb 2012 18:45:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S25Zf-00035T-8y;
	Mon, 27 Feb 2012 18:45:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12090-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 27 Feb 2012 18:45:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12090: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12090 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12090/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 12031
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 12031
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 12031
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 12031
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 12031
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 12031
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 12031
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 12031
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 12031

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 12085
 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail in 12085 pass in 12090

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass

version targeted for testing:
 xen                  71159fb049f2
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 348 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 18:56:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 18:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S25jy-00062G-3v; Mon, 27 Feb 2012 18:56:06 +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 1S25jw-00062B-LK
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 18:56:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330368890!58414856!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24456 invoked from network); 27 Feb 2012 18:54:50 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 18:54:50 -0000
Received: by wgbdr12 with SMTP id dr12so1918864wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 10:55:58 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.86.9 as permitted sender) client-ip=10.180.86.9; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.86.9 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.86.9])
	by 10.180.86.9 with SMTP id l9mr31082497wiz.15.1330368958565 (num_hops
	= 1); Mon, 27 Feb 2012 10:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tUAf3ZglROwwQnpdIaLkBQgsqL6cMnfvIKSoZKfGrFc=;
	b=kirPHtehNW9OGbVChnoV/t+f04OgWMnjCLoPqrMmtMxhjBBVIvUlyHDnnyxPoHr2E2
	0NwK828xF6eQ7BTUOm4izShUuRKQkC7ZiB51jKrYaBEp0XknYpM5g1vGFAXp5ricl/Sq
	dPsz195LUxnG+T70BPHeuuuoQQxge/rGDsKw8=
Received: by 10.180.86.9 with SMTP id l9mr24688936wiz.15.1330368951764;
	Mon, 27 Feb 2012 10:55:51 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id p10sm24183720wic.0.2012.02.27.10.55.49
	(version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 10:55:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 18:55:47 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB718233.2C60D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH DOCDAY] hcall: markup the grant table
	hypercalls to improve generated docs
Thread-Index: Acz1gWpOwHjAOsvTskq+JDo90H7jPA==
In-Reply-To: <da2738f5050d9487313f.1330357568@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the grant table
 hypercalls to improve generated 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 27/02/2012 15:46, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date
> 1330357554 0
# Node ID da2738f5050d9487313f29f4a069a8a2bacb6b55
# Parent
> b6a3a0d68c91ce8fa6023aee3046efd3866942df
hcall: markup the grant table
> hypercalls to improve generated docs

As part of this I looked through the
> relevant chapter from interfaces.tex (from
4.1, deleted in unstable) to ensure
> no critical information was missing.

Signed-off-by: Ian Campbell
> <ian.campbell@citrix.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 Mon Feb 27 18:56:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 18:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S25jy-00062G-3v; Mon, 27 Feb 2012 18:56:06 +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 1S25jw-00062B-LK
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 18:56:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330368890!58414856!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24456 invoked from network); 27 Feb 2012 18:54:50 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 18:54:50 -0000
Received: by wgbdr12 with SMTP id dr12so1918864wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 10:55:58 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.86.9 as permitted sender) client-ip=10.180.86.9; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.86.9 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.86.9])
	by 10.180.86.9 with SMTP id l9mr31082497wiz.15.1330368958565 (num_hops
	= 1); Mon, 27 Feb 2012 10:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tUAf3ZglROwwQnpdIaLkBQgsqL6cMnfvIKSoZKfGrFc=;
	b=kirPHtehNW9OGbVChnoV/t+f04OgWMnjCLoPqrMmtMxhjBBVIvUlyHDnnyxPoHr2E2
	0NwK828xF6eQ7BTUOm4izShUuRKQkC7ZiB51jKrYaBEp0XknYpM5g1vGFAXp5ricl/Sq
	dPsz195LUxnG+T70BPHeuuuoQQxge/rGDsKw8=
Received: by 10.180.86.9 with SMTP id l9mr24688936wiz.15.1330368951764;
	Mon, 27 Feb 2012 10:55:51 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71])
	by mx.google.com with ESMTPS id p10sm24183720wic.0.2012.02.27.10.55.49
	(version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 10:55:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 27 Feb 2012 18:55:47 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB718233.2C60D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH DOCDAY] hcall: markup the grant table
	hypercalls to improve generated docs
Thread-Index: Acz1gWpOwHjAOsvTskq+JDo90H7jPA==
In-Reply-To: <da2738f5050d9487313f.1330357568@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the grant table
 hypercalls to improve generated 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 27/02/2012 15:46, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date
> 1330357554 0
# Node ID da2738f5050d9487313f29f4a069a8a2bacb6b55
# Parent
> b6a3a0d68c91ce8fa6023aee3046efd3866942df
hcall: markup the grant table
> hypercalls to improve generated docs

As part of this I looked through the
> relevant chapter from interfaces.tex (from
4.1, deleted in unstable) to ensure
> no critical information was missing.

Signed-off-by: Ian Campbell
> <ian.campbell@citrix.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 Mon Feb 27 19:04:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S25s3-0006H3-3Z; Mon, 27 Feb 2012 19:04:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1S25s1-0006Gx-VI
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 19:04:26 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1330369458!12701403!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7763 invoked from network); 27 Feb 2012 19:04:19 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 19:04:19 -0000
Received: by bkcjg9 with SMTP id jg9so1423171bkc.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 11:04:18 -0800 (PST)
Received-SPF: pass (google.com: domain of thunderbird2k@gmail.com designates
	10.204.156.219 as permitted sender) client-ip=10.204.156.219; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	thunderbird2k@gmail.com designates 10.204.156.219 as permitted
	sender) smtp.mail=thunderbird2k@gmail.com;
	dkim=pass header.i=thunderbird2k@gmail.com
Received: from mr.google.com ([10.204.156.219])
	by 10.204.156.219 with SMTP id y27mr7421915bkw.110.1330369458367
	(num_hops = 1); Mon, 27 Feb 2012 11:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=FH7kqnuXxYl2A74MPw820OlzkE/8qgrN/EBPcjSq4Lw=;
	b=K+IhAKbu3ta5kdURO6AVOXxQ1boFsbOlJCB15IrHOoWPmTi1AiaSnSKb0nz1aqHzGH
	jlpVwPbYzaX4JWIVGP/L9aafgIBn3b4w9EYwKWMn21XXWIHt0nUqBw5biel3saaaxsdS
	WD96eYGQypZExpsAC9oqTZn+A+NYwVwEP8370=
MIME-Version: 1.0
Received: by 10.204.156.219 with SMTP id y27mr5932385bkw.110.1330369458223;
	Mon, 27 Feb 2012 11:04:18 -0800 (PST)
Received: by 10.204.188.12 with HTTP; Mon, 27 Feb 2012 11:04:18 -0800 (PST)
In-Reply-To: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
	<4F468B96.5030703@cantab.net>
	<CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
Date: Mon, 27 Feb 2012 19:04:18 +0000
Message-ID: <CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Henrik Olsson <henrik@fixme.se>
Cc: David Vrabel <dvrabel@cantab.net>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 5:34 PM, Henrik Olsson <henrik@fixme.se> wrote:
> On Thu, Feb 23, 2012 at 19:55, David Vrabel <dvrabel@cantab.net> wrote:
>> On 22/02/12 22:19, Henrik Olsson wrote:
>>> Hi, i'm having some trouble with assigning memory to my dom0.
>>>
>>> I've added "dom0_mem=3D8192M" to the xen command line yet "free -m"
>>> reports only 5686MB total.
>>
>> [ =A0 =A00.000000] Freeing =A06f000-100000 pfn range: 593920 pages freed
>> [ =A0 =A00.000000] 1-1 mapping on 6f000->100000
>> [ =A0 =A00.000000] Released 595312 pages of unused memory
>>
>> This accounts for most of your "missing" memory. =A0To get it back you
>> need to adjust the balloon driver's target to the amount of memory you w=
ant.
>>
>> David
>
> Hi, i'm not sure i understand..
>
> I've configured /etc/xen/xend-config.sxp with:
> (dom0-min-mem 8192)
> (enable-dom0-ballooning no)
>
> Shouldn't this disable ballooning? Or do i need to pass some parameter
> somewhere?
>
> Regards,
> Henrik
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Make sure you have added the following patch to your Xen if you are
using a recent >=3D3.1 kernel. Unfortunately it isn't in Xen 4.1.x, but
I guess it should be added to there:
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c56dd5eb0fa2

See if it helps.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:04:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S25s3-0006H3-3Z; Mon, 27 Feb 2012 19:04:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1S25s1-0006Gx-VI
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 19:04:26 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1330369458!12701403!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7763 invoked from network); 27 Feb 2012 19:04:19 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 19:04:19 -0000
Received: by bkcjg9 with SMTP id jg9so1423171bkc.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 11:04:18 -0800 (PST)
Received-SPF: pass (google.com: domain of thunderbird2k@gmail.com designates
	10.204.156.219 as permitted sender) client-ip=10.204.156.219; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	thunderbird2k@gmail.com designates 10.204.156.219 as permitted
	sender) smtp.mail=thunderbird2k@gmail.com;
	dkim=pass header.i=thunderbird2k@gmail.com
Received: from mr.google.com ([10.204.156.219])
	by 10.204.156.219 with SMTP id y27mr7421915bkw.110.1330369458367
	(num_hops = 1); Mon, 27 Feb 2012 11:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=FH7kqnuXxYl2A74MPw820OlzkE/8qgrN/EBPcjSq4Lw=;
	b=K+IhAKbu3ta5kdURO6AVOXxQ1boFsbOlJCB15IrHOoWPmTi1AiaSnSKb0nz1aqHzGH
	jlpVwPbYzaX4JWIVGP/L9aafgIBn3b4w9EYwKWMn21XXWIHt0nUqBw5biel3saaaxsdS
	WD96eYGQypZExpsAC9oqTZn+A+NYwVwEP8370=
MIME-Version: 1.0
Received: by 10.204.156.219 with SMTP id y27mr5932385bkw.110.1330369458223;
	Mon, 27 Feb 2012 11:04:18 -0800 (PST)
Received: by 10.204.188.12 with HTTP; Mon, 27 Feb 2012 11:04:18 -0800 (PST)
In-Reply-To: <CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
References: <CAA_XowMLKy0JrcNvV=igA5NC-neTNs6WWZt-deccvG53148WWg@mail.gmail.com>
	<4F468B96.5030703@cantab.net>
	<CAA_XowPntQ1SMgE98aR_DAfdB2YGTwL___Do3TxeH=5uRsp1kw@mail.gmail.com>
Date: Mon, 27 Feb 2012 19:04:18 +0000
Message-ID: <CAEc3jaCyV213dnAO8dfPrr9ov0ab56KEk05MXoMRo9Y0XbLv6A@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Henrik Olsson <henrik@fixme.se>
Cc: David Vrabel <dvrabel@cantab.net>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 not seeing all of the assigned memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 5:34 PM, Henrik Olsson <henrik@fixme.se> wrote:
> On Thu, Feb 23, 2012 at 19:55, David Vrabel <dvrabel@cantab.net> wrote:
>> On 22/02/12 22:19, Henrik Olsson wrote:
>>> Hi, i'm having some trouble with assigning memory to my dom0.
>>>
>>> I've added "dom0_mem=3D8192M" to the xen command line yet "free -m"
>>> reports only 5686MB total.
>>
>> [ =A0 =A00.000000] Freeing =A06f000-100000 pfn range: 593920 pages freed
>> [ =A0 =A00.000000] 1-1 mapping on 6f000->100000
>> [ =A0 =A00.000000] Released 595312 pages of unused memory
>>
>> This accounts for most of your "missing" memory. =A0To get it back you
>> need to adjust the balloon driver's target to the amount of memory you w=
ant.
>>
>> David
>
> Hi, i'm not sure i understand..
>
> I've configured /etc/xen/xend-config.sxp with:
> (dom0-min-mem 8192)
> (enable-dom0-ballooning no)
>
> Shouldn't this disable ballooning? Or do i need to pass some parameter
> somewhere?
>
> Regards,
> Henrik
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Make sure you have added the following patch to your Xen if you are
using a recent >=3D3.1 kernel. Unfortunately it isn't in Xen 4.1.x, but
I guess it should be added to there:
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c56dd5eb0fa2

See if it helps.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:20:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:20:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S266l-0006Tw-HR; Mon, 27 Feb 2012 19:19:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S266j-0006TV-RL
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:19:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330370371!13665966!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9620 invoked from network); 27 Feb 2012 19:19:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:19:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S266a-000Pig-Ms; Mon, 27 Feb 2012 19:19:28 +0000
Date: Mon, 27 Feb 2012 19:19:28 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20120227191928.GA98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
	<4F468D9A.3050000@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F468D9A.3050000@cantab.net>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02 of 10] arm: implement udelay()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:03 +0000 on 23 Feb (1330023834), David Vrabel wrote:
> On 23/02/12 17:40, Tim Deegan wrote:
> > arm: implement udelay()
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> [...]
> > diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/time.c
> > --- a/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> > +++ b/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> > @@ -171,6 +171,16 @@ void __cpuinit init_timer_interrupt(void
> >      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
> >  }
> >  
> > +/* Wait a set number of microseconds */
> > +void udelay(unsigned long usecs)
> > +{
> > +    s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
> > +    do {
> > +        dsb();
> > +        isb();
> 
> What are these barriers for?

To make sure the CPU doesn't hoist any instructions past the wait
loop. :)  They don't really have to be inside the loop body; I can
change that if you like.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:20:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:20:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S266l-0006Tw-HR; Mon, 27 Feb 2012 19:19:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S266j-0006TV-RL
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:19:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330370371!13665966!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9620 invoked from network); 27 Feb 2012 19:19:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:19:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S266a-000Pig-Ms; Mon, 27 Feb 2012 19:19:28 +0000
Date: Mon, 27 Feb 2012 19:19:28 +0000
From: Tim Deegan <tim@xen.org>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20120227191928.GA98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<ec051056db2b6d373446.1330018849@whitby.uk.xensource.com>
	<4F468D9A.3050000@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F468D9A.3050000@cantab.net>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02 of 10] arm: implement udelay()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:03 +0000 on 23 Feb (1330023834), David Vrabel wrote:
> On 23/02/12 17:40, Tim Deegan wrote:
> > arm: implement udelay()
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> [...]
> > diff -r 4a7c14209131 -r ec051056db2b xen/arch/arm/time.c
> > --- a/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> > +++ b/xen/arch/arm/time.c	Thu Feb 23 17:39:59 2012 +0000
> > @@ -171,6 +171,16 @@ void __cpuinit init_timer_interrupt(void
> >      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
> >  }
> >  
> > +/* Wait a set number of microseconds */
> > +void udelay(unsigned long usecs)
> > +{
> > +    s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
> > +    do {
> > +        dsb();
> > +        isb();
> 
> What are these barriers for?

To make sure the CPU doesn't hoist any instructions past the wait
loop. :)  They don't really have to be inside the loop body; I can
change that if you like.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:21:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S267w-0006X3-05; Mon, 27 Feb 2012 19:20:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S267u-0006WY-5I
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:20:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330370443!15170273!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19533 invoked from network); 27 Feb 2012 19:20:43 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:20:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S267n-000PjJ-3e; Mon, 27 Feb 2012 19:20:43 +0000
Date: Mon, 27 Feb 2012 19:20:43 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120227192043.GB98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
	<1330024560.10008.6.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330024560.10008.6.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10] arm: More SMP bringup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:16 +0000 on 23 Feb (1330024560), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> [...]
> > +	/* Signal the next non-boot CPU to come and join us here */
> > +	ldr   r0, =boot_gate         /* VA of gate */
> > +	add   r0, r0, r10            /* PA of gate */
> > +	mov   r1, #0                 /* (0 == unlocked) */
> > +	str   r1, [r0]
> > +	dsb
> > +	isb
> > +	sev
> 
> Here we have released the next CPU from the holding pen...
> 
> [...]
> > +	/* Non-boot CPUs report that they've got this far */
> > +	ldr   r0, =ready_cpus
> > +	ldr   r1, [r0]               /* Read count of ready CPUs */
> > +	add   r1, r1, #1             /* ++ */
> > +	str   r1, [r0]               /* Writeback */
> > +	dsb
> 
> ... and here we do a non-atomic update of a shared variable.
> 
> What prevents the following CPU from catching us up and conflicting
> here?
> 
> Would we be better signalling the next CPU after the increment instead?

Yes, we would.  I'll fix that.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:21:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S267w-0006X3-05; Mon, 27 Feb 2012 19:20:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S267u-0006WY-5I
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:20:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330370443!15170273!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19533 invoked from network); 27 Feb 2012 19:20:43 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:20:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S267n-000PjJ-3e; Mon, 27 Feb 2012 19:20:43 +0000
Date: Mon, 27 Feb 2012 19:20:43 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120227192043.GB98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<1e9c6bd7cc99d1af0107.1330018852@whitby.uk.xensource.com>
	<1330024560.10008.6.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330024560.10008.6.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 10] arm: More SMP bringup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:16 +0000 on 23 Feb (1330024560), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> [...]
> > +	/* Signal the next non-boot CPU to come and join us here */
> > +	ldr   r0, =boot_gate         /* VA of gate */
> > +	add   r0, r0, r10            /* PA of gate */
> > +	mov   r1, #0                 /* (0 == unlocked) */
> > +	str   r1, [r0]
> > +	dsb
> > +	isb
> > +	sev
> 
> Here we have released the next CPU from the holding pen...
> 
> [...]
> > +	/* Non-boot CPUs report that they've got this far */
> > +	ldr   r0, =ready_cpus
> > +	ldr   r1, [r0]               /* Read count of ready CPUs */
> > +	add   r1, r1, #1             /* ++ */
> > +	str   r1, [r0]               /* Writeback */
> > +	dsb
> 
> ... and here we do a non-atomic update of a shared variable.
> 
> What prevents the following CPU from catching us up and conflicting
> here?
> 
> Would we be better signalling the next CPU after the increment instead?

Yes, we would.  I'll fix that.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:27:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26Dr-0006lf-Ps; Mon, 27 Feb 2012 19:26:59 +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 1S26Dp-0006la-IA
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:26:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330370757!51018660!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 917 invoked from network); 27 Feb 2012 19:25:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:25:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26Dk-000Plh-Aj; Mon, 27 Feb 2012 19:26:52 +0000
Date: Mon, 27 Feb 2012 19:26:52 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120227192652.GC98737@ocelot.phlegethon.org>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
	<20120224134544.GA13134@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120224134544.GA13134@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 14:45 +0100 on 24 Feb (1330094744), Olaf Hering wrote:
> >  #ifdef __x86_64__
> > +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> > +         && p2m->domain == current->domain ) 
> > +    {
> > +        if ( locked )
> > +            gfn_unlock(p2m, gfn, 0);
> > +
> > +        /* Ping the pager */
> > +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> > +            p2m_mem_paging_populate(p2m->domain, gfn);
> > +
> > +        /* Wait until the pager finishes paging it in */
> > +        current->arch.mem_paging_gfn = gfn;
> > +        wait_event(current->arch.mem_paging_wq, ({
> > +                    int done;
> > +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> > +                    done = (*t != p2m_ram_paging_in);
> 
> I assume p2m_mem_paging_populate() will not return until the state is
> forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
> more obvious what this check is supposed to do.

But it would be wrong.  If the type anything other than
p2m_ram_paging_in, then we can't be sure that the pager is working on
unblocking us.

Andres made the same suggestion - clearly this code needs a comment. :)

> > +                    /* Safety catch: it _should_ be safe to wait here
> > +                     * but if it's not, crash the VM, not the host */
> > +                    if ( in_atomic() )
> > +                    {
> > +                        WARN();
> > +                        domain_crash(p2m->domain);
> > +                        done = 1;
> > +                    }
> > +                    done;
> > +                }));
> > +        goto again;
> > +    }
> > +#endif

> >  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >  {
> >      struct vcpu *v = current;
> > @@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
> >      p2m_access_t a;
> >      mfn_t mfn;
> >      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    int send_request = 0;
> 
> Is that variable supposed to be used?

Erk.  Clearly something got mangled in the rebase.  I'll sort that out.

> Perhaps the feature to fast-forward (or rollback) from
> p2m_ram_paging_out to p2m_ram_rw could be a separate patch. My initial
> version of this patch did not have a strict requirement for this
> feature, if I remember correctly.

Sure, I can split that into a separate patch.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:27:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26Dr-0006lf-Ps; Mon, 27 Feb 2012 19:26:59 +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 1S26Dp-0006la-IA
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:26:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330370757!51018660!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 917 invoked from network); 27 Feb 2012 19:25:57 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:25:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26Dk-000Plh-Aj; Mon, 27 Feb 2012 19:26:52 +0000
Date: Mon, 27 Feb 2012 19:26:52 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120227192652.GC98737@ocelot.phlegethon.org>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
	<20120224134544.GA13134@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120224134544.GA13134@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 14:45 +0100 on 24 Feb (1330094744), Olaf Hering wrote:
> >  #ifdef __x86_64__
> > +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> > +         && p2m->domain == current->domain ) 
> > +    {
> > +        if ( locked )
> > +            gfn_unlock(p2m, gfn, 0);
> > +
> > +        /* Ping the pager */
> > +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> > +            p2m_mem_paging_populate(p2m->domain, gfn);
> > +
> > +        /* Wait until the pager finishes paging it in */
> > +        current->arch.mem_paging_gfn = gfn;
> > +        wait_event(current->arch.mem_paging_wq, ({
> > +                    int done;
> > +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> > +                    done = (*t != p2m_ram_paging_in);
> 
> I assume p2m_mem_paging_populate() will not return until the state is
> forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
> more obvious what this check is supposed to do.

But it would be wrong.  If the type anything other than
p2m_ram_paging_in, then we can't be sure that the pager is working on
unblocking us.

Andres made the same suggestion - clearly this code needs a comment. :)

> > +                    /* Safety catch: it _should_ be safe to wait here
> > +                     * but if it's not, crash the VM, not the host */
> > +                    if ( in_atomic() )
> > +                    {
> > +                        WARN();
> > +                        domain_crash(p2m->domain);
> > +                        done = 1;
> > +                    }
> > +                    done;
> > +                }));
> > +        goto again;
> > +    }
> > +#endif

> >  void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >  {
> >      struct vcpu *v = current;
> > @@ -965,6 +1001,7 @@ void p2m_mem_paging_populate(struct doma
> >      p2m_access_t a;
> >      mfn_t mfn;
> >      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    int send_request = 0;
> 
> Is that variable supposed to be used?

Erk.  Clearly something got mangled in the rebase.  I'll sort that out.

> Perhaps the feature to fast-forward (or rollback) from
> p2m_ram_paging_out to p2m_ram_rw could be a separate patch. My initial
> version of this patch did not have a strict requirement for this
> feature, if I remember correctly.

Sure, I can split that into a separate patch.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26El-0006oW-7P; Mon, 27 Feb 2012 19:27:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1S26Ej-0006o6-US
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:27:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330370867!16700200!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQwNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20337 invoked from network); 27 Feb 2012 19:27:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 19:27: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 9DEF526F5;
	Mon, 27 Feb 2012 21:27:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 105DD2004A; Mon, 27 Feb 2012 21:27:46 +0200 (EET)
Date: Mon, 27 Feb 2012 21:27:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120227192746.GU12984@reaktio.net>
References: <4F4BCEBE.6010608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4BCEBE.6010608@citrix.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 06:43:10PM +0000, Andrew Cooper wrote:
> Attached is an attempt to document all the Xen command line parameters.
> 
> Because of other tasks, (and choosing to document the rather twisty
> 'acpi' option first), It is far less complete than I was hoping.
> 
> However, I am submitting it so other people may benefit (and contribute)
> going forward.
> 

Related link:
http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options

-- Pasi


> -- 
> 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 Feb 27 19:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26El-0006oW-7P; Mon, 27 Feb 2012 19:27:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1S26Ej-0006o6-US
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:27:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330370867!16700200!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQwNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20337 invoked from network); 27 Feb 2012 19:27:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 19:27: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 9DEF526F5;
	Mon, 27 Feb 2012 21:27:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 105DD2004A; Mon, 27 Feb 2012 21:27:46 +0200 (EET)
Date: Mon, 27 Feb 2012 21:27:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120227192746.GU12984@reaktio.net>
References: <4F4BCEBE.6010608@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F4BCEBE.6010608@citrix.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 06:43:10PM +0000, Andrew Cooper wrote:
> Attached is an attempt to document all the Xen command line parameters.
> 
> Because of other tasks, (and choosing to document the rather twisty
> 'acpi' option first), It is far less complete than I was hoping.
> 
> However, I am submitting it so other people may benefit (and contribute)
> going forward.
> 

Related link:
http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options

-- Pasi


> -- 
> 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 Feb 27 19:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26Ho-00071H-1L; Mon, 27 Feb 2012 19:31:04 +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 1S26Hm-000717-Bt
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:31:02 +0000
Received: from [85.158.139.83:5249] by server-10.bemta-5.messagelabs.com id
	DD/8C-06263-5F9DB4F4; Mon, 27 Feb 2012 19:31:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330371060!5652123!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5749 invoked from network); 27 Feb 2012 19:31:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:31:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26Hk-000Pmw-0F; Mon, 27 Feb 2012 19:31:00 +0000
Date: Mon, 27 Feb 2012 19:30:59 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120227193059.GD98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
	<1330363933.8557.317.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330363933.8557.317.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor
	init out of the per-CPU init 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

At 17:32 +0000 on 27 Feb (1330363933), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1330018799 0
> > # Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
> > # Parent  ec051056db2b6d37344629e2f01d17240099d5ec
> > arm: Move some GIC distributor init out of the per-CPU init function
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
> > --- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > +++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > @@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
> >      for ( i = 32; i < gic.lines; i += 32 )
> >          GICD[GICD_ICENABLER + i / 32] = ~0ul;
> >  
> > -    /* Turn on the distributor */
> > -    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> > -}
> > -
> > -static void __cpuinit gic_cpu_init(void)
> > -{
> > -    int i;
> > -
> >      /* Disable all PPI and enable all SGI */
> >      GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
> >      GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
> 
> PPIs and SGIs are per physical-CPU and therefore, I think, the GICD
> registers of various sorts which refer to the first 32 interrupts are
> per physical-CPU as well. IOW moving these from gic_cpu_init to
> gic_dist_init is wrong?

Yep, you're right ISENABLER0 and ICENABLER0 are banked.  I'll replace
this with a comment explaining 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 Mon Feb 27 19:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26Ho-00071H-1L; Mon, 27 Feb 2012 19:31:04 +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 1S26Hm-000717-Bt
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:31:02 +0000
Received: from [85.158.139.83:5249] by server-10.bemta-5.messagelabs.com id
	DD/8C-06263-5F9DB4F4; Mon, 27 Feb 2012 19:31:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330371060!5652123!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5749 invoked from network); 27 Feb 2012 19:31:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:31:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26Hk-000Pmw-0F; Mon, 27 Feb 2012 19:31:00 +0000
Date: Mon, 27 Feb 2012 19:30:59 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120227193059.GD98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
	<1330363933.8557.317.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330363933.8557.317.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor
	init out of the per-CPU init 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

At 17:32 +0000 on 27 Feb (1330363933), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1330018799 0
> > # Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
> > # Parent  ec051056db2b6d37344629e2f01d17240099d5ec
> > arm: Move some GIC distributor init out of the per-CPU init function
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
> > --- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > +++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > @@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
> >      for ( i = 32; i < gic.lines; i += 32 )
> >          GICD[GICD_ICENABLER + i / 32] = ~0ul;
> >  
> > -    /* Turn on the distributor */
> > -    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> > -}
> > -
> > -static void __cpuinit gic_cpu_init(void)
> > -{
> > -    int i;
> > -
> >      /* Disable all PPI and enable all SGI */
> >      GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
> >      GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
> 
> PPIs and SGIs are per physical-CPU and therefore, I think, the GICD
> registers of various sorts which refer to the first 32 interrupts are
> per physical-CPU as well. IOW moving these from gic_cpu_init to
> gic_dist_init is wrong?

Yep, you're right ISENABLER0 and ICENABLER0 are banked.  I'll replace
this with a comment explaining 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 Mon Feb 27 19:33:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26KN-0007Ah-Jl; Mon, 27 Feb 2012 19:33: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 1S26KM-0007Ab-7n
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:33:42 +0000
Received: from [85.158.139.83:20167] by server-5.bemta-5.messagelabs.com id
	70/9E-13566-59ADB4F4; Mon, 27 Feb 2012 19:33:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330371220!16066602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31322 invoked from network); 27 Feb 2012 19:33:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 19:33:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="10965141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 19:33:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 19:33:39 +0000
Message-ID: <1330371219.10008.34.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Mon, 27 Feb 2012 19:33:39 +0000
In-Reply-To: <20120227180355.GB2023@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 04:27:23PM +0000, Ian Campbell wrote:
> > On Thu, 2012-02-23 at 17:48 +0000, Stefano Stabellini wrote:
> > > 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".
> > 
> > R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> > immediate (which can only target r0..r7).
> 
> This is untrue.  The important instructions, like MOV Rd, Rn can access
> all the regs.  But anyway, there is no such thing as a Thumb-1 kernel,
> so we won't really care.

I did say "mov immediate", which is the one which matters when loading a
constant hypercall number (the common case). AFAIK the "mov Rd, #imm" T1
encoding cannot access all registers.

The "mov rd,rn" form only helps for syscall(2) like functions, which are
unusual, at least for Xen, although as Stefano says, they do exist.

> > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > instructions.
> > 
> > Should we use r7 instead to maximise instruction density for Thumb code?
> 
> The difference seems trivial when put into context, even if you code a
> special Thumb version of the code to maximise density (the Thumb-2 code
> which gets built from assembler in the kernel is very suboptimal in
> size, but there simply isn't a high proportion of asm code in the kernel
> anyway.)  I wouldn't consider the ARM/Thumb differences as an important
> factor when deciding on a register.

OK, that's useful information. thanks.

> One argument for _not_ using r12 for this purpose is that it is then
> harder to put a generic "HVC" function (analogous to the "syscall"
> syscall) out-of-line, since r12 could get destroyed by the call.

For an out of line syscall(2) wouldn't the syscall number either be in a
standard C calling convention argument register or on the stack when the
function was called, since it is just a normal argument at that point?
As you point out it cannot be passed in r12 (and could never be, due to
the clobbering).

The syscall function itself would have to move the arguments and syscall
nr etc around before issuing the syscall.

I think the same is true of a similar hypercall(2)

> If you don't think you will ever care about putting HVC out of line
> though, it may not matter.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:33:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26KN-0007Ah-Jl; Mon, 27 Feb 2012 19:33: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 1S26KM-0007Ab-7n
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:33:42 +0000
Received: from [85.158.139.83:20167] by server-5.bemta-5.messagelabs.com id
	70/9E-13566-59ADB4F4; Mon, 27 Feb 2012 19:33:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330371220!16066602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31322 invoked from network); 27 Feb 2012 19:33:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 19:33:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="10965141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 19:33:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 19:33:39 +0000
Message-ID: <1330371219.10008.34.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Mon, 27 Feb 2012 19:33:39 +0000
In-Reply-To: <20120227180355.GB2023@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 04:27:23PM +0000, Ian Campbell wrote:
> > On Thu, 2012-02-23 at 17:48 +0000, Stefano Stabellini wrote:
> > > 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".
> > 
> > R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> > immediate (which can only target r0..r7).
> 
> This is untrue.  The important instructions, like MOV Rd, Rn can access
> all the regs.  But anyway, there is no such thing as a Thumb-1 kernel,
> so we won't really care.

I did say "mov immediate", which is the one which matters when loading a
constant hypercall number (the common case). AFAIK the "mov Rd, #imm" T1
encoding cannot access all registers.

The "mov rd,rn" form only helps for syscall(2) like functions, which are
unusual, at least for Xen, although as Stefano says, they do exist.

> > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > instructions.
> > 
> > Should we use r7 instead to maximise instruction density for Thumb code?
> 
> The difference seems trivial when put into context, even if you code a
> special Thumb version of the code to maximise density (the Thumb-2 code
> which gets built from assembler in the kernel is very suboptimal in
> size, but there simply isn't a high proportion of asm code in the kernel
> anyway.)  I wouldn't consider the ARM/Thumb differences as an important
> factor when deciding on a register.

OK, that's useful information. thanks.

> One argument for _not_ using r12 for this purpose is that it is then
> harder to put a generic "HVC" function (analogous to the "syscall"
> syscall) out-of-line, since r12 could get destroyed by the call.

For an out of line syscall(2) wouldn't the syscall number either be in a
standard C calling convention argument register or on the stack when the
function was called, since it is just a normal argument at that point?
As you point out it cannot be passed in r12 (and could never be, due to
the clobbering).

The syscall function itself would have to move the arguments and syscall
nr etc around before issuing the syscall.

I think the same is true of a similar hypercall(2)

> If you don't think you will ever care about putting HVC out of line
> though, it may not matter.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26Z4-0007UT-MI; Mon, 27 Feb 2012 19:48:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S26Z3-0007U9-AT
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:48:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330372126!13318599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3413 invoked from network); 27 Feb 2012 19:48:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 19:48:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="10965291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 19:48:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 19:48:46 +0000
Message-ID: <1330372125.10008.47.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Mon, 27 Feb 2012 19:48:45 +0000
In-Reply-To: <20120227175327.GA2023@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120227175327.GA2023@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-27 at 17:53 +0000, Dave Martin wrote:
> On Thu, Feb 23, 2012 at 05:48:22PM +0000, Stefano Stabellini wrote:
> > 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".
> 
> This would be massively simplified if you didn't try to inline the HVC.
> Does it really need to be inline?
>
> > +#define __HYPERCALL ".word 0xe1400070 + " __HVC_IMM(XEN_HYPERCALL_TAG)
> 
> Please, do not do this.  It won't work in Thumb, where the encodings are
> different.
> 
> It is reasonable to expect anyone building Xen to have reasonably new
> tools, you you can justifiably use
> 
> AFLAGS_thisfile.o := -Wa,-march=armv7-a+virt
> 
> in the Makefile and just use the hvc instruction directly.

Our aim is for guest kernel binaries not to be specific to Xen -- i.e.
they should be able to run on baremetal and other hypervisors as well.
The differences should only be in the device-tree passed to the kernel.

> Of course, this is only practical if the HVC invocation is not inlined.

I suppose we could make the stub functions out of line, we just copied
what Xen does on x86.

The only thing which springs to mind is that 5 argument hypercalls will
end up pushing the fifth argument to the stack only to pop it back into
r4 for the hypercall and IIRC it also needs to preserve r4 (callee saved
reg) which is going to involve some small amount of code to move stuff
around too.

So by inlining the functions we avoid some thunking because the compiler
would know exactly what was happening at the hypercall site.

We don't currently have any 6 argument hypercalls but the same would
extend there.

> If we can't avoid macro-ising HVC, we should do it globally, not locally
> to the Xen code.  That way we at least keep all the horror in one place.

That sounds like a good idea to me.

Given that Stefano is proposing to make the ISS a (per-hypervisor)
constant we could consider just defining the Thumb and non-Thumb
constants instead of doing all the construction with the __HVC_IMM stuff
-- that would remove a big bit of the macroization.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19: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 1S26Z4-0007UT-MI; Mon, 27 Feb 2012 19:48:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S26Z3-0007U9-AT
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:48:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330372126!13318599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTMyMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3413 invoked from network); 27 Feb 2012 19:48:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 19:48:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,492,1325462400"; d="scan'208";a="10965291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 19:48:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 27 Feb 2012 19:48:46 +0000
Message-ID: <1330372125.10008.47.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Mon, 27 Feb 2012 19:48:45 +0000
In-Reply-To: <20120227175327.GA2023@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120227175327.GA2023@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-27 at 17:53 +0000, Dave Martin wrote:
> On Thu, Feb 23, 2012 at 05:48:22PM +0000, Stefano Stabellini wrote:
> > 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".
> 
> This would be massively simplified if you didn't try to inline the HVC.
> Does it really need to be inline?
>
> > +#define __HYPERCALL ".word 0xe1400070 + " __HVC_IMM(XEN_HYPERCALL_TAG)
> 
> Please, do not do this.  It won't work in Thumb, where the encodings are
> different.
> 
> It is reasonable to expect anyone building Xen to have reasonably new
> tools, you you can justifiably use
> 
> AFLAGS_thisfile.o := -Wa,-march=armv7-a+virt
> 
> in the Makefile and just use the hvc instruction directly.

Our aim is for guest kernel binaries not to be specific to Xen -- i.e.
they should be able to run on baremetal and other hypervisors as well.
The differences should only be in the device-tree passed to the kernel.

> Of course, this is only practical if the HVC invocation is not inlined.

I suppose we could make the stub functions out of line, we just copied
what Xen does on x86.

The only thing which springs to mind is that 5 argument hypercalls will
end up pushing the fifth argument to the stack only to pop it back into
r4 for the hypercall and IIRC it also needs to preserve r4 (callee saved
reg) which is going to involve some small amount of code to move stuff
around too.

So by inlining the functions we avoid some thunking because the compiler
would know exactly what was happening at the hypercall site.

We don't currently have any 6 argument hypercalls but the same would
extend there.

> If we can't avoid macro-ising HVC, we should do it globally, not locally
> to the Xen code.  That way we at least keep all the horror in one place.

That sounds like a good idea to me.

Given that Stefano is proposing to make the ISS a (per-hypervisor)
constant we could consider just defining the Thumb and non-Thumb
constants instead of doing all the construction with the __HVC_IMM stuff
-- that would remove a big bit of the macroization.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:51:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:51:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26ba-0007h4-7y; Mon, 27 Feb 2012 19:51:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S26bY-0007gW-0e
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:51:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330372281!16380850!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28000 invoked from network); 27 Feb 2012 19:51:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:51:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26bL-000Pqr-Hp; Mon, 27 Feb 2012 19:51:15 +0000
Date: Mon, 27 Feb 2012 19:51:15 +0000
From: Tim Deegan <tim@xen.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120227195115.GE98737@ocelot.phlegethon.org>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f8264e57-9326-4794-8025-db8ff0f07380@default>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> 1) How is the capability and implementation similar or different
> from VMware's?  And specifically I'm asking for hard information
> relating to:
> 
> http://lwn.net/Articles/309155/ 
> http://lwn.net/Articles/330589/ 
> 
> I am not a lawyer and my employer forbids me from reading the
> related patent claims or speculating on any related issues, but
> I will be strongly recommending a thorough legal review before
> Oracle ships this code in any form that customers can enable.
> (I'm hoping for an answer that would render a review moot.)

I am not a lawyer and my employer forbids me from reading the
related patent claims or speculating on any related issues. :P

> 2) Assuming no legal issues, how is Xen memory overcommit different
> or better than VMware's, which is known to have lots of issues
> in the real world, such that few customers (outside of a handful
> of domains such as VDI) enable it?  Or is this effort largely to
> remove an item from the VMware sales team's differentiation list?
> And a comparison vs Hyper-V and KVM would be interesting also.

The blktap-based page-sharing tool doesn't use content hashes to find
pages to share; it relies on storage-layer knowledge to detect disk
reads that will have identical results.  Grzegorz's PhD dissertation and
the paper on Satori discuss why that's a better idea than trying to find
shareable pages by scanning.

I agree that using page sharing to try to recover memory for higher VM
density is, let's say, challenging.  But in certain specific workloads
(e.g. snowflock &c), or if you're doing something else with the
recovered memory (e.g. tmem?) then it makes more sense.

I have no direct experience of real-world deployments.

> 3) Is there new evidence that a host-based-policy-driven memory
> balancer works sufficiently well on one system, or for
> multiple hosts, or for a data center? 

That, I think, is an open research question.

> It would be nice for
> all Xen developers/vendors to understand the intended customer
> (e.g. is it the desktop user running a handful of VMs running
> known workloads?)

With my hypervisor hat on, we've tried to make a sensible interface
where all the policy-related decisions that this question would apply to
can be made in the tools.  (I realise that I'm totally punting on the
question).

> Perhaps this would be a better topic for the Xen Hack-a-thon...
> sadly I won't be there and, anyway, I don't know if there will
> be a quorum present of the Xen developers specifically working
> on memory overcommit technology, so I thought it should be
> brought up on-list beforehand.

I won't be at the hackathon either.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:51:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:51:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26ba-0007h4-7y; Mon, 27 Feb 2012 19:51:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S26bY-0007gW-0e
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:51:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330372281!16380850!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28000 invoked from network); 27 Feb 2012 19:51:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:51:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26bL-000Pqr-Hp; Mon, 27 Feb 2012 19:51:15 +0000
Date: Mon, 27 Feb 2012 19:51:15 +0000
From: Tim Deegan <tim@xen.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120227195115.GE98737@ocelot.phlegethon.org>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f8264e57-9326-4794-8025-db8ff0f07380@default>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> 1) How is the capability and implementation similar or different
> from VMware's?  And specifically I'm asking for hard information
> relating to:
> 
> http://lwn.net/Articles/309155/ 
> http://lwn.net/Articles/330589/ 
> 
> I am not a lawyer and my employer forbids me from reading the
> related patent claims or speculating on any related issues, but
> I will be strongly recommending a thorough legal review before
> Oracle ships this code in any form that customers can enable.
> (I'm hoping for an answer that would render a review moot.)

I am not a lawyer and my employer forbids me from reading the
related patent claims or speculating on any related issues. :P

> 2) Assuming no legal issues, how is Xen memory overcommit different
> or better than VMware's, which is known to have lots of issues
> in the real world, such that few customers (outside of a handful
> of domains such as VDI) enable it?  Or is this effort largely to
> remove an item from the VMware sales team's differentiation list?
> And a comparison vs Hyper-V and KVM would be interesting also.

The blktap-based page-sharing tool doesn't use content hashes to find
pages to share; it relies on storage-layer knowledge to detect disk
reads that will have identical results.  Grzegorz's PhD dissertation and
the paper on Satori discuss why that's a better idea than trying to find
shareable pages by scanning.

I agree that using page sharing to try to recover memory for higher VM
density is, let's say, challenging.  But in certain specific workloads
(e.g. snowflock &c), or if you're doing something else with the
recovered memory (e.g. tmem?) then it makes more sense.

I have no direct experience of real-world deployments.

> 3) Is there new evidence that a host-based-policy-driven memory
> balancer works sufficiently well on one system, or for
> multiple hosts, or for a data center? 

That, I think, is an open research question.

> It would be nice for
> all Xen developers/vendors to understand the intended customer
> (e.g. is it the desktop user running a handful of VMs running
> known workloads?)

With my hypervisor hat on, we've tried to make a sensible interface
where all the policy-related decisions that this question would apply to
can be made in the tools.  (I realise that I'm totally punting on the
question).

> Perhaps this would be a better topic for the Xen Hack-a-thon...
> sadly I won't be there and, anyway, I don't know if there will
> be a quorum present of the Xen developers specifically working
> on memory overcommit technology, so I thought it should be
> brought up on-list beforehand.

I won't be at the hackathon either.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26ee-0007th-R8; Mon, 27 Feb 2012 19:54:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S26ed-0007tG-FT
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:54:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330372472!3896061!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31712 invoked from network); 27 Feb 2012 19:54:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:54:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26eW-000PrY-9u; Mon, 27 Feb 2012 19:54:32 +0000
Date: Mon, 27 Feb 2012 19:54:32 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120227195432.GF98737@ocelot.phlegethon.org>
References: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove obsolete
	XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:05 +0100 on 26 Feb (1330268705), Olaf Hering wrote:
> diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
>  #define XENMEM_paging_op_nominate           0
>  #define XENMEM_paging_op_evict              1
>  #define XENMEM_paging_op_prep               2
> -#define XENMEM_paging_op_resume             3

Acked, except for this part - we should leave a gravestone here so
we don't reuse the number.  Anyone using the old interface should get an
explicit ENOSYS error.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 19:54:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 19:54:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26ee-0007th-R8; Mon, 27 Feb 2012 19:54:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S26ed-0007tG-FT
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 19:54:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330372472!3896061!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31712 invoked from network); 27 Feb 2012 19:54:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 19:54:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S26eW-000PrY-9u; Mon, 27 Feb 2012 19:54:32 +0000
Date: Mon, 27 Feb 2012 19:54:32 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120227195432.GF98737@ocelot.phlegethon.org>
References: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove obsolete
	XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:05 +0100 on 26 Feb (1330268705), Olaf Hering wrote:
> diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
>  #define XENMEM_paging_op_nominate           0
>  #define XENMEM_paging_op_evict              1
>  #define XENMEM_paging_op_prep               2
> -#define XENMEM_paging_op_resume             3

Acked, except for this part - we should leave a gravestone here so
we don't reuse the number.  Anyone using the old interface should get an
explicit ENOSYS error.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:11:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26ut-0008GM-Dc; Mon, 27 Feb 2012 20:11:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S26us-0008GH-6H
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:11:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330373477!3855708!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM1NTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM1NTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5613 invoked from network); 27 Feb 2012 20:11:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 20:11:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330373474; l=759;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7EqXnS/4VBLHFEcPhRVK1JuX93g=;
	b=Y00T83K5vp2ZYSk6xobZuW17mVgxVgK2tFSuCVgdKp6SNm83Frz2oY2skfWINirSF46
	IE4Le5DEo6mT5NoAn8SJfgoyKLC0OKnwGikegeTErd2kn1eGCFrvuilu92O1JrPagIz7+
	/Ff+xlOqsORcRQxrXudxLsQvBrI9I2oaA8A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by smtp.strato.de (jimi mo5) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y025f6o1RI94BM ;
	Mon, 27 Feb 2012 21:11:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C8FFA18638; Mon, 27 Feb 2012 21:11:00 +0100 (CET)
Date: Mon, 27 Feb 2012 21:11:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120227201100.GA6158@aepfle.de>
References: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
	<20120227195432.GF98737@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120227195432.GF98737@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove obsolete
 XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, Tim Deegan wrote:

> At 15:05 +0100 on 26 Feb (1330268705), Olaf Hering wrote:
> > diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
> >  #define XENMEM_paging_op_nominate           0
> >  #define XENMEM_paging_op_evict              1
> >  #define XENMEM_paging_op_prep               2
> > -#define XENMEM_paging_op_resume             3
> 
> Acked, except for this part - we should leave a gravestone here so
> we don't reuse the number.  Anyone using the old interface should get an
> explicit ENOSYS error.

There can be no old user. xen-4.1 did not have this interface and
XENMEM_paging_* is just a 17 days old.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:11:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:11:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26ut-0008GM-Dc; Mon, 27 Feb 2012 20:11:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S26us-0008GH-6H
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:11:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330373477!3855708!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM1NTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM1NTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5613 invoked from network); 27 Feb 2012 20:11:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 20:11:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330373474; l=759;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7EqXnS/4VBLHFEcPhRVK1JuX93g=;
	b=Y00T83K5vp2ZYSk6xobZuW17mVgxVgK2tFSuCVgdKp6SNm83Frz2oY2skfWINirSF46
	IE4Le5DEo6mT5NoAn8SJfgoyKLC0OKnwGikegeTErd2kn1eGCFrvuilu92O1JrPagIz7+
	/Ff+xlOqsORcRQxrXudxLsQvBrI9I2oaA8A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by smtp.strato.de (jimi mo5) (RZmta 27.7 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y025f6o1RI94BM ;
	Mon, 27 Feb 2012 21:11:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C8FFA18638; Mon, 27 Feb 2012 21:11:00 +0100 (CET)
Date: Mon, 27 Feb 2012 21:11:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120227201100.GA6158@aepfle.de>
References: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
	<20120227195432.GF98737@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120227195432.GF98737@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove obsolete
 XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, Tim Deegan wrote:

> At 15:05 +0100 on 26 Feb (1330268705), Olaf Hering wrote:
> > diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
> >  #define XENMEM_paging_op_nominate           0
> >  #define XENMEM_paging_op_evict              1
> >  #define XENMEM_paging_op_prep               2
> > -#define XENMEM_paging_op_resume             3
> 
> Acked, except for this part - we should leave a gravestone here so
> we don't reuse the number.  Anyone using the old interface should get an
> explicit ENOSYS error.

There can be no old user. xen-4.1 did not have this interface and
XENMEM_paging_* is just a 17 days old.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26xX-0008MP-Va; Mon, 27 Feb 2012 20:14: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 1S26xV-0008MH-M1
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:14:09 +0000
Received: from [85.158.139.83:49721] by server-11.bemta-5.messagelabs.com id
	12/35-14397-014EB4F4; Mon, 27 Feb 2012 20:14:08 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330373646!16283996!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY5ODc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17670 invoked from network); 27 Feb 2012 20:14:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 20:14: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 q1RKE4xt032292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 20:14: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
	q1RKE3Y1018896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 20:14:03 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
	q1RKE24U025648; Mon, 27 Feb 2012 14:14:02 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 27 Feb 2012 12:14:02 -0800
Date: Mon, 27 Feb 2012 12:14:01 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120227121401.096bd19d@mantra.us.oracle.com>
In-Reply-To: <CB6E72DB.2C43B%keir.xen@gmail.com>
References: <1330163951764-5514885.post@n5.nabble.com>
	<CB6E72DB.2C43B%keir.xen@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F4BE40C.00C4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, "Liu.yi" <liu.yi24@zte.com.cn>
Subject: Re: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2012 11:13:31 +0000
Keir Fraser <keir.xen@gmail.com> wrote:

> > Is there any optimization ways to deal with x86_64's system call?
> 
> Run PV guest in an HVM container, which provides sufficient
> protection to allow us to have guest applications syscall directly
> into guest OS. Mukes Rathor at Oracle (cc'ed) is working on this.
> 
>  -- Keir
 
Yup, with domU hybrid (PV in HVM container), we got expected results. 
dom0 hybrid coming soon, currently debugging some ept violation.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:14:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S26xX-0008MP-Va; Mon, 27 Feb 2012 20:14: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 1S26xV-0008MH-M1
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:14:09 +0000
Received: from [85.158.139.83:49721] by server-11.bemta-5.messagelabs.com id
	12/35-14397-014EB4F4; Mon, 27 Feb 2012 20:14:08 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330373646!16283996!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY5ODc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17670 invoked from network); 27 Feb 2012 20:14:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2012 20:14: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 q1RKE4xt032292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 20:14: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
	q1RKE3Y1018896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 20:14:03 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
	q1RKE24U025648; Mon, 27 Feb 2012 14:14:02 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 27 Feb 2012 12:14:02 -0800
Date: Mon, 27 Feb 2012 12:14:01 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120227121401.096bd19d@mantra.us.oracle.com>
In-Reply-To: <CB6E72DB.2C43B%keir.xen@gmail.com>
References: <1330163951764-5514885.post@n5.nabble.com>
	<CB6E72DB.2C43B%keir.xen@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F4BE40C.00C4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, "Liu.yi" <liu.yi24@zte.com.cn>
Subject: Re: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2012 11:13:31 +0000
Keir Fraser <keir.xen@gmail.com> wrote:

> > Is there any optimization ways to deal with x86_64's system call?
> 
> Run PV guest in an HVM container, which provides sufficient
> protection to allow us to have guest applications syscall directly
> into guest OS. Mukes Rathor at Oracle (cc'ed) is working on this.
> 
>  -- Keir
 
Yup, with domU hybrid (PV in HVM container), we got expected results. 
dom0 hybrid coming soon, currently debugging some ept violation.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:18:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:18:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S271q-00007S-Li; Mon, 27 Feb 2012 20:18:38 +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 1S271p-00007J-Kx
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:18:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330373881!58547207!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24891 invoked from network); 27 Feb 2012 20:18:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Feb 2012 20:18:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330373913; l=1501;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=bWg9X7Tz1084QIrA0ctfwDuZ2ys=;
	b=BJfwU7sGCvy5ZIGeNJU8ArcFTCu82PM38gyoFr+4oyekFRVAx30vas8ImQd4I99Jj98
	11p5EmioeB2Khj8SPCyvtgEjYG5h8IlfmW4N2stUO6XQBlmUE7pNj7XeEXx6r/x6rkfV4
	V4v579SMCjbHcaRucl54To9NFDt2b2j9p+I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by post.strato.de (mrclete mo18) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5050f8o1RJadzW ;
	Mon, 27 Feb 2012 21:18:26 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B636718638; Mon, 27 Feb 2012 21:18:23 +0100 (CET)
Date: Mon, 27 Feb 2012 21:18:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120227201823.GB6158@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
	<20120224134544.GA13134@aepfle.de>
	<20120227192652.GC98737@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120227192652.GC98737@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, Tim Deegan wrote:

> At 14:45 +0100 on 24 Feb (1330094744), Olaf Hering wrote:
> > >  #ifdef __x86_64__
> > > +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> > > +         && p2m->domain == current->domain ) 
> > > +    {
> > > +        if ( locked )
> > > +            gfn_unlock(p2m, gfn, 0);
> > > +
> > > +        /* Ping the pager */
> > > +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> > > +            p2m_mem_paging_populate(p2m->domain, gfn);
> > > +
> > > +        /* Wait until the pager finishes paging it in */
> > > +        current->arch.mem_paging_gfn = gfn;
> > > +        wait_event(current->arch.mem_paging_wq, ({
> > > +                    int done;
> > > +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> > > +                    done = (*t != p2m_ram_paging_in);
> > 
> > I assume p2m_mem_paging_populate() will not return until the state is
> > forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
> > more obvious what this check is supposed to do.
> 
> But it would be wrong.  If the type anything other than
> p2m_ram_paging_in, then we can't be sure that the pager is working on
> unblocking us.

Not really wrong. I think it depends what will happen to the p2mt once
it leaves the paging state and once the condition in wait_event() is
executed again. Now I see what its supposed to mean, it enters
wait_event() with p2m_ram_paging_in and it is supposed to leave once the
type changed to something else. It works because the page-in path has
now only one p2mt, not two like a few weeks ago.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:18:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:18:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S271q-00007S-Li; Mon, 27 Feb 2012 20:18:38 +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 1S271p-00007J-Kx
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:18:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330373881!58547207!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24891 invoked from network); 27 Feb 2012 20:18:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Feb 2012 20:18:01 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330373913; l=1501;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=bWg9X7Tz1084QIrA0ctfwDuZ2ys=;
	b=BJfwU7sGCvy5ZIGeNJU8ArcFTCu82PM38gyoFr+4oyekFRVAx30vas8ImQd4I99Jj98
	11p5EmioeB2Khj8SPCyvtgEjYG5h8IlfmW4N2stUO6XQBlmUE7pNj7XeEXx6r/x6rkfV4
	V4v579SMCjbHcaRucl54To9NFDt2b2j9p+I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV7qE=
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-4.vodafone-net.de [80.226.24.4])
	by post.strato.de (mrclete mo18) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5050f8o1RJadzW ;
	Mon, 27 Feb 2012 21:18:26 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B636718638; Mon, 27 Feb 2012 21:18:23 +0100 (CET)
Date: Mon, 27 Feb 2012 21:18:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120227201823.GB6158@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<510d80343793227bd39b.1330014867@whitby.uk.xensource.com>
	<20120224134544.GA13134@aepfle.de>
	<20120227192652.GC98737@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120227192652.GC98737@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for
	mem_paging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, Tim Deegan wrote:

> At 14:45 +0100 on 24 Feb (1330094744), Olaf Hering wrote:
> > >  #ifdef __x86_64__
> > > +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> > > +         && p2m->domain == current->domain ) 
> > > +    {
> > > +        if ( locked )
> > > +            gfn_unlock(p2m, gfn, 0);
> > > +
> > > +        /* Ping the pager */
> > > +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> > > +            p2m_mem_paging_populate(p2m->domain, gfn);
> > > +
> > > +        /* Wait until the pager finishes paging it in */
> > > +        current->arch.mem_paging_gfn = gfn;
> > > +        wait_event(current->arch.mem_paging_wq, ({
> > > +                    int done;
> > > +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> > > +                    done = (*t != p2m_ram_paging_in);
> > 
> > I assume p2m_mem_paging_populate() will not return until the state is
> > forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
> > more obvious what this check is supposed to do.
> 
> But it would be wrong.  If the type anything other than
> p2m_ram_paging_in, then we can't be sure that the pager is working on
> unblocking us.

Not really wrong. I think it depends what will happen to the p2mt once
it leaves the paging state and once the condition in wait_event() is
executed again. Now I see what its supposed to mean, it enters
wait_event() with p2m_ram_paging_in and it is supposed to leave once the
type changed to something else. It works because the page-in path has
now only one p2mt, not two like a few weeks ago.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:54:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S27a0-0000h9-JM; Mon, 27 Feb 2012 20:53:56 +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 1S27Zz-0000h3-8f
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:53:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330376009!65331681!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23664 invoked from network); 27 Feb 2012 20:53:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 20:53:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S27Zx-00006m-MO; Mon, 27 Feb 2012 20:53:53 +0000
Date: Mon, 27 Feb 2012 20:53:53 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120227205353.GH98737@ocelot.phlegethon.org>
References: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
	<20120227195432.GF98737@ocelot.phlegethon.org>
	<20120227201100.GA6158@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120227201100.GA6158@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove obsolete
	XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:11 +0100 on 27 Feb (1330377060), Olaf Hering wrote:
> On Mon, Feb 27, Tim Deegan wrote:
> 
> > At 15:05 +0100 on 26 Feb (1330268705), Olaf Hering wrote:
> > > diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
> > > --- a/xen/include/public/memory.h
> > > +++ b/xen/include/public/memory.h
> > > @@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
> > >  #define XENMEM_paging_op_nominate           0
> > >  #define XENMEM_paging_op_evict              1
> > >  #define XENMEM_paging_op_prep               2
> > > -#define XENMEM_paging_op_resume             3
> > 
> > Acked, except for this part - we should leave a gravestone here so
> > we don't reuse the number.  Anyone using the old interface should get an
> > explicit ENOSYS error.
> 
> There can be no old user. xen-4.1 did not have this interface and
> XENMEM_paging_* is just a 17 days old.

Fair enough. :)  Ack.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 20:54:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 20:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S27a0-0000h9-JM; Mon, 27 Feb 2012 20:53:56 +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 1S27Zz-0000h3-8f
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 20:53:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330376009!65331681!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23664 invoked from network); 27 Feb 2012 20:53:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2012 20:53:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S27Zx-00006m-MO; Mon, 27 Feb 2012 20:53:53 +0000
Date: Mon, 27 Feb 2012 20:53:53 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120227205353.GH98737@ocelot.phlegethon.org>
References: <3ace34b89ebe3bdd6afb.1330265105@probook.site>
	<20120227195432.GF98737@ocelot.phlegethon.org>
	<20120227201100.GA6158@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120227201100.GA6158@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: remove obsolete
	XENMEM_paging_op_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:11 +0100 on 27 Feb (1330377060), Olaf Hering wrote:
> On Mon, Feb 27, Tim Deegan wrote:
> 
> > At 15:05 +0100 on 26 Feb (1330268705), Olaf Hering wrote:
> > > diff -r 6fb2fee7c183 -r 3ace34b89ebe xen/include/public/memory.h
> > > --- a/xen/include/public/memory.h
> > > +++ b/xen/include/public/memory.h
> > > @@ -322,7 +322,6 @@ typedef struct xen_pod_target xen_pod_ta
> > >  #define XENMEM_paging_op_nominate           0
> > >  #define XENMEM_paging_op_evict              1
> > >  #define XENMEM_paging_op_prep               2
> > > -#define XENMEM_paging_op_resume             3
> > 
> > Acked, except for this part - we should leave a gravestone here so
> > we don't reuse the number.  Anyone using the old interface should get an
> > explicit ENOSYS error.
> 
> There can be no old user. xen-4.1 did not have this interface and
> XENMEM_paging_* is just a 17 days old.

Fair enough. :)  Ack.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 21:05:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 21:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S27kz-0000uG-Nc; Mon, 27 Feb 2012 21:05:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1S27ky-0000u8-Cc
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 21:05:16 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330376708!16708810!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10626 invoked from network); 27 Feb 2012 21:05:10 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 21:05:10 -0000
Received: by qcsp15 with SMTP id p15so15192193qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 13:05:08 -0800 (PST)
Received-SPF: pass (google.com: domain of peter.maydell@linaro.org designates
	10.224.185.207 as permitted sender) client-ip=10.224.185.207; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	peter.maydell@linaro.org designates 10.224.185.207 as permitted
	sender) smtp.mail=peter.maydell@linaro.org
Received: from mr.google.com ([10.224.185.207])
	by 10.224.185.207 with SMTP id cp15mr12728400qab.72.1330376708527
	(num_hops = 1); Mon, 27 Feb 2012 13:05:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.185.207 with SMTP id cp15mr10707880qab.72.1330376708428;
	Mon, 27 Feb 2012 13:05:08 -0800 (PST)
Received: by 10.229.50.85 with HTTP; Mon, 27 Feb 2012 13:05:08 -0800 (PST)
In-Reply-To: <1330360043.8557.302.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 21:05:08 +0000
Message-ID: <CAFEAcA8PzT9mfnEz60CYvwQWX1OEvejrZvkpuPL2LpTPosp8cA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQlFpn7cqOfHqx7Nhq/M3UJPchUH9hgt87NrUlD+VpucpIjN6I+FtQ2U/LETnRb8cb9QPQDz
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27 February 2012 16:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> immediate (which can only target r0..r7).
>
> Since we support only ARMv7+ there are "T2" and "T3" encodings available
> which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> instructions.
>
> Should we use r7 instead to maximise instruction density for Thumb code?

r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
makes it worth avoiding in this context.

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 21:05:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 21:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S27kz-0000uG-Nc; Mon, 27 Feb 2012 21:05:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1S27ky-0000u8-Cc
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 21:05:16 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330376708!16708810!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10626 invoked from network); 27 Feb 2012 21:05:10 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 21:05:10 -0000
Received: by qcsp15 with SMTP id p15so15192193qcs.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 13:05:08 -0800 (PST)
Received-SPF: pass (google.com: domain of peter.maydell@linaro.org designates
	10.224.185.207 as permitted sender) client-ip=10.224.185.207; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	peter.maydell@linaro.org designates 10.224.185.207 as permitted
	sender) smtp.mail=peter.maydell@linaro.org
Received: from mr.google.com ([10.224.185.207])
	by 10.224.185.207 with SMTP id cp15mr12728400qab.72.1330376708527
	(num_hops = 1); Mon, 27 Feb 2012 13:05:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.185.207 with SMTP id cp15mr10707880qab.72.1330376708428;
	Mon, 27 Feb 2012 13:05:08 -0800 (PST)
Received: by 10.229.50.85 with HTTP; Mon, 27 Feb 2012 13:05:08 -0800 (PST)
In-Reply-To: <1330360043.8557.302.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
Date: Mon, 27 Feb 2012 21:05:08 +0000
Message-ID: <CAFEAcA8PzT9mfnEz60CYvwQWX1OEvejrZvkpuPL2LpTPosp8cA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQlFpn7cqOfHqx7Nhq/M3UJPchUH9hgt87NrUlD+VpucpIjN6I+FtQ2U/LETnRb8cb9QPQDz
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27 February 2012 16:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> immediate (which can only target r0..r7).
>
> Since we support only ARMv7+ there are "T2" and "T3" encodings available
> which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> instructions.
>
> Should we use r7 instead to maximise instruction density for Thumb code?

r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
makes it worth avoiding in this context.

-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 21:21:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 21: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 1S27zp-00014a-6J; Mon, 27 Feb 2012 21:20:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S27zn-00014U-I7
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 21:20:35 +0000
Received: from [85.158.139.83:3161] by server-9.bemta-5.messagelabs.com id
	A8/FD-05451-2A3FB4F4; Mon, 27 Feb 2012 21:20:34 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330377633!16385195!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7344 invoked from network); 27 Feb 2012 21:20:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 21:20:33 -0000
Received: by bkcjg9 with SMTP id jg9so1594843bkc.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 13:20:33 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.112.28.74 as permitted sender) client-ip=10.112.28.74; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.112.28.74 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.112.28.74])
	by 10.112.28.74 with SMTP id z10mr844772lbg.14.1330377633381 (num_hops
	= 1); Mon, 27 Feb 2012 13:20:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=dNq6Dgw93vG84n0W/8h38hy5xbWooa5zQfA9V2ZyMiE=;
	b=g4dxmZXGNPZaomC4WCp2Vr4ioVmObLydnWqT5z1eWlC8nCCPmnkMjVlkQ194d0BEIL
	4cp+o5H7BMVG7Pn/Vt0mbMP5DS+NNc5OlfiC/nSeWegDlcdOKf7S7ViZivSa2f7RFGN3
	8lBmCDpTLzQbWRVIH47x7N9PhAq6iOnBo1bC0=
Received: by 10.112.28.74 with SMTP id z10mr690346lbg.14.1330377633294; Mon,
	27 Feb 2012 13:20:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Mon, 27 Feb 2012 13:20:13 -0800 (PST)
In-Reply-To: <20120223173617.GA19213@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Mon, 27 Feb 2012 13:20:13 -0800
Message-ID: <CAFw--Dd=xFnWMn6nN_YAaJ7YgkmV6ggfbuRNLZFYTSFpj-Bp1g@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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: multipart/mixed; boundary="===============2117433026110874506=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2117433026110874506==
Content-Type: multipart/alternative; boundary=bcaec554db9e3febc204b9f8aeac

--bcaec554db9e3febc204b9f8aeac
Content-Type: text/plain; charset=ISO-8859-1

All,

I was attempting to perform a 'make dist' and installing from the 'dist'
onto another machine. It looks like the last line of the install.sh script
in the dist folder wants to check the prerequisites from the 'check'
directory. I wanted to ask what the dist install methodology is with the
autoconf configuration. I can give a hand, just wanted to check if people
were working on this and what the thoughts were.

###/dist/install.sh
cd $src/../check
./chk install
echo "All done."


On Thu, Feb 23, 2012 at 9:36 AM, Olaf Hering <olaf@aepfle.de> wrote:

> On Tue, Feb 21, Roger Pau Monne wrote:
>
> > -${PYTHON} -c '
> > -import sys
> > -sys.exit(sys.version_info[0] < 2 or sys.version_info[1] < 3)
> > -' || fail "need python version >= 2.3"
>
> > +`$PYTHON -c 'import sys; exit(eval("sys.version_info < ($1, $2)"))'`
>
>
> Old python can not handle that new syntax:
>
>  $ python
> Python 2.4.2 (#1, Feb 16 2011, 12:49:02)
> [GCC 4.1.2 20070115 (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> exit(eval("sys.version_info < (2, 3)"))
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
> TypeError: 'str' object is not callable
> >>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--bcaec554db9e3febc204b9f8aeac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,<br><br>I was attempting to perform a &#39;make dist&#39; and installin=
g from the &#39;dist&#39; onto another machine. It looks like the last line=
 of the install.sh script in the dist folder wants to check the prerequisit=
es from the &#39;check&#39; directory. I wanted to ask what the dist instal=
l methodology is with the autoconf configuration. I can give a hand, just w=
anted to check if people were working on this and what the thoughts were.<b=
r>

<br>###/dist/install.sh<br>cd $src/../check<br>./chk install<br>echo &quot;=
All done.&quot;<br><br><br><div class=3D"gmail_quote">On Thu, Feb 23, 2012 =
at 9:36 AM, Olaf Hering <span dir=3D"ltr">&lt;<a href=3D"mailto:olaf@aepfle=
.de">olaf@aepfle.de</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, Feb 21, Roger Pau =
Monne wrote:<br>
<br>
</div>&gt; -${PYTHON} -c &#39;<br>
&gt; -import sys<br>
&gt; -sys.exit(sys.version_info[0] &lt; 2 or sys.version_info[1] &lt; 3)<br=
>
&gt; -&#39; || fail &quot;need python version &gt;=3D 2.3&quot;<br>
<br>
&gt; +`$PYTHON -c &#39;import sys; exit(eval(&quot;sys.version_info &lt; ($=
1, $2)&quot;))&#39;`<br>
<br>
<br>
Old python can not handle that new syntax:<br>
<br>
=A0$ python<br>
Python 2.4.2 (#1, Feb 16 2011, 12:49:02)<br>
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2<br>
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;=
license&quot; for more information.<br>
&gt;&gt;&gt; import sys<br>
&gt;&gt;&gt; exit(eval(&quot;sys.version_info &lt; (2, 3)&quot;))<br>
Traceback (most recent call last):<br>
 =A0File &quot;&lt;stdin&gt;&quot;, line 1, in ?<br>
TypeError: &#39;str&#39; object is not callable<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt;&gt;&gt;<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>

--bcaec554db9e3febc204b9f8aeac--


--===============2117433026110874506==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2117433026110874506==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 21:21:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 21: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 1S27zp-00014a-6J; Mon, 27 Feb 2012 21:20:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S27zn-00014U-I7
	for xen-devel@lists.xen.org; Mon, 27 Feb 2012 21:20:35 +0000
Received: from [85.158.139.83:3161] by server-9.bemta-5.messagelabs.com id
	A8/FD-05451-2A3FB4F4; Mon, 27 Feb 2012 21:20:34 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330377633!16385195!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7344 invoked from network); 27 Feb 2012 21:20:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 21:20:33 -0000
Received: by bkcjg9 with SMTP id jg9so1594843bkc.32
	for <xen-devel@lists.xen.org>; Mon, 27 Feb 2012 13:20:33 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.112.28.74 as permitted sender) client-ip=10.112.28.74; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.112.28.74 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.112.28.74])
	by 10.112.28.74 with SMTP id z10mr844772lbg.14.1330377633381 (num_hops
	= 1); Mon, 27 Feb 2012 13:20:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=dNq6Dgw93vG84n0W/8h38hy5xbWooa5zQfA9V2ZyMiE=;
	b=g4dxmZXGNPZaomC4WCp2Vr4ioVmObLydnWqT5z1eWlC8nCCPmnkMjVlkQ194d0BEIL
	4cp+o5H7BMVG7Pn/Vt0mbMP5DS+NNc5OlfiC/nSeWegDlcdOKf7S7ViZivSa2f7RFGN3
	8lBmCDpTLzQbWRVIH47x7N9PhAq6iOnBo1bC0=
Received: by 10.112.28.74 with SMTP id z10mr690346lbg.14.1330377633294; Mon,
	27 Feb 2012 13:20:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Mon, 27 Feb 2012 13:20:13 -0800 (PST)
In-Reply-To: <20120223173617.GA19213@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Mon, 27 Feb 2012 13:20:13 -0800
Message-ID: <CAFw--Dd=xFnWMn6nN_YAaJ7YgkmV6ggfbuRNLZFYTSFpj-Bp1g@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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: multipart/mixed; boundary="===============2117433026110874506=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2117433026110874506==
Content-Type: multipart/alternative; boundary=bcaec554db9e3febc204b9f8aeac

--bcaec554db9e3febc204b9f8aeac
Content-Type: text/plain; charset=ISO-8859-1

All,

I was attempting to perform a 'make dist' and installing from the 'dist'
onto another machine. It looks like the last line of the install.sh script
in the dist folder wants to check the prerequisites from the 'check'
directory. I wanted to ask what the dist install methodology is with the
autoconf configuration. I can give a hand, just wanted to check if people
were working on this and what the thoughts were.

###/dist/install.sh
cd $src/../check
./chk install
echo "All done."


On Thu, Feb 23, 2012 at 9:36 AM, Olaf Hering <olaf@aepfle.de> wrote:

> On Tue, Feb 21, Roger Pau Monne wrote:
>
> > -${PYTHON} -c '
> > -import sys
> > -sys.exit(sys.version_info[0] < 2 or sys.version_info[1] < 3)
> > -' || fail "need python version >= 2.3"
>
> > +`$PYTHON -c 'import sys; exit(eval("sys.version_info < ($1, $2)"))'`
>
>
> Old python can not handle that new syntax:
>
>  $ python
> Python 2.4.2 (#1, Feb 16 2011, 12:49:02)
> [GCC 4.1.2 20070115 (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> exit(eval("sys.version_info < (2, 3)"))
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
> TypeError: 'str' object is not callable
> >>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--bcaec554db9e3febc204b9f8aeac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

All,<br><br>I was attempting to perform a &#39;make dist&#39; and installin=
g from the &#39;dist&#39; onto another machine. It looks like the last line=
 of the install.sh script in the dist folder wants to check the prerequisit=
es from the &#39;check&#39; directory. I wanted to ask what the dist instal=
l methodology is with the autoconf configuration. I can give a hand, just w=
anted to check if people were working on this and what the thoughts were.<b=
r>

<br>###/dist/install.sh<br>cd $src/../check<br>./chk install<br>echo &quot;=
All done.&quot;<br><br><br><div class=3D"gmail_quote">On Thu, Feb 23, 2012 =
at 9:36 AM, Olaf Hering <span dir=3D"ltr">&lt;<a href=3D"mailto:olaf@aepfle=
.de">olaf@aepfle.de</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, Feb 21, Roger Pau =
Monne wrote:<br>
<br>
</div>&gt; -${PYTHON} -c &#39;<br>
&gt; -import sys<br>
&gt; -sys.exit(sys.version_info[0] &lt; 2 or sys.version_info[1] &lt; 3)<br=
>
&gt; -&#39; || fail &quot;need python version &gt;=3D 2.3&quot;<br>
<br>
&gt; +`$PYTHON -c &#39;import sys; exit(eval(&quot;sys.version_info &lt; ($=
1, $2)&quot;))&#39;`<br>
<br>
<br>
Old python can not handle that new syntax:<br>
<br>
=A0$ python<br>
Python 2.4.2 (#1, Feb 16 2011, 12:49:02)<br>
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2<br>
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;=
license&quot; for more information.<br>
&gt;&gt;&gt; import sys<br>
&gt;&gt;&gt; exit(eval(&quot;sys.version_info &lt; (2, 3)&quot;))<br>
Traceback (most recent call last):<br>
 =A0File &quot;&lt;stdin&gt;&quot;, line 1, in ?<br>
TypeError: &#39;str&#39; object is not callable<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt;&gt;&gt;<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>

--bcaec554db9e3febc204b9f8aeac--


--===============2117433026110874506==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2117433026110874506==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 22:41:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 22: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 1S29FU-0001t3-DI; Mon, 27 Feb 2012 22:40:52 +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 1S29FS-0001sy-TY
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 22:40:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330382407!54273681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18715 invoked from network); 27 Feb 2012 22:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 22:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,493,1325462400"; d="scan'208";a="10967603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 22:40:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 22:40:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S29FQ-0000aP-BT;
	Mon, 27 Feb 2012 22:40:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S29FQ-0000h0-8t;
	Mon, 27 Feb 2012 22:40:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12092-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 27 Feb 2012 22:40:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12092: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12092 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12092/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-win         7 windows-install             fail pass in 12088
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12088 pass in 12092

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12088 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12088 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 22:41:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 22: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 1S29FU-0001t3-DI; Mon, 27 Feb 2012 22:40:52 +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 1S29FS-0001sy-TY
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 22:40:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330382407!54273681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18715 invoked from network); 27 Feb 2012 22:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 22:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,493,1325462400"; d="scan'208";a="10967603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2012 22:40:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 27 Feb 2012 22:40:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S29FQ-0000aP-BT;
	Mon, 27 Feb 2012 22:40:48 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S29FQ-0000h0-8t;
	Mon, 27 Feb 2012 22:40:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12092-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 27 Feb 2012 22:40:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12092: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12092 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12092/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-win         7 windows-install             fail pass in 12088
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 12088 pass in 12092

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail like 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2 fail in 12088 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 12088 never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 22:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 22:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S29I0-0001yK-Ui; Mon, 27 Feb 2012 22:43:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S29Hz-0001yB-LG
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 22:43:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330382601!16639642!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcxMzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8343 invoked from network); 27 Feb 2012 22:43:21 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-6.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 22:43:21 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 9EB894B008F;
	Mon, 27 Feb 2012 14:43:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=r8K1sJBU0CXQyxmxi5yhQB6ZXv7aH3IING8WHsg2/Fx/
	tAPQomEHMybrgTwlptObMVKCNO0UJXpdFu5H5aEraGMKTfnLwJWATtqo4bblUUbs
	Nss+8PHAxGU0Wd5KK1LwOogcndAitqaYaZRjwWJyQ282WAADPzCLnYcGgPANBfg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=S3AA36bBXKSDuIiOQrHElX3KG/g=; b=ZLrGq4tQ
	JH7S9EEp64p23xcHsgwVIU+K5U4wyhfVY96XKT2qvmzak521waPfxlVRvT82QtS5
	6NjWhSweQdJV78kfFc3VSoXP453F5PGxVVhvcw6H5zY2hJd+Z+jJzY63okFyzOZR
	cotugBwGTpFGTV64d8bzG6iVRyY9f83pSIs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 255154B0089; 
	Mon, 27 Feb 2012 14:43:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 27 Feb 2012 14:43:20 -0800
Message-ID: <77a82566e2a5c2a1e33be231486ac132.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120223160755.GI25694@ocelot.phlegethon.org>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<20120223160755.GI25694@ocelot.phlegethon.org>
Date: Mon, 27 Feb 2012 14:43:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: ian.campbell@citrix.com,
 ian.jackson@citrix.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	Tim Deegan <tim@xen.org>, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 7] Mem event ring setup interface update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 01:05 -0500 on 23 Feb (1329959105), Andres Lagar-Cavilla wrote:
>> Update the interface for setting up mem event rings (for sharing, mem
>> access or
>> paging).
>>
>> Remove the "shared page", which was a waste of a whole page for a single
>> event
>> channel port value.
>>
>> More importantly, both the shared page and the ring page were dom0
>> user-space
>> process pages mapped by the hypervisor. If the dom0 process does not
>> clean up,
>> the hypervisor keeps posting events (and holding a map) to a page now
>> belonging
>> to another process.
>>
>> Solutions proposed:
>> - Pass the event channel port explicitly as part of the domctl payload.
>> - Reserve a pfn in the guest physmap for a each mem event ring.
>> Set/retrieve
>> these pfns via hvm params. Ensure they are set during build and restore,
>> and
>> retrieved during save. Ensure these pages don't leak and domains are
>> left zombie.
>>
>> In all cases mem events consumers in-tree (xenpaging and xen-access)
>> have been
>> updated.
>>
>> Updating the interface to deal with these problems requires
>> backwards-incompatible changes on both the helper<->libxc and
>> libxc<->hypervisor interfaces.
> 5A>
>> Take advantage of the interface update to plumb setting up of the
>> sharing ring,
>> which was missing.
>>
>> All patches touch x86/mm hypervisor bits. Patches 1, 3 and 5 are tools
>> patches
>> as well.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> For the Xen parts:
> Acked-by: Tim Deegan <tim@xen.org>

Ping, on the tools side. Also note the Acked-by from Olaf.
Thanks,
Andres

>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 22:44:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 22:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S29I0-0001yK-Ui; Mon, 27 Feb 2012 22:43:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S29Hz-0001yB-LG
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 22:43:27 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330382601!16639642!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcxMzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8343 invoked from network); 27 Feb 2012 22:43:21 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-6.tower-216.messagelabs.com with SMTP;
	27 Feb 2012 22:43:21 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 9EB894B008F;
	Mon, 27 Feb 2012 14:43:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=r8K1sJBU0CXQyxmxi5yhQB6ZXv7aH3IING8WHsg2/Fx/
	tAPQomEHMybrgTwlptObMVKCNO0UJXpdFu5H5aEraGMKTfnLwJWATtqo4bblUUbs
	Nss+8PHAxGU0Wd5KK1LwOogcndAitqaYaZRjwWJyQ282WAADPzCLnYcGgPANBfg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=S3AA36bBXKSDuIiOQrHElX3KG/g=; b=ZLrGq4tQ
	JH7S9EEp64p23xcHsgwVIU+K5U4wyhfVY96XKT2qvmzak521waPfxlVRvT82QtS5
	6NjWhSweQdJV78kfFc3VSoXP453F5PGxVVhvcw6H5zY2hJd+Z+jJzY63okFyzOZR
	cotugBwGTpFGTV64d8bzG6iVRyY9f83pSIs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 255154B0089; 
	Mon, 27 Feb 2012 14:43:20 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 27 Feb 2012 14:43:20 -0800
Message-ID: <77a82566e2a5c2a1e33be231486ac132.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120223160755.GI25694@ocelot.phlegethon.org>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<20120223160755.GI25694@ocelot.phlegethon.org>
Date: Mon, 27 Feb 2012 14:43:20 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: ian.campbell@citrix.com,
 ian.jackson@citrix.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	Tim Deegan <tim@xen.org>, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 7] Mem event ring setup interface update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> At 01:05 -0500 on 23 Feb (1329959105), Andres Lagar-Cavilla wrote:
>> Update the interface for setting up mem event rings (for sharing, mem
>> access or
>> paging).
>>
>> Remove the "shared page", which was a waste of a whole page for a single
>> event
>> channel port value.
>>
>> More importantly, both the shared page and the ring page were dom0
>> user-space
>> process pages mapped by the hypervisor. If the dom0 process does not
>> clean up,
>> the hypervisor keeps posting events (and holding a map) to a page now
>> belonging
>> to another process.
>>
>> Solutions proposed:
>> - Pass the event channel port explicitly as part of the domctl payload.
>> - Reserve a pfn in the guest physmap for a each mem event ring.
>> Set/retrieve
>> these pfns via hvm params. Ensure they are set during build and restore,
>> and
>> retrieved during save. Ensure these pages don't leak and domains are
>> left zombie.
>>
>> In all cases mem events consumers in-tree (xenpaging and xen-access)
>> have been
>> updated.
>>
>> Updating the interface to deal with these problems requires
>> backwards-incompatible changes on both the helper<->libxc and
>> libxc<->hypervisor interfaces.
> 5A>
>> Take advantage of the interface update to plumb setting up of the
>> sharing ring,
>> which was missing.
>>
>> All patches touch x86/mm hypervisor bits. Patches 1, 3 and 5 are tools
>> patches
>> as well.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> For the Xen parts:
> Acked-by: Tim Deegan <tim@xen.org>

Ping, on the tools side. Also note the Acked-by from Olaf.
Thanks,
Andres

>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 23:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23: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 1S29rL-0002IV-1T; Mon, 27 Feb 2012 23:19:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S29rJ-0002IP-17
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:19:57 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330384789!10040874!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32606 invoked from network); 27 Feb 2012 23:19:49 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 23:19:49 -0000
Received: by lagr15 with SMTP id r15so5431785lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 15:19:48 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.112.40.72 as permitted sender) client-ip=10.112.40.72; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.112.40.72 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.112.40.72])
	by 10.112.40.72 with SMTP id v8mr6807636lbk.49.1330384788478 (num_hops
	= 1); Mon, 27 Feb 2012 15:19:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=ODnySnryaVAj2XYuEbg60S1bw3JNhd6XY46eP3eCwjs=;
	b=cDw5SRBu7AuOaQYkxNKTwj/dk0bemdA6HwW1acb0RE3Ag/UDIKXZIJXA1FQa6j6rDF
	4ZgzDtDwVZwsTIJPZ/6po99VZtwMeqgj0bAC7aY2YRs+5kh2ZYl9gNKfQ1Tob+l7tgh+
	S6yoMRYksFwPSQOxUfRIzvU0A3GhVvROHaiUY=
Received: by 10.112.40.72 with SMTP id v8mr5704084lbk.49.1330384788318; Mon,
	27 Feb 2012 15:19:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Mon, 27 Feb 2012 15:19:28 -0800 (PST)
In-Reply-To: <CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Mon, 27 Feb 2012 15:19:28 -0800
Message-ID: <CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2211291426785941375=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2211291426785941375==
Content-Type: multipart/alternative; boundary=e0cb4efe2d58b8ea8904b9fa5821

--e0cb4efe2d58b8ea8904b9fa5821
Content-Type: text/plain; charset=ISO-8859-1

System: Centos 6.1, xen-unstable (4.2), x86_64

Hello all,

I was just wondering what the "correct" way is to go about this. I have a
x86_64 centos system that has all of the libs going to /usr/lib and not
/usr/lib64. It sounds like we want to keep everything in /usr/lib on
purpose. Is that correct?

Jeff

On Sun, Oct 23, 2011 at 10:52 PM, AP <apxeng@gmail.com> wrote:

> On Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
> > On Fri, 2011-10-21 at 04:52 +0100, AP wrote:
> >> On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>
> wrote:
> >> > Ian Campbell writes ("Re: [Xen-devel] make install not creating lib
> entries in /> It might be nice if there was a single variable which could
> be set to
> >> >> control this behaviour, or even better if it can be automatically
> >> >> detected. I'm also inclined to suggest that the default should be to
> >> >> use /usr/lib and leave the lib64 thing as a RH special case, but then
> >> >> I'm a Debian user so I would think that ;-)
> >> >
> >> > At the very least we ought not to dump things in /usr/lib64 unless it
> >> > already exists and is distinct from /usr/lib.
> >>
> >> I deleted my /usr/lib64 and did a "make install-tools
> >> PYTHON_PREFIX_ARG=". At the end a /usr/lib64 directory was created
> >> with Xen related libraries inside.
> >
> > I think you need to reread my earlier reply -- I explained what is going
> > on and provided an example of the sort of patch which fixes it. There is
> > no reason to expect that deleting /usr/lib64 will change anything.
>
> Sorry, I misunderstood Ian Jackson's comment. It made me think
> deleting /usr/lib64 might change something :) I now understand the
> point he was trying to make and your fix. Thanks for the help.
>
> > Ian.
> >
> >>
> >> > We should think about multiarch too at some point.
> >> >
> >> > Ian.
> >> >
> >
> >
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--e0cb4efe2d58b8ea8904b9fa5821
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

System: Centos 6.1, xen-unstable (4.2), x86_64<br><br>Hello all,<br><br>I w=
as just wondering what the &quot;correct&quot; way is to go about this. I h=
ave a x86_64 centos system that has all of the libs going to /usr/lib and n=
ot /usr/lib64. It sounds like we want to keep everything in /usr/lib on pur=
pose. Is that correct?<br>

<br>Jeff<br><br><div class=3D"gmail_quote">On Sun, Oct 23, 2011 at 10:52 PM=
, AP <span dir=3D"ltr">&lt;<a href=3D"mailto:apxeng@gmail.com">apxeng@gmail=
.com</a>&gt;</span> wrote:<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 Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell &lt;<a href=
=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<=
br>
&gt; On Fri, 2011-10-21 at 04:52 +0100, AP wrote:<br>
&gt;&gt; On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson &lt;<a href=3D"mailto=
:Ian.Jackson@eu.citrix.com">Ian.Jackson@eu.citrix.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Ian Campbell writes (&quot;Re: [Xen-devel] make install not c=
reating lib entries in /&gt; It might be nice if there was a single variabl=
e which could be set to<br>
&gt;&gt; &gt;&gt; control this behaviour, or even better if it can be autom=
atically<br>
&gt;&gt; &gt;&gt; detected. I&#39;m also inclined to suggest that the defau=
lt should be to<br>
&gt;&gt; &gt;&gt; use /usr/lib and leave the lib64 thing as a RH special ca=
se, but then<br>
&gt;&gt; &gt;&gt; I&#39;m a Debian user so I would think that ;-)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; At the very least we ought not to dump things in /usr/lib64 u=
nless it<br>
&gt;&gt; &gt; already exists and is distinct from /usr/lib.<br>
&gt;&gt;<br>
&gt;&gt; I deleted my /usr/lib64 and did a &quot;make install-tools<br>
&gt;&gt; PYTHON_PREFIX_ARG=3D&quot;. At the end a /usr/lib64 directory was =
created<br>
&gt;&gt; with Xen related libraries inside.<br>
&gt;<br>
&gt; I think you need to reread my earlier reply -- I explained what is goi=
ng<br>
&gt; on and provided an example of the sort of patch which fixes it. There =
is<br>
&gt; no reason to expect that deleting /usr/lib64 will change anything.<br>
<br>
</div>Sorry, I misunderstood Ian Jackson&#39;s comment. It made me think<br=
>
deleting /usr/lib64 might change something :) I now understand the<br>
point he was trying to make and your fix. Thanks for the help.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; Ian.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; We should think about multiarch too at some point.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Ian.<br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--e0cb4efe2d58b8ea8904b9fa5821--


--===============2211291426785941375==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2211291426785941375==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 23:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23: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 1S29rL-0002IV-1T; Mon, 27 Feb 2012 23:19:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S29rJ-0002IP-17
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:19:57 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330384789!10040874!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32606 invoked from network); 27 Feb 2012 23:19:49 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 23:19:49 -0000
Received: by lagr15 with SMTP id r15so5431785lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 15:19:48 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.112.40.72 as permitted sender) client-ip=10.112.40.72; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.112.40.72 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.112.40.72])
	by 10.112.40.72 with SMTP id v8mr6807636lbk.49.1330384788478 (num_hops
	= 1); Mon, 27 Feb 2012 15:19:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=ODnySnryaVAj2XYuEbg60S1bw3JNhd6XY46eP3eCwjs=;
	b=cDw5SRBu7AuOaQYkxNKTwj/dk0bemdA6HwW1acb0RE3Ag/UDIKXZIJXA1FQa6j6rDF
	4ZgzDtDwVZwsTIJPZ/6po99VZtwMeqgj0bAC7aY2YRs+5kh2ZYl9gNKfQ1Tob+l7tgh+
	S6yoMRYksFwPSQOxUfRIzvU0A3GhVvROHaiUY=
Received: by 10.112.40.72 with SMTP id v8mr5704084lbk.49.1330384788318; Mon,
	27 Feb 2012 15:19:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Mon, 27 Feb 2012 15:19:28 -0800 (PST)
In-Reply-To: <CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Mon, 27 Feb 2012 15:19:28 -0800
Message-ID: <CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2211291426785941375=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2211291426785941375==
Content-Type: multipart/alternative; boundary=e0cb4efe2d58b8ea8904b9fa5821

--e0cb4efe2d58b8ea8904b9fa5821
Content-Type: text/plain; charset=ISO-8859-1

System: Centos 6.1, xen-unstable (4.2), x86_64

Hello all,

I was just wondering what the "correct" way is to go about this. I have a
x86_64 centos system that has all of the libs going to /usr/lib and not
/usr/lib64. It sounds like we want to keep everything in /usr/lib on
purpose. Is that correct?

Jeff

On Sun, Oct 23, 2011 at 10:52 PM, AP <apxeng@gmail.com> wrote:

> On Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
> > On Fri, 2011-10-21 at 04:52 +0100, AP wrote:
> >> On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>
> wrote:
> >> > Ian Campbell writes ("Re: [Xen-devel] make install not creating lib
> entries in /> It might be nice if there was a single variable which could
> be set to
> >> >> control this behaviour, or even better if it can be automatically
> >> >> detected. I'm also inclined to suggest that the default should be to
> >> >> use /usr/lib and leave the lib64 thing as a RH special case, but then
> >> >> I'm a Debian user so I would think that ;-)
> >> >
> >> > At the very least we ought not to dump things in /usr/lib64 unless it
> >> > already exists and is distinct from /usr/lib.
> >>
> >> I deleted my /usr/lib64 and did a "make install-tools
> >> PYTHON_PREFIX_ARG=". At the end a /usr/lib64 directory was created
> >> with Xen related libraries inside.
> >
> > I think you need to reread my earlier reply -- I explained what is going
> > on and provided an example of the sort of patch which fixes it. There is
> > no reason to expect that deleting /usr/lib64 will change anything.
>
> Sorry, I misunderstood Ian Jackson's comment. It made me think
> deleting /usr/lib64 might change something :) I now understand the
> point he was trying to make and your fix. Thanks for the help.
>
> > Ian.
> >
> >>
> >> > We should think about multiarch too at some point.
> >> >
> >> > Ian.
> >> >
> >
> >
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--e0cb4efe2d58b8ea8904b9fa5821
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

System: Centos 6.1, xen-unstable (4.2), x86_64<br><br>Hello all,<br><br>I w=
as just wondering what the &quot;correct&quot; way is to go about this. I h=
ave a x86_64 centos system that has all of the libs going to /usr/lib and n=
ot /usr/lib64. It sounds like we want to keep everything in /usr/lib on pur=
pose. Is that correct?<br>

<br>Jeff<br><br><div class=3D"gmail_quote">On Sun, Oct 23, 2011 at 10:52 PM=
, AP <span dir=3D"ltr">&lt;<a href=3D"mailto:apxeng@gmail.com">apxeng@gmail=
.com</a>&gt;</span> wrote:<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 Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell &lt;<a href=
=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<=
br>
&gt; On Fri, 2011-10-21 at 04:52 +0100, AP wrote:<br>
&gt;&gt; On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson &lt;<a href=3D"mailto=
:Ian.Jackson@eu.citrix.com">Ian.Jackson@eu.citrix.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Ian Campbell writes (&quot;Re: [Xen-devel] make install not c=
reating lib entries in /&gt; It might be nice if there was a single variabl=
e which could be set to<br>
&gt;&gt; &gt;&gt; control this behaviour, or even better if it can be autom=
atically<br>
&gt;&gt; &gt;&gt; detected. I&#39;m also inclined to suggest that the defau=
lt should be to<br>
&gt;&gt; &gt;&gt; use /usr/lib and leave the lib64 thing as a RH special ca=
se, but then<br>
&gt;&gt; &gt;&gt; I&#39;m a Debian user so I would think that ;-)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; At the very least we ought not to dump things in /usr/lib64 u=
nless it<br>
&gt;&gt; &gt; already exists and is distinct from /usr/lib.<br>
&gt;&gt;<br>
&gt;&gt; I deleted my /usr/lib64 and did a &quot;make install-tools<br>
&gt;&gt; PYTHON_PREFIX_ARG=3D&quot;. At the end a /usr/lib64 directory was =
created<br>
&gt;&gt; with Xen related libraries inside.<br>
&gt;<br>
&gt; I think you need to reread my earlier reply -- I explained what is goi=
ng<br>
&gt; on and provided an example of the sort of patch which fixes it. There =
is<br>
&gt; no reason to expect that deleting /usr/lib64 will change anything.<br>
<br>
</div>Sorry, I misunderstood Ian Jackson&#39;s comment. It made me think<br=
>
deleting /usr/lib64 might change something :) I now understand the<br>
point he was trying to make and your fix. Thanks for the help.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; Ian.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; We should think about multiarch too at some point.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Ian.<br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>

--e0cb4efe2d58b8ea8904b9fa5821--


--===============2211291426785941375==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2211291426785941375==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 23:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ABr-0002Vd-3V; Mon, 27 Feb 2012 23:41:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2ABq-0002VY-B9
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:41:10 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330386062!3873569!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3MTAyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3760 invoked from network); 27 Feb 2012 23:41:03 -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; 27 Feb 2012 23:41:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1RNeuw6006829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 23:40: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
	q1RNestB011556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 23:40:55 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
	q1RNerAu026275; Mon, 27 Feb 2012 17:40:53 -0600
MIME-Version: 1.0
Message-ID: <104d17ef-192d-4a13-9d19-b27a58f04384@default>
Date: Mon, 27 Feb 2012 15:40:39 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
In-Reply-To: <20120224214228.GA23473@aepfle.de>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4F4C1489.0089,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]

Hi Olaf --

Thanks for the reply!  Since Tim answers my questions later in the
thread, one quick comment...

> To me memory overcommit means swapping, which is what xenpaging does:
> turn the whole guest gfn range into some sort of virtual memory,
> transparent to the guest.
> 
> xenpaging is the red emergency knob to free some host memory without
> caring about the actual memory constraints within the paged guests.

Sure, but the whole point of increasing RAM in one or more guests
is to increase performance, and if overcommitting *always* means
swapping, why would anyone use it?

So xenpaging is fine and useful, but IMHO only in conjunction
with some other technology that reduces total physical RAM usage
to less than sum(max_mem(all VMs)).

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 23:41:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ABr-0002Vd-3V; Mon, 27 Feb 2012 23:41:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2ABq-0002VY-B9
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:41:10 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330386062!3873569!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3MTAyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3760 invoked from network); 27 Feb 2012 23:41:03 -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; 27 Feb 2012 23:41:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1RNeuw6006829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 23:40: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
	q1RNestB011556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 23:40:55 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
	q1RNerAu026275; Mon, 27 Feb 2012 17:40:53 -0600
MIME-Version: 1.0
Message-ID: <104d17ef-192d-4a13-9d19-b27a58f04384@default>
Date: Mon, 27 Feb 2012 15:40:39 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
In-Reply-To: <20120224214228.GA23473@aepfle.de>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4F4C1489.0089,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]

Hi Olaf --

Thanks for the reply!  Since Tim answers my questions later in the
thread, one quick comment...

> To me memory overcommit means swapping, which is what xenpaging does:
> turn the whole guest gfn range into some sort of virtual memory,
> transparent to the guest.
> 
> xenpaging is the red emergency knob to free some host memory without
> caring about the actual memory constraints within the paged guests.

Sure, but the whole point of increasing RAM in one or more guests
is to increase performance, and if overcommitting *always* means
swapping, why would anyone use it?

So xenpaging is fine and useful, but IMHO only in conjunction
with some other technology that reduces total physical RAM usage
to less than sum(max_mem(all VMs)).

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 23:47:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2AHG-0002ep-Rj; Mon, 27 Feb 2012 23:46:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2AHE-0002ei-WB
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:46:45 +0000
Received: from [85.158.139.83:59123] by server-1.bemta-5.messagelabs.com id
	55/BA-28458-4E51C4F4; Mon, 27 Feb 2012 23:46:44 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330386402!16940602!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16099 invoked from network); 27 Feb 2012 23:46:43 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 23:46:43 -0000
Received: by lagr15 with SMTP id r15so5461187lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 15:46:42 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.152.130.234 as permitted sender) client-ip=10.152.130.234; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.152.130.234 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.152.130.234])
	by 10.152.130.234 with SMTP id oh10mr14794710lab.35.1330386402410
	(num_hops = 1); Mon, 27 Feb 2012 15:46:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=kKTabTutZ4WFIKVA3zLIgV0Hu14vuhpMjrivYfdMaEM=;
	b=McZN1PCydvri5mUrtqRsopvENxN7BrCUGYEiLG1pUJJo1effjorsZ1lSIo2cQZDveg
	CPAlk+sJnNp9FIVpafVoy93MOZKX1C7Dtj1eH1zLzifB3vZTBvaQW7sj6pL+YDLQ7fNE
	I59JfZ2tUfR3qlj9hZKhGOHDlHz4RudZT/zc4=
Received: by 10.152.130.234 with SMTP id oh10mr12310175lab.35.1330386402318;
	Mon, 27 Feb 2012 15:46:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Mon, 27 Feb 2012 15:46:22 -0800 (PST)
In-Reply-To: <CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Mon, 27 Feb 2012 15:46:22 -0800
Message-ID: <CAFw--Dd8_K=Y=XcFyMKb61=E2kTANy1TjAshETLYKKXCMjtbPQ@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7759724610795859902=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7759724610795859902==
Content-Type: multipart/alternative; boundary=f46d042c5ec7ec97d804b9fab8b8

--f46d042c5ec7ec97d804b9fab8b8
Content-Type: text/plain; charset=ISO-8859-1

In re-reading my last message by itself (without reading the referenced
thread) it sounds rather confusing. What I meant to say was that upon
running a 'make install' or 'make dist' on my Centos x86_64 machine, I find
that all of the libraries (except python2.6)  find their way into the
/usr/lib directory rather than the /usr/lib64 directory. Is this the
intended outcome?

On Mon, Feb 27, 2012 at 3:19 PM, Jeffrey Karrels <karrelsj@gmail.com> wrote:

> System: Centos 6.1, xen-unstable (4.2), x86_64
>
> Hello all,
>
> I was just wondering what the "correct" way is to go about this. I have a
> x86_64 centos system that has all of the libs going to /usr/lib and not
> /usr/lib64. It sounds like we want to keep everything in /usr/lib on
> purpose. Is that correct?
>
> Jeff
>
>
> On Sun, Oct 23, 2011 at 10:52 PM, AP <apxeng@gmail.com> wrote:
>
>> On Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell <Ian.Campbell@citrix.com>
>> wrote:
>> > On Fri, 2011-10-21 at 04:52 +0100, AP wrote:
>> >> On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson <
>> Ian.Jackson@eu.citrix.com> wrote:
>> >> > Ian Campbell writes ("Re: [Xen-devel] make install not creating lib
>> entries in /> It might be nice if there was a single variable which could
>> be set to
>> >> >> control this behaviour, or even better if it can be automatically
>> >> >> detected. I'm also inclined to suggest that the default should be to
>> >> >> use /usr/lib and leave the lib64 thing as a RH special case, but
>> then
>> >> >> I'm a Debian user so I would think that ;-)
>> >> >
>> >> > At the very least we ought not to dump things in /usr/lib64 unless it
>> >> > already exists and is distinct from /usr/lib.
>> >>
>> >> I deleted my /usr/lib64 and did a "make install-tools
>> >> PYTHON_PREFIX_ARG=". At the end a /usr/lib64 directory was created
>> >> with Xen related libraries inside.
>> >
>> > I think you need to reread my earlier reply -- I explained what is going
>> > on and provided an example of the sort of patch which fixes it. There is
>> > no reason to expect that deleting /usr/lib64 will change anything.
>>
>> Sorry, I misunderstood Ian Jackson's comment. It made me think
>> deleting /usr/lib64 might change something :) I now understand the
>> point he was trying to make and your fix. Thanks for the help.
>>
>> > Ian.
>> >
>> >>
>> >> > We should think about multiarch too at some point.
>> >> >
>> >> > Ian.
>> >> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>

--f46d042c5ec7ec97d804b9fab8b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In re-reading my last message by itself (without reading the referenced thr=
ead) it sounds rather confusing. What I meant to say was that upon running =
a &#39;make install&#39; or &#39;make dist&#39; on my Centos x86_64 machine=
, I find that all of the libraries (except python2.6)=A0 find their way int=
o the /usr/lib directory rather than the /usr/lib64 directory. Is this the =
intended outcome? <br>

<br><div class=3D"gmail_quote">On Mon, Feb 27, 2012 at 3:19 PM, Jeffrey Kar=
rels <span dir=3D"ltr">&lt;<a href=3D"mailto:karrelsj@gmail.com">karrelsj@g=
mail.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">

System: Centos 6.1, xen-unstable (4.2), x86_64<br><br>Hello all,<br><br>I w=
as just wondering what the &quot;correct&quot; way is to go about this. I h=
ave a x86_64 centos system that has all of the libs going to /usr/lib and n=
ot /usr/lib64. It sounds like we want to keep everything in /usr/lib on pur=
pose. Is that correct?<br>


<br>Jeff<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gmail=
_quote">On Sun, Oct 23, 2011 at 10:52 PM, AP <span dir=3D"ltr">&lt;<a href=
=3D"mailto:apxeng@gmail.com" target=3D"_blank">apxeng@gmail.com</a>&gt;</sp=
an> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>On Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell &lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt; wr=
ote:<br>
&gt; On Fri, 2011-10-21 at 04:52 +0100, AP wrote:<br>
&gt;&gt; On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson &lt;<a href=3D"mailto=
:Ian.Jackson@eu.citrix.com" target=3D"_blank">Ian.Jackson@eu.citrix.com</a>=
&gt; wrote:<br>
&gt;&gt; &gt; Ian Campbell writes (&quot;Re: [Xen-devel] make install not c=
reating lib entries in /&gt; It might be nice if there was a single variabl=
e which could be set to<br>
&gt;&gt; &gt;&gt; control this behaviour, or even better if it can be autom=
atically<br>
&gt;&gt; &gt;&gt; detected. I&#39;m also inclined to suggest that the defau=
lt should be to<br>
&gt;&gt; &gt;&gt; use /usr/lib and leave the lib64 thing as a RH special ca=
se, but then<br>
&gt;&gt; &gt;&gt; I&#39;m a Debian user so I would think that ;-)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; At the very least we ought not to dump things in /usr/lib64 u=
nless it<br>
&gt;&gt; &gt; already exists and is distinct from /usr/lib.<br>
&gt;&gt;<br>
&gt;&gt; I deleted my /usr/lib64 and did a &quot;make install-tools<br>
&gt;&gt; PYTHON_PREFIX_ARG=3D&quot;. At the end a /usr/lib64 directory was =
created<br>
&gt;&gt; with Xen related libraries inside.<br>
&gt;<br>
&gt; I think you need to reread my earlier reply -- I explained what is goi=
ng<br>
&gt; on and provided an example of the sort of patch which fixes it. There =
is<br>
&gt; no reason to expect that deleting /usr/lib64 will change anything.<br>
<br>
</div>Sorry, I misunderstood Ian Jackson&#39;s comment. It made me think<br=
>
deleting /usr/lib64 might change something :) I now understand the<br>
point he was trying to make and your fix. Thanks for the help.<br>
<div><div><br>
&gt; Ian.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; We should think about multiarch too at some point.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Ian.<br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>

--f46d042c5ec7ec97d804b9fab8b8--


--===============7759724610795859902==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7759724610795859902==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 23:47:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2AHG-0002ep-Rj; Mon, 27 Feb 2012 23:46:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2AHE-0002ei-WB
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:46:45 +0000
Received: from [85.158.139.83:59123] by server-1.bemta-5.messagelabs.com id
	55/BA-28458-4E51C4F4; Mon, 27 Feb 2012 23:46:44 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330386402!16940602!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16099 invoked from network); 27 Feb 2012 23:46:43 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2012 23:46:43 -0000
Received: by lagr15 with SMTP id r15so5461187lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 15:46:42 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.152.130.234 as permitted sender) client-ip=10.152.130.234; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.152.130.234 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.152.130.234])
	by 10.152.130.234 with SMTP id oh10mr14794710lab.35.1330386402410
	(num_hops = 1); Mon, 27 Feb 2012 15:46:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=kKTabTutZ4WFIKVA3zLIgV0Hu14vuhpMjrivYfdMaEM=;
	b=McZN1PCydvri5mUrtqRsopvENxN7BrCUGYEiLG1pUJJo1effjorsZ1lSIo2cQZDveg
	CPAlk+sJnNp9FIVpafVoy93MOZKX1C7Dtj1eH1zLzifB3vZTBvaQW7sj6pL+YDLQ7fNE
	I59JfZ2tUfR3qlj9hZKhGOHDlHz4RudZT/zc4=
Received: by 10.152.130.234 with SMTP id oh10mr12310175lab.35.1330386402318;
	Mon, 27 Feb 2012 15:46:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Mon, 27 Feb 2012 15:46:22 -0800 (PST)
In-Reply-To: <CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Mon, 27 Feb 2012 15:46:22 -0800
Message-ID: <CAFw--Dd8_K=Y=XcFyMKb61=E2kTANy1TjAshETLYKKXCMjtbPQ@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7759724610795859902=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7759724610795859902==
Content-Type: multipart/alternative; boundary=f46d042c5ec7ec97d804b9fab8b8

--f46d042c5ec7ec97d804b9fab8b8
Content-Type: text/plain; charset=ISO-8859-1

In re-reading my last message by itself (without reading the referenced
thread) it sounds rather confusing. What I meant to say was that upon
running a 'make install' or 'make dist' on my Centos x86_64 machine, I find
that all of the libraries (except python2.6)  find their way into the
/usr/lib directory rather than the /usr/lib64 directory. Is this the
intended outcome?

On Mon, Feb 27, 2012 at 3:19 PM, Jeffrey Karrels <karrelsj@gmail.com> wrote:

> System: Centos 6.1, xen-unstable (4.2), x86_64
>
> Hello all,
>
> I was just wondering what the "correct" way is to go about this. I have a
> x86_64 centos system that has all of the libs going to /usr/lib and not
> /usr/lib64. It sounds like we want to keep everything in /usr/lib on
> purpose. Is that correct?
>
> Jeff
>
>
> On Sun, Oct 23, 2011 at 10:52 PM, AP <apxeng@gmail.com> wrote:
>
>> On Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell <Ian.Campbell@citrix.com>
>> wrote:
>> > On Fri, 2011-10-21 at 04:52 +0100, AP wrote:
>> >> On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson <
>> Ian.Jackson@eu.citrix.com> wrote:
>> >> > Ian Campbell writes ("Re: [Xen-devel] make install not creating lib
>> entries in /> It might be nice if there was a single variable which could
>> be set to
>> >> >> control this behaviour, or even better if it can be automatically
>> >> >> detected. I'm also inclined to suggest that the default should be to
>> >> >> use /usr/lib and leave the lib64 thing as a RH special case, but
>> then
>> >> >> I'm a Debian user so I would think that ;-)
>> >> >
>> >> > At the very least we ought not to dump things in /usr/lib64 unless it
>> >> > already exists and is distinct from /usr/lib.
>> >>
>> >> I deleted my /usr/lib64 and did a "make install-tools
>> >> PYTHON_PREFIX_ARG=". At the end a /usr/lib64 directory was created
>> >> with Xen related libraries inside.
>> >
>> > I think you need to reread my earlier reply -- I explained what is going
>> > on and provided an example of the sort of patch which fixes it. There is
>> > no reason to expect that deleting /usr/lib64 will change anything.
>>
>> Sorry, I misunderstood Ian Jackson's comment. It made me think
>> deleting /usr/lib64 might change something :) I now understand the
>> point he was trying to make and your fix. Thanks for the help.
>>
>> > Ian.
>> >
>> >>
>> >> > We should think about multiarch too at some point.
>> >> >
>> >> > Ian.
>> >> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>

--f46d042c5ec7ec97d804b9fab8b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In re-reading my last message by itself (without reading the referenced thr=
ead) it sounds rather confusing. What I meant to say was that upon running =
a &#39;make install&#39; or &#39;make dist&#39; on my Centos x86_64 machine=
, I find that all of the libraries (except python2.6)=A0 find their way int=
o the /usr/lib directory rather than the /usr/lib64 directory. Is this the =
intended outcome? <br>

<br><div class=3D"gmail_quote">On Mon, Feb 27, 2012 at 3:19 PM, Jeffrey Kar=
rels <span dir=3D"ltr">&lt;<a href=3D"mailto:karrelsj@gmail.com">karrelsj@g=
mail.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">

System: Centos 6.1, xen-unstable (4.2), x86_64<br><br>Hello all,<br><br>I w=
as just wondering what the &quot;correct&quot; way is to go about this. I h=
ave a x86_64 centos system that has all of the libs going to /usr/lib and n=
ot /usr/lib64. It sounds like we want to keep everything in /usr/lib on pur=
pose. Is that correct?<br>


<br>Jeff<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gmail=
_quote">On Sun, Oct 23, 2011 at 10:52 PM, AP <span dir=3D"ltr">&lt;<a href=
=3D"mailto:apxeng@gmail.com" target=3D"_blank">apxeng@gmail.com</a>&gt;</sp=
an> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>On Sat, Oct 22, 2011 at 5:47 AM, Ian Campbell &lt;<a href=3D"mailto:Ia=
n.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt; wr=
ote:<br>
&gt; On Fri, 2011-10-21 at 04:52 +0100, AP wrote:<br>
&gt;&gt; On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson &lt;<a href=3D"mailto=
:Ian.Jackson@eu.citrix.com" target=3D"_blank">Ian.Jackson@eu.citrix.com</a>=
&gt; wrote:<br>
&gt;&gt; &gt; Ian Campbell writes (&quot;Re: [Xen-devel] make install not c=
reating lib entries in /&gt; It might be nice if there was a single variabl=
e which could be set to<br>
&gt;&gt; &gt;&gt; control this behaviour, or even better if it can be autom=
atically<br>
&gt;&gt; &gt;&gt; detected. I&#39;m also inclined to suggest that the defau=
lt should be to<br>
&gt;&gt; &gt;&gt; use /usr/lib and leave the lib64 thing as a RH special ca=
se, but then<br>
&gt;&gt; &gt;&gt; I&#39;m a Debian user so I would think that ;-)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; At the very least we ought not to dump things in /usr/lib64 u=
nless it<br>
&gt;&gt; &gt; already exists and is distinct from /usr/lib.<br>
&gt;&gt;<br>
&gt;&gt; I deleted my /usr/lib64 and did a &quot;make install-tools<br>
&gt;&gt; PYTHON_PREFIX_ARG=3D&quot;. At the end a /usr/lib64 directory was =
created<br>
&gt;&gt; with Xen related libraries inside.<br>
&gt;<br>
&gt; I think you need to reread my earlier reply -- I explained what is goi=
ng<br>
&gt; on and provided an example of the sort of patch which fixes it. There =
is<br>
&gt; no reason to expect that deleting /usr/lib64 will change anything.<br>
<br>
</div>Sorry, I misunderstood Ian Jackson&#39;s comment. It made me think<br=
>
deleting /usr/lib64 might change something :) I now understand the<br>
point he was trying to make and your fix. Thanks for the help.<br>
<div><div><br>
&gt; Ian.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; We should think about multiarch too at some point.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Ian.<br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>

--f46d042c5ec7ec97d804b9fab8b8--


--===============7759724610795859902==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7759724610795859902==--


From xen-devel-bounces@lists.xen.org Mon Feb 27 23:51:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ALT-0002n1-H9; Mon, 27 Feb 2012 23:51:07 +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 1S2ALR-0002mv-Qz
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:51:06 +0000
Received: from [85.158.139.83:7031] by server-8.bemta-5.messagelabs.com id
	D7/7E-09797-9E61C4F4; Mon, 27 Feb 2012 23:51:05 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330386663!13010868!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY5ODc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13015 invoked from network); 27 Feb 2012 23:51:04 -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; 27 Feb 2012 23:51: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 q1RNouaM030879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 23:50:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1RNotUw019219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 23:50:55 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
	q1RNosLO024483; Mon, 27 Feb 2012 17:50:54 -0600
MIME-Version: 1.0
Message-ID: <24bf2149-d045-4668-a0b1-31152fc07e66@default>
Date: Mon, 27 Feb 2012 15:50:41 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Tim Deegan <tim@xen.org>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120227195115.GE98737@ocelot.phlegethon.org>
In-Reply-To: <20120227195115.GE98737@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090208.4F4C16E1.00A7,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: Pointed questions re Xen memory overcommit

Thanks much for the reply Tim!

> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> > 1) How is the capability and implementation similar or different
> > from VMware's?  And specifically I'm asking for hard information
> > relating to:
> >
> > http://lwn.net/Articles/309155/
> > http://lwn.net/Articles/330589/
> >
> > I am not a lawyer and my employer forbids me from reading the
> > related patent claims or speculating on any related issues, but
> > I will be strongly recommending a thorough legal review before
> > Oracle ships this code in any form that customers can enable.
> > (I'm hoping for an answer that would render a review moot.)
> 
> I am not a lawyer and my employer forbids me from reading the
> related patent claims or speculating on any related issues. :P

Heh.  If there is a smiley-face that means "we both roll
our eyes at the insanity of lawyers", put it here.
 
> > 2) Assuming no legal issues, how is Xen memory overcommit different
> > or better than VMware's, which is known to have lots of issues
> > in the real world, such that few customers (outside of a handful
> > of domains such as VDI) enable it?  Or is this effort largely to
> > remove an item from the VMware sales team's differentiation list?
> > And a comparison vs Hyper-V and KVM would be interesting also.
> 
> The blktap-based page-sharing tool doesn't use content hashes to find
> pages to share; it relies on storage-layer knowledge to detect disk
> reads that will have identical results.  Grzegorz's PhD dissertation and
> the paper on Satori discuss why that's a better idea than trying to find
> shareable pages by scanning.

Excellent.

> I agree that using page sharing to try to recover memory for higher VM
> density is, let's say, challenging.  But in certain specific workloads
> (e.g. snowflock &c), or if you're doing something else with the
> recovered memory (e.g. tmem?) then it makes more sense.
> 
> I have no direct experience of real-world deployments.

Me neither, just some comments from a few VMware users.  I agreea
Satori and or "the other page sharing" may make good sense in certain
heavily redundant workloads.

> > 3) Is there new evidence that a host-based-policy-driven memory
> > balancer works sufficiently well on one system, or for
> > multiple hosts, or for a data center?
> 
> That, I think, is an open research question.

OK, that's what I thought.

> > It would be nice for
> > all Xen developers/vendors to understand the intended customer
> > (e.g. is it the desktop user running a handful of VMs running
> > known workloads?)
> 
> With my hypervisor hat on, we've tried to make a sensible interface
> where all the policy-related decisions that this question would apply to
> can be made in the tools.  (I realise that I'm totally punting on the
> question).

That's OK... though "sensible" is difficult to measure without
a broader context.  IMHO (and I know I'm in a minority), punting
to the tools only increases the main problem (semantic gap).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 27 23:51:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 27 Feb 2012 23:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ALT-0002n1-H9; Mon, 27 Feb 2012 23:51:07 +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 1S2ALR-0002mv-Qz
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:51:06 +0000
Received: from [85.158.139.83:7031] by server-8.bemta-5.messagelabs.com id
	D7/7E-09797-9E61C4F4; Mon, 27 Feb 2012 23:51:05 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330386663!13010868!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTY5ODc3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13015 invoked from network); 27 Feb 2012 23:51:04 -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; 27 Feb 2012 23:51: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 q1RNouaM030879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 27 Feb 2012 23:50:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q1RNotUw019219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Feb 2012 23:50:55 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
	q1RNosLO024483; Mon, 27 Feb 2012 17:50:54 -0600
MIME-Version: 1.0
Message-ID: <24bf2149-d045-4668-a0b1-31152fc07e66@default>
Date: Mon, 27 Feb 2012 15:50:41 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Tim Deegan <tim@xen.org>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120227195115.GE98737@ocelot.phlegethon.org>
In-Reply-To: <20120227195115.GE98737@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090208.4F4C16E1.00A7,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: Pointed questions re Xen memory overcommit

Thanks much for the reply Tim!

> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> > 1) How is the capability and implementation similar or different
> > from VMware's?  And specifically I'm asking for hard information
> > relating to:
> >
> > http://lwn.net/Articles/309155/
> > http://lwn.net/Articles/330589/
> >
> > I am not a lawyer and my employer forbids me from reading the
> > related patent claims or speculating on any related issues, but
> > I will be strongly recommending a thorough legal review before
> > Oracle ships this code in any form that customers can enable.
> > (I'm hoping for an answer that would render a review moot.)
> 
> I am not a lawyer and my employer forbids me from reading the
> related patent claims or speculating on any related issues. :P

Heh.  If there is a smiley-face that means "we both roll
our eyes at the insanity of lawyers", put it here.
 
> > 2) Assuming no legal issues, how is Xen memory overcommit different
> > or better than VMware's, which is known to have lots of issues
> > in the real world, such that few customers (outside of a handful
> > of domains such as VDI) enable it?  Or is this effort largely to
> > remove an item from the VMware sales team's differentiation list?
> > And a comparison vs Hyper-V and KVM would be interesting also.
> 
> The blktap-based page-sharing tool doesn't use content hashes to find
> pages to share; it relies on storage-layer knowledge to detect disk
> reads that will have identical results.  Grzegorz's PhD dissertation and
> the paper on Satori discuss why that's a better idea than trying to find
> shareable pages by scanning.

Excellent.

> I agree that using page sharing to try to recover memory for higher VM
> density is, let's say, challenging.  But in certain specific workloads
> (e.g. snowflock &c), or if you're doing something else with the
> recovered memory (e.g. tmem?) then it makes more sense.
> 
> I have no direct experience of real-world deployments.

Me neither, just some comments from a few VMware users.  I agreea
Satori and or "the other page sharing" may make good sense in certain
heavily redundant workloads.

> > 3) Is there new evidence that a host-based-policy-driven memory
> > balancer works sufficiently well on one system, or for
> > multiple hosts, or for a data center?
> 
> That, I think, is an open research question.

OK, that's what I thought.

> > It would be nice for
> > all Xen developers/vendors to understand the intended customer
> > (e.g. is it the desktop user running a handful of VMs running
> > known workloads?)
> 
> With my hypervisor hat on, we've tried to make a sensible interface
> where all the policy-related decisions that this question would apply to
> can be made in the tools.  (I realise that I'm totally punting on the
> question).

That's OK... though "sensible" is difficult to measure without
a broader context.  IMHO (and I know I'm in a minority), punting
to the tools only increases the main problem (semantic gap).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 00:58:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 00:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2BNy-0003s8-9d; Tue, 28 Feb 2012 00:57:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S2BNw-0003s3-Hp
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 00:57:44 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330390657!10047554!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9641 invoked from network); 28 Feb 2012 00:57:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2012 00:57:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S2BNo-0005fM-Ni
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:57:36 -0800
Date: Mon, 27 Feb 2012 16:57:36 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1330390656726-5520504.post@n5.nabble.com>
In-Reply-To: <20120227121401.096bd19d@mantra.us.oracle.com>
References: <1330163951764-5514885.post@n5.nabble.com>
	<CB6E72DB.2C43B%keir.xen@gmail.com>
	<20120227121401.096bd19d@mantra.us.oracle.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 really a good news. Expecting the good job.

--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-system-call-efficiency-on-x86-64-tp5514885p5520504.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 00:58:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 00:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2BNy-0003s8-9d; Tue, 28 Feb 2012 00:57:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S2BNw-0003s3-Hp
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 00:57:44 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330390657!10047554!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9641 invoked from network); 28 Feb 2012 00:57:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2012 00:57:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1S2BNo-0005fM-Ni
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 16:57:36 -0800
Date: Mon, 27 Feb 2012 16:57:36 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1330390656726-5520504.post@n5.nabble.com>
In-Reply-To: <20120227121401.096bd19d@mantra.us.oracle.com>
References: <1330163951764-5514885.post@n5.nabble.com>
	<CB6E72DB.2C43B%keir.xen@gmail.com>
	<20120227121401.096bd19d@mantra.us.oracle.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] dom0 system call efficiency on x86_64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 really a good news. Expecting the good job.

--
View this message in context: http://xen.1045712.n5.nabble.com/dom0-system-call-efficiency-on-x86-64-tp5514885p5520504.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 03:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 03: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 1S2E3t-0000hf-FY; Tue, 28 Feb 2012 03:49:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2E3r-0000hX-Fa
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 03:49:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330400944!16660738!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzIw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzIw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19842 invoked from network); 28 Feb 2012 03:49:04 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 03:49:04 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 893EE76C06F;
	Mon, 27 Feb 2012 19:49:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AM7cmovVG8xSkK6fZXMcah+ecZt0/Hl0NtVZQCa/dl5T
	g8IIxVD9HyNhBwUwW/eAd+24h3Onr+2kahwF66eqS8949LtavcPQkqFgAF+QH25T
	9Yqvb0ZXIIRUlVGvg8onCaAu5/vlBLs3mAJv918LvEijMOd379Aqi4fZbF60w60=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Uv4aGPOSHEjGdy+3Ot7GcHowJ9g=; b=N/GhGc3F
	4zuGyrXlF0EBhr7YID2J2McVLlvU10X5p9608c3rSQnEZsVIYRvoivRHFr9ZttsI
	VIBhrPAAgFWYZfsZK49cy0UVulyLjojgErFN053R9nZh++70aK4quN9KQnS+UT1p
	EhoAXhY1bFbQmCknGzQFr233gJpNBxkvb1w=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 1BCEE76C06E; 
	Mon, 27 Feb 2012 19:49:03 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 27 Feb 2012 19:49:03 -0800
Message-ID: <0c174157fb78a2f50706b50b08cace35.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4684.1330272940.1471.xen-devel@lists.xen.org>
References: <mailman.4684.1330272940.1471.xen-devel@lists.xen.org>
Date: Mon, 27 Feb 2012 19:49:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de
Subject: Re: [Xen-devel] [RFC]: xenpaging: add command to to flush qemu
 buffer cache via VMCALL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Date: Sun, 26 Feb 2012 17:15:12 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] [RFC]: xenpaging: add command to to flush
> 	qemu buffer cache via VMCALL
> Message-ID: <e17afed13a35989bdf42.1330272912@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1330272880 -3600
> # Node ID e17afed13a35989bdf422b75d44843bfd2fda0f4
> # Parent  3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
> [RFC]: xenpaging: add command to to flush qemu buffer cache via VMCALL
>
> Is the approach taken in this patch ok?
> With the debug output in my patch I get output like pasted below. It
> means that xenpaging set qemu_mapcache_invalidate very often before a
> VMCALL occoured.
>
> What triggers a VMCALL anyway?

If your VM is not using pv drivers, then hypercalls won't happen. You
could argue that most VMs out there use some form of pv driver, but you
are far from getting 100% coverage.

I don't think this is the right approach, anyways. xenpaging and qemu are
dom0 user-space daemons, they have plenty of ways to agree on things. What
happened to the xenstore, or to qmp? Enlisting the hypervisor is rather
unnecessary.

Andres

> It looks like its not something one can
> depend on. From xenpagings PoV its not required that the command reaches
> qemu right away, but it should be processed "soon".
> Could send_invalidate_req() be called from another exit reason (or from
> another place perhaps)?
>
> Olaf
>
>
> ....
> (XEN) irq.c:350: Dom1 callback via changed to PCI INTx Dev 0x03 IntA
> (XEN) hvm_do_hypercall: 0 1 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 0 1 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 3049 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 4562 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 6 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 6 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 14 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 598 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 1 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 3 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 161 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 1 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 4860 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 1 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 799 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 5 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> ....
>
>
>
> ....
> qemu will just keep mapping pages and not release them, which causes
> problems for the memory pager (since the page is mapped, it won't get
> paged out).  When the pager has trouble finding a page to page out, it
> asks qemu to flush its buffer, which releases all the page mappings.
> This makes it possible to find  pages to swap out agian.
>
> This change removes the code which writes "flush-cache" to xenstore
> because the corresponding change for qemu-xen-traditional was never
> applied, and it also will not work with qemu-xen-upstream.
>
> Instead of sending commands via xenstore, use the existing
> IOREQ_TYPE_INVALIDATE command for HVM guests. A simple memory_op just
> sets qemu_mapcache_invalidate flag which in turn causes the hypervisor
> to send the actual IOREQ_TYPE_INVALIDATE during next VMEXIT_VMCALL.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -93,6 +93,14 @@ int xc_mem_paging_load(xc_interface *xch
>      return rc;
>  }
>
> +int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id)
> +{
> +    return xc_mem_event_memop(xch, domain_id,
> +                                XENMEM_paging_op_ioemu_flush,
> +                                XENMEM_paging_op,
> +                                0, NULL);
> +}
> +
>
>  /*
>   * Local variables:
> diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1902,6 +1902,7 @@ int xc_mem_paging_evict(xc_interface *xc
>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned
> long gfn);
>  int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
>                          unsigned long gfn, void *buffer);
> +int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id);
>
>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>                          void *shared_page, void *ring_page);
> diff -r 3ace34b89ebe -r e17afed13a35 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -62,15 +62,11 @@ static void close_handler(int sig)
>      unlink_pagefile();
>  }
>
> -static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging
> *paging)
> +static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging
> *paging)
>  {
> -    struct xs_handle *xsh = paging->xs_handle;
> +    xc_interface *xch = paging->xc_handle;
>      domid_t domain_id = paging->mem_event.domain_id;
> -    char path[80];
> -
> -    sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
> -
> -    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache"));
> +    return xc_mem_paging_flush(xch, domain_id);
>  }
>
>  static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
> @@ -768,7 +764,12 @@ static int evict_victim(struct xenpaging
>              if ( num_paged_out != paging->num_paged_out )
>              {
>                  DPRINTF("Flushing qemu cache\n");
> -                xenpaging_mem_paging_flush_ioemu_cache(paging);
> +                ret = xenpaging_mem_paging_flush_ioemu_cache(paging);
> +                if ( ret < 0 )
> +                {
> +                    PERROR("Flushing qemu cache\n");
> +                    goto out;
> +                }
>                  num_paged_out = paging->num_paged_out;
>              }
>              ret = ENOSPC;
> diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2997,6 +2997,7 @@ static long hvm_memory_op(int cmd, XEN_G
>          return -ENOSYS;
>      case XENMEM_decrease_reservation:
>          rc = do_memory_op(cmd, arg);
> +        current->domain->arch.hvm_domain.inv_hvm++;
>          current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
>          return rc;
>      }
> @@ -3088,6 +3089,7 @@ static long hvm_memory_op_compat32(int c
>          return -ENOSYS;
>      case XENMEM_decrease_reservation:
>          rc = compat_memory_op(cmd, arg);
> +        current->domain->arch.hvm_domain.inv_hvm32++;
>          current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
>          return rc;
>      }
> @@ -3246,7 +3248,17 @@ int hvm_do_hypercall(struct cpu_user_reg
>      if ( unlikely(curr->domain->arch.hvm_domain.qemu_mapcache_invalidate)
> &&
>           test_and_clear_bool(curr->domain->arch.hvm_domain.
>                               qemu_mapcache_invalidate) )
> +    {
> +        printk("%s: %u %u %u\n",
> +            __func__,
> +            curr->domain->arch.hvm_domain.inv_paging,
> +            curr->domain->arch.hvm_domain.inv_hvm,
> +            curr->domain->arch.hvm_domain.inv_hvm32);
> +        curr->domain->arch.hvm_domain.inv_paging =
> +        curr->domain->arch.hvm_domain.inv_hvm =
> +        curr->domain->arch.hvm_domain.inv_hvm32 = 0;
>          return HVM_HCALL_invalidate;
> +    }
>
>      return HVM_HCALL_completed;
>  }
> diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/io.c
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -152,6 +152,7 @@ void send_invalidate_req(void)
>      struct vcpu *v = current;
>      ioreq_t *p = get_ioreq(v);
>
> +    gdprintk(XENLOG_DEBUG,"%s\n", __func__);
>      if ( p->state != STATE_IOREQ_NONE )
>      {
>          gdprintk(XENLOG_ERR, "WARNING: send invalidate req with something
> "
> diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/mm/mem_paging.c
> --- a/xen/arch/x86/mm/mem_paging.c
> +++ b/xen/arch/x86/mm/mem_paging.c
> @@ -53,6 +53,15 @@ int mem_paging_memop(struct domain *d, x
>      }
>      break;
>
> +    case XENMEM_paging_op_ioemu_flush:
> +    {
> +        /* Flush qemu cache on next VMEXIT_VMCALL */
> +        d->arch.hvm_domain.inv_paging++;
> +        d->arch.hvm_domain.qemu_mapcache_invalidate = 1;
> +        return 0;
> +    }
> +    break;
> +
>      default:
>          return -ENOSYS;
>          break;
> diff -r 3ace34b89ebe -r e17afed13a35 xen/include/asm-x86/hvm/domain.h
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -95,6 +95,9 @@ struct hvm_domain {
>      bool_t                 mem_sharing_enabled;
>      bool_t                 qemu_mapcache_invalidate;
>      bool_t                 is_s3_suspended;
> +    unsigned int inv_paging;
> +    unsigned int inv_hvm;
> +    unsigned int inv_hvm32;
>
>      union {
>          struct vmx_domain vmx;
> diff -r 3ace34b89ebe -r e17afed13a35 xen/include/public/memory.h
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -322,6 +322,7 @@ typedef struct xen_pod_target xen_pod_ta
>  #define XENMEM_paging_op_nominate           0
>  #define XENMEM_paging_op_evict              1
>  #define XENMEM_paging_op_prep               2
> +#define XENMEM_paging_op_ioemu_flush        3
>
>  #define XENMEM_access_op                    21
>  #define XENMEM_access_op_resume             0
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
> End of Xen-devel Digest, Vol 84, Issue 450
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 03:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 03: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 1S2E3t-0000hf-FY; Tue, 28 Feb 2012 03:49:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2E3r-0000hX-Fa
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 03:49:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330400944!16660738!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzIw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzIw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19842 invoked from network); 28 Feb 2012 03:49:04 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 03:49:04 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 893EE76C06F;
	Mon, 27 Feb 2012 19:49:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AM7cmovVG8xSkK6fZXMcah+ecZt0/Hl0NtVZQCa/dl5T
	g8IIxVD9HyNhBwUwW/eAd+24h3Onr+2kahwF66eqS8949LtavcPQkqFgAF+QH25T
	9Yqvb0ZXIIRUlVGvg8onCaAu5/vlBLs3mAJv918LvEijMOd379Aqi4fZbF60w60=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Uv4aGPOSHEjGdy+3Ot7GcHowJ9g=; b=N/GhGc3F
	4zuGyrXlF0EBhr7YID2J2McVLlvU10X5p9608c3rSQnEZsVIYRvoivRHFr9ZttsI
	VIBhrPAAgFWYZfsZK49cy0UVulyLjojgErFN053R9nZh++70aK4quN9KQnS+UT1p
	EhoAXhY1bFbQmCknGzQFr233gJpNBxkvb1w=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 1BCEE76C06E; 
	Mon, 27 Feb 2012 19:49:03 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 27 Feb 2012 19:49:03 -0800
Message-ID: <0c174157fb78a2f50706b50b08cace35.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4684.1330272940.1471.xen-devel@lists.xen.org>
References: <mailman.4684.1330272940.1471.xen-devel@lists.xen.org>
Date: Mon, 27 Feb 2012 19:49:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de
Subject: Re: [Xen-devel] [RFC]: xenpaging: add command to to flush qemu
 buffer cache via VMCALL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Date: Sun, 26 Feb 2012 17:15:12 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] [RFC]: xenpaging: add command to to flush
> 	qemu buffer cache via VMCALL
> Message-ID: <e17afed13a35989bdf42.1330272912@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1330272880 -3600
> # Node ID e17afed13a35989bdf422b75d44843bfd2fda0f4
> # Parent  3ace34b89ebe3bdd6afb0bca85b0c1270f99c1bb
> [RFC]: xenpaging: add command to to flush qemu buffer cache via VMCALL
>
> Is the approach taken in this patch ok?
> With the debug output in my patch I get output like pasted below. It
> means that xenpaging set qemu_mapcache_invalidate very often before a
> VMCALL occoured.
>
> What triggers a VMCALL anyway?

If your VM is not using pv drivers, then hypercalls won't happen. You
could argue that most VMs out there use some form of pv driver, but you
are far from getting 100% coverage.

I don't think this is the right approach, anyways. xenpaging and qemu are
dom0 user-space daemons, they have plenty of ways to agree on things. What
happened to the xenstore, or to qmp? Enlisting the hypervisor is rather
unnecessary.

Andres

> It looks like its not something one can
> depend on. From xenpagings PoV its not required that the command reaches
> qemu right away, but it should be processed "soon".
> Could send_invalidate_req() be called from another exit reason (or from
> another place perhaps)?
>
> Olaf
>
>
> ....
> (XEN) irq.c:350: Dom1 callback via changed to PCI INTx Dev 0x03 IntA
> (XEN) hvm_do_hypercall: 0 1 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 0 1 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 3049 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 4562 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 6 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 6 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 14 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 598 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 1 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 3 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 161 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 1 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 4860 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 1 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 799 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> (XEN) hvm_do_hypercall: 5 0 0
> (XEN) io.c:155:d1 send_invalidate_req
> ....
>
>
>
> ....
> qemu will just keep mapping pages and not release them, which causes
> problems for the memory pager (since the page is mapped, it won't get
> paged out).  When the pager has trouble finding a page to page out, it
> asks qemu to flush its buffer, which releases all the page mappings.
> This makes it possible to find  pages to swap out agian.
>
> This change removes the code which writes "flush-cache" to xenstore
> because the corresponding change for qemu-xen-traditional was never
> applied, and it also will not work with qemu-xen-upstream.
>
> Instead of sending commands via xenstore, use the existing
> IOREQ_TYPE_INVALIDATE command for HVM guests. A simple memory_op just
> sets qemu_mapcache_invalidate flag which in turn causes the hypervisor
> to send the actual IOREQ_TYPE_INVALIDATE during next VMEXIT_VMCALL.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -93,6 +93,14 @@ int xc_mem_paging_load(xc_interface *xch
>      return rc;
>  }
>
> +int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id)
> +{
> +    return xc_mem_event_memop(xch, domain_id,
> +                                XENMEM_paging_op_ioemu_flush,
> +                                XENMEM_paging_op,
> +                                0, NULL);
> +}
> +
>
>  /*
>   * Local variables:
> diff -r 3ace34b89ebe -r e17afed13a35 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -1902,6 +1902,7 @@ int xc_mem_paging_evict(xc_interface *xc
>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned
> long gfn);
>  int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
>                          unsigned long gfn, void *buffer);
> +int xc_mem_paging_flush(xc_interface *xch, domid_t domain_id);
>
>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>                          void *shared_page, void *ring_page);
> diff -r 3ace34b89ebe -r e17afed13a35 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -62,15 +62,11 @@ static void close_handler(int sig)
>      unlink_pagefile();
>  }
>
> -static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging
> *paging)
> +static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging
> *paging)
>  {
> -    struct xs_handle *xsh = paging->xs_handle;
> +    xc_interface *xch = paging->xc_handle;
>      domid_t domain_id = paging->mem_event.domain_id;
> -    char path[80];
> -
> -    sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
> -
> -    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache"));
> +    return xc_mem_paging_flush(xch, domain_id);
>  }
>
>  static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
> @@ -768,7 +764,12 @@ static int evict_victim(struct xenpaging
>              if ( num_paged_out != paging->num_paged_out )
>              {
>                  DPRINTF("Flushing qemu cache\n");
> -                xenpaging_mem_paging_flush_ioemu_cache(paging);
> +                ret = xenpaging_mem_paging_flush_ioemu_cache(paging);
> +                if ( ret < 0 )
> +                {
> +                    PERROR("Flushing qemu cache\n");
> +                    goto out;
> +                }
>                  num_paged_out = paging->num_paged_out;
>              }
>              ret = ENOSPC;
> diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2997,6 +2997,7 @@ static long hvm_memory_op(int cmd, XEN_G
>          return -ENOSYS;
>      case XENMEM_decrease_reservation:
>          rc = do_memory_op(cmd, arg);
> +        current->domain->arch.hvm_domain.inv_hvm++;
>          current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
>          return rc;
>      }
> @@ -3088,6 +3089,7 @@ static long hvm_memory_op_compat32(int c
>          return -ENOSYS;
>      case XENMEM_decrease_reservation:
>          rc = compat_memory_op(cmd, arg);
> +        current->domain->arch.hvm_domain.inv_hvm32++;
>          current->domain->arch.hvm_domain.qemu_mapcache_invalidate = 1;
>          return rc;
>      }
> @@ -3246,7 +3248,17 @@ int hvm_do_hypercall(struct cpu_user_reg
>      if ( unlikely(curr->domain->arch.hvm_domain.qemu_mapcache_invalidate)
> &&
>           test_and_clear_bool(curr->domain->arch.hvm_domain.
>                               qemu_mapcache_invalidate) )
> +    {
> +        printk("%s: %u %u %u\n",
> +            __func__,
> +            curr->domain->arch.hvm_domain.inv_paging,
> +            curr->domain->arch.hvm_domain.inv_hvm,
> +            curr->domain->arch.hvm_domain.inv_hvm32);
> +        curr->domain->arch.hvm_domain.inv_paging =
> +        curr->domain->arch.hvm_domain.inv_hvm =
> +        curr->domain->arch.hvm_domain.inv_hvm32 = 0;
>          return HVM_HCALL_invalidate;
> +    }
>
>      return HVM_HCALL_completed;
>  }
> diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/hvm/io.c
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -152,6 +152,7 @@ void send_invalidate_req(void)
>      struct vcpu *v = current;
>      ioreq_t *p = get_ioreq(v);
>
> +    gdprintk(XENLOG_DEBUG,"%s\n", __func__);
>      if ( p->state != STATE_IOREQ_NONE )
>      {
>          gdprintk(XENLOG_ERR, "WARNING: send invalidate req with something
> "
> diff -r 3ace34b89ebe -r e17afed13a35 xen/arch/x86/mm/mem_paging.c
> --- a/xen/arch/x86/mm/mem_paging.c
> +++ b/xen/arch/x86/mm/mem_paging.c
> @@ -53,6 +53,15 @@ int mem_paging_memop(struct domain *d, x
>      }
>      break;
>
> +    case XENMEM_paging_op_ioemu_flush:
> +    {
> +        /* Flush qemu cache on next VMEXIT_VMCALL */
> +        d->arch.hvm_domain.inv_paging++;
> +        d->arch.hvm_domain.qemu_mapcache_invalidate = 1;
> +        return 0;
> +    }
> +    break;
> +
>      default:
>          return -ENOSYS;
>          break;
> diff -r 3ace34b89ebe -r e17afed13a35 xen/include/asm-x86/hvm/domain.h
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -95,6 +95,9 @@ struct hvm_domain {
>      bool_t                 mem_sharing_enabled;
>      bool_t                 qemu_mapcache_invalidate;
>      bool_t                 is_s3_suspended;
> +    unsigned int inv_paging;
> +    unsigned int inv_hvm;
> +    unsigned int inv_hvm32;
>
>      union {
>          struct vmx_domain vmx;
> diff -r 3ace34b89ebe -r e17afed13a35 xen/include/public/memory.h
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -322,6 +322,7 @@ typedef struct xen_pod_target xen_pod_ta
>  #define XENMEM_paging_op_nominate           0
>  #define XENMEM_paging_op_evict              1
>  #define XENMEM_paging_op_prep               2
> +#define XENMEM_paging_op_ioemu_flush        3
>
>  #define XENMEM_access_op                    21
>  #define XENMEM_access_op_resume             0
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
> End of Xen-devel Digest, Vol 84, Issue 450
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 04:57:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 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 1S2F78-00015f-QJ; Tue, 28 Feb 2012 04:56:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2F77-00015a-SD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 04:56:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330404990!13034031!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17704 invoked from network); 28 Feb 2012 04:56:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 04:56:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,494,1325462400"; d="scan'208";a="10969709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 04:56:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 04:56:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2F6z-0003B5-Rt;
	Tue, 28 Feb 2012 04:56:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2F6z-0006Pd-RC;
	Tue, 28 Feb 2012 04:56:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S2F6z-0006Pd-RC@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 04:56:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl-win
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-i386-i386-xl-win
test windows-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12090 fail [host=leaf-beetle] / 12031 ok.
Failure / basis pass flights: 12090 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-71159fb049f2
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 62 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12073 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12090 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12098 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12053 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12079 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12100 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12102 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12062 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12085 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12089 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12091 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12093 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12094 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12095 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12096 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12097 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12062 (fail), for basis failure
 Repro found: flight 12089 (pass), for basis pass
 Repro found: flight 12090 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12095 (pass), for last pass
 Result found: flight 12096 (fail), for first failure
 Repro found: flight 12097 (pass), for last pass
 Repro found: flight 12098 (fail), for first failure
 Repro found: flight 12100 (pass), for last pass
 Repro found: flight 12102 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.{dot,ps,png,html}.
----------------------------------------
12102: ALL FAIL

flight 12102 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12102/


jobs:
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 04:57:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 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 1S2F78-00015f-QJ; Tue, 28 Feb 2012 04:56:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2F77-00015a-SD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 04:56:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330404990!13034031!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17704 invoked from network); 28 Feb 2012 04:56:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 04:56:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,494,1325462400"; d="scan'208";a="10969709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 04:56:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 04:56:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2F6z-0003B5-Rt;
	Tue, 28 Feb 2012 04:56:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2F6z-0006Pd-RC;
	Tue, 28 Feb 2012 04:56:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1S2F6z-0006Pd-RC@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 04:56:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl-win
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-i386-i386-xl-win
test windows-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39


  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 12090 fail [host=leaf-beetle] / 12031 ok.
Failure / basis pass flights: 12090 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-71159fb049f2
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 62 nodes in revision graph
Searching for test results:
 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
 12073 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12090 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12098 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12053 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12079 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12100 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12102 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12062 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12085 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12089 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
 12091 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 71159fb049f2
 12093 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
 12094 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
 12095 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
 12096 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
 12097 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
Searching for interesting versions
 Result found: flight 12024 (pass), for basis pass
 Result found: flight 12062 (fail), for basis failure
 Repro found: flight 12089 (pass), for basis pass
 Repro found: flight 12090 (fail), for basis failure
 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
 Result found: flight 12095 (pass), for last pass
 Result found: flight 12096 (fail), for first failure
 Repro found: flight 12097 (pass), for last pass
 Repro found: flight 12098 (fail), for first failure
 Repro found: flight 12100 (pass), for last pass
 Repro found: flight 12102 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  a59c1dcfe968
  Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24875:a59c1dcfe968
  user:        Justin T. Gibbs <justing@spectralogic.com>
  date:        Thu Feb 23 10:03:07 2012 +0000
      
      blkif.h: Define and document the request number/size/segments extension
      
      Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
            BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.  Drivers must be
            updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
            before being recompiled with a __XEN_INTERFACE_VERSION greater
            than or equal to this value.
      
      This extension first appeared in the FreeBSD Operating System.
      
      Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl-win.windows-install.{dot,ps,png,html}.
----------------------------------------
12102: ALL FAIL

flight 12102 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12102/


jobs:
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 05:10:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 05: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 1S2FJY-0001Rc-2X; Tue, 28 Feb 2012 05:09:28 +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 1S2FJW-0001RX-5w
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 05:09:26 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330405738!54770077!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNTQ2OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2607 invoked from network); 28 Feb 2012 05:08:59 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 05:08:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 27 Feb 2012 21:09:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="130191691"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 27 Feb 2012 21:09:17 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:09:09 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:09:09 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Tue, 28 Feb 2012 13:09:07 +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] X86: expose HLE/RTM features to dom0
Thread-Index: Acz11xlgr8yeCv22SGOY28KjL9V7BA==
Date: Tue, 28 Feb 2012 05:09:06 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B7B46@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_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose HLE/RTM features to dom0

Intel recently release 2 new features, HLE and TRM.
Refer to http://software.intel.com/file/41417.
This patch expose them to dom0.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 92e03310878f xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/arch/x86/traps.c	Mon Feb 27 02:23:42 2012 +0800
@@ -857,9 +857,11 @@
     case 0x00000007:
         if ( regs->ecx =3D=3D 0 )
             b &=3D (cpufeat_mask(X86_FEATURE_BMI1) |
+                  cpufeat_mask(X86_FEATURE_HLE)  |
                   cpufeat_mask(X86_FEATURE_AVX2) |
                   cpufeat_mask(X86_FEATURE_BMI2) |
                   cpufeat_mask(X86_FEATURE_ERMS) |
+                  cpufeat_mask(X86_FEATURE_RTM)  |
                   cpufeat_mask(X86_FEATURE_FSGSBASE));
         else
             b =3D 0;
diff -r 92e03310878f xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Mon Feb 27 02:23:42 2012 +0800
@@ -149,11 +149,13 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
 #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions =
*/
 #define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
+#define X86_FEATURE_HLE 	(7*32+ 4) /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
 #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
 #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
 #define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate Process Context ID */
+#define X86_FEATURE_RTM 	(7*32+11) /* Restricted Transactional Memory */
=20
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
 #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)=

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="expose_hlertm_for_dom0.patch"
Content-Description: expose_hlertm_for_dom0.patch
Content-Disposition: attachment; filename="expose_hlertm_for_dom0.patch";
	size=1926; creation-date="Tue, 28 Feb 2012 05:01:55 GMT";
	modification-date="Sun, 26 Feb 2012 18:50:04 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSExFL1JUTSBmZWF0dXJlcyB0byBkb20wCgpJbnRlbCByZWNlbnRseSByZWxl
YXNlIDIgbmV3IGZlYXR1cmVzLCBITEUgYW5kIFRSTS4KUmVmZXIgdG8gaHR0cDovL3NvZnR3YXJl
LmludGVsLmNvbS9maWxlLzQxNDE3LgpUaGlzIHBhdGNoIGV4cG9zZSB0aGVtIHRvIGRvbTAuCgpT
aWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYg
LXIgOTJlMDMzMTA4NzhmIHhlbi9hcmNoL3g4Ni90cmFwcy5jCi0tLSBhL3hlbi9hcmNoL3g4Ni90
cmFwcy5jCVdlZCBGZWIgMDggMjE6MDU6NTIgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
dHJhcHMuYwlNb24gRmViIDI3IDAyOjIzOjQyIDIwMTIgKzA4MDAKQEAgLTg1Nyw5ICs4NTcsMTEg
QEAKICAgICBjYXNlIDB4MDAwMDAwMDc6CiAgICAgICAgIGlmICggcmVncy0+ZWN4ID09IDAgKQog
ICAgICAgICAgICAgYiAmPSAoY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0JNSTEpIHwKKyAgICAg
ICAgICAgICAgICAgIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9ITEUpICB8CiAgICAgICAgICAg
ICAgICAgICBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfQVZYMikgfAogICAgICAgICAgICAgICAg
ICAgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0JNSTIpIHwKICAgICAgICAgICAgICAgICAgIGNw
dWZlYXRfbWFzayhYODZfRkVBVFVSRV9FUk1TKSB8CisgICAgICAgICAgICAgICAgICBjcHVmZWF0
X21hc2soWDg2X0ZFQVRVUkVfUlRNKSAgfAogICAgICAgICAgICAgICAgICAgY3B1ZmVhdF9tYXNr
KFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIGIgPSAw
OwpkaWZmIC1yIDkyZTAzMzEwODc4ZiB4ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAot
LS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAlXZWQgRmViIDA4IDIxOjA1OjUy
IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgJTW9uIEZl
YiAyNyAwMjoyMzo0MiAyMDEyICswODAwCkBAIC0xNDksMTEgKzE0OSwxMyBAQAogLyogSW50ZWwt
ZGVmaW5lZCBDUFUgZmVhdHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MCAoZWJ4KSwgd29y
ZCA3ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0ZTR1NCQVNFCSg3KjMyKyAwKSAvKiB7UkQsV1J9
e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEJKDcq
MzIrIDMpIC8qIDFzdCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KKyNkZWZpbmUgWDg2
X0ZFQVRVUkVfSExFIAkoNyozMisgNCkgLyogSGFyZHdhcmUgTG9jayBFbGlzaW9uICovCiAjZGVm
aW5lIFg4Nl9GRUFUVVJFX0FWWDIJKDcqMzIrIDUpIC8qIEFWWDIgaW5zdHJ1Y3Rpb25zICovCiAj
ZGVmaW5lIFg4Nl9GRUFUVVJFX1NNRVAJKDcqMzIrIDcpIC8qIFN1cGVydmlzb3IgTW9kZSBFeGVj
dXRpb24gUHJvdGVjdGlvbiAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9CTUkyCSg3KjMyKyA4KSAv
KiAybmQgYml0IG1hbmlwdWxhdGlvbiBleHRlbnNpb25zICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJF
X0VSTVMJKDcqMzIrIDkpIC8qIEVuaGFuY2VkIFJFUCBNT1ZTQi9TVE9TQiAqLwogI2RlZmluZSBY
ODZfRkVBVFVSRV9JTlZQQ0lECSg3KjMyKzEwKSAvKiBJbnZhbGlkYXRlIFByb2Nlc3MgQ29udGV4
dCBJRCAqLworI2RlZmluZSBYODZfRkVBVFVSRV9SVE0gCSg3KjMyKzExKSAvKiBSZXN0cmljdGVk
IFRyYW5zYWN0aW9uYWwgTWVtb3J5ICovCiAKICNkZWZpbmUgY3B1X2hhcyhjLCBiaXQpCQl0ZXN0
X2JpdChiaXQsIChjKS0+eDg2X2NhcGFiaWxpdHkpCiAjZGVmaW5lIGJvb3RfY3B1X2hhcyhiaXQp
CXRlc3RfYml0KGJpdCwgYm9vdF9jcHVfZGF0YS54ODZfY2FwYWJpbGl0eSkK

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Feb 28 05:10:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 05: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 1S2FJY-0001Rc-2X; Tue, 28 Feb 2012 05:09:28 +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 1S2FJW-0001RX-5w
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 05:09:26 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330405738!54770077!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNTQ2OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2607 invoked from network); 28 Feb 2012 05:08:59 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 05:08:59 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 27 Feb 2012 21:09:23 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="130191691"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 27 Feb 2012 21:09:17 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:09:09 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:09:09 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Tue, 28 Feb 2012 13:09:07 +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] X86: expose HLE/RTM features to dom0
Thread-Index: Acz11xlgr8yeCv22SGOY28KjL9V7BA==
Date: Tue, 28 Feb 2012 05:09:06 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B7B46@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_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose HLE/RTM features to dom0

Intel recently release 2 new features, HLE and TRM.
Refer to http://software.intel.com/file/41417.
This patch expose them to dom0.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 92e03310878f xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/arch/x86/traps.c	Mon Feb 27 02:23:42 2012 +0800
@@ -857,9 +857,11 @@
     case 0x00000007:
         if ( regs->ecx =3D=3D 0 )
             b &=3D (cpufeat_mask(X86_FEATURE_BMI1) |
+                  cpufeat_mask(X86_FEATURE_HLE)  |
                   cpufeat_mask(X86_FEATURE_AVX2) |
                   cpufeat_mask(X86_FEATURE_BMI2) |
                   cpufeat_mask(X86_FEATURE_ERMS) |
+                  cpufeat_mask(X86_FEATURE_RTM)  |
                   cpufeat_mask(X86_FEATURE_FSGSBASE));
         else
             b =3D 0;
diff -r 92e03310878f xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Mon Feb 27 02:23:42 2012 +0800
@@ -149,11 +149,13 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
 #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions =
*/
 #define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
+#define X86_FEATURE_HLE 	(7*32+ 4) /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
 #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
 #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
 #define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate Process Context ID */
+#define X86_FEATURE_RTM 	(7*32+11) /* Restricted Transactional Memory */
=20
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
 #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)=

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="expose_hlertm_for_dom0.patch"
Content-Description: expose_hlertm_for_dom0.patch
Content-Disposition: attachment; filename="expose_hlertm_for_dom0.patch";
	size=1926; creation-date="Tue, 28 Feb 2012 05:01:55 GMT";
	modification-date="Sun, 26 Feb 2012 18:50:04 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSExFL1JUTSBmZWF0dXJlcyB0byBkb20wCgpJbnRlbCByZWNlbnRseSByZWxl
YXNlIDIgbmV3IGZlYXR1cmVzLCBITEUgYW5kIFRSTS4KUmVmZXIgdG8gaHR0cDovL3NvZnR3YXJl
LmludGVsLmNvbS9maWxlLzQxNDE3LgpUaGlzIHBhdGNoIGV4cG9zZSB0aGVtIHRvIGRvbTAuCgpT
aWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYg
LXIgOTJlMDMzMTA4NzhmIHhlbi9hcmNoL3g4Ni90cmFwcy5jCi0tLSBhL3hlbi9hcmNoL3g4Ni90
cmFwcy5jCVdlZCBGZWIgMDggMjE6MDU6NTIgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
dHJhcHMuYwlNb24gRmViIDI3IDAyOjIzOjQyIDIwMTIgKzA4MDAKQEAgLTg1Nyw5ICs4NTcsMTEg
QEAKICAgICBjYXNlIDB4MDAwMDAwMDc6CiAgICAgICAgIGlmICggcmVncy0+ZWN4ID09IDAgKQog
ICAgICAgICAgICAgYiAmPSAoY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0JNSTEpIHwKKyAgICAg
ICAgICAgICAgICAgIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9ITEUpICB8CiAgICAgICAgICAg
ICAgICAgICBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfQVZYMikgfAogICAgICAgICAgICAgICAg
ICAgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0JNSTIpIHwKICAgICAgICAgICAgICAgICAgIGNw
dWZlYXRfbWFzayhYODZfRkVBVFVSRV9FUk1TKSB8CisgICAgICAgICAgICAgICAgICBjcHVmZWF0
X21hc2soWDg2X0ZFQVRVUkVfUlRNKSAgfAogICAgICAgICAgICAgICAgICAgY3B1ZmVhdF9tYXNr
KFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIGIgPSAw
OwpkaWZmIC1yIDkyZTAzMzEwODc4ZiB4ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAot
LS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAlXZWQgRmViIDA4IDIxOjA1OjUy
IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgJTW9uIEZl
YiAyNyAwMjoyMzo0MiAyMDEyICswODAwCkBAIC0xNDksMTEgKzE0OSwxMyBAQAogLyogSW50ZWwt
ZGVmaW5lZCBDUFUgZmVhdHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MCAoZWJ4KSwgd29y
ZCA3ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0ZTR1NCQVNFCSg3KjMyKyAwKSAvKiB7UkQsV1J9
e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEJKDcq
MzIrIDMpIC8qIDFzdCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KKyNkZWZpbmUgWDg2
X0ZFQVRVUkVfSExFIAkoNyozMisgNCkgLyogSGFyZHdhcmUgTG9jayBFbGlzaW9uICovCiAjZGVm
aW5lIFg4Nl9GRUFUVVJFX0FWWDIJKDcqMzIrIDUpIC8qIEFWWDIgaW5zdHJ1Y3Rpb25zICovCiAj
ZGVmaW5lIFg4Nl9GRUFUVVJFX1NNRVAJKDcqMzIrIDcpIC8qIFN1cGVydmlzb3IgTW9kZSBFeGVj
dXRpb24gUHJvdGVjdGlvbiAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9CTUkyCSg3KjMyKyA4KSAv
KiAybmQgYml0IG1hbmlwdWxhdGlvbiBleHRlbnNpb25zICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJF
X0VSTVMJKDcqMzIrIDkpIC8qIEVuaGFuY2VkIFJFUCBNT1ZTQi9TVE9TQiAqLwogI2RlZmluZSBY
ODZfRkVBVFVSRV9JTlZQQ0lECSg3KjMyKzEwKSAvKiBJbnZhbGlkYXRlIFByb2Nlc3MgQ29udGV4
dCBJRCAqLworI2RlZmluZSBYODZfRkVBVFVSRV9SVE0gCSg3KjMyKzExKSAvKiBSZXN0cmljdGVk
IFRyYW5zYWN0aW9uYWwgTWVtb3J5ICovCiAKICNkZWZpbmUgY3B1X2hhcyhjLCBiaXQpCQl0ZXN0
X2JpdChiaXQsIChjKS0+eDg2X2NhcGFiaWxpdHkpCiAjZGVmaW5lIGJvb3RfY3B1X2hhcyhiaXQp
CXRlc3RfYml0KGJpdCwgYm9vdF9jcHVfZGF0YS54ODZfY2FwYWJpbGl0eSkK

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350B7B46SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Feb 28 05:13:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 05:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2FMp-0001Xf-MC; Tue, 28 Feb 2012 05:12:51 +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 1S2FMn-0001XZ-Gk
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 05:12:49 +0000
Received: from [85.158.139.83:19259] by server-8.bemta-5.messagelabs.com id
	70/35-09797-0526C4F4; Tue, 28 Feb 2012 05:12:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330405966!16976682!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNzQ2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2202 invoked from network); 28 Feb 2012 05:12:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-182.messagelabs.com with SMTP;
	28 Feb 2012 05:12:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Feb 2012 21:12:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="112484643"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2012 21:11:44 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:10:57 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:10:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Tue, 28 Feb 2012 13:10:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Patch] X86: expose HLE/RTM features to pv and hvm
Thread-Index: Acz111p5fwWKnMM8T56sMJIBOQQX7w==
Date: Tue, 28 Feb 2012 05:10:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B7B51@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_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [Patch] X86: expose HLE/RTM features to pv and 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose HLE/RTM features to pv and hvm

Intel recently release 2 new features, HLE and TRM.
Refer to http://software.intel.com/file/41417.
This patch expose them to pv and hvm

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 8174412310fa tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Mon Feb 27 02:23:43 2012 +0800
+++ b/tools/libxc/xc_cpufeature.h	Mon Feb 27 03:41:13 2012 +0800
@@ -129,10 +129,12 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
 #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 */
 #define X86_FEATURE_SMEP         7 /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2         8 /* 2nd group bit manipulation extension=
s */
 #define X86_FEATURE_ERMS         9 /* Enhanced REP MOVSB/STOSB */
 #define X86_FEATURE_INVPCID     10 /* Invalidate Process Context ID */
+#define X86_FEATURE_RTM         11 /* Restricted Transactional Memory */
=20
 #endif /* __LIBXC_CPUFEATURE_H */
diff -r 8174412310fa tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Mon Feb 27 02:23:43 2012 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Feb 27 03:41:13 2012 +0800
@@ -362,11 +362,13 @@
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
             regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_SMEP) |
                         bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
                         bitmaskof(X86_FEATURE_INVPCID) |
+                        bitmaskof(X86_FEATURE_RTM)  |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         } else
             regs[1] =3D 0;
@@ -495,9 +497,11 @@
     case 0x00000007:
         if ( input[1] =3D=3D 0 )
             regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
+                        bitmaskof(X86_FEATURE_RTM)  |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         else
             regs[1] =3D 0;=

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="expose_hlertm_for_pvhvm.patch"
Content-Description: expose_hlertm_for_pvhvm.patch
Content-Disposition: attachment; filename="expose_hlertm_for_pvhvm.patch";
	size=2519; creation-date="Tue, 28 Feb 2012 05:01:55 GMT";
	modification-date="Sun, 26 Feb 2012 20:17:22 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSExFL1JUTSBmZWF0dXJlcyB0byBwdiBhbmQgaHZtCgpJbnRlbCByZWNlbnRs
eSByZWxlYXNlIDIgbmV3IGZlYXR1cmVzLCBITEUgYW5kIFRSTS4KUmVmZXIgdG8gaHR0cDovL3Nv
ZnR3YXJlLmludGVsLmNvbS9maWxlLzQxNDE3LgpUaGlzIHBhdGNoIGV4cG9zZSB0aGVtIHRvIHB2
IGFuZCBodm0KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwu
Y29tPgoKZGlmZiAtciA4MTc0NDEyMzEwZmEgdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2NwdWZlYXR1cmUuaAlNb24gRmViIDI3IDAyOjIzOjQzIDIwMTIg
KzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCU1vbiBGZWIgMjcgMDM6NDE6
MTMgMjAxMiArMDgwMApAQCAtMTI5LDEwICsxMjksMTIgQEAKIC8qIEludGVsLWRlZmluZWQgQ1BV
IGZlYXR1cmVzLCBDUFVJRCBsZXZlbCAweDAwMDAwMDA3OjAgKGVieCkgKi8KICNkZWZpbmUgWDg2
X0ZFQVRVUkVfRlNHU0JBU0UgICAgIDAgLyoge1JELFdSfXtGUyxHU31CQVNFIGluc3RydWN0aW9u
cyAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9CTUkxICAgICAgICAgMyAvKiAxc3QgZ3JvdXAgYml0
IG1hbmlwdWxhdGlvbiBleHRlbnNpb25zICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0hMRSAgICAg
ICAgICA0IC8qIEhhcmR3YXJlIExvY2sgRWxpc2lvbiAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9B
VlgyICAgICAgICAgNSAvKiBBVlgyIGluc3RydWN0aW9ucyAqLwogI2RlZmluZSBYODZfRkVBVFVS
RV9TTUVQICAgICAgICAgNyAvKiBTdXBlcnZpc29yIE1vZGUgRXhlY3V0aW9uIFByb3RlY3Rpb24g
Ki8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfQk1JMiAgICAgICAgIDggLyogMm5kIGdyb3VwIGJpdCBt
YW5pcHVsYXRpb24gZXh0ZW5zaW9ucyAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9FUk1TICAgICAg
ICAgOSAvKiBFbmhhbmNlZCBSRVAgTU9WU0IvU1RPU0IgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVf
SU5WUENJRCAgICAgMTAgLyogSW52YWxpZGF0ZSBQcm9jZXNzIENvbnRleHQgSUQgKi8KKyNkZWZp
bmUgWDg2X0ZFQVRVUkVfUlRNICAgICAgICAgMTEgLyogUmVzdHJpY3RlZCBUcmFuc2FjdGlvbmFs
IE1lbW9yeSAqLwogCiAjZW5kaWYgLyogX19MSUJYQ19DUFVGRUFUVVJFX0ggKi8KZGlmZiAtciA4
MTc0NDEyMzEwZmEgdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMKLS0tIGEvdG9vbHMvbGlieGMv
eGNfY3B1aWRfeDg2LmMJTW9uIEZlYiAyNyAwMjoyMzo0MyAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2NwdWlkX3g4Ni5jCU1vbiBGZWIgMjcgMDM6NDE6MTMgMjAxMiArMDgwMApAQCAt
MzYyLDExICszNjIsMTMgQEAKICAgICBjYXNlIDB4MDAwMDAwMDc6IC8qIEludGVsLWRlZmluZWQg
Q1BVIGZlYXR1cmVzICovCiAgICAgICAgIGlmICggaW5wdXRbMV0gPT0gMCApIHsKICAgICAgICAg
ICAgIHJlZ3NbMV0gJj0gKGJpdG1hc2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CisgICAgICAgICAg
ICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSExFKSAgfAogICAgICAgICAgICAg
ICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKICAgICAgICAgICAgICAg
ICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9TTUVQKSB8CiAgICAgICAgICAgICAgICAg
ICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQk1JMikgfAogICAgICAgICAgICAgICAgICAg
ICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0VSTVMpIHwKICAgICAgICAgICAgICAgICAgICAg
ICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9JTlZQQ0lEKSB8CisgICAgICAgICAgICAgICAgICAg
ICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfUlRNKSAgfAogICAgICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIH0gZWxzZQogICAg
ICAgICAgICAgcmVnc1sxXSA9IDA7CkBAIC00OTUsOSArNDk3LDExIEBACiAgICAgY2FzZSAweDAw
MDAwMDA3OgogICAgICAgICBpZiAoIGlucHV0WzFdID09IDAgKQogICAgICAgICAgICAgcmVnc1sx
XSAmPSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX0JNSTEpIHwKKyAgICAgICAgICAgICAgICAgICAg
ICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9ITEUpICB8CiAgICAgICAgICAgICAgICAgICAgICAg
ICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQVZYMikgfAogICAgICAgICAgICAgICAgICAgICAgICAg
Yml0bWFza29mKFg4Nl9GRUFUVVJFX0JNSTIpIHwKICAgICAgICAgICAgICAgICAgICAgICAgIGJp
dG1hc2tvZihYODZfRkVBVFVSRV9FUk1TKSB8CisgICAgICAgICAgICAgICAgICAgICAgICBiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfUlRNKSAgfAogICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFz
a29mKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJl
Z3NbMV0gPSAwOwo=

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Feb 28 05:13:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 05:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2FMp-0001Xf-MC; Tue, 28 Feb 2012 05:12:51 +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 1S2FMn-0001XZ-Gk
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 05:12:49 +0000
Received: from [85.158.139.83:19259] by server-8.bemta-5.messagelabs.com id
	70/35-09797-0526C4F4; Tue, 28 Feb 2012 05:12:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330405966!16976682!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwNzQ2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2202 invoked from network); 28 Feb 2012 05:12:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-182.messagelabs.com with SMTP;
	28 Feb 2012 05:12:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Feb 2012 21:12:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="112484643"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2012 21:11:44 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:10:57 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 28 Feb 2012 13:10:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Tue, 28 Feb 2012 13:10:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Patch] X86: expose HLE/RTM features to pv and hvm
Thread-Index: Acz111p5fwWKnMM8T56sMJIBOQQX7w==
Date: Tue, 28 Feb 2012 05:10:55 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B7B51@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_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir.xen@gmail.com" <keir.xen@gmail.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [Patch] X86: expose HLE/RTM features to pv and 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose HLE/RTM features to pv and hvm

Intel recently release 2 new features, HLE and TRM.
Refer to http://software.intel.com/file/41417.
This patch expose them to pv and hvm

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 8174412310fa tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Mon Feb 27 02:23:43 2012 +0800
+++ b/tools/libxc/xc_cpufeature.h	Mon Feb 27 03:41:13 2012 +0800
@@ -129,10 +129,12 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
 #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 */
 #define X86_FEATURE_SMEP         7 /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2         8 /* 2nd group bit manipulation extension=
s */
 #define X86_FEATURE_ERMS         9 /* Enhanced REP MOVSB/STOSB */
 #define X86_FEATURE_INVPCID     10 /* Invalidate Process Context ID */
+#define X86_FEATURE_RTM         11 /* Restricted Transactional Memory */
=20
 #endif /* __LIBXC_CPUFEATURE_H */
diff -r 8174412310fa tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Mon Feb 27 02:23:43 2012 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Feb 27 03:41:13 2012 +0800
@@ -362,11 +362,13 @@
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
             regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_SMEP) |
                         bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
                         bitmaskof(X86_FEATURE_INVPCID) |
+                        bitmaskof(X86_FEATURE_RTM)  |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         } else
             regs[1] =3D 0;
@@ -495,9 +497,11 @@
     case 0x00000007:
         if ( input[1] =3D=3D 0 )
             regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
+                        bitmaskof(X86_FEATURE_RTM)  |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         else
             regs[1] =3D 0;=

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="expose_hlertm_for_pvhvm.patch"
Content-Description: expose_hlertm_for_pvhvm.patch
Content-Disposition: attachment; filename="expose_hlertm_for_pvhvm.patch";
	size=2519; creation-date="Tue, 28 Feb 2012 05:01:55 GMT";
	modification-date="Sun, 26 Feb 2012 20:17:22 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSExFL1JUTSBmZWF0dXJlcyB0byBwdiBhbmQgaHZtCgpJbnRlbCByZWNlbnRs
eSByZWxlYXNlIDIgbmV3IGZlYXR1cmVzLCBITEUgYW5kIFRSTS4KUmVmZXIgdG8gaHR0cDovL3Nv
ZnR3YXJlLmludGVsLmNvbS9maWxlLzQxNDE3LgpUaGlzIHBhdGNoIGV4cG9zZSB0aGVtIHRvIHB2
IGFuZCBodm0KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwu
Y29tPgoKZGlmZiAtciA4MTc0NDEyMzEwZmEgdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2NwdWZlYXR1cmUuaAlNb24gRmViIDI3IDAyOjIzOjQzIDIwMTIg
KzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCU1vbiBGZWIgMjcgMDM6NDE6
MTMgMjAxMiArMDgwMApAQCAtMTI5LDEwICsxMjksMTIgQEAKIC8qIEludGVsLWRlZmluZWQgQ1BV
IGZlYXR1cmVzLCBDUFVJRCBsZXZlbCAweDAwMDAwMDA3OjAgKGVieCkgKi8KICNkZWZpbmUgWDg2
X0ZFQVRVUkVfRlNHU0JBU0UgICAgIDAgLyoge1JELFdSfXtGUyxHU31CQVNFIGluc3RydWN0aW9u
cyAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9CTUkxICAgICAgICAgMyAvKiAxc3QgZ3JvdXAgYml0
IG1hbmlwdWxhdGlvbiBleHRlbnNpb25zICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0hMRSAgICAg
ICAgICA0IC8qIEhhcmR3YXJlIExvY2sgRWxpc2lvbiAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9B
VlgyICAgICAgICAgNSAvKiBBVlgyIGluc3RydWN0aW9ucyAqLwogI2RlZmluZSBYODZfRkVBVFVS
RV9TTUVQICAgICAgICAgNyAvKiBTdXBlcnZpc29yIE1vZGUgRXhlY3V0aW9uIFByb3RlY3Rpb24g
Ki8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfQk1JMiAgICAgICAgIDggLyogMm5kIGdyb3VwIGJpdCBt
YW5pcHVsYXRpb24gZXh0ZW5zaW9ucyAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9FUk1TICAgICAg
ICAgOSAvKiBFbmhhbmNlZCBSRVAgTU9WU0IvU1RPU0IgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVf
SU5WUENJRCAgICAgMTAgLyogSW52YWxpZGF0ZSBQcm9jZXNzIENvbnRleHQgSUQgKi8KKyNkZWZp
bmUgWDg2X0ZFQVRVUkVfUlRNICAgICAgICAgMTEgLyogUmVzdHJpY3RlZCBUcmFuc2FjdGlvbmFs
IE1lbW9yeSAqLwogCiAjZW5kaWYgLyogX19MSUJYQ19DUFVGRUFUVVJFX0ggKi8KZGlmZiAtciA4
MTc0NDEyMzEwZmEgdG9vbHMvbGlieGMveGNfY3B1aWRfeDg2LmMKLS0tIGEvdG9vbHMvbGlieGMv
eGNfY3B1aWRfeDg2LmMJTW9uIEZlYiAyNyAwMjoyMzo0MyAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2NwdWlkX3g4Ni5jCU1vbiBGZWIgMjcgMDM6NDE6MTMgMjAxMiArMDgwMApAQCAt
MzYyLDExICszNjIsMTMgQEAKICAgICBjYXNlIDB4MDAwMDAwMDc6IC8qIEludGVsLWRlZmluZWQg
Q1BVIGZlYXR1cmVzICovCiAgICAgICAgIGlmICggaW5wdXRbMV0gPT0gMCApIHsKICAgICAgICAg
ICAgIHJlZ3NbMV0gJj0gKGJpdG1hc2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CisgICAgICAgICAg
ICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSExFKSAgfAogICAgICAgICAgICAg
ICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKICAgICAgICAgICAgICAg
ICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9TTUVQKSB8CiAgICAgICAgICAgICAgICAg
ICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQk1JMikgfAogICAgICAgICAgICAgICAgICAg
ICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0VSTVMpIHwKICAgICAgICAgICAgICAgICAgICAg
ICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9JTlZQQ0lEKSB8CisgICAgICAgICAgICAgICAgICAg
ICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfUlRNKSAgfAogICAgICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIH0gZWxzZQogICAg
ICAgICAgICAgcmVnc1sxXSA9IDA7CkBAIC00OTUsOSArNDk3LDExIEBACiAgICAgY2FzZSAweDAw
MDAwMDA3OgogICAgICAgICBpZiAoIGlucHV0WzFdID09IDAgKQogICAgICAgICAgICAgcmVnc1sx
XSAmPSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX0JNSTEpIHwKKyAgICAgICAgICAgICAgICAgICAg
ICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9ITEUpICB8CiAgICAgICAgICAgICAgICAgICAgICAg
ICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQVZYMikgfAogICAgICAgICAgICAgICAgICAgICAgICAg
Yml0bWFza29mKFg4Nl9GRUFUVVJFX0JNSTIpIHwKICAgICAgICAgICAgICAgICAgICAgICAgIGJp
dG1hc2tvZihYODZfRkVBVFVSRV9FUk1TKSB8CisgICAgICAgICAgICAgICAgICAgICAgICBiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfUlRNKSAgfAogICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFz
a29mKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJl
Z3NbMV0gPSAwOwo=

--_002_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350B7B51SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Feb 28 06:37:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 06: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 1S2Gfp-0001yv-55; Tue, 28 Feb 2012 06: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 1S2Gfn-0001yq-6M
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 06:36:31 +0000
Received: from [85.158.139.83:18835] by server-4.bemta-5.messagelabs.com id
	B3/96-10788-EE57C4F4; Tue, 28 Feb 2012 06:36:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330410989!16427250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21465 invoked from network); 28 Feb 2012 06:36:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 06:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,494,1325462400"; d="scan'208";a="10970358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 06:36:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 06:36:00 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2GfI-0003uq-61;
	Tue, 28 Feb 2012 06:36:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2GfI-0005Wh-4r;
	Tue, 28 Feb 2012 06:36:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12099-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 06:36:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12099: 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 12099 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12099/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-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
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  a7bacdc5449a
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@citrix.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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a7bacdc5449a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a7bacdc5449a
+ branch=xen-unstable
+ revision=a7bacdc5449a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a7bacdc5449a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 23 changesets with 55 changes to 43 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 06:37:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 06: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 1S2Gfp-0001yv-55; Tue, 28 Feb 2012 06: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 1S2Gfn-0001yq-6M
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 06:36:31 +0000
Received: from [85.158.139.83:18835] by server-4.bemta-5.messagelabs.com id
	B3/96-10788-EE57C4F4; Tue, 28 Feb 2012 06:36:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330410989!16427250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21465 invoked from network); 28 Feb 2012 06:36:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 06:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.73,494,1325462400"; d="scan'208";a="10970358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 06:36:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 06:36:00 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2GfI-0003uq-61;
	Tue, 28 Feb 2012 06:36:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2GfI-0005Wh-4r;
	Tue, 28 Feb 2012 06:36:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12099-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 06:36:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12099: 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 12099 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12099/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12031
 test-i386-i386-win           14 guest-start.2                fail   like 12031

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-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
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  a7bacdc5449a
baseline version:
 xen                  a4d93d0e0df2

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Attilio Rao <attilio.rao@citrix.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>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Justin T. Gibbs <justing@spectralogic.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a7bacdc5449a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a7bacdc5449a
+ branch=xen-unstable
+ revision=a7bacdc5449a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : xen@xenbits.xensource.com:git/linux-pvops
++ : 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
++ : xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a7bacdc5449a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 23 changesets with 55 changes to 43 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 06:54:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 06:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Gwd-0002xz-JR; Tue, 28 Feb 2012 06:53:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidxu06@gmail.com>) id 1S2Gwc-0002xu-QT
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 06:53:55 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330412027!15206080!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26167 invoked from network); 28 Feb 2012 06:53:48 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 06:53:48 -0000
Received: by vcbf11 with SMTP id f11so1409346vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 22:53:47 -0800 (PST)
Received-SPF: pass (google.com: domain of davidxu06@gmail.com designates
	10.52.91.18 as permitted sender) client-ip=10.52.91.18; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of davidxu06@gmail.com
	designates 10.52.91.18 as permitted sender)
	smtp.mail=davidxu06@gmail.com;
	dkim=pass header.i=davidxu06@gmail.com
Received: from mr.google.com ([10.52.91.18])
	by 10.52.91.18 with SMTP id ca18mr10863943vdb.101.1330412027224
	(num_hops = 1); Mon, 27 Feb 2012 22:53:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=pMWSmV7R6AU9tvDwjeK2HL6VauVVOm3bAt4ORlvL4WI=;
	b=c8265bNrrTj8NhzSUMlYHIKpxB4RR3rzeA8y3oLysGR+oydpPTTIA3GRSGbk1foZQU
	YHbhw2wkBu0ZJcHCOTH51aoNfopfhBRr0CiSiHfCDfG/SQNL/SIxXNaxnN1B50voBEFn
	T9+Xf2CYVi8H/SWQzMhmUKAcVekzdigvml5PA=
MIME-Version: 1.0
Received: by 10.52.91.18 with SMTP id ca18mr8905400vdb.101.1330412027190; Mon,
	27 Feb 2012 22:53:47 -0800 (PST)
Received: by 10.52.28.226 with HTTP; Mon, 27 Feb 2012 22:53:47 -0800 (PST)
Date: Tue, 28 Feb 2012 01:53:47 -0500
Message-ID: <CAGjowiTZ-KQLavVO0XTQrYbpN=EfHiJo2oBQv4GOgB-agCY-uw@mail.gmail.com>
From: David Xu <davidxu06@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] how to get the information of memory usage of a VM from
	hypervisor or dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I wonder if I can know which VM runs a memory-intensive application?
Is there a tool or method to get the information of memory usage of a
VM from hypervisor or dom0? Thanks.

Regards,
Cong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 06:54:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 06:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Gwd-0002xz-JR; Tue, 28 Feb 2012 06:53:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidxu06@gmail.com>) id 1S2Gwc-0002xu-QT
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 06:53:55 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330412027!15206080!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26167 invoked from network); 28 Feb 2012 06:53:48 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 06:53:48 -0000
Received: by vcbf11 with SMTP id f11so1409346vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 27 Feb 2012 22:53:47 -0800 (PST)
Received-SPF: pass (google.com: domain of davidxu06@gmail.com designates
	10.52.91.18 as permitted sender) client-ip=10.52.91.18; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of davidxu06@gmail.com
	designates 10.52.91.18 as permitted sender)
	smtp.mail=davidxu06@gmail.com;
	dkim=pass header.i=davidxu06@gmail.com
Received: from mr.google.com ([10.52.91.18])
	by 10.52.91.18 with SMTP id ca18mr10863943vdb.101.1330412027224
	(num_hops = 1); Mon, 27 Feb 2012 22:53:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=pMWSmV7R6AU9tvDwjeK2HL6VauVVOm3bAt4ORlvL4WI=;
	b=c8265bNrrTj8NhzSUMlYHIKpxB4RR3rzeA8y3oLysGR+oydpPTTIA3GRSGbk1foZQU
	YHbhw2wkBu0ZJcHCOTH51aoNfopfhBRr0CiSiHfCDfG/SQNL/SIxXNaxnN1B50voBEFn
	T9+Xf2CYVi8H/SWQzMhmUKAcVekzdigvml5PA=
MIME-Version: 1.0
Received: by 10.52.91.18 with SMTP id ca18mr8905400vdb.101.1330412027190; Mon,
	27 Feb 2012 22:53:47 -0800 (PST)
Received: by 10.52.28.226 with HTTP; Mon, 27 Feb 2012 22:53:47 -0800 (PST)
Date: Tue, 28 Feb 2012 01:53:47 -0500
Message-ID: <CAGjowiTZ-KQLavVO0XTQrYbpN=EfHiJo2oBQv4GOgB-agCY-uw@mail.gmail.com>
From: David Xu <davidxu06@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] how to get the information of memory usage of a VM from
	hypervisor or dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I wonder if I can know which VM runs a memory-intensive application?
Is there a tool or method to get the information of memory usage of a
VM from hypervisor or dom0? Thanks.

Regards,
Cong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 07:29:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 07:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2HUx-0003MG-Er; Tue, 28 Feb 2012 07:29:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1S2HUv-0003MB-Jh
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 07:29:21 +0000
X-Env-Sender: wang_nets@163.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330414127!58598254!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16590 invoked from network); 28 Feb 2012 07:28:48 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2012 07:28:48 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1S2HUs-0006gM-CK
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:29:18 -0800
Date: Mon, 27 Feb 2012 23:29:18 -0800 (PST)
From: SuperWong <wang_nets@163.com>
To: xen-devel@lists.xensource.com
Message-ID: <1330414158371-5521071.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Attempted to call hypercall from userspace failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgQUxMOgogIEkgYW0gYSBub3ZpY2UsSSBoYXZlIGF0dGVtcHRlZCB0byBjYWxsIGh5cGVyY2Fs
bCBmcm9tIHVzZXJzcGFjZS5JdCdzCmZhaWxlZC4KICBNeSBPUyBpcyBGZWRvcmEgMTYoNjRiaXQp
IC4KICBGaXJzdCxJIGhhdmUgY3JlYXRlZCBhIG5ldyBoeXBlcmNhbGwuIAogICp4ZW4vaW5jbHVk
ZS9wdWJsaWMqCiAgI2RlZmluZSBfX0hZUEVSVklTT1JfdG1lbV9vcCAgICAgICAgICAgICAgMzgK
ICAjZGVmaW5lIF9fSFlQRVJWSVNPUl9wcmludF9zdHJpbmcgICAgICAgICAgIDM5LypuZXcgYWRk
aXRpb24qLwogIAogICp4ZW4vYXJjaC94ODYveDg2XzY0KgogIEVOVFJZKGh5cGVyY2FsbF90YWJs
ZSkK4oCmCiAgICAucXVhZCAgZG9fdG1lbV9vcAogICAgLnF1YWQgIGRvX3ByaW50X3N0cmluZwri
gKYKICBFTlRSWShoeXBlcmNhbGxfYXJnc190YWJsZSkKICAgIC5ieXRlIDEgLyogZG9fdG1lbV9v
cCAgKi8KICAgIC5ieXRlIDEgLyogZG9fcHJpbnRfc3RyaW5nICAqLwoKICAqWGVuL2luY2x1ZGUv
YXNtLXg4Ni9oeXBlcmNhbGwuaCoKICAjaWZkZWYgIF9feDg2XzY0X18KICDigKYKICBleHRlcm4g
aW50CiAgZG9fcHJpbnRfc3RyaW5nKAogICAgICAgICBjaGFyKiBtZXNzYWdlKTsKICAjZWxzZQoK
ICAqeGVuL2FyY2gveDg2L21tLmMqCiAgaW50IGRvX3ByaW50X3N0cmluZyhjaGFyICptZXNzYWdl
KQp7CiAgI2lmZGVmIF9feDg2XzY0X18KICBpZihtZXNzYWdlKQogICAgcHJpbnRrKOKAnE1FU1NB
R0UoeDg2XzY0OiVzXG4p4oCdLG1lc3NhZ2UpOwogIGVsc2UKICAgIHByaW50ayjigJxNRVNTQUdF
KHg4Nl82NCk6Tm90aGluZyBPdXRwdXQh4oCdKTsKICAjZW5kaWYKICAgIGlmKG1lc3NhZ2UpCiAg
ICBQcmludGso4oCcTUVTU0FHRSh4ODZfMzI6JXNcbinigJ0sbWVzc2FnZSk7CiAgZWxzZQogICAg
cHJpbnRrKOKAnE1FU1NBR0UoeDg2XzMyKTpOb3RoaW5nIE91dHB1dCHigJ0pOwogICAgcmV0dXJu
IDE7Cn0KCmh5cGVyY2FsbC5jCmludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pICAKeyAg
CiAgICBpbnQgZmQsIHJldDsgIAogICBjaGFyICogbWVzc2FnZTsgIAogICAgaWYgKGFyZ2MgIT0g
MikgeyAgCiAgICAgICAgcHJpbnRmKCJwbGVhc2UgcHV0IG9uZSBwYXJhbWV0ZXIhL24iKTsgIAog
ICAgICAgIHJldHVybiAtMTsgIAogICAgfSAgCiAgIG1lc3NhZ2UgPSAoY2hhciAqKSBtYWxsb2Mo
c2l6ZW9mKGNoYXIpICogKHN0cmxlbihhcmd2WzFdKSsxKSk7ICAKICAgc3RyY3B5KG1lc3NhZ2Us
IGFyZ3ZbMV0pOyAgCiAgICBwcml2Y21kX2h5cGVyY2FsbF90IGhjYWxsID0geyAgCiAgICAgICAg
X19IWVBFUlZJU09SX3ByaW50X3N0cmluZywgIAogICAgICAgIHttZXNzYWdlLCAwLCAwLCAwLCAw
fSAgCiAgICB9OyAgCiAgICBmZCA9IG9wZW4oIi9wcm9jL3hlbi9wcml2Y21kIiwgT19SRFdSKTsg
IAogICAgaWYgKGZkIDwgMCkgeyAgCiAgICAgICAgcGVycm9yKCJvcGVuIik7ICAKICAgICAgICBl
eGl0KDEpOyAgCiAgICB9IGVsc2UgIAogICAgICAgIHByaW50ZigiZmQgPSAlZC9uIiwgZmQpOyAg
CiAgICByZXQgPSBpb2N0bChmZCwgSU9DVExfUFJJVkNNRF9IWVBFUkNBTEwsICZoY2FsbCk7ICAK
ICAgIHByaW50ZigicmV0ID0gJWQvbiIsIHJldCk7ICAKfSAgCldoZW4gSSBleGVjdXRlZCAuL2Eu
b3V0IEhlbGxvX3dvcmxkLGZkPTMgYW5kIHJldD0tMS5JdCdzIGZhaWxlZC5PZiBjb3Vyc2UKdGhl
IGNvbW1hbmQgeG0gZG1lc2cgcHJpbnRlZCBub3RoaW5nLlBsZWFzZSB0ZWxsIG1lIHdoZXJlIGlz
IHdyb25nLlRoYW5rcy4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94
ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL0F0dGVtcHRlZC10by1jYWxsLWh5cGVyY2FsbC1mcm9t
LXVzZXJzcGFjZS1mYWlsZWQtdHA1NTIxMDcxcDU1MjEwNzEuaHRtbApTZW50IGZyb20gdGhlIFhl
biAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 28 07:29:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 07:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2HUx-0003MG-Er; Tue, 28 Feb 2012 07:29:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1S2HUv-0003MB-Jh
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 07:29:21 +0000
X-Env-Sender: wang_nets@163.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330414127!58598254!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16590 invoked from network); 28 Feb 2012 07:28:48 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2012 07:28:48 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <wang_nets@163.com>) id 1S2HUs-0006gM-CK
	for xen-devel@lists.xensource.com; Mon, 27 Feb 2012 23:29:18 -0800
Date: Mon, 27 Feb 2012 23:29:18 -0800 (PST)
From: SuperWong <wang_nets@163.com>
To: xen-devel@lists.xensource.com
Message-ID: <1330414158371-5521071.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Attempted to call hypercall from userspace failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgQUxMOgogIEkgYW0gYSBub3ZpY2UsSSBoYXZlIGF0dGVtcHRlZCB0byBjYWxsIGh5cGVyY2Fs
bCBmcm9tIHVzZXJzcGFjZS5JdCdzCmZhaWxlZC4KICBNeSBPUyBpcyBGZWRvcmEgMTYoNjRiaXQp
IC4KICBGaXJzdCxJIGhhdmUgY3JlYXRlZCBhIG5ldyBoeXBlcmNhbGwuIAogICp4ZW4vaW5jbHVk
ZS9wdWJsaWMqCiAgI2RlZmluZSBfX0hZUEVSVklTT1JfdG1lbV9vcCAgICAgICAgICAgICAgMzgK
ICAjZGVmaW5lIF9fSFlQRVJWSVNPUl9wcmludF9zdHJpbmcgICAgICAgICAgIDM5LypuZXcgYWRk
aXRpb24qLwogIAogICp4ZW4vYXJjaC94ODYveDg2XzY0KgogIEVOVFJZKGh5cGVyY2FsbF90YWJs
ZSkK4oCmCiAgICAucXVhZCAgZG9fdG1lbV9vcAogICAgLnF1YWQgIGRvX3ByaW50X3N0cmluZwri
gKYKICBFTlRSWShoeXBlcmNhbGxfYXJnc190YWJsZSkKICAgIC5ieXRlIDEgLyogZG9fdG1lbV9v
cCAgKi8KICAgIC5ieXRlIDEgLyogZG9fcHJpbnRfc3RyaW5nICAqLwoKICAqWGVuL2luY2x1ZGUv
YXNtLXg4Ni9oeXBlcmNhbGwuaCoKICAjaWZkZWYgIF9feDg2XzY0X18KICDigKYKICBleHRlcm4g
aW50CiAgZG9fcHJpbnRfc3RyaW5nKAogICAgICAgICBjaGFyKiBtZXNzYWdlKTsKICAjZWxzZQoK
ICAqeGVuL2FyY2gveDg2L21tLmMqCiAgaW50IGRvX3ByaW50X3N0cmluZyhjaGFyICptZXNzYWdl
KQp7CiAgI2lmZGVmIF9feDg2XzY0X18KICBpZihtZXNzYWdlKQogICAgcHJpbnRrKOKAnE1FU1NB
R0UoeDg2XzY0OiVzXG4p4oCdLG1lc3NhZ2UpOwogIGVsc2UKICAgIHByaW50ayjigJxNRVNTQUdF
KHg4Nl82NCk6Tm90aGluZyBPdXRwdXQh4oCdKTsKICAjZW5kaWYKICAgIGlmKG1lc3NhZ2UpCiAg
ICBQcmludGso4oCcTUVTU0FHRSh4ODZfMzI6JXNcbinigJ0sbWVzc2FnZSk7CiAgZWxzZQogICAg
cHJpbnRrKOKAnE1FU1NBR0UoeDg2XzMyKTpOb3RoaW5nIE91dHB1dCHigJ0pOwogICAgcmV0dXJu
IDE7Cn0KCmh5cGVyY2FsbC5jCmludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pICAKeyAg
CiAgICBpbnQgZmQsIHJldDsgIAogICBjaGFyICogbWVzc2FnZTsgIAogICAgaWYgKGFyZ2MgIT0g
MikgeyAgCiAgICAgICAgcHJpbnRmKCJwbGVhc2UgcHV0IG9uZSBwYXJhbWV0ZXIhL24iKTsgIAog
ICAgICAgIHJldHVybiAtMTsgIAogICAgfSAgCiAgIG1lc3NhZ2UgPSAoY2hhciAqKSBtYWxsb2Mo
c2l6ZW9mKGNoYXIpICogKHN0cmxlbihhcmd2WzFdKSsxKSk7ICAKICAgc3RyY3B5KG1lc3NhZ2Us
IGFyZ3ZbMV0pOyAgCiAgICBwcml2Y21kX2h5cGVyY2FsbF90IGhjYWxsID0geyAgCiAgICAgICAg
X19IWVBFUlZJU09SX3ByaW50X3N0cmluZywgIAogICAgICAgIHttZXNzYWdlLCAwLCAwLCAwLCAw
fSAgCiAgICB9OyAgCiAgICBmZCA9IG9wZW4oIi9wcm9jL3hlbi9wcml2Y21kIiwgT19SRFdSKTsg
IAogICAgaWYgKGZkIDwgMCkgeyAgCiAgICAgICAgcGVycm9yKCJvcGVuIik7ICAKICAgICAgICBl
eGl0KDEpOyAgCiAgICB9IGVsc2UgIAogICAgICAgIHByaW50ZigiZmQgPSAlZC9uIiwgZmQpOyAg
CiAgICByZXQgPSBpb2N0bChmZCwgSU9DVExfUFJJVkNNRF9IWVBFUkNBTEwsICZoY2FsbCk7ICAK
ICAgIHByaW50ZigicmV0ID0gJWQvbiIsIHJldCk7ICAKfSAgCldoZW4gSSBleGVjdXRlZCAuL2Eu
b3V0IEhlbGxvX3dvcmxkLGZkPTMgYW5kIHJldD0tMS5JdCdzIGZhaWxlZC5PZiBjb3Vyc2UKdGhl
IGNvbW1hbmQgeG0gZG1lc2cgcHJpbnRlZCBub3RoaW5nLlBsZWFzZSB0ZWxsIG1lIHdoZXJlIGlz
IHdyb25nLlRoYW5rcy4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94
ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL0F0dGVtcHRlZC10by1jYWxsLWh5cGVyY2FsbC1mcm9t
LXVzZXJzcGFjZS1mYWlsZWQtdHA1NTIxMDcxcDU1MjEwNzEuaHRtbApTZW50IGZyb20gdGhlIFhl
biAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 28 08:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08: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 1S2IA6-0004P5-DG; Tue, 28 Feb 2012 08:11:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2IA5-0004Ov-LT
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 08:11:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330416707!3926029!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12998 invoked from network); 28 Feb 2012 08:11:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 08:11:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 08:11:46 +0000
Message-Id: <4F4C9A7702000078000751B9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 08:12:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 06:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86: expose HLE/RTM features to dom0
> 
> Intel recently release 2 new features, HLE and TRM.
> Refer to http://software.intel.com/file/41417.
> This patch expose them to dom0.

While I committed this as obviously correct and desirable, I wonder
what plans you have with this feature wrt
- permitting use for HVM guests
- permitting use in pv DomU
- actual use in the hypervisor itself
- use in Linux (afaict impossible at least for HLE with ticket locks, yet
  HLE is certainly the more desirable first step)

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 Feb 28 08:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08: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 1S2IA6-0004P5-DG; Tue, 28 Feb 2012 08:11:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2IA5-0004Ov-LT
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 08:11:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330416707!3926029!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12998 invoked from network); 28 Feb 2012 08:11:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 08:11:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 08:11:46 +0000
Message-Id: <4F4C9A7702000078000751B9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 08:12:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 06:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86: expose HLE/RTM features to dom0
> 
> Intel recently release 2 new features, HLE and TRM.
> Refer to http://software.intel.com/file/41417.
> This patch expose them to dom0.

While I committed this as obviously correct and desirable, I wonder
what plans you have with this feature wrt
- permitting use for HVM guests
- permitting use in pv DomU
- actual use in the hypervisor itself
- use in Linux (afaict impossible at least for HLE with ticket locks, yet
  HLE is certainly the more desirable first step)

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 Feb 28 08:26:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2INF-0004sy-Me; Tue, 28 Feb 2012 08:25:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2INE-0004sk-2w
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 08:25:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330417521!10088194!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16909 invoked from network); 28 Feb 2012 08:25:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 08:25:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 08:25:21 +0000
Message-Id: <4F4C9DA702000078000751D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 08:25:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
	<4F4C9A7702000078000751B9@nat28.tlf.novell.com>
In-Reply-To: <4F4C9A7702000078000751B9@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 09:12, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 28.02.12 at 06:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> X86: expose HLE/RTM features to dom0
>> 
>> Intel recently release 2 new features, HLE and TRM.
>> Refer to http://software.intel.com/file/41417.
>> This patch expose them to dom0.
> 
> While I committed this as obviously correct and desirable, I wonder
> what plans you have with this feature wrt
> - permitting use for HVM guests
> - permitting use in pv DomU

Just saw that you already sent a patch to that effect (albeit to IanC
instead of IanJ).

Jan

> - actual use in the hypervisor itself
> - use in Linux (afaict impossible at least for HLE with ticket locks, yet
>   HLE is certainly the more desirable first step)
> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 08:26:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2INF-0004sy-Me; Tue, 28 Feb 2012 08:25:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2INE-0004sk-2w
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 08:25:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330417521!10088194!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16909 invoked from network); 28 Feb 2012 08:25:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 08:25:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 08:25:21 +0000
Message-Id: <4F4C9DA702000078000751D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 08:25:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
	<4F4C9A7702000078000751B9@nat28.tlf.novell.com>
In-Reply-To: <4F4C9A7702000078000751B9@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 09:12, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 28.02.12 at 06:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> X86: expose HLE/RTM features to dom0
>> 
>> Intel recently release 2 new features, HLE and TRM.
>> Refer to http://software.intel.com/file/41417.
>> This patch expose them to dom0.
> 
> While I committed this as obviously correct and desirable, I wonder
> what plans you have with this feature wrt
> - permitting use for HVM guests
> - permitting use in pv DomU

Just saw that you already sent a patch to that effect (albeit to IanC
instead of IanJ).

Jan

> - actual use in the hypervisor itself
> - use in Linux (afaict impossible at least for HLE with ticket locks, yet
>   HLE is certainly the more desirable first step)
> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 08:27:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2IOR-0004wn-59; Tue, 28 Feb 2012 08:26:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2IOP-0004wS-Rd
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 08:26:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330417595!3928456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1126 invoked from network); 28 Feb 2012 08:26:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 08:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10972133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 08:26:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 08:26:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2INk-0004rJ-Pb;
	Tue, 28 Feb 2012 08:26:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2INk-0001u4-ID;
	Tue, 28 Feb 2012 08:26:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12101-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 08:26:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12101: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12101 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12101/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 11770

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 08:27:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2IOR-0004wn-59; Tue, 28 Feb 2012 08:26:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2IOP-0004wS-Rd
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 08:26:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1330417595!3928456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTYyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1126 invoked from network); 28 Feb 2012 08:26:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 08:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10972133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 08:26:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 08:26:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2INk-0004rJ-Pb;
	Tue, 28 Feb 2012 08:26:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2INk-0001u4-ID;
	Tue, 28 Feb 2012 08:26:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12101-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 08:26:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12101: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12101 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12101/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 11770

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 08:41:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Icr-0005Cs-IQ; Tue, 28 Feb 2012 08:41:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2Icp-0005Cn-B9
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 08:41:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330418489!17216591!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14134 invoked from network); 28 Feb 2012 08:41:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 08:41:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 08:41:28 +0000
Message-Id: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 08:42:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Ian,

with these I'm getting the impression we're making it, just like for qemu,
a requirement to use the xenbits mirror rather than the original as well,
even more so given that the two post-1.6.3.1 commits the mirror now
has don't even exist in the upstream tree (yet), making this not even a
mirror anymore.

I really had hoped that we would bring down (rather than up) the
number of private clones of upstream trees, and provide true mirrors
on xenbits really just for developers' convenience. Any word on the
overall picture?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 08:41:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 08:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Icr-0005Cs-IQ; Tue, 28 Feb 2012 08:41:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2Icp-0005Cn-B9
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 08:41:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330418489!17216591!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14134 invoked from network); 28 Feb 2012 08:41:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 08:41:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 08:41:28 +0000
Message-Id: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 08:42:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Ian,

with these I'm getting the impression we're making it, just like for qemu,
a requirement to use the xenbits mirror rather than the original as well,
even more so given that the two post-1.6.3.1 commits the mirror now
has don't even exist in the upstream tree (yet), making this not even a
mirror anymore.

I really had hoped that we would bring down (rather than up) the
number of private clones of upstream trees, and provide true mirrors
on xenbits really just for developers' convenience. Any word on the
overall picture?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 09:29:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09: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 1S2JMJ-0005Vm-J6; Tue, 28 Feb 2012 09:28:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2JMI-0005Vd-1m
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 09:28:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330421308!16702250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12441 invoked from network); 28 Feb 2012 09:28:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 09:28:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10975378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 09:28:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 09:28:27 +0000
Message-ID: <1330421306.31269.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 28 Feb 2012 09:28:26 +0000
In-Reply-To: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
> Hi Ian,
> 
> with these I'm getting the impression we're making it, just like for qemu,
> a requirement to use the xenbits mirror rather than the original as well,
> even more so given that the two post-1.6.3.1 commits the mirror now
> has don't even exist in the upstream tree (yet), making this not even a
> mirror anymore.

I cherry picked both of those commits directly from the mainline SeaBIOS
tree, so they are upstream.

> I really had hoped that we would bring down (rather than up) the
> number of private clones of upstream trees, and provide true mirrors
> on xenbits really just for developers' convenience. Any word on the
> overall picture?

The reality is that we will sometimes need to backport fixes to stable
trees which are specific to Xen and which upstream declines to take into
their own stable branch (e.g. because they need to balance the risk of
taking a Xen thing against other non-Xen users of their stable branch).

It is also possible that we will want to backport new features from
upstream mainline in order to better expose them to Xen users and
developers prior to a new upstream release occurring. For example I
expect that the upstream qemu support for save/restore will fall into
this category.

In this case I should have asked upstream about a backport to their
stable branch before taking them myself which I neglected to do, sorry.
I have approached upstream about these two now and will fixup with the
appropriate merging in 1.6.3-stable-xen if the decide to take them.

The rules which I will be applying (and which e.g. Stefano will be
applying for the qemu tree) will be similar to the upstream kernel
stable rules -- primarily that a commit must be included in the relevant
mainline branch before being proposed for backport. This ensures that
the fork will be bounded due to being reset each time we rebase to a new
upstream stable release.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 09:29:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09: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 1S2JMJ-0005Vm-J6; Tue, 28 Feb 2012 09:28:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2JMI-0005Vd-1m
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 09:28:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330421308!16702250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12441 invoked from network); 28 Feb 2012 09:28:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 09:28:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10975378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 09:28:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 09:28:27 +0000
Message-ID: <1330421306.31269.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 28 Feb 2012 09:28:26 +0000
In-Reply-To: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
> Hi Ian,
> 
> with these I'm getting the impression we're making it, just like for qemu,
> a requirement to use the xenbits mirror rather than the original as well,
> even more so given that the two post-1.6.3.1 commits the mirror now
> has don't even exist in the upstream tree (yet), making this not even a
> mirror anymore.

I cherry picked both of those commits directly from the mainline SeaBIOS
tree, so they are upstream.

> I really had hoped that we would bring down (rather than up) the
> number of private clones of upstream trees, and provide true mirrors
> on xenbits really just for developers' convenience. Any word on the
> overall picture?

The reality is that we will sometimes need to backport fixes to stable
trees which are specific to Xen and which upstream declines to take into
their own stable branch (e.g. because they need to balance the risk of
taking a Xen thing against other non-Xen users of their stable branch).

It is also possible that we will want to backport new features from
upstream mainline in order to better expose them to Xen users and
developers prior to a new upstream release occurring. For example I
expect that the upstream qemu support for save/restore will fall into
this category.

In this case I should have asked upstream about a backport to their
stable branch before taking them myself which I neglected to do, sorry.
I have approached upstream about these two now and will fixup with the
appropriate merging in 1.6.3-stable-xen if the decide to take them.

The rules which I will be applying (and which e.g. Stefano will be
applying for the qemu tree) will be similar to the upstream kernel
stable rules -- primarily that a commit must be included in the relevant
mainline branch before being proposed for backport. This ensures that
the fork will be bounded due to being reset each time we rebase to a new
upstream stable release.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 09:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09: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 1S2JQG-0005fj-7W; Tue, 28 Feb 2012 09:32: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 1S2JQE-0005fX-4W
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 09:32:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330421426!60999793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19256 invoked from network); 28 Feb 2012 09:30:26 -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;
	28 Feb 2012 09:30:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10975534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 09:32:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 09:32:37 +0000
Message-ID: <1330421555.31269.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 09:32:35 +0000
In-Reply-To: <osstest-12101-mainreport@xen.org>
References: <osstest-12101-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux test] 12101: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 08:26 +0000, xen.org wrote:
> flight 12101 linux real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12101/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

This has been failing for ages -- is the bisector on the case?

The last tolerable fail (11891) had this as "fail blocked in 10764".
This was back on 5 Feb.

Could it be that changes to the heisenbug detector (e.g. to be more
sticky about the host) have turned this previously occasional failure
into an always fail?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 09:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09: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 1S2JQG-0005fj-7W; Tue, 28 Feb 2012 09:32: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 1S2JQE-0005fX-4W
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 09:32:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330421426!60999793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19256 invoked from network); 28 Feb 2012 09:30:26 -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;
	28 Feb 2012 09:30:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10975534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 09:32:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 09:32:37 +0000
Message-ID: <1330421555.31269.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 09:32:35 +0000
In-Reply-To: <osstest-12101-mainreport@xen.org>
References: <osstest-12101-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [linux test] 12101: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 08:26 +0000, xen.org wrote:
> flight 12101 linux real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12101/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

This has been failing for ages -- is the bisector on the case?

The last tolerable fail (11891) had this as "fail blocked in 10764".
This was back on 5 Feb.

Could it be that changes to the heisenbug detector (e.g. to be more
sticky about the host) have turned this previously occasional failure
into an always fail?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 09:41:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09:41:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2JXw-0005ul-Aa; Tue, 28 Feb 2012 09:40:36 +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 1S2JXv-0005ug-2C
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 09:40:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330421985!54339807!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17704 invoked from network); 28 Feb 2012 09:39:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 09:39:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325480400"; d="scan'208";a="183668488"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 04:40:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012
	04:40:26 -0500
Message-ID: <4F4CA108.3040009@citrix.com>
Date: Tue, 28 Feb 2012 09:40:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <4F4BCEBE.6010608@citrix.com> <20120227192746.GU12984@reaktio.net>
In-Reply-To: <20120227192746.GU12984@reaktio.net>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/02/12 19:27, Pasi K=E4rkk=E4inen wrote:
> On Mon, Feb 27, 2012 at 06:43:10PM +0000, Andrew Cooper wrote:
>> Attached is an attempt to document all the Xen command line parameters.
>>
>> Because of other tasks, (and choosing to document the rather twisty
>> 'acpi' option first), It is far less complete than I was hoping.
>>
>> However, I am submitting it so other people may benefit (and contribute)
>> going forward.
>>
> Related link:
> http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options
>
> -- Pasi

Yes - I am aware of that, but sadly it is starting to get out of date. =

The idea of having a markdown document in the source tree is so any
patch modifying command line behavior should also patch this file, so
hopefully the document will stay up to date going forward.

~Andrew

>
>> -- =

>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>> T: +44 (0)1223 225 900, http://www.citrix.com
>>
>

-- =

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 Feb 28 09:41:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09:41:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2JXw-0005ul-Aa; Tue, 28 Feb 2012 09:40:36 +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 1S2JXv-0005ug-2C
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 09:40:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330421985!54339807!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17704 invoked from network); 28 Feb 2012 09:39:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 09:39:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325480400"; d="scan'208";a="183668488"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 04:40:26 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012
	04:40:26 -0500
Message-ID: <4F4CA108.3040009@citrix.com>
Date: Tue, 28 Feb 2012 09:40:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <4F4BCEBE.6010608@citrix.com> <20120227192746.GU12984@reaktio.net>
In-Reply-To: <20120227192746.GU12984@reaktio.net>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/02/12 19:27, Pasi K=E4rkk=E4inen wrote:
> On Mon, Feb 27, 2012 at 06:43:10PM +0000, Andrew Cooper wrote:
>> Attached is an attempt to document all the Xen command line parameters.
>>
>> Because of other tasks, (and choosing to document the rather twisty
>> 'acpi' option first), It is far less complete than I was hoping.
>>
>> However, I am submitting it so other people may benefit (and contribute)
>> going forward.
>>
> Related link:
> http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options
>
> -- Pasi

Yes - I am aware of that, but sadly it is starting to get out of date. =

The idea of having a markdown document in the source tree is so any
patch modifying command line behavior should also patch this file, so
hopefully the document will stay up to date going forward.

~Andrew

>
>> -- =

>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>> T: +44 (0)1223 225 900, http://www.citrix.com
>>
>

-- =

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 Feb 28 09:47:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2JeI-00064L-92; Tue, 28 Feb 2012 09:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2JeG-00064B-Kq
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 09:47:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330422422!13371883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27916 invoked from network); 28 Feb 2012 09:47:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 09:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10976388"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 09:47:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 09:47:02 +0000
Message-ID: <1330422420.31269.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Tue, 28 Feb 2012 09:47:00 +0000
In-Reply-To: <4F4CA108.3040009@citrix.com>
References: <4F4BCEBE.6010608@citrix.com>
	<20120227192746.GU12984@reaktio.net> <4F4CA108.3040009@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTI4IGF0IDA5OjQwICswMDAwLCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+
IE9uIDI3LzAyLzEyIDE5OjI3LCBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZToKPiA+IE9uIE1vbiwg
RmViIDI3LCAyMDEyIGF0IDA2OjQzOjEwUE0gKzAwMDAsIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4g
Pj4gQXR0YWNoZWQgaXMgYW4gYXR0ZW1wdCB0byBkb2N1bWVudCBhbGwgdGhlIFhlbiBjb21tYW5k
IGxpbmUgcGFyYW1ldGVycy4KPiA+Pgo+ID4+IEJlY2F1c2Ugb2Ygb3RoZXIgdGFza3MsIChhbmQg
Y2hvb3NpbmcgdG8gZG9jdW1lbnQgdGhlIHJhdGhlciB0d2lzdHkKPiA+PiAnYWNwaScgb3B0aW9u
IGZpcnN0KSwgSXQgaXMgZmFyIGxlc3MgY29tcGxldGUgdGhhbiBJIHdhcyBob3BpbmcuCj4gPj4K
PiA+PiBIb3dldmVyLCBJIGFtIHN1Ym1pdHRpbmcgaXQgc28gb3RoZXIgcGVvcGxlIG1heSBiZW5l
Zml0IChhbmQgY29udHJpYnV0ZSkKPiA+PiBnb2luZyBmb3J3YXJkLgo+ID4+Cj4gPiBSZWxhdGVk
IGxpbms6Cj4gPiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX0h5cGVydmlzb3JfQm9vdF9P
cHRpb25zCj4gPgo+ID4gLS0gUGFzaQo+IAo+IFllcyAtIEkgYW0gYXdhcmUgb2YgdGhhdCwgYnV0
IHNhZGx5IGl0IGlzIHN0YXJ0aW5nIHRvIGdldCBvdXQgb2YgZGF0ZS4gCj4gVGhlIGlkZWEgb2Yg
aGF2aW5nIGEgbWFya2Rvd24gZG9jdW1lbnQgaW4gdGhlIHNvdXJjZSB0cmVlIGlzIHNvIGFueQo+
IHBhdGNoIG1vZGlmeWluZyBjb21tYW5kIGxpbmUgYmVoYXZpb3Igc2hvdWxkIGFsc28gcGF0Y2gg
dGhpcyBmaWxlLCBzbwo+IGhvcGVmdWxseSB0aGUgZG9jdW1lbnQgd2lsbCBzdGF5IHVwIHRvIGRh
dGUgZ29pbmcgZm9yd2FyZC4KCkEgZ29vZCBzdGFydGluZyBwb2ludCB3b3VsZCBiZSB0byBjdXQt
bi1wYXN0ZSB0aGF0IHdpa2kgcGFnZSBpbnRvIHRoZQptYXJrZG93biBkb2NzIGFuZCB0aGVuIHJl
cGxhY2UgdGhlIHdpa2kgcGFnZSB3aXRoIGEgbGluayB0byB0aGUKZ2VuZXJhdGVkIGRvY3MgYXQg
aHR0cDovL3hlbmJpdHMueGVuLm9yZy9kb2NzIC4gVGhpcyB3b3VsZCBiZSBwcmVmZXJhYmxlCnRv
IHN0YXJ0aW5nIGNvbXBsZXRlbHkgZnJvbSBzY3JhdGNoLgoKQXNpZGU7IFRoYXQgd2lraSBwYWdl
J3MgdXNlIG9mICJHcnViLmNvbmYgb3B0aW9ucyBmb3IgWGVuIiB2cyAiWGVuCkNvbW1hbmQgTGlu
ZSIgaXMgcHJldHR5IGNvbmZ1c2luZywgSSB0aGluayBpdCBpcyB0cnlpbmcgdG8gc2F5ICJYZW4K
Q29tbWFuZCBMaW5lIiBhbmQgIkRvbTAgTGludXggS2VybmVsIENvbW1hbmQgTGluZSIgcmVzcGVj
dGl2ZWx5IGJ1dCBJCndhc24ndCBzdXJlIHNvIEkgZGlkbid0IHdhbnQgdG8gdG91Y2ggaXQuCgpJ
YW4uCgo+IAo+IH5BbmRyZXcKPiAKPiA+Cj4gPj4gLS0gCj4gPj4gQW5kcmV3IENvb3BlciAtIERv
bTAgS2VybmVsIEVuZ2luZWVyLCBDaXRyaXggWGVuU2VydmVyCj4gPj4gVDogKzQ0ICgwKTEyMjMg
MjI1IDkwMCwgaHR0cDovL3d3dy5jaXRyaXguY29tCj4gPj4KPiA+Cj4gCgoKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 09:47:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 09:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2JeI-00064L-92; Tue, 28 Feb 2012 09:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2JeG-00064B-Kq
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 09:47:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330422422!13371883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27916 invoked from network); 28 Feb 2012 09:47:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 09:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10976388"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 09:47:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 09:47:02 +0000
Message-ID: <1330422420.31269.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Tue, 28 Feb 2012 09:47:00 +0000
In-Reply-To: <4F4CA108.3040009@citrix.com>
References: <4F4BCEBE.6010608@citrix.com>
	<20120227192746.GU12984@reaktio.net> <4F4CA108.3040009@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTI4IGF0IDA5OjQwICswMDAwLCBBbmRyZXcgQ29vcGVyIHdyb3RlOgo+
IE9uIDI3LzAyLzEyIDE5OjI3LCBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZToKPiA+IE9uIE1vbiwg
RmViIDI3LCAyMDEyIGF0IDA2OjQzOjEwUE0gKzAwMDAsIEFuZHJldyBDb29wZXIgd3JvdGU6Cj4g
Pj4gQXR0YWNoZWQgaXMgYW4gYXR0ZW1wdCB0byBkb2N1bWVudCBhbGwgdGhlIFhlbiBjb21tYW5k
IGxpbmUgcGFyYW1ldGVycy4KPiA+Pgo+ID4+IEJlY2F1c2Ugb2Ygb3RoZXIgdGFza3MsIChhbmQg
Y2hvb3NpbmcgdG8gZG9jdW1lbnQgdGhlIHJhdGhlciB0d2lzdHkKPiA+PiAnYWNwaScgb3B0aW9u
IGZpcnN0KSwgSXQgaXMgZmFyIGxlc3MgY29tcGxldGUgdGhhbiBJIHdhcyBob3BpbmcuCj4gPj4K
PiA+PiBIb3dldmVyLCBJIGFtIHN1Ym1pdHRpbmcgaXQgc28gb3RoZXIgcGVvcGxlIG1heSBiZW5l
Zml0IChhbmQgY29udHJpYnV0ZSkKPiA+PiBnb2luZyBmb3J3YXJkLgo+ID4+Cj4gPiBSZWxhdGVk
IGxpbms6Cj4gPiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX0h5cGVydmlzb3JfQm9vdF9P
cHRpb25zCj4gPgo+ID4gLS0gUGFzaQo+IAo+IFllcyAtIEkgYW0gYXdhcmUgb2YgdGhhdCwgYnV0
IHNhZGx5IGl0IGlzIHN0YXJ0aW5nIHRvIGdldCBvdXQgb2YgZGF0ZS4gCj4gVGhlIGlkZWEgb2Yg
aGF2aW5nIGEgbWFya2Rvd24gZG9jdW1lbnQgaW4gdGhlIHNvdXJjZSB0cmVlIGlzIHNvIGFueQo+
IHBhdGNoIG1vZGlmeWluZyBjb21tYW5kIGxpbmUgYmVoYXZpb3Igc2hvdWxkIGFsc28gcGF0Y2gg
dGhpcyBmaWxlLCBzbwo+IGhvcGVmdWxseSB0aGUgZG9jdW1lbnQgd2lsbCBzdGF5IHVwIHRvIGRh
dGUgZ29pbmcgZm9yd2FyZC4KCkEgZ29vZCBzdGFydGluZyBwb2ludCB3b3VsZCBiZSB0byBjdXQt
bi1wYXN0ZSB0aGF0IHdpa2kgcGFnZSBpbnRvIHRoZQptYXJrZG93biBkb2NzIGFuZCB0aGVuIHJl
cGxhY2UgdGhlIHdpa2kgcGFnZSB3aXRoIGEgbGluayB0byB0aGUKZ2VuZXJhdGVkIGRvY3MgYXQg
aHR0cDovL3hlbmJpdHMueGVuLm9yZy9kb2NzIC4gVGhpcyB3b3VsZCBiZSBwcmVmZXJhYmxlCnRv
IHN0YXJ0aW5nIGNvbXBsZXRlbHkgZnJvbSBzY3JhdGNoLgoKQXNpZGU7IFRoYXQgd2lraSBwYWdl
J3MgdXNlIG9mICJHcnViLmNvbmYgb3B0aW9ucyBmb3IgWGVuIiB2cyAiWGVuCkNvbW1hbmQgTGlu
ZSIgaXMgcHJldHR5IGNvbmZ1c2luZywgSSB0aGluayBpdCBpcyB0cnlpbmcgdG8gc2F5ICJYZW4K
Q29tbWFuZCBMaW5lIiBhbmQgIkRvbTAgTGludXggS2VybmVsIENvbW1hbmQgTGluZSIgcmVzcGVj
dGl2ZWx5IGJ1dCBJCndhc24ndCBzdXJlIHNvIEkgZGlkbid0IHdhbnQgdG8gdG91Y2ggaXQuCgpJ
YW4uCgo+IAo+IH5BbmRyZXcKPiAKPiA+Cj4gPj4gLS0gCj4gPj4gQW5kcmV3IENvb3BlciAtIERv
bTAgS2VybmVsIEVuZ2luZWVyLCBDaXRyaXggWGVuU2VydmVyCj4gPj4gVDogKzQ0ICgwKTEyMjMg
MjI1IDkwMCwgaHR0cDovL3d3dy5jaXRyaXguY29tCj4gPj4KPiA+Cj4gCgoKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2JrI-0006J4-Qc; Tue, 28 Feb 2012 10:00: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 1S2JrG-0006Iz-JU
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:00:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330423204!65409145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3955 invoked from network); 28 Feb 2012 10:00:04 -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;
	28 Feb 2012 10:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10976826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:00:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:00:28 +0000
Message-ID: <1330423226.31269.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 10:00:26 +0000
In-Reply-To: <CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please do not top post, it destroys the flow of the conversation.

On Mon, 2012-02-27 at 23:19 +0000, Jeffrey Karrels wrote:
> I was just wondering what the "correct" way is to go about this. I
> have a x86_64 centos system that has all of the libs going to /usr/lib
> and not /usr/lib64. It sounds like we want to keep everything
> in /usr/lib on purpose. Is that correct

/usr/lib vs /usr/lib64 is a distro decision which Xen has to fit in
with, not a decision which we get to make.

The variables under config/ are the mechanism which we provide in order
to allow you as a user to make Xen fit in with your distro's policy.
Have you modified these at all?

Debian and Ubuntu policy is to always use /usr/lib
or /usr/lib/<gnu-triple> (with the latter being the multiarch thing).
AIUI CentOS and RHEL (perhaps/probably SuSE too) always use /usr/lib for
32 bit stuff and /usr/lib64 for 64 bit stuff, regardless of whether the
installation is primarily 32 bit or 64 bit. I don't use CentOS or RHEL
so I may be mistaken here (but I don't think I am)

config/StdGNU.mk implements (or is supposed to implement) the
CentOS/RHEL policy by default, hence the discussion below about
modifying the variables for Ubuntu.

Have you changed anything here or are you saying that a pristine Xen
tree when built on CentOS installs 64 bit libraries to /usr/lib instead
of /usr/lib64? If so please can you be precise about what tree you are
running (e.g. the exact URL you cloned and which changeset you got) and
steps you took to install (e.g. what patches did you apply, what
commands did you type) and what exactly you saw (e.g. what was
in /usr/lib and what was in /usr/lib64).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2JrI-0006J4-Qc; Tue, 28 Feb 2012 10:00: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 1S2JrG-0006Iz-JU
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:00:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330423204!65409145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3955 invoked from network); 28 Feb 2012 10:00:04 -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;
	28 Feb 2012 10:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10976826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:00:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:00:28 +0000
Message-ID: <1330423226.31269.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 10:00:26 +0000
In-Reply-To: <CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please do not top post, it destroys the flow of the conversation.

On Mon, 2012-02-27 at 23:19 +0000, Jeffrey Karrels wrote:
> I was just wondering what the "correct" way is to go about this. I
> have a x86_64 centos system that has all of the libs going to /usr/lib
> and not /usr/lib64. It sounds like we want to keep everything
> in /usr/lib on purpose. Is that correct

/usr/lib vs /usr/lib64 is a distro decision which Xen has to fit in
with, not a decision which we get to make.

The variables under config/ are the mechanism which we provide in order
to allow you as a user to make Xen fit in with your distro's policy.
Have you modified these at all?

Debian and Ubuntu policy is to always use /usr/lib
or /usr/lib/<gnu-triple> (with the latter being the multiarch thing).
AIUI CentOS and RHEL (perhaps/probably SuSE too) always use /usr/lib for
32 bit stuff and /usr/lib64 for 64 bit stuff, regardless of whether the
installation is primarily 32 bit or 64 bit. I don't use CentOS or RHEL
so I may be mistaken here (but I don't think I am)

config/StdGNU.mk implements (or is supposed to implement) the
CentOS/RHEL policy by default, hence the discussion below about
modifying the variables for Ubuntu.

Have you changed anything here or are you saying that a pristine Xen
tree when built on CentOS installs 64 bit libraries to /usr/lib instead
of /usr/lib64? If so please can you be precise about what tree you are
running (e.g. the exact URL you cloned and which changeset you got) and
steps you took to install (e.g. what patches did you apply, what
commands did you type) and what exactly you saw (e.g. what was
in /usr/lib and what was in /usr/lib64).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:07:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Jxr-0006SV-L0; Tue, 28 Feb 2012 10:07:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2Jxq-0006SP-RR
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:07:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330423636!16166518!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5992 invoked from network); 28 Feb 2012 10:07:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:07:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:07:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:07:16 +0000
Message-ID: <1330423635.31269.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Tue, 28 Feb 2012 10:07:15 +0000
In-Reply-To: <20120228094616.GA2063@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120227175327.GA2023@linaro.org>
	<1330372125.10008.47.camel@dagon.hellion.org.uk>
	<20120228094616.GA2063@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 09:46 +0000, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 07:48:45PM +0000, Ian Campbell wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the construction with the __HVC_IMM stuff
> > -- that would remove a big bit of the macroization.
> 
> It's not quite as simple as that -- emitting instructions using data
> directives is not endianness safe, and even in the cases where .long gives
> the right result for ARM, it gives the wrong result for 32-bit Thumb
> instructions if the opcode is given in human-readable order.

Urk, yes,..

> I was trying to solve the same problem for the kvm guys with some global
> macros -- I'm aiming to get a patch posted soon, so I'll make sure
> you're on CC.

Awesome, thanks!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:07:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Jxr-0006SV-L0; Tue, 28 Feb 2012 10:07:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2Jxq-0006SP-RR
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:07:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330423636!16166518!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5992 invoked from network); 28 Feb 2012 10:07:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:07:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:07:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:07:16 +0000
Message-ID: <1330423635.31269.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Tue, 28 Feb 2012 10:07:15 +0000
In-Reply-To: <20120228094616.GA2063@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120227175327.GA2023@linaro.org>
	<1330372125.10008.47.camel@dagon.hellion.org.uk>
	<20120228094616.GA2063@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 09:46 +0000, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 07:48:45PM +0000, Ian Campbell wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the construction with the __HVC_IMM stuff
> > -- that would remove a big bit of the macroization.
> 
> It's not quite as simple as that -- emitting instructions using data
> directives is not endianness safe, and even in the cases where .long gives
> the right result for ARM, it gives the wrong result for 32-bit Thumb
> instructions if the opcode is given in human-readable order.

Urk, yes,..

> I was trying to solve the same problem for the kvm guys with some global
> macros -- I'm aiming to get a patch posted soon, so I'll make sure
> you're on CC.

Awesome, thanks!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:13:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2K3H-0006bC-D0; Tue, 28 Feb 2012 10:12:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2K3F-0006b3-W1
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330423971!15089067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19524 invoked from network); 28 Feb 2012 10:12:52 -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;
	28 Feb 2012 10:12:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:12:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:12:51 +0000
Message-ID: <1330423970.31269.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 28 Feb 2012 10:12:50 +0000
In-Reply-To: <CAFEAcA8PzT9mfnEz60CYvwQWX1OEvejrZvkpuPL2LpTPosp8cA@mail.gmail.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<CAFEAcA8PzT9mfnEz60CYvwQWX1OEvejrZvkpuPL2LpTPosp8cA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-27 at 21:05 +0000, Peter Maydell wrote:
> On 27 February 2012 16:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> > immediate (which can only target r0..r7).
> >
> > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > instructions.
> >
> > Should we use r7 instead to maximise instruction density for Thumb code?
> 
> r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> makes it worth avoiding in this context.

I think it does.

It actually sounds as if using r12 is fine here, the impact on code
density should be pretty small -- there aren't really all that many call
sites which involve hypercalls.

By way of an example I measured an x86 kernel which should be using more
hypercalls due to pv paging etc and found that 0.014% of the lines in
"objdump -d" contained a call to the hypercall_page. (I know not all
lines of objdump -d output are instructions but it's a reasonable approx
IMHO).

So I think using 3 16 bit instructions slots instead of 2 won't make
much impact in practice.

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:13:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2K3H-0006bC-D0; Tue, 28 Feb 2012 10:12:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2K3F-0006b3-W1
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330423971!15089067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19524 invoked from network); 28 Feb 2012 10:12:52 -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;
	28 Feb 2012 10:12:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:12:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:12:51 +0000
Message-ID: <1330423970.31269.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 28 Feb 2012 10:12:50 +0000
In-Reply-To: <CAFEAcA8PzT9mfnEz60CYvwQWX1OEvejrZvkpuPL2LpTPosp8cA@mail.gmail.com>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<CAFEAcA8PzT9mfnEz60CYvwQWX1OEvejrZvkpuPL2LpTPosp8cA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-02-27 at 21:05 +0000, Peter Maydell wrote:
> On 27 February 2012 16:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> > immediate (which can only target r0..r7).
> >
> > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > instructions.
> >
> > Should we use r7 instead to maximise instruction density for Thumb code?
> 
> r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> makes it worth avoiding in this context.

I think it does.

It actually sounds as if using r12 is fine here, the impact on code
density should be pretty small -- there aren't really all that many call
sites which involve hypercalls.

By way of an example I measured an x86 kernel which should be using more
hypercalls due to pv paging etc and found that 0.014% of the lines in
"objdump -d" contained a call to the hypercall_page. (I know not all
lines of objdump -d output are instructions but it's a reasonable approx
IMHO).

So I think using 3 16 bit instructions slots instead of 2 won't make
much impact in practice.

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:13:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10: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 1S2K3x-0006dt-Qi; Tue, 28 Feb 2012 10:13:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2K3w-0006dL-M7
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 10:13:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330424014!17236221!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 28 Feb 2012 10:13:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 10:13:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 10:13:33 +0000
Message-Id: <4F4CB7020200007800075245@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 10:14:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
	<1330421306.31269.17.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330421306.31269.17.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
>> Hi Ian,
>> 
>> with these I'm getting the impression we're making it, just like for qemu,
>> a requirement to use the xenbits mirror rather than the original as well,
>> even more so given that the two post-1.6.3.1 commits the mirror now
>> has don't even exist in the upstream tree (yet), making this not even a
>> mirror anymore.
> 
> I cherry picked both of those commits directly from the mainline SeaBIOS
> tree, so they are upstream.

Then I may be tracking (and looking at) another mirror rather than
upstream. What is "upstream" here?

>> I really had hoped that we would bring down (rather than up) the
>> number of private clones of upstream trees, and provide true mirrors
>> on xenbits really just for developers' convenience. Any word on the
>> overall picture?
> 
> The reality is that we will sometimes need to backport fixes to stable
> trees which are specific to Xen and which upstream declines to take into
> their own stable branch (e.g. because they need to balance the risk of
> taking a Xen thing against other non-Xen users of their stable branch).
> 
> It is also possible that we will want to backport new features from
> upstream mainline in order to better expose them to Xen users and
> developers prior to a new upstream release occurring. For example I
> expect that the upstream qemu support for save/restore will fall into
> this category.
> 
> In this case I should have asked upstream about a backport to their
> stable branch before taking them myself which I neglected to do, sorry.
> I have approached upstream about these two now and will fixup with the
> appropriate merging in 1.6.3-stable-xen if the decide to take them.
> 
> The rules which I will be applying (and which e.g. Stefano will be
> applying for the qemu tree) will be similar to the upstream kernel
> stable rules -- primarily that a commit must be included in the relevant
> mainline branch before being proposed for backport. This ensures that
> the fork will be bounded due to being reset each time we rebase to a new
> upstream stable release.

Okay, thanks for the explanation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:13:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10: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 1S2K3x-0006dt-Qi; Tue, 28 Feb 2012 10:13:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2K3w-0006dL-M7
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 10:13:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1330424014!17236221!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23172 invoked from network); 28 Feb 2012 10:13:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 10:13:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 10:13:33 +0000
Message-Id: <4F4CB7020200007800075245@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 10:14:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
	<1330421306.31269.17.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330421306.31269.17.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
>> Hi Ian,
>> 
>> with these I'm getting the impression we're making it, just like for qemu,
>> a requirement to use the xenbits mirror rather than the original as well,
>> even more so given that the two post-1.6.3.1 commits the mirror now
>> has don't even exist in the upstream tree (yet), making this not even a
>> mirror anymore.
> 
> I cherry picked both of those commits directly from the mainline SeaBIOS
> tree, so they are upstream.

Then I may be tracking (and looking at) another mirror rather than
upstream. What is "upstream" here?

>> I really had hoped that we would bring down (rather than up) the
>> number of private clones of upstream trees, and provide true mirrors
>> on xenbits really just for developers' convenience. Any word on the
>> overall picture?
> 
> The reality is that we will sometimes need to backport fixes to stable
> trees which are specific to Xen and which upstream declines to take into
> their own stable branch (e.g. because they need to balance the risk of
> taking a Xen thing against other non-Xen users of their stable branch).
> 
> It is also possible that we will want to backport new features from
> upstream mainline in order to better expose them to Xen users and
> developers prior to a new upstream release occurring. For example I
> expect that the upstream qemu support for save/restore will fall into
> this category.
> 
> In this case I should have asked upstream about a backport to their
> stable branch before taking them myself which I neglected to do, sorry.
> I have approached upstream about these two now and will fixup with the
> appropriate merging in 1.6.3-stable-xen if the decide to take them.
> 
> The rules which I will be applying (and which e.g. Stefano will be
> applying for the qemu tree) will be similar to the upstream kernel
> stable rules -- primarily that a commit must be included in the relevant
> mainline branch before being proposed for backport. This ensures that
> the fork will be bounded due to being reset each time we rebase to a new
> upstream stable release.

Okay, thanks for the explanation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:19:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 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 1S2K8t-000701-Bh; Tue, 28 Feb 2012 10:18:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2K8r-0006z6-I7
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:18:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330424314!3943334!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7727 invoked from network); 28 Feb 2012 10:18:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:18:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:18:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:18:34 +0000
Message-ID: <1330424312.31269.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:18:32 +0000
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00 of 10] arm: SMP 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-02-23 at 17:40 +0000, Tim Deegan wrote:
> This patch series implements SMP boot for arch/arm, as far as getting
> all CPUs up and running the idle loop.
> 
> The first few patches are semi-independent cleanups and improvements,
> most of which are needed for the SMP patches later.

I have applied:
01: arm: strip xen binary
04: arm: Handle booting on SMP platforms

I looked at taking a few others but they had dependencies on things
which I or others have commented on. I'll go through and ack them as
appropriate now.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:19:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 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 1S2K8t-000701-Bh; Tue, 28 Feb 2012 10:18:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2K8r-0006z6-I7
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:18:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330424314!3943334!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7727 invoked from network); 28 Feb 2012 10:18:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:18:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:18:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:18:34 +0000
Message-ID: <1330424312.31269.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:18:32 +0000
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00 of 10] arm: SMP 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-02-23 at 17:40 +0000, Tim Deegan wrote:
> This patch series implements SMP boot for arch/arm, as far as getting
> all CPUs up and running the idle loop.
> 
> The first few patches are semi-independent cleanups and improvements,
> most of which are needed for the SMP patches later.

I have applied:
01: arm: strip xen binary
04: arm: Handle booting on SMP platforms

I looked at taking a few others but they had dependencies on things
which I or others have commented on. I'll go through and ack them as
appropriate now.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:24:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KEA-0007Li-9s; Tue, 28 Feb 2012 10:24: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 1S2KE8-0007LV-BT
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:24:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330424591!54646331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19515 invoked from network); 28 Feb 2012 10:23:11 -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;
	28 Feb 2012 10:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:24:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:24:06 +0000
Message-ID: <1330424644.31269.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:24:04 +0000
In-Reply-To: <20120227193059.GD98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
	<1330363933.8557.317.camel@zakaz.uk.xensource.com>
	<20120227193059.GD98737@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor
 init out of the per-CPU init 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-02-27 at 19:30 +0000, Tim Deegan wrote:
> At 17:32 +0000 on 27 Feb (1330363933), Ian Campbell wrote:
> > On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > > # HG changeset patch
> > > # User Tim Deegan <tim@xen.org>
> > > # Date 1330018799 0
> > > # Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
> > > # Parent  ec051056db2b6d37344629e2f01d17240099d5ec
> > > arm: Move some GIC distributor init out of the per-CPU init function
> > > 
> > > Signed-off-by: Tim Deegan <tim@xen.org>
> > > 
> > > diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
> > > --- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > > +++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > > @@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
> > >      for ( i = 32; i < gic.lines; i += 32 )
> > >          GICD[GICD_ICENABLER + i / 32] = ~0ul;
> > >  
> > > -    /* Turn on the distributor */
> > > -    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> > > -}
> > > -
> > > -static void __cpuinit gic_cpu_init(void)
> > > -{
> > > -    int i;
> > > -
> > >      /* Disable all PPI and enable all SGI */
> > >      GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
> > >      GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
> > 
> > PPIs and SGIs are per physical-CPU and therefore, I think, the GICD
> > registers of various sorts which refer to the first 32 interrupts are
> > per physical-CPU as well. IOW moving these from gic_cpu_init to
> > gic_dist_init is wrong?
> 
> Yep, you're right ISENABLER0 and ICENABLER0 are banked.

BTW so are GICD_IPRIORITYR0..4 which are initialised just outside the
context here. More generally all the per-IRQ registers are banked for
the first few which cover the PPIs and SGIs.

>  I'll replace this with a comment explaining that.

Thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:24:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KEA-0007Li-9s; Tue, 28 Feb 2012 10:24: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 1S2KE8-0007LV-BT
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:24:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330424591!54646331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19515 invoked from network); 28 Feb 2012 10:23:11 -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;
	28 Feb 2012 10:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:24:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:24:06 +0000
Message-ID: <1330424644.31269.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:24:04 +0000
In-Reply-To: <20120227193059.GD98737@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<437ad1207a175c9ad376.1330018850@whitby.uk.xensource.com>
	<1330363933.8557.317.camel@zakaz.uk.xensource.com>
	<20120227193059.GD98737@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03 of 10] arm: Move some GIC distributor
 init out of the per-CPU init 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-02-27 at 19:30 +0000, Tim Deegan wrote:
> At 17:32 +0000 on 27 Feb (1330363933), Ian Campbell wrote:
> > On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > > # HG changeset patch
> > > # User Tim Deegan <tim@xen.org>
> > > # Date 1330018799 0
> > > # Node ID 437ad1207a175c9ad376871f3f4c075dbcd5b6e6
> > > # Parent  ec051056db2b6d37344629e2f01d17240099d5ec
> > > arm: Move some GIC distributor init out of the per-CPU init function
> > > 
> > > Signed-off-by: Tim Deegan <tim@xen.org>
> > > 
> > > diff -r ec051056db2b -r 437ad1207a17 xen/arch/arm/gic.c
> > > --- a/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > > +++ b/xen/arch/arm/gic.c	Thu Feb 23 17:39:59 2012 +0000
> > > @@ -216,14 +216,6 @@ static void __init gic_dist_init(void)
> > >      for ( i = 32; i < gic.lines; i += 32 )
> > >          GICD[GICD_ICENABLER + i / 32] = ~0ul;
> > >  
> > > -    /* Turn on the distributor */
> > > -    GICD[GICD_CTLR] = GICD_CTL_ENABLE;
> > > -}
> > > -
> > > -static void __cpuinit gic_cpu_init(void)
> > > -{
> > > -    int i;
> > > -
> > >      /* Disable all PPI and enable all SGI */
> > >      GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */
> > >      GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */
> > 
> > PPIs and SGIs are per physical-CPU and therefore, I think, the GICD
> > registers of various sorts which refer to the first 32 interrupts are
> > per physical-CPU as well. IOW moving these from gic_cpu_init to
> > gic_dist_init is wrong?
> 
> Yep, you're right ISENABLER0 and ICENABLER0 are banked.

BTW so are GICD_IPRIORITYR0..4 which are initialised just outside the
context here. More generally all the per-IRQ registers are banked for
the first few which cover the PPIs and SGIs.

>  I'll replace this with a comment explaining that.

Thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:25:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KFP-0007Rc-U1; Tue, 28 Feb 2012 10:25: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 1S2KFO-0007RR-JM
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:25:30 +0000
Received: from [85.158.139.83:63954] by server-9.bemta-5.messagelabs.com id
	43/52-09826-99BAC4F4; Tue, 28 Feb 2012 10:25:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1330424728!17009483!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15551 invoked from network); 28 Feb 2012 10:25:28 -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;
	28 Feb 2012 10:25:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:25:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:25:27 +0000
Message-ID: <1330424726.31269.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:25:26 +0000
In-Reply-To: <3b1d7a91a2596baca178.1330018853@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<3b1d7a91a2596baca178.1330018853@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10] arm: per-cpu areas
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID 3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
> # Parent  1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
> arm: per-cpu areas
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

I tried to apply this along with #1 and #4 but the result hung at just
after freeing initial memory. I expect that's due to missing #2,#3 or #5
rather than a bug here.

With that in mind:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/Makefile
> --- a/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
> @@ -13,6 +13,7 @@ obj-y += irq.o
>  obj-y += kernel.o
>  obj-y += mm.o
>  obj-y += p2m.o
> +obj-y += percpu.o
>  obj-y += guestcopy.o
>  obj-y += setup.o
>  obj-y += time.o
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/dummy.S
> --- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> @@ -14,7 +14,6 @@ DUMMY(per_cpu__cpu_core_mask);
>  DUMMY(per_cpu__cpu_sibling_mask);
>  DUMMY(node_online_map);
>  DUMMY(smp_send_state_dump);
> -DUMMY(__per_cpu_offset);
>  
>  /* PIRQ support */
>  DUMMY(alloc_pirq_struct);
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/percpu.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/xen/arch/arm/percpu.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -0,0 +1,85 @@
> +#include <xen/config.h>
> +#include <xen/percpu.h>
> +#include <xen/cpu.h>
> +#include <xen/init.h>
> +#include <xen/mm.h>
> +#include <xen/rcupdate.h>
> +
> +unsigned long __per_cpu_offset[NR_CPUS];
> +#define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
> +#define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
> +
> +void __init percpu_init_areas(void)
> +{
> +    unsigned int cpu;
> +    for ( cpu = 1; cpu < NR_CPUS; cpu++ )
> +        __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
> +}
> +
> +static int init_percpu_area(unsigned int cpu)
> +{
> +    char *p;
> +    if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA )
> +        return -EBUSY;
> +    if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL )
> +        return -ENOMEM;
> +    memset(p, 0, __per_cpu_data_end - __per_cpu_start);
> +    __per_cpu_offset[cpu] = p - __per_cpu_start;
> +    return 0;
> +}
> +
> +struct free_info {
> +    unsigned int cpu;
> +    struct rcu_head rcu;
> +};
> +static DEFINE_PER_CPU(struct free_info, free_info);
> +
> +static void _free_percpu_area(struct rcu_head *head)
> +{
> +    struct free_info *info = container_of(head, struct free_info, rcu);
> +    unsigned int cpu = info->cpu;
> +    char *p = __per_cpu_start + __per_cpu_offset[cpu];
> +    free_xenheap_pages(p, PERCPU_ORDER);
> +    __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
> +}
> +
> +static void free_percpu_area(unsigned int cpu)
> +{
> +    struct free_info *info = &per_cpu(free_info, cpu);
> +    info->cpu = cpu;
> +    call_rcu(&info->rcu, _free_percpu_area);
> +}
> +
> +static int cpu_percpu_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:
> +        rc = init_percpu_area(cpu);
> +        break;
> +    case CPU_UP_CANCELED:
> +    case CPU_DEAD:
> +        free_percpu_area(cpu);
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
> +}
> +
> +static struct notifier_block cpu_percpu_nfb = {
> +    .notifier_call = cpu_percpu_callback,
> +    .priority = 100 /* highest priority */
> +};
> +
> +static int __init percpu_presmp_init(void)
> +{
> +    register_cpu_notifier(&cpu_percpu_nfb);
> +    return 0;
> +}
> +presmp_initcall(percpu_presmp_init);
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/include/asm-arm/percpu.h
> --- a/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
> @@ -12,8 +12,11 @@ void percpu_init_areas(void);
>      __attribute__((__section__(".bss.percpu" #suffix)))         \
>      __typeof__(type) per_cpu_##name
>  
> -#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
> -#define __get_cpu_var(var) per_cpu__##var
> +
> +#define per_cpu(var, cpu)  \
> +    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> +#define __get_cpu_var(var) \
> +    (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset))
>  
>  #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:25:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KFP-0007Rc-U1; Tue, 28 Feb 2012 10:25: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 1S2KFO-0007RR-JM
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:25:30 +0000
Received: from [85.158.139.83:63954] by server-9.bemta-5.messagelabs.com id
	43/52-09826-99BAC4F4; Tue, 28 Feb 2012 10:25:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1330424728!17009483!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15551 invoked from network); 28 Feb 2012 10:25:28 -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;
	28 Feb 2012 10:25:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:25:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:25:27 +0000
Message-ID: <1330424726.31269.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:25:26 +0000
In-Reply-To: <3b1d7a91a2596baca178.1330018853@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<3b1d7a91a2596baca178.1330018853@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 06 of 10] arm: per-cpu areas
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID 3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
> # Parent  1e9c6bd7cc99d1af0107aa927ee2ba03721449b7
> arm: per-cpu areas
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

I tried to apply this along with #1 and #4 but the result hung at just
after freeing initial memory. I expect that's due to missing #2,#3 or #5
rather than a bug here.

With that in mind:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/Makefile
> --- a/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/Makefile	Thu Feb 23 17:39:59 2012 +0000
> @@ -13,6 +13,7 @@ obj-y += irq.o
>  obj-y += kernel.o
>  obj-y += mm.o
>  obj-y += p2m.o
> +obj-y += percpu.o
>  obj-y += guestcopy.o
>  obj-y += setup.o
>  obj-y += time.o
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/dummy.S
> --- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> @@ -14,7 +14,6 @@ DUMMY(per_cpu__cpu_core_mask);
>  DUMMY(per_cpu__cpu_sibling_mask);
>  DUMMY(node_online_map);
>  DUMMY(smp_send_state_dump);
> -DUMMY(__per_cpu_offset);
>  
>  /* PIRQ support */
>  DUMMY(alloc_pirq_struct);
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/arch/arm/percpu.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/xen/arch/arm/percpu.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -0,0 +1,85 @@
> +#include <xen/config.h>
> +#include <xen/percpu.h>
> +#include <xen/cpu.h>
> +#include <xen/init.h>
> +#include <xen/mm.h>
> +#include <xen/rcupdate.h>
> +
> +unsigned long __per_cpu_offset[NR_CPUS];
> +#define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
> +#define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
> +
> +void __init percpu_init_areas(void)
> +{
> +    unsigned int cpu;
> +    for ( cpu = 1; cpu < NR_CPUS; cpu++ )
> +        __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
> +}
> +
> +static int init_percpu_area(unsigned int cpu)
> +{
> +    char *p;
> +    if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA )
> +        return -EBUSY;
> +    if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL )
> +        return -ENOMEM;
> +    memset(p, 0, __per_cpu_data_end - __per_cpu_start);
> +    __per_cpu_offset[cpu] = p - __per_cpu_start;
> +    return 0;
> +}
> +
> +struct free_info {
> +    unsigned int cpu;
> +    struct rcu_head rcu;
> +};
> +static DEFINE_PER_CPU(struct free_info, free_info);
> +
> +static void _free_percpu_area(struct rcu_head *head)
> +{
> +    struct free_info *info = container_of(head, struct free_info, rcu);
> +    unsigned int cpu = info->cpu;
> +    char *p = __per_cpu_start + __per_cpu_offset[cpu];
> +    free_xenheap_pages(p, PERCPU_ORDER);
> +    __per_cpu_offset[cpu] = INVALID_PERCPU_AREA;
> +}
> +
> +static void free_percpu_area(unsigned int cpu)
> +{
> +    struct free_info *info = &per_cpu(free_info, cpu);
> +    info->cpu = cpu;
> +    call_rcu(&info->rcu, _free_percpu_area);
> +}
> +
> +static int cpu_percpu_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:
> +        rc = init_percpu_area(cpu);
> +        break;
> +    case CPU_UP_CANCELED:
> +    case CPU_DEAD:
> +        free_percpu_area(cpu);
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
> +}
> +
> +static struct notifier_block cpu_percpu_nfb = {
> +    .notifier_call = cpu_percpu_callback,
> +    .priority = 100 /* highest priority */
> +};
> +
> +static int __init percpu_presmp_init(void)
> +{
> +    register_cpu_notifier(&cpu_percpu_nfb);
> +    return 0;
> +}
> +presmp_initcall(percpu_presmp_init);
> diff -r 1e9c6bd7cc99 -r 3b1d7a91a259 xen/include/asm-arm/percpu.h
> --- a/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/include/asm-arm/percpu.h	Thu Feb 23 17:39:59 2012 +0000
> @@ -12,8 +12,11 @@ void percpu_init_areas(void);
>      __attribute__((__section__(".bss.percpu" #suffix)))         \
>      __typeof__(type) per_cpu_##name
>  
> -#define per_cpu(var, cpu) ((&per_cpu__##var)[cpu?0:0])
> -#define __get_cpu_var(var) per_cpu__##var
> +
> +#define per_cpu(var, cpu)  \
> +    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> +#define __get_cpu_var(var) \
> +    (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset))
>  
>  #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:27:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KHS-0007cl-J2; Tue, 28 Feb 2012 10:27:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KHR-0007c3-6v
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330424851!15052924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28551 invoked from network); 28 Feb 2012 10:27:31 -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;
	28 Feb 2012 10:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:27:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:27:31 +0000
Message-ID: <1330424849.31269.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:27:29 +0000
In-Reply-To: <fd78d23ba19de4129e21.1330018854@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<fd78d23ba19de4129e21.1330018854@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] arm: start plumbing in SMP bringup
	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 Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID fd78d23ba19de4129e21cdc7303848b105057227
> # Parent  3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
> arm: start plumbing in SMP bringup in C
> 
> Still a noop, but no longer just a dummy symbol.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/dummy.S
> --- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> @@ -7,9 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruc
>  x:	mov pc, lr
>  	
>  /* SMP support */
> -DUMMY(__cpu_die);
> -DUMMY(__cpu_disable);
> -DUMMY(__cpu_up);
>  DUMMY(per_cpu__cpu_core_mask);
>  DUMMY(per_cpu__cpu_sibling_mask);
>  DUMMY(node_online_map);
> diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/setup.c
> --- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -38,9 +38,6 @@
>  #include <asm/setup.h>
>  #include "gic.h"
>  
> -/* maxcpus: maximum number of CPUs to activate. */
> -static unsigned int __initdata max_cpus = NR_CPUS;
> -
>  /* Xen stack for bringing up the first CPU. */
>  unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
>  
> @@ -206,7 +203,7 @@ void __init start_xen(unsigned long boot
>      cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
>      cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
>  
> -    smp_prepare_cpus(max_cpus);
> +    smp_prepare_cpus(cpus);
>  
>      init_xen_time();
>  
> @@ -253,7 +250,7 @@ void __init start_xen(unsigned long boot
>  
>      for_each_present_cpu ( i )
>      {
> -        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
> +        if ( (num_online_cpus() < cpus) && !cpu_online(i) )
>          {
>              int ret = cpu_up(i);
>              if ( ret != 0 )
> diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/smpboot.c
> --- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -19,6 +19,7 @@
>  #include <xen/cpumask.h>
>  #include <xen/smp.h>
>  #include <xen/init.h>
> +#include <xen/errno.h>
>  
>  cpumask_t cpu_online_map;
>  EXPORT_SYMBOL(cpu_online_map);
> @@ -30,16 +31,40 @@ EXPORT_SYMBOL(cpu_possible_map);
>  void __init
>  smp_prepare_cpus (unsigned int max_cpus)
>  {
> -        set_processor_id(0); /* needed early, for smp_processor_id() */
> +    int i;
> +    set_processor_id(0); /* needed early, for smp_processor_id() */
>  
> -        cpumask_clear(&cpu_online_map);
> -        cpumask_clear(&cpu_present_map);
> -        cpumask_clear(&cpu_possible_map);
> -        cpumask_set_cpu(0, &cpu_online_map);
> -        cpumask_set_cpu(0, &cpu_present_map);
> -        cpumask_set_cpu(0, &cpu_possible_map);
> -        return;
> +    cpumask_clear(&cpu_online_map);
> +    cpumask_set_cpu(0, &cpu_online_map);
> +
> +    cpumask_clear(&cpu_possible_map);
> +    for ( i = 0; i < max_cpus; i++ )
> +        cpumask_set_cpu(i, &cpu_possible_map);
> +    cpumask_copy(&cpu_present_map, &cpu_possible_map);
>  }
> +
> +/* Bring up a non-boot CPU */
> +int __cpu_up(unsigned int cpu)
> +{
> +    /* Not yet... */
> +    return -ENODEV;
> +}
> +
> +/* Shut down the current CPU */
> +void __cpu_disable(void)
> +{
> +    /* TODO: take down timers, GIC, &c. */
> +    BUG();
> +}
> +
> +/* Wait for a remote CPU to die */
> +void __cpu_die(unsigned int cpu)
> +{
> +    /* TODO: interlock with __cpu_disable */
> +    BUG();
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:27:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KHS-0007cl-J2; Tue, 28 Feb 2012 10:27:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KHR-0007c3-6v
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:27:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330424851!15052924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28551 invoked from network); 28 Feb 2012 10:27:31 -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;
	28 Feb 2012 10:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:27:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:27:31 +0000
Message-ID: <1330424849.31269.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:27:29 +0000
In-Reply-To: <fd78d23ba19de4129e21.1330018854@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<fd78d23ba19de4129e21.1330018854@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07 of 10] arm: start plumbing in SMP bringup
	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 Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID fd78d23ba19de4129e21cdc7303848b105057227
> # Parent  3b1d7a91a2596baca178e8b5610b3cbc299fa5ea
> arm: start plumbing in SMP bringup in C
> 
> Still a noop, but no longer just a dummy symbol.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/dummy.S
> --- a/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/dummy.S	Thu Feb 23 17:39:59 2012 +0000
> @@ -7,9 +7,6 @@ x:	.word 0xe7f000f0 /* Undefined instruc
>  x:	mov pc, lr
>  	
>  /* SMP support */
> -DUMMY(__cpu_die);
> -DUMMY(__cpu_disable);
> -DUMMY(__cpu_up);
>  DUMMY(per_cpu__cpu_core_mask);
>  DUMMY(per_cpu__cpu_sibling_mask);
>  DUMMY(node_online_map);
> diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/setup.c
> --- a/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/setup.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -38,9 +38,6 @@
>  #include <asm/setup.h>
>  #include "gic.h"
>  
> -/* maxcpus: maximum number of CPUs to activate. */
> -static unsigned int __initdata max_cpus = NR_CPUS;
> -
>  /* Xen stack for bringing up the first CPU. */
>  unsigned char __initdata init_stack[STACK_SIZE] __attribute__((__aligned__(STACK_SIZE)));
>  
> @@ -206,7 +203,7 @@ void __init start_xen(unsigned long boot
>      cpumask_set_cpu(smp_processor_id(), &cpu_online_map);
>      cpumask_set_cpu(smp_processor_id(), &cpu_present_map);
>  
> -    smp_prepare_cpus(max_cpus);
> +    smp_prepare_cpus(cpus);
>  
>      init_xen_time();
>  
> @@ -253,7 +250,7 @@ void __init start_xen(unsigned long boot
>  
>      for_each_present_cpu ( i )
>      {
> -        if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
> +        if ( (num_online_cpus() < cpus) && !cpu_online(i) )
>          {
>              int ret = cpu_up(i);
>              if ( ret != 0 )
> diff -r 3b1d7a91a259 -r fd78d23ba19d xen/arch/arm/smpboot.c
> --- a/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/smpboot.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -19,6 +19,7 @@
>  #include <xen/cpumask.h>
>  #include <xen/smp.h>
>  #include <xen/init.h>
> +#include <xen/errno.h>
>  
>  cpumask_t cpu_online_map;
>  EXPORT_SYMBOL(cpu_online_map);
> @@ -30,16 +31,40 @@ EXPORT_SYMBOL(cpu_possible_map);
>  void __init
>  smp_prepare_cpus (unsigned int max_cpus)
>  {
> -        set_processor_id(0); /* needed early, for smp_processor_id() */
> +    int i;
> +    set_processor_id(0); /* needed early, for smp_processor_id() */
>  
> -        cpumask_clear(&cpu_online_map);
> -        cpumask_clear(&cpu_present_map);
> -        cpumask_clear(&cpu_possible_map);
> -        cpumask_set_cpu(0, &cpu_online_map);
> -        cpumask_set_cpu(0, &cpu_present_map);
> -        cpumask_set_cpu(0, &cpu_possible_map);
> -        return;
> +    cpumask_clear(&cpu_online_map);
> +    cpumask_set_cpu(0, &cpu_online_map);
> +
> +    cpumask_clear(&cpu_possible_map);
> +    for ( i = 0; i < max_cpus; i++ )
> +        cpumask_set_cpu(i, &cpu_possible_map);
> +    cpumask_copy(&cpu_present_map, &cpu_possible_map);
>  }
> +
> +/* Bring up a non-boot CPU */
> +int __cpu_up(unsigned int cpu)
> +{
> +    /* Not yet... */
> +    return -ENODEV;
> +}
> +
> +/* Shut down the current CPU */
> +void __cpu_disable(void)
> +{
> +    /* TODO: take down timers, GIC, &c. */
> +    BUG();
> +}
> +
> +/* Wait for a remote CPU to die */
> +void __cpu_die(unsigned int cpu)
> +{
> +    /* TODO: interlock with __cpu_disable */
> +    BUG();
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:35:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KOa-0007xo-Fq; Tue, 28 Feb 2012 10:35:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KOY-0007xj-Iz
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:34:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330425291!15274865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14693 invoked from network); 28 Feb 2012 10:34:52 -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;
	28 Feb 2012 10:34:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:34:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:34:51 +0000
Message-ID: <1330425290.31269.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:34:50 +0000
In-Reply-To: <d35b52e5fde829dfbaf3.1330018855@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<d35b52e5fde829dfbaf3.1330018855@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10] arm: Boot secondary CPUs into C
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID d35b52e5fde829dfbaf3da73e0716d004faded2f
> # Parent  fd78d23ba19de4129e21cdc7303848b105057227
> arm: Boot secondary CPUs into C
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

I think this need rebasing a bit past the per-vcpu stacks changes so I
wont' ack just yet although I like the general shape of it.

> @@ -28,6 +33,14 @@ EXPORT_SYMBOL(cpu_online_map);
>  cpumask_t cpu_possible_map;
>  EXPORT_SYMBOL(cpu_possible_map);
>  
> +/* Xen stack for bringing up the first CPU. */
> +static unsigned char cpu0_stack[STACK_SIZE]
> +       __attribute__((__aligned__(STACK_SIZE)));
> +
> +/* Remember where the boot-time stacks live */
> +/* TODO: overhaul this, and get_processor_id(), for per-vcpu stacks */
> +unsigned char *init_stacks[NR_CPUS] = { cpu0_stack, 0 };

Do we need to track the per-CPU idle stacks after the CPUs have been
brought up?

We are already serialized due to the use of the shared smp_up_cpu so
could we get away with a single "smp_bringup_args" area and avoid the
NR_CPUS array?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:35:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KOa-0007xo-Fq; Tue, 28 Feb 2012 10:35:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KOY-0007xj-Iz
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:34:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330425291!15274865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14693 invoked from network); 28 Feb 2012 10:34:52 -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;
	28 Feb 2012 10:34:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10977992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:34:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:34:51 +0000
Message-ID: <1330425290.31269.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:34:50 +0000
In-Reply-To: <d35b52e5fde829dfbaf3.1330018855@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<d35b52e5fde829dfbaf3.1330018855@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 08 of 10] arm: Boot secondary CPUs into C
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID d35b52e5fde829dfbaf3da73e0716d004faded2f
> # Parent  fd78d23ba19de4129e21cdc7303848b105057227
> arm: Boot secondary CPUs into C
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

I think this need rebasing a bit past the per-vcpu stacks changes so I
wont' ack just yet although I like the general shape of it.

> @@ -28,6 +33,14 @@ EXPORT_SYMBOL(cpu_online_map);
>  cpumask_t cpu_possible_map;
>  EXPORT_SYMBOL(cpu_possible_map);
>  
> +/* Xen stack for bringing up the first CPU. */
> +static unsigned char cpu0_stack[STACK_SIZE]
> +       __attribute__((__aligned__(STACK_SIZE)));
> +
> +/* Remember where the boot-time stacks live */
> +/* TODO: overhaul this, and get_processor_id(), for per-vcpu stacks */
> +unsigned char *init_stacks[NR_CPUS] = { cpu0_stack, 0 };

Do we need to track the per-CPU idle stacks after the CPUs have been
brought up?

We are already serialized due to the use of the shared smp_up_cpu so
could we get away with a single "smp_bringup_args" area and avoid the
NR_CPUS array?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10: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 1S2KSF-00085c-4e; Tue, 28 Feb 2012 10:38:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KSE-00085O-6A
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:38:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330425520!11416767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20345 invoked from network); 28 Feb 2012 10:38:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:38:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:38:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:38:40 +0000
Message-ID: <1330425518.31269.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:38:38 +0000
In-Reply-To: <a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] arm: SMP CPU 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

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID a78bc9b8421492e0545c6d52c7a32b9de9737d61
> # Parent  d35b52e5fde829dfbaf3da73e0716d004faded2f
> arm: SMP CPU shutdown
> 
> For completeness, also implelent the CPU shutdown path.

Does something free the init_stack for a CPU as it goes down?

Alternatively the bring up path could reuse it if the CPU came back but
we don't seem to do that either.

> Signed-off-by: TIm Deegan <tim@xen.org>

Typo here.

[...]
> +    /* It's now safe to remove this processor from the online map */
> +    cpumask_clear_cpu(cpu, &cpu_online_map);
> +
> +    if ( cpu_disable_scheduler(cpu) )
> +        BUG();
> +    mb();
> +
> +    /* Return to caller; eventually the IPI mecahnism will unwind and the 

                                               mechanism

> +     * scheduler will drop to the idle loop, which will call stop_cpu(). */
> +}
> +
> +void stop_cpu(void)
> +{
> +    local_irq_disable();
> +    cpu_is_dead = 1;

Do we lock this variable? What stops multiple CPUs coming down at once?

> +    /* Make sure the write happens before we sleep forever */
> +    dsb();
> +    isb();
> +    while ( 1 ) 
> +        asm volatile("wfi");
>  }
>  
>  /* Bring up a remote CPU */

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10: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 1S2KSF-00085c-4e; Tue, 28 Feb 2012 10:38:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KSE-00085O-6A
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:38:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330425520!11416767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20345 invoked from network); 28 Feb 2012 10:38:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:38:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:38:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:38:40 +0000
Message-ID: <1330425518.31269.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:38:38 +0000
In-Reply-To: <a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] arm: SMP CPU 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

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID a78bc9b8421492e0545c6d52c7a32b9de9737d61
> # Parent  d35b52e5fde829dfbaf3da73e0716d004faded2f
> arm: SMP CPU shutdown
> 
> For completeness, also implelent the CPU shutdown path.

Does something free the init_stack for a CPU as it goes down?

Alternatively the bring up path could reuse it if the CPU came back but
we don't seem to do that either.

> Signed-off-by: TIm Deegan <tim@xen.org>

Typo here.

[...]
> +    /* It's now safe to remove this processor from the online map */
> +    cpumask_clear_cpu(cpu, &cpu_online_map);
> +
> +    if ( cpu_disable_scheduler(cpu) )
> +        BUG();
> +    mb();
> +
> +    /* Return to caller; eventually the IPI mecahnism will unwind and the 

                                               mechanism

> +     * scheduler will drop to the idle loop, which will call stop_cpu(). */
> +}
> +
> +void stop_cpu(void)
> +{
> +    local_irq_disable();
> +    cpu_is_dead = 1;

Do we lock this variable? What stops multiple CPUs coming down at once?

> +    /* Make sure the write happens before we sleep forever */
> +    dsb();
> +    isb();
> +    while ( 1 ) 
> +        asm volatile("wfi");
>  }
>  
>  /* Bring up a remote CPU */

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10: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 1S2KTW-0008Aw-JO; Tue, 28 Feb 2012 10:40:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KTV-0008AL-37
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:40:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330425599!16174247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14098 invoked from network); 28 Feb 2012 10:39:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:39:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:39:59 +0000
Message-ID: <1330425597.31269.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:39:57 +0000
In-Reply-To: <8a2d38ab67ccaf8637e2.1330018857@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<8a2d38ab67ccaf8637e2.1330018857@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10] arm: Shutdown and reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID 8a2d38ab67ccaf8637e223feb0d0678433974e93
> # Parent  a78bc9b8421492e0545c6d52c7a32b9de9737d61
> arm: Shutdown and reboot
> 
> Reboot runes grabbed from linux's SP810 reset function.
> Doesn't seem to work on the model, though.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

But please add an "XXX get this from device tree" somewhere
appropriate ;-)

> 
> diff -r a78bc9b84214 -r 8a2d38ab67cc xen/arch/arm/shutdown.c
> --- a/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -1,18 +1,63 @@
>  #include <xen/config.h>
> +#include <xen/console.h>
> +#include <xen/cpu.h>
> +#include <xen/delay.h>
>  #include <xen/lib.h>
> +#include <xen/mm.h>
> +#include <xen/smp.h>
> +
> +static void raw_machine_reset(void)
> +{
> +#ifdef SP810_ADDRESS
> +    /* Use the SP810 system controller to force a reset */
> +    volatile uint32_t *sp810;
> +    set_fixmap(FIXMAP_MISC, SP810_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
> +    sp810 = ((uint32_t *)
> +             (FIXMAP_ADDR(FIXMAP_MISC) + (SP810_ADDRESS & ~PAGE_MASK)));
> +    sp810[0] = 0x3; /* switch to slow mode */
> +    dsb(); isb();
> +    sp810[1] = 0x1; /* writing any value to SCSYSSTAT reg will reset system */
> +    dsb(); isb();
> +    clear_fixmap(FIXMAP_MISC);
> +#endif
> +}
> +
> +static void halt_this_cpu(void *arg)
> +{
> +    __cpu_disable();
> +    stop_cpu();
> +}
>  
>  void machine_halt(void)
>  {
> -        /* TODO: halt */
> -        while(1) ;
> +    watchdog_disable();
> +    console_start_sync();
> +    local_irq_enable();
> +    smp_call_function(halt_this_cpu, NULL, 0);
> +    halt_this_cpu(NULL);
>  }
>  
>  void machine_restart(unsigned int delay_millisecs)
>  {
> -        /* TODO: restart */
> -        printk("Cannot restart yet\n");
> -        while(1);
> +    int timeout = 10;
> +
> +    local_irq_enable();
> +    smp_call_function(halt_this_cpu, NULL, 0);
> +    local_irq_disable();
> +
> +    mdelay(delay_millisecs);
> +
> +    /* Wait at most another 10ms for all other CPUs to go offline. */
> +    while ( (num_online_cpus() > 1) && (timeout-- > 0) )
> +        mdelay(1);
> +
> +    while ( 1 )
> +    {
> +        raw_machine_reset();
> +        mdelay(100);
> +    }
>  }
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r a78bc9b84214 -r 8a2d38ab67cc xen/include/asm-arm/config.h
> --- a/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
> @@ -119,6 +119,9 @@ extern unsigned long frametable_virt_end
>  #define GIC_CR_OFFSET 0x2000
>  #define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
>  #define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
> +/* Board-specific: base address of system controller */
> +#define SP810_ADDRESS 0x1C020000
> +
>  
>  #endif /* __ARM_CONFIG_H__ */
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10: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 1S2KTW-0008Aw-JO; Tue, 28 Feb 2012 10:40:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KTV-0008AL-37
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:40:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330425599!16174247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14098 invoked from network); 28 Feb 2012 10:39:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:39:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:39:59 +0000
Message-ID: <1330425597.31269.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 28 Feb 2012 10:39:57 +0000
In-Reply-To: <8a2d38ab67ccaf8637e2.1330018857@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<8a2d38ab67ccaf8637e2.1330018857@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10 of 10] arm: Shutdown and reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1330018799 0
> # Node ID 8a2d38ab67ccaf8637e223feb0d0678433974e93
> # Parent  a78bc9b8421492e0545c6d52c7a32b9de9737d61
> arm: Shutdown and reboot
> 
> Reboot runes grabbed from linux's SP810 reset function.
> Doesn't seem to work on the model, though.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

But please add an "XXX get this from device tree" somewhere
appropriate ;-)

> 
> diff -r a78bc9b84214 -r 8a2d38ab67cc xen/arch/arm/shutdown.c
> --- a/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/arch/arm/shutdown.c	Thu Feb 23 17:39:59 2012 +0000
> @@ -1,18 +1,63 @@
>  #include <xen/config.h>
> +#include <xen/console.h>
> +#include <xen/cpu.h>
> +#include <xen/delay.h>
>  #include <xen/lib.h>
> +#include <xen/mm.h>
> +#include <xen/smp.h>
> +
> +static void raw_machine_reset(void)
> +{
> +#ifdef SP810_ADDRESS
> +    /* Use the SP810 system controller to force a reset */
> +    volatile uint32_t *sp810;
> +    set_fixmap(FIXMAP_MISC, SP810_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
> +    sp810 = ((uint32_t *)
> +             (FIXMAP_ADDR(FIXMAP_MISC) + (SP810_ADDRESS & ~PAGE_MASK)));
> +    sp810[0] = 0x3; /* switch to slow mode */
> +    dsb(); isb();
> +    sp810[1] = 0x1; /* writing any value to SCSYSSTAT reg will reset system */
> +    dsb(); isb();
> +    clear_fixmap(FIXMAP_MISC);
> +#endif
> +}
> +
> +static void halt_this_cpu(void *arg)
> +{
> +    __cpu_disable();
> +    stop_cpu();
> +}
>  
>  void machine_halt(void)
>  {
> -        /* TODO: halt */
> -        while(1) ;
> +    watchdog_disable();
> +    console_start_sync();
> +    local_irq_enable();
> +    smp_call_function(halt_this_cpu, NULL, 0);
> +    halt_this_cpu(NULL);
>  }
>  
>  void machine_restart(unsigned int delay_millisecs)
>  {
> -        /* TODO: restart */
> -        printk("Cannot restart yet\n");
> -        while(1);
> +    int timeout = 10;
> +
> +    local_irq_enable();
> +    smp_call_function(halt_this_cpu, NULL, 0);
> +    local_irq_disable();
> +
> +    mdelay(delay_millisecs);
> +
> +    /* Wait at most another 10ms for all other CPUs to go offline. */
> +    while ( (num_online_cpus() > 1) && (timeout-- > 0) )
> +        mdelay(1);
> +
> +    while ( 1 )
> +    {
> +        raw_machine_reset();
> +        mdelay(100);
> +    }
>  }
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r a78bc9b84214 -r 8a2d38ab67cc xen/include/asm-arm/config.h
> --- a/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
> +++ b/xen/include/asm-arm/config.h	Thu Feb 23 17:39:59 2012 +0000
> @@ -119,6 +119,9 @@ extern unsigned long frametable_virt_end
>  #define GIC_CR_OFFSET 0x2000
>  #define GIC_HR_OFFSET 0x4000 /* Guess work http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/064219.html */
>  #define GIC_VR_OFFSET 0x6000 /* Virtual Machine CPU interface) */
> +/* Board-specific: base address of system controller */
> +#define SP810_ADDRESS 0x1C020000
> +
>  
>  #endif /* __ARM_CONFIG_H__ */
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:49:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KcB-0000HU-Au; Tue, 28 Feb 2012 10:49:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KcA-0000HP-89
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:49:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330426136!13411720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13318 invoked from network); 28 Feb 2012 10:48:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:48:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:48:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:48:55 +0000
Message-ID: <1330426133.31269.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Tue, 28 Feb 2012 10:48:53 +0000
In-Reply-To: <20120228102040.GB2063@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 10:20 +0000, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 07:33:39PM +0000, Ian Campbell wrote:
> > On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote:
> > > > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > > > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > > > instructions.
> > > > 
> > > > Should we use r7 instead to maximise instruction density for Thumb code?
> > > 
> > > The difference seems trivial when put into context, even if you code a
> > > special Thumb version of the code to maximise density (the Thumb-2 code
> > > which gets built from assembler in the kernel is very suboptimal in
> > > size, but there simply isn't a high proportion of asm code in the kernel
> > > anyway.)  I wouldn't consider the ARM/Thumb differences as an important
> > > factor when deciding on a register.
> > 
> > OK, that's useful information. thanks.
> > 
> > > One argument for _not_ using r12 for this purpose is that it is then
> > > harder to put a generic "HVC" function (analogous to the "syscall"
> > > syscall) out-of-line, since r12 could get destroyed by the call.
> > 
> > For an out of line syscall(2) wouldn't the syscall number either be in a
> > standard C calling convention argument register or on the stack when the
> > function was called, since it is just a normal argument at that point?
> > As you point out it cannot be passed in r12 (and could never be, due to
> > the clobbering).
> > 
> > The syscall function itself would have to move the arguments and syscall
> > nr etc around before issuing the syscall.
> > 
> > I think the same is true of a similar hypercall(2)
> > 
> > > If you don't think you will ever care about putting HVC out of line
> > > though, it may not matter.
> 
> If you have both inline and out-of-line hypercalls, it's hard to ensure
> that you never have to shuffle the registers in either case.

Agreed.

I think we want to optimise for the inline case since those are the
majority.

The only non-inline case is the special "privcmd ioctl" which is the
mechanism that allows the Xen toolstack to make hypercalls. It's
somewhat akin to syscall(2). By the time you get to it you will already
have done a system call for the ioctl, pulled the arguments from the
ioctl argument structure etc, plus such hypercalls are not really
performance critical.

> Shuffling can be reduced but only at the expense of strange argument
> ordering in some cases when calling from C -- the complexity is probably
> not worth it.  Linux doesn't bother for its own syscalls.
> 
> Note that even in assembler, a branch from one section to a label in
> another section may cause r12 to get destroyed, so you will need to be
> careful about how you code the hypervisor trap handler.  However, this
> is not different from coding exception handlers in general, so I don't
> know that it constitutes a conclusive argument on its own.

We are happy to arrange that this doesn't occur on our trap entry paths,
at least until the guest register state has been saved. Currently the
hypercall dispatcher is in C and gets r12 from the on-stack saved state.
We will likely eventually optimise the hypercall path directly in ASM
and in that case we are happy to take steps to ensure we don't clobber
r12 before we need it.

> My instinctive preference would therefore be for r7 (which also seems to
> be good enough for Linux syscalls) -- but it really depends how many
> arguments you expect to need to support.

Apparently r7 is the frame pointer for gcc in thumb mode which I think
is a good reason to avoid it.

We currently have some 5 argument hypercalls and there have been
occasional suggestions for interfaces which use 6 -- although none of
them have come to reality.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:49:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KcB-0000HU-Au; Tue, 28 Feb 2012 10:49:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2KcA-0000HP-89
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 10:49:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330426136!13411720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13318 invoked from network); 28 Feb 2012 10:48:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:48:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:48:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:48:55 +0000
Message-ID: <1330426133.31269.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Tue, 28 Feb 2012 10:48:53 +0000
In-Reply-To: <20120228102040.GB2063@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 10:20 +0000, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 07:33:39PM +0000, Ian Campbell wrote:
> > On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote:
> > > > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > > > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > > > instructions.
> > > > 
> > > > Should we use r7 instead to maximise instruction density for Thumb code?
> > > 
> > > The difference seems trivial when put into context, even if you code a
> > > special Thumb version of the code to maximise density (the Thumb-2 code
> > > which gets built from assembler in the kernel is very suboptimal in
> > > size, but there simply isn't a high proportion of asm code in the kernel
> > > anyway.)  I wouldn't consider the ARM/Thumb differences as an important
> > > factor when deciding on a register.
> > 
> > OK, that's useful information. thanks.
> > 
> > > One argument for _not_ using r12 for this purpose is that it is then
> > > harder to put a generic "HVC" function (analogous to the "syscall"
> > > syscall) out-of-line, since r12 could get destroyed by the call.
> > 
> > For an out of line syscall(2) wouldn't the syscall number either be in a
> > standard C calling convention argument register or on the stack when the
> > function was called, since it is just a normal argument at that point?
> > As you point out it cannot be passed in r12 (and could never be, due to
> > the clobbering).
> > 
> > The syscall function itself would have to move the arguments and syscall
> > nr etc around before issuing the syscall.
> > 
> > I think the same is true of a similar hypercall(2)
> > 
> > > If you don't think you will ever care about putting HVC out of line
> > > though, it may not matter.
> 
> If you have both inline and out-of-line hypercalls, it's hard to ensure
> that you never have to shuffle the registers in either case.

Agreed.

I think we want to optimise for the inline case since those are the
majority.

The only non-inline case is the special "privcmd ioctl" which is the
mechanism that allows the Xen toolstack to make hypercalls. It's
somewhat akin to syscall(2). By the time you get to it you will already
have done a system call for the ioctl, pulled the arguments from the
ioctl argument structure etc, plus such hypercalls are not really
performance critical.

> Shuffling can be reduced but only at the expense of strange argument
> ordering in some cases when calling from C -- the complexity is probably
> not worth it.  Linux doesn't bother for its own syscalls.
> 
> Note that even in assembler, a branch from one section to a label in
> another section may cause r12 to get destroyed, so you will need to be
> careful about how you code the hypervisor trap handler.  However, this
> is not different from coding exception handlers in general, so I don't
> know that it constitutes a conclusive argument on its own.

We are happy to arrange that this doesn't occur on our trap entry paths,
at least until the guest register state has been saved. Currently the
hypercall dispatcher is in C and gets r12 from the on-stack saved state.
We will likely eventually optimise the hypercall path directly in ASM
and in that case we are happy to take steps to ensure we don't clobber
r12 before we need it.

> My instinctive preference would therefore be for r7 (which also seems to
> be good enough for Linux syscalls) -- but it really depends how many
> arguments you expect to need to support.

Apparently r7 is the frame pointer for gcc in thumb mode which I think
is a good reason to avoid it.

We currently have some 5 argument hypercalls and there have been
occasional suggestions for interfaces which use 6 -- although none of
them have come to reality.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KiK-0000YF-Lg; Tue, 28 Feb 2012 10:55: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 1S2KiJ-0000Y7-7n
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 10:55:23 +0000
Received: from [85.158.139.83:27807] by server-11.bemta-5.messagelabs.com id
	C0/D5-14397-A92BC4F4; Tue, 28 Feb 2012 10:55:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330426521!16163684!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11639 invoked from network); 28 Feb 2012 10:55:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:55:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:50:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:50:21 +0000
Message-ID: <1330426219.31269.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 28 Feb 2012 10:50:19 +0000
In-Reply-To: <4F4CB7020200007800075245@nat28.tlf.novell.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
	<1330421306.31269.17.camel@zakaz.uk.xensource.com>
	<4F4CB7020200007800075245@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 10:14 +0000, Jan Beulich wrote:
> >>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
> >> Hi Ian,
> >> 
> >> with these I'm getting the impression we're making it, just like for qemu,
> >> a requirement to use the xenbits mirror rather than the original as well,
> >> even more so given that the two post-1.6.3.1 commits the mirror now
> >> has don't even exist in the upstream tree (yet), making this not even a
> >> mirror anymore.
> > 
> > I cherry picked both of those commits directly from the mainline SeaBIOS
> > tree, so they are upstream.
> 
> Then I may be tracking (and looking at) another mirror rather than
> upstream. What is "upstream" here?

git://git.seabios.org/seabios.git

Are you looking at qemu's mirror perhaps?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 10:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 10:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2KiK-0000YF-Lg; Tue, 28 Feb 2012 10:55: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 1S2KiJ-0000Y7-7n
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 10:55:23 +0000
Received: from [85.158.139.83:27807] by server-11.bemta-5.messagelabs.com id
	C0/D5-14397-A92BC4F4; Tue, 28 Feb 2012 10:55:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330426521!16163684!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11639 invoked from network); 28 Feb 2012 10:55:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 10:55:21 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10978494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:50:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:50:21 +0000
Message-ID: <1330426219.31269.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 28 Feb 2012 10:50:19 +0000
In-Reply-To: <4F4CB7020200007800075245@nat28.tlf.novell.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
	<1330421306.31269.17.camel@zakaz.uk.xensource.com>
	<4F4CB7020200007800075245@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 10:14 +0000, Jan Beulich wrote:
> >>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
> >> Hi Ian,
> >> 
> >> with these I'm getting the impression we're making it, just like for qemu,
> >> a requirement to use the xenbits mirror rather than the original as well,
> >> even more so given that the two post-1.6.3.1 commits the mirror now
> >> has don't even exist in the upstream tree (yet), making this not even a
> >> mirror anymore.
> > 
> > I cherry picked both of those commits directly from the mainline SeaBIOS
> > tree, so they are upstream.
> 
> Then I may be tracking (and looking at) another mirror rather than
> upstream. What is "upstream" here?

git://git.seabios.org/seabios.git

Are you looking at qemu's mirror perhaps?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 11:16:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 11: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 1S2L2H-0000nF-In; Tue, 28 Feb 2012 11:16:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2L2F-0000nA-Jo
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 11:15:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330427699!51118690!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9160 invoked from network); 28 Feb 2012 11:14:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 11:14:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 11:15:54 +0000
Message-Id: <4F4CC5A00200007800075296@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 11:16:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
	<1330421306.31269.17.camel@zakaz.uk.xensource.com>
	<4F4CB7020200007800075245@nat28.tlf.novell.com>
	<1330426219.31269.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330426219.31269.71.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-02-28 at 10:14 +0000, Jan Beulich wrote:
>> >>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
>> >> Hi Ian,
>> >> 
>> >> with these I'm getting the impression we're making it, just like for qemu,
>> >> a requirement to use the xenbits mirror rather than the original as well,
>> >> even more so given that the two post-1.6.3.1 commits the mirror now
>> >> has don't even exist in the upstream tree (yet), making this not even a
>> >> mirror anymore.
>> > 
>> > I cherry picked both of those commits directly from the mainline SeaBIOS
>> > tree, so they are upstream.
>> 
>> Then I may be tracking (and looking at) another mirror rather than
>> upstream. What is "upstream" here?
> 
> git://git.seabios.org/seabios.git

Thanks.

> Are you looking at qemu's mirror perhaps?

Indeed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 11:16:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 11: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 1S2L2H-0000nF-In; Tue, 28 Feb 2012 11:16:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2L2F-0000nA-Jo
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 11:15:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330427699!51118690!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9160 invoked from network); 28 Feb 2012 11:14:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 11:14:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 28 Feb 2012 11:15:54 +0000
Message-Id: <4F4CC5A00200007800075296@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 28 Feb 2012 11:16:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4F4CA16E02000078000751E5@nat28.tlf.novell.com>
	<1330421306.31269.17.camel@zakaz.uk.xensource.com>
	<4F4CB7020200007800075245@nat28.tlf.novell.com>
	<1330426219.31269.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330426219.31269.71.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] recent seabios tag updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 11:50, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2012-02-28 at 10:14 +0000, Jan Beulich wrote:
>> >>> On 28.02.12 at 10:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2012-02-28 at 08:42 +0000, Jan Beulich wrote:
>> >> Hi Ian,
>> >> 
>> >> with these I'm getting the impression we're making it, just like for qemu,
>> >> a requirement to use the xenbits mirror rather than the original as well,
>> >> even more so given that the two post-1.6.3.1 commits the mirror now
>> >> has don't even exist in the upstream tree (yet), making this not even a
>> >> mirror anymore.
>> > 
>> > I cherry picked both of those commits directly from the mainline SeaBIOS
>> > tree, so they are upstream.
>> 
>> Then I may be tracking (and looking at) another mirror rather than
>> upstream. What is "upstream" here?
> 
> git://git.seabios.org/seabios.git

Thanks.

> Are you looking at qemu's mirror perhaps?

Indeed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 11:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 11:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2L6I-0000vC-89; Tue, 28 Feb 2012 11:20:10 +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 1S2L6H-0000v0-Dy
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 11:20:09 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330427944!53669596!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12285 invoked from network); 28 Feb 2012 11:19:05 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 11:19:05 -0000
Received: by obcuy19 with SMTP id uy19so8223818obc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 03:20:03 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.60.5.138 as permitted sender) client-ip=10.60.5.138; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.60.5.138 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.60.5.138])
	by 10.60.5.138 with SMTP id s10mr1562446oes.66.1330428003447 (num_hops
	= 1); Tue, 28 Feb 2012 03:20:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=0nreJt8W7/OPzn/SJP+/GD4ITv+nODyuo6wN02jWqeI=;
	b=RhzPyX7V7t+LGkMp8fWIJRku5z9nuDnMdBJvztuD0josryRcSM8XZAqj758Snj5Jlf
	AjFJyf+uupEWHmIfnRKOMlsSYd7+w6EggYwHLd+aChCFNQHWo3ibrupMlFmhATYZqpWI
	y0CftA+INEFEV+4gcaVaGRZM1RZh6pdlwsPG0=
Received: by 10.60.5.138 with SMTP id s10mr1361926oes.66.1330428003355; Tue,
	28 Feb 2012 03:20:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 28 Feb 2012 03:19:33 -0800 (PST)
In-Reply-To: <20120219133549.GB16160@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
	<20120219133549.GB16160@redhat.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 28 Feb 2012 11:19:33 +0000
X-Google-Sender-Auth: fOAIu5U2J4ltdtsc93hmaZM1MuM
Message-ID: <CAJJyHjL0DKy71O4WnrP0bMLZNAj4u6EshJ9cFHL_yuqRoinoYQ@mail.gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V7 06/11] pci.c: Add
	pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCBGZWIgMTksIDIwMTIgYXQgMTM6MzUsIE1pY2hhZWwgUy4gVHNpcmtpbiA8bXN0QHJl
ZGhhdC5jb20+IHdyb3RlOgo+IE9uIEZyaSwgRmViIDE3LCAyMDEyIGF0IDA1OjA4OjQwUE0gKzAw
MDAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOgo+PiBGcm9tOiBZdWppIFNoaW1hZGEgPHNoaW1hZGEt
eXhiQG5lY3N0Lm5lYy5jby5qcD4KPj4KPj4gVGhpcyBmdW5jdGlvbiBoZWxwcyBYZW4gUENJIFBh
c3N0aHJvdWdoIGRldmljZSB0byBjaGVjayBmb3Igb3ZlcmxhcC4KPj4KPj4gU2lnbmVkLW9mZi1i
eTogWXVqaSBTaGltYWRhIDxzaGltYWRhLXl4YkBuZWNzdC5uZWMuY28uanA+Cj4+IFNpZ25lZC1v
ZmYtYnk6IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEBjaXRyaXguY29tPgo+Cj4gQXMg
ZmFyIGFzIEkgY2FuIHNlZSwgdGhpcyBzY2FucyB0aGUgYnVzIGEgc3BlY2lmaWMKPiBkZXZpY2Ug
aXMgb24sIGxvb2tpbmcgZm9yIGRldmljZXMgd2hvIGhhdmUgY29uZmxpY3RpbmcKPiBCQVJzLiBS
ZXR1cm5zIDEgaWYgZm91bmQsIDAgaWYgbm90Lgo+Cj4gTm90IHN1cmUgd2hhdCB3b3VsZCBkZXZp
Y2VzIGRvIHdpdGggdGhpcyBpbmZvcm1hdGlvbiwgcmVhbGx5Ogo+IHBhdGNoZXMgcG9zdGVkIGp1
c3QgcHJpbnQgb3V0IGEgd2FybmluZyB3aGljaCBkb2VzIG5vdCBzZWVtCj4gdG9vIHVzZWZ1bC4K
ClRoaXMgZnVuY3Rpb24gaXMganVzdCBoZXJlIHRvIHByaW50IGEgd2FybmluZyBpbiBjYXNlIGFu
IG92ZXJsYXAKaGFwcGVuLCBidXQgd2Ugd291bGQgbGlrZSB0b28ga2VlcCB0aGlzIHdhcm5pbmcu
Cgo+IEp1c3QgRllJLCBpZiB5b3UgZGVjaWRlZCB0byBlLmcuIGRpc2FibGUgZGV2aWNlIGluCj4g
c3VjaCBhIGNhc2UgdGhhdCB3b3VsZCBiZSB3cm9uZzogaXQgaXMgbGVnYWwgdG8gaGF2ZSBvdmVy
bGFwcGluZyBCQVJzIGFzCj4gbG9uZyBhcyB0aGVyZSBhcmUgbm8gYWNjZXNzZXMuCj4gU28gYSBs
ZWdhbCB0aGluZyBmb3IgYSBndWVzdCB0byBkbyBpczoKPgo+IEFzc2lnbiBCQVIxID0gYWJjZGUK
PiBBc3NpZ24gQkFSMiA9IGFiY2RlIDwtIG92ZXJsYXBzIHRlbXBvcmFyaWx5Cj4gQXNzaWduIEJB
UjEgPSAxMjM0NQo+Cj4gQW5kIHRoaXMgbWVhbnMgdGhhdCB5b3UgY2FuJ3QganVzdCBjaGVjayB5
b3VyIGRldmljZQo+IGhhcyBubyBjb25mbGljdHMgd2hlbiB5b3VyIGRldmljZSBpcyB0b3VjaGVk
Ogo+IGl0IG5lZWRzIHRvIGJlIGNoZWNrZWQgZWFjaCB0aW1lIG1hcHBpbmdzIGFyZSB1cGRhdGVk
Lgo+Cj4+IC0tLQo+PiDCoGh3L3BjaS5jIHwgwqAgNDcgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysKPj4gwqBody9wY2kuaCB8IMKgIMKgMyArKysKPj4gwqAy
IGZpbGVzIGNoYW5nZWQsIDUwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCj4+Cj4+IGRp
ZmYgLS1naXQgYS9ody9wY2kuYyBiL2h3L3BjaS5jCj4+IGluZGV4IDY3OGE4YzEuLjc1ZDY1Mjkg
MTAwNjQ0Cj4+IC0tLSBhL2h3L3BjaS5jCj4+ICsrKyBiL2h3L3BjaS5jCj4+IEBAIC0xOTg1LDYg
KzE5ODUsNTMgQEAgTWVtb3J5UmVnaW9uICpwY2lfYWRkcmVzc19zcGFjZV9pbyhQQ0lEZXZpY2Ug
KmRldikKPj4gwqAgwqAgwqByZXR1cm4gZGV2LT5idXMtPmFkZHJlc3Nfc3BhY2VfaW87Cj4+IMKg
fQo+Pgo+PiAraW50IHBjaV9jaGVja19iYXJfb3ZlcmxhcChQQ0lEZXZpY2UgKmRldiwKPj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBjaWJ1c190IGFkZHIsIHBjaWJ1
c190IHNpemUsIHVpbnQ4X3QgdHlwZSkKPgo+IFRoaXMgbGFja3MgY29tbWVudHMgZG9jdW1lbnRu
ZyB3aGF0IHRoaXMgZG9lcywgcGFyYW1ldGVycywgcmV0dXJuCj4gdmFsdWVzLCBldGMuCgpJJ2xs
IGZpeCB0aGF0LgoKPj4gK3sKPj4gKyDCoCDCoFBDSUJ1cyAqYnVzID0gZGV2LT5idXM7Cj4+ICsg
wqAgwqBQQ0lEZXZpY2UgKmRldmljZXMgPSBOVUxMOwo+PiArIMKgIMKgUENJSU9SZWdpb24gKnI7
Cj4+ICsgwqAgwqBpbnQgaSwgajsKPj4gKyDCoCDCoGludCByYyA9IDA7Cj4+ICsKPj4gKyDCoCDC
oC8qIGNoZWNrIE92ZXJsYXBwZWQgdG8gQmFzZSBBZGRyZXNzICovCj4KPiBXZWlyZCB1c2Ugb2Yg
dXBwZXIgY2FzZS4gSW50ZW50aW9uYWw/Cj4gQWxzbyAtIHdoYXQgZG9lcyB0aGlzIGNvbW1lbnQg
bWVhbj8KCkRvbid0IGtub3csIEkgd2lsbCByZW1vdmUgdGhlIGNvbW1lbnQsIGl0IGlzIHVzZWxl
c3MuCgo+PiArIMKgIMKgZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUoYnVzLT5kZXZpY2VzKTsg
aSsrKSB7Cj4+ICsgwqAgwqAgwqAgwqBkZXZpY2VzID0gYnVzLT5kZXZpY2VzW2ldOwo+PiArIMKg
IMKgIMKgIMKgaWYgKCFkZXZpY2VzKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqBjb250aW51ZTsK
Pj4gKyDCoCDCoCDCoCDCoH0KPj4gKwo+PiArIMKgIMKgIMKgIMKgLyogc2tpcCBpdHNlbGYgKi8K
Pgo+IGl0c2VsZj8KClNhbWUgaGVyZSwgdGhlIGNvbW1lbnQgaXMgcHJvYmFibHkgdXNlbGVzcywg
dGhlIG5leHQgbGluZSBzaG91bGQgYmUKZWFzeSB0byB1bmRlcnN0YW5kLgoKPj4gKyDCoCDCoCDC
oCDCoGlmIChkZXZpY2VzLT5kZXZmbiA9PSBkZXYtPmRldmZuKSB7Cj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqBjb250aW51ZTsKPj4gKyDCoCDCoCDCoCDCoH0KPj4gKwo+PiArIMKgIMKgIMKgIMKgZm9y
IChqID0gMDsgaiA8IFBDSV9OVU1fUkVHSU9OUzsgaisrKSB7Cj4KPiBUaGlzIGlnbm9yZXMgYnJp
ZGdlcy4KCkknbSBub3QgZmFtaWxpYXIgd2l0aCBicmlnZGVzLiBJJ2xsIHRyeSB0byB0YWtlIGEg
bG9vay4KCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqByID0gJmRldmljZXMtPmlvX3JlZ2lvbnNbal07
Cj4+ICsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoC8qIHNraXAgZGlmZmVyZW50IHJlc291cmNlIHR5
cGUsIGJ1dCBkb24ndCBza2lwIHdoZW4KPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCAqIHByZWZldGNo
IGFuZCBub24tcHJlZmV0Y2ggbWVtb3J5IGFyZSBjb21wYXJlZC4KPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCAqLwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgaWYgKHR5cGUgIT0gci0+dHlwZSkgewo+PiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgKHR5cGUgJiBQQ0lfQkFTRV9BRERSRVNTX1NQQUNF
X0lPIHx8Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByLT50eXBlICYgUENJX0JB
U0VfQUREUkVTU19TUEFDRV9JTykgewo+Cj4gRG8geW91IG1lYW4KPiDCoCDCoCDCoCDCoHR5cGUg
JiBQQ0lfQkFTRV9BRERSRVNTX1NQQUNFX0lPICE9IHItPnR5cGUgJgo+IFBDSV9CQVNFX0FERFJF
U1NfU1BBQ0VfSU8KPiA/Cj4KPiBUaGlzIHdvdWxkIG5vdCBuZWVkIGEgY29tbWVudCB0aGVuLgoK
WWVzLCBJJ2xsIHJlcGxhY2UgdGhhdC4KCj4KPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGNvbnRpbnVlOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfQo+PiArIMKgIMKgIMKg
IMKgIMKgIMKgfQo+PiArCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqBpZiAoKGFkZHIgPCAoci0+YWRk
ciArIHItPnNpemUpKSAmJiAoKGFkZHIgKyBzaXplKSA+IHItPmFkZHIpKSB7Cj4KPiBDYW4gcmFu
Z2VzX292ZXJsYXAgYmUgdXNlZD8KClllcy4KCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBw
cmludGYoIk92ZXJsYXBwZWQgdG8gZGV2aWNlWyUwMng6JTAyeC4leF1bUmVnaW9uOiVkXSIKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAiW0FkZHJlc3M6JSJQUkl4NjQiaF1b
U2l6ZTolIlBSSXg2NCJoXVxuIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBwY2lfYnVzX251bShidXMpLCBQQ0lfU0xPVChkZXZpY2VzLT5kZXZmbiksCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUENJX0ZVTkMoZGV2aWNlcy0+ZGV2Zm4pLCBqLCBy
LT5hZGRyLCByLT5zaXplKTsKPgo+Cj4gVGhhdCdzIG5vdCBob3cgb25lIHNob3VsZCByZXBvcnQg
ZXJyb3JzLgoKQSBjYWxsYmFjayB3b3VsZCBiZSBiZXR0ZXI/CgoKVGhhbmtzLAoKLS0gCkFudGhv
bnkgUEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 11:20:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 11:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2L6I-0000vC-89; Tue, 28 Feb 2012 11:20:10 +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 1S2L6H-0000v0-Dy
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 11:20:09 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330427944!53669596!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12285 invoked from network); 28 Feb 2012 11:19:05 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 11:19:05 -0000
Received: by obcuy19 with SMTP id uy19so8223818obc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 03:20:03 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.60.5.138 as permitted sender) client-ip=10.60.5.138; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.60.5.138 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.60.5.138])
	by 10.60.5.138 with SMTP id s10mr1562446oes.66.1330428003447 (num_hops
	= 1); Tue, 28 Feb 2012 03:20:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=0nreJt8W7/OPzn/SJP+/GD4ITv+nODyuo6wN02jWqeI=;
	b=RhzPyX7V7t+LGkMp8fWIJRku5z9nuDnMdBJvztuD0josryRcSM8XZAqj758Snj5Jlf
	AjFJyf+uupEWHmIfnRKOMlsSYd7+w6EggYwHLd+aChCFNQHWo3ibrupMlFmhATYZqpWI
	y0CftA+INEFEV+4gcaVaGRZM1RZh6pdlwsPG0=
Received: by 10.60.5.138 with SMTP id s10mr1361926oes.66.1330428003355; Tue,
	28 Feb 2012 03:20:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.14.105 with HTTP; Tue, 28 Feb 2012 03:19:33 -0800 (PST)
In-Reply-To: <20120219133549.GB16160@redhat.com>
References: <1329498525-8454-1-git-send-email-anthony.perard@citrix.com>
	<1329498525-8454-7-git-send-email-anthony.perard@citrix.com>
	<20120219133549.GB16160@redhat.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 28 Feb 2012 11:19:33 +0000
X-Google-Sender-Auth: fOAIu5U2J4ltdtsc93hmaZM1MuM
Message-ID: <CAJJyHjL0DKy71O4WnrP0bMLZNAj4u6EshJ9cFHL_yuqRoinoYQ@mail.gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V7 06/11] pci.c: Add
	pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCBGZWIgMTksIDIwMTIgYXQgMTM6MzUsIE1pY2hhZWwgUy4gVHNpcmtpbiA8bXN0QHJl
ZGhhdC5jb20+IHdyb3RlOgo+IE9uIEZyaSwgRmViIDE3LCAyMDEyIGF0IDA1OjA4OjQwUE0gKzAw
MDAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOgo+PiBGcm9tOiBZdWppIFNoaW1hZGEgPHNoaW1hZGEt
eXhiQG5lY3N0Lm5lYy5jby5qcD4KPj4KPj4gVGhpcyBmdW5jdGlvbiBoZWxwcyBYZW4gUENJIFBh
c3N0aHJvdWdoIGRldmljZSB0byBjaGVjayBmb3Igb3ZlcmxhcC4KPj4KPj4gU2lnbmVkLW9mZi1i
eTogWXVqaSBTaGltYWRhIDxzaGltYWRhLXl4YkBuZWNzdC5uZWMuY28uanA+Cj4+IFNpZ25lZC1v
ZmYtYnk6IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEBjaXRyaXguY29tPgo+Cj4gQXMg
ZmFyIGFzIEkgY2FuIHNlZSwgdGhpcyBzY2FucyB0aGUgYnVzIGEgc3BlY2lmaWMKPiBkZXZpY2Ug
aXMgb24sIGxvb2tpbmcgZm9yIGRldmljZXMgd2hvIGhhdmUgY29uZmxpY3RpbmcKPiBCQVJzLiBS
ZXR1cm5zIDEgaWYgZm91bmQsIDAgaWYgbm90Lgo+Cj4gTm90IHN1cmUgd2hhdCB3b3VsZCBkZXZp
Y2VzIGRvIHdpdGggdGhpcyBpbmZvcm1hdGlvbiwgcmVhbGx5Ogo+IHBhdGNoZXMgcG9zdGVkIGp1
c3QgcHJpbnQgb3V0IGEgd2FybmluZyB3aGljaCBkb2VzIG5vdCBzZWVtCj4gdG9vIHVzZWZ1bC4K
ClRoaXMgZnVuY3Rpb24gaXMganVzdCBoZXJlIHRvIHByaW50IGEgd2FybmluZyBpbiBjYXNlIGFu
IG92ZXJsYXAKaGFwcGVuLCBidXQgd2Ugd291bGQgbGlrZSB0b28ga2VlcCB0aGlzIHdhcm5pbmcu
Cgo+IEp1c3QgRllJLCBpZiB5b3UgZGVjaWRlZCB0byBlLmcuIGRpc2FibGUgZGV2aWNlIGluCj4g
c3VjaCBhIGNhc2UgdGhhdCB3b3VsZCBiZSB3cm9uZzogaXQgaXMgbGVnYWwgdG8gaGF2ZSBvdmVy
bGFwcGluZyBCQVJzIGFzCj4gbG9uZyBhcyB0aGVyZSBhcmUgbm8gYWNjZXNzZXMuCj4gU28gYSBs
ZWdhbCB0aGluZyBmb3IgYSBndWVzdCB0byBkbyBpczoKPgo+IEFzc2lnbiBCQVIxID0gYWJjZGUK
PiBBc3NpZ24gQkFSMiA9IGFiY2RlIDwtIG92ZXJsYXBzIHRlbXBvcmFyaWx5Cj4gQXNzaWduIEJB
UjEgPSAxMjM0NQo+Cj4gQW5kIHRoaXMgbWVhbnMgdGhhdCB5b3UgY2FuJ3QganVzdCBjaGVjayB5
b3VyIGRldmljZQo+IGhhcyBubyBjb25mbGljdHMgd2hlbiB5b3VyIGRldmljZSBpcyB0b3VjaGVk
Ogo+IGl0IG5lZWRzIHRvIGJlIGNoZWNrZWQgZWFjaCB0aW1lIG1hcHBpbmdzIGFyZSB1cGRhdGVk
Lgo+Cj4+IC0tLQo+PiDCoGh3L3BjaS5jIHwgwqAgNDcgKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysKPj4gwqBody9wY2kuaCB8IMKgIMKgMyArKysKPj4gwqAy
IGZpbGVzIGNoYW5nZWQsIDUwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCj4+Cj4+IGRp
ZmYgLS1naXQgYS9ody9wY2kuYyBiL2h3L3BjaS5jCj4+IGluZGV4IDY3OGE4YzEuLjc1ZDY1Mjkg
MTAwNjQ0Cj4+IC0tLSBhL2h3L3BjaS5jCj4+ICsrKyBiL2h3L3BjaS5jCj4+IEBAIC0xOTg1LDYg
KzE5ODUsNTMgQEAgTWVtb3J5UmVnaW9uICpwY2lfYWRkcmVzc19zcGFjZV9pbyhQQ0lEZXZpY2Ug
KmRldikKPj4gwqAgwqAgwqByZXR1cm4gZGV2LT5idXMtPmFkZHJlc3Nfc3BhY2VfaW87Cj4+IMKg
fQo+Pgo+PiAraW50IHBjaV9jaGVja19iYXJfb3ZlcmxhcChQQ0lEZXZpY2UgKmRldiwKPj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBjaWJ1c190IGFkZHIsIHBjaWJ1
c190IHNpemUsIHVpbnQ4X3QgdHlwZSkKPgo+IFRoaXMgbGFja3MgY29tbWVudHMgZG9jdW1lbnRu
ZyB3aGF0IHRoaXMgZG9lcywgcGFyYW1ldGVycywgcmV0dXJuCj4gdmFsdWVzLCBldGMuCgpJJ2xs
IGZpeCB0aGF0LgoKPj4gK3sKPj4gKyDCoCDCoFBDSUJ1cyAqYnVzID0gZGV2LT5idXM7Cj4+ICsg
wqAgwqBQQ0lEZXZpY2UgKmRldmljZXMgPSBOVUxMOwo+PiArIMKgIMKgUENJSU9SZWdpb24gKnI7
Cj4+ICsgwqAgwqBpbnQgaSwgajsKPj4gKyDCoCDCoGludCByYyA9IDA7Cj4+ICsKPj4gKyDCoCDC
oC8qIGNoZWNrIE92ZXJsYXBwZWQgdG8gQmFzZSBBZGRyZXNzICovCj4KPiBXZWlyZCB1c2Ugb2Yg
dXBwZXIgY2FzZS4gSW50ZW50aW9uYWw/Cj4gQWxzbyAtIHdoYXQgZG9lcyB0aGlzIGNvbW1lbnQg
bWVhbj8KCkRvbid0IGtub3csIEkgd2lsbCByZW1vdmUgdGhlIGNvbW1lbnQsIGl0IGlzIHVzZWxl
c3MuCgo+PiArIMKgIMKgZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUoYnVzLT5kZXZpY2VzKTsg
aSsrKSB7Cj4+ICsgwqAgwqAgwqAgwqBkZXZpY2VzID0gYnVzLT5kZXZpY2VzW2ldOwo+PiArIMKg
IMKgIMKgIMKgaWYgKCFkZXZpY2VzKSB7Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqBjb250aW51ZTsK
Pj4gKyDCoCDCoCDCoCDCoH0KPj4gKwo+PiArIMKgIMKgIMKgIMKgLyogc2tpcCBpdHNlbGYgKi8K
Pgo+IGl0c2VsZj8KClNhbWUgaGVyZSwgdGhlIGNvbW1lbnQgaXMgcHJvYmFibHkgdXNlbGVzcywg
dGhlIG5leHQgbGluZSBzaG91bGQgYmUKZWFzeSB0byB1bmRlcnN0YW5kLgoKPj4gKyDCoCDCoCDC
oCDCoGlmIChkZXZpY2VzLT5kZXZmbiA9PSBkZXYtPmRldmZuKSB7Cj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqBjb250aW51ZTsKPj4gKyDCoCDCoCDCoCDCoH0KPj4gKwo+PiArIMKgIMKgIMKgIMKgZm9y
IChqID0gMDsgaiA8IFBDSV9OVU1fUkVHSU9OUzsgaisrKSB7Cj4KPiBUaGlzIGlnbm9yZXMgYnJp
ZGdlcy4KCkknbSBub3QgZmFtaWxpYXIgd2l0aCBicmlnZGVzLiBJJ2xsIHRyeSB0byB0YWtlIGEg
bG9vay4KCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqByID0gJmRldmljZXMtPmlvX3JlZ2lvbnNbal07
Cj4+ICsKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoC8qIHNraXAgZGlmZmVyZW50IHJlc291cmNlIHR5
cGUsIGJ1dCBkb24ndCBza2lwIHdoZW4KPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCAqIHByZWZldGNo
IGFuZCBub24tcHJlZmV0Y2ggbWVtb3J5IGFyZSBjb21wYXJlZC4KPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCAqLwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgaWYgKHR5cGUgIT0gci0+dHlwZSkgewo+PiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgKHR5cGUgJiBQQ0lfQkFTRV9BRERSRVNTX1NQQUNF
X0lPIHx8Cj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByLT50eXBlICYgUENJX0JB
U0VfQUREUkVTU19TUEFDRV9JTykgewo+Cj4gRG8geW91IG1lYW4KPiDCoCDCoCDCoCDCoHR5cGUg
JiBQQ0lfQkFTRV9BRERSRVNTX1NQQUNFX0lPICE9IHItPnR5cGUgJgo+IFBDSV9CQVNFX0FERFJF
U1NfU1BBQ0VfSU8KPiA/Cj4KPiBUaGlzIHdvdWxkIG5vdCBuZWVkIGEgY29tbWVudCB0aGVuLgoK
WWVzLCBJJ2xsIHJlcGxhY2UgdGhhdC4KCj4KPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGNvbnRpbnVlOwo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfQo+PiArIMKgIMKgIMKg
IMKgIMKgIMKgfQo+PiArCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqBpZiAoKGFkZHIgPCAoci0+YWRk
ciArIHItPnNpemUpKSAmJiAoKGFkZHIgKyBzaXplKSA+IHItPmFkZHIpKSB7Cj4KPiBDYW4gcmFu
Z2VzX292ZXJsYXAgYmUgdXNlZD8KClllcy4KCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBw
cmludGYoIk92ZXJsYXBwZWQgdG8gZGV2aWNlWyUwMng6JTAyeC4leF1bUmVnaW9uOiVkXSIKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAiW0FkZHJlc3M6JSJQUkl4NjQiaF1b
U2l6ZTolIlBSSXg2NCJoXVxuIiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBwY2lfYnVzX251bShidXMpLCBQQ0lfU0xPVChkZXZpY2VzLT5kZXZmbiksCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUENJX0ZVTkMoZGV2aWNlcy0+ZGV2Zm4pLCBqLCBy
LT5hZGRyLCByLT5zaXplKTsKPgo+Cj4gVGhhdCdzIG5vdCBob3cgb25lIHNob3VsZCByZXBvcnQg
ZXJyb3JzLgoKQSBjYWxsYmFjayB3b3VsZCBiZSBiZXR0ZXI/CgoKVGhhbmtzLAoKLS0gCkFudGhv
bnkgUEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 11:25:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 11: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 1S2LB6-00014U-VI; Tue, 28 Feb 2012 11:25: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 1S2LB5-00014L-65
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 11:25:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330428276!65428485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25503 invoked from network); 28 Feb 2012 11:24:36 -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;
	28 Feb 2012 11:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10979475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11: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.213.0;
	Tue, 28 Feb 2012 11:25:01 +0000
Message-ID: <1330428299.31269.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 28 Feb 2012 11:24:59 +0000
In-Reply-To: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/2] arm: support fewer LR registers than
	virtual 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 Thu, 2012-02-23 at 17:00 +0000, Stefano Stabellini wrote:
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.

There is an ordering constraint on this list. It should be mentioned
somewhere in a comment.

> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   95 ++++++++++++++++++++++++++++++++----------
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 74 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..2ff7bce 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;
> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,50 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +    struct pending_irq *iter, *n;
> +
> +    spin_lock(&gic.lock);
> +
> +    if ( list_empty(&gic.lr_pending) )

This could really do with some comments.

The logic here is that if the "lr_pending" list has nothing in it then
there are no other IRQs queued waiting for an LR to become available and
therefore we can take a fast path and inject this IRQ directly?

> +    {
> +        i = find_first_zero_bit(&gic.lr_mask, sizeof(uint64_t));
> +        if (i < sizeof(uint64_t)) {

What does find_first_zero_bit(0xffff.fff, 64) return?

> +            set_bit(i, &gic.lr_mask);
> +            gic_set_lr(i, virtual_irq, state, priority);
> +            goto out;
> +        }
> +    }
> +
> +    n = irq_to_pending(current, virtual_irq);
> +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> +    {
> +        if ( iter->priority < priority )
> +        {
> +            list_add_tail(&n->lr_link, &iter->lr_link);
> +            goto out;
> +        }
> +    }
> +    list_add(&n->lr_link, &gic.lr_pending);

Should this be list_add_tail?

Lower numbers are higher priority and therefore the list should be
ordered from low->high, since we want to pull the next interrupt off the
front of the list. I don't think the above implements that though.

If we imagine a list containing priorities [2,4,6] into which we are
inserting a priority 5 interrupt.

On the first iteration of the loop iter->priority == 2 so "if
(iter->priority < priority)" is true and we insert 5 after 2 in the list
resulting in [2,5,4,6].

> +
> +out:
> +    spin_unlock(&gic.lock);
> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -431,30 +470,42 @@ void gicv_setup(struct domain *d)
>  
>  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
> -    int i, virq;
> +    int i = 0, virq;
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> -        if ( eisr & ((uint64_t)1 << i) ) {
> -            struct pending_irq *p;
> -
> -            lr = GICH[GICH_LR + i];
> -            virq = lr & GICH_LR_VIRTUAL_MASK;
> -            GICH[GICH_LR + i] = 0;
> -
> -            spin_lock(&current->arch.vgic.lock);
> -            p = irq_to_pending(current, virq);
> -            if ( p->desc != NULL ) {
> -                p->desc->status &= ~IRQ_INPROGRESS;
> -                GICC[GICC_DIR] = virq;
> -            }
> +    while ((i = find_next_bit((const long unsigned int *) &eisr,
> +                              sizeof(eisr), i)) < sizeof(eisr)) {

> +        struct pending_irq *p;
> +
> +        spin_lock(&gic.lock);
> +        lr = GICH[GICH_LR + i];
> +        virq = lr & GICH_LR_VIRTUAL_MASK;
> +        GICH[GICH_LR + i] = 0;
> +        clear_bit(i, &gic.lr_mask);
> +
> +        if ( !list_empty(gic.lr_pending.next) ) {

This seems odd, why not "list_empty(gic.lr_pending)"?

Otherwise won't you fail to inject anything if there is exactly one
entry on lr_pending?

> +            p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +            list_del_init(&p->lr_link);
> +            set_bit(i, &gic.lr_mask);
> +        } else {
>              gic_inject_irq_stop();
> -            list_del(&p->link);
> -            INIT_LIST_HEAD(&p->link);
> -            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> -            spin_unlock(&current->arch.vgic.lock);
>          }
> +        spin_unlock(&gic.lock);
> +
> +        spin_lock(&current->arch.vgic.lock);
> +        p = irq_to_pending(current, virq);
> +        if ( p->desc != NULL ) {
> +            p->desc->status &= ~IRQ_INPROGRESS;
> +            GICC[GICC_DIR] = virq;
> +        }
> +        list_del(&p->link);
> +        INIT_LIST_HEAD(&p->link);
> +        cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> +        spin_unlock(&current->arch.vgic.lock);
> +
> +        i++;

Does find_next_bit include or exclude the bit which you give it as the
3rd argument?

>      }
>  }
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;

Calling this "link" or "lr_link" when it is used in the context or link
registers (e.g. link-register_link) just adds to the confusion around
these two lists IMHO, as does having one just called link and the other
prefix_link. Calling them foo_list, both with a descriptive prefix,
would be better, e.g. active_list and queued_list (or whatever you deem
appropriate to their semantics)

Even better would be if the invariant "always on either active or
pending lists, never both" were true -- in which case only one list_head
would be needed here.

What do we actually use "link" for? It is chained off vgic.inflight_irqs
but we seem to only use it for anything other than manipulating itself
in vgic_softirq where it is used as a binary "something to inject" flag
-- we could just as well maintain a nr_inflight variable if that were
the case, couldn't we?

Ian.

>  };
>  
>  struct arch_domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 11:25:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 11: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 1S2LB6-00014U-VI; Tue, 28 Feb 2012 11:25: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 1S2LB5-00014L-65
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 11:25:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330428276!65428485!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25503 invoked from network); 28 Feb 2012 11:24:36 -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;
	28 Feb 2012 11:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10979475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11: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.213.0;
	Tue, 28 Feb 2012 11:25:01 +0000
Message-ID: <1330428299.31269.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 28 Feb 2012 11:24:59 +0000
In-Reply-To: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/2] arm: support fewer LR registers than
	virtual 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 Thu, 2012-02-23 at 17:00 +0000, Stefano Stabellini wrote:
> If the vgic needs to inject a virtual irq into the guest, but no free
> LR registers are available, add the irq to a list and return.

There is an ordering constraint on this list. It should be mentioned
somewhere in a comment.

> Whenever an LR register becomes available we add the queued irq to it
> and remove it from the list.
> We use the gic lock to protect the list and the bitmask.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c           |   95 ++++++++++++++++++++++++++++++++----------
>  xen/include/asm-arm/domain.h |    1 +
>  2 files changed, 74 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index adc10bb..2ff7bce 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -25,6 +25,7 @@
>  #include <xen/sched.h>
>  #include <xen/errno.h>
>  #include <xen/softirq.h>
> +#include <xen/list.h>
>  #include <asm/p2m.h>
>  #include <asm/domain.h>
>  
> @@ -45,6 +46,8 @@ static struct {
>      unsigned int lines;
>      unsigned int cpus;
>      spinlock_t lock;
> +    uint64_t lr_mask;
> +    struct list_head lr_pending;
>  } gic;
>  
>  irq_desc_t irq_desc[NR_IRQS];
> @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
>  
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      GICH[GICH_MISR] = GICH_MISR_EOI;
> +    gic.lr_mask = 0ULL;
> +    INIT_LIST_HEAD(&gic.lr_pending);
>  }
>  
>  /* Set up the GIC */
> @@ -345,16 +350,50 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
>      return rc;
>  }
>  
> -void gic_set_guest_irq(unsigned int virtual_irq,
> +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
>          unsigned int state, unsigned int priority)
>  {
> -    BUG_ON(virtual_irq > nr_lrs);
> -    GICH[GICH_LR + virtual_irq] = state |
> +    BUG_ON(lr > nr_lrs);
> +    GICH[GICH_LR + lr] = state |
>          GICH_LR_MAINTENANCE_IRQ |
>          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
>          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
>  }
>  
> +void gic_set_guest_irq(unsigned int virtual_irq,
> +        unsigned int state, unsigned int priority)
> +{
> +    int i;
> +    struct pending_irq *iter, *n;
> +
> +    spin_lock(&gic.lock);
> +
> +    if ( list_empty(&gic.lr_pending) )

This could really do with some comments.

The logic here is that if the "lr_pending" list has nothing in it then
there are no other IRQs queued waiting for an LR to become available and
therefore we can take a fast path and inject this IRQ directly?

> +    {
> +        i = find_first_zero_bit(&gic.lr_mask, sizeof(uint64_t));
> +        if (i < sizeof(uint64_t)) {

What does find_first_zero_bit(0xffff.fff, 64) return?

> +            set_bit(i, &gic.lr_mask);
> +            gic_set_lr(i, virtual_irq, state, priority);
> +            goto out;
> +        }
> +    }
> +
> +    n = irq_to_pending(current, virtual_irq);
> +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> +    {
> +        if ( iter->priority < priority )
> +        {
> +            list_add_tail(&n->lr_link, &iter->lr_link);
> +            goto out;
> +        }
> +    }
> +    list_add(&n->lr_link, &gic.lr_pending);

Should this be list_add_tail?

Lower numbers are higher priority and therefore the list should be
ordered from low->high, since we want to pull the next interrupt off the
front of the list. I don't think the above implements that though.

If we imagine a list containing priorities [2,4,6] into which we are
inserting a priority 5 interrupt.

On the first iteration of the loop iter->priority == 2 so "if
(iter->priority < priority)" is true and we insert 5 after 2 in the list
resulting in [2,5,4,6].

> +
> +out:
> +    spin_unlock(&gic.lock);
> +    return;
> +}
> +
>  void gic_inject_irq_start(void)
>  {
>      uint32_t hcr;
> @@ -431,30 +470,42 @@ void gicv_setup(struct domain *d)
>  
>  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
>  {
> -    int i, virq;
> +    int i = 0, virq;
>      uint32_t lr;
>      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
>  
> -    for ( i = 0; i < 64; i++ ) {
> -        if ( eisr & ((uint64_t)1 << i) ) {
> -            struct pending_irq *p;
> -
> -            lr = GICH[GICH_LR + i];
> -            virq = lr & GICH_LR_VIRTUAL_MASK;
> -            GICH[GICH_LR + i] = 0;
> -
> -            spin_lock(&current->arch.vgic.lock);
> -            p = irq_to_pending(current, virq);
> -            if ( p->desc != NULL ) {
> -                p->desc->status &= ~IRQ_INPROGRESS;
> -                GICC[GICC_DIR] = virq;
> -            }
> +    while ((i = find_next_bit((const long unsigned int *) &eisr,
> +                              sizeof(eisr), i)) < sizeof(eisr)) {

> +        struct pending_irq *p;
> +
> +        spin_lock(&gic.lock);
> +        lr = GICH[GICH_LR + i];
> +        virq = lr & GICH_LR_VIRTUAL_MASK;
> +        GICH[GICH_LR + i] = 0;
> +        clear_bit(i, &gic.lr_mask);
> +
> +        if ( !list_empty(gic.lr_pending.next) ) {

This seems odd, why not "list_empty(gic.lr_pending)"?

Otherwise won't you fail to inject anything if there is exactly one
entry on lr_pending?

> +            p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> +            list_del_init(&p->lr_link);
> +            set_bit(i, &gic.lr_mask);
> +        } else {
>              gic_inject_irq_stop();
> -            list_del(&p->link);
> -            INIT_LIST_HEAD(&p->link);
> -            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> -            spin_unlock(&current->arch.vgic.lock);
>          }
> +        spin_unlock(&gic.lock);
> +
> +        spin_lock(&current->arch.vgic.lock);
> +        p = irq_to_pending(current, virq);
> +        if ( p->desc != NULL ) {
> +            p->desc->status &= ~IRQ_INPROGRESS;
> +            GICC[GICC_DIR] = virq;
> +        }
> +        list_del(&p->link);
> +        INIT_LIST_HEAD(&p->link);
> +        cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> +        spin_unlock(&current->arch.vgic.lock);
> +
> +        i++;

Does find_next_bit include or exclude the bit which you give it as the
3rd argument?

>      }
>  }
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 3372d14..75095ff 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -21,6 +21,7 @@ struct pending_irq
>      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
>      uint8_t priority;
>      struct list_head link;
> +    struct list_head lr_link;

Calling this "link" or "lr_link" when it is used in the context or link
registers (e.g. link-register_link) just adds to the confusion around
these two lists IMHO, as does having one just called link and the other
prefix_link. Calling them foo_list, both with a descriptive prefix,
would be better, e.g. active_list and queued_list (or whatever you deem
appropriate to their semantics)

Even better would be if the invariant "always on either active or
pending lists, never both" were true -- in which case only one list_head
would be needed here.

What do we actually use "link" for? It is chained off vgic.inflight_irqs
but we seem to only use it for anything other than manipulating itself
in vgic_softirq where it is used as a binary "something to inject" flag
-- we could just as well maintain a nr_inflight variable if that were
the case, couldn't we?

Ian.

>  };
>  
>  struct arch_domain



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:15:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2LxT-0001XV-Or; Tue, 28 Feb 2012 12:15:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2LxS-0001XQ-6m
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:15:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330431300!15256735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9558 invoked from network); 28 Feb 2012 12:15:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:15:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10980931"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:15:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 12:15:00 +0000
Date: Tue, 28 Feb 2012 12:21:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120228094616.GA2063@linaro.org>
Message-ID: <alpine.DEB.2.00.1202281131550.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120227175327.GA2023@linaro.org>
	<1330372125.10008.47.camel@dagon.hellion.org.uk>
	<20120228094616.GA2063@linaro.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 28 Feb 2012, Dave Martin wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the construction with the __HVC_IMM stuff
> > -- that would remove a big bit of the macroization.
> 
> It's not quite as simple as that -- emitting instructions using data
> directives is not endianness safe, and even in the cases where .long gives
> the right result for ARM, it gives the wrong result for 32-bit Thumb
> instructions if the opcode is given in human-readable order.
> 
> I was trying to solve the same problem for the kvm guys with some global
> macros -- I'm aiming to get a patch posted soon, so I'll make sure
> you're on CC.
 
That would be great, thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:15:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2LxT-0001XV-Or; Tue, 28 Feb 2012 12:15:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2LxS-0001XQ-6m
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:15:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330431300!15256735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9558 invoked from network); 28 Feb 2012 12:15:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:15:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10980931"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:15:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 12:15:00 +0000
Date: Tue, 28 Feb 2012 12:21:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120228094616.GA2063@linaro.org>
Message-ID: <alpine.DEB.2.00.1202281131550.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120227175327.GA2023@linaro.org>
	<1330372125.10008.47.camel@dagon.hellion.org.uk>
	<20120228094616.GA2063@linaro.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 28 Feb 2012, Dave Martin wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the construction with the __HVC_IMM stuff
> > -- that would remove a big bit of the macroization.
> 
> It's not quite as simple as that -- emitting instructions using data
> directives is not endianness safe, and even in the cases where .long gives
> the right result for ARM, it gives the wrong result for 32-bit Thumb
> instructions if the opcode is given in human-readable order.
> 
> I was trying to solve the same problem for the kvm guys with some global
> macros -- I'm aiming to get a patch posted soon, so I'll make sure
> you're on CC.
 
That would be great, thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:22:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2M47-0001hs-JJ; Tue, 28 Feb 2012 12:21:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2M46-0001hg-8l
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:21:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330431711!15288440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22544 invoked from network); 28 Feb 2012 12:21:52 -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;
	28 Feb 2012 12:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10981099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:21:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 12:21:52 +0000
Date: Tue, 28 Feb 2012 12:28:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330426133.31269.70.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
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>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 28 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-28 at 10:20 +0000, Dave Martin wrote:
> > On Mon, Feb 27, 2012 at 07:33:39PM +0000, Ian Campbell wrote:
> > > On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote:
> > > > > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > > > > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > > > > instructions.
> > > > > 
> > > > > Should we use r7 instead to maximise instruction density for Thumb code?
> > > > 
> > > > The difference seems trivial when put into context, even if you code a
> > > > special Thumb version of the code to maximise density (the Thumb-2 code
> > > > which gets built from assembler in the kernel is very suboptimal in
> > > > size, but there simply isn't a high proportion of asm code in the kernel
> > > > anyway.)  I wouldn't consider the ARM/Thumb differences as an important
> > > > factor when deciding on a register.
> > > 
> > > OK, that's useful information. thanks.
> > > 
> > > > One argument for _not_ using r12 for this purpose is that it is then
> > > > harder to put a generic "HVC" function (analogous to the "syscall"
> > > > syscall) out-of-line, since r12 could get destroyed by the call.
> > > 
> > > For an out of line syscall(2) wouldn't the syscall number either be in a
> > > standard C calling convention argument register or on the stack when the
> > > function was called, since it is just a normal argument at that point?
> > > As you point out it cannot be passed in r12 (and could never be, due to
> > > the clobbering).
> > > 
> > > The syscall function itself would have to move the arguments and syscall
> > > nr etc around before issuing the syscall.
> > > 
> > > I think the same is true of a similar hypercall(2)
> > > 
> > > > If you don't think you will ever care about putting HVC out of line
> > > > though, it may not matter.
> > 
> > If you have both inline and out-of-line hypercalls, it's hard to ensure
> > that you never have to shuffle the registers in either case.
> 
> Agreed.
> 
> I think we want to optimise for the inline case since those are the
> majority.

They are not just the majority, all of them are static inline at the
moment, even on x86 (where the number of hypercalls is much higher).

So yes, we should optimize for the inline case.


> The only non-inline case is the special "privcmd ioctl" which is the
> mechanism that allows the Xen toolstack to make hypercalls. It's
> somewhat akin to syscall(2). By the time you get to it you will already
> have done a system call for the ioctl, pulled the arguments from the
> ioctl argument structure etc, plus such hypercalls are not really
> performance critical.

Even the privcmd hypercall (privcmd_call) is a static inline function,
it is just that at the moment there is only one caller :)


> > Shuffling can be reduced but only at the expense of strange argument
> > ordering in some cases when calling from C -- the complexity is probably
> > not worth it.  Linux doesn't bother for its own syscalls.
> > 
> > Note that even in assembler, a branch from one section to a label in
> > another section may cause r12 to get destroyed, so you will need to be
> > careful about how you code the hypervisor trap handler.  However, this
> > is not different from coding exception handlers in general, so I don't
> > know that it constitutes a conclusive argument on its own.
> 
> We are happy to arrange that this doesn't occur on our trap entry paths,
> at least until the guest register state has been saved. Currently the
> hypercall dispatcher is in C and gets r12 from the on-stack saved state.
> We will likely eventually optimise the hypercall path directly in ASM
> and in that case we are happy to take steps to ensure we don't clobber
> r12 before we need it.

Yes, I don't think this should be an issue.


> > My instinctive preference would therefore be for r7 (which also seems to
> > be good enough for Linux syscalls) -- but it really depends how many
> > arguments you expect to need to support.
> 
> Apparently r7 is the frame pointer for gcc in thumb mode which I think
> is a good reason to avoid it.
> 
> We currently have some 5 argument hypercalls and there have been
> occasional suggestions for interfaces which use 6 -- although none of
> them have come to reality.
 
I don't have a very strong opinion on which register we should use, but
I would like to avoid r7 if it is already actively used by gcc.

The fact that r12 can be destroyed so easily is actually a good argument
for using it because it means it is less likely to contain useful data
that needs to be saved/restored by gcc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:22:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2M47-0001hs-JJ; Tue, 28 Feb 2012 12:21:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2M46-0001hg-8l
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:21:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330431711!15288440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22544 invoked from network); 28 Feb 2012 12:21:52 -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;
	28 Feb 2012 12:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="10981099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:21:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 12:21:52 +0000
Date: Tue, 28 Feb 2012 12:28:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330426133.31269.70.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
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>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 28 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-28 at 10:20 +0000, Dave Martin wrote:
> > On Mon, Feb 27, 2012 at 07:33:39PM +0000, Ian Campbell wrote:
> > > On Mon, 2012-02-27 at 18:03 +0000, Dave Martin wrote:
> > > > > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > > > > which do allow direct mov of an immediate into R12, but are 32 bit Thumb
> > > > > instructions.
> > > > > 
> > > > > Should we use r7 instead to maximise instruction density for Thumb code?
> > > > 
> > > > The difference seems trivial when put into context, even if you code a
> > > > special Thumb version of the code to maximise density (the Thumb-2 code
> > > > which gets built from assembler in the kernel is very suboptimal in
> > > > size, but there simply isn't a high proportion of asm code in the kernel
> > > > anyway.)  I wouldn't consider the ARM/Thumb differences as an important
> > > > factor when deciding on a register.
> > > 
> > > OK, that's useful information. thanks.
> > > 
> > > > One argument for _not_ using r12 for this purpose is that it is then
> > > > harder to put a generic "HVC" function (analogous to the "syscall"
> > > > syscall) out-of-line, since r12 could get destroyed by the call.
> > > 
> > > For an out of line syscall(2) wouldn't the syscall number either be in a
> > > standard C calling convention argument register or on the stack when the
> > > function was called, since it is just a normal argument at that point?
> > > As you point out it cannot be passed in r12 (and could never be, due to
> > > the clobbering).
> > > 
> > > The syscall function itself would have to move the arguments and syscall
> > > nr etc around before issuing the syscall.
> > > 
> > > I think the same is true of a similar hypercall(2)
> > > 
> > > > If you don't think you will ever care about putting HVC out of line
> > > > though, it may not matter.
> > 
> > If you have both inline and out-of-line hypercalls, it's hard to ensure
> > that you never have to shuffle the registers in either case.
> 
> Agreed.
> 
> I think we want to optimise for the inline case since those are the
> majority.

They are not just the majority, all of them are static inline at the
moment, even on x86 (where the number of hypercalls is much higher).

So yes, we should optimize for the inline case.


> The only non-inline case is the special "privcmd ioctl" which is the
> mechanism that allows the Xen toolstack to make hypercalls. It's
> somewhat akin to syscall(2). By the time you get to it you will already
> have done a system call for the ioctl, pulled the arguments from the
> ioctl argument structure etc, plus such hypercalls are not really
> performance critical.

Even the privcmd hypercall (privcmd_call) is a static inline function,
it is just that at the moment there is only one caller :)


> > Shuffling can be reduced but only at the expense of strange argument
> > ordering in some cases when calling from C -- the complexity is probably
> > not worth it.  Linux doesn't bother for its own syscalls.
> > 
> > Note that even in assembler, a branch from one section to a label in
> > another section may cause r12 to get destroyed, so you will need to be
> > careful about how you code the hypervisor trap handler.  However, this
> > is not different from coding exception handlers in general, so I don't
> > know that it constitutes a conclusive argument on its own.
> 
> We are happy to arrange that this doesn't occur on our trap entry paths,
> at least until the guest register state has been saved. Currently the
> hypercall dispatcher is in C and gets r12 from the on-stack saved state.
> We will likely eventually optimise the hypercall path directly in ASM
> and in that case we are happy to take steps to ensure we don't clobber
> r12 before we need it.

Yes, I don't think this should be an issue.


> > My instinctive preference would therefore be for r7 (which also seems to
> > be good enough for Linux syscalls) -- but it really depends how many
> > arguments you expect to need to support.
> 
> Apparently r7 is the frame pointer for gcc in thumb mode which I think
> is a good reason to avoid it.
> 
> We currently have some 5 argument hypercalls and there have been
> occasional suggestions for interfaces which use 6 -- although none of
> them have come to reality.
 
I don't have a very strong opinion on which register we should use, but
I would like to avoid r7 if it is already actively used by gcc.

The fact that r12 can be destroyed so easily is actually a good argument
for using it because it means it is less likely to contain useful data
that needs to be saved/restored by gcc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:39:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MKs-00027r-OZ; Tue, 28 Feb 2012 12:39: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 1S2MKr-00027m-9X
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:39:17 +0000
Received: from [85.158.139.83:30624] by server-2.bemta-5.messagelabs.com id
	E4/58-20263-4FACC4F4; Tue, 28 Feb 2012 12:39:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330432755!16185873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3065 invoked from network); 28 Feb 2012 12:39:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:39:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:39:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 12:39:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2MKo-0007S0-OW; Tue, 28 Feb 2012 12:39:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2MKo-00022R-Ki;
	Tue, 28 Feb 2012 12:39:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20300.51954.552010.422304@mariner.uk.xensource.com>
Date: Tue, 28 Feb 2012 12:39:14 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330346266.8557.282.camel@zakaz.uk.xensource.com>
References: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
	<1330346266.8557.282.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] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel hypercalls to improve generated docs"):
> Actually, the intro from that chapter is interesting/useful and I missed
> it. Here's a new version with it included.
...
> hcall: markup the event channel hypercalls to improve generated docs

Good stuff.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Also, as requested:

commit 78ed3b5816ed60e7e86810c2d93069fae63dc406
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Tue Feb 28 12:36:15 2012 +0000

    docs: xen-headers: Annotate typedefs
    
    Parse (some) typedef statements.  (Make type names links to the
    underlying struct if there is one, rather than to just the typedef.)
    
    Also, exclude the new arch-arm headers.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/docs/Makefile b/docs/Makefile
index 49e33cb..007a5a9 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -120,7 +120,7 @@ html/hypercall/index.html: ./xen-headers
 	@$(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-ia64 -X arch-x86_32 -X xen-x86_32 -X arch-arm \
 		../xen include/public include/xen/errno.h
 
 -include html/hypercall/.deps
diff --git a/docs/xen-headers b/docs/xen-headers
index 08fd7f3..68c9504 100755
--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -120,11 +120,12 @@ sub aelem ($$$) {
     return "<a $hparams>$ytext</a>";
 }
 
-sub defn ($$$;$) {
-    my ($text,$type,$name,$hparams) = @_;
+sub defn ($$$;$$) {
+    my ($text,$type,$name,$hparams,$deref) = @_;
     $hparams='' if !defined $hparams;
-    debug(2,"DEFN $. $type $name $hparams");
+    debug(2,"DEFN $. $type $name $hparams |$text|");
     $sdef{$type}{$name}{DefLocs}{"$leaf:$."} = $leaf_opath;
+    $sdef{$type}{$name}{Derefs}{"$leaf:$."} = $deref;
     my $xrefs = $sdef{$type}{$name}{Xrefs};
     push @pending_xrefs, values %$xrefs if $xrefs;
     $hparams .= " name=\"${type}_$name\"" if $sdef{$type}{$name}{Used};
@@ -140,7 +141,7 @@ sub norm ($) {
 	} elsif (s/^(struct|union|enum)\s+(\w+)\b//) {
 	    $no .= ahref($&, (ucfirst $1), $2);
 	} elsif (s/^\w+\b//) {
-	    $no .= ahref($&, 'Func', $&);
+	    $no .= ahref($&, [qw(Func Typedef)], $&);
 	} else {
 	    die "$_ ?";
 	}
@@ -148,18 +149,48 @@ sub norm ($) {
     return $no;
 }
 
-sub refhref ($$) {
-    my ($type,$name) = @_;
+sub sdefval ($$$) {
+    my ($type,$name,$hkey) = @_;
     $sdef{$type}{$name}{Used} = 1;
-    my $locs = $sdef{$type}{$name}{DefLocs};
-    return '' unless $locs;
-    if ((scalar keys %$locs) != 1 && !$sdef{$type}{$name}{MultiWarned}) {
-	warning("multiple definitions of $type $name: $_")
-	    foreach keys %$locs;
-	$sdef{$type}{$name}{MultiWarned}=1;
+    my $sdef = $sdef{$type}{$name};
+    my $hash = $sdef->{$hkey};
+    if ((scalar keys %$hash) > 1 && !$sdef->{MultiWarned}{$hkey}) {
+        warning("multiple definitions of $type $name: $_")
+            foreach keys %$hash;
+        $sdef->{MultiWarned}{$hkey}=1;
+    }
+    my ($val) = values %$hash;
+    return $val;
+}
+
+sub refhref ($$) {
+    my ($types,$name) = @_;
+    foreach my $type (ref($types) ? @$types : ($types)) {
+        my ($ttype,$tname) = ($type,$name);
+        my $loc = sdefval($ttype,$tname,'DefLocs');
+        for (;;) {
+            my $deref = sdefval($ttype,$tname,'Derefs');
+            last unless $deref;
+            my ($type2,$name2,$loc2);
+            my @deref = @$deref;
+ if ($name eq 'buf_ioreq_t') {
+     print STDERR "REFHREF $type $name | $ttype $tname | @deref\n";
+ }
+            while (@deref) {
+                ($type2,$name2,@deref) = @deref;
+                $loc2 = sdefval($type2,$name2,'DefLocs');
+ if ($name eq 'buf_ioreq_t') {
+     print STDERR "REFHREF $type $name | $ttype $tname | $type2 $name2 GOT $loc2\n";
+ }
+                last if defined $loc2;
+            }
+            last unless defined $loc2;
+            ($loc,$ttype,$tname) = ($loc2,$type2,$name2);
+        }
+        next unless defined $loc;
+        return "href=\"$loc#${ttype}_$tname\"";
     }
-    my ($loc) = values %$locs;
-    return "href=\"$loc#${type}_$name\"";
+    return '';
 }
 
 sub ahref ($$$) {
@@ -259,6 +290,14 @@ sub process_file ($$) {
 		    in_enum($1,(ucfirst $2),$3);
 	        }
 	    }
+	} elsif (s/^(typedef \s+ )((struct|union|enum) \  (\w+))
+                      (\s+) (\w+)(\;)$
+                  / norm($1).norm($2).$5.
+                    defn($6,'Typedef',$6,undef,[(ucfirst $3),$4]).
+                    $7 /xe) {
+        } elsif (s/^(typedef \s+) (\w+) (\s+) (\w+) (\;)$
+                  / $1.norm($2).$3.
+                    defn($4,'Typedef',$4,undef,['Typedef',$2]). $5 /xe) {
 	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
                   / $1.defmacro($2).norm($3) /xe) {
 	} elsif (s/( \`incontents \s+ (\d+) \s+ (\w+) \s+ )(\S .* \S)
@@ -315,6 +354,7 @@ END
     $forkind->('Func','Functions','','()');
     $forkind->('Struct','Structs','struct ','');
     $forkind->('Enum','Enums and sets of #defines','','');
+    $forkind->('Typedef','Typedefs','typedef ','');
     $forkind->('EnumVal','Enum values and individual #defines','','');
     $o .= "</ul>\n<h2>Files</h2><ul>\n";
     foreach my $of (sort { $a->[0] cmp $b->[0] } @outfiles) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:39:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MKs-00027r-OZ; Tue, 28 Feb 2012 12:39: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 1S2MKr-00027m-9X
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:39:17 +0000
Received: from [85.158.139.83:30624] by server-2.bemta-5.messagelabs.com id
	E4/58-20263-4FACC4F4; Tue, 28 Feb 2012 12:39:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330432755!16185873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3065 invoked from network); 28 Feb 2012 12:39:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:39:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:39:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 12:39:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2MKo-0007S0-OW; Tue, 28 Feb 2012 12:39:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2MKo-00022R-Ki;
	Tue, 28 Feb 2012 12:39:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20300.51954.552010.422304@mariner.uk.xensource.com>
Date: Tue, 28 Feb 2012 12:39:14 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330346266.8557.282.camel@zakaz.uk.xensource.com>
References: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
	<1330346266.8557.282.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] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel hypercalls to improve generated docs"):
> Actually, the intro from that chapter is interesting/useful and I missed
> it. Here's a new version with it included.
...
> hcall: markup the event channel hypercalls to improve generated docs

Good stuff.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Also, as requested:

commit 78ed3b5816ed60e7e86810c2d93069fae63dc406
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Tue Feb 28 12:36:15 2012 +0000

    docs: xen-headers: Annotate typedefs
    
    Parse (some) typedef statements.  (Make type names links to the
    underlying struct if there is one, rather than to just the typedef.)
    
    Also, exclude the new arch-arm headers.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/docs/Makefile b/docs/Makefile
index 49e33cb..007a5a9 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -120,7 +120,7 @@ html/hypercall/index.html: ./xen-headers
 	@$(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-ia64 -X arch-x86_32 -X xen-x86_32 -X arch-arm \
 		../xen include/public include/xen/errno.h
 
 -include html/hypercall/.deps
diff --git a/docs/xen-headers b/docs/xen-headers
index 08fd7f3..68c9504 100755
--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -120,11 +120,12 @@ sub aelem ($$$) {
     return "<a $hparams>$ytext</a>";
 }
 
-sub defn ($$$;$) {
-    my ($text,$type,$name,$hparams) = @_;
+sub defn ($$$;$$) {
+    my ($text,$type,$name,$hparams,$deref) = @_;
     $hparams='' if !defined $hparams;
-    debug(2,"DEFN $. $type $name $hparams");
+    debug(2,"DEFN $. $type $name $hparams |$text|");
     $sdef{$type}{$name}{DefLocs}{"$leaf:$."} = $leaf_opath;
+    $sdef{$type}{$name}{Derefs}{"$leaf:$."} = $deref;
     my $xrefs = $sdef{$type}{$name}{Xrefs};
     push @pending_xrefs, values %$xrefs if $xrefs;
     $hparams .= " name=\"${type}_$name\"" if $sdef{$type}{$name}{Used};
@@ -140,7 +141,7 @@ sub norm ($) {
 	} elsif (s/^(struct|union|enum)\s+(\w+)\b//) {
 	    $no .= ahref($&, (ucfirst $1), $2);
 	} elsif (s/^\w+\b//) {
-	    $no .= ahref($&, 'Func', $&);
+	    $no .= ahref($&, [qw(Func Typedef)], $&);
 	} else {
 	    die "$_ ?";
 	}
@@ -148,18 +149,48 @@ sub norm ($) {
     return $no;
 }
 
-sub refhref ($$) {
-    my ($type,$name) = @_;
+sub sdefval ($$$) {
+    my ($type,$name,$hkey) = @_;
     $sdef{$type}{$name}{Used} = 1;
-    my $locs = $sdef{$type}{$name}{DefLocs};
-    return '' unless $locs;
-    if ((scalar keys %$locs) != 1 && !$sdef{$type}{$name}{MultiWarned}) {
-	warning("multiple definitions of $type $name: $_")
-	    foreach keys %$locs;
-	$sdef{$type}{$name}{MultiWarned}=1;
+    my $sdef = $sdef{$type}{$name};
+    my $hash = $sdef->{$hkey};
+    if ((scalar keys %$hash) > 1 && !$sdef->{MultiWarned}{$hkey}) {
+        warning("multiple definitions of $type $name: $_")
+            foreach keys %$hash;
+        $sdef->{MultiWarned}{$hkey}=1;
+    }
+    my ($val) = values %$hash;
+    return $val;
+}
+
+sub refhref ($$) {
+    my ($types,$name) = @_;
+    foreach my $type (ref($types) ? @$types : ($types)) {
+        my ($ttype,$tname) = ($type,$name);
+        my $loc = sdefval($ttype,$tname,'DefLocs');
+        for (;;) {
+            my $deref = sdefval($ttype,$tname,'Derefs');
+            last unless $deref;
+            my ($type2,$name2,$loc2);
+            my @deref = @$deref;
+ if ($name eq 'buf_ioreq_t') {
+     print STDERR "REFHREF $type $name | $ttype $tname | @deref\n";
+ }
+            while (@deref) {
+                ($type2,$name2,@deref) = @deref;
+                $loc2 = sdefval($type2,$name2,'DefLocs');
+ if ($name eq 'buf_ioreq_t') {
+     print STDERR "REFHREF $type $name | $ttype $tname | $type2 $name2 GOT $loc2\n";
+ }
+                last if defined $loc2;
+            }
+            last unless defined $loc2;
+            ($loc,$ttype,$tname) = ($loc2,$type2,$name2);
+        }
+        next unless defined $loc;
+        return "href=\"$loc#${ttype}_$tname\"";
     }
-    my ($loc) = values %$locs;
-    return "href=\"$loc#${type}_$name\"";
+    return '';
 }
 
 sub ahref ($$$) {
@@ -259,6 +290,14 @@ sub process_file ($$) {
 		    in_enum($1,(ucfirst $2),$3);
 	        }
 	    }
+	} elsif (s/^(typedef \s+ )((struct|union|enum) \  (\w+))
+                      (\s+) (\w+)(\;)$
+                  / norm($1).norm($2).$5.
+                    defn($6,'Typedef',$6,undef,[(ucfirst $3),$4]).
+                    $7 /xe) {
+        } elsif (s/^(typedef \s+) (\w+) (\s+) (\w+) (\;)$
+                  / $1.norm($2).$3.
+                    defn($4,'Typedef',$4,undef,['Typedef',$2]). $5 /xe) {
 	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
                   / $1.defmacro($2).norm($3) /xe) {
 	} elsif (s/( \`incontents \s+ (\d+) \s+ (\w+) \s+ )(\S .* \S)
@@ -315,6 +354,7 @@ END
     $forkind->('Func','Functions','','()');
     $forkind->('Struct','Structs','struct ','');
     $forkind->('Enum','Enums and sets of #defines','','');
+    $forkind->('Typedef','Typedefs','typedef ','');
     $forkind->('EnumVal','Enum values and individual #defines','','');
     $o .= "</ul>\n<h2>Files</h2><ul>\n";
     foreach my $of (sort { $a->[0] cmp $b->[0] } @outfiles) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12: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 1S2MMU-0002DI-7p; Tue, 28 Feb 2012 12:40:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MMS-0002Ck-JY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:40:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330432850!9188738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4072 invoked from network); 28 Feb 2012 12:40:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:40:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:40:49 +0000
Message-ID: <1330432847.31269.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Tue, 28 Feb 2012 12:40:47 +0000
In-Reply-To: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
References: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v2] Add the bios 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


> [Patch v2] Add the bios option to specify the bios to load.
> 
> Please note 2 things:
> - I've used the name of 'OVMF' rather than adding the arch postfix 
> because we are going to make this code arch-size agnostic (in another
> patch)
> - Other seems missing in xl.cfg.pod5, like firmware_override

:-( If you notice such please add them, with an XXX is fine. In this
case I thought I saw a patch from Olaf adding a bunch of missing
options.

> 
> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

> On Fri, 2012-02-24 at 18:24 +0000, Attilio Rao wrote:
> diff -r adcd6ab160fa -r 20ea6f881776 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 24 18:19:56 2012 +0000
> @@ -430,6 +430,12 @@ accept the defaults for these options wh
>  
>  =over 4
>  
> +=item B<bios="STRING">

Can we enumerate the valid values of "STRING" here and their
requirements (even if we aren't enforcing them) WRT which
device_model_version they can be used with.

> +Load the specified BIOS in HVMLOADER. By default, HVMLOADER will try
> +to do a guess about the BIOS to run, but sometimes it may be useful
> +to force a different one, like OVMF UEFI.

I don't think we need to mention the implementation detail that
HVMLOADER is involved. I think it will be sufficient to simply say that
this selects the virtual firmware which is exposed to the guest.

> +
>  =item B<pae=BOOLEAN>
>  
>  Hide or expose the IA32 Physical Address Extensions. These extensions
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>      case LIBXL_DOMAIN_TYPE_HVM:
>          b_info->video_memkb = 8 * 1024;
>          b_info->u.hvm.firmware = NULL;
> +        b_info->u.hvm.bios = 0;
>          b_info->u.hvm.pae = 1;
>          b_info->u.hvm.apic = 1;
>          b_info->u.hvm.acpi = 1;
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>  static const char *libxl__domain_bios(libxl__gc *gc,
>                                  const libxl_domain_build_info *info)
>  {
> +    if (info->u.hvm.bios)
> +       return libxl_bios_types_to_string(info->u.hvm.bios);
>      switch (info->device_model_version) {
>      case 1: return "rombios";
>      case 2: return "seabios";
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Fri Feb 24 18:19:56 2012 +0000
> @@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
>      (3, "one_missed_tick_pending"),
>      ])
>  
> +libxl_bios_types = Enumeration("bios_types", [

Whether by coincidence or design we seem to have been using the singular
form for our enum names, so this would be "libxl_bios_type"

Ian.

> +    (1, "rombios"),
> +    (2, "seabios"),
> +    (3, "ovmf"),
> +    ])
> +
>  #
>  # Complex libxl types
>  #
> @@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
>  
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware", string),
> +                                       ("bios", libxl_bios_types),
>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -704,6 +704,12 @@ static void parse_config_data(const char
>  
>          xlu_cfg_replace_string (config, "firmware_override",
>                                  &b_info->u.hvm.firmware, 0);
> +        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
> +            libxl_bios_types_from_string(buf, &b_info->u.hvm.bios)) {
> +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
> +                    buf);
> +                exit (1);
> +        }
>          if (!xlu_cfg_get_long (config, "pae", &l, 0))
>              b_info->u.hvm.pae = l;
>          if (!xlu_cfg_get_long (config, "apic", &l, 0))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12: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 1S2MMU-0002DI-7p; Tue, 28 Feb 2012 12:40:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MMS-0002Ck-JY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:40:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330432850!9188738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4072 invoked from network); 28 Feb 2012 12:40:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:40:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:40:49 +0000
Message-ID: <1330432847.31269.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Tue, 28 Feb 2012 12:40:47 +0000
In-Reply-To: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
References: <20ea6f881776a8912dbe.1330107857@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v2] Add the bios 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


> [Patch v2] Add the bios option to specify the bios to load.
> 
> Please note 2 things:
> - I've used the name of 'OVMF' rather than adding the arch postfix 
> because we are going to make this code arch-size agnostic (in another
> patch)
> - Other seems missing in xl.cfg.pod5, like firmware_override

:-( If you notice such please add them, with an XXX is fine. In this
case I thought I saw a patch from Olaf adding a bunch of missing
options.

> 
> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

> On Fri, 2012-02-24 at 18:24 +0000, Attilio Rao wrote:
> diff -r adcd6ab160fa -r 20ea6f881776 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
> +++ b/docs/man/xl.cfg.pod.5	Fri Feb 24 18:19:56 2012 +0000
> @@ -430,6 +430,12 @@ accept the defaults for these options wh
>  
>  =over 4
>  
> +=item B<bios="STRING">

Can we enumerate the valid values of "STRING" here and their
requirements (even if we aren't enforcing them) WRT which
device_model_version they can be used with.

> +Load the specified BIOS in HVMLOADER. By default, HVMLOADER will try
> +to do a guess about the BIOS to run, but sometimes it may be useful
> +to force a different one, like OVMF UEFI.

I don't think we need to mention the implementation detail that
HVMLOADER is involved. I think it will be sufficient to simply say that
this selects the virtual firmware which is exposed to the guest.

> +
>  =item B<pae=BOOLEAN>
>  
>  Hide or expose the IA32 Physical Address Extensions. These extensions
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>      case LIBXL_DOMAIN_TYPE_HVM:
>          b_info->video_memkb = 8 * 1024;
>          b_info->u.hvm.firmware = NULL;
> +        b_info->u.hvm.bios = 0;
>          b_info->u.hvm.pae = 1;
>          b_info->u.hvm.apic = 1;
>          b_info->u.hvm.acpi = 1;
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
>  static const char *libxl__domain_bios(libxl__gc *gc,
>                                  const libxl_domain_build_info *info)
>  {
> +    if (info->u.hvm.bios)
> +       return libxl_bios_types_to_string(info->u.hvm.bios);
>      switch (info->device_model_version) {
>      case 1: return "rombios";
>      case 2: return "seabios";
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Fri Feb 24 18:19:56 2012 +0000
> @@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
>      (3, "one_missed_tick_pending"),
>      ])
>  
> +libxl_bios_types = Enumeration("bios_types", [

Whether by coincidence or design we seem to have been using the singular
form for our enum names, so this would be "libxl_bios_type"

Ian.

> +    (1, "rombios"),
> +    (2, "seabios"),
> +    (3, "ovmf"),
> +    ])
> +
>  #
>  # Complex libxl types
>  #
> @@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
>  
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware", string),
> +                                       ("bios", libxl_bios_types),
>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> diff -r adcd6ab160fa -r 20ea6f881776 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Feb 24 18:19:56 2012 +0000
> @@ -704,6 +704,12 @@ static void parse_config_data(const char
>  
>          xlu_cfg_replace_string (config, "firmware_override",
>                                  &b_info->u.hvm.firmware, 0);
> +        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
> +            libxl_bios_types_from_string(buf, &b_info->u.hvm.bios)) {
> +                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
> +                    buf);
> +                exit (1);
> +        }
>          if (!xlu_cfg_get_long (config, "pae", &l, 0))
>              b_info->u.hvm.pae = l;
>          if (!xlu_cfg_get_long (config, "apic", &l, 0))



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:42:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MNM-0002Hr-VN; Tue, 28 Feb 2012 12:41: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 1S2MNL-0002Ha-L5
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:41:51 +0000
Received: from [85.158.139.83:32728] by server-4.bemta-5.messagelabs.com id
	2B/49-10788-E8BCC4F4; Tue, 28 Feb 2012 12:41:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330432908!17057317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31702 invoked from network); 28 Feb 2012 12:41:49 -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;
	28 Feb 2012 12:41:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:41:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:41:47 +0000
Message-ID: <1330432906.31269.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Tue, 28 Feb 2012 12:41:46 +0000
In-Reply-To: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
References: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Signed-off-by: Attilio Rao
	<attilio.rao@citrix.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


> - Per discussion on the mailing list, drop the ovmf32 support and
> rename 
> ovmf64 as the more generic name ovmf which becames the official 
> supported one. Now the ROM has to be copied like that:
> 
> Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->  tools/firmware/ovmf/ovmf.bin
> 
> - Remove the 15cpus hack from ovmf because it should be unnecessary
> on 
> nowadays windows/EFI supported.
> 
> Signed-off-by: Attilio Rao <attilio.rao@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 Feb 28 12:42:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MNM-0002Hr-VN; Tue, 28 Feb 2012 12:41: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 1S2MNL-0002Ha-L5
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:41:51 +0000
Received: from [85.158.139.83:32728] by server-4.bemta-5.messagelabs.com id
	2B/49-10788-E8BCC4F4; Tue, 28 Feb 2012 12:41:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330432908!17057317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31702 invoked from network); 28 Feb 2012 12:41:49 -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;
	28 Feb 2012 12:41:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:41:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:41:47 +0000
Message-ID: <1330432906.31269.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Tue, 28 Feb 2012 12:41:46 +0000
In-Reply-To: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
References: <eb51dd646ce097b54a58.1330108555@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Signed-off-by: Attilio Rao
	<attilio.rao@citrix.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


> - Per discussion on the mailing list, drop the ovmf32 support and
> rename 
> ovmf64 as the more generic name ovmf which becames the official 
> supported one. Now the ROM has to be copied like that:
> 
> Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->  tools/firmware/ovmf/ovmf.bin
> 
> - Remove the 15cpus hack from ovmf because it should be unnecessary
> on 
> nowadays windows/EFI supported.
> 
> Signed-off-by: Attilio Rao <attilio.rao@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 Feb 28 12:44:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MPI-0002Tq-G0; Tue, 28 Feb 2012 12:43:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MPH-0002TO-7v
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:43:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330433024!11446056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11055 invoked from network); 28 Feb 2012 12:43:44 -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;
	28 Feb 2012 12:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:43:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:43:43 +0000
Message-ID: <1330433022.31269.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 12:43:42 +0000
In-Reply-To: <20300.51954.552010.422304@mariner.uk.xensource.com>
References: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
	<1330346266.8557.282.camel@zakaz.uk.xensource.com>
	<20300.51954.552010.422304@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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 Tue, 2012-02-28 at 12:39 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel hypercalls to improve generated docs"):
> > Actually, the intro from that chapter is interesting/useful and I missed
> > it. Here's a new version with it included.
> ...
> > hcall: markup the event channel hypercalls to improve generated docs
> 
> Good stuff.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

> 
> Also, as requested:
> 
> commit 78ed3b5816ed60e7e86810c2d93069fae63dc406
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Tue Feb 28 12:36:15 2012 +0000
> 
>     docs: xen-headers: Annotate typedefs
>     
>     Parse (some) typedef statements.  (Make type names links to the
>     underlying struct if there is one, rather than to just the typedef.)
>     
>     Also, exclude the new arch-arm headers.
>     
>     Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Thanks, I didn't review closely or try it yet but this jumped out at me
(twice):

> + if ($name eq 'buf_ioreq_t') {
> +     print STDERR "REFHREF $type $name | $ttype $tname | @deref\n";
> + }

And this has a odd looking indentation:

> @@ -259,6 +290,14 @@ sub process_file ($$) {
>  		    in_enum($1,(ucfirst $2),$3);
>  	        }
>  	    }
> +	} elsif (s/^(typedef \s+ )((struct|union|enum) \  (\w+))
> +                      (\s+) (\w+)(\;)$
> +                  / norm($1).norm($2).$5.
> +                    defn($6,'Typedef',$6,undef,[(ucfirst $3),$4]).
> +                    $7 /xe) {
> +        } elsif (s/^(typedef \s+) (\w+) (\s+) (\w+) (\;)$

Extra leading space or a sneaky hard tab?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:44:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MPI-0002Tq-G0; Tue, 28 Feb 2012 12:43:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MPH-0002TO-7v
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:43:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330433024!11446056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11055 invoked from network); 28 Feb 2012 12:43:44 -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;
	28 Feb 2012 12:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:43:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:43:43 +0000
Message-ID: <1330433022.31269.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 12:43:42 +0000
In-Reply-To: <20300.51954.552010.422304@mariner.uk.xensource.com>
References: <31eb9ee09b726bfab1df.1330344431@cosworth.uk.xensource.com>
	<1330346266.8557.282.camel@zakaz.uk.xensource.com>
	<20300.51954.552010.422304@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel
 hypercalls to improve generated 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 Tue, 2012-02-28 at 12:39 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH DOCDAY] hcall: markup the event channel hypercalls to improve generated docs"):
> > Actually, the intro from that chapter is interesting/useful and I missed
> > it. Here's a new version with it included.
> ...
> > hcall: markup the event channel hypercalls to improve generated docs
> 
> Good stuff.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

> 
> Also, as requested:
> 
> commit 78ed3b5816ed60e7e86810c2d93069fae63dc406
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Tue Feb 28 12:36:15 2012 +0000
> 
>     docs: xen-headers: Annotate typedefs
>     
>     Parse (some) typedef statements.  (Make type names links to the
>     underlying struct if there is one, rather than to just the typedef.)
>     
>     Also, exclude the new arch-arm headers.
>     
>     Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Thanks, I didn't review closely or try it yet but this jumped out at me
(twice):

> + if ($name eq 'buf_ioreq_t') {
> +     print STDERR "REFHREF $type $name | $ttype $tname | @deref\n";
> + }

And this has a odd looking indentation:

> @@ -259,6 +290,14 @@ sub process_file ($$) {
>  		    in_enum($1,(ucfirst $2),$3);
>  	        }
>  	    }
> +	} elsif (s/^(typedef \s+ )((struct|union|enum) \  (\w+))
> +                      (\s+) (\w+)(\;)$
> +                  / norm($1).norm($2).$5.
> +                    defn($6,'Typedef',$6,undef,[(ucfirst $3),$4]).
> +                    $7 /xe) {
> +        } elsif (s/^(typedef \s+) (\w+) (\s+) (\w+) (\;)$

Extra leading space or a sneaky hard tab?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:50:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:50:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MVw-0002qg-Iq; Tue, 28 Feb 2012 12:50:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MVv-0002qb-6K
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:50:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330433436!15283773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18119 invoked from network); 28 Feb 2012 12:50:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:50:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:50:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:50:36 +0000
Message-ID: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 12:50:34 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RGF5IGxhdGUgZHVlIHRvIGRvYyBkYXkgeWVzdGVyZGF5LiBGWUkgSSdsbCBiZSBhdCB0aGUgaGFj
a2F0aG9uIG5leHQKd2VlayBzbyBJIGV4cGVjdCBJJ2xsIGJlIHNraXBwaW5nIHRoYXQgdXBkYXRl
LgoKQXMgdXN1YWwgcGxlYXNlIHBpbmcgbWUgd2l0aCBhbnkgdXBkYXRlcy9jb3JyZWN0aW9ucy4K
Cmh5cGVydmlzb3IsIGJsb2NrZXJzOgogICAgICAqIGRvbWN0bHMgLyBzeXNjdGxzIHNldCB1cCB0
byBtb2RpZnkgc2NoZWR1bGVyIHBhcmFtZXRlcnMsIGxpa2UKICAgICAgICB0aGUgY3JlZGl0MSB0
aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwLCBwYXRjaGVzCiAgICAg
ICAgcG9zdGVkKQogCnRvb2xzLCBibG9ja2VyczoKCiAgICAgICogbGlieGwgc3RhYmxlIEFQSSAt
LSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAgICAgd2hpY2gg
ZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBv
ZgogICAgICAgIHRoaXMgYXJlOgogICAgICAgICAgICAgICogYWRkIGxpYnhsX2RlZmJvb2wgYW5k
IGdlbmVyYWxseSB0cnkgYW5kIGFycmFuZ2UgdGhhdAogICAgICAgICAgICAgICAgbWVtc2V0KGZv
bywwLC4uLikgcmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCiAgICAgICAgICAg
ICAgICBwYXRjaGVzIHJlcG9zdGVkKQogICAgICAgICAgICAgICogU2FmZSBmb3JrIHZzLiBmZCBo
YW5kbGluZyBob29rcy4gVGhpcyBpcyBhbiBBUEkKICAgICAgICAgICAgICAgIGFkZGl0aW9uLCBz
byBtYXliZSBub3QgcmVxdWlyZWQgZnJvIHN0YWJsZSBBUEksIGJpdCBuZWVkCiAgICAgICAgICAg
ICAgICB0byBoYXZlIGZvciA0LjI/IChJYW4gSiwgcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICAgICAg
ICAgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9y
dAogICAgICAgICAgICAgICAgKEdlb3JnZSBEdW5sYXApCiAgICAgICAgICAgICAgKiBNb3JlIGZv
cm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeQogICAgICAg
ICAgICAgICAgaW4gdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24g
YXJvdW5kCiAgICAgICAgICAgICAgICAtcmMxIHRvIHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4K
ICAgICAgKiBDb3JyZWN0IHBhZ2luZy9zaGFyaW5nIHRvb2xzIGJ1ZmZlciBtbG9ja2luZyAoVGlt
LCBBbmRyZXMsCiAgICAgICAgcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICogQXV0b2NvbmYgKFJvZ2Vy
IFBhdSBNb25uw6kgJiBJYW4gSiwgRE9ORSkKICAgICAgKiB4bCBzdXBwb3J0IGZvciAicnRjX3Rp
bWVvZmZzZXQiIGFuZCAibG9jYWx0aW1lIiAoTm9ib2R5IEFGQUlDVCkKCmh5cGVydmlzb3IsIG5p
Y2UgdG8gaGF2ZToKICAgICAgKiAKICAgICAgKiBzb2xpZCBpbXBsZW1lbnRhdGlvbiBvZiBzaGFy
aW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCiAgICAgICAgcXVldWVzKSAoVGltIERl
ZWdhbiwgT2xhZiBIZXJyaW5nIGV0IGFsKQogICAgICAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBp
cyBhIGZ1bGx5IHN5bmNocm9uaXplZCBwMm0gKGxvY2tpbmcKICAgICAgICBsb29rdXBzKSAoQW5k
cmVzIExhZ2FyLUNhdmlsbGEsIERPTkUpCgp0b29scywgbmljZSB0byBoYXZlOgoKICAgICAgKiBI
b3RwbHVnIHNjcmlwdCBzdHVmZiAtLSBpbnRlcm5hbCB0byBsaWJ4bCAoSSB0aGluaywgdGhlcmVm
b3JlIEkKICAgICAgICBkaWRuJ3QgcHV0IHRoaXMgdW5kZXIgc3RhYmxlIEFQSSBhYm92ZSkgYnV0
IHN0aWxsIGdvb2QgdG8gaGF2ZQogICAgICAgIGZvciA0LjI/IChSb2dlciBQYXUgTW9ubsOpLCBw
YXRjaGVzIHBvc3RlZCkKICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9u
IGZyb20gaG90cGx1ZyBzY3JpcHQgKFJvZ2VyCiAgICAgICAgUGF1IE1vbm7DqSkKICAgICAgKiBD
b25maWd1cmUvY29udHJvbCBwYWdpbmcgdmlhIHhsL2xpYnhsIChPbGFmIEhlcnJpbmcpCiAgICAg
ICogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6CiAgICAgICAgICAgICAgKiBVcHN0cmVh
bSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBlcmFyZCwKICAgICAgICAg
ICAgICAgIHBhdGNoZXMgc2VudCkKICAgICAgICAgICAgICAqIFVwc3RyZWFtIHFlbXUgc2F2ZSBy
ZXN0b3JlIChBbnRob255IFBlcmFyZCwgU3RlZmFubwogICAgICAgICAgICAgICAgU3RhYmVsbGlu
aSwgcGF0Y2hlcyBzZW50LCB3YWl0aW5nIGZvciB1cHN0cmVhbSBhY2spCiAgICAgICogTmVzdGVk
LXZpcnR1YWxpc2F0aW9uIChjdXJyZW50bHkgc2hvdWxkIGJlIG1hcmtlZCBleHBlcmltZW50YWws
CiAgICAgICAgbGlrZWx5IHRvIHJlbGVhc2UgdGhhdCB3YXk/IENvbnNpZGVyIG5lc3RlZC1zdm0g
c2VwYXJhdGUgdG8KICAgICAgICBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBz
aGFwZSkKICAgICAgKiBJbml0aWFsIHhsIHN1cHBvcnQgZm9yIFJlbXVzIChtZW1vcnkgY2hlY2tw
b2ludCwgYmxhY2tob2xpbmcpCiAgICAgICAgKFNocmlyYW0sIHBhdGNoZXMgcG9zdGVkLCBibG9j
a2VkIGJlaGluZCBxZW11IHNhdmUgcmVzdG9yZQogICAgICAgIHBhdGNoZXMpCiAgICAgICogeGwg
c3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3Igb3RoZXJ3
aXNlKQogICAgICAgIChOb2JvZHkgQUZBSUNUKQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:50:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12:50:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2MVw-0002qg-Iq; Tue, 28 Feb 2012 12:50:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MVv-0002qb-6K
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:50:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330433436!15283773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18119 invoked from network); 28 Feb 2012 12:50:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 12:50:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:50:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:50:36 +0000
Message-ID: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 12:50:34 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

RGF5IGxhdGUgZHVlIHRvIGRvYyBkYXkgeWVzdGVyZGF5LiBGWUkgSSdsbCBiZSBhdCB0aGUgaGFj
a2F0aG9uIG5leHQKd2VlayBzbyBJIGV4cGVjdCBJJ2xsIGJlIHNraXBwaW5nIHRoYXQgdXBkYXRl
LgoKQXMgdXN1YWwgcGxlYXNlIHBpbmcgbWUgd2l0aCBhbnkgdXBkYXRlcy9jb3JyZWN0aW9ucy4K
Cmh5cGVydmlzb3IsIGJsb2NrZXJzOgogICAgICAqIGRvbWN0bHMgLyBzeXNjdGxzIHNldCB1cCB0
byBtb2RpZnkgc2NoZWR1bGVyIHBhcmFtZXRlcnMsIGxpa2UKICAgICAgICB0aGUgY3JlZGl0MSB0
aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwLCBwYXRjaGVzCiAgICAg
ICAgcG9zdGVkKQogCnRvb2xzLCBibG9ja2VyczoKCiAgICAgICogbGlieGwgc3RhYmxlIEFQSSAt
LSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAgICAgd2hpY2gg
ZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBv
ZgogICAgICAgIHRoaXMgYXJlOgogICAgICAgICAgICAgICogYWRkIGxpYnhsX2RlZmJvb2wgYW5k
IGdlbmVyYWxseSB0cnkgYW5kIGFycmFuZ2UgdGhhdAogICAgICAgICAgICAgICAgbWVtc2V0KGZv
bywwLC4uLikgcmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCiAgICAgICAgICAg
ICAgICBwYXRjaGVzIHJlcG9zdGVkKQogICAgICAgICAgICAgICogU2FmZSBmb3JrIHZzLiBmZCBo
YW5kbGluZyBob29rcy4gVGhpcyBpcyBhbiBBUEkKICAgICAgICAgICAgICAgIGFkZGl0aW9uLCBz
byBtYXliZSBub3QgcmVxdWlyZWQgZnJvIHN0YWJsZSBBUEksIGJpdCBuZWVkCiAgICAgICAgICAg
ICAgICB0byBoYXZlIGZvciA0LjI/IChJYW4gSiwgcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICAgICAg
ICAgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9y
dAogICAgICAgICAgICAgICAgKEdlb3JnZSBEdW5sYXApCiAgICAgICAgICAgICAgKiBNb3JlIGZv
cm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeQogICAgICAg
ICAgICAgICAgaW4gdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24g
YXJvdW5kCiAgICAgICAgICAgICAgICAtcmMxIHRvIHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4K
ICAgICAgKiBDb3JyZWN0IHBhZ2luZy9zaGFyaW5nIHRvb2xzIGJ1ZmZlciBtbG9ja2luZyAoVGlt
LCBBbmRyZXMsCiAgICAgICAgcGF0Y2hlcyBwb3N0ZWQpCiAgICAgICogQXV0b2NvbmYgKFJvZ2Vy
IFBhdSBNb25uw6kgJiBJYW4gSiwgRE9ORSkKICAgICAgKiB4bCBzdXBwb3J0IGZvciAicnRjX3Rp
bWVvZmZzZXQiIGFuZCAibG9jYWx0aW1lIiAoTm9ib2R5IEFGQUlDVCkKCmh5cGVydmlzb3IsIG5p
Y2UgdG8gaGF2ZToKICAgICAgKiAKICAgICAgKiBzb2xpZCBpbXBsZW1lbnRhdGlvbiBvZiBzaGFy
aW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCiAgICAgICAgcXVldWVzKSAoVGltIERl
ZWdhbiwgT2xhZiBIZXJyaW5nIGV0IGFsKQogICAgICAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBp
cyBhIGZ1bGx5IHN5bmNocm9uaXplZCBwMm0gKGxvY2tpbmcKICAgICAgICBsb29rdXBzKSAoQW5k
cmVzIExhZ2FyLUNhdmlsbGEsIERPTkUpCgp0b29scywgbmljZSB0byBoYXZlOgoKICAgICAgKiBI
b3RwbHVnIHNjcmlwdCBzdHVmZiAtLSBpbnRlcm5hbCB0byBsaWJ4bCAoSSB0aGluaywgdGhlcmVm
b3JlIEkKICAgICAgICBkaWRuJ3QgcHV0IHRoaXMgdW5kZXIgc3RhYmxlIEFQSSBhYm92ZSkgYnV0
IHN0aWxsIGdvb2QgdG8gaGF2ZQogICAgICAgIGZvciA0LjI/IChSb2dlciBQYXUgTW9ubsOpLCBw
YXRjaGVzIHBvc3RlZCkKICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9u
IGZyb20gaG90cGx1ZyBzY3JpcHQgKFJvZ2VyCiAgICAgICAgUGF1IE1vbm7DqSkKICAgICAgKiBD
b25maWd1cmUvY29udHJvbCBwYWdpbmcgdmlhIHhsL2xpYnhsIChPbGFmIEhlcnJpbmcpCiAgICAg
ICogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6CiAgICAgICAgICAgICAgKiBVcHN0cmVh
bSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBlcmFyZCwKICAgICAgICAg
ICAgICAgIHBhdGNoZXMgc2VudCkKICAgICAgICAgICAgICAqIFVwc3RyZWFtIHFlbXUgc2F2ZSBy
ZXN0b3JlIChBbnRob255IFBlcmFyZCwgU3RlZmFubwogICAgICAgICAgICAgICAgU3RhYmVsbGlu
aSwgcGF0Y2hlcyBzZW50LCB3YWl0aW5nIGZvciB1cHN0cmVhbSBhY2spCiAgICAgICogTmVzdGVk
LXZpcnR1YWxpc2F0aW9uIChjdXJyZW50bHkgc2hvdWxkIGJlIG1hcmtlZCBleHBlcmltZW50YWws
CiAgICAgICAgbGlrZWx5IHRvIHJlbGVhc2UgdGhhdCB3YXk/IENvbnNpZGVyIG5lc3RlZC1zdm0g
c2VwYXJhdGUgdG8KICAgICAgICBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBz
aGFwZSkKICAgICAgKiBJbml0aWFsIHhsIHN1cHBvcnQgZm9yIFJlbXVzIChtZW1vcnkgY2hlY2tw
b2ludCwgYmxhY2tob2xpbmcpCiAgICAgICAgKFNocmlyYW0sIHBhdGNoZXMgcG9zdGVkLCBibG9j
a2VkIGJlaGluZCBxZW11IHNhdmUgcmVzdG9yZQogICAgICAgIHBhdGNoZXMpCiAgICAgICogeGwg
c3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3Igb3RoZXJ3
aXNlKQogICAgICAgIChOb2JvZHkgQUZBSUNUKQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:56:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12: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 1S2Mbg-0002zX-BZ; Tue, 28 Feb 2012 12:56: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 1S2Mbe-0002zO-G2
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:56:39 +0000
Received: from [85.158.139.83:49028] by server-4.bemta-5.messagelabs.com id
	AB/05-10788-50FCC4F4; Tue, 28 Feb 2012 12:56:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330433796!17055772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15536 invoked from network); 28 Feb 2012 12:56:37 -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;
	28 Feb 2012 12:56:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:56:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:56:35 +0000
Message-ID: <1330433794.31269.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Tue, 28 Feb 2012 12:56:34 +0000
In-Reply-To: <3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize
 mem_event/access/paging interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_mem_access.c         |  10 ++++++++--
>  tools/libxc/xc_mem_event.c          |  13 ++++++++-----
>  tools/libxc/xc_mem_paging.c         |  10 ++++++++--
>  tools/libxc/xenctrl.h               |   6 +++---
>  tools/tests/xen-access/xen-access.c |  22 ++++------------------
>  tools/xenpaging/xenpaging.c         |  18 +++---------------
>  tools/xenpaging/xenpaging.h         |   2 +-
>  xen/arch/x86/mm/mem_event.c         |  33 +++------------------------------
>  xen/include/public/domctl.h         |   4 ++--
>  xen/include/public/mem_event.h      |   4 ----
>  xen/include/xen/sched.h             |   2 --
>  11 files changed, 40 insertions(+), 84 deletions(-)
> 
> 
> Don't use the superfluous shared page, return the event channel directly as
> part of the domctl struct, instead.
> 
> In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
> so please voice any concerns.
> 
> Known pending issues:
> - pager could die and its ring page could be used by some other process, yet
>   Xen retains the mapping to it.
> - use a saner interface for the paging_load buffer.
> 
> This change also affects the x86/mm bits in the hypervisor that process the
> mem_event setup domctl.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_access.c
> --- a/tools/libxc/xc_mem_access.c
> +++ b/tools/libxc/xc_mem_access.c
> @@ -25,12 +25,18 @@
> 
> 
>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
> -                        void *shared_page, void *ring_page)
> +                         uint32_t *port, void *ring_page)
>  {
> +    if ( !port )
> +    {
> +        errno = -EINVAL;

Aren't errno vals normally +ve?

Is there any situation where port==NULL would be valid, i.e. any chance
that this might happen, or are such callers just buggy?

> +        return -1;
> +    }

> +
>      return xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
> -                                shared_page, ring_page);
> +                                port, ring_page);
>  }
> 
>  int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_event.c
> --- a/tools/libxc/xc_mem_event.c
> +++ b/tools/libxc/xc_mem_event.c
> @@ -24,19 +24,22 @@
>  #include "xc_private.h"
> 
>  int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
> -                         unsigned int mode, void *page, void *ring_page)
> +                         unsigned int mode, uint32_t *port, void *ring_page)
>  {
>      DECLARE_DOMCTL;
> +    int rc;
> 
>      domctl.cmd = XEN_DOMCTL_mem_event_op;
>      domctl.domain = domain_id;
>      domctl.u.mem_event_op.op = op;
>      domctl.u.mem_event_op.mode = mode;
> -
> -    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
> -    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
> +    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
> 
> -    return do_domctl(xch, &domctl);
> +    errno = 0;
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc && port )
> +        *port = domctl.u.mem_event_op.port;
> +    return rc;

Clearing errno is an unusual pattern, normally callers only expect errno
to contain a valid value on failure. Are you trying to provide some
backwards compatibility with something or is there another reason for
doing it this way?

>  }
> 
>  int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -25,12 +25,18 @@
> 
> 
>  int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
> -                        void *shared_page, void *ring_page)
> +                         uint32_t *port, void *ring_page)
>  {
> +    if ( !port )
> +    {
> +        errno = -EINVAL;

Same comments as before.

> +        return -1;
> +    }
> +
>      return xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
> -                                shared_page, ring_page);
> +                                port, ring_page);
>  }
> 

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 12:56:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 12: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 1S2Mbg-0002zX-BZ; Tue, 28 Feb 2012 12:56: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 1S2Mbe-0002zO-G2
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 12:56:39 +0000
Received: from [85.158.139.83:49028] by server-4.bemta-5.messagelabs.com id
	AB/05-10788-50FCC4F4; Tue, 28 Feb 2012 12:56:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330433796!17055772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15536 invoked from network); 28 Feb 2012 12:56:37 -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;
	28 Feb 2012 12:56:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10981896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 12:56:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 12:56:35 +0000
Message-ID: <1330433794.31269.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Tue, 28 Feb 2012 12:56:34 +0000
In-Reply-To: <3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize
 mem_event/access/paging interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_mem_access.c         |  10 ++++++++--
>  tools/libxc/xc_mem_event.c          |  13 ++++++++-----
>  tools/libxc/xc_mem_paging.c         |  10 ++++++++--
>  tools/libxc/xenctrl.h               |   6 +++---
>  tools/tests/xen-access/xen-access.c |  22 ++++------------------
>  tools/xenpaging/xenpaging.c         |  18 +++---------------
>  tools/xenpaging/xenpaging.h         |   2 +-
>  xen/arch/x86/mm/mem_event.c         |  33 +++------------------------------
>  xen/include/public/domctl.h         |   4 ++--
>  xen/include/public/mem_event.h      |   4 ----
>  xen/include/xen/sched.h             |   2 --
>  11 files changed, 40 insertions(+), 84 deletions(-)
> 
> 
> Don't use the superfluous shared page, return the event channel directly as
> part of the domctl struct, instead.
> 
> In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API change,
> so please voice any concerns.
> 
> Known pending issues:
> - pager could die and its ring page could be used by some other process, yet
>   Xen retains the mapping to it.
> - use a saner interface for the paging_load buffer.
> 
> This change also affects the x86/mm bits in the hypervisor that process the
> mem_event setup domctl.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_access.c
> --- a/tools/libxc/xc_mem_access.c
> +++ b/tools/libxc/xc_mem_access.c
> @@ -25,12 +25,18 @@
> 
> 
>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
> -                        void *shared_page, void *ring_page)
> +                         uint32_t *port, void *ring_page)
>  {
> +    if ( !port )
> +    {
> +        errno = -EINVAL;

Aren't errno vals normally +ve?

Is there any situation where port==NULL would be valid, i.e. any chance
that this might happen, or are such callers just buggy?

> +        return -1;
> +    }

> +
>      return xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
> -                                shared_page, ring_page);
> +                                port, ring_page);
>  }
> 
>  int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_event.c
> --- a/tools/libxc/xc_mem_event.c
> +++ b/tools/libxc/xc_mem_event.c
> @@ -24,19 +24,22 @@
>  #include "xc_private.h"
> 
>  int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
> -                         unsigned int mode, void *page, void *ring_page)
> +                         unsigned int mode, uint32_t *port, void *ring_page)
>  {
>      DECLARE_DOMCTL;
> +    int rc;
> 
>      domctl.cmd = XEN_DOMCTL_mem_event_op;
>      domctl.domain = domain_id;
>      domctl.u.mem_event_op.op = op;
>      domctl.u.mem_event_op.mode = mode;
> -
> -    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
> -    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
> +    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
> 
> -    return do_domctl(xch, &domctl);
> +    errno = 0;
> +    rc = do_domctl(xch, &domctl);
> +    if ( !rc && port )
> +        *port = domctl.u.mem_event_op.port;
> +    return rc;

Clearing errno is an unusual pattern, normally callers only expect errno
to contain a valid value on failure. Are you trying to provide some
backwards compatibility with something or is there another reason for
doing it this way?

>  }
> 
>  int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -25,12 +25,18 @@
> 
> 
>  int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
> -                        void *shared_page, void *ring_page)
> +                         uint32_t *port, void *ring_page)
>  {
> +    if ( !port )
> +    {
> +        errno = -EINVAL;

Same comments as before.

> +        return -1;
> +    }
> +
>      return xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
> -                                shared_page, ring_page);
> +                                port, ring_page);
>  }
> 

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 13:02:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13: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 1S2MhS-0003Ah-6x; Tue, 28 Feb 2012 13:02:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MhR-0003AZ-0H
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:02:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330434150!15283953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31963 invoked from network); 28 Feb 2012 13:02:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:02:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10982033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:02:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 13:02:29 +0000
Message-ID: <1330434147.31269.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Tue, 28 Feb 2012 13:02:27 +0000
In-Reply-To: <9c6cbbe72dc44e27a732.1329977110@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<9c6cbbe72dc44e27a732.1329977110@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 5 of 7] Tools: libxc side for setting up the
 mem sharing 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 Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  25 +++++++++++++++++++++++++
>  tools/libxc/xenctrl.h   |   5 +++++
>  2 files changed, 30 insertions(+), 0 deletions(-)
> 
> 
> This ring is used to report failed allocations in the unshare path.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 85157ed138a9 -r 9c6cbbe72dc4 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -42,6 +42,31 @@ int xc_memshr_control(xc_interface *xch,
>      return do_domctl(xch, &domctl);
>  }
>  
> +int xc_memshr_ring_enable(xc_interface *xch, 
> +                          domid_t domid, 
> +                          uint32_t *port)
> +{
> +    if ( !port )
> +    {
> +        errno = -EINVAL;

+ve. 

> +        return -1;
> +    }
> +        
> +    return xc_mem_event_control(xch, domid,
> +                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE,
> +                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
> +                                port);
> +}

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 13:02:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13: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 1S2MhS-0003Ah-6x; Tue, 28 Feb 2012 13:02:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2MhR-0003AZ-0H
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:02:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330434150!15283953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31963 invoked from network); 28 Feb 2012 13:02:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:02:30 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10982033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:02:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 13:02:29 +0000
Message-ID: <1330434147.31269.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Tue, 28 Feb 2012 13:02:27 +0000
In-Reply-To: <9c6cbbe72dc44e27a732.1329977110@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<9c6cbbe72dc44e27a732.1329977110@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 5 of 7] Tools: libxc side for setting up the
 mem sharing 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 Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
> tools/libxc/xc_memshr.c |  25 +++++++++++++++++++++++++
>  tools/libxc/xenctrl.h   |   5 +++++
>  2 files changed, 30 insertions(+), 0 deletions(-)
> 
> 
> This ring is used to report failed allocations in the unshare path.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r 85157ed138a9 -r 9c6cbbe72dc4 tools/libxc/xc_memshr.c
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -42,6 +42,31 @@ int xc_memshr_control(xc_interface *xch,
>      return do_domctl(xch, &domctl);
>  }
>  
> +int xc_memshr_ring_enable(xc_interface *xch, 
> +                          domid_t domid, 
> +                          uint32_t *port)
> +{
> +    if ( !port )
> +    {
> +        errno = -EINVAL;

+ve. 

> +        return -1;
> +    }
> +        
> +    return xc_mem_event_control(xch, domid,
> +                                XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE,
> +                                XEN_DOMCTL_MEM_EVENT_OP_SHARING,
> +                                port);
> +}

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 13:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13: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 1S2Mhe-0003Ba-J5; Tue, 28 Feb 2012 13:02:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2Mhd-0003B9-FF
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:02:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330434162!10620812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19001 invoked from network); 28 Feb 2012 13:02:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:02:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10982012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:01:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 13:01:35 +0000
Message-ID: <1330434093.31269.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Tue, 28 Feb 2012 13:01:33 +0000
In-Reply-To: <0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest
 address space to store mem event rings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:

Doers this mean that a guest can now potentially observe, or even modify
it's own mem event ring? Are we sure there's no potential for havoc
here?

Is there no scope for making these pages owned by the domain but not
actually part of the P2M? We can cope with that for other types of magic
page, can't we?

I didn't atually dig into the implementation other than to see if it
answered  my questions, although I did notice:

> diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
> --- a/tools/libxc/xc_hvm_build.c
> +++ b/tools/libxc/xc_hvm_build.c
> @@ -38,12 +38,15 @@
>  #define SUPERPAGE_1GB_SHIFT   18
>  #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> 
> -#define SPECIALPAGE_BUFIOREQ 0
> -#define SPECIALPAGE_XENSTORE 1
> -#define SPECIALPAGE_IOREQ    2
> -#define SPECIALPAGE_IDENT_PT 3
> -#define SPECIALPAGE_CONSOLE  4
> -#define NR_SPECIAL_PAGES     5
> +#define SPECIALPAGE_PAGING   0
> +#define SPECIALPAGE_ACCESS   1
> +#define SPECIALPAGE_SHARING  2
> +#define SPECIALPAGE_BUFIOREQ 3
> +#define SPECIALPAGE_XENSTORE 4
> +#define SPECIALPAGE_IOREQ    5
> +#define SPECIALPAGE_IDENT_PT 6
> +#define SPECIALPAGE_CONSOLE  7
> +#define NR_SPECIAL_PAGES     8

Any reason to not simply append 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 Feb 28 13:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13: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 1S2Mhe-0003Ba-J5; Tue, 28 Feb 2012 13:02:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2Mhd-0003B9-FF
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:02:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330434162!10620812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19001 invoked from network); 28 Feb 2012 13:02:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:02:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10982012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:01:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 13:01:35 +0000
Message-ID: <1330434093.31269.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Tue, 28 Feb 2012 13:01:33 +0000
In-Reply-To: <0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest
 address space to store mem event rings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:

Doers this mean that a guest can now potentially observe, or even modify
it's own mem event ring? Are we sure there's no potential for havoc
here?

Is there no scope for making these pages owned by the domain but not
actually part of the P2M? We can cope with that for other types of magic
page, can't we?

I didn't atually dig into the implementation other than to see if it
answered  my questions, although I did notice:

> diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
> --- a/tools/libxc/xc_hvm_build.c
> +++ b/tools/libxc/xc_hvm_build.c
> @@ -38,12 +38,15 @@
>  #define SUPERPAGE_1GB_SHIFT   18
>  #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
> 
> -#define SPECIALPAGE_BUFIOREQ 0
> -#define SPECIALPAGE_XENSTORE 1
> -#define SPECIALPAGE_IOREQ    2
> -#define SPECIALPAGE_IDENT_PT 3
> -#define SPECIALPAGE_CONSOLE  4
> -#define NR_SPECIAL_PAGES     5
> +#define SPECIALPAGE_PAGING   0
> +#define SPECIALPAGE_ACCESS   1
> +#define SPECIALPAGE_SHARING  2
> +#define SPECIALPAGE_BUFIOREQ 3
> +#define SPECIALPAGE_XENSTORE 4
> +#define SPECIALPAGE_IOREQ    5
> +#define SPECIALPAGE_IDENT_PT 6
> +#define SPECIALPAGE_CONSOLE  7
> +#define NR_SPECIAL_PAGES     8

Any reason to not simply append 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 Feb 28 13:05:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13: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 1S2MkQ-0003NP-5H; Tue, 28 Feb 2012 13:05:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2MkO-0003NE-TS
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:05:41 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330434333!10621461!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32044 invoked from network); 28 Feb 2012 13:05:34 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:05:34 -0000
Received: by yenl11 with SMTP id l11so39540379yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 05:05:32 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.179.7 as permitted sender) client-ip=10.50.179.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.179.7 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.179.7])
	by 10.50.179.7 with SMTP id dc7mr2386484igc.38.1330434332589 (num_hops
	= 1); Tue, 28 Feb 2012 05:05:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ylGQfY9NBy+RgOCr3oF5DuuL/m+hoPz3eKyGZoNZ3dQ=;
	b=nKtqxSuwR7P9mpILo22/VsOdmVKjELqyMN2ZSCqZ64IKBxUbjlGLY8N8IG2u9y7qVu
	IeW/EhMt9/JBH/+/8J6MhaG6gq6JbhqnzTB1JTVz05VeyZUZiIVo9p5KQlUnQdGSH4dw
	k18107Lem2K8bK4M1X18xOexyiHrjIeMOIG/g=
MIME-Version: 1.0
Received: by 10.50.179.7 with SMTP id dc7mr2015269igc.38.1330434332540; Tue,
	28 Feb 2012 05:05:32 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 05:05:31 -0800 (PST)
In-Reply-To: <9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
	<9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
Date: Tue, 28 Feb 2012 13:05:31 +0000
X-Google-Sender-Auth: bbbMxJZy_A1W-UjNVC_mPFANP0c
Message-ID: <CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: andres@lagarcavilla.org
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>> shared page gains you nothing. The ballooner can't know what is shared
>>> and what isn't, in order to make an educated decision. And the sharer
>>> can't foresee what the balloon will victimize.
>>
>> Doesn't ballooning generally evict unused pages, because it allocates
>> new _free_ pages, even if they were shared is there any benefit to doing
>> so?
>
> Certainly the balloon will pick free pages. The sharing daemon should not
> have shared those, but it's not unlikely that it will have.
>
> It's a classic semantic gap problem, and we were discussing this in the
> context of paging ("the pager should not have paged out page table pages")
>
> Beyond free pages, a prime target for sharing are read-only disk buffers
> in the page cache. Those are victim #2 for the balloon.

Not exactly -- victim #2 would be read-only disk buffers *which have
not been read recently*.  Buffers which are in active use will not be
evicted.  So although evicting these pages from the guests' cache
doesn't buy the system any more memory, it doesn't have a major impact
on the guest either.

In any case, if the guest experiences its own internal memory
pressure, these pages will be the first to go anyway.  After that, it
will go for trying to evict infrequently-used read-write pages --
which, if the pager is active, will already have been paged out to
disk; thus we'll end up with the double-paging problem.  This will
have a much larger impact on performance than uselessly evicting
little-used read-only pages.

So I think that even though sharing+balloon will lead to some
occasional sub-optimal behavior, it's still a lot better than
sharing+paging and no ballooning.  Remember that ballooning was a
technique introduced in the paper by VMWare that talked about page
sharing -- they obviously thought sharing+ballooning was better than
sharing+paging.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 13:05:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13: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 1S2MkQ-0003NP-5H; Tue, 28 Feb 2012 13:05:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2MkO-0003NE-TS
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:05:41 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330434333!10621461!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32044 invoked from network); 28 Feb 2012 13:05:34 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:05:34 -0000
Received: by yenl11 with SMTP id l11so39540379yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 05:05:32 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.179.7 as permitted sender) client-ip=10.50.179.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.179.7 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.179.7])
	by 10.50.179.7 with SMTP id dc7mr2386484igc.38.1330434332589 (num_hops
	= 1); Tue, 28 Feb 2012 05:05:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ylGQfY9NBy+RgOCr3oF5DuuL/m+hoPz3eKyGZoNZ3dQ=;
	b=nKtqxSuwR7P9mpILo22/VsOdmVKjELqyMN2ZSCqZ64IKBxUbjlGLY8N8IG2u9y7qVu
	IeW/EhMt9/JBH/+/8J6MhaG6gq6JbhqnzTB1JTVz05VeyZUZiIVo9p5KQlUnQdGSH4dw
	k18107Lem2K8bK4M1X18xOexyiHrjIeMOIG/g=
MIME-Version: 1.0
Received: by 10.50.179.7 with SMTP id dc7mr2015269igc.38.1330434332540; Tue,
	28 Feb 2012 05:05:32 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 05:05:31 -0800 (PST)
In-Reply-To: <9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
	<9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
Date: Tue, 28 Feb 2012 13:05:31 +0000
X-Google-Sender-Auth: bbbMxJZy_A1W-UjNVC_mPFANP0c
Message-ID: <CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: andres@lagarcavilla.org
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>> shared page gains you nothing. The ballooner can't know what is shared
>>> and what isn't, in order to make an educated decision. And the sharer
>>> can't foresee what the balloon will victimize.
>>
>> Doesn't ballooning generally evict unused pages, because it allocates
>> new _free_ pages, even if they were shared is there any benefit to doing
>> so?
>
> Certainly the balloon will pick free pages. The sharing daemon should not
> have shared those, but it's not unlikely that it will have.
>
> It's a classic semantic gap problem, and we were discussing this in the
> context of paging ("the pager should not have paged out page table pages")
>
> Beyond free pages, a prime target for sharing are read-only disk buffers
> in the page cache. Those are victim #2 for the balloon.

Not exactly -- victim #2 would be read-only disk buffers *which have
not been read recently*.  Buffers which are in active use will not be
evicted.  So although evicting these pages from the guests' cache
doesn't buy the system any more memory, it doesn't have a major impact
on the guest either.

In any case, if the guest experiences its own internal memory
pressure, these pages will be the first to go anyway.  After that, it
will go for trying to evict infrequently-used read-write pages --
which, if the pager is active, will already have been paged out to
disk; thus we'll end up with the double-paging problem.  This will
have a much larger impact on performance than uselessly evicting
little-used read-only pages.

So I think that even though sharing+balloon will lead to some
occasional sub-optimal behavior, it's still a lot better than
sharing+paging and no ballooning.  Remember that ballooning was a
technique introduced in the paper by VMWare that talked about page
sharing -- they obviously thought sharing+ballooning was better than
sharing+paging.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 13:35:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2NCQ-0003zS-Bh; Tue, 28 Feb 2012 13:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1S2NCO-0003zN-EJ
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:34:36 +0000
Received: from [85.158.139.83:6260] by server-7.bemta-5.messagelabs.com id
	56/74-16195-BE7DC4F4; Tue, 28 Feb 2012 13:34:35 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330436074!17066653!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTkzOTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18376 invoked from network); 28 Feb 2012 13:34:34 -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; 28 Feb 2012 13:34:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1B9802C51;
	Tue, 28 Feb 2012 15:34:33 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D5C412004A; Tue, 28 Feb 2012 15:34:32 +0200 (EET)
Date: Tue, 28 Feb 2012 15:34:32 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120228133432.GV12984@reaktio.net>
References: <4F4BCEBE.6010608@citrix.com> <20120227192746.GU12984@reaktio.net>
	<4F4CA108.3040009@citrix.com>
	<1330422420.31269.25.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330422420.31269.25.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 09:47:00AM +0000, Ian Campbell wrote:
> On Tue, 2012-02-28 at 09:40 +0000, Andrew Cooper wrote:
> > On 27/02/12 19:27, Pasi K=E4rkk=E4inen wrote:
> > > On Mon, Feb 27, 2012 at 06:43:10PM +0000, Andrew Cooper wrote:
> > >> Attached is an attempt to document all the Xen command line paramete=
rs.
> > >>
> > >> Because of other tasks, (and choosing to document the rather twisty
> > >> 'acpi' option first), It is far less complete than I was hoping.
> > >>
> > >> However, I am submitting it so other people may benefit (and contrib=
ute)
> > >> going forward.
> > >>
> > > Related link:
> > > http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options
> > >
> > > -- Pasi
> > =

> > Yes - I am aware of that, but sadly it is starting to get out of date. =

> > The idea of having a markdown document in the source tree is so any
> > patch modifying command line behavior should also patch this file, so
> > hopefully the document will stay up to date going forward.
> =

> A good starting point would be to cut-n-paste that wiki page into the
> markdown docs and then replace the wiki page with a link to the
> generated docs at http://xenbits.xen.org/docs . This would be preferable
> to starting completely from scratch.
> =


Makes sense..

> Aside That wiki page's use of "Grub.conf options for Xen" vs "Xen
> Command Line" is pretty confusing, I think it is trying to say "Xen
> Command Line" and "Dom0 Linux Kernel Command Line" respectively but I
> wasn't sure so I didn't want to touch it.
> =


I think there is (or at least was on the old wiki) a page listing all the d=
om0 kernel options.

So the Xen_Hypervisor_Boot_Options has only Xen (xen.gz) options.

-- Pasi

> Ian.
> =

> > =

> > ~Andrew
> > =

> > >
> > >> -- =

> > >> 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 Feb 28 13:35:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 13:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2NCQ-0003zS-Bh; Tue, 28 Feb 2012 13:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1S2NCO-0003zN-EJ
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 13:34:36 +0000
Received: from [85.158.139.83:6260] by server-7.bemta-5.messagelabs.com id
	56/74-16195-BE7DC4F4; Tue, 28 Feb 2012 13:34:35 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330436074!17066653!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTkzOTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18376 invoked from network); 28 Feb 2012 13:34:34 -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; 28 Feb 2012 13:34:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1B9802C51;
	Tue, 28 Feb 2012 15:34:33 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D5C412004A; Tue, 28 Feb 2012 15:34:32 +0200 (EET)
Date: Tue, 28 Feb 2012 15:34:32 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120228133432.GV12984@reaktio.net>
References: <4F4BCEBE.6010608@citrix.com> <20120227192746.GU12984@reaktio.net>
	<4F4CA108.3040009@citrix.com>
	<1330422420.31269.25.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330422420.31269.25.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] DOC-DAY: WIP for command line options documentation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 09:47:00AM +0000, Ian Campbell wrote:
> On Tue, 2012-02-28 at 09:40 +0000, Andrew Cooper wrote:
> > On 27/02/12 19:27, Pasi K=E4rkk=E4inen wrote:
> > > On Mon, Feb 27, 2012 at 06:43:10PM +0000, Andrew Cooper wrote:
> > >> Attached is an attempt to document all the Xen command line paramete=
rs.
> > >>
> > >> Because of other tasks, (and choosing to document the rather twisty
> > >> 'acpi' option first), It is far less complete than I was hoping.
> > >>
> > >> However, I am submitting it so other people may benefit (and contrib=
ute)
> > >> going forward.
> > >>
> > > Related link:
> > > http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options
> > >
> > > -- Pasi
> > =

> > Yes - I am aware of that, but sadly it is starting to get out of date. =

> > The idea of having a markdown document in the source tree is so any
> > patch modifying command line behavior should also patch this file, so
> > hopefully the document will stay up to date going forward.
> =

> A good starting point would be to cut-n-paste that wiki page into the
> markdown docs and then replace the wiki page with a link to the
> generated docs at http://xenbits.xen.org/docs . This would be preferable
> to starting completely from scratch.
> =


Makes sense..

> Aside That wiki page's use of "Grub.conf options for Xen" vs "Xen
> Command Line" is pretty confusing, I think it is trying to say "Xen
> Command Line" and "Dom0 Linux Kernel Command Line" respectively but I
> wasn't sure so I didn't want to touch it.
> =


I think there is (or at least was on the old wiki) a page listing all the d=
om0 kernel options.

So the Xen_Hypervisor_Boot_Options has only Xen (xen.gz) options.

-- Pasi

> Ian.
> =

> > =

> > ~Andrew
> > =

> > >
> > >> -- =

> > >> 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 Feb 28 14:00:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Nb2-0004L6-M4; Tue, 28 Feb 2012 14:00:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2Nb0-0004H4-Uo
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:00:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330437595!15287219!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22008 invoked from network); 28 Feb 2012 13:59:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:59:56 -0000
Received: by iadj38 with SMTP id j38so6600967iad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 05:59:54 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.158.227 as permitted sender) client-ip=10.50.158.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.158.227 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.158.227])
	by 10.50.158.227 with SMTP id wx3mr2555860igb.46.1330437594952
	(num_hops = 1); Tue, 28 Feb 2012 05:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=gE9Ei8VkRLL5KCIM0p5udiUwAjkQ4uZEIIPE4PrLs1w=;
	b=oqtiz2IB5XN9KlwVSxrWwb8PfGklczPW4oJs10/BWAfNIK7zyyp48R7KIWXZrPJgZs
	ugcp1iL7VgOiS9fF7R7Q1vNs9WKQBcWEdPHT0symvpfDZF8ey0uL0w2cuGONN1WDS2BZ
	sPL8Fcv0Q8BJ6K5fULLmBVoofCbJ6qTUN+Mgk=
MIME-Version: 1.0
Received: by 10.50.158.227 with SMTP id wx3mr2134180igb.46.1330437294045; Tue,
	28 Feb 2012 05:54:54 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 05:54:53 -0800 (PST)
In-Reply-To: <104d17ef-192d-4a13-9d19-b27a58f04384@default>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
Date: Tue, 28 Feb 2012 13:54:53 +0000
X-Google-Sender-Auth: d7pfRsRigGiB8AsJRxxhE-NtsVk
Message-ID: <CAFLBxZZSPwPd0q7ng3BLW+nRaFaxCLYNX98xEcJinbU9jk0emw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 11:40 PM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
>> From: Olaf Hering [mailto:olaf@aepfle.de]
>
> Hi Olaf --
>
> Thanks for the reply! =A0Since Tim answers my questions later in the
> thread, one quick comment...
>
>> To me memory overcommit means swapping, which is what xenpaging does:
>> turn the whole guest gfn range into some sort of virtual memory,
>> transparent to the guest.
>>
>> xenpaging is the red emergency knob to free some host memory without
>> caring about the actual memory constraints within the paged guests.
>
> Sure, but the whole point of increasing RAM in one or more guests
> is to increase performance, and if overcommitting *always* means
> swapping, why would anyone use it?
>
> So xenpaging is fine and useful, but IMHO only in conjunction
> with some other technology that reduces total physical RAM usage
> to less than sum(max_mem(all VMs)).

I agree -- overcommitting means giving the guests the illusion of more
aggregate memory than there is.  Paging is one way of doing that; page
sharing is another way.  The big reason paging is needed is if guests
start to "call in" the committments, by writing to previously shared
pages.  I would think tmem would also come under "memory overcommit".

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:00:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Nb2-0004L6-M4; Tue, 28 Feb 2012 14:00:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2Nb0-0004H4-Uo
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:00:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330437595!15287219!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22008 invoked from network); 28 Feb 2012 13:59:56 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:59:56 -0000
Received: by iadj38 with SMTP id j38so6600967iad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 05:59:54 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.158.227 as permitted sender) client-ip=10.50.158.227; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.158.227 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.158.227])
	by 10.50.158.227 with SMTP id wx3mr2555860igb.46.1330437594952
	(num_hops = 1); Tue, 28 Feb 2012 05:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=gE9Ei8VkRLL5KCIM0p5udiUwAjkQ4uZEIIPE4PrLs1w=;
	b=oqtiz2IB5XN9KlwVSxrWwb8PfGklczPW4oJs10/BWAfNIK7zyyp48R7KIWXZrPJgZs
	ugcp1iL7VgOiS9fF7R7Q1vNs9WKQBcWEdPHT0symvpfDZF8ey0uL0w2cuGONN1WDS2BZ
	sPL8Fcv0Q8BJ6K5fULLmBVoofCbJ6qTUN+Mgk=
MIME-Version: 1.0
Received: by 10.50.158.227 with SMTP id wx3mr2134180igb.46.1330437294045; Tue,
	28 Feb 2012 05:54:54 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 05:54:53 -0800 (PST)
In-Reply-To: <104d17ef-192d-4a13-9d19-b27a58f04384@default>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
Date: Tue, 28 Feb 2012 13:54:53 +0000
X-Google-Sender-Auth: d7pfRsRigGiB8AsJRxxhE-NtsVk
Message-ID: <CAFLBxZZSPwPd0q7ng3BLW+nRaFaxCLYNX98xEcJinbU9jk0emw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, 2012 at 11:40 PM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
>> From: Olaf Hering [mailto:olaf@aepfle.de]
>
> Hi Olaf --
>
> Thanks for the reply! =A0Since Tim answers my questions later in the
> thread, one quick comment...
>
>> To me memory overcommit means swapping, which is what xenpaging does:
>> turn the whole guest gfn range into some sort of virtual memory,
>> transparent to the guest.
>>
>> xenpaging is the red emergency knob to free some host memory without
>> caring about the actual memory constraints within the paged guests.
>
> Sure, but the whole point of increasing RAM in one or more guests
> is to increase performance, and if overcommitting *always* means
> swapping, why would anyone use it?
>
> So xenpaging is fine and useful, but IMHO only in conjunction
> with some other technology that reduces total physical RAM usage
> to less than sum(max_mem(all VMs)).

I agree -- overcommitting means giving the guests the illusion of more
aggregate memory than there is.  Paging is one way of doing that; page
sharing is another way.  The big reason paging is needed is if guests
start to "call in" the committments, by writing to previously shared
pages.  I would think tmem would also come under "memory overcommit".

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:00:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2Nb3-0004LD-1v; Tue, 28 Feb 2012 14:00:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2Nb2-0004H5-8q
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:00:04 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330437595!15287219!2
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22123 invoked from network); 28 Feb 2012 13:59:58 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:59:58 -0000
Received: by mail-iy0-f171.google.com with SMTP id j38so6600967iad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 05:59:57 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.179.7 as permitted sender) client-ip=10.50.179.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.179.7 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.179.7])
	by 10.50.179.7 with SMTP id dc7mr2569203igc.38.1330437597662 (num_hops
	= 1); Tue, 28 Feb 2012 05:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=dJRYU16aKLLiFa3gwMIjqe0FPKS/Dwih1DuEUitjTvY=;
	b=EYs15UV00Wtn/3yyomSDmoJLH00H1U2SfizGSSi+ze/vofI9yVqUWW4Ta73i3u8Tv/
	pkDdb4r0QJe7WaUx0EWPQ9x/3wUUIEIdhcANwlhAaxQ6YN5MUh28KbqPspLyE2dz9VNU
	aeaetwtWyseW5UbD9/wCEAP8+ZvLWn0oZK7yI=
MIME-Version: 1.0
Received: by 10.50.179.7 with SMTP id dc7mr2165405igc.38.1330437597621; Tue,
	28 Feb 2012 05:59:57 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 05:59:57 -0800 (PST)
In-Reply-To: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 13:59:57 +0000
X-Google-Sender-Auth: G2OzOuyvywQGnoycnCQbgVWcM-c
Message-ID: <CAFLBxZbViMi5w9UsJVy0kRZ+J9RFx8b=1rySTDkmngCO9Hbgfw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 12:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> Day late due to doc day yesterday. FYI I'll be at the hackathon next
> week so I expect I'll be skipping that update.
>
> As usual please ping me with any updates/corrections.
>
> hypervisor, blockers:
> =A0 =A0 =A0* domctls / sysctls set up to modify scheduler parameters, like
> =A0 =A0 =A0 =A0the credit1 timeslice and schedule rate. (George Dunlap, p=
atches
> =A0 =A0 =A0 =A0posted)

Hypervisor patches and (I believe) libxc patches committed; just libxl
/ xl patches outstanding.

> tools, blockers:
>
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* add libxl_defbool and generally try and arra=
nge that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(foo,0,...) requests the defaults (I=
an Campbell,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches reposted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. This is an =
API
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addition, so maybe not required fro stable=
 API, bit need
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to have for 4.2? (Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl feature parity with xend wrt driver domai=
n support
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(George Dunlap)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* More formally deprecate xm/xend. Manpage pat=
ches already
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in tree. Needs release noting and communic=
ation around
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-rc1 to remind people to test xl.
> =A0 =A0 =A0* Correct paging/sharing tools buffer mlocking (Tim, Andres,
> =A0 =A0 =A0 =A0patches posted)
> =A0 =A0 =A0* Autoconf (Roger Pau Monn=E9 & Ian J, DONE)
> =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localtime" (Nobody AFAI=
CT)
>
> hypervisor, nice to have:
> =A0 =A0 =A0*
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al)
> =A0 =A0 =A0* A long standing issue is a fully synchronized p2m (locking
> =A0 =A0 =A0 =A0lookups) (Andres Lagar-Cavilla, DONE)
>
> tools, nice to have:
>
> =A0 =A0 =A0* Hotplug script stuff -- internal to libxl (I think, therefor=
e I
> =A0 =A0 =A0 =A0didn't put this under stable API above) but still good to =
have
> =A0 =A0 =A0 =A0for 4.2? (Roger Pau Monn=E9, patches posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, patches sent, waiting for upst=
ream ack)
> =A0 =A0 =A0* Nested-virtualisation (currently should be marked experiment=
al,
> =A0 =A0 =A0 =A0likely to release that way? Consider nested-svm separate to
> =A0 =A0 =A0 =A0nested-vmx. Nested-svm is in better shape)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, patches posted, blocked behind qemu save restore
> =A0 =A0 =A0 =A0patches)
> =A0 =A0 =A0* xl support for autospawning vncviewer (vncviewer=3D1 or othe=
rwise)
> =A0 =A0 =A0 =A0(Nobody AFAICT)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:00:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2Nb3-0004LD-1v; Tue, 28 Feb 2012 14:00:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2Nb2-0004H5-8q
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:00:04 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330437595!15287219!2
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22123 invoked from network); 28 Feb 2012 13:59:58 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 13:59:58 -0000
Received: by mail-iy0-f171.google.com with SMTP id j38so6600967iad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 05:59:57 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.179.7 as permitted sender) client-ip=10.50.179.7; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.179.7 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.179.7])
	by 10.50.179.7 with SMTP id dc7mr2569203igc.38.1330437597662 (num_hops
	= 1); Tue, 28 Feb 2012 05:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=dJRYU16aKLLiFa3gwMIjqe0FPKS/Dwih1DuEUitjTvY=;
	b=EYs15UV00Wtn/3yyomSDmoJLH00H1U2SfizGSSi+ze/vofI9yVqUWW4Ta73i3u8Tv/
	pkDdb4r0QJe7WaUx0EWPQ9x/3wUUIEIdhcANwlhAaxQ6YN5MUh28KbqPspLyE2dz9VNU
	aeaetwtWyseW5UbD9/wCEAP8+ZvLWn0oZK7yI=
MIME-Version: 1.0
Received: by 10.50.179.7 with SMTP id dc7mr2165405igc.38.1330437597621; Tue,
	28 Feb 2012 05:59:57 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 05:59:57 -0800 (PST)
In-Reply-To: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 13:59:57 +0000
X-Google-Sender-Auth: G2OzOuyvywQGnoycnCQbgVWcM-c
Message-ID: <CAFLBxZbViMi5w9UsJVy0kRZ+J9RFx8b=1rySTDkmngCO9Hbgfw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 12:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> Day late due to doc day yesterday. FYI I'll be at the hackathon next
> week so I expect I'll be skipping that update.
>
> As usual please ping me with any updates/corrections.
>
> hypervisor, blockers:
> =A0 =A0 =A0* domctls / sysctls set up to modify scheduler parameters, like
> =A0 =A0 =A0 =A0the credit1 timeslice and schedule rate. (George Dunlap, p=
atches
> =A0 =A0 =A0 =A0posted)

Hypervisor patches and (I believe) libxc patches committed; just libxl
/ xl patches outstanding.

> tools, blockers:
>
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* add libxl_defbool and generally try and arra=
nge that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(foo,0,...) requests the defaults (I=
an Campbell,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches reposted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. This is an =
API
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addition, so maybe not required fro stable=
 API, bit need
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to have for 4.2? (Ian J, patches posted)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl feature parity with xend wrt driver domai=
n support
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(George Dunlap)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* More formally deprecate xm/xend. Manpage pat=
ches already
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in tree. Needs release noting and communic=
ation around
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-rc1 to remind people to test xl.
> =A0 =A0 =A0* Correct paging/sharing tools buffer mlocking (Tim, Andres,
> =A0 =A0 =A0 =A0patches posted)
> =A0 =A0 =A0* Autoconf (Roger Pau Monn=E9 & Ian J, DONE)
> =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localtime" (Nobody AFAI=
CT)
>
> hypervisor, nice to have:
> =A0 =A0 =A0*
> =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work
> =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al)
> =A0 =A0 =A0* A long standing issue is a fully synchronized p2m (locking
> =A0 =A0 =A0 =A0lookups) (Andres Lagar-Cavilla, DONE)
>
> tools, nice to have:
>
> =A0 =A0 =A0* Hotplug script stuff -- internal to libxl (I think, therefor=
e I
> =A0 =A0 =A0 =A0didn't put this under stable API above) but still good to =
have
> =A0 =A0 =A0 =A0for 4.2? (Roger Pau Monn=E9, patches posted)
> =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger
> =A0 =A0 =A0 =A0Pau Monn=E9)
> =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring)
> =A0 =A0 =A0* Upstream qemu feature patches:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho=
ny Perard,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, =
Stefano
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, patches sent, waiting for upst=
ream ack)
> =A0 =A0 =A0* Nested-virtualisation (currently should be marked experiment=
al,
> =A0 =A0 =A0 =A0likely to release that way? Consider nested-svm separate to
> =A0 =A0 =A0 =A0nested-vmx. Nested-svm is in better shape)
> =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing)
> =A0 =A0 =A0 =A0(Shriram, patches posted, blocked behind qemu save restore
> =A0 =A0 =A0 =A0patches)
> =A0 =A0 =A0* xl support for autospawning vncviewer (vncviewer=3D1 or othe=
rwise)
> =A0 =A0 =A0 =A0(Nobody AFAICT)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:03:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2NeK-0004Wr-Lo; Tue, 28 Feb 2012 14:03:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2NeI-0004Wb-QY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:03:27 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330437799!8495856!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13961 invoked from network); 28 Feb 2012 14:03:19 -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; 28 Feb 2012 14:03:19 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 47BD740021F
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:03:19 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id SsWA-DcFNxgc for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:03:18 +0100 (CET)
Received: from [192.168.178.50]
	(host239-90-dynamic.11-79-r.retail.telecomitalia.it [79.11.90.239])
	(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 584E44000E2
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:03:18 +0100 (CET)
Message-ID: <4F4CDEA2.1000909@tiscali.it>
Date: Tue, 28 Feb 2012 15:03:14 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] tools/examples: Move readmes and examples to
 subdirectory docs
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="===============8030474553492293441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8030474553492293441==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070201030906050506040908"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070201030906050506040908
Content-Type: multipart/mixed;
 boundary="------------080809040108010600030708"

This is a multi-part message in MIME format.
--------------080809040108010600030708
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

tools/examples: Move readmes and examples to subdirectory docs

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index 8cea724..be71872 100644
--- a/tools/examples/Makefile
+++ b/tools/examples/Makefile
@@ -7,20 +7,20 @@ XENDOMAINS_INITD =3D init.d/xendomains
  XENDOMAINS_SYSCONFIG =3D init.d/sysconfig.xendomains

  # Xen configuration dir and configs to go there.
-XEN_READMES =3D README
-XEN_READMES +=3D README.incompatibilities
+XEN_DOCS =3D README
+XEN_DOCS +=3D README.incompatibilities
  XEN_CONFIGS =3D xend-config.sxp
  XEN_CONFIGS +=3D xm-config.xml
-XEN_CONFIGS +=3D xmexample1
-XEN_CONFIGS +=3D xmexample2
-XEN_CONFIGS +=3D xmexample3
-XEN_CONFIGS +=3D xmexample.hvm
-XEN_CONFIGS +=3D xmexample.hvm-stubdom
-XEN_CONFIGS +=3D xmexample.pv-grub
-XEN_CONFIGS +=3D xmexample.nbd
-XEN_CONFIGS +=3D xmexample.vti
-XEN_CONFIGS +=3D xlexample.hvm
-XEN_CONFIGS +=3D xlexample.pvlinux
+XEN_DOCS +=3D xmexample1
+XEN_DOCS +=3D xmexample2
+XEN_DOCS +=3D xmexample3
+XEN_DOCS +=3D xmexample.hvm
+XEN_DOCS +=3D xmexample.hvm-stubdom
+XEN_DOCS +=3D xmexample.pv-grub
+XEN_DOCS +=3D xmexample.nbd
+XEN_DOCS +=3D xmexample.vti
+XEN_DOCS +=3D xlexample.hvm
+XEN_DOCS +=3D xlexample.pvlinux
  XEN_CONFIGS +=3D xend-pci-quirks.sxp
  XEN_CONFIGS +=3D xend-pci-permissive.sxp
  XEN_CONFIGS +=3D xl.conf
@@ -33,15 +33,17 @@ all:
  build:

  .PHONY: install
-install: all install-readmes install-configs $(HOTPLUGS)
+install: all install-docs install-configs $(HOTPLUGS)

-.PHONY: install-readmes
-install-readmes:
+.PHONY: install-docs
+install-docs:
      [ -d $(DESTDIR)$(XEN_CONFIG_DIR) ] || \
          $(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
-    set -e; for i in $(XEN_READMES); \
-        do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/$$i ] || \
-        $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR); \
+    [ -d $(DESTDIR)$(XEN_CONFIG_DIR)/docs ] || \
+        $(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)/docs
+    set -e; for i in $(XEN_DOCS); \
+        do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/docs/$$i ] || \
+        $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR)/docs/; \
      done

  .PHONY: install-configs

--------------080809040108010600030708
Content-Type: text/plain;
 name="move_readmes_and_example_to_subdir_docs.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="move_readmes_and_example_to_subdir_docs.patch"

dG9vbHMvZXhhbXBsZXM6IE1vdmUgcmVhZG1lcyBhbmQgZXhhbXBsZXMgdG8gc3ViZGlyZWN0
b3J5IGRvY3MKClNpZ25lZC1vZmYtYnk6IEZhYmlvIEZhbnRvbmkgPGZhYmlvLmZhbnRvbmlA
aGVsaW1hbi5pdD4KCmRpZmYgLS1naXQgYS90b29scy9leGFtcGxlcy9NYWtlZmlsZSBiL3Rv
b2xzL2V4YW1wbGVzL01ha2VmaWxlCmluZGV4IDhjZWE3MjQuLmJlNzE4NzIgMTAwNjQ0Ci0t
LSBhL3Rvb2xzL2V4YW1wbGVzL01ha2VmaWxlCisrKyBiL3Rvb2xzL2V4YW1wbGVzL01ha2Vm
aWxlCkBAIC03LDIwICs3LDIwIEBAIFhFTkRPTUFJTlNfSU5JVEQgPSBpbml0LmQveGVuZG9t
YWlucwogWEVORE9NQUlOU19TWVNDT05GSUcgPSBpbml0LmQvc3lzY29uZmlnLnhlbmRvbWFp
bnMKIAogIyBYZW4gY29uZmlndXJhdGlvbiBkaXIgYW5kIGNvbmZpZ3MgdG8gZ28gdGhlcmUu
Ci1YRU5fUkVBRE1FUyA9IFJFQURNRQotWEVOX1JFQURNRVMgKz0gUkVBRE1FLmluY29tcGF0
aWJpbGl0aWVzCitYRU5fRE9DUyA9IFJFQURNRQorWEVOX0RPQ1MgKz0gUkVBRE1FLmluY29t
cGF0aWJpbGl0aWVzCiBYRU5fQ09ORklHUyA9IHhlbmQtY29uZmlnLnN4cAogWEVOX0NPTkZJ
R1MgKz0geG0tY29uZmlnLnhtbAotWEVOX0NPTkZJR1MgKz0geG1leGFtcGxlMSAKLVhFTl9D
T05GSUdTICs9IHhtZXhhbXBsZTIKLVhFTl9DT05GSUdTICs9IHhtZXhhbXBsZTMKLVhFTl9D
T05GSUdTICs9IHhtZXhhbXBsZS5odm0KLVhFTl9DT05GSUdTICs9IHhtZXhhbXBsZS5odm0t
c3R1YmRvbQotWEVOX0NPTkZJR1MgKz0geG1leGFtcGxlLnB2LWdydWIKLVhFTl9DT05GSUdT
ICs9IHhtZXhhbXBsZS5uYmQKLVhFTl9DT05GSUdTICs9IHhtZXhhbXBsZS52dGkKLVhFTl9D
T05GSUdTICs9IHhsZXhhbXBsZS5odm0KLVhFTl9DT05GSUdTICs9IHhsZXhhbXBsZS5wdmxp
bnV4CitYRU5fRE9DUyArPSB4bWV4YW1wbGUxIAorWEVOX0RPQ1MgKz0geG1leGFtcGxlMgor
WEVOX0RPQ1MgKz0geG1leGFtcGxlMworWEVOX0RPQ1MgKz0geG1leGFtcGxlLmh2bQorWEVO
X0RPQ1MgKz0geG1leGFtcGxlLmh2bS1zdHViZG9tCitYRU5fRE9DUyArPSB4bWV4YW1wbGUu
cHYtZ3J1YgorWEVOX0RPQ1MgKz0geG1leGFtcGxlLm5iZAorWEVOX0RPQ1MgKz0geG1leGFt
cGxlLnZ0aQorWEVOX0RPQ1MgKz0geGxleGFtcGxlLmh2bQorWEVOX0RPQ1MgKz0geGxleGFt
cGxlLnB2bGludXgKIFhFTl9DT05GSUdTICs9IHhlbmQtcGNpLXF1aXJrcy5zeHAKIFhFTl9D
T05GSUdTICs9IHhlbmQtcGNpLXBlcm1pc3NpdmUuc3hwCiBYRU5fQ09ORklHUyArPSB4bC5j
b25mCkBAIC0zMywxNSArMzMsMTcgQEAgYWxsOgogYnVpbGQ6CiAKIC5QSE9OWTogaW5zdGFs
bAotaW5zdGFsbDogYWxsIGluc3RhbGwtcmVhZG1lcyBpbnN0YWxsLWNvbmZpZ3MgJChIT1RQ
TFVHUykKK2luc3RhbGw6IGFsbCBpbnN0YWxsLWRvY3MgaW5zdGFsbC1jb25maWdzICQoSE9U
UExVR1MpCiAKLS5QSE9OWTogaW5zdGFsbC1yZWFkbWVzCi1pbnN0YWxsLXJlYWRtZXM6Cisu
UEhPTlk6IGluc3RhbGwtZG9jcworaW5zdGFsbC1kb2NzOgogCVsgLWQgJChERVNURElSKSQo
WEVOX0NPTkZJR19ESVIpIF0gfHwgXAogCQkkKElOU1RBTExfRElSKSAkKERFU1RESVIpJChY
RU5fQ09ORklHX0RJUikKLQlzZXQgLWU7IGZvciBpIGluICQoWEVOX1JFQURNRVMpOyBcCi0J
ICAgIGRvIFsgLWUgJChERVNURElSKSQoWEVOX0NPTkZJR19ESVIpLyQkaSBdIHx8IFwKLQkg
ICAgJChJTlNUQUxMX0RBVEEpICQkaSAkKERFU1RESVIpJChYRU5fQ09ORklHX0RJUik7IFwK
KwlbIC1kICQoREVTVERJUikkKFhFTl9DT05GSUdfRElSKS9kb2NzIF0gfHwgXAorCQkkKElO
U1RBTExfRElSKSAkKERFU1RESVIpJChYRU5fQ09ORklHX0RJUikvZG9jcworCXNldCAtZTsg
Zm9yIGkgaW4gJChYRU5fRE9DUyk7IFwKKwkgICAgZG8gWyAtZSAkKERFU1RESVIpJChYRU5f
Q09ORklHX0RJUikvZG9jcy8kJGkgXSB8fCBcCisJICAgICQoSU5TVEFMTF9EQVRBKSAkJGkg
JChERVNURElSKSQoWEVOX0NPTkZJR19ESVIpL2RvY3MvOyBcCiAJZG9uZQogCiAuUEhPTlk6
IGluc3RhbGwtY29uZmlncwog
--------------080809040108010600030708--

--------------ms070201030906050506040908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuDCC
Bs4wggW2oAMCAQICAgYuMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwHhcNMTAwMzE1MDEzNjEyWhcNMTIwMzE1MTgyMDI0WjCBwjEgMB4GA1UE
DRMXMTYzNjM4LU1SaENTbDhEM1BCVDVpRkQxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdCZXJn
YW1vMRAwDgYDVQQHEwdSb3ZldHRhMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxFjAUBgNVBAMTDUZhYmlvIEZhbnRvbmkxJjAkBgkqhkiG9w0BCQEW
F2ZhbnRvbmlmYWJpb0B0aXNjYWxpLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA77WvZhtp73ChfRf93cyCnb/kZtkekJf00AOSj4Rakj/Osadbbk4/5Oz85IZoTUMw6/Fk
wwqlWjcFTDmWF3AEB5wD7lddRkBYZ9VUCUdfUdlzHDOuarDf2V2hYgkVmErJLNYPmd8PdWuS
pknt9yvTdshVSQouyZwRo8HVA2k/RmLII/RZ2Mb7n8vKjnHzsx8OTyhesQvHKQSqcB5BylBN
dTcxkZcee5A7LP74lphcRMOXiHMZveYGjb0vKvw04+4fDp1vqY0GXZArHi4wTHHf3U3h4zGw
sVz4qEdtDgd5cNQq9ZCnENncmBnQnDbER86QVaiSrrtAYT76mxaJPLJ53wIDAQABo4IDADCC
AvwwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMB0GA1UdDgQWBBQ3WDZRCgKgMguGasRKY0STU5Op4DAfBgNVHSMEGDAWgBSuVYNv7DHK
ufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYW50b25pZmFiaW9AdGlzY2FsaS5pdDCCAUIG
A1UdIASCATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENv
bSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExp
bWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9s
aWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMG
A1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmww
K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh
c3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2Vy
dHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAk9f6iILWFDYsbUah0iASW6fCIvNya9Mq
hmcmCdthqCD0IpshjXsry6wiuZKHrX1jWXVriCnzBNROAvSMJRIon6nuGQSoItSe/6t92D7+
NTX2jAp/9ZAeljwoUMkeO7lodyK5qnbSNYjQ/SYN1OuULSAteg9LWkiI32HgledhHfiUcFAN
MOanv+qEJqVpEfTrrBZhKzO5eOZpjujUbkI48dBXrsEA4dgw/u9uqxUPtxYlA7XW/T9HEKwg
8OO/JNgyfkN6KrrjU4OI5/Xw1DJoNI8HY3lDAdkWMAP1sNpwZzcDI2Lo+jAKh9fKaHPlNaqC
pQhe/rTAzXazJIhTOwpTRTCCB+IwggXKoAMCAQICAQ4wDQYJKoZIhvcNAQEFBQAwfTELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YF
n7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2
acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzEl
VIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkz
UreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1sw
ggNXMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9r
MfPIHeOsuzCBqAYDVR0jBIGgMIGdgBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcw
AoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MGAGA1UdHwRZMFcwLKAqoCiG
Jmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCegJaAjhiFodHRwOi8v
Y3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQB
gbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlh
dGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkg
THRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs
IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBk
ZjARBglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIg
UHJpbWFyeSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqG
SIb3DQEBBQUAA4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J
40UBXsw9DKU8TylE4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1G
YTJ+hPiBEv0HmHnDxjhnJIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw
40K+r3N4lykySQNp2ElIJ8H1z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcp
DExcGlefweQs7+DYUK3spiQkJpN7qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHp
OUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJ
ul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHK
SboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9tsi77oT4AgZry0/6lgX56ak+f/umQihN
PgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDHjXoUAD03DUMEbKsWvqFB7nJNVesn
gbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bKqnkvpTGCA80wggPJAgEBMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMAkGBSsOAwIaBQCgggIO
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyODE0MDMx
NFowIwYJKoZIhvcNAQkEMRYEFHLWWjqD5SlLbR14i/ji+q2pl6+YMF8GCSqGSIb3DQEJDzFS
MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMIGmBgsqhkiG9w0BCRACCzGBlqCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGLjANBgkqhkiG9w0BAQEF
AASCAQBmLf13JUJJ5vSElFjKbdnvBa0K3Dy+im8Q3C00dtNz+DcUJ7L2PDQcazBkhxjxcylx
DEBc1ldd7bLA8GCOz/+U82gUucs1Rrzqc1ojChxeCi7WBzQ61Oapv16c9nPb+KuCFRL1ArP1
3xMXAmgb4XJU0zeuHkaBRAUee8lo4epTT/QQ0R2RYkOX7092xW0vmftgOpLNS9krj76EcpPm
5UWZj9Kih+0N5VgxrI80gcjb8zISYrti5vjO+H7s4YmlVh2IY25r/XEpwu9LRJKcmG9Elxfk
//afPGhjqWcGHg9kr0SeDY35vd9uhfPTzQKypteLMrgvoWK/GpxD5EyYTleCAAAAAAAA
--------------ms070201030906050506040908--


--===============8030474553492293441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8030474553492293441==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 14:03:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2NeK-0004Wr-Lo; Tue, 28 Feb 2012 14:03:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2NeI-0004Wb-QY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:03:27 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330437799!8495856!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13961 invoked from network); 28 Feb 2012 14:03:19 -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; 28 Feb 2012 14:03:19 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 47BD740021F
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:03:19 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id SsWA-DcFNxgc for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:03:18 +0100 (CET)
Received: from [192.168.178.50]
	(host239-90-dynamic.11-79-r.retail.telecomitalia.it [79.11.90.239])
	(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 584E44000E2
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:03:18 +0100 (CET)
Message-ID: <4F4CDEA2.1000909@tiscali.it>
Date: Tue, 28 Feb 2012 15:03:14 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] tools/examples: Move readmes and examples to
 subdirectory docs
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="===============8030474553492293441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8030474553492293441==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070201030906050506040908"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070201030906050506040908
Content-Type: multipart/mixed;
 boundary="------------080809040108010600030708"

This is a multi-part message in MIME format.
--------------080809040108010600030708
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

tools/examples: Move readmes and examples to subdirectory docs

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff --git a/tools/examples/Makefile b/tools/examples/Makefile
index 8cea724..be71872 100644
--- a/tools/examples/Makefile
+++ b/tools/examples/Makefile
@@ -7,20 +7,20 @@ XENDOMAINS_INITD =3D init.d/xendomains
  XENDOMAINS_SYSCONFIG =3D init.d/sysconfig.xendomains

  # Xen configuration dir and configs to go there.
-XEN_READMES =3D README
-XEN_READMES +=3D README.incompatibilities
+XEN_DOCS =3D README
+XEN_DOCS +=3D README.incompatibilities
  XEN_CONFIGS =3D xend-config.sxp
  XEN_CONFIGS +=3D xm-config.xml
-XEN_CONFIGS +=3D xmexample1
-XEN_CONFIGS +=3D xmexample2
-XEN_CONFIGS +=3D xmexample3
-XEN_CONFIGS +=3D xmexample.hvm
-XEN_CONFIGS +=3D xmexample.hvm-stubdom
-XEN_CONFIGS +=3D xmexample.pv-grub
-XEN_CONFIGS +=3D xmexample.nbd
-XEN_CONFIGS +=3D xmexample.vti
-XEN_CONFIGS +=3D xlexample.hvm
-XEN_CONFIGS +=3D xlexample.pvlinux
+XEN_DOCS +=3D xmexample1
+XEN_DOCS +=3D xmexample2
+XEN_DOCS +=3D xmexample3
+XEN_DOCS +=3D xmexample.hvm
+XEN_DOCS +=3D xmexample.hvm-stubdom
+XEN_DOCS +=3D xmexample.pv-grub
+XEN_DOCS +=3D xmexample.nbd
+XEN_DOCS +=3D xmexample.vti
+XEN_DOCS +=3D xlexample.hvm
+XEN_DOCS +=3D xlexample.pvlinux
  XEN_CONFIGS +=3D xend-pci-quirks.sxp
  XEN_CONFIGS +=3D xend-pci-permissive.sxp
  XEN_CONFIGS +=3D xl.conf
@@ -33,15 +33,17 @@ all:
  build:

  .PHONY: install
-install: all install-readmes install-configs $(HOTPLUGS)
+install: all install-docs install-configs $(HOTPLUGS)

-.PHONY: install-readmes
-install-readmes:
+.PHONY: install-docs
+install-docs:
      [ -d $(DESTDIR)$(XEN_CONFIG_DIR) ] || \
          $(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)
-    set -e; for i in $(XEN_READMES); \
-        do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/$$i ] || \
-        $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR); \
+    [ -d $(DESTDIR)$(XEN_CONFIG_DIR)/docs ] || \
+        $(INSTALL_DIR) $(DESTDIR)$(XEN_CONFIG_DIR)/docs
+    set -e; for i in $(XEN_DOCS); \
+        do [ -e $(DESTDIR)$(XEN_CONFIG_DIR)/docs/$$i ] || \
+        $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_CONFIG_DIR)/docs/; \
      done

  .PHONY: install-configs

--------------080809040108010600030708
Content-Type: text/plain;
 name="move_readmes_and_example_to_subdir_docs.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="move_readmes_and_example_to_subdir_docs.patch"

dG9vbHMvZXhhbXBsZXM6IE1vdmUgcmVhZG1lcyBhbmQgZXhhbXBsZXMgdG8gc3ViZGlyZWN0
b3J5IGRvY3MKClNpZ25lZC1vZmYtYnk6IEZhYmlvIEZhbnRvbmkgPGZhYmlvLmZhbnRvbmlA
aGVsaW1hbi5pdD4KCmRpZmYgLS1naXQgYS90b29scy9leGFtcGxlcy9NYWtlZmlsZSBiL3Rv
b2xzL2V4YW1wbGVzL01ha2VmaWxlCmluZGV4IDhjZWE3MjQuLmJlNzE4NzIgMTAwNjQ0Ci0t
LSBhL3Rvb2xzL2V4YW1wbGVzL01ha2VmaWxlCisrKyBiL3Rvb2xzL2V4YW1wbGVzL01ha2Vm
aWxlCkBAIC03LDIwICs3LDIwIEBAIFhFTkRPTUFJTlNfSU5JVEQgPSBpbml0LmQveGVuZG9t
YWlucwogWEVORE9NQUlOU19TWVNDT05GSUcgPSBpbml0LmQvc3lzY29uZmlnLnhlbmRvbWFp
bnMKIAogIyBYZW4gY29uZmlndXJhdGlvbiBkaXIgYW5kIGNvbmZpZ3MgdG8gZ28gdGhlcmUu
Ci1YRU5fUkVBRE1FUyA9IFJFQURNRQotWEVOX1JFQURNRVMgKz0gUkVBRE1FLmluY29tcGF0
aWJpbGl0aWVzCitYRU5fRE9DUyA9IFJFQURNRQorWEVOX0RPQ1MgKz0gUkVBRE1FLmluY29t
cGF0aWJpbGl0aWVzCiBYRU5fQ09ORklHUyA9IHhlbmQtY29uZmlnLnN4cAogWEVOX0NPTkZJ
R1MgKz0geG0tY29uZmlnLnhtbAotWEVOX0NPTkZJR1MgKz0geG1leGFtcGxlMSAKLVhFTl9D
T05GSUdTICs9IHhtZXhhbXBsZTIKLVhFTl9DT05GSUdTICs9IHhtZXhhbXBsZTMKLVhFTl9D
T05GSUdTICs9IHhtZXhhbXBsZS5odm0KLVhFTl9DT05GSUdTICs9IHhtZXhhbXBsZS5odm0t
c3R1YmRvbQotWEVOX0NPTkZJR1MgKz0geG1leGFtcGxlLnB2LWdydWIKLVhFTl9DT05GSUdT
ICs9IHhtZXhhbXBsZS5uYmQKLVhFTl9DT05GSUdTICs9IHhtZXhhbXBsZS52dGkKLVhFTl9D
T05GSUdTICs9IHhsZXhhbXBsZS5odm0KLVhFTl9DT05GSUdTICs9IHhsZXhhbXBsZS5wdmxp
bnV4CitYRU5fRE9DUyArPSB4bWV4YW1wbGUxIAorWEVOX0RPQ1MgKz0geG1leGFtcGxlMgor
WEVOX0RPQ1MgKz0geG1leGFtcGxlMworWEVOX0RPQ1MgKz0geG1leGFtcGxlLmh2bQorWEVO
X0RPQ1MgKz0geG1leGFtcGxlLmh2bS1zdHViZG9tCitYRU5fRE9DUyArPSB4bWV4YW1wbGUu
cHYtZ3J1YgorWEVOX0RPQ1MgKz0geG1leGFtcGxlLm5iZAorWEVOX0RPQ1MgKz0geG1leGFt
cGxlLnZ0aQorWEVOX0RPQ1MgKz0geGxleGFtcGxlLmh2bQorWEVOX0RPQ1MgKz0geGxleGFt
cGxlLnB2bGludXgKIFhFTl9DT05GSUdTICs9IHhlbmQtcGNpLXF1aXJrcy5zeHAKIFhFTl9D
T05GSUdTICs9IHhlbmQtcGNpLXBlcm1pc3NpdmUuc3hwCiBYRU5fQ09ORklHUyArPSB4bC5j
b25mCkBAIC0zMywxNSArMzMsMTcgQEAgYWxsOgogYnVpbGQ6CiAKIC5QSE9OWTogaW5zdGFs
bAotaW5zdGFsbDogYWxsIGluc3RhbGwtcmVhZG1lcyBpbnN0YWxsLWNvbmZpZ3MgJChIT1RQ
TFVHUykKK2luc3RhbGw6IGFsbCBpbnN0YWxsLWRvY3MgaW5zdGFsbC1jb25maWdzICQoSE9U
UExVR1MpCiAKLS5QSE9OWTogaW5zdGFsbC1yZWFkbWVzCi1pbnN0YWxsLXJlYWRtZXM6Cisu
UEhPTlk6IGluc3RhbGwtZG9jcworaW5zdGFsbC1kb2NzOgogCVsgLWQgJChERVNURElSKSQo
WEVOX0NPTkZJR19ESVIpIF0gfHwgXAogCQkkKElOU1RBTExfRElSKSAkKERFU1RESVIpJChY
RU5fQ09ORklHX0RJUikKLQlzZXQgLWU7IGZvciBpIGluICQoWEVOX1JFQURNRVMpOyBcCi0J
ICAgIGRvIFsgLWUgJChERVNURElSKSQoWEVOX0NPTkZJR19ESVIpLyQkaSBdIHx8IFwKLQkg
ICAgJChJTlNUQUxMX0RBVEEpICQkaSAkKERFU1RESVIpJChYRU5fQ09ORklHX0RJUik7IFwK
KwlbIC1kICQoREVTVERJUikkKFhFTl9DT05GSUdfRElSKS9kb2NzIF0gfHwgXAorCQkkKElO
U1RBTExfRElSKSAkKERFU1RESVIpJChYRU5fQ09ORklHX0RJUikvZG9jcworCXNldCAtZTsg
Zm9yIGkgaW4gJChYRU5fRE9DUyk7IFwKKwkgICAgZG8gWyAtZSAkKERFU1RESVIpJChYRU5f
Q09ORklHX0RJUikvZG9jcy8kJGkgXSB8fCBcCisJICAgICQoSU5TVEFMTF9EQVRBKSAkJGkg
JChERVNURElSKSQoWEVOX0NPTkZJR19ESVIpL2RvY3MvOyBcCiAJZG9uZQogCiAuUEhPTlk6
IGluc3RhbGwtY29uZmlncwog
--------------080809040108010600030708--

--------------ms070201030906050506040908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuDCC
Bs4wggW2oAMCAQICAgYuMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwHhcNMTAwMzE1MDEzNjEyWhcNMTIwMzE1MTgyMDI0WjCBwjEgMB4GA1UE
DRMXMTYzNjM4LU1SaENTbDhEM1BCVDVpRkQxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdCZXJn
YW1vMRAwDgYDVQQHEwdSb3ZldHRhMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxFjAUBgNVBAMTDUZhYmlvIEZhbnRvbmkxJjAkBgkqhkiG9w0BCQEW
F2ZhbnRvbmlmYWJpb0B0aXNjYWxpLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA77WvZhtp73ChfRf93cyCnb/kZtkekJf00AOSj4Rakj/Osadbbk4/5Oz85IZoTUMw6/Fk
wwqlWjcFTDmWF3AEB5wD7lddRkBYZ9VUCUdfUdlzHDOuarDf2V2hYgkVmErJLNYPmd8PdWuS
pknt9yvTdshVSQouyZwRo8HVA2k/RmLII/RZ2Mb7n8vKjnHzsx8OTyhesQvHKQSqcB5BylBN
dTcxkZcee5A7LP74lphcRMOXiHMZveYGjb0vKvw04+4fDp1vqY0GXZArHi4wTHHf3U3h4zGw
sVz4qEdtDgd5cNQq9ZCnENncmBnQnDbER86QVaiSrrtAYT76mxaJPLJ53wIDAQABo4IDADCC
AvwwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMB0GA1UdDgQWBBQ3WDZRCgKgMguGasRKY0STU5Op4DAfBgNVHSMEGDAWgBSuVYNv7DHK
ufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYW50b25pZmFiaW9AdGlzY2FsaS5pdDCCAUIG
A1UdIASCATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENv
bSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExp
bWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9s
aWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMG
A1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmww
K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh
c3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2Vy
dHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAk9f6iILWFDYsbUah0iASW6fCIvNya9Mq
hmcmCdthqCD0IpshjXsry6wiuZKHrX1jWXVriCnzBNROAvSMJRIon6nuGQSoItSe/6t92D7+
NTX2jAp/9ZAeljwoUMkeO7lodyK5qnbSNYjQ/SYN1OuULSAteg9LWkiI32HgledhHfiUcFAN
MOanv+qEJqVpEfTrrBZhKzO5eOZpjujUbkI48dBXrsEA4dgw/u9uqxUPtxYlA7XW/T9HEKwg
8OO/JNgyfkN6KrrjU4OI5/Xw1DJoNI8HY3lDAdkWMAP1sNpwZzcDI2Lo+jAKh9fKaHPlNaqC
pQhe/rTAzXazJIhTOwpTRTCCB+IwggXKoAMCAQICAQ4wDQYJKoZIhvcNAQEFBQAwfTELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YF
n7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2
acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzEl
VIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkz
UreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1sw
ggNXMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9r
MfPIHeOsuzCBqAYDVR0jBIGgMIGdgBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcw
AoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MGAGA1UdHwRZMFcwLKAqoCiG
Jmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCegJaAjhiFodHRwOi8v
Y3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQB
gbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlh
dGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkg
THRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs
IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBk
ZjARBglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIg
UHJpbWFyeSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqG
SIb3DQEBBQUAA4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J
40UBXsw9DKU8TylE4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1G
YTJ+hPiBEv0HmHnDxjhnJIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw
40K+r3N4lykySQNp2ElIJ8H1z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcp
DExcGlefweQs7+DYUK3spiQkJpN7qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHp
OUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJ
ul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHK
SboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9tsi77oT4AgZry0/6lgX56ak+f/umQihN
PgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDHjXoUAD03DUMEbKsWvqFB7nJNVesn
gbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bKqnkvpTGCA80wggPJAgEBMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMAkGBSsOAwIaBQCgggIO
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyODE0MDMx
NFowIwYJKoZIhvcNAQkEMRYEFHLWWjqD5SlLbR14i/ji+q2pl6+YMF8GCSqGSIb3DQEJDzFS
MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMIGmBgsqhkiG9w0BCRACCzGBlqCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGLjANBgkqhkiG9w0BAQEF
AASCAQBmLf13JUJJ5vSElFjKbdnvBa0K3Dy+im8Q3C00dtNz+DcUJ7L2PDQcazBkhxjxcylx
DEBc1ldd7bLA8GCOz/+U82gUucs1Rrzqc1ojChxeCi7WBzQ61Oapv16c9nPb+KuCFRL1ArP1
3xMXAmgb4XJU0zeuHkaBRAUee8lo4epTT/QQ0R2RYkOX7092xW0vmftgOpLNS9krj76EcpPm
5UWZj9Kih+0N5VgxrI80gcjb8zISYrti5vjO+H7s4YmlVh2IY25r/XEpwu9LRJKcmG9Elxfk
//afPGhjqWcGHg9kr0SeDY35vd9uhfPTzQKypteLMrgvoWK/GpxD5EyYTleCAAAAAAAA
--------------ms070201030906050506040908--


--===============8030474553492293441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8030474553492293441==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 14:15:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Npd-0004mW-Vz; Tue, 28 Feb 2012 14:15: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 1S2Npc-0004mR-7c
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:15:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330438455!62077745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17383 invoked from network); 28 Feb 2012 14:14:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:14:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10984284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 14:15:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 14:15:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2NpV-00089X-NO;
	Tue, 28 Feb 2012 14:15:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2NpV-0001zC-Ko;
	Tue, 28 Feb 2012 14:15:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12104-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 14:15:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12104: 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 12104 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12104/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12099

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12099
 test-i386-i386-win           14 guest-start.2                fail   like 12099

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-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
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12099 never pass

version targeted for testing:
 xen                  a7bacdc5449a
baseline version:
 xen                  a7bacdc5449a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:15:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Npd-0004mW-Vz; Tue, 28 Feb 2012 14:15: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 1S2Npc-0004mR-7c
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:15:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330438455!62077745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17383 invoked from network); 28 Feb 2012 14:14:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:14:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10984284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 14:15:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 14:15:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2NpV-00089X-NO;
	Tue, 28 Feb 2012 14:15:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2NpV-0001zC-Ko;
	Tue, 28 Feb 2012 14:15:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12104-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 14:15:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12104: 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 12104 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12104/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 12099

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12099
 test-i386-i386-win           14 guest-start.2                fail   like 12099

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-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
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 12099 never pass

version targeted for testing:
 xen                  a7bacdc5449a
baseline version:
 xen                  a7bacdc5449a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:21:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2Nv2-0004yg-T7; Tue, 28 Feb 2012 14:20:44 +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 1S2Nv1-0004ya-Nh
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:20:44 +0000
Received: from [85.158.139.83:34675] by server-11.bemta-5.messagelabs.com id
	71/6B-14397-AB2EC4F4; Tue, 28 Feb 2012 14:20:42 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330438839!16414972!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22714 invoked from network); 28 Feb 2012 14:20:41 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	VA3EHSOBE002.bigfish.com) (216.32.180.14)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Feb 2012 14:20:41 -0000
Received: from mail108-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 14:20:38 +0000
Received: from mail108-va3 (localhost [127.0.0.1])	by
	mail108-va3-R.bigfish.com (Postfix) with ESMTP id 12DEB202C8;
	Tue, 28 Feb 2012 14:20:39 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail108-va3 (localhost.localdomain [127.0.0.1]) by mail108-va3
	(MessageSwitch) id 1330438837825527_16639;
	Tue, 28 Feb 2012 14:20:37 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.251])	by
	mail108-va3.bigfish.com (Postfix) with ESMTP id C4911A0088;
	Tue, 28 Feb 2012 14:20:37 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 14:20:32 +0000
X-WSS-ID: 0M03X64-01-NQ5-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 2E1E510281D0;	Tue, 28 Feb 2012 08:20:28 -0600 (CST)
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, 28 Feb 2012 08:20:37 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 28 Feb 2012 08:20:28 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012
	09:20:26 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BD84149C65B; Tue, 28 Feb 2012
	14:20:25 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A29B05940FF; Tue, 28 Feb 2012
	15:20:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 928b131ba6558387e546725fa955996434171a95
Message-ID: <928b131ba6558387e546.1330438919@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 28 Feb 2012 15:21:59 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>, <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: Introduce a new lock for event and
	ppr logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1330438725 -3600
# Node ID 928b131ba6558387e546725fa955996434171a95
# Parent  a43eeaedf61ccaf269d0823ea80d3dfa8157cc63
amd iommu: Introduce a new lock for event and ppr logging

iommu->lock is used with irq disabled, so it cannot be used to protect ppr log.
Otherwise, after c/s 24770, get_gfn will trigger a BUG() if called by
parse_ppr_log_entry(). This patch adds an additional lock to protect ppr and
event pointers in iommu_read_log().

signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r a43eeaedf61c -r 928b131ba655 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Feb 28 10:17:27 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Feb 28 15:18:45 2012 +0100
@@ -367,6 +367,8 @@ static int iommu_read_log(struct amd_iom
     u32 tail, head, *entry, tail_offest, head_offset;
 
     BUG_ON(!iommu || ((log != &iommu->event_log) && (log != &iommu->ppr_log)));
+    
+    spin_lock(&log->lock);
 
     /* make sure there's an entry in the log */
     tail_offest = ( log == &iommu->event_log ) ?
@@ -396,6 +398,8 @@ static int iommu_read_log(struct amd_iom
         writel(head, iommu->mmio_base + head_offset);
     }
 
+    spin_unlock(&log->lock);
+   
     return 0;
 }
 
@@ -618,11 +622,11 @@ static void iommu_check_event_log(struct
     u32 entry;
     unsigned long flags;
 
-    spin_lock_irqsave(&iommu->lock, flags);
-
     iommu_read_log(iommu, &iommu->event_log,
                    sizeof(event_entry_t), parse_event_log_entry);
 
+    spin_lock_irqsave(&iommu->lock, flags);
+    
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
@@ -651,14 +655,10 @@ void parse_ppr_log_entry(struct amd_iomm
     bus = PCI_BUS(device_id);
     devfn = PCI_DEVFN2(device_id);
 
-    local_irq_enable();
-
     spin_lock(&pcidevs_lock);
     pdev = pci_get_pdev(iommu->seg, bus, devfn);
     spin_unlock(&pcidevs_lock);
 
-    local_irq_disable();
-
     if ( pdev == NULL )
         return;
 
@@ -672,10 +672,10 @@ static void iommu_check_ppr_log(struct a
     u32 entry;
     unsigned long flags;
 
-    spin_lock_irqsave(&iommu->lock, flags);
-
     iommu_read_log(iommu, &iommu->ppr_log,
                    sizeof(ppr_entry_t), parse_ppr_log_entry);
+    
+    spin_lock_irqsave(&iommu->lock, flags);
 
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
@@ -852,6 +852,8 @@ static void * __init allocate_ring_buffe
     ring_buf->head = 0;
     ring_buf->tail = 0;
 
+    spin_lock_init(&ring_buf->lock);
+    
     ring_buf->alloc_size = PAGE_SIZE << get_order_from_bytes(entries *
                                                              entry_size);
     ring_buf->entries = ring_buf->alloc_size / entry_size;
diff -r a43eeaedf61c -r 928b131ba655 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Feb 28 10:17:27 2012 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Feb 28 15:18:45 2012 +0100
@@ -65,6 +65,7 @@ struct ring_buffer {
     unsigned long alloc_size;
     uint32_t tail;
     uint32_t head;
+    spinlock_t lock;    /* protect buffer pointers */
 };
 
 typedef struct iommu_cap {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:21:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2Nv2-0004yg-T7; Tue, 28 Feb 2012 14:20:44 +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 1S2Nv1-0004ya-Nh
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:20:44 +0000
Received: from [85.158.139.83:34675] by server-11.bemta-5.messagelabs.com id
	71/6B-14397-AB2EC4F4; Tue, 28 Feb 2012 14:20:42 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330438839!16414972!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22714 invoked from network); 28 Feb 2012 14:20:41 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	VA3EHSOBE002.bigfish.com) (216.32.180.14)
	by server-9.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Feb 2012 14:20:41 -0000
Received: from mail108-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 14:20:38 +0000
Received: from mail108-va3 (localhost [127.0.0.1])	by
	mail108-va3-R.bigfish.com (Postfix) with ESMTP id 12DEB202C8;
	Tue, 28 Feb 2012 14:20:39 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail108-va3 (localhost.localdomain [127.0.0.1]) by mail108-va3
	(MessageSwitch) id 1330438837825527_16639;
	Tue, 28 Feb 2012 14:20:37 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.251])	by
	mail108-va3.bigfish.com (Postfix) with ESMTP id C4911A0088;
	Tue, 28 Feb 2012 14:20:37 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 14:20:32 +0000
X-WSS-ID: 0M03X64-01-NQ5-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 2E1E510281D0;	Tue, 28 Feb 2012 08:20:28 -0600 (CST)
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, 28 Feb 2012 08:20:37 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 28 Feb 2012 08:20:28 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012
	09:20:26 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BD84149C65B; Tue, 28 Feb 2012
	14:20:25 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id A29B05940FF; Tue, 28 Feb 2012
	15:20:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 928b131ba6558387e546725fa955996434171a95
Message-ID: <928b131ba6558387e546.1330438919@gran.amd.com>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Tue, 28 Feb 2012 15:21:59 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>, <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: Introduce a new lock for event and
	ppr logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1330438725 -3600
# Node ID 928b131ba6558387e546725fa955996434171a95
# Parent  a43eeaedf61ccaf269d0823ea80d3dfa8157cc63
amd iommu: Introduce a new lock for event and ppr logging

iommu->lock is used with irq disabled, so it cannot be used to protect ppr log.
Otherwise, after c/s 24770, get_gfn will trigger a BUG() if called by
parse_ppr_log_entry(). This patch adds an additional lock to protect ppr and
event pointers in iommu_read_log().

signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r a43eeaedf61c -r 928b131ba655 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Feb 28 10:17:27 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Feb 28 15:18:45 2012 +0100
@@ -367,6 +367,8 @@ static int iommu_read_log(struct amd_iom
     u32 tail, head, *entry, tail_offest, head_offset;
 
     BUG_ON(!iommu || ((log != &iommu->event_log) && (log != &iommu->ppr_log)));
+    
+    spin_lock(&log->lock);
 
     /* make sure there's an entry in the log */
     tail_offest = ( log == &iommu->event_log ) ?
@@ -396,6 +398,8 @@ static int iommu_read_log(struct amd_iom
         writel(head, iommu->mmio_base + head_offset);
     }
 
+    spin_unlock(&log->lock);
+   
     return 0;
 }
 
@@ -618,11 +622,11 @@ static void iommu_check_event_log(struct
     u32 entry;
     unsigned long flags;
 
-    spin_lock_irqsave(&iommu->lock, flags);
-
     iommu_read_log(iommu, &iommu->event_log,
                    sizeof(event_entry_t), parse_event_log_entry);
 
+    spin_lock_irqsave(&iommu->lock, flags);
+    
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
 
@@ -651,14 +655,10 @@ void parse_ppr_log_entry(struct amd_iomm
     bus = PCI_BUS(device_id);
     devfn = PCI_DEVFN2(device_id);
 
-    local_irq_enable();
-
     spin_lock(&pcidevs_lock);
     pdev = pci_get_pdev(iommu->seg, bus, devfn);
     spin_unlock(&pcidevs_lock);
 
-    local_irq_disable();
-
     if ( pdev == NULL )
         return;
 
@@ -672,10 +672,10 @@ static void iommu_check_ppr_log(struct a
     u32 entry;
     unsigned long flags;
 
-    spin_lock_irqsave(&iommu->lock, flags);
-
     iommu_read_log(iommu, &iommu->ppr_log,
                    sizeof(ppr_entry_t), parse_ppr_log_entry);
+    
+    spin_lock_irqsave(&iommu->lock, flags);
 
     /*check event overflow */
     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
@@ -852,6 +852,8 @@ static void * __init allocate_ring_buffe
     ring_buf->head = 0;
     ring_buf->tail = 0;
 
+    spin_lock_init(&ring_buf->lock);
+    
     ring_buf->alloc_size = PAGE_SIZE << get_order_from_bytes(entries *
                                                              entry_size);
     ring_buf->entries = ring_buf->alloc_size / entry_size;
diff -r a43eeaedf61c -r 928b131ba655 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Feb 28 10:17:27 2012 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Feb 28 15:18:45 2012 +0100
@@ -65,6 +65,7 @@ struct ring_buffer {
     unsigned long alloc_size;
     uint32_t tail;
     uint32_t head;
+    spinlock_t lock;    /* protect buffer pointers */
 };
 
 typedef struct iommu_cap {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2O2H-00058m-PP; Tue, 28 Feb 2012 14:28:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2O2G-00058h-H9
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:28:12 +0000
Received: from [85.158.139.83:37354] by server-9.bemta-5.messagelabs.com id
	D4/95-09826-B74EC4F4; Tue, 28 Feb 2012 14:28:11 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330439290!13127674!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4898 invoked from network); 28 Feb 2012 14:28:10 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 14:28:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 4E24C400612
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:28:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GksQT0qRhDac for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:28:09 +0100 (CET)
Received: from [192.168.178.50]
	(host239-90-dynamic.11-79-r.retail.telecomitalia.it [79.11.90.239])
	(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 E10A240021F
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:28:08 +0100 (CET)
Message-ID: <4F4CE476.9060905@tiscali.it>
Date: Tue, 28 Feb 2012 15:28:06 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Add optionals build configs for qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0915041708255452105=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============0915041708255452105==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070606090302080206010403"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070606090302080206010403
Content-Type: multipart/mixed;
 boundary="------------050200000209070802060602"

This is a multi-part message in MIME format.
--------------050200000209070802060602
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Add optionals build configs for qemu upstream:
CONFIG_QEMUU_DEBUG for enable debug, disabled by default
CONFIG_QEMUU_SPICE for enable spice, disabled by default for now
Add to README requirements for spice enabled

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff --git a/Config.mk b/Config.mk
index bc6be65..918aa7b 100644
--- a/Config.mk
+++ b/Config.mk
@@ -203,6 +203,8 @@ ETHERBOOT_NICS ?=3D rtl8139 8086100e
  CONFIG_OVMF ?=3D n
  CONFIG_ROMBIOS ?=3D y
  CONFIG_SEABIOS ?=3D y
+CONFIG_QEMUU_DEBUG ?=3D n
+CONFIG_QEMUU_SPICE ?=3D n

  # Specify which qemu-dm to use. This may be `ioemu' to use the old
  # Mercurial in-tree version, or a local directory, or a git URL.diff=20
--git a/README b/README
index b15a59b..fdb5e3a 100644
--- a/README
+++ b/README
@@ -60,6 +60,8 @@ provided by your OS distributor:
      * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 &=20
bcc debs)
      * ACPI ASL compiler (iasl)
      * markdown
+    * if CONFIG_QEMUU_SPICE=3Dy Dev of spice protocol (e.g.=20
libspice-protocol-dev)
+      Dev of spice server (e.g. libspice-server-dev >=3D0.10)

  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.=20
Ifdiff --git a/tools/Makefile b/tools/Makefile
index 6430bfb..eceecb2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -87,6 +87,14 @@ IOEMU_CONFIGURE_CROSS ?=3D --cpu=3D$(XEN_TARGET_ARCH) =
\
               --interp-prefix=3D$(CROSS_SYS_ROOT)
  endif

+ifeq ($(CONFIG_QEMUU_DEBUG),y)
+QEMU_OPTIONAL_CONFIGS +=3D --enable-debug
+endif
+
+ifeq ($(CONFIG_QEMUU_SPICE),y)
+QEMU_OPTIONAL_CONFIGS +=3D --enable-spice
+endif
+
  QEMU_ROOT :=3D $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo=20
"$(CONFIG_QEMU)"; else echo .; fi)
  ifneq ($(QEMU_ROOT),.)
  export QEMU_ROOT
@@ -158,6 +166,7 @@ subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: =

qemu-xen-dir-find
          --disable-kvm \
          --python=3D$(PYTHON) \
          $(IOEMU_CONFIGURE_CROSS); \
+        $(QEMU_OPTIONAL_CONFIGS); \
      $(MAKE) install

  subdir-clean-qemu-xen-dir:

--------------050200000209070802060602
Content-Type: text/plain;
 name="add_qemu_optionals_build_config.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="add_qemu_optionals_build_config.patch"

QWRkIG9wdGlvbmFscyBidWlsZCBjb25maWdzIGZvciBxZW11IHVwc3RyZWFtOgpDT05GSUdf
UUVNVVVfREVCVUcgZm9yIGVuYWJsZSBkZWJ1ZywgZGlzYWJsZWQgYnkgZGVmYXVsdApDT05G
SUdfUUVNVVVfU1BJQ0UgZm9yIGVuYWJsZSBzcGljZSwgZGlzYWJsZWQgYnkgZGVmYXVsdCBm
b3Igbm93CkFkZCB0byBSRUFETUUgcmVxdWlyZW1lbnRzIGZvciBzcGljZSBlbmFibGVkCgpT
aWduZWQtb2ZmLWJ5OiBGYWJpbyBGYW50b25pIDxmYWJpby5mYW50b25pQGhlbGltYW4uaXQ+
CgpkaWZmIC0tZ2l0IGEvQ29uZmlnLm1rIGIvQ29uZmlnLm1rCmluZGV4IGJjNmJlNjUuLjkx
OGFhN2IgMTAwNjQ0Ci0tLSBhL0NvbmZpZy5taworKysgYi9Db25maWcubWsKQEAgLTIwMyw2
ICsyMDMsOCBAQCBFVEhFUkJPT1RfTklDUyA/PSBydGw4MTM5IDgwODYxMDBlCiBDT05GSUdf
T1ZNRiA/PSBuCiBDT05GSUdfUk9NQklPUyA/PSB5CiBDT05GSUdfU0VBQklPUyA/PSB5CitD
T05GSUdfUUVNVVVfREVCVUcgPz0gbgorQ09ORklHX1FFTVVVX1NQSUNFID89IG4KIAogIyBT
cGVjaWZ5IHdoaWNoIHFlbXUtZG0gdG8gdXNlLiBUaGlzIG1heSBiZSBgaW9lbXUnIHRvIHVz
ZSB0aGUgb2xkCiAjIE1lcmN1cmlhbCBpbi10cmVlIHZlcnNpb24sIG9yIGEgbG9jYWwgZGly
ZWN0b3J5LCBvciBhIGdpdCBVUkwuZGlmZiAtLWdpdCBhL1JFQURNRSBiL1JFQURNRQppbmRl
eCBiMTVhNTliLi5mZGI1ZTNhIDEwMDY0NAotLS0gYS9SRUFETUUKKysrIGIvUkVBRE1FCkBA
IC02MCw2ICs2MCw4IEBAIHByb3ZpZGVkIGJ5IHlvdXIgT1MgZGlzdHJpYnV0b3I6CiAgICAg
KiAxNi1iaXQgeDg2IGFzc2VtYmxlciwgbG9hZGVyIGFuZCBjb21waWxlciAoZGV2ODYgcnBt
IG9yIGJpbjg2ICYgYmNjIGRlYnMpCiAgICAgKiBBQ1BJIEFTTCBjb21waWxlciAoaWFzbCkK
ICAgICAqIG1hcmtkb3duCisgICAgKiBpZiBDT05GSUdfUUVNVVVfU1BJQ0U9eSBEZXYgb2Yg
c3BpY2UgcHJvdG9jb2wgKGUuZy4gbGlic3BpY2UtcHJvdG9jb2wtZGV2KQorICAgICAgRGV2
IG9mIHNwaWNlIHNlcnZlciAoZS5nLiBsaWJzcGljZS1zZXJ2ZXItZGV2ID49MC4xMCkKIAog
U2Vjb25kLCB5b3UgbmVlZCB0byBhY3F1aXJlIGEgc3VpdGFibGUga2VybmVsIGZvciB1c2Ug
aW4gZG9tYWluIDAuIElmCiBwb3NzaWJsZSB5b3Ugc2hvdWxkIHVzZSBhIGtlcm5lbCBwcm92
aWRlZCBieSB5b3VyIE9TIGRpc3RyaWJ1dG9yLiBJZmRpZmYgLS1naXQgYS90b29scy9NYWtl
ZmlsZSBiL3Rvb2xzL01ha2VmaWxlCmluZGV4IDY0MzBiZmIuLmVjZWVjYjIgMTAwNjQ0Ci0t
LSBhL3Rvb2xzL01ha2VmaWxlCisrKyBiL3Rvb2xzL01ha2VmaWxlCkBAIC04Nyw2ICs4Nywx
NCBAQCBJT0VNVV9DT05GSUdVUkVfQ1JPU1MgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gp
IFwKIAkJCSAtLWludGVycC1wcmVmaXg9JChDUk9TU19TWVNfUk9PVCkKIGVuZGlmCiAKK2lm
ZXEgKCQoQ09ORklHX1FFTVVVX0RFQlVHKSx5KQorUUVNVV9PUFRJT05BTF9DT05GSUdTICs9
IC0tZW5hYmxlLWRlYnVnCitlbmRpZgorCitpZmVxICgkKENPTkZJR19RRU1VVV9TUElDRSks
eSkKK1FFTVVfT1BUSU9OQUxfQ09ORklHUyArPSAtLWVuYWJsZS1zcGljZQorZW5kaWYKKwog
UUVNVV9ST09UIDo9ICQoc2hlbGwgaWYgWyAtZCAiJChDT05GSUdfUUVNVSkiIF07IHRoZW4g
ZWNobyAiJChDT05GSUdfUUVNVSkiOyBlbHNlIGVjaG8gLjsgZmkpCiBpZm5lcSAoJChRRU1V
X1JPT1QpLC4pCiBleHBvcnQgUUVNVV9ST09UCkBAIC0xNTgsNiArMTY2LDcgQEAgc3ViZGly
LWFsbC1xZW11LXhlbi1kaXIgc3ViZGlyLWluc3RhbGwtcWVtdS14ZW4tZGlyOiBxZW11LXhl
bi1kaXItZmluZAogCQktLWRpc2FibGUta3ZtIFwKIAkJLS1weXRob249JChQWVRIT04pIFwK
IAkJJChJT0VNVV9DT05GSUdVUkVfQ1JPU1MpOyBcCisJCSQoUUVNVV9PUFRJT05BTF9DT05G
SUdTKTsgXAogCSQoTUFLRSkgaW5zdGFsbAogCiBzdWJkaXItY2xlYW4tcWVtdS14ZW4tZGly
Og==
--------------050200000209070802060602--

--------------ms070606090302080206010403
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuDCC
Bs4wggW2oAMCAQICAgYuMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwHhcNMTAwMzE1MDEzNjEyWhcNMTIwMzE1MTgyMDI0WjCBwjEgMB4GA1UE
DRMXMTYzNjM4LU1SaENTbDhEM1BCVDVpRkQxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdCZXJn
YW1vMRAwDgYDVQQHEwdSb3ZldHRhMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxFjAUBgNVBAMTDUZhYmlvIEZhbnRvbmkxJjAkBgkqhkiG9w0BCQEW
F2ZhbnRvbmlmYWJpb0B0aXNjYWxpLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA77WvZhtp73ChfRf93cyCnb/kZtkekJf00AOSj4Rakj/Osadbbk4/5Oz85IZoTUMw6/Fk
wwqlWjcFTDmWF3AEB5wD7lddRkBYZ9VUCUdfUdlzHDOuarDf2V2hYgkVmErJLNYPmd8PdWuS
pknt9yvTdshVSQouyZwRo8HVA2k/RmLII/RZ2Mb7n8vKjnHzsx8OTyhesQvHKQSqcB5BylBN
dTcxkZcee5A7LP74lphcRMOXiHMZveYGjb0vKvw04+4fDp1vqY0GXZArHi4wTHHf3U3h4zGw
sVz4qEdtDgd5cNQq9ZCnENncmBnQnDbER86QVaiSrrtAYT76mxaJPLJ53wIDAQABo4IDADCC
AvwwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMB0GA1UdDgQWBBQ3WDZRCgKgMguGasRKY0STU5Op4DAfBgNVHSMEGDAWgBSuVYNv7DHK
ufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYW50b25pZmFiaW9AdGlzY2FsaS5pdDCCAUIG
A1UdIASCATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENv
bSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExp
bWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9s
aWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMG
A1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmww
K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh
c3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2Vy
dHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAk9f6iILWFDYsbUah0iASW6fCIvNya9Mq
hmcmCdthqCD0IpshjXsry6wiuZKHrX1jWXVriCnzBNROAvSMJRIon6nuGQSoItSe/6t92D7+
NTX2jAp/9ZAeljwoUMkeO7lodyK5qnbSNYjQ/SYN1OuULSAteg9LWkiI32HgledhHfiUcFAN
MOanv+qEJqVpEfTrrBZhKzO5eOZpjujUbkI48dBXrsEA4dgw/u9uqxUPtxYlA7XW/T9HEKwg
8OO/JNgyfkN6KrrjU4OI5/Xw1DJoNI8HY3lDAdkWMAP1sNpwZzcDI2Lo+jAKh9fKaHPlNaqC
pQhe/rTAzXazJIhTOwpTRTCCB+IwggXKoAMCAQICAQ4wDQYJKoZIhvcNAQEFBQAwfTELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YF
n7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2
acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzEl
VIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkz
UreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1sw
ggNXMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9r
MfPIHeOsuzCBqAYDVR0jBIGgMIGdgBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcw
AoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MGAGA1UdHwRZMFcwLKAqoCiG
Jmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCegJaAjhiFodHRwOi8v
Y3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQB
gbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlh
dGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkg
THRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs
IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBk
ZjARBglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIg
UHJpbWFyeSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqG
SIb3DQEBBQUAA4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J
40UBXsw9DKU8TylE4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1G
YTJ+hPiBEv0HmHnDxjhnJIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw
40K+r3N4lykySQNp2ElIJ8H1z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcp
DExcGlefweQs7+DYUK3spiQkJpN7qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHp
OUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJ
ul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHK
SboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9tsi77oT4AgZry0/6lgX56ak+f/umQihN
PgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDHjXoUAD03DUMEbKsWvqFB7nJNVesn
gbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bKqnkvpTGCA80wggPJAgEBMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMAkGBSsOAwIaBQCgggIO
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyODE0Mjgw
NlowIwYJKoZIhvcNAQkEMRYEFOabijbyUHn4t9660UJs1lhxFIAjMF8GCSqGSIb3DQEJDzFS
MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMIGmBgsqhkiG9w0BCRACCzGBlqCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGLjANBgkqhkiG9w0BAQEF
AASCAQAfrohBmsHxC0SPuXmM22QSvDq49H2vP0LvFdiynhFHF6+ozoAX8eysjw+gL70DjcPv
zglXPZ776J57OaEbje/XrnWk4Q46/e/Ep2YkMmmSfvdih/QjpeCdYtIrW7vXIdHjlrsehNsX
C9QQEdPsIDwdLsi19KZ421D2y/4pp5vqNSKV0MMbUM8QLL4ZAIDCqLk76iAR2/3TRplV8S9L
RhjjBbdtIeN8DNSkhNO/R7cfrmrKz0MGBaztFqfXl7oP2QVx/+EI61RCWemUBYLkO++Y8MNf
cCSS27Fpt1G/Jx3yTFNc/urFZKFD/fp+Y9d05Bwm1DA5mpwpVOSjqCyWePQAAAAAAAAA
--------------ms070606090302080206010403--


--===============0915041708255452105==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0915041708255452105==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 14:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2O2H-00058m-PP; Tue, 28 Feb 2012 14:28:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2O2G-00058h-H9
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:28:12 +0000
Received: from [85.158.139.83:37354] by server-9.bemta-5.messagelabs.com id
	D4/95-09826-B74EC4F4; Tue, 28 Feb 2012 14:28:11 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330439290!13127674!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4898 invoked from network); 28 Feb 2012 14:28:10 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 14:28:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 4E24C400612
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:28:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GksQT0qRhDac for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:28:09 +0100 (CET)
Received: from [192.168.178.50]
	(host239-90-dynamic.11-79-r.retail.telecomitalia.it [79.11.90.239])
	(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 E10A240021F
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 15:28:08 +0100 (CET)
Message-ID: <4F4CE476.9060905@tiscali.it>
Date: Tue, 28 Feb 2012 15:28:06 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Add optionals build configs for qemu upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0915041708255452105=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============0915041708255452105==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070606090302080206010403"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070606090302080206010403
Content-Type: multipart/mixed;
 boundary="------------050200000209070802060602"

This is a multi-part message in MIME format.
--------------050200000209070802060602
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Add optionals build configs for qemu upstream:
CONFIG_QEMUU_DEBUG for enable debug, disabled by default
CONFIG_QEMUU_SPICE for enable spice, disabled by default for now
Add to README requirements for spice enabled

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff --git a/Config.mk b/Config.mk
index bc6be65..918aa7b 100644
--- a/Config.mk
+++ b/Config.mk
@@ -203,6 +203,8 @@ ETHERBOOT_NICS ?=3D rtl8139 8086100e
  CONFIG_OVMF ?=3D n
  CONFIG_ROMBIOS ?=3D y
  CONFIG_SEABIOS ?=3D y
+CONFIG_QEMUU_DEBUG ?=3D n
+CONFIG_QEMUU_SPICE ?=3D n

  # Specify which qemu-dm to use. This may be `ioemu' to use the old
  # Mercurial in-tree version, or a local directory, or a git URL.diff=20
--git a/README b/README
index b15a59b..fdb5e3a 100644
--- a/README
+++ b/README
@@ -60,6 +60,8 @@ provided by your OS distributor:
      * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 &=20
bcc debs)
      * ACPI ASL compiler (iasl)
      * markdown
+    * if CONFIG_QEMUU_SPICE=3Dy Dev of spice protocol (e.g.=20
libspice-protocol-dev)
+      Dev of spice server (e.g. libspice-server-dev >=3D0.10)

  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.=20
Ifdiff --git a/tools/Makefile b/tools/Makefile
index 6430bfb..eceecb2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -87,6 +87,14 @@ IOEMU_CONFIGURE_CROSS ?=3D --cpu=3D$(XEN_TARGET_ARCH) =
\
               --interp-prefix=3D$(CROSS_SYS_ROOT)
  endif

+ifeq ($(CONFIG_QEMUU_DEBUG),y)
+QEMU_OPTIONAL_CONFIGS +=3D --enable-debug
+endif
+
+ifeq ($(CONFIG_QEMUU_SPICE),y)
+QEMU_OPTIONAL_CONFIGS +=3D --enable-spice
+endif
+
  QEMU_ROOT :=3D $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo=20
"$(CONFIG_QEMU)"; else echo .; fi)
  ifneq ($(QEMU_ROOT),.)
  export QEMU_ROOT
@@ -158,6 +166,7 @@ subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: =

qemu-xen-dir-find
          --disable-kvm \
          --python=3D$(PYTHON) \
          $(IOEMU_CONFIGURE_CROSS); \
+        $(QEMU_OPTIONAL_CONFIGS); \
      $(MAKE) install

  subdir-clean-qemu-xen-dir:

--------------050200000209070802060602
Content-Type: text/plain;
 name="add_qemu_optionals_build_config.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="add_qemu_optionals_build_config.patch"

QWRkIG9wdGlvbmFscyBidWlsZCBjb25maWdzIGZvciBxZW11IHVwc3RyZWFtOgpDT05GSUdf
UUVNVVVfREVCVUcgZm9yIGVuYWJsZSBkZWJ1ZywgZGlzYWJsZWQgYnkgZGVmYXVsdApDT05G
SUdfUUVNVVVfU1BJQ0UgZm9yIGVuYWJsZSBzcGljZSwgZGlzYWJsZWQgYnkgZGVmYXVsdCBm
b3Igbm93CkFkZCB0byBSRUFETUUgcmVxdWlyZW1lbnRzIGZvciBzcGljZSBlbmFibGVkCgpT
aWduZWQtb2ZmLWJ5OiBGYWJpbyBGYW50b25pIDxmYWJpby5mYW50b25pQGhlbGltYW4uaXQ+
CgpkaWZmIC0tZ2l0IGEvQ29uZmlnLm1rIGIvQ29uZmlnLm1rCmluZGV4IGJjNmJlNjUuLjkx
OGFhN2IgMTAwNjQ0Ci0tLSBhL0NvbmZpZy5taworKysgYi9Db25maWcubWsKQEAgLTIwMyw2
ICsyMDMsOCBAQCBFVEhFUkJPT1RfTklDUyA/PSBydGw4MTM5IDgwODYxMDBlCiBDT05GSUdf
T1ZNRiA/PSBuCiBDT05GSUdfUk9NQklPUyA/PSB5CiBDT05GSUdfU0VBQklPUyA/PSB5CitD
T05GSUdfUUVNVVVfREVCVUcgPz0gbgorQ09ORklHX1FFTVVVX1NQSUNFID89IG4KIAogIyBT
cGVjaWZ5IHdoaWNoIHFlbXUtZG0gdG8gdXNlLiBUaGlzIG1heSBiZSBgaW9lbXUnIHRvIHVz
ZSB0aGUgb2xkCiAjIE1lcmN1cmlhbCBpbi10cmVlIHZlcnNpb24sIG9yIGEgbG9jYWwgZGly
ZWN0b3J5LCBvciBhIGdpdCBVUkwuZGlmZiAtLWdpdCBhL1JFQURNRSBiL1JFQURNRQppbmRl
eCBiMTVhNTliLi5mZGI1ZTNhIDEwMDY0NAotLS0gYS9SRUFETUUKKysrIGIvUkVBRE1FCkBA
IC02MCw2ICs2MCw4IEBAIHByb3ZpZGVkIGJ5IHlvdXIgT1MgZGlzdHJpYnV0b3I6CiAgICAg
KiAxNi1iaXQgeDg2IGFzc2VtYmxlciwgbG9hZGVyIGFuZCBjb21waWxlciAoZGV2ODYgcnBt
IG9yIGJpbjg2ICYgYmNjIGRlYnMpCiAgICAgKiBBQ1BJIEFTTCBjb21waWxlciAoaWFzbCkK
ICAgICAqIG1hcmtkb3duCisgICAgKiBpZiBDT05GSUdfUUVNVVVfU1BJQ0U9eSBEZXYgb2Yg
c3BpY2UgcHJvdG9jb2wgKGUuZy4gbGlic3BpY2UtcHJvdG9jb2wtZGV2KQorICAgICAgRGV2
IG9mIHNwaWNlIHNlcnZlciAoZS5nLiBsaWJzcGljZS1zZXJ2ZXItZGV2ID49MC4xMCkKIAog
U2Vjb25kLCB5b3UgbmVlZCB0byBhY3F1aXJlIGEgc3VpdGFibGUga2VybmVsIGZvciB1c2Ug
aW4gZG9tYWluIDAuIElmCiBwb3NzaWJsZSB5b3Ugc2hvdWxkIHVzZSBhIGtlcm5lbCBwcm92
aWRlZCBieSB5b3VyIE9TIGRpc3RyaWJ1dG9yLiBJZmRpZmYgLS1naXQgYS90b29scy9NYWtl
ZmlsZSBiL3Rvb2xzL01ha2VmaWxlCmluZGV4IDY0MzBiZmIuLmVjZWVjYjIgMTAwNjQ0Ci0t
LSBhL3Rvb2xzL01ha2VmaWxlCisrKyBiL3Rvb2xzL01ha2VmaWxlCkBAIC04Nyw2ICs4Nywx
NCBAQCBJT0VNVV9DT05GSUdVUkVfQ1JPU1MgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gp
IFwKIAkJCSAtLWludGVycC1wcmVmaXg9JChDUk9TU19TWVNfUk9PVCkKIGVuZGlmCiAKK2lm
ZXEgKCQoQ09ORklHX1FFTVVVX0RFQlVHKSx5KQorUUVNVV9PUFRJT05BTF9DT05GSUdTICs9
IC0tZW5hYmxlLWRlYnVnCitlbmRpZgorCitpZmVxICgkKENPTkZJR19RRU1VVV9TUElDRSks
eSkKK1FFTVVfT1BUSU9OQUxfQ09ORklHUyArPSAtLWVuYWJsZS1zcGljZQorZW5kaWYKKwog
UUVNVV9ST09UIDo9ICQoc2hlbGwgaWYgWyAtZCAiJChDT05GSUdfUUVNVSkiIF07IHRoZW4g
ZWNobyAiJChDT05GSUdfUUVNVSkiOyBlbHNlIGVjaG8gLjsgZmkpCiBpZm5lcSAoJChRRU1V
X1JPT1QpLC4pCiBleHBvcnQgUUVNVV9ST09UCkBAIC0xNTgsNiArMTY2LDcgQEAgc3ViZGly
LWFsbC1xZW11LXhlbi1kaXIgc3ViZGlyLWluc3RhbGwtcWVtdS14ZW4tZGlyOiBxZW11LXhl
bi1kaXItZmluZAogCQktLWRpc2FibGUta3ZtIFwKIAkJLS1weXRob249JChQWVRIT04pIFwK
IAkJJChJT0VNVV9DT05GSUdVUkVfQ1JPU1MpOyBcCisJCSQoUUVNVV9PUFRJT05BTF9DT05G
SUdTKTsgXAogCSQoTUFLRSkgaW5zdGFsbAogCiBzdWJkaXItY2xlYW4tcWVtdS14ZW4tZGly
Og==
--------------050200000209070802060602--

--------------ms070606090302080206010403
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuDCC
Bs4wggW2oAMCAQICAgYuMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwHhcNMTAwMzE1MDEzNjEyWhcNMTIwMzE1MTgyMDI0WjCBwjEgMB4GA1UE
DRMXMTYzNjM4LU1SaENTbDhEM1BCVDVpRkQxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdCZXJn
YW1vMRAwDgYDVQQHEwdSb3ZldHRhMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxFjAUBgNVBAMTDUZhYmlvIEZhbnRvbmkxJjAkBgkqhkiG9w0BCQEW
F2ZhbnRvbmlmYWJpb0B0aXNjYWxpLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA77WvZhtp73ChfRf93cyCnb/kZtkekJf00AOSj4Rakj/Osadbbk4/5Oz85IZoTUMw6/Fk
wwqlWjcFTDmWF3AEB5wD7lddRkBYZ9VUCUdfUdlzHDOuarDf2V2hYgkVmErJLNYPmd8PdWuS
pknt9yvTdshVSQouyZwRo8HVA2k/RmLII/RZ2Mb7n8vKjnHzsx8OTyhesQvHKQSqcB5BylBN
dTcxkZcee5A7LP74lphcRMOXiHMZveYGjb0vKvw04+4fDp1vqY0GXZArHi4wTHHf3U3h4zGw
sVz4qEdtDgd5cNQq9ZCnENncmBnQnDbER86QVaiSrrtAYT76mxaJPLJ53wIDAQABo4IDADCC
AvwwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMB0GA1UdDgQWBBQ3WDZRCgKgMguGasRKY0STU5Op4DAfBgNVHSMEGDAWgBSuVYNv7DHK
ufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYW50b25pZmFiaW9AdGlzY2FsaS5pdDCCAUIG
A1UdIASCATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENv
bSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExp
bWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9s
aWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMG
A1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmww
K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh
c3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2Vy
dHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAk9f6iILWFDYsbUah0iASW6fCIvNya9Mq
hmcmCdthqCD0IpshjXsry6wiuZKHrX1jWXVriCnzBNROAvSMJRIon6nuGQSoItSe/6t92D7+
NTX2jAp/9ZAeljwoUMkeO7lodyK5qnbSNYjQ/SYN1OuULSAteg9LWkiI32HgledhHfiUcFAN
MOanv+qEJqVpEfTrrBZhKzO5eOZpjujUbkI48dBXrsEA4dgw/u9uqxUPtxYlA7XW/T9HEKwg
8OO/JNgyfkN6KrrjU4OI5/Xw1DJoNI8HY3lDAdkWMAP1sNpwZzcDI2Lo+jAKh9fKaHPlNaqC
pQhe/rTAzXazJIhTOwpTRTCCB+IwggXKoAMCAQICAQ4wDQYJKoZIhvcNAQEFBQAwfTELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwxCzAJBgNV
BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YF
n7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2
acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzEl
VIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkz
UreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1sw
ggNXMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9r
MfPIHeOsuzCBqAYDVR0jBIGgMIGdgBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcw
AoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MGAGA1UdHwRZMFcwLKAqoCiG
Jmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCegJaAjhiFodHRwOi8v
Y3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQB
gbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlh
dGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkg
THRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs
IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBk
ZjARBglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIg
UHJpbWFyeSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqG
SIb3DQEBBQUAA4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J
40UBXsw9DKU8TylE4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1G
YTJ+hPiBEv0HmHnDxjhnJIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw
40K+r3N4lykySQNp2ElIJ8H1z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcp
DExcGlefweQs7+DYUK3spiQkJpN7qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHp
OUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJ
ul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHK
SboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9tsi77oT4AgZry0/6lgX56ak+f/umQihN
PgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDHjXoUAD03DUMEbKsWvqFB7nJNVesn
gbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bKqnkvpTGCA80wggPJAgEBMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMAkGBSsOAwIaBQCgggIO
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyODE0Mjgw
NlowIwYJKoZIhvcNAQkEMRYEFOabijbyUHn4t9660UJs1lhxFIAjMF8GCSqGSIb3DQEJDzFS
MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgYuMIGmBgsqhkiG9w0BCRACCzGBlqCB
kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGLjANBgkqhkiG9w0BAQEF
AASCAQAfrohBmsHxC0SPuXmM22QSvDq49H2vP0LvFdiynhFHF6+ozoAX8eysjw+gL70DjcPv
zglXPZ776J57OaEbje/XrnWk4Q46/e/Ep2YkMmmSfvdih/QjpeCdYtIrW7vXIdHjlrsehNsX
C9QQEdPsIDwdLsi19KZ421D2y/4pp5vqNSKV0MMbUM8QLL4ZAIDCqLk76iAR2/3TRplV8S9L
RhjjBbdtIeN8DNSkhNO/R7cfrmrKz0MGBaztFqfXl7oP2QVx/+EI61RCWemUBYLkO++Y8MNf
cCSS27Fpt1G/Jx3yTFNc/urFZKFD/fp+Y9d05Bwm1DA5mpwpVOSjqCyWePQAAAAAAAAA
--------------ms070606090302080206010403--


--===============0915041708255452105==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0915041708255452105==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 14:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2O7l-0005HZ-Jw; Tue, 28 Feb 2012 14:33:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1S2O7j-0005HS-Ma
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:33:52 +0000
Received: from [85.158.139.83:28643] by server-11.bemta-5.messagelabs.com id
	8F/33-14397-EC5EC4F4; Tue, 28 Feb 2012 14:33:50 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330439617!13128656!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23422 invoked from network); 28 Feb 2012 14:33:37 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 14:33:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=u9mAk+uE5nzYAa+h5RhPOSKq1jAX7
	s/DMt2+JQdBebc=; b=NH3YWsJjdszdXvc0h+MDR3eGTuasTMv+nShG9PEbGv6pX
	ifS7RDBnp00Pk4Mpd77iT/dhFTEbPzYaJ8P7ArA4bV1VtsGGBmYaEKxwnxnpYf+t
	PSlsHpx56XSmOtCMVFwoXbL7ljWh5SLw1IZVbELZ4B9m4K7hxLHxAO1B9jqje8=
Received: (qmail 9830 invoked from network); 28 Feb 2012 15:33:35 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.157.158)
	by mail.zeus06.de with ESMTPA; 28 Feb 2012 15:33:35 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 0960C2C5FD;
	Tue, 28 Feb 2012 15:35:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Z2k8O9ag+iFc; Tue, 28 Feb 2012 15:35:02 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id DE2BF2C5FC;
	Tue, 28 Feb 2012 15:35:02 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Tue, 28 Feb 2012 15:35:02 +0100
Mime-Version: 1.0
In-Reply-To: <20120217150759.GA29554@phenom.dumpdata.com>
References: <20120217150759.GA29554@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f4ce616.5763.747aa36d2ca6afc9@uhura.space.zz>
Cc: =?utf-8?Q?Sander_Eikel?= =?utf-8?Q?enboom?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1900018042941023838=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============1900018042941023838==
Content-Type: multipart/alternative; 
 boundary="=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well let me check for a longer period of time, and especially, whether th=
e DomU is still=0D=0A=0D=0Aworking (can do that only from at home), but l=
oad looks pretty well after applying the=0D=0A=0D=0Apatch to 3.2.8 :-D.=0D=
=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=
=BCngliche Nachricht-----=0D=0AAn:Jan Beulich <JBeulich@suse.com>;=20=0D=0A=
CC:Konrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel <xen-devel@lists.=
xensource.com>; Carsten Schiers <carsten@schiers.de>; Sander Eikelenboom =
<linux@eikelenboom.it>;=20=0D=0AVon:Konrad Rzeszutek Wilk <konrad.wilk@or=
acle.com>=0D=0AGesendet:Fr 17.02.2012 16:18=0D=0ABetreff:Re: [Xen-devel] =
Load increase after memory upgrade (part2)=0D=0AOn Thu, Feb 16, 2012 at 0=
8:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> On 15.02.12 at 20:28, Konr=
ad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:=0D=0A> >@@ -1550,7 +155=
2,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gf=
p_mask,=0D=0A> > struct page **pages;=0D=0A> > unsigned int nr_pages, arr=
ay_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) |=
 __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D gfp_mask & (__GFP_DMA =
| __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=0A> >+if (dma_mask =3D=
=3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I didn't spot where you f=
orce this normally invalid combination, without=0D=0A> which the change w=
on't affect vmalloc32() in a 32-bit kernel.=0D=0A>=20=0D=0A> >+gfp_mask &=
=3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gfp_mask &=3D ~(__GFP_DMA=
 | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0ADuh!=0D=0AGood eyes. Tha=
nks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=0A> > nr_pages =3D (=
area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > array_size =3D (nr_pages =
* sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=0D=0A______________=
_________________________________=0D=0AXen-devel mailing list=0D=0AXen-de=
vel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/xen-devel=0D=0A
--=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>Well let me check for a longer period of time, and especially, whether =
the DomU is still</p><p>working (can do that only from at home), but load=
 looks pretty well after applying the</p><p>patch to 3.2.8 :-D.</p><p>&nb=
sp;</p><p>BR,</p><p>Carsten.<br />&nbsp;</p><blockquote style=3D"border-l=
eft: 2px solid #325FBA; padding-left: 5px;margin-left:5px;">-----Urspr&uu=
ml;ngliche Nachricht-----<br /><strong>An:</strong>=09Jan Beulich &lt;JBe=
ulich@suse.com&gt;; <br /><strong>CC:</strong>=09Konrad Rzeszutek Wilk &l=
t;konrad@darnok.org&gt;; xen-devel &lt;xen-devel@lists.xensource.com&gt;;=
 Carsten Schiers &lt;carsten@schiers.de&gt;; Sander Eikelenboom &lt;linux=
@eikelenboom.it&gt;; <br /><strong>Von:</strong>=09Konrad Rzeszutek Wilk =
&lt;konrad.wilk@oracle.com&gt;<br /><strong>Gesendet:</strong>=09Fr 17.02=
=2E2012 16:18<br /><strong>Betreff:</strong>=09Re: [Xen-devel] Load incre=
ase after memory upgrade (part2)<br />On Thu, Feb 16, 2012 at 08:56:53AM =
+0000, Jan Beulich wrote:<br />&gt; &gt;&gt;&gt; On 15.02.12 at 20:28, Ko=
nrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt; wrote:<br />&gt; &gt;@=
@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *=
area, gfp_t gfp_mask,<br />&gt; &gt; =09struct page **pages;<br />&gt; &g=
t; =09unsigned int nr_pages, array_size, i;<br />&gt; &gt; =09gfp_t neste=
d_gfp =3D (gfp_mask &amp; GFP_RECLAIM_MASK) | __GFP_ZERO;<br />&gt; &gt;-=
<br />&gt; &gt;+=09gfp_t dma_mask =3D gfp_mask &amp; (__GFP_DMA | __GFP_D=
MA32);<br />&gt; &gt;+=09if (xen_pv_domain()) {<br />&gt; &gt;+=09=09if (=
dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))<br />&gt; <br />&gt; I didn&#3=
9;t spot where you force this normally invalid combination, without<br />=
&gt; which the change won&#39;t affect vmalloc32() in a 32-bit kernel.<br=
 />&gt; <br />&gt; &gt;+=09=09=09gfp_mask &amp;=3D (__GFP_DMA | __GFP_DMA=
32);<br />&gt; <br />&gt; =09=09=09gfp_mask &amp;=3D ~(__GFP_DMA | __GFP_=
DMA32);<br />&gt; <br />&gt; Jan<br /><br />Duh!<br />Good eyes. Thanks f=
or catching that.<br /><br />&gt; <br />&gt; &gt;+=09}<br />&gt; &gt; =09=
nr_pages =3D (area-&gt;size - PAGE_SIZE) &gt;&gt; PAGE_SHIFT;<br />&gt; &=
gt; =09array_size =3D (nr_pages * sizeof(struct page *));<br />&gt; &gt; =
<br />&gt; <br /><br />_______________________________________________<br=
 />Xen-devel mailing list<br />Xen-devel@lists.xensource.com<br />http://=
lists.xensource.com/xen-devel<br /></blockquote>=0A</body>=0A</html>
--=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG--



--===============1900018042941023838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1900018042941023838==--



From xen-devel-bounces@lists.xen.org Tue Feb 28 14:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2O7l-0005HZ-Jw; Tue, 28 Feb 2012 14:33:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1S2O7j-0005HS-Ma
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:33:52 +0000
Received: from [85.158.139.83:28643] by server-11.bemta-5.messagelabs.com id
	8F/33-14397-EC5EC4F4; Tue, 28 Feb 2012 14:33:50 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330439617!13128656!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23422 invoked from network); 28 Feb 2012 14:33:37 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 14:33:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=u9mAk+uE5nzYAa+h5RhPOSKq1jAX7
	s/DMt2+JQdBebc=; b=NH3YWsJjdszdXvc0h+MDR3eGTuasTMv+nShG9PEbGv6pX
	ifS7RDBnp00Pk4Mpd77iT/dhFTEbPzYaJ8P7ArA4bV1VtsGGBmYaEKxwnxnpYf+t
	PSlsHpx56XSmOtCMVFwoXbL7ljWh5SLw1IZVbELZ4B9m4K7hxLHxAO1B9jqje8=
Received: (qmail 9830 invoked from network); 28 Feb 2012 15:33:35 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.157.158)
	by mail.zeus06.de with ESMTPA; 28 Feb 2012 15:33:35 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 0960C2C5FD;
	Tue, 28 Feb 2012 15:35:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Z2k8O9ag+iFc; Tue, 28 Feb 2012 15:35:02 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id DE2BF2C5FC;
	Tue, 28 Feb 2012 15:35:02 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Tue, 28 Feb 2012 15:35:02 +0100
Mime-Version: 1.0
In-Reply-To: <20120217150759.GA29554@phenom.dumpdata.com>
References: <20120217150759.GA29554@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f4ce616.5763.747aa36d2ca6afc9@uhura.space.zz>
Cc: =?utf-8?Q?Sander_Eikel?= =?utf-8?Q?enboom?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1900018042941023838=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============1900018042941023838==
Content-Type: multipart/alternative; 
 boundary="=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well let me check for a longer period of time, and especially, whether th=
e DomU is still=0D=0A=0D=0Aworking (can do that only from at home), but l=
oad looks pretty well after applying the=0D=0A=0D=0Apatch to 3.2.8 :-D.=0D=
=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=
=BCngliche Nachricht-----=0D=0AAn:Jan Beulich <JBeulich@suse.com>;=20=0D=0A=
CC:Konrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel <xen-devel@lists.=
xensource.com>; Carsten Schiers <carsten@schiers.de>; Sander Eikelenboom =
<linux@eikelenboom.it>;=20=0D=0AVon:Konrad Rzeszutek Wilk <konrad.wilk@or=
acle.com>=0D=0AGesendet:Fr 17.02.2012 16:18=0D=0ABetreff:Re: [Xen-devel] =
Load increase after memory upgrade (part2)=0D=0AOn Thu, Feb 16, 2012 at 0=
8:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> On 15.02.12 at 20:28, Konr=
ad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:=0D=0A> >@@ -1550,7 +155=
2,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gf=
p_mask,=0D=0A> > struct page **pages;=0D=0A> > unsigned int nr_pages, arr=
ay_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) |=
 __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D gfp_mask & (__GFP_DMA =
| __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=0A> >+if (dma_mask =3D=
=3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I didn't spot where you f=
orce this normally invalid combination, without=0D=0A> which the change w=
on't affect vmalloc32() in a 32-bit kernel.=0D=0A>=20=0D=0A> >+gfp_mask &=
=3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gfp_mask &=3D ~(__GFP_DMA=
 | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0ADuh!=0D=0AGood eyes. Tha=
nks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=0A> > nr_pages =3D (=
area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > array_size =3D (nr_pages =
* sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=0D=0A______________=
_________________________________=0D=0AXen-devel mailing list=0D=0AXen-de=
vel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/xen-devel=0D=0A
--=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>Well let me check for a longer period of time, and especially, whether =
the DomU is still</p><p>working (can do that only from at home), but load=
 looks pretty well after applying the</p><p>patch to 3.2.8 :-D.</p><p>&nb=
sp;</p><p>BR,</p><p>Carsten.<br />&nbsp;</p><blockquote style=3D"border-l=
eft: 2px solid #325FBA; padding-left: 5px;margin-left:5px;">-----Urspr&uu=
ml;ngliche Nachricht-----<br /><strong>An:</strong>=09Jan Beulich &lt;JBe=
ulich@suse.com&gt;; <br /><strong>CC:</strong>=09Konrad Rzeszutek Wilk &l=
t;konrad@darnok.org&gt;; xen-devel &lt;xen-devel@lists.xensource.com&gt;;=
 Carsten Schiers &lt;carsten@schiers.de&gt;; Sander Eikelenboom &lt;linux=
@eikelenboom.it&gt;; <br /><strong>Von:</strong>=09Konrad Rzeszutek Wilk =
&lt;konrad.wilk@oracle.com&gt;<br /><strong>Gesendet:</strong>=09Fr 17.02=
=2E2012 16:18<br /><strong>Betreff:</strong>=09Re: [Xen-devel] Load incre=
ase after memory upgrade (part2)<br />On Thu, Feb 16, 2012 at 08:56:53AM =
+0000, Jan Beulich wrote:<br />&gt; &gt;&gt;&gt; On 15.02.12 at 20:28, Ko=
nrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt; wrote:<br />&gt; &gt;@=
@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *=
area, gfp_t gfp_mask,<br />&gt; &gt; =09struct page **pages;<br />&gt; &g=
t; =09unsigned int nr_pages, array_size, i;<br />&gt; &gt; =09gfp_t neste=
d_gfp =3D (gfp_mask &amp; GFP_RECLAIM_MASK) | __GFP_ZERO;<br />&gt; &gt;-=
<br />&gt; &gt;+=09gfp_t dma_mask =3D gfp_mask &amp; (__GFP_DMA | __GFP_D=
MA32);<br />&gt; &gt;+=09if (xen_pv_domain()) {<br />&gt; &gt;+=09=09if (=
dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))<br />&gt; <br />&gt; I didn&#3=
9;t spot where you force this normally invalid combination, without<br />=
&gt; which the change won&#39;t affect vmalloc32() in a 32-bit kernel.<br=
 />&gt; <br />&gt; &gt;+=09=09=09gfp_mask &amp;=3D (__GFP_DMA | __GFP_DMA=
32);<br />&gt; <br />&gt; =09=09=09gfp_mask &amp;=3D ~(__GFP_DMA | __GFP_=
DMA32);<br />&gt; <br />&gt; Jan<br /><br />Duh!<br />Good eyes. Thanks f=
or catching that.<br /><br />&gt; <br />&gt; &gt;+=09}<br />&gt; &gt; =09=
nr_pages =3D (area-&gt;size - PAGE_SIZE) &gt;&gt; PAGE_SHIFT;<br />&gt; &=
gt; =09array_size =3D (nr_pages * sizeof(struct page *));<br />&gt; &gt; =
<br />&gt; <br /><br />_______________________________________________<br=
 />Xen-devel mailing list<br />Xen-devel@lists.xensource.com<br />http://=
lists.xensource.com/xen-devel<br /></blockquote>=0A</body>=0A</html>
--=_moejqVqBTqpWyxsFKDF12xZofkJ2aLsa6Hz0GQ9oD1zXNEXG--



--===============1900018042941023838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1900018042941023838==--



From xen-devel-bounces@lists.xen.org Tue Feb 28 14:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2OBx-0005Rj-Dr; Tue, 28 Feb 2012 14:38:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2OBw-0005RV-GD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:38:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1330439886!16282037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18132 invoked from network); 28 Feb 2012 14:38:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:38:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10985105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 14:38:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 14:38:05 +0000
Message-ID: <1330439884.31269.184.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 28 Feb 2012 14:38:04 +0000
In-Reply-To: <4F4CE476.9060905@tiscali.it>
References: <4F4CE476.9060905@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add optionals build configs for qemu
 upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 14:28 +0000, Fabio Fantoni wrote:
> Add optionals build configs for qemu upstream:
> CONFIG_QEMUU_DEBUG for enable debug, disabled by default
> CONFIG_QEMUU_SPICE for enable spice, disabled by default for now
> Add to README requirements for spice enabled

I think only the latter is required, isn't it?

If a user's environment meets the requirements then they will get spice,
otherwise they will not.

Also your patch appears to have been w/s mangled.

> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff --git a/Config.mk b/Config.mk
> index bc6be65..918aa7b 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -203,6 +203,8 @@ ETHERBOOT_NICS ?= rtl8139 8086100e
>   CONFIG_OVMF ?= n
>   CONFIG_ROMBIOS ?= y
>   CONFIG_SEABIOS ?= y
> +CONFIG_QEMUU_DEBUG ?= n
> +CONFIG_QEMUU_SPICE ?= n
> 
>   # Specify which qemu-dm to use. This may be `ioemu' to use the old
>   # Mercurial in-tree version, or a local directory, or a git URL.diff 
> --git a/README b/README
> index b15a59b..fdb5e3a 100644
> --- a/README
> +++ b/README
> @@ -60,6 +60,8 @@ provided by your OS distributor:
>       * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & 
> bcc debs)
>       * ACPI ASL compiler (iasl)
>       * markdown
> +    * if CONFIG_QEMUU_SPICE=y Dev of spice protocol (e.g. 
> libspice-protocol-dev)
> +      Dev of spice server (e.g. libspice-server-dev >=0.10)
> 
>   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. 
> Ifdiff --git a/tools/Makefile b/tools/Makefile
> index 6430bfb..eceecb2 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -87,6 +87,14 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
>                --interp-prefix=$(CROSS_SYS_ROOT)
>   endif
> 
> +ifeq ($(CONFIG_QEMUU_DEBUG),y)
> +QEMU_OPTIONAL_CONFIGS += --enable-debug
> +endif
> +
> +ifeq ($(CONFIG_QEMUU_SPICE),y)
> +QEMU_OPTIONAL_CONFIGS += --enable-spice
> +endif
> +
>   QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo 
> "$(CONFIG_QEMU)"; else echo .; fi)
>   ifneq ($(QEMU_ROOT),.)
>   export QEMU_ROOT
> @@ -158,6 +166,7 @@ subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: 
> qemu-xen-dir-find
>           --disable-kvm \
>           --python=$(PYTHON) \
>           $(IOEMU_CONFIGURE_CROSS); \
> +        $(QEMU_OPTIONAL_CONFIGS); \
>       $(MAKE) install
> 
>   subdir-clean-qemu-xen-dir:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14: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 1S2OBx-0005Rj-Dr; Tue, 28 Feb 2012 14:38:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2OBw-0005RV-GD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:38:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1330439886!16282037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18132 invoked from network); 28 Feb 2012 14:38:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:38:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10985105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 14:38:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 14:38:05 +0000
Message-ID: <1330439884.31269.184.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 28 Feb 2012 14:38:04 +0000
In-Reply-To: <4F4CE476.9060905@tiscali.it>
References: <4F4CE476.9060905@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add optionals build configs for qemu
 upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 14:28 +0000, Fabio Fantoni wrote:
> Add optionals build configs for qemu upstream:
> CONFIG_QEMUU_DEBUG for enable debug, disabled by default
> CONFIG_QEMUU_SPICE for enable spice, disabled by default for now
> Add to README requirements for spice enabled

I think only the latter is required, isn't it?

If a user's environment meets the requirements then they will get spice,
otherwise they will not.

Also your patch appears to have been w/s mangled.

> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff --git a/Config.mk b/Config.mk
> index bc6be65..918aa7b 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -203,6 +203,8 @@ ETHERBOOT_NICS ?= rtl8139 8086100e
>   CONFIG_OVMF ?= n
>   CONFIG_ROMBIOS ?= y
>   CONFIG_SEABIOS ?= y
> +CONFIG_QEMUU_DEBUG ?= n
> +CONFIG_QEMUU_SPICE ?= n
> 
>   # Specify which qemu-dm to use. This may be `ioemu' to use the old
>   # Mercurial in-tree version, or a local directory, or a git URL.diff 
> --git a/README b/README
> index b15a59b..fdb5e3a 100644
> --- a/README
> +++ b/README
> @@ -60,6 +60,8 @@ provided by your OS distributor:
>       * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & 
> bcc debs)
>       * ACPI ASL compiler (iasl)
>       * markdown
> +    * if CONFIG_QEMUU_SPICE=y Dev of spice protocol (e.g. 
> libspice-protocol-dev)
> +      Dev of spice server (e.g. libspice-server-dev >=0.10)
> 
>   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. 
> Ifdiff --git a/tools/Makefile b/tools/Makefile
> index 6430bfb..eceecb2 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -87,6 +87,14 @@ IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
>                --interp-prefix=$(CROSS_SYS_ROOT)
>   endif
> 
> +ifeq ($(CONFIG_QEMUU_DEBUG),y)
> +QEMU_OPTIONAL_CONFIGS += --enable-debug
> +endif
> +
> +ifeq ($(CONFIG_QEMUU_SPICE),y)
> +QEMU_OPTIONAL_CONFIGS += --enable-spice
> +endif
> +
>   QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo 
> "$(CONFIG_QEMU)"; else echo .; fi)
>   ifneq ($(QEMU_ROOT),.)
>   export QEMU_ROOT
> @@ -158,6 +166,7 @@ subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: 
> qemu-xen-dir-find
>           --disable-kvm \
>           --python=$(PYTHON) \
>           $(IOEMU_CONFIGURE_CROSS); \
> +        $(QEMU_OPTIONAL_CONFIGS); \
>       $(MAKE) install
> 
>   subdir-clean-qemu-xen-dir:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:53:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:53:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OQR-0005iB-I6; Tue, 28 Feb 2012 14:53:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2OQP-0005hQ-Sy
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:53:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330440783!16226583!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9493 invoked from network); 28 Feb 2012 14:53:03 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:53:03 -0000
Received: by wgbds1 with SMTP id ds1so2356722wgb.0
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 06:53:03 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr10062057wia.3.1330440783455 (num_hops
	= 1); Tue, 28 Feb 2012 06:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=cyDQxCsONPpDphqFVgBLny8P+YUrXAog/hIhkbNg77o=;
	b=x2R63xUdQ6SGODVodH2bBjiIz7YXcuVnngL5j03dltp/DZwceWZiM4ZaG0t4BCqJn8
	pBAnYg+v9HiAHCLFCAySsDliZlPsbXC69hWfL2qPygiqNUy2e4Ovz7mgMD227+g8/LC2
	PdPkQwQ0JgJwMolnTQCVSdxAVZDpKQQkey1CE=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr7997087wia.3.1330440783388; Tue, 28
	Feb 2012 06:53:03 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Tue, 28 Feb 2012 06:53:03 -0800 (PST)
In-Reply-To: <4F4CE476.9060905@tiscali.it>
References: <4F4CE476.9060905@tiscali.it>
Date: Tue, 28 Feb 2012 15:53:03 +0100
X-Google-Sender-Auth: rMOxFeEYTeqQGLzDMh_MrRwRpEY
Message-ID: <CAPLaKK7cY6fe2_4mRqNX6s=ASu6fq5-wNN_pYfoietQJAFxT-Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: fantonifabio@tiscali.it
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add optionals build configs for qemu
	upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI4IEZhYmlvIEZhbnRvbmkgPGZhbnRvbmlmYWJpb0B0aXNjYWxpLml0PjoKPiBBZGQg
b3B0aW9uYWxzIGJ1aWxkIGNvbmZpZ3MgZm9yIHFlbXUgdXBzdHJlYW06Cj4gQ09ORklHX1FFTVVV
X0RFQlVHIGZvciBlbmFibGUgZGVidWcsIGRpc2FibGVkIGJ5IGRlZmF1bHQKPiBDT05GSUdfUUVN
VVVfU1BJQ0UgZm9yIGVuYWJsZSBzcGljZSwgZGlzYWJsZWQgYnkgZGVmYXVsdCBmb3Igbm93Cj4g
QWRkIHRvIFJFQURNRSByZXF1aXJlbWVudHMgZm9yIHNwaWNlIGVuYWJsZWQKPgo+IFNpZ25lZC1v
ZmYtYnk6IEZhYmlvIEZhbnRvbmkgPGZhYmlvLmZhbnRvbmlAaGVsaW1hbi5pdD4KPgo+IGRpZmYg
LS1naXQgYS9Db25maWcubWsgYi9Db25maWcubWsKPiBpbmRleCBiYzZiZTY1Li45MThhYTdiIDEw
MDY0NAo+IC0tLSBhL0NvbmZpZy5tawo+ICsrKyBiL0NvbmZpZy5tawo+IEBAIC0yMDMsNiArMjAz
LDggQEAgRVRIRVJCT09UX05JQ1MgPz0gcnRsODEzOSA4MDg2MTAwZQo+IMKgQ09ORklHX09WTUYg
Pz0gbgo+IMKgQ09ORklHX1JPTUJJT1MgPz0geQo+IMKgQ09ORklHX1NFQUJJT1MgPz0geQo+ICtD
T05GSUdfUUVNVVVfREVCVUcgPz0gbgo+ICtDT05GSUdfUUVNVVVfU1BJQ0UgPz0gbgoKSXQgd2ls
bCBiZSBuaWNlIHRvIGFkZCB0aGlzIGFzIGNvbmZpZ3VyZSBvcHRpb25zLCBzbyBhIHVzZXIgY2Fu
IHBhc3MKIi0tZW5hYmxlLXFlbXUtZGVidWciIG9yICItLWVuYWJsZS1xZW11LXNwaWNlIiB0byBj
b25maWd1cmUgYW5kIHRoZQpwcm9wZXIgZmxhZ3MgYXJlIHNldCBvbiB0aGUgZ2VuZXJhdGVkIGNv
bmZpZy9Ub29scy5tayBpbnN0ZWFkIG9mCnNldHRpbmcgdGhlbSBkaXJlY3RseSBvbiAuY29uZmln
IG9yIENvbmZpZy5tay4gVGhlcmUgYXJlIHNvbWUgZXhhbXBsZXMKb2YgdGhpcyBvbiB0b29scy9j
b25maWd1cmUuYWMuCgo+Cj4gwqAjIFNwZWNpZnkgd2hpY2ggcWVtdS1kbSB0byB1c2UuIFRoaXMg
bWF5IGJlIGBpb2VtdScgdG8gdXNlIHRoZSBvbGQKPiDCoCMgTWVyY3VyaWFsIGluLXRyZWUgdmVy
c2lvbiwgb3IgYSBsb2NhbCBkaXJlY3RvcnksIG9yIGEgZ2l0IFVSTC5kaWZmIC0tZ2l0Cj4gYS9S
RUFETUUgYi9SRUFETUUKPiBpbmRleCBiMTVhNTliLi5mZGI1ZTNhIDEwMDY0NAo+IC0tLSBhL1JF
QURNRQo+ICsrKyBiL1JFQURNRQo+IEBAIC02MCw2ICs2MCw4IEBAIHByb3ZpZGVkIGJ5IHlvdXIg
T1MgZGlzdHJpYnV0b3I6Cj4gwqAgwqAgKiAxNi1iaXQgeDg2IGFzc2VtYmxlciwgbG9hZGVyIGFu
ZCBjb21waWxlciAoZGV2ODYgcnBtIG9yIGJpbjg2ICYgYmNjCj4gZGVicykKPiDCoCDCoCAqIEFD
UEkgQVNMIGNvbXBpbGVyIChpYXNsKQo+IMKgIMKgICogbWFya2Rvd24KPiArIMKgIMKgKiBpZiBD
T05GSUdfUUVNVVVfU1BJQ0U9eSBEZXYgb2Ygc3BpY2UgcHJvdG9jb2wgKGUuZy4KPiBsaWJzcGlj
ZS1wcm90b2NvbC1kZXYpCj4gKyDCoCDCoCDCoERldiBvZiBzcGljZSBzZXJ2ZXIgKGUuZy4gbGli
c3BpY2Utc2VydmVyLWRldiA+PTAuMTApCj4KPiDCoFNlY29uZCwgeW91IG5lZWQgdG8gYWNxdWly
ZSBhIHN1aXRhYmxlIGtlcm5lbCBmb3IgdXNlIGluIGRvbWFpbiAwLiBJZgo+IMKgcG9zc2libGUg
eW91IHNob3VsZCB1c2UgYSBrZXJuZWwgcHJvdmlkZWQgYnkgeW91ciBPUyBkaXN0cmlidXRvci4g
SWZkaWZmCj4gLS1naXQgYS90b29scy9NYWtlZmlsZSBiL3Rvb2xzL01ha2VmaWxlCj4gaW5kZXgg
NjQzMGJmYi4uZWNlZWNiMiAxMDA2NDQKPiAtLS0gYS90b29scy9NYWtlZmlsZQo+ICsrKyBiL3Rv
b2xzL01ha2VmaWxlCj4gQEAgLTg3LDYgKzg3LDE0IEBAIElPRU1VX0NPTkZJR1VSRV9DUk9TUyA/
PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgLS1pbnRl
cnAtcHJlZml4PSQoQ1JPU1NfU1lTX1JPT1QpCj4gwqBlbmRpZgo+Cj4gK2lmZXEgKCQoQ09ORklH
X1FFTVVVX0RFQlVHKSx5KQo+ICtRRU1VX09QVElPTkFMX0NPTkZJR1MgKz0gLS1lbmFibGUtZGVi
dWcKPiArZW5kaWYKPiArCj4gK2lmZXEgKCQoQ09ORklHX1FFTVVVX1NQSUNFKSx5KQo+ICtRRU1V
X09QVElPTkFMX0NPTkZJR1MgKz0gLS1lbmFibGUtc3BpY2UKPiArZW5kaWYKPiArCj4gwqBRRU1V
X1JPT1QgOj0gJChzaGVsbCBpZiBbIC1kICIkKENPTkZJR19RRU1VKSIgXTsgdGhlbiBlY2hvCj4g
IiQoQ09ORklHX1FFTVUpIjsgZWxzZSBlY2hvIC47IGZpKQo+IMKgaWZuZXEgKCQoUUVNVV9ST09U
KSwuKQo+IMKgZXhwb3J0IFFFTVVfUk9PVAo+IEBAIC0xNTgsNiArMTY2LDcgQEAgc3ViZGlyLWFs
bC1xZW11LXhlbi1kaXIgc3ViZGlyLWluc3RhbGwtcWVtdS14ZW4tZGlyOgo+IHFlbXUteGVuLWRp
ci1maW5kCj4gwqAgwqAgwqAgwqAgLS1kaXNhYmxlLWt2bSBcCj4gwqAgwqAgwqAgwqAgLS1weXRo
b249JChQWVRIT04pIFwKPiDCoCDCoCDCoCDCoCAkKElPRU1VX0NPTkZJR1VSRV9DUk9TUyk7IFwK
PiArIMKgIMKgIMKgIMKgJChRRU1VX09QVElPTkFMX0NPTkZJR1MpOyBcCj4gwqAgwqAgJChNQUtF
KSBpbnN0YWxsCj4KPiDCoHN1YmRpci1jbGVhbi1xZW11LXhlbi1kaXI6Cj4KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:53:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:53:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OQR-0005iB-I6; Tue, 28 Feb 2012 14:53:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2OQP-0005hQ-Sy
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:53:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330440783!16226583!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9493 invoked from network); 28 Feb 2012 14:53:03 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:53:03 -0000
Received: by wgbds1 with SMTP id ds1so2356722wgb.0
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 06:53:03 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.7.231 as permitted sender) client-ip=10.180.7.231; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.7.231 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.7.231])
	by 10.180.7.231 with SMTP id m7mr10062057wia.3.1330440783455 (num_hops
	= 1); Tue, 28 Feb 2012 06:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=cyDQxCsONPpDphqFVgBLny8P+YUrXAog/hIhkbNg77o=;
	b=x2R63xUdQ6SGODVodH2bBjiIz7YXcuVnngL5j03dltp/DZwceWZiM4ZaG0t4BCqJn8
	pBAnYg+v9HiAHCLFCAySsDliZlPsbXC69hWfL2qPygiqNUy2e4Ovz7mgMD227+g8/LC2
	PdPkQwQ0JgJwMolnTQCVSdxAVZDpKQQkey1CE=
MIME-Version: 1.0
Received: by 10.180.7.231 with SMTP id m7mr7997087wia.3.1330440783388; Tue, 28
	Feb 2012 06:53:03 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Tue, 28 Feb 2012 06:53:03 -0800 (PST)
In-Reply-To: <4F4CE476.9060905@tiscali.it>
References: <4F4CE476.9060905@tiscali.it>
Date: Tue, 28 Feb 2012 15:53:03 +0100
X-Google-Sender-Auth: rMOxFeEYTeqQGLzDMh_MrRwRpEY
Message-ID: <CAPLaKK7cY6fe2_4mRqNX6s=ASu6fq5-wNN_pYfoietQJAFxT-Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: fantonifabio@tiscali.it
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add optionals build configs for qemu
	upstream
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI4IEZhYmlvIEZhbnRvbmkgPGZhbnRvbmlmYWJpb0B0aXNjYWxpLml0PjoKPiBBZGQg
b3B0aW9uYWxzIGJ1aWxkIGNvbmZpZ3MgZm9yIHFlbXUgdXBzdHJlYW06Cj4gQ09ORklHX1FFTVVV
X0RFQlVHIGZvciBlbmFibGUgZGVidWcsIGRpc2FibGVkIGJ5IGRlZmF1bHQKPiBDT05GSUdfUUVN
VVVfU1BJQ0UgZm9yIGVuYWJsZSBzcGljZSwgZGlzYWJsZWQgYnkgZGVmYXVsdCBmb3Igbm93Cj4g
QWRkIHRvIFJFQURNRSByZXF1aXJlbWVudHMgZm9yIHNwaWNlIGVuYWJsZWQKPgo+IFNpZ25lZC1v
ZmYtYnk6IEZhYmlvIEZhbnRvbmkgPGZhYmlvLmZhbnRvbmlAaGVsaW1hbi5pdD4KPgo+IGRpZmYg
LS1naXQgYS9Db25maWcubWsgYi9Db25maWcubWsKPiBpbmRleCBiYzZiZTY1Li45MThhYTdiIDEw
MDY0NAo+IC0tLSBhL0NvbmZpZy5tawo+ICsrKyBiL0NvbmZpZy5tawo+IEBAIC0yMDMsNiArMjAz
LDggQEAgRVRIRVJCT09UX05JQ1MgPz0gcnRsODEzOSA4MDg2MTAwZQo+IMKgQ09ORklHX09WTUYg
Pz0gbgo+IMKgQ09ORklHX1JPTUJJT1MgPz0geQo+IMKgQ09ORklHX1NFQUJJT1MgPz0geQo+ICtD
T05GSUdfUUVNVVVfREVCVUcgPz0gbgo+ICtDT05GSUdfUUVNVVVfU1BJQ0UgPz0gbgoKSXQgd2ls
bCBiZSBuaWNlIHRvIGFkZCB0aGlzIGFzIGNvbmZpZ3VyZSBvcHRpb25zLCBzbyBhIHVzZXIgY2Fu
IHBhc3MKIi0tZW5hYmxlLXFlbXUtZGVidWciIG9yICItLWVuYWJsZS1xZW11LXNwaWNlIiB0byBj
b25maWd1cmUgYW5kIHRoZQpwcm9wZXIgZmxhZ3MgYXJlIHNldCBvbiB0aGUgZ2VuZXJhdGVkIGNv
bmZpZy9Ub29scy5tayBpbnN0ZWFkIG9mCnNldHRpbmcgdGhlbSBkaXJlY3RseSBvbiAuY29uZmln
IG9yIENvbmZpZy5tay4gVGhlcmUgYXJlIHNvbWUgZXhhbXBsZXMKb2YgdGhpcyBvbiB0b29scy9j
b25maWd1cmUuYWMuCgo+Cj4gwqAjIFNwZWNpZnkgd2hpY2ggcWVtdS1kbSB0byB1c2UuIFRoaXMg
bWF5IGJlIGBpb2VtdScgdG8gdXNlIHRoZSBvbGQKPiDCoCMgTWVyY3VyaWFsIGluLXRyZWUgdmVy
c2lvbiwgb3IgYSBsb2NhbCBkaXJlY3RvcnksIG9yIGEgZ2l0IFVSTC5kaWZmIC0tZ2l0Cj4gYS9S
RUFETUUgYi9SRUFETUUKPiBpbmRleCBiMTVhNTliLi5mZGI1ZTNhIDEwMDY0NAo+IC0tLSBhL1JF
QURNRQo+ICsrKyBiL1JFQURNRQo+IEBAIC02MCw2ICs2MCw4IEBAIHByb3ZpZGVkIGJ5IHlvdXIg
T1MgZGlzdHJpYnV0b3I6Cj4gwqAgwqAgKiAxNi1iaXQgeDg2IGFzc2VtYmxlciwgbG9hZGVyIGFu
ZCBjb21waWxlciAoZGV2ODYgcnBtIG9yIGJpbjg2ICYgYmNjCj4gZGVicykKPiDCoCDCoCAqIEFD
UEkgQVNMIGNvbXBpbGVyIChpYXNsKQo+IMKgIMKgICogbWFya2Rvd24KPiArIMKgIMKgKiBpZiBD
T05GSUdfUUVNVVVfU1BJQ0U9eSBEZXYgb2Ygc3BpY2UgcHJvdG9jb2wgKGUuZy4KPiBsaWJzcGlj
ZS1wcm90b2NvbC1kZXYpCj4gKyDCoCDCoCDCoERldiBvZiBzcGljZSBzZXJ2ZXIgKGUuZy4gbGli
c3BpY2Utc2VydmVyLWRldiA+PTAuMTApCj4KPiDCoFNlY29uZCwgeW91IG5lZWQgdG8gYWNxdWly
ZSBhIHN1aXRhYmxlIGtlcm5lbCBmb3IgdXNlIGluIGRvbWFpbiAwLiBJZgo+IMKgcG9zc2libGUg
eW91IHNob3VsZCB1c2UgYSBrZXJuZWwgcHJvdmlkZWQgYnkgeW91ciBPUyBkaXN0cmlidXRvci4g
SWZkaWZmCj4gLS1naXQgYS90b29scy9NYWtlZmlsZSBiL3Rvb2xzL01ha2VmaWxlCj4gaW5kZXgg
NjQzMGJmYi4uZWNlZWNiMiAxMDA2NDQKPiAtLS0gYS90b29scy9NYWtlZmlsZQo+ICsrKyBiL3Rv
b2xzL01ha2VmaWxlCj4gQEAgLTg3LDYgKzg3LDE0IEBAIElPRU1VX0NPTkZJR1VSRV9DUk9TUyA/
PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgLS1pbnRl
cnAtcHJlZml4PSQoQ1JPU1NfU1lTX1JPT1QpCj4gwqBlbmRpZgo+Cj4gK2lmZXEgKCQoQ09ORklH
X1FFTVVVX0RFQlVHKSx5KQo+ICtRRU1VX09QVElPTkFMX0NPTkZJR1MgKz0gLS1lbmFibGUtZGVi
dWcKPiArZW5kaWYKPiArCj4gK2lmZXEgKCQoQ09ORklHX1FFTVVVX1NQSUNFKSx5KQo+ICtRRU1V
X09QVElPTkFMX0NPTkZJR1MgKz0gLS1lbmFibGUtc3BpY2UKPiArZW5kaWYKPiArCj4gwqBRRU1V
X1JPT1QgOj0gJChzaGVsbCBpZiBbIC1kICIkKENPTkZJR19RRU1VKSIgXTsgdGhlbiBlY2hvCj4g
IiQoQ09ORklHX1FFTVUpIjsgZWxzZSBlY2hvIC47IGZpKQo+IMKgaWZuZXEgKCQoUUVNVV9ST09U
KSwuKQo+IMKgZXhwb3J0IFFFTVVfUk9PVAo+IEBAIC0xNTgsNiArMTY2LDcgQEAgc3ViZGlyLWFs
bC1xZW11LXhlbi1kaXIgc3ViZGlyLWluc3RhbGwtcWVtdS14ZW4tZGlyOgo+IHFlbXUteGVuLWRp
ci1maW5kCj4gwqAgwqAgwqAgwqAgLS1kaXNhYmxlLWt2bSBcCj4gwqAgwqAgwqAgwqAgLS1weXRo
b249JChQWVRIT04pIFwKPiDCoCDCoCDCoCDCoCAkKElPRU1VX0NPTkZJR1VSRV9DUk9TUyk7IFwK
PiArIMKgIMKgIMKgIMKgJChRRU1VX09QVElPTkFMX0NPTkZJR1MpOyBcCj4gwqAgwqAgJChNQUtF
KSBpbnN0YWxsCj4KPiDCoHN1YmRpci1jbGVhbi1xZW11LXhlbi1kaXI6Cj4KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:56:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OTk-0005xB-5V; Tue, 28 Feb 2012 14:56:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2OTi-0005x0-Cv
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:56:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330440951!54405903!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14046 invoked from network); 28 Feb 2012 14:55:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:55:51 -0000
Received: by werm1 with SMTP id m1so2452397wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 06:56:33 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.135.193 as permitted sender) client-ip=10.216.135.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.135.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.135.193])
	by 10.216.135.193 with SMTP id u43mr10108560wei.34.1330440993023
	(num_hops = 1); Tue, 28 Feb 2012 06:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=khIE35p8MvMWtFP3jse3XvUvrLugiMI8HYrJMLh543Q=;
	b=vdHIM1YghmWiSw/ejSHL8SHOKpBm5cw9Ih2wmbgXuHZAQaufBRaRp1aFKvMUZSETzs
	reEdG8U6XtAT95SAavRZiihdxNPbJ+RybsEex1uiKgI91CbyJHaOrqW9/VzfpjX4NYyn
	2flueLyb3j5LUjG7J4T/7IXznKtv2XrHx9pKo=
MIME-Version: 1.0
Received: by 10.216.135.193 with SMTP id u43mr8037110wei.34.1330440992901;
	Tue, 28 Feb 2012 06:56:32 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Tue, 28 Feb 2012 06:56:32 -0800 (PST)
In-Reply-To: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 15:56:32 +0100
X-Google-Sender-Auth: T1M09J0iIfhuhMJQ7wMEWx0D-_s
Message-ID: <CAPLaKK5TZ9-URXJ8fSY6W7uB7ZGxPO9BFH+Mhw3COCC3Ko6f4A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI4IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IERheSBs
YXRlIGR1ZSB0byBkb2MgZGF5IHllc3RlcmRheS4gRllJIEknbGwgYmUgYXQgdGhlIGhhY2thdGhv
biBuZXh0Cj4gd2VlayBzbyBJIGV4cGVjdCBJJ2xsIGJlIHNraXBwaW5nIHRoYXQgdXBkYXRlLgo+
Cj4gQXMgdXN1YWwgcGxlYXNlIHBpbmcgbWUgd2l0aCBhbnkgdXBkYXRlcy9jb3JyZWN0aW9ucy4K
Pgo+IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+IMKgIMKgIMKgKiBkb21jdGxzIC8gc3lzY3RscyBz
ZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtlCj4gwqAgwqAgwqAgwqB0
aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwLCBw
YXRjaGVzCj4gwqAgwqAgwqAgwqBwb3N0ZWQpCj4KPiB0b29scywgYmxvY2tlcnM6Cj4KPiDCoCDC
oCDCoCogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBz
dGFibGUgQVBJCj4gwqAgwqAgwqAgwqB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJl
bHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCj4gwqAgwqAgwqAgwqB0aGlzIGFyZToKPiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogYWRkIGxpYnhsX2RlZmJvb2wgYW5kIGdlbmVyYWxseSB0cnkg
YW5kIGFycmFuZ2UgdGhhdAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbWVtc2V0KGZvbywwLC4u
LikgcmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBwYXRjaGVzIHJlcG9zdGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBTYWZlIGZv
cmsgdnMuIGZkIGhhbmRsaW5nIGhvb2tzLiBUaGlzIGlzIGFuIEFQSQo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgYWRkaXRpb24sIHNvIG1heWJlIG5vdCByZXF1aXJlZCBmcm8gc3RhYmxlIEFQSSwg
Yml0IG5lZWQKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRvIGhhdmUgZm9yIDQuMj8gKElhbiBK
LCBwYXRjaGVzIHBvc3RlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogeGwgZmVhdHVyZSBwYXJp
dHkgd2l0aCB4ZW5kIHdydCBkcml2ZXIgZG9tYWluIHN1cHBvcnQKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoChHZW9yZ2UgRHVubGFwKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBNb3JlIGZvcm1h
bGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeQo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgaW4gdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmlj
YXRpb24gYXJvdW5kCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtcmMxIHRvIHJlbWluZCBwZW9w
bGUgdG8gdGVzdCB4bC4KPiDCoCDCoCDCoCogQ29ycmVjdCBwYWdpbmcvc2hhcmluZyB0b29scyBi
dWZmZXIgbWxvY2tpbmcgKFRpbSwgQW5kcmVzLAo+IMKgIMKgIMKgIMKgcGF0Y2hlcyBwb3N0ZWQp
Cj4gwqAgwqAgwqAqIEF1dG9jb25mIChSb2dlciBQYXUgTW9ubsOpICYgSWFuIEosIERPTkUpCj4g
wqAgwqAgwqAqIHhsIHN1cHBvcnQgZm9yICJydGNfdGltZW9mZnNldCIgYW5kICJsb2NhbHRpbWUi
IChOb2JvZHkgQUZBSUNUKQogICAgICAgKiB5YWpsIDIuMCBzdXBwb3J0IGlzIHN0aWxsIG5vdCBm
aW5pc2hlZCBJIHRoaW5rLCBPbGFmIHBhdGNoZXMKaGF2ZSBub3QgeWV0IGJlZW4gY29tbWl0dGVk
IHRvIHRoZSByZXBvc2l0b3J5LCB0aGlzIHNob3VsZCBiZSBhCmJsb2NrZXIuCj4KPiBoeXBlcnZp
c29yLCBuaWNlIHRvIGhhdmU6Cj4gwqAgwqAgwqAqCj4gwqAgwqAgwqAqIHNvbGlkIGltcGxlbWVu
dGF0aW9uIG9mIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVudHMgKHVzaW5nIHdvcmsKPiDCoCDCoCDC
oCDCoHF1ZXVlcykgKFRpbSBEZWVnYW4sIE9sYWYgSGVycmluZyBldCBhbCkKPiDCoCDCoCDCoCog
QSBsb25nIHN0YW5kaW5nIGlzc3VlIGlzIGEgZnVsbHkgc3luY2hyb25pemVkIHAybSAobG9ja2lu
Zwo+IMKgIMKgIMKgIMKgbG9va3VwcykgKEFuZHJlcyBMYWdhci1DYXZpbGxhLCBET05FKQo+Cj4g
dG9vbHMsIG5pY2UgdG8gaGF2ZToKPgo+IMKgIMKgIMKgKiBIb3RwbHVnIHNjcmlwdCBzdHVmZiAt
LSBpbnRlcm5hbCB0byBsaWJ4bCAoSSB0aGluaywgdGhlcmVmb3JlIEkKPiDCoCDCoCDCoCDCoGRp
ZG4ndCBwdXQgdGhpcyB1bmRlciBzdGFibGUgQVBJIGFib3ZlKSBidXQgc3RpbGwgZ29vZCB0byBo
YXZlCj4gwqAgwqAgwqAgwqBmb3IgNC4yPyAoUm9nZXIgUGF1IE1vbm7DqSwgcGF0Y2hlcyBwb3N0
ZWQpCj4gwqAgwqAgwqAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBo
b3RwbHVnIHNjcmlwdCAoUm9nZXIKPiDCoCDCoCDCoCDCoFBhdSBNb25uw6kpCj4gwqAgwqAgwqAq
IENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZykKPiDC
oCDCoCDCoCogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVy
YXJkLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGF0Y2hlcyBzZW50KQo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0
ZWZhbm8KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFN0YWJlbGxpbmksIHBhdGNoZXMgc2VudCwg
d2FpdGluZyBmb3IgdXBzdHJlYW0gYWNrKQo+IMKgIMKgIMKgKiBOZXN0ZWQtdmlydHVhbGlzYXRp
b24gKGN1cnJlbnRseSBzaG91bGQgYmUgbWFya2VkIGV4cGVyaW1lbnRhbCwKPiDCoCDCoCDCoCDC
oGxpa2VseSB0byByZWxlYXNlIHRoYXQgd2F5PyBDb25zaWRlciBuZXN0ZWQtc3ZtIHNlcGFyYXRl
IHRvCj4gwqAgwqAgwqAgwqBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBzaGFw
ZSkKPiDCoCDCoCDCoCogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5IGNoZWNr
cG9pbnQsIGJsYWNraG9saW5nKQo+IMKgIMKgIMKgIMKgKFNocmlyYW0sIHBhdGNoZXMgcG9zdGVk
LCBibG9ja2VkIGJlaGluZCBxZW11IHNhdmUgcmVzdG9yZQo+IMKgIMKgIMKgIMKgcGF0Y2hlcykK
PiDCoCDCoCDCoCogeGwgc3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmll
d2VyPTEgb3Igb3RoZXJ3aXNlKQo+IMKgIMKgIMKgIMKgKE5vYm9keSBBRkFJQ1QpCj4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 14:56:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 14:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OTk-0005xB-5V; Tue, 28 Feb 2012 14:56:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2OTi-0005x0-Cv
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 14:56:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330440951!54405903!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14046 invoked from network); 28 Feb 2012 14:55:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 14:55:51 -0000
Received: by werm1 with SMTP id m1so2452397wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 06:56:33 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.135.193 as permitted sender) client-ip=10.216.135.193; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.135.193 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.135.193])
	by 10.216.135.193 with SMTP id u43mr10108560wei.34.1330440993023
	(num_hops = 1); Tue, 28 Feb 2012 06:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=khIE35p8MvMWtFP3jse3XvUvrLugiMI8HYrJMLh543Q=;
	b=vdHIM1YghmWiSw/ejSHL8SHOKpBm5cw9Ih2wmbgXuHZAQaufBRaRp1aFKvMUZSETzs
	reEdG8U6XtAT95SAavRZiihdxNPbJ+RybsEex1uiKgI91CbyJHaOrqW9/VzfpjX4NYyn
	2flueLyb3j5LUjG7J4T/7IXznKtv2XrHx9pKo=
MIME-Version: 1.0
Received: by 10.216.135.193 with SMTP id u43mr8037110wei.34.1330440992901;
	Tue, 28 Feb 2012 06:56:32 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Tue, 28 Feb 2012 06:56:32 -0800 (PST)
In-Reply-To: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 15:56:32 +0100
X-Google-Sender-Auth: T1M09J0iIfhuhMJQ7wMEWx0D-_s
Message-ID: <CAPLaKK5TZ9-URXJ8fSY6W7uB7ZGxPO9BFH+Mhw3COCC3Ko6f4A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI4IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IERheSBs
YXRlIGR1ZSB0byBkb2MgZGF5IHllc3RlcmRheS4gRllJIEknbGwgYmUgYXQgdGhlIGhhY2thdGhv
biBuZXh0Cj4gd2VlayBzbyBJIGV4cGVjdCBJJ2xsIGJlIHNraXBwaW5nIHRoYXQgdXBkYXRlLgo+
Cj4gQXMgdXN1YWwgcGxlYXNlIHBpbmcgbWUgd2l0aCBhbnkgdXBkYXRlcy9jb3JyZWN0aW9ucy4K
Pgo+IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+IMKgIMKgIMKgKiBkb21jdGxzIC8gc3lzY3RscyBz
ZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtlCj4gwqAgwqAgwqAgwqB0
aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwLCBw
YXRjaGVzCj4gwqAgwqAgwqAgwqBwb3N0ZWQpCj4KPiB0b29scywgYmxvY2tlcnM6Cj4KPiDCoCDC
oCDCoCogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBz
dGFibGUgQVBJCj4gwqAgwqAgwqAgwqB3aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJl
bHkgb24gbm90IGNoYW5naW5nLiBBc3BlY3RzIG9mCj4gwqAgwqAgwqAgwqB0aGlzIGFyZToKPiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogYWRkIGxpYnhsX2RlZmJvb2wgYW5kIGdlbmVyYWxseSB0cnkg
YW5kIGFycmFuZ2UgdGhhdAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbWVtc2V0KGZvbywwLC4u
LikgcmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqBwYXRjaGVzIHJlcG9zdGVkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBTYWZlIGZv
cmsgdnMuIGZkIGhhbmRsaW5nIGhvb2tzLiBUaGlzIGlzIGFuIEFQSQo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgYWRkaXRpb24sIHNvIG1heWJlIG5vdCByZXF1aXJlZCBmcm8gc3RhYmxlIEFQSSwg
Yml0IG5lZWQKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRvIGhhdmUgZm9yIDQuMj8gKElhbiBK
LCBwYXRjaGVzIHBvc3RlZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogeGwgZmVhdHVyZSBwYXJp
dHkgd2l0aCB4ZW5kIHdydCBkcml2ZXIgZG9tYWluIHN1cHBvcnQKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoChHZW9yZ2UgRHVubGFwKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBNb3JlIGZvcm1h
bGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeQo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgaW4gdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmlj
YXRpb24gYXJvdW5kCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtcmMxIHRvIHJlbWluZCBwZW9w
bGUgdG8gdGVzdCB4bC4KPiDCoCDCoCDCoCogQ29ycmVjdCBwYWdpbmcvc2hhcmluZyB0b29scyBi
dWZmZXIgbWxvY2tpbmcgKFRpbSwgQW5kcmVzLAo+IMKgIMKgIMKgIMKgcGF0Y2hlcyBwb3N0ZWQp
Cj4gwqAgwqAgwqAqIEF1dG9jb25mIChSb2dlciBQYXUgTW9ubsOpICYgSWFuIEosIERPTkUpCj4g
wqAgwqAgwqAqIHhsIHN1cHBvcnQgZm9yICJydGNfdGltZW9mZnNldCIgYW5kICJsb2NhbHRpbWUi
IChOb2JvZHkgQUZBSUNUKQogICAgICAgKiB5YWpsIDIuMCBzdXBwb3J0IGlzIHN0aWxsIG5vdCBm
aW5pc2hlZCBJIHRoaW5rLCBPbGFmIHBhdGNoZXMKaGF2ZSBub3QgeWV0IGJlZW4gY29tbWl0dGVk
IHRvIHRoZSByZXBvc2l0b3J5LCB0aGlzIHNob3VsZCBiZSBhCmJsb2NrZXIuCj4KPiBoeXBlcnZp
c29yLCBuaWNlIHRvIGhhdmU6Cj4gwqAgwqAgwqAqCj4gwqAgwqAgwqAqIHNvbGlkIGltcGxlbWVu
dGF0aW9uIG9mIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVudHMgKHVzaW5nIHdvcmsKPiDCoCDCoCDC
oCDCoHF1ZXVlcykgKFRpbSBEZWVnYW4sIE9sYWYgSGVycmluZyBldCBhbCkKPiDCoCDCoCDCoCog
QSBsb25nIHN0YW5kaW5nIGlzc3VlIGlzIGEgZnVsbHkgc3luY2hyb25pemVkIHAybSAobG9ja2lu
Zwo+IMKgIMKgIMKgIMKgbG9va3VwcykgKEFuZHJlcyBMYWdhci1DYXZpbGxhLCBET05FKQo+Cj4g
dG9vbHMsIG5pY2UgdG8gaGF2ZToKPgo+IMKgIMKgIMKgKiBIb3RwbHVnIHNjcmlwdCBzdHVmZiAt
LSBpbnRlcm5hbCB0byBsaWJ4bCAoSSB0aGluaywgdGhlcmVmb3JlIEkKPiDCoCDCoCDCoCDCoGRp
ZG4ndCBwdXQgdGhpcyB1bmRlciBzdGFibGUgQVBJIGFib3ZlKSBidXQgc3RpbGwgZ29vZCB0byBo
YXZlCj4gwqAgwqAgwqAgwqBmb3IgNC4yPyAoUm9nZXIgUGF1IE1vbm7DqSwgcGF0Y2hlcyBwb3N0
ZWQpCj4gwqAgwqAgwqAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBo
b3RwbHVnIHNjcmlwdCAoUm9nZXIKPiDCoCDCoCDCoCDCoFBhdSBNb25uw6kpCj4gwqAgwqAgwqAq
IENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZykKPiDC
oCDCoCDCoCogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gwqAgwqAgwqAgwqAgwqAg
wqAgwqAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVy
YXJkLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGF0Y2hlcyBzZW50KQo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0
ZWZhbm8KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFN0YWJlbGxpbmksIHBhdGNoZXMgc2VudCwg
d2FpdGluZyBmb3IgdXBzdHJlYW0gYWNrKQo+IMKgIMKgIMKgKiBOZXN0ZWQtdmlydHVhbGlzYXRp
b24gKGN1cnJlbnRseSBzaG91bGQgYmUgbWFya2VkIGV4cGVyaW1lbnRhbCwKPiDCoCDCoCDCoCDC
oGxpa2VseSB0byByZWxlYXNlIHRoYXQgd2F5PyBDb25zaWRlciBuZXN0ZWQtc3ZtIHNlcGFyYXRl
IHRvCj4gwqAgwqAgwqAgwqBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBzaGFw
ZSkKPiDCoCDCoCDCoCogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5IGNoZWNr
cG9pbnQsIGJsYWNraG9saW5nKQo+IMKgIMKgIMKgIMKgKFNocmlyYW0sIHBhdGNoZXMgcG9zdGVk
LCBibG9ja2VkIGJlaGluZCBxZW11IHNhdmUgcmVzdG9yZQo+IMKgIMKgIMKgIMKgcGF0Y2hlcykK
PiDCoCDCoCDCoCogeGwgc3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmll
d2VyPTEgb3Igb3RoZXJ3aXNlKQo+IMKgIMKgIMKgIMKgKE5vYm9keSBBRkFJQ1QpCj4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2Oet-0006Ir-Ai; Tue, 28 Feb 2012 15:08:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1S2Oer-0006Im-VY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:08:06 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330441624!53714248!1
X-Originating-IP: [70.38.127.103]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5706 invoked from network); 28 Feb 2012 15:07:05 -0000
Received: from mail1.malak.privatedns.com (HELO mail.corp.iweb.com)
	(70.38.127.103)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 15:07:05 -0000
Received: (qmail 15531 invoked by uid 509); 28 Feb 2012 15:08:03 -0000
Received: from fw.corp.privatedns.com (HELO poste-125.local)
	(mgagne@iweb.com@70.38.99.5)
	by mail.corp.iweb.com with SMTP; 28 Feb 2012 15:08:03 -0000
Message-ID: <4F4CEDD2.7080403@iweb.com>
Date: Tue, 28 Feb 2012 10:08:02 -0500
From: =?UTF-8?B?TWF0aGlldSBHYWduw6k=?= <mgagne@iweb.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:11.0) Gecko/20120222 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
X-TagToolbar-Keys: D20120228100802521
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

On 2/28/12 7:50 AM, Ian Campbell wrote:
> tools, blockers:
>
>        * libxl stable API -- we would like 4.2 to define a stable API
>          which downstream's can start to rely on not changing. Aspects of
>          this are:
>                * More formally deprecate xm/xend. Manpage patches already
>                  in tree. Needs release noting and communication around
>                  -rc1 to remind people to test xl.

Will there be support for rate limiting for vif as there is in xm/xend?

The help for the command "network-attach" shows support for "rate". 
Unfortunately, an error occurs when using the "rate" parameter:
"the rate parameter for vifs is currently not supported"

The same applies for the "accel" parameter which I don't know the 
purpose and don't use.

-- 
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2Oet-0006Ir-Ai; Tue, 28 Feb 2012 15:08:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1S2Oer-0006Im-VY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:08:06 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330441624!53714248!1
X-Originating-IP: [70.38.127.103]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5706 invoked from network); 28 Feb 2012 15:07:05 -0000
Received: from mail1.malak.privatedns.com (HELO mail.corp.iweb.com)
	(70.38.127.103)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 15:07:05 -0000
Received: (qmail 15531 invoked by uid 509); 28 Feb 2012 15:08:03 -0000
Received: from fw.corp.privatedns.com (HELO poste-125.local)
	(mgagne@iweb.com@70.38.99.5)
	by mail.corp.iweb.com with SMTP; 28 Feb 2012 15:08:03 -0000
Message-ID: <4F4CEDD2.7080403@iweb.com>
Date: Tue, 28 Feb 2012 10:08:02 -0500
From: =?UTF-8?B?TWF0aGlldSBHYWduw6k=?= <mgagne@iweb.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:11.0) Gecko/20120222 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
X-TagToolbar-Keys: D20120228100802521
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

On 2/28/12 7:50 AM, Ian Campbell wrote:
> tools, blockers:
>
>        * libxl stable API -- we would like 4.2 to define a stable API
>          which downstream's can start to rely on not changing. Aspects of
>          this are:
>                * More formally deprecate xm/xend. Manpage patches already
>                  in tree. Needs release noting and communication around
>                  -rc1 to remind people to test xl.

Will there be support for rate limiting for vif as there is in xm/xend?

The help for the command "network-attach" shows support for "rate". 
Unfortunately, an error occurs when using the "rate" parameter:
"the rate parameter for vifs is currently not supported"

The same applies for the "accel" parameter which I don't know the 
purpose and don't use.

-- 
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:15:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OlR-0006TH-53; Tue, 28 Feb 2012 15:14:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2OlP-0006T9-1M
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:14:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330442052!58690355!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTg3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28118 invoked from network); 28 Feb 2012 15:14:12 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-13.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 15:14:12 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 9473E1A8076;
	Tue, 28 Feb 2012 07:14:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YFT3vy+AvsxBsEEtxGPGXDRs7MSGRqkv00Jaxkf70tI9
	9+y+qJst4vCW+bhWx5TCNHqP2YCWgbtC1A76vfid2LKvWtOiT8zR/jZeTJBaX6TY
	VzJBRdG9EefEbBJi/GxKfXp8QVSs5gaIF9ZMA29Anhx5OaW656VvSayCTf0JfRM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=XbZK605x7pC0dApffT8V4lyYL9o=; b=cjiqMUMr
	5JNqsjL7/sJr9u7jXbg23hApkFziErtWMuxbmDyQ7NYBR+gYLlQRzpYP8ddgzekT
	jjCiTrmRADD/6w2D1aJPhQLDz+Fp2ttiDz7wH2kGDZOHI8hYQjI1v3L/WcSqgIpO
	ZNH0hlDSNaYA3U/Z3zD1Nipf6VFujUa04iA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 1152D1A8069; 
	Tue, 28 Feb 2012 07:14:43 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 07:14:43 -0800
Message-ID: <d584802ff8deff07b8de3483b75aada7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330433794.31269.146.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
	<1330433794.31269.146.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 07:14:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize
 mem_event/access/paging interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
>> tools/libxc/xc_mem_access.c         |  10 ++++++++--
>>  tools/libxc/xc_mem_event.c          |  13 ++++++++-----
>>  tools/libxc/xc_mem_paging.c         |  10 ++++++++--
>>  tools/libxc/xenctrl.h               |   6 +++---
>>  tools/tests/xen-access/xen-access.c |  22 ++++------------------
>>  tools/xenpaging/xenpaging.c         |  18 +++---------------
>>  tools/xenpaging/xenpaging.h         |   2 +-
>>  xen/arch/x86/mm/mem_event.c         |  33
>> +++------------------------------
>>  xen/include/public/domctl.h         |   4 ++--
>>  xen/include/public/mem_event.h      |   4 ----
>>  xen/include/xen/sched.h             |   2 --
>>  11 files changed, 40 insertions(+), 84 deletions(-)
>>
>>
>> Don't use the superfluous shared page, return the event channel directly
>> as
>> part of the domctl struct, instead.
>>
>> In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API
>> change,
>> so please voice any concerns.
>>
>> Known pending issues:
>> - pager could die and its ring page could be used by some other process,
>> yet
>>   Xen retains the mapping to it.
>> - use a saner interface for the paging_load buffer.
>>
>> This change also affects the x86/mm bits in the hypervisor that process
>> the
>> mem_event setup domctl.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_access.c
>> --- a/tools/libxc/xc_mem_access.c
>> +++ b/tools/libxc/xc_mem_access.c
>> @@ -25,12 +25,18 @@
>>
>>
>>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>> -                        void *shared_page, void *ring_page)
>> +                         uint32_t *port, void *ring_page)
>>  {
>> +    if ( !port )
>> +    {
>> +        errno = -EINVAL;
>
> Aren't errno vals normally +ve?
>
> Is there any situation where port==NULL would be valid, i.e. any chance
> that this might happen, or are such callers just buggy?

Definitely, it should be errno = EINVAL. I'll fix this in this patch and
the sharing ring one.
>
>> +        return -1;
>> +    }
>
>> +
>>      return xc_mem_event_control(xch, domain_id,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
>> -                                shared_page, ring_page);
>> +                                port, ring_page);
>>  }
>>
>>  int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
>> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_event.c
>> --- a/tools/libxc/xc_mem_event.c
>> +++ b/tools/libxc/xc_mem_event.c
>> @@ -24,19 +24,22 @@
>>  #include "xc_private.h"
>>
>>  int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned
>> int op,
>> -                         unsigned int mode, void *page, void
>> *ring_page)
>> +                         unsigned int mode, uint32_t *port, void
>> *ring_page)
>>  {
>>      DECLARE_DOMCTL;
>> +    int rc;
>>
>>      domctl.cmd = XEN_DOMCTL_mem_event_op;
>>      domctl.domain = domain_id;
>>      domctl.u.mem_event_op.op = op;
>>      domctl.u.mem_event_op.mode = mode;
>> -
>> -    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
>> -    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
>> +    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
>>
>> -    return do_domctl(xch, &domctl);
>> +    errno = 0;
>> +    rc = do_domctl(xch, &domctl);
>> +    if ( !rc && port )
>> +        *port = domctl.u.mem_event_op.port;
>> +    return rc;
>
> Clearing errno is an unusual pattern, normally callers only expect errno
> to contain a valid value on failure. Are you trying to provide some
> backwards compatibility with something or is there another reason for
> doing it this way?

I can remove that as well.
Thanks,
Andres
>
>>  }
>>
>>  int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_paging.c
>> --- a/tools/libxc/xc_mem_paging.c
>> +++ b/tools/libxc/xc_mem_paging.c
>> @@ -25,12 +25,18 @@
>>
>>
>>  int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
>> -                        void *shared_page, void *ring_page)
>> +                         uint32_t *port, void *ring_page)
>>  {
>> +    if ( !port )
>> +    {
>> +        errno = -EINVAL;
>
> Same comments as before.
>
>> +        return -1;
>> +    }
>> +
>>      return xc_mem_event_control(xch, domain_id,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>> -                                shared_page, ring_page);
>> +                                port, ring_page);
>>  }
>>
>
> Ian.
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:15:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OlR-0006TH-53; Tue, 28 Feb 2012 15:14:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2OlP-0006T9-1M
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:14:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330442052!58690355!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTg3NzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28118 invoked from network); 28 Feb 2012 15:14:12 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-13.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 15:14:12 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 9473E1A8076;
	Tue, 28 Feb 2012 07:14:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=YFT3vy+AvsxBsEEtxGPGXDRs7MSGRqkv00Jaxkf70tI9
	9+y+qJst4vCW+bhWx5TCNHqP2YCWgbtC1A76vfid2LKvWtOiT8zR/jZeTJBaX6TY
	VzJBRdG9EefEbBJi/GxKfXp8QVSs5gaIF9ZMA29Anhx5OaW656VvSayCTf0JfRM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=XbZK605x7pC0dApffT8V4lyYL9o=; b=cjiqMUMr
	5JNqsjL7/sJr9u7jXbg23hApkFziErtWMuxbmDyQ7NYBR+gYLlQRzpYP8ddgzekT
	jjCiTrmRADD/6w2D1aJPhQLDz+Fp2ttiDz7wH2kGDZOHI8hYQjI1v3L/WcSqgIpO
	ZNH0hlDSNaYA3U/Z3zD1Nipf6VFujUa04iA=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 1152D1A8069; 
	Tue, 28 Feb 2012 07:14:43 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 07:14:43 -0800
Message-ID: <d584802ff8deff07b8de3483b75aada7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330433794.31269.146.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<3b24188d8815aa5a5abb.1329977106@xdev.gridcentric.ca>
	<1330433794.31269.146.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 07:14:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 7] Tools: Sanitize
 mem_event/access/paging interfaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
>> tools/libxc/xc_mem_access.c         |  10 ++++++++--
>>  tools/libxc/xc_mem_event.c          |  13 ++++++++-----
>>  tools/libxc/xc_mem_paging.c         |  10 ++++++++--
>>  tools/libxc/xenctrl.h               |   6 +++---
>>  tools/tests/xen-access/xen-access.c |  22 ++++------------------
>>  tools/xenpaging/xenpaging.c         |  18 +++---------------
>>  tools/xenpaging/xenpaging.h         |   2 +-
>>  xen/arch/x86/mm/mem_event.c         |  33
>> +++------------------------------
>>  xen/include/public/domctl.h         |   4 ++--
>>  xen/include/public/mem_event.h      |   4 ----
>>  xen/include/xen/sched.h             |   2 --
>>  11 files changed, 40 insertions(+), 84 deletions(-)
>>
>>
>> Don't use the superfluous shared page, return the event channel directly
>> as
>> part of the domctl struct, instead.
>>
>> In-tree consumers (xenpaging, xen-access) updated. This is an ABI/API
>> change,
>> so please voice any concerns.
>>
>> Known pending issues:
>> - pager could die and its ring page could be used by some other process,
>> yet
>>   Xen retains the mapping to it.
>> - use a saner interface for the paging_load buffer.
>>
>> This change also affects the x86/mm bits in the hypervisor that process
>> the
>> mem_event setup domctl.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_access.c
>> --- a/tools/libxc/xc_mem_access.c
>> +++ b/tools/libxc/xc_mem_access.c
>> @@ -25,12 +25,18 @@
>>
>>
>>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>> -                        void *shared_page, void *ring_page)
>> +                         uint32_t *port, void *ring_page)
>>  {
>> +    if ( !port )
>> +    {
>> +        errno = -EINVAL;
>
> Aren't errno vals normally +ve?
>
> Is there any situation where port==NULL would be valid, i.e. any chance
> that this might happen, or are such callers just buggy?

Definitely, it should be errno = EINVAL. I'll fix this in this patch and
the sharing ring one.
>
>> +        return -1;
>> +    }
>
>> +
>>      return xc_mem_event_control(xch, domain_id,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
>> -                                shared_page, ring_page);
>> +                                port, ring_page);
>>  }
>>
>>  int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
>> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_event.c
>> --- a/tools/libxc/xc_mem_event.c
>> +++ b/tools/libxc/xc_mem_event.c
>> @@ -24,19 +24,22 @@
>>  #include "xc_private.h"
>>
>>  int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned
>> int op,
>> -                         unsigned int mode, void *page, void
>> *ring_page)
>> +                         unsigned int mode, uint32_t *port, void
>> *ring_page)
>>  {
>>      DECLARE_DOMCTL;
>> +    int rc;
>>
>>      domctl.cmd = XEN_DOMCTL_mem_event_op;
>>      domctl.domain = domain_id;
>>      domctl.u.mem_event_op.op = op;
>>      domctl.u.mem_event_op.mode = mode;
>> -
>> -    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
>> -    domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
>> +    domctl.u.mem_event_op.ring_addr = (unsigned long) ring_page;
>>
>> -    return do_domctl(xch, &domctl);
>> +    errno = 0;
>> +    rc = do_domctl(xch, &domctl);
>> +    if ( !rc && port )
>> +        *port = domctl.u.mem_event_op.port;
>> +    return rc;
>
> Clearing errno is an unusual pattern, normally callers only expect errno
> to contain a valid value on failure. Are you trying to provide some
> backwards compatibility with something or is there another reason for
> doing it this way?

I can remove that as well.
Thanks,
Andres
>
>>  }
>>
>>  int xc_mem_event_memop(xc_interface *xch, domid_t domain_id,
>> diff -r 8ddd13cc783e -r 3b24188d8815 tools/libxc/xc_mem_paging.c
>> --- a/tools/libxc/xc_mem_paging.c
>> +++ b/tools/libxc/xc_mem_paging.c
>> @@ -25,12 +25,18 @@
>>
>>
>>  int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
>> -                        void *shared_page, void *ring_page)
>> +                         uint32_t *port, void *ring_page)
>>  {
>> +    if ( !port )
>> +    {
>> +        errno = -EINVAL;
>
> Same comments as before.
>
>> +        return -1;
>> +    }
>> +
>>      return xc_mem_event_control(xch, domain_id,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
>>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>> -                                shared_page, ring_page);
>> +                                port, ring_page);
>>  }
>>
>
> Ian.
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:20:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2OqP-0006dK-SU; Tue, 28 Feb 2012 15:20:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2OqO-0006dD-1j
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:20:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330442342!51768146!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTcwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5787 invoked from network); 28 Feb 2012 15:19:02 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 15:19:02 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C981E300072;
	Tue, 28 Feb 2012 07:19:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MQyclGp59XqsvqVxdZkYSJJoYrflaJ6loC4A6gB28ltq
	u0UH+E624RLcoT5WaAAijrVQu9ldVLwRIxIK9vQ4XElEtNegnNiz2byQ00ou2K+k
	J0tM4Uwz+iJXD3XIzGZplvNP9/l7SonwE0OGyMiD8DuhKWmShIHVw34I1QMVJ/k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=kmOB3Z2g0xTt6rKJOhheM7mEJ6g=; b=id4MZGOS
	zN82j3oGuda/Ojc3L/jp/3IfDYwLn152hbaq8lyYljzaqsvX/c7nMchuLhMzQVcp
	VHzYijzDBhnBIG4dRRqBNEJr3+kCMp8B8FG7VIlH74t4v8yto8jLH6egc3jhBKGa
	h45uUxkad3SkqGm0odlsmYdhIN+Ur48XDPc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 4860230006C; 
	Tue, 28 Feb 2012 07:19:54 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 07:19:54 -0800
Message-ID: <5e43716b77c694ad491d82077777b705.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330434093.31269.150.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
	<1330434093.31269.150.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 07:19:54 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest
 address space to store mem event rings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
>
> Doers this mean that a guest can now potentially observe, or even modify
> it's own mem event ring? Are we sure there's no potential for havoc
> here?

This is the same mechanism we use to map the qemu ioreq and bufioreq
rings. These pfns lie within a reserved region as advertised by the e820
to the guest, so that's the protection we rely upon.

>
> Is there no scope for making these pages owned by the domain but not
> actually part of the P2M? We can cope with that for other types of magic
> page, can't we?

If you're referring to the qemu rings, I don't think so. They're like any
other page in the p2m. They get allocated with xc_populate_physmap_exact.

>
> I didn't atually dig into the implementation other than to see if it
> answered  my questions, although I did notice:
>
>> diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
>> --- a/tools/libxc/xc_hvm_build.c
>> +++ b/tools/libxc/xc_hvm_build.c
>> @@ -38,12 +38,15 @@
>>  #define SUPERPAGE_1GB_SHIFT   18
>>  #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
>>
>> -#define SPECIALPAGE_BUFIOREQ 0
>> -#define SPECIALPAGE_XENSTORE 1
>> -#define SPECIALPAGE_IOREQ    2
>> -#define SPECIALPAGE_IDENT_PT 3
>> -#define SPECIALPAGE_CONSOLE  4
>> -#define NR_SPECIAL_PAGES     5
>> +#define SPECIALPAGE_PAGING   0
>> +#define SPECIALPAGE_ACCESS   1
>> +#define SPECIALPAGE_SHARING  2
>> +#define SPECIALPAGE_BUFIOREQ 3
>> +#define SPECIALPAGE_XENSTORE 4
>> +#define SPECIALPAGE_IOREQ    5
>> +#define SPECIALPAGE_IDENT_PT 6
>> +#define SPECIALPAGE_CONSOLE  7
>> +#define NR_SPECIAL_PAGES     8
>
> Any reason to not simply append them?

Yes: I didn't want to change the existing magic pfn's. If I just append,
all pfns shift, and now the venerable store or ioreq pfn's are on
different locations.

Andres
>
> Ian.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:20:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2OqP-0006dK-SU; Tue, 28 Feb 2012 15:20:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2OqO-0006dD-1j
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:20:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330442342!51768146!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTcwNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5787 invoked from network); 28 Feb 2012 15:19:02 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-6.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 15:19:02 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C981E300072;
	Tue, 28 Feb 2012 07:19:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MQyclGp59XqsvqVxdZkYSJJoYrflaJ6loC4A6gB28ltq
	u0UH+E624RLcoT5WaAAijrVQu9ldVLwRIxIK9vQ4XElEtNegnNiz2byQ00ou2K+k
	J0tM4Uwz+iJXD3XIzGZplvNP9/l7SonwE0OGyMiD8DuhKWmShIHVw34I1QMVJ/k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=kmOB3Z2g0xTt6rKJOhheM7mEJ6g=; b=id4MZGOS
	zN82j3oGuda/Ojc3L/jp/3IfDYwLn152hbaq8lyYljzaqsvX/c7nMchuLhMzQVcp
	VHzYijzDBhnBIG4dRRqBNEJr3+kCMp8B8FG7VIlH74t4v8yto8jLH6egc3jhBKGa
	h45uUxkad3SkqGm0odlsmYdhIN+Ur48XDPc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 4860230006C; 
	Tue, 28 Feb 2012 07:19:54 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 07:19:54 -0800
Message-ID: <5e43716b77c694ad491d82077777b705.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1330434093.31269.150.camel@zakaz.uk.xensource.com>
References: <patchbomb.1329977105@xdev.gridcentric.ca>
	<0e79f8005b6b68e84a0f.1329977108@xdev.gridcentric.ca>
	<1330434093.31269.150.camel@zakaz.uk.xensource.com>
Date: Tue, 28 Feb 2012 07:19:54 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "olaf@aepfle.de" <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 3 of 7] Use a reserved pfn in the guest
 address space to store mem event rings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Thu, 2012-02-23 at 06:05 +0000, Andres Lagar-Cavilla wrote:
>
> Doers this mean that a guest can now potentially observe, or even modify
> it's own mem event ring? Are we sure there's no potential for havoc
> here?

This is the same mechanism we use to map the qemu ioreq and bufioreq
rings. These pfns lie within a reserved region as advertised by the e820
to the guest, so that's the protection we rely upon.

>
> Is there no scope for making these pages owned by the domain but not
> actually part of the P2M? We can cope with that for other types of magic
> page, can't we?

If you're referring to the qemu rings, I don't think so. They're like any
other page in the p2m. They get allocated with xc_populate_physmap_exact.

>
> I didn't atually dig into the implementation other than to see if it
> answered  my questions, although I did notice:
>
>> diff -r 99e6c9b9e971 -r 0e79f8005b6b tools/libxc/xc_hvm_build.c
>> --- a/tools/libxc/xc_hvm_build.c
>> +++ b/tools/libxc/xc_hvm_build.c
>> @@ -38,12 +38,15 @@
>>  #define SUPERPAGE_1GB_SHIFT   18
>>  #define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
>>
>> -#define SPECIALPAGE_BUFIOREQ 0
>> -#define SPECIALPAGE_XENSTORE 1
>> -#define SPECIALPAGE_IOREQ    2
>> -#define SPECIALPAGE_IDENT_PT 3
>> -#define SPECIALPAGE_CONSOLE  4
>> -#define NR_SPECIAL_PAGES     5
>> +#define SPECIALPAGE_PAGING   0
>> +#define SPECIALPAGE_ACCESS   1
>> +#define SPECIALPAGE_SHARING  2
>> +#define SPECIALPAGE_BUFIOREQ 3
>> +#define SPECIALPAGE_XENSTORE 4
>> +#define SPECIALPAGE_IOREQ    5
>> +#define SPECIALPAGE_IDENT_PT 6
>> +#define SPECIALPAGE_CONSOLE  7
>> +#define NR_SPECIAL_PAGES     8
>
> Any reason to not simply append them?

Yes: I didn't want to change the existing magic pfn's. If I just append,
all pfns shift, and now the venerable store or ioreq pfn's are on
different locations.

Andres
>
> Ian.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:22:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OsP-0006kw-K0; Tue, 28 Feb 2012 15:22:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2OsO-0006kb-Ue
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:22:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330442518!13159310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3319 invoked from network); 28 Feb 2012 15:21:59 -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 Feb 2012 15:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10986571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:21:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 15:21:11 +0000
Message-ID: <1330442470.31269.187.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 28 Feb 2012 15:21:10 +0000
In-Reply-To: <4F4CEDD2.7080403@iweb.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<4F4CEDD2.7080403@iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTI4IGF0IDE1OjA4ICswMDAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBIaSwKPiAKPiBPbiAyLzI4LzEyIDc6NTAgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+IHRv
b2xzLCBibG9ja2VyczoKPiA+Cj4gPiAgICAgICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdv
dWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKPiA+ICAgICAgICAgIHdoaWNoIGRv
d25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YK
PiA+ICAgICAgICAgIHRoaXMgYXJlOgo+ID4gICAgICAgICAgICAgICAgKiBNb3JlIGZvcm1hbGx5
IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeQo+ID4gICAgICAgICAg
ICAgICAgICBpbiB0cmVlLiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBh
cm91bmQKPiA+ICAgICAgICAgICAgICAgICAgLXJjMSB0byByZW1pbmQgcGVvcGxlIHRvIHRlc3Qg
eGwuCj4gCj4gV2lsbCB0aGVyZSBiZSBzdXBwb3J0IGZvciByYXRlIGxpbWl0aW5nIGZvciB2aWYg
YXMgdGhlcmUgaXMgaW4geG0veGVuZD8KPiAKPiBUaGUgaGVscCBmb3IgdGhlIGNvbW1hbmQgIm5l
dHdvcmstYXR0YWNoIiBzaG93cyBzdXBwb3J0IGZvciAicmF0ZSIuIAo+IFVuZm9ydHVuYXRlbHks
IGFuIGVycm9yIG9jY3VycyB3aGVuIHVzaW5nIHRoZSAicmF0ZSIgcGFyYW1ldGVyOgo+ICJ0aGUg
cmF0ZSBwYXJhbWV0ZXIgZm9yIHZpZnMgaXMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWQiCgpJIHRo
aW5rIHRoaXMgb3VnaHQgdG8gYmUgZml4ZWQgYmVmb3JlIDQuMi4KCkl0IHNob3VsZCBiZSBhIGZh
aXJseSBzaW1wbGUgbWF0dGVyIHRvIHBsdW1iIHRoZSBwYXJhbWV0ZXIgdGhyb3VnaCB0bwp0aGUg
dW5kZXJseWluZyB4ZW5zdG9yZSBrZXkuIElmIHlvdSBmZWVsIHVwIHRvIGNyZWF0aW5nIGEgcGF0
Y2ggSSdkIGJlCmhhcHB5IHRvIGdpdmUgc29tZSBndWlkYW5jZS4KCj4gVGhlIHNhbWUgYXBwbGll
cyBmb3IgdGhlICJhY2NlbCIgcGFyYW1ldGVyIHdoaWNoIEkgZG9uJ3Qga25vdyB0aGUgCj4gcHVy
cG9zZSBhbmQgZG9uJ3QgdXNlLgoKVGhpcyBlbmFibGVzIChvciB3b3VsZCwgaWYgaXQgd2VyZSBp
bXBsZW1lbnRlZCkgdGhlIHVzZSBvZiB0aGUgb2xkIGgvdwphY2NlbGVyYXRpb24gaW50ZXJmYWNl
IGZvciBuZXRjaGFubmVsLiBJJ20gbm90IHN1cmUgaWYgYW55b25lIGlzIHN0aWxsCnVzaW5nIG9y
IHN1cHBvcnRpbmcgdGhpcyBlaXRoZXIuIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IHN1cHBv
cnQgaW4KdGhlIHVwc3RyZWFtIGtlcm5lbHMgZm9yIHRoaXMgc3R1ZmYgZWl0aGVyLiBJJ20gaW5j
bGluZWQgdG8gb21pdCBpdCBmb3IKNC4yIHVubGVzcyBzb21lb25lIGlzIGtlZW4gdG8gZG8gdGhl
IG5lY2Vzc2FyeSB3b3JrLgoKSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:22:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:22:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OsP-0006kw-K0; Tue, 28 Feb 2012 15:22:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2OsO-0006kb-Ue
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:22:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1330442518!13159310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3319 invoked from network); 28 Feb 2012 15:21:59 -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 Feb 2012 15:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10986571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:21:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 15:21:11 +0000
Message-ID: <1330442470.31269.187.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 28 Feb 2012 15:21:10 +0000
In-Reply-To: <4F4CEDD2.7080403@iweb.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<4F4CEDD2.7080403@iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTI4IGF0IDE1OjA4ICswMDAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBIaSwKPiAKPiBPbiAyLzI4LzEyIDc6NTAgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+IHRv
b2xzLCBibG9ja2VyczoKPiA+Cj4gPiAgICAgICAgKiBsaWJ4bCBzdGFibGUgQVBJIC0tIHdlIHdv
dWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKPiA+ICAgICAgICAgIHdoaWNoIGRv
d25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YK
PiA+ICAgICAgICAgIHRoaXMgYXJlOgo+ID4gICAgICAgICAgICAgICAgKiBNb3JlIGZvcm1hbGx5
IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeQo+ID4gICAgICAgICAg
ICAgICAgICBpbiB0cmVlLiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBh
cm91bmQKPiA+ICAgICAgICAgICAgICAgICAgLXJjMSB0byByZW1pbmQgcGVvcGxlIHRvIHRlc3Qg
eGwuCj4gCj4gV2lsbCB0aGVyZSBiZSBzdXBwb3J0IGZvciByYXRlIGxpbWl0aW5nIGZvciB2aWYg
YXMgdGhlcmUgaXMgaW4geG0veGVuZD8KPiAKPiBUaGUgaGVscCBmb3IgdGhlIGNvbW1hbmQgIm5l
dHdvcmstYXR0YWNoIiBzaG93cyBzdXBwb3J0IGZvciAicmF0ZSIuIAo+IFVuZm9ydHVuYXRlbHks
IGFuIGVycm9yIG9jY3VycyB3aGVuIHVzaW5nIHRoZSAicmF0ZSIgcGFyYW1ldGVyOgo+ICJ0aGUg
cmF0ZSBwYXJhbWV0ZXIgZm9yIHZpZnMgaXMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWQiCgpJIHRo
aW5rIHRoaXMgb3VnaHQgdG8gYmUgZml4ZWQgYmVmb3JlIDQuMi4KCkl0IHNob3VsZCBiZSBhIGZh
aXJseSBzaW1wbGUgbWF0dGVyIHRvIHBsdW1iIHRoZSBwYXJhbWV0ZXIgdGhyb3VnaCB0bwp0aGUg
dW5kZXJseWluZyB4ZW5zdG9yZSBrZXkuIElmIHlvdSBmZWVsIHVwIHRvIGNyZWF0aW5nIGEgcGF0
Y2ggSSdkIGJlCmhhcHB5IHRvIGdpdmUgc29tZSBndWlkYW5jZS4KCj4gVGhlIHNhbWUgYXBwbGll
cyBmb3IgdGhlICJhY2NlbCIgcGFyYW1ldGVyIHdoaWNoIEkgZG9uJ3Qga25vdyB0aGUgCj4gcHVy
cG9zZSBhbmQgZG9uJ3QgdXNlLgoKVGhpcyBlbmFibGVzIChvciB3b3VsZCwgaWYgaXQgd2VyZSBp
bXBsZW1lbnRlZCkgdGhlIHVzZSBvZiB0aGUgb2xkIGgvdwphY2NlbGVyYXRpb24gaW50ZXJmYWNl
IGZvciBuZXRjaGFubmVsLiBJJ20gbm90IHN1cmUgaWYgYW55b25lIGlzIHN0aWxsCnVzaW5nIG9y
IHN1cHBvcnRpbmcgdGhpcyBlaXRoZXIuIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IHN1cHBv
cnQgaW4KdGhlIHVwc3RyZWFtIGtlcm5lbHMgZm9yIHRoaXMgc3R1ZmYgZWl0aGVyLiBJJ20gaW5j
bGluZWQgdG8gb21pdCBpdCBmb3IKNC4yIHVubGVzcyBzb21lb25lIGlzIGtlZW4gdG8gZG8gdGhl
IG5lY2Vzc2FyeSB3b3JrLgoKSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:26:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OwB-0006wc-87; Tue, 28 Feb 2012 15:25:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2Ow9-0006wS-Ck
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:25:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330442750!15112256!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDIzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25806 invoked from network); 28 Feb 2012 15:25:50 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 15:25:50 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 7D407458085;
	Tue, 28 Feb 2012 07:25:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=EIErPKxZ6GAkgwIXMPMBLoiVnISrt7tIdJM8QFqY40ZK
	Yks//ISMPzjLTfiA2+lkzQ5+2wGlDqryNzg396FCBmQqNi2w/OMaDdsi2JUqhzrX
	/WmrFRcRVDt5fObYTh22w1/kPWkcCEih7vAzidSjVwLtlINuYzg7Tkh/9psQv/o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=u9D0sfR5520+KLghqy+MGsoS3Ug=; b=okxQOvvV
	bmXjGggAUj9FXQ69+Fbo2ex1sOzbqahoJ52L46gG9Lo+7q0VoVHdNHN2dzDTEwb7
	wEHLxBSgb7dj8XpwyZSL+iaxetdw345glpAZxBPIwrn+SYnCW39pleHwIsrbgM2q
	C5fIQ9XPC1CqTKKqWUGCNoC6HXjz63lnVlY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 3C299458084; 
	Tue, 28 Feb 2012 07:25:49 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 07:25:49 -0800
Message-ID: <2fb7e1b28da3154380f570cc40a36ddc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
	<9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
	<CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
Date: Tue, 28 Feb 2012 07:25:49 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>>> shared page gains you nothing. The ballooner can't know what is shared
>>>> and what isn't, in order to make an educated decision. And the sharer
>>>> can't foresee what the balloon will victimize.
>>>
>>> Doesn't ballooning generally evict unused pages, because it allocates
>>> new _free_ pages, even if they were shared is there any benefit to
>>> doing
>>> so?
>>
>> Certainly the balloon will pick free pages. The sharing daemon should
>> not
>> have shared those, but it's not unlikely that it will have.
>>
>> It's a classic semantic gap problem, and we were discussing this in the
>> context of paging ("the pager should not have paged out page table
>> pages")
>>
>> Beyond free pages, a prime target for sharing are read-only disk buffers
>> in the page cache. Those are victim #2 for the balloon.
>
> Not exactly -- victim #2 would be read-only disk buffers *which have
> not been read recently*.

Everything's been read recently in Windows. Seriously ;)

> Buffers which are in active use will not be
> evicted.  So although evicting these pages from the guests' cache
> doesn't buy the system any more memory, it doesn't have a major impact
> on the guest either.

That's debatable. Maybe guests shouldn't have a page cache then. Or a
really small one.

I'm not saying you're wrong, I'm saying that the answer is, as with many
things, "it depends"

>
> In any case, if the guest experiences its own internal memory
> pressure, these pages will be the first to go anyway.  After that, it
> will go for trying to evict infrequently-used read-write pages --
> which, if the pager is active, will already have been paged out to
> disk; thus we'll end up with the double-paging problem.  This will
> have a much larger impact on performance than uselessly evicting
> little-used read-only pages.
>
> So I think that even though sharing+balloon will lead to some
> occasional sub-optimal behavior, it's still a lot better than
> sharing+paging and no ballooning.  Remember that ballooning was a
> technique introduced in the paper by VMWare that talked about page
> sharing -- they obviously thought sharing+ballooning was better than
> sharing+paging.

Ties in with Dan's thread. Depends on how much effort you spend choosing
sharing and paging candidates, and how hard you inflate the balloon. I'm
not in favor of any such overarching statement (even though I made one
myself!!).

Andres

>
>  -George
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:26:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2OwB-0006wc-87; Tue, 28 Feb 2012 15:25:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2Ow9-0006wS-Ck
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:25:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330442750!15112256!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDIzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25806 invoked from network); 28 Feb 2012 15:25:50 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.66) by server-14.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 15:25:50 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 7D407458085;
	Tue, 28 Feb 2012 07:25:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=EIErPKxZ6GAkgwIXMPMBLoiVnISrt7tIdJM8QFqY40ZK
	Yks//ISMPzjLTfiA2+lkzQ5+2wGlDqryNzg396FCBmQqNi2w/OMaDdsi2JUqhzrX
	/WmrFRcRVDt5fObYTh22w1/kPWkcCEih7vAzidSjVwLtlINuYzg7Tkh/9psQv/o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=u9D0sfR5520+KLghqy+MGsoS3Ug=; b=okxQOvvV
	bmXjGggAUj9FXQ69+Fbo2ex1sOzbqahoJ52L46gG9Lo+7q0VoVHdNHN2dzDTEwb7
	wEHLxBSgb7dj8XpwyZSL+iaxetdw345glpAZxBPIwrn+SYnCW39pleHwIsrbgM2q
	C5fIQ9XPC1CqTKKqWUGCNoC6HXjz63lnVlY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 3C299458084; 
	Tue, 28 Feb 2012 07:25:49 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 07:25:49 -0800
Message-ID: <2fb7e1b28da3154380f570cc40a36ddc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
	<9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
	<CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
Date: Tue, 28 Feb 2012 07:25:49 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
> <andres@lagarcavilla.org> wrote:
>>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>>> shared page gains you nothing. The ballooner can't know what is shared
>>>> and what isn't, in order to make an educated decision. And the sharer
>>>> can't foresee what the balloon will victimize.
>>>
>>> Doesn't ballooning generally evict unused pages, because it allocates
>>> new _free_ pages, even if they were shared is there any benefit to
>>> doing
>>> so?
>>
>> Certainly the balloon will pick free pages. The sharing daemon should
>> not
>> have shared those, but it's not unlikely that it will have.
>>
>> It's a classic semantic gap problem, and we were discussing this in the
>> context of paging ("the pager should not have paged out page table
>> pages")
>>
>> Beyond free pages, a prime target for sharing are read-only disk buffers
>> in the page cache. Those are victim #2 for the balloon.
>
> Not exactly -- victim #2 would be read-only disk buffers *which have
> not been read recently*.

Everything's been read recently in Windows. Seriously ;)

> Buffers which are in active use will not be
> evicted.  So although evicting these pages from the guests' cache
> doesn't buy the system any more memory, it doesn't have a major impact
> on the guest either.

That's debatable. Maybe guests shouldn't have a page cache then. Or a
really small one.

I'm not saying you're wrong, I'm saying that the answer is, as with many
things, "it depends"

>
> In any case, if the guest experiences its own internal memory
> pressure, these pages will be the first to go anyway.  After that, it
> will go for trying to evict infrequently-used read-write pages --
> which, if the pager is active, will already have been paged out to
> disk; thus we'll end up with the double-paging problem.  This will
> have a much larger impact on performance than uselessly evicting
> little-used read-only pages.
>
> So I think that even though sharing+balloon will lead to some
> occasional sub-optimal behavior, it's still a lot better than
> sharing+paging and no ballooning.  Remember that ballooning was a
> technique introduced in the paper by VMWare that talked about page
> sharing -- they obviously thought sharing+ballooning was better than
> sharing+paging.

Ties in with Dan's thread. Depends on how much effort you spend choosing
sharing and paging candidates, and how hard you inflate the balloon. I'm
not in favor of any such overarching statement (even though I made one
myself!!).

Andres

>
>  -George
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2P9j-00078f-N8; Tue, 28 Feb 2012 15:39:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2P9h-00078a-MB
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:39:57 +0000
Received: from [85.158.139.83:34046] by server-1.bemta-5.messagelabs.com id
	3B/DE-28458-C45FC4F4; Tue, 28 Feb 2012 15:39:56 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330443595!13141444!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15272 invoked from network); 28 Feb 2012 15:39:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2012 15:39:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2P9e-00066F-JX
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 07:39:54 -0800
Date: Tue, 28 Feb 2012 07:39:54 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330443594598-5522191.post@n5.nabble.com>
In-Reply-To: <CAPLaKK5TZ9-URXJ8fSY6W7uB7ZGxPO9BFH+Mhw3COCC3Ko6f4A@mail.gmail.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<CAPLaKK5TZ9-URXJ8fSY6W7uB7ZGxPO9BFH+Mhw3COCC3Ko6f4A@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ClJvZ2VyIFBhdSBNb25uw6kgd3JvdGUKPiAKPiAgICAgICAgKiB5YWpsIDIuMCBzdXBwb3J0IGlz
IHN0aWxsIG5vdCBmaW5pc2hlZCBJIHRoaW5rLCBPbGFmIHBhdGNoZXMKPiBoYXZlIG5vdCB5ZXQg
YmVlbiBjb21taXR0ZWQgdG8gdGhlIHJlcG9zaXRvcnksIHRoaXMgc2hvdWxkIGJlIGEKPiBibG9j
a2VyLgo+IAoKWWVzLCB3aXRob3V0IHN1Y2ggcGF0Y2hlcyB0aGUgYnVpbGQgb24gV2hlZXp5IGZh
aWxzLgoKLS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEy
Lm41Lm5hYmJsZS5jb20vNC0yLVRPRE8tTGlzdC10cDU1MjE3MzNwNTUyMjE5MS5odG1sClNlbnQg
ZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2P9j-00078f-N8; Tue, 28 Feb 2012 15:39:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2P9h-00078a-MB
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:39:57 +0000
Received: from [85.158.139.83:34046] by server-1.bemta-5.messagelabs.com id
	3B/DE-28458-C45FC4F4; Tue, 28 Feb 2012 15:39:56 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330443595!13141444!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15272 invoked from network); 28 Feb 2012 15:39:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2012 15:39:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2P9e-00066F-JX
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 07:39:54 -0800
Date: Tue, 28 Feb 2012 07:39:54 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330443594598-5522191.post@n5.nabble.com>
In-Reply-To: <CAPLaKK5TZ9-URXJ8fSY6W7uB7ZGxPO9BFH+Mhw3COCC3Ko6f4A@mail.gmail.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<CAPLaKK5TZ9-URXJ8fSY6W7uB7ZGxPO9BFH+Mhw3COCC3Ko6f4A@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ClJvZ2VyIFBhdSBNb25uw6kgd3JvdGUKPiAKPiAgICAgICAgKiB5YWpsIDIuMCBzdXBwb3J0IGlz
IHN0aWxsIG5vdCBmaW5pc2hlZCBJIHRoaW5rLCBPbGFmIHBhdGNoZXMKPiBoYXZlIG5vdCB5ZXQg
YmVlbiBjb21taXR0ZWQgdG8gdGhlIHJlcG9zaXRvcnksIHRoaXMgc2hvdWxkIGJlIGEKPiBibG9j
a2VyLgo+IAoKWWVzLCB3aXRob3V0IHN1Y2ggcGF0Y2hlcyB0aGUgYnVpbGQgb24gV2hlZXp5IGZh
aWxzLgoKLS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEy
Lm41Lm5hYmJsZS5jb20vNC0yLVRPRE8tTGlzdC10cDU1MjE3MzNwNTUyMjE5MS5odG1sClNlbnQg
ZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:43:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2PDE-0007Ei-9u; Tue, 28 Feb 2012 15:43:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PDD-0007EU-6J
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:43:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1330443808!8958871!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 28 Feb 2012 15:43:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:43:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10987247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:43:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 15:43:27 +0000
Date: Tue, 28 Feb 2012 15:50:06 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 fifth version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


Please review the first three patches that touch generic code.
This patch series have been lying around for quite a while and it is
now blocking patches from getting in xen-unstable.



Changes in v5:

- rebased on b4bd0b168e9f4898b98308f4a8a089f647a86d16.


Changes in v4:

- following Anthony's suggestion I have introduced a new monitor command
to save the non-ram device state to file;

- I have also removed the hack not to reset the cirrus videoram on
restore, because it turns out that the videoram doesn't need to be
reset in the reset handler at all (tested on Win2K, where the problem
was found in the first place).



This is the list of patches with a diffstat:

Anthony PERARD (2):
      xen mapcache: check if memory region has moved.
      xen: do not allocate RAM during INMIGRATE runstate

Stefano Stabellini (4):
      cirrus_vga: do not reset videoram
      Introduce "save_devices"
      xen: record physmap changes to xenstore
      Set runstate to INMIGRATE earlier

 block-migration.c |    2 +-
 hmp-commands.hx   |   14 +++++++
 hw/cirrus_vga.c   |    4 --
 qmp-commands.hx   |   17 +++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    4 +-
 vmstate.h         |    1 +
 xen-all.c         |  104 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c    |   22 ++++++++++--
 xen-mapcache.h    |    9 ++++-
 11 files changed, 235 insertions(+), 15 deletions(-)

git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-5

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:43:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2PDE-0007Ei-9u; Tue, 28 Feb 2012 15:43:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PDD-0007EU-6J
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:43:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1330443808!8958871!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 28 Feb 2012 15:43:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:43:28 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="10987247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:43:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 15:43:27 +0000
Date: Tue, 28 Feb 2012 15:50:06 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 fifth version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


Please review the first three patches that touch generic code.
This patch series have been lying around for quite a while and it is
now blocking patches from getting in xen-unstable.



Changes in v5:

- rebased on b4bd0b168e9f4898b98308f4a8a089f647a86d16.


Changes in v4:

- following Anthony's suggestion I have introduced a new monitor command
to save the non-ram device state to file;

- I have also removed the hack not to reset the cirrus videoram on
restore, because it turns out that the videoram doesn't need to be
reset in the reset handler at all (tested on Win2K, where the problem
was found in the first place).



This is the list of patches with a diffstat:

Anthony PERARD (2):
      xen mapcache: check if memory region has moved.
      xen: do not allocate RAM during INMIGRATE runstate

Stefano Stabellini (4):
      cirrus_vga: do not reset videoram
      Introduce "save_devices"
      xen: record physmap changes to xenstore
      Set runstate to INMIGRATE earlier

 block-migration.c |    2 +-
 hmp-commands.hx   |   14 +++++++
 hw/cirrus_vga.c   |    4 --
 qmp-commands.hx   |   17 +++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    4 +-
 vmstate.h         |    1 +
 xen-all.c         |  104 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c    |   22 ++++++++++--
 xen-mapcache.h    |    9 ++++-
 11 files changed, 235 insertions(+), 15 deletions(-)

git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-5

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2PEZ-0007Km-Eb; Tue, 28 Feb 2012 15:44:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEY-0007JN-2c
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23701 invoked from network); 28 Feb 2012 15:44:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523383"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-AQ; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:34 +0000
Message-ID: <1330444295-8859-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 5/6] xen mapcache: check if memory
	region has moved.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index f2cad82..972cffd 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -1043,7 +1059,7 @@ int xen_hvm_init(void)
     }
 
     /* Init RAM management */
-    xen_map_cache_init();
+    xen_map_cache_init(xen_phys_offset_to_gaddr, state);
     xen_ram_init(ram_size);
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 585b559..a456479 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -78,6 +78,9 @@ typedef struct MapCache {
     uint8_t *last_address_vaddr;
     unsigned long max_mcache_size;
     unsigned int mcache_bucket_shift;
+
+    phys_offset_to_gaddr_t phys_offset_to_gaddr;
+    void *opaque;
 } MapCache;
 
 static MapCache *mapcache;
@@ -91,13 +94,16 @@ static inline int test_bits(int nr, int size, const unsigned long *addr)
         return 0;
 }
 
-void xen_map_cache_init(void)
+void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
 {
     unsigned long size;
     struct rlimit rlimit_as;
 
     mapcache = g_malloc0(sizeof (MapCache));
 
+    mapcache->phys_offset_to_gaddr = f;
+    mapcache->opaque = opaque;
+
     QTAILQ_INIT(&mapcache->locked_entries);
     mapcache->last_address_index = -1;
 
@@ -193,9 +199,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock)
 {
     MapCacheEntry *entry, *pentry = NULL;
-    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
-    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+    target_phys_addr_t address_index;
+    target_phys_addr_t address_offset;
     target_phys_addr_t __size = size;
+    bool translated = false;
+
+tryagain:
+    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
+    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
 
     trace_xen_map_cache(phys_addr);
 
@@ -237,6 +248,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
     if(!test_bits(address_offset >> XC_PAGE_SHIFT, size >> XC_PAGE_SHIFT,
                 entry->valid_mapping)) {
         mapcache->last_address_index = -1;
+        if (!translated && mapcache->phys_offset_to_gaddr) {
+            phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, mapcache->opaque);
+            translated = true;
+            goto tryagain;
+        }
         trace_xen_map_cache_return(NULL);
         return NULL;
     }
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..70301a5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -11,9 +11,13 @@
 
 #include <stdlib.h>
 
+typedef target_phys_addr_t (*phys_offset_to_gaddr_t)(target_phys_addr_t start_addr,
+                                                     ram_addr_t size,
+                                                     void *opaque);
 #ifdef CONFIG_XEN
 
-void xen_map_cache_init(void);
+void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                        void *opaque);
 uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock);
 ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
@@ -22,7 +26,8 @@ void xen_invalidate_map_cache(void);
 
 #else
 
-static inline void xen_map_cache_init(void)
+static inline void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                                      void *opaque)
 {
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2PEZ-0007Km-Eb; Tue, 28 Feb 2012 15:44:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEY-0007JN-2c
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23701 invoked from network); 28 Feb 2012 15:44:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523383"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-AQ; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:34 +0000
Message-ID: <1330444295-8859-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 5/6] xen mapcache: check if memory
	region has moved.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index f2cad82..972cffd 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -1043,7 +1059,7 @@ int xen_hvm_init(void)
     }
 
     /* Init RAM management */
-    xen_map_cache_init();
+    xen_map_cache_init(xen_phys_offset_to_gaddr, state);
     xen_ram_init(ram_size);
 
     qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 585b559..a456479 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -78,6 +78,9 @@ typedef struct MapCache {
     uint8_t *last_address_vaddr;
     unsigned long max_mcache_size;
     unsigned int mcache_bucket_shift;
+
+    phys_offset_to_gaddr_t phys_offset_to_gaddr;
+    void *opaque;
 } MapCache;
 
 static MapCache *mapcache;
@@ -91,13 +94,16 @@ static inline int test_bits(int nr, int size, const unsigned long *addr)
         return 0;
 }
 
-void xen_map_cache_init(void)
+void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
 {
     unsigned long size;
     struct rlimit rlimit_as;
 
     mapcache = g_malloc0(sizeof (MapCache));
 
+    mapcache->phys_offset_to_gaddr = f;
+    mapcache->opaque = opaque;
+
     QTAILQ_INIT(&mapcache->locked_entries);
     mapcache->last_address_index = -1;
 
@@ -193,9 +199,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock)
 {
     MapCacheEntry *entry, *pentry = NULL;
-    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
-    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+    target_phys_addr_t address_index;
+    target_phys_addr_t address_offset;
     target_phys_addr_t __size = size;
+    bool translated = false;
+
+tryagain:
+    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
+    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
 
     trace_xen_map_cache(phys_addr);
 
@@ -237,6 +248,11 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
     if(!test_bits(address_offset >> XC_PAGE_SHIFT, size >> XC_PAGE_SHIFT,
                 entry->valid_mapping)) {
         mapcache->last_address_index = -1;
+        if (!translated && mapcache->phys_offset_to_gaddr) {
+            phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, mapcache->opaque);
+            translated = true;
+            goto tryagain;
+        }
         trace_xen_map_cache_return(NULL);
         return NULL;
     }
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..70301a5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -11,9 +11,13 @@
 
 #include <stdlib.h>
 
+typedef target_phys_addr_t (*phys_offset_to_gaddr_t)(target_phys_addr_t start_addr,
+                                                     ram_addr_t size,
+                                                     void *opaque);
 #ifdef CONFIG_XEN
 
-void xen_map_cache_init(void);
+void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                        void *opaque);
 uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock);
 ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
@@ -22,7 +26,8 @@ void xen_invalidate_map_cache(void);
 
 #else
 
-static inline void xen_map_cache_init(void)
+static inline void xen_map_cache_init(phys_offset_to_gaddr_t f,
+                                      void *opaque)
 {
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEW-0007Ji-P9; Tue, 28 Feb 2012 15:44:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEV-0007JE-KM
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23584 invoked from network); 28 Feb 2012 15:44:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523378"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-9F; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:32 +0000
Message-ID: <1330444295-8859-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 3/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 5b2b84c..341775b 100644
--- a/vl.c
+++ b/vl.c
@@ -3099,6 +3099,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3596,7 +3597,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEW-0007Ji-P9; Tue, 28 Feb 2012 15:44:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEV-0007JE-KM
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23584 invoked from network); 28 Feb 2012 15:44:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523378"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-9F; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:32 +0000
Message-ID: <1330444295-8859-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 3/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 5b2b84c..341775b 100644
--- a/vl.c
+++ b/vl.c
@@ -3099,6 +3099,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3596,7 +3597,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEY-0007KG-Gb; Tue, 28 Feb 2012 15:44:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEW-0007JI-TG
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23654 invoked from network); 28 Feb 2012 15:44:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523380"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-8i; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:31 +0000
Message-ID: <1330444295-8859-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 2/6] Introduce "save_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

- add an "is_ram" flag to SaveStateEntry;

- add an "is_ram" parameter to register_savevm_live;

- introduce a "save_devices" monitor command that can be used to save
the state of non-ram devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 block-migration.c |    2 +-
 hmp-commands.hx   |   14 ++++++++++
 qmp-commands.hx   |   17 ++++++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    2 +-
 vmstate.h         |    1 +
 7 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 4467468..d283fd0 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -722,6 +722,6 @@ void blk_mig_init(void)
     QSIMPLEQ_INIT(&block_mig_state.bmds_list);
     QSIMPLEQ_INIT(&block_mig_state.blk_list);
 
-    register_savevm_live(NULL, "block", 0, 1, block_set_params,
+    register_savevm_live(NULL, "block", 0, 1, 0, block_set_params,
                          block_save_live, NULL, block_load, &block_mig_state);
 }
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 64b3656..873abc9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -280,6 +280,20 @@ a snapshot with the same tag or ID, it is replaced. More info at
 ETEXI
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .mhandler.cmd_new = do_save_device_state,
+    },
+
+STEXI
+@item save_devices @var{filename}
+@findex save_devices
+Save the state of non-ram devices.
+ETEXI
+
+    {
         .name       = "loadvm",
         .args_type  = "name:s",
         .params     = "tag|id",
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 705f704..619d9de 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -444,6 +444,23 @@ Note: inject-nmi is only supported for x86 guest currently, it will
 EQMP
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .user_print = monitor_user_noop,	
+    .mhandler.cmd_new = do_save_device_state,
+    },
+
+SQMP
+save_devices
+-------
+
+Save the state of non-ram devices.
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/savevm.c b/savevm.c
index 80be1ff..d0e62bb 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
     void *opaque;
     CompatEntry *compat;
     int no_migrate;
+    int is_ram;
 } SaveStateEntry;
 
 
@@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
                          SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
@@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
     se->opaque = opaque;
     se->vmsd = NULL;
     se->no_migrate = 0;
+    se->is_ram = is_ram;
 
     if (dev && dev->parent_bus && dev->parent_bus->info->get_dev_path) {
         char *id = dev->parent_bus->info->get_dev_path(dev);
@@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
                     LoadStateHandler *load_state,
                     void *opaque)
 {
-    return register_savevm_live(dev, idstr, instance_id, version_id,
+    return register_savevm_live(dev, idstr, instance_id, version_id, 0,
                                 NULL, NULL, save_state, load_state, opaque);
 }
 
@@ -1728,6 +1731,43 @@ out:
     return ret;
 }
 
+static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
+{
+    SaveStateEntry *se;
+
+    qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+    qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+    cpu_synchronize_all_states();
+
+    QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+        int len;
+
+        if (se->is_ram)
+            continue;
+        if (se->save_state == NULL && se->vmsd == NULL)
+            continue;
+
+        /* Section type */
+        qemu_put_byte(f, QEMU_VM_SECTION_FULL);
+        qemu_put_be32(f, se->section_id);
+
+        /* ID string */
+        len = strlen(se->idstr);
+        qemu_put_byte(f, len);
+        qemu_put_buffer(f, (uint8_t *)se->idstr, len);
+
+        qemu_put_be32(f, se->instance_id);
+        qemu_put_be32(f, se->version_id);
+
+        vmstate_save(f, se);
+    }
+
+    qemu_put_byte(f, QEMU_VM_EOF);
+
+    return qemu_file_get_error(f);
+}
+
 static SaveStateEntry *find_se(const char *idstr, int instance_id)
 {
     SaveStateEntry *se;
@@ -2109,6 +2149,36 @@ void do_savevm(Monitor *mon, const QDict *qdict)
         vm_start();
 }
 
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    int ret;
+    QEMUFile *f;
+    int saved_vm_running;
+    const char *filename = qdict_get_try_str(qdict, "filename");
+
+    saved_vm_running = runstate_is_running();
+    vm_stop(RUN_STATE_SAVE_VM);
+
+    f = qemu_fopen(filename, "wb");
+    if (!f) {
+        monitor_printf(mon, "Could not open VM state file\n");
+        ret = -1;
+        goto the_end;
+    }
+    ret = qemu_save_device_state(mon, f);
+    qemu_fclose(f);
+    if (ret < 0) {
+        monitor_printf(mon, "Error %d while writing VM\n", ret);
+        goto the_end;
+    }
+    ret = 0;
+
+ the_end:
+    if (saved_vm_running)
+        vm_start();
+    return ret;
+}
+
 int load_vmstate(const char *name)
 {
     BlockDriverState *bs, *bs_vm_state;
diff --git a/sysemu.h b/sysemu.h
index 98118cc..f4d5bf4 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -70,6 +70,7 @@ void qemu_remove_exit_notifier(Notifier *notify);
 void qemu_add_machine_init_done_notifier(Notifier *notify);
 
 void do_savevm(Monitor *mon, const QDict *qdict);
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data);
 int load_vmstate(const char *name);
 void do_delvm(Monitor *mon, const QDict *qdict);
 void do_info_snapshots(Monitor *mon);
diff --git a/vl.c b/vl.c
index 1d4c350..5b2b84c 100644
--- a/vl.c
+++ b/vl.c
@@ -3393,7 +3393,7 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+    register_savevm_live(NULL, "ram", 0, 4, 1, NULL, ram_save_live, NULL,
                          ram_load, NULL);
 
     if (nb_numa_nodes > 0) {
diff --git a/vmstate.h b/vmstate.h
index 9d3c49c..3cef117 100644
--- a/vmstate.h
+++ b/vmstate.h
@@ -44,6 +44,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
                          SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEY-0007KG-Gb; Tue, 28 Feb 2012 15:44:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEW-0007JI-TG
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23654 invoked from network); 28 Feb 2012 15:44:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523380"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-8i; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:31 +0000
Message-ID: <1330444295-8859-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 2/6] Introduce "save_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

- add an "is_ram" flag to SaveStateEntry;

- add an "is_ram" parameter to register_savevm_live;

- introduce a "save_devices" monitor command that can be used to save
the state of non-ram devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 block-migration.c |    2 +-
 hmp-commands.hx   |   14 ++++++++++
 qmp-commands.hx   |   17 ++++++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    2 +-
 vmstate.h         |    1 +
 7 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 4467468..d283fd0 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -722,6 +722,6 @@ void blk_mig_init(void)
     QSIMPLEQ_INIT(&block_mig_state.bmds_list);
     QSIMPLEQ_INIT(&block_mig_state.blk_list);
 
-    register_savevm_live(NULL, "block", 0, 1, block_set_params,
+    register_savevm_live(NULL, "block", 0, 1, 0, block_set_params,
                          block_save_live, NULL, block_load, &block_mig_state);
 }
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 64b3656..873abc9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -280,6 +280,20 @@ a snapshot with the same tag or ID, it is replaced. More info at
 ETEXI
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .mhandler.cmd_new = do_save_device_state,
+    },
+
+STEXI
+@item save_devices @var{filename}
+@findex save_devices
+Save the state of non-ram devices.
+ETEXI
+
+    {
         .name       = "loadvm",
         .args_type  = "name:s",
         .params     = "tag|id",
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 705f704..619d9de 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -444,6 +444,23 @@ Note: inject-nmi is only supported for x86 guest currently, it will
 EQMP
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .user_print = monitor_user_noop,	
+    .mhandler.cmd_new = do_save_device_state,
+    },
+
+SQMP
+save_devices
+-------
+
+Save the state of non-ram devices.
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/savevm.c b/savevm.c
index 80be1ff..d0e62bb 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
     void *opaque;
     CompatEntry *compat;
     int no_migrate;
+    int is_ram;
 } SaveStateEntry;
 
 
@@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
                          SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
@@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
     se->opaque = opaque;
     se->vmsd = NULL;
     se->no_migrate = 0;
+    se->is_ram = is_ram;
 
     if (dev && dev->parent_bus && dev->parent_bus->info->get_dev_path) {
         char *id = dev->parent_bus->info->get_dev_path(dev);
@@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
                     LoadStateHandler *load_state,
                     void *opaque)
 {
-    return register_savevm_live(dev, idstr, instance_id, version_id,
+    return register_savevm_live(dev, idstr, instance_id, version_id, 0,
                                 NULL, NULL, save_state, load_state, opaque);
 }
 
@@ -1728,6 +1731,43 @@ out:
     return ret;
 }
 
+static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
+{
+    SaveStateEntry *se;
+
+    qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+    qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+    cpu_synchronize_all_states();
+
+    QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+        int len;
+
+        if (se->is_ram)
+            continue;
+        if (se->save_state == NULL && se->vmsd == NULL)
+            continue;
+
+        /* Section type */
+        qemu_put_byte(f, QEMU_VM_SECTION_FULL);
+        qemu_put_be32(f, se->section_id);
+
+        /* ID string */
+        len = strlen(se->idstr);
+        qemu_put_byte(f, len);
+        qemu_put_buffer(f, (uint8_t *)se->idstr, len);
+
+        qemu_put_be32(f, se->instance_id);
+        qemu_put_be32(f, se->version_id);
+
+        vmstate_save(f, se);
+    }
+
+    qemu_put_byte(f, QEMU_VM_EOF);
+
+    return qemu_file_get_error(f);
+}
+
 static SaveStateEntry *find_se(const char *idstr, int instance_id)
 {
     SaveStateEntry *se;
@@ -2109,6 +2149,36 @@ void do_savevm(Monitor *mon, const QDict *qdict)
         vm_start();
 }
 
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    int ret;
+    QEMUFile *f;
+    int saved_vm_running;
+    const char *filename = qdict_get_try_str(qdict, "filename");
+
+    saved_vm_running = runstate_is_running();
+    vm_stop(RUN_STATE_SAVE_VM);
+
+    f = qemu_fopen(filename, "wb");
+    if (!f) {
+        monitor_printf(mon, "Could not open VM state file\n");
+        ret = -1;
+        goto the_end;
+    }
+    ret = qemu_save_device_state(mon, f);
+    qemu_fclose(f);
+    if (ret < 0) {
+        monitor_printf(mon, "Error %d while writing VM\n", ret);
+        goto the_end;
+    }
+    ret = 0;
+
+ the_end:
+    if (saved_vm_running)
+        vm_start();
+    return ret;
+}
+
 int load_vmstate(const char *name)
 {
     BlockDriverState *bs, *bs_vm_state;
diff --git a/sysemu.h b/sysemu.h
index 98118cc..f4d5bf4 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -70,6 +70,7 @@ void qemu_remove_exit_notifier(Notifier *notify);
 void qemu_add_machine_init_done_notifier(Notifier *notify);
 
 void do_savevm(Monitor *mon, const QDict *qdict);
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data);
 int load_vmstate(const char *name);
 void do_delvm(Monitor *mon, const QDict *qdict);
 void do_info_snapshots(Monitor *mon);
diff --git a/vl.c b/vl.c
index 1d4c350..5b2b84c 100644
--- a/vl.c
+++ b/vl.c
@@ -3393,7 +3393,7 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+    register_savevm_live(NULL, "ram", 0, 4, 1, NULL, ram_save_live, NULL,
                          ram_load, NULL);
 
     if (nb_numa_nodes > 0) {
diff --git a/vmstate.h b/vmstate.h
index 9d3c49c..3cef117 100644
--- a/vmstate.h
+++ b/vmstate.h
@@ -44,6 +44,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
                          SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEY-0007K1-4q; Tue, 28 Feb 2012 15:44:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEW-0007JF-5Y
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23629 invoked from network); 28 Feb 2012 15:44:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523379"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-6q; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:30 +0000
Message-ID: <1330444295-8859-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 1/6] cirrus_vga: do not reset videoram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 no need to set the videoram to 0xff in cirrus_reset, because it
is the BIOS' job.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 4edcb94..afedaa4 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2767,10 +2767,6 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
-
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEY-0007K1-4q; Tue, 28 Feb 2012 15:44:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEW-0007JF-5Y
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23629 invoked from network); 28 Feb 2012 15:44:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523379"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-6q; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:30 +0000
Message-ID: <1330444295-8859-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 1/6] cirrus_vga: do not reset videoram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 no need to set the videoram to 0xff in cirrus_reset, because it
is the BIOS' job.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 4edcb94..afedaa4 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2767,10 +2767,6 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
-
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEZ-0007Kb-33; Tue, 28 Feb 2012 15:44:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEX-0007JM-Ep
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23676 invoked from network); 28 Feb 2012 15:44:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523381"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-B0; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:35 +0000
Message-ID: <1330444295-8859-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 6/6] xen: do not allocate RAM during
	INMIGRATE runstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Anthony PERARD <anthony.perard@citrix.com>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 972cffd..10d53d1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+                " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+                __func__, size, ram_addr); 
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEZ-0007Kb-33; Tue, 28 Feb 2012 15:44:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEX-0007JM-Ep
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:44:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330443888!16237397!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23676 invoked from network); 28 Feb 2012 15:44:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:44:51 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523381"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-B0; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:35 +0000
Message-ID: <1330444295-8859-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 6/6] xen: do not allocate RAM during
	INMIGRATE runstate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Anthony PERARD <anthony.perard@citrix.com>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 972cffd..10d53d1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+                " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+                __func__, size, ram_addr); 
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEv-0007Qf-Sq; Tue, 28 Feb 2012 15:45:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEt-0007OY-P8
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:45:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330443890!15259421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30156 invoked from network); 28 Feb 2012 15:44:52 -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;
	28 Feb 2012 15:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523382"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-9t; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:33 +0000
Message-ID: <1330444295-8859-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 4/6] xen: record physmap changes to
	xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b0ed1ed..f2cad82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -65,7 +65,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
-    MemoryRegion *mr;
+    char *name;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -237,6 +237,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -275,6 +276,7 @@ go_physmap:
 
     physmap->start_addr = start_addr;
     physmap->size = size;
+    physmap->name = (char *)mr->name;
     physmap->phys_offset = phys_offset;
 
     QLIST_INSERT_HEAD(&state->physmap, physmap, list);
@@ -283,6 +285,30 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    if (mr->name) {
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                xen_domid, (uint64_t)phys_offset);
+        if (!xs_write(state->xenstore, 0, path, mr->name, strlen(mr->name))) {
+            return -1;
+        }
+    }
+
     return 0;
 }
 
@@ -911,6 +937,55 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/name",
+                xen_domid, entries[i]);
+        physmap->name = xs_read(state->xenstore, 0, path, &len);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -986,6 +1061,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:45:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PEv-0007Qf-Sq; Tue, 28 Feb 2012 15:45:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PEt-0007OY-P8
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:45:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330443890!15259421!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30156 invoked from network); 28 Feb 2012 15:44:52 -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;
	28 Feb 2012 15:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,496,1325480400"; d="scan'208";a="22523382"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:44:48 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:44:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PEI-00083u-9t; Tue, 28 Feb 2012 15:44:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Tue, 28 Feb 2012 15:51:33 +0000
Message-ID: <1330444295-8859-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 4/6] xen: record physmap changes to
	xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b0ed1ed..f2cad82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -65,7 +65,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
-    MemoryRegion *mr;
+    char *name;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -237,6 +237,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -275,6 +276,7 @@ go_physmap:
 
     physmap->start_addr = start_addr;
     physmap->size = size;
+    physmap->name = (char *)mr->name;
     physmap->phys_offset = phys_offset;
 
     QLIST_INSERT_HEAD(&state->physmap, physmap, list);
@@ -283,6 +285,30 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    if (mr->name) {
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                xen_domid, (uint64_t)phys_offset);
+        if (!xs_write(state->xenstore, 0, path, mr->name, strlen(mr->name))) {
+            return -1;
+        }
+    }
+
     return 0;
 }
 
@@ -911,6 +937,55 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/name",
+                xen_domid, entries[i]);
+        physmap->name = xs_read(state->xenstore, 0, path, &len);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -986,6 +1061,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:48:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PHO-00081l-HU; Tue, 28 Feb 2012 15:47:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1S2PHJ-00080U-25
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:47:50 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330444005!53722121!1
X-Originating-IP: [70.38.127.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29517 invoked from network); 28 Feb 2012 15:46:45 -0000
Received: from mail2.malak.privatedns.com (HELO mail.corp.iweb.com)
	(70.38.127.104) by server-3.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 15:46:45 -0000
Received: (qmail 26537 invoked by uid 509); 28 Feb 2012 15:47:44 -0000
Received: from fw.corp.privatedns.com (HELO poste-125.local)
	(mgagne@iweb.com@70.38.99.5)
	by mail.corp.iweb.com with SMTP; 28 Feb 2012 15:47:44 -0000
Message-ID: <4F4CF71F.1000204@iweb.com>
Date: Tue, 28 Feb 2012 10:47:43 -0500
From: =?UTF-8?B?TWF0aGlldSBHYWduw6k=?= <mgagne@iweb.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:11.0) Gecko/20120222 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<4F4CEDD2.7080403@iweb.com>
	<1330442470.31269.187.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330442470.31269.187.camel@zakaz.uk.xensource.com>
X-TagToolbar-Keys: D20120228104743214
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

T24gMi8yOC8xMiAxMDoyMSBBTSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFR1ZSwgMjAxMi0w
Mi0yOCBhdCAxNTowOCArMDAwMCwgTWF0aGlldSBHYWduw6kgd3JvdGU6Cj4+Cj4+IFdpbGwgdGhl
cmUgYmUgc3VwcG9ydCBmb3IgcmF0ZSBsaW1pdGluZyBmb3IgdmlmIGFzIHRoZXJlIGlzIGluIHht
L3hlbmQ/Cj4+Cj4+IFRoZSBoZWxwIGZvciB0aGUgY29tbWFuZCAibmV0d29yay1hdHRhY2giIHNo
b3dzIHN1cHBvcnQgZm9yICJyYXRlIi4KPj4gVW5mb3J0dW5hdGVseSwgYW4gZXJyb3Igb2NjdXJz
IHdoZW4gdXNpbmcgdGhlICJyYXRlIiBwYXJhbWV0ZXI6Cj4+ICJ0aGUgcmF0ZSBwYXJhbWV0ZXIg
Zm9yIHZpZnMgaXMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWQiCj4KPiBJIHRoaW5rIHRoaXMgb3Vn
aHQgdG8gYmUgZml4ZWQgYmVmb3JlIDQuMi4KPgo+IEl0IHNob3VsZCBiZSBhIGZhaXJseSBzaW1w
bGUgbWF0dGVyIHRvIHBsdW1iIHRoZSBwYXJhbWV0ZXIgdGhyb3VnaCB0bwo+IHRoZSB1bmRlcmx5
aW5nIHhlbnN0b3JlIGtleS4gSWYgeW91IGZlZWwgdXAgdG8gY3JlYXRpbmcgYSBwYXRjaCBJJ2Qg
YmUKPiBoYXBweSB0byBnaXZlIHNvbWUgZ3VpZGFuY2UuCj4KClNvbWVvbmUgYWxyZWFkeSBwcm9w
b3NlZCBbMV0gYSBwYXRjaCB3aGljaCBhY2NlcHQgcmF0ZSBpbiB0aGUgZm9ybSAKImtiX3Blcl9z
ZWMsdGltZXNsaWNlX3VzZWMiLiBIb3dldmVyIGl0IGdvdCByZWplY3RlZCBbMV0gYmVjYXVzZSB4
bS94ZW5kIAphY2NlcHRzIHRoaXMgc3ludGF4ICgxTWIvc0AxbXMpIGluc3RlYWQgYW5kIGJhY2t3
YXJkIGNvbXBhdGliaWxpdHkgCnNob3VsZCBiZSBwcmVzZXJ2ZWQuCgpXaGF0IHNob3VsZCBiZSB0
aGUgc3ludGF4IGZvciB0aGlzIHBhcmFtZXRlcj8KClsxXSBodHRwOi8vbGlzdHMueGVuLm9yZy9h
cmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTAzL21zZzAxOTYzLmh0bWwKWzJdIGh0dHA6Ly9s
aXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTEtMDMvbXNnMDE5NzguaHRt
bAoKLS0gCk1hdGhpZXUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:48:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:48:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PHO-00081l-HU; Tue, 28 Feb 2012 15:47:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mgagne@iweb.com>) id 1S2PHJ-00080U-25
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:47:50 +0000
X-Env-Sender: mgagne@iweb.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330444005!53722121!1
X-Originating-IP: [70.38.127.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29517 invoked from network); 28 Feb 2012 15:46:45 -0000
Received: from mail2.malak.privatedns.com (HELO mail.corp.iweb.com)
	(70.38.127.104) by server-3.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 15:46:45 -0000
Received: (qmail 26537 invoked by uid 509); 28 Feb 2012 15:47:44 -0000
Received: from fw.corp.privatedns.com (HELO poste-125.local)
	(mgagne@iweb.com@70.38.99.5)
	by mail.corp.iweb.com with SMTP; 28 Feb 2012 15:47:44 -0000
Message-ID: <4F4CF71F.1000204@iweb.com>
Date: Tue, 28 Feb 2012 10:47:43 -0500
From: =?UTF-8?B?TWF0aGlldSBHYWduw6k=?= <mgagne@iweb.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:11.0) Gecko/20120222 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<4F4CEDD2.7080403@iweb.com>
	<1330442470.31269.187.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330442470.31269.187.camel@zakaz.uk.xensource.com>
X-TagToolbar-Keys: D20120228104743214
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

T24gMi8yOC8xMiAxMDoyMSBBTSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIFR1ZSwgMjAxMi0w
Mi0yOCBhdCAxNTowOCArMDAwMCwgTWF0aGlldSBHYWduw6kgd3JvdGU6Cj4+Cj4+IFdpbGwgdGhl
cmUgYmUgc3VwcG9ydCBmb3IgcmF0ZSBsaW1pdGluZyBmb3IgdmlmIGFzIHRoZXJlIGlzIGluIHht
L3hlbmQ/Cj4+Cj4+IFRoZSBoZWxwIGZvciB0aGUgY29tbWFuZCAibmV0d29yay1hdHRhY2giIHNo
b3dzIHN1cHBvcnQgZm9yICJyYXRlIi4KPj4gVW5mb3J0dW5hdGVseSwgYW4gZXJyb3Igb2NjdXJz
IHdoZW4gdXNpbmcgdGhlICJyYXRlIiBwYXJhbWV0ZXI6Cj4+ICJ0aGUgcmF0ZSBwYXJhbWV0ZXIg
Zm9yIHZpZnMgaXMgY3VycmVudGx5IG5vdCBzdXBwb3J0ZWQiCj4KPiBJIHRoaW5rIHRoaXMgb3Vn
aHQgdG8gYmUgZml4ZWQgYmVmb3JlIDQuMi4KPgo+IEl0IHNob3VsZCBiZSBhIGZhaXJseSBzaW1w
bGUgbWF0dGVyIHRvIHBsdW1iIHRoZSBwYXJhbWV0ZXIgdGhyb3VnaCB0bwo+IHRoZSB1bmRlcmx5
aW5nIHhlbnN0b3JlIGtleS4gSWYgeW91IGZlZWwgdXAgdG8gY3JlYXRpbmcgYSBwYXRjaCBJJ2Qg
YmUKPiBoYXBweSB0byBnaXZlIHNvbWUgZ3VpZGFuY2UuCj4KClNvbWVvbmUgYWxyZWFkeSBwcm9w
b3NlZCBbMV0gYSBwYXRjaCB3aGljaCBhY2NlcHQgcmF0ZSBpbiB0aGUgZm9ybSAKImtiX3Blcl9z
ZWMsdGltZXNsaWNlX3VzZWMiLiBIb3dldmVyIGl0IGdvdCByZWplY3RlZCBbMV0gYmVjYXVzZSB4
bS94ZW5kIAphY2NlcHRzIHRoaXMgc3ludGF4ICgxTWIvc0AxbXMpIGluc3RlYWQgYW5kIGJhY2t3
YXJkIGNvbXBhdGliaWxpdHkgCnNob3VsZCBiZSBwcmVzZXJ2ZWQuCgpXaGF0IHNob3VsZCBiZSB0
aGUgc3ludGF4IGZvciB0aGlzIHBhcmFtZXRlcj8KClsxXSBodHRwOi8vbGlzdHMueGVuLm9yZy9h
cmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTAzL21zZzAxOTYzLmh0bWwKWzJdIGh0dHA6Ly9s
aXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTEtMDMvbXNnMDE5NzguaHRt
bAoKLS0gCk1hdGhpZXUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2PIM-0008Ef-G4; Tue, 28 Feb 2012 15:48:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PIK-0008Dl-V3
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:48:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330444120!11490085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 28 Feb 2012 15:48:46 -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 Feb 2012 15:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10987418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:48:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 15:48:40 +0000
Date: Tue, 28 Feb 2012 15:55:19 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

Important note: the second and third patches only make sense if the
corresponding QEMU's patches[1] are accepted.


[1] http://marc.info/?l=qemu-devel&m=133044385500538&w=2


Changes in v5:

- rebased on "arm: lr register in hyp mode is really LR_usr.".



Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_dom_boot.c       |    8 --
 tools/libxc/xc_domain_restore.c |   46 ++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 ++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  143 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +---------------------
 tools/xcutils/xc_restore.c      |    2 +-
 9 files changed, 222 insertions(+), 102 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2PIM-0008Ef-G4; Tue, 28 Feb 2012 15:48:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2PIK-0008Dl-V3
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:48:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330444120!11490085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 28 Feb 2012 15:48:46 -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 Feb 2012 15:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10987418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:48:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 15:48:40 +0000
Date: Tue, 28 Feb 2012 15:55:19 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 0/3] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

Important note: the second and third patches only make sense if the
corresponding QEMU's patches[1] are accepted.


[1] http://marc.info/?l=qemu-devel&m=133044385500538&w=2


Changes in v5:

- rebased on "arm: lr register in hyp mode is really LR_usr.".



Changes in v4:

- addressed Shriram's comments about the first patch: saving/restoring
toolstack extra information should work we Remus too now;

- added a new patch to use QMP "save_devices" command rather than
"migrate" to save QEMU's device state.



Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (3):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap
      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save

 tools/libxc/xc_dom_boot.c       |    8 --
 tools/libxc/xc_domain_restore.c |   46 ++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 ++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  143 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/libxl_internal.h    |    2 +-
 tools/libxl/libxl_qmp.c         |   82 +---------------------
 tools/xcutils/xc_restore.c      |    2 +-
 9 files changed, 222 insertions(+), 102 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:50:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PJY-0008Qd-RJ; Tue, 28 Feb 2012 15:50:08 +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 1S2PJW-0008Oz-HY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:50:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330444174!65482206!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5098 invoked from network); 28 Feb 2012 15:49:36 -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;
	28 Feb 2012 15:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22523626"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:49:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:49:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PJI-00088j-D0; Tue, 28 Feb 2012 15:49:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 15:56:45 +0000
Message-ID: <1330444605-9238-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 3/3] libxl_qmp: remove
	libxl__qmp_migrate, introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "save_devices" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "save_devices".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f53ef78..2e65e7b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -805,18 +805,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 46e131a..797131b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1005,7 +1005,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 43fd134..2978ece 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -538,52 +538,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -817,34 +771,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -854,23 +782,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "save_devices", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:50:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PJY-0008Qd-RJ; Tue, 28 Feb 2012 15:50:08 +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 1S2PJW-0008Oz-HY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:50:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330444174!65482206!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5098 invoked from network); 28 Feb 2012 15:49:36 -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;
	28 Feb 2012 15:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22523626"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:49:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:49:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PJI-00088j-D0; Tue, 28 Feb 2012 15:49:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 15:56:45 +0000
Message-ID: <1330444605-9238-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 3/3] libxl_qmp: remove
	libxl__qmp_migrate, introduce libxl__qmp_save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Following the recent changes to upstream Qemu, the best monitor command
to suit or needs is "save_devices" rather than "migrate".
This patch removes libxl__qmp_migrate and introduces libxl__qmp_save
instead, that uses "save_devices".

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   11 +-----
 tools/libxl/libxl_internal.h |    2 +-
 tools/libxl/libxl_qmp.c      |   82 ++----------------------------------------
 3 files changed, 5 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f53ef78..2e65e7b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -805,18 +805,9 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
+        ret = libxl__qmp_save(gc, domid, (char *)filename);
         if (ret)
             goto out;
-        close(fd2);
-        fd2 = -1;
         break;
     default:
         return ERROR_INVAL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 46e131a..797131b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1005,7 +1005,7 @@ _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
 /* Save current QEMU state into fd. */
-_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
+_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 43fd134..2978ece 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -538,52 +538,6 @@ out:
     return rc;
 }
 
-static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                       libxl_key_value_list *args,
-                       qmp_callback_t callback, void *opaque,
-                       qmp_request_context *context,
-                       int fd)
-{
-    struct msghdr msg = { 0 };
-    struct cmsghdr *cmsg;
-    char control[CMSG_SPACE(sizeof (fd))];
-    struct iovec iov;
-    char *buf = NULL;
-
-    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
-
-    /* Response data */
-    iov.iov_base = buf;
-    iov.iov_len  = strlen(buf);
-
-    /* compose the message */
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-    msg.msg_control = control;
-    msg.msg_controllen = sizeof (control);
-
-    /* attach open fd */
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
-    *(int *)CMSG_DATA(cmsg) = fd;
-
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
-        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
-                         "Failed to send a QMP message to QEMU.");
-        return ERROR_FAIL;
-    }
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-                            "CRLF", "QMP socket")) {
-        return ERROR_FAIL;
-    }
-
-    return qmp->last_id_used;
-}
-
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -817,34 +771,8 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
-static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
-                     int fd, const char *name)
-{
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
-    int rc = 0;
-
-    parameters = flexarray_make(2, 1);
-    if (!parameters)
-        return ERROR_NOMEM;
-    flexarray_append_pair(parameters, "fdname", (char*)name);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
-        rc = ERROR_FAIL;
-    }
-out:
-    flexarray_free(parameters);
-    return rc;
-}
-
-int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-#define MIGRATE_FD_NAME "dm-migrate"
     libxl__qmp_handler *qmp = NULL;
     flexarray_t *parameters = NULL;
     libxl_key_value_list args = NULL;
@@ -854,23 +782,19 @@ int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
     if (!qmp)
         return ERROR_FAIL;
 
-    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
-    if (rc)
-        goto out;
-
     parameters = flexarray_make(2, 1);
     if (!parameters) {
         rc = ERROR_NOMEM;
         goto out;
     }
-    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
     if (!args) {
         rc = ERROR_NOMEM;
         goto out2;
     }
 
-    rc = qmp_synchronous_send(qmp, "migrate", &args,
+    rc = qmp_synchronous_send(qmp, "save_devices", &args,
                               NULL, NULL, qmp->timeout);
 
 out2:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:50:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PJY-0008QI-AI; Tue, 28 Feb 2012 15:50:08 +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 1S2PJV-0008Ov-Vo
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:50:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330444174!65482206!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5052 invoked from network); 28 Feb 2012 15:49:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:49:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22523625"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:49:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:49:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PJI-00088j-CQ; Tue, 28 Feb 2012 15:49:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 15:56:44 +0000
Message-ID: <1330444605-9238-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1438842..f53ef78 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -385,6 +385,66 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -394,6 +454,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -401,6 +462,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = info->u.hvm.pae;
         no_incr_generationid = info->u.hvm.no_incr_generationid;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -416,7 +479,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -571,6 +634,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -633,6 +762,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:50:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PJY-0008QI-AI; Tue, 28 Feb 2012 15:50:08 +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 1S2PJV-0008Ov-Vo
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:50:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330444174!65482206!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5052 invoked from network); 28 Feb 2012 15:49:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 15:49:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22523625"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:49:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:49:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PJI-00088j-CQ; Tue, 28 Feb 2012 15:49:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 15:56:44 +0000
Message-ID: <1330444605-9238-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 2/3] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1438842..f53ef78 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -385,6 +385,66 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -394,6 +454,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -401,6 +462,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = info->u.hvm.pae;
         no_incr_generationid = info->u.hvm.no_incr_generationid;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -416,7 +479,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -571,6 +634,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -633,6 +762,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:50:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PJX-0008Q6-VY; Tue, 28 Feb 2012 15:50:07 +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 1S2PJV-0008P3-Fo
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:50:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330444174!65482206!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5150 invoked from network); 28 Feb 2012 15:49:36 -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;
	28 Feb 2012 15:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22523627"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:49:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:49:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PJI-00088j-Bl; Tue, 28 Feb 2012 15:49:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 15:56:43 +0000
Message-ID: <1330444605-9238-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 1/3] libxc: introduce
	XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   46 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 06bea86..0869049 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -682,6 +687,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1263,7 +1287,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1311,6 +1336,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1323,6 +1349,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1582,6 +1609,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2032,6 +2063,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 533e702..ca61c6e 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -83,7 +103,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 60ed1d5..1438842 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -416,7 +416,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index e41a133..0235579 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
                             console_evtchn, &console_mfn, 0, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:50:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2PJX-0008Q6-VY; Tue, 28 Feb 2012 15:50:07 +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 1S2PJV-0008P3-Fo
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:50:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330444174!65482206!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5150 invoked from network); 28 Feb 2012 15:49:36 -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;
	28 Feb 2012 15:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22523627"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 10:49:58 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 10:49:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59]
	helo=localhost.localdomain)	by ukmail1.uk.xensource.com with esmtp
	(Exim 4.69)	(envelope-from <stefano.stabellini@eu.citrix.com>)	id
	1S2PJI-00088j-Bl; Tue, 28 Feb 2012 15:49:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 15:56:43 +0000
Message-ID: <1330444605-9238-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH RESEND v5 1/3] libxc: introduce
	XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   46 ++++++++++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 ++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 06bea86..0869049 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -659,6 +659,11 @@ static void tailbuf_free(tailbuf_t *buf)
         tailbuf_free_pv(&buf->u.pv);
 }
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 typedef struct {
     void* pages;
     /* pages is of length nr_physpages, pfn_types is of length nr_pages */
@@ -682,6 +687,8 @@ typedef struct {
     uint64_t acpi_ioport_location;
     uint64_t viridian;
     uint64_t vm_generationid_addr;
+
+    struct toolstack_data_t tdata;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -692,6 +699,10 @@ static int pagebuf_init(pagebuf_t* buf)
 
 static void pagebuf_free(pagebuf_t* buf)
 {
+    if (buf->tdata.data != NULL) {
+        free(buf->tdata.data);
+        buf->tdata.data = NULL;
+    }
     if (buf->pages) {
         free(buf->pages);
         buf->pages = NULL;
@@ -827,6 +838,19 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &buf->tdata.len, sizeof(buf->tdata.len));
+            buf->tdata.data = (uint8_t*) realloc(buf->tdata.data, buf->tdata.len);
+            if ( buf->tdata.data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf->tdata.data, buf->tdata.len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1263,7 +1287,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1311,6 +1336,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1323,6 +1349,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1582,6 +1609,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         ERROR("Error, unknow acpi ioport location (%i)", pagebuf.acpi_ioport_location);
     }
 
+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;
+
     if ( ctx->last_checkpoint )
     {
         // DPRINTF("Last checkpoint, finishing\n");
@@ -2032,6 +2063,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL &&
+            tdata.data != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 533e702..ca61c6e 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -83,7 +103,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 60ed1d5..1438842 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -416,7 +416,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_domid, state->console_port,
                            &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index e41a133..0235579 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
                             console_evtchn, &console_mfn, 0, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:55:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2POY-0000e0-RO; Tue, 28 Feb 2012 15:55:18 +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 1S2POX-0000dt-7s
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:55:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330444447!58571360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17457 invoked from network); 28 Feb 2012 15:54:07 -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;
	28 Feb 2012 15:54:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10987575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:55:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 15:55:15 +0000
Message-ID: <1330444514.4270.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 28 Feb 2012 15:55:14 +0000
In-Reply-To: <4F4CF71F.1000204@iweb.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<4F4CEDD2.7080403@iweb.com>
	<1330442470.31269.187.camel@zakaz.uk.xensource.com>
	<4F4CF71F.1000204@iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTI4IGF0IDE1OjQ3ICswMDAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBPbiAyLzI4LzEyIDEwOjIxIEFNLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPiBPbiBUdWUsIDIw
MTItMDItMjggYXQgMTU6MDggKzAwMDAsIE1hdGhpZXUgR2FnbsOpIHdyb3RlOgo+ID4+Cj4gPj4g
V2lsbCB0aGVyZSBiZSBzdXBwb3J0IGZvciByYXRlIGxpbWl0aW5nIGZvciB2aWYgYXMgdGhlcmUg
aXMgaW4geG0veGVuZD8KPiA+Pgo+ID4+IFRoZSBoZWxwIGZvciB0aGUgY29tbWFuZCAibmV0d29y
ay1hdHRhY2giIHNob3dzIHN1cHBvcnQgZm9yICJyYXRlIi4KPiA+PiBVbmZvcnR1bmF0ZWx5LCBh
biBlcnJvciBvY2N1cnMgd2hlbiB1c2luZyB0aGUgInJhdGUiIHBhcmFtZXRlcjoKPiA+PiAidGhl
IHJhdGUgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkIgo+ID4K
PiA+IEkgdGhpbmsgdGhpcyBvdWdodCB0byBiZSBmaXhlZCBiZWZvcmUgNC4yLgo+ID4KPiA+IEl0
IHNob3VsZCBiZSBhIGZhaXJseSBzaW1wbGUgbWF0dGVyIHRvIHBsdW1iIHRoZSBwYXJhbWV0ZXIg
dGhyb3VnaCB0bwo+ID4gdGhlIHVuZGVybHlpbmcgeGVuc3RvcmUga2V5LiBJZiB5b3UgZmVlbCB1
cCB0byBjcmVhdGluZyBhIHBhdGNoIEknZCBiZQo+ID4gaGFwcHkgdG8gZ2l2ZSBzb21lIGd1aWRh
bmNlLgo+ID4KPiAKPiBTb21lb25lIGFscmVhZHkgcHJvcG9zZWQgWzFdIGEgcGF0Y2ggd2hpY2gg
YWNjZXB0IHJhdGUgaW4gdGhlIGZvcm0gCj4gImtiX3Blcl9zZWMsdGltZXNsaWNlX3VzZWMiLiBI
b3dldmVyIGl0IGdvdCByZWplY3RlZCBbMV0gYmVjYXVzZSB4bS94ZW5kIAo+IGFjY2VwdHMgdGhp
cyBzeW50YXggKDFNYi9zQDFtcykgaW5zdGVhZCBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSAK
PiBzaG91bGQgYmUgcHJlc2VydmVkLgo+IAo+IFdoYXQgc2hvdWxkIGJlIHRoZSBzeW50YXggZm9y
IHRoaXMgcGFyYW1ldGVyPwoKSXQgc2hvdWxkIGJlIHRoZSB4ZW5kIHN5bnRheCB1bmxlc3Mgd2hv
ZXZlciBpbXBsZW1lbnRzIGl0Y2FuIG1ha2UgYQpjb252aW5jaW5nIGFyZ3VtZW50IHdoeSBzb21l
IG90aGVyIHN5bnRheCBpcyAiYmV0dGVyIGVub3VnaCIgdG8ganVzdGlmeQpicmVha2luZyBiYWNr
d2FyZHMgY29ubXBhdC4KCj4gCj4gWzFdIGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0
bWwveGVuLWRldmVsLzIwMTEtMDMvbXNnMDE5NjMuaHRtbAo+IFsyXSBodHRwOi8vbGlzdHMueGVu
Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTAzL21zZzAxOTc4Lmh0bWwKPiAKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 28 15:55:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 15: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 1S2POY-0000e0-RO; Tue, 28 Feb 2012 15:55:18 +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 1S2POX-0000dt-7s
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 15:55:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330444447!58571360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17457 invoked from network); 28 Feb 2012 15:54:07 -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;
	28 Feb 2012 15:54:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10987575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 15:55:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 15:55:15 +0000
Message-ID: <1330444514.4270.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathieu =?ISO-8859-1?Q?Gagn=E9?= <mgagne@iweb.com>
Date: Tue, 28 Feb 2012 15:55:14 +0000
In-Reply-To: <4F4CF71F.1000204@iweb.com>
References: <1330433434.31269.141.camel@zakaz.uk.xensource.com>
	<4F4CEDD2.7080403@iweb.com>
	<1330442470.31269.187.camel@zakaz.uk.xensource.com>
	<4F4CF71F.1000204@iweb.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 4.2 TODO List
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTAyLTI4IGF0IDE1OjQ3ICswMDAwLCBNYXRoaWV1IEdhZ27DqSB3cm90ZToK
PiBPbiAyLzI4LzEyIDEwOjIxIEFNLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPiBPbiBUdWUsIDIw
MTItMDItMjggYXQgMTU6MDggKzAwMDAsIE1hdGhpZXUgR2FnbsOpIHdyb3RlOgo+ID4+Cj4gPj4g
V2lsbCB0aGVyZSBiZSBzdXBwb3J0IGZvciByYXRlIGxpbWl0aW5nIGZvciB2aWYgYXMgdGhlcmUg
aXMgaW4geG0veGVuZD8KPiA+Pgo+ID4+IFRoZSBoZWxwIGZvciB0aGUgY29tbWFuZCAibmV0d29y
ay1hdHRhY2giIHNob3dzIHN1cHBvcnQgZm9yICJyYXRlIi4KPiA+PiBVbmZvcnR1bmF0ZWx5LCBh
biBlcnJvciBvY2N1cnMgd2hlbiB1c2luZyB0aGUgInJhdGUiIHBhcmFtZXRlcjoKPiA+PiAidGhl
IHJhdGUgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkIgo+ID4K
PiA+IEkgdGhpbmsgdGhpcyBvdWdodCB0byBiZSBmaXhlZCBiZWZvcmUgNC4yLgo+ID4KPiA+IEl0
IHNob3VsZCBiZSBhIGZhaXJseSBzaW1wbGUgbWF0dGVyIHRvIHBsdW1iIHRoZSBwYXJhbWV0ZXIg
dGhyb3VnaCB0bwo+ID4gdGhlIHVuZGVybHlpbmcgeGVuc3RvcmUga2V5LiBJZiB5b3UgZmVlbCB1
cCB0byBjcmVhdGluZyBhIHBhdGNoIEknZCBiZQo+ID4gaGFwcHkgdG8gZ2l2ZSBzb21lIGd1aWRh
bmNlLgo+ID4KPiAKPiBTb21lb25lIGFscmVhZHkgcHJvcG9zZWQgWzFdIGEgcGF0Y2ggd2hpY2gg
YWNjZXB0IHJhdGUgaW4gdGhlIGZvcm0gCj4gImtiX3Blcl9zZWMsdGltZXNsaWNlX3VzZWMiLiBI
b3dldmVyIGl0IGdvdCByZWplY3RlZCBbMV0gYmVjYXVzZSB4bS94ZW5kIAo+IGFjY2VwdHMgdGhp
cyBzeW50YXggKDFNYi9zQDFtcykgaW5zdGVhZCBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSAK
PiBzaG91bGQgYmUgcHJlc2VydmVkLgo+IAo+IFdoYXQgc2hvdWxkIGJlIHRoZSBzeW50YXggZm9y
IHRoaXMgcGFyYW1ldGVyPwoKSXQgc2hvdWxkIGJlIHRoZSB4ZW5kIHN5bnRheCB1bmxlc3Mgd2hv
ZXZlciBpbXBsZW1lbnRzIGl0Y2FuIG1ha2UgYQpjb252aW5jaW5nIGFyZ3VtZW50IHdoeSBzb21l
IG90aGVyIHN5bnRheCBpcyAiYmV0dGVyIGVub3VnaCIgdG8ganVzdGlmeQpicmVha2luZyBiYWNr
d2FyZHMgY29ubXBhdC4KCj4gCj4gWzFdIGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0
bWwveGVuLWRldmVsLzIwMTEtMDMvbXNnMDE5NjMuaHRtbAo+IFsyXSBodHRwOi8vbGlzdHMueGVu
Lm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTAzL21zZzAxOTc4Lmh0bWwKPiAKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phc-0001GR-7E; Tue, 28 Feb 2012 16:15:00 +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 1S2Pha-0001GA-QO
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:14:59 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3620 invoked from network); 28 Feb 2012 16:13:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:13:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725576"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:23 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-Rx;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:07 +0000
Message-ID: <1330445653-6030-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 2/8] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index f9d5330..82fa594 100755
--- a/configure
+++ b/configure
@@ -133,6 +133,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -668,6 +669,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1016,6 +1021,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1469,6 +1476,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3606,6 +3628,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phc-0001GR-7E; Tue, 28 Feb 2012 16:15:00 +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 1S2Pha-0001GA-QO
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:14:59 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3620 invoked from network); 28 Feb 2012 16:13:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:13:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725576"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:23 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-Rx;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:07 +0000
Message-ID: <1330445653-6030-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 2/8] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index f9d5330..82fa594 100755
--- a/configure
+++ b/configure
@@ -133,6 +133,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
 attr=""
@@ -668,6 +669,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -1016,6 +1021,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1469,6 +1476,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3606,6 +3628,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phb-0001GG-SB; Tue, 28 Feb 2012 16:14:59 +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 1S2PhZ-0001G5-SO
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:14:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3558 invoked from network); 28 Feb 2012 16:13:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:13:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725580"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-TA;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:09 +0000
Message-ID: <1330445653-6030-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 4/8] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function helps Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    5 +++++
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 38e1de5..f950b4e 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1992,6 +1992,56 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
     return dev->bus->address_space_io;
 }
 
+/* This function checks if an io_region overlap an io_region from another
+ * device.  The io_region to check is provide with (addr, size and type)
+ * A callback can be provide and will be called for every region that is
+ * overlapped.
+ * The return value indicate if the region is overlappsed */
+bool pci_check_bar_overlap(PCIDevice *device,
+                           pcibus_t addr, pcibus_t size, uint8_t type,
+                           void (*c)(void *o, const PCIDevice *d, int index),
+                           void *opaque)
+{
+    PCIBus *bus = device->bus;
+    int i, j;
+    bool rc = false;
+
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        PCIDevice *d = bus->devices[i];
+        if (!d) {
+            continue;
+        }
+
+        if (d->devfn == device->devfn) {
+            continue;
+        }
+
+        /* xxx: This ignores bridges. */
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            PCIIORegion *r = &d->io_regions[j];
+
+            if (!r->size) {
+                continue;
+            }
+            if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+                != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+                continue;
+            }
+
+            if (ranges_overlap(addr, size, r->addr, r->size)) {
+                if (c) {
+                    c(opaque, d, j);
+                    rc = true;
+                } else {
+                    return true;
+                }
+            }
+        }
+    }
+
+    return rc;
+}
+
 static void pci_device_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/hw/pci.h b/hw/pci.h
index 4f19fdb..cbd04e1 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -628,4 +628,9 @@ extern const VMStateDescription vmstate_pci_device;
     .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
 }
 
+bool pci_check_bar_overlap(PCIDevice *dev,
+                           pcibus_t addr, pcibus_t size, uint8_t type,
+                           void (*c)(void *o, const PCIDevice *d, int index),
+                           void *opaque);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phb-0001GG-SB; Tue, 28 Feb 2012 16:14:59 +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 1S2PhZ-0001G5-SO
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:14:58 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3558 invoked from network); 28 Feb 2012 16:13:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:13:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725580"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-TA;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:09 +0000
Message-ID: <1330445653-6030-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 4/8] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function helps Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    5 +++++
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 38e1de5..f950b4e 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1992,6 +1992,56 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
     return dev->bus->address_space_io;
 }
 
+/* This function checks if an io_region overlap an io_region from another
+ * device.  The io_region to check is provide with (addr, size and type)
+ * A callback can be provide and will be called for every region that is
+ * overlapped.
+ * The return value indicate if the region is overlappsed */
+bool pci_check_bar_overlap(PCIDevice *device,
+                           pcibus_t addr, pcibus_t size, uint8_t type,
+                           void (*c)(void *o, const PCIDevice *d, int index),
+                           void *opaque)
+{
+    PCIBus *bus = device->bus;
+    int i, j;
+    bool rc = false;
+
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        PCIDevice *d = bus->devices[i];
+        if (!d) {
+            continue;
+        }
+
+        if (d->devfn == device->devfn) {
+            continue;
+        }
+
+        /* xxx: This ignores bridges. */
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            PCIIORegion *r = &d->io_regions[j];
+
+            if (!r->size) {
+                continue;
+            }
+            if ((type & PCI_BASE_ADDRESS_SPACE_IO)
+                != (r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+                continue;
+            }
+
+            if (ranges_overlap(addr, size, r->addr, r->size)) {
+                if (c) {
+                    c(opaque, d, j);
+                    rc = true;
+                } else {
+                    return true;
+                }
+            }
+        }
+    }
+
+    return rc;
+}
+
 static void pci_device_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *k = DEVICE_CLASS(klass);
diff --git a/hw/pci.h b/hw/pci.h
index 4f19fdb..cbd04e1 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -628,4 +628,9 @@ extern const VMStateDescription vmstate_pci_device;
     .offset     = vmstate_offset_pointer(_state, _field, PCIDevice), \
 }
 
+bool pci_check_bar_overlap(PCIDevice *dev,
+                           pcibus_t addr, pcibus_t size, uint8_t type,
+                           void (*c)(void *o, const PCIDevice *d, int index),
+                           void *opaque);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phi-0001HX-4I; Tue, 28 Feb 2012 16:15:06 +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 1S2Phg-0001Gk-ML
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:05 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3701 invoked from network); 28 Feb 2012 16:14:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:14:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725588"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:25 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph1-00005E-1W;
	Tue, 28 Feb 2012 16:14:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:13 +0000
Message-ID: <1330445653-6030-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 8/8] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   31 ++-
 hw/xen_pci_passthrough.h             |   51 +++
 hw/xen_pci_passthrough_config_init.c |  473 ++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  615 ++++++++++++++++++++++++++++++++++
 6 files changed, 1172 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 0118994..1a407d7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -227,6 +227,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 159d50d..45ad426 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -487,7 +501,15 @@ static void pt_region_update(XenPCIPassthroughState *s,
     int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
 
     bar = pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -682,6 +704,13 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 6a4d416..7bd38df 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -162,6 +162,36 @@ typedef struct XenPTRegGroup {
 
 
 #define PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -174,6 +204,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -249,4 +282,22 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 4e3ecc3..ed19f65 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1020,6 +1020,412 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            PT_LOG(&s->dev, "setup MSI\n");
+            if (pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *value &= ~PCI_MSI_FLAGS_ENABLE;
+    *value |= val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev,
+               "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int rc = 0;
+
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        PT_LOG(&s->dev, "%s MSI-X\n",
+               s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1113,6 +1519,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1153,6 +1602,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1197,6 +1654,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1381,6 +1846,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..dc62493
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,615 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    host_pci_set_word(s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int *ppirq,
+                           bool is_msix,
+                           int msix_entry,
+                           bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                   " (vec: %#x, entry: %#x)\n",
+                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                   is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: %#x)\n",
+           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+               is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                   is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+               is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+               is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        PT_ERR(&s->dev,
+               "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                   "enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *hd = s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+               msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phi-0001HX-4I; Tue, 28 Feb 2012 16:15:06 +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 1S2Phg-0001Gk-ML
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:05 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3701 invoked from network); 28 Feb 2012 16:14:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:14:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725588"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:25 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph1-00005E-1W;
	Tue, 28 Feb 2012 16:14:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:13 +0000
Message-ID: <1330445653-6030-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 8/8] Introduce Xen PCI Passthrough, MSI (3/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   31 ++-
 hw/xen_pci_passthrough.h             |   51 +++
 hw/xen_pci_passthrough_config_init.c |  473 ++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  615 ++++++++++++++++++++++++++++++++++
 6 files changed, 1172 insertions(+), 1 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 0118994..1a407d7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -227,6 +227,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 159d50d..45ad426 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -36,6 +36,20 @@
  *
  *     Write '1'
  *       - Set real bit to '1'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -487,7 +501,15 @@ static void pt_region_update(XenPCIPassthroughState *s,
     int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
 
     bar = pt_bar_from_region(s, mr);
-    if (bar == -1) {
+    if (bar == -1 && (!s->msix || &s->msix->mmio != mr)) {
+        return;
+    }
+
+    if (s->msix && &s->msix->mmio == mr) {
+        if (adding) {
+            s->msix->mmio_base_addr = sec->offset_within_address_space;
+            rc = pt_msix_update_remap(s, s->msix->bar_index);
+        }
         return;
     }
 
@@ -682,6 +704,13 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 6a4d416..7bd38df 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -162,6 +162,36 @@ typedef struct XenPTRegGroup {
 
 
 #define PT_UNASSIGNED_PIRQ (-1)
+typedef struct XenPTMSI {
+    uint16_t flags;
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    bool initialized;  /* when guest MSI is initialized */
+    bool mapped;       /* when pirq is mapped */
+} XenPTMSI;
+
+typedef struct XenPTMSIXEntry {
+    int pirq;
+    uint64_t addr;
+    uint32_t data;
+    uint32_t vector_ctrl;
+    bool updated; /* indicate whether MSI ADDR or DATA is updated */
+} XenPTMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    bool enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    MemoryRegion mmio;
+    void *phys_iomem_base;
+    XenPTMSIXEntry msix_entry[0];
+} XenPTMSIX;
 
 struct XenPCIPassthroughState {
     PCIDevice dev;
@@ -174,6 +204,9 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
     MemoryRegion bar[PCI_NUM_REGIONS - 1];
     MemoryRegion rom;
 
@@ -249,4 +282,22 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+
+static inline bool pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
+{
+    return s->msix && s->msix->bar_index == bar;
+}
+
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 4e3ecc3..ed19f65 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1020,6 +1020,412 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
 };
 
 
+/********************************
+ * MSI Capability
+ */
+
+/* Helper */
+static bool pt_msgdata_check_type(uint32_t offset, uint16_t flags)
+{
+    /* check the offset whether matches the type or not */
+    bool is_32 = (offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT);
+    bool is_64 = (offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT);
+    return is_32 || is_64;
+}
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    XenPTMSI *msi = s->msi;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    msi->flags |= reg_field;
+    msi->ctrl_offset = real_offset;
+    msi->initialized = false;
+    msi->mapped = false;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "Tries to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    msi->flags |= cfg_entry->data & ~PCI_MSI_FLAGS_ENABLE;
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (!msi->initialized) {
+            /* Init physical one */
+            PT_LOG(&s->dev, "setup MSI\n");
+            if (pt_msi_setup(s)) {
+                /* We do not broadcast the error to the framework code, so
+                 * that MSI errors are contained in MSI emulation code and
+                 * QEMU can go on running.
+                 * Guest MSI would be actually not working.
+                 */
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not map MSI.\n");
+                return 0;
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            msi->initialized = true;
+            msi->mapped = true;
+        }
+        msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit */
+    *value &= ~PCI_MSI_FLAGS_ENABLE;
+    *value |= val & PCI_MSI_FLAGS_ENABLE;
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (pt_msgdata_check_type(offset, flags)) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev,
+               "Can't write to the upper address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTMSI *msi = s->msi;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!pt_msgdata_check_type(offset, msi->flags)) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (msi->mapped) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disabling it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    int rc = 0;
+
+    int debug_msix_enabled_old;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        pt_msix_update(s);
+    }
+
+    debug_msix_enabled_old = s->msix->enabled;
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+    if (s->msix->enabled != debug_msix_enabled_old) {
+        PT_LOG(&s->dev, "%s MSI-X\n",
+               s->msix->enabled ? "enable" : "disable");
+    }
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
 /****************************
  * Capabilities
  */
@@ -1113,6 +1519,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check if 64-bit address is capable of per-vector masking */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1153,6 +1602,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1197,6 +1654,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1381,6 +1846,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free all register group entry */
     QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
         /* free all register entry */
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..dc62493
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,615 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static inline uint8_t msi_vector(uint32_t data)
+{
+    return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+static inline uint8_t msi_dest_id(uint32_t addr)
+{
+    return (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+}
+
+static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
+{
+    return addr_hi & 0xffffff00;
+}
+
+static uint32_t msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = msi_dest_id(addr);
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+        (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+        (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+static inline uint64_t msi_addr64(XenPTMSI *msi)
+{
+    return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
+}
+
+static int msi_msix_enable(XenPCIPassthroughState *s,
+                           uint32_t address,
+                           uint16_t flag,
+                           bool enable)
+{
+    uint16_t val = 0;
+
+    if (!address) {
+        return -1;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    if (enable) {
+        val |= flag;
+    } else {
+        val &= ~flag;
+    }
+    host_pci_set_word(s->real_device, address, val);
+    return 0;
+}
+
+static int msi_msix_setup(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int *ppirq,
+                           bool is_msix,
+                           int msix_entry,
+                           bool is_not_mapped)
+{
+    uint8_t gvec = msi_vector(data);
+    int rc = 0;
+
+    assert((!is_msix && msix_entry == 0) || is_msix);
+
+    if (gvec == 0) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
+        if (!*ppirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            *ppirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq %d for MSI%s"
+                   " (vec: %#x, entry: %#x)\n",
+                   *ppirq, is_msix ? "-X" : "", gvec, msix_entry);
+        }
+    }
+
+    if (is_not_mapped) {
+        uint64_t table_base = 0;
+
+        if (is_msix) {
+            table_base = s->msix->table_base;
+        }
+
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, ppirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus,
+                                     msix_entry, table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping of MSI%s (rc: %i, vec: %#x, entry %#x)\n",
+                   is_msix ? "-X" : "", rc, gvec, msix_entry);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+static int msi_msix_update(XenPCIPassthroughState *s,
+                           uint64_t addr,
+                           uint32_t data,
+                           int pirq,
+                           bool is_msix,
+                           int msix_entry,
+                           int *old_pirq)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+    uint64_t table_addr = 0;
+
+    PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x (entry: %#x)\n",
+           is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+
+    if (is_msix) {
+        table_addr = s->msix->mmio_base_addr;
+    }
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  pirq, gflags, table_addr);
+
+    if (rc) {
+        PT_ERR(d, "Updating of MSI%s failed. (rc: %d)\n",
+               is_msix ? "-X" : "", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, *old_pirq)) {
+            PT_ERR(d, "Unmapping of MSI%s pirq %d failed.\n",
+                   is_msix ? "-X" : "", *old_pirq);
+        }
+        *old_pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+static int msi_msix_disable(XenPCIPassthroughState *s,
+                            uint64_t addr,
+                            uint32_t data,
+                            int pirq,
+                            bool is_msix,
+                            bool is_binded)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = msi_vector(data);
+    uint32_t gflags = msi_gflags(data, addr);
+    int rc = 0;
+
+    if (pirq == PT_UNASSIGNED_PIRQ) {
+        return 0;
+    }
+
+    if (is_binded) {
+        PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
+               is_msix ? "-X" : "", pirq, gvec);
+        rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+        if (rc) {
+            PT_ERR(d, "Unbinding of MSI%s failed. (pirq: %d, gvec: %#x)\n",
+                   is_msix ? "-X" : "", pirq, gvec);
+            return rc;
+        }
+    }
+
+    PT_LOG(d, "Unmap MSI%s pirq %d\n", is_msix ? "-X" : "", pirq);
+    rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, pirq);
+    if (rc) {
+        PT_ERR(d, "Unmapping of MSI%s pirq %d failed. (rc: %i)\n",
+               is_msix ? "-X" : "", pirq, rc);
+        return rc;
+    }
+
+    return 0;
+}
+
+/*
+ * MSI virtualization functions
+ */
+
+int pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+{
+    PT_LOG(&s->dev, "%s MSI.\n", enable ? "enabling" : "disabling");
+
+    if (!s->msi) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msi->ctrl_offset, PCI_MSI_FLAGS_ENABLE,
+                           enable);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    int rc = 0;
+    XenPTMSI *msi = s->msi;
+
+    if (msi->initialized) {
+        PT_ERR(&s->dev,
+               "Setup physical MSI when it has been properly initialized.\n");
+        return -1;
+    }
+
+    rc = msi_msix_setup(s, msi_addr64(msi), msi->data, &pirq, false, 0, true);
+    if (rc) {
+        return rc;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number: %d.\n", pirq);
+        return -1;
+    }
+
+    msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+    return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
+                           false, 0, &msi->pirq);
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    XenPTMSI *msi = s->msi;
+
+    if (!msi) {
+        return;
+    }
+
+    pt_msi_set_enable(s, false);
+
+    msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
+                     msi->initialized);
+
+    /* clear msi info */
+    msi->flags = 0;
+    msi->mapped = false;
+    msi->pirq = PT_UNASSIGNED_PIRQ;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static int msix_set_enable(XenPCIPassthroughState *s, bool enabled)
+{
+    PT_LOG(&s->dev, "%s MSI-X.\n", enabled ? "enabling" : "disabling");
+
+    if (!s->msix) {
+        return -1;
+    }
+
+    return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE,
+                           enabled);
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenPTMSIXEntry *entry = NULL;
+    int pirq;
+    int rc;
+
+    if (entry_nr < 0 || entry_nr >= s->msix->total_entries) {
+        return -EINVAL;
+    }
+
+    entry = &s->msix->msix_entry[entry_nr];
+
+    if (!entry->updated) {
+        return 0;
+    }
+
+    pirq = entry->pirq;
+
+    rc = msi_msix_setup(s, entry->data, entry->data, &pirq, true, entry_nr,
+                        entry->pirq == PT_UNASSIGNED_PIRQ);
+    if (rc) {
+        return rc;
+    }
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        entry->pirq = pirq;
+    }
+
+    rc = msi_msix_update(s, entry->addr, entry->data, pirq, true,
+                         entry_nr, &entry->pirq);
+
+    if (!rc) {
+        entry->updated = false;
+    }
+
+    return rc;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    int i = 0;
+
+    msix_set_enable(s, false);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        XenPTMSIXEntry *entry = &s->msix->msix_entry[i];
+
+        msi_msix_disable(s, entry->addr, entry->data, entry->pirq, true, true);
+
+        /* clear MSI-X info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->updated = false;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenPTMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->updated = true;
+        }
+    }
+    return pt_msix_update(s);
+}
+
+static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        return e->addr & UINT32_MAX;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        return e->addr >> 32;
+    case PCI_MSIX_ENTRY_DATA:
+        return e->data;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        return e->vector_ctrl;
+    default:
+        return 0;
+    }
+}
+
+static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
+{
+    switch (offset) {
+    case PCI_MSIX_ENTRY_LOWER_ADDR:
+        e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
+        break;
+    case PCI_MSIX_ENTRY_UPPER_ADDR:
+        e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
+        break;
+    case PCI_MSIX_ENTRY_DATA:
+        e->data = val;
+        break;
+    case PCI_MSIX_ENTRY_VECTOR_CTRL:
+        e->vector_ctrl = val;
+        break;
+    }
+}
+
+static void pci_msix_write(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenPTMSIXEntry *entry;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return;
+    }
+    entry = &msix->msix_entry[entry_nr];
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (offset != PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        const volatile uint32_t *vec_ctrl;
+
+        if (get_entry_value(entry, offset) == val) {
+            return;
+        }
+
+        /*
+         * If Xen intercepts the mask bit access, entry->vec_ctrl may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl = s->msix->phys_iomem_base + entry_nr * PCI_MSIX_ENTRY_SIZE
+            + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+        if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                   "enabled.\n", entry_nr);
+            return;
+        }
+
+        entry->updated = true;
+    }
+
+    set_entry_value(entry, offset, val);
+
+    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
+        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+    }
+}
+
+static uint64_t pci_msix_read(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
+    if (entry_nr < 0) {
+        PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+        return 0;
+    }
+
+    offset = addr % PCI_MSIX_ENTRY_SIZE;
+
+    if (addr < msix->total_entries * PCI_MSIX_ENTRY_SIZE) {
+        return get_entry_value(&msix->msix_entry[entry_nr], offset);
+    } else {
+        /* Pending Bit Array (PBA) */
+        return *(uint32_t *)(msix->phys_iomem_base + addr);
+    }
+}
+
+static const MemoryRegionOps pci_msix_ops = {
+    .read = pci_msix_read,
+    .write = pci_msix_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+        .unaligned = false,
+    },
+};
+
+int pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *hd = s->real_device;
+    PCIDevice *d = &s->dev;
+    int fd = -1;
+    XenPTMSIX *msix = NULL;
+    int rc = 0;
+
+    rc = host_pci_get_byte(hd, base + PCI_CAP_LIST_ID, &id);
+    if (rc) {
+        return rc;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(d, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+    total_entries = control & PCI_MSIX_FLAGS_QSIZE;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenPTMSIXEntry));
+    msix = s->msix;
+
+    msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    memory_region_init_io(&msix->mmio, &pci_msix_ops, s, "xen-pci-pt-msix",
+                          (total_entries * PCI_MSIX_ENTRY_SIZE
+                           + XC_PAGE_SIZE - 1)
+                          & XC_PAGE_MASK);
+
+    host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(d, "get MSI-X table BAR base 0x%"PRIx64"\n", msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        rc = -errno;
+        PT_ERR(d, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(d, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    msix->table_offset_adjust = table_off & 0x0fff;
+    msix->phys_iomem_base =
+        mmap(NULL,
+             total_entries * PCI_MSIX_ENTRY_SIZE + msix->table_offset_adjust,
+             PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             msix->table_base + table_off - msix->table_offset_adjust);
+    close(fd);
+    if (msix->phys_iomem_base == MAP_FAILED) {
+        rc = -errno;
+        PT_ERR(d, "Can't map physical MSI-X table: %s\n", strerror(errno));
+        goto error_out;
+    }
+    msix->phys_iomem_base = (char *)msix->phys_iomem_base
+        + msix->table_offset_adjust;
+
+    PT_LOG(d, "mapping physical MSI-X table to %p\n", msix->phys_iomem_base);
+
+    memory_region_add_subregion_overlap(&s->bar[bar_index], table_off,
+                                        &msix->mmio,
+                                        2); /* Priority: pci default + 1 */
+
+    return 0;
+
+error_out:
+    memory_region_destroy(&msix->mmio);
+    g_free(s->msix);
+    s->msix = NULL;
+    return rc;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+
+    if (!msix) {
+        return;
+    }
+
+    /* unmap the MSI-X memory mapped register area */
+    if (msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+               msix->phys_iomem_base);
+        munmap(msix->phys_iomem_base, msix->total_entries * PCI_MSIX_ENTRY_SIZE
+               + msix->table_offset_adjust);
+    }
+
+    memory_region_del_subregion(&s->bar[msix->bar_index], &msix->mmio);
+    memory_region_destroy(&msix->mmio);
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phk-0001Ij-Pa; Tue, 28 Feb 2012 16:15:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phj-0001H2-Op
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330445698!15949365!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29816 invoked from network); 28 Feb 2012 16:15:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725583"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph1-00005E-0r;
	Tue, 28 Feb 2012 16:14:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:12 +0000
Message-ID: <1330445653-6030-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 7/8] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index ff9d24e..f9a73a8 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 static APICCommonState *local_apics[MAX_APICS + 1];
 
 static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phj-0001I5-OD; Tue, 28 Feb 2012 16:15:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phi-0001Ge-18
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:06 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330445697!15323074!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27403 invoked from network); 28 Feb 2012 16:14: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;
	28 Feb 2012 16:14:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725587"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:25 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-Vc;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:10 +0000
Message-ID: <1330445653-6030-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 5/8] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  730 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  250 ++++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1008 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 646ea00..0118994 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -225,6 +225,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..b5230b9
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,730 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+uint8_t mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0-Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, addr, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t a, uint64_t v, unsigned s)
+{
+    PCIDevice *d = o;
+    /* Same comment as bar_read function */
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", a);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->flags & IORESOURCE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->flags & IORESOURCE_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]);
+
+        PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64" type: %#x)\n",
+               i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    HostPCIDevice *d = s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+static void print_overlapped_region(void *opaque, const PCIDevice *d, int bar)
+{
+    const XenPCIPassthroughState *s = opaque;
+    const PCIIORegion *r = &d->io_regions[bar];
+
+    PT_WARN(&s->dev, "Overlapped to device [%02x:%02x.%x] Region: %i"
+            " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+            bar, r->addr, r->size);
+}
+
+static void pt_region_update(XenPCIPassthroughState *s,
+                             MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+
+    bar = pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    if (pci_check_bar_overlap(d, sec->offset_within_address_space,
+                              sec->size, d->io_regions[bar].type,
+                              &print_overlapped_region, s)) {
+        PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                   adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      PFN(size),
+                                      op);
+        if (rc) {
+            PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                   adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    pt_region_update(s, sec, true);
+}
+
+static void pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    pt_region_update(s, sec, false);
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .region_add = pt_region_add,
+    .region_del = pt_region_del,
+};
+
+/* init */
+
+static int pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, d->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener);
+    PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+           bus, slot, func);
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            PT_ERR(d, "unbinding of interrupt INT%c failed."
+                   " (machine irq: %i, rc: %d)"
+                   " But bravely continuing on..\n",
+                   'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                       " But bravely continuing on..\n",
+                       machine_irq, rc);
+            }
+        }
+    }
+
+    pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pt_initfn;
+    k->exit = pt_unregister_device;
+    k->config_read = pt_pci_read_config;
+    k->config_write = pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..2c5e83d
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,250 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b0ed1ed..d280dc6 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1014,3 +1014,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phk-0001Ij-Pa; Tue, 28 Feb 2012 16:15:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phj-0001H2-Op
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330445698!15949365!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29816 invoked from network); 28 Feb 2012 16:15:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725583"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph1-00005E-0r;
	Tue, 28 Feb 2012 16:14:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:12 +0000
Message-ID: <1330445653-6030-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 7/8] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index ff9d24e..f9a73a8 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -22,19 +22,10 @@
 #include "host-utils.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 static APICCommonState *local_apics[MAX_APICS + 1];
 
 static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phj-0001I5-OD; Tue, 28 Feb 2012 16:15:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phi-0001Ge-18
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:06 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330445697!15323074!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27403 invoked from network); 28 Feb 2012 16:14: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;
	28 Feb 2012 16:14:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725587"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:25 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-Vc;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:10 +0000
Message-ID: <1330445653-6030-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 5/8] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  730 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  250 ++++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1008 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index 646ea00..0118994 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -225,6 +225,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..b5230b9
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,730 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+uint8_t mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+/* Config Space */
+
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = addr;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((addr & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, addr, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t addr,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = addr;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, addr, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, addr, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(addr);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", addr, len);
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, addr);
+    if (reg_grp_entry) {
+        /* check 0-Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0-Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", addr, len);
+            return;
+        }
+    }
+
+    rc = host_pci_get_block(s->real_device, addr, (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    memory_region_transaction_begin();
+    pci_default_write_config(d, addr, val, len);
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (addr & 3) << 3;
+    val <<= (addr & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (addr & 3) << 3;
+
+    memory_region_transaction_commit();
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, addr, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* register regions */
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    /* if this function is called, that probably means that there is a
+     * misconfiguration of the IOMMU. */
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t a, uint64_t v, unsigned s)
+{
+    PCIDevice *d = o;
+    /* Same comment as bar_read function */
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", a);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+        uint8_t type;
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        s->bases[i].access.u = r->base_addr;
+
+        if (r->flags & IORESOURCE_IO) {
+            type = PCI_BASE_ADDRESS_SPACE_IO;
+        } else {
+            type = PCI_BASE_ADDRESS_SPACE_MEMORY;
+            if (r->flags & IORESOURCE_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]);
+
+        PT_LOG(&s->dev, "IO region %i registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64" type: %#x)\n",
+               i, r->size, r->base_addr, type);
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        uint32_t bar_data = 0;
+
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    HostPCIDevice *d = s->real_device;
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr == 0 || r->size == 0) {
+            continue;
+        }
+
+        memory_region_destroy(&s->bar[i]);
+    }
+    if (d->rom.base_addr && d->rom.size) {
+        memory_region_destroy(&s->rom);
+    }
+}
+
+/* region mapping */
+
+static int pt_bar_from_region(XenPCIPassthroughState *s, MemoryRegion *mr)
+{
+    int i = 0;
+
+    for (i = 0; i < PCI_NUM_REGIONS - 1; i++) {
+        if (mr == &s->bar[i]) {
+            return i;
+        }
+    }
+    if (mr == &s->rom) {
+        return PCI_ROM_SLOT;
+    }
+    return -1;
+}
+
+static void print_overlapped_region(void *opaque, const PCIDevice *d, int bar)
+{
+    const XenPCIPassthroughState *s = opaque;
+    const PCIIORegion *r = &d->io_regions[bar];
+
+    PT_WARN(&s->dev, "Overlapped to device [%02x:%02x.%x] Region: %i"
+            " (addr: %#"FMT_PCIBUS", len: %#"FMT_PCIBUS")\n",
+            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+            bar, r->addr, r->size);
+}
+
+static void pt_region_update(XenPCIPassthroughState *s,
+                             MemoryRegionSection *sec, bool adding)
+{
+    PCIDevice *d = &s->dev;
+    MemoryRegion *mr = sec->mr;
+    int bar = -1;
+    int rc;
+    int op = adding ? DPCI_ADD_MAPPING : DPCI_REMOVE_MAPPING;
+
+    bar = pt_bar_from_region(s, mr);
+    if (bar == -1) {
+        return;
+    }
+
+    if (pci_check_bar_overlap(d, sec->offset_within_address_space,
+                              sec->size, d->io_regions[bar].type,
+                              &print_overlapped_region, s)) {
+        PT_WARN(d, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, sec->offset_within_address_space, sec->size);
+    }
+
+    if (d->io_regions[bar].type & PCI_BASE_ADDRESS_SPACE_IO) {
+        uint32_t guest_port = sec->offset_within_address_space;
+        uint32_t machine_port = s->bases[bar].access.pio_base;
+        uint32_t size = sec->size;
+        rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                                      guest_port, machine_port, size,
+                                      op);
+        if (rc) {
+            PT_ERR(d, "%s ioport mapping failed! (rc: %i)\n",
+                   adding ? "create new" : "remove old", rc);
+        }
+    } else {
+        pcibus_t guest_addr = sec->offset_within_address_space;
+        pcibus_t machine_addr = s->bases[bar].access.maddr
+            + sec->offset_within_region;
+        pcibus_t size = sec->size;
+        rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                      PFN(guest_addr + XC_PAGE_SIZE - 1),
+                                      PFN(machine_addr + XC_PAGE_SIZE - 1),
+                                      PFN(size),
+                                      op);
+        if (rc) {
+            PT_ERR(d, "%s mem mapping failed! (rc: %i)\n",
+                   adding ? "create new" : "remove old", rc);
+        }
+    }
+}
+
+static void pt_region_add(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    pt_region_update(s, sec, true);
+}
+
+static void pt_region_del(MemoryListener *l, MemoryRegionSection *sec)
+{
+    XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
+                                             memory_listener);
+
+    pt_region_update(s, sec, false);
+}
+
+static const MemoryListener xen_pt_memory_listener = {
+    .region_add = pt_region_add,
+    .region_del = pt_region_del,
+};
+
+/* init */
+
+static int pt_initfn(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(d, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(d, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(d, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, d->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    s->memory_listener = xen_pt_memory_listener;
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(d, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(d, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (machine_irq != 0) {
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq,
+                                       pci_bus_num(d->bus),
+                                       PCI_SLOT(d->devfn),
+                                       e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(d, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    memory_listener_register(&s->memory_listener);
+    PT_LOG(d, "Real physical device %02x:%02x.%x registered successfuly!\n",
+           bus, slot, func);
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *d)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint8_t machine_irq = s->machine_irq;
+    uint8_t intx = pci_intx(s);
+    int rc;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI,
+                                     pci_bus_num(d->bus),
+                                     PCI_SLOT(s->dev.devfn),
+                                     intx,
+                                     0 /* isa_irq */);
+        if (rc < 0) {
+            PT_ERR(d, "unbinding of interrupt INT%c failed."
+                   " (machine irq: %i, rc: %d)"
+                   " But bravely continuing on..\n",
+                   'a' + intx, machine_irq, rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(d, "unmapping of interrupt %i failed. (rc: %d)"
+                       " But bravely continuing on..\n",
+                       machine_irq, rc);
+            }
+        }
+    }
+
+    pt_unregister_regions(s);
+    memory_listener_unregister(&s->memory_listener);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static Property xen_pci_passthrough_properties[] = {
+    DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pt_initfn;
+    k->exit = pt_unregister_device;
+    k->config_read = pt_pci_read_config;
+    k->config_write = pt_pci_write_config;
+    dc->desc = "Assign an host PCI device with Xen";
+    dc->props = xen_pci_passthrough_properties;
+};
+
+static TypeInfo xen_pci_passthrough_info = {
+    .name = "xen-pci-passthrough",
+    .parent = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(XenPCIPassthroughState),
+    .class_init = xen_pci_passthrough_class_init,
+};
+
+static void xen_pci_passthrough_register_types(void)
+{
+    type_register_static(&xen_pci_passthrough_info);
+}
+
+type_init(xen_pci_passthrough_register_types)
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..2c5e83d
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,250 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+/* Helper */
+#define PFN(x) ((x) >> XC_PAGE_SHIFT)
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data; /* emulated value */
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+#define PT_UNASSIGNED_PIRQ (-1)
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+
+    MemoryListener memory_listener;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the interrupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b0ed1ed..d280dc6 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1014,3 +1014,15 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
     framebuffer = mr;
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phk-0001IW-Be; Tue, 28 Feb 2012 16:15:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phj-0001Gj-06
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330445698!15949365!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29660 invoked from network); 28 Feb 2012 16:15:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725590"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:26 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph1-00005E-07;
	Tue, 28 Feb 2012 16:14:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:11 +0000
Message-ID: <1330445653-6030-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 6/8] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   10 +
 hw/xen_pci_passthrough.h             |    2 +
 hw/xen_pci_passthrough_config_init.c | 1384 ++++++++++++++++++++++++++++++++++
 3 files changed, 1396 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index b5230b9..159d50d 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -591,6 +591,13 @@ static int pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(d, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(d, "no pin interrupt\n");
@@ -689,6 +696,9 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 2c5e83d..6a4d416 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -64,6 +64,8 @@ typedef int (*conf_byte_read)
 #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
 #define PT_PCI_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..4e3ecc3 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,1395 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                int j = 0;
+                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phd-0001Gp-NZ; Tue, 28 Feb 2012 16:15:01 +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 1S2Phb-0001GF-On
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:00 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3661 invoked from network); 28 Feb 2012 16:13:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725577"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-Pa;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:05 +0000
Message-ID: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 0/8] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change since the previous set:
  - rework of the memory mapping of BARs. We now use a memory_listener to update
    a xen memory_mapping when a memory_region is updated.
  - address few comment from Michael in the pci_check_overlap function.
  - fix the handling of the ROM slot.


Change v6-v7:
  - few fix and rebased on master
  - remove of the power management capability, keep the minimum like if it is
    always desactivated.
  - new patch: port of patch from the qemu-xen fork.


Change v5-v6:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.


Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property





Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (4):
  pci_ids: Add INTEL_82599_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 +++++
 hw/host-pci-device.h                 |   75 ++
 hw/pci.c                             |   50 +
 hw/pci.h                             |    5 +
 hw/pci_ids.h                         |    1 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  769 ++++++++++++++
 hw/xen_pci_passthrough.h             |  303 ++++++
 hw/xen_pci_passthrough_config_init.c | 1868 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  615 +++++++++++
 xen-all.c                            |   12 +
 15 files changed, 4041 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phk-0001IW-Be; Tue, 28 Feb 2012 16:15:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phj-0001Gj-06
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:07 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330445698!15949365!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29660 invoked from network); 28 Feb 2012 16:15:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725590"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:26 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph1-00005E-07;
	Tue, 28 Feb 2012 16:14:23 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:11 +0000
Message-ID: <1330445653-6030-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 6/8] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   10 +
 hw/xen_pci_passthrough.h             |    2 +
 hw/xen_pci_passthrough_config_init.c | 1384 ++++++++++++++++++++++++++++++++++
 3 files changed, 1396 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index b5230b9..159d50d 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -591,6 +591,13 @@ static int pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(d, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(d, "no pin interrupt\n");
@@ -689,6 +696,9 @@ static int pt_unregister_device(PCIDevice *d)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     pt_unregister_regions(s);
     memory_listener_unregister(&s->memory_listener);
 
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 2c5e83d..6a4d416 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -64,6 +64,8 @@ typedef int (*conf_byte_read)
 #define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
 #define PT_PCI_BAR_UNMAPPED (-1)
 
+#define PCI_CAP_MAX 48
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..4e3ecc3 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,1395 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    const PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0 || index >= PCI_NUM_REGIONS) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask values depend on the BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+        }
+        break;
+    default:
+        break;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r_size = d->io_regions[PCI_ROM_SLOT].size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    r_size = pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
+                                             uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return flags & PCI_EXP_FLAGS_VERS;
+}
+
+static inline uint8_t get_device_type(XenPCIPassthroughState *s,
+                                      uint32_t offset)
+{
+    uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
+    return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+}
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+    uint32_t reg_field = 0;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* write Power Management Control/Status register */
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t version = get_capability_version(s, base_offset);
+    uint8_t type = get_device_type(s, base_offset);
+    uint8_t pcie_size = 0;
+
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Unsupported device/port type %#x.\n", type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Unsupported capability version %#x.\n", version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    int i;
+    uint8_t *config = s->dev.config;
+    uint32_t reg_field = pci_get_byte(config + real_offset);
+    uint8_t cap_id = 0;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            cap_id = pci_get_byte(config + reg_field + PCI_CAP_LIST_ID);
+            if (pt_emu_reg_grp_tbl[i].grp_id == cap_id) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+
+        /* next capability */
+        reg_field = pci_get_byte(config + reg_field + PCI_CAP_LIST_NEXT);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    unsigned max_cap = PCI_CAP_MAX;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < PCI_CONFIG_HEADER_SIZE) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    int i, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        uint32_t reg_grp_offset = 0;
+        XenPTRegGroup *reg_grp_entry = NULL;
+
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                int j = 0;
+                XenPTRegInfo *reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phd-0001Gp-NZ; Tue, 28 Feb 2012 16:15:01 +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 1S2Phb-0001GF-On
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:00 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330445635!53727191!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3661 invoked from network); 28 Feb 2012 16:13:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725577"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-Pa;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:05 +0000
Message-ID: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 0/8] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:07:00.1".


Change since the previous set:
  - rework of the memory mapping of BARs. We now use a memory_listener to update
    a xen memory_mapping when a memory_region is updated.
  - address few comment from Michael in the pci_check_overlap function.
  - fix the handling of the ROM slot.


Change v6-v7:
  - few fix and rebased on master
  - remove of the power management capability, keep the minimum like if it is
    always desactivated.
  - new patch: port of patch from the qemu-xen fork.


Change v5-v6:
  - msitraslate code have been removed.
  - code for the power management capability is removed, but will be re-added
    for the next version of the patch series as a separate patch.

  - new patch to remove a check in pci_parse_devaddr.
  - use pci_default_config_write, so no more hack to handle the BAR mapping in
    QEMU.
  - improve the code in general (a bit more comprehensible).
  - update to QOM.


Change v4-v5:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)

Change v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.

Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.

Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property





Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (4):
  pci_ids: Add INTEL_82599_VF id.
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 +++++
 hw/host-pci-device.h                 |   75 ++
 hw/pci.c                             |   50 +
 hw/pci.h                             |    5 +
 hw/pci_ids.h                         |    1 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  769 ++++++++++++++
 hw/xen_pci_passthrough.h             |  303 ++++++
 hw/xen_pci_passthrough_config_init.c | 1868 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  615 +++++++++++
 xen-all.c                            |   12 +
 15 files changed, 4041 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phu-0001N2-Ct; Tue, 28 Feb 2012 16:15:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phs-0001Jv-Rv
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:17 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330445708!15302550!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15618 invoked from network); 28 Feb 2012 16:15:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725579"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-QF;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:06 +0000
Message-ID: <1330445653-6030-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 1/8] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..943106a 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:15:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Phu-0001N2-Ct; Tue, 28 Feb 2012 16:15:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phs-0001Jv-Rv
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:17 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330445708!15302550!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15618 invoked from network); 28 Feb 2012 16:15:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:10 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725579"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:24 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-QF;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:06 +0000
Message-ID: <1330445653-6030-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 1/8] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index e8235a7..943106a 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -118,6 +118,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2Phv-0001PJ-Q6; Tue, 28 Feb 2012 16:15:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phu-0001KJ-1O
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330445708!15302550!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15647 invoked from network); 28 Feb 2012 16:15:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725585"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:25 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-SX;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:08 +0000
Message-ID: <1330445653-6030-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 3/8] Introduce HostPCIDevice to access a pci
	device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 68a5641..646ea00 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,6 +223,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 1);
+    if (rc == 0) {
+        *p = buf;
+    }
+    return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 2);
+    if (rc == 0) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 4);
+    if (rc == 0) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+    return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:15:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2Phv-0001PJ-Q6; Tue, 28 Feb 2012 16:15:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2Phu-0001KJ-1O
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:15:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330445708!15302550!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15647 invoked from network); 28 Feb 2012 16:15:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183725585"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 11:14:25 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 11:14:23 -0500
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 1S2Ph0-00005E-SX;
	Tue, 28 Feb 2012 16:14:22 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Tue, 28 Feb 2012 16:14:08 +0000
Message-ID: <1330445653-6030-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
References: <1330445653-6030-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V8 3/8] Introduce HostPCIDevice to access a pci
	device on the host.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 68a5641..646ea00 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,6 +223,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+    uint8_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 1);
+    if (rc == 0) {
+        *p = buf;
+    }
+    return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+    uint16_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 2);
+    if (rc == 0) {
+        *p = le16_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+    uint32_t buf;
+    int rc = host_pci_config_read(d, pos, &buf, 4);
+    if (rc == 0) {
+        *p = le32_to_cpu(buf);
+    }
+    return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+    return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+    data = cpu_to_le16(data);
+    return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+    data = cpu_to_le32(data);
+    return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+    return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:24:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Pqm-0002k8-AU; Tue, 28 Feb 2012 16:24:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2Pqk-0002k3-5R
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:24:26 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330446259!15950738!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM4NjA4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2822 invoked from network); 28 Feb 2012 16:24:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 16:24:20 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 28 Feb 2012 08:24:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112267805"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 28 Feb 2012 08:24:13 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 29 Feb 2012 00:24:11 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 00:24:10 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AQHM9Kz1m4MGy1d3TzK01xgwJYdnxZZSeQog
Date: Tue, 28 Feb 2012 16:24:09 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
	<20120226173458.GB18098@phenom.dumpdata.com>
In-Reply-To: <20120226173458.GB18098@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
>> Liu, Jinsong wrote:
>>> Jan Beulich wrote:
>>>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>>>> --- a/drivers/acpi/Kconfig
>>>>> +++ b/drivers/acpi/Kconfig
>>>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>>>    default y
>>>>  >
>>>>> config ACPI_PROCESSOR_AGGREGATOR
>>>>> -    tristate "Processor Aggregator"
>>>>> +    bool "Processor Aggregator"
>>>> 
>>>> There must be ways to address whatever strange problem you see
>>>> without making this piece of code non-modular.
>>>> 
>>> 
>>> Yes, another approach is x86_init approach, defining acpi_pad_ops at
>>> x86_init.c and overwritten when xen_start_kernel. This patch is just
>>> a RFC patch, to evaluate which approch is more reasonable :-)
>>> 
>> 
>> Have a more think about it, x86_init approach still need to disable
>> acpi_pad module. 
>> Seems we have to set acpi_pad as bool, as long as it need to hook to
>> native acpi_pad fucs/variables. 
> 
> What about the other approach I suggested where there are some
> function overrides in osl.c? Something similar to
> https://lkml.org/lkml/2012/1/17/401, specifically
> https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
> the modules into being built in, but intead have the function table
> already in the kernel (as some form of EXPORT_SYMBOL_GPL or a
> registration function). 
> 

Thanks for the example (it's good itself :-), but per my understanding they are different cases.

In the osl example case, tboot_late_init call acpi_os_set_prepare_sleep to register func, so it works no matter tboot.c built as y/n/m (through currently it's bool).

However, in our case, we just cannot do so. We need
1. predefine a hook to native acpi pad funcs, take effect when static compile stage;
2. when xen init, redirect the hook to xen acpi pad funcs, take effect at running time;
(The point is, we cannot do init twice for native and xen acpi pad, so we have to statically predefine a hook to native acpi_pad)

For the reason above, I think we have to remove acpi_pad module, as long as we need to hook to native acpi_pad funcs. Thoughts?

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 Feb 28 16:24:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Pqm-0002k8-AU; Tue, 28 Feb 2012 16:24:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2Pqk-0002k3-5R
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:24:26 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330446259!15950738!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjM4NjA4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2822 invoked from network); 28 Feb 2012 16:24:20 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 16:24:20 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 28 Feb 2012 08:24:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112267805"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 28 Feb 2012 08:24:13 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 29 Feb 2012 00:24:11 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 00:24:10 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Thread-Index: AQHM9Kz1m4MGy1d3TzK01xgwJYdnxZZSeQog
Date: Tue, 28 Feb 2012 16:24:09 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
	<20120226173458.GB18098@phenom.dumpdata.com>
In-Reply-To: <20120226173458.GB18098@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
>> Liu, Jinsong wrote:
>>> Jan Beulich wrote:
>>>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>>>> --- a/drivers/acpi/Kconfig
>>>>> +++ b/drivers/acpi/Kconfig
>>>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>>>    default y
>>>>  >
>>>>> config ACPI_PROCESSOR_AGGREGATOR
>>>>> -    tristate "Processor Aggregator"
>>>>> +    bool "Processor Aggregator"
>>>> 
>>>> There must be ways to address whatever strange problem you see
>>>> without making this piece of code non-modular.
>>>> 
>>> 
>>> Yes, another approach is x86_init approach, defining acpi_pad_ops at
>>> x86_init.c and overwritten when xen_start_kernel. This patch is just
>>> a RFC patch, to evaluate which approch is more reasonable :-)
>>> 
>> 
>> Have a more think about it, x86_init approach still need to disable
>> acpi_pad module. 
>> Seems we have to set acpi_pad as bool, as long as it need to hook to
>> native acpi_pad fucs/variables. 
> 
> What about the other approach I suggested where there are some
> function overrides in osl.c? Something similar to
> https://lkml.org/lkml/2012/1/17/401, specifically
> https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
> the modules into being built in, but intead have the function table
> already in the kernel (as some form of EXPORT_SYMBOL_GPL or a
> registration function). 
> 

Thanks for the example (it's good itself :-), but per my understanding they are different cases.

In the osl example case, tboot_late_init call acpi_os_set_prepare_sleep to register func, so it works no matter tboot.c built as y/n/m (through currently it's bool).

However, in our case, we just cannot do so. We need
1. predefine a hook to native acpi pad funcs, take effect when static compile stage;
2. when xen init, redirect the hook to xen acpi pad funcs, take effect at running time;
(The point is, we cannot do init twice for native and xen acpi pad, so we have to statically predefine a hook to native acpi_pad)

For the reason above, I think we have to remove acpi_pad module, as long as we need to hook to native acpi_pad funcs. Thoughts?

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 Feb 28 16:47:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2QCV-00032B-J8; Tue, 28 Feb 2012 16:46:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1S2QCT-000324-77
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:46:53 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330447605!8532328!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.8 required=7.0 tests=INFO_TLD,MIME_QP_LONG_LINE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18030 invoked from network); 28 Feb 2012 16:46:46 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:46:46 -0000
Received: by pbcuo5 with SMTP id uo5so2030696pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 08:46:44 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@gmail.com designates
	10.68.203.135 as permitted sender) client-ip=10.68.203.135; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@gmail.com
	designates 10.68.203.135 as permitted sender)
	smtp.mail=rshriram@gmail.com
Received: from mr.google.com ([10.68.203.135])
	by 10.68.203.135 with SMTP id kq7mr9007282pbc.1.1330447604583 (num_hops
	= 1); Tue, 28 Feb 2012 08:46:44 -0800 (PST)
Received: by 10.68.203.135 with SMTP id kq7mr7586651pbc.1.1330447604330;
	Tue, 28 Feb 2012 08:46:44 -0800 (PST)
Received: from [206.12.52.198] ([206.12.52.198])
	by mx.google.com with ESMTPS id y9sm16103184pbi.3.2012.02.28.08.46.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 28 Feb 2012 08:46:43 -0800 (PST)
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <49053115-D19B-4A45-A8ED-A70652D3AF4F@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 28 Feb 2012 08:46:40 -0800
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RESEND v5 0/3] libxl: save/restore qemu
	physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-02-28, at 7:55 AM, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> wrote:

> Hi all,
> this patch series introduces a new xc_save_id called
> XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
> Libxl is going to use the new save_id to save and restore qemu's
> physmap.
> 
> Important note: the second and third patches only make sense if the
> corresponding QEMU's patches[1] are accepted.
> 
> 
> [1] http://marc.info/?l=qemu-devel&m=133044385500538&w=2
> 
> 

Have they been accepted ?

Shriram

> Changes in v5:
> 
> - rebased on "arm: lr register in hyp mode is really LR_usr.".
> 
> 
> 
> Changes in v4:
> 
> - addressed Shriram's comments about the first patch: saving/restoring
> toolstack extra information should work we Remus too now;
> 
> - added a new patch to use QMP "save_devices" command rather than
> "migrate" to save QEMU's device state.
> 
> 
> 
> Changes in v3:
> 
> - rebased the series;
> 
> - xc_domain_restore: read the toolstack data in pagebuf_get_one, call
> the callback at finish_hvm;
> 
> 
> 
> Changes in v2:
> 
> - xc_domain_save frees the buffer allocated by the callback;
> 
> - introduce a version number in the libxl save record;
> 
> - define libxl__physmap_info and use it to read/store information to the
> buffer.
> 
> 
> Stefano Stabellini (3):
>      libxc: introduce XC_SAVE_ID_TOOLSTACK
>      libxl: save/restore qemu's physmap
>      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save
> 
> tools/libxc/xc_dom_boot.c       |    8 --
> tools/libxc/xc_domain_restore.c |   46 ++++++++++++-
> tools/libxc/xc_domain_save.c    |   17 +++++
> tools/libxc/xenguest.h          |   23 ++++++-
> tools/libxc/xg_save_restore.h   |    1 +
> tools/libxl/libxl_dom.c         |  143 ++++++++++++++++++++++++++++++++++++---
> tools/libxl/libxl_internal.h    |    2 +-
> tools/libxl/libxl_qmp.c         |   82 +---------------------
> tools/xcutils/xc_restore.c      |    2 +-
> 9 files changed, 222 insertions(+), 102 deletions(-)
> 
> 
> Cheers,
> 
> Stefano
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:47:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2QCV-00032B-J8; Tue, 28 Feb 2012 16:46:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1S2QCT-000324-77
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:46:53 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330447605!8532328!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=1.8 required=7.0 tests=INFO_TLD,MIME_QP_LONG_LINE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18030 invoked from network); 28 Feb 2012 16:46:46 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:46:46 -0000
Received: by pbcuo5 with SMTP id uo5so2030696pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 08:46:44 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@gmail.com designates
	10.68.203.135 as permitted sender) client-ip=10.68.203.135; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@gmail.com
	designates 10.68.203.135 as permitted sender)
	smtp.mail=rshriram@gmail.com
Received: from mr.google.com ([10.68.203.135])
	by 10.68.203.135 with SMTP id kq7mr9007282pbc.1.1330447604583 (num_hops
	= 1); Tue, 28 Feb 2012 08:46:44 -0800 (PST)
Received: by 10.68.203.135 with SMTP id kq7mr7586651pbc.1.1330447604330;
	Tue, 28 Feb 2012 08:46:44 -0800 (PST)
Received: from [206.12.52.198] ([206.12.52.198])
	by mx.google.com with ESMTPS id y9sm16103184pbi.3.2012.02.28.08.46.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 28 Feb 2012 08:46:43 -0800 (PST)
References: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1202281553010.23091@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <49053115-D19B-4A45-A8ED-A70652D3AF4F@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 28 Feb 2012 08:46:40 -0800
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RESEND v5 0/3] libxl: save/restore qemu
	physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-02-28, at 7:55 AM, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> wrote:

> Hi all,
> this patch series introduces a new xc_save_id called
> XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
> Libxl is going to use the new save_id to save and restore qemu's
> physmap.
> 
> Important note: the second and third patches only make sense if the
> corresponding QEMU's patches[1] are accepted.
> 
> 
> [1] http://marc.info/?l=qemu-devel&m=133044385500538&w=2
> 
> 

Have they been accepted ?

Shriram

> Changes in v5:
> 
> - rebased on "arm: lr register in hyp mode is really LR_usr.".
> 
> 
> 
> Changes in v4:
> 
> - addressed Shriram's comments about the first patch: saving/restoring
> toolstack extra information should work we Remus too now;
> 
> - added a new patch to use QMP "save_devices" command rather than
> "migrate" to save QEMU's device state.
> 
> 
> 
> Changes in v3:
> 
> - rebased the series;
> 
> - xc_domain_restore: read the toolstack data in pagebuf_get_one, call
> the callback at finish_hvm;
> 
> 
> 
> Changes in v2:
> 
> - xc_domain_save frees the buffer allocated by the callback;
> 
> - introduce a version number in the libxl save record;
> 
> - define libxl__physmap_info and use it to read/store information to the
> buffer.
> 
> 
> Stefano Stabellini (3):
>      libxc: introduce XC_SAVE_ID_TOOLSTACK
>      libxl: save/restore qemu's physmap
>      libxl_qmp: remove libxl__qmp_migrate, introduce libxl__qmp_save
> 
> tools/libxc/xc_dom_boot.c       |    8 --
> tools/libxc/xc_domain_restore.c |   46 ++++++++++++-
> tools/libxc/xc_domain_save.c    |   17 +++++
> tools/libxc/xenguest.h          |   23 ++++++-
> tools/libxc/xg_save_restore.h   |    1 +
> tools/libxl/libxl_dom.c         |  143 ++++++++++++++++++++++++++++++++++++---
> tools/libxl/libxl_internal.h    |    2 +-
> tools/libxl/libxl_qmp.c         |   82 +---------------------
> tools/xcutils/xc_restore.c      |    2 +-
> 9 files changed, 222 insertions(+), 102 deletions(-)
> 
> 
> Cheers,
> 
> Stefano
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK5-0003Hn-F0; Tue, 28 Feb 2012 16:54:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Fi-GD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15930 invoked from network); 28 Feb 2012 16:54:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:22 +0000
Message-ID: <1330448064-32267-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Build a flat device tree for dom0 based on the one supplied to Xen.
The following changes are made:

  * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
    bootargs.

  * In all memory nodes, the reg parameters are adjusted to reflect
    the amount of memory dom0 can use.  The p2m is updated using this
    info.

Support for passing ATAGS to dom0 is removed.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile         |    2 +
 xen/arch/arm/domain_build.c   |  238 ++++++++++++++++++++++++++++++++++-------
 xen/arch/arm/kernel.c         |    4 +-
 xen/arch/arm/kernel.h         |    8 +-
 xen/common/device_tree.c      |   44 +++++---
 xen/include/xen/device_tree.h |    8 ++
 6 files changed, 246 insertions(+), 58 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index da5096a..4c9517c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,8 @@ obj-y += vtimer.o
 
 #obj-bin-y += ....o
 
+CFLAGS += -I../../common/libfdt
+
 ifdef CONFIG_DTB_FILE
 obj-y += dtb.o
 AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9240209..ca8c706 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -6,6 +6,11 @@
 #include <xen/sched.h>
 #include <asm/irq.h>
 #include <asm/regs.h>
+#include <xen/errno.h>
+#include <xen/device_tree.h>
+#include <xen/guest_access.h>
+
+#include <libfdt.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -27,43 +32,190 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
     return alloc_vcpu(dom0, 0, 0);
 }
 
-extern void guest_mode_entry(void);
+static void set_memory_reg(struct domain *d, struct kernel_info *dom0,
+                           const void *fdt,
+                           const u32 *cell, int address_cells, int size_cells,
+                           u32 *new_cell, int *len)
+{
+    int reg_size = (address_cells + size_cells) * sizeof(*cell);
+    int l;
+    u64 start;
+    u64 size;
+
+    l = *len;
+
+    while (dom0->unassigned_mem > 0 && l > reg_size
+           && dom0->mem.nr_banks < NR_MEM_BANKS)
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+        if (size > dom0->unassigned_mem)
+            size = dom0->unassigned_mem;
+
+        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
+
+        printk("Populate P2M %#llx->%#llx\n", start, start + size);
+        p2m_populate_ram(d, start, start + size);
+        dom0->mem.bank[dom0->mem.nr_banks].start = start;
+        dom0->mem.bank[dom0->mem.nr_banks].size = size;
+        dom0->unassigned_mem -= size;
+
+        l -= reg_size;
+    }
+
+    *len -= l;
+}
+
+static int write_properties(struct domain *d, struct kernel_info *dom0,
+                            const void *fdt,
+                            int node, const char *name, int depth,
+                            u32 address_cells, u32 size_cells)
+{
+    int prop;
+
+    for (prop = fdt_first_property_offset(fdt, node);
+         prop >= 0;
+         prop = fdt_next_property_offset(fdt, prop))
+    {
+        const struct fdt_property *p;
+        const char *prop_name;
+        const char *prop_data;
+        int prop_len;
+        char *new_data = NULL;
+
+        p = fdt_get_property_by_offset(fdt, prop, NULL);
+        prop_name = fdt_string(fdt, fdt32_to_cpu(p->nameoff));
+        prop_data = p->data;
+        prop_len  = fdt32_to_cpu(p->len);
+
+        /*
+         * In chosen node: replace bootargs with value from
+         * xen,dom0-bootargs.
+         */
+        if (device_tree_node_matches(fdt, node, "chosen")) {
+            if (strcmp(prop_name, "bootargs") == 0)
+                continue;
+            if (strcmp(prop_name, "xen,dom0-bootargs") == 0)
+                prop_name = "bootargs";
+        }
+
+        /*
+         * In a memory node: adjust reg property.
+         */
+        if (device_tree_node_matches(fdt, node, "memory")) {
+            if (strcmp(prop_name, "reg") == 0) {
+                new_data = xzalloc_bytes(prop_len);
+                if (new_data  == NULL)
+                    return -ENOMEM;
+
+                set_memory_reg(d, dom0, fdt,
+                               (u32 *)prop_data, address_cells, size_cells,
+                               (u32 *)new_data, &prop_len);
+                prop_data = new_data;
+            }
+        }
+
+        /*
+         * TODO: Should call map_mmio_regions() for all devices in the
+         * tree that have a "reg" parameter (except cpus).  This
+         * requires that adjacent regions are coalesced and rounded up
+         * to whole pages.
+         */
+
+        fdt_property(dom0->fdt, prop_name, prop_data, prop_len);
+
+        xfree(new_data);
+    }
+
+    if (prop == -FDT_ERR_NOTFOUND)
+        return 0;
+    return prop;
+}
+
+static int write_nodes(struct domain *d, struct kernel_info *dom0,
+                       const void *fdt)
+{
+    int node;
+    int depth = 0, last_depth = -1;
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    for (node = 0, depth = 0;
+         node >= 0 && depth >= 0;
+         node = fdt_next_node(fdt, node, &depth))
+    {
+        const char *name;
+
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= DEVICE_TREE_MAX_DEPTH) {
+            printk("warning: node `%s' is nested too deep\n", name);
+            continue;
+        }
+
+        while (last_depth-- >= depth)
+            fdt_end_node(dom0->fdt);
+
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
+
+        fdt_begin_node(dom0->fdt, name);
 
-static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+        ret = write_properties(d, dom0, fdt, node, name, depth,
+                               address_cells[depth-1], size_cells[depth-1]);
+        if (ret < 0)
+            return ret;
+
+        last_depth = depth;
+    }
+
+    while (last_depth-- >= 0)
+        fdt_end_node(dom0->fdt);
+
+    return 0;
+}
+
+static int prepare_dtb(struct domain *d, struct kernel_info *dom0)
 {
-    paddr_t ma = gvirt_to_maddr(tags);
-    void *map = map_domain_page(ma>>PAGE_SHIFT);
-    void *p = map + (tags & (PAGE_SIZE - 1));
-    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+    void *fdt;
+    int new_size;
+    int ret;
 
-    /* not enough room on this page for all the tags */
-    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+    fdt = device_tree_flattened;
 
-#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+    new_size = fdt_totalsize(fdt) + 8192;
+    dom0->fdt = xmalloc_bytes(new_size);
+    if (dom0->fdt == NULL)
+        return -ENOMEM;
 
-    /* ATAG_CORE */
-    TAG(uint32_t, 2);
-    TAG(uint32_t, 0x54410001);
+    ret = fdt_create(dom0->fdt, new_size);
+    if (ret < 0)
+        goto err;
 
-    /* ATAG_MEM */
-    TAG(uint32_t, 4);
-    TAG(uint32_t, 0x54410002);
-    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
-    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+    fdt_finish_reservemap(dom0->fdt);
 
-    /* ATAG_CMDLINE */
-    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
-    TAG(uint32_t, 0x54410009);
-    memcpy(p, cmdline, strlen(cmdline) + 1);
-    p += ((strlen(cmdline) + 4) >> 2) << 2;
+    ret = write_nodes(d, dom0, fdt);
+    if (ret < 0)
+        goto err;
 
-    /* ATAG_NONE */
-    TAG(uint32_t, 0);
-    TAG(uint32_t, 0);
+    fdt_finish(dom0->fdt);
 
-#undef TAG
+    device_tree_dump(dom0->fdt);
+
+    dom0->fdt = dom0->fdt;
+    return 0;
+
+  err:
+    xfree(dom0->fdt);
+    return ret;
+}
+
+static void dtb_load(struct kernel_info *dom0)
+{
+    void *dtb_virt = (void *)(u32)dom0->dtb_paddr;
 
-    unmap_domain_page(map);
+    raw_copy_to_guest(dtb_virt, dom0->fdt, fdt_totalsize(dom0->fdt));
+    xfree(dom0->fdt);
 }
 
 int construct_dom0(struct domain *d)
@@ -81,22 +233,27 @@ int construct_dom0(struct domain *d)
 
     printk("*** LOADING DOMAIN 0 ***\n");
 
-    /* 128M at 2G physical */
-    /* TODO size and location from DT. */
-    kinfo.ram_start = 0x80000000;
-    kinfo.ram_end   = 0x88000000;
+    d->max_pages = ~0U;
 
-    rc = kernel_prepare(&kinfo);
-    if (rc < 0)
+    if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    d->max_pages = ~0U;
+    kinfo.unassigned_mem = 0x08000000; /* XXX */
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
+    rc = prepare_dtb(d, &kinfo);
+    if (rc < 0)
         return rc;
 
-    printk("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
-    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
+    /* First RAM bank must be below 4 GiB or a 32-bit dom0 kernel
+       cannot be loaded. */
+    if (kinfo.mem.bank[0].start >= 1ull << 32) {
+        printk("No memory accessible to 32 bit dom0.");
+        return -EINVAL;
+    }
+
+    rc = kernel_prepare(&kinfo);
+    if (rc < 0)
+        return rc;
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -124,13 +281,12 @@ int construct_dom0(struct domain *d)
     /* Enable second stage translation */
     WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
 
-    /* The following load uses domain's p2m */
+    /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
 
+    dtb_load(&kinfo);
     kernel_load(&kinfo);
 
-    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
-
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
@@ -152,7 +308,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
+    regs->r2 = kinfo.dtb_paddr;
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index dd757e5..b27b20d 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -121,7 +121,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
      * at 32k from start of RAM.
      */
     if (start == 0)
-        info->zimage.load_addr = info->ram_start + 0x8000;
+        info->zimage.load_addr = info->mem.bank[0].start + 0x8000;
     else
         info->zimage.load_addr = start;
     info->zimage.len = end - start;
@@ -176,6 +176,8 @@ int kernel_prepare(struct kernel_info *info)
 {
     int rc;
 
+    info->dtb_paddr = info->mem.bank[0].start + 0x100;
+
     rc = kernel_try_zimage_prepare(info);
     if (rc < 0)
         rc = kernel_try_elf_prepare(info);
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 5caebe5..4533568 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -7,11 +7,15 @@
 #define __ARCH_ARM_KERNEL_H__
 
 #include <xen/libelf.h>
+#include <xen/device_tree.h>
 
 struct kernel_info {
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct dt_mem_info mem;
+
+    paddr_t dtb_paddr;
     paddr_t entry;
-    paddr_t ram_start;
-    paddr_t ram_end;
 
     void *kernel_img;
     unsigned kernel_order;
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index dbc4f61..2422fba 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -24,7 +24,7 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
-static bool_t __init node_matches(const void *fdt, int node, const char *match)
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
 {
     const char *name;
     size_t len;
@@ -48,14 +48,32 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
     }
 }
 
-static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
-                                u64 *start, u64 *size)
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size)
 {
     get_val(cell, address_cells, start);
     get_val(cell, size_cells, size);
 }
 
-static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+void set_val(u32 **cell, u32 cells, u64 val)
+{
+    u32 c = cells;
+
+    while (c--) {
+        (*cell)[c] = cpu_to_fdt32(val);
+        val >>= 32;
+    }
+    (*cell) += cells;
+}
+
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size)
+{
+    set_val(cell, address_cells, start);
+    set_val(cell, size_cells, size);
+}
+
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
 {
     const struct fdt_property *prop;
 
@@ -66,8 +84,6 @@ static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_n
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-#define MAX_DEPTH 16
-
 /**
  * device_tree_for_each_node - iterate over all device tree nodes
  * @fdt: flat device tree.
@@ -79,19 +95,19 @@ int device_tree_for_each_node(const void *fdt,
 {
     int node;
     int depth;
-    u32 address_cells[MAX_DEPTH];
-    u32 size_cells[MAX_DEPTH];
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
     int ret;
 
     for (node = 0, depth = 0;
          node >=0 && depth >= 0;
          node = fdt_next_node(fdt, node, &depth))
     {
-        if (depth >= MAX_DEPTH)
+        if (depth >= DEVICE_TREE_MAX_DEPTH)
             continue;
 
-        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
-        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
         ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
                    address_cells[depth-1], size_cells[depth-1], data);
@@ -104,7 +120,7 @@ int device_tree_for_each_node(const void *fdt,
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
-    char prefix[2*MAX_DEPTH + 1] = "";
+    char prefix[2*DEVICE_TREE_MAX_DEPTH + 1] = "";
     int i;
     int prop;
 
@@ -165,7 +181,7 @@ static void __init process_memory_node(const void *fdt, int node, const char *na
     banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
 
     for (i = 0; i < banks && early_info.mem.nr_banks < NR_MEM_BANKS; i++) {
-        get_register(&cell, address_cells, size_cells, &start, &size);
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
         early_info.mem.bank[early_info.mem.nr_banks].start = start;
         early_info.mem.bank[early_info.mem.nr_banks].size = size;
         early_info.mem.nr_banks++;
@@ -176,7 +192,7 @@ static int __init early_scan_node(const void *fdt,
                                   int node, const char *name, int depth,
                                   u32 address_cells, u32 size_cells, void *data)
 {
-    if (node_matches(fdt, node, "memory"))
+    if (device_tree_node_matches(fdt, node, "memory"))
         process_memory_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index b91b39f..510b5b4 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -12,6 +12,8 @@
 
 #include <xen/types.h>
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
 #define NR_MEM_BANKS 8
 
 struct membank {
@@ -39,6 +41,12 @@ extern void *device_tree_flattened;
 size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size);
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size);
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 void device_tree_dump(const void *fdt);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK5-0003Hn-F0; Tue, 28 Feb 2012 16:54:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Fi-GD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15930 invoked from network); 28 Feb 2012 16:54:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:22 +0000
Message-ID: <1330448064-32267-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] device tree,
	arm: supply a flat device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Build a flat device tree for dom0 based on the one supplied to Xen.
The following changes are made:

  * In the /chosen node, the xen,dom0-bootargs parameter is renamed to
    bootargs.

  * In all memory nodes, the reg parameters are adjusted to reflect
    the amount of memory dom0 can use.  The p2m is updated using this
    info.

Support for passing ATAGS to dom0 is removed.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile         |    2 +
 xen/arch/arm/domain_build.c   |  238 ++++++++++++++++++++++++++++++++++-------
 xen/arch/arm/kernel.c         |    4 +-
 xen/arch/arm/kernel.h         |    8 +-
 xen/common/device_tree.c      |   44 +++++---
 xen/include/xen/device_tree.h |    8 ++
 6 files changed, 246 insertions(+), 58 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index da5096a..4c9517c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,6 +25,8 @@ obj-y += vtimer.o
 
 #obj-bin-y += ....o
 
+CFLAGS += -I../../common/libfdt
+
 ifdef CONFIG_DTB_FILE
 obj-y += dtb.o
 AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9240209..ca8c706 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -6,6 +6,11 @@
 #include <xen/sched.h>
 #include <asm/irq.h>
 #include <asm/regs.h>
+#include <xen/errno.h>
+#include <xen/device_tree.h>
+#include <xen/guest_access.h>
+
+#include <libfdt.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -27,43 +32,190 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
     return alloc_vcpu(dom0, 0, 0);
 }
 
-extern void guest_mode_entry(void);
+static void set_memory_reg(struct domain *d, struct kernel_info *dom0,
+                           const void *fdt,
+                           const u32 *cell, int address_cells, int size_cells,
+                           u32 *new_cell, int *len)
+{
+    int reg_size = (address_cells + size_cells) * sizeof(*cell);
+    int l;
+    u64 start;
+    u64 size;
+
+    l = *len;
+
+    while (dom0->unassigned_mem > 0 && l > reg_size
+           && dom0->mem.nr_banks < NR_MEM_BANKS)
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+        if (size > dom0->unassigned_mem)
+            size = dom0->unassigned_mem;
+
+        device_tree_set_reg(&new_cell, address_cells, size_cells, start, size);
+
+        printk("Populate P2M %#llx->%#llx\n", start, start + size);
+        p2m_populate_ram(d, start, start + size);
+        dom0->mem.bank[dom0->mem.nr_banks].start = start;
+        dom0->mem.bank[dom0->mem.nr_banks].size = size;
+        dom0->unassigned_mem -= size;
+
+        l -= reg_size;
+    }
+
+    *len -= l;
+}
+
+static int write_properties(struct domain *d, struct kernel_info *dom0,
+                            const void *fdt,
+                            int node, const char *name, int depth,
+                            u32 address_cells, u32 size_cells)
+{
+    int prop;
+
+    for (prop = fdt_first_property_offset(fdt, node);
+         prop >= 0;
+         prop = fdt_next_property_offset(fdt, prop))
+    {
+        const struct fdt_property *p;
+        const char *prop_name;
+        const char *prop_data;
+        int prop_len;
+        char *new_data = NULL;
+
+        p = fdt_get_property_by_offset(fdt, prop, NULL);
+        prop_name = fdt_string(fdt, fdt32_to_cpu(p->nameoff));
+        prop_data = p->data;
+        prop_len  = fdt32_to_cpu(p->len);
+
+        /*
+         * In chosen node: replace bootargs with value from
+         * xen,dom0-bootargs.
+         */
+        if (device_tree_node_matches(fdt, node, "chosen")) {
+            if (strcmp(prop_name, "bootargs") == 0)
+                continue;
+            if (strcmp(prop_name, "xen,dom0-bootargs") == 0)
+                prop_name = "bootargs";
+        }
+
+        /*
+         * In a memory node: adjust reg property.
+         */
+        if (device_tree_node_matches(fdt, node, "memory")) {
+            if (strcmp(prop_name, "reg") == 0) {
+                new_data = xzalloc_bytes(prop_len);
+                if (new_data  == NULL)
+                    return -ENOMEM;
+
+                set_memory_reg(d, dom0, fdt,
+                               (u32 *)prop_data, address_cells, size_cells,
+                               (u32 *)new_data, &prop_len);
+                prop_data = new_data;
+            }
+        }
+
+        /*
+         * TODO: Should call map_mmio_regions() for all devices in the
+         * tree that have a "reg" parameter (except cpus).  This
+         * requires that adjacent regions are coalesced and rounded up
+         * to whole pages.
+         */
+
+        fdt_property(dom0->fdt, prop_name, prop_data, prop_len);
+
+        xfree(new_data);
+    }
+
+    if (prop == -FDT_ERR_NOTFOUND)
+        return 0;
+    return prop;
+}
+
+static int write_nodes(struct domain *d, struct kernel_info *dom0,
+                       const void *fdt)
+{
+    int node;
+    int depth = 0, last_depth = -1;
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    for (node = 0, depth = 0;
+         node >= 0 && depth >= 0;
+         node = fdt_next_node(fdt, node, &depth))
+    {
+        const char *name;
+
+        name = fdt_get_name(fdt, node, NULL);
+
+        if (depth >= DEVICE_TREE_MAX_DEPTH) {
+            printk("warning: node `%s' is nested too deep\n", name);
+            continue;
+        }
+
+        while (last_depth-- >= depth)
+            fdt_end_node(dom0->fdt);
+
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
+
+        fdt_begin_node(dom0->fdt, name);
 
-static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
+        ret = write_properties(d, dom0, fdt, node, name, depth,
+                               address_cells[depth-1], size_cells[depth-1]);
+        if (ret < 0)
+            return ret;
+
+        last_depth = depth;
+    }
+
+    while (last_depth-- >= 0)
+        fdt_end_node(dom0->fdt);
+
+    return 0;
+}
+
+static int prepare_dtb(struct domain *d, struct kernel_info *dom0)
 {
-    paddr_t ma = gvirt_to_maddr(tags);
-    void *map = map_domain_page(ma>>PAGE_SHIFT);
-    void *p = map + (tags & (PAGE_SIZE - 1));
-    char cmdline[] = "earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw";
+    void *fdt;
+    int new_size;
+    int ret;
 
-    /* not enough room on this page for all the tags */
-    BUG_ON(PAGE_SIZE - (tags & (PAGE_SIZE - 1)) < 8 * sizeof(uint32_t));
+    fdt = device_tree_flattened;
 
-#define TAG(type, val) *(type*)p = val; p+= sizeof(type)
+    new_size = fdt_totalsize(fdt) + 8192;
+    dom0->fdt = xmalloc_bytes(new_size);
+    if (dom0->fdt == NULL)
+        return -ENOMEM;
 
-    /* ATAG_CORE */
-    TAG(uint32_t, 2);
-    TAG(uint32_t, 0x54410001);
+    ret = fdt_create(dom0->fdt, new_size);
+    if (ret < 0)
+        goto err;
 
-    /* ATAG_MEM */
-    TAG(uint32_t, 4);
-    TAG(uint32_t, 0x54410002);
-    TAG(uint32_t, (ram_e - ram_s) & 0xFFFFFFFF);
-    TAG(uint32_t, ram_s & 0xFFFFFFFF);
+    fdt_finish_reservemap(dom0->fdt);
 
-    /* ATAG_CMDLINE */
-    TAG(uint32_t, 2 + ((strlen(cmdline) + 4) >> 2));
-    TAG(uint32_t, 0x54410009);
-    memcpy(p, cmdline, strlen(cmdline) + 1);
-    p += ((strlen(cmdline) + 4) >> 2) << 2;
+    ret = write_nodes(d, dom0, fdt);
+    if (ret < 0)
+        goto err;
 
-    /* ATAG_NONE */
-    TAG(uint32_t, 0);
-    TAG(uint32_t, 0);
+    fdt_finish(dom0->fdt);
 
-#undef TAG
+    device_tree_dump(dom0->fdt);
+
+    dom0->fdt = dom0->fdt;
+    return 0;
+
+  err:
+    xfree(dom0->fdt);
+    return ret;
+}
+
+static void dtb_load(struct kernel_info *dom0)
+{
+    void *dtb_virt = (void *)(u32)dom0->dtb_paddr;
 
-    unmap_domain_page(map);
+    raw_copy_to_guest(dtb_virt, dom0->fdt, fdt_totalsize(dom0->fdt));
+    xfree(dom0->fdt);
 }
 
 int construct_dom0(struct domain *d)
@@ -81,22 +233,27 @@ int construct_dom0(struct domain *d)
 
     printk("*** LOADING DOMAIN 0 ***\n");
 
-    /* 128M at 2G physical */
-    /* TODO size and location from DT. */
-    kinfo.ram_start = 0x80000000;
-    kinfo.ram_end   = 0x88000000;
+    d->max_pages = ~0U;
 
-    rc = kernel_prepare(&kinfo);
-    if (rc < 0)
+    if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    d->max_pages = ~0U;
+    kinfo.unassigned_mem = 0x08000000; /* XXX */
 
-    if ( (rc = p2m_alloc_table(d)) != 0 )
+    rc = prepare_dtb(d, &kinfo);
+    if (rc < 0)
         return rc;
 
-    printk("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
-    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
+    /* First RAM bank must be below 4 GiB or a 32-bit dom0 kernel
+       cannot be loaded. */
+    if (kinfo.mem.bank[0].start >= 1ull << 32) {
+        printk("No memory accessible to 32 bit dom0.");
+        return -EINVAL;
+    }
+
+    rc = kernel_prepare(&kinfo);
+    if (rc < 0)
+        return rc;
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -124,13 +281,12 @@ int construct_dom0(struct domain *d)
     /* Enable second stage translation */
     WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
 
-    /* The following load uses domain's p2m */
+    /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
 
+    dtb_load(&kinfo);
     kernel_load(&kinfo);
 
-    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
-
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
@@ -152,7 +308,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
+    regs->r2 = kinfo.dtb_paddr;
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index dd757e5..b27b20d 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -121,7 +121,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
      * at 32k from start of RAM.
      */
     if (start == 0)
-        info->zimage.load_addr = info->ram_start + 0x8000;
+        info->zimage.load_addr = info->mem.bank[0].start + 0x8000;
     else
         info->zimage.load_addr = start;
     info->zimage.len = end - start;
@@ -176,6 +176,8 @@ int kernel_prepare(struct kernel_info *info)
 {
     int rc;
 
+    info->dtb_paddr = info->mem.bank[0].start + 0x100;
+
     rc = kernel_try_zimage_prepare(info);
     if (rc < 0)
         rc = kernel_try_elf_prepare(info);
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 5caebe5..4533568 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -7,11 +7,15 @@
 #define __ARCH_ARM_KERNEL_H__
 
 #include <xen/libelf.h>
+#include <xen/device_tree.h>
 
 struct kernel_info {
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct dt_mem_info mem;
+
+    paddr_t dtb_paddr;
     paddr_t entry;
-    paddr_t ram_start;
-    paddr_t ram_end;
 
     void *kernel_img;
     unsigned kernel_order;
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index dbc4f61..2422fba 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -24,7 +24,7 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
-static bool_t __init node_matches(const void *fdt, int node, const char *match)
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match)
 {
     const char *name;
     size_t len;
@@ -48,14 +48,32 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
     }
 }
 
-static void __init get_register(const u32 **cell, u32 address_cells, u32 size_cells,
-                                u64 *start, u64 *size)
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size)
 {
     get_val(cell, address_cells, start);
     get_val(cell, size_cells, size);
 }
 
-static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_name)
+void set_val(u32 **cell, u32 cells, u64 val)
+{
+    u32 c = cells;
+
+    while (c--) {
+        (*cell)[c] = cpu_to_fdt32(val);
+        val >>= 32;
+    }
+    (*cell) += cells;
+}
+
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size)
+{
+    set_val(cell, address_cells, start);
+    set_val(cell, size_cells, size);
+}
+
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
 {
     const struct fdt_property *prop;
 
@@ -66,8 +84,6 @@ static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_n
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-#define MAX_DEPTH 16
-
 /**
  * device_tree_for_each_node - iterate over all device tree nodes
  * @fdt: flat device tree.
@@ -79,19 +95,19 @@ int device_tree_for_each_node(const void *fdt,
 {
     int node;
     int depth;
-    u32 address_cells[MAX_DEPTH];
-    u32 size_cells[MAX_DEPTH];
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
     int ret;
 
     for (node = 0, depth = 0;
          node >=0 && depth >= 0;
          node = fdt_next_node(fdt, node, &depth))
     {
-        if (depth >= MAX_DEPTH)
+        if (depth >= DEVICE_TREE_MAX_DEPTH)
             continue;
 
-        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
-        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
 
         ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
                    address_cells[depth-1], size_cells[depth-1], data);
@@ -104,7 +120,7 @@ int device_tree_for_each_node(const void *fdt,
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
-    char prefix[2*MAX_DEPTH + 1] = "";
+    char prefix[2*DEVICE_TREE_MAX_DEPTH + 1] = "";
     int i;
     int prop;
 
@@ -165,7 +181,7 @@ static void __init process_memory_node(const void *fdt, int node, const char *na
     banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof(u32));
 
     for (i = 0; i < banks && early_info.mem.nr_banks < NR_MEM_BANKS; i++) {
-        get_register(&cell, address_cells, size_cells, &start, &size);
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
         early_info.mem.bank[early_info.mem.nr_banks].start = start;
         early_info.mem.bank[early_info.mem.nr_banks].size = size;
         early_info.mem.nr_banks++;
@@ -176,7 +192,7 @@ static int __init early_scan_node(const void *fdt,
                                   int node, const char *name, int depth,
                                   u32 address_cells, u32 size_cells, void *data)
 {
-    if (node_matches(fdt, node, "memory"))
+    if (device_tree_node_matches(fdt, node, "memory"))
         process_memory_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index b91b39f..510b5b4 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -12,6 +12,8 @@
 
 #include <xen/types.h>
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
 #define NR_MEM_BANKS 8
 
 struct membank {
@@ -39,6 +41,12 @@ extern void *device_tree_flattened;
 size_t device_tree_early_init(const void *fdt);
 paddr_t device_tree_get_xen_paddr(void);
 
+void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 *start, u64 *size);
+void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
+                         u64 start, u64 size);
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
+bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 void device_tree_dump(const void *fdt);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK4-0003HB-9M; Tue, 28 Feb 2012 16:54:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Ff-8y
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11500 invoked from network); 28 Feb 2012 16:54: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;
	28 Feb 2012 16:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:18 +0000
Message-ID: <1330448064-32267-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] device tree: correctly ignore unit-address
	when matching nodes by name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

When matching node by their name, correctly ignore the unit address
(@...) part of the name.  Previously, a "memory-controller" node would
be incorrectly matched as a "memory" node.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/device_tree.c |   19 +++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d50cb9c..e5df748 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -24,6 +24,20 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
+static bool_t __init node_matches(const void *fdt, int node, const char *match)
+{
+    const char *name;
+    size_t len;
+
+    name = fdt_get_name(fdt, node, NULL);
+    len = strlen(match);
+
+    /* Match both "match" and "match@..." patterns but not
+       "match-foo". */
+    return strncmp(name, match, len) == 0
+        && (name[len] == '@' || name[len] == '\0');
+}
+
 static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
     *val = 0;
@@ -93,13 +107,10 @@ static void __init early_scan(const void *fdt)
 {
     int node;
     int depth;
-    const char *name;
     u32 address_cells[MAX_DEPTH];
     u32 size_cells[MAX_DEPTH];
 
     for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
-        name = fdt_get_name(fdt, node, NULL);
-
         if (depth >= MAX_DEPTH) {
             early_printk("fdt: node '%s': nested too deep\n",
                          fdt_get_name(fdt, node, NULL));
@@ -109,7 +120,7 @@ static void __init early_scan(const void *fdt)
         address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
         size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
 
-        if (strncmp(name, "memory", 6) == 0)
+        if (node_matches(fdt, node, "memory"))
             process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
     }
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK4-0003HB-9M; Tue, 28 Feb 2012 16:54:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Ff-8y
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11500 invoked from network); 28 Feb 2012 16:54: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;
	28 Feb 2012 16:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:18 +0000
Message-ID: <1330448064-32267-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] device tree: correctly ignore unit-address
	when matching nodes by name
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

When matching node by their name, correctly ignore the unit address
(@...) part of the name.  Previously, a "memory-controller" node would
be incorrectly matched as a "memory" node.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/device_tree.c |   19 +++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d50cb9c..e5df748 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -24,6 +24,20 @@
 struct dt_early_info __initdata early_info;
 void *device_tree_flattened;
 
+static bool_t __init node_matches(const void *fdt, int node, const char *match)
+{
+    const char *name;
+    size_t len;
+
+    name = fdt_get_name(fdt, node, NULL);
+    len = strlen(match);
+
+    /* Match both "match" and "match@..." patterns but not
+       "match-foo". */
+    return strncmp(name, match, len) == 0
+        && (name[len] == '@' || name[len] == '\0');
+}
+
 static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
     *val = 0;
@@ -93,13 +107,10 @@ static void __init early_scan(const void *fdt)
 {
     int node;
     int depth;
-    const char *name;
     u32 address_cells[MAX_DEPTH];
     u32 size_cells[MAX_DEPTH];
 
     for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
-        name = fdt_get_name(fdt, node, NULL);
-
         if (depth >= MAX_DEPTH) {
             early_printk("fdt: node '%s': nested too deep\n",
                          fdt_get_name(fdt, node, NULL));
@@ -109,7 +120,7 @@ static void __init early_scan(const void *fdt)
         address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
         size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
 
-        if (strncmp(name, "memory", 6) == 0)
+        if (node_matches(fdt, node, "memory"))
             process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
     }
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK3-0003Gt-G5; Tue, 28 Feb 2012 16:54:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK0-0003Fb-V2
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15880 invoked from network); 28 Feb 2012 16:54:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:33 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:17 +0000
Message-ID: <1330448064-32267-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] arm: add generated files to .gitignore and
	.hgignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 .gitignore |    2 ++
 .hgignore  |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8810b35..ba4b241 100644
--- a/.gitignore
+++ b/.gitignore
@@ -284,6 +284,8 @@ tools/ocaml-xenstored*
 xen/.banner*
 xen/BLOG
 xen/System.map
+xen/arch/arm/asm-offsets.s
+xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
diff --git a/.hgignore b/.hgignore
index 46655ad..dffce07 100644
--- a/.hgignore
+++ b/.hgignore
@@ -312,6 +312,8 @@
 ^xen/\.banner.*$
 ^xen/BLOG$
 ^xen/System.map$
+^xen/arch/arm/asm-offsets\.s$
+^xen/arch/arm/xen\.lds$
 ^xen/arch/x86/asm-offsets\.s$
 ^xen/arch/x86/boot/mkelf32$
 ^xen/arch/x86/xen\.lds$
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK3-0003Gt-G5; Tue, 28 Feb 2012 16:54:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK0-0003Fb-V2
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15880 invoked from network); 28 Feb 2012 16:54:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:33 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:17 +0000
Message-ID: <1330448064-32267-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] arm: add generated files to .gitignore and
	.hgignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 .gitignore |    2 ++
 .hgignore  |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8810b35..ba4b241 100644
--- a/.gitignore
+++ b/.gitignore
@@ -284,6 +284,8 @@ tools/ocaml-xenstored*
 xen/.banner*
 xen/BLOG
 xen/System.map
+xen/arch/arm/asm-offsets.s
+xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
diff --git a/.hgignore b/.hgignore
index 46655ad..dffce07 100644
--- a/.hgignore
+++ b/.hgignore
@@ -312,6 +312,8 @@
 ^xen/\.banner.*$
 ^xen/BLOG$
 ^xen/System.map$
+^xen/arch/arm/asm-offsets\.s$
+^xen/arch/arm/xen\.lds$
 ^xen/arch/x86/asm-offsets\.s$
 ^xen/arch/x86/boot/mkelf32$
 ^xen/arch/x86/xen\.lds$
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK3-0003Gf-42; Tue, 28 Feb 2012 16:54:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK0-0003Fa-SE
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15875 invoked from network); 28 Feb 2012 16:54:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:33 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:16 +0000
Message-ID: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/8] arm: pass a device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series of patches makes Xen pass a (somewhat) valid device tree
to dom0.  The device tree for dom0 is the same as the one supplied to
Xen except the memory and chosen nodes are adjusted appropriately.

We don't yet make use of the device tree to map MMIO regions or setup
interrupts for the guest and we still include the UART used for Xen's
console.

Note that loading Linux using a vmlinux file is no longer supported
and the kernel must support device tree (ATAGS are no longer provided
by Xen).

It is also possible to provide the Xen and dom0 command line via the
device tree.  This isn't as useful as it seems as Xen still needs to
be rebuilt to included the updated device tree.

The instructions on the wiki[1] have been updated to reflect these
changes.

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK3-0003Gf-42; Tue, 28 Feb 2012 16:54:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK0-0003Fa-SE
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15875 invoked from network); 28 Feb 2012 16:54:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:34 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:33 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:33 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:16 +0000
Message-ID: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/8] arm: pass a device tree to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series of patches makes Xen pass a (somewhat) valid device tree
to dom0.  The device tree for dom0 is the same as the one supplied to
Xen except the memory and chosen nodes are adjusted appropriately.

We don't yet make use of the device tree to map MMIO regions or setup
interrupts for the guest and we still include the UART used for Xen's
console.

Note that loading Linux using a vmlinux file is no longer supported
and the kernel must support device tree (ATAGS are no longer provided
by Xen).

It is also possible to provide the Xen and dom0 command line via the
device tree.  This isn't as useful as it seems as Xen still needs to
be rebuilt to included the updated device tree.

The instructions on the wiki[1] have been updated to reflect these
changes.

David

[1] http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QJy-0003Fp-OC; Tue, 28 Feb 2012 16:54: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 1S2QJx-0003Fe-DI
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330448034!54427884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9629 invoked from network); 28 Feb 2012 16:53:54 -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;
	28 Feb 2012 16:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:35 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:35 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:23 +0000
Message-ID: <1330448064-32267-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] arm: use bootargs for the command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Use the /chosen node's bootargs parameter for the Xen command line.
Parse it early on before the serial console is setup.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/setup.c          |    2 ++
 xen/common/device_tree.c      |   20 ++++++++++++++++++++
 xen/common/kernel.c           |    2 +-
 xen/include/xen/device_tree.h |    1 +
 xen/include/xen/lib.h         |    2 +-
 5 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4c0244c..01ead73 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -164,6 +164,8 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+    cmdline_parse(device_tree_bootargs(fdt));
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 2422fba..512297f 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -117,6 +117,26 @@ int device_tree_for_each_node(const void *fdt,
     return 0;
 }
 
+/**
+ * device_tree_bootargs - return the bootargs (the Xen command line)
+ * @fdt flat device tree.
+ */
+const char *device_tree_bootargs(const void *fdt)
+{
+    int node; 
+    const struct fdt_property *prop;
+
+    node = fdt_path_offset(fdt, "/chosen");
+    if (node < 0)
+        return NULL;
+
+    prop = fdt_get_property(fdt, node, "bootargs", NULL);
+    if (prop == NULL)
+        return NULL;
+
+    return prop->data;
+}
+
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 88984d2..145b0b6 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -46,7 +46,7 @@ static void __init assign_integer_param(
     }
 }
 
-void __init cmdline_parse(char *cmdline)
+void __init cmdline_parse(const char *cmdline)
 {
     char opt[100], *optval, *optkey, *q;
     const char *p = cmdline;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 510b5b4..8e1626c 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -49,6 +49,7 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
+const char *device_tree_bootargs(const void *fdt);
 void device_tree_dump(const void *fdt);
 
 #endif
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index d6f9182..36b4c7f 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -56,7 +56,7 @@ do {                                                            \
 
 struct domain;
 
-void cmdline_parse(char *cmdline);
+void cmdline_parse(const char *cmdline);
 int parse_bool(const char *s);
 
 /*#define DEBUG_TRACE_DUMP*/
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK3-0003H3-T9; Tue, 28 Feb 2012 16:54:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK1-0003Fc-Ow
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11518 invoked from network); 28 Feb 2012 16:54: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;
	28 Feb 2012 16:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:20 +0000
Message-ID: <1330448064-32267-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] device tree: add device_tree_dump() to
	print a flat device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add a device_tree_dump() function which prints to main structure and
properties names of a flat device tree (but not the properties values
yet).

This will be useful for debugging problems with the device tree
generated for dom0.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/device_tree.c      |   38 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h |    1 +
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index e95ff3c..dbc4f61 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -101,6 +101,44 @@ int device_tree_for_each_node(const void *fdt,
     return 0;
 }
 
+static int dump_node(const void *fdt, int node, const char *name, int depth,
+                     u32 address_cells, u32 size_cells, void *data)
+{
+    char prefix[2*MAX_DEPTH + 1] = "";
+    int i;
+    int prop;
+
+    for (i = 0; i < depth; i++)
+        safe_strcat(prefix, "  ");
+
+    if (name[0] == '\0')
+        name = "/";
+    printk("%s%s:\n", prefix, name);
+
+    for (prop = fdt_first_property_offset(fdt, node);
+         prop >= 0;
+         prop = fdt_next_property_offset(fdt, prop))
+    {
+        const struct fdt_property *p;
+
+        p = fdt_get_property_by_offset(fdt, prop, NULL);
+
+        printk("%s  %s\n", prefix, fdt_string(fdt, fdt32_to_cpu(p->nameoff)));
+    }
+
+    return 0;
+}
+
+/**
+ * device_tree_dump - print a text representation of a device tree
+ * @fdt: flat device tree to print
+ */
+void device_tree_dump(const void *fdt)
+{
+    device_tree_for_each_node(fdt, dump_node, NULL);
+}
+
+
 static void __init process_memory_node(const void *fdt, int node, const char *name,
                                        u32 address_cells, u32 size_cells)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 505f3e3..b91b39f 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -41,5 +41,6 @@ paddr_t device_tree_get_xen_paddr(void);
 
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
+void device_tree_dump(const void *fdt);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QJy-0003Fp-OC; Tue, 28 Feb 2012 16:54: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 1S2QJx-0003Fe-DI
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330448034!54427884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9629 invoked from network); 28 Feb 2012 16:53:54 -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;
	28 Feb 2012 16:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:35 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:35 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:23 +0000
Message-ID: <1330448064-32267-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] arm: use bootargs for the command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Use the /chosen node's bootargs parameter for the Xen command line.
Parse it early on before the serial console is setup.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/setup.c          |    2 ++
 xen/common/device_tree.c      |   20 ++++++++++++++++++++
 xen/common/kernel.c           |    2 +-
 xen/include/xen/device_tree.h |    1 +
 xen/include/xen/lib.h         |    2 +-
 5 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4c0244c..01ead73 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -164,6 +164,8 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+    cmdline_parse(device_tree_bootargs(fdt));
+
     setup_pagetables(boot_phys_offset);
 
 #ifdef EARLY_UART_ADDRESS
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 2422fba..512297f 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -117,6 +117,26 @@ int device_tree_for_each_node(const void *fdt,
     return 0;
 }
 
+/**
+ * device_tree_bootargs - return the bootargs (the Xen command line)
+ * @fdt flat device tree.
+ */
+const char *device_tree_bootargs(const void *fdt)
+{
+    int node; 
+    const struct fdt_property *prop;
+
+    node = fdt_path_offset(fdt, "/chosen");
+    if (node < 0)
+        return NULL;
+
+    prop = fdt_get_property(fdt, node, "bootargs", NULL);
+    if (prop == NULL)
+        return NULL;
+
+    return prop->data;
+}
+
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 88984d2..145b0b6 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -46,7 +46,7 @@ static void __init assign_integer_param(
     }
 }
 
-void __init cmdline_parse(char *cmdline)
+void __init cmdline_parse(const char *cmdline)
 {
     char opt[100], *optval, *optkey, *q;
     const char *p = cmdline;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 510b5b4..8e1626c 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -49,6 +49,7 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name);
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
+const char *device_tree_bootargs(const void *fdt);
 void device_tree_dump(const void *fdt);
 
 #endif
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index d6f9182..36b4c7f 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -56,7 +56,7 @@ do {                                                            \
 
 struct domain;
 
-void cmdline_parse(char *cmdline);
+void cmdline_parse(const char *cmdline);
 int parse_bool(const char *s);
 
 /*#define DEBUG_TRACE_DUMP*/
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK3-0003H3-T9; Tue, 28 Feb 2012 16:54:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK1-0003Fc-Ow
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:41 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11518 invoked from network); 28 Feb 2012 16:54: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;
	28 Feb 2012 16:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:20 +0000
Message-ID: <1330448064-32267-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] device tree: add device_tree_dump() to
	print a flat device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add a device_tree_dump() function which prints to main structure and
properties names of a flat device tree (but not the properties values
yet).

This will be useful for debugging problems with the device tree
generated for dom0.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/device_tree.c      |   38 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h |    1 +
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index e95ff3c..dbc4f61 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -101,6 +101,44 @@ int device_tree_for_each_node(const void *fdt,
     return 0;
 }
 
+static int dump_node(const void *fdt, int node, const char *name, int depth,
+                     u32 address_cells, u32 size_cells, void *data)
+{
+    char prefix[2*MAX_DEPTH + 1] = "";
+    int i;
+    int prop;
+
+    for (i = 0; i < depth; i++)
+        safe_strcat(prefix, "  ");
+
+    if (name[0] == '\0')
+        name = "/";
+    printk("%s%s:\n", prefix, name);
+
+    for (prop = fdt_first_property_offset(fdt, node);
+         prop >= 0;
+         prop = fdt_next_property_offset(fdt, prop))
+    {
+        const struct fdt_property *p;
+
+        p = fdt_get_property_by_offset(fdt, prop, NULL);
+
+        printk("%s  %s\n", prefix, fdt_string(fdt, fdt32_to_cpu(p->nameoff)));
+    }
+
+    return 0;
+}
+
+/**
+ * device_tree_dump - print a text representation of a device tree
+ * @fdt: flat device tree to print
+ */
+void device_tree_dump(const void *fdt)
+{
+    device_tree_for_each_node(fdt, dump_node, NULL);
+}
+
+
 static void __init process_memory_node(const void *fdt, int node, const char *name,
                                        u32 address_cells, u32 size_cells)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 505f3e3..b91b39f 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -41,5 +41,6 @@ paddr_t device_tree_get_xen_paddr(void);
 
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
+void device_tree_dump(const void *fdt);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK5-0003Ha-1a; Tue, 28 Feb 2012 16:54:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Fd-BO
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15903 invoked from network); 28 Feb 2012 16:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989298"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:19 +0000
Message-ID: <1330448064-32267-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] device tree: add device_tree_for_each_node()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add device_tree_for_each_node() to iterate over all nodes in a flat
device tree.  Use this in device_tree_early_init().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/device_tree.c      |   71 ++++++++++++++++++++++++++---------------
 xen/include/xen/device_tree.h |    8 +++++
 2 files changed, 53 insertions(+), 26 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index e5df748..e95ff3c 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -66,7 +66,42 @@ static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_n
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-static void __init process_memory_node(const void *fdt, int node,
+#define MAX_DEPTH 16
+
+/**
+ * device_tree_for_each_node - iterate over all device tree nodes
+ * @fdt: flat device tree.
+ * @func: function to call for each node.
+ * @data: data to pass to @func.
+ */
+int device_tree_for_each_node(const void *fdt,
+                              device_tree_node_func func, void *data)
+{
+    int node;
+    int depth;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+    int ret;
+
+    for (node = 0, depth = 0;
+         node >=0 && depth >= 0;
+         node = fdt_next_node(fdt, node, &depth))
+    {
+        if (depth >= MAX_DEPTH)
+            continue;
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
+                   address_cells[depth-1], size_cells[depth-1], data);
+        if (ret < 0)
+            return ret;
+    }
+    return 0;
+}
+
+static void __init process_memory_node(const void *fdt, int node, const char *name,
                                        u32 address_cells, u32 size_cells)
 {
     const struct fdt_property *prop;
@@ -77,15 +112,13 @@ static void __init process_memory_node(const void *fdt, int node,
     paddr_t start, size;
 
     if (address_cells < 1 || size_cells < 1) {
-        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
-                     fdt_get_name(fdt, node, NULL));
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells", name);
         return;
     }
 
     prop = fdt_get_property(fdt, node, "reg", NULL);
     if (!prop) {
-        early_printk("fdt: node `%s': missing `reg' property\n",
-                     fdt_get_name(fdt, node, NULL));
+        early_printk("fdt: node `%s': missing `reg' property\n", name);
         return;
     }
 
@@ -101,28 +134,14 @@ static void __init process_memory_node(const void *fdt, int node,
     }
 }
 
-#define MAX_DEPTH 16
-
-static void __init early_scan(const void *fdt)
+static int __init early_scan_node(const void *fdt,
+                                  int node, const char *name, int depth,
+                                  u32 address_cells, u32 size_cells, void *data)
 {
-    int node;
-    int depth;
-    u32 address_cells[MAX_DEPTH];
-    u32 size_cells[MAX_DEPTH];
-
-    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
-        if (depth >= MAX_DEPTH) {
-            early_printk("fdt: node '%s': nested too deep\n",
-                         fdt_get_name(fdt, node, NULL));
-            continue;
-        }
+    if (node_matches(fdt, node, "memory"))
+        process_memory_node(fdt, node, name, address_cells, size_cells);
 
-        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
-        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
-
-        if (node_matches(fdt, node, "memory"))
-            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
-    }
+    return 0;
 }
 
 static void __init early_print_info(void)
@@ -149,7 +168,7 @@ size_t __init device_tree_early_init(const void *fdt)
     if (ret < 0)
         early_panic("No valid device tree\n");
 
-    early_scan(fdt);
+    device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
     early_print_info();
 
     return fdt_totalsize(fdt);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 28a3dee..505f3e3 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -28,10 +28,18 @@ struct dt_early_info {
     struct dt_mem_info mem;
 };
 
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
 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);
 
+int device_tree_for_each_node(const void *fdt,
+                              device_tree_node_func func, void *data);
+
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK5-0003Ha-1a; Tue, 28 Feb 2012 16:54:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Fd-BO
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330448074!15271340!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15903 invoked from network); 28 Feb 2012 16:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 16:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989298"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:19 +0000
Message-ID: <1330448064-32267-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] device tree: add device_tree_for_each_node()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add device_tree_for_each_node() to iterate over all nodes in a flat
device tree.  Use this in device_tree_early_init().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/device_tree.c      |   71 ++++++++++++++++++++++++++---------------
 xen/include/xen/device_tree.h |    8 +++++
 2 files changed, 53 insertions(+), 26 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index e5df748..e95ff3c 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -66,7 +66,42 @@ static u32 __init prop_by_name_u32(const void *fdt, int node, const char *prop_n
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-static void __init process_memory_node(const void *fdt, int node,
+#define MAX_DEPTH 16
+
+/**
+ * device_tree_for_each_node - iterate over all device tree nodes
+ * @fdt: flat device tree.
+ * @func: function to call for each node.
+ * @data: data to pass to @func.
+ */
+int device_tree_for_each_node(const void *fdt,
+                              device_tree_node_func func, void *data)
+{
+    int node;
+    int depth;
+    u32 address_cells[MAX_DEPTH];
+    u32 size_cells[MAX_DEPTH];
+    int ret;
+
+    for (node = 0, depth = 0;
+         node >=0 && depth >= 0;
+         node = fdt_next_node(fdt, node, &depth))
+    {
+        if (depth >= MAX_DEPTH)
+            continue;
+
+        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
+        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
+
+        ret = func(fdt, node, fdt_get_name(fdt, node, NULL), depth,
+                   address_cells[depth-1], size_cells[depth-1], data);
+        if (ret < 0)
+            return ret;
+    }
+    return 0;
+}
+
+static void __init process_memory_node(const void *fdt, int node, const char *name,
                                        u32 address_cells, u32 size_cells)
 {
     const struct fdt_property *prop;
@@ -77,15 +112,13 @@ static void __init process_memory_node(const void *fdt, int node,
     paddr_t start, size;
 
     if (address_cells < 1 || size_cells < 1) {
-        early_printk("fdt: node `%s': invalid #address-cells or #size-cells",
-                     fdt_get_name(fdt, node, NULL));
+        early_printk("fdt: node `%s': invalid #address-cells or #size-cells", name);
         return;
     }
 
     prop = fdt_get_property(fdt, node, "reg", NULL);
     if (!prop) {
-        early_printk("fdt: node `%s': missing `reg' property\n",
-                     fdt_get_name(fdt, node, NULL));
+        early_printk("fdt: node `%s': missing `reg' property\n", name);
         return;
     }
 
@@ -101,28 +134,14 @@ static void __init process_memory_node(const void *fdt, int node,
     }
 }
 
-#define MAX_DEPTH 16
-
-static void __init early_scan(const void *fdt)
+static int __init early_scan_node(const void *fdt,
+                                  int node, const char *name, int depth,
+                                  u32 address_cells, u32 size_cells, void *data)
 {
-    int node;
-    int depth;
-    u32 address_cells[MAX_DEPTH];
-    u32 size_cells[MAX_DEPTH];
-
-    for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
-        if (depth >= MAX_DEPTH) {
-            early_printk("fdt: node '%s': nested too deep\n",
-                         fdt_get_name(fdt, node, NULL));
-            continue;
-        }
+    if (node_matches(fdt, node, "memory"))
+        process_memory_node(fdt, node, name, address_cells, size_cells);
 
-        address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
-        size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
-
-        if (node_matches(fdt, node, "memory"))
-            process_memory_node(fdt, node, address_cells[depth-1], size_cells[depth-1]);
-    }
+    return 0;
 }
 
 static void __init early_print_info(void)
@@ -149,7 +168,7 @@ size_t __init device_tree_early_init(const void *fdt)
     if (ret < 0)
         early_panic("No valid device tree\n");
 
-    early_scan(fdt);
+    device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
     early_print_info();
 
     return fdt_totalsize(fdt);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 28a3dee..505f3e3 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -28,10 +28,18 @@ struct dt_early_info {
     struct dt_mem_info mem;
 };
 
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
 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);
 
+int device_tree_for_each_node(const void *fdt,
+                              device_tree_node_func func, void *data);
+
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK4-0003HO-Lq; Tue, 28 Feb 2012 16:54:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Fg-CD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11543 invoked from network); 28 Feb 2012 16:54:36 -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;
	28 Feb 2012 16:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:35 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:35 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:24 +0000
Message-ID: <1330448064-32267-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] arm: add dom0_mem command line argument
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add a simple dom0_mem command line argument.  It's not as flexible as
the x86 equivalent (the 'max' and 'min' prefixes are not supported).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ca8c706..26f1104 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -18,6 +18,17 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+#define DOM0_MEM_DEFAULT 0x8000000 /* 128 MiB */
+static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+
+static void __init parse_dom0_mem(const char *s)
+{
+    dom0_mem = parse_size_and_unit(s, &s);
+    if (dom0_mem == 0)
+        dom0_mem = DOM0_MEM_DEFAULT;
+}
+custom_param("dom0_mem", parse_dom0_mem);
+
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
     dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
@@ -181,6 +192,8 @@ static int prepare_dtb(struct domain *d, struct kernel_info *dom0)
     int new_size;
     int ret;
 
+    dom0->unassigned_mem = dom0_mem;
+
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + 8192;
@@ -238,8 +251,6 @@ int construct_dom0(struct domain *d)
     if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    kinfo.unassigned_mem = 0x08000000; /* XXX */
-
     rc = prepare_dtb(d, &kinfo);
     if (rc < 0)
         return rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK4-0003HO-Lq; Tue, 28 Feb 2012 16:54:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK2-0003Fg-CD
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11543 invoked from network); 28 Feb 2012 16:54:36 -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;
	28 Feb 2012 16:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:35 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:35 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 16:54:24 +0000
Message-ID: <1330448064-32267-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] arm: add dom0_mem command line argument
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Add a simple dom0_mem command line argument.  It's not as flexible as
the x86 equivalent (the 'max' and 'min' prefixes are not supported).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ca8c706..26f1104 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -18,6 +18,17 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+#define DOM0_MEM_DEFAULT 0x8000000 /* 128 MiB */
+static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+
+static void __init parse_dom0_mem(const char *s)
+{
+    dom0_mem = parse_size_and_unit(s, &s);
+    if (dom0_mem == 0)
+        dom0_mem = DOM0_MEM_DEFAULT;
+}
+custom_param("dom0_mem", parse_dom0_mem);
+
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
     dom0->vcpu = xmalloc_array(struct vcpu *, opt_dom0_max_vcpus);
@@ -181,6 +192,8 @@ static int prepare_dtb(struct domain *d, struct kernel_info *dom0)
     int new_size;
     int ret;
 
+    dom0->unassigned_mem = dom0_mem;
+
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + 8192;
@@ -238,8 +251,6 @@ int construct_dom0(struct domain *d)
     if ( (rc = p2m_alloc_table(d)) != 0 )
         return rc;
 
-    kinfo.unassigned_mem = 0x08000000; /* XXX */
-
     rc = prepare_dtb(d, &kinfo);
     if (rc < 0)
         return rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK5-0003I7-SU; Tue, 28 Feb 2012 16:54:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK3-0003Fn-6x
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11537 invoked from network); 28 Feb 2012 16:54:36 -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;
	28 Feb 2012 16:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:21 +0000
Message-ID: <1330448064-32267-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] arm: remove the hack for loading vmlinux
	images
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Don't adjust the RAM location/size when loading an ELF for dom0.  It
was vmlinux specific and no longer needed because Linux can be loaded
from a zImage.

This also makes preparing the device tree for dom0 easier.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c |   11 ++---------
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 71a204d..dd757e5 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -91,7 +91,6 @@ static void kernel_zimage_load(struct kernel_info *info)
 
 /**
  * Check the image is a zImage and return the load address and length
- * (FIXME: including any appended DTB).
  */
 static int kernel_try_zimage_prepare(struct kernel_info *info)
 {
@@ -117,8 +116,6 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
         end += be32_to_cpu(dtb_hdr.total_size);
     }
 
-    /* FIXME: get RAM location from appended DTB (if there is one)? */
-
     /*
      * If start is zero, the zImage is position independent -- load it
      * at 32k from start of RAM.
@@ -166,13 +163,9 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
         return rc;
 
     /*
-     * FIXME: can the ELF header be used to find the physical address
-     * to load the image to?  Instead of making virt == phys by
-     * relocating the guest's RAM.
+     * TODO: can the ELF header be used to find the physical address
+     * to load the image to?  Instead of assuming virt == phys.
      */
-    info->ram_start = 0xc0000000;
-    info->ram_end   = 0xc8000000;
-
     info->entry = info->elf.parms.virt_entry;
     info->load = kernel_elf_load;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 16:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 16: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 1S2QK5-0003I7-SU; Tue, 28 Feb 2012 16:54:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2QK3-0003Fn-6x
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 16:54:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330448074!11503852!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11537 invoked from network); 28 Feb 2012 16:54:36 -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;
	28 Feb 2012 16:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 16:54:34 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 16:54:34 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 28 Feb 2012 16:54:21 +0000
Message-ID: <1330448064-32267-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
References: <1330448064-32267-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] arm: remove the hack for loading vmlinux
	images
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

Don't adjust the RAM location/size when loading an ELF for dom0.  It
was vmlinux specific and no longer needed because Linux can be loaded
from a zImage.

This also makes preparing the device tree for dom0 easier.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c |   11 ++---------
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 71a204d..dd757e5 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -91,7 +91,6 @@ static void kernel_zimage_load(struct kernel_info *info)
 
 /**
  * Check the image is a zImage and return the load address and length
- * (FIXME: including any appended DTB).
  */
 static int kernel_try_zimage_prepare(struct kernel_info *info)
 {
@@ -117,8 +116,6 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
         end += be32_to_cpu(dtb_hdr.total_size);
     }
 
-    /* FIXME: get RAM location from appended DTB (if there is one)? */
-
     /*
      * If start is zero, the zImage is position independent -- load it
      * at 32k from start of RAM.
@@ -166,13 +163,9 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
         return rc;
 
     /*
-     * FIXME: can the ELF header be used to find the physical address
-     * to load the image to?  Instead of making virt == phys by
-     * relocating the guest's RAM.
+     * TODO: can the ELF header be used to find the physical address
+     * to load the image to?  Instead of assuming virt == phys.
      */
-    info->ram_start = 0xc0000000;
-    info->ram_end   = 0xc8000000;
-
     info->entry = info->elf.parms.virt_entry;
     info->load = kernel_elf_load;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:02:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2QRd-0004cO-4H; Tue, 28 Feb 2012 17:02:33 +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 1S2QRb-0004cJ-LA
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:02:32 +0000
Received: from [85.158.139.83:21894] by server-11.bemta-5.messagelabs.com id
	41/8B-14397-6A80D4F4; Tue, 28 Feb 2012 17:02:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330448548!9755198!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 426 invoked from network); 28 Feb 2012 17:02:29 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:02:29 -0000
Received: by ggnu1 with SMTP id u1so80055224ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 09:02:27 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.42.136 as permitted sender) client-ip=10.50.42.136; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.42.136 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.42.136])
	by 10.50.42.136 with SMTP id o8mr3450338igl.38.1330448547408 (num_hops
	= 1); Tue, 28 Feb 2012 09:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=fJTKdDMzFYhk4M1DwyOleVyNRyR6lfYaMeo/p/F/T/A=;
	b=WqUmIinoHcyoSR8lBdECGpzBW2V/jKfK/OK2GATKlK7/XZoB5/qSMHjZPb9pgnO1KL
	mG3ro2YscOiQ7fvEtMzZXNEwXHWpZe6Qg9pvGBweF+Bwp0o1/H082961LDSYNdBQ5RDw
	g7+0HlbdkYfyAYXWjP+ia0DZ9ZkiV9tTgl1Rw=
MIME-Version: 1.0
Received: by 10.50.42.136 with SMTP id o8mr2859317igl.38.1330448547351; Tue,
	28 Feb 2012 09:02:27 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 09:02:27 -0800 (PST)
In-Reply-To: <CAFLBxZavBR0c_p1E9NpfkNzhrN-LCbtV=kPRwFZ3VFFMKPBNKg@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<CAFLBxZavBR0c_p1E9NpfkNzhrN-LCbtV=kPRwFZ3VFFMKPBNKg@mail.gmail.com>
Date: Tue, 28 Feb 2012 17:02:27 +0000
X-Google-Sender-Auth: sXjYQWE-tqP_SldhICu9MiqLvV8
Message-ID: <CAFLBxZbu_7Q2ZT1Ndtg_a0V9KmCbV+218EBaMa5GXt+-ovf7OA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@eu.citrix.com>
Subject: [Xen-devel] Fwd: [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Oops, forgot to reply-to-all...

---------- Forwarded message ----------
From: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, Feb 28, 2012 at 1:17 PM
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
To: Ian Campbell <Ian.Campbell@citrix.com>


On Fri, Feb 24, 2012 at 10:11 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
>> However, I'd say the main public "knobs" should be just consist of two
>> things:
>> * xl mem-set memory-target. =A0This is the minimum amount of physical RAM
>> a guest can get; we make sure that the sum of these for all VMs does not
>> exceed the host capacity.
>
> Isn't this what we've previously called mem-paging-set? We defined
> mem-set earlier as controlling the amount of RAM the guest _thinks_ it
> has, which is different.

No, I thought mem-set was supposed to be the Simple Knob, that the
user turned to say, "I don't care how you do it, just make the guest
take X amount of RAM". =A0The whole thing with the pagingdelay and all
that was how long and whether that Simple Knob would set the balloon
target first, before resorting to sharing. =A0Since the user can't
really control how much sharing happens, it makes sense to me for this
Simple Knob also be the "minimum memory this VM should get if all
extra pages from sharing suddenly disappear".

>> * xl sharing-policy [policy]. =A0This tells the sharing system how to use
>> the "windfall" pages gathered from page sharing.
>>
>> Then internally, the sharing system should combine the "minimum
>> footprint" with the number of extra pages and the policy to set the
>> amount of memory actually used (via balloon driver or paging).
>
> This is an argument in favour of mem-footprint-set rather than
> mem-paging set?
>
> Here is an updated version of my proposed interface which includes
> sharing, I think as you described (modulo the use of mem-paging-set
> where you said mem-set above).
>
> I also included "mem-paging-set manual" as an explicit thing with an
> error on "mem-paging-set N" if you don't switch to manual mode. This
> might be too draconian -- I'm not wedded to it.
>
> maxmem=3DX =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# maximum RAM t=
he domain can ever see
> memory=3DM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# current amoun=
t of RAM seen by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# domain

What do you mean "seen by the domain"?

If you mean "pages which aren't ballooned", then it looks an awful lot
to me like you're (perhaps unintentionally) smuggling back into the
interface "balloon target" and "paging target" (since "memory seen by
the domain" would then always be equal to "balloon target", and
"memory actually available" would always equal "paging target"). =A0I
thought the whole point was to hide all this complexity from the user,
unless she wants to see it?

Or am I misunderstanding something?

> paging=3D[off|on] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # allow the amount of m=
emory a guest
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# thinks i=
t has to differ from the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# amount a=
ctually available to it (its
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# "footpri=
nt")
> pagingauto=3D[off|on] (dflt=3Don) =A0 # enable automatic enforcement of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# "footpri=
nt" for guests which do not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# voluntar=
ily obey changes to memory=3DM
> pagingdelay=3D60 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# amount of time to g=
ive a guest to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# voluntar=
ily comply before enforcing a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# footprint
> pagesharing=3D[off|on] =A0 =A0 =A0 =A0 =A0 =A0# cause this guest to share=
 pages with
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# other si=
milarly enabled guests where
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# possible=
. Requires paging=3Don.
> pageextrapolocy=3D... =A0 =A0 =A0 =A0 =A0 =A0 # controls what happens to =
extra pages
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# gain via=
 sharing (could be combined
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# with pag=
esharing option:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# =A0 =A0 =
=A0 [off|policy|...])
>
> =A0 =A0 =A0 =A0Open question -- does pagesharing=3Don require paging=3Don=
? I've
> =A0 =A0 =A0 =A0tried to specify things below such that it does not, but it
> =A0 =A0 =A0 =A0might simplify things to require this.
>
> xl mem-set domain M
> =A0 =A0 =A0 =A0Sets the amount of RAM which the guest believes it has ava=
ilable
> =A0 =A0 =A0 =A0to M. The guest should arrange to use only that much RAM a=
nd
> =A0 =A0 =A0 =A0return the rest to the hypervisor (e.g. by using a balloon
> =A0 =A0 =A0 =A0driver). If the guest does not do so then the host may use
> =A0 =A0 =A0 =A0technical means to enforce the guest's footprint of M. The=
 guest
> =A0 =A0 =A0 =A0may suffer a performance penalty for this enforcement.
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 set balloon target to M.
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0set balloon target to M.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if pagingauto:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wait delay=
 IFF new target < old
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set paging=
 target to M
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support -t=
 <delay> to override default?
>
> =A0 =A0 =A0 =A0Open question -- if a domain balloons to M as requested sh=
ould
> =A0 =A0 =A0 =A0it still be subject to sharing? There is a performance hit
> =A0 =A0 =A0 =A0associated with sharing (far less than paging though?) but
> =A0 =A0 =A0 =A0presumably the admin would not have enabled sharing if they
> =A0 =A0 =A0 =A0didn't want this, therefore I think it is right for sharin=
g on
> =A0 =A0 =A0 =A0to allow the guest to actually have <M assigned to it. Mig=
ht be
> =A0 =A0 =A0 =A0a function of the individual sharing policy?
>
> xl mem-paging-set domain manual
> =A0 =A0 =A0 =A0Enables manual control of paging target.
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 error
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0set pagingauto=3Doff
> =A0 =A0 =A0 =A0sharing on: =A0 =A0 same as paging on.
>
> xl mem-paging-set domain N
> =A0 =A0 =A0 =A0Overrides the amount of RAM which the guest actually has
> =A0 =A0 =A0 =A0available (its "footprint") to N. The host will use techni=
cal
> =A0 =A0 =A0 =A0means to continue to provide the illusion to the guest tha=
t it
> =A0 =A0 =A0 =A0has memory=3DM (as adjusted by mem-set). There may be a
> =A0 =A0 =A0 =A0performance penalty for this.
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 error
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0if pagingauto=3Don:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set paging target
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set pagingauto=3Doff
>
> xl mem-paging-set domain auto
> =A0 =A0 =A0 =A0Automatically manage paging. Request that the guest uses
> =A0 =A0 =A0 =A0memory=3DM (current value of memory, as adjusted by mem-se=
t)
> =A0 =A0 =A0 =A0enforced when the guest is uncooperative (as described in
> =A0 =A0 =A0 =A0"mem-set")
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 error
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0set paging target to M
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set pagingauto=3Don
>
> xl mem-sharing-policy-set domain [policy]
> =A0 =A0 =A0 =A0Configures policy for use of extra pages.
>
> =A0 =A0 =A0 =A0if !paging || pagingauto:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If guest's actual usage drops below M due =
to sharing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0then extra pages are distributed per the s=
haring policy.
> =A0 =A0 =A0 =A0else:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If If guest's actual usage drops below N d=
ue to sharing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0then extra pages are distributed per the s=
haring policy.
>
> =A0 =A0 =A0 =A0TBD potential policies.
>
> =A0 =A0 =A0 =A0NB: shared pages reduce a domain's actual usage. Therefore=
 it is
> =A0 =A0 =A0 =A0possible that sharing reduces the usage to less than the p=
aging
> =A0 =A0 =A0 =A0target. In this case no pages will be paged out.
>
> We should ensure that the sum over for all domains of:
> =A0 =A0 =A0 =A0pagingauto(D)? M : N
> does not exceed the amount of host memory.
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:02:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:02:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2QRd-0004cO-4H; Tue, 28 Feb 2012 17:02:33 +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 1S2QRb-0004cJ-LA
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:02:32 +0000
Received: from [85.158.139.83:21894] by server-11.bemta-5.messagelabs.com id
	41/8B-14397-6A80D4F4; Tue, 28 Feb 2012 17:02:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330448548!9755198!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 426 invoked from network); 28 Feb 2012 17:02:29 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:02:29 -0000
Received: by ggnu1 with SMTP id u1so80055224ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 09:02:27 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.42.136 as permitted sender) client-ip=10.50.42.136; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.42.136 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.42.136])
	by 10.50.42.136 with SMTP id o8mr3450338igl.38.1330448547408 (num_hops
	= 1); Tue, 28 Feb 2012 09:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=fJTKdDMzFYhk4M1DwyOleVyNRyR6lfYaMeo/p/F/T/A=;
	b=WqUmIinoHcyoSR8lBdECGpzBW2V/jKfK/OK2GATKlK7/XZoB5/qSMHjZPb9pgnO1KL
	mG3ro2YscOiQ7fvEtMzZXNEwXHWpZe6Qg9pvGBweF+Bwp0o1/H082961LDSYNdBQ5RDw
	g7+0HlbdkYfyAYXWjP+ia0DZ9ZkiV9tTgl1Rw=
MIME-Version: 1.0
Received: by 10.50.42.136 with SMTP id o8mr2859317igl.38.1330448547351; Tue,
	28 Feb 2012 09:02:27 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 09:02:27 -0800 (PST)
In-Reply-To: <CAFLBxZavBR0c_p1E9NpfkNzhrN-LCbtV=kPRwFZ3VFFMKPBNKg@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<CAFLBxZavBR0c_p1E9NpfkNzhrN-LCbtV=kPRwFZ3VFFMKPBNKg@mail.gmail.com>
Date: Tue, 28 Feb 2012 17:02:27 +0000
X-Google-Sender-Auth: sXjYQWE-tqP_SldhICu9MiqLvV8
Message-ID: <CAFLBxZbu_7Q2ZT1Ndtg_a0V9KmCbV+218EBaMa5GXt+-ovf7OA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@eu.citrix.com>
Subject: [Xen-devel] Fwd: [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Oops, forgot to reply-to-all...

---------- Forwarded message ----------
From: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, Feb 28, 2012 at 1:17 PM
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
To: Ian Campbell <Ian.Campbell@citrix.com>


On Fri, Feb 24, 2012 at 10:11 AM, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
>> However, I'd say the main public "knobs" should be just consist of two
>> things:
>> * xl mem-set memory-target. =A0This is the minimum amount of physical RAM
>> a guest can get; we make sure that the sum of these for all VMs does not
>> exceed the host capacity.
>
> Isn't this what we've previously called mem-paging-set? We defined
> mem-set earlier as controlling the amount of RAM the guest _thinks_ it
> has, which is different.

No, I thought mem-set was supposed to be the Simple Knob, that the
user turned to say, "I don't care how you do it, just make the guest
take X amount of RAM". =A0The whole thing with the pagingdelay and all
that was how long and whether that Simple Knob would set the balloon
target first, before resorting to sharing. =A0Since the user can't
really control how much sharing happens, it makes sense to me for this
Simple Knob also be the "minimum memory this VM should get if all
extra pages from sharing suddenly disappear".

>> * xl sharing-policy [policy]. =A0This tells the sharing system how to use
>> the "windfall" pages gathered from page sharing.
>>
>> Then internally, the sharing system should combine the "minimum
>> footprint" with the number of extra pages and the policy to set the
>> amount of memory actually used (via balloon driver or paging).
>
> This is an argument in favour of mem-footprint-set rather than
> mem-paging set?
>
> Here is an updated version of my proposed interface which includes
> sharing, I think as you described (modulo the use of mem-paging-set
> where you said mem-set above).
>
> I also included "mem-paging-set manual" as an explicit thing with an
> error on "mem-paging-set N" if you don't switch to manual mode. This
> might be too draconian -- I'm not wedded to it.
>
> maxmem=3DX =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# maximum RAM t=
he domain can ever see
> memory=3DM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# current amoun=
t of RAM seen by the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# domain

What do you mean "seen by the domain"?

If you mean "pages which aren't ballooned", then it looks an awful lot
to me like you're (perhaps unintentionally) smuggling back into the
interface "balloon target" and "paging target" (since "memory seen by
the domain" would then always be equal to "balloon target", and
"memory actually available" would always equal "paging target"). =A0I
thought the whole point was to hide all this complexity from the user,
unless she wants to see it?

Or am I misunderstanding something?

> paging=3D[off|on] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # allow the amount of m=
emory a guest
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# thinks i=
t has to differ from the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# amount a=
ctually available to it (its
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# "footpri=
nt")
> pagingauto=3D[off|on] (dflt=3Don) =A0 # enable automatic enforcement of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# "footpri=
nt" for guests which do not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# voluntar=
ily obey changes to memory=3DM
> pagingdelay=3D60 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# amount of time to g=
ive a guest to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# voluntar=
ily comply before enforcing a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# footprint
> pagesharing=3D[off|on] =A0 =A0 =A0 =A0 =A0 =A0# cause this guest to share=
 pages with
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# other si=
milarly enabled guests where
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# possible=
. Requires paging=3Don.
> pageextrapolocy=3D... =A0 =A0 =A0 =A0 =A0 =A0 # controls what happens to =
extra pages
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# gain via=
 sharing (could be combined
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# with pag=
esharing option:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# =A0 =A0 =
=A0 [off|policy|...])
>
> =A0 =A0 =A0 =A0Open question -- does pagesharing=3Don require paging=3Don=
? I've
> =A0 =A0 =A0 =A0tried to specify things below such that it does not, but it
> =A0 =A0 =A0 =A0might simplify things to require this.
>
> xl mem-set domain M
> =A0 =A0 =A0 =A0Sets the amount of RAM which the guest believes it has ava=
ilable
> =A0 =A0 =A0 =A0to M. The guest should arrange to use only that much RAM a=
nd
> =A0 =A0 =A0 =A0return the rest to the hypervisor (e.g. by using a balloon
> =A0 =A0 =A0 =A0driver). If the guest does not do so then the host may use
> =A0 =A0 =A0 =A0technical means to enforce the guest's footprint of M. The=
 guest
> =A0 =A0 =A0 =A0may suffer a performance penalty for this enforcement.
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 set balloon target to M.
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0set balloon target to M.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if pagingauto:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wait delay=
 IFF new target < old
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set paging=
 target to M
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support -t=
 <delay> to override default?
>
> =A0 =A0 =A0 =A0Open question -- if a domain balloons to M as requested sh=
ould
> =A0 =A0 =A0 =A0it still be subject to sharing? There is a performance hit
> =A0 =A0 =A0 =A0associated with sharing (far less than paging though?) but
> =A0 =A0 =A0 =A0presumably the admin would not have enabled sharing if they
> =A0 =A0 =A0 =A0didn't want this, therefore I think it is right for sharin=
g on
> =A0 =A0 =A0 =A0to allow the guest to actually have <M assigned to it. Mig=
ht be
> =A0 =A0 =A0 =A0a function of the individual sharing policy?
>
> xl mem-paging-set domain manual
> =A0 =A0 =A0 =A0Enables manual control of paging target.
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 error
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0set pagingauto=3Doff
> =A0 =A0 =A0 =A0sharing on: =A0 =A0 same as paging on.
>
> xl mem-paging-set domain N
> =A0 =A0 =A0 =A0Overrides the amount of RAM which the guest actually has
> =A0 =A0 =A0 =A0available (its "footprint") to N. The host will use techni=
cal
> =A0 =A0 =A0 =A0means to continue to provide the illusion to the guest tha=
t it
> =A0 =A0 =A0 =A0has memory=3DM (as adjusted by mem-set). There may be a
> =A0 =A0 =A0 =A0performance penalty for this.
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 error
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0if pagingauto=3Don:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set paging target
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set pagingauto=3Doff
>
> xl mem-paging-set domain auto
> =A0 =A0 =A0 =A0Automatically manage paging. Request that the guest uses
> =A0 =A0 =A0 =A0memory=3DM (current value of memory, as adjusted by mem-se=
t)
> =A0 =A0 =A0 =A0enforced when the guest is uncooperative (as described in
> =A0 =A0 =A0 =A0"mem-set")
>
> =A0 =A0 =A0 =A0paging off: =A0 =A0 error
> =A0 =A0 =A0 =A0paging on: =A0 =A0 =A0set paging target to M
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set pagingauto=3Don
>
> xl mem-sharing-policy-set domain [policy]
> =A0 =A0 =A0 =A0Configures policy for use of extra pages.
>
> =A0 =A0 =A0 =A0if !paging || pagingauto:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If guest's actual usage drops below M due =
to sharing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0then extra pages are distributed per the s=
haring policy.
> =A0 =A0 =A0 =A0else:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If If guest's actual usage drops below N d=
ue to sharing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0then extra pages are distributed per the s=
haring policy.
>
> =A0 =A0 =A0 =A0TBD potential policies.
>
> =A0 =A0 =A0 =A0NB: shared pages reduce a domain's actual usage. Therefore=
 it is
> =A0 =A0 =A0 =A0possible that sharing reduces the usage to less than the p=
aging
> =A0 =A0 =A0 =A0target. In this case no pages will be paged out.
>
> We should ensure that the sum over for all domains of:
> =A0 =A0 =A0 =A0pagingauto(D)? M : N
> does not exceed the amount of host memory.
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:03:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2QST-0004gP-P8; Tue, 28 Feb 2012 17:03:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2QSR-0004fo-IC
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:03:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330448596!10673789!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27553 invoked from network); 28 Feb 2012 17:03:17 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:03:17 -0000
Received: by yhkk6 with SMTP id k6so53466247yhk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 09:03:15 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.181.169 as permitted sender) client-ip=10.50.181.169; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.181.169 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.181.169])
	by 10.50.181.169 with SMTP id dx9mr3428250igc.46.1330448595416
	(num_hops = 1); Tue, 28 Feb 2012 09:03:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=0LQIKHC4mEVW4zF+HzvKO12+OCvlvapEO+8cXlVDBsk=;
	b=fb5nPy8TdBFddqsev3dANSGbqOcRth4R0jrzTCSR+HlJ73yqfVnC4z20eztypfRsTi
	uQvf3ftZ8IbOeDb/EPrRWPwvpF0yXvkoa5M3ojRUs1aNhG+SUBtZF7ye7g3l2z5EW6ek
	aHAS2TCU1tO9OdhTbemhMOS/mPNT4l7oWhV4o=
MIME-Version: 1.0
Received: by 10.50.181.169 with SMTP id dx9mr2834741igc.46.1330448595351; Tue,
	28 Feb 2012 09:03:15 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 09:03:15 -0800 (PST)
In-Reply-To: <CAFLBxZapKUVaiz4e-VwGTwj0a0FOPij5hXrRkevrTC6brtug4Q@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
	<9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
	<CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
	<2fb7e1b28da3154380f570cc40a36ddc.squirrel@webmail.lagarcavilla.org>
	<CAFLBxZapKUVaiz4e-VwGTwj0a0FOPij5hXrRkevrTC6brtug4Q@mail.gmail.com>
Date: Tue, 28 Feb 2012 17:03:15 +0000
X-Google-Sender-Auth: hIu57pvTbNhR94oUM_ovPb7O0eU
Message-ID: <CAFLBxZarzACVuKABdG9qhUS4GtgiM5sKDVFn6UkvTg1JO7rdYw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com, 
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: [Xen-devel] Fwd: [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once again, didn't reply-to-all.  (Hmm, I'm pretty sure I actually did...)
 -George

---------- Forwarded message ----------
From: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, Feb 28, 2012 at 3:43 PM
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
To: andres@lagarcavilla.org


On Tue, Feb 28, 2012 at 3:25 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>> On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>>>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>>>> shared page gains you nothing. The ballooner can't know what is shared
>>>>> and what isn't, in order to make an educated decision. And the sharer
>>>>> can't foresee what the balloon will victimize.
>>>>
>>>> Doesn't ballooning generally evict unused pages, because it allocates
>>>> new _free_ pages, even if they were shared is there any benefit to
>>>> doing
>>>> so?
>>>
>>> Certainly the balloon will pick free pages. The sharing daemon should
>>> not
>>> have shared those, but it's not unlikely that it will have.
>>>
>>> It's a classic semantic gap problem, and we were discussing this in the
>>> context of paging ("the pager should not have paged out page table
>>> pages")
>>>
>>> Beyond free pages, a prime target for sharing are read-only disk buffers
>>> in the page cache. Those are victim #2 for the balloon.
>>
>> Not exactly -- victim #2 would be read-only disk buffers *which have
>> not been read recently*.
>
> Everything's been read recently in Windows. Seriously ;)

Uum, do you really mean to say that Windows doesn't use the accessed
bit to try to find which pages are in active use? =A0That's rather
surprising.

>> Buffers which are in active use will not be
>> evicted. =A0So although evicting these pages from the guests' cache
>> doesn't buy the system any more memory, it doesn't have a major impact
>> on the guest either.
>
> That's debatable. Maybe guests shouldn't have a page cache then. Or a
> really small one.
>
> I'm not saying you're wrong, I'm saying that the answer is, as with many
> things, "it depends"

Sure, it depends. If there's lots of free memory, then sure, keep the
stuff around; maybe it will come in handy. =A0If memory is tight, then
the ideal is to have the pages which are actually used frequently --
whether they're in the page cache or elsewhere -- kept in memory, and
the rest paged out to disk / handed back to Xen.

>> In any case, if the guest experiences its own internal memory
>> pressure, these pages will be the first to go anyway. =A0After that, it
>> will go for trying to evict infrequently-used read-write pages --
>> which, if the pager is active, will already have been paged out to
>> disk; thus we'll end up with the double-paging problem. =A0This will
>> have a much larger impact on performance than uselessly evicting
>> little-used read-only pages.
>>
>> So I think that even though sharing+balloon will lead to some
>> occasional sub-optimal behavior, it's still a lot better than
>> sharing+paging and no ballooning. =A0Remember that ballooning was a
>> technique introduced in the paper by VMWare that talked about page
>> sharing -- they obviously thought sharing+ballooning was better than
>> sharing+paging.
>
> Ties in with Dan's thread. Depends on how much effort you spend choosing
> sharing and paging candidates, and how hard you inflate the balloon. I'm
> not in favor of any such overarching statement (even though I made one
> myself!!).

Yes, but at some point, if we want people to use this stuff, we have
to have a simple answer for xl, and recommendations for more
complicated answers. =A0I think re the "simple answer" possibilities for
xl and sharing, I think we have:
* Take whatever advantage of sharing we can; if we need to reduce
guest footprint (i.e., actual memory used), use ballooning first,
paging only afterwards
* Take whatever advantage of sharing we can; if we need to reduce
guest footprint, use only paging.

The first, as you say will have the disadvantage that early ballooning
will reduce sharing without getting memory back, but later ballooning
will evict pages properly without risking double paging. =A0The second
has the advantage that early paging will keep shared pages longer, but
the disadvantage that when the guest starts paging, you'll run into
the double paging problem. =A0As a cost-benefits analysis, I think the
second comes out worse.

(Of course, someone running some actual numbers would be the final
answer for this one, but I'm not sure anyone has the time or
inclination to do that at this point.)

Now, a really clever toolstack could use paging first, and then switch
to ballooning if it detects significant double-paging. =A0But I think
that's more than we want from xl.

=A0-George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:03:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2QST-0004gP-P8; Tue, 28 Feb 2012 17:03:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2QSR-0004fo-IC
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:03:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330448596!10673789!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27553 invoked from network); 28 Feb 2012 17:03:17 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:03:17 -0000
Received: by yhkk6 with SMTP id k6so53466247yhk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 09:03:15 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.181.169 as permitted sender) client-ip=10.50.181.169; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.181.169 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.181.169])
	by 10.50.181.169 with SMTP id dx9mr3428250igc.46.1330448595416
	(num_hops = 1); Tue, 28 Feb 2012 09:03:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=0LQIKHC4mEVW4zF+HzvKO12+OCvlvapEO+8cXlVDBsk=;
	b=fb5nPy8TdBFddqsev3dANSGbqOcRth4R0jrzTCSR+HlJ73yqfVnC4z20eztypfRsTi
	uQvf3ftZ8IbOeDb/EPrRWPwvpF0yXvkoa5M3ojRUs1aNhG+SUBtZF7ye7g3l2z5EW6ek
	aHAS2TCU1tO9OdhTbemhMOS/mPNT4l7oWhV4o=
MIME-Version: 1.0
Received: by 10.50.181.169 with SMTP id dx9mr2834741igc.46.1330448595351; Tue,
	28 Feb 2012 09:03:15 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Tue, 28 Feb 2012 09:03:15 -0800 (PST)
In-Reply-To: <CAFLBxZapKUVaiz4e-VwGTwj0a0FOPij5hXrRkevrTC6brtug4Q@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<c9734d9a7e84ac0f1c3ba2b3d4ead923.squirrel@webmail.lagarcavilla.org>
	<1330335877.8557.253.camel@zakaz.uk.xensource.com>
	<9ca33a90d00fa202b73ba94abe14a2b5.squirrel@webmail.lagarcavilla.org>
	<CAFLBxZac5qHoQdCjE3kpzcEB7-AuKZU7svJ_yq8dDgZ3MNSNow@mail.gmail.com>
	<2fb7e1b28da3154380f570cc40a36ddc.squirrel@webmail.lagarcavilla.org>
	<CAFLBxZapKUVaiz4e-VwGTwj0a0FOPij5hXrRkevrTC6brtug4Q@mail.gmail.com>
Date: Tue, 28 Feb 2012 17:03:15 +0000
X-Google-Sender-Auth: hIu57pvTbNhR94oUM_ovPb7O0eU
Message-ID: <CAFLBxZarzACVuKABdG9qhUS4GtgiM5sKDVFn6UkvTg1JO7rdYw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com, 
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: [Xen-devel] Fwd: [PATCH] RFC: initial libxl support for xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once again, didn't reply-to-all.  (Hmm, I'm pretty sure I actually did...)
 -George

---------- Forwarded message ----------
From: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, Feb 28, 2012 at 3:43 PM
Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging
To: andres@lagarcavilla.org


On Tue, Feb 28, 2012 at 3:25 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>> On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
>> <andres@lagarcavilla.org> wrote:
>>>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>>>> shared page gains you nothing. The ballooner can't know what is shared
>>>>> and what isn't, in order to make an educated decision. And the sharer
>>>>> can't foresee what the balloon will victimize.
>>>>
>>>> Doesn't ballooning generally evict unused pages, because it allocates
>>>> new _free_ pages, even if they were shared is there any benefit to
>>>> doing
>>>> so?
>>>
>>> Certainly the balloon will pick free pages. The sharing daemon should
>>> not
>>> have shared those, but it's not unlikely that it will have.
>>>
>>> It's a classic semantic gap problem, and we were discussing this in the
>>> context of paging ("the pager should not have paged out page table
>>> pages")
>>>
>>> Beyond free pages, a prime target for sharing are read-only disk buffers
>>> in the page cache. Those are victim #2 for the balloon.
>>
>> Not exactly -- victim #2 would be read-only disk buffers *which have
>> not been read recently*.
>
> Everything's been read recently in Windows. Seriously ;)

Uum, do you really mean to say that Windows doesn't use the accessed
bit to try to find which pages are in active use? =A0That's rather
surprising.

>> Buffers which are in active use will not be
>> evicted. =A0So although evicting these pages from the guests' cache
>> doesn't buy the system any more memory, it doesn't have a major impact
>> on the guest either.
>
> That's debatable. Maybe guests shouldn't have a page cache then. Or a
> really small one.
>
> I'm not saying you're wrong, I'm saying that the answer is, as with many
> things, "it depends"

Sure, it depends. If there's lots of free memory, then sure, keep the
stuff around; maybe it will come in handy. =A0If memory is tight, then
the ideal is to have the pages which are actually used frequently --
whether they're in the page cache or elsewhere -- kept in memory, and
the rest paged out to disk / handed back to Xen.

>> In any case, if the guest experiences its own internal memory
>> pressure, these pages will be the first to go anyway. =A0After that, it
>> will go for trying to evict infrequently-used read-write pages --
>> which, if the pager is active, will already have been paged out to
>> disk; thus we'll end up with the double-paging problem. =A0This will
>> have a much larger impact on performance than uselessly evicting
>> little-used read-only pages.
>>
>> So I think that even though sharing+balloon will lead to some
>> occasional sub-optimal behavior, it's still a lot better than
>> sharing+paging and no ballooning. =A0Remember that ballooning was a
>> technique introduced in the paper by VMWare that talked about page
>> sharing -- they obviously thought sharing+ballooning was better than
>> sharing+paging.
>
> Ties in with Dan's thread. Depends on how much effort you spend choosing
> sharing and paging candidates, and how hard you inflate the balloon. I'm
> not in favor of any such overarching statement (even though I made one
> myself!!).

Yes, but at some point, if we want people to use this stuff, we have
to have a simple answer for xl, and recommendations for more
complicated answers. =A0I think re the "simple answer" possibilities for
xl and sharing, I think we have:
* Take whatever advantage of sharing we can; if we need to reduce
guest footprint (i.e., actual memory used), use ballooning first,
paging only afterwards
* Take whatever advantage of sharing we can; if we need to reduce
guest footprint, use only paging.

The first, as you say will have the disadvantage that early ballooning
will reduce sharing without getting memory back, but later ballooning
will evict pages properly without risking double paging. =A0The second
has the advantage that early paging will keep shared pages longer, but
the disadvantage that when the guest starts paging, you'll run into
the double paging problem. =A0As a cost-benefits analysis, I think the
second comes out worse.

(Of course, someone running some actual numbers would be the final
answer for this one, but I'm not sure anyone has the time or
inclination to do that at this point.)

Now, a really clever toolstack could use paging first, and then switch
to ballooning if it detects significant double-paging. =A0But I think
that's more than we want from xl.

=A0-George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:12:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Qat-00059c-Ga; Tue, 28 Feb 2012 17:12: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 1S2Qas-00059U-Cm
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:12:06 +0000
Received: from [85.158.139.83:18693] by server-1.bemta-5.messagelabs.com id
	99/FF-28458-5EA0D4F4; Tue, 28 Feb 2012 17:12:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330449124!16235385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15084 invoked from network); 28 Feb 2012 17:12:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:12:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 17:12:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 17:12:04 +0000
Message-ID: <1330449123.4270.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 28 Feb 2012 17:12:03 +0000
In-Reply-To: <CAFLBxZbu_7Q2ZT1Ndtg_a0V9KmCbV+218EBaMa5GXt+-ovf7OA@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<CAFLBxZavBR0c_p1E9NpfkNzhrN-LCbtV=kPRwFZ3VFFMKPBNKg@mail.gmail.com>
	<CAFLBxZbu_7Q2ZT1Ndtg_a0V9KmCbV+218EBaMa5GXt+-ovf7OA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: [PATCH] RFC: initial libxl support for
 xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 13:17 +0000, George Dunlap wrote:
> On Fri, Feb 24, 2012 at 10:11 AM, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> >> However, I'd say the main public "knobs" should be just consist of
two
> >> things:
> >> * xl mem-set memory-target.  This is the minimum amount of physical
RAM
> >> a guest can get; we make sure that the sum of these for all VMs
does not
> >> exceed the host capacity.
> >
> > Isn't this what we've previously called mem-paging-set? We defined
> > mem-set earlier as controlling the amount of RAM the guest _thinks_
it
> > has, which is different.
> 
> No, I thought mem-set was supposed to be the Simple Knob, that the
> user turned to say, "I don't care how you do it, just make the guest
> take X amount of RAM".  The whole thing with the pagingdelay and all
> that was how long and whether that Simple Knob would set the balloon
> target first, before resorting to sharing.  Since the user can't
> really control how much sharing happens, it makes sense to me for this
> Simple Knob also be the "minimum memory this VM should get if all
> extra pages from sharing suddenly disappear".

I think you might be correct. I suspect I wrote the above before I had
fully integrated sharing into my understanding/proposal (I took a few
iteration locally to get it "right")

I don't think this filtered into the actual interface proposal, or do
you see somewhere which it did (modulo the discussion below)?

> >> * xl sharing-policy [policy].  This tells the sharing system how to
use
> >> the "windfall" pages gathered from page sharing.
> >>
> >> Then internally, the sharing system should combine the "minimum
> >> footprint" with the number of extra pages and the policy to set the
> >> amount of memory actually used (via balloon driver or paging).
> >
> > This is an argument in favour of mem-footprint-set rather than
> > mem-paging set?
> >
> > Here is an updated version of my proposed interface which includes
> > sharing, I think as you described (modulo the use of mem-paging-set
> > where you said mem-set above).
> >
> > I also included "mem-paging-set manual" as an explicit thing with an
> > error on "mem-paging-set N" if you don't switch to manual mode. This
> > might be too draconian -- I'm not wedded to it.
> >
> > maxmem=X                        # maximum RAM the domain can ever
see
> > memory=M                        # current amount of RAM seen by the
> >                                # domain
> 
> What do you mean "seen by the domain"?

> If you mean "pages which aren't ballooned", then it looks an awful lot
> to me like you're (perhaps unintentionally) smuggling back into the
> interface "balloon target" and "paging target" (since "memory seen by
> the domain" would then always be equal to "balloon target", and
> "memory actually available" would always equal "paging target").  I
> thought the whole point was to hide all this complexity from the user,
> unless she wants to see it?
> 
> Or am I misunderstanding something?

Pages which the guest sees is not the same as ballooning target if the
guest has not met the target. So e.g. if a guest is using 10M and we do
"mem-set 6M" but the guest only balloons to 8M then the amount of RAM
"currently seen" by the guest is 8M not 6M.

In this situation we would eventually decide to use paging at which
point the actual RAM used by the guest would drop to 6M but as far as
the guest knows it is still using 8M, e.g. it "currently sees" 8M while
"memory actually available" is 6M. Also the balloon target remains 6M
because we expect the guest to keep on trying.

You are right though that for a well behaved guest there will be no
practical difference between the balloon target and the amount of RAM
seen by the guest, at least so long as ballooning is the mechanism by
which we expect guest to meet these targets.

I don't mention sharing in the above because all sharing does is reduce
the memory the guest "actually" has below what it "thinks" it has. So it
might be that we do "mem-set 6M" and that the guest makes it to 8M but
that 1M is shared. At which point we have "guest sees" == 8M and
"actual" == 8-1 == 7M. Eventually we would enable paging to reach the
desired "actual" == 6M, presumably by paging out an addition 1M.

If at this point all of the guests pages suddenly become unshared then
the pager will kick in and the amount of paged memory will presumably
grow to 2M, maintaining the actual target of "6M"

Another scenario would be where we mem-set 6M and the guest does
actually meet that target, so "guest sees" == "actual" == 6M and there
is no sharing or paging. If at this point we detect 1M worth of sharable
pages, so now "guest sees" == 6M but "actual" == "5M" and we have 1M of
spare memory to distribute as per the sharing policy.

If the policy is such that we need to guarantee to be able to give the
guest 6M again if it ends up unsharing everything then the sharing
policy would only allow us to use that memory for "ephemeral" purposes.

If the sharing policy does not guarantee that we can get that memory
back then we may find ourselves in a situation where "guest sees" == 6M
but "actual" == 5M, with the slack made up for by paging and not
sharing, despite having done "mem-set 6M". IMHO the user was effectively
asking for this (or at least acknowledging the possibility) when they
chose that sharing policy. In this case the paging target would still be
6M and the pager would, I presume, be actively trying to reduce the
amount of paged RAM, such that if some RAM becomes available it would
suck it up and move closer to "actual" == 6M.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:12:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Qat-00059c-Ga; Tue, 28 Feb 2012 17:12: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 1S2Qas-00059U-Cm
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:12:06 +0000
Received: from [85.158.139.83:18693] by server-1.bemta-5.messagelabs.com id
	99/FF-28458-5EA0D4F4; Tue, 28 Feb 2012 17:12:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330449124!16235385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15084 invoked from network); 28 Feb 2012 17:12:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:12:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10989827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 17:12:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 17:12:04 +0000
Message-ID: <1330449123.4270.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 28 Feb 2012 17:12:03 +0000
In-Reply-To: <CAFLBxZbu_7Q2ZT1Ndtg_a0V9KmCbV+218EBaMa5GXt+-ovf7OA@mail.gmail.com>
References: <1329486241.3131.81.camel@zakaz.uk.xensource.com>
	<20120217142505.GA10523@aepfle.de>
	<1329490712.3131.97.camel@zakaz.uk.xensource.com>
	<20120217152443.GA16995@aepfle.de>
	<1329492796.3131.104.camel@zakaz.uk.xensource.com>
	<20120217154346.GA19731@aepfle.de>
	<1329494069.3131.109.camel@zakaz.uk.xensource.com>
	<20120217160341.GA22266@aepfle.de>
	<1329496998.3131.131.camel@zakaz.uk.xensource.com>
	<CAFLBxZafgFbuYTY+QNObn_5=vbK1mJ4B=GoOsK4=fJ9BJLRE1A@mail.gmail.com>
	<20120220111230.GA5856@aepfle.de>
	<CAFLBxZYEVaQY4kTX7GrOhno0sK2a3Q81eF7vVPBVjKB+3jnA6Q@mail.gmail.com>
	<1329818358.25232.64.camel@dagon.hellion.org.uk>
	<1329826841.2196.85.camel@elijah>
	<1329993761.8557.66.camel@zakaz.uk.xensource.com>
	<1329999531.19361.74.camel@elijah>
	<1330078304.8557.157.camel@zakaz.uk.xensource.com>
	<CAFLBxZavBR0c_p1E9NpfkNzhrN-LCbtV=kPRwFZ3VFFMKPBNKg@mail.gmail.com>
	<CAFLBxZbu_7Q2ZT1Ndtg_a0V9KmCbV+218EBaMa5GXt+-ovf7OA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Fwd: [PATCH] RFC: initial libxl support for
 xenpaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 13:17 +0000, George Dunlap wrote:
> On Fri, Feb 24, 2012 at 10:11 AM, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> >> However, I'd say the main public "knobs" should be just consist of
two
> >> things:
> >> * xl mem-set memory-target.  This is the minimum amount of physical
RAM
> >> a guest can get; we make sure that the sum of these for all VMs
does not
> >> exceed the host capacity.
> >
> > Isn't this what we've previously called mem-paging-set? We defined
> > mem-set earlier as controlling the amount of RAM the guest _thinks_
it
> > has, which is different.
> 
> No, I thought mem-set was supposed to be the Simple Knob, that the
> user turned to say, "I don't care how you do it, just make the guest
> take X amount of RAM".  The whole thing with the pagingdelay and all
> that was how long and whether that Simple Knob would set the balloon
> target first, before resorting to sharing.  Since the user can't
> really control how much sharing happens, it makes sense to me for this
> Simple Knob also be the "minimum memory this VM should get if all
> extra pages from sharing suddenly disappear".

I think you might be correct. I suspect I wrote the above before I had
fully integrated sharing into my understanding/proposal (I took a few
iteration locally to get it "right")

I don't think this filtered into the actual interface proposal, or do
you see somewhere which it did (modulo the discussion below)?

> >> * xl sharing-policy [policy].  This tells the sharing system how to
use
> >> the "windfall" pages gathered from page sharing.
> >>
> >> Then internally, the sharing system should combine the "minimum
> >> footprint" with the number of extra pages and the policy to set the
> >> amount of memory actually used (via balloon driver or paging).
> >
> > This is an argument in favour of mem-footprint-set rather than
> > mem-paging set?
> >
> > Here is an updated version of my proposed interface which includes
> > sharing, I think as you described (modulo the use of mem-paging-set
> > where you said mem-set above).
> >
> > I also included "mem-paging-set manual" as an explicit thing with an
> > error on "mem-paging-set N" if you don't switch to manual mode. This
> > might be too draconian -- I'm not wedded to it.
> >
> > maxmem=X                        # maximum RAM the domain can ever
see
> > memory=M                        # current amount of RAM seen by the
> >                                # domain
> 
> What do you mean "seen by the domain"?

> If you mean "pages which aren't ballooned", then it looks an awful lot
> to me like you're (perhaps unintentionally) smuggling back into the
> interface "balloon target" and "paging target" (since "memory seen by
> the domain" would then always be equal to "balloon target", and
> "memory actually available" would always equal "paging target").  I
> thought the whole point was to hide all this complexity from the user,
> unless she wants to see it?
> 
> Or am I misunderstanding something?

Pages which the guest sees is not the same as ballooning target if the
guest has not met the target. So e.g. if a guest is using 10M and we do
"mem-set 6M" but the guest only balloons to 8M then the amount of RAM
"currently seen" by the guest is 8M not 6M.

In this situation we would eventually decide to use paging at which
point the actual RAM used by the guest would drop to 6M but as far as
the guest knows it is still using 8M, e.g. it "currently sees" 8M while
"memory actually available" is 6M. Also the balloon target remains 6M
because we expect the guest to keep on trying.

You are right though that for a well behaved guest there will be no
practical difference between the balloon target and the amount of RAM
seen by the guest, at least so long as ballooning is the mechanism by
which we expect guest to meet these targets.

I don't mention sharing in the above because all sharing does is reduce
the memory the guest "actually" has below what it "thinks" it has. So it
might be that we do "mem-set 6M" and that the guest makes it to 8M but
that 1M is shared. At which point we have "guest sees" == 8M and
"actual" == 8-1 == 7M. Eventually we would enable paging to reach the
desired "actual" == 6M, presumably by paging out an addition 1M.

If at this point all of the guests pages suddenly become unshared then
the pager will kick in and the amount of paged memory will presumably
grow to 2M, maintaining the actual target of "6M"

Another scenario would be where we mem-set 6M and the guest does
actually meet that target, so "guest sees" == "actual" == 6M and there
is no sharing or paging. If at this point we detect 1M worth of sharable
pages, so now "guest sees" == 6M but "actual" == "5M" and we have 1M of
spare memory to distribute as per the sharing policy.

If the policy is such that we need to guarantee to be able to give the
guest 6M again if it ends up unsharing everything then the sharing
policy would only allow us to use that memory for "ephemeral" purposes.

If the sharing policy does not guarantee that we can get that memory
back then we may find ourselves in a situation where "guest sees" == 6M
but "actual" == 5M, with the slack made up for by paging and not
sharing, despite having done "mem-set 6M". IMHO the user was effectively
asking for this (or at least acknowledging the possibility) when they
chose that sharing policy. In this case the paging target would still be
6M and the pager would, I presume, be actively trying to reduce the
amount of paged RAM, such that if some RAM becomes available it would
suck it up and move closer to "actual" == 6M.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:25:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Qnr-0005Yf-Uh; Tue, 28 Feb 2012 17:25:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S2Qnp-0005Y6-Nb
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:25:29 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330449923!15344077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7624 invoked from network); 28 Feb 2012 17:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10990086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 17:25:23 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 17:25:23 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4c425ca35c4b8ea7c2b9bfb0f0ce92482ea4314a
Message-ID: <4c425ca35c4b8ea7c2b9.1330449973@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 28 Feb 2012 17:26:13 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] [PATCH v3] Add the bios option to specify the
	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Differences with previous revision:
- Rename of libxl_bios_types into libxl_bios_type
- Improvement to the manpage, discussed with Ian

diff -r adcd6ab160fa -r 4c425ca35c4b docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Feb 28 17:25:37 2012 +0000
@@ -430,6 +430,30 @@ accept the defaults for these options wh
 
 =over 4
 
+=item B<bios="STRING">
+
+Select the virtual firmware that is exposed to the guest.
+By default, a guess is operated based on the device model, but sometimes
+it may be useful to force a different one, like UEFI.
+
+=over 4
+
+=item B<rombios>
+
+Load a traditional x86 BIOS used by default when device_model_version=qemu-xen-traditional. This is the only BIOS option supported when device_model_version=qemu-xen-traditional.
+
+=item B<seabios>
+
+Loads SeaBIOS, a 16-bit x86 compatbile BIOS. This is used by default
+with device_model_version=qemu-xen.
+
+=item B<ovmf>
+
+Loads OVMF, a standard UEFI firmware by Tianocore project. It can only
+be enabled via the B<bios> option. Requires device_model_version=qemu-xen.
+
+=back
+
 =item B<pae=BOOLEAN>
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Tue Feb 28 17:25:37 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = 0;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Feb 28 17:25:37 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return libxl_bios_type_to_string(info->u.hvm.bios);
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Feb 28 17:25:37 2012 +0000
@@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+libxl_bios_type = Enumeration("bios_type", [
+    (1, "rombios"),
+    (2, "seabios"),
+    (3, "ovmf"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", libxl_bios_type),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 28 17:25:37 2012 +0000
@@ -704,6 +704,12 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
+            libxl_bios_type_from_string(buf, &b_info->u.hvm.bios)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
+                    buf);
+                exit (1);
+        }
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:25:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Qnr-0005Yf-Uh; Tue, 28 Feb 2012 17:25:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S2Qnp-0005Y6-Nb
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:25:29 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330449923!15344077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7624 invoked from network); 28 Feb 2012 17:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10990086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 17:25:23 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 17:25:23 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4c425ca35c4b8ea7c2b9bfb0f0ce92482ea4314a
Message-ID: <4c425ca35c4b8ea7c2b9.1330449973@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 28 Feb 2012 17:26:13 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] [PATCH v3] Add the bios option to specify the
	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Differences with previous revision:
- Rename of libxl_bios_types into libxl_bios_type
- Improvement to the manpage, discussed with Ian

diff -r adcd6ab160fa -r 4c425ca35c4b docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Feb 28 17:25:37 2012 +0000
@@ -430,6 +430,30 @@ accept the defaults for these options wh
 
 =over 4
 
+=item B<bios="STRING">
+
+Select the virtual firmware that is exposed to the guest.
+By default, a guess is operated based on the device model, but sometimes
+it may be useful to force a different one, like UEFI.
+
+=over 4
+
+=item B<rombios>
+
+Load a traditional x86 BIOS used by default when device_model_version=qemu-xen-traditional. This is the only BIOS option supported when device_model_version=qemu-xen-traditional.
+
+=item B<seabios>
+
+Loads SeaBIOS, a 16-bit x86 compatbile BIOS. This is used by default
+with device_model_version=qemu-xen.
+
+=item B<ovmf>
+
+Loads OVMF, a standard UEFI firmware by Tianocore project. It can only
+be enabled via the B<bios> option. Requires device_model_version=qemu-xen.
+
+=back
+
 =item B<pae=BOOLEAN>
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Tue Feb 28 17:25:37 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = 0;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Feb 28 17:25:37 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return libxl_bios_type_to_string(info->u.hvm.bios);
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Feb 28 17:25:37 2012 +0000
@@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+libxl_bios_type = Enumeration("bios_type", [
+    (1, "rombios"),
+    (2, "seabios"),
+    (3, "ovmf"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", libxl_bios_type),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r adcd6ab160fa -r 4c425ca35c4b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Feb 28 17:25:37 2012 +0000
@@ -704,6 +704,12 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
+            libxl_bios_type_from_string(buf, &b_info->u.hvm.bios)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
+                    buf);
+                exit (1);
+        }
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:42:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2R3W-0005ls-IO; Tue, 28 Feb 2012 17:41: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 1S2R3V-0005ln-3o
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:41:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330450864!58716139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22865 invoked from network); 28 Feb 2012 17:41:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10990678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 17:41:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 17:41:09 +0000
Message-ID: <1330450868.4270.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Tue, 28 Feb 2012 17:41:08 +0000
In-Reply-To: <4c425ca35c4b8ea7c2b9.1330449973@dhcp-3-145.uk.xensource.com>
References: <4c425ca35c4b8ea7c2b9.1330449973@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v3] Add the bios option to specify
 the bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 17:26 +0000, Attilio Rao wrote:
> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ---
> 
> Differences with previous revision:
> - Rename of libxl_bios_types into libxl_bios_type
> - Improvement to the manpage, discussed with Ian
> 
> diff -r adcd6ab160fa -r 4c425ca35c4b docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
> +++ b/docs/man/xl.cfg.pod.5	Tue Feb 28 17:25:37 2012 +0000
> @@ -430,6 +430,30 @@ accept the defaults for these options wh
>  
>  =over 4
>  
> +=item B<bios="STRING">
> +
> +Select the virtual firmware that is exposed to the guest.
> +By default, a guess is operated based on the device model, but sometimes

"...a guess is made based on ..."

> +it may be useful to force a different one, like UEFI.

I'd say "configure" or "request" rather than "force", force sounds like
it's not recommended or something.

> +
> +=over 4
> +
> +=item B<rombios>
> +
> +Load a traditional x86 BIOS used by default when device_model_version=qemu-xen-traditional. This is the only BIOS option supported when device_model_version=qemu-xen-traditional.

Very long line. Please wrap to < 80 cols.

This paragraph looks very different to the SeaBIOS and OVMF ones,
structure-wise which is a little jarring . Also rombios is no more or
less "traditional" or "16 bit x86 compatible" than SeaBIOS is. It's just
that SeaBIOS is better code and better maintained so we are
transitioning to it along with the upstream qemu transition.

I think I'd say something like the following:

        Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default
        when device_model_version=qemu-xen-traditional. This is the only BIOS
        option supported when device_model_version=qemu-xen-traditional. This is
        the BIOS used by all previous Xen versions.

> +
> +=item B<seabios>
> +
> +Loads SeaBIOS, a 16-bit x86 compatbile BIOS. This is used by default

                              compatible

> +with device_model_version=qemu-xen.
> +
> +=item B<ovmf>
> +
> +Loads OVMF, a standard UEFI firmware by Tianocore project. It can only
> +be enabled via the B<bios> option.

I think this last sentence is implicit in the fact that it is not the
default.

>  Requires device_model_version=qemu-xen.
> +
> +=back
> +
>  =item B<pae=BOOLEAN>
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:42:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2R3W-0005ls-IO; Tue, 28 Feb 2012 17:41: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 1S2R3V-0005ln-3o
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:41:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330450864!58716139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22865 invoked from network); 28 Feb 2012 17:41:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10990678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 17:41:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 17:41:09 +0000
Message-ID: <1330450868.4270.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Attilio Rao <attilio.rao@citrix.com>
Date: Tue, 28 Feb 2012 17:41:08 +0000
In-Reply-To: <4c425ca35c4b8ea7c2b9.1330449973@dhcp-3-145.uk.xensource.com>
References: <4c425ca35c4b8ea7c2b9.1330449973@dhcp-3-145.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v3] Add the bios option to specify
 the bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 17:26 +0000, Attilio Rao wrote:
> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> ---
> 
> Differences with previous revision:
> - Rename of libxl_bios_types into libxl_bios_type
> - Improvement to the manpage, discussed with Ian
> 
> diff -r adcd6ab160fa -r 4c425ca35c4b docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
> +++ b/docs/man/xl.cfg.pod.5	Tue Feb 28 17:25:37 2012 +0000
> @@ -430,6 +430,30 @@ accept the defaults for these options wh
>  
>  =over 4
>  
> +=item B<bios="STRING">
> +
> +Select the virtual firmware that is exposed to the guest.
> +By default, a guess is operated based on the device model, but sometimes

"...a guess is made based on ..."

> +it may be useful to force a different one, like UEFI.

I'd say "configure" or "request" rather than "force", force sounds like
it's not recommended or something.

> +
> +=over 4
> +
> +=item B<rombios>
> +
> +Load a traditional x86 BIOS used by default when device_model_version=qemu-xen-traditional. This is the only BIOS option supported when device_model_version=qemu-xen-traditional.

Very long line. Please wrap to < 80 cols.

This paragraph looks very different to the SeaBIOS and OVMF ones,
structure-wise which is a little jarring . Also rombios is no more or
less "traditional" or "16 bit x86 compatible" than SeaBIOS is. It's just
that SeaBIOS is better code and better maintained so we are
transitioning to it along with the upstream qemu transition.

I think I'd say something like the following:

        Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default
        when device_model_version=qemu-xen-traditional. This is the only BIOS
        option supported when device_model_version=qemu-xen-traditional. This is
        the BIOS used by all previous Xen versions.

> +
> +=item B<seabios>
> +
> +Loads SeaBIOS, a 16-bit x86 compatbile BIOS. This is used by default

                              compatible

> +with device_model_version=qemu-xen.
> +
> +=item B<ovmf>
> +
> +Loads OVMF, a standard UEFI firmware by Tianocore project. It can only
> +be enabled via the B<bios> option.

I think this last sentence is implicit in the fact that it is not the
default.

>  Requires device_model_version=qemu-xen.
> +
> +=back
> +
>  =item B<pae=BOOLEAN>
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:45:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2R6k-0005s9-5K; Tue, 28 Feb 2012 17:45:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S2R6i-0005rt-GD
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 17:45:00 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330451092!16550707!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11622 invoked from network); 28 Feb 2012 17:44:53 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-5.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 17:44:53 -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 6180016296
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 17:44:51 +0000 (GMT)
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 7O-WnLMzAJRm for <xen-devel@lists.xen.org>;
	Tue, 28 Feb 2012 17:44:49 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id 1226616295
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 17:44:48 +0000 (GMT)
Message-ID: <4F4D1291.6010705@abpni.co.uk>
Date: Tue, 28 Feb 2012 17:44:49 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] CVE-2011-1166
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Everyone,

I'm currently looking at CVE-2011-1166:

http://securitytracker.com/id/1025226

Am I correct in saying that this issue is fixed in the latest stable 4.x 
branch, but not in the 3.4.4 release? I see the fix here:

http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8

however I do not see the same fix applied in 3.4.4:

http://xenbits.xen.org/hg/xen-3.4-testing.hg/file/ac68ad6fe4b7/xen/arch/x86/domain.c#l716

Shouldn't this be fixed?

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:45:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2R6k-0005s9-5K; Tue, 28 Feb 2012 17:45:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S2R6i-0005rt-GD
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 17:45:00 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330451092!16550707!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11622 invoked from network); 28 Feb 2012 17:44:53 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-5.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 17:44:53 -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 6180016296
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 17:44:51 +0000 (GMT)
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 7O-WnLMzAJRm for <xen-devel@lists.xen.org>;
	Tue, 28 Feb 2012 17:44:49 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id 1226616295
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 17:44:48 +0000 (GMT)
Message-ID: <4F4D1291.6010705@abpni.co.uk>
Date: Tue, 28 Feb 2012 17:44:49 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] CVE-2011-1166
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Everyone,

I'm currently looking at CVE-2011-1166:

http://securitytracker.com/id/1025226

Am I correct in saying that this issue is fixed in the latest stable 4.x 
branch, but not in the 3.4.4 release? I see the fix here:

http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8

however I do not see the same fix applied in 3.4.4:

http://xenbits.xen.org/hg/xen-3.4-testing.hg/file/ac68ad6fe4b7/xen/arch/x86/domain.c#l716

Shouldn't this be fixed?

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:52:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RDP-0006Ak-AJ; Tue, 28 Feb 2012 17:51:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2RDN-0006Af-8X
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:51:53 +0000
Received: from [85.158.139.83:48512] by server-7.bemta-5.messagelabs.com id
	BC/69-16195-7341D4F4; Tue, 28 Feb 2012 17:51:51 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330451510!17097241!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13132 invoked from network); 28 Feb 2012 17:51:51 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:51:51 -0000
Received: by bkwq16 with SMTP id q16so5784652bkw.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 09:51:50 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.112.28.74 as permitted sender) client-ip=10.112.28.74; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.112.28.74 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.112.28.74])
	by 10.112.28.74 with SMTP id z10mr2990006lbg.14.1330451510558 (num_hops
	= 1); Tue, 28 Feb 2012 09:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=huEkjVdQEMXpDCA2GjIJt92FfQZjbH9x7CR0+LLpE5k=;
	b=Smum1UkkH0KIJuATdF9wAoJtoKFwdpv+G10p7YHa+FkxeundabGBWllaFhab9ZzEG3
	RIwXlOIO5VEuBQJVdEzXq4YRsIVsSgZDFdrxRrRylODqJp8IMU16QGH29nW6NXmPAWK+
	QB7s5pL6N/FRWqvYRXKCpp8lDtCrXDfKAg6zc=
Received: by 10.112.28.74 with SMTP id z10mr2428221lbg.14.1330451510465; Tue,
	28 Feb 2012 09:51:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Tue, 28 Feb 2012 09:51:30 -0800 (PST)
In-Reply-To: <1330423226.31269.35.camel@zakaz.uk.xensource.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 09:51:30 -0800
Message-ID: <CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Please do not top post, it destroys the flow of the conversation.

ok, sorry.

> /usr/lib vs /usr/lib64 is a distro decision which Xen has to fit in
> with, not a decision which we get to make.


I understand that, but from this thread I was not sure what the
intentions were for the xen architecture on supporting multiple
distrbutions. i.e. I was going to put a patch in place, but was not
sure if I was stepping on peoples feet.

> Have you changed anything here or are you saying that a pristine Xen
> tree when built on CentOS installs 64 bit libraries to /usr/lib instead
> of /usr/lib64? If so please can you be precise about what tree you are
> running (e.g. the exact URL you cloned and which changeset you got) and
> steps you took to install (e.g. what patches did you apply, what
> commands did you type) and what exactly you saw (e.g. what was
> in /usr/lib and what was in /usr/lib64)

#uname -a
Linux xenbuild2.cyberlab 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24
02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux

#hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
#cd xen-unstable
#./configure --enable-xsm --libdir=/usr/lib64
#make dist
#ls dist/install/usr/lib64
python2.6
#ls dist/install/usr/lib
fs                     libvhd.so.1.0.0       libxenstat.so.0
libblktap.a            libxenctrl.a          libxenstat.so.0.0
libblktapctl.a         libxenctrl.so         libxenstore.a
libblktapctl.so        libxenctrl.so.4.2     libxenstore.so
libblktapctl.so.1.0    libxenctrl.so.4.2.0   libxenstore.so.3.0
libblktapctl.so.1.0.0  libxenguest.a         libxenstore.so.3.0.1
libblktap.so           libxenguest.so        libxenvchan.a
libblktap.so.3.0       libxenguest.so.4.2    libxenvchan.so
libblktap.so.3.0.0     libxenguest.so.4.2.0  libxenvchan.so.1.0
libfsimage.so          libxenlight.a         libxenvchan.so.1.0.0
libfsimage.so.1.0      libxenlight.so        libxlutil.a
libfsimage.so.1.0.0    libxenlight.so.2.0    libxlutil.so
libvhd.a               libxenlight.so.2.0.0  libxlutil.so.1.0
libvhd.so              libxenstat.a          libxlutil.so.1.0.0
libvhd.so.1.0          libxenstat.so         xen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 17:52:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 17:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RDP-0006Ak-AJ; Tue, 28 Feb 2012 17:51:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2RDN-0006Af-8X
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 17:51:53 +0000
Received: from [85.158.139.83:48512] by server-7.bemta-5.messagelabs.com id
	BC/69-16195-7341D4F4; Tue, 28 Feb 2012 17:51:51 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330451510!17097241!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13132 invoked from network); 28 Feb 2012 17:51:51 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 17:51:51 -0000
Received: by bkwq16 with SMTP id q16so5784652bkw.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 09:51:50 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.112.28.74 as permitted sender) client-ip=10.112.28.74; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.112.28.74 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.112.28.74])
	by 10.112.28.74 with SMTP id z10mr2990006lbg.14.1330451510558 (num_hops
	= 1); Tue, 28 Feb 2012 09:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=huEkjVdQEMXpDCA2GjIJt92FfQZjbH9x7CR0+LLpE5k=;
	b=Smum1UkkH0KIJuATdF9wAoJtoKFwdpv+G10p7YHa+FkxeundabGBWllaFhab9ZzEG3
	RIwXlOIO5VEuBQJVdEzXq4YRsIVsSgZDFdrxRrRylODqJp8IMU16QGH29nW6NXmPAWK+
	QB7s5pL6N/FRWqvYRXKCpp8lDtCrXDfKAg6zc=
Received: by 10.112.28.74 with SMTP id z10mr2428221lbg.14.1330451510465; Tue,
	28 Feb 2012 09:51:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Tue, 28 Feb 2012 09:51:30 -0800 (PST)
In-Reply-To: <1330423226.31269.35.camel@zakaz.uk.xensource.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 09:51:30 -0800
Message-ID: <CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Please do not top post, it destroys the flow of the conversation.

ok, sorry.

> /usr/lib vs /usr/lib64 is a distro decision which Xen has to fit in
> with, not a decision which we get to make.


I understand that, but from this thread I was not sure what the
intentions were for the xen architecture on supporting multiple
distrbutions. i.e. I was going to put a patch in place, but was not
sure if I was stepping on peoples feet.

> Have you changed anything here or are you saying that a pristine Xen
> tree when built on CentOS installs 64 bit libraries to /usr/lib instead
> of /usr/lib64? If so please can you be precise about what tree you are
> running (e.g. the exact URL you cloned and which changeset you got) and
> steps you took to install (e.g. what patches did you apply, what
> commands did you type) and what exactly you saw (e.g. what was
> in /usr/lib and what was in /usr/lib64)

#uname -a
Linux xenbuild2.cyberlab 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24
02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux

#hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
#cd xen-unstable
#./configure --enable-xsm --libdir=/usr/lib64
#make dist
#ls dist/install/usr/lib64
python2.6
#ls dist/install/usr/lib
fs                     libvhd.so.1.0.0       libxenstat.so.0
libblktap.a            libxenctrl.a          libxenstat.so.0.0
libblktapctl.a         libxenctrl.so         libxenstore.a
libblktapctl.so        libxenctrl.so.4.2     libxenstore.so
libblktapctl.so.1.0    libxenctrl.so.4.2.0   libxenstore.so.3.0
libblktapctl.so.1.0.0  libxenguest.a         libxenstore.so.3.0.1
libblktap.so           libxenguest.so        libxenvchan.a
libblktap.so.3.0       libxenguest.so.4.2    libxenvchan.so
libblktap.so.3.0.0     libxenguest.so.4.2.0  libxenvchan.so.1.0
libfsimage.so          libxenlight.a         libxenvchan.so.1.0.0
libfsimage.so.1.0      libxenlight.so        libxlutil.a
libfsimage.so.1.0.0    libxenlight.so.2.0    libxlutil.so
libvhd.a               libxenlight.so.2.0.0  libxlutil.so.1.0
libvhd.so              libxenstat.a          libxlutil.so.1.0.0
libvhd.so.1.0          libxenstat.so         xen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RQg-0006Ov-Kx; Tue, 28 Feb 2012 18:05:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72) (envelope-from
	<s-voafcsfFTThaOxzqqUZOgsfmfaAArfO4Hw7I03_8NVU3UN8_tltOUL@bounce.linkedin.com>)
	id 1S2RQf-0006Oq-Jj
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:05:37 +0000
X-Env-Sender: s-voafcsfFTThaOxzqqUZOgsfmfaAArfO4Hw7I03_8NVU3UN8_tltOUL@bo
	unce.linkedin.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330452305!54907700!1
X-Originating-IP: [69.28.147.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjkuMjguMTQ3LjE0OSA9PiAxMDAyOTUw\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: ,received_headers: No Received 
	headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2246 invoked from network); 28 Feb 2012 18:05:06 -0000
Received: from mailb-ad.linkedin.com (HELO mailb-ad.linkedin.com)
	(69.28.147.149) by server-11.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 18:05:06 -0000
DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=prod; d=linkedin.com;
	h=DKIM-Signature:Sender:Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:X-LinkedIn-Template:X-LinkedIn-Class:X-LinkedIn-fbl;
	b=EIHTm9YqL5BnLNpz7dRoqgVJQd0Oj9eDMstMAN5yAKjkJZa3OoSXBUyPwarUn8Id
	o2VDeGFbMIMVXTf+yRBqXkE5w7HJkpb5ThhiV7oetsi/nmFPZ0koGEArT4v+xNfo
DKIM-Signature: v=1; a=rsa-sha1; d=linkedin.com; s=proddkim; c=relaxed/relaxed;
	q=dns/txt; i=@linkedin.com; t=1330452330;
	h=From:Subject:Date:To:MIME-Version:Content-Type:X-LinkedIn-Class:X-LinkedIn-fbl:
	X-LinkedIn-Template; bh=zJGkmymgies1m9SkqW/5UbFF7Yc=;
	b=l4vCv6lu1st/zvfpBSIEatbgJ736j327Ym1PB8zHmu+4kph1pdlPxpYCylmPAsGS
	+rAJIs9O2G+6rjJeq4C3FRrfbc+DGDxKzYvr/eplEhoeX7hupQR2nz5ie/ZcaSnU;
Date: Tue, 28 Feb 2012 18:05:30 +0000 (UTC)
From: Carter Cheng via LinkedIn <member@linkedin.com>
To: "Sameer N." <xen-devel@lists.xensource.com>
Message-ID: <1185263773.13652874.1330452330423.JavaMail.app@ela4-app0135.prod>
MIME-Version: 1.0
X-LinkedIn-Template: invite_member_17
X-LinkedIn-Class: INVITE-MBR
X-LinkedIn-fbl: s-voafcsfFTThaOxzqqUZOgsfmfaAArfO4Hw7I03_8NVU3UN8_tltOUL
Subject: [Xen-devel] Invitation to connect on LinkedIn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Carter Cheng <cartercheng@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6896801341682962209=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6896801341682962209==
Content-Type: multipart/alternative; 
	boundary="----=_Part_13652873_1950564958.1330452330421"

------=_Part_13652873_1950564958.1330452330421
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

LinkedIn
------------




    Carter Cheng requested to add you as a connection on LinkedIn:
  

------------------------------------------

Sameer,

I'd like to add you to my professional network on LinkedIn.

- Carter

Accept invitation from Carter Cheng
http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYNclYOe38RdPwRdz99bQxmsApMp4p1bP0RdjoNd38McjoLrCBxbOYWrSlI/EML_comm_afe/?hs=false&tok=3rnulUHHnZml81

View invitation from Carter Cheng
http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/34NnP8UczkTe3kScAALqnpPbOYWrSlI/svi/?hs=false&tok=0jRHSQDmjZml81

------------------------------------------

Why might connecting with Carter Cheng be a good idea?

Carter Cheng's connections could be useful to you:

After accepting Carter Cheng's invitation, check Carter Cheng's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future.
 
-- 
(c) 2012, LinkedIn Corporation
------=_Part_13652873_1950564958.1330452330421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


<html>
  <body>




  
  
  

<table border="0" width="550" cellpadding="0" cellspacing="0" style="max-width:550px; border-top:4px solid #39C; font: 12px arial, sans-serif; margin: 0 auto;"><tr><td>  
  <h1 style="color: #000; font: bold 23px arial; margin:5px 0;" >LinkedIn</h1>
<div style="font:13px arial, sans-serif; width:540px">
  




    Carter Cheng requested to add you as a connection on LinkedIn:
  


  <p>
    Sameer,<br/>
<br/>
I'd like to add you to my professional network on LinkedIn.<br/>
<br/>
- Carter
  </p>
  
  <div style="margin-top: 15px; margin-bottom:10px; border-bottom: 1px solid #ddd; line-height:1px">&nbsp;</div>

  <table cellpadding="0" cellspacing="0">
    <tr>
        <td style="width:15%; padding-right:20px;">
					<table border="0" cellpadding="6" cellspacing="1" align=""><tr><td align="center" valign="middle" bgcolor="#FFE86C" background="http://www.linkedin.com/scds/common/u/img/bg/yellow_button_back.png" style="background:url(http://www.linkedin.com/scds/common/u/img/bg/yellow_button_back.png) repeat-x scroll 100% 0 #FFE86C;background-color:#FFE86C;border:1px solid #E8B463;-moz-border-radius:4px;-webkit-border-radius:4px;border-radius:4px;"><div style="padding-right:10px;padding-left:10px;"><a href="http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYNclYOe38RdPwRdz99bQxmsApMp4p1bP0RdjoNd38McjoLrCBxbOYWrSlI/EML_comm_afe/?hs=false&amp;tok=3rnulUHHnZml81" style="text-decoration:none;"><span style="font-size:12px;font-family:Arial;font-weight:bold;color:#333333;white-space:nowrap;display:block;">Accept</span></a></div></td></tr></table>
        </td>
        <td style="font: 13px arial, sans-serif;"> 
              <a href="http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/34NnP8UczkTe3kScAALqnpPbOYWrSlI/S2_svi/?hs=false&amp;tok=3go38GjYTZml81">View invitation from Carter Cheng</a>
        </td>
    </tr>
  </table>
  
  <br>
  <div style="margin-top: 5px; border-bottom: 2px solid #ddd; line-height:2px">&nbsp;</div>
  <br>
  <p><strong>WHY MIGHT CONNECTING WITH CARTER CHENG BE A GOOD IDEA?</strong></p>
  <p><strong>Carter Cheng's connections could be useful to you</strong></p>
  <p>After accepting Carter Cheng's invitation, check Carter Cheng's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future.</p>
  <div style="margin-top: 6px; border-bottom: 2px solid #ddd; line-height:3px">&nbsp;</div>
</div>





    <p style="width: 550px; margin: 3px auto; font: 10px arial, sans-serif; color: #999;">
&#169; 2012, LinkedIn Corporation    </p>
</body>
</html>
------=_Part_13652873_1950564958.1330452330421--


--===============6896801341682962209==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6896801341682962209==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 18:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RQg-0006Ov-Kx; Tue, 28 Feb 2012 18:05:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72) (envelope-from
	<s-voafcsfFTThaOxzqqUZOgsfmfaAArfO4Hw7I03_8NVU3UN8_tltOUL@bounce.linkedin.com>)
	id 1S2RQf-0006Oq-Jj
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:05:37 +0000
X-Env-Sender: s-voafcsfFTThaOxzqqUZOgsfmfaAArfO4Hw7I03_8NVU3UN8_tltOUL@bo
	unce.linkedin.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330452305!54907700!1
X-Originating-IP: [69.28.147.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjkuMjguMTQ3LjE0OSA9PiAxMDAyOTUw\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: ,received_headers: No Received 
	headers
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2246 invoked from network); 28 Feb 2012 18:05:06 -0000
Received: from mailb-ad.linkedin.com (HELO mailb-ad.linkedin.com)
	(69.28.147.149) by server-11.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 18:05:06 -0000
DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=prod; d=linkedin.com;
	h=DKIM-Signature:Sender:Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:X-LinkedIn-Template:X-LinkedIn-Class:X-LinkedIn-fbl;
	b=EIHTm9YqL5BnLNpz7dRoqgVJQd0Oj9eDMstMAN5yAKjkJZa3OoSXBUyPwarUn8Id
	o2VDeGFbMIMVXTf+yRBqXkE5w7HJkpb5ThhiV7oetsi/nmFPZ0koGEArT4v+xNfo
DKIM-Signature: v=1; a=rsa-sha1; d=linkedin.com; s=proddkim; c=relaxed/relaxed;
	q=dns/txt; i=@linkedin.com; t=1330452330;
	h=From:Subject:Date:To:MIME-Version:Content-Type:X-LinkedIn-Class:X-LinkedIn-fbl:
	X-LinkedIn-Template; bh=zJGkmymgies1m9SkqW/5UbFF7Yc=;
	b=l4vCv6lu1st/zvfpBSIEatbgJ736j327Ym1PB8zHmu+4kph1pdlPxpYCylmPAsGS
	+rAJIs9O2G+6rjJeq4C3FRrfbc+DGDxKzYvr/eplEhoeX7hupQR2nz5ie/ZcaSnU;
Date: Tue, 28 Feb 2012 18:05:30 +0000 (UTC)
From: Carter Cheng via LinkedIn <member@linkedin.com>
To: "Sameer N." <xen-devel@lists.xensource.com>
Message-ID: <1185263773.13652874.1330452330423.JavaMail.app@ela4-app0135.prod>
MIME-Version: 1.0
X-LinkedIn-Template: invite_member_17
X-LinkedIn-Class: INVITE-MBR
X-LinkedIn-fbl: s-voafcsfFTThaOxzqqUZOgsfmfaAArfO4Hw7I03_8NVU3UN8_tltOUL
Subject: [Xen-devel] Invitation to connect on LinkedIn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Carter Cheng <cartercheng@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6896801341682962209=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6896801341682962209==
Content-Type: multipart/alternative; 
	boundary="----=_Part_13652873_1950564958.1330452330421"

------=_Part_13652873_1950564958.1330452330421
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

LinkedIn
------------




    Carter Cheng requested to add you as a connection on LinkedIn:
  

------------------------------------------

Sameer,

I'd like to add you to my professional network on LinkedIn.

- Carter

Accept invitation from Carter Cheng
http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYNclYOe38RdPwRdz99bQxmsApMp4p1bP0RdjoNd38McjoLrCBxbOYWrSlI/EML_comm_afe/?hs=false&tok=3rnulUHHnZml81

View invitation from Carter Cheng
http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/34NnP8UczkTe3kScAALqnpPbOYWrSlI/svi/?hs=false&tok=0jRHSQDmjZml81

------------------------------------------

Why might connecting with Carter Cheng be a good idea?

Carter Cheng's connections could be useful to you:

After accepting Carter Cheng's invitation, check Carter Cheng's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future.
 
-- 
(c) 2012, LinkedIn Corporation
------=_Part_13652873_1950564958.1330452330421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


<html>
  <body>




  
  
  

<table border="0" width="550" cellpadding="0" cellspacing="0" style="max-width:550px; border-top:4px solid #39C; font: 12px arial, sans-serif; margin: 0 auto;"><tr><td>  
  <h1 style="color: #000; font: bold 23px arial; margin:5px 0;" >LinkedIn</h1>
<div style="font:13px arial, sans-serif; width:540px">
  




    Carter Cheng requested to add you as a connection on LinkedIn:
  


  <p>
    Sameer,<br/>
<br/>
I'd like to add you to my professional network on LinkedIn.<br/>
<br/>
- Carter
  </p>
  
  <div style="margin-top: 15px; margin-bottom:10px; border-bottom: 1px solid #ddd; line-height:1px">&nbsp;</div>

  <table cellpadding="0" cellspacing="0">
    <tr>
        <td style="width:15%; padding-right:20px;">
					<table border="0" cellpadding="6" cellspacing="1" align=""><tr><td align="center" valign="middle" bgcolor="#FFE86C" background="http://www.linkedin.com/scds/common/u/img/bg/yellow_button_back.png" style="background:url(http://www.linkedin.com/scds/common/u/img/bg/yellow_button_back.png) repeat-x scroll 100% 0 #FFE86C;background-color:#FFE86C;border:1px solid #E8B463;-moz-border-radius:4px;-webkit-border-radius:4px;border-radius:4px;"><div style="padding-right:10px;padding-left:10px;"><a href="http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYNclYOe38RdPwRdz99bQxmsApMp4p1bP0RdjoNd38McjoLrCBxbOYWrSlI/EML_comm_afe/?hs=false&amp;tok=3rnulUHHnZml81" style="text-decoration:none;"><span style="font-size:12px;font-family:Arial;font-weight:bold;color:#333333;white-space:nowrap;display:block;">Accept</span></a></div></td></tr></table>
        </td>
        <td style="font: 13px arial, sans-serif;"> 
              <a href="http://www.linkedin.com/e/g3qy2u-gz78ysa7-4w/93IoRa1TuGiXQo4VcYuX-eBzziJq_RmV_Y76_WtjajRk/blk/I265875282_11/34NnP8UczkTe3kScAALqnpPbOYWrSlI/S2_svi/?hs=false&amp;tok=3go38GjYTZml81">View invitation from Carter Cheng</a>
        </td>
    </tr>
  </table>
  
  <br>
  <div style="margin-top: 5px; border-bottom: 2px solid #ddd; line-height:2px">&nbsp;</div>
  <br>
  <p><strong>WHY MIGHT CONNECTING WITH CARTER CHENG BE A GOOD IDEA?</strong></p>
  <p><strong>Carter Cheng's connections could be useful to you</strong></p>
  <p>After accepting Carter Cheng's invitation, check Carter Cheng's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future.</p>
  <div style="margin-top: 6px; border-bottom: 2px solid #ddd; line-height:3px">&nbsp;</div>
</div>





    <p style="width: 550px; margin: 3px auto; font: 10px arial, sans-serif; color: #999;">
&#169; 2012, LinkedIn Corporation    </p>
</body>
</html>
------=_Part_13652873_1950564958.1330452330421--


--===============6896801341682962209==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6896801341682962209==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 18:10:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RUy-0006Wh-DN; Tue, 28 Feb 2012 18:10:04 +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 1S2RUx-0006Wa-7x
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 18:10:03 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330452548!51795810!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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19192 invoked from network); 28 Feb 2012 18:09:09 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:09:09 -0000
Received: by lahe6 with SMTP id e6so2485169lah.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 10:10:01 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.152.147.202 as permitted sender) client-ip=10.152.147.202; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.152.147.202 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.152.147.202])
	by 10.152.147.202 with SMTP id tm10mr18321777lab.49.1330452601393
	(num_hops = 1); Tue, 28 Feb 2012 10:10:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=0rf97zojv3+JaBX8SmH8+0L1LlsboPRvBMnAEOFGavE=;
	b=B2uMZitust0kz9Jo2Ned2aiVbR4zj1F4MYFwYw+VHgpnSGRRBAVY0QCqJ/e/v46Tc2
	eNjEN/36qcIg0AGKy6MVTFhKO0aXqhOsnl3Mf9kiU1qUyMkOoSTPL9B0QAA56wp/DJpv
	ENIcVA5iJza5udP51Xz+U55AMrfrArAcH9fK8=
Received: by 10.152.147.202 with SMTP id tm10mr15180358lab.49.1330452601248;
	Tue, 28 Feb 2012 10:10:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Tue, 28 Feb 2012 10:09:40 -0800 (PST)
In-Reply-To: <20120223173617.GA19213@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 10:09:40 -0800
Message-ID: <CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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

>Added autotools magic to replace custom check scripts

Let me start over on this one...  What is the install methodology with
the replacement of the custom checks with "autotools magic?" I am
working on a dist build and realized that the dist build goes over and
grabs the checks out of the tools directory to check the installation.
 So if I were to:

#hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
#cd xen-unstable
#./configure
#make dist
#tar cvfz something.tar.gz dist
#scp something.tar.gz xen@newhost:/temp
#ssh xen@newhost
#....
#./install.sh
...
Checking to see whether prerequisite tools are installed...
./install.sh: line 53: cd: ./install/../check: No such file or directory
./install.sh: line 54: ./chk: No such file or directory
All done.

#ls dist
COPYING  install  install.sh  README

#tail -n 6 dist/install.sh
echo "Checking to see whether prerequisite tools are installed..."
cd $src/../check
./chk install
echo "All done."

exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:10:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RUy-0006Wh-DN; Tue, 28 Feb 2012 18:10:04 +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 1S2RUx-0006Wa-7x
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 18:10:03 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330452548!51795810!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-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19192 invoked from network); 28 Feb 2012 18:09:09 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:09:09 -0000
Received: by lahe6 with SMTP id e6so2485169lah.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 10:10:01 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.152.147.202 as permitted sender) client-ip=10.152.147.202; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.152.147.202 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.152.147.202])
	by 10.152.147.202 with SMTP id tm10mr18321777lab.49.1330452601393
	(num_hops = 1); Tue, 28 Feb 2012 10:10:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=0rf97zojv3+JaBX8SmH8+0L1LlsboPRvBMnAEOFGavE=;
	b=B2uMZitust0kz9Jo2Ned2aiVbR4zj1F4MYFwYw+VHgpnSGRRBAVY0QCqJ/e/v46Tc2
	eNjEN/36qcIg0AGKy6MVTFhKO0aXqhOsnl3Mf9kiU1qUyMkOoSTPL9B0QAA56wp/DJpv
	ENIcVA5iJza5udP51Xz+U55AMrfrArAcH9fK8=
Received: by 10.152.147.202 with SMTP id tm10mr15180358lab.49.1330452601248;
	Tue, 28 Feb 2012 10:10:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Tue, 28 Feb 2012 10:09:40 -0800 (PST)
In-Reply-To: <20120223173617.GA19213@aepfle.de>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 10:09:40 -0800
Message-ID: <CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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

>Added autotools magic to replace custom check scripts

Let me start over on this one...  What is the install methodology with
the replacement of the custom checks with "autotools magic?" I am
working on a dist build and realized that the dist build goes over and
grabs the checks out of the tools directory to check the installation.
 So if I were to:

#hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
#cd xen-unstable
#./configure
#make dist
#tar cvfz something.tar.gz dist
#scp something.tar.gz xen@newhost:/temp
#ssh xen@newhost
#....
#./install.sh
...
Checking to see whether prerequisite tools are installed...
./install.sh: line 53: cd: ./install/../check: No such file or directory
./install.sh: line 54: ./chk: No such file or directory
All done.

#ls dist
COPYING  install  install.sh  README

#tail -n 6 dist/install.sh
echo "Checking to see whether prerequisite tools are installed..."
cd $src/../check
./chk install
echo "All done."

exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:12:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RWd-0006cU-Sj; Tue, 28 Feb 2012 18:11:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1S2RWc-0006bv-QV
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:11:47 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330452698!15349746!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16079 invoked from network); 28 Feb 2012 18:11:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:11:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183749856"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:11:16 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 28 Feb 2012
	13:11:16 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 13:11:17 -0500
Thread-Topic: [RFC] HVM BIOS pass-through
Thread-Index: Acz2N8/+kaKiGbcQS9yYcMWuEWo1tw==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724F631110@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] [RFC] HVM BIOS pass-through
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 what I am now posting as an RFC started life as a patch series to introduce SMBIOS table pass-through for HVMs ([PATCH 0/3] SMBIOS table passthrough support). After getting feedback from the community (thank you) and giving it some thought I decided to try this approach and in the process expand the scope of the functionality that I am attempting to introduce.


Overview:

Pass-through of portions of a host's firmware (specifically SMBIOS and ACPI) is useful in supporting vendor/OEM specific functionality in HVM guests. This includes OEM platform specific software and drivers, support for custom value add hardware like laptop buttons, device pass-through firmware requirements, etc. The proposal is to build a somewhat generic interface to pass in certain pieces of the platform BIOS for inclusion in the virtual firmware as built by HVMLOADER.

The first section will cover the primary functionality of the proposal; this being the creation of a generic framework to pass platform firmware data to HVMLOADER during HVM guest creation. The second section will cover the possible inclusion of an HVM helper library to generate the firmware data format for HVMLOADER and tool-stack considerations.


BIOS Pass-through Framework:

The first part is to build a framework to load firmware "modules" with the HVMLOADER when creating a guest. The earlier idea was to use the shared HVM info page but this is being phased out. The current consensus seems to be that the modules can be loaded into the guest while it is built. Specifically they can be loaded in much the same way as HVMLOADER is by libxc and note these modules are only for use by the HVMLOADER. HVMLOADER is copied into what will become the RAM area in the E820 and the HVMLOADER modules could be stacked up behind it in that same area:

0000000000100000 - HVMLOADER
0000000000200000 - 1-N HVMLOADER MODULES

These modules will effectively "disappear" with the HVMLOADER once control is given to the guest BIOS and E820 identifies that area as usable RAM. 

The HVMLOADER modules would have a standard layout defined in a public header. All modules would all have a standard header with the basics: signature, type, length, checksum, with this followed by a type specific header. At the moment there would be support for ACPI and SMBIOS table pass-through. The HVMLOADER will have to be modified to process the specific module types and load them in the appropriate manner. It is conceivable that this same mechanism could be used to load other types of firmware information e.g. for adding or overriding OROMs.

The exact nature of how this functionality would be used is not really built into this proposal. This merely provides a mechanism to customize an HVM's virtual firmware is a variety of ways. By default, the addition of this functionality will not change the current behavior in any way. How modules are generated and managed would vary by use case. For example, the question of guest launch measurement came up. This model would allow the HVMLOADER and associated modules to be measured by a domain builder but that would mean tight control over the creation and maintenance of the modules.

Here are a few details that need to be thought out (and there are probably more than are listed):
 - The minimum HVM size is currently 2Mb - this would have to increase, perhaps derived off the total module(s) size.
 - ACPI builder uses some scratch space behind HVMLOADER to build the tables the first time - have to make sure this doesn't crash into the modules.
 - Need suggestions on how to best modify libxc to do this work; it is fairly clear where it would happen but it probably needs a new API.
 - How to tell HVMLOADER where the module(s) base GPA is: register, xenstore, ?
 - Other firmware information like simple string/numeric values and meta information like control flags can be passed in xenstore.


Library and Tool-stack Support:

In addition to the HVMLOADER support, it would be helpful to have a library that would read the relevant platform information and write the HVMLOADER modules in the proper format. This library could be extended to help manage the various xenstore keys that are used in HVMLOADER but not really defined a particular location. And yet one step further, this library could be used to setup the current values that passed via the HVM info table allowing us to deprecate the latter's use.

For the moment changes to the open source tool-stacks is not being considered beyond changes to libxc to support the loading of modules. This is obviously up for discussion too.

Thanks and sorry for the lengthiness...


Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
781-301-7949
ross.philipson@citrix.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:12:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RWd-0006cU-Sj; Tue, 28 Feb 2012 18:11:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1S2RWc-0006bv-QV
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:11:47 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330452698!15349746!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg5ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16079 invoked from network); 28 Feb 2012 18:11:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:11:40 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="183749856"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:11:16 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 28 Feb 2012
	13:11:16 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 13:11:17 -0500
Thread-Topic: [RFC] HVM BIOS pass-through
Thread-Index: Acz2N8/+kaKiGbcQS9yYcMWuEWo1tw==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724F631110@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] [RFC] HVM BIOS pass-through
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 what I am now posting as an RFC started life as a patch series to introduce SMBIOS table pass-through for HVMs ([PATCH 0/3] SMBIOS table passthrough support). After getting feedback from the community (thank you) and giving it some thought I decided to try this approach and in the process expand the scope of the functionality that I am attempting to introduce.


Overview:

Pass-through of portions of a host's firmware (specifically SMBIOS and ACPI) is useful in supporting vendor/OEM specific functionality in HVM guests. This includes OEM platform specific software and drivers, support for custom value add hardware like laptop buttons, device pass-through firmware requirements, etc. The proposal is to build a somewhat generic interface to pass in certain pieces of the platform BIOS for inclusion in the virtual firmware as built by HVMLOADER.

The first section will cover the primary functionality of the proposal; this being the creation of a generic framework to pass platform firmware data to HVMLOADER during HVM guest creation. The second section will cover the possible inclusion of an HVM helper library to generate the firmware data format for HVMLOADER and tool-stack considerations.


BIOS Pass-through Framework:

The first part is to build a framework to load firmware "modules" with the HVMLOADER when creating a guest. The earlier idea was to use the shared HVM info page but this is being phased out. The current consensus seems to be that the modules can be loaded into the guest while it is built. Specifically they can be loaded in much the same way as HVMLOADER is by libxc and note these modules are only for use by the HVMLOADER. HVMLOADER is copied into what will become the RAM area in the E820 and the HVMLOADER modules could be stacked up behind it in that same area:

0000000000100000 - HVMLOADER
0000000000200000 - 1-N HVMLOADER MODULES

These modules will effectively "disappear" with the HVMLOADER once control is given to the guest BIOS and E820 identifies that area as usable RAM. 

The HVMLOADER modules would have a standard layout defined in a public header. All modules would all have a standard header with the basics: signature, type, length, checksum, with this followed by a type specific header. At the moment there would be support for ACPI and SMBIOS table pass-through. The HVMLOADER will have to be modified to process the specific module types and load them in the appropriate manner. It is conceivable that this same mechanism could be used to load other types of firmware information e.g. for adding or overriding OROMs.

The exact nature of how this functionality would be used is not really built into this proposal. This merely provides a mechanism to customize an HVM's virtual firmware is a variety of ways. By default, the addition of this functionality will not change the current behavior in any way. How modules are generated and managed would vary by use case. For example, the question of guest launch measurement came up. This model would allow the HVMLOADER and associated modules to be measured by a domain builder but that would mean tight control over the creation and maintenance of the modules.

Here are a few details that need to be thought out (and there are probably more than are listed):
 - The minimum HVM size is currently 2Mb - this would have to increase, perhaps derived off the total module(s) size.
 - ACPI builder uses some scratch space behind HVMLOADER to build the tables the first time - have to make sure this doesn't crash into the modules.
 - Need suggestions on how to best modify libxc to do this work; it is fairly clear where it would happen but it probably needs a new API.
 - How to tell HVMLOADER where the module(s) base GPA is: register, xenstore, ?
 - Other firmware information like simple string/numeric values and meta information like control flags can be passed in xenstore.


Library and Tool-stack Support:

In addition to the HVMLOADER support, it would be helpful to have a library that would read the relevant platform information and write the HVMLOADER modules in the proper format. This library could be extended to help manage the various xenstore keys that are used in HVMLOADER but not really defined a particular location. And yet one step further, this library could be used to setup the current values that passed via the HVM info table allowing us to deprecate the latter's use.

For the moment changes to the open source tool-stacks is not being considered beyond changes to libxc to support the loading of modules. This is obviously up for discussion too.

Thanks and sorry for the lengthiness...


Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
781-301-7949
ross.philipson@citrix.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:13:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RYN-0006oQ-Ae; Tue, 28 Feb 2012 18:13:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S2RYL-0006nW-N5
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:13:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330452807!15965747!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1427 invoked from network); 28 Feb 2012 18:13:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 18:13:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S2RYE-00054Q-QG; Tue, 28 Feb 2012 18:13:26 +0000
Date: Tue, 28 Feb 2012 18:13:26 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120228181326.GA18897@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
	<1330425518.31269.61.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330425518.31269.61.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] arm: SMP CPU 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

At 10:38 +0000 on 28 Feb (1330425518), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1330018799 0
> > # Node ID a78bc9b8421492e0545c6d52c7a32b9de9737d61
> > # Parent  d35b52e5fde829dfbaf3da73e0716d004faded2f
> > arm: SMP CPU shutdown
> > 
> > For completeness, also implelent the CPU shutdown path.
> 
> Does something free the init_stack for a CPU as it goes down?

Er, no. :)  

> Alternatively the bring up path could reuse it if the CPU came back but
> we don't seem to do that either.

I'll make it so. 

> > Signed-off-by: TIm Deegan <tim@xen.org>
> 
> Typo here.

WHat TYpo? I ALways SIgn MY NAme THat WAy.

> [...]
> > +    /* It's now safe to remove this processor from the online map */
> > +    cpumask_clear_cpu(cpu, &cpu_online_map);
> > +
> > +    if ( cpu_disable_scheduler(cpu) )
> > +        BUG();
> > +    mb();
> > +
> > +    /* Return to caller; eventually the IPI mecahnism will unwind and the 
> 
>                                                mechanism

ta.

> > +     * scheduler will drop to the idle loop, which will call stop_cpu(). */
> > +}
> > +
> > +void stop_cpu(void)
> > +{
> > +    local_irq_disable();
> > +    cpu_is_dead = 1;
> 
> Do we lock this variable? What stops multiple CPUs coming down at once?

IIRC that's serialized at a higher level, and the x86 equivalent
similarly uses static variables for signalling.  Will double-check
before I re-send this series (probably next week).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:13:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RYN-0006oQ-Ae; Tue, 28 Feb 2012 18:13:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S2RYL-0006nW-N5
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:13:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330452807!15965747!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1427 invoked from network); 28 Feb 2012 18:13:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2012 18:13:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S2RYE-00054Q-QG; Tue, 28 Feb 2012 18:13:26 +0000
Date: Tue, 28 Feb 2012 18:13:26 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120228181326.GA18897@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<a78bc9b8421492e0545c.1330018856@whitby.uk.xensource.com>
	<1330425518.31269.61.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330425518.31269.61.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09 of 10] arm: SMP CPU 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

At 10:38 +0000 on 28 Feb (1330425518), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1330018799 0
> > # Node ID a78bc9b8421492e0545c6d52c7a32b9de9737d61
> > # Parent  d35b52e5fde829dfbaf3da73e0716d004faded2f
> > arm: SMP CPU shutdown
> > 
> > For completeness, also implelent the CPU shutdown path.
> 
> Does something free the init_stack for a CPU as it goes down?

Er, no. :)  

> Alternatively the bring up path could reuse it if the CPU came back but
> we don't seem to do that either.

I'll make it so. 

> > Signed-off-by: TIm Deegan <tim@xen.org>
> 
> Typo here.

WHat TYpo? I ALways SIgn MY NAme THat WAy.

> [...]
> > +    /* It's now safe to remove this processor from the online map */
> > +    cpumask_clear_cpu(cpu, &cpu_online_map);
> > +
> > +    if ( cpu_disable_scheduler(cpu) )
> > +        BUG();
> > +    mb();
> > +
> > +    /* Return to caller; eventually the IPI mecahnism will unwind and the 
> 
>                                                mechanism

ta.

> > +     * scheduler will drop to the idle loop, which will call stop_cpu(). */
> > +}
> > +
> > +void stop_cpu(void)
> > +{
> > +    local_irq_disable();
> > +    cpu_is_dead = 1;
> 
> Do we lock this variable? What stops multiple CPUs coming down at once?

IIRC that's serialized at a higher level, and the x86 equivalent
similarly uses static variables for signalling.  Will double-check
before I re-send this series (probably next week).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RmO-0007dJ-Uk; Tue, 28 Feb 2012 18:28:04 +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 1S2RmN-0007cT-Gc
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:28:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330453618!53746108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26903 invoked from network); 28 Feb 2012 18:26:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10992257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 18:27:57 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 18:27:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 18:27:51 +0000
Message-ID: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] libxc: allow size of MMIO hole for HVM
	guests to be 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

This series allows a user of libxc to set the size of the MMIO hole of
HVM guests.  The rationale for this is included in the patch 2.

As part of this, the API calls were tidied up to allow new parameters
to be added more easily (by using a transparent structure).  Note that
this breaks backwards compatibility and that adding more parameters
will also break backwards compatibility.

I took a stab at fixing the ia64 version of xc_hvm_domain_build() but
I haven't even tried a ia64 build...

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:28:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2RmO-0007dJ-Uk; Tue, 28 Feb 2012 18:28:04 +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 1S2RmN-0007cT-Gc
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:28:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330453618!53746108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26903 invoked from network); 28 Feb 2012 18:26:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10992257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 18:27:57 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 18:27:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 18:27:51 +0000
Message-ID: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] libxc: allow size of MMIO hole for HVM
	guests to be 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

This series allows a user of libxc to set the size of the MMIO hole of
HVM guests.  The rationale for this is included in the patch 2.

As part of this, the API calls were tidied up to allow new parameters
to be added more easily (by using a transparent structure).  Note that
this breaks backwards compatibility and that adding more parameters
will also break backwards compatibility.

I took a stab at fixing the ia64 version of xc_hvm_domain_build() but
I haven't even tried a ia64 build...

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:28:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RmK-0007cc-Du; Tue, 28 Feb 2012 18:28:00 +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 1S2RmI-0007cV-U2
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:27:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330453618!53746108!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26920 invoked from network); 28 Feb 2012 18:26:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10992259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 18:27:57 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 18:27:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 18:27:53 +0000
Message-ID: <1330453673-8606-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxc: add MMIO hole size parameter to
	xc_hvm_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

From: David Vrabel <david.vrabel@citrix.com>

Add a parameter for the MMIO hole size when building a HVM domain.

This is useful for specifying a larger than normal MMIO hole to ensure
that no PCI device's MMIO region overlaps with the guest physical
addresses of RAM.  This is needed on certain systems with PCI bridges
with ACS versions that are broken.  On these systems, if a device
behind the bridge attempts a DMA to a guest physical address that
overlaps with the MMIO region of another device behind the bridge,
then the bridge intercepts the access and forwards it directly to the
device and the read or write never hits RAM.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/xc_hvm_build.c |   29 ++++++++++++++++++-----------
 tools/libxc/xenguest.h     |    1 +
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 31d4734..fbeddac 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -46,7 +46,8 @@
 #define NR_SPECIAL_PAGES     5
 #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
 
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
     struct hvm_info_table *hvm_info = (struct hvm_info_table *)
         (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -54,10 +55,10 @@ static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
     uint8_t sum;
     int i;
 
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    if ( lowmem_end > mmio_start )
     {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
+        highmem_end = (1ull<<32) + (lowmem_end - mmio_start);
+        lowmem_end = mmio_start;
     }
 
     memset(hvm_info_page, 0, PAGE_SIZE);
@@ -126,10 +127,10 @@ static int loadelfimage(
  * Check whether there exists mmio hole in the specified memory range.
  * Returns 1 if exists, else returns 0.
  */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
+static int check_mmio_hole(uint64_t start, uint64_t memsize,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
         return 0;
     else
         return 1;
@@ -142,6 +143,8 @@ static int setup_guest(xc_interface *xch,
     xen_pfn_t *page_array = NULL;
     unsigned long i, nr_pages = params->mem_size >> PAGE_SHIFT;
     unsigned long target_pages = params->mem_target >> PAGE_SHIFT;
+    uint64_t mmio_start = (1ull << 32) - params->mmio_size;
+    uint64_t mmio_size = params->mmio_size;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -188,8 +191,8 @@ static int setup_guest(xc_interface *xch,
 
     for ( i = 0; i < nr_pages; i++ )
         page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+    for ( i = mmio_start >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += mmio_size >> PAGE_SHIFT;
 
     /*
      * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
@@ -230,7 +233,8 @@ static int setup_guest(xc_interface *xch,
         if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
              /* Check if there exists MMIO hole in the 1GB memory range */
              !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT,
+                              mmio_start, mmio_size) )
         {
             long done;
             unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
@@ -327,7 +331,7 @@ static int setup_guest(xc_interface *xch,
               xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
               HVM_INFO_PFN)) == NULL )
         goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
+    build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
     munmap(hvm_info_page, PAGE_SIZE);
 
     /* Allocate and clear special pages. */
@@ -408,6 +412,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
     if ( params.mem_target == 0 )
         params.mem_target = params.mem_size;
 
+    if ( params.mmio_size == 0 )
+        params.mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
+
     /* An HVM guest must be initialised with at least 2MB memory. */
     if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull << 20) )
         return -1;
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 19b0382..b06788c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -174,6 +174,7 @@ int xc_linux_build_mem(xc_interface *xch,
 struct xc_hvm_params {
     uint64_t mem_size;           /**< Memory size in bytes. */
     uint64_t mem_target;         /**< Memory target in bytes. */
+    uint64_t mmio_size;          /**< Size of the MMIO hole in bytes. */
     const char *image_file_name; /**< File name of the image to load. */
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:28:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RmK-0007cc-Du; Tue, 28 Feb 2012 18:28:00 +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 1S2RmI-0007cV-U2
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:27:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330453618!53746108!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26920 invoked from network); 28 Feb 2012 18:26:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10992259"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 18:27:57 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 18:27:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 18:27:53 +0000
Message-ID: <1330453673-8606-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxc: add MMIO hole size parameter to
	xc_hvm_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

From: David Vrabel <david.vrabel@citrix.com>

Add a parameter for the MMIO hole size when building a HVM domain.

This is useful for specifying a larger than normal MMIO hole to ensure
that no PCI device's MMIO region overlaps with the guest physical
addresses of RAM.  This is needed on certain systems with PCI bridges
with ACS versions that are broken.  On these systems, if a device
behind the bridge attempts a DMA to a guest physical address that
overlaps with the MMIO region of another device behind the bridge,
then the bridge intercepts the access and forwards it directly to the
device and the read or write never hits RAM.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/xc_hvm_build.c |   29 ++++++++++++++++++-----------
 tools/libxc/xenguest.h     |    1 +
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 31d4734..fbeddac 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -46,7 +46,8 @@
 #define NR_SPECIAL_PAGES     5
 #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
 
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
     struct hvm_info_table *hvm_info = (struct hvm_info_table *)
         (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -54,10 +55,10 @@ static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
     uint8_t sum;
     int i;
 
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    if ( lowmem_end > mmio_start )
     {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
+        highmem_end = (1ull<<32) + (lowmem_end - mmio_start);
+        lowmem_end = mmio_start;
     }
 
     memset(hvm_info_page, 0, PAGE_SIZE);
@@ -126,10 +127,10 @@ static int loadelfimage(
  * Check whether there exists mmio hole in the specified memory range.
  * Returns 1 if exists, else returns 0.
  */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
+static int check_mmio_hole(uint64_t start, uint64_t memsize,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
         return 0;
     else
         return 1;
@@ -142,6 +143,8 @@ static int setup_guest(xc_interface *xch,
     xen_pfn_t *page_array = NULL;
     unsigned long i, nr_pages = params->mem_size >> PAGE_SHIFT;
     unsigned long target_pages = params->mem_target >> PAGE_SHIFT;
+    uint64_t mmio_start = (1ull << 32) - params->mmio_size;
+    uint64_t mmio_size = params->mmio_size;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -188,8 +191,8 @@ static int setup_guest(xc_interface *xch,
 
     for ( i = 0; i < nr_pages; i++ )
         page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+    for ( i = mmio_start >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += mmio_size >> PAGE_SHIFT;
 
     /*
      * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
@@ -230,7 +233,8 @@ static int setup_guest(xc_interface *xch,
         if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
              /* Check if there exists MMIO hole in the 1GB memory range */
              !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT,
+                              mmio_start, mmio_size) )
         {
             long done;
             unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
@@ -327,7 +331,7 @@ static int setup_guest(xc_interface *xch,
               xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
               HVM_INFO_PFN)) == NULL )
         goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
+    build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
     munmap(hvm_info_page, PAGE_SIZE);
 
     /* Allocate and clear special pages. */
@@ -408,6 +412,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
     if ( params.mem_target == 0 )
         params.mem_target = params.mem_size;
 
+    if ( params.mmio_size == 0 )
+        params.mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
+
     /* An HVM guest must be initialised with at least 2MB memory. */
     if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull << 20) )
         return -1;
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 19b0382..b06788c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -174,6 +174,7 @@ int xc_linux_build_mem(xc_interface *xch,
 struct xc_hvm_params {
     uint64_t mem_size;           /**< Memory size in bytes. */
     uint64_t mem_target;         /**< Memory target in bytes. */
+    uint64_t mmio_size;          /**< Size of the MMIO hole in bytes. */
     const char *image_file_name; /**< File name of the image to load. */
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:28:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RmP-0007dS-AQ; Tue, 28 Feb 2012 18:28: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 1S2RmN-0007cU-Os
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:28:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330453618!53746108!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26912 invoked from network); 28 Feb 2012 18:26:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10992258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 18:27:57 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 18:27:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 18:27:52 +0000
Message-ID: <1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxc: pass parameters to xc_hvm_build() in
	a 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

From: David Vrabel <david.vrabel@citrix.com>

To allow new parameters to be added to the xc_hvm_build*() family of
functions, pass them in a structure.  Make the other variants fill in
the structure and call xc_hvm_build() (except for xc_hvm_build_mem()
which had no users and is removed).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/ia64/xc_ia64_hvm_build.c |   21 ++++--
 tools/libxc/xc_hvm_build.c           |  115 +++++++++-------------------------
 tools/libxc/xenguest.h               |   27 +++++---
 tools/libxc/xg_private.c             |    3 +-
 4 files changed, 62 insertions(+), 104 deletions(-)

diff --git a/tools/libxc/ia64/xc_ia64_hvm_build.c b/tools/libxc/ia64/xc_ia64_hvm_build.c
index 18be616..16dace0 100644
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c
@@ -912,8 +912,8 @@ setup_guest(xc_interface *xch, uint32_t dom, unsigned long memsize,
             char *image, unsigned long image_size)
 {
     xen_pfn_t *pfn_list;
-    unsigned long dom_memsize = memsize << 20;
-    unsigned long nr_pages = memsize << (20 - PAGE_SHIFT);
+    unsigned long dom_memsize = memsize;
+    unsigned long nr_pages = memsize >> PAGE_SHIFT;
     unsigned long vcpus;
     unsigned long nr_special_pages;
     unsigned long memmap_info_pfn;
@@ -1072,14 +1072,14 @@ error_out:
 }
 
 int
-xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_name)
+xc_hvm_build(xc_interface *xch, uint32_t domid, const struct xc_hvm_params *params)
 {
     vcpu_guest_context_any_t st_ctxt_any;
     vcpu_guest_context_t *ctxt = &st_ctxt_any.c;
     char *image = NULL;
     unsigned long image_size;
 
-    image = xc_read_image(xch, image_name, &image_size);
+    image = xc_read_image(xch, params->image_file_name, &image_size);
     if (image == NULL) {
         PERROR("Could not read guest firmware image %s", image_name);
         goto error_out;
@@ -1087,7 +1087,7 @@ xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_n
 
     image_size = (image_size + PAGE_SIZE - 1) & PAGE_MASK;
 
-    if (setup_guest(xch, domid, (unsigned long)memsize, image,
+    if (setup_guest(xch, domid, (unsigned long)params->mem_size, image,
                     image_size) < 0) {
         ERROR("Error constructing guest OS");
         goto error_out;
@@ -1114,6 +1114,8 @@ error_out:
  * files/filenames.  If target < memsize, domain is created with
  * memsize pages marked populate-on-demand, and with a PoD cache size
  * of target.  If target == memsize, pages are populated normally.
+ *
+ * XXX:PoD isn't supported yet so setting target does nothing.
  */
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -1121,8 +1123,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name)
 {
-    /* XXX:PoD isn't supported yet */
-    return xc_hvm_build(xch, domid, target, image_name);
+    struct xc_hvm_params params;
+
+    params.mem_size = (uint64_t)memsize << 20;
+    params.mem_target = (uint64_t)target << 20;
+    params.image_file_name = image_name;
+
+    return xc_hvm_build(xch, domid, &params);
 }
 
 /*
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 1fa5658..31d4734 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -136,12 +136,12 @@ static int check_mmio_hole(uint64_t start, uint64_t memsize)
 }
 
 static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
+                       uint32_t dom, const struct xc_hvm_params *params,
                        char *image, unsigned long image_size)
 {
     xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long i, nr_pages = params->mem_size >> PAGE_SHIFT;
+    unsigned long target_pages = params->mem_target >> PAGE_SHIFT;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -153,11 +153,7 @@ static int setup_guest(xc_interface *xch,
         stat_1gb_pages = 0;
     int pod_mode = 0;
 
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
+    if ( nr_pages > target_pages )
         pod_mode = 1;
 
     memset(&elf, 0, sizeof(elf));
@@ -168,7 +164,7 @@ static int setup_guest(xc_interface *xch,
 
     elf_parse_binary(&elf);
     v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
+    v_end = params->mem_size;
 
     if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
     {
@@ -393,39 +389,34 @@ static int setup_guest(xc_interface *xch,
     return -1;
 }
 
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
 /* xc_hvm_build:
  * Create a domain for a virtualized Linux, using files/filenames.
  */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_params *hvm_params)
 {
-    char *image;
-    int  sts;
+    struct xc_hvm_params params = *hvm_params;
+    void *image;
     unsigned long image_size;
+    int sts;
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+    if ( domid == 0 )
+        return -1;
+    if ( params.image_file_name == NULL )
         return -1;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+    if ( params.mem_target == 0 )
+        params.mem_target = params.mem_size;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull << 20) )
+        return -1;
+
+    image = xc_read_image(xch, params.image_file_name, &image_size);
+    if ( image == NULL )
+        return -1;
+
+    sts = setup_guest(xch, domid, &params, image, image_size);
 
     free(image);
 
@@ -445,59 +436,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                            int target,
                            const char *image_name)
 {
-    char *image;
-    int  sts;
-    unsigned long image_size;
+    struct xc_hvm_params params = {};
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
+    params.mem_size = (uint64_t)memsize << 20;
+    params.mem_target = (uint64_t)target << 20;
+    params.image_file_name = image_name;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
+    return xc_hvm_build(xch, domid, &params);
 }
 
 /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 533e702..19b0382 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
                        unsigned int console_evtchn,
                        unsigned long *console_mfn);
 
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name);
+struct xc_hvm_params {
+    uint64_t mem_size;           /**< Memory size in bytes. */
+    uint64_t mem_target;         /**< Memory target in bytes. */
+    const char *image_file_name; /**< File name of the image to load. */
+};
+
+/**
+ * Build a HVM domain using a set of parameters.
+ * @parm xch    libxc context handle.
+ * @parm domid  domain ID for the new domain.
+ * @parm params parameters for the new domain.
+ *
+ * The memory size and image file parameters are required, the reset
+ * are optional.
+ */
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_params *hvm_params);
 
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -182,12 +195,6 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name);
 
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size);
-
 int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
 
 int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port);
diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
index 4b624a5..f7e2139 100644
--- a/tools/libxc/xg_private.c
+++ b/tools/libxc/xg_private.c
@@ -192,8 +192,7 @@ unsigned long csum_page(void *page)
 __attribute__((weak)) 
     int xc_hvm_build(xc_interface *xch,
                      uint32_t domid,
-                     int memsize,
-                     const char *image_name)
+                     const struct xc_hvm_params *hvm_params)
 {
     errno = ENOSYS;
     return -1;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:28:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RmP-0007dS-AQ; Tue, 28 Feb 2012 18:28: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 1S2RmN-0007cU-Os
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:28:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330453618!53746108!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26912 invoked from network); 28 Feb 2012 18:26:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:26:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10992258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 18:27:57 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 18:27:57 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 28 Feb 2012 18:27:52 +0000
Message-ID: <1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxc: pass parameters to xc_hvm_build() in
	a 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

From: David Vrabel <david.vrabel@citrix.com>

To allow new parameters to be added to the xc_hvm_build*() family of
functions, pass them in a structure.  Make the other variants fill in
the structure and call xc_hvm_build() (except for xc_hvm_build_mem()
which had no users and is removed).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/ia64/xc_ia64_hvm_build.c |   21 ++++--
 tools/libxc/xc_hvm_build.c           |  115 +++++++++-------------------------
 tools/libxc/xenguest.h               |   27 +++++---
 tools/libxc/xg_private.c             |    3 +-
 4 files changed, 62 insertions(+), 104 deletions(-)

diff --git a/tools/libxc/ia64/xc_ia64_hvm_build.c b/tools/libxc/ia64/xc_ia64_hvm_build.c
index 18be616..16dace0 100644
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c
@@ -912,8 +912,8 @@ setup_guest(xc_interface *xch, uint32_t dom, unsigned long memsize,
             char *image, unsigned long image_size)
 {
     xen_pfn_t *pfn_list;
-    unsigned long dom_memsize = memsize << 20;
-    unsigned long nr_pages = memsize << (20 - PAGE_SHIFT);
+    unsigned long dom_memsize = memsize;
+    unsigned long nr_pages = memsize >> PAGE_SHIFT;
     unsigned long vcpus;
     unsigned long nr_special_pages;
     unsigned long memmap_info_pfn;
@@ -1072,14 +1072,14 @@ error_out:
 }
 
 int
-xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_name)
+xc_hvm_build(xc_interface *xch, uint32_t domid, const struct xc_hvm_params *params)
 {
     vcpu_guest_context_any_t st_ctxt_any;
     vcpu_guest_context_t *ctxt = &st_ctxt_any.c;
     char *image = NULL;
     unsigned long image_size;
 
-    image = xc_read_image(xch, image_name, &image_size);
+    image = xc_read_image(xch, params->image_file_name, &image_size);
     if (image == NULL) {
         PERROR("Could not read guest firmware image %s", image_name);
         goto error_out;
@@ -1087,7 +1087,7 @@ xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_n
 
     image_size = (image_size + PAGE_SIZE - 1) & PAGE_MASK;
 
-    if (setup_guest(xch, domid, (unsigned long)memsize, image,
+    if (setup_guest(xch, domid, (unsigned long)params->mem_size, image,
                     image_size) < 0) {
         ERROR("Error constructing guest OS");
         goto error_out;
@@ -1114,6 +1114,8 @@ error_out:
  * files/filenames.  If target < memsize, domain is created with
  * memsize pages marked populate-on-demand, and with a PoD cache size
  * of target.  If target == memsize, pages are populated normally.
+ *
+ * XXX:PoD isn't supported yet so setting target does nothing.
  */
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -1121,8 +1123,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name)
 {
-    /* XXX:PoD isn't supported yet */
-    return xc_hvm_build(xch, domid, target, image_name);
+    struct xc_hvm_params params;
+
+    params.mem_size = (uint64_t)memsize << 20;
+    params.mem_target = (uint64_t)target << 20;
+    params.image_file_name = image_name;
+
+    return xc_hvm_build(xch, domid, &params);
 }
 
 /*
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 1fa5658..31d4734 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -136,12 +136,12 @@ static int check_mmio_hole(uint64_t start, uint64_t memsize)
 }
 
 static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
+                       uint32_t dom, const struct xc_hvm_params *params,
                        char *image, unsigned long image_size)
 {
     xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long i, nr_pages = params->mem_size >> PAGE_SHIFT;
+    unsigned long target_pages = params->mem_target >> PAGE_SHIFT;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -153,11 +153,7 @@ static int setup_guest(xc_interface *xch,
         stat_1gb_pages = 0;
     int pod_mode = 0;
 
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
+    if ( nr_pages > target_pages )
         pod_mode = 1;
 
     memset(&elf, 0, sizeof(elf));
@@ -168,7 +164,7 @@ static int setup_guest(xc_interface *xch,
 
     elf_parse_binary(&elf);
     v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
+    v_end = params->mem_size;
 
     if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
     {
@@ -393,39 +389,34 @@ static int setup_guest(xc_interface *xch,
     return -1;
 }
 
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
 /* xc_hvm_build:
  * Create a domain for a virtualized Linux, using files/filenames.
  */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_params *hvm_params)
 {
-    char *image;
-    int  sts;
+    struct xc_hvm_params params = *hvm_params;
+    void *image;
     unsigned long image_size;
+    int sts;
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+    if ( domid == 0 )
+        return -1;
+    if ( params.image_file_name == NULL )
         return -1;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+    if ( params.mem_target == 0 )
+        params.mem_target = params.mem_size;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull << 20) )
+        return -1;
+
+    image = xc_read_image(xch, params.image_file_name, &image_size);
+    if ( image == NULL )
+        return -1;
+
+    sts = setup_guest(xch, domid, &params, image, image_size);
 
     free(image);
 
@@ -445,59 +436,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                            int target,
                            const char *image_name)
 {
-    char *image;
-    int  sts;
-    unsigned long image_size;
+    struct xc_hvm_params params = {};
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
+    params.mem_size = (uint64_t)memsize << 20;
+    params.mem_target = (uint64_t)target << 20;
+    params.image_file_name = image_name;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
+    return xc_hvm_build(xch, domid, &params);
 }
 
 /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 533e702..19b0382 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
                        unsigned int console_evtchn,
                        unsigned long *console_mfn);
 
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name);
+struct xc_hvm_params {
+    uint64_t mem_size;           /**< Memory size in bytes. */
+    uint64_t mem_target;         /**< Memory target in bytes. */
+    const char *image_file_name; /**< File name of the image to load. */
+};
+
+/**
+ * Build a HVM domain using a set of parameters.
+ * @parm xch    libxc context handle.
+ * @parm domid  domain ID for the new domain.
+ * @parm params parameters for the new domain.
+ *
+ * The memory size and image file parameters are required, the reset
+ * are optional.
+ */
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_params *hvm_params);
 
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -182,12 +195,6 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name);
 
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size);
-
 int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
 
 int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port);
diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
index 4b624a5..f7e2139 100644
--- a/tools/libxc/xg_private.c
+++ b/tools/libxc/xg_private.c
@@ -192,8 +192,7 @@ unsigned long csum_page(void *page)
 __attribute__((weak)) 
     int xc_hvm_build(xc_interface *xch,
                      uint32_t domid,
-                     int memsize,
-                     const char *image_name)
+                     const struct xc_hvm_params *hvm_params)
 {
     errno = ENOSYS;
     return -1;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RtM-0008Bi-Qa; Tue, 28 Feb 2012 18:35:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1S2RtL-0008B3-5J
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:35:15 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330454107!8548566!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14267 invoked from network); 28 Feb 2012 18:35:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:35:08 -0000
Received: by yenl11 with SMTP id l11so41545126yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 10:35:07 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.236.170.134 as permitted sender) client-ip=10.236.170.134; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.236.170.134 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.236.170.134])
	by 10.236.170.134 with SMTP id p6mr30577506yhl.81.1330454107021
	(num_hops = 1); Tue, 28 Feb 2012 10:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=1a1yZ0F6t2bLzokisx2HtJLfLEL63hSUGwVq6mtBbmU=;
	b=tITaRFNkrhyfgGti5x6r9bs5Q9ryolq7dqgJZentxFj7MbKLhUmMsDdA5GlPjN4yJ6
	qWFJyQ8Al6BBiNKEAOD4djynHsgJ4ron7QyRpJPKQ0skLpZJ5818Laa9TM8dyOtKmpdK
	Ba0ktMdsDe0ppc1T0GvLvG6u1ZlByFbabsqQs=
Received: by 10.236.170.134 with SMTP id p6mr23101722yhl.81.1330454106915;
	Tue, 28 Feb 2012 10:35:06 -0800 (PST)
Received: from [10.80.3.61] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id m30sm13359801yhe.15.2012.02.28.10.35.04
	(version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 10:35:06 -0800 (PST)
Message-ID: <4F4D1E56.7000709@gmail.com>
Date: Tue, 28 Feb 2012 18:35:02 +0000
From: Anthony PERARD <anthony.perard@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
	<1330444295-8859-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330444295-8859-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, avi@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v5 1/6] cirrus_vga: do
	not reset videoram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/02/12 15:51, Stefano Stabellini wrote:
> There is no need to set the videoram to 0xff in cirrus_reset, because it
> is the BIOS' job.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18: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 1S2RtM-0008Bi-Qa; Tue, 28 Feb 2012 18:35:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1S2RtL-0008B3-5J
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:35:15 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330454107!8548566!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14267 invoked from network); 28 Feb 2012 18:35:08 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:35:08 -0000
Received: by yenl11 with SMTP id l11so41545126yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 10:35:07 -0800 (PST)
Received-SPF: pass (google.com: domain of anthony.perard@gmail.com designates
	10.236.170.134 as permitted sender) client-ip=10.236.170.134; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	anthony.perard@gmail.com designates 10.236.170.134 as permitted
	sender) smtp.mail=anthony.perard@gmail.com;
	dkim=pass header.i=anthony.perard@gmail.com
Received: from mr.google.com ([10.236.170.134])
	by 10.236.170.134 with SMTP id p6mr30577506yhl.81.1330454107021
	(num_hops = 1); Tue, 28 Feb 2012 10:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=1a1yZ0F6t2bLzokisx2HtJLfLEL63hSUGwVq6mtBbmU=;
	b=tITaRFNkrhyfgGti5x6r9bs5Q9ryolq7dqgJZentxFj7MbKLhUmMsDdA5GlPjN4yJ6
	qWFJyQ8Al6BBiNKEAOD4djynHsgJ4ron7QyRpJPKQ0skLpZJ5818Laa9TM8dyOtKmpdK
	Ba0ktMdsDe0ppc1T0GvLvG6u1ZlByFbabsqQs=
Received: by 10.236.170.134 with SMTP id p6mr23101722yhl.81.1330454106915;
	Tue, 28 Feb 2012 10:35:06 -0800 (PST)
Received: from [10.80.3.61] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id m30sm13359801yhe.15.2012.02.28.10.35.04
	(version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 10:35:06 -0800 (PST)
Message-ID: <4F4D1E56.7000709@gmail.com>
Date: Tue, 28 Feb 2012 18:35:02 +0000
From: Anthony PERARD <anthony.perard@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
	<1330444295-8859-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330444295-8859-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, avi@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v5 1/6] cirrus_vga: do
	not reset videoram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/02/12 15:51, Stefano Stabellini wrote:
> There is no need to set the videoram to 0xff in cirrus_reset, because it
> is the BIOS' job.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:48:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2S5q-0000T1-PY; Tue, 28 Feb 2012 18:48:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2S5p-0000So-Ig
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 18:48:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330454883!11149227!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25232 invoked from network); 28 Feb 2012 18:48:03 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:48:03 -0000
Received: by werp12 with SMTP id p12so2454753wer.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 10:48:03 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr50701350wib.3.1330454883241 (num_hops
	= 1); Tue, 28 Feb 2012 10:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=r/LO47lOABpH1ujKW59HYk+5yjU0Ow8CrGgLdRswmW4=;
	b=wrjMRfhUmkldWkBFDWTGaGR2pn3J3uE907800W8U/IEBwn0FY79ocVUSb025ba3bR2
	Ner0HjdBFyhDZBUEAjOT0ztNNbxglw4NTEZn/K1RNy2uQECPjdR/JXhi8XXM2ZS6KQW5
	pAe4B93qnjJvgA4e1OGi/QCOd6p75y/nEmEnA=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr40608307wib.3.1330454883060; Tue,
	28 Feb 2012 10:48:03 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Tue, 28 Feb 2012 10:48:02 -0800 (PST)
In-Reply-To: <CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
	<CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
Date: Tue, 28 Feb 2012 19:48:02 +0100
X-Google-Sender-Auth: nQqccN7kRbGXYIG4HS8OYfd-jIE
Message-ID: <CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jeffrey Karrels <karrelsj@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI4IEplZmZyZXkgS2FycmVscyA8a2FycmVsc2pAZ21haWwuY29tPjoKPj5BZGRlZCBh
dXRvdG9vbHMgbWFnaWMgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cwo+Cj4gTGV0IG1l
IHN0YXJ0IG92ZXIgb24gdGhpcyBvbmUuLi4gwqBXaGF0IGlzIHRoZSBpbnN0YWxsIG1ldGhvZG9s
b2d5IHdpdGgKPiB0aGUgcmVwbGFjZW1lbnQgb2YgdGhlIGN1c3RvbSBjaGVja3Mgd2l0aCAiYXV0
b3Rvb2xzIG1hZ2ljPyIgSSBhbQo+IHdvcmtpbmcgb24gYSBkaXN0IGJ1aWxkIGFuZCByZWFsaXpl
ZCB0aGF0IHRoZSBkaXN0IGJ1aWxkIGdvZXMgb3ZlciBhbmQKPiBncmFicyB0aGUgY2hlY2tzIG91
dCBvZiB0aGUgdG9vbHMgZGlyZWN0b3J5IHRvIGNoZWNrIHRoZSBpbnN0YWxsYXRpb24uCj4gwqBT
byBpZiBJIHdlcmUgdG86Cj4KPiAjaGcgY2xvbmUgLXIgMjQ4NjkgaHR0cDovL3hlbmJpdHMueGVu
Lm9yZy9oZy94ZW4tdW5zdGFibGUuaGcKPiAjY2QgeGVuLXVuc3RhYmxlCj4gIy4vY29uZmlndXJl
Cj4gI21ha2UgZGlzdAo+ICN0YXIgY3ZmeiBzb21ldGhpbmcudGFyLmd6IGRpc3QKPiAjc2NwIHNv
bWV0aGluZy50YXIuZ3ogeGVuQG5ld2hvc3Q6L3RlbXAKPiAjc3NoIHhlbkBuZXdob3N0Cj4gIy4u
Li4KPiAjLi9pbnN0YWxsLnNoCj4gLi4uCj4gQ2hlY2tpbmcgdG8gc2VlIHdoZXRoZXIgcHJlcmVx
dWlzaXRlIHRvb2xzIGFyZSBpbnN0YWxsZWQuLi4KPiAuL2luc3RhbGwuc2g6IGxpbmUgNTM6IGNk
OiAuL2luc3RhbGwvLi4vY2hlY2s6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKPiAuL2luc3Rh
bGwuc2g6IGxpbmUgNTQ6IC4vY2hrOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cj4gQWxsIGRv
bmUuCgpUaGlzIHNob3VsZCBmaXggaXQgKEkgaGF2ZW4ndCB0ZXN0ZWQpOgoKODwtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKaW5zdGFsbDogcmVtb3ZlIG9sZCBj
aGVja3MgZnJvbSBpbnN0YWxsLnNoCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJv
Z2VyLnBhdUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciBlMWZkYzU1MDliYjQgaW5zdGFsbC5zaAot
LS0gYS9pbnN0YWxsLnNoCVdlZCBGZWIgMjIgMDQ6MTU6MzQgMjAxMiArMDEwMAorKysgYi9pbnN0
YWxsLnNoCVdlZCBGZWIgMjIgMDQ6NDY6MDcgMjAxMiArMDEwMApAQCAtNDksOSArNDksNCBAQCBy
bSAtcmYgIiR0bXAiCgogZWNobyAiQWxsIGRvbmUuIgoKLWVjaG8gIkNoZWNraW5nIHRvIHNlZSB3
aGV0aGVyIHByZXJlcXVpc2l0ZSB0b29scyBhcmUgaW5zdGFsbGVkLi4uIgotY2QgJHNyYy8uLi9j
aGVjawotLi9jaGsgaW5zdGFsbAotZWNobyAiQWxsIGRvbmUuIgotCiBleGl0IDAKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:48:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2S5q-0000T1-PY; Tue, 28 Feb 2012 18:48:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2S5p-0000So-Ig
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 18:48:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330454883!11149227!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25232 invoked from network); 28 Feb 2012 18:48:03 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:48:03 -0000
Received: by werp12 with SMTP id p12so2454753wer.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 10:48:03 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.71 as permitted sender) client-ip=10.180.92.71; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.71 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.71])
	by 10.180.92.71 with SMTP id ck7mr50701350wib.3.1330454883241 (num_hops
	= 1); Tue, 28 Feb 2012 10:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=r/LO47lOABpH1ujKW59HYk+5yjU0Ow8CrGgLdRswmW4=;
	b=wrjMRfhUmkldWkBFDWTGaGR2pn3J3uE907800W8U/IEBwn0FY79ocVUSb025ba3bR2
	Ner0HjdBFyhDZBUEAjOT0ztNNbxglw4NTEZn/K1RNy2uQECPjdR/JXhi8XXM2ZS6KQW5
	pAe4B93qnjJvgA4e1OGi/QCOd6p75y/nEmEnA=
MIME-Version: 1.0
Received: by 10.180.92.71 with SMTP id ck7mr40608307wib.3.1330454883060; Tue,
	28 Feb 2012 10:48:03 -0800 (PST)
Received: by 10.216.229.170 with HTTP; Tue, 28 Feb 2012 10:48:02 -0800 (PST)
In-Reply-To: <CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
	<CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
Date: Tue, 28 Feb 2012 19:48:02 +0100
X-Google-Sender-Auth: nQqccN7kRbGXYIG4HS8OYfd-jIE
Message-ID: <CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Jeffrey Karrels <karrelsj@gmail.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI4IEplZmZyZXkgS2FycmVscyA8a2FycmVsc2pAZ21haWwuY29tPjoKPj5BZGRlZCBh
dXRvdG9vbHMgbWFnaWMgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cwo+Cj4gTGV0IG1l
IHN0YXJ0IG92ZXIgb24gdGhpcyBvbmUuLi4gwqBXaGF0IGlzIHRoZSBpbnN0YWxsIG1ldGhvZG9s
b2d5IHdpdGgKPiB0aGUgcmVwbGFjZW1lbnQgb2YgdGhlIGN1c3RvbSBjaGVja3Mgd2l0aCAiYXV0
b3Rvb2xzIG1hZ2ljPyIgSSBhbQo+IHdvcmtpbmcgb24gYSBkaXN0IGJ1aWxkIGFuZCByZWFsaXpl
ZCB0aGF0IHRoZSBkaXN0IGJ1aWxkIGdvZXMgb3ZlciBhbmQKPiBncmFicyB0aGUgY2hlY2tzIG91
dCBvZiB0aGUgdG9vbHMgZGlyZWN0b3J5IHRvIGNoZWNrIHRoZSBpbnN0YWxsYXRpb24uCj4gwqBT
byBpZiBJIHdlcmUgdG86Cj4KPiAjaGcgY2xvbmUgLXIgMjQ4NjkgaHR0cDovL3hlbmJpdHMueGVu
Lm9yZy9oZy94ZW4tdW5zdGFibGUuaGcKPiAjY2QgeGVuLXVuc3RhYmxlCj4gIy4vY29uZmlndXJl
Cj4gI21ha2UgZGlzdAo+ICN0YXIgY3ZmeiBzb21ldGhpbmcudGFyLmd6IGRpc3QKPiAjc2NwIHNv
bWV0aGluZy50YXIuZ3ogeGVuQG5ld2hvc3Q6L3RlbXAKPiAjc3NoIHhlbkBuZXdob3N0Cj4gIy4u
Li4KPiAjLi9pbnN0YWxsLnNoCj4gLi4uCj4gQ2hlY2tpbmcgdG8gc2VlIHdoZXRoZXIgcHJlcmVx
dWlzaXRlIHRvb2xzIGFyZSBpbnN0YWxsZWQuLi4KPiAuL2luc3RhbGwuc2g6IGxpbmUgNTM6IGNk
OiAuL2luc3RhbGwvLi4vY2hlY2s6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKPiAuL2luc3Rh
bGwuc2g6IGxpbmUgNTQ6IC4vY2hrOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cj4gQWxsIGRv
bmUuCgpUaGlzIHNob3VsZCBmaXggaXQgKEkgaGF2ZW4ndCB0ZXN0ZWQpOgoKODwtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKaW5zdGFsbDogcmVtb3ZlIG9sZCBj
aGVja3MgZnJvbSBpbnN0YWxsLnNoCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJv
Z2VyLnBhdUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciBlMWZkYzU1MDliYjQgaW5zdGFsbC5zaAot
LS0gYS9pbnN0YWxsLnNoCVdlZCBGZWIgMjIgMDQ6MTU6MzQgMjAxMiArMDEwMAorKysgYi9pbnN0
YWxsLnNoCVdlZCBGZWIgMjIgMDQ6NDY6MDcgMjAxMiArMDEwMApAQCAtNDksOSArNDksNCBAQCBy
bSAtcmYgIiR0bXAiCgogZWNobyAiQWxsIGRvbmUuIgoKLWVjaG8gIkNoZWNraW5nIHRvIHNlZSB3
aGV0aGVyIHByZXJlcXVpc2l0ZSB0b29scyBhcmUgaW5zdGFsbGVkLi4uIgotY2QgJHNyYy8uLi9j
aGVjawotLi9jaGsgaW5zdGFsbAotZWNobyAiQWxsIGRvbmUuIgotCiBleGl0IDAKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:58:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2SFi-0000km-Uf; Tue, 28 Feb 2012 18:58:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2SFg-0000kh-Mk
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:58:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330455491!13496840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20435 invoked from network); 28 Feb 2012 18:58:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:58:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22533997"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:58:10 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 13:58:10 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1S2SFV-0002VK-MJ;
	Tue, 28 Feb 2012 18:58:09 +0000
Message-ID: <4F4D23C1.9020101@citrix.com>
Date: Tue, 28 Feb 2012 18:58:09 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
	<1330444295-8859-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330444295-8859-2-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, avi@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v5 2/6] Introduce
	"save_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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/02/12 15:51, Stefano Stabellini wrote:
> - add an "is_ram" flag to SaveStateEntry;
>
> - add an "is_ram" parameter to register_savevm_live;
>
> - introduce a "save_devices" monitor command that can be used to save
> the state of non-ram devices.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   block-migration.c |    2 +-
>   hmp-commands.hx   |   14 ++++++++++
>   qmp-commands.hx   |   17 ++++++++++++
>   savevm.c          |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>   sysemu.h          |    1 +
>   vl.c              |    2 +-
>   vmstate.h         |    1 +
>   7 files changed, 106 insertions(+), 3 deletions(-)
>
> diff --git a/block-migration.c b/block-migration.c
> index 4467468..d283fd0 100644
> --- a/block-migration.c
> +++ b/block-migration.c
> @@ -722,6 +722,6 @@ void blk_mig_init(void)
>       QSIMPLEQ_INIT(&block_mig_state.bmds_list);
>       QSIMPLEQ_INIT(&block_mig_state.blk_list);
>
> -    register_savevm_live(NULL, "block", 0, 1, block_set_params,
> +    register_savevm_live(NULL, "block", 0, 1, 0, block_set_params,
>                            block_save_live, NULL, block_load,&block_mig_state);
>   }
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 64b3656..873abc9 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -280,6 +280,20 @@ a snapshot with the same tag or ID, it is replaced. More info at
>   ETEXI
>
>       {
> +        .name       = "save_devices",
> +        .args_type  = "filename:F",
> +        .params     = "filename",
> +        .help       = "save the state of non-ram devices.",
> +        .mhandler.cmd_new = do_save_device_state,
> +    },
> +
> +STEXI
> +@item save_devices @var{filename}
> +@findex save_devices
> +Save the state of non-ram devices.
> +ETEXI
> +
> +    {
>           .name       = "loadvm",
>           .args_type  = "name:s",
>           .params     = "tag|id",
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 705f704..619d9de 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -444,6 +444,23 @@ Note: inject-nmi is only supported for x86 guest currently, it will
>   EQMP
>
>       {
> +        .name       = "save_devices",
> +        .args_type  = "filename:F",
> +        .params     = "filename",
> +        .help       = "save the state of non-ram devices.",
> +        .user_print = monitor_user_noop,	
> +    .mhandler.cmd_new = do_save_device_state,
> +    },
> +
> +SQMP
> +save_devices
> +-------
> +
> +Save the state of non-ram devices.
> +
> +EQMP
> +
> +    {
>           .name       = "migrate",
>           .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
>           .params     = "[-d] [-b] [-i] uri",
> diff --git a/savevm.c b/savevm.c
> index 80be1ff..d0e62bb 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
>       void *opaque;
>       CompatEntry *compat;
>       int no_migrate;
> +    int is_ram;
>   } SaveStateEntry;
>
>
> @@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
>                            const char *idstr,
>                            int instance_id,
>                            int version_id,
> +                         int is_ram,
>                            SaveSetParamsHandler *set_params,
>                            SaveLiveStateHandler *save_live_state,
>                            SaveStateHandler *save_state,
> @@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
>       se->opaque = opaque;
>       se->vmsd = NULL;
>       se->no_migrate = 0;
> +    se->is_ram = is_ram;
>
>       if (dev&&  dev->parent_bus&&  dev->parent_bus->info->get_dev_path) {
>           char *id = dev->parent_bus->info->get_dev_path(dev);
> @@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
>                       LoadStateHandler *load_state,
>                       void *opaque)
>   {
> -    return register_savevm_live(dev, idstr, instance_id, version_id,
> +    return register_savevm_live(dev, idstr, instance_id, version_id, 0,
>                                   NULL, NULL, save_state, load_state, opaque);
>   }
>
> @@ -1728,6 +1731,43 @@ out:
>       return ret;
>   }
>
> +static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
> +{
> +    SaveStateEntry *se;
> +
> +    qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
> +    qemu_put_be32(f, QEMU_VM_FILE_VERSION);
> +
> +    cpu_synchronize_all_states();
> +
> +    QTAILQ_FOREACH(se,&savevm_handlers, entry) {
> +        int len;
> +
> +        if (se->is_ram)
> +            continue;
> +        if (se->save_state == NULL&&  se->vmsd == NULL)
> +            continue;
> +
> +        /* Section type */
> +        qemu_put_byte(f, QEMU_VM_SECTION_FULL);
> +        qemu_put_be32(f, se->section_id);
> +
> +        /* ID string */
> +        len = strlen(se->idstr);
> +        qemu_put_byte(f, len);
> +        qemu_put_buffer(f, (uint8_t *)se->idstr, len);
> +
> +        qemu_put_be32(f, se->instance_id);
> +        qemu_put_be32(f, se->version_id);
> +
> +        vmstate_save(f, se);
> +    }
> +
> +    qemu_put_byte(f, QEMU_VM_EOF);
> +
> +    return qemu_file_get_error(f);
> +}
> +
>   static SaveStateEntry *find_se(const char *idstr, int instance_id)
>   {
>       SaveStateEntry *se;
> @@ -2109,6 +2149,36 @@ void do_savevm(Monitor *mon, const QDict *qdict)
>           vm_start();
>   }
>
> +int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +    int ret;
> +    QEMUFile *f;
> +    int saved_vm_running;
> +    const char *filename = qdict_get_try_str(qdict, "filename");
> +
> +    saved_vm_running = runstate_is_running();
> +    vm_stop(RUN_STATE_SAVE_VM);
> +
> +    f = qemu_fopen(filename, "wb");
> +    if (!f) {
> +        monitor_printf(mon, "Could not open VM state file\n");
> +        ret = -1;
> +        goto the_end;
> +    }
> +    ret = qemu_save_device_state(mon, f);
> +    qemu_fclose(f);
> +    if (ret<  0) {
> +        monitor_printf(mon, "Error %d while writing VM\n", ret);
> +        goto the_end;
> +    }
> +    ret = 0;
> +
> + the_end:
> +    if (saved_vm_running)
> +        vm_start();
> +    return ret;
> +}
> +
>   int load_vmstate(const char *name)
>   {
>       BlockDriverState *bs, *bs_vm_state;
> diff --git a/sysemu.h b/sysemu.h
> index 98118cc..f4d5bf4 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -70,6 +70,7 @@ void qemu_remove_exit_notifier(Notifier *notify);
>   void qemu_add_machine_init_done_notifier(Notifier *notify);
>
>   void do_savevm(Monitor *mon, const QDict *qdict);
> +int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data);
>   int load_vmstate(const char *name);
>   void do_delvm(Monitor *mon, const QDict *qdict);
>   void do_info_snapshots(Monitor *mon);
> diff --git a/vl.c b/vl.c
> index 1d4c350..5b2b84c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3393,7 +3393,7 @@ int main(int argc, char **argv, char **envp)
>       default_drive(default_sdcard, snapshot, machine->use_scsi,
>                     IF_SD, 0, SD_OPTS);
>
> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> +    register_savevm_live(NULL, "ram", 0, 4, 1, NULL, ram_save_live, NULL,
>                            ram_load, NULL);
>
>       if (nb_numa_nodes>  0) {
> diff --git a/vmstate.h b/vmstate.h
> index 9d3c49c..3cef117 100644
> --- a/vmstate.h
> +++ b/vmstate.h
> @@ -44,6 +44,7 @@ int register_savevm_live(DeviceState *dev,
>                            const char *idstr,
>                            int instance_id,
>                            int version_id,
> +                         int is_ram,
>                            SaveSetParamsHandler *set_params,
>                            SaveLiveStateHandler *save_live_state,
>                            SaveStateHandler *save_state,

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 18:58:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 18:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2SFi-0000km-Uf; Tue, 28 Feb 2012 18:58:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1S2SFg-0000kh-Mk
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 18:58:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330455491!13496840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20435 invoked from network); 28 Feb 2012 18:58:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 18:58:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22533997"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 13:58:10 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 13:58:10 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1S2SFV-0002VK-MJ;
	Tue, 28 Feb 2012 18:58:09 +0000
Message-ID: <4F4D23C1.9020101@citrix.com>
Date: Tue, 28 Feb 2012 18:58:09 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
	<1330444295-8859-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330444295-8859-2-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, avi@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v5 2/6] Introduce
	"save_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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/02/12 15:51, Stefano Stabellini wrote:
> - add an "is_ram" flag to SaveStateEntry;
>
> - add an "is_ram" parameter to register_savevm_live;
>
> - introduce a "save_devices" monitor command that can be used to save
> the state of non-ram devices.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   block-migration.c |    2 +-
>   hmp-commands.hx   |   14 ++++++++++
>   qmp-commands.hx   |   17 ++++++++++++
>   savevm.c          |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>   sysemu.h          |    1 +
>   vl.c              |    2 +-
>   vmstate.h         |    1 +
>   7 files changed, 106 insertions(+), 3 deletions(-)
>
> diff --git a/block-migration.c b/block-migration.c
> index 4467468..d283fd0 100644
> --- a/block-migration.c
> +++ b/block-migration.c
> @@ -722,6 +722,6 @@ void blk_mig_init(void)
>       QSIMPLEQ_INIT(&block_mig_state.bmds_list);
>       QSIMPLEQ_INIT(&block_mig_state.blk_list);
>
> -    register_savevm_live(NULL, "block", 0, 1, block_set_params,
> +    register_savevm_live(NULL, "block", 0, 1, 0, block_set_params,
>                            block_save_live, NULL, block_load,&block_mig_state);
>   }
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 64b3656..873abc9 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -280,6 +280,20 @@ a snapshot with the same tag or ID, it is replaced. More info at
>   ETEXI
>
>       {
> +        .name       = "save_devices",
> +        .args_type  = "filename:F",
> +        .params     = "filename",
> +        .help       = "save the state of non-ram devices.",
> +        .mhandler.cmd_new = do_save_device_state,
> +    },
> +
> +STEXI
> +@item save_devices @var{filename}
> +@findex save_devices
> +Save the state of non-ram devices.
> +ETEXI
> +
> +    {
>           .name       = "loadvm",
>           .args_type  = "name:s",
>           .params     = "tag|id",
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 705f704..619d9de 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -444,6 +444,23 @@ Note: inject-nmi is only supported for x86 guest currently, it will
>   EQMP
>
>       {
> +        .name       = "save_devices",
> +        .args_type  = "filename:F",
> +        .params     = "filename",
> +        .help       = "save the state of non-ram devices.",
> +        .user_print = monitor_user_noop,	
> +    .mhandler.cmd_new = do_save_device_state,
> +    },
> +
> +SQMP
> +save_devices
> +-------
> +
> +Save the state of non-ram devices.
> +
> +EQMP
> +
> +    {
>           .name       = "migrate",
>           .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
>           .params     = "[-d] [-b] [-i] uri",
> diff --git a/savevm.c b/savevm.c
> index 80be1ff..d0e62bb 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
>       void *opaque;
>       CompatEntry *compat;
>       int no_migrate;
> +    int is_ram;
>   } SaveStateEntry;
>
>
> @@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
>                            const char *idstr,
>                            int instance_id,
>                            int version_id,
> +                         int is_ram,
>                            SaveSetParamsHandler *set_params,
>                            SaveLiveStateHandler *save_live_state,
>                            SaveStateHandler *save_state,
> @@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
>       se->opaque = opaque;
>       se->vmsd = NULL;
>       se->no_migrate = 0;
> +    se->is_ram = is_ram;
>
>       if (dev&&  dev->parent_bus&&  dev->parent_bus->info->get_dev_path) {
>           char *id = dev->parent_bus->info->get_dev_path(dev);
> @@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
>                       LoadStateHandler *load_state,
>                       void *opaque)
>   {
> -    return register_savevm_live(dev, idstr, instance_id, version_id,
> +    return register_savevm_live(dev, idstr, instance_id, version_id, 0,
>                                   NULL, NULL, save_state, load_state, opaque);
>   }
>
> @@ -1728,6 +1731,43 @@ out:
>       return ret;
>   }
>
> +static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
> +{
> +    SaveStateEntry *se;
> +
> +    qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
> +    qemu_put_be32(f, QEMU_VM_FILE_VERSION);
> +
> +    cpu_synchronize_all_states();
> +
> +    QTAILQ_FOREACH(se,&savevm_handlers, entry) {
> +        int len;
> +
> +        if (se->is_ram)
> +            continue;
> +        if (se->save_state == NULL&&  se->vmsd == NULL)
> +            continue;
> +
> +        /* Section type */
> +        qemu_put_byte(f, QEMU_VM_SECTION_FULL);
> +        qemu_put_be32(f, se->section_id);
> +
> +        /* ID string */
> +        len = strlen(se->idstr);
> +        qemu_put_byte(f, len);
> +        qemu_put_buffer(f, (uint8_t *)se->idstr, len);
> +
> +        qemu_put_be32(f, se->instance_id);
> +        qemu_put_be32(f, se->version_id);
> +
> +        vmstate_save(f, se);
> +    }
> +
> +    qemu_put_byte(f, QEMU_VM_EOF);
> +
> +    return qemu_file_get_error(f);
> +}
> +
>   static SaveStateEntry *find_se(const char *idstr, int instance_id)
>   {
>       SaveStateEntry *se;
> @@ -2109,6 +2149,36 @@ void do_savevm(Monitor *mon, const QDict *qdict)
>           vm_start();
>   }
>
> +int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +    int ret;
> +    QEMUFile *f;
> +    int saved_vm_running;
> +    const char *filename = qdict_get_try_str(qdict, "filename");
> +
> +    saved_vm_running = runstate_is_running();
> +    vm_stop(RUN_STATE_SAVE_VM);
> +
> +    f = qemu_fopen(filename, "wb");
> +    if (!f) {
> +        monitor_printf(mon, "Could not open VM state file\n");
> +        ret = -1;
> +        goto the_end;
> +    }
> +    ret = qemu_save_device_state(mon, f);
> +    qemu_fclose(f);
> +    if (ret<  0) {
> +        monitor_printf(mon, "Error %d while writing VM\n", ret);
> +        goto the_end;
> +    }
> +    ret = 0;
> +
> + the_end:
> +    if (saved_vm_running)
> +        vm_start();
> +    return ret;
> +}
> +
>   int load_vmstate(const char *name)
>   {
>       BlockDriverState *bs, *bs_vm_state;
> diff --git a/sysemu.h b/sysemu.h
> index 98118cc..f4d5bf4 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -70,6 +70,7 @@ void qemu_remove_exit_notifier(Notifier *notify);
>   void qemu_add_machine_init_done_notifier(Notifier *notify);
>
>   void do_savevm(Monitor *mon, const QDict *qdict);
> +int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data);
>   int load_vmstate(const char *name);
>   void do_delvm(Monitor *mon, const QDict *qdict);
>   void do_info_snapshots(Monitor *mon);
> diff --git a/vl.c b/vl.c
> index 1d4c350..5b2b84c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3393,7 +3393,7 @@ int main(int argc, char **argv, char **envp)
>       default_drive(default_sdcard, snapshot, machine->use_scsi,
>                     IF_SD, 0, SD_OPTS);
>
> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> +    register_savevm_live(NULL, "ram", 0, 4, 1, NULL, ram_save_live, NULL,
>                            ram_load, NULL);
>
>       if (nb_numa_nodes>  0) {
> diff --git a/vmstate.h b/vmstate.h
> index 9d3c49c..3cef117 100644
> --- a/vmstate.h
> +++ b/vmstate.h
> @@ -44,6 +44,7 @@ int register_savevm_live(DeviceState *dev,
>                            const char *idstr,
>                            int instance_id,
>                            int version_id,
> +                         int is_ram,
>                            SaveSetParamsHandler *set_params,
>                            SaveLiveStateHandler *save_live_state,
>                            SaveStateHandler *save_state,

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 19:05:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 19:05:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2SMC-0000xn-1l; Tue, 28 Feb 2012 19:05:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2SMA-0000xg-Jq
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 19:05:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330455896!3206044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10644 invoked from network); 28 Feb 2012 19:04:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 19:04:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10993750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 19:04:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 19:04:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2SM3-00026U-Tp;
	Tue, 28 Feb 2012 19:04:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2SM3-0004qL-Sb;
	Tue, 28 Feb 2012 19:04:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12105-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 19:04:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12105: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12105 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12105/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 19:05:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 19:05:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2SMC-0000xn-1l; Tue, 28 Feb 2012 19:05:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2SMA-0000xg-Jq
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 19:05:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330455896!3206044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10644 invoked from network); 28 Feb 2012 19:04:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 19:04:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10993750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 19:04:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 19:04:56 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2SM3-00026U-Tp;
	Tue, 28 Feb 2012 19:04:55 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2SM3-0004qL-Sb;
	Tue, 28 Feb 2012 19:04:55 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-12105-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 19:04:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12105: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12105 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12105/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 19:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 19: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 1S2Sp1-0001c1-Bb; Tue, 28 Feb 2012 19:34:51 +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 1S2Soz-0001bw-8j
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 19:34:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330457640!62126764!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30480 invoked from network); 28 Feb 2012 19:34:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 19:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22535683"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 14:34:46 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 14:34:46 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1S2Sov-00034c-O0;
	Tue, 28 Feb 2012 19:34:45 +0000
Message-ID: <4F4D2C55.20706@citrix.com>
Date: Tue, 28 Feb 2012 19:34:45 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
	<1330444295-8859-3-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330444295-8859-3-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, avi@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v5 3/6] Set runstate to
 INMIGRATE earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/02/12 15:51, Stefano Stabellini wrote:
> Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 19:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 19: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 1S2Sp1-0001c1-Bb; Tue, 28 Feb 2012 19:34:51 +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 1S2Soz-0001bw-8j
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 19:34:49 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330457640!62126764!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjMyNjg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30480 invoked from network); 28 Feb 2012 19:34:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 19:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="22535683"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 14:34:46 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 14:34:46 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1S2Sov-00034c-O0;
	Tue, 28 Feb 2012 19:34:45 +0000
Message-ID: <4F4D2C55.20706@citrix.com>
Date: Tue, 28 Feb 2012 19:34:45 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1202281525110.23091@kaball-desktop>
	<1330444295-8859-3-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1330444295-8859-3-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, avi@redhat.com
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH RESEND v5 3/6] Set runstate to
 INMIGRATE earlier
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/02/12 15:51, Stefano Stabellini wrote:
> Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 19:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 19: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 1S2TAi-0002QE-HC; Tue, 28 Feb 2012 19:57:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2TAg-0002Py-GZ
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 19:57:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330459027!3509476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29112 invoked from network); 28 Feb 2012 19:57:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 19:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10994300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 19:57:07 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 19:57:07 +0000
Message-ID: <1330459026.10008.57.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 19:57:06 +0000
In-Reply-To: <CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 17:51 +0000, Jeffrey Karrels wrote:

> > Have you changed anything here or are you saying that a pristine Xen
> > tree when built on CentOS installs 64 bit libraries to /usr/lib instead
> > of /usr/lib64? If so please can you be precise about what tree you are
> > running (e.g. the exact URL you cloned and which changeset you got) and
> > steps you took to install (e.g. what patches did you apply, what
> > commands did you type) and what exactly you saw (e.g. what was
> > in /usr/lib and what was in /usr/lib64)
> 
> #uname -a
> Linux xenbuild2.cyberlab 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24
> 02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
> 
> #hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
> #cd xen-unstable
> #./configure --enable-xsm --libdir=/usr/lib64

OK, so you are using something new enough to have the autoconf stuff --
I think this is simply a bug in that. I've CC'd Roger.

Ideally configure would auto-detect the right thing for the given system
and so --libdir would not be required. This would certainly be n
improvement over the pre-autoconf thing.

> #make dist
> #ls dist/install/usr/lib64
> python2.6
> #ls dist/install/usr/lib
> fs                     libvhd.so.1.0.0       libxenstat.so.0
> libblktap.a            libxenctrl.a          libxenstat.so.0.0
> libblktapctl.a         libxenctrl.so         libxenstore.a
> libblktapctl.so        libxenctrl.so.4.2     libxenstore.so
> libblktapctl.so.1.0    libxenctrl.so.4.2.0   libxenstore.so.3.0
> libblktapctl.so.1.0.0  libxenguest.a         libxenstore.so.3.0.1
> libblktap.so           libxenguest.so        libxenvchan.a
> libblktap.so.3.0       libxenguest.so.4.2    libxenvchan.so
> libblktap.so.3.0.0     libxenguest.so.4.2.0  libxenvchan.so.1.0
> libfsimage.so          libxenlight.a         libxenvchan.so.1.0.0
> libfsimage.so.1.0      libxenlight.so        libxlutil.a
> libfsimage.so.1.0.0    libxenlight.so.2.0    libxlutil.so
> libvhd.a               libxenlight.so.2.0.0  libxlutil.so.1.0
> libvhd.so              libxenstat.a          libxlutil.so.1.0.0
> libvhd.so.1.0          libxenstat.so         xen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 19:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 19: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 1S2TAi-0002QE-HC; Tue, 28 Feb 2012 19:57:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2TAg-0002Py-GZ
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 19:57:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330459027!3509476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29112 invoked from network); 28 Feb 2012 19:57:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 19:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="10994300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 19:57:07 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 28 Feb 2012 19:57:07 +0000
Message-ID: <1330459026.10008.57.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 19:57:06 +0000
In-Reply-To: <CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 17:51 +0000, Jeffrey Karrels wrote:

> > Have you changed anything here or are you saying that a pristine Xen
> > tree when built on CentOS installs 64 bit libraries to /usr/lib instead
> > of /usr/lib64? If so please can you be precise about what tree you are
> > running (e.g. the exact URL you cloned and which changeset you got) and
> > steps you took to install (e.g. what patches did you apply, what
> > commands did you type) and what exactly you saw (e.g. what was
> > in /usr/lib and what was in /usr/lib64)
> 
> #uname -a
> Linux xenbuild2.cyberlab 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24
> 02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
> 
> #hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
> #cd xen-unstable
> #./configure --enable-xsm --libdir=/usr/lib64

OK, so you are using something new enough to have the autoconf stuff --
I think this is simply a bug in that. I've CC'd Roger.

Ideally configure would auto-detect the right thing for the given system
and so --libdir would not be required. This would certainly be n
improvement over the pre-autoconf thing.

> #make dist
> #ls dist/install/usr/lib64
> python2.6
> #ls dist/install/usr/lib
> fs                     libvhd.so.1.0.0       libxenstat.so.0
> libblktap.a            libxenctrl.a          libxenstat.so.0.0
> libblktapctl.a         libxenctrl.so         libxenstore.a
> libblktapctl.so        libxenctrl.so.4.2     libxenstore.so
> libblktapctl.so.1.0    libxenctrl.so.4.2.0   libxenstore.so.3.0
> libblktapctl.so.1.0.0  libxenguest.a         libxenstore.so.3.0.1
> libblktap.so           libxenguest.so        libxenvchan.a
> libblktap.so.3.0       libxenguest.so.4.2    libxenvchan.so
> libblktap.so.3.0.0     libxenguest.so.4.2.0  libxenvchan.so.1.0
> libfsimage.so          libxenlight.a         libxenvchan.so.1.0.0
> libfsimage.so.1.0      libxenlight.so        libxlutil.a
> libfsimage.so.1.0.0    libxenlight.so.2.0    libxlutil.so
> libvhd.a               libxenlight.so.2.0.0  libxlutil.so.1.0
> libvhd.so              libxenstat.a          libxlutil.so.1.0.0
> libvhd.so.1.0          libxenstat.so         xen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:12:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2UL6-0004LM-Ng; Tue, 28 Feb 2012 21:12:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2UL5-0004LH-AS
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:12:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330463515!16892773!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzU3\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18660 invoked from network); 28 Feb 2012 21:11:56 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 21:11:56 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id D9AB3714070;
	Tue, 28 Feb 2012 13:11:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=nzyuoKL7Rs3J6oOk2PW+npvDBByZwxmfBQMBpWx5g+dn
	WjZW2AeRP7gw9Y1hShZ1eNVi2lV69nTtwI78XlGk+chZ2KDEpTpD63hf+I6jSDST
	8xs8tCjQxbWk9PRl3wrw1GYGFefJNhGMm+ZoD+Mf9Aq9dGpvo+P1g3lMzamxxhc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=d6ozUdX695K7bc6RtZpwASq/S70=; b=rF5UlGgM
	7Hi/t5O/S+KUvE9ZY2rdKu1f89tom9fv5vVuo9Y13oPCfbSBLQCaYGt0wlJSRcMu
	Z3MnMzo1JPSpBO52sYEWfLICedeq/4FU8SqO+gu0pVgz6LKXUm85rxkDJVA4h8XD
	dD70Kl5fqldhciA7nGbN5tc4HBwdZQQ1AXM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 61DAB714083; 
	Tue, 28 Feb 2012 13:11:53 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 13:11:54 -0800
Message-ID: <c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de> <20120227165152.GA32471@aepfle.de>
	<EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
Date: Tue, 28 Feb 2012 13:11:54 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 tim@xen.org,
 olaf@aepfle.de
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>
> On Feb 27, 2012, at 11:51 AM, Olaf Hering wrote:
>
>> On Sun, Feb 26, Olaf Hering wrote:
>>
>>> On Thu, Feb 23, Tim Deegan wrote:
>>>
>>>> This is v2 of the patch I posted last week, after feedback from
>>>> Andres.
>>>
>>> Tried this series, but processes in dom0 started to hang in D state
>>> when a paged guest is started. I will see if I can spot the error.
>>
>> This change for patch #5 is needed, especially the first part.
>> Now it appears to work.
>>
>> Olaf

Unfortunately, I get all kinds of borking on Win7 domains with Citrix PV
drivers 6.0. So it's a no-go from my end for now.

The pv drivers are calling memops on pages that are paged out, ka-boom.

I applied Tim's 6 patch series plus Olaf's fix. Xen WARNs below.
Andres

(XEN) Xen WARN at p2m.c:200
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 000000000000000b   rcx: ffff83083ffaff18
(XEN) rdx: 00000043bfcac680   rsi: 0000000000000000   rdi: 000000183f775000
(XEN) rbp: ffff83083ffaf9a8   rsp: ffff83083ffaf928   r8:  0000000000000001
(XEN) r9:  0000000000000000   r10: 000000000000000c   r11: fffff88002fe3b0e
(XEN) r12: ffff83183f7a1bb0   r13: ffff83083ffaf9dc   r14: 0000000000000000
(XEN) r15: 00000000000033c0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000183f793000   cr2: 000000007724f4df
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83083ffaf928:
(XEN)    ffff83083ffaff18 ffff83083ffaff18 0000000000000000 000000018012635a
(XEN)    ffff83083ffaf9d8 ffff83083ffaff18 ffff82c48030a760 ffff82c48030a760
(XEN)    ffff82c48030a760 ffff82c48030a760 01ff82c4801264b3 0000000000000000
(XEN)    ffff83183f7a3000 ffff83083ffafa28 0000000000000000 000000000183f7b9
(XEN)    ffff83083ffafa08 ffff82c480170b91 ffff830000000001 ffff83183f7a3010
(XEN)    0000000000000000 ffff82c4801b3d94 0000000b00000007 ffff83183f7a3000
(XEN)    fffff88002fe3b80 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafa88 ffff82c480170e4b 8b13687800000000 7d4d94af0000009f
(XEN)    0000000100007ff0 0000000000000000 00000000000033c0 ffff82c48015a3ff
(XEN)    0000000000000202 ffff83183f7a3000 ffff82c4801265c1 0000000000000008
(XEN)    0000000000000007 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafc78 ffff82c480114c72 0000000000000286 ffff83083ffafab8
(XEN)    ffff82c4801265c1 ffff83183f6a19a0 ffff83083ffafae8 ffff82c48012daa1
(XEN)    ffff83083ffafb18 0000000000000040 ffff83183f6a1990 ffff83183f7a3000
(XEN)    ffff83083ffafb18 ffff82c48012dbc5 0000000000000040 ffff83083ffeffd0
(XEN)    ffff83183f7a3000 ffff82c4803099c0 ffff83083ffafb68 ffff82c480105e63
(XEN)    0000000000000003 0000000000000000 ffff83183f6a19d0 ffff83083ffb6048
(XEN)    ffff83183f7a1bb0 0000000000000001 0000000000000001 0000000000000001
(XEN)    ffff83083ffafbf8 ffff82c4801e6f0d 00000000000000ff 0000000300000000
(XEN)    ffff83083ffafbc8 ffff83083ffafbc0 0000000000000000 ffff83083ffafcd8
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN)    [<ffff82c480170b91>] xenmem_add_to_physmap_once+0x610/0x773
(XEN)    [<ffff82c480170e4b>] arch_memory_op+0x157/0xc7a
(XEN)    [<ffff82c480114c72>] do_memory_op+0x1d60/0x1dce
(XEN)    [<ffff82c4801b5409>] hvm_memory_op+0x62/0x6a
(XEN)    [<ffff82c4801b84f1>] hvm_do_hypercall+0x1af/0x2f5
(XEN)    [<ffff82c4801d73a5>] vmx_vmexit_handler+0xef3/0x1849
(XEN)
(XEN) domain_crash called from p2m.c:200
(XEN) Domain 2 (vcpu#0) crashed on cpu#4:
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffffa8002252185>]
(XEN) RFLAGS: 0000000000000082   CONTEXT: hvm guest
(XEN) rax: 000000000000000c   rbx: 00000000000033c0   rcx: 0000000000000180
(XEN) rdx: 0000000000000007   rsi: fffff88002fe3b80   rdi: 0000000000000007
(XEN) rbp: 0000000000000001   rsp: fffff88002fe3b30   r8:  fffff88002fe3b80
(XEN) r9:  00000000ffffffff   r10: 0000000000000000   r11: fffff88002fe3b0e
(XEN) r12: 0000000000000004   r13: fffffa800222d200   r14: fffff880010d7730
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000007724f4df
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN) Xen WARN at p2m.c:200
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 000000000000000b   rcx: ffff83083ffaff18
(XEN) rdx: 00000043bfcac680   rsi: 0000000000000000   rdi: 000000183f775000
(XEN) rbp: ffff83083ffaf9a8   rsp: ffff83083ffaf928   r8:  0000000000000001
(XEN) r9:  0000000000000000   r10: 0000000000000002   r11: 0000000000000002
(XEN) r12: ffff83183f7a1bb0   r13: ffff83083ffaf9dc   r14: 0000000000000000
(XEN) r15: 00000000000033c0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000183f793000   cr2: 000000007724f4df
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83083ffaf928:
(XEN)    ffff83083ffaff18 ffff83083ffaff18 0000000000000000 000000018012635a
(XEN)    ffff83083ffaf9d8 ffff83083ffaff18 ffff82c48030a760 ffff82c48030a760
(XEN)    ffff82c48030a760 ffff82c48030a760 01ff82c4801264b3 0000000000000000
(XEN)    ffff83183f7a3000 ffff83083ffafa28 0000000000000000 000000000183f7b9
(XEN)    ffff83083ffafa08 ffff82c480170b91 ffff830000000001 ffff83183f7a3010
(XEN)    0000000000000000 ffff82c4801b3d94 0000000b00000007 ffff83183f7a3000
(XEN)    fffff88002fe3b80 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafa88 ffff82c480170e4b 8b13687800000000 7d4d94af0000009f
(XEN)    0000000100007ff0 0000000000000000 00000000000033c0 ffff82c48015a3ff
(XEN)    0000000000000202 ffff83183f7a3000 ffff82c4801265c1 0000000000000008
(XEN)    0000000000000007 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafc78 ffff82c480114c72 0000000000000286 ffff83083ffafab8
(XEN)    ffff82c4801265c1 ffff83183f6a19a0 ffff83083ffafae8 ffff82c48012daa1
(XEN)    ffff83083ffafb18 0000000000000040 ffff83183f6a1990 ffff83183f7a3000
(XEN)    ffff83083ffafb18 ffff82c48012dbc5 0000000000000040 ffff83083ffeffd0
(XEN)    ffff83183f7a3000 ffff82c4803099c0 ffff83083ffafb68 ffff82c480105e63
(XEN)    0000000000000003 0000000000000000 ffff83183f6a19d0 ffff83083ffb6048
(XEN)    ffff83183f7a1bb0 0000000000000001 0000000000000001 0000000000000001
(XEN)    ffff83083ffafbf8 ffff82c4801e6f0d 00000000000000ff 0000000300000000
(XEN)    ffff83083ffafbc8 ffff83083ffafbc0 0000000000000000 ffff83083ffafcd8
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN)    [<ffff82c480170b91>] xenmem_add_to_physmap_once+0x610/0x773
(XEN)    [<ffff82c480170e4b>] arch_memory_op+0x157/0xc7a
(XEN)    [<ffff82c480114c72>] do_memory_op+0x1d60/0x1dce
(XEN)    [<ffff82c4801b5409>] hvm_memory_op+0x62/0x6a
(XEN)    [<ffff82c4801b84f1>] hvm_do_hypercall+0x1af/0x2f5
(XEN)    [<ffff82c4801d73a5>] vmx_vmexit_handler+0xef3/0x1849
(XEN)
(XEN) domain_crash called from p2m.c:200
(XEN) Xen WARN at p2m.c:200
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 000000000000000b   rcx: ffff83083ffaff18
(XEN) rdx: 00000043bfcac680   rsi: 0000000000000000   rdi: 000000183f775000
(XEN) rbp: ffff83083ffaf9a8   rsp: ffff83083ffaf928   r8:  0000000000000001
(XEN) r9:  0000000000000000   r10: 0000000000000003   r11: 0000000000000003
(XEN) r12: ffff83183f7a1bb0   r13: ffff83083ffaf9dc   r14: 0000000000000000
(XEN) r15: 00000000000033c0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000183f793000   cr2: 000000007724f4df
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83083ffaf928:
(XEN)    ffff83083ffaff18 ffff83083ffaff18 0000000000000000 000000018012635a
(XEN)    ffff83083ffaf9d8 ffff83083ffaff18 ffff82c48030a760 ffff82c48030a760
(XEN)    ffff82c48030a760 ffff82c48030a760 01ff82c4801264b3 0000000000000000
(XEN)    ffff83183f7a3000 ffff83083ffafa28 0000000000000000 000000000183f7b9
(XEN)    ffff83083ffafa08 ffff82c480170b91 ffff830000000001 ffff83183f7a3010
(XEN)    0000000000000000 ffff82c4801b3d94 0000000b00000007 ffff83183f7a3000
(XEN)    fffff88002fe3b80 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafa88 ffff82c480170e4b 8b13687800000000 7d4d94af0000009f
(XEN)    0000000100007ff0 0000000000000000 00000000000033c0 ffff82c48015a3ff
(XEN)    0000000000000202 ffff83183f7a3000 ffff82c4801265c1 0000000000000008
(XEN)    0000000000000007 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafc78 ffff82c480114c72 0000000000000286 ffff83083ffafab8
(XEN)    ffff82c4801265c1 ffff83183f6a19a0 ffff83083ffafae8 ffff82c48012daa1
(XEN)    ffff83083ffafb18 0000000000000040 ffff83183f6a1990 ffff83183f7a3000
(XEN)    ffff83083ffafb18 ffff82c48012dbc5 0000000000000040 ffff83083ffeffd0
(XEN)    ffff83183f7a3000 ffff82c4803099c0 ffff83083ffafb68 ffff82c480105e63
(XEN)    0000000000000003 0000000000000000 ffff83183f6a19d0 ffff83083ffb6048
(XEN)    ffff83183f7a1bb0 0000000000000001 0000000000000001 0000000000000001
(XEN)    ffff83083ffafbf8 ffff82c4801e6f0d 00000000000000ff 0000000300000000
(XEN)    ffff83083ffafbc8 ffff83083ffafbc0 0000000000000000 ffff83083ffafcd8
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN)    [<ffff82c480170b91>] xenmem_add_to_physmap_once+0x610/0x773
(XEN)    [<ffff82c480170e4b>] arch_memory_op+0x157/0xc7a
(XEN)    [<ffff82c480114c72>] do_memory_op+0x1d60/0x1dce
(XEN)    [<ffff82c4801b5409>] hvm_memory_op+0x62/0x6a
(XEN)    [<ffff82c4801b84f1>] hvm_do_hypercall+0x1af/0x2f5
(XEN)    [<ffff82c4801d73a5>] vmx_vmexit_handler+0xef3/0x1849
(XEN)
(XEN) domain_crash called from p2m.c:200



>>
>>
>> # HG changeset patch
>> # Parent c3738598897f5239a72cabde676f5e86fd4c8241
>>
>> diff -r c3738598897f xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -999,6 +999,10 @@ int hvm_vcpu_initialise(struct vcpu *v)
>>
>>     v->arch.hvm_vcpu.inject_trap = -1;
>>
>> +#ifdef CONFIG_X86_64
>> +    init_waitqueue_head(&v->arch.hvm_vcpu.mem_paging_wq);
>> +#endif
>> +
>> #ifdef CONFIG_COMPAT
>>     rc = setup_compat_arg_xlat(v);
>>     if ( rc != 0 )
>> diff -r c3738598897f xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -183,8 +183,8 @@ again:
>>             p2m_mem_paging_populate(p2m->domain, gfn);
>>
>>         /* Wait until the pager finishes paging it in */
>> -        current->arch.mem_paging_gfn = gfn;
>> -        wait_event(current->arch.mem_paging_wq, ({
>> +        current->arch.hvm_vcpu.mem_paging_gfn = gfn;
>> +        wait_event(current->arch.hvm_vcpu.mem_paging_wq, ({
>>                     int done;
>>                     mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
>>                     done = (*t != p2m_ram_paging_in);
>> @@ -1190,8 +1190,8 @@ void p2m_mem_paging_resume(struct domain
>>         }
>>         /* Wake any vcpus that were waiting for this GFN */
>>         for_each_vcpu ( d, v )
>> -            if ( v->arch.mem_paging_gfn == rsp.gfn )
>> -                wake_up_all(&v->arch.mem_paging_wq);
>> +            if ( v->arch.hvm_vcpu.mem_paging_gfn == rsp.gfn )
>> +                wake_up_all(&v->arch.hvm_vcpu.mem_paging_wq);
>>     }
>> }
>>
>> diff -r c3738598897f xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -494,12 +494,6 @@ struct arch_vcpu
>>
>>     struct paging_vcpu paging;
>>
>> -#ifdef CONFIG_X86_64
>> -    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
>> -    struct waitqueue_head mem_paging_wq;
>> -    unsigned long mem_paging_gfn;
>> -#endif
>> -
>> #ifdef CONFIG_X86_32
>>     /* map_domain_page() mapping cache. */
>>     struct mapcache_vcpu mapcache;
>> diff -r c3738598897f xen/include/asm-x86/hvm/vcpu.h
>> --- a/xen/include/asm-x86/hvm/vcpu.h
>> +++ b/xen/include/asm-x86/hvm/vcpu.h
>> @@ -170,6 +170,13 @@ struct hvm_vcpu {
>>     unsigned long inject_cr2;
>>
>>     struct viridian_vcpu viridian;
>> +
>> +#ifdef CONFIG_X86_64
>> +    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
>> +    struct waitqueue_head mem_paging_wq;
>> +    unsigned long mem_paging_gfn;
>> +#endif
>> +
>> };
>>
>> #endif /* __ASM_X86_HVM_VCPU_H__ */
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:12:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2UL6-0004LM-Ng; Tue, 28 Feb 2012 21:12:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2UL5-0004LH-AS
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:12:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330463515!16892773!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzU3\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MzU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18660 invoked from network); 28 Feb 2012 21:11:56 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 21:11:56 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id D9AB3714070;
	Tue, 28 Feb 2012 13:11:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=nzyuoKL7Rs3J6oOk2PW+npvDBByZwxmfBQMBpWx5g+dn
	WjZW2AeRP7gw9Y1hShZ1eNVi2lV69nTtwI78XlGk+chZ2KDEpTpD63hf+I6jSDST
	8xs8tCjQxbWk9PRl3wrw1GYGFefJNhGMm+ZoD+Mf9Aq9dGpvo+P1g3lMzamxxhc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=d6ozUdX695K7bc6RtZpwASq/S70=; b=rF5UlGgM
	7Hi/t5O/S+KUvE9ZY2rdKu1f89tom9fv5vVuo9Y13oPCfbSBLQCaYGt0wlJSRcMu
	Z3MnMzo1JPSpBO52sYEWfLICedeq/4FU8SqO+gu0pVgz6LKXUm85rxkDJVA4h8XD
	dD70Kl5fqldhciA7nGbN5tc4HBwdZQQ1AXM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 61DAB714083; 
	Tue, 28 Feb 2012 13:11:53 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 13:11:54 -0800
Message-ID: <c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de> <20120227165152.GA32471@aepfle.de>
	<EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
Date: Tue, 28 Feb 2012 13:11:54 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 tim@xen.org,
 olaf@aepfle.de
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>
> On Feb 27, 2012, at 11:51 AM, Olaf Hering wrote:
>
>> On Sun, Feb 26, Olaf Hering wrote:
>>
>>> On Thu, Feb 23, Tim Deegan wrote:
>>>
>>>> This is v2 of the patch I posted last week, after feedback from
>>>> Andres.
>>>
>>> Tried this series, but processes in dom0 started to hang in D state
>>> when a paged guest is started. I will see if I can spot the error.
>>
>> This change for patch #5 is needed, especially the first part.
>> Now it appears to work.
>>
>> Olaf

Unfortunately, I get all kinds of borking on Win7 domains with Citrix PV
drivers 6.0. So it's a no-go from my end for now.

The pv drivers are calling memops on pages that are paged out, ka-boom.

I applied Tim's 6 patch series plus Olaf's fix. Xen WARNs below.
Andres

(XEN) Xen WARN at p2m.c:200
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 000000000000000b   rcx: ffff83083ffaff18
(XEN) rdx: 00000043bfcac680   rsi: 0000000000000000   rdi: 000000183f775000
(XEN) rbp: ffff83083ffaf9a8   rsp: ffff83083ffaf928   r8:  0000000000000001
(XEN) r9:  0000000000000000   r10: 000000000000000c   r11: fffff88002fe3b0e
(XEN) r12: ffff83183f7a1bb0   r13: ffff83083ffaf9dc   r14: 0000000000000000
(XEN) r15: 00000000000033c0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000183f793000   cr2: 000000007724f4df
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83083ffaf928:
(XEN)    ffff83083ffaff18 ffff83083ffaff18 0000000000000000 000000018012635a
(XEN)    ffff83083ffaf9d8 ffff83083ffaff18 ffff82c48030a760 ffff82c48030a760
(XEN)    ffff82c48030a760 ffff82c48030a760 01ff82c4801264b3 0000000000000000
(XEN)    ffff83183f7a3000 ffff83083ffafa28 0000000000000000 000000000183f7b9
(XEN)    ffff83083ffafa08 ffff82c480170b91 ffff830000000001 ffff83183f7a3010
(XEN)    0000000000000000 ffff82c4801b3d94 0000000b00000007 ffff83183f7a3000
(XEN)    fffff88002fe3b80 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafa88 ffff82c480170e4b 8b13687800000000 7d4d94af0000009f
(XEN)    0000000100007ff0 0000000000000000 00000000000033c0 ffff82c48015a3ff
(XEN)    0000000000000202 ffff83183f7a3000 ffff82c4801265c1 0000000000000008
(XEN)    0000000000000007 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafc78 ffff82c480114c72 0000000000000286 ffff83083ffafab8
(XEN)    ffff82c4801265c1 ffff83183f6a19a0 ffff83083ffafae8 ffff82c48012daa1
(XEN)    ffff83083ffafb18 0000000000000040 ffff83183f6a1990 ffff83183f7a3000
(XEN)    ffff83083ffafb18 ffff82c48012dbc5 0000000000000040 ffff83083ffeffd0
(XEN)    ffff83183f7a3000 ffff82c4803099c0 ffff83083ffafb68 ffff82c480105e63
(XEN)    0000000000000003 0000000000000000 ffff83183f6a19d0 ffff83083ffb6048
(XEN)    ffff83183f7a1bb0 0000000000000001 0000000000000001 0000000000000001
(XEN)    ffff83083ffafbf8 ffff82c4801e6f0d 00000000000000ff 0000000300000000
(XEN)    ffff83083ffafbc8 ffff83083ffafbc0 0000000000000000 ffff83083ffafcd8
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN)    [<ffff82c480170b91>] xenmem_add_to_physmap_once+0x610/0x773
(XEN)    [<ffff82c480170e4b>] arch_memory_op+0x157/0xc7a
(XEN)    [<ffff82c480114c72>] do_memory_op+0x1d60/0x1dce
(XEN)    [<ffff82c4801b5409>] hvm_memory_op+0x62/0x6a
(XEN)    [<ffff82c4801b84f1>] hvm_do_hypercall+0x1af/0x2f5
(XEN)    [<ffff82c4801d73a5>] vmx_vmexit_handler+0xef3/0x1849
(XEN)
(XEN) domain_crash called from p2m.c:200
(XEN) Domain 2 (vcpu#0) crashed on cpu#4:
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    0010:[<fffffa8002252185>]
(XEN) RFLAGS: 0000000000000082   CONTEXT: hvm guest
(XEN) rax: 000000000000000c   rbx: 00000000000033c0   rcx: 0000000000000180
(XEN) rdx: 0000000000000007   rsi: fffff88002fe3b80   rdi: 0000000000000007
(XEN) rbp: 0000000000000001   rsp: fffff88002fe3b30   r8:  fffff88002fe3b80
(XEN) r9:  00000000ffffffff   r10: 0000000000000000   r11: fffff88002fe3b0e
(XEN) r12: 0000000000000004   r13: fffffa800222d200   r14: fffff880010d7730
(XEN) r15: 0000000000000001   cr0: 0000000080050031   cr4: 00000000000006f8
(XEN) cr3: 0000000000187000   cr2: 000000007724f4df
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0000   cs: 0010
(XEN) Xen WARN at p2m.c:200
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 000000000000000b   rcx: ffff83083ffaff18
(XEN) rdx: 00000043bfcac680   rsi: 0000000000000000   rdi: 000000183f775000
(XEN) rbp: ffff83083ffaf9a8   rsp: ffff83083ffaf928   r8:  0000000000000001
(XEN) r9:  0000000000000000   r10: 0000000000000002   r11: 0000000000000002
(XEN) r12: ffff83183f7a1bb0   r13: ffff83083ffaf9dc   r14: 0000000000000000
(XEN) r15: 00000000000033c0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000183f793000   cr2: 000000007724f4df
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83083ffaf928:
(XEN)    ffff83083ffaff18 ffff83083ffaff18 0000000000000000 000000018012635a
(XEN)    ffff83083ffaf9d8 ffff83083ffaff18 ffff82c48030a760 ffff82c48030a760
(XEN)    ffff82c48030a760 ffff82c48030a760 01ff82c4801264b3 0000000000000000
(XEN)    ffff83183f7a3000 ffff83083ffafa28 0000000000000000 000000000183f7b9
(XEN)    ffff83083ffafa08 ffff82c480170b91 ffff830000000001 ffff83183f7a3010
(XEN)    0000000000000000 ffff82c4801b3d94 0000000b00000007 ffff83183f7a3000
(XEN)    fffff88002fe3b80 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafa88 ffff82c480170e4b 8b13687800000000 7d4d94af0000009f
(XEN)    0000000100007ff0 0000000000000000 00000000000033c0 ffff82c48015a3ff
(XEN)    0000000000000202 ffff83183f7a3000 ffff82c4801265c1 0000000000000008
(XEN)    0000000000000007 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafc78 ffff82c480114c72 0000000000000286 ffff83083ffafab8
(XEN)    ffff82c4801265c1 ffff83183f6a19a0 ffff83083ffafae8 ffff82c48012daa1
(XEN)    ffff83083ffafb18 0000000000000040 ffff83183f6a1990 ffff83183f7a3000
(XEN)    ffff83083ffafb18 ffff82c48012dbc5 0000000000000040 ffff83083ffeffd0
(XEN)    ffff83183f7a3000 ffff82c4803099c0 ffff83083ffafb68 ffff82c480105e63
(XEN)    0000000000000003 0000000000000000 ffff83183f6a19d0 ffff83083ffb6048
(XEN)    ffff83183f7a1bb0 0000000000000001 0000000000000001 0000000000000001
(XEN)    ffff83083ffafbf8 ffff82c4801e6f0d 00000000000000ff 0000000300000000
(XEN)    ffff83083ffafbc8 ffff83083ffafbc0 0000000000000000 ffff83083ffafcd8
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN)    [<ffff82c480170b91>] xenmem_add_to_physmap_once+0x610/0x773
(XEN)    [<ffff82c480170e4b>] arch_memory_op+0x157/0xc7a
(XEN)    [<ffff82c480114c72>] do_memory_op+0x1d60/0x1dce
(XEN)    [<ffff82c4801b5409>] hvm_memory_op+0x62/0x6a
(XEN)    [<ffff82c4801b84f1>] hvm_do_hypercall+0x1af/0x2f5
(XEN)    [<ffff82c4801d73a5>] vmx_vmexit_handler+0xef3/0x1849
(XEN)
(XEN) domain_crash called from p2m.c:200
(XEN) Xen WARN at p2m.c:200
(XEN) ----[ Xen-4.2-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 000000000000000b   rcx: ffff83083ffaff18
(XEN) rdx: 00000043bfcac680   rsi: 0000000000000000   rdi: 000000183f775000
(XEN) rbp: ffff83083ffaf9a8   rsp: ffff83083ffaf928   r8:  0000000000000001
(XEN) r9:  0000000000000000   r10: 0000000000000003   r11: 0000000000000003
(XEN) r12: ffff83183f7a1bb0   r13: ffff83083ffaf9dc   r14: 0000000000000000
(XEN) r15: 00000000000033c0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000183f793000   cr2: 000000007724f4df
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83083ffaf928:
(XEN)    ffff83083ffaff18 ffff83083ffaff18 0000000000000000 000000018012635a
(XEN)    ffff83083ffaf9d8 ffff83083ffaff18 ffff82c48030a760 ffff82c48030a760
(XEN)    ffff82c48030a760 ffff82c48030a760 01ff82c4801264b3 0000000000000000
(XEN)    ffff83183f7a3000 ffff83083ffafa28 0000000000000000 000000000183f7b9
(XEN)    ffff83083ffafa08 ffff82c480170b91 ffff830000000001 ffff83183f7a3010
(XEN)    0000000000000000 ffff82c4801b3d94 0000000b00000007 ffff83183f7a3000
(XEN)    fffff88002fe3b80 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafa88 ffff82c480170e4b 8b13687800000000 7d4d94af0000009f
(XEN)    0000000100007ff0 0000000000000000 00000000000033c0 ffff82c48015a3ff
(XEN)    0000000000000202 ffff83183f7a3000 ffff82c4801265c1 0000000000000008
(XEN)    0000000000000007 fffff88002fe3b80 ffff8300bf2ea000 ffff82c4801b5344
(XEN)    ffff83083ffafc78 ffff82c480114c72 0000000000000286 ffff83083ffafab8
(XEN)    ffff82c4801265c1 ffff83183f6a19a0 ffff83083ffafae8 ffff82c48012daa1
(XEN)    ffff83083ffafb18 0000000000000040 ffff83183f6a1990 ffff83183f7a3000
(XEN)    ffff83083ffafb18 ffff82c48012dbc5 0000000000000040 ffff83083ffeffd0
(XEN)    ffff83183f7a3000 ffff82c4803099c0 ffff83083ffafb68 ffff82c480105e63
(XEN)    0000000000000003 0000000000000000 ffff83183f6a19d0 ffff83083ffb6048
(XEN)    ffff83183f7a1bb0 0000000000000001 0000000000000001 0000000000000001
(XEN)    ffff83083ffafbf8 ffff82c4801e6f0d 00000000000000ff 0000000300000000
(XEN)    ffff83083ffafbc8 ffff83083ffafbc0 0000000000000000 ffff83083ffafcd8
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e08e2>] __get_gfn_type_access+0x230/0x3ee
(XEN)    [<ffff82c480170b91>] xenmem_add_to_physmap_once+0x610/0x773
(XEN)    [<ffff82c480170e4b>] arch_memory_op+0x157/0xc7a
(XEN)    [<ffff82c480114c72>] do_memory_op+0x1d60/0x1dce
(XEN)    [<ffff82c4801b5409>] hvm_memory_op+0x62/0x6a
(XEN)    [<ffff82c4801b84f1>] hvm_do_hypercall+0x1af/0x2f5
(XEN)    [<ffff82c4801d73a5>] vmx_vmexit_handler+0xef3/0x1849
(XEN)
(XEN) domain_crash called from p2m.c:200



>>
>>
>> # HG changeset patch
>> # Parent c3738598897f5239a72cabde676f5e86fd4c8241
>>
>> diff -r c3738598897f xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -999,6 +999,10 @@ int hvm_vcpu_initialise(struct vcpu *v)
>>
>>     v->arch.hvm_vcpu.inject_trap = -1;
>>
>> +#ifdef CONFIG_X86_64
>> +    init_waitqueue_head(&v->arch.hvm_vcpu.mem_paging_wq);
>> +#endif
>> +
>> #ifdef CONFIG_COMPAT
>>     rc = setup_compat_arg_xlat(v);
>>     if ( rc != 0 )
>> diff -r c3738598897f xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -183,8 +183,8 @@ again:
>>             p2m_mem_paging_populate(p2m->domain, gfn);
>>
>>         /* Wait until the pager finishes paging it in */
>> -        current->arch.mem_paging_gfn = gfn;
>> -        wait_event(current->arch.mem_paging_wq, ({
>> +        current->arch.hvm_vcpu.mem_paging_gfn = gfn;
>> +        wait_event(current->arch.hvm_vcpu.mem_paging_wq, ({
>>                     int done;
>>                     mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
>>                     done = (*t != p2m_ram_paging_in);
>> @@ -1190,8 +1190,8 @@ void p2m_mem_paging_resume(struct domain
>>         }
>>         /* Wake any vcpus that were waiting for this GFN */
>>         for_each_vcpu ( d, v )
>> -            if ( v->arch.mem_paging_gfn == rsp.gfn )
>> -                wake_up_all(&v->arch.mem_paging_wq);
>> +            if ( v->arch.hvm_vcpu.mem_paging_gfn == rsp.gfn )
>> +                wake_up_all(&v->arch.hvm_vcpu.mem_paging_wq);
>>     }
>> }
>>
>> diff -r c3738598897f xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -494,12 +494,6 @@ struct arch_vcpu
>>
>>     struct paging_vcpu paging;
>>
>> -#ifdef CONFIG_X86_64
>> -    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
>> -    struct waitqueue_head mem_paging_wq;
>> -    unsigned long mem_paging_gfn;
>> -#endif
>> -
>> #ifdef CONFIG_X86_32
>>     /* map_domain_page() mapping cache. */
>>     struct mapcache_vcpu mapcache;
>> diff -r c3738598897f xen/include/asm-x86/hvm/vcpu.h
>> --- a/xen/include/asm-x86/hvm/vcpu.h
>> +++ b/xen/include/asm-x86/hvm/vcpu.h
>> @@ -170,6 +170,13 @@ struct hvm_vcpu {
>>     unsigned long inject_cr2;
>>
>>     struct viridian_vcpu viridian;
>> +
>> +#ifdef CONFIG_X86_64
>> +    /* Mem-paging: this vcpu is waiting for a gfn to be paged in */
>> +    struct waitqueue_head mem_paging_wq;
>> +    unsigned long mem_paging_gfn;
>> +#endif
>> +
>> };
>>
>> #endif /* __ASM_X86_HVM_VCPU_H__ */
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2UgX-0004cy-5W; Tue, 28 Feb 2012 21:34:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2UgW-0004cf-4g
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:34:12 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330464844!15331430!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3MjkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7900 invoked from network); 28 Feb 2012 21:34:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 21:34: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 q1SLXwNk004252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 28 Feb 2012 21:33:59 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
	q1SLXvq1004680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 28 Feb 2012 21:33:57 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
	q1SLWuWa030144; Tue, 28 Feb 2012 15:32:56 -0600
MIME-Version: 1.0
Message-ID: <5e49fa0f-fe13-4e8f-bbbe-4855fd82701c@default>
Date: Tue, 28 Feb 2012 13:32:42 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: George Dunlap <dunlapg@umich.edu>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<CAFLBxZZSPwPd0q7ng3BLW+nRaFaxCLYNX98xEcJinbU9jk0emw@mail.gmail.com>
In-Reply-To: <CAFLBxZZSPwPd0q7ng3BLW+nRaFaxCLYNX98xEcJinbU9jk0emw@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F4D4848.0088,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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: George Dunlap [mailto:dunlapg@umich.edu]
> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
> =

> On Mon, Feb 27, 2012 at 11:40 PM, Dan Magenheimer
> <dan.magenheimer@oracle.com> wrote:
> >> From: Olaf Hering [mailto:olaf@aepfle.de]
> >
> > Hi Olaf --
> >
> > Thanks for the reply! =A0Since Tim answers my questions later in the
> > thread, one quick comment...
> >
> >> To me memory overcommit means swapping, which is what xenpaging does:
> >> turn the whole guest gfn range into some sort of virtual memory,
> >> transparent to the guest.
> >>
> >> xenpaging is the red emergency knob to free some host memory without
> >> caring about the actual memory constraints within the paged guests.
> >
> > Sure, but the whole point of increasing RAM in one or more guests
> > is to increase performance, and if overcommitting *always* means
> > swapping, why would anyone use it?
> >
> > So xenpaging is fine and useful, but IMHO only in conjunction
> > with some other technology that reduces total physical RAM usage
> > to less than sum(max_mem(all VMs)).
> =

> I agree -- overcommitting means giving the guests the illusion of more
> aggregate memory than there is.  Paging is one way of doing that; page
> sharing is another way.  The big reason paging is needed is if guests
> start to "call in" the committments, by writing to previously shared
> pages.  I would think tmem would also come under "memory overcommit".

Yes and no.  By default, tmem's primary role is to grease the
transfer of RAM capacity from one VM to another while minimizing the
loss of performance that occurs when aggressively selfballooning
(or maybe doing "host-policy-driven-ballooning-with-a-semantic-gap").

However, tmem has two optional features "tmem_compress" and
"tmem_dedup" which do result in "memory overcommit" and neither
has the "call in the commitments" issue that occurs with shared
pages, so tmem does not require xenpaging.

That said, I can conceive of a RAMster*-like implementation for
which the ability to move hypervisor pages to dom0 might be
useful/necessary, so some parts of the xenpaging code in the
hypervisor might be required.

* http://lwn.net/Articles/481681/ =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2UgX-0004cy-5W; Tue, 28 Feb 2012 21:34:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2UgW-0004cf-4g
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:34:12 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1330464844!15331430!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3MjkwOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7900 invoked from network); 28 Feb 2012 21:34:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2012 21:34: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 q1SLXwNk004252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 28 Feb 2012 21:33:59 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
	q1SLXvq1004680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 28 Feb 2012 21:33:57 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
	q1SLWuWa030144; Tue, 28 Feb 2012 15:32:56 -0600
MIME-Version: 1.0
Message-ID: <5e49fa0f-fe13-4e8f-bbbe-4855fd82701c@default>
Date: Tue, 28 Feb 2012 13:32:42 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: George Dunlap <dunlapg@umich.edu>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<CAFLBxZZSPwPd0q7ng3BLW+nRaFaxCLYNX98xEcJinbU9jk0emw@mail.gmail.com>
In-Reply-To: <CAFLBxZZSPwPd0q7ng3BLW+nRaFaxCLYNX98xEcJinbU9jk0emw@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F4D4848.0088,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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: George Dunlap [mailto:dunlapg@umich.edu]
> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
> =

> On Mon, Feb 27, 2012 at 11:40 PM, Dan Magenheimer
> <dan.magenheimer@oracle.com> wrote:
> >> From: Olaf Hering [mailto:olaf@aepfle.de]
> >
> > Hi Olaf --
> >
> > Thanks for the reply! =A0Since Tim answers my questions later in the
> > thread, one quick comment...
> >
> >> To me memory overcommit means swapping, which is what xenpaging does:
> >> turn the whole guest gfn range into some sort of virtual memory,
> >> transparent to the guest.
> >>
> >> xenpaging is the red emergency knob to free some host memory without
> >> caring about the actual memory constraints within the paged guests.
> >
> > Sure, but the whole point of increasing RAM in one or more guests
> > is to increase performance, and if overcommitting *always* means
> > swapping, why would anyone use it?
> >
> > So xenpaging is fine and useful, but IMHO only in conjunction
> > with some other technology that reduces total physical RAM usage
> > to less than sum(max_mem(all VMs)).
> =

> I agree -- overcommitting means giving the guests the illusion of more
> aggregate memory than there is.  Paging is one way of doing that; page
> sharing is another way.  The big reason paging is needed is if guests
> start to "call in" the committments, by writing to previously shared
> pages.  I would think tmem would also come under "memory overcommit".

Yes and no.  By default, tmem's primary role is to grease the
transfer of RAM capacity from one VM to another while minimizing the
loss of performance that occurs when aggressively selfballooning
(or maybe doing "host-policy-driven-ballooning-with-a-semantic-gap").

However, tmem has two optional features "tmem_compress" and
"tmem_dedup" which do result in "memory overcommit" and neither
has the "call in the commitments" issue that occurs with shared
pages, so tmem does not require xenpaging.

That said, I can conceive of a RAMster*-like implementation for
which the ability to move hypervisor pages to dom0 might be
useful/necessary, so some parts of the xenpaging code in the
hypervisor might be required.

* http://lwn.net/Articles/481681/ =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:56:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2V1F-0004s4-Oq; Tue, 28 Feb 2012 21:55:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2V1D-0004rS-UY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:55:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330466128!15339070!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NzAz\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NzAz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5305 invoked from network); 28 Feb 2012 21:55:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-8.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 21:55:29 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id DB0FC714085;
	Tue, 28 Feb 2012 13:55:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=L+SLhY8AguKpB4G2kPLZ4huPaLVPkjMNt5Hw4yL//So8
	Tm4Z+H5HhUW6FrZmdVMMRHIy0zmc5G1xLwkJgOByCgLMg/30/Zmh4eU3Snl/mgFh
	DvgCOSARWwurVy8p+m+nOuE0694NYBheBST04wG3zZt6aEUI8xJimOqX1mEhPak=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=AUUumTpvzp7q0mxJzFmaB4bVydE=; b=N/seY6oxOWs
	eDqj0qT4XITK0R7W+LXGGZRfLtyZ9MxhrYBKgA8aZxnuL4T0pEQNkQBAP/7PUTCe
	1DZYHvT13xgkvyD2r45HuLXyzoSlgSda9NkyCURcPOT6iDz4GeOi4WMv0+86GxCL
	aRpyGO/5nI0X6wlrKrvAj2rnL87RmkBQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id F35AA714070; 
	Tue, 28 Feb 2012 13:55:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c44e9fe0ecca69b516d8f45fcf37393aedfb5ee2
Message-Id: <c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1330466175@xdev.gridcentric.ca>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 28 Feb 2012 16:56:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page_alloc.c  |  92 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h |   1 +
 2 files changed, 93 insertions(+), 0 deletions(-)


When a low memory threshold on the Xen heap is reached, we fire a global dom0
virq. If someone's listening, they can free up some more memory. The low
threshold is configurable via the command line token 'low_mem_virq_limit", and
defaults to 64MiB.

We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
xenballoond, or anything else that can be fired through xencommons.

We error-check the low mem virq against initial available heap (after dom0
allocation), to avoid firing immediately.

Virq issuing is controlled by a hysteresis algorithm: when memory dips below a
threshold, the virq is issued and the next virq will fire when memory shrinks
another order of magnitude. The virq will not fire again in the current "band"
until memory grows over the next higher order of magnitude.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 0696aa1de7c2 -r c44e9fe0ecca xen/common/page_alloc.c
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/event.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
@@ -300,6 +301,91 @@ static unsigned long init_node_heap(int 
     return needed;
 }
 
+/* Default to 64 MiB */
+#define DEFAULT_LOW_MEM_VIRQ    (((paddr_t) 64)   << 20)
+#define MAX_LOW_MEM_VIRQ        (((paddr_t) 1024) << 20)
+
+static paddr_t __read_mostly opt_low_mem_virq = DEFAULT_LOW_MEM_VIRQ;
+size_param("low_mem_virq_limit", opt_low_mem_virq);
+
+/* Thresholds to control hysteresis. In pages */
+/* When memory grows above this threshold, reset hysteresis.
+ * -1 initially to not reset until at least one virq issued. */
+static unsigned long low_mem_virq_high      = -1UL;
+/* Threshold at which we issue virq */
+static unsigned long low_mem_virq_th        = 0;
+/* Original threshold after all checks completed */
+static unsigned long low_mem_virq_orig      = 0;
+/* Order for current threshold */
+static unsigned int  low_mem_virq_th_order  = 0;
+
+/* Perform bootstrapping checks and set bounds */
+static void __init setup_low_mem_virq(void)
+{
+    unsigned int order;
+    paddr_t threshold;
+
+    /* Dom0 has already been allocated by now. So check we won't 
+     * be complaining immediately with whatever's left of the heap. */
+    threshold = min(opt_low_mem_virq, 
+                    ((paddr_t) total_avail_pages) << PAGE_SHIFT);
+
+    /* Then, cap to some predefined maximum */
+    threshold = min(threshold, MAX_LOW_MEM_VIRQ);
+
+    /* If the user specified no knob, and we are at the current available 
+     * level, halve the threshold. */
+    if ( (opt_low_mem_virq == DEFAULT_LOW_MEM_VIRQ)
+            && (threshold == (((paddr_t) total_avail_pages) << PAGE_SHIFT)) )
+        threshold >>= 1;
+
+    /* Threshold bytes -> pages */
+    low_mem_virq_th = threshold >> PAGE_SHIFT;
+
+    /* Next, round the threshold down to the next order */
+    order = get_order_from_pages(low_mem_virq_th);
+    if ( (1UL << order) > low_mem_virq_th ) 
+        order--;
+
+    /* Set bounds, ready to go */
+    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",
+            low_mem_virq_th);
+}
+
+static void check_low_mem_virq(void)
+{
+    if ( total_avail_pages <= low_mem_virq_th )
+    {
+        send_global_virq(VIRQ_ENOMEM);
+
+        /* Update thresholds. Next warning will be when we drop below
+         * next order. However, we wait until we grow beyond one
+         * order above us to complain again at the current order */
+        low_mem_virq_high   = 1UL << (low_mem_virq_th_order + 1);
+        if ( low_mem_virq_th_order > 0 )
+            low_mem_virq_th_order--;
+        low_mem_virq_th     = 1UL << low_mem_virq_th_order;
+        return;
+    }
+
+    if ( total_avail_pages >= low_mem_virq_high )
+    {
+        /* Reset hysteresis. Bring threshold up one order.
+         * If we are back where originally set, set high
+         * threshold to -1 to avoid further growth of 
+         * virq threshold. */
+        low_mem_virq_th_order++;
+        low_mem_virq_th = 1UL << low_mem_virq_th_order;
+        if ( low_mem_virq_th == low_mem_virq_orig )
+            low_mem_virq_high = -1UL;
+        else
+            low_mem_virq_high = 1UL << (low_mem_virq_th_order + 2);
+    }
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi,
@@ -420,6 +506,8 @@ static struct page_info *alloc_heap_page
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
+    check_low_mem_virq();
+
     if ( d != NULL )
         d->last_alloc_node = node;
 
@@ -1022,6 +1110,10 @@ void __init scrub_heap_pages(void)
     }
 
     printk("done.\n");
+
+    /* Now that the heap is initialized, run checks and set bounds
+     * for the low mem virq algorithm. */
+    setup_low_mem_virq();
 }
 
 
diff -r 0696aa1de7c2 -r c44e9fe0ecca xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #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       */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:56:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2V1F-0004s4-Oq; Tue, 28 Feb 2012 21:55:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2V1D-0004rS-UY
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:55:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1330466128!15339070!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NzAz\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NzAz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5305 invoked from network); 28 Feb 2012 21:55:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.81) by server-8.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 21:55:29 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id DB0FC714085;
	Tue, 28 Feb 2012 13:55:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=L+SLhY8AguKpB4G2kPLZ4huPaLVPkjMNt5Hw4yL//So8
	Tm4Z+H5HhUW6FrZmdVMMRHIy0zmc5G1xLwkJgOByCgLMg/30/Zmh4eU3Snl/mgFh
	DvgCOSARWwurVy8p+m+nOuE0694NYBheBST04wG3zZt6aEUI8xJimOqX1mEhPak=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=AUUumTpvzp7q0mxJzFmaB4bVydE=; b=N/seY6oxOWs
	eDqj0qT4XITK0R7W+LXGGZRfLtyZ9MxhrYBKgA8aZxnuL4T0pEQNkQBAP/7PUTCe
	1DZYHvT13xgkvyD2r45HuLXyzoSlgSda9NkyCURcPOT6iDz4GeOi4WMv0+86GxCL
	aRpyGO/5nI0X6wlrKrvAj2rnL87RmkBQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id F35AA714070; 
	Tue, 28 Feb 2012 13:55:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c44e9fe0ecca69b516d8f45fcf37393aedfb5ee2
Message-Id: <c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1330466175@xdev.gridcentric.ca>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 28 Feb 2012 16:56:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/page_alloc.c  |  92 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h |   1 +
 2 files changed, 93 insertions(+), 0 deletions(-)


When a low memory threshold on the Xen heap is reached, we fire a global dom0
virq. If someone's listening, they can free up some more memory. The low
threshold is configurable via the command line token 'low_mem_virq_limit", and
defaults to 64MiB.

We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
xenballoond, or anything else that can be fired through xencommons.

We error-check the low mem virq against initial available heap (after dom0
allocation), to avoid firing immediately.

Virq issuing is controlled by a hysteresis algorithm: when memory dips below a
threshold, the virq is issued and the next virq will fire when memory shrinks
another order of magnitude. The virq will not fire again in the current "band"
until memory grows over the next higher order of magnitude.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 0696aa1de7c2 -r c44e9fe0ecca xen/common/page_alloc.c
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/event.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
@@ -300,6 +301,91 @@ static unsigned long init_node_heap(int 
     return needed;
 }
 
+/* Default to 64 MiB */
+#define DEFAULT_LOW_MEM_VIRQ    (((paddr_t) 64)   << 20)
+#define MAX_LOW_MEM_VIRQ        (((paddr_t) 1024) << 20)
+
+static paddr_t __read_mostly opt_low_mem_virq = DEFAULT_LOW_MEM_VIRQ;
+size_param("low_mem_virq_limit", opt_low_mem_virq);
+
+/* Thresholds to control hysteresis. In pages */
+/* When memory grows above this threshold, reset hysteresis.
+ * -1 initially to not reset until at least one virq issued. */
+static unsigned long low_mem_virq_high      = -1UL;
+/* Threshold at which we issue virq */
+static unsigned long low_mem_virq_th        = 0;
+/* Original threshold after all checks completed */
+static unsigned long low_mem_virq_orig      = 0;
+/* Order for current threshold */
+static unsigned int  low_mem_virq_th_order  = 0;
+
+/* Perform bootstrapping checks and set bounds */
+static void __init setup_low_mem_virq(void)
+{
+    unsigned int order;
+    paddr_t threshold;
+
+    /* Dom0 has already been allocated by now. So check we won't 
+     * be complaining immediately with whatever's left of the heap. */
+    threshold = min(opt_low_mem_virq, 
+                    ((paddr_t) total_avail_pages) << PAGE_SHIFT);
+
+    /* Then, cap to some predefined maximum */
+    threshold = min(threshold, MAX_LOW_MEM_VIRQ);
+
+    /* If the user specified no knob, and we are at the current available 
+     * level, halve the threshold. */
+    if ( (opt_low_mem_virq == DEFAULT_LOW_MEM_VIRQ)
+            && (threshold == (((paddr_t) total_avail_pages) << PAGE_SHIFT)) )
+        threshold >>= 1;
+
+    /* Threshold bytes -> pages */
+    low_mem_virq_th = threshold >> PAGE_SHIFT;
+
+    /* Next, round the threshold down to the next order */
+    order = get_order_from_pages(low_mem_virq_th);
+    if ( (1UL << order) > low_mem_virq_th ) 
+        order--;
+
+    /* Set bounds, ready to go */
+    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",
+            low_mem_virq_th);
+}
+
+static void check_low_mem_virq(void)
+{
+    if ( total_avail_pages <= low_mem_virq_th )
+    {
+        send_global_virq(VIRQ_ENOMEM);
+
+        /* Update thresholds. Next warning will be when we drop below
+         * next order. However, we wait until we grow beyond one
+         * order above us to complain again at the current order */
+        low_mem_virq_high   = 1UL << (low_mem_virq_th_order + 1);
+        if ( low_mem_virq_th_order > 0 )
+            low_mem_virq_th_order--;
+        low_mem_virq_th     = 1UL << low_mem_virq_th_order;
+        return;
+    }
+
+    if ( total_avail_pages >= low_mem_virq_high )
+    {
+        /* Reset hysteresis. Bring threshold up one order.
+         * If we are back where originally set, set high
+         * threshold to -1 to avoid further growth of 
+         * virq threshold. */
+        low_mem_virq_th_order++;
+        low_mem_virq_th = 1UL << low_mem_virq_th_order;
+        if ( low_mem_virq_th == low_mem_virq_orig )
+            low_mem_virq_high = -1UL;
+        else
+            low_mem_virq_high = 1UL << (low_mem_virq_th_order + 2);
+    }
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
     unsigned int zone_lo, unsigned int zone_hi,
@@ -420,6 +506,8 @@ static struct page_info *alloc_heap_page
     total_avail_pages -= request;
     ASSERT(total_avail_pages >= 0);
 
+    check_low_mem_virq();
+
     if ( d != NULL )
         d->last_alloc_node = node;
 
@@ -1022,6 +1110,10 @@ void __init scrub_heap_pages(void)
     }
 
     printk("done.\n");
+
+    /* Now that the heap is initialized, run checks and set bounds
+     * for the low mem virq algorithm. */
+    setup_low_mem_virq();
 }
 
 
diff -r 0696aa1de7c2 -r c44e9fe0ecca xen/include/public/xen.h
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,6 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #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       */
 
 /* Architecture-specific VIRQ definitions. */
 #define VIRQ_ARCH_0    16

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 21:56:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2V1C-0004rj-Cg; Tue, 28 Feb 2012 21:55:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2V1B-0004rR-8U
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:55:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330466126!15369545!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9004 invoked from network); 28 Feb 2012 21:55:26 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.74) by server-11.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 21:55:26 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id C4FCD714083;
	Tue, 28 Feb 2012 13:55:25 -0800 (PST)
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=EBdZPNAyWASkW1uytCWj9/
	xULEbo3DD/3HjGtCDi9L1mamgtdNlujQN242Z4zKCQb4uGkibfzZJ48akfOMR0Jt
	ND7klrP1VB3S8jG2nhJ0eZw2eyJmY/4bJGeSe4aF651mWU3Py7SAwAqvZTDKHF/I
	UzsXgkkU/ZgbzgMH0KwE8=
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=ROqr0G4ye3n7
	3qjqtkPJ1yG390w=; b=biBbn5wxfCGEYcN/UjYPzFvBRaoWtQIEh4epVZFU4dDi
	By/vUM+5lvT5qgSmWh318SN/jPVYsbesZcJoSZmdT8WA3idd39P01o58qw3Rvelg
	XsTGR3vlizctyaDmuKX0HLsjjGlr1OEQqYoIcgm632GF0DSjNsmpcKpjVoY59Gc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 9D862714070; 
	Tue, 28 Feb 2012 13:55:24 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1330466175@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 28 Feb 2012 16:56:15 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Virq for low memory condition, V3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 now a patch series:
- First patch is hypervisor code to implement a virq that will fire upon low 
memory conditions. Integrated feedback from Jan Beulich since version posted on
Feb 23rd.
- Second patch is demo code to leverage the virq form dom0 user-space.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 

 xen/common/page_alloc.c  |   92 +++++++++++++++++++++++++++++
 xen/include/public/xen.h |    1 +
 tools/misc/Makefile      |    7 +-
 tools/misc/lowmemd.c     |  148 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 246 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 Tue Feb 28 21:56:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2V1C-0004rj-Cg; Tue, 28 Feb 2012 21:55:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2V1B-0004rR-8U
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:55:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330466126!15369545!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9004 invoked from network); 28 Feb 2012 21:55:26 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.74) by server-11.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 21:55:26 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id C4FCD714083;
	Tue, 28 Feb 2012 13:55:25 -0800 (PST)
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=EBdZPNAyWASkW1uytCWj9/
	xULEbo3DD/3HjGtCDi9L1mamgtdNlujQN242Z4zKCQb4uGkibfzZJ48akfOMR0Jt
	ND7klrP1VB3S8jG2nhJ0eZw2eyJmY/4bJGeSe4aF651mWU3Py7SAwAqvZTDKHF/I
	UzsXgkkU/ZgbzgMH0KwE8=
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=ROqr0G4ye3n7
	3qjqtkPJ1yG390w=; b=biBbn5wxfCGEYcN/UjYPzFvBRaoWtQIEh4epVZFU4dDi
	By/vUM+5lvT5qgSmWh318SN/jPVYsbesZcJoSZmdT8WA3idd39P01o58qw3Rvelg
	XsTGR3vlizctyaDmuKX0HLsjjGlr1OEQqYoIcgm632GF0DSjNsmpcKpjVoY59Gc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 9D862714070; 
	Tue, 28 Feb 2012 13:55:24 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1330466175@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 28 Feb 2012 16:56:15 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Virq for low memory condition, V3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 now a patch series:
- First patch is hypervisor code to implement a virq that will fire upon low 
memory conditions. Integrated feedback from Jan Beulich since version posted on
Feb 23rd.
- Second patch is demo code to leverage the virq form dom0 user-space.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
 

 xen/common/page_alloc.c  |   92 +++++++++++++++++++++++++++++
 xen/include/public/xen.h |    1 +
 tools/misc/Makefile      |    7 +-
 tools/misc/lowmemd.c     |  148 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 246 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 Tue Feb 28 21:56:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2V1B-0004rY-0q; Tue, 28 Feb 2012 21:55:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2V19-0004rT-I1
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:55:31 +0000
Received: from [85.158.139.83:7840] by server-2.bemta-5.messagelabs.com id
	B5/F0-20263-25D4D4F4; Tue, 28 Feb 2012 21:55:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330466129!9783757!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ4NDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20483 invoked from network); 28 Feb 2012 21:55:30 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-182.messagelabs.com with SMTP;
	28 Feb 2012 21:55:30 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 44263714088;
	Tue, 28 Feb 2012 13:55:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tdKc/4qcqy1LF6djidzC/2aOB20xb8QFs+IFa3TZXXa0
	6UqnCSYOT/NUuv5co2DtcJkttI+y11ie+m2ttD3bXY0tEzV8dSdSSXyxSHjVKR3l
	j2ciKAq8HpOfvHbUziLpbvsDV495nxBVCRCdAINKtzPDUwnkGVZIS3ZIsSdenJQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=0BLsiMH2TlyA3GMD33+mxXWtjiE=; b=oHZ2Hc0Z8OP
	VdZJClp1+eEwoAqF2Z/997hsGD8unZZvUI2JImnXxILWb7eRCogrF/Hzf7YjcIR6
	r1CAgBEi+IMcYVhlpeFsZtwGGVw34f/nhZHYQtV2qjSkkFFBLzYBwYrr97/RprmX
	7Us8L5mNinCe60G82rAYMLdi+IS4EE0k=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 36FFE714086; 
	Tue, 28 Feb 2012 13:55:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4300b0d765753dc359bb206f4fdeb3cf302fa56f
Message-Id: <4300b0d765753dc359bb.1330466177@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1330466175@xdev.gridcentric.ca>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 28 Feb 2012 16:56:17 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Lowmemd: Simple demo code to show use of
	VIRQ_ENOMEM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/misc/Makefile  |    7 +-
 tools/misc/lowmemd.c |  148 +++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 153 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c44e9fe0ecca -r 4300b0d76575 tools/misc/Makefile
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 HDRS     = $(wildcard *.h)
 
 TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
-TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash
+TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
 
@@ -21,7 +21,7 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -70,6 +70,9 @@ xen-hptool: xen-hptool.o
 xenwatchdogd: xenwatchdogd.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+lowmemd: lowmemd.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
+
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
diff -r c44e9fe0ecca -r 4300b0d76575 tools/misc/lowmemd.c
--- /dev/null
+++ b/tools/misc/lowmemd.c
@@ -0,0 +1,148 @@
+/*
+ * lowmemd: demo VIRQ_ENOMEM
+ * Andres Lagar-Cavilla (GridCentric Inc.)
+ */
+
+#include <stdio.h>
+#include <xenctrl.h>
+#include <xs.h>
+#include <stdlib.h>
+#include <string.h>
+
+static evtchn_port_t virq_port      = -1;
+static xc_evtchn *xce_handle        = NULL;
+static xc_interface *xch            = NULL;
+static struct xs_handle *xs_handle  = NULL;
+
+void cleanup(void)
+{
+    if (virq_port > -1)
+        xc_evtchn_unbind(xce_handle, virq_port);
+    if (xce_handle)
+        xc_evtchn_close(xce_handle);
+    if (xch)
+        xc_interface_close(xch);
+    if (xs_handle)
+        xs_daemon_close(xs_handle);
+}
+
+/* Never shrink dom0 below 1 GiB */
+#define DOM0_FLOOR  (1 << 30)
+#define DOM0_FLOOR_PG   ((DOM0_FLOOR) >> 12)
+
+/* Act if free memory is less than 92 MiB */
+#define THRESHOLD   (92 << 20)
+#define THRESHOLD_PG    ((THRESHOLD) >> 12)
+
+#define BUFSZ 512
+void handle_low_mem(void)
+{
+    xc_dominfo_t  dom0_info;
+    xc_physinfo_t info;
+    unsigned long long free_pages, dom0_pages, diff, dom0_target;
+    char data[BUFSZ], error[BUFSZ];
+
+    if (xc_physinfo(xch, &info) < 0)
+    {
+        perror("Getting physinfo failed");
+        return;
+    }
+
+    free_pages = (unsigned long long) info.free_pages;
+    printf("Available free pages: 0x%llx:%llux\n",
+            free_pages, free_pages);
+
+    /* Don't do anything if we have more than the threshold free */
+    if ( free_pages >= THRESHOLD_PG )
+        return;
+    diff = THRESHOLD_PG - free_pages; 
+
+    if (xc_domain_getinfo(xch, 0, 1, &dom0_info) < 1)
+    {
+        perror("Failed to get dom0 info");
+        return;
+    }
+
+    dom0_pages = (unsigned long long) dom0_info.nr_pages;
+    printf("Dom0 pages: 0x%llx:%llu\n", dom0_pages, dom0_pages);
+    dom0_target = dom0_pages - diff;
+    if (dom0_target <= DOM0_FLOOR_PG)
+        return;
+
+    printf("Shooting for dom0 target 0x%llx:%llu\n", 
+            dom0_target, dom0_target);
+
+    snprintf(data, BUFSZ, "%llu", dom0_target);
+    if (!xs_write(xs_handle, XBT_NULL, 
+            "/local/domain/0/memory/target", data, strlen(data)))
+    {
+        snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data);
+        perror(error);
+    }
+}
+
+int main(int argc, char *argv[])
+{
+    int rc;
+
+    atexit(cleanup);
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (xch == NULL)
+    {
+        perror("Failed to open xc interface");
+        return 1;
+    }
+
+	xce_handle = xc_evtchn_open(NULL, 0);
+	if (xce_handle == NULL)
+    {
+        perror("Failed to open evtchn device");
+        return 2;
+    }
+
+    xs_handle = xs_daemon_open();
+    if (xs_handle == NULL)
+    {
+        perror("Failed to open xenstore connection");
+        return 3;
+    }
+
+	if ((rc = xc_evtchn_bind_virq(xce_handle, VIRQ_ENOMEM)) == -1)
+    {
+        perror("Failed to bind to domain exception virq port");
+        return 4;
+    }
+
+    virq_port = rc;
+    
+    while(1)
+    {
+        evtchn_port_t port;
+
+        if ((port = xc_evtchn_pending(xce_handle)) == -1)
+        {
+            perror("Failed to listen for pending event channel");
+            return 5;
+        }
+
+        if (port != virq_port)
+        {
+            char data[BUFSZ];
+            snprintf(data, BUFSZ, "Wrong port, got %d expected %d", port, virq_port);
+            perror(data);
+            return 6;
+        }
+
+        if (xc_evtchn_unmask(xce_handle, port) == -1)
+        {
+            perror("Failed to unmask port");
+            return 7;
+        }
+
+        printf("Got a virq kick, time to get work\n");
+        handle_low_mem();
+    }
+
+    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 Feb 28 21:56:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 21: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 1S2V1B-0004rY-0q; Tue, 28 Feb 2012 21:55:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2V19-0004rT-I1
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 21:55:31 +0000
Received: from [85.158.139.83:7840] by server-2.bemta-5.messagelabs.com id
	B5/F0-20263-25D4D4F4; Tue, 28 Feb 2012 21:55:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330466129!9783757!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ4NDM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20483 invoked from network); 28 Feb 2012 21:55:30 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-182.messagelabs.com with SMTP;
	28 Feb 2012 21:55:30 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 44263714088;
	Tue, 28 Feb 2012 13:55:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=tdKc/4qcqy1LF6djidzC/2aOB20xb8QFs+IFa3TZXXa0
	6UqnCSYOT/NUuv5co2DtcJkttI+y11ie+m2ttD3bXY0tEzV8dSdSSXyxSHjVKR3l
	j2ciKAq8HpOfvHbUziLpbvsDV495nxBVCRCdAINKtzPDUwnkGVZIS3ZIsSdenJQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=0BLsiMH2TlyA3GMD33+mxXWtjiE=; b=oHZ2Hc0Z8OP
	VdZJClp1+eEwoAqF2Z/997hsGD8unZZvUI2JImnXxILWb7eRCogrF/Hzf7YjcIR6
	r1CAgBEi+IMcYVhlpeFsZtwGGVw34f/nhZHYQtV2qjSkkFFBLzYBwYrr97/RprmX
	7Us8L5mNinCe60G82rAYMLdi+IS4EE0k=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 36FFE714086; 
	Tue, 28 Feb 2012 13:55:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4300b0d765753dc359bb206f4fdeb3cf302fa56f
Message-Id: <4300b0d765753dc359bb.1330466177@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1330466175@xdev.gridcentric.ca>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 28 Feb 2012 16:56:17 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Lowmemd: Simple demo code to show use of
	VIRQ_ENOMEM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/misc/Makefile  |    7 +-
 tools/misc/lowmemd.c |  148 +++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 153 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c44e9fe0ecca -r 4300b0d76575 tools/misc/Makefile
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 HDRS     = $(wildcard *.h)
 
 TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
-TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash
+TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
 
@@ -21,7 +21,7 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -70,6 +70,9 @@ xen-hptool: xen-hptool.o
 xenwatchdogd: xenwatchdogd.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+lowmemd: lowmemd.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
+
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
diff -r c44e9fe0ecca -r 4300b0d76575 tools/misc/lowmemd.c
--- /dev/null
+++ b/tools/misc/lowmemd.c
@@ -0,0 +1,148 @@
+/*
+ * lowmemd: demo VIRQ_ENOMEM
+ * Andres Lagar-Cavilla (GridCentric Inc.)
+ */
+
+#include <stdio.h>
+#include <xenctrl.h>
+#include <xs.h>
+#include <stdlib.h>
+#include <string.h>
+
+static evtchn_port_t virq_port      = -1;
+static xc_evtchn *xce_handle        = NULL;
+static xc_interface *xch            = NULL;
+static struct xs_handle *xs_handle  = NULL;
+
+void cleanup(void)
+{
+    if (virq_port > -1)
+        xc_evtchn_unbind(xce_handle, virq_port);
+    if (xce_handle)
+        xc_evtchn_close(xce_handle);
+    if (xch)
+        xc_interface_close(xch);
+    if (xs_handle)
+        xs_daemon_close(xs_handle);
+}
+
+/* Never shrink dom0 below 1 GiB */
+#define DOM0_FLOOR  (1 << 30)
+#define DOM0_FLOOR_PG   ((DOM0_FLOOR) >> 12)
+
+/* Act if free memory is less than 92 MiB */
+#define THRESHOLD   (92 << 20)
+#define THRESHOLD_PG    ((THRESHOLD) >> 12)
+
+#define BUFSZ 512
+void handle_low_mem(void)
+{
+    xc_dominfo_t  dom0_info;
+    xc_physinfo_t info;
+    unsigned long long free_pages, dom0_pages, diff, dom0_target;
+    char data[BUFSZ], error[BUFSZ];
+
+    if (xc_physinfo(xch, &info) < 0)
+    {
+        perror("Getting physinfo failed");
+        return;
+    }
+
+    free_pages = (unsigned long long) info.free_pages;
+    printf("Available free pages: 0x%llx:%llux\n",
+            free_pages, free_pages);
+
+    /* Don't do anything if we have more than the threshold free */
+    if ( free_pages >= THRESHOLD_PG )
+        return;
+    diff = THRESHOLD_PG - free_pages; 
+
+    if (xc_domain_getinfo(xch, 0, 1, &dom0_info) < 1)
+    {
+        perror("Failed to get dom0 info");
+        return;
+    }
+
+    dom0_pages = (unsigned long long) dom0_info.nr_pages;
+    printf("Dom0 pages: 0x%llx:%llu\n", dom0_pages, dom0_pages);
+    dom0_target = dom0_pages - diff;
+    if (dom0_target <= DOM0_FLOOR_PG)
+        return;
+
+    printf("Shooting for dom0 target 0x%llx:%llu\n", 
+            dom0_target, dom0_target);
+
+    snprintf(data, BUFSZ, "%llu", dom0_target);
+    if (!xs_write(xs_handle, XBT_NULL, 
+            "/local/domain/0/memory/target", data, strlen(data)))
+    {
+        snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data);
+        perror(error);
+    }
+}
+
+int main(int argc, char *argv[])
+{
+    int rc;
+
+    atexit(cleanup);
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (xch == NULL)
+    {
+        perror("Failed to open xc interface");
+        return 1;
+    }
+
+	xce_handle = xc_evtchn_open(NULL, 0);
+	if (xce_handle == NULL)
+    {
+        perror("Failed to open evtchn device");
+        return 2;
+    }
+
+    xs_handle = xs_daemon_open();
+    if (xs_handle == NULL)
+    {
+        perror("Failed to open xenstore connection");
+        return 3;
+    }
+
+	if ((rc = xc_evtchn_bind_virq(xce_handle, VIRQ_ENOMEM)) == -1)
+    {
+        perror("Failed to bind to domain exception virq port");
+        return 4;
+    }
+
+    virq_port = rc;
+    
+    while(1)
+    {
+        evtchn_port_t port;
+
+        if ((port = xc_evtchn_pending(xce_handle)) == -1)
+        {
+            perror("Failed to listen for pending event channel");
+            return 5;
+        }
+
+        if (port != virq_port)
+        {
+            char data[BUFSZ];
+            snprintf(data, BUFSZ, "Wrong port, got %d expected %d", port, virq_port);
+            perror(data);
+            return 6;
+        }
+
+        if (xc_evtchn_unmask(xce_handle, port) == -1)
+        {
+            perror("Failed to unmask port");
+            return 7;
+        }
+
+        printf("Got a virq kick, time to get work\n");
+        handle_low_mem();
+    }
+
+    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 Feb 28 22:09:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 22: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 1S2VEG-0005KN-3O; Tue, 28 Feb 2012 22:09:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2VEE-0005KI-5r
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 22:09:02 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330466884!62574756!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28510 invoked from network); 28 Feb 2012 22:08:05 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.15)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Feb 2012 22:08:05 -0000
Received: from mail22-tx2-R.bigfish.com (10.9.14.244) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 22:08:56 +0000
Received: from mail22-tx2 (localhost [127.0.0.1])	by mail22-tx2-R.bigfish.com
	(Postfix) with ESMTP id 2CC1F30036B	for
	<xen-devel@lists.xensource.com>; Tue,
	28 Feb 2012 22:08:56 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail22-tx2 (localhost.localdomain [127.0.0.1]) by mail22-tx2
	(MessageSwitch) id 1330466934396455_10650;
	Tue, 28 Feb 2012 22:08:54 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.244])	by
	mail22-tx2.bigfish.com (Postfix) with ESMTP id 526E6420047	for
	<xen-devel@lists.xensource.com>; Tue, 28 Feb 2012 22:08:54 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 22:08:50 +0000
X-WSS-ID: 0M04IUN-01-2KF-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 29B3210281D0	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 16:08:47 -0600 (CST)
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, 28 Feb 2012 16:08:57 -0600
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;
	Tue, 28 Feb 2012 16:08:48 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012
	17:08:43 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1ACD649C65B; Tue, 28 Feb 2012
	22:08:43 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 09AEF2D202B; Tue,
	28 Feb 2012 23:08:43 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9e5991ad9c85b5176ce269001e7957e8805dd93c
Message-ID: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Tue, 28 Feb 2012 23:08:30 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com
Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1330466573 -3600
# Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
# Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
x86: Use deep C states for off-lined CPUs

Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT
is used). This patch allows a core to go to deeper C states resulting in significantly
higher power savings.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
@@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
     if ( (cx = &power->states[power->count-1]) == NULL )
         goto default_halt;
 
-    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
-
     if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
     {
+        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
+
         /*
          * Cache must be flushed as the last operation before sleeping.
          * Otherwise, CPU may still hold dirty data, breaking cache coherency,
@@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
             mb();
             __mwait(cx->address, 0);
         }
+    } 
+    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
+    {
+        /* Avoid references to shared data after the cache flush */
+        u32 address = cx->address;
+        u32 pmtmr_ioport_local = pmtmr_ioport;
+
+        wbinvd();	
+
+        while ( 1 )
+        {
+            inb(address);
+            inl(pmtmr_ioport_local);
+        }
     }
 
 default_halt:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 22:09:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 22: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 1S2VEG-0005KN-3O; Tue, 28 Feb 2012 22:09:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2VEE-0005KI-5r
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 22:09:02 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330466884!62574756!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28510 invoked from network); 28 Feb 2012 22:08:05 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.15)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Feb 2012 22:08:05 -0000
Received: from mail22-tx2-R.bigfish.com (10.9.14.244) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 22:08:56 +0000
Received: from mail22-tx2 (localhost [127.0.0.1])	by mail22-tx2-R.bigfish.com
	(Postfix) with ESMTP id 2CC1F30036B	for
	<xen-devel@lists.xensource.com>; Tue,
	28 Feb 2012 22:08:56 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail22-tx2 (localhost.localdomain [127.0.0.1]) by mail22-tx2
	(MessageSwitch) id 1330466934396455_10650;
	Tue, 28 Feb 2012 22:08:54 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.244])	by
	mail22-tx2.bigfish.com (Postfix) with ESMTP id 526E6420047	for
	<xen-devel@lists.xensource.com>; Tue, 28 Feb 2012 22:08:54 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server id
	14.1.225.23; Tue, 28 Feb 2012 22:08:50 +0000
X-WSS-ID: 0M04IUN-01-2KF-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 29B3210281D0	for <xen-devel@lists.xensource.com>;
	Tue, 28 Feb 2012 16:08:47 -0600 (CST)
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, 28 Feb 2012 16:08:57 -0600
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;
	Tue, 28 Feb 2012 16:08:48 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012
	17:08:43 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1ACD649C65B; Tue, 28 Feb 2012
	22:08:43 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 09AEF2D202B; Tue,
	28 Feb 2012 23:08:43 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9e5991ad9c85b5176ce269001e7957e8805dd93c
Message-ID: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Tue, 28 Feb 2012 23:08:30 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com
Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1330466573 -3600
# Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
# Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
x86: Use deep C states for off-lined CPUs

Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT
is used). This patch allows a core to go to deeper C states resulting in significantly
higher power savings.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
@@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
     if ( (cx = &power->states[power->count-1]) == NULL )
         goto default_halt;
 
-    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
-
     if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
     {
+        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
+
         /*
          * Cache must be flushed as the last operation before sleeping.
          * Otherwise, CPU may still hold dirty data, breaking cache coherency,
@@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
             mb();
             __mwait(cx->address, 0);
         }
+    } 
+    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
+    {
+        /* Avoid references to shared data after the cache flush */
+        u32 address = cx->address;
+        u32 pmtmr_ioport_local = pmtmr_ioport;
+
+        wbinvd();	
+
+        while ( 1 )
+        {
+            inb(address);
+            inl(pmtmr_ioport_local);
+        }
     }
 
 default_halt:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 22:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 22: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 1S2Vb1-0005im-DW; Tue, 28 Feb 2012 22:32:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2Vb0-0005ih-8A
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 22:32:34 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330468347!3525085!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18812 invoked from network); 28 Feb 2012 22:32:28 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 22:32:28 -0000
Received: by ggnj2 with SMTP id j2so1452697ggn.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 14:32:26 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.50.153.166 as permitted sender) client-ip=10.50.153.166; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.50.153.166 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.50.153.166])
	by 10.50.153.166 with SMTP id vh6mr4647405igb.44.1330468346395
	(num_hops = 1); Tue, 28 Feb 2012 14:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=RbyHH9c0d2M1Bwva8F3rwfo9s3YjBl8+305auAr7ifk=;
	b=iMemF19nCcyOFrR1qJbSogVRzZu8UGtrM+nAss6d1qyxxQmJ8ZudWHMz1drgXFFm+x
	Rmt0ek6pXGEHHib+/+F95y9TQPkBw2OKfubs/16zcGTzJcfgwYAsDO2ReVTqO+jYRBDK
	boiHE5be4hFrmxRdYIatArZxapdrh61rteF30=
Received: by 10.50.153.166 with SMTP id vh6mr3849633igb.44.1330468346342; Tue,
	28 Feb 2012 14:32:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.190.74 with HTTP; Tue, 28 Feb 2012 14:32:06 -0800 (PST)
In-Reply-To: <CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
	<CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
	<CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 14:32:06 -0800
Message-ID: <CAFw--Dc9d2dHFJrST6ixCKc1sdjscNuDGJ48=vDw9bE-_Xod3A@mail.gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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

> This should fix it (I haven't tested):
>

That was what I did as well. Seems to work fine for me. Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 22:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 22: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 1S2Vb1-0005im-DW; Tue, 28 Feb 2012 22:32:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2Vb0-0005ih-8A
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 22:32:34 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1330468347!3525085!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18812 invoked from network); 28 Feb 2012 22:32:28 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 22:32:28 -0000
Received: by ggnj2 with SMTP id j2so1452697ggn.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 14:32:26 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.50.153.166 as permitted sender) client-ip=10.50.153.166; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.50.153.166 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.50.153.166])
	by 10.50.153.166 with SMTP id vh6mr4647405igb.44.1330468346395
	(num_hops = 1); Tue, 28 Feb 2012 14:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=RbyHH9c0d2M1Bwva8F3rwfo9s3YjBl8+305auAr7ifk=;
	b=iMemF19nCcyOFrR1qJbSogVRzZu8UGtrM+nAss6d1qyxxQmJ8ZudWHMz1drgXFFm+x
	Rmt0ek6pXGEHHib+/+F95y9TQPkBw2OKfubs/16zcGTzJcfgwYAsDO2ReVTqO+jYRBDK
	boiHE5be4hFrmxRdYIatArZxapdrh61rteF30=
Received: by 10.50.153.166 with SMTP id vh6mr3849633igb.44.1330468346342; Tue,
	28 Feb 2012 14:32:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.190.74 with HTTP; Tue, 28 Feb 2012 14:32:06 -0800 (PST)
In-Reply-To: <CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
	<CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
	<CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 28 Feb 2012 14:32:06 -0800
Message-ID: <CAFw--Dc9d2dHFJrST6ixCKc1sdjscNuDGJ48=vDw9bE-_Xod3A@mail.gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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

> This should fix it (I haven't tested):
>

That was what I did as well. Seems to work fine for me. Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 22:48:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 22:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2VqQ-0005x1-TG; Tue, 28 Feb 2012 22:48:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2VqP-0005ww-Qg
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 22:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330469303!16283202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18489 invoked from network); 28 Feb 2012 22:48:23 -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;
	28 Feb 2012 22:48:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,498,1325462400"; d="scan'208";a="10996684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 22:48:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 22:48:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2VqJ-000494-9X;
	Tue, 28 Feb 2012 22:48:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2VqJ-0006P2-6v;
	Tue, 28 Feb 2012 22:48:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12106-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 22:48:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12106: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12106 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12106/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 12104

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12104
 test-i386-i386-win           14 guest-start.2                fail   like 12104

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-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
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  a43eeaedf61c
baseline version:
 xen                  a7bacdc5449a

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Liu, Jinsong <jinsong.liu@intel.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24895:a43eeaedf61c
tag:         tip
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: Handle booting on SMP platforms
    
    Make all non-boot CPUs wait forever instead of trying to boot in parallel.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24894:d19a254197d7
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: strip xen binary
    
    The symbols in it are wrong anyway and will only confuse people
    who ought to be looking at xen-syms.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24893:72551f578776
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Tue Feb 28 09:06:27 2012 +0100
    
    X86: expose HLE/RTM features to dom0
    
    Intel recently release 2 new features, HLE and TRM.
    Refer to http://software.intel.com/file/41417.
    This patch expose them to dom0.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24892:a7bacdc5449a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 27 17:05:18 2012 +0000
    
    Update SEABIOS_UPSTREAM_TAG
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 22:48:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 22:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2VqQ-0005x1-TG; Tue, 28 Feb 2012 22:48:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2VqP-0005ww-Qg
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 22:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330469303!16283202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTc0Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18489 invoked from network); 28 Feb 2012 22:48:23 -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;
	28 Feb 2012 22:48:23 -0000
X-IronPort-AV: E=Sophos;i="4.73,498,1325462400"; d="scan'208";a="10996684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2012 22:48:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 28 Feb 2012 22:48:23 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2VqJ-000494-9X;
	Tue, 28 Feb 2012 22:48:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2VqJ-0006P2-6v;
	Tue, 28 Feb 2012 22:48:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12106-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 28 Feb 2012 22:48:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12106: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12106 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12106/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 12104

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail like 12104
 test-i386-i386-win           14 guest-start.2                fail   like 12104

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-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
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  a43eeaedf61c
baseline version:
 xen                  a7bacdc5449a

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <Ian.Campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Liu, Jinsong <jinsong.liu@intel.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24895:a43eeaedf61c
tag:         tip
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: Handle booting on SMP platforms
    
    Make all non-boot CPUs wait forever instead of trying to boot in parallel.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24894:d19a254197d7
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: strip xen binary
    
    The symbols in it are wrong anyway and will only confuse people
    who ought to be looking at xen-syms.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24893:72551f578776
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Tue Feb 28 09:06:27 2012 +0100
    
    X86: expose HLE/RTM features to dom0
    
    Intel recently release 2 new features, HLE and TRM.
    Refer to http://software.intel.com/file/41417.
    This patch expose them to dom0.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24892:a7bacdc5449a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 27 17:05:18 2012 +0000
    
    Update SEABIOS_UPSTREAM_TAG
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSS-0006Gb-77; Tue, 28 Feb 2012 23:27:48 +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 1S2WSQ-0006Fa-Bc
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330471604!54758872!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6235 invoked from network); 28 Feb 2012 23:26:45 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:45 -0000
X-TM-IMSS-Message-ID: <145c918000005518@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 145c918000005518 ;
	Tue, 28 Feb 2012 18:30:01 -0500
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 q1SNRcOO003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:13 -0500
Message-Id: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 1/5] build: Export configure variables to
	hypervisor 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

Since the introduction of autoconf, builds with XSM enabled in .config
have been broken unless FLASK_ENABLE was explicitly set. Since the
setting in .config has apparently been deprecated in favor of an
autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
also makes --disable-debug and some paths to be pulled from the
configure process in the hypervisor build.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 .gitignore         |    1 +
 .hgignore          |    1 +
 config/Tools.mk.in |    4 ----
 config/Xen.mk.in   |   19 +++++++++++++++++++
 tools/configure.ac |    1 +
 xen/Rules.mk       |    1 +
 6 files changed, 23 insertions(+), 4 deletions(-)
 create mode 100644 config/Xen.mk.in

diff --git a/.gitignore b/.gitignore
index 8810b35..865505f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -111,6 +111,7 @@ tools/config.log
 tools/config.status
 tools/config.cache
 config/Tools.mk
+config/Xen.mk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/.hgignore b/.hgignore
index 46655ad..7d5ccc1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -309,6 +309,7 @@
 ^tools/config\.status$
 ^tools/config\.cache$
 ^config/Tools\.mk$
+^config/Xen\.mk$
 ^xen/\.banner.*$
 ^xen/BLOG$
 ^xen/System.map$
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 06d5e89..315ced4 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE          := @xsm@
-FLASK_ENABLE        := @xsm@
-
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/config/Xen.mk.in b/config/Xen.mk.in
new file mode 100644
index 0000000..e152f39
--- /dev/null
+++ b/config/Xen.mk.in
@@ -0,0 +1,19 @@
+# Prefix and install folder
+PREFIX              := @prefix@
+LIBLEAFDIR_x86_64   := @LIB_PATH@
+
+# A debug build of xen?
+debug               := @debug@
+
+# Tools path
+PYTHON              := @PYTHON@
+
+# Extra folder for libs/includes
+PREPEND_INCLUDES    := @PREPEND_INCLUDES@
+PREPEND_LIB         := @PREPEND_LIB@
+APPEND_INCLUDES     := @APPEND_INCLUDES@
+APPEND_LIB          := @APPEND_LIB@
+
+# Enable XSM security module (by default, Flask).
+XSM_ENABLE          := @xsm@
+FLASK_ENABLE        := @xsm@
diff --git a/tools/configure.ac b/tools/configure.ac
index c5dec9c..5b2815d 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -6,6 +6,7 @@ AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
     [xen-devel@lists.xensource.com])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
+AC_CONFIG_FILES([../config/Xen.mk])
 AC_CONFIG_HEADERS([config.h])
 AC_PREFIX_DEFAULT([/usr])
 AC_CONFIG_AUX_DIR([.])
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 6123835..6c17a3f 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -12,6 +12,7 @@ frame_pointer ?= n
 lto           ?= n
 
 include $(XEN_ROOT)/Config.mk
+include $(XEN_ROOT)/config/Xen.mk
 
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSS-0006Gb-77; Tue, 28 Feb 2012 23:27:48 +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 1S2WSQ-0006Fa-Bc
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330471604!54758872!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6235 invoked from network); 28 Feb 2012 23:26:45 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:45 -0000
X-TM-IMSS-Message-ID: <145c918000005518@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 145c918000005518 ;
	Tue, 28 Feb 2012 18:30:01 -0500
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 q1SNRcOO003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:13 -0500
Message-Id: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 1/5] build: Export configure variables to
	hypervisor 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

Since the introduction of autoconf, builds with XSM enabled in .config
have been broken unless FLASK_ENABLE was explicitly set. Since the
setting in .config has apparently been deprecated in favor of an
autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
also makes --disable-debug and some paths to be pulled from the
configure process in the hypervisor build.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 .gitignore         |    1 +
 .hgignore          |    1 +
 config/Tools.mk.in |    4 ----
 config/Xen.mk.in   |   19 +++++++++++++++++++
 tools/configure.ac |    1 +
 xen/Rules.mk       |    1 +
 6 files changed, 23 insertions(+), 4 deletions(-)
 create mode 100644 config/Xen.mk.in

diff --git a/.gitignore b/.gitignore
index 8810b35..865505f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -111,6 +111,7 @@ tools/config.log
 tools/config.status
 tools/config.cache
 config/Tools.mk
+config/Xen.mk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/.hgignore b/.hgignore
index 46655ad..7d5ccc1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -309,6 +309,7 @@
 ^tools/config\.status$
 ^tools/config\.cache$
 ^config/Tools\.mk$
+^config/Xen\.mk$
 ^xen/\.banner.*$
 ^xen/BLOG$
 ^xen/System.map$
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 06d5e89..315ced4 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE          := @xsm@
-FLASK_ENABLE        := @xsm@
-
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/config/Xen.mk.in b/config/Xen.mk.in
new file mode 100644
index 0000000..e152f39
--- /dev/null
+++ b/config/Xen.mk.in
@@ -0,0 +1,19 @@
+# Prefix and install folder
+PREFIX              := @prefix@
+LIBLEAFDIR_x86_64   := @LIB_PATH@
+
+# A debug build of xen?
+debug               := @debug@
+
+# Tools path
+PYTHON              := @PYTHON@
+
+# Extra folder for libs/includes
+PREPEND_INCLUDES    := @PREPEND_INCLUDES@
+PREPEND_LIB         := @PREPEND_LIB@
+APPEND_INCLUDES     := @APPEND_INCLUDES@
+APPEND_LIB          := @APPEND_LIB@
+
+# Enable XSM security module (by default, Flask).
+XSM_ENABLE          := @xsm@
+FLASK_ENABLE        := @xsm@
diff --git a/tools/configure.ac b/tools/configure.ac
index c5dec9c..5b2815d 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -6,6 +6,7 @@ AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
     [xen-devel@lists.xensource.com])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
+AC_CONFIG_FILES([../config/Xen.mk])
 AC_CONFIG_HEADERS([config.h])
 AC_PREFIX_DEFAULT([/usr])
 AC_CONFIG_AUX_DIR([.])
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 6123835..6c17a3f 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -12,6 +12,7 @@ frame_pointer ?= n
 lto           ?= n
 
 include $(XEN_ROOT)/Config.mk
+include $(XEN_ROOT)/config/Xen.mk
 
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSN-0006Fn-38; Tue, 28 Feb 2012 23:27:43 +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 1S2WSL-0006Fc-Ez
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330471575!62131161!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31686 invoked from network); 28 Feb 2012 23:26:15 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:15 -0000
X-TM-IMSS-Message-ID: <145c92d700005519@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 145c92d700005519 ;
	Tue, 28 Feb 2012 18:30:02 -0500
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 q1SNRcOQ003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:15 -0500
Message-Id: <1330471637-8104-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 3/5] xsm/flask: clean interdomain event channel
	hook
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't attempt to relabel the already-bound half of the event channel
pair created by an interdomain event channel. This relabeling also
performed an incorrect check that the destination domain is permitted to
create the reverse event channel, which may not be true if the unbound
channel was created by the domain builder (like the xenstore channel).

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   30 ++++++++----------------------
 1 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 649c473..9948fca 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -182,12 +182,12 @@ static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn,
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid1;
-    u32 newsid2;
+    u32 newsid;
     int rc;
-    struct domain_security_struct *dsec1, *dsec2;
+    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec1, *esec2;
 
+    dsec = current->domain->ssid;
     dsec1 = d1->ssid;
     dsec2 = d2->ssid;
 
@@ -195,7 +195,7 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
     esec2 = chn2->ssid;
 
     rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid1);
+                                 SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -203,33 +203,19 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec1->sid, newsid1, SECCLASS_EVENT, EVENT__CREATE, NULL);
-    if ( rc )
-        return rc;
-
-    rc = security_transition_sid(dsec2->sid, dsec1->sid, 
-                                 SECCLASS_EVENT, &newsid2);
+    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
-    {
-        printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
-               __FUNCTION__, -rc, d1->domain_id);
         return rc;
-    }
 
-    rc = avc_has_perm(dsec2->sid, newsid2, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid1, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid2, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
-    if ( rc )
-        return rc;    
-
-    esec1->sid = newsid1;
-    esec2->sid = newsid2;
+    esec1->sid = newsid;
 
     return rc;
 }
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSN-0006Fn-38; Tue, 28 Feb 2012 23:27:43 +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 1S2WSL-0006Fc-Ez
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330471575!62131161!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31686 invoked from network); 28 Feb 2012 23:26:15 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:15 -0000
X-TM-IMSS-Message-ID: <145c92d700005519@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 145c92d700005519 ;
	Tue, 28 Feb 2012 18:30:02 -0500
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 q1SNRcOQ003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:15 -0500
Message-Id: <1330471637-8104-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 3/5] xsm/flask: clean interdomain event channel
	hook
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't attempt to relabel the already-bound half of the event channel
pair created by an interdomain event channel. This relabeling also
performed an incorrect check that the destination domain is permitted to
create the reverse event channel, which may not be true if the unbound
channel was created by the domain builder (like the xenstore channel).

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   30 ++++++++----------------------
 1 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 649c473..9948fca 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -182,12 +182,12 @@ static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn,
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid1;
-    u32 newsid2;
+    u32 newsid;
     int rc;
-    struct domain_security_struct *dsec1, *dsec2;
+    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec1, *esec2;
 
+    dsec = current->domain->ssid;
     dsec1 = d1->ssid;
     dsec2 = d2->ssid;
 
@@ -195,7 +195,7 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
     esec2 = chn2->ssid;
 
     rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid1);
+                                 SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -203,33 +203,19 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec1->sid, newsid1, SECCLASS_EVENT, EVENT__CREATE, NULL);
-    if ( rc )
-        return rc;
-
-    rc = security_transition_sid(dsec2->sid, dsec1->sid, 
-                                 SECCLASS_EVENT, &newsid2);
+    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
-    {
-        printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
-               __FUNCTION__, -rc, d1->domain_id);
         return rc;
-    }
 
-    rc = avc_has_perm(dsec2->sid, newsid2, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid1, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid2, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
-    if ( rc )
-        return rc;    
-
-    esec1->sid = newsid1;
-    esec2->sid = newsid2;
+    esec1->sid = newsid;
 
     return rc;
 }
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSR-0006GT-QI; Tue, 28 Feb 2012 23:27:47 +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 1S2WSQ-0006Fb-94
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330471604!51221649!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27689 invoked from network); 28 Feb 2012 23:26:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:44 -0000
X-TM-IMSS-Message-ID: <1489587700006403@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 1489587700006403 ;
	Tue, 28 Feb 2012 18:39:36 -0500
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 q1SNRcOP003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:14 -0500
Message-Id: <1330471637-8104-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 2/5] xsm: label xen-consumer event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Event channels created during the domain build process for HVM domains
did not call the XSM creation hook. Since these channels are used
internally by Xen, redirect them to DOMAIN_INVAID instead of failing to
create if the XSM hook fails the permissions check.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 989ebae..ce309da 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1106,6 +1106,7 @@ int alloc_unbound_xen_event_channel(
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
     int            port;
+    int            rc;
 
     spin_lock(&d->event_lock);
 
@@ -1113,10 +1114,15 @@ int alloc_unbound_xen_event_channel(
         goto out;
     chn = evtchn_from_port(d, port);
 
+    rc = xsm_evtchn_unbound(d, chn, remote_domid);
+
     chn->state = ECS_UNBOUND;
     chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
-    chn->u.unbound.remote_domid = remote_domid;
+    if ( rc )
+        chn->u.unbound.remote_domid = DOMID_INVALID;
+    else
+        chn->u.unbound.remote_domid = remote_domid;
 
  out:
     spin_unlock(&d->event_lock);
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSN-0006Fu-OH; Tue, 28 Feb 2012 23:27:43 +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 1S2WSM-0006Fi-9r
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330471600!53768898!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30462 invoked from network); 28 Feb 2012 23:26:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:41 -0000
X-TM-IMSS-Message-ID: <145c94da0000551b@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 145c94da0000551b ;
	Tue, 28 Feb 2012 18:30:02 -0500
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 q1SNRcOR003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:16 -0500
Message-Id: <1330471637-8104-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 4/5] xsm/flask: buffer AVC messages for output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When multiple CPUs hit an AVC audit message, the resulting output in the
ring buffer and serial console is garbled due to the audit process using
many separate printk invocations for each message. Change the AVC audit
process to use a temporary buffer and output the contents once the
entire audit message is complete.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c |  107 +++++++++++++++++++++++++++++++++++++++------------
 1 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 74f160d..b5486a3 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -132,12 +132,54 @@ static inline int avc_hash(u32 ssid, u32 tsid, u16 tclass)
     return (ssid ^ (tsid<<2) ^ (tclass<<4)) & (AVC_CACHE_SLOTS - 1);
 }
 
+/* no use making this larger than the printk buffer */
+#define AVC_BUF_SIZE 1024
+static DEFINE_SPINLOCK(avc_emerg_lock);
+static char avc_emerg_buf[AVC_BUF_SIZE];
+
+struct avc_dump_buf {
+    char *start;
+    char *pos;
+    u32 free;
+};
+
+static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
+{
+    int i;
+    va_list args;
+
+ again:
+    va_start(args, fmt);
+    i = vsnprintf(buf->pos, buf->free, fmt, args);
+    va_end(args);
+    if ( i < buf->free )
+    {
+        buf->pos += i;
+        buf->free -= i;
+    }
+    else if ( buf->free < AVC_BUF_SIZE )
+    {
+        buf->pos[0] = 0;
+        printk("%s", buf->start);
+        buf->pos = buf->start;
+        buf->free = AVC_BUF_SIZE;
+        goto again;
+    }
+    else
+    {
+        printk("%s", buf->start);
+        printk("\navc_printk: overflow\n");
+        buf->pos = buf->start;
+        buf->free = AVC_BUF_SIZE;
+    }
+}
+
 /**
  * avc_dump_av - Display an access vector in human-readable form.
  * @tclass: target security class
  * @av: access vector
  */
-static void avc_dump_av(u16 tclass, u32 av)
+static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
     const char **common_pts = NULL;
     u32 common_base = 0;
@@ -145,7 +187,7 @@ static void avc_dump_av(u16 tclass, u32 av)
 
     if ( av == 0 )
     {
-        printk(" null");
+        avc_printk(buf, " null");
         return;
     }
 
@@ -159,14 +201,14 @@ static void avc_dump_av(u16 tclass, u32 av)
         }
     }
 
-    printk(" {");
+    avc_printk(buf, " {");
     i = 0;
     perm = 1;
     while ( perm < common_base )
     {
         if (perm & av)
         {
-            printk(" %s", common_pts[i]);
+            avc_printk(buf, " %s", common_pts[i]);
             av &= ~perm;
         }
         i++;
@@ -185,7 +227,7 @@ static void avc_dump_av(u16 tclass, u32 av)
             }
             if ( i2 < ARRAY_SIZE(av_perm_to_string) )
             {
-                printk(" %s", av_perm_to_string[i2].name);
+                avc_printk(buf, " %s", av_perm_to_string[i2].name);
                 av &= ~perm;
             }
         }
@@ -194,9 +236,9 @@ static void avc_dump_av(u16 tclass, u32 av)
     }
 
     if ( av )
-        printk(" 0x%x", av);
+        avc_printk(buf, " 0x%x", av);
 
-    printk(" }");
+    avc_printk(buf, " }");
 }
 
 /**
@@ -205,7 +247,7 @@ static void avc_dump_av(u16 tclass, u32 av)
  * @tsid: target security identifier
  * @tclass: target security class
  */
-static void avc_dump_query(u32 ssid, u32 tsid, u16 tclass)
+static void avc_dump_query(struct avc_dump_buf *buf, u32 ssid, u32 tsid, u16 tclass)
 {
     int rc;
     char *scontext;
@@ -213,23 +255,23 @@ static void avc_dump_query(u32 ssid, u32 tsid, u16 tclass)
 
     rc = security_sid_to_context(ssid, &scontext, &scontext_len);
     if ( rc )
-        printk("ssid=%d", ssid);
+        avc_printk(buf, "ssid=%d", ssid);
     else
     {
-        printk("scontext=%s", scontext);
+        avc_printk(buf, "scontext=%s", scontext);
         xfree(scontext);
     }
 
     rc = security_sid_to_context(tsid, &scontext, &scontext_len);
     if ( rc )
-        printk(" tsid=%d", tsid);
+        avc_printk(buf, " tsid=%d", tsid);
     else
     {
-        printk(" tcontext=%s", scontext);
+        avc_printk(buf, " tcontext=%s", scontext);
         xfree(scontext);
     }
 
-    printk(" tclass=%s", class_to_string[tclass]);
+    avc_printk(buf, " tclass=%s", class_to_string[tclass]);
 }
 
 /**
@@ -544,6 +586,7 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
 {
     struct domain *cdom = current->domain;
     u32 denied, audited;
+    struct avc_dump_buf buf;
 
     denied = requested & ~avd->allowed;
     if ( denied )
@@ -562,36 +605,50 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
         if ( !(audited & avd->auditallow) )
             return;
     }
+    buf.start = xmalloc_bytes(AVC_BUF_SIZE);
+    if ( !buf.start )
+    {
+        spin_lock(&avc_emerg_lock);
+        buf.start = avc_emerg_buf;
+    }
+    buf.pos = buf.start;
+    buf.free = AVC_BUF_SIZE;
 
-    printk("avc:  %s ", denied ? "denied" : "granted");
-    avc_dump_av(tclass, audited);
-    printk(" for ");
+    avc_printk(&buf, "avc:  %s ", denied ? "denied" : "granted");
+    avc_dump_av(&buf, tclass, audited);
+    avc_printk(&buf, " for ");
 
     if ( a && (a->sdom || a->tdom) )
     {
         if ( a->sdom && a->tdom && a->sdom != a->tdom )
-            printk("domid=%d target=%d ", a->sdom->domain_id, a->tdom->domain_id);
+            avc_printk(&buf, "domid=%d target=%d ", a->sdom->domain_id, a->tdom->domain_id);
         else if ( a->sdom )
-            printk("domid=%d ", a->sdom->domain_id);
+            avc_printk(&buf, "domid=%d ", a->sdom->domain_id);
         else
-            printk("target=%d ", a->tdom->domain_id);
+            avc_printk(&buf, "target=%d ", a->tdom->domain_id);
     }
     else if ( cdom )
-        printk("domid=%d ", cdom->domain_id);
+        avc_printk(&buf, "domid=%d ", cdom->domain_id);
     switch ( a ? a->type : 0 ) {
     case AVC_AUDIT_DATA_DEV:
-        printk("device=0x%lx ", a->device);
+        avc_printk(&buf, "device=0x%lx ", a->device);
         break;
     case AVC_AUDIT_DATA_IRQ:
-        printk("irq=%d ", a->irq);
+        avc_printk(&buf, "irq=%d ", a->irq);
         break;
     case AVC_AUDIT_DATA_RANGE:
-        printk("range=0x%lx-0x%lx ", a->range.start, a->range.end);
+        avc_printk(&buf, "range=0x%lx-0x%lx ", a->range.start, a->range.end);
         break;
     }
 
-    avc_dump_query(ssid, tsid, tclass);
-    printk("\n");
+    avc_dump_query(&buf, ssid, tsid, tclass);
+    avc_printk(&buf, "\n");
+    printk("%s", buf.start);
+
+    if ( buf.start == avc_emerg_buf )
+        spin_unlock(&avc_emerg_lock);
+    else
+        xfree(buf.start);
 }
 
 /**
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSR-0006GT-QI; Tue, 28 Feb 2012 23:27:47 +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 1S2WSQ-0006Fb-94
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330471604!51221649!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27689 invoked from network); 28 Feb 2012 23:26:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:44 -0000
X-TM-IMSS-Message-ID: <1489587700006403@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 1489587700006403 ;
	Tue, 28 Feb 2012 18:39:36 -0500
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 q1SNRcOP003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:14 -0500
Message-Id: <1330471637-8104-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 2/5] xsm: label xen-consumer event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Event channels created during the domain build process for HVM domains
did not call the XSM creation hook. Since these channels are used
internally by Xen, redirect them to DOMAIN_INVAID instead of failing to
create if the XSM hook fails the permissions check.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 989ebae..ce309da 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1106,6 +1106,7 @@ int alloc_unbound_xen_event_channel(
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
     int            port;
+    int            rc;
 
     spin_lock(&d->event_lock);
 
@@ -1113,10 +1114,15 @@ int alloc_unbound_xen_event_channel(
         goto out;
     chn = evtchn_from_port(d, port);
 
+    rc = xsm_evtchn_unbound(d, chn, remote_domid);
+
     chn->state = ECS_UNBOUND;
     chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
-    chn->u.unbound.remote_domid = remote_domid;
+    if ( rc )
+        chn->u.unbound.remote_domid = DOMID_INVALID;
+    else
+        chn->u.unbound.remote_domid = remote_domid;
 
  out:
     spin_unlock(&d->event_lock);
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSN-0006Fu-OH; Tue, 28 Feb 2012 23:27:43 +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 1S2WSM-0006Fi-9r
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330471600!53768898!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30462 invoked from network); 28 Feb 2012 23:26:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-27.messagelabs.com with SMTP;
	28 Feb 2012 23:26:41 -0000
X-TM-IMSS-Message-ID: <145c94da0000551b@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 145c94da0000551b ;
	Tue, 28 Feb 2012 18:30:02 -0500
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 q1SNRcOR003101; 
	Tue, 28 Feb 2012 18:27:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:16 -0500
Message-Id: <1330471637-8104-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 4/5] xsm/flask: buffer AVC messages for output
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When multiple CPUs hit an AVC audit message, the resulting output in the
ring buffer and serial console is garbled due to the audit process using
many separate printk invocations for each message. Change the AVC audit
process to use a temporary buffer and output the contents once the
entire audit message is complete.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c |  107 +++++++++++++++++++++++++++++++++++++++------------
 1 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 74f160d..b5486a3 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -132,12 +132,54 @@ static inline int avc_hash(u32 ssid, u32 tsid, u16 tclass)
     return (ssid ^ (tsid<<2) ^ (tclass<<4)) & (AVC_CACHE_SLOTS - 1);
 }
 
+/* no use making this larger than the printk buffer */
+#define AVC_BUF_SIZE 1024
+static DEFINE_SPINLOCK(avc_emerg_lock);
+static char avc_emerg_buf[AVC_BUF_SIZE];
+
+struct avc_dump_buf {
+    char *start;
+    char *pos;
+    u32 free;
+};
+
+static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
+{
+    int i;
+    va_list args;
+
+ again:
+    va_start(args, fmt);
+    i = vsnprintf(buf->pos, buf->free, fmt, args);
+    va_end(args);
+    if ( i < buf->free )
+    {
+        buf->pos += i;
+        buf->free -= i;
+    }
+    else if ( buf->free < AVC_BUF_SIZE )
+    {
+        buf->pos[0] = 0;
+        printk("%s", buf->start);
+        buf->pos = buf->start;
+        buf->free = AVC_BUF_SIZE;
+        goto again;
+    }
+    else
+    {
+        printk("%s", buf->start);
+        printk("\navc_printk: overflow\n");
+        buf->pos = buf->start;
+        buf->free = AVC_BUF_SIZE;
+    }
+}
+
 /**
  * avc_dump_av - Display an access vector in human-readable form.
  * @tclass: target security class
  * @av: access vector
  */
-static void avc_dump_av(u16 tclass, u32 av)
+static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
     const char **common_pts = NULL;
     u32 common_base = 0;
@@ -145,7 +187,7 @@ static void avc_dump_av(u16 tclass, u32 av)
 
     if ( av == 0 )
     {
-        printk(" null");
+        avc_printk(buf, " null");
         return;
     }
 
@@ -159,14 +201,14 @@ static void avc_dump_av(u16 tclass, u32 av)
         }
     }
 
-    printk(" {");
+    avc_printk(buf, " {");
     i = 0;
     perm = 1;
     while ( perm < common_base )
     {
         if (perm & av)
         {
-            printk(" %s", common_pts[i]);
+            avc_printk(buf, " %s", common_pts[i]);
             av &= ~perm;
         }
         i++;
@@ -185,7 +227,7 @@ static void avc_dump_av(u16 tclass, u32 av)
             }
             if ( i2 < ARRAY_SIZE(av_perm_to_string) )
             {
-                printk(" %s", av_perm_to_string[i2].name);
+                avc_printk(buf, " %s", av_perm_to_string[i2].name);
                 av &= ~perm;
             }
         }
@@ -194,9 +236,9 @@ static void avc_dump_av(u16 tclass, u32 av)
     }
 
     if ( av )
-        printk(" 0x%x", av);
+        avc_printk(buf, " 0x%x", av);
 
-    printk(" }");
+    avc_printk(buf, " }");
 }
 
 /**
@@ -205,7 +247,7 @@ static void avc_dump_av(u16 tclass, u32 av)
  * @tsid: target security identifier
  * @tclass: target security class
  */
-static void avc_dump_query(u32 ssid, u32 tsid, u16 tclass)
+static void avc_dump_query(struct avc_dump_buf *buf, u32 ssid, u32 tsid, u16 tclass)
 {
     int rc;
     char *scontext;
@@ -213,23 +255,23 @@ static void avc_dump_query(u32 ssid, u32 tsid, u16 tclass)
 
     rc = security_sid_to_context(ssid, &scontext, &scontext_len);
     if ( rc )
-        printk("ssid=%d", ssid);
+        avc_printk(buf, "ssid=%d", ssid);
     else
     {
-        printk("scontext=%s", scontext);
+        avc_printk(buf, "scontext=%s", scontext);
         xfree(scontext);
     }
 
     rc = security_sid_to_context(tsid, &scontext, &scontext_len);
     if ( rc )
-        printk(" tsid=%d", tsid);
+        avc_printk(buf, " tsid=%d", tsid);
     else
     {
-        printk(" tcontext=%s", scontext);
+        avc_printk(buf, " tcontext=%s", scontext);
         xfree(scontext);
     }
 
-    printk(" tclass=%s", class_to_string[tclass]);
+    avc_printk(buf, " tclass=%s", class_to_string[tclass]);
 }
 
 /**
@@ -544,6 +586,7 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
 {
     struct domain *cdom = current->domain;
     u32 denied, audited;
+    struct avc_dump_buf buf;
 
     denied = requested & ~avd->allowed;
     if ( denied )
@@ -562,36 +605,50 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
         if ( !(audited & avd->auditallow) )
             return;
     }
+    buf.start = xmalloc_bytes(AVC_BUF_SIZE);
+    if ( !buf.start )
+    {
+        spin_lock(&avc_emerg_lock);
+        buf.start = avc_emerg_buf;
+    }
+    buf.pos = buf.start;
+    buf.free = AVC_BUF_SIZE;
 
-    printk("avc:  %s ", denied ? "denied" : "granted");
-    avc_dump_av(tclass, audited);
-    printk(" for ");
+    avc_printk(&buf, "avc:  %s ", denied ? "denied" : "granted");
+    avc_dump_av(&buf, tclass, audited);
+    avc_printk(&buf, " for ");
 
     if ( a && (a->sdom || a->tdom) )
     {
         if ( a->sdom && a->tdom && a->sdom != a->tdom )
-            printk("domid=%d target=%d ", a->sdom->domain_id, a->tdom->domain_id);
+            avc_printk(&buf, "domid=%d target=%d ", a->sdom->domain_id, a->tdom->domain_id);
         else if ( a->sdom )
-            printk("domid=%d ", a->sdom->domain_id);
+            avc_printk(&buf, "domid=%d ", a->sdom->domain_id);
         else
-            printk("target=%d ", a->tdom->domain_id);
+            avc_printk(&buf, "target=%d ", a->tdom->domain_id);
     }
     else if ( cdom )
-        printk("domid=%d ", cdom->domain_id);
+        avc_printk(&buf, "domid=%d ", cdom->domain_id);
     switch ( a ? a->type : 0 ) {
     case AVC_AUDIT_DATA_DEV:
-        printk("device=0x%lx ", a->device);
+        avc_printk(&buf, "device=0x%lx ", a->device);
         break;
     case AVC_AUDIT_DATA_IRQ:
-        printk("irq=%d ", a->irq);
+        avc_printk(&buf, "irq=%d ", a->irq);
         break;
     case AVC_AUDIT_DATA_RANGE:
-        printk("range=0x%lx-0x%lx ", a->range.start, a->range.end);
+        avc_printk(&buf, "range=0x%lx-0x%lx ", a->range.start, a->range.end);
         break;
     }
 
-    avc_dump_query(ssid, tsid, tclass);
-    printk("\n");
+    avc_dump_query(&buf, ssid, tsid, tclass);
+    avc_printk(&buf, "\n");
+    printk("%s", buf.start);
+
+    if ( buf.start == avc_emerg_buf )
+        spin_unlock(&avc_emerg_lock);
+    else
+        xfree(buf.start);
 }
 
 /**
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSS-0006Gj-Jz; Tue, 28 Feb 2012 23:27:48 +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 1S2WSQ-0006Fd-Dr
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330471627!58744853!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2875 invoked from network); 28 Feb 2012 23:27: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;
	28 Feb 2012 23:27:08 -0000
X-TM-IMSS-Message-ID: <14895bc100006405@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 14895bc100006405 ;
	Tue, 28 Feb 2012 18:39:37 -0500
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 q1SNRcOS003101; 
	Tue, 28 Feb 2012 18:27:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:17 -0500
Message-Id: <1330471637-8104-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 5/5] xsm: expose context of event channel peers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This hypercall allows a domain to identify the security context of a
domain that it is communicating with using the interdomain event channel
that it is using for the communication. This can be used to augment
Xen's security permissions with intra-domain security checks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c        |    8 --------
 xen/include/public/xsm/flask_op.h |    9 +++++++++
 xen/include/xen/event.h           |   10 ++++++++++
 xen/xsm/flask/flask_op.c          |   36 ++++++++++++++++++++++++++++++++++++
 4 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index ce309da..38df69d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -32,14 +32,6 @@
 #include <public/event_channel.h>
 #include <xsm/xsm.h>
 
-#define bucket_from_port(d,p) \
-    ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-#define port_is_valid(d,p)    \
-    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
-     (bucket_from_port(d,p) != NULL))
-#define evtchn_from_port(d,p) \
-    (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
-
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 83dcd99..1a251c9 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -135,6 +135,13 @@ struct xen_flask_ocontext {
     uint64_t low, high;
 };
 
+struct xen_flask_peersid {
+    /* IN */
+    evtchn_port_t evtchn;
+    /* OUT */
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -159,6 +166,7 @@ struct xen_flask_op {
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
+#define FLASK_GET_PEER_SID      23
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -176,6 +184,7 @@ struct xen_flask_op {
         struct xen_flask_cache_stats cache_stats;
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
+        struct xen_flask_peersid peersid;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 22fc6a3..11a639a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -70,6 +70,16 @@ 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);
 
+/* Internal event channel object accessors */
+#define bucket_from_port(d,p) \
+    ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
+#define port_is_valid(d,p)    \
+    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
+     (bucket_from_port(d,p) != NULL))
+#define evtchn_from_port(d,p) \
+    (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
+
+
 /* Wait on a Xen-attached event channel. */
 #define wait_on_xen_event_channel(port, condition)                      \
     do {                                                                \
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 00a0af2..bd4db37 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -9,6 +9,7 @@
  */
 
 #include <xen/errno.h>
+#include <xen/event.h>
 #include <xsm/xsm.h>
 #include <xen/guest_access.h>
 
@@ -44,6 +45,7 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
         1UL<<FLASK_MEMBER | \
+        1UL<<FLASK_GET_PEER_SID | \
    0)
 
 static DEFINE_SPINLOCK(sel_sem);
@@ -541,6 +543,36 @@ static int flask_ocontext_add(struct xen_flask_ocontext *arg)
     return security_ocontext_add(arg->ocon, arg->low, arg->high, arg->sid);
 }
 
+static int flask_get_peer_sid(struct xen_flask_peersid *arg)
+{
+    int rv = -EINVAL;
+    struct domain *d = current->domain;
+    struct domain *peer;
+    struct evtchn *chn;
+    struct domain_security_struct *dsec;
+
+    spin_lock(&d->event_lock);
+
+    if ( !port_is_valid(d, arg->evtchn) )
+        goto out;
+
+    chn = evtchn_from_port(d, arg->evtchn);
+    if ( chn->state != ECS_INTERDOMAIN )
+        goto out;
+
+    peer = chn->u.interdomain.remote_dom;
+    if ( !peer )
+        goto out;
+
+    dsec = peer->ssid;
+    arg->sid = dsec->sid;
+    rv = 0;
+
+ out:
+    spin_unlock(&d->event_lock);
+    return rv;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -644,6 +676,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_ocontext_del(&op.u.ocontext);
         break;
 
+    case FLASK_GET_PEER_SID:
+        rv = flask_get_peer_sid(&op.u.peersid);
+        break;
+
     default:
         rv = -ENOSYS;
     }
-- 
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 Feb 28 23:28:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WSS-0006Gj-Jz; Tue, 28 Feb 2012 23:27:48 +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 1S2WSQ-0006Fd-Dr
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:27:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330471627!58744853!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2875 invoked from network); 28 Feb 2012 23:27: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;
	28 Feb 2012 23:27:08 -0000
X-TM-IMSS-Message-ID: <14895bc100006405@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 14895bc100006405 ;
	Tue, 28 Feb 2012 18:39:37 -0500
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 q1SNRcOS003101; 
	Tue, 28 Feb 2012 18:27:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Tue, 28 Feb 2012 18:27:17 -0500
Message-Id: <1330471637-8104-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org
Subject: [Xen-devel] [PATCH 5/5] xsm: expose context of event channel peers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This hypercall allows a domain to identify the security context of a
domain that it is communicating with using the interdomain event channel
that it is using for the communication. This can be used to augment
Xen's security permissions with intra-domain security checks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c        |    8 --------
 xen/include/public/xsm/flask_op.h |    9 +++++++++
 xen/include/xen/event.h           |   10 ++++++++++
 xen/xsm/flask/flask_op.c          |   36 ++++++++++++++++++++++++++++++++++++
 4 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index ce309da..38df69d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -32,14 +32,6 @@
 #include <public/event_channel.h>
 #include <xsm/xsm.h>
 
-#define bucket_from_port(d,p) \
-    ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-#define port_is_valid(d,p)    \
-    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
-     (bucket_from_port(d,p) != NULL))
-#define evtchn_from_port(d,p) \
-    (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
-
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 83dcd99..1a251c9 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -135,6 +135,13 @@ struct xen_flask_ocontext {
     uint64_t low, high;
 };
 
+struct xen_flask_peersid {
+    /* IN */
+    evtchn_port_t evtchn;
+    /* OUT */
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -159,6 +166,7 @@ struct xen_flask_op {
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
+#define FLASK_GET_PEER_SID      23
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -176,6 +184,7 @@ struct xen_flask_op {
         struct xen_flask_cache_stats cache_stats;
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
+        struct xen_flask_peersid peersid;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 22fc6a3..11a639a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -70,6 +70,16 @@ 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);
 
+/* Internal event channel object accessors */
+#define bucket_from_port(d,p) \
+    ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
+#define port_is_valid(d,p)    \
+    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
+     (bucket_from_port(d,p) != NULL))
+#define evtchn_from_port(d,p) \
+    (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
+
+
 /* Wait on a Xen-attached event channel. */
 #define wait_on_xen_event_channel(port, condition)                      \
     do {                                                                \
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 00a0af2..bd4db37 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -9,6 +9,7 @@
  */
 
 #include <xen/errno.h>
+#include <xen/event.h>
 #include <xsm/xsm.h>
 #include <xen/guest_access.h>
 
@@ -44,6 +45,7 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
         1UL<<FLASK_MEMBER | \
+        1UL<<FLASK_GET_PEER_SID | \
    0)
 
 static DEFINE_SPINLOCK(sel_sem);
@@ -541,6 +543,36 @@ static int flask_ocontext_add(struct xen_flask_ocontext *arg)
     return security_ocontext_add(arg->ocon, arg->low, arg->high, arg->sid);
 }
 
+static int flask_get_peer_sid(struct xen_flask_peersid *arg)
+{
+    int rv = -EINVAL;
+    struct domain *d = current->domain;
+    struct domain *peer;
+    struct evtchn *chn;
+    struct domain_security_struct *dsec;
+
+    spin_lock(&d->event_lock);
+
+    if ( !port_is_valid(d, arg->evtchn) )
+        goto out;
+
+    chn = evtchn_from_port(d, arg->evtchn);
+    if ( chn->state != ECS_INTERDOMAIN )
+        goto out;
+
+    peer = chn->u.interdomain.remote_dom;
+    if ( !peer )
+        goto out;
+
+    dsec = peer->ssid;
+    arg->sid = dsec->sid;
+    rv = 0;
+
+ out:
+    spin_unlock(&d->event_lock);
+    return rv;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -644,6 +676,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_ocontext_del(&op.u.ocontext);
         break;
 
+    case FLASK_GET_PEER_SID:
+        rv = flask_get_peer_sid(&op.u.peersid);
+        break;
+
     default:
         rv = -ENOSYS;
     }
-- 
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 Feb 28 23:37:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23: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 1S2WbM-0006z4-T4; Tue, 28 Feb 2012 23:37:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S2WbK-0006yz-EQ
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:36:58 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330472211!16332348!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	HTML_SHOUTING5
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6505 invoked from network); 28 Feb 2012 23:36:51 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-11.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 23:36:51 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id C3D0D16296
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 23:36:51 +0000 (GMT)
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 a5ArNqrhyd-l for <xen-devel@lists.xen.org>;
	Tue, 28 Feb 2012 23:36:48 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id B2FD216295;
	Tue, 28 Feb 2012 23:36:46 +0000 (GMT)
Message-ID: <4F4D650E.3010909@abpni.co.uk>
Date: Tue, 28 Feb 2012 23:36:46 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: keith.coleman@n2servers.com, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6647900648941034328=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6647900648941034328==
Content-Type: multipart/alternative;
 boundary="------------090008030301000905020605"

This is a multi-part message in MIME format.
--------------090008030301000905020605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Keith,

CC: Xen-devel Mailing List

I've noticed that you seem to be a major contributor with regards to 
keeping the 3.4.x branch updated with backported security patches. As 
Xen security is a high priority, I hope you don't mind me discussing 
with you whether some CVEs are backported or not. I really appreciate 
your time to read this email. Of course, the rest of the list can chime 
in as always!


    CVE-2011-2901:

http://www.openwall.com/lists/oss-security/2011/09/02/2

The patch performs the following:

-    (((unsigned long)(addr)<  (1UL<<48)) || \
+    (((unsigned long)(addr)<  (1UL<<47)) || \


I see that the Xen security advisory says that only hypervisors 3.3 or 
earlier are affected. However, I note that in later versions of Xen, the 
line changed in the patch remains untouched. Any ideas why this is the 
case? Additionally, Redhat in their advisories claim to fix this issue 
in their kernel update. How can this be, given that this is a Xen 
hypervisor issue?


    CVE-2011-1898

http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg00687.html

Any idea when this can be backported to 3.4.x? I see that this has made 
it to 4.1-testing stable branch

****CVE-2012-0029**
http://seclists.org/oss-sec/2012/q1/360

Maybe this is currently impossible to get going on the 3.4.x branch as 
the upstream qemu trees don't have a 3.4.x Xen patch for this?

*CVE-2011-1166*
https://bugzilla.redhat.com/show_bug.cgi?id=688579
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8

Again, this doesn't appear to be backported to 3.4.x, however I note 
that Red Hat claim to have fixed this in their kernel version. This is 
where I get confused again. How can a hypervisor issue be fixed in the 
kernel??

Once again, I really appreciate your time, and I'm very sorry if I'm 
wasting it!

Thanks,

Jonathan

--------------090008030301000905020605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Keith,<br>
    <br>
    CC: Xen-devel Mailing List<br>
    <br>
    I've noticed that you seem to be a major contributor with regards to
    keeping the 3.4.x branch updated with backported security patches.
    As Xen security is a high priority, I hope you don't mind me
    discussing with you whether some CVEs are backported or not. I
    really appreciate your time to read this email. Of course, the rest
    of the list can chime in as always!<br>
    <meta charset="utf-8">
    <span style="color: rgb(0, 0, 0); font-family: 'DejaVu Sans',
      'Liberation Sans', sans-serif; font-size: 16px; font-style:
      normal; font-variant: normal; font-weight: bold; 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(208, 208,
      208); display: inline !important; float: none; "></span>
    <h2><small>CVE-2011-2901:</small></h2>
    <a class="moz-txt-link-freetext" href="http://www.openwall.com/lists/oss-security/2011/09/02/2">http://www.openwall.com/lists/oss-security/2011/09/02/2</a><br>
    <br>
    The patch performs the following:<br>
    <meta charset="utf-8">
    <pre style="color: rgb(0, 0, 0); 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; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(224, 224, 224); white-space: pre-wrap; ">-    (((unsigned long)(addr) &lt; (1UL&lt;&lt;48)) || \
+    (((unsigned long)(addr) &lt; (1UL&lt;&lt;47)) || \</pre>
    <br>
    I see that the Xen security advisory says that only hypervisors 3.3
    or earlier are affected. However, I note that in later versions of
    Xen, the line changed in the patch remains untouched. Any ideas why
    this is the case? Additionally, Redhat in their advisories claim to
    fix this issue in their kernel update. How can this be, given that
    this is a Xen hypervisor issue?<br>
    <br>
    <meta charset="utf-8">
    <h2 style="margin-top: 0.25em; margin-bottom: 0.25em; color: rgb(0,
      0, 0); font-family: Times; font-style: normal; font-variant:
      normal; letter-spacing: normal; line-height: normal; orphans: 2;
      text-indent: 0px; text-transform: none; white-space: normal;
      widows: 2; word-spacing: 0px;">CVE-2011-1898</h2>
<a class="moz-txt-link-freetext" href="http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg00687.html">http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg00687.html</a><br>
    <br>
    Any idea when this can be backported to 3.4.x? I see that this has
    made it to 4.1-testing stable branch<br>
    <br>
    <meta charset="utf-8">
    <big><big><big><big><strong style="color: rgb(0, 0, 0); font-family:
              Times; font-style: normal; font-variant: 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); font-size: medium; "></strong></big></big><small><b><strong>CVE-2012-0029</strong></b></small></big></big><br>
    <a class="moz-txt-link-freetext" href="http://seclists.org/oss-sec/2012/q1/360">http://seclists.org/oss-sec/2012/q1/360</a><br>
    <br>
    Maybe this is currently impossible to get going on the 3.4.x branch
    as the upstream qemu trees don't have a 3.4.x Xen patch for this?<br>
    <br>
    <b><big>CVE-2011-1166</big></b><br>
    <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=688579">https://bugzilla.redhat.com/show_bug.cgi?id=688579</a><br>
    <a class="moz-txt-link-freetext" href="http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8">http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8</a><br>
    <br>
    Again, this doesn't appear to be backported to 3.4.x, however I note
    that Red Hat claim to have fixed this in their kernel version. This
    is where I get confused again. How can a hypervisor issue be fixed
    in the kernel??<br>
    <br>
    Once again, I really appreciate your time, and I'm very sorry if I'm
    wasting it!<br>
    <br>
    Thanks,<br>
    <br>
    Jonathan<br>
  </body>
</html>

--------------090008030301000905020605--


--===============6647900648941034328==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6647900648941034328==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 23:37:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23: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 1S2WbM-0006z4-T4; Tue, 28 Feb 2012 23:37:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S2WbK-0006yz-EQ
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:36:58 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330472211!16332348!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	HTML_SHOUTING5
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6505 invoked from network); 28 Feb 2012 23:36:51 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-11.tower-216.messagelabs.com with SMTP;
	28 Feb 2012 23:36:51 -0000
Received: from localhost (mail1.gosport.corp.uk.abpni.net [127.0.0.1])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTP id C3D0D16296
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 23:36:51 +0000 (GMT)
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 a5ArNqrhyd-l for <xen-devel@lists.xen.org>;
	Tue, 28 Feb 2012 23:36:48 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id B2FD216295;
	Tue, 28 Feb 2012 23:36:46 +0000 (GMT)
Message-ID: <4F4D650E.3010909@abpni.co.uk>
Date: Tue, 28 Feb 2012 23:36:46 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: keith.coleman@n2servers.com, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6647900648941034328=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6647900648941034328==
Content-Type: multipart/alternative;
 boundary="------------090008030301000905020605"

This is a multi-part message in MIME format.
--------------090008030301000905020605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Keith,

CC: Xen-devel Mailing List

I've noticed that you seem to be a major contributor with regards to 
keeping the 3.4.x branch updated with backported security patches. As 
Xen security is a high priority, I hope you don't mind me discussing 
with you whether some CVEs are backported or not. I really appreciate 
your time to read this email. Of course, the rest of the list can chime 
in as always!


    CVE-2011-2901:

http://www.openwall.com/lists/oss-security/2011/09/02/2

The patch performs the following:

-    (((unsigned long)(addr)<  (1UL<<48)) || \
+    (((unsigned long)(addr)<  (1UL<<47)) || \


I see that the Xen security advisory says that only hypervisors 3.3 or 
earlier are affected. However, I note that in later versions of Xen, the 
line changed in the patch remains untouched. Any ideas why this is the 
case? Additionally, Redhat in their advisories claim to fix this issue 
in their kernel update. How can this be, given that this is a Xen 
hypervisor issue?


    CVE-2011-1898

http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg00687.html

Any idea when this can be backported to 3.4.x? I see that this has made 
it to 4.1-testing stable branch

****CVE-2012-0029**
http://seclists.org/oss-sec/2012/q1/360

Maybe this is currently impossible to get going on the 3.4.x branch as 
the upstream qemu trees don't have a 3.4.x Xen patch for this?

*CVE-2011-1166*
https://bugzilla.redhat.com/show_bug.cgi?id=688579
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8

Again, this doesn't appear to be backported to 3.4.x, however I note 
that Red Hat claim to have fixed this in their kernel version. This is 
where I get confused again. How can a hypervisor issue be fixed in the 
kernel??

Once again, I really appreciate your time, and I'm very sorry if I'm 
wasting it!

Thanks,

Jonathan

--------------090008030301000905020605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Keith,<br>
    <br>
    CC: Xen-devel Mailing List<br>
    <br>
    I've noticed that you seem to be a major contributor with regards to
    keeping the 3.4.x branch updated with backported security patches.
    As Xen security is a high priority, I hope you don't mind me
    discussing with you whether some CVEs are backported or not. I
    really appreciate your time to read this email. Of course, the rest
    of the list can chime in as always!<br>
    <meta charset="utf-8">
    <span style="color: rgb(0, 0, 0); font-family: 'DejaVu Sans',
      'Liberation Sans', sans-serif; font-size: 16px; font-style:
      normal; font-variant: normal; font-weight: bold; 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(208, 208,
      208); display: inline !important; float: none; "></span>
    <h2><small>CVE-2011-2901:</small></h2>
    <a class="moz-txt-link-freetext" href="http://www.openwall.com/lists/oss-security/2011/09/02/2">http://www.openwall.com/lists/oss-security/2011/09/02/2</a><br>
    <br>
    The patch performs the following:<br>
    <meta charset="utf-8">
    <pre style="color: rgb(0, 0, 0); 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; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(224, 224, 224); white-space: pre-wrap; ">-    (((unsigned long)(addr) &lt; (1UL&lt;&lt;48)) || \
+    (((unsigned long)(addr) &lt; (1UL&lt;&lt;47)) || \</pre>
    <br>
    I see that the Xen security advisory says that only hypervisors 3.3
    or earlier are affected. However, I note that in later versions of
    Xen, the line changed in the patch remains untouched. Any ideas why
    this is the case? Additionally, Redhat in their advisories claim to
    fix this issue in their kernel update. How can this be, given that
    this is a Xen hypervisor issue?<br>
    <br>
    <meta charset="utf-8">
    <h2 style="margin-top: 0.25em; margin-bottom: 0.25em; color: rgb(0,
      0, 0); font-family: Times; font-style: normal; font-variant:
      normal; letter-spacing: normal; line-height: normal; orphans: 2;
      text-indent: 0px; text-transform: none; white-space: normal;
      widows: 2; word-spacing: 0px;">CVE-2011-1898</h2>
<a class="moz-txt-link-freetext" href="http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg00687.html">http://old-list-archives.xen.org/archives/html/xen-devel/2011-05/msg00687.html</a><br>
    <br>
    Any idea when this can be backported to 3.4.x? I see that this has
    made it to 4.1-testing stable branch<br>
    <br>
    <meta charset="utf-8">
    <big><big><big><big><strong style="color: rgb(0, 0, 0); font-family:
              Times; font-style: normal; font-variant: 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); font-size: medium; "></strong></big></big><small><b><strong>CVE-2012-0029</strong></b></small></big></big><br>
    <a class="moz-txt-link-freetext" href="http://seclists.org/oss-sec/2012/q1/360">http://seclists.org/oss-sec/2012/q1/360</a><br>
    <br>
    Maybe this is currently impossible to get going on the 3.4.x branch
    as the upstream qemu trees don't have a 3.4.x Xen patch for this?<br>
    <br>
    <b><big>CVE-2011-1166</big></b><br>
    <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=688579">https://bugzilla.redhat.com/show_bug.cgi?id=688579</a><br>
    <a class="moz-txt-link-freetext" href="http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8">http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8</a><br>
    <br>
    Again, this doesn't appear to be backported to 3.4.x, however I note
    that Red Hat claim to have fixed this in their kernel version. This
    is where I get confused again. How can a hypervisor issue be fixed
    in the kernel??<br>
    <br>
    Once again, I really appreciate your time, and I'm very sorry if I'm
    wasting it!<br>
    <br>
    Thanks,<br>
    <br>
    Jonathan<br>
  </body>
</html>

--------------090008030301000905020605--


--===============6647900648941034328==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6647900648941034328==--


From xen-devel-bounces@lists.xen.org Tue Feb 28 23:47:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23: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 1S2Wld-0007De-1g; Tue, 28 Feb 2012 23:47:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1S2Wlb-0007DZ-Jl
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:47:35 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330472847!15165264!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9732 invoked from network); 28 Feb 2012 23:47:29 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 23:47:29 -0000
Received: by dadp14 with SMTP id p14so7276340dad.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 15:47:27 -0800 (PST)
Received-SPF: pass (google.com: domain of fajar@fajar.net designates
	10.68.208.228 as permitted sender) client-ip=10.68.208.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of fajar@fajar.net
	designates 10.68.208.228 as permitted sender)
	smtp.mail=fajar@fajar.net
Received: from mr.google.com ([10.68.208.228])
	by 10.68.208.228 with SMTP id mh4mr59618478pbc.13.1330472847067
	(num_hops = 1); Tue, 28 Feb 2012 15:47:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.208.228 with SMTP id mh4mr50134192pbc.13.1330472846942;
	Tue, 28 Feb 2012 15:47:26 -0800 (PST)
Received: by 10.68.212.167 with HTTP; Tue, 28 Feb 2012 15:47:26 -0800 (PST)
In-Reply-To: <4F4D650E.3010909@abpni.co.uk>
References: <4F4D650E.3010909@abpni.co.uk>
Date: Wed, 29 Feb 2012 06:47:26 +0700
Message-ID: <CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
X-Gm-Message-State: ALoCoQmKzuY8J9AEs5e1TMnuhGbHhWDbqgf3z4G8DKcRZ7eSwkMJAnBnIlZ/bpazhEsGkGxm9Asn
Cc: keith.coleman@n2servers.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> CVE-2011-1166
> https://bugzilla.redhat.com/show_bug.cgi?id=688579
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>
> Again, this doesn't appear to be backported to 3.4.x, however I note that
> Red Hat claim to have fixed this in their kernel version. This is where I
> get confused again. How can a hypervisor issue be fixed in the kernel??

Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
rpm, while xen rpm only contains the userland part. So if you have
three different versions of kernel-xen rpm installed, you'd have three
versions of hypervisors.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 23:47:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23: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 1S2Wld-0007De-1g; Tue, 28 Feb 2012 23:47:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1S2Wlb-0007DZ-Jl
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:47:35 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-14.tower-174.messagelabs.com!1330472847!15165264!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9732 invoked from network); 28 Feb 2012 23:47:29 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 23:47:29 -0000
Received: by dadp14 with SMTP id p14so7276340dad.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 15:47:27 -0800 (PST)
Received-SPF: pass (google.com: domain of fajar@fajar.net designates
	10.68.208.228 as permitted sender) client-ip=10.68.208.228; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of fajar@fajar.net
	designates 10.68.208.228 as permitted sender)
	smtp.mail=fajar@fajar.net
Received: from mr.google.com ([10.68.208.228])
	by 10.68.208.228 with SMTP id mh4mr59618478pbc.13.1330472847067
	(num_hops = 1); Tue, 28 Feb 2012 15:47:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.208.228 with SMTP id mh4mr50134192pbc.13.1330472846942;
	Tue, 28 Feb 2012 15:47:26 -0800 (PST)
Received: by 10.68.212.167 with HTTP; Tue, 28 Feb 2012 15:47:26 -0800 (PST)
In-Reply-To: <4F4D650E.3010909@abpni.co.uk>
References: <4F4D650E.3010909@abpni.co.uk>
Date: Wed, 29 Feb 2012 06:47:26 +0700
Message-ID: <CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
X-Gm-Message-State: ALoCoQmKzuY8J9AEs5e1TMnuhGbHhWDbqgf3z4G8DKcRZ7eSwkMJAnBnIlZ/bpazhEsGkGxm9Asn
Cc: keith.coleman@n2servers.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> CVE-2011-1166
> https://bugzilla.redhat.com/show_bug.cgi?id=688579
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>
> Again, this doesn't appear to be backported to 3.4.x, however I note that
> Red Hat claim to have fixed this in their kernel version. This is where I
> get confused again. How can a hypervisor issue be fixed in the kernel??

Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
rpm, while xen rpm only contains the userland part. So if you have
three different versions of kernel-xen rpm installed, you'd have three
versions of hypervisors.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 23:51:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:51:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Woj-0007KO-Kx; Tue, 28 Feb 2012 23:50:49 +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 1S2Woi-0007KE-0L
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 23:50:48 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330472998!62144710!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1MzI4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9174 invoked from network); 28 Feb 2012 23:50:00 -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; 28 Feb 2012 23:50: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 q1SNodGj013105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 28 Feb 2012 23:50:40 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
	q1SNocEx016677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 28 Feb 2012 23:50:38 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
	q1SNobre026854; Tue, 28 Feb 2012 17:50:37 -0600
MIME-Version: 1.0
Message-ID: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
Date: Tue, 28 Feb 2012 15:50:23 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xensource.com
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
In-Reply-To: <c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F4D6851.00E6,ss=1,re=0.000,fgs=0
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Tuesday, February 28, 2012 2:56 PM
> To: xen-devel@lists.xensource.com
> Cc: ian.campbell@citrix.com; andres@gridcentric.ca; tim@xen.org; JBeulich@suse.com;
> ian.jackson@citrix.com; adin@gridcentric.ca
> Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
> 
>  xen/common/page_alloc.c  |  92 ++++++++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/xen.h |   1 +
>  2 files changed, 93 insertions(+), 0 deletions(-)
> 
> 
> When a low memory threshold on the Xen heap is reached, we fire a global dom0
> virq. If someone's listening, they can free up some more memory. The low
> threshold is configurable via the command line token 'low_mem_virq_limit", and
> defaults to 64MiB.
> 
> We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
> xenballoond, or anything else that can be fired through xencommons.
> 
> We error-check the low mem virq against initial available heap (after dom0
> allocation), to avoid firing immediately.
> 
> Virq issuing is controlled by a hysteresis algorithm: when memory dips below a
> threshold, the virq is issued and the next virq will fire when memory shrinks
> another order of magnitude. The virq will not fire again in the current "band"
> until memory grows over the next higher order of magnitude.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Sorry to be late to the party here, but does this take into
account any fragmentation, i.e. does it reflect that allocations
of order==0 will succeed but order>0 might fail?  Should it?

Or maybe Jan's recent work has eliminated all but the corner
cases of order>0 allocations?  (/me crosses fingers)

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 Feb 28 23:51:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:51:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Woj-0007KO-Kx; Tue, 28 Feb 2012 23:50:49 +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 1S2Woi-0007KE-0L
	for xen-devel@lists.xensource.com; Tue, 28 Feb 2012 23:50:48 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1330472998!62144710!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc1MzI4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9174 invoked from network); 28 Feb 2012 23:50:00 -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; 28 Feb 2012 23:50: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 q1SNodGj013105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 28 Feb 2012 23:50:40 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
	q1SNocEx016677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 28 Feb 2012 23:50:38 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
	q1SNobre026854; Tue, 28 Feb 2012 17:50:37 -0600
MIME-Version: 1.0
Message-ID: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
Date: Tue, 28 Feb 2012 15:50:23 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xensource.com
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
In-Reply-To: <c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-CT-RefId: str=0001.0A090202.4F4D6851.00E6,ss=1,re=0.000,fgs=0
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Tuesday, February 28, 2012 2:56 PM
> To: xen-devel@lists.xensource.com
> Cc: ian.campbell@citrix.com; andres@gridcentric.ca; tim@xen.org; JBeulich@suse.com;
> ian.jackson@citrix.com; adin@gridcentric.ca
> Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
> 
>  xen/common/page_alloc.c  |  92 ++++++++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/xen.h |   1 +
>  2 files changed, 93 insertions(+), 0 deletions(-)
> 
> 
> When a low memory threshold on the Xen heap is reached, we fire a global dom0
> virq. If someone's listening, they can free up some more memory. The low
> threshold is configurable via the command line token 'low_mem_virq_limit", and
> defaults to 64MiB.
> 
> We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
> xenballoond, or anything else that can be fired through xencommons.
> 
> We error-check the low mem virq against initial available heap (after dom0
> allocation), to avoid firing immediately.
> 
> Virq issuing is controlled by a hysteresis algorithm: when memory dips below a
> threshold, the virq is issued and the next virq will fire when memory shrinks
> another order of magnitude. The virq will not fire again in the current "band"
> until memory grows over the next higher order of magnitude.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Sorry to be late to the party here, but does this take into
account any fragmentation, i.e. does it reflect that allocations
of order==0 will succeed but order>0 might fail?  Should it?

Or maybe Jan's recent work has eliminated all but the corner
cases of order>0 allocations?  (/me crosses fingers)

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 Feb 28 23:51:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WpQ-0007Ne-30; Tue, 28 Feb 2012 23:51:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S2WpO-0007NB-HM
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:51:30 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330473084!11148498!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28100 invoked from network); 28 Feb 2012 23:51:24 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-7.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 23:51:24 -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 5F0BA16298
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 23:51:24 +0000 (GMT)
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 M8QvU15ZZ+0h for <xen-devel@lists.xen.org>;
	Tue, 28 Feb 2012 23:51:24 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id BA75C16295;
	Tue, 28 Feb 2012 23:51:18 +0000 (GMT)
Message-ID: <4F4D6876.9040508@abpni.co.uk>
Date: Tue, 28 Feb 2012 23:51:18 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <4F4D650E.3010909@abpni.co.uk>
	<CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
In-Reply-To: <CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
Cc: keith.coleman@n2servers.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 28/02/2012 23:47, Fajar A. Nugraha wrote:
> On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy<jonnyt@abpni.co.uk>  wrote:
>> CVE-2011-1166
>> https://bugzilla.redhat.com/show_bug.cgi?id=688579
>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>>
>> Again, this doesn't appear to be backported to 3.4.x, however I note that
>> Red Hat claim to have fixed this in their kernel version. This is where I
>> get confused again. How can a hypervisor issue be fixed in the kernel??
> Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
> rpm, while xen rpm only contains the userland part. So if you have
> three different versions of kernel-xen rpm installed, you'd have three
> versions of hypervisors.
Interesting!

What we currently do is use CentOS's kernel-xen purely for the Linux 
Kernel, however we use the xen.gz (3.4.x) image from GitCo. Is this bad? 
It's been a very stable combination for us.

I take it this means, for my security concerns, that I have to rely on 
what has been backported to the 3.4.x branch in xenbits, as I'm not 
using Red Hat's backports?

Sorry that I'm a bit confused here

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 23:51:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2WpQ-0007Ne-30; Tue, 28 Feb 2012 23:51:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jonnyt@abpni.co.uk>) id 1S2WpO-0007NB-HM
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:51:30 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330473084!11148498!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28100 invoked from network); 28 Feb 2012 23:51:24 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-7.tower-174.messagelabs.com with SMTP;
	28 Feb 2012 23:51:24 -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 5F0BA16298
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 23:51:24 +0000 (GMT)
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 M8QvU15ZZ+0h for <xen-devel@lists.xen.org>;
	Tue, 28 Feb 2012 23:51:24 +0000 (GMT)
Received: from Jonathans-MacBook-Air.local (unknown [10.87.0.109])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPSA id BA75C16295;
	Tue, 28 Feb 2012 23:51:18 +0000 (GMT)
Message-ID: <4F4D6876.9040508@abpni.co.uk>
Date: Tue, 28 Feb 2012 23:51:18 +0000
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Fajar A. Nugraha" <list@fajar.net>
References: <4F4D650E.3010909@abpni.co.uk>
	<CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
In-Reply-To: <CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
Cc: keith.coleman@n2servers.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 28/02/2012 23:47, Fajar A. Nugraha wrote:
> On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy<jonnyt@abpni.co.uk>  wrote:
>> CVE-2011-1166
>> https://bugzilla.redhat.com/show_bug.cgi?id=688579
>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>>
>> Again, this doesn't appear to be backported to 3.4.x, however I note that
>> Red Hat claim to have fixed this in their kernel version. This is where I
>> get confused again. How can a hypervisor issue be fixed in the kernel??
> Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
> rpm, while xen rpm only contains the userland part. So if you have
> three different versions of kernel-xen rpm installed, you'd have three
> versions of hypervisors.
Interesting!

What we currently do is use CentOS's kernel-xen purely for the Linux 
Kernel, however we use the xen.gz (3.4.x) image from GitCo. Is this bad? 
It's been a very stable combination for us.

I take it this means, for my security concerns, that I have to rely on 
what has been backported to the 3.4.x branch in xenbits, as I'm not 
using Red Hat's backports?

Sorry that I'm a bit confused here

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 23:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Wuh-0007gk-2K; Tue, 28 Feb 2012 23:56:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1S2Wug-0007ge-0J
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:56:58 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330473409!15357991!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7812 invoked from network); 28 Feb 2012 23:56:51 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 23:56:51 -0000
Received: by dadp14 with SMTP id p14so7284207dad.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 15:56:49 -0800 (PST)
Received-SPF: pass (google.com: domain of fajar@fajar.net designates
	10.68.221.73 as permitted sender) client-ip=10.68.221.73; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of fajar@fajar.net
	designates 10.68.221.73 as permitted sender)
	smtp.mail=fajar@fajar.net
Received: from mr.google.com ([10.68.221.73])
	by 10.68.221.73 with SMTP id qc9mr23238849pbc.139.1330473409027
	(num_hops = 1); Tue, 28 Feb 2012 15:56:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.221.73 with SMTP id qc9mr19226496pbc.139.1330473408772;
	Tue, 28 Feb 2012 15:56:48 -0800 (PST)
Received: by 10.68.212.167 with HTTP; Tue, 28 Feb 2012 15:56:48 -0800 (PST)
In-Reply-To: <4F4D6876.9040508@abpni.co.uk>
References: <4F4D650E.3010909@abpni.co.uk>
	<CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
	<4F4D6876.9040508@abpni.co.uk>
Date: Wed, 29 Feb 2012 06:56:48 +0700
Message-ID: <CAG1y0sfMOtbMeiYuNBPcWA4HuQN2B9Yv6Wyjix15_75BdMyD0g@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
X-Gm-Message-State: ALoCoQkJII/JeOWvRl9WMpkKh6Bk/Zy3Mfyd80yZcSg4b7a0qneJi2HaGJF907QwEBbH05FL05Cj
Cc: keith.coleman@n2servers.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 6:51 AM, Jonathan Tripathy <jonnyt@abpni.co.uk> wro=
te:
>
> On 28/02/2012 23:47, Fajar A. Nugraha wrote:
>>
>> On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy<jonnyt@abpni.co.uk>
>> =A0wrote:
>>>
>>> CVE-2011-1166
>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D688579
>>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>>>
>>> Again, this doesn't appear to be backported to 3.4.x, however I note th=
at
>>> Red Hat claim to have fixed this in their kernel version. This is where=
 I
>>> get confused again. How can a hypervisor issue be fixed in the kernel??
>>
>> Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
>> rpm, while xen rpm only contains the userland part. So if you have
>> three different versions of kernel-xen rpm installed, you'd have three
>> versions of hypervisors.
>
> Interesting!
>
> What we currently do is use CentOS's kernel-xen purely for the Linux Kern=
el,
> however we use the xen.gz (3.4.x) image from GitCo. Is this bad?

It depends :)

> It's been a
> very stable combination for us.
>
> I take it this means, for my security concerns, that I have to rely on wh=
at
> has been backported to the 3.4.x branch in xenbits, as I'm not using Red
> Hat's backports?

You could take a look at what redhat has done, and see if you can
integrate the patches into Gitco's RPM.

If you only use block device backend (i.e. phy:/), it might be easier
to just switch to xen-4.1.2 + latest upstream kernel (e.g. using
kernel-ml 3.x rpm from elrpo.org). That way you can easily apply
latest security patches yourself, without having to backport it.

-- =

Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 28 23:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 28 Feb 2012 23:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2Wuh-0007gk-2K; Tue, 28 Feb 2012 23:56:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1S2Wug-0007ge-0J
	for xen-devel@lists.xen.org; Tue, 28 Feb 2012 23:56:58 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330473409!15357991!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7812 invoked from network); 28 Feb 2012 23:56:51 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2012 23:56:51 -0000
Received: by dadp14 with SMTP id p14so7284207dad.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 15:56:49 -0800 (PST)
Received-SPF: pass (google.com: domain of fajar@fajar.net designates
	10.68.221.73 as permitted sender) client-ip=10.68.221.73; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of fajar@fajar.net
	designates 10.68.221.73 as permitted sender)
	smtp.mail=fajar@fajar.net
Received: from mr.google.com ([10.68.221.73])
	by 10.68.221.73 with SMTP id qc9mr23238849pbc.139.1330473409027
	(num_hops = 1); Tue, 28 Feb 2012 15:56:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.221.73 with SMTP id qc9mr19226496pbc.139.1330473408772;
	Tue, 28 Feb 2012 15:56:48 -0800 (PST)
Received: by 10.68.212.167 with HTTP; Tue, 28 Feb 2012 15:56:48 -0800 (PST)
In-Reply-To: <4F4D6876.9040508@abpni.co.uk>
References: <4F4D650E.3010909@abpni.co.uk>
	<CAG1y0sc7=YnvYD3SMVuxSzXbDS3iknqUBd3Jyj9j9pzfhw08XA@mail.gmail.com>
	<4F4D6876.9040508@abpni.co.uk>
Date: Wed, 29 Feb 2012 06:56:48 +0700
Message-ID: <CAG1y0sfMOtbMeiYuNBPcWA4HuQN2B9Yv6Wyjix15_75BdMyD0g@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
X-Gm-Message-State: ALoCoQkJII/JeOWvRl9WMpkKh6Bk/Zy3Mfyd80yZcSg4b7a0qneJi2HaGJF907QwEBbH05FL05Cj
Cc: keith.coleman@n2servers.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 6:51 AM, Jonathan Tripathy <jonnyt@abpni.co.uk> wro=
te:
>
> On 28/02/2012 23:47, Fajar A. Nugraha wrote:
>>
>> On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy<jonnyt@abpni.co.uk>
>> =A0wrote:
>>>
>>> CVE-2011-1166
>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D688579
>>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>>>
>>> Again, this doesn't appear to be backported to 3.4.x, however I note th=
at
>>> Red Hat claim to have fixed this in their kernel version. This is where=
 I
>>> get confused again. How can a hypervisor issue be fixed in the kernel??
>>
>> Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
>> rpm, while xen rpm only contains the userland part. So if you have
>> three different versions of kernel-xen rpm installed, you'd have three
>> versions of hypervisors.
>
> Interesting!
>
> What we currently do is use CentOS's kernel-xen purely for the Linux Kern=
el,
> however we use the xen.gz (3.4.x) image from GitCo. Is this bad?

It depends :)

> It's been a
> very stable combination for us.
>
> I take it this means, for my security concerns, that I have to rely on wh=
at
> has been backported to the 3.4.x branch in xenbits, as I'm not using Red
> Hat's backports?

You could take a look at what redhat has done, and see if you can
integrate the patches into Gitco's RPM.

If you only use block device backend (i.e. phy:/), it might be easier
to just switch to xen-4.1.2 + latest upstream kernel (e.g. using
kernel-ml 3.x rpm from elrpo.org). That way you can easily apply
latest security patches yourself, without having to backport it.

-- =

Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 00:28:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 00: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 1S2XP1-0008Oe-Me; Wed, 29 Feb 2012 00:28:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1S2XOz-0008OZ-Rb
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 00:28:18 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330475207!62135247!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21979 invoked from network); 29 Feb 2012 00:26:48 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 00:26:48 -0000
Received: by yhoo21 with SMTP id o21so1519144yho.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 16:28:12 -0800 (PST)
Received-SPF: pass (google.com: domain of thunderbird2k@gmail.com designates
	10.236.79.195 as permitted sender) client-ip=10.236.79.195; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	thunderbird2k@gmail.com designates 10.236.79.195 as permitted
	sender) smtp.mail=thunderbird2k@gmail.com;
	dkim=pass header.i=thunderbird2k@gmail.com
Received: from mr.google.com ([10.236.79.195])
	by 10.236.79.195 with SMTP id i43mr26954938yhe.53.1330475292124
	(num_hops = 1); Tue, 28 Feb 2012 16:28:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/VvL+aiNmC7HfyCUSzbYZzzw6pSJl3S3KCryIQIeI5w=;
	b=oPzlbZzYxjC16EvFiX294uverHDCtXOQXDiSG29t/fvd+D8RakgEdIO6CnvvWQxEoa
	ZS9D4ZR0wV6qgZKslKm1SACky4Ii4ryBxD5b75px4OlAuZNNl1bp3Rgkl1ksRsVaMKsE
	sk0QJb6mQhd0RySHCfa2v9djcC2seWgPEkGI0=
MIME-Version: 1.0
Received: by 10.236.79.195 with SMTP id i43mr20360536yhe.53.1330475292083;
	Tue, 28 Feb 2012 16:28:12 -0800 (PST)
Received: by 10.100.18.12 with HTTP; Tue, 28 Feb 2012 16:28:11 -0800 (PST)
Date: Wed, 29 Feb 2012 00:28:11 +0000
Message-ID: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Problems with hyperthreading in Windows 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

Hi,

I have been trying to get Hyperthreading to work in a Windows HVM on
Xen 4.1.2 as described in 'xmexample.hvm'. I think I have set it up
correctly, but I can't seem to get it to work. There is not much
documentation on it and most topics are from years ago. I'm curious to
know to whether this functionality is still supposed to work.

I'm aware that Xen itself supports Hyperthreading, but my software is
not happy about seeing every VCPU from Xen as a physical core. I would
like to use hyperthreading opposed to disabling it since the software
in question does benefit of using Hyperthreading.

For reference this is the original Hyperthreading example from 'xmexample.hvm':
#   Expose to the guest multi-core cpu instead of multiple processors
# Example for intel, expose a 8-core processor :
#cpuid=['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
#          ebx=xxxxxxxx00010000xxxxxxxxxxxxxxxx',
#     '4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx']
#  - CPUID.1[EDX][HT] : Enable HT
#  - CPUID.1[EBX] : Number of vcpus * 2
#  - CPUID.4,0[EAX] : Number of vcpus * 2 - 1
#vcpus=8

I tried the example from xmexample.hvm on a 4-core system of which I
wanted to pass 2 physical cores (so 4 logical) to Windows:
cpuid = ['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,ebx=xxxxxxxx00000100xxxxxxxxxxxxxxxx',
'4,0:eax=000011xxxxxxxxxxxxxxxxxxxxxxxxxx' ]
vcpus=2
cpus=['4', '6'] # pin to 2 different physical cores

When I boot up the VM, Windows detects just 2 physical cores. Debug
tools like Sysinternals coreinfo, cpu-z also don't detect 4 logical
cores.

To figure out what is going wrong, I wrote a small win32 tool to check
the result of the cpuid patching. For function 1, it shows that the
correct bits in edx and ebx got updated. The bits of function 4 which
should contain a part of the ACPI ID don't seem to got patched. In
fact eax/ebx/ecx/edx are all reported as 0. From what I saw in
'xc_cpuid_hvm_policy' and 'intel_xc_cpuid_policy' in libxc, Xen
performs filtering on a bunch of cpuid functions. Though all the ones
I patched are preserved by the filtering. From what I saw in past
email threads there were issues with ACPI ID stuff in the past, can
there be new issues here? Does anyone have hyperthreading working?

Thanks,
Roderick Colenbrander

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 00:28:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 00: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 1S2XP1-0008Oe-Me; Wed, 29 Feb 2012 00:28:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1S2XOz-0008OZ-Rb
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 00:28:18 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1330475207!62135247!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21979 invoked from network); 29 Feb 2012 00:26:48 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 00:26:48 -0000
Received: by yhoo21 with SMTP id o21so1519144yho.32
	for <xen-devel@lists.xen.org>; Tue, 28 Feb 2012 16:28:12 -0800 (PST)
Received-SPF: pass (google.com: domain of thunderbird2k@gmail.com designates
	10.236.79.195 as permitted sender) client-ip=10.236.79.195; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	thunderbird2k@gmail.com designates 10.236.79.195 as permitted
	sender) smtp.mail=thunderbird2k@gmail.com;
	dkim=pass header.i=thunderbird2k@gmail.com
Received: from mr.google.com ([10.236.79.195])
	by 10.236.79.195 with SMTP id i43mr26954938yhe.53.1330475292124
	(num_hops = 1); Tue, 28 Feb 2012 16:28:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=/VvL+aiNmC7HfyCUSzbYZzzw6pSJl3S3KCryIQIeI5w=;
	b=oPzlbZzYxjC16EvFiX294uverHDCtXOQXDiSG29t/fvd+D8RakgEdIO6CnvvWQxEoa
	ZS9D4ZR0wV6qgZKslKm1SACky4Ii4ryBxD5b75px4OlAuZNNl1bp3Rgkl1ksRsVaMKsE
	sk0QJb6mQhd0RySHCfa2v9djcC2seWgPEkGI0=
MIME-Version: 1.0
Received: by 10.236.79.195 with SMTP id i43mr20360536yhe.53.1330475292083;
	Tue, 28 Feb 2012 16:28:12 -0800 (PST)
Received: by 10.100.18.12 with HTTP; Tue, 28 Feb 2012 16:28:11 -0800 (PST)
Date: Wed, 29 Feb 2012 00:28:11 +0000
Message-ID: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Problems with hyperthreading in Windows 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

Hi,

I have been trying to get Hyperthreading to work in a Windows HVM on
Xen 4.1.2 as described in 'xmexample.hvm'. I think I have set it up
correctly, but I can't seem to get it to work. There is not much
documentation on it and most topics are from years ago. I'm curious to
know to whether this functionality is still supposed to work.

I'm aware that Xen itself supports Hyperthreading, but my software is
not happy about seeing every VCPU from Xen as a physical core. I would
like to use hyperthreading opposed to disabling it since the software
in question does benefit of using Hyperthreading.

For reference this is the original Hyperthreading example from 'xmexample.hvm':
#   Expose to the guest multi-core cpu instead of multiple processors
# Example for intel, expose a 8-core processor :
#cpuid=['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
#          ebx=xxxxxxxx00010000xxxxxxxxxxxxxxxx',
#     '4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx']
#  - CPUID.1[EDX][HT] : Enable HT
#  - CPUID.1[EBX] : Number of vcpus * 2
#  - CPUID.4,0[EAX] : Number of vcpus * 2 - 1
#vcpus=8

I tried the example from xmexample.hvm on a 4-core system of which I
wanted to pass 2 physical cores (so 4 logical) to Windows:
cpuid = ['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,ebx=xxxxxxxx00000100xxxxxxxxxxxxxxxx',
'4,0:eax=000011xxxxxxxxxxxxxxxxxxxxxxxxxx' ]
vcpus=2
cpus=['4', '6'] # pin to 2 different physical cores

When I boot up the VM, Windows detects just 2 physical cores. Debug
tools like Sysinternals coreinfo, cpu-z also don't detect 4 logical
cores.

To figure out what is going wrong, I wrote a small win32 tool to check
the result of the cpuid patching. For function 1, it shows that the
correct bits in edx and ebx got updated. The bits of function 4 which
should contain a part of the ACPI ID don't seem to got patched. In
fact eax/ebx/ecx/edx are all reported as 0. From what I saw in
'xc_cpuid_hvm_policy' and 'intel_xc_cpuid_policy' in libxc, Xen
performs filtering on a bunch of cpuid functions. Though all the ones
I patched are preserved by the filtering. From what I saw in past
email threads there were issues with ACPI ID stuff in the past, can
there be new issues here? Does anyone have hyperthreading working?

Thanks,
Roderick Colenbrander

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 00:51:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 00: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 1S2Xkp-0000C4-L9; Wed, 29 Feb 2012 00:50:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1S2Xkn-0000Bw-Q4
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 00:50:50 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330476641!3238717!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjAzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19133 invoked from network); 29 Feb 2012 00:50:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-21.messagelabs.com with SMTP;
	29 Feb 2012 00:50:42 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Feb 2012 16:50:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="p7s'?scan'208";a="130684964"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 28 Feb 2012 16:50:40 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 08:50:39 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 08:50:33 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
Thread-Index: AQHM9fDcOgxqEIaz10u7t9yvY06r/JZTCo5A
Date: Wed, 29 Feb 2012 00:50:32 +0000
Message-ID: <6E28F413615167448D5D4146F2D9370B0FCD8E77@SHSMSX102.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
	<4F4C9A7702000078000751B9@nat28.tlf.novell.com>
In-Reply-To: <4F4C9A7702000078000751B9@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]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2806606368032162785=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2806606368032162785==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0050_01CCF6BF.31B34380"

------=_NextPart_000_0050_01CCF6BF.31B34380
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> - actual use in the hypervisor itself
> - use in Linux (afaict impossible at least for HLE with ticket locks, yet
Jan,
We are working on the first one. I know someone is working on the kernel
side, but I don't know any details.
But HLE should be useful for a lock(not fine grained) for protecting an
in-memory data structure that are actually grasped by different lock holders
to access different data fields(which are non-relevant to each other).
It might not be the cases for Xen hypervisor. We need profile and see.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Tuesday, February 28, 2012 4:12 PM
> To: Liu, Jinsong
> Cc: xen-devel@lists.xensource.com; keir.xen@gmail.com; Ian Campbell
> Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
> 
> >>> On 28.02.12 at 06:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> > X86: expose HLE/RTM features to dom0
> >
> > Intel recently release 2 new features, HLE and TRM.
> > Refer to http://software.intel.com/file/41417.
> > This patch expose them to dom0.
> 
> While I committed this as obviously correct and desirable, I wonder what
> plans you have with this feature wrt
> - permitting use for HVM guests
> - permitting use in pv DomU
> - actual use in the hypervisor itself
> - use in Linux (afaict impossible at least for HLE with ticket locks, yet
>   HLE is certainly the more desirable first step)
> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

------=_NextPart_000_0050_01CCF6BF.31B34380
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTIwMjI5MDA1MDMxWjAjBgkqhkiG9w0BCQQxFgQU6u+6VOLpHITqa7RDhknmp5CbgYYw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBTTpITd72YvO9hI8aUcor4g/1Uz7rkdhQVLUU+
39DccqG1x9JKazh6smcmxEtNVsk93UkjACOD7wMhN+TNgYDbFxjbWfIvm4vVpfxP4co+/N4Umy0l
Ivrd7B2NUPilPx7R0L8zSdWoA0S05A6IcZu/zemIptqhYFT33+ZkQ2/tWoZJ+N2IHui0rD7lT2Dw
gWXtsdJMRcWHpja45K14VrEyRkNsLHVx4+U5V7p/pMXMyCgAtzuL7gPFF0B210H1TG2QVh+On8p/
autQ4BAa9fGBksMZToyNnv7Ec5ETp7BxqZHVeColOEC62rthmdy0sXL7s0M9jPrzakpGmXIdRXyX
AAAAAAAA

------=_NextPart_000_0050_01CCF6BF.31B34380--


--===============2806606368032162785==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2806606368032162785==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 00:51:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 00: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 1S2Xkp-0000C4-L9; Wed, 29 Feb 2012 00:50:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <haitao.shan@intel.com>) id 1S2Xkn-0000Bw-Q4
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 00:50:50 +0000
X-Env-Sender: haitao.shan@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330476641!3238717!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjAzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19133 invoked from network); 29 Feb 2012 00:50:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-21.messagelabs.com with SMTP;
	29 Feb 2012 00:50:42 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 28 Feb 2012 16:50:41 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; 
	d="p7s'?scan'208";a="130684964"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by fmsmga002.fm.intel.com with ESMTP; 28 Feb 2012 16:50:40 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 08:50:39 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 08:50:33 +0800
From: "Shan, Haitao" <haitao.shan@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Liu, Jinsong" <jinsong.liu@intel.com>
Thread-Topic: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
Thread-Index: AQHM9fDcOgxqEIaz10u7t9yvY06r/JZTCo5A
Date: Wed, 29 Feb 2012 00:50:32 +0000
Message-ID: <6E28F413615167448D5D4146F2D9370B0FCD8E77@SHSMSX102.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350B7B46@SHSMSX101.ccr.corp.intel.com>
	<4F4C9A7702000078000751B9@nat28.tlf.novell.com>
In-Reply-To: <4F4C9A7702000078000751B9@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]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2806606368032162785=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2806606368032162785==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0050_01CCF6BF.31B34380"

------=_NextPart_000_0050_01CCF6BF.31B34380
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> - actual use in the hypervisor itself
> - use in Linux (afaict impossible at least for HLE with ticket locks, yet
Jan,
We are working on the first one. I know someone is working on the kernel
side, but I don't know any details.
But HLE should be useful for a lock(not fine grained) for protecting an
in-memory data structure that are actually grasped by different lock holders
to access different data fields(which are non-relevant to each other).
It might not be the cases for Xen hypervisor. We need profile and see.

Shan Haitao

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Tuesday, February 28, 2012 4:12 PM
> To: Liu, Jinsong
> Cc: xen-devel@lists.xensource.com; keir.xen@gmail.com; Ian Campbell
> Subject: Re: [Xen-devel] [Patch] X86: expose HLE/RTM features to dom0
> 
> >>> On 28.02.12 at 06:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> > X86: expose HLE/RTM features to dom0
> >
> > Intel recently release 2 new features, HLE and TRM.
> > Refer to http://software.intel.com/file/41417.
> > This patch expose them to dom0.
> 
> While I committed this as obviously correct and desirable, I wonder what
> plans you have with this feature wrt
> - permitting use for HVM guests
> - permitting use in pv DomU
> - actual use in the hypervisor itself
> - use in Linux (afaict impossible at least for HLE with ticket locks, yet
>   HLE is certainly the more desirable first step)
> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

------=_NextPart_000_0050_01CCF6BF.31B34380
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCCAyAw
ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx
dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05
ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp
ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg
uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3
wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E
aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE
EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY
IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG
CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1
hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8
7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3
ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT
EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD
IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj
ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv
uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4
lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+
iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0
Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl
Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD
AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69
tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j
Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFijCCBHKgAwIBAgIKYSCKYgAA
AAAACDANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wOTA1MTUx
OTI3MjZaFw0xNTA1MTUxOTM3MjZaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKQEM1Wn9TU9vc9C+/Tc7KB+eiYElmrcEWE32WUd
HvWG+IcQHVQsikTmMyKKojNLw2B5s6Iekc8ivDo/wCfjZzX9JyftMnc+AArc0la87Olybzm8K9jX
EfTBvTnUSFSiI9ZYefITdiUgqlAFuljFZEHYKYtLuhrRacpmQfP4mV63NKdc2bT804HRf6YptZFa
4k6YN94zlrGNrBuQQ74WFzz/jLBusbUpEkro6Mu/ZYFOFWQrV9lBhF9Ruk8yN+3N6n9fUo/qBigi
F2kEn9xVh1ykl7SCGL2jBUkXx4qgV27a6Si8lRRdgrHGtN/HWnSWlLXTH5l575H4Lq++77OFv38C
AwEAAaOCAlwwggJYMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFA7GKvdZsggQkCVvw939imYx
MCvFMAsGA1UdDwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcVAgQWBBQ5oFY2
ekKQ/5Ktim+VdMeSWb4QWTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQa
xgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3kl
MjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu
dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYw
gdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNh
dGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcw
AoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMv
SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQCxtQEHchVQhXyjEqtMVUMe6gkmPsIczHxSeqNbo9dsD+6xbT65JT+oYgpIAtfEsYXeUJu1
cChqpb22U5bMAz7eaQcW5bzefufWvA6lg2048B8oczBj/q+5P5NpYrUO8jOmN4jTjfJq3ElZ7yFW
py7rB3Vm/aN6ATYqWfMbS/xfh+JCxmH3droUmMJI0/aZJHsLtjbjFnNsHDNrJZX1vxlM78Lb1hjs
kTENPmhbVbfTj5i/ZGnhv4tmI8QZPCNtcegXJrfhRl2D9bWpdTOPrWiLDUqzy1Z6KL7TcOS/PCl8
RHCJXkPau/thTQCpIoDa2+c+3XA++gRTfAQ4svTO260NMIIGBzCCBO+gAwIBAgIKEx06gQABAAB7
rTANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMTExMDEy
MDEyNDIwWhcNMTQwOTI2MDEyNDIwWjA9MRUwEwYDVQQDEwxTaGFuLCBIYWl0YW8xJDAiBgkqhkiG
9w0BCQEWFWhhaXRhby5zaGFuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALpHYbXkMy06K6Pl9IGxbsKl0zT/OYd523Rh3CX7tHG/80ZGcPeLlzFK+l+30Fhpzf8fsFwG
l5fX2pRtWqT96BUWecXEVJhisfa1Wrq7DBC6coxEnExFADU+2UsBQ/ACKFSCiq/fADojyFWJgPKv
4PLDKJ9LU23Q+g1WRruGHfBnhCMv0KxnkE7pTk3cFRXtNUSUnYLqcvrZwt9VogQNiNNw3jMlDb8t
bJjMsXdhrwqFGW49z/gAJ2Mnr6/lNnqBdcKF2Qm28SfYXRohGrmam3KReM49ZG0+J/+JPF5drbiw
UAV++PMHA3IXIvZF2c66jQM5BzbF93SkoZXmrQZA2jMCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIH
gDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBD
AgFkAgEIMB0GA1UdDgQWBBQ/OInBCgrko9ziRWiEhjM+SyeeoDAfBgNVHSMEGDAWgBQOxir3WbII
EJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRwOi8vd3d3LmludGVsLmNv
bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El
MjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JM
L0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNybDCB9QYI
KwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVw
b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy
MENBJTIwM0IoMSkuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQB
gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBHBgNVHREEQDA+oCUGCisGAQQBgjcU
AgOgFwwVaGFpdGFvLnNoYW5AaW50ZWwuY29tgRVoYWl0YW8uc2hhbkBpbnRlbC5jb20wDQYJKoZI
hvcNAQEFBQADggEBAG5Us26ruu8jKt3RhZuirjqgF61p+wZer/xV6BTABUx5++DhWXslTztavsvy
JZ5WsZ7xaijBUO3UQViWTylwmSyGwbhEwreu3XRNGlMOnRk+sH7JGiXZJIpqoD/jtRWp0ypHG2g3
nDqAQ1/j4wUgcI0b12KUJyYAeN6cwEeAqIV4mdD8GpH3DS2nZbEZjTNhkaeJuT7lO1jRqzEGOSCk
KDHPfqUtqpw+wZa6mFbzSso9swc4ypgRIl4l5i/4OwNMQazHm2O6Ov91aDJs6j3DCdALzP736hmF
QFfHWL34GFQMRdpO/OI6z/Q0VYm/6N9o4SD/s4J9Edq8zyYNQxBR03QwggZOMIIFNqADAgECAgoT
I00xAAEAAHuuMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD
b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe
Fw0xMTEwMTIwMTMwNTZaFw0xNDA5MjYwMTMwNTZaMD0xFTATBgNVBAMTDFNoYW4sIEhhaXRhbzEk
MCIGCSqGSIb3DQEJARYVaGFpdGFvLnNoYW5AaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEApaOcuQtYCobUiLQTadd0Hi+U/ausgzeSE59iUrc57VUzvLsLNnKRxLPm+T26
KN9fMDAS3/MZOl5tf+9mKEwrergim5GzwJpfZWPLAyK2Gs57+F+BMgtX6DT0eh4sGQLQDahPZDhy
Ubo420AiTGuTA9/L22B/qbPNuDRNMMJoreAZeSNBSVPa7Q+Y0oXcfKpAmKzHH2Y+WAzupN5jfxhJ
6yb7MpsPDqoU0Ek4VttgUIl4AQlRFMI18ScKvAG2p9kWSSgq+Z9xdQl7F/3ASkXlQMKEOHCDw8E7
XUzqy4pOoXGaI3FVI4AerPeLgz2SkNINfqLnxdhN+BQ6iuRgsOeyIwIDAQABo4IDNTCCAzEwCwYD
VR0PBAQDAgQwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ
Z4S52UGHhP9OAgFkAgEMMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU/+6IdpvPrUveCml7StYwqL40
iqMwHwYDVR0jBBgwFoAUDsYq91myCBCQJW/D3f2KZjEwK8Uwgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4ZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy
MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3JshmBodHRwOi8vY2VydGlmaWNhdGVzLmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQigxKS5jcmwwgfUGCCsGAQUFBwEBBIHoMIHlMGwGCCsGAQUFBzAChmBodHRwOi8v
d3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIw
QmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcnQwdQYIKwYBBQUHMAKGaWh0dHA6Ly9jZXJ0
aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJu
YWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDAfBgNVHSUEGDAWBggrBgEFBQcD
BAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw
RwYDVR0RBEAwPqAlBgorBgEEAYI3FAIDoBcMFWhhaXRhby5zaGFuQGludGVsLmNvbYEVaGFpdGFv
LnNoYW5AaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqWvSRW8jKGuWVwUKo/+QRxKvuT3cv
/975omnwo7QeOj78XruY/Wsl6/tnzI8jgf6ZE5SRoj5sSGBHmy7qHSZNWodLuJgjN+a0Fk2hy0jB
wX2UJLS3ctijemo4e4u8/YFebLVXCzy81lWa7dZcidebnslLlcQXHNzl8hhFAfQwhcCXMAiA89NO
3uJqd9Sk/PSfG90b/f+1u2xIthxQmeh7u1yuiHZrf1u/e6rJWS50iW+LWmrH0c70XN8voHpLXVDo
09C9DETzJOUrhr1BqLVSxKjNn/uhCOcQxNYM3CYsgQBwVogKsGj59xeGFA5iWPKGRj7SfUXH0m3T
kiSaWLnWMYIDhjCCA4ICAQEwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y
YXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMdOoEA
AQAAe60wCQYFKw4DAhoFAKCCAfcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTIwMjI5MDA1MDMxWjAjBgkqhkiG9w0BCQQxFgQU6u+6VOLpHITqa7RDhknmp5CbgYYw
cwYJKwYBBAGCNxAEMWYwZDBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp
b24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ICChMjTTEAAQAA
e64wdQYLKoZIhvcNAQkQAgsxZqBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQgIKEyNN
MQABAAB7rjCBqwYJKoZIhvcNAQkPMYGdMIGaMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglg
hkgBZQMEARYwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG
CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBTTpITd72YvO9hI8aUcor4g/1Uz7rkdhQVLUU+
39DccqG1x9JKazh6smcmxEtNVsk93UkjACOD7wMhN+TNgYDbFxjbWfIvm4vVpfxP4co+/N4Umy0l
Ivrd7B2NUPilPx7R0L8zSdWoA0S05A6IcZu/zemIptqhYFT33+ZkQ2/tWoZJ+N2IHui0rD7lT2Dw
gWXtsdJMRcWHpja45K14VrEyRkNsLHVx4+U5V7p/pMXMyCgAtzuL7gPFF0B210H1TG2QVh+On8p/
autQ4BAa9fGBksMZToyNnv7Ec5ETp7BxqZHVeColOEC62rthmdy0sXL7s0M9jPrzakpGmXIdRXyX
AAAAAAAA

------=_NextPart_000_0050_01CCF6BF.31B34380--


--===============2806606368032162785==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2806606368032162785==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 01:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 01:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2YUx-0004GR-B5; Wed, 29 Feb 2012 01:38:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1S2YUw-0004GM-8Q
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 01:38:30 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330479503!16295369!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1MTIy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17629 invoked from network); 29 Feb 2012 01:38:24 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 01:38:24 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 28 Feb 2012 17:38:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="71603111"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Feb 2012 17:38:22 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 09:37:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 09:37:11 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mXoLtMbLcjAQU+xeB0hceXa1ZZTEttw
Date: Wed, 29 Feb 2012 01:37:11 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
In-Reply-To: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

I noticed the following comments when using mwait based idle:
-------------------------------------------------------------------------
        while ( 1 )
        {
            /*
             * 1. The CLFLUSH is a workaround for erratum AAI65 for
             * the Xeon 7400 series.
             * 2. The WBINVD is insufficient due to the spurious-wakeup
             * case where we return around the loop.
             * 3. Unlike wbinvd, clflush is a light weight but not serializing
             * instruction, hence memory fence is necessary to make sure all
             * load/store visible before flush cache line.
             */
            mb();
            clflush(mwait_ptr);
            __monitor(mwait_ptr, 0, 0);
            mb();
            __mwait(cx->address, 0);
        }
    }
-------------------------------------------------------------------------
Your patch should follow it too.

best regards
yang


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
> Sent: Wednesday, February 29, 2012 6:09 AM
> To: xen-devel@lists.xensource.com
> Cc: boris.ostrovsky@amd.com
> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
> 
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330466573 -3600 #
> Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
> x86: Use deep C states for off-lined CPUs
> 
> Currently when a core is taken off-line it is placed in C1 state (unless
> MONITOR/MWAIT is used). This patch allows a core to go to deeper C states
> resulting in significantly higher power savings.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> 
> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
> 
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +
>          /*
>           * Cache must be flushed as the last operation before sleeping.
>           * Otherwise, CPU may still hold dirty data, breaking cache coherency,
> @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    }
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }
>      }
> 
>  default_halt:
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 01:39:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 01:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2YUx-0004GR-B5; Wed, 29 Feb 2012 01:38:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1S2YUw-0004GM-8Q
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 01:38:30 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330479503!16295369!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1MTIy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17629 invoked from network); 29 Feb 2012 01:38:24 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 01:38:24 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 28 Feb 2012 17:38:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="71603111"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Feb 2012 17:38:22 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 09:37:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 09:37:11 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mXoLtMbLcjAQU+xeB0hceXa1ZZTEttw
Date: Wed, 29 Feb 2012 01:37:11 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
In-Reply-To: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

I noticed the following comments when using mwait based idle:
-------------------------------------------------------------------------
        while ( 1 )
        {
            /*
             * 1. The CLFLUSH is a workaround for erratum AAI65 for
             * the Xeon 7400 series.
             * 2. The WBINVD is insufficient due to the spurious-wakeup
             * case where we return around the loop.
             * 3. Unlike wbinvd, clflush is a light weight but not serializing
             * instruction, hence memory fence is necessary to make sure all
             * load/store visible before flush cache line.
             */
            mb();
            clflush(mwait_ptr);
            __monitor(mwait_ptr, 0, 0);
            mb();
            __mwait(cx->address, 0);
        }
    }
-------------------------------------------------------------------------
Your patch should follow it too.

best regards
yang


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
> Sent: Wednesday, February 29, 2012 6:09 AM
> To: xen-devel@lists.xensource.com
> Cc: boris.ostrovsky@amd.com
> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
> 
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330466573 -3600 #
> Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
> x86: Use deep C states for off-lined CPUs
> 
> Currently when a core is taken off-line it is placed in C1 state (unless
> MONITOR/MWAIT is used). This patch allows a core to go to deeper C states
> resulting in significantly higher power savings.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> 
> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
> 
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +
>          /*
>           * Cache must be flushed as the last operation before sleeping.
>           * Otherwise, CPU may still hold dirty data, breaking cache coherency,
> @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    }
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }
>      }
> 
>  default_halt:
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 04:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 04: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 1S2akN-0005P3-Ps; Wed, 29 Feb 2012 04:02:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2akM-0005Oy-5B
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:02:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330488142!11201056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTk1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 957 invoked from network); 29 Feb 2012 04:02:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 04:02:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,499,1325462400"; d="scan'208";a="10998437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 04:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 04:02:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2ak9-000687-2X;
	Wed, 29 Feb 2012 04:02:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2ak9-0001m7-1t;
	Wed, 29 Feb 2012 04:02:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12107-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 29 Feb 2012 04:02:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12107: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12107 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12107/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12105

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 04:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 04: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 1S2akN-0005P3-Ps; Wed, 29 Feb 2012 04:02:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2akM-0005Oy-5B
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:02:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330488142!11201056!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTk1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 957 invoked from network); 29 Feb 2012 04:02:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 04:02:22 -0000
X-IronPort-AV: E=Sophos;i="4.73,499,1325462400"; d="scan'208";a="10998437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 04:02:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 04:02:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2ak9-000687-2X;
	Wed, 29 Feb 2012 04:02:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2ak9-0001m7-1t;
	Wed, 29 Feb 2012 04:02:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12107-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 29 Feb 2012 04:02:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 12107: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12107 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12107/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11891

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 12105

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  9 guest-start.2            fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  9 guest-start.2          fail never pass
 test-amd64-i386-rhel6hvm-amd 11 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-i386-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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                8326829847694d598382b3c5717f220e30b03137
baseline version:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad

------------------------------------------------------------
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-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.

------------------------------------------------------------
commit 8326829847694d598382b3c5717f220e30b03137
Merge: 1aaf53e... adb67a7...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Sat Feb 18 15:02:07 2012 -0800

    Merge commit 'v2.6.32.56' into xen/next-2.6.32
    
    * commit 'v2.6.32.56': (22 commits)
      Linux 2.6.32.56
      USB: ftdi_sio: fix initial baud rate
      USB: cp210x: do not map baud rates to B0
      USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
      hwmon: (sht15) fix bad error code
      hwmon: (f71805f) Fix clamping of temperature limits
      USB: usbsevseg: fix max length
      usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
      USB: cdc-wdm: updating desc->length must be protected by spin_lock
      USB: ftdi_sio: Add more identifiers
      USB: serial: ftdi additional IDs
      USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
      USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
      dm: do not forward ioctls from logical volumes to the underlying device
      block: fail SCSI passthrough ioctls on partition devices
      Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
      crypto: sha512 - reduce stack usage to safe number
      crypto: sha512 - make it work, undo percpu message schedule
      drm: Fix authentication kernel crash
      eCryptfs: Make truncate path killable
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 04:04:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 04:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2als-0005TU-FE; Wed, 29 Feb 2012 04:04:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2alq-0005T8-QL
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:04:07 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330488238!15393942!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2732 invoked from network); 29 Feb 2012 04:04:00 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.15)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Feb 2012 04:04:00 -0000
Received: from mail156-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 04:03:58 +0000
Received: from mail156-tx2 (localhost [127.0.0.1])	by
	mail156-tx2-R.bigfish.com (Postfix) with ESMTP id 6718940596;
	Wed, 29 Feb 2012 04:03:58 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zz9371I542M1432Nzz1202hzz8275bh8275dhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2
	(MessageSwitch) id 1330488236371171_6159;
	Wed, 29 Feb 2012 04:03:56 +0000 (UTC)
Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.246])	by
	mail156-tx2.bigfish.com (Postfix) with ESMTP id 5682E140046;
	Wed, 29 Feb 2012 04:03:56 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 04:03:56 +0000
X-WSS-ID: 0M04ZAI-01-21L-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 2D6B310281DA;	Tue, 28 Feb 2012 22:03:54 -0600 (CST)
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, 28 Feb 2012 22:04:04 -0600
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag03.amd.com ([fe80::85b5:3838:d8b4:20ba%24]) with mapi id
	14.01.0323.003; Tue, 28 Feb 2012 22:03:54 -0600
From: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mWLRwF6ZZmpfEOiGbCIzNTxU5ZTfRmA///DKzI=
Date: Wed, 29 Feb 2012 04:03:54 +0000
Message-ID: <12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [163.181.250.155]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

The patch is adding IO-based C-states. My understading is that CFLUSH was to work around a MONITOR-related erratum. 

Or are you referring to something else?

-boris


________________________________________
From: Zhang, Yang Z [yang.z.zhang@intel.com]
Sent: Tuesday, February 28, 2012 8:37 PM
To: Ostrovsky, Boris; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs

I noticed the following comments when using mwait based idle:
-------------------------------------------------------------------------
        while ( 1 )
        {
            /*
             * 1. The CLFLUSH is a workaround for erratum AAI65 for
             * the Xeon 7400 series.
             * 2. The WBINVD is insufficient due to the spurious-wakeup
             * case where we return around the loop.
             * 3. Unlike wbinvd, clflush is a light weight but not serializing
             * instruction, hence memory fence is necessary to make sure all
             * load/store visible before flush cache line.
             */
            mb();
            clflush(mwait_ptr);
            __monitor(mwait_ptr, 0, 0);
            mb();
            __mwait(cx->address, 0);
        }
    }
-------------------------------------------------------------------------
Your patch should follow it too.

best regards
yang


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
> Sent: Wednesday, February 29, 2012 6:09 AM
> To: xen-devel@lists.xensource.com
> Cc: boris.ostrovsky@amd.com
> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
>
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330466573 -3600 #
> Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
> x86: Use deep C states for off-lined CPUs
>
> Currently when a core is taken off-line it is placed in C1 state (unless
> MONITOR/MWAIT is used). This patch allows a core to go to deeper C states
> resulting in significantly higher power savings.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>
> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c    Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c    Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
>
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +
>          /*
>           * Cache must be flushed as the last operation before sleeping.
>           * Otherwise, CPU may still hold dirty data, breaking cache coherency,
> @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    }
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }
>      }
>
>  default_halt:
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 04:04:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 04:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2als-0005TU-FE; Wed, 29 Feb 2012 04:04:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2alq-0005T8-QL
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:04:07 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330488238!15393942!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2732 invoked from network); 29 Feb 2012 04:04:00 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.15)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Feb 2012 04:04:00 -0000
Received: from mail156-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 04:03:58 +0000
Received: from mail156-tx2 (localhost [127.0.0.1])	by
	mail156-tx2-R.bigfish.com (Postfix) with ESMTP id 6718940596;
	Wed, 29 Feb 2012 04:03:58 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zz9371I542M1432Nzz1202hzz8275bh8275dhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2
	(MessageSwitch) id 1330488236371171_6159;
	Wed, 29 Feb 2012 04:03:56 +0000 (UTC)
Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.246])	by
	mail156-tx2.bigfish.com (Postfix) with ESMTP id 5682E140046;
	Wed, 29 Feb 2012 04:03:56 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 04:03:56 +0000
X-WSS-ID: 0M04ZAI-01-21L-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 2D6B310281DA;	Tue, 28 Feb 2012 22:03:54 -0600 (CST)
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, 28 Feb 2012 22:04:04 -0600
Received: from SAUSEXDAG02.amd.com ([fe80::ed3c:9786:3083:dd99]) by
	sausexdag03.amd.com ([fe80::85b5:3838:d8b4:20ba%24]) with mapi id
	14.01.0323.003; Tue, 28 Feb 2012 22:03:54 -0600
From: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mWLRwF6ZZmpfEOiGbCIzNTxU5ZTfRmA///DKzI=
Date: Wed, 29 Feb 2012 04:03:54 +0000
Message-ID: <12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [163.181.250.155]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

The patch is adding IO-based C-states. My understading is that CFLUSH was to work around a MONITOR-related erratum. 

Or are you referring to something else?

-boris


________________________________________
From: Zhang, Yang Z [yang.z.zhang@intel.com]
Sent: Tuesday, February 28, 2012 8:37 PM
To: Ostrovsky, Boris; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs

I noticed the following comments when using mwait based idle:
-------------------------------------------------------------------------
        while ( 1 )
        {
            /*
             * 1. The CLFLUSH is a workaround for erratum AAI65 for
             * the Xeon 7400 series.
             * 2. The WBINVD is insufficient due to the spurious-wakeup
             * case where we return around the loop.
             * 3. Unlike wbinvd, clflush is a light weight but not serializing
             * instruction, hence memory fence is necessary to make sure all
             * load/store visible before flush cache line.
             */
            mb();
            clflush(mwait_ptr);
            __monitor(mwait_ptr, 0, 0);
            mb();
            __mwait(cx->address, 0);
        }
    }
-------------------------------------------------------------------------
Your patch should follow it too.

best regards
yang


> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
> Sent: Wednesday, February 29, 2012 6:09 AM
> To: xen-devel@lists.xensource.com
> Cc: boris.ostrovsky@amd.com
> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
>
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330466573 -3600 #
> Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
> x86: Use deep C states for off-lined CPUs
>
> Currently when a core is taken off-line it is placed in C1 state (unless
> MONITOR/MWAIT is used). This patch allows a core to go to deeper C states
> resulting in significantly higher power savings.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>
> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c    Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c    Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
>
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +
>          /*
>           * Cache must be flushed as the last operation before sleeping.
>           * Otherwise, CPU may still hold dirty data, breaking cache coherency,
> @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    }
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }
>      }
>
>  default_halt:
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 04:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 04: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 1S2az8-0005oQ-0S; Wed, 29 Feb 2012 04:17:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2az1-0005oI-B9
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:17:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330489056!13538055!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24404 invoked from network); 29 Feb 2012 04:17:36 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.74) by server-15.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 04:17:36 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id A9A554B0084;
	Tue, 28 Feb 2012 20:17:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LAnWIlruPt7S2nTFS6VHftiBZ5G4V5k+4iPZ5NUTdwTu
	1A7rijVyEDRbZIVivkjJz5Xyh0pOZdNqcYvHAupVC/hoS9SQyHzlflnyzdfGtZp4
	oF/8mztH3xAylwlX5vS26N06SuJ5i/8rsmzNikZYnnKWRqFBLzYMuyLbPS83hnA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=WvQuyDFFfjfG+S47Yeu4c4vbE38=; b=ZHqKuh26
	XYujEkuHqn7ebnDEsU6UA2QLEZ1ZOC3MMuiL0lVMdH7FY76C8rtkZ7zB3EX0Y3vi
	rwO9RTM+Z7yWFW3IJsZLJTaX67bLrS3y5w2k64HumpRIcegl+PYu9zHib8xe5n2D
	CyWmOI80kfA9CLIgGntH0vtpNjvtteU5OPY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 5C8B44B006D; 
	Tue, 28 Feb 2012 20:17:35 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 20:17:35 -0800
Message-ID: <ab105e3149d7b9bd1331fb2ec99ae983.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
	<7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
Date: Tue, 28 Feb 2012 20:17:35 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Tuesday, February 28, 2012 2:56 PM
>> To: xen-devel@lists.xensource.com
>> Cc: ian.campbell@citrix.com; andres@gridcentric.ca; tim@xen.org;
>> JBeulich@suse.com;
>> ian.jackson@citrix.com; adin@gridcentric.ca
>> Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory
>> situations
>>
>>  xen/common/page_alloc.c  |  92
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/xen.h |   1 +
>>  2 files changed, 93 insertions(+), 0 deletions(-)
>>
>>
>> When a low memory threshold on the Xen heap is reached, we fire a global
>> dom0
>> virq. If someone's listening, they can free up some more memory. The low
>> threshold is configurable via the command line token
>> 'low_mem_virq_limit", and
>> defaults to 64MiB.
>>
>> We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
>> xenballoond, or anything else that can be fired through xencommons.
>>
>> We error-check the low mem virq against initial available heap (after
>> dom0
>> allocation), to avoid firing immediately.
>>
>> Virq issuing is controlled by a hysteresis algorithm: when memory dips
>> below a
>> threshold, the virq is issued and the next virq will fire when memory
>> shrinks
>> another order of magnitude. The virq will not fire again in the current
>> "band"
>> until memory grows over the next higher order of magnitude.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Sorry to be late to the party here, but does this take into
> account any fragmentation, i.e. does it reflect that allocations
> of order==0 will succeed but order>0 might fail?  Should it?

Not really concerned about fragmentation. Simply looking at overall count.
Andres

>
> Or maybe Jan's recent work has eliminated all but the corner
> cases of order>0 allocations?  (/me crosses fingers)
>
> 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 Feb 29 04:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 04: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 1S2az8-0005oQ-0S; Wed, 29 Feb 2012 04:17:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2az1-0005oI-B9
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:17:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1330489056!13538055!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzE1Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24404 invoked from network); 29 Feb 2012 04:17:36 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.74) by server-15.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 04:17:36 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id A9A554B0084;
	Tue, 28 Feb 2012 20:17:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LAnWIlruPt7S2nTFS6VHftiBZ5G4V5k+4iPZ5NUTdwTu
	1A7rijVyEDRbZIVivkjJz5Xyh0pOZdNqcYvHAupVC/hoS9SQyHzlflnyzdfGtZp4
	oF/8mztH3xAylwlX5vS26N06SuJ5i/8rsmzNikZYnnKWRqFBLzYMuyLbPS83hnA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=WvQuyDFFfjfG+S47Yeu4c4vbE38=; b=ZHqKuh26
	XYujEkuHqn7ebnDEsU6UA2QLEZ1ZOC3MMuiL0lVMdH7FY76C8rtkZ7zB3EX0Y3vi
	rwO9RTM+Z7yWFW3IJsZLJTaX67bLrS3y5w2k64HumpRIcegl+PYu9zHib8xe5n2D
	CyWmOI80kfA9CLIgGntH0vtpNjvtteU5OPY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 5C8B44B006D; 
	Tue, 28 Feb 2012 20:17:35 -0800 (PST)
Received: from 69.196.132.193 (proxying for 69.196.132.193)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 28 Feb 2012 20:17:35 -0800
Message-ID: <ab105e3149d7b9bd1331fb2ec99ae983.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
	<7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
Date: Tue, 28 Feb 2012 20:17:35 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Tuesday, February 28, 2012 2:56 PM
>> To: xen-devel@lists.xensource.com
>> Cc: ian.campbell@citrix.com; andres@gridcentric.ca; tim@xen.org;
>> JBeulich@suse.com;
>> ian.jackson@citrix.com; adin@gridcentric.ca
>> Subject: [Xen-devel] [PATCH 1 of 2] Global virq for low memory
>> situations
>>
>>  xen/common/page_alloc.c  |  92
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/xen.h |   1 +
>>  2 files changed, 93 insertions(+), 0 deletions(-)
>>
>>
>> When a low memory threshold on the Xen heap is reached, we fire a global
>> dom0
>> virq. If someone's listening, they can free up some more memory. The low
>> threshold is configurable via the command line token
>> 'low_mem_virq_limit", and
>> defaults to 64MiB.
>>
>> We define a new virq VIRQ_ENOMEM. Potential listeners include squeezed,
>> xenballoond, or anything else that can be fired through xencommons.
>>
>> We error-check the low mem virq against initial available heap (after
>> dom0
>> allocation), to avoid firing immediately.
>>
>> Virq issuing is controlled by a hysteresis algorithm: when memory dips
>> below a
>> threshold, the virq is issued and the next virq will fire when memory
>> shrinks
>> another order of magnitude. The virq will not fire again in the current
>> "band"
>> until memory grows over the next higher order of magnitude.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Sorry to be late to the party here, but does this take into
> account any fragmentation, i.e. does it reflect that allocations
> of order==0 will succeed but order>0 might fail?  Should it?

Not really concerned about fragmentation. Simply looking at overall count.
Andres

>
> Or maybe Jan's recent work has eliminated all but the corner
> cases of order>0 allocations?  (/me crosses fingers)
>
> 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 Feb 29 05:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 05: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 1S2bdh-00065y-DF; Wed, 29 Feb 2012 04:59:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2bdf-00065t-RQ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:59:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330491577!15406403!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjAzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26015 invoked from network); 29 Feb 2012 04:59:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 04:59:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 28 Feb 2012 20:59:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122964319"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2012 20:59:35 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 12:59:04 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 12:59:04 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 12:58:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mX1reT45x1/cUmLtPslQNqUjZZTTrmg
Date: Wed, 29 Feb 2012 04:58:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BA8B7@SHSMSX101.ccr.corp.intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
In-Reply-To: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

I don't think we should go back to old SYSIO method, the history here is:

Xen originally has SYSIO method when offline cpu, but at c/s 23022 we cancel it as reason below
======================
x86: Fix cpu offline bug: cancel SYSIO method when play dead

Play dead is a fragile and tricky point of cpu offline logic.  For how
to play cpu dead, linux kernel changed several times: Very old kernel
support 3 ways to play cpu dead: mwait, SYSIO, and halt, just like
what cpuidle did when enter C3; Later, it cancel mwait and SYSIO
support, only use halt to play dead; Latest linux 2.6.38 add mwait
support when cpu dead.

This patch cancel SYSIO method when cpu dead, keep same with latest
kernel.

SYSIO is an obsoleted method to enter deep C, with some tricky
hardware behavior, and seldom supported in new platform.  Xen
experiment indicate that when cpu dead, SYSIO method would trigger
unknown issue which would bring strange error.  We now cancel SYSIO
method when cpu dead, after all, correctness is more important than
power save, and btw new platform use mwait.
======================

Thanks,
Jinsong

Boris Ostrovsky wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1330466573 -3600
> # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
> x86: Use deep C states for off-lined CPUs
> 
> Currently when a core is taken off-line it is placed in C1 state
> (unless MONITOR/MWAIT is used). This patch allows a core to go to
> deeper C states resulting in significantly higher power savings.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> 
> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
> 
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +
>          /*
>           * Cache must be flushed as the last operation before
> sleeping. 
>           * Otherwise, CPU may still hold dirty data, breaking cache
> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    }
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }
>      }
> 
>  default_halt:
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 05:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 05: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 1S2bdh-00065y-DF; Wed, 29 Feb 2012 04:59:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2bdf-00065t-RQ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:59:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330491577!15406403!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjAzNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26015 invoked from network); 29 Feb 2012 04:59:37 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-9.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 04:59:37 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 28 Feb 2012 20:59:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122964319"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2012 20:59:35 -0800
Received: from pgsmsx152.gar.corp.intel.com (172.30.236.43) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 12:59:04 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX152.gar.corp.intel.com (172.30.236.43) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 12:59:04 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 12:58:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mX1reT45x1/cUmLtPslQNqUjZZTTrmg
Date: Wed, 29 Feb 2012 04:58:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BA8B7@SHSMSX101.ccr.corp.intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
In-Reply-To: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

I don't think we should go back to old SYSIO method, the history here is:

Xen originally has SYSIO method when offline cpu, but at c/s 23022 we cancel it as reason below
======================
x86: Fix cpu offline bug: cancel SYSIO method when play dead

Play dead is a fragile and tricky point of cpu offline logic.  For how
to play cpu dead, linux kernel changed several times: Very old kernel
support 3 ways to play cpu dead: mwait, SYSIO, and halt, just like
what cpuidle did when enter C3; Later, it cancel mwait and SYSIO
support, only use halt to play dead; Latest linux 2.6.38 add mwait
support when cpu dead.

This patch cancel SYSIO method when cpu dead, keep same with latest
kernel.

SYSIO is an obsoleted method to enter deep C, with some tricky
hardware behavior, and seldom supported in new platform.  Xen
experiment indicate that when cpu dead, SYSIO method would trigger
unknown issue which would bring strange error.  We now cancel SYSIO
method when cpu dead, after all, correctness is more important than
power save, and btw new platform use mwait.
======================

Thanks,
Jinsong

Boris Ostrovsky wrote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1330466573 -3600
> # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
> x86: Use deep C states for off-lined CPUs
> 
> Currently when a core is taken off-line it is placed in C1 state
> (unless MONITOR/MWAIT is used). This patch allows a core to go to
> deeper C states resulting in significantly higher power savings.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
> 
> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
> 
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +
>          /*
>           * Cache must be flushed as the last operation before
> sleeping. 
>           * Otherwise, CPU may still hold dirty data, breaking cache
> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    }
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }
>      }
> 
>  default_halt:
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 05:23:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 05:23:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2bzf-0006XG-B2; Wed, 29 Feb 2012 05:22:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2bzd-0006XB-4g
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 05:22:25 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330492937!16355065!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwNTE0NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1327 invoked from network); 29 Feb 2012 05:22:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 05:22:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 28 Feb 2012 21:22:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122972214"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2012 21:22:15 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 13:21:21 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 13:21:20 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 13:21:19 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mWLreT45x1/cUmLtPslQNqUjZZTfRmA///DKzKAABLVUA==
Date: Wed, 29 Feb 2012 05:21:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
	<12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
In-Reply-To: <12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.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: "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

Hmm, no.

It need flush cache, as long as *deep Cx* would be spurious-wokenup.
The reason clflush here is, it's a light-weight flush, in fact it also could use wbinvd if not consider performance.

For halt, it don't need to do so since cpu still keep snoop when sleep.

Thanks,
Jinsong

Ostrovsky, Boris wrote:
> The patch is adding IO-based C-states. My understading is that CFLUSH
> was to work around a MONITOR-related erratum. 
> 
> Or are you referring to something else?
> 
> -boris
> 
> 
> ________________________________________
> From: Zhang, Yang Z [yang.z.zhang@intel.com]
> Sent: Tuesday, February 28, 2012 8:37 PM
> To: Ostrovsky, Boris; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
> CPUs 
> 
> I noticed the following comments when using mwait based idle:
> -------------------------------------------------------------------------
>         while ( 1 )
>         {
>             /*
>              * 1. The CLFLUSH is a workaround for erratum AAI65 for
>              * the Xeon 7400 series.
>              * 2. The WBINVD is insufficient due to the
> spurious-wakeup 
>              * case where we return around the loop.
>              * 3. Unlike wbinvd, clflush is a light weight but not
> serializing 
>              * instruction, hence memory fence is necessary to make
> sure all 
>              * load/store visible before flush cache line.
>              */
>             mb();
>             clflush(mwait_ptr);
>             __monitor(mwait_ptr, 0, 0);
>             mb();
>             __mwait(cx->address, 0);
>         }
>     }
> -------------------------------------------------------------------------
> Your patch should follow it too.
> 
> best regards
> yang
> 
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
>> Sent: Wednesday, February 29, 2012 6:09 AM
>> To: xen-devel@lists.xensource.com
>> Cc: boris.ostrovsky@amd.com
>> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
>> CPUs 
>> 
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330466573
>> -3600 # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
>> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
>> x86: Use deep C states for off-lined CPUs
>> 
>> Currently when a core is taken off-line it is placed in C1 state
>> (unless MONITOR/MWAIT is used). This patch allows a core to go to
>> deeper C states resulting in significantly higher power savings.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> 
>> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
>> --- a/xen/arch/x86/acpi/cpu_idle.c    Mon Feb 27 17:05:18 2012 +0000
>> +++ b/xen/arch/x86/acpi/cpu_idle.c    Tue Feb 28 23:02:53 2012 +0100
>> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>>      if ( (cx = &power->states[power->count-1]) == NULL )         
>> goto default_halt; 
>> 
>> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); -
>>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>>      {
>> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); +
>>          /*
>>           * Cache must be flushed as the last operation before
>> sleeping. 
>>           * Otherwise, CPU may still hold dirty data, breaking cache
>> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)    
>>              mb(); __mwait(cx->address, 0);
>>          }
>> +    }
>> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO ) +    {
>> +        /* Avoid references to shared data after the cache flush */
>> +        u32 address = cx->address;
>> +        u32 pmtmr_ioport_local = pmtmr_ioport;
>> +
>> +        wbinvd();
>> +
>> +        while ( 1 )
>> +        {
>> +            inb(address);
>> +            inl(pmtmr_ioport_local);
>> +        }
>>      }
>> 
>>  default_halt:
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Feb 29 05:23:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 05:23:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2bzf-0006XG-B2; Wed, 29 Feb 2012 05:22:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2bzd-0006XB-4g
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 05:22:25 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330492937!16355065!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwNTE0NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1327 invoked from network); 29 Feb 2012 05:22:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 05:22:18 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 28 Feb 2012 21:22:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122972214"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
	by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2012 21:22:15 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 13:21:21 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 13:21:20 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.36]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 13:21:19 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>, "Zhang, Yang Z"
	<yang.z.zhang@intel.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH] x86: Use deep C states for off-lined CPUs
Thread-Index: AQHM9mWLreT45x1/cUmLtPslQNqUjZZTfRmA///DKzKAABLVUA==
Date: Wed, 29 Feb 2012 05:21:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
	<12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
In-Reply-To: <12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.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: "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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

Hmm, no.

It need flush cache, as long as *deep Cx* would be spurious-wokenup.
The reason clflush here is, it's a light-weight flush, in fact it also could use wbinvd if not consider performance.

For halt, it don't need to do so since cpu still keep snoop when sleep.

Thanks,
Jinsong

Ostrovsky, Boris wrote:
> The patch is adding IO-based C-states. My understading is that CFLUSH
> was to work around a MONITOR-related erratum. 
> 
> Or are you referring to something else?
> 
> -boris
> 
> 
> ________________________________________
> From: Zhang, Yang Z [yang.z.zhang@intel.com]
> Sent: Tuesday, February 28, 2012 8:37 PM
> To: Ostrovsky, Boris; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
> CPUs 
> 
> I noticed the following comments when using mwait based idle:
> -------------------------------------------------------------------------
>         while ( 1 )
>         {
>             /*
>              * 1. The CLFLUSH is a workaround for erratum AAI65 for
>              * the Xeon 7400 series.
>              * 2. The WBINVD is insufficient due to the
> spurious-wakeup 
>              * case where we return around the loop.
>              * 3. Unlike wbinvd, clflush is a light weight but not
> serializing 
>              * instruction, hence memory fence is necessary to make
> sure all 
>              * load/store visible before flush cache line.
>              */
>             mb();
>             clflush(mwait_ptr);
>             __monitor(mwait_ptr, 0, 0);
>             mb();
>             __mwait(cx->address, 0);
>         }
>     }
> -------------------------------------------------------------------------
> Your patch should follow it too.
> 
> best regards
> yang
> 
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
>> Sent: Wednesday, February 29, 2012 6:09 AM
>> To: xen-devel@lists.xensource.com
>> Cc: boris.ostrovsky@amd.com
>> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
>> CPUs 
>> 
>> # HG changeset patch
>> # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330466573
>> -3600 # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
>> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
>> x86: Use deep C states for off-lined CPUs
>> 
>> Currently when a core is taken off-line it is placed in C1 state
>> (unless MONITOR/MWAIT is used). This patch allows a core to go to
>> deeper C states resulting in significantly higher power savings.
>> 
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
>> 
>> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
>> --- a/xen/arch/x86/acpi/cpu_idle.c    Mon Feb 27 17:05:18 2012 +0000
>> +++ b/xen/arch/x86/acpi/cpu_idle.c    Tue Feb 28 23:02:53 2012 +0100
>> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>>      if ( (cx = &power->states[power->count-1]) == NULL )         
>> goto default_halt; 
>> 
>> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); -
>>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>>      {
>> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); +
>>          /*
>>           * Cache must be flushed as the last operation before
>> sleeping. 
>>           * Otherwise, CPU may still hold dirty data, breaking cache
>> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)    
>>              mb(); __mwait(cx->address, 0);
>>          }
>> +    }
>> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO ) +    {
>> +        /* Avoid references to shared data after the cache flush */
>> +        u32 address = cx->address;
>> +        u32 pmtmr_ioport_local = pmtmr_ioport;
>> +
>> +        wbinvd();
>> +
>> +        while ( 1 )
>> +        {
>> +            inb(address);
>> +            inl(pmtmr_ioport_local);
>> +        }
>>      }
>> 
>>  default_halt:
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Feb 29 08:03:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08: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 1S2eVC-0000fa-2q; Wed, 29 Feb 2012 08:03:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2eVA-0000fR-1S
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 08:03:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330502580!16373358!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1MTIy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6513 invoked from network); 29 Feb 2012 08:03:01 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 08:03:01 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 29 Feb 2012 00:02:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112641445"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 29 Feb 2012 00:02:58 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 29 Feb 2012 16:01:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 16:01:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
Thread-Index: AQHM9Kz1m4MGy1d3TzK01xgwJYdnxZZSeQoggAD7/5A=
Date: Wed, 29 Feb 2012 08:01:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BAC09@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
	<20120226173458.GB18098@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350B9496@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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and
	xen	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
>>> Liu, Jinsong wrote:
>>>> Jan Beulich wrote:
>>>>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>>>>> --- a/drivers/acpi/Kconfig
>>>>>> +++ b/drivers/acpi/Kconfig
>>>>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>>>>    default y
>>>>>  >
>>>>>> config ACPI_PROCESSOR_AGGREGATOR
>>>>>> -    tristate "Processor Aggregator"
>>>>>> +    bool "Processor Aggregator"
>>>>> 
>>>>> There must be ways to address whatever strange problem you see
>>>>> without making this piece of code non-modular.
>>>>> 
>>>> 
>>>> Yes, another approach is x86_init approach, defining acpi_pad_ops
>>>> at x86_init.c and overwritten when xen_start_kernel. This patch is
>>>> just a RFC patch, to evaluate which approch is more reasonable :-)
>>>> 
>>> 
>>> Have a more think about it, x86_init approach still need to disable
>>> acpi_pad module. Seems we have to set acpi_pad as bool, as long as
>>> it need to hook to native acpi_pad fucs/variables.
>> 
>> What about the other approach I suggested where there are some
>> function overrides in osl.c? Something similar to
>> https://lkml.org/lkml/2012/1/17/401, specifically
>> https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
>> the modules into being built in, but intead have the function table
>> already in the kernel (as some form of EXPORT_SYMBOL_GPL or a
>> registration function). 
>> 
> 
> Thanks for the example (it's good itself :-), but per my
> understanding they are different cases. 
> 
> In the osl example case, tboot_late_init call
> acpi_os_set_prepare_sleep to register func, so it works no matter
> tboot.c built as y/n/m (through currently it's bool).  
> 
> However, in our case, we just cannot do so. We need
> 1. predefine a hook to native acpi pad funcs, take effect when static
> compile stage; 
> 2. when xen init, redirect the hook to xen acpi pad funcs, take
> effect at running time; (The point is, we cannot do init twice for
> native and xen acpi pad, so we have to statically predefine a hook to
> native acpi_pad)  
> 
> For the reason above, I think we have to remove acpi_pad module, as
> long as we need to hook to native acpi_pad funcs. Thoughts? 
> 

Compare approaches:

1. xen overwritten approach (patches V2, x86_init, osl approach)
    Pros:
        a little simpler code
    Cons:
        1). specific to xen, cannot extend to other virt platform;
        2). need to change natvie acpi_pad as modular;

2. paravirt interface approach (original patches V1)
    Pros:
        1). standard hypervisor-agnostic interface (USENIX conference 2006), can easily hook to Xen/lguest/... on demand;
        2). arch independent;
        3). no need to change native acpi_pad as non-modular;
    Cons:
        a little complicated code, and code patching is some overkilled for this case (but no harm);

(BTW, in the future we need add more and more pv ops, like pv_pm_ops, pv_cpu_hotplug_ops, pv_mem_hotplug_ops, etc. So how about add a pv_misc_ops template to handle them all? seems it's a common issue).

Your opinion?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:03:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08: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 1S2eVC-0000fa-2q; Wed, 29 Feb 2012 08:03:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2eVA-0000fR-1S
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 08:03:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330502580!16373358!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1MTIy\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6513 invoked from network); 29 Feb 2012 08:03:01 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 08:03:01 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 29 Feb 2012 00:02:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112641445"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by azsmga001.ch.intel.com with ESMTP; 29 Feb 2012 00:02:58 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 29 Feb 2012 16:01:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 16:01:55 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen
	platform
Thread-Index: AQHM9Kz1m4MGy1d3TzK01xgwJYdnxZZSeQoggAD7/5A=
Date: Wed, 29 Feb 2012 08:01:54 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BAC09@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC82923350AD088@SHSMSX101.ccr.corp.intel.com>
	<4F46530B020000780007F751@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
	<20120226173458.GB18098@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350B9496@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: "Brown, Len" <len.brown@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Jan Beulich <jbeulich@suse.com>, "Li, Shaohua" <shaohua.li@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and
	xen	platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
>>> Liu, Jinsong wrote:
>>>> Jan Beulich wrote:
>>>>>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 02/23/12 2:29 PM >>>
>>>>>> --- a/drivers/acpi/Kconfig
>>>>>> +++ b/drivers/acpi/Kconfig
>>>>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>>>>    default y
>>>>>  >
>>>>>> config ACPI_PROCESSOR_AGGREGATOR
>>>>>> -    tristate "Processor Aggregator"
>>>>>> +    bool "Processor Aggregator"
>>>>> 
>>>>> There must be ways to address whatever strange problem you see
>>>>> without making this piece of code non-modular.
>>>>> 
>>>> 
>>>> Yes, another approach is x86_init approach, defining acpi_pad_ops
>>>> at x86_init.c and overwritten when xen_start_kernel. This patch is
>>>> just a RFC patch, to evaluate which approch is more reasonable :-)
>>>> 
>>> 
>>> Have a more think about it, x86_init approach still need to disable
>>> acpi_pad module. Seems we have to set acpi_pad as bool, as long as
>>> it need to hook to native acpi_pad fucs/variables.
>> 
>> What about the other approach I suggested where there are some
>> function overrides in osl.c? Something similar to
>> https://lkml.org/lkml/2012/1/17/401, specifically
>> https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
>> the modules into being built in, but intead have the function table
>> already in the kernel (as some form of EXPORT_SYMBOL_GPL or a
>> registration function). 
>> 
> 
> Thanks for the example (it's good itself :-), but per my
> understanding they are different cases. 
> 
> In the osl example case, tboot_late_init call
> acpi_os_set_prepare_sleep to register func, so it works no matter
> tboot.c built as y/n/m (through currently it's bool).  
> 
> However, in our case, we just cannot do so. We need
> 1. predefine a hook to native acpi pad funcs, take effect when static
> compile stage; 
> 2. when xen init, redirect the hook to xen acpi pad funcs, take
> effect at running time; (The point is, we cannot do init twice for
> native and xen acpi pad, so we have to statically predefine a hook to
> native acpi_pad)  
> 
> For the reason above, I think we have to remove acpi_pad module, as
> long as we need to hook to native acpi_pad funcs. Thoughts? 
> 

Compare approaches:

1. xen overwritten approach (patches V2, x86_init, osl approach)
    Pros:
        a little simpler code
    Cons:
        1). specific to xen, cannot extend to other virt platform;
        2). need to change natvie acpi_pad as modular;

2. paravirt interface approach (original patches V1)
    Pros:
        1). standard hypervisor-agnostic interface (USENIX conference 2006), can easily hook to Xen/lguest/... on demand;
        2). arch independent;
        3). no need to change native acpi_pad as non-modular;
    Cons:
        a little complicated code, and code patching is some overkilled for this case (but no harm);

(BTW, in the future we need add more and more pv ops, like pv_pm_ops, pv_cpu_hotplug_ops, pv_mem_hotplug_ops, etc. So how about add a pv_misc_ops template to handle them all? seems it's a common issue).

Your opinion?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:53:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08:53:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2fH5-0002Vj-J8; Wed, 29 Feb 2012 08:52:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2fH4-0002VT-FU
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 08:52:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330505551!16382331!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17722 invoked from network); 29 Feb 2012 08:52:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 08:52:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 08:52:31 +0000
Message-Id: <4F4DF58502000078000755C1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 08:53:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
In-Reply-To: <c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 >>> On 28.02.12 at 22:56, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> @@ -300,6 +301,91 @@ static unsigned long init_node_heap(int 
>      return needed;
>  }
>  
> +/* Default to 64 MiB */
> +#define DEFAULT_LOW_MEM_VIRQ    (((paddr_t) 64)   << 20)
> +#define MAX_LOW_MEM_VIRQ        (((paddr_t) 1024) << 20)
> +
> +static paddr_t __read_mostly opt_low_mem_virq = DEFAULT_LOW_MEM_VIRQ;
> +size_param("low_mem_virq_limit", opt_low_mem_virq);
> +
> +/* Thresholds to control hysteresis. In pages */
> +/* When memory grows above this threshold, reset hysteresis.
> + * -1 initially to not reset until at least one virq issued. */
> +static unsigned long low_mem_virq_high      = -1UL;
> +/* Threshold at which we issue virq */
> +static unsigned long low_mem_virq_th        = 0;
> +/* Original threshold after all checks completed */
> +static unsigned long low_mem_virq_orig      = 0;
> +/* Order for current threshold */
> +static unsigned int  low_mem_virq_th_order  = 0;
> +
> +/* Perform bootstrapping checks and set bounds */
> +static void __init setup_low_mem_virq(void)
> +{
> +    unsigned int order;
> +    paddr_t threshold;
> +
> +    /* Dom0 has already been allocated by now. So check we won't 
> +     * be complaining immediately with whatever's left of the heap. */
> +    threshold = min(opt_low_mem_virq, 
> +                    ((paddr_t) total_avail_pages) << PAGE_SHIFT);
> +
> +    /* Then, cap to some predefined maximum */
> +    threshold = min(threshold, MAX_LOW_MEM_VIRQ);
> +
> +    /* If the user specified no knob, and we are at the current available 
> +     * level, halve the threshold. */
> +    if ( (opt_low_mem_virq == DEFAULT_LOW_MEM_VIRQ)

This condition being true is not an indication that there was nothing
specified on the command line.

> +            && (threshold == (((paddr_t) total_avail_pages) << PAGE_SHIFT)) )
> +        threshold >>= 1;
> +
> +    /* Threshold bytes -> pages */
> +    low_mem_virq_th = threshold >> PAGE_SHIFT;
> +
> +    /* Next, round the threshold down to the next order */
> +    order = get_order_from_pages(low_mem_virq_th);

This has undefined (and unexpected by you) behavior if
low_mem_virq_th is zero (which I would think ought to mean "disable
this whole logic").

> +    if ( (1UL << order) > low_mem_virq_th ) 
> +        order--;
> +
> +    /* Set bounds, ready to go */
> +    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",
> +            low_mem_virq_th);
> +}
> +
> +static void check_low_mem_virq(void)
> +{
> +    if ( total_avail_pages <= low_mem_virq_th )
> +    {
> +        send_global_virq(VIRQ_ENOMEM);
> +
> +        /* Update thresholds. Next warning will be when we drop below
> +         * next order. However, we wait until we grow beyond one
> +         * order above us to complain again at the current order */
> +        low_mem_virq_high   = 1UL << (low_mem_virq_th_order + 1);
> +        if ( low_mem_virq_th_order > 0 )
> +            low_mem_virq_th_order--;
> +        low_mem_virq_th     = 1UL << low_mem_virq_th_order;
> +        return;
> +    }
> +
> +    if ( total_avail_pages >= low_mem_virq_high )
> +    {
> +        /* Reset hysteresis. Bring threshold up one order.
> +         * If we are back where originally set, set high
> +         * threshold to -1 to avoid further growth of 
> +         * virq threshold. */
> +        low_mem_virq_th_order++;
> +        low_mem_virq_th = 1UL << low_mem_virq_th_order;
> +        if ( low_mem_virq_th == low_mem_virq_orig )
> +            low_mem_virq_high = -1UL;
> +        else
> +            low_mem_virq_high = 1UL << (low_mem_virq_th_order + 2);
> +    }
> +}
> +
>  /* Allocate 2^@order contiguous pages. */
>  static struct page_info *alloc_heap_pages(
>      unsigned int zone_lo, unsigned int zone_hi,

Also, could you please check your patches for not introducing trailing
whitespace?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:53:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08:53:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2fH5-0002Vj-J8; Wed, 29 Feb 2012 08:52:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2fH4-0002VT-FU
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 08:52:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330505551!16382331!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17722 invoked from network); 29 Feb 2012 08:52:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 08:52:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 08:52:31 +0000
Message-Id: <4F4DF58502000078000755C1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 08:53:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
In-Reply-To: <c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 >>> On 28.02.12 at 22:56, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> @@ -300,6 +301,91 @@ static unsigned long init_node_heap(int 
>      return needed;
>  }
>  
> +/* Default to 64 MiB */
> +#define DEFAULT_LOW_MEM_VIRQ    (((paddr_t) 64)   << 20)
> +#define MAX_LOW_MEM_VIRQ        (((paddr_t) 1024) << 20)
> +
> +static paddr_t __read_mostly opt_low_mem_virq = DEFAULT_LOW_MEM_VIRQ;
> +size_param("low_mem_virq_limit", opt_low_mem_virq);
> +
> +/* Thresholds to control hysteresis. In pages */
> +/* When memory grows above this threshold, reset hysteresis.
> + * -1 initially to not reset until at least one virq issued. */
> +static unsigned long low_mem_virq_high      = -1UL;
> +/* Threshold at which we issue virq */
> +static unsigned long low_mem_virq_th        = 0;
> +/* Original threshold after all checks completed */
> +static unsigned long low_mem_virq_orig      = 0;
> +/* Order for current threshold */
> +static unsigned int  low_mem_virq_th_order  = 0;
> +
> +/* Perform bootstrapping checks and set bounds */
> +static void __init setup_low_mem_virq(void)
> +{
> +    unsigned int order;
> +    paddr_t threshold;
> +
> +    /* Dom0 has already been allocated by now. So check we won't 
> +     * be complaining immediately with whatever's left of the heap. */
> +    threshold = min(opt_low_mem_virq, 
> +                    ((paddr_t) total_avail_pages) << PAGE_SHIFT);
> +
> +    /* Then, cap to some predefined maximum */
> +    threshold = min(threshold, MAX_LOW_MEM_VIRQ);
> +
> +    /* If the user specified no knob, and we are at the current available 
> +     * level, halve the threshold. */
> +    if ( (opt_low_mem_virq == DEFAULT_LOW_MEM_VIRQ)

This condition being true is not an indication that there was nothing
specified on the command line.

> +            && (threshold == (((paddr_t) total_avail_pages) << PAGE_SHIFT)) )
> +        threshold >>= 1;
> +
> +    /* Threshold bytes -> pages */
> +    low_mem_virq_th = threshold >> PAGE_SHIFT;
> +
> +    /* Next, round the threshold down to the next order */
> +    order = get_order_from_pages(low_mem_virq_th);

This has undefined (and unexpected by you) behavior if
low_mem_virq_th is zero (which I would think ought to mean "disable
this whole logic").

> +    if ( (1UL << order) > low_mem_virq_th ) 
> +        order--;
> +
> +    /* Set bounds, ready to go */
> +    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",
> +            low_mem_virq_th);
> +}
> +
> +static void check_low_mem_virq(void)
> +{
> +    if ( total_avail_pages <= low_mem_virq_th )
> +    {
> +        send_global_virq(VIRQ_ENOMEM);
> +
> +        /* Update thresholds. Next warning will be when we drop below
> +         * next order. However, we wait until we grow beyond one
> +         * order above us to complain again at the current order */
> +        low_mem_virq_high   = 1UL << (low_mem_virq_th_order + 1);
> +        if ( low_mem_virq_th_order > 0 )
> +            low_mem_virq_th_order--;
> +        low_mem_virq_th     = 1UL << low_mem_virq_th_order;
> +        return;
> +    }
> +
> +    if ( total_avail_pages >= low_mem_virq_high )
> +    {
> +        /* Reset hysteresis. Bring threshold up one order.
> +         * If we are back where originally set, set high
> +         * threshold to -1 to avoid further growth of 
> +         * virq threshold. */
> +        low_mem_virq_th_order++;
> +        low_mem_virq_th = 1UL << low_mem_virq_th_order;
> +        if ( low_mem_virq_th == low_mem_virq_orig )
> +            low_mem_virq_high = -1UL;
> +        else
> +            low_mem_virq_high = 1UL << (low_mem_virq_th_order + 2);
> +    }
> +}
> +
>  /* Allocate 2^@order contiguous pages. */
>  static struct page_info *alloc_heap_pages(
>      unsigned int zone_lo, unsigned int zone_hi,

Also, could you please check your patches for not introducing trailing
whitespace?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08: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 1S2fIG-0002aW-1i; Wed, 29 Feb 2012 08:53: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 1S2fIE-0002aK-3p
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 08:53:50 +0000
Received: from [85.158.139.83:52380] by server-1.bemta-5.messagelabs.com id
	DC/8E-28458-D97ED4F4; Wed, 29 Feb 2012 08:53:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330505628!17185128!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11349 invoked from network); 29 Feb 2012 08:53:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 08:53:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 08:53:47 +0000
Message-Id: <4F4DF5D102000078000755C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 08:54:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
	<7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
In-Reply-To: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.12 at 00:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Or maybe Jan's recent work has eliminated all but the corner
> cases of order>0 allocations?  (/me crosses fingers)

I'm unaware of remaining violators of this, but I'm also not constantly
monitoring.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08: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 1S2fIG-0002aW-1i; Wed, 29 Feb 2012 08:53: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 1S2fIE-0002aK-3p
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 08:53:50 +0000
Received: from [85.158.139.83:52380] by server-1.bemta-5.messagelabs.com id
	DC/8E-28458-D97ED4F4; Wed, 29 Feb 2012 08:53:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1330505628!17185128!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11349 invoked from network); 29 Feb 2012 08:53:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 08:53:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 08:53:47 +0000
Message-Id: <4F4DF5D102000078000755C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 08:54:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<c44e9fe0ecca69b516d8.1330466176@xdev.gridcentric.ca>
	<7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
In-Reply-To: <7e6a9e72-e028-4f3e-a474-76be9babe3c5@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.12 at 00:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Or maybe Jan's recent work has eliminated all but the corner
> cases of order>0 allocations?  (/me crosses fingers)

I'm unaware of remaining violators of this, but I'm also not constantly
monitoring.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:57:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08: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 1S2fL4-0002nm-Jj; Wed, 29 Feb 2012 08:56:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2fL3-0002nI-2n
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 08:56:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330505798!16954023!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19309 invoked from network); 29 Feb 2012 08:56:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 08:56:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 08:56:37 +0000
Message-Id: <4F4DF67A02000078000755DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 08:57:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<4300b0d765753dc359bb.1330466177@xdev.gridcentric.ca>
In-Reply-To: <4300b0d765753dc359bb.1330466177@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] Lowmemd: Simple demo code to show
 use of VIRQ_ENOMEM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 22:56, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:

Thanks for contributing this.

> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_xeninclude)
>  HDRS     = $(wildcard *.h)
>  
>  TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat 
> xenlockprof xenwatchdogd
> -TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash
> +TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash lowmemd

If this should get committed (which I'm in favor of at least as a first
step, to get more advanced over time if needed), we would certainly
want to prefix the binary with xen- (since that's what it's for, it's not
dealing with domain side low memory conditions).

Jan

>  TARGETS-$(CONFIG_MIGRATE) += xen-hptool
>  TARGETS := $(TARGETS-y)
>  
> @@ -21,7 +21,7 @@ INSTALL_BIN-y := xencons
>  INSTALL_BIN-$(CONFIG_X86) += xen-detect
>  INSTALL_BIN := $(INSTALL_BIN-y)
>  
> -INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm 
> xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd 
> xen-ringwatch
> +INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm 
> xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd 
> xen-ringwatch lowmemd
>  INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash
>  INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
>  INSTALL_SBIN := $(INSTALL_SBIN-y)
> @@ -70,6 +70,9 @@ xen-hptool: xen-hptool.o
>  xenwatchdogd: xenwatchdogd.o
>  	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
>  
> +lowmemd: lowmemd.o
> +	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) 
> $(APPEND_LDFLAGS)
> +
>  gtraceview: gtraceview.o
>  	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
>  
> diff -r c44e9fe0ecca -r 4300b0d76575 tools/misc/lowmemd.c
> --- /dev/null
> +++ b/tools/misc/lowmemd.c
> @@ -0,0 +1,148 @@
> +/*
> + * lowmemd: demo VIRQ_ENOMEM
> + * Andres Lagar-Cavilla (GridCentric Inc.)
> + */
> +
> +#include <stdio.h>
> +#include <xenctrl.h>
> +#include <xs.h>
> +#include <stdlib.h>
> +#include <string.h>
> +
> +static evtchn_port_t virq_port      = -1;
> +static xc_evtchn *xce_handle        = NULL;
> +static xc_interface *xch            = NULL;
> +static struct xs_handle *xs_handle  = NULL;
> +
> +void cleanup(void)
> +{
> +    if (virq_port > -1)
> +        xc_evtchn_unbind(xce_handle, virq_port);
> +    if (xce_handle)
> +        xc_evtchn_close(xce_handle);
> +    if (xch)
> +        xc_interface_close(xch);
> +    if (xs_handle)
> +        xs_daemon_close(xs_handle);
> +}
> +
> +/* Never shrink dom0 below 1 GiB */
> +#define DOM0_FLOOR  (1 << 30)
> +#define DOM0_FLOOR_PG   ((DOM0_FLOOR) >> 12)
> +
> +/* Act if free memory is less than 92 MiB */
> +#define THRESHOLD   (92 << 20)
> +#define THRESHOLD_PG    ((THRESHOLD) >> 12)
> +
> +#define BUFSZ 512
> +void handle_low_mem(void)
> +{
> +    xc_dominfo_t  dom0_info;
> +    xc_physinfo_t info;
> +    unsigned long long free_pages, dom0_pages, diff, dom0_target;
> +    char data[BUFSZ], error[BUFSZ];
> +
> +    if (xc_physinfo(xch, &info) < 0)
> +    {
> +        perror("Getting physinfo failed");
> +        return;
> +    }
> +
> +    free_pages = (unsigned long long) info.free_pages;
> +    printf("Available free pages: 0x%llx:%llux\n",
> +            free_pages, free_pages);
> +
> +    /* Don't do anything if we have more than the threshold free */
> +    if ( free_pages >= THRESHOLD_PG )
> +        return;
> +    diff = THRESHOLD_PG - free_pages; 
> +
> +    if (xc_domain_getinfo(xch, 0, 1, &dom0_info) < 1)
> +    {
> +        perror("Failed to get dom0 info");
> +        return;
> +    }
> +
> +    dom0_pages = (unsigned long long) dom0_info.nr_pages;
> +    printf("Dom0 pages: 0x%llx:%llu\n", dom0_pages, dom0_pages);
> +    dom0_target = dom0_pages - diff;
> +    if (dom0_target <= DOM0_FLOOR_PG)
> +        return;
> +
> +    printf("Shooting for dom0 target 0x%llx:%llu\n", 
> +            dom0_target, dom0_target);
> +
> +    snprintf(data, BUFSZ, "%llu", dom0_target);
> +    if (!xs_write(xs_handle, XBT_NULL, 
> +            "/local/domain/0/memory/target", data, strlen(data)))
> +    {
> +        snprintf(error, BUFSZ,"Failed to write target %s to xenstore", 
> data);
> +        perror(error);
> +    }
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +    int rc;
> +
> +    atexit(cleanup);
> +
> +	xch = xc_interface_open(NULL, NULL, 0);
> +	if (xch == NULL)
> +    {
> +        perror("Failed to open xc interface");
> +        return 1;
> +    }
> +
> +	xce_handle = xc_evtchn_open(NULL, 0);
> +	if (xce_handle == NULL)
> +    {
> +        perror("Failed to open evtchn device");
> +        return 2;
> +    }
> +
> +    xs_handle = xs_daemon_open();
> +    if (xs_handle == NULL)
> +    {
> +        perror("Failed to open xenstore connection");
> +        return 3;
> +    }
> +
> +	if ((rc = xc_evtchn_bind_virq(xce_handle, VIRQ_ENOMEM)) == -1)
> +    {
> +        perror("Failed to bind to domain exception virq port");
> +        return 4;
> +    }
> +
> +    virq_port = rc;
> +    
> +    while(1)
> +    {
> +        evtchn_port_t port;
> +
> +        if ((port = xc_evtchn_pending(xce_handle)) == -1)
> +        {
> +            perror("Failed to listen for pending event channel");
> +            return 5;
> +        }
> +
> +        if (port != virq_port)
> +        {
> +            char data[BUFSZ];
> +            snprintf(data, BUFSZ, "Wrong port, got %d expected %d", port, 
> virq_port);
> +            perror(data);
> +            return 6;
> +        }
> +
> +        if (xc_evtchn_unmask(xce_handle, port) == -1)
> +        {
> +            perror("Failed to unmask port");
> +            return 7;
> +        }
> +
> +        printf("Got a virq kick, time to get work\n");
> +        handle_low_mem();
> +    }
> +
> +    return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 08:57:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 08: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 1S2fL4-0002nm-Jj; Wed, 29 Feb 2012 08:56:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2fL3-0002nI-2n
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 08:56:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330505798!16954023!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19309 invoked from network); 29 Feb 2012 08:56:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 08:56:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 08:56:37 +0000
Message-Id: <4F4DF67A02000078000755DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 08:57:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1330466175@xdev.gridcentric.ca>
	<4300b0d765753dc359bb.1330466177@xdev.gridcentric.ca>
In-Reply-To: <4300b0d765753dc359bb.1330466177@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 2] Lowmemd: Simple demo code to show
 use of VIRQ_ENOMEM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.02.12 at 22:56, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:

Thanks for contributing this.

> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_xeninclude)
>  HDRS     = $(wildcard *.h)
>  
>  TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat 
> xenlockprof xenwatchdogd
> -TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash
> +TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash lowmemd

If this should get committed (which I'm in favor of at least as a first
step, to get more advanced over time if needed), we would certainly
want to prefix the binary with xen- (since that's what it's for, it's not
dealing with domain side low memory conditions).

Jan

>  TARGETS-$(CONFIG_MIGRATE) += xen-hptool
>  TARGETS := $(TARGETS-y)
>  
> @@ -21,7 +21,7 @@ INSTALL_BIN-y := xencons
>  INSTALL_BIN-$(CONFIG_X86) += xen-detect
>  INSTALL_BIN := $(INSTALL_BIN-y)
>  
> -INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm 
> xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd 
> xen-ringwatch
> +INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm 
> xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd 
> xen-ringwatch lowmemd
>  INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash
>  INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
>  INSTALL_SBIN := $(INSTALL_SBIN-y)
> @@ -70,6 +70,9 @@ xen-hptool: xen-hptool.o
>  xenwatchdogd: xenwatchdogd.o
>  	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
>  
> +lowmemd: lowmemd.o
> +	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) 
> $(APPEND_LDFLAGS)
> +
>  gtraceview: gtraceview.o
>  	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
>  
> diff -r c44e9fe0ecca -r 4300b0d76575 tools/misc/lowmemd.c
> --- /dev/null
> +++ b/tools/misc/lowmemd.c
> @@ -0,0 +1,148 @@
> +/*
> + * lowmemd: demo VIRQ_ENOMEM
> + * Andres Lagar-Cavilla (GridCentric Inc.)
> + */
> +
> +#include <stdio.h>
> +#include <xenctrl.h>
> +#include <xs.h>
> +#include <stdlib.h>
> +#include <string.h>
> +
> +static evtchn_port_t virq_port      = -1;
> +static xc_evtchn *xce_handle        = NULL;
> +static xc_interface *xch            = NULL;
> +static struct xs_handle *xs_handle  = NULL;
> +
> +void cleanup(void)
> +{
> +    if (virq_port > -1)
> +        xc_evtchn_unbind(xce_handle, virq_port);
> +    if (xce_handle)
> +        xc_evtchn_close(xce_handle);
> +    if (xch)
> +        xc_interface_close(xch);
> +    if (xs_handle)
> +        xs_daemon_close(xs_handle);
> +}
> +
> +/* Never shrink dom0 below 1 GiB */
> +#define DOM0_FLOOR  (1 << 30)
> +#define DOM0_FLOOR_PG   ((DOM0_FLOOR) >> 12)
> +
> +/* Act if free memory is less than 92 MiB */
> +#define THRESHOLD   (92 << 20)
> +#define THRESHOLD_PG    ((THRESHOLD) >> 12)
> +
> +#define BUFSZ 512
> +void handle_low_mem(void)
> +{
> +    xc_dominfo_t  dom0_info;
> +    xc_physinfo_t info;
> +    unsigned long long free_pages, dom0_pages, diff, dom0_target;
> +    char data[BUFSZ], error[BUFSZ];
> +
> +    if (xc_physinfo(xch, &info) < 0)
> +    {
> +        perror("Getting physinfo failed");
> +        return;
> +    }
> +
> +    free_pages = (unsigned long long) info.free_pages;
> +    printf("Available free pages: 0x%llx:%llux\n",
> +            free_pages, free_pages);
> +
> +    /* Don't do anything if we have more than the threshold free */
> +    if ( free_pages >= THRESHOLD_PG )
> +        return;
> +    diff = THRESHOLD_PG - free_pages; 
> +
> +    if (xc_domain_getinfo(xch, 0, 1, &dom0_info) < 1)
> +    {
> +        perror("Failed to get dom0 info");
> +        return;
> +    }
> +
> +    dom0_pages = (unsigned long long) dom0_info.nr_pages;
> +    printf("Dom0 pages: 0x%llx:%llu\n", dom0_pages, dom0_pages);
> +    dom0_target = dom0_pages - diff;
> +    if (dom0_target <= DOM0_FLOOR_PG)
> +        return;
> +
> +    printf("Shooting for dom0 target 0x%llx:%llu\n", 
> +            dom0_target, dom0_target);
> +
> +    snprintf(data, BUFSZ, "%llu", dom0_target);
> +    if (!xs_write(xs_handle, XBT_NULL, 
> +            "/local/domain/0/memory/target", data, strlen(data)))
> +    {
> +        snprintf(error, BUFSZ,"Failed to write target %s to xenstore", 
> data);
> +        perror(error);
> +    }
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +    int rc;
> +
> +    atexit(cleanup);
> +
> +	xch = xc_interface_open(NULL, NULL, 0);
> +	if (xch == NULL)
> +    {
> +        perror("Failed to open xc interface");
> +        return 1;
> +    }
> +
> +	xce_handle = xc_evtchn_open(NULL, 0);
> +	if (xce_handle == NULL)
> +    {
> +        perror("Failed to open evtchn device");
> +        return 2;
> +    }
> +
> +    xs_handle = xs_daemon_open();
> +    if (xs_handle == NULL)
> +    {
> +        perror("Failed to open xenstore connection");
> +        return 3;
> +    }
> +
> +	if ((rc = xc_evtchn_bind_virq(xce_handle, VIRQ_ENOMEM)) == -1)
> +    {
> +        perror("Failed to bind to domain exception virq port");
> +        return 4;
> +    }
> +
> +    virq_port = rc;
> +    
> +    while(1)
> +    {
> +        evtchn_port_t port;
> +
> +        if ((port = xc_evtchn_pending(xce_handle)) == -1)
> +        {
> +            perror("Failed to listen for pending event channel");
> +            return 5;
> +        }
> +
> +        if (port != virq_port)
> +        {
> +            char data[BUFSZ];
> +            snprintf(data, BUFSZ, "Wrong port, got %d expected %d", port, 
> virq_port);
> +            perror(data);
> +            return 6;
> +        }
> +
> +        if (xc_evtchn_unmask(xce_handle, port) == -1)
> +        {
> +            perror("Failed to unmask port");
> +            return 7;
> +        }
> +
> +        printf("Got a virq kick, time to get work\n");
> +        handle_low_mem();
> +    }
> +
> +    return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:12:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09: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 1S2fZU-00039b-6p; Wed, 29 Feb 2012 09:11:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2fZS-00039W-2f
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 09:11:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330506691!3300358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18094 invoked from network); 29 Feb 2012 09:11:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 09:11:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 09:11:31 +0000
Message-Id: <4F4DF9F902000078000755EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 09:12:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <boris.ostrovsky@amd.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
In-Reply-To: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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 28.02.12 at 23:08, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
>  
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +

If you're concerned about the placement of this (the change being
unrelated to what your patch is aiming it anyway), then you should
- explain why
- move the declaration of mwait_ptr also into the if() scope

>          /*
>           * Cache must be flushed as the last operation before sleeping.
>           * Otherwise, CPU may still hold dirty data, breaking cache coherency,
> @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    } 
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();	
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }

You will need to eliminate the reservations of the Intel folks for this
to be accepted, I'm afraid, or make this AMD specific (provided the
issues pointed out by them don't affect AMD systems).

Jan

>      }
>  
>  default_halt:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:12:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09: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 1S2fZU-00039b-6p; Wed, 29 Feb 2012 09:11:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2fZS-00039W-2f
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 09:11:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1330506691!3300358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18094 invoked from network); 29 Feb 2012 09:11:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 09:11:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 09:11:31 +0000
Message-Id: <4F4DF9F902000078000755EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 09:12:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <boris.ostrovsky@amd.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
In-Reply-To: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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 28.02.12 at 23:08, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>      if ( (cx = &power->states[power->count-1]) == NULL )
>          goto default_halt;
>  
> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> -
>      if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>      {
> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
> +

If you're concerned about the placement of this (the change being
unrelated to what your patch is aiming it anyway), then you should
- explain why
- move the declaration of mwait_ptr also into the if() scope

>          /*
>           * Cache must be flushed as the last operation before sleeping.
>           * Otherwise, CPU may still hold dirty data, breaking cache coherency,
> @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>              mb();
>              __mwait(cx->address, 0);
>          }
> +    } 
> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
> +    {
> +        /* Avoid references to shared data after the cache flush */
> +        u32 address = cx->address;
> +        u32 pmtmr_ioport_local = pmtmr_ioport;
> +
> +        wbinvd();	
> +
> +        while ( 1 )
> +        {
> +            inb(address);
> +            inl(pmtmr_ioport_local);
> +        }

You will need to eliminate the reservations of the Intel folks for this
to be accepted, I'm afraid, or make this AMD specific (provided the
issues pointed out by them don't affect AMD systems).

Jan

>      }
>  
>  default_halt:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09: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 1S2fuE-0003fs-Sj; Wed, 29 Feb 2012 09:33:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1S2fuD-0003ff-Cs
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 09:33:05 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330507922!51278267!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23452 invoked from network); 29 Feb 2012 09:32:02 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 09:32:02 -0000
Received: by bkcjg9 with SMTP id jg9so3296990bkc.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 01:32:58 -0800 (PST)
Received-SPF: pass (google.com: domain of janez3k@gmail.com designates
	10.204.9.205 as permitted sender) client-ip=10.204.9.205; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of janez3k@gmail.com
	designates 10.204.9.205 as permitted sender)
	smtp.mail=janez3k@gmail.com;
	dkim=pass header.i=janez3k@gmail.com
Received: from mr.google.com ([10.204.9.205])
	by 10.204.9.205 with SMTP id m13mr11273545bkm.68.1330507978386
	(num_hops = 1); Wed, 29 Feb 2012 01:32:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=klaTwJ1zqWz0B8A0TCSSjD+RHZiFtRxAGpb34Hk+5D8=;
	b=BCsNTfmN9DT6ooetDTFafZXX/tCzk6Id0AewgHEL+hpuHzlFjMq5hwX0XGO3sB8YZb
	lOD3FD7e+btgRKiO970codlHMGTHgCn0AxLHr0++r6rNmvSJEDOL4HDGvEEMdTQ1C4DR
	RaBEhQBYVRN6rwAjNa4qSUi1pub0s+j4fs7n8=
MIME-Version: 1.0
Received: by 10.204.9.205 with SMTP id m13mr9150626bkm.68.1330507978306; Wed,
	29 Feb 2012 01:32:58 -0800 (PST)
Received: by 10.204.168.207 with HTTP; Wed, 29 Feb 2012 01:32:58 -0800 (PST)
In-Reply-To: <CACC+8CQdicMj=CnRsi3HXOhxhBuejyD1-QngFEz7R6VBKW+brA@mail.gmail.com>
References: <CACC+8CQdicMj=CnRsi3HXOhxhBuejyD1-QngFEz7R6VBKW+brA@mail.gmail.com>
Date: Wed, 29 Feb 2012 10:32:58 +0100
Message-ID: <CACC+8CRaMfCqAOOMcVtiQZt4cu+Z+Qpg+GpJPC9KaZbwNgGL4g@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0980507053549566151=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0980507053549566151==
Content-Type: multipart/alternative; boundary=0015175caebe6af4d104ba170759

--0015175caebe6af4d104ba170759
Content-Type: text/plain; charset=ISO-8859-1

Hi,

is there something wrong with xen git?
.......
+ test -d git://xenbits.xensource.com/qemu-xen-unstable.git
+ export GIT=git
+ GIT=git
+ /root/XEN_4_2/xen-unstable.hg-rev-24888/tools/../scripts/git-checkout.sh
git://xenbits.xensource.com/qemu-xen-unstable.git128de2549c5f24e4a437b86bd2e46f023976d50a
qemu-xen-traditional-dir
Cloning into qemu-xen-traditional-dir-remote.tmp...
fatal: read error: Connection reset by peer
make[1]: *** [qemu-xen-traditional-dir-find] Error 128
make[1]: Leaving directory `/root/XEN_4_2/xen-unstable.hg-rev-24888/tools'
make: *** [tools/qemu-xen-traditional-dir] Error 2


Best Regards,
Kristijan Lecnik

--0015175caebe6af4d104ba170759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><div class=3D"gmail_quote"><br>is there something wrong with xen git=
?<br>.......<br>+ test -d git://<a href=3D"http://xenbits.xensource.com/qem=
u-xen-unstable.git" target=3D"_blank">xenbits.xensource.com/qemu-xen-unstab=
le.git</a><br>
+ export GIT=3Dgit<br>+ GIT=3Dgit<br>
+ /root/XEN_4_2/xen-unstable.hg-rev-24888/tools/../scripts/git-checkout.sh =
git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" target=
=3D"_blank">xenbits.xensource.com/qemu-xen-unstable.git</a> 128de2549c5f24e=
4a437b86bd2e46f023976d50a qemu-xen-traditional-dir<br>

Cloning into qemu-xen-traditional-dir-remote.tmp...<br>fatal: read error: C=
onnection reset by peer<br>make[1]: *** [qemu-xen-traditional-dir-find] Err=
or 128<br>make[1]: Leaving directory `/root/XEN_4_2/xen-unstable.hg-rev-248=
88/tools&#39;<br>

make: *** [tools/qemu-xen-traditional-dir] Error 2<br><br><br>Best Regards,=
<br>Kristijan Lecnik<br><br>
</div><br>

--0015175caebe6af4d104ba170759--


--===============0980507053549566151==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0980507053549566151==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 09:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09: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 1S2fuE-0003fs-Sj; Wed, 29 Feb 2012 09:33:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <janez3k@gmail.com>) id 1S2fuD-0003ff-Cs
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 09:33:05 +0000
X-Env-Sender: janez3k@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330507922!51278267!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23452 invoked from network); 29 Feb 2012 09:32:02 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 09:32:02 -0000
Received: by bkcjg9 with SMTP id jg9so3296990bkc.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 01:32:58 -0800 (PST)
Received-SPF: pass (google.com: domain of janez3k@gmail.com designates
	10.204.9.205 as permitted sender) client-ip=10.204.9.205; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of janez3k@gmail.com
	designates 10.204.9.205 as permitted sender)
	smtp.mail=janez3k@gmail.com;
	dkim=pass header.i=janez3k@gmail.com
Received: from mr.google.com ([10.204.9.205])
	by 10.204.9.205 with SMTP id m13mr11273545bkm.68.1330507978386
	(num_hops = 1); Wed, 29 Feb 2012 01:32:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=klaTwJ1zqWz0B8A0TCSSjD+RHZiFtRxAGpb34Hk+5D8=;
	b=BCsNTfmN9DT6ooetDTFafZXX/tCzk6Id0AewgHEL+hpuHzlFjMq5hwX0XGO3sB8YZb
	lOD3FD7e+btgRKiO970codlHMGTHgCn0AxLHr0++r6rNmvSJEDOL4HDGvEEMdTQ1C4DR
	RaBEhQBYVRN6rwAjNa4qSUi1pub0s+j4fs7n8=
MIME-Version: 1.0
Received: by 10.204.9.205 with SMTP id m13mr9150626bkm.68.1330507978306; Wed,
	29 Feb 2012 01:32:58 -0800 (PST)
Received: by 10.204.168.207 with HTTP; Wed, 29 Feb 2012 01:32:58 -0800 (PST)
In-Reply-To: <CACC+8CQdicMj=CnRsi3HXOhxhBuejyD1-QngFEz7R6VBKW+brA@mail.gmail.com>
References: <CACC+8CQdicMj=CnRsi3HXOhxhBuejyD1-QngFEz7R6VBKW+brA@mail.gmail.com>
Date: Wed, 29 Feb 2012 10:32:58 +0100
Message-ID: <CACC+8CRaMfCqAOOMcVtiQZt4cu+Z+Qpg+GpJPC9KaZbwNgGL4g@mail.gmail.com>
From: =?UTF-8?Q?Kristijan_Le=C4=8Dnik?= <janez3k@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0980507053549566151=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0980507053549566151==
Content-Type: multipart/alternative; boundary=0015175caebe6af4d104ba170759

--0015175caebe6af4d104ba170759
Content-Type: text/plain; charset=ISO-8859-1

Hi,

is there something wrong with xen git?
.......
+ test -d git://xenbits.xensource.com/qemu-xen-unstable.git
+ export GIT=git
+ GIT=git
+ /root/XEN_4_2/xen-unstable.hg-rev-24888/tools/../scripts/git-checkout.sh
git://xenbits.xensource.com/qemu-xen-unstable.git128de2549c5f24e4a437b86bd2e46f023976d50a
qemu-xen-traditional-dir
Cloning into qemu-xen-traditional-dir-remote.tmp...
fatal: read error: Connection reset by peer
make[1]: *** [qemu-xen-traditional-dir-find] Error 128
make[1]: Leaving directory `/root/XEN_4_2/xen-unstable.hg-rev-24888/tools'
make: *** [tools/qemu-xen-traditional-dir] Error 2


Best Regards,
Kristijan Lecnik

--0015175caebe6af4d104ba170759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><div class=3D"gmail_quote"><br>is there something wrong with xen git=
?<br>.......<br>+ test -d git://<a href=3D"http://xenbits.xensource.com/qem=
u-xen-unstable.git" target=3D"_blank">xenbits.xensource.com/qemu-xen-unstab=
le.git</a><br>
+ export GIT=3Dgit<br>+ GIT=3Dgit<br>
+ /root/XEN_4_2/xen-unstable.hg-rev-24888/tools/../scripts/git-checkout.sh =
git://<a href=3D"http://xenbits.xensource.com/qemu-xen-unstable.git" target=
=3D"_blank">xenbits.xensource.com/qemu-xen-unstable.git</a> 128de2549c5f24e=
4a437b86bd2e46f023976d50a qemu-xen-traditional-dir<br>

Cloning into qemu-xen-traditional-dir-remote.tmp...<br>fatal: read error: C=
onnection reset by peer<br>make[1]: *** [qemu-xen-traditional-dir-find] Err=
or 128<br>make[1]: Leaving directory `/root/XEN_4_2/xen-unstable.hg-rev-248=
88/tools&#39;<br>

make: *** [tools/qemu-xen-traditional-dir] Error 2<br><br><br>Best Regards,=
<br>Kristijan Lecnik<br><br>
</div><br>

--0015175caebe6af4d104ba170759--


--===============0980507053549566151==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0980507053549566151==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 09:52:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gCi-0004JH-9j; Wed, 29 Feb 2012 09:52:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1S2gCh-0004J9-4C
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 09:52:11 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330509124!16395287!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMjYzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20540 invoked from network); 29 Feb 2012 09:52:05 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 09:52:05 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=Y+ZnYAOEEKOjpbD4ycr4l9KzK0WvqpAaQFgyqzAleAmJFRN6yK+bD7aQ
	0GB04jH0hecMo0AP6pHuxv4/XvFA1YWlRBTiQX5KYxWevRHoy37J4+EeY
	g4EFmtdC3VC0XaBJVmwOl9Le1oK06lX/uzcLFLTSv04+3nGMAPjXAmk2z
	no8nBEHVjojgJjyovkMmTxZcwYt34Q+0Xm4pr3V1bHdpIYLj3nTBM66SH
	bMt5KoeYIKeW1RzTEri/+bJJMd9L7;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1330509125; x=1362045125;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=+02Gy3t1sYggMkJd6c6b7YLtXak1YwoAzuOcyIwiiu8=;
	b=ickRMqtaKRtXNMlU8zyP8c2lByt3iL8c3/W/VnTEUQwaFDmF9ttoMGN+
	iWyVE+vcuJbcQv7awGhG23VuVVJwe4krQrsrpdDQrf2CWW5FBLicYKPvL
	rVIg3p63j66KD7ohImh5hzo4n4KSGFQmn+D66gzy+Y7+zzJ3waEiEIp3p
	5IZ2SPCE1unch/oaRSCjpNdSQAKNMlA8qoarwji1ceqcKnbEwhS1YwJCy
	QBKnVML19zo02W61SAVWjrEMJdS+G;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="103346163"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 29 Feb 2012 10:52:04 +0100
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="129916526"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 29 Feb 2012 10:52:04 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 5A3D1960FD6
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 10:52:04 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 29 Feb 2012 10:52:04 +0100
Message-ID: <1728056.Ypgg7efjbu@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] vpmu: cleanup structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

a small cleanup of vpmu structures:

- struct msr_load_store_entry is unused
- struct pmumsr is only used in the vmx part

Dietmar.


Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


# HG changeset patch
# Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9

diff -r a7bacdc5449a xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 29 10:42:56 2012 +0100
@@ -112,6 +112,11 @@ u32 core2_ctrls_msr[] = {
     MSR_IA32_PEBS_ENABLE,
     MSR_IA32_DS_AREA};
 
+struct pmumsr {
+    unsigned int num;
+    u32 *msr;
+};
+
 struct pmumsr core2_counters = {
     3,
     core2_counters_msr
diff -r a7bacdc5449a xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 29 10:42:56 2012 +0100
@@ -34,16 +34,6 @@
 #define MSR_TYPE_ARCH_COUNTER       3
 #define MSR_TYPE_ARCH_CTRL          4
 
-struct pmumsr {
-    unsigned int num;
-    u32 *msr;
-};
-
-struct msr_load_store_entry {
-    u32 msr_index;
-    u32 msr_reserved;
-    u64 msr_data;
-};
 
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:52:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gCi-0004JH-9j; Wed, 29 Feb 2012 09:52:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1S2gCh-0004J9-4C
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 09:52:11 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1330509124!16395287!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMjYzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20540 invoked from network); 29 Feb 2012 09:52:05 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 09:52:05 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=Y+ZnYAOEEKOjpbD4ycr4l9KzK0WvqpAaQFgyqzAleAmJFRN6yK+bD7aQ
	0GB04jH0hecMo0AP6pHuxv4/XvFA1YWlRBTiQX5KYxWevRHoy37J4+EeY
	g4EFmtdC3VC0XaBJVmwOl9Le1oK06lX/uzcLFLTSv04+3nGMAPjXAmk2z
	no8nBEHVjojgJjyovkMmTxZcwYt34Q+0Xm4pr3V1bHdpIYLj3nTBM66SH
	bMt5KoeYIKeW1RzTEri/+bJJMd9L7;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1330509125; x=1362045125;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=+02Gy3t1sYggMkJd6c6b7YLtXak1YwoAzuOcyIwiiu8=;
	b=ickRMqtaKRtXNMlU8zyP8c2lByt3iL8c3/W/VnTEUQwaFDmF9ttoMGN+
	iWyVE+vcuJbcQv7awGhG23VuVVJwe4krQrsrpdDQrf2CWW5FBLicYKPvL
	rVIg3p63j66KD7ohImh5hzo4n4KSGFQmn+D66gzy+Y7+zzJ3waEiEIp3p
	5IZ2SPCE1unch/oaRSCjpNdSQAKNMlA8qoarwji1ceqcKnbEwhS1YwJCy
	QBKnVML19zo02W61SAVWjrEMJdS+G;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="103346163"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 29 Feb 2012 10:52:04 +0100
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="129916526"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 29 Feb 2012 10:52:04 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 5A3D1960FD6
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 10:52:04 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 29 Feb 2012 10:52:04 +0100
Message-ID: <1728056.Ypgg7efjbu@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] vpmu: cleanup structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

a small cleanup of vpmu structures:

- struct msr_load_store_entry is unused
- struct pmumsr is only used in the vmx part

Dietmar.


Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>


# HG changeset patch
# Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9

diff -r a7bacdc5449a xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 29 10:42:56 2012 +0100
@@ -112,6 +112,11 @@ u32 core2_ctrls_msr[] = {
     MSR_IA32_PEBS_ENABLE,
     MSR_IA32_DS_AREA};
 
+struct pmumsr {
+    unsigned int num;
+    u32 *msr;
+};
+
 struct pmumsr core2_counters = {
     3,
     core2_counters_msr
diff -r a7bacdc5449a xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 29 10:42:56 2012 +0100
@@ -34,16 +34,6 @@
 #define MSR_TYPE_ARCH_COUNTER       3
 #define MSR_TYPE_ARCH_CTRL          4
 
-struct pmumsr {
-    unsigned int num;
-    u32 *msr;
-};
-
-struct msr_load_store_entry {
-    u32 msr_index;
-    u32 msr_reserved;
-    u64 msr_data;
-};
 
 /* Arch specific operations shared by all vpmus */
 struct arch_vpmu_ops {

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:53:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gDq-0004NN-T3; Wed, 29 Feb 2012 09:53: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 1S2gDp-0004ND-Je
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 09:53:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330509175!65587507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 29 Feb 2012 09:52:56 -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;
	29 Feb 2012 09:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11003428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:53:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 09:53:20 +0000
Message-ID: <1330509198.4270.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Date: Wed, 29 Feb 2012 09:53:18 +0000
In-Reply-To: <4F4D650E.3010909@abpni.co.uk>
References: <4F4D650E.3010909@abpni.co.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "keith.coleman@n2servers.com" <keith.coleman@n2servers.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 23:36 +0000, Jonathan Tripathy wrote:
> Hi Keith,

On a related note it would be very useful if
http://wiki.xen.org/wiki/Security_Announcements could be updated when
security fixes corresponding to Xen.org security vulnerability
disclosures are added to the 3.4 branch. Keith, can you do that? If not
then if you drop me a line each time I'll take care of it for you.

> CVE-2011-2901:
> http://www.openwall.com/lists/oss-security/2011/09/02/2
> 
> The patch performs the following:
> -    (((unsigned long)(addr) < (1UL<<48)) || \
> +    (((unsigned long)(addr) < (1UL<<47)) || \
> 
> I see that the Xen security advisory says that only hypervisors 3.3 or
> earlier are affected. However, I note that in later versions of Xen,
> the line changed in the patch remains untouched. Any ideas why this is
> the case?

The problem has been fixed in xen-unstable. However only 3.3 and earlier
were actually vulnerable due to the issue and so it has not been
backported the stable branches.

[...]

I've left the others for Keith to comment on as 3.4 maintainer.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:53:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gDq-0004NN-T3; Wed, 29 Feb 2012 09:53: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 1S2gDp-0004ND-Je
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 09:53:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330509175!65587507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 29 Feb 2012 09:52:56 -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;
	29 Feb 2012 09:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11003428"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:53:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 09:53:20 +0000
Message-ID: <1330509198.4270.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Date: Wed, 29 Feb 2012 09:53:18 +0000
In-Reply-To: <4F4D650E.3010909@abpni.co.uk>
References: <4F4D650E.3010909@abpni.co.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "keith.coleman@n2servers.com" <keith.coleman@n2servers.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 3.4.x Backports
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 23:36 +0000, Jonathan Tripathy wrote:
> Hi Keith,

On a related note it would be very useful if
http://wiki.xen.org/wiki/Security_Announcements could be updated when
security fixes corresponding to Xen.org security vulnerability
disclosures are added to the 3.4 branch. Keith, can you do that? If not
then if you drop me a line each time I'll take care of it for you.

> CVE-2011-2901:
> http://www.openwall.com/lists/oss-security/2011/09/02/2
> 
> The patch performs the following:
> -    (((unsigned long)(addr) < (1UL<<48)) || \
> +    (((unsigned long)(addr) < (1UL<<47)) || \
> 
> I see that the Xen security advisory says that only hypervisors 3.3 or
> earlier are affected. However, I note that in later versions of Xen,
> the line changed in the patch remains untouched. Any ideas why this is
> the case?

The problem has been fixed in xen-unstable. However only 3.3 and earlier
were actually vulnerable due to the issue and so it has not been
backported the stable branches.

[...]

I've left the others for Keith to comment on as 3.4 maintainer.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:56:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gGX-0004Xv-EE; Wed, 29 Feb 2012 09:56:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2gGW-0004Xm-C7
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 09:56:08 +0000
Received: from [85.158.139.83:46276] by server-11.bemta-5.messagelabs.com id
	BC/B2-05465-736FD4F4; Wed, 29 Feb 2012 09:56:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330509366!5916735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11716 invoked from network); 29 Feb 2012 09:56:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 09:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11003525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:56:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 09:56:04 +0000
Message-ID: <1330509362.4270.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>, Peter Maydell
	<peter.maydell@linaro.org>
Date: Wed, 29 Feb 2012 09:56:02 +0000
In-Reply-To: <20120229093436.GA2077@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
	<20120229093436.GA2077@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:

> > I don't have a very strong opinion on which register we should use, but
> > I would like to avoid r7 if it is already actively used by gcc.
> 
> But there is no framepointer for Thumb-2 code (?)

Peter Maydell suggested there was:
> r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> makes it worth avoiding in this context.

Sounds like it might be a gcc-ism, possibly a non-default option?

Anyway, I think r12 will be fine for our purposes so the point is rather
moot.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 09:56:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 09:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gGX-0004Xv-EE; Wed, 29 Feb 2012 09:56:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2gGW-0004Xm-C7
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 09:56:08 +0000
Received: from [85.158.139.83:46276] by server-11.bemta-5.messagelabs.com id
	BC/B2-05465-736FD4F4; Wed, 29 Feb 2012 09:56:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330509366!5916735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11716 invoked from network); 29 Feb 2012 09:56:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 09:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11003525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:56:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 09:56:04 +0000
Message-ID: <1330509362.4270.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>, Peter Maydell
	<peter.maydell@linaro.org>
Date: Wed, 29 Feb 2012 09:56:02 +0000
In-Reply-To: <20120229093436.GA2077@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
	<20120229093436.GA2077@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:

> > I don't have a very strong opinion on which register we should use, but
> > I would like to avoid r7 if it is already actively used by gcc.
> 
> But there is no framepointer for Thumb-2 code (?)

Peter Maydell suggested there was:
> r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> makes it worth avoiding in this context.

Sounds like it might be a gcc-ism, possibly a non-default option?

Anyway, I think r12 will be fine for our purposes so the point is rather
moot.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:18:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:18:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gc2-0004tP-GX; Wed, 29 Feb 2012 10:18:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2gc1-0004tK-3f
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:18:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330510694!16062174!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16801 invoked from network); 29 Feb 2012 10:18:14 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 10:18:14 -0000
Received: by werm1 with SMTP id m1so3535144wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 02:18:14 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.87 as permitted sender) client-ip=10.216.134.87; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.87 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.87])
	by 10.216.134.87 with SMTP id r65mr12042007wei.46.1330510694474
	(num_hops = 1); Wed, 29 Feb 2012 02:18:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=kgUvQi1huu9vowETbHbzW83xU+6hJV67qnFKaONkSVs=;
	b=AXvi3PKNGwJw8B4wlCiEUrct+IXNe8C6suRbMoDGrRRN/+Te0i9MOSQFGOThoeAZmm
	CrUjNF9LxLVen9k37B6aBBxSHS7HFJxx+d9U4fi9KR3EJXA8czB6relOJaD/z1vtaBjK
	r7qCkoDrA1sqGc7IDZD/2IuHtiNUkQVUiDm1I=
MIME-Version: 1.0
Received: by 10.216.134.87 with SMTP id r65mr9617008wei.46.1330510694370; Wed,
	29 Feb 2012 02:18:14 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 02:18:14 -0800 (PST)
In-Reply-To: <1330459026.10008.57.camel@dagon.hellion.org.uk>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
Date: Wed, 29 Feb 2012 11:18:14 +0100
X-Google-Sender-Auth: WhUG7tO1vfd26zgzNbP2ME9imrg
Message-ID: <CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/28 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2012-02-28 at 17:51 +0000, Jeffrey Karrels wrote:
>
>> > Have you changed anything here or are you saying that a pristine Xen
>> > tree when built on CentOS installs 64 bit libraries to /usr/lib instead
>> > of /usr/lib64? If so please can you be precise about what tree you are
>> > running (e.g. the exact URL you cloned and which changeset you got) and
>> > steps you took to install (e.g. what patches did you apply, what
>> > commands did you type) and what exactly you saw (e.g. what was
>> > in /usr/lib and what was in /usr/lib64)
>>
>> #uname -a
>> Linux xenbuild2.cyberlab 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24
>> 02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
>>
>> #hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
>> #cd xen-unstable
>> #./configure --enable-xsm --libdir=/usr/lib64
>
> OK, so you are using something new enough to have the autoconf stuff --
> I think this is simply a bug in that. I've CC'd Roger.
>
> Ideally configure would auto-detect the right thing for the given system
> and so --libdir would not be required. This would certainly be n
> improvement over the pre-autoconf thing.

configure was not properly parsing the libdir path and always set it
to "lib", this is a fix:

8<--------------------------------------------

autoconf: fix libdir detection

If user specifies a libdir it is used, if no libdir is specified
configure checks if $prefix/lib64 is a directory and uses that, if not
lib is used.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 4758a7a94c15 tools/configure
--- a/tools/configure	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/configure	Wed Feb 22 06:31:53 2012 +0100
@@ -3845,7 +3845,6 @@ case $host_os in *\ *) host_os=`echo "$h



-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -6551,13 +6550,23 @@ else
 fi

 # Check library path
-if test -d "$prefix/lib64"; then :
-
-    LIB_PATH="lib64"
-
-else
-
-    LIB_PATH="lib"
+if test "\${exec_prefix}/lib" = "$libdir"; then :
+  if test "$prefix" = "NONE"; then :
+  prefix=$ac_default_prefix
+fi
+    if test -d "${prefix}/lib64"; then :
+
+        LIB_PATH="lib64"
+
+else
+
+        LIB_PATH="lib"
+
+fi
+
+else
+
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"

 fi

diff -r 4758a7a94c15 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/m4/default_lib.m4	Wed Feb 22 06:31:53 2012 +0100
@@ -1,8 +1,12 @@
 AC_DEFUN([AX_DEFAULT_LIB],
-[AS_IF([test -d "$prefix/lib64"], [
-    LIB_PATH="lib64"
-],[
-    LIB_PATH="lib"
+[AS_IF([test "\${exec_prefix}/lib" = "$libdir"],
+    [AS_IF([test "$prefix" = "NONE"], [prefix=$ac_default_prefix])
+    AS_IF([test -d "${prefix}/lib64"], [
+        LIB_PATH="lib64"
+    ],[
+        LIB_PATH="lib"
+    ])
+], [
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
 ])
 AC_SUBST(LIB_PATH)])
-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:18:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:18:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gc2-0004tP-GX; Wed, 29 Feb 2012 10:18:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2gc1-0004tK-3f
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:18:21 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330510694!16062174!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16801 invoked from network); 29 Feb 2012 10:18:14 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 10:18:14 -0000
Received: by werm1 with SMTP id m1so3535144wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 02:18:14 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.87 as permitted sender) client-ip=10.216.134.87; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.87 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.87])
	by 10.216.134.87 with SMTP id r65mr12042007wei.46.1330510694474
	(num_hops = 1); Wed, 29 Feb 2012 02:18:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=kgUvQi1huu9vowETbHbzW83xU+6hJV67qnFKaONkSVs=;
	b=AXvi3PKNGwJw8B4wlCiEUrct+IXNe8C6suRbMoDGrRRN/+Te0i9MOSQFGOThoeAZmm
	CrUjNF9LxLVen9k37B6aBBxSHS7HFJxx+d9U4fi9KR3EJXA8czB6relOJaD/z1vtaBjK
	r7qCkoDrA1sqGc7IDZD/2IuHtiNUkQVUiDm1I=
MIME-Version: 1.0
Received: by 10.216.134.87 with SMTP id r65mr9617008wei.46.1330510694370; Wed,
	29 Feb 2012 02:18:14 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 02:18:14 -0800 (PST)
In-Reply-To: <1330459026.10008.57.camel@dagon.hellion.org.uk>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
Date: Wed, 29 Feb 2012 11:18:14 +0100
X-Google-Sender-Auth: WhUG7tO1vfd26zgzNbP2ME9imrg
Message-ID: <CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/28 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2012-02-28 at 17:51 +0000, Jeffrey Karrels wrote:
>
>> > Have you changed anything here or are you saying that a pristine Xen
>> > tree when built on CentOS installs 64 bit libraries to /usr/lib instead
>> > of /usr/lib64? If so please can you be precise about what tree you are
>> > running (e.g. the exact URL you cloned and which changeset you got) and
>> > steps you took to install (e.g. what patches did you apply, what
>> > commands did you type) and what exactly you saw (e.g. what was
>> > in /usr/lib and what was in /usr/lib64)
>>
>> #uname -a
>> Linux xenbuild2.cyberlab 2.6.32-220.4.1.el6.x86_64 #1 SMP Tue Jan 24
>> 02:13:44 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
>>
>> #hg clone -r 24869 http://xenbits.xen.org/hg/xen-unstable.hg
>> #cd xen-unstable
>> #./configure --enable-xsm --libdir=/usr/lib64
>
> OK, so you are using something new enough to have the autoconf stuff --
> I think this is simply a bug in that. I've CC'd Roger.
>
> Ideally configure would auto-detect the right thing for the given system
> and so --libdir would not be required. This would certainly be n
> improvement over the pre-autoconf thing.

configure was not properly parsing the libdir path and always set it
to "lib", this is a fix:

8<--------------------------------------------

autoconf: fix libdir detection

If user specifies a libdir it is used, if no libdir is specified
configure checks if $prefix/lib64 is a directory and uses that, if not
lib is used.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 4758a7a94c15 tools/configure
--- a/tools/configure	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/configure	Wed Feb 22 06:31:53 2012 +0100
@@ -3845,7 +3845,6 @@ case $host_os in *\ *) host_os=`echo "$h



-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -6551,13 +6550,23 @@ else
 fi

 # Check library path
-if test -d "$prefix/lib64"; then :
-
-    LIB_PATH="lib64"
-
-else
-
-    LIB_PATH="lib"
+if test "\${exec_prefix}/lib" = "$libdir"; then :
+  if test "$prefix" = "NONE"; then :
+  prefix=$ac_default_prefix
+fi
+    if test -d "${prefix}/lib64"; then :
+
+        LIB_PATH="lib64"
+
+else
+
+        LIB_PATH="lib"
+
+fi
+
+else
+
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"

 fi

diff -r 4758a7a94c15 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/m4/default_lib.m4	Wed Feb 22 06:31:53 2012 +0100
@@ -1,8 +1,12 @@
 AC_DEFUN([AX_DEFAULT_LIB],
-[AS_IF([test -d "$prefix/lib64"], [
-    LIB_PATH="lib64"
-],[
-    LIB_PATH="lib"
+[AS_IF([test "\${exec_prefix}/lib" = "$libdir"],
+    [AS_IF([test "$prefix" = "NONE"], [prefix=$ac_default_prefix])
+    AS_IF([test -d "${prefix}/lib64"], [
+        LIB_PATH="lib64"
+    ],[
+        LIB_PATH="lib"
+    ])
+], [
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
 ])
 AC_SUBST(LIB_PATH)])
-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:32:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gp6-00053z-Qe; Wed, 29 Feb 2012 10:31:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1S2gp5-00053r-0D
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:31:51 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330511502!16977221!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17517 invoked from network); 29 Feb 2012 10:31:42 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 10:31:42 -0000
Received: by lagr15 with SMTP id r15so7857795lag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 02:31:42 -0800 (PST)
Received-SPF: pass (google.com: domain of vase@selfip.ru designates
	10.112.8.129 as permitted sender) client-ip=10.112.8.129; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of vase@selfip.ru
	designates 10.112.8.129 as permitted sender)
	smtp.mail=vase@selfip.ru; dkim=pass header.i=vase@selfip.ru
Received: from mr.google.com ([10.112.8.129])
	by 10.112.8.129 with SMTP id r1mr9741454lba.38.1330511502276 (num_hops
	= 1); Wed, 29 Feb 2012 02:31:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=yyMMFs57K1wwmxa2iBJL0iPgmBj4dW5RXp+c7NrXAIg=;
	b=UD2c4t8HwCh3yNu8a4uL5WTtIru7v1jCfEbXaXd+o5icT0E4XdMvsw4mGY9KCQk/p5
	0tAZNOi1icrCJLVjeTrP0oGI6TL5ms65LgK0beblwdqGRsNwLVcCQXSnbIZsifiIaXDc
	rMWXdUzZUwpF6YCpZIMRmmxkfxL+Z6WeRyW0s=
Received: by 10.112.8.129 with SMTP id r1mr8143094lba.38.1330511502155; Wed,
	29 Feb 2012 02:31:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.6.4 with HTTP; Wed, 29 Feb 2012 02:31:27 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Wed, 29 Feb 2012 14:31:27 +0400
X-Google-Sender-Auth: l3v21379go_Z9RBltI1I8VD00Qc
Message-ID: <CACaajQsfyy476bMCCfKpHvNOaoTE3HGREE85ht8YpN6JHQHeDQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnjf8BLkhU+myk0ZuQ5BpT1qqZ5XNBWqHyGgf6eRSj6iXTF2PrLrxbAsLcdLBK+YiokyBmq
Subject: [Xen-devel] sometimes installer of windows 2008 r2 not able to
	install on hard disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello. I'm create simple winpe windows installer with windows aik and
integrate into it xen gpl pv drivers. Sometimes i can't install
windows to hard drive.
Windows syas, that hard disk not properly configured in bios or not
able to boot from it.
Disk is the phisical device, domU config:

kernel='hvmloader'
builder='hvm'
memory=1024
name="21-706"
vcpus=4
vif="mac=00:16:3e:00:17:b9,ip=62.76.47.68,type=paravirtualised"
disk="file:/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso,hdc:cdrom,r"
disk="phy:/dev/disk/vbd/21-1206,hda,w"
device_model='qemu-dm'
boot='c'
vnc=1
vncpasswd='uRFCg8oPkD'
serial='pty'
usbdevice='tablet'
keymap='en-us'
boot='d'
-p
disk="file:/var/storage/iso/winpe_amd64.iso,hdb:cdrom,r"
on_reboot=destroy
on_poweroff=destroy
on_crash=destroy

qemu-dm log conains this messages:

domid: 1155
Using file /var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
in read-only mode
Using file /dev/disk/vbd/21-1206 in read-write mode
Using file /var/storage/iso/winpe_amd64.iso in read-only mode
Watching /local/domain/0/device-model/1155/logdirty/cmd
Watching /local/domain/0/device-model/1155/command
char device redirected to /dev/pts/59
qemu_map_cache_init nr_buckets = 10000 size 4194304
/usr/src/packages/BUILD/xen-4.0.1-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
Init blktap pipes
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 64ebb4f3-827b-4bbd-3ada-358b66e61a95
Time offset set 0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/1155/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 0):
/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdb' (index: 2): /var/storage/iso/winpe_amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/1155/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
log_throttling disabled
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
12974973492593: XenPCI --> XenPci_InitialBalloonDown
12974973492593: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492593: XenPCI     Xen Version 4.0
12974973492593: XenPCI     Hypercall area at FFFFFA80010B7000
12974973492593: XenPCI     XENMEM_maximum_reservation = 263168
12974973492593: XenPCI     XENMEM_current_reservation = 263160
12974973492593: XenPCI     Trying to give 32 KB (0 MB) to Xen
12974973492609: XenPCI <-- XenPci_InitialBalloonDown
12974973492609: XenPCI     KeInitializeCrashDumpHeader status =
00000000, size = 8192
12974973492609: XenPCI GPLPV 0.10.0.357
12974973492609: XenPCI --> XenPci_FixLoadOrder
12974973492609: XenPCI     dummy_group_index = -1
12974973492609: XenPCI     wdf_load_group_index = 2
12974973492609: XenPCI     xenpci_group_index = -1
12974973492609: XenPCI     boot_bus_extender_index = 3
12974973492609: XenPCI <-- XenPci_FixLoadOrder
12974973492609: XenPCI     SystemStartOptions =  MININT  REDIRECT
RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088
RDPATH=MULTI(0)DISK(0)CDROM(0)\SOURCES\BOOT.WIM
12974973492625: XenPCI     Version = 1
Unknown PV product 2 loaded in guest
PV driver build 1
12974973492625: XenPCI     Disabled qemu devices 01
12974973492625: XenPCI <-- DriverEntry
12974973492625: XenPCI     Xen PCI device found - must be fdo
12974973492625: XenPCI --> XenPci_EvtDeviceAdd_XenPci
12974973492625: XenPCI <-- XenPci_EvtDeviceAdd_XenPci
12974973492640: XenPCI --> XenPci_EvtDevicePrepareHardware
12974973492640: XenPCI     IoPort Address(c000) Length: 256
12974973492640: XenPCI     Private Data: 0x01 0x00 0x00
12974973492640: XenPCI     Memory mapped CSR:(f2000000:0) Length:(16777216)
12974973492640: XenPCI     Memory flags = 0084
12974973492640: XenPCI     Private Data: 0x01 0x01 0x00
12974973492640: XenPCI     irq_number = 01c
12974973492640: XenPCI     irq_vector = 0a2
12974973492640: XenPCI     irq_level = 00a
12974973492640: XenPCI     irq_mode = LevelSensitive
12974973492656: XenPCI     ShareDisposition = CmResourceShareShared
12974973492656: XenPCI <-- XenPci_EvtDevicePrepareHardware
12974973492656: XenPCI --> XenPci_EvtDeviceD0Entry
12974973492656: XenPCI     WdfPowerDeviceD3Final
12974973492656: XenPCI --> XenPci_Init
12974973492656: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492656: XenPCI     Xen Version 4.0
12974973492656: XenPCI     Hypercall area at FFFFFA80011BD000
12974973492656: XenPCI     shared_info_area_unmapped.QuadPart = f2000000
12974973492656: XenPCI     gpfn = f2000
12974973492656: XenPCI     hypervisor memory op
(XENMAPSPACE_shared_info) ret = 0
12974973492671: XenPCI <-- XenPci_Init
12974973492671: XenPCI --> GntTbl_Init
12974973492671: XenPCI     grant_frames = 32
12974973492671: XenPCI     grant_entries = 16384
12974973492671: XenPCI     pfn = 3fa1e
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1e
12974973492671: XenPCI     decreased 1 pages for grant table frame 0
12974973492671: XenPCI     pfn = 3fa1f
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1f
12974973492671: XenPCI     decreased 1 pages for grant table frame 1
12974973492671: XenPCI     pfn = 3fa20
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa20
12974973492687: XenPCI     decreased 1 pages for grant table frame 2
12974973492687: XenPCI     pfn = 3fa21
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa21
12974973492687: XenPCI     decreased 1 pages for grant table frame 3
12974973492687: XenPCI     pfn = 3fa22
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa22
12974973492687: XenPCI     decreased 1 pages for grant table frame 4
12974973492687: XenPCI     pfn = 3fa23
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa23
12974973492703: XenPCI     decreased 1 pages for grant table frame 5
12974973492703: XenPCI     pfn = 3fa24
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa24
12974973492703: XenPCI     decreased 1 pages for grant table frame 6
12974973492703: XenPCI     pfn = 3fa25
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa25
12974973492703: XenPCI     decreased 1 pages for grant table frame 7
12974973492718: XenPCI     pfn = 3fa26
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa26
12974973492718: XenPCI     decreased 1 pages for grant table frame 8
12974973492718: XenPCI     pfn = 3fa27
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa27
12974973492718: XenPCI     decreased 1 pages for grant table frame 9
12974973492718: XenPCI     pfn = 3fa28
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa28
12974973492718: XenPCI     decreased 1 pages for grant table frame 10
12974973492734: XenPCI     pfn = 3fa29
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa29
12974973492734: XenPCI     decreased 1 pages for grant table frame 11
12974973492734: XenPCI     pfn = 3fa2a
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2a
12974973492734: XenPCI     decreased 1 pages for grant table frame 12
12974973492734: XenPCI     pfn = 3fa2b
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2b
12974973492750: XenPCI     decreased 1 pages for grant table frame 13
12974973492750: XenPCI     pfn = 3fa2c
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2c
12974973492750: XenPCI     decreased 1 pages for grant table frame 14
12974973492750: XenPCI     pfn = 3fa2d
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2d
12974973492750: XenPCI     decreased 1 pages for grant table frame 15
12974973492750: XenPCI     pfn = 3fa2e
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2e
12974973492765: XenPCI     decreased 1 pages for grant table frame 16
12974973492765: XenPCI     pfn = 3fa2f
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2f
12974973492765: XenPCI     decreased 1 pages for grant table frame 17
12974973492765: XenPCI     pfn = 3fa30
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa30
12974973492765: XenPCI     decreased 1 pages for grant table frame 18
12974973492765: XenPCI     pfn = 3fa31
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa31
12974973492765: XenPCI     decreased 1 pages for grant table frame 19
12974973492781: XenPCI     pfn = 3fa32
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa32
12974973492781: XenPCI     decreased 1 pages for grant table frame 20
12974973492781: XenPCI     pfn = 3fa33
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa33
12974973492781: XenPCI     decreased 1 pages for grant table frame 21
12974973492781: XenPCI     pfn = 3fa34
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa34
12974973492796: XenPCI     decreased 1 pages for grant table frame 22
12974973492796: XenPCI     pfn = 3fa35
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa35
12974973492796: XenPCI     decreased 1 pages for grant table frame 23
12974973492796: XenPCI     pfn = 3fa36
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa36
12974973492796: XenPCI     decreased 1 pages for grant table frame 24
12974973492796: XenPCI     pfn = 3fa37
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa37
12974973492812: XenPCI     decreased 1 pages for grant table frame 25
12974973492812: XenPCI     pfn = 3fa38
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa38
12974973492812: XenPCI     decreased 1 pages for grant table frame 26
12974973492812: XenPCI     pfn = 3fa39
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa39
12974973492812: XenPCI     decreased 1 pages for grant table frame 27
12974973492812: XenPCI     pfn = 3fa3a
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3a
12974973492828: XenPCI     decreased 1 pages for grant table frame 28
12974973492828: XenPCI     pfn = 3fa3b
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3b
12974973492828: XenPCI     decreased 1 pages for grant table frame 29
12974973492828: XenPCI     pfn = 3fa3c
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3c
12974973492828: XenPCI     decreased 1 pages for grant table frame 30
12974973492828: XenPCI     pfn = 3fa3d
12974973492843: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3d
12974973492843: XenPCI     decreased 1 pages for grant table frame 31
12974973492859: XenPCI --> GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Init
12974973492875: XenPCI --> EvtChn_Init
12974973492875: XenPCI --> _hvm_set_parameter
12974973492890: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492890: XenPCI <-- _hvm_set_parameter
12974973492890: XenPCI     hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0
12974973492890: XenPCI --> EvtChn_AllocIpi
12974973492890: XenPCI <-- EvtChn_AllocIpi
12974973492890: XenPCI --> EvtChn_BindDpc
12974973492890: XenPCI <-- EvtChn_BindDpc
12974973492890: XenPCI     pdo_event_channel = 7
12974973492890: XenPCI <-- EvtChn_Init
12974973492890: XenPCI <-- XenPci_EvtDeviceD0Entry
12974973492890: XenPCI --> EvtChn_EvtInterruptEnable
12974973492890: XenPCI <-- EvtChn_EvtInterruptEnable
12974973492906: XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492906: XenPCI --> XenBus_Init
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI <-- XenBus_Init
12974973492906: XenPCI     suspend event channel = 8
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI --> XenPci_SysrqHandler
12974973492906: XenPCI     SysRq Value = (null)
12974973492921: XenPCI <-- XenPci_SysrqHandler
12974973492921: XenPCI --> XenPci_ShutdownHandler
12974973492921: XenPCI     Initial Memory Value = 1048576 (1048576)
12974973492953: Error reading shutdown path - ENOENT
12974973492953: XenPCI <-- XenPci_ShutdownHandler
12974973492953: XenPCI --> XenPci_BalloonThreadProc
12974973492953: XenPCI --> XenPci_DeviceWatchHandler
12974973492953: XenPCI     low_mem_event = FFFFFA8000C865C0, state = 0
12974973492953: XenPCI <-- XenPci_DeviceWatchHandler
12974973492953: XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492953: XenPCI --> XenPci_BalloonHandler
12974973492953: XenPCI --> XenPci_EvtChildListScanForChildren
12974973492953: XenPCI     target memory value = 1048576 (1048576)
12974973492953: XenPCI     Found path = device/vfb/0
12974973492953: XenPCI     Got balloon event, current = 1048576,
target = 1048576
12974973492968: XenPCI     Found path = device/vbd/5632
12974973492968: XenPCI     No change to memory
12974973492968: XenPCI <-- XenPci_BalloonHandler
12974973492968: XenPCI     Found path = device/vbd/768
12974973492968: XenPCI     Found path = device/vbd/832
12974973492968: XenPCI     Found path = device/vif/0
12974973492968: XenPCI     Found path = device/suspend/event-channel
12974973492968: XenPCI <-- XenPci_EvtChildListScanForChildren
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492968: XenPCI     device = 'vfb', index = '0', path = 'device/vfb/0'
12974973492968: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '5632', path =
'device/vbd/5632'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '768', path =
'device/vbd/768'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '832', path =
'device/vbd/832'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vif', index = '0', path = 'device/vif/0'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973493000: XenPCI     device = 'suspend', index = '0', path =
'device/suspend/event-channel'
12974973493000: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973503046: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI     device/vbd/5632
12974973503046: XenPCI     CmResourceTypeMemory (0)
12974973503046: XenPCI     Start = f2000000, Length = 0
12974973503046: XenPCI     pfn[0] = 0001b0ac
12974973503046: XenPCI     New Start = 000000001b0ac000, Length = 4096
12974973503046: XenPCI     CmResourceTypeMemory (1)
12974973503046: XenPCI     Start = f2000001, Length = 0
12974973503046: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503062: XenPCI     path = device/vbd/5632
12974973503062: XenPCI     WdfPowerDeviceD3Final
12974973503062: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503062: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503062: XenPCI --> XenPci_UpdateBackendState
12974973503078: XenPCI --> XenConfig_InitConfigPage
12974973503078: XenPCI     Backend State Changed to InitWait
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503078: XenPCI <-- XenPci_UpdateBackendState
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI <-- XenConfig_InitConfigPage
12974973503078: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503078: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503093: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503093: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503093: XenVbd     IRQL = 0
12974973503093: XenVbd     xvdd = FFFFFA80013C8008
12974973503093: XenVbd     BusInterruptLevel = 28
12974973503093: XenVbd     BusInterruptVector = 01c
12974973503093: XenVbd     NumberOfAccessRanges = 1
12974973503093: XenVbd     RangeStart = 1b0ac000, RangeLength = 00001000
12974973503093: XenVbd --> XenVbd_InitConfig
12974973503109: XenVbd     XEN_INIT_TYPE_13
12974973503109: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503109: XenVbd     XEN_INIT_TYPE_11
12974973503109: XenVbd     XEN_INIT_TYPE_17
12974973503109: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
12974973503109: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 9
12974973503109: XenPCI --> XenPci_DeviceWatchHandler
12974973503109: XenPCI --> EvtChn_BindDpc
12974973503109: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- EvtChn_BindDpc
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendState
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_UpdateBackendState
12974973503140: XenPCI     Backend State Changed to Connected
12974973503140: XenPCI <-- XenPci_UpdateBackendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI --> XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503156: XenPCI <-- XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503156: XenVbd <-- XenVbd_InitConfig
12974973503156: XenVbd --> XenVbd_InitFromConfig
12974973503156: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503156: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 00000000013795D0
12974973503156: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503156: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 9 (00000009)
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503156: XenVbd     device-type = CDROM
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503156: XenVbd     mode = r
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 6544648
12974973503171: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503171: XenVbd     qemu_hide_flags_value = 1
12974973503171: XenVbd     Device is inactive
12974973503171: XenVbd <-- XenVbd_InitFromConfig
12974973503171: XenVbd     aligned_buffer_data = FFFFFA80013CA8E8
12974973503171: XenVbd     aligned_buffer = FFFFFA80013CB000
12974973503171: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503171: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503171: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503187: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503187: XenVbd     Dma64BitAddresses supported
12974973503187: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503187: XenVbd --> XenVbd_HwStorInitialize
12974973503187: XenVbd     IRQL = 0
12974973503187: XenVbd     dump_mode = 0
12974973503187: XenVbd <-- XenVbd_HwStorInitialize
12974973503187: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503203: XenPCI     device/vbd/768
12974973503203: XenPCI     CmResourceTypeMemory (0)
12974973503203: XenPCI     Start = f2000000, Length = 0
12974973503203: XenPCI     pfn[0] = 0001afad
12974973503203: XenPCI     New Start = 000000001afad000, Length = 4096
12974973503203: XenPCI     CmResourceTypeMemory (1)
12974973503203: XenPCI     Start = f2000001, Length = 0
12974973503218: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503218: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503234: XenPCI     path = device/vbd/768
12974973503234: XenPCI     WdfPowerDeviceD3Final
12974973503234: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503234: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503234: XenPCI --> XenPci_UpdateBackendState
12974973503234: XenPCI --> XenConfig_InitConfigPage
12974973503234: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503250: XenPCI     Backend State Changed to InitWait
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenPci_UpdateBackendState
12974973503250: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenConfig_InitConfigPage
12974973503250: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503265: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503281: XenVbd     IRQL = 0
12974973503281: XenVbd     xvdd = FFFFFA800141B008
12974973503281: XenVbd     BusInterruptLevel = 28
12974973503281: XenVbd     BusInterruptVector = 01c
12974973503281: XenVbd     NumberOfAccessRanges = 1
12974973503281: XenVbd     RangeStart = 1afad000, RangeLength = 00001000
12974973503281: XenVbd --> XenVbd_InitConfig
12974973503281: XenVbd     XEN_INIT_TYPE_13
12974973503281: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503296: XenVbd     XEN_INIT_TYPE_11
12974973503296: XenVbd     XEN_INIT_TYPE_17
12974973503296: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16382
12974973503296: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 10
12974973503312: XenPCI --> XenPci_DeviceWatchHandler
12974973503328: XenPCI --> EvtChn_BindDpc
12974973503343: XenPCI <-- XenPci_DeviceWatchHandler
12974973503343: XenPCI <-- EvtChn_BindDpc
12974973503343: XenPCI --> XenPci_DeviceWatchHandler
12974973503343: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503375: XenPCI <-- XenPci_DeviceWatchHandler
12974973503375: XenPCI --> XenPci_ChangeFrontendState
12974973503390: XenPCI --> XenPci_DeviceWatchHandler
12974973503390: XenPCI <-- XenPci_DeviceWatchHandler
12974973503390: XenPCI --> XenPci_UpdateBackendState
12974973503406: XenPCI     Backend State Changed to Connected
12974973503406: XenPCI <-- XenPci_UpdateBackendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503406: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503421: XenPCI --> XenPci_ChangeFrontendState
12974973503421: XenPCI <-- XenPci_ChangeFrontendState
12974973503421: XenPCI --> XenPci_DeviceWatchHandler
12974973503421: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503437: XenPCI <-- XenPci_DeviceWatchHandler
12974973503437: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503437: XenVbd <-- XenVbd_InitConfig
12974973503437: XenVbd --> XenVbd_InitFromConfig
12974973503437: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503437: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137B5D0
12974973503437: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503453: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 10 (0000000a)
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = disk
12974973503453: XenVbd     device-type = Disk
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = w
12974973503453: XenVbd     mode = w
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 44038000
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503468: XenVbd     qemu_hide_flags_value = 1
12974973503468: XenVbd <-- XenVbd_InitFromConfig
12974973503468: XenVbd     aligned_buffer_data = FFFFFA800141D8E8
12974973503468: XenVbd     aligned_buffer = FFFFFA800141E000
12974973503484: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503484: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503484: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503484: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503500: XenVbd     Dma64BitAddresses supported
12974973503500: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503515: XenVbd --> XenVbd_HwStorInitialize
12974973503515: XenVbd     IRQL = 0
12974973503515: XenVbd     dump_mode = 0
12974973503515: XenVbd <-- XenVbd_HwStorInitialize
12974973503515: XenVbd --- HwStorStartIo (Still figuring out ring)
12974973503531: XenVbd     ring_detect_state = 1, index = 0, operation
= ff, id = 0, status = -1
12974973503531: XenVbd     req_prod = 2, rsp_prod = 1, rsp_cons = 0
12974973503531: XenVbd     ring_detect_state = 2, index = 1, operation
= ff, id = 0, status = -1
12974973503546: XenVbd     req_prod = 2, rsp_prod = 2, rsp_cons = 1
12974973503656: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973503656: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd     SRB_FUNCTION_PNP
12974973503671: XenVbd      StorQueryCapabilities
12974973503671: XenVbd      SrbPnPFlags = 00000000
12974973503671: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503718: XenPCI     device/vbd/832
12974973503718: XenPCI     CmResourceTypeMemory (0)
12974973503718: XenPCI     Start = f2000000, Length = 0
12974973503718: XenPCI     pfn[0] = 0001afae
12974973503718: XenPCI     New Start = 000000001afae000, Length = 4096
12974973503718: XenPCI     CmResourceTypeMemory (1)
12974973503718: XenPCI     Start = f2000001, Length = 0
12974973503718: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503734: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503734: XenPCI     path = device/vbd/832
12974973503734: XenPCI     WdfPowerDeviceD3Final
12974973503734: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503734: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503734: XenPCI --> XenPci_UpdateBackendState
12974973503750: XenPCI --> XenConfig_InitConfigPage
12974973503750: XenPCI     Backend State Changed to InitWait
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503750: XenPCI <-- XenPci_UpdateBackendState
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI <-- XenConfig_InitConfigPage
12974973503750: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503750: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503750: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503765: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503765: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503765: XenVbd     IRQL = 0
12974973503765: XenVbd     xvdd = FFFFFA8001471008
12974973503765: XenVbd     BusInterruptLevel = 28
12974973503765: XenVbd     BusInterruptVector = 01c
12974973503781: XenVbd     NumberOfAccessRanges = 1
12974973503781: XenVbd     RangeStart = 1afae000, RangeLength = 00001000
12974973503781: XenVbd --> XenVbd_InitConfig
12974973503781: XenVbd     XEN_INIT_TYPE_13
12974973503781: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503796: XenVbd     XEN_INIT_TYPE_11
12974973503796: XenVbd     XEN_INIT_TYPE_17
12974973503796: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16381
12974973503812: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 11
12974973503828: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> EvtChn_BindDpc
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- EvtChn_BindDpc
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendState
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503859: XenPCI --> XenPci_UpdateBackendState
12974973503859: XenPCI     Backend State Changed to Connected
12974973503859: XenPCI <-- XenPci_UpdateBackendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI --> XenPci_DeviceWatchHandler
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503875: XenPCI <-- XenPci_DeviceWatchHandler
12974973503875: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503875: XenVbd <-- XenVbd_InitConfig
12974973503875: XenVbd --> XenVbd_InitFromConfig
12974973503875: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503875: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137C9C0
12974973503875: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503875: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 11 (0000000b)
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503875: XenVbd     device-type = CDROM
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503875: XenVbd     mode = r
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 422560
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503890: XenVbd     qemu_hide_flags_value = 1
12974973503890: XenVbd     Device is inactive
12974973503890: XenVbd <-- XenVbd_InitFromConfig
12974973503890: XenVbd     aligned_buffer_data = FFFFFA80014738E8
12974973503890: XenVbd     aligned_buffer = FFFFFA8001474000
12974973503890: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503890: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503890: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503906: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503906: XenVbd     Dma64BitAddresses supported
12974973503906: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503906: XenVbd --> XenVbd_HwStorInitialize
12974973503906: XenVbd     IRQL = 0
12974973503906: XenVbd     dump_mode = 0
12974973503906: XenVbd <-- XenVbd_HwStorInitialize
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503921: XenVbd     SRB_FUNCTION_IO_CONTROL
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 28, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503937: XenVbd     SRB_FUNCTION_PNP
12974973503937: XenVbd      StorQueryCapabilities
12974973503937: XenVbd      SrbPnPFlags = 00000000
12974973504203: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973504218: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973505265: Trying to enable physical device already in use.
12974973524343: XenNet --> DriverEntry
12974973524343: XenNet     Driver MajorNdisVersion = 6, Driver
MinorNdisVersion = 1
12974973524359: XenNet     Windows MajorNdisVersion = 6, Windows
MinorNdisVersion = 20
12974973524359: XenNet --> XenNet_SetOptions
12974973524359: XenNet <-- XenNet_SetOptions
12974973524359: XenNet <-- DriverEntry
12974973524359: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524375: XenPCI     device/vif/0
12974973524375: XenPCI     CmResourceTypeMemory (0)
12974973524375: XenPCI     Start = f2000000, Length = 0
12974973524375: XenPCI     pfn[0] = 0001afaf
12974973524375: XenPCI     New Start = 000000001afaf000, Length = 4096
12974973524375: XenPCI     CmResourceTypeMemory (1)
12974973524390: XenPCI     Start = f2000001, Length = 0
12974973524390: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524390: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973524390: XenPCI     path = device/vif/0
12974973524406: XenPCI     WdfPowerDeviceD3Final
12974973524406: XenPCI --> XenPci_GetBackendAndAddWatch
12974973524406: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973524406: XenPCI --> XenPci_UpdateBackendState
12974973524421: XenPCI --> XenConfig_InitConfigPage
12974973524421: XenPCI     Backend State Changed to InitWait
12974973524421: XenPCI     fdo_driver_object = FFFFFA8001BB7060
12974973524421: XenPCI <-- XenPci_UpdateBackendState
12974973524421: XenPCI     fdo_driver_extension = 0000000000000000
12974973524421: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973524437: XenPCI     fdo_driver_extension = 0000000000000000
12974973524437: XenPCI <-- XenConfig_InitConfigPage
12974973524437: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524437: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524437: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524453: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973524468: XenNet --> XenNet_Initialize
12974973524468: XenNet     XEN_INIT_TYPE_13
12974973524468: XenNet     XEN_INIT_TYPE_VECTORS
12974973524468: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524468: ScatterGather = 1
12974973524468: LargeSendOffload = 61440
12974973524500: LargeSendOffloadRxSplitMTU = 1
12974973524500: ChecksumOffload = 1
12974973524500: MTU = 1500
12974973524515: Could not read NetworkAddress value (c0000001) or
value is invalid
12974973524515: XenNet --> XenNet_D0Entry
12974973524515: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = 16380
12974973524531: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524546: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = 16379
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524562: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI --> EvtChn_Bind
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI <-- EvtChn_Bind
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendState
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_UpdateBackendState
12974973524593: XenPCI     Backend State Changed to Connected
12974973524593: XenPCI <-- XenPci_UpdateBackendState
12974973524593: XenPCI <-- XenPci_ChangeFrontendState
12974973524609: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524609: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524609: XenNet --> XenNet_ConnectBackend
12974973524609: XenNet     XEN_INIT_TYPE_13
12974973524609: XenNet     XEN_INIT_TYPE_VECTORS
12974973524609: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524609: XenNet     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524609: XenNet     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524609: XenNet     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:00:17:b9
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - feature-sg = 1
12974973524625: XenNet     XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1
12974973524625: XenNet     XEN_INIT_TYPE_17
12974973524625: XenNet <-- XenNet_ConnectBackend
12974973524625: XenNet --> XenNet_RxInit
12974973524625: XenNet <-- XenNet_RxInit
12974973524625: XenNet <-- XenNet_D0Entry
12974973524640: XenNet     Supporting 00010102
(OID_GEN_HARDWARE_STATUS) get only 4 bytes
12974973524640: XenNet     Supporting 00010108
(OID_GEN_TRANSMIT_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 00010109
(OID_GEN_RECEIVE_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010a
(OID_GEN_TRANSMIT_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010b
(OID_GEN_RECEIVE_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010c (OID_GEN_VENDOR_ID) get
only 4 bytes
12974973524656: XenNet     Supporting 0001010d
(OID_GEN_VENDOR_DESCRIPTION) get only 10 bytes
12974973524656: XenNet     Supporting 00010116
(OID_GEN_VENDOR_DRIVER_VERSION) get only 4 bytes
12974973524656: XenNet     Supporting 0001010e
(OID_GEN_CURRENT_PACKET_FILTER) get/set 4 bytes
12974973524656: XenNet     Supporting 0001010f
(OID_GEN_CURRENT_LOOKAHEAD) get/set 4 bytes
12974973524656: XenNet     Supporting 00010111
(OID_GEN_MAXIMUM_TOTAL_SIZE) get only 4 bytes
12974973524656: XenNet     Supporting 00010208
(OID_GEN_LINK_PARAMETERS) set only 32 bytes
12974973524656: XenNet     Supporting 00010209
(OID_GEN_INTERRUPT_MODERATION) get/set 12 bytes
12974973524671: XenNet     Supporting 00010115
(OID_GEN_MAXIMUM_SEND_PACKETS) get only 4 bytes
12974973524671: XenNet     Supporting 00010103
(OID_GEN_MEDIA_SUPPORTED) get only 4 bytes
12974973524671: XenNet     Supporting 00010104 (OID_GEN_MEDIA_IN_USE)
get only 4 bytes
12974973524671: XenNet     Supporting 00010105
(OID_GEN_MAXIMUM_LOOKAHEAD) get only 4 bytes
12974973524671: XenNet     Supporting 00010118
(OID_GEN_NETWORK_LAYER_ADDRESSES) set only 6 bytes
12974973524671: XenNet     Supporting 0001021a (OID_GEN_MACHINE_NAME)
set only 0 bytes
12974973524687: XenNet     Supporting 0101010a
(OID_OFFLOAD_ENCAPSULATION) set only 28 bytes
12974973524687: XenNet     Supporting fd010101 (OID_PNP_SET_POWER) set
only 4 bytes
12974973524687: XenNet     Supporting 00020101 (OID_GEN_XMIT_OK) get
only 0 bytes
12974973524687: XenNet     Supporting 00020102 (OID_GEN_RCV_OK) get only 0 bytes
12974973524687: XenNet     Supporting 00020103 (OID_GEN_XMIT_ERROR)
get only 0 bytes
12974973524703: XenNet     Supporting 00020104 (OID_GEN_RCV_ERROR) get
only 0 bytes
12974973524703: XenNet     Supporting 00020105 (OID_GEN_RCV_NO_BUFFER)
get only 0 bytes
12974973524703: XenNet     Supporting 01020101
(OID_802_3_RCV_ERROR_ALIGNMENT) get only 0 bytes
12974973524703: XenNet     Supporting 01020102
(OID_802_3_XMIT_ONE_COLLISION) get only 0 bytes
12974973524703: XenNet     Supporting 01020103
(OID_802_3_XMIT_MORE_COLLISIONS) get only 0 bytes
12974973524703: XenNet     Supporting fc010209 (OID_IP4_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting fc01020a (OID_IP6_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting 00020106 (OID_GEN_STATISTICS)
get only 152 bytes
12974973524718: XenNet     Supporting 01010101
(OID_802_3_PERMANENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010102
(OID_802_3_CURRENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010103
(OID_802_3_MULTICAST_LIST) get/set 0 bytes
12974973524734: XenNet     Supporting 01010104
(OID_802_3_MAXIMUM_LIST_SIZE) get only 4 bytes
12974973524734: XenNet     name = minint-ps2nl91
12974973524734: XenNet --> XenNet_Restart
12974973524734: XenNet <-- XenNet_Restart
12974973524734: XenNet --> XenNet_DevicePnPEventNotify
12974973524734: XenNet     NdisDevicePnPEventPowerProfileChanged
12974973524734: XenNet <-- XenNet_DevicePnPEventNotify
12974973524734: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 62 (FFFFFA8001BB9000)
12974973524750: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524750: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524750: XenNet     Unsupported OID 00010117
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524781: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 82 (FFFFFA8001BB9000)
12974973524781: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524796: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524796: XenNet     NDIS_PACKET_TYPE_BROADCAST
12974973524796: XenNet      IPv4.Enabled = NDIS_OFFLOAD_SET_ON
12974973524796: XenNet      IPv4.HeaderSize = 14
12974973524796: XenNet      IPv6.EncapsulationType = 0
12974973524796: XenNet      IPv6.Enabled = NDIS_OFFLOAD_SET_OFF
12974973524812: XenNet      IPv6.HeaderSize = 0
12974973534531: XenNet     AddressType = 2
12974973534531: XenNet     AddressCount = 1
12974973534531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973534531: XenNet     Address[0].Length = 16
12974973534531: XenNet     Address[0].in_addr = 169.254.239.84
12974973586906: XenPCI --> XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoWrite
12974973586921: XenPCI     36 bytes of write buffer remaining
12974973586921: XenPCI     completing request with length 36
12974973586921: XenPCI <-- XenBus_EvtIoWrite
12974973586921: XenPCI <-- XenPci_EvtIoDefault
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoRead
12974973586921: XenPCI     found pending read
12974973586937: XenPCI <-- XenBus_ProcessReadRequest
12974973586937: XenPCI <-- XenBus_EvtIoRead
12974973586937: XenPCI <-- XenPci_EvtIoDefault
12974973586937: XenPCI --> XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenPci_EvtFileClose
12974973586937: XenPCI --> XenBus_EvtFileClose
12974973586937: XenPCI <-- XenBus_EvtFileClose
12974973586937: XenPCI <-- XenPci_EvtFileClose
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591531: XenNet     Address[0].Length = 16
12974973591531: XenNet     Address[0].in_addr = 62.76.47.68
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591546: XenNet     Address[0].Length = 16
12974973591546: XenNet     Address[0].in_addr = 62.76.47.68
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973612640: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613343: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613390: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613453: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613468: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613500: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613531: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613812: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613859: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613890: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613953: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613968: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614015: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973618406: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629718: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629750: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629765: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973635718: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973640703: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973648015: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973652000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:32:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2gp6-00053z-Qe; Wed, 29 Feb 2012 10:31:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1S2gp5-00053r-0D
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:31:51 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330511502!16977221!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17517 invoked from network); 29 Feb 2012 10:31:42 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 10:31:42 -0000
Received: by lagr15 with SMTP id r15so7857795lag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 02:31:42 -0800 (PST)
Received-SPF: pass (google.com: domain of vase@selfip.ru designates
	10.112.8.129 as permitted sender) client-ip=10.112.8.129; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of vase@selfip.ru
	designates 10.112.8.129 as permitted sender)
	smtp.mail=vase@selfip.ru; dkim=pass header.i=vase@selfip.ru
Received: from mr.google.com ([10.112.8.129])
	by 10.112.8.129 with SMTP id r1mr9741454lba.38.1330511502276 (num_hops
	= 1); Wed, 29 Feb 2012 02:31:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=yyMMFs57K1wwmxa2iBJL0iPgmBj4dW5RXp+c7NrXAIg=;
	b=UD2c4t8HwCh3yNu8a4uL5WTtIru7v1jCfEbXaXd+o5icT0E4XdMvsw4mGY9KCQk/p5
	0tAZNOi1icrCJLVjeTrP0oGI6TL5ms65LgK0beblwdqGRsNwLVcCQXSnbIZsifiIaXDc
	rMWXdUzZUwpF6YCpZIMRmmxkfxL+Z6WeRyW0s=
Received: by 10.112.8.129 with SMTP id r1mr8143094lba.38.1330511502155; Wed,
	29 Feb 2012 02:31:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.6.4 with HTTP; Wed, 29 Feb 2012 02:31:27 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Wed, 29 Feb 2012 14:31:27 +0400
X-Google-Sender-Auth: l3v21379go_Z9RBltI1I8VD00Qc
Message-ID: <CACaajQsfyy476bMCCfKpHvNOaoTE3HGREE85ht8YpN6JHQHeDQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQnjf8BLkhU+myk0ZuQ5BpT1qqZ5XNBWqHyGgf6eRSj6iXTF2PrLrxbAsLcdLBK+YiokyBmq
Subject: [Xen-devel] sometimes installer of windows 2008 r2 not able to
	install on hard disk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello. I'm create simple winpe windows installer with windows aik and
integrate into it xen gpl pv drivers. Sometimes i can't install
windows to hard drive.
Windows syas, that hard disk not properly configured in bios or not
able to boot from it.
Disk is the phisical device, domU config:

kernel='hvmloader'
builder='hvm'
memory=1024
name="21-706"
vcpus=4
vif="mac=00:16:3e:00:17:b9,ip=62.76.47.68,type=paravirtualised"
disk="file:/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso,hdc:cdrom,r"
disk="phy:/dev/disk/vbd/21-1206,hda,w"
device_model='qemu-dm'
boot='c'
vnc=1
vncpasswd='uRFCg8oPkD'
serial='pty'
usbdevice='tablet'
keymap='en-us'
boot='d'
-p
disk="file:/var/storage/iso/winpe_amd64.iso,hdb:cdrom,r"
on_reboot=destroy
on_poweroff=destroy
on_crash=destroy

qemu-dm log conains this messages:

domid: 1155
Using file /var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
in read-only mode
Using file /dev/disk/vbd/21-1206 in read-write mode
Using file /var/storage/iso/winpe_amd64.iso in read-only mode
Watching /local/domain/0/device-model/1155/logdirty/cmd
Watching /local/domain/0/device-model/1155/command
char device redirected to /dev/pts/59
qemu_map_cache_init nr_buckets = 10000 size 4194304
/usr/src/packages/BUILD/xen-4.0.1-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
Init blktap pipes
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 64ebb4f3-827b-4bbd-3ada-358b66e61a95
Time offset set 0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/1155/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 0):
/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdb' (index: 2): /var/storage/iso/winpe_amd64.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/1155/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
log_throttling disabled
qemu: ignoring not-understood drive `/local/domain/1155/log-throttling'
medium change watch on `/local/domain/1155/log-throttling' - unknown
device, ignored
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
12974973492593: XenPCI --> XenPci_InitialBalloonDown
12974973492593: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492593: XenPCI     Xen Version 4.0
12974973492593: XenPCI     Hypercall area at FFFFFA80010B7000
12974973492593: XenPCI     XENMEM_maximum_reservation = 263168
12974973492593: XenPCI     XENMEM_current_reservation = 263160
12974973492593: XenPCI     Trying to give 32 KB (0 MB) to Xen
12974973492609: XenPCI <-- XenPci_InitialBalloonDown
12974973492609: XenPCI     KeInitializeCrashDumpHeader status =
00000000, size = 8192
12974973492609: XenPCI GPLPV 0.10.0.357
12974973492609: XenPCI --> XenPci_FixLoadOrder
12974973492609: XenPCI     dummy_group_index = -1
12974973492609: XenPCI     wdf_load_group_index = 2
12974973492609: XenPCI     xenpci_group_index = -1
12974973492609: XenPCI     boot_bus_extender_index = 3
12974973492609: XenPCI <-- XenPci_FixLoadOrder
12974973492609: XenPCI     SystemStartOptions =  MININT  REDIRECT
RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088
RDPATH=MULTI(0)DISK(0)CDROM(0)\SOURCES\BOOT.WIM
12974973492625: XenPCI     Version = 1
Unknown PV product 2 loaded in guest
PV driver build 1
12974973492625: XenPCI     Disabled qemu devices 01
12974973492625: XenPCI <-- DriverEntry
12974973492625: XenPCI     Xen PCI device found - must be fdo
12974973492625: XenPCI --> XenPci_EvtDeviceAdd_XenPci
12974973492625: XenPCI <-- XenPci_EvtDeviceAdd_XenPci
12974973492640: XenPCI --> XenPci_EvtDevicePrepareHardware
12974973492640: XenPCI     IoPort Address(c000) Length: 256
12974973492640: XenPCI     Private Data: 0x01 0x00 0x00
12974973492640: XenPCI     Memory mapped CSR:(f2000000:0) Length:(16777216)
12974973492640: XenPCI     Memory flags = 0084
12974973492640: XenPCI     Private Data: 0x01 0x01 0x00
12974973492640: XenPCI     irq_number = 01c
12974973492640: XenPCI     irq_vector = 0a2
12974973492640: XenPCI     irq_level = 00a
12974973492640: XenPCI     irq_mode = LevelSensitive
12974973492656: XenPCI     ShareDisposition = CmResourceShareShared
12974973492656: XenPCI <-- XenPci_EvtDevicePrepareHardware
12974973492656: XenPCI --> XenPci_EvtDeviceD0Entry
12974973492656: XenPCI     WdfPowerDeviceD3Final
12974973492656: XenPCI --> XenPci_Init
12974973492656: XenPCI     base = 0x40000000, Xen Signature =
XenVMMXenVMM, EAX = 0x40000003
12974973492656: XenPCI     Xen Version 4.0
12974973492656: XenPCI     Hypercall area at FFFFFA80011BD000
12974973492656: XenPCI     shared_info_area_unmapped.QuadPart = f2000000
12974973492656: XenPCI     gpfn = f2000
12974973492656: XenPCI     hypervisor memory op
(XENMAPSPACE_shared_info) ret = 0
12974973492671: XenPCI <-- XenPci_Init
12974973492671: XenPCI --> GntTbl_Init
12974973492671: XenPCI     grant_frames = 32
12974973492671: XenPCI     grant_entries = 16384
12974973492671: XenPCI     pfn = 3fa1e
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1e
12974973492671: XenPCI     decreased 1 pages for grant table frame 0
12974973492671: XenPCI     pfn = 3fa1f
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa1f
12974973492671: XenPCI     decreased 1 pages for grant table frame 1
12974973492671: XenPCI     pfn = 3fa20
12974973492671: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa20
12974973492687: XenPCI     decreased 1 pages for grant table frame 2
12974973492687: XenPCI     pfn = 3fa21
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa21
12974973492687: XenPCI     decreased 1 pages for grant table frame 3
12974973492687: XenPCI     pfn = 3fa22
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa22
12974973492687: XenPCI     decreased 1 pages for grant table frame 4
12974973492687: XenPCI     pfn = 3fa23
12974973492687: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa23
12974973492703: XenPCI     decreased 1 pages for grant table frame 5
12974973492703: XenPCI     pfn = 3fa24
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa24
12974973492703: XenPCI     decreased 1 pages for grant table frame 6
12974973492703: XenPCI     pfn = 3fa25
12974973492703: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa25
12974973492703: XenPCI     decreased 1 pages for grant table frame 7
12974973492718: XenPCI     pfn = 3fa26
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa26
12974973492718: XenPCI     decreased 1 pages for grant table frame 8
12974973492718: XenPCI     pfn = 3fa27
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa27
12974973492718: XenPCI     decreased 1 pages for grant table frame 9
12974973492718: XenPCI     pfn = 3fa28
12974973492718: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa28
12974973492718: XenPCI     decreased 1 pages for grant table frame 10
12974973492734: XenPCI     pfn = 3fa29
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa29
12974973492734: XenPCI     decreased 1 pages for grant table frame 11
12974973492734: XenPCI     pfn = 3fa2a
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2a
12974973492734: XenPCI     decreased 1 pages for grant table frame 12
12974973492734: XenPCI     pfn = 3fa2b
12974973492734: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2b
12974973492750: XenPCI     decreased 1 pages for grant table frame 13
12974973492750: XenPCI     pfn = 3fa2c
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2c
12974973492750: XenPCI     decreased 1 pages for grant table frame 14
12974973492750: XenPCI     pfn = 3fa2d
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2d
12974973492750: XenPCI     decreased 1 pages for grant table frame 15
12974973492750: XenPCI     pfn = 3fa2e
12974973492750: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2e
12974973492765: XenPCI     decreased 1 pages for grant table frame 16
12974973492765: XenPCI     pfn = 3fa2f
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa2f
12974973492765: XenPCI     decreased 1 pages for grant table frame 17
12974973492765: XenPCI     pfn = 3fa30
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa30
12974973492765: XenPCI     decreased 1 pages for grant table frame 18
12974973492765: XenPCI     pfn = 3fa31
12974973492765: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa31
12974973492765: XenPCI     decreased 1 pages for grant table frame 19
12974973492781: XenPCI     pfn = 3fa32
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa32
12974973492781: XenPCI     decreased 1 pages for grant table frame 20
12974973492781: XenPCI     pfn = 3fa33
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa33
12974973492781: XenPCI     decreased 1 pages for grant table frame 21
12974973492781: XenPCI     pfn = 3fa34
12974973492781: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa34
12974973492796: XenPCI     decreased 1 pages for grant table frame 22
12974973492796: XenPCI     pfn = 3fa35
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa35
12974973492796: XenPCI     decreased 1 pages for grant table frame 23
12974973492796: XenPCI     pfn = 3fa36
12974973492796: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa36
12974973492796: XenPCI     decreased 1 pages for grant table frame 24
12974973492796: XenPCI     pfn = 3fa37
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa37
12974973492812: XenPCI     decreased 1 pages for grant table frame 25
12974973492812: XenPCI     pfn = 3fa38
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa38
12974973492812: XenPCI     decreased 1 pages for grant table frame 26
12974973492812: XenPCI     pfn = 3fa39
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa39
12974973492812: XenPCI     decreased 1 pages for grant table frame 27
12974973492812: XenPCI     pfn = 3fa3a
12974973492812: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3a
12974973492828: XenPCI     decreased 1 pages for grant table frame 28
12974973492828: XenPCI     pfn = 3fa3b
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3b
12974973492828: XenPCI     decreased 1 pages for grant table frame 29
12974973492828: XenPCI     pfn = 3fa3c
12974973492828: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3c
12974973492828: XenPCI     decreased 1 pages for grant table frame 30
12974973492828: XenPCI     pfn = 3fa3d
12974973492843: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3fa3d
12974973492843: XenPCI     decreased 1 pages for grant table frame 31
12974973492859: XenPCI --> GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Map
12974973492875: XenPCI <-- GntTbl_Init
12974973492875: XenPCI --> EvtChn_Init
12974973492875: XenPCI --> _hvm_set_parameter
12974973492890: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492890: XenPCI <-- _hvm_set_parameter
12974973492890: XenPCI     hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0
12974973492890: XenPCI --> EvtChn_AllocIpi
12974973492890: XenPCI <-- EvtChn_AllocIpi
12974973492890: XenPCI --> EvtChn_BindDpc
12974973492890: XenPCI <-- EvtChn_BindDpc
12974973492890: XenPCI     pdo_event_channel = 7
12974973492890: XenPCI <-- EvtChn_Init
12974973492890: XenPCI <-- XenPci_EvtDeviceD0Entry
12974973492890: XenPCI --> EvtChn_EvtInterruptEnable
12974973492890: XenPCI <-- EvtChn_EvtInterruptEnable
12974973492906: XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492906: XenPCI --> XenBus_Init
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> _hvm_get_parameter
12974973492906: XenPCI HYPERVISOR_hvm_op retval = 0
12974973492906: XenPCI <-- _hvm_get_parameter
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI <-- XenBus_Init
12974973492906: XenPCI     suspend event channel = 8
12974973492906: XenPCI --> EvtChn_BindDpc
12974973492906: XenPCI <-- EvtChn_BindDpc
12974973492906: XenPCI --> XenPci_SysrqHandler
12974973492906: XenPCI     SysRq Value = (null)
12974973492921: XenPCI <-- XenPci_SysrqHandler
12974973492921: XenPCI --> XenPci_ShutdownHandler
12974973492921: XenPCI     Initial Memory Value = 1048576 (1048576)
12974973492953: Error reading shutdown path - ENOENT
12974973492953: XenPCI <-- XenPci_ShutdownHandler
12974973492953: XenPCI --> XenPci_BalloonThreadProc
12974973492953: XenPCI --> XenPci_DeviceWatchHandler
12974973492953: XenPCI     low_mem_event = FFFFFA8000C865C0, state = 0
12974973492953: XenPCI <-- XenPci_DeviceWatchHandler
12974973492953: XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled
12974973492953: XenPCI --> XenPci_BalloonHandler
12974973492953: XenPCI --> XenPci_EvtChildListScanForChildren
12974973492953: XenPCI     target memory value = 1048576 (1048576)
12974973492953: XenPCI     Found path = device/vfb/0
12974973492953: XenPCI     Got balloon event, current = 1048576,
target = 1048576
12974973492968: XenPCI     Found path = device/vbd/5632
12974973492968: XenPCI     No change to memory
12974973492968: XenPCI <-- XenPci_BalloonHandler
12974973492968: XenPCI     Found path = device/vbd/768
12974973492968: XenPCI     Found path = device/vbd/832
12974973492968: XenPCI     Found path = device/vif/0
12974973492968: XenPCI     Found path = device/suspend/event-channel
12974973492968: XenPCI <-- XenPci_EvtChildListScanForChildren
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492968: XenPCI     device = 'vfb', index = '0', path = 'device/vfb/0'
12974973492968: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492968: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '5632', path =
'device/vbd/5632'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '768', path =
'device/vbd/768'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vbd', index = '832', path =
'device/vbd/832'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973492984: XenPCI     device = 'vif', index = '0', path = 'device/vif/0'
12974973492984: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973492984: XenPCI --> XenPci_EvtChildListCreateDevice
12974973493000: XenPCI     device = 'suspend', index = '0', path =
'device/suspend/event-channel'
12974973493000: XenPCI <-- XenPci_EvtChildListCreateDevice
12974973503046: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI     device/vbd/5632
12974973503046: XenPCI     CmResourceTypeMemory (0)
12974973503046: XenPCI     Start = f2000000, Length = 0
12974973503046: XenPCI     pfn[0] = 0001b0ac
12974973503046: XenPCI     New Start = 000000001b0ac000, Length = 4096
12974973503046: XenPCI     CmResourceTypeMemory (1)
12974973503046: XenPCI     Start = f2000001, Length = 0
12974973503046: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503046: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503046: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503062: XenPCI     path = device/vbd/5632
12974973503062: XenPCI     WdfPowerDeviceD3Final
12974973503062: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503062: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503062: XenPCI --> XenPci_UpdateBackendState
12974973503078: XenPCI --> XenConfig_InitConfigPage
12974973503078: XenPCI     Backend State Changed to InitWait
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503078: XenPCI <-- XenPci_UpdateBackendState
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503078: XenPCI     fdo_driver_extension = 0000000000000000
12974973503078: XenPCI <-- XenConfig_InitConfigPage
12974973503078: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503078: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503093: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503093: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503093: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503093: XenVbd     IRQL = 0
12974973503093: XenVbd     xvdd = FFFFFA80013C8008
12974973503093: XenVbd     BusInterruptLevel = 28
12974973503093: XenVbd     BusInterruptVector = 01c
12974973503093: XenVbd     NumberOfAccessRanges = 1
12974973503093: XenVbd     RangeStart = 1b0ac000, RangeLength = 00001000
12974973503093: XenVbd --> XenVbd_InitConfig
12974973503109: XenVbd     XEN_INIT_TYPE_13
12974973503109: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503109: XenVbd     XEN_INIT_TYPE_11
12974973503109: XenVbd     XEN_INIT_TYPE_17
12974973503109: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503109: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
12974973503109: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 9
12974973503109: XenPCI --> XenPci_DeviceWatchHandler
12974973503109: XenPCI --> EvtChn_BindDpc
12974973503109: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- EvtChn_BindDpc
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_ChangeFrontendState
12974973503125: XenPCI --> XenPci_DeviceWatchHandler
12974973503125: XenPCI <-- XenPci_DeviceWatchHandler
12974973503125: XenPCI --> XenPci_UpdateBackendState
12974973503140: XenPCI     Backend State Changed to Connected
12974973503140: XenPCI <-- XenPci_UpdateBackendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503140: XenPCI --> XenPci_ChangeFrontendState
12974973503140: XenPCI <-- XenPci_ChangeFrontendState
12974973503140: XenPCI --> XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503156: XenPCI <-- XenPci_DeviceWatchHandler
12974973503156: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503156: XenVbd <-- XenVbd_InitConfig
12974973503156: XenVbd --> XenVbd_InitFromConfig
12974973503156: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503156: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 00000000013795D0
12974973503156: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA80013D7000
12974973503156: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 9 (00000009)
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503156: XenVbd     device-type = CDROM
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503156: XenVbd     mode = r
12974973503156: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 6544648
12974973503171: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503171: XenVbd     qemu_hide_flags_value = 1
12974973503171: XenVbd     Device is inactive
12974973503171: XenVbd <-- XenVbd_InitFromConfig
12974973503171: XenVbd     aligned_buffer_data = FFFFFA80013CA8E8
12974973503171: XenVbd     aligned_buffer = FFFFFA80013CB000
12974973503171: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503171: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503171: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503187: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503187: XenVbd     Dma64BitAddresses supported
12974973503187: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503187: XenVbd --> XenVbd_HwStorInitialize
12974973503187: XenVbd     IRQL = 0
12974973503187: XenVbd     dump_mode = 0
12974973503187: XenVbd <-- XenVbd_HwStorInitialize
12974973503187: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenVbd     Inactive srb->Function = 00000000
12974973503203: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503203: XenPCI     device/vbd/768
12974973503203: XenPCI     CmResourceTypeMemory (0)
12974973503203: XenPCI     Start = f2000000, Length = 0
12974973503203: XenPCI     pfn[0] = 0001afad
12974973503203: XenPCI     New Start = 000000001afad000, Length = 4096
12974973503203: XenPCI     CmResourceTypeMemory (1)
12974973503203: XenPCI     Start = f2000001, Length = 0
12974973503218: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503218: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503234: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503234: XenPCI     path = device/vbd/768
12974973503234: XenPCI     WdfPowerDeviceD3Final
12974973503234: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503234: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503234: XenPCI --> XenPci_UpdateBackendState
12974973503234: XenPCI --> XenConfig_InitConfigPage
12974973503234: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503250: XenPCI     Backend State Changed to InitWait
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenPci_UpdateBackendState
12974973503250: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503250: XenPCI     fdo_driver_extension = 0000000000000000
12974973503250: XenPCI <-- XenConfig_InitConfigPage
12974973503250: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503265: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503265: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503265: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503281: XenVbd     IRQL = 0
12974973503281: XenVbd     xvdd = FFFFFA800141B008
12974973503281: XenVbd     BusInterruptLevel = 28
12974973503281: XenVbd     BusInterruptVector = 01c
12974973503281: XenVbd     NumberOfAccessRanges = 1
12974973503281: XenVbd     RangeStart = 1afad000, RangeLength = 00001000
12974973503281: XenVbd --> XenVbd_InitConfig
12974973503281: XenVbd     XEN_INIT_TYPE_13
12974973503281: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503296: XenVbd     XEN_INIT_TYPE_11
12974973503296: XenVbd     XEN_INIT_TYPE_17
12974973503296: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503296: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16382
12974973503296: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 10
12974973503312: XenPCI --> XenPci_DeviceWatchHandler
12974973503328: XenPCI --> EvtChn_BindDpc
12974973503343: XenPCI <-- XenPci_DeviceWatchHandler
12974973503343: XenPCI <-- EvtChn_BindDpc
12974973503343: XenPCI --> XenPci_DeviceWatchHandler
12974973503343: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503375: XenPCI <-- XenPci_DeviceWatchHandler
12974973503375: XenPCI --> XenPci_ChangeFrontendState
12974973503390: XenPCI --> XenPci_DeviceWatchHandler
12974973503390: XenPCI <-- XenPci_DeviceWatchHandler
12974973503390: XenPCI --> XenPci_UpdateBackendState
12974973503406: XenPCI     Backend State Changed to Connected
12974973503406: XenPCI <-- XenPci_UpdateBackendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendState
12974973503406: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503406: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503421: XenPCI --> XenPci_ChangeFrontendState
12974973503421: XenPCI <-- XenPci_ChangeFrontendState
12974973503421: XenPCI --> XenPci_DeviceWatchHandler
12974973503421: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503437: XenPCI <-- XenPci_DeviceWatchHandler
12974973503437: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503437: XenVbd <-- XenVbd_InitConfig
12974973503437: XenVbd --> XenVbd_InitFromConfig
12974973503437: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503437: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137B5D0
12974973503437: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800142A000
12974973503453: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 10 (0000000a)
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = disk
12974973503453: XenVbd     device-type = Disk
12974973503453: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = w
12974973503453: XenVbd     mode = w
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 44038000
12974973503468: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503468: XenVbd     qemu_hide_flags_value = 1
12974973503468: XenVbd <-- XenVbd_InitFromConfig
12974973503468: XenVbd     aligned_buffer_data = FFFFFA800141D8E8
12974973503468: XenVbd     aligned_buffer = FFFFFA800141E000
12974973503484: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503484: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503484: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503484: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503500: XenVbd     Dma64BitAddresses supported
12974973503500: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503515: XenVbd --> XenVbd_HwStorInitialize
12974973503515: XenVbd     IRQL = 0
12974973503515: XenVbd     dump_mode = 0
12974973503515: XenVbd <-- XenVbd_HwStorInitialize
12974973503515: XenVbd --- HwStorStartIo (Still figuring out ring)
12974973503531: XenVbd     ring_detect_state = 1, index = 0, operation
= ff, id = 0, status = -1
12974973503531: XenVbd     req_prod = 2, rsp_prod = 1, rsp_cons = 0
12974973503531: XenVbd     ring_detect_state = 2, index = 1, operation
= ff, id = 0, status = -1
12974973503546: XenVbd     req_prod = 2, rsp_prod = 2, rsp_cons = 1
12974973503656: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973503656: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973503656: XenVbd     SRB_FUNCTION_PNP
12974973503671: XenVbd      StorQueryCapabilities
12974973503671: XenVbd      SrbPnPFlags = 00000000
12974973503671: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503718: XenPCI     device/vbd/832
12974973503718: XenPCI     CmResourceTypeMemory (0)
12974973503718: XenPCI     Start = f2000000, Length = 0
12974973503718: XenPCI     pfn[0] = 0001afae
12974973503718: XenPCI     New Start = 000000001afae000, Length = 4096
12974973503718: XenPCI     CmResourceTypeMemory (1)
12974973503718: XenPCI     Start = f2000001, Length = 0
12974973503718: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973503734: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973503734: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973503734: XenPCI     path = device/vbd/832
12974973503734: XenPCI     WdfPowerDeviceD3Final
12974973503734: XenPCI --> XenPci_GetBackendAndAddWatch
12974973503734: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973503734: XenPCI --> XenPci_UpdateBackendState
12974973503750: XenPCI --> XenConfig_InitConfigPage
12974973503750: XenPCI     Backend State Changed to InitWait
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000CFB8A0
12974973503750: XenPCI <-- XenPci_UpdateBackendState
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973503750: XenPCI     fdo_driver_extension = 0000000000000000
12974973503750: XenPCI <-- XenConfig_InitConfigPage
12974973503750: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503750: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503750: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503765: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503765: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973503765: XenVbd --> XenVbd_VirtualHwStorFindAdapter
12974973503765: XenVbd     IRQL = 0
12974973503765: XenVbd     xvdd = FFFFFA8001471008
12974973503765: XenVbd     BusInterruptLevel = 28
12974973503765: XenVbd     BusInterruptVector = 01c
12974973503781: XenVbd     NumberOfAccessRanges = 1
12974973503781: XenVbd     RangeStart = 1afae000, RangeLength = 00001000
12974973503781: XenVbd --> XenVbd_InitConfig
12974973503781: XenVbd     XEN_INIT_TYPE_13
12974973503781: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503796: XenVbd     XEN_INIT_TYPE_11
12974973503796: XenVbd     XEN_INIT_TYPE_17
12974973503796: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503796: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16381
12974973503812: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 11
12974973503828: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> EvtChn_BindDpc
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- EvtChn_BindDpc
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503843: XenPCI --> XenPci_ChangeFrontendState
12974973503843: XenPCI --> XenPci_DeviceWatchHandler
12974973503843: XenPCI <-- XenPci_DeviceWatchHandler
12974973503859: XenPCI --> XenPci_UpdateBackendState
12974973503859: XenPCI     Backend State Changed to Connected
12974973503859: XenPCI <-- XenPci_UpdateBackendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendStateMap
12974973503859: XenPCI --> XenPci_ChangeFrontendState
12974973503859: XenPCI <-- XenPci_ChangeFrontendState
12974973503859: XenPCI --> XenPci_DeviceWatchHandler
12974973503859: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973503875: XenPCI <-- XenPci_DeviceWatchHandler
12974973503875: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973503875: XenVbd <-- XenVbd_InitConfig
12974973503875: XenVbd --> XenVbd_InitFromConfig
12974973503875: XenVbd     XEN_INIT_TYPE_VECTORS
12974973503875: XenVbd     XEN_INIT_TYPE_DEVICE_STATE - 000000000137C9C0
12974973503875: XenVbd     XEN_INIT_TYPE_RING - ring-ref = FFFFFA8001480000
12974973503875: XenVbd     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel
= 11 (0000000b)
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - device-type = cdrom
12974973503875: XenVbd     device-type = CDROM
12974973503875: XenVbd     XEN_INIT_TYPE_READ_STRING - mode = r
12974973503875: XenVbd     mode = r
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sectors = 422560
12974973503890: XenVbd     XEN_INIT_TYPE_READ_STRING - sector-size = 512
12974973503890: XenVbd     qemu_hide_flags_value = 1
12974973503890: XenVbd     Device is inactive
12974973503890: XenVbd <-- XenVbd_InitFromConfig
12974973503890: XenVbd     aligned_buffer_data = FFFFFA80014738E8
12974973503890: XenVbd     aligned_buffer = FFFFFA8001474000
12974973503890: XenVbd     ConfigInfo->MaximumTransferLength = 4194304
12974973503890: XenVbd     ConfigInfo->NumberOfPhysicalBreaks = 1024
12974973503890: XenVbd     ConfigInfo->VirtualDevice = 1
12974973503906: XenVbd     ConfigInfo->NeedPhysicalAddresses = 1
12974973503906: XenVbd     Dma64BitAddresses supported
12974973503906: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
12974973503906: XenVbd --> XenVbd_HwStorInitialize
12974973503906: XenVbd     IRQL = 0
12974973503906: XenVbd     dump_mode = 0
12974973503906: XenVbd <-- XenVbd_HwStorInitialize
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503906: XenVbd     Inactive srb->Function = 00000000
12974973503921: XenVbd     SRB_FUNCTION_IO_CONTROL
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 28, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 8, allocation_length = 192
12974973503937: XenVbd     SRB_FUNCTION_PNP
12974973503937: XenVbd      StorQueryCapabilities
12974973503937: XenVbd      SrbPnPFlags = 00000000
12974973504203: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973504218: XenVbd     Inactive srb->Function = 00000017
12974973504218: XenVbd     Unhandled srb->Function = 00000017
12974973505265: Trying to enable physical device already in use.
12974973524343: XenNet --> DriverEntry
12974973524343: XenNet     Driver MajorNdisVersion = 6, Driver
MinorNdisVersion = 1
12974973524359: XenNet     Windows MajorNdisVersion = 6, Windows
MinorNdisVersion = 20
12974973524359: XenNet --> XenNet_SetOptions
12974973524359: XenNet <-- XenNet_SetOptions
12974973524359: XenNet <-- DriverEntry
12974973524359: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524375: XenPCI     device/vif/0
12974973524375: XenPCI     CmResourceTypeMemory (0)
12974973524375: XenPCI     Start = f2000000, Length = 0
12974973524375: XenPCI     pfn[0] = 0001afaf
12974973524375: XenPCI     New Start = 000000001afaf000, Length = 4096
12974973524375: XenPCI     CmResourceTypeMemory (1)
12974973524390: XenPCI     Start = f2000001, Length = 0
12974973524390: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
12974973524390: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
12974973524390: XenPCI --> XenPciPdo_EvtDeviceD0Entry
12974973524390: XenPCI     path = device/vif/0
12974973524406: XenPCI     WdfPowerDeviceD3Final
12974973524406: XenPCI --> XenPci_GetBackendAndAddWatch
12974973524406: XenPCI <-- XenPci_GetBackendAndAddWatch
12974973524406: XenPCI --> XenPci_UpdateBackendState
12974973524421: XenPCI --> XenConfig_InitConfigPage
12974973524421: XenPCI     Backend State Changed to InitWait
12974973524421: XenPCI     fdo_driver_object = FFFFFA8001BB7060
12974973524421: XenPCI <-- XenPci_UpdateBackendState
12974973524421: XenPCI     fdo_driver_extension = 0000000000000000
12974973524421: XenPCI     fdo_driver_object = FFFFFA8000F93DE0
12974973524437: XenPCI     fdo_driver_extension = 0000000000000000
12974973524437: XenPCI <-- XenConfig_InitConfigPage
12974973524437: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524437: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524437: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524453: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524453: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
12974973524468: XenNet --> XenNet_Initialize
12974973524468: XenNet     XEN_INIT_TYPE_13
12974973524468: XenNet     XEN_INIT_TYPE_VECTORS
12974973524468: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524468: ScatterGather = 1
12974973524468: LargeSendOffload = 61440
12974973524500: LargeSendOffloadRxSplitMTU = 1
12974973524500: ChecksumOffload = 1
12974973524500: MTU = 1500
12974973524515: Could not read NetworkAddress value (c0000001) or
value is invalid
12974973524515: XenNet --> XenNet_D0Entry
12974973524515: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524515: XenPCI     XEN_INIT_TYPE_RING - tx-ring-ref = 16380
12974973524531: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524546: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_RING - rx-ring-ref = 16379
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524562: XenPCI --> XenPci_DeviceWatchHandler
12974973524562: XenPCI --> EvtChn_Bind
12974973524562: XenPCI <-- XenPci_DeviceWatchHandler
12974973524562: XenPCI <-- EvtChn_Bind
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendStateMap
12974973524578: XenPCI --> XenPci_DeviceWatchHandler
12974973524578: XenPCI --> XenPci_ChangeFrontendState
12974973524578: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_DeviceWatchHandler
12974973524593: XenPCI <-- XenPci_DeviceWatchHandler
12974973524593: XenPCI --> XenPci_UpdateBackendState
12974973524593: XenPCI     Backend State Changed to Connected
12974973524593: XenPCI <-- XenPci_UpdateBackendState
12974973524593: XenPCI <-- XenPci_ChangeFrontendState
12974973524609: XenPCI <-- XenPci_ChangeFrontendStateMap
12974973524609: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
12974973524609: XenNet --> XenNet_ConnectBackend
12974973524609: XenNet     XEN_INIT_TYPE_13
12974973524609: XenNet     XEN_INIT_TYPE_VECTORS
12974973524609: XenNet     XEN_INIT_TYPE_DEVICE_STATE - 000000000137F5D0
12974973524609: XenNet     XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8001BBC000
12974973524609: XenNet     XEN_INIT_TYPE_RING - rx-ring-ref = FFFFFA8001BBD000
12974973524609: XenNet     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 12
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - mac = 00:16:3e:00:17:b9
12974973524609: XenNet     XEN_INIT_TYPE_READ_STRING - feature-sg = 1
12974973524625: XenNet     XEN_INIT_TYPE_READ_STRING - feature-gso-tcpv4 = 1
12974973524625: XenNet     XEN_INIT_TYPE_17
12974973524625: XenNet <-- XenNet_ConnectBackend
12974973524625: XenNet --> XenNet_RxInit
12974973524625: XenNet <-- XenNet_RxInit
12974973524625: XenNet <-- XenNet_D0Entry
12974973524640: XenNet     Supporting 00010102
(OID_GEN_HARDWARE_STATUS) get only 4 bytes
12974973524640: XenNet     Supporting 00010108
(OID_GEN_TRANSMIT_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 00010109
(OID_GEN_RECEIVE_BUFFER_SPACE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010a
(OID_GEN_TRANSMIT_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010b
(OID_GEN_RECEIVE_BLOCK_SIZE) get only 4 bytes
12974973524640: XenNet     Supporting 0001010c (OID_GEN_VENDOR_ID) get
only 4 bytes
12974973524656: XenNet     Supporting 0001010d
(OID_GEN_VENDOR_DESCRIPTION) get only 10 bytes
12974973524656: XenNet     Supporting 00010116
(OID_GEN_VENDOR_DRIVER_VERSION) get only 4 bytes
12974973524656: XenNet     Supporting 0001010e
(OID_GEN_CURRENT_PACKET_FILTER) get/set 4 bytes
12974973524656: XenNet     Supporting 0001010f
(OID_GEN_CURRENT_LOOKAHEAD) get/set 4 bytes
12974973524656: XenNet     Supporting 00010111
(OID_GEN_MAXIMUM_TOTAL_SIZE) get only 4 bytes
12974973524656: XenNet     Supporting 00010208
(OID_GEN_LINK_PARAMETERS) set only 32 bytes
12974973524656: XenNet     Supporting 00010209
(OID_GEN_INTERRUPT_MODERATION) get/set 12 bytes
12974973524671: XenNet     Supporting 00010115
(OID_GEN_MAXIMUM_SEND_PACKETS) get only 4 bytes
12974973524671: XenNet     Supporting 00010103
(OID_GEN_MEDIA_SUPPORTED) get only 4 bytes
12974973524671: XenNet     Supporting 00010104 (OID_GEN_MEDIA_IN_USE)
get only 4 bytes
12974973524671: XenNet     Supporting 00010105
(OID_GEN_MAXIMUM_LOOKAHEAD) get only 4 bytes
12974973524671: XenNet     Supporting 00010118
(OID_GEN_NETWORK_LAYER_ADDRESSES) set only 6 bytes
12974973524671: XenNet     Supporting 0001021a (OID_GEN_MACHINE_NAME)
set only 0 bytes
12974973524687: XenNet     Supporting 0101010a
(OID_OFFLOAD_ENCAPSULATION) set only 28 bytes
12974973524687: XenNet     Supporting fd010101 (OID_PNP_SET_POWER) set
only 4 bytes
12974973524687: XenNet     Supporting 00020101 (OID_GEN_XMIT_OK) get
only 0 bytes
12974973524687: XenNet     Supporting 00020102 (OID_GEN_RCV_OK) get only 0 bytes
12974973524687: XenNet     Supporting 00020103 (OID_GEN_XMIT_ERROR)
get only 0 bytes
12974973524703: XenNet     Supporting 00020104 (OID_GEN_RCV_ERROR) get
only 0 bytes
12974973524703: XenNet     Supporting 00020105 (OID_GEN_RCV_NO_BUFFER)
get only 0 bytes
12974973524703: XenNet     Supporting 01020101
(OID_802_3_RCV_ERROR_ALIGNMENT) get only 0 bytes
12974973524703: XenNet     Supporting 01020102
(OID_802_3_XMIT_ONE_COLLISION) get only 0 bytes
12974973524703: XenNet     Supporting 01020103
(OID_802_3_XMIT_MORE_COLLISIONS) get only 0 bytes
12974973524703: XenNet     Supporting fc010209 (OID_IP4_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting fc01020a (OID_IP6_OFFLOAD_STATS)
none 0 bytes
12974973524718: XenNet     Supporting 00020106 (OID_GEN_STATISTICS)
get only 152 bytes
12974973524718: XenNet     Supporting 01010101
(OID_802_3_PERMANENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010102
(OID_802_3_CURRENT_ADDRESS) get only 6 bytes
12974973524718: XenNet     Supporting 01010103
(OID_802_3_MULTICAST_LIST) get/set 0 bytes
12974973524734: XenNet     Supporting 01010104
(OID_802_3_MAXIMUM_LIST_SIZE) get only 4 bytes
12974973524734: XenNet     name = minint-ps2nl91
12974973524734: XenNet --> XenNet_Restart
12974973524734: XenNet <-- XenNet_Restart
12974973524734: XenNet --> XenNet_DevicePnPEventNotify
12974973524734: XenNet     NdisDevicePnPEventPowerProfileChanged
12974973524734: XenNet <-- XenNet_DevicePnPEventNotify
12974973524734: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 62 (FFFFFA8001BB9000)
12974973524750: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524750: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524750: XenNet     Unsupported OID 00010117
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524750: XenNet     Unknown Encapsulation Type 0
12974973524781: XenNet     Set OID_GEN_CURRENT_LOOKAHEAD 82 (FFFFFA8001BB9000)
12974973524781: XenNet     NDIS_PACKET_TYPE_DIRECTED
12974973524796: XenNet     NDIS_PACKET_TYPE_MULTICAST
12974973524796: XenNet     NDIS_PACKET_TYPE_BROADCAST
12974973524796: XenNet      IPv4.Enabled = NDIS_OFFLOAD_SET_ON
12974973524796: XenNet      IPv4.HeaderSize = 14
12974973524796: XenNet      IPv6.EncapsulationType = 0
12974973524796: XenNet      IPv6.Enabled = NDIS_OFFLOAD_SET_OFF
12974973524812: XenNet      IPv6.HeaderSize = 0
12974973534531: XenNet     AddressType = 2
12974973534531: XenNet     AddressCount = 1
12974973534531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973534531: XenNet     Address[0].Length = 16
12974973534531: XenNet     Address[0].in_addr = 169.254.239.84
12974973586906: XenPCI --> XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenBus_DeviceFileInit
12974973586921: XenPCI <-- XenPci_EvtDeviceFileCreate
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoWrite
12974973586921: XenPCI     36 bytes of write buffer remaining
12974973586921: XenPCI     completing request with length 36
12974973586921: XenPCI <-- XenBus_EvtIoWrite
12974973586921: XenPCI <-- XenPci_EvtIoDefault
12974973586921: XenPCI --> XenPci_EvtIoDefault
12974973586921: XenPCI --> XenBus_EvtIoRead
12974973586921: XenPCI     found pending read
12974973586937: XenPCI <-- XenBus_ProcessReadRequest
12974973586937: XenPCI <-- XenBus_EvtIoRead
12974973586937: XenPCI <-- XenPci_EvtIoDefault
12974973586937: XenPCI --> XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenBus_EvtFileCleanup
12974973586937: XenPCI <-- XenPci_EvtFileCleanup
12974973586937: XenPCI --> XenPci_EvtFileClose
12974973586937: XenPCI --> XenBus_EvtFileClose
12974973586937: XenPCI <-- XenBus_EvtFileClose
12974973586937: XenPCI <-- XenPci_EvtFileClose
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591531: XenNet     Address[0].Length = 16
12974973591531: XenNet     Address[0].in_addr = 62.76.47.68
12974973591531: XenNet     AddressType = 2
12974973591531: XenNet     AddressCount = 1
12974973591531: XenNet     Address[0].Type = NDIS_PROTOCOL_ID_TCP_IP
12974973591546: XenNet     Address[0].Length = 16
12974973591546: XenNet     Address[0].in_addr = 62.76.47.68
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973604156: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973612640: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613343: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613359: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613390: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613453: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613468: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613484: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613500: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613531: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613812: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613859: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613875: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613890: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613906: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613921: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613937: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613953: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613968: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973613984: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973614015: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973617375: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973618406: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629578: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629593: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629718: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629750: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629765: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629828: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973629843: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635703: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Inactive srb->Function = 00000000
12974973635718: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973635718: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635718: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973635734: XenVbd     Inactive srb->Function = 00000000
12974973640703: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648015: XenVbd     Unhandled EXECUTE_SCSI Command = A0
12974973648015: XenVbd     EXECUTE_SCSI Command = A0 returned error 00
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd --- HwStorStartIo (Out of bounds - PathId = 0,
TargetId = 1, Lun = 0)
12974973648015: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973648031: XenVbd     Inactive srb->Function = 00000000
12974973652000: XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0,
page_code = 63, allocation_length = 192


-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:37:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2guQ-0005GX-DK; Wed, 29 Feb 2012 10:37:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2guP-0005G3-66
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:37:21 +0000
Received: from [85.158.139.83:6962] by server-12.bemta-5.messagelabs.com id
	BB/48-05587-0EFFD4F4; Wed, 29 Feb 2012 10:37:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330511839!13325830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13504 invoked from network); 29 Feb 2012 10:37:19 -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;
	29 Feb 2012 10:37:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11004974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:37:19 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 10:37:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 10:36:26 +0000
Message-ID: <1330511786.10387.32.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	wei.liu2@citrix.com
Subject: [Xen-devel] Question on grant copying a previous grant mapped page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all

I'm implementing a TX zero-copy prototype for Xen netback. It is very
common for several guests to connect through a bridge and communicate
with each other. So in the RX path there is something like:

if (page is from another domU)
  retrieve this page's src_gref and owner src_dom
  grant copy this (src_dom,src_gref) to dest domU (dst_dom,dst_gref)

Actually the code is doing grant copy from one gref to another gref,
only that the src_gref has been already mapped in Dom0.

Then we go down to hypervisor:

__gnttab_copy
{
  __acquire_grant_for_copy(src_gref)
  __acquire_grant_for_copy(dst_gref)
  ...copy...
  __release_grant_for_copy(src_gref)
  __release_grant_for_cooy(dst_gref)
}

__acquire_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (!act->pin) {
    check stuff for transitive grant
    if (!act->pin) {
      set fields in act
    }
  } else {
    set owning_domain
  }
}

__release_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (grant table version is 1) {
    use v1 stuff
  } else {
    td = act->trans_domain
    trans_gref = act->trans_gref
  }
  if (td != rd) {
    recursively release grant
    rcu_unlock_domain(td)
  }
}

Because src_gref is already mapped in Dom0, so its act->pin is not 0.
When we come to __release_grant_for_copy, since we're using version 2,
so td = act->trans_domain, in which case it is NULL(?!). rd is not NULL,
so (td != rd), we do a rcu_unlock_domain(NULL), which messes up the
preemption count. Finally it triggers ASSERT(!in_atomic()) in
do_softirq.

I haven't modified netfront to use transitive grant. I don't know
whether I found a bug or I did things in a wrong way. However
rcu_unlocking NULL looks quite buggy to me, shouldn't we at least guard
against this case and fail earlier (in grant release code path)?

Any advice is welcomed.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:37:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2guQ-0005GX-DK; Wed, 29 Feb 2012 10:37:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2guP-0005G3-66
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:37:21 +0000
Received: from [85.158.139.83:6962] by server-12.bemta-5.messagelabs.com id
	BB/48-05587-0EFFD4F4; Wed, 29 Feb 2012 10:37:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330511839!13325830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13504 invoked from network); 29 Feb 2012 10:37:19 -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;
	29 Feb 2012 10:37:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11004974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:37:19 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 10:37:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 10:36:26 +0000
Message-ID: <1330511786.10387.32.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	wei.liu2@citrix.com
Subject: [Xen-devel] Question on grant copying a previous grant mapped page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all

I'm implementing a TX zero-copy prototype for Xen netback. It is very
common for several guests to connect through a bridge and communicate
with each other. So in the RX path there is something like:

if (page is from another domU)
  retrieve this page's src_gref and owner src_dom
  grant copy this (src_dom,src_gref) to dest domU (dst_dom,dst_gref)

Actually the code is doing grant copy from one gref to another gref,
only that the src_gref has been already mapped in Dom0.

Then we go down to hypervisor:

__gnttab_copy
{
  __acquire_grant_for_copy(src_gref)
  __acquire_grant_for_copy(dst_gref)
  ...copy...
  __release_grant_for_copy(src_gref)
  __release_grant_for_cooy(dst_gref)
}

__acquire_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (!act->pin) {
    check stuff for transitive grant
    if (!act->pin) {
      set fields in act
    }
  } else {
    set owning_domain
  }
}

__release_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (grant table version is 1) {
    use v1 stuff
  } else {
    td = act->trans_domain
    trans_gref = act->trans_gref
  }
  if (td != rd) {
    recursively release grant
    rcu_unlock_domain(td)
  }
}

Because src_gref is already mapped in Dom0, so its act->pin is not 0.
When we come to __release_grant_for_copy, since we're using version 2,
so td = act->trans_domain, in which case it is NULL(?!). rd is not NULL,
so (td != rd), we do a rcu_unlock_domain(NULL), which messes up the
preemption count. Finally it triggers ASSERT(!in_atomic()) in
do_softirq.

I haven't modified netfront to use transitive grant. I don't know
whether I found a bug or I did things in a wrong way. However
rcu_unlocking NULL looks quite buggy to me, shouldn't we at least guard
against this case and fail earlier (in grant release code path)?

Any advice is welcomed.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:40:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10: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 1S2gwm-0005TM-Uk; Wed, 29 Feb 2012 10:39:48 +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 1S2gwj-0005Sn-4P
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:39:47 +0000
Received: from [85.158.139.83:28348] by server-4.bemta-5.messagelabs.com id
	C2/CB-10788-0700E4F4; Wed, 29 Feb 2012 10:39:44 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330511983!9860971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10960 invoked from network); 29 Feb 2012 10:39:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 10:39:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005033"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:39:43 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 29 Feb 2012
	10:39:43 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>, xen-devel
	<xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 10:39:42 +0000
Thread-Topic: Question on grant copying a previous grant mapped page
Thread-Index: Acz2zhzHS4ysQiaWSHOIykz5ZbEfEAAADEQA
Message-ID: <291EDFCB1E9E224A99088639C4762022C8115F63F7@LONPMAILBOX01.citrite.net>
References: <1330511786.10387.32.camel@leeds.uk.xensource.com>
In-Reply-To: <1330511786.10387.32.camel@leeds.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] Question on grant copying a previous grant mapped
	page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

That sounds like a basic bug in gnttab2 and it also sounds very similar to something I thought I already fixed.

  Paul

> -----Original Message-----
> From: Wei Liu (Intern)
> Sent: 29 February 2012 10:36
> To: xen-devel
> Cc: Wei Liu (Intern); Keir (Xen.org); Paul Durrant
> Subject: Question on grant copying a previous grant mapped page
> 
> Hi all
> 
> I'm implementing a TX zero-copy prototype for Xen netback. It is very
> common for several guests to connect through a bridge and communicate
> with each other. So in the RX path there is something like:
> 
> if (page is from another domU)
>   retrieve this page's src_gref and owner src_dom
>   grant copy this (src_dom,src_gref) to dest domU (dst_dom,dst_gref)
> 
> Actually the code is doing grant copy from one gref to another gref, only
> that the src_gref has been already mapped in Dom0.
> 
> Then we go down to hypervisor:
> 
> __gnttab_copy
> {
>   __acquire_grant_for_copy(src_gref)
>   __acquire_grant_for_copy(dst_gref)
>   ...copy...
>   __release_grant_for_copy(src_gref)
>   __release_grant_for_cooy(dst_gref)
> }
> 
> __acquire_grant_for_copy(rd,gref)
> {
>   act <- get active entry for gref
>   if (!act->pin) {
>     check stuff for transitive grant
>     if (!act->pin) {
>       set fields in act
>     }
>   } else {
>     set owning_domain
>   }
> }
> 
> __release_grant_for_copy(rd,gref)
> {
>   act <- get active entry for gref
>   if (grant table version is 1) {
>     use v1 stuff
>   } else {
>     td = act->trans_domain
>     trans_gref = act->trans_gref
>   }
>   if (td != rd) {
>     recursively release grant
>     rcu_unlock_domain(td)
>   }
> }
> 
> Because src_gref is already mapped in Dom0, so its act->pin is not 0.
> When we come to __release_grant_for_copy, since we're using version 2, so
> td = act->trans_domain, in which case it is NULL(?!). rd is not NULL, so (td !=
> rd), we do a rcu_unlock_domain(NULL), which messes up the preemption
> count. Finally it triggers ASSERT(!in_atomic()) in do_softirq.
> 
> I haven't modified netfront to use transitive grant. I don't know whether I
> found a bug or I did things in a wrong way. However rcu_unlocking NULL
> looks quite buggy to me, shouldn't we at least guard against this case and
> fail earlier (in grant release code path)?
> 
> Any advice is welcomed.
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:40:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10: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 1S2gwm-0005TM-Uk; Wed, 29 Feb 2012 10:39:48 +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 1S2gwj-0005Sn-4P
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:39:47 +0000
Received: from [85.158.139.83:28348] by server-4.bemta-5.messagelabs.com id
	C2/CB-10788-0700E4F4; Wed, 29 Feb 2012 10:39:44 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330511983!9860971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10960 invoked from network); 29 Feb 2012 10:39:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 10:39:43 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005033"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:39:43 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 29 Feb 2012
	10:39:43 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>, xen-devel
	<xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 10:39:42 +0000
Thread-Topic: Question on grant copying a previous grant mapped page
Thread-Index: Acz2zhzHS4ysQiaWSHOIykz5ZbEfEAAADEQA
Message-ID: <291EDFCB1E9E224A99088639C4762022C8115F63F7@LONPMAILBOX01.citrite.net>
References: <1330511786.10387.32.camel@leeds.uk.xensource.com>
In-Reply-To: <1330511786.10387.32.camel@leeds.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] Question on grant copying a previous grant mapped
	page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

That sounds like a basic bug in gnttab2 and it also sounds very similar to something I thought I already fixed.

  Paul

> -----Original Message-----
> From: Wei Liu (Intern)
> Sent: 29 February 2012 10:36
> To: xen-devel
> Cc: Wei Liu (Intern); Keir (Xen.org); Paul Durrant
> Subject: Question on grant copying a previous grant mapped page
> 
> Hi all
> 
> I'm implementing a TX zero-copy prototype for Xen netback. It is very
> common for several guests to connect through a bridge and communicate
> with each other. So in the RX path there is something like:
> 
> if (page is from another domU)
>   retrieve this page's src_gref and owner src_dom
>   grant copy this (src_dom,src_gref) to dest domU (dst_dom,dst_gref)
> 
> Actually the code is doing grant copy from one gref to another gref, only
> that the src_gref has been already mapped in Dom0.
> 
> Then we go down to hypervisor:
> 
> __gnttab_copy
> {
>   __acquire_grant_for_copy(src_gref)
>   __acquire_grant_for_copy(dst_gref)
>   ...copy...
>   __release_grant_for_copy(src_gref)
>   __release_grant_for_cooy(dst_gref)
> }
> 
> __acquire_grant_for_copy(rd,gref)
> {
>   act <- get active entry for gref
>   if (!act->pin) {
>     check stuff for transitive grant
>     if (!act->pin) {
>       set fields in act
>     }
>   } else {
>     set owning_domain
>   }
> }
> 
> __release_grant_for_copy(rd,gref)
> {
>   act <- get active entry for gref
>   if (grant table version is 1) {
>     use v1 stuff
>   } else {
>     td = act->trans_domain
>     trans_gref = act->trans_gref
>   }
>   if (td != rd) {
>     recursively release grant
>     rcu_unlock_domain(td)
>   }
> }
> 
> Because src_gref is already mapped in Dom0, so its act->pin is not 0.
> When we come to __release_grant_for_copy, since we're using version 2, so
> td = act->trans_domain, in which case it is NULL(?!). rd is not NULL, so (td !=
> rd), we do a rcu_unlock_domain(NULL), which messes up the preemption
> count. Finally it triggers ASSERT(!in_atomic()) in do_softirq.
> 
> I haven't modified netfront to use transitive grant. I don't know whether I
> found a bug or I did things in a wrong way. However rcu_unlocking NULL
> looks quite buggy to me, shouldn't we at least guard against this case and
> fail earlier (in grant release code path)?
> 
> Any advice is welcomed.
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:43:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2h0K-0005n3-Ig; Wed, 29 Feb 2012 10:43:28 +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 1S2h0J-0005mh-FB
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:43:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330512173!58819524!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13419 invoked from network); 29 Feb 2012 10:42:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 29 Feb 2012 10:42:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330512205; l=769;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=LWQ+xoWkfyEcCHX9rVQhfe32A+c=;
	b=oTkublP07HdVoC+jJRP/Kz7J8swrtA3F5x6Xe7u6KxxVhLYWA3t1yEoXAy/WWNRQevA
	RecaGBTKFCRkDDZkGaJDvQO4Nt4EwO8DoLcQGQpRjWlvGaqy0OHJ9tEE8I2QAjNRezUVO
	taSRw/zmOjQYEVPAJburOl+sXLydwv+Qz7g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (klopstock mo56) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 50193co1TAFJBc ;
	Wed, 29 Feb 2012 11:43:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6950C18638; Wed, 29 Feb 2012 11:43:08 +0100 (CET)
Date: Wed, 29 Feb 2012 11:43:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120229104308.GA23724@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <104d17ef-192d-4a13-9d19-b27a58f04384@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, Dan Magenheimer wrote:

> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > To me memory overcommit means swapping, which is what xenpaging does:
> > turn the whole guest gfn range into some sort of virtual memory,
> > transparent to the guest.
> > 
> > xenpaging is the red emergency knob to free some host memory without
> > caring about the actual memory constraints within the paged guests.
> 
> Sure, but the whole point of increasing RAM in one or more guests
> is to increase performance, and if overcommitting *always* means
> swapping, why would anyone use it?

The usage patterns depend on the goal. As I wrote, swapping frees host
memory so it can be used for something else, like starting yet another
guest on the host.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:43:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2h0K-0005n3-Ig; Wed, 29 Feb 2012 10:43:28 +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 1S2h0J-0005mh-FB
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:43:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1330512173!58819524!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyMjY2OTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13419 invoked from network); 29 Feb 2012 10:42:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 29 Feb 2012 10:42:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330512205; l=769;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=LWQ+xoWkfyEcCHX9rVQhfe32A+c=;
	b=oTkublP07HdVoC+jJRP/Kz7J8swrtA3F5x6Xe7u6KxxVhLYWA3t1yEoXAy/WWNRQevA
	RecaGBTKFCRkDDZkGaJDvQO4Nt4EwO8DoLcQGQpRjWlvGaqy0OHJ9tEE8I2QAjNRezUVO
	taSRw/zmOjQYEVPAJburOl+sXLydwv+Qz7g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (klopstock mo56) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 50193co1TAFJBc ;
	Wed, 29 Feb 2012 11:43:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6950C18638; Wed, 29 Feb 2012 11:43:08 +0100 (CET)
Date: Wed, 29 Feb 2012 11:43:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120229104308.GA23724@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <104d17ef-192d-4a13-9d19-b27a58f04384@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 27, Dan Magenheimer wrote:

> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > To me memory overcommit means swapping, which is what xenpaging does:
> > turn the whole guest gfn range into some sort of virtual memory,
> > transparent to the guest.
> > 
> > xenpaging is the red emergency knob to free some host memory without
> > caring about the actual memory constraints within the paged guests.
> 
> Sure, but the whole point of increasing RAM in one or more guests
> is to increase performance, and if overcommitting *always* means
> swapping, why would anyone use it?

The usage patterns depend on the goal. As I wrote, swapping frees host
memory so it can be used for something else, like starting yet another
guest on the host.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:51:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10: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 1S2h7O-0006Jk-4Y; Wed, 29 Feb 2012 10:50:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2h7M-0006JU-TA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:50:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330512629!16656048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32552 invoked from network); 29 Feb 2012 10:50:38 -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;
	29 Feb 2012 10:50:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:50:29 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 10:50:29 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C8115F63F7@LONPMAILBOX01.citrite.net>
References: <1330511786.10387.32.camel@leeds.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C8115F63F7@LONPMAILBOX01.citrite.net>
Date: Wed, 29 Feb 2012 10:49:38 +0000
Message-ID: <1330512578.10387.36.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "Keir
	\(Xen.org\)" <keir@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] Question on grant copying a previous grant mapped
	page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 10:39 +0000, Paul Durrant wrote:
> That sounds like a basic bug in gnttab2 and it also sounds very similar to something I thought I already fixed.
> 
>   Paul

You mean this one?

changeset:   22994:299ed79acecf
user:        Keir Fraser <keir@xen.org>
date:        Tue Mar 08 16:30:30 2011 +0000
files:       xen/common/grant_table.c xen/include/xen/grant_table.h
description:
Fix rcu domain locking for transitive grants

When acquiring a transitive grant for copy then the owning domain
needs to be locked down as well as the granting domain. This was being
done, but the unlocking was not. The acquire code now stores the
struct domain * of the owning domain (rather than the domid) in the
active entry in the granting domain. The release code then does the
unlock on the owning domain.  Note that I believe I also fixed a bug
where, for non-transitive grants the active entry contained a
reference to the acquiring domain rather than the granting
domain. From my reading of the code this would stop the release code
for transitive grants from terminating its recursion correctly.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>


This is the non-transitive case, but active entry contains no reference
to any domain.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:51:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10: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 1S2h7O-0006Jk-4Y; Wed, 29 Feb 2012 10:50:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2h7M-0006JU-TA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:50:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1330512629!16656048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32552 invoked from network); 29 Feb 2012 10:50:38 -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;
	29 Feb 2012 10:50:38 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:50:29 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 10:50:29 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C8115F63F7@LONPMAILBOX01.citrite.net>
References: <1330511786.10387.32.camel@leeds.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C8115F63F7@LONPMAILBOX01.citrite.net>
Date: Wed, 29 Feb 2012 10:49:38 +0000
Message-ID: <1330512578.10387.36.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "Keir
	\(Xen.org\)" <keir@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] Question on grant copying a previous grant mapped
	page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 10:39 +0000, Paul Durrant wrote:
> That sounds like a basic bug in gnttab2 and it also sounds very similar to something I thought I already fixed.
> 
>   Paul

You mean this one?

changeset:   22994:299ed79acecf
user:        Keir Fraser <keir@xen.org>
date:        Tue Mar 08 16:30:30 2011 +0000
files:       xen/common/grant_table.c xen/include/xen/grant_table.h
description:
Fix rcu domain locking for transitive grants

When acquiring a transitive grant for copy then the owning domain
needs to be locked down as well as the granting domain. This was being
done, but the unlocking was not. The acquire code now stores the
struct domain * of the owning domain (rather than the domid) in the
active entry in the granting domain. The release code then does the
unlock on the owning domain.  Note that I believe I also fixed a bug
where, for non-transitive grants the active entry contained a
reference to the acquiring domain rather than the granting
domain. From my reading of the code this would stop the release code
for transitive grants from terminating its recursion correctly.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>


This is the non-transitive case, but active entry contains no reference
to any domain.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:57:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10: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 1S2hDh-0006XM-Uk; Wed, 29 Feb 2012 10:57:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2hDf-0006X7-Jy
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:57:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330513029!4169971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3054 invoked from network); 29 Feb 2012 10:57:09 -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;
	29 Feb 2012 10:57:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:57:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 10:57:09 +0000
Message-ID: <1330513027.4270.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 10:57:07 +0000
In-Reply-To: <CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
	<CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDEwOjE4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yOCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFR1ZSwgMjAxMi0wMi0yOCBhdCAxNzo1MSArMDAwMCwgSmVmZnJleSBLYXJyZWxzIHdyb3Rl
Ogo+ID4KPiA+PiA+IEhhdmUgeW91IGNoYW5nZWQgYW55dGhpbmcgaGVyZSBvciBhcmUgeW91IHNh
eWluZyB0aGF0IGEgcHJpc3RpbmUgWGVuCj4gPj4gPiB0cmVlIHdoZW4gYnVpbHQgb24gQ2VudE9T
IGluc3RhbGxzIDY0IGJpdCBsaWJyYXJpZXMgdG8gL3Vzci9saWIgaW5zdGVhZAo+ID4+ID4gb2Yg
L3Vzci9saWI2ND8gSWYgc28gcGxlYXNlIGNhbiB5b3UgYmUgcHJlY2lzZSBhYm91dCB3aGF0IHRy
ZWUgeW91IGFyZQo+ID4+ID4gcnVubmluZyAoZS5nLiB0aGUgZXhhY3QgVVJMIHlvdSBjbG9uZWQg
YW5kIHdoaWNoIGNoYW5nZXNldCB5b3UgZ290KSBhbmQKPiA+PiA+IHN0ZXBzIHlvdSB0b29rIHRv
IGluc3RhbGwgKGUuZy4gd2hhdCBwYXRjaGVzIGRpZCB5b3UgYXBwbHksIHdoYXQKPiA+PiA+IGNv
bW1hbmRzIGRpZCB5b3UgdHlwZSkgYW5kIHdoYXQgZXhhY3RseSB5b3Ugc2F3IChlLmcuIHdoYXQg
d2FzCj4gPj4gPiBpbiAvdXNyL2xpYiBhbmQgd2hhdCB3YXMgaW4gL3Vzci9saWI2NCkKPiA+Pgo+
ID4+ICN1bmFtZSAtYQo+ID4+IExpbnV4IHhlbmJ1aWxkMi5jeWJlcmxhYiAyLjYuMzItMjIwLjQu
MS5lbDYueDg2XzY0ICMxIFNNUCBUdWUgSmFuIDI0Cj4gPj4gMDI6MTM6NDQgR01UIDIwMTIgeDg2
XzY0IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4Cj4gPj4KPiA+PiAjaGcgY2xvbmUgLXIgMjQ4Njkg
aHR0cDovL3hlbmJpdHMueGVuLm9yZy9oZy94ZW4tdW5zdGFibGUuaGcKPiA+PiAjY2QgeGVuLXVu
c3RhYmxlCj4gPj4gIy4vY29uZmlndXJlIC0tZW5hYmxlLXhzbSAtLWxpYmRpcj0vdXNyL2xpYjY0
Cj4gPgo+ID4gT0ssIHNvIHlvdSBhcmUgdXNpbmcgc29tZXRoaW5nIG5ldyBlbm91Z2ggdG8gaGF2
ZSB0aGUgYXV0b2NvbmYgc3R1ZmYgLS0KPiA+IEkgdGhpbmsgdGhpcyBpcyBzaW1wbHkgYSBidWcg
aW4gdGhhdC4gSSd2ZSBDQydkIFJvZ2VyLgo+ID4KPiA+IElkZWFsbHkgY29uZmlndXJlIHdvdWxk
IGF1dG8tZGV0ZWN0IHRoZSByaWdodCB0aGluZyBmb3IgdGhlIGdpdmVuIHN5c3RlbQo+ID4gYW5k
IHNvIC0tbGliZGlyIHdvdWxkIG5vdCBiZSByZXF1aXJlZC4gVGhpcyB3b3VsZCBjZXJ0YWlubHkg
YmUgbgo+ID4gaW1wcm92ZW1lbnQgb3ZlciB0aGUgcHJlLWF1dG9jb25mIHRoaW5nLgo+IAo+IGNv
bmZpZ3VyZSB3YXMgbm90IHByb3Blcmx5IHBhcnNpbmcgdGhlIGxpYmRpciBwYXRoIGFuZCBhbHdh
eXMgc2V0IGl0Cj4gdG8gImxpYiIsIHRoaXMgaXMgYSBmaXg6CgpUaGFua3MuCgo+IDg8LS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiBhdXRvY29uZjogZml4
IGxpYmRpciBkZXRlY3Rpb24KPiAKPiBJZiB1c2VyIHNwZWNpZmllcyBhIGxpYmRpciBpdCBpcyB1
c2VkLCBpZiBubyBsaWJkaXIgaXMgc3BlY2lmaWVkCj4gY29uZmlndXJlIGNoZWNrcyBpZiAkcHJl
Zml4L2xpYjY0IGlzIGEgZGlyZWN0b3J5IGFuZCB1c2VzIHRoYXQsIGlmIG5vdAo+IGxpYiBpcyB1
c2VkLgoKVGhlIGNvZGUgc2VlbXMgdG8gdXNlIGJvdGggJHtleGVjX3ByZWZpeH0gYW5kICR7cHJl
Zml4fSBpcyB0aGF0IGNvcnJlY3Q/ClNlZW1zIGxpa2UgYW4gb2RkIHBsYWNlIHRvIHNldCBcJHBy
ZWZpeCBpcyBhbGwuCgo+IGRpZmYgLXIgNDc1OGE3YTk0YzE1IHRvb2xzL200L2RlZmF1bHRfbGli
Lm00Cj4gLS0tIGEvdG9vbHMvbTQvZGVmYXVsdF9saWIubTQJV2VkIEZlYiAyMiAwNDo0NjowNyAy
MDEyICswMTAwCj4gKysrIGIvdG9vbHMvbTQvZGVmYXVsdF9saWIubTQJV2VkIEZlYiAyMiAwNjoz
MTo1MyAyMDEyICswMTAwCj4gQEAgLTEsOCArMSwxMiBAQAo+ICBBQ19ERUZVTihbQVhfREVGQVVM
VF9MSUJdLAo+IC1bQVNfSUYoW3Rlc3QgLWQgIiRwcmVmaXgvbGliNjQiXSwgWwo+IC0gICAgTElC
X1BBVEg9ImxpYjY0Igo+IC1dLFsKPiAtICAgIExJQl9QQVRIPSJsaWIiCj4gK1tBU19JRihbdGVz
dCAiXCR7ZXhlY19wcmVmaXh9L2xpYiIgPSAiJGxpYmRpciJdLAo+ICsgICAgW0FTX0lGKFt0ZXN0
ICIkcHJlZml4IiA9ICJOT05FIl0sIFtwcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4XSkKPiArICAg
IEFTX0lGKFt0ZXN0IC1kICIke3ByZWZpeH0vbGliNjQiXSwgWwo+ICsgICAgICAgIExJQl9QQVRI
PSJsaWI2NCIKPiArICAgIF0sWwo+ICsgICAgICAgIExJQl9QQVRIPSJsaWIiCj4gKyAgICBdKQo+
ICtdLCBbCj4gKyAgICBMSUJfUEFUSD0iJHtsaWJkaXI6YGV4cHIgbGVuZ3RoICIkZXhlY19wcmVm
aXgiICsgMWB9Igo+ICBdKQo+ICBBQ19TVUJTVChMSUJfUEFUSCldKQo+IC0KCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 29 10:57:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 10: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 1S2hDh-0006XM-Uk; Wed, 29 Feb 2012 10:57:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2hDf-0006X7-Jy
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 10:57:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330513029!4169971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3054 invoked from network); 29 Feb 2012 10:57:09 -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;
	29 Feb 2012 10:57:09 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 10:57:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 10:57:09 +0000
Message-ID: <1330513027.4270.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 10:57:07 +0000
In-Reply-To: <CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
	<CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDEwOjE4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yOCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFR1ZSwgMjAxMi0wMi0yOCBhdCAxNzo1MSArMDAwMCwgSmVmZnJleSBLYXJyZWxzIHdyb3Rl
Ogo+ID4KPiA+PiA+IEhhdmUgeW91IGNoYW5nZWQgYW55dGhpbmcgaGVyZSBvciBhcmUgeW91IHNh
eWluZyB0aGF0IGEgcHJpc3RpbmUgWGVuCj4gPj4gPiB0cmVlIHdoZW4gYnVpbHQgb24gQ2VudE9T
IGluc3RhbGxzIDY0IGJpdCBsaWJyYXJpZXMgdG8gL3Vzci9saWIgaW5zdGVhZAo+ID4+ID4gb2Yg
L3Vzci9saWI2ND8gSWYgc28gcGxlYXNlIGNhbiB5b3UgYmUgcHJlY2lzZSBhYm91dCB3aGF0IHRy
ZWUgeW91IGFyZQo+ID4+ID4gcnVubmluZyAoZS5nLiB0aGUgZXhhY3QgVVJMIHlvdSBjbG9uZWQg
YW5kIHdoaWNoIGNoYW5nZXNldCB5b3UgZ290KSBhbmQKPiA+PiA+IHN0ZXBzIHlvdSB0b29rIHRv
IGluc3RhbGwgKGUuZy4gd2hhdCBwYXRjaGVzIGRpZCB5b3UgYXBwbHksIHdoYXQKPiA+PiA+IGNv
bW1hbmRzIGRpZCB5b3UgdHlwZSkgYW5kIHdoYXQgZXhhY3RseSB5b3Ugc2F3IChlLmcuIHdoYXQg
d2FzCj4gPj4gPiBpbiAvdXNyL2xpYiBhbmQgd2hhdCB3YXMgaW4gL3Vzci9saWI2NCkKPiA+Pgo+
ID4+ICN1bmFtZSAtYQo+ID4+IExpbnV4IHhlbmJ1aWxkMi5jeWJlcmxhYiAyLjYuMzItMjIwLjQu
MS5lbDYueDg2XzY0ICMxIFNNUCBUdWUgSmFuIDI0Cj4gPj4gMDI6MTM6NDQgR01UIDIwMTIgeDg2
XzY0IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4Cj4gPj4KPiA+PiAjaGcgY2xvbmUgLXIgMjQ4Njkg
aHR0cDovL3hlbmJpdHMueGVuLm9yZy9oZy94ZW4tdW5zdGFibGUuaGcKPiA+PiAjY2QgeGVuLXVu
c3RhYmxlCj4gPj4gIy4vY29uZmlndXJlIC0tZW5hYmxlLXhzbSAtLWxpYmRpcj0vdXNyL2xpYjY0
Cj4gPgo+ID4gT0ssIHNvIHlvdSBhcmUgdXNpbmcgc29tZXRoaW5nIG5ldyBlbm91Z2ggdG8gaGF2
ZSB0aGUgYXV0b2NvbmYgc3R1ZmYgLS0KPiA+IEkgdGhpbmsgdGhpcyBpcyBzaW1wbHkgYSBidWcg
aW4gdGhhdC4gSSd2ZSBDQydkIFJvZ2VyLgo+ID4KPiA+IElkZWFsbHkgY29uZmlndXJlIHdvdWxk
IGF1dG8tZGV0ZWN0IHRoZSByaWdodCB0aGluZyBmb3IgdGhlIGdpdmVuIHN5c3RlbQo+ID4gYW5k
IHNvIC0tbGliZGlyIHdvdWxkIG5vdCBiZSByZXF1aXJlZC4gVGhpcyB3b3VsZCBjZXJ0YWlubHkg
YmUgbgo+ID4gaW1wcm92ZW1lbnQgb3ZlciB0aGUgcHJlLWF1dG9jb25mIHRoaW5nLgo+IAo+IGNv
bmZpZ3VyZSB3YXMgbm90IHByb3Blcmx5IHBhcnNpbmcgdGhlIGxpYmRpciBwYXRoIGFuZCBhbHdh
eXMgc2V0IGl0Cj4gdG8gImxpYiIsIHRoaXMgaXMgYSBmaXg6CgpUaGFua3MuCgo+IDg8LS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAKPiBhdXRvY29uZjogZml4
IGxpYmRpciBkZXRlY3Rpb24KPiAKPiBJZiB1c2VyIHNwZWNpZmllcyBhIGxpYmRpciBpdCBpcyB1
c2VkLCBpZiBubyBsaWJkaXIgaXMgc3BlY2lmaWVkCj4gY29uZmlndXJlIGNoZWNrcyBpZiAkcHJl
Zml4L2xpYjY0IGlzIGEgZGlyZWN0b3J5IGFuZCB1c2VzIHRoYXQsIGlmIG5vdAo+IGxpYiBpcyB1
c2VkLgoKVGhlIGNvZGUgc2VlbXMgdG8gdXNlIGJvdGggJHtleGVjX3ByZWZpeH0gYW5kICR7cHJl
Zml4fSBpcyB0aGF0IGNvcnJlY3Q/ClNlZW1zIGxpa2UgYW4gb2RkIHBsYWNlIHRvIHNldCBcJHBy
ZWZpeCBpcyBhbGwuCgo+IGRpZmYgLXIgNDc1OGE3YTk0YzE1IHRvb2xzL200L2RlZmF1bHRfbGli
Lm00Cj4gLS0tIGEvdG9vbHMvbTQvZGVmYXVsdF9saWIubTQJV2VkIEZlYiAyMiAwNDo0NjowNyAy
MDEyICswMTAwCj4gKysrIGIvdG9vbHMvbTQvZGVmYXVsdF9saWIubTQJV2VkIEZlYiAyMiAwNjoz
MTo1MyAyMDEyICswMTAwCj4gQEAgLTEsOCArMSwxMiBAQAo+ICBBQ19ERUZVTihbQVhfREVGQVVM
VF9MSUJdLAo+IC1bQVNfSUYoW3Rlc3QgLWQgIiRwcmVmaXgvbGliNjQiXSwgWwo+IC0gICAgTElC
X1BBVEg9ImxpYjY0Igo+IC1dLFsKPiAtICAgIExJQl9QQVRIPSJsaWIiCj4gK1tBU19JRihbdGVz
dCAiXCR7ZXhlY19wcmVmaXh9L2xpYiIgPSAiJGxpYmRpciJdLAo+ICsgICAgW0FTX0lGKFt0ZXN0
ICIkcHJlZml4IiA9ICJOT05FIl0sIFtwcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4XSkKPiArICAg
IEFTX0lGKFt0ZXN0IC1kICIke3ByZWZpeH0vbGliNjQiXSwgWwo+ICsgICAgICAgIExJQl9QQVRI
PSJsaWI2NCIKPiArICAgIF0sWwo+ICsgICAgICAgIExJQl9QQVRIPSJsaWIiCj4gKyAgICBdKQo+
ICtdLCBbCj4gKyAgICBMSUJfUEFUSD0iJHtsaWJkaXI6YGV4cHIgbGVuZ3RoICIkZXhlY19wcmVm
aXgiICsgMWB9Igo+ICBdKQo+ICBBQ19TVUJTVChMSUJfUEFUSCldKQo+IC0KCgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:01:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hHJ-0006iQ-JK; Wed, 29 Feb 2012 11:01:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2hHI-0006iB-JC
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 11:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330513253!9777900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29836 invoked from network); 29 Feb 2012 11:00:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005779"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 11:00:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 11:00:53 +0000
Message-ID: <1330513251.4270.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 29 Feb 2012 11:00:51 +0000
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "Keir
	\(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 23:27 +0000, Daniel De Graaf wrote:
> Since the introduction of autoconf, builds with XSM enabled in .config
> have been broken unless FLASK_ENABLE was explicitly set. Since the
> setting in .config has apparently been deprecated in favor of an
> autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
> also makes --disable-debug and some paths to be pulled from the
> configure process in the hypervisor build.

AIUI the intention was for only the tools to require configure, which is
why it is tools/configure* and not just configure*.

I'm not sure anyone thought about the case of options like FLASK_ENABLE
which have both hypervisor and tools components controlled by a single
option.

It seems like the intention would have been to retain FLASK_ENABLE for
the hypervisor but enable the tools via configure -- but that seems
disconnected in a really odd way to me.

Perhaps we should just move the configure stuff up to the top level and
agree that it can control both tools and hypervisor configuration
options? I'm not sure why we would want to use different mechanisms for
the tools and h/v anyway.

Ian.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  .gitignore         |    1 +
>  .hgignore          |    1 +
>  config/Tools.mk.in |    4 ----
>  config/Xen.mk.in   |   19 +++++++++++++++++++
>  tools/configure.ac |    1 +
>  xen/Rules.mk       |    1 +
>  6 files changed, 23 insertions(+), 4 deletions(-)
>  create mode 100644 config/Xen.mk.in
> 
> diff --git a/.gitignore b/.gitignore
> index 8810b35..865505f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -111,6 +111,7 @@ tools/config.log
>  tools/config.status
>  tools/config.cache
>  config/Tools.mk
> +config/Xen.mk
>  tools/blktap2/daemon/blktapctrl
>  tools/blktap2/drivers/img2qcow
>  tools/blktap2/drivers/lock-util
> diff --git a/.hgignore b/.hgignore
> index 46655ad..7d5ccc1 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -309,6 +309,7 @@
>  ^tools/config\.status$
>  ^tools/config\.cache$
>  ^config/Tools\.mk$
> +^config/Xen\.mk$
>  ^xen/\.banner.*$
>  ^xen/BLOG$
>  ^xen/System.map$
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 06d5e89..315ced4 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
>  APPEND_INCLUDES     := @APPEND_INCLUDES@
>  APPEND_LIB          := @APPEND_LIB@
>  
> -# Enable XSM security module (by default, Flask).
> -XSM_ENABLE          := @xsm@
> -FLASK_ENABLE        := @xsm@
> -
>  # Download GIT repositories via HTTP or GIT's own protocol?
>  # GIT's protocol is faster and more robust, when it works at all (firewalls
>  # may block it). We make it the default, but if your GIT repository downloads
> diff --git a/config/Xen.mk.in b/config/Xen.mk.in
> new file mode 100644
> index 0000000..e152f39
> --- /dev/null
> +++ b/config/Xen.mk.in
> @@ -0,0 +1,19 @@
> +# Prefix and install folder
> +PREFIX              := @prefix@
> +LIBLEAFDIR_x86_64   := @LIB_PATH@
> +
> +# A debug build of xen?
> +debug               := @debug@
> +
> +# Tools path
> +PYTHON              := @PYTHON@
> +
> +# Extra folder for libs/includes
> +PREPEND_INCLUDES    := @PREPEND_INCLUDES@
> +PREPEND_LIB         := @PREPEND_LIB@
> +APPEND_INCLUDES     := @APPEND_INCLUDES@
> +APPEND_LIB          := @APPEND_LIB@
> +
> +# Enable XSM security module (by default, Flask).
> +XSM_ENABLE          := @xsm@
> +FLASK_ENABLE        := @xsm@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index c5dec9c..5b2815d 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -6,6 +6,7 @@ AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
>      [xen-devel@lists.xensource.com])
>  AC_CONFIG_SRCDIR([libxl/libxl.c])
>  AC_CONFIG_FILES([../config/Tools.mk])
> +AC_CONFIG_FILES([../config/Xen.mk])
>  AC_CONFIG_HEADERS([config.h])
>  AC_PREFIX_DEFAULT([/usr])
>  AC_CONFIG_AUX_DIR([.])
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 6123835..6c17a3f 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -12,6 +12,7 @@ frame_pointer ?= n
>  lto           ?= n
>  
>  include $(XEN_ROOT)/Config.mk
> +include $(XEN_ROOT)/config/Xen.mk
>  
>  # Hardcoded configuration implications and dependencies.
>  # Do this is a neater way if it becomes unwieldy.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:01:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hHJ-0006iQ-JK; Wed, 29 Feb 2012 11:01:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2hHI-0006iB-JC
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 11:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330513253!9777900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29836 invoked from network); 29 Feb 2012 11:00:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="11005779"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 11:00:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 11:00:53 +0000
Message-ID: <1330513251.4270.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 29 Feb 2012 11:00:51 +0000
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, "Keir
	\(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-02-28 at 23:27 +0000, Daniel De Graaf wrote:
> Since the introduction of autoconf, builds with XSM enabled in .config
> have been broken unless FLASK_ENABLE was explicitly set. Since the
> setting in .config has apparently been deprecated in favor of an
> autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
> also makes --disable-debug and some paths to be pulled from the
> configure process in the hypervisor build.

AIUI the intention was for only the tools to require configure, which is
why it is tools/configure* and not just configure*.

I'm not sure anyone thought about the case of options like FLASK_ENABLE
which have both hypervisor and tools components controlled by a single
option.

It seems like the intention would have been to retain FLASK_ENABLE for
the hypervisor but enable the tools via configure -- but that seems
disconnected in a really odd way to me.

Perhaps we should just move the configure stuff up to the top level and
agree that it can control both tools and hypervisor configuration
options? I'm not sure why we would want to use different mechanisms for
the tools and h/v anyway.

Ian.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  .gitignore         |    1 +
>  .hgignore          |    1 +
>  config/Tools.mk.in |    4 ----
>  config/Xen.mk.in   |   19 +++++++++++++++++++
>  tools/configure.ac |    1 +
>  xen/Rules.mk       |    1 +
>  6 files changed, 23 insertions(+), 4 deletions(-)
>  create mode 100644 config/Xen.mk.in
> 
> diff --git a/.gitignore b/.gitignore
> index 8810b35..865505f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -111,6 +111,7 @@ tools/config.log
>  tools/config.status
>  tools/config.cache
>  config/Tools.mk
> +config/Xen.mk
>  tools/blktap2/daemon/blktapctrl
>  tools/blktap2/drivers/img2qcow
>  tools/blktap2/drivers/lock-util
> diff --git a/.hgignore b/.hgignore
> index 46655ad..7d5ccc1 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -309,6 +309,7 @@
>  ^tools/config\.status$
>  ^tools/config\.cache$
>  ^config/Tools\.mk$
> +^config/Xen\.mk$
>  ^xen/\.banner.*$
>  ^xen/BLOG$
>  ^xen/System.map$
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 06d5e89..315ced4 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
>  APPEND_INCLUDES     := @APPEND_INCLUDES@
>  APPEND_LIB          := @APPEND_LIB@
>  
> -# Enable XSM security module (by default, Flask).
> -XSM_ENABLE          := @xsm@
> -FLASK_ENABLE        := @xsm@
> -
>  # Download GIT repositories via HTTP or GIT's own protocol?
>  # GIT's protocol is faster and more robust, when it works at all (firewalls
>  # may block it). We make it the default, but if your GIT repository downloads
> diff --git a/config/Xen.mk.in b/config/Xen.mk.in
> new file mode 100644
> index 0000000..e152f39
> --- /dev/null
> +++ b/config/Xen.mk.in
> @@ -0,0 +1,19 @@
> +# Prefix and install folder
> +PREFIX              := @prefix@
> +LIBLEAFDIR_x86_64   := @LIB_PATH@
> +
> +# A debug build of xen?
> +debug               := @debug@
> +
> +# Tools path
> +PYTHON              := @PYTHON@
> +
> +# Extra folder for libs/includes
> +PREPEND_INCLUDES    := @PREPEND_INCLUDES@
> +PREPEND_LIB         := @PREPEND_LIB@
> +APPEND_INCLUDES     := @APPEND_INCLUDES@
> +APPEND_LIB          := @APPEND_LIB@
> +
> +# Enable XSM security module (by default, Flask).
> +XSM_ENABLE          := @xsm@
> +FLASK_ENABLE        := @xsm@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index c5dec9c..5b2815d 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -6,6 +6,7 @@ AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]),
>      [xen-devel@lists.xensource.com])
>  AC_CONFIG_SRCDIR([libxl/libxl.c])
>  AC_CONFIG_FILES([../config/Tools.mk])
> +AC_CONFIG_FILES([../config/Xen.mk])
>  AC_CONFIG_HEADERS([config.h])
>  AC_PREFIX_DEFAULT([/usr])
>  AC_CONFIG_AUX_DIR([.])
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 6123835..6c17a3f 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -12,6 +12,7 @@ frame_pointer ?= n
>  lto           ?= n
>  
>  include $(XEN_ROOT)/Config.mk
> +include $(XEN_ROOT)/config/Xen.mk
>  
>  # Hardcoded configuration implications and dependencies.
>  # Do this is a neater way if it becomes unwieldy.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:03:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11: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 1S2hJD-0006pf-2u; Wed, 29 Feb 2012 11:02:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1S2hJ8-0006pW-UV
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:02:57 +0000
Received: from [85.158.139.83:58024] by server-11.bemta-5.messagelabs.com id
	E9/56-05465-ED50E4F4; Wed, 29 Feb 2012 11:02:54 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330513372!17131925!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMjYzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19502 invoked from network); 29 Feb 2012 11:02:52 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:02:52 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:Content-Type:
	Content-Transfer-Encoding;
	b=V3rOClJz9o1W6gAZINVqv5yLdAuAjTiCn0+nK/2JjxxCCUwvVNXsvWsN
	vCI8RbEophIgw1qEJ5SmxoL3s1WJquVfwyOleQa54KTrFktTiuiO79R/c
	F3yP99kaDr+ZdNsLYOeTuk8j2E9GElp3u6UIudwbp2YKW92YsY7BZQavL
	BDIz56ZXCkEirLIxIuQ88Sx9gyySFQzH116rqOIB1kK5FlhDI87AyWSOe
	RoPTpCQun/VYlbDS394dZfAuliHwB;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1330513373; x=1362049373;
	h=message-id:date:from:mime-version:to:subject:
	content-transfer-encoding;
	bh=ck3wdLSnDPBkxmSTS1siOj3+ZXDruY2vFWYKuD5rzlY=;
	b=Zr84dEZs/BiptzXYDsKIwonTOzZT04Fy3CibGKIaaS2UVNFbGASYa4b5
	kkWlqHeRa0gjeqmcGKs0X1hs3ohWds5aJWWgK4TZtIy3mOHr1LbOXYYdP
	dq4qCxpjaQ6rZEvSpAM7TLwro9fByuuoEOCF5A8v4epwQqdXGszbB+K/c
	aHUB+Oq1G1diPhx6mfi9NSZ276r5ux6c46OqHJlvs7rnLamnBW8iPdHry
	X0M1HuAM7h0Cb6PZU8fQ6tmL2gSbU;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="103359881"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 29 Feb 2012 12:02:52 +0100
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="129927162"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 29 Feb 2012 12:02:51 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 8C9B8959A07
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 12:02:51 +0100 (CET)
Message-ID: <4F4E05DB.5020401@ts.fujitsu.com>
Date: Wed, 29 Feb 2012 12:02:51 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] GP fault after live migration of hvm domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

during a live migration of a hvm domain with pv-drivers I get a general
protection fault on the target machine just after the domain has been resumed
there. The fault occurs on vcpu 6 when it is trying to access the lapic timer.

Xen version is 4.0.2 (SLES11 SP1), on the console I see:

(XEN) io.c:194:d6 MMIO emulation failed @ 0020:ffff9700ff00de42: 89 b8 80 03 00 00

which is exactly the failing instruction in the domain. All registers seem to
be okay, %rax holds the virtual address of the lapic.
Needless to say this routine has no problems in normal cases. The domain was
migrated several times successful.

Has something like this been seen before?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:03:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11: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 1S2hJD-0006pf-2u; Wed, 29 Feb 2012 11:02:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1S2hJ8-0006pW-UV
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:02:57 +0000
Received: from [85.158.139.83:58024] by server-11.bemta-5.messagelabs.com id
	E9/56-05465-ED50E4F4; Wed, 29 Feb 2012 11:02:54 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330513372!17131925!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMjYzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19502 invoked from network); 29 Feb 2012 11:02:52 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:02:52 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:Content-Type:
	Content-Transfer-Encoding;
	b=V3rOClJz9o1W6gAZINVqv5yLdAuAjTiCn0+nK/2JjxxCCUwvVNXsvWsN
	vCI8RbEophIgw1qEJ5SmxoL3s1WJquVfwyOleQa54KTrFktTiuiO79R/c
	F3yP99kaDr+ZdNsLYOeTuk8j2E9GElp3u6UIudwbp2YKW92YsY7BZQavL
	BDIz56ZXCkEirLIxIuQ88Sx9gyySFQzH116rqOIB1kK5FlhDI87AyWSOe
	RoPTpCQun/VYlbDS394dZfAuliHwB;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1330513373; x=1362049373;
	h=message-id:date:from:mime-version:to:subject:
	content-transfer-encoding;
	bh=ck3wdLSnDPBkxmSTS1siOj3+ZXDruY2vFWYKuD5rzlY=;
	b=Zr84dEZs/BiptzXYDsKIwonTOzZT04Fy3CibGKIaaS2UVNFbGASYa4b5
	kkWlqHeRa0gjeqmcGKs0X1hs3ohWds5aJWWgK4TZtIy3mOHr1LbOXYYdP
	dq4qCxpjaQ6rZEvSpAM7TLwro9fByuuoEOCF5A8v4epwQqdXGszbB+K/c
	aHUB+Oq1G1diPhx6mfi9NSZ276r5ux6c46OqHJlvs7rnLamnBW8iPdHry
	X0M1HuAM7h0Cb6PZU8fQ6tmL2gSbU;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="103359881"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 29 Feb 2012 12:02:52 +0100
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="129927162"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 29 Feb 2012 12:02:51 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 8C9B8959A07
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 12:02:51 +0100 (CET)
Message-ID: <4F4E05DB.5020401@ts.fujitsu.com>
Date: Wed, 29 Feb 2012 12:02:51 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] GP fault after live migration of hvm domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

during a live migration of a hvm domain with pv-drivers I get a general
protection fault on the target machine just after the domain has been resumed
there. The fault occurs on vcpu 6 when it is trying to access the lapic timer.

Xen version is 4.0.2 (SLES11 SP1), on the console I see:

(XEN) io.c:194:d6 MMIO emulation failed @ 0020:ffff9700ff00de42: 89 b8 80 03 00 00

which is exactly the failing instruction in the domain. All registers seem to
be okay, %rax holds the virtual address of the lapic.
Needless to say this routine has no problems in normal cases. The domain was
migrated several times successful.

Has something like this been seen before?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:04:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hKC-0006wK-Mb; Wed, 29 Feb 2012 11:04:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2hKB-0006ve-Gw
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 11:03:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330513433!11271737!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17046 invoked from network); 29 Feb 2012 11:03:53 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:03:53 -0000
Received: by werp12 with SMTP id p12so3003964wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 03:03:53 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.165 as permitted sender) client-ip=10.180.92.165; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.165 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.165])
	by 10.180.92.165 with SMTP id cn5mr16392894wib.2.1330513433134
	(num_hops = 1); Wed, 29 Feb 2012 03:03:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Ui1QaDNhVZ3qZar9EcXj9PFi87YEKmHxqZttVvfX1y4=;
	b=VnRCHJcV+wSua6S6pfwjglnR5zl5QNx+aEjsDtiDW8DR+ySZ2JRzNaor6FQBXau5BP
	l/o6MtfgceWFfowlWNt+itU7oQGhPA1BkaRO6fP8lV2e0M/K9qeip+r9TpEX6VNElFon
	ryKlr+jDj2u1IC6Bx4rfJgaGdbNfI6N1nVlxo=
MIME-Version: 1.0
Received: by 10.180.92.165 with SMTP id cn5mr13060273wib.2.1330513432987; Wed,
	29 Feb 2012 03:03:52 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 03:03:52 -0800 (PST)
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Date: Wed, 29 Feb 2012 12:03:52 +0100
X-Google-Sender-Auth: fiOR7hVm7NetGXsD6pXy7OzwSi0
Message-ID: <CAPLaKK6pBepTy_DOZtrhemsvATUmZCVq1AX9ky=hC9eXbD7Mmw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: keir@xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor 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

2012/2/29 Daniel De Graaf <dgdegra@tycho.nsa.gov>:
> Since the introduction of autoconf, builds with XSM enabled in .config
> have been broken unless FLASK_ENABLE was explicitly set. Since the
> setting in .config has apparently been deprecated in favor of an
> autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
> also makes --disable-debug and some paths to be pulled from the
> configure process in the hypervisor build.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>

When we started the autoconf stuff we decided to make it a tools only
thing, that's why configure.ac resides in tools/, if the hypervisor
starts using it too, we should move tools/configure.ac and it's stuff
to /. Apart from that, I think the patch is ok, provided that the
following is applied after:

8<--------------------------------------------

autoconf: rebuild configure and check for config/Xen.mk

Rebuild configure after Daniel De Graaf patch. Check for
config/Xen.mk when building the hypervisor and delete config/Xen.mk
when doing a distclean.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9e45c5b8b8f2 tools/configure
--- a/tools/configure	Wed Feb 22 06:38:22 2012 +0100
+++ b/tools/configure	Wed Feb 22 07:19:50 2012 +0100
@@ -2435,6 +2435,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu

 ac_config_files="$ac_config_files ../config/Tools.mk"

+ac_config_files="$ac_config_files ../config/Xen.mk"
+
 ac_config_headers="$ac_config_headers config.h"


@@ -9588,6 +9590,7 @@ for ac_config_target in $ac_config_targe
 do
   case $ac_config_target in
     "../config/Tools.mk") CONFIG_FILES="$CONFIG_FILES ../config/Tools.mk" ;;
+    "../config/Xen.mk") CONFIG_FILES="$CONFIG_FILES ../config/Xen.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;

   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
diff -r 9e45c5b8b8f2 xen/Makefile
--- a/xen/Makefile	Wed Feb 22 06:38:22 2012 +0100
+++ b/xen/Makefile	Wed Feb 22 07:19:50 2012 +0100
@@ -67,7 +67,7 @@ build install debug clean distclean csco

 .PHONY: _distclean
 _distclean: clean
-	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
+	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
../config/Xen.mk

 $(TARGET).gz: $(TARGET)
 	gzip -f -9 < $< > $@.new
diff -r 9e45c5b8b8f2 xen/Rules.mk
--- a/xen/Rules.mk	Wed Feb 22 06:38:22 2012 +0100
+++ b/xen/Rules.mk	Wed Feb 22 07:19:50 2012 +0100
@@ -179,4 +179,8 @@ SPECIAL_DATA_SECTIONS := rodata $(foreac
 %.s: %.S Makefile
 	$(CPP) $(AFLAGS) $< -o $@

+$(XEN_ROOT)/config/Xen.mk:
+	@echo "You have to run ./configure before building or installing the
hypervisor"
+	@exit 1
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:04:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hKC-0006wK-Mb; Wed, 29 Feb 2012 11:04:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2hKB-0006ve-Gw
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 11:03:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330513433!11271737!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17046 invoked from network); 29 Feb 2012 11:03:53 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:03:53 -0000
Received: by werp12 with SMTP id p12so3003964wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 03:03:53 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.165 as permitted sender) client-ip=10.180.92.165; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.165 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.165])
	by 10.180.92.165 with SMTP id cn5mr16392894wib.2.1330513433134
	(num_hops = 1); Wed, 29 Feb 2012 03:03:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Ui1QaDNhVZ3qZar9EcXj9PFi87YEKmHxqZttVvfX1y4=;
	b=VnRCHJcV+wSua6S6pfwjglnR5zl5QNx+aEjsDtiDW8DR+ySZ2JRzNaor6FQBXau5BP
	l/o6MtfgceWFfowlWNt+itU7oQGhPA1BkaRO6fP8lV2e0M/K9qeip+r9TpEX6VNElFon
	ryKlr+jDj2u1IC6Bx4rfJgaGdbNfI6N1nVlxo=
MIME-Version: 1.0
Received: by 10.180.92.165 with SMTP id cn5mr13060273wib.2.1330513432987; Wed,
	29 Feb 2012 03:03:52 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 03:03:52 -0800 (PST)
In-Reply-To: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
Date: Wed, 29 Feb 2012 12:03:52 +0100
X-Google-Sender-Auth: fiOR7hVm7NetGXsD6pXy7OzwSi0
Message-ID: <CAPLaKK6pBepTy_DOZtrhemsvATUmZCVq1AX9ky=hC9eXbD7Mmw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: keir@xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor 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

2012/2/29 Daniel De Graaf <dgdegra@tycho.nsa.gov>:
> Since the introduction of autoconf, builds with XSM enabled in .config
> have been broken unless FLASK_ENABLE was explicitly set. Since the
> setting in .config has apparently been deprecated in favor of an
> autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
> also makes --disable-debug and some paths to be pulled from the
> configure process in the hypervisor build.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>

When we started the autoconf stuff we decided to make it a tools only
thing, that's why configure.ac resides in tools/, if the hypervisor
starts using it too, we should move tools/configure.ac and it's stuff
to /. Apart from that, I think the patch is ok, provided that the
following is applied after:

8<--------------------------------------------

autoconf: rebuild configure and check for config/Xen.mk

Rebuild configure after Daniel De Graaf patch. Check for
config/Xen.mk when building the hypervisor and delete config/Xen.mk
when doing a distclean.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9e45c5b8b8f2 tools/configure
--- a/tools/configure	Wed Feb 22 06:38:22 2012 +0100
+++ b/tools/configure	Wed Feb 22 07:19:50 2012 +0100
@@ -2435,6 +2435,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu

 ac_config_files="$ac_config_files ../config/Tools.mk"

+ac_config_files="$ac_config_files ../config/Xen.mk"
+
 ac_config_headers="$ac_config_headers config.h"


@@ -9588,6 +9590,7 @@ for ac_config_target in $ac_config_targe
 do
   case $ac_config_target in
     "../config/Tools.mk") CONFIG_FILES="$CONFIG_FILES ../config/Tools.mk" ;;
+    "../config/Xen.mk") CONFIG_FILES="$CONFIG_FILES ../config/Xen.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;

   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
diff -r 9e45c5b8b8f2 xen/Makefile
--- a/xen/Makefile	Wed Feb 22 06:38:22 2012 +0100
+++ b/xen/Makefile	Wed Feb 22 07:19:50 2012 +0100
@@ -67,7 +67,7 @@ build install debug clean distclean csco

 .PHONY: _distclean
 _distclean: clean
-	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
+	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
../config/Xen.mk

 $(TARGET).gz: $(TARGET)
 	gzip -f -9 < $< > $@.new
diff -r 9e45c5b8b8f2 xen/Rules.mk
--- a/xen/Rules.mk	Wed Feb 22 06:38:22 2012 +0100
+++ b/xen/Rules.mk	Wed Feb 22 07:19:50 2012 +0100
@@ -179,4 +179,8 @@ SPECIAL_DATA_SECTIONS := rodata $(foreac
 %.s: %.S Makefile
 	$(CPP) $(AFLAGS) $< -o $@

+$(XEN_ROOT)/config/Xen.mk:
+	@echo "You have to run ./configure before building or installing the
hypervisor"
+	@exit 1
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:09:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:09:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hPP-0007ES-GV; Wed, 29 Feb 2012 11:09:23 +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 1S2hPO-0007EK-3H
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:09:22 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330513732!65604543!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4714 invoked from network); 29 Feb 2012 11:08:53 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 11:08:53 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2hPI-0001w9-5i
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 03:09:16 -0800
Date: Wed, 29 Feb 2012 03:09:16 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330513756170-5524689.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm trying to make the necessary patches to complete the Spice support on
libxl.
Qxl graphic add do always error and I not understand why, I need to see all
dm_args for try to search the cause, I try with LIBXL__LOG (on libxl_dm.c
before the line return (char **) flexarray_contents(dm_args);) but always
fails, someone can help me to do log of full dm_args please?

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Need-help-with-qemu-args-debug-tp5524689p5524689.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:09:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:09:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hPP-0007ES-GV; Wed, 29 Feb 2012 11:09:23 +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 1S2hPO-0007EK-3H
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:09:22 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1330513732!65604543!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4714 invoked from network); 29 Feb 2012 11:08:53 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 11:08:53 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2hPI-0001w9-5i
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 03:09:16 -0800
Date: Wed, 29 Feb 2012 03:09:16 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330513756170-5524689.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm trying to make the necessary patches to complete the Spice support on
libxl.
Qxl graphic add do always error and I not understand why, I need to see all
dm_args for try to search the cause, I try with LIBXL__LOG (on libxl_dm.c
before the line return (char **) flexarray_contents(dm_args);) but always
fails, someone can help me to do log of full dm_args please?

Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Need-help-with-qemu-args-debug-tp5524689p5524689.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:23:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hcL-0007Sc-1c; Wed, 29 Feb 2012 11:22:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2hcJ-0007SX-Lw
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:22:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330514557!9782950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6273 invoked from network); 29 Feb 2012 11:22:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:22:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11006403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 11:22:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 11:22:36 +0000
Message-ID: <1330514555.4270.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 29 Feb 2012 11:22:35 +0000
In-Reply-To: <1330513756170-5524689.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 11:09 +0000, Fantu wrote:
> I'm trying to make the necessary patches to complete the Spice support on
> libxl.
> Qxl graphic add do always error and I not understand why, I need to see all
> dm_args for try to search the cause, I try with LIBXL__LOG (on libxl_dm.c
> before the line return (char **) flexarray_contents(dm_args);) but always
> fails, someone can help me to do log of full dm_args please?

That should be possible, but you haven't shown your code so I can't say
where you have gone wrong.

What I often do is create qemu-debug.sh:
	#!/bin/sh
	echo "Starting QEMU with: $*" >> /tmp/qemu-dbg.log
	exec /usr/lib/xen/bin/qemu-system-i386 $@

And then using device_model_override to call this instead of calling
qemu directly.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:23:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hcL-0007Sc-1c; Wed, 29 Feb 2012 11:22:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2hcJ-0007SX-Lw
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:22:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330514557!9782950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6273 invoked from network); 29 Feb 2012 11:22:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:22:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11006403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 11:22:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 11:22:36 +0000
Message-ID: <1330514555.4270.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 29 Feb 2012 11:22:35 +0000
In-Reply-To: <1330513756170-5524689.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 11:09 +0000, Fantu wrote:
> I'm trying to make the necessary patches to complete the Spice support on
> libxl.
> Qxl graphic add do always error and I not understand why, I need to see all
> dm_args for try to search the cause, I try with LIBXL__LOG (on libxl_dm.c
> before the line return (char **) flexarray_contents(dm_args);) but always
> fails, someone can help me to do log of full dm_args please?

That should be possible, but you haven't shown your code so I can't say
where you have gone wrong.

What I often do is create qemu-debug.sh:
	#!/bin/sh
	echo "Starting QEMU with: $*" >> /tmp/qemu-dbg.log
	exec /usr/lib/xen/bin/qemu-system-i386 $@

And then using device_model_override to call this instead of calling
qemu directly.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:41:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11: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 1S2hu2-0007sL-Ah; Wed, 29 Feb 2012 11:41:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2hu0-0007sC-Dw
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:41:00 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330515652!15455992!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12896 invoked from network); 29 Feb 2012 11:40:53 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:40:53 -0000
Received: by iadj38 with SMTP id j38so8483601iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 03:40:51 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.220.164 as permitted sender) client-ip=10.50.220.164; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.220.164 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.220.164])
	by 10.50.220.164 with SMTP id px4mr6351327igc.46.1330515651695
	(num_hops = 1); Wed, 29 Feb 2012 03:40:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=d28XT9VL1vs0jEqqYe6wmTwKIIlbY+/fchoycBPWQsU=;
	b=mowQirGNcZp15W3sLLs6IMMy4m8PT1/S6+HE80nXx9Rdm+Y0gO28AcOH+OHRh852XJ
	GkwkCV2M/JIOy6tC0bF0zM3HFqPDswvSYI7Wsqne9qmDyxg7sbgiNBqyXhYU5O1+2DBa
	ZptYNngdemoAnsAXrOK/+k2QVH5muZMXIEcng=
MIME-Version: 1.0
Received: by 10.50.220.164 with SMTP id px4mr5269861igc.46.1330515651612; Wed,
	29 Feb 2012 03:40:51 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Wed, 29 Feb 2012 03:40:51 -0800 (PST)
In-Reply-To: <1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 11:40:51 +0000
X-Google-Sender-Auth: VUVDT--EgENKXA0djrPtMfcmCbs
Message-ID: <CAFLBxZYt0iUN_8vmUutOXCvGSUEK1yS9vupn63c93AhWiZyW4w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 6:27 PM, David Vrabel <david.vrabel@citrix.com> wro=
te:
> From: David Vrabel <david.vrabel@citrix.com>
>
> To allow new parameters to be added to the xc_hvm_build*() family of
> functions, pass them in a structure. =A0Make the other variants fill in
> the structure and call xc_hvm_build() (except for xc_hvm_build_mem()
> which had no users and is removed).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

You should probably mention in the commit message that you're changing
from megabytes to bytes.  Other than that, looks good to me:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

> ---
> =A0tools/libxc/ia64/xc_ia64_hvm_build.c | =A0 21 ++++--
> =A0tools/libxc/xc_hvm_build.c =A0 =A0 =A0 =A0 =A0 | =A0115 +++++++++-----=
--------------------
> =A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 27 +++++---
> =A0tools/libxc/xg_private.c =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A03 +-
> =A04 files changed, 62 insertions(+), 104 deletions(-)
>
> diff --git a/tools/libxc/ia64/xc_ia64_hvm_build.c b/tools/libxc/ia64/xc_i=
a64_hvm_build.c
> index 18be616..16dace0 100644
> --- a/tools/libxc/ia64/xc_ia64_hvm_build.c
> +++ b/tools/libxc/ia64/xc_ia64_hvm_build.c
> @@ -912,8 +912,8 @@ setup_guest(xc_interface *xch, uint32_t dom, unsigned=
 long memsize,
> =A0 =A0 =A0 =A0 =A0 =A0 char *image, unsigned long image_size)
> =A0{
> =A0 =A0 xen_pfn_t *pfn_list;
> - =A0 =A0unsigned long dom_memsize =3D memsize << 20;
> - =A0 =A0unsigned long nr_pages =3D memsize << (20 - PAGE_SHIFT);
> + =A0 =A0unsigned long dom_memsize =3D memsize;
> + =A0 =A0unsigned long nr_pages =3D memsize >> PAGE_SHIFT;
> =A0 =A0 unsigned long vcpus;
> =A0 =A0 unsigned long nr_special_pages;
> =A0 =A0 unsigned long memmap_info_pfn;
> @@ -1072,14 +1072,14 @@ error_out:
> =A0}
>
> =A0int
> -xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char =
*image_name)
> +xc_hvm_build(xc_interface *xch, uint32_t domid, const struct xc_hvm_para=
ms *params)
> =A0{
> =A0 =A0 vcpu_guest_context_any_t st_ctxt_any;
> =A0 =A0 vcpu_guest_context_t *ctxt =3D &st_ctxt_any.c;
> =A0 =A0 char *image =3D NULL;
> =A0 =A0 unsigned long image_size;
>
> - =A0 =A0image =3D xc_read_image(xch, image_name, &image_size);
> + =A0 =A0image =3D xc_read_image(xch, params->image_file_name, &image_siz=
e);
> =A0 =A0 if (image =3D=3D NULL) {
> =A0 =A0 =A0 =A0 PERROR("Could not read guest firmware image %s", image_na=
me);
> =A0 =A0 =A0 =A0 goto error_out;
> @@ -1087,7 +1087,7 @@ xc_hvm_build(xc_interface *xch, uint32_t domid, int=
 memsize, const char *image_n
>
> =A0 =A0 image_size =3D (image_size + PAGE_SIZE - 1) & PAGE_MASK;
>
> - =A0 =A0if (setup_guest(xch, domid, (unsigned long)memsize, image,
> + =A0 =A0if (setup_guest(xch, domid, (unsigned long)params->mem_size, ima=
ge,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 image_size) < 0) {
> =A0 =A0 =A0 =A0 ERROR("Error constructing guest OS");
> =A0 =A0 =A0 =A0 goto error_out;
> @@ -1114,6 +1114,8 @@ error_out:
> =A0* files/filenames. =A0If target < memsize, domain is created with
> =A0* memsize pages marked populate-on-demand, and with a PoD cache size
> =A0* of target. =A0If target =3D=3D memsize, pages are populated normally.
> + *
> + * XXX:PoD isn't supported yet so setting target does nothing.
> =A0*/
> =A0int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> @@ -1121,8 +1123,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int target,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image=
_name)
> =A0{
> - =A0 =A0/* XXX:PoD isn't supported yet */
> - =A0 =A0return xc_hvm_build(xch, domid, target, image_name);
> + =A0 =A0struct xc_hvm_params params;
> +
> + =A0 =A0params.mem_size =3D (uint64_t)memsize << 20;
> + =A0 =A0params.mem_target =3D (uint64_t)target << 20;
> + =A0 =A0params.image_file_name =3D image_name;
> +
> + =A0 =A0return xc_hvm_build(xch, domid, &params);
> =A0}
>
> =A0/*
> diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
> index 1fa5658..31d4734 100644
> --- a/tools/libxc/xc_hvm_build.c
> +++ b/tools/libxc/xc_hvm_build.c
> @@ -136,12 +136,12 @@ static int check_mmio_hole(uint64_t start, uint64_t=
 memsize)
> =A0}
>
> =A0static int setup_guest(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t dom, int memsize, =
int target,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t dom, const struct =
xc_hvm_params *params,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *image, unsigned long=
 image_size)
> =A0{
> =A0 =A0 xen_pfn_t *page_array =3D NULL;
> - =A0 =A0unsigned long i, nr_pages =3D (unsigned long)memsize << (20 - PA=
GE_SHIFT);
> - =A0 =A0unsigned long target_pages =3D (unsigned long)target << (20 - PA=
GE_SHIFT);
> + =A0 =A0unsigned long i, nr_pages =3D params->mem_size >> PAGE_SHIFT;
> + =A0 =A0unsigned long target_pages =3D params->mem_target >> PAGE_SHIFT;
> =A0 =A0 unsigned long entry_eip, cur_pages, cur_pfn;
> =A0 =A0 void *hvm_info_page;
> =A0 =A0 uint32_t *ident_pt;
> @@ -153,11 +153,7 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 =A0 =A0 stat_1gb_pages =3D 0;
> =A0 =A0 int pod_mode =3D 0;
>
> - =A0 =A0/* An HVM guest must be initialised with at least 2MB memory. */
> - =A0 =A0if ( memsize < 2 || target < 2 )
> - =A0 =A0 =A0 =A0goto error_out;
> -
> - =A0 =A0if ( memsize > target )
> + =A0 =A0if ( nr_pages > target_pages )
> =A0 =A0 =A0 =A0 pod_mode =3D 1;
>
> =A0 =A0 memset(&elf, 0, sizeof(elf));
> @@ -168,7 +164,7 @@ static int setup_guest(xc_interface *xch,
>
> =A0 =A0 elf_parse_binary(&elf);
> =A0 =A0 v_start =3D 0;
> - =A0 =A0v_end =3D (unsigned long long)memsize << 20;
> + =A0 =A0v_end =3D params->mem_size;
>
> =A0 =A0 if ( xc_version(xch, XENVER_capabilities, &caps) !=3D 0 )
> =A0 =A0 {
> @@ -393,39 +389,34 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 return -1;
> =A0}
>
> -static int xc_hvm_build_internal(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_=
t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int mem=
size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int tar=
get,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *i=
mage,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigne=
d long image_size)
> -{
> - =A0 =A0if ( (image =3D=3D NULL) || (image_size =3D=3D 0) )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0ERROR("Image required");
> - =A0 =A0 =A0 =A0return -1;
> - =A0 =A0}
> -
> - =A0 =A0return setup_guest(xch, domid, memsize, target, image, image_siz=
e);
> -}
> -
> =A0/* xc_hvm_build:
> =A0* Create a domain for a virtualized Linux, using files/filenames.
> =A0*/
> -int xc_hvm_build(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_name)
> +int xc_hvm_build(xc_interface *xch, uint32_t domid,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct xc_hvm_params *hvm_params)
> =A0{
> - =A0 =A0char *image;
> - =A0 =A0int =A0sts;
> + =A0 =A0struct xc_hvm_params params =3D *hvm_params;
> + =A0 =A0void *image;
> =A0 =A0 unsigned long image_size;
> + =A0 =A0int sts;
>
> - =A0 =A0if ( (image_name =3D=3D NULL) ||
> - =A0 =A0 =A0 =A0 ((image =3D xc_read_image(xch, image_name, &image_size)=
) =3D=3D NULL) )
> + =A0 =A0if ( domid =3D=3D 0 )
> + =A0 =A0 =A0 =A0return -1;
> + =A0 =A0if ( params.image_file_name =3D=3D NULL )
> =A0 =A0 =A0 =A0 return -1;
>
> - =A0 =A0sts =3D xc_hvm_build_internal(xch, domid, memsize, memsize, imag=
e, image_size);
> + =A0 =A0if ( params.mem_target =3D=3D 0 )
> + =A0 =A0 =A0 =A0params.mem_target =3D params.mem_size;
> +
> + =A0 =A0/* An HVM guest must be initialised with at least 2MB memory. */
> + =A0 =A0if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull=
 << 20) )
> + =A0 =A0 =A0 =A0return -1;
> +
> + =A0 =A0image =3D xc_read_image(xch, params.image_file_name, &image_size=
);
> + =A0 =A0if ( image =3D=3D NULL )
> + =A0 =A0 =A0 =A0return -1;
> +
> + =A0 =A0sts =3D setup_guest(xch, domid, &params, image, image_size);
>
> =A0 =A0 free(image);
>
> @@ -445,59 +436,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int target,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *image_=
name)
> =A0{
> - =A0 =A0char *image;
> - =A0 =A0int =A0sts;
> - =A0 =A0unsigned long image_size;
> + =A0 =A0struct xc_hvm_params params =3D {};
>
> - =A0 =A0if ( (image_name =3D=3D NULL) ||
> - =A0 =A0 =A0 =A0 ((image =3D xc_read_image(xch, image_name, &image_size)=
) =3D=3D NULL) )
> - =A0 =A0 =A0 =A0return -1;
> + =A0 =A0params.mem_size =3D (uint64_t)memsize << 20;
> + =A0 =A0params.mem_target =3D (uint64_t)target << 20;
> + =A0 =A0params.image_file_name =3D image_name;
>
> - =A0 =A0sts =3D xc_hvm_build_internal(xch, domid, memsize, target, image=
, image_size);
> -
> - =A0 =A0free(image);
> -
> - =A0 =A0return sts;
> -}
> -
> -/* xc_hvm_build_mem:
> - * Create a domain for a virtualized Linux, using memory buffers.
> - */
> -int xc_hvm_build_mem(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_buffer,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long image_size)
> -{
> - =A0 =A0int =A0 =A0 =A0 =A0 =A0 sts;
> - =A0 =A0unsigned long img_len;
> - =A0 =A0char =A0 =A0 =A0 =A0 *img;
> -
> - =A0 =A0/* Validate that there is a kernel buffer */
> -
> - =A0 =A0if ( (image_buffer =3D=3D NULL) || (image_size =3D=3D 0) )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0ERROR("kernel image buffer not present");
> - =A0 =A0 =A0 =A0return -1;
> - =A0 =A0}
> -
> - =A0 =A0img =3D xc_inflate_buffer(xch, image_buffer, image_size, &img_le=
n);
> - =A0 =A0if ( img =3D=3D NULL )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0ERROR("unable to inflate ram disk buffer");
> - =A0 =A0 =A0 =A0return -1;
> - =A0 =A0}
> -
> - =A0 =A0sts =3D xc_hvm_build_internal(xch, domid, memsize, memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0img, img=
_len);
> -
> - =A0 =A0/* xc_inflate_buffer may return the original buffer pointer (for
> - =A0 =A0 =A0 for already inflated buffers), so exercise some care in fre=
eing */
> -
> - =A0 =A0if ( (img !=3D NULL) && (img !=3D image_buffer) )
> - =A0 =A0 =A0 =A0free(img);
> -
> - =A0 =A0return sts;
> + =A0 =A0return xc_hvm_build(xch, domid, &params);
> =A0}
>
> =A0/*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 533e702..19b0382 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int console_evtch=
n,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *console_mfn=
);
>
> -int xc_hvm_build(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_name);
> +struct xc_hvm_params {
> + =A0 =A0uint64_t mem_size; =A0 =A0 =A0 =A0 =A0 /**< Memory size in bytes=
. */
> + =A0 =A0uint64_t mem_target; =A0 =A0 =A0 =A0 /**< Memory target in bytes=
. */
> + =A0 =A0const char *image_file_name; /**< File name of the image to load=
. */
> +};
> +
> +/**
> + * Build a HVM domain using a set of parameters.
> + * @parm xch =A0 =A0libxc context handle.
> + * @parm domid =A0domain ID for the new domain.
> + * @parm params parameters for the new domain.
> + *
> + * The memory size and image file parameters are required, the reset
> + * are optional.
> + */
> +int xc_hvm_build(xc_interface *xch, uint32_t domid,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct xc_hvm_params *hvm_params);
>
> =A0int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> @@ -182,12 +195,6 @@ int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int target,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image=
_name);
>
> -int xc_hvm_build_mem(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_buffer,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long image_size);
> -
> =A0int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int d=
omid, int suspend_evtchn);
>
> =A0int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domi=
d, int port);
> diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
> index 4b624a5..f7e2139 100644
> --- a/tools/libxc/xg_private.c
> +++ b/tools/libxc/xg_private.c
> @@ -192,8 +192,7 @@ unsigned long csum_page(void *page)
> =A0__attribute__((weak))
> =A0 =A0 int xc_hvm_build(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_name)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct xc_hvm_params *hvm=
_params)
> =A0{
> =A0 =A0 errno =3D ENOSYS;
> =A0 =A0 return -1;
> --
> 1.7.2.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:41:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11: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 1S2hu2-0007sL-Ah; Wed, 29 Feb 2012 11:41:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2hu0-0007sC-Dw
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:41:00 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330515652!15455992!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12896 invoked from network); 29 Feb 2012 11:40:53 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:40:53 -0000
Received: by iadj38 with SMTP id j38so8483601iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 03:40:51 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.220.164 as permitted sender) client-ip=10.50.220.164; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.220.164 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.220.164])
	by 10.50.220.164 with SMTP id px4mr6351327igc.46.1330515651695
	(num_hops = 1); Wed, 29 Feb 2012 03:40:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=d28XT9VL1vs0jEqqYe6wmTwKIIlbY+/fchoycBPWQsU=;
	b=mowQirGNcZp15W3sLLs6IMMy4m8PT1/S6+HE80nXx9Rdm+Y0gO28AcOH+OHRh852XJ
	GkwkCV2M/JIOy6tC0bF0zM3HFqPDswvSYI7Wsqne9qmDyxg7sbgiNBqyXhYU5O1+2DBa
	ZptYNngdemoAnsAXrOK/+k2QVH5muZMXIEcng=
MIME-Version: 1.0
Received: by 10.50.220.164 with SMTP id px4mr5269861igc.46.1330515651612; Wed,
	29 Feb 2012 03:40:51 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Wed, 29 Feb 2012 03:40:51 -0800 (PST)
In-Reply-To: <1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 11:40:51 +0000
X-Google-Sender-Auth: VUVDT--EgENKXA0djrPtMfcmCbs
Message-ID: <CAFLBxZYt0iUN_8vmUutOXCvGSUEK1yS9vupn63c93AhWiZyW4w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 6:27 PM, David Vrabel <david.vrabel@citrix.com> wro=
te:
> From: David Vrabel <david.vrabel@citrix.com>
>
> To allow new parameters to be added to the xc_hvm_build*() family of
> functions, pass them in a structure. =A0Make the other variants fill in
> the structure and call xc_hvm_build() (except for xc_hvm_build_mem()
> which had no users and is removed).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

You should probably mention in the commit message that you're changing
from megabytes to bytes.  Other than that, looks good to me:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

> ---
> =A0tools/libxc/ia64/xc_ia64_hvm_build.c | =A0 21 ++++--
> =A0tools/libxc/xc_hvm_build.c =A0 =A0 =A0 =A0 =A0 | =A0115 +++++++++-----=
--------------------
> =A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 27 +++++---
> =A0tools/libxc/xg_private.c =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A03 +-
> =A04 files changed, 62 insertions(+), 104 deletions(-)
>
> diff --git a/tools/libxc/ia64/xc_ia64_hvm_build.c b/tools/libxc/ia64/xc_i=
a64_hvm_build.c
> index 18be616..16dace0 100644
> --- a/tools/libxc/ia64/xc_ia64_hvm_build.c
> +++ b/tools/libxc/ia64/xc_ia64_hvm_build.c
> @@ -912,8 +912,8 @@ setup_guest(xc_interface *xch, uint32_t dom, unsigned=
 long memsize,
> =A0 =A0 =A0 =A0 =A0 =A0 char *image, unsigned long image_size)
> =A0{
> =A0 =A0 xen_pfn_t *pfn_list;
> - =A0 =A0unsigned long dom_memsize =3D memsize << 20;
> - =A0 =A0unsigned long nr_pages =3D memsize << (20 - PAGE_SHIFT);
> + =A0 =A0unsigned long dom_memsize =3D memsize;
> + =A0 =A0unsigned long nr_pages =3D memsize >> PAGE_SHIFT;
> =A0 =A0 unsigned long vcpus;
> =A0 =A0 unsigned long nr_special_pages;
> =A0 =A0 unsigned long memmap_info_pfn;
> @@ -1072,14 +1072,14 @@ error_out:
> =A0}
>
> =A0int
> -xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char =
*image_name)
> +xc_hvm_build(xc_interface *xch, uint32_t domid, const struct xc_hvm_para=
ms *params)
> =A0{
> =A0 =A0 vcpu_guest_context_any_t st_ctxt_any;
> =A0 =A0 vcpu_guest_context_t *ctxt =3D &st_ctxt_any.c;
> =A0 =A0 char *image =3D NULL;
> =A0 =A0 unsigned long image_size;
>
> - =A0 =A0image =3D xc_read_image(xch, image_name, &image_size);
> + =A0 =A0image =3D xc_read_image(xch, params->image_file_name, &image_siz=
e);
> =A0 =A0 if (image =3D=3D NULL) {
> =A0 =A0 =A0 =A0 PERROR("Could not read guest firmware image %s", image_na=
me);
> =A0 =A0 =A0 =A0 goto error_out;
> @@ -1087,7 +1087,7 @@ xc_hvm_build(xc_interface *xch, uint32_t domid, int=
 memsize, const char *image_n
>
> =A0 =A0 image_size =3D (image_size + PAGE_SIZE - 1) & PAGE_MASK;
>
> - =A0 =A0if (setup_guest(xch, domid, (unsigned long)memsize, image,
> + =A0 =A0if (setup_guest(xch, domid, (unsigned long)params->mem_size, ima=
ge,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 image_size) < 0) {
> =A0 =A0 =A0 =A0 ERROR("Error constructing guest OS");
> =A0 =A0 =A0 =A0 goto error_out;
> @@ -1114,6 +1114,8 @@ error_out:
> =A0* files/filenames. =A0If target < memsize, domain is created with
> =A0* memsize pages marked populate-on-demand, and with a PoD cache size
> =A0* of target. =A0If target =3D=3D memsize, pages are populated normally.
> + *
> + * XXX:PoD isn't supported yet so setting target does nothing.
> =A0*/
> =A0int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> @@ -1121,8 +1123,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int target,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image=
_name)
> =A0{
> - =A0 =A0/* XXX:PoD isn't supported yet */
> - =A0 =A0return xc_hvm_build(xch, domid, target, image_name);
> + =A0 =A0struct xc_hvm_params params;
> +
> + =A0 =A0params.mem_size =3D (uint64_t)memsize << 20;
> + =A0 =A0params.mem_target =3D (uint64_t)target << 20;
> + =A0 =A0params.image_file_name =3D image_name;
> +
> + =A0 =A0return xc_hvm_build(xch, domid, &params);
> =A0}
>
> =A0/*
> diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
> index 1fa5658..31d4734 100644
> --- a/tools/libxc/xc_hvm_build.c
> +++ b/tools/libxc/xc_hvm_build.c
> @@ -136,12 +136,12 @@ static int check_mmio_hole(uint64_t start, uint64_t=
 memsize)
> =A0}
>
> =A0static int setup_guest(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t dom, int memsize, =
int target,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t dom, const struct =
xc_hvm_params *params,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *image, unsigned long=
 image_size)
> =A0{
> =A0 =A0 xen_pfn_t *page_array =3D NULL;
> - =A0 =A0unsigned long i, nr_pages =3D (unsigned long)memsize << (20 - PA=
GE_SHIFT);
> - =A0 =A0unsigned long target_pages =3D (unsigned long)target << (20 - PA=
GE_SHIFT);
> + =A0 =A0unsigned long i, nr_pages =3D params->mem_size >> PAGE_SHIFT;
> + =A0 =A0unsigned long target_pages =3D params->mem_target >> PAGE_SHIFT;
> =A0 =A0 unsigned long entry_eip, cur_pages, cur_pfn;
> =A0 =A0 void *hvm_info_page;
> =A0 =A0 uint32_t *ident_pt;
> @@ -153,11 +153,7 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 =A0 =A0 stat_1gb_pages =3D 0;
> =A0 =A0 int pod_mode =3D 0;
>
> - =A0 =A0/* An HVM guest must be initialised with at least 2MB memory. */
> - =A0 =A0if ( memsize < 2 || target < 2 )
> - =A0 =A0 =A0 =A0goto error_out;
> -
> - =A0 =A0if ( memsize > target )
> + =A0 =A0if ( nr_pages > target_pages )
> =A0 =A0 =A0 =A0 pod_mode =3D 1;
>
> =A0 =A0 memset(&elf, 0, sizeof(elf));
> @@ -168,7 +164,7 @@ static int setup_guest(xc_interface *xch,
>
> =A0 =A0 elf_parse_binary(&elf);
> =A0 =A0 v_start =3D 0;
> - =A0 =A0v_end =3D (unsigned long long)memsize << 20;
> + =A0 =A0v_end =3D params->mem_size;
>
> =A0 =A0 if ( xc_version(xch, XENVER_capabilities, &caps) !=3D 0 )
> =A0 =A0 {
> @@ -393,39 +389,34 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 return -1;
> =A0}
>
> -static int xc_hvm_build_internal(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_=
t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int mem=
size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int tar=
get,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *i=
mage,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigne=
d long image_size)
> -{
> - =A0 =A0if ( (image =3D=3D NULL) || (image_size =3D=3D 0) )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0ERROR("Image required");
> - =A0 =A0 =A0 =A0return -1;
> - =A0 =A0}
> -
> - =A0 =A0return setup_guest(xch, domid, memsize, target, image, image_siz=
e);
> -}
> -
> =A0/* xc_hvm_build:
> =A0* Create a domain for a virtualized Linux, using files/filenames.
> =A0*/
> -int xc_hvm_build(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_name)
> +int xc_hvm_build(xc_interface *xch, uint32_t domid,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct xc_hvm_params *hvm_params)
> =A0{
> - =A0 =A0char *image;
> - =A0 =A0int =A0sts;
> + =A0 =A0struct xc_hvm_params params =3D *hvm_params;
> + =A0 =A0void *image;
> =A0 =A0 unsigned long image_size;
> + =A0 =A0int sts;
>
> - =A0 =A0if ( (image_name =3D=3D NULL) ||
> - =A0 =A0 =A0 =A0 ((image =3D xc_read_image(xch, image_name, &image_size)=
) =3D=3D NULL) )
> + =A0 =A0if ( domid =3D=3D 0 )
> + =A0 =A0 =A0 =A0return -1;
> + =A0 =A0if ( params.image_file_name =3D=3D NULL )
> =A0 =A0 =A0 =A0 return -1;
>
> - =A0 =A0sts =3D xc_hvm_build_internal(xch, domid, memsize, memsize, imag=
e, image_size);
> + =A0 =A0if ( params.mem_target =3D=3D 0 )
> + =A0 =A0 =A0 =A0params.mem_target =3D params.mem_size;
> +
> + =A0 =A0/* An HVM guest must be initialised with at least 2MB memory. */
> + =A0 =A0if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull=
 << 20) )
> + =A0 =A0 =A0 =A0return -1;
> +
> + =A0 =A0image =3D xc_read_image(xch, params.image_file_name, &image_size=
);
> + =A0 =A0if ( image =3D=3D NULL )
> + =A0 =A0 =A0 =A0return -1;
> +
> + =A0 =A0sts =3D setup_guest(xch, domid, &params, image, image_size);
>
> =A0 =A0 free(image);
>
> @@ -445,59 +436,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int target,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *image_=
name)
> =A0{
> - =A0 =A0char *image;
> - =A0 =A0int =A0sts;
> - =A0 =A0unsigned long image_size;
> + =A0 =A0struct xc_hvm_params params =3D {};
>
> - =A0 =A0if ( (image_name =3D=3D NULL) ||
> - =A0 =A0 =A0 =A0 ((image =3D xc_read_image(xch, image_name, &image_size)=
) =3D=3D NULL) )
> - =A0 =A0 =A0 =A0return -1;
> + =A0 =A0params.mem_size =3D (uint64_t)memsize << 20;
> + =A0 =A0params.mem_target =3D (uint64_t)target << 20;
> + =A0 =A0params.image_file_name =3D image_name;
>
> - =A0 =A0sts =3D xc_hvm_build_internal(xch, domid, memsize, target, image=
, image_size);
> -
> - =A0 =A0free(image);
> -
> - =A0 =A0return sts;
> -}
> -
> -/* xc_hvm_build_mem:
> - * Create a domain for a virtualized Linux, using memory buffers.
> - */
> -int xc_hvm_build_mem(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_buffer,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long image_size)
> -{
> - =A0 =A0int =A0 =A0 =A0 =A0 =A0 sts;
> - =A0 =A0unsigned long img_len;
> - =A0 =A0char =A0 =A0 =A0 =A0 *img;
> -
> - =A0 =A0/* Validate that there is a kernel buffer */
> -
> - =A0 =A0if ( (image_buffer =3D=3D NULL) || (image_size =3D=3D 0) )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0ERROR("kernel image buffer not present");
> - =A0 =A0 =A0 =A0return -1;
> - =A0 =A0}
> -
> - =A0 =A0img =3D xc_inflate_buffer(xch, image_buffer, image_size, &img_le=
n);
> - =A0 =A0if ( img =3D=3D NULL )
> - =A0 =A0{
> - =A0 =A0 =A0 =A0ERROR("unable to inflate ram disk buffer");
> - =A0 =A0 =A0 =A0return -1;
> - =A0 =A0}
> -
> - =A0 =A0sts =3D xc_hvm_build_internal(xch, domid, memsize, memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0img, img=
_len);
> -
> - =A0 =A0/* xc_inflate_buffer may return the original buffer pointer (for
> - =A0 =A0 =A0 for already inflated buffers), so exercise some care in fre=
eing */
> -
> - =A0 =A0if ( (img !=3D NULL) && (img !=3D image_buffer) )
> - =A0 =A0 =A0 =A0free(img);
> -
> - =A0 =A0return sts;
> + =A0 =A0return xc_hvm_build(xch, domid, &params);
> =A0}
>
> =A0/*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 533e702..19b0382 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int console_evtch=
n,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *console_mfn=
);
>
> -int xc_hvm_build(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_name);
> +struct xc_hvm_params {
> + =A0 =A0uint64_t mem_size; =A0 =A0 =A0 =A0 =A0 /**< Memory size in bytes=
. */
> + =A0 =A0uint64_t mem_target; =A0 =A0 =A0 =A0 /**< Memory target in bytes=
. */
> + =A0 =A0const char *image_file_name; /**< File name of the image to load=
. */
> +};
> +
> +/**
> + * Build a HVM domain using a set of parameters.
> + * @parm xch =A0 =A0libxc context handle.
> + * @parm domid =A0domain ID for the new domain.
> + * @parm params parameters for the new domain.
> + *
> + * The memory size and image file parameters are required, the reset
> + * are optional.
> + */
> +int xc_hvm_build(xc_interface *xch, uint32_t domid,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct xc_hvm_params *hvm_params);
>
> =A0int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> @@ -182,12 +195,6 @@ int xc_hvm_build_target_mem(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int target,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image=
_name);
>
> -int xc_hvm_build_mem(xc_interface *xch,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_buffer,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long image_size);
> -
> =A0int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int d=
omid, int suspend_evtchn);
>
> =A0int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domi=
d, int port);
> diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
> index 4b624a5..f7e2139 100644
> --- a/tools/libxc/xg_private.c
> +++ b/tools/libxc/xg_private.c
> @@ -192,8 +192,7 @@ unsigned long csum_page(void *page)
> =A0__attribute__((weak))
> =A0 =A0 int xc_hvm_build(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t domid,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int memsize,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *image_name)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct xc_hvm_params *hvm=
_params)
> =A0{
> =A0 =A0 errno =3D ENOSYS;
> =A0 =A0 return -1;
> --
> 1.7.2.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:42:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hum-0007ur-Oy; Wed, 29 Feb 2012 11:41:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2huk-0007uV-Qn
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:41:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330515698!11230812!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11099 invoked from network); 29 Feb 2012 11:41:40 -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;
	29 Feb 2012 11:41:40 -0000
Received: by iadj38 with SMTP id j38so8484757iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 03:41:38 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.194.232 as permitted sender) client-ip=10.50.194.232; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.194.232 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.194.232])
	by 10.50.194.232 with SMTP id hz8mr6413781igc.38.1330515698331
	(num_hops = 1); Wed, 29 Feb 2012 03:41:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5jGGxndjWWtzDAw6uK8X7fYjGHvY+8hBOsBsrzyUB7o=;
	b=K7opfvf0gB7ZqHDiAIh0X5tDaLyaLM79lLjGLXgV9aK8fMAZAS7BZro4Q7wb4VcMuT
	FhBnG0rx755/0Ax583ocm3a6V8p3iGeVNBGgWmpK6J2JGG8i5Qd7NepDS7u9SyDIS39N
	uj0jPnY0PziaJCGPmV1ZqKEHu8RhUG1HWIFKw=
MIME-Version: 1.0
Received: by 10.50.194.232 with SMTP id hz8mr5324255igc.38.1330515698227; Wed,
	29 Feb 2012 03:41:38 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Wed, 29 Feb 2012 03:41:38 -0800 (PST)
In-Reply-To: <1330453673-8606-3-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-3-git-send-email-david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 11:41:38 +0000
X-Google-Sender-Auth: VncXBiCEDM3wYyiqtp94nFkwRRI
Message-ID: <CAFLBxZbA2nOKHujoAY5ww4_2iwG1oY9Q50zhFbf_CzoGcJZLbw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] libxc: add MMIO hole size parameter to
	xc_hvm_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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 6:27 PM, David Vrabel <david.vrabel@citrix.com> wro=
te:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Add a parameter for the MMIO hole size when building a HVM domain.
>
> This is useful for specifying a larger than normal MMIO hole to ensure
> that no PCI device's MMIO region overlaps with the guest physical
> addresses of RAM. =A0This is needed on certain systems with PCI bridges
> with ACS versions that are broken. =A0On these systems, if a device
> behind the bridge attempts a DMA to a guest physical address that
> overlaps with the MMIO region of another device behind the bridge,
> then the bridge intercepts the access and forwards it directly to the
> device and the read or write never hits RAM.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

> ---
> =A0tools/libxc/xc_hvm_build.c | =A0 29 ++++++++++++++++++-----------
> =A0tools/libxc/xenguest.h =A0 =A0 | =A0 =A01 +
> =A02 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
> index 31d4734..fbeddac 100644
> --- a/tools/libxc/xc_hvm_build.c
> +++ b/tools/libxc/xc_hvm_build.c
> @@ -46,7 +46,8 @@
> =A0#define NR_SPECIAL_PAGES =A0 =A0 5
> =A0#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
>
> -static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
> +static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint64_t mmio_start=
, uint64_t mmio_size)
> =A0{
> =A0 =A0 struct hvm_info_table *hvm_info =3D (struct hvm_info_table *)
> =A0 =A0 =A0 =A0 (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> @@ -54,10 +55,10 @@ static void build_hvm_info(void *hvm_info_page, uint6=
4_t mem_size)
> =A0 =A0 uint8_t sum;
> =A0 =A0 int i;
>
> - =A0 =A0if ( lowmem_end > HVM_BELOW_4G_RAM_END )
> + =A0 =A0if ( lowmem_end > mmio_start )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0highmem_end =3D lowmem_end + (1ull<<32) - HVM_BELOW_4G_R=
AM_END;
> - =A0 =A0 =A0 =A0lowmem_end =3D HVM_BELOW_4G_RAM_END;
> + =A0 =A0 =A0 =A0highmem_end =3D (1ull<<32) + (lowmem_end - mmio_start);
> + =A0 =A0 =A0 =A0lowmem_end =3D mmio_start;
> =A0 =A0 }
>
> =A0 =A0 memset(hvm_info_page, 0, PAGE_SIZE);
> @@ -126,10 +127,10 @@ static int loadelfimage(
> =A0* Check whether there exists mmio hole in the specified memory range.
> =A0* Returns 1 if exists, else returns 0.
> =A0*/
> -static int check_mmio_hole(uint64_t start, uint64_t memsize)
> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint64_t mmio_start=
, uint64_t mmio_size)
> =A0{
> - =A0 =A0if ( start + memsize <=3D HVM_BELOW_4G_MMIO_START ||
> - =A0 =A0 =A0 =A0 start >=3D HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_=
LENGTH )
> + =A0 =A0if ( start + memsize <=3D mmio_start || start >=3D mmio_start + =
mmio_size )
> =A0 =A0 =A0 =A0 return 0;
> =A0 =A0 else
> =A0 =A0 =A0 =A0 return 1;
> @@ -142,6 +143,8 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 xen_pfn_t *page_array =3D NULL;
> =A0 =A0 unsigned long i, nr_pages =3D params->mem_size >> PAGE_SHIFT;
> =A0 =A0 unsigned long target_pages =3D params->mem_target >> PAGE_SHIFT;
> + =A0 =A0uint64_t mmio_start =3D (1ull << 32) - params->mmio_size;
> + =A0 =A0uint64_t mmio_size =3D params->mmio_size;
> =A0 =A0 unsigned long entry_eip, cur_pages, cur_pfn;
> =A0 =A0 void *hvm_info_page;
> =A0 =A0 uint32_t *ident_pt;
> @@ -188,8 +191,8 @@ static int setup_guest(xc_interface *xch,
>
> =A0 =A0 for ( i =3D 0; i < nr_pages; i++ )
> =A0 =A0 =A0 =A0 page_array[i] =3D i;
> - =A0 =A0for ( i =3D HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i+=
+ )
> - =A0 =A0 =A0 =A0page_array[i] +=3D HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIF=
T;
> + =A0 =A0for ( i =3D mmio_start >> PAGE_SHIFT; i < nr_pages; i++ )
> + =A0 =A0 =A0 =A0page_array[i] +=3D mmio_size >> PAGE_SHIFT;
>
> =A0 =A0 /*
> =A0 =A0 =A0* Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC=
0000.
> @@ -230,7 +233,8 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 =A0 =A0 if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) =
=3D=3D 0 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check if there exists MMIO hole in the 1GB =
memory range */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0!check_mmio_hole(cur_pfn << PAGE_SHIFT,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SUPERPAGE_1G=
B_NR_PFNS << PAGE_SHIFT) )
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SUPERPAGE_1G=
B_NR_PFNS << PAGE_SHIFT,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mmio_start, =
mmio_size) )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 long done;
> =A0 =A0 =A0 =A0 =A0 =A0 unsigned long nr_extents =3D count >> SUPERPAGE_1=
GB_SHIFT;
> @@ -327,7 +331,7 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 HVM_INFO_PFN)) =3D=3D NULL )
> =A0 =A0 =A0 =A0 goto error_out;
> - =A0 =A0build_hvm_info(hvm_info_page, v_end);
> + =A0 =A0build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
> =A0 =A0 munmap(hvm_info_page, PAGE_SIZE);
>
> =A0 =A0 /* Allocate and clear special pages. */
> @@ -408,6 +412,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
> =A0 =A0 if ( params.mem_target =3D=3D 0 )
> =A0 =A0 =A0 =A0 params.mem_target =3D params.mem_size;
>
> + =A0 =A0if ( params.mmio_size =3D=3D 0 )
> + =A0 =A0 =A0 =A0params.mmio_size =3D HVM_BELOW_4G_MMIO_LENGTH;
> +
> =A0 =A0 /* An HVM guest must be initialised with at least 2MB memory. */
> =A0 =A0 if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull =
<< 20) )
> =A0 =A0 =A0 =A0 return -1;
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 19b0382..b06788c 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -174,6 +174,7 @@ int xc_linux_build_mem(xc_interface *xch,
> =A0struct xc_hvm_params {
> =A0 =A0 uint64_t mem_size; =A0 =A0 =A0 =A0 =A0 /**< Memory size in bytes.=
 */
> =A0 =A0 uint64_t mem_target; =A0 =A0 =A0 =A0 /**< Memory target in bytes.=
 */
> + =A0 =A0uint64_t mmio_size; =A0 =A0 =A0 =A0 =A0/**< Size of the MMIO hol=
e in bytes. */
> =A0 =A0 const char *image_file_name; /**< File name of the image to load.=
 */
> =A0};
>
> --
> 1.7.2.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:42:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:42:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hum-0007ur-Oy; Wed, 29 Feb 2012 11:41:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2huk-0007uV-Qn
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:41:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1330515698!11230812!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11099 invoked from network); 29 Feb 2012 11:41:40 -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;
	29 Feb 2012 11:41:40 -0000
Received: by iadj38 with SMTP id j38so8484757iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 03:41:38 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.194.232 as permitted sender) client-ip=10.50.194.232; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.194.232 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.194.232])
	by 10.50.194.232 with SMTP id hz8mr6413781igc.38.1330515698331
	(num_hops = 1); Wed, 29 Feb 2012 03:41:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=5jGGxndjWWtzDAw6uK8X7fYjGHvY+8hBOsBsrzyUB7o=;
	b=K7opfvf0gB7ZqHDiAIh0X5tDaLyaLM79lLjGLXgV9aK8fMAZAS7BZro4Q7wb4VcMuT
	FhBnG0rx755/0Ax583ocm3a6V8p3iGeVNBGgWmpK6J2JGG8i5Qd7NepDS7u9SyDIS39N
	uj0jPnY0PziaJCGPmV1ZqKEHu8RhUG1HWIFKw=
MIME-Version: 1.0
Received: by 10.50.194.232 with SMTP id hz8mr5324255igc.38.1330515698227; Wed,
	29 Feb 2012 03:41:38 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Wed, 29 Feb 2012 03:41:38 -0800 (PST)
In-Reply-To: <1330453673-8606-3-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-3-git-send-email-david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 11:41:38 +0000
X-Google-Sender-Auth: VncXBiCEDM3wYyiqtp94nFkwRRI
Message-ID: <CAFLBxZbA2nOKHujoAY5ww4_2iwG1oY9Q50zhFbf_CzoGcJZLbw@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] libxc: add MMIO hole size parameter to
	xc_hvm_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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, 2012 at 6:27 PM, David Vrabel <david.vrabel@citrix.com> wro=
te:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Add a parameter for the MMIO hole size when building a HVM domain.
>
> This is useful for specifying a larger than normal MMIO hole to ensure
> that no PCI device's MMIO region overlaps with the guest physical
> addresses of RAM. =A0This is needed on certain systems with PCI bridges
> with ACS versions that are broken. =A0On these systems, if a device
> behind the bridge attempts a DMA to a guest physical address that
> overlaps with the MMIO region of another device behind the bridge,
> then the bridge intercepts the access and forwards it directly to the
> device and the read or write never hits RAM.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

> ---
> =A0tools/libxc/xc_hvm_build.c | =A0 29 ++++++++++++++++++-----------
> =A0tools/libxc/xenguest.h =A0 =A0 | =A0 =A01 +
> =A02 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
> index 31d4734..fbeddac 100644
> --- a/tools/libxc/xc_hvm_build.c
> +++ b/tools/libxc/xc_hvm_build.c
> @@ -46,7 +46,8 @@
> =A0#define NR_SPECIAL_PAGES =A0 =A0 5
> =A0#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
>
> -static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
> +static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint64_t mmio_start=
, uint64_t mmio_size)
> =A0{
> =A0 =A0 struct hvm_info_table *hvm_info =3D (struct hvm_info_table *)
> =A0 =A0 =A0 =A0 (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
> @@ -54,10 +55,10 @@ static void build_hvm_info(void *hvm_info_page, uint6=
4_t mem_size)
> =A0 =A0 uint8_t sum;
> =A0 =A0 int i;
>
> - =A0 =A0if ( lowmem_end > HVM_BELOW_4G_RAM_END )
> + =A0 =A0if ( lowmem_end > mmio_start )
> =A0 =A0 {
> - =A0 =A0 =A0 =A0highmem_end =3D lowmem_end + (1ull<<32) - HVM_BELOW_4G_R=
AM_END;
> - =A0 =A0 =A0 =A0lowmem_end =3D HVM_BELOW_4G_RAM_END;
> + =A0 =A0 =A0 =A0highmem_end =3D (1ull<<32) + (lowmem_end - mmio_start);
> + =A0 =A0 =A0 =A0lowmem_end =3D mmio_start;
> =A0 =A0 }
>
> =A0 =A0 memset(hvm_info_page, 0, PAGE_SIZE);
> @@ -126,10 +127,10 @@ static int loadelfimage(
> =A0* Check whether there exists mmio hole in the specified memory range.
> =A0* Returns 1 if exists, else returns 0.
> =A0*/
> -static int check_mmio_hole(uint64_t start, uint64_t memsize)
> +static int check_mmio_hole(uint64_t start, uint64_t memsize,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint64_t mmio_start=
, uint64_t mmio_size)
> =A0{
> - =A0 =A0if ( start + memsize <=3D HVM_BELOW_4G_MMIO_START ||
> - =A0 =A0 =A0 =A0 start >=3D HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_=
LENGTH )
> + =A0 =A0if ( start + memsize <=3D mmio_start || start >=3D mmio_start + =
mmio_size )
> =A0 =A0 =A0 =A0 return 0;
> =A0 =A0 else
> =A0 =A0 =A0 =A0 return 1;
> @@ -142,6 +143,8 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 xen_pfn_t *page_array =3D NULL;
> =A0 =A0 unsigned long i, nr_pages =3D params->mem_size >> PAGE_SHIFT;
> =A0 =A0 unsigned long target_pages =3D params->mem_target >> PAGE_SHIFT;
> + =A0 =A0uint64_t mmio_start =3D (1ull << 32) - params->mmio_size;
> + =A0 =A0uint64_t mmio_size =3D params->mmio_size;
> =A0 =A0 unsigned long entry_eip, cur_pages, cur_pfn;
> =A0 =A0 void *hvm_info_page;
> =A0 =A0 uint32_t *ident_pt;
> @@ -188,8 +191,8 @@ static int setup_guest(xc_interface *xch,
>
> =A0 =A0 for ( i =3D 0; i < nr_pages; i++ )
> =A0 =A0 =A0 =A0 page_array[i] =3D i;
> - =A0 =A0for ( i =3D HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i+=
+ )
> - =A0 =A0 =A0 =A0page_array[i] +=3D HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIF=
T;
> + =A0 =A0for ( i =3D mmio_start >> PAGE_SHIFT; i < nr_pages; i++ )
> + =A0 =A0 =A0 =A0page_array[i] +=3D mmio_size >> PAGE_SHIFT;
>
> =A0 =A0 /*
> =A0 =A0 =A0* Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC=
0000.
> @@ -230,7 +233,8 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 =A0 =A0 if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) =
=3D=3D 0 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check if there exists MMIO hole in the 1GB =
memory range */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0!check_mmio_hole(cur_pfn << PAGE_SHIFT,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SUPERPAGE_1G=
B_NR_PFNS << PAGE_SHIFT) )
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SUPERPAGE_1G=
B_NR_PFNS << PAGE_SHIFT,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mmio_start, =
mmio_size) )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 long done;
> =A0 =A0 =A0 =A0 =A0 =A0 unsigned long nr_extents =3D count >> SUPERPAGE_1=
GB_SHIFT;
> @@ -327,7 +331,7 @@ static int setup_guest(xc_interface *xch,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 HVM_INFO_PFN)) =3D=3D NULL )
> =A0 =A0 =A0 =A0 goto error_out;
> - =A0 =A0build_hvm_info(hvm_info_page, v_end);
> + =A0 =A0build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
> =A0 =A0 munmap(hvm_info_page, PAGE_SIZE);
>
> =A0 =A0 /* Allocate and clear special pages. */
> @@ -408,6 +412,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
> =A0 =A0 if ( params.mem_target =3D=3D 0 )
> =A0 =A0 =A0 =A0 params.mem_target =3D params.mem_size;
>
> + =A0 =A0if ( params.mmio_size =3D=3D 0 )
> + =A0 =A0 =A0 =A0params.mmio_size =3D HVM_BELOW_4G_MMIO_LENGTH;
> +
> =A0 =A0 /* An HVM guest must be initialised with at least 2MB memory. */
> =A0 =A0 if ( params.mem_size < (2ull << 20) || params.mem_target < (2ull =
<< 20) )
> =A0 =A0 =A0 =A0 return -1;
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 19b0382..b06788c 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -174,6 +174,7 @@ int xc_linux_build_mem(xc_interface *xch,
> =A0struct xc_hvm_params {
> =A0 =A0 uint64_t mem_size; =A0 =A0 =A0 =A0 =A0 /**< Memory size in bytes.=
 */
> =A0 =A0 uint64_t mem_target; =A0 =A0 =A0 =A0 /**< Memory target in bytes.=
 */
> + =A0 =A0uint64_t mmio_size; =A0 =A0 =A0 =A0 =A0/**< Size of the MMIO hol=
e in bytes. */
> =A0 =A0 const char *image_file_name; /**< File name of the image to load.=
 */
> =A0};
>
> --
> 1.7.2.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:43:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hwI-00085o-Dz; Wed, 29 Feb 2012 11:43:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2hwH-00085A-R0
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:43:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330515795!16990701!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28078 invoked from network); 29 Feb 2012 11:43:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:43:15 -0000
Received: by werm1 with SMTP id m1so3620320wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 03:43:15 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.165 as permitted sender) client-ip=10.180.92.165; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.165 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.165])
	by 10.180.92.165 with SMTP id cn5mr16719819wib.2.1330515795014
	(num_hops = 1); Wed, 29 Feb 2012 03:43:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=x/vpizO9C4Od9OWfh/YkoMX2wm9vZRRJn8KxgqteNRk=;
	b=gw36hJB7ufc4QeGOJ2PJ1MRb4/qS0Fq9OWVMG0AaFfQNmA9+yanmmNJTPkAPcJ3p4V
	PxS5nSTwrNuevsEmt6M480F674W7T1pDk2CspMVErflWME4A6iwE1LIN72xvqf0FZp1z
	YBgIBc8fQETeuu91ti82ig4KkOvR9qy56QMGk=
MIME-Version: 1.0
Received: by 10.180.92.165 with SMTP id cn5mr13324954wib.2.1330515794972; Wed,
	29 Feb 2012 03:43:14 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 03:43:14 -0800 (PST)
In-Reply-To: <1330513027.4270.43.camel@zakaz.uk.xensource.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
	<CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
	<1330513027.4270.43.camel@zakaz.uk.xensource.com>
Date: Wed, 29 Feb 2012 12:43:14 +0100
X-Google-Sender-Auth: 9Dg8HD2IP2D03pey-4RizscMiiA
Message-ID: <CAPLaKK7RbsoTinxf7f=BtL2PZ-4gUqDPC3kM9bka=bLBnmpAxQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/29 Ian Campbell <Ian.Campbell@citrix.com>:
> The code seems to use both ${exec_prefix} and ${prefix} is that correct?
> Seems like an odd place to set \$prefix is all.

$prefix is set by passing the command line option or by default when
calling AC_OUTPUT, but since AC_OUTPUT is called at the end, this is
not really helpful, so we have to set $exec_prefix manually to the
correct value, either $prefix if different than NONE or
$ac_default_prefix. I agree that the previous patch was a bit of a
mess with $prefix and $exec_prefix, this is more "correct"

8<--------------------------------------------

autoconf: fix libdir detection

If user specifies a libdir it is used, if no libdir is specified
configure checks if $exec_prefix/lib64 is a directory and uses that,
if not lib is used.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 4758a7a94c15 tools/configure
--- a/tools/configure	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/configure	Wed Feb 22 07:55:48 2012 +0100
@@ -3845,7 +3845,6 @@ case $host_os in *\ *) host_os=`echo "$h



-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -6551,13 +6550,26 @@ else
 fi

 # Check library path
-if test -d "$prefix/lib64"; then :
-
-    LIB_PATH="lib64"
-
-else
-
-    LIB_PATH="lib"
+if test "\${exec_prefix}/lib" = "$libdir"; then :
+  if test "$exec_prefix" = "NONE" && test "$prefix" != "NONE"; then :
+  exec_prefix=$prefix
+fi
+    if test "$exec_prefix" = "NONE"; then :
+  exec_prefix=$ac_default_prefix
+fi
+    if test -d "${exec_prefix}/lib64"; then :
+
+        LIB_PATH="lib64"
+
+else
+
+        LIB_PATH="lib"
+
+fi
+
+else
+
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"

 fi

diff -r 4758a7a94c15 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/m4/default_lib.m4	Wed Feb 22 07:55:48 2012 +0100
@@ -1,8 +1,14 @@
 AC_DEFUN([AX_DEFAULT_LIB],
-[AS_IF([test -d "$prefix/lib64"], [
-    LIB_PATH="lib64"
-],[
-    LIB_PATH="lib"
+[AS_IF([test "\${exec_prefix}/lib" = "$libdir"],
+    [AS_IF([test "$exec_prefix" = "NONE" && test "$prefix" != "NONE"],
+        [exec_prefix=$prefix])
+    AS_IF([test "$exec_prefix" = "NONE"], [exec_prefix=$ac_default_prefix])
+    AS_IF([test -d "${exec_prefix}/lib64"], [
+        LIB_PATH="lib64"
+    ],[
+        LIB_PATH="lib"
+    ])
+], [
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
 ])
 AC_SUBST(LIB_PATH)])
-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:43:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hwI-00085o-Dz; Wed, 29 Feb 2012 11:43:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2hwH-00085A-R0
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 11:43:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330515795!16990701!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28078 invoked from network); 29 Feb 2012 11:43:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 11:43:15 -0000
Received: by werm1 with SMTP id m1so3620320wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 03:43:15 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.165 as permitted sender) client-ip=10.180.92.165; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.165 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.165])
	by 10.180.92.165 with SMTP id cn5mr16719819wib.2.1330515795014
	(num_hops = 1); Wed, 29 Feb 2012 03:43:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=x/vpizO9C4Od9OWfh/YkoMX2wm9vZRRJn8KxgqteNRk=;
	b=gw36hJB7ufc4QeGOJ2PJ1MRb4/qS0Fq9OWVMG0AaFfQNmA9+yanmmNJTPkAPcJ3p4V
	PxS5nSTwrNuevsEmt6M480F674W7T1pDk2CspMVErflWME4A6iwE1LIN72xvqf0FZp1z
	YBgIBc8fQETeuu91ti82ig4KkOvR9qy56QMGk=
MIME-Version: 1.0
Received: by 10.180.92.165 with SMTP id cn5mr13324954wib.2.1330515794972; Wed,
	29 Feb 2012 03:43:14 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 03:43:14 -0800 (PST)
In-Reply-To: <1330513027.4270.43.camel@zakaz.uk.xensource.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
	<CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
	<1330513027.4270.43.camel@zakaz.uk.xensource.com>
Date: Wed, 29 Feb 2012 12:43:14 +0100
X-Google-Sender-Auth: 9Dg8HD2IP2D03pey-4RizscMiiA
Message-ID: <CAPLaKK7RbsoTinxf7f=BtL2PZ-4gUqDPC3kM9bka=bLBnmpAxQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

2012/2/29 Ian Campbell <Ian.Campbell@citrix.com>:
> The code seems to use both ${exec_prefix} and ${prefix} is that correct?
> Seems like an odd place to set \$prefix is all.

$prefix is set by passing the command line option or by default when
calling AC_OUTPUT, but since AC_OUTPUT is called at the end, this is
not really helpful, so we have to set $exec_prefix manually to the
correct value, either $prefix if different than NONE or
$ac_default_prefix. I agree that the previous patch was a bit of a
mess with $prefix and $exec_prefix, this is more "correct"

8<--------------------------------------------

autoconf: fix libdir detection

If user specifies a libdir it is used, if no libdir is specified
configure checks if $exec_prefix/lib64 is a directory and uses that,
if not lib is used.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 4758a7a94c15 tools/configure
--- a/tools/configure	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/configure	Wed Feb 22 07:55:48 2012 +0100
@@ -3845,7 +3845,6 @@ case $host_os in *\ *) host_os=`echo "$h



-
 # pkg.m4 - Macros to locate and utilise pkg-config.            -*- Autoconf -*-
 # serial 1 (pkg-config-0.24)
 #
@@ -6551,13 +6550,26 @@ else
 fi

 # Check library path
-if test -d "$prefix/lib64"; then :
-
-    LIB_PATH="lib64"
-
-else
-
-    LIB_PATH="lib"
+if test "\${exec_prefix}/lib" = "$libdir"; then :
+  if test "$exec_prefix" = "NONE" && test "$prefix" != "NONE"; then :
+  exec_prefix=$prefix
+fi
+    if test "$exec_prefix" = "NONE"; then :
+  exec_prefix=$ac_default_prefix
+fi
+    if test -d "${exec_prefix}/lib64"; then :
+
+        LIB_PATH="lib64"
+
+else
+
+        LIB_PATH="lib"
+
+fi
+
+else
+
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"

 fi

diff -r 4758a7a94c15 tools/m4/default_lib.m4
--- a/tools/m4/default_lib.m4	Wed Feb 22 04:46:07 2012 +0100
+++ b/tools/m4/default_lib.m4	Wed Feb 22 07:55:48 2012 +0100
@@ -1,8 +1,14 @@
 AC_DEFUN([AX_DEFAULT_LIB],
-[AS_IF([test -d "$prefix/lib64"], [
-    LIB_PATH="lib64"
-],[
-    LIB_PATH="lib"
+[AS_IF([test "\${exec_prefix}/lib" = "$libdir"],
+    [AS_IF([test "$exec_prefix" = "NONE" && test "$prefix" != "NONE"],
+        [exec_prefix=$prefix])
+    AS_IF([test "$exec_prefix" = "NONE"], [exec_prefix=$ac_default_prefix])
+    AS_IF([test -d "${exec_prefix}/lib64"], [
+        LIB_PATH="lib64"
+    ],[
+        LIB_PATH="lib"
+    ])
+], [
+    LIB_PATH="${libdir:`expr length "$exec_prefix" + 1`}"
 ])
 AC_SUBST(LIB_PATH)])
-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:45:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hxi-0008EV-TX; Wed, 29 Feb 2012 11:44:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2hxh-0008EG-Fn
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 11:44:49 +0000
Received: from [85.158.139.83:63327] by server-7.bemta-5.messagelabs.com id
	06/99-16195-0BF0E4F4; Wed, 29 Feb 2012 11:44:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330515888!17220714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21859 invoked from network); 29 Feb 2012 11:44:48 -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;
	29 Feb 2012 11:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11006946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 11: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.213.0; Wed, 29 Feb 2012 11:44:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2hxf-000333-Lu; Wed, 29 Feb 2012 11:44:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2hxf-0003AI-GP;
	Wed, 29 Feb 2012 11:44:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.4013.955941.793577@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 11:44:45 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330513251.4270.47.camel@zakaz.uk.xensource.com>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to hypervisor build"):
> Perhaps we should just move the configure stuff up to the top level and
> agree that it can control both tools and hypervisor configuration
> options? I'm not sure why we would want to use different mechanisms for
> the tools and h/v anyway.

I assume that the concern was that some people might object to the
involvement of autoconf in building the hypervisor.  But no-one seems
to be objecting very much.

If they do then the right thing is for configure to automatically
honour settings like FLASK_ENABLE, not to have two separate options
which cause the build to fail unless you set or clear both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 11:45:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 11:45:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2hxi-0008EV-TX; Wed, 29 Feb 2012 11:44:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2hxh-0008EG-Fn
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 11:44:49 +0000
Received: from [85.158.139.83:63327] by server-7.bemta-5.messagelabs.com id
	06/99-16195-0BF0E4F4; Wed, 29 Feb 2012 11:44:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330515888!17220714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21859 invoked from network); 29 Feb 2012 11:44:48 -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;
	29 Feb 2012 11:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11006946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 11: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.213.0; Wed, 29 Feb 2012 11:44:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2hxf-000333-Lu; Wed, 29 Feb 2012 11:44:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2hxf-0003AI-GP;
	Wed, 29 Feb 2012 11:44:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.4013.955941.793577@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 11:44:45 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330513251.4270.47.camel@zakaz.uk.xensource.com>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to hypervisor build"):
> Perhaps we should just move the configure stuff up to the top level and
> agree that it can control both tools and hypervisor configuration
> options? I'm not sure why we would want to use different mechanisms for
> the tools and h/v anyway.

I assume that the concern was that some people might object to the
involvement of autoconf in building the hypervisor.  But no-one seems
to be objecting very much.

If they do then the right thing is for configure to automatically
honour settings like FLASK_ENABLE, not to have two separate options
which cause the build to fail unless you set or clear both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iL9-0000ZH-De; Wed, 29 Feb 2012 12:09:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1S2iL7-0000Z8-DQ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:09:02 +0000
Received: from [85.158.139.83:14360] by server-3.bemta-5.messagelabs.com id
	87/EC-25237-C551E4F4; Wed, 29 Feb 2012 12:09:00 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330517338!17212866!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_90_100,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21480 invoked from network); 29 Feb 2012 12:08:59 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 12:08:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=5SMWku3gNDhASYqzlQ6Jr8Qe/Ztv5
	BX0E1lNEw4SSAM=; b=Sx+EGxk9VqRYQgsjY9yT4d+PbvFliOA7gB/9V8e0pVhD8
	uq9YZab968734pTAuy4ynx653Ryp2Df0ZqWN3zDhiV5qK4dEvFWJdV673kCE/yIJ
	eHqoDTKtIPufTA4AIT4sN5VNN1HcC4eWyVKLqzir+5qlH7X4VdQmvw+mOhdaE0=
Received: (qmail 12045 invoked from network); 29 Feb 2012 13:08:56 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.158.253)
	by mail.zeus06.de with ESMTPA; 29 Feb 2012 13:08:56 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id CB5772C5FD;
	Wed, 29 Feb 2012 13:10:37 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Mscc3GvE3gDR; Wed, 29 Feb 2012 13:10:29 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 7ED652C5FC;
	Wed, 29 Feb 2012 13:10:29 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Wed, 29 Feb 2012 13:10:29 +0100
Mime-Version: 1.0
In-Reply-To: <zarafa.4f4ce616.5763.747aa36d2ca6afc9@uhura.space.zz>
References: <zarafa.4f4ce616.5763.747aa36d2ca6afc9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f4e15b5.3926.5c7b11b715fbc27d@uhura.space.zz>
Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?utf-8?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3070970385178588289=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============3070970385178588289==
Content-Type: multipart/alternative; 
 boundary="=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Great news: it works and load is back to normal. In the attached graph yo=
u can see the peak=0D=0A=0D=0Ain blue (compilation of the patched 3.2.8 K=
ernel) and then after 16.00 the going life of the=20=0D=0A=0D=0Avideo Dom=
U. We are below an avaerage of 7% usage (figures are in Permille).=0D=0A=0D=
=0A=0D=0AThanks so much. Is that already "the final patch"=3F=20=0D=0A=0D=
=0A=C2=A0=0D=0ABR, Carsten.=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0A----=
-Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Konrad Rzeszutek Wilk <konrad.=
wilk@oracle.com>;=20=0D=0ACC:Sander Eikelenboom <linux@eikelenboom.it>; x=
en-devel <xen-devel@lists.xensource.com>; Jan Beulich <jbeulich@suse.com>=
; Konrad Rzeszutek Wilk <konrad@darnok.org>;=20=0D=0AVon:Carsten Schiers =
<carsten@schiers.de>=0D=0AGesendet:Di 28.02.2012 15:39=0D=0ABetreff:Re: [=
Xen-devel] Load increase after memory upgrade (part2)=0D=0AAnlage:inline.=
txt=0D=0A=20=0D=0A=0D=0AWell let me check for a longer period of time, an=
d especially, whether the DomU is still=0D=0A=0D=0Aworking (can do that o=
nly from at home), but load looks pretty well after applying the=0D=0A=0D=
=0Apatch to 3.2.8 :-D.=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=
=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Jan Beulich <J=
Beulich@suse.com>;=20=0D=0ACC:Konrad Rzeszutek Wilk <konrad@darnok.org>; =
xen-devel <xen-devel@lists.xensource.com>; Carsten Schiers <carsten@schie=
rs.de>; Sander Eikelenboom <linux@eikelenboom.it>;=20=0D=0AVon:Konrad Rze=
szutek Wilk <konrad.wilk@oracle.com>=0D=0AGesendet:Fr 17.02.2012 16:18=0D=
=0ABetreff:Re: [Xen-devel] Load increase after memory upgrade (part2)=0D=0A=
On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> O=
n 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote=
:=0D=0A> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct =
vm_struct *area, gfp_t gfp_mask,=0D=0A> > struct page **pages;=0D=0A> > u=
nsigned int nr_pages, array_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_m=
ask & GFP_RECLAIM_MASK) | __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D=
 gfp_mask & (__GFP_DMA | __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=
=0A> >+if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I =
didn't spot where you force this normally invalid combination, without=0D=
=0A> which the change won't affect vmalloc32() in a 32-bit kernel.=0D=0A>=
=20=0D=0A> >+gfp_mask &=3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gf=
p_mask &=3D ~(__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0AD=
uh!=0D=0AGood eyes. Thanks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=
=0A> > nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > arra=
y_size =3D (nr_pages * sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=
=0D=0A_______________________________________________=0D=0AXen-devel mail=
ing list=0D=0AXen-devel@lists.xensource.com=0D=0Ahttp://lists.xensource.c=
om/xen-devel=0D=0A=20
--=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>Great news: it works and load is back to normal. In the attached graph =
you can see the peak</p><p>in blue (compilation of the patched 3.2.8 Kern=
el) and then after 16.00 the going life of the </p><p>video DomU. We are =
below an avaerage of 7% usage (figures are in Permille).</p><p><br />Than=
ks so much. Is that already &quot;the final patch&quot;=3F </p><p>&nbsp;<=
/p><p>BR, Carsten.</p><p>&nbsp;</p><p><br />&nbsp;<img alt=3D"" src=3D"da=
ta:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAfEAAAGECAIAAACpv45YAAAgAElEQ=
VR4nO2dfXQUVZ73b0gCISAJwSBgtknEkJA3zAYVfUaPj2cdHceDOIFlZgB3dpxhRkQj6Koc52=
CvsDoKAzjBLDmoZINBMN2BBFlfEEkE9xAJ6KBEjLw4KEh3Oq/3nz3n+SPPHxeuRd2q6pvurur=
qqu/n9OnTXX3r3vu7devbv9yu+oZ8BgAAwBG0traSePcBAABADGhtbX3jjTcuaToFAACQyLzx=
xhvQdAAAcAjQdAAAcA7QdAAAcA7QdAAASCQaBZSfQtMBkIIQEu8uDINY9TaxonYVg4ODTM2h6=
cCBmCc9vGbxRUyqNQlourPp7+8/cuSIz+c7f/58U1OT8iNouqtZuHDhb3/7W+WWf/3Xf120aF=
E0dRJCCCFJSUlXXXVVWVnZ8uXLz549G103Y4ymToWV7CjVzWJxhKY7mM7OzpaWlra2tq6urqa=
mpiNHjig/haa7mkAgUFRU9MYbb7C3r7/+enFxcTAYjKZOrgKBQODQoUMPP/zw5MmTT5w4EW1f=
Ywc03fp6QAz56KOPzp8/r/cpNN3tHD169Jprrjl27NixY8cmTZrEpkF/f/+KFSuuvvrq0aNHV=
1ZW/vDDD6wwIWTjxo0ejyc1NbWsrOyTTz4RKxRV4Omnn/7lL3/JXnd3d//Lv/zLVVddddVVV/=
3mN7/p7u7me23YsGHq1KkjR46cMWPGBx98sHnz5mnTprGGDh8+zIp98cUXP/vZz8aMGTNq1Ki=
77rrrzJkzqkYj6yHfSBSINYsvxPKaPTSo1mBAwgZiACFk9erV2dnZ6enpixYtCoVClNJbb711=
69atvExnZ+ekSZNU6hAKhRYuXJienj5x4sQ1a9YYxyVTIbAYaDqgr732WnFxcXFxcV1dHdvyp=
z/96c477zx58uQPP/ywcOHC3/3ud2w7IaSysvLrr78OBALPPvtsRUWFWJuomJ2dnddccw17/d=
hjj919991nzpw5ffr0P/3TP1VVVfG95syZ89VXXwUCgeeee27s2LEPPPAAf3vjjTeyYoWFhe+=
8804wGDx//vzSpUsXLFigajSyHlL9PF1mPb26uvqee+6R7KHqrcGAhA3EAEIIq/bMmTN33333=
448/TindtWtXQUHBwMAAK/Pggw8+//zzqh2rqqp4f+666y7eT824ZCoEMQfXvYDwlJeXz5o1i=
7/1eDzHjh1jr0+fPj1x4kT2mhBy7tw59joQCKSkpIhViZLX29ubmprKXk+ePPnzzz9nrz/77L=
MpU6bwvf7+97/zmlVvNRsKBAJXX321qtHIekij0PSWlpaZM2fyP2XC9lD11mBAwgZiACHkb3/=
7G3v9+eefX3vttex1RUXF66+/zjcGAgHVjlOmTOE7fvbZZ5pjpYwrbIXAJHDdC9Bl8+bNN9xw=
ww033PDaa6+xLSkpKcrlgqSkJLZdT5iMN7I/ydnr5OTk/v5+9rqvr49LlXHN/O2HH354yy23p=
Ken63VMpocjRozgfWD09/ePGDHCuAbNJo4cOTJt2jTlrwVhe6h6G9mA8I3K9RzVR5rV7tixIz=
8/v7+/f/78+WvXrhV3VPUn7MiHrRCYAa57AbocOXJk8uTJX3zxxfHjxydPnnz06FFKaU5Oztd=
ffy0WjkzTn3766V/96lfs9eTJk5Vp4OTJk2Vq5m+nTJlSV1d3/vz5wcHBCxcuhE2iNXvo8Xj+=
53/+R7nl0KFDHo/HuAbxxZkzZ/Lz8/ft26csH7aHqreRDUhYlHn63/72N57+Dw4OFhcXV1VVe=
Tyenp4ecUdlnv7555+HHfmwFYKYg+tegC6BQGDGjBlvvfUWe/vmm2+y616ee+65u++++/jx43=
19fYcPH66srGQFhqXp7LqXpUuXKq97WbZsGV/nveuuux599FGZmvnb8ePH79ixIxQKffHFF5W=
VlZFp+r//+7+Xl5d/9NFHoVAoFArt379/5syZa9asYZ9mZGTwdSfNmvmLG2+8cfPmzarK9Xqo=
V21kAxIWQsjPfvazs2fPnj179p577uHL9JTSuro6Qsirr76quWNVVRXbkS3Ehx35sBWCmIPrX=
oAuCxcu5CLCePjhhxcuXDgwMOD1etlFF0VFRfy3U/kFgaSkpDFjxpSWlj7++OP86hRKaTAYXL=
x48dixY8eOHbt48WJ+3aSkpr/11lu5ubnJycn/8A//sHbt2sg0fXBwcO3atcXFxaNGjRo1alR=
xcfFf/vIX/umqVavGjBljULPyhRLjHupVG9mAhIUorntZuHAhv5yGUrpt27Zp06b19fVp7tjd=
3f3rX/969OjR2dnZyute9OIKWyGwGGg6AO7i3nvv5Xck2LNCYAyuewEAUErpwMBAdXV1YWEhv=
/rQbhUCGVQiDk0HwKUQQjweT2trq20rBDI0NTX19vay1729vbjuBQAAEpjW1tZPP/20r6+vr6=
/v008/bWtrU34KTQcAgESiu7v7wIEDfr/f7/e3trYqfwCn0HQAAEhosJ4OAADOAZoOAAAJjIu=
uZTy+d+/xvXvj3QsAALAOx2p6Xyi0/pZb1t9yS18oFO++AACARThW0z946SWvx+P1eD546aV4=
9wUAAOKDQzT9/MmTa/Lzmaavyc8/f/JkvHsEAACmEAwGW1tb+bWMqn826RBNr1+8mAk6e9QvX=
hzvHgEAgCns27fv2LFjvb29vb29R48eVbk9O0TTGU899ZRMsa6uLuuLyZfs7eiIS7uI15p2Ea=
817do83mjw+XzcYGdgYMDn8yk/daOmHzx40Ppi8iUvbNoUl3YRrzXtIl5r2rV5vNHgijy9t7f=
3xIkTv/3tb4eGhk6fPm38/L//+79hywwNDZ08eTKGtcmX7Dp2LC7tIl7Ei3gti3doaOjrr78+=
ceKE/B8KnEAg4Pz1dMZTTz01JMGpU6esLyZfkra1xaVdxGtNu4jXmnZtHu+lwibgRk0HAAA7E=
JnQueK6Fwby9GhKIl5r2kW81rRr83gvFY4IO66n19fXFxYWpqamlpaWtrS08O0rV67k/+fw66=
+/nj179siRI2fPns3+h724RQXydABAAhGZftrxupcHHnigvb29u7t706ZNEyZMYBvb2tomTZr=
ENX3evHkrVqzo7u5esWLF/PnzNbeoQJ4eTUnEa027iNeadm0e76XCEWHHPJ1z4sQJj8dDKe3u=
7i4uLt67dy/X9AkTJpw+fZpSevr0aab74hYVyNMBAAlEZLJp3+teTp06VV5evnPnTkrp0qVLX=
3zxRUop1/QRI0awvy/6+/uTk5M1t3D6//73C6+88uTvf08PHBgaGjJ+Pr1zZ9gy9MCBU6dOxb=
A2+ZK0rS0u7SJexIt4LYuXHjjw/0KhC6+80tPeHltdjZumt7a2ejyeLVu2sLdJSUlEAaU0Kyt=
LlZWLW1QgTwcAJBCRiacd/dOrq6uzs7N3794tfsTz9MrKSr56XllZqblFBdbToymJeK1pF/Fa=
067N471UOCJUIq4iPppOruTixYvKj9iLr7766qabbkpNTb355ptPnjypuUUF8nQAQAIRmX7aU=
dNNAnl6NCURrzXtIl5r2rV5vJcKRwQ0HQAA7IgZMuhGTXfG97zb8hrEG2VJxGtNu/B7iQ3D8m=
XEM57xjOe4P0fmy/jOO++0t7efPn26v79fs4BDNJ2BPD2akojXmnYRrzXt2jzeS4WHz4ULF44=
fP75///6mpqb9+/cfP378woULygJu1HQAALAD0chdX1/f6dOn29vb33nnHeV2N2q6M77n3ZbX=
IN4oSyJea9p16Xq66MsoboEvIwDA2ZihrnbxZRS3wJfR4nYRrzXtIl5r2rV5vJcKm4BdfBnFL=
fBlBAA4m5ioqC38XhinFL6M4hb4MsLHDvEiXqfGS2Pny2gXTVf5Mopb4MsIAHA2kYlnYvgyil=
vgy2hxu4jXmnYRrzXt2jzeS4VjgS00XfRlFLfAlxEA4GxiIqe20HSTQJ4eTUnEa027iNeadm0=
e76XCJuBGTQcAADsQmdAFg0Gb/j/SmIM8PZqSiNeadhGvNe3aPN5LhSNi3759x44d6+3t7e3t=
PXr06L59+5SfOkTT4cuIZzzjObGeI/NlpJT6fD52VTeldGBgwOfzKT91iKYznJenkw2EbCDWt=
GuHeK1sF/Fa0y7iNSocEa7I0xnOW0830HQAQKITmdAFAgGsp19BAn3PdwyRjiHk6aa0i3itaR=
fxGhU2Abv4Msq4MLrEl1GZm9eS2lpSG9/+AABMIjL9tON9pJG5MDrPl5FrN9Nx9pizMofLegW=
prdDRdLflNYg3ypKI15p2LcjTmYhzKbeFpnOG5cLoPF9GlaYPEUI2EK/X2zFEWHpuoOkAgEQn=
Mtn0+/0//PCDz+e7cOHChQsXdu3apfzULr6MMi6MzvNlrH/sMfba6/W25KyqJbUtOauac55ry=
VlVQWrpgQMVpHZ5zqqYt5uIPnaIF/E6KV4ahS/jp59+2tTU1NnZ+c477/j9/i+//FL5qV18GW=
VcGJ3ny8jXymtJbYXwGBoaIkv2kCV74tpHAIBZmCGtdvFllHFhdJ4vY4WWplflPCej6W5bf0S=
8UZZEvNa0a816uu1+I43MhdF5voxc0y+JuJfwF0zKkacD4GDMUFdcn25RMc2SSk1n8k2W7Jnz=
4EYu5cjTzWsX8VrTLuI1KmwCbtR0+8D1mgu68jGEPB0AR2OGDLpR0+3zPa+p6cjTrWkX8VrTL=
uI1KmwCDtH0BPVlJEv2sNfFK3aQJXtUz3x73PuJZzzjOebPEfsywj9djX2+55GnDyGPs6pdxG=
tNu/BljCVYTwcAJBCRCR3809XY53seefoQ8jir2kW81rTr0jydX5nOtzQ0NOTl5SUnJ+fm5jY=
0NFB3+DIiTwfAzUSmn/b1T1dq+rhx4/x+fygU8vl8GRkZ1CW+jMjTkcdZ1S7itaZdV1/3otT0=
kpISv9/f09Pj8/nKysqoS3wZkacD4GIiU047egMwlJp+4MCBcePGEULGjRt34MAB6g5fxrmL1=
7PXZMmeuYvXs+c5D25kr/n2mLebiD52iBfxOileGoUvo33905WaPm3aNL72cv3111N3+DIiTw=
fAzUSmnImh6ZmZmXztZfz48dQdvoxkyZ5L/94I6+mWt4t4rWkX8RoVjgg7arrKl5FSWl9f7/F=
4kpOTp06d+uabb1J3+DJqajrydABcQkzk1BaabhKJmKez/yKNPN36dhGvNe0iXqPCsQCabiPI=
kj3MMB15OgAuJDKhs+91LzEnEfN0UdORp1vTLuK1pl3Ea1Q4FjhT0xPXl/H+4poKUgtfRjzj2=
W3PEfsyqnCmpjMSMU8XH8jTrWkX8VrTLuI1KmwCbtR0m6B3uQvW0wFwCZEJHdbT1djke15P05=
GnW9Mu4rWmXcRrVNgE7OLLODAwsHLlysmTJyclJbHtjvdl7BgKk6dz0Y93TwEAphCZfto3T1d=
q+qpVq6ZPn97e3j44OMi2ON6XsVbnEkaep/MCsW3XmmLyJZHHWdMu4rWmXWvy9J6envfee6+p=
qens2bOqj+yi6R6PR/XfOhzvy6h3WTp/VBhqOgAg0YlMOZmgHzt27Lvvvtu9e/f58+eVn9pF0=
5OTkx955JHRo0d7PJ4dO3ZQF/gyVpBa7sVItHwZl+esIvBlRLyI14nx0ih8Gd99910u199880=
1LS4vyU7to+oQJE3w+H/NlvPrqq6kLfBmRpwPgciJTTpVWf/nll8q3YTR93759+fn5SUlJlNI=
FCxbU1dVF1glNlJo+f/58n8/HfBmzs7OpC3wZ9aScr6cba7rb1h8Rb5QlEa817Vrjyxj5b6TX=
X3/9rl27mPh+9dVXU6dOjawTKkRfxq6urp/85Cepqal5eXlsYd3xvoxhLnq58kJ1AIDziEw/o=
/LaTU1NDYVCTHbPnTuXnp4eWSeswWF5urGmuy2vQbxRlkS81rRrd//0O+64Y/PmzYSQrq6uBQ=
sWzJkzJ7JOWAPydABAAhGZ0EWl6V1dXffdd196enp6evqcOXO+/fbbyDphDcjToylp87wG8UZ=
ZEvFa065L7yONOYnoy6jpxaj5bIfe4hnPeI7tc8S+jPa9jzTmIE+PpqTN8xrEG2VJxGtNu5bl=
6YODg6pFGIa2phN9oumE2WA9HQCQQESsdf39/UeOHPH5fOfPn29qalJ+hDzdomJiSeTpDORx1=
rSLeK1p14I8vbOzs6Wlpa2traurq6mp6ciRI8pP7eLLyFi5ciXf6HhfRuTpALicyPTzo48+Un=
m8KInn2ouqtra2tkmTJvGNjvdlRJ7OQB5nTbuI15p2XX3di1LTu7u7i4uL9+7dyzc63pcReTo=
ALscMXbWLpi9duvTFF19UbnS8LyMRHBnJlb6M/Dm27cYrXr1n+PYhXhfGS6PwZTRGV9OZtlq2=
9sL+vZGyFcf7MiJPB8DlxFBOOXbJ08WN8GXEerqp7SJea9pFvEaFTSDO172IuT9/C19G5OkAO=
Bsz1DWMpm/fvt3j8SgXRszoRKxAnh5NSZvnNYg3ypKI15p27Z6nT5gwYdu2bf39/Wa0HXOQpw=
MAEggzZDCMpmdmZgYCATMaNgPk6dGUtHleg3ijLIl4rWnX7nn6s88+u3Llyu7ubjPajiHwZcQ=
znvGcWM8R+zIaE0bTGxoaRo0a5TAPL5t8zyNPZyCPs6ZdxGtNu3bP07OzsxsaGrCebgZYTwfA=
5Zghg2E0fdy4cVhPj0kxsSTydAbyOGvaRbzWtGv3PN2k9XRxJae+vr6wsDA1NbW0tLSlpYXCl=
xF5OgBOJ7a6ygij6ZZ5AzzwwAPt7e3d3d2bNm1i9/3DlxF5uqntIl5r2kW8RoVNwHbeACdOnP=
B4PBS+jMrHBhLvzgIAYo8ZuhpG05OSksxolSFq+qlTp8rLy3fu3Enhy6jcvoHAxw7xIl4nxUu=
t92VkTJky5ezZs7FtkqPS9NbWVo/Hs2XLFvYWvoz84fV6491ZAEDsMUNXw2j6iy+++NBDD128=
eNGMtpWaXl1dnZ2dvXv3br4Fvoz8UUtqY9iuNcXkS2K91Zp2Ea817dp9Pd2k30jFOlVbLl68C=
F9GY00HACQ6MZFTFfH8jTTmODVPr0CejnijLol4rWnX7nl6YuHUPF1T0wEAiY4ZMhhG0/ft25=
efn8+uflmwYEFdXZ0ZnYgVyNOj6aHN8xrEG2VJxGtNu3bP06+//vpdu3axJe+vvvpq6tSpZnQ=
iehzuy/h+cdx7i2c84zm2z/HxZUxNTQ2FQkzTz507l56eHtvmY4tT8/Qhr8Y9R27La6yMV3mT=
lxviNbVdxGtU2ATCaPodd9yxefNmQkhXV9eCBQvmzJljRidihVPX0wksX6wFN+4CazBDBsNoe=
ldX13333Zeenp6enj5nzpxvv/3WjE7ECqfm6Zqa7ra8Bnl6lCVxfK1p1+55ukmIV7vLuDC61p=
cRebrFIE8H1mCGutrFw0vGhdG1vozI081oF3m6Ne0iXqPCJqCr6R9++GFhYWFKSkphYeFHH31=
kRttKTZdxYXSvLyPydGtBng6swQxd1dX0oqKil19+ORAIvPzyyyUlJWa0rdR0GRdG9/oyLtkD=
Hzsr4537dI6r4nXb8bVDvNR6X8bk5OSenh5KaSgUUglorFBquowLo2t9GZGnWwzZQJCqAwswQ=
1d1NV0puLH990aa1cq4MLrWlxHr6Wa0a7yezjXdDfGa2i7iNSpsAkaarklMWhXrlHFhdK0vI/=
J0i0GeDqwhJnKqwo0eXjb5nkeezrBhHoc8PYYlEa9RYRNwo6bbBOTptgV5OrAGM2TQjZpuk+9=
55OkMG+ZxyNNjWBLxGhU2AYdourN9GYtX7Ih7b131TDaQ4g3wwsSzuc/x8WVMLJCnR9NDm+c1=
yNOjLInja027yNNjCdbTQUzAejqwBjNk0I2abpPveeTpDBvmccjTY1gS8RoVNgG7aHpDQ0NeX=
l5ycnJubm5DQwOFLyPy9PiBPB1YgxlaahdNHzdunN/vD4VCPp8vIyODwpcRebrJ7SJPt6ZdxG=
tU2ATsouklJSV+v7+np8fn85WVlVH4MiJPjx/I04E1mKGldtH0AwcOjBs3jhAybty4AwcOUPg=
ywpcxfvHOfTqHbCDuiddtx9cO8VLrfRktZtq0aXzt5frrr6fwZUSeHj+QpwNrMENL7aLpmZmZ=
fO1l/PjxFL6MWE83uV2sp1vTLuI1KmwCdtH0+vp6j8eTnJw8derUN998k8KXEXl6/ECeDqzBD=
C21i6bHBOTp0fTQ5nkN8vQoS+L4WtMu8vRYgjwdxATk6cAazJBBN2q6Tb7nkaczbJjHIU+PYU=
nEa1TYBByi6fBlxHMMn+HLiGcLnuHLGB7k6dH00OZ5DfL0KEvi+FrTLvL0WIL1dBATsJ4OzEC=
cVGbIoBs13Sbf88jTGTbM45Cnx7Ak4uW4S9MHBgZWrlw5efLkpKQkQgiFLyPy9PiBPB2Ygbs0=
fdWqVdOnT29vbx8cHGRb4MtokzxdNRHdkMchT49hScTLcZemezwen8+n3AJfRpvk6cPNWB2Q5=
DogBGBD3KXpycnJjzzyyOjRoz0ez44dOyh8GVXbn86JVbvDjZc7FErWRjYQ1tvE9e2DLyPiNS=
Ne1VnscF/GCRMm+Hw+5st49dVXU/gyqh5xTBsJ8nQAYoC78vT58+f7fD7my5idnU3hy3jlw+v=
1xqrd4RarJbXDq40Q9jWQuOutWE+PYUnEy3GXpnd1df3kJz9JTU3Ny8tjC+vwZVQ+VMJqJcNt=
upbUxrG3MQF5OjADd2l6THBwnl4hqKRt83Su6YmbxyFPj2FJxMuBpg8bB+fpoqZbBvJ0AGICN=
H3YIE+PpodiMTYFkafHtl0bxmtqu4iXA00fBo73ZawgtXHo4YZisoHUFNcMa6+a4praePQ2tl=
HDlxHPMX8mG4hyC3wZw4M8PZoeisW8Xi/ZQNyWp7MkHXl6rEoiXg7y9GGTQOvpZAMZ3vXp8bi=
VtJbUdgypNV1mr4ReT1dpOgCxApo+bBIoTzfQdM08XdR0C/Iaps7Gebo4TZGnG2O3eM1uF/Fy=
3KjpK1euZKaM1Om+jLWkNiHy9LBJt4GmJyjI04FJuE7T29raJk2axDXd2b6MBppuhzydiZpMn=
i7KN/J0Y+wWr9ntIl6OuzS9u7u7uLh47969XNOd6svI9KLC3nm6gaarMND0BCXh8vQE6qrLcZ=
emL1269MUXX6SUck13qi/j3KdzvF7v8pxVZFi+jIvXR9nusOJl3oq1pLYlZ1UtqTWoTfUp29K=
Ss0q+Xbv59rHYE8iXcdnTs6OJ1+xxttvxjWO87vJlZP/eiEOd68vo9XprSa3N83Sv18v6iTzd=
/iT0aLsKd+XpHJ6nO9WXkUmegabbYT2dq/mlrirmItbTo2w35vHWlNTEsEL7x4v1dGPsq+lO9=
WW8JHleW1+fbqDpYknNfU3uoIkgTwcm4VJNj4ZEydONF17My9ONpco4T9fLW5GnD7dd5OnWtG=
vDeKHpwyYh8vSKiBbTo8/TyQbCVsnDZqD8ipeKyw+D1NUZeboyOh5soqTqtYZ/SAE7wA4QNH3=
YJESeHlbTTcrTuVLr/S86XkzU9FpSy78PVJex62m6qqQBMnmcfG1DOiMjarR4Pb7yNd9i/7y1=
pqSmYyi8ptswbzW1XVvFC00fNgnky1hBau8vriHSjow/PkfnFOj1eu8vrqkgtcY+i8UbiocIY=
SXZc/H7xbWklrktrlmzRlWnWNulvTYUD132OIzewS56l0RVT5TOi8x7kntJcl9Gsecx71VMnm=
vDHVO7Pcd33OLSOps58GUcNhHk6ZLry5K1yZSMOE8X00zNJQJVvslLKvNug+7xSy1/XHjpIMq=
EXVx2H7pyGPlyDWuX/SdVg3E2yGuUDUWTT2kMFCHvnyq5tIUQ5XqRQZ6u/Mg48TcIx4w8XWax=
K+55q3JmWtCuwe8lesWMl7CQp8eBCNbTI1g2lSyvVyyyxXSyZM8QuaKroriIiqN8hNV0xhXFO=
ohK01XXwNTy2oha09nyC1+H0RtnZecNQlBVohoH46OgXE3SfKu6DF/V6JXVaWi6zBQydb3bgh=
8wYtJ/A003dXzk2zKvG9D0CNHUdHE0Wf7IP9XLvPj6snGxkg0lxvmyqt2w2q2XpysliWwgJRt=
KhghhOeYVHRN0p2RDSe2V0qwXL9lAVBk6eyg38niH+DU8V8of13TW7qWPiMbosddzVuaox5ao=
A2G1sXg1KxHHWXnUvF6vMnDWK7YMrdR01V6svPL4Kofa6/WqglKOjArlejdtaxOnil4UMvJnQ=
Z6uuV4vn7eSy38P8dpUUXi9XtXfnQbyKh+IagA1a1YWM9Z0pW6oUPbc4PiKB9oMGbSLptfX1x=
cWFqamppaWlra0tNBIfRnF4YvyIUqkZhmZYpdq6xj2lelsl4rL0sM8zVW/YfKPKkhtxxDhZXh=
5PU1XPrj2GWi6Mt4Khab/uMbiJUPeH1uvUCqmYpVDbJ11m4UwRIgyLjFeycOnGivWgQqdB6uW=
KQ6Ljm3hvw+LqT3vtnE3VB3mosaHXXXCKweEXPlNoypDrvybQ09ENCvRK8DjVfVfT8v0ZOuKa=
a8YBDGrEA+ockhVait56DW6JHeSRv9QNaQ3XR2u6Q888EB7e3t3d/emTZvYff+R+TLWCic8kx=
v+1uv1vn+qhF3+wQ/Aj1pDLuVfQ4Sw9EepIFxrOoZ+TNPWrFnDFYHtyB6sGKuQFT5VUvKjUA4=
rT7+s6crH/SU1etqkWZK1O+QlQx2K1QZFRsy6p1LzS3spZL3mcrtMfJXKe2mQL38N8JL8U66n=
bEDYM83JMdBZvXiV3ytK5WUL5WHlW28A2YHjh7uC1J4qKRG/nzQfbF6pjrtybrAtc1bmKKcfD=
4HvyDbyw8G/Dll0rBift0OEsECU+7JiFfxfmhDi9Xr5n02sJCvDesgFlI1e7ZWTmbtEqCRJ/D=
tMeR7xHh5vyxEHtvbyaPMvS95u7eVjp/weVZ7Ca9asqVVMAHWZcOkAACAASURBVPZp7eWrs/g=
4swFkJVW5gnJffnx5Z7gxBg+fn7+qAVTGy7fTnBzeBG9XVHb2V4sZWmoXTeecOHHC4/HQSH0Z=
JWUujo+wmq6dp1+ZLEferkRVQ1cKuvGOyi+bS2d4LHob52Ok0HQ88Ij+oVyl5BtdoemnTp0qL=
y/fuXMnjdSXcXnOqgpSa/z8/Ow/hS2zPGfV/SU1MayNl5z7Rg7pIHPfyCHyvowdZO4bOTFrt4=
MYxDt0uYzes6pdsTbeW8keVuU8Z8Y4R3N85z6d0zFETGrXhvGa2i7iVc4r5RaH+zJSSltbWz0=
ez5YtW9jbyHwZK+L9hRz28WPaO8w8fcgbVeYomafrZeh6+2puSfQ8XWYtCA88hvvga2KX3jo7=
T6+urs7Ozt69ezffEpkvo8zISq5Ex7ZYxZXr2gaarr2eLgjl/SU1vIByu+bK+1C4JRSN7uk8l=
PHqqTzbyNoN+1VUlfOcGeOsPp2u/FVApkI2klG2a028QxJfoibN5wji1extzNu1T7x6D4drOr=
mSixcvRujLKJy6osZpbmRXa4gblSUvXa8t7CsKq0G7V0ik8q1Oem7GY+jyQyNeiTydx6vUdD5=
6ylZ4Ad6W5lipesLeiofj0nX63vDHV2PfK79+rhjzyy9U1+OTyz9N87mhmgyaE0a1UW9eifHq=
zUn14IQLzbhdZW267WrODS0hFkvqzSvlwLK3eqMnDqDM8dWN1ysRr8Qx0jvomvuqmhi68hT4c=
buzNT0mPPXUUzKKVvJ+ifXF5EvOeXCjWu4taTf6YkwydEvqRHQpXsvH2aCYUitjf3zrcowHhG=
2/ojb+xRNNvCt2GBW4/PWm0a6qDC95ucJLqYDe8eXxGjStGYVm68pAYjIscrM0kuMrVFuhNNn=
ucM11L9Egqel44GH8qJBYg8IDj+E+VPMKmh4eh+TpYfMac9pFvIgX8VoWL4GmG8N9GUkHKX6/=
GM94xjOebf4MX8bwIE9HvIgX8SZEvAR5ugxYT8cDDzwS5QFNDw/ydMSLeBFvQsRLoOlU0pdRb=
jTxwAMPPOL74Jpe/+CD33/1Vax0MpE0XcaXUWYonfE977a8BvEiXifFSxSa7vV41kyf/sFLL/=
V1d0evk4mk6TK+jJKjiQceeOAR34dS09ljw//5P397550odTKRNF3Tl/Ho0aNPPPHEimXLHrv=
vvv97662PL1z4xBNPGD//7v77w5Z5fOHC3/zmNzGsTb5k1S9+EZd2ES/iRbyWxfv4woVMtZb/=
9rc/avqtt/5tz54odTKRNF3Gl1Gmni+//NL6YvIlu99/Py7tIl5r2kW81rRr83iVsLWX9//8Z=
9etvcj4MsrU09PTY30x+ZIXNm2KS7uI15p2Ea817do8XiX1ixd/39k53L30SCRNl/FltL5XMa=
f/7Nl4d8FSEK+zQbwWk0iaHpb2WP/HEAAASCwcpemJAiEk3l0A5oJD7GzsfHyh6SbC/r/HqFG=
jpk+f/txzz/X39xsUU86S+vr6wsLC1NTU0tLSlpYWZWHxxquwt2IBkyCE/Nd//Rd/+x//8R96=
p/qwjhoOsU2QP762OoWh6SbCjnFvb+/HH3984403/tu//VvYwowHHnigvb29u7t706ZNqit8x=
Buvwt6KBUyCEDJ79uzBwUFKaW9vb2lpqd45P6yjhkNsE+SPLy/PX8fxFIamm4jyGHd0dFx77b=
Xids3CnBMnTng8HuWn4o1XYW/FAiZBCPnjH/+4Y8cOSunmzZufeOIJfphUR1PmqOEQ2w3542u=
w0fpTGJpuIspj3Nvbm5KSIm7XLMw4depUeXn5zp07lRvFG680b8UCFkAIOX78eEVFxeDgYGlp=
6cmTJ/XO+WEdNRximyB/fPU2xuUUhqabiPIYHz16NCcnR9yuWZhS2tra6vF4tmzZoiom3ngV9=
lYsYBLskN13332///3vf/GLX1DFQVQdzWEdNRximyB/fDU3xusUhqabCF9PP3To0OzZs/l6et=
gJUV1dnZ2dvXv3brGYeONV2FuxgEmwQ/b+++8TQvbt20f1z/lhHTUcYpsgf3zFjXE8haHpJsJ=
+Ch85ciS77qWvr49vF4spfzpXbbl48SLfRbzxKuytWMAkxBNb75yXOWo4xHZD/vja6hSGpgMA=
gHOApgMAgHOApgMAgHOApgMAgHOApgMAgHOApgMAgHOApgMAgHOApgO3Y2zMBEBiAU1PYHp6e=
pYtW3b11VePHTv2+eefj3d37A4h5IUXXqCGpqmA097eTgjB/5mRwVZTC5qewCxfvvy+++775p=
tvvv/++0cffTTe3bE7hJCCgoLBwcHp06fH/cSzP2vWrBkxYsSaNWvi3ZEEwFZTC5qewEyZMkX=
1v8yV80l5H/Py5cvT09PLysrEYu6BEHLLLbesWrXq1ltvVQ6OatBefvnl8ePHZ2Zmbrr8z4Ld=
OVx33HHHgw8+eMcdd7C3ZWVl7H87NDc3z5w5k1La1tZWUFCQlpa2YsUKYyMUxyNOLTavUlJS+=
P/E+P3vf//rX/+aUvqrX/1qyZIlfMeYdwaansAkJyer/neSnqa/8MILgUDgoYcesrR/NoMQ8s=
Ybb4wYMWLr1q2aA8Ver1+/PhgMNjU1udkBMRAIjBkz5ptvvhkzZkwgEKCUrl27lv8Dh3Xr1lF=
KS0pKNm7cGAgENm3a5E4p5+hNrf7+/n379k2aNIlS2tfXd+edd/7hD3+48847ufWTGUDTExiD=
PL2vr0+p6b29vVZ3zn4Y6LjytZ7VmqtobGzk/lONjY2U0nPnzmVkZHz55ZcZGRnfffcdpTQlJ=
SUYDFJKg8Ggm8eKak2n9evXezyeESNGEEKSkpLYR21tbYSQtrY2UzsDTU9gqqqq7rvvvlOnTp=
0/f76qqopSOmHChN27d3d3d2/YsMHlfw6LSGq65mu3sWTJEvar+/PPP88XCiorK2+44YZ58+a=
xt8XFxX/961+DweB//ud/unmsqNa0SUtLa2pqCgaDPp+PbQkGg6WlpXfffXdpaWl3d7d5nYGm=
JzChUOjhhx+eMGECv+6luro6IyNj/Pjx69atM9B0d56B4omnaZEqlnfhcOXl5R0+fJhSevjw4=
by8PLaxubmZENLc3Mzetra25ufnp6WlPf744yNGjGAbXThWVGvaPPvssxkZGRkZGatXr2ZbFi=
1atGDBAkrpP//zPy9evFjcMVZA0wEAkTMwMPDWW29Nnz493h0Bl4CmAwAihC0W5+Xl/fd//3e=
8+wIuAU0HAADnAE0HAADnkBia7s4fXgAAYLgMT9OJDpolk5KSrrnmmj/84Q/sIlYr6ezsvOmm=
m0aOHHnTTTd99dVXFrduGeL4NzQ0zJgxY+TIkeXl5e+99x7bkpeXl5ycnJeXt337ds16GhoaP=
B5PamrqjTfeePz4cUrpli1brrvuutTU1JkzZ+7du9eacMxGHC5xSygUeuSRR7Kzs/UmNtUaZO=
NzIRHRC8fr9fKN4rSRqUc5VllZWSb132LEKSFKkIwoieedzIRUMXxN7xAeOpo+ODh48uTJ+fP=
n//GPf5TpSgyZO3fuihUruru7V6xYUVlZaXHrFqMc/8rKyo6OjlAotH379okTJ1JKMzIydu3a=
FQqF/H5/RkaGZg1ZWVktLS09PT0+n+/nP/85pXTu3LmHDx/u7u7esmWLw26nNL6ys6qqqqysr=
KOjY3BwUK8GcZAdI+UqVHF98sknTFzYW3HaSNbDWLJkyZNPPhnD3sYRcUqIEiQjSuJ5JzMhVZ=
io6ezFyZMn2a2xH374YWFhYUpKSmFh4YcffsjK/OM//uO8efNyc3PZjQzsu0hpksA3KmsWHTl=
UZGVlnT59mlJ6+vRph0mSiDj+wWCwvr6eXV5WWlra3Nzc09Oze/duZtMhkpWVtWfPHnZyjh8/=
XvnRyZMnU1NTnXQbqrGmT548+d1335WpRznIhJCMjIz09PSf/vSnJ06ciGFv44vqL5iioqLXX=
ntNqel608agHsb333+fmZnZ1dUV8z7HEeWUECVoWKLEzzv5CckxXdP7+/tTUlIopQUFBa+++m=
owGKyuri4sLGRluJ/nmDFj+L5KkwRVbVTOkWPEiBEDAwO33HJLf39/cnKyzEAkLqrx53/VHjx=
4kFLa2tqamZlJCMnMzNS7Kbmuru7aa68dPXr0448/rhyub7/9tqKiwmGOj8aanpycvGLFivT0=
9JycnG3bthlUohxkxtmzZ6uqqm666aaY9zleKEfmscce+8UvfqHcqDdtjOthrF69mt2A4xhUU=
0KUIHlRUp53khNSiXV5enJyMltYDwQCTOWJ4s49om+SQAVND+vIkZWVdebMGerWPD0QCGzdur=
WoqIhSmp+f7/f7Q6GQz+crKCgwrmrv3r1Tpkxhrw8ePJibm7tixYqBgQEzuh0vjDU9MzPT5/P=
19PS0tLQYr/YqB5nT3d2dmpoaw97GF+XIsLNSc51dOW3C1kMp7evry8nJMdv2xHqUU0KUIElR=
Up138hOSY+56+tdff/3LX/6S+UVo5umqZ9EkgdcW9rWS+++//8knnwyFQk8++SRLLhyMchAWL=
VrU2dkZCoXq6+vZn8Pjxo3z+/09PT27du3SW0+nlA4ODh49erSkpIT5xtTU1FRUVLAlModhrO=
n33nsvP4X0TjxxkBk//PDDqlWrKioqYt/pOGGcrlFh2kjWU1dXN3v27Fh10g6IU0KUIBlREs8=
7mQmpwkRNT0pKmjhx4u9+9zvm1blv376CgoLk5OSCggK+nq56Fk0SyJVQOU0/ceLErFmz2C/y=
nZ2dMgORiIiDU1tbm5ubm5KSUlRU5Pf7KaV1dXXsT5+pU6fW19fzHcV6srOzly5dGgqFxJovX=
rxoeXCxR3MuqbYcP3581qxZKSkpHo+noaGB76isRxxktvuoUaNuv/32zz//3PLIYo84MsqPlG=
WU04bqTC1VPbNmzZJcRkgUxCkhSpCmKBkP18WLFzUnpDFmXcsIAADAehLjniMD8AUDAACchNd=
0AAAAHGg6AAA4B+s0XWZVBCsnAAAQDdb9RhpDTYf0yyBzdPQ8KJS2Hm5AxotDLCPjpZPQiGYj=
MkZAYhmH/dYlhiPOBL2BMj6zYuK8NHxNX7JH/YCm2xjjsdL0oFDZergBSS8OVRkZL52ERjQbk=
TEC0ivjsBmlDEecCZqDEPbMionzklmafujQoZkzZyYnJxPF1awqn5ajR4/efPPNqamp06ZN4/=
52lNKzZ8/edtttmzdvpjouMarvSbGeWbNmsf+a6Ly7G4aL8YkkelCIth5uQMaLQywj46WT0Bi=
YjcgYAanKOGxGKcMxmAl8EGTOrJg4L5ml6SUlJevWreN3IlAtn5by8vLXX389FArt2rVr2rRp=
rExHR0dZWRk38BLvPqXC5BDr2bp1KzMFKy8v37lzZ9i4HIzxiSR6UIi2Hm5AxotDLCPjpZPQ6=
JmNyBgBiWUcNqOU4ejNBOUgyJxZMXFeMkvTU1JS2O2jyn1VPi0pKSk842buLoSQ0tLS7Ozs9v=
Z2VlJ0iaHCoIj19PX1XXfdddu2bSsoKJD3qHQkYfN0lQeFga2Hg5Hx4hDLDMtLJxHRNBuRMQL=
SLOOw6aQMR3MmqAZhWGdWNM5LZml6cXHxunXrenp6lPuqXldUVDQ2NnZ3dyu3nzlzZseOHbm5=
uezvXM08feTIkUpHU7EeSunzzz+fnp6uZ8brHoxnj4EHhcPOQGNkvDjEMpJeOomLaDYiYwSkV=
8ZhM0oZjjgTDAbKeByid14yS9M//vjj0tJS9tUkRsJeHzt27Pbbb09LS+NfXLxMTU3NrFmzgs=
Gg6BJDKV22bBnbi70V66GU/v3vf8/KyrL+XyzZB3IlfKOyjIExjsPOQGNkvDjEMppeOk5CNBt=
RTSpmBKQaKLGM5lRMXMRwxJmgOVB8d83XfK8onZec6fcyMDDwl7/8ZdmyZfHuCAAAWIoz7yMl=
hJSVlbHVGwAAcA/O1HQAAHAn0HQAAHAO8HsBAADnkJB+L0AeGb8I0clExv/EkchMaQwXQ2asR=
AMTcYurCOv3ovKNiWC4hq3pQ171A5puZyQNOlROJjL+Jw7GeB5iuJQYj5VoYCJucQ9h/V5E35=
gIhsssTTfP74U7BzQ3NzvSZMMkDPwiRCcTGf8TBxNWpzBcnLBjpTIwMbA0cTYyfi+ib0wEw2W=
Wppvn97J27dr58+dTSufNm7du3TqZIIGxX4ToZCLjf+JgjHUKw6XEeKxEAxM9SxPHI+P3IvrG=
RDBcZmm6eX4v586dy8jI+PLLLzMyMr777juZIF1OWL8I0clExv/EwYTNPTFcHMn1UqWBid4WZ=
yPj92LgICQ/XGZpuql+L5WVlTfccANzXgTGyPhFiE4mMv4nDsZYpzBcSsJqusrARHOLqzAYMU=
0HoeEOl1mabqrfS3NzMyGEOaQDY1RXKGkadIhOJgY+MM5G84IuDJcmMmPFPhINTJRb3IaohBw=
935hhDZcz/V4AAMCd4D5SAABwDtB0AABwDtB0AABwDmZpOhbZAQDAesz6jRSabhPg9zIsZH72=
x3AxZKZWQ0PDjBkzRo4cWV5ezu4VD4VCjzzyCLtF3sEqIU4kpWDyf+6qidITJoKpNfxrGTvUD=
2i6nYHfSwQYz14MF0NmalVWVnZ0dIRCoe3bt0+cOJFSWlVVVVZW1tHR4YZ//q45kZYsWfLkk0=
/q7aLyhIlgapmr6UrnFtHdZe3atR6Ph3nC4DvAbOD3Io/xbMRwqTCYWoxgMFhfXz99+nRK6eT=
Jk999910LexdPxIn0/fffZ2ZmdnV1aZYXPWEimFomarrKuUV0dxkzZozX6+3o6FDebgrMAH4v=
w8JY0zFcSoynFr285pCVlXXw4EFKaXJy8ooVK9LT03NycrZt22ZhT+OAOJFWr169YMECvfKiJ=
0wEU8tETVc5t4juLm+//fY999wzbdq0sWPHPvPMMzLdBREAv5fhEjZPx3Axwk4tRiAQ2Lp1a1=
FREaU0MzPT5/P19PS0tLQYLys7ANVE6uvry8nJYeZcmoieMBFMLRM1XeXcIrq7MAYGBvbu3Zu=
eni7TXTBc4PcSAcaajuFiyEytRYsWdXZ2hkKh+vp6ZhV77733ck13/PcfEW79nz179rB2jGBq=
mf4bKXdu0XR3IYQwc4ONGzfKdBcMF9UVSvB7MUY1XHyjsgyGiyEztWpra3Nzc1NSUoqKivx+P=
6X0+PHjs2bNSklJ8Xg8DQ0N8em6+WhOpFmzZqmWm/SyB749gqkFvxcAAHAOuI8UAACcAzQdAA=
CcAzQdAACcg9Warlx8x0I8AADElnj+RgpNjzmimUZDQ0NeXl5ycnJeXt727ds192poaPB4POy=
39ePHj2vW4xJkPEzEwXGD34sYtVIB9K40F6efzIR0AOI5JTNJYmIlNGxNryC1qgc03T6IZhoZ=
GRm7du0KhUJ+v5//h0MVWVlZLS0tPT09Pp/v5z//uWY9LkHGw0QcHDf4vRhMCQMDE3H6yUxIB=
yCeUzKTJCZWQiZqOiFk+fLl6enpZWVlfIu49mLsCaNZD9BDNNMoLS1tbm7u6enZvXv3zJkzNf=
fKysras2cPm3/sxhBXmXJoYuBhIg6OG/xe9KaEsYGJOP1kJqQDEM8pmUkSEyshczX9hRdeCAQ=
CDz30kHKj8nVYTxi9eoAmoplGa2trZmYmISQzM1PvpuS6urprr7129OjRjz/+OPOUcJUph4ix=
h4k4OG7we9GbEsYGJuL0k5mQDkA8p2QmSUyshMzVdDHNUWl6WE8YvXqAJqKZRn5+vt/vD4VCP=
p+voKDAePe9e/dOmTJFsx73ENbDRBwcN/i9aE6JsAYm4vQb1oR0APyckpkkMbESMlfTjTcSOU=
8YLLvLI5ppjBs3zu/39/T07Nq1y2D5cnBw8OjRoyUlJVVVVZr1uAQZDxNxcNzg96I5JcIamIj=
TT3JCOgDVOSUzSWJiJWSdpouXyvACBp4wYj3AANFMo66uzuPxMFOd+vp6Vkzz0GRnZy9dujQU=
CmnW4xJUs1TTw0QcHDf4vWhOibAGJuL005yQzkM8pzQniWq4YmIlBL8XAABwDriPFAAAnAM0H=
QAAnAM0HQAAnIN1mj6sy2P4R8br9VjKBwAAJdb9Rhqx/kLTo0HGuQV+LxyZWa1nweH1eh08Vu=
KwNDQ0zJgxY+TIkeXl5fyubxXiWDnS70W0CRInkuSZqBqcCK5DGbam15Ja1QOabmdknFvg98K=
RmVGaFhyffPIJO13N7V+8UQZYWVnZ0dERCoW2b98+ceJEzfLiWDnS70W0CRJngsw5pTc4ttD0=
tWvXejye5ORk/iVDCHn55ZfHjx+fmZm5adMmXqFydz2/F2XNra2tBQUFaWlpVVVV7COxLcCRc=
W6B3wuHEJKRkZGenv7Tn/70xIkTmmVEC45QKFRUVPTaa685fvqJAQaDwfr6+unTp2uWF8fK2X=
4v3CZInEgy55Te4NhC08eMGeP1ejs6Onp6evi+69evDwaDTU1NylsTlbvr+b0oa54xY0ZNTU0=
wGHzllVfYR2JbgCPj3AK/FxVnz56tqqq66aabND8VLTgee+wxdo+f2zSdZVFZWVkHDx7ULC+O=
lYP9XkSbIOVEkjmn9AbHFpr+9ttv33PPPdOmTRs7duwzzzzD9u3r6xO7qHyt5/eirDklJSUYD=
FJKA4EA+0hsC3CG5dwCvxdOd3d3amqq5keiBceIESOG+/NSgiJGFwgEtm7dWlRUpFleHCun+r=
3o2QTxiSRzTukNji00nTEwMLB379709HSqr+PK15p+L5MmTVJmAUVFRSxPr66uVu6rbAtwJJ1=
b4Pei5Icffli1alVFRYXmpwYWHM4WdHplgIsWLers7AyFQvX19WzJTkQcK0f6vejZBCknksw5=
pTc4ttB0lrAwV4eNGzdSLR0nV0Ip1fR7+etf/5qens7f7t+/Pz8/Py0tbfny5cp6lG0BjqZNh=
+Zf0PB7oZeHYtSoUbfffvvnn3/ONyrLGFhwOFjTxbO1trY2Nzc3JSWlqKjI7/fzYsq9xLFypN=
+LanAuXrwoTiSZM1EcHHHYwwK/FwAAcA64jxQAAJwDNB0AAJwDNB0AAJyD3TUdi/UAACCP3X8=
jhaZHiehEISKacuhZmjgemSmN4WLIjJVoJeRIvxd5jE2BxMERBzAsw9b0jiH1A5puZ0QnCs0y=
KlMOTUsT92A86zBcSozHSrQScqTfiyRhTYHEwREHMCxmabqm30tVVVVaWtr06dNbW1sppR9++=
GFhYWFKSkphYSG7XP/QoUMzZ85ke/EWKaVnz5697bbbNm/eLBMS0IQ7UYgfiaYc4hZXEVanMF=
ycsGOlshJytt+LATKmQOLgiAMYFrM0XdPvpbq6OhgM1tTUFBcXU0oLCgpeffVVdkdoYWEhpbS=
kpGTdunXstpcfW+zoKCsra2lpkYkHaCI6USgRTTnELa7CWKcwXEqMx0q0EnKw34sxMqZA4uCI=
AxgWszRd0++F+bQEg0FmgJCcnMydW1JSUiilKSkpgUBA1WJpaWl2dnZ7e7tMPEBEz4mCI5pyi=
FtcRdjcE8PFkVwd5VZCTvV7CYuMKZDB4PABDIu56+kqvxeWldfU1MyYMYNq5enFxcXr1q1T2i=
sSQs6cObNjx47c3Fz25y0YFnpOFEpEUw4DSxM3YKxTGC4lYTVdZSXkSL+XYWEwYpqDoxrAsJi=
l6ey7SOX3wtbT8/Pz9+/fTyndt29fQUFBcnJyQUEBE52PP/64tLSUfaGp4q+pqZk1axbL64E8=
qiuULl68SCVMOQwsTZyN5gVdGC5NZMaKfaS0EnKk38uwUA6Rarj0/F6UAxiWBPjfdQAAACSJ/=
/+YBgAAECvsfh8pAAAAeaDpAADgHOyo6VilAQCAyDDxN1JIsx1oaGiYMWPGyJEjy8vL33vvPc=
0yMDDhwB5HHpmx0rMrMbY9cTBh/V5UwyUzyCqGrelDwgOabmcqKys7OjpCodD27dsnTpyoWQY=
GJhzY48gjM1aadiVhbU+cStjAxeGSGWQVZmm6ZhZPCFm+fHl6enpZWRnV8nvhO8p0HcgTDAbr=
6+unT5+u+SkMTERgjyOP8Vip7EpkbE8ciUzgBu4uBoOswtI8nRDywgsvBAKBhx56iGrdR6q3I=
4gG9jWZlZV18OBBzQIwMFEBexx5jMdKtCuRsT1xJDKB67m7GA+yCqs1Xfk9I/q96O0IoiQQCG=
zdurWoqEjzUxiYKIE9jjxhx4rD7UpkbE8cybACV7q7yA8yw0RNHzly5IkTJ1S7K98iT7eARYs=
WdXZ2hkKh+vp6Pa9OGJhwYI8jj8xYUX27Etee5saBq4ZLcpCVmKjpy5YtS0tLU62nKwuIfi8R=
WA4AY2pra3Nzc1NSUoqKivx+P9uoGlsYmHBUMxD2OAbIjBX7SNOuxLUnuIEkisOlOcjG2P1/1=
wEAAJDHjvccAQAAiAxoOgAAOAdoOgAAOAe7azoW6wEAQB67+71A06NE5ndsGJhwMFzyyIxVQ0=
NDXl5ecnJyXl7e9u3bJfdyAGKYksOl8nuJYLiGreleAWi6/TEeRhiYqMBwyWM8VhkZGbt27Qq=
FQn6/X/nfR11yXothGgeuaY8Tdi8VZmm6mMUT4arMsrKylpYWSmlzc/PMmTOplgMMK3n27Nnb=
brtt8+bN8oEBJWFnEgxMlGC45DEeq9LS0ubm5p6ent27d7NzXGYvxxCBpmv6vdhC08V+iJq+d=
u3a+fPnU0rnzZu3bt06qnVnKSGko6ODqz+IDOM5AQMTFRgueYzHqrW1NTMzkxCSmZnZ1tYmuZ=
djGK6m6/m92F3T+/r62Otz585lZGR8+eWXGRkZ3333HdVygCGElJaWZmdnt7e3y0cFVITNDmB=
gogTDJY/xWOXn5/v9/lAo5PP5CgoKJPdyDMPVdI7S70V+L4aJmq7ye5kwYcLu3bu7u7s3bNjA=
d6msrLzhhhvmzZvH3mrm6WfOnNmxY0dubi77/MwFpgAACHZJREFU8xZEgPGcgIGJCgyXPMZjN=
W7cOL/f39PTs2vXLqyna25RoWmPYxdNV/m9VFdXZ2RkjB8/ft26dXxjc3MzIaS5uZm91XSAYR=
/V1NTMmjWLZfFAHnIlfKOyDAxMOBgueWTGqq6uzuPxjBgxYurUqfX19Xp7OQ8xTJnhYh8Z+L3=
INA2/FwAAcA52v+cIAACAPNB0AABwDtB0AABwDtZpOpbdAQDAbKz7jRSabgF6R8Tg8iTqYlMO=
EeWszsrK0iyj5+5iPMiJzpYtW6677rrU1NSZM2fu3buXUtrQ0DBjxoyRI0eWl5e/9957mnuJE=
0msxwGIZ5Do3CITeGSDrGL4mr5BeEDTbYZqqD/55JPs7GyD8Xe5KYcmS5YsefLJJzU/0nR3CT=
vIic7cuXMPHz7c3d29ZcsWdl9VZWVlR0dHKBTavn37xIkTDfZVDotYjwMQzyDRuUUm8GgGmWO=
Wpis38sszX3755fHjx2dmZm7atEmzDHuxfPny9PT0srIyevl7PiUlpbS0FPYAkigHNhQKFRUV=
vfbaawZy43JTDpHvv/8+MzOzq6tL81PR3UVmkB3DyZMnU1NTe3t72dtgMFhfXz99+nSDXTSHR=
VVPQiOeQXrOLVQu8AgGmWOppq9fvz4YDDY1NbEzQU/TX3jhhUAg8NBDD/FP+/v79+3bN2nSJJ=
mQgHJgH3vsMXZno4HcuNyUQ2T16tULFizQ+1R0d5EZZGfw7bffVlRUPProo+wtX6Q6ePCgwV7=
isKjqSXTEM0jPuUUm8MgGmWO6pnN3F0JIX1+f8lOxDNuo/AZbv349uw+NEJKUlCQTElAeETZ0=
xuvjLjflUNHX15eTk6P8blMhurvIDLIDOHjwYG5u7ooVKwYGBvjGQCCwdevWoqIigx1VY6JZT=
0KjdwbRK51bZAKPeJA5Zmm66O4iZuWaDjCq2tLS0pqamoLBoM/nc/DZElvC/uWkwuWmHCrq6u=
pmz55tUMDA3cXBI1ZTU1NRUcEcOxiLFi3q7OwMhUL19fWq5QUVymER63EAmmeQyrlFJvBoBpl=
jlqaL7i6ipms6wKhqe/bZZzMyMjIyMlavXu3gEyZWkCtRfaT5mrrYlEOTWbNmbdu2TblFNQIG=
7i4OHivVlLh48WJtbW1ubm5KSkpRUZHf7+fFDPbSrCcOwcQavTPIwLmFBW48XHqDbAz8XgAAw=
DngPlIAAHAO0HQAAHAO0HQAAHAO0HQAbI3dfq+Kpj92i8WRQNMB0CBi9Ym5bBlUGH1b/J5YSu=
mpU6f0LG5kGpW5bkKmw5qeJyrvFIPW+RYZpxTRukfPzMe4LZmrRcS4xLbEeiKwx4GmA6CBSzT=
95ptvfu+99yZPnjxlypR3333X+MJ840ZlOiNTRvQ8Eb1TZOqXcUoRrXs0zXwkYzGOToxLry1l=
PRHY40DTAdBA84wlV1oPrV271uPxJCcn89xK5gJfVX7HnquqqtLS0qZPn97a2kopbW1tLSgoS=
EtLq6qqUtasbF1s6+jRozfffHNqauq0adN4ZmosNIsWLVq9evXUqVM9Hs+aNWsWL16sWY/YH5=
kRE+shhCxfvnz06NE8UgO454mBd0rYPqicUlQFROsecYtmtZobJb9ilXGJbenVI2+PA00HQAO=
981NpPTRmzBiv19vR0dHT0xN2R80CXK+rq6uDwWBNTU1xcTGldMaMGTU1NcFg8JVXXlGWVxkf=
qdoqLy9//fXXQ6HQrl27pk2bJhPm6tWrb7zxxnnz5lVWVt54441r1qzRrEevP6q4VF8zYj3KS=
I3vdFd6nuh5p2j2QeySgVOKaN0jbpFsS3OLcVx6bYn1DMseB5oOgAbieSVaD7399tv33HPPtG=
nTxo4d+8wzz+jtqFez0gopGAxSSoPBYGpqKqU0JSWFbQkEAqyMpvGRqq2UlBQuqZLmSDt27Eh=
KSnrppZf+/Oc/JyUl7dy5U7MesT8yIybWI0aqiZ4vitI7RbIPxk4ponWPuEW+rbCHXhWXXluq=
eoZrjwNNB0AD8fzUsx4aGBjYu3dveno6ezty5MgTJ04Y1KxphfTqq6+y7HXGjBmU0qKiIpYXV=
1dXszKaravaqqioaGxs7O7ulg/z2LFjhJADBw589NFHhBAmAmI9Yn9ExO1iPcpI2V8kIpq+KC=
rvFD2UfZBxShGtewzMfMLGa6zpYlx6bSnricAeB5oOgAbiSoJoPcQ+Yi4fGzduZDsuW7YsLS3=
N4PTWtEJi6+n5+fn79++nlO7fvz8/Pz8tLW358uV6rYttHTt27Pbbb2db+EZjoent7R0zZkxP=
T08oFBozZgxzThXrEfujOWKqLWI9ykj11tNVI3/x4kX2QumdEnYvSqmMHY1o3aNp5qPaS2xL3=
CITl9hW2Jpl7HGg6QDEGWPZBWBYQNMBiDPQdBBDoOkAAOAcoOkAAOAcoOkAAOAcoOkAAOAcoO=
kgMWhsbGxqaurv729qampsbJTcxfhTvQKBQMDn82mWN9gLADsATQeJQWNj4/vvv//ZZ5998ME=
HsVJVvXoOHTokfgQpBwkBNB0kBo2NjceOHfP7/ceOHePyqnrR2NjY3t7u9/uPHj2qt1FVp9jQ=
Dz/80NzcrKnpfr9/z549p06dimlkAMQSaDpIDBobG8+dO8ef+Ubli8bGxu+++y4QCLD7BjU3q=
uoUG/r444+PHz+u+dHg4OCpU6d2794du7AAiDHQdJAYNDY2Dg4OvvPOO4ODg1xw/X5/IBDgKi=
9KvLhRVadmQ3rr5oODg2fOnIGmAzsDTQeJgVJh+eujR4/6/f729vYINF0l3OKn4ovGxsY9e/Z=
88803sQwMgJgCTQcAAOcATQcAAOcATQcAAOcATQcAAOcATQcAAOcATQcAAOfwo6a3tra+AQAA=
IPEhEHQAAHAM/x/Obh51kwBDGgAAAABJRU5ErkJggg=3D=3D" /></p><blockquote style=
=3D"border-left: 2px solid #325FBA; padding-left: 5px;margin-left:5px;">-=
----Urspr&uuml;ngliche Nachricht-----<br /><strong>An:</strong>=09Konrad =
Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;; <br /><strong>CC:</strong>=
=09Sander Eikelenboom &lt;linux@eikelenboom.it&gt;; xen-devel &lt;xen-dev=
el@lists.xensource.com&gt;; Jan Beulich &lt;jbeulich@suse.com&gt;; Konrad=
 Rzeszutek Wilk &lt;konrad@darnok.org&gt;; <br /><strong>Von:</strong>=09=
Carsten Schiers &lt;carsten@schiers.de&gt;<br /><strong>Gesendet:</strong=
>=09Di 28.02.2012 15:39<br /><strong>Betreff:</strong>=09Re: [Xen-devel] =
Load increase after memory upgrade (part2)<br /><strong>Anlage:</strong>=09=
inline.txt<br /><style type=3D"text/css">body { font-family: monospace; }=
</style>               <style type=3D"text/css">       .bodyclass       {=
         font-family: Arial, Verdana, Sans-Serif ! important;         fon=
t-size: 12px;         padding: 5px 5px 5px 5px;         margin: 0px;     =
    border-style: none;         background-color: #ffffff;       }       =
 p, ul, li       {         margin-top: 0px;         margin-bottom: 0px;  =
     }   </style>  <div><p>Well let me check for a longer period of time,=
 and especially, whether the DomU is still</p><p>working (can do that onl=
y from at home), but load looks pretty well after applying the</p><p>patc=
h to 3.2.8 :-D.</p><p>&nbsp;</p><p>BR,</p><p>Carsten.<br />&nbsp;</p><blo=
ckquote style=3D"border-left: 2px solid #325FBA; padding-left: 5px;margin=
-left:5px;">-----Urspr&uuml;ngliche Nachricht-----<br /><strong>An:</stro=
ng>=09Jan Beulich &lt;JBeulich@suse.com&gt;; <br /><strong>CC:</strong>=09=
Konrad Rzeszutek Wilk &lt;konrad@darnok.org&gt;; xen-devel &lt;xen-devel@=
lists.xensource.com&gt;; Carsten Schiers &lt;carsten@schiers.de&gt;; Sand=
er Eikelenboom &lt;linux@eikelenboom.it&gt;; <br /><strong>Von:</strong>=09=
Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;<br /><strong>Gesende=
t:</strong>=09Fr 17.02.2012 16:18<br /><strong>Betreff:</strong>=09Re: [X=
en-devel] Load increase after memory upgrade (part2)<br />On Thu, Feb 16,=
 2012 at 08:56:53AM +0000, Jan Beulich wrote:<br />&gt; &gt;&gt;&gt; On 1=
5.02.12 at 20:28, Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt; wr=
ote:<br />&gt; &gt;@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_nod=
e(struct vm_struct *area, gfp_t gfp_mask,<br />&gt; &gt; =09struct page *=
*pages;<br />&gt; &gt; =09unsigned int nr_pages, array_size, i;<br />&gt;=
 &gt; =09gfp_t nested_gfp =3D (gfp_mask &amp; GFP_RECLAIM_MASK) | __GFP_Z=
ERO;<br />&gt; &gt;-<br />&gt; &gt;+=09gfp_t dma_mask =3D gfp_mask &amp; =
(__GFP_DMA | __GFP_DMA32);<br />&gt; &gt;+=09if (xen_pv_domain()) {<br />=
&gt; &gt;+=09=09if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))<br />&gt; =
<br />&gt; I didn&#39;t spot where you force this normally invalid combin=
ation, without<br />&gt; which the change won&#39;t affect vmalloc32() in=
 a 32-bit kernel.<br />&gt; <br />&gt; &gt;+=09=09=09gfp_mask &amp;=3D (_=
_GFP_DMA | __GFP_DMA32);<br />&gt; <br />&gt; =09=09=09gfp_mask &amp;=3D =
~(__GFP_DMA | __GFP_DMA32);<br />&gt; <br />&gt; Jan<br /><br />Duh!<br /=
>Good eyes. Thanks for catching that.<br /><br />&gt; <br />&gt; &gt;+=09=
}<br />&gt; &gt; =09nr_pages =3D (area-&gt;size - PAGE_SIZE) &gt;&gt; PAG=
E_SHIFT;<br />&gt; &gt; =09array_size =3D (nr_pages * sizeof(struct page =
*));<br />&gt; &gt; <br />&gt; <br /><br />______________________________=
_________________<br />Xen-devel mailing list<br />Xen-devel@lists.xensou=
rce.com<br />http://lists.xensource.com/xen-devel<br /></blockquote></div=
>   </blockquote>=0A</body>=0A</html>
--=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj--



--===============3070970385178588289==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3070970385178588289==--



From xen-devel-bounces@lists.xen.org Wed Feb 29 12:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iL9-0000ZH-De; Wed, 29 Feb 2012 12:09:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1S2iL7-0000Z8-DQ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:09:02 +0000
Received: from [85.158.139.83:14360] by server-3.bemta-5.messagelabs.com id
	87/EC-25237-C551E4F4; Wed, 29 Feb 2012 12:09:00 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1330517338!17212866!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_90_100,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21480 invoked from network); 29 Feb 2012 12:08:59 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 12:08:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=5SMWku3gNDhASYqzlQ6Jr8Qe/Ztv5
	BX0E1lNEw4SSAM=; b=Sx+EGxk9VqRYQgsjY9yT4d+PbvFliOA7gB/9V8e0pVhD8
	uq9YZab968734pTAuy4ynx653Ryp2Df0ZqWN3zDhiV5qK4dEvFWJdV673kCE/yIJ
	eHqoDTKtIPufTA4AIT4sN5VNN1HcC4eWyVKLqzir+5qlH7X4VdQmvw+mOhdaE0=
Received: (qmail 12045 invoked from network); 29 Feb 2012 13:08:56 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.158.253)
	by mail.zeus06.de with ESMTPA; 29 Feb 2012 13:08:56 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id CB5772C5FD;
	Wed, 29 Feb 2012 13:10:37 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Mscc3GvE3gDR; Wed, 29 Feb 2012 13:10:29 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 7ED652C5FC;
	Wed, 29 Feb 2012 13:10:29 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Wed, 29 Feb 2012 13:10:29 +0100
Mime-Version: 1.0
In-Reply-To: <zarafa.4f4ce616.5763.747aa36d2ca6afc9@uhura.space.zz>
References: <zarafa.4f4ce616.5763.747aa36d2ca6afc9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f4e15b5.3926.5c7b11b715fbc27d@uhura.space.zz>
Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?utf-8?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3070970385178588289=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============3070970385178588289==
Content-Type: multipart/alternative; 
 boundary="=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Great news: it works and load is back to normal. In the attached graph yo=
u can see the peak=0D=0A=0D=0Ain blue (compilation of the patched 3.2.8 K=
ernel) and then after 16.00 the going life of the=20=0D=0A=0D=0Avideo Dom=
U. We are below an avaerage of 7% usage (figures are in Permille).=0D=0A=0D=
=0A=0D=0AThanks so much. Is that already "the final patch"=3F=20=0D=0A=0D=
=0A=C2=A0=0D=0ABR, Carsten.=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0A----=
-Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Konrad Rzeszutek Wilk <konrad.=
wilk@oracle.com>;=20=0D=0ACC:Sander Eikelenboom <linux@eikelenboom.it>; x=
en-devel <xen-devel@lists.xensource.com>; Jan Beulich <jbeulich@suse.com>=
; Konrad Rzeszutek Wilk <konrad@darnok.org>;=20=0D=0AVon:Carsten Schiers =
<carsten@schiers.de>=0D=0AGesendet:Di 28.02.2012 15:39=0D=0ABetreff:Re: [=
Xen-devel] Load increase after memory upgrade (part2)=0D=0AAnlage:inline.=
txt=0D=0A=20=0D=0A=0D=0AWell let me check for a longer period of time, an=
d especially, whether the DomU is still=0D=0A=0D=0Aworking (can do that o=
nly from at home), but load looks pretty well after applying the=0D=0A=0D=
=0Apatch to 3.2.8 :-D.=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=
=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Jan Beulich <J=
Beulich@suse.com>;=20=0D=0ACC:Konrad Rzeszutek Wilk <konrad@darnok.org>; =
xen-devel <xen-devel@lists.xensource.com>; Carsten Schiers <carsten@schie=
rs.de>; Sander Eikelenboom <linux@eikelenboom.it>;=20=0D=0AVon:Konrad Rze=
szutek Wilk <konrad.wilk@oracle.com>=0D=0AGesendet:Fr 17.02.2012 16:18=0D=
=0ABetreff:Re: [Xen-devel] Load increase after memory upgrade (part2)=0D=0A=
On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> O=
n 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote=
:=0D=0A> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct =
vm_struct *area, gfp_t gfp_mask,=0D=0A> > struct page **pages;=0D=0A> > u=
nsigned int nr_pages, array_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_m=
ask & GFP_RECLAIM_MASK) | __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D=
 gfp_mask & (__GFP_DMA | __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=
=0A> >+if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I =
didn't spot where you force this normally invalid combination, without=0D=
=0A> which the change won't affect vmalloc32() in a 32-bit kernel.=0D=0A>=
=20=0D=0A> >+gfp_mask &=3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gf=
p_mask &=3D ~(__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0AD=
uh!=0D=0AGood eyes. Thanks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=
=0A> > nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > arra=
y_size =3D (nr_pages * sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=
=0D=0A_______________________________________________=0D=0AXen-devel mail=
ing list=0D=0AXen-devel@lists.xensource.com=0D=0Ahttp://lists.xensource.c=
om/xen-devel=0D=0A=20
--=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>Great news: it works and load is back to normal. In the attached graph =
you can see the peak</p><p>in blue (compilation of the patched 3.2.8 Kern=
el) and then after 16.00 the going life of the </p><p>video DomU. We are =
below an avaerage of 7% usage (figures are in Permille).</p><p><br />Than=
ks so much. Is that already &quot;the final patch&quot;=3F </p><p>&nbsp;<=
/p><p>BR, Carsten.</p><p>&nbsp;</p><p><br />&nbsp;<img alt=3D"" src=3D"da=
ta:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAfEAAAGECAIAAACpv45YAAAgAElEQ=
VR4nO2dfXQUVZ73b0gCISAJwSBgtknEkJA3zAYVfUaPj2cdHceDOIFlZgB3dpxhRkQj6Koc52=
CvsDoKAzjBLDmoZINBMN2BBFlfEEkE9xAJ6KBEjLw4KEh3Oq/3nz3n+SPPHxeuRd2q6pvurur=
qqu/n9OnTXX3r3vu7devbv9yu+oZ8BgAAwBG0traSePcBAABADGhtbX3jjTcuaToFAACQyLzx=
xhvQdAAAcAjQdAAAcA7QdAAAcA7QdAAASCQaBZSfQtMBkIIQEu8uDINY9TaxonYVg4ODTM2h6=
cCBmCc9vGbxRUyqNQlourPp7+8/cuSIz+c7f/58U1OT8iNouqtZuHDhb3/7W+WWf/3Xf120aF=
E0dRJCCCFJSUlXXXVVWVnZ8uXLz549G103Y4ymToWV7CjVzWJxhKY7mM7OzpaWlra2tq6urqa=
mpiNHjig/haa7mkAgUFRU9MYbb7C3r7/+enFxcTAYjKZOrgKBQODQoUMPP/zw5MmTT5w4EW1f=
Ywc03fp6QAz56KOPzp8/r/cpNN3tHD169Jprrjl27NixY8cmTZrEpkF/f/+KFSuuvvrq0aNHV=
1ZW/vDDD6wwIWTjxo0ejyc1NbWsrOyTTz4RKxRV4Omnn/7lL3/JXnd3d//Lv/zLVVddddVVV/=
3mN7/p7u7me23YsGHq1KkjR46cMWPGBx98sHnz5mnTprGGDh8+zIp98cUXP/vZz8aMGTNq1Ki=
77rrrzJkzqkYj6yHfSBSINYsvxPKaPTSo1mBAwgZiACFk9erV2dnZ6enpixYtCoVClNJbb711=
69atvExnZ+ekSZNU6hAKhRYuXJienj5x4sQ1a9YYxyVTIbAYaDqgr732WnFxcXFxcV1dHdvyp=
z/96c477zx58uQPP/ywcOHC3/3ud2w7IaSysvLrr78OBALPPvtsRUWFWJuomJ2dnddccw17/d=
hjj919991nzpw5ffr0P/3TP1VVVfG95syZ89VXXwUCgeeee27s2LEPPPAAf3vjjTeyYoWFhe+=
8804wGDx//vzSpUsXLFigajSyHlL9PF1mPb26uvqee+6R7KHqrcGAhA3EAEIIq/bMmTN33333=
448/TindtWtXQUHBwMAAK/Pggw8+//zzqh2rqqp4f+666y7eT824ZCoEMQfXvYDwlJeXz5o1i=
7/1eDzHjh1jr0+fPj1x4kT2mhBy7tw59joQCKSkpIhViZLX29ubmprKXk+ePPnzzz9nrz/77L=
MpU6bwvf7+97/zmlVvNRsKBAJXX321qtHIekij0PSWlpaZM2fyP2XC9lD11mBAwgZiACHkb3/=
7G3v9+eefX3vttex1RUXF66+/zjcGAgHVjlOmTOE7fvbZZ5pjpYwrbIXAJHDdC9Bl8+bNN9xw=
ww033PDaa6+xLSkpKcrlgqSkJLZdT5iMN7I/ydnr5OTk/v5+9rqvr49LlXHN/O2HH354yy23p=
Ken63VMpocjRozgfWD09/ePGDHCuAbNJo4cOTJt2jTlrwVhe6h6G9mA8I3K9RzVR5rV7tixIz=
8/v7+/f/78+WvXrhV3VPUn7MiHrRCYAa57AbocOXJk8uTJX3zxxfHjxydPnnz06FFKaU5Oztd=
ffy0WjkzTn3766V/96lfs9eTJk5Vp4OTJk2Vq5m+nTJlSV1d3/vz5wcHBCxcuhE2iNXvo8Xj+=
53/+R7nl0KFDHo/HuAbxxZkzZ/Lz8/ft26csH7aHqreRDUhYlHn63/72N57+Dw4OFhcXV1VVe=
Tyenp4ecUdlnv7555+HHfmwFYKYg+tegC6BQGDGjBlvvfUWe/vmm2+y616ee+65u++++/jx43=
19fYcPH66srGQFhqXp7LqXpUuXKq97WbZsGV/nveuuux599FGZmvnb8ePH79ixIxQKffHFF5W=
VlZFp+r//+7+Xl5d/9NFHoVAoFArt379/5syZa9asYZ9mZGTwdSfNmvmLG2+8cfPmzarK9Xqo=
V21kAxIWQsjPfvazs2fPnj179p577uHL9JTSuro6Qsirr76quWNVVRXbkS3Ehx35sBWCmIPrX=
oAuCxcu5CLCePjhhxcuXDgwMOD1etlFF0VFRfy3U/kFgaSkpDFjxpSWlj7++OP86hRKaTAYXL=
x48dixY8eOHbt48WJ+3aSkpr/11lu5ubnJycn/8A//sHbt2sg0fXBwcO3atcXFxaNGjRo1alR=
xcfFf/vIX/umqVavGjBljULPyhRLjHupVG9mAhIUorntZuHAhv5yGUrpt27Zp06b19fVp7tjd=
3f3rX/969OjR2dnZyute9OIKWyGwGGg6AO7i3nvv5Xck2LNCYAyuewEAUErpwMBAdXV1YWEhv=
/rQbhUCGVQiDk0HwKUQQjweT2trq20rBDI0NTX19vay1729vbjuBQAAEpjW1tZPP/20r6+vr6=
/v008/bWtrU34KTQcAgESiu7v7wIEDfr/f7/e3trYqfwCn0HQAAEhosJ4OAADOAZoOAAAJjIu=
uZTy+d+/xvXvj3QsAALAOx2p6Xyi0/pZb1t9yS18oFO++AACARThW0z946SWvx+P1eD546aV4=
9wUAAOKDQzT9/MmTa/Lzmaavyc8/f/JkvHsEAACmEAwGW1tb+bWMqn826RBNr1+8mAk6e9QvX=
hzvHgEAgCns27fv2LFjvb29vb29R48eVbk9O0TTGU899ZRMsa6uLuuLyZfs7eiIS7uI15p2Ea=
817do83mjw+XzcYGdgYMDn8yk/daOmHzx40Ppi8iUvbNoUl3YRrzXtIl5r2rV5vNHgijy9t7f=
3xIkTv/3tb4eGhk6fPm38/L//+79hywwNDZ08eTKGtcmX7Dp2LC7tIl7Ei3gti3doaOjrr78+=
ceKE/B8KnEAg4Pz1dMZTTz01JMGpU6esLyZfkra1xaVdxGtNu4jXmnZtHu+lwibgRk0HAAA7E=
JnQueK6Fwby9GhKIl5r2kW81rRr83gvFY4IO66n19fXFxYWpqamlpaWtrS08O0rV67k/+fw66=
+/nj179siRI2fPns3+h724RQXydABAAhGZftrxupcHHnigvb29u7t706ZNEyZMYBvb2tomTZr=
ENX3evHkrVqzo7u5esWLF/PnzNbeoQJ4eTUnEa027iNeadm0e76XCEWHHPJ1z4sQJj8dDKe3u=
7i4uLt67dy/X9AkTJpw+fZpSevr0aab74hYVyNMBAAlEZLJp3+teTp06VV5evnPnTkrp0qVLX=
3zxRUop1/QRI0awvy/6+/uTk5M1t3D6//73C6+88uTvf08PHBgaGjJ+Pr1zZ9gy9MCBU6dOxb=
A2+ZK0rS0u7SJexIt4LYuXHjjw/0KhC6+80tPeHltdjZumt7a2ejyeLVu2sLdJSUlEAaU0Kyt=
LlZWLW1QgTwcAJBCRiacd/dOrq6uzs7N3794tfsTz9MrKSr56XllZqblFBdbToymJeK1pF/Fa=
067N471UOCJUIq4iPppOruTixYvKj9iLr7766qabbkpNTb355ptPnjypuUUF8nQAQAIRmX7aU=
dNNAnl6NCURrzXtIl5r2rV5vJcKRwQ0HQAA7IgZMuhGTXfG97zb8hrEG2VJxGtNu/B7iQ3D8m=
XEM57xjOe4P0fmy/jOO++0t7efPn26v79fs4BDNJ2BPD2akojXmnYRrzXt2jzeS4WHz4ULF44=
fP75///6mpqb9+/cfP378woULygJu1HQAALAD0chdX1/f6dOn29vb33nnHeV2N2q6M77n3ZbX=
IN4oSyJea9p16Xq66MsoboEvIwDA2ZihrnbxZRS3wJfR4nYRrzXtIl5r2rV5vJcKm4BdfBnFL=
fBlBAA4m5ioqC38XhinFL6M4hb4MsLHDvEiXqfGS2Pny2gXTVf5Mopb4MsIAHA2kYlnYvgyil=
vgy2hxu4jXmnYRrzXt2jzeS4VjgS00XfRlFLfAlxEA4GxiIqe20HSTQJ4eTUnEa027iNeadm0=
e76XCJuBGTQcAADsQmdAFg0Gb/j/SmIM8PZqSiNeadhGvNe3aPN5LhSNi3759x44d6+3t7e3t=
PXr06L59+5SfOkTT4cuIZzzjObGeI/NlpJT6fD52VTeldGBgwOfzKT91iKYznJenkw2EbCDWt=
GuHeK1sF/Fa0y7iNSocEa7I0xnOW0830HQAQKITmdAFAgGsp19BAn3PdwyRjiHk6aa0i3itaR=
fxGhU2Abv4Msq4MLrEl1GZm9eS2lpSG9/+AABMIjL9tON9pJG5MDrPl5FrN9Nx9pizMofLegW=
prdDRdLflNYg3ypKI15p2LcjTmYhzKbeFpnOG5cLoPF9GlaYPEUI2EK/X2zFEWHpuoOkAgEQn=
Mtn0+/0//PCDz+e7cOHChQsXdu3apfzULr6MMi6MzvNlrH/sMfba6/W25KyqJbUtOauac55ry=
VlVQWrpgQMVpHZ5zqqYt5uIPnaIF/E6KV4ahS/jp59+2tTU1NnZ+c477/j9/i+//FL5qV18GW=
VcGJ3ny8jXymtJbYXwGBoaIkv2kCV74tpHAIBZmCGtdvFllHFhdJ4vY4WWplflPCej6W5bf0S=
8UZZEvNa0a816uu1+I43MhdF5voxc0y+JuJfwF0zKkacD4GDMUFdcn25RMc2SSk1n8k2W7Jnz=
4EYu5cjTzWsX8VrTLuI1KmwCbtR0+8D1mgu68jGEPB0AR2OGDLpR0+3zPa+p6cjTrWkX8VrTL=
uI1KmwCDtH0BPVlJEv2sNfFK3aQJXtUz3x73PuJZzzjOebPEfsywj9djX2+55GnDyGPs6pdxG=
tNu/BljCVYTwcAJBCRCR3809XY53seefoQ8jir2kW81rTr0jydX5nOtzQ0NOTl5SUnJ+fm5jY=
0NFB3+DIiTwfAzUSmn/b1T1dq+rhx4/x+fygU8vl8GRkZ1CW+jMjTkcdZ1S7itaZdV1/3otT0=
kpISv9/f09Pj8/nKysqoS3wZkacD4GIiU047egMwlJp+4MCBcePGEULGjRt34MAB6g5fxrmL1=
7PXZMmeuYvXs+c5D25kr/n2mLebiD52iBfxOileGoUvo33905WaPm3aNL72cv3111N3+DIiTw=
fAzUSmnImh6ZmZmXztZfz48dQdvoxkyZ5L/94I6+mWt4t4rWkX8RoVjgg7arrKl5FSWl9f7/F=
4kpOTp06d+uabb1J3+DJqajrydABcQkzk1BaabhKJmKez/yKNPN36dhGvNe0iXqPCsQCabiPI=
kj3MMB15OgAuJDKhs+91LzEnEfN0UdORp1vTLuK1pl3Ea1Q4FjhT0xPXl/H+4poKUgtfRjzj2=
W3PEfsyqnCmpjMSMU8XH8jTrWkX8VrTLuI1KmwCbtR0m6B3uQvW0wFwCZEJHdbT1djke15P05=
GnW9Mu4rWmXcRrVNgE7OLLODAwsHLlysmTJyclJbHtjvdl7BgKk6dz0Y93TwEAphCZfto3T1d=
q+qpVq6ZPn97e3j44OMi2ON6XsVbnEkaep/MCsW3XmmLyJZHHWdMu4rWmXWvy9J6envfee6+p=
qens2bOqj+yi6R6PR/XfOhzvy6h3WTp/VBhqOgAg0YlMOZmgHzt27Lvvvtu9e/f58+eVn9pF0=
5OTkx955JHRo0d7PJ4dO3ZQF/gyVpBa7sVItHwZl+esIvBlRLyI14nx0ih8Gd99910u199880=
1LS4vyU7to+oQJE3w+H/NlvPrqq6kLfBmRpwPgciJTTpVWf/nll8q3YTR93759+fn5SUlJlNI=
FCxbU1dVF1glNlJo+f/58n8/HfBmzs7OpC3wZ9aScr6cba7rb1h8Rb5QlEa817Vrjyxj5b6TX=
X3/9rl27mPh+9dVXU6dOjawTKkRfxq6urp/85Cepqal5eXlsYd3xvoxhLnq58kJ1AIDziEw/o=
/LaTU1NDYVCTHbPnTuXnp4eWSeswWF5urGmuy2vQbxRlkS81rRrd//0O+64Y/PmzYSQrq6uBQ=
sWzJkzJ7JOWAPydABAAhGZ0EWl6V1dXffdd196enp6evqcOXO+/fbbyDphDcjToylp87wG8UZ=
ZEvFa065L7yONOYnoy6jpxaj5bIfe4hnPeI7tc8S+jPa9jzTmIE+PpqTN8xrEG2VJxGtNu5bl=
6YODg6pFGIa2phN9oumE2WA9HQCQQESsdf39/UeOHPH5fOfPn29qalJ+hDzdomJiSeTpDORx1=
rSLeK1p14I8vbOzs6Wlpa2traurq6mp6ciRI8pP7eLLyFi5ciXf6HhfRuTpALicyPTzo48+Un=
m8KInn2ouqtra2tkmTJvGNjvdlRJ7OQB5nTbuI15p2XX3di1LTu7u7i4uL9+7dyzc63pcReTo=
ALscMXbWLpi9duvTFF19UbnS8LyMRHBnJlb6M/Dm27cYrXr1n+PYhXhfGS6PwZTRGV9OZtlq2=
9sL+vZGyFcf7MiJPB8DlxFBOOXbJ08WN8GXEerqp7SJea9pFvEaFTSDO172IuT9/C19G5OkAO=
Bsz1DWMpm/fvt3j8SgXRszoRKxAnh5NSZvnNYg3ypKI15p27Z6nT5gwYdu2bf39/Wa0HXOQpw=
MAEggzZDCMpmdmZgYCATMaNgPk6dGUtHleg3ijLIl4rWnX7nn6s88+u3Llyu7ubjPajiHwZcQ=
znvGcWM8R+zIaE0bTGxoaRo0a5TAPL5t8zyNPZyCPs6ZdxGtNu3bP07OzsxsaGrCebgZYTwfA=
5Zghg2E0fdy4cVhPj0kxsSTydAbyOGvaRbzWtGv3PN2k9XRxJae+vr6wsDA1NbW0tLSlpYXCl=
xF5OgBOJ7a6ygij6ZZ5AzzwwAPt7e3d3d2bNm1i9/3DlxF5uqntIl5r2kW8RoVNwHbeACdOnP=
B4PBS+jMrHBhLvzgIAYo8ZuhpG05OSksxolSFq+qlTp8rLy3fu3Enhy6jcvoHAxw7xIl4nxUu=
t92VkTJky5ezZs7FtkqPS9NbWVo/Hs2XLFvYWvoz84fV6491ZAEDsMUNXw2j6iy+++NBDD128=
eNGMtpWaXl1dnZ2dvXv3br4Fvoz8UUtqY9iuNcXkS2K91Zp2Ea817dp9Pd2k30jFOlVbLl68C=
F9GY00HACQ6MZFTFfH8jTTmODVPr0CejnijLol4rWnX7nl6YuHUPF1T0wEAiY4ZMhhG0/ft25=
efn8+uflmwYEFdXZ0ZnYgVyNOj6aHN8xrEG2VJxGtNu3bP06+//vpdu3axJe+vvvpq6tSpZnQ=
iehzuy/h+cdx7i2c84zm2z/HxZUxNTQ2FQkzTz507l56eHtvmY4tT8/Qhr8Y9R27La6yMV3mT=
lxviNbVdxGtU2ATCaPodd9yxefNmQkhXV9eCBQvmzJljRidihVPX0wksX6wFN+4CazBDBsNoe=
ldX13333Zeenp6enj5nzpxvv/3WjE7ECqfm6Zqa7ra8Bnl6lCVxfK1p1+55ukmIV7vLuDC61p=
cRebrFIE8H1mCGutrFw0vGhdG1vozI081oF3m6Ne0iXqPCJqCr6R9++GFhYWFKSkphYeFHH31=
kRttKTZdxYXSvLyPydGtBng6swQxd1dX0oqKil19+ORAIvPzyyyUlJWa0rdR0GRdG9/oyLtkD=
Hzsr4537dI6r4nXb8bVDvNR6X8bk5OSenh5KaSgUUglorFBquowLo2t9GZGnWwzZQJCqAwswQ=
1d1NV0puLH990aa1cq4MLrWlxHr6Wa0a7yezjXdDfGa2i7iNSpsAkaarklMWhXrlHFhdK0vI/=
J0i0GeDqwhJnKqwo0eXjb5nkeezrBhHoc8PYYlEa9RYRNwo6bbBOTptgV5OrAGM2TQjZpuk+9=
55OkMG+ZxyNNjWBLxGhU2AYdourN9GYtX7Ih7b131TDaQ4g3wwsSzuc/x8WVMLJCnR9NDm+c1=
yNOjLInja027yNNjCdbTQUzAejqwBjNk0I2abpPveeTpDBvmccjTY1gS8RoVNgG7aHpDQ0NeX=
l5ycnJubm5DQwOFLyPy9PiBPB1YgxlaahdNHzdunN/vD4VCPp8vIyODwpcRebrJ7SJPt6ZdxG=
tU2ATsouklJSV+v7+np8fn85WVlVH4MiJPjx/I04E1mKGldtH0AwcOjBs3jhAybty4AwcOUPg=
ywpcxfvHOfTqHbCDuiddtx9cO8VLrfRktZtq0aXzt5frrr6fwZUSeHj+QpwNrMENL7aLpmZmZ=
fO1l/PjxFL6MWE83uV2sp1vTLuI1KmwCdtH0+vp6j8eTnJw8derUN998k8KXEXl6/ECeDqzBD=
C21i6bHBOTp0fTQ5nkN8vQoS+L4WtMu8vRYgjwdxATk6cAazJBBN2q6Tb7nkaczbJjHIU+PYU=
nEa1TYBByi6fBlxHMMn+HLiGcLnuHLGB7k6dH00OZ5DfL0KEvi+FrTLvL0WIL1dBATsJ4OzEC=
cVGbIoBs13Sbf88jTGTbM45Cnx7Ak4uW4S9MHBgZWrlw5efLkpKQkQgiFLyPy9PiBPB2Ygbs0=
fdWqVdOnT29vbx8cHGRb4MtokzxdNRHdkMchT49hScTLcZemezwen8+n3AJfRpvk6cPNWB2Q5=
DogBGBD3KXpycnJjzzyyOjRoz0ez44dOyh8GVXbn86JVbvDjZc7FErWRjYQ1tvE9e2DLyPiNS=
Ne1VnscF/GCRMm+Hw+5st49dVXU/gyqh5xTBsJ8nQAYoC78vT58+f7fD7my5idnU3hy3jlw+v=
1xqrd4RarJbXDq40Q9jWQuOutWE+PYUnEy3GXpnd1df3kJz9JTU3Ny8tjC+vwZVQ+VMJqJcNt=
upbUxrG3MQF5OjADd2l6THBwnl4hqKRt83Su6YmbxyFPj2FJxMuBpg8bB+fpoqZbBvJ0AGICN=
H3YIE+PpodiMTYFkafHtl0bxmtqu4iXA00fBo73ZawgtXHo4YZisoHUFNcMa6+a4praePQ2tl=
HDlxHPMX8mG4hyC3wZw4M8PZoeisW8Xi/ZQNyWp7MkHXl6rEoiXg7y9GGTQOvpZAMZ3vXp8bi=
VtJbUdgypNV1mr4ReT1dpOgCxApo+bBIoTzfQdM08XdR0C/Iaps7Gebo4TZGnG2O3eM1uF/Fy=
3KjpK1euZKaM1Om+jLWkNiHy9LBJt4GmJyjI04FJuE7T29raJk2axDXd2b6MBppuhzydiZpMn=
i7KN/J0Y+wWr9ntIl6OuzS9u7u7uLh47969XNOd6svI9KLC3nm6gaarMND0BCXh8vQE6qrLcZ=
emL1269MUXX6SUck13qi/j3KdzvF7v8pxVZFi+jIvXR9nusOJl3oq1pLYlZ1UtqTWoTfUp29K=
Ss0q+Xbv59rHYE8iXcdnTs6OJ1+xxttvxjWO87vJlZP/eiEOd68vo9XprSa3N83Sv18v6iTzd=
/iT0aLsKd+XpHJ6nO9WXkUmegabbYT2dq/mlrirmItbTo2w35vHWlNTEsEL7x4v1dGPsq+lO9=
WW8JHleW1+fbqDpYknNfU3uoIkgTwcm4VJNj4ZEydONF17My9ONpco4T9fLW5GnD7dd5OnWtG=
vDeKHpwyYh8vSKiBbTo8/TyQbCVsnDZqD8ipeKyw+D1NUZeboyOh5soqTqtYZ/SAE7wA4QNH3=
YJESeHlbTTcrTuVLr/S86XkzU9FpSy78PVJex62m6qqQBMnmcfG1DOiMjarR4Pb7yNd9i/7y1=
pqSmYyi8ptswbzW1XVvFC00fNgnky1hBau8vriHSjow/PkfnFOj1eu8vrqkgtcY+i8UbiocIY=
SXZc/H7xbWklrktrlmzRlWnWNulvTYUD132OIzewS56l0RVT5TOi8x7kntJcl9Gsecx71VMnm=
vDHVO7Pcd33OLSOps58GUcNhHk6ZLry5K1yZSMOE8X00zNJQJVvslLKvNug+7xSy1/XHjpIMq=
EXVx2H7pyGPlyDWuX/SdVg3E2yGuUDUWTT2kMFCHvnyq5tIUQ5XqRQZ6u/Mg48TcIx4w8XWax=
K+55q3JmWtCuwe8lesWMl7CQp8eBCNbTI1g2lSyvVyyyxXSyZM8QuaKroriIiqN8hNV0xhXFO=
ohK01XXwNTy2oha09nyC1+H0RtnZecNQlBVohoH46OgXE3SfKu6DF/V6JXVaWi6zBQydb3bgh=
8wYtJ/A003dXzk2zKvG9D0CNHUdHE0Wf7IP9XLvPj6snGxkg0lxvmyqt2w2q2XpysliWwgJRt=
KhghhOeYVHRN0p2RDSe2V0qwXL9lAVBk6eyg38niH+DU8V8of13TW7qWPiMbosddzVuaox5ao=
A2G1sXg1KxHHWXnUvF6vMnDWK7YMrdR01V6svPL4Kofa6/WqglKOjArlejdtaxOnil4UMvJnQ=
Z6uuV4vn7eSy38P8dpUUXi9XtXfnQbyKh+IagA1a1YWM9Z0pW6oUPbc4PiKB9oMGbSLptfX1x=
cWFqamppaWlra0tNBIfRnF4YvyIUqkZhmZYpdq6xj2lelsl4rL0sM8zVW/YfKPKkhtxxDhZXh=
5PU1XPrj2GWi6Mt4Khab/uMbiJUPeH1uvUCqmYpVDbJ11m4UwRIgyLjFeycOnGivWgQqdB6uW=
KQ6Ljm3hvw+LqT3vtnE3VB3mosaHXXXCKweEXPlNoypDrvybQ09ENCvRK8DjVfVfT8v0ZOuKa=
a8YBDGrEA+ockhVait56DW6JHeSRv9QNaQ3XR2u6Q888EB7e3t3d/emTZvYff+R+TLWCic8kx=
v+1uv1vn+qhF3+wQ/Aj1pDLuVfQ4Sw9EepIFxrOoZ+TNPWrFnDFYHtyB6sGKuQFT5VUvKjUA4=
rT7+s6crH/SU1etqkWZK1O+QlQx2K1QZFRsy6p1LzS3spZL3mcrtMfJXKe2mQL38N8JL8U66n=
bEDYM83JMdBZvXiV3ytK5WUL5WHlW28A2YHjh7uC1J4qKRG/nzQfbF6pjrtybrAtc1bmKKcfD=
4HvyDbyw8G/Dll0rBift0OEsECU+7JiFfxfmhDi9Xr5n02sJCvDesgFlI1e7ZWTmbtEqCRJ/D=
tMeR7xHh5vyxEHtvbyaPMvS95u7eVjp/weVZ7Ca9asqVVMAHWZcOkAACAASURBVPZp7eWrs/g=
4swFkJVW5gnJffnx5Z7gxBg+fn7+qAVTGy7fTnBzeBG9XVHb2V4sZWmoXTeecOHHC4/HQSH0Z=
JWUujo+wmq6dp1+ZLEferkRVQ1cKuvGOyi+bS2d4LHob52Ok0HQ88Ij+oVyl5BtdoemnTp0qL=
y/fuXMnjdSXcXnOqgpSa/z8/Ow/hS2zPGfV/SU1MayNl5z7Rg7pIHPfyCHyvowdZO4bOTFrt4=
MYxDt0uYzes6pdsTbeW8keVuU8Z8Y4R3N85z6d0zFETGrXhvGa2i7iVc4r5RaH+zJSSltbWz0=
ez5YtW9jbyHwZK+L9hRz28WPaO8w8fcgbVeYomafrZeh6+2puSfQ8XWYtCA88hvvga2KX3jo7=
T6+urs7Ozt69ezffEpkvo8zISq5Ex7ZYxZXr2gaarr2eLgjl/SU1vIByu+bK+1C4JRSN7uk8l=
PHqqTzbyNoN+1VUlfOcGeOsPp2u/FVApkI2klG2a028QxJfoibN5wji1extzNu1T7x6D4drOr=
mSixcvRujLKJy6osZpbmRXa4gblSUvXa8t7CsKq0G7V0ik8q1Oem7GY+jyQyNeiTydx6vUdD5=
6ylZ4Ad6W5lipesLeiofj0nX63vDHV2PfK79+rhjzyy9U1+OTyz9N87mhmgyaE0a1UW9eifHq=
zUn14IQLzbhdZW267WrODS0hFkvqzSvlwLK3eqMnDqDM8dWN1ysRr8Qx0jvomvuqmhi68hT4c=
buzNT0mPPXUUzKKVvJ+ifXF5EvOeXCjWu4taTf6YkwydEvqRHQpXsvH2aCYUitjf3zrcowHhG=
2/ojb+xRNNvCt2GBW4/PWm0a6qDC95ucJLqYDe8eXxGjStGYVm68pAYjIscrM0kuMrVFuhNNn=
ucM11L9Egqel44GH8qJBYg8IDj+E+VPMKmh4eh+TpYfMac9pFvIgX8VoWL4GmG8N9GUkHKX6/=
GM94xjOebf4MX8bwIE9HvIgX8SZEvAR5ugxYT8cDDzwS5QFNDw/ydMSLeBFvQsRLoOlU0pdRb=
jTxwAMPPOL74Jpe/+CD33/1Vax0MpE0XcaXUWYonfE977a8BvEiXifFSxSa7vV41kyf/sFLL/=
V1d0evk4mk6TK+jJKjiQceeOAR34dS09ljw//5P397550odTKRNF3Tl/Ho0aNPPPHEimXLHrv=
vvv97662PL1z4xBNPGD//7v77w5Z5fOHC3/zmNzGsTb5k1S9+EZd2ES/iRbyWxfv4woVMtZb/=
9rc/avqtt/5tz54odTKRNF3Gl1Gmni+//NL6YvIlu99/Py7tIl5r2kW81rRr83iVsLWX9//8Z=
9etvcj4MsrU09PTY30x+ZIXNm2KS7uI15p2Ea817do8XiX1ixd/39k53L30SCRNl/FltL5XMa=
f/7Nl4d8FSEK+zQbwWk0iaHpb2WP/HEAAASCwcpemJAiEk3l0A5oJD7GzsfHyh6SbC/r/HqFG=
jpk+f/txzz/X39xsUU86S+vr6wsLC1NTU0tLSlpYWZWHxxquwt2IBkyCE/Nd//Rd/+x//8R96=
p/qwjhoOsU2QP762OoWh6SbCjnFvb+/HH3984403/tu//VvYwowHHnigvb29u7t706ZNqit8x=
Buvwt6KBUyCEDJ79uzBwUFKaW9vb2lpqd45P6yjhkNsE+SPLy/PX8fxFIamm4jyGHd0dFx77b=
Xids3CnBMnTng8HuWn4o1XYW/FAiZBCPnjH/+4Y8cOSunmzZufeOIJfphUR1PmqOEQ2w3542u=
w0fpTGJpuIspj3Nvbm5KSIm7XLMw4depUeXn5zp07lRvFG680b8UCFkAIOX78eEVFxeDgYGlp=
6cmTJ/XO+WEdNRximyB/fPU2xuUUhqabiPIYHz16NCcnR9yuWZhS2tra6vF4tmzZoiom3ngV9=
lYsYBLskN13332///3vf/GLX1DFQVQdzWEdNRximyB/fDU3xusUhqabCF9PP3To0OzZs/l6et=
gJUV1dnZ2dvXv3brGYeONV2FuxgEmwQ/b+++8TQvbt20f1z/lhHTUcYpsgf3zFjXE8haHpJsJ=
+Ch85ciS77qWvr49vF4spfzpXbbl48SLfRbzxKuytWMAkxBNb75yXOWo4xHZD/vja6hSGpgMA=
gHOApgMAgHOApgMAgHOApgMAgHOApgMAgHOApgMAgHOApgMAgHOApgO3Y2zMBEBiAU1PYHp6e=
pYtW3b11VePHTv2+eefj3d37A4h5IUXXqCGpqmA097eTgjB/5mRwVZTC5qewCxfvvy+++775p=
tvvv/++0cffTTe3bE7hJCCgoLBwcHp06fH/cSzP2vWrBkxYsSaNWvi3ZEEwFZTC5qewEyZMkX=
1v8yV80l5H/Py5cvT09PLysrEYu6BEHLLLbesWrXq1ltvVQ6OatBefvnl8ePHZ2Zmbrr8z4Ld=
OVx33HHHgw8+eMcdd7C3ZWVl7H87NDc3z5w5k1La1tZWUFCQlpa2YsUKYyMUxyNOLTavUlJS+=
P/E+P3vf//rX/+aUvqrX/1qyZIlfMeYdwaansAkJyer/neSnqa/8MILgUDgoYcesrR/NoMQ8s=
Ybb4wYMWLr1q2aA8Ver1+/PhgMNjU1udkBMRAIjBkz5ptvvhkzZkwgEKCUrl27lv8Dh3Xr1lF=
KS0pKNm7cGAgENm3a5E4p5+hNrf7+/n379k2aNIlS2tfXd+edd/7hD3+48847ufWTGUDTExiD=
PL2vr0+p6b29vVZ3zn4Y6LjytZ7VmqtobGzk/lONjY2U0nPnzmVkZHz55ZcZGRnfffcdpTQlJ=
SUYDFJKg8Ggm8eKak2n9evXezyeESNGEEKSkpLYR21tbYSQtrY2UzsDTU9gqqqq7rvvvlOnTp=
0/f76qqopSOmHChN27d3d3d2/YsMHlfw6LSGq65mu3sWTJEvar+/PPP88XCiorK2+44YZ58+a=
xt8XFxX/961+DweB//ud/unmsqNa0SUtLa2pqCgaDPp+PbQkGg6WlpXfffXdpaWl3d7d5nYGm=
JzChUOjhhx+eMGECv+6luro6IyNj/Pjx69atM9B0d56B4omnaZEqlnfhcOXl5R0+fJhSevjw4=
by8PLaxubmZENLc3Mzetra25ufnp6WlPf744yNGjGAbXThWVGvaPPvssxkZGRkZGatXr2ZbFi=
1atGDBAkrpP//zPy9evFjcMVZA0wEAkTMwMPDWW29Nnz493h0Bl4CmAwAihC0W5+Xl/fd//3e=
8+wIuAU0HAADnAE0HAADnkBia7s4fXgAAYLgMT9OJDpolk5KSrrnmmj/84Q/sIlYr6ezsvOmm=
m0aOHHnTTTd99dVXFrduGeL4NzQ0zJgxY+TIkeXl5e+99x7bkpeXl5ycnJeXt337ds16GhoaP=
B5PamrqjTfeePz4cUrpli1brrvuutTU1JkzZ+7du9eacMxGHC5xSygUeuSRR7Kzs/UmNtUaZO=
NzIRHRC8fr9fKN4rSRqUc5VllZWSb132LEKSFKkIwoieedzIRUMXxN7xAeOpo+ODh48uTJ+fP=
n//GPf5TpSgyZO3fuihUruru7V6xYUVlZaXHrFqMc/8rKyo6OjlAotH379okTJ1JKMzIydu3a=
FQqF/H5/RkaGZg1ZWVktLS09PT0+n+/nP/85pXTu3LmHDx/u7u7esmWLw26nNL6ys6qqqqysr=
KOjY3BwUK8GcZAdI+UqVHF98sknTFzYW3HaSNbDWLJkyZNPPhnD3sYRcUqIEiQjSuJ5JzMhVZ=
io6ezFyZMn2a2xH374YWFhYUpKSmFh4YcffsjK/OM//uO8efNyc3PZjQzsu0hpksA3KmsWHTl=
UZGVlnT59mlJ6+vRph0mSiDj+wWCwvr6eXV5WWlra3Nzc09Oze/duZtMhkpWVtWfPHnZyjh8/=
XvnRyZMnU1NTnXQbqrGmT548+d1335WpRznIhJCMjIz09PSf/vSnJ06ciGFv44vqL5iioqLXX=
ntNqel608agHsb333+fmZnZ1dUV8z7HEeWUECVoWKLEzzv5CckxXdP7+/tTUlIopQUFBa+++m=
owGKyuri4sLGRluJ/nmDFj+L5KkwRVbVTOkWPEiBEDAwO33HJLf39/cnKyzEAkLqrx53/VHjx=
4kFLa2tqamZlJCMnMzNS7Kbmuru7aa68dPXr0448/rhyub7/9tqKiwmGOj8aanpycvGLFivT0=
9JycnG3bthlUohxkxtmzZ6uqqm666aaY9zleKEfmscce+8UvfqHcqDdtjOthrF69mt2A4xhUU=
0KUIHlRUp53khNSiXV5enJyMltYDwQCTOWJ4s49om+SQAVND+vIkZWVdebMGerWPD0QCGzdur=
WoqIhSmp+f7/f7Q6GQz+crKCgwrmrv3r1Tpkxhrw8ePJibm7tixYqBgQEzuh0vjDU9MzPT5/P=
19PS0tLQYr/YqB5nT3d2dmpoaw97GF+XIsLNSc51dOW3C1kMp7evry8nJMdv2xHqUU0KUIElR=
Up138hOSY+56+tdff/3LX/6S+UVo5umqZ9EkgdcW9rWS+++//8knnwyFQk8++SRLLhyMchAWL=
VrU2dkZCoXq6+vZn8Pjxo3z+/09PT27du3SW0+nlA4ODh49erSkpIT5xtTU1FRUVLAlModhrO=
n33nsvP4X0TjxxkBk//PDDqlWrKioqYt/pOGGcrlFh2kjWU1dXN3v27Fh10g6IU0KUIBlREs8=
7mQmpwkRNT0pKmjhx4u9+9zvm1blv376CgoLk5OSCggK+nq56Fk0SyJVQOU0/ceLErFmz2C/y=
nZ2dMgORiIiDU1tbm5ubm5KSUlRU5Pf7KaV1dXXsT5+pU6fW19fzHcV6srOzly5dGgqFxJovX=
rxoeXCxR3MuqbYcP3581qxZKSkpHo+noaGB76isRxxktvuoUaNuv/32zz//3PLIYo84MsqPlG=
WU04bqTC1VPbNmzZJcRkgUxCkhSpCmKBkP18WLFzUnpDFmXcsIAADAehLjniMD8AUDAACchNd=
0AAAAHGg6AAA4B+s0XWZVBCsnAAAQDdb9RhpDTYf0yyBzdPQ8KJS2Hm5AxotDLCPjpZPQiGYj=
MkZAYhmH/dYlhiPOBL2BMj6zYuK8NHxNX7JH/YCm2xjjsdL0oFDZergBSS8OVRkZL52ERjQbk=
TEC0ivjsBmlDEecCZqDEPbMionzklmafujQoZkzZyYnJxPF1awqn5ajR4/efPPNqamp06ZN4/=
52lNKzZ8/edtttmzdvpjouMarvSbGeWbNmsf+a6Ly7G4aL8YkkelCIth5uQMaLQywj46WT0Bi=
YjcgYAanKOGxGKcMxmAl8EGTOrJg4L5ml6SUlJevWreN3IlAtn5by8vLXX389FArt2rVr2rRp=
rExHR0dZWRk38BLvPqXC5BDr2bp1KzMFKy8v37lzZ9i4HIzxiSR6UIi2Hm5AxotDLCPjpZPQ6=
JmNyBgBiWUcNqOU4ejNBOUgyJxZMXFeMkvTU1JS2O2jyn1VPi0pKSk842buLoSQ0tLS7Ozs9v=
Z2VlJ0iaHCoIj19PX1XXfdddu2bSsoKJD3qHQkYfN0lQeFga2Hg5Hx4hDLDMtLJxHRNBuRMQL=
SLOOw6aQMR3MmqAZhWGdWNM5LZml6cXHxunXrenp6lPuqXldUVDQ2NnZ3dyu3nzlzZseOHbm5=
uezvXM08feTIkUpHU7EeSunzzz+fnp6uZ8brHoxnj4EHhcPOQGNkvDjEMpJeOomLaDYiYwSkV=
8ZhM0oZjjgTDAbKeByid14yS9M//vjj0tJS9tUkRsJeHzt27Pbbb09LS+NfXLxMTU3NrFmzgs=
Gg6BJDKV22bBnbi70V66GU/v3vf8/KyrL+XyzZB3IlfKOyjIExjsPOQGNkvDjEMppeOk5CNBt=
RTSpmBKQaKLGM5lRMXMRwxJmgOVB8d83XfK8onZec6fcyMDDwl7/8ZdmyZfHuCAAAWIoz7yMl=
hJSVlbHVGwAAcA/O1HQAAHAn0HQAAHAO8HsBAADnkJB+L0AeGb8I0clExv/EkchMaQwXQ2asR=
AMTcYurCOv3ovKNiWC4hq3pQ171A5puZyQNOlROJjL+Jw7GeB5iuJQYj5VoYCJucQ9h/V5E35=
gIhsssTTfP74U7BzQ3NzvSZMMkDPwiRCcTGf8TBxNWpzBcnLBjpTIwMbA0cTYyfi+ib0wEw2W=
Wppvn97J27dr58+dTSufNm7du3TqZIIGxX4ToZCLjf+JgjHUKw6XEeKxEAxM9SxPHI+P3IvrG=
RDBcZmm6eX4v586dy8jI+PLLLzMyMr777juZIF1OWL8I0clExv/EwYTNPTFcHMn1UqWBid4WZ=
yPj92LgICQ/XGZpuql+L5WVlTfccANzXgTGyPhFiE4mMv4nDsZYpzBcSsJqusrARHOLqzAYMU=
0HoeEOl1mabqrfS3NzMyGEOaQDY1RXKGkadIhOJgY+MM5G84IuDJcmMmPFPhINTJRb3IaohBw=
935hhDZcz/V4AAMCd4D5SAABwDtB0AABwDtB0AABwDmZpOhbZAQDAesz6jRSabhPg9zIsZH72=
x3AxZKZWQ0PDjBkzRo4cWV5ezu4VD4VCjzzyCLtF3sEqIU4kpWDyf+6qidITJoKpNfxrGTvUD=
2i6nYHfSwQYz14MF0NmalVWVnZ0dIRCoe3bt0+cOJFSWlVVVVZW1tHR4YZ//q45kZYsWfLkk0=
/q7aLyhIlgapmr6UrnFtHdZe3atR6Ph3nC4DvAbOD3Io/xbMRwqTCYWoxgMFhfXz99+nRK6eT=
Jk999910LexdPxIn0/fffZ2ZmdnV1aZYXPWEimFomarrKuUV0dxkzZozX6+3o6FDebgrMAH4v=
w8JY0zFcSoynFr285pCVlXXw4EFKaXJy8ooVK9LT03NycrZt22ZhT+OAOJFWr169YMECvfKiJ=
0wEU8tETVc5t4juLm+//fY999wzbdq0sWPHPvPMMzLdBREAv5fhEjZPx3Axwk4tRiAQ2Lp1a1=
FREaU0MzPT5/P19PS0tLQYLys7ANVE6uvry8nJYeZcmoieMBFMLRM1XeXcIrq7MAYGBvbu3Zu=
eni7TXTBc4PcSAcaajuFiyEytRYsWdXZ2hkKh+vp6ZhV77733ck13/PcfEW79nz179rB2jGBq=
mf4bKXdu0XR3IYQwc4ONGzfKdBcMF9UVSvB7MUY1XHyjsgyGiyEztWpra3Nzc1NSUoqKivx+P=
6X0+PHjs2bNSklJ8Xg8DQ0N8em6+WhOpFmzZqmWm/SyB749gqkFvxcAAHAOuI8UAACcAzQdAA=
CcAzQdAACcg9Warlx8x0I8AADElnj+RgpNjzmimUZDQ0NeXl5ycnJeXt727ds192poaPB4POy=
39ePHj2vW4xJkPEzEwXGD34sYtVIB9K40F6efzIR0AOI5JTNJYmIlNGxNryC1qgc03T6IZhoZ=
GRm7du0KhUJ+v5//h0MVWVlZLS0tPT09Pp/v5z//uWY9LkHGw0QcHDf4vRhMCQMDE3H6yUxIB=
yCeUzKTJCZWQiZqOiFk+fLl6enpZWVlfIu49mLsCaNZD9BDNNMoLS1tbm7u6enZvXv3zJkzNf=
fKysras2cPm3/sxhBXmXJoYuBhIg6OG/xe9KaEsYGJOP1kJqQDEM8pmUkSEyshczX9hRdeCAQ=
CDz30kHKj8nVYTxi9eoAmoplGa2trZmYmISQzM1PvpuS6urprr7129OjRjz/+OPOUcJUph4ix=
h4k4OG7we9GbEsYGJuL0k5mQDkA8p2QmSUyshMzVdDHNUWl6WE8YvXqAJqKZRn5+vt/vD4VCP=
p+voKDAePe9e/dOmTJFsx73ENbDRBwcN/i9aE6JsAYm4vQb1oR0APyckpkkMbESMlfTjTcSOU=
8YLLvLI5ppjBs3zu/39/T07Nq1y2D5cnBw8OjRoyUlJVVVVZr1uAQZDxNxcNzg96I5JcIamIj=
TT3JCOgDVOSUzSWJiJWSdpouXyvACBp4wYj3AANFMo66uzuPxMFOd+vp6Vkzz0GRnZy9dujQU=
CmnW4xJUs1TTw0QcHDf4vWhOibAGJuL005yQzkM8pzQniWq4YmIlBL8XAABwDriPFAAAnAM0H=
QAAnAM0HQAAnIN1mj6sy2P4R8br9VjKBwAAJdb9Rhqx/kLTo0HGuQV+LxyZWa1nweH1eh08Vu=
KwNDQ0zJgxY+TIkeXl5fyubxXiWDnS70W0CRInkuSZqBqcCK5DGbam15Ja1QOabmdknFvg98K=
RmVGaFhyffPIJO13N7V+8UQZYWVnZ0dERCoW2b98+ceJEzfLiWDnS70W0CRJngsw5pTc4ttD0=
tWvXejye5ORk/iVDCHn55ZfHjx+fmZm5adMmXqFydz2/F2XNra2tBQUFaWlpVVVV7COxLcCRc=
W6B3wuHEJKRkZGenv7Tn/70xIkTmmVEC45QKFRUVPTaa685fvqJAQaDwfr6+unTp2uWF8fK2X=
4v3CZInEgy55Te4NhC08eMGeP1ejs6Onp6evi+69evDwaDTU1NylsTlbvr+b0oa54xY0ZNTU0=
wGHzllVfYR2JbgCPj3AK/FxVnz56tqqq66aabND8VLTgee+wxdo+f2zSdZVFZWVkHDx7ULC+O=
lYP9XkSbIOVEkjmn9AbHFpr+9ttv33PPPdOmTRs7duwzzzzD9u3r6xO7qHyt5/eirDklJSUYD=
FJKA4EA+0hsC3CG5dwCvxdOd3d3amqq5keiBceIESOG+/NSgiJGFwgEtm7dWlRUpFleHCun+r=
3o2QTxiSRzTukNji00nTEwMLB379709HSqr+PK15p+L5MmTVJmAUVFRSxPr66uVu6rbAtwJJ1=
b4Pei5Icffli1alVFRYXmpwYWHM4WdHplgIsWLers7AyFQvX19WzJTkQcK0f6vejZBCknksw5=
pTc4ttB0lrAwV4eNGzdSLR0nV0Ip1fR7+etf/5qens7f7t+/Pz8/Py0tbfny5cp6lG0BjqZNh=
+Zf0PB7oZeHYtSoUbfffvvnn3/ONyrLGFhwOFjTxbO1trY2Nzc3JSWlqKjI7/fzYsq9xLFypN=
+LanAuXrwoTiSZM1EcHHHYwwK/FwAAcA64jxQAAJwDNB0AAJwDNB0AAJyD3TUdi/UAACCP3X8=
jhaZHiehEISKacuhZmjgemSmN4WLIjJVoJeRIvxd5jE2BxMERBzAsw9b0jiH1A5puZ0QnCs0y=
KlMOTUsT92A86zBcSozHSrQScqTfiyRhTYHEwREHMCxmabqm30tVVVVaWtr06dNbW1sppR9++=
GFhYWFKSkphYSG7XP/QoUMzZ85ke/EWKaVnz5697bbbNm/eLBMS0IQ7UYgfiaYc4hZXEVanMF=
ycsGOlshJytt+LATKmQOLgiAMYFrM0XdPvpbq6OhgM1tTUFBcXU0oLCgpeffVVdkdoYWEhpbS=
kpGTdunXstpcfW+zoKCsra2lpkYkHaCI6USgRTTnELa7CWKcwXEqMx0q0EnKw34sxMqZA4uCI=
AxgWszRd0++F+bQEg0FmgJCcnMydW1JSUiilKSkpgUBA1WJpaWl2dnZ7e7tMPEBEz4mCI5pyi=
FtcRdjcE8PFkVwd5VZCTvV7CYuMKZDB4PABDIu56+kqvxeWldfU1MyYMYNq5enFxcXr1q1T2i=
sSQs6cObNjx47c3Fz25y0YFnpOFEpEUw4DSxM3YKxTGC4lYTVdZSXkSL+XYWEwYpqDoxrAsJi=
l6ey7SOX3wtbT8/Pz9+/fTyndt29fQUFBcnJyQUEBE52PP/64tLSUfaGp4q+pqZk1axbL64E8=
qiuULl68SCVMOQwsTZyN5gVdGC5NZMaKfaS0EnKk38uwUA6Rarj0/F6UAxiWBPjfdQAAACSJ/=
/+YBgAAECvsfh8pAAAAeaDpAADgHOyo6VilAQCAyDDxN1JIsx1oaGiYMWPGyJEjy8vL33vvPc=
0yMDDhwB5HHpmx0rMrMbY9cTBh/V5UwyUzyCqGrelDwgOabmcqKys7OjpCodD27dsnTpyoWQY=
GJhzY48gjM1aadiVhbU+cStjAxeGSGWQVZmm6ZhZPCFm+fHl6enpZWRnV8nvhO8p0HcgTDAbr=
6+unT5+u+SkMTERgjyOP8Vip7EpkbE8ciUzgBu4uBoOswtI8nRDywgsvBAKBhx56iGrdR6q3I=
4gG9jWZlZV18OBBzQIwMFEBexx5jMdKtCuRsT1xJDKB67m7GA+yCqs1Xfk9I/q96O0IoiQQCG=
zdurWoqEjzUxiYKIE9jjxhx4rD7UpkbE8cybACV7q7yA8yw0RNHzly5IkTJ1S7K98iT7eARYs=
WdXZ2hkKh+vp6Pa9OGJhwYI8jj8xYUX27Etee5saBq4ZLcpCVmKjpy5YtS0tLU62nKwuIfi8R=
WA4AY2pra3Nzc1NSUoqKivx+P9uoGlsYmHBUMxD2OAbIjBX7SNOuxLUnuIEkisOlOcjG2P1/1=
wEAAJDHjvccAQAAiAxoOgAAOAdoOgAAOAe7azoW6wEAQB67+71A06NE5ndsGJhwMFzyyIxVQ0=
NDXl5ecnJyXl7e9u3bJfdyAGKYksOl8nuJYLiGreleAWi6/TEeRhiYqMBwyWM8VhkZGbt27Qq=
FQn6/X/nfR11yXothGgeuaY8Tdi8VZmm6mMUT4arMsrKylpYWSmlzc/PMmTOplgMMK3n27Nnb=
brtt8+bN8oEBJWFnEgxMlGC45DEeq9LS0ubm5p6ent27d7NzXGYvxxCBpmv6vdhC08V+iJq+d=
u3a+fPnU0rnzZu3bt06qnVnKSGko6ODqz+IDOM5AQMTFRgueYzHqrW1NTMzkxCSmZnZ1tYmuZ=
djGK6m6/m92F3T+/r62Otz585lZGR8+eWXGRkZ3333HdVygCGElJaWZmdnt7e3y0cFVITNDmB=
gogTDJY/xWOXn5/v9/lAo5PP5CgoKJPdyDMPVdI7S70V+L4aJmq7ye5kwYcLu3bu7u7s3bNjA=
d6msrLzhhhvmzZvH3mrm6WfOnNmxY0dubi77/MwFpgAACHZJREFU8xZEgPGcgIGJCgyXPMZjN=
W7cOL/f39PTs2vXLqyna25RoWmPYxdNV/m9VFdXZ2RkjB8/ft26dXxjc3MzIaS5uZm91XSAYR=
/V1NTMmjWLZfFAHnIlfKOyDAxMOBgueWTGqq6uzuPxjBgxYurUqfX19Xp7OQ8xTJnhYh8Z+L3=
INA2/FwAAcA52v+cIAACAPNB0AABwDtB0AABwDtZpOpbdAQDAbKz7jRSabgF6R8Tg8iTqYlMO=
EeWszsrK0iyj5+5iPMiJzpYtW6677rrU1NSZM2fu3buXUtrQ0DBjxoyRI0eWl5e/9957mnuJE=
0msxwGIZ5Do3CITeGSDrGL4mr5BeEDTbYZqqD/55JPs7GyD8Xe5KYcmS5YsefLJJzU/0nR3CT=
vIic7cuXMPHz7c3d29ZcsWdl9VZWVlR0dHKBTavn37xIkTDfZVDotYjwMQzyDRuUUm8GgGmWO=
Wpis38sszX3755fHjx2dmZm7atEmzDHuxfPny9PT0srIyevl7PiUlpbS0FPYAkigHNhQKFRUV=
vfbaawZy43JTDpHvv/8+MzOzq6tL81PR3UVmkB3DyZMnU1NTe3t72dtgMFhfXz99+nSDXTSHR=
VVPQiOeQXrOLVQu8AgGmWOppq9fvz4YDDY1NbEzQU/TX3jhhUAg8NBDD/FP+/v79+3bN2nSJJ=
mQgHJgH3vsMXZno4HcuNyUQ2T16tULFizQ+1R0d5EZZGfw7bffVlRUPProo+wtX6Q6ePCgwV7=
isKjqSXTEM0jPuUUm8MgGmWO6pnN3F0JIX1+f8lOxDNuo/AZbv349uw+NEJKUlCQTElAeETZ0=
xuvjLjflUNHX15eTk6P8blMhurvIDLIDOHjwYG5u7ooVKwYGBvjGQCCwdevWoqIigx1VY6JZT=
0KjdwbRK51bZAKPeJA5Zmm66O4iZuWaDjCq2tLS0pqamoLBoM/nc/DZElvC/uWkwuWmHCrq6u=
pmz55tUMDA3cXBI1ZTU1NRUcEcOxiLFi3q7OwMhUL19fWq5QUVymER63EAmmeQyrlFJvBoBpl=
jlqaL7i6ipms6wKhqe/bZZzMyMjIyMlavXu3gEyZWkCtRfaT5mrrYlEOTWbNmbdu2TblFNQIG=
7i4OHivVlLh48WJtbW1ubm5KSkpRUZHf7+fFDPbSrCcOwcQavTPIwLmFBW48XHqDbAz8XgAAw=
DngPlIAAHAO0HQAAHAO0HQAAHAO0HQAbI3dfq+Kpj92i8WRQNMB0CBi9Ym5bBlUGH1b/J5YSu=
mpU6f0LG5kGpW5bkKmw5qeJyrvFIPW+RYZpxTRukfPzMe4LZmrRcS4xLbEeiKwx4GmA6CBSzT=
95ptvfu+99yZPnjxlypR3333X+MJ840ZlOiNTRvQ8Eb1TZOqXcUoRrXs0zXwkYzGOToxLry1l=
PRHY40DTAdBA84wlV1oPrV271uPxJCcn89xK5gJfVX7HnquqqtLS0qZPn97a2kopbW1tLSgoS=
EtLq6qqUtasbF1s6+jRozfffHNqauq0adN4ZmosNIsWLVq9evXUqVM9Hs+aNWsWL16sWY/YH5=
kRE+shhCxfvnz06NE8UgO454mBd0rYPqicUlQFROsecYtmtZobJb9ilXGJbenVI2+PA00HQAO=
981NpPTRmzBiv19vR0dHT0xN2R80CXK+rq6uDwWBNTU1xcTGldMaMGTU1NcFg8JVXXlGWVxkf=
qdoqLy9//fXXQ6HQrl27pk2bJhPm6tWrb7zxxnnz5lVWVt54441r1qzRrEevP6q4VF8zYj3KS=
I3vdFd6nuh5p2j2QeySgVOKaN0jbpFsS3OLcVx6bYn1DMseB5oOgAbieSVaD7399tv33HPPtG=
nTxo4d+8wzz+jtqFez0gopGAxSSoPBYGpqKqU0JSWFbQkEAqyMpvGRqq2UlBQuqZLmSDt27Eh=
KSnrppZf+/Oc/JyUl7dy5U7MesT8yIybWI0aqiZ4vitI7RbIPxk4ponWPuEW+rbCHXhWXXluq=
eoZrjwNNB0AD8fzUsx4aGBjYu3dveno6ezty5MgTJ04Y1KxphfTqq6+y7HXGjBmU0qKiIpYXV=
1dXszKaravaqqioaGxs7O7ulg/z2LFjhJADBw589NFHhBAmAmI9Yn9ExO1iPcpI2V8kIpq+KC=
rvFD2UfZBxShGtewzMfMLGa6zpYlx6bSnricAeB5oOgAbiSoJoPcQ+Yi4fGzduZDsuW7YsLS3=
N4PTWtEJi6+n5+fn79++nlO7fvz8/Pz8tLW358uV6rYttHTt27Pbbb2db+EZjoent7R0zZkxP=
T08oFBozZgxzThXrEfujOWKqLWI9ykj11tNVI3/x4kX2QumdEnYvSqmMHY1o3aNp5qPaS2xL3=
CITl9hW2Jpl7HGg6QDEGWPZBWBYQNMBiDPQdBBDoOkAAOAcoOkAAOAcoOkAAOAcoOkAAOAcoO=
kgMWhsbGxqaurv729qampsbJTcxfhTvQKBQMDn82mWN9gLADsATQeJQWNj4/vvv//ZZ5998ME=
HsVJVvXoOHTokfgQpBwkBNB0kBo2NjceOHfP7/ceOHePyqnrR2NjY3t7u9/uPHj2qt1FVp9jQ=
Dz/80NzcrKnpfr9/z549p06dimlkAMQSaDpIDBobG8+dO8ef+Ubli8bGxu+++y4QCLD7BjU3q=
uoUG/r444+PHz+u+dHg4OCpU6d2794du7AAiDHQdJAYNDY2Dg4OvvPOO4ODg1xw/X5/IBDgKi=
9KvLhRVadmQ3rr5oODg2fOnIGmAzsDTQeJgVJh+eujR4/6/f729vYINF0l3OKn4ovGxsY9e/Z=
88803sQwMgJgCTQcAAOcATQcAAOcATQcAAOcATQcAAOcATQcAAOcATQcAAOfwo6a3tra+AQAA=
IPEhEHQAAHAM/x/Obh51kwBDGgAAAABJRU5ErkJggg=3D=3D" /></p><blockquote style=
=3D"border-left: 2px solid #325FBA; padding-left: 5px;margin-left:5px;">-=
----Urspr&uuml;ngliche Nachricht-----<br /><strong>An:</strong>=09Konrad =
Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;; <br /><strong>CC:</strong>=
=09Sander Eikelenboom &lt;linux@eikelenboom.it&gt;; xen-devel &lt;xen-dev=
el@lists.xensource.com&gt;; Jan Beulich &lt;jbeulich@suse.com&gt;; Konrad=
 Rzeszutek Wilk &lt;konrad@darnok.org&gt;; <br /><strong>Von:</strong>=09=
Carsten Schiers &lt;carsten@schiers.de&gt;<br /><strong>Gesendet:</strong=
>=09Di 28.02.2012 15:39<br /><strong>Betreff:</strong>=09Re: [Xen-devel] =
Load increase after memory upgrade (part2)<br /><strong>Anlage:</strong>=09=
inline.txt<br /><style type=3D"text/css">body { font-family: monospace; }=
</style>               <style type=3D"text/css">       .bodyclass       {=
         font-family: Arial, Verdana, Sans-Serif ! important;         fon=
t-size: 12px;         padding: 5px 5px 5px 5px;         margin: 0px;     =
    border-style: none;         background-color: #ffffff;       }       =
 p, ul, li       {         margin-top: 0px;         margin-bottom: 0px;  =
     }   </style>  <div><p>Well let me check for a longer period of time,=
 and especially, whether the DomU is still</p><p>working (can do that onl=
y from at home), but load looks pretty well after applying the</p><p>patc=
h to 3.2.8 :-D.</p><p>&nbsp;</p><p>BR,</p><p>Carsten.<br />&nbsp;</p><blo=
ckquote style=3D"border-left: 2px solid #325FBA; padding-left: 5px;margin=
-left:5px;">-----Urspr&uuml;ngliche Nachricht-----<br /><strong>An:</stro=
ng>=09Jan Beulich &lt;JBeulich@suse.com&gt;; <br /><strong>CC:</strong>=09=
Konrad Rzeszutek Wilk &lt;konrad@darnok.org&gt;; xen-devel &lt;xen-devel@=
lists.xensource.com&gt;; Carsten Schiers &lt;carsten@schiers.de&gt;; Sand=
er Eikelenboom &lt;linux@eikelenboom.it&gt;; <br /><strong>Von:</strong>=09=
Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;<br /><strong>Gesende=
t:</strong>=09Fr 17.02.2012 16:18<br /><strong>Betreff:</strong>=09Re: [X=
en-devel] Load increase after memory upgrade (part2)<br />On Thu, Feb 16,=
 2012 at 08:56:53AM +0000, Jan Beulich wrote:<br />&gt; &gt;&gt;&gt; On 1=
5.02.12 at 20:28, Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt; wr=
ote:<br />&gt; &gt;@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_nod=
e(struct vm_struct *area, gfp_t gfp_mask,<br />&gt; &gt; =09struct page *=
*pages;<br />&gt; &gt; =09unsigned int nr_pages, array_size, i;<br />&gt;=
 &gt; =09gfp_t nested_gfp =3D (gfp_mask &amp; GFP_RECLAIM_MASK) | __GFP_Z=
ERO;<br />&gt; &gt;-<br />&gt; &gt;+=09gfp_t dma_mask =3D gfp_mask &amp; =
(__GFP_DMA | __GFP_DMA32);<br />&gt; &gt;+=09if (xen_pv_domain()) {<br />=
&gt; &gt;+=09=09if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))<br />&gt; =
<br />&gt; I didn&#39;t spot where you force this normally invalid combin=
ation, without<br />&gt; which the change won&#39;t affect vmalloc32() in=
 a 32-bit kernel.<br />&gt; <br />&gt; &gt;+=09=09=09gfp_mask &amp;=3D (_=
_GFP_DMA | __GFP_DMA32);<br />&gt; <br />&gt; =09=09=09gfp_mask &amp;=3D =
~(__GFP_DMA | __GFP_DMA32);<br />&gt; <br />&gt; Jan<br /><br />Duh!<br /=
>Good eyes. Thanks for catching that.<br /><br />&gt; <br />&gt; &gt;+=09=
}<br />&gt; &gt; =09nr_pages =3D (area-&gt;size - PAGE_SIZE) &gt;&gt; PAG=
E_SHIFT;<br />&gt; &gt; =09array_size =3D (nr_pages * sizeof(struct page =
*));<br />&gt; &gt; <br />&gt; <br /><br />______________________________=
_________________<br />Xen-devel mailing list<br />Xen-devel@lists.xensou=
rce.com<br />http://lists.xensource.com/xen-devel<br /></blockquote></div=
>   </blockquote>=0A</body>=0A</html>
--=_RmxjJNJsrwnVui3cj4DPBppoz3cSlsTnPeMw6PZpGIQPD9Xj--



--===============3070970385178588289==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3070970385178588289==--



From xen-devel-bounces@lists.xen.org Wed Feb 29 12:12:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2iOD-0000or-UU; Wed, 29 Feb 2012 12:12:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2iOC-0000o8-8U
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:12:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330517525!10314942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6117 invoked from network); 29 Feb 2012 12:12:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 12:12:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11007639"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:12:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 12:12:06 +0000
Message-ID: <1330517524.4270.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 12:12:04 +0000
In-Reply-To: <1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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 Tue, 2012-02-28 at 18:27 +0000, David Vrabel wrote:
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 533e702..19b0382 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
>                         unsigned int console_evtchn,
>                         unsigned long *console_mfn);
> 
> -int xc_hvm_build(xc_interface *xch,
> -                 uint32_t domid,
> -                 int memsize,
> -                 const char *image_name);
> +struct xc_hvm_params {
> +    uint64_t mem_size;           /**< Memory size in bytes. */
> +    uint64_t mem_target;         /**< Memory target in bytes. */
> +    const char *image_file_name; /**< File name of the image to load.
> */
> +}; 

Only a minor nit but Xen already has a concept of an "HVM param" which
is something else. Might this be confusing?

What parses that "/**<" syntax? Don't see it anywhere else in the tree
apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:12:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2iOD-0000or-UU; Wed, 29 Feb 2012 12:12:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2iOC-0000o8-8U
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:12:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330517525!10314942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6117 invoked from network); 29 Feb 2012 12:12:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 12:12:06 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11007639"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:12:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 12:12:06 +0000
Message-ID: <1330517524.4270.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 12:12:04 +0000
In-Reply-To: <1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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 Tue, 2012-02-28 at 18:27 +0000, David Vrabel wrote:
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 533e702..19b0382 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
>                         unsigned int console_evtchn,
>                         unsigned long *console_mfn);
> 
> -int xc_hvm_build(xc_interface *xch,
> -                 uint32_t domid,
> -                 int memsize,
> -                 const char *image_name);
> +struct xc_hvm_params {
> +    uint64_t mem_size;           /**< Memory size in bytes. */
> +    uint64_t mem_target;         /**< Memory target in bytes. */
> +    const char *image_file_name; /**< File name of the image to load.
> */
> +}; 

Only a minor nit but Xen already has a concept of an "HVM param" which
is something else. Might this be confusing?

What parses that "/**<" syntax? Don't see it anywhere else in the tree
apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iSc-0001Da-M1; Wed, 29 Feb 2012 12:16:46 +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 1S2iSb-0001DL-80
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:16:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330517746!51912718!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1MDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 369 invoked from network); 29 Feb 2012 12:15:47 -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;
	29 Feb 2012 12:15:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325480400"; d="scan'208";a="183864880"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 07:16:16 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 29 Feb 2012
	07:16:15 -0500
Message-ID: <4F4E170E.4090006@citrix.com>
Date: Wed, 29 Feb 2012 12:16:14 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>	
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
	<1330517524.4270.60.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330517524.4270.60.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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 29/02/12 12:12, Ian Campbell wrote:
> On Tue, 2012-02-28 at 18:27 +0000, David Vrabel wrote:
>> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
>> index 533e702..19b0382 100644
>> --- a/tools/libxc/xenguest.h
>> +++ b/tools/libxc/xenguest.h
>> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
>>                         unsigned int console_evtchn,
>>                         unsigned long *console_mfn);
>>
>> -int xc_hvm_build(xc_interface *xch,
>> -                 uint32_t domid,
>> -                 int memsize,
>> -                 const char *image_name);
>> +struct xc_hvm_params {
>> +    uint64_t mem_size;           /**< Memory size in bytes. */
>> +    uint64_t mem_target;         /**< Memory target in bytes. */
>> +    const char *image_file_name; /**< File name of the image to load.
>> */
>> +}; 
> 
> Only a minor nit but Xen already has a concept of an "HVM param" which
> is something else. Might this be confusing?

Probably.  Suggestions for a better name?  struct xc_hvm_options?

> What parses that "/**<" syntax? Don't see it anywhere else in the tree
> apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.

Doxygen.  I added the markers out of habit.  Shall I remove them?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iSc-0001Da-M1; Wed, 29 Feb 2012 12:16:46 +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 1S2iSb-0001DL-80
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:16:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330517746!51912718!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk1MDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 369 invoked from network); 29 Feb 2012 12:15:47 -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;
	29 Feb 2012 12:15:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325480400"; d="scan'208";a="183864880"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 07:16:16 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 29 Feb 2012
	07:16:15 -0500
Message-ID: <4F4E170E.4090006@citrix.com>
Date: Wed, 29 Feb 2012 12:16:14 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>	
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
	<1330517524.4270.60.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330517524.4270.60.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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 29/02/12 12:12, Ian Campbell wrote:
> On Tue, 2012-02-28 at 18:27 +0000, David Vrabel wrote:
>> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
>> index 533e702..19b0382 100644
>> --- a/tools/libxc/xenguest.h
>> +++ b/tools/libxc/xenguest.h
>> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
>>                         unsigned int console_evtchn,
>>                         unsigned long *console_mfn);
>>
>> -int xc_hvm_build(xc_interface *xch,
>> -                 uint32_t domid,
>> -                 int memsize,
>> -                 const char *image_name);
>> +struct xc_hvm_params {
>> +    uint64_t mem_size;           /**< Memory size in bytes. */
>> +    uint64_t mem_target;         /**< Memory target in bytes. */
>> +    const char *image_file_name; /**< File name of the image to load.
>> */
>> +}; 
> 
> Only a minor nit but Xen already has a concept of an "HVM param" which
> is something else. Might this be confusing?

Probably.  Suggestions for a better name?  struct xc_hvm_options?

> What parses that "/**<" syntax? Don't see it anywhere else in the tree
> apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.

Doxygen.  I added the markers out of habit.  Shall I remove them?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iU3-0001KU-4q; Wed, 29 Feb 2012 12:18:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2iU1-0001K5-PS
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:18:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330517885!11289197!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26199 invoked from network); 29 Feb 2012 12:18:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 12:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11007777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:18:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 12:18:05 +0000
Message-ID: <1330517883.4270.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 12:18:03 +0000
In-Reply-To: <4F4E170E.4090006@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
	<1330517524.4270.60.camel@zakaz.uk.xensource.com>
	<4F4E170E.4090006@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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 Wed, 2012-02-29 at 12:16 +0000, David Vrabel wrote:
> On 29/02/12 12:12, Ian Campbell wrote:
> > On Tue, 2012-02-28 at 18:27 +0000, David Vrabel wrote:
> >> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> >> index 533e702..19b0382 100644
> >> --- a/tools/libxc/xenguest.h
> >> +++ b/tools/libxc/xenguest.h
> >> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
> >>                         unsigned int console_evtchn,
> >>                         unsigned long *console_mfn);
> >>
> >> -int xc_hvm_build(xc_interface *xch,
> >> -                 uint32_t domid,
> >> -                 int memsize,
> >> -                 const char *image_name);
> >> +struct xc_hvm_params {
> >> +    uint64_t mem_size;           /**< Memory size in bytes. */
> >> +    uint64_t mem_target;         /**< Memory target in bytes. */
> >> +    const char *image_file_name; /**< File name of the image to load.
> >> */
> >> +}; 
> > 
> > Only a minor nit but Xen already has a concept of an "HVM param" which
> > is something else. Might this be confusing?
> 
> Probably.  Suggestions for a better name?  struct xc_hvm_options?

strcut xc_hvm_build_params? Consistent with the name of the function?

> > What parses that "/**<" syntax? Don't see it anywhere else in the tree
> > apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.
> 
> Doxygen.  I added the markers out of habit.  Shall I remove them?

I doubt we'll ever use doxygen so if you are resending you may as well.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iU3-0001KU-4q; Wed, 29 Feb 2012 12:18:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2iU1-0001K5-PS
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:18:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330517885!11289197!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26199 invoked from network); 29 Feb 2012 12:18:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 12:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11007777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:18:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 12:18:05 +0000
Message-ID: <1330517883.4270.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 12:18:03 +0000
In-Reply-To: <4F4E170E.4090006@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
	<1330517524.4270.60.camel@zakaz.uk.xensource.com>
	<4F4E170E.4090006@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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 Wed, 2012-02-29 at 12:16 +0000, David Vrabel wrote:
> On 29/02/12 12:12, Ian Campbell wrote:
> > On Tue, 2012-02-28 at 18:27 +0000, David Vrabel wrote:
> >> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> >> index 533e702..19b0382 100644
> >> --- a/tools/libxc/xenguest.h
> >> +++ b/tools/libxc/xenguest.h
> >> @@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
> >>                         unsigned int console_evtchn,
> >>                         unsigned long *console_mfn);
> >>
> >> -int xc_hvm_build(xc_interface *xch,
> >> -                 uint32_t domid,
> >> -                 int memsize,
> >> -                 const char *image_name);
> >> +struct xc_hvm_params {
> >> +    uint64_t mem_size;           /**< Memory size in bytes. */
> >> +    uint64_t mem_target;         /**< Memory target in bytes. */
> >> +    const char *image_file_name; /**< File name of the image to load.
> >> */
> >> +}; 
> > 
> > Only a minor nit but Xen already has a concept of an "HVM param" which
> > is something else. Might this be confusing?
> 
> Probably.  Suggestions for a better name?  struct xc_hvm_options?

strcut xc_hvm_build_params? Consistent with the name of the function?

> > What parses that "/**<" syntax? Don't see it anywhere else in the tree
> > apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.
> 
> Doxygen.  I added the markers out of habit.  Shall I remove them?

I doubt we'll ever use doxygen so if you are resending you may as well.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:21:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iWr-0001aP-PD; Wed, 29 Feb 2012 12:21:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2iWp-0001Zv-I8
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:21:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1330518061!13003092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15221 invoked from network); 29 Feb 2012 12:21:01 -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;
	29 Feb 2012 12:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11007853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:21:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 12:21:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2iWi-0003Kw-V6; Wed, 29 Feb 2012 12:21:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2iWi-0003Dh-U9;
	Wed, 29 Feb 2012 12:21:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.6188.921498.964809@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 12:21:00 +0000
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F4E170E.4090006@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
	<1330517524.4270.60.camel@zakaz.uk.xensource.com>
	<4F4E170E.4090006@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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

David Vrabel writes ("Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to xc_hvm_build() in a structure"):
> On 29/02/12 12:12, Ian Campbell wrote:
> > Only a minor nit but Xen already has a concept of an "HVM param" which
> > is something else. Might this be confusing?
> 
> Probably.  Suggestions for a better name?  struct xc_hvm_options?

Or args maybe.

> > What parses that "/**<" syntax? Don't see it anywhere else in the tree
> > apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.
> 
> Doxygen.  I added the markers out of habit.  Shall I remove them?

Please.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:21:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2iWr-0001aP-PD; Wed, 29 Feb 2012 12:21:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2iWp-0001Zv-I8
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:21:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1330518061!13003092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15221 invoked from network); 29 Feb 2012 12:21:01 -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;
	29 Feb 2012 12:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11007853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:21:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 12:21:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2iWi-0003Kw-V6; Wed, 29 Feb 2012 12:21:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2iWi-0003Dh-U9;
	Wed, 29 Feb 2012 12:21:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.6188.921498.964809@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 12:21:00 +0000
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F4E170E.4090006@citrix.com>
References: <1330453673-8606-1-git-send-email-david.vrabel@citrix.com>
	<1330453673-8606-2-git-send-email-david.vrabel@citrix.com>
	<1330517524.4270.60.camel@zakaz.uk.xensource.com>
	<4F4E170E.4090006@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to
 xc_hvm_build() in a 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

David Vrabel writes ("Re: [Xen-devel] [PATCH 1/2] libxc: pass parameters to xc_hvm_build() in a structure"):
> On 29/02/12 12:12, Ian Campbell wrote:
> > Only a minor nit but Xen already has a concept of an "HVM param" which
> > is something else. Might this be confusing?
> 
> Probably.  Suggestions for a better name?  struct xc_hvm_options?

Or args maybe.

> > What parses that "/**<" syntax? Don't see it anywhere else in the tree
> > apart from tools/libxl/libxlu_disk_l.h etcv which are autogenerated.
> 
> Doxygen.  I added the markers out of habit.  Shall I remove them?

Please.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2irA-00027y-8g; Wed, 29 Feb 2012 12:42:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2ir9-00027s-6U
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 12:42:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330519311!9406953!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyMTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10441 invoked from network); 29 Feb 2012 12:41:52 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-21.messagelabs.com with SMTP;
	29 Feb 2012 12:41:52 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 29 Feb 2012 04:41:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="113045484"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by orsmga001.jf.intel.com with ESMTP; 29 Feb 2012 04:41:50 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 29 Feb 2012 20:41:49 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 20:41:49 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 20:41:47 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM8G9dFE2rD8kEpUevO+lz9U2PUZZINiCAgAunZSA=
Date: Wed, 29 Feb 2012 12:41:47 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350A7F35@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A7F35@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: "Liu, Jinsong" <jinsong.liu@intel.com>, "Li,
	Shaohua" <shaohua.li@intel.com>,
	"'keir.xen@gmail.com'" <keir.xen@gmail.com>,
	'Konrad RzeszutekWilk' <konrad.wilk@oracle.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>> wrote: 
>>> Jan Beulich wrote:
>>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> Core parking is a power control feature and it can co-work with
>>>>> NPTM to control system power budget through online/offline some
>>>>> CPUs in the system. These patches implement core parking feature
>>>>> for xen. They consist of 2 parts: dom0 patches and xen hypervisor
>>>>> patches. 
>>>>> 
>>>>> At dom0 side, patches include
>>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>>> logic, providing a native interface for natvie platform and a
>>>>> paravirt template for paravirt platform, so that os can implicitly
>>>>> hook to proper ops accordingly; [Patch 2/3] redirect paravirt
>>>>> template to Xen pv ops; [Patch 3/3] implement Xen pad logic, and
>>>>> when getting pad device notification, it hypercalls to Xen
>>>>> hypervisor for core parking. Due to the characteristic of xen
>>>>> continue_hypercall_on_cpu, dom0 seperately send/get core parking
>>>>> request/result; 
>>>>> 
>>>>> At Xen hypervisor side, patches include
>>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>>> parking request, and get core parking result;
>>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>>> sequence has different power/performance result, due to cpu
>>>>> socket/core/thread topology. This patch provide power-first and
>>>>> performance-first policies, users can choose core parking policy
>>>>> on their own demand, considering power and performance tradeoff.
>>>> 
>>>> Does this really need to be implemented in the hypervisor? All this
>>>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>>>> have hypercall interfaces already. So I'd rather see this as being
>>>> an extension to Dom0's pCPU management patches (which aren't
>>>> upstream afaict)... 
>>>> 
>>>> Jan
>>> 
>>> It's a design choice. Core parking is not only a wrapper around
>>> cpu_down/up, it also involves policy algorithms which depend on
>>> physical cpu topology and cpu_online/present_map, etc. Implement
>>> core parking at dom0 side need expose all those information to dom0,
>>> with potential issues (like coherence), while dom0 still need do
>>> same work as hypervisor. Our idea is to keep dom0 as ACPI parser,
>>> then hypercall and do rest things at hypervisor side.
>> 
>> Actually, after some more thought, I don't even think this ought to
>> be implemented in the Dom0 kernel, but in user space altogether.
>> Afaict all information necessary is already being exposed.
>> 
> 
> No, user space lack necessary information. If I didn't misunderstand,
> it has some dom0-side dependencies not ready now, like 
> 1. sysfs interface, and exposing xen pcpu topology and maps;
> 2. intecept pad notify and call usermodehelper;
> 3. a daemon to monitor/policy core parking (daemon enable when linux
> run as pvops under xen (kernel acpi_pad disable now), daemon disable
> when linux run under baremetal (kernel acpi_pad enable now))  
> 
> Seems keep same approach as native kernel which handle acpi_pad in
> kernel side (for us, in hypervisor side) is a reasonable choice. Per
> my understanding core parking is a co-work part of NPTM, the whole
> process is basically a remote controller-microengine-bios-kernel
> process, not necessarily involve user action.    
> 

Any comments?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:42:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2irA-00027y-8g; Wed, 29 Feb 2012 12:42:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1S2ir9-00027s-6U
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 12:42:07 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330519311!9406953!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyMTA2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10441 invoked from network); 29 Feb 2012 12:41:52 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-21.messagelabs.com with SMTP;
	29 Feb 2012 12:41:52 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 29 Feb 2012 04:41:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="113045484"
Received: from pgsmsx509.gar.corp.intel.com ([172.30.13.17])
	by orsmga001.jf.intel.com with ESMTP; 29 Feb 2012 04:41:50 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 29 Feb 2012 20:41:49 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 20:41:49 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 20:41:47 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM8G9dFE2rD8kEpUevO+lz9U2PUZZINiCAgAunZSA=
Date: Wed, 29 Feb 2012 12:41:47 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350A7F35@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350A7F35@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: "Liu, Jinsong" <jinsong.liu@intel.com>, "Li,
	Shaohua" <shaohua.li@intel.com>,
	"'keir.xen@gmail.com'" <keir.xen@gmail.com>,
	'Konrad RzeszutekWilk' <konrad.wilk@oracle.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>> wrote: 
>>> Jan Beulich wrote:
>>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> Core parking is a power control feature and it can co-work with
>>>>> NPTM to control system power budget through online/offline some
>>>>> CPUs in the system. These patches implement core parking feature
>>>>> for xen. They consist of 2 parts: dom0 patches and xen hypervisor
>>>>> patches. 
>>>>> 
>>>>> At dom0 side, patches include
>>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>>> logic, providing a native interface for natvie platform and a
>>>>> paravirt template for paravirt platform, so that os can implicitly
>>>>> hook to proper ops accordingly; [Patch 2/3] redirect paravirt
>>>>> template to Xen pv ops; [Patch 3/3] implement Xen pad logic, and
>>>>> when getting pad device notification, it hypercalls to Xen
>>>>> hypervisor for core parking. Due to the characteristic of xen
>>>>> continue_hypercall_on_cpu, dom0 seperately send/get core parking
>>>>> request/result; 
>>>>> 
>>>>> At Xen hypervisor side, patches include
>>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>>> parking request, and get core parking result;
>>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>>> sequence has different power/performance result, due to cpu
>>>>> socket/core/thread topology. This patch provide power-first and
>>>>> performance-first policies, users can choose core parking policy
>>>>> on their own demand, considering power and performance tradeoff.
>>>> 
>>>> Does this really need to be implemented in the hypervisor? All this
>>>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>>>> have hypercall interfaces already. So I'd rather see this as being
>>>> an extension to Dom0's pCPU management patches (which aren't
>>>> upstream afaict)... 
>>>> 
>>>> Jan
>>> 
>>> It's a design choice. Core parking is not only a wrapper around
>>> cpu_down/up, it also involves policy algorithms which depend on
>>> physical cpu topology and cpu_online/present_map, etc. Implement
>>> core parking at dom0 side need expose all those information to dom0,
>>> with potential issues (like coherence), while dom0 still need do
>>> same work as hypervisor. Our idea is to keep dom0 as ACPI parser,
>>> then hypercall and do rest things at hypervisor side.
>> 
>> Actually, after some more thought, I don't even think this ought to
>> be implemented in the Dom0 kernel, but in user space altogether.
>> Afaict all information necessary is already being exposed.
>> 
> 
> No, user space lack necessary information. If I didn't misunderstand,
> it has some dom0-side dependencies not ready now, like 
> 1. sysfs interface, and exposing xen pcpu topology and maps;
> 2. intecept pad notify and call usermodehelper;
> 3. a daemon to monitor/policy core parking (daemon enable when linux
> run as pvops under xen (kernel acpi_pad disable now), daemon disable
> when linux run under baremetal (kernel acpi_pad enable now))  
> 
> Seems keep same approach as native kernel which handle acpi_pad in
> kernel side (for us, in hypervisor side) is a reasonable choice. Per
> my understanding core parking is a co-work part of NPTM, the whole
> process is basically a remote controller-microengine-bios-kernel
> process, not necessarily involve user action.    
> 

Any comments?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:45:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2itz-0002FL-R8; Wed, 29 Feb 2012 12:45:03 +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 1S2ity-0002FE-2d
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:45:02 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330519439!53865905!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19589 invoked from network); 29 Feb 2012 12:44:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 12:44:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2itv-0006Og-43
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:44:59 -0800
Date: Wed, 29 Feb 2012 04:44:59 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330519499118-5524861.post@n5.nabble.com>
In-Reply-To: <1330514555.4270.52.camel@zakaz.uk.xensource.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CklhbiBDYW1wYmVsbC0xMCB3cm90ZQo+IAo+IFRoYXQgc2hvdWxkIGJlIHBvc3NpYmxlLCBidXQg
eW91IGhhdmVuJ3Qgc2hvd24geW91ciBjb2RlIHNvIEkgY2FuJ3Qgc2F5Cj4gd2hlcmUgeW91IGhh
dmUgZ29uZSB3cm9uZy4KPiAKPiBXaGF0IEkgb2Z0ZW4gZG8gaXMgY3JlYXRlIHFlbXUtZGVidWcu
c2g6Cj4gCSMhL2Jpbi9zaAo+IAllY2hvICJTdGFydGluZyBRRU1VIHdpdGg6ICQqIiA+PiAvdG1w
L3FlbXUtZGJnLmxvZwo+IAlleGVjIC91c3IvbGliL3hlbi9iaW4vcWVtdS1zeXN0ZW0taTM4NiAk
QAo+IAo+IEFuZCB0aGVuIHVzaW5nIGRldmljZV9tb2RlbF9vdmVycmlkZSB0byBjYWxsIHRoaXMg
aW5zdGVhZCBvZiBjYWxsaW5nCj4gcWVtdSBkaXJlY3RseS4KPiAKClRoYW5rcyBmb3IgcmVwbHkK
ClF4bCBncmFwaGljIGlzIG5lZWRlZCBmb3IgbWFueSB0aGluZ3Mgd2l0aCBzcGljZSwgSSBzdGFy
dCB0byB0cnkgYWRkIGl0CmZvbGxvd2luZyB0aGlzOiBodHRwOi8vc3BpY2Utc3BhY2Uub3JnL2Rv
Y3Mvc3BpY2VfdXNlcl9tYW51YWwucGRmCgpPbiBsaWJ4bF9kbS5jIGFkZCB0aGlzIGxpbmU6CmZs
ZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1xeGwgMSIpOwpiZWZvcmUgdGhpczoKZmxleGFycmF5
X2FwcGVuZChkbV9hcmdzLCAiLXNwaWNlIik7CgpXaXRoIGRtIG92ZXJyaWRlIGdpdmU6ClN0YXJ0
aW5nIFFFTVUgd2l0aDogLXhlbi1kb21pZCAyMiAtY2hhcmRldgpzb2NrZXQsaWQ9bGlieGwtY21k
LHBhdGg9L3Zhci9ydW4veGVuL3FtcC1saWJ4bC0yMixzZXJ2ZXIsbm93YWl0IC1tb24KY2hhcmRl
dj1saWJ4bC1jbWQsbW9kZT1jb250cm9sIC1uYW1lIFBSRUNJU0VIVk0gLXZuYyAxMjcuMC4wLjE6
MCx0bz05OSAtcXhsCjEgLXNwaWNlIHBvcnQ9NjAwMCx0bHMtcG9ydD0wLGFkZHI9MC4wLjAuMCxw
YXNzd29yZD10ZXN0LGFnZW50LW1vdXNlPW9uCi1ib290IG9yZGVyPWMgLXNtcCAyLG1heGNwdXM9
MyAtZGV2aWNlCnJ0bDgxMzksaWQ9bmljMCxuZXRkZXY9bmV0MCxtYWM9MDA6MTY6M2U6NmI6ODE6
ODkgLW5ldGRldgp0eXBlPXRhcCxpZD1uZXQwLGlmbmFtZT10YXAyMi4wLHNjcmlwdD1ubyAtTSB4
ZW5mdiAtbSAxMDI0IC1kcml2ZQpmaWxlPS9tbnQvdm0vZGlza3MvUFJFQ0lTRUhWTS5kaXNrMS54
bSxpZj1pZGUsaW5kZXg9MCxtZWRpYT1kaXNrLGZvcm1hdD1yYXcKLWRyaXZlIGZpbGU9L2Rldi9z
cjAsaWY9aWRlLGluZGV4PTEsbWVkaWE9Y2Ryb20sZm9ybWF0PXJhdwoKQW5kIG9uIC92YXIvbG9n
L3hlbi9xZW11LWRtLVBSRUNJU0VIVk0ubG9nOgpxZW11LXN5c3RlbS1pMzg2OiAtcXhsOiBpbnZh
bGlkIG9wdGlvbgoKVGhlcmUgaXNuJ3Qgb3RoZXIgLXZnYSBvciAtbm9ncmFwaGljIG9wdGlvbnMs
IEkgbm90IHVuZGVzdGFuZCB0aGUgcHJvYmxlbSwKd2l0aG91dCBxeGwgd29yayBidXQgb24gc3Bp
Y2UgY29ubmVjdCBhbmQgbG9hZCBzZWUgdGhlIGNpcnJ1cyB2aWRlbyBjYXJkLAp2aWRlbyBwZXJm
b3JtYW5jZSBpcyBub3QgZ29vZCBhbmQgaXMgaW1wb3NzaWJsZSByZXNpemUgcmVzb2x1dGlvbiwg
cXhsCmdyYXBoaWMgaXMgbmVlZGVkLgpJIGhhdmUgYWxzbyB0cnkgLXZnYSBxeGwgYnV0IHNhbWUg
cHJvYmxlbS4KCkJlZm9yZSBpIHRyeSB0byBhZGQgcGVybWFudCBkbV9hcmdzIGRlYnVnIG9uIGxv
ZyB3aXRoOgpPbiBsaWJ4bF9kbS5jIGFkZCB0aGlzIGxpbmU6CkxJQlhMX19MT0coY3R4LCBMSUJY
TF9fTE9HX0RFQlVHLCAiZG1fYXJnczogIiwgZmxleGFycmF5X2NvbnRlbnRzKGRtX2FyZ3MpCik7
CmJlZm9yZSB0aGlzOgpyZXR1cm4gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhkbV9hcmdz
KTsKClNob3c6CmxpYnhsX2RtLmM6IEluIGZ1bmN0aW9uIMOibGlieGxfX2J1aWxkX2RldmljZV9t
b2RlbF9hcmdzX25ld8OiOgpsaWJ4bF9kbS5jOjU4MjoyOiBlcnJvcjogdG9vIG1hbnkgYXJndW1l
bnRzIGZvciBmb3JtYXQKWy1XZXJyb3I9Zm9ybWF0LWV4dHJhLWFyZ3NdCmNjMTogYWxsIHdhcm5p
bmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCgoKCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNv
bnRleHQ6IGh0dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL05lZWQtaGVscC13aXRoLXFl
bXUtYXJncy1kZWJ1Zy10cDU1MjQ2ODlwNTUyNDg2MS5odG1sClNlbnQgZnJvbSB0aGUgWGVuIC0g
RGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:45:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2itz-0002FL-R8; Wed, 29 Feb 2012 12:45:03 +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 1S2ity-0002FE-2d
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:45:02 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330519439!53865905!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19589 invoked from network); 29 Feb 2012 12:44:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 12:44:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2itv-0006Og-43
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 04:44:59 -0800
Date: Wed, 29 Feb 2012 04:44:59 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330519499118-5524861.post@n5.nabble.com>
In-Reply-To: <1330514555.4270.52.camel@zakaz.uk.xensource.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CklhbiBDYW1wYmVsbC0xMCB3cm90ZQo+IAo+IFRoYXQgc2hvdWxkIGJlIHBvc3NpYmxlLCBidXQg
eW91IGhhdmVuJ3Qgc2hvd24geW91ciBjb2RlIHNvIEkgY2FuJ3Qgc2F5Cj4gd2hlcmUgeW91IGhh
dmUgZ29uZSB3cm9uZy4KPiAKPiBXaGF0IEkgb2Z0ZW4gZG8gaXMgY3JlYXRlIHFlbXUtZGVidWcu
c2g6Cj4gCSMhL2Jpbi9zaAo+IAllY2hvICJTdGFydGluZyBRRU1VIHdpdGg6ICQqIiA+PiAvdG1w
L3FlbXUtZGJnLmxvZwo+IAlleGVjIC91c3IvbGliL3hlbi9iaW4vcWVtdS1zeXN0ZW0taTM4NiAk
QAo+IAo+IEFuZCB0aGVuIHVzaW5nIGRldmljZV9tb2RlbF9vdmVycmlkZSB0byBjYWxsIHRoaXMg
aW5zdGVhZCBvZiBjYWxsaW5nCj4gcWVtdSBkaXJlY3RseS4KPiAKClRoYW5rcyBmb3IgcmVwbHkK
ClF4bCBncmFwaGljIGlzIG5lZWRlZCBmb3IgbWFueSB0aGluZ3Mgd2l0aCBzcGljZSwgSSBzdGFy
dCB0byB0cnkgYWRkIGl0CmZvbGxvd2luZyB0aGlzOiBodHRwOi8vc3BpY2Utc3BhY2Uub3JnL2Rv
Y3Mvc3BpY2VfdXNlcl9tYW51YWwucGRmCgpPbiBsaWJ4bF9kbS5jIGFkZCB0aGlzIGxpbmU6CmZs
ZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1xeGwgMSIpOwpiZWZvcmUgdGhpczoKZmxleGFycmF5
X2FwcGVuZChkbV9hcmdzLCAiLXNwaWNlIik7CgpXaXRoIGRtIG92ZXJyaWRlIGdpdmU6ClN0YXJ0
aW5nIFFFTVUgd2l0aDogLXhlbi1kb21pZCAyMiAtY2hhcmRldgpzb2NrZXQsaWQ9bGlieGwtY21k
LHBhdGg9L3Zhci9ydW4veGVuL3FtcC1saWJ4bC0yMixzZXJ2ZXIsbm93YWl0IC1tb24KY2hhcmRl
dj1saWJ4bC1jbWQsbW9kZT1jb250cm9sIC1uYW1lIFBSRUNJU0VIVk0gLXZuYyAxMjcuMC4wLjE6
MCx0bz05OSAtcXhsCjEgLXNwaWNlIHBvcnQ9NjAwMCx0bHMtcG9ydD0wLGFkZHI9MC4wLjAuMCxw
YXNzd29yZD10ZXN0LGFnZW50LW1vdXNlPW9uCi1ib290IG9yZGVyPWMgLXNtcCAyLG1heGNwdXM9
MyAtZGV2aWNlCnJ0bDgxMzksaWQ9bmljMCxuZXRkZXY9bmV0MCxtYWM9MDA6MTY6M2U6NmI6ODE6
ODkgLW5ldGRldgp0eXBlPXRhcCxpZD1uZXQwLGlmbmFtZT10YXAyMi4wLHNjcmlwdD1ubyAtTSB4
ZW5mdiAtbSAxMDI0IC1kcml2ZQpmaWxlPS9tbnQvdm0vZGlza3MvUFJFQ0lTRUhWTS5kaXNrMS54
bSxpZj1pZGUsaW5kZXg9MCxtZWRpYT1kaXNrLGZvcm1hdD1yYXcKLWRyaXZlIGZpbGU9L2Rldi9z
cjAsaWY9aWRlLGluZGV4PTEsbWVkaWE9Y2Ryb20sZm9ybWF0PXJhdwoKQW5kIG9uIC92YXIvbG9n
L3hlbi9xZW11LWRtLVBSRUNJU0VIVk0ubG9nOgpxZW11LXN5c3RlbS1pMzg2OiAtcXhsOiBpbnZh
bGlkIG9wdGlvbgoKVGhlcmUgaXNuJ3Qgb3RoZXIgLXZnYSBvciAtbm9ncmFwaGljIG9wdGlvbnMs
IEkgbm90IHVuZGVzdGFuZCB0aGUgcHJvYmxlbSwKd2l0aG91dCBxeGwgd29yayBidXQgb24gc3Bp
Y2UgY29ubmVjdCBhbmQgbG9hZCBzZWUgdGhlIGNpcnJ1cyB2aWRlbyBjYXJkLAp2aWRlbyBwZXJm
b3JtYW5jZSBpcyBub3QgZ29vZCBhbmQgaXMgaW1wb3NzaWJsZSByZXNpemUgcmVzb2x1dGlvbiwg
cXhsCmdyYXBoaWMgaXMgbmVlZGVkLgpJIGhhdmUgYWxzbyB0cnkgLXZnYSBxeGwgYnV0IHNhbWUg
cHJvYmxlbS4KCkJlZm9yZSBpIHRyeSB0byBhZGQgcGVybWFudCBkbV9hcmdzIGRlYnVnIG9uIGxv
ZyB3aXRoOgpPbiBsaWJ4bF9kbS5jIGFkZCB0aGlzIGxpbmU6CkxJQlhMX19MT0coY3R4LCBMSUJY
TF9fTE9HX0RFQlVHLCAiZG1fYXJnczogIiwgZmxleGFycmF5X2NvbnRlbnRzKGRtX2FyZ3MpCik7
CmJlZm9yZSB0aGlzOgpyZXR1cm4gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhkbV9hcmdz
KTsKClNob3c6CmxpYnhsX2RtLmM6IEluIGZ1bmN0aW9uIMOibGlieGxfX2J1aWxkX2RldmljZV9t
b2RlbF9hcmdzX25ld8OiOgpsaWJ4bF9kbS5jOjU4MjoyOiBlcnJvcjogdG9vIG1hbnkgYXJndW1l
bnRzIGZvciBmb3JtYXQKWy1XZXJyb3I9Zm9ybWF0LWV4dHJhLWFyZ3NdCmNjMTogYWxsIHdhcm5p
bmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCgoKCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNv
bnRleHQ6IGh0dHA6Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL05lZWQtaGVscC13aXRoLXFl
bXUtYXJncy1kZWJ1Zy10cDU1MjQ2ODlwNTUyNDg2MS5odG1sClNlbnQgZnJvbSB0aGUgWGVuIC0g
RGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:51:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2izv-0002ZA-Ll; Wed, 29 Feb 2012 12:51:11 +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 1S2izt-0002Z5-7u
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 12:51:09 +0000
Received: from [85.158.139.83:64768] by server-9.bemta-5.messagelabs.com id
	A7/5E-09826-C3F1E4F4; Wed, 29 Feb 2012 12:51:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330519866!17232040!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1NzI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7705 invoked from network); 29 Feb 2012 12:51:06 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-182.messagelabs.com with SMTP;
	29 Feb 2012 12:51:06 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 29 Feb 2012 04:51:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112741049"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by azsmga001.ch.intel.com with ESMTP; 29 Feb 2012 04:50:56 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 20:47:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 20:47:43 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM8G9dFE2rD8kEpUevO+lz9U2PUZZINiCAgAunZSCAAAEtIA==
Date: Wed, 29 Feb 2012 12:47:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BC845@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350A7F35@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BC806@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_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"'keir.xen@gmail.com'" <keir.xen@gmail.com>,
	'Konrad RzeszutekWilk' <konrad.wilk@oracle.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Liu, Jinsong wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote:
>>>> Jan Beulich wrote:
>>>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>> wrote:
>>>>>> Core parking is a power control feature and it can co-work with
>>>>>> NPTM to control system power budget through online/offline some
>>>>>> CPUs in the system. These patches implement core parking feature
>>>>>> for xen. They consist of 2 parts: dom0 patches and xen
>>>>>> hypervisor patches.=20
>>>>>>=20
>>>>>> At dom0 side, patches include
>>>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>>>> logic, providing a native interface for natvie platform and a
>>>>>> paravirt template for paravirt platform, so that os can
>>>>>> implicitly hook to proper ops accordingly; [Patch 2/3] redirect
>>>>>> paravirt template to Xen pv ops; [Patch 3/3] implement Xen pad
>>>>>> logic, and when getting pad device notification, it hypercalls
>>>>>> to Xen hypervisor for core parking. Due to the characteristic of
>>>>>> xen continue_hypercall_on_cpu, dom0 seperately send/get core
>>>>>> parking request/result;=20
>>>>>>=20
>>>>>> At Xen hypervisor side, patches include
>>>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>>>> parking request, and get core parking result;
>>>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>>>> sequence has different power/performance result, due to cpu
>>>>>> socket/core/thread topology. This patch provide power-first and
>>>>>> performance-first policies, users can choose core parking policy
>>>>>> on their own demand, considering power and performance tradeoff.
>>>>>=20
>>>>> Does this really need to be implemented in the hypervisor? All
>>>>> this boils down to is a wrapper around cpu_down() and cpu_up(),
>>>>> which have hypercall interfaces already. So I'd rather see this
>>>>> as being an extension to Dom0's pCPU management patches (which
>>>>> aren't upstream afaict)...=20
>>>>>=20
>>>>> Jan
>>>>=20
>>>> It's a design choice. Core parking is not only a wrapper around
>>>> cpu_down/up, it also involves policy algorithms which depend on
>>>> physical cpu topology and cpu_online/present_map, etc. Implement
>>>> core parking at dom0 side need expose all those information to
>>>> dom0, with potential issues (like coherence), while dom0 still
>>>> need do same work as hypervisor. Our idea is to keep dom0 as ACPI
>>>> parser, then hypercall and do rest things at hypervisor side.
>>>=20
>>> Actually, after some more thought, I don't even think this ought to
>>> be implemented in the Dom0 kernel, but in user space altogether.
>>> Afaict all information necessary is already being exposed.
>>>=20
>>=20
>> No, user space lack necessary information. If I didn't misunderstand,
>> it has some dom0-side dependencies not ready now, like
>> 1. sysfs interface, and exposing xen pcpu topology and maps;
>> 2. intecept pad notify and call usermodehelper;
>> 3. a daemon to monitor/policy core parking (daemon enable when linux
>> run as pvops under xen (kernel acpi_pad disable now), daemon disable
>> when linux run under baremetal (kernel acpi_pad enable now))
>>=20
>> Seems keep same approach as native kernel which handle acpi_pad in
>> kernel side (for us, in hypervisor side) is a reasonable choice. Per
>> my understanding core parking is a co-work part of NPTM, the whole
>> process is basically a remote controller-microengine-bios-kernel
>> process, not necessarily involve user action.
>>=20
>=20
> Any comments?
>=20

Sorry, forgot to re-attach patches :-)


--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_1.patch"
Content-Description: xen_core_parking_1.patch
Content-Disposition: attachment; filename="xen_core_parking_1.patch";
	size=3395; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Mon, 13 Feb 2012 16:41:16 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAxOiBoeXBlcmNhbGwKClRoaXMgcGF0Y2ggaW1wbGVtZW50IGh5cGVy
Y2FsbCB0aHJvdWdoIHdoaWNoIGRvbTAgc2VuZCBjb3JlIHBhcmtpbmcgcmVxdWVzdCwgYW5kIGdl
dCBjb3JlIHBhcmtpbmcgcmVzdWx0LgpEdWUgdG8gdGhlIGNoYXJhY3RlcmlzdGljIG9mIGNvbnRp
bnVlX2h5cGVyY2FsbF9vbl9jcHUsIGRvbTAgc2VwZXJhdGVseSBzZW5kL2dldCBjb3JlIHBhcmtp
bmcgcmVxdWVzdC9yZXN1bHQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcu
bGl1QGludGVsLmNvbT4KCmRpZmYgLXIgOTJlMDMzMTA4NzhmIHhlbi9hcmNoL3g4Ni9wbGF0Zm9y
bV9oeXBlcmNhbGwuYwotLS0gYS94ZW4vYXJjaC94ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMJV2Vk
IEZlYiAwOCAyMTowNTo1MiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9o
eXBlcmNhbGwuYwlNb24gRmViIDEzIDExOjMzOjE2IDIwMTIgKzA4MDAKQEAgLTU2LDYgKzU2LDEw
IEBACiBsb25nIGNwdV91cF9oZWxwZXIodm9pZCAqZGF0YSk7CiBsb25nIGNwdV9kb3duX2hlbHBl
cih2b2lkICpkYXRhKTsKIAorLyogZnJvbSBjb3JlX3BhcmtpbmcuYyAqLworbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpOwordWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9p
ZCk7CisKIHJldF90IGRvX3BsYXRmb3JtX29wKFhFTl9HVUVTVF9IQU5ETEUoeGVuX3BsYXRmb3Jt
X29wX3QpIHVfeGVucGZfb3ApCiB7CiAgICAgcmV0X3QgcmV0ID0gMDsKQEAgLTU5Myw2ICs1OTcs
MzIgQEAKICAgICAgICAgICAgICAgICAgICAgICBvcC0+dS5tZW1fYWRkLmVwZm4sCiAgICAgICAg
ICAgICAgICAgICAgICAgb3AtPnUubWVtX2FkZC5weG0pOwogICAgICAgICBicmVhazsKKworICAg
IGNhc2UgWEVOUEZfY29yZV9wYXJraW5nOgorICAgIHsKKyAgICAgICAgdWludDMyX3QgaWRsZV9u
dW1zOworCisgICAgICAgIHN3aXRjaChvcC0+dS5jb3JlX3BhcmtpbmcudHlwZSkKKyAgICAgICAg
eworICAgICAgICBjYXNlIFhFTl9DT1JFX1BBUktJTkdfU0VUOgorICAgICAgICAgICAgaWRsZV9u
dW1zID0gbWluX3QodWludDMyX3QsCisgICAgICAgICAgICAgICAgICAgIG9wLT51LmNvcmVfcGFy
a2luZy5pZGxlX251bXMsIG51bV9wcmVzZW50X2NwdXMoKSAtIDEpOworICAgICAgICAgICAgcmV0
ID0gY29udGludWVfaHlwZXJjYWxsX29uX2NwdSgKKyAgICAgICAgICAgICAgICAgICAgMCwgY29y
ZV9wYXJraW5nX2hlbHBlciwgKHZvaWQgKikodW5zaWduZWQgbG9uZylpZGxlX251bXMpOworICAg
ICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgY2FzZSBYRU5fQ09SRV9QQVJLSU5HX0dFVDoKKyAg
ICAgICAgICAgIG9wLT51LmNvcmVfcGFya2luZy5pZGxlX251bXMgPSBnZXRfY3VyX2lkbGVfbnVt
cygpOworICAgICAgICAgICAgcmV0ID0gY29weV90b19ndWVzdCh1X3hlbnBmX29wLCBvcCwgMSkg
PyAtRUZBVUxUIDogMDsKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIGRlZmF1bHQ6Cisg
ICAgICAgICAgICByZXQgPSAtRUlOVkFMOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIH0K
KyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSAtRU5PU1lT
OwogICAgICAgICBicmVhazsKZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9NYWtlZmls
ZQotLS0gYS94ZW4vY29tbW9uL01ha2VmaWxlCVdlZCBGZWIgMDggMjE6MDU6NTIgMjAxMiArMDgw
MAorKysgYi94ZW4vY29tbW9uL01ha2VmaWxlCU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgw
MApAQCAtMSw2ICsxLDcgQEAKIG9iai15ICs9IGJpdG1hcC5vCiBvYmoteSArPSBjcHUubwogb2Jq
LXkgKz0gY3B1cG9vbC5vCitvYmoteSArPSBjb3JlX3Bhcmtpbmcubwogb2JqLXkgKz0gZG9tY3Rs
Lm8KIG9iai15ICs9IGRvbWFpbi5vCiBvYmoteSArPSBldmVudF9jaGFubmVsLm8KZGlmZiAtciA5
MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5j
CU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtMCwwICsxLDEzIEBACisjaW5jbHVk
ZSA8eGVuL3R5cGVzLmg+CisKK3N0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOworCitsb25n
IGNvcmVfcGFya2luZ19oZWxwZXIodm9pZCAqZGF0YSkKK3sKKyAgICByZXR1cm4gMDsKK30KKwor
dWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9pZCkKK3sKKyAgICByZXR1cm4gY3VyX2lkbGVf
bnVtczsKK30KZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3Jt
LmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3JtLmgJV2VkIEZlYiAwOCAyMTowNTo1
MiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9wbGF0Zm9ybS5oCU1vbiBGZWIg
MTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtNDkwLDYgKzQ5MCwyMCBAQAogICAgIHVpbnQzMl90
IGZsYWdzOwogfTsKIAorI2RlZmluZSBYRU5QRl9jb3JlX3BhcmtpbmcgIDYwCisKKyNkZWZpbmUg
WEVOX0NPUkVfUEFSS0lOR19TRVQgMQorI2RlZmluZSBYRU5fQ09SRV9QQVJLSU5HX0dFVCAyCitz
dHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nIHsKKyAgICAvKiBJTiB2YXJpYWJsZXMgKi8KKyAgICB1
aW50MzJfdCB0eXBlOworICAgIC8qIElOIHZhcmlhYmxlczogIHNldCBjcHUgbnVtcyBleHBlY3Rl
ZCB0byBiZSBpZGxlZCAqLworICAgIC8qIE9VVCB2YXJpYWJsZXM6IGdldCBjcHUgbnVtcyBhY3R1
YWxseSBiZSBpZGxlZCAqLworICAgIHVpbnQzMl90IGlkbGVfbnVtczsKK307Cit0eXBlZGVmIHN0
cnVjdCB4ZW5wZl9jb3JlX3BhcmtpbmcgeGVucGZfY29yZV9wYXJraW5nX3Q7CitERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5wZl9jb3JlX3BhcmtpbmdfdCk7CisKIHN0cnVjdCB4ZW5fcGxhdGZv
cm1fb3AgewogICAgIHVpbnQzMl90IGNtZDsKICAgICB1aW50MzJfdCBpbnRlcmZhY2VfdmVyc2lv
bjsgLyogWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAgLTUxMSw2ICs1MjUsNyBAQAogICAg
ICAgICBzdHJ1Y3QgeGVucGZfY3B1X29sICAgICAgICAgICAgY3B1X29sOwogICAgICAgICBzdHJ1
Y3QgeGVucGZfY3B1X2hvdGFkZCAgICAgICAgY3B1X2FkZDsKICAgICAgICAgc3RydWN0IHhlbnBm
X21lbV9ob3RhZGQgICAgICAgIG1lbV9hZGQ7CisgICAgICAgIHN0cnVjdCB4ZW5wZl9jb3JlX3Bh
cmtpbmcgICAgICBjb3JlX3Bhcmtpbmc7CiAgICAgICAgIHVpbnQ4X3QgICAgICAgICAgICAgICAg
ICAgICAgICBwYWRbMTI4XTsKICAgICB9IHU7CiB9Owo=

--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_2.patch"
Content-Description: xen_core_parking_2.patch
Content-Disposition: attachment; filename="xen_core_parking_2.patch";
	size=7292; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Thu, 16 Feb 2012 15:39:58 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAyOiBjb3JlIHBhcmtpbmcgaW1wbGVtZW50YXRpb24KClRoaXMgcGF0
Y2ggaW1wbGVtZW50IFhlbiBjb3JlIHBhcmtpbmcuCkRpZmZlcmVudCBjb3JlIHBhcmtpbmcgc2Vx
dWVuY2UgaGFzIGRpZmZlcmVudCBwb3dlci9wZXJmb3JtYW5jZSByZXN1bHQsIGR1ZSB0byBjcHUg
c29ja2V0L2NvcmUvdGhyZWFkIHRvcG9sb2d5LgpUaGlzIHBhdGNoIHByb3ZpZGUgcG93ZXItZmly
c3QgYW5kIHBlcmZvcm1hbmNlLWZpcnN0IHBvbGljaWVzLCB1c2VycyBjYW4gY2hvb3NlIGNvcmUg
cGFya2luZyBwb2xpY3kgYnkgdGhlaXIgb3duIGRlbWFuZC4KClNpZ25lZC1vZmYtYnk6IExpdSwg
Smluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciAzOTJlNzcxNzFkNzQgeGVu
L2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gYS94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5jCU1v
biBGZWIgMTMgMTE6MzM6MTcgMjAxMiArMDgwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2lu
Zy5jCVRodSBGZWIgMTYgMjM6Mzk6NTcgMjAxMiArMDgwMApAQCAtMSwxMyArMSwyNDAgQEAKKy8q
CisgKiAgY29yZV9wYXJraW5nLmMgLSBpbXBsZW1lbnQgY29yZSBwYXJraW5nIGFjY29yZGluZyB0
byBkb20wIHJlcXVpcmVtZW50CisgKgorICogIENvcHlyaWdodCAoQykgMjAxMiwgSW50ZWwgQ29y
cG9yYXRpb24uCisgKiAgICAgQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KKyAqCisgKiAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVk
aXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICogIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9y
IChhdAorICogIHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAqCisgKiAgVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWws
IGJ1dAorICogIFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQg
d2FycmFudHkgb2YKKyAqICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorICogIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9y
IG1vcmUgZGV0YWlscy4KKyAqLworCiAjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8
eGVuL2NwdS5oPgorI2luY2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL2NwdW1hc2su
aD4KKyNpbmNsdWRlIDxhc20vcGVyY3B1Lmg+CisjaW5jbHVkZSA8YXNtL3NtcC5oPgorCisjZGVm
aW5lIENPUkVfUEFSS0lOR19JTkNSRU1FTlQgMQorI2RlZmluZSBDT1JFX1BBUktJTkdfREVDUkVN
RU5UIDIKKworc3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQg
aW50IGV2ZW50KTsKK3N0YXRpYyB1bnNpZ25lZCBpbnQgY29yZV9wYXJraW5nX3BlcmZvcm1hbmNl
KHVuc2lnbmVkIGludCBldmVudCk7CiAKIHN0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOwor
c3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfY3B1bnVtW05SX0NQVVNdID0ge1swIC4u
LiBOUl9DUFVTLTFdID0gLTF9OworCitzdGF0aWMgc3RydWN0IGNvcmVfcGFya2luZ19wb2xpY3kg
eworICAgIGNoYXIgbmFtZVszMF07CisgICAgdW5zaWduZWQgaW50ICgqbmV4dCkodW5zaWduZWQg
aW50IGV2ZW50KTsKK30gKmNvcmVfcGFya2luZ19wb2xpY3k7CisKK3N0YXRpYyBlbnVtIGNvcmVf
cGFya2luZ19jb250cm9sbGVyIHsKKyAgICBQT1dFUl9GSVJTVCwKKyAgICBQRVJGT1JNQU5DRV9G
SVJTVAorfSBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBPV0VSX0ZJUlNUOworCitzdGF0aWMg
dm9pZCBfX2luaXQgc2V0dXBfY29yZV9wYXJraW5nX29wdGlvbihjaGFyICpzdHIpCit7CisgICAg
aWYgKCAhc3RyY21wKHN0ciwgInBvd2VyIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJv
bGxlciA9IFBPV0VSX0ZJUlNUOworICAgIGVsc2UgaWYgKCAhc3RyY21wKHN0ciwgInBlcmZvcm1h
bmNlIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBFUkZPUk1BTkNFX0ZJ
UlNUOworICAgIGVsc2UKKyAgICAgICAgcmV0dXJuOworfQorY3VzdG9tX3BhcmFtKCJjb3JlX3Bh
cmtpbmciLCBzZXR1cF9jb3JlX3Bhcmtpbmdfb3B0aW9uKTsKKworc3RhdGljIHVuc2lnbmVkIGlu
dCBjb3JlX3BhcmtpbmdfcGVyZm9ybWFuY2UodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVu
c2lnbmVkIGludCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAg
Y2FzZSBDT1JFX1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1w
LCBjb3JlX3dlaWdodCA9IC0xOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gLTE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAsIHNpYmxpbmdf
Y2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFw
KTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKworICAg
ICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVlOworCisgICAg
ICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2NvcmVfbWFzaywg
Y3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0IDwgY29yZV90bXAgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7CisgICAgICAg
ICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
ICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3JlX3RtcCApCisg
ICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlkYXRlX21hcCk7
CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVf
bWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1hc2tfd2VpZ2h0
KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIHNpYmxp
bmdfd2VpZ2h0IDwgc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
IHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAgY3B1bWFza19j
bGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBjcHVtYXNrX3Nl
dF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCApCisgICAgICAg
ICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRlX21hcCk7Cisg
ICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5nX2NhbmRpZGF0
ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJLSU5HX0RFQ1JF
TUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1bY3VyX2lkbGVf
bnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAgICAgICAgYnJl
YWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KKworc3RhdGljIHVuc2lnbmVkIGludCBj
b3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVuc2lnbmVkIGlu
dCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAgY2FzZSBDT1JF
X1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1wLCBjb3JlX3dl
aWdodCA9IE5SX0NQVVMgKyAxOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gTlJfQ1BVUyArIDE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAs
IHNpYmxpbmdfY2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5k
aWRhdGVfbWFwKTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFw
KTsKKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVl
OworCisgICAgICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2Nv
cmVfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0ID4gY29yZV90bXAg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7
CisgICAgICAgICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAg
ICAgICAgICAgICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsK
KyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3Jl
X3RtcCApCisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlk
YXRlX21hcCk7CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9j
YW5kaWRhdGVfbWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1h
c2tfd2VpZ2h0KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBp
ZiAoIHNpYmxpbmdfd2VpZ2h0ID4gc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAg
ICAgICAgICAgIHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAg
Y3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBj
cHVtYXNrX3NldF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
IH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCAp
CisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRl
X21hcCk7CisgICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5n
X2NhbmRpZGF0ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJL
SU5HX0RFQ1JFTUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1b
Y3VyX2lkbGVfbnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAg
ICAgICAgYnJlYWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KIAogbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpCiB7Ci0gICAgcmV0dXJuIDA7CisgICAgdWludDMyX3Qg
aWRsZV9udW1zID0gKHVuc2lnbmVkIGxvbmcpZGF0YTsKKyAgICB1bnNpZ25lZCBpbnQgY3B1Owor
ICAgIGludCByZXQgPSAwOworCisgICAgaWYgKCAhY29yZV9wYXJraW5nX3BvbGljeSApCisgICAg
ICAgIHJldHVybiAtRUlOVkFMOworCisgICAgd2hpbGUgKCBjdXJfaWRsZV9udW1zIDwgaWRsZV9u
dW1zICkKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19wb2xpY3ktPm5leHQoQ09S
RV9QQVJLSU5HX0lOQ1JFTUVOVCk7CisgICAgICAgIHJldCA9IGNwdV9kb3duKGNwdSk7CisgICAg
ICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiByZXQ7CisgICAgICAgIGNvcmVfcGFy
a2luZ19jcHVudW1bY3VyX2lkbGVfbnVtcysrXSA9IGNwdTsKKyAgICB9CisKKyAgICB3aGlsZSAo
IGN1cl9pZGxlX251bXMgPiBpZGxlX251bXMgKQorICAgIHsKKyAgICAgICAgY3B1ID0gY29yZV9w
YXJraW5nX3BvbGljeS0+bmV4dChDT1JFX1BBUktJTkdfREVDUkVNRU5UKTsKKyAgICAgICAgcmV0
ID0gY3B1X3VwKGNwdSk7CisgICAgICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiBy
ZXQ7CisgICAgICAgIGNvcmVfcGFya2luZ19jcHVudW1bLS1jdXJfaWRsZV9udW1zXSA9IC0xOwor
ICAgIH0KKworICAgIHJldHVybiByZXQ7CiB9CiAKIHVpbnQzMl90IGdldF9jdXJfaWRsZV9udW1z
KHZvaWQpCiB7CiAgICAgcmV0dXJuIGN1cl9pZGxlX251bXM7CiB9CisKK3N0YXRpYyBzdHJ1Y3Qg
Y29yZV9wYXJraW5nX3BvbGljeSBwb3dlcl9maXJzdCA9IHsKKyAgICAubmFtZSA9ICJwb3dlciIs
CisgICAgLm5leHQgPSBjb3JlX3BhcmtpbmdfcG93ZXIsCit9OworCitzdGF0aWMgc3RydWN0IGNv
cmVfcGFya2luZ19wb2xpY3kgcGVyZm9ybWFuY2VfZmlyc3QgPSB7CisgICAgLm5hbWUgPSAicGVy
Zm9ybWFuY2UiLAorICAgIC5uZXh0ID0gY29yZV9wYXJraW5nX3BlcmZvcm1hbmNlLAorfTsKKwor
c3RhdGljIGludCByZWdpc3Rlcl9jb3JlX3BhcmtpbmdfcG9saWN5KHN0cnVjdCBjb3JlX3Bhcmtp
bmdfcG9saWN5ICpwb2xpY3kpCit7CisgICAgaWYgKCAhcG9saWN5IHx8ICFwb2xpY3ktPm5leHQg
KQorICAgICAgICByZXR1cm4gLUVJTlZBTDsKKworICAgIGNvcmVfcGFya2luZ19wb2xpY3kgPSBw
b2xpY3k7CisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IGNvcmVfcGFya2lu
Z19pbml0KHZvaWQpCit7CisgICAgaW50IHJldCA9IDA7CisKKyAgICBpZiAoIGNvcmVfcGFya2lu
Z19jb250cm9sbGVyID09IFBFUkZPUk1BTkNFX0ZJUlNUICkKKyAgICAgICAgcmV0ID0gcmVnaXN0
ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcGVyZm9ybWFuY2VfZmlyc3QpOworICAgIGVsc2UKKyAg
ICAgICAgcmV0ID0gcmVnaXN0ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcG93ZXJfZmlyc3QpOwor
CisgICAgcmV0dXJuIHJldDsKK30KK19faW5pdGNhbGwoY29yZV9wYXJraW5nX2luaXQpOwo=

--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 29 12:51:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2izv-0002ZA-Ll; Wed, 29 Feb 2012 12:51:11 +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 1S2izt-0002Z5-7u
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 12:51:09 +0000
Received: from [85.158.139.83:64768] by server-9.bemta-5.messagelabs.com id
	A7/5E-09826-C3F1E4F4; Wed, 29 Feb 2012 12:51:08 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330519866!17232040!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1NzI2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7705 invoked from network); 29 Feb 2012 12:51:06 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-182.messagelabs.com with SMTP;
	29 Feb 2012 12:51:06 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 29 Feb 2012 04:51:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112741049"
Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80])
	by azsmga001.ch.intel.com with ESMTP; 29 Feb 2012 04:50:56 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 29 Feb 2012 20:47:45 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.142]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id
	14.01.0355.002; Wed, 29 Feb 2012 20:47:43 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Thread-Topic: Core parking feature enable
Thread-Index: AQHM8G9dFE2rD8kEpUevO+lz9U2PUZZINiCAgAunZSCAAAEtIA==
Date: Wed, 29 Feb 2012 12:47:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350BC845@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350A7F35@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BC806@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_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"'keir.xen@gmail.com'" <keir.xen@gmail.com>,
	'Konrad RzeszutekWilk' <konrad.wilk@oracle.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Liu, Jinsong wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote:
>>>> Jan Beulich wrote:
>>>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>> wrote:
>>>>>> Core parking is a power control feature and it can co-work with
>>>>>> NPTM to control system power budget through online/offline some
>>>>>> CPUs in the system. These patches implement core parking feature
>>>>>> for xen. They consist of 2 parts: dom0 patches and xen
>>>>>> hypervisor patches.=20
>>>>>>=20
>>>>>> At dom0 side, patches include
>>>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>>>> logic, providing a native interface for natvie platform and a
>>>>>> paravirt template for paravirt platform, so that os can
>>>>>> implicitly hook to proper ops accordingly; [Patch 2/3] redirect
>>>>>> paravirt template to Xen pv ops; [Patch 3/3] implement Xen pad
>>>>>> logic, and when getting pad device notification, it hypercalls
>>>>>> to Xen hypervisor for core parking. Due to the characteristic of
>>>>>> xen continue_hypercall_on_cpu, dom0 seperately send/get core
>>>>>> parking request/result;=20
>>>>>>=20
>>>>>> At Xen hypervisor side, patches include
>>>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>>>> parking request, and get core parking result;
>>>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>>>> sequence has different power/performance result, due to cpu
>>>>>> socket/core/thread topology. This patch provide power-first and
>>>>>> performance-first policies, users can choose core parking policy
>>>>>> on their own demand, considering power and performance tradeoff.
>>>>>=20
>>>>> Does this really need to be implemented in the hypervisor? All
>>>>> this boils down to is a wrapper around cpu_down() and cpu_up(),
>>>>> which have hypercall interfaces already. So I'd rather see this
>>>>> as being an extension to Dom0's pCPU management patches (which
>>>>> aren't upstream afaict)...=20
>>>>>=20
>>>>> Jan
>>>>=20
>>>> It's a design choice. Core parking is not only a wrapper around
>>>> cpu_down/up, it also involves policy algorithms which depend on
>>>> physical cpu topology and cpu_online/present_map, etc. Implement
>>>> core parking at dom0 side need expose all those information to
>>>> dom0, with potential issues (like coherence), while dom0 still
>>>> need do same work as hypervisor. Our idea is to keep dom0 as ACPI
>>>> parser, then hypercall and do rest things at hypervisor side.
>>>=20
>>> Actually, after some more thought, I don't even think this ought to
>>> be implemented in the Dom0 kernel, but in user space altogether.
>>> Afaict all information necessary is already being exposed.
>>>=20
>>=20
>> No, user space lack necessary information. If I didn't misunderstand,
>> it has some dom0-side dependencies not ready now, like
>> 1. sysfs interface, and exposing xen pcpu topology and maps;
>> 2. intecept pad notify and call usermodehelper;
>> 3. a daemon to monitor/policy core parking (daemon enable when linux
>> run as pvops under xen (kernel acpi_pad disable now), daemon disable
>> when linux run under baremetal (kernel acpi_pad enable now))
>>=20
>> Seems keep same approach as native kernel which handle acpi_pad in
>> kernel side (for us, in hypervisor side) is a reasonable choice. Per
>> my understanding core parking is a co-work part of NPTM, the whole
>> process is basically a remote controller-microengine-bios-kernel
>> process, not necessarily involve user action.
>>=20
>=20
> Any comments?
>=20

Sorry, forgot to re-attach patches :-)


--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_1.patch"
Content-Description: xen_core_parking_1.patch
Content-Disposition: attachment; filename="xen_core_parking_1.patch";
	size=3395; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Mon, 13 Feb 2012 16:41:16 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAxOiBoeXBlcmNhbGwKClRoaXMgcGF0Y2ggaW1wbGVtZW50IGh5cGVy
Y2FsbCB0aHJvdWdoIHdoaWNoIGRvbTAgc2VuZCBjb3JlIHBhcmtpbmcgcmVxdWVzdCwgYW5kIGdl
dCBjb3JlIHBhcmtpbmcgcmVzdWx0LgpEdWUgdG8gdGhlIGNoYXJhY3RlcmlzdGljIG9mIGNvbnRp
bnVlX2h5cGVyY2FsbF9vbl9jcHUsIGRvbTAgc2VwZXJhdGVseSBzZW5kL2dldCBjb3JlIHBhcmtp
bmcgcmVxdWVzdC9yZXN1bHQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcu
bGl1QGludGVsLmNvbT4KCmRpZmYgLXIgOTJlMDMzMTA4NzhmIHhlbi9hcmNoL3g4Ni9wbGF0Zm9y
bV9oeXBlcmNhbGwuYwotLS0gYS94ZW4vYXJjaC94ODYvcGxhdGZvcm1faHlwZXJjYWxsLmMJV2Vk
IEZlYiAwOCAyMTowNTo1MiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9wbGF0Zm9ybV9o
eXBlcmNhbGwuYwlNb24gRmViIDEzIDExOjMzOjE2IDIwMTIgKzA4MDAKQEAgLTU2LDYgKzU2LDEw
IEBACiBsb25nIGNwdV91cF9oZWxwZXIodm9pZCAqZGF0YSk7CiBsb25nIGNwdV9kb3duX2hlbHBl
cih2b2lkICpkYXRhKTsKIAorLyogZnJvbSBjb3JlX3BhcmtpbmcuYyAqLworbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpOwordWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9p
ZCk7CisKIHJldF90IGRvX3BsYXRmb3JtX29wKFhFTl9HVUVTVF9IQU5ETEUoeGVuX3BsYXRmb3Jt
X29wX3QpIHVfeGVucGZfb3ApCiB7CiAgICAgcmV0X3QgcmV0ID0gMDsKQEAgLTU5Myw2ICs1OTcs
MzIgQEAKICAgICAgICAgICAgICAgICAgICAgICBvcC0+dS5tZW1fYWRkLmVwZm4sCiAgICAgICAg
ICAgICAgICAgICAgICAgb3AtPnUubWVtX2FkZC5weG0pOwogICAgICAgICBicmVhazsKKworICAg
IGNhc2UgWEVOUEZfY29yZV9wYXJraW5nOgorICAgIHsKKyAgICAgICAgdWludDMyX3QgaWRsZV9u
dW1zOworCisgICAgICAgIHN3aXRjaChvcC0+dS5jb3JlX3BhcmtpbmcudHlwZSkKKyAgICAgICAg
eworICAgICAgICBjYXNlIFhFTl9DT1JFX1BBUktJTkdfU0VUOgorICAgICAgICAgICAgaWRsZV9u
dW1zID0gbWluX3QodWludDMyX3QsCisgICAgICAgICAgICAgICAgICAgIG9wLT51LmNvcmVfcGFy
a2luZy5pZGxlX251bXMsIG51bV9wcmVzZW50X2NwdXMoKSAtIDEpOworICAgICAgICAgICAgcmV0
ID0gY29udGludWVfaHlwZXJjYWxsX29uX2NwdSgKKyAgICAgICAgICAgICAgICAgICAgMCwgY29y
ZV9wYXJraW5nX2hlbHBlciwgKHZvaWQgKikodW5zaWduZWQgbG9uZylpZGxlX251bXMpOworICAg
ICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgY2FzZSBYRU5fQ09SRV9QQVJLSU5HX0dFVDoKKyAg
ICAgICAgICAgIG9wLT51LmNvcmVfcGFya2luZy5pZGxlX251bXMgPSBnZXRfY3VyX2lkbGVfbnVt
cygpOworICAgICAgICAgICAgcmV0ID0gY29weV90b19ndWVzdCh1X3hlbnBmX29wLCBvcCwgMSkg
PyAtRUZBVUxUIDogMDsKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIGRlZmF1bHQ6Cisg
ICAgICAgICAgICByZXQgPSAtRUlOVkFMOworICAgICAgICAgICAgYnJlYWs7CisgICAgICAgIH0K
KyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSAtRU5PU1lT
OwogICAgICAgICBicmVhazsKZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9NYWtlZmls
ZQotLS0gYS94ZW4vY29tbW9uL01ha2VmaWxlCVdlZCBGZWIgMDggMjE6MDU6NTIgMjAxMiArMDgw
MAorKysgYi94ZW4vY29tbW9uL01ha2VmaWxlCU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgw
MApAQCAtMSw2ICsxLDcgQEAKIG9iai15ICs9IGJpdG1hcC5vCiBvYmoteSArPSBjcHUubwogb2Jq
LXkgKz0gY3B1cG9vbC5vCitvYmoteSArPSBjb3JlX3Bhcmtpbmcubwogb2JqLXkgKz0gZG9tY3Rs
Lm8KIG9iai15ICs9IGRvbWFpbi5vCiBvYmoteSArPSBldmVudF9jaGFubmVsLm8KZGlmZiAtciA5
MmUwMzMxMDg3OGYgeGVuL2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5j
CU1vbiBGZWIgMTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtMCwwICsxLDEzIEBACisjaW5jbHVk
ZSA8eGVuL3R5cGVzLmg+CisKK3N0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOworCitsb25n
IGNvcmVfcGFya2luZ19oZWxwZXIodm9pZCAqZGF0YSkKK3sKKyAgICByZXR1cm4gMDsKK30KKwor
dWludDMyX3QgZ2V0X2N1cl9pZGxlX251bXModm9pZCkKK3sKKyAgICByZXR1cm4gY3VyX2lkbGVf
bnVtczsKK30KZGlmZiAtciA5MmUwMzMxMDg3OGYgeGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3Jt
LmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL3BsYXRmb3JtLmgJV2VkIEZlYiAwOCAyMTowNTo1
MiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9wbGF0Zm9ybS5oCU1vbiBGZWIg
MTMgMTE6MzM6MTYgMjAxMiArMDgwMApAQCAtNDkwLDYgKzQ5MCwyMCBAQAogICAgIHVpbnQzMl90
IGZsYWdzOwogfTsKIAorI2RlZmluZSBYRU5QRl9jb3JlX3BhcmtpbmcgIDYwCisKKyNkZWZpbmUg
WEVOX0NPUkVfUEFSS0lOR19TRVQgMQorI2RlZmluZSBYRU5fQ09SRV9QQVJLSU5HX0dFVCAyCitz
dHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nIHsKKyAgICAvKiBJTiB2YXJpYWJsZXMgKi8KKyAgICB1
aW50MzJfdCB0eXBlOworICAgIC8qIElOIHZhcmlhYmxlczogIHNldCBjcHUgbnVtcyBleHBlY3Rl
ZCB0byBiZSBpZGxlZCAqLworICAgIC8qIE9VVCB2YXJpYWJsZXM6IGdldCBjcHUgbnVtcyBhY3R1
YWxseSBiZSBpZGxlZCAqLworICAgIHVpbnQzMl90IGlkbGVfbnVtczsKK307Cit0eXBlZGVmIHN0
cnVjdCB4ZW5wZl9jb3JlX3BhcmtpbmcgeGVucGZfY29yZV9wYXJraW5nX3Q7CitERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5wZl9jb3JlX3BhcmtpbmdfdCk7CisKIHN0cnVjdCB4ZW5fcGxhdGZv
cm1fb3AgewogICAgIHVpbnQzMl90IGNtZDsKICAgICB1aW50MzJfdCBpbnRlcmZhY2VfdmVyc2lv
bjsgLyogWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAgLTUxMSw2ICs1MjUsNyBAQAogICAg
ICAgICBzdHJ1Y3QgeGVucGZfY3B1X29sICAgICAgICAgICAgY3B1X29sOwogICAgICAgICBzdHJ1
Y3QgeGVucGZfY3B1X2hvdGFkZCAgICAgICAgY3B1X2FkZDsKICAgICAgICAgc3RydWN0IHhlbnBm
X21lbV9ob3RhZGQgICAgICAgIG1lbV9hZGQ7CisgICAgICAgIHN0cnVjdCB4ZW5wZl9jb3JlX3Bh
cmtpbmcgICAgICBjb3JlX3Bhcmtpbmc7CiAgICAgICAgIHVpbnQ4X3QgICAgICAgICAgICAgICAg
ICAgICAgICBwYWRbMTI4XTsKICAgICB9IHU7CiB9Owo=

--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen_core_parking_2.patch"
Content-Description: xen_core_parking_2.patch
Content-Disposition: attachment; filename="xen_core_parking_2.patch";
	size=7292; creation-date="Fri, 17 Feb 2012 08:53:15 GMT";
	modification-date="Thu, 16 Feb 2012 15:39:58 GMT"
Content-Transfer-Encoding: base64

WGVuIGNvcmUgcGFya2luZyAyOiBjb3JlIHBhcmtpbmcgaW1wbGVtZW50YXRpb24KClRoaXMgcGF0
Y2ggaW1wbGVtZW50IFhlbiBjb3JlIHBhcmtpbmcuCkRpZmZlcmVudCBjb3JlIHBhcmtpbmcgc2Vx
dWVuY2UgaGFzIGRpZmZlcmVudCBwb3dlci9wZXJmb3JtYW5jZSByZXN1bHQsIGR1ZSB0byBjcHUg
c29ja2V0L2NvcmUvdGhyZWFkIHRvcG9sb2d5LgpUaGlzIHBhdGNoIHByb3ZpZGUgcG93ZXItZmly
c3QgYW5kIHBlcmZvcm1hbmNlLWZpcnN0IHBvbGljaWVzLCB1c2VycyBjYW4gY2hvb3NlIGNvcmUg
cGFya2luZyBwb2xpY3kgYnkgdGhlaXIgb3duIGRlbWFuZC4KClNpZ25lZC1vZmYtYnk6IExpdSwg
Smluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciAzOTJlNzcxNzFkNzQgeGVu
L2NvbW1vbi9jb3JlX3BhcmtpbmcuYwotLS0gYS94ZW4vY29tbW9uL2NvcmVfcGFya2luZy5jCU1v
biBGZWIgMTMgMTE6MzM6MTcgMjAxMiArMDgwMAorKysgYi94ZW4vY29tbW9uL2NvcmVfcGFya2lu
Zy5jCVRodSBGZWIgMTYgMjM6Mzk6NTcgMjAxMiArMDgwMApAQCAtMSwxMyArMSwyNDAgQEAKKy8q
CisgKiAgY29yZV9wYXJraW5nLmMgLSBpbXBsZW1lbnQgY29yZSBwYXJraW5nIGFjY29yZGluZyB0
byBkb20wIHJlcXVpcmVtZW50CisgKgorICogIENvcHlyaWdodCAoQykgMjAxMiwgSW50ZWwgQ29y
cG9yYXRpb24uCisgKiAgICAgQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVs
LmNvbT4KKyAqCisgKiAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVk
aXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAqICBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhl
IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICogIHRoZSBGcmVl
IFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9y
IChhdAorICogIHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyAqCisgKiAgVGhpcyBw
cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWws
IGJ1dAorICogIFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQg
d2FycmFudHkgb2YKKyAqICBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorICogIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9y
IG1vcmUgZGV0YWlscy4KKyAqLworCiAjaW5jbHVkZSA8eGVuL3R5cGVzLmg+CisjaW5jbHVkZSA8
eGVuL2NwdS5oPgorI2luY2x1ZGUgPHhlbi9pbml0Lmg+CisjaW5jbHVkZSA8eGVuL2NwdW1hc2su
aD4KKyNpbmNsdWRlIDxhc20vcGVyY3B1Lmg+CisjaW5jbHVkZSA8YXNtL3NtcC5oPgorCisjZGVm
aW5lIENPUkVfUEFSS0lOR19JTkNSRU1FTlQgMQorI2RlZmluZSBDT1JFX1BBUktJTkdfREVDUkVN
RU5UIDIKKworc3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQg
aW50IGV2ZW50KTsKK3N0YXRpYyB1bnNpZ25lZCBpbnQgY29yZV9wYXJraW5nX3BlcmZvcm1hbmNl
KHVuc2lnbmVkIGludCBldmVudCk7CiAKIHN0YXRpYyB1aW50MzJfdCBjdXJfaWRsZV9udW1zOwor
c3RhdGljIHVuc2lnbmVkIGludCBjb3JlX3BhcmtpbmdfY3B1bnVtW05SX0NQVVNdID0ge1swIC4u
LiBOUl9DUFVTLTFdID0gLTF9OworCitzdGF0aWMgc3RydWN0IGNvcmVfcGFya2luZ19wb2xpY3kg
eworICAgIGNoYXIgbmFtZVszMF07CisgICAgdW5zaWduZWQgaW50ICgqbmV4dCkodW5zaWduZWQg
aW50IGV2ZW50KTsKK30gKmNvcmVfcGFya2luZ19wb2xpY3k7CisKK3N0YXRpYyBlbnVtIGNvcmVf
cGFya2luZ19jb250cm9sbGVyIHsKKyAgICBQT1dFUl9GSVJTVCwKKyAgICBQRVJGT1JNQU5DRV9G
SVJTVAorfSBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBPV0VSX0ZJUlNUOworCitzdGF0aWMg
dm9pZCBfX2luaXQgc2V0dXBfY29yZV9wYXJraW5nX29wdGlvbihjaGFyICpzdHIpCit7CisgICAg
aWYgKCAhc3RyY21wKHN0ciwgInBvd2VyIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJv
bGxlciA9IFBPV0VSX0ZJUlNUOworICAgIGVsc2UgaWYgKCAhc3RyY21wKHN0ciwgInBlcmZvcm1h
bmNlIikgKQorICAgICAgICBjb3JlX3BhcmtpbmdfY29udHJvbGxlciA9IFBFUkZPUk1BTkNFX0ZJ
UlNUOworICAgIGVsc2UKKyAgICAgICAgcmV0dXJuOworfQorY3VzdG9tX3BhcmFtKCJjb3JlX3Bh
cmtpbmciLCBzZXR1cF9jb3JlX3Bhcmtpbmdfb3B0aW9uKTsKKworc3RhdGljIHVuc2lnbmVkIGlu
dCBjb3JlX3BhcmtpbmdfcGVyZm9ybWFuY2UodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVu
c2lnbmVkIGludCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAg
Y2FzZSBDT1JFX1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1w
LCBjb3JlX3dlaWdodCA9IC0xOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gLTE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAsIHNpYmxpbmdf
Y2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFw
KTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKworICAg
ICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVlOworCisgICAg
ICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2NvcmVfbWFzaywg
Y3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0IDwgY29yZV90bXAgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7CisgICAgICAg
ICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
ICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3JlX3RtcCApCisg
ICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlkYXRlX21hcCk7
CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVf
bWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1hc2tfd2VpZ2h0
KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIHNpYmxp
bmdfd2VpZ2h0IDwgc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
IHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAgY3B1bWFza19j
bGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBjcHVtYXNrX3Nl
dF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCApCisgICAgICAg
ICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRlX21hcCk7Cisg
ICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5nX2NhbmRpZGF0
ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJLSU5HX0RFQ1JF
TUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1bY3VyX2lkbGVf
bnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAgICAgICAgYnJl
YWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KKworc3RhdGljIHVuc2lnbmVkIGludCBj
b3JlX3BhcmtpbmdfcG93ZXIodW5zaWduZWQgaW50IGV2ZW50KQoreworICAgIHVuc2lnbmVkIGlu
dCBjcHUgPSAtMTsKKworICAgIHN3aXRjaCAoIGV2ZW50ICkKKyAgICB7CisgICAgY2FzZSBDT1JF
X1BBUktJTkdfSU5DUkVNRU5UOgorICAgIHsKKyAgICAgICAgaW50IGNvcmVfdG1wLCBjb3JlX3dl
aWdodCA9IE5SX0NQVVMgKyAxOworICAgICAgICBpbnQgc2libGluZ190bXAsIHNpYmxpbmdfd2Vp
Z2h0ID0gTlJfQ1BVUyArIDE7CisgICAgICAgIGNwdW1hc2tfdCBjb3JlX2NhbmRpZGF0ZV9tYXAs
IHNpYmxpbmdfY2FuZGlkYXRlX21hcDsKKyAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5k
aWRhdGVfbWFwKTsKKyAgICAgICAgY3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFw
KTsKKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY3B1X29ubGluZV9tYXApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGlmICggY3B1ID09IDAgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVl
OworCisgICAgICAgICAgICBjb3JlX3RtcCA9IGNwdW1hc2tfd2VpZ2h0KHBlcl9jcHUoY3B1X2Nv
cmVfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBpZiAoIGNvcmVfd2VpZ2h0ID4gY29yZV90bXAg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGNvcmVfd2VpZ2h0ID0gY29yZV90bXA7
CisgICAgICAgICAgICAgICAgY3B1bWFza19jbGVhcigmY29yZV9jYW5kaWRhdGVfbWFwKTsKKyAg
ICAgICAgICAgICAgICBjcHVtYXNrX3NldF9jcHUoY3B1LCAmY29yZV9jYW5kaWRhdGVfbWFwKTsK
KyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBjb3JlX3dlaWdodCA9PSBjb3Jl
X3RtcCApCisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJmNvcmVfY2FuZGlk
YXRlX21hcCk7CisgICAgICAgIH0KKworICAgICAgICBmb3JfZWFjaF9jcHUoY3B1LCAmY29yZV9j
YW5kaWRhdGVfbWFwKQorICAgICAgICB7CisgICAgICAgICAgICBzaWJsaW5nX3RtcCA9IGNwdW1h
c2tfd2VpZ2h0KHBlcl9jcHUoY3B1X3NpYmxpbmdfbWFzaywgY3B1KSk7CisgICAgICAgICAgICBp
ZiAoIHNpYmxpbmdfd2VpZ2h0ID4gc2libGluZ190bXAgKQorICAgICAgICAgICAgeworICAgICAg
ICAgICAgICAgIHNpYmxpbmdfd2VpZ2h0ID0gc2libGluZ190bXA7CisgICAgICAgICAgICAgICAg
Y3B1bWFza19jbGVhcigmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAgICAgICBj
cHVtYXNrX3NldF9jcHUoY3B1LCAmc2libGluZ19jYW5kaWRhdGVfbWFwKTsKKyAgICAgICAgICAg
IH0KKyAgICAgICAgICAgIGVsc2UgaWYgKCBzaWJsaW5nX3dlaWdodCA9PSBzaWJsaW5nX3RtcCAp
CisgICAgICAgICAgICAgICAgY3B1bWFza19zZXRfY3B1KGNwdSwgJnNpYmxpbmdfY2FuZGlkYXRl
X21hcCk7CisgICAgICAgIH0KKworICAgICAgICBjcHUgPSBjcHVtYXNrX2ZpcnN0KCZzaWJsaW5n
X2NhbmRpZGF0ZV9tYXApOworICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgQ09SRV9QQVJL
SU5HX0RFQ1JFTUVOVDoKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19jcHVudW1b
Y3VyX2lkbGVfbnVtcyAtMV07CisgICAgfQorICAgIGJyZWFrOworCisgICAgZGVmYXVsdDoKKyAg
ICAgICAgYnJlYWs7CisgICAgfQorCisgICAgcmV0dXJuIGNwdTsKK30KIAogbG9uZyBjb3JlX3Bh
cmtpbmdfaGVscGVyKHZvaWQgKmRhdGEpCiB7Ci0gICAgcmV0dXJuIDA7CisgICAgdWludDMyX3Qg
aWRsZV9udW1zID0gKHVuc2lnbmVkIGxvbmcpZGF0YTsKKyAgICB1bnNpZ25lZCBpbnQgY3B1Owor
ICAgIGludCByZXQgPSAwOworCisgICAgaWYgKCAhY29yZV9wYXJraW5nX3BvbGljeSApCisgICAg
ICAgIHJldHVybiAtRUlOVkFMOworCisgICAgd2hpbGUgKCBjdXJfaWRsZV9udW1zIDwgaWRsZV9u
dW1zICkKKyAgICB7CisgICAgICAgIGNwdSA9IGNvcmVfcGFya2luZ19wb2xpY3ktPm5leHQoQ09S
RV9QQVJLSU5HX0lOQ1JFTUVOVCk7CisgICAgICAgIHJldCA9IGNwdV9kb3duKGNwdSk7CisgICAg
ICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiByZXQ7CisgICAgICAgIGNvcmVfcGFy
a2luZ19jcHVudW1bY3VyX2lkbGVfbnVtcysrXSA9IGNwdTsKKyAgICB9CisKKyAgICB3aGlsZSAo
IGN1cl9pZGxlX251bXMgPiBpZGxlX251bXMgKQorICAgIHsKKyAgICAgICAgY3B1ID0gY29yZV9w
YXJraW5nX3BvbGljeS0+bmV4dChDT1JFX1BBUktJTkdfREVDUkVNRU5UKTsKKyAgICAgICAgcmV0
ID0gY3B1X3VwKGNwdSk7CisgICAgICAgIGlmICggcmV0ICkKKyAgICAgICAgICAgIHJldHVybiBy
ZXQ7CisgICAgICAgIGNvcmVfcGFya2luZ19jcHVudW1bLS1jdXJfaWRsZV9udW1zXSA9IC0xOwor
ICAgIH0KKworICAgIHJldHVybiByZXQ7CiB9CiAKIHVpbnQzMl90IGdldF9jdXJfaWRsZV9udW1z
KHZvaWQpCiB7CiAgICAgcmV0dXJuIGN1cl9pZGxlX251bXM7CiB9CisKK3N0YXRpYyBzdHJ1Y3Qg
Y29yZV9wYXJraW5nX3BvbGljeSBwb3dlcl9maXJzdCA9IHsKKyAgICAubmFtZSA9ICJwb3dlciIs
CisgICAgLm5leHQgPSBjb3JlX3BhcmtpbmdfcG93ZXIsCit9OworCitzdGF0aWMgc3RydWN0IGNv
cmVfcGFya2luZ19wb2xpY3kgcGVyZm9ybWFuY2VfZmlyc3QgPSB7CisgICAgLm5hbWUgPSAicGVy
Zm9ybWFuY2UiLAorICAgIC5uZXh0ID0gY29yZV9wYXJraW5nX3BlcmZvcm1hbmNlLAorfTsKKwor
c3RhdGljIGludCByZWdpc3Rlcl9jb3JlX3BhcmtpbmdfcG9saWN5KHN0cnVjdCBjb3JlX3Bhcmtp
bmdfcG9saWN5ICpwb2xpY3kpCit7CisgICAgaWYgKCAhcG9saWN5IHx8ICFwb2xpY3ktPm5leHQg
KQorICAgICAgICByZXR1cm4gLUVJTlZBTDsKKworICAgIGNvcmVfcGFya2luZ19wb2xpY3kgPSBw
b2xpY3k7CisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgX19pbml0IGNvcmVfcGFya2lu
Z19pbml0KHZvaWQpCit7CisgICAgaW50IHJldCA9IDA7CisKKyAgICBpZiAoIGNvcmVfcGFya2lu
Z19jb250cm9sbGVyID09IFBFUkZPUk1BTkNFX0ZJUlNUICkKKyAgICAgICAgcmV0ID0gcmVnaXN0
ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcGVyZm9ybWFuY2VfZmlyc3QpOworICAgIGVsc2UKKyAg
ICAgICAgcmV0ID0gcmVnaXN0ZXJfY29yZV9wYXJraW5nX3BvbGljeSgmcG93ZXJfZmlyc3QpOwor
CisgICAgcmV0dXJuIHJldDsKK30KK19faW5pdGNhbGwoY29yZV9wYXJraW5nX2luaXQpOwo=

--_003_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923350BC845SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 29 12:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2j3x-0002iN-G0; Wed, 29 Feb 2012 12:55:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1S2j3v-0002iG-FT
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:55:20 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330520110!16095062!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	FROM_EXCESS_QP,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24509 invoked from network); 29 Feb 2012 12:55:11 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 12:55:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=cX/TnsRBFvorpSjDmC2NmlpLcIg+1
	yp9tVWxzLaAJCg=; b=Za1pdeKu2HFij4Vs4rrqT5QgEMt8Q8NVGuQ72KzC3Fvjx
	q48R7n17WA9kkIpKBlxH+aRujFCaZjLC7hB1j17x4VZIqq0xBGZZS3i3JsAOghXV
	0/asi/K5LqtGHapHOziqXIuGIoZOvDqs8bpv12+aTOX2dT601eQWDb+eT5JeSI=
Received: (qmail 21372 invoked from network); 29 Feb 2012 13:54:35 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.158.253)
	by mail.zeus06.de with ESMTPA; 29 Feb 2012 13:54:35 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 65AD92C5FD;
	Wed, 29 Feb 2012 13:56:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id XUcE-CvZtfba; Wed, 29 Feb 2012 13:56:09 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E06392C5FC;
	Wed, 29 Feb 2012 13:56:09 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Wed, 29 Feb 2012 13:56:09 +0100
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw"
In-Reply-To: <zarafa.4f4e15b5.3926.5c7b11b715fbc27d@uhura.space.zz>
References: <zarafa.4f4e15b5.3926.5c7b11b715fbc27d@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
Cc: =?utf-8?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw
Content-Type: multipart/alternative; 
 boundary="=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg"

--=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am very sorry. I accidently started the DomU with the wrong config file=
, thus it's clear why there is no difference=0D=0A=0D=0Abetween the two. =
And unfortunately, the DomU with the correct config file is having a BUG:=
=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=0A[   14.674883] BUG: unable to handle ker=
nel paging request at ffffc7fffffff000=0A[   14.674910] IP: [<ffffffff811=
b4c0b>] swiotlb_bounce+0x2e/0x31=0A[   14.674930] PGD 0=20=0A[   14.67494=
0] Oops: 0002 [#1] SMP=20=0A[   14.674952] CPU 0=20=0A[   14.674957] Modu=
les linked in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc=
 tda10023 budget_av evdev saa7146_vv videodev v4l2_compat_ioctl32 videobu=
f_dma_sg videobuf_core budget_core snd_pcm dvb_core snd_timer saa7146 snd=
 ttpci_eeprom soundcore snd_page_alloc i2c_core pcspkr ext3 jbd mbcache x=
en_netfront xen_blkfront=0A[   14.675057]=20=0A[   14.675065] Pid: 0, com=
m: swapper/0 Not tainted 3.2.8-amd64 #1 =20=0A[   14.675079] RIP: e030:[<=
ffffffff811b4c0b>]  [<ffffffff811b4c0b>] swiotlb_bounce+0x2e/0x31=0A[   1=
4.675097] RSP: e02b:ffff880013fabe58  EFLAGS: 00010202=0A[   14.675106] R=
AX: ffff880012800000 RBX: 0000000000000001 RCX: 0000000000001000=0A[   14=
=2E675116] RDX: 0000000000001000 RSI: ffff880012800000 RDI: ffffc7fffffff=
000=0A[   14.675126] RBP: 0000000000000002 R08: ffffc7fffffff000 R09: fff=
f880013f98000=0A[   14.675137] R10: 0000000000000001 R11: ffff88000337600=
0 R12: ffff8800032c5090=0A[   14.675147] R13: 0000000000000149 R14: ffff8=
800033e0000 R15: ffffffff81601fd8=0A[   14.675163] FS:  00007f3ff9893700(=
0000) GS:ffff880013fa8000(0000) knlGS:0000000000000000=0A[   14.675175] C=
S:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b=0A[   14.675184] CR2: ff=
ffc7fffffff000 CR3: 0000000012683000 CR4: 0000000000000660=0A[   14.67519=
5] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000=0A[ =
  14.675205] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400=0A[   14.675216] Process swapper/0 (pid: 0, threadinfo ffffffff8160=
0000, task ffffffff8160d020)=0A[   14.675227] Stack:=0A[   14.675232]  ff=
ffffff81211826 ffff880002eda000 0000000000000000 ffffc90000408000=0A[   1=
4.675251]  00000000000b0150 0000000000000006 ffffffffa013ec4a ffffffff810=
946cd=0A[   14.675270]  ffffffff81099203 ffff880003376000 000000000000000=
0 ffff880002eda4b0=0A[   14.675289] Call Trace:=0A[   14.675295]  <IRQ>=20=
=0A[   14.675307]  [<ffffffff81211826>] =3F xen_swiotlb_sync_sg_for_cpu+0=
x2e/0x47=0A[   14.675322]  [<ffffffffa013ec4a>] =3F vpeirq+0x7f/0x198 [bu=
dget_core]=0A[   14.675337]  [<ffffffff810946cd>] =3F handle_irq_event_pe=
rcpu+0x166/0x184=0A[   14.675350]  [<ffffffff81099203>] =3F __rcu_process=
_callbacks+0x71/0x2f8=0A[   14.675364]  [<ffffffff8104d175>] =3F tasklet_=
action+0x76/0xc5=0A[   14.675376]  [<ffffffff8120a9ac>] =3F eoi_pirq+0x5b=
/0x77=0A[   14.675388]  [<ffffffff8104cbc6>] =3F __do_softirq+0xc4/0x1a0=0A=
[   14.675400]  [<ffffffff8120a022>] =3F __xen_evtchn_do_upcall+0x1c7/0x2=
05=0A[   14.675412]  [<ffffffff8134b06c>] =3F call_softirq+0x1c/0x30=0A[ =
  14.675425]  [<ffffffff8100fa47>] =3F do_softirq+0x3f/0x79=0A[   14.6754=
36]  [<ffffffff8104c996>] =3F irq_exit+0x44/0xb5=0A[   14.675452]  [<ffff=
ffff8120b032>] =3F xen_evtchn_do_upcall+0x27/0x32=0A[   14.675464]  [<fff=
fffff8134b0be>] =3F xen_do_hypervisor_callback+0x1e/0x30=0A[   14.675473]=
  <EOI>=20=0D=0A=0D=0A=C2=A0=0D=0AComplete log is attached.=0D=0A=0D=0A=C2=
=A0=0D=0ABR, Carsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-=
----=0D=0AAn:Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>;=20=0D=0ACC:K=
onrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel <xen-devel@lists.xens=
ource.com>; Jan Beulich <jbeulich@suse.com>; Sander Eikelenboom <linux@ei=
kelenboom.it>;=20=0D=0AVon:Carsten Schiers <carsten@schiers.de>=0D=0AGese=
ndet:Mi 29.02.2012 13:16=0D=0ABetreff:Re: [Xen-devel] Load increase after=
 memory upgrade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=0D=0A=0D=0AGreat =
news: it works and load is back to normal. In the attached graph you can =
see the peak=0D=0A=0D=0Ain blue (compilation of the patched 3.2.8 Kernel)=
 and then after 16.00 the going life of the=0D=0A=0D=0Avideo DomU. We are=
 below an avaerage of 7% usage (figures are in Permille).=0D=0A=0D=0A=0D=0A=
Thanks so much. Is that already "the final patch"=3F=0D=0A=0D=0A=C2=A0=0D=
=0ABR, Carsten.=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0A-----Urspr=C3=BC=
ngliche Nachricht-----=0D=0AAn:Konrad Rzeszutek Wilk <konrad.wilk@oracle.=
com>;=20=0D=0ACC:Sander Eikelenboom <linux@eikelenboom.it>; xen-devel <xe=
n-devel@lists.xensource.com>; Jan Beulich <jbeulich@suse.com>; Konrad Rze=
szutek Wilk <konrad@darnok.org>;=20=0D=0AVon:Carsten Schiers <carsten@sch=
iers.de>=0D=0AGesendet:Di 28.02.2012 15:39=0D=0ABetreff:Re: [Xen-devel] L=
oad increase after memory upgrade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=
=0D=0A=0D=0AWell let me check for a longer period of time, and especially=
, whether the DomU is still=0D=0A=0D=0Aworking (can do that only from at =
home), but load looks pretty well after applying the=0D=0A=0D=0Apatch to =
3.2.8 :-D.=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A=
-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Jan Beulich <JBeulich@suse=
=2Ecom>;=20=0D=0ACC:Konrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel =
<xen-devel@lists.xensource.com>; Carsten Schiers <carsten@schiers.de>; Sa=
nder Eikelenboom <linux@eikelenboom.it>;=20=0D=0AVon:Konrad Rzeszutek Wil=
k <konrad.wilk@oracle.com>=0D=0AGesendet:Fr 17.02.2012 16:18=0D=0ABetreff=
:Re: [Xen-devel] Load increase after memory upgrade (part2)=0D=0AOn Thu, =
Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> On 15.02.=
12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:=0D=0A>=
 >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struc=
t *area, gfp_t gfp_mask,=0D=0A> > struct page **pages;=0D=0A> > unsigned =
int nr_pages, array_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_mask & GF=
P_RECLAIM_MASK) | __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D gfp_m=
ask & (__GFP_DMA | __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=0A> >=
+if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I didn't=
 spot where you force this normally invalid combination, without=0D=0A> w=
hich the change won't affect vmalloc32() in a 32-bit kernel.=0D=0A>=20=0D=
=0A> >+gfp_mask &=3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gfp_mask=
 &=3D ~(__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0ADuh!=0D=
=0AGood eyes. Thanks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=0A>=
 > nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > array_si=
ze =3D (nr_pages * sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=0D=
=0A_______________________________________________=0D=0AXen-devel mailing=
 list=0D=0AXen-devel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/=
xen-devel=0D=0A=20=0D=0A=20=0D=0A=0D=0A=C2=A0=0D=0A
--=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv
bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+PGh0bWw+
CjxoZWFkPgogIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iWmFyYWZhIFdlYkFj
Y2VzcyB2Ny4wLjItMjk0NzAiPgogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8dGl0bGU+QVc6IFtYZW4t
ZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTwvdGl0
bGU+CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgYm9keQ0KICAgICAgew0KICAg
ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh
bnQ7DQogICAgICAgIGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgcGFkZGluZzogNXB4IDVw
eCA1cHggNXB4Ow0KICAgICAgICBtYXJnaW46IDBweDsNCiAgICAgICAgYm9yZGVyLXN0eWxl
OiBub25lOw0KICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KICAgICAgfQ0K
DQogICAgICBwLCB1bCwgbGkNCiAgICAgIHsNCiAgICAgICAgbWFyZ2luLXRvcDogMHB4Ow0K
ICAgICAgICBtYXJnaW4tYm90dG9tOiAwcHg7DQogICAgICB9DQogIDwvc3R5bGU+CjwvaGVh
ZD4KPGJvZHk+CjxwPkkgYW0gdmVyeSBzb3JyeS4gSSBhY2NpZGVudGx5IHN0YXJ0ZWQgdGhl
IERvbVUgd2l0aCB0aGUgd3JvbmcgY29uZmlnIGZpbGUsIHRodXMgaXQmIzM5O3MgY2xlYXIg
d2h5IHRoZXJlIGlzIG5vIGRpZmZlcmVuY2U8L3A+PHA+YmV0d2VlbiB0aGUgdHdvLiBBbmQg
dW5mb3J0dW5hdGVseSwgdGhlIERvbVUgd2l0aCB0aGUgY29ycmVjdCBjb25maWcgZmlsZSBp
cyBoYXZpbmcgYSBCVUc6PC9wPjxwPiZuYnNwOzwvcD48cHJlPgpbICAgMTQuNjc0ODgzXSBC
VUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZjN2Zm
ZmZmZmYwMDAKWyAgIDE0LjY3NDkxMF0gSVA6IFsmbHQ7ZmZmZmZmZmY4MTFiNGMwYiZndDtd
IHN3aW90bGJfYm91bmNlKzB4MmUvMHgzMQpbICAgMTQuNjc0OTMwXSBQR0QgMCAKWyAgIDE0
LjY3NDk0MF0gT29wczogMDAwMiBbIzFdIFNNUCAKWyAgIDE0LjY3NDk1Ml0gQ1BVIDAgClsg
ICAxNC42NzQ5NTddIE1vZHVsZXMgbGlua2VkIGluOiBuZnNkIGV4cG9ydGZzIG5mcyBsb2Nr
ZCBmc2NhY2hlIGF1dGhfcnBjZ3NzIG5mc19hY2wgc3VucnBjIHRkYTEwMDIzIGJ1ZGdldF9h
diBldmRldiBzYWE3MTQ2X3Z2IHZpZGVvZGV2IHY0bDJfY29tcGF0X2lvY3RsMzIgdmlkZW9i
dWZfZG1hX3NnIHZpZGVvYnVmX2NvcmUgYnVkZ2V0X2NvcmUgc25kX3BjbSBkdmJfY29yZSBz
bmRfdGltZXIgc2FhNzE0NiBzbmQgdHRwY2lfZWVwcm9tIHNvdW5kY29yZSBzbmRfcGFnZV9h
bGxvYyBpMmNfY29yZSBwY3Nwa3IgZXh0MyBqYmQgbWJjYWNoZSB4ZW5fbmV0ZnJvbnQgeGVu
X2Jsa2Zyb250ClsgICAxNC42NzUwNTddIApbICAgMTQuNjc1MDY1XSBQaWQ6IDAsIGNvbW06
IHN3YXBwZXIvMCBOb3QgdGFpbnRlZCAzLjIuOC1hbWQ2NCAjMSAgClsgICAxNC42NzUwNzld
IFJJUDogZTAzMDpbJmx0O2ZmZmZmZmZmODExYjRjMGImZ3Q7XSAgWyZsdDtmZmZmZmZmZjgx
MWI0YzBiJmd0O10gc3dpb3RsYl9ib3VuY2UrMHgyZS8weDMxClsgICAxNC42NzUwOTddIFJT
UDogZTAyYjpmZmZmODgwMDEzZmFiZTU4ICBFRkxBR1M6IDAwMDEwMjAyClsgICAxNC42NzUx
MDZdIFJBWDogZmZmZjg4MDAxMjgwMDAwMCBSQlg6IDAwMDAwMDAwMDAwMDAwMDEgUkNYOiAw
MDAwMDAwMDAwMDAxMDAwClsgICAxNC42NzUxMTZdIFJEWDogMDAwMDAwMDAwMDAwMTAwMCBS
U0k6IGZmZmY4ODAwMTI4MDAwMDAgUkRJOiBmZmZmYzdmZmZmZmZmMDAwClsgICAxNC42NzUx
MjZdIFJCUDogMDAwMDAwMDAwMDAwMDAwMiBSMDg6IGZmZmZjN2ZmZmZmZmYwMDAgUjA5OiBm
ZmZmODgwMDEzZjk4MDAwClsgICAxNC42NzUxMzddIFIxMDogMDAwMDAwMDAwMDAwMDAwMSBS
MTE6IGZmZmY4ODAwMDMzNzYwMDAgUjEyOiBmZmZmODgwMDAzMmM1MDkwClsgICAxNC42NzUx
NDddIFIxMzogMDAwMDAwMDAwMDAwMDE0OSBSMTQ6IGZmZmY4ODAwMDMzZTAwMDAgUjE1OiBm
ZmZmZmZmZjgxNjAxZmQ4ClsgICAxNC42NzUxNjNdIEZTOiAgMDAwMDdmM2ZmOTg5MzcwMCgw
MDAwKSBHUzpmZmZmODgwMDEzZmE4MDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAK
WyAgIDE0LjY3NTE3NV0gQ1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAw
MDA4MDA1MDAzYgpbICAgMTQuNjc1MTg0XSBDUjI6IGZmZmZjN2ZmZmZmZmYwMDAgQ1IzOiAw
MDAwMDAwMDEyNjgzMDAwIENSNDogMDAwMDAwMDAwMDAwMDY2MApbICAgMTQuNjc1MTk1XSBE
UjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERSMjogMDAwMDAw
MDAwMDAwMDAwMApbICAgMTQuNjc1MjA1XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAw
MDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMApbICAgMTQuNjc1MjE2XSBQ
cm9jZXNzIHN3YXBwZXIvMCAocGlkOiAwLCB0aHJlYWRpbmZvIGZmZmZmZmZmODE2MDAwMDAs
IHRhc2sgZmZmZmZmZmY4MTYwZDAyMCkKWyAgIDE0LjY3NTIyN10gU3RhY2s6ClsgICAxNC42
NzUyMzJdICBmZmZmZmZmZjgxMjExODI2IGZmZmY4ODAwMDJlZGEwMDAgMDAwMDAwMDAwMDAw
MDAwMCBmZmZmYzkwMDAwNDA4MDAwClsgICAxNC42NzUyNTFdICAwMDAwMDAwMDAwMGIwMTUw
IDAwMDAwMDAwMDAwMDAwMDYgZmZmZmZmZmZhMDEzZWM0YSBmZmZmZmZmZjgxMDk0NmNkClsg
ICAxNC42NzUyNzBdICBmZmZmZmZmZjgxMDk5MjAzIGZmZmY4ODAwMDMzNzYwMDAgMDAwMDAw
MDAwMDAwMDAwMCBmZmZmODgwMDAyZWRhNGIwClsgICAxNC42NzUyODldIENhbGwgVHJhY2U6
ClsgICAxNC42NzUyOTVdICAmbHQ7SVJRJmd0OyAKWyAgIDE0LjY3NTMwN10gIFsmbHQ7ZmZm
ZmZmZmY4MTIxMTgyNiZndDtdID8geGVuX3N3aW90bGJfc3luY19zZ19mb3JfY3B1KzB4MmUv
MHg0NwpbICAgMTQuNjc1MzIyXSAgWyZsdDtmZmZmZmZmZmEwMTNlYzRhJmd0O10gPyB2cGVp
cnErMHg3Zi8weDE5OCBbYnVkZ2V0X2NvcmVdClsgICAxNC42NzUzMzddICBbJmx0O2ZmZmZm
ZmZmODEwOTQ2Y2QmZ3Q7XSA/IGhhbmRsZV9pcnFfZXZlbnRfcGVyY3B1KzB4MTY2LzB4MTg0
ClsgICAxNC42NzUzNTBdICBbJmx0O2ZmZmZmZmZmODEwOTkyMDMmZ3Q7XSA/IF9fcmN1X3By
b2Nlc3NfY2FsbGJhY2tzKzB4NzEvMHgyZjgKWyAgIDE0LjY3NTM2NF0gIFsmbHQ7ZmZmZmZm
ZmY4MTA0ZDE3NSZndDtdID8gdGFza2xldF9hY3Rpb24rMHg3Ni8weGM1ClsgICAxNC42NzUz
NzZdICBbJmx0O2ZmZmZmZmZmODEyMGE5YWMmZ3Q7XSA/IGVvaV9waXJxKzB4NWIvMHg3Nwpb
ICAgMTQuNjc1Mzg4XSAgWyZsdDtmZmZmZmZmZjgxMDRjYmM2Jmd0O10gPyBfX2RvX3NvZnRp
cnErMHhjNC8weDFhMApbICAgMTQuNjc1NDAwXSAgWyZsdDtmZmZmZmZmZjgxMjBhMDIyJmd0
O10gPyBfX3hlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MWM3LzB4MjA1ClsgICAxNC42NzU0MTJd
ICBbJmx0O2ZmZmZmZmZmODEzNGIwNmMmZ3Q7XSA/IGNhbGxfc29mdGlycSsweDFjLzB4MzAK
WyAgIDE0LjY3NTQyNV0gIFsmbHQ7ZmZmZmZmZmY4MTAwZmE0NyZndDtdID8gZG9fc29mdGly
cSsweDNmLzB4NzkKWyAgIDE0LjY3NTQzNl0gIFsmbHQ7ZmZmZmZmZmY4MTA0Yzk5NiZndDtd
ID8gaXJxX2V4aXQrMHg0NC8weGI1ClsgICAxNC42NzU0NTJdICBbJmx0O2ZmZmZmZmZmODEy
MGIwMzImZ3Q7XSA/IHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MjcvMHgzMgpbICAgMTQuNjc1
NDY0XSAgWyZsdDtmZmZmZmZmZjgxMzRiMGJlJmd0O10gPyB4ZW5fZG9faHlwZXJ2aXNvcl9j
YWxsYmFjaysweDFlLzB4MzAKWyAgIDE0LjY3NTQ3M10gICZsdDtFT0kmZ3Q7IDwvcHJlPjxw
PiZuYnNwOzwvcD48cD5Db21wbGV0ZSBsb2cgaXMgYXR0YWNoZWQuPC9wPjxwPiZuYnNwOzwv
cD48cD5CUiwgQ2Fyc3Rlbi48YnIgLz4mbmJzcDs8L3A+PGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlci1sZWZ0OiAycHggc29saWQgIzMyNUZCQTsgcGFkZGluZy1sZWZ0OiA1cHg7bWFyZ2lu
LWxlZnQ6NXB4OyI+LS0tLS1VcnNwciZ1dW1sO25nbGljaGUgTmFjaHJpY2h0LS0tLS08YnIg
Lz48c3Ryb25nPkFuOjwvc3Ryb25nPglLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJh
ZC53aWxrQG9yYWNsZS5jb20mZ3Q7OyA8YnIgLz48c3Ryb25nPkNDOjwvc3Ryb25nPglLb25y
YWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZEBkYXJub2sub3JnJmd0OzsgeGVuLWRldmVs
ICZsdDt4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbSZndDs7IEphbiBCZXVsaWNoICZs
dDtqYmV1bGljaEBzdXNlLmNvbSZndDs7IFNhbmRlciBFaWtlbGVuYm9vbSAmbHQ7bGludXhA
ZWlrZWxlbmJvb20uaXQmZ3Q7OyA8YnIgLz48c3Ryb25nPlZvbjo8L3N0cm9uZz4JQ2Fyc3Rl
biBTY2hpZXJzICZsdDtjYXJzdGVuQHNjaGllcnMuZGUmZ3Q7PGJyIC8+PHN0cm9uZz5HZXNl
bmRldDo8L3N0cm9uZz4JTWkgMjkuMDIuMjAxMiAxMzoxNjxiciAvPjxzdHJvbmc+QmV0cmVm
Zjo8L3N0cm9uZz4JUmU6IFtYZW4tZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5
IHVwZ3JhZGUgKHBhcnQyKTxiciAvPjxzdHJvbmc+QW5sYWdlOjwvc3Ryb25nPglpbmxpbmUu
dHh0PGJyIC8+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHsgZm9udC1mYW1pbHk6IG1v
bm9zcGFjZTsgfTwvc3R5bGU+ICAgICAgICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3Nz
Ij4gICAgICAgLmJvZHljbGFzcyAgICAgICB7ICAgICAgICAgZm9udC1mYW1pbHk6IEFyaWFs
LCBWZXJkYW5hLCBTYW5zLVNlcmlmICEgaW1wb3J0YW50OyAgICAgICAgIGZvbnQtc2l6ZTog
MTJweDsgICAgICAgICBwYWRkaW5nOiA1cHggNXB4IDVweCA1cHg7ICAgICAgICAgbWFyZ2lu
OiAwcHg7ICAgICAgICAgYm9yZGVyLXN0eWxlOiBub25lOyAgICAgICAgIGJhY2tncm91bmQt
Y29sb3I6ICNmZmZmZmY7ICAgICAgIH0gICAgICAgIHAsIHVsLCBsaSAgICAgICB7ICAgICAg
ICAgbWFyZ2luLXRvcDogMHB4OyAgICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsgICAgICAg
fSAgIDwvc3R5bGU+ICA8ZGl2PjxwPkdyZWF0IG5ld3M6IGl0IHdvcmtzIGFuZCBsb2FkIGlz
IGJhY2sgdG8gbm9ybWFsLiBJbiB0aGUgYXR0YWNoZWQgZ3JhcGggeW91IGNhbiBzZWUgdGhl
IHBlYWs8L3A+PHA+aW4gYmx1ZSAoY29tcGlsYXRpb24gb2YgdGhlIHBhdGNoZWQgMy4yLjgg
S2VybmVsKSBhbmQgdGhlbiBhZnRlciAxNi4wMCB0aGUgZ29pbmcgbGlmZSBvZiB0aGU8L3A+
PHA+dmlkZW8gRG9tVS4gV2UgYXJlIGJlbG93IGFuIGF2YWVyYWdlIG9mIDclIHVzYWdlIChm
aWd1cmVzIGFyZSBpbiBQZXJtaWxsZSkuPC9wPjxwPjxiciAvPlRoYW5rcyBzbyBtdWNoLiBJ
cyB0aGF0IGFscmVhZHkgJnF1b3Q7dGhlIGZpbmFsIHBhdGNoJnF1b3Q7PzwvcD48cD4mbmJz
cDs8L3A+PHA+QlIsIENhcnN0ZW4uPC9wPjxwPiZuYnNwOzwvcD48cD48YnIgLz4mbmJzcDs8
aW1nIHNyYz0iZGF0YTppbWFnZS9wbmc7YmFzZTY0LGlWQk9SdzBLR2dvQUFBQU5TVWhFVWdB
QUFmRUFBQUdFQ0FJQUFBQ3B2NDVZQUFBZ0FFbEVRVlI0bk8yZGZYUVVWWjczYjBnQ0lTQUp3
U0JndGtuRWtKQTN6QVlWZlVhUGoyY2RIY2VET0lGbFpnQjNkcHhoUmtRajZLb2M1MkN2c0Rv
S0F6akJMRG1vWklOQk1OMkJCRmxmRUVrRTl4QUo2S0JFakx3NEtFaDNPcS8zbnozbitTUFBI
eGV1UmQycTZwdnVydXJxcXUvbjlPblRYWDNyM3Z1N2RldmJ2OXl1K29aOEJnQUF3QkcwdHJh
U2VQY0JBQUJBREdodGJYM2pqVGN1YVRvRkFBQ1F5THp4eGh2UWRBQUFjQWpRZEFBQWNBN1Fk
QUFBY0E3UWRBQUFTQ1FhQlpTZlF0TUJrSUlRRXU4dURJTlk5VGF4b25ZVmc0T0RUTTJoNmND
Qm1DYzl2R2J4UlV5cU5RbG91clBwNys4L2N1U0l6K2M3Zi81OFUxT1Q4aU5vdXF0WnVIRGhi
My83VytXV2YvM1hmMTIwYUZFMGRSSkNDQ0ZKU1VsWFhYVlZXVm5aOHVYTHo1NDlHMTAzWTR5
bVRvV1Y3Q2pWeldKeGhLWTdtTTdPenBhV2xyYTJ0cTZ1cnFhbXBpTkhqaWcvaGFhN21rQWdV
RlJVOU1ZYmI3QzNyNy8rZW5GeGNUQVlqS1pPcmdLQlFPRFFvVU1QUC96dzVNbVRUNXc0RVcx
Zll3YzAzZnA2UUF6NTZLT1B6cDgvci9jcE5OM3RIRDE2OUpwcnJqbDI3Tml4WThjbVRackVw
a0YvZi8rS0ZTdXV2dnJxMGFOSFYxWlcvdkRERDZ3d0lXVGp4bzBlanljMU5iV3NyT3lUVHo0
Ukt4UlY0T21ubi83bEwzL0pYbmQzZC8vTHYvekxWVmRkZGRWVlYvM21ONy9wN3U3bWUyM1lz
R0hxMUtralI0NmNNV1BHQng5OHNIbno1bW5UcHJHR0RoOCt6SXA5OGNVWFAvdlp6OGFNR1RO
cTFLaTc3cnJyekprenFrWWo2eUhmU0JTSU5Zc3Z4UEthUFRTbzFtQkF3Z1ppQUNGazllclYy
ZG5aNmVucGl4WXRDb1ZDbE5KYmI3MTE2OWF0dkV4blorZWtTWk5VNmhBS2hSWXVYSmllbmo1
eDRzUTFhOVlZeHlWVEliQVlhRHFncjczMlduRnhjWEZ4Y1YxZEhkdnlwei85NmM0Nzd6eDU4
dVFQUC95d2NPSEMzLzN1ZDJ3N0lhU3lzdkxycjc4T0JBTFBQdnRzUlVXRldKdW9tSjJkbmRk
Y2N3MTcvZGhqajkxOTk5MW56cHc1ZmZyMFAvM1RQMVZWVmZHOTVzeVo4OVZYWHdVQ2dlZWVl
MjdzMkxFUFBQQUFmM3ZqalRleVlvV0ZoZSs4ODA0d0dEeC8vdnpTcFVzWExGaWdhalN5SGxM
OVBGMW1QYjI2dXZxZWUrNlI3S0hxcmNHQWhBM0VBRUlJcS9iTW1UTjMzMzMzNDQ4L1RpbmR0
V3RYUVVIQndNQUFLL1BnZ3c4Ky8venpxaDJycXFwNGYrNjY2eTdlVDgyNFpDb0VNUWZYdllE
d2xKZVh6NW8xaTcvMWVEekhqaDFqcjArZlBqMXg0a1QybWhCeTd0dzU5am9RQ0tTa3BJaFZp
WkxYMjl1Ym1wcktYaytlUFBuenp6OW5yei83N0xNcFU2Ynd2ZjcrOTcvem1sVnZOUnNLQkFK
WFgzMjFxdEhJZWtpajBQU1dscGFaTTJmeVAyWEM5bEQxMW1CQXdnWmlBQ0hrYjMvN0czdjkr
ZWVmWDN2dHRleDFSVVhGNjYrL3pqY0dBZ0hWamxPbVRPRTdmdmJaWjVwanBZd3JiSVhBSkhE
ZEM5Qmw4K2JOTjl4d3d3MDMzUERhYTYreExTa3BLY3JsZ3FTa0pMWmRUNWlNTjdJL3lkbnI1
T1RrL3Y1KzlycXZyNDlMbFhITi9PMkhIMzU0eXkyM3BLZW42M1ZNcG9jalJvemdmV0QwOS9l
UEdESEN1QWJOSm80Y09USnQyalRscndWaGU2aDZHOW1BOEkzSzlSelZSNXJWN3RpeEl6OC92
NysvZi83OCtXdlhyaFYzVlBVbjdNaUhyUkNZQWE1N0Fib2NPWEprOHVUSlgzenh4ZkhqeHlk
UG5uejA2RkZLYVU1T3p0ZGZmeTBXamt6VG4zNzY2Vi85NmxmczllVEprNVZwNE9USmsyVnE1
bStuVEpsU1YxZDMvdno1d2NIQkN4Y3VoRTJpTlh2bzhYais1My8rUjdubDBLRkRIby9IdUFi
eHhaa3paL0x6OC9mdDI2Y3NIN2FIcXJlUkRVaFlsSG42My83Mk41NytEdzRPRmhjWFYxVlZl
VHllbnA0ZWNVZGxudjc1NTUrSEhmbXdGWUtZZyt0ZWdDNkJRR0RHakJsdnZmVVdlL3ZtbTIr
eTYxNmVlKzY1dSsrKysvang0MzE5ZlljUEg2NnNyR1FGaHFYcDdMcVhwVXVYS3E5N1diWnNH
Vi9udmV1dXV4NTk5RkdabXZuYjhlUEg3OWl4SXhRS2ZmSEZGNVdWbFpGcCtyLy8rNytYbDVk
LzlORkhvVkFvRkFydDM3OS81c3laYTlhc1laOW1aR1R3ZFNmTm12bUxHMis4Y2ZQbXphcks5
WHFvVjIxa0F4SVdRc2pQZnZhenMyZlBuajE3OXA1Nzd1SEw5SlRTdXJvNlFzaXJyNzZxdVdO
VlZSWGJrUzNFaHgzNXNCV0NtSVByWG9BdUN4Y3U1Q0xDZVBqaGh4Y3VYRGd3TU9EMWV0bEZG
MFZGUmZ5M1Uva0ZnYVNrcERGanhwU1dsajcrK09QODZoUkthVEFZWEx4NDhkaXhZOGVPSGJ0
NDhXSiszYVNrcHIvMTFsdTV1Ym5KeWNuLzhBLy9zSGJ0MnNnMGZYQndjTzNhdGNYRnhhTkdq
Um8xYWxSeGNmRmYvdklYL3VtcVZhdkdqQmxqVUxQeWhSTGpIdXBWRzltQWhJVW9ybnRadUhB
aHY1eUdVcnB0MjdacDA2YjE5ZlZwN3RqZDNmM3JYLzk2OU9qUjJkblp5dXRlOU9JS1d5R3dH
R2c2QU83aTNudnY1WGNrMkxOQ1lBeXVld0VBVUVycHdNQkFkWFYxWVdFaHYvclFiaFVDR1ZR
aURrMEh3S1VRUWp3ZVQydHJxMjByQkRJME5UWDE5dmF5MTcyOXZianVCUUFBRXBqVzF0WlBQ
LzIwcjYrdnI2L3YwMDgvYld0clUzNEtUUWNBZ0VTaXU3djd3SUVEZnIvZjcvZTN0cllxZndD
bjBIUUFBRWhvc0o0T0FBRE9BWm9PQUFBSmpJdXVaVHkrZCsveHZYdmozUXNBQUxBT3gycDZY
eWkwL3BaYjF0OXlTMThvRk8rK0FBQ0FSVGhXMHo5NDZTV3Z4K1AxZUQ1NDZhVjQ5d1VBQU9L
RFF6VDkvTW1UYS9Mem1hYXZ5YzgvZi9Ka3ZIc0VBQUNtRUF3R1cxdGIrYldNcW44MjZSQk5y
MSs4bUFrNmU5UXZYaHp2SGdFQWdDbnMyN2Z2MkxGanZiMjl2YjI5UjQ4ZVZiazlPMFRUR1U4
OTlaUk1zYTZ1THV1THlaZnM3ZWlJUzd1STE1cDJFYTgxN2RvODNtancrWHpjWUdkZ1lNRG44
eWsvZGFPbUh6eDQwUHBpOGlVdmJOb1VsM1lScnpYdElsNXIyclY1dk5IZ2lqeTl0N2YzeElr
VHYvM3RiNGVHaGs2ZlBtMzgvTC8vKzc5aHl3d05EWjA4ZVRLR3RjbVg3RHAyTEM3dElsN0Vp
M2d0aTNkb2FPanJyNzgrY2VLRS9COEtuRUFnNFB6MWRNWlRUejAxSk1HcFU2ZXNMeVpma3Jh
MXhhVmR4R3ROdTRqWG1uWnRIdStsd2liZ1JrMEhBQUE3RUpuUXVlSzZGd2J5OUdoS0lsNXIy
a1c4MXJScjgzZ3ZGWTRJTzY2bjE5ZlhGeFlXcHFhbWxwYVd0clMwOE8wclY2N2svK2Z3NjYr
L25qMTc5c2lSSTJmUG5zMytoNzI0UlFYeWRBQkFBaEdaZnRyeHVwY0hIbmlndmIyOXU3dDcw
NlpORXlaTVlCdmIydG9tVFpyRU5YM2V2SGtyVnF6bzd1NWVzV0xGL1Buek5iZW9RSjRlVFVu
RWEwMjdpTmVhZG0wZTc2WENFV0hIUEoxejRzUUpqOGRES2UzdTdpNHVMdDY3ZHkvWDlBa1RK
cHcrZlpwU2V2cjBhYWI3NGhZVnlOTUJBQWxFWkxKcDMrdGVUcDA2VlY1ZXZuUG5Ua3JwMHFW
TFgzenhSVW9wMS9RUkkwYXd2eS82Ky91VGs1TTF0M0Q2Ly83M0M2Kzg4dVR2ZjA4UEhCZ2FH
akorUHIxelo5Z3k5TUNCVTZkT3hiQTIrWkswclMwdTdTSmV4SXQ0TFl1WEhqancvMEtoQzYr
ODB0UGVIbHRkalp1bXQ3YTJlanllTFZ1MnNMZEpTVWxFQWFVMEt5dExsWldMVzFRZ1R3Y0FK
QkNSaWFjZC9kT3JxNnV6czdOMzc5NHRmc1R6OU1yS1NyNTZYbGxacWJsRkJkYlRveW1KZUsx
cEYvRmEwNjdONDcxVU9DSlVJcTRpUHBwT3J1VGl4WXZLajlpTHI3NzY2cWFiYmtwTlRiMzU1
cHRQbmp5cHVVVUY4blFBUUFJUm1YN2FVZE5OQW5sNk5DVVJyelh0SWw1cjJyVjV2SmNLUndR
MEhRQUE3SWdaTXVoR1RYZkc5N3piOGhyRUcyVkp4R3ROdS9CN2lRM0Q4bVhFTTU3eGpPZTRQ
MGZteS9qT08rKzB0N2VmUG4yNnY3OWZzNEJETkoyQlBEMmFrb2pYbW5ZUnJ6WHQyanplUzRX
SHo0VUxGNDRmUDc1Ly8vNm1wcWI5Ky9jZlAzNzh3b1VMeWdKdTFIUUFBTEFEMGNoZFgxL2Y2
ZE9uMjl2YjMzbm5IZVYyTjJxNk03N24zWmJYSU40b1N5SmVhOXAxNlhxNjZNc29ib0V2SXdE
QTJaaWhybmJ4WlJTM3dKZlI0bllScnpYdElsNXIyclY1dkpjS200QmRmQm5GTGZCbEJBQTRt
NWlvcUMzOFhoaW5GTDZNNGhiNE1zTEhEdkVpWHFmR1MyUG55MmdYVFZmNU1vcGI0TXNJQUhB
MmtZbG5Zdmd5aWx2Z3kyaHh1NGpYbW5ZUnJ6WHQyanplUzRWamdTMDBYZlJsRkxmQWx4RUE0
R3hpSXFlMjBIU1RRSjRlVFVuRWEwMjdpTmVhZG0wZTc2WENKdUJHVFFjQUFEc1FtZEFGZzBH
Yi9qL1NtSU04UFpxU2lOZWFkaEd2TmUzYVBONUxoU05pMzc1OXg0NGQ2KzN0N2UzdFBYcjA2
TDU5KzVTZk9rVFQ0Y3VJWnp6ak9iR2VJL05scEpUNmZENTJWVGVsZEdCZ3dPZnpLVDkxaUtZ
em5KZW5rdzJFYkNEV3RHdUhlSzFzRi9GYTB5N2lOU29jRWE3STB4bk9XMDgzMEhRQVFLSVRt
ZEFGQWdHc3AxOUJBbjNQZHd5UmppSGs2YWEwaTNpdGFSZnhHaFUyQWJ2NE1zcTRNTHJFbDFH
Wm05ZVMybHBTRzkvK0FBQk1Jakw5dE9OOXBKRzVNRHJQbDVGck45Tng5cGl6TW9mTGVnV3By
ZERSZExmbE5ZZzN5cEtJMTVwMkxjalRtWWh6S2JlRnBuT0c1Y0xvUEY5R2xhWVBFVUkyRUsv
WDJ6RkVXSHB1b09rQWdFUW5NdG4wKy8wLy9QQ0R6K2U3Y09IQ2hRc1hkdTNhcGZ6VUxyNk1N
aTZNenZObHJIL3NNZmJhNi9XMjVLeXFKYlV0T2F1YWM1NXJ5VmxWUVdycGdRTVZwSFo1enFx
WXQ1dUlQbmFJRi9FNktWNGFoUy9qcDU5KzJ0VFUxTm5aK2M0NzcvajkvaSsvL0ZMNXFWMThH
V1ZjR0ozbnk4alh5bXRKYllYd0dCb2FJa3Yya0NWNzR0cEhBSUJabUNHdGR2RmxsSEZoZEo0
dlk0V1dwbGZsUENlajZXNWJmMFM4VVpaRXZOYTBhODE2dXUxK0k0M01oZEY1dm94YzB5K0p1
SmZ3RjB6S2thY0Q0R0RNVUZkY24yNVJNYzJTU2sxbjhrMlc3Sm56NEVZdTVjalR6V3NYOFZy
VEx1STFLbXdDYnRSMCs4RDFtZ3U2OGpHRVBCMEFSMk9HRExwUjArM3pQYStwNmNqVHJXa1g4
VnJUTHVJMUttd0NEdEgwQlBWbEpFdjJzTmZGSzNhUUpYdFV6M3g3M1B1Slp6empPZWJQRWZz
eXdqOWRqWDIrNTVHbkR5R1BzNnBkeEd0TnUvQmxqQ1ZZVHdjQUpCQ1JDUjM4MDlYWTUzc2Vl
Zm9ROGppcjJrVzgxclRyMGp5ZFg1bk90elEwTk9UbDVTVW5KK2ZtNWpZME5GQjMrRElpVHdm
QXpVU21uL2IxVDFkcStyaHg0L3grZnlnVTh2bDhHUmtaMUNXK2pNalRrY2RaMVM3aXRhWmRW
MS8zb3RUMGtwSVN2OS9mMDlQajgvbkt5c3FvUzN3WmthY0Q0R0lpVTA0N2VnTXdsSnArNE1D
QmNlUEdFVUxHalJ0MzRNQUI2ZzVmeHJtTDE3UFhaTW1ldVl2WHMrYzVEMjVrci9uMm1MZWJp
RDUyaUJmeE9pbGVHb1V2bzMzOTA1V2FQbTNhTkw3MmN2MzExMU4zK0RJaVR3ZkF6VVNtbklt
aDZabVptWHp0WmZ6NDhkUWR2b3hreVo1TC85NEk2K21XdDR0NHJXa1g4Um9WamdnN2Fyckts
NUZTV2w5ZjcvRjRrcE9UcDA2ZCt1YWJiMUozK0RKcWFqcnlkQUJjUWt6azFCYWFiaEtKbUtl
ei95S05QTjM2ZGhHdk5lMGlYcVBDc1FDYWJpUElrajNNTUIxNU9nQXVKREtocys5MUx6RW5F
Zk4wVWRPUnAxdlRMdUsxcGwzRWExUTRGamhUMHhQWGwvSCs0cG9LVWd0ZlJqemoyVzNQRWZz
eXFuQ21wak1TTVU4WEg4alRyV2tYOFZyVEx1STFLbXdDYnRSMG02QjN1UXZXMHdGd0NaRUpI
ZGJUMWRqa2UxNVAwNUduVzlNdTRyV21YY1JyVk5nRTdPTExPREF3c0hMbHlzbVRKeWNsSmJI
dGp2ZGw3QmdLazZkejBZOTNUd0VBcGhDWmZ0bzNUMWRxK3FwVnE2WlBuOTdlM2o0NE9NaTJP
TjZYc1ZibkVrYWVwL01Dc1czWG1tTHlKWkhIV2RNdTRyV21YV3Z5OUo2ZW52ZmVlNitwcWVu
czJiT3FqK3lpNlI2UFIvWGZPaHp2eTZoM1dUcC9WQmhxT2dBZzBZbE1PWm1nSHp0MjdMdnZ2
dHU5ZS9mNTgrZVZuOXBGMDVPVGt4OTU1SkhSbzBkN1BKNGRPM1pRRi9neVZwQmE3c1ZJdEh3
WmwrZXNJdkJsUkx5STE0bngwaWg4R2Q5OTkxMHUxOTk4ODAxTFM0dnlVN3RvK29RSkUzdytI
L05sdlBycXE2a0xmQm1ScHdQZ2NpSlRUcFZXZi9ubGw4cTNZVFI5Mzc1OStmbjVTVWxKbE5J
RkN4YlUxZFZGMWdsTmxKbytmLzU4bjgvSGZCbXpzN09wQzN3WjlhU2NyNmNiYTdyYjFoOFJi
NVFsRWE4MTdWcmp5eGo1YjZUWFgzLzlybDI3bVBoKzlkVlhVNmRPamF3VEtrUmZ4cTZ1cnAv
ODVDZXBxYWw1ZVhsc1lkM3h2b3hoTG5xNThrSjFBSUR6aUV3L28vTGFUVTFORFlWQ1RIYlBu
VHVYbnA0ZVdTZXN3V0Y1dXJHbXV5MnZRYnhSbGtTODFyUnJkLy8wTys2NFkvUG16WVNRcnE2
dUJRc1d6Smt6SjdKT1dBUHlkQUJBQWhHWjBFV2w2VjFkWGZmZGQxOTZlbnA2ZXZxY09YTysv
ZmJieURwaERjalRveWxwODd3RzhVWlpFdkZhMDY1TDd5T05PWW5veTZqcHhhajViSWZlNGhu
UGVJN3RjOFMralBhOWp6VG1JRStQcHFUTjh4ckVHMlZKeEd0TnU1Ymw2WU9EZzZwRkdJYTJw
aE45b3VtRTJXQTlIUUNRUUVTc2RmMzkvVWVPSFBINWZPZlBuMjlxYWxKK2hEemRvbUppU2VU
cERPUngxclNMZUsxcDE0STh2Yk96czZXbHBhMnRyYXVycTZtcDZjaVJJOHBQN2VMTHlGaTVj
aVhmNkhoZlJ1VHBBTGljeVBUem80OCtVbm04S0lubjJvdXF0cmEydGttVEp2R05qdmRsUko3
T1FCNW5UYnVJMTVwMlhYM2RpMUxUdTd1N2k0dUw5KzdkeXpjNjNwY1JlVG9BTHNjTVhiV0xw
aTlkdXZURkYxOVViblM4THlNUkhCbkpsYjZNL0RtMjdjWXJYcjFuK1BZaFhoZkdTNlB3WlRS
R1Y5T1p0bHEyOXNMK3ZaR3lGY2Y3TWlKUEI4RGx4RkJPT1hiSjA4V044R1hFZXJxcDdTSmVh
OXBGdkVhRlRTRE8xNzJJdVQ5L0MxOUc1T2tBT0JzejFEV01wbS9mdnQzajhTZ1hSc3pvUkt4
QW5oNU5TWnZuTllnM3lwS0kxNXAyN1o2blQ1Z3dZZHUyYmYzOS9XYTBIWE9RcHdNQUVnZ3pa
RENNcG1kbVpnWUNBVE1hTmdQazZkR1V0SGxlZzNpakxJbDRyV25YN25uNnM4OCt1M0xseXU3
dWJqUGFqaUh3WmNRem52R2NXTThSK3pJYUUwYlRHeG9hUm8wYTVUQVBMNXQ4enlOUFp5Q1Bz
NlpkeEd0TnUzYlAwN096c3hzYUdyQ2ViZ1pZVHdmQTVaZ2hnMkUwZmR5NGNWaFBqMGt4c1NU
eWRBYnlPR3ZhUmJ6V3RHdjNQTjJrOVhSeEphZSt2cjZ3c0RBMU5iVzB0TFNscFlYQ2x4RjVP
Z0JPSjdhNnlnaWo2Wlo1QXp6d3dBUHQ3ZTNkM2QyYk5tMWk5LzNEbHhGNXVxbnRJbDVyMmtX
OFJvVk53SGJlQUNkT25QQjRQQlMrak1ySEJoTHZ6Z0lBWW84WnVocEcwNU9Ta3N4b2xTRnEr
cWxUcDhyTHkzZnUzRW5oeTZqY3ZvSEF4dzd4SWw0bnhVdXQ5MlZrVEpreTVlelpzN0Z0a3FQ
UzlOYldWby9IczJYTEZ2WVd2b3o4NGZWNjQ5MVpBRURzTVVOWHcyajZpeSsrK05CREQxMjhl
TkdNdHBXYVhsMWRuWjJkdlh2M2JyNEZ2b3o4VVV0cVk5aXVOY1hrUzJLOTFacDJFYTgxN2Rw
OVBkMmszMGpGT2xWYkxsNjhDRjlHWTAwSEFDUTZNWkZURmZIOGpUVG1PRFZQcjBDZWpuaWpM
b2w0clduWDdubDZZdUhVUEYxVDB3RUFpWTRaTWhoRzAvZnQyNWVmbjgrdWZsbXdZRUZkWFow
Wm5ZZ1Z5Tk9qNmFITjh4ckVHMlZKeEd0TnUzYlAwNisvL3ZwZHUzYXhKZSt2dnZwcTZ0U3Ba
blFpZWh6dXkvaCtjZHg3aTJjODR6bTJ6L0h4WlV4TlRRMkZRa3pUejUwN2w1NmVIdHZtWTR0
VDgvUWhyOFk5UjI3TGE2eU1WM21UbHh2aU5iVmR4R3RVMkFUQ2FQb2RkOXl4ZWZObVFraFhW
OWVDQlF2bXpKbGpSaWRpaFZQWDB3a3NYNndGTis0Q2F6QkRCc05vZWxkWDEzMzMzWmVlbnA2
ZW5qNW56cHh2di8zV2pFN0VDcWZtNlpxYTdyYThCbmw2bENWeGZLMXAxKzU1dWttSVY3dkx1
REM2MXBjUmVickZJRThIMW1DR3V0ckZ3MHZHaGRHMXZvekkwODFvRjNtNk5lMGlYcVBDSnFD
cjZSOSsrR0ZoWVdGS1NrcGhZZUZISDMxa1J0dEtUWmR4WVhTdkx5UHlkR3RCbmc2c3dReGQx
ZFgwb3FLaWwxOStPUkFJdlB6eXl5VWxKV2EwcmRSMEdSZEc5L295THRrREh6c3I0NTM3ZEk2
cjRuWGI4YlZEdk5SNlg4Yms1T1Nlbmg1S2FTZ1VVZ2xvckZCcXVvd0xvMnQ5R1pHbld3elpR
SkNxQXdzd1ExZDFOVjBwdUxIOTkwYWExY3E0TUxyV2x4SHI2V2EwYTd5ZXpqWGREZkdhMmk3
aU5TcHNBa2FhcmtsTVdoWHJsSEZoZEswdkkvSjBpMEdlRHF3aEpuS3F3bzBlWGpiNW5rZWV6
ckJoSG9jOFBZWWxFYTlSWVJOd282YmJCT1RwdGdWNU9yQUdNMlRRalpwdWsrOTU1T2tNRyta
eHlOTmpXQkx4R2hVMkFZZG91ck45R1l0WDdJaDdiMTMxVERhUTRnM3d3c1N6dWMveDhXVk1M
SkNuUjlORG0rYzF5Tk9qTEluamEwMjd5Tk5qQ2RiVFFVekFlanF3QmpOazBJMmFicFB2ZWVU
cERCdm1jY2pUWTFnUzhSb1ZOZ0c3YUhwRFEwTmVYbDV5Y25KdWJtNURRd09GTHlQeTlQaUJQ
QjFZZ3hsYWFoZE5IemR1bk4vdkQ0VkNQcDh2SXlPRHdwY1JlYnJKN1NKUHQ2WmR4R3RVMkFU
c291a2xKU1YrdjcrbnA4Zm44NVdWbFZINE1pSlBqeC9JMDRFMW1LR2xkdEgwQXdjT2pCczNq
aEF5YnR5NEF3Y09VUGd5d3BjeGZ2SE9mVHFIYkNEdWlkZHR4OWNPOFZMcmZSa3RadHEwYVh6
dDVmcnJyNmZ3WlVTZUhqK1Fwd05yTUVOTDdhTHBtWm1aZk8xbC9QanhGTDZNV0U4M3VWMnNw
MXZUTHVJMUttd0NkdEgwK3ZwNmo4ZVRuSnc4ZGVyVU45OThrOEtYRVhsNi9FQ2VEcXpCREMy
MWk2YkhCT1RwMGZUUTVua044dlFvUytMNFd0TXU4dlJZZ2p3ZHhBVGs2Y0FhekpCQk4ycTZU
Yjdua2FjemJKakhJVStQWVVuRWExVFlCQnlpNmZCbHhITU1uK0hMaUdjTG51SExHQjdrNmRI
MDBPWjVEZkwwS0V2aStGclRMdkwwV0lMMWRCQVRzSjRPekVDY1ZHYklvQnMxM1NiZjg4alRH
VGJNNDVDbng3QWs0dVc0UzlNSEJnWldybHc1ZWZMa3BLUWtRZ2lGTHlQeTlQaUJQQjJZZ2Jz
MGZkV3FWZE9uVDI5dmJ4OGNIR1JiNE10b2t6eGROUkhka01jaFQ0OWhTY1RMY1plbWV6d2Vu
OCtuM0FKZlJwdms2Y1BOV0IyUTVEb2dCR0JEM0tYcHljbkpqenp5eU9qUm96MGV6NDRkT3lo
OEdWWGJuODZKVmJ2RGpaYzdGRXJXUmpZUTF0dkU5ZTJETHlQaU5TTmUxVm5zY0YvR0NSTW0r
SHcrNXN0NDlkVlhVL2d5cWg1eFRCc0o4blFBWW9DNzh2VDU4K2Y3ZkQ3bXk1aWRuVTNoeTNq
bHcrdjF4cXJkNFJhckpiWERxNDBROWpXUXVPdXRXRStQWVVuRXkzR1hwbmQxZGYza0p6OUpU
VTNOeTh0akMrdndaVlErVk1KcUpjTnR1cGJVeHJHM01RRjVPakFEZDJsNlRIQndubDRocUtS
dDgzU3U2WW1ieHlGUGoyRkp4TXVCcGc4YkIrZnBvcVpiQnZKMEFHSUNOSDNZSUUrUHBvZGlN
VFlGa2FmSHRsMGJ4bXRxdTRpWEEwMGZCbzczWmF3Z3RYSG80WVppc29IVUZOY01hNithNHBy
YWVQUTJ0bEhEbHhIUE1YOG1HNGh5QzN3Wnc0TThQWm9laXNXOFhpL1pRTnlXcDdNa0hYbDZy
RW9pWGc3eTlHR1RRT3ZwWkFNWjN2WHA4YmlWdEpiVWRneXBOVjFtcjRSZVQxZHBPZ0N4QXBv
K2JCSW9UemZRZE0wOFhkUjBDL0lhcHM3R2VibzRUWkduRzJPM2VNMXVGL0Z5M0tqcEsxZXVa
S2FNMU9tK2pMV2tOaUh5OUxCSnQ0R21KeWpJMDRGSnVFN1QyOXJhSmsyYXhEWGQyYjZNQnBw
dWh6eWRpWnBNbmk3S04vSjBZK3dXcjludElsNk91elM5dTd1N3VMaDQ3OTY5WE5PZDZzdkk5
S0xDM25tNmdhYXJNTkQwQkNYaDh2UUU2cXJMY1plbUwxMjY5TVVYWDZTVWNrMTNxaS9qM0tk
enZGN3Y4cHhWWkZpK2pJdlhSOW51c09KbDNvcTFwTFlsWjFVdHFUV29UZlVwMjlLU3MwcStY
YnY1OXJIWUU4aVhjZG5UczZPSjEreHh0dHZ4aldPODd2SmxaUC9laUVPZDY4dm85WHByU2Ez
TjgzU3YxOHY2aVR6ZC9pVDBhTHNLZCtYcEhKNm5POVdYa1VtZWdhYmJZVDJkcS9tbHJpcm1J
dGJUbzJ3MzV2SFdsTlRFc0VMN3g0djFkR1BzcStsTzlXVzhKSGxlVzErZmJxRHBZa25OZlUz
dW9Ja2dUd2NtNFZKTmo0WkV5ZE9ORjE3TXk5T05wY280VDlmTFc1R25EN2RkNU9uV3RHdkRl
S0hwd3lZaDh2U0tpQmJUbzgvVHlRYkNWc25EWnFEOGlwZUt5dytEMU5VWmVib3lPaDVzb3FU
cXRZWi9TQUU3d0E0UU5IM1lKRVNlSGxiVFRjclR1VkxyL1M4NlhrelU5RnBTeTc4UFZKZXg2
Mm02cXFRQk1ubWNmRzFET2lNamFyUjRQYjd5TmQ5aS83eTFwcVNtWXlpOHB0c3dielcxWFZ2
RkMwMGZOZ25reTFoQmF1OHZyaUhTam93L1BrZm5GT2oxZXU4dnJxa2d0Y1kraThVYmlvY0lZ
U1haYy9IN3hiV2tscmt0cmxtelJsV25XTnVsdlRZVUQxMzJPSXpld1M1NmwwUlZUNVRPaTh4
N2tudEpjbDlHc2VjeDcxVk1ubXZESFZPN1BjZDMzT0xTT3BzNThHVWNOaEhrNlpMcnk1SzF5
WlNNT0U4WDAwek5KUUpWdnNsTEt2TnVnKzd4U3kxL1hIanBJTXFFWFZ4Mkg3cHlHUGx5RFd1
WC9TZFZnM0UyeUd1VURVV1RUMmtNRkNIdm55cTV0SVVRNVhxUlFaNnUvTWc0OFRjSXg0dzhY
V2F4Sys1NXEzSm1XdEN1d2U4bGVzV01sN0NRcDhlQkNOYlRJMWcybFN5dlZ5eXl4WFN5Wk04
UXVhS3JvcmlJaXFOOGhOVjB4aFhGT29oSzAxWFh3TlR5Mm9oYTA5bnlDMStIMFJ0blplY05R
bEJWb2hvSDQ2T2dYRTNTZkt1NkRGL1Y2SlhWYVdpNnpCUXlkYjNiZ2g4d1l0Si9BMDAzZFh6
azJ6S3ZHOUQwQ05IVWRIRTBXZjdJUDlYTHZQajZzbkd4a2cwbHh2bXlxdDJ3MnEyWHB5c2xp
V3dnSlJ0S2hnaGhPZVlWSFJOMHAyUkRTZTJWMHF3WEw5bEFWQms2ZXlnMzhuaUgrRFU4Vjhv
ZjEzVFc3cVdQaU1ib3NkZHpWdWFveDVhb0EyRzFzWGcxS3hISFdYblV2RjZ2TW5EV0s3WU1y
ZFIwMVY2c3ZQTDRLb2ZhNi9XcWdsS09qQXJsZWpkdGF4T25pbDRVTXZKblFaNnV1VjR2bjdl
U3kzOFA4ZHBVVVhpOVh0WGZuUWJ5S2grSWFnQTFhMVlXTTlaMHBXNm9VUGJjNFBpS0I5b01H
YlNMcHRmWDF4Y1dGcWFtcHBhV2xyYTB0TkJJZlJuRjRZdnlJVXFrWmhtWllwZHE2eGoybGVs
c2w0ckwwc004elZXL1lmS1BLa2h0eHhEaFpYaDVQVTFYUHJqMkdXaTZNdDRLaGFiL3VNYmlK
VVBlSDF1dlVDcW1ZcFZEYkoxMW00VXdSSWd5TGpGZXljT25HaXZXZ1FxZEI2dVdLUTZMam0z
aHZ3K0xxVDN2dG5FM1ZCM21vc2FIWFhYQ0t3ZUVYUGxOb3lwRHJ2eWJRMDlFTkN2Uks4RGpW
ZlZmVDh2MFpPdUthYThZQkRHckVBK29ja2hWYWl0NTZEVzZKSGVTUnY5UU5hUTNYUjJ1NlE4
ODhFQjdlM3QzZC9lbVRadllmZitSK1RMV0NpYzhreHYrMXV2MXZuK3FoRjMrd1EvQWoxcERM
dVZmUTRTdzlFZXBJRnhyT29aK1ROUFdyRm5ERllIdHlCNnNHS3VRRlQ1VlV2S2pVQTRyVDcr
czZjckgvU1UxZXRxa1daSzFPK1FsUXgySzFRWkZSc3k2cDFMelMzc3BaTDNtY3J0TWZKWEtl
Mm1RTDM4TjhKTDhVNjZuYkVEWU04M0pNZEJadlhpVjN5dEs1V1VMNVdIbFcyOEEyWUhqaDd1
QzFKNHFLUkcvbnpRZmJGNnBqcnR5YnJBdGMxYm1LS2NmRDRIdnlEYnl3OEcvRGxsMHJCaWZ0
ME9Fc0VDVSs3SmlGZnhmbWhEaTlYcjVuMDJzSkN2RGVzZ0ZsSTFlN1pXVG1idEVxQ1JKL0R0
TWVSN3hIaDV2eXhFSHR2YnlhUE12Uzk1dTdlVmpwL3dlVlo3Q2E5YXNxVlZNQUhXWmNPa0FB
Q0FBU1VSQlZQWnA3ZVdycy9nNHN3RmtKVlc1Z25KZmZueDVaN2d4QmcrZm43K3FBVlRHeTdm
VG5CemVCRzlYVkhiMlY0c1pXbW9YVGVlY09ISEM0L0hRU0gwWkpXVXVqbyt3bXE2ZHAxK1pM
RWZlcmtSVlExY0t1dkdPeWkrYlMyZDRMSG9iNTJPazBIUTg4SWorb1Z5bDVCdGRvZW1uVHAw
cUx5L2Z1WE1uamRTWGNYbk9xZ3BTYS96OC9Pdy9oUzJ6UEdmVi9TVTFNYXlObDV6N1JnN3BJ
SFBmeUNIeXZvd2RaTzRiT1RGcnQ0TVl4RHQwdVl6ZXM2cGRzVGJlVzhrZVZ1VThaOFk0UjNO
ODV6NmQwekZFVEdyWGh2R2EyaTdpVmM0cjVSYUgrekpTU2x0Yld6MGV6NVl0VzlqYnlId1pL
K0w5aFJ6MjhXUGFPOHc4ZmNnYlZlWW9tYWZyWmVoNisycHVTZlE4WFdZdENBODhodnZnYTJL
WDNqbzdUNit1cnM3T3p0NjllemZmRXBrdm84eklTcTVFeDdaWXhaWHIyZ2FhcnIyZUxnamwv
U1UxdklCeXUrYksrMUM0SlJTTjd1azhsUEhxcVR6YnlOb04rMVZVbGZPY0dlT3NQcDJ1L0ZW
QXBrSTJrbEcyYTAyOFF4SmZvaWJONXdqaTFleHR6TnUxVDd4NkQ0ZHJPcm1TaXhjdlJ1akxL
Snk2b3NacGJtUlhhNGdibFNVdlhhOHQ3Q3NLcTBHN1YwaWs4cTFPZW03R1kranlReU5laVR5
ZHg2dlVkRDU2eWxaNEFkNlc1bGlwZXNMZWlvZmowblg2M3ZESFYyUGZLNzkrcmhqenl5OVUx
K09UeXo5Tjg3bWhtZ3lhRTBhMVVXOWVpZkhxelVuMTRJUUx6YmhkWlcyNjdXck9EUzBoRmt2
cXpTdmx3TEszZXFNbkRxRE04ZFdOMXlzUnI4UXgwanZvbXZ1cW1oaTY4aFQ0Y2J1ek5UMG1Q
UFhVVXpLS1Z2SitpZlhGNUV2T2VYQ2pXdTR0YVRmNllrd3lkRXZxUkhRcFhzdkgyYUNZVWl0
amYzenJjb3dIaEcyL29qYit4Uk5OdkN0MkdCVzQvUFdtMGE2cURDOTV1Y0pMcVlEZThlWHhH
alN0R1lWbTY4cEFZaklzY3JNMGt1TXJWRnVoTk5udWNNMTFMOUVncWVsNDRHSDhxSkJZZzhJ
RGorRStWUE1LbWg0ZWgrVHBZZk1hYzlwRnZJZ1g4Vm9XTDRHbUc4TjlHVWtIS1g2L0dNOTR4
ak9lYmY0TVg4YndJRTlIdklnWDhTWkV2QVI1dWd4WVQ4Y0REendTNVFGTkR3L3lkTVNMZUJG
dlFzUkxvT2xVMHBkUmJqVHh3QU1QUE9MNzRKcGUvK0NEMzMvMVZheDBNcEUwWGNhWFVXWW9u
ZkU5NzdhOEJ2RWlYaWZGU3hTYTd2VjQxa3lmL3NGTEwvVjFkMGV2azRtazZUSytqSktqaVFj
ZWVPQVIzNGRTMDlsancvLzVQMzk3NTUwb2RUS1JORjNUbC9IbzBhTlBQUEhFaW1YTEhydnZ2
djk3NjYyUEwxejR4Qk5QR0QvLzd2Nzd3NVo1Zk9IQzMvem1OekdzVGI1azFTOStFWmQyRVMv
aVJieVd4ZnY0d29WTXRaYi85cmMvYXZxdHQvNXR6NTRvZFRLUk5GM0dsMUdtbmkrLy9OTDZZ
dklsdTk5L1B5N3RJbDVyMmtXODFyUnI4M2lWc0xXWDkvLzhaOWV0dmNqNE1zclUwOVBUWTMw
eCtaSVhObTJLUzd1STE1cDJFYTgxN2RvOFhpWDFpeGQvMzlrNTNMMzBTQ1JObC9GbHRMNVhN
YWYvN05sNGQ4RlNFSyt6UWJ3V2swaWFIcGIyV1AvSEVBQUFTQ3djcGVtSkFpRWszbDBBNW9K
RDdHenNmSHloNlNiQy9yL0hxRkdqcGsrZi90eHp6L1gzOXhzVVU4NlMrdnI2d3NMQzFOVFUw
dExTbHBZV1pXSHh4cXV3dDJJQmt5Q0UvTmQvL1JkLyt4Ly84Ujk2cC9xd2pob09zVTJRUDc2
Mk9vV2g2U2JDam5GdmIrL0hIMzk4NDQwMy90dS8vVnZZd293SEhuaWd2YjI5dTd0NzA2Wk5x
aXQ4eEJ1dnd0NktCVXlDRURKNzl1ekJ3VUZLYVc5dmIybHBxZDQ1UDZ5amhrTnNFK1NQTHkv
UFg4ZnhGSWFtbTRqeUdIZDBkRng3N2JYaWRzM0NuQk1uVG5nOEh1V240bzFYWVcvRkFpWkJD
UG5qSC8rNFk4Y09TdW5telp1ZmVPSUpmcGhVUjFQbXFPRVEydzM1NDJ1dzBmcFRHSnB1SXNw
ajNOdmJtNUtTSW03WExNdzRkZXBVZVhuNXpwMDdsUnZGRzY4MGI4VUNGa0FJT1g3OGVFVkZ4
ZURnWUdscDZjbVRKL1hPK1dFZE5SeGlteUIvZlBVMnh1VVVocWFiaVBJWUh6MTZOQ2NuUjl5
dVdaaFMydHJhNnZGNHRtelpvaW9tM25nVjlsWXNZQkxza04xMzMzMi8vLzN2Zi9HTFgxREZR
VlFkeldFZE5SeGlteUIvZkRVM3h1c1VocWFiQ0Y5UFAzVG8wT3pacy9sNmV0Z0pVVjFkbloy
ZHZYdjNickdZZU9OVjJGdXhnRW13US9iKysrOFRRdmJ0MjBmMXovbGhIVFVjWXBzZ2YzekZq
WEU4aGFIcEpzSitDaDg1Y2lTNzdxV3ZyNDl2RjRzcGZ6cFhiYmw0OFNMZlJienhLdXl0V01B
a3hCTmI3NXlYT1dvNHhIWkQvdmphNmhTR3BnTUFnSE9BcGdNQWdIT0FwZ01BZ0hPQXBnTUFn
SE9BcGdNQWdIT0FwZ01BZ0hPQXBnTUFnSE9BcGdPM1kyek1CRUJpQVUxUFlIcDZlcFl0VzNi
MTFWZVBIVHYyK2VlZmozZDM3QTRoNUlVWFhxQ0dwcW1BMDk3ZVRnakIvNW1Sd1ZaVEM1cWV3
Q3hmdnZ5KysrNzc1cHR2dnYvKyswY2ZmVFRlM2JFN2hKQ0Nnb0xCd2NIcDA2ZkgvY1N6UDJ2
V3JCa3hZc1NhTld2aTNaRUV3RlpUQzVxZXdFeVpNa1gxdjh5VjgwbDVIL1B5NWN2VDA5UEx5
c3JFWXU2QkVITExMYmVzV3JYcTFsdHZWUTZPYXRCZWZ2bmw4ZVBIWjJabWJycjh6NExkT1Z4
MzNISEhndzgrZU1jZGQ3QzNaV1ZsN0g4N05EYzN6NXc1azFMYTF0WldVRkNRbHBhMllzVUtZ
eU1VeHlOT0xUYXZVbEpTK1AvRStQM3ZmLy9yWC8rYVV2cXJYLzFxeVpJbGZNZVlkd2FhbnNB
a0p5ZXIvbmVTbnFhLzhNSUxnVURnb1ljZXNyUi9Ob01ROHNZYmI0d1lNV0xyMXEyYUE4VmVy
MSsvUGhnTU5qVTF1ZGtCTVJBSWpCa3o1cHR2dmhrelprd2dFS0NVcmwyN2x2OERoM1hyMWxG
S1MwcEtObTdjR0FnRU5tM2E1RTRwNStoTnJmNysvbjM3OWsyYU5JbFMydGZYZCtlZGQvN2hE
Mys0ODg0N3VmV1RHVURURXhpRFBMMnZyMCtwNmIyOXZWWjN6bjRZNkxqeXRaN1ZtcXRvYkd6
ay9sT05qWTJVMG5QbnptVmtaSHo1NVpjWkdSbmZmZmNkcFRRbEpTVVlERkpLZzhHZ204ZUth
azJuOWV2WGV6eWVFU05HRUVLU2twTFlSMjF0YllTUXRyWTJVenNEVFU5Z3FxcXE3cnZ2dmxP
blRwMC9mNzZxcW9wU09tSENoTjI3ZDNkM2QyL1lzTUhsZnc2TFNHcTY1bXUzc1dUSkV2YXIr
L1BQUDg4WENpb3JLMis0NFlaNTgrYXh0OFhGeFgvOTYxK0R3ZUIvL3VkL3VubXNxTmEwU1V0
TGEycHFDZ2FEUHArUGJRa0dnNldscFhmZmZYZHBhV2wzZDdkNW5ZR21KekNoVU9qaGh4K2VN
R0VDdis2bHVybzZJeU5qL1BqeDY5YXRNOUIwZDU2QjRvbW5hWkVxbG5maGNPWGw1UjArZkpo
U2V2anc0Ynk4UExheHVibVpFTkxjM016ZXRyYTI1dWZucDZXbFBmNzQ0eU5HakdBYlhUaFdW
R3ZhUFB2c3N4a1pHUmtaR2F0WHIyWmJGaTFhdEdEQkFrcnBQLy96UHk5ZXZGamNNVlpBMHdF
QWtUTXdNUERXVzI5Tm56NDkzaDBCbDRDbUF3QWloQzBXNStYbC9mZC8vM2U4K3dJdUFVMEhB
QURuQUUwSEFBRG5rQmlhN3M0ZlhnQUFZTGdNVDlPSkRwb2xrNUtTcnJubW1qLzg0US9zSWxZ
cjZlenN2T21tbTBhT0hIblRUVGQ5OWRWWEZyZHVHZUw0TnpRMHpKZ3hZK1RJa2VYbDVlKzk5
eDdia3BlWGw1eWNuSmVYdDMzN2RzMTZHaG9hUEI1UGFtcnFqVGZlZVB6NGNVcnBsaTFicnJ2
dXV0VFUxSmt6Wis3ZHU5ZWFjTXhHSEM1eFN5Z1VldVNSUjdLenMvVW1OdFVhWk9OeklSSFJD
OGZyOWZLTjRyU1JxVWM1VmxsWldTYjEzMkxFS1NGS2tJd29pZWVkeklSVU1YeE43eEFlT3Bv
K09EaDQ4dVRKK2ZQbi8vR1BmNVRwU2d5Wk8zZnVpaFVydXJ1N1Y2eFlVVmxaYVhIckZxTWMv
OHJLeW82T2psQW90SDM3OW9rVEoxSktNekl5ZHUzYUZRcUYvSDUvUmthR1pnMVpXVmt0TFMw
OVBUMCtuKy9uUC84NXBYVHUzTG1IRHgvdTd1N2VzbVdMdzI2bk5MNnlzNnFxcXF5c3JLT2pZ
M0J3VUs4R2NaQWRJK1VxVkhGOThza25URnpZVzNIYVNOYkRXTEpreVpOUFBobkQzc1lSY1Vx
SUVpUWpTdUo1SnpNaFZaaW82ZXpGeVpNbjJhMnhIMzc0WVdGaFlVcEtTbUZoNFljZmZzaksv
T00vL3VPOGVmTnljM1BaalF6c3UwaHBrc0EzS21zV0hUbFVaR1ZsblQ1OW1sSjYrdlJwaDBt
U2lEait3V0N3dnI2ZVhWNVdXbHJhM056YzA5T3plL2R1WnRNaGtwV1Z0V2ZQSG5aeWpoOC9Y
dm5SeVpNblUxTlRuWFFicXJHbVQ1NDgrZDEzMzVXcFJ6bkloSkNNakl6MDlQU2YvdlNuSjA2
Y2lHRnY0NHZxTDVpaW9xTFhYbnROcWVsNjA4YWdIc2IzMzMrZm1abloxZFVWOHo3SEVlV1VF
Q1ZvV0tMRXp6djVDY2t4WGRQNysvdFRVbElvcFFVRkJhKysrbW93R0t5dXJpNHNMR1JsdUov
bm1ERmorTDVLa3dSVmJWVE9rV1BFaUJFREF3TzMzSEpMZjM5L2NuS3l6RUFrTHFyeDUzL1ZI
ang0a0ZMYTJ0cWFtWmxKQ01uTXpOUzdLYm11cnU3YWE2OGRQWHIwNDQ4L3JoeXViNy85dHFL
aXdtR09qOGFhbnB5Y3ZHTEZpdlQwOUp5Y25HM2J0aGxVb2h4a3h0bXpaNnVxcW02NjZhYVk5
emxlS0VmbXNjY2UrOFV2ZnFIY3FEZHRqT3RockY2OW10MkE0eGhVVTBLVUlIbFJVcDUza2hO
U2lYVjVlbkp5TWx0WUR3UUNUT1dKNHM0OW9tK1NRQVZORCt2SWtaV1ZkZWJNR2VyV1BEMFFD
R3pkdXJXb3FJaFNtcCtmNy9mN1E2R1F6K2NyS0Nnd3JtcnYzcjFUcGt4aHJ3OGVQSmlibTd0
aXhZcUJnUUV6dWgwdmpEVTlNelBUNS9QMTlQUzB0TFFZci9ZcUI1blQzZDJkbXBvYXc5N0dG
K1hJc0xOU2M1MWRPVzNDMWtNcDdldnJ5OG5KTWR2MnhIcVVVMEtVSUVsUlVwMTM4aE9TWSs1
Nit0ZGZmLzNMWC82UytVVm81dW1xWjlFa2dkY1c5cldTKysrLy84a25ud3lGUWs4KytTUkxM
aHlNY2hBV0xWclUyZGtaQ29YcTYrdlpuOFBqeG8zeisvMDlQVDI3ZHUzU1cwK25sQTRPRGg0
OWVyU2twSVQ1eHRUVTFGUlVWTEFsTW9kaHJPbjMzbnN2UDRYMFRqeHhrQmsvL1BERHFsV3JL
aW9xWXQvcE9HR2NybEZoMmtqV1UxZFhOM3YyN0ZoMTBnNklVMEtVSUJsUkVzODdtUW1wd2tS
TlQwcEttamh4NHU5Kzl6dm0xYmx2Mzc2Q2dvTGs1T1NDZ2dLK25xNTZGazBTeUpWUU9VMC9j
ZUxFckZtejJDL3luWjJkTWdPUmlJaURVMXRibTV1Ym01S1NVbFJVNVBmN0thVjFkWFhzVDUr
cFU2ZlcxOWZ6SGNWNnNyT3pseTVkR2dxRnhKb3ZYcnhvZVhDeFIzTXVxYlljUDM1ODFxeFpL
U2twSG8rbm9hR0I3NmlzUnh4a3R2dW9VYU51di8zMnp6Ly8zUExJWW84NE1zcVBsR1dVMDRi
cVRDMVZQYk5telpKY1JrZ1V4Q2toU3BDbUtCa1AxOFdMRnpVbnBERm1YY3NJQUFEQWVoTGpu
aU1EOEFVREFBQ2NoTmQwQUFBQUhHZzZBQUE0QitzMFhXWlZCQ3NuQUFBUURkYjlSaHBEVFlm
MHl5QnpkUFE4S0pTMkhtNUF4b3RETENQanBaUFFpR1lqTWtaQVlobUgvZFlsaGlQT0JMMkJN
ajZ6WXVLOE5IeE5YN0pIL1lDbTJ4ampzZEwwb0ZEWmVyZ0JTUzhPVlJrWkw1MkVSalFia1RF
QzBpdmpzQm1sREVlY0NacURFUGJNaW9uemtsbWFmdWpRb1prelp5WW5KeFBGMWF3cW41YWpS
NC9lZlBQTnFhbXAwNlpONC81MmxOS3paOC9lZHR0dG16ZHZwam91TWFydlNiR2VXYk5tc2Yr
YTZMeTdHNGFMOFlra2VsQ0l0aDV1UU1hTFF5d2o0NldUMEJpWWpjZ1lBYW5LT0d4R0tjTXht
QWw4RUdUT3JKZzRMNW1sNlNVbEpldldyZU4zSWxBdG41Ynk4dkxYWDM4OUZBcnQyclZyMnJS
cHJFeEhSMGRaV1JrMzhCTHZQcVhDNUJEcjJicDFLek1GS3k4djM3bHpaOWk0SEl6eGlTUjZV
SWkySG01QXhvdERMQ1BqcFpQUTZKbU55QmdCaVdVY05xT1U0ZWpOQk9VZ3lKeFpNWEZlTWt2
VFUxSlMyTzJqeW4xVlBpMHBLU2s4NDJidUxvU1EwdExTN096czl2WjJWbEowaWFIQ29JajE5
UFgxWFhmZGRkdTJiU3NvS0pEM3FIUWtZZk4wbFFlRmdhMkhnNUh4NGhETERNdExKeEhSTkJ1
Uk1RTFNMT093NmFRTVIzTW1xQVpoV0dkV05NNUxabWw2Y1hIeHVuWHJlbnA2bFB1cVhsZFVW
RFEyTm5aM2R5dTNuemx6WnNlT0hibTV1ZXp2WE0wOGZlVElrVXBIVTdFZVN1bnp6eitmbnA2
dVo4YnJIb3huajRFSGhjUE9RR05rdkRqRU1wSmVPb21MYURZaVl3U2tWOFpoTTBvWmpqZ1RE
QWJLZUJ5aWQxNHlTOU0vL3ZqajB0SlM5dFVrUnNKZUh6dDI3UGJiYjA5TFMrTmZYTHhNVFUz
TnJGbXpnc0dnNkJKREtWMjJiQm5iaTcwVjY2R1UvdjN2ZjgvS3lyTCtYeXpaQjNJbGZLT3lq
SUV4anNQT1FHTmt2RGpFTXBwZU9rNUNOQnRSVFNwbUJLUWFLTEdNNWxSTVhNUnd4Sm1nT1ZC
OGQ4M1hmSzhvblplYzZmY3lNRER3bDcvOFpkbXlaZkh1Q0FBQVdJb3o3eU1saEpTVmxiSFZH
d0FBY0EvTzFIUUFBSEFuMEhRQUFIQU84SHNCQUFEbmtKQitMMEFlR2I4STBjbEV4di9Fa2No
TWFRd1hRMmFzUkFNVGNZdXJDT3Yzb3ZLTmlXQzRocTNwUTE3MUE1cHVaeVFOT2xST0pqTCtK
dzdHZUI1aXVKUVlqNVZvWUNKdWNROWgvVjVFMzVnSWhzc3NUVGZQNzRVN0J6UTNOenZTWk1N
a0RQd2lSQ2NUR2Y4VEJ4TldwekJjbkxCanBUSXdNYkEwY1RZeWZpK2liMHdFdzJXV3Bwdm45
N0oyN2RyNTgrZFRTdWZObTdkdTNUcVpJSUd4WDRUb1pDTGpmK0pnakhVS3c2WEVlS3hFQXhN
OVN4UEhJK1AzSXZyR1JEQmNabW02ZVg0djU4NmR5OGpJK1BMTEx6TXlNcjc3N2p1WklGMU9X
TDhJMGNsRXh2L0V3WVROUFRGY0hNbjFVcVdCaWQ0V1p5UGo5MkxnSUNRL1hHWnB1cWwrTDVX
VmxUZmNjQU56WGdUR3lQaEZpRTRtTXY0bkRzWllwekJjU3NKcXVzckFSSE9McXpBWU1VMEhv
ZUVPbDFtYWJxcmZTM056TXlHRU9hUURZMVJYS0drYWRJaE9KZ1krTU01Rzg0SXVESmNtTW1Q
RlBoSU5USlJiM0lhb2hCdzkzNWhoRFpjei9WNEFBTUNkNEQ1U0FBQndEdEIwQUFCd0R0QjBB
QUJ3RG1acE9oYlpBUURBZXN6NmpSU2FiaFBnOXpJc1pINzJ4M0F4WktaV1EwUERqQmt6Um80
Y1dWNWV6dTRWRDRWQ2p6enlDTHRGM3NFcUlVNGtwV0R5Zis2cWlkSVRKb0twTmZ4ckdUdlVE
Mmk2bllIZlN3UVl6MTRNRjBObWFsVldWblowZElSQ29lM2J0MCtjT0pGU1dsVlZWVlpXMXRI
UjRZWi8vcTQ1a1pZc1dmTGtrMC9xN2FMeWhJbGdhcG1yNlVybkZ0SGRaZTNhdFI2UGgzbkM0
RHZBYk9EM0lvL3hiTVJ3cVRDWVdveGdNRmhmWHo5OStuUks2ZVRKazk5OTkxMExleGRQeElu
MC9mZmZaMlptZG5WMWFaWVhQV0VpbUZvbWFyckt1VVYwZHhrelpvelg2KzNvNkZEZWJnck1B
SDR2dzhKWTB6RmNTb3luRnIyODVwQ1ZsWFh3NEVGS2FYSnk4b29WSzlMVDAzTnljclp0MjJa
aFQrT0FPSkZXcjE2OVlNRUN2ZktpSjB3RVU4dEVUVmM1dDRqdUxtKy8vZlk5OTl3emJkcTBz
V1BIUHZQTU16TGRCUkVBdjVmaEVqWlB4M0F4d2s0dFJpQVEyTHAxYTFGUkVhVTBNelBUNS9Q
MTlQUzB0TFFZTHlzN0FOVkU2dXZyeThuSlllWmNtb2llTUJGTUxSTTFYZVhjSXJxN01BWUdC
dmJ1M1p1ZW5pN1RYVEJjNFBjU0FjYWFqdUZpeUV5dFJZc1dkWFoyaGtLaCt2cDZaaFY3Nzcz
M2NrMTMvUGNmRVc3OW56MTc5ckIyakdCcW1mNGJLWGR1MFhSM0lZUXdjNE9OR3pmS2RCY01G
OVVWU3ZCN01VWTFYSHlqc2d5R2l5RXp0V3ByYTNOemMxTlNVb3FLaXZ4K1A2WDArUEhqczJi
TlNrbEo4WGc4RFEwTjhlbTYrV2hPcEZtelpxbVdtL1N5Qjc0OWdxa0Z2eGNBQUhBT3VJOFVB
QUNjQXpRZEFBQ2NBelFkQUFDY2c5V2FybHg4eDBJOEFBREVsbmorUmdwTmp6bWltVVpEUTBO
ZVhsNXljbkplWHQ3MjdkczE5MnBvYVBCNFBPeTM5ZVBIajJ2VzR4SmtQRXpFd1hHRDM0c1l0
VklCOUs0MEY2ZWZ6SVIwQU9JNUpUTkpZbUlsTkd4TnJ5QzFxZ2MwM1Q2SVpob1pHUm03ZHUw
S2hVSit2NS8vaDBNVldWbFpMUzB0UFQwOVBwL3Y1ei8vdVdZOUxrSEd3MFFjSERmNHZSaE1D
UU1ERTNINnlVeElCeUNlVXpLVEpDWldRaVpxT2lGaytmTGw2ZW5wWldWbGZJdTQ5bUxzQ2FO
WkQ5QkROTk1vTFMxdGJtN3U2ZW5adlh2M3pKa3pOZmZLeXNyYXMyY1BtMy9zeGhCWG1YSm9Z
dUJoSWc2T0cveGU5S2FFc1lHSk9QMWtKcVFERU04cG1Va1NFeXNoY3pYOWhSZGVDQVFDRHoz
MGtIS2o4blZZVHhpOWVvQW1vcGxHYTJ0clptWW1JU1F6TTFQdnB1UzZ1cnBycjcxMjlPalJq
ei8rT1BPVWNKVXBoNGl4aDRrNE9HN3dlOUdiRXNZR0p1TDBrNW1RRGtBOHAyUW1TVXlzaE16
VmRESE5VV2w2V0U4WXZYcUFKcUtaUm41K3Z0L3ZENFZDUHArdm9LREFlUGU5ZS9kT21USkZz
eDczRU5iRFJCd2NOL2k5YUU2SnNBWW00dlFiMW9SMEFQeWNrcGtrTWJFU01sZlRqVGNTT1U4
WUxMdkxJNXBwakJzM3p1LzM5L1QwN05xMXkyRDVjbkJ3OE9qUm95VWxKVlZWVlpyMXVBUVpE
eE54Y056Zzk2STVKY0lhbUlqVFQzSkNPZ0RWT1NVelNXSmlKV1NkcG91WHl2QUNCcDR3WWoz
QUFORk1vNjZ1enVQeE1GT2QrdnA2Vmt6ejBHUm5aeTlkdWpRVUNtblc0eEpVczFUVHcwUWNI
RGY0dldoT2liQUdKdUwwMDV5UXprTThwelFuaVdxNFltSWxCTDhYQUFCd0RyaVBGQUFBbkFN
MEhRQUFuQU0wSFFBQW5JTjFtajZzeTJQNFI4YnI5VmpLQndBQUpkYjlSaHF4L2tMVG8wSEd1
UVYrTHh5WldhMW53ZUgxZWgwOFZ1S3dORFEwekpneFkrVElrZVhsNWZ5dWJ4WGlXRG5TNzBX
MENSSW5rdVNacUJxY0NLNURHYmFtMTVKYTFRT2FibWRrbkZ2Zzk4S1JtVkdhRmh5ZmZQSUpP
MTNON1YrOFVRWllXVm5aMGRFUkNvVzJiOTgrY2VKRXpmTGlXRG5TNzBXMENSSm5nc3c1cFRj
NHR0RDB0V3ZYZWp5ZTVPUmsvaVZEQ0huNTVaZkhqeCtmbVptNWFkTW1YcUZ5ZHoyL0YyWE5y
YTJ0QlFVRmFXbHBWVlZWN0NPeExjQ1JjVzZCM3d1SEVKS1JrWkdlbnY3VG4vNzB4SWtUbW1W
RUM0NVFLRlJVVlBUYWE2ODVmdnFKQVFhRHdmcjYrdW5UcDJ1V0Y4ZksyWDR2M0NaSW5FZ3k1
NVRlNE5oQzA4ZU1HZVAxZWpzNk9ucDZldmkrNjlldkR3YURUVTFOeWxzVGxidnIrYjBvYTU0
eFkwWk5UVTB3R0h6bGxWZllSMkpiZ0NQajNBSy9GeFZuejU2dHFxcTY2YWFiTkQ4VkxUZ2Vl
K3d4ZG8rZjJ6U2RaVkZaV1ZrSER4N1VMQytPbFlQOVhrU2JJT1ZFa2ptbjlBYkhGcHIrOXR0
djMzUFBQZE9tVFJzN2R1d3p6enpEOXUzcjZ4TzdxSHl0NS9laXJEa2xKU1VZREZKS0E0RUEr
MGhzQzNDRzVkd0N2eGRPZDNkM2FtcXE1a2VpQmNlSUVTT0crL05TZ2lKR0Z3Z0V0bTdkV2xS
VXBGbGVIQ3VuK3IzbzJRVHhpU1J6VHVrTmppMDBuVEV3TUxCMzc5NzA5SFNxcitQSzE1cCtM
NU1tVFZKbUFVVkZSU3hQcjY2dVZ1NnJiQXR3SkoxYjRQZWk1SWNmZmxpMWFsVkZSWVhtcHdZ
V0hNNFdkSHBsZ0lzV0xlcnM3QXlGUXZYMTlXekpUa1FjSzBmNnZlalpCQ2tua3N3NXBUYzR0
dEIwbHJBd1Y0ZU5HemRTTFIwblYwSXAxZlI3K2V0Zi81cWVuczdmN3QrL1B6OC9QeTB0YmZu
eTVjcDZsRzBCanFaTmgrWmYwUEI3b1plSFl0U29VYmZmZnZ2bm4zL09OeXJMR0Zod09GalR4
Yk8xdHJZMk56YzNKU1dscUtqSTcvZnpZc3E5eExGeXBOK0xhbkF1WHJ3b1RpU1pNMUVjSEhI
WXd3Sy9Gd0FBY0E2NGp4UUFBSndETkIwQUFKd0ROQjBBQUp5RDNUVWRpL1VBQUNDUDNYOGpo
YVpIaWVoRUlTS2FjdWhabWpnZW1TbU40V0xJakpWb0plUkl2eGQ1akUyQnhNRVJCekFzdzli
MGppSDFBNXB1WjBRbkNzMHlLbE1PVFVzVDkyQTg2ekJjU296SFNyUVNjcVRmaXlSaFRZSEV3
UkVITUN4bWFicW0zMHRWVlZWYVd0cjA2ZE5iVzFzcHBSOSsrR0ZoWVdGS1NrcGhZU0c3WFAv
UW9VTXpaODVrZS9FV0thVm56NTY5N2JiYk5tL2VMQk1TMElRN1VZZ2ZpYVljNGhaWEVWYW5N
Rnljc0dPbHNoSnl0dCtMQVRLbVFPTGdpQU1ZRnJNMFhkUHZwYnE2T2hnTTF0VFVGQmNYVTBv
TENncGVmZlZWZGtkb1lXRWhwYlNrcEdUZHVuWHN0cGNmVyt6b0tDc3JhMmxwa1lrSGFDSTZV
U2dSVFRuRUxhN0NXS2N3WEVxTXgwcTBFbkt3MzRzeE1xWkE0dUNJQXhnV3N6UmQwKytGK2JR
RWcwRm1nSkNjbk15ZFcxSlNVaWlsS1NrcGdVQkExV0pwYVdsMmRuWjdlN3RNUEVCRXo0bUNJ
NXB5aUZ0Y1JkamNFOFBGa1Z3ZDVWWkNUdlY3Q1l1TUtaREI0UEFCREl1NTYra3F2eGVXbGRm
VTFNeVlNWU5xNWVuRnhjWHIxcTFUMmlzU1FzNmNPYk5qeDQ3YzNGejI1eTBZRm5wT0ZFcEVV
dzREU3hNM1lLeFRHQzRsWVRWZFpTWGtTTCtYWVdFd1lwcURveHJBc0ppbDZleTdTT1gzd3Ri
VDgvUHo5Ky9mVHluZHQyOWZRVUZCY25KeVFVRUJFNTJQUC82NHRMU1VmYUdwNHErcHFaazFh
eGJMNjRFOHFpdVVMbDY4U0NWTU9Rd3NUWnlONWdWZEdDNU5aTWFLZmFTMEVuS2szOHV3VUE2
UmFyajAvRjZVQXhpV0JQamZkUUFBQUNTSi8vK1lCZ0FBRUN2c2ZoOHBBQUFBZWFEcEFBRGdI
T3lvNlZpbEFRQ0F5RER4TjFKSXN4MW9hR2lZTVdQR3lKRWp5OHZMMzN2dlBjMHlNRERod0I1
SEhwbXgwck1yTWJZOWNUQmgvVjVVd3lVenlDcUdyZWxEd2dPYWJtY3FLeXM3T2pwQ29kRDI3
ZHNuVHB5b1dRWUdKaHpZNDhnak0xYWFkaVZoYlUrY1N0akF4ZUdTR1dRVlptbTZaaFpQQ0Zt
K2ZIbDZlbnBaV1JuVjhudmhPOHAwSGNnVERBYnI2K3VuVDUrdStTa01URVJnanlPUDhWaXA3
RXBrYkU4Y2lVemdCdTR1Qm9Pc3d0SThuUkR5d2dzdkJBS0JoeDU2aUdyZFI2cTNJNGdHOWpX
WmxaVjE4T0JCelFJd01GRUJleHg1ak1kS3RDdVJzVDF4SkRLQjY3bTdHQSt5Q3FzMVhmazlJ
L3E5Nk8wSW9pUVFDR3pkdXJXb3FFanpVeGlZS0lFOWpqeGh4NHJEN1Vwa2JFOGN5YkFDVjdx
N3lBOHl3MFJOSHpseTVJa1RKMVM3Szk4aVQ3ZUFSWXNXZFhaMmhrS2grdnA2UGE5T0dKaHdZ
SThqajh4WVVYMjdFdGVlNXNhQnE0WkxjcENWbUtqcHk1WXRTMHRMVTYybkt3dUlmaThSV0E0
QVkycHJhM056YzFOU1VvcUtpdngrUDl1b0dsc1ltSEJVTXhEMk9BYklqQlg3U05PdXhMVW51
SUVraXNPbE9jakcyUDEvMXdFQUFKREhqdmNjQVFBQWlBeG9PZ0FBT0Fkb09nQUFPQWU3YXpv
VzZ3RUFRQjY3KzcxQTA2TkU1bmRzR0pod01Genl5SXhWUTBORFhsNWVjbkp5WGw3ZTl1M2JK
ZmR5QUdLWWtzT2w4bnVKWUxpR3JlbGVBV2k2L1RFZVJoaVlxTUJ3eVdNOFZoa1pHYnQyN1Fx
RlFuNi9YL25mUjExeVhvdGhHZ2V1YVk4VGRpOFZabW02bU1VVDRhck1zckt5bHBZV1NtbHpj
L1BNbVRPcGxnTU1LM24yN05uYmJydHQ4K2JOOG9FQkpXRm5FZ3hNbEdDNDVERWVxOUxTMHVi
bTVwNmVudDI3ZDdOelhHWXZ4eENCcG12NnZkaEMwOFYraUpxK2R1M2ErZlBuVTBybnpadTNi
dDA2cW5WbktTR2tvNk9EcXorSURPTTVBUU1URlJndWVZekhxclcxTlRNemt4Q1NtWm5aMXRZ
bXVaZGpHSzZtNi9tOTJGM1QrL3I2Mk90ejU4NWxaR1I4K2VXWEdSa1ozMzMzSGRWeWdDR0Vs
SmFXWm1kbnQ3ZTN5MGNGVklUTkRtQmdvZ1RESlkveFdPWG41L3Y5L2xBbzVQUDVDZ29LSlBk
eURNUFZkSTdTNzBWK0w0YUptcTd5ZTVrd1ljTHUzYnU3dTdzM2JOakFkNm1zckx6aGhodm16
WnZIM21ybTZXZk9uTm14WTBkdWJpNzcvTXdGcGdBQUNIWkpSRUZVOHhaRWdQR2NnSUdKQ2d5
WFBNWmpOVzdjT0wvZjM5UFRzMnZYTHF5bmEyNVJvV21QWXhkTlYvbTlWRmRYWjJSa2pCOC9m
dDI2ZFh4amMzTXpJYVM1dVptOTFYU0FZUi9WMU5UTW1qV0xaZkZBSG5JbGZLT3lEQXhNT0Jn
dWVXVEdxcTZ1enVQeGpCZ3hZdXJVcWZYMTlYcDdPUTh4VEpuaFloOForTDNJTkEyL0Z3QUFj
QTUyditjSUFBQ0FQTkIwQUFCd0R0QjBBQUJ3RHRacE9wYmRBUURBYkt6N2pSU2FiZ0Y2UjhU
ZzhpVHFZbE1PRWVXc3pzckswaXlqNSs1aVBNaUp6cFl0VzY2NzdyclUxTlNaTTJmdTNidVhV
dHJRMERCanhveVJJMGVXbDVlLzk5NTdtbnVKRTBtc3h3R0laNURvM0NJVGVHU0RyR0w0bXI1
QmVFRFRiWVpxcUQvNTVKUHM3R3lEOFhlNUtZY21TNVlzZWZMSkp6VS8wblIzQ1R2SWljN2N1
WE1QSHo3YzNkMjlaY3NXZGw5VlpXVmxSMGRIS0JUYXZuMzd4SWtURGZaVkRvdFlqd01RenlE
UnVVVW04R2dHbVdPV3BpczM4c3N6WDM3NTVmSGp4MmRtWm03YXRFbXpESHV4ZlBueTlQVDBz
ckl5ZXZsN1BpVWxwYlMwRlBZQWtpZ0hOaFFLRlJVVnZmYmFhd1p5NDNKVERwSHZ2LzgrTXpP
enE2dEw4MVBSM1VWbWtCM0R5Wk1uVTFOVGUzdDcyZHRnTUZoZlh6OTkrblNEWFRTSFJWVlBR
aU9lUVhyT0xWUXU4QWdHbVdPcHBxOWZ2ejRZRERZMU5iRXpRVS9UWDNqaGhVQWc4TkJERC9G
UCsvdjc5KzNiTjJuU0pKbVFnSEpnSDN2c01YWm5vNEhjdU55VVEyVDE2dFVMRml6USsxUjBk
NUVaWkdmdzdiZmZWbFJVUFByb28rd3RYNlE2ZVBDZ3dWN2lzS2pxU1hURU0walB1VVVtOE1n
R21XTzZwbk4zRjBKSVgxK2Y4bE94RE51by9BWmJ2MzQ5dXcrTkVKS1VsQ1FURWxBZUVUWjB4
dXZqTGpmbFVOSFgxNWVUazZQOGJsTWh1cnZJRExJRE9IandZRzV1N29vVkt3WUdCdmpHUUND
d2RldldvcUlpZ3gxVlk2SlpUMEtqZHdiUks1MWJaQUtQZUpBNVptbTY2TzRpWnVXYURqQ3Ey
dExTMHBxYW1vTEJvTS9uYy9EWkVsdkMvdVdrd3VXbUhDcnE2dXBtejU1dFVNREEzY1hCSTFa
VFUxTlJVY0VjT3hpTEZpM3E3T3dNaFVMMTlmV3E1UVVWeW1FUjYzRUFtbWVReXJsRkp2Qm9C
cGxqbHFhTDdpNmlwbXM2d0tocWUvYlpaek15TWpJeU1sYXZYdTNnRXlaV2tDdFJmYVQ1bXJy
WWxFT1RXYk5tYmR1MlRibEZOUUlHN2k0T0hpdlZsTGg0OFdKdGJXMXVibTVLU2twUlVaSGY3
K2ZGRFBiU3JDY093Y1FhdlRQSXdMbUZCVzQ4WEhxRGJBejhYZ0FBd0RuZ1BsSUFBSEFPMEhR
QUFIQU8wSFFBQUhBTzBIUUFiSTNkZnErS3BqOTJpOFdSUU5NQjBDQmk5WW01YkJsVUdIMWIv
SjVZU3VtcFU2ZjBMRzVrR3BXNWJrS213NXFlSnlydkZJUFcrUllacHhUUnVrZlB6TWU0TFpt
clJjUzR4TGJFZWlLd3g0R21BNkNCU3pUOTVwdHZmdSs5OXlaUG5qeGx5cFIzMzMzWCtNSjg0
MFpsT2lOVFJ2UThFYjFUWk9xWGNVb1JyWHMwelh3a1l6R09Ub3hMcnkxbFBSSFk0MERUQWRC
QTg0d2xWMW9QclYyNzF1UHhKQ2NuODl4SzVnSmZWWDdIbnF1cXF0TFMwcVpQbjk3YTJrb3Bi
VzF0TFNnb1NFdExxNnFxVXRhc2JGMXM2K2pSb3pmZmZITnFhdXEwYWRONFptb3NOSXNXTFZx
OWV2WFVxVk05SHMrYU5Xc1dMMTZzV1kvWUg1a1JFK3NoaEN4ZnZuejA2TkU4VWdPNDU0bUJk
MHJZUHFpY1VsUUZST3NlY1l0bXRab2JKYjlpbFhHSmJlblZJMitQQTAwSFFBTzk4MU5wUFRS
bXpCaXYxOXZSMGRIVDB4TjJSODBDWEsrcnE2dUR3V0JOVFUxeGNUR2xkTWFNR1RVMU5jRmc4
SlZYWGxHV1Z4a2ZxZG9xTHk5Ly9mWFhRNkhRcmwyN3BrMmJKaFBtNnRXcmI3enh4bm56NWxW
V1Z0NTQ0NDFyMXF6UnJFZXZQNnE0VkY4ellqM0tTSTN2ZEZkNm51aDVwMmoyUWV5U2dWT0th
TjBqYnBGc1MzT0xjVng2YlluMURNc2VCNW9PZ0FiaWVTVmFENzM5OXR2MzNIUFB0R25UeG80
ZCs4d3p6K2p0cUZlejBnb3BHQXhTU29QQllHcHFLcVUwSlNXRmJRa0VBcXlNcHZHUnFxMlVs
QlF1cVpMbVNEdDI3RWhLU25ycHBaZisvT2MvSnlVbDdkeTVVN01lc1Q4eUl5YldJMGFxaVo0
dml0STdSYklQeGs0cG9uV1B1RVcrcmJDSFhoV1hYbHVxZW9acmp3Tk5CMEFEOGZ6VXN4NGFH
QmpZdTNkdmVubzZlenR5NU1nVEowNFkxS3hwaGZUcXE2K3k3SFhHakJtVTBxS2lJcFlYVjFk
WHN6S2FyYXZhcXFpb2FHeHM3Tzd1bGcvejJMRmpoSkFEQnc1ODlORkhoQkFtQW1JOVluOUV4
TzFpUGNwSTJWOGtJcHErS0NydkZEMlVmWkJ4U2hHdGV3ek1mTUxHYTZ6cFlseDZiU25yaWNB
ZUI1b09nQWJpU29Kb1BjUStZaTRmR3pkdVpEc3VXN1lzTFMzTjRQVFd0RUppNituNStmbjc5
KytubE83ZnZ6OC9Qejh0TFczNTh1VjZyWXR0SFR0MjdQYmJiMmRiK0Vaam9lbnQ3UjB6Wmt4
UFQwOG9GQm96Wmd4elRoWHJFZnVqT1dLcUxXSTl5a2oxMXROVkkzL3g0a1gyUXVtZEVuWXZT
cW1NSFkxbzNhTnA1cVBhUzJ4TDNDSVRsOWhXMkpwbDdIR2c2UURFR1dQWkJXQllRTk1CaURQ
UWRCQkRvT2tBQU9BY29Pa0FBT0Fjb09rQUFPQWNvT2tBQU9BY29Pa2dNV2hzYkd4cWF1cnY3
MjlxYW1wc2JKVGN4ZmhUdlFLQlFNRG44Mm1XTjlnTEFEc0FUUWVKUVdOajQvdnZ2Ly9aWjU5
OThNRUhzVkpWdlhvT0hUb2tmZ1FwQndrQk5CMGtCbzJOamNlT0hmUDcvY2VPSGVQeXFuclIy
TmpZM3Q3dTkvdVBIajJxdDFGVnA5alFEei84ME56Y3JLbnBmcjkvejU0OXAwNmRpbWxrQU1R
U2FEcElEQm9iRzgrZE84ZWYrVWJsaThiR3h1KysreTRRQ0xEN0JqVTNxdW9VRy9yNDQ0K1BI
eit1K2RIZzRPQ3BVNmQyNzk0ZHU3QUFpREhRZEpBWU5EWTJEZzRPdnZQT080T0RnMXh3L1g1
L0lCRGdLaTlLdkxoUlZhZG1RM3JyNW9PRGcyZk9uSUdtQXpzRFRRZUpnVkpoK2V1alI0LzYv
ZjcyOXZZSU5GMGwzT0tuNG92R3hzWTllL1o4ODgwM3NRd01nSmdDVFFjQUFPY0FUUWNBQU9j
QVRRY0FBT2NBVFFjQUFPY0FUUWNBQU9jQVRRY0FBT2Z3bzZhM3RyYStBUUFBSVBFaEVIUUFB
SEFNL3gvT2JoNTFrd0JER2dBQUFBQkpSVTVFcmtKZ2dnPT0iIGFsdD0iIiAvPjwvcD48Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCAjMzI1RkJBOyBwYWRkaW5n
LWxlZnQ6IDVweDttYXJnaW4tbGVmdDo1cHg7Ij4tLS0tLVVyc3ByJnV1bWw7bmdsaWNoZSBO
YWNocmljaHQtLS0tLTxiciAvPjxzdHJvbmc+QW46PC9zdHJvbmc+CUtvbnJhZCBSemVzenV0
ZWsgV2lsayAmbHQ7a29ucmFkLndpbGtAb3JhY2xlLmNvbSZndDs7IDxiciAvPjxzdHJvbmc+
Q0M6PC9zdHJvbmc+CVNhbmRlciBFaWtlbGVuYm9vbSAmbHQ7bGludXhAZWlrZWxlbmJvb20u
aXQmZ3Q7OyB4ZW4tZGV2ZWwgJmx0O3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tJmd0
OzsgSmFuIEJldWxpY2ggJmx0O2piZXVsaWNoQHN1c2UuY29tJmd0OzsgS29ucmFkIFJ6ZXN6
dXRlayBXaWxrICZsdDtrb25yYWRAZGFybm9rLm9yZyZndDs7IDxiciAvPjxzdHJvbmc+Vm9u
Ojwvc3Ryb25nPglDYXJzdGVuIFNjaGllcnMgJmx0O2NhcnN0ZW5Ac2NoaWVycy5kZSZndDs8
YnIgLz48c3Ryb25nPkdlc2VuZGV0Ojwvc3Ryb25nPglEaSAyOC4wMi4yMDEyIDE1OjM5PGJy
IC8+PHN0cm9uZz5CZXRyZWZmOjwvc3Ryb25nPglSZTogW1hlbi1kZXZlbF0gTG9hZCBpbmNy
ZWFzZSBhZnRlciBtZW1vcnkgdXBncmFkZSAocGFydDIpPGJyIC8+PHN0cm9uZz5BbmxhZ2U6
PC9zdHJvbmc+CWlubGluZS50eHQ8YnIgLz48c3R5bGUgdHlwZT0idGV4dC9jc3MiPi5ib2R5
Y2xhc3MgeyBmb250LWZhbWlseTogbW9ub3NwYWNlOyB9PC9zdHlsZT4gICAgICAgICAgICAg
ICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPiAgICAgICAuYm9keWNsYXNzICAgICAgIHsgICAg
ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh
bnQ7ICAgICAgICAgZm9udC1zaXplOiAxMnB4OyAgICAgICAgIHBhZGRpbmc6IDVweCA1cHgg
NXB4IDVweDsgICAgICAgICBtYXJnaW46IDBweDsgICAgICAgICBib3JkZXItc3R5bGU6IG5v
bmU7ICAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogI2ZmZmZmZjsgICAgICAgfSAgICAgICAg
cCwgdWwsIGxpICAgICAgIHsgICAgICAgICBtYXJnaW4tdG9wOiAwcHg7ICAgICAgICAgbWFy
Z2luLWJvdHRvbTogMHB4OyAgICAgICB9ICAgPC9zdHlsZT4gIDxkaXY+PHA+V2VsbCBsZXQg
bWUgY2hlY2sgZm9yIGEgbG9uZ2VyIHBlcmlvZCBvZiB0aW1lLCBhbmQgZXNwZWNpYWxseSwg
d2hldGhlciB0aGUgRG9tVSBpcyBzdGlsbDwvcD48cD53b3JraW5nIChjYW4gZG8gdGhhdCBv
bmx5IGZyb20gYXQgaG9tZSksIGJ1dCBsb2FkIGxvb2tzIHByZXR0eSB3ZWxsIGFmdGVyIGFw
cGx5aW5nIHRoZTwvcD48cD5wYXRjaCB0byAzLjIuOCA6LUQuPC9wPjxwPiZuYnNwOzwvcD48
cD5CUiw8L3A+PHA+Q2Fyc3Rlbi48YnIgLz4mbmJzcDs8L3A+PGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlci1sZWZ0OiAycHggc29saWQgIzMyNUZCQTsgcGFkZGluZy1sZWZ0OiA1cHg7bWFy
Z2luLWxlZnQ6NXB4OyI+LS0tLS1VcnNwciZ1dW1sO25nbGljaGUgTmFjaHJpY2h0LS0tLS08
YnIgLz48c3Ryb25nPkFuOjwvc3Ryb25nPglKYW4gQmV1bGljaCAmbHQ7SkJldWxpY2hAc3Vz
ZS5jb20mZ3Q7OyA8YnIgLz48c3Ryb25nPkNDOjwvc3Ryb25nPglLb25yYWQgUnplc3p1dGVr
IFdpbGsgJmx0O2tvbnJhZEBkYXJub2sub3JnJmd0OzsgeGVuLWRldmVsICZsdDt4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbSZndDs7IENhcnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3Rl
bkBzY2hpZXJzLmRlJmd0OzsgU2FuZGVyIEVpa2VsZW5ib29tICZsdDtsaW51eEBlaWtlbGVu
Ym9vbS5pdCZndDs7IDxiciAvPjxzdHJvbmc+Vm9uOjwvc3Ryb25nPglLb25yYWQgUnplc3p1
dGVrIFdpbGsgJmx0O2tvbnJhZC53aWxrQG9yYWNsZS5jb20mZ3Q7PGJyIC8+PHN0cm9uZz5H
ZXNlbmRldDo8L3N0cm9uZz4JRnIgMTcuMDIuMjAxMiAxNjoxODxiciAvPjxzdHJvbmc+QmV0
cmVmZjo8L3N0cm9uZz4JUmU6IFtYZW4tZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVt
b3J5IHVwZ3JhZGUgKHBhcnQyKTxiciAvPk9uIFRodSwgRmViIDE2LCAyMDEyIGF0IDA4OjU2
OjUzQU0gKzAwMDAsIEphbiBCZXVsaWNoIHdyb3RlOjxiciAvPiZndDsgJmd0OyZndDsmZ3Q7
IE9uIDE1LjAyLjEyIGF0IDIwOjI4LCBLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJh
ZC53aWxrQG9yYWNsZS5jb20mZ3Q7IHdyb3RlOjxiciAvPiZndDsgJmd0O0BAIC0xNTUwLDcg
KzE1NTIsMTEgQEAgc3RhdGljIHZvaWQgKl9fdm1hbGxvY19hcmVhX25vZGUoc3RydWN0IHZt
X3N0cnVjdCAqYXJlYSwgZ2ZwX3QgZ2ZwX21hc2ssPGJyIC8+Jmd0OyAmZ3Q7IAlzdHJ1Y3Qg
cGFnZSAqKnBhZ2VzOzxiciAvPiZndDsgJmd0OyAJdW5zaWduZWQgaW50IG5yX3BhZ2VzLCBh
cnJheV9zaXplLCBpOzxiciAvPiZndDsgJmd0OyAJZ2ZwX3QgbmVzdGVkX2dmcCA9IChnZnBf
bWFzayAmYW1wOyBHRlBfUkVDTEFJTV9NQVNLKSB8IF9fR0ZQX1pFUk87PGJyIC8+Jmd0OyAm
Z3Q7LTxiciAvPiZndDsgJmd0OysJZ2ZwX3QgZG1hX21hc2sgPSBnZnBfbWFzayAmYW1wOyAo
X19HRlBfRE1BIHwgX19HRlBfRE1BMzIpOzxiciAvPiZndDsgJmd0OysJaWYgKHhlbl9wdl9k
b21haW4oKSkgezxiciAvPiZndDsgJmd0OysJCWlmIChkbWFfbWFzayA9PSAoX19HRlBfRE1B
IHwgX19HRlBfRE1BMzIpKTxiciAvPiZndDsgPGJyIC8+Jmd0OyBJIGRpZG4mIzM5O3Qgc3Bv
dCB3aGVyZSB5b3UgZm9yY2UgdGhpcyBub3JtYWxseSBpbnZhbGlkIGNvbWJpbmF0aW9uLCB3
aXRob3V0PGJyIC8+Jmd0OyB3aGljaCB0aGUgY2hhbmdlIHdvbiYjMzk7dCBhZmZlY3Qgdm1h
bGxvYzMyKCkgaW4gYSAzMi1iaXQga2VybmVsLjxiciAvPiZndDsgPGJyIC8+Jmd0OyAmZ3Q7
KwkJCWdmcF9tYXNrICZhbXA7PSAoX19HRlBfRE1BIHwgX19HRlBfRE1BMzIpOzxiciAvPiZn
dDsgPGJyIC8+Jmd0OyAJCQlnZnBfbWFzayAmYW1wOz0gfihfX0dGUF9ETUEgfCBfX0dGUF9E
TUEzMik7PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7IEphbjxiciAvPjxiciAvPkR1aCE8YnIgLz5H
b29kIGV5ZXMuIFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhhdC48YnIgLz48YnIgLz4mZ3Q7IDxi
ciAvPiZndDsgJmd0OysJfTxiciAvPiZndDsgJmd0OyAJbnJfcGFnZXMgPSAoYXJlYS0mZ3Q7
c2l6ZSAtIFBBR0VfU0laRSkgJmd0OyZndDsgUEFHRV9TSElGVDs8YnIgLz4mZ3Q7ICZndDsg
CWFycmF5X3NpemUgPSAobnJfcGFnZXMgKiBzaXplb2Yoc3RydWN0IHBhZ2UgKikpOzxiciAv
PiZndDsgJmd0OyA8YnIgLz4mZ3Q7IDxiciAvPjxiciAvPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIC8+WGVuLWRldmVsIG1haWxpbmcgbGlz
dDxiciAvPlhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPGJyIC8+aHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsPGJyIC8+PC9ibG9ja3F1b3RlPjwvZGl2PiAgIDwv
YmxvY2txdW90ZT48L2Rpdj4gICA8L2Jsb2NrcXVvdGU+PHA+Jm5ic3A7PC9wPgo8L2JvZHk+
CjwvaHRtbD4=
--=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg--

--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw
Content-Type: application/octet-stream; name=debug.log
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=debug.log

VXNpbmcgY29uZmlnIGZpbGUgIi9ldGMveGVuL3Jpa2VyLjMyIi4KU3RhcnRlZCBkb21haW4g
cmlrZXIgKGlkPTE1KQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5
cyBjcHVzZXQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw
dQ0KWyAgICAwLjAwMDAwMF0gTGludXggdmVyc2lvbiAzLjIuOC1hbWQ2NCAocm9vdEBjaGVr
b3RleSkgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgVHVl
IEZlYiAyOCAxMTozMjoyNyBDRVQgMjAxMg0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5l
OiByb290PS9kZXYveHZkYTEgcm8gaW9tbXU9c29mdCBzd2lvdGxiPTQwOTYgeGVuY29ucz10
dHkNClsgICAgMC4wMDAwMDBdIEFDUEkgaW4gdW5wcml2aWxlZ2VkIGRvbWFpbiBkaXNhYmxl
ZA0KWyAgICAwLjAwMDAwMF0gUmVsZWFzZWQgMCBwYWdlcyBvZiB1bnVzZWQgbWVtb3J5DQpb
ICAgIDAuMDAwMDAwXSBTZXQgMCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5nDQpbICAgIDAuMDAw
MDAwXSBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSAg
WGVuOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAodXNhYmxlKQ0KWyAg
ICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDBhMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAg
KHJlc2VydmVkKQ0KWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDEwMDAwMCAtIDAw
MDAwMDAwMTQ4MDAwMDAgKHVzYWJsZSkNClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERp
c2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAwLjAwMDAwMF0gRE1JIG5vdCBwcmVz
ZW50IG9yIGludmFsaWQuDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kDQpb
ICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MTQ4MDAgbWF4X2FyY2hfcGZuID0gMHg0MDAw
MDAwMDANClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAw
MDAwMDAtMDAwMDAwMDAxNDgwMDAwMA0KWyAgICAwLjAwMDAwMF0gUkFNRElTSzogMDE5Mjgw
MDAgLSAwMzUwYTAwMA0KWyAgICAwLjAwMDAwMF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZv
dW5kDQpbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAt
MDAwMDAwMDAxNDgwMDAwMA0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAg
MDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDE0ODAwMDAwDQpbICAgIDAuMDAwMDAwXSAgIE5P
REVfREFUQSBbMDAwMDAwMDAxM2ZmYjAwMCAtIDAwMDAwMDAwMTNmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSBab25lIFBGTiByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERNQSAgICAgIDB4
MDAwMDAwMTAgLT4gMHgwMDAwMTAwMA0KWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAweDAw
MDAxMDAwIC0+IDB4MDAxMDAwMDANClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkN
ClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQ0K
WyAgICAwLjAwMDAwMF0gZWFybHlfbm9kZV9tYXBbMl0gYWN0aXZlIFBGTiByYW5nZXMNClsg
ICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwYTANClsgICAgMC4w
MDAwMDBdICAgICAwOiAweDAwMDAwMTAwIC0+IDB4MDAwMTQ4MDANClsgICAgMC4wMDAwMDBd
IFNGSTogU2ltcGxlIEZpcm13YXJlIEludGVyZmFjZSB2MC44MSBodHRwOi8vc2ltcGxlZmly
bXdhcmUub3JnDQpbICAgIDAuMDAwMDAwXSBTTVA6IEFsbG93aW5nIDEgQ1BVcywgMCBob3Rw
bHVnIENQVXMNClsgICAgMC4wMDAwMDBdIE5vIGxvY2FsIEFQSUMgcHJlc2VudA0KWyAgICAw
LjAwMDAwMF0gQVBJQzogZGlzYWJsZSBhcGljIGZhY2lsaXR5DQpbICAgIDAuMDAwMDAwXSBB
UElDOiBzd2l0Y2hlZCB0byBhcGljIE5PT1ANClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl
cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw
DQpbICAgIDAuMDAwMDAwXSBBbGxvY2F0aW5nIFBDSSByZXNvdXJjZXMgc3RhcnRpbmcgYXQg
MTQ4MDAwMDAgKGdhcDogMTQ4MDAwMDA6ZWI4MDAwMDApDQpbICAgIDAuMDAwMDAwXSBCb290
aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuDQpbICAgIDAuMDAwMDAwXSBYZW4g
dmVyc2lvbjogNC4xLjIgKHByZXNlcnZlLUFEKQ0KWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVy
Y3B1OiBOUl9DUFVTOjUxMiBucl9jcHVtYXNrX2JpdHM6NTEyIG5yX2NwdV9pZHM6MSBucl9u
b2RlX2lkczoxDQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI3IHBhZ2VzL2Nw
dSBAZmZmZjg4MDAxM2ZhODAwMCBzODE2MDAgcjgxOTIgZDIwODAwIHUxMTA1OTINClsgICAg
MC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdy
b3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDgyNTM5DQpbICAgIDAuMDAwMDAwXSBQb2xpY3kg
em9uZTogRE1BMzINClsgICAgMC4wMDAwMDBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9
L2Rldi94dmRhMSBybyBpb21tdT1zb2Z0IHN3aW90bGI9NDA5NiB4ZW5jb25zPXR0eQ0KWyAg
ICAwLjAwMDAwMF0gUElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2
Mzg0IGJ5dGVzKQ0KWyAgICAwLjAwMDAwMF0gUGxhY2luZyA4TUIgc29mdHdhcmUgSU8gVExC
IGJldHdlZW4gZmZmZjg4MDAxMjgwMDAwMCAtIGZmZmY4ODAwMTMwMDAwMDANClsgICAgMC4w
MDAwMDBdIHNvZnR3YXJlIElPIFRMQiBhdCBwaHlzIDB4MTI4MDAwMDAgLSAweDEzMDAwMDAw
DQpbICAgIDAuMDAwMDAwXSBNZW1vcnk6IDI3NDM0OGsvMzM1ODcyayBhdmFpbGFibGUgKDMz
ODJrIGtlcm5lbCBjb2RlLCA0NDhrIGFic2VudCwgNjEwNzZrIHJlc2VydmVkLCAzMjkxayBk
YXRhLCA1NjhrIGluaXQpDQpbICAgIDAuMDAwMDAwXSBTTFVCOiBHZW5zbGFicz0xNSwgSFdh
bGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9MSwgTm9kZXM9MQ0KWyAg
ICAwLjAwMDAwMF0gSGllcmFyY2hpY2FsIFJDVSBpbXBsZW1lbnRhdGlvbi4NClsgICAgMC4w
MDAwMDBdIE5SX0lSUVM6MzMwMjQgbnJfaXJxczoyNTYgMTYNClsgICAgMC4wMDAwMDBdIENv
bnNvbGU6IGNvbG91ciBkdW1teSBkZXZpY2UgODB4MjUNClsgICAgMC4wMDAwMDBdIGNvbnNv
bGUgW3R0eTBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBdIGNvbnNvbGUgW2h2YzBdIGVuYWJs
ZWQNClsgICAgMC4wMDAwMDBdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KWyAg
ICAwLjAwMDAwMF0gRGV0ZWN0ZWQgMjIxMC4wMzggTUh6IHByb2Nlc3Nvci4NClsgICAgMC4w
MDQwMDBdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxh
dGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDQ0MjAuMDcgQm9nb01JUFMgKGxwaj04ODQw
MTUyKQ0KWyAgICAwLjAwNDAwMF0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTog
MzAxDQpbICAgIDAuMDA0MDAwXSBTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQNClsg
ICAgMC4wMDQwMDBdIFNFTGludXg6ICBEaXNhYmxlZCBhdCBib290Lg0KWyAgICAwLjAwNDAw
MF0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1
MjQyODggYnl0ZXMpDQpbICAgIDAuMDA0MDAwXSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVu
dHJpZXM6IDMyNzY4IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KWyAgICAwLjAwNDAwMF0g
TW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYNClsgICAgMC4wMDQwMDBdIElu
aXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QNClsgICAgMC4wMDQwMDBdIEluaXRp
YWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmljZXMNClsgICAgMC4wMDQwMDBdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGZyZWV6ZXINClsgICAgMC4wMDQwMDBdIEluaXRpYWxpemlu
ZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMNClsgICAgMC4wMDQwMDBdIENQVTogUGh5c2ljYWwg
UHJvY2Vzc29yIElEOiAwDQpbICAgIDAuMDA0MDAwXSBDUFU6IFByb2Nlc3NvciBDb3JlIElE
OiAyDQpbICAgIDAuMDA0MDAwXSBTTVAgYWx0ZXJuYXRpdmVzOiBzd2l0Y2hpbmcgdG8gVVAg
Y29kZQ0KWyAgICAwLjAwNDAyNl0gRnJlZWluZyBTTVAgYWx0ZXJuYXRpdmVzOiAxNmsgZnJl
ZWQNClsgICAgMC4wMDQxNTFdIFBlcmZvcm1hbmNlIEV2ZW50czogDQpbICAgIDAuMDA0MTU4
XSBubyBBUElDLCBib290IHdpdGggdGhlICJsYXBpYyIgYm9vdCBwYXJhbWV0ZXIgdG8gZm9y
Y2UtZW5hYmxlIGl0Lg0KWyAgICAwLjAwNDE2Nl0gbm8gaGFyZHdhcmUgc2FtcGxpbmcgaW50
ZXJydXB0IGF2YWlsYWJsZS4NClsgICAgMC4wMDQxODRdIEJyb2tlbiBQTVUgaGFyZHdhcmUg
ZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2ZW50cyBvbmx5Lg0KWyAgICAwLjAwNDQ0NV0g
QnJvdWdodCB1cCAxIENQVXMNClsgICAgMC4wMDQ2NDJdIGRldnRtcGZzOiBpbml0aWFsaXpl
ZA0KWyAgICAwLjAxMDU3OV0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQNClsgICAgMC4wMTA2
NDVdIHByaW50X2NvbnN0cmFpbnRzOiBkdW1teTogDQpbICAgIDAuMDEwNjkzXSBORVQ6IFJl
Z2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2DQpbICAgIDAuMDEwODc2XSBFeHRlbmRlZCBD
b25maWcgU3BhY2UgZW5hYmxlZCBvbiAwIG5vZGVzDQpbICAgIDAuMDEwOTMyXSBQQ0k6IHNl
dHRpbmcgdXAgWGVuIFBDSSBmcm9udGVuZCBzdHViDQpbICAgIDAuMDEwOTMyXSBiaW86IGNy
ZWF0ZSBzbGFiIDxiaW8tMD4gYXQgMA0KWyAgICAwLjAxMDkzMl0gQUNQSTogSW50ZXJwcmV0
ZXIgZGlzYWJsZWQuDQpbICAgIDAuMDEyMDM0XSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5n
IGJhbGxvb24gZHJpdmVyLg0KWyAgICAwLjAxMjA3M10geGVuLWJhbGxvb246IEluaXRpYWxp
c2luZyBiYWxsb29uIGRyaXZlci4NClsgICAgMC4wMTIwNzNdIHZnYWFyYjogbG9hZGVkDQpb
ICAgIDAuMDEyMTE2XSBQQ0k6IFN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IFBDSQ0KWyAgICAw
LjAxMjEyMl0gUENJOiBTeXN0ZW0gZG9lcyBub3Qgc3VwcG9ydCBQQ0kNClsgICAgMC4wMTIy
MjhdIFN3aXRjaGluZyB0byBjbG9ja3NvdXJjZSB4ZW4NClsgICAgMC4wMTM2NjZdIHBucDog
UG5QIEFDUEk6IGRpc2FibGVkDQpbICAgIDAuMDE1MjcxXSBORVQ6IFJlZ2lzdGVyZWQgcHJv
dG9jb2wgZmFtaWx5IDINClsgICAgMC4wMTUzNTddIElQIHJvdXRlIGNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KWyAgICAwLjAxNTYy
Ml0gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVyOiA2
LCAyNjIxNDQgYnl0ZXMpDQpbICAgIDAuMDE1Nzk5XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVu
dHJpZXM6IDE2Mzg0IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KWyAgICAwLjAxNTg5Ml0g
VENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4NCBiaW5kIDE2
Mzg0KQ0KWyAgICAwLjAxNTkwMF0gVENQIHJlbm8gcmVnaXN0ZXJlZA0KWyAgICAwLjAxNTkx
NF0gVURQIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogMSwgODE5MiBieXRlcykN
ClsgICAgMC4wMTU5MjhdIFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRl
cjogMSwgODE5MiBieXRlcykNClsgICAgMC4wMTYwMTFdIE5FVDogUmVnaXN0ZXJlZCBwcm90
b2NvbCBmYW1pbHkgMQ0KWyAgICAwLjAxNjExNl0gVW5wYWNraW5nIGluaXRyYW1mcy4uLg0K
WyAgICAwLjA1NjczMV0gRnJlZWluZyBpbml0cmQgbWVtb3J5OiAyODU1MmsgZnJlZWQNClsg
ICAgMC4wNjczMDhdIHBsYXRmb3JtIHJ0Y19jbW9zOiByZWdpc3RlcmVkIHBsYXRmb3JtIFJU
QyBkZXZpY2UgKG5vIFBOUCBkZXZpY2UgZm91bmQpDQpbICAgIDAuMDY3NTQ3XSBhdWRpdDog
aW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkNClsgICAgMC4wNjc1NjNd
IHR5cGU9MjAwMCBhdWRpdCgxMzMwNTE5NDkzLjQ3MToxKTogaW5pdGlhbGl6ZWQNClsgICAg
MC4wNzk4MjldIEh1Z2VUTEIgcmVnaXN0ZXJlZCAyIE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9j
YXRlZCAwIHBhZ2VzDQpbICAgIDAuMDgxNzAxXSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYu
NS4yDQpbICAgIDAuMDgxNzY2XSBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUx
MiAob3JkZXIgMCwgNDA5NiBieXRlcykNClsgICAgMC4wODE4NjRdIG1zZ21uaSBoYXMgYmVl
biBzZXQgdG8gNTkxDQpbICAgIDAuMDgyMDc4XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMg
KGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUzKQ0KWyAgICAwLjA4
MjA4N10gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZA0KWyAgICAwLjA4MjA5Ml0gaW8g
c2NoZWR1bGVyIGRlYWRsaW5lIHJlZ2lzdGVyZWQNClsgICAgMC4wODIxMjZdIGlvIHNjaGVk
dWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkNClsgICAgMC4wOTg0MDRdIFNlcmlhbDog
ODI1MC8xNjU1MCBkcml2ZXIsIDQgcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQNClsgICAg
MC4wOTg2OThdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMw0KWyAgICAwLjA5OTIx
OV0gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRz
IGRpcmVjdGx5Lg0KWyAgICAwLjEwMDAzN10gaTgwNDI6IE5vIGNvbnRyb2xsZXIgZm91bmQN
ClsgICAgMC4xMDAxMjJdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9y
IGFsbCBtaWNlDQpbICAgIDAuMTQwMTA3XSBydGNfY21vcyBydGNfY21vczogcnRjIGNvcmU6
IHJlZ2lzdGVyZWQgcnRjX2Ntb3MgYXMgcnRjMA0KWyAgICAwLjE0MDE4MV0gcnRjX2Ntb3M6
IHByb2JlIG9mIHJ0Y19jbW9zIGZhaWxlZCB3aXRoIGVycm9yIC0zOA0KWyAgICAwLjE0MDI2
NV0gcGNpZnJvbnQgcGNpLTA6IEluc3RhbGxpbmcgUENJIGZyb250ZW5kDQpbICAgIDAuMTQw
NDU4XSBwY2lmcm9udCBwY2ktMDogQ3JlYXRpbmcgUENJIEZyb250ZW5kIEJ1cyAwMDAwOjAw
DQpbICAgIDAuMTU2MzA3XSBUQ1AgY3ViaWMgcmVnaXN0ZXJlZA0KWyAgICAwLjE1NjQzNF0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMA0KWyAgICAwLjE1Njk5OV0gTW9i
aWxlIElQdjYNClsgICAgMC4xNTcwMTNdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMTcNClsgICAgMC4xNTcwMjFdIFJlZ2lzdGVyaW5nIHRoZSBkbnNfcmVzb2x2ZXIga2V5
IHR5cGUNClsgICAgMC4xNTcxNjJdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQ0K
WyAgICAwLjE2OTQ1NV0gcGNpZnJvbnQgcGNpLTA6IGNsYWltaW5nIHJlc291cmNlIDAwMDA6
MDA6MDAuMC8wDQpbICAgIDAuMTY5NDY3XSBwY2lmcm9udCBwY2ktMDogY2xhaW1pbmcgcmVz
b3VyY2UgMDAwMDowMDowMS4wLzANClsgICAgMC4xNjk0NzNdIHBjaWZyb250IHBjaS0wOiBj
bGFpbWluZyByZXNvdXJjZSAwMDAwOjAwOjAyLjAvMA0KWyAgICAwLjI1NjE1OF0gWEVOQlVT
OiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS92YmQvNTE3MTMNClsgICAgMC4yNTYx
OTNdIFhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmJkLzUxNzE0DQpb
ICAgIDAuMjU2MjEwXSBYRU5CVVM6IERldmljZSB3aXRoIG5vIGRyaXZlcjogZGV2aWNlL3Zi
ZC81MTcyOQ0KWyAgICAwLjI1NjIyNV0gWEVOQlVTOiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6
IGRldmljZS92aWYvMA0KWyAgICAwLjI1NjIzOV0gWEVOQlVTOiBEZXZpY2Ugd2l0aCBubyBk
cml2ZXI6IGRldmljZS9jb25zb2xlLzANClsgICAgMC4yNTYyODldIGRyaXZlcnMvcnRjL2hj
dG9zeXMuYzogdW5hYmxlIHRvIG9wZW4gcnRjIGRldmljZSAocnRjMCkNClsgICAgMC4yNTYz
NjVdIEluaXRpYWxpemluZyBuZXR3b3JrIGRyb3AgbW9uaXRvciBzZXJ2aWNlDQpbICAgIDAu
MjU3MTkxXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA1NjhrIGZyZWVkDQpbICAg
IDAuMjU3NTczXSBXcml0ZSBwcm90ZWN0aW5nIHRoZSBrZXJuZWwgcmVhZC1vbmx5IGRhdGE6
IDYxNDRrDQpbICAgIDAuMjY2NDUwXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA2
OTZrIGZyZWVkDQpbICAgIDAuMjY4MDAzXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5
OiA4NDRrIGZyZWVkDQpMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLg0KWyAgICAwLjMyNDM4NF0g
dWRldls0NF06IHN0YXJ0aW5nIHZlcnNpb24gMTY0DQpbICAgIDAuMzY2MDcxXSBJbml0aWFs
aXNpbmcgWGVuIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVyLg0KWyAgICAwLjQ3NzIxNF0gYmxr
ZnJvbnQ6IHh2ZGExOiBiYXJyaWVyOiBlbmFibGVkDQpbICAgIDAuNDkzNDI4XSBibGtmcm9u
dDogeHZkYTI6IGJhcnJpZXI6IGVuYWJsZWQNClsgICAgMC41MDE4NDVdIFNldHRpbmcgY2Fw
YWNpdHkgdG8gODM4ODYwOA0KWyAgICAwLjUwMTg2MF0geHZkYTE6IGRldGVjdGVkIGNhcGFj
aXR5IGNoYW5nZSBmcm9tIDAgdG8gNDI5NDk2NzI5Ng0KWyAgICAwLjUwMjcwMF0gYmxrZnJv
bnQ6IHh2ZGIxOiBiYXJyaWVyOiBlbmFibGVkDQpbICAgIDAuNTA2MTg2XSBTZXR0aW5nIGNh
cGFjaXR5IHRvIDIwOTcxNTINClsgICAgMC41MDYyMDNdIHh2ZGEyOiBkZXRlY3RlZCBjYXBh
Y2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDEwNzM3NDE4MjQNClsgICAgMC41MDY1NzJdIFNldHRp
bmcgY2FwYWNpdHkgdG8gMjkzMDI3MjAwMg0KWyAgICAwLjUwNjU4MV0geHZkYjE6IGRldGVj
dGVkIGNhcGFjaXR5IGNoYW5nZSBmcm9tIDAgdG8gMTUwMDI5OTI2NTAyNA0KQmVnaW46IExv
YWRpbmcgZXNzZW50aWFsIGRyaXZlcnMgLi4uIGRvbmUuDQpCZWdpbjogUnVubmluZyAvc2Ny
aXB0cy9pbml0LXByZW1vdW50IC4uLiBkb25lLg0KQmVnaW46IE1vdW50aW5nIHJvb3QgZmls
ZSBzeXN0ZW0gLi4uIEJlZ2luOiBSdW5uaW5nIC9zY3JpcHRzL2xvY2FsLXRvcCAuLi4gZG9u
ZS4NCkJlZ2luOiBSdW5uaW5nIC9zY3JpcHRzL2xvY2FsLXByZW1vdW50IC4uLiBbICAgIDAu
Njk1NzM2XSBQTTogU3RhcnRpbmcgbWFudWFsIHJlc3VtZSBmcm9tIGRpc2sNCmRvbmUuDQpb
ICAgIDAuNzI5Njg4XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBz
ZWNvbmRzDQpbICAgIDAuNzI5NzM1XSBFWFQzLWZzICh4dmRhMSk6IG1vdW50ZWQgZmlsZXN5
c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlDQpCZWdpbjogUnVubmluZyAvc2NyaXB0cy9s
b2NhbC1ib3R0b20gLi4uIGRvbmUuDQpkb25lLg0KQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv
aW5pdC1ib3R0b20gLi4uIGRvbmUuDQoNSU5JVDogdmVyc2lvbiAyLjg4IGJvb3RpbmcNDQpV
c2luZyBtYWtlZmlsZS1zdHlsZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgUy4NClN0
YXJ0aW5nIHRoZSBob3RwbHVnIGV2ZW50cyBkaXNwYXRjaGVyOiB1ZGV2ZFsgICAgMS42OTg2
NjVdIHVkZXZbMTU1XTogc3RhcnRpbmcgdmVyc2lvbiAxNjQNCi4NClN5bnRoZXNpemluZyB0
aGUgaW5pdGlhbCBob3RwbHVnIGV2ZW50cy4uLmRvbmUuDQpXYWl0aW5nIGZvciAvZGV2IHRv
IGJlIGZ1bGx5IHBvcHVsYXRlZC4uLlsgICAgMS45NTY1NDFdIGlucHV0OiBQQyBTcGVha2Vy
IGFzIC9kZXZpY2VzL3BsYXRmb3JtL3Bjc3Brci9pbnB1dC9pbnB1dDANClsgICAgMi4yODIw
MTZdIEVycm9yOiBEcml2ZXIgJ3Bjc3BrcicgaXMgYWxyZWFkeSByZWdpc3RlcmVkLCBhYm9y
dGluZy4uLg0KWyAgICAyLjMzMTEyNl0gTGludXggdmlkZW8gY2FwdHVyZSBpbnRlcmZhY2U6
IHYyLjAwDQpbICAgIDIuMzUxOTgxXSBzYWE3MTQ2OiByZWdpc3RlciBleHRlbnNpb24gJ2J1
ZGdldF9hdicNClsgICAgMi4zNTI2MjJdIGJ1ZGdldF9hdiAwMDAwOjAwOjAwLjA6IGVuYWJs
aW5nIGRldmljZSAoMDAwMCAtPiAwMDAyKQ0KWyAgICAyLjM1MzYyOF0gYnVkZ2V0X2F2IDAw
MDA6MDA6MDAuMDogWGVuIFBDSSBtYXBwZWQgR1NJMTcgdG8gSVJRMjgNClsgICAgMi4zNTQz
MTZdIHNhYTcxNDY6IGZvdW5kIHNhYTcxNDYgQCBtZW0gZmZmZmM5MDAwMDQwNjAwMCAocmV2
aXNpb24gMSwgaXJxIDI4KSAoMHgxODk0LDB4MDAyOCkNClsgICAgMi4zNTQzNDRdIHNhYTcx
NDYgKDApOiBkbWEgYnVmZmVyIHNpemUgMTM0NzU4NA0KWyAgICAyLjM1NDM2MF0gRFZCOiBy
ZWdpc3RlcmluZyBuZXcgYWRhcHRlciAoS05DMSBEVkItQyBUREExMDAyNCkNClsgICAgMi4z
ODkzNzhdIGFkYXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sNClsgICAgMi4zODk0
MDVdIGVuY29kZWQgTUFDIGZyb20gRUVQUk9NIHdhcyBmZjpmZjpmZjpmZjpmZjpmZjpmZjpm
ZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZg0KWyAgICAyLjY2MDU5NV0g
YnVkZ2V0X2F2OiBLTkMxLTA6IE1BQyBhZGRyID0gMDA6MDk6ZDY6NmQ6YjM6MGENClsgICAg
Mi44MjkxNzJdIERWQjogcmVnaXN0ZXJpbmcgYWRhcHRlciAwIGZyb250ZW5kIDAgKFBoaWxp
cHMgVERBMTAwMjMgRFZCLUMpLi4uDQpbICAgIDIuODI5ODQ3XSBidWRnZXRfYXY6IGNpIGlu
dGVyZmFjZSBpbml0aWFsaXNlZA0KWyAgICAyLjgzMDM3MV0gYnVkZ2V0X2F2IDAwMDA6MDA6
MDEuMDogWGVuIFBDSSBtYXBwZWQgR1NJMTggdG8gSVJRMjkNClsgICAgMi44MzExOTBdIHNh
YTcxNDY6IGZvdW5kIHNhYTcxNDYgQCBtZW0gZmZmZmM5MDAwMDY5ODAwMCAocmV2aXNpb24g
MSwgaXJxIDI5KSAoMHgxODk0LDB4MDAyYykNClsgICAgMi44MzEyMTddIHNhYTcxNDYgKDEp
OiBkbWEgYnVmZmVyIHNpemUgMTM0NzU4NA0KWyAgICAyLjgzMTIzM10gRFZCOiByZWdpc3Rl
cmluZyBuZXcgYWRhcHRlciAoU2F0ZWxjbyBFYXN5V2F0Y2ggRFZCLUMgTUszKQ0KWyAgICAy
Ljg2NjAwOV0gYWRhcHRlciBmYWlsZWQgTUFDIHNpZ25hdHVyZSBjaGVjaw0KWyAgICAyLjg2
NjAzNl0gZW5jb2RlZCBNQUMgZnJvbSBFRVBST00gd2FzIGZmOmZmOmZmOmZmOmZmOmZmOmZm
OmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmDQpbICAgIDMuMTQwNzM2
XSBidWRnZXRfYXY6IEtOQzEtMTogTUFDIGFkZHIgPSAwMDowOTpkNjo2ZDpiMDozMw0KWyAg
ICAzLjI4MTE3MF0gRFZCOiByZWdpc3RlcmluZyBhZGFwdGVyIDEgZnJvbnRlbmQgMCAoUGhp
bGlwcyBUREExMDAyMyBEVkItQykuLi4NClsgICAgMy4yODM3OTBdIGJ1ZGdldF9hdjogY2kg
aW50ZXJmYWNlIGluaXRpYWxpc2VkDQpbICAgIDMuMjg0NTA3XSBidWRnZXRfYXYgMDAwMDow
MDowMi4wOiBYZW4gUENJIG1hcHBlZCBHU0kxOSB0byBJUlEzMA0KWyAgICAzLjI4NTEyNV0g
c2FhNzE0NjogZm91bmQgc2FhNzE0NiBAIG1lbSBmZmZmYzkwMDAwOTI2MDAwIChyZXZpc2lv
biAxLCBpcnEgMzApICgweDE4OTQsMHgwMDIyKQ0KWyAgICAzLjI4NTE1NV0gc2FhNzE0NiAo
Mik6IGRtYSBidWZmZXIgc2l6ZSAxMzQ3NTg0DQpbICAgIDMuMjg1MTcxXSBEVkI6IHJlZ2lz
dGVyaW5nIG5ldyBhZGFwdGVyIChLTkMxIERWQi1DIE1LMykNClsgICAgMy4zMjE0MzddIGFk
YXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sNClsgICAgMy4zMjE0NjZdIGVuY29k
ZWQgTUFDIGZyb20gRUVQUk9NIHdhcyBmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpm
ZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZg0KWyAgICAzLjU5NjYwMl0gYnVkZ2V0X2F2
OiBLTkMxLTI6IE1BQyBhZGRyID0gMDA6MDk6ZDY6NmQ6NmQ6N2ENClsgICAgMy43MzcxNjZd
IERWQjogcmVnaXN0ZXJpbmcgYWRhcHRlciAyIGZyb250ZW5kIDAgKFBoaWxpcHMgVERBMTAw
MjMgRFZCLUMpLi4uDQpbICAgIDMuNzM3ODI2XSBidWRnZXRfYXY6IGNpIGludGVyZmFjZSBp
bml0aWFsaXNlZA0KZG9uZS4NCkFjdGl2YXRpbmcgc3dhcC4uLlsgICAgMy45NzczNDJdIEFk
ZGluZyAxMDQ4NTcyayBzd2FwIG9uIC9kZXYveHZkYTIuICBQcmlvcml0eTotMSBleHRlbnRz
OjEgYWNyb3NzOjEwNDg1NzJrIFNTDQpkb25lLg0KWyAgICAzLjk4NTY1N10gRVhUMy1mcyAo
eHZkYTEpOiB3YXJuaW5nOiBtYXhpbWFsIG1vdW50IGNvdW50IHJlYWNoZWQsIHJ1bm5pbmcg
ZTJmc2NrIGlzIHJlY29tbWVuZGVkDQpbICAgIDMuOTg2MDYxXSBFWFQzLWZzICh4dmRhMSk6
IHVzaW5nIGludGVybmFsIGpvdXJuYWwNCkxvYWRpbmcga2VybmVsIG1vZHVsZXMuLi5kb25l
Lg0KQ2xlYW5pbmcgdXAgaWZ1cGRvd24uLi4uDQpTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4u
DQpBY3RpdmF0aW5nIGx2bSBhbmQgbWQgc3dhcC4uLmRvbmUuDQpDaGVja2luZyBmaWxlIHN5
c3RlbXMuLi5mc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjINCmRvbmUuDQpNb3VudGlu
ZyBsb2NhbCBmaWxlc3lzdGVtcy4uLlsgICAgNC40Mjg1NDBdIGtqb3VybmFsZCBzdGFydGlu
Zy4gIENvbW1pdCBpbnRlcnZhbCA1IHNlY29uZHMNClsgICAgNC40Mjk2ODBdIEVYVDMtZnMg
KHh2ZGIxKTogd2FybmluZzogbWF4aW1hbCBtb3VudCBjb3VudCByZWFjaGVkLCBydW5uaW5n
IGUyZnNjayBpcyByZWNvbW1lbmRlZA0KWyAgICA0LjQzMjM3MF0gRVhUMy1mcyAoeHZkYjEp
OiB1c2luZyBpbnRlcm5hbCBqb3VybmFsDQpbICAgIDQuNDMyMzk5XSBFWFQzLWZzICh4dmRi
MSk6IHJlY292ZXJ5IGNvbXBsZXRlDQpbICAgIDQuNDMyNDE5XSBFWFQzLWZzICh4dmRiMSk6
IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlDQpkb25lLg0KQWN0
aXZhdGluZyBzd2FwZmlsZSBzd2FwLi4uZG9uZS4NCkNsZWFuaW5nIHVwIHRlbXBvcmFyeSBm
aWxlcy4uLi4NCkNvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJmYWNlcy4uLlNldHRpbmcga2Vy
bmVsIHZhcmlhYmxlcyAuLi5lcnJvcjogInhlbi5pbmRlcGVuZGVudF93YWxsY2xvY2siIGlz
IGFuIHVua25vd24ga2V5DQobWzMxbWZhaWxlZC4bWzM5OzQ5bQ0KZG9uZS4NClN0YXJ0aW5n
IHBvcnRtYXAgZGFlbW9uLi4uLg0KU3RhcnRpbmcgTkZTIGNvbW1vbiB1dGlsaXRpZXM6IHN0
YXRkWyAgICA1LjQ2OTgxN10gUlBDOiBSZWdpc3RlcmVkIG5hbWVkIFVOSVggc29ja2V0IHRy
YW5zcG9ydCBtb2R1bGUuDQpbICAgIDUuNDY5ODU0XSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRy
YW5zcG9ydCBtb2R1bGUuDQpbICAgIDUuNDY5ODcwXSBSUEM6IFJlZ2lzdGVyZWQgdGNwIHRy
YW5zcG9ydCBtb2R1bGUuDQpbICAgIDUuNDY5ODg0XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5G
U3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4NClsgICAgNS41MzU3ODddIEZT
LUNhY2hlOiBMb2FkZWQNClsgICAgNS41NjY1NDJdIEZTLUNhY2hlOiBOZXRmcyAnbmZzJyBy
ZWdpc3RlcmVkIGZvciBjYWNoaW5nDQpbICAgIDUuNjAxNzU5XSBJbnN0YWxsaW5nIGtuZnNk
IChjb3B5cmlnaHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLg0KIGlkbWFwZC4NCkNs
ZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4NClNldHRpbmcgY29uc29sZSBzY3JlZW4g
bW9kZXMgYW5kIGZvbnRzLg0KG11SY2Fubm90ICh1bilzZXQgcG93ZXJzYXZlIG1vZGUNChtb
OTszMF0bWzE0OzMwXQ1JTklUOiBFbnRlcmluZyBydW5sZXZlbDogMg0NClVzaW5nIG1ha2Vm
aWxlLXN0eWxlIGNvbmN1cnJlbnQgYm9vdCBpbiBydW5sZXZlbCAyLg0KU3RhcnRpbmcgcG9y
dG1hcCBkYWVtb24uLi5BbHJlYWR5IHJ1bm5pbmcuLg0KU3RhcnRpbmcgTkZTIGNvbW1vbiB1
dGlsaXRpZXM6IHN0YXRkIGlkbWFwZC4NClN0YXJ0aW5nIGVuaGFuY2VkIHN5c2xvZ2Q6IHJz
eXNsb2dkLg0KWyAgICA2LjUwMDgyM10gc3ZjOiBmYWlsZWQgdG8gcmVnaXN0ZXIgbG9ja2R2
MSBSUEMgc2VydmljZSAoZXJybm8gOTcpLg0KWyAgICA2LjUwNDM5OV0gTkZTRDogVXNpbmcg
L3Zhci9saWIvbmZzL3Y0cmVjb3ZlcnkgYXMgdGhlIE5GU3Y0IHN0YXRlIHJlY292ZXJ5IGRp
cmVjdG9yeQ0KWyAgICA2LjUyNjY4OF0gTkZTRDogc3RhcnRpbmcgOTAtc2Vjb25kIGdyYWNl
IHBlcmlvZA0KRXhwb3J0aW5nIGRpcmVjdG9yaWVzIGZvciBORlMga2VybmVsIGRhZW1vbi4u
Li4NClN0YXJ0aW5nIE5GUyBrZXJuZWwgZGFlbW9uOiBuZnNkIG1vdW50ZC4NClN0YXJ0aW5n
IHBlcmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLg0KU3RhcnRpbmcgc3lzdGVtIG1l
c3NhZ2UgYnVzOiBkYnVzLg0KU3RhcnRpbmcgTlRQIHNlcnZlcjogbnRwZC4NClN0YXJ0aW5n
IFNhbWJhIGRhZW1vbnM6IG5tYmQgc21iZC4NClN0YXJ0aW5nIE9wZW5CU0QgU2VjdXJlIFNo
ZWxsIHNlcnZlcjogc3NoZFsgICAgNy45NDE2NDldIHNzaGQgKDcwMyk6IC9wcm9jLzcwMy9v
b21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvNzAzL29vbV9zY29yZV9h
ZGogaW5zdGVhZC4NCi4NClN0YXJ0aW5nIExpbnV4IFZpZGVvIERpc2sgUmVjb3JkZXI6IHZk
cg0KU2VhcmNoaW5nIGZvciBwbHVnaW5zIChWRFIgMS43LjIxLzEuNy4yMSkgKGNhY2hlIGhp
dCk6dmRyYWRtaW4tYW06IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCiBlcGdzZWFyY2hv
bmx5IHh2ZHIgZXBnc2VhcmNoIHZvbXBzZXJ2ZXIgZmVtb24gcXVpY2tlcGdzZWFyY2ggY29u
ZmxpY3RjaGVja29ubHkgd2lyYmVsc2Nhbi4NClN0YXJ0aW5nIE11bmluLU5vZGU6IGRvbmUu
DQpzdGFydHBhcjogc2VydmljZShzKSByZXR1cm5lZCBmYWlsdXJlOiB2ZHJhZG1pbi1hbSAu
Li4gG1szMW1mYWlsZWQhG1szOTs0OW0NClsgICAxNC42NzQ4ODNdIEJVRzogdW5hYmxlIHRv
IGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQgZmZmZmM3ZmZmZmZmZjAwMA0KWyAg
IDE0LjY3NDkxMF0gSVA6IFs8ZmZmZmZmZmY4MTFiNGMwYj5dIHN3aW90bGJfYm91bmNlKzB4
MmUvMHgzMQ0KWyAgIDE0LjY3NDkzMF0gUEdEIDAgDQpbICAgMTQuNjc0OTQwXSBPb3BzOiAw
MDAyIFsjMV0gU01QIA0KWyAgIDE0LjY3NDk1Ml0gQ1BVIDAgDQpbICAgMTQuNjc0OTU3XSBN
b2R1bGVzIGxpbmtlZCBpbjogbmZzZCBleHBvcnRmcyBuZnMgbG9ja2QgZnNjYWNoZSBhdXRo
X3JwY2dzcyBuZnNfYWNsIHN1bnJwYyB0ZGExMDAyMyBidWRnZXRfYXYgZXZkZXYgc2FhNzE0
Nl92diB2aWRlb2RldiB2NGwyX2NvbXBhdF9pb2N0bDMyIHZpZGVvYnVmX2RtYV9zZyB2aWRl
b2J1Zl9jb3JlIGJ1ZGdldF9jb3JlIHNuZF9wY20gZHZiX2NvcmUgc25kX3RpbWVyIHNhYTcx
NDYgc25kIHR0cGNpX2VlcHJvbSBzb3VuZGNvcmUgc25kX3BhZ2VfYWxsb2MgaTJjX2NvcmUg
cGNzcGtyIGV4dDMgamJkIG1iY2FjaGUgeGVuX25ldGZyb250IHhlbl9ibGtmcm9udA0KWyAg
IDE0LjY3NTA1N10gDQpbICAgMTQuNjc1MDY1XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBO
b3QgdGFpbnRlZCAzLjIuOC1hbWQ2NCAjMSAgDQpbICAgMTQuNjc1MDc5XSBSSVA6IGUwMzA6
WzxmZmZmZmZmZjgxMWI0YzBiPl0gIFs8ZmZmZmZmZmY4MTFiNGMwYj5dIHN3aW90bGJfYm91
bmNlKzB4MmUvMHgzMQ0KWyAgIDE0LjY3NTA5N10gUlNQOiBlMDJiOmZmZmY4ODAwMTNmYWJl
NTggIEVGTEFHUzogMDAwMTAyMDINClsgICAxNC42NzUxMDZdIFJBWDogZmZmZjg4MDAxMjgw
MDAwMCBSQlg6IDAwMDAwMDAwMDAwMDAwMDEgUkNYOiAwMDAwMDAwMDAwMDAxMDAwDQpbICAg
MTQuNjc1MTE2XSBSRFg6IDAwMDAwMDAwMDAwMDEwMDAgUlNJOiBmZmZmODgwMDEyODAwMDAw
IFJESTogZmZmZmM3ZmZmZmZmZjAwMA0KWyAgIDE0LjY3NTEyNl0gUkJQOiAwMDAwMDAwMDAw
MDAwMDAyIFIwODogZmZmZmM3ZmZmZmZmZjAwMCBSMDk6IGZmZmY4ODAwMTNmOTgwMDANClsg
ICAxNC42NzUxMzddIFIxMDogMDAwMDAwMDAwMDAwMDAwMSBSMTE6IGZmZmY4ODAwMDMzNzYw
MDAgUjEyOiBmZmZmODgwMDAzMmM1MDkwDQpbICAgMTQuNjc1MTQ3XSBSMTM6IDAwMDAwMDAw
MDAwMDAxNDkgUjE0OiBmZmZmODgwMDAzM2UwMDAwIFIxNTogZmZmZmZmZmY4MTYwMWZkOA0K
WyAgIDE0LjY3NTE2M10gRlM6ICAwMDAwN2YzZmY5ODkzNzAwKDAwMDApIEdTOmZmZmY4ODAw
MTNmYTgwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMA0KWyAgIDE0LjY3NTE3NV0g
Q1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYg0KWyAg
IDE0LjY3NTE4NF0gQ1IyOiBmZmZmYzdmZmZmZmZmMDAwIENSMzogMDAwMDAwMDAxMjY4MzAw
MCBDUjQ6IDAwMDAwMDAwMDAwMDA2NjANClsgICAxNC42NzUxOTVdIERSMDogMDAwMDAwMDAw
MDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAwMDAwDQpb
ICAgMTQuNjc1MjA1XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYw
ZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMA0KWyAgIDE0LjY3NTIxNl0gUHJvY2VzcyBzd2Fw
cGVyLzAgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZmZjgxNjAwMDAwLCB0YXNrIGZmZmZm
ZmZmODE2MGQwMjApDQpbICAgMTQuNjc1MjI3XSBTdGFjazoNClsgICAxNC42NzUyMzJdICBm
ZmZmZmZmZjgxMjExODI2IGZmZmY4ODAwMDJlZGEwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZm
YzkwMDAwNDA4MDAwDQpbICAgMTQuNjc1MjUxXSAgMDAwMDAwMDAwMDBiMDE1MCAwMDAwMDAw
MDAwMDAwMDA2IGZmZmZmZmZmYTAxM2VjNGEgZmZmZmZmZmY4MTA5NDZjZA0KWyAgIDE0LjY3
NTI3MF0gIGZmZmZmZmZmODEwOTkyMDMgZmZmZjg4MDAwMzM3NjAwMCAwMDAwMDAwMDAwMDAw
MDAwIGZmZmY4ODAwMDJlZGE0YjANClsgICAxNC42NzUyODldIENhbGwgVHJhY2U6DQpbICAg
MTQuNjc1Mjk1XSAgPElSUT4gDQpbICAgMTQuNjc1MzA3XSAgWzxmZmZmZmZmZjgxMjExODI2
Pl0gPyB4ZW5fc3dpb3RsYl9zeW5jX3NnX2Zvcl9jcHUrMHgyZS8weDQ3DQpbICAgMTQuNjc1
MzIyXSAgWzxmZmZmZmZmZmEwMTNlYzRhPl0gPyB2cGVpcnErMHg3Zi8weDE5OCBbYnVkZ2V0
X2NvcmVdDQpbICAgMTQuNjc1MzM3XSAgWzxmZmZmZmZmZjgxMDk0NmNkPl0gPyBoYW5kbGVf
aXJxX2V2ZW50X3BlcmNwdSsweDE2Ni8weDE4NA0KWyAgIDE0LjY3NTM1MF0gIFs8ZmZmZmZm
ZmY4MTA5OTIwMz5dID8gX19yY3VfcHJvY2Vzc19jYWxsYmFja3MrMHg3MS8weDJmOA0KWyAg
IDE0LjY3NTM2NF0gIFs8ZmZmZmZmZmY4MTA0ZDE3NT5dID8gdGFza2xldF9hY3Rpb24rMHg3
Ni8weGM1DQpbICAgMTQuNjc1Mzc2XSAgWzxmZmZmZmZmZjgxMjBhOWFjPl0gPyBlb2lfcGly
cSsweDViLzB4NzcNClsgICAxNC42NzUzODhdICBbPGZmZmZmZmZmODEwNGNiYzY+XSA/IF9f
ZG9fc29mdGlycSsweGM0LzB4MWEwDQpbICAgMTQuNjc1NDAwXSAgWzxmZmZmZmZmZjgxMjBh
MDIyPl0gPyBfX3hlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MWM3LzB4MjA1DQpbICAgMTQuNjc1
NDEyXSAgWzxmZmZmZmZmZjgxMzRiMDZjPl0gPyBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpb
ICAgMTQuNjc1NDI1XSAgWzxmZmZmZmZmZjgxMDBmYTQ3Pl0gPyBkb19zb2Z0aXJxKzB4M2Yv
MHg3OQ0KWyAgIDE0LjY3NTQzNl0gIFs8ZmZmZmZmZmY4MTA0Yzk5Nj5dID8gaXJxX2V4aXQr
MHg0NC8weGI1DQpbICAgMTQuNjc1NDUyXSAgWzxmZmZmZmZmZjgxMjBiMDMyPl0gPyB4ZW5f
ZXZ0Y2huX2RvX3VwY2FsbCsweDI3LzB4MzINClsgICAxNC42NzU0NjRdICBbPGZmZmZmZmZm
ODEzNGIwYmU+XSA/IHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAg
IDE0LjY3NTQ3M10gIDxFT0k+IA0KWyAgIDE0LjY3NTQ4NF0gIFs8ZmZmZmZmZmY4MTAwNzM2
Zj5dID8geGVuX3Jlc3RvcmVfZmxfZGlyZWN0X3JlbG9jKzB4NC8weDQNClsgICAxNC42NzU0
OTZdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IGh5cGVyY2FsbF9wYWdlKzB4M2FhLzB4MTAw
MA0KWyAgIDE0LjY3NTUwN10gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8gaHlwZXJjYWxsX3Bh
Z2UrMHgzYWEvMHgxMDAwDQpbICAgMTQuNjc1NTIxXSAgWzxmZmZmZmZmZjgxMjZhZTE3Pl0g
PyBjcHVpZGxlX2lkbGVfY2FsbCsweDE2LzB4MWFmDQpbICAgMTQuNjc1NTMzXSAgWzxmZmZm
ZmZmZjgxMDA2ZDE0Pl0gPyB4ZW5fc2FmZV9oYWx0KzB4Yy8weDE1DQpbICAgMTQuNjc1NTQ1
XSAgWzxmZmZmZmZmZjgxMDE1MGEyPl0gPyBkZWZhdWx0X2lkbGUrMHg0Yi8weDg0DQpbICAg
MTQuNjc1NTU2XSAgWzxmZmZmZmZmZjgxMDBkZGY2Pl0gPyBjcHVfaWRsZSsweGI5LzB4ZWYN
ClsgICAxNC42NzU1NjhdICBbPGZmZmZmZmZmODE2OWFiZmY+XSA/IHN0YXJ0X2tlcm5lbCsw
eDM5NS8weDNhMA0KWyAgIDE0LjY3NTU4MF0gIFs8ZmZmZmZmZmY4MTY5YzhhNT5dID8geGVu
X3N0YXJ0X2tlcm5lbCsweDU5My8weDU5OA0KWyAgIDE0LjY3NTU4OV0gQ29kZTogODkgZjAg
NzUgMTMgNDggYmUgMDAgMDAgMDAgMDAgMDAgODggZmYgZmYgNDggOGQgMzQgMzcgNDggODkg
YzcgZWIgMTEgNDkgYjggMDAgMDAgMDAgMDAgMDAgODggZmYgZmYgNGUgOGQgMDQgMDcgNGMg
ODkgYzcgNDggODkgZDEgPGYzPiBhNCBjMyA0OCA4OSBmMCA0OCAyYiAwNSA3MCA5NiA2MiAw
MCA0YyA4YiAwZCA5OSA5NiA2MiAwMCA0OCANClsgICAxNC42NzU3MzVdIFJJUCAgWzxmZmZm
ZmZmZjgxMWI0YzBiPl0gc3dpb3RsYl9ib3VuY2UrMHgyZS8weDMxDQpbICAgMTQuNjc1NzQ4
XSAgUlNQIDxmZmZmODgwMDEzZmFiZTU4Pg0KWyAgIDE0LjY3NTc1NV0gQ1IyOiBmZmZmYzdm
ZmZmZmZmMDAwDQpbICAgMTQuNjc1NzY1XSAtLS1bIGVuZCB0cmFjZSA2Mjg4NzIyZmU5MTkw
OGNkIF0tLS0NClsgICAxNC42NzU3NzRdIEtlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBG
YXRhbCBleGNlcHRpb24gaW4gaW50ZXJydXB0DQpbICAgMTQuNjc1Nzg0XSBQaWQ6IDAsIGNv
bW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgRCAgICAgIDMuMi44LWFtZDY0ICMxDQpb
ICAgMTQuNjc1NzkzXSBDYWxsIFRyYWNlOg0KWyAgIDE0LjY3NTc5OV0gIDxJUlE+ICBbPGZm
ZmZmZmZmODEzNDBiYWM+XSA/IHBhbmljKzB4OTIvMHgxYTANClsgICAxNC42NzU4MTddICBb
PGZmZmZmZmZmODEwNDc5Njg+XSA/IGttc2dfZHVtcCsweDQxLzB4ZGQNClsgICAxNC42NzU4
MjhdICBbPGZmZmZmZmZmODEzNDM4NDE+XSA/IG9vcHNfZW5kKzB4YTkvMHhiNg0KWyAgIDE0
LjY3NTgzOV0gIFs8ZmZmZmZmZmY4MTAyZWM3NT5dID8gbm9fY29udGV4dCsweDFmZi8weDIw
Yw0KWyAgIDE0LjY3NTg1Ml0gIFs8ZmZmZmZmZmY4MTA0M2JmYT5dID8gdHJ5X3RvX3dha2Vf
dXArMHgxODEvMHgxOTENClsgICAxNC42NzU4NjNdICBbPGZmZmZmZmZmODEzNDU5MWQ+XSA/
IGRvX3BhZ2VfZmF1bHQrMHgxYWQvMHgzNGMNClsgICAxNC42NzU4NzVdICBbPGZmZmZmZmZm
ODEwMmMxMjI+XSA/IHB2Y2xvY2tfY2xvY2tzb3VyY2VfcmVhZCsweDQ2LzB4YjQNClsgICAx
NC42NzU4ODhdICBbPGZmZmZmZmZmODEwYjc2YzY+XSA/IHBlcmZfZXZlbnRfdGFza190aWNr
KzB4MjUvMHgyM2ENClsgICAxNC42NzU5MDFdICBbPGZmZmZmZmZmODEwNjMxYjg+XSA/IHJ1
bl9wb3NpeF9jcHVfdGltZXJzKzB4MjcvMHg2MWINClsgICAxNC42NzU5MTNdICBbPGZmZmZm
ZmZmODEwNmRmN2I+XSA/IHRpY2tfbm9oel9oYW5kbGVyKzB4Y2IvMHhjYg0KWyAgIDE0LjY3
NTkyNV0gIFs8ZmZmZmZmZmY4MTAxMzk2ZD5dID8gc2NoZWRfY2xvY2srMHg1LzB4OA0KWyAg
IDE0LjY3NTkzNl0gIFs8ZmZmZmZmZmY4MTAyYzEyMj5dID8gcHZjbG9ja19jbG9ja3NvdXJj
ZV9yZWFkKzB4NDYvMHhiNA0KWyAgIDE0LjY3NTk0OF0gIFs8ZmZmZmZmZmY4MTM0MmYzNT5d
ID8gcGFnZV9mYXVsdCsweDI1LzB4MzANClsgICAxNC42NzU5NTldICBbPGZmZmZmZmZmODEx
YjRjMGI+XSA/IHN3aW90bGJfYm91bmNlKzB4MmUvMHgzMQ0KWyAgIDE0LjY3NTk3MV0gIFs8
ZmZmZmZmZmY4MTIxMTgyNj5dID8geGVuX3N3aW90bGJfc3luY19zZ19mb3JfY3B1KzB4MmUv
MHg0Nw0KWyAgIDE0LjY3NTk4NV0gIFs8ZmZmZmZmZmZhMDEzZWM0YT5dID8gdnBlaXJxKzB4
N2YvMHgxOTggW2J1ZGdldF9jb3JlXQ0KWyAgIDE0LjY3NTk5N10gIFs8ZmZmZmZmZmY4MTA5
NDZjZD5dID8gaGFuZGxlX2lycV9ldmVudF9wZXJjcHUrMHgxNjYvMHgxODQNClsgICAxNC42
NzYwMDldICBbPGZmZmZmZmZmODEwOTkyMDM+XSA/IF9fcmN1X3Byb2Nlc3NfY2FsbGJhY2tz
KzB4NzEvMHgyZjgNClsgICAxNC42NzYwMjJdICBbPGZmZmZmZmZmODEwNGQxNzU+XSA/IHRh
c2tsZXRfYWN0aW9uKzB4NzYvMHhjNQ0KWyAgIDE0LjY3NjAzM10gIFs8ZmZmZmZmZmY4MTIw
YTlhYz5dID8gZW9pX3BpcnErMHg1Yi8weDc3DQpbICAgMTQuNjc2MDQ0XSAgWzxmZmZmZmZm
ZjgxMDRjYmM2Pl0gPyBfX2RvX3NvZnRpcnErMHhjNC8weDFhMA0KWyAgIDE0LjY3NjA1OV0g
IFs8ZmZmZmZmZmY4MTIwYTAyMj5dID8gX194ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDFjNy8w
eDIwNQ0KWyAgIDE0LjY3NjA3Ml0gIFs8ZmZmZmZmZmY4MTM0YjA2Yz5dID8gY2FsbF9zb2Z0
aXJxKzB4MWMvMHgzMA0KWyAgIDE0LjY3NjA4M10gIFs8ZmZmZmZmZmY4MTAwZmE0Nz5dID8g
ZG9fc29mdGlycSsweDNmLzB4NzkNClsgICAxNC42NzYwOTRdICBbPGZmZmZmZmZmODEwNGM5
OTY+XSA/IGlycV9leGl0KzB4NDQvMHhiNQ0KWyAgIDE0LjY3NjEwNl0gIFs8ZmZmZmZmZmY4
MTIwYjAzMj5dID8geGVuX2V2dGNobl9kb191cGNhbGwrMHgyNy8weDMyDQpbICAgMTQuNjc2
MTIwXSAgWzxmZmZmZmZmZjgxMzRiMGJlPl0gPyB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFj
aysweDFlLzB4MzANClsgICAxNC42NzYxMjldICA8RU9JPiAgWzxmZmZmZmZmZjgxMDA3MzZm
Pl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NA0KWyAgIDE0LjY3NjE0
OV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8gaHlwZXJjYWxsX3BhZ2UrMHgzYWEvMHgxMDAw
DQpbICAgMTQuNjc2MTYwXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyBoeXBlcmNhbGxfcGFn
ZSsweDNhYS8weDEwMDANClsgICAxNC42NzYxNzJdICBbPGZmZmZmZmZmODEyNmFlMTc+XSA/
IGNwdWlkbGVfaWRsZV9jYWxsKzB4MTYvMHgxYWYNClsgICAxNC42NzYxODRdICBbPGZmZmZm
ZmZmODEwMDZkMTQ+XSA/IHhlbl9zYWZlX2hhbHQrMHhjLzB4MTUNClsgICAxNC42NzYxOTVd
ICBbPGZmZmZmZmZmODEwMTUwYTI+XSA/IGRlZmF1bHRfaWRsZSsweDRiLzB4ODQNClsgICAx
NC42NzYyMDZdICBbPGZmZmZmZmZmODEwMGRkZjY+XSA/IGNwdV9pZGxlKzB4YjkvMHhlZg0K
WyAgIDE0LjY3NjIxN10gIFs8ZmZmZmZmZmY4MTY5YWJmZj5dID8gc3RhcnRfa2VybmVsKzB4
Mzk1LzB4M2EwDQpbICAgMTQuNjc2MjI5XSAgWzxmZmZmZmZmZjgxNjljOGE1Pl0gPyB4ZW5f
c3RhcnRfa2VybmVsKzB4NTkzLzB4NTk4DQo=
--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw--



From xen-devel-bounces@lists.xen.org Wed Feb 29 12:55:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2j3x-0002iN-G0; Wed, 29 Feb 2012 12:55:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1S2j3v-0002iG-FT
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:55:20 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330520110!16095062!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	FROM_EXCESS_QP,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24509 invoked from network); 29 Feb 2012 12:55:11 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 12:55:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=cX/TnsRBFvorpSjDmC2NmlpLcIg+1
	yp9tVWxzLaAJCg=; b=Za1pdeKu2HFij4Vs4rrqT5QgEMt8Q8NVGuQ72KzC3Fvjx
	q48R7n17WA9kkIpKBlxH+aRujFCaZjLC7hB1j17x4VZIqq0xBGZZS3i3JsAOghXV
	0/asi/K5LqtGHapHOziqXIuGIoZOvDqs8bpv12+aTOX2dT601eQWDb+eT5JeSI=
Received: (qmail 21372 invoked from network); 29 Feb 2012 13:54:35 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.158.253)
	by mail.zeus06.de with ESMTPA; 29 Feb 2012 13:54:35 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 65AD92C5FD;
	Wed, 29 Feb 2012 13:56:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id XUcE-CvZtfba; Wed, 29 Feb 2012 13:56:09 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E06392C5FC;
	Wed, 29 Feb 2012 13:56:09 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Wed, 29 Feb 2012 13:56:09 +0100
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw"
In-Reply-To: <zarafa.4f4e15b5.3926.5c7b11b715fbc27d@uhura.space.zz>
References: <zarafa.4f4e15b5.3926.5c7b11b715fbc27d@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f4e2069.413c.75dd1c180ec000b7@uhura.space.zz>
Cc: =?utf-8?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>,
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw
Content-Type: multipart/alternative; 
 boundary="=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg"

--=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am very sorry. I accidently started the DomU with the wrong config file=
, thus it's clear why there is no difference=0D=0A=0D=0Abetween the two. =
And unfortunately, the DomU with the correct config file is having a BUG:=
=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=0A[   14.674883] BUG: unable to handle ker=
nel paging request at ffffc7fffffff000=0A[   14.674910] IP: [<ffffffff811=
b4c0b>] swiotlb_bounce+0x2e/0x31=0A[   14.674930] PGD 0=20=0A[   14.67494=
0] Oops: 0002 [#1] SMP=20=0A[   14.674952] CPU 0=20=0A[   14.674957] Modu=
les linked in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc=
 tda10023 budget_av evdev saa7146_vv videodev v4l2_compat_ioctl32 videobu=
f_dma_sg videobuf_core budget_core snd_pcm dvb_core snd_timer saa7146 snd=
 ttpci_eeprom soundcore snd_page_alloc i2c_core pcspkr ext3 jbd mbcache x=
en_netfront xen_blkfront=0A[   14.675057]=20=0A[   14.675065] Pid: 0, com=
m: swapper/0 Not tainted 3.2.8-amd64 #1 =20=0A[   14.675079] RIP: e030:[<=
ffffffff811b4c0b>]  [<ffffffff811b4c0b>] swiotlb_bounce+0x2e/0x31=0A[   1=
4.675097] RSP: e02b:ffff880013fabe58  EFLAGS: 00010202=0A[   14.675106] R=
AX: ffff880012800000 RBX: 0000000000000001 RCX: 0000000000001000=0A[   14=
=2E675116] RDX: 0000000000001000 RSI: ffff880012800000 RDI: ffffc7fffffff=
000=0A[   14.675126] RBP: 0000000000000002 R08: ffffc7fffffff000 R09: fff=
f880013f98000=0A[   14.675137] R10: 0000000000000001 R11: ffff88000337600=
0 R12: ffff8800032c5090=0A[   14.675147] R13: 0000000000000149 R14: ffff8=
800033e0000 R15: ffffffff81601fd8=0A[   14.675163] FS:  00007f3ff9893700(=
0000) GS:ffff880013fa8000(0000) knlGS:0000000000000000=0A[   14.675175] C=
S:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b=0A[   14.675184] CR2: ff=
ffc7fffffff000 CR3: 0000000012683000 CR4: 0000000000000660=0A[   14.67519=
5] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000=0A[ =
  14.675205] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400=0A[   14.675216] Process swapper/0 (pid: 0, threadinfo ffffffff8160=
0000, task ffffffff8160d020)=0A[   14.675227] Stack:=0A[   14.675232]  ff=
ffffff81211826 ffff880002eda000 0000000000000000 ffffc90000408000=0A[   1=
4.675251]  00000000000b0150 0000000000000006 ffffffffa013ec4a ffffffff810=
946cd=0A[   14.675270]  ffffffff81099203 ffff880003376000 000000000000000=
0 ffff880002eda4b0=0A[   14.675289] Call Trace:=0A[   14.675295]  <IRQ>=20=
=0A[   14.675307]  [<ffffffff81211826>] =3F xen_swiotlb_sync_sg_for_cpu+0=
x2e/0x47=0A[   14.675322]  [<ffffffffa013ec4a>] =3F vpeirq+0x7f/0x198 [bu=
dget_core]=0A[   14.675337]  [<ffffffff810946cd>] =3F handle_irq_event_pe=
rcpu+0x166/0x184=0A[   14.675350]  [<ffffffff81099203>] =3F __rcu_process=
_callbacks+0x71/0x2f8=0A[   14.675364]  [<ffffffff8104d175>] =3F tasklet_=
action+0x76/0xc5=0A[   14.675376]  [<ffffffff8120a9ac>] =3F eoi_pirq+0x5b=
/0x77=0A[   14.675388]  [<ffffffff8104cbc6>] =3F __do_softirq+0xc4/0x1a0=0A=
[   14.675400]  [<ffffffff8120a022>] =3F __xen_evtchn_do_upcall+0x1c7/0x2=
05=0A[   14.675412]  [<ffffffff8134b06c>] =3F call_softirq+0x1c/0x30=0A[ =
  14.675425]  [<ffffffff8100fa47>] =3F do_softirq+0x3f/0x79=0A[   14.6754=
36]  [<ffffffff8104c996>] =3F irq_exit+0x44/0xb5=0A[   14.675452]  [<ffff=
ffff8120b032>] =3F xen_evtchn_do_upcall+0x27/0x32=0A[   14.675464]  [<fff=
fffff8134b0be>] =3F xen_do_hypervisor_callback+0x1e/0x30=0A[   14.675473]=
  <EOI>=20=0D=0A=0D=0A=C2=A0=0D=0AComplete log is attached.=0D=0A=0D=0A=C2=
=A0=0D=0ABR, Carsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-=
----=0D=0AAn:Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>;=20=0D=0ACC:K=
onrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel <xen-devel@lists.xens=
ource.com>; Jan Beulich <jbeulich@suse.com>; Sander Eikelenboom <linux@ei=
kelenboom.it>;=20=0D=0AVon:Carsten Schiers <carsten@schiers.de>=0D=0AGese=
ndet:Mi 29.02.2012 13:16=0D=0ABetreff:Re: [Xen-devel] Load increase after=
 memory upgrade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=0D=0A=0D=0AGreat =
news: it works and load is back to normal. In the attached graph you can =
see the peak=0D=0A=0D=0Ain blue (compilation of the patched 3.2.8 Kernel)=
 and then after 16.00 the going life of the=0D=0A=0D=0Avideo DomU. We are=
 below an avaerage of 7% usage (figures are in Permille).=0D=0A=0D=0A=0D=0A=
Thanks so much. Is that already "the final patch"=3F=0D=0A=0D=0A=C2=A0=0D=
=0ABR, Carsten.=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0A-----Urspr=C3=BC=
ngliche Nachricht-----=0D=0AAn:Konrad Rzeszutek Wilk <konrad.wilk@oracle.=
com>;=20=0D=0ACC:Sander Eikelenboom <linux@eikelenboom.it>; xen-devel <xe=
n-devel@lists.xensource.com>; Jan Beulich <jbeulich@suse.com>; Konrad Rze=
szutek Wilk <konrad@darnok.org>;=20=0D=0AVon:Carsten Schiers <carsten@sch=
iers.de>=0D=0AGesendet:Di 28.02.2012 15:39=0D=0ABetreff:Re: [Xen-devel] L=
oad increase after memory upgrade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=
=0D=0A=0D=0AWell let me check for a longer period of time, and especially=
, whether the DomU is still=0D=0A=0D=0Aworking (can do that only from at =
home), but load looks pretty well after applying the=0D=0A=0D=0Apatch to =
3.2.8 :-D.=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A=
-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Jan Beulich <JBeulich@suse=
=2Ecom>;=20=0D=0ACC:Konrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel =
<xen-devel@lists.xensource.com>; Carsten Schiers <carsten@schiers.de>; Sa=
nder Eikelenboom <linux@eikelenboom.it>;=20=0D=0AVon:Konrad Rzeszutek Wil=
k <konrad.wilk@oracle.com>=0D=0AGesendet:Fr 17.02.2012 16:18=0D=0ABetreff=
:Re: [Xen-devel] Load increase after memory upgrade (part2)=0D=0AOn Thu, =
Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> On 15.02.=
12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:=0D=0A>=
 >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struc=
t *area, gfp_t gfp_mask,=0D=0A> > struct page **pages;=0D=0A> > unsigned =
int nr_pages, array_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_mask & GF=
P_RECLAIM_MASK) | __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D gfp_m=
ask & (__GFP_DMA | __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=0A> >=
+if (dma_mask =3D=3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I didn't=
 spot where you force this normally invalid combination, without=0D=0A> w=
hich the change won't affect vmalloc32() in a 32-bit kernel.=0D=0A>=20=0D=
=0A> >+gfp_mask &=3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gfp_mask=
 &=3D ~(__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0ADuh!=0D=
=0AGood eyes. Thanks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=0A>=
 > nr_pages =3D (area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > array_si=
ze =3D (nr_pages * sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=0D=
=0A_______________________________________________=0D=0AXen-devel mailing=
 list=0D=0AXen-devel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/=
xen-devel=0D=0A=20=0D=0A=20=0D=0A=0D=0A=C2=A0=0D=0A
--=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv
bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+PGh0bWw+
CjxoZWFkPgogIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iWmFyYWZhIFdlYkFj
Y2VzcyB2Ny4wLjItMjk0NzAiPgogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8dGl0bGU+QVc6IFtYZW4t
ZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTwvdGl0
bGU+CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgYm9keQ0KICAgICAgew0KICAg
ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh
bnQ7DQogICAgICAgIGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgcGFkZGluZzogNXB4IDVw
eCA1cHggNXB4Ow0KICAgICAgICBtYXJnaW46IDBweDsNCiAgICAgICAgYm9yZGVyLXN0eWxl
OiBub25lOw0KICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KICAgICAgfQ0K
DQogICAgICBwLCB1bCwgbGkNCiAgICAgIHsNCiAgICAgICAgbWFyZ2luLXRvcDogMHB4Ow0K
ICAgICAgICBtYXJnaW4tYm90dG9tOiAwcHg7DQogICAgICB9DQogIDwvc3R5bGU+CjwvaGVh
ZD4KPGJvZHk+CjxwPkkgYW0gdmVyeSBzb3JyeS4gSSBhY2NpZGVudGx5IHN0YXJ0ZWQgdGhl
IERvbVUgd2l0aCB0aGUgd3JvbmcgY29uZmlnIGZpbGUsIHRodXMgaXQmIzM5O3MgY2xlYXIg
d2h5IHRoZXJlIGlzIG5vIGRpZmZlcmVuY2U8L3A+PHA+YmV0d2VlbiB0aGUgdHdvLiBBbmQg
dW5mb3J0dW5hdGVseSwgdGhlIERvbVUgd2l0aCB0aGUgY29ycmVjdCBjb25maWcgZmlsZSBp
cyBoYXZpbmcgYSBCVUc6PC9wPjxwPiZuYnNwOzwvcD48cHJlPgpbICAgMTQuNjc0ODgzXSBC
VUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZjN2Zm
ZmZmZmYwMDAKWyAgIDE0LjY3NDkxMF0gSVA6IFsmbHQ7ZmZmZmZmZmY4MTFiNGMwYiZndDtd
IHN3aW90bGJfYm91bmNlKzB4MmUvMHgzMQpbICAgMTQuNjc0OTMwXSBQR0QgMCAKWyAgIDE0
LjY3NDk0MF0gT29wczogMDAwMiBbIzFdIFNNUCAKWyAgIDE0LjY3NDk1Ml0gQ1BVIDAgClsg
ICAxNC42NzQ5NTddIE1vZHVsZXMgbGlua2VkIGluOiBuZnNkIGV4cG9ydGZzIG5mcyBsb2Nr
ZCBmc2NhY2hlIGF1dGhfcnBjZ3NzIG5mc19hY2wgc3VucnBjIHRkYTEwMDIzIGJ1ZGdldF9h
diBldmRldiBzYWE3MTQ2X3Z2IHZpZGVvZGV2IHY0bDJfY29tcGF0X2lvY3RsMzIgdmlkZW9i
dWZfZG1hX3NnIHZpZGVvYnVmX2NvcmUgYnVkZ2V0X2NvcmUgc25kX3BjbSBkdmJfY29yZSBz
bmRfdGltZXIgc2FhNzE0NiBzbmQgdHRwY2lfZWVwcm9tIHNvdW5kY29yZSBzbmRfcGFnZV9h
bGxvYyBpMmNfY29yZSBwY3Nwa3IgZXh0MyBqYmQgbWJjYWNoZSB4ZW5fbmV0ZnJvbnQgeGVu
X2Jsa2Zyb250ClsgICAxNC42NzUwNTddIApbICAgMTQuNjc1MDY1XSBQaWQ6IDAsIGNvbW06
IHN3YXBwZXIvMCBOb3QgdGFpbnRlZCAzLjIuOC1hbWQ2NCAjMSAgClsgICAxNC42NzUwNzld
IFJJUDogZTAzMDpbJmx0O2ZmZmZmZmZmODExYjRjMGImZ3Q7XSAgWyZsdDtmZmZmZmZmZjgx
MWI0YzBiJmd0O10gc3dpb3RsYl9ib3VuY2UrMHgyZS8weDMxClsgICAxNC42NzUwOTddIFJT
UDogZTAyYjpmZmZmODgwMDEzZmFiZTU4ICBFRkxBR1M6IDAwMDEwMjAyClsgICAxNC42NzUx
MDZdIFJBWDogZmZmZjg4MDAxMjgwMDAwMCBSQlg6IDAwMDAwMDAwMDAwMDAwMDEgUkNYOiAw
MDAwMDAwMDAwMDAxMDAwClsgICAxNC42NzUxMTZdIFJEWDogMDAwMDAwMDAwMDAwMTAwMCBS
U0k6IGZmZmY4ODAwMTI4MDAwMDAgUkRJOiBmZmZmYzdmZmZmZmZmMDAwClsgICAxNC42NzUx
MjZdIFJCUDogMDAwMDAwMDAwMDAwMDAwMiBSMDg6IGZmZmZjN2ZmZmZmZmYwMDAgUjA5OiBm
ZmZmODgwMDEzZjk4MDAwClsgICAxNC42NzUxMzddIFIxMDogMDAwMDAwMDAwMDAwMDAwMSBS
MTE6IGZmZmY4ODAwMDMzNzYwMDAgUjEyOiBmZmZmODgwMDAzMmM1MDkwClsgICAxNC42NzUx
NDddIFIxMzogMDAwMDAwMDAwMDAwMDE0OSBSMTQ6IGZmZmY4ODAwMDMzZTAwMDAgUjE1OiBm
ZmZmZmZmZjgxNjAxZmQ4ClsgICAxNC42NzUxNjNdIEZTOiAgMDAwMDdmM2ZmOTg5MzcwMCgw
MDAwKSBHUzpmZmZmODgwMDEzZmE4MDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAK
WyAgIDE0LjY3NTE3NV0gQ1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAw
MDA4MDA1MDAzYgpbICAgMTQuNjc1MTg0XSBDUjI6IGZmZmZjN2ZmZmZmZmYwMDAgQ1IzOiAw
MDAwMDAwMDEyNjgzMDAwIENSNDogMDAwMDAwMDAwMDAwMDY2MApbICAgMTQuNjc1MTk1XSBE
UjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERSMjogMDAwMDAw
MDAwMDAwMDAwMApbICAgMTQuNjc1MjA1XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAw
MDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMApbICAgMTQuNjc1MjE2XSBQ
cm9jZXNzIHN3YXBwZXIvMCAocGlkOiAwLCB0aHJlYWRpbmZvIGZmZmZmZmZmODE2MDAwMDAs
IHRhc2sgZmZmZmZmZmY4MTYwZDAyMCkKWyAgIDE0LjY3NTIyN10gU3RhY2s6ClsgICAxNC42
NzUyMzJdICBmZmZmZmZmZjgxMjExODI2IGZmZmY4ODAwMDJlZGEwMDAgMDAwMDAwMDAwMDAw
MDAwMCBmZmZmYzkwMDAwNDA4MDAwClsgICAxNC42NzUyNTFdICAwMDAwMDAwMDAwMGIwMTUw
IDAwMDAwMDAwMDAwMDAwMDYgZmZmZmZmZmZhMDEzZWM0YSBmZmZmZmZmZjgxMDk0NmNkClsg
ICAxNC42NzUyNzBdICBmZmZmZmZmZjgxMDk5MjAzIGZmZmY4ODAwMDMzNzYwMDAgMDAwMDAw
MDAwMDAwMDAwMCBmZmZmODgwMDAyZWRhNGIwClsgICAxNC42NzUyODldIENhbGwgVHJhY2U6
ClsgICAxNC42NzUyOTVdICAmbHQ7SVJRJmd0OyAKWyAgIDE0LjY3NTMwN10gIFsmbHQ7ZmZm
ZmZmZmY4MTIxMTgyNiZndDtdID8geGVuX3N3aW90bGJfc3luY19zZ19mb3JfY3B1KzB4MmUv
MHg0NwpbICAgMTQuNjc1MzIyXSAgWyZsdDtmZmZmZmZmZmEwMTNlYzRhJmd0O10gPyB2cGVp
cnErMHg3Zi8weDE5OCBbYnVkZ2V0X2NvcmVdClsgICAxNC42NzUzMzddICBbJmx0O2ZmZmZm
ZmZmODEwOTQ2Y2QmZ3Q7XSA/IGhhbmRsZV9pcnFfZXZlbnRfcGVyY3B1KzB4MTY2LzB4MTg0
ClsgICAxNC42NzUzNTBdICBbJmx0O2ZmZmZmZmZmODEwOTkyMDMmZ3Q7XSA/IF9fcmN1X3By
b2Nlc3NfY2FsbGJhY2tzKzB4NzEvMHgyZjgKWyAgIDE0LjY3NTM2NF0gIFsmbHQ7ZmZmZmZm
ZmY4MTA0ZDE3NSZndDtdID8gdGFza2xldF9hY3Rpb24rMHg3Ni8weGM1ClsgICAxNC42NzUz
NzZdICBbJmx0O2ZmZmZmZmZmODEyMGE5YWMmZ3Q7XSA/IGVvaV9waXJxKzB4NWIvMHg3Nwpb
ICAgMTQuNjc1Mzg4XSAgWyZsdDtmZmZmZmZmZjgxMDRjYmM2Jmd0O10gPyBfX2RvX3NvZnRp
cnErMHhjNC8weDFhMApbICAgMTQuNjc1NDAwXSAgWyZsdDtmZmZmZmZmZjgxMjBhMDIyJmd0
O10gPyBfX3hlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MWM3LzB4MjA1ClsgICAxNC42NzU0MTJd
ICBbJmx0O2ZmZmZmZmZmODEzNGIwNmMmZ3Q7XSA/IGNhbGxfc29mdGlycSsweDFjLzB4MzAK
WyAgIDE0LjY3NTQyNV0gIFsmbHQ7ZmZmZmZmZmY4MTAwZmE0NyZndDtdID8gZG9fc29mdGly
cSsweDNmLzB4NzkKWyAgIDE0LjY3NTQzNl0gIFsmbHQ7ZmZmZmZmZmY4MTA0Yzk5NiZndDtd
ID8gaXJxX2V4aXQrMHg0NC8weGI1ClsgICAxNC42NzU0NTJdICBbJmx0O2ZmZmZmZmZmODEy
MGIwMzImZ3Q7XSA/IHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MjcvMHgzMgpbICAgMTQuNjc1
NDY0XSAgWyZsdDtmZmZmZmZmZjgxMzRiMGJlJmd0O10gPyB4ZW5fZG9faHlwZXJ2aXNvcl9j
YWxsYmFjaysweDFlLzB4MzAKWyAgIDE0LjY3NTQ3M10gICZsdDtFT0kmZ3Q7IDwvcHJlPjxw
PiZuYnNwOzwvcD48cD5Db21wbGV0ZSBsb2cgaXMgYXR0YWNoZWQuPC9wPjxwPiZuYnNwOzwv
cD48cD5CUiwgQ2Fyc3Rlbi48YnIgLz4mbmJzcDs8L3A+PGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlci1sZWZ0OiAycHggc29saWQgIzMyNUZCQTsgcGFkZGluZy1sZWZ0OiA1cHg7bWFyZ2lu
LWxlZnQ6NXB4OyI+LS0tLS1VcnNwciZ1dW1sO25nbGljaGUgTmFjaHJpY2h0LS0tLS08YnIg
Lz48c3Ryb25nPkFuOjwvc3Ryb25nPglLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJh
ZC53aWxrQG9yYWNsZS5jb20mZ3Q7OyA8YnIgLz48c3Ryb25nPkNDOjwvc3Ryb25nPglLb25y
YWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZEBkYXJub2sub3JnJmd0OzsgeGVuLWRldmVs
ICZsdDt4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbSZndDs7IEphbiBCZXVsaWNoICZs
dDtqYmV1bGljaEBzdXNlLmNvbSZndDs7IFNhbmRlciBFaWtlbGVuYm9vbSAmbHQ7bGludXhA
ZWlrZWxlbmJvb20uaXQmZ3Q7OyA8YnIgLz48c3Ryb25nPlZvbjo8L3N0cm9uZz4JQ2Fyc3Rl
biBTY2hpZXJzICZsdDtjYXJzdGVuQHNjaGllcnMuZGUmZ3Q7PGJyIC8+PHN0cm9uZz5HZXNl
bmRldDo8L3N0cm9uZz4JTWkgMjkuMDIuMjAxMiAxMzoxNjxiciAvPjxzdHJvbmc+QmV0cmVm
Zjo8L3N0cm9uZz4JUmU6IFtYZW4tZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5
IHVwZ3JhZGUgKHBhcnQyKTxiciAvPjxzdHJvbmc+QW5sYWdlOjwvc3Ryb25nPglpbmxpbmUu
dHh0PGJyIC8+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHsgZm9udC1mYW1pbHk6IG1v
bm9zcGFjZTsgfTwvc3R5bGU+ICAgICAgICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3Nz
Ij4gICAgICAgLmJvZHljbGFzcyAgICAgICB7ICAgICAgICAgZm9udC1mYW1pbHk6IEFyaWFs
LCBWZXJkYW5hLCBTYW5zLVNlcmlmICEgaW1wb3J0YW50OyAgICAgICAgIGZvbnQtc2l6ZTog
MTJweDsgICAgICAgICBwYWRkaW5nOiA1cHggNXB4IDVweCA1cHg7ICAgICAgICAgbWFyZ2lu
OiAwcHg7ICAgICAgICAgYm9yZGVyLXN0eWxlOiBub25lOyAgICAgICAgIGJhY2tncm91bmQt
Y29sb3I6ICNmZmZmZmY7ICAgICAgIH0gICAgICAgIHAsIHVsLCBsaSAgICAgICB7ICAgICAg
ICAgbWFyZ2luLXRvcDogMHB4OyAgICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsgICAgICAg
fSAgIDwvc3R5bGU+ICA8ZGl2PjxwPkdyZWF0IG5ld3M6IGl0IHdvcmtzIGFuZCBsb2FkIGlz
IGJhY2sgdG8gbm9ybWFsLiBJbiB0aGUgYXR0YWNoZWQgZ3JhcGggeW91IGNhbiBzZWUgdGhl
IHBlYWs8L3A+PHA+aW4gYmx1ZSAoY29tcGlsYXRpb24gb2YgdGhlIHBhdGNoZWQgMy4yLjgg
S2VybmVsKSBhbmQgdGhlbiBhZnRlciAxNi4wMCB0aGUgZ29pbmcgbGlmZSBvZiB0aGU8L3A+
PHA+dmlkZW8gRG9tVS4gV2UgYXJlIGJlbG93IGFuIGF2YWVyYWdlIG9mIDclIHVzYWdlIChm
aWd1cmVzIGFyZSBpbiBQZXJtaWxsZSkuPC9wPjxwPjxiciAvPlRoYW5rcyBzbyBtdWNoLiBJ
cyB0aGF0IGFscmVhZHkgJnF1b3Q7dGhlIGZpbmFsIHBhdGNoJnF1b3Q7PzwvcD48cD4mbmJz
cDs8L3A+PHA+QlIsIENhcnN0ZW4uPC9wPjxwPiZuYnNwOzwvcD48cD48YnIgLz4mbmJzcDs8
aW1nIHNyYz0iZGF0YTppbWFnZS9wbmc7YmFzZTY0LGlWQk9SdzBLR2dvQUFBQU5TVWhFVWdB
QUFmRUFBQUdFQ0FJQUFBQ3B2NDVZQUFBZ0FFbEVRVlI0bk8yZGZYUVVWWjczYjBnQ0lTQUp3
U0JndGtuRWtKQTN6QVlWZlVhUGoyY2RIY2VET0lGbFpnQjNkcHhoUmtRajZLb2M1MkN2c0Rv
S0F6akJMRG1vWklOQk1OMkJCRmxmRUVrRTl4QUo2S0JFakx3NEtFaDNPcS8zbnozbitTUFBI
eGV1UmQycTZwdnVydXJxcXUvbjlPblRYWDNyM3Z1N2RldmJ2OXl1K29aOEJnQUF3QkcwdHJh
U2VQY0JBQUJBREdodGJYM2pqVGN1YVRvRkFBQ1F5THp4eGh2UWRBQUFjQWpRZEFBQWNBN1Fk
QUFBY0E3UWRBQUFTQ1FhQlpTZlF0TUJrSUlRRXU4dURJTlk5VGF4b25ZVmc0T0RUTTJoNmND
Qm1DYzl2R2J4UlV5cU5RbG91clBwNys4L2N1U0l6K2M3Zi81OFUxT1Q4aU5vdXF0WnVIRGhi
My83VytXV2YvM1hmMTIwYUZFMGRSSkNDQ0ZKU1VsWFhYVlZXVm5aOHVYTHo1NDlHMTAzWTR5
bVRvV1Y3Q2pWeldKeGhLWTdtTTdPenBhV2xyYTJ0cTZ1cnFhbXBpTkhqaWcvaGFhN21rQWdV
RlJVOU1ZYmI3QzNyNy8rZW5GeGNUQVlqS1pPcmdLQlFPRFFvVU1QUC96dzVNbVRUNXc0RVcx
Zll3YzAzZnA2UUF6NTZLT1B6cDgvci9jcE5OM3RIRDE2OUpwcnJqbDI3Tml4WThjbVRackVw
a0YvZi8rS0ZTdXV2dnJxMGFOSFYxWlcvdkRERDZ3d0lXVGp4bzBlanljMU5iV3NyT3lUVHo0
Ukt4UlY0T21ubi83bEwzL0pYbmQzZC8vTHYvekxWVmRkZGRWVlYvM21ONy9wN3U3bWUyM1lz
R0hxMUtralI0NmNNV1BHQng5OHNIbno1bW5UcHJHR0RoOCt6SXA5OGNVWFAvdlp6OGFNR1RO
cTFLaTc3cnJyekprenFrWWo2eUhmU0JTSU5Zc3Z4UEthUFRTbzFtQkF3Z1ppQUNGazllclYy
ZG5aNmVucGl4WXRDb1ZDbE5KYmI3MTE2OWF0dkV4blorZWtTWk5VNmhBS2hSWXVYSmllbmo1
eDRzUTFhOVlZeHlWVEliQVlhRHFncjczMlduRnhjWEZ4Y1YxZEhkdnlwei85NmM0Nzd6eDU4
dVFQUC95d2NPSEMzLzN1ZDJ3N0lhU3lzdkxycjc4T0JBTFBQdnRzUlVXRldKdW9tSjJkbmRk
Y2N3MTcvZGhqajkxOTk5MW56cHc1ZmZyMFAvM1RQMVZWVmZHOTVzeVo4OVZYWHdVQ2dlZWVl
MjdzMkxFUFBQQUFmM3ZqalRleVlvV0ZoZSs4ODA0d0dEeC8vdnpTcFVzWExGaWdhalN5SGxM
OVBGMW1QYjI2dXZxZWUrNlI3S0hxcmNHQWhBM0VBRUlJcS9iTW1UTjMzMzMzNDQ4L1RpbmR0
V3RYUVVIQndNQUFLL1BnZ3c4Ky8venpxaDJycXFwNGYrNjY2eTdlVDgyNFpDb0VNUWZYdllE
d2xKZVh6NW8xaTcvMWVEekhqaDFqcjArZlBqMXg0a1QybWhCeTd0dzU5am9RQ0tTa3BJaFZp
WkxYMjl1Ym1wcktYaytlUFBuenp6OW5yei83N0xNcFU2Ynd2ZjcrOTcvem1sVnZOUnNLQkFK
WFgzMjFxdEhJZWtpajBQU1dscGFaTTJmeVAyWEM5bEQxMW1CQXdnWmlBQ0hrYjMvN0czdjkr
ZWVmWDN2dHRleDFSVVhGNjYrL3pqY0dBZ0hWamxPbVRPRTdmdmJaWjVwanBZd3JiSVhBSkhE
ZEM5Qmw4K2JOTjl4d3d3MDMzUERhYTYreExTa3BLY3JsZ3FTa0pMWmRUNWlNTjdJL3lkbnI1
T1RrL3Y1KzlycXZyNDlMbFhITi9PMkhIMzU0eXkyM3BLZW42M1ZNcG9jalJvemdmV0QwOS9l
UEdESEN1QWJOSm80Y09USnQyalRscndWaGU2aDZHOW1BOEkzSzlSelZSNXJWN3RpeEl6OC92
NysvZi83OCtXdlhyaFYzVlBVbjdNaUhyUkNZQWE1N0Fib2NPWEprOHVUSlgzenh4ZkhqeHlk
UG5uejA2RkZLYVU1T3p0ZGZmeTBXamt6VG4zNzY2Vi85NmxmczllVEprNVZwNE9USmsyVnE1
bStuVEpsU1YxZDMvdno1d2NIQkN4Y3VoRTJpTlh2bzhYais1My8rUjdubDBLRkRIby9IdUFi
eHhaa3paL0x6OC9mdDI2Y3NIN2FIcXJlUkRVaFlsSG42My83Mk41NytEdzRPRmhjWFYxVlZl
VHllbnA0ZWNVZGxudjc1NTUrSEhmbXdGWUtZZyt0ZWdDNkJRR0RHakJsdnZmVVdlL3ZtbTIr
eTYxNmVlKzY1dSsrKysvang0MzE5ZlljUEg2NnNyR1FGaHFYcDdMcVhwVXVYS3E5N1diWnNH
Vi9udmV1dXV4NTk5RkdabXZuYjhlUEg3OWl4SXhRS2ZmSEZGNVdWbFpGcCtyLy8rNytYbDVk
LzlORkhvVkFvRkFydDM3OS81c3laYTlhc1laOW1aR1R3ZFNmTm12bUxHMis4Y2ZQbXphcks5
WHFvVjIxa0F4SVdRc2pQZnZhenMyZlBuajE3OXA1Nzd1SEw5SlRTdXJvNlFzaXJyNzZxdVdO
VlZSWGJrUzNFaHgzNXNCV0NtSVByWG9BdUN4Y3U1Q0xDZVBqaGh4Y3VYRGd3TU9EMWV0bEZG
MFZGUmZ5M1Uva0ZnYVNrcERGanhwU1dsajcrK09QODZoUkthVEFZWEx4NDhkaXhZOGVPSGJ0
NDhXSiszYVNrcHIvMTFsdTV1Ym5KeWNuLzhBLy9zSGJ0MnNnMGZYQndjTzNhdGNYRnhhTkdq
Um8xYWxSeGNmRmYvdklYL3VtcVZhdkdqQmxqVUxQeWhSTGpIdXBWRzltQWhJVW9ybnRadUhB
aHY1eUdVcnB0MjdacDA2YjE5ZlZwN3RqZDNmM3JYLzk2OU9qUjJkblp5dXRlOU9JS1d5R3dH
R2c2QU83aTNudnY1WGNrMkxOQ1lBeXVld0VBVUVycHdNQkFkWFYxWVdFaHYvclFiaFVDR1ZR
aURrMEh3S1VRUWp3ZVQydHJxMjByQkRJME5UWDE5dmF5MTcyOXZianVCUUFBRXBqVzF0WlBQ
LzIwcjYrdnI2L3YwMDgvYld0clUzNEtUUWNBZ0VTaXU3djd3SUVEZnIvZjcvZTN0cllxZndD
bjBIUUFBRWhvc0o0T0FBRE9BWm9PQUFBSmpJdXVaVHkrZCsveHZYdmozUXNBQUxBT3gycDZY
eWkwL3BaYjF0OXlTMThvRk8rK0FBQ0FSVGhXMHo5NDZTV3Z4K1AxZUQ1NDZhVjQ5d1VBQU9L
RFF6VDkvTW1UYS9Mem1hYXZ5YzgvZi9Ka3ZIc0VBQUNtRUF3R1cxdGIrYldNcW44MjZSQk5y
MSs4bUFrNmU5UXZYaHp2SGdFQWdDbnMyN2Z2MkxGanZiMjl2YjI5UjQ4ZVZiazlPMFRUR1U4
OTlaUk1zYTZ1THV1THlaZnM3ZWlJUzd1STE1cDJFYTgxN2RvODNtancrWHpjWUdkZ1lNRG44
eWsvZGFPbUh6eDQwUHBpOGlVdmJOb1VsM1lScnpYdElsNXIyclY1dk5IZ2lqeTl0N2YzeElr
VHYvM3RiNGVHaGs2ZlBtMzgvTC8vKzc5aHl3d05EWjA4ZVRLR3RjbVg3RHAyTEM3dElsN0Vp
M2d0aTNkb2FPanJyNzgrY2VLRS9COEtuRUFnNFB6MWRNWlRUejAxSk1HcFU2ZXNMeVpma3Jh
MXhhVmR4R3ROdTRqWG1uWnRIdStsd2liZ1JrMEhBQUE3RUpuUXVlSzZGd2J5OUdoS0lsNXIy
a1c4MXJScjgzZ3ZGWTRJTzY2bjE5ZlhGeFlXcHFhbWxwYVd0clMwOE8wclY2N2svK2Z3NjYr
L25qMTc5c2lSSTJmUG5zMytoNzI0UlFYeWRBQkFBaEdaZnRyeHVwY0hIbmlndmIyOXU3dDcw
NlpORXlaTVlCdmIydG9tVFpyRU5YM2V2SGtyVnF6bzd1NWVzV0xGL1Buek5iZW9RSjRlVFVu
RWEwMjdpTmVhZG0wZTc2WENFV0hIUEoxejRzUUpqOGRES2UzdTdpNHVMdDY3ZHkvWDlBa1RK
cHcrZlpwU2V2cjBhYWI3NGhZVnlOTUJBQWxFWkxKcDMrdGVUcDA2VlY1ZXZuUG5Ua3JwMHFW
TFgzenhSVW9wMS9RUkkwYXd2eS82Ky91VGs1TTF0M0Q2Ly83M0M2Kzg4dVR2ZjA4UEhCZ2FH
akorUHIxelo5Z3k5TUNCVTZkT3hiQTIrWkswclMwdTdTSmV4SXQ0TFl1WEhqancvMEtoQzYr
ODB0UGVIbHRkalp1bXQ3YTJlanllTFZ1MnNMZEpTVWxFQWFVMEt5dExsWldMVzFRZ1R3Y0FK
QkNSaWFjZC9kT3JxNnV6czdOMzc5NHRmc1R6OU1yS1NyNTZYbGxacWJsRkJkYlRveW1KZUsx
cEYvRmEwNjdONDcxVU9DSlVJcTRpUHBwT3J1VGl4WXZLajlpTHI3NzY2cWFiYmtwTlRiMzU1
cHRQbmp5cHVVVUY4blFBUUFJUm1YN2FVZE5OQW5sNk5DVVJyelh0SWw1cjJyVjV2SmNLUndR
MEhRQUE3SWdaTXVoR1RYZkc5N3piOGhyRUcyVkp4R3ROdS9CN2lRM0Q4bVhFTTU3eGpPZTRQ
MGZteS9qT08rKzB0N2VmUG4yNnY3OWZzNEJETkoyQlBEMmFrb2pYbW5ZUnJ6WHQyanplUzRX
SHo0VUxGNDRmUDc1Ly8vNm1wcWI5Ky9jZlAzNzh3b1VMeWdKdTFIUUFBTEFEMGNoZFgxL2Y2
ZE9uMjl2YjMzbm5IZVYyTjJxNk03N24zWmJYSU40b1N5SmVhOXAxNlhxNjZNc29ib0V2SXdE
QTJaaWhybmJ4WlJTM3dKZlI0bllScnpYdElsNXIyclY1dkpjS200QmRmQm5GTGZCbEJBQTRt
NWlvcUMzOFhoaW5GTDZNNGhiNE1zTEhEdkVpWHFmR1MyUG55MmdYVFZmNU1vcGI0TXNJQUhB
MmtZbG5Zdmd5aWx2Z3kyaHh1NGpYbW5ZUnJ6WHQyanplUzRWamdTMDBYZlJsRkxmQWx4RUE0
R3hpSXFlMjBIU1RRSjRlVFVuRWEwMjdpTmVhZG0wZTc2WENKdUJHVFFjQUFEc1FtZEFGZzBH
Yi9qL1NtSU04UFpxU2lOZWFkaEd2TmUzYVBONUxoU05pMzc1OXg0NGQ2KzN0N2UzdFBYcjA2
TDU5KzVTZk9rVFQ0Y3VJWnp6ak9iR2VJL05scEpUNmZENTJWVGVsZEdCZ3dPZnpLVDkxaUtZ
em5KZW5rdzJFYkNEV3RHdUhlSzFzRi9GYTB5N2lOU29jRWE3STB4bk9XMDgzMEhRQVFLSVRt
ZEFGQWdHc3AxOUJBbjNQZHd5UmppSGs2YWEwaTNpdGFSZnhHaFUyQWJ2NE1zcTRNTHJFbDFH
Wm05ZVMybHBTRzkvK0FBQk1Jakw5dE9OOXBKRzVNRHJQbDVGck45Tng5cGl6TW9mTGVnV3By
ZERSZExmbE5ZZzN5cEtJMTVwMkxjalRtWWh6S2JlRnBuT0c1Y0xvUEY5R2xhWVBFVUkyRUsv
WDJ6RkVXSHB1b09rQWdFUW5NdG4wKy8wLy9QQ0R6K2U3Y09IQ2hRc1hkdTNhcGZ6VUxyNk1N
aTZNenZObHJIL3NNZmJhNi9XMjVLeXFKYlV0T2F1YWM1NXJ5VmxWUVdycGdRTVZwSFo1enFx
WXQ1dUlQbmFJRi9FNktWNGFoUy9qcDU5KzJ0VFUxTm5aK2M0NzcvajkvaSsvL0ZMNXFWMThH
V1ZjR0ozbnk4alh5bXRKYllYd0dCb2FJa3Yya0NWNzR0cEhBSUJabUNHdGR2RmxsSEZoZEo0
dlk0V1dwbGZsUENlajZXNWJmMFM4VVpaRXZOYTBhODE2dXUxK0k0M01oZEY1dm94YzB5K0p1
SmZ3RjB6S2thY0Q0R0RNVUZkY24yNVJNYzJTU2sxbjhrMlc3Sm56NEVZdTVjalR6V3NYOFZy
VEx1STFLbXdDYnRSMCs4RDFtZ3U2OGpHRVBCMEFSMk9HRExwUjArM3pQYStwNmNqVHJXa1g4
VnJUTHVJMUttd0NEdEgwQlBWbEpFdjJzTmZGSzNhUUpYdFV6M3g3M1B1Slp6empPZWJQRWZz
eXdqOWRqWDIrNTVHbkR5R1BzNnBkeEd0TnUvQmxqQ1ZZVHdjQUpCQ1JDUjM4MDlYWTUzc2Vl
Zm9ROGppcjJrVzgxclRyMGp5ZFg1bk90elEwTk9UbDVTVW5KK2ZtNWpZME5GQjMrRElpVHdm
QXpVU21uL2IxVDFkcStyaHg0L3grZnlnVTh2bDhHUmtaMUNXK2pNalRrY2RaMVM3aXRhWmRW
MS8zb3RUMGtwSVN2OS9mMDlQajgvbkt5c3FvUzN3WmthY0Q0R0lpVTA0N2VnTXdsSnArNE1D
QmNlUEdFVUxHalJ0MzRNQUI2ZzVmeHJtTDE3UFhaTW1ldVl2WHMrYzVEMjVrci9uMm1MZWJp
RDUyaUJmeE9pbGVHb1V2bzMzOTA1V2FQbTNhTkw3MmN2MzExMU4zK0RJaVR3ZkF6VVNtbklt
aDZabVptWHp0WmZ6NDhkUWR2b3hreVo1TC85NEk2K21XdDR0NHJXa1g4Um9WamdnN2Fyckts
NUZTV2w5ZjcvRjRrcE9UcDA2ZCt1YWJiMUozK0RKcWFqcnlkQUJjUWt6azFCYWFiaEtKbUtl
ei95S05QTjM2ZGhHdk5lMGlYcVBDc1FDYWJpUElrajNNTUIxNU9nQXVKREtocys5MUx6RW5F
Zk4wVWRPUnAxdlRMdUsxcGwzRWExUTRGamhUMHhQWGwvSCs0cG9LVWd0ZlJqemoyVzNQRWZz
eXFuQ21wak1TTVU4WEg4alRyV2tYOFZyVEx1STFLbXdDYnRSMG02QjN1UXZXMHdGd0NaRUpI
ZGJUMWRqa2UxNVAwNUduVzlNdTRyV21YY1JyVk5nRTdPTExPREF3c0hMbHlzbVRKeWNsSmJI
dGp2ZGw3QmdLazZkejBZOTNUd0VBcGhDWmZ0bzNUMWRxK3FwVnE2WlBuOTdlM2o0NE9NaTJP
TjZYc1ZibkVrYWVwL01Dc1czWG1tTHlKWkhIV2RNdTRyV21YV3Z5OUo2ZW52ZmVlNitwcWVu
czJiT3FqK3lpNlI2UFIvWGZPaHp2eTZoM1dUcC9WQmhxT2dBZzBZbE1PWm1nSHp0MjdMdnZ2
dHU5ZS9mNTgrZVZuOXBGMDVPVGt4OTU1SkhSbzBkN1BKNGRPM1pRRi9neVZwQmE3c1ZJdEh3
WmwrZXNJdkJsUkx5STE0bngwaWg4R2Q5OTkxMHUxOTk4ODAxTFM0dnlVN3RvK29RSkUzdytI
L05sdlBycXE2a0xmQm1ScHdQZ2NpSlRUcFZXZi9ubGw4cTNZVFI5Mzc1OStmbjVTVWxKbE5J
RkN4YlUxZFZGMWdsTmxKbytmLzU4bjgvSGZCbXpzN09wQzN3WjlhU2NyNmNiYTdyYjFoOFJi
NVFsRWE4MTdWcmp5eGo1YjZUWFgzLzlybDI3bVBoKzlkVlhVNmRPamF3VEtrUmZ4cTZ1cnAv
ODVDZXBxYWw1ZVhsc1lkM3h2b3hoTG5xNThrSjFBSUR6aUV3L28vTGFUVTFORFlWQ1RIYlBu
VHVYbnA0ZVdTZXN3V0Y1dXJHbXV5MnZRYnhSbGtTODFyUnJkLy8wTys2NFkvUG16WVNRcnE2
dUJRc1d6Smt6SjdKT1dBUHlkQUJBQWhHWjBFV2w2VjFkWGZmZGQxOTZlbnA2ZXZxY09YTysv
ZmJieURwaERjalRveWxwODd3RzhVWlpFdkZhMDY1TDd5T05PWW5veTZqcHhhajViSWZlNGhu
UGVJN3RjOFMralBhOWp6VG1JRStQcHFUTjh4ckVHMlZKeEd0TnU1Ymw2WU9EZzZwRkdJYTJw
aE45b3VtRTJXQTlIUUNRUUVTc2RmMzkvVWVPSFBINWZPZlBuMjlxYWxKK2hEemRvbUppU2VU
cERPUngxclNMZUsxcDE0STh2Yk96czZXbHBhMnRyYXVycTZtcDZjaVJJOHBQN2VMTHlGaTVj
aVhmNkhoZlJ1VHBBTGljeVBUem80OCtVbm04S0lubjJvdXF0cmEydGttVEp2R05qdmRsUko3
T1FCNW5UYnVJMTVwMlhYM2RpMUxUdTd1N2k0dUw5KzdkeXpjNjNwY1JlVG9BTHNjTVhiV0xw
aTlkdXZURkYxOVViblM4THlNUkhCbkpsYjZNL0RtMjdjWXJYcjFuK1BZaFhoZkdTNlB3WlRS
R1Y5T1p0bHEyOXNMK3ZaR3lGY2Y3TWlKUEI4RGx4RkJPT1hiSjA4V044R1hFZXJxcDdTSmVh
OXBGdkVhRlRTRE8xNzJJdVQ5L0MxOUc1T2tBT0JzejFEV01wbS9mdnQzajhTZ1hSc3pvUkt4
QW5oNU5TWnZuTllnM3lwS0kxNXAyN1o2blQ1Z3dZZHUyYmYzOS9XYTBIWE9RcHdNQUVnZ3pa
RENNcG1kbVpnWUNBVE1hTmdQazZkR1V0SGxlZzNpakxJbDRyV25YN25uNnM4OCt1M0xseXU3
dWJqUGFqaUh3WmNRem52R2NXTThSK3pJYUUwYlRHeG9hUm8wYTVUQVBMNXQ4enlOUFp5Q1Bz
NlpkeEd0TnUzYlAwN096c3hzYUdyQ2ViZ1pZVHdmQTVaZ2hnMkUwZmR5NGNWaFBqMGt4c1NU
eWRBYnlPR3ZhUmJ6V3RHdjNQTjJrOVhSeEphZSt2cjZ3c0RBMU5iVzB0TFNscFlYQ2x4RjVP
Z0JPSjdhNnlnaWo2Wlo1QXp6d3dBUHQ3ZTNkM2QyYk5tMWk5LzNEbHhGNXVxbnRJbDVyMmtX
OFJvVk53SGJlQUNkT25QQjRQQlMrak1ySEJoTHZ6Z0lBWW84WnVocEcwNU9Ta3N4b2xTRnEr
cWxUcDhyTHkzZnUzRW5oeTZqY3ZvSEF4dzd4SWw0bnhVdXQ5MlZrVEpreTVlelpzN0Z0a3FQ
UzlOYldWby9IczJYTEZ2WVd2b3o4NGZWNjQ5MVpBRURzTVVOWHcyajZpeSsrK05CREQxMjhl
TkdNdHBXYVhsMWRuWjJkdlh2M2JyNEZ2b3o4VVV0cVk5aXVOY1hrUzJLOTFacDJFYTgxN2Rw
OVBkMmszMGpGT2xWYkxsNjhDRjlHWTAwSEFDUTZNWkZURmZIOGpUVG1PRFZQcjBDZWpuaWpM
b2w0clduWDdubDZZdUhVUEYxVDB3RUFpWTRaTWhoRzAvZnQyNWVmbjgrdWZsbXdZRUZkWFow
Wm5ZZ1Z5Tk9qNmFITjh4ckVHMlZKeEd0TnUzYlAwNisvL3ZwZHUzYXhKZSt2dnZwcTZ0U3Ba
blFpZWh6dXkvaCtjZHg3aTJjODR6bTJ6L0h4WlV4TlRRMkZRa3pUejUwN2w1NmVIdHZtWTR0
VDgvUWhyOFk5UjI3TGE2eU1WM21UbHh2aU5iVmR4R3RVMkFUQ2FQb2RkOXl4ZWZObVFraFhW
OWVDQlF2bXpKbGpSaWRpaFZQWDB3a3NYNndGTis0Q2F6QkRCc05vZWxkWDEzMzMzWmVlbnA2
ZW5qNW56cHh2di8zV2pFN0VDcWZtNlpxYTdyYThCbmw2bENWeGZLMXAxKzU1dWttSVY3dkx1
REM2MXBjUmVickZJRThIMW1DR3V0ckZ3MHZHaGRHMXZvekkwODFvRjNtNk5lMGlYcVBDSnFD
cjZSOSsrR0ZoWVdGS1NrcGhZZUZISDMxa1J0dEtUWmR4WVhTdkx5UHlkR3RCbmc2c3dReGQx
ZFgwb3FLaWwxOStPUkFJdlB6eXl5VWxKV2EwcmRSMEdSZEc5L295THRrREh6c3I0NTM3ZEk2
cjRuWGI4YlZEdk5SNlg4Yms1T1Nlbmg1S2FTZ1VVZ2xvckZCcXVvd0xvMnQ5R1pHbld3elpR
SkNxQXdzd1ExZDFOVjBwdUxIOTkwYWExY3E0TUxyV2x4SHI2V2EwYTd5ZXpqWGREZkdhMmk3
aU5TcHNBa2FhcmtsTVdoWHJsSEZoZEswdkkvSjBpMEdlRHF3aEpuS3F3bzBlWGpiNW5rZWV6
ckJoSG9jOFBZWWxFYTlSWVJOd282YmJCT1RwdGdWNU9yQUdNMlRRalpwdWsrOTU1T2tNRyta
eHlOTmpXQkx4R2hVMkFZZG91ck45R1l0WDdJaDdiMTMxVERhUTRnM3d3c1N6dWMveDhXVk1M
SkNuUjlORG0rYzF5Tk9qTEluamEwMjd5Tk5qQ2RiVFFVekFlanF3QmpOazBJMmFicFB2ZWVU
cERCdm1jY2pUWTFnUzhSb1ZOZ0c3YUhwRFEwTmVYbDV5Y25KdWJtNURRd09GTHlQeTlQaUJQ
QjFZZ3hsYWFoZE5IemR1bk4vdkQ0VkNQcDh2SXlPRHdwY1JlYnJKN1NKUHQ2WmR4R3RVMkFU
c291a2xKU1YrdjcrbnA4Zm44NVdWbFZINE1pSlBqeC9JMDRFMW1LR2xkdEgwQXdjT2pCczNq
aEF5YnR5NEF3Y09VUGd5d3BjeGZ2SE9mVHFIYkNEdWlkZHR4OWNPOFZMcmZSa3RadHEwYVh6
dDVmcnJyNmZ3WlVTZUhqK1Fwd05yTUVOTDdhTHBtWm1aZk8xbC9QanhGTDZNV0U4M3VWMnNw
MXZUTHVJMUttd0NkdEgwK3ZwNmo4ZVRuSnc4ZGVyVU45OThrOEtYRVhsNi9FQ2VEcXpCREMy
MWk2YkhCT1RwMGZUUTVua044dlFvUytMNFd0TXU4dlJZZ2p3ZHhBVGs2Y0FhekpCQk4ycTZU
Yjdua2FjemJKakhJVStQWVVuRWExVFlCQnlpNmZCbHhITU1uK0hMaUdjTG51SExHQjdrNmRI
MDBPWjVEZkwwS0V2aStGclRMdkwwV0lMMWRCQVRzSjRPekVDY1ZHYklvQnMxM1NiZjg4alRH
VGJNNDVDbng3QWs0dVc0UzlNSEJnWldybHc1ZWZMa3BLUWtRZ2lGTHlQeTlQaUJQQjJZZ2Jz
MGZkV3FWZE9uVDI5dmJ4OGNIR1JiNE10b2t6eGROUkhka01jaFQ0OWhTY1RMY1plbWV6d2Vu
OCtuM0FKZlJwdms2Y1BOV0IyUTVEb2dCR0JEM0tYcHljbkpqenp5eU9qUm96MGV6NDRkT3lo
OEdWWGJuODZKVmJ2RGpaYzdGRXJXUmpZUTF0dkU5ZTJETHlQaU5TTmUxVm5zY0YvR0NSTW0r
SHcrNXN0NDlkVlhVL2d5cWg1eFRCc0o4blFBWW9DNzh2VDU4K2Y3ZkQ3bXk1aWRuVTNoeTNq
bHcrdjF4cXJkNFJhckpiWERxNDBROWpXUXVPdXRXRStQWVVuRXkzR1hwbmQxZGYza0p6OUpU
VTNOeTh0akMrdndaVlErVk1KcUpjTnR1cGJVeHJHM01RRjVPakFEZDJsNlRIQndubDRocUtS
dDgzU3U2WW1ieHlGUGoyRkp4TXVCcGc4YkIrZnBvcVpiQnZKMEFHSUNOSDNZSUUrUHBvZGlN
VFlGa2FmSHRsMGJ4bXRxdTRpWEEwMGZCbzczWmF3Z3RYSG80WVppc29IVUZOY01hNithNHBy
YWVQUTJ0bEhEbHhIUE1YOG1HNGh5QzN3Wnc0TThQWm9laXNXOFhpL1pRTnlXcDdNa0hYbDZy
RW9pWGc3eTlHR1RRT3ZwWkFNWjN2WHA4YmlWdEpiVWRneXBOVjFtcjRSZVQxZHBPZ0N4QXBv
K2JCSW9UemZRZE0wOFhkUjBDL0lhcHM3R2VibzRUWkduRzJPM2VNMXVGL0Z5M0tqcEsxZXVa
S2FNMU9tK2pMV2tOaUh5OUxCSnQ0R21KeWpJMDRGSnVFN1QyOXJhSmsyYXhEWGQyYjZNQnBw
dWh6eWRpWnBNbmk3S04vSjBZK3dXcjludElsNk91elM5dTd1N3VMaDQ3OTY5WE5PZDZzdkk5
S0xDM25tNmdhYXJNTkQwQkNYaDh2UUU2cXJMY1plbUwxMjY5TVVYWDZTVWNrMTNxaS9qM0tk
enZGN3Y4cHhWWkZpK2pJdlhSOW51c09KbDNvcTFwTFlsWjFVdHFUV29UZlVwMjlLU3MwcStY
YnY1OXJIWUU4aVhjZG5UczZPSjEreHh0dHZ4aldPODd2SmxaUC9laUVPZDY4dm85WHByU2Ez
TjgzU3YxOHY2aVR6ZC9pVDBhTHNLZCtYcEhKNm5POVdYa1VtZWdhYmJZVDJkcS9tbHJpcm1J
dGJUbzJ3MzV2SFdsTlRFc0VMN3g0djFkR1BzcStsTzlXVzhKSGxlVzErZmJxRHBZa25OZlUz
dW9Ja2dUd2NtNFZKTmo0WkV5ZE9ORjE3TXk5T05wY280VDlmTFc1R25EN2RkNU9uV3RHdkRl
S0hwd3lZaDh2U0tpQmJUbzgvVHlRYkNWc25EWnFEOGlwZUt5dytEMU5VWmVib3lPaDVzb3FU
cXRZWi9TQUU3d0E0UU5IM1lKRVNlSGxiVFRjclR1VkxyL1M4NlhrelU5RnBTeTc4UFZKZXg2
Mm02cXFRQk1ubWNmRzFET2lNamFyUjRQYjd5TmQ5aS83eTFwcVNtWXlpOHB0c3dielcxWFZ2
RkMwMGZOZ25reTFoQmF1OHZyaUhTam93L1BrZm5GT2oxZXU4dnJxa2d0Y1kraThVYmlvY0lZ
U1haYy9IN3hiV2tscmt0cmxtelJsV25XTnVsdlRZVUQxMzJPSXpld1M1NmwwUlZUNVRPaTh4
N2tudEpjbDlHc2VjeDcxVk1ubXZESFZPN1BjZDMzT0xTT3BzNThHVWNOaEhrNlpMcnk1SzF5
WlNNT0U4WDAwek5KUUpWdnNsTEt2TnVnKzd4U3kxL1hIanBJTXFFWFZ4Mkg3cHlHUGx5RFd1
WC9TZFZnM0UyeUd1VURVV1RUMmtNRkNIdm55cTV0SVVRNVhxUlFaNnUvTWc0OFRjSXg0dzhY
V2F4Sys1NXEzSm1XdEN1d2U4bGVzV01sN0NRcDhlQkNOYlRJMWcybFN5dlZ5eXl4WFN5Wk04
UXVhS3JvcmlJaXFOOGhOVjB4aFhGT29oSzAxWFh3TlR5Mm9oYTA5bnlDMStIMFJ0blplY05R
bEJWb2hvSDQ2T2dYRTNTZkt1NkRGL1Y2SlhWYVdpNnpCUXlkYjNiZ2g4d1l0Si9BMDAzZFh6
azJ6S3ZHOUQwQ05IVWRIRTBXZjdJUDlYTHZQajZzbkd4a2cwbHh2bXlxdDJ3MnEyWHB5c2xp
V3dnSlJ0S2hnaGhPZVlWSFJOMHAyUkRTZTJWMHF3WEw5bEFWQms2ZXlnMzhuaUgrRFU4Vjhv
ZjEzVFc3cVdQaU1ib3NkZHpWdWFveDVhb0EyRzFzWGcxS3hISFdYblV2RjZ2TW5EV0s3WU1y
ZFIwMVY2c3ZQTDRLb2ZhNi9XcWdsS09qQXJsZWpkdGF4T25pbDRVTXZKblFaNnV1VjR2bjdl
U3kzOFA4ZHBVVVhpOVh0WGZuUWJ5S2grSWFnQTFhMVlXTTlaMHBXNm9VUGJjNFBpS0I5b01H
YlNMcHRmWDF4Y1dGcWFtcHBhV2xyYTB0TkJJZlJuRjRZdnlJVXFrWmhtWllwZHE2eGoybGVs
c2w0ckwwc004elZXL1lmS1BLa2h0eHhEaFpYaDVQVTFYUHJqMkdXaTZNdDRLaGFiL3VNYmlK
VVBlSDF1dlVDcW1ZcFZEYkoxMW00VXdSSWd5TGpGZXljT25HaXZXZ1FxZEI2dVdLUTZMam0z
aHZ3K0xxVDN2dG5FM1ZCM21vc2FIWFhYQ0t3ZUVYUGxOb3lwRHJ2eWJRMDlFTkN2Uks4RGpW
ZlZmVDh2MFpPdUthYThZQkRHckVBK29ja2hWYWl0NTZEVzZKSGVTUnY5UU5hUTNYUjJ1NlE4
ODhFQjdlM3QzZC9lbVRadllmZitSK1RMV0NpYzhreHYrMXV2MXZuK3FoRjMrd1EvQWoxcERM
dVZmUTRTdzlFZXBJRnhyT29aK1ROUFdyRm5ERllIdHlCNnNHS3VRRlQ1VlV2S2pVQTRyVDcr
czZjckgvU1UxZXRxa1daSzFPK1FsUXgySzFRWkZSc3k2cDFMelMzc3BaTDNtY3J0TWZKWEtl
Mm1RTDM4TjhKTDhVNjZuYkVEWU04M0pNZEJadlhpVjN5dEs1V1VMNVdIbFcyOEEyWUhqaDd1
QzFKNHFLUkcvbnpRZmJGNnBqcnR5YnJBdGMxYm1LS2NmRDRIdnlEYnl3OEcvRGxsMHJCaWZ0
ME9Fc0VDVSs3SmlGZnhmbWhEaTlYcjVuMDJzSkN2RGVzZ0ZsSTFlN1pXVG1idEVxQ1JKL0R0
TWVSN3hIaDV2eXhFSHR2YnlhUE12Uzk1dTdlVmpwL3dlVlo3Q2E5YXNxVlZNQUhXWmNPa0FB
Q0FBU1VSQlZQWnA3ZVdycy9nNHN3RmtKVlc1Z25KZmZueDVaN2d4QmcrZm43K3FBVlRHeTdm
VG5CemVCRzlYVkhiMlY0c1pXbW9YVGVlY09ISEM0L0hRU0gwWkpXVXVqbyt3bXE2ZHAxK1pM
RWZlcmtSVlExY0t1dkdPeWkrYlMyZDRMSG9iNTJPazBIUTg4SWorb1Z5bDVCdGRvZW1uVHAw
cUx5L2Z1WE1uamRTWGNYbk9xZ3BTYS96OC9Pdy9oUzJ6UEdmVi9TVTFNYXlObDV6N1JnN3BJ
SFBmeUNIeXZvd2RaTzRiT1RGcnQ0TVl4RHQwdVl6ZXM2cGRzVGJlVzhrZVZ1VThaOFk0UjNO
ODV6NmQwekZFVEdyWGh2R2EyaTdpVmM0cjVSYUgrekpTU2x0Yld6MGV6NVl0VzlqYnlId1pL
K0w5aFJ6MjhXUGFPOHc4ZmNnYlZlWW9tYWZyWmVoNisycHVTZlE4WFdZdENBODhodnZnYTJL
WDNqbzdUNit1cnM3T3p0NjllemZmRXBrdm84eklTcTVFeDdaWXhaWHIyZ2FhcnIyZUxnamwv
U1UxdklCeXUrYksrMUM0SlJTTjd1azhsUEhxcVR6YnlOb04rMVZVbGZPY0dlT3NQcDJ1L0ZW
QXBrSTJrbEcyYTAyOFF4SmZvaWJONXdqaTFleHR6TnUxVDd4NkQ0ZHJPcm1TaXhjdlJ1akxL
Snk2b3NacGJtUlhhNGdibFNVdlhhOHQ3Q3NLcTBHN1YwaWs4cTFPZW03R1kranlReU5laVR5
ZHg2dlVkRDU2eWxaNEFkNlc1bGlwZXNMZWlvZmowblg2M3ZESFYyUGZLNzkrcmhqenl5OVUx
K09UeXo5Tjg3bWhtZ3lhRTBhMVVXOWVpZkhxelVuMTRJUUx6YmhkWlcyNjdXck9EUzBoRmt2
cXpTdmx3TEszZXFNbkRxRE04ZFdOMXlzUnI4UXgwanZvbXZ1cW1oaTY4aFQ0Y2J1ek5UMG1Q
UFhVVXpLS1Z2SitpZlhGNUV2T2VYQ2pXdTR0YVRmNllrd3lkRXZxUkhRcFhzdkgyYUNZVWl0
amYzenJjb3dIaEcyL29qYit4Uk5OdkN0MkdCVzQvUFdtMGE2cURDOTV1Y0pMcVlEZThlWHhH
alN0R1lWbTY4cEFZaklzY3JNMGt1TXJWRnVoTk5udWNNMTFMOUVncWVsNDRHSDhxSkJZZzhJ
RGorRStWUE1LbWg0ZWgrVHBZZk1hYzlwRnZJZ1g4Vm9XTDRHbUc4TjlHVWtIS1g2L0dNOTR4
ak9lYmY0TVg4YndJRTlIdklnWDhTWkV2QVI1dWd4WVQ4Y0REendTNVFGTkR3L3lkTVNMZUJG
dlFzUkxvT2xVMHBkUmJqVHh3QU1QUE9MNzRKcGUvK0NEMzMvMVZheDBNcEUwWGNhWFVXWW9u
ZkU5NzdhOEJ2RWlYaWZGU3hTYTd2VjQxa3lmL3NGTEwvVjFkMGV2azRtazZUSytqSktqaVFj
ZWVPQVIzNGRTMDlsancvLzVQMzk3NTUwb2RUS1JORjNUbC9IbzBhTlBQUEhFaW1YTEhydnZ2
djk3NjYyUEwxejR4Qk5QR0QvLzd2Nzd3NVo1Zk9IQzMvem1OekdzVGI1azFTOStFWmQyRVMv
aVJieVd4ZnY0d29WTXRaYi85cmMvYXZxdHQvNXR6NTRvZFRLUk5GM0dsMUdtbmkrLy9OTDZZ
dklsdTk5L1B5N3RJbDVyMmtXODFyUnI4M2lWc0xXWDkvLzhaOWV0dmNqNE1zclUwOVBUWTMw
eCtaSVhObTJLUzd1STE1cDJFYTgxN2RvOFhpWDFpeGQvMzlrNTNMMzBTQ1JObC9GbHRMNVhN
YWYvN05sNGQ4RlNFSyt6UWJ3V2swaWFIcGIyV1AvSEVBQUFTQ3djcGVtSkFpRWszbDBBNW9K
RDdHenNmSHloNlNiQy9yL0hxRkdqcGsrZi90eHp6L1gzOXhzVVU4NlMrdnI2d3NMQzFOVFUw
dExTbHBZV1pXSHh4cXV3dDJJQmt5Q0UvTmQvL1JkLyt4Ly84Ujk2cC9xd2pob09zVTJRUDc2
Mk9vV2g2U2JDam5GdmIrL0hIMzk4NDQwMy90dS8vVnZZd293SEhuaWd2YjI5dTd0NzA2Wk5x
aXQ4eEJ1dnd0NktCVXlDRURKNzl1ekJ3VUZLYVc5dmIybHBxZDQ1UDZ5amhrTnNFK1NQTHkv
UFg4ZnhGSWFtbTRqeUdIZDBkRng3N2JYaWRzM0NuQk1uVG5nOEh1V240bzFYWVcvRkFpWkJD
UG5qSC8rNFk4Y09TdW5telp1ZmVPSUpmcGhVUjFQbXFPRVEydzM1NDJ1dzBmcFRHSnB1SXNw
ajNOdmJtNUtTSW03WExNdzRkZXBVZVhuNXpwMDdsUnZGRzY4MGI4VUNGa0FJT1g3OGVFVkZ4
ZURnWUdscDZjbVRKL1hPK1dFZE5SeGlteUIvZlBVMnh1VVVocWFiaVBJWUh6MTZOQ2NuUjl5
dVdaaFMydHJhNnZGNHRtelpvaW9tM25nVjlsWXNZQkxza04xMzMzMi8vLzN2Zi9HTFgxREZR
VlFkeldFZE5SeGlteUIvZkRVM3h1c1VocWFiQ0Y5UFAzVG8wT3pacy9sNmV0Z0pVVjFkbloy
ZHZYdjNickdZZU9OVjJGdXhnRW13US9iKysrOFRRdmJ0MjBmMXovbGhIVFVjWXBzZ2YzekZq
WEU4aGFIcEpzSitDaDg1Y2lTNzdxV3ZyNDl2RjRzcGZ6cFhiYmw0OFNMZlJienhLdXl0V01B
a3hCTmI3NXlYT1dvNHhIWkQvdmphNmhTR3BnTUFnSE9BcGdNQWdIT0FwZ01BZ0hPQXBnTUFn
SE9BcGdNQWdIT0FwZ01BZ0hPQXBnTUFnSE9BcGdPM1kyek1CRUJpQVUxUFlIcDZlcFl0VzNi
MTFWZVBIVHYyK2VlZmozZDM3QTRoNUlVWFhxQ0dwcW1BMDk3ZVRnakIvNW1Sd1ZaVEM1cWV3
Q3hmdnZ5KysrNzc1cHR2dnYvKyswY2ZmVFRlM2JFN2hKQ0Nnb0xCd2NIcDA2ZkgvY1N6UDJ2
V3JCa3hZc1NhTld2aTNaRUV3RlpUQzVxZXdFeVpNa1gxdjh5VjgwbDVIL1B5NWN2VDA5UEx5
c3JFWXU2QkVITExMYmVzV3JYcTFsdHZWUTZPYXRCZWZ2bmw4ZVBIWjJabWJycjh6NExkT1Z4
MzNISEhndzgrZU1jZGQ3QzNaV1ZsN0g4N05EYzN6NXc1azFMYTF0WldVRkNRbHBhMllzVUtZ
eU1VeHlOT0xUYXZVbEpTK1AvRStQM3ZmLy9yWC8rYVV2cXJYLzFxeVpJbGZNZVlkd2FhbnNB
a0p5ZXIvbmVTbnFhLzhNSUxnVURnb1ljZXNyUi9Ob01ROHNZYmI0d1lNV0xyMXEyYUE4VmVy
MSsvUGhnTU5qVTF1ZGtCTVJBSWpCa3o1cHR2dmhrelprd2dFS0NVcmwyN2x2OERoM1hyMWxG
S1MwcEtObTdjR0FnRU5tM2E1RTRwNStoTnJmNysvbjM3OWsyYU5JbFMydGZYZCtlZGQvN2hE
Mys0ODg0N3VmV1RHVURURXhpRFBMMnZyMCtwNmIyOXZWWjN6bjRZNkxqeXRaN1ZtcXRvYkd6
ay9sT05qWTJVMG5QbnptVmtaSHo1NVpjWkdSbmZmZmNkcFRRbEpTVVlERkpLZzhHZ204ZUth
azJuOWV2WGV6eWVFU05HRUVLU2twTFlSMjF0YllTUXRyWTJVenNEVFU5Z3FxcXE3cnZ2dmxP
blRwMC9mNzZxcW9wU09tSENoTjI3ZDNkM2QyL1lzTUhsZnc2TFNHcTY1bXUzc1dUSkV2YXIr
L1BQUDg4WENpb3JLMis0NFlaNTgrYXh0OFhGeFgvOTYxK0R3ZUIvL3VkL3VubXNxTmEwU1V0
TGEycHFDZ2FEUHArUGJRa0dnNldscFhmZmZYZHBhV2wzZDdkNW5ZR21KekNoVU9qaGh4K2VN
R0VDdis2bHVybzZJeU5qL1BqeDY5YXRNOUIwZDU2QjRvbW5hWkVxbG5maGNPWGw1UjArZkpo
U2V2anc0Ynk4UExheHVibVpFTkxjM016ZXRyYTI1dWZucDZXbFBmNzQ0eU5HakdBYlhUaFdW
R3ZhUFB2c3N4a1pHUmtaR2F0WHIyWmJGaTFhdEdEQkFrcnBQLy96UHk5ZXZGamNNVlpBMHdF
QWtUTXdNUERXVzI5Tm56NDkzaDBCbDRDbUF3QWloQzBXNStYbC9mZC8vM2U4K3dJdUFVMEhB
QURuQUUwSEFBRG5rQmlhN3M0ZlhnQUFZTGdNVDlPSkRwb2xrNUtTcnJubW1qLzg0US9zSWxZ
cjZlenN2T21tbTBhT0hIblRUVGQ5OWRWWEZyZHVHZUw0TnpRMHpKZ3hZK1RJa2VYbDVlKzk5
eDdia3BlWGw1eWNuSmVYdDMzN2RzMTZHaG9hUEI1UGFtcnFqVGZlZVB6NGNVcnBsaTFicnJ2
dXV0VFUxSmt6Wis3ZHU5ZWFjTXhHSEM1eFN5Z1VldVNSUjdLenMvVW1OdFVhWk9OeklSSFJD
OGZyOWZLTjRyU1JxVWM1VmxsWldTYjEzMkxFS1NGS2tJd29pZWVkeklSVU1YeE43eEFlT3Bv
K09EaDQ4dVRKK2ZQbi8vR1BmNVRwU2d5Wk8zZnVpaFVydXJ1N1Y2eFlVVmxaYVhIckZxTWMv
OHJLeW82T2psQW90SDM3OW9rVEoxSktNekl5ZHUzYUZRcUYvSDUvUmthR1pnMVpXVmt0TFMw
OVBUMCtuKy9uUC84NXBYVHUzTG1IRHgvdTd1N2VzbVdMdzI2bk5MNnlzNnFxcXF5c3JLT2pZ
M0J3VUs4R2NaQWRJK1VxVkhGOThza25URnpZVzNIYVNOYkRXTEpreVpOUFBobkQzc1lSY1Vx
SUVpUWpTdUo1SnpNaFZaaW82ZXpGeVpNbjJhMnhIMzc0WVdGaFlVcEtTbUZoNFljZmZzaksv
T00vL3VPOGVmTnljM1BaalF6c3UwaHBrc0EzS21zV0hUbFVaR1ZsblQ1OW1sSjYrdlJwaDBt
U2lEait3V0N3dnI2ZVhWNVdXbHJhM056YzA5T3plL2R1WnRNaGtwV1Z0V2ZQSG5aeWpoOC9Y
dm5SeVpNblUxTlRuWFFicXJHbVQ1NDgrZDEzMzVXcFJ6bkloSkNNakl6MDlQU2YvdlNuSjA2
Y2lHRnY0NHZxTDVpaW9xTFhYbnROcWVsNjA4YWdIc2IzMzMrZm1abloxZFVWOHo3SEVlV1VF
Q1ZvV0tMRXp6djVDY2t4WGRQNysvdFRVbElvcFFVRkJhKysrbW93R0t5dXJpNHNMR1JsdUov
bm1ERmorTDVLa3dSVmJWVE9rV1BFaUJFREF3TzMzSEpMZjM5L2NuS3l6RUFrTHFyeDUzL1ZI
ang0a0ZMYTJ0cWFtWmxKQ01uTXpOUzdLYm11cnU3YWE2OGRQWHIwNDQ4L3JoeXViNy85dHFL
aXdtR09qOGFhbnB5Y3ZHTEZpdlQwOUp5Y25HM2J0aGxVb2h4a3h0bXpaNnVxcW02NjZhYVk5
emxlS0VmbXNjY2UrOFV2ZnFIY3FEZHRqT3RockY2OW10MkE0eGhVVTBLVUlIbFJVcDUza2hO
U2lYVjVlbkp5TWx0WUR3UUNUT1dKNHM0OW9tK1NRQVZORCt2SWtaV1ZkZWJNR2VyV1BEMFFD
R3pkdXJXb3FJaFNtcCtmNy9mN1E2R1F6K2NyS0Nnd3JtcnYzcjFUcGt4aHJ3OGVQSmlibTd0
aXhZcUJnUUV6dWgwdmpEVTlNelBUNS9QMTlQUzB0TFFZci9ZcUI1blQzZDJkbXBvYXc5N0dG
K1hJc0xOU2M1MWRPVzNDMWtNcDdldnJ5OG5KTWR2MnhIcVVVMEtVSUVsUlVwMTM4aE9TWSs1
Nit0ZGZmLzNMWC82UytVVm81dW1xWjlFa2dkY1c5cldTKysrLy84a25ud3lGUWs4KytTUkxM
aHlNY2hBV0xWclUyZGtaQ29YcTYrdlpuOFBqeG8zeisvMDlQVDI3ZHUzU1cwK25sQTRPRGg0
OWVyU2twSVQ1eHRUVTFGUlVWTEFsTW9kaHJPbjMzbnN2UDRYMFRqeHhrQmsvL1BERHFsV3JL
aW9xWXQvcE9HR2NybEZoMmtqV1UxZFhOM3YyN0ZoMTBnNklVMEtVSUJsUkVzODdtUW1wd2tS
TlQwcEttamh4NHU5Kzl6dm0xYmx2Mzc2Q2dvTGs1T1NDZ2dLK25xNTZGazBTeUpWUU9VMC9j
ZUxFckZtejJDL3luWjJkTWdPUmlJaURVMXRibTV1Ym01S1NVbFJVNVBmN0thVjFkWFhzVDUr
cFU2ZlcxOWZ6SGNWNnNyT3pseTVkR2dxRnhKb3ZYcnhvZVhDeFIzTXVxYlljUDM1ODFxeFpL
U2twSG8rbm9hR0I3NmlzUnh4a3R2dW9VYU51di8zMnp6Ly8zUExJWW84NE1zcVBsR1dVMDRi
cVRDMVZQYk5telpKY1JrZ1V4Q2toU3BDbUtCa1AxOFdMRnpVbnBERm1YY3NJQUFEQWVoTGpu
aU1EOEFVREFBQ2NoTmQwQUFBQUhHZzZBQUE0QitzMFhXWlZCQ3NuQUFBUURkYjlSaHBEVFlm
MHl5QnpkUFE4S0pTMkhtNUF4b3RETENQanBaUFFpR1lqTWtaQVlobUgvZFlsaGlQT0JMMkJN
ajZ6WXVLOE5IeE5YN0pIL1lDbTJ4ampzZEwwb0ZEWmVyZ0JTUzhPVlJrWkw1MkVSalFia1RF
QzBpdmpzQm1sREVlY0NacURFUGJNaW9uemtsbWFmdWpRb1prelp5WW5KeFBGMWF3cW41YWpS
NC9lZlBQTnFhbXAwNlpONC81MmxOS3paOC9lZHR0dG16ZHZwam91TWFydlNiR2VXYk5tc2Yr
YTZMeTdHNGFMOFlra2VsQ0l0aDV1UU1hTFF5d2o0NldUMEJpWWpjZ1lBYW5LT0d4R0tjTXht
QWw4RUdUT3JKZzRMNW1sNlNVbEpldldyZU4zSWxBdG41Ynk4dkxYWDM4OUZBcnQyclZyMnJS
cHJFeEhSMGRaV1JrMzhCTHZQcVhDNUJEcjJicDFLek1GS3k4djM3bHpaOWk0SEl6eGlTUjZV
SWkySG01QXhvdERMQ1BqcFpQUTZKbU55QmdCaVdVY05xT1U0ZWpOQk9VZ3lKeFpNWEZlTWt2
VFUxSlMyTzJqeW4xVlBpMHBLU2s4NDJidUxvU1EwdExTN096czl2WjJWbEowaWFIQ29JajE5
UFgxWFhmZGRkdTJiU3NvS0pEM3FIUWtZZk4wbFFlRmdhMkhnNUh4NGhETERNdExKeEhSTkJ1
Uk1RTFNMT093NmFRTVIzTW1xQVpoV0dkV05NNUxabWw2Y1hIeHVuWHJlbnA2bFB1cVhsZFVW
RFEyTm5aM2R5dTNuemx6WnNlT0hibTV1ZXp2WE0wOGZlVElrVXBIVTdFZVN1bnp6eitmbnA2
dVo4YnJIb3huajRFSGhjUE9RR05rdkRqRU1wSmVPb21MYURZaVl3U2tWOFpoTTBvWmpqZ1RE
QWJLZUJ5aWQxNHlTOU0vL3ZqajB0SlM5dFVrUnNKZUh6dDI3UGJiYjA5TFMrTmZYTHhNVFUz
TnJGbXpnc0dnNkJKREtWMjJiQm5iaTcwVjY2R1UvdjN2ZjgvS3lyTCtYeXpaQjNJbGZLT3lq
SUV4anNQT1FHTmt2RGpFTXBwZU9rNUNOQnRSVFNwbUJLUWFLTEdNNWxSTVhNUnd4Sm1nT1ZC
OGQ4M1hmSzhvblplYzZmY3lNRER3bDcvOFpkbXlaZkh1Q0FBQVdJb3o3eU1saEpTVmxiSFZH
d0FBY0EvTzFIUUFBSEFuMEhRQUFIQU84SHNCQUFEbmtKQitMMEFlR2I4STBjbEV4di9Fa2No
TWFRd1hRMmFzUkFNVGNZdXJDT3Yzb3ZLTmlXQzRocTNwUTE3MUE1cHVaeVFOT2xST0pqTCtK
dzdHZUI1aXVKUVlqNVZvWUNKdWNROWgvVjVFMzVnSWhzc3NUVGZQNzRVN0J6UTNOenZTWk1N
a0RQd2lSQ2NUR2Y4VEJ4TldwekJjbkxCanBUSXdNYkEwY1RZeWZpK2liMHdFdzJXV3Bwdm45
N0oyN2RyNTgrZFRTdWZObTdkdTNUcVpJSUd4WDRUb1pDTGpmK0pnakhVS3c2WEVlS3hFQXhN
OVN4UEhJK1AzSXZyR1JEQmNabW02ZVg0djU4NmR5OGpJK1BMTEx6TXlNcjc3N2p1WklGMU9X
TDhJMGNsRXh2L0V3WVROUFRGY0hNbjFVcVdCaWQ0V1p5UGo5MkxnSUNRL1hHWnB1cWwrTDVX
VmxUZmNjQU56WGdUR3lQaEZpRTRtTXY0bkRzWllwekJjU3NKcXVzckFSSE9McXpBWU1VMEhv
ZUVPbDFtYWJxcmZTM056TXlHRU9hUURZMVJYS0drYWRJaE9KZ1krTU01Rzg0SXVESmNtTW1Q
RlBoSU5USlJiM0lhb2hCdzkzNWhoRFpjei9WNEFBTUNkNEQ1U0FBQndEdEIwQUFCd0R0QjBB
QUJ3RG1acE9oYlpBUURBZXN6NmpSU2FiaFBnOXpJc1pINzJ4M0F4WktaV1EwUERqQmt6Um80
Y1dWNWV6dTRWRDRWQ2p6enlDTHRGM3NFcUlVNGtwV0R5Zis2cWlkSVRKb0twTmZ4ckdUdlVE
Mmk2bllIZlN3UVl6MTRNRjBObWFsVldWblowZElSQ29lM2J0MCtjT0pGU1dsVlZWVlpXMXRI
UjRZWi8vcTQ1a1pZc1dmTGtrMC9xN2FMeWhJbGdhcG1yNlVybkZ0SGRaZTNhdFI2UGgzbkM0
RHZBYk9EM0lvL3hiTVJ3cVRDWVdveGdNRmhmWHo5OStuUks2ZVRKazk5OTkxMExleGRQeElu
MC9mZmZaMlptZG5WMWFaWVhQV0VpbUZvbWFyckt1VVYwZHhrelpvelg2KzNvNkZEZWJnck1B
SDR2dzhKWTB6RmNTb3luRnIyODVwQ1ZsWFh3NEVGS2FYSnk4b29WSzlMVDAzTnljclp0MjJa
aFQrT0FPSkZXcjE2OVlNRUN2ZktpSjB3RVU4dEVUVmM1dDRqdUxtKy8vZlk5OTl3emJkcTBz
V1BIUHZQTU16TGRCUkVBdjVmaEVqWlB4M0F4d2s0dFJpQVEyTHAxYTFGUkVhVTBNelBUNS9Q
MTlQUzB0TFFZTHlzN0FOVkU2dXZyeThuSlllWmNtb2llTUJGTUxSTTFYZVhjSXJxN01BWUdC
dmJ1M1p1ZW5pN1RYVEJjNFBjU0FjYWFqdUZpeUV5dFJZc1dkWFoyaGtLaCt2cDZaaFY3Nzcz
M2NrMTMvUGNmRVc3OW56MTc5ckIyakdCcW1mNGJLWGR1MFhSM0lZUXdjNE9OR3pmS2RCY01G
OVVWU3ZCN01VWTFYSHlqc2d5R2l5RXp0V3ByYTNOemMxTlNVb3FLaXZ4K1A2WDArUEhqczJi
TlNrbEo4WGc4RFEwTjhlbTYrV2hPcEZtelpxbVdtL1N5Qjc0OWdxa0Z2eGNBQUhBT3VJOFVB
QUNjQXpRZEFBQ2NBelFkQUFDY2c5V2FybHg4eDBJOEFBREVsbmorUmdwTmp6bWltVVpEUTBO
ZVhsNXljbkplWHQ3MjdkczE5MnBvYVBCNFBPeTM5ZVBIajJ2VzR4SmtQRXpFd1hHRDM0c1l0
VklCOUs0MEY2ZWZ6SVIwQU9JNUpUTkpZbUlsTkd4TnJ5QzFxZ2MwM1Q2SVpob1pHUm03ZHUw
S2hVSit2NS8vaDBNVldWbFpMUzB0UFQwOVBwL3Y1ei8vdVdZOUxrSEd3MFFjSERmNHZSaE1D
UU1ERTNINnlVeElCeUNlVXpLVEpDWldRaVpxT2lGaytmTGw2ZW5wWldWbGZJdTQ5bUxzQ2FO
WkQ5QkROTk1vTFMxdGJtN3U2ZW5adlh2M3pKa3pOZmZLeXNyYXMyY1BtMy9zeGhCWG1YSm9Z
dUJoSWc2T0cveGU5S2FFc1lHSk9QMWtKcVFERU04cG1Va1NFeXNoY3pYOWhSZGVDQVFDRHoz
MGtIS2o4blZZVHhpOWVvQW1vcGxHYTJ0clptWW1JU1F6TTFQdnB1UzZ1cnBycjcxMjlPalJq
ei8rT1BPVWNKVXBoNGl4aDRrNE9HN3dlOUdiRXNZR0p1TDBrNW1RRGtBOHAyUW1TVXlzaE16
VmRESE5VV2w2V0U4WXZYcUFKcUtaUm41K3Z0L3ZENFZDUHArdm9LREFlUGU5ZS9kT21USkZz
eDczRU5iRFJCd2NOL2k5YUU2SnNBWW00dlFiMW9SMEFQeWNrcGtrTWJFU01sZlRqVGNTT1U4
WUxMdkxJNXBwakJzM3p1LzM5L1QwN05xMXkyRDVjbkJ3OE9qUm95VWxKVlZWVlpyMXVBUVpE
eE54Y056Zzk2STVKY0lhbUlqVFQzSkNPZ0RWT1NVelNXSmlKV1NkcG91WHl2QUNCcDR3WWoz
QUFORk1vNjZ1enVQeE1GT2QrdnA2Vmt6ejBHUm5aeTlkdWpRVUNtblc0eEpVczFUVHcwUWNI
RGY0dldoT2liQUdKdUwwMDV5UXprTThwelFuaVdxNFltSWxCTDhYQUFCd0RyaVBGQUFBbkFN
MEhRQUFuQU0wSFFBQW5JTjFtajZzeTJQNFI4YnI5VmpLQndBQUpkYjlSaHF4L2tMVG8wSEd1
UVYrTHh5WldhMW53ZUgxZWgwOFZ1S3dORFEwekpneFkrVElrZVhsNWZ5dWJ4WGlXRG5TNzBX
MENSSW5rdVNacUJxY0NLNURHYmFtMTVKYTFRT2FibWRrbkZ2Zzk4S1JtVkdhRmh5ZmZQSUpP
MTNON1YrOFVRWllXVm5aMGRFUkNvVzJiOTgrY2VKRXpmTGlXRG5TNzBXMENSSm5nc3c1cFRj
NHR0RDB0V3ZYZWp5ZTVPUmsvaVZEQ0huNTVaZkhqeCtmbVptNWFkTW1YcUZ5ZHoyL0YyWE5y
YTJ0QlFVRmFXbHBWVlZWN0NPeExjQ1JjVzZCM3d1SEVKS1JrWkdlbnY3VG4vNzB4SWtUbW1W
RUM0NVFLRlJVVlBUYWE2ODVmdnFKQVFhRHdmcjYrdW5UcDJ1V0Y4ZksyWDR2M0NaSW5FZ3k1
NVRlNE5oQzA4ZU1HZVAxZWpzNk9ucDZldmkrNjlldkR3YURUVTFOeWxzVGxidnIrYjBvYTU0
eFkwWk5UVTB3R0h6bGxWZllSMkpiZ0NQajNBSy9GeFZuejU2dHFxcTY2YWFiTkQ4VkxUZ2Vl
K3d4ZG8rZjJ6U2RaVkZaV1ZrSER4N1VMQytPbFlQOVhrU2JJT1ZFa2ptbjlBYkhGcHIrOXR0
djMzUFBQZE9tVFJzN2R1d3p6enpEOXUzcjZ4TzdxSHl0NS9laXJEa2xKU1VZREZKS0E0RUEr
MGhzQzNDRzVkd0N2eGRPZDNkM2FtcXE1a2VpQmNlSUVTT0crL05TZ2lKR0Z3Z0V0bTdkV2xS
VXBGbGVIQ3VuK3IzbzJRVHhpU1J6VHVrTmppMDBuVEV3TUxCMzc5NzA5SFNxcitQSzE1cCtM
NU1tVFZKbUFVVkZSU3hQcjY2dVZ1NnJiQXR3SkoxYjRQZWk1SWNmZmxpMWFsVkZSWVhtcHdZ
V0hNNFdkSHBsZ0lzV0xlcnM3QXlGUXZYMTlXekpUa1FjSzBmNnZlalpCQ2tua3N3NXBUYzR0
dEIwbHJBd1Y0ZU5HemRTTFIwblYwSXAxZlI3K2V0Zi81cWVuczdmN3QrL1B6OC9QeTB0YmZu
eTVjcDZsRzBCanFaTmgrWmYwUEI3b1plSFl0U29VYmZmZnZ2bm4zL09OeXJMR0Zod09GalR4
Yk8xdHJZMk56YzNKU1dscUtqSTcvZnpZc3E5eExGeXBOK0xhbkF1WHJ3b1RpU1pNMUVjSEhI
WXd3Sy9Gd0FBY0E2NGp4UUFBSndETkIwQUFKd0ROQjBBQUp5RDNUVWRpL1VBQUNDUDNYOGpo
YVpIaWVoRUlTS2FjdWhabWpnZW1TbU40V0xJakpWb0plUkl2eGQ1akUyQnhNRVJCekFzdzli
MGppSDFBNXB1WjBRbkNzMHlLbE1PVFVzVDkyQTg2ekJjU296SFNyUVNjcVRmaXlSaFRZSEV3
UkVITUN4bWFicW0zMHRWVlZWYVd0cjA2ZE5iVzFzcHBSOSsrR0ZoWVdGS1NrcGhZU0c3WFAv
UW9VTXpaODVrZS9FV0thVm56NTY5N2JiYk5tL2VMQk1TMElRN1VZZ2ZpYVljNGhaWEVWYW5N
Rnljc0dPbHNoSnl0dCtMQVRLbVFPTGdpQU1ZRnJNMFhkUHZwYnE2T2hnTTF0VFVGQmNYVTBv
TENncGVmZlZWZGtkb1lXRWhwYlNrcEdUZHVuWHN0cGNmVyt6b0tDc3JhMmxwa1lrSGFDSTZV
U2dSVFRuRUxhN0NXS2N3WEVxTXgwcTBFbkt3MzRzeE1xWkE0dUNJQXhnV3N6UmQwKytGK2JR
RWcwRm1nSkNjbk15ZFcxSlNVaWlsS1NrcGdVQkExV0pwYVdsMmRuWjdlN3RNUEVCRXo0bUNJ
NXB5aUZ0Y1JkamNFOFBGa1Z3ZDVWWkNUdlY3Q1l1TUtaREI0UEFCREl1NTYra3F2eGVXbGRm
VTFNeVlNWU5xNWVuRnhjWHIxcTFUMmlzU1FzNmNPYk5qeDQ3YzNGejI1eTBZRm5wT0ZFcEVV
dzREU3hNM1lLeFRHQzRsWVRWZFpTWGtTTCtYWVdFd1lwcURveHJBc0ppbDZleTdTT1gzd3Ri
VDgvUHo5Ky9mVHluZHQyOWZRVUZCY25KeVFVRUJFNTJQUC82NHRMU1VmYUdwNHErcHFaazFh
eGJMNjRFOHFpdVVMbDY4U0NWTU9Rd3NUWnlONWdWZEdDNU5aTWFLZmFTMEVuS2szOHV3VUE2
UmFyajAvRjZVQXhpV0JQamZkUUFBQUNTSi8vK1lCZ0FBRUN2c2ZoOHBBQUFBZWFEcEFBRGdI
T3lvNlZpbEFRQ0F5RER4TjFKSXN4MW9hR2lZTVdQR3lKRWp5OHZMMzN2dlBjMHlNRERod0I1
SEhwbXgwck1yTWJZOWNUQmgvVjVVd3lVenlDcUdyZWxEd2dPYWJtY3FLeXM3T2pwQ29kRDI3
ZHNuVHB5b1dRWUdKaHpZNDhnak0xYWFkaVZoYlUrY1N0akF4ZUdTR1dRVlptbTZaaFpQQ0Zt
K2ZIbDZlbnBaV1JuVjhudmhPOHAwSGNnVERBYnI2K3VuVDUrdStTa01URVJnanlPUDhWaXA3
RXBrYkU4Y2lVemdCdTR1Qm9Pc3d0SThuUkR5d2dzdkJBS0JoeDU2aUdyZFI2cTNJNGdHOWpX
WmxaVjE4T0JCelFJd01GRUJleHg1ak1kS3RDdVJzVDF4SkRLQjY3bTdHQSt5Q3FzMVhmazlJ
L3E5Nk8wSW9pUVFDR3pkdXJXb3FFanpVeGlZS0lFOWpqeGh4NHJEN1Vwa2JFOGN5YkFDVjdx
N3lBOHl3MFJOSHpseTVJa1RKMVM3Szk4aVQ3ZUFSWXNXZFhaMmhrS2grdnA2UGE5T0dKaHdZ
SThqajh4WVVYMjdFdGVlNXNhQnE0WkxjcENWbUtqcHk1WXRTMHRMVTYybkt3dUlmaThSV0E0
QVkycHJhM056YzFOU1VvcUtpdngrUDl1b0dsc1ltSEJVTXhEMk9BYklqQlg3U05PdXhMVW51
SUVraXNPbE9jakcyUDEvMXdFQUFKREhqdmNjQVFBQWlBeG9PZ0FBT0Fkb09nQUFPQWU3YXpv
VzZ3RUFRQjY3KzcxQTA2TkU1bmRzR0pod01Genl5SXhWUTBORFhsNWVjbkp5WGw3ZTl1M2JK
ZmR5QUdLWWtzT2w4bnVKWUxpR3JlbGVBV2k2L1RFZVJoaVlxTUJ3eVdNOFZoa1pHYnQyN1Fx
RlFuNi9YL25mUjExeVhvdGhHZ2V1YVk4VGRpOFZabW02bU1VVDRhck1zckt5bHBZV1NtbHpj
L1BNbVRPcGxnTU1LM24yN05uYmJydHQ4K2JOOG9FQkpXRm5FZ3hNbEdDNDVERWVxOUxTMHVi
bTVwNmVudDI3ZDdOelhHWXZ4eENCcG12NnZkaEMwOFYraUpxK2R1M2ErZlBuVTBybnpadTNi
dDA2cW5WbktTR2tvNk9EcXorSURPTTVBUU1URlJndWVZekhxclcxTlRNemt4Q1NtWm5aMXRZ
bXVaZGpHSzZtNi9tOTJGM1QrL3I2Mk90ejU4NWxaR1I4K2VXWEdSa1ozMzMzSGRWeWdDR0Vs
SmFXWm1kbnQ3ZTN5MGNGVklUTkRtQmdvZ1RESlkveFdPWG41L3Y5L2xBbzVQUDVDZ29LSlBk
eURNUFZkSTdTNzBWK0w0YUptcTd5ZTVrd1ljTHUzYnU3dTdzM2JOakFkNm1zckx6aGhodm16
WnZIM21ybTZXZk9uTm14WTBkdWJpNzcvTXdGcGdBQUNIWkpSRUZVOHhaRWdQR2NnSUdKQ2d5
WFBNWmpOVzdjT0wvZjM5UFRzMnZYTHF5bmEyNVJvV21QWXhkTlYvbTlWRmRYWjJSa2pCOC9m
dDI2ZFh4amMzTXpJYVM1dVptOTFYU0FZUi9WMU5UTW1qV0xaZkZBSG5JbGZLT3lEQXhNT0Jn
dWVXVEdxcTZ1enVQeGpCZ3hZdXJVcWZYMTlYcDdPUTh4VEpuaFloOForTDNJTkEyL0Z3QUFj
QTUyditjSUFBQ0FQTkIwQUFCd0R0QjBBQUJ3RHRacE9wYmRBUURBYkt6N2pSU2FiZ0Y2UjhU
ZzhpVHFZbE1PRWVXc3pzckswaXlqNSs1aVBNaUp6cFl0VzY2NzdyclUxTlNaTTJmdTNidVhV
dHJRMERCanhveVJJMGVXbDVlLzk5NTdtbnVKRTBtc3h3R0laNURvM0NJVGVHU0RyR0w0bXI1
QmVFRFRiWVpxcUQvNTVKUHM3R3lEOFhlNUtZY21TNVlzZWZMSkp6VS8wblIzQ1R2SWljN2N1
WE1QSHo3YzNkMjlaY3NXZGw5VlpXVmxSMGRIS0JUYXZuMzd4SWtURGZaVkRvdFlqd01RenlE
UnVVVW04R2dHbVdPV3BpczM4c3N6WDM3NTVmSGp4MmRtWm03YXRFbXpESHV4ZlBueTlQVDBz
ckl5ZXZsN1BpVWxwYlMwRlBZQWtpZ0hOaFFLRlJVVnZmYmFhd1p5NDNKVERwSHZ2LzgrTXpP
enE2dEw4MVBSM1VWbWtCM0R5Wk1uVTFOVGUzdDcyZHRnTUZoZlh6OTkrblNEWFRTSFJWVlBR
aU9lUVhyT0xWUXU4QWdHbVdPcHBxOWZ2ejRZRERZMU5iRXpRVS9UWDNqaGhVQWc4TkJERC9G
UCsvdjc5KzNiTjJuU0pKbVFnSEpnSDN2c01YWm5vNEhjdU55VVEyVDE2dFVMRml6USsxUjBk
NUVaWkdmdzdiZmZWbFJVUFByb28rd3RYNlE2ZVBDZ3dWN2lzS2pxU1hURU0walB1VVVtOE1n
R21XTzZwbk4zRjBKSVgxK2Y4bE94RE51by9BWmJ2MzQ5dXcrTkVKS1VsQ1FURWxBZUVUWjB4
dXZqTGpmbFVOSFgxNWVUazZQOGJsTWh1cnZJRExJRE9IandZRzV1N29vVkt3WUdCdmpHUUND
d2RldldvcUlpZ3gxVlk2SlpUMEtqZHdiUks1MWJaQUtQZUpBNVptbTY2TzRpWnVXYURqQ3Ey
dExTMHBxYW1vTEJvTS9uYy9EWkVsdkMvdVdrd3VXbUhDcnE2dXBtejU1dFVNREEzY1hCSTFa
VFUxTlJVY0VjT3hpTEZpM3E3T3dNaFVMMTlmV3E1UVVWeW1FUjYzRUFtbWVReXJsRkp2Qm9C
cGxqbHFhTDdpNmlwbXM2d0tocWUvYlpaek15TWpJeU1sYXZYdTNnRXlaV2tDdFJmYVQ1bXJy
WWxFT1RXYk5tYmR1MlRibEZOUUlHN2k0T0hpdlZsTGg0OFdKdGJXMXVibTVLU2twUlVaSGY3
K2ZGRFBiU3JDY093Y1FhdlRQSXdMbUZCVzQ4WEhxRGJBejhYZ0FBd0RuZ1BsSUFBSEFPMEhR
QUFIQU8wSFFBQUhBTzBIUUFiSTNkZnErS3BqOTJpOFdSUU5NQjBDQmk5WW01YkJsVUdIMWIv
SjVZU3VtcFU2ZjBMRzVrR3BXNWJrS213NXFlSnlydkZJUFcrUllacHhUUnVrZlB6TWU0TFpt
clJjUzR4TGJFZWlLd3g0R21BNkNCU3pUOTVwdHZmdSs5OXlaUG5qeGx5cFIzMzMzWCtNSjg0
MFpsT2lOVFJ2UThFYjFUWk9xWGNVb1JyWHMwelh3a1l6R09Ub3hMcnkxbFBSSFk0MERUQWRC
QTg0d2xWMW9QclYyNzF1UHhKQ2NuODl4SzVnSmZWWDdIbnF1cXF0TFMwcVpQbjk3YTJrb3Bi
VzF0TFNnb1NFdExxNnFxVXRhc2JGMXM2K2pSb3pmZmZITnFhdXEwYWRONFptb3NOSXNXTFZx
OWV2WFVxVk05SHMrYU5Xc1dMMTZzV1kvWUg1a1JFK3NoaEN4ZnZuejA2TkU4VWdPNDU0bUJk
MHJZUHFpY1VsUUZST3NlY1l0bXRab2JKYjlpbFhHSmJlblZJMitQQTAwSFFBTzk4MU5wUFRS
bXpCaXYxOXZSMGRIVDB4TjJSODBDWEsrcnE2dUR3V0JOVFUxeGNUR2xkTWFNR1RVMU5jRmc4
SlZYWGxHV1Z4a2ZxZG9xTHk5Ly9mWFhRNkhRcmwyN3BrMmJKaFBtNnRXcmI3enh4bm56NWxW
V1Z0NTQ0NDFyMXF6UnJFZXZQNnE0VkY4ellqM0tTSTN2ZEZkNm51aDVwMmoyUWV5U2dWT0th
TjBqYnBGc1MzT0xjVng2YlluMURNc2VCNW9PZ0FiaWVTVmFENzM5OXR2MzNIUFB0R25UeG80
ZCs4d3p6K2p0cUZlejBnb3BHQXhTU29QQllHcHFLcVUwSlNXRmJRa0VBcXlNcHZHUnFxMlVs
QlF1cVpMbVNEdDI3RWhLU25ycHBaZisvT2MvSnlVbDdkeTVVN01lc1Q4eUl5YldJMGFxaVo0
dml0STdSYklQeGs0cG9uV1B1RVcrcmJDSFhoV1hYbHVxZW9acmp3Tk5CMEFEOGZ6VXN4NGFH
QmpZdTNkdmVubzZlenR5NU1nVEowNFkxS3hwaGZUcXE2K3k3SFhHakJtVTBxS2lJcFlYVjFk
WHN6S2FyYXZhcXFpb2FHeHM3Tzd1bGcvejJMRmpoSkFEQnc1ODlORkhoQkFtQW1JOVluOUV4
TzFpUGNwSTJWOGtJcHErS0NydkZEMlVmWkJ4U2hHdGV3ek1mTUxHYTZ6cFlseDZiU25yaWNB
ZUI1b09nQWJpU29Kb1BjUStZaTRmR3pkdVpEc3VXN1lzTFMzTjRQVFd0RUppNituNStmbjc5
KytubE83ZnZ6OC9Qejh0TFczNTh1VjZyWXR0SFR0MjdQYmJiMmRiK0Vaam9lbnQ3UjB6Wmt4
UFQwOG9GQm96Wmd4elRoWHJFZnVqT1dLcUxXSTl5a2oxMXROVkkzL3g0a1gyUXVtZEVuWXZT
cW1NSFkxbzNhTnA1cVBhUzJ4TDNDSVRsOWhXMkpwbDdIR2c2UURFR1dQWkJXQllRTk1CaURQ
UWRCQkRvT2tBQU9BY29Pa0FBT0Fjb09rQUFPQWNvT2tBQU9BY29Pa2dNV2hzYkd4cWF1cnY3
MjlxYW1wc2JKVGN4ZmhUdlFLQlFNRG44Mm1XTjlnTEFEc0FUUWVKUVdOajQvdnZ2Ly9aWjU5
OThNRUhzVkpWdlhvT0hUb2tmZ1FwQndrQk5CMGtCbzJOamNlT0hmUDcvY2VPSGVQeXFuclIy
TmpZM3Q3dTkvdVBIajJxdDFGVnA5alFEei84ME56Y3JLbnBmcjkvejU0OXAwNmRpbWxrQU1R
U2FEcElEQm9iRzgrZE84ZWYrVWJsaThiR3h1KysreTRRQ0xEN0JqVTNxdW9VRy9yNDQ0K1BI
eit1K2RIZzRPQ3BVNmQyNzk0ZHU3QUFpREhRZEpBWU5EWTJEZzRPdnZQT080T0RnMXh3L1g1
L0lCRGdLaTlLdkxoUlZhZG1RM3JyNW9PRGcyZk9uSUdtQXpzRFRRZUpnVkpoK2V1alI0LzYv
ZjcyOXZZSU5GMGwzT0tuNG92R3hzWTllL1o4ODgwM3NRd01nSmdDVFFjQUFPY0FUUWNBQU9j
QVRRY0FBT2NBVFFjQUFPY0FUUWNBQU9jQVRRY0FBT2Z3bzZhM3RyYStBUUFBSVBFaEVIUUFB
SEFNL3gvT2JoNTFrd0JER2dBQUFBQkpSVTVFcmtKZ2dnPT0iIGFsdD0iIiAvPjwvcD48Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCAjMzI1RkJBOyBwYWRkaW5n
LWxlZnQ6IDVweDttYXJnaW4tbGVmdDo1cHg7Ij4tLS0tLVVyc3ByJnV1bWw7bmdsaWNoZSBO
YWNocmljaHQtLS0tLTxiciAvPjxzdHJvbmc+QW46PC9zdHJvbmc+CUtvbnJhZCBSemVzenV0
ZWsgV2lsayAmbHQ7a29ucmFkLndpbGtAb3JhY2xlLmNvbSZndDs7IDxiciAvPjxzdHJvbmc+
Q0M6PC9zdHJvbmc+CVNhbmRlciBFaWtlbGVuYm9vbSAmbHQ7bGludXhAZWlrZWxlbmJvb20u
aXQmZ3Q7OyB4ZW4tZGV2ZWwgJmx0O3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tJmd0
OzsgSmFuIEJldWxpY2ggJmx0O2piZXVsaWNoQHN1c2UuY29tJmd0OzsgS29ucmFkIFJ6ZXN6
dXRlayBXaWxrICZsdDtrb25yYWRAZGFybm9rLm9yZyZndDs7IDxiciAvPjxzdHJvbmc+Vm9u
Ojwvc3Ryb25nPglDYXJzdGVuIFNjaGllcnMgJmx0O2NhcnN0ZW5Ac2NoaWVycy5kZSZndDs8
YnIgLz48c3Ryb25nPkdlc2VuZGV0Ojwvc3Ryb25nPglEaSAyOC4wMi4yMDEyIDE1OjM5PGJy
IC8+PHN0cm9uZz5CZXRyZWZmOjwvc3Ryb25nPglSZTogW1hlbi1kZXZlbF0gTG9hZCBpbmNy
ZWFzZSBhZnRlciBtZW1vcnkgdXBncmFkZSAocGFydDIpPGJyIC8+PHN0cm9uZz5BbmxhZ2U6
PC9zdHJvbmc+CWlubGluZS50eHQ8YnIgLz48c3R5bGUgdHlwZT0idGV4dC9jc3MiPi5ib2R5
Y2xhc3MgeyBmb250LWZhbWlseTogbW9ub3NwYWNlOyB9PC9zdHlsZT4gICAgICAgICAgICAg
ICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPiAgICAgICAuYm9keWNsYXNzICAgICAgIHsgICAg
ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh
bnQ7ICAgICAgICAgZm9udC1zaXplOiAxMnB4OyAgICAgICAgIHBhZGRpbmc6IDVweCA1cHgg
NXB4IDVweDsgICAgICAgICBtYXJnaW46IDBweDsgICAgICAgICBib3JkZXItc3R5bGU6IG5v
bmU7ICAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogI2ZmZmZmZjsgICAgICAgfSAgICAgICAg
cCwgdWwsIGxpICAgICAgIHsgICAgICAgICBtYXJnaW4tdG9wOiAwcHg7ICAgICAgICAgbWFy
Z2luLWJvdHRvbTogMHB4OyAgICAgICB9ICAgPC9zdHlsZT4gIDxkaXY+PHA+V2VsbCBsZXQg
bWUgY2hlY2sgZm9yIGEgbG9uZ2VyIHBlcmlvZCBvZiB0aW1lLCBhbmQgZXNwZWNpYWxseSwg
d2hldGhlciB0aGUgRG9tVSBpcyBzdGlsbDwvcD48cD53b3JraW5nIChjYW4gZG8gdGhhdCBv
bmx5IGZyb20gYXQgaG9tZSksIGJ1dCBsb2FkIGxvb2tzIHByZXR0eSB3ZWxsIGFmdGVyIGFw
cGx5aW5nIHRoZTwvcD48cD5wYXRjaCB0byAzLjIuOCA6LUQuPC9wPjxwPiZuYnNwOzwvcD48
cD5CUiw8L3A+PHA+Q2Fyc3Rlbi48YnIgLz4mbmJzcDs8L3A+PGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlci1sZWZ0OiAycHggc29saWQgIzMyNUZCQTsgcGFkZGluZy1sZWZ0OiA1cHg7bWFy
Z2luLWxlZnQ6NXB4OyI+LS0tLS1VcnNwciZ1dW1sO25nbGljaGUgTmFjaHJpY2h0LS0tLS08
YnIgLz48c3Ryb25nPkFuOjwvc3Ryb25nPglKYW4gQmV1bGljaCAmbHQ7SkJldWxpY2hAc3Vz
ZS5jb20mZ3Q7OyA8YnIgLz48c3Ryb25nPkNDOjwvc3Ryb25nPglLb25yYWQgUnplc3p1dGVr
IFdpbGsgJmx0O2tvbnJhZEBkYXJub2sub3JnJmd0OzsgeGVuLWRldmVsICZsdDt4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbSZndDs7IENhcnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3Rl
bkBzY2hpZXJzLmRlJmd0OzsgU2FuZGVyIEVpa2VsZW5ib29tICZsdDtsaW51eEBlaWtlbGVu
Ym9vbS5pdCZndDs7IDxiciAvPjxzdHJvbmc+Vm9uOjwvc3Ryb25nPglLb25yYWQgUnplc3p1
dGVrIFdpbGsgJmx0O2tvbnJhZC53aWxrQG9yYWNsZS5jb20mZ3Q7PGJyIC8+PHN0cm9uZz5H
ZXNlbmRldDo8L3N0cm9uZz4JRnIgMTcuMDIuMjAxMiAxNjoxODxiciAvPjxzdHJvbmc+QmV0
cmVmZjo8L3N0cm9uZz4JUmU6IFtYZW4tZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVt
b3J5IHVwZ3JhZGUgKHBhcnQyKTxiciAvPk9uIFRodSwgRmViIDE2LCAyMDEyIGF0IDA4OjU2
OjUzQU0gKzAwMDAsIEphbiBCZXVsaWNoIHdyb3RlOjxiciAvPiZndDsgJmd0OyZndDsmZ3Q7
IE9uIDE1LjAyLjEyIGF0IDIwOjI4LCBLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJh
ZC53aWxrQG9yYWNsZS5jb20mZ3Q7IHdyb3RlOjxiciAvPiZndDsgJmd0O0BAIC0xNTUwLDcg
KzE1NTIsMTEgQEAgc3RhdGljIHZvaWQgKl9fdm1hbGxvY19hcmVhX25vZGUoc3RydWN0IHZt
X3N0cnVjdCAqYXJlYSwgZ2ZwX3QgZ2ZwX21hc2ssPGJyIC8+Jmd0OyAmZ3Q7IAlzdHJ1Y3Qg
cGFnZSAqKnBhZ2VzOzxiciAvPiZndDsgJmd0OyAJdW5zaWduZWQgaW50IG5yX3BhZ2VzLCBh
cnJheV9zaXplLCBpOzxiciAvPiZndDsgJmd0OyAJZ2ZwX3QgbmVzdGVkX2dmcCA9IChnZnBf
bWFzayAmYW1wOyBHRlBfUkVDTEFJTV9NQVNLKSB8IF9fR0ZQX1pFUk87PGJyIC8+Jmd0OyAm
Z3Q7LTxiciAvPiZndDsgJmd0OysJZ2ZwX3QgZG1hX21hc2sgPSBnZnBfbWFzayAmYW1wOyAo
X19HRlBfRE1BIHwgX19HRlBfRE1BMzIpOzxiciAvPiZndDsgJmd0OysJaWYgKHhlbl9wdl9k
b21haW4oKSkgezxiciAvPiZndDsgJmd0OysJCWlmIChkbWFfbWFzayA9PSAoX19HRlBfRE1B
IHwgX19HRlBfRE1BMzIpKTxiciAvPiZndDsgPGJyIC8+Jmd0OyBJIGRpZG4mIzM5O3Qgc3Bv
dCB3aGVyZSB5b3UgZm9yY2UgdGhpcyBub3JtYWxseSBpbnZhbGlkIGNvbWJpbmF0aW9uLCB3
aXRob3V0PGJyIC8+Jmd0OyB3aGljaCB0aGUgY2hhbmdlIHdvbiYjMzk7dCBhZmZlY3Qgdm1h
bGxvYzMyKCkgaW4gYSAzMi1iaXQga2VybmVsLjxiciAvPiZndDsgPGJyIC8+Jmd0OyAmZ3Q7
KwkJCWdmcF9tYXNrICZhbXA7PSAoX19HRlBfRE1BIHwgX19HRlBfRE1BMzIpOzxiciAvPiZn
dDsgPGJyIC8+Jmd0OyAJCQlnZnBfbWFzayAmYW1wOz0gfihfX0dGUF9ETUEgfCBfX0dGUF9E
TUEzMik7PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7IEphbjxiciAvPjxiciAvPkR1aCE8YnIgLz5H
b29kIGV5ZXMuIFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhhdC48YnIgLz48YnIgLz4mZ3Q7IDxi
ciAvPiZndDsgJmd0OysJfTxiciAvPiZndDsgJmd0OyAJbnJfcGFnZXMgPSAoYXJlYS0mZ3Q7
c2l6ZSAtIFBBR0VfU0laRSkgJmd0OyZndDsgUEFHRV9TSElGVDs8YnIgLz4mZ3Q7ICZndDsg
CWFycmF5X3NpemUgPSAobnJfcGFnZXMgKiBzaXplb2Yoc3RydWN0IHBhZ2UgKikpOzxiciAv
PiZndDsgJmd0OyA8YnIgLz4mZ3Q7IDxiciAvPjxiciAvPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIC8+WGVuLWRldmVsIG1haWxpbmcgbGlz
dDxiciAvPlhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPGJyIC8+aHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsPGJyIC8+PC9ibG9ja3F1b3RlPjwvZGl2PiAgIDwv
YmxvY2txdW90ZT48L2Rpdj4gICA8L2Jsb2NrcXVvdGU+PHA+Jm5ic3A7PC9wPgo8L2JvZHk+
CjwvaHRtbD4=
--=_F1yjPY0x5Rt03QtpR+eAjTruBumDA6U+Yn3CBd30zLybmgQg--

--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw
Content-Type: application/octet-stream; name=debug.log
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=debug.log

VXNpbmcgY29uZmlnIGZpbGUgIi9ldGMveGVuL3Jpa2VyLjMyIi4KU3RhcnRlZCBkb21haW4g
cmlrZXIgKGlkPTE1KQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5
cyBjcHVzZXQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw
dQ0KWyAgICAwLjAwMDAwMF0gTGludXggdmVyc2lvbiAzLjIuOC1hbWQ2NCAocm9vdEBjaGVr
b3RleSkgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgVHVl
IEZlYiAyOCAxMTozMjoyNyBDRVQgMjAxMg0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5l
OiByb290PS9kZXYveHZkYTEgcm8gaW9tbXU9c29mdCBzd2lvdGxiPTQwOTYgeGVuY29ucz10
dHkNClsgICAgMC4wMDAwMDBdIEFDUEkgaW4gdW5wcml2aWxlZ2VkIGRvbWFpbiBkaXNhYmxl
ZA0KWyAgICAwLjAwMDAwMF0gUmVsZWFzZWQgMCBwYWdlcyBvZiB1bnVzZWQgbWVtb3J5DQpb
ICAgIDAuMDAwMDAwXSBTZXQgMCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5nDQpbICAgIDAuMDAw
MDAwXSBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSAg
WGVuOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAodXNhYmxlKQ0KWyAg
ICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDBhMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAg
KHJlc2VydmVkKQ0KWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDAwMDEwMDAwMCAtIDAw
MDAwMDAwMTQ4MDAwMDAgKHVzYWJsZSkNClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERp
c2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAwLjAwMDAwMF0gRE1JIG5vdCBwcmVz
ZW50IG9yIGludmFsaWQuDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kDQpb
ICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4MTQ4MDAgbWF4X2FyY2hfcGZuID0gMHg0MDAw
MDAwMDANClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAw
MDAwMDAtMDAwMDAwMDAxNDgwMDAwMA0KWyAgICAwLjAwMDAwMF0gUkFNRElTSzogMDE5Mjgw
MDAgLSAwMzUwYTAwMA0KWyAgICAwLjAwMDAwMF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZv
dW5kDQpbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAt
MDAwMDAwMDAxNDgwMDAwMA0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAg
MDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDE0ODAwMDAwDQpbICAgIDAuMDAwMDAwXSAgIE5P
REVfREFUQSBbMDAwMDAwMDAxM2ZmYjAwMCAtIDAwMDAwMDAwMTNmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSBab25lIFBGTiByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERNQSAgICAgIDB4
MDAwMDAwMTAgLT4gMHgwMDAwMTAwMA0KWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAweDAw
MDAxMDAwIC0+IDB4MDAxMDAwMDANClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkN
ClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQ0K
WyAgICAwLjAwMDAwMF0gZWFybHlfbm9kZV9tYXBbMl0gYWN0aXZlIFBGTiByYW5nZXMNClsg
ICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwYTANClsgICAgMC4w
MDAwMDBdICAgICAwOiAweDAwMDAwMTAwIC0+IDB4MDAwMTQ4MDANClsgICAgMC4wMDAwMDBd
IFNGSTogU2ltcGxlIEZpcm13YXJlIEludGVyZmFjZSB2MC44MSBodHRwOi8vc2ltcGxlZmly
bXdhcmUub3JnDQpbICAgIDAuMDAwMDAwXSBTTVA6IEFsbG93aW5nIDEgQ1BVcywgMCBob3Rw
bHVnIENQVXMNClsgICAgMC4wMDAwMDBdIE5vIGxvY2FsIEFQSUMgcHJlc2VudA0KWyAgICAw
LjAwMDAwMF0gQVBJQzogZGlzYWJsZSBhcGljIGZhY2lsaXR5DQpbICAgIDAuMDAwMDAwXSBB
UElDOiBzd2l0Y2hlZCB0byBhcGljIE5PT1ANClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl
cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw
DQpbICAgIDAuMDAwMDAwXSBBbGxvY2F0aW5nIFBDSSByZXNvdXJjZXMgc3RhcnRpbmcgYXQg
MTQ4MDAwMDAgKGdhcDogMTQ4MDAwMDA6ZWI4MDAwMDApDQpbICAgIDAuMDAwMDAwXSBCb290
aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuDQpbICAgIDAuMDAwMDAwXSBYZW4g
dmVyc2lvbjogNC4xLjIgKHByZXNlcnZlLUFEKQ0KWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVy
Y3B1OiBOUl9DUFVTOjUxMiBucl9jcHVtYXNrX2JpdHM6NTEyIG5yX2NwdV9pZHM6MSBucl9u
b2RlX2lkczoxDQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI3IHBhZ2VzL2Nw
dSBAZmZmZjg4MDAxM2ZhODAwMCBzODE2MDAgcjgxOTIgZDIwODAwIHUxMTA1OTINClsgICAg
MC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdy
b3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6IDgyNTM5DQpbICAgIDAuMDAwMDAwXSBQb2xpY3kg
em9uZTogRE1BMzINClsgICAgMC4wMDAwMDBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9
L2Rldi94dmRhMSBybyBpb21tdT1zb2Z0IHN3aW90bGI9NDA5NiB4ZW5jb25zPXR0eQ0KWyAg
ICAwLjAwMDAwMF0gUElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2
Mzg0IGJ5dGVzKQ0KWyAgICAwLjAwMDAwMF0gUGxhY2luZyA4TUIgc29mdHdhcmUgSU8gVExC
IGJldHdlZW4gZmZmZjg4MDAxMjgwMDAwMCAtIGZmZmY4ODAwMTMwMDAwMDANClsgICAgMC4w
MDAwMDBdIHNvZnR3YXJlIElPIFRMQiBhdCBwaHlzIDB4MTI4MDAwMDAgLSAweDEzMDAwMDAw
DQpbICAgIDAuMDAwMDAwXSBNZW1vcnk6IDI3NDM0OGsvMzM1ODcyayBhdmFpbGFibGUgKDMz
ODJrIGtlcm5lbCBjb2RlLCA0NDhrIGFic2VudCwgNjEwNzZrIHJlc2VydmVkLCAzMjkxayBk
YXRhLCA1NjhrIGluaXQpDQpbICAgIDAuMDAwMDAwXSBTTFVCOiBHZW5zbGFicz0xNSwgSFdh
bGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9MSwgTm9kZXM9MQ0KWyAg
ICAwLjAwMDAwMF0gSGllcmFyY2hpY2FsIFJDVSBpbXBsZW1lbnRhdGlvbi4NClsgICAgMC4w
MDAwMDBdIE5SX0lSUVM6MzMwMjQgbnJfaXJxczoyNTYgMTYNClsgICAgMC4wMDAwMDBdIENv
bnNvbGU6IGNvbG91ciBkdW1teSBkZXZpY2UgODB4MjUNClsgICAgMC4wMDAwMDBdIGNvbnNv
bGUgW3R0eTBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBdIGNvbnNvbGUgW2h2YzBdIGVuYWJs
ZWQNClsgICAgMC4wMDAwMDBdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KWyAg
ICAwLjAwMDAwMF0gRGV0ZWN0ZWQgMjIxMC4wMzggTUh6IHByb2Nlc3Nvci4NClsgICAgMC4w
MDQwMDBdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxh
dGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDQ0MjAuMDcgQm9nb01JUFMgKGxwaj04ODQw
MTUyKQ0KWyAgICAwLjAwNDAwMF0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTog
MzAxDQpbICAgIDAuMDA0MDAwXSBTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQNClsg
ICAgMC4wMDQwMDBdIFNFTGludXg6ICBEaXNhYmxlZCBhdCBib290Lg0KWyAgICAwLjAwNDAw
MF0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1
MjQyODggYnl0ZXMpDQpbICAgIDAuMDA0MDAwXSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVu
dHJpZXM6IDMyNzY4IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KWyAgICAwLjAwNDAwMF0g
TW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYNClsgICAgMC4wMDQwMDBdIElu
aXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QNClsgICAgMC4wMDQwMDBdIEluaXRp
YWxpemluZyBjZ3JvdXAgc3Vic3lzIGRldmljZXMNClsgICAgMC4wMDQwMDBdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGZyZWV6ZXINClsgICAgMC4wMDQwMDBdIEluaXRpYWxpemlu
ZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMNClsgICAgMC4wMDQwMDBdIENQVTogUGh5c2ljYWwg
UHJvY2Vzc29yIElEOiAwDQpbICAgIDAuMDA0MDAwXSBDUFU6IFByb2Nlc3NvciBDb3JlIElE
OiAyDQpbICAgIDAuMDA0MDAwXSBTTVAgYWx0ZXJuYXRpdmVzOiBzd2l0Y2hpbmcgdG8gVVAg
Y29kZQ0KWyAgICAwLjAwNDAyNl0gRnJlZWluZyBTTVAgYWx0ZXJuYXRpdmVzOiAxNmsgZnJl
ZWQNClsgICAgMC4wMDQxNTFdIFBlcmZvcm1hbmNlIEV2ZW50czogDQpbICAgIDAuMDA0MTU4
XSBubyBBUElDLCBib290IHdpdGggdGhlICJsYXBpYyIgYm9vdCBwYXJhbWV0ZXIgdG8gZm9y
Y2UtZW5hYmxlIGl0Lg0KWyAgICAwLjAwNDE2Nl0gbm8gaGFyZHdhcmUgc2FtcGxpbmcgaW50
ZXJydXB0IGF2YWlsYWJsZS4NClsgICAgMC4wMDQxODRdIEJyb2tlbiBQTVUgaGFyZHdhcmUg
ZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2ZW50cyBvbmx5Lg0KWyAgICAwLjAwNDQ0NV0g
QnJvdWdodCB1cCAxIENQVXMNClsgICAgMC4wMDQ2NDJdIGRldnRtcGZzOiBpbml0aWFsaXpl
ZA0KWyAgICAwLjAxMDU3OV0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQNClsgICAgMC4wMTA2
NDVdIHByaW50X2NvbnN0cmFpbnRzOiBkdW1teTogDQpbICAgIDAuMDEwNjkzXSBORVQ6IFJl
Z2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2DQpbICAgIDAuMDEwODc2XSBFeHRlbmRlZCBD
b25maWcgU3BhY2UgZW5hYmxlZCBvbiAwIG5vZGVzDQpbICAgIDAuMDEwOTMyXSBQQ0k6IHNl
dHRpbmcgdXAgWGVuIFBDSSBmcm9udGVuZCBzdHViDQpbICAgIDAuMDEwOTMyXSBiaW86IGNy
ZWF0ZSBzbGFiIDxiaW8tMD4gYXQgMA0KWyAgICAwLjAxMDkzMl0gQUNQSTogSW50ZXJwcmV0
ZXIgZGlzYWJsZWQuDQpbICAgIDAuMDEyMDM0XSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5n
IGJhbGxvb24gZHJpdmVyLg0KWyAgICAwLjAxMjA3M10geGVuLWJhbGxvb246IEluaXRpYWxp
c2luZyBiYWxsb29uIGRyaXZlci4NClsgICAgMC4wMTIwNzNdIHZnYWFyYjogbG9hZGVkDQpb
ICAgIDAuMDEyMTE2XSBQQ0k6IFN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IFBDSQ0KWyAgICAw
LjAxMjEyMl0gUENJOiBTeXN0ZW0gZG9lcyBub3Qgc3VwcG9ydCBQQ0kNClsgICAgMC4wMTIy
MjhdIFN3aXRjaGluZyB0byBjbG9ja3NvdXJjZSB4ZW4NClsgICAgMC4wMTM2NjZdIHBucDog
UG5QIEFDUEk6IGRpc2FibGVkDQpbICAgIDAuMDE1MjcxXSBORVQ6IFJlZ2lzdGVyZWQgcHJv
dG9jb2wgZmFtaWx5IDINClsgICAgMC4wMTUzNTddIElQIHJvdXRlIGNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KWyAgICAwLjAxNTYy
Ml0gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMTYzODQgKG9yZGVyOiA2
LCAyNjIxNDQgYnl0ZXMpDQpbICAgIDAuMDE1Nzk5XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVu
dHJpZXM6IDE2Mzg0IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KWyAgICAwLjAxNTg5Ml0g
VENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxNjM4NCBiaW5kIDE2
Mzg0KQ0KWyAgICAwLjAxNTkwMF0gVENQIHJlbm8gcmVnaXN0ZXJlZA0KWyAgICAwLjAxNTkx
NF0gVURQIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogMSwgODE5MiBieXRlcykN
ClsgICAgMC4wMTU5MjhdIFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRl
cjogMSwgODE5MiBieXRlcykNClsgICAgMC4wMTYwMTFdIE5FVDogUmVnaXN0ZXJlZCBwcm90
b2NvbCBmYW1pbHkgMQ0KWyAgICAwLjAxNjExNl0gVW5wYWNraW5nIGluaXRyYW1mcy4uLg0K
WyAgICAwLjA1NjczMV0gRnJlZWluZyBpbml0cmQgbWVtb3J5OiAyODU1MmsgZnJlZWQNClsg
ICAgMC4wNjczMDhdIHBsYXRmb3JtIHJ0Y19jbW9zOiByZWdpc3RlcmVkIHBsYXRmb3JtIFJU
QyBkZXZpY2UgKG5vIFBOUCBkZXZpY2UgZm91bmQpDQpbICAgIDAuMDY3NTQ3XSBhdWRpdDog
aW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkNClsgICAgMC4wNjc1NjNd
IHR5cGU9MjAwMCBhdWRpdCgxMzMwNTE5NDkzLjQ3MToxKTogaW5pdGlhbGl6ZWQNClsgICAg
MC4wNzk4MjldIEh1Z2VUTEIgcmVnaXN0ZXJlZCAyIE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9j
YXRlZCAwIHBhZ2VzDQpbICAgIDAuMDgxNzAxXSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYu
NS4yDQpbICAgIDAuMDgxNzY2XSBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUx
MiAob3JkZXIgMCwgNDA5NiBieXRlcykNClsgICAgMC4wODE4NjRdIG1zZ21uaSBoYXMgYmVl
biBzZXQgdG8gNTkxDQpbICAgIDAuMDgyMDc4XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMg
KGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUzKQ0KWyAgICAwLjA4
MjA4N10gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZA0KWyAgICAwLjA4MjA5Ml0gaW8g
c2NoZWR1bGVyIGRlYWRsaW5lIHJlZ2lzdGVyZWQNClsgICAgMC4wODIxMjZdIGlvIHNjaGVk
dWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVmYXVsdCkNClsgICAgMC4wOTg0MDRdIFNlcmlhbDog
ODI1MC8xNjU1MCBkcml2ZXIsIDQgcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQNClsgICAg
MC4wOTg2OThdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMw0KWyAgICAwLjA5OTIx
OV0gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRz
IGRpcmVjdGx5Lg0KWyAgICAwLjEwMDAzN10gaTgwNDI6IE5vIGNvbnRyb2xsZXIgZm91bmQN
ClsgICAgMC4xMDAxMjJdIG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9y
IGFsbCBtaWNlDQpbICAgIDAuMTQwMTA3XSBydGNfY21vcyBydGNfY21vczogcnRjIGNvcmU6
IHJlZ2lzdGVyZWQgcnRjX2Ntb3MgYXMgcnRjMA0KWyAgICAwLjE0MDE4MV0gcnRjX2Ntb3M6
IHByb2JlIG9mIHJ0Y19jbW9zIGZhaWxlZCB3aXRoIGVycm9yIC0zOA0KWyAgICAwLjE0MDI2
NV0gcGNpZnJvbnQgcGNpLTA6IEluc3RhbGxpbmcgUENJIGZyb250ZW5kDQpbICAgIDAuMTQw
NDU4XSBwY2lmcm9udCBwY2ktMDogQ3JlYXRpbmcgUENJIEZyb250ZW5kIEJ1cyAwMDAwOjAw
DQpbICAgIDAuMTU2MzA3XSBUQ1AgY3ViaWMgcmVnaXN0ZXJlZA0KWyAgICAwLjE1NjQzNF0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMA0KWyAgICAwLjE1Njk5OV0gTW9i
aWxlIElQdjYNClsgICAgMC4xNTcwMTNdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMTcNClsgICAgMC4xNTcwMjFdIFJlZ2lzdGVyaW5nIHRoZSBkbnNfcmVzb2x2ZXIga2V5
IHR5cGUNClsgICAgMC4xNTcxNjJdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQ0K
WyAgICAwLjE2OTQ1NV0gcGNpZnJvbnQgcGNpLTA6IGNsYWltaW5nIHJlc291cmNlIDAwMDA6
MDA6MDAuMC8wDQpbICAgIDAuMTY5NDY3XSBwY2lmcm9udCBwY2ktMDogY2xhaW1pbmcgcmVz
b3VyY2UgMDAwMDowMDowMS4wLzANClsgICAgMC4xNjk0NzNdIHBjaWZyb250IHBjaS0wOiBj
bGFpbWluZyByZXNvdXJjZSAwMDAwOjAwOjAyLjAvMA0KWyAgICAwLjI1NjE1OF0gWEVOQlVT
OiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6IGRldmljZS92YmQvNTE3MTMNClsgICAgMC4yNTYx
OTNdIFhFTkJVUzogRGV2aWNlIHdpdGggbm8gZHJpdmVyOiBkZXZpY2UvdmJkLzUxNzE0DQpb
ICAgIDAuMjU2MjEwXSBYRU5CVVM6IERldmljZSB3aXRoIG5vIGRyaXZlcjogZGV2aWNlL3Zi
ZC81MTcyOQ0KWyAgICAwLjI1NjIyNV0gWEVOQlVTOiBEZXZpY2Ugd2l0aCBubyBkcml2ZXI6
IGRldmljZS92aWYvMA0KWyAgICAwLjI1NjIzOV0gWEVOQlVTOiBEZXZpY2Ugd2l0aCBubyBk
cml2ZXI6IGRldmljZS9jb25zb2xlLzANClsgICAgMC4yNTYyODldIGRyaXZlcnMvcnRjL2hj
dG9zeXMuYzogdW5hYmxlIHRvIG9wZW4gcnRjIGRldmljZSAocnRjMCkNClsgICAgMC4yNTYz
NjVdIEluaXRpYWxpemluZyBuZXR3b3JrIGRyb3AgbW9uaXRvciBzZXJ2aWNlDQpbICAgIDAu
MjU3MTkxXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA1NjhrIGZyZWVkDQpbICAg
IDAuMjU3NTczXSBXcml0ZSBwcm90ZWN0aW5nIHRoZSBrZXJuZWwgcmVhZC1vbmx5IGRhdGE6
IDYxNDRrDQpbICAgIDAuMjY2NDUwXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA2
OTZrIGZyZWVkDQpbICAgIDAuMjY4MDAzXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5
OiA4NDRrIGZyZWVkDQpMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLg0KWyAgICAwLjMyNDM4NF0g
dWRldls0NF06IHN0YXJ0aW5nIHZlcnNpb24gMTY0DQpbICAgIDAuMzY2MDcxXSBJbml0aWFs
aXNpbmcgWGVuIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVyLg0KWyAgICAwLjQ3NzIxNF0gYmxr
ZnJvbnQ6IHh2ZGExOiBiYXJyaWVyOiBlbmFibGVkDQpbICAgIDAuNDkzNDI4XSBibGtmcm9u
dDogeHZkYTI6IGJhcnJpZXI6IGVuYWJsZWQNClsgICAgMC41MDE4NDVdIFNldHRpbmcgY2Fw
YWNpdHkgdG8gODM4ODYwOA0KWyAgICAwLjUwMTg2MF0geHZkYTE6IGRldGVjdGVkIGNhcGFj
aXR5IGNoYW5nZSBmcm9tIDAgdG8gNDI5NDk2NzI5Ng0KWyAgICAwLjUwMjcwMF0gYmxrZnJv
bnQ6IHh2ZGIxOiBiYXJyaWVyOiBlbmFibGVkDQpbICAgIDAuNTA2MTg2XSBTZXR0aW5nIGNh
cGFjaXR5IHRvIDIwOTcxNTINClsgICAgMC41MDYyMDNdIHh2ZGEyOiBkZXRlY3RlZCBjYXBh
Y2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDEwNzM3NDE4MjQNClsgICAgMC41MDY1NzJdIFNldHRp
bmcgY2FwYWNpdHkgdG8gMjkzMDI3MjAwMg0KWyAgICAwLjUwNjU4MV0geHZkYjE6IGRldGVj
dGVkIGNhcGFjaXR5IGNoYW5nZSBmcm9tIDAgdG8gMTUwMDI5OTI2NTAyNA0KQmVnaW46IExv
YWRpbmcgZXNzZW50aWFsIGRyaXZlcnMgLi4uIGRvbmUuDQpCZWdpbjogUnVubmluZyAvc2Ny
aXB0cy9pbml0LXByZW1vdW50IC4uLiBkb25lLg0KQmVnaW46IE1vdW50aW5nIHJvb3QgZmls
ZSBzeXN0ZW0gLi4uIEJlZ2luOiBSdW5uaW5nIC9zY3JpcHRzL2xvY2FsLXRvcCAuLi4gZG9u
ZS4NCkJlZ2luOiBSdW5uaW5nIC9zY3JpcHRzL2xvY2FsLXByZW1vdW50IC4uLiBbICAgIDAu
Njk1NzM2XSBQTTogU3RhcnRpbmcgbWFudWFsIHJlc3VtZSBmcm9tIGRpc2sNCmRvbmUuDQpb
ICAgIDAuNzI5Njg4XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBz
ZWNvbmRzDQpbICAgIDAuNzI5NzM1XSBFWFQzLWZzICh4dmRhMSk6IG1vdW50ZWQgZmlsZXN5
c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlDQpCZWdpbjogUnVubmluZyAvc2NyaXB0cy9s
b2NhbC1ib3R0b20gLi4uIGRvbmUuDQpkb25lLg0KQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv
aW5pdC1ib3R0b20gLi4uIGRvbmUuDQoNSU5JVDogdmVyc2lvbiAyLjg4IGJvb3RpbmcNDQpV
c2luZyBtYWtlZmlsZS1zdHlsZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgUy4NClN0
YXJ0aW5nIHRoZSBob3RwbHVnIGV2ZW50cyBkaXNwYXRjaGVyOiB1ZGV2ZFsgICAgMS42OTg2
NjVdIHVkZXZbMTU1XTogc3RhcnRpbmcgdmVyc2lvbiAxNjQNCi4NClN5bnRoZXNpemluZyB0
aGUgaW5pdGlhbCBob3RwbHVnIGV2ZW50cy4uLmRvbmUuDQpXYWl0aW5nIGZvciAvZGV2IHRv
IGJlIGZ1bGx5IHBvcHVsYXRlZC4uLlsgICAgMS45NTY1NDFdIGlucHV0OiBQQyBTcGVha2Vy
IGFzIC9kZXZpY2VzL3BsYXRmb3JtL3Bjc3Brci9pbnB1dC9pbnB1dDANClsgICAgMi4yODIw
MTZdIEVycm9yOiBEcml2ZXIgJ3Bjc3BrcicgaXMgYWxyZWFkeSByZWdpc3RlcmVkLCBhYm9y
dGluZy4uLg0KWyAgICAyLjMzMTEyNl0gTGludXggdmlkZW8gY2FwdHVyZSBpbnRlcmZhY2U6
IHYyLjAwDQpbICAgIDIuMzUxOTgxXSBzYWE3MTQ2OiByZWdpc3RlciBleHRlbnNpb24gJ2J1
ZGdldF9hdicNClsgICAgMi4zNTI2MjJdIGJ1ZGdldF9hdiAwMDAwOjAwOjAwLjA6IGVuYWJs
aW5nIGRldmljZSAoMDAwMCAtPiAwMDAyKQ0KWyAgICAyLjM1MzYyOF0gYnVkZ2V0X2F2IDAw
MDA6MDA6MDAuMDogWGVuIFBDSSBtYXBwZWQgR1NJMTcgdG8gSVJRMjgNClsgICAgMi4zNTQz
MTZdIHNhYTcxNDY6IGZvdW5kIHNhYTcxNDYgQCBtZW0gZmZmZmM5MDAwMDQwNjAwMCAocmV2
aXNpb24gMSwgaXJxIDI4KSAoMHgxODk0LDB4MDAyOCkNClsgICAgMi4zNTQzNDRdIHNhYTcx
NDYgKDApOiBkbWEgYnVmZmVyIHNpemUgMTM0NzU4NA0KWyAgICAyLjM1NDM2MF0gRFZCOiBy
ZWdpc3RlcmluZyBuZXcgYWRhcHRlciAoS05DMSBEVkItQyBUREExMDAyNCkNClsgICAgMi4z
ODkzNzhdIGFkYXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sNClsgICAgMi4zODk0
MDVdIGVuY29kZWQgTUFDIGZyb20gRUVQUk9NIHdhcyBmZjpmZjpmZjpmZjpmZjpmZjpmZjpm
ZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZg0KWyAgICAyLjY2MDU5NV0g
YnVkZ2V0X2F2OiBLTkMxLTA6IE1BQyBhZGRyID0gMDA6MDk6ZDY6NmQ6YjM6MGENClsgICAg
Mi44MjkxNzJdIERWQjogcmVnaXN0ZXJpbmcgYWRhcHRlciAwIGZyb250ZW5kIDAgKFBoaWxp
cHMgVERBMTAwMjMgRFZCLUMpLi4uDQpbICAgIDIuODI5ODQ3XSBidWRnZXRfYXY6IGNpIGlu
dGVyZmFjZSBpbml0aWFsaXNlZA0KWyAgICAyLjgzMDM3MV0gYnVkZ2V0X2F2IDAwMDA6MDA6
MDEuMDogWGVuIFBDSSBtYXBwZWQgR1NJMTggdG8gSVJRMjkNClsgICAgMi44MzExOTBdIHNh
YTcxNDY6IGZvdW5kIHNhYTcxNDYgQCBtZW0gZmZmZmM5MDAwMDY5ODAwMCAocmV2aXNpb24g
MSwgaXJxIDI5KSAoMHgxODk0LDB4MDAyYykNClsgICAgMi44MzEyMTddIHNhYTcxNDYgKDEp
OiBkbWEgYnVmZmVyIHNpemUgMTM0NzU4NA0KWyAgICAyLjgzMTIzM10gRFZCOiByZWdpc3Rl
cmluZyBuZXcgYWRhcHRlciAoU2F0ZWxjbyBFYXN5V2F0Y2ggRFZCLUMgTUszKQ0KWyAgICAy
Ljg2NjAwOV0gYWRhcHRlciBmYWlsZWQgTUFDIHNpZ25hdHVyZSBjaGVjaw0KWyAgICAyLjg2
NjAzNl0gZW5jb2RlZCBNQUMgZnJvbSBFRVBST00gd2FzIGZmOmZmOmZmOmZmOmZmOmZmOmZm
OmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmOmZmDQpbICAgIDMuMTQwNzM2
XSBidWRnZXRfYXY6IEtOQzEtMTogTUFDIGFkZHIgPSAwMDowOTpkNjo2ZDpiMDozMw0KWyAg
ICAzLjI4MTE3MF0gRFZCOiByZWdpc3RlcmluZyBhZGFwdGVyIDEgZnJvbnRlbmQgMCAoUGhp
bGlwcyBUREExMDAyMyBEVkItQykuLi4NClsgICAgMy4yODM3OTBdIGJ1ZGdldF9hdjogY2kg
aW50ZXJmYWNlIGluaXRpYWxpc2VkDQpbICAgIDMuMjg0NTA3XSBidWRnZXRfYXYgMDAwMDow
MDowMi4wOiBYZW4gUENJIG1hcHBlZCBHU0kxOSB0byBJUlEzMA0KWyAgICAzLjI4NTEyNV0g
c2FhNzE0NjogZm91bmQgc2FhNzE0NiBAIG1lbSBmZmZmYzkwMDAwOTI2MDAwIChyZXZpc2lv
biAxLCBpcnEgMzApICgweDE4OTQsMHgwMDIyKQ0KWyAgICAzLjI4NTE1NV0gc2FhNzE0NiAo
Mik6IGRtYSBidWZmZXIgc2l6ZSAxMzQ3NTg0DQpbICAgIDMuMjg1MTcxXSBEVkI6IHJlZ2lz
dGVyaW5nIG5ldyBhZGFwdGVyIChLTkMxIERWQi1DIE1LMykNClsgICAgMy4zMjE0MzddIGFk
YXB0ZXIgZmFpbGVkIE1BQyBzaWduYXR1cmUgY2hlY2sNClsgICAgMy4zMjE0NjZdIGVuY29k
ZWQgTUFDIGZyb20gRUVQUk9NIHdhcyBmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpm
ZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZjpmZg0KWyAgICAzLjU5NjYwMl0gYnVkZ2V0X2F2
OiBLTkMxLTI6IE1BQyBhZGRyID0gMDA6MDk6ZDY6NmQ6NmQ6N2ENClsgICAgMy43MzcxNjZd
IERWQjogcmVnaXN0ZXJpbmcgYWRhcHRlciAyIGZyb250ZW5kIDAgKFBoaWxpcHMgVERBMTAw
MjMgRFZCLUMpLi4uDQpbICAgIDMuNzM3ODI2XSBidWRnZXRfYXY6IGNpIGludGVyZmFjZSBp
bml0aWFsaXNlZA0KZG9uZS4NCkFjdGl2YXRpbmcgc3dhcC4uLlsgICAgMy45NzczNDJdIEFk
ZGluZyAxMDQ4NTcyayBzd2FwIG9uIC9kZXYveHZkYTIuICBQcmlvcml0eTotMSBleHRlbnRz
OjEgYWNyb3NzOjEwNDg1NzJrIFNTDQpkb25lLg0KWyAgICAzLjk4NTY1N10gRVhUMy1mcyAo
eHZkYTEpOiB3YXJuaW5nOiBtYXhpbWFsIG1vdW50IGNvdW50IHJlYWNoZWQsIHJ1bm5pbmcg
ZTJmc2NrIGlzIHJlY29tbWVuZGVkDQpbICAgIDMuOTg2MDYxXSBFWFQzLWZzICh4dmRhMSk6
IHVzaW5nIGludGVybmFsIGpvdXJuYWwNCkxvYWRpbmcga2VybmVsIG1vZHVsZXMuLi5kb25l
Lg0KQ2xlYW5pbmcgdXAgaWZ1cGRvd24uLi4uDQpTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4u
DQpBY3RpdmF0aW5nIGx2bSBhbmQgbWQgc3dhcC4uLmRvbmUuDQpDaGVja2luZyBmaWxlIHN5
c3RlbXMuLi5mc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjINCmRvbmUuDQpNb3VudGlu
ZyBsb2NhbCBmaWxlc3lzdGVtcy4uLlsgICAgNC40Mjg1NDBdIGtqb3VybmFsZCBzdGFydGlu
Zy4gIENvbW1pdCBpbnRlcnZhbCA1IHNlY29uZHMNClsgICAgNC40Mjk2ODBdIEVYVDMtZnMg
KHh2ZGIxKTogd2FybmluZzogbWF4aW1hbCBtb3VudCBjb3VudCByZWFjaGVkLCBydW5uaW5n
IGUyZnNjayBpcyByZWNvbW1lbmRlZA0KWyAgICA0LjQzMjM3MF0gRVhUMy1mcyAoeHZkYjEp
OiB1c2luZyBpbnRlcm5hbCBqb3VybmFsDQpbICAgIDQuNDMyMzk5XSBFWFQzLWZzICh4dmRi
MSk6IHJlY292ZXJ5IGNvbXBsZXRlDQpbICAgIDQuNDMyNDE5XSBFWFQzLWZzICh4dmRiMSk6
IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlDQpkb25lLg0KQWN0
aXZhdGluZyBzd2FwZmlsZSBzd2FwLi4uZG9uZS4NCkNsZWFuaW5nIHVwIHRlbXBvcmFyeSBm
aWxlcy4uLi4NCkNvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJmYWNlcy4uLlNldHRpbmcga2Vy
bmVsIHZhcmlhYmxlcyAuLi5lcnJvcjogInhlbi5pbmRlcGVuZGVudF93YWxsY2xvY2siIGlz
IGFuIHVua25vd24ga2V5DQobWzMxbWZhaWxlZC4bWzM5OzQ5bQ0KZG9uZS4NClN0YXJ0aW5n
IHBvcnRtYXAgZGFlbW9uLi4uLg0KU3RhcnRpbmcgTkZTIGNvbW1vbiB1dGlsaXRpZXM6IHN0
YXRkWyAgICA1LjQ2OTgxN10gUlBDOiBSZWdpc3RlcmVkIG5hbWVkIFVOSVggc29ja2V0IHRy
YW5zcG9ydCBtb2R1bGUuDQpbICAgIDUuNDY5ODU0XSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRy
YW5zcG9ydCBtb2R1bGUuDQpbICAgIDUuNDY5ODcwXSBSUEM6IFJlZ2lzdGVyZWQgdGNwIHRy
YW5zcG9ydCBtb2R1bGUuDQpbICAgIDUuNDY5ODg0XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5G
U3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4NClsgICAgNS41MzU3ODddIEZT
LUNhY2hlOiBMb2FkZWQNClsgICAgNS41NjY1NDJdIEZTLUNhY2hlOiBOZXRmcyAnbmZzJyBy
ZWdpc3RlcmVkIGZvciBjYWNoaW5nDQpbICAgIDUuNjAxNzU5XSBJbnN0YWxsaW5nIGtuZnNk
IChjb3B5cmlnaHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLg0KIGlkbWFwZC4NCkNs
ZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4NClNldHRpbmcgY29uc29sZSBzY3JlZW4g
bW9kZXMgYW5kIGZvbnRzLg0KG11SY2Fubm90ICh1bilzZXQgcG93ZXJzYXZlIG1vZGUNChtb
OTszMF0bWzE0OzMwXQ1JTklUOiBFbnRlcmluZyBydW5sZXZlbDogMg0NClVzaW5nIG1ha2Vm
aWxlLXN0eWxlIGNvbmN1cnJlbnQgYm9vdCBpbiBydW5sZXZlbCAyLg0KU3RhcnRpbmcgcG9y
dG1hcCBkYWVtb24uLi5BbHJlYWR5IHJ1bm5pbmcuLg0KU3RhcnRpbmcgTkZTIGNvbW1vbiB1
dGlsaXRpZXM6IHN0YXRkIGlkbWFwZC4NClN0YXJ0aW5nIGVuaGFuY2VkIHN5c2xvZ2Q6IHJz
eXNsb2dkLg0KWyAgICA2LjUwMDgyM10gc3ZjOiBmYWlsZWQgdG8gcmVnaXN0ZXIgbG9ja2R2
MSBSUEMgc2VydmljZSAoZXJybm8gOTcpLg0KWyAgICA2LjUwNDM5OV0gTkZTRDogVXNpbmcg
L3Zhci9saWIvbmZzL3Y0cmVjb3ZlcnkgYXMgdGhlIE5GU3Y0IHN0YXRlIHJlY292ZXJ5IGRp
cmVjdG9yeQ0KWyAgICA2LjUyNjY4OF0gTkZTRDogc3RhcnRpbmcgOTAtc2Vjb25kIGdyYWNl
IHBlcmlvZA0KRXhwb3J0aW5nIGRpcmVjdG9yaWVzIGZvciBORlMga2VybmVsIGRhZW1vbi4u
Li4NClN0YXJ0aW5nIE5GUyBrZXJuZWwgZGFlbW9uOiBuZnNkIG1vdW50ZC4NClN0YXJ0aW5n
IHBlcmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLg0KU3RhcnRpbmcgc3lzdGVtIG1l
c3NhZ2UgYnVzOiBkYnVzLg0KU3RhcnRpbmcgTlRQIHNlcnZlcjogbnRwZC4NClN0YXJ0aW5n
IFNhbWJhIGRhZW1vbnM6IG5tYmQgc21iZC4NClN0YXJ0aW5nIE9wZW5CU0QgU2VjdXJlIFNo
ZWxsIHNlcnZlcjogc3NoZFsgICAgNy45NDE2NDldIHNzaGQgKDcwMyk6IC9wcm9jLzcwMy9v
b21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvNzAzL29vbV9zY29yZV9h
ZGogaW5zdGVhZC4NCi4NClN0YXJ0aW5nIExpbnV4IFZpZGVvIERpc2sgUmVjb3JkZXI6IHZk
cg0KU2VhcmNoaW5nIGZvciBwbHVnaW5zIChWRFIgMS43LjIxLzEuNy4yMSkgKGNhY2hlIGhp
dCk6dmRyYWRtaW4tYW06IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCiBlcGdzZWFyY2hv
bmx5IHh2ZHIgZXBnc2VhcmNoIHZvbXBzZXJ2ZXIgZmVtb24gcXVpY2tlcGdzZWFyY2ggY29u
ZmxpY3RjaGVja29ubHkgd2lyYmVsc2Nhbi4NClN0YXJ0aW5nIE11bmluLU5vZGU6IGRvbmUu
DQpzdGFydHBhcjogc2VydmljZShzKSByZXR1cm5lZCBmYWlsdXJlOiB2ZHJhZG1pbi1hbSAu
Li4gG1szMW1mYWlsZWQhG1szOTs0OW0NClsgICAxNC42NzQ4ODNdIEJVRzogdW5hYmxlIHRv
IGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQgZmZmZmM3ZmZmZmZmZjAwMA0KWyAg
IDE0LjY3NDkxMF0gSVA6IFs8ZmZmZmZmZmY4MTFiNGMwYj5dIHN3aW90bGJfYm91bmNlKzB4
MmUvMHgzMQ0KWyAgIDE0LjY3NDkzMF0gUEdEIDAgDQpbICAgMTQuNjc0OTQwXSBPb3BzOiAw
MDAyIFsjMV0gU01QIA0KWyAgIDE0LjY3NDk1Ml0gQ1BVIDAgDQpbICAgMTQuNjc0OTU3XSBN
b2R1bGVzIGxpbmtlZCBpbjogbmZzZCBleHBvcnRmcyBuZnMgbG9ja2QgZnNjYWNoZSBhdXRo
X3JwY2dzcyBuZnNfYWNsIHN1bnJwYyB0ZGExMDAyMyBidWRnZXRfYXYgZXZkZXYgc2FhNzE0
Nl92diB2aWRlb2RldiB2NGwyX2NvbXBhdF9pb2N0bDMyIHZpZGVvYnVmX2RtYV9zZyB2aWRl
b2J1Zl9jb3JlIGJ1ZGdldF9jb3JlIHNuZF9wY20gZHZiX2NvcmUgc25kX3RpbWVyIHNhYTcx
NDYgc25kIHR0cGNpX2VlcHJvbSBzb3VuZGNvcmUgc25kX3BhZ2VfYWxsb2MgaTJjX2NvcmUg
cGNzcGtyIGV4dDMgamJkIG1iY2FjaGUgeGVuX25ldGZyb250IHhlbl9ibGtmcm9udA0KWyAg
IDE0LjY3NTA1N10gDQpbICAgMTQuNjc1MDY1XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBO
b3QgdGFpbnRlZCAzLjIuOC1hbWQ2NCAjMSAgDQpbICAgMTQuNjc1MDc5XSBSSVA6IGUwMzA6
WzxmZmZmZmZmZjgxMWI0YzBiPl0gIFs8ZmZmZmZmZmY4MTFiNGMwYj5dIHN3aW90bGJfYm91
bmNlKzB4MmUvMHgzMQ0KWyAgIDE0LjY3NTA5N10gUlNQOiBlMDJiOmZmZmY4ODAwMTNmYWJl
NTggIEVGTEFHUzogMDAwMTAyMDINClsgICAxNC42NzUxMDZdIFJBWDogZmZmZjg4MDAxMjgw
MDAwMCBSQlg6IDAwMDAwMDAwMDAwMDAwMDEgUkNYOiAwMDAwMDAwMDAwMDAxMDAwDQpbICAg
MTQuNjc1MTE2XSBSRFg6IDAwMDAwMDAwMDAwMDEwMDAgUlNJOiBmZmZmODgwMDEyODAwMDAw
IFJESTogZmZmZmM3ZmZmZmZmZjAwMA0KWyAgIDE0LjY3NTEyNl0gUkJQOiAwMDAwMDAwMDAw
MDAwMDAyIFIwODogZmZmZmM3ZmZmZmZmZjAwMCBSMDk6IGZmZmY4ODAwMTNmOTgwMDANClsg
ICAxNC42NzUxMzddIFIxMDogMDAwMDAwMDAwMDAwMDAwMSBSMTE6IGZmZmY4ODAwMDMzNzYw
MDAgUjEyOiBmZmZmODgwMDAzMmM1MDkwDQpbICAgMTQuNjc1MTQ3XSBSMTM6IDAwMDAwMDAw
MDAwMDAxNDkgUjE0OiBmZmZmODgwMDAzM2UwMDAwIFIxNTogZmZmZmZmZmY4MTYwMWZkOA0K
WyAgIDE0LjY3NTE2M10gRlM6ICAwMDAwN2YzZmY5ODkzNzAwKDAwMDApIEdTOmZmZmY4ODAw
MTNmYTgwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMA0KWyAgIDE0LjY3NTE3NV0g
Q1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYg0KWyAg
IDE0LjY3NTE4NF0gQ1IyOiBmZmZmYzdmZmZmZmZmMDAwIENSMzogMDAwMDAwMDAxMjY4MzAw
MCBDUjQ6IDAwMDAwMDAwMDAwMDA2NjANClsgICAxNC42NzUxOTVdIERSMDogMDAwMDAwMDAw
MDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAwMDAwDQpb
ICAgMTQuNjc1MjA1XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYw
ZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMA0KWyAgIDE0LjY3NTIxNl0gUHJvY2VzcyBzd2Fw
cGVyLzAgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZmZjgxNjAwMDAwLCB0YXNrIGZmZmZm
ZmZmODE2MGQwMjApDQpbICAgMTQuNjc1MjI3XSBTdGFjazoNClsgICAxNC42NzUyMzJdICBm
ZmZmZmZmZjgxMjExODI2IGZmZmY4ODAwMDJlZGEwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZm
YzkwMDAwNDA4MDAwDQpbICAgMTQuNjc1MjUxXSAgMDAwMDAwMDAwMDBiMDE1MCAwMDAwMDAw
MDAwMDAwMDA2IGZmZmZmZmZmYTAxM2VjNGEgZmZmZmZmZmY4MTA5NDZjZA0KWyAgIDE0LjY3
NTI3MF0gIGZmZmZmZmZmODEwOTkyMDMgZmZmZjg4MDAwMzM3NjAwMCAwMDAwMDAwMDAwMDAw
MDAwIGZmZmY4ODAwMDJlZGE0YjANClsgICAxNC42NzUyODldIENhbGwgVHJhY2U6DQpbICAg
MTQuNjc1Mjk1XSAgPElSUT4gDQpbICAgMTQuNjc1MzA3XSAgWzxmZmZmZmZmZjgxMjExODI2
Pl0gPyB4ZW5fc3dpb3RsYl9zeW5jX3NnX2Zvcl9jcHUrMHgyZS8weDQ3DQpbICAgMTQuNjc1
MzIyXSAgWzxmZmZmZmZmZmEwMTNlYzRhPl0gPyB2cGVpcnErMHg3Zi8weDE5OCBbYnVkZ2V0
X2NvcmVdDQpbICAgMTQuNjc1MzM3XSAgWzxmZmZmZmZmZjgxMDk0NmNkPl0gPyBoYW5kbGVf
aXJxX2V2ZW50X3BlcmNwdSsweDE2Ni8weDE4NA0KWyAgIDE0LjY3NTM1MF0gIFs8ZmZmZmZm
ZmY4MTA5OTIwMz5dID8gX19yY3VfcHJvY2Vzc19jYWxsYmFja3MrMHg3MS8weDJmOA0KWyAg
IDE0LjY3NTM2NF0gIFs8ZmZmZmZmZmY4MTA0ZDE3NT5dID8gdGFza2xldF9hY3Rpb24rMHg3
Ni8weGM1DQpbICAgMTQuNjc1Mzc2XSAgWzxmZmZmZmZmZjgxMjBhOWFjPl0gPyBlb2lfcGly
cSsweDViLzB4NzcNClsgICAxNC42NzUzODhdICBbPGZmZmZmZmZmODEwNGNiYzY+XSA/IF9f
ZG9fc29mdGlycSsweGM0LzB4MWEwDQpbICAgMTQuNjc1NDAwXSAgWzxmZmZmZmZmZjgxMjBh
MDIyPl0gPyBfX3hlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MWM3LzB4MjA1DQpbICAgMTQuNjc1
NDEyXSAgWzxmZmZmZmZmZjgxMzRiMDZjPl0gPyBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpb
ICAgMTQuNjc1NDI1XSAgWzxmZmZmZmZmZjgxMDBmYTQ3Pl0gPyBkb19zb2Z0aXJxKzB4M2Yv
MHg3OQ0KWyAgIDE0LjY3NTQzNl0gIFs8ZmZmZmZmZmY4MTA0Yzk5Nj5dID8gaXJxX2V4aXQr
MHg0NC8weGI1DQpbICAgMTQuNjc1NDUyXSAgWzxmZmZmZmZmZjgxMjBiMDMyPl0gPyB4ZW5f
ZXZ0Y2huX2RvX3VwY2FsbCsweDI3LzB4MzINClsgICAxNC42NzU0NjRdICBbPGZmZmZmZmZm
ODEzNGIwYmU+XSA/IHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAg
IDE0LjY3NTQ3M10gIDxFT0k+IA0KWyAgIDE0LjY3NTQ4NF0gIFs8ZmZmZmZmZmY4MTAwNzM2
Zj5dID8geGVuX3Jlc3RvcmVfZmxfZGlyZWN0X3JlbG9jKzB4NC8weDQNClsgICAxNC42NzU0
OTZdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IGh5cGVyY2FsbF9wYWdlKzB4M2FhLzB4MTAw
MA0KWyAgIDE0LjY3NTUwN10gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8gaHlwZXJjYWxsX3Bh
Z2UrMHgzYWEvMHgxMDAwDQpbICAgMTQuNjc1NTIxXSAgWzxmZmZmZmZmZjgxMjZhZTE3Pl0g
PyBjcHVpZGxlX2lkbGVfY2FsbCsweDE2LzB4MWFmDQpbICAgMTQuNjc1NTMzXSAgWzxmZmZm
ZmZmZjgxMDA2ZDE0Pl0gPyB4ZW5fc2FmZV9oYWx0KzB4Yy8weDE1DQpbICAgMTQuNjc1NTQ1
XSAgWzxmZmZmZmZmZjgxMDE1MGEyPl0gPyBkZWZhdWx0X2lkbGUrMHg0Yi8weDg0DQpbICAg
MTQuNjc1NTU2XSAgWzxmZmZmZmZmZjgxMDBkZGY2Pl0gPyBjcHVfaWRsZSsweGI5LzB4ZWYN
ClsgICAxNC42NzU1NjhdICBbPGZmZmZmZmZmODE2OWFiZmY+XSA/IHN0YXJ0X2tlcm5lbCsw
eDM5NS8weDNhMA0KWyAgIDE0LjY3NTU4MF0gIFs8ZmZmZmZmZmY4MTY5YzhhNT5dID8geGVu
X3N0YXJ0X2tlcm5lbCsweDU5My8weDU5OA0KWyAgIDE0LjY3NTU4OV0gQ29kZTogODkgZjAg
NzUgMTMgNDggYmUgMDAgMDAgMDAgMDAgMDAgODggZmYgZmYgNDggOGQgMzQgMzcgNDggODkg
YzcgZWIgMTEgNDkgYjggMDAgMDAgMDAgMDAgMDAgODggZmYgZmYgNGUgOGQgMDQgMDcgNGMg
ODkgYzcgNDggODkgZDEgPGYzPiBhNCBjMyA0OCA4OSBmMCA0OCAyYiAwNSA3MCA5NiA2MiAw
MCA0YyA4YiAwZCA5OSA5NiA2MiAwMCA0OCANClsgICAxNC42NzU3MzVdIFJJUCAgWzxmZmZm
ZmZmZjgxMWI0YzBiPl0gc3dpb3RsYl9ib3VuY2UrMHgyZS8weDMxDQpbICAgMTQuNjc1NzQ4
XSAgUlNQIDxmZmZmODgwMDEzZmFiZTU4Pg0KWyAgIDE0LjY3NTc1NV0gQ1IyOiBmZmZmYzdm
ZmZmZmZmMDAwDQpbICAgMTQuNjc1NzY1XSAtLS1bIGVuZCB0cmFjZSA2Mjg4NzIyZmU5MTkw
OGNkIF0tLS0NClsgICAxNC42NzU3NzRdIEtlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBG
YXRhbCBleGNlcHRpb24gaW4gaW50ZXJydXB0DQpbICAgMTQuNjc1Nzg0XSBQaWQ6IDAsIGNv
bW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgRCAgICAgIDMuMi44LWFtZDY0ICMxDQpb
ICAgMTQuNjc1NzkzXSBDYWxsIFRyYWNlOg0KWyAgIDE0LjY3NTc5OV0gIDxJUlE+ICBbPGZm
ZmZmZmZmODEzNDBiYWM+XSA/IHBhbmljKzB4OTIvMHgxYTANClsgICAxNC42NzU4MTddICBb
PGZmZmZmZmZmODEwNDc5Njg+XSA/IGttc2dfZHVtcCsweDQxLzB4ZGQNClsgICAxNC42NzU4
MjhdICBbPGZmZmZmZmZmODEzNDM4NDE+XSA/IG9vcHNfZW5kKzB4YTkvMHhiNg0KWyAgIDE0
LjY3NTgzOV0gIFs8ZmZmZmZmZmY4MTAyZWM3NT5dID8gbm9fY29udGV4dCsweDFmZi8weDIw
Yw0KWyAgIDE0LjY3NTg1Ml0gIFs8ZmZmZmZmZmY4MTA0M2JmYT5dID8gdHJ5X3RvX3dha2Vf
dXArMHgxODEvMHgxOTENClsgICAxNC42NzU4NjNdICBbPGZmZmZmZmZmODEzNDU5MWQ+XSA/
IGRvX3BhZ2VfZmF1bHQrMHgxYWQvMHgzNGMNClsgICAxNC42NzU4NzVdICBbPGZmZmZmZmZm
ODEwMmMxMjI+XSA/IHB2Y2xvY2tfY2xvY2tzb3VyY2VfcmVhZCsweDQ2LzB4YjQNClsgICAx
NC42NzU4ODhdICBbPGZmZmZmZmZmODEwYjc2YzY+XSA/IHBlcmZfZXZlbnRfdGFza190aWNr
KzB4MjUvMHgyM2ENClsgICAxNC42NzU5MDFdICBbPGZmZmZmZmZmODEwNjMxYjg+XSA/IHJ1
bl9wb3NpeF9jcHVfdGltZXJzKzB4MjcvMHg2MWINClsgICAxNC42NzU5MTNdICBbPGZmZmZm
ZmZmODEwNmRmN2I+XSA/IHRpY2tfbm9oel9oYW5kbGVyKzB4Y2IvMHhjYg0KWyAgIDE0LjY3
NTkyNV0gIFs8ZmZmZmZmZmY4MTAxMzk2ZD5dID8gc2NoZWRfY2xvY2srMHg1LzB4OA0KWyAg
IDE0LjY3NTkzNl0gIFs8ZmZmZmZmZmY4MTAyYzEyMj5dID8gcHZjbG9ja19jbG9ja3NvdXJj
ZV9yZWFkKzB4NDYvMHhiNA0KWyAgIDE0LjY3NTk0OF0gIFs8ZmZmZmZmZmY4MTM0MmYzNT5d
ID8gcGFnZV9mYXVsdCsweDI1LzB4MzANClsgICAxNC42NzU5NTldICBbPGZmZmZmZmZmODEx
YjRjMGI+XSA/IHN3aW90bGJfYm91bmNlKzB4MmUvMHgzMQ0KWyAgIDE0LjY3NTk3MV0gIFs8
ZmZmZmZmZmY4MTIxMTgyNj5dID8geGVuX3N3aW90bGJfc3luY19zZ19mb3JfY3B1KzB4MmUv
MHg0Nw0KWyAgIDE0LjY3NTk4NV0gIFs8ZmZmZmZmZmZhMDEzZWM0YT5dID8gdnBlaXJxKzB4
N2YvMHgxOTggW2J1ZGdldF9jb3JlXQ0KWyAgIDE0LjY3NTk5N10gIFs8ZmZmZmZmZmY4MTA5
NDZjZD5dID8gaGFuZGxlX2lycV9ldmVudF9wZXJjcHUrMHgxNjYvMHgxODQNClsgICAxNC42
NzYwMDldICBbPGZmZmZmZmZmODEwOTkyMDM+XSA/IF9fcmN1X3Byb2Nlc3NfY2FsbGJhY2tz
KzB4NzEvMHgyZjgNClsgICAxNC42NzYwMjJdICBbPGZmZmZmZmZmODEwNGQxNzU+XSA/IHRh
c2tsZXRfYWN0aW9uKzB4NzYvMHhjNQ0KWyAgIDE0LjY3NjAzM10gIFs8ZmZmZmZmZmY4MTIw
YTlhYz5dID8gZW9pX3BpcnErMHg1Yi8weDc3DQpbICAgMTQuNjc2MDQ0XSAgWzxmZmZmZmZm
ZjgxMDRjYmM2Pl0gPyBfX2RvX3NvZnRpcnErMHhjNC8weDFhMA0KWyAgIDE0LjY3NjA1OV0g
IFs8ZmZmZmZmZmY4MTIwYTAyMj5dID8gX194ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDFjNy8w
eDIwNQ0KWyAgIDE0LjY3NjA3Ml0gIFs8ZmZmZmZmZmY4MTM0YjA2Yz5dID8gY2FsbF9zb2Z0
aXJxKzB4MWMvMHgzMA0KWyAgIDE0LjY3NjA4M10gIFs8ZmZmZmZmZmY4MTAwZmE0Nz5dID8g
ZG9fc29mdGlycSsweDNmLzB4NzkNClsgICAxNC42NzYwOTRdICBbPGZmZmZmZmZmODEwNGM5
OTY+XSA/IGlycV9leGl0KzB4NDQvMHhiNQ0KWyAgIDE0LjY3NjEwNl0gIFs8ZmZmZmZmZmY4
MTIwYjAzMj5dID8geGVuX2V2dGNobl9kb191cGNhbGwrMHgyNy8weDMyDQpbICAgMTQuNjc2
MTIwXSAgWzxmZmZmZmZmZjgxMzRiMGJlPl0gPyB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFj
aysweDFlLzB4MzANClsgICAxNC42NzYxMjldICA8RU9JPiAgWzxmZmZmZmZmZjgxMDA3MzZm
Pl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NA0KWyAgIDE0LjY3NjE0
OV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8gaHlwZXJjYWxsX3BhZ2UrMHgzYWEvMHgxMDAw
DQpbICAgMTQuNjc2MTYwXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyBoeXBlcmNhbGxfcGFn
ZSsweDNhYS8weDEwMDANClsgICAxNC42NzYxNzJdICBbPGZmZmZmZmZmODEyNmFlMTc+XSA/
IGNwdWlkbGVfaWRsZV9jYWxsKzB4MTYvMHgxYWYNClsgICAxNC42NzYxODRdICBbPGZmZmZm
ZmZmODEwMDZkMTQ+XSA/IHhlbl9zYWZlX2hhbHQrMHhjLzB4MTUNClsgICAxNC42NzYxOTVd
ICBbPGZmZmZmZmZmODEwMTUwYTI+XSA/IGRlZmF1bHRfaWRsZSsweDRiLzB4ODQNClsgICAx
NC42NzYyMDZdICBbPGZmZmZmZmZmODEwMGRkZjY+XSA/IGNwdV9pZGxlKzB4YjkvMHhlZg0K
WyAgIDE0LjY3NjIxN10gIFs8ZmZmZmZmZmY4MTY5YWJmZj5dID8gc3RhcnRfa2VybmVsKzB4
Mzk1LzB4M2EwDQpbICAgMTQuNjc2MjI5XSAgWzxmZmZmZmZmZjgxNjljOGE1Pl0gPyB4ZW5f
c3RhcnRfa2VybmVsKzB4NTkzLzB4NTk4DQo=
--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=_F1yjpLocfe5Ra5tK65RmHGcdd2qVYzUzBxBqAXkQZGBAcVOw--



From xen-devel-bounces@lists.xen.org Wed Feb 29 12:59:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2j89-0002tR-Ey; Wed, 29 Feb 2012 12:59:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S2j87-0002tJ-AM
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:59:39 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330520322!51322636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29213 invoked from network); 29 Feb 2012 12:58:42 -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;
	29 Feb 2012 12:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11008958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:59:38 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 12:59:38 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3c10ba854d375075010069931e09bbf9320a9f00
Message-ID: <3c10ba854d3750750100.1330520427@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 29 Feb 2012 13:00:27 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify the
	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Differences with previous revision:
- Improvements to the manpage:
  * s/operated/made
  * s/compatbile/compatible
  * New paragraph for rombios, provided by Ian
  * s/force/request
  * redundant line removal in UEFI explanatory
  * Wrap of lines at 80 cols

diff -r adcd6ab160fa -r 3c10ba854d37 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
+++ b/docs/man/xl.cfg.pod.5	Wed Feb 29 13:00:06 2012 +0000
@@ -430,6 +430,33 @@ accept the defaults for these options wh
 
 =over 4
 
+=item B<bios="STRING">
+
+Select the virtual firmware that is exposed to the guest.
+By default, a guess is made based on the device model, but sometimes
+it may be useful to request a different one, like UEFI.
+
+=over 4
+
+=item B<rombios>
+
+Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default
+when device_model_version=qemu-xen-traditional. This is the only BIOS
+option supported when device_model_version=qemu-xen-traditional. This is
+the BIOS used by all previous Xen versions.
+
+=item B<seabios>
+
+Loads SeaBIOS, a 16-bit x86 compatible BIOS. This is used by default
+with device_model_version=qemu-xen.
+
+=item B<ovmf>
+
+Loads OVMF, a standard UEFI firmware by Tianocore project.
+Requires device_model_version=qemu-xen.
+
+=back
+
 =item B<pae=BOOLEAN>
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Feb 29 13:00:06 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = 0;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Feb 29 13:00:06 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return libxl_bios_type_to_string(info->u.hvm.bios);
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 29 13:00:06 2012 +0000
@@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+libxl_bios_type = Enumeration("bios_type", [
+    (1, "rombios"),
+    (2, "seabios"),
+    (3, "ovmf"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", libxl_bios_type),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 29 13:00:06 2012 +0000
@@ -704,6 +704,12 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
+            libxl_bios_type_from_string(buf, &b_info->u.hvm.bios)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
+                    buf);
+                exit (1);
+        }
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 12:59:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 12: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 1S2j89-0002tR-Ey; Wed, 29 Feb 2012 12:59:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S2j87-0002tJ-AM
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 12:59:39 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330520322!51322636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29213 invoked from network); 29 Feb 2012 12:58:42 -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;
	29 Feb 2012 12:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11008958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 12:59:38 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 12:59:38 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3c10ba854d375075010069931e09bbf9320a9f00
Message-ID: <3c10ba854d3750750100.1330520427@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 29 Feb 2012 13:00:27 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify the
	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---

Differences with previous revision:
- Improvements to the manpage:
  * s/operated/made
  * s/compatbile/compatible
  * New paragraph for rombios, provided by Ian
  * s/force/request
  * redundant line removal in UEFI explanatory
  * Wrap of lines at 80 cols

diff -r adcd6ab160fa -r 3c10ba854d37 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Feb 23 10:29:27 2012 +0000
+++ b/docs/man/xl.cfg.pod.5	Wed Feb 29 13:00:06 2012 +0000
@@ -430,6 +430,33 @@ accept the defaults for these options wh
 
 =over 4
 
+=item B<bios="STRING">
+
+Select the virtual firmware that is exposed to the guest.
+By default, a guess is made based on the device model, but sometimes
+it may be useful to request a different one, like UEFI.
+
+=over 4
+
+=item B<rombios>
+
+Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default
+when device_model_version=qemu-xen-traditional. This is the only BIOS
+option supported when device_model_version=qemu-xen-traditional. This is
+the BIOS used by all previous Xen versions.
+
+=item B<seabios>
+
+Loads SeaBIOS, a 16-bit x86 compatible BIOS. This is used by default
+with device_model_version=qemu-xen.
+
+=item B<ovmf>
+
+Loads OVMF, a standard UEFI firmware by Tianocore project.
+Requires device_model_version=qemu-xen.
+
+=back
+
 =item B<pae=BOOLEAN>
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Feb 29 13:00:06 2012 +0000
@@ -89,6 +89,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
+        b_info->u.hvm.bios = 0;
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Feb 29 13:00:06 2012 +0000
@@ -66,6 +66,8 @@ const char *libxl__domain_device_model(l
 static const char *libxl__domain_bios(libxl__gc *gc,
                                 const libxl_domain_build_info *info)
 {
+    if (info->u.hvm.bios)
+       return libxl_bios_type_to_string(info->u.hvm.bios);
     switch (info->device_model_version) {
     case 1: return "rombios";
     case 2: return "seabios";
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Feb 29 13:00:06 2012 +0000
@@ -99,6 +99,12 @@ libxl_timer_mode = Enumeration("timer_mo
     (3, "one_missed_tick_pending"),
     ])
 
+libxl_bios_type = Enumeration("bios_type", [
+    (1, "rombios"),
+    (2, "seabios"),
+    (3, "ovmf"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -228,6 +234,7 @@ libxl_domain_build_info = Struct("domain
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
+                                       ("bios", libxl_bios_type),
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
diff -r adcd6ab160fa -r 3c10ba854d37 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Feb 23 10:29:27 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 29 13:00:06 2012 +0000
@@ -704,6 +704,12 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_string(config, "bios", &buf, 0) &&
+            libxl_bios_type_from_string(buf, &b_info->u.hvm.bios)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"bios\"\n",
+                    buf);
+                exit (1);
+        }
         if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
         if (!xlu_cfg_get_long (config, "apic", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:06:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jE1-00035u-97; Wed, 29 Feb 2012 13:05: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 1S2jDz-00035o-2e
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:05:43 +0000
Received: from [85.158.139.83:7054] by server-4.bemta-5.messagelabs.com id
	5A/AB-10788-6A22E4F4; Wed, 29 Feb 2012 13:05:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330520741!17234895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14707 invoked from network); 29 Feb 2012 13:05:41 -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;
	29 Feb 2012 13:05:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11009158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 13:05:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 13:05:41 +0000
Message-ID: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 29 Feb 2012 13:05:38 +0000
In-Reply-To: <1330519499118-5524861.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDEyOjQ0ICswMDAwLCBGYW50dSB3cm90ZToKPiBJYW4gQ2Ft
cGJlbGwtMTAgd3JvdGUKPiA+IAo+ID4gVGhhdCBzaG91bGQgYmUgcG9zc2libGUsIGJ1dCB5b3Ug
aGF2ZW4ndCBzaG93biB5b3VyIGNvZGUgc28gSSBjYW4ndCBzYXkKPiA+IHdoZXJlIHlvdSBoYXZl
IGdvbmUgd3JvbmcuCj4gPiAKPiA+IFdoYXQgSSBvZnRlbiBkbyBpcyBjcmVhdGUgcWVtdS1kZWJ1
Zy5zaDoKPiA+IAkjIS9iaW4vc2gKPiA+IAllY2hvICJTdGFydGluZyBRRU1VIHdpdGg6ICQqIiA+
PiAvdG1wL3FlbXUtZGJnLmxvZwo+ID4gCWV4ZWMgL3Vzci9saWIveGVuL2Jpbi9xZW11LXN5c3Rl
bS1pMzg2ICRACj4gPiAKPiA+IEFuZCB0aGVuIHVzaW5nIGRldmljZV9tb2RlbF9vdmVycmlkZSB0
byBjYWxsIHRoaXMgaW5zdGVhZCBvZiBjYWxsaW5nCj4gPiBxZW11IGRpcmVjdGx5Lgo+ID4gCj4g
Cj4gVGhhbmtzIGZvciByZXBseQo+IAo+IFF4bCBncmFwaGljIGlzIG5lZWRlZCBmb3IgbWFueSB0
aGluZ3Mgd2l0aCBzcGljZSwgSSBzdGFydCB0byB0cnkgYWRkIGl0Cj4gZm9sbG93aW5nIHRoaXM6
IGh0dHA6Ly9zcGljZS1zcGFjZS5vcmcvZG9jcy9zcGljZV91c2VyX21hbnVhbC5wZGYKPiAKPiBP
biBsaWJ4bF9kbS5jIGFkZCB0aGlzIGxpbmU6Cj4gZmxleGFycmF5X2FwcGVuZChkbV9hcmdzLCAi
LXF4bCAxIik7CgpEb2Vzbid0IHRoaXMgbmVlZCB0byBiZSBmbGV4YXJyYXlfYXBwZW5kX3BhaXIo
ZG1fYXJncywgIi1xeGwiLCAiMSIpIG9yCmVsc2UgdGhlIGFjdHVhbCBhcmd1bWVudCB3aWxsIGJl
IGxpdGVyYWxseSAiLXF4bCAxIj8KCihwcm9iYWJseSB0aGUgYmFkIHF1b3RpbmcgaW4gdGhlIGV4
YW1wbGUgSSBnYXZlIGhhcyBsZWFkIHRvIHRoZQpxZW11LWRlYnVnLnNoICJjb3JyZWN0aW5nIiB0
aGlzIGZvciB5b3UuIEkgdGhpbmsgSSBzaG91bGQgaGF2ZSBzYWlkCmVpdGhlciAKCWV4ZWMgL3Vz
ci9saWIveGVuL2Jpbi9xZW11LXN5c3RlbS1pMzg2ICIkQCIKb3IKCWV4ZWMgL3Vzci9saWIveGVu
L2Jpbi9xZW11LXN5c3RlbS1pMzg2ICIkKiIKKEkgY2FuIG5ldmVyIHJlbWVtYmVyIHdoaWNoIGlz
IGNvcnJlY3QpCgo+IGJlZm9yZSB0aGlzOgo+IGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1z
cGljZSIpOwo+IAo+IFdpdGggZG0gb3ZlcnJpZGUgZ2l2ZToKPiBTdGFydGluZyBRRU1VIHdpdGg6
IC14ZW4tZG9taWQgMjIgLWNoYXJkZXYKPiBzb2NrZXQsaWQ9bGlieGwtY21kLHBhdGg9L3Zhci9y
dW4veGVuL3FtcC1saWJ4bC0yMixzZXJ2ZXIsbm93YWl0IC1tb24KPiBjaGFyZGV2PWxpYnhsLWNt
ZCxtb2RlPWNvbnRyb2wgLW5hbWUgUFJFQ0lTRUhWTSAtdm5jIDEyNy4wLjAuMTowLHRvPTk5IC1x
eGwKPiAxIC1zcGljZSBwb3J0PTYwMDAsdGxzLXBvcnQ9MCxhZGRyPTAuMC4wLjAscGFzc3dvcmQ9
dGVzdCxhZ2VudC1tb3VzZT1vbgo+IC1ib290IG9yZGVyPWMgLXNtcCAyLG1heGNwdXM9MyAtZGV2
aWNlCj4gcnRsODEzOSxpZD1uaWMwLG5ldGRldj1uZXQwLG1hYz0wMDoxNjozZTo2Yjo4MTo4OSAt
bmV0ZGV2Cj4gdHlwZT10YXAsaWQ9bmV0MCxpZm5hbWU9dGFwMjIuMCxzY3JpcHQ9bm8gLU0geGVu
ZnYgLW0gMTAyNCAtZHJpdmUKPiBmaWxlPS9tbnQvdm0vZGlza3MvUFJFQ0lTRUhWTS5kaXNrMS54
bSxpZj1pZGUsaW5kZXg9MCxtZWRpYT1kaXNrLGZvcm1hdD1yYXcKPiAtZHJpdmUgZmlsZT0vZGV2
L3NyMCxpZj1pZGUsaW5kZXg9MSxtZWRpYT1jZHJvbSxmb3JtYXQ9cmF3Cj4gCj4gQW5kIG9uIC92
YXIvbG9nL3hlbi9xZW11LWRtLVBSRUNJU0VIVk0ubG9nOgo+IHFlbXUtc3lzdGVtLWkzODY6IC1x
eGw6IGludmFsaWQgb3B0aW9uCj4gCj4gVGhlcmUgaXNuJ3Qgb3RoZXIgLXZnYSBvciAtbm9ncmFw
aGljIG9wdGlvbnMsIEkgbm90IHVuZGVzdGFuZCB0aGUgcHJvYmxlbSwKPiB3aXRob3V0IHF4bCB3
b3JrIGJ1dCBvbiBzcGljZSBjb25uZWN0IGFuZCBsb2FkIHNlZSB0aGUgY2lycnVzIHZpZGVvIGNh
cmQsCj4gdmlkZW8gcGVyZm9ybWFuY2UgaXMgbm90IGdvb2QgYW5kIGlzIGltcG9zc2libGUgcmVz
aXplIHJlc29sdXRpb24sIHF4bAo+IGdyYXBoaWMgaXMgbmVlZGVkLgo+IEkgaGF2ZSBhbHNvIHRy
eSAtdmdhIHF4bCBidXQgc2FtZSBwcm9ibGVtLgoKWW91IGhhdmUgdHJpZWQgdHdvIGRpZmZlcmVu
dCBzeW50YXhlcyBoZXJlLCB3aGljaCBvbmUgaXMgdGhlIGNvcnJlY3QKcWVtdSBjb21tYW5kIGxp
bmUgc3ludGF4PwoKSSB0aGluayB5b3UgbmVlZCB0byBjb25zdWx0IHRoZSBxZW11IGRvY3VtZW50
YXRpb24gdG8gZGV0ZXJtaW5lIHdoYXQgdGhlCmNvcnJlY3QgY29tbWFuZCBsaW5lIHN5bnRheCBp
cyBzdXBwb3NlZCB0byBiZS4gCgpQZXJoYXBzIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBnZXQgdGhp
cyB3b3JraW5nIHdpdGggYSBub3JtYWwgcWVtdSAoZS5nLgplbXVsYXRlZCBndWVzdCkgcHJvY2Vz
cyBiZWZvcmUgdHJ5aW5nIHRvIG1ha2UgaXQgd29yayB3aXRoIFhlbj8KCj4gQmVmb3JlIGkgdHJ5
IHRvIGFkZCBwZXJtYW50IGRtX2FyZ3MgZGVidWcgb24gbG9nIHdpdGg6Cj4gT24gbGlieGxfZG0u
YyBhZGQgdGhpcyBsaW5lOgo+IExJQlhMX19MT0coY3R4LCBMSUJYTF9fTE9HX0RFQlVHLCAiZG1f
YXJnczogIiwgZmxleGFycmF5X2NvbnRlbnRzKGRtX2FyZ3MpCj4gKTsKCmZsZXhhcnJheV9jb250
ZW50cyByZXR1cm5zIGEgImNoYXIgKioiIC0tIHlvdSB3b3VsZCBuZWVkIHRvIGxvb3Agb3Zlcgp0
aGF0IGFycmF5IHByaW50aW5nIGVhY2ggZWxlbWVudCBpbiB0dXJuIHVudGlsIHlvdSBmaW5kIE5V
TEwuCgo+IGJlZm9yZSB0aGlzOgo+IHJldHVybiAoY2hhciAqKikgZmxleGFycmF5X2NvbnRlbnRz
KGRtX2FyZ3MpOwo+IAo+IFNob3c6Cj4gbGlieGxfZG0uYzogSW4gZnVuY3Rpb24gw6JsaWJ4bF9f
YnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3w6I6Cj4gbGlieGxfZG0uYzo1ODI6MjogZXJyb3I6
IHRvbyBtYW55IGFyZ3VtZW50cyBmb3IgZm9ybWF0Cj4gWy1XZXJyb3I9Zm9ybWF0LWV4dHJhLWFy
Z3NdCj4gY2MxOiBhbGwgd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKPiAKPiAKPiAK
PiAtLQo+IFZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4uMTA0NTcxMi5u
NS5uYWJibGUuY29tL05lZWQtaGVscC13aXRoLXFlbXUtYXJncy1kZWJ1Zy10cDU1MjQ2ODlwNTUy
NDg2MS5odG1sCj4gU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUg
YXQgTmFiYmxlLmNvbS4KPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:06:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:06:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jE1-00035u-97; Wed, 29 Feb 2012 13:05: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 1S2jDz-00035o-2e
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:05:43 +0000
Received: from [85.158.139.83:7054] by server-4.bemta-5.messagelabs.com id
	5A/AB-10788-6A22E4F4; Wed, 29 Feb 2012 13:05:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330520741!17234895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14707 invoked from network); 29 Feb 2012 13:05:41 -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;
	29 Feb 2012 13:05:41 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11009158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 13:05:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 13:05:41 +0000
Message-ID: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 29 Feb 2012 13:05:38 +0000
In-Reply-To: <1330519499118-5524861.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDEyOjQ0ICswMDAwLCBGYW50dSB3cm90ZToKPiBJYW4gQ2Ft
cGJlbGwtMTAgd3JvdGUKPiA+IAo+ID4gVGhhdCBzaG91bGQgYmUgcG9zc2libGUsIGJ1dCB5b3Ug
aGF2ZW4ndCBzaG93biB5b3VyIGNvZGUgc28gSSBjYW4ndCBzYXkKPiA+IHdoZXJlIHlvdSBoYXZl
IGdvbmUgd3JvbmcuCj4gPiAKPiA+IFdoYXQgSSBvZnRlbiBkbyBpcyBjcmVhdGUgcWVtdS1kZWJ1
Zy5zaDoKPiA+IAkjIS9iaW4vc2gKPiA+IAllY2hvICJTdGFydGluZyBRRU1VIHdpdGg6ICQqIiA+
PiAvdG1wL3FlbXUtZGJnLmxvZwo+ID4gCWV4ZWMgL3Vzci9saWIveGVuL2Jpbi9xZW11LXN5c3Rl
bS1pMzg2ICRACj4gPiAKPiA+IEFuZCB0aGVuIHVzaW5nIGRldmljZV9tb2RlbF9vdmVycmlkZSB0
byBjYWxsIHRoaXMgaW5zdGVhZCBvZiBjYWxsaW5nCj4gPiBxZW11IGRpcmVjdGx5Lgo+ID4gCj4g
Cj4gVGhhbmtzIGZvciByZXBseQo+IAo+IFF4bCBncmFwaGljIGlzIG5lZWRlZCBmb3IgbWFueSB0
aGluZ3Mgd2l0aCBzcGljZSwgSSBzdGFydCB0byB0cnkgYWRkIGl0Cj4gZm9sbG93aW5nIHRoaXM6
IGh0dHA6Ly9zcGljZS1zcGFjZS5vcmcvZG9jcy9zcGljZV91c2VyX21hbnVhbC5wZGYKPiAKPiBP
biBsaWJ4bF9kbS5jIGFkZCB0aGlzIGxpbmU6Cj4gZmxleGFycmF5X2FwcGVuZChkbV9hcmdzLCAi
LXF4bCAxIik7CgpEb2Vzbid0IHRoaXMgbmVlZCB0byBiZSBmbGV4YXJyYXlfYXBwZW5kX3BhaXIo
ZG1fYXJncywgIi1xeGwiLCAiMSIpIG9yCmVsc2UgdGhlIGFjdHVhbCBhcmd1bWVudCB3aWxsIGJl
IGxpdGVyYWxseSAiLXF4bCAxIj8KCihwcm9iYWJseSB0aGUgYmFkIHF1b3RpbmcgaW4gdGhlIGV4
YW1wbGUgSSBnYXZlIGhhcyBsZWFkIHRvIHRoZQpxZW11LWRlYnVnLnNoICJjb3JyZWN0aW5nIiB0
aGlzIGZvciB5b3UuIEkgdGhpbmsgSSBzaG91bGQgaGF2ZSBzYWlkCmVpdGhlciAKCWV4ZWMgL3Vz
ci9saWIveGVuL2Jpbi9xZW11LXN5c3RlbS1pMzg2ICIkQCIKb3IKCWV4ZWMgL3Vzci9saWIveGVu
L2Jpbi9xZW11LXN5c3RlbS1pMzg2ICIkKiIKKEkgY2FuIG5ldmVyIHJlbWVtYmVyIHdoaWNoIGlz
IGNvcnJlY3QpCgo+IGJlZm9yZSB0aGlzOgo+IGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1z
cGljZSIpOwo+IAo+IFdpdGggZG0gb3ZlcnJpZGUgZ2l2ZToKPiBTdGFydGluZyBRRU1VIHdpdGg6
IC14ZW4tZG9taWQgMjIgLWNoYXJkZXYKPiBzb2NrZXQsaWQ9bGlieGwtY21kLHBhdGg9L3Zhci9y
dW4veGVuL3FtcC1saWJ4bC0yMixzZXJ2ZXIsbm93YWl0IC1tb24KPiBjaGFyZGV2PWxpYnhsLWNt
ZCxtb2RlPWNvbnRyb2wgLW5hbWUgUFJFQ0lTRUhWTSAtdm5jIDEyNy4wLjAuMTowLHRvPTk5IC1x
eGwKPiAxIC1zcGljZSBwb3J0PTYwMDAsdGxzLXBvcnQ9MCxhZGRyPTAuMC4wLjAscGFzc3dvcmQ9
dGVzdCxhZ2VudC1tb3VzZT1vbgo+IC1ib290IG9yZGVyPWMgLXNtcCAyLG1heGNwdXM9MyAtZGV2
aWNlCj4gcnRsODEzOSxpZD1uaWMwLG5ldGRldj1uZXQwLG1hYz0wMDoxNjozZTo2Yjo4MTo4OSAt
bmV0ZGV2Cj4gdHlwZT10YXAsaWQ9bmV0MCxpZm5hbWU9dGFwMjIuMCxzY3JpcHQ9bm8gLU0geGVu
ZnYgLW0gMTAyNCAtZHJpdmUKPiBmaWxlPS9tbnQvdm0vZGlza3MvUFJFQ0lTRUhWTS5kaXNrMS54
bSxpZj1pZGUsaW5kZXg9MCxtZWRpYT1kaXNrLGZvcm1hdD1yYXcKPiAtZHJpdmUgZmlsZT0vZGV2
L3NyMCxpZj1pZGUsaW5kZXg9MSxtZWRpYT1jZHJvbSxmb3JtYXQ9cmF3Cj4gCj4gQW5kIG9uIC92
YXIvbG9nL3hlbi9xZW11LWRtLVBSRUNJU0VIVk0ubG9nOgo+IHFlbXUtc3lzdGVtLWkzODY6IC1x
eGw6IGludmFsaWQgb3B0aW9uCj4gCj4gVGhlcmUgaXNuJ3Qgb3RoZXIgLXZnYSBvciAtbm9ncmFw
aGljIG9wdGlvbnMsIEkgbm90IHVuZGVzdGFuZCB0aGUgcHJvYmxlbSwKPiB3aXRob3V0IHF4bCB3
b3JrIGJ1dCBvbiBzcGljZSBjb25uZWN0IGFuZCBsb2FkIHNlZSB0aGUgY2lycnVzIHZpZGVvIGNh
cmQsCj4gdmlkZW8gcGVyZm9ybWFuY2UgaXMgbm90IGdvb2QgYW5kIGlzIGltcG9zc2libGUgcmVz
aXplIHJlc29sdXRpb24sIHF4bAo+IGdyYXBoaWMgaXMgbmVlZGVkLgo+IEkgaGF2ZSBhbHNvIHRy
eSAtdmdhIHF4bCBidXQgc2FtZSBwcm9ibGVtLgoKWW91IGhhdmUgdHJpZWQgdHdvIGRpZmZlcmVu
dCBzeW50YXhlcyBoZXJlLCB3aGljaCBvbmUgaXMgdGhlIGNvcnJlY3QKcWVtdSBjb21tYW5kIGxp
bmUgc3ludGF4PwoKSSB0aGluayB5b3UgbmVlZCB0byBjb25zdWx0IHRoZSBxZW11IGRvY3VtZW50
YXRpb24gdG8gZGV0ZXJtaW5lIHdoYXQgdGhlCmNvcnJlY3QgY29tbWFuZCBsaW5lIHN5bnRheCBp
cyBzdXBwb3NlZCB0byBiZS4gCgpQZXJoYXBzIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBnZXQgdGhp
cyB3b3JraW5nIHdpdGggYSBub3JtYWwgcWVtdSAoZS5nLgplbXVsYXRlZCBndWVzdCkgcHJvY2Vz
cyBiZWZvcmUgdHJ5aW5nIHRvIG1ha2UgaXQgd29yayB3aXRoIFhlbj8KCj4gQmVmb3JlIGkgdHJ5
IHRvIGFkZCBwZXJtYW50IGRtX2FyZ3MgZGVidWcgb24gbG9nIHdpdGg6Cj4gT24gbGlieGxfZG0u
YyBhZGQgdGhpcyBsaW5lOgo+IExJQlhMX19MT0coY3R4LCBMSUJYTF9fTE9HX0RFQlVHLCAiZG1f
YXJnczogIiwgZmxleGFycmF5X2NvbnRlbnRzKGRtX2FyZ3MpCj4gKTsKCmZsZXhhcnJheV9jb250
ZW50cyByZXR1cm5zIGEgImNoYXIgKioiIC0tIHlvdSB3b3VsZCBuZWVkIHRvIGxvb3Agb3Zlcgp0
aGF0IGFycmF5IHByaW50aW5nIGVhY2ggZWxlbWVudCBpbiB0dXJuIHVudGlsIHlvdSBmaW5kIE5V
TEwuCgo+IGJlZm9yZSB0aGlzOgo+IHJldHVybiAoY2hhciAqKikgZmxleGFycmF5X2NvbnRlbnRz
KGRtX2FyZ3MpOwo+IAo+IFNob3c6Cj4gbGlieGxfZG0uYzogSW4gZnVuY3Rpb24gw6JsaWJ4bF9f
YnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3w6I6Cj4gbGlieGxfZG0uYzo1ODI6MjogZXJyb3I6
IHRvbyBtYW55IGFyZ3VtZW50cyBmb3IgZm9ybWF0Cj4gWy1XZXJyb3I9Zm9ybWF0LWV4dHJhLWFy
Z3NdCj4gY2MxOiBhbGwgd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKPiAKPiAKPiAK
PiAtLQo+IFZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4uMTA0NTcxMi5u
NS5uYWJibGUuY29tL05lZWQtaGVscC13aXRoLXFlbXUtYXJncy1kZWJ1Zy10cDU1MjQ2ODlwNTUy
NDg2MS5odG1sCj4gU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUg
YXQgTmFiYmxlLmNvbS4KPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:06:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jEG-00036k-LZ; Wed, 29 Feb 2012 13:06:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2jEF-00036c-E7
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:05:59 +0000
Received: from [85.158.139.83:10629] by server-9.bemta-5.messagelabs.com id
	05/F2-09826-6B22E4F4; Wed, 29 Feb 2012 13:05:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330520756!9888830!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2660 invoked from network); 29 Feb 2012 13:05:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 13:05:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2jEC-0002IJ-CE
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 05:05:56 -0800
Date: Wed, 29 Feb 2012 05:05:56 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330520756321-5524897.post@n5.nabble.com>
In-Reply-To: <1330519499118-5524861.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CkZhbnR1IHdyb3RlCj4gCj4gCj4gSWFuIENhbXBiZWxsLTEwIHdyb3RlCj4+IAo+PiBUaGF0IHNo
b3VsZCBiZSBwb3NzaWJsZSwgYnV0IHlvdSBoYXZlbid0IHNob3duIHlvdXIgY29kZSBzbyBJIGNh
bid0IHNheQo+PiB3aGVyZSB5b3UgaGF2ZSBnb25lIHdyb25nLgo+PiAKPj4gV2hhdCBJIG9mdGVu
IGRvIGlzIGNyZWF0ZSBxZW11LWRlYnVnLnNoOgo+PiAJIyEvYmluL3NoCj4+IAllY2hvICJTdGFy
dGluZyBRRU1VIHdpdGg6ICQqIiA+PiAvdG1wL3FlbXUtZGJnLmxvZwo+PiAJZXhlYyAvdXNyL2xp
Yi94ZW4vYmluL3FlbXUtc3lzdGVtLWkzODYgJEAKPj4gCj4+IEFuZCB0aGVuIHVzaW5nIGRldmlj
ZV9tb2RlbF9vdmVycmlkZSB0byBjYWxsIHRoaXMgaW5zdGVhZCBvZiBjYWxsaW5nCj4+IHFlbXUg
ZGlyZWN0bHkuCj4+IAo+IAo+IFRoYW5rcyBmb3IgcmVwbHkKPiAKPiBReGwgZ3JhcGhpYyBpcyBu
ZWVkZWQgZm9yIG1hbnkgdGhpbmdzIHdpdGggc3BpY2UsIEkgc3RhcnQgdG8gdHJ5IGFkZCBpdAo+
IGZvbGxvd2luZyB0aGlzOiBodHRwOi8vc3BpY2Utc3BhY2Uub3JnL2RvY3Mvc3BpY2VfdXNlcl9t
YW51YWwucGRmCj4gCj4gT24gbGlieGxfZG0uYyBhZGQgdGhpcyBsaW5lOgo+IGZsZXhhcnJheV9h
cHBlbmQoZG1fYXJncywgIi1xeGwgMSIpOwo+IGJlZm9yZSB0aGlzOgo+IGZsZXhhcnJheV9hcHBl
bmQoZG1fYXJncywgIi1zcGljZSIpOwo+IAo+IFdpdGggZG0gb3ZlcnJpZGUgZ2l2ZToKPiBTdGFy
dGluZyBRRU1VIHdpdGg6IC14ZW4tZG9taWQgMjIgLWNoYXJkZXYKPiBzb2NrZXQsaWQ9bGlieGwt
Y21kLHBhdGg9L3Zhci9ydW4veGVuL3FtcC1saWJ4bC0yMixzZXJ2ZXIsbm93YWl0IC1tb24KPiBj
aGFyZGV2PWxpYnhsLWNtZCxtb2RlPWNvbnRyb2wgLW5hbWUgUFJFQ0lTRUhWTSAtdm5jIDEyNy4w
LjAuMTowLHRvPTk5Cj4gLXF4bCAxIC1zcGljZQo+IHBvcnQ9NjAwMCx0bHMtcG9ydD0wLGFkZHI9
MC4wLjAuMCxwYXNzd29yZD10ZXN0LGFnZW50LW1vdXNlPW9uIC1ib290Cj4gb3JkZXI9YyAtc21w
IDIsbWF4Y3B1cz0zIC1kZXZpY2UKPiBydGw4MTM5LGlkPW5pYzAsbmV0ZGV2PW5ldDAsbWFjPTAw
OjE2OjNlOjZiOjgxOjg5IC1uZXRkZXYKPiB0eXBlPXRhcCxpZD1uZXQwLGlmbmFtZT10YXAyMi4w
LHNjcmlwdD1ubyAtTSB4ZW5mdiAtbSAxMDI0IC1kcml2ZQo+IGZpbGU9L21udC92bS9kaXNrcy9Q
UkVDSVNFSFZNLmRpc2sxLnhtLGlmPWlkZSxpbmRleD0wLG1lZGlhPWRpc2ssZm9ybWF0PXJhdwo+
IC1kcml2ZSBmaWxlPS9kZXYvc3IwLGlmPWlkZSxpbmRleD0xLG1lZGlhPWNkcm9tLGZvcm1hdD1y
YXcKPiAKPiBBbmQgb24gL3Zhci9sb2cveGVuL3FlbXUtZG0tUFJFQ0lTRUhWTS5sb2c6Cj4gcWVt
dS1zeXN0ZW0taTM4NjogLXF4bDogaW52YWxpZCBvcHRpb24KPiAKPiBUaGVyZSBpc24ndCBvdGhl
ciAtdmdhIG9yIC1ub2dyYXBoaWMgb3B0aW9ucywgSSBub3QgdW5kZXN0YW5kIHRoZSBwcm9ibGVt
LAo+IHdpdGhvdXQgcXhsIHdvcmsgYnV0IG9uIHNwaWNlIGNvbm5lY3QgYW5kIGxvYWQgc2VlIHRo
ZSBjaXJydXMgdmlkZW8gY2FyZCwKPiB2aWRlbyBwZXJmb3JtYW5jZSBpcyBub3QgZ29vZCBhbmQg
aXMgaW1wb3NzaWJsZSByZXNpemUgcmVzb2x1dGlvbiwgcXhsCj4gZ3JhcGhpYyBpcyBuZWVkZWQu
Cj4gSSBoYXZlIGFsc28gdHJ5IC12Z2EgcXhsIGJ1dCBzYW1lIHByb2JsZW0uCj4gCj4gQmVmb3Jl
IGkgdHJ5IHRvIGFkZCBwZXJtYW50IGRtX2FyZ3MgZGVidWcgb24gbG9nIHdpdGg6Cj4gT24gbGli
eGxfZG0uYyBhZGQgdGhpcyBsaW5lOgo+IExJQlhMX19MT0coY3R4LCBMSUJYTF9fTE9HX0RFQlVH
LCAiZG1fYXJnczogIiwgZmxleGFycmF5X2NvbnRlbnRzKGRtX2FyZ3MpCj4gKTsKPiBiZWZvcmUg
dGhpczoKPiByZXR1cm4gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhkbV9hcmdzKTsKPiAK
PiBTaG93Ogo+IGxpYnhsX2RtLmM6IEluIGZ1bmN0aW9uIMOibGlieGxfX2J1aWxkX2RldmljZV9t
b2RlbF9hcmdzX25ld8OiOgo+IGxpYnhsX2RtLmM6NTgyOjI6IGVycm9yOiB0b28gbWFueSBhcmd1
bWVudHMgZm9yIGZvcm1hdAo+IFstV2Vycm9yPWZvcm1hdC1leHRyYS1hcmdzXQo+IGNjMTogYWxs
IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCj4gCgpTZWUgb25seSBub3cgaG93IC12
Z2EgcXhsIHRyeSB0byBzdGFydCBidXQgZ2l2ZSBvdGhlciBlcnJvci4uLgoKU3RhcnRpbmcgUUVN
VSB3aXRoOiAteGVuLWRvbWlkIDI1IC1jaGFyZGV2CnNvY2tldCxpZD1saWJ4bC1jbWQscGF0aD0v
dmFyL3J1bi94ZW4vcW1wLWxpYnhsLTI1LHNlcnZlcixub3dhaXQgLW1vbgpjaGFyZGV2PWxpYnhs
LWNtZCxtb2RlPWNvbnRyb2wgLW5hbWUgUFJFQ0lTRUhWTSAtdmdhIHF4bCAtc3BpY2UKcG9ydD02
MDAwLHRscy1wb3J0PTAsYWRkcj0wLjAuMC4wLHBhc3N3b3JkPXRlc3QsYWdlbnQtbW91c2U9b24g
LWJvb3Qgb3JkZXI9Ywotc21wIDIsbWF4Y3B1cz0zIC1kZXZpY2UgcnRsODEzOSxpZD1uaWMwLG5l
dGRldj1uZXQwLG1hYz0wMDoxNjozZTozODpiZToxZAotbmV0ZGV2IHR5cGU9dGFwLGlkPW5ldDAs
aWZuYW1lPXRhcDI1LjAsc2NyaXB0PW5vIC1NIHhlbmZ2IC1tIDEwMjQgLWRyaXZlCmZpbGU9L21u
dC92bS9kaXNrcy9QUkVDSVNFSFZNLmRpc2sxLnhtLGlmPWlkZSxpbmRleD0wLG1lZGlhPWRpc2ss
Zm9ybWF0PXJhdwotZHJpdmUgZmlsZT0vZGV2L3NyMCxpZj1pZGUsaW5kZXg9MSxtZWRpYT1jZHJv
bSxmb3JtYXQ9cmF3Cgpkb19zcGljZV9pbml0OiBzdGFydGluZyAwLjEwLjEKc3BpY2Vfc2VydmVy
X2FkZF9pbnRlcmZhY2U6IFNQSUNFX0lOVEVSRkFDRV9NSUdSQVRJT04Kc3BpY2Vfc2VydmVyX2Fk
ZF9pbnRlcmZhY2U6IFNQSUNFX0lOVEVSRkFDRV9LRVlCT0FSRApzcGljZV9zZXJ2ZXJfYWRkX2lu
dGVyZmFjZTogU1BJQ0VfSU5URVJGQUNFX01PVVNFCnFlbXU6IGhhcmR3YXJlIGVycm9yOiB4ZW46
IGZhaWxlZCB0byBwb3B1bGF0ZSByYW0gYXQgNDAwMDAwMDAKClRoZSBmdWxsIGxvZzogCmh0dHA6
Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL2ZpbGUvbjU1MjQ4OTcvcWVtdS1kbS1QUkVDSVNF
SFZNLmxvZwpxZW11LWRtLVBSRUNJU0VIVk0ubG9nIAoKLS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4g
Y29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vTmVlZC1oZWxwLXdpdGgt
cWVtdS1hcmdzLWRlYnVnLXRwNTUyNDY4OXA1NTI0ODk3Lmh0bWwKU2VudCBmcm9tIHRoZSBYZW4g
LSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:06:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jEG-00036k-LZ; Wed, 29 Feb 2012 13:06:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2jEF-00036c-E7
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:05:59 +0000
Received: from [85.158.139.83:10629] by server-9.bemta-5.messagelabs.com id
	05/F2-09826-6B22E4F4; Wed, 29 Feb 2012 13:05:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330520756!9888830!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2660 invoked from network); 29 Feb 2012 13:05:57 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 13:05:57 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2jEC-0002IJ-CE
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 05:05:56 -0800
Date: Wed, 29 Feb 2012 05:05:56 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330520756321-5524897.post@n5.nabble.com>
In-Reply-To: <1330519499118-5524861.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CkZhbnR1IHdyb3RlCj4gCj4gCj4gSWFuIENhbXBiZWxsLTEwIHdyb3RlCj4+IAo+PiBUaGF0IHNo
b3VsZCBiZSBwb3NzaWJsZSwgYnV0IHlvdSBoYXZlbid0IHNob3duIHlvdXIgY29kZSBzbyBJIGNh
bid0IHNheQo+PiB3aGVyZSB5b3UgaGF2ZSBnb25lIHdyb25nLgo+PiAKPj4gV2hhdCBJIG9mdGVu
IGRvIGlzIGNyZWF0ZSBxZW11LWRlYnVnLnNoOgo+PiAJIyEvYmluL3NoCj4+IAllY2hvICJTdGFy
dGluZyBRRU1VIHdpdGg6ICQqIiA+PiAvdG1wL3FlbXUtZGJnLmxvZwo+PiAJZXhlYyAvdXNyL2xp
Yi94ZW4vYmluL3FlbXUtc3lzdGVtLWkzODYgJEAKPj4gCj4+IEFuZCB0aGVuIHVzaW5nIGRldmlj
ZV9tb2RlbF9vdmVycmlkZSB0byBjYWxsIHRoaXMgaW5zdGVhZCBvZiBjYWxsaW5nCj4+IHFlbXUg
ZGlyZWN0bHkuCj4+IAo+IAo+IFRoYW5rcyBmb3IgcmVwbHkKPiAKPiBReGwgZ3JhcGhpYyBpcyBu
ZWVkZWQgZm9yIG1hbnkgdGhpbmdzIHdpdGggc3BpY2UsIEkgc3RhcnQgdG8gdHJ5IGFkZCBpdAo+
IGZvbGxvd2luZyB0aGlzOiBodHRwOi8vc3BpY2Utc3BhY2Uub3JnL2RvY3Mvc3BpY2VfdXNlcl9t
YW51YWwucGRmCj4gCj4gT24gbGlieGxfZG0uYyBhZGQgdGhpcyBsaW5lOgo+IGZsZXhhcnJheV9h
cHBlbmQoZG1fYXJncywgIi1xeGwgMSIpOwo+IGJlZm9yZSB0aGlzOgo+IGZsZXhhcnJheV9hcHBl
bmQoZG1fYXJncywgIi1zcGljZSIpOwo+IAo+IFdpdGggZG0gb3ZlcnJpZGUgZ2l2ZToKPiBTdGFy
dGluZyBRRU1VIHdpdGg6IC14ZW4tZG9taWQgMjIgLWNoYXJkZXYKPiBzb2NrZXQsaWQ9bGlieGwt
Y21kLHBhdGg9L3Zhci9ydW4veGVuL3FtcC1saWJ4bC0yMixzZXJ2ZXIsbm93YWl0IC1tb24KPiBj
aGFyZGV2PWxpYnhsLWNtZCxtb2RlPWNvbnRyb2wgLW5hbWUgUFJFQ0lTRUhWTSAtdm5jIDEyNy4w
LjAuMTowLHRvPTk5Cj4gLXF4bCAxIC1zcGljZQo+IHBvcnQ9NjAwMCx0bHMtcG9ydD0wLGFkZHI9
MC4wLjAuMCxwYXNzd29yZD10ZXN0LGFnZW50LW1vdXNlPW9uIC1ib290Cj4gb3JkZXI9YyAtc21w
IDIsbWF4Y3B1cz0zIC1kZXZpY2UKPiBydGw4MTM5LGlkPW5pYzAsbmV0ZGV2PW5ldDAsbWFjPTAw
OjE2OjNlOjZiOjgxOjg5IC1uZXRkZXYKPiB0eXBlPXRhcCxpZD1uZXQwLGlmbmFtZT10YXAyMi4w
LHNjcmlwdD1ubyAtTSB4ZW5mdiAtbSAxMDI0IC1kcml2ZQo+IGZpbGU9L21udC92bS9kaXNrcy9Q
UkVDSVNFSFZNLmRpc2sxLnhtLGlmPWlkZSxpbmRleD0wLG1lZGlhPWRpc2ssZm9ybWF0PXJhdwo+
IC1kcml2ZSBmaWxlPS9kZXYvc3IwLGlmPWlkZSxpbmRleD0xLG1lZGlhPWNkcm9tLGZvcm1hdD1y
YXcKPiAKPiBBbmQgb24gL3Zhci9sb2cveGVuL3FlbXUtZG0tUFJFQ0lTRUhWTS5sb2c6Cj4gcWVt
dS1zeXN0ZW0taTM4NjogLXF4bDogaW52YWxpZCBvcHRpb24KPiAKPiBUaGVyZSBpc24ndCBvdGhl
ciAtdmdhIG9yIC1ub2dyYXBoaWMgb3B0aW9ucywgSSBub3QgdW5kZXN0YW5kIHRoZSBwcm9ibGVt
LAo+IHdpdGhvdXQgcXhsIHdvcmsgYnV0IG9uIHNwaWNlIGNvbm5lY3QgYW5kIGxvYWQgc2VlIHRo
ZSBjaXJydXMgdmlkZW8gY2FyZCwKPiB2aWRlbyBwZXJmb3JtYW5jZSBpcyBub3QgZ29vZCBhbmQg
aXMgaW1wb3NzaWJsZSByZXNpemUgcmVzb2x1dGlvbiwgcXhsCj4gZ3JhcGhpYyBpcyBuZWVkZWQu
Cj4gSSBoYXZlIGFsc28gdHJ5IC12Z2EgcXhsIGJ1dCBzYW1lIHByb2JsZW0uCj4gCj4gQmVmb3Jl
IGkgdHJ5IHRvIGFkZCBwZXJtYW50IGRtX2FyZ3MgZGVidWcgb24gbG9nIHdpdGg6Cj4gT24gbGli
eGxfZG0uYyBhZGQgdGhpcyBsaW5lOgo+IExJQlhMX19MT0coY3R4LCBMSUJYTF9fTE9HX0RFQlVH
LCAiZG1fYXJnczogIiwgZmxleGFycmF5X2NvbnRlbnRzKGRtX2FyZ3MpCj4gKTsKPiBiZWZvcmUg
dGhpczoKPiByZXR1cm4gKGNoYXIgKiopIGZsZXhhcnJheV9jb250ZW50cyhkbV9hcmdzKTsKPiAK
PiBTaG93Ogo+IGxpYnhsX2RtLmM6IEluIGZ1bmN0aW9uIMOibGlieGxfX2J1aWxkX2RldmljZV9t
b2RlbF9hcmdzX25ld8OiOgo+IGxpYnhsX2RtLmM6NTgyOjI6IGVycm9yOiB0b28gbWFueSBhcmd1
bWVudHMgZm9yIGZvcm1hdAo+IFstV2Vycm9yPWZvcm1hdC1leHRyYS1hcmdzXQo+IGNjMTogYWxs
IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCj4gCgpTZWUgb25seSBub3cgaG93IC12
Z2EgcXhsIHRyeSB0byBzdGFydCBidXQgZ2l2ZSBvdGhlciBlcnJvci4uLgoKU3RhcnRpbmcgUUVN
VSB3aXRoOiAteGVuLWRvbWlkIDI1IC1jaGFyZGV2CnNvY2tldCxpZD1saWJ4bC1jbWQscGF0aD0v
dmFyL3J1bi94ZW4vcW1wLWxpYnhsLTI1LHNlcnZlcixub3dhaXQgLW1vbgpjaGFyZGV2PWxpYnhs
LWNtZCxtb2RlPWNvbnRyb2wgLW5hbWUgUFJFQ0lTRUhWTSAtdmdhIHF4bCAtc3BpY2UKcG9ydD02
MDAwLHRscy1wb3J0PTAsYWRkcj0wLjAuMC4wLHBhc3N3b3JkPXRlc3QsYWdlbnQtbW91c2U9b24g
LWJvb3Qgb3JkZXI9Ywotc21wIDIsbWF4Y3B1cz0zIC1kZXZpY2UgcnRsODEzOSxpZD1uaWMwLG5l
dGRldj1uZXQwLG1hYz0wMDoxNjozZTozODpiZToxZAotbmV0ZGV2IHR5cGU9dGFwLGlkPW5ldDAs
aWZuYW1lPXRhcDI1LjAsc2NyaXB0PW5vIC1NIHhlbmZ2IC1tIDEwMjQgLWRyaXZlCmZpbGU9L21u
dC92bS9kaXNrcy9QUkVDSVNFSFZNLmRpc2sxLnhtLGlmPWlkZSxpbmRleD0wLG1lZGlhPWRpc2ss
Zm9ybWF0PXJhdwotZHJpdmUgZmlsZT0vZGV2L3NyMCxpZj1pZGUsaW5kZXg9MSxtZWRpYT1jZHJv
bSxmb3JtYXQ9cmF3Cgpkb19zcGljZV9pbml0OiBzdGFydGluZyAwLjEwLjEKc3BpY2Vfc2VydmVy
X2FkZF9pbnRlcmZhY2U6IFNQSUNFX0lOVEVSRkFDRV9NSUdSQVRJT04Kc3BpY2Vfc2VydmVyX2Fk
ZF9pbnRlcmZhY2U6IFNQSUNFX0lOVEVSRkFDRV9LRVlCT0FSRApzcGljZV9zZXJ2ZXJfYWRkX2lu
dGVyZmFjZTogU1BJQ0VfSU5URVJGQUNFX01PVVNFCnFlbXU6IGhhcmR3YXJlIGVycm9yOiB4ZW46
IGZhaWxlZCB0byBwb3B1bGF0ZSByYW0gYXQgNDAwMDAwMDAKClRoZSBmdWxsIGxvZzogCmh0dHA6
Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tL2ZpbGUvbjU1MjQ4OTcvcWVtdS1kbS1QUkVDSVNF
SFZNLmxvZwpxZW11LWRtLVBSRUNJU0VIVk0ubG9nIAoKLS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4g
Y29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vTmVlZC1oZWxwLXdpdGgt
cWVtdS1hcmdzLWRlYnVnLXRwNTUyNDY4OXA1NTI0ODk3Lmh0bWwKU2VudCBmcm9tIHRoZSBYZW4g
LSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:17:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jOv-0003RG-RU; Wed, 29 Feb 2012 13:17:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1S2jOt-0003R1-TA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:17:00 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330521353!53872640!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1MzAzOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3390 invoked from network); 29 Feb 2012 13:15:54 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 13:15:54 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=MR2y9Nn1ou6aRMtDrGF2CLrVDnC6wRrCcvNEjNQo2RYPwMjZEVFbRdh4
	ZRMy5nBxl/6CQ8Vkbu1E3giPt8VkHaQymnGAaE07mmsLIVR/NvGanSWER
	DktPcB0UAPR5zAOGgEQKeuldl3u7t7qk/2TmhzMWEEYs11cYGFgC+LmxX
	PB70CIO1FicT/Gw1xDFUE8debxX+Gd7UzNv3RTxc5GT252autLqq9/aSP
	G7MC5ng1KRWrOP0SDlgBL9+c2/1iu;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1330521414; x=1362057414;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=WINmyrN6bueTeeZ+0mK2mOsfxjNRAISndLXQBxTjMj8=;
	b=dfO/90Wgmt4BPsDhGgCSSWoFeoR8vZYpOdRh2CWm7TCp6eBASrX5bCrV
	AWE/A0ZqgKg5kS+B+BhJVzZiBlnzNgIud0zirVJ78a3oA4gVMQVJKOpmf
	zVqsNwCqAlsFbNFH7KHrQ5C1pCexgpRJYa6SePYvHDOjQP5usn9OrMitA
	3kYVVhclsj4dZ5/doNiaz9SuMeYhxodrO9H0yu/LYV6rCZ8gi0aX/mIdW
	RdXePc5z4UuaW+4CzXaSx9aUfhPvP;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="87651813"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 29 Feb 2012 14:16:53 +0100
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="130174030"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 29 Feb 2012 14:16:53 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 06A69960FBA
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 14:16:53 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 29 Feb 2012 14:16:52 +0100
Message-ID: <2753116.SHYV1MtyK5@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] vpmu: No need for two initialisation 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

Hi,

with the changeset 24529:87854d3bed93 we got 2 initialisation functions for
the arch specific stuff. This is no more needed.

Dietmar.


Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

# HG changeset patch
# Parent 8082ad2fc6e3705776a4a4b64982c8b49d162c27

diff -r 8082ad2fc6e3 xen/arch/x86/hvm/svm/vpmu.c
--- a/xen/arch/x86/hvm/svm/vpmu.c	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vpmu.c	Wed Feb 29 14:04:42 2012 +0100
@@ -292,14 +292,14 @@ static int amd_vpmu_do_rdmsr(unsigned in
     return 1;
 }
 
-static void amd_vpmu_initialise(struct vcpu *v)
+static int amd_vpmu_initialise(struct vcpu *v)
 {
     struct amd_vpmu_context *ctxt = NULL;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
 
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return;
+        return 0;
 
     if ( counters == NULL )
     {
@@ -329,11 +329,12 @@ static void amd_vpmu_initialise(struct v
         gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
             " PMU feature is unavailable on domain %d vcpu %d.\n",
             v->vcpu_id, v->domain->domain_id);
-        return;
+        return -ENOMEM;
     }
 
     vpmu->context = (void *)ctxt;
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+    return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
@@ -357,7 +358,6 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .do_wrmsr = amd_vpmu_do_wrmsr,
     .do_rdmsr = amd_vpmu_do_rdmsr,
     .do_interrupt = amd_vpmu_do_interrupt,
-    .arch_vpmu_initialise = amd_vpmu_initialise,
     .arch_vpmu_destroy = amd_vpmu_destroy,
     .arch_vpmu_save = amd_vpmu_save,
     .arch_vpmu_load = amd_vpmu_restore
@@ -375,7 +375,7 @@ int svm_vpmu_initialise(struct vcpu *v)
     case 0x14:
     case 0x15:
         vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-        return 0;
+        return amd_vpmu_initialise(v);
     }
 
     printk("VPMU: Initialization failed. "
diff -r 8082ad2fc6e3 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 29 14:04:42 2012 +0100
@@ -583,9 +583,10 @@ static int core2_vpmu_do_interrupt(struc
     return 1;
 }
 
-static void core2_vpmu_initialise(struct vcpu *v)
+static int core2_vpmu_initialise(struct vcpu *v)
 {
     check_pmc_quirk();
+    return 0;
 }
 
 static void core2_vpmu_destroy(struct vcpu *v)
@@ -607,7 +608,6 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .do_wrmsr = core2_vpmu_do_wrmsr,
     .do_rdmsr = core2_vpmu_do_rdmsr,
     .do_interrupt = core2_vpmu_do_interrupt,
-    .arch_vpmu_initialise = core2_vpmu_initialise,
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
     .arch_vpmu_load = core2_vpmu_load
@@ -633,7 +633,7 @@ int vmx_vpmu_initialise(struct vcpu *v)
         case 47:
         case 58:
             vpmu->arch_vpmu_ops = &core2_vpmu_ops;
-            return 0;
+            return core2_vpmu_initialise(v);
         }
     }
 
diff -r 8082ad2fc6e3 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Wed Feb 29 14:04:42 2012 +0100
@@ -88,6 +88,8 @@ void vpmu_initialise(struct vcpu *v)
 
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
+    vpmu_clear(vpmu);
+    vpmu->context = NULL;
 
     switch ( vendor )
     {
@@ -107,13 +109,6 @@ void vpmu_initialise(struct vcpu *v)
         opt_vpmu_enabled = 0;
         break;
     }
-
-    if ( vpmu->arch_vpmu_ops != NULL )
-    {
-        vpmu_clear(vpmu);
-        vpmu->context = NULL;
-        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
-    }
 }
 
 void vpmu_destroy(struct vcpu *v)
diff -r 8082ad2fc6e3 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 29 14:04:42 2012 +0100
@@ -40,7 +40,6 @@ struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content);
     int (*do_rdmsr)(unsigned int msr, uint64_t *msr_content);
     int (*do_interrupt)(struct cpu_user_regs *regs);
-    void (*arch_vpmu_initialise)(struct vcpu *v);
     void (*arch_vpmu_destroy)(struct vcpu *v);
     void (*arch_vpmu_save)(struct vcpu *v);
     void (*arch_vpmu_load)(struct vcpu *v);

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:17:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jOv-0003RG-RU; Wed, 29 Feb 2012 13:17:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1S2jOt-0003R1-TA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:17:00 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330521353!53872640!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1MzAzOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3390 invoked from network); 29 Feb 2012 13:15:54 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 13:15:54 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=MR2y9Nn1ou6aRMtDrGF2CLrVDnC6wRrCcvNEjNQo2RYPwMjZEVFbRdh4
	ZRMy5nBxl/6CQ8Vkbu1E3giPt8VkHaQymnGAaE07mmsLIVR/NvGanSWER
	DktPcB0UAPR5zAOGgEQKeuldl3u7t7qk/2TmhzMWEEYs11cYGFgC+LmxX
	PB70CIO1FicT/Gw1xDFUE8debxX+Gd7UzNv3RTxc5GT252autLqq9/aSP
	G7MC5ng1KRWrOP0SDlgBL9+c2/1iu;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1330521414; x=1362057414;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=WINmyrN6bueTeeZ+0mK2mOsfxjNRAISndLXQBxTjMj8=;
	b=dfO/90Wgmt4BPsDhGgCSSWoFeoR8vZYpOdRh2CWm7TCp6eBASrX5bCrV
	AWE/A0ZqgKg5kS+B+BhJVzZiBlnzNgIud0zirVJ78a3oA4gVMQVJKOpmf
	zVqsNwCqAlsFbNFH7KHrQ5C1pCexgpRJYa6SePYvHDOjQP5usn9OrMitA
	3kYVVhclsj4dZ5/doNiaz9SuMeYhxodrO9H0yu/LYV6rCZ8gi0aX/mIdW
	RdXePc5z4UuaW+4CzXaSx9aUfhPvP;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="87651813"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 29 Feb 2012 14:16:53 +0100
X-IronPort-AV: E=Sophos;i="4.73,501,1325458800"; d="scan'208";a="130174030"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 29 Feb 2012 14:16:53 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 06A69960FBA
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 14:16:53 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 29 Feb 2012 14:16:52 +0100
Message-ID: <2753116.SHYV1MtyK5@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] vpmu: No need for two initialisation 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

Hi,

with the changeset 24529:87854d3bed93 we got 2 initialisation functions for
the arch specific stuff. This is no more needed.

Dietmar.


Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

# HG changeset patch
# Parent 8082ad2fc6e3705776a4a4b64982c8b49d162c27

diff -r 8082ad2fc6e3 xen/arch/x86/hvm/svm/vpmu.c
--- a/xen/arch/x86/hvm/svm/vpmu.c	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vpmu.c	Wed Feb 29 14:04:42 2012 +0100
@@ -292,14 +292,14 @@ static int amd_vpmu_do_rdmsr(unsigned in
     return 1;
 }
 
-static void amd_vpmu_initialise(struct vcpu *v)
+static int amd_vpmu_initialise(struct vcpu *v)
 {
     struct amd_vpmu_context *ctxt = NULL;
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     uint8_t family = current_cpu_data.x86;
 
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-        return;
+        return 0;
 
     if ( counters == NULL )
     {
@@ -329,11 +329,12 @@ static void amd_vpmu_initialise(struct v
         gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
             " PMU feature is unavailable on domain %d vcpu %d.\n",
             v->vcpu_id, v->domain->domain_id);
-        return;
+        return -ENOMEM;
     }
 
     vpmu->context = (void *)ctxt;
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+    return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
@@ -357,7 +358,6 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .do_wrmsr = amd_vpmu_do_wrmsr,
     .do_rdmsr = amd_vpmu_do_rdmsr,
     .do_interrupt = amd_vpmu_do_interrupt,
-    .arch_vpmu_initialise = amd_vpmu_initialise,
     .arch_vpmu_destroy = amd_vpmu_destroy,
     .arch_vpmu_save = amd_vpmu_save,
     .arch_vpmu_load = amd_vpmu_restore
@@ -375,7 +375,7 @@ int svm_vpmu_initialise(struct vcpu *v)
     case 0x14:
     case 0x15:
         vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-        return 0;
+        return amd_vpmu_initialise(v);
     }
 
     printk("VPMU: Initialization failed. "
diff -r 8082ad2fc6e3 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Wed Feb 29 14:04:42 2012 +0100
@@ -583,9 +583,10 @@ static int core2_vpmu_do_interrupt(struc
     return 1;
 }
 
-static void core2_vpmu_initialise(struct vcpu *v)
+static int core2_vpmu_initialise(struct vcpu *v)
 {
     check_pmc_quirk();
+    return 0;
 }
 
 static void core2_vpmu_destroy(struct vcpu *v)
@@ -607,7 +608,6 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .do_wrmsr = core2_vpmu_do_wrmsr,
     .do_rdmsr = core2_vpmu_do_rdmsr,
     .do_interrupt = core2_vpmu_do_interrupt,
-    .arch_vpmu_initialise = core2_vpmu_initialise,
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
     .arch_vpmu_load = core2_vpmu_load
@@ -633,7 +633,7 @@ int vmx_vpmu_initialise(struct vcpu *v)
         case 47:
         case 58:
             vpmu->arch_vpmu_ops = &core2_vpmu_ops;
-            return 0;
+            return core2_vpmu_initialise(v);
         }
     }
 
diff -r 8082ad2fc6e3 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Wed Feb 29 14:04:42 2012 +0100
@@ -88,6 +88,8 @@ void vpmu_initialise(struct vcpu *v)
 
     if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
         vpmu_destroy(v);
+    vpmu_clear(vpmu);
+    vpmu->context = NULL;
 
     switch ( vendor )
     {
@@ -107,13 +109,6 @@ void vpmu_initialise(struct vcpu *v)
         opt_vpmu_enabled = 0;
         break;
     }
-
-    if ( vpmu->arch_vpmu_ops != NULL )
-    {
-        vpmu_clear(vpmu);
-        vpmu->context = NULL;
-        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
-    }
 }
 
 void vpmu_destroy(struct vcpu *v)
diff -r 8082ad2fc6e3 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 29 13:50:57 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Wed Feb 29 14:04:42 2012 +0100
@@ -40,7 +40,6 @@ struct arch_vpmu_ops {
     int (*do_wrmsr)(unsigned int msr, uint64_t msr_content);
     int (*do_rdmsr)(unsigned int msr, uint64_t *msr_content);
     int (*do_interrupt)(struct cpu_user_regs *regs);
-    void (*arch_vpmu_initialise)(struct vcpu *v);
     void (*arch_vpmu_destroy)(struct vcpu *v);
     void (*arch_vpmu_save)(struct vcpu *v);
     void (*arch_vpmu_load)(struct vcpu *v);

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13: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 1S2js4-0003kA-Ig; Wed, 29 Feb 2012 13:47:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2js2-0003jj-En
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 13:47:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330523220!18826911!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28909 invoked from network); 29 Feb 2012 13:47:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 13:47:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 13:48:51 +0000
Message-Id: <4F4E3A8602000078000756E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 13:47:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350A7F35@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"'keir.xen@gmail.com'" <keir.xen@gmail.com>,
	'KonradRzeszutekWilk' <konrad.wilk@oracle.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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 29.02.12 at 13:41, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Jan Beulich wrote:
>>>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>> wrote:
>>>>>> Core parking is a power control feature and it can co-work with
>>>>>> NPTM to control system power budget through online/offline some
>>>>>> CPUs in the system. These patches implement core parking feature
>>>>>> for xen. They consist of 2 parts: dom0 patches and xen hypervisor
>>>>>> patches. 
>>>>>> 
>>>>>> At dom0 side, patches include
>>>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>>>> logic, providing a native interface for natvie platform and a
>>>>>> paravirt template for paravirt platform, so that os can implicitly
>>>>>> hook to proper ops accordingly; [Patch 2/3] redirect paravirt
>>>>>> template to Xen pv ops; [Patch 3/3] implement Xen pad logic, and
>>>>>> when getting pad device notification, it hypercalls to Xen
>>>>>> hypervisor for core parking. Due to the characteristic of xen
>>>>>> continue_hypercall_on_cpu, dom0 seperately send/get core parking
>>>>>> request/result; 
>>>>>> 
>>>>>> At Xen hypervisor side, patches include
>>>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>>>> parking request, and get core parking result;
>>>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>>>> sequence has different power/performance result, due to cpu
>>>>>> socket/core/thread topology. This patch provide power-first and
>>>>>> performance-first policies, users can choose core parking policy
>>>>>> on their own demand, considering power and performance tradeoff.
>>>>> 
>>>>> Does this really need to be implemented in the hypervisor? All this
>>>>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>>>>> have hypercall interfaces already. So I'd rather see this as being
>>>>> an extension to Dom0's pCPU management patches (which aren't
>>>>> upstream afaict)... 
>>>>> 
>>>>> Jan
>>>> 
>>>> It's a design choice. Core parking is not only a wrapper around
>>>> cpu_down/up, it also involves policy algorithms which depend on
>>>> physical cpu topology and cpu_online/present_map, etc. Implement
>>>> core parking at dom0 side need expose all those information to dom0,
>>>> with potential issues (like coherence), while dom0 still need do
>>>> same work as hypervisor. Our idea is to keep dom0 as ACPI parser,
>>>> then hypercall and do rest things at hypervisor side.
>>> 
>>> Actually, after some more thought, I don't even think this ought to
>>> be implemented in the Dom0 kernel, but in user space altogether.
>>> Afaict all information necessary is already being exposed.
>>> 
>> 
>> No, user space lack necessary information. If I didn't misunderstand,
>> it has some dom0-side dependencies not ready now, like 
>> 1. sysfs interface, and exposing xen pcpu topology and maps;
>> 2. intecept pad notify and call usermodehelper;
>> 3. a daemon to monitor/policy core parking (daemon enable when linux
>> run as pvops under xen (kernel acpi_pad disable now), daemon disable
>> when linux run under baremetal (kernel acpi_pad enable now))  
>> 
>> Seems keep same approach as native kernel which handle acpi_pad in
>> kernel side (for us, in hypervisor side) is a reasonable choice. Per
>> my understanding core parking is a co-work part of NPTM, the whole
>> process is basically a remote controller-microengine-bios-kernel
>> process, not necessarily involve user action.    
>> 
> 
> Any comments?

No - I continue to disagree that this needs to be done outside of
user space (the fact that certain necessary kernel pieces aren't in
pv-ops is no excuse, nor is it that native does this in the kernel -
that would at most allow for implementing it in the kernel, but still
won't justify doing it in the hypervisor).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13: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 1S2js4-0003kA-Ig; Wed, 29 Feb 2012 13:47:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2js2-0003jj-En
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 13:47:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330523220!18826911!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28909 invoked from network); 29 Feb 2012 13:47:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 13:47:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 13:48:51 +0000
Message-Id: <4F4E3A8602000078000756E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 13:47:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233509D848@SHSMSX101.ccr.corp.intel.com>
	<4F3E2EEA020000780007397F@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233509EF1F@SHSMSX101.ccr.corp.intel.com>
	<4F435DED0200007800074080@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC82923350A7F35@SHSMSX101.ccr.corp.intel.com>
	<DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BC806@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Shaohua Li <shaohua.li@intel.com>,
	"'keir.xen@gmail.com'" <keir.xen@gmail.com>,
	'KonradRzeszutekWilk' <konrad.wilk@oracle.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Core parking feature 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 29.02.12 at 13:41, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Liu, Jinsong wrote:
>> Jan Beulich wrote:
>>>>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> Jan Beulich wrote:
>>>>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>> wrote:
>>>>>> Core parking is a power control feature and it can co-work with
>>>>>> NPTM to control system power budget through online/offline some
>>>>>> CPUs in the system. These patches implement core parking feature
>>>>>> for xen. They consist of 2 parts: dom0 patches and xen hypervisor
>>>>>> patches. 
>>>>>> 
>>>>>> At dom0 side, patches include
>>>>>> [Patch 1/3] intercept native pad (Processor Aggregator Device)
>>>>>> logic, providing a native interface for natvie platform and a
>>>>>> paravirt template for paravirt platform, so that os can implicitly
>>>>>> hook to proper ops accordingly; [Patch 2/3] redirect paravirt
>>>>>> template to Xen pv ops; [Patch 3/3] implement Xen pad logic, and
>>>>>> when getting pad device notification, it hypercalls to Xen
>>>>>> hypervisor for core parking. Due to the characteristic of xen
>>>>>> continue_hypercall_on_cpu, dom0 seperately send/get core parking
>>>>>> request/result; 
>>>>>> 
>>>>>> At Xen hypervisor side, patches include
>>>>>> [Patch 1/2] implement hypercall through which dom0 send core
>>>>>> parking request, and get core parking result;
>>>>>> [Patch 2/2] implement Xen core parking. Different core parking
>>>>>> sequence has different power/performance result, due to cpu
>>>>>> socket/core/thread topology. This patch provide power-first and
>>>>>> performance-first policies, users can choose core parking policy
>>>>>> on their own demand, considering power and performance tradeoff.
>>>>> 
>>>>> Does this really need to be implemented in the hypervisor? All this
>>>>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>>>>> have hypercall interfaces already. So I'd rather see this as being
>>>>> an extension to Dom0's pCPU management patches (which aren't
>>>>> upstream afaict)... 
>>>>> 
>>>>> Jan
>>>> 
>>>> It's a design choice. Core parking is not only a wrapper around
>>>> cpu_down/up, it also involves policy algorithms which depend on
>>>> physical cpu topology and cpu_online/present_map, etc. Implement
>>>> core parking at dom0 side need expose all those information to dom0,
>>>> with potential issues (like coherence), while dom0 still need do
>>>> same work as hypervisor. Our idea is to keep dom0 as ACPI parser,
>>>> then hypercall and do rest things at hypervisor side.
>>> 
>>> Actually, after some more thought, I don't even think this ought to
>>> be implemented in the Dom0 kernel, but in user space altogether.
>>> Afaict all information necessary is already being exposed.
>>> 
>> 
>> No, user space lack necessary information. If I didn't misunderstand,
>> it has some dom0-side dependencies not ready now, like 
>> 1. sysfs interface, and exposing xen pcpu topology and maps;
>> 2. intecept pad notify and call usermodehelper;
>> 3. a daemon to monitor/policy core parking (daemon enable when linux
>> run as pvops under xen (kernel acpi_pad disable now), daemon disable
>> when linux run under baremetal (kernel acpi_pad enable now))  
>> 
>> Seems keep same approach as native kernel which handle acpi_pad in
>> kernel side (for us, in hypervisor side) is a reasonable choice. Per
>> my understanding core parking is a co-work part of NPTM, the whole
>> process is basically a remote controller-microengine-bios-kernel
>> process, not necessarily involve user action.    
>> 
> 
> Any comments?

No - I continue to disagree that this needs to be done outside of
user space (the fact that certain necessary kernel pieces aren't in
pv-ops is no excuse, nor is it that native does this in the kernel -
that would at most allow for implementing it in the kernel, but still
won't justify doing it in the hypervisor).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:49:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jtk-0003q9-6i; Wed, 29 Feb 2012 13:48:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2jti-0003ps-JA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:48:50 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330523323!9816183!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18305 invoked from network); 29 Feb 2012 13:48:44 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Feb 2012 13:48:44 -0000
Received: from mail104-ch1-R.bigfish.com (10.43.68.230) by
	CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 13:48:42 +0000
Received: from mail104-ch1 (localhost [127.0.0.1])	by
	mail104-ch1-R.bigfish.com (Postfix) with ESMTP id 8CD0A4A02A0;
	Wed, 29 Feb 2012 13:48:42 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI1432N98dK4015Izz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail104-ch1 (localhost.localdomain [127.0.0.1]) by mail104-ch1
	(MessageSwitch) id 1330523320988430_26784;
	Wed, 29 Feb 2012 13:48:40 +0000 (UTC)
Received: from CH1EHSMHS004.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.236])	by mail104-ch1.bigfish.com (Postfix) with ESMTP id
	ECE823C004F;	Wed, 29 Feb 2012 13:48:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 13:48:39 +0000
X-WSS-ID: 0M05QD2-01-7WM-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 2BD0C10281DC;	Wed, 29 Feb 2012 07:48:37 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 29 Feb 2012 07:48:50 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 07:48:38 -0600
Message-ID: <4F4E2CB5.6080107@amd.com>
Date: Wed, 29 Feb 2012 08:48:37 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
	<DE8DF0795D48FD4CA783C40EC82923350BA8B7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BA8B7@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As far as I can tell the most relevant change in Linux was this: 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ea53069231f9317062910d6e772cca4ce93de8c8
and it sounds that it was made mostly because MWAIT-based idle is more 
efficient on Intel processors. That's not the case on AMD where IO-based 
idle is preferred (and I am not aware of any issues, at least so far).

I can make the patch to be AMD_specific but since for the most parts the 
logic is the same as in acpi_idle_do_entry() won't we have to modify 
that function as well?

-boris


On 02/28/12 23:58, Liu, Jinsong wrote:
> I don't think we should go back to old SYSIO method, the history here is:
>
> Xen originally has SYSIO method when offline cpu, but at c/s 23022 we cancel it as reason below
> ======================
> x86: Fix cpu offline bug: cancel SYSIO method when play dead
>
> Play dead is a fragile and tricky point of cpu offline logic.  For how
> to play cpu dead, linux kernel changed several times: Very old kernel
> support 3 ways to play cpu dead: mwait, SYSIO, and halt, just like
> what cpuidle did when enter C3; Later, it cancel mwait and SYSIO
> support, only use halt to play dead; Latest linux 2.6.38 add mwait
> support when cpu dead.
>
> This patch cancel SYSIO method when cpu dead, keep same with latest
> kernel.
>
> SYSIO is an obsoleted method to enter deep C, with some tricky
> hardware behavior, and seldom supported in new platform.  Xen
> experiment indicate that when cpu dead, SYSIO method would trigger
> unknown issue which would bring strange error.  We now cancel SYSIO
> method when cpu dead, after all, correctness is more important than
> power save, and btw new platform use mwait.
> ======================
>
> Thanks,
> Jinsong
>
> Boris Ostrovsky wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # Date 1330466573 -3600
>> # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
>> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
>> x86: Use deep C states for off-lined CPUs
>>
>> Currently when a core is taken off-line it is placed in C1 state
>> (unless MONITOR/MWAIT is used). This patch allows a core to go to
>> deeper C states resulting in significantly higher power savings.
>>
>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>
>> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
>> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
>> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
>> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>>       if ( (cx =&power->states[power->count-1]) == NULL )
>>           goto default_halt;
>>
>> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
>> -
>>       if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>>       {
>> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
>> +
>>           /*
>>            * Cache must be flushed as the last operation before
>> sleeping.
>>            * Otherwise, CPU may still hold dirty data, breaking cache
>> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>>               mb();
>>               __mwait(cx->address, 0);
>>           }
>> +    }
>> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
>> +    {
>> +        /* Avoid references to shared data after the cache flush */
>> +        u32 address = cx->address;
>> +        u32 pmtmr_ioport_local = pmtmr_ioport;
>> +
>> +        wbinvd();
>> +
>> +        while ( 1 )
>> +        {
>> +            inb(address);
>> +            inl(pmtmr_ioport_local);
>> +        }
>>       }
>>
>>   default_halt:
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:49:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jtk-0003q9-6i; Wed, 29 Feb 2012 13:48:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2jti-0003ps-JA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:48:50 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330523323!9816183!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18305 invoked from network); 29 Feb 2012 13:48:44 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Feb 2012 13:48:44 -0000
Received: from mail104-ch1-R.bigfish.com (10.43.68.230) by
	CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 13:48:42 +0000
Received: from mail104-ch1 (localhost [127.0.0.1])	by
	mail104-ch1-R.bigfish.com (Postfix) with ESMTP id 8CD0A4A02A0;
	Wed, 29 Feb 2012 13:48:42 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI1432N98dK4015Izz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail104-ch1 (localhost.localdomain [127.0.0.1]) by mail104-ch1
	(MessageSwitch) id 1330523320988430_26784;
	Wed, 29 Feb 2012 13:48:40 +0000 (UTC)
Received: from CH1EHSMHS004.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.236])	by mail104-ch1.bigfish.com (Postfix) with ESMTP id
	ECE823C004F;	Wed, 29 Feb 2012 13:48:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 13:48:39 +0000
X-WSS-ID: 0M05QD2-01-7WM-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 2BD0C10281DC;	Wed, 29 Feb 2012 07:48:37 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 29 Feb 2012 07:48:50 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 07:48:38 -0600
Message-ID: <4F4E2CB5.6080107@amd.com>
Date: Wed, 29 Feb 2012 08:48:37 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>
	<DE8DF0795D48FD4CA783C40EC82923350BA8B7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BA8B7@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As far as I can tell the most relevant change in Linux was this: 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ea53069231f9317062910d6e772cca4ce93de8c8
and it sounds that it was made mostly because MWAIT-based idle is more 
efficient on Intel processors. That's not the case on AMD where IO-based 
idle is preferred (and I am not aware of any issues, at least so far).

I can make the patch to be AMD_specific but since for the most parts the 
logic is the same as in acpi_idle_do_entry() won't we have to modify 
that function as well?

-boris


On 02/28/12 23:58, Liu, Jinsong wrote:
> I don't think we should go back to old SYSIO method, the history here is:
>
> Xen originally has SYSIO method when offline cpu, but at c/s 23022 we cancel it as reason below
> ======================
> x86: Fix cpu offline bug: cancel SYSIO method when play dead
>
> Play dead is a fragile and tricky point of cpu offline logic.  For how
> to play cpu dead, linux kernel changed several times: Very old kernel
> support 3 ways to play cpu dead: mwait, SYSIO, and halt, just like
> what cpuidle did when enter C3; Later, it cancel mwait and SYSIO
> support, only use halt to play dead; Latest linux 2.6.38 add mwait
> support when cpu dead.
>
> This patch cancel SYSIO method when cpu dead, keep same with latest
> kernel.
>
> SYSIO is an obsoleted method to enter deep C, with some tricky
> hardware behavior, and seldom supported in new platform.  Xen
> experiment indicate that when cpu dead, SYSIO method would trigger
> unknown issue which would bring strange error.  We now cancel SYSIO
> method when cpu dead, after all, correctness is more important than
> power save, and btw new platform use mwait.
> ======================
>
> Thanks,
> Jinsong
>
> Boris Ostrovsky wrote:
>> # HG changeset patch
>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>> # Date 1330466573 -3600
>> # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
>> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
>> x86: Use deep C states for off-lined CPUs
>>
>> Currently when a core is taken off-line it is placed in C1 state
>> (unless MONITOR/MWAIT is used). This patch allows a core to go to
>> deeper C states resulting in significantly higher power savings.
>>
>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>
>> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
>> --- a/xen/arch/x86/acpi/cpu_idle.c	Mon Feb 27 17:05:18 2012 +0000
>> +++ b/xen/arch/x86/acpi/cpu_idle.c	Tue Feb 28 23:02:53 2012 +0100
>> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>>       if ( (cx =&power->states[power->count-1]) == NULL )
>>           goto default_halt;
>>
>> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
>> -
>>       if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>>       {
>> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id());
>> +
>>           /*
>>            * Cache must be flushed as the last operation before
>> sleeping.
>>            * Otherwise, CPU may still hold dirty data, breaking cache
>> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>>               mb();
>>               __mwait(cx->address, 0);
>>           }
>> +    }
>> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO )
>> +    {
>> +        /* Avoid references to shared data after the cache flush */
>> +        u32 address = cx->address;
>> +        u32 pmtmr_ioport_local = pmtmr_ioport;
>> +
>> +        wbinvd();
>> +
>> +        while ( 1 )
>> +        {
>> +            inb(address);
>> +            inl(pmtmr_ioport_local);
>> +        }
>>       }
>>
>>   default_halt:
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:54:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jyj-00043S-3J; Wed, 29 Feb 2012 13:54:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2jyi-00043M-0b
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:54:00 +0000
Received: from [85.158.139.83:42216] by server-8.bemta-5.messagelabs.com id
	C5/BD-07862-7FD2E4F4; Wed, 29 Feb 2012 13:53:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330523638!9897894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28368 invoked from network); 29 Feb 2012 13:53:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 13:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11010542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 13:53:58 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 13:53:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 13:53:08 +0000
Message-ID: <1330523588.10387.40.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH] Grant table: fix a bug when grant copying a
 previous grant mapped page.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1330523387 0
# Node ID be6bd7febd33d5dd21cbbeb180e6907cd6038a77
# Parent  a43eeaedf61ccaf269d0823ea80d3dfa8157cc63
Grant table: fix a bug when grant copying a previous grant mapped page.

In grant table version 2, when we create a non-transitive mapping from
DomU to Dom0, we need to set active entry's trans_domain and trans_ref.
Otherwise when we grant copy from this previous mapped ref, preemption
count will get messed up.

Considering following scenario, src_gref is already grant mapped
(act->pin != 0) in Dom0 and it is not transitive.

__gnttab_copy(src_gref,dst_gref)
{
  __acquire_grant_for_copy(src_gref)
  __acquire_grant_for_copy(dst_gref)
  ...copy...
  __release_grant_for_copy(src_gref)
  __release_grant_for_cooy(dst_gref)
}

__acquire_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (!act->pin) {
    check stuff for transitive grant
    if (!act->pin) {
      set fields in act
    }
  } else {
    set owning_domain
  }
}

__release_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (grant table version is 1) {
    use v1 stuff
  } else {
    td = act->trans_domain
    trans_gref = act->trans_gref
  }
  if (td != rd) {
    recursively release grant
    rcu_unlock_domain(td)
  }
}

If we don't set trans_domain when creating mapping, in the release path
td = act->trans_domain, in which case it is NULL, will screw up preemption
count with rcu_unlock_domain(NULL).

See changeset 22994:299ed79acecf for more information.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -585,6 +585,8 @@ __gnttab_map_grant_ref(
             act->start = 0;
             act->length = PAGE_SIZE;
             act->is_sub_page = 0;
+            act->trans_domain = rd;
+            act->trans_gref = op->ref;
         }
     }
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 13:54:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 13:54:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2jyj-00043S-3J; Wed, 29 Feb 2012 13:54:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2jyi-00043M-0b
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 13:54:00 +0000
Received: from [85.158.139.83:42216] by server-8.bemta-5.messagelabs.com id
	C5/BD-07862-7FD2E4F4; Wed, 29 Feb 2012 13:53:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1330523638!9897894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28368 invoked from network); 29 Feb 2012 13:53:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 13:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11010542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 13:53:58 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 13:53:58 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 13:53:08 +0000
Message-ID: <1330523588.10387.40.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Paul Durrant <Paul.Durrant@citrix.com>,
	wei.liu2@citrix.com
Subject: [Xen-devel] [PATCH] Grant table: fix a bug when grant copying a
 previous grant mapped page.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1330523387 0
# Node ID be6bd7febd33d5dd21cbbeb180e6907cd6038a77
# Parent  a43eeaedf61ccaf269d0823ea80d3dfa8157cc63
Grant table: fix a bug when grant copying a previous grant mapped page.

In grant table version 2, when we create a non-transitive mapping from
DomU to Dom0, we need to set active entry's trans_domain and trans_ref.
Otherwise when we grant copy from this previous mapped ref, preemption
count will get messed up.

Considering following scenario, src_gref is already grant mapped
(act->pin != 0) in Dom0 and it is not transitive.

__gnttab_copy(src_gref,dst_gref)
{
  __acquire_grant_for_copy(src_gref)
  __acquire_grant_for_copy(dst_gref)
  ...copy...
  __release_grant_for_copy(src_gref)
  __release_grant_for_cooy(dst_gref)
}

__acquire_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (!act->pin) {
    check stuff for transitive grant
    if (!act->pin) {
      set fields in act
    }
  } else {
    set owning_domain
  }
}

__release_grant_for_copy(rd,gref)
{
  act <- get active entry for gref
  if (grant table version is 1) {
    use v1 stuff
  } else {
    td = act->trans_domain
    trans_gref = act->trans_gref
  }
  if (td != rd) {
    recursively release grant
    rcu_unlock_domain(td)
  }
}

If we don't set trans_domain when creating mapping, in the release path
td = act->trans_domain, in which case it is NULL, will screw up preemption
count with rcu_unlock_domain(NULL).

See changeset 22994:299ed79acecf for more information.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -585,6 +585,8 @@ __gnttab_map_grant_ref(
             act->start = 0;
             act->length = PAGE_SIZE;
             act->is_sub_page = 0;
+            act->trans_domain = rd;
+            act->trans_gref = op->ref;
         }
     }
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:25:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kSy-0004QD-TN; Wed, 29 Feb 2012 14:25: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 1S2kSw-0004Q8-MR
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:25:15 +0000
Received: from [85.158.139.83:19346] by server-12.bemta-5.messagelabs.com id
	04/87-05587-9453E4F4; Wed, 29 Feb 2012 14:25:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330525509!17169629!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjM3NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10280 invoked from network); 29 Feb 2012 14:25:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325480400"; d="scan'208";a="22562010"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:25:08 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 09:25:08 -0500
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S2kSp-0002MQ-Rb;
	Wed, 29 Feb 2012 14:25:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 14:25:07 +0000
Message-ID: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I _think_ this isn't required because we also checkin the generated files. A
more complete fix might also allow the user to force regeneration but I didn't
both here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/configure    |  559 +++++++++++++++++++++++++---------------------------
 tools/configure.ac |    1 -
 2 files changed, 268 insertions(+), 292 deletions(-)

diff --git a/tools/configure b/tools/configure
index 5fe72cf..96509b6 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
 #
 # Report bugs to <xen-devel@lists.xensource.com>.
 #
@@ -91,7 +91,6 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
-as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -217,18 +216,11 @@ IFS=$as_save_IFS
   # We cannot yet assume a decent shell, so we have to provide a
 	# neutralization value for shells without unset; and this also
 	# works around shells that cannot unset nonexistent variables.
-	# Preserve -v and -x to the replacement shell.
 	BASH_ENV=/dev/null
 	ENV=/dev/null
 	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
 	export CONFIG_SHELL
-	case $- in # ((((
-	  *v*x* | *x*v* ) as_opts=-vx ;;
-	  *v* ) as_opts=-v ;;
-	  *x* ) as_opts=-x ;;
-	  * ) as_opts= ;;
-	esac
-	exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
+	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
 fi
 
     if test x$as_have_required = xno; then :
@@ -633,6 +625,7 @@ OCAMLOPT
 OCAMLLIB
 OCAMLVERSION
 OCAMLC
+BISON
 INSTALL_DATA
 INSTALL_SCRIPT
 INSTALL_PROGRAM
@@ -644,7 +637,6 @@ BASH
 XML
 CURL
 FLEX
-BISON
 IP
 PERL
 PYTHON
@@ -748,7 +740,6 @@ APPEND_LIB
 PYTHON
 PERL
 IP
-BISON
 FLEX
 CURL
 XML
@@ -1163,7 +1154,7 @@ Try \`$0 --help' for more information"
     $as_echo "$as_me: WARNING: you should use --build, --host, --target" >&2
     expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
       $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
-    : "${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}"
+    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
     ;;
 
   esac
@@ -1403,7 +1394,6 @@ Some influential environment variables:
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
   IP          Path to ip tool
-  BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
   CURL        Path to curl-config tool
   XML         Path to xml2-config tool
@@ -1484,7 +1474,7 @@ test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
 Xen Hypervisor configure 4.2
-generated by GNU Autoconf 2.68
+generated by GNU Autoconf 2.67
 
 Copyright (C) 2010 Free Software Foundation, Inc.
 This configure script is free software; the Free Software Foundation
@@ -1530,7 +1520,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
 	ac_retval=1
 fi
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_compile
@@ -1567,7 +1557,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
     ac_retval=1
 fi
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_cpp
@@ -1580,10 +1570,10 @@ fi
 ac_fn_c_check_header_mongrel ()
 {
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  if eval \${$3+:} false; then :
+  if eval "test \"\${$3+set}\"" = set; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 fi
 eval ac_res=\$$3
@@ -1650,7 +1640,7 @@ $as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
 esac
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=\$ac_header_compiler"
@@ -1659,7 +1649,7 @@ eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
 fi
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_header_mongrel
 
@@ -1700,7 +1690,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
        ac_retval=$ac_status
 fi
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_run
@@ -1714,7 +1704,7 @@ ac_fn_c_check_header_compile ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1732,7 +1722,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_header_compile
 
@@ -1777,65 +1767,11 @@ fi
   # interfere with the next link command; also delete a directory that is
   # left behind by Apple's compiler.  We do this before executing the actions.
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_link
 
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cache
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=no"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-	 return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-	    return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=yes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=\$$3
-	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_check_func LINENO FUNC VAR
 # ----------------------------------
 # Tests whether FUNC exists, setting the cache variable VAR accordingly
@@ -1844,7 +1780,7 @@ ac_fn_c_check_func ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1899,10 +1835,64 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_func
 
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cache
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval "test \"\${$3+set}\"" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=no"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof ($2))
+	 return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof (($2)))
+	    return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+
+else
+  eval "$3=yes"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=\$$3
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+
+} # ac_fn_c_check_type
+
 # ac_fn_c_find_intX_t LINENO BITS VAR
 # -----------------------------------
 # Finds a signed integer type with width BITS, setting cache variable VAR
@@ -1912,7 +1902,7 @@ ac_fn_c_find_intX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
 $as_echo_n "checking for int$2_t... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -1973,7 +1963,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_find_intX_t
 
@@ -1986,7 +1976,7 @@ ac_fn_c_check_member ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
 $as_echo_n "checking for $2.$3... " >&6; }
-if eval \${$4+:} false; then :
+if eval "test \"\${$4+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -2030,7 +2020,7 @@ fi
 eval ac_res=\$$4
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_member
 
@@ -2043,7 +2033,7 @@ ac_fn_c_find_uintX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
 $as_echo_n "checking for uint$2_t... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -2083,7 +2073,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_find_uintX_t
 cat >config.log <<_ACEOF
@@ -2091,7 +2081,7 @@ This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
 It was created by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.68.  Invocation command line was
+generated by GNU Autoconf 2.67.  Invocation command line was
 
   $ $0 $@
 
@@ -2349,7 +2339,7 @@ $as_echo "$as_me: loading site script $ac_site_file" >&6;}
       || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
   fi
 done
 
@@ -2504,7 +2494,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2544,7 +2534,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2597,7 +2587,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2637,7 +2627,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2696,7 +2686,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2740,7 +2730,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2795,7 +2785,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -2910,7 +2900,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -2953,7 +2943,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and link
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3012,7 +3002,7 @@ $as_echo "$ac_try_echo"; } >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
     fi
   fi
 fi
@@ -3023,7 +3013,7 @@ rm -f conftest.$ac_ext conftest$ac_cv_exeext conftest.out
 ac_clean_files=$ac_clean_files_save
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
 $as_echo_n "checking for suffix of object files... " >&6; }
-if ${ac_cv_objext+:} false; then :
+if test "${ac_cv_objext+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3064,7 +3054,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 rm -f conftest.$ac_cv_objext conftest.$ac_ext
 fi
@@ -3074,7 +3064,7 @@ OBJEXT=$ac_cv_objext
 ac_objext=$OBJEXT
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if ${ac_cv_c_compiler_gnu+:} false; then :
+if test "${ac_cv_c_compiler_gnu+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3111,7 +3101,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if ${ac_cv_prog_cc_g+:} false; then :
+if test "${ac_cv_prog_cc_g+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -3189,7 +3179,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if ${ac_cv_prog_cc_c89+:} false; then :
+if test "${ac_cv_prog_cc_c89+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -3297,7 +3287,7 @@ if test -n "$CPP" && test -d "$CPP"; then
   CPP=
 fi
 if test -z "$CPP"; then
-  if ${ac_cv_prog_CPP+:} false; then :
+  if test "${ac_cv_prog_CPP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
       # Double quotes because CPP needs to be expanded
@@ -3413,7 +3403,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 
 ac_ext=c
@@ -3425,7 +3415,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long lines and -e" >&5
 $as_echo_n "checking for grep that handles long lines and -e... " >&6; }
-if ${ac_cv_path_GREP+:} false; then :
+if test "${ac_cv_path_GREP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -z "$GREP"; then
@@ -3488,7 +3478,7 @@ $as_echo "$ac_cv_path_GREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
 $as_echo_n "checking for egrep... " >&6; }
-if ${ac_cv_path_EGREP+:} false; then :
+if test "${ac_cv_path_EGREP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
@@ -3555,7 +3545,7 @@ $as_echo "$ac_cv_path_EGREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header files" >&5
 $as_echo_n "checking for ANSI C header files... " >&6; }
-if ${ac_cv_header_stdc+:} false; then :
+if test "${ac_cv_header_stdc+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3684,7 +3674,7 @@ done
 
 
   ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_minix_config_h" "$ac_includes_default"
-if test "x$ac_cv_header_minix_config_h" = xyes; then :
+if test "x$ac_cv_header_minix_config_h" = x""yes; then :
   MINIX=yes
 else
   MINIX=
@@ -3706,7 +3696,7 @@ $as_echo "#define _MINIX 1" >>confdefs.h
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe to define __EXTENSIONS__" >&5
 $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&6; }
-if ${ac_cv_safe_to_define___extensions__+:} false; then :
+if test "${ac_cv_safe_to_define___extensions__+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3749,7 +3739,7 @@ $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
 $as_echo_n "checking build system type... " >&6; }
-if ${ac_cv_build+:} false; then :
+if test "${ac_cv_build+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_build_alias=$build_alias
@@ -3765,7 +3755,7 @@ fi
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
 esac
 build=$ac_cv_build
 ac_save_IFS=$IFS; IFS='-'
@@ -3783,7 +3773,7 @@ case $build_os in *\ *) build_os=`echo "$build_os" | sed 's/ /-/g'`;; esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
 $as_echo_n "checking host system type... " >&6; }
-if ${ac_cv_host+:} false; then :
+if test "${ac_cv_host+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "x$host_alias" = x; then
@@ -3798,7 +3788,7 @@ fi
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
 esac
 host=$ac_cv_host
 ac_save_IFS=$IFS; IFS='-'
@@ -4168,11 +4158,10 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"
 
 
 
-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
-if ${ac_cv_path_SED+:} false; then :
+if test "${ac_cv_path_SED+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
             ac_script=s/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/
@@ -4249,7 +4238,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4289,7 +4278,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4342,7 +4331,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4382,7 +4371,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4441,7 +4430,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4485,7 +4474,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4540,7 +4529,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -4569,7 +4558,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if ${ac_cv_c_compiler_gnu+:} false; then :
+if test "${ac_cv_c_compiler_gnu+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -4606,7 +4595,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if ${ac_cv_prog_cc_g+:} false; then :
+if test "${ac_cv_prog_cc_g+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -4684,7 +4673,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if ${ac_cv_prog_cc_c89+:} false; then :
+if test "${ac_cv_prog_cc_c89+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -4794,7 +4783,7 @@ fi
 $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
 set x ${MAKE-make}
 ac_make=`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
-if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
+if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat >conftest.make <<\_ACEOF
@@ -4838,7 +4827,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible install" >&5
 $as_echo_n "checking for a BSD-compatible install... " >&6; }
 if test -z "$INSTALL"; then
-if ${ac_cv_path_install+:} false; then :
+if test "${ac_cv_path_install+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -4918,7 +4907,7 @@ test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 set dummy perl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_PERL+:} false; then :
+if test "${ac_cv_path_PERL+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $PERL in
@@ -4963,7 +4952,7 @@ fi
 set dummy ip; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_IP+:} false; then :
+if test "${ac_cv_path_IP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $IP in
@@ -5008,7 +4997,7 @@ fi
 set dummy bison; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_BISON+:} false; then :
+if test "${ac_cv_path_BISON+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $BISON in
@@ -5053,7 +5042,7 @@ fi
 set dummy flex; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_FLEX+:} false; then :
+if test "${ac_cv_path_FLEX+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $FLEX in
@@ -5100,7 +5089,7 @@ if test "x$xapi" = "xy"; then :
 set dummy curl-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_CURL+:} false; then :
+if test "${ac_cv_path_CURL+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $CURL in
@@ -5145,7 +5134,7 @@ fi
 set dummy xml2-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_XML+:} false; then :
+if test "${ac_cv_path_XML+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $XML in
@@ -5196,7 +5185,7 @@ if test "x$ocamltools" = "xy"; then :
 set dummy ${ac_tool_prefix}ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLC+:} false; then :
+if test "${ac_cv_prog_OCAMLC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLC"; then
@@ -5236,7 +5225,7 @@ if test -z "$ac_cv_prog_OCAMLC"; then
 set dummy ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLC"; then
@@ -5307,7 +5296,7 @@ $as_echo "OCaml library path is $OCAMLLIB" >&6; }
 set dummy ${ac_tool_prefix}ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLOPT+:} false; then :
+if test "${ac_cv_prog_OCAMLOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPT"; then
@@ -5347,7 +5336,7 @@ if test -z "$ac_cv_prog_OCAMLOPT"; then
 set dummy ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPT"; then
@@ -5417,7 +5406,7 @@ $as_echo "versions differs from ocamlc; ocamlopt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
+if test "${ac_cv_prog_OCAMLCDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLCDOTOPT"; then
@@ -5457,7 +5446,7 @@ if test -z "$ac_cv_prog_OCAMLCDOTOPT"; then
 set dummy ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLCDOTOPT"; then
@@ -5521,7 +5510,7 @@ $as_echo "versions differs from ocamlc; ocamlc.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
+if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPTDOTOPT"; then
@@ -5561,7 +5550,7 @@ if test -z "$ac_cv_prog_OCAMLOPTDOTOPT"; then
 set dummy ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
@@ -5630,7 +5619,7 @@ $as_echo "version differs from ocamlc; ocamlopt.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAML+:} false; then :
+if test "${ac_cv_prog_OCAML+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAML"; then
@@ -5670,7 +5659,7 @@ if test -z "$ac_cv_prog_OCAML"; then
 set dummy ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAML+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAML"; then
@@ -5724,7 +5713,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLDEP+:} false; then :
+if test "${ac_cv_prog_OCAMLDEP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDEP"; then
@@ -5764,7 +5753,7 @@ if test -z "$ac_cv_prog_OCAMLDEP"; then
 set dummy ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDEP"; then
@@ -5818,7 +5807,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
+if test "${ac_cv_prog_OCAMLMKTOP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKTOP"; then
@@ -5858,7 +5847,7 @@ if test -z "$ac_cv_prog_OCAMLMKTOP"; then
 set dummy ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKTOP"; then
@@ -5912,7 +5901,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
+if test "${ac_cv_prog_OCAMLMKLIB+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKLIB"; then
@@ -5952,7 +5941,7 @@ if test -z "$ac_cv_prog_OCAMLMKLIB"; then
 set dummy ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKLIB"; then
@@ -6006,7 +5995,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLDOC+:} false; then :
+if test "${ac_cv_prog_OCAMLDOC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDOC"; then
@@ -6046,7 +6035,7 @@ if test -z "$ac_cv_prog_OCAMLDOC"; then
 set dummy ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDOC"; then
@@ -6100,7 +6089,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLBUILD+:} false; then :
+if test "${ac_cv_prog_OCAMLBUILD+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLBUILD"; then
@@ -6140,7 +6129,7 @@ if test -z "$ac_cv_prog_OCAMLBUILD"; then
 set dummy ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLBUILD"; then
@@ -6203,7 +6192,7 @@ fi
 set dummy bash; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_BASH+:} false; then :
+if test "${ac_cv_path_BASH+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $BASH in
@@ -6260,7 +6249,7 @@ fi
 set dummy $PYTHON; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_PYTHONPATH+:} false; then :
+if test "${ac_cv_path_PYTHONPATH+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $PYTHONPATH in
@@ -6352,7 +6341,7 @@ fi
 set dummy xgettext; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_XGETTEXT+:} false; then :
+if test "${ac_cv_path_XGETTEXT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $XGETTEXT in
@@ -6396,7 +6385,7 @@ fi
 if test "x$host_os" == "xlinux-gnu"
 then
     ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_uuid_h" = xyes; then :
+if test "x$ac_cv_header_uuid_uuid_h" = x""yes; then :
 
 else
   as_fn_error $? "cannot find uuid headers" "$LINENO" 5
@@ -6405,7 +6394,7 @@ fi
 
 else
     ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_h" = xyes; then :
+if test "x$ac_cv_header_uuid_h" = x""yes; then :
 
 else
   as_fn_error $? "cannot find uuid headers" "$LINENO" 5
@@ -6426,7 +6415,7 @@ if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
 set dummy ${ac_tool_prefix}pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_PKG_CONFIG+:} false; then :
+if test "${ac_cv_path_PKG_CONFIG+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $PKG_CONFIG in
@@ -6469,7 +6458,7 @@ if test -z "$ac_cv_path_PKG_CONFIG"; then
 set dummy pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
+if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $ac_pt_PKG_CONFIG in
@@ -6614,7 +6603,7 @@ and glib_LIBS to avoid the need to call pkg-config.
 See the pkg-config man page for more details.
 
 To get pkg-config, see <http://pkg-config.freedesktop.org/>.
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 else
 	glib_CFLAGS=$pkg_cv_glib_CFLAGS
 	glib_LIBS=$pkg_cv_glib_LIBS
@@ -6638,7 +6627,7 @@ fi
 # Checks for libraries.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio" >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
-if ${ac_cv_lib_aio_io_setup+:} false; then :
+if test "${ac_cv_lib_aio_io_setup+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6672,7 +6661,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup" >&5
 $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
-if test "x$ac_cv_lib_aio_io_setup" = xyes; then :
+if test "x$ac_cv_lib_aio_io_setup" = x""yes; then :
   system_aio="y"
 else
   system_aio="n"
@@ -6681,7 +6670,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >&5
 $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
-if ${ac_cv_lib_crypto_MD5+:} false; then :
+if test "${ac_cv_lib_crypto_MD5+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6715,7 +6704,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" >&5
 $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
-if test "x$ac_cv_lib_crypto_MD5" = xyes; then :
+if test "x$ac_cv_lib_crypto_MD5" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBCRYPTO 1
 _ACEOF
@@ -6728,7 +6717,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -lext2fs" >&5
 $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
-if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
+if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6762,7 +6751,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2fs_open2" >&5
 $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
-if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = xyes; then :
+if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = x""yes; then :
   libext2fs="y"
 else
   libext2fs="n"
@@ -6771,7 +6760,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffer in -lgcrypt" >&5
 $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
+if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6805,7 +6794,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&5
 $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = xyes; then :
+if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = x""yes; then :
   libgcrypt="y"
 else
   libgcrypt="n"
@@ -6814,7 +6803,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in -lpthread" >&5
 $as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if ${ac_cv_lib_pthread_pthread_create+:} false; then :
+if test "${ac_cv_lib_pthread_pthread_create+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6848,7 +6837,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_create" >&5
 $as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then :
+if test "x$ac_cv_lib_pthread_pthread_create" = x""yes; then :
 
 else
   as_fn_error $? "Could not find libpthread" "$LINENO" 5
@@ -6856,7 +6845,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
-if ${ac_cv_lib_rt_clock_gettime+:} false; then :
+if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6890,7 +6879,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_gettime" >&5
 $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
-if test "x$ac_cv_lib_rt_clock_gettime" = xyes; then :
+if test "x$ac_cv_lib_rt_clock_gettime" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBRT 1
 _ACEOF
@@ -6901,7 +6890,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
-if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
+if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6935,7 +6924,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_clear" >&5
 $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
-if test "x$ac_cv_lib_uuid_uuid_clear" = xyes; then :
+if test "x$ac_cv_lib_uuid_uuid_clear" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBUUID 1
 _ACEOF
@@ -6948,7 +6937,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
-if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
+if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6982,7 +6971,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_alloc" >&5
 $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
-if test "x$ac_cv_lib_yajl_yajl_alloc" = xyes; then :
+if test "x$ac_cv_lib_yajl_yajl_alloc" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBYAJL 1
 _ACEOF
@@ -6995,7 +6984,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz" >&5
 $as_echo_n "checking for deflateCopy in -lz... " >&6; }
-if ${ac_cv_lib_z_deflateCopy+:} false; then :
+if test "${ac_cv_lib_z_deflateCopy+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7029,7 +7018,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCopy" >&5
 $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
-if test "x$ac_cv_lib_z_deflateCopy" = xyes; then :
+if test "x$ac_cv_lib_z_deflateCopy" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBZ 1
 _ACEOF
@@ -7042,7 +7031,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -liconv" >&5
 $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
-if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
+if test "${ac_cv_lib_iconv_libiconv_open+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7076,7 +7065,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libiconv_open" >&5
 $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
-if test "x$ac_cv_lib_iconv_libiconv_open" = xyes; then :
+if test "x$ac_cv_lib_iconv_libiconv_open" = x""yes; then :
   libiconv="y"
 else
   libiconv="n"
@@ -7085,22 +7074,11 @@ fi
 
 
 # Checks for header files.
-ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
-if test "x$ac_cv_type_size_t" = xyes; then :
-
-else
-
-cat >>confdefs.h <<_ACEOF
-#define size_t unsigned int
-_ACEOF
-
-fi
-
 # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
 # for constant arguments.  Useless!
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" >&5
 $as_echo_n "checking for working alloca.h... " >&6; }
-if ${ac_cv_working_alloca_h+:} false; then :
+if test "${ac_cv_working_alloca_h+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7133,7 +7111,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
 $as_echo_n "checking for alloca... " >&6; }
-if ${ac_cv_func_alloca_works+:} false; then :
+if test "${ac_cv_func_alloca_works+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7152,7 +7130,7 @@ else
  #pragma alloca
 #   else
 #    ifndef alloca /* predefined by HP cc +Olibcalls */
-void *alloca (size_t);
+char *alloca ();
 #    endif
 #   endif
 #  endif
@@ -7196,7 +7174,7 @@ $as_echo "#define C_ALLOCA 1" >>confdefs.h
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' needs Cray hooks" >&5
 $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
-if ${ac_cv_os_cray+:} false; then :
+if test "${ac_cv_os_cray+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7237,7 +7215,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C alloca" >&5
 $as_echo_n "checking stack direction for C alloca... " >&6; }
-if ${ac_cv_c_stack_direction+:} false; then :
+if test "${ac_cv_c_stack_direction+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7308,7 +7286,7 @@ done
 # Checks for typedefs, structures, and compiler characteristics.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that conforms to C99" >&5
 $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if ${ac_cv_header_stdbool_h+:} false; then :
+if test "${ac_cv_header_stdbool_h+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7340,7 +7318,7 @@ else
 	char b[false == 0 ? 1 : -1];
 	char c[__bool_true_false_are_defined == 1 ? 1 : -1];
 	char d[(bool) 0.5 == true ? 1 : -1];
-	/* See body of main program for 'e'.  */
+	bool e = &s;
 	char f[(_Bool) 0.0 == false ? 1 : -1];
 	char g[true];
 	char h[sizeof (_Bool)];
@@ -7351,6 +7329,25 @@ else
 	_Bool n[m];
 	char o[sizeof n == m * sizeof n[0] ? 1 : -1];
 	char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
+#	if defined __xlc__ || defined __GNUC__
+	 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
+	    reported by James Lemley on 2005-10-05; see
+	    http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
+	    This test is not quite right, since xlc is allowed to
+	    reject this program, as the initializer for xlcbug is
+	    not one of the forms that C requires support for.
+	    However, doing the test right would require a runtime
+	    test, and that would make cross-compilation harder.
+	    Let us hope that IBM fixes the xlc bug, and also adds
+	    support for this kind of constant expression.  In the
+	    meantime, this test will reject xlc, which is OK, since
+	    our stdbool.h substitute should suffice.  We also test
+	    this with GCC, where it should work, to detect more
+	    quickly whether someone messes up the test in the
+	    future.  */
+	 char digs[] = "0123456789";
+	 int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
+#	endif
 	/* Catch a bug in an HP-UX C compiler.  See
 	   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
 	   http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
@@ -7362,7 +7359,6 @@ int
 main ()
 {
 
-	bool e = &s;
 	*pq |= q;
 	*pq |= ! q;
 	/* Refer to every declared value, to avoid compiler optimizations.  */
@@ -7383,7 +7379,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h" >&5
 $as_echo "$ac_cv_header_stdbool_h" >&6; }
 ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_default"
-if test "x$ac_cv_type__Bool" = xyes; then :
+if test "x$ac_cv_type__Bool" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE__BOOL 1
@@ -7400,7 +7396,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types.h" >&5
 $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
-if ${ac_cv_type_uid_t+:} false; then :
+if test "${ac_cv_type_uid_t+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7430,7 +7426,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
 $as_echo_n "checking for inline... " >&6; }
-if ${ac_cv_c_inline+:} false; then :
+if test "${ac_cv_c_inline+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_inline=no
@@ -7515,7 +7511,7 @@ _ACEOF
 esac
 
 ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_default"
-if test "x$ac_cv_type_mode_t" = xyes; then :
+if test "x$ac_cv_type_mode_t" = x""yes; then :
 
 else
 
@@ -7526,7 +7522,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_default"
-if test "x$ac_cv_type_off_t" = xyes; then :
+if test "x$ac_cv_type_off_t" = x""yes; then :
 
 else
 
@@ -7537,7 +7533,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_default"
-if test "x$ac_cv_type_pid_t" = xyes; then :
+if test "x$ac_cv_type_pid_t" = x""yes; then :
 
 else
 
@@ -7549,7 +7545,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
 $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if ${ac_cv_c_restrict+:} false; then :
+if test "${ac_cv_c_restrict+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_restrict=no
@@ -7594,7 +7590,7 @@ _ACEOF
  esac
 
 ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
-if test "x$ac_cv_type_size_t" = xyes; then :
+if test "x$ac_cv_type_size_t" = x""yes; then :
 
 else
 
@@ -7605,7 +7601,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_includes_default"
-if test "x$ac_cv_type_ssize_t" = xyes; then :
+if test "x$ac_cv_type_ssize_t" = x""yes; then :
 
 else
 
@@ -7616,7 +7612,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_struct_stat_st_blksize" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blksize" = xyes; then :
+if test "x$ac_cv_member_struct_stat_st_blksize" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
@@ -7626,7 +7622,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_struct_stat_st_blocks" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blocks" = xyes; then :
+if test "x$ac_cv_member_struct_stat_st_blocks" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLOCKS 1
@@ -7646,7 +7642,7 @@ fi
 
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_struct_stat_st_rdev" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_rdev" = xyes; then :
+if test "x$ac_cv_member_struct_stat_st_rdev" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_RDEV 1
@@ -7710,7 +7706,7 @@ _ACEOF
   esac
 
 ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_includes_default"
-if test "x$ac_cv_type_ptrdiff_t" = xyes; then :
+if test "x$ac_cv_type_ptrdiff_t" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_PTRDIFF_T 1
@@ -7723,7 +7719,7 @@ fi
 # Checks for library functions.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5
 $as_echo_n "checking for error_at_line... " >&6; }
-if ${ac_cv_lib_error_at_line+:} false; then :
+if test "${ac_cv_lib_error_at_line+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7759,7 +7755,7 @@ fi
 for ac_header in vfork.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h" "$ac_includes_default"
-if test "x$ac_cv_header_vfork_h" = xyes; then :
+if test "x$ac_cv_header_vfork_h" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_VFORK_H 1
 _ACEOF
@@ -7783,7 +7779,7 @@ done
 if test "x$ac_cv_func_fork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&5
 $as_echo_n "checking for working fork... " >&6; }
-if ${ac_cv_func_fork_works+:} false; then :
+if test "${ac_cv_func_fork_works+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7836,7 +7832,7 @@ ac_cv_func_vfork_works=$ac_cv_func_vfork
 if test "x$ac_cv_func_vfork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >&5
 $as_echo_n "checking for working vfork... " >&6; }
-if ${ac_cv_func_vfork_works+:} false; then :
+if test "${ac_cv_func_vfork_works+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7971,7 +7967,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE value needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files... " >&6; }
-if ${ac_cv_sys_largefile_source+:} false; then :
+if test "${ac_cv_sys_largefile_source+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   while :; do
@@ -8039,7 +8035,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctly handles trailing slash" >&5
 $as_echo_n "checking whether lstat correctly handles trailing slash... " >&6; }
-if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
+if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   rm -f conftest.sym conftest.file
@@ -8101,7 +8097,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h defines makedev" >&5
 $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
-if ${ac_cv_header_sys_types_h_makedev+:} false; then :
+if test "${ac_cv_header_sys_types_h_makedev+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8129,7 +8125,7 @@ $as_echo "$ac_cv_header_sys_types_h_makedev" >&6; }
 
 if test $ac_cv_header_sys_types_h_makedev = no; then
 ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_mkdev_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_mkdev_h" = xyes; then :
+if test "x$ac_cv_header_sys_mkdev_h" = x""yes; then :
 
 $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
 
@@ -8139,7 +8135,7 @@ fi
 
   if test $ac_cv_header_sys_mkdev_h = no; then
     ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_header_sys_sysmacros_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sysmacros_h" = xyes; then :
+if test "x$ac_cv_header_sys_sysmacros_h" = x""yes; then :
 
 $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
 
@@ -8152,7 +8148,7 @@ fi
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = xyes; then :
+if test "x$ac_cv_header_stdlib_h" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8163,7 +8159,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible malloc" >&5
 $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
-if ${ac_cv_func_malloc_0_nonnull+:} false; then :
+if test "${ac_cv_func_malloc_0_nonnull+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8218,7 +8214,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys/time.h may both be included" >&5
 $as_echo_n "checking whether time.h and sys/time.h may both be included... " >&6; }
-if ${ac_cv_header_time+:} false; then :
+if test "${ac_cv_header_time+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8293,7 +8289,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&5
 $as_echo_n "checking for working mktime... " >&6; }
-if ${ac_cv_func_working_mktime+:} false; then :
+if test "${ac_cv_func_working_mktime+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8522,7 +8518,7 @@ fi
 for ac_func in getpagesize
 do :
   ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
-if test "x$ac_cv_func_getpagesize" = xyes; then :
+if test "x$ac_cv_func_getpagesize" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_GETPAGESIZE 1
 _ACEOF
@@ -8532,7 +8528,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
 $as_echo_n "checking for working mmap... " >&6; }
-if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
+if test "${ac_cv_func_mmap_fixed_mapped+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8699,7 +8695,7 @@ rm -f conftest.mmap conftest.txt
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = xyes; then :
+if test "x$ac_cv_header_stdlib_h" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8710,7 +8706,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible realloc" >&5
 $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
-if ${ac_cv_func_realloc_0_nonnull+:} false; then :
+if test "${ac_cv_func_realloc_0_nonnull+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8763,17 +8759,13 @@ $as_echo "#define realloc rpl_realloc" >>confdefs.h
 fi
 
 
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
 $as_echo_n "checking for working strnlen... " >&6; }
-if ${ac_cv_func_strnlen_working+:} false; then :
+if test "${ac_cv_func_strnlen_working+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
-  # Guess no on AIX systems, yes otherwise.
-		case "$host_os" in
-		  aix*) ac_cv_func_strnlen_working=no;;
-		  *)    ac_cv_func_strnlen_working=yes;;
-		esac
+  ac_cv_func_strnlen_working=no
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -8822,7 +8814,7 @@ esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&5
 $as_echo_n "checking for working strtod... " >&6; }
-if ${ac_cv_func_strtod+:} false; then :
+if test "${ac_cv_func_strtod+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8881,14 +8873,14 @@ if test $ac_cv_func_strtod = no; then
 esac
 
 ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
-if test "x$ac_cv_func_pow" = xyes; then :
+if test "x$ac_cv_func_pow" = x""yes; then :
 
 fi
 
 if test $ac_cv_func_pow = no; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
 $as_echo_n "checking for pow in -lm... " >&6; }
-if ${ac_cv_lib_m_pow+:} false; then :
+if test "${ac_cv_lib_m_pow+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -8922,7 +8914,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
 $as_echo "$ac_cv_lib_m_pow" >&6; }
-if test "x$ac_cv_lib_m_pow" = xyes; then :
+if test "x$ac_cv_lib_m_pow" = x""yes; then :
   POW_LIB=-lm
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library containing definition of pow" >&5
@@ -9018,21 +9010,10 @@ $as_echo "$as_me: WARNING: cache variable $ac_var contains a newline" >&2;} ;;
      :end' >>confcache
 if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
   if test -w "$cache_file"; then
-    if test "x$cache_file" != "x/dev/null"; then
+    test "x$cache_file" != "x/dev/null" &&
       { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_file" >&5
 $as_echo "$as_me: updating cache $cache_file" >&6;}
-      if test ! -f "$cache_file" || test -h "$cache_file"; then
-	cat confcache >"$cache_file"
-      else
-        case $cache_file in #(
-        */* | ?:*)
-	  mv -f confcache "$cache_file"$$ &&
-	  mv -f "$cache_file"$$ "$cache_file" ;; #(
-        *)
-	  mv -f confcache "$cache_file" ;;
-	esac
-      fi
-    fi
+    cat confcache >$cache_file
   else
     { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cache $cache_file" >&5
 $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
@@ -9064,7 +9045,7 @@ LTLIBOBJS=$ac_ltlibobjs
 
 
 
-: "${CONFIG_STATUS=./config.status}"
+: ${CONFIG_STATUS=./config.status}
 ac_write_fail=0
 ac_clean_files_save=$ac_clean_files
 ac_clean_files="$ac_clean_files $CONFIG_STATUS"
@@ -9165,7 +9146,6 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
-as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -9473,7 +9453,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # values after options handling.
 ac_log="
 This file was extended by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.68.  Invocation command line was
+generated by GNU Autoconf 2.67.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
   CONFIG_HEADERS  = $CONFIG_HEADERS
@@ -9535,7 +9515,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
 ac_cs_version="\\
 Xen Hypervisor config.status 4.2
-configured by $0, generated by GNU Autoconf 2.68,
+configured by $0, generated by GNU Autoconf 2.67,
   with options \\"\$ac_cs_config\\"
 
 Copyright (C) 2010 Free Software Foundation, Inc.
@@ -9660,7 +9640,7 @@ do
     "../config/Xen.mk") CONFIG_FILES="$CONFIG_FILES ../config/Xen.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
-  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
+  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
   esac
 done
 
@@ -9682,10 +9662,9 @@ fi
 # after its creation but before its name has been assigned to `$tmp'.
 $debug ||
 {
-  tmp= ac_tmp=
+  tmp=
   trap 'exit_status=$?
-  : "${ac_tmp:=$tmp}"
-  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
+  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit_status
 ' 0
   trap 'as_fn_exit 1' 1 2 13 15
 }
@@ -9693,13 +9672,12 @@ $debug ||
 
 {
   tmp=`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
-  test -d "$tmp"
+  test -n "$tmp" && test -d "$tmp"
 }  ||
 {
   tmp=./conf$$-$RANDOM
   (umask 077 && mkdir "$tmp")
 } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO" 5
-ac_tmp=$tmp
 
 # Set up the scripts for CONFIG_FILES section.
 # No need to generate them if there are no CONFIG_FILES.
@@ -9721,7 +9699,7 @@ else
   ac_cs_awk_cr=$ac_cr
 fi
 
-echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
+echo 'BEGIN {' >"$tmp/subs1.awk" &&
 _ACEOF
 
 
@@ -9749,7 +9727,7 @@ done
 rm -f conf$$subs.sh
 
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
-cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
+cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
 _ACEOF
 sed -n '
 h
@@ -9797,7 +9775,7 @@ t delim
 rm -f conf$$subs.awk
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 _ACAWK
-cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
+cat >>"\$tmp/subs1.awk" <<_ACAWK &&
   for (key in S) S_is_set[key] = 1
   FS = ""
 
@@ -9829,7 +9807,7 @@ if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
   sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
 else
   cat
-fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
+fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
   || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
 _ACEOF
 
@@ -9863,7 +9841,7 @@ fi # test -n "$CONFIG_FILES"
 # No need to generate them if there are no CONFIG_HEADERS.
 # This happens for instance with `./config.status Makefile'.
 if test -n "$CONFIG_HEADERS"; then
-cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
+cat >"$tmp/defines.awk" <<\_ACAWK ||
 BEGIN {
 _ACEOF
 
@@ -9875,8 +9853,8 @@ _ACEOF
 # handling of long lines.
 ac_delim='%!_!# '
 for ac_last_try in false false :; do
-  ac_tt=`sed -n "/$ac_delim/p" confdefs.h`
-  if test -z "$ac_tt"; then
+  ac_t=`sed -n "/$ac_delim/p" confdefs.h`
+  if test -z "$ac_t"; then
     break
   elif $ac_last_try; then
     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
@@ -9977,7 +9955,7 @@ do
   esac
   case $ac_mode$ac_tag in
   :[FHL]*:*);;
-  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
+  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
   :[FH]-) ac_tag=-:-;;
   :[FH]*) ac_tag=$ac_tag:$ac_tag.in;;
   esac
@@ -9996,7 +9974,7 @@ do
     for ac_f
     do
       case $ac_f in
-      -) ac_f="$ac_tmp/stdin";;
+      -) ac_f="$tmp/stdin";;
       *) # Look for the file first in the build tree, then in the source tree
 	 # (if the path is not absolute).  The absolute path cannot be DOS-style,
 	 # because $ac_f cannot contain `:'.
@@ -10005,7 +9983,7 @@ do
 	   [\\/$]*) false;;
 	   *) test -f "$srcdir/$ac_f" && ac_f="$srcdir/$ac_f";;
 	   esac ||
-	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
+	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
       esac
       case $ac_f in *\'*) ac_f=`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\''/g"`;; esac
       as_fn_append ac_file_inputs " '$ac_f'"
@@ -10031,8 +10009,8 @@ $as_echo "$as_me: creating $ac_file" >&6;}
     esac
 
     case $ac_tag in
-    *:-:* | *:-) cat >"$ac_tmp/stdin" \
-      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
+    *:-:* | *:-) cat >"$tmp/stdin" \
+      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
     esac
     ;;
   esac
@@ -10162,22 +10140,21 @@ s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
 s&@INSTALL@&$ac_INSTALL&;t t
 $ac_datarootdir_hack
 "
-eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.awk" \
-  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5
+eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" >$tmp/out \
+  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
 
 test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
-  { ac_out=`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_out"; } &&
-  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' \
-      "$ac_tmp/out"`; test -z "$ac_out"; } &&
+  { ac_out=`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"; } &&
+  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' "$tmp/out"`; test -z "$ac_out"; } &&
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&5
 $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&2;}
 
-  rm -f "$ac_tmp/stdin"
+  rm -f "$tmp/stdin"
   case $ac_file in
-  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
-  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
+  -) cat "$tmp/out" && rm -f "$tmp/out";;
+  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
   esac \
   || as_fn_error $? "could not create $ac_file" "$LINENO" 5
  ;;
@@ -10188,20 +10165,20 @@ which seems to be undefined.  Please make sure it is defined" >&2;}
   if test x"$ac_file" != x-; then
     {
       $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
-    } >"$ac_tmp/config.h" \
+      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
+    } >"$tmp/config.h" \
       || as_fn_error $? "could not create $ac_file" "$LINENO" 5
-    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
+    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
 $as_echo "$as_me: $ac_file is unchanged" >&6;}
     else
       rm -f "$ac_file"
-      mv "$ac_tmp/config.h" "$ac_file" \
+      mv "$tmp/config.h" "$ac_file" \
 	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
     fi
   else
     $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
+      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
       || as_fn_error $? "could not create -" "$LINENO" 5
   fi
  ;;
diff --git a/tools/configure.ac b/tools/configure.ac
index 5b2815d..b0668b4 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -64,7 +64,6 @@ AX_SET_FLAGS
 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
 AC_ARG_VAR([IP], [Path to ip tool])
-AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
 AC_ARG_VAR([CURL], [Path to curl-config tool])
 AC_ARG_VAR([XML], [Path to xml2-config tool])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:25:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kSy-0004QD-TN; Wed, 29 Feb 2012 14:25: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 1S2kSw-0004Q8-MR
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:25:15 +0000
Received: from [85.158.139.83:19346] by server-12.bemta-5.messagelabs.com id
	04/87-05587-9453E4F4; Wed, 29 Feb 2012 14:25:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330525509!17169629!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjM3NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10280 invoked from network); 29 Feb 2012 14:25:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325480400"; d="scan'208";a="22562010"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:25:08 -0500
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 09:25:08 -0500
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1S2kSp-0002MQ-Rb;
	Wed, 29 Feb 2012 14:25:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 14:25:07 +0000
Message-ID: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I _think_ this isn't required because we also checkin the generated files. A
more complete fix might also allow the user to force regeneration but I didn't
both here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/configure    |  559 +++++++++++++++++++++++++---------------------------
 tools/configure.ac |    1 -
 2 files changed, 268 insertions(+), 292 deletions(-)

diff --git a/tools/configure b/tools/configure
index 5fe72cf..96509b6 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.68 for Xen Hypervisor 4.2.
+# Generated by GNU Autoconf 2.67 for Xen Hypervisor 4.2.
 #
 # Report bugs to <xen-devel@lists.xensource.com>.
 #
@@ -91,7 +91,6 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
-as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -217,18 +216,11 @@ IFS=$as_save_IFS
   # We cannot yet assume a decent shell, so we have to provide a
 	# neutralization value for shells without unset; and this also
 	# works around shells that cannot unset nonexistent variables.
-	# Preserve -v and -x to the replacement shell.
 	BASH_ENV=/dev/null
 	ENV=/dev/null
 	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
 	export CONFIG_SHELL
-	case $- in # ((((
-	  *v*x* | *x*v* ) as_opts=-vx ;;
-	  *v* ) as_opts=-v ;;
-	  *x* ) as_opts=-x ;;
-	  * ) as_opts= ;;
-	esac
-	exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"}
+	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
 fi
 
     if test x$as_have_required = xno; then :
@@ -633,6 +625,7 @@ OCAMLOPT
 OCAMLLIB
 OCAMLVERSION
 OCAMLC
+BISON
 INSTALL_DATA
 INSTALL_SCRIPT
 INSTALL_PROGRAM
@@ -644,7 +637,6 @@ BASH
 XML
 CURL
 FLEX
-BISON
 IP
 PERL
 PYTHON
@@ -748,7 +740,6 @@ APPEND_LIB
 PYTHON
 PERL
 IP
-BISON
 FLEX
 CURL
 XML
@@ -1163,7 +1154,7 @@ Try \`$0 --help' for more information"
     $as_echo "$as_me: WARNING: you should use --build, --host, --target" >&2
     expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
       $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
-    : "${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}"
+    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
     ;;
 
   esac
@@ -1403,7 +1394,6 @@ Some influential environment variables:
   PYTHON      Path to the Python parser
   PERL        Path to Perl parser
   IP          Path to ip tool
-  BISON       Path to Bison parser generator
   FLEX        Path to Flex lexical analyser generator
   CURL        Path to curl-config tool
   XML         Path to xml2-config tool
@@ -1484,7 +1474,7 @@ test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
 Xen Hypervisor configure 4.2
-generated by GNU Autoconf 2.68
+generated by GNU Autoconf 2.67
 
 Copyright (C) 2010 Free Software Foundation, Inc.
 This configure script is free software; the Free Software Foundation
@@ -1530,7 +1520,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
 	ac_retval=1
 fi
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_compile
@@ -1567,7 +1557,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 
     ac_retval=1
 fi
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_cpp
@@ -1580,10 +1570,10 @@ fi
 ac_fn_c_check_header_mongrel ()
 {
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  if eval \${$3+:} false; then :
+  if eval "test \"\${$3+set}\"" = set; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 fi
 eval ac_res=\$$3
@@ -1650,7 +1640,7 @@ $as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
 esac
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=\$ac_header_compiler"
@@ -1659,7 +1649,7 @@ eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
 fi
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_header_mongrel
 
@@ -1700,7 +1690,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
        ac_retval=$ac_status
 fi
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_run
@@ -1714,7 +1704,7 @@ ac_fn_c_check_header_compile ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1732,7 +1722,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_header_compile
 
@@ -1777,65 +1767,11 @@ fi
   # interfere with the next link command; also delete a directory that is
   # left behind by Apple's compiler.  We do this before executing the actions.
   rm -rf conftest.dSYM conftest_ipa8_conftest.oo
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
   as_fn_set_status $ac_retval
 
 } # ac_fn_c_try_link
 
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cache
-# variable VAR accordingly.
-ac_fn_c_check_type ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  eval "$3=no"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof ($2))
-	 return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-$4
-int
-main ()
-{
-if (sizeof (($2)))
-	    return 0;
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  eval "$3=yes"
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-eval ac_res=\$$3
-	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
-$as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
-
-} # ac_fn_c_check_type
-
 # ac_fn_c_check_func LINENO FUNC VAR
 # ----------------------------------
 # Tests whether FUNC exists, setting the cache variable VAR accordingly
@@ -1844,7 +1780,7 @@ ac_fn_c_check_func ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
 $as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -1899,10 +1835,64 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_func
 
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cache
+# variable VAR accordingly.
+ac_fn_c_check_type ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval "test \"\${$3+set}\"" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  eval "$3=no"
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof ($2))
+	 return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+if (sizeof (($2)))
+	    return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+
+else
+  eval "$3=yes"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=\$$3
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
+
+} # ac_fn_c_check_type
+
 # ac_fn_c_find_intX_t LINENO BITS VAR
 # -----------------------------------
 # Finds a signed integer type with width BITS, setting cache variable VAR
@@ -1912,7 +1902,7 @@ ac_fn_c_find_intX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for int$2_t" >&5
 $as_echo_n "checking for int$2_t... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -1973,7 +1963,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_find_intX_t
 
@@ -1986,7 +1976,7 @@ ac_fn_c_check_member ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
 $as_echo_n "checking for $2.$3... " >&6; }
-if eval \${$4+:} false; then :
+if eval "test \"\${$4+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -2030,7 +2020,7 @@ fi
 eval ac_res=\$$4
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_check_member
 
@@ -2043,7 +2033,7 @@ ac_fn_c_find_uintX_t ()
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uint$2_t" >&5
 $as_echo_n "checking for uint$2_t... " >&6; }
-if eval \${$3+:} false; then :
+if eval "test \"\${$3+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   eval "$3=no"
@@ -2083,7 +2073,7 @@ fi
 eval ac_res=\$$3
 	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
 $as_echo "$ac_res" >&6; }
-  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
 
 } # ac_fn_c_find_uintX_t
 cat >config.log <<_ACEOF
@@ -2091,7 +2081,7 @@ This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
 It was created by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.68.  Invocation command line was
+generated by GNU Autoconf 2.67.  Invocation command line was
 
   $ $0 $@
 
@@ -2349,7 +2339,7 @@ $as_echo "$as_me: loading site script $ac_site_file" >&6;}
       || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
   fi
 done
 
@@ -2504,7 +2494,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2544,7 +2534,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2597,7 +2587,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2637,7 +2627,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2696,7 +2686,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -2740,7 +2730,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -2795,7 +2785,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -2910,7 +2900,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -2953,7 +2943,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and link
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3012,7 +3002,7 @@ $as_echo "$ac_try_echo"; } >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
     fi
   fi
 fi
@@ -3023,7 +3013,7 @@ rm -f conftest.$ac_ext conftest$ac_cv_exeext conftest.out
 ac_clean_files=$ac_clean_files_save
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
 $as_echo_n "checking for suffix of object files... " >&6; }
-if ${ac_cv_objext+:} false; then :
+if test "${ac_cv_objext+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3064,7 +3054,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 rm -f conftest.$ac_cv_objext conftest.$ac_ext
 fi
@@ -3074,7 +3064,7 @@ OBJEXT=$ac_cv_objext
 ac_objext=$OBJEXT
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if ${ac_cv_c_compiler_gnu+:} false; then :
+if test "${ac_cv_c_compiler_gnu+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3111,7 +3101,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if ${ac_cv_prog_cc_g+:} false; then :
+if test "${ac_cv_prog_cc_g+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -3189,7 +3179,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if ${ac_cv_prog_cc_c89+:} false; then :
+if test "${ac_cv_prog_cc_c89+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -3297,7 +3287,7 @@ if test -n "$CPP" && test -d "$CPP"; then
   CPP=
 fi
 if test -z "$CPP"; then
-  if ${ac_cv_prog_CPP+:} false; then :
+  if test "${ac_cv_prog_CPP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
       # Double quotes because CPP needs to be expanded
@@ -3413,7 +3403,7 @@ else
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 
 ac_ext=c
@@ -3425,7 +3415,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long lines and -e" >&5
 $as_echo_n "checking for grep that handles long lines and -e... " >&6; }
-if ${ac_cv_path_GREP+:} false; then :
+if test "${ac_cv_path_GREP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -z "$GREP"; then
@@ -3488,7 +3478,7 @@ $as_echo "$ac_cv_path_GREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
 $as_echo_n "checking for egrep... " >&6; }
-if ${ac_cv_path_EGREP+:} false; then :
+if test "${ac_cv_path_EGREP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
@@ -3555,7 +3545,7 @@ $as_echo "$ac_cv_path_EGREP" >&6; }
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header files" >&5
 $as_echo_n "checking for ANSI C header files... " >&6; }
-if ${ac_cv_header_stdc+:} false; then :
+if test "${ac_cv_header_stdc+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3684,7 +3674,7 @@ done
 
 
   ac_fn_c_check_header_mongrel "$LINENO" "minix/config.h" "ac_cv_header_minix_config_h" "$ac_includes_default"
-if test "x$ac_cv_header_minix_config_h" = xyes; then :
+if test "x$ac_cv_header_minix_config_h" = x""yes; then :
   MINIX=yes
 else
   MINIX=
@@ -3706,7 +3696,7 @@ $as_echo "#define _MINIX 1" >>confdefs.h
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether it is safe to define __EXTENSIONS__" >&5
 $as_echo_n "checking whether it is safe to define __EXTENSIONS__... " >&6; }
-if ${ac_cv_safe_to_define___extensions__+:} false; then :
+if test "${ac_cv_safe_to_define___extensions__+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -3749,7 +3739,7 @@ $SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
 $as_echo_n "checking build system type... " >&6; }
-if ${ac_cv_build+:} false; then :
+if test "${ac_cv_build+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_build_alias=$build_alias
@@ -3765,7 +3755,7 @@ fi
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
 esac
 build=$ac_cv_build
 ac_save_IFS=$IFS; IFS='-'
@@ -3783,7 +3773,7 @@ case $build_os in *\ *) build_os=`echo "$build_os" | sed 's/ /-/g'`;; esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
 $as_echo_n "checking host system type... " >&6; }
-if ${ac_cv_host+:} false; then :
+if test "${ac_cv_host+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "x$host_alias" = x; then
@@ -3798,7 +3788,7 @@ fi
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
 esac
 host=$ac_cv_host
 ac_save_IFS=$IFS; IFS='-'
@@ -4168,11 +4158,10 @@ LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"
 
 
 
-
 # Checks for programs.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
 $as_echo_n "checking for a sed that does not truncate output... " >&6; }
-if ${ac_cv_path_SED+:} false; then :
+if test "${ac_cv_path_SED+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
             ac_script=s/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/
@@ -4249,7 +4238,7 @@ if test -n "$ac_tool_prefix"; then
 set dummy ${ac_tool_prefix}gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4289,7 +4278,7 @@ if test -z "$ac_cv_prog_CC"; then
 set dummy gcc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4342,7 +4331,7 @@ if test -z "$CC"; then
 set dummy ${ac_tool_prefix}cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4382,7 +4371,7 @@ if test -z "$CC"; then
 set dummy cc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4441,7 +4430,7 @@ if test -z "$CC"; then
 set dummy $ac_tool_prefix$ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_CC+:} false; then :
+if test "${ac_cv_prog_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$CC"; then
@@ -4485,7 +4474,7 @@ do
 set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CC+:} false; then :
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_CC"; then
@@ -4540,7 +4529,7 @@ fi
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -4569,7 +4558,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
 $as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
-if ${ac_cv_c_compiler_gnu+:} false; then :
+if test "${ac_cv_c_compiler_gnu+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -4606,7 +4595,7 @@ ac_test_CFLAGS=${CFLAGS+set}
 ac_save_CFLAGS=$CFLAGS
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
 $as_echo_n "checking whether $CC accepts -g... " >&6; }
-if ${ac_cv_prog_cc_g+:} false; then :
+if test "${ac_cv_prog_cc_g+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_save_c_werror_flag=$ac_c_werror_flag
@@ -4684,7 +4673,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
 $as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
-if ${ac_cv_prog_cc_c89+:} false; then :
+if test "${ac_cv_prog_cc_c89+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_prog_cc_c89=no
@@ -4794,7 +4783,7 @@ fi
 $as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
 set x ${MAKE-make}
 ac_make=`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
-if eval \${ac_cv_prog_make_${ac_make}_set+:} false; then :
+if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat >conftest.make <<\_ACEOF
@@ -4838,7 +4827,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible install" >&5
 $as_echo_n "checking for a BSD-compatible install... " >&6; }
 if test -z "$INSTALL"; then
-if ${ac_cv_path_install+:} false; then :
+if test "${ac_cv_path_install+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -4918,7 +4907,7 @@ test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 set dummy perl; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_PERL+:} false; then :
+if test "${ac_cv_path_PERL+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $PERL in
@@ -4963,7 +4952,7 @@ fi
 set dummy ip; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_IP+:} false; then :
+if test "${ac_cv_path_IP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $IP in
@@ -5008,7 +4997,7 @@ fi
 set dummy bison; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_BISON+:} false; then :
+if test "${ac_cv_path_BISON+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $BISON in
@@ -5053,7 +5042,7 @@ fi
 set dummy flex; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_FLEX+:} false; then :
+if test "${ac_cv_path_FLEX+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $FLEX in
@@ -5100,7 +5089,7 @@ if test "x$xapi" = "xy"; then :
 set dummy curl-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_CURL+:} false; then :
+if test "${ac_cv_path_CURL+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $CURL in
@@ -5145,7 +5134,7 @@ fi
 set dummy xml2-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_XML+:} false; then :
+if test "${ac_cv_path_XML+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $XML in
@@ -5196,7 +5185,7 @@ if test "x$ocamltools" = "xy"; then :
 set dummy ${ac_tool_prefix}ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLC+:} false; then :
+if test "${ac_cv_prog_OCAMLC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLC"; then
@@ -5236,7 +5225,7 @@ if test -z "$ac_cv_prog_OCAMLC"; then
 set dummy ocamlc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLC+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLC"; then
@@ -5307,7 +5296,7 @@ $as_echo "OCaml library path is $OCAMLLIB" >&6; }
 set dummy ${ac_tool_prefix}ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLOPT+:} false; then :
+if test "${ac_cv_prog_OCAMLOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPT"; then
@@ -5347,7 +5336,7 @@ if test -z "$ac_cv_prog_OCAMLOPT"; then
 set dummy ocamlopt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLOPT+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPT"; then
@@ -5417,7 +5406,7 @@ $as_echo "versions differs from ocamlc; ocamlopt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLCDOTOPT+:} false; then :
+if test "${ac_cv_prog_OCAMLCDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLCDOTOPT"; then
@@ -5457,7 +5446,7 @@ if test -z "$ac_cv_prog_OCAMLCDOTOPT"; then
 set dummy ocamlc.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLCDOTOPT+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLCDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLCDOTOPT"; then
@@ -5521,7 +5510,7 @@ $as_echo "versions differs from ocamlc; ocamlc.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLOPTDOTOPT+:} false; then :
+if test "${ac_cv_prog_OCAMLOPTDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLOPTDOTOPT"; then
@@ -5561,7 +5550,7 @@ if test -z "$ac_cv_prog_OCAMLOPTDOTOPT"; then
 set dummy ocamlopt.opt; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLOPTDOTOPT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLOPTDOTOPT"; then
@@ -5630,7 +5619,7 @@ $as_echo "version differs from ocamlc; ocamlopt.opt discarded." >&6; }
 set dummy ${ac_tool_prefix}ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAML+:} false; then :
+if test "${ac_cv_prog_OCAML+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAML"; then
@@ -5670,7 +5659,7 @@ if test -z "$ac_cv_prog_OCAML"; then
 set dummy ocaml; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAML+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAML+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAML"; then
@@ -5724,7 +5713,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLDEP+:} false; then :
+if test "${ac_cv_prog_OCAMLDEP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDEP"; then
@@ -5764,7 +5753,7 @@ if test -z "$ac_cv_prog_OCAMLDEP"; then
 set dummy ocamldep; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLDEP+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLDEP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDEP"; then
@@ -5818,7 +5807,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLMKTOP+:} false; then :
+if test "${ac_cv_prog_OCAMLMKTOP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKTOP"; then
@@ -5858,7 +5847,7 @@ if test -z "$ac_cv_prog_OCAMLMKTOP"; then
 set dummy ocamlmktop; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLMKTOP+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLMKTOP+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKTOP"; then
@@ -5912,7 +5901,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLMKLIB+:} false; then :
+if test "${ac_cv_prog_OCAMLMKLIB+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLMKLIB"; then
@@ -5952,7 +5941,7 @@ if test -z "$ac_cv_prog_OCAMLMKLIB"; then
 set dummy ocamlmklib; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLMKLIB+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLMKLIB+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLMKLIB"; then
@@ -6006,7 +5995,7 @@ fi
 set dummy ${ac_tool_prefix}ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLDOC+:} false; then :
+if test "${ac_cv_prog_OCAMLDOC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLDOC"; then
@@ -6046,7 +6035,7 @@ if test -z "$ac_cv_prog_OCAMLDOC"; then
 set dummy ocamldoc; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLDOC+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLDOC+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLDOC"; then
@@ -6100,7 +6089,7 @@ fi
 set dummy ${ac_tool_prefix}ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_OCAMLBUILD+:} false; then :
+if test "${ac_cv_prog_OCAMLBUILD+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$OCAMLBUILD"; then
@@ -6140,7 +6129,7 @@ if test -z "$ac_cv_prog_OCAMLBUILD"; then
 set dummy ocamlbuild; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_OCAMLBUILD+:} false; then :
+if test "${ac_cv_prog_ac_ct_OCAMLBUILD+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test -n "$ac_ct_OCAMLBUILD"; then
@@ -6203,7 +6192,7 @@ fi
 set dummy bash; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_BASH+:} false; then :
+if test "${ac_cv_path_BASH+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $BASH in
@@ -6260,7 +6249,7 @@ fi
 set dummy $PYTHON; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_PYTHONPATH+:} false; then :
+if test "${ac_cv_path_PYTHONPATH+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $PYTHONPATH in
@@ -6352,7 +6341,7 @@ fi
 set dummy xgettext; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_XGETTEXT+:} false; then :
+if test "${ac_cv_path_XGETTEXT+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $XGETTEXT in
@@ -6396,7 +6385,7 @@ fi
 if test "x$host_os" == "xlinux-gnu"
 then
     ac_fn_c_check_header_mongrel "$LINENO" "uuid/uuid.h" "ac_cv_header_uuid_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_uuid_h" = xyes; then :
+if test "x$ac_cv_header_uuid_uuid_h" = x""yes; then :
 
 else
   as_fn_error $? "cannot find uuid headers" "$LINENO" 5
@@ -6405,7 +6394,7 @@ fi
 
 else
     ac_fn_c_check_header_mongrel "$LINENO" "uuid.h" "ac_cv_header_uuid_h" "$ac_includes_default"
-if test "x$ac_cv_header_uuid_h" = xyes; then :
+if test "x$ac_cv_header_uuid_h" = x""yes; then :
 
 else
   as_fn_error $? "cannot find uuid headers" "$LINENO" 5
@@ -6426,7 +6415,7 @@ if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
 set dummy ${ac_tool_prefix}pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_PKG_CONFIG+:} false; then :
+if test "${ac_cv_path_PKG_CONFIG+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $PKG_CONFIG in
@@ -6469,7 +6458,7 @@ if test -z "$ac_cv_path_PKG_CONFIG"; then
 set dummy pkg-config; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_ac_pt_PKG_CONFIG+:} false; then :
+if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   case $ac_pt_PKG_CONFIG in
@@ -6614,7 +6603,7 @@ and glib_LIBS to avoid the need to call pkg-config.
 See the pkg-config man page for more details.
 
 To get pkg-config, see <http://pkg-config.freedesktop.org/>.
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 else
 	glib_CFLAGS=$pkg_cv_glib_CFLAGS
 	glib_LIBS=$pkg_cv_glib_LIBS
@@ -6638,7 +6627,7 @@ fi
 # Checks for libraries.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for io_setup in -laio" >&5
 $as_echo_n "checking for io_setup in -laio... " >&6; }
-if ${ac_cv_lib_aio_io_setup+:} false; then :
+if test "${ac_cv_lib_aio_io_setup+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6672,7 +6661,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aio_io_setup" >&5
 $as_echo "$ac_cv_lib_aio_io_setup" >&6; }
-if test "x$ac_cv_lib_aio_io_setup" = xyes; then :
+if test "x$ac_cv_lib_aio_io_setup" = x""yes; then :
   system_aio="y"
 else
   system_aio="n"
@@ -6681,7 +6670,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for MD5 in -lcrypto" >&5
 $as_echo_n "checking for MD5 in -lcrypto... " >&6; }
-if ${ac_cv_lib_crypto_MD5+:} false; then :
+if test "${ac_cv_lib_crypto_MD5+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6715,7 +6704,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_crypto_MD5" >&5
 $as_echo "$ac_cv_lib_crypto_MD5" >&6; }
-if test "x$ac_cv_lib_crypto_MD5" = xyes; then :
+if test "x$ac_cv_lib_crypto_MD5" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBCRYPTO 1
 _ACEOF
@@ -6728,7 +6717,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ext2fs_open2 in -lext2fs" >&5
 $as_echo_n "checking for ext2fs_open2 in -lext2fs... " >&6; }
-if ${ac_cv_lib_ext2fs_ext2fs_open2+:} false; then :
+if test "${ac_cv_lib_ext2fs_ext2fs_open2+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6762,7 +6751,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ext2fs_ext2fs_open2" >&5
 $as_echo "$ac_cv_lib_ext2fs_ext2fs_open2" >&6; }
-if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = xyes; then :
+if test "x$ac_cv_lib_ext2fs_ext2fs_open2" = x""yes; then :
   libext2fs="y"
 else
   libext2fs="n"
@@ -6771,7 +6760,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffer in -lgcrypt" >&5
 $as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
+if test "${ac_cv_lib_gcrypt_gcry_md_hash_buffer+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6805,7 +6794,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&5
 $as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = xyes; then :
+if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = x""yes; then :
   libgcrypt="y"
 else
   libgcrypt="n"
@@ -6814,7 +6803,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_create in -lpthread" >&5
 $as_echo_n "checking for pthread_create in -lpthread... " >&6; }
-if ${ac_cv_lib_pthread_pthread_create+:} false; then :
+if test "${ac_cv_lib_pthread_pthread_create+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6848,7 +6837,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_create" >&5
 $as_echo "$ac_cv_lib_pthread_pthread_create" >&6; }
-if test "x$ac_cv_lib_pthread_pthread_create" = xyes; then :
+if test "x$ac_cv_lib_pthread_pthread_create" = x""yes; then :
 
 else
   as_fn_error $? "Could not find libpthread" "$LINENO" 5
@@ -6856,7 +6845,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_gettime in -lrt" >&5
 $as_echo_n "checking for clock_gettime in -lrt... " >&6; }
-if ${ac_cv_lib_rt_clock_gettime+:} false; then :
+if test "${ac_cv_lib_rt_clock_gettime+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6890,7 +6879,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_rt_clock_gettime" >&5
 $as_echo "$ac_cv_lib_rt_clock_gettime" >&6; }
-if test "x$ac_cv_lib_rt_clock_gettime" = xyes; then :
+if test "x$ac_cv_lib_rt_clock_gettime" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBRT 1
 _ACEOF
@@ -6901,7 +6890,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_clear in -luuid" >&5
 $as_echo_n "checking for uuid_clear in -luuid... " >&6; }
-if ${ac_cv_lib_uuid_uuid_clear+:} false; then :
+if test "${ac_cv_lib_uuid_uuid_clear+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6935,7 +6924,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_uuid_uuid_clear" >&5
 $as_echo "$ac_cv_lib_uuid_uuid_clear" >&6; }
-if test "x$ac_cv_lib_uuid_uuid_clear" = xyes; then :
+if test "x$ac_cv_lib_uuid_uuid_clear" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBUUID 1
 _ACEOF
@@ -6948,7 +6937,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5
 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; }
-if ${ac_cv_lib_yajl_yajl_alloc+:} false; then :
+if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -6982,7 +6971,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_yajl_yajl_alloc" >&5
 $as_echo "$ac_cv_lib_yajl_yajl_alloc" >&6; }
-if test "x$ac_cv_lib_yajl_yajl_alloc" = xyes; then :
+if test "x$ac_cv_lib_yajl_yajl_alloc" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBYAJL 1
 _ACEOF
@@ -6995,7 +6984,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflateCopy in -lz" >&5
 $as_echo_n "checking for deflateCopy in -lz... " >&6; }
-if ${ac_cv_lib_z_deflateCopy+:} false; then :
+if test "${ac_cv_lib_z_deflateCopy+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7029,7 +7018,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_z_deflateCopy" >&5
 $as_echo "$ac_cv_lib_z_deflateCopy" >&6; }
-if test "x$ac_cv_lib_z_deflateCopy" = xyes; then :
+if test "x$ac_cv_lib_z_deflateCopy" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_LIBZ 1
 _ACEOF
@@ -7042,7 +7031,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for libiconv_open in -liconv" >&5
 $as_echo_n "checking for libiconv_open in -liconv... " >&6; }
-if ${ac_cv_lib_iconv_libiconv_open+:} false; then :
+if test "${ac_cv_lib_iconv_libiconv_open+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -7076,7 +7065,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_iconv_libiconv_open" >&5
 $as_echo "$ac_cv_lib_iconv_libiconv_open" >&6; }
-if test "x$ac_cv_lib_iconv_libiconv_open" = xyes; then :
+if test "x$ac_cv_lib_iconv_libiconv_open" = x""yes; then :
   libiconv="y"
 else
   libiconv="n"
@@ -7085,22 +7074,11 @@ fi
 
 
 # Checks for header files.
-ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
-if test "x$ac_cv_type_size_t" = xyes; then :
-
-else
-
-cat >>confdefs.h <<_ACEOF
-#define size_t unsigned int
-_ACEOF
-
-fi
-
 # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works
 # for constant arguments.  Useless!
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working alloca.h" >&5
 $as_echo_n "checking for working alloca.h... " >&6; }
-if ${ac_cv_working_alloca_h+:} false; then :
+if test "${ac_cv_working_alloca_h+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7133,7 +7111,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for alloca" >&5
 $as_echo_n "checking for alloca... " >&6; }
-if ${ac_cv_func_alloca_works+:} false; then :
+if test "${ac_cv_func_alloca_works+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7152,7 +7130,7 @@ else
  #pragma alloca
 #   else
 #    ifndef alloca /* predefined by HP cc +Olibcalls */
-void *alloca (size_t);
+char *alloca ();
 #    endif
 #   endif
 #  endif
@@ -7196,7 +7174,7 @@ $as_echo "#define C_ALLOCA 1" >>confdefs.h
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether \`alloca.c' needs Cray hooks" >&5
 $as_echo_n "checking whether \`alloca.c' needs Cray hooks... " >&6; }
-if ${ac_cv_os_cray+:} false; then :
+if test "${ac_cv_os_cray+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7237,7 +7215,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking stack direction for C alloca" >&5
 $as_echo_n "checking stack direction for C alloca... " >&6; }
-if ${ac_cv_c_stack_direction+:} false; then :
+if test "${ac_cv_c_stack_direction+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7308,7 +7286,7 @@ done
 # Checks for typedefs, structures, and compiler characteristics.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that conforms to C99" >&5
 $as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if ${ac_cv_header_stdbool_h+:} false; then :
+if test "${ac_cv_header_stdbool_h+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7340,7 +7318,7 @@ else
 	char b[false == 0 ? 1 : -1];
 	char c[__bool_true_false_are_defined == 1 ? 1 : -1];
 	char d[(bool) 0.5 == true ? 1 : -1];
-	/* See body of main program for 'e'.  */
+	bool e = &s;
 	char f[(_Bool) 0.0 == false ? 1 : -1];
 	char g[true];
 	char h[sizeof (_Bool)];
@@ -7351,6 +7329,25 @@ else
 	_Bool n[m];
 	char o[sizeof n == m * sizeof n[0] ? 1 : -1];
 	char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
+#	if defined __xlc__ || defined __GNUC__
+	 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
+	    reported by James Lemley on 2005-10-05; see
+	    http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
+	    This test is not quite right, since xlc is allowed to
+	    reject this program, as the initializer for xlcbug is
+	    not one of the forms that C requires support for.
+	    However, doing the test right would require a runtime
+	    test, and that would make cross-compilation harder.
+	    Let us hope that IBM fixes the xlc bug, and also adds
+	    support for this kind of constant expression.  In the
+	    meantime, this test will reject xlc, which is OK, since
+	    our stdbool.h substitute should suffice.  We also test
+	    this with GCC, where it should work, to detect more
+	    quickly whether someone messes up the test in the
+	    future.  */
+	 char digs[] = "0123456789";
+	 int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
+#	endif
 	/* Catch a bug in an HP-UX C compiler.  See
 	   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
 	   http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
@@ -7362,7 +7359,6 @@ int
 main ()
 {
 
-	bool e = &s;
 	*pq |= q;
 	*pq |= ! q;
 	/* Refer to every declared value, to avoid compiler optimizations.  */
@@ -7383,7 +7379,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h" >&5
 $as_echo "$ac_cv_header_stdbool_h" >&6; }
 ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_default"
-if test "x$ac_cv_type__Bool" = xyes; then :
+if test "x$ac_cv_type__Bool" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE__BOOL 1
@@ -7400,7 +7396,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types.h" >&5
 $as_echo_n "checking for uid_t in sys/types.h... " >&6; }
-if ${ac_cv_type_uid_t+:} false; then :
+if test "${ac_cv_type_uid_t+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7430,7 +7426,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
 $as_echo_n "checking for inline... " >&6; }
-if ${ac_cv_c_inline+:} false; then :
+if test "${ac_cv_c_inline+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_inline=no
@@ -7515,7 +7511,7 @@ _ACEOF
 esac
 
 ac_fn_c_check_type "$LINENO" "mode_t" "ac_cv_type_mode_t" "$ac_includes_default"
-if test "x$ac_cv_type_mode_t" = xyes; then :
+if test "x$ac_cv_type_mode_t" = x""yes; then :
 
 else
 
@@ -7526,7 +7522,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_default"
-if test "x$ac_cv_type_off_t" = xyes; then :
+if test "x$ac_cv_type_off_t" = x""yes; then :
 
 else
 
@@ -7537,7 +7533,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_default"
-if test "x$ac_cv_type_pid_t" = xyes; then :
+if test "x$ac_cv_type_pid_t" = x""yes; then :
 
 else
 
@@ -7549,7 +7545,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
 $as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if ${ac_cv_c_restrict+:} false; then :
+if test "${ac_cv_c_restrict+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_cv_c_restrict=no
@@ -7594,7 +7590,7 @@ _ACEOF
  esac
 
 ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
-if test "x$ac_cv_type_size_t" = xyes; then :
+if test "x$ac_cv_type_size_t" = x""yes; then :
 
 else
 
@@ -7605,7 +7601,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_includes_default"
-if test "x$ac_cv_type_ssize_t" = xyes; then :
+if test "x$ac_cv_type_ssize_t" = x""yes; then :
 
 else
 
@@ -7616,7 +7612,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blksize" "ac_cv_member_struct_stat_st_blksize" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blksize" = xyes; then :
+if test "x$ac_cv_member_struct_stat_st_blksize" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
@@ -7626,7 +7622,7 @@ _ACEOF
 fi
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_blocks" "ac_cv_member_struct_stat_st_blocks" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_blocks" = xyes; then :
+if test "x$ac_cv_member_struct_stat_st_blocks" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_BLOCKS 1
@@ -7646,7 +7642,7 @@ fi
 
 
 ac_fn_c_check_member "$LINENO" "struct stat" "st_rdev" "ac_cv_member_struct_stat_st_rdev" "$ac_includes_default"
-if test "x$ac_cv_member_struct_stat_st_rdev" = xyes; then :
+if test "x$ac_cv_member_struct_stat_st_rdev" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_STRUCT_STAT_ST_RDEV 1
@@ -7710,7 +7706,7 @@ _ACEOF
   esac
 
 ac_fn_c_check_type "$LINENO" "ptrdiff_t" "ac_cv_type_ptrdiff_t" "$ac_includes_default"
-if test "x$ac_cv_type_ptrdiff_t" = xyes; then :
+if test "x$ac_cv_type_ptrdiff_t" = x""yes; then :
 
 cat >>confdefs.h <<_ACEOF
 #define HAVE_PTRDIFF_T 1
@@ -7723,7 +7719,7 @@ fi
 # Checks for library functions.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for error_at_line" >&5
 $as_echo_n "checking for error_at_line... " >&6; }
-if ${ac_cv_lib_error_at_line+:} false; then :
+if test "${ac_cv_lib_error_at_line+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -7759,7 +7755,7 @@ fi
 for ac_header in vfork.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "vfork.h" "ac_cv_header_vfork_h" "$ac_includes_default"
-if test "x$ac_cv_header_vfork_h" = xyes; then :
+if test "x$ac_cv_header_vfork_h" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_VFORK_H 1
 _ACEOF
@@ -7783,7 +7779,7 @@ done
 if test "x$ac_cv_func_fork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working fork" >&5
 $as_echo_n "checking for working fork... " >&6; }
-if ${ac_cv_func_fork_works+:} false; then :
+if test "${ac_cv_func_fork_works+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7836,7 +7832,7 @@ ac_cv_func_vfork_works=$ac_cv_func_vfork
 if test "x$ac_cv_func_vfork" = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vfork" >&5
 $as_echo_n "checking for working vfork... " >&6; }
-if ${ac_cv_func_vfork_works+:} false; then :
+if test "${ac_cv_func_vfork_works+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -7971,7 +7967,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE value needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files... " >&6; }
-if ${ac_cv_sys_largefile_source+:} false; then :
+if test "${ac_cv_sys_largefile_source+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   while :; do
@@ -8039,7 +8035,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether lstat correctly handles trailing slash" >&5
 $as_echo_n "checking whether lstat correctly handles trailing slash... " >&6; }
-if ${ac_cv_func_lstat_dereferences_slashed_symlink+:} false; then :
+if test "${ac_cv_func_lstat_dereferences_slashed_symlink+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   rm -f conftest.sym conftest.file
@@ -8101,7 +8097,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether sys/types.h defines makedev" >&5
 $as_echo_n "checking whether sys/types.h defines makedev... " >&6; }
-if ${ac_cv_header_sys_types_h_makedev+:} false; then :
+if test "${ac_cv_header_sys_types_h_makedev+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8129,7 +8125,7 @@ $as_echo "$ac_cv_header_sys_types_h_makedev" >&6; }
 
 if test $ac_cv_header_sys_types_h_makedev = no; then
 ac_fn_c_check_header_mongrel "$LINENO" "sys/mkdev.h" "ac_cv_header_sys_mkdev_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_mkdev_h" = xyes; then :
+if test "x$ac_cv_header_sys_mkdev_h" = x""yes; then :
 
 $as_echo "#define MAJOR_IN_MKDEV 1" >>confdefs.h
 
@@ -8139,7 +8135,7 @@ fi
 
   if test $ac_cv_header_sys_mkdev_h = no; then
     ac_fn_c_check_header_mongrel "$LINENO" "sys/sysmacros.h" "ac_cv_header_sys_sysmacros_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sysmacros_h" = xyes; then :
+if test "x$ac_cv_header_sys_sysmacros_h" = x""yes; then :
 
 $as_echo "#define MAJOR_IN_SYSMACROS 1" >>confdefs.h
 
@@ -8152,7 +8148,7 @@ fi
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = xyes; then :
+if test "x$ac_cv_header_stdlib_h" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8163,7 +8159,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible malloc" >&5
 $as_echo_n "checking for GNU libc compatible malloc... " >&6; }
-if ${ac_cv_func_malloc_0_nonnull+:} false; then :
+if test "${ac_cv_func_malloc_0_nonnull+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8218,7 +8214,7 @@ fi
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys/time.h may both be included" >&5
 $as_echo_n "checking whether time.h and sys/time.h may both be included... " >&6; }
-if ${ac_cv_header_time+:} false; then :
+if test "${ac_cv_header_time+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
@@ -8293,7 +8289,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mktime" >&5
 $as_echo_n "checking for working mktime... " >&6; }
-if ${ac_cv_func_working_mktime+:} false; then :
+if test "${ac_cv_func_working_mktime+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8522,7 +8518,7 @@ fi
 for ac_func in getpagesize
 do :
   ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
-if test "x$ac_cv_func_getpagesize" = xyes; then :
+if test "x$ac_cv_func_getpagesize" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_GETPAGESIZE 1
 _ACEOF
@@ -8532,7 +8528,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
 $as_echo_n "checking for working mmap... " >&6; }
-if ${ac_cv_func_mmap_fixed_mapped+:} false; then :
+if test "${ac_cv_func_mmap_fixed_mapped+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8699,7 +8695,7 @@ rm -f conftest.mmap conftest.txt
 for ac_header in stdlib.h
 do :
   ac_fn_c_check_header_mongrel "$LINENO" "stdlib.h" "ac_cv_header_stdlib_h" "$ac_includes_default"
-if test "x$ac_cv_header_stdlib_h" = xyes; then :
+if test "x$ac_cv_header_stdlib_h" = x""yes; then :
   cat >>confdefs.h <<_ACEOF
 #define HAVE_STDLIB_H 1
 _ACEOF
@@ -8710,7 +8706,7 @@ done
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU libc compatible realloc" >&5
 $as_echo_n "checking for GNU libc compatible realloc... " >&6; }
-if ${ac_cv_func_realloc_0_nonnull+:} false; then :
+if test "${ac_cv_func_realloc_0_nonnull+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8763,17 +8759,13 @@ $as_echo "#define realloc rpl_realloc" >>confdefs.h
 fi
 
 
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strnlen" >&5
 $as_echo_n "checking for working strnlen... " >&6; }
-if ${ac_cv_func_strnlen_working+:} false; then :
+if test "${ac_cv_func_strnlen_working+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
-  # Guess no on AIX systems, yes otherwise.
-		case "$host_os" in
-		  aix*) ac_cv_func_strnlen_working=no;;
-		  *)    ac_cv_func_strnlen_working=yes;;
-		esac
+  ac_cv_func_strnlen_working=no
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -8822,7 +8814,7 @@ esac
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for working strtod" >&5
 $as_echo_n "checking for working strtod... " >&6; }
-if ${ac_cv_func_strtod+:} false; then :
+if test "${ac_cv_func_strtod+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   if test "$cross_compiling" = yes; then :
@@ -8881,14 +8873,14 @@ if test $ac_cv_func_strtod = no; then
 esac
 
 ac_fn_c_check_func "$LINENO" "pow" "ac_cv_func_pow"
-if test "x$ac_cv_func_pow" = xyes; then :
+if test "x$ac_cv_func_pow" = x""yes; then :
 
 fi
 
 if test $ac_cv_func_pow = no; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pow in -lm" >&5
 $as_echo_n "checking for pow in -lm... " >&6; }
-if ${ac_cv_lib_m_pow+:} false; then :
+if test "${ac_cv_lib_m_pow+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -8922,7 +8914,7 @@ LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_m_pow" >&5
 $as_echo "$ac_cv_lib_m_pow" >&6; }
-if test "x$ac_cv_lib_m_pow" = xyes; then :
+if test "x$ac_cv_lib_m_pow" = x""yes; then :
   POW_LIB=-lm
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cannot find library containing definition of pow" >&5
@@ -9018,21 +9010,10 @@ $as_echo "$as_me: WARNING: cache variable $ac_var contains a newline" >&2;} ;;
      :end' >>confcache
 if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
   if test -w "$cache_file"; then
-    if test "x$cache_file" != "x/dev/null"; then
+    test "x$cache_file" != "x/dev/null" &&
       { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_file" >&5
 $as_echo "$as_me: updating cache $cache_file" >&6;}
-      if test ! -f "$cache_file" || test -h "$cache_file"; then
-	cat confcache >"$cache_file"
-      else
-        case $cache_file in #(
-        */* | ?:*)
-	  mv -f confcache "$cache_file"$$ &&
-	  mv -f "$cache_file"$$ "$cache_file" ;; #(
-        *)
-	  mv -f confcache "$cache_file" ;;
-	esac
-      fi
-    fi
+    cat confcache >$cache_file
   else
     { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cache $cache_file" >&5
 $as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
@@ -9064,7 +9045,7 @@ LTLIBOBJS=$ac_ltlibobjs
 
 
 
-: "${CONFIG_STATUS=./config.status}"
+: ${CONFIG_STATUS=./config.status}
 ac_write_fail=0
 ac_clean_files_save=$ac_clean_files
 ac_clean_files="$ac_clean_files $CONFIG_STATUS"
@@ -9165,7 +9146,6 @@ fi
 IFS=" ""	$as_nl"
 
 # Find who we are.  Look in the path if we contain no directory separator.
-as_myself=
 case $0 in #((
   *[\\/]* ) as_myself=$0 ;;
   *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
@@ -9473,7 +9453,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # values after options handling.
 ac_log="
 This file was extended by Xen Hypervisor $as_me 4.2, which was
-generated by GNU Autoconf 2.68.  Invocation command line was
+generated by GNU Autoconf 2.67.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
   CONFIG_HEADERS  = $CONFIG_HEADERS
@@ -9535,7 +9515,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
 ac_cs_version="\\
 Xen Hypervisor config.status 4.2
-configured by $0, generated by GNU Autoconf 2.68,
+configured by $0, generated by GNU Autoconf 2.67,
   with options \\"\$ac_cs_config\\"
 
 Copyright (C) 2010 Free Software Foundation, Inc.
@@ -9660,7 +9640,7 @@ do
     "../config/Xen.mk") CONFIG_FILES="$CONFIG_FILES ../config/Xen.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;;
 
-  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
+  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
   esac
 done
 
@@ -9682,10 +9662,9 @@ fi
 # after its creation but before its name has been assigned to `$tmp'.
 $debug ||
 {
-  tmp= ac_tmp=
+  tmp=
   trap 'exit_status=$?
-  : "${ac_tmp:=$tmp}"
-  { test ! -d "$ac_tmp" || rm -fr "$ac_tmp"; } && exit $exit_status
+  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit_status
 ' 0
   trap 'as_fn_exit 1' 1 2 13 15
 }
@@ -9693,13 +9672,12 @@ $debug ||
 
 {
   tmp=`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
-  test -d "$tmp"
+  test -n "$tmp" && test -d "$tmp"
 }  ||
 {
   tmp=./conf$$-$RANDOM
   (umask 077 && mkdir "$tmp")
 } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO" 5
-ac_tmp=$tmp
 
 # Set up the scripts for CONFIG_FILES section.
 # No need to generate them if there are no CONFIG_FILES.
@@ -9721,7 +9699,7 @@ else
   ac_cs_awk_cr=$ac_cr
 fi
 
-echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
+echo 'BEGIN {' >"$tmp/subs1.awk" &&
 _ACEOF
 
 
@@ -9749,7 +9727,7 @@ done
 rm -f conf$$subs.sh
 
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
-cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&
+cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
 _ACEOF
 sed -n '
 h
@@ -9797,7 +9775,7 @@ t delim
 rm -f conf$$subs.awk
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 _ACAWK
-cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
+cat >>"\$tmp/subs1.awk" <<_ACAWK &&
   for (key in S) S_is_set[key] = 1
   FS = ""
 
@@ -9829,7 +9807,7 @@ if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
   sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
 else
   cat
-fi < "$ac_tmp/subs1.awk" > "$ac_tmp/subs.awk" \
+fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
   || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
 _ACEOF
 
@@ -9863,7 +9841,7 @@ fi # test -n "$CONFIG_FILES"
 # No need to generate them if there are no CONFIG_HEADERS.
 # This happens for instance with `./config.status Makefile'.
 if test -n "$CONFIG_HEADERS"; then
-cat >"$ac_tmp/defines.awk" <<\_ACAWK ||
+cat >"$tmp/defines.awk" <<\_ACAWK ||
 BEGIN {
 _ACEOF
 
@@ -9875,8 +9853,8 @@ _ACEOF
 # handling of long lines.
 ac_delim='%!_!# '
 for ac_last_try in false false :; do
-  ac_tt=`sed -n "/$ac_delim/p" confdefs.h`
-  if test -z "$ac_tt"; then
+  ac_t=`sed -n "/$ac_delim/p" confdefs.h`
+  if test -z "$ac_t"; then
     break
   elif $ac_last_try; then
     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
@@ -9977,7 +9955,7 @@ do
   esac
   case $ac_mode$ac_tag in
   :[FHL]*:*);;
-  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5;;
+  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
   :[FH]-) ac_tag=-:-;;
   :[FH]*) ac_tag=$ac_tag:$ac_tag.in;;
   esac
@@ -9996,7 +9974,7 @@ do
     for ac_f
     do
       case $ac_f in
-      -) ac_f="$ac_tmp/stdin";;
+      -) ac_f="$tmp/stdin";;
       *) # Look for the file first in the build tree, then in the source tree
 	 # (if the path is not absolute).  The absolute path cannot be DOS-style,
 	 # because $ac_f cannot contain `:'.
@@ -10005,7 +9983,7 @@ do
 	   [\\/$]*) false;;
 	   *) test -f "$srcdir/$ac_f" && ac_f="$srcdir/$ac_f";;
 	   esac ||
-	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5;;
+	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
       esac
       case $ac_f in *\'*) ac_f=`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\''/g"`;; esac
       as_fn_append ac_file_inputs " '$ac_f'"
@@ -10031,8 +10009,8 @@ $as_echo "$as_me: creating $ac_file" >&6;}
     esac
 
     case $ac_tag in
-    *:-:* | *:-) cat >"$ac_tmp/stdin" \
-      || as_fn_error $? "could not create $ac_file" "$LINENO" 5 ;;
+    *:-:* | *:-) cat >"$tmp/stdin" \
+      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
     esac
     ;;
   esac
@@ -10162,22 +10140,21 @@ s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
 s&@INSTALL@&$ac_INSTALL&;t t
 $ac_datarootdir_hack
 "
-eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$ac_tmp/subs.awk" \
-  >$ac_tmp/out || as_fn_error $? "could not create $ac_file" "$LINENO" 5
+eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" >$tmp/out \
+  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
 
 test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
-  { ac_out=`sed -n '/\${datarootdir}/p' "$ac_tmp/out"`; test -n "$ac_out"; } &&
-  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' \
-      "$ac_tmp/out"`; test -z "$ac_out"; } &&
+  { ac_out=`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"; } &&
+  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' "$tmp/out"`; test -z "$ac_out"; } &&
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&5
 $as_echo "$as_me: WARNING: $ac_file contains a reference to the variable \`datarootdir'
 which seems to be undefined.  Please make sure it is defined" >&2;}
 
-  rm -f "$ac_tmp/stdin"
+  rm -f "$tmp/stdin"
   case $ac_file in
-  -) cat "$ac_tmp/out" && rm -f "$ac_tmp/out";;
-  *) rm -f "$ac_file" && mv "$ac_tmp/out" "$ac_file";;
+  -) cat "$tmp/out" && rm -f "$tmp/out";;
+  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
   esac \
   || as_fn_error $? "could not create $ac_file" "$LINENO" 5
  ;;
@@ -10188,20 +10165,20 @@ which seems to be undefined.  Please make sure it is defined" >&2;}
   if test x"$ac_file" != x-; then
     {
       $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs"
-    } >"$ac_tmp/config.h" \
+      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
+    } >"$tmp/config.h" \
       || as_fn_error $? "could not create $ac_file" "$LINENO" 5
-    if diff "$ac_file" "$ac_tmp/config.h" >/dev/null 2>&1; then
+    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
 $as_echo "$as_me: $ac_file is unchanged" >&6;}
     else
       rm -f "$ac_file"
-      mv "$ac_tmp/config.h" "$ac_file" \
+      mv "$tmp/config.h" "$ac_file" \
 	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
     fi
   else
     $as_echo "/* $configure_input  */" \
-      && eval '$AWK -f "$ac_tmp/defines.awk"' "$ac_file_inputs" \
+      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
       || as_fn_error $? "could not create -" "$LINENO" 5
   fi
  ;;
diff --git a/tools/configure.ac b/tools/configure.ac
index 5b2815d..b0668b4 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -64,7 +64,6 @@ AX_SET_FLAGS
 AC_ARG_VAR([PYTHON], [Path to the Python parser])
 AC_ARG_VAR([PERL], [Path to Perl parser])
 AC_ARG_VAR([IP], [Path to ip tool])
-AC_ARG_VAR([BISON], [Path to Bison parser generator])
 AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
 AC_ARG_VAR([CURL], [Path to curl-config tool])
 AC_ARG_VAR([XML], [Path to xml2-config tool])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:34:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kbG-0004bU-3K; Wed, 29 Feb 2012 14:33:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2kbE-0004bO-DL
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:33:48 +0000
Received: from [85.158.139.83:36686] by server-9.bemta-5.messagelabs.com id
	C1/AE-09826-B473E4F4; Wed, 29 Feb 2012 14:33:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330526027!17245954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24715 invoked from network); 29 Feb 2012 14:33:47 -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;
	29 Feb 2012 14:33:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11011698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 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.213.0; Wed, 29 Feb 2012 14:33:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2kbC-0004Eq-Q7; Wed, 29 Feb 2012 14:33:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2kbC-0003Uo-PQ;
	Wed, 29 Feb 2012 14:33:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14154.774708.240615@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:33:46 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328792705.6133.168.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328791978@probook.site>
	<85fcc1d0f072c4f9d1e8.1328791979@probook.site>
	<1328792705.6133.168.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename
 libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename libxl__yajl_gen_alloc"):
> On Thu, 2012-02-09 at 12:52 +0000, Olaf Hering wrote:
> > libxl__yajl_gen_alloc() is called by generic code,
> > rename it to libx__yajl_gen_alloc().
> 
> Other than this typo both patches in this series look good to me,
> thanks.
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, applied both (with fixed message for 1/2).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:34:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kbG-0004bU-3K; Wed, 29 Feb 2012 14:33:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2kbE-0004bO-DL
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:33:48 +0000
Received: from [85.158.139.83:36686] by server-9.bemta-5.messagelabs.com id
	C1/AE-09826-B473E4F4; Wed, 29 Feb 2012 14:33:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1330526027!17245954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24715 invoked from network); 29 Feb 2012 14:33:47 -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;
	29 Feb 2012 14:33:47 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11011698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 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.213.0; Wed, 29 Feb 2012 14:33:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2kbC-0004Eq-Q7; Wed, 29 Feb 2012 14:33:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2kbC-0003Uo-PQ;
	Wed, 29 Feb 2012 14:33:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14154.774708.240615@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:33:46 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1328792705.6133.168.camel@zakaz.uk.xensource.com>
References: <patchbomb.1328791978@probook.site>
	<85fcc1d0f072c4f9d1e8.1328791979@probook.site>
	<1328792705.6133.168.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename
 libxl__yajl_gen_alloc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1 of 2] tools/libxl: rename libxl__yajl_gen_alloc"):
> On Thu, 2012-02-09 at 12:52 +0000, Olaf Hering wrote:
> > libxl__yajl_gen_alloc() is called by generic code,
> > rename it to libx__yajl_gen_alloc().
> 
> Other than this typo both patches in this series look good to me,
> thanks.
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, applied both (with fixed message for 1/2).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:37:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2keF-0004he-Lc; Wed, 29 Feb 2012 14:36:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2keE-0004hX-5v
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:36:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330526207!15480868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32271 invoked from network); 29 Feb 2012 14:36:48 -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;
	29 Feb 2012 14:36:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11011767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:36:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:36:25 +0000
Message-ID: <1330526182.4270.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 29 Feb 2012 14:36:22 +0000
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00 of 10] arm: SMP 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-02-23 at 17:40 +0000, Tim Deegan wrote:
> This patch series implements SMP boot for arch/arm, as far as getting
> all CPUs up and running the idle loop.

What additional steps are needed when building the model to get an SMP
system?

Ideally this would eventually be documented in
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModels but it is probably a bit premature for that right now.

I think it is sufficient to do the following after opening the project
("sgcanvas <SGPROJ>") and before clicking the "Build" button.

      * Right click the header of the "cluster" in the diagram (the top
        bit of the box which says "cluster" in it)
      * Select "Object Properties" from the context menu
      * In the "Parameters" tab update the "num_cores" variable, e.g. to
        "0x4"
      * Click build and continue as usual.

Do that sound about right? It appears to work for me at least. I've not
applied all your patches so I can't see how many processors there really
are.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:37:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2keF-0004he-Lc; Wed, 29 Feb 2012 14:36:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2keE-0004hX-5v
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:36:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330526207!15480868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32271 invoked from network); 29 Feb 2012 14:36:48 -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;
	29 Feb 2012 14:36:48 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11011767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:36:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:36:25 +0000
Message-ID: <1330526182.4270.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 29 Feb 2012 14:36:22 +0000
In-Reply-To: <patchbomb.1330018847@whitby.uk.xensource.com>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00 of 10] arm: SMP 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-02-23 at 17:40 +0000, Tim Deegan wrote:
> This patch series implements SMP boot for arch/arm, as far as getting
> all CPUs up and running the idle loop.

What additional steps are needed when building the model to get an SMP
system?

Ideally this would eventually be documented in
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModels but it is probably a bit premature for that right now.

I think it is sufficient to do the following after opening the project
("sgcanvas <SGPROJ>") and before clicking the "Build" button.

      * Right click the header of the "cluster" in the diagram (the top
        bit of the box which says "cluster" in it)
      * Select "Object Properties" from the context menu
      * In the "Parameters" tab update the "num_cores" variable, e.g. to
        "0x4"
      * Click build and continue as usual.

Do that sound about right? It appears to work for me at least. I've not
applied all your patches so I can't see how many processors there really
are.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:38:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kf2-0004kq-2Q; Wed, 29 Feb 2012 14:37: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 1S2kf1-0004kj-F0
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:37:43 +0000
Received: from [85.158.139.83:10381] by server-9.bemta-5.messagelabs.com id
	C0/0D-09826-6383E4F4; Wed, 29 Feb 2012 14:37:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330526261!13373603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 29 Feb 2012 14:37:42 -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;
	29 Feb 2012 14:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11011805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:37:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:37:42 +0000
Message-ID: <1330526260.4270.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Date: Wed, 29 Feb 2012 14:37:40 +0000
In-Reply-To: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
References: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems with hyperthreading in Windows 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 Wed, 2012-02-29 at 00:28 +0000, Roderick Colenbrander wrote:
> Hi,
> 
> I have been trying to get Hyperthreading to work in a Windows HVM on
> Xen 4.1.2 as described in 'xmexample.hvm'. I think I have set it up
> correctly, but I can't seem to get it to work. There is not much
> documentation on it and most topics are from years ago.

I don't know the answers to your questions, or whether this particular
type of cpuid modification has ever worked. But might it be that
something on the hypervisor side is also modifying the cpuid results?

I suppose you could start at xen/arch/x86/hvm/emulate.c:hvmemul_cpuid
and trace down to the actual code in question? Looks like hvm_cpuid() is
probably the key function of interest.

Note sure where APIC IDs come from either, xen/arch/x86/hvm/vlapic.c
might be an interesting starting point. Or perhaps this is done by
hvmloader tools/firmware/hvmloader.c?

More questions than answers in the above, sorry about 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 Feb 29 14:38:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kf2-0004kq-2Q; Wed, 29 Feb 2012 14:37: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 1S2kf1-0004kj-F0
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:37:43 +0000
Received: from [85.158.139.83:10381] by server-9.bemta-5.messagelabs.com id
	C0/0D-09826-6383E4F4; Wed, 29 Feb 2012 14:37:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1330526261!13373603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25133 invoked from network); 29 Feb 2012 14:37:42 -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;
	29 Feb 2012 14:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11011805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:37:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:37:42 +0000
Message-ID: <1330526260.4270.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Date: Wed, 29 Feb 2012 14:37:40 +0000
In-Reply-To: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
References: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems with hyperthreading in Windows 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 Wed, 2012-02-29 at 00:28 +0000, Roderick Colenbrander wrote:
> Hi,
> 
> I have been trying to get Hyperthreading to work in a Windows HVM on
> Xen 4.1.2 as described in 'xmexample.hvm'. I think I have set it up
> correctly, but I can't seem to get it to work. There is not much
> documentation on it and most topics are from years ago.

I don't know the answers to your questions, or whether this particular
type of cpuid modification has ever worked. But might it be that
something on the hypervisor side is also modifying the cpuid results?

I suppose you could start at xen/arch/x86/hvm/emulate.c:hvmemul_cpuid
and trace down to the actual code in question? Looks like hvm_cpuid() is
probably the key function of interest.

Note sure where APIC IDs come from either, xen/arch/x86/hvm/vlapic.c
might be an interesting starting point. Or perhaps this is done by
hvmloader tools/firmware/hvmloader.c?

More questions than answers in the above, sorry about 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 Feb 29 14:44:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2klR-00052s-US; Wed, 29 Feb 2012 14:44:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2klR-00052n-41
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:44:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330526654!15475469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24631 invoked from network); 29 Feb 2012 14:44:15 -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;
	29 Feb 2012 14:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:44:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:44:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2klK-0004If-5v; Wed, 29 Feb 2012 14:44:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2klK-00047M-4t;
	Wed, 29 Feb 2012 14:44:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14782.49746.371873@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:44:14 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
	<CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
	<CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v8] build: add autoconf t=
o replace custom checks in tools/check"):
> install: remove old checks from install.sh
> =

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Looks good to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:44:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2klR-00052s-US; Wed, 29 Feb 2012 14:44:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2klR-00052n-41
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:44:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1330526654!15475469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24631 invoked from network); 29 Feb 2012 14:44:15 -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;
	29 Feb 2012 14:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:44:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:44:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2klK-0004If-5v; Wed, 29 Feb 2012 14:44:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2klK-00047M-4t;
	Wed, 29 Feb 2012 14:44:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14782.49746.371873@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:44:14 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
References: <c2f0820e48ae9cf0735c.1329794352@build.localdomain>
	<20120223173617.GA19213@aepfle.de>
	<CAFw--Dcegx1xZeLDWrJhrTJ32ivQPRF4=gD5Fj3zvdT9eKOaYw@mail.gmail.com>
	<CAPLaKK4gM4nyDnwRQ=jr6coBuKjEU7xTOYU7-yHZ3QY0Lr5C5g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jeffrey Karrels <karrelsj@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v8] build: add autoconf to replace custom
 checks in tools/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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v8] build: add autoconf t=
o replace custom checks in tools/check"):
> install: remove old checks from install.sh
> =

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Looks good to me.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2klZ-00053I-9y; Wed, 29 Feb 2012 14:44: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 1S2klX-000539-NF
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:44:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330526606!53891125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18873 invoked from network); 29 Feb 2012 14:43:27 -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;
	29 Feb 2012 14:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:44:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:44:26 +0000
Message-ID: <1330526664.4270.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Wed, 29 Feb 2012 14:44:24 +0000
In-Reply-To: <20120229125826.GC2077@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
	<20120229093436.GA2077@linaro.org>
	<1330509362.4270.20.camel@zakaz.uk.xensource.com>
	<20120229125826.GC2077@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 12:58 +0000, Dave Martin wrote:
> On Wed, Feb 29, 2012 at 09:56:02AM +0000, Ian Campbell wrote:
> > On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> > > On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:
> > 
> > > > I don't have a very strong opinion on which register we should use, but
> > > > I would like to avoid r7 if it is already actively used by gcc.
> > > 
> > > But there is no framepointer for Thumb-2 code (?)
> > 
> > Peter Maydell suggested there was:
> > > r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> > > makes it worth avoiding in this context.
> > 
> > Sounds like it might be a gcc-ism, possibly a non-default option?
> > 
> > Anyway, I think r12 will be fine for our purposes so the point is rather
> > moot.
> 
> Just had a chat with some tools guys -- apparently, when passing register
> arguments to gcc inline asms there really isn't a guarantee that those
> variables will be in the expected registers on entry to the inline asm.
> 
> If gcc reorders other function calls or other code around the inline asm
> (which it can do, except under certain controlled situations), then
> intervening code can clobber any registers in general.
> 
> Or, to summarise another way, there is no way to control which register
> is used to pass something to an inline asm in general (often we get away
> with this, and there are a lot of inline asms in the kernel that assume
> it works, but the more you inline the more likely you are to get nasty
> surprises).  There is no workaroud, except on some architectures where
> special asm constraints allow specific individual registers to be
> specified for operands (i386 for example).

I had assumed I just couldn't find the right syntax. Useful to know that
I couldn't find it because it doesn't exist!

> If you need a specific register, this means that you must set up that
> register explicitly inside the asm if you want a guarantee that the
> code will work:
> 
> 	asm volatile (
> 		"movw	r12, %[hvc_num]\n\t"

Is gcc (or gas?) smart enough to optimise this away if it turns out that
%[hvc_num] == r12?

> 		...
> 		"hvc	#0"
> 		:: [hvc_num] "i" (NUMBER) : "r12"
> 	);
> 
> Of course, if you need to set up more than about 5 or 6 registers in
> this way, the doubled register footprint means that the compiler will
> have to start spilling stuff to the stack.
> 
> 
> This is the kind of problem which goes away when out-of-lining the
> hvc wrapper behind a C function interface, since the ABI then provides
> guarantees about how values are mershaled into and out of that code.

I don't think anything would stop gcc from clobbering an argument
register right on function entry (e..g it might move r0 to r8 and
clobber r0, for whatever reason), so that they are no longer where you
expect them to be when you hit the asm. Unlikely perhaps but no more so
than the other issues you've raised?
	
Or did you mean out-of-line as in "written in a .S file" as well as out
of line?

> Notwithstanding the above, even if we do make theoretically unsound
> (but often true) assumptions about inline asms, ARM will be no worse
> than other arches in this respect.

This is true.

> Other than serving as a reminder that inline asm is a deep can of
> worms, this doesn't really give us a neat solution...

How are system calls implemented on the userspace side? I confess I
don't know what the ARM syscall ABI looks like -- is it all registers or
is some of it on the stack? It sounds like the solution ought to be
pretty similar 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 Feb 29 14:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:44:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2klZ-00053I-9y; Wed, 29 Feb 2012 14:44: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 1S2klX-000539-NF
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:44:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1330526606!53891125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18873 invoked from network); 29 Feb 2012 14:43:27 -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;
	29 Feb 2012 14:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:44:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:44:26 +0000
Message-ID: <1330526664.4270.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dave Martin <dave.martin@linaro.org>
Date: Wed, 29 Feb 2012 14:44:24 +0000
In-Reply-To: <20120229125826.GC2077@linaro.org>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
	<20120229093436.GA2077@linaro.org>
	<1330509362.4270.20.camel@zakaz.uk.xensource.com>
	<20120229125826.GC2077@linaro.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.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-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 12:58 +0000, Dave Martin wrote:
> On Wed, Feb 29, 2012 at 09:56:02AM +0000, Ian Campbell wrote:
> > On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> > > On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:
> > 
> > > > I don't have a very strong opinion on which register we should use, but
> > > > I would like to avoid r7 if it is already actively used by gcc.
> > > 
> > > But there is no framepointer for Thumb-2 code (?)
> > 
> > Peter Maydell suggested there was:
> > > r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> > > makes it worth avoiding in this context.
> > 
> > Sounds like it might be a gcc-ism, possibly a non-default option?
> > 
> > Anyway, I think r12 will be fine for our purposes so the point is rather
> > moot.
> 
> Just had a chat with some tools guys -- apparently, when passing register
> arguments to gcc inline asms there really isn't a guarantee that those
> variables will be in the expected registers on entry to the inline asm.
> 
> If gcc reorders other function calls or other code around the inline asm
> (which it can do, except under certain controlled situations), then
> intervening code can clobber any registers in general.
> 
> Or, to summarise another way, there is no way to control which register
> is used to pass something to an inline asm in general (often we get away
> with this, and there are a lot of inline asms in the kernel that assume
> it works, but the more you inline the more likely you are to get nasty
> surprises).  There is no workaroud, except on some architectures where
> special asm constraints allow specific individual registers to be
> specified for operands (i386 for example).

I had assumed I just couldn't find the right syntax. Useful to know that
I couldn't find it because it doesn't exist!

> If you need a specific register, this means that you must set up that
> register explicitly inside the asm if you want a guarantee that the
> code will work:
> 
> 	asm volatile (
> 		"movw	r12, %[hvc_num]\n\t"

Is gcc (or gas?) smart enough to optimise this away if it turns out that
%[hvc_num] == r12?

> 		...
> 		"hvc	#0"
> 		:: [hvc_num] "i" (NUMBER) : "r12"
> 	);
> 
> Of course, if you need to set up more than about 5 or 6 registers in
> this way, the doubled register footprint means that the compiler will
> have to start spilling stuff to the stack.
> 
> 
> This is the kind of problem which goes away when out-of-lining the
> hvc wrapper behind a C function interface, since the ABI then provides
> guarantees about how values are mershaled into and out of that code.

I don't think anything would stop gcc from clobbering an argument
register right on function entry (e..g it might move r0 to r8 and
clobber r0, for whatever reason), so that they are no longer where you
expect them to be when you hit the asm. Unlikely perhaps but no more so
than the other issues you've raised?
	
Or did you mean out-of-line as in "written in a .S file" as well as out
of line?

> Notwithstanding the above, even if we do make theoretically unsound
> (but often true) assumptions about inline asms, ARM will be no worse
> than other arches in this respect.

This is true.

> Other than serving as a reminder that inline asm is a deep can of
> worms, this doesn't really give us a neat solution...

How are system calls implemented on the userspace side? I confess I
don't know what the ARM syscall ABI looks like -- is it all registers or
is some of it on the stack? It sounds like the solution ought to be
pretty similar 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 Feb 29 14:46:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kn2-0005Ay-P7; Wed, 29 Feb 2012 14:46:00 +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 1S2kn1-0005AW-1y
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:45:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330526682!58740575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7877 invoked from network); 29 Feb 2012 14:44:42 -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;
	29 Feb 2012 14:44:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:45:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:45:50 +0000
Date: Wed, 29 Feb 2012 14:52:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120229125826.GC2077@linaro.org>
Message-ID: <alpine.DEB.2.00.1202291435400.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
	<20120229093436.GA2077@linaro.org>
	<1330509362.4270.20.camel@zakaz.uk.xensource.com>
	<20120229125826.GC2077@linaro.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@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>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>, David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 29 Feb 2012, Dave Martin wrote:
> On Wed, Feb 29, 2012 at 09:56:02AM +0000, Ian Campbell wrote:
> > On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> > > On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:
> > 
> > > > I don't have a very strong opinion on which register we should use, but
> > > > I would like to avoid r7 if it is already actively used by gcc.
> > > 
> > > But there is no framepointer for Thumb-2 code (?)
> > 
> > Peter Maydell suggested there was:
> > > r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> > > makes it worth avoiding in this context.
> > 
> > Sounds like it might be a gcc-ism, possibly a non-default option?
> > 
> > Anyway, I think r12 will be fine for our purposes so the point is rather
> > moot.
> 
> Just had a chat with some tools guys -- apparently, when passing register
> arguments to gcc inline asms there really isn't a guarantee that those
> variables will be in the expected registers on entry to the inline asm.
> 
> If gcc reorders other function calls or other code around the inline asm
> (which it can do, except under certain controlled situations), then
> intervening code can clobber any registers in general.
> 
> Or, to summarise another way, there is no way to control which register
> is used to pass something to an inline asm in general (often we get away
> with this, and there are a lot of inline asms in the kernel that assume
> it works, but the more you inline the more likely you are to get nasty
> surprises).  There is no workaroud, except on some architectures where
> special asm constraints allow specific individual registers to be
> specified for operands (i386 for example).
> 
> If you need a specific register, this means that you must set up that
> register explicitly inside the asm if you want a guarantee that the
> code will work:
> 
> 	asm volatile (
> 		"movw	r12, %[hvc_num]\n\t"
> 		...
> 		"hvc	#0"
> 		:: [hvc_num] "i" (NUMBER) : "r12"
> 	);
> 

OK, we can arrange the hypercall code to be like that.
Also with your patch series it would be "_hvc" because of the .macro,
right?



> This is the kind of problem which goes away when out-of-lining the
> hvc wrapper behind a C function interface, since the ABI then provides
> guarantees about how values are mershaled into and out of that code.

Do you mean implementing the entire HYPERVISOR_example_op in assembly
and calling it from C?
Because I guess that gcc would still be free to mess with the registers
between the C function entry point and any inline assembly code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:46:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kn2-0005Ay-P7; Wed, 29 Feb 2012 14:46:00 +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 1S2kn1-0005AW-1y
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:45:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1330526682!58740575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7877 invoked from network); 29 Feb 2012 14:44:42 -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;
	29 Feb 2012 14:44:42 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:45:50 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:45:50 +0000
Date: Wed, 29 Feb 2012 14:52:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120229125826.GC2077@linaro.org>
Message-ID: <alpine.DEB.2.00.1202291435400.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231714590.23091@kaball-desktop>
	<1330019314-20865-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330360043.8557.302.camel@zakaz.uk.xensource.com>
	<20120227180355.GB2023@linaro.org>
	<1330371219.10008.34.camel@dagon.hellion.org.uk>
	<20120228102040.GB2063@linaro.org>
	<1330426133.31269.70.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202281149210.23091@kaball-desktop>
	<20120229093436.GA2077@linaro.org>
	<1330509362.4270.20.camel@zakaz.uk.xensource.com>
	<20120229125826.GC2077@linaro.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@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>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>, David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH-WIP 01/13] xen/arm: use r12 to pass the
 hypercall number to the hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 29 Feb 2012, Dave Martin wrote:
> On Wed, Feb 29, 2012 at 09:56:02AM +0000, Ian Campbell wrote:
> > On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> > > On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:
> > 
> > > > I don't have a very strong opinion on which register we should use, but
> > > > I would like to avoid r7 if it is already actively used by gcc.
> > > 
> > > But there is no framepointer for Thumb-2 code (?)
> > 
> > Peter Maydell suggested there was:
> > > r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> > > makes it worth avoiding in this context.
> > 
> > Sounds like it might be a gcc-ism, possibly a non-default option?
> > 
> > Anyway, I think r12 will be fine for our purposes so the point is rather
> > moot.
> 
> Just had a chat with some tools guys -- apparently, when passing register
> arguments to gcc inline asms there really isn't a guarantee that those
> variables will be in the expected registers on entry to the inline asm.
> 
> If gcc reorders other function calls or other code around the inline asm
> (which it can do, except under certain controlled situations), then
> intervening code can clobber any registers in general.
> 
> Or, to summarise another way, there is no way to control which register
> is used to pass something to an inline asm in general (often we get away
> with this, and there are a lot of inline asms in the kernel that assume
> it works, but the more you inline the more likely you are to get nasty
> surprises).  There is no workaroud, except on some architectures where
> special asm constraints allow specific individual registers to be
> specified for operands (i386 for example).
> 
> If you need a specific register, this means that you must set up that
> register explicitly inside the asm if you want a guarantee that the
> code will work:
> 
> 	asm volatile (
> 		"movw	r12, %[hvc_num]\n\t"
> 		...
> 		"hvc	#0"
> 		:: [hvc_num] "i" (NUMBER) : "r12"
> 	);
> 

OK, we can arrange the hypercall code to be like that.
Also with your patch series it would be "_hvc" because of the .macro,
right?



> This is the kind of problem which goes away when out-of-lining the
> hvc wrapper behind a C function interface, since the ABI then provides
> guarantees about how values are mershaled into and out of that code.

Do you mean implementing the entire HYPERVISOR_example_op in assembly
and calling it from C?
Because I guess that gcc would still be free to mess with the registers
between the C function entry point and any inline assembly code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2koY-0005Mm-8Y; Wed, 29 Feb 2012 14:47:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2koX-0005MJ-Ht
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:47:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330526803!4220523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8279 invoked from network); 29 Feb 2012 14:46:45 -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;
	29 Feb 2012 14:46:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:46:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:46:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2kna-0004Jd-U6; Wed, 29 Feb 2012 14:46:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2kna-00047l-TI;
	Wed, 29 Feb 2012 14:46:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14922.894731.936631@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:46:34 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] configure failure"):
> I'm going to fix this right now. Should I commit the output from
> autoconf also with my patches Ian? I'm asking this because we use
> different versions and the output is slightly different.

I don't mind whether you commit the output from autoconf and include
it in your patch.  It's probably easier for other people not to have
to read the autoconf output diff if your version is different to mine.

BUT please include a note instructing me to rerun autogen.sh.  Or I
might just possibly forget...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2koY-0005Mm-8Y; Wed, 29 Feb 2012 14:47:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2koX-0005MJ-Ht
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:47:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330526803!4220523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8279 invoked from network); 29 Feb 2012 14:46:45 -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;
	29 Feb 2012 14:46:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:46:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:46:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2kna-0004Jd-U6; Wed, 29 Feb 2012 14:46:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2kna-00047l-TI;
	Wed, 29 Feb 2012 14:46:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14922.894731.936631@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:46:34 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] configure failure"):
> I'm going to fix this right now. Should I commit the output from
> autoconf also with my patches Ian? I'm asking this because we use
> different versions and the output is slightly different.

I don't mind whether you commit the output from autoconf and include
it in your patch.  It's probably easier for other people not to have
to read the autoconf output diff if your version is different to mine.

BUT please include a note instructing me to rerun autogen.sh.  Or I
might just possibly forget...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:47:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kog-0005Nv-L2; Wed, 29 Feb 2012 14:47:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2koe-0005N2-Sz
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:47:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330526803!4220523!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9049 invoked from network); 29 Feb 2012 14:46:55 -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;
	29 Feb 2012 14:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:46:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:46:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2knv-0004Jo-Ey; Wed, 29 Feb 2012 14:46:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2knv-000482-EK;
	Wed, 29 Feb 2012 14:46:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14943.414270.806966@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:46:55 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120223131320.GA12900@aepfle.de>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
	<20120223131320.GA12900@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, Christoph Egger <Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] configure failure"):
> I also think configure should just check compile time requirements.
> ip(1) is most likely not needed to compile and link xen+tools.

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 Feb 29 14:47:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kog-0005Nv-L2; Wed, 29 Feb 2012 14:47:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2koe-0005N2-Sz
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:47:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1330526803!4220523!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9049 invoked from network); 29 Feb 2012 14:46:55 -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;
	29 Feb 2012 14:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:46:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:46:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2knv-0004Jo-Ey; Wed, 29 Feb 2012 14:46:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2knv-000482-EK;
	Wed, 29 Feb 2012 14:46:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.14943.414270.806966@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:46:55 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120223131320.GA12900@aepfle.de>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
	<20120223131320.GA12900@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, Christoph Egger <Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] configure failure"):
> I also think configure should just check compile time requirements.
> ip(1) is most likely not needed to compile and link xen+tools.

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 Feb 29 14:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kqP-0005eL-A8; Wed, 29 Feb 2012 14:49: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 1S2kqN-0005dj-4c
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:49:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330526935!55051242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4989 invoked from network); 29 Feb 2012 14:48:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:48:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:49:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:49:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2kqG-0004Kj-Jf; Wed, 29 Feb 2012 14:49:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2kqG-00048L-Hf;
	Wed, 29 Feb 2012 14:49:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.15088.379608.564715@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:49:20 +0000
To: Keith Coleman <keith.coleman@n2servers.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F4D1291.6010705@abpni.co.uk>
References: <4F4D1291.6010705@abpni.co.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jonathan Tripathy <jonnyt@abpni.co.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] CVE-2011-1166
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jonathan Tripathy writes ("[Xen-devel] CVE-2011-1166"):
> I'm currently looking at CVE-2011-1166:
> 
> http://securitytracker.com/id/1025226
> 
> Am I correct in saying that this issue is fixed in the latest stable 4.x 
> branch, but not in the 3.4.4 release? I see the fix here:
> 
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
> 
> however I do not see the same fix applied in 3.4.4:
> 
> http://xenbits.xen.org/hg/xen-3.4-testing.hg/file/ac68ad6fe4b7/xen/arch/x86/domain.c#l716
> 
> Shouldn't this be fixed?

Probably.  I haven't checked whether 3.4 is vulnerable.  This is a
question for the 3.4 stable tree maintainer, Keith Coleman.  Keith ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kqP-0005eL-A8; Wed, 29 Feb 2012 14:49: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 1S2kqN-0005dj-4c
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:49:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1330526935!55051242!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4989 invoked from network); 29 Feb 2012 14:48:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:48:57 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:49:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:49:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2kqG-0004Kj-Jf; Wed, 29 Feb 2012 14:49:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2kqG-00048L-Hf;
	Wed, 29 Feb 2012 14:49:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.15088.379608.564715@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 14:49:20 +0000
To: Keith Coleman <keith.coleman@n2servers.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F4D1291.6010705@abpni.co.uk>
References: <4F4D1291.6010705@abpni.co.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jonathan Tripathy <jonnyt@abpni.co.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] CVE-2011-1166
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jonathan Tripathy writes ("[Xen-devel] CVE-2011-1166"):
> I'm currently looking at CVE-2011-1166:
> 
> http://securitytracker.com/id/1025226
> 
> Am I correct in saying that this issue is fixed in the latest stable 4.x 
> branch, but not in the 3.4.4 release? I see the fix here:
> 
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
> 
> however I do not see the same fix applied in 3.4.4:
> 
> http://xenbits.xen.org/hg/xen-3.4-testing.hg/file/ac68ad6fe4b7/xen/arch/x86/domain.c#l716
> 
> Shouldn't this be fixed?

Probably.  I haven't checked whether 3.4 is vulnerable.  This is a
question for the 3.4 stable tree maintainer, Keith Coleman.  Keith ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:51:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ksP-0005tO-Ti; Wed, 29 Feb 2012 14:51:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2ksO-0005t5-Ui
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:51:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330527085!17032031!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1663 invoked from network); 29 Feb 2012 14:51:26 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:51:26 -0000
Received: by werp12 with SMTP id p12so3188882wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 06:51:25 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.37 as permitted sender) client-ip=10.216.134.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.37 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.37])
	by 10.216.134.37 with SMTP id r37mr333512wei.38.1330527085170 (num_hops
	= 1); Wed, 29 Feb 2012 06:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=EePttgTaiEl7VARbo/3KSjdc9lK4F/7JQAMptMIsFm0=;
	b=eGNm3duGT6vrCYxWNOM0QJzjGYuN5uL3do699FQObccE5L8A+XozsNv863nYGMsj40
	n4MnH4Jw1w0blu5sWVBQ3JyGHrn+Mgh14oYdHiOPEC9320A0MIBe/M3woELyu4tx0AfH
	mb9sT39LSIS90BLQQMntDLQS/hS0ss+XXVVus=
MIME-Version: 1.0
Received: by 10.216.134.37 with SMTP id r37mr268544wei.38.1330527085105; Wed,
	29 Feb 2012 06:51:25 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 06:51:25 -0800 (PST)
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
Date: Wed, 29 Feb 2012 15:51:25 +0100
X-Google-Sender-Auth: WIL82xbwiAXpm5XPFitG-2Id1Vk
Message-ID: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI5IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IEkgX3Ro
aW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRoZSBnZW5l
cmF0ZWQgZmlsZXMuIEEKPiBtb3JlIGNvbXBsZXRlIGZpeCBtaWdodCBhbHNvIGFsbG93IHRoZSB1
c2VyIHRvIGZvcmNlIHJlZ2VuZXJhdGlvbiBidXQgSSBkaWRuJ3QKPiBib3RoIGhlcmUuCj4KPiBT
aWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+IC0t
LQo+IMKgdG9vbHMvY29uZmlndXJlIMKgIMKgfCDCoDU1OSArKysrKysrKysrKysrKysrKysrKysr
KysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gwqB0b29scy9jb25maWd1cmUuYWMgfCDC
oCDCoDEgLQoKWW91IGZvcmdldCB0byByZW1vdmU6CgpBQ19BUkdfVkFSKFtCSVNPTl0sIFtQYXRo
IHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQoKZnJvbSB0b29scy9jb25maWd1cmUuYWMgYW5k
IGFsc28gY2xlYW4gcmVsYXRlZCB2YXJpYWJsZXMgZnJvbQpjb25maWcvVG9vbHMubWsuaW4uIElm
IHlvdSBjYW4sIGNvdWxkIHlvdSB1c2UgYXV0b2NvbmYgMi42OCAocHJlc2VudAppbiBEZWJpYW4g
c3RhYmxlKSB0byBnZW5lcmF0ZSB0aGUgbmV3IGNvbmZpZ3VyZSBzY3JpcHQ/IFNvIHdlIGRvbid0
CmhhdmUgdG8gcHVzaCBzbyBtYW55IHVucmVsYXRlZCBjaGFuZ2VzIHRvIGNvbmZpZ3VyZSBzY3Jp
cHQgYW5kCmRvd25ncmF0ZSBpdHMgdmVyc2lvbj8KCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:51:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ksP-0005tO-Ti; Wed, 29 Feb 2012 14:51:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2ksO-0005t5-Ui
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:51:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330527085!17032031!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1663 invoked from network); 29 Feb 2012 14:51:26 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:51:26 -0000
Received: by werp12 with SMTP id p12so3188882wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 06:51:25 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.216.134.37 as permitted sender) client-ip=10.216.134.37; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.216.134.37 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.216.134.37])
	by 10.216.134.37 with SMTP id r37mr333512wei.38.1330527085170 (num_hops
	= 1); Wed, 29 Feb 2012 06:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=EePttgTaiEl7VARbo/3KSjdc9lK4F/7JQAMptMIsFm0=;
	b=eGNm3duGT6vrCYxWNOM0QJzjGYuN5uL3do699FQObccE5L8A+XozsNv863nYGMsj40
	n4MnH4Jw1w0blu5sWVBQ3JyGHrn+Mgh14oYdHiOPEC9320A0MIBe/M3woELyu4tx0AfH
	mb9sT39LSIS90BLQQMntDLQS/hS0ss+XXVVus=
MIME-Version: 1.0
Received: by 10.216.134.37 with SMTP id r37mr268544wei.38.1330527085105; Wed,
	29 Feb 2012 06:51:25 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 06:51:25 -0800 (PST)
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
Date: Wed, 29 Feb 2012 15:51:25 +0100
X-Google-Sender-Auth: WIL82xbwiAXpm5XPFitG-2Id1Vk
Message-ID: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI5IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IEkgX3Ro
aW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRoZSBnZW5l
cmF0ZWQgZmlsZXMuIEEKPiBtb3JlIGNvbXBsZXRlIGZpeCBtaWdodCBhbHNvIGFsbG93IHRoZSB1
c2VyIHRvIGZvcmNlIHJlZ2VuZXJhdGlvbiBidXQgSSBkaWRuJ3QKPiBib3RoIGhlcmUuCj4KPiBT
aWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+IC0t
LQo+IMKgdG9vbHMvY29uZmlndXJlIMKgIMKgfCDCoDU1OSArKysrKysrKysrKysrKysrKysrKysr
KysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gwqB0b29scy9jb25maWd1cmUuYWMgfCDC
oCDCoDEgLQoKWW91IGZvcmdldCB0byByZW1vdmU6CgpBQ19BUkdfVkFSKFtCSVNPTl0sIFtQYXRo
IHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQoKZnJvbSB0b29scy9jb25maWd1cmUuYWMgYW5k
IGFsc28gY2xlYW4gcmVsYXRlZCB2YXJpYWJsZXMgZnJvbQpjb25maWcvVG9vbHMubWsuaW4uIElm
IHlvdSBjYW4sIGNvdWxkIHlvdSB1c2UgYXV0b2NvbmYgMi42OCAocHJlc2VudAppbiBEZWJpYW4g
c3RhYmxlKSB0byBnZW5lcmF0ZSB0aGUgbmV3IGNvbmZpZ3VyZSBzY3JpcHQ/IFNvIHdlIGRvbid0
CmhhdmUgdG8gcHVzaCBzbyBtYW55IHVucmVsYXRlZCBjaGFuZ2VzIHRvIGNvbmZpZ3VyZSBzY3Jp
cHQgYW5kCmRvd25ncmF0ZSBpdHMgdmVyc2lvbj8KCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:53:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ku6-00061o-DJ; Wed, 29 Feb 2012 14:53:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2ku4-00061a-U9
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:53:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330527064!61249916!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 29 Feb 2012 14:51:04 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:51:04 -0000
Received: by werm1 with SMTP id m1so3833842wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 06:53:15 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.165 as permitted sender) client-ip=10.180.92.165; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.165 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.165])
	by 10.180.92.165 with SMTP id cn5mr18304947wib.2.1330527195518
	(num_hops = 1); Wed, 29 Feb 2012 06:53:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=vKIBszsh8QLARroSGOIwvBi2BnfM+hTBmNM6fOOb0T0=;
	b=S1MlCSsZg3HgG08FuvzszZ+uwur5lQ1RDgJwsPCJ0T0DK1ZselXv9/EcEqAaTaAEWE
	0v3n7LgV9OS5ZOrGvxi1Cx5Cjt+MFbu+dnoFVjQETrDk5ZeMxG1Pf+UOyb+x9zpVaJ/3
	kMdCNPYAj7hI4nhOwcd2iuFAI+Qe6nj1lzOmY=
MIME-Version: 1.0
Received: by 10.180.92.165 with SMTP id cn5mr14601888wib.2.1330527195388; Wed,
	29 Feb 2012 06:53:15 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 06:53:15 -0800 (PST)
In-Reply-To: <20302.14922.894731.936631@mariner.uk.xensource.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
	<20302.14922.894731.936631@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 15:53:15 +0100
X-Google-Sender-Auth: Zl7o4orHcSuARX9nq1PWIz_QNPM
Message-ID: <CAPLaKK6LHqytkzkF022NXrRJQErY_31SWf9Lj59qr37dH6L+Rg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI5IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBjb25maWd1cmUgZmFpbHVyZSIp
Ogo+PiBJJ20gZ29pbmcgdG8gZml4IHRoaXMgcmlnaHQgbm93LiBTaG91bGQgSSBjb21taXQgdGhl
IG91dHB1dCBmcm9tCj4+IGF1dG9jb25mIGFsc28gd2l0aCBteSBwYXRjaGVzIElhbj8gSSdtIGFz
a2luZyB0aGlzIGJlY2F1c2Ugd2UgdXNlCj4+IGRpZmZlcmVudCB2ZXJzaW9ucyBhbmQgdGhlIG91
dHB1dCBpcyBzbGlnaHRseSBkaWZmZXJlbnQuCj4KPiBJIGRvbid0IG1pbmQgd2hldGhlciB5b3Ug
Y29tbWl0IHRoZSBvdXRwdXQgZnJvbSBhdXRvY29uZiBhbmQgaW5jbHVkZQo+IGl0IGluIHlvdXIg
cGF0Y2guIMKgSXQncyBwcm9iYWJseSBlYXNpZXIgZm9yIG90aGVyIHBlb3BsZSBub3QgdG8gaGF2
ZQo+IHRvIHJlYWQgdGhlIGF1dG9jb25mIG91dHB1dCBkaWZmIGlmIHlvdXIgdmVyc2lvbiBpcyBk
aWZmZXJlbnQgdG8gbWluZS4KPgo+IEJVVCBwbGVhc2UgaW5jbHVkZSBhIG5vdGUgaW5zdHJ1Y3Rp
bmcgbWUgdG8gcmVydW4gYXV0b2dlbi5zaC4gwqBPciBJCj4gbWlnaHQganVzdCBwb3NzaWJseSBm
b3JnZXQuLi4KCk5ldmVybWluZCwgSSd2ZSBpbnN0YWxsZWQgdGhlIHNhbWUgdmVyc2lvbiB0aGF0
IHlvdSB1c2VkLCBzbyBjaGFuZ2VzCnRvIGNvbmZpZ3VyZSBzY3JpcHQgYXJlIG1pbmltYWwgYW5k
IHJlbGF0ZWQgdG8gdGhlIGFjdHVhbCBjaGFuZ2VzCmJlaW5nIG1hZGUgaW4gY29uZmlndXJlLmFj
LgoKPiBJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:53:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2ku6-00061o-DJ; Wed, 29 Feb 2012 14:53:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2ku4-00061a-U9
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:53:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330527064!61249916!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 29 Feb 2012 14:51:04 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:51:04 -0000
Received: by werm1 with SMTP id m1so3833842wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 06:53:15 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.92.165 as permitted sender) client-ip=10.180.92.165; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.92.165 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.92.165])
	by 10.180.92.165 with SMTP id cn5mr18304947wib.2.1330527195518
	(num_hops = 1); Wed, 29 Feb 2012 06:53:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=vKIBszsh8QLARroSGOIwvBi2BnfM+hTBmNM6fOOb0T0=;
	b=S1MlCSsZg3HgG08FuvzszZ+uwur5lQ1RDgJwsPCJ0T0DK1ZselXv9/EcEqAaTaAEWE
	0v3n7LgV9OS5ZOrGvxi1Cx5Cjt+MFbu+dnoFVjQETrDk5ZeMxG1Pf+UOyb+x9zpVaJ/3
	kMdCNPYAj7hI4nhOwcd2iuFAI+Qe6nj1lzOmY=
MIME-Version: 1.0
Received: by 10.180.92.165 with SMTP id cn5mr14601888wib.2.1330527195388; Wed,
	29 Feb 2012 06:53:15 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 06:53:15 -0800 (PST)
In-Reply-To: <20302.14922.894731.936631@mariner.uk.xensource.com>
References: <4F44BBFA.6070403@amd.com>
	<CAPLaKK5PM7CEAnFb6tjAFa85qGK610Xmpse-oGuhzjsz+N73OA@mail.gmail.com>
	<4F44C1A7.6070405@amd.com>
	<CAPLaKK474jUie5oN_=qwrs5RDZTcTcu7z5dJ=HegjP4G1fscUw@mail.gmail.com>
	<20302.14922.894731.936631@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 15:53:15 +0100
X-Google-Sender-Auth: Zl7o4orHcSuARX9nq1PWIz_QNPM
Message-ID: <CAPLaKK6LHqytkzkF022NXrRJQErY_31SWf9Lj59qr37dH6L+Rg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] configure failure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI5IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBjb25maWd1cmUgZmFpbHVyZSIp
Ogo+PiBJJ20gZ29pbmcgdG8gZml4IHRoaXMgcmlnaHQgbm93LiBTaG91bGQgSSBjb21taXQgdGhl
IG91dHB1dCBmcm9tCj4+IGF1dG9jb25mIGFsc28gd2l0aCBteSBwYXRjaGVzIElhbj8gSSdtIGFz
a2luZyB0aGlzIGJlY2F1c2Ugd2UgdXNlCj4+IGRpZmZlcmVudCB2ZXJzaW9ucyBhbmQgdGhlIG91
dHB1dCBpcyBzbGlnaHRseSBkaWZmZXJlbnQuCj4KPiBJIGRvbid0IG1pbmQgd2hldGhlciB5b3Ug
Y29tbWl0IHRoZSBvdXRwdXQgZnJvbSBhdXRvY29uZiBhbmQgaW5jbHVkZQo+IGl0IGluIHlvdXIg
cGF0Y2guIMKgSXQncyBwcm9iYWJseSBlYXNpZXIgZm9yIG90aGVyIHBlb3BsZSBub3QgdG8gaGF2
ZQo+IHRvIHJlYWQgdGhlIGF1dG9jb25mIG91dHB1dCBkaWZmIGlmIHlvdXIgdmVyc2lvbiBpcyBk
aWZmZXJlbnQgdG8gbWluZS4KPgo+IEJVVCBwbGVhc2UgaW5jbHVkZSBhIG5vdGUgaW5zdHJ1Y3Rp
bmcgbWUgdG8gcmVydW4gYXV0b2dlbi5zaC4gwqBPciBJCj4gbWlnaHQganVzdCBwb3NzaWJseSBm
b3JnZXQuLi4KCk5ldmVybWluZCwgSSd2ZSBpbnN0YWxsZWQgdGhlIHNhbWUgdmVyc2lvbiB0aGF0
IHlvdSB1c2VkLCBzbyBjaGFuZ2VzCnRvIGNvbmZpZ3VyZSBzY3JpcHQgYXJlIG1pbmltYWwgYW5k
IHJlbGF0ZWQgdG8gdGhlIGFjdHVhbCBjaGFuZ2VzCmJlaW5nIG1hZGUgaW4gY29uZmlndXJlLmFj
LgoKPiBJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kv0-00067H-TQ; Wed, 29 Feb 2012 14:54:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2kuy-00066r-SX
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330527239!13622680!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7079 invoked from network); 29 Feb 2012 14:54:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 29 Feb 2012 14:54:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330527239; l=381;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BN61ZMrkJEodhYm0eudZ7eT2Q3M=;
	b=HHwdWnP0KA1JWt7b8/xtMtNj6Z6hwCL0McBuAU5FSd0UUHAl6Y/EwD3tqkOn4BYhm/6
	A++PltnUe0+y+dN2tFlkzm3k8gm5Yjz+Ye2IhzfaRLv63uNgBAdFGPC7qU1VJ7JOy1MZE
	UZ9u4VyTWWLFeRl1CoirmGWnoJUjeMCe+IA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo57) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w036e2o1TEmU3t ;
	Wed, 29 Feb 2012 15:53:36 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5C1A618638; Wed, 29 Feb 2012 15:53:34 +0100 (CET)
Date: Wed, 29 Feb 2012 15:53:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120229145334.GA26404@aepfle.de>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, Ian Campbell wrote:

> I _think_ this isn't required because we also checkin the generated files. A
> more complete fix might also allow the user to force regeneration but I didn't
> both here.

Perhaps flex is not really needed as well, at least it wasnt before the
change to configure. But then, both are needed if one updates .y and .l
files.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kv0-00067H-TQ; Wed, 29 Feb 2012 14:54:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2kuy-00066r-SX
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330527239!13622680!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7079 invoked from network); 29 Feb 2012 14:54:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 29 Feb 2012 14:54:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330527239; l=381;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BN61ZMrkJEodhYm0eudZ7eT2Q3M=;
	b=HHwdWnP0KA1JWt7b8/xtMtNj6Z6hwCL0McBuAU5FSd0UUHAl6Y/EwD3tqkOn4BYhm/6
	A++PltnUe0+y+dN2tFlkzm3k8gm5Yjz+Ye2IhzfaRLv63uNgBAdFGPC7qU1VJ7JOy1MZE
	UZ9u4VyTWWLFeRl1CoirmGWnoJUjeMCe+IA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo57) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w036e2o1TEmU3t ;
	Wed, 29 Feb 2012 15:53:36 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5C1A618638; Wed, 29 Feb 2012 15:53:34 +0100 (CET)
Date: Wed, 29 Feb 2012 15:53:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120229145334.GA26404@aepfle.de>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, Ian Campbell wrote:

> I _think_ this isn't required because we also checkin the generated files. A
> more complete fix might also allow the user to force regeneration but I didn't
> both here.

Perhaps flex is not really needed as well, at least it wasnt before the
change to configure. But then, both are needed if one updates .y and .l
files.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kwl-0006IC-FK; Wed, 29 Feb 2012 14:56:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2kwk-0006Ho-6o
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:56:02 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330527354!15493650!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27196 invoked from network); 29 Feb 2012 14:55:54 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.140)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Feb 2012 14:55:54 -0000
Received: from mail42-db3-R.bigfish.com (10.3.81.246) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 14:55:53 +0000
Received: from mail42-db3 (localhost [127.0.0.1])	by mail42-db3-R.bigfish.com
	(Postfix) with ESMTP id 8C8814C0295;
	Wed, 29 Feb 2012 14:55:53 +0000 (UTC)
X-SpamScore: -23
X-BigFish: VPS-23(zzbb2dI9371I179dN542M1432N98dK4015Izz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail42-db3 (localhost.localdomain [127.0.0.1]) by mail42-db3
	(MessageSwitch) id 1330527351466860_22528;
	Wed, 29 Feb 2012 14:55:51 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.243])	by
	mail42-db3.bigfish.com (Postfix) with ESMTP id 61EC0A0045;
	Wed, 29 Feb 2012 14:55:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 14:55:50 +0000
X-WSS-ID: 0M05TGY-02-9JI-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 220ACC81D4;	Wed, 29 Feb 2012 08:55:45 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 29 Feb 2012 08:55:58 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 08:55:46 -0600
Message-ID: <4F4E3C72.2030101@amd.com>
Date: Wed, 29 Feb 2012 09:55:46 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
	<12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
	<DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/29/12 00:21, Liu, Jinsong wrote:
> Hmm, no.
>
> It need flush cache, as long as *deep Cx* would be spurious-wokenup.
> The reason clflush here is, it's a light-weight flush, in fact it also could use wbinvd if not consider performance.

What address would need to be CFLUSH'd ? Both "address" and 
"pmtmr_ioport_local"?

>
> For halt, it don't need to do so since cpu still keep snoop when sleep.

If cpu not snoop when in deeper C-states, wouldn't we have a problem 
with acpi_idle_do_entry()? There is a code path (at least for for C2) 
where the cache is not flushed.

Incidentally, if CFLUSH is required for MONITOR then perhaps 
mwait_idle_with_hints() needs to have it as well?

-boris

>
> Thanks,
> Jinsong
>
> Ostrovsky, Boris wrote:
>> The patch is adding IO-based C-states. My understading is that CFLUSH
>> was to work around a MONITOR-related erratum.
>>
>> Or are you referring to something else?
>>
>> -boris
>>
>>
>> ________________________________________
>> From: Zhang, Yang Z [yang.z.zhang@intel.com]
>> Sent: Tuesday, February 28, 2012 8:37 PM
>> To: Ostrovsky, Boris; xen-devel@lists.xensource.com
>> Subject: RE: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
>> CPUs
>>
>> I noticed the following comments when using mwait based idle:
>> -------------------------------------------------------------------------
>>          while ( 1 )
>>          {
>>              /*
>>               * 1. The CLFLUSH is a workaround for erratum AAI65 for
>>               * the Xeon 7400 series.
>>               * 2. The WBINVD is insufficient due to the
>> spurious-wakeup
>>               * case where we return around the loop.
>>               * 3. Unlike wbinvd, clflush is a light weight but not
>> serializing
>>               * instruction, hence memory fence is necessary to make
>> sure all
>>               * load/store visible before flush cache line.
>>               */
>>              mb();
>>              clflush(mwait_ptr);
>>              __monitor(mwait_ptr, 0, 0);
>>              mb();
>>              __mwait(cx->address, 0);
>>          }
>>      }
>> -------------------------------------------------------------------------
>> Your patch should follow it too.
>>
>> best regards
>> yang
>>
>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xen.org
>>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
>>> Sent: Wednesday, February 29, 2012 6:09 AM
>>> To: xen-devel@lists.xensource.com
>>> Cc: boris.ostrovsky@amd.com
>>> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
>>> CPUs
>>>
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>  # Date 1330466573
>>> -3600 # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
>>> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
>>> x86: Use deep C states for off-lined CPUs
>>>
>>> Currently when a core is taken off-line it is placed in C1 state
>>> (unless MONITOR/MWAIT is used). This patch allows a core to go to
>>> deeper C states resulting in significantly higher power savings.
>>>
>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>
>>> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
>>> --- a/xen/arch/x86/acpi/cpu_idle.c    Mon Feb 27 17:05:18 2012 +0000
>>> +++ b/xen/arch/x86/acpi/cpu_idle.c    Tue Feb 28 23:02:53 2012 +0100
>>> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>>>       if ( (cx =&power->states[power->count-1]) == NULL )
>>> goto default_halt;
>>>
>>> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); -
>>>       if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>>>       {
>>> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); +
>>>           /*
>>>            * Cache must be flushed as the last operation before
>>> sleeping.
>>>            * Otherwise, CPU may still hold dirty data, breaking cache
>>> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>>>               mb(); __mwait(cx->address, 0);
>>>           }
>>> +    }
>>> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO ) +    {
>>> +        /* Avoid references to shared data after the cache flush */
>>> +        u32 address = cx->address;
>>> +        u32 pmtmr_ioport_local = pmtmr_ioport;
>>> +
>>> +        wbinvd();
>>> +
>>> +        while ( 1 )
>>> +        {
>>> +            inb(address);
>>> +            inl(pmtmr_ioport_local);
>>> +        }
>>>       }
>>>
>>>   default_halt:
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@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 Feb 29 14:56:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kwl-0006IC-FK; Wed, 29 Feb 2012 14:56:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1S2kwk-0006Ho-6o
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:56:02 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1330527354!15493650!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27196 invoked from network); 29 Feb 2012 14:55:54 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.140)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Feb 2012 14:55:54 -0000
Received: from mail42-db3-R.bigfish.com (10.3.81.246) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 14:55:53 +0000
Received: from mail42-db3 (localhost [127.0.0.1])	by mail42-db3-R.bigfish.com
	(Postfix) with ESMTP id 8C8814C0295;
	Wed, 29 Feb 2012 14:55:53 +0000 (UTC)
X-SpamScore: -23
X-BigFish: VPS-23(zzbb2dI9371I179dN542M1432N98dK4015Izz1202hzz8275bh8275dhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail42-db3 (localhost.localdomain [127.0.0.1]) by mail42-db3
	(MessageSwitch) id 1330527351466860_22528;
	Wed, 29 Feb 2012 14:55:51 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.243])	by
	mail42-db3.bigfish.com (Postfix) with ESMTP id 61EC0A0045;
	Wed, 29 Feb 2012 14:55:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 29 Feb 2012 14:55:50 +0000
X-WSS-ID: 0M05TGY-02-9JI-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 220ACC81D4;	Wed, 29 Feb 2012 08:55:45 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 29 Feb 2012 08:55:58 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 08:55:46 -0600
Message-ID: <4F4E3C72.2030101@amd.com>
Date: Wed, 29 Feb 2012 09:55:46 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
	<12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
	<DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/29/12 00:21, Liu, Jinsong wrote:
> Hmm, no.
>
> It need flush cache, as long as *deep Cx* would be spurious-wokenup.
> The reason clflush here is, it's a light-weight flush, in fact it also could use wbinvd if not consider performance.

What address would need to be CFLUSH'd ? Both "address" and 
"pmtmr_ioport_local"?

>
> For halt, it don't need to do so since cpu still keep snoop when sleep.

If cpu not snoop when in deeper C-states, wouldn't we have a problem 
with acpi_idle_do_entry()? There is a code path (at least for for C2) 
where the cache is not flushed.

Incidentally, if CFLUSH is required for MONITOR then perhaps 
mwait_idle_with_hints() needs to have it as well?

-boris

>
> Thanks,
> Jinsong
>
> Ostrovsky, Boris wrote:
>> The patch is adding IO-based C-states. My understading is that CFLUSH
>> was to work around a MONITOR-related erratum.
>>
>> Or are you referring to something else?
>>
>> -boris
>>
>>
>> ________________________________________
>> From: Zhang, Yang Z [yang.z.zhang@intel.com]
>> Sent: Tuesday, February 28, 2012 8:37 PM
>> To: Ostrovsky, Boris; xen-devel@lists.xensource.com
>> Subject: RE: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
>> CPUs
>>
>> I noticed the following comments when using mwait based idle:
>> -------------------------------------------------------------------------
>>          while ( 1 )
>>          {
>>              /*
>>               * 1. The CLFLUSH is a workaround for erratum AAI65 for
>>               * the Xeon 7400 series.
>>               * 2. The WBINVD is insufficient due to the
>> spurious-wakeup
>>               * case where we return around the loop.
>>               * 3. Unlike wbinvd, clflush is a light weight but not
>> serializing
>>               * instruction, hence memory fence is necessary to make
>> sure all
>>               * load/store visible before flush cache line.
>>               */
>>              mb();
>>              clflush(mwait_ptr);
>>              __monitor(mwait_ptr, 0, 0);
>>              mb();
>>              __mwait(cx->address, 0);
>>          }
>>      }
>> -------------------------------------------------------------------------
>> Your patch should follow it too.
>>
>> best regards
>> yang
>>
>>
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xen.org
>>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Boris Ostrovsky
>>> Sent: Wednesday, February 29, 2012 6:09 AM
>>> To: xen-devel@lists.xensource.com
>>> Cc: boris.ostrovsky@amd.com
>>> Subject: [Xen-devel] [PATCH] x86: Use deep C states for off-lined
>>> CPUs
>>>
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>  # Date 1330466573
>>> -3600 # Node ID 9e5991ad9c85b5176ce269001e7957e8805dd93c
>>> # Parent  a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
>>> x86: Use deep C states for off-lined CPUs
>>>
>>> Currently when a core is taken off-line it is placed in C1 state
>>> (unless MONITOR/MWAIT is used). This patch allows a core to go to
>>> deeper C states resulting in significantly higher power savings.
>>>
>>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@amd.com>
>>>
>>> diff -r a7bacdc5449a -r 9e5991ad9c85 xen/arch/x86/acpi/cpu_idle.c
>>> --- a/xen/arch/x86/acpi/cpu_idle.c    Mon Feb 27 17:05:18 2012 +0000
>>> +++ b/xen/arch/x86/acpi/cpu_idle.c    Tue Feb 28 23:02:53 2012 +0100
>>> @@ -573,10 +573,10 @@ static void acpi_dead_idle(void)
>>>       if ( (cx =&power->states[power->count-1]) == NULL )
>>> goto default_halt;
>>>
>>> -    mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); -
>>>       if ( cx->entry_method == ACPI_CSTATE_EM_FFH )
>>>       {
>>> +        mwait_ptr = (void *)&mwait_wakeup(smp_processor_id()); +
>>>           /*
>>>            * Cache must be flushed as the last operation before
>>> sleeping.
>>>            * Otherwise, CPU may still hold dirty data, breaking cache
>>> coherency, @@ -601,6 +601,20 @@ static void acpi_dead_idle(void)
>>>               mb(); __mwait(cx->address, 0);
>>>           }
>>> +    }
>>> +    else if ( cx->entry_method == ACPI_CSTATE_EM_SYSIO ) +    {
>>> +        /* Avoid references to shared data after the cache flush */
>>> +        u32 address = cx->address;
>>> +        u32 pmtmr_ioport_local = pmtmr_ioport;
>>> +
>>> +        wbinvd();
>>> +
>>> +        while ( 1 )
>>> +        {
>>> +            inb(address);
>>> +            inl(pmtmr_ioport_local);
>>> +        }
>>>       }
>>>
>>>   default_halt:
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@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 Feb 29 14:56:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kx0-0006KH-Rm; Wed, 29 Feb 2012 14:56:18 +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 1S2kx0-0006K7-2m
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:56:18 +0000
Received: from [85.158.139.83:39212] by server-8.bemta-5.messagelabs.com id
	F7/05-07862-19C3E4F4; Wed, 29 Feb 2012 14:56:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1330527375!17238607!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjM3NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15413 invoked from network); 29 Feb 2012 14:56:16 -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;
	29 Feb 2012 14:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325480400"; d="scan'208";a="22563607"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:56:15 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 29 Feb 2012
	09:56:15 -0500
Message-ID: <4F4E3C8D.40607@citrix.com>
Date: Wed, 29 Feb 2012 14:56:13 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/12 14:25, Ian Campbell wrote:
> 
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -64,7 +64,6 @@ AX_SET_FLAGS
>  AC_ARG_VAR([PYTHON], [Path to the Python parser])
>  AC_ARG_VAR([PERL], [Path to Perl parser])
>  AC_ARG_VAR([IP], [Path to ip tool])
> -AC_ARG_VAR([BISON], [Path to Bison parser generator])
>  AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])

Similarly, what about flex?  Are flex generated file checked in as well?

>  AC_ARG_VAR([CURL], [Path to curl-config tool])
>  AC_ARG_VAR([XML], [Path to xml2-config tool])

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:56:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kx0-0006KH-Rm; Wed, 29 Feb 2012 14:56:18 +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 1S2kx0-0006K7-2m
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 14:56:18 +0000
Received: from [85.158.139.83:39212] by server-8.bemta-5.messagelabs.com id
	F7/05-07862-19C3E4F4; Wed, 29 Feb 2012 14:56:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1330527375!17238607!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMjM3NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15413 invoked from network); 29 Feb 2012 14:56:16 -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;
	29 Feb 2012 14:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325480400"; d="scan'208";a="22563607"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 09:56:15 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 29 Feb 2012
	09:56:15 -0500
Message-ID: <4F4E3C8D.40607@citrix.com>
Date: Wed, 29 Feb 2012 14:56:13 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/12 14:25, Ian Campbell wrote:
> 
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -64,7 +64,6 @@ AX_SET_FLAGS
>  AC_ARG_VAR([PYTHON], [Path to the Python parser])
>  AC_ARG_VAR([PERL], [Path to Perl parser])
>  AC_ARG_VAR([IP], [Path to ip tool])
> -AC_ARG_VAR([BISON], [Path to Bison parser generator])
>  AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])

Similarly, what about flex?  Are flex generated file checked in as well?

>  AC_ARG_VAR([CURL], [Path to curl-config tool])
>  AC_ARG_VAR([XML], [Path to xml2-config tool])

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kza-0006bO-Or; Wed, 29 Feb 2012 14:58:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2kzY-0006aa-KJ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:58:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527530!9831425!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27630 invoked from network); 29 Feb 2012 14:58:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:58:50 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:58:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 14:58:43 +0000
Message-ID: <1330527524-23837-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
References: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxc: pass arguments to xc_hvm_build() in
	a 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

From: David Vrabel <david.vrabel@citrix.com>

To allow new parameters to be added to the xc_hvm_build*() family of
functions, pass them in a structure.  Make the other variants fill in
the structure and call xc_hvm_build() (except for xc_hvm_build_mem()
which had no users and is removed).

The units of the mem_size and mem_target arguments are in bytes (not
MiB like the old functions).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/libxc/ia64/xc_ia64_hvm_build.c |   21 ++++--
 tools/libxc/xc_hvm_build.c           |  115 +++++++++-------------------------
 tools/libxc/xenguest.h               |   27 +++++---
 tools/libxc/xg_private.c             |    3 +-
 4 files changed, 62 insertions(+), 104 deletions(-)

diff --git a/tools/libxc/ia64/xc_ia64_hvm_build.c b/tools/libxc/ia64/xc_ia64_hvm_build.c
index 18be616..3f9273f 100644
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c
@@ -912,8 +912,8 @@ setup_guest(xc_interface *xch, uint32_t dom, unsigned long memsize,
             char *image, unsigned long image_size)
 {
     xen_pfn_t *pfn_list;
-    unsigned long dom_memsize = memsize << 20;
-    unsigned long nr_pages = memsize << (20 - PAGE_SHIFT);
+    unsigned long dom_memsize = memsize;
+    unsigned long nr_pages = memsize >> PAGE_SHIFT;
     unsigned long vcpus;
     unsigned long nr_special_pages;
     unsigned long memmap_info_pfn;
@@ -1072,14 +1072,14 @@ error_out:
 }
 
 int
-xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_name)
+xc_hvm_build(xc_interface *xch, uint32_t domid, const struct xc_hvm_build_args *args)
 {
     vcpu_guest_context_any_t st_ctxt_any;
     vcpu_guest_context_t *ctxt = &st_ctxt_any.c;
     char *image = NULL;
     unsigned long image_size;
 
-    image = xc_read_image(xch, image_name, &image_size);
+    image = xc_read_image(xch, args->image_file_name, &image_size);
     if (image == NULL) {
         PERROR("Could not read guest firmware image %s", image_name);
         goto error_out;
@@ -1087,7 +1087,7 @@ xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_n
 
     image_size = (image_size + PAGE_SIZE - 1) & PAGE_MASK;
 
-    if (setup_guest(xch, domid, (unsigned long)memsize, image,
+    if (setup_guest(xch, domid, (unsigned long)args->mem_size, image,
                     image_size) < 0) {
         ERROR("Error constructing guest OS");
         goto error_out;
@@ -1114,6 +1114,8 @@ error_out:
  * files/filenames.  If target < memsize, domain is created with
  * memsize pages marked populate-on-demand, and with a PoD cache size
  * of target.  If target == memsize, pages are populated normally.
+ *
+ * XXX:PoD isn't supported yet so setting target does nothing.
  */
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -1121,8 +1123,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name)
 {
-    /* XXX:PoD isn't supported yet */
-    return xc_hvm_build(xch, domid, target, image_name);
+    struct xc_hvm_build_args args;
+
+    args.mem_size = (uint64_t)memsize << 20;
+    args.mem_target = (uint64_t)target << 20;
+    args.image_file_name = image_name;
+
+    return xc_hvm_build(xch, domid, &args);
 }
 
 /*
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 1fa5658..d08b54b 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -136,12 +136,12 @@ static int check_mmio_hole(uint64_t start, uint64_t memsize)
 }
 
 static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
+                       uint32_t dom, const struct xc_hvm_build_args *args,
                        char *image, unsigned long image_size)
 {
     xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long i, nr_pages = args->mem_size >> PAGE_SHIFT;
+    unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -153,11 +153,7 @@ static int setup_guest(xc_interface *xch,
         stat_1gb_pages = 0;
     int pod_mode = 0;
 
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
+    if ( nr_pages > target_pages )
         pod_mode = 1;
 
     memset(&elf, 0, sizeof(elf));
@@ -168,7 +164,7 @@ static int setup_guest(xc_interface *xch,
 
     elf_parse_binary(&elf);
     v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
+    v_end = args->mem_size;
 
     if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
     {
@@ -393,39 +389,34 @@ static int setup_guest(xc_interface *xch,
     return -1;
 }
 
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
 /* xc_hvm_build:
  * Create a domain for a virtualized Linux, using files/filenames.
  */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_build_args *hvm_args)
 {
-    char *image;
-    int  sts;
+    struct xc_hvm_build_args args = *hvm_args;
+    void *image;
     unsigned long image_size;
+    int sts;
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+    if ( domid == 0 )
+        return -1;
+    if ( args.image_file_name == NULL )
         return -1;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+    if ( args.mem_target == 0 )
+        args.mem_target = args.mem_size;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( args.mem_size < (2ull << 20) || args.mem_target < (2ull << 20) )
+        return -1;
+
+    image = xc_read_image(xch, args.image_file_name, &image_size);
+    if ( image == NULL )
+        return -1;
+
+    sts = setup_guest(xch, domid, &args, image, image_size);
 
     free(image);
 
@@ -445,59 +436,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                            int target,
                            const char *image_name)
 {
-    char *image;
-    int  sts;
-    unsigned long image_size;
+    struct xc_hvm_build_args args = {};
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
+    args.mem_size = (uint64_t)memsize << 20;
+    args.mem_target = (uint64_t)target << 20;
+    args.image_file_name = image_name;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
+    return xc_hvm_build(xch, domid, &args);
 }
 
 /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 533e702..f52ca74 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
                        unsigned int console_evtchn,
                        unsigned long *console_mfn);
 
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name);
+struct xc_hvm_build_args {
+    uint64_t mem_size;           /* Memory size in bytes. */
+    uint64_t mem_target;         /* Memory target in bytes. */
+    const char *image_file_name; /* File name of the image to load. */
+};
+
+/**
+ * Build a HVM domain.
+ * @parm xch      libxc context handle.
+ * @parm domid    domain ID for the new domain.
+ * @parm hvm_args parameters for the new domain.
+ *
+ * The memory size and image file parameters are required, the rest
+ * are optional.
+ */
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_build_args *hvm_args);
 
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -182,12 +195,6 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name);
 
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size);
-
 int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
 
 int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port);
diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
index 4b624a5..3864bc7 100644
--- a/tools/libxc/xg_private.c
+++ b/tools/libxc/xg_private.c
@@ -192,8 +192,7 @@ unsigned long csum_page(void *page)
 __attribute__((weak)) 
     int xc_hvm_build(xc_interface *xch,
                      uint32_t domid,
-                     int memsize,
-                     const char *image_name)
+                     const struct xc_hvm_build_args *hvm_args)
 {
     errno = ENOSYS;
     return -1;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kza-0006bO-Or; Wed, 29 Feb 2012 14:58:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2kzY-0006aa-KJ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:58:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527530!9831425!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27630 invoked from network); 29 Feb 2012 14:58:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:58:50 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:58:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 14:58:43 +0000
Message-ID: <1330527524-23837-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
References: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxc: pass arguments to xc_hvm_build() in
	a 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

From: David Vrabel <david.vrabel@citrix.com>

To allow new parameters to be added to the xc_hvm_build*() family of
functions, pass them in a structure.  Make the other variants fill in
the structure and call xc_hvm_build() (except for xc_hvm_build_mem()
which had no users and is removed).

The units of the mem_size and mem_target arguments are in bytes (not
MiB like the old functions).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/libxc/ia64/xc_ia64_hvm_build.c |   21 ++++--
 tools/libxc/xc_hvm_build.c           |  115 +++++++++-------------------------
 tools/libxc/xenguest.h               |   27 +++++---
 tools/libxc/xg_private.c             |    3 +-
 4 files changed, 62 insertions(+), 104 deletions(-)

diff --git a/tools/libxc/ia64/xc_ia64_hvm_build.c b/tools/libxc/ia64/xc_ia64_hvm_build.c
index 18be616..3f9273f 100644
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c
@@ -912,8 +912,8 @@ setup_guest(xc_interface *xch, uint32_t dom, unsigned long memsize,
             char *image, unsigned long image_size)
 {
     xen_pfn_t *pfn_list;
-    unsigned long dom_memsize = memsize << 20;
-    unsigned long nr_pages = memsize << (20 - PAGE_SHIFT);
+    unsigned long dom_memsize = memsize;
+    unsigned long nr_pages = memsize >> PAGE_SHIFT;
     unsigned long vcpus;
     unsigned long nr_special_pages;
     unsigned long memmap_info_pfn;
@@ -1072,14 +1072,14 @@ error_out:
 }
 
 int
-xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_name)
+xc_hvm_build(xc_interface *xch, uint32_t domid, const struct xc_hvm_build_args *args)
 {
     vcpu_guest_context_any_t st_ctxt_any;
     vcpu_guest_context_t *ctxt = &st_ctxt_any.c;
     char *image = NULL;
     unsigned long image_size;
 
-    image = xc_read_image(xch, image_name, &image_size);
+    image = xc_read_image(xch, args->image_file_name, &image_size);
     if (image == NULL) {
         PERROR("Could not read guest firmware image %s", image_name);
         goto error_out;
@@ -1087,7 +1087,7 @@ xc_hvm_build(xc_interface *xch, uint32_t domid, int memsize, const char *image_n
 
     image_size = (image_size + PAGE_SIZE - 1) & PAGE_MASK;
 
-    if (setup_guest(xch, domid, (unsigned long)memsize, image,
+    if (setup_guest(xch, domid, (unsigned long)args->mem_size, image,
                     image_size) < 0) {
         ERROR("Error constructing guest OS");
         goto error_out;
@@ -1114,6 +1114,8 @@ error_out:
  * files/filenames.  If target < memsize, domain is created with
  * memsize pages marked populate-on-demand, and with a PoD cache size
  * of target.  If target == memsize, pages are populated normally.
+ *
+ * XXX:PoD isn't supported yet so setting target does nothing.
  */
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -1121,8 +1123,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name)
 {
-    /* XXX:PoD isn't supported yet */
-    return xc_hvm_build(xch, domid, target, image_name);
+    struct xc_hvm_build_args args;
+
+    args.mem_size = (uint64_t)memsize << 20;
+    args.mem_target = (uint64_t)target << 20;
+    args.image_file_name = image_name;
+
+    return xc_hvm_build(xch, domid, &args);
 }
 
 /*
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 1fa5658..d08b54b 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -136,12 +136,12 @@ static int check_mmio_hole(uint64_t start, uint64_t memsize)
 }
 
 static int setup_guest(xc_interface *xch,
-                       uint32_t dom, int memsize, int target,
+                       uint32_t dom, const struct xc_hvm_build_args *args,
                        char *image, unsigned long image_size)
 {
     xen_pfn_t *page_array = NULL;
-    unsigned long i, nr_pages = (unsigned long)memsize << (20 - PAGE_SHIFT);
-    unsigned long target_pages = (unsigned long)target << (20 - PAGE_SHIFT);
+    unsigned long i, nr_pages = args->mem_size >> PAGE_SHIFT;
+    unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -153,11 +153,7 @@ static int setup_guest(xc_interface *xch,
         stat_1gb_pages = 0;
     int pod_mode = 0;
 
-    /* An HVM guest must be initialised with at least 2MB memory. */
-    if ( memsize < 2 || target < 2 )
-        goto error_out;
-
-    if ( memsize > target )
+    if ( nr_pages > target_pages )
         pod_mode = 1;
 
     memset(&elf, 0, sizeof(elf));
@@ -168,7 +164,7 @@ static int setup_guest(xc_interface *xch,
 
     elf_parse_binary(&elf);
     v_start = 0;
-    v_end = (unsigned long long)memsize << 20;
+    v_end = args->mem_size;
 
     if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
     {
@@ -393,39 +389,34 @@ static int setup_guest(xc_interface *xch,
     return -1;
 }
 
-static int xc_hvm_build_internal(xc_interface *xch,
-                                 uint32_t domid,
-                                 int memsize,
-                                 int target,
-                                 char *image,
-                                 unsigned long image_size)
-{
-    if ( (image == NULL) || (image_size == 0) )
-    {
-        ERROR("Image required");
-        return -1;
-    }
-
-    return setup_guest(xch, domid, memsize, target, image, image_size);
-}
-
 /* xc_hvm_build:
  * Create a domain for a virtualized Linux, using files/filenames.
  */
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name)
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_build_args *hvm_args)
 {
-    char *image;
-    int  sts;
+    struct xc_hvm_build_args args = *hvm_args;
+    void *image;
     unsigned long image_size;
+    int sts;
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
+    if ( domid == 0 )
+        return -1;
+    if ( args.image_file_name == NULL )
         return -1;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize, image, image_size);
+    if ( args.mem_target == 0 )
+        args.mem_target = args.mem_size;
+
+    /* An HVM guest must be initialised with at least 2MB memory. */
+    if ( args.mem_size < (2ull << 20) || args.mem_target < (2ull << 20) )
+        return -1;
+
+    image = xc_read_image(xch, args.image_file_name, &image_size);
+    if ( image == NULL )
+        return -1;
+
+    sts = setup_guest(xch, domid, &args, image, image_size);
 
     free(image);
 
@@ -445,59 +436,13 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                            int target,
                            const char *image_name)
 {
-    char *image;
-    int  sts;
-    unsigned long image_size;
+    struct xc_hvm_build_args args = {};
 
-    if ( (image_name == NULL) ||
-         ((image = xc_read_image(xch, image_name, &image_size)) == NULL) )
-        return -1;
+    args.mem_size = (uint64_t)memsize << 20;
+    args.mem_target = (uint64_t)target << 20;
+    args.image_file_name = image_name;
 
-    sts = xc_hvm_build_internal(xch, domid, memsize, target, image, image_size);
-
-    free(image);
-
-    return sts;
-}
-
-/* xc_hvm_build_mem:
- * Create a domain for a virtualized Linux, using memory buffers.
- */
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size)
-{
-    int           sts;
-    unsigned long img_len;
-    char         *img;
-
-    /* Validate that there is a kernel buffer */
-
-    if ( (image_buffer == NULL) || (image_size == 0) )
-    {
-        ERROR("kernel image buffer not present");
-        return -1;
-    }
-
-    img = xc_inflate_buffer(xch, image_buffer, image_size, &img_len);
-    if ( img == NULL )
-    {
-        ERROR("unable to inflate ram disk buffer");
-        return -1;
-    }
-
-    sts = xc_hvm_build_internal(xch, domid, memsize, memsize,
-                                img, img_len);
-
-    /* xc_inflate_buffer may return the original buffer pointer (for
-       for already inflated buffers), so exercise some care in freeing */
-
-    if ( (img != NULL) && (img != image_buffer) )
-        free(img);
-
-    return sts;
+    return xc_hvm_build(xch, domid, &args);
 }
 
 /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 533e702..f52ca74 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -171,10 +171,23 @@ int xc_linux_build_mem(xc_interface *xch,
                        unsigned int console_evtchn,
                        unsigned long *console_mfn);
 
-int xc_hvm_build(xc_interface *xch,
-                 uint32_t domid,
-                 int memsize,
-                 const char *image_name);
+struct xc_hvm_build_args {
+    uint64_t mem_size;           /* Memory size in bytes. */
+    uint64_t mem_target;         /* Memory target in bytes. */
+    const char *image_file_name; /* File name of the image to load. */
+};
+
+/**
+ * Build a HVM domain.
+ * @parm xch      libxc context handle.
+ * @parm domid    domain ID for the new domain.
+ * @parm hvm_args parameters for the new domain.
+ *
+ * The memory size and image file parameters are required, the rest
+ * are optional.
+ */
+int xc_hvm_build(xc_interface *xch, uint32_t domid,
+                 const struct xc_hvm_build_args *hvm_args);
 
 int xc_hvm_build_target_mem(xc_interface *xch,
                             uint32_t domid,
@@ -182,12 +195,6 @@ int xc_hvm_build_target_mem(xc_interface *xch,
                             int target,
                             const char *image_name);
 
-int xc_hvm_build_mem(xc_interface *xch,
-                     uint32_t domid,
-                     int memsize,
-                     const char *image_buffer,
-                     unsigned long image_size);
-
 int xc_suspend_evtchn_release(xc_interface *xch, xc_evtchn *xce, int domid, int suspend_evtchn);
 
 int xc_suspend_evtchn_init(xc_interface *xch, xc_evtchn *xce, int domid, int port);
diff --git a/tools/libxc/xg_private.c b/tools/libxc/xg_private.c
index 4b624a5..3864bc7 100644
--- a/tools/libxc/xg_private.c
+++ b/tools/libxc/xg_private.c
@@ -192,8 +192,7 @@ unsigned long csum_page(void *page)
 __attribute__((weak)) 
     int xc_hvm_build(xc_interface *xch,
                      uint32_t domid,
-                     int memsize,
-                     const char *image_name)
+                     const struct xc_hvm_build_args *hvm_args)
 {
     errno = ENOSYS;
     return -1;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kzZ-0006bC-Db; Wed, 29 Feb 2012 14:58:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2kzY-0006aW-4N
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:58:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527530!9831425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27620 invoked from network); 29 Feb 2012 14:58:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:58:50 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:58:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 29 Feb 2012 14:58:42 +0000
Message-ID: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/2] libxc: allow size of MMIO hole for HVM
	guests to be 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

This series allows a user of libxc to set the size of the MMIO hole of
HVM guests.  The rationale for this is included in the patch 2.

As part of this, the API calls were tidied up to allow new parameters
to be added more easily (by using a transparent structure).  Note that
this breaks backwards compatibility and that adding more parameters
will also break backwards compatibility.

I took a stab at fixing the ia64 version of xc_hvm_domain_build() but
I haven't even tried a ia64 build...

David

Changes since v1:

- rename structure to struct xc_hvm_build_args
- remove /**< markers


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kzZ-0006bC-Db; Wed, 29 Feb 2012 14:58:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2kzY-0006aW-4N
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:58:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527530!9831425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27620 invoked from network); 29 Feb 2012 14:58:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:58:50 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:58:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 29 Feb 2012 14:58:42 +0000
Message-ID: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/2] libxc: allow size of MMIO hole for HVM
	guests to be 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

This series allows a user of libxc to set the size of the MMIO hole of
HVM guests.  The rationale for this is included in the patch 2.

As part of this, the API calls were tidied up to allow new parameters
to be added more easily (by using a transparent structure).  Note that
this breaks backwards compatibility and that adding more parameters
will also break backwards compatibility.

I took a stab at fixing the ia64 version of xc_hvm_domain_build() but
I haven't even tried a ia64 build...

David

Changes since v1:

- rename structure to struct xc_hvm_build_args
- remove /**< markers


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kzb-0006bb-45; Wed, 29 Feb 2012 14:58:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2kzY-0006ab-RK
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:58:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527530!9831425!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27654 invoked from network); 29 Feb 2012 14:58:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:58:50 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:58:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 14:58:44 +0000
Message-ID: <1330527524-23837-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
References: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxc: add MMIO hole size parameter to
	xc_hvm_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

From: David Vrabel <david.vrabel@citrix.com>

Add a parameter for the MMIO hole size when building a HVM domain.

This is useful for specifying a larger than normal MMIO hole to ensure
that no PCIe device's MMIO region overlaps with RAM in a guest's
physical address space.  This is needed on certain systems with PCIe
switches with a broken ACS capability.  On these systems, if a device
downstream of the switch attempts a DMA to a guest physical address
that overlaps with the MMIO region of another downstream device, then
the switch routes the transfer directly to the device and the read or
write never hits RAM.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/libxc/xc_hvm_build.c |   29 ++++++++++++++++++-----------
 tools/libxc/xenguest.h     |    1 +
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index d08b54b..780b23f 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -46,7 +46,8 @@
 #define NR_SPECIAL_PAGES     5
 #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
 
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
     struct hvm_info_table *hvm_info = (struct hvm_info_table *)
         (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -54,10 +55,10 @@ static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
     uint8_t sum;
     int i;
 
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    if ( lowmem_end > mmio_start )
     {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
+        highmem_end = (1ull<<32) + (lowmem_end - mmio_start);
+        lowmem_end = mmio_start;
     }
 
     memset(hvm_info_page, 0, PAGE_SIZE);
@@ -126,10 +127,10 @@ static int loadelfimage(
  * Check whether there exists mmio hole in the specified memory range.
  * Returns 1 if exists, else returns 0.
  */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
+static int check_mmio_hole(uint64_t start, uint64_t memsize,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
         return 0;
     else
         return 1;
@@ -142,6 +143,8 @@ static int setup_guest(xc_interface *xch,
     xen_pfn_t *page_array = NULL;
     unsigned long i, nr_pages = args->mem_size >> PAGE_SHIFT;
     unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
+    uint64_t mmio_start = (1ull << 32) - args->mmio_size;
+    uint64_t mmio_size = args->mmio_size;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -188,8 +191,8 @@ static int setup_guest(xc_interface *xch,
 
     for ( i = 0; i < nr_pages; i++ )
         page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+    for ( i = mmio_start >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += mmio_size >> PAGE_SHIFT;
 
     /*
      * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
@@ -230,7 +233,8 @@ static int setup_guest(xc_interface *xch,
         if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
              /* Check if there exists MMIO hole in the 1GB memory range */
              !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT,
+                              mmio_start, mmio_size) )
         {
             long done;
             unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
@@ -327,7 +331,7 @@ static int setup_guest(xc_interface *xch,
               xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
               HVM_INFO_PFN)) == NULL )
         goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
+    build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
     munmap(hvm_info_page, PAGE_SIZE);
 
     /* Allocate and clear special pages. */
@@ -408,6 +412,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
     if ( args.mem_target == 0 )
         args.mem_target = args.mem_size;
 
+    if ( args.mmio_size == 0 )
+        args.mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
+
     /* An HVM guest must be initialised with at least 2MB memory. */
     if ( args.mem_size < (2ull << 20) || args.mem_target < (2ull << 20) )
         return -1;
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index f52ca74..8d885d3 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -174,6 +174,7 @@ int xc_linux_build_mem(xc_interface *xch,
 struct xc_hvm_build_args {
     uint64_t mem_size;           /* Memory size in bytes. */
     uint64_t mem_target;         /* Memory target in bytes. */
+    uint64_t mmio_size;          /* Size of the MMIO hole in bytes. */
     const char *image_file_name; /* File name of the image to load. */
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14: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 1S2kzb-0006bb-45; Wed, 29 Feb 2012 14:58:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1S2kzY-0006ab-RK
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:58:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527530!9831425!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27654 invoked from network); 29 Feb 2012 14:58:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:58:50 +0000
Received: from qabil.uk.xensource.com (10.80.2.76) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 14:58:50 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 29 Feb 2012 14:58:44 +0000
Message-ID: <1330527524-23837-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
References: <1330527524-23837-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxc: add MMIO hole size parameter to
	xc_hvm_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

From: David Vrabel <david.vrabel@citrix.com>

Add a parameter for the MMIO hole size when building a HVM domain.

This is useful for specifying a larger than normal MMIO hole to ensure
that no PCIe device's MMIO region overlaps with RAM in a guest's
physical address space.  This is needed on certain systems with PCIe
switches with a broken ACS capability.  On these systems, if a device
downstream of the switch attempts a DMA to a guest physical address
that overlaps with the MMIO region of another downstream device, then
the switch routes the transfer directly to the device and the read or
write never hits RAM.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 tools/libxc/xc_hvm_build.c |   29 ++++++++++++++++++-----------
 tools/libxc/xenguest.h     |    1 +
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index d08b54b..780b23f 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -46,7 +46,8 @@
 #define NR_SPECIAL_PAGES     5
 #define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
 
-static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
+static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
     struct hvm_info_table *hvm_info = (struct hvm_info_table *)
         (((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -54,10 +55,10 @@ static void build_hvm_info(void *hvm_info_page, uint64_t mem_size)
     uint8_t sum;
     int i;
 
-    if ( lowmem_end > HVM_BELOW_4G_RAM_END )
+    if ( lowmem_end > mmio_start )
     {
-        highmem_end = lowmem_end + (1ull<<32) - HVM_BELOW_4G_RAM_END;
-        lowmem_end = HVM_BELOW_4G_RAM_END;
+        highmem_end = (1ull<<32) + (lowmem_end - mmio_start);
+        lowmem_end = mmio_start;
     }
 
     memset(hvm_info_page, 0, PAGE_SIZE);
@@ -126,10 +127,10 @@ static int loadelfimage(
  * Check whether there exists mmio hole in the specified memory range.
  * Returns 1 if exists, else returns 0.
  */
-static int check_mmio_hole(uint64_t start, uint64_t memsize)
+static int check_mmio_hole(uint64_t start, uint64_t memsize,
+                           uint64_t mmio_start, uint64_t mmio_size)
 {
-    if ( start + memsize <= HVM_BELOW_4G_MMIO_START ||
-         start >= HVM_BELOW_4G_MMIO_START + HVM_BELOW_4G_MMIO_LENGTH )
+    if ( start + memsize <= mmio_start || start >= mmio_start + mmio_size )
         return 0;
     else
         return 1;
@@ -142,6 +143,8 @@ static int setup_guest(xc_interface *xch,
     xen_pfn_t *page_array = NULL;
     unsigned long i, nr_pages = args->mem_size >> PAGE_SHIFT;
     unsigned long target_pages = args->mem_target >> PAGE_SHIFT;
+    uint64_t mmio_start = (1ull << 32) - args->mmio_size;
+    uint64_t mmio_size = args->mmio_size;
     unsigned long entry_eip, cur_pages, cur_pfn;
     void *hvm_info_page;
     uint32_t *ident_pt;
@@ -188,8 +191,8 @@ static int setup_guest(xc_interface *xch,
 
     for ( i = 0; i < nr_pages; i++ )
         page_array[i] = i;
-    for ( i = HVM_BELOW_4G_RAM_END >> PAGE_SHIFT; i < nr_pages; i++ )
-        page_array[i] += HVM_BELOW_4G_MMIO_LENGTH >> PAGE_SHIFT;
+    for ( i = mmio_start >> PAGE_SHIFT; i < nr_pages; i++ )
+        page_array[i] += mmio_size >> PAGE_SHIFT;
 
     /*
      * Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
@@ -230,7 +233,8 @@ static int setup_guest(xc_interface *xch,
         if ( ((count | cur_pfn) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 &&
              /* Check if there exists MMIO hole in the 1GB memory range */
              !check_mmio_hole(cur_pfn << PAGE_SHIFT,
-                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT) )
+                              SUPERPAGE_1GB_NR_PFNS << PAGE_SHIFT,
+                              mmio_start, mmio_size) )
         {
             long done;
             unsigned long nr_extents = count >> SUPERPAGE_1GB_SHIFT;
@@ -327,7 +331,7 @@ static int setup_guest(xc_interface *xch,
               xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
               HVM_INFO_PFN)) == NULL )
         goto error_out;
-    build_hvm_info(hvm_info_page, v_end);
+    build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
     munmap(hvm_info_page, PAGE_SIZE);
 
     /* Allocate and clear special pages. */
@@ -408,6 +412,9 @@ int xc_hvm_build(xc_interface *xch, uint32_t domid,
     if ( args.mem_target == 0 )
         args.mem_target = args.mem_size;
 
+    if ( args.mmio_size == 0 )
+        args.mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
+
     /* An HVM guest must be initialised with at least 2MB memory. */
     if ( args.mem_size < (2ull << 20) || args.mem_target < (2ull << 20) )
         return -1;
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index f52ca74..8d885d3 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -174,6 +174,7 @@ int xc_linux_build_mem(xc_interface *xch,
 struct xc_hvm_build_args {
     uint64_t mem_size;           /* Memory size in bytes. */
     uint64_t mem_target;         /* Memory target in bytes. */
+    uint64_t mmio_size;          /* Size of the MMIO hole in bytes. */
     const char *image_file_name; /* File name of the image to load. */
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kzr-0006gB-Nz; Wed, 29 Feb 2012 14:59: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 1S2kzq-0006fe-6c
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:59:14 +0000
Received: from [85.158.139.83:9250] by server-11.bemta-5.messagelabs.com id
	0C/EB-05465-14D3E4F4; Wed, 29 Feb 2012 14:59:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330527552!17175574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31822 invoked from network); 29 Feb 2012 14:59:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:59:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:59:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:59:11 +0000
Date: Wed, 29 Feb 2012 15:06:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1330520756321-5524897.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520756321-5524897.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-465885046-1330527975=:23091"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-465885046-1330527975=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 29 Feb 2012, Fantu wrote:
> Fantu wrote
> > 
> > 
> > Ian Campbell-10 wrote
> >> 
> >> That should be possible, but you haven't shown your code so I can't say
> >> where you have gone wrong.
> >> 
> >> What I often do is create qemu-debug.sh:
> >> 	#!/bin/sh
> >> 	echo "Starting QEMU with: $*" >> /tmp/qemu-dbg.log
> >> 	exec /usr/lib/xen/bin/qemu-system-i386 $@
> >> 
> >> And then using device_model_override to call this instead of calling
> >> qemu directly.
> >> 
> > 
> > Thanks for reply
> > 
> > Qxl graphic is needed for many things with spice, I start to try add it
> > following this: http://spice-space.org/docs/spice_user_manual.pdf
> > 
> > On libxl_dm.c add this line:
> > flexarray_append(dm_args, "-qxl 1");
> > before this:
> > flexarray_append(dm_args, "-spice");
> > 
> > With dm override give:
> > Starting QEMU with: -xen-domid 22 -chardev
> > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-22,server,nowait -mon
> > chardev=libxl-cmd,mode=control -name PRECISEHVM -vnc 127.0.0.1:0,to=99
> > -qxl 1 -spice
> > port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on -boot
> > order=c -smp 2,maxcpus=3 -device
> > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:6b:81:89 -netdev
> > type=tap,id=net0,ifname=tap22.0,script=no -M xenfv -m 1024 -drive
> > file=/mnt/vm/disks/PRECISEHVM.disk1.xm,if=ide,index=0,media=disk,format=raw
> > -drive file=/dev/sr0,if=ide,index=1,media=cdrom,format=raw
> > 
> > And on /var/log/xen/qemu-dm-PRECISEHVM.log:
> > qemu-system-i386: -qxl: invalid option
> > 
> > There isn't other -vga or -nographic options, I not undestand the problem,
> > without qxl work but on spice connect and load see the cirrus video card,
> > video performance is not good and is impossible resize resolution, qxl
> > graphic is needed.
> > I have also try -vga qxl but same problem.
> > 
> > Before i try to add permant dm_args debug on log with:
> > On libxl_dm.c add this line:
> > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "dm_args: ", flexarray_contents(dm_args)
> > );
> > before this:
> > return (char **) flexarray_contents(dm_args);
> > 
> > Show:
> > libxl_dm.c: In function âlibxl__build_device_model_args_newâ:
> > libxl_dm.c:582:2: error: too many arguments for format
> > [-Werror=format-extra-args]
> > cc1: all warnings being treated as errors
> > 
> 
> See only now how -vga qxl try to start but give other error...
> 
> Starting QEMU with: -xen-domid 25 -chardev
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-25,server,nowait -mon
> chardev=libxl-cmd,mode=control -name PRECISEHVM -vga qxl -spice
> port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on -boot order=c
> -smp 2,maxcpus=3 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:38:be:1d
> -netdev type=tap,id=net0,ifname=tap25.0,script=no -M xenfv -m 1024 -drive
> file=/mnt/vm/disks/PRECISEHVM.disk1.xm,if=ide,index=0,media=disk,format=raw
> -drive file=/dev/sr0,if=ide,index=1,media=cdrom,format=raw
> 
> do_spice_init: starting 0.10.1
> spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> spice_server_add_interface: SPICE_INTERFACE_MOUSE
> qemu: hardware error: xen: failed to populate ram at 40000000
> 
> The full log: 
> http://xen.1045712.n5.nabble.com/file/n5524897/qemu-dm-PRECISEHVM.log
> qemu-dm-PRECISEHVM.log 

Try adding videoram=32 to the VM config file, I think the issue is that
the default videoram size for QXL is much larger (32MB) than the default
videoram size for Cirrus (8MB).

--8323329-465885046-1330527975=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-465885046-1330527975=:23091--


From xen-devel-bounces@lists.xen.org Wed Feb 29 14:59:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 14:59:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2kzr-0006gB-Nz; Wed, 29 Feb 2012 14:59: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 1S2kzq-0006fe-6c
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 14:59:14 +0000
Received: from [85.158.139.83:9250] by server-11.bemta-5.messagelabs.com id
	0C/EB-05465-14D3E4F4; Wed, 29 Feb 2012 14:59:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330527552!17175574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31822 invoked from network); 29 Feb 2012 14:59:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 14:59:13 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 14:59:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 14:59:11 +0000
Date: Wed, 29 Feb 2012 15:06:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Fantu <fantonifabio@tiscali.it>
In-Reply-To: <1330520756321-5524897.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520756321-5524897.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-465885046-1330527975=:23091"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--8323329-465885046-1330527975=:23091
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 29 Feb 2012, Fantu wrote:
> Fantu wrote
> > 
> > 
> > Ian Campbell-10 wrote
> >> 
> >> That should be possible, but you haven't shown your code so I can't say
> >> where you have gone wrong.
> >> 
> >> What I often do is create qemu-debug.sh:
> >> 	#!/bin/sh
> >> 	echo "Starting QEMU with: $*" >> /tmp/qemu-dbg.log
> >> 	exec /usr/lib/xen/bin/qemu-system-i386 $@
> >> 
> >> And then using device_model_override to call this instead of calling
> >> qemu directly.
> >> 
> > 
> > Thanks for reply
> > 
> > Qxl graphic is needed for many things with spice, I start to try add it
> > following this: http://spice-space.org/docs/spice_user_manual.pdf
> > 
> > On libxl_dm.c add this line:
> > flexarray_append(dm_args, "-qxl 1");
> > before this:
> > flexarray_append(dm_args, "-spice");
> > 
> > With dm override give:
> > Starting QEMU with: -xen-domid 22 -chardev
> > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-22,server,nowait -mon
> > chardev=libxl-cmd,mode=control -name PRECISEHVM -vnc 127.0.0.1:0,to=99
> > -qxl 1 -spice
> > port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on -boot
> > order=c -smp 2,maxcpus=3 -device
> > rtl8139,id=nic0,netdev=net0,mac=00:16:3e:6b:81:89 -netdev
> > type=tap,id=net0,ifname=tap22.0,script=no -M xenfv -m 1024 -drive
> > file=/mnt/vm/disks/PRECISEHVM.disk1.xm,if=ide,index=0,media=disk,format=raw
> > -drive file=/dev/sr0,if=ide,index=1,media=cdrom,format=raw
> > 
> > And on /var/log/xen/qemu-dm-PRECISEHVM.log:
> > qemu-system-i386: -qxl: invalid option
> > 
> > There isn't other -vga or -nographic options, I not undestand the problem,
> > without qxl work but on spice connect and load see the cirrus video card,
> > video performance is not good and is impossible resize resolution, qxl
> > graphic is needed.
> > I have also try -vga qxl but same problem.
> > 
> > Before i try to add permant dm_args debug on log with:
> > On libxl_dm.c add this line:
> > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "dm_args: ", flexarray_contents(dm_args)
> > );
> > before this:
> > return (char **) flexarray_contents(dm_args);
> > 
> > Show:
> > libxl_dm.c: In function âlibxl__build_device_model_args_newâ:
> > libxl_dm.c:582:2: error: too many arguments for format
> > [-Werror=format-extra-args]
> > cc1: all warnings being treated as errors
> > 
> 
> See only now how -vga qxl try to start but give other error...
> 
> Starting QEMU with: -xen-domid 25 -chardev
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-25,server,nowait -mon
> chardev=libxl-cmd,mode=control -name PRECISEHVM -vga qxl -spice
> port=6000,tls-port=0,addr=0.0.0.0,password=test,agent-mouse=on -boot order=c
> -smp 2,maxcpus=3 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:38:be:1d
> -netdev type=tap,id=net0,ifname=tap25.0,script=no -M xenfv -m 1024 -drive
> file=/mnt/vm/disks/PRECISEHVM.disk1.xm,if=ide,index=0,media=disk,format=raw
> -drive file=/dev/sr0,if=ide,index=1,media=cdrom,format=raw
> 
> do_spice_init: starting 0.10.1
> spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> spice_server_add_interface: SPICE_INTERFACE_MOUSE
> qemu: hardware error: xen: failed to populate ram at 40000000
> 
> The full log: 
> http://xen.1045712.n5.nabble.com/file/n5524897/qemu-dm-PRECISEHVM.log
> qemu-dm-PRECISEHVM.log 

Try adding videoram=32 to the VM config file, I think the issue is that
the default videoram size for QXL is much larger (32MB) than the default
videoram size for Cirrus (8MB).

--8323329-465885046-1330527975=:23091
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-465885046-1330527975=:23091--


From xen-devel-bounces@lists.xen.org Wed Feb 29 15:00:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 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 1S2l16-00072V-1e; Wed, 29 Feb 2012 15:00:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2l15-00071J-A8
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:00:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330527621!8118288!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32719 invoked from network); 29 Feb 2012 15:00:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 15:00:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 15:00:21 +0000
Message-Id: <4F4E4BBC0200007800075788@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 15:01:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>, "Keir Fraser" <keir@xen.org>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
	<20302.4013.955941.793577@mariner.uk.xensource.com>
In-Reply-To: <20302.4013.955941.793577@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.02.12 at 12:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure 
> variables to hypervisor build"):
>> Perhaps we should just move the configure stuff up to the top level and
>> agree that it can control both tools and hypervisor configuration
>> options? I'm not sure why we would want to use different mechanisms for
>> the tools and h/v anyway.
> 
> I assume that the concern was that some people might object to the
> involvement of autoconf in building the hypervisor.  But no-one seems
> to be objecting very much.
> 
> If they do then the right thing is for configure to automatically
> honour settings like FLASK_ENABLE, not to have two separate options
> which cause the build to fail unless you set or clear both.

Yes, please. (I realize that Keir applied the patch here already, but
I really consider it wrong to require a configure step before building
Xen, unless the configure step is exhaustive, i.e. covers everything
that can be controlled, and interactive, like for the Linux kernel. Nor
do I understand what stuff like {PRE,AP}PEND_{INCLUDES,LIB} is
needed for in config/Xen.mk. And finally, with .config being included
[almost] first thing in Config.mk, overriding its settings [like debug] in
config/Xen.mk seems wrong to me too. Or did I miss an announcement
of .config no longer being supported, in which I'd need a hint how to
replace certain settings I've been doing there so far? All in all, Keir,
you may read this as a request to revert that patch.)

And then again, shouldn't tools and hypervisor _build_ be
independent of one another, in that the set of options enabled in
one would still allow it to work with a different set of options
enabled in the other? Or if not, how is the option sets being in
sync getting enforced (i.e. if mismatched builds from the same c/s
got run by someone)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:00:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 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 1S2l16-00072V-1e; Wed, 29 Feb 2012 15:00:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2l15-00071J-A8
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:00:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330527621!8118288!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32719 invoked from network); 29 Feb 2012 15:00:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 15:00:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 15:00:21 +0000
Message-Id: <4F4E4BBC0200007800075788@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 15:01:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>, "Keir Fraser" <keir@xen.org>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
	<20302.4013.955941.793577@mariner.uk.xensource.com>
In-Reply-To: <20302.4013.955941.793577@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.02.12 at 12:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure 
> variables to hypervisor build"):
>> Perhaps we should just move the configure stuff up to the top level and
>> agree that it can control both tools and hypervisor configuration
>> options? I'm not sure why we would want to use different mechanisms for
>> the tools and h/v anyway.
> 
> I assume that the concern was that some people might object to the
> involvement of autoconf in building the hypervisor.  But no-one seems
> to be objecting very much.
> 
> If they do then the right thing is for configure to automatically
> honour settings like FLASK_ENABLE, not to have two separate options
> which cause the build to fail unless you set or clear both.

Yes, please. (I realize that Keir applied the patch here already, but
I really consider it wrong to require a configure step before building
Xen, unless the configure step is exhaustive, i.e. covers everything
that can be controlled, and interactive, like for the Linux kernel. Nor
do I understand what stuff like {PRE,AP}PEND_{INCLUDES,LIB} is
needed for in config/Xen.mk. And finally, with .config being included
[almost] first thing in Config.mk, overriding its settings [like debug] in
config/Xen.mk seems wrong to me too. Or did I miss an announcement
of .config no longer being supported, in which I'd need a hint how to
replace certain settings I've been doing there so far? All in all, Keir,
you may read this as a request to revert that patch.)

And then again, shouldn't tools and hypervisor _build_ be
independent of one another, in that the set of options enabled in
one would still allow it to work with a different set of options
enabled in the other? Or if not, how is the option sets being in
sync getting enforced (i.e. if mismatched builds from the same c/s
got run by someone)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:01:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l1Z-00078y-EZ; Wed, 29 Feb 2012 15:01:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2l1Y-00077c-BQ
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330527654!16121599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19708 invoked from network); 29 Feb 2012 15:00:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 15:00:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 15:00:54 +0000
Message-ID: <1330527652.4270.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 15:00:52 +0000
In-Reply-To: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDE0OjUxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yOSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEkgX3RoaW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRo
ZSBnZW5lcmF0ZWQgZmlsZXMuIEEKPiA+IG1vcmUgY29tcGxldGUgZml4IG1pZ2h0IGFsc28gYWxs
b3cgdGhlIHVzZXIgdG8gZm9yY2UgcmVnZW5lcmF0aW9uIGJ1dCBJIGRpZG4ndAo+ID4gYm90aCBo
ZXJlLgo+ID4KPiA+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+Cj4gPiAtLS0KPiA+ICB0b29scy9jb25maWd1cmUgICAgfCAgNTU5ICsrKysrKysr
KysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICB0b29scy9j
b25maWd1cmUuYWMgfCAgICAxIC0KPiAKPiBZb3UgZm9yZ2V0IHRvIHJlbW92ZToKPiAKPiBBQ19B
UkdfVkFSKFtCSVNPTl0sIFtQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQo+IAo+IGZy
b20gdG9vbHMvY29uZmlndXJlLmFjIGFuZCBhbHNvIGNsZWFuIHJlbGF0ZWQgdmFyaWFibGVzIGZy
b20KPiBjb25maWcvVG9vbHMubWsuaW4uCgpXaWxsIGRvLCB0aGFua3MuCgo+ICBJZiB5b3UgY2Fu
LCBjb3VsZCB5b3UgdXNlIGF1dG9jb25mIDIuNjggKHByZXNlbnQKPiBpbiBEZWJpYW4gc3RhYmxl
KSB0byBnZW5lcmF0ZSB0aGUgbmV3IGNvbmZpZ3VyZSBzY3JpcHQ/CgpJIGhhdmUgMi42Ny0yIGZy
b20gc3RhYmxlLiBJIHRoaW5rIHRoZSAyLjY4IGNhbWUgZnJvbQoyNDk0MDpiZTlkNTZmYWRhODYu
CgpJcyB0aGVyZSBhIHdheSB0byBtYWtlIGNvbmZpZ3VyZS5hYyByZXF1aXJlIGEgY2VydGFpbiB2
ZXJzaW9uIG9mCmF1dG9jb25mIHNvIHdlIGNhbiBiZSBzdXJlIHRoZXNlIHNvcnRzIG9mIGNoYW5n
ZXMgYXJlIGV4cGxpY2l0PwoKPiAgU28gd2UgZG9uJ3QKPiBoYXZlIHRvIHB1c2ggc28gbWFueSB1
bnJlbGF0ZWQgY2hhbmdlcyB0byBjb25maWd1cmUgc2NyaXB0IGFuZAo+IGRvd25ncmF0ZSBpdHMg
dmVyc2lvbj8KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:01:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l1Z-00078y-EZ; Wed, 29 Feb 2012 15:01:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2l1Y-00077c-BQ
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1330527654!16121599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19708 invoked from network); 29 Feb 2012 15:00:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 15:00:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 15:00:54 +0000
Message-ID: <1330527652.4270.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 15:00:52 +0000
In-Reply-To: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDE0OjUxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yOSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEkgX3RoaW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRo
ZSBnZW5lcmF0ZWQgZmlsZXMuIEEKPiA+IG1vcmUgY29tcGxldGUgZml4IG1pZ2h0IGFsc28gYWxs
b3cgdGhlIHVzZXIgdG8gZm9yY2UgcmVnZW5lcmF0aW9uIGJ1dCBJIGRpZG4ndAo+ID4gYm90aCBo
ZXJlLgo+ID4KPiA+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+Cj4gPiAtLS0KPiA+ICB0b29scy9jb25maWd1cmUgICAgfCAgNTU5ICsrKysrKysr
KysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICB0b29scy9j
b25maWd1cmUuYWMgfCAgICAxIC0KPiAKPiBZb3UgZm9yZ2V0IHRvIHJlbW92ZToKPiAKPiBBQ19B
UkdfVkFSKFtCSVNPTl0sIFtQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQo+IAo+IGZy
b20gdG9vbHMvY29uZmlndXJlLmFjIGFuZCBhbHNvIGNsZWFuIHJlbGF0ZWQgdmFyaWFibGVzIGZy
b20KPiBjb25maWcvVG9vbHMubWsuaW4uCgpXaWxsIGRvLCB0aGFua3MuCgo+ICBJZiB5b3UgY2Fu
LCBjb3VsZCB5b3UgdXNlIGF1dG9jb25mIDIuNjggKHByZXNlbnQKPiBpbiBEZWJpYW4gc3RhYmxl
KSB0byBnZW5lcmF0ZSB0aGUgbmV3IGNvbmZpZ3VyZSBzY3JpcHQ/CgpJIGhhdmUgMi42Ny0yIGZy
b20gc3RhYmxlLiBJIHRoaW5rIHRoZSAyLjY4IGNhbWUgZnJvbQoyNDk0MDpiZTlkNTZmYWRhODYu
CgpJcyB0aGVyZSBhIHdheSB0byBtYWtlIGNvbmZpZ3VyZS5hYyByZXF1aXJlIGEgY2VydGFpbiB2
ZXJzaW9uIG9mCmF1dG9jb25mIHNvIHdlIGNhbiBiZSBzdXJlIHRoZXNlIHNvcnRzIG9mIGNoYW5n
ZXMgYXJlIGV4cGxpY2l0PwoKPiAgU28gd2UgZG9uJ3QKPiBoYXZlIHRvIHB1c2ggc28gbWFueSB1
bnJlbGF0ZWQgY2hhbmdlcyB0byBjb25maWd1cmUgc2NyaXB0IGFuZAo+IGRvd25ncmF0ZSBpdHMg
dmVyc2lvbj8KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:02:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l2W-0007Mr-23; Wed, 29 Feb 2012 15:02:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2l2U-0007Lc-2c
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:01:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330527711!17032136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9930 invoked from network); 29 Feb 2012 15:01:52 -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;
	29 Feb 2012 15:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 15:01:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 15:01:28 +0000
Message-ID: <1330527687.4270.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 15:01:27 +0000
In-Reply-To: <4F4E3C8D.40607@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<4F4E3C8D.40607@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 14:56 +0000, David Vrabel wrote:
> On 29/02/12 14:25, Ian Campbell wrote:
> > 
> > --- a/tools/configure.ac
> > +++ b/tools/configure.ac
> > @@ -64,7 +64,6 @@ AX_SET_FLAGS
> >  AC_ARG_VAR([PYTHON], [Path to the Python parser])
> >  AC_ARG_VAR([PERL], [Path to Perl parser])
> >  AC_ARG_VAR([IP], [Path to ip tool])
> > -AC_ARG_VAR([BISON], [Path to Bison parser generator])
> >  AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
> 
> Similarly, what about flex?  Are flex generated file checked in as well?

I think so, I just happened to have flex already installed...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:02:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:02:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l2W-0007Mr-23; Wed, 29 Feb 2012 15:02:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2l2U-0007Lc-2c
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:01:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1330527711!17032136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9930 invoked from network); 29 Feb 2012 15:01:52 -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;
	29 Feb 2012 15:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="11012800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 15:01:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 15:01:28 +0000
Message-ID: <1330527687.4270.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 29 Feb 2012 15:01:27 +0000
In-Reply-To: <4F4E3C8D.40607@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<4F4E3C8D.40607@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 14:56 +0000, David Vrabel wrote:
> On 29/02/12 14:25, Ian Campbell wrote:
> > 
> > --- a/tools/configure.ac
> > +++ b/tools/configure.ac
> > @@ -64,7 +64,6 @@ AX_SET_FLAGS
> >  AC_ARG_VAR([PYTHON], [Path to the Python parser])
> >  AC_ARG_VAR([PERL], [Path to Perl parser])
> >  AC_ARG_VAR([IP], [Path to ip tool])
> > -AC_ARG_VAR([BISON], [Path to Bison parser generator])
> >  AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator])
> 
> Similarly, what about flex?  Are flex generated file checked in as well?

I think so, I just happened to have flex already installed...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:02:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l3L-0007b2-Kb; Wed, 29 Feb 2012 15:02:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2l3K-0007Zg-0r
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:02:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527753!9832426!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15255 invoked from network); 29 Feb 2012 15:02:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 15:02:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 15:02:32 +0000
Message-Id: <4F4E4C3E020000780007578B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 15:03:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
	<12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
	<DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
	<4F4E3C72.2030101@amd.com>
In-Reply-To: <4F4E3C72.2030101@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gang Wei <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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 29.02.12 at 15:55, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/29/12 00:21, Liu, Jinsong wrote:
>> Hmm, no.
>>
>> It need flush cache, as long as *deep Cx* would be spurious-wokenup.
>> The reason clflush here is, it's a light-weight flush, in fact it also could 
> use wbinvd if not consider performance.
> 
> What address would need to be CFLUSH'd ? Both "address" and 
> "pmtmr_ioport_local"?

Hardly - these are both I/O ports.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:02:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:02:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l3L-0007b2-Kb; Wed, 29 Feb 2012 15:02:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2l3K-0007Zg-0r
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:02:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1330527753!9832426!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15255 invoked from network); 29 Feb 2012 15:02:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 15:02:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 15:02:32 +0000
Message-Id: <4F4E4C3E020000780007578B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 15:03:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <9e5991ad9c85b5176ce2.1330466910@wotan.osrc.amd.com>,
	<A9667DDFB95DB7438FA9D7D576C3D87E080EE9@SHSMSX101.ccr.corp.intel.com>
	<12EBBFBA42012542B30BB4E52B6DCEEB03189495@sausexdag02.amd.com>
	<DE8DF0795D48FD4CA783C40EC82923350BA911@SHSMSX101.ccr.corp.intel.com>
	<4F4E3C72.2030101@amd.com>
In-Reply-To: <4F4E3C72.2030101@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gang Wei <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: Use deep C states for off-lined 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 29.02.12 at 15:55, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 02/29/12 00:21, Liu, Jinsong wrote:
>> Hmm, no.
>>
>> It need flush cache, as long as *deep Cx* would be spurious-wokenup.
>> The reason clflush here is, it's a light-weight flush, in fact it also could 
> use wbinvd if not consider performance.
> 
> What address would need to be CFLUSH'd ? Both "address" and 
> "pmtmr_ioport_local"?

Hardly - these are both I/O ports.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15: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 1S2l6b-00085j-Mp; Wed, 29 Feb 2012 15:06: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 1S2l6Z-00085V-Tj
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:06:12 +0000
Received: from [85.158.139.83:54427] by server-1.bemta-5.messagelabs.com id
	B2/28-28458-3EE3E4F4; Wed, 29 Feb 2012 15:06:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330527970!17259524!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4734 invoked from network); 29 Feb 2012 15:06:10 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-182.messagelabs.com with SMTP;
	29 Feb 2012 15:06:10 -0000
X-TM-IMSS-Message-ID: <17b7be8a0000be5e@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 17b7be8a0000be5e ;
	Wed, 29 Feb 2012 10:08:28 -0500
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 q1TF66NT015160; 
	Wed, 29 Feb 2012 10:06:06 -0500
Message-ID: <4F4E3EE5.4020703@tycho.nsa.gov>
Date: Wed, 29 Feb 2012 10:06:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
	<20302.4013.955941.793577@mariner.uk.xensource.com>
In-Reply-To: <20302.4013.955941.793577@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/29/2012 06:44 AM, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to hypervisor build"):
>> Perhaps we should just move the configure stuff up to the top level and
>> agree that it can control both tools and hypervisor configuration
>> options? I'm not sure why we would want to use different mechanisms for
>> the tools and h/v anyway.
> 
> I assume that the concern was that some people might object to the
> involvement of autoconf in building the hypervisor.  But no-one seems
> to be objecting very much.
> 
> If they do then the right thing is for configure to automatically
> honour settings like FLASK_ENABLE, not to have two separate options
> which cause the build to fail unless you set or clear both.
> 
> Ian.
> 

Actually, FLASK_ENABLE and XSM_ENABLE are not used in the tools build at all -
they are purely hypervisor build options. If a ./configure dependency isn't
wanted for the hypervisor build, reverting the removal of XSM_ENABLE from
Config.mk and eliminating the --enable-xsm option would also work.

-- 
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 Wed Feb 29 15:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15: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 1S2l6b-00085j-Mp; Wed, 29 Feb 2012 15:06: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 1S2l6Z-00085V-Tj
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:06:12 +0000
Received: from [85.158.139.83:54427] by server-1.bemta-5.messagelabs.com id
	B2/28-28458-3EE3E4F4; Wed, 29 Feb 2012 15:06:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1330527970!17259524!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4734 invoked from network); 29 Feb 2012 15:06:10 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-182.messagelabs.com with SMTP;
	29 Feb 2012 15:06:10 -0000
X-TM-IMSS-Message-ID: <17b7be8a0000be5e@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 17b7be8a0000be5e ;
	Wed, 29 Feb 2012 10:08:28 -0500
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 q1TF66NT015160; 
	Wed, 29 Feb 2012 10:06:06 -0500
Message-ID: <4F4E3EE5.4020703@tycho.nsa.gov>
Date: Wed, 29 Feb 2012 10:06:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
	<20302.4013.955941.793577@mariner.uk.xensource.com>
In-Reply-To: <20302.4013.955941.793577@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.5
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/29/2012 06:44 AM, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to hypervisor build"):
>> Perhaps we should just move the configure stuff up to the top level and
>> agree that it can control both tools and hypervisor configuration
>> options? I'm not sure why we would want to use different mechanisms for
>> the tools and h/v anyway.
> 
> I assume that the concern was that some people might object to the
> involvement of autoconf in building the hypervisor.  But no-one seems
> to be objecting very much.
> 
> If they do then the right thing is for configure to automatically
> honour settings like FLASK_ENABLE, not to have two separate options
> which cause the build to fail unless you set or clear both.
> 
> Ian.
> 

Actually, FLASK_ENABLE and XSM_ENABLE are not used in the tools build at all -
they are purely hypervisor build options. If a ./configure dependency isn't
wanted for the hypervisor build, reverting the removal of XSM_ENABLE from
Config.mk and eliminating the --enable-xsm option would also work.

-- 
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 Wed Feb 29 15:09:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l9j-0008Jy-HA; Wed, 29 Feb 2012 15:09:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S2l9h-0008Jj-Ji
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:09:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330528159!11326165!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7650 invoked from network); 29 Feb 2012 15:09:19 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:09:19 -0000
Received: by werp12 with SMTP id p12so3205337wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 07:09:19 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr2127368wib.3.1330528159462 (num_hops
	= 1); Wed, 29 Feb 2012 07:09:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=4MiiyMVXlxkSBOjtMRgzHmG0DulYCluxBwZWAqHP/Cg=;
	b=QqMtxu2PkMCa+CgsV6XwuIySEmyS4ohilcxtalY8OdwPB7JPrl9lzAwy9y+HnEQgiR
	S5tPxTgwM3qQUZpIBFHnOGg/j7V0HKf6gsM5cTa6LAz7gAPe9PuoamFHhVabvMHtUbsb
	e4MXSM58gWlF/wzvVwJHuteMrELmHS7/6KaNs=
Received: by 10.180.100.33 with SMTP id ev1mr1714166wib.3.1330528159316;
	Wed, 29 Feb 2012 07:09:19 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71]) by mx.google.com with ESMTPS id
	fq10sm11076628wib.11.2012.02.29.07.09.16
	(version=SSLv3 cipher=OTHER); Wed, 29 Feb 2012 07:09:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 29 Feb 2012 15:09:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CB73F01B.2C8DB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/5] build: Export configure variables to
	hypervisor build
Thread-Index: Acz29Bmr98NKOcc2n0+sutUIePKNxQ==
In-Reply-To: <4F4E3EE5.4020703@tycho.nsa.gov>
Mime-version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/02/2012 15:06, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> On 02/29/2012 06:44 AM, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure
>> variables to hypervisor build"):
>>> Perhaps we should just move the configure stuff up to the top level and
>>> agree that it can control both tools and hypervisor configuration
>>> options? I'm not sure why we would want to use different mechanisms for
>>> the tools and h/v anyway.
>> 
>> I assume that the concern was that some people might object to the
>> involvement of autoconf in building the hypervisor.  But no-one seems
>> to be objecting very much.
>> 
>> If they do then the right thing is for configure to automatically
>> honour settings like FLASK_ENABLE, not to have two separate options
>> which cause the build to fail unless you set or clear both.
>> 
>> Ian.
>> 
> 
> Actually, FLASK_ENABLE and XSM_ENABLE are not used in the tools build at all -
> they are purely hypervisor build options. If a ./configure dependency isn't
> wanted for the hypervisor build, reverting the removal of XSM_ENABLE from
> Config.mk and eliminating the --enable-xsm option would also work.

I'll revert the patch I just applied. Do you want to make another patch for
this alternative solution?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:09:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2l9j-0008Jy-HA; Wed, 29 Feb 2012 15:09:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1S2l9h-0008Jj-Ji
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:09:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330528159!11326165!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7650 invoked from network); 29 Feb 2012 15:09:19 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:09:19 -0000
Received: by werp12 with SMTP id p12so3205337wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 07:09:19 -0800 (PST)
Received-SPF: pass (google.com: domain of keir.xen@gmail.com designates
	10.180.100.33 as permitted sender) client-ip=10.180.100.33; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of keir.xen@gmail.com
	designates 10.180.100.33 as permitted sender)
	smtp.mail=keir.xen@gmail.com;
	dkim=pass header.i=keir.xen@gmail.com
Received: from mr.google.com ([10.180.100.33])
	by 10.180.100.33 with SMTP id ev1mr2127368wib.3.1330528159462 (num_hops
	= 1); Wed, 29 Feb 2012 07:09:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=4MiiyMVXlxkSBOjtMRgzHmG0DulYCluxBwZWAqHP/Cg=;
	b=QqMtxu2PkMCa+CgsV6XwuIySEmyS4ohilcxtalY8OdwPB7JPrl9lzAwy9y+HnEQgiR
	S5tPxTgwM3qQUZpIBFHnOGg/j7V0HKf6gsM5cTa6LAz7gAPe9PuoamFHhVabvMHtUbsb
	e4MXSM58gWlF/wzvVwJHuteMrELmHS7/6KaNs=
Received: by 10.180.100.33 with SMTP id ev1mr1714166wib.3.1330528159316;
	Wed, 29 Feb 2012 07:09:19 -0800 (PST)
Received: from [192.168.1.84] (host86-154-65-71.range86-154.btcentralplus.com.
	[86.154.65.71]) by mx.google.com with ESMTPS id
	fq10sm11076628wib.11.2012.02.29.07.09.16
	(version=SSLv3 cipher=OTHER); Wed, 29 Feb 2012 07:09:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 29 Feb 2012 15:09:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CB73F01B.2C8DB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/5] build: Export configure variables to
	hypervisor build
Thread-Index: Acz29Bmr98NKOcc2n0+sutUIePKNxQ==
In-Reply-To: <4F4E3EE5.4020703@tycho.nsa.gov>
Mime-version: 1.0
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/02/2012 15:06, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> On 02/29/2012 06:44 AM, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure
>> variables to hypervisor build"):
>>> Perhaps we should just move the configure stuff up to the top level and
>>> agree that it can control both tools and hypervisor configuration
>>> options? I'm not sure why we would want to use different mechanisms for
>>> the tools and h/v anyway.
>> 
>> I assume that the concern was that some people might object to the
>> involvement of autoconf in building the hypervisor.  But no-one seems
>> to be objecting very much.
>> 
>> If they do then the right thing is for configure to automatically
>> honour settings like FLASK_ENABLE, not to have two separate options
>> which cause the build to fail unless you set or clear both.
>> 
>> Ian.
>> 
> 
> Actually, FLASK_ENABLE and XSM_ENABLE are not used in the tools build at all -
> they are purely hypervisor build options. If a ./configure dependency isn't
> wanted for the hypervisor build, reverting the removal of XSM_ENABLE from
> Config.mk and eliminating the --enable-xsm option would also work.

I'll revert the patch I just applied. Do you want to make another patch for
this alternative solution?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15: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 1S2l9u-0008LS-Th; Wed, 29 Feb 2012 15:09:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2l9t-0008KU-F0
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:09:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330528159!11326165!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8380 invoked from network); 29 Feb 2012 15:09:31 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:09:31 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so3205337wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 07:09:31 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.14.230 as permitted sender) client-ip=10.180.14.230; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.14.230 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.14.230])
	by 10.180.14.230 with SMTP id s6mr1776287wic.2.1330528171515 (num_hops
	= 1); Wed, 29 Feb 2012 07:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=DZuhKebR+Zwyim00LNLGOZ9LdDTHMSvjj+bLElGitCM=;
	b=mePb0M1TGWUUOLRrMxm7t+UpW5SPts+piKFAI1Ugu9hcTclMK/pYs0t2GXkph9nppc
	qoJgoMrCRpLhmzwrHHL51iWeS1LAvT+ATYMxGyeDLv3hRa7Fvujf/yxAS72nmU3go3PG
	JN1AKMIOyNB2t8p512SoRr02G1zNeemy1cq5k=
MIME-Version: 1.0
Received: by 10.180.14.230 with SMTP id s6mr1430903wic.2.1330528171479; Wed,
	29 Feb 2012 07:09:31 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 07:09:31 -0800 (PST)
In-Reply-To: <1330527652.4270.130.camel@zakaz.uk.xensource.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
	<1330527652.4270.130.camel@zakaz.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:09:31 +0100
X-Google-Sender-Auth: yJflXjRPNozKPUP7jKG0jpzRyvg
Message-ID: <CAPLaKK7oSQPHq4Gx2J0xCD42qMxmPp--0CBwi3ptWC+_VpkRyw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI5IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMi0yOSBhdCAxNDo1MSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8yLzI5IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IEkg
X3RoaW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRoZSBn
ZW5lcmF0ZWQgZmlsZXMuIEEKPj4gPiBtb3JlIGNvbXBsZXRlIGZpeCBtaWdodCBhbHNvIGFsbG93
IHRoZSB1c2VyIHRvIGZvcmNlIHJlZ2VuZXJhdGlvbiBidXQgSSBkaWRuJ3QKPj4gPiBib3RoIGhl
cmUuCj4+ID4KPj4gPiBTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPgo+PiA+IC0tLQo+PiA+IMKgdG9vbHMvY29uZmlndXJlIMKgIMKgfCDCoDU1OSAr
KysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+ID4g
wqB0b29scy9jb25maWd1cmUuYWMgfCDCoCDCoDEgLQo+Pgo+PiBZb3UgZm9yZ2V0IHRvIHJlbW92
ZToKPj4KPj4gQUNfQVJHX1ZBUihbQklTT05dLCBbUGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJh
dG9yXSkKPj4KPj4gZnJvbSB0b29scy9jb25maWd1cmUuYWMgYW5kIGFsc28gY2xlYW4gcmVsYXRl
ZCB2YXJpYWJsZXMgZnJvbQo+PiBjb25maWcvVG9vbHMubWsuaW4uCj4KPiBXaWxsIGRvLCB0aGFu
a3MuCj4KPj4gwqBJZiB5b3UgY2FuLCBjb3VsZCB5b3UgdXNlIGF1dG9jb25mIDIuNjggKHByZXNl
bnQKPj4gaW4gRGViaWFuIHN0YWJsZSkgdG8gZ2VuZXJhdGUgdGhlIG5ldyBjb25maWd1cmUgc2Ny
aXB0Pwo+Cj4gSSBoYXZlIDIuNjctMiBmcm9tIHN0YWJsZS4gSSB0aGluayB0aGUgMi42OCBjYW1l
IGZyb20KPiAyNDk0MDpiZTlkNTZmYWRhODYuCj4KPiBJcyB0aGVyZSBhIHdheSB0byBtYWtlIGNv
bmZpZ3VyZS5hYyByZXF1aXJlIGEgY2VydGFpbiB2ZXJzaW9uIG9mCj4gYXV0b2NvbmYgc28gd2Ug
Y2FuIGJlIHN1cmUgdGhlc2Ugc29ydHMgb2YgY2hhbmdlcyBhcmUgZXhwbGljaXQ/CgpBQ19QUkVS
RVEoWzIuNjddKSBzaG91bGQgcHJvYmFibHkgYmUgc2V0IHRvIDIuNjggaWYgdGhhdCdzIG9rIHdp
dGgKZXZlcnlvbmUuIEkgd291bGQgcHJlZmVyIHRvIHVzZSBhIHZlcnNpb24gYXMgbmV3IGFzIHBv
c2libGUsIHRvIGF2b2lkCmhpdHRpbmcgYXV0Y29uZiBidWdzLgoKPj4gwqBTbyB3ZSBkb24ndAo+
PiBoYXZlIHRvIHB1c2ggc28gbWFueSB1bnJlbGF0ZWQgY2hhbmdlcyB0byBjb25maWd1cmUgc2Ny
aXB0IGFuZAo+PiBkb3duZ3JhdGUgaXRzIHZlcnNpb24/Cj4KPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15: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 1S2l9u-0008LS-Th; Wed, 29 Feb 2012 15:09:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1S2l9t-0008KU-F0
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:09:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330528159!11326165!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8380 invoked from network); 29 Feb 2012 15:09:31 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:09:31 -0000
Received: by mail-we0-f173.google.com with SMTP id p12so3205337wer.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 07:09:31 -0800 (PST)
Received-SPF: pass (google.com: domain of royger@gmail.com designates
	10.180.14.230 as permitted sender) client-ip=10.180.14.230; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of royger@gmail.com
	designates 10.180.14.230 as permitted sender)
	smtp.mail=royger@gmail.com; dkim=pass header.i=royger@gmail.com
Received: from mr.google.com ([10.180.14.230])
	by 10.180.14.230 with SMTP id s6mr1776287wic.2.1330528171515 (num_hops
	= 1); Wed, 29 Feb 2012 07:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=DZuhKebR+Zwyim00LNLGOZ9LdDTHMSvjj+bLElGitCM=;
	b=mePb0M1TGWUUOLRrMxm7t+UpW5SPts+piKFAI1Ugu9hcTclMK/pYs0t2GXkph9nppc
	qoJgoMrCRpLhmzwrHHL51iWeS1LAvT+ATYMxGyeDLv3hRa7Fvujf/yxAS72nmU3go3PG
	JN1AKMIOyNB2t8p512SoRr02G1zNeemy1cq5k=
MIME-Version: 1.0
Received: by 10.180.14.230 with SMTP id s6mr1430903wic.2.1330528171479; Wed,
	29 Feb 2012 07:09:31 -0800 (PST)
Received: by 10.216.1.9 with HTTP; Wed, 29 Feb 2012 07:09:31 -0800 (PST)
In-Reply-To: <1330527652.4270.130.camel@zakaz.uk.xensource.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
	<1330527652.4270.130.camel@zakaz.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:09:31 +0100
X-Google-Sender-Auth: yJflXjRPNozKPUP7jKG0jpzRyvg
Message-ID: <CAPLaKK7oSQPHq4Gx2J0xCD42qMxmPp--0CBwi3ptWC+_VpkRyw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

MjAxMi8yLzI5IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMi0yOSBhdCAxNDo1MSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8yLzI5IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IEkg
X3RoaW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRoZSBn
ZW5lcmF0ZWQgZmlsZXMuIEEKPj4gPiBtb3JlIGNvbXBsZXRlIGZpeCBtaWdodCBhbHNvIGFsbG93
IHRoZSB1c2VyIHRvIGZvcmNlIHJlZ2VuZXJhdGlvbiBidXQgSSBkaWRuJ3QKPj4gPiBib3RoIGhl
cmUuCj4+ID4KPj4gPiBTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPgo+PiA+IC0tLQo+PiA+IMKgdG9vbHMvY29uZmlndXJlIMKgIMKgfCDCoDU1OSAr
KysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+ID4g
wqB0b29scy9jb25maWd1cmUuYWMgfCDCoCDCoDEgLQo+Pgo+PiBZb3UgZm9yZ2V0IHRvIHJlbW92
ZToKPj4KPj4gQUNfQVJHX1ZBUihbQklTT05dLCBbUGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJh
dG9yXSkKPj4KPj4gZnJvbSB0b29scy9jb25maWd1cmUuYWMgYW5kIGFsc28gY2xlYW4gcmVsYXRl
ZCB2YXJpYWJsZXMgZnJvbQo+PiBjb25maWcvVG9vbHMubWsuaW4uCj4KPiBXaWxsIGRvLCB0aGFu
a3MuCj4KPj4gwqBJZiB5b3UgY2FuLCBjb3VsZCB5b3UgdXNlIGF1dG9jb25mIDIuNjggKHByZXNl
bnQKPj4gaW4gRGViaWFuIHN0YWJsZSkgdG8gZ2VuZXJhdGUgdGhlIG5ldyBjb25maWd1cmUgc2Ny
aXB0Pwo+Cj4gSSBoYXZlIDIuNjctMiBmcm9tIHN0YWJsZS4gSSB0aGluayB0aGUgMi42OCBjYW1l
IGZyb20KPiAyNDk0MDpiZTlkNTZmYWRhODYuCj4KPiBJcyB0aGVyZSBhIHdheSB0byBtYWtlIGNv
bmZpZ3VyZS5hYyByZXF1aXJlIGEgY2VydGFpbiB2ZXJzaW9uIG9mCj4gYXV0b2NvbmYgc28gd2Ug
Y2FuIGJlIHN1cmUgdGhlc2Ugc29ydHMgb2YgY2hhbmdlcyBhcmUgZXhwbGljaXQ/CgpBQ19QUkVS
RVEoWzIuNjddKSBzaG91bGQgcHJvYmFibHkgYmUgc2V0IHRvIDIuNjggaWYgdGhhdCdzIG9rIHdp
dGgKZXZlcnlvbmUuIEkgd291bGQgcHJlZmVyIHRvIHVzZSBhIHZlcnNpb24gYXMgbmV3IGFzIHBv
c2libGUsIHRvIGF2b2lkCmhpdHRpbmcgYXV0Y29uZiBidWdzLgoKPj4gwqBTbyB3ZSBkb24ndAo+
PiBoYXZlIHRvIHB1c2ggc28gbWFueSB1bnJlbGF0ZWQgY2hhbmdlcyB0byBjb25maWd1cmUgc2Ny
aXB0IGFuZAo+PiBkb3duZ3JhdGUgaXRzIHZlcnNpb24/Cj4KPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:11:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lBS-0008Ue-D4; Wed, 29 Feb 2012 15:11:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2lBQ-0008Tt-SS
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:11:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330528264!15487638!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14170 invoked from network); 29 Feb 2012 15:11:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 15:11:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 15:11:03 +0000
Message-Id: <4F4E4E3F02000078000757CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 15:11:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>, "Keir Fraser" <keir@xen.org>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
	<20302.4013.955941.793577@mariner.uk.xensource.com>
	<4F4E4BBC0200007800075788@nat28.tlf.novell.com>
In-Reply-To: <4F4E4BBC0200007800075788@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.02.12 at 16:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> Yes, please. (I realize that Keir applied the patch here already, but
> I really consider it wrong to require a configure step before building
> Xen, unless the configure step is exhaustive, i.e. covers everything
> that can be controlled, and interactive, like for the Linux kernel. Nor

Even more so for cross builds: On a 32-bit host, there is no point in
building 64-bit tools, yet building a 64-bit hypervisor is rather useful.
So the current situation iiuc would make it necessary that I run a
tools side configure first, and only then the hypervisor build.

Jan

> do I understand what stuff like {PRE,AP}PEND_{INCLUDES,LIB} is
> needed for in config/Xen.mk. And finally, with .config being included
> [almost] first thing in Config.mk, overriding its settings [like debug] in
> config/Xen.mk seems wrong to me too. Or did I miss an announcement
> of .config no longer being supported, in which I'd need a hint how to
> replace certain settings I've been doing there so far? All in all, Keir,
> you may read this as a request to revert that patch.)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:11:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:11:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lBS-0008Ue-D4; Wed, 29 Feb 2012 15:11:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1S2lBQ-0008Tt-SS
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:11:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330528264!15487638!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MjU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14170 invoked from network); 29 Feb 2012 15:11:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 15:11:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 29 Feb 2012 15:11:03 +0000
Message-Id: <4F4E4E3F02000078000757CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 29 Feb 2012 15:11:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>, "Keir Fraser" <keir@xen.org>
References: <1330471637-8104-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1330513251.4270.47.camel@zakaz.uk.xensource.com>
	<20302.4013.955941.793577@mariner.uk.xensource.com>
	<4F4E4BBC0200007800075788@nat28.tlf.novell.com>
In-Reply-To: <4F4E4BBC0200007800075788@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/5] build: Export configure variables to
 hypervisor build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.02.12 at 16:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> Yes, please. (I realize that Keir applied the patch here already, but
> I really consider it wrong to require a configure step before building
> Xen, unless the configure step is exhaustive, i.e. covers everything
> that can be controlled, and interactive, like for the Linux kernel. Nor

Even more so for cross builds: On a 32-bit host, there is no point in
building 64-bit tools, yet building a 64-bit hypervisor is rather useful.
So the current situation iiuc would make it necessary that I run a
tools side configure first, and only then the hypervisor build.

Jan

> do I understand what stuff like {PRE,AP}PEND_{INCLUDES,LIB} is
> needed for in config/Xen.mk. And finally, with .config being included
> [almost] first thing in Config.mk, overriding its settings [like debug] in
> config/Xen.mk seems wrong to me too. Or did I miss an announcement
> of .config no longer being supported, in which I'd need a hint how to
> replace certain settings I've been doing there so far? All in all, Keir,
> you may read this as a request to revert that patch.)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:30:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lUL-0000wZ-Ki; Wed, 29 Feb 2012 15:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lUK-0000w2-F1
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:30:44 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330529437!18848744!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6356 invoked from network); 29 Feb 2012 15:30:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 15:30:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lUC-0003lq-Tz
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 07:30:36 -0800
Date: Wed, 29 Feb 2012 07:30:36 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330529436918-5525248.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520756321-5524897.post@n5.nabble.com>
	<alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Stefano Stabellini-3 wrote
> 
> Try adding videoram=32 to the VM config file, I think the issue is that
> the default videoram size for QXL is much larger (32MB) than the default
> videoram size for Cirrus (8MB).
> 

Already thought and tried, -videoram invalid option, is also missed in
--help of qemu-system-i386

--
View this message in context: http://xen.1045712.n5.nabble.com/Need-help-with-qemu-args-debug-tp5524689p5525248.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:30:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lUL-0000wZ-Ki; Wed, 29 Feb 2012 15:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lUK-0000w2-F1
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:30:44 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330529437!18848744!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6356 invoked from network); 29 Feb 2012 15:30:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 15:30:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lUC-0003lq-Tz
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 07:30:36 -0800
Date: Wed, 29 Feb 2012 07:30:36 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330529436918-5525248.post@n5.nabble.com>
In-Reply-To: <alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520756321-5524897.post@n5.nabble.com>
	<alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Stefano Stabellini-3 wrote
> 
> Try adding videoram=32 to the VM config file, I think the issue is that
> the default videoram size for QXL is much larger (32MB) than the default
> videoram size for Cirrus (8MB).
> 

Already thought and tried, -videoram invalid option, is also missed in
--help of qemu-system-i386

--
View this message in context: http://xen.1045712.n5.nabble.com/Need-help-with-qemu-args-debug-tp5524689p5525248.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:35:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lYv-0001E0-AO; Wed, 29 Feb 2012 15:35:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1S2lYt-0001Dm-CD
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:35:27 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330529719!13631085!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2019 invoked from network); 29 Feb 2012 15:35:20 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 15:35:20 -0000
X-TM-IMSS-Message-ID: <17ff35cd0000dddc@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 17ff35cd0000dddc ;
	Wed, 29 Feb 2012 10:47:12 -0500
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 q1TFZFsJ017088; 
	Wed, 29 Feb 2012 10:35:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: keir@xen.org
Date: Wed, 29 Feb 2012 10:35:20 -0500
Message-Id: <1330529720-17126-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <CB73F01B.2C8DB%keir.xen@gmail.com>
References: <CB73F01B.2C8DB%keir.xen@gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Roger Pau Monne <roger.pau@entel.upc.edu>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] build: remove hypervisor-only configuration
	from tools/configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 adding autoconf support, the configuration options for XSM and
FLASK_ENABLE were incorrectly removed from Config.mk and added to the
tools configuration. Since these are hypervisor configuration options,
they should not depend on running tools configuration.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 Config.mk          |    4 ++++
 config/Tools.mk.in |    4 ----
 tools/configure.ac |    4 +---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Config.mk b/Config.mk
index bc6be65..97bc9be 100644
--- a/Config.mk
+++ b/Config.mk
@@ -175,6 +175,10 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+# Enable XSM security module (by default, Flask).
+XSM_ENABLE ?= n
+FLASK_ENABLE ?= $(XSM_ENABLE)
+
 XEN_EXTFILES_URL=http://xenbits.xensource.com/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 06d5e89..315ced4 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE          := @xsm@
-FLASK_ENABLE        := @xsm@
-
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure.ac b/tools/configure.ac
index c5dec9c..b8f69e6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -36,8 +36,6 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 
 # Enable/disable options
-AX_ARG_ENABLE_AND_EXPORT([xsm],
-    [Enable XSM security module (by default, Flask)])
 AX_ARG_ENABLE_AND_EXPORT([githttp], [Download GIT repositories via HTTP])
 AX_ARG_DISABLE_AND_EXPORT([monitors],
     [Disable xenstat and xentop monitoring tools])
@@ -47,7 +45,7 @@ AX_ARG_DISABLE_AND_EXPORT([pythontools], [Disable Python tools])
 AX_ARG_DISABLE_AND_EXPORT([ocamltools], [Disable Ocaml tools])
 AX_ARG_ENABLE_AND_EXPORT([miniterm], [Enable miniterm])
 AX_ARG_ENABLE_AND_EXPORT([lomount], [Enable lomount])
-AX_ARG_DISABLE_AND_EXPORT([debug], [Disable debug build of Xen and tools])
+AX_ARG_DISABLE_AND_EXPORT([debug], [Disable debug build of tools])
 
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:35:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lYv-0001E0-AO; Wed, 29 Feb 2012 15:35:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1S2lYt-0001Dm-CD
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:35:27 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1330529719!13631085!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2019 invoked from network); 29 Feb 2012 15:35:20 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 15:35:20 -0000
X-TM-IMSS-Message-ID: <17ff35cd0000dddc@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;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id 17ff35cd0000dddc ;
	Wed, 29 Feb 2012 10:47:12 -0500
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 q1TFZFsJ017088; 
	Wed, 29 Feb 2012 10:35:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: keir@xen.org
Date: Wed, 29 Feb 2012 10:35:20 -0500
Message-Id: <1330529720-17126-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <CB73F01B.2C8DB%keir.xen@gmail.com>
References: <CB73F01B.2C8DB%keir.xen@gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Roger Pau Monne <roger.pau@entel.upc.edu>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] build: remove hypervisor-only configuration
	from tools/configure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 adding autoconf support, the configuration options for XSM and
FLASK_ENABLE were incorrectly removed from Config.mk and added to the
tools configuration. Since these are hypervisor configuration options,
they should not depend on running tools configuration.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 Config.mk          |    4 ++++
 config/Tools.mk.in |    4 ----
 tools/configure.ac |    4 +---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Config.mk b/Config.mk
index bc6be65..97bc9be 100644
--- a/Config.mk
+++ b/Config.mk
@@ -175,6 +175,10 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+# Enable XSM security module (by default, Flask).
+XSM_ENABLE ?= n
+FLASK_ENABLE ?= $(XSM_ENABLE)
+
 XEN_EXTFILES_URL=http://xenbits.xensource.com/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 06d5e89..315ced4 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE          := @xsm@
-FLASK_ENABLE        := @xsm@
-
 # Download GIT repositories via HTTP or GIT's own protocol?
 # GIT's protocol is faster and more robust, when it works at all (firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure.ac b/tools/configure.ac
index c5dec9c..b8f69e6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -36,8 +36,6 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 
 # Enable/disable options
-AX_ARG_ENABLE_AND_EXPORT([xsm],
-    [Enable XSM security module (by default, Flask)])
 AX_ARG_ENABLE_AND_EXPORT([githttp], [Download GIT repositories via HTTP])
 AX_ARG_DISABLE_AND_EXPORT([monitors],
     [Disable xenstat and xentop monitoring tools])
@@ -47,7 +45,7 @@ AX_ARG_DISABLE_AND_EXPORT([pythontools], [Disable Python tools])
 AX_ARG_DISABLE_AND_EXPORT([ocamltools], [Disable Ocaml tools])
 AX_ARG_ENABLE_AND_EXPORT([miniterm], [Enable miniterm])
 AX_ARG_ENABLE_AND_EXPORT([lomount], [Enable lomount])
-AX_ARG_DISABLE_AND_EXPORT([debug], [Disable debug build of Xen and tools])
+AX_ARG_DISABLE_AND_EXPORT([debug], [Disable debug build of tools])
 
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:39:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:39:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lcx-0001S3-0s; Wed, 29 Feb 2012 15:39:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lcw-0001Ry-CE
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:39:38 +0000
Received: from [85.158.139.83:23038] by server-2.bemta-5.messagelabs.com id
	8D/53-20263-9B64E4F4; Wed, 29 Feb 2012 15:39:37 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330529975!13319656!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5245 invoked from network); 29 Feb 2012 15:39:36 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 15:39:36 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lct-0004yc-95
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 07:39:35 -0800
Date: Wed, 29 Feb 2012 07:39:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330529975275-5525276.post@n5.nabble.com>
In-Reply-To: <1330529436918-5525248.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520756321-5524897.post@n5.nabble.com>
	<alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
	<1330529436918-5525248.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Now I search for other options, found and tried with -global
qxl-vga.vram_size=4194304 but same problem...

do_spice_init: starting 0.10.1
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: SPICE_INTERFACE_MOUSE
qemu: hardware error: xen: failed to populate ram at 40000000

--
View this message in context: http://xen.1045712.n5.nabble.com/Need-help-with-qemu-args-debug-tp5524689p5525276.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:39:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:39:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lcx-0001S3-0s; Wed, 29 Feb 2012 15:39:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lcw-0001Ry-CE
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:39:38 +0000
Received: from [85.158.139.83:23038] by server-2.bemta-5.messagelabs.com id
	8D/53-20263-9B64E4F4; Wed, 29 Feb 2012 15:39:37 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330529975!13319656!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5245 invoked from network); 29 Feb 2012 15:39:36 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Feb 2012 15:39:36 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1S2lct-0004yc-95
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 07:39:35 -0800
Date: Wed, 29 Feb 2012 07:39:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1330529975275-5525276.post@n5.nabble.com>
In-Reply-To: <1330529436918-5525248.post@n5.nabble.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520756321-5524897.post@n5.nabble.com>
	<alpine.DEB.2.00.1202291503030.23091@kaball-desktop>
	<1330529436918-5525248.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Now I search for other options, found and tried with -global
qxl-vga.vram_size=4194304 but same problem...

do_spice_init: starting 0.10.1
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: SPICE_INTERFACE_MOUSE
qemu: hardware error: xen: failed to populate ram at 40000000

--
View this message in context: http://xen.1045712.n5.nabble.com/Need-help-with-qemu-args-debug-tp5524689p5525276.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:48:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:48:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lkm-0001vV-Ju; Wed, 29 Feb 2012 15:47:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1S2lkk-0001v6-Ng
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:47:42 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330530455!15506479!1
X-Originating-IP: [209.85.213.193]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20120 invoked from network); 29 Feb 2012 15:47:36 -0000
Received: from mail-yx0-f193.google.com (HELO mail-yx0-f193.google.com)
	(209.85.213.193)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:47:36 -0000
Received: by yenl12 with SMTP id l12so285352yen.0
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 07:47:34 -0800 (PST)
Received-SPF: pass (google.com: domain of yzt356@gmail.com designates
	10.236.148.143 as permitted sender) client-ip=10.236.148.143; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of yzt356@gmail.com
	designates 10.236.148.143 as permitted sender)
	smtp.mail=yzt356@gmail.com; dkim=pass header.i=yzt356@gmail.com
Received: from mr.google.com ([10.236.148.143])
	by 10.236.148.143 with SMTP id v15mr1243332yhj.47.1330530454827
	(num_hops = 1); Wed, 29 Feb 2012 07:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=8neZSS34ybsK4P12Y+YhMxC8fz2zhUZfb648szfjt3A=;
	b=MO/I27++bNtTXJlHbSXsY4V750h8WFqjnnWR/w1FFtYTItCQQkixgGtkAo/4b/AKCJ
	Tou6c+VXJGOUx1x81/XeI10a+sa7yWIR85fCOjmsV52aumqAAmy0sa0VKVCWhjtxtvl6
	saHUoL9C+EASql2mArjHo4cu7P5NC16mrAYvU=
MIME-Version: 1.0
Received: by 10.236.148.143 with SMTP id v15mr993506yhj.47.1330530454782; Wed,
	29 Feb 2012 07:47:34 -0800 (PST)
Received: by 10.236.182.234 with HTTP; Wed, 29 Feb 2012 07:47:34 -0800 (PST)
Date: Wed, 29 Feb 2012 23:47:34 +0800
Message-ID: <CABpY8MJ1TKX2T+H+tOhiNjQmhG6bpDE2-Jk8GdeqPn7POqCbwg@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [xen-devel] Question about local disk support for live
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8221327408989025471=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8221327408989025471==
Content-Type: multipart/alternative; boundary=20cf303a320b1ec15c04ba1c4333

--20cf303a320b1ec15c04ba1c4333
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I know Xen does not support local disk sync support for live migration, and
I want to know if there's any plan in adding this module as a future
feature? Or if anyone is doing this?

Thanks.

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf303a320b1ec15c04ba1c4333
Content-Type: text/html; charset=ISO-8859-1

Hi all,<div>I know Xen does not support local disk sync support for live migration, and I want to know if there&#39;s any plan in adding this module as a future feature? Or if anyone is doing this?</div><div><br></div><div>

Thanks.<br clear="all"><div><br></div>-- <br>Chunqi Li<br>Department of Computer Science<br>School of EECS<br>Peking University<br>Beijing, China<br>
</div>

--20cf303a320b1ec15c04ba1c4333--


--===============8221327408989025471==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8221327408989025471==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 15:48:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:48:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lkm-0001vV-Ju; Wed, 29 Feb 2012 15:47:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yzt356@gmail.com>) id 1S2lkk-0001v6-Ng
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 15:47:42 +0000
X-Env-Sender: yzt356@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330530455!15506479!1
X-Originating-IP: [209.85.213.193]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20120 invoked from network); 29 Feb 2012 15:47:36 -0000
Received: from mail-yx0-f193.google.com (HELO mail-yx0-f193.google.com)
	(209.85.213.193)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 15:47:36 -0000
Received: by yenl12 with SMTP id l12so285352yen.0
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 07:47:34 -0800 (PST)
Received-SPF: pass (google.com: domain of yzt356@gmail.com designates
	10.236.148.143 as permitted sender) client-ip=10.236.148.143; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of yzt356@gmail.com
	designates 10.236.148.143 as permitted sender)
	smtp.mail=yzt356@gmail.com; dkim=pass header.i=yzt356@gmail.com
Received: from mr.google.com ([10.236.148.143])
	by 10.236.148.143 with SMTP id v15mr1243332yhj.47.1330530454827
	(num_hops = 1); Wed, 29 Feb 2012 07:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=8neZSS34ybsK4P12Y+YhMxC8fz2zhUZfb648szfjt3A=;
	b=MO/I27++bNtTXJlHbSXsY4V750h8WFqjnnWR/w1FFtYTItCQQkixgGtkAo/4b/AKCJ
	Tou6c+VXJGOUx1x81/XeI10a+sa7yWIR85fCOjmsV52aumqAAmy0sa0VKVCWhjtxtvl6
	saHUoL9C+EASql2mArjHo4cu7P5NC16mrAYvU=
MIME-Version: 1.0
Received: by 10.236.148.143 with SMTP id v15mr993506yhj.47.1330530454782; Wed,
	29 Feb 2012 07:47:34 -0800 (PST)
Received: by 10.236.182.234 with HTTP; Wed, 29 Feb 2012 07:47:34 -0800 (PST)
Date: Wed, 29 Feb 2012 23:47:34 +0800
Message-ID: <CABpY8MJ1TKX2T+H+tOhiNjQmhG6bpDE2-Jk8GdeqPn7POqCbwg@mail.gmail.com>
From: =?UTF-8?B?5p2O5pil5aWHIDxDaHVucWkgTGk+?= <yzt356@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [xen-devel] Question about local disk support for live
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8221327408989025471=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8221327408989025471==
Content-Type: multipart/alternative; boundary=20cf303a320b1ec15c04ba1c4333

--20cf303a320b1ec15c04ba1c4333
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I know Xen does not support local disk sync support for live migration, and
I want to know if there's any plan in adding this module as a future
feature? Or if anyone is doing this?

Thanks.

-- 
Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China

--20cf303a320b1ec15c04ba1c4333
Content-Type: text/html; charset=ISO-8859-1

Hi all,<div>I know Xen does not support local disk sync support for live migration, and I want to know if there&#39;s any plan in adding this module as a future feature? Or if anyone is doing this?</div><div><br></div><div>

Thanks.<br clear="all"><div><br></div>-- <br>Chunqi Li<br>Department of Computer Science<br>School of EECS<br>Peking University<br>Beijing, China<br>
</div>

--20cf303a320b1ec15c04ba1c4333--


--===============8221327408989025471==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8221327408989025471==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 15:52:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lp9-0002IY-Tk; Wed, 29 Feb 2012 15:52:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2lp8-0002Hw-Jm
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:52:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330530728!17044034!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25197 invoked from network); 29 Feb 2012 15:52:08 -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;
	29 Feb 2012 15:52:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11014859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 15:52:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 15:52:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2lp2-000587-5n; Wed, 29 Feb 2012 15:52:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2lp2-0005b2-4v;
	Wed, 29 Feb 2012 15:52:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.18856.140051.792707@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 15:52:08 +0000
To: <xen-devel@lists.xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Tools maintainer away next week
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 will be away next week, starting on Friday (for 6 working days,
thus).

During this time if there are things that urgently need to be done to
fix problems with the tools side of Xen, Ian Campbell will be standing
in for me.

I hope to get through my patch backlog and be up to date before leaving.
After that please don't take silence from me as assent :-).  I will
deal with submitted patches when I get back.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 15:52:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 15:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2lp9-0002IY-Tk; Wed, 29 Feb 2012 15:52:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2lp8-0002Hw-Jm
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 15:52:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330530728!17044034!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25197 invoked from network); 29 Feb 2012 15:52:08 -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;
	29 Feb 2012 15:52:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11014859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 15:52:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 15:52:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2lp2-000587-5n; Wed, 29 Feb 2012 15:52:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2lp2-0005b2-4v;
	Wed, 29 Feb 2012 15:52:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.18856.140051.792707@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 15:52:08 +0000
To: <xen-devel@lists.xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Tools maintainer away next week
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 will be away next week, starting on Friday (for 6 working days,
thus).

During this time if there are things that urgently need to be done to
fix problems with the tools side of Xen, Ian Campbell will be standing
in for me.

I hope to get through my patch backlog and be up to date before leaving.
After that please don't take silence from me as assent :-).  I will
deal with submitted patches when I get back.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:19:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2mEk-0003H3-EY; Wed, 29 Feb 2012 16:18:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2mEi-0003Gy-OA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:18:41 +0000
Received: from [85.158.139.83:15367] by server-7.bemta-5.messagelabs.com id
	19/7F-16195-FDF4E4F4; Wed, 29 Feb 2012 16:18:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330532318!16406033!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16517 invoked from network); 29 Feb 2012 16:18:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 16:18:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330532318; l=863;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hvIvZ7Kd1XRegmEZbRh+CNv5zFU=;
	b=m9tRK4MwT2I2RCUPNfQbUFfZhkblTXM7mAAJbDyw2qLXwCQqN36ulO9GrCmDpWfB2e5
	w889hTwBaXcXKCGEnGRdomg/YnDgeRvt2neAURSgMZi1WU6cnyTr6RyBbc0jwOmxitxJO
	yK50KYbVP+Lcnww/t+cReIkGOFResyULqqA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (cohen mo57) (RZmta 28.0 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id w002c1o1TF27ZX ;
	Wed, 29 Feb 2012 17:18:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 706A618638; Wed, 29 Feb 2012 17:18:22 +0100 (CET)
Date: Wed, 29 Feb 2012 17:18:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120229161822.GA6878@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de>
	<20120227165152.GA32471@aepfle.de>
	<EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
	<c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, Andres Lagar-Cavilla wrote:

> >
> > On Feb 27, 2012, at 11:51 AM, Olaf Hering wrote:
> >
> >> On Sun, Feb 26, Olaf Hering wrote:
> >>
> >>> On Thu, Feb 23, Tim Deegan wrote:
> >>>
> >>>> This is v2 of the patch I posted last week, after feedback from
> >>>> Andres.
> >>>
> >>> Tried this series, but processes in dom0 started to hang in D state
> >>> when a paged guest is started. I will see if I can spot the error.
> >>
> >> This change for patch #5 is needed, especially the first part.
> >> Now it appears to work.
> >>
> >> Olaf
> 
> Unfortunately, I get all kinds of borking on Win7 domains with Citrix PV
> drivers 6.0. So it's a no-go from my end for now.

This is the domain_lock() in xenmem_add_to_physmap_once(). 

Is get_gfn_untyped() correct, or would get_gfn_query() work as well in
this context?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:19:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16:19:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2mEk-0003H3-EY; Wed, 29 Feb 2012 16:18:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2mEi-0003Gy-OA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:18:41 +0000
Received: from [85.158.139.83:15367] by server-7.bemta-5.messagelabs.com id
	19/7F-16195-FDF4E4F4; Wed, 29 Feb 2012 16:18:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1330532318!16406033!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16517 invoked from network); 29 Feb 2012 16:18:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 16:18:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330532318; l=863;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hvIvZ7Kd1XRegmEZbRh+CNv5zFU=;
	b=m9tRK4MwT2I2RCUPNfQbUFfZhkblTXM7mAAJbDyw2qLXwCQqN36ulO9GrCmDpWfB2e5
	w889hTwBaXcXKCGEnGRdomg/YnDgeRvt2neAURSgMZi1WU6cnyTr6RyBbc0jwOmxitxJO
	yK50KYbVP+Lcnww/t+cReIkGOFResyULqqA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (cohen mo57) (RZmta 28.0 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id w002c1o1TF27ZX ;
	Wed, 29 Feb 2012 17:18:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 706A618638; Wed, 29 Feb 2012 17:18:22 +0100 (CET)
Date: Wed, 29 Feb 2012 17:18:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120229161822.GA6878@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de>
	<20120227165152.GA32471@aepfle.de>
	<EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
	<c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 28, Andres Lagar-Cavilla wrote:

> >
> > On Feb 27, 2012, at 11:51 AM, Olaf Hering wrote:
> >
> >> On Sun, Feb 26, Olaf Hering wrote:
> >>
> >>> On Thu, Feb 23, Tim Deegan wrote:
> >>>
> >>>> This is v2 of the patch I posted last week, after feedback from
> >>>> Andres.
> >>>
> >>> Tried this series, but processes in dom0 started to hang in D state
> >>> when a paged guest is started. I will see if I can spot the error.
> >>
> >> This change for patch #5 is needed, especially the first part.
> >> Now it appears to work.
> >>
> >> Olaf
> 
> Unfortunately, I get all kinds of borking on Win7 domains with Citrix PV
> drivers 6.0. So it's a no-go from my end for now.

This is the domain_lock() in xenmem_add_to_physmap_once(). 

Is get_gfn_untyped() correct, or would get_gfn_query() work as well in
this context?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:19:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2mFE-0003Im-Rl; Wed, 29 Feb 2012 16:19:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mFD-0003I6-D4
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:19:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330532344!15511956!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31856 invoked from network); 29 Feb 2012 16:19:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:19:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:19:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:19:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mF6-0005dm-6Y; Wed, 29 Feb 2012 16:19:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mF6-00064Q-5i;
	Wed, 29 Feb 2012 16:19:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.20472.162310.143441@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:19:04 +0000
To: Kristijan =?iso-8859-2?Q?Le=E8nik?= <janez3k@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACC+8CRaMfCqAOOMcVtiQZt4cu+Z+Qpg+GpJPC9KaZbwNgGL4g@mail.gmail.com>
References: <CACC+8CQdicMj=CnRsi3HXOhxhBuejyD1-QngFEz7R6VBKW+brA@mail.gmail.com>
	<CACC+8CRaMfCqAOOMcVtiQZt4cu+Z+Qpg+GpJPC9KaZbwNgGL4g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Kristijan Le=E8nik writes ("[Xen-devel] xen git"):
> is there something wrong with xen git?

Yes, there was.  I fixed it earlier today.  I have changed the
configuration in a way which I hope will prevent a recurrence.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:19:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2mFE-0003Im-Rl; Wed, 29 Feb 2012 16:19:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mFD-0003I6-D4
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:19:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330532344!15511956!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31856 invoked from network); 29 Feb 2012 16:19:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:19:05 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:19:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:19:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mF6-0005dm-6Y; Wed, 29 Feb 2012 16:19:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mF6-00064Q-5i;
	Wed, 29 Feb 2012 16:19:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.20472.162310.143441@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:19:04 +0000
To: Kristijan =?iso-8859-2?Q?Le=E8nik?= <janez3k@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACC+8CRaMfCqAOOMcVtiQZt4cu+Z+Qpg+GpJPC9KaZbwNgGL4g@mail.gmail.com>
References: <CACC+8CQdicMj=CnRsi3HXOhxhBuejyD1-QngFEz7R6VBKW+brA@mail.gmail.com>
	<CACC+8CRaMfCqAOOMcVtiQZt4cu+Z+Qpg+GpJPC9KaZbwNgGL4g@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Kristijan Le=E8nik writes ("[Xen-devel] xen git"):
> is there something wrong with xen git?

Yes, there was.  I fixed it earlier today.  I have changed the
configuration in a way which I hope will prevent a recurrence.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mGv-0003RP-B4; Wed, 29 Feb 2012 16:20:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mGt-0003Qn-FA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:20:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330532449!10362222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16108 invoked from network); 29 Feb 2012 16:20:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:20:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:20:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mGm-0005eV-H5; Wed, 29 Feb 2012 16:20:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mGm-00066q-GF;
	Wed, 29 Feb 2012 16:20:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.20576.488036.858878@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:20:48 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520738.4270.84.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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] Need help with qemu args debug"):
> (probably the bad quoting in the example I gave has lead to the
> qemu-debug.sh "correcting" this for you. I think I should have said
> either 
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$@"
> or
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$*"
> (I can never remember which is correct)

"$@"

You should not normally use $* at all.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mGv-0003RP-B4; Wed, 29 Feb 2012 16:20:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mGt-0003Qn-FA
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:20:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330532449!10362222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16108 invoked from network); 29 Feb 2012 16:20:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:20:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:20:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mGm-0005eV-H5; Wed, 29 Feb 2012 16:20:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mGm-00066q-GF;
	Wed, 29 Feb 2012 16:20:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.20576.488036.858878@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:20:48 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520738.4270.84.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fantu <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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] Need help with qemu args debug"):
> (probably the bad quoting in the example I gave has lead to the
> qemu-debug.sh "correcting" this for you. I think I should have said
> either 
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$@"
> or
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$*"
> (I can never remember which is correct)

"$@"

You should not normally use $* at all.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:25:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mL1-0003oX-0P; Wed, 29 Feb 2012 16:25:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2mL0-0003oN-0R
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:25:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330532703!15512930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25815 invoked from network); 29 Feb 2012 16:25:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:23:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 16:23:23 +0000
Message-ID: <1330532601.4270.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 16:23:21 +0000
In-Reply-To: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDE0OjUxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yOSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEkgX3RoaW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRo
ZSBnZW5lcmF0ZWQgZmlsZXMuIEEKPiA+IG1vcmUgY29tcGxldGUgZml4IG1pZ2h0IGFsc28gYWxs
b3cgdGhlIHVzZXIgdG8gZm9yY2UgcmVnZW5lcmF0aW9uIGJ1dCBJIGRpZG4ndAo+ID4gYm90aCBo
ZXJlLgo+ID4KPiA+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+Cj4gPiAtLS0KPiA+ICB0b29scy9jb25maWd1cmUgICAgfCAgNTU5ICsrKysrKysr
KysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICB0b29scy9j
b25maWd1cmUuYWMgfCAgICAxIC0KPiAKPiBZb3UgZm9yZ2V0IHRvIHJlbW92ZToKPiAKPiBBQ19B
UkdfVkFSKFtCSVNPTl0sIFtQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQo+IGZyb20g
dG9vbHMvY29uZmlndXJlLmFjIGFuZCBhbHNvIGNsZWFuIHJlbGF0ZWQgdmFyaWFibGVzIGZyb20K
PiBjb25maWcvVG9vbHMubWsuaW4uCj4gCkFjdHVhbGx5LCB0aGlua2luZyBhYm91dCB0aGlzIGEg
Yml0IG1vcmUsIEkgdGhpbmsgd2Ugd2FudCB0byBrZWVwIHRoaXMKYml0IHNvIHRoYXQgdGhlIGJp
c29uIGJpbmFyeSBpcyBzdGlsbCBjb25maWd1cmFibGUgZm9yIHRob3NlIHdobyBhcmUKY2hhbmdp
bmcgdGhvc2UgcGFydGljdWxhciBzb3VyY2UgZmlsZXMuCgpIZW5jZSBJIGFtIGp1c3QgcmVtb3Zp
bmcgdGhlIEFYX1BBVEhfUFJPR19PUl9GQUlMIHJlbGF0aW5nIHRvIEJpc29uIGFuZApGbGV4LgoK
SSBoYXZlIG9taXR0ZWQgdGhlIGNoYW5nZSB0byB0aGUgZ2VuZXJhdGVkIGZpbGUuCgo4PC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
CkZyb20gNzFkYzQ1ODFkMjIyNjExMmYxNzMwODIxMGY1M2EzMDE4OWQ0ZDU2MiBNb24gU2VwIDE3
IDAwOjAwOjAwIDIwMDEKRnJvbTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNv
bT4KRGF0ZTogV2VkLCAyOSBGZWIgMjAxMiAxNDoyMjozNCArMDAwMApTdWJqZWN0OiBbUEFUQ0hd
IGNvbmZpZ3VyZTogZG8gbm90IHJlcXVpcmUgQmlzb24gb3IgRmxleAoKSSBfdGhpbmtfIHRoaXMg
aXNuJ3QgcmVxdWlyZWQgYmVjYXVzZSB3ZSBhbHNvIGNoZWNraW4gdGhlIGdlbmVyYXRlZCBmaWxl
cy4gQQptb3JlIGNvbXBsZXRlIGZpeCBtaWdodCBhbHNvIGFsbG93IHRoZSB1c2VyIHRvIGZvcmNl
IHJlZ2VuZXJhdGlvbiBidXQgSSBkaWRuJ3QKYm90aCBoZXJlLgoKU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCmRpZmYgLS1naXQgYS90b29scy9j
b25maWd1cmUuYWMgYi90b29scy9jb25maWd1cmUuYWMKaW5kZXggNWIyODE1ZC4uZTZkOGY0YiAx
MDA2NDQKLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwpA
QCAtNzksOCArNzksNiBAQCBBQ19QUk9HX01BS0VfU0VUCiBBQ19QUk9HX0lOU1RBTEwKIEFYX1BB
VEhfUFJPR19PUl9GQUlMKFtQRVJMXSwgW3BlcmxdKQogQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQ
XSwgW2lwXSkKLUFYX1BBVEhfUFJPR19PUl9GQUlMKFtCSVNPTl0sIFtiaXNvbl0pCi1BWF9QQVRI
X1BST0dfT1JfRkFJTChbRkxFWF0sIFtmbGV4XSkKIEFTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5
Il0sIFsKICAgICBBWF9QQVRIX1BST0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCiAg
ICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10pCi0tIAoxLjcuMi41
CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:25:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mL1-0003oX-0P; Wed, 29 Feb 2012 16:25:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2mL0-0003oN-0R
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:25:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1330532703!15512930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25815 invoked from network); 29 Feb 2012 16:25:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:23:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 16:23:23 +0000
Message-ID: <1330532601.4270.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 29 Feb 2012 16:23:21 +0000
In-Reply-To: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTAyLTI5IGF0IDE0OjUxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMi8yOSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEkgX3RoaW5rXyB0aGlzIGlzbid0IHJlcXVpcmVkIGJlY2F1c2Ugd2UgYWxzbyBjaGVja2luIHRo
ZSBnZW5lcmF0ZWQgZmlsZXMuIEEKPiA+IG1vcmUgY29tcGxldGUgZml4IG1pZ2h0IGFsc28gYWxs
b3cgdGhlIHVzZXIgdG8gZm9yY2UgcmVnZW5lcmF0aW9uIGJ1dCBJIGRpZG4ndAo+ID4gYm90aCBo
ZXJlLgo+ID4KPiA+IFNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp
dHJpeC5jb20+Cj4gPiAtLS0KPiA+ICB0b29scy9jb25maWd1cmUgICAgfCAgNTU5ICsrKysrKysr
KysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICB0b29scy9j
b25maWd1cmUuYWMgfCAgICAxIC0KPiAKPiBZb3UgZm9yZ2V0IHRvIHJlbW92ZToKPiAKPiBBQ19B
UkdfVkFSKFtCSVNPTl0sIFtQYXRoIHRvIEJpc29uIHBhcnNlciBnZW5lcmF0b3JdKQo+IGZyb20g
dG9vbHMvY29uZmlndXJlLmFjIGFuZCBhbHNvIGNsZWFuIHJlbGF0ZWQgdmFyaWFibGVzIGZyb20K
PiBjb25maWcvVG9vbHMubWsuaW4uCj4gCkFjdHVhbGx5LCB0aGlua2luZyBhYm91dCB0aGlzIGEg
Yml0IG1vcmUsIEkgdGhpbmsgd2Ugd2FudCB0byBrZWVwIHRoaXMKYml0IHNvIHRoYXQgdGhlIGJp
c29uIGJpbmFyeSBpcyBzdGlsbCBjb25maWd1cmFibGUgZm9yIHRob3NlIHdobyBhcmUKY2hhbmdp
bmcgdGhvc2UgcGFydGljdWxhciBzb3VyY2UgZmlsZXMuCgpIZW5jZSBJIGFtIGp1c3QgcmVtb3Zp
bmcgdGhlIEFYX1BBVEhfUFJPR19PUl9GQUlMIHJlbGF0aW5nIHRvIEJpc29uIGFuZApGbGV4LgoK
SSBoYXZlIG9taXR0ZWQgdGhlIGNoYW5nZSB0byB0aGUgZ2VuZXJhdGVkIGZpbGUuCgo4PC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
CkZyb20gNzFkYzQ1ODFkMjIyNjExMmYxNzMwODIxMGY1M2EzMDE4OWQ0ZDU2MiBNb24gU2VwIDE3
IDAwOjAwOjAwIDIwMDEKRnJvbTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNv
bT4KRGF0ZTogV2VkLCAyOSBGZWIgMjAxMiAxNDoyMjozNCArMDAwMApTdWJqZWN0OiBbUEFUQ0hd
IGNvbmZpZ3VyZTogZG8gbm90IHJlcXVpcmUgQmlzb24gb3IgRmxleAoKSSBfdGhpbmtfIHRoaXMg
aXNuJ3QgcmVxdWlyZWQgYmVjYXVzZSB3ZSBhbHNvIGNoZWNraW4gdGhlIGdlbmVyYXRlZCBmaWxl
cy4gQQptb3JlIGNvbXBsZXRlIGZpeCBtaWdodCBhbHNvIGFsbG93IHRoZSB1c2VyIHRvIGZvcmNl
IHJlZ2VuZXJhdGlvbiBidXQgSSBkaWRuJ3QKYm90aCBoZXJlLgoKU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCmRpZmYgLS1naXQgYS90b29scy9j
b25maWd1cmUuYWMgYi90b29scy9jb25maWd1cmUuYWMKaW5kZXggNWIyODE1ZC4uZTZkOGY0YiAx
MDA2NDQKLS0tIGEvdG9vbHMvY29uZmlndXJlLmFjCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZS5hYwpA
QCAtNzksOCArNzksNiBAQCBBQ19QUk9HX01BS0VfU0VUCiBBQ19QUk9HX0lOU1RBTEwKIEFYX1BB
VEhfUFJPR19PUl9GQUlMKFtQRVJMXSwgW3BlcmxdKQogQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQ
XSwgW2lwXSkKLUFYX1BBVEhfUFJPR19PUl9GQUlMKFtCSVNPTl0sIFtiaXNvbl0pCi1BWF9QQVRI
X1BST0dfT1JfRkFJTChbRkxFWF0sIFtmbGV4XSkKIEFTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5
Il0sIFsKICAgICBBWF9QQVRIX1BST0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCiAg
ICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10pCi0tIAoxLjcuMi41
CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:26:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16:26:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2mLg-0003ri-Dt; Wed, 29 Feb 2012 16:25:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mLf-0003rD-9B
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:25:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330532744!15503942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11156 invoked from network); 29 Feb 2012 16:25:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:25:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:25:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mLX-0005gL-Kh; Wed, 29 Feb 2012 16:25:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mLX-0006KX-Jz;
	Wed, 29 Feb 2012 16:25:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.20871.593869.740250@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:25:43 +0000
To: Attilio Rao <attilio.rao@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3c10ba854d3750750100.1330520427@dhcp-3-145.uk.xensource.com>
References: <3c10ba854d3750750100.1330520427@dhcp-3-145.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@citrix.com
Subject: Re: [Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify
	the	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Attilio Rao writes ("[Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify the bios to load"):
> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:26:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16:26:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2mLg-0003ri-Dt; Wed, 29 Feb 2012 16:25:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mLf-0003rD-9B
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:25:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1330532744!15503942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11156 invoked from network); 29 Feb 2012 16:25:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:25:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:25:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mLX-0005gL-Kh; Wed, 29 Feb 2012 16:25:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mLX-0006KX-Jz;
	Wed, 29 Feb 2012 16:25:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.20871.593869.740250@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:25:43 +0000
To: Attilio Rao <attilio.rao@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3c10ba854d3750750100.1330520427@dhcp-3-145.uk.xensource.com>
References: <3c10ba854d3750750100.1330520427@dhcp-3-145.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@citrix.com
Subject: Re: [Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify
	the	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Attilio Rao writes ("[Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify the bios to load"):
> Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:30:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mQ4-00046O-3b; Wed, 29 Feb 2012 16:30:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mQ2-00046H-Ra
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:30:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330533016!16974492!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16413 invoked from network); 29 Feb 2012 16:30: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;
	29 Feb 2012 16:30:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:30:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:30:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mPv-0005iM-U4; Wed, 29 Feb 2012 16:30:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mPv-0006QM-TD;
	Wed, 29 Feb 2012 16:30:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.21143.892134.675256@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:30:15 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xen.org
Subject: [Xen-devel]  [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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] configure: do not require Bison"):
> I _think_ this isn't required because we also checkin the generated files. A
> more complete fix might also allow the user to force regeneration but I didn't
> both here.

flex is optional too 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 Feb 29 16:30:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mQ4-00046O-3b; Wed, 29 Feb 2012 16:30:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mQ2-00046H-Ra
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:30:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330533016!16974492!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16413 invoked from network); 29 Feb 2012 16:30: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;
	29 Feb 2012 16:30:16 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:30:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:30:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mPv-0005iM-U4; Wed, 29 Feb 2012 16:30:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mPv-0006QM-TD;
	Wed, 29 Feb 2012 16:30:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.21143.892134.675256@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:30:15 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>, xen-devel@lists.xen.org
Subject: [Xen-devel]  [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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] configure: do not require Bison"):
> I _think_ this isn't required because we also checkin the generated files. A
> more complete fix might also allow the user to force regeneration but I didn't
> both here.

flex is optional too 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 Feb 29 16:35:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mVA-0004KG-G3; Wed, 29 Feb 2012 16:35:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mV8-0004Jx-WD
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:35:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330533330!8138488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32313 invoked from network); 29 Feb 2012 16:35:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:35:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:35:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mV0-0005kJ-3z; Wed, 29 Feb 2012 16:35:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mV0-0006WR-3B;
	Wed, 29 Feb 2012 16:35:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.21458.85753.480598@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:35:30 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] configure: do not requir=
e Bison> If you can, could you use autoconf 2.68 (present
> in Debian stable) to generate the new configure script? So we don't
> have to push so many unrelated changes to configure script and
> downgrate its version?

This is not necessary.  When I apply this patch I will rerun autoconf
myself, so what gets committed is sane.  Patches of this kind can be
submitted either with or without the generated changes.

But please would submitters mention that autogen needs to be rerun, in
case I don't spot it (which is particularly likely if the submitter's
patch fails to include the autogenerated file changes).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:35:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mVA-0004KG-G3; Wed, 29 Feb 2012 16:35:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mV8-0004Jx-WD
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 16:35:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1330533330!8138488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32313 invoked from network); 29 Feb 2012 16:35:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:35:31 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11016678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:35:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 16:35:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mV0-0005kJ-3z; Wed, 29 Feb 2012 16:35:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mV0-0006WR-3B;
	Wed, 29 Feb 2012 16:35:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.21458.85753.480598@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 16:35:30 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] configure: do not requir=
e Bison> If you can, could you use autoconf 2.68 (present
> in Debian stable) to generate the new configure script? So we don't
> have to push so many unrelated changes to configure script and
> downgrate its version?

This is not necessary.  When I apply this patch I will rerun autoconf
myself, so what gets committed is sane.  Patches of this kind can be
submitted either with or without the generated changes.

But please would submitters mention that autogen needs to be rerun, in
case I don't spot it (which is particularly likely if the submitter's
patch fails to include the autogenerated file changes).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:54:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mn2-0004qs-A3; Wed, 29 Feb 2012 16:54:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2mn0-0004qc-Gk
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:54:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330534439!16978554!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10174 invoked from network); 29 Feb 2012 16:54:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:54:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017193"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:53:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 16:53:58 +0000
Message-ID: <1330534437.4270.143.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, <xen-api@lists.xen.org>
Date: Wed, 29 Feb 2012 16:53:57 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] GSoC 2012 project brainstorming
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Below are a few ideas which have been floating around as potential
projects (or broad subject areas for projects) for GSoC this year.

If you want any more information on any particular item then please ask.
Likewise if you have any ideas of your own please feel free to chip in.

If you think you might be interested in a project, either as mentor or
potential student, then please add it to the wiki page at
http://wiki.xen.org/wiki/GSoC_2012_Ideas

Ian.

TOOLS
-----
- pv grub2
- xapi support in libvirt
- make xapi use libxl
- compile xapi on ARM
- OpenXenManager
- driver domains
- PV dbus
- HA daemon for Remus
- HA daemon for XCP

PERF
----
- Oprofile
- Linux perf tools in guest

HYPERVISOR
----------
- insmod Xen
- event channel limits
- NUMA

MEMORY
------
- disk based memory sharing
- memory scanner
- paging replacing PoD
- VM Fork
- Copy on read (past VDI boot)


IO
--
- PV OpenGL/Gallium
- PV USB
- PV USB3
- PV SCSI
- PVFB in Xorg
- Infiniband


STORAGE
-------
- gluster/ceph plugins


QEMU
----
- BSD libc
- upstream QEMU stubdoms


TESTS
-----
- better web reporting
- more tests
- upstream linux


DISTROS
-------
- packaging stubdoms
- xen on centos6
- driver domains
- figure out the VM format issue
- XSM in distros



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 16:54:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 16: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 1S2mn2-0004qs-A3; Wed, 29 Feb 2012 16:54:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2mn0-0004qc-Gk
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 16:54:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330534439!16978554!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10174 invoked from network); 29 Feb 2012 16:54:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 16:54:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017193"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 16:53:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 16:53:58 +0000
Message-ID: <1330534437.4270.143.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, <xen-api@lists.xen.org>
Date: Wed, 29 Feb 2012 16:53:57 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Subject: [Xen-devel] GSoC 2012 project brainstorming
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Below are a few ideas which have been floating around as potential
projects (or broad subject areas for projects) for GSoC this year.

If you want any more information on any particular item then please ask.
Likewise if you have any ideas of your own please feel free to chip in.

If you think you might be interested in a project, either as mentor or
potential student, then please add it to the wiki page at
http://wiki.xen.org/wiki/GSoC_2012_Ideas

Ian.

TOOLS
-----
- pv grub2
- xapi support in libvirt
- make xapi use libxl
- compile xapi on ARM
- OpenXenManager
- driver domains
- PV dbus
- HA daemon for Remus
- HA daemon for XCP

PERF
----
- Oprofile
- Linux perf tools in guest

HYPERVISOR
----------
- insmod Xen
- event channel limits
- NUMA

MEMORY
------
- disk based memory sharing
- memory scanner
- paging replacing PoD
- VM Fork
- Copy on read (past VDI boot)


IO
--
- PV OpenGL/Gallium
- PV USB
- PV USB3
- PV SCSI
- PVFB in Xorg
- Infiniband


STORAGE
-------
- gluster/ceph plugins


QEMU
----
- BSD libc
- upstream QEMU stubdoms


TESTS
-----
- better web reporting
- more tests
- upstream linux


DISTROS
-------
- packaging stubdoms
- xen on centos6
- driver domains
- figure out the VM format issue
- XSM in distros



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2muH-00056s-6d; Wed, 29 Feb 2012 17:01:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2muG-00056n-Ao
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:01:36 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330534889!11349302!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24474 invoked from network); 29 Feb 2012 17:01:30 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:01:30 -0000
Received: by lagr15 with SMTP id r15so8358532lag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 09:01:29 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.152.130.234 as permitted sender) client-ip=10.152.130.234; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.152.130.234 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.152.130.234])
	by 10.152.130.234 with SMTP id oh10mr1115767lab.35.1330534889344
	(num_hops = 1); Wed, 29 Feb 2012 09:01:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=x9LOA4Mtj4Av3xiQx2THNu6ObnCrlMRppK2RzdjlJ9E=;
	b=WawmEZHI8uY6ZRGtYYSlQz1nTAfz6J/HPZmWf5g1xn1kBBoE2Kkn0ICY+nu1x8xxID
	5L7Eju9zcMZOIt3YIQu40MW3rIV0Au3ytiAYAgr9ErSIq+nzeGFg6Kqt+tLcJLaUWeZs
	Bz0OxtZNYBThHqQ/EeBfdscr3yZO53ejrypXs=
Received: by 10.152.130.234 with SMTP id oh10mr906945lab.35.1330534889288;
	Wed, 29 Feb 2012 09:01:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Wed, 29 Feb 2012 09:01:09 -0800 (PST)
In-Reply-To: <CAPLaKK7RbsoTinxf7f=BtL2PZ-4gUqDPC3kM9bka=bLBnmpAxQ@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
	<CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
	<1330513027.4270.43.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RbsoTinxf7f=BtL2PZ-4gUqDPC3kM9bka=bLBnmpAxQ@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Wed, 29 Feb 2012 09:01:09 -0800
Message-ID: <CAFw--DfJREXUSs36okYTBCjvGp17y-uWszoxNuJ6vA05o3AUww@mail.gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> $prefix is set by passing the command line option or by default when
> calling AC_OUTPUT, but since AC_OUTPUT is called at the end, this is
> not really helpful, so we have to set $exec_prefix manually to the
> correct value, either $prefix if different than NONE or
> $ac_default_prefix. I agree that the previous patch was a bit of a
> mess with $prefix and $exec_prefix, this is more "correct"

I applied this patch to my local system and it corrected the issue.
Thanks Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2muH-00056s-6d; Wed, 29 Feb 2012 17:01:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1S2muG-00056n-Ao
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:01:36 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1330534889!11349302!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24474 invoked from network); 29 Feb 2012 17:01:30 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:01:30 -0000
Received: by lagr15 with SMTP id r15so8358532lag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 09:01:29 -0800 (PST)
Received-SPF: pass (google.com: domain of karrelsj@gmail.com designates
	10.152.130.234 as permitted sender) client-ip=10.152.130.234; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of karrelsj@gmail.com
	designates 10.152.130.234 as permitted sender)
	smtp.mail=karrelsj@gmail.com;
	dkim=pass header.i=karrelsj@gmail.com
Received: from mr.google.com ([10.152.130.234])
	by 10.152.130.234 with SMTP id oh10mr1115767lab.35.1330534889344
	(num_hops = 1); Wed, 29 Feb 2012 09:01:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=x9LOA4Mtj4Av3xiQx2THNu6ObnCrlMRppK2RzdjlJ9E=;
	b=WawmEZHI8uY6ZRGtYYSlQz1nTAfz6J/HPZmWf5g1xn1kBBoE2Kkn0ICY+nu1x8xxID
	5L7Eju9zcMZOIt3YIQu40MW3rIV0Au3ytiAYAgr9ErSIq+nzeGFg6Kqt+tLcJLaUWeZs
	Bz0OxtZNYBThHqQ/EeBfdscr3yZO53ejrypXs=
Received: by 10.152.130.234 with SMTP id oh10mr906945lab.35.1330534889288;
	Wed, 29 Feb 2012 09:01:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.22.40 with HTTP; Wed, 29 Feb 2012 09:01:09 -0800 (PST)
In-Reply-To: <CAPLaKK7RbsoTinxf7f=BtL2PZ-4gUqDPC3kM9bka=bLBnmpAxQ@mail.gmail.com>
References: <CAGU+aut64MmMmf901p9Gsya4O=hep8merZUDfSUuJCJXMVFtrg@mail.gmail.com>
	<1319013780.3385.64.camel@zakaz.uk.xensource.com>
	<20126.62103.576976.140927@mariner.uk.xensource.com>
	<CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
	<1319287633.17770.10.camel@dagon.hellion.org.uk>
	<CAGU+auvQx1+dtj-ByDHSCyw6B3WwT7pJsHrgn3mx3+jj3rAjew@mail.gmail.com>
	<CAFw--Df2t22i426x5rvNnjsP27u0ZajMC0LP6+9_c03YKYRbYQ@mail.gmail.com>
	<1330423226.31269.35.camel@zakaz.uk.xensource.com>
	<CAFw--Dex20YfbkutrOuXq7O6CupCnkf=qqiSCWeND6GXrFgOUw@mail.gmail.com>
	<1330459026.10008.57.camel@dagon.hellion.org.uk>
	<CAPLaKK70K8u1bo6vF3Cbo-JUnDb5s-EBEAB-S20djjcfJ2Lnqw@mail.gmail.com>
	<1330513027.4270.43.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RbsoTinxf7f=BtL2PZ-4gUqDPC3kM9bka=bLBnmpAxQ@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Wed, 29 Feb 2012 09:01:09 -0800
Message-ID: <CAFw--DfJREXUSs36okYTBCjvGp17y-uWszoxNuJ6vA05o3AUww@mail.gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] make install not creating lib entries in /usr/lib
 under Ubunu 11.10
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> $prefix is set by passing the command line option or by default when
> calling AC_OUTPUT, but since AC_OUTPUT is called at the end, this is
> not really helpful, so we have to set $exec_prefix manually to the
> correct value, either $prefix if different than NONE or
> $ac_default_prefix. I agree that the previous patch was a bit of a
> mess with $prefix and $exec_prefix, this is more "correct"

I applied this patch to my local system and it corrected the issue.
Thanks Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2muo-00059F-Os; Wed, 29 Feb 2012 17:02:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mun-00058g-AG
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:02:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330534923!14077811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30256 invoked from network); 29 Feb 2012 17:02:03 -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;
	29 Feb 2012 17:02:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:02:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 17:02:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mug-0005uJ-VK; Wed, 29 Feb 2012 17:02:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mug-0006sT-UW;
	Wed, 29 Feb 2012 17:02:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.23050.932924.311250@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 17:02:02 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330532601.4270.135.camel@zakaz.uk.xensource.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
	<1330532601.4270.135.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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] configure: do not require Bison"):
> Subject: [PATCH] configure: do not require Bison or Flex
> 
> I _think_ this isn't required because we also checkin the generated files. A
> more complete fix might also allow the user to force regeneration but I didn't
> both here.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I fixed up the commit message too :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:02:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2muo-00059F-Os; Wed, 29 Feb 2012 17:02:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2mun-00058g-AG
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:02:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1330534923!14077811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30256 invoked from network); 29 Feb 2012 17:02:03 -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;
	29 Feb 2012 17:02:03 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:02:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 17:02:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1S2mug-0005uJ-VK; Wed, 29 Feb 2012 17:02:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1S2mug-0006sT-UW;
	Wed, 29 Feb 2012 17:02:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20302.23050.932924.311250@mariner.uk.xensource.com>
Date: Wed, 29 Feb 2012 17:02:02 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1330532601.4270.135.camel@zakaz.uk.xensource.com>
References: <1330525507-7833-1-git-send-email-ian.campbell@citrix.com>
	<CAPLaKK473A7BuqcQr=SQ-jJRGG4EvODWL1OtcxXetdF2u6mP2A@mail.gmail.com>
	<1330532601.4270.135.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] configure: do not require Bison
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-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] configure: do not require Bison"):
> Subject: [PATCH] configure: do not require Bison or Flex
> 
> I _think_ this isn't required because we also checkin the generated files. A
> more complete fix might also allow the user to force regeneration but I didn't
> both here.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I fixed up the commit message too :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17: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 1S2mux-0005AJ-4x; Wed, 29 Feb 2012 17:02:19 +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 1S2muv-00059k-Kq
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:02:17 +0000
Received: from [85.158.139.83:37941] by server-12.bemta-5.messagelabs.com id
	ED/DF-05587-51A5E4F4; Wed, 29 Feb 2012 17:02:13 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330534931!17196335!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19039 invoked from network); 29 Feb 2012 17:02:12 -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; 29 Feb 2012 17:02:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1TH1k32018799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 17:01:57 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
	q1TGKwKZ001226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 16:20:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1TGKvod012562; Wed, 29 Feb 2012 10:20:57 -0600
MIME-Version: 1.0
Message-ID: <1dff9dfa-2b66-4f82-8058-0ed5e20623ca@default>
Date: Wed, 29 Feb 2012 08:20:42 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, keir@xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020207.4F4E5A0C.0170,ss=1,re=0.000,fgs=0
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] "Deprecate" order>0 allocations? (was: [PATCH 1 of 2]
 Global virq for low memory situations)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Wednesday, February 29, 2012 1:54 AM
> To: Dan Magenheimer
> Cc: ian.campbell@citrix.com; ian.jackson@citrix.com; adin@gridcentric.ca; andres@gridcentric.ca;
> Andres Lagar-Cavilla; xen-devel; tim@xen.org
> Subject: RE: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
> 
> >>> On 29.02.12 at 00:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > Or maybe Jan's recent work has eliminated all but the corner
> > cases of order>0 allocations?  (/me crosses fingers)
> 
> I'm unaware of remaining violators of this, but I'm also not constantly
> monitoring.
> 
> Jan

As various "move memory back and forth between domains"
solutions are becoming increasingly fashionable, use
of order>0 allocations remains a ticking timebomb.

Does it make sense then now to somehow "deprecate" the
code in the allocator that allows order>0 allocations?
Not quite sure how, so just brainstorming.  Some ideas:

1) At minimum, a very big comment warning about the
   silent pitfalls due to fragmentation and a WARN_ON_ONCE
   that occurs when order>1 and debug=1 (and for xen-unstable).
2) Add a new routine for order>0 allocations (with
   a WARN_ON and a big comment) and BUG_ON order>0
   allocations attempted via the old interface.

IIRC, last I heard, some of the PCI-passthrough code
still uses order>0 allocations, so this (and any
other remaining culprits) might need to be grandfathered
in somehow.

But it would be nice to guarantee that new code isn't
allowed to make matters worse.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17: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 1S2mux-0005AJ-4x; Wed, 29 Feb 2012 17:02:19 +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 1S2muv-00059k-Kq
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:02:17 +0000
Received: from [85.158.139.83:37941] by server-12.bemta-5.messagelabs.com id
	ED/DF-05587-51A5E4F4; Wed, 29 Feb 2012 17:02:13 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1330534931!17196335!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19039 invoked from network); 29 Feb 2012 17:02:12 -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; 29 Feb 2012 17:02:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q1TH1k32018799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 17:01:57 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
	q1TGKwKZ001226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 16:20:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q1TGKvod012562; Wed, 29 Feb 2012 10:20:57 -0600
MIME-Version: 1.0
Message-ID: <1dff9dfa-2b66-4f82-8058-0ed5e20623ca@default>
Date: Wed, 29 Feb 2012 08:20:42 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, keir@xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020207.4F4E5A0C.0170,ss=1,re=0.000,fgs=0
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	xen-devel <xen-devel@lists.xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] "Deprecate" order>0 allocations? (was: [PATCH 1 of 2]
 Global virq for low memory situations)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Wednesday, February 29, 2012 1:54 AM
> To: Dan Magenheimer
> Cc: ian.campbell@citrix.com; ian.jackson@citrix.com; adin@gridcentric.ca; andres@gridcentric.ca;
> Andres Lagar-Cavilla; xen-devel; tim@xen.org
> Subject: RE: [Xen-devel] [PATCH 1 of 2] Global virq for low memory situations
> 
> >>> On 29.02.12 at 00:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > Or maybe Jan's recent work has eliminated all but the corner
> > cases of order>0 allocations?  (/me crosses fingers)
> 
> I'm unaware of remaining violators of this, but I'm also not constantly
> monitoring.
> 
> Jan

As various "move memory back and forth between domains"
solutions are becoming increasingly fashionable, use
of order>0 allocations remains a ticking timebomb.

Does it make sense then now to somehow "deprecate" the
code in the allocator that allows order>0 allocations?
Not quite sure how, so just brainstorming.  Some ideas:

1) At minimum, a very big comment warning about the
   silent pitfalls due to fragmentation and a WARN_ON_ONCE
   that occurs when order>1 and debug=1 (and for xen-unstable).
2) Add a new routine for order>0 allocations (with
   a WARN_ON and a big comment) and BUG_ON order>0
   allocations attempted via the old interface.

IIRC, last I heard, some of the PCI-passthrough code
still uses order>0 allocations, so this (and any
other remaining culprits) might need to be grandfathered
in somehow.

But it would be nice to guarantee that new code isn't
allowed to make matters worse.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:08:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:08:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2n0C-0005ZQ-Sy; Wed, 29 Feb 2012 17:07:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2n0B-0005Z6-Mi
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:07:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1330535257!16495999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2589 invoked from network); 29 Feb 2012 17:07:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:07:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:07:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 17:07:37 +0000
Date: Wed, 29 Feb 2012 17:14:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330103000.8557.227.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202291708410.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
	<4F476C0E.2010107@citrix.com>
	<alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
	<1330103000.8557.227.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 24 Feb 2012, Ian Campbell wrote:
> On Fri, 2012-02-24 at 14:15 +0000, Stefano Stabellini wrote:
> > On Fri, 24 Feb 2012, David Vrabel wrote:
> > > On 24/02/12 10:33, Ian Campbell wrote:
> > > > On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > > >> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> > > >> we reserve for Xen usage.
> > > > 
> > > > Does this require a trap when the guest acks or EOIs this interrupt?
> > > > What about maintenance interrupts arising from injecting this?
> > 
> > Yes, we would get a maintenance interrupt in the hypervisor every time
> > the guest EOI's it.
> 
> We really want to avoid those.

yep

> > > > Might we want to instead inject this interrupt as an SGI, so that it
> > > > appears as a per-VCPU interrupt?
> > > 
> > > I don't think it's possible to register a SGI handler in Linux
> > > currently.  The mapping of IRQ numbers to GIC interrupts skips over the
> > > SGIs.  This would be easy to fix I think.
> > 
> > A per-vcpu interrupt that doesn't require an EOI would be ideal, however
> > like David wrote, it is not possible to register an SGI handler in Linux
> > at the moment. I'll give it a look though.
> 
> Do SGIs avoid the EOI and maintenance interrupt issues though?
 
SGI (or PPI) would avoid maintenance interrupt issues if we don't ask
for any maintenance interrupts in the LR.

It is easy to determine if an event notification interrupt has already
been EOI'd by the guest just looking at the evtchn_upcall_pending bit in
the shared_info page.
Also we can safely assume that there is at most one event notification
interrupt pending at any time in any set of LR registers because we
never inject more than a single event notification interrupt in one pcpu
(see vcpu_mark_events_pending).
Therefore checking for event notification interrupts that need to be
cleaned whenever we receive a maintenance interrupt and whenever we want
to inject a new interrupt should be enough.

More details and actual code in the next patch series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:08:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:08:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2n0C-0005ZQ-Sy; Wed, 29 Feb 2012 17:07:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2n0B-0005Z6-Mi
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:07:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1330535257!16495999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2589 invoked from network); 29 Feb 2012 17:07:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:07:37 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:07:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 17:07:37 +0000
Date: Wed, 29 Feb 2012 17:14:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330103000.8557.227.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202291708410.23091@kaball-desktop>
References: <alpine.DEB.2.00.1202231817350.23091@kaball-desktop>
	<1330021293-21554-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330079609.8557.165.camel@zakaz.uk.xensource.com>
	<4F476C0E.2010107@citrix.com>
	<alpine.DEB.2.00.1202241411480.23091@kaball-desktop>
	<1330103000.8557.227.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] arm: implement
	vcpu_mark_events_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 24 Feb 2012, Ian Campbell wrote:
> On Fri, 2012-02-24 at 14:15 +0000, Stefano Stabellini wrote:
> > On Fri, 24 Feb 2012, David Vrabel wrote:
> > > On 24/02/12 10:33, Ian Campbell wrote:
> > > > On Thu, 2012-02-23 at 18:21 +0000, Stefano Stabellini wrote:
> > > >> Implement vcpu_mark_events_pending using the vgic to inject INT 63, that
> > > >> we reserve for Xen usage.
> > > > 
> > > > Does this require a trap when the guest acks or EOIs this interrupt?
> > > > What about maintenance interrupts arising from injecting this?
> > 
> > Yes, we would get a maintenance interrupt in the hypervisor every time
> > the guest EOI's it.
> 
> We really want to avoid those.

yep

> > > > Might we want to instead inject this interrupt as an SGI, so that it
> > > > appears as a per-VCPU interrupt?
> > > 
> > > I don't think it's possible to register a SGI handler in Linux
> > > currently.  The mapping of IRQ numbers to GIC interrupts skips over the
> > > SGIs.  This would be easy to fix I think.
> > 
> > A per-vcpu interrupt that doesn't require an EOI would be ideal, however
> > like David wrote, it is not possible to register an SGI handler in Linux
> > at the moment. I'll give it a look though.
> 
> Do SGIs avoid the EOI and maintenance interrupt issues though?
 
SGI (or PPI) would avoid maintenance interrupt issues if we don't ask
for any maintenance interrupts in the LR.

It is easy to determine if an event notification interrupt has already
been EOI'd by the guest just looking at the evtchn_upcall_pending bit in
the shared_info page.
Also we can safely assume that there is at most one event notification
interrupt pending at any time in any set of LR registers because we
never inject more than a single event notification interrupt in one pcpu
(see vcpu_mark_events_pending).
Therefore checking for event notification interrupts that need to be
cleaned whenever we receive a maintenance interrupt and whenever we want
to inject a new interrupt should be enough.

More details and actual code in the next patch series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:12:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:12:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2n4C-0005hx-Kg; Wed, 29 Feb 2012 17:11:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2n4B-0005hf-Hw
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:11:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330535505!16438606!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16437 invoked from network); 29 Feb 2012 17:11:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:11:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 17:11:42 +0000
Date: Wed, 29 Feb 2012 17:18:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330363330.8557.314.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202291716280.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329482789.3131.71.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
	<1330363330.8557.314.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual 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 Mon, 27 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 15:45 +0000, Stefano Stabellini wrote:
> > On Fri, 17 Feb 2012, Ian Campbell wrote:
> > > If there's only going to be one active LR then we can jut always use LR0
> > > and do away with the bitmap for the time being.
> > 
> > We have two lists: one list, inflight_irqs, is kept by the vgic to keep
> > track of which irqs the vgic has injected and have not been eoi'd by the
> > guest yet.
> 
> This means "currently live in an LR" ?

nope, that means "I want to be injected in the guest"


> > The second list, gic.lr_pending, is a list of irqs that from the vgic
> > POV have been already injected (they have been added to
> > inflight_irqs already) but because of hardware limitations
> > (limited availability of LR registers) the gic hasn't been able to
> > inject them yet.
> 
> This means "would be in an LR if there was space" ?

yes


> Is lr_pending list a superset of the inflight_irqs ones? Or are they
> always disjoint? If they are disjoint then doesn't a single list next
> pointer in struct pending_irq suffice?

inflight_irqs is a superset of lr_pending


> It would be really nice to have a comment somewhere which describes the
> purpose of these lists and what the invariants are for an entry on them.

yeah


> > Here we are going through the second list, gic.lr_pending, that is
> > ordered by priority, and we are inserting this last guest irq in the
> > right spot so that as soon as an LR register is available we can
> > actually inject it into the guest.
> > 
> > The vgic is not actually aware that the gic hasn't managed to inject the
> > irq yet.
> 
> I was just looking at applying v4 and it has:
> 
> > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> > index 3372d14..75095ff 100644
> > --- a/xen/include/asm-arm/domain.h
> > +++ b/xen/include/asm-arm/domain.h
> > @@ -21,6 +21,7 @@ struct pending_irq
> >      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
> >      uint8_t priority;
> >      struct list_head link;
> > +    struct list_head lr_link;
> 
> I think two list fields named link and lr_link need something to
> describe and/or distinguish them, their purpose etc.
> 
> The use of the name "pending" as the field in the struct is a little
> confusing, because there are multiple ways in which an interrupt can be
> pending, both in and out of an LR.
 
yes, they deserve at least a comment

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:12:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:12:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2n4C-0005hx-Kg; Wed, 29 Feb 2012 17:11:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2n4B-0005hf-Hw
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:11:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330535505!16438606!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16437 invoked from network); 29 Feb 2012 17:11:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:11:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 17:11:42 +0000
Date: Wed, 29 Feb 2012 17:18:42 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330363330.8557.314.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202291716280.23091@kaball-desktop>
References: <1329314609-31761-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1329482789.3131.71.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1202231452310.23091@kaball-desktop>
	<1330363330.8557.314.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] arm: support fewer LR registers than
	virtual 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 Mon, 27 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 15:45 +0000, Stefano Stabellini wrote:
> > On Fri, 17 Feb 2012, Ian Campbell wrote:
> > > If there's only going to be one active LR then we can jut always use LR0
> > > and do away with the bitmap for the time being.
> > 
> > We have two lists: one list, inflight_irqs, is kept by the vgic to keep
> > track of which irqs the vgic has injected and have not been eoi'd by the
> > guest yet.
> 
> This means "currently live in an LR" ?

nope, that means "I want to be injected in the guest"


> > The second list, gic.lr_pending, is a list of irqs that from the vgic
> > POV have been already injected (they have been added to
> > inflight_irqs already) but because of hardware limitations
> > (limited availability of LR registers) the gic hasn't been able to
> > inject them yet.
> 
> This means "would be in an LR if there was space" ?

yes


> Is lr_pending list a superset of the inflight_irqs ones? Or are they
> always disjoint? If they are disjoint then doesn't a single list next
> pointer in struct pending_irq suffice?

inflight_irqs is a superset of lr_pending


> It would be really nice to have a comment somewhere which describes the
> purpose of these lists and what the invariants are for an entry on them.

yeah


> > Here we are going through the second list, gic.lr_pending, that is
> > ordered by priority, and we are inserting this last guest irq in the
> > right spot so that as soon as an LR register is available we can
> > actually inject it into the guest.
> > 
> > The vgic is not actually aware that the gic hasn't managed to inject the
> > irq yet.
> 
> I was just looking at applying v4 and it has:
> 
> > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> > index 3372d14..75095ff 100644
> > --- a/xen/include/asm-arm/domain.h
> > +++ b/xen/include/asm-arm/domain.h
> > @@ -21,6 +21,7 @@ struct pending_irq
> >      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
> >      uint8_t priority;
> >      struct list_head link;
> > +    struct list_head lr_link;
> 
> I think two list fields named link and lr_link need something to
> describe and/or distinguish them, their purpose etc.
> 
> The use of the name "pending" as the field in the struct is a little
> confusing, because there are multiple ways in which an interrupt can be
> pending, both in and out of an LR.
 
yes, they deserve at least a comment

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nEE-0005yg-QA; Wed, 29 Feb 2012 17:22:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2nED-0005yb-2G
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:22:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330536127!8754332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22972 invoked from network); 29 Feb 2012 17:22:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:22:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:22:06 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 17:22:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Wed, 29 Feb 2012 17:21:17 +0000
Message-ID: <1330536077.10387.57.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all

This patch adds MSI / MSIX injection for Xen HVM guest. This is not new,
six months ago we had a discussion in
http://marc.info/?l=qemu-devel&m=130639451725966&w=2


Wei.

-------8<-----
MSI / MSIX injection for Xen.

This is supposed to be used in conjunction with Xen's
hypercall interface for emualted MSI / MSIX injection.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 hw/msi.c   |    7 ++++++-
 hw/msix.c  |    8 +++++++-
 hw/xen.h   |    1 +
 xen-all.c  |    5 +++++
 xen-stub.c |    4 ++++
 5 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/hw/msi.c b/hw/msi.c
index 5d6ceb6..b11eeac 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -20,6 +20,7 @@
 
 #include "msi.h"
 #include "range.h"
+#include "xen.h"
 
 /* Eventually those constants should go to Linux pci_regs.h */
 #define PCI_MSI_PENDING_32      0x10
@@ -257,7 +258,11 @@ void msi_notify(PCIDevice *dev, unsigned int vector)
                    "notify vector 0x%x"
                    " address: 0x%"PRIx64" data: 0x%"PRIx32"\n",
                    vector, address, data);
-    stl_le_phys(address, data);
+    if (xen_enabled()) {
+        xen_hvm_inject_msi(address, data);
+    } else {
+        stl_le_phys(address, data);
+    }
 }
 
 /* call this function after updating configs by pci_default_write_config(). */
diff --git a/hw/msix.c b/hw/msix.c
index 3835eaa..1ddd34e 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -19,6 +19,7 @@
 #include "msix.h"
 #include "pci.h"
 #include "range.h"
+#include "xen.h"
 
 #define MSIX_CAP_LENGTH 12
 
@@ -365,7 +366,12 @@ void msix_notify(PCIDevice *dev, unsigned vector)
 
     address = pci_get_quad(table_entry + PCI_MSIX_ENTRY_LOWER_ADDR);
     data = pci_get_long(table_entry + PCI_MSIX_ENTRY_DATA);
-    stl_le_phys(address, data);
+
+    if (xen_enabled()) {
+	    xen_hvm_inject_msi(address, data);
+    } else {
+	    stl_le_phys(address, data);
+    }
 }
 
 void msix_reset(PCIDevice *dev)
diff --git a/hw/xen.h b/hw/xen.h
index b46879c..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -34,6 +34,7 @@ static inline int xen_enabled(void)
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 
 qemu_irq *xen_interrupt_controller_init(void);
diff --git a/xen-all.c b/xen-all.c
index b0ed1ed..78c6df3 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -122,6 +122,11 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+}
+
 static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
diff --git a/xen-stub.c b/xen-stub.c
index 9ea02d4..8ff2b79 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -29,6 +29,10 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 {
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+}
+
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
-- 
1.7.2.5






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nEE-0005yg-QA; Wed, 29 Feb 2012 17:22:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1S2nED-0005yb-2G
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:22:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1330536127!8754332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22972 invoked from network); 29 Feb 2012 17:22:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:22:07 -0000
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="11017742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:22:06 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 17:22:06 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Wed, 29 Feb 2012 17:21:17 +0000
Message-ID: <1330536077.10387.57.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all

This patch adds MSI / MSIX injection for Xen HVM guest. This is not new,
six months ago we had a discussion in
http://marc.info/?l=qemu-devel&m=130639451725966&w=2


Wei.

-------8<-----
MSI / MSIX injection for Xen.

This is supposed to be used in conjunction with Xen's
hypercall interface for emualted MSI / MSIX injection.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 hw/msi.c   |    7 ++++++-
 hw/msix.c  |    8 +++++++-
 hw/xen.h   |    1 +
 xen-all.c  |    5 +++++
 xen-stub.c |    4 ++++
 5 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/hw/msi.c b/hw/msi.c
index 5d6ceb6..b11eeac 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -20,6 +20,7 @@
 
 #include "msi.h"
 #include "range.h"
+#include "xen.h"
 
 /* Eventually those constants should go to Linux pci_regs.h */
 #define PCI_MSI_PENDING_32      0x10
@@ -257,7 +258,11 @@ void msi_notify(PCIDevice *dev, unsigned int vector)
                    "notify vector 0x%x"
                    " address: 0x%"PRIx64" data: 0x%"PRIx32"\n",
                    vector, address, data);
-    stl_le_phys(address, data);
+    if (xen_enabled()) {
+        xen_hvm_inject_msi(address, data);
+    } else {
+        stl_le_phys(address, data);
+    }
 }
 
 /* call this function after updating configs by pci_default_write_config(). */
diff --git a/hw/msix.c b/hw/msix.c
index 3835eaa..1ddd34e 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -19,6 +19,7 @@
 #include "msix.h"
 #include "pci.h"
 #include "range.h"
+#include "xen.h"
 
 #define MSIX_CAP_LENGTH 12
 
@@ -365,7 +366,12 @@ void msix_notify(PCIDevice *dev, unsigned vector)
 
     address = pci_get_quad(table_entry + PCI_MSIX_ENTRY_LOWER_ADDR);
     data = pci_get_long(table_entry + PCI_MSIX_ENTRY_DATA);
-    stl_le_phys(address, data);
+
+    if (xen_enabled()) {
+	    xen_hvm_inject_msi(address, data);
+    } else {
+	    stl_le_phys(address, data);
+    }
 }
 
 void msix_reset(PCIDevice *dev)
diff --git a/hw/xen.h b/hw/xen.h
index b46879c..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -34,6 +34,7 @@ static inline int xen_enabled(void)
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level);
 
 qemu_irq *xen_interrupt_controller_init(void);
diff --git a/xen-all.c b/xen-all.c
index b0ed1ed..78c6df3 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -122,6 +122,11 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+    xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+}
+
 static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
     xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
diff --git a/xen-stub.c b/xen-stub.c
index 9ea02d4..8ff2b79 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -29,6 +29,10 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
 {
 }
 
+void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
+{
+}
+
 void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
 {
 }
-- 
1.7.2.5






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:26:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:26:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nHw-00066H-E8; Wed, 29 Feb 2012 17:26:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1S2nHu-000661-IP
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:26:02 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330536355!18868836!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17753 invoked from network); 29 Feb 2012 17:25:56 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-2.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 17:25:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 5C84776910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:25:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 4FCCD769114
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:25:55 +0100 (CET)
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 9j3sgll+Cj2w for <xen-devel@lists.xen.org>;
	Wed, 29 Feb 2012 18:25:36 +0100 (CET)
Received: from [10.205.1.98] (unknown [10.205.1.98])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 32BDA76910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:25:36 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xen.org
Date: Wed, 29 Feb 2012 18:25:27 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330514555.4270.52.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202291825.31160.hahn@univention.de>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4989055526077375934=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4989055526077375934==
Content-Type: multipart/signed;
  boundary="nextPart12332747.0InXCOq4L0";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart12332747.0InXCOq4L0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

just a nit:

On Wednesday 29 February 2012 12:22:35 Ian Campbell wrote:
> What I often do is create qemu-debug.sh:
> 	#!/bin/sh
> 	echo "Starting QEMU with: $*" >> /tmp/qemu-dbg.log
> 	exec /usr/lib/xen/bin/qemu-system-i386 $@

You should always put double-quotes arount the $@, otherwise the shell does=
=20
IFS-splitting on the arguments. Probably not that important in this case, b=
ut=20
since this creates nasty quoting problems in general, post "good code" for=
=20
the archive.

Sincerely
Philipp

PS: I know there are broken shell, which don't handle "$@" correct, but hey=
,=20
they're broken anyway.
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart12332747.0InXCOq4L0
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)

iEYEABECAAYFAk9OX4cACgkQYPlgoZpUDjmkeQCghu4PQq+04uAqM9rjOyt1JCAq
ql4An2jw5lkOp+uFOKTUBiElNRE+EtEI
=1Rng
-----END PGP SIGNATURE-----

--nextPart12332747.0InXCOq4L0--


--===============4989055526077375934==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4989055526077375934==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 17:26:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:26:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nHw-00066H-E8; Wed, 29 Feb 2012 17:26:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1S2nHu-000661-IP
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:26:02 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330536355!18868836!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17753 invoked from network); 29 Feb 2012 17:25:56 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-2.tower-216.messagelabs.com with SMTP;
	29 Feb 2012 17:25:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 5C84776910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:25:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 4FCCD769114
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:25:55 +0100 (CET)
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 9j3sgll+Cj2w for <xen-devel@lists.xen.org>;
	Wed, 29 Feb 2012 18:25:36 +0100 (CET)
Received: from [10.205.1.98] (unknown [10.205.1.98])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 32BDA76910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:25:36 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xen.org
Date: Wed, 29 Feb 2012 18:25:27 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330514555.4270.52.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202291825.31160.hahn@univention.de>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4989055526077375934=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4989055526077375934==
Content-Type: multipart/signed;
  boundary="nextPart12332747.0InXCOq4L0";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart12332747.0InXCOq4L0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

just a nit:

On Wednesday 29 February 2012 12:22:35 Ian Campbell wrote:
> What I often do is create qemu-debug.sh:
> 	#!/bin/sh
> 	echo "Starting QEMU with: $*" >> /tmp/qemu-dbg.log
> 	exec /usr/lib/xen/bin/qemu-system-i386 $@

You should always put double-quotes arount the $@, otherwise the shell does=
=20
IFS-splitting on the arguments. Probably not that important in this case, b=
ut=20
since this creates nasty quoting problems in general, post "good code" for=
=20
the archive.

Sincerely
Philipp

PS: I know there are broken shell, which don't handle "$@" correct, but hey=
,=20
they're broken anyway.
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart12332747.0InXCOq4L0
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)

iEYEABECAAYFAk9OX4cACgkQYPlgoZpUDjmkeQCghu4PQq+04uAqM9rjOyt1JCAq
ql4An2jw5lkOp+uFOKTUBiElNRE+EtEI
=1Rng
-----END PGP SIGNATURE-----

--nextPart12332747.0InXCOq4L0--


--===============4989055526077375934==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4989055526077375934==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 17:32:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:32:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nNb-0006H5-A3; Wed, 29 Feb 2012 17:31:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1S2nNa-0006H0-BM
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:31:54 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330536708!15531708!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1054 invoked from network); 29 Feb 2012 17:31:48 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 17:31:48 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id D3DF276910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:31:47 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id C36E8769114
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:31:47 +0100 (CET)
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 cWfaBMgkvmoa for <xen-devel@lists.xen.org>;
	Wed, 29 Feb 2012 18:31:47 +0100 (CET)
Received: from [10.205.1.98] (unknown [10.205.1.98])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 6492476910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:31:47 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xen.org
Date: Wed, 29 Feb 2012 18:31:45 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520738.4270.84.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202291831.45630.hahn@univention.de>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1632147959467780789=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1632147959467780789==
Content-Type: multipart/signed;
  boundary="nextPart1665807.Sr0N4Wdbt7";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1665807.Sr0N4Wdbt7
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

On Wednesday 29 February 2012 14:05:38 Ian Campbell wrote:
> either
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$@"
> or
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$*"
> (I can never remember which is correct)

"$@" =E2=86=92 each argument quoted by itself
"$*" =E2=86=92 all arguments concatenated by the first char of $IFS, as one=
 argument
$* =E2=86=92 all arguments splited by $IFS =E2=86=92 "lots of little garbag=
e"
$@ =E2=86=92 same as $*

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart1665807.Sr0N4Wdbt7
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)

iEYEABECAAYFAk9OYQEACgkQYPlgoZpUDjnGDgCfadGGh7mEAL2eXVQr5S4Nr6Ro
UIsAnjs1/jk5HH26RGQ6NwqlJaNOrP9q
=MhZY
-----END PGP SIGNATURE-----

--nextPart1665807.Sr0N4Wdbt7--


--===============1632147959467780789==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1632147959467780789==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 17:32:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:32:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nNb-0006H5-A3; Wed, 29 Feb 2012 17:31:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1S2nNa-0006H0-BM
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:31:54 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1330536708!15531708!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1054 invoked from network); 29 Feb 2012 17:31:48 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 17:31:48 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id D3DF276910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:31:47 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id C36E8769114
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:31:47 +0100 (CET)
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 cWfaBMgkvmoa for <xen-devel@lists.xen.org>;
	Wed, 29 Feb 2012 18:31:47 +0100 (CET)
Received: from [10.205.1.98] (unknown [10.205.1.98])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 6492476910D
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 18:31:47 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xen.org
Date: Wed, 29 Feb 2012 18:31:45 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520738.4270.84.camel@zakaz.uk.xensource.com>
In-Reply-To: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201202291831.45630.hahn@univention.de>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1632147959467780789=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1632147959467780789==
Content-Type: multipart/signed;
  boundary="nextPart1665807.Sr0N4Wdbt7";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1665807.Sr0N4Wdbt7
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

On Wednesday 29 February 2012 14:05:38 Ian Campbell wrote:
> either
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$@"
> or
> 	exec /usr/lib/xen/bin/qemu-system-i386 "$*"
> (I can never remember which is correct)

"$@" =E2=86=92 each argument quoted by itself
"$*" =E2=86=92 all arguments concatenated by the first char of $IFS, as one=
 argument
$* =E2=86=92 all arguments splited by $IFS =E2=86=92 "lots of little garbag=
e"
$@ =E2=86=92 same as $*

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart1665807.Sr0N4Wdbt7
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)

iEYEABECAAYFAk9OYQEACgkQYPlgoZpUDjnGDgCfadGGh7mEAL2eXVQr5S4Nr6Ro
UIsAnjs1/jk5HH26RGQ6NwqlJaNOrP9q
=MhZY
-----END PGP SIGNATURE-----

--nextPart1665807.Sr0N4Wdbt7--


--===============1632147959467780789==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1632147959467780789==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 17:34:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nQH-0006On-1f; Wed, 29 Feb 2012 17:34:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2nQF-0006OZ-DC
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:34:39 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330536871!15350665!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc3MDQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26646 invoked from network); 29 Feb 2012 17:34:32 -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; 29 Feb 2012 17:34: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 q1THSgrq021630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 17:34: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
	q1THQuh0023848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 17:26:56 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
	q1THQtKu000435; Wed, 29 Feb 2012 11:26:56 -0600
MIME-Version: 1.0
Message-ID: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
Date: Wed, 29 Feb 2012 09:26:41 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
In-Reply-To: <20120229104308.GA23724@aepfle.de>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F4E61A1.011C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]
> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
> 
> On Mon, Feb 27, Dan Magenheimer wrote:
> 
> > > From: Olaf Hering [mailto:olaf@aepfle.de]
> > > To me memory overcommit means swapping, which is what xenpaging does:
> > > turn the whole guest gfn range into some sort of virtual memory,
> > > transparent to the guest.
> > >
> > > xenpaging is the red emergency knob to free some host memory without
> > > caring about the actual memory constraints within the paged guests.
> >
> > Sure, but the whole point of increasing RAM in one or more guests
> > is to increase performance, and if overcommitting *always* means
> > swapping, why would anyone use it?
> 
> The usage patterns depend on the goal. As I wrote, swapping frees host
> memory so it can be used for something else, like starting yet another
> guest on the host.

OK, I suppose xenpaging by itself could be useful in a situation such as:

1) A failover occurs from machine A that has lots of RAM to machine B
   that has much less RAM, and even horribly bad performance is better
   than total service interruption.
2) All currently running VMs have been ballooned down "far enough"
   and either have no swap device or insufficiently-sized swap devices,
   Xen simply has no more free space, and horrible performance is
   acceptable.

The historical problem with "hypervisor-based-swapping" solutions such
as xenpaging is that it is impossible to ensure that "horribly bad
performance" doesn't start occurring under "normal" circumstances
specifically because (as Tim indirectly concurs below), policies
driven by heuristics and external inference (i.e. dom0 trying
to guess how much memory every domU "needs") just don't work.

As a result, VMware customers outside of some very specific domains
(domains possibly overlapping with Snowflock?) will tell you
that "memory overcommit sucks and so we turn it off".

Which is why I raised the question "why are we doing this?"...
If the answer is "Snowflock customers will benefit from it",
that's fine.  If the answer is "to handle disastrous failover
situations", that's fine too.  And I suppose if the answer is
"so that VMware can't claim to have a feature that Xen doesn't
have (even if almost nobody uses it)", I suppose that's fine too.

I'm mostly curious because I've spent the last four years
trying to solve this problem in a more intelligent way
and am wondering if the "old way" has improved, or is
still just the old way but mostly warmed over for Xen.
And, admittedly, a bit jealous because there's apparently
so much effort going into the "old way" and not toward
"a better way".

Dan

> <following pasted from earlier in thread>
> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: Pointed questions re Xen memory overcommit
> 
> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> > 3) Is there new evidence that a host-based-policy-driven memory
> > balancer works sufficiently well on one system, or for
> > multiple hosts, or for a data center?
> 
> That, I think, is an open research question.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:34:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nQH-0006On-1f; Wed, 29 Feb 2012 17:34:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2nQF-0006OZ-DC
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:34:39 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330536871!15350665!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTc3MDQz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26646 invoked from network); 29 Feb 2012 17:34:32 -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; 29 Feb 2012 17:34: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 q1THSgrq021630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 17:34: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
	q1THQuh0023848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 17:26:56 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
	q1THQtKu000435; Wed, 29 Feb 2012 11:26:56 -0600
MIME-Version: 1.0
Message-ID: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
Date: Wed, 29 Feb 2012 09:26:41 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
In-Reply-To: <20120229104308.GA23724@aepfle.de>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-CT-RefId: str=0001.0A090209.4F4E61A1.011C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]
> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
> 
> On Mon, Feb 27, Dan Magenheimer wrote:
> 
> > > From: Olaf Hering [mailto:olaf@aepfle.de]
> > > To me memory overcommit means swapping, which is what xenpaging does:
> > > turn the whole guest gfn range into some sort of virtual memory,
> > > transparent to the guest.
> > >
> > > xenpaging is the red emergency knob to free some host memory without
> > > caring about the actual memory constraints within the paged guests.
> >
> > Sure, but the whole point of increasing RAM in one or more guests
> > is to increase performance, and if overcommitting *always* means
> > swapping, why would anyone use it?
> 
> The usage patterns depend on the goal. As I wrote, swapping frees host
> memory so it can be used for something else, like starting yet another
> guest on the host.

OK, I suppose xenpaging by itself could be useful in a situation such as:

1) A failover occurs from machine A that has lots of RAM to machine B
   that has much less RAM, and even horribly bad performance is better
   than total service interruption.
2) All currently running VMs have been ballooned down "far enough"
   and either have no swap device or insufficiently-sized swap devices,
   Xen simply has no more free space, and horrible performance is
   acceptable.

The historical problem with "hypervisor-based-swapping" solutions such
as xenpaging is that it is impossible to ensure that "horribly bad
performance" doesn't start occurring under "normal" circumstances
specifically because (as Tim indirectly concurs below), policies
driven by heuristics and external inference (i.e. dom0 trying
to guess how much memory every domU "needs") just don't work.

As a result, VMware customers outside of some very specific domains
(domains possibly overlapping with Snowflock?) will tell you
that "memory overcommit sucks and so we turn it off".

Which is why I raised the question "why are we doing this?"...
If the answer is "Snowflock customers will benefit from it",
that's fine.  If the answer is "to handle disastrous failover
situations", that's fine too.  And I suppose if the answer is
"so that VMware can't claim to have a feature that Xen doesn't
have (even if almost nobody uses it)", I suppose that's fine too.

I'm mostly curious because I've spent the last four years
trying to solve this problem in a more intelligent way
and am wondering if the "old way" has improved, or is
still just the old way but mostly warmed over for Xen.
And, admittedly, a bit jealous because there's apparently
so much effort going into the "old way" and not toward
"a better way".

Dan

> <following pasted from earlier in thread>
> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: Pointed questions re Xen memory overcommit
> 
> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> > 3) Is there new evidence that a host-based-policy-driven memory
> > balancer works sufficiently well on one system, or for
> > multiple hosts, or for a data center?
> 
> That, I think, is an open research question.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:43:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nYl-0006bZ-WF; Wed, 29 Feb 2012 17:43:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2nYk-0006bU-0b
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:43:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330537399!15456863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16459 invoked from network); 29 Feb 2012 17:43:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11018502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:43:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 17:43:19 +0000
Message-ID: <1330537397.18632.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 29 Feb 2012 17:43:17 +0000
In-Reply-To: <20302.20871.593869.740250@mariner.uk.xensource.com>
References: <3c10ba854d3750750100.1330520427@dhcp-3-145.uk.xensource.com>
	<20302.20871.593869.740250@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify
 the	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 16:25 +0000, Ian Jackson wrote:
> Attilio Rao writes ("[Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify the bios to load"):
> > Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

There was a conflict between this and my "libxl: improved handling for
default values in API" series. I'm rebasing now and will repost
(probably in the morning 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 Wed Feb 29 17:43:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nYl-0006bZ-WF; Wed, 29 Feb 2012 17:43:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2nYk-0006bU-0b
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:43:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1330537399!15456863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16459 invoked from network); 29 Feb 2012 17:43:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 17:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11018502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 17:43:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 29 Feb 2012 17:43:19 +0000
Message-ID: <1330537397.18632.1.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 29 Feb 2012 17:43:17 +0000
In-Reply-To: <20302.20871.593869.740250@mariner.uk.xensource.com>
References: <3c10ba854d3750750100.1330520427@dhcp-3-145.uk.xensource.com>
	<20302.20871.593869.740250@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify
 the	bios to load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 16:25 +0000, Ian Jackson wrote:
> Attilio Rao writes ("[Xen-devel] [PATCH] [PATCH v4] Add the bios option to specify the bios to load"):
> > Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

There was a conflict between this and my "libxl: improved handling for
default values in API" series. I'm rebasing now and will repost
(probably in the morning 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 Wed Feb 29 17:48:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nd2-0006kM-Mx; Wed, 29 Feb 2012 17:47:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1S2nd1-0006k6-Rb
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:47:52 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330537665!9470798!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMzNTQyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16163 invoked from network); 29 Feb 2012 17:47:45 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:47:45 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q1THlZhS028272;
	Wed, 29 Feb 2012 18:47:35 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q1THlXk3008818;
	Wed, 29 Feb 2012 18:47:34 +0100
Message-ID: <4F4E64B5.5080900@siemens.com>
Date: Wed, 29 Feb 2012 18:47:33 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
In-Reply-To: <1330536077.10387.57.camel@leeds.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-02-29 18:21, Wei Liu wrote:
> Hi all
> 
> This patch adds MSI / MSIX injection for Xen HVM guest. This is not new,
> six months ago we had a discussion in
> http://marc.info/?l=qemu-devel&m=130639451725966&w=2

There are some coding style issues, please use checkpatch.pl.

Back then I voted against "if (xen_enabled())" as I was planning for a
msi injection hook that also Xen could use. That may change again, the
final MSI layer design is not settled yet. Therefore, no concerns from
that POV, this work takes longer. We can refactor the Xen hooks during
that run again.

However, you know that you miss those (uncommon) messages that are
injected via DMA? They end up directly in apic_deliver_msi (where KVM
will once pick them up as well).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:48:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nd2-0006kM-Mx; Wed, 29 Feb 2012 17:47:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1S2nd1-0006k6-Rb
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 17:47:52 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1330537665!9470798!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMzNTQyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16163 invoked from network); 29 Feb 2012 17:47:45 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:47:45 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q1THlZhS028272;
	Wed, 29 Feb 2012 18:47:35 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q1THlXk3008818;
	Wed, 29 Feb 2012 18:47:34 +0100
Message-ID: <4F4E64B5.5080900@siemens.com>
Date: Wed, 29 Feb 2012 18:47:33 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de;
	rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12
	Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1330536077.10387.57.camel@leeds.uk.xensource.com>
In-Reply-To: <1330536077.10387.57.camel@leeds.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] MSI / MSIX injection for Xen HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-02-29 18:21, Wei Liu wrote:
> Hi all
> 
> This patch adds MSI / MSIX injection for Xen HVM guest. This is not new,
> six months ago we had a discussion in
> http://marc.info/?l=qemu-devel&m=130639451725966&w=2

There are some coding style issues, please use checkpatch.pl.

Back then I voted against "if (xen_enabled())" as I was planning for a
msi injection hook that also Xen could use. That may change again, the
final MSI layer design is not settled yet. Therefore, no concerns from
that POV, this work takes longer. We can refactor the Xen hooks during
that run again.

However, you know that you miss those (uncommon) messages that are
injected via DMA? They end up directly in apic_deliver_msi (where KVM
will once pick them up as well).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nfa-0006sn-R2; Wed, 29 Feb 2012 17:50:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfZ-0006sR-8D
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330537820!10375438!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25583 invoked from network); 29 Feb 2012 17:50:22 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 17:50:22 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnuCa019361; Wed, 29 Feb 2012 09:49:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnugP019358;
	Wed, 29 Feb 2012 09:49:56 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:49 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3 RESEND V5] libxl: refactor suspend/resume
	code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nfa-0006sn-R2; Wed, 29 Feb 2012 17:50:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfZ-0006sR-8D
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-174.messagelabs.com!1330537820!10375438!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25583 invoked from network); 29 Feb 2012 17:50:22 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 17:50:22 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnuCa019361; Wed, 29 Feb 2012 09:49:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnugP019358;
	Wed, 29 Feb 2012 09:49:56 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:49 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3 RESEND V5] libxl: refactor suspend/resume
	code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nfa-0006sg-Fs; Wed, 29 Feb 2012 17:50:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfZ-0006sS-2T
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330537766!51377100!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31544 invoked from network); 29 Feb 2012 17:49:28 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:49:28 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnuV3019375; Wed, 29 Feb 2012 09:49:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnuMj019372;
	Wed, 29 Feb 2012 09:49:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: d2c0bd5c1b414465b1a370f89caceaa7ee6a8ba2
Message-Id: <d2c0bd5c1b414465b1a3.1330537371@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:51 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3 RESEND V5] libxl: support suspend_cancel
	in	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1330534776 28800
# Node ID d2c0bd5c1b414465b1a370f89caceaa7ee6a8ba2
# Parent  c6514dac062bdb033b94ab8f850006a4cb90efab
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c6514dac062b -r d2c0bd5c1b41 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 29 08:58:40 2012 -0800
+++ b/tools/libxl/libxl.c	Wed Feb 29 08:59:36 2012 -0800
@@ -298,24 +298,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r c6514dac062b -r d2c0bd5c1b41 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 29 08:58:40 2012 -0800
+++ b/tools/libxl/libxl.h	Wed Feb 29 08:59:36 2012 -0800
@@ -325,7 +325,12 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+
+/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
+ *   If this parameter is true, use co-operative resume. The guest
+ *   must support this.
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r c6514dac062b -r d2c0bd5c1b41 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:58:40 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:59:36 2012 -0800
@@ -2820,7 +2820,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 0);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2842,7 +2842,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 0);
     exit(-ERROR_FAIL);
 
  failed_badly:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nfa-0006sg-Fs; Wed, 29 Feb 2012 17:50:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfZ-0006sS-2T
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:29 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-27.messagelabs.com!1330537766!51377100!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31544 invoked from network); 29 Feb 2012 17:49:28 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:49:28 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnuV3019375; Wed, 29 Feb 2012 09:49:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnuMj019372;
	Wed, 29 Feb 2012 09:49:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: d2c0bd5c1b414465b1a370f89caceaa7ee6a8ba2
Message-Id: <d2c0bd5c1b414465b1a3.1330537371@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:51 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3 RESEND V5] libxl: support suspend_cancel
	in	domain_resume
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1330534776 28800
# Node ID d2c0bd5c1b414465b1a370f89caceaa7ee6a8ba2
# Parent  c6514dac062bdb033b94ab8f850006a4cb90efab
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c6514dac062b -r d2c0bd5c1b41 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Feb 29 08:58:40 2012 -0800
+++ b/tools/libxl/libxl.c	Wed Feb 29 08:59:36 2012 -0800
@@ -298,24 +298,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, suspend_cancel)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r c6514dac062b -r d2c0bd5c1b41 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 29 08:58:40 2012 -0800
+++ b/tools/libxl/libxl.h	Wed Feb 29 08:59:36 2012 -0800
@@ -325,7 +325,12 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+
+/* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
+ *   If this parameter is true, use co-operative resume. The guest
+ *   must support this.
+ */
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r c6514dac062b -r d2c0bd5c1b41 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:58:40 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:59:36 2012 -0800
@@ -2820,7 +2820,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 0);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2842,7 +2842,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 0);
     exit(-ERROR_FAIL);
 
  failed_badly:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nfd-0006t7-6t; Wed, 29 Feb 2012 17:50:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfb-0006sT-FJ
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:31 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330537823!17063380!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28945 invoked from network); 29 Feb 2012 17:50:24 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:50:24 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnvOl019382; Wed, 29 Feb 2012 09:49:57 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnvnt019379;
	Wed, 29 Feb 2012 09:49:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: b3faa2880bd3d05d0d515287f21597ac830bd13e
Message-Id: <b3faa2880bd3d05d0d51.1330537372@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:52 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3 RESEND V5] libxl: refactor migrate_domain
	and generalize	migrate_receive
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1330534783 28800
# Node ID b3faa2880bd3d05d0d515287f21597ac830bd13e
# Parent  d2c0bd5c1b414465b1a370f89caceaa7ee6a8ba2
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d2c0bd5c1b41 -r b3faa2880bd3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:59:36 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:59:43 2012 -0800
@@ -2600,6 +2600,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2685,53 +2722,17 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
+                                uint8_t *config_data, int config_len,
+                                const char *rune)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
-    uint8_t *config_data;
-    int config_len;
-
-    save_domain_core_begin(domain_spec, override_config_file,
-                           &config_data, &config_len);
-
-    if (!config_len) {
-        fprintf(stderr, "No config file stored for running domain and "
-                "none supplied - cannot migrate.\n");
+    int rc = 0;
+
+    if (send_fd < 0 || recv_fd < 0) {
+        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
     rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
@@ -2744,6 +2745,34 @@ static void migrate_domain(const char *d
     save_domain_core_writeconfig(send_fd, "migration stream",
                                  config_data, config_len);
 
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    pid_t child = -1;
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    uint8_t *config_data;
+    int config_len;
+
+    save_domain_core_begin(domain_spec, override_config_file,
+                           &config_data, &config_len);
+
+    if (!config_len) {
+        fprintf(stderr, "No config file stored for running domain and "
+                "none supplied - cannot migrate.\n");
+        exit(1);
+    }
+
+    child = create_migration_child(rune, &send_fd, &recv_fd);
+
+    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                        rune);
+
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2867,7 +2896,8 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2879,7 +2909,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2891,7 +2921,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2905,13 +2935,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2930,7 +2960,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2938,7 +2968,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2956,7 +2986,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -3052,7 +3082,9 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    STDOUT_FILENO, STDIN_FILENO);
+
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nfd-0006t7-6t; Wed, 29 Feb 2012 17:50:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfb-0006sT-FJ
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:31 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-9.tower-216.messagelabs.com!1330537823!17063380!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28945 invoked from network); 29 Feb 2012 17:50:24 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:50:24 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnvOl019382; Wed, 29 Feb 2012 09:49:57 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnvnt019379;
	Wed, 29 Feb 2012 09:49:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: b3faa2880bd3d05d0d515287f21597ac830bd13e
Message-Id: <b3faa2880bd3d05d0d51.1330537372@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:52 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3 RESEND V5] libxl: refactor migrate_domain
	and generalize	migrate_receive
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1330534783 28800
# Node ID b3faa2880bd3d05d0d515287f21597ac830bd13e
# Parent  d2c0bd5c1b414465b1a370f89caceaa7ee6a8ba2
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d2c0bd5c1b41 -r b3faa2880bd3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:59:36 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 29 08:59:43 2012 -0800
@@ -2600,6 +2600,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2685,53 +2722,17 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+static void migrate_do_preamble(int send_fd, int recv_fd, pid_t child,
+                                uint8_t *config_data, int config_len,
+                                const char *rune)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
-    uint8_t *config_data;
-    int config_len;
-
-    save_domain_core_begin(domain_spec, override_config_file,
-                           &config_data, &config_len);
-
-    if (!config_len) {
-        fprintf(stderr, "No config file stored for running domain and "
-                "none supplied - cannot migrate.\n");
+    int rc = 0;
+
+    if (send_fd < 0 || recv_fd < 0) {
+        fprintf(stderr, "migrate_do_preamble: invalid file descriptors\n");
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
     rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
@@ -2744,6 +2745,34 @@ static void migrate_domain(const char *d
     save_domain_core_writeconfig(send_fd, "migration stream",
                                  config_data, config_len);
 
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    pid_t child = -1;
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    uint8_t *config_data;
+    int config_len;
+
+    save_domain_core_begin(domain_spec, override_config_file,
+                           &config_data, &config_len);
+
+    if (!config_len) {
+        fprintf(stderr, "No config file stored for running domain and "
+                "none supplied - cannot migrate.\n");
+        exit(1);
+    }
+
+    child = create_migration_child(rune, &send_fd, &recv_fd);
+
+    migrate_do_preamble(send_fd, recv_fd, child, config_data, config_len,
+                        rune);
+
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2867,7 +2896,8 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2879,7 +2909,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2891,7 +2921,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2905,13 +2935,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2930,7 +2960,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2938,7 +2968,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2956,7 +2986,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -3052,7 +3082,9 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    STDOUT_FILENO, STDIN_FILENO);
+
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 17:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17: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 1S2nfl-0006uz-Oj; Wed, 29 Feb 2012 17:50:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfk-0006uY-PG
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:41 +0000
Received: from [85.158.139.83:17774] by server-3.bemta-5.messagelabs.com id
	93/0D-25237-0756E4F4; Wed, 29 Feb 2012 17:50:40 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-182.messagelabs.com!1330537822!14569634!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8516 invoked from network); 29 Feb 2012 17:50:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:50:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnuD4019368; Wed, 29 Feb 2012 09:49:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnubf019365;
	Wed, 29 Feb 2012 09:49:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: c6514dac062bdb033b94ab8f850006a4cb90efab
Message-Id: <c6514dac062bdb033b94.1330537370@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:50 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3 RESEND V5] libxl: QMP stop/resume &
	refactor QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1330534720 28800
# Node ID c6514dac062bdb033b94ab8f850006a4cb90efab
# Parent  8b40decde52bd2e52897e78b5eddeef1509bbf4e
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8b40decde52b -r c6514dac062b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 29 08:33:10 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Wed Feb 29 08:58:40 2012 -0800
@@ -516,6 +516,54 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        /* Save DM state into filename */
+        ret = libxl__qmp_save(gc, domid, filename);
+        if (ret)
+            unlink(filename);
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        libxl__wait_for_device_model(gc, domid, "running", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -545,7 +593,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto guest_suspended;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -623,7 +671,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto guest_suspended;
             }
         }
 
@@ -632,6 +680,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ guest_suspended:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
@@ -796,23 +855,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        ret = libxl__qmp_save(gc, domid, (char *)filename);
-        if (ret)
-            goto out;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 8b40decde52b -r c6514dac062b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Feb 29 08:33:10 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Wed Feb 29 08:58:40 2012 -0800
@@ -633,6 +633,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -1004,6 +1006,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_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);
 /* close and free the QMP handler */
diff -r 8b40decde52b -r c6514dac062b tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Wed Feb 29 08:33:10 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Wed Feb 29 08:58:40 2012 -0800
@@ -827,6 +827,38 @@ static int qmp_change(libxl__gc *gc, lib
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    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 Wed Feb 29 17:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 17: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 1S2nfl-0006uz-Oj; Wed, 29 Feb 2012 17:50:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nfk-0006uY-PG
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 17:50:41 +0000
Received: from [85.158.139.83:17774] by server-3.bemta-5.messagelabs.com id
	93/0D-25237-0756E4F4; Wed, 29 Feb 2012 17:50:40 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-182.messagelabs.com!1330537822!14569634!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8516 invoked from network); 29 Feb 2012 17:50:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 17:50:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q1THnuD4019368; Wed, 29 Feb 2012 09:49:56 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q1THnubf019365;
	Wed, 29 Feb 2012 09:49:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: c6514dac062bdb033b94ab8f850006a4cb90efab
Message-Id: <c6514dac062bdb033b94.1330537370@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Wed, 29 Feb 2012 09:42:50 -0800
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
To: xen-devel@lists.xen.org
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3 RESEND V5] libxl: QMP stop/resume &
	refactor QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1330534720 28800
# Node ID c6514dac062bdb033b94ab8f850006a4cb90efab
# Parent  8b40decde52bd2e52897e78b5eddeef1509bbf4e
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8b40decde52b -r c6514dac062b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 29 08:33:10 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Wed Feb 29 08:58:40 2012 -0800
@@ -516,6 +516,54 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        /* Save DM state into filename */
+        ret = libxl__qmp_save(gc, domid, filename);
+        if (ret)
+            unlink(filename);
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        libxl__wait_for_device_model(gc, domid, "running", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -545,7 +593,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto guest_suspended;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -623,7 +671,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto guest_suspended;
             }
         }
 
@@ -632,6 +680,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ guest_suspended:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
@@ -796,23 +855,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        ret = libxl__qmp_save(gc, domid, (char *)filename);
-        if (ret)
-            goto out;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 8b40decde52b -r c6514dac062b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Feb 29 08:33:10 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Wed Feb 29 08:58:40 2012 -0800
@@ -633,6 +633,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -1004,6 +1006,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_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);
 /* close and free the QMP handler */
diff -r 8b40decde52b -r c6514dac062b tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Wed Feb 29 08:33:10 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Wed Feb 29 08:58:40 2012 -0800
@@ -827,6 +827,38 @@ static int qmp_change(libxl__gc *gc, lib
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    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 Wed Feb 29 18:01:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2npo-0007ae-T7; Wed, 29 Feb 2012 18:01:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2npm-0007aZ-Sc
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:01:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330538454!15353815!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ5MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23492 invoked from network); 29 Feb 2012 18:00:55 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 18:00:55 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1B994300061;
	Wed, 29 Feb 2012 10:00:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=CXPrJZyufwtlD6T9ohJEO6Q6P6kzgZ/ifsY+mkuN0qWT
	zqj8gaK8cmHgebDhnU+VxesRPXbT9FG1Xwe62aWHBpyJs+ArXfapayocSbAG6f6M
	aEXb/SVcL5nlWtBDpx273Ff+Fyi0NAZUbrFA8qzNKstS3bbiP0JGzsbY56Sm7aw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=qWvUdMb0+K9QdSZhEMJnWIfioGU=; b=HM9LRmUn
	QeAq6jKG1OQmyvmcos0B4bL6EpdS9GRLsL7/lZGR3Bz0bxM1Ryjn46/3VrwiFxkU
	Sf7EvWymx4VO4E58/TgIPQUWGacUDqjUFB3ObEddqJgO209S3kPqphVARipwPpds
	1bKibgRy7J0JGyu8FzrKgcizCDAUlIDOrPo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id D9683300059; 
	Wed, 29 Feb 2012 10:00:51 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 29 Feb 2012 10:00:53 -0800
Message-ID: <ccacbfbb75a2413727f98f49af7e226c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
Date: Wed, 29 Feb 2012 10:00:53 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> From: Olaf Hering [mailto:olaf@aepfle.de]
>> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
>>
>> On Mon, Feb 27, Dan Magenheimer wrote:
>>
>> > > From: Olaf Hering [mailto:olaf@aepfle.de]
>> > > To me memory overcommit means swapping, which is what xenpaging
>> does:
>> > > turn the whole guest gfn range into some sort of virtual memory,
>> > > transparent to the guest.
>> > >
>> > > xenpaging is the red emergency knob to free some host memory without
>> > > caring about the actual memory constraints within the paged guests.
>> >
>> > Sure, but the whole point of increasing RAM in one or more guests
>> > is to increase performance, and if overcommitting *always* means
>> > swapping, why would anyone use it?
>>
>> The usage patterns depend on the goal. As I wrote, swapping frees host
>> memory so it can be used for something else, like starting yet another
>> guest on the host.
>
> OK, I suppose xenpaging by itself could be useful in a situation such as:
>
> 1) A failover occurs from machine A that has lots of RAM to machine B
>    that has much less RAM, and even horribly bad performance is better
>    than total service interruption.
> 2) All currently running VMs have been ballooned down "far enough"
>    and either have no swap device or insufficiently-sized swap devices,
>    Xen simply has no more free space, and horrible performance is
>    acceptable.
>
> The historical problem with "hypervisor-based-swapping" solutions such
> as xenpaging is that it is impossible to ensure that "horribly bad
> performance" doesn't start occurring under "normal" circumstances
> specifically because (as Tim indirectly concurs below), policies
> driven by heuristics and external inference (i.e. dom0 trying
> to guess how much memory every domU "needs") just don't work.
>
> As a result, VMware customers outside of some very specific domains
> (domains possibly overlapping with Snowflock?) will tell you
> that "memory overcommit sucks and so we turn it off".
>
> Which is why I raised the question "why are we doing this?"...
> If the answer is "Snowflock customers will benefit from it",

How come SnowFlock crept in here? :)

I can unequivocally assert there is no such thing as "SnowFlock customers".

You have to keep in mind that paging is 1. not bad to have and 2. powerful
and generic, and 3. a far more generic mechanism to populating on demand,
than what is labeled in the hypervisor as "populate-on-demand".

Re 2. you could implement a balloon using a pager -- or you could
implement a version of ramster by putting the page file on a fuse fs with
compression turned on. Not that you would want to, just to prove a point.

And re 3. not that there's anything wrong with PoD, but it has several
assumptions baked in about being a temporary balloon replacement. I
predict that once 32 bit hypervisor and shadow mode are phased out, PoD
will also go away, as it will be a "simple" sub-case of paging.

Olaf Hering from SuSe invested significant time and effort in getting
paging to where it is, so you also have to add to the list whatever
his/their motivations are.

Andres

> that's fine.  If the answer is "to handle disastrous failover
> situations", that's fine too.  And I suppose if the answer is
> "so that VMware can't claim to have a feature that Xen doesn't
> have (even if almost nobody uses it)", I suppose that's fine too.
>
> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".
>
> Dan
>
>> <following pasted from earlier in thread>
>> From: Tim Deegan [mailto:tim@xen.org]
>> Subject: Re: Pointed questions re Xen memory overcommit
>>
>> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
>> > 3) Is there new evidence that a host-based-policy-driven memory
>> > balancer works sufficiently well on one system, or for
>> > multiple hosts, or for a data center?
>>
>> That, I think, is an open research question.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:01:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2npo-0007ae-T7; Wed, 29 Feb 2012 18:01:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1S2npm-0007aZ-Sc
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:01:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1330538454!15353815!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ5MjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23492 invoked from network); 29 Feb 2012 18:00:55 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-16.tower-174.messagelabs.com with SMTP;
	29 Feb 2012 18:00:55 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1B994300061;
	Wed, 29 Feb 2012 10:00:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=CXPrJZyufwtlD6T9ohJEO6Q6P6kzgZ/ifsY+mkuN0qWT
	zqj8gaK8cmHgebDhnU+VxesRPXbT9FG1Xwe62aWHBpyJs+ArXfapayocSbAG6f6M
	aEXb/SVcL5nlWtBDpx273Ff+Fyi0NAZUbrFA8qzNKstS3bbiP0JGzsbY56Sm7aw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=qWvUdMb0+K9QdSZhEMJnWIfioGU=; b=HM9LRmUn
	QeAq6jKG1OQmyvmcos0B4bL6EpdS9GRLsL7/lZGR3Bz0bxM1Ryjn46/3VrwiFxkU
	Sf7EvWymx4VO4E58/TgIPQUWGacUDqjUFB3ObEddqJgO209S3kPqphVARipwPpds
	1bKibgRy7J0JGyu8FzrKgcizCDAUlIDOrPo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id D9683300059; 
	Wed, 29 Feb 2012 10:00:51 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 29 Feb 2012 10:00:53 -0800
Message-ID: <ccacbfbb75a2413727f98f49af7e226c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
Date: Wed, 29 Feb 2012 10:00:53 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> From: Olaf Hering [mailto:olaf@aepfle.de]
>> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
>>
>> On Mon, Feb 27, Dan Magenheimer wrote:
>>
>> > > From: Olaf Hering [mailto:olaf@aepfle.de]
>> > > To me memory overcommit means swapping, which is what xenpaging
>> does:
>> > > turn the whole guest gfn range into some sort of virtual memory,
>> > > transparent to the guest.
>> > >
>> > > xenpaging is the red emergency knob to free some host memory without
>> > > caring about the actual memory constraints within the paged guests.
>> >
>> > Sure, but the whole point of increasing RAM in one or more guests
>> > is to increase performance, and if overcommitting *always* means
>> > swapping, why would anyone use it?
>>
>> The usage patterns depend on the goal. As I wrote, swapping frees host
>> memory so it can be used for something else, like starting yet another
>> guest on the host.
>
> OK, I suppose xenpaging by itself could be useful in a situation such as:
>
> 1) A failover occurs from machine A that has lots of RAM to machine B
>    that has much less RAM, and even horribly bad performance is better
>    than total service interruption.
> 2) All currently running VMs have been ballooned down "far enough"
>    and either have no swap device or insufficiently-sized swap devices,
>    Xen simply has no more free space, and horrible performance is
>    acceptable.
>
> The historical problem with "hypervisor-based-swapping" solutions such
> as xenpaging is that it is impossible to ensure that "horribly bad
> performance" doesn't start occurring under "normal" circumstances
> specifically because (as Tim indirectly concurs below), policies
> driven by heuristics and external inference (i.e. dom0 trying
> to guess how much memory every domU "needs") just don't work.
>
> As a result, VMware customers outside of some very specific domains
> (domains possibly overlapping with Snowflock?) will tell you
> that "memory overcommit sucks and so we turn it off".
>
> Which is why I raised the question "why are we doing this?"...
> If the answer is "Snowflock customers will benefit from it",

How come SnowFlock crept in here? :)

I can unequivocally assert there is no such thing as "SnowFlock customers".

You have to keep in mind that paging is 1. not bad to have and 2. powerful
and generic, and 3. a far more generic mechanism to populating on demand,
than what is labeled in the hypervisor as "populate-on-demand".

Re 2. you could implement a balloon using a pager -- or you could
implement a version of ramster by putting the page file on a fuse fs with
compression turned on. Not that you would want to, just to prove a point.

And re 3. not that there's anything wrong with PoD, but it has several
assumptions baked in about being a temporary balloon replacement. I
predict that once 32 bit hypervisor and shadow mode are phased out, PoD
will also go away, as it will be a "simple" sub-case of paging.

Olaf Hering from SuSe invested significant time and effort in getting
paging to where it is, so you also have to add to the list whatever
his/their motivations are.

Andres

> that's fine.  If the answer is "to handle disastrous failover
> situations", that's fine too.  And I suppose if the answer is
> "so that VMware can't claim to have a feature that Xen doesn't
> have (even if almost nobody uses it)", I suppose that's fine too.
>
> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".
>
> Dan
>
>> <following pasted from earlier in thread>
>> From: Tim Deegan [mailto:tim@xen.org]
>> Subject: Re: Pointed questions re Xen memory overcommit
>>
>> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
>> > 3) Is there new evidence that a host-based-policy-driven memory
>> > balancer works sufficiently well on one system, or for
>> > multiple hosts, or for a data center?
>>
>> That, I think, is an open research question.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:06:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nut-0007k2-M5; Wed, 29 Feb 2012 18:06:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nus-0007jr-Kq
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 18:06:18 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330538769!16446241!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5746 invoked from network); 29 Feb 2012 18:06:11 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 18:06:11 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1TI66pC029273
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 10:06:07 -0800
Received: by bkcjg9 with SMTP id jg9so3919377bkc.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 10:06:05 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.156.204 as permitted sender) client-ip=10.204.156.204; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.156.204 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.156.204])
	by 10.204.156.204 with SMTP id y12mr726266bkw.113.1330538765369
	(num_hops = 1); Wed, 29 Feb 2012 10:06:05 -0800 (PST)
Received: by 10.204.156.204 with SMTP id y12mr593501bkw.113.1330538765289;
	Wed, 29 Feb 2012 10:06:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.44.6 with HTTP; Wed, 29 Feb 2012 10:05:25 -0800 (PST)
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 29 Feb 2012 10:05:25 -0800
Message-ID: <CAP8mzPPdBWPmjJycKxGqxBRvNPmh6zo6XmZuVW4ejsxfxVEwRg@mail.gmail.com>
To: ian.jackson@eu.citrix.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3 RESEND V5] libxl: refactor
 suspend/resume code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4202338337480840982=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4202338337480840982==
Content-Type: multipart/alternative; boundary=0015175cb9d677085204ba1e325a

--0015175cb9d677085204ba1e325a
Content-Type: text/plain; charset=ISO-8859-1

Sorry for the empty preamble. something got messed up and one of the
patches also
didnt make it! Unfortunately, I forgot to include the last patch

"libxl: resume instead of unpause on xl save -c" in this series.
(message id: c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca )
It remains the same.

Ian, could you please include that, when you commit this series ?

Intro message:
------

This patch series refactors the suspend/resume code to minimize
Remus specific code in libxl. There are a couple of trivial bug
fixes too.

Changes in V5:
 This series is just a resend, rebasing the patches to the latest tip. It
depends on
 Stefano's "V5: libxl: save/restore qemu physmap".

Changes in V4:
1. Incorporated Ian Campbell's comments on the suspend_cancel support patch.


Changes in V3:

1. rebase patches based on Stefano's patches
  use qmp_save instead of qmp_migrate
2. check if qemu moves to "running" state after resuming the device model
3. Moved comments on the co-operative suspend to libxl.h


Changes in V2:
1. migrate code is refactored as save_config , create child,
  do_preamble instead of coaelscing them all into one single
  function.
2. More documentation for suspend_cancel parameter in domain_resume
3. Minor nits

shriram

--0015175cb9d677085204ba1e325a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry for the empty preamble. something got messed up and one of the patche=
s also<br>didnt make it! Unfortunately, I forgot to include the last patch<=
br><br>&quot;libxl: resume instead of unpause on xl save -c&quot; in this s=
eries.<br>

(message id: <a href=3D"mailto:c7abecc14cceb1814033.1328251802@athos.nss.cs=
.ubc.ca">c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca</a> )<br>It re=
mains the same.<br><br>Ian, could you please include that, when you commit =
this series ?<br>

<br>Intro message:<br>------<br><br>This patch series refactors the suspend=
/resume code to minimize<br>
Remus specific code in libxl. There are a couple of trivial bug<br>
fixes too.<br>

<br>Changes in V5:<br>=A0This series is just a resend, rebasing the patches=
 to the latest tip. It depends on <br>=A0Stefano&#39;s &quot;V5: libxl: sav=
e/restore qemu physmap&quot;.<br><br>Changes in V4:<br>1. Incorporated Ian =
Campbell&#39;s comments on the suspend_cancel support patch.<br>


<br><br>Changes in V3:<br>
<br>
1. rebase patches based on Stefano&#39;s patches<br>
 =A0 use qmp_save instead of qmp_migrate<br>
2. check if qemu moves to &quot;running&quot; state after resuming the devi=
ce model<br>
3. Moved comments on the co-operative suspend to libxl.h<br>
<br>
<br>
Changes in V2:<br>
1. migrate code is refactored as save_config , create child,<br>
 =A0 do_preamble instead of coaelscing them all into one single<br>
 =A0 function.<br>
2. More documentation for suspend_cancel parameter in domain_resume<br>
3. Minor nits<br>
<br>
shriram<br><br>

--0015175cb9d677085204ba1e325a--


--===============4202338337480840982==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4202338337480840982==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 18:06:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2nut-0007k2-M5; Wed, 29 Feb 2012 18:06:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1S2nus-0007jr-Kq
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 18:06:18 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330538769!16446241!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5746 invoked from network); 29 Feb 2012 18:06:11 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Feb 2012 18:06:11 -0000
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com
	[209.85.214.45]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q1TI66pC029273
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 10:06:07 -0800
Received: by bkcjg9 with SMTP id jg9so3919377bkc.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 10:06:05 -0800 (PST)
Received-SPF: pass (google.com: domain of rshriram@cs.ubc.ca designates
	10.204.156.204 as permitted sender) client-ip=10.204.156.204; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of rshriram@cs.ubc.ca
	designates 10.204.156.204 as permitted sender)
	smtp.mail=rshriram@cs.ubc.ca
Received: from mr.google.com ([10.204.156.204])
	by 10.204.156.204 with SMTP id y12mr726266bkw.113.1330538765369
	(num_hops = 1); Wed, 29 Feb 2012 10:06:05 -0800 (PST)
Received: by 10.204.156.204 with SMTP id y12mr593501bkw.113.1330538765289;
	Wed, 29 Feb 2012 10:06:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.44.6 with HTTP; Wed, 29 Feb 2012 10:05:25 -0800 (PST)
In-Reply-To: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
References: <patchbomb.1330537369@athos.nss.cs.ubc.ca>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 29 Feb 2012 10:05:25 -0800
Message-ID: <CAP8mzPPdBWPmjJycKxGqxBRvNPmh6zo6XmZuVW4ejsxfxVEwRg@mail.gmail.com>
To: ian.jackson@eu.citrix.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 3 RESEND V5] libxl: refactor
 suspend/resume code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4202338337480840982=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4202338337480840982==
Content-Type: multipart/alternative; boundary=0015175cb9d677085204ba1e325a

--0015175cb9d677085204ba1e325a
Content-Type: text/plain; charset=ISO-8859-1

Sorry for the empty preamble. something got messed up and one of the
patches also
didnt make it! Unfortunately, I forgot to include the last patch

"libxl: resume instead of unpause on xl save -c" in this series.
(message id: c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca )
It remains the same.

Ian, could you please include that, when you commit this series ?

Intro message:
------

This patch series refactors the suspend/resume code to minimize
Remus specific code in libxl. There are a couple of trivial bug
fixes too.

Changes in V5:
 This series is just a resend, rebasing the patches to the latest tip. It
depends on
 Stefano's "V5: libxl: save/restore qemu physmap".

Changes in V4:
1. Incorporated Ian Campbell's comments on the suspend_cancel support patch.


Changes in V3:

1. rebase patches based on Stefano's patches
  use qmp_save instead of qmp_migrate
2. check if qemu moves to "running" state after resuming the device model
3. Moved comments on the co-operative suspend to libxl.h


Changes in V2:
1. migrate code is refactored as save_config , create child,
  do_preamble instead of coaelscing them all into one single
  function.
2. More documentation for suspend_cancel parameter in domain_resume
3. Minor nits

shriram

--0015175cb9d677085204ba1e325a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry for the empty preamble. something got messed up and one of the patche=
s also<br>didnt make it! Unfortunately, I forgot to include the last patch<=
br><br>&quot;libxl: resume instead of unpause on xl save -c&quot; in this s=
eries.<br>

(message id: <a href=3D"mailto:c7abecc14cceb1814033.1328251802@athos.nss.cs=
.ubc.ca">c7abecc14cceb1814033.1328251802@athos.nss.cs.ubc.ca</a> )<br>It re=
mains the same.<br><br>Ian, could you please include that, when you commit =
this series ?<br>

<br>Intro message:<br>------<br><br>This patch series refactors the suspend=
/resume code to minimize<br>
Remus specific code in libxl. There are a couple of trivial bug<br>
fixes too.<br>

<br>Changes in V5:<br>=A0This series is just a resend, rebasing the patches=
 to the latest tip. It depends on <br>=A0Stefano&#39;s &quot;V5: libxl: sav=
e/restore qemu physmap&quot;.<br><br>Changes in V4:<br>1. Incorporated Ian =
Campbell&#39;s comments on the suspend_cancel support patch.<br>


<br><br>Changes in V3:<br>
<br>
1. rebase patches based on Stefano&#39;s patches<br>
 =A0 use qmp_save instead of qmp_migrate<br>
2. check if qemu moves to &quot;running&quot; state after resuming the devi=
ce model<br>
3. Moved comments on the co-operative suspend to libxl.h<br>
<br>
<br>
Changes in V2:<br>
1. migrate code is refactored as save_config , create child,<br>
 =A0 do_preamble instead of coaelscing them all into one single<br>
 =A0 function.<br>
2. More documentation for suspend_cancel parameter in domain_resume<br>
3. Minor nits<br>
<br>
shriram<br><br>

--0015175cb9d677085204ba1e325a--


--===============4202338337480840982==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4202338337480840982==--


From xen-devel-bounces@lists.xen.org Wed Feb 29 18:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18: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 1S2o1t-0007vS-I8; Wed, 29 Feb 2012 18:13:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1S2o1s-0007vN-2Y
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 18:13:32 +0000
Received: from [193.109.254.147:61854] by server-8.bemta-14.messagelabs.com id
	B4/B6-04087-BCA6E4F4; Wed, 29 Feb 2012 18:13:31 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330539157!62733977!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21933 invoked from network); 29 Feb 2012 18:12:38 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 18:12:38 -0000
Received: by ggnj2 with SMTP id j2so1944758ggn.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 10:13:29 -0800 (PST)
Received-SPF: pass (google.com: domain of thunderbird2k@gmail.com designates
	10.236.170.163 as permitted sender) client-ip=10.236.170.163; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	thunderbird2k@gmail.com designates 10.236.170.163 as permitted
	sender) smtp.mail=thunderbird2k@gmail.com;
	dkim=pass header.i=thunderbird2k@gmail.com
Received: from mr.google.com ([10.236.170.163])
	by 10.236.170.163 with SMTP id p23mr2144588yhl.36.1330539209267
	(num_hops = 1); Wed, 29 Feb 2012 10:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=aWIXKlZAfs1BQX/7i5/tHxFw1mpaafOBsK/G7Q6qOVM=;
	b=TOv5FG5KueORZRktN7lZfhumwqzvMx41WfiPIp6n64Z9gT64qQ6ha2BYMdpk/6QiNE
	ODgmTgyayxxmm2P4mw1B6xI9bKu3OCKwXm0vw6eHpFE0T2MSriLUPmhNmxUGKeKQqu0p
	e16dlyb+rZWd7j7r11wy5QlQhdCYl2D/UmnxQ=
MIME-Version: 1.0
Received: by 10.236.170.163 with SMTP id p23mr1702808yhl.36.1330539209093;
	Wed, 29 Feb 2012 10:13:29 -0800 (PST)
Received: by 10.100.18.12 with HTTP; Wed, 29 Feb 2012 10:13:29 -0800 (PST)
In-Reply-To: <1330526260.4270.124.camel@zakaz.uk.xensource.com>
References: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
	<1330526260.4270.124.camel@zakaz.uk.xensource.com>
Date: Wed, 29 Feb 2012 18:13:29 +0000
Message-ID: <CAEc3jaBn_nWFELJ0LL_HemgVM3-jTbmibQ4DHOYWkHykjE+ORA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems with hyperthreading in Windows 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 Wed, Feb 29, 2012 at 2:37 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-02-29 at 00:28 +0000, Roderick Colenbrander wrote:
>> Hi,
>>
>> I have been trying to get Hyperthreading to work in a Windows HVM on
>> Xen 4.1.2 as described in 'xmexample.hvm'. I think I have set it up
>> correctly, but I can't seem to get it to work. There is not much
>> documentation on it and most topics are from years ago.
>
> I don't know the answers to your questions, or whether this particular
> type of cpuid modification has ever worked. But might it be that
> something on the hypervisor side is also modifying the cpuid results?

It looks like there is code in xen/arch/x86/hvm/hvm.c which deals with
some more cpuid overrides. Initially it looked like libxc was doing
all the filtering and that 'XEN_DOMCTL_set_cpuid' just stored the
info. I'm not sure yet how that hypercall and the hvm.c code interact.
I have to dive more into it.

It also seems that for modern CPUs cpuid function 11 contains
additional topology information which may have to patched as well.

> I suppose you could start at xen/arch/x86/hvm/emulate.c:hvmemul_cpuid
> and trace down to the actual code in question? Looks like hvm_cpuid() is
> probably the key function of interest.
>
> Note sure where APIC IDs come from either, xen/arch/x86/hvm/vlapic.c
> might be an interesting starting point. Or perhaps this is done by
> hvmloader tools/firmware/hvmloader.c?
>
> More questions than answers in the above, sorry about that!
>
> Ian.
>

I'm going to dive further into the code and look at the places you
pointed to. I guess it can be made to work with some patching.
Assuming this would all work, I really wonder whether how this
hyperthreading fixup would interact with Xen itself. Normally Xen
hides hyperthreading for a reason and each guest works with 'virtual
cores' which get scheduled. My feeling is that the hyperthreading
fixup would have to be combined with CPU pinning to the correct
physical cores. Then to get 4 logical cores in the VM, you need to
assign 2 VCPUs to the VM. Would the guest OS really be able to
schedule threads over 4 logical cores? I really don't know how this
would work in Xen.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18: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 1S2o1t-0007vS-I8; Wed, 29 Feb 2012 18:13:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1S2o1s-0007vN-2Y
	for xen-devel@lists.xen.org; Wed, 29 Feb 2012 18:13:32 +0000
Received: from [193.109.254.147:61854] by server-8.bemta-14.messagelabs.com id
	B4/B6-04087-BCA6E4F4; Wed, 29 Feb 2012 18:13:31 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1330539157!62733977!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21933 invoked from network); 29 Feb 2012 18:12:38 -0000
Received: from mail-gx0-f173.google.com (HELO mail-gx0-f173.google.com)
	(209.85.161.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 18:12:38 -0000
Received: by ggnj2 with SMTP id j2so1944758ggn.32
	for <xen-devel@lists.xen.org>; Wed, 29 Feb 2012 10:13:29 -0800 (PST)
Received-SPF: pass (google.com: domain of thunderbird2k@gmail.com designates
	10.236.170.163 as permitted sender) client-ip=10.236.170.163; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	thunderbird2k@gmail.com designates 10.236.170.163 as permitted
	sender) smtp.mail=thunderbird2k@gmail.com;
	dkim=pass header.i=thunderbird2k@gmail.com
Received: from mr.google.com ([10.236.170.163])
	by 10.236.170.163 with SMTP id p23mr2144588yhl.36.1330539209267
	(num_hops = 1); Wed, 29 Feb 2012 10:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=aWIXKlZAfs1BQX/7i5/tHxFw1mpaafOBsK/G7Q6qOVM=;
	b=TOv5FG5KueORZRktN7lZfhumwqzvMx41WfiPIp6n64Z9gT64qQ6ha2BYMdpk/6QiNE
	ODgmTgyayxxmm2P4mw1B6xI9bKu3OCKwXm0vw6eHpFE0T2MSriLUPmhNmxUGKeKQqu0p
	e16dlyb+rZWd7j7r11wy5QlQhdCYl2D/UmnxQ=
MIME-Version: 1.0
Received: by 10.236.170.163 with SMTP id p23mr1702808yhl.36.1330539209093;
	Wed, 29 Feb 2012 10:13:29 -0800 (PST)
Received: by 10.100.18.12 with HTTP; Wed, 29 Feb 2012 10:13:29 -0800 (PST)
In-Reply-To: <1330526260.4270.124.camel@zakaz.uk.xensource.com>
References: <CAEc3jaA=Vt9ji+VwRQK4JqMUsa9tpO4D+aO2JCgCfjs4R80K4g@mail.gmail.com>
	<1330526260.4270.124.camel@zakaz.uk.xensource.com>
Date: Wed, 29 Feb 2012 18:13:29 +0000
Message-ID: <CAEc3jaBn_nWFELJ0LL_HemgVM3-jTbmibQ4DHOYWkHykjE+ORA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems with hyperthreading in Windows 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 Wed, Feb 29, 2012 at 2:37 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-02-29 at 00:28 +0000, Roderick Colenbrander wrote:
>> Hi,
>>
>> I have been trying to get Hyperthreading to work in a Windows HVM on
>> Xen 4.1.2 as described in 'xmexample.hvm'. I think I have set it up
>> correctly, but I can't seem to get it to work. There is not much
>> documentation on it and most topics are from years ago.
>
> I don't know the answers to your questions, or whether this particular
> type of cpuid modification has ever worked. But might it be that
> something on the hypervisor side is also modifying the cpuid results?

It looks like there is code in xen/arch/x86/hvm/hvm.c which deals with
some more cpuid overrides. Initially it looked like libxc was doing
all the filtering and that 'XEN_DOMCTL_set_cpuid' just stored the
info. I'm not sure yet how that hypercall and the hvm.c code interact.
I have to dive more into it.

It also seems that for modern CPUs cpuid function 11 contains
additional topology information which may have to patched as well.

> I suppose you could start at xen/arch/x86/hvm/emulate.c:hvmemul_cpuid
> and trace down to the actual code in question? Looks like hvm_cpuid() is
> probably the key function of interest.
>
> Note sure where APIC IDs come from either, xen/arch/x86/hvm/vlapic.c
> might be an interesting starting point. Or perhaps this is done by
> hvmloader tools/firmware/hvmloader.c?
>
> More questions than answers in the above, sorry about that!
>
> Ian.
>

I'm going to dive further into the code and look at the places you
pointed to. I guess it can be made to work with some patching.
Assuming this would all work, I really wonder whether how this
hyperthreading fixup would interact with Xen itself. Normally Xen
hides hyperthreading for a reason and each guest works with 'virtual
cores' which get scheduled. My feeling is that the hyperthreading
fixup would have to be combined with CPU pinning to the correct
physical cores. Then to get 4 logical cores in the VM, you need to
assign 2 VCPUs to the VM. Would the guest OS really be able to
schedule threads over 4 logical cores? I really don't know how this
would work in Xen.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:25:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2oD5-000874-Sb; Wed, 29 Feb 2012 18:25:07 +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 1S2oD4-00086q-Lv
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:25:06 +0000
Received: from [85.158.139.83:59405] by server-1.bemta-5.messagelabs.com id
	0B/9E-28458-18D6E4F4; Wed, 29 Feb 2012 18:25:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330539904!13344122!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTQxMDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9249 invoked from network); 29 Feb 2012 18:25:05 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 18:25: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 CB89B240C;
	Wed, 29 Feb 2012 20:25:03 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 66DA62004A; Wed, 29 Feb 2012 20:25:03 +0200 (EET)
Date: Wed, 29 Feb 2012 20:25:03 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120229182503.GX12984@reaktio.net>
References: <1330534437.4270.143.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330534437.4270.143.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, xen-api@lists.xen.org
Subject: Re: [Xen-devel] GSoC 2012 project brainstorming
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 04:53:57PM +0000, Ian Campbell wrote:
> Below are a few ideas which have been floating around as potential
> projects (or broad subject areas for projects) for GSoC this year.
> 
> If you want any more information on any particular item then please ask.
> Likewise if you have any ideas of your own please feel free to chip in.
> 
> If you think you might be interested in a project, either as mentor or
> potential student, then please add it to the wiki page at
> http://wiki.xen.org/wiki/GSoC_2012_Ideas
> 
> Ian.
> 
> 
> HYPERVISOR
> ----------
> - insmod Xen
> - event channel limits
> - NUMA
> 

See below..

> IO
> --
> - PV OpenGL/Gallium
> - PV USB

Just for reference..
PVUSB (USB 2) driver for pvops Linux 3.x is available from:
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00576.html
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html

http://wiki.xen.org/wiki/Xen_USB_Passthrough


> - PV USB3

Is anyone working on this?


> - PV SCSI

PVSCSI driver for pvops Linux 3.x is available from:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/xen-scsi.v1.0

http://wiki.xen.org/wiki/Paravirtualized_SCSI

> 
> 
> QEMU
> ----
> - BSD libc
> - upstream QEMU stubdoms
> 

Not sure if this should be in HYPERVISOR or QEMU section:

- Xen HVM guest direct kernel+initramfs boot support, just like for PV guests. 
This has been requested a couple of times and would be useful feature to have.
KVM/Qemu supports 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 Feb 29 18:25:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2oD5-000874-Sb; Wed, 29 Feb 2012 18:25:07 +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 1S2oD4-00086q-Lv
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:25:06 +0000
Received: from [85.158.139.83:59405] by server-1.bemta-5.messagelabs.com id
	0B/9E-28458-18D6E4F4; Wed, 29 Feb 2012 18:25:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-182.messagelabs.com!1330539904!13344122!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTQxMDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9249 invoked from network); 29 Feb 2012 18:25:05 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 18:25: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 CB89B240C;
	Wed, 29 Feb 2012 20:25:03 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 66DA62004A; Wed, 29 Feb 2012 20:25:03 +0200 (EET)
Date: Wed, 29 Feb 2012 20:25:03 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120229182503.GX12984@reaktio.net>
References: <1330534437.4270.143.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330534437.4270.143.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, xen-api@lists.xen.org
Subject: Re: [Xen-devel] GSoC 2012 project brainstorming
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 04:53:57PM +0000, Ian Campbell wrote:
> Below are a few ideas which have been floating around as potential
> projects (or broad subject areas for projects) for GSoC this year.
> 
> If you want any more information on any particular item then please ask.
> Likewise if you have any ideas of your own please feel free to chip in.
> 
> If you think you might be interested in a project, either as mentor or
> potential student, then please add it to the wiki page at
> http://wiki.xen.org/wiki/GSoC_2012_Ideas
> 
> Ian.
> 
> 
> HYPERVISOR
> ----------
> - insmod Xen
> - event channel limits
> - NUMA
> 

See below..

> IO
> --
> - PV OpenGL/Gallium
> - PV USB

Just for reference..
PVUSB (USB 2) driver for pvops Linux 3.x is available from:
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00576.html
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html

http://wiki.xen.org/wiki/Xen_USB_Passthrough


> - PV USB3

Is anyone working on this?


> - PV SCSI

PVSCSI driver for pvops Linux 3.x is available from:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/xen-scsi.v1.0

http://wiki.xen.org/wiki/Paravirtualized_SCSI

> 
> 
> QEMU
> ----
> - BSD libc
> - upstream QEMU stubdoms
> 

Not sure if this should be in HYPERVISOR or QEMU section:

- Xen HVM guest direct kernel+initramfs boot support, just like for PV guests. 
This has been requested a couple of times and would be useful feature to have.
KVM/Qemu supports 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 Feb 29 18:28:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18: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 1S2oFm-0008I2-Os; Wed, 29 Feb 2012 18:27:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2oFl-0008Hc-C2
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:27:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330540066!2980452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24039 invoked from network); 29 Feb 2012 18:27:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 18:27:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11019331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 18:27:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 18:27:46 +0000
Date: Wed, 29 Feb 2012 18:34:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330428299.31269.91.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202291735190.31630@kaball-desktop>
References: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330428299.31269.91.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/2] arm: support fewer LR registers than
 virtual 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 Tue, 28 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:00 +0000, Stefano Stabellini wrote:
> > If the vgic needs to inject a virtual irq into the guest, but no free
> > LR registers are available, add the irq to a list and return.
> 
> There is an ordering constraint on this list. It should be mentioned
> somewhere in a comment.

right


> > Whenever an LR register becomes available we add the queued irq to it
> > and remove it from the list.
> > We use the gic lock to protect the list and the bitmask.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c           |   95 ++++++++++++++++++++++++++++++++----------
> >  xen/include/asm-arm/domain.h |    1 +
> >  2 files changed, 74 insertions(+), 22 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index adc10bb..2ff7bce 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -25,6 +25,7 @@
> >  #include <xen/sched.h>
> >  #include <xen/errno.h>
> >  #include <xen/softirq.h>
> > +#include <xen/list.h>
> >  #include <asm/p2m.h>
> >  #include <asm/domain.h>
> >  
> > @@ -45,6 +46,8 @@ static struct {
> >      unsigned int lines;
> >      unsigned int cpus;
> >      spinlock_t lock;
> > +    uint64_t lr_mask;
> > +    struct list_head lr_pending;
> >  } gic;
> >  
> >  irq_desc_t irq_desc[NR_IRQS];
> > @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
> >  
> >      GICH[GICH_HCR] = GICH_HCR_EN;
> >      GICH[GICH_MISR] = GICH_MISR_EOI;
> > +    gic.lr_mask = 0ULL;
> > +    INIT_LIST_HEAD(&gic.lr_pending);
> >  }
> >  
> >  /* Set up the GIC */
> > @@ -345,16 +350,50 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
> >      return rc;
> >  }
> >  
> > -void gic_set_guest_irq(unsigned int virtual_irq,
> > +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
> >          unsigned int state, unsigned int priority)
> >  {
> > -    BUG_ON(virtual_irq > nr_lrs);
> > -    GICH[GICH_LR + virtual_irq] = state |
> > +    BUG_ON(lr > nr_lrs);
> > +    GICH[GICH_LR + lr] = state |
> >          GICH_LR_MAINTENANCE_IRQ |
> >          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> >          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >  }
> >  
> > +void gic_set_guest_irq(unsigned int virtual_irq,
> > +        unsigned int state, unsigned int priority)
> > +{
> > +    int i;
> > +    struct pending_irq *iter, *n;
> > +
> > +    spin_lock(&gic.lock);
> > +
> > +    if ( list_empty(&gic.lr_pending) )
> 
> This could really do with some comments.
> 
> The logic here is that if the "lr_pending" list has nothing in it then
> there are no other IRQs queued waiting for an LR to become available and
> therefore we can take a fast path and inject this IRQ directly?

Yes: if there are no IRQs waiting for an LR it means that an LR might
actually be free. If we have IRQs queued in lr_pending then there is no
point in checking for a free LR.


> > +    {
> > +        i = find_first_zero_bit(&gic.lr_mask, sizeof(uint64_t));
> > +        if (i < sizeof(uint64_t)) {
> 
> What does find_first_zero_bit(0xffff.fff, 64) return?

0

> > +            set_bit(i, &gic.lr_mask);
> > +            gic_set_lr(i, virtual_irq, state, priority);
> > +            goto out;
> > +        }
> > +    }
> > +
> > +    n = irq_to_pending(current, virtual_irq);
> > +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> > +    {
> > +        if ( iter->priority < priority )
> > +        {
> > +            list_add_tail(&n->lr_link, &iter->lr_link);
> > +            goto out;
> > +        }
> > +    }
> > +    list_add(&n->lr_link, &gic.lr_pending);
> 
> Should this be list_add_tail?

yes

> Lower numbers are higher priority and therefore the list should be
> ordered from low->high, since we want to pull the next interrupt off the
> front of the list. I don't think the above implements that though.

Yes, the priority test is inverted.
I think we want:

iter->priority > priority


> If we imagine a list containing priorities [2,4,6] into which we are
> inserting a priority 5 interrupt.
> 
> On the first iteration of the loop iter->priority == 2 so "if
> (iter->priority < priority)" is true and we insert 5 after 2 in the list
> resulting in [2,5,4,6].

Actually list_add_tail adds the entry before the head, not after.
So if we have the right priority check and the list is [2,4,6], adding 5
should result in [2,4,5,6].


> > +
> > +out:
> > +    spin_unlock(&gic.lock);
> > +    return;
> > +}
> > +
> >  void gic_inject_irq_start(void)
> >  {
> >      uint32_t hcr;
> > @@ -431,30 +470,42 @@ void gicv_setup(struct domain *d)
> >  
> >  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> >  {
> > -    int i, virq;
> > +    int i = 0, virq;
> >      uint32_t lr;
> >      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
> >  
> > -    for ( i = 0; i < 64; i++ ) {
> > -        if ( eisr & ((uint64_t)1 << i) ) {
> > -            struct pending_irq *p;
> > -
> > -            lr = GICH[GICH_LR + i];
> > -            virq = lr & GICH_LR_VIRTUAL_MASK;
> > -            GICH[GICH_LR + i] = 0;
> > -
> > -            spin_lock(&current->arch.vgic.lock);
> > -            p = irq_to_pending(current, virq);
> > -            if ( p->desc != NULL ) {
> > -                p->desc->status &= ~IRQ_INPROGRESS;
> > -                GICC[GICC_DIR] = virq;
> > -            }
> > +    while ((i = find_next_bit((const long unsigned int *) &eisr,
> > +                              sizeof(eisr), i)) < sizeof(eisr)) {
> 
> > +        struct pending_irq *p;
> > +
> > +        spin_lock(&gic.lock);
> > +        lr = GICH[GICH_LR + i];
> > +        virq = lr & GICH_LR_VIRTUAL_MASK;
> > +        GICH[GICH_LR + i] = 0;
> > +        clear_bit(i, &gic.lr_mask);
> > +
> > +        if ( !list_empty(gic.lr_pending.next) ) {
> 
> This seems odd, why not "list_empty(gic.lr_pending)"?
> 
> Otherwise won't you fail to inject anything if there is exactly one
> entry on lr_pending?

You are correct, that is a mistake.


> > +            p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> > +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +            list_del_init(&p->lr_link);
> > +            set_bit(i, &gic.lr_mask);
> > +        } else {
> >              gic_inject_irq_stop();
> > -            list_del(&p->link);
> > -            INIT_LIST_HEAD(&p->link);
> > -            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> > -            spin_unlock(&current->arch.vgic.lock);
> >          }
> > +        spin_unlock(&gic.lock);
> > +
> > +        spin_lock(&current->arch.vgic.lock);
> > +        p = irq_to_pending(current, virq);
> > +        if ( p->desc != NULL ) {
> > +            p->desc->status &= ~IRQ_INPROGRESS;
> > +            GICC[GICC_DIR] = virq;
> > +        }
> > +        list_del(&p->link);
> > +        INIT_LIST_HEAD(&p->link);
> > +        cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> > +        spin_unlock(&current->arch.vgic.lock);
> > +
> > +        i++;
> 
> Does find_next_bit include or exclude the bit which you give it as the
> 3rd argument?

include


> >      }
> >  }
> >  
> > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> > index 3372d14..75095ff 100644
> > --- a/xen/include/asm-arm/domain.h
> > +++ b/xen/include/asm-arm/domain.h
> > @@ -21,6 +21,7 @@ struct pending_irq
> >      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
> >      uint8_t priority;
> >      struct list_head link;
> > +    struct list_head lr_link;
> 
> Calling this "link" or "lr_link" when it is used in the context or link
> registers (e.g. link-register_link) just adds to the confusion around
> these two lists IMHO, as does having one just called link and the other
> prefix_link. Calling them foo_list, both with a descriptive prefix,
> would be better, e.g. active_list and queued_list (or whatever you deem
> appropriate to their semantics)
> 
> Even better would be if the invariant "always on either active or
> pending lists, never both" were true -- in which case only one list_head
> would be needed here.

I'll try to come up with better descriptive names and comments.


> What do we actually use "link" for? It is chained off vgic.inflight_irqs
> but we seem to only use it for anything other than manipulating itself
> in vgic_softirq where it is used as a binary "something to inject" flag
> -- we could just as well maintain a nr_inflight variable if that were
> the case, couldn't we?

It is used by the vgic to keep track of what IRQs have been injected
from its point of view. These IRQs might have been injected and
currently resident in an LR register, or they might be queued in
lr_pending. I'll write a comment to better the explain the life cycle of
an IRQ.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:28:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18: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 1S2oFm-0008I2-Os; Wed, 29 Feb 2012 18:27:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1S2oFl-0008Hc-C2
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:27:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1330540066!2980452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24039 invoked from network); 29 Feb 2012 18:27:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 18:27:46 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11019331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 18:27:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 18:27:46 +0000
Date: Wed, 29 Feb 2012 18:34:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1330428299.31269.91.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1202291735190.31630@kaball-desktop>
References: <1330016454-19752-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1330428299.31269.91.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/2] arm: support fewer LR registers than
 virtual 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 Tue, 28 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:00 +0000, Stefano Stabellini wrote:
> > If the vgic needs to inject a virtual irq into the guest, but no free
> > LR registers are available, add the irq to a list and return.
> 
> There is an ordering constraint on this list. It should be mentioned
> somewhere in a comment.

right


> > Whenever an LR register becomes available we add the queued irq to it
> > and remove it from the list.
> > We use the gic lock to protect the list and the bitmask.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c           |   95 ++++++++++++++++++++++++++++++++----------
> >  xen/include/asm-arm/domain.h |    1 +
> >  2 files changed, 74 insertions(+), 22 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index adc10bb..2ff7bce 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -25,6 +25,7 @@
> >  #include <xen/sched.h>
> >  #include <xen/errno.h>
> >  #include <xen/softirq.h>
> > +#include <xen/list.h>
> >  #include <asm/p2m.h>
> >  #include <asm/domain.h>
> >  
> > @@ -45,6 +46,8 @@ static struct {
> >      unsigned int lines;
> >      unsigned int cpus;
> >      spinlock_t lock;
> > +    uint64_t lr_mask;
> > +    struct list_head lr_pending;
> >  } gic;
> >  
> >  irq_desc_t irq_desc[NR_IRQS];
> > @@ -247,6 +250,8 @@ static void __cpuinit gic_hyp_init(void)
> >  
> >      GICH[GICH_HCR] = GICH_HCR_EN;
> >      GICH[GICH_MISR] = GICH_MISR_EOI;
> > +    gic.lr_mask = 0ULL;
> > +    INIT_LIST_HEAD(&gic.lr_pending);
> >  }
> >  
> >  /* Set up the GIC */
> > @@ -345,16 +350,50 @@ int __init setup_irq(unsigned int irq, struct irqaction *new)
> >      return rc;
> >  }
> >  
> > -void gic_set_guest_irq(unsigned int virtual_irq,
> > +static inline void gic_set_lr(int lr, unsigned int virtual_irq,
> >          unsigned int state, unsigned int priority)
> >  {
> > -    BUG_ON(virtual_irq > nr_lrs);
> > -    GICH[GICH_LR + virtual_irq] = state |
> > +    BUG_ON(lr > nr_lrs);
> > +    GICH[GICH_LR + lr] = state |
> >          GICH_LR_MAINTENANCE_IRQ |
> >          ((priority >> 3) << GICH_LR_PRIORITY_SHIFT) |
> >          ((virtual_irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT);
> >  }
> >  
> > +void gic_set_guest_irq(unsigned int virtual_irq,
> > +        unsigned int state, unsigned int priority)
> > +{
> > +    int i;
> > +    struct pending_irq *iter, *n;
> > +
> > +    spin_lock(&gic.lock);
> > +
> > +    if ( list_empty(&gic.lr_pending) )
> 
> This could really do with some comments.
> 
> The logic here is that if the "lr_pending" list has nothing in it then
> there are no other IRQs queued waiting for an LR to become available and
> therefore we can take a fast path and inject this IRQ directly?

Yes: if there are no IRQs waiting for an LR it means that an LR might
actually be free. If we have IRQs queued in lr_pending then there is no
point in checking for a free LR.


> > +    {
> > +        i = find_first_zero_bit(&gic.lr_mask, sizeof(uint64_t));
> > +        if (i < sizeof(uint64_t)) {
> 
> What does find_first_zero_bit(0xffff.fff, 64) return?

0

> > +            set_bit(i, &gic.lr_mask);
> > +            gic_set_lr(i, virtual_irq, state, priority);
> > +            goto out;
> > +        }
> > +    }
> > +
> > +    n = irq_to_pending(current, virtual_irq);
> > +    list_for_each_entry ( iter, &gic.lr_pending, lr_link )
> > +    {
> > +        if ( iter->priority < priority )
> > +        {
> > +            list_add_tail(&n->lr_link, &iter->lr_link);
> > +            goto out;
> > +        }
> > +    }
> > +    list_add(&n->lr_link, &gic.lr_pending);
> 
> Should this be list_add_tail?

yes

> Lower numbers are higher priority and therefore the list should be
> ordered from low->high, since we want to pull the next interrupt off the
> front of the list. I don't think the above implements that though.

Yes, the priority test is inverted.
I think we want:

iter->priority > priority


> If we imagine a list containing priorities [2,4,6] into which we are
> inserting a priority 5 interrupt.
> 
> On the first iteration of the loop iter->priority == 2 so "if
> (iter->priority < priority)" is true and we insert 5 after 2 in the list
> resulting in [2,5,4,6].

Actually list_add_tail adds the entry before the head, not after.
So if we have the right priority check and the list is [2,4,6], adding 5
should result in [2,4,5,6].


> > +
> > +out:
> > +    spin_unlock(&gic.lock);
> > +    return;
> > +}
> > +
> >  void gic_inject_irq_start(void)
> >  {
> >      uint32_t hcr;
> > @@ -431,30 +470,42 @@ void gicv_setup(struct domain *d)
> >  
> >  static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> >  {
> > -    int i, virq;
> > +    int i = 0, virq;
> >      uint32_t lr;
> >      uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1]) << 32);
> >  
> > -    for ( i = 0; i < 64; i++ ) {
> > -        if ( eisr & ((uint64_t)1 << i) ) {
> > -            struct pending_irq *p;
> > -
> > -            lr = GICH[GICH_LR + i];
> > -            virq = lr & GICH_LR_VIRTUAL_MASK;
> > -            GICH[GICH_LR + i] = 0;
> > -
> > -            spin_lock(&current->arch.vgic.lock);
> > -            p = irq_to_pending(current, virq);
> > -            if ( p->desc != NULL ) {
> > -                p->desc->status &= ~IRQ_INPROGRESS;
> > -                GICC[GICC_DIR] = virq;
> > -            }
> > +    while ((i = find_next_bit((const long unsigned int *) &eisr,
> > +                              sizeof(eisr), i)) < sizeof(eisr)) {
> 
> > +        struct pending_irq *p;
> > +
> > +        spin_lock(&gic.lock);
> > +        lr = GICH[GICH_LR + i];
> > +        virq = lr & GICH_LR_VIRTUAL_MASK;
> > +        GICH[GICH_LR + i] = 0;
> > +        clear_bit(i, &gic.lr_mask);
> > +
> > +        if ( !list_empty(gic.lr_pending.next) ) {
> 
> This seems odd, why not "list_empty(gic.lr_pending)"?
> 
> Otherwise won't you fail to inject anything if there is exactly one
> entry on lr_pending?

You are correct, that is a mistake.


> > +            p = list_entry(gic.lr_pending.next, typeof(*p), lr_link);
> > +            gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
> > +            list_del_init(&p->lr_link);
> > +            set_bit(i, &gic.lr_mask);
> > +        } else {
> >              gic_inject_irq_stop();
> > -            list_del(&p->link);
> > -            INIT_LIST_HEAD(&p->link);
> > -            cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> > -            spin_unlock(&current->arch.vgic.lock);
> >          }
> > +        spin_unlock(&gic.lock);
> > +
> > +        spin_lock(&current->arch.vgic.lock);
> > +        p = irq_to_pending(current, virq);
> > +        if ( p->desc != NULL ) {
> > +            p->desc->status &= ~IRQ_INPROGRESS;
> > +            GICC[GICC_DIR] = virq;
> > +        }
> > +        list_del(&p->link);
> > +        INIT_LIST_HEAD(&p->link);
> > +        cpu_raise_softirq(current->processor, VGIC_SOFTIRQ);
> > +        spin_unlock(&current->arch.vgic.lock);
> > +
> > +        i++;
> 
> Does find_next_bit include or exclude the bit which you give it as the
> 3rd argument?

include


> >      }
> >  }
> >  
> > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> > index 3372d14..75095ff 100644
> > --- a/xen/include/asm-arm/domain.h
> > +++ b/xen/include/asm-arm/domain.h
> > @@ -21,6 +21,7 @@ struct pending_irq
> >      struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
> >      uint8_t priority;
> >      struct list_head link;
> > +    struct list_head lr_link;
> 
> Calling this "link" or "lr_link" when it is used in the context or link
> registers (e.g. link-register_link) just adds to the confusion around
> these two lists IMHO, as does having one just called link and the other
> prefix_link. Calling them foo_list, both with a descriptive prefix,
> would be better, e.g. active_list and queued_list (or whatever you deem
> appropriate to their semantics)
> 
> Even better would be if the invariant "always on either active or
> pending lists, never both" were true -- in which case only one list_head
> would be needed here.

I'll try to come up with better descriptive names and comments.


> What do we actually use "link" for? It is chained off vgic.inflight_irqs
> but we seem to only use it for anything other than manipulating itself
> in vgic_softirq where it is used as a binary "something to inject" flag
> -- we could just as well maintain a nr_inflight variable if that were
> the case, couldn't we?

It is used by the vgic to keep track of what IRQs have been injected
from its point of view. These IRQs might have been injected and
currently resident in an LR register, or they might be queued in
lr_pending. I'll write a comment to better the explain the life cycle of
an IRQ.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:46:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2oXL-0008WQ-F9; Wed, 29 Feb 2012 18:46:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2oXK-0008WL-0P
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330541154!18878841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10727 invoked from network); 29 Feb 2012 18:45:55 -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;
	29 Feb 2012 18:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11019544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 18:45: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.213.0;
	Wed, 29 Feb 2012 18:45:52 +0000
Message-ID: <1330541152.10008.62.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 29 Feb 2012 18:45:52 +0000
In-Reply-To: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520738.4270.84.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 13:05 +0000, Ian Campbell wrote:
> 
> (probably the bad quoting in the example I gave has lead to the
> qemu-debug.sh "correcting" this for you. I think I should have said
> either 
>         exec /usr/lib/xen/bin/qemu-system-i386 "$@"
> or
>         exec /usr/lib/xen/bin/qemu-system-i386 "$*"
> (I can never remember which is correct) 

Thanks to everyone for correcting me ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 18:46:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 18:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2oXL-0008WQ-F9; Wed, 29 Feb 2012 18:46:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1S2oXK-0008WL-0P
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 18:46:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1330541154!18878841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10727 invoked from network); 29 Feb 2012 18:45:55 -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;
	29 Feb 2012 18:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11019544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 18:45: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.213.0;
	Wed, 29 Feb 2012 18:45:52 +0000
Message-ID: <1330541152.10008.62.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 29 Feb 2012 18:45:52 +0000
In-Reply-To: <1330520738.4270.84.camel@zakaz.uk.xensource.com>
References: <1330513756170-5524689.post@n5.nabble.com>
	<1330514555.4270.52.camel@zakaz.uk.xensource.com>
	<1330519499118-5524861.post@n5.nabble.com>
	<1330520738.4270.84.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Need help with qemu args debug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-02-29 at 13:05 +0000, Ian Campbell wrote:
> 
> (probably the bad quoting in the example I gave has lead to the
> qemu-debug.sh "correcting" this for you. I think I should have said
> either 
>         exec /usr/lib/xen/bin/qemu-system-i386 "$@"
> or
>         exec /usr/lib/xen/bin/qemu-system-i386 "$*"
> (I can never remember which is correct) 

Thanks to everyone for correcting me ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19: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 1S2owU-0000Ja-Kl; Wed, 29 Feb 2012 19:12:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2owS-0000JV-MJ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:12:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330542712!15521982!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15220 invoked from network); 29 Feb 2012 19:11:53 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 19:11:53 -0000
Received: by iadj38 with SMTP id j38so9097748iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 11:11:52 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.220.164 as permitted sender) client-ip=10.50.220.164; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.220.164 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.220.164])
	by 10.50.220.164 with SMTP id px4mr8227769igc.46.1330542712012
	(num_hops = 1); Wed, 29 Feb 2012 11:11:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=VIRvxLFjmkdgbiL2YTBzdTbT3WeLrCP/e28QnxeW+NA=;
	b=lrgHMIvo46Xi86ZuWDWqG/syeSSsc0NVwWrXrhhb7tjSolqNtwaI4a+52dHgN+Y4+Q
	4tMipet9pF6dc+xzBLd1nnsXEPqwYMQnDy1yx+D74ayZtgN5IQkziRcAkalzVUlVRrrN
	aqU/l420y67Uy0rXXKy7/ljtEm1xC4MoklE3c=
MIME-Version: 1.0
Received: by 10.50.220.164 with SMTP id px4mr6815570igc.46.1330542711926; Wed,
	29 Feb 2012 11:11:51 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Wed, 29 Feb 2012 11:11:51 -0800 (PST)
In-Reply-To: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
Date: Wed, 29 Feb 2012 19:11:51 +0000
X-Google-Sender-Auth: UwXS6Uc_R2S4SkGhXKKnLjPfTok
Message-ID: <CAFLBxZb0c-6ALrXM3MvHuiGHDX4O__8Sq4f11eVyn1sbo3FtZA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 5:26 PM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
>> From: Olaf Hering [mailto:olaf@aepfle.de]
>> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
>>
>> On Mon, Feb 27, Dan Magenheimer wrote:
>>
>> > > From: Olaf Hering [mailto:olaf@aepfle.de]
>> > > To me memory overcommit means swapping, which is what xenpaging does:
>> > > turn the whole guest gfn range into some sort of virtual memory,
>> > > transparent to the guest.
>> > >
>> > > xenpaging is the red emergency knob to free some host memory without
>> > > caring about the actual memory constraints within the paged guests.
>> >
>> > Sure, but the whole point of increasing RAM in one or more guests
>> > is to increase performance, and if overcommitting *always* means
>> > swapping, why would anyone use it?
>>
>> The usage patterns depend on the goal. As I wrote, swapping frees host
>> memory so it can be used for something else, like starting yet another
>> guest on the host.
>
> OK, I suppose xenpaging by itself could be useful in a situation such as:
>
> 1) A failover occurs from machine A that has lots of RAM to machine B
> =A0 that has much less RAM, and even horribly bad performance is better
> =A0 than total service interruption.
> 2) All currently running VMs have been ballooned down "far enough"
> =A0 and either have no swap device or insufficiently-sized swap devices,
> =A0 Xen simply has no more free space, and horrible performance is
> =A0 acceptable.
>
> The historical problem with "hypervisor-based-swapping" solutions such
> as xenpaging is that it is impossible to ensure that "horribly bad
> performance" doesn't start occurring under "normal" circumstances
> specifically because (as Tim indirectly concurs below), policies
> driven by heuristics and external inference (i.e. dom0 trying
> to guess how much memory every domU "needs") just don't work.
>
> As a result, VMware customers outside of some very specific domains
> (domains possibly overlapping with Snowflock?) will tell you
> that "memory overcommit sucks and so we turn it off".
>
> Which is why I raised the question "why are we doing this?"...
> If the answer is "Snowflock customers will benefit from it",
> that's fine. =A0If the answer is "to handle disastrous failover
> situations", that's fine too. =A0And I suppose if the answer is
> "so that VMware can't claim to have a feature that Xen doesn't
> have (even if almost nobody uses it)", I suppose that's fine too.
>
> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".

Is it possible to use the "better way" in Windows?  If not, then those
who want to support Windows guests are stuck with the old way, until
MS discovers / "re-invents" tmem. :-)  (Maybe you should give a your
tmem talk at MS research?  Or try to give it again if you already
have?)  Even then there'd still be a market for supporting all those
pre-tmem OS's for quite a while.

Apart from that, here's my perspective:
* Having page sharing is good, because of potential memory savings in
VDI deployments, but also because of potential for fun things like VM
fork, &c
* Having page sharing requires you to have an emergency plan if
suddenly all the VMs write to their pages and un-share them.
Hypervisor paging is the only reasonable option here.

If it makes you feel any better, one of the suggested default policies
for "what to do with all the memory sharing generates" was "put it
into a tmem pool". :-)  That, and as we try to hammer out what the
implications of default policies are, the semantic gap between balloon
drivers, paging, and sharing, is rearing a very ugly head -- I would
much rather just hand the paging/ballooning stuff over to tmem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19: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 1S2owU-0000Ja-Kl; Wed, 29 Feb 2012 19:12:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1S2owS-0000JV-MJ
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:12:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1330542712!15521982!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15220 invoked from network); 29 Feb 2012 19:11:53 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 19:11:53 -0000
Received: by iadj38 with SMTP id j38so9097748iad.30
	for <xen-devel@lists.xensource.com>;
	Wed, 29 Feb 2012 11:11:52 -0800 (PST)
Received-SPF: pass (google.com: domain of dunlapg@gmail.com designates
	10.50.220.164 as permitted sender) client-ip=10.50.220.164; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of dunlapg@gmail.com
	designates 10.50.220.164 as permitted sender)
	smtp.mail=dunlapg@gmail.com;
	dkim=pass header.i=dunlapg@gmail.com
Received: from mr.google.com ([10.50.220.164])
	by 10.50.220.164 with SMTP id px4mr8227769igc.46.1330542712012
	(num_hops = 1); Wed, 29 Feb 2012 11:11:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	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=VIRvxLFjmkdgbiL2YTBzdTbT3WeLrCP/e28QnxeW+NA=;
	b=lrgHMIvo46Xi86ZuWDWqG/syeSSsc0NVwWrXrhhb7tjSolqNtwaI4a+52dHgN+Y4+Q
	4tMipet9pF6dc+xzBLd1nnsXEPqwYMQnDy1yx+D74ayZtgN5IQkziRcAkalzVUlVRrrN
	aqU/l420y67Uy0rXXKy7/ljtEm1xC4MoklE3c=
MIME-Version: 1.0
Received: by 10.50.220.164 with SMTP id px4mr6815570igc.46.1330542711926; Wed,
	29 Feb 2012 11:11:51 -0800 (PST)
Received: by 10.231.199.200 with HTTP; Wed, 29 Feb 2012 11:11:51 -0800 (PST)
In-Reply-To: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
Date: Wed, 29 Feb 2012 19:11:51 +0000
X-Google-Sender-Auth: UwXS6Uc_R2S4SkGhXKKnLjPfTok
Message-ID: <CAFLBxZb0c-6ALrXM3MvHuiGHDX4O__8Sq4f11eVyn1sbo3FtZA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, 2012 at 5:26 PM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
>> From: Olaf Hering [mailto:olaf@aepfle.de]
>> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
>>
>> On Mon, Feb 27, Dan Magenheimer wrote:
>>
>> > > From: Olaf Hering [mailto:olaf@aepfle.de]
>> > > To me memory overcommit means swapping, which is what xenpaging does:
>> > > turn the whole guest gfn range into some sort of virtual memory,
>> > > transparent to the guest.
>> > >
>> > > xenpaging is the red emergency knob to free some host memory without
>> > > caring about the actual memory constraints within the paged guests.
>> >
>> > Sure, but the whole point of increasing RAM in one or more guests
>> > is to increase performance, and if overcommitting *always* means
>> > swapping, why would anyone use it?
>>
>> The usage patterns depend on the goal. As I wrote, swapping frees host
>> memory so it can be used for something else, like starting yet another
>> guest on the host.
>
> OK, I suppose xenpaging by itself could be useful in a situation such as:
>
> 1) A failover occurs from machine A that has lots of RAM to machine B
> =A0 that has much less RAM, and even horribly bad performance is better
> =A0 than total service interruption.
> 2) All currently running VMs have been ballooned down "far enough"
> =A0 and either have no swap device or insufficiently-sized swap devices,
> =A0 Xen simply has no more free space, and horrible performance is
> =A0 acceptable.
>
> The historical problem with "hypervisor-based-swapping" solutions such
> as xenpaging is that it is impossible to ensure that "horribly bad
> performance" doesn't start occurring under "normal" circumstances
> specifically because (as Tim indirectly concurs below), policies
> driven by heuristics and external inference (i.e. dom0 trying
> to guess how much memory every domU "needs") just don't work.
>
> As a result, VMware customers outside of some very specific domains
> (domains possibly overlapping with Snowflock?) will tell you
> that "memory overcommit sucks and so we turn it off".
>
> Which is why I raised the question "why are we doing this?"...
> If the answer is "Snowflock customers will benefit from it",
> that's fine. =A0If the answer is "to handle disastrous failover
> situations", that's fine too. =A0And I suppose if the answer is
> "so that VMware can't claim to have a feature that Xen doesn't
> have (even if almost nobody uses it)", I suppose that's fine too.
>
> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".

Is it possible to use the "better way" in Windows?  If not, then those
who want to support Windows guests are stuck with the old way, until
MS discovers / "re-invents" tmem. :-)  (Maybe you should give a your
tmem talk at MS research?  Or try to give it again if you already
have?)  Even then there'd still be a market for supporting all those
pre-tmem OS's for quite a while.

Apart from that, here's my perspective:
* Having page sharing is good, because of potential memory savings in
VDI deployments, but also because of potential for fun things like VM
fork, &c
* Having page sharing requires you to have an emergency plan if
suddenly all the VMs write to their pages and un-share them.
Hypervisor paging is the only reasonable option here.

If it makes you feel any better, one of the suggested default policies
for "what to do with all the memory sharing generates" was "put it
into a tmem pool". :-)  That, and as we try to hammer out what the
implications of default policies are, the semantic gap between balloon
drivers, paging, and sharing, is rearing a very ugly head -- I would
much rather just hand the paging/ballooning stuff over to tmem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:23:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2p7I-0000VJ-U2; Wed, 29 Feb 2012 19:23:12 +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 1S2p7H-0000VB-2J
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:23:11 +0000
Received: from [85.158.139.83:41079] by server-2.bemta-5.messagelabs.com id
	8F/B9-20263-E1B7E4F4; Wed, 29 Feb 2012 19:23:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330543388!16631854!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3006 invoked from network); 29 Feb 2012 19:23:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 19:23:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330543387; l=860;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Ni+AfhZKcKn3So58VgsoaXeomZU=;
	b=amQmNIoXe2D27igKF5pFzpDS5t1bdHk1aBE9/I1pqPE79B9QipuIXzAn0pFDfs6I+ZU
	q5bRZ31dGYOqaMyLyzrfTgXS80fJ6I4UaPBI+YIqxHUGyhTmwHNMdcnLBhVB5VuKX1VMF
	wnKo1uYuXjoMDG9csrdmIEo+r+NzYivVol0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (cohen mo23) (RZmta 28.0 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I05eb5o1TIQWhX ;
	Wed, 29 Feb 2012 20:22:41 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0745E18638; Wed, 29 Feb 2012 20:22:38 +0100 (CET)
Date: Wed, 29 Feb 2012 20:22:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120229192238.GA9226@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, Dan Magenheimer wrote:

> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".

The checkbox thing, and because its fun, is certainly a big part of it.
I agree that a in-guest solution where all capable guests can give away
pages to others is best because there is no IO overhead. And guests know
best what pages can be put into the pool.

Then I think that not all guests are capable enough to contribute their
free pages. And if host memory is low, then things like swapping can
solve the problem at hand.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:23:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2p7I-0000VJ-U2; Wed, 29 Feb 2012 19:23:12 +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 1S2p7H-0000VB-2J
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:23:11 +0000
Received: from [85.158.139.83:41079] by server-2.bemta-5.messagelabs.com id
	8F/B9-20263-E1B7E4F4; Wed, 29 Feb 2012 19:23:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1330543388!16631854!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3006 invoked from network); 29 Feb 2012 19:23:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 19:23:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330543387; l=860;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Ni+AfhZKcKn3So58VgsoaXeomZU=;
	b=amQmNIoXe2D27igKF5pFzpDS5t1bdHk1aBE9/I1pqPE79B9QipuIXzAn0pFDfs6I+ZU
	q5bRZ31dGYOqaMyLyzrfTgXS80fJ6I4UaPBI+YIqxHUGyhTmwHNMdcnLBhVB5VuKX1VMF
	wnKo1uYuXjoMDG9csrdmIEo+r+NzYivVol0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (cohen mo23) (RZmta 28.0 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I05eb5o1TIQWhX ;
	Wed, 29 Feb 2012 20:22:41 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0745E18638; Wed, 29 Feb 2012 20:22:38 +0100 (CET)
Date: Wed, 29 Feb 2012 20:22:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Message-ID: <20120229192238.GA9226@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, Dan Magenheimer wrote:

> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".

The checkbox thing, and because its fun, is certainly a big part of it.
I agree that a in-guest solution where all capable guests can give away
pages to others is best because there is no IO overhead. And guests know
best what pages can be put into the pool.

Then I think that not all guests are capable enough to contribute their
free pages. And if host memory is low, then things like swapping can
solve the problem at hand.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2pKu-0000ts-UW; Wed, 29 Feb 2012 19:37:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S2pKs-0000tj-T4
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:37:15 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330544228!16999001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5535 invoked from network); 29 Feb 2012 19:37:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 19:37:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11020074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 19:37:07 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 19:37:07 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7bdf0747c170499fabf0db9825d8f53bc1e19b4c
Message-ID: <7bdf0747c170499fabf0.1330544276@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 29 Feb 2012 19:37:56 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: attilio.rao@citrix.com
Subject: [Xen-devel] [PATCH] Fetch the OVMF repository from specific git
 mirror and enable 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

- Fetch the OVMF parent tree from: http://github.com/tianocore/edk2.git
- Add a simple Makefile to edk2 that automagically runs the right scripts
  to build OVMF and setles the resulting binary properly

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

diff -r d7fe4cd831a0 -r 7bdf0747c170 Config.mk
--- a/Config.mk	Wed Feb 29 17:01:41 2012 +0000
+++ b/Config.mk	Wed Feb 29 19:37:29 2012 +0000
@@ -187,12 +187,15 @@ QEMU_REMOTE=git://xenbits.xensource.com/
 endif
 
 ifeq ($(GIT_HTTP),y)
+OVMF_UPSTREAM_URL ?= http://github.com/tianocore/edk2.git
 QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
 else
+OVMF_UPSTREAM_URL ?= git://github.com/tianocore/edk2.git
 QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
+OVMF_UPSTREAM_REVISION ?= master
 QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_TAG ?= c69e288adfe6c273df4b1f3d9c223d8a4fb613cd
 # Wed Feb 8 20:23:36 2012 -0500
@@ -200,7 +203,7 @@ SEABIOS_UPSTREAM_TAG ?= c69e288adfe6c273
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
-CONFIG_OVMF ?= n
+CONFIG_OVMF ?= y
 CONFIG_ROMBIOS ?= y
 CONFIG_SEABIOS ?= y
 
diff -r d7fe4cd831a0 -r 7bdf0747c170 tools/firmware/Makefile
--- a/tools/firmware/Makefile	Wed Feb 29 17:01:41 2012 +0000
+++ b/tools/firmware/Makefile	Wed Feb 29 19:37:29 2012 +0000
@@ -6,12 +6,17 @@ TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
+SUBDIRS-$(CONFIG_OVMF) += ovmf
 SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
 SUBDIRS-$(CONFIG_ROMBIOS) += rombios
 SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
 SUBDIRS-y += hvmloader
 
+ovmf:
+	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf
+	cp ovmf-makefile ovmf/Makefile;
+
 seabios-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
 	cp seabios-config seabios-dir/.config;
@@ -44,9 +49,21 @@ distclean: subdirs-distclean
 subdir-distclean-etherboot: .phony
 	$(MAKE) -C etherboot distclean
 
+subdir-distclean-ovmf: .phony
+	rm -rf ovmf ovmf-remote
+
 subdir-distclean-seabios-dir: .phony
 	rm -rf seabios-dir seabios-dir-remote
 
+.PHONY: ovmf-force-update
+ovmf-force-update:
+	set -ex; \
+	if [ "$(OVMF_UPSTREAM_REVISION)" ]; then \
+		cd ovmf-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(OVMF_UPSTREAM_REVISION); \
+	fi
+
 .PHONY: seabios-dir-force-update
 seabios-dir-force-update:
 	set -ex; \
diff -r d7fe4cd831a0 -r 7bdf0747c170 tools/firmware/ovmf-makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/ovmf-makefile	Wed Feb 29 19:37:29 2012 +0000
@@ -0,0 +1,17 @@
+# OVMF building system is not ready yet to run in parallel.
+# Force it to be serial in order to exploit parallelism for neighbors.
+
+.NOTPARALLEL:
+MAKEFLAGS  += -j1
+
+.PHONY: all
+all: ovmf.bin
+
+.PHONY: ovmf.bin
+ovmf.bin:
+	OvmfPkg/build.sh -a X64
+	cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
+
+.PHONY: clean
+clean:
+	rm -rf ovmf.bin Build/*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2pKu-0000ts-UW; Wed, 29 Feb 2012 19:37:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1S2pKs-0000tj-T4
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:37:15 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1330544228!16999001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5535 invoked from network); 29 Feb 2012 19:37:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Feb 2012 19:37:08 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11020074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 19:37:07 +0000
Received: from dhcp-3-145.uk.xensource.com (10.80.3.221) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 19:37:07 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7bdf0747c170499fabf0db9825d8f53bc1e19b4c
Message-ID: <7bdf0747c170499fabf0.1330544276@dhcp-3-145.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 29 Feb 2012 19:37:56 +0000
From: Attilio Rao <attilio.rao@citrix.com>
To: xen-devel@lists.xensource.com
Cc: attilio.rao@citrix.com
Subject: [Xen-devel] [PATCH] Fetch the OVMF repository from specific git
 mirror and enable 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

- Fetch the OVMF parent tree from: http://github.com/tianocore/edk2.git
- Add a simple Makefile to edk2 that automagically runs the right scripts
  to build OVMF and setles the resulting binary properly

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>

diff -r d7fe4cd831a0 -r 7bdf0747c170 Config.mk
--- a/Config.mk	Wed Feb 29 17:01:41 2012 +0000
+++ b/Config.mk	Wed Feb 29 19:37:29 2012 +0000
@@ -187,12 +187,15 @@ QEMU_REMOTE=git://xenbits.xensource.com/
 endif
 
 ifeq ($(GIT_HTTP),y)
+OVMF_UPSTREAM_URL ?= http://github.com/tianocore/edk2.git
 QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
 else
+OVMF_UPSTREAM_URL ?= git://github.com/tianocore/edk2.git
 QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
+OVMF_UPSTREAM_REVISION ?= master
 QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_TAG ?= c69e288adfe6c273df4b1f3d9c223d8a4fb613cd
 # Wed Feb 8 20:23:36 2012 -0500
@@ -200,7 +203,7 @@ SEABIOS_UPSTREAM_TAG ?= c69e288adfe6c273
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
-CONFIG_OVMF ?= n
+CONFIG_OVMF ?= y
 CONFIG_ROMBIOS ?= y
 CONFIG_SEABIOS ?= y
 
diff -r d7fe4cd831a0 -r 7bdf0747c170 tools/firmware/Makefile
--- a/tools/firmware/Makefile	Wed Feb 29 17:01:41 2012 +0000
+++ b/tools/firmware/Makefile	Wed Feb 29 19:37:29 2012 +0000
@@ -6,12 +6,17 @@ TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
+SUBDIRS-$(CONFIG_OVMF) += ovmf
 SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
 SUBDIRS-$(CONFIG_ROMBIOS) += rombios
 SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
 SUBDIRS-y += hvmloader
 
+ovmf:
+	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) $(OVMF_UPSTREAM_REVISION) ovmf
+	cp ovmf-makefile ovmf/Makefile;
+
 seabios-dir:
 	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
 	cp seabios-config seabios-dir/.config;
@@ -44,9 +49,21 @@ distclean: subdirs-distclean
 subdir-distclean-etherboot: .phony
 	$(MAKE) -C etherboot distclean
 
+subdir-distclean-ovmf: .phony
+	rm -rf ovmf ovmf-remote
+
 subdir-distclean-seabios-dir: .phony
 	rm -rf seabios-dir seabios-dir-remote
 
+.PHONY: ovmf-force-update
+ovmf-force-update:
+	set -ex; \
+	if [ "$(OVMF_UPSTREAM_REVISION)" ]; then \
+		cd ovmf-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(OVMF_UPSTREAM_REVISION); \
+	fi
+
 .PHONY: seabios-dir-force-update
 seabios-dir-force-update:
 	set -ex; \
diff -r d7fe4cd831a0 -r 7bdf0747c170 tools/firmware/ovmf-makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/ovmf-makefile	Wed Feb 29 19:37:29 2012 +0000
@@ -0,0 +1,17 @@
+# OVMF building system is not ready yet to run in parallel.
+# Force it to be serial in order to exploit parallelism for neighbors.
+
+.NOTPARALLEL:
+MAKEFLAGS  += -j1
+
+.PHONY: all
+all: ovmf.bin
+
+.PHONY: ovmf.bin
+ovmf.bin:
+	OvmfPkg/build.sh -a X64
+	cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
+
+.PHONY: clean
+clean:
+	rm -rf ovmf.bin Build/*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2pdd-0001TM-Hl; Wed, 29 Feb 2012 19:56:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2pdc-0001TF-CH
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:56:36 +0000
Received: from [85.158.139.83:30020] by server-4.bemta-5.messagelabs.com id
	C8/C5-10788-2F28E4F4; Wed, 29 Feb 2012 19:56:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330545392!6014325!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11467 invoked from network); 29 Feb 2012 19:56:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 19:56:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330545392; l=454;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=pwyiw2xGhuwDDG/R4Ixd3uzVfUI=;
	b=bajczFk8/XHZS8f+pYpz7PhBIwru7QXnUxRk3J4LsmsNRaJHNL6grj/WED/chQqeq7m
	VycYIiI+qO3/ZyiYUcG64hR0h2AzkTw5aF38V2+fkBz4u1NcDslmT7G0zg2Kq9Hgudft+
	REKrq6T8RzPWtLr2Nhrhd8hhECwCj8UWOZA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (cohen mo39) (RZmta 28.0 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q00a77o1TJ5i8X ;
	Wed, 29 Feb 2012 20:56:28 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A097018638; Wed, 29 Feb 2012 20:56:23 +0100 (CET)
Date: Wed, 29 Feb 2012 20:56:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120229195623.GA11126@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de>
	<20120227165152.GA32471@aepfle.de>
	<EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
	<c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
	<20120229161822.GA6878@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120229161822.GA6878@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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 Wed, Feb 29, Olaf Hering wrote:

> This is the domain_lock() in xenmem_add_to_physmap_once(). 
> 
> Is get_gfn_untyped() correct, or would get_gfn_query() work as well in
> this context?

Another case is emulate_privileged_op(), in "Write CR3" case
get_gfn_untyped() is called with domain_lock().

Same for XENMEM_remove_from_physmap.

These are the places I found by a quick grep for get_gfn_untyped,
get_gfn and get_gfn_unshare.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 19:57:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 19:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2pdd-0001TM-Hl; Wed, 29 Feb 2012 19:56:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2pdc-0001TF-CH
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 19:56:36 +0000
Received: from [85.158.139.83:30020] by server-4.bemta-5.messagelabs.com id
	C8/C5-10788-2F28E4F4; Wed, 29 Feb 2012 19:56:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1330545392!6014325!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyMzM2MjM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11467 invoked from network); 29 Feb 2012 19:56:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Feb 2012 19:56:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330545392; l=454;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=pwyiw2xGhuwDDG/R4Ixd3uzVfUI=;
	b=bajczFk8/XHZS8f+pYpz7PhBIwru7QXnUxRk3J4LsmsNRaJHNL6grj/WED/chQqeq7m
	VycYIiI+qO3/ZyiYUcG64hR0h2AzkTw5aF38V2+fkBz4u1NcDslmT7G0zg2Kq9Hgudft+
	REKrq6T8RzPWtLr2Nhrhd8hhECwCj8UWOZA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (cohen mo39) (RZmta 28.0 SBL|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q00a77o1TJ5i8X ;
	Wed, 29 Feb 2012 20:56:28 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A097018638; Wed, 29 Feb 2012 20:56:23 +0100 (CET)
Date: Wed, 29 Feb 2012 20:56:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120229195623.GA11126@aepfle.de>
References: <patchbomb.1330014862@whitby.uk.xensource.com>
	<20120226221407.GA6385@aepfle.de>
	<20120227165152.GA32471@aepfle.de>
	<EC947F02-8448-45B0-A240-8BBD41C3F9B7@gridcentric.ca>
	<c5cfafa8a6b8bbe61f70aedd3beacfa4.squirrel@webmail.lagarcavilla.org>
	<20120229161822.GA6878@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120229161822.GA6878@aepfle.de>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] [RFC] Use wait queues for paging, 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 Wed, Feb 29, Olaf Hering wrote:

> This is the domain_lock() in xenmem_add_to_physmap_once(). 
> 
> Is get_gfn_untyped() correct, or would get_gfn_query() work as well in
> this context?

Another case is emulate_privileged_op(), in "Write CR3" case
get_gfn_untyped() is called with domain_lock().

Same for XENMEM_remove_from_physmap.

These are the places I found by a quick grep for get_gfn_untyped,
get_gfn and get_gfn_unshare.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:19:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2pyl-0001nX-F8; Wed, 29 Feb 2012 20:18:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@ORACLE.COM>) id 1S2pyj-0001nS-9T
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:18:25 +0000
Received: from [193.109.254.147:3629] by server-6.bemta-14.messagelabs.com id
	EA/F5-01457-0188E4F4; Wed, 29 Feb 2012 20:18:24 +0000
X-Env-Sender: dan.magenheimer@ORACLE.COM
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330546649!51989973!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22221 invoked from network); 29 Feb 2012 20:17:30 -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; 29 Feb 2012 20:17: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 q1TKGP4q019047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 20:17:39 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
	q1TIVIja029402
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 18:31:19 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
	q1TIVHiK019472; Wed, 29 Feb 2012 12:31:17 -0600
MIME-Version: 1.0
Message-ID: <1c14f948-904a-4902-98b5-397d01e39203@default>
Date: Wed, 29 Feb 2012 10:31:02 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
To: andres@lagarcavilla.org
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<ccacbfbb75a2413727f98f49af7e226c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <ccacbfbb75a2413727f98f49af7e226c.squirrel@webmail.lagarcavilla.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F4E87EB.0069,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@ORACLE.COM>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@ORACLE.COM>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > OK, I suppose xenpaging by itself could be useful in a situation such as:
> >
> > 1) A failover occurs from machine A that has lots of RAM to machine B
> >    that has much less RAM, and even horribly bad performance is better
> >    than total service interruption.
> > 2) All currently running VMs have been ballooned down "far enough"
> >    and either have no swap device or insufficiently-sized swap devices,
> >    Xen simply has no more free space, and horrible performance is
> >    acceptable.
> >
> > The historical problem with "hypervisor-based-swapping" solutions such
> > as xenpaging is that it is impossible to ensure that "horribly bad
> > performance" doesn't start occurring under "normal" circumstances
> > specifically because (as Tim indirectly concurs below), policies
> > driven by heuristics and external inference (i.e. dom0 trying
> > to guess how much memory every domU "needs") just don't work.
> >
> > As a result, VMware customers outside of some very specific domains
> > (domains possibly overlapping with Snowflock?) will tell you
> > that "memory overcommit sucks and so we turn it off".
> >
> > Which is why I raised the question "why are we doing this?"...
> > If the answer is "Snowflock customers will benefit from it",
> 
> How come SnowFlock crept in here? :)
> 
> I can unequivocally assert there is no such thing as "SnowFlock customers".

Sorry, no ill will intended.  Tim (I think) earlier in this thread
suggested that page-sharing might benefit snowflock-like workloads.

> Olaf Hering from SuSe invested significant time and effort in getting
> paging to where it is, so you also have to add to the list whatever
> his/their motivations are.

Thus my curiosity... if Novell has some super-secret plans
that we aren't privileged to know, that's fine.  Otherwise,
I was trying to understand the motivations.

> You have to keep in mind that paging is 1. not bad to have and 2. powerful
> and generic, and 3. a far more generic mechanism to populating on demand,
> than what is labeled in the hypervisor as "populate-on-demand".
> 
> Re 2. you could implement a balloon using a pager -- or you could
> implement a version of ramster by putting the page file on a fuse fs with
> compression turned on. Not that you would want to, just to prove a point.
> 
> And re 3. not that there's anything wrong with PoD, but it has several
> assumptions baked in about being a temporary balloon replacement. I
> predict that once 32 bit hypervisor and shadow mode are phased out, PoD
> will also go away, as it will be a "simple" sub-case of paging.

I *think* we are all working on the same goal of "reduce RAM
as a bottleneck *without* a big performance hit".  With xenpaging,
I fear Xen customers will be excited about "reduce/eliminate
RAM as a bottleneck" and then be surprised when there IS a
big performance hit.  I also fear that, with current policy
technology, it will be impossible to draw any sane line to implement
"I want to reduce/eliminate RAM as a bottleneck *as much as possible*
WITHOUT a big performance hit".  In other words, I am hoping
to avoid repeating all the same mistakes that VMware has already
gone through and getting all the same results VMware customers
have already gone through, e.g. "memory overcommit sucks so just
turn it off."  This would be IMHO the classic definition of insanity.
http://www.quotationspage.com/quote/26032.html 

As for PoD and paging, if adding xenpaging or replacing PoD with
xenpaging ensures that a guest continues to run in situations
where PoD would have caused the guest to crash, great!  But
if xenpaging makes performance suck where PoD was doing just
fine, see above.

(And, P.S., apologies to Jan who HAS invested time and energy
into tmem.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:19:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2pyl-0001nX-F8; Wed, 29 Feb 2012 20:18:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@ORACLE.COM>) id 1S2pyj-0001nS-9T
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:18:25 +0000
Received: from [193.109.254.147:3629] by server-6.bemta-14.messagelabs.com id
	EA/F5-01457-0188E4F4; Wed, 29 Feb 2012 20:18:24 +0000
X-Env-Sender: dan.magenheimer@ORACLE.COM
X-Msg-Ref: server-6.tower-27.messagelabs.com!1330546649!51989973!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22221 invoked from network); 29 Feb 2012 20:17:30 -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; 29 Feb 2012 20:17: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 q1TKGP4q019047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 20:17:39 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
	q1TIVIja029402
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 18:31:19 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
	q1TIVHiK019472; Wed, 29 Feb 2012 12:31:17 -0600
MIME-Version: 1.0
Message-ID: <1c14f948-904a-4902-98b5-397d01e39203@default>
Date: Wed, 29 Feb 2012 10:31:02 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
To: andres@lagarcavilla.org
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<ccacbfbb75a2413727f98f49af7e226c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <ccacbfbb75a2413727f98f49af7e226c.squirrel@webmail.lagarcavilla.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F4E87EB.0069,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@ORACLE.COM>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@ORACLE.COM>, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> > OK, I suppose xenpaging by itself could be useful in a situation such as:
> >
> > 1) A failover occurs from machine A that has lots of RAM to machine B
> >    that has much less RAM, and even horribly bad performance is better
> >    than total service interruption.
> > 2) All currently running VMs have been ballooned down "far enough"
> >    and either have no swap device or insufficiently-sized swap devices,
> >    Xen simply has no more free space, and horrible performance is
> >    acceptable.
> >
> > The historical problem with "hypervisor-based-swapping" solutions such
> > as xenpaging is that it is impossible to ensure that "horribly bad
> > performance" doesn't start occurring under "normal" circumstances
> > specifically because (as Tim indirectly concurs below), policies
> > driven by heuristics and external inference (i.e. dom0 trying
> > to guess how much memory every domU "needs") just don't work.
> >
> > As a result, VMware customers outside of some very specific domains
> > (domains possibly overlapping with Snowflock?) will tell you
> > that "memory overcommit sucks and so we turn it off".
> >
> > Which is why I raised the question "why are we doing this?"...
> > If the answer is "Snowflock customers will benefit from it",
> 
> How come SnowFlock crept in here? :)
> 
> I can unequivocally assert there is no such thing as "SnowFlock customers".

Sorry, no ill will intended.  Tim (I think) earlier in this thread
suggested that page-sharing might benefit snowflock-like workloads.

> Olaf Hering from SuSe invested significant time and effort in getting
> paging to where it is, so you also have to add to the list whatever
> his/their motivations are.

Thus my curiosity... if Novell has some super-secret plans
that we aren't privileged to know, that's fine.  Otherwise,
I was trying to understand the motivations.

> You have to keep in mind that paging is 1. not bad to have and 2. powerful
> and generic, and 3. a far more generic mechanism to populating on demand,
> than what is labeled in the hypervisor as "populate-on-demand".
> 
> Re 2. you could implement a balloon using a pager -- or you could
> implement a version of ramster by putting the page file on a fuse fs with
> compression turned on. Not that you would want to, just to prove a point.
> 
> And re 3. not that there's anything wrong with PoD, but it has several
> assumptions baked in about being a temporary balloon replacement. I
> predict that once 32 bit hypervisor and shadow mode are phased out, PoD
> will also go away, as it will be a "simple" sub-case of paging.

I *think* we are all working on the same goal of "reduce RAM
as a bottleneck *without* a big performance hit".  With xenpaging,
I fear Xen customers will be excited about "reduce/eliminate
RAM as a bottleneck" and then be surprised when there IS a
big performance hit.  I also fear that, with current policy
technology, it will be impossible to draw any sane line to implement
"I want to reduce/eliminate RAM as a bottleneck *as much as possible*
WITHOUT a big performance hit".  In other words, I am hoping
to avoid repeating all the same mistakes that VMware has already
gone through and getting all the same results VMware customers
have already gone through, e.g. "memory overcommit sucks so just
turn it off."  This would be IMHO the classic definition of insanity.
http://www.quotationspage.com/quote/26032.html 

As for PoD and paging, if adding xenpaging or replacing PoD with
xenpaging ensures that a guest continues to run in situations
where PoD would have caused the guest to crash, great!  But
if xenpaging makes performance suck where PoD was doing just
fine, see above.

(And, P.S., apologies to Jan who HAS invested time and energy
into tmem.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2q7d-0001xG-FC; Wed, 29 Feb 2012 20:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2q7c-0001xB-7E
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:27:36 +0000
Received: from [193.109.254.147:43245] by server-8.bemta-14.messagelabs.com id
	26/02-04087-63A8E4F4; Wed, 29 Feb 2012 20:27:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330547197!54928595!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32693 invoked from network); 29 Feb 2012 20:26:38 -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; 29 Feb 2012 20:26: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 q1TKRAT9031949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 20:27:11 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
	q1TKQov4014164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 20:26:50 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
	q1TKQnJm002580; Wed, 29 Feb 2012 14:26:49 -0600
MIME-Version: 1.0
Message-ID: <c7009772-34ff-4663-b3ec-e07989f8b449@default>
Date: Wed, 29 Feb 2012 12:26:34 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<CAFLBxZb0c-6ALrXM3MvHuiGHDX4O__8Sq4f11eVyn1sbo3FtZA@mail.gmail.com>
In-Reply-To: <CAFLBxZb0c-6ALrXM3MvHuiGHDX4O__8Sq4f11eVyn1sbo3FtZA@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F4E8A28.003E,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > As a result, VMware customers outside of some very specific domains
> > (domains possibly overlapping with Snowflock?) will tell you
> > that "memory overcommit sucks and so we turn it off".
> >
> > Which is why I raised the question "why are we doing this?"...
> > If the answer is "Snowflock customers will benefit from it",
> > that's fine. =A0If the answer is "to handle disastrous failover
> > situations", that's fine too. =A0And I suppose if the answer is
> > "so that VMware can't claim to have a feature that Xen doesn't
> > have (even if almost nobody uses it)", I suppose that's fine too.
> >
> > I'm mostly curious because I've spent the last four years
> > trying to solve this problem in a more intelligent way
> > and am wondering if the "old way" has improved, or is
> > still just the old way but mostly warmed over for Xen.
> > And, admittedly, a bit jealous because there's apparently
> > so much effort going into the "old way" and not toward
> > "a better way".
> =

> Is it possible to use the "better way" in Windows?

Ian Pratt at one point suggested it might be possible to use some
binary modification techniques to put the tmem hooks into Windows,
though I am dubious.  Lacking that, it would require source
changes done at MS.

> If not, then those
> who want to support Windows guests are stuck with the old way, until
> MS discovers / "re-invents" tmem. :-)  (Maybe you should give a your
> tmem talk at MS research?  Or try to give it again if you already
> have?)

I have an invite (from KY) to visit MS but I think tmem
will require broader support (community and corporate) before
MS would seriously consider it.  Oracle is not exactly MS's
best customer. :-}

> Even then there'd still be a market for supporting all those
> pre-tmem OS's for quite a while.

Yes, very true.

> Apart from that, here's my perspective:
> * Having page sharing is good, because of potential memory savings in
> VDI deployments, but also because of potential for fun things like VM
> fork, &c
> * Having page sharing requires you to have an emergency plan if
> suddenly all the VMs write to their pages and un-share them.
> Hypervisor paging is the only reasonable option here.

Yes, agreed.

> If it makes you feel any better, one of the suggested default policies
> for "what to do with all the memory sharing generates" was "put it
> into a tmem pool". :-)  That, and as we try to hammer out what the
> implications of default policies are, the semantic gap between balloon
> drivers, paging, and sharing, is rearing a very ugly head -- I would
> much rather just hand the paging/ballooning stuff over to tmem.

/me smiles.  Yes, thanks it does make me feel better :-)

I'm not sure putting raw memory into a tmem pool would do
more good than just freeing it.  Putting *data* into tmem
is what makes it valuable, and I think it takes a guest OS
to know how and when to put and get the data and (perhaps
most importantly) when to flush it to ensure coherency.

BUT, maybe this IS a possible new use of tmem that I just
haven't really considered and can't see my way through because
of focusing on the other uses for too long.  So if I can
help with talking this through, let me know.

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 Feb 29 20:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2q7d-0001xG-FC; Wed, 29 Feb 2012 20:27:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1S2q7c-0001xB-7E
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:27:36 +0000
Received: from [193.109.254.147:43245] by server-8.bemta-14.messagelabs.com id
	26/02-04087-63A8E4F4; Wed, 29 Feb 2012 20:27:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1330547197!54928595!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32693 invoked from network); 29 Feb 2012 20:26:38 -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; 29 Feb 2012 20:26: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 q1TKRAT9031949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 20:27:11 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
	q1TKQov4014164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 20:26:50 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
	q1TKQnJm002580; Wed, 29 Feb 2012 14:26:49 -0600
MIME-Version: 1.0
Message-ID: <c7009772-34ff-4663-b3ec-e07989f8b449@default>
Date: Wed, 29 Feb 2012 12:26:34 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<CAFLBxZb0c-6ALrXM3MvHuiGHDX4O__8Sq4f11eVyn1sbo3FtZA@mail.gmail.com>
In-Reply-To: <CAFLBxZb0c-6ALrXM3MvHuiGHDX4O__8Sq4f11eVyn1sbo3FtZA@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F4E8A28.003E,ss=1,re=0.000,fgs=0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@oracle.com>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > As a result, VMware customers outside of some very specific domains
> > (domains possibly overlapping with Snowflock?) will tell you
> > that "memory overcommit sucks and so we turn it off".
> >
> > Which is why I raised the question "why are we doing this?"...
> > If the answer is "Snowflock customers will benefit from it",
> > that's fine. =A0If the answer is "to handle disastrous failover
> > situations", that's fine too. =A0And I suppose if the answer is
> > "so that VMware can't claim to have a feature that Xen doesn't
> > have (even if almost nobody uses it)", I suppose that's fine too.
> >
> > I'm mostly curious because I've spent the last four years
> > trying to solve this problem in a more intelligent way
> > and am wondering if the "old way" has improved, or is
> > still just the old way but mostly warmed over for Xen.
> > And, admittedly, a bit jealous because there's apparently
> > so much effort going into the "old way" and not toward
> > "a better way".
> =

> Is it possible to use the "better way" in Windows?

Ian Pratt at one point suggested it might be possible to use some
binary modification techniques to put the tmem hooks into Windows,
though I am dubious.  Lacking that, it would require source
changes done at MS.

> If not, then those
> who want to support Windows guests are stuck with the old way, until
> MS discovers / "re-invents" tmem. :-)  (Maybe you should give a your
> tmem talk at MS research?  Or try to give it again if you already
> have?)

I have an invite (from KY) to visit MS but I think tmem
will require broader support (community and corporate) before
MS would seriously consider it.  Oracle is not exactly MS's
best customer. :-}

> Even then there'd still be a market for supporting all those
> pre-tmem OS's for quite a while.

Yes, very true.

> Apart from that, here's my perspective:
> * Having page sharing is good, because of potential memory savings in
> VDI deployments, but also because of potential for fun things like VM
> fork, &c
> * Having page sharing requires you to have an emergency plan if
> suddenly all the VMs write to their pages and un-share them.
> Hypervisor paging is the only reasonable option here.

Yes, agreed.

> If it makes you feel any better, one of the suggested default policies
> for "what to do with all the memory sharing generates" was "put it
> into a tmem pool". :-)  That, and as we try to hammer out what the
> implications of default policies are, the semantic gap between balloon
> drivers, paging, and sharing, is rearing a very ugly head -- I would
> much rather just hand the paging/ballooning stuff over to tmem.

/me smiles.  Yes, thanks it does make me feel better :-)

I'm not sure putting raw memory into a tmem pool would do
more good than just freeing it.  Putting *data* into tmem
is what makes it valuable, and I think it takes a guest OS
to know how and when to put and get the data and (perhaps
most importantly) when to flush it to ensure coherency.

BUT, maybe this IS a possible new use of tmem that I just
haven't really considered and can't see my way through because
of focusing on the other uses for too long.  So if I can
help with talking this through, let me know.

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 Feb 29 20:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2qEb-000278-Av; Wed, 29 Feb 2012 20:34:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@ORACLE.COM>) id 1S2qEZ-000273-MI
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:34:47 +0000
Received: from [193.109.254.147:20147] by server-5.bemta-14.messagelabs.com id
	2C/C4-01689-6EB8E4F4; Wed, 29 Feb 2012 20:34:46 +0000
X-Env-Sender: dan.magenheimer@ORACLE.COM
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330547554!61295642!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20889 invoked from network); 29 Feb 2012 20:32:35 -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; 29 Feb 2012 20:32:35 -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 q1TKVA1m004879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 20:34:34 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
	q1TKUbl8022833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 20:30: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
	q1TKUaN3008702; Wed, 29 Feb 2012 14:30:36 -0600
MIME-Version: 1.0
Message-ID: <e37faafb-c01c-4f34-8794-9b178d5dc9a6@default>
Date: Wed, 29 Feb 2012 12:30:22 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
To: Olaf Hering <olaf@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<20120229192238.GA9226@aepfle.de>
In-Reply-To: <20120229192238.GA9226@aepfle.de>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F4E8BE1.0003,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@ORACLE.COM>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@ORACLE.COM>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]
> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
> 
> On Wed, Feb 29, Dan Magenheimer wrote:
> 
> > I'm mostly curious because I've spent the last four years
> > trying to solve this problem in a more intelligent way
> > and am wondering if the "old way" has improved, or is
> > still just the old way but mostly warmed over for Xen.
> > And, admittedly, a bit jealous because there's apparently
> > so much effort going into the "old way" and not toward
> > "a better way".
> 
> The checkbox thing, and because its fun, is certainly a big part of it.

OK.  I can relate to that! ;-)

> I agree that a in-guest solution where all capable guests can give away
> pages to others is best because there is no IO overhead. And guests know
> best what pages can be put into the pool.
> 
> Then I think that not all guests are capable enough to contribute their
> free pages. And if host memory is low, then things like swapping can
> solve the problem at hand.

Yes, as George points out, there will always be legacy guests
for which swapping can solve a problem.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2qEb-000278-Av; Wed, 29 Feb 2012 20:34:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@ORACLE.COM>) id 1S2qEZ-000273-MI
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:34:47 +0000
Received: from [193.109.254.147:20147] by server-5.bemta-14.messagelabs.com id
	2C/C4-01689-6EB8E4F4; Wed, 29 Feb 2012 20:34:46 +0000
X-Env-Sender: dan.magenheimer@ORACLE.COM
X-Msg-Ref: server-8.tower-27.messagelabs.com!1330547554!61295642!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDU3NjQ0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20889 invoked from network); 29 Feb 2012 20:32:35 -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; 29 Feb 2012 20:32:35 -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 q1TKVA1m004879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 29 Feb 2012 20:34:34 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
	q1TKUbl8022833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 29 Feb 2012 20:30: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
	q1TKUaN3008702; Wed, 29 Feb 2012 14:30:36 -0600
MIME-Version: 1.0
Message-ID: <e37faafb-c01c-4f34-8794-9b178d5dc9a6@default>
Date: Wed, 29 Feb 2012 12:30:22 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
To: Olaf Hering <olaf@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<20120229192238.GA9226@aepfle.de>
In-Reply-To: <20120229192238.GA9226@aepfle.de>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6  (510070) [OL
	12.0.6607.1000 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F4E8BE1.0003,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@ORACLE.COM>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@ORACLE.COM>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]
> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
> 
> On Wed, Feb 29, Dan Magenheimer wrote:
> 
> > I'm mostly curious because I've spent the last four years
> > trying to solve this problem in a more intelligent way
> > and am wondering if the "old way" has improved, or is
> > still just the old way but mostly warmed over for Xen.
> > And, admittedly, a bit jealous because there's apparently
> > so much effort going into the "old way" and not toward
> > "a better way".
> 
> The checkbox thing, and because its fun, is certainly a big part of it.

OK.  I can relate to that! ;-)

> I agree that a in-guest solution where all capable guests can give away
> pages to others is best because there is no IO overhead. And guests know
> best what pages can be put into the pool.
> 
> Then I think that not all guests are capable enough to contribute their
> free pages. And if host memory is low, then things like swapping can
> solve the problem at hand.

Yes, as George points out, there will always be legacy guests
for which swapping can solve a problem.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:39:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2qIi-0002EU-WE; Wed, 29 Feb 2012 20:39:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2qIh-0002EH-5a
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:39:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330547933!16462159!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17596 invoked from network); 29 Feb 2012 20:38:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 29 Feb 2012 20:38:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330547932; l=421;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fkTcI7CZfxg0syBtkD4jdxcISbI=;
	b=wsUvSKkDLxmVqRKb617MQr89Lzon/+IRh96KwPbBp6O2O8UL9wuzwiX7NXpV7CfFgsg
	YfK+0QG8m34yqGn7S3sfs3Rg91Ck9NgX6x7Poe59N2GkU7geXOTKnHfiM0INQbdl3NJUM
	+NCv1QBsadsmQt0z+SmMpP/ZOlahsAqP68Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo13) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y01662o1TKPdlv ;
	Wed, 29 Feb 2012 21:38:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B9B5F18638; Wed, 29 Feb 2012 21:38:39 +0100 (CET)
Date: Wed, 29 Feb 2012 21:38:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
Message-ID: <20120229203839.GA16937@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<20120229192238.GA9226@aepfle.de>
	<e37faafb-c01c-4f34-8794-9b178d5dc9a6@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e37faafb-c01c-4f34-8794-9b178d5dc9a6@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@ORACLE.COM>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@ORACLE.COM>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, Dan Magenheimer wrote:

> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Then I think that not all guests are capable enough to contribute their
> > free pages. And if host memory is low, then things like swapping can
> > solve the problem at hand.
> 
> Yes, as George points out, there will always be legacy guests
> for which swapping can solve a problem.

So thats the motivation.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:39:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2qIi-0002EU-WE; Wed, 29 Feb 2012 20:39:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1S2qIh-0002EH-5a
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:39:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1330547933!16462159!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMDc5ODM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17596 invoked from network); 29 Feb 2012 20:38:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 29 Feb 2012 20:38:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330547932; l=421;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=fkTcI7CZfxg0syBtkD4jdxcISbI=;
	b=wsUvSKkDLxmVqRKb617MQr89Lzon/+IRh96KwPbBp6O2O8UL9wuzwiX7NXpV7CfFgsg
	YfK+0QG8m34yqGn7S3sfs3Rg91Ck9NgX6x7Poe59N2GkU7geXOTKnHfiM0INQbdl3NJUM
	+NCv1QBsadsmQt0z+SmMpP/ZOlahsAqP68Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmxtMZ80VwmRNV6936
X-RZG-CLASS-ID: mo00
Received: from probook.site (ip-80-226-24-15.vodafone-net.de [80.226.24.15])
	by smtp.strato.de (fruni mo13) (RZmta 27.7 SBL|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y01662o1TKPdlv ;
	Wed, 29 Feb 2012 21:38:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B9B5F18638; Wed, 29 Feb 2012 21:38:39 +0100 (CET)
Date: Wed, 29 Feb 2012 21:38:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Dan Magenheimer <dan.magenheimer@ORACLE.COM>
Message-ID: <20120229203839.GA16937@aepfle.de>
References: <f8264e57-9326-4794-8025-db8ff0f07380@default>
	<20120224214228.GA23473@aepfle.de>
	<104d17ef-192d-4a13-9d19-b27a58f04384@default>
	<20120229104308.GA23724@aepfle.de>
	<cc4d85dc-cc0e-478d-b678-3747e6c06df9@default>
	<20120229192238.GA9226@aepfle.de>
	<e37faafb-c01c-4f34-8794-9b178d5dc9a6@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e37faafb-c01c-4f34-8794-9b178d5dc9a6@default>
User-Agent: Mutt/1.5.21.rev5543 (2011-12-20)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@ORACLE.COM>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	Kurt Hackel <kurt.hackel@ORACLE.COM>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Feb 29, Dan Magenheimer wrote:

> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Then I think that not all guests are capable enough to contribute their
> > free pages. And if host memory is low, then things like swapping can
> > solve the problem at hand.
> 
> Yes, as George points out, there will always be legacy guests
> for which swapping can solve a problem.

So thats the motivation.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:49:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2qSO-0002Qq-2F; Wed, 29 Feb 2012 20:49:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2qSM-0002Ql-7w
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:49:02 +0000
Received: from [85.158.139.83:12626] by server-2.bemta-5.messagelabs.com id
	42/D4-20263-D3F8E4F4; Wed, 29 Feb 2012 20:49:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330548540!16746585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27386 invoked from network); 29 Feb 2012 20:49:00 -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;
	29 Feb 2012 20:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11021232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 20:49:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 20:49:00 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2qSK-0007Wl-2D;
	Wed, 29 Feb 2012 20:49:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2qSJ-00051M-TK;
	Wed, 29 Feb 2012 20:48:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12115-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 29 Feb 2012 20:48:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12115: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12115 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12115/

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. 12104
 build-i386                    4 xen-build                 fail REGR. vs. 12104

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 12104

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-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-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  39283113682e
baseline version:
 xen                  a7bacdc5449a

------------------------------------------------------------
People who touched revisions under test:
  Attilio Rao <attilio.rao@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 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:   24908:39283113682e
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Feb 29 14:38:28 2012 +0000
    
    tools: xencommons: revert accidental hunk in 24905:2b5cf6bde62d
    
    24905:2b5cf6bde62d accidentally contained a change to
    tools/hotplug/Linux/init.d/xencommons.  That change is probably OK but
    should not be in 24905 so remove it.
    
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24907:24117fff2fe1
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 29 14:36:04 2012 +0000
    
    install: remove old checks from install.sh
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24906:606af3fbd6fc
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Feb 29 14:32:51 2012 +0000
    
    libxl: use libxl wrapper for yajl_gen_alloc
    
    To fix compile errors with libyajl2:
     * use libxl_yajl_gen_alloc()
     * use libxl_yajl_length
     * link xl with -lyajl for yajl_gen_string()
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24905:2b5cf6bde62d
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Feb 29 14:31:59 2012 +0000
    
    libxl: rename libxl__yajl_gen_alloc
    
    libxl__yajl_gen_alloc() is called by generic code,
    rename it to libx_yajl_gen_alloc().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24904:93d379d11cbb
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Wed Feb 29 13:51:42 2012 +0000
    
    vpmu: No need for two initialisation functions
    
    With the changeset 24529:87854d3bed93 we got 2 initialisation
    functions for the arch specific stuff. This is no more needed.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24903:bea68a25f368
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Wed Feb 29 13:51:12 2012 +0000
    
    vpmu: cleanup structures
    
    - struct msr_load_store_entry is unused
    - struct pmumsr is only used in the vmx part
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24902:57706facdbdd
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:48:41 2012 +0000
    
    xsm: expose context of event channel peers
    
    This hypercall allows a domain to identify the security context of a
    domain that it is communicating with using the interdomain event
    channel that it is using for the communication. This can be used to
    augment Xen's security permissions with intra-domain security checks.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24901:b8adaf598a6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:47:41 2012 +0000
    
    xsm/flask: buffer AVC messages for output
    
    When multiple CPUs hit an AVC audit message, the resulting output in
    the ring buffer and serial console is garbled due to the audit process
    using many separate printk invocations for each message. Change the
    AVC audit process to use a temporary buffer and output the contents
    once the entire audit message is complete.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24900:2e6c3194c3b2
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:47:11 2012 +0000
    
    xsm/flask: clean interdomain event channel hook
    
    Don't attempt to relabel the already-bound half of the event channel
    pair created by an interdomain event channel. This relabeling also
    performed an incorrect check that the destination domain is permitted
    to create the reverse event channel, which may not be true if the
    unbound channel was created by the domain builder (like the xenstore
    channel).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24899:ea7a07622a43
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:46:32 2012 +0000
    
    xsm: label xen-consumer event channels
    
    Event channels created during the domain build process for HVM domains
    did not call the XSM creation hook. Since these channels are used
    internally by Xen, redirect them to DOMAIN_INVAID instead of failing
    to create if the XSM hook fails the permissions check.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24898:be9d56fada86
user:        Keir Fraser <keir@xen.org>
date:        Wed Feb 29 13:43:44 2012 +0000
    
    Update autoconf-generated configure script.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24897:f25e5785327e
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:40:25 2012 +0000
    
    build: Export configure variables to hypervisor build
    
    Since the introduction of autoconf, builds with XSM enabled in .config
    have been broken unless FLASK_ENABLE was explicitly set. Since the
    setting in .config has apparently been deprecated in favor of an
    autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
    also makes --disable-debug and some paths to be pulled from the
    configure process in the hypervisor build.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24896:d6c72d5ab780
user:        Attilio Rao <attilio.rao@citrix.com>
date:        Wed Feb 29 13:33:51 2012 +0000
    
    hvmloader: drop the ovmf32 support and rename ovmf64 -> ovmf.
    
    - Remove the 15cpus hack from ovmf because it should be unnecessary on
    nowadays windows/EFI supported.
    
    Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24895:a43eeaedf61c
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: Handle booting on SMP platforms
    
    Make all non-boot CPUs wait forever instead of trying to boot in parallel.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24894:d19a254197d7
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: strip xen binary
    
    The symbols in it are wrong anyway and will only confuse people
    who ought to be looking at xen-syms.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24893:72551f578776
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Tue Feb 28 09:06:27 2012 +0100
    
    X86: expose HLE/RTM features to dom0
    
    Intel recently release 2 new features, HLE and TRM.
    Refer to http://software.intel.com/file/41417.
    This patch expose them to dom0.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24892:a7bacdc5449a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 27 17:05:18 2012 +0000
    
    Update SEABIOS_UPSTREAM_TAG
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 20:49:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 20: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 1S2qSO-0002Qq-2F; Wed, 29 Feb 2012 20:49:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1S2qSM-0002Ql-7w
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 20:49:02 +0000
Received: from [85.158.139.83:12626] by server-2.bemta-5.messagelabs.com id
	42/D4-20263-D3F8E4F4; Wed, 29 Feb 2012 20:49:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1330548540!16746585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjA4MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27386 invoked from network); 29 Feb 2012 20:49:00 -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;
	29 Feb 2012 20:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="11021232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Feb 2012 20:49:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 29 Feb 2012 20:49:00 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1S2qSK-0007Wl-2D;
	Wed, 29 Feb 2012 20:49:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1S2qSJ-00051M-TK;
	Wed, 29 Feb 2012 20:48:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-12115-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 29 Feb 2012 20:48:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 12115: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 12115 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12115/

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. 12104
 build-i386                    4 xen-build                 fail REGR. vs. 12104

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 12104

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-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-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  39283113682e
baseline version:
 xen                  a7bacdc5449a

------------------------------------------------------------
People who touched revisions under test:
  Attilio Rao <attilio.rao@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 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:   24908:39283113682e
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Feb 29 14:38:28 2012 +0000
    
    tools: xencommons: revert accidental hunk in 24905:2b5cf6bde62d
    
    24905:2b5cf6bde62d accidentally contained a change to
    tools/hotplug/Linux/init.d/xencommons.  That change is probably OK but
    should not be in 24905 so remove it.
    
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24907:24117fff2fe1
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Wed Feb 29 14:36:04 2012 +0000
    
    install: remove old checks from install.sh
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24906:606af3fbd6fc
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Feb 29 14:32:51 2012 +0000
    
    libxl: use libxl wrapper for yajl_gen_alloc
    
    To fix compile errors with libyajl2:
     * use libxl_yajl_gen_alloc()
     * use libxl_yajl_length
     * link xl with -lyajl for yajl_gen_string()
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24905:2b5cf6bde62d
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Feb 29 14:31:59 2012 +0000
    
    libxl: rename libxl__yajl_gen_alloc
    
    libxl__yajl_gen_alloc() is called by generic code,
    rename it to libx_yajl_gen_alloc().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24904:93d379d11cbb
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Wed Feb 29 13:51:42 2012 +0000
    
    vpmu: No need for two initialisation functions
    
    With the changeset 24529:87854d3bed93 we got 2 initialisation
    functions for the arch specific stuff. This is no more needed.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24903:bea68a25f368
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Wed Feb 29 13:51:12 2012 +0000
    
    vpmu: cleanup structures
    
    - struct msr_load_store_entry is unused
    - struct pmumsr is only used in the vmx part
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24902:57706facdbdd
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:48:41 2012 +0000
    
    xsm: expose context of event channel peers
    
    This hypercall allows a domain to identify the security context of a
    domain that it is communicating with using the interdomain event
    channel that it is using for the communication. This can be used to
    augment Xen's security permissions with intra-domain security checks.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24901:b8adaf598a6a
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:47:41 2012 +0000
    
    xsm/flask: buffer AVC messages for output
    
    When multiple CPUs hit an AVC audit message, the resulting output in
    the ring buffer and serial console is garbled due to the audit process
    using many separate printk invocations for each message. Change the
    AVC audit process to use a temporary buffer and output the contents
    once the entire audit message is complete.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24900:2e6c3194c3b2
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:47:11 2012 +0000
    
    xsm/flask: clean interdomain event channel hook
    
    Don't attempt to relabel the already-bound half of the event channel
    pair created by an interdomain event channel. This relabeling also
    performed an incorrect check that the destination domain is permitted
    to create the reverse event channel, which may not be true if the
    unbound channel was created by the domain builder (like the xenstore
    channel).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24899:ea7a07622a43
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:46:32 2012 +0000
    
    xsm: label xen-consumer event channels
    
    Event channels created during the domain build process for HVM domains
    did not call the XSM creation hook. Since these channels are used
    internally by Xen, redirect them to DOMAIN_INVAID instead of failing
    to create if the XSM hook fails the permissions check.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24898:be9d56fada86
user:        Keir Fraser <keir@xen.org>
date:        Wed Feb 29 13:43:44 2012 +0000
    
    Update autoconf-generated configure script.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24897:f25e5785327e
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 29 13:40:25 2012 +0000
    
    build: Export configure variables to hypervisor build
    
    Since the introduction of autoconf, builds with XSM enabled in .config
    have been broken unless FLASK_ENABLE was explicitly set. Since the
    setting in .config has apparently been deprecated in favor of an
    autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
    also makes --disable-debug and some paths to be pulled from the
    configure process in the hypervisor build.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24896:d6c72d5ab780
user:        Attilio Rao <attilio.rao@citrix.com>
date:        Wed Feb 29 13:33:51 2012 +0000
    
    hvmloader: drop the ovmf32 support and rename ovmf64 -> ovmf.
    
    - Remove the 15cpus hack from ovmf because it should be unnecessary on
    nowadays windows/EFI supported.
    
    Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24895:a43eeaedf61c
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: Handle booting on SMP platforms
    
    Make all non-boot CPUs wait forever instead of trying to boot in parallel.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24894:d19a254197d7
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 28 10:17:27 2012 +0000
    
    arm: strip xen binary
    
    The symbols in it are wrong anyway and will only confuse people
    who ought to be looking at xen-syms.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24893:72551f578776
user:        Liu, Jinsong <jinsong.liu@intel.com>
date:        Tue Feb 28 09:06:27 2012 +0100
    
    X86: expose HLE/RTM features to dom0
    
    Intel recently release 2 new features, HLE and TRM.
    Refer to http://software.intel.com/file/41417.
    This patch expose them to dom0.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24892:a7bacdc5449a
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Feb 27 17:05:18 2012 +0000
    
    Update SEABIOS_UPSTREAM_TAG
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <Ian.Campbell@citrix.com>
    
    
========================================
commit 128de2549c5f24e4a437b86bd2e46f023976d50a
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Mon Feb 20 16:21:47 2012 +0000

    Intel GPU passthrough: Host bridge config space
    
    Expose more host bridge config space value to make the driver happy
    for all the different revisions of the device.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 22:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 22: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 1S2rh3-0002q9-GC; Wed, 29 Feb 2012 22:08:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S2rh2-0002q4-KU
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 22:08:16 +0000
Received: from [193.109.254.147:9598] by server-8.bemta-14.messagelabs.com id
	E5/79-04087-FC1AE4F4; Wed, 29 Feb 2012 22:08:15 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330553252!54639390!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14167 invoked from network); 29 Feb 2012 22:07:33 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-12.tower-27.messagelabs.com with SMTP;
	29 Feb 2012 22:07:33 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 29 Feb 2012 15:08:14 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1TM8Dal086369;
	Wed, 29 Feb 2012 15:08:14 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 932a05fb73bbd775b8f7084c5af247fc6fec8694
Message-Id: <932a05fb73bbd775b8f7.1330553293@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Wed, 29 Feb 2012 15:08:13 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 29 Feb 2012 22:08:14.0546 (UTC)
	FILETIME=[A2016B20:01CCF72E]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] Improve documentation of the blkif 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

 o Fix typo "discard-aligment" -> "discard-alignment"
 o Fix typo "unamp" -> "unmap"
 o Fix typo "formated" -> "formatted"
 o Clarify the text for "params".
 o Clarify the text for "sector-size".

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a7bacdc5449a -r 932a05fb73bb xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/include/public/io/blkif.h	Wed Feb 29 15:07:54 2012 -0700
@@ -59,7 +59,7 @@
  * All data in the XenStore is stored as strings.  Nodes specifying numeric
  * values are encoded in decimal.  Integer value ranges listed below are
  * expressed as fixed sized integer types capable of storing the conversion
- * of a properly formated node string, without loss of information.
+ * of a properly formatted node string, without loss of information.
  *
  * Any specified default value is in effect if the corresponding XenBus node
  * is not present in the XenStore.
@@ -88,9 +88,9 @@
  * params
  *      Values:         string
  *
- *      A free formatted string providing sufficient information for the
- *      backend driver to open the backing device.  (e.g. the path to the
- *      file or block device representing the backing store.)
+ *      Data used by the backend driver to locate and configure the backing
+ *      device.  The format and semantics of this data vary according to the
+ *      backing device in use and are outside the scope of this specification.
  *
  * type
  *      Values:         "file", "phy", "tap"
@@ -147,7 +147,7 @@
  *
  *------------------------- Backend Device Properties -------------------------
  *
- * discard-aligment
+ * discard-alignment
  *      Values:         <uint32_t>
  *      Default Value:  0
  *      Notes:          4, 5
@@ -180,7 +180,8 @@
  * sector-size
  *      Values:         <uint32_t>
  *
- *      The native sector size, in bytes, of the backend device.
+ *      The size, in bytes, of the individually addressible data blocks
+ *      on the backend device.
  *
  * sectors
  *      Values:         <uint64_t>
@@ -261,11 +262,11 @@
  * -----
  * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
  *     PV drivers.
- * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ * (2) Multi-page ring buffer scheme first used in some Red Hat distributions
  *     including a distribution deployed on certain nodes of the Amazon
  *     EC2 cluster.
  * (3) Support for multi-page ring buffers was implemented independently,
- *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     in slightly different forms, by both Citrix and Red Hat/Amazon.
  *     For full interoperability, block front and backends should publish
  *     identical ring parameters, adjusted for unit differences, to the
  *     XenStore nodes used in both schemes.
@@ -387,7 +388,7 @@
  * discarded region on the device must be rendered unrecoverable before the
  * command returns.
  *
- * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * This operation is analogous to performing a trim (ATA) or unmap (SCSI),
  * command on a native device.
  *
  * More information about trim/unmap operations can be found at:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 22:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 22: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 1S2rh3-0002q9-GC; Wed, 29 Feb 2012 22:08:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <justing@spectralogic.com>) id 1S2rh2-0002q4-KU
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 22:08:16 +0000
Received: from [193.109.254.147:9598] by server-8.bemta-14.messagelabs.com id
	E5/79-04087-FC1AE4F4; Wed, 29 Feb 2012 22:08:15 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1330553252!54639390!1
X-Originating-IP: [207.225.98.7]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14167 invoked from network); 29 Feb 2012 22:07:33 -0000
Received: from slblexch02.spectralogic.com (HELO slblexch02.sldomain.com)
	(207.225.98.7) by server-12.tower-27.messagelabs.com with SMTP;
	29 Feb 2012 22:07:33 -0000
Received: from ns1.eng.sldomain.com ([10.1.0.9]) by slblexch02.sldomain.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 29 Feb 2012 15:08:14 -0700
Received: from ns1.eng.sldomain.com (ns1.eng.sldomain.com [10.1.0.9])
	by ns1.eng.sldomain.com (8.14.5/8.14.5) with ESMTP id q1TM8Dal086369;
	Wed, 29 Feb 2012 15:08:14 -0700 (MST)
	(envelope-from justing@spectralogic.com)
MIME-Version: 1.0
X-Mercurial-Node: 932a05fb73bbd775b8f7084c5af247fc6fec8694
Message-Id: <932a05fb73bbd775b8f7.1330553293@ns1.eng.sldomain.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Wed, 29 Feb 2012 15:08:13 -0700
From: "Justin T. Gibbs" <justing@spectralogic.com>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 29 Feb 2012 22:08:14.0546 (UTC)
	FILETIME=[A2016B20:01CCF72E]
Cc: Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH] Improve documentation of the blkif 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

 o Fix typo "discard-aligment" -> "discard-alignment"
 o Fix typo "unamp" -> "unmap"
 o Fix typo "formated" -> "formatted"
 o Clarify the text for "params".
 o Clarify the text for "sector-size".

No functional changes.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>

diff -r a7bacdc5449a -r 932a05fb73bb xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h	Mon Feb 27 17:05:18 2012 +0000
+++ b/xen/include/public/io/blkif.h	Wed Feb 29 15:07:54 2012 -0700
@@ -59,7 +59,7 @@
  * All data in the XenStore is stored as strings.  Nodes specifying numeric
  * values are encoded in decimal.  Integer value ranges listed below are
  * expressed as fixed sized integer types capable of storing the conversion
- * of a properly formated node string, without loss of information.
+ * of a properly formatted node string, without loss of information.
  *
  * Any specified default value is in effect if the corresponding XenBus node
  * is not present in the XenStore.
@@ -88,9 +88,9 @@
  * params
  *      Values:         string
  *
- *      A free formatted string providing sufficient information for the
- *      backend driver to open the backing device.  (e.g. the path to the
- *      file or block device representing the backing store.)
+ *      Data used by the backend driver to locate and configure the backing
+ *      device.  The format and semantics of this data vary according to the
+ *      backing device in use and are outside the scope of this specification.
  *
  * type
  *      Values:         "file", "phy", "tap"
@@ -147,7 +147,7 @@
  *
  *------------------------- Backend Device Properties -------------------------
  *
- * discard-aligment
+ * discard-alignment
  *      Values:         <uint32_t>
  *      Default Value:  0
  *      Notes:          4, 5
@@ -180,7 +180,8 @@
  * sector-size
  *      Values:         <uint32_t>
  *
- *      The native sector size, in bytes, of the backend device.
+ *      The size, in bytes, of the individually addressible data blocks
+ *      on the backend device.
  *
  * sectors
  *      Values:         <uint64_t>
@@ -261,11 +262,11 @@
  * -----
  * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer
  *     PV drivers.
- * (2) Multi-page ring buffer scheme first used in some RedHat distributions
+ * (2) Multi-page ring buffer scheme first used in some Red Hat distributions
  *     including a distribution deployed on certain nodes of the Amazon
  *     EC2 cluster.
  * (3) Support for multi-page ring buffers was implemented independently,
- *     in slightly different forms, by both Citrix and RedHat/Amazon.
+ *     in slightly different forms, by both Citrix and Red Hat/Amazon.
  *     For full interoperability, block front and backends should publish
  *     identical ring parameters, adjusted for unit differences, to the
  *     XenStore nodes used in both schemes.
@@ -387,7 +388,7 @@
  * discarded region on the device must be rendered unrecoverable before the
  * command returns.
  *
- * This operation is analogous to performing a trim (ATA) or unamp (SCSI),
+ * This operation is analogous to performing a trim (ATA) or unmap (SCSI),
  * command on a native device.
  *
  * More information about trim/unmap operations can be found at:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 22:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 22:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2rv8-00030J-Sh; Wed, 29 Feb 2012 22:22:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S2rv7-00030B-Jf
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 22:22:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330554162!10931962!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 29 Feb 2012 22:22:42 -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; 29 Feb 2012 22:22:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S2ruy-0009kz-F5; Wed, 29 Feb 2012 22:22:40 +0000
Date: Wed, 29 Feb 2012 22:22:40 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120229222240.GB35093@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<1330526182.4270.123.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330526182.4270.123.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00 of 10] arm: SMP 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 14:36 +0000 on 29 Feb (1330526182), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > This patch series implements SMP boot for arch/arm, as far as getting
> > all CPUs up and running the idle loop.
> 
> What additional steps are needed when building the model to get an SMP
> system?
> 
> Ideally this would eventually be documented in
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModels but it is probably a bit premature for that right now.
> 
> I think it is sufficient to do the following after opening the project
> ("sgcanvas <SGPROJ>") and before clicking the "Build" button.
> 
>       * Right click the header of the "cluster" in the diagram (the top
>         bit of the box which says "cluster" in it)
>       * Select "Object Properties" from the context menu
>       * In the "Parameters" tab update the "num_cores" variable, e.g. to
>         "0x4"
>       * Click build and continue as usual.

Yes, that is exactly what I did. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 29 22:23:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 29 Feb 2012 22:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1S2rv8-00030J-Sh; Wed, 29 Feb 2012 22:22:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1S2rv7-00030B-Jf
	for xen-devel@lists.xensource.com; Wed, 29 Feb 2012 22:22:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1330554162!10931962!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 29 Feb 2012 22:22:42 -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; 29 Feb 2012 22:22:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1S2ruy-0009kz-F5; Wed, 29 Feb 2012 22:22:40 +0000
Date: Wed, 29 Feb 2012 22:22:40 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120229222240.GB35093@ocelot.phlegethon.org>
References: <patchbomb.1330018847@whitby.uk.xensource.com>
	<1330526182.4270.123.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1330526182.4270.123.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00 of 10] arm: SMP 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 14:36 +0000 on 29 Feb (1330526182), Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:40 +0000, Tim Deegan wrote:
> > This patch series implements SMP boot for arch/arm, as far as getting
> > all CPUs up and running the idle loop.
> 
> What additional steps are needed when building the model to get an SMP
> system?
> 
> Ideally this would eventually be documented in
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/FastModels but it is probably a bit premature for that right now.
> 
> I think it is sufficient to do the following after opening the project
> ("sgcanvas <SGPROJ>") and before clicking the "Build" button.
> 
>       * Right click the header of the "cluster" in the diagram (the top
>         bit of the box which says "cluster" in it)
>       * Select "Object Properties" from the context menu
>       * In the "Parameters" tab update the "num_cores" variable, e.g. to
>         "0x4"
>       * Click build and continue as usual.

Yes, that is exactly what I did. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel